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
drivers: display: introduce G1120B0MIPI watch display #57578
drivers: display: introduce G1120B0MIPI watch display #57578
Conversation
dd3e157
to
6770484
Compare
8295130
to
b889404
Compare
a93a930
to
9fb0296
Compare
#define MCUX_DSI_DPI_CONFIG(id) \ | ||
IF_ENABLED(DT_NODE_HAS_PROP(DT_DRV_INST(id), nxp_lcdif), \ | ||
(.dpi_config = { \ | ||
.dpiColorCoding = DT_INST_ENUM_IDX(id, dpi_color_coding), \ |
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.
How about having the macro at this level? Like
#define MCUX_DSI_DPI_CONFIG_INIT(id) { \
.dpiColorCoding = ...
That's what I had in mind when I suggested to bring it out (sorry I was unclear), thinking that doing that would get rid of another tab and then you'd actually be able to keep more stuff inline.
The kernel structure have these all over, example: https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/kernel.h#L695-L710
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 misunderstood- thanks for clarifying. Should be fixed to this format in latest push
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.
Thanks, I feel a bit bad that after making you redo this twice most lines still don't fit without wrapping by just one character but it's probably good to have it split out anyway :-)
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.
No worries- still looks cleaner overall
4c27347
to
d567341
Compare
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.
some minor nitpicks
if DISPLAY | ||
|
||
# Enable MIPI DSI, as this display controller requires it. | ||
|
||
config MIPI_DSI | ||
default y | ||
|
||
endif # DISPLAY |
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.
note: I think we can safely follow the select MIPI_DSI
pattern here.
* Note- the actual controller present on this IC is a FT3267, | ||
* but the FT35336 driver in Zephyr supports this IC. | ||
*/ | ||
compatible = "focaltech,ft5336"; |
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.
compatible = "focaltech,ft5336"; | |
compatible = "focaltech,ft3267"; |
and adjust driver to support multiple compatibles?
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.
Oh, just noticed a typo in the comment too: "FT35336"
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 input driver here already supports multiple devices (although only the one compatible). Should we instead rename the compatible to focaltech,ftxxxx
? We can keep the focaltech,ft5336
compatible so that downsteam devicetrees aren't affected.
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.
Renaming it is a bit of a nightmare, it'd mess up downstream applications. I think we should avoid that for now since we don't have a well defined format for handling driver with multiple compatibles. I'd say do the def-undef trick (like https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/sensor/tmp108/tmp108.c#L406 but you can use the same init macro), though that does not scale that well. @gmarull how about having two compatibles in it? Unsure what's less worse, wish we had a proper framework for this case were we could add specific compatibles without causing regressions downstream.
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 agree, about the renaming being an issue- I don't want to mess up applications downstream here. Maybe we use the def-undef trick to cover the following compatibles:
- focaltech,ft5336
- focaltech,ft5xx6
- focaltech,ft6xx6
- focaltech,ft3267
I'd prefer to leave the Kconfig itself untouched, as that would also affect downstream applications
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'm also siding for leaving this as is, counting on the ADI folks to come up with something more convenient down the road to handle driver families.
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 definitely can be fixed later, it's not a blocker to me, just noting this needs to be improved/fixed.
drivers/display/Kconfig.rm67162
Outdated
config RM67162 | ||
bool "RM67162 display driver" | ||
default y | ||
depends on MIPI_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.
see above, select
drivers/display/display_rm67162.c
Outdated
gpio_pin_set_dt(&config->reset_gpio, 0); | ||
/* Per datasheet, reset low pulse width should be at least 10usec */ | ||
k_sleep(K_USEC(30)); | ||
gpio_pin_set_dt(&config->reset_gpio, 1); |
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.
missing error handling here
drivers/input/input_ft5336.c
Outdated
/* Delay 5 ms to reset controller */ | ||
k_sleep(K_MSEC(5)); |
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.
where are these 5ms documented?
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've updated the comment based on the datasheet. It appears that the minimum reset time is 1ms, but I would rather keep the longer delay to be safe (as the reset time needs to be extended if the controller is just powering on)
7f7d4c2
d567341
to
7f7d4c2
Compare
Add DSI video mode flag to MIPI configuration, to indicate to MIPI drivers that this display uses video mode and must be refreshed constantly. Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Make DPI mode an optional configuration for the DSI MCUX 2L driver. DPI mode will only be enabled when the MIPI is attached in video mode, since this is when DPI formatted packets are expected. This will enable the DSI driver to also support DBI/command mode, for displays that use this format. Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Fixup support for DCS_LONG_WRITE command in DSI MCUX 2L driver. Since long DCS commands may benefit from nonblocking I/O, add support for non blocking transfers to the DSI driver. This commit also corrects the interrupt number for the RT595, which uses the DSI_MCUX_2L IP block. Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Only setup DPI input from LCDIF if MODE_VIDEO is set, as this is the the only case where input from the LCDIF would be required to drive the display. Do not populate the dpi_config structure unless a reference the the NXP LCDIF device is provided, since this is the output device providing DPI data. Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Fix support for DCS long write command in DSI mcux driver, to enable use with displays that require this command for full support. Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Only set LV_Z_VDB_CUSTOM_SECTION for the RK055HDMIPI4M shield, as it is only required when using displays that require a large framebuffer. Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Add support for RM67162 MIPI display controller. This controller is configured to run in MIPI command/DBI mode, driving a 400x392 OLED display. Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Add support for resetting controller at boot, and update FT5336 documentation to indicate that the FT3267 IC is also supported by this driver. Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Add g1120b0mipi watch display to shields. This shield is currently supported with the RT595 and RT1170 EVK. The shield contains a 400x392 circular OLED watch display, with an integrated RM67162 display controller Note that the touchscreen IC can be driven by the FT5336 driver, with the following changes: - the FT3267 reports touch data as inverted from the FT5336, so LVGL must be made aware of this via CONFIG_LV_Z_POINTER_KSCAN_INVERT_Y - the FT3267 reports the X and Y coordinates as swapped from the FT5336. To resolve this, the RM67162 driver reports the display as rotated by 90 degrees. Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
7f7d4c2
to
33fca87
Compare
@gmarull can you verify that your comments have been addressed? |
This PR introduces the G1120B0MIPI watch display. It includes the following updates:
This display has been verified to function with the RT1170 and RT595 EVKs.
Note that this PR currently depends on #53907 and #55493, and contains commits from both. The commits will be removed as those PRs merge.Signed-off-by: Daniel DeGrasse daniel.degrasse@nxp.com