Skip to content
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

Merged

Conversation

danieldegrasse
Copy link
Collaborator

@danieldegrasse danieldegrasse commented May 5, 2023

This PR introduces the G1120B0MIPI watch display. It includes the following updates:

  • display driver for RM67162 display controller on the G1120B0 display
  • updates to the FT5336 input driver to handle the reset GPIO present on some focaltech chips, and to clarify the driver supports the FT3267 IC
  • updates to both MCUX DSI drivers to fix incorrect handling of DCS_LONG_WRITE commands, as well as to respect the MODE_VIDEO flag, which indicates a display uses constant refreshing.

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

drivers/mipi_dsi/dsi_mcux_2l.c Show resolved Hide resolved
dts/arm/nxp/nxp_rt5xx_common.dtsi Show resolved Hide resolved
drivers/display/display_rm67162.c Show resolved Hide resolved
drivers/display/display_rm67162.c Outdated Show resolved Hide resolved
drivers/display/display_rm67162.c Outdated Show resolved Hide resolved
drivers/display/display_rm67162.c Outdated Show resolved Hide resolved
boards/shields/g1120b0mipi/g1120b0mipi.overlay Outdated Show resolved Hide resolved
boards/shields/g1120b0mipi/g1120b0mipi.overlay Outdated Show resolved Hide resolved
@danieldegrasse danieldegrasse force-pushed the feature/rm67162_display branch 2 times, most recently from a93a930 to 9fb0296 Compare July 17, 2023 15:39
#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), \
Copy link
Member

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

Copy link
Collaborator Author

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

Copy link
Member

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 :-)

Copy link
Collaborator Author

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

@danieldegrasse danieldegrasse force-pushed the feature/rm67162_display branch 2 times, most recently from 4c27347 to d567341 Compare July 18, 2023 18:22
fabiobaltieri
fabiobaltieri previously approved these changes Jul 18, 2023
jfischer-no
jfischer-no previously approved these changes Jul 19, 2023
Copy link
Member

@gmarull gmarull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some minor nitpicks

Comment on lines 6 to 13
if DISPLAY

# Enable MIPI DSI, as this display controller requires it.

config MIPI_DSI
default y

endif # DISPLAY
Copy link
Member

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";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
compatible = "focaltech,ft5336";
compatible = "focaltech,ft3267";

and adjust driver to support multiple compatibles?

Copy link
Member

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"

Copy link
Collaborator Author

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.

Copy link
Member

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.

Copy link
Collaborator Author

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

Copy link
Member

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.

Copy link
Member

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.

config RM67162
bool "RM67162 display driver"
default y
depends on MIPI_DSI
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see above, select

Comment on lines 246 to 253
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);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing error handling here

Comment on lines 162 to 167
/* Delay 5 ms to reset controller */
k_sleep(K_MSEC(5));
Copy link
Member

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?

Copy link
Collaborator Author

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)

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>
@danieldegrasse
Copy link
Collaborator Author

@gmarull can you verify that your comments have been addressed?

@carlescufi carlescufi merged commit f907f95 into zephyrproject-rtos:main Jul 25, 2023
18 checks passed
@danieldegrasse danieldegrasse deleted the feature/rm67162_display branch July 28, 2023 21:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Devicetree Binding PR modifies or adds a Device Tree binding area: Display area: Input Input Subsystem and Drivers area: Shields Shields (add-on boards) platform: NXP NXP
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants