| Message ID | 1455754647-10378-1-git-send-email-aford173@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Adam Ford <aford173@gmail.com> [160217 16:17]: > At the request of Logic PD, this patch sets the display parameters to > match that of Logic PD's display type 28 since type 15 is discontinued. > > V2: A previous patch attempted to eliminate an warning indicating no > power supply for the LCD. This undoes some of those patches to make > the Type 28 display work correctly. > > V1: First attempt to enable Type 28 display from Logic PD. So what about people with the type 15 displays? Can the display revision be detected over some control channel for the touchscreen or something? If there's no way to detect them, you should at least add comments to the dts file about it only supporting type 28 and what people should do to get type 15 working. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Ideally, I wanted to have both timings available and attempt to select them through kernel parameters. Do you (or anyone) know if it's possible to do that with the panel-dpi driver? I wanted to do something like omapfb.mode=<display> but I couldn't figure it out. The only differences are the timings, the touch screen isn't impacted. adam On Fri, Feb 19, 2016 at 10:52 AM, Tony Lindgren <tony@atomide.com> wrote: > * Adam Ford <aford173@gmail.com> [160217 16:17]: >> At the request of Logic PD, this patch sets the display parameters to >> match that of Logic PD's display type 28 since type 15 is discontinued. >> >> V2: A previous patch attempted to eliminate an warning indicating no >> power supply for the LCD. This undoes some of those patches to make >> the Type 28 display work correctly. >> >> V1: First attempt to enable Type 28 display from Logic PD. > > So what about people with the type 15 displays? Can the display > revision be detected over some control channel for the touchscreen > or something? > > If there's no way to detect them, you should at least add comments > to the dts file about it only supporting type 28 and what people > should do to get type 15 working. > > Regards, > > Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Adam Ford <aford173@gmail.com> [160219 11:37]: > Ideally, I wanted to have both timings available and attempt to select > them through kernel parameters. Do you (or anyone) know if it's > possible to do that with the panel-dpi driver? I wanted to do > something like omapfb.mode=<display> but I couldn't figure it out. Yeah maybe setting some display specific cmdline params would make sense here. Tomi do you have better ideas on selecting a LCD between multiple revisions? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 19/02/16 22:49, Tony Lindgren wrote: > * Adam Ford <aford173@gmail.com> [160219 11:37]: >> Ideally, I wanted to have both timings available and attempt to select >> them through kernel parameters. Do you (or anyone) know if it's >> possible to do that with the panel-dpi driver? I wanted to do >> something like omapfb.mode=<display> but I couldn't figure it out. > > Yeah maybe setting some display specific cmdline params would > make sense here. Tomi do you have better ideas on selecting > a LCD between multiple revisions? I think separate .dtb files are the best option at the moment, and choose the right one in the bootloader. Hopefully DT overlays will provide a better solution in the near future. Tomi
Tony, How about I propose that I move the Panel Timings into the two dtsi files, one for each panel type. Users can include the corresponding dtsi file based on their panel type. In there I can also include instructions on what line to patch since those panels need a small delay inserted into the driver. Does that work for you? adam On Mon, Feb 22, 2016 at 2:09 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: > > > On 19/02/16 22:49, Tony Lindgren wrote: >> * Adam Ford <aford173@gmail.com> [160219 11:37]: >>> Ideally, I wanted to have both timings available and attempt to select >>> them through kernel parameters. Do you (or anyone) know if it's >>> possible to do that with the panel-dpi driver? I wanted to do >>> something like omapfb.mode=<display> but I couldn't figure it out. >> >> Yeah maybe setting some display specific cmdline params would >> make sense here. Tomi do you have better ideas on selecting >> a LCD between multiple revisions? > > I think separate .dtb files are the best option at the moment, and > choose the right one in the bootloader. > > Hopefully DT overlays will provide a better solution in the near future. > > Tomi > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Adam Ford <aford173@gmail.com> [160222 04:26]: > Tony, > > How about I propose that I move the Panel Timings into the two dtsi > files, one for each panel type. Users can include the corresponding > dtsi file based on their panel type. In there I can also include > instructions on what line to patch since those panels need a small > delay inserted into the driver. Does that work for you? Well let's not add code that does not build into the mainline kernel. Also, please don't top-post on the mailing lists.. It breaks the flow of the thread making it hard to reply. > On Mon, Feb 22, 2016 at 2:09 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: > > On 19/02/16 22:49, Tony Lindgren wrote: > >> * Adam Ford <aford173@gmail.com> [160219 11:37]: > >>> Ideally, I wanted to have both timings available and attempt to select > >>> them through kernel parameters. Do you (or anyone) know if it's > >>> possible to do that with the panel-dpi driver? I wanted to do > >>> something like omapfb.mode=<display> but I couldn't figure it out. > >> > >> Yeah maybe setting some display specific cmdline params would > >> make sense here. Tomi do you have better ideas on selecting > >> a LCD between multiple revisions? > > > > I think separate .dtb files are the best option at the moment, and > > choose the right one in the bootloader. That's not going to work for many boards as there are just too many combinations to support. > > Hopefully DT overlays will provide a better solution in the near future. And that's been already years in making. I think the only current real fix for issues like this is to include multiple configurations in the panel code that can then be selected based on the device tree compatible flag or kernel cmdline. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 22/02/16 18:49, Tony Lindgren wrote: >>> I think separate .dtb files are the best option at the moment, and >>> choose the right one in the bootloader. > > That's not going to work for many boards as there are just too many > combinations to support. I think it's fine if there's just one "base" .dts file, so for N panels you'll end up with N .dtbs. The problems start if you have multiple base .dts files for, say, different board and SoC revisions. Then the amount of .dtbs explode. >>> Hopefully DT overlays will provide a better solution in the near future. > > And that's been already years in making. > > I think the only current real fix for issues like this is to include > multiple configurations in the panel code that can then be selected > based on the device tree compatible flag or kernel cmdline. Well, there are a few options other than the DT overlays and dealing with this in the bootloader, and each of those options is hacky. - board specific platform code detects the display, and appends the necessary DT data (or uses platform data, but I'd rather get rid of pdata, not add more). - create board specific drivers that detect the display and use the correct video timings. - abuse the board's .dts, and fill in all the possible panels there, and then at runtime somehow choose which one is used. Well, nothing else comes to my mind. And those above are roughly in my least-bad-to-most-bad order. Tomi
* Tomi Valkeinen <tomi.valkeinen@ti.com> [160222 09:30]: > On 22/02/16 18:49, Tony Lindgren wrote: > > >>> I think separate .dtb files are the best option at the moment, and > >>> choose the right one in the bootloader. > > > > That's not going to work for many boards as there are just too many > > combinations to support. > > I think it's fine if there's just one "base" .dts file, so for N panels > you'll end up with N .dtbs. The problems start if you have multiple base > .dts files for, say, different board and SoC revisions. Then the amount > of .dtbs explode. Yeah in this case of modular development boards you can have multiple CPU modules and multiple display panel options. Adam, just for fun, care to estimate the potential permutations with the torpedo kit for example? > >>> Hopefully DT overlays will provide a better solution in the near future. > > > > And that's been already years in making. > > > > I think the only current real fix for issues like this is to include > > multiple configurations in the panel code that can then be selected > > based on the device tree compatible flag or kernel cmdline. > > Well, there are a few options other than the DT overlays and dealing > with this in the bootloader, and each of those options is hacky. > > - board specific platform code detects the display, and appends the > necessary DT data (or uses platform data, but I'd rather get rid of > pdata, not add more). Yeah if the panel can be detected over I2C or by probing the GPIO pins then this might be doable. Probably no need to mix DT data into runtime detection like this though, it can be done in a board specific device driver that then creates the struct device for the panel detected. > - create board specific drivers that detect the display and use the > correct video timings. Having a custom driver seems better to me than trying stuff the detection code into the arch/arm/. > - abuse the board's .dts, and fill in all the possible panels there, and > then at runtime somehow choose which one is used. Heh yeah something like this could be done in the bootloader :) > Well, nothing else comes to my mind. And those above are roughly in my > least-bad-to-most-bad order. Yeah I'd still prefer a kernel cmdline option until we have a better Linux generic solution merged into the mainline kernel. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 22/02/16 19:45, Tony Lindgren wrote: > * Tomi Valkeinen <tomi.valkeinen@ti.com> [160222 09:30]: >> On 22/02/16 18:49, Tony Lindgren wrote: >> >>>>> I think separate .dtb files are the best option at the moment, and >>>>> choose the right one in the bootloader. >>> >>> That's not going to work for many boards as there are just too many >>> combinations to support. >> >> I think it's fine if there's just one "base" .dts file, so for N panels >> you'll end up with N .dtbs. The problems start if you have multiple base >> .dts files for, say, different board and SoC revisions. Then the amount >> of .dtbs explode. > > Yeah in this case of modular development boards you can have multiple > CPU modules and multiple display panel options. Adam, just for fun, > care to estimate the potential permutations with the torpedo kit for > example? > >>>>> Hopefully DT overlays will provide a better solution in the near future. >>> >>> And that's been already years in making. >>> >>> I think the only current real fix for issues like this is to include >>> multiple configurations in the panel code that can then be selected >>> based on the device tree compatible flag or kernel cmdline. >> >> Well, there are a few options other than the DT overlays and dealing >> with this in the bootloader, and each of those options is hacky. >> >> - board specific platform code detects the display, and appends the >> necessary DT data (or uses platform data, but I'd rather get rid of >> pdata, not add more). > > Yeah if the panel can be detected over I2C or by probing the GPIO > pins then this might be doable. Probably no need to mix DT data We can 'detect' the panel with a kernel cmdline parameter. Or maybe a DT property. I think u-boot supports setting a DT property. > into runtime detection like this though, it can be done in a board > specific device driver that then creates the struct device for the > panel detected. If there's no DT data for the panel then we need platform data. And I've been removing platform data support from the display drivers, as it's a total mess, and it doesn't support anything a bit more complex. >> - create board specific drivers that detect the display and use the >> correct video timings. > > Having a custom driver seems better to me than trying stuff the > detection code into the arch/arm/. The nice part about having the code in arch/arm/mach-omap2/ is that outside that piece of code, the situation would look like as if the u-boot passed proper HW data in the .dts. When the u-boot actually does that, the piece of code could be just removed. In the other options we more or less get stuck with a custom solution which may become a maintenance nightmare. >> - abuse the board's .dts, and fill in all the possible panels there, and >> then at runtime somehow choose which one is used. > > Heh yeah something like this could be done in the bootloader :) I didn't mean the bootloader would do anything here. The .dts file would contain all the panels, described as being all connected to the same SoC video output. The problem with this one is that all the panels would need to be in that .dts, and we'd need to support that in the future, and it's not correct use of DT files. Also, the "somehow choose which one to use" is unclear to me. >> Well, nothing else comes to my mind. And those above are roughly in my >> least-bad-to-most-bad order. > > Yeah I'd still prefer a kernel cmdline option until we have a > better Linux generic solution merged into the mainline kernel. The kernel cmdline only provides part of the solution. Cmdline can be used for the detection part, in any of the different options above. But in addition to that we need information about the panel itself and how it's integrated to the board. Tomi
* Tomi Valkeinen <tomi.valkeinen@ti.com> [160222 10:02]: > On 22/02/16 19:45, Tony Lindgren wrote: > > * Tomi Valkeinen <tomi.valkeinen@ti.com> [160222 09:30]: > >> On 22/02/16 18:49, Tony Lindgren wrote: > >>> I think the only current real fix for issues like this is to include > >>> multiple configurations in the panel code that can then be selected > >>> based on the device tree compatible flag or kernel cmdline. > >> > >> Well, there are a few options other than the DT overlays and dealing > >> with this in the bootloader, and each of those options is hacky. > >> > >> - board specific platform code detects the display, and appends the > >> necessary DT data (or uses platform data, but I'd rather get rid of > >> pdata, not add more). > > > > Yeah if the panel can be detected over I2C or by probing the GPIO > > pins then this might be doable. Probably no need to mix DT data > > We can 'detect' the panel with a kernel cmdline parameter. Or maybe a DT > property. I think u-boot supports setting a DT property. Yeah both sound OK to me. > > into runtime detection like this though, it can be done in a board > > specific device driver that then creates the struct device for the > > panel detected. > > If there's no DT data for the panel then we need platform data. And I've > been removing platform data support from the display drivers, as it's a > total mess, and it doesn't support anything a bit more complex. Yeah DT works well for passing board specific parameters. > >> - create board specific drivers that detect the display and use the > >> correct video timings. > > > > Having a custom driver seems better to me than trying stuff the > > detection code into the arch/arm/. > > The nice part about having the code in arch/arm/mach-omap2/ is that > outside that piece of code, the situation would look like as if the > u-boot passed proper HW data in the .dts. When the u-boot actually does > that, the piece of code could be just removed. If something can be done in pdata-quirks.c to pass a minimal display type in pdata to the panel driver that's fine with me. But let's not try to add any I2C based detection there as that clearly depends on drivers that should be possible to have as loadable modules. > In the other options we more or less get stuck with a custom solution > which may become a maintenance nightmare. > > >> - abuse the board's .dts, and fill in all the possible panels there, and > >> then at runtime somehow choose which one is used. > > > > Heh yeah something like this could be done in the bootloader :) > > I didn't mean the bootloader would do anything here. The .dts file would > contain all the panels, described as being all connected to the same SoC > video output. If there's some generic Linux kernel code to modify the dts that works too, but let's not add any custom hacks to pdata-quirks.c for that. > The problem with this one is that all the panels would need to be in > that .dts, and we'd need to support that in the future, and it's not > correct use of DT files. Also, the "somehow choose which one to use" is > unclear to me. > > >> Well, nothing else comes to my mind. And those above are roughly in my > >> least-bad-to-most-bad order. > > > > Yeah I'd still prefer a kernel cmdline option until we have a > > better Linux generic solution merged into the mainline kernel. > > The kernel cmdline only provides part of the solution. Cmdline can be > used for the detection part, in any of the different options above. But > in addition to that we need information about the panel itself and how > it's integrated to the board. Yes agreed. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 22, 2016 at 11:45 AM, Tony Lindgren <tony@atomide.com> wrote: > * Tomi Valkeinen <tomi.valkeinen@ti.com> [160222 09:30]: >> On 22/02/16 18:49, Tony Lindgren wrote: >> >> >>> I think separate .dtb files are the best option at the moment, and >> >>> choose the right one in the bootloader. >> > >> > That's not going to work for many boards as there are just too many >> > combinations to support. >> >> I think it's fine if there's just one "base" .dts file, so for N panels >> you'll end up with N .dtbs. The problems start if you have multiple base >> .dts files for, say, different board and SoC revisions. Then the amount >> of .dtbs explode. > That is also what I'm trying to avoid. > Yeah in this case of modular development boards you can have multiple > CPU modules and multiple display panel options. Adam, just for fun, > care to estimate the potential permutations with the torpedo kit for > example? There are only 2 panels that Logic PD sold in their development kits. They had other displays, but I believe they are no longer being sold. 800 MHz Torpedo (Device trees TBD) 1000 MHz Torpedo (Device trees TBD) 800 MHz Torpedo + Wireless 1000 MHz Torpedo + Wireless (needs modified device tree) 800MHz DM37xx SOM-LV (Device trees pending review) 1000 MHz DM37xx SOM-LV (Device trees TBD) OMAP3530 Torpedo (Device trees to come soon) OMAP3530 SOM-LV (Device trees to come soon) 8 Devices * 2 Displays = 16 Device Trees (Yuck!) This would cut down a bit if the OMAP3630 /3730 had some way of detecting it's max speed. Thankfully, Logic PD doesn't sell all the displays they used to sell or it would be worse. > Logic PD did some evaluation kits for TI like an L138, AM1808 and an AM3517. Those kits should be compatible with these above mentioned displays, with a minor tweak to the panel-dpi driver. >> >>> Hopefully DT overlays will provide a better solution in the near future. >> > >> > And that's been already years in making. >> > >> > I think the only current real fix for issues like this is to include >> > multiple configurations in the panel code that can then be selected >> > based on the device tree compatible flag or kernel cmdline. >> >> Well, there are a few options other than the DT overlays and dealing >> with this in the bootloader, and each of those options is hacky. >> >> - board specific platform code detects the display, and appends the >> necessary DT data (or uses platform data, but I'd rather get rid of >> pdata, not add more). > > Yeah if the panel can be detected over I2C or by probing the GPIO > pins then this might be doable. Probably no need to mix DT data > into runtime detection like this though, it can be done in a board > specific device driver that then creates the struct device for the > panel detected. > >> - create board specific drivers that detect the display and use the >> correct video timings. > > Having a custom driver seems better to me than trying stuff the > detection code into the arch/arm/. The Logic PD panels are not probe-able. They are simple panel-dpi devices with not other interaction than the DSS lines and a few enable pins. For me it seems like a waste to copy/paste the panel-dpi driver to simply add one delay, but I can certainly look at doing that and integrating the display timings into that driver. Having the added delay I need be an optional device tree entry would reduce the amount of duplicate code. >> - abuse the board's .dts, and fill in all the possible panels there, and >> then at runtime somehow choose which one is used. > > Heh yeah something like this could be done in the bootloader :) > >> Well, nothing else comes to my mind. And those above are roughly in my >> least-bad-to-most-bad order. > > Yeah I'd still prefer a kernel cmdline option until we have a > better Linux generic solution merged into the mainline kernel. In my ideal world, we'd be able to have a device tree with a list of panel timings and a simple command line parameter that selects which one OR a nice way to merge the device trees in U-Boot so I could compile the panel info into a dtb and merge it with the module's DTB. If Tomi would permit me, I'd like to add a single optional delay entry into the panel-dpi device tree which should fix the TI kits made by Logic PD and allow them to work with both the Type 15 and Type 28 displays. > Regards, > > Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Adam Ford <aford173@gmail.com> [160222 11:05]: > On Mon, Feb 22, 2016 at 11:45 AM, Tony Lindgren <tony@atomide.com> wrote: > > * Tomi Valkeinen <tomi.valkeinen@ti.com> [160222 09:30]: > >> On 22/02/16 18:49, Tony Lindgren wrote: > >> > >> >>> I think separate .dtb files are the best option at the moment, and > >> >>> choose the right one in the bootloader. > >> > > >> > That's not going to work for many boards as there are just too many > >> > combinations to support. > >> > >> I think it's fine if there's just one "base" .dts file, so for N panels > >> you'll end up with N .dtbs. The problems start if you have multiple base > >> .dts files for, say, different board and SoC revisions. Then the amount > >> of .dtbs explode. > > > That is also what I'm trying to avoid. > > > Yeah in this case of modular development boards you can have multiple > > CPU modules and multiple display panel options. Adam, just for fun, > > care to estimate the potential permutations with the torpedo kit for > > example? > > There are only 2 panels that Logic PD sold in their development kits. > They had other displays, but I believe they are no longer being sold. > > 800 MHz Torpedo (Device trees TBD) > 1000 MHz Torpedo (Device trees TBD) > 800 MHz Torpedo + Wireless > 1000 MHz Torpedo + Wireless (needs modified device tree) > 800MHz DM37xx SOM-LV (Device trees pending review) > 1000 MHz DM37xx SOM-LV (Device trees TBD) > OMAP3530 Torpedo (Device trees to come soon) > OMAP3530 SOM-LV (Device trees to come soon) > > 8 Devices * 2 Displays = 16 Device Trees (Yuck!) > This would cut down a bit if the OMAP3630 /3730 had some way of > detecting it's max speed. I think that might be available in the SR/OPP code to read from the efuses? > Thankfully, Logic PD doesn't sell all the displays they used to sell > or it would be worse. I think we should just now use your suggested solution with the comments in the dtsi file for the older display panel. Or set up a separate board dts file for the older display. Then when we have a better solution we can switch to using it. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts index 874ce46..4b00b58 100644 --- a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts +++ b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts @@ -128,22 +128,20 @@ }; video_reg: video_reg { - pinctrl-names = "default"; - pinctrl-0 = <&panel_pwr_pins>; compatible = "regulator-fixed"; regulator-name = "fixed-supply"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; - gpio = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd INI */ }; lcd0: display@0 { compatible = "panel-dpi"; - label = "15"; + label = "28"; status = "okay"; /* default-on; */ pinctrl-names = "default"; - + pinctrl-0 = <&lcd_enable_pin>; + enable-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd INI */ port { lcd_in: endpoint { remote-endpoint = <&dpi_out>; @@ -158,12 +156,12 @@ hback-porch = <2>; hsync-len = <42>; vback-porch = <3>; - vfront-porch = <4>; + vfront-porch = <2>; vsync-len = <11>; - hsync-active = <0>; - vsync-active = <0>; + hsync-active = <1>; + vsync-active = <1>; de-active = <1>; - pixelclk-active = <1>; + pixelclk-active = <0>; }; }; @@ -245,7 +243,7 @@ >; }; - panel_pwr_pins: pinmux_panel_pwr_pins { + lcd_enable_pin: pinmux_lcd_enable_pin { pinctrl-single,pins = < OMAP3_CORE1_IOPAD(0x218a, PIN_OUTPUT | PIN_OFF_OUTPUT_LOW | MUX_MODE4) /* mcbsp4_fs.gpio_155 */ >;
At the request of Logic PD, this patch sets the display parameters to match that of Logic PD's display type 28 since type 15 is discontinued. V2: A previous patch attempted to eliminate an warning indicating no power supply for the LCD. This undoes some of those patches to make the Type 28 display work correctly. V1: First attempt to enable Type 28 display from Logic PD. Signed-off-by: Adam Ford <aford173@gmail.com> --- arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-)