-
Notifications
You must be signed in to change notification settings - Fork 5.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add driver for the Waveshare DSI-TOUCH series panels. #6566
base: rpi-6.6.y
Are you sure you want to change the base?
Conversation
Check the auto-build errors. And as a wider question, does this warrant a new driver? Are the devices so different from the v1s? |
aeec1c0
to
086de2c
Compare
Yes, I think a new driver needs to be developed. v2 versions have significant architectural changes compared to the v1 series.
btw,The previous check auto-build errors has been resolved |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I had a couple of these comments pending when I thought I'd submitted them.
Other than possibly EMC, seeing as both the 2 and 4 lane modes achieve the same refresh rate, is there a benefit in providing options for both?
return ret; | ||
} | ||
|
||
ctx->panel.prepare_prev_first = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Duplicate of line 1205.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do I need to push it again to solve this problem? Avoid repeated reviews, or do I directly push the modified parts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update the patches on your local repo (git commit --amend
and git rebase -i
) to make a consistent set of what you want to merge, and then git push -f ...
to push to the same waveshare DSI-LCD branch on Github. That automatically updates the PR, and we'll review the changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issues raised have been fixed , PTAL.
.height_mm = 172, | ||
}; | ||
|
||
static const struct drm_display_mode ws_panel_8_a_2lane_mode = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This mode is identical to ws_panel_8_a_mode
, so you could remove the duplication.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And the same as above, we will modify it
.htotal = 800 + 40 + 20 + 20, | ||
.vdisplay = 1280, | ||
.vsync_start = 1280 + 30, | ||
.vsync_end = 1280 + 30 + 10, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a need to vary the vertical front porch and sync width between the 2 and 4 lane modes? Both appear to work as well as each other in 2 lane mode (haven't tested 4) when using kmstest --flip -r 70000000,800/40/20/20/+,1280/30/10/4/+
and kmstest --flip -r 70000000,800/40/20/20/+,1280/20/20/4/+
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both seem to work normally, we will unify them
.vsync_end = 1280 + 30 + 10, | |
.vsync_end = 1280 + 20+ 10, |
&ws_panel_10_1_inch_a_4lane_desc }, | ||
{ .compatible = "waveshare,10.1-dsi-touch-a", | ||
&ws_panel_10_1_inch_a_desc }, | ||
{ .compatible = "waveshare,8.0-dsi-touch-a,4lane", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't believe commas are permitted within compatibles other than separating the vendor and product name. @pelwell Could you confirm?
Ditto for waveshare,10.1-dsi-touch-a,4lane
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. The current version of the spec says:
The recommended format is "manufacturer,model", where manufacturer is a string describing the name
of the manufacturer (such as a stock ticker symbol), and model specifies the model number.
The compatible string should consist only of lowercase letters, digits and dashes, and should start with a letter.
A single comma is typically only used following a vendor prefix. Underscores should not be used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the reminder, we will change it
{ .compatible = "waveshare,8.0-dsi-touch-a,4lane", | |
{ .compatible = "waveshare,8.0-dsi-touch-a-4lane", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few comments, however as this driver isn't going to be upstreamed in the current form, I don't view any of them as critical to be resolved.
If you want to implement any of the changes then please respond in the next 48 hours to say so, otherwise I'm happy for this to be merged.
int ret; | ||
|
||
/* And reset it */ | ||
if (ctx->reset != NULL) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can be simplified to if (ctx->reset) {
This occurs in number of places.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good suggestion, we'll deal with it.
return 0; | ||
} | ||
|
||
static int ws_panel_enable(struct drm_panel *panel) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the panel functions are optional, so you can just omit these.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, we'll delete this part.
struct ws_panel *ctx = panel_to_ws(panel); | ||
|
||
mipi_dsi_dcs_set_display_off(ctx->dsi); | ||
mipi_dsi_dcs_enter_sleep_mode(ctx->dsi); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Slight mismatch with these two as mipi_dsi_dcs_set_display_on
and mipi_dsi_dcs_exit_sleep_mode
aren't called in prepare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initialized to add display and postpone sleep instructions. Because some screens need to add other instructions to the mipi_dsi_dcs_set_display_on (0x29) and mipi_dsi_dcs_exit_sleep_mode (0x11) , there is no direct function call.
|
||
state->direction_state &= ~(1 << offset); | ||
|
||
last_val = state->poweron_state; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
state->poweron_state
is being accessed here without the mutex being claimed.
Is the mutex needed to protect state->direction_state
? You are doing a read/modify/write with the &=
, and |=
in waveshare_panel_gpio_direction_in
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, we'll add a mutex
|
||
last_val = state->poweron_state; | ||
if (brightness) | ||
last_val |= (1 << 2); // Enable BL_EN |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bit 2 is going to be advertised as a GPIO that another driver could request, however you are modifying it internally from the driver. You have the potential for issues there if others make use of this driver from their own overlays.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, we will use gpiod_set_value_cansleep to modify the BL_EN hardware instead of writing the registers directly
#gpio-cells = <2>; | ||
}; | ||
|
||
touch: goodix@5d { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seeing as we have no control over the interrupt line, I assume it is pulled down so that the touch controller will reliably come out of reset on address 0x5d. (Using the INT line to determine I2C address is a right pain with these Goodix controllers).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The muc is connected to the INT pin. If necessary, we can set the INT pin level when exiting the reset through the MCU. By default, the I2C address of Goodix controllers is 0x5d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As long as you have it in hand.
Avoiding a repeat of #6538 would be good, and I've been in exactly the same position with an early version of the Raspberry Pi Touch Display 2.
The vc4-dpi-hyperpixel4 overlay hacks around the issue by defining the touch controller on both addresses, and accepts that one will fail to probe.
data); | ||
|
||
state->direction_state = 0; | ||
state->poweron_state = (1 << 9) | (1 << 8) | (1 << 4) | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a general preference to use the BIT(n)
macro to denote bit-usage such as these. It could probably replace all your 1 << n
uses in the driver.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, we'll use BIT(n)
replace, maybe we're a bit old-school,lol
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would often go for the 1<<n
style too, but the Linux coding style can be a bit fussy and I'm now used to reviewing based on that.
} | ||
|
||
static int waveshare_panel_gpio_direction_out(struct gpio_chip *gc, | ||
unsigned int offset, int val) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you need to be able to control the direction with the current panels? If not, then keep the driver simple for now, and add direction control later when it is needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can control the direction of some GPIOs, such as the INT pin mentioned above, which we hope to keep. If necessary, we can detect the level of some pins.
The regulator of the Waveshare DSI-TOUCH series panels is different. Add a new driver for this regulator. Signed-off-by: Waveshare_Team <support@waveshare.com>
…ries panels. the driver are provided for the Waveshare DSI-TOUCH series panels, modelled after the other Ilitek controller drivers, but not limited to Ilitek series controllers. The aim is to offer a more consistent operation and experience for the Waveshare DSI-TOUCH series panels. Signed-off-by: Waveshare_Team <support@waveshare.com>
…vice Tree support. Add the device tree for the Waveshare DSI-TOUCH series panels. Signed-off-by: Waveshare_Team <support@waveshare.com>
Enable the Waveshare DSI-TOUCH series panel driver in the defconfig files that support the Pi5/Pi4/Pi3 family. Signed-off-by: Waveshare_Team <support@waveshare.com>
Hello, everyone:
This is the driver for the DSI-TOUCH series of panels to be released by Waveshare.
Regarding the missing help warning, it should be caused by the length of the help description being less than 4, so i think it allowed to ignore things.
If you have any other suggestions we'd be happy to make changes!