Hi Adam, On Mon, Dec 02, 2019 at 07:13:40AM -0600, Adam Ford wrote: > On Mon, Dec 2, 2019 at 6:59 AM Laurent Pinchart wrote: > > > > Hi Adam, > > > > (CC'ing Jyri and Tomi) > > > > I'm sorry for the very late reply, your e-mail got burried in my inbox. > > No worries. I moved on a while ago. ;-) > > > On Wed, Aug 21, 2019 at 09:39:27PM -0500, Adam Ford wrote: > > > On Wed, Aug 21, 2019 at 9:08 PM Laurent Pinchart wrote: > > > > On Wed, Aug 21, 2019 at 08:14:43PM -0500, Adam Ford wrote: > > > > > I know it's been nearly 9 months this this was removed, but for those > > > > > of us who still define our displays in the device tree expecting the > > > > > dpi-panel, we're not getting video. > > > > > > > > > > The commit message only states: > > > > > > > > > > Panels are now supported through the drm_panel infrastructure, remove > > > > > the omapdrm-specific driver. > > > > > > > > > > It does not give examples of how to do this, and I feel like we should > > > > > have been given some warning or indication. Is there an example I can > > > > > follow for linking a dpi panel into the omap DSS? > > > > > > > > Sorry to have left you with non-working systems :-( > > > > > > I have really only been following the omap-linux mailing list and only > > > really focus on the LTS kernels because my employer uses the LTS > > > kernels as the basis for the their linux distributions. If there is a > > > different mailing list I should follow, let me know. I just wish it > > > would have been marked as deprecated or something before just being > > > killed. > > I believe device trees that I support for Logic PD are now in the > MAINTAINER file with references to the omap mailing list, so if they > are modified, I should see them if I don't subscribe to other mailing > lists which modify stuff. > > I think what would have helped is if the 'panel-dpi' reference in the > device trees would have been deleted since there were no longer any > drivers to support. I think I could have caught it earlier. I don't > always have an LCD on the devices I test when I do spot checks. I agree, and I should have submitted support for the corresponding panels to panel-simple.c as part of that process, but I failed to notice the issue :-S > The good news in the process, I was able to work with Tomi and others > to fix an annoying bug in the OMAP3630 which always requried me to > modify the kernel config because the stock omap2plus crashed with my > panel timings on the omap3630. > > > > > If the panel is supported by a mainline DRM panel driver the change > > > > should be transparent (provided of course that the driver is compiled in > > > > the kernel or as a module). Most panels are supported by the > > > > panel-simple driver (CONFIG_DRM_PANEL_SIMPLE), with a few dozen of other > > > > panels supported by dedicated drivers (in drivers/gpu/drm/panel/) > > > > > > > > Could you point me to the DT sources of one (or all) of the affected > > > > systems ? > > > > > > Sure, > > > The same panel is used on these these two boards: > > > logicpd-som-lv-baseboard.dtsi > > > logicpd-torpedo-37xx-devkit-28.dts > > > > > > A second panel is used on: > > > logicpd-torpedo-37xx-devkit.dts which has the LCD timings defined in > > > logicpd-torpedo-baseboard.dtsi > > > The am3517-evm also uses the same timings, but the gpio enables are different. > > > > I see. The omap3-ha-lcd.dts is also affected. There are only two ways to > > fix this as far as I can tell: > > > > - Add a panel driver matching against the panel-dpi compatible string, > > and parsing the panel timings from DT there. Thierry Reding, the DRM > > panel maintainer, has rejected this option multiple times (but it > > seems people are still trying). > > It would be nice to have a generic DT based parser so we don't have to > keep writing C code for something that could be done in DT. I also > recognize that not all platforms use DT, but for those people C makes > sense. > > > - Add the exact panel model to the above DT files (see omap3-thunder.dts > > for an example), and make sure we have a kernel driver for those > > panels (possibly extending the panel-simple driver). It seems that we > > are also missing support in panel drivers for innolux,at070tn83, > > osddisplays,osd057T0559-34ts, samsung,lte430wq-f0c and > > startek,startek-kd050c. > > > > Tomi, which approach do you think is best at this point ? > > I have already submitted patches to add the missing panels to the > simple panel driver for one of the LCD's. Great :-) Thanks for that. > I believe they've been > accepted already. For the other LCD, I found a device already present > in the simple panels driver and I'm using it. So for my omap3 based, > boards, I have a solution already in process. I also submitted a fix > to all the simple panel driver to the omap2plus_defconfig so it is > included in the build. Please note the related discussion in https://patchwork.kernel.org/cover/11243277/. > > > The da850-evm uses the same panel as the am3517-evm, but it's not > > > using the same video driver, and I haven't had a chance to see if that > > > driver still exists or not. > > > > The tilcdc driver is still present in the kernel (I'm not aware of a > > plan to remove it), and uses a similar panel support hack as the omapdrm > > driver. I think it would make sense to fix it at some point, but I have > > no plan to do so myself at the moment. > > If this driver does lose support for the LCD's, it should be trivial > to migrate the da850-evm to the simple panel driver. > > > > Thanks for your quick response. > > > :-) > > > > Looks like I did a way worse job this time. Sorry again. > > I get why you did it. > > > > Sorry if my e-mail came across angrily, it wasn't my intention. > > > > No worries, and in any case you had reasons to be annoyed. -- Regards, Laurent Pinchart
