| Message ID | 20191114093950.4101-3-tomi.valkeinen@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/omap: fix am4 evm lcd | expand |
Hi Tomi, Thank you for the patch. On Thu, Nov 14, 2019 at 11:39:49AM +0200, Tomi Valkeinen wrote: > panel-simple now handled panel osd070t1718-19ts, and we no longer need > the panel timings in the DT file. So remove them. Should you in that case drop the panel-dpi compatible string too, as the panel-dpi bindings require panel timings in DT ? > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> > --- > arch/arm/boot/dts/am437x-gp-evm.dts | 16 ---------------- > arch/arm/boot/dts/am43x-epos-evm.dts | 16 ---------------- > 2 files changed, 32 deletions(-) > > diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts > index 811c8cae315b..040403049cea 100644 > --- a/arch/arm/boot/dts/am437x-gp-evm.dts > +++ b/arch/arm/boot/dts/am437x-gp-evm.dts > @@ -91,22 +91,6 @@ > > backlight = <&lcd_bl>; > > - panel-timing { > - clock-frequency = <33000000>; > - hactive = <800>; > - vactive = <480>; > - hfront-porch = <210>; > - hback-porch = <16>; > - hsync-len = <30>; > - vback-porch = <10>; > - vfront-porch = <22>; > - vsync-len = <13>; > - hsync-active = <0>; > - vsync-active = <0>; > - de-active = <1>; > - pixelclk-active = <1>; > - }; > - > port { > lcd_in: endpoint { > remote-endpoint = <&dpi_out>; > diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts > index 078cb473fa7d..330fce060e8b 100644 > --- a/arch/arm/boot/dts/am43x-epos-evm.dts > +++ b/arch/arm/boot/dts/am43x-epos-evm.dts > @@ -47,22 +47,6 @@ > > backlight = <&lcd_bl>; > > - panel-timing { > - clock-frequency = <33000000>; > - hactive = <800>; > - vactive = <480>; > - hfront-porch = <210>; > - hback-porch = <16>; > - hsync-len = <30>; > - vback-porch = <10>; > - vfront-porch = <22>; > - vsync-len = <13>; > - hsync-active = <0>; > - vsync-active = <0>; > - de-active = <1>; > - pixelclk-active = <1>; > - }; > - > port { > lcd_in: endpoint { > remote-endpoint = <&dpi_out>;
* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [191202 13:05]: > Hi Tomi, > > Thank you for the patch. > > On Thu, Nov 14, 2019 at 11:39:49AM +0200, Tomi Valkeinen wrote: > > panel-simple now handled panel osd070t1718-19ts, and we no longer need > > the panel timings in the DT file. So remove them. > > Should you in that case drop the panel-dpi compatible string too, as the > panel-dpi bindings require panel timings in DT ? Yeah sounds like if panel-dpi is no longer usable for this device it should be dropped from the compatible list. Regards, Tony
On 11/12/2019 18:53, Tony Lindgren wrote: > * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [191202 13:05]: >> Hi Tomi, >> >> Thank you for the patch. >> >> On Thu, Nov 14, 2019 at 11:39:49AM +0200, Tomi Valkeinen wrote: >>> panel-simple now handled panel osd070t1718-19ts, and we no longer need >>> the panel timings in the DT file. So remove them. >> >> Should you in that case drop the panel-dpi compatible string too, as the >> panel-dpi bindings require panel timings in DT ? > > Yeah sounds like if panel-dpi is no longer usable for this device it > should be dropped from the compatible list. Ok, I agree. Looking at the dts files, panel-dpi is used in a bunch of boards. But we even have 3 dts files with panel-dpi, without the detailed panel model in compatible... Fixing those will break the compatibility with old dtbs and new kernel, unless we add timings-from-dt to a panel driver that handles panel-dpi. Tomi
Hi Tomi, On Thu, Dec 12, 2019 at 11:37:51AM +0200, Tomi Valkeinen wrote: > On 11/12/2019 18:53, Tony Lindgren wrote: > > * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [191202 13:05]: > >> Hi Tomi, > >> > >> Thank you for the patch. > >> > >> On Thu, Nov 14, 2019 at 11:39:49AM +0200, Tomi Valkeinen wrote: > >>> panel-simple now handled panel osd070t1718-19ts, and we no longer need > >>> the panel timings in the DT file. So remove them. > >> > >> Should you in that case drop the panel-dpi compatible string too, as the > >> panel-dpi bindings require panel timings in DT ? > > > > Yeah sounds like if panel-dpi is no longer usable for this device it > > should be dropped from the compatible list. > > Ok, I agree. > > Looking at the dts files, panel-dpi is used in a bunch of boards. But > we even have 3 dts files with panel-dpi, without the detailed panel > model in compatible... > > Fixing those will break the compatibility with old dtbs and new > kernel, unless we add timings-from-dt to a panel driver that handles > panel-dpi. I know, and I don't have a perfect answer for this :-( I don't see a third option, it's either breaking DT backward compatibility or adding timings parsing to a panel driver (either a new panel-dpi driver or to panel-simple). What's your preferred option ?
On 12/12/2019 22:35, Laurent Pinchart wrote: > Hi Tomi, > > On Thu, Dec 12, 2019 at 11:37:51AM +0200, Tomi Valkeinen wrote: >> On 11/12/2019 18:53, Tony Lindgren wrote: >>> * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [191202 13:05]: >>>> Hi Tomi, >>>> >>>> Thank you for the patch. >>>> >>>> On Thu, Nov 14, 2019 at 11:39:49AM +0200, Tomi Valkeinen wrote: >>>>> panel-simple now handled panel osd070t1718-19ts, and we no longer need >>>>> the panel timings in the DT file. So remove them. >>>> >>>> Should you in that case drop the panel-dpi compatible string too, as the >>>> panel-dpi bindings require panel timings in DT ? >>> >>> Yeah sounds like if panel-dpi is no longer usable for this device it >>> should be dropped from the compatible list. >> >> Ok, I agree. >> >> Looking at the dts files, panel-dpi is used in a bunch of boards. But >> we even have 3 dts files with panel-dpi, without the detailed panel >> model in compatible... >> >> Fixing those will break the compatibility with old dtbs and new >> kernel, unless we add timings-from-dt to a panel driver that handles >> panel-dpi. > > I know, and I don't have a perfect answer for this :-( I don't see a > third option, it's either breaking DT backward compatibility or adding > timings parsing to a panel driver (either a new panel-dpi driver or to > panel-simple). What's your preferred option ? Hmm, I just realized that changing these will break omapfb. It relies on panel-dpi and timings from DT... Tomi
On 13/01/2020 14:01, Tomi Valkeinen wrote: > On 12/12/2019 22:35, Laurent Pinchart wrote: >> Hi Tomi, >> >> On Thu, Dec 12, 2019 at 11:37:51AM +0200, Tomi Valkeinen wrote: >>> On 11/12/2019 18:53, Tony Lindgren wrote: >>>> * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [191202 13:05]: >>>>> Hi Tomi, >>>>> >>>>> Thank you for the patch. >>>>> >>>>> On Thu, Nov 14, 2019 at 11:39:49AM +0200, Tomi Valkeinen wrote: >>>>>> panel-simple now handled panel osd070t1718-19ts, and we no longer need >>>>>> the panel timings in the DT file. So remove them. >>>>> >>>>> Should you in that case drop the panel-dpi compatible string too, as the >>>>> panel-dpi bindings require panel timings in DT ? >>>> >>>> Yeah sounds like if panel-dpi is no longer usable for this device it >>>> should be dropped from the compatible list. >>> >>> Ok, I agree. >>> >>> Looking at the dts files, panel-dpi is used in a bunch of boards. But >>> we even have 3 dts files with panel-dpi, without the detailed panel >>> model in compatible... >>> >>> Fixing those will break the compatibility with old dtbs and new >>> kernel, unless we add timings-from-dt to a panel driver that handles >>> panel-dpi. >> >> I know, and I don't have a perfect answer for this :-( I don't see a >> third option, it's either breaking DT backward compatibility or adding >> timings parsing to a panel driver (either a new panel-dpi driver or to >> panel-simple). What's your preferred option ? > > Hmm, I just realized that changing these will break omapfb. It relies on panel-dpi and timings from > DT... If no one objects, I think we should just drop the timings from the .dts, and say that these boards are no longer supported with omapfb. I don't think there's much point in trying to keep omapfb working fine for boards that are fully supported by omapdrm. Hopefully soon (in five years? =) we can say that omapdrm supports all the boards, and we can deprecate omapfb. Tomi
Hi Tomi, On Tue, Feb 11, 2020 at 12:01:31PM +0200, Tomi Valkeinen wrote: > On 13/01/2020 14:01, Tomi Valkeinen wrote: > > On 12/12/2019 22:35, Laurent Pinchart wrote: > >> On Thu, Dec 12, 2019 at 11:37:51AM +0200, Tomi Valkeinen wrote: > >>> On 11/12/2019 18:53, Tony Lindgren wrote: > >>>> * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [191202 13:05]: > >>>>> Hi Tomi, > >>>>> > >>>>> Thank you for the patch. > >>>>> > >>>>> On Thu, Nov 14, 2019 at 11:39:49AM +0200, Tomi Valkeinen wrote: > >>>>>> panel-simple now handled panel osd070t1718-19ts, and we no longer need > >>>>>> the panel timings in the DT file. So remove them. > >>>>> > >>>>> Should you in that case drop the panel-dpi compatible string too, as the > >>>>> panel-dpi bindings require panel timings in DT ? > >>>> > >>>> Yeah sounds like if panel-dpi is no longer usable for this device it > >>>> should be dropped from the compatible list. > >>> > >>> Ok, I agree. > >>> > >>> Looking at the dts files, panel-dpi is used in a bunch of boards. But > >>> we even have 3 dts files with panel-dpi, without the detailed panel > >>> model in compatible... > >>> > >>> Fixing those will break the compatibility with old dtbs and new > >>> kernel, unless we add timings-from-dt to a panel driver that handles > >>> panel-dpi. > >> > >> I know, and I don't have a perfect answer for this :-( I don't see a > >> third option, it's either breaking DT backward compatibility or adding > >> timings parsing to a panel driver (either a new panel-dpi driver or to > >> panel-simple). What's your preferred option ? > > > > Hmm, I just realized that changing these will break omapfb. It > > relies on panel-dpi and timings from DT... > > If no one objects, I think we should just drop the timings from the > .dts, and say that these boards are no longer supported with omapfb. I > don't think there's much point in trying to keep omapfb working fine > for boards that are fully supported by omapdrm. No objection from me. > Hopefully soon (in five years? =) we can say that omapdrm supports all > the boards, and we can deprecate omapfb. I'd love to send a patch to remove omapfb, but I'll let you do the honours :-)
On 11/02/2020 13:07, Laurent Pinchart wrote: >> Hopefully soon (in five years? =) we can say that omapdrm supports all >> the boards, and we can deprecate omapfb. > > I'd love to send a patch to remove omapfb, but I'll let you do the > honours :-) Not before we add DSI support to omapdrm... Tomi
On Tue, Feb 11, 2020 at 01:08:12PM +0200, Tomi Valkeinen wrote: > On 11/02/2020 13:07, Laurent Pinchart wrote: > > >> Hopefully soon (in five years? =) we can say that omapdrm supports all > >> the boards, and we can deprecate omapfb. > > > > I'd love to send a patch to remove omapfb, but I'll let you do the > > honours :-) > > Not before we add DSI support to omapdrm... Details, details ;-) Seriously speaking, Sebastian's patches are on my todo list.
Hi, On 11/02/2020 12:08, Tomi Valkeinen wrote: > On 11/02/2020 13:07, Laurent Pinchart wrote: > >>> Hopefully soon (in five years? =) we can say that omapdrm supports all >>> the boards, and we can deprecate omapfb. >> >> I'd love to send a patch to remove omapfb, but I'll let you do the >> honours :-) > > Not before we add DSI support to omapdrm... This is probably known, but for devices that would like use PowerVR SGX, there sometimes is only userspace available that works with omap(l)fb, and not with DRM. The Nokia N900 is such an example. There might be a newer release of (closed) userspace coming for the aging device(s), but as it stands, I don't think it's possible to do 3D with PowerVR SGX on omapdrm currently. But I might be wrong... Cheers, Merlijn
* Merlijn Wajer <merlijn@wizzup.org> [200211 12:54]: > Hi, > > On 11/02/2020 12:08, Tomi Valkeinen wrote: > > On 11/02/2020 13:07, Laurent Pinchart wrote: > > > >>> Hopefully soon (in five years? =) we can say that omapdrm supports all > >>> the boards, and we can deprecate omapfb. > >> > >> I'd love to send a patch to remove omapfb, but I'll let you do the > >> honours :-) > > > > Not before we add DSI support to omapdrm... Hmm do your mean RFBI? The DSI support we already have :) > This is probably known, but for devices that would like use PowerVR SGX, > there sometimes is only userspace available that works with omap(l)fb, > and not with DRM. The Nokia N900 is such an example. > > There might be a newer release of (closed) userspace coming for the > aging device(s), but as it stands, I don't think it's possible to do 3D > with PowerVR SGX on omapdrm currently. > > But I might be wrong... Yes SGX is a bottleneck currently for omap3 users. And I think RFBI is blocking n8x0 from moving to omapdrm and finally leaving drivers/video/fbdev/omap2 behind. With those blockers fixed, I'd also be happy to just get rid of drivers/video/fbdev/omap2 as there should be no reason to keep using it. Regards, Tony
On 11/02/2020 18:05, Tony Lindgren wrote: > * Merlijn Wajer <merlijn@wizzup.org> [200211 12:54]: >> Hi, >> >> On 11/02/2020 12:08, Tomi Valkeinen wrote: >>> On 11/02/2020 13:07, Laurent Pinchart wrote: >>> >>>>> Hopefully soon (in five years? =) we can say that omapdrm supports all >>>>> the boards, and we can deprecate omapfb. >>>> >>>> I'd love to send a patch to remove omapfb, but I'll let you do the >>>> honours :-) >>> >>> Not before we add DSI support to omapdrm... > > Hmm do your mean RFBI? The DSI support we already have :) Oh, I didn't even remember RFBI... But it is not supported in omapfb either, so it's not blocking removal of omapfb. We are still missing DSI command mode support, and moving it to the common DRM model. >> This is probably known, but for devices that would like use PowerVR SGX, >> there sometimes is only userspace available that works with omap(l)fb, >> and not with DRM. The Nokia N900 is such an example. >> >> There might be a newer release of (closed) userspace coming for the >> aging device(s), but as it stands, I don't think it's possible to do 3D >> with PowerVR SGX on omapdrm currently. >> >> But I might be wrong... > > Yes SGX is a bottleneck currently for omap3 users. And I think > RFBI is blocking n8x0 from moving to omapdrm and finally leaving > drivers/video/fbdev/omap2 behind. > > With those blockers fixed, I'd also be happy to just get rid of > drivers/video/fbdev/omap2 as there should be no reason to > keep using it. I don't know what to do about SGX, but if someone sends patches to omapdrm to allow using SGX, I'll review =). Tomi
* Tomi Valkeinen <tomi.valkeinen@ti.com> [200211 16:14]: > On 11/02/2020 18:05, Tony Lindgren wrote: > > * Merlijn Wajer <merlijn@wizzup.org> [200211 12:54]: > > > Hi, > > > > > > On 11/02/2020 12:08, Tomi Valkeinen wrote: > > > > On 11/02/2020 13:07, Laurent Pinchart wrote: > > > > > > > > > > Hopefully soon (in five years? =) we can say that omapdrm supports all > > > > > > the boards, and we can deprecate omapfb. > > > > > > > > > > I'd love to send a patch to remove omapfb, but I'll let you do the > > > > > honours :-) > > > > > > > > Not before we add DSI support to omapdrm... > > > > Hmm do your mean RFBI? The DSI support we already have :) > > Oh, I didn't even remember RFBI... But it is not supported in omapfb either, > so it's not blocking removal of omapfb. Oh OK. > We are still missing DSI command mode support, and moving it to the common DRM model. Nope, DSI command mode support has been working just fine for a while now :) And Sebastian has a WIP git tree of the common DRM model changes for it. I don't think we have devices with DSI command mode working for omapfb but not for omapdrm? What got missed for v5.6-rc1 is the LCD backlight patch though, I think the only issue there is default-brightness vs more common default-brightness-value usage if you have any input to that. > > > This is probably known, but for devices that would like use PowerVR SGX, > > > there sometimes is only userspace available that works with omap(l)fb, > > > and not with DRM. The Nokia N900 is such an example. > > > > > > There might be a newer release of (closed) userspace coming for the > > > aging device(s), but as it stands, I don't think it's possible to do 3D > > > with PowerVR SGX on omapdrm currently. > > > > > > But I might be wrong... > > > > Yes SGX is a bottleneck currently for omap3 users. And I think > > RFBI is blocking n8x0 from moving to omapdrm and finally leaving > > drivers/video/fbdev/omap2 behind. > > > > With those blockers fixed, I'd also be happy to just get rid of > > drivers/video/fbdev/omap2 as there should be no reason to > > keep using it. > > I don't know what to do about SGX, but if someone sends patches to omapdrm > to allow using SGX, I'll review =). OK so then the only blocker seems to be the lack of SGX blobs for omap3 devices which seems to be in process of getting fixed. Regards, Tony
On 11/02/2020 18:27, Tony Lindgren wrote: >> We are still missing DSI command mode support, and moving it to the common DRM model. > > Nope, DSI command mode support has been working just fine for > a while now :) And Sebastian has a WIP git tree of the common DRM Indeed... It had been going on for so long that now my mind is stuck at dsi-command-mode-not-yet-in =). > model changes for it. I don't think we have devices with DSI > command mode working for omapfb but not for omapdrm? Yes, I think that is true. > What got missed for v5.6-rc1 is the LCD backlight patch though, > I think the only issue there is default-brightness vs more common > default-brightness-value usage if you have any input to that. At least for some boards a power supply is needed, and I think there was no conclusion on who should enable that. It didn't seem to fit in anywhere... But need to check on the latest status. I wasn't following that work closely, as JJ was working on it. Tomi
Hi, On Tue, Feb 11, 2020 at 07:22:14PM +0200, Tomi Valkeinen wrote: > On 11/02/2020 18:27, Tony Lindgren wrote: > > > We are still missing DSI command mode support, and moving it > > > to the common DRM model. > > > > Nope, DSI command mode support has been working just fine for > > a while now :) And Sebastian has a WIP git tree of the common DRM > > Indeed... It had been going on for so long that now my mind is > stuck at dsi-command-mode-not-yet-in =). Welcome in the future :) > > model changes for it. I don't think we have devices with DSI > > command mode working for omapfb but not for omapdrm? > > Yes, I think that is true. Note, that OMAP3 quirk is missing (IDK if its supported in omapfb, haven't used it for ages). I planned to have a look at OMAP3 once the patchset moving omapdrm DSI to common DRM is merged, which needs a non-trivial rebase. > > What got missed for v5.6-rc1 is the LCD backlight patch though, > > I think the only issue there is default-brightness vs more common > > default-brightness-value usage if you have any input to that. > > At least for some boards a power supply is needed, and I think > there was no conclusion on who should enable that. It didn't seem > to fit in anywhere... > > But need to check on the latest status. I wasn't following that > work closely, as JJ was working on it. FWIW omapdrm's DSI driver is ready for that and omapfb is not :P -- Sebastian
Hi, On Tue, Feb 11, 2020 at 01:10:07PM +0200, Laurent Pinchart wrote: > On Tue, Feb 11, 2020 at 01:08:12PM +0200, Tomi Valkeinen wrote: > > On 11/02/2020 13:07, Laurent Pinchart wrote: > > > > >> Hopefully soon (in five years? =) we can say that omapdrm supports all > > >> the boards, and we can deprecate omapfb. > > > > > > I'd love to send a patch to remove omapfb, but I'll let you do the > > > honours :-) > > > > Not before we add DSI support to omapdrm... > > Details, details ;-) > > Seriously speaking, Sebastian's patches are on my todo list. The patches need to be rebased. My hack for supporting panel un/rebind stole connector and drm_dev pointer from drm_panel, which is no longer possible. I hoped this could be cleaned up once your and my omapdrm patches landed... I do have a compile-tested-only WIP branch here, but I doubt I got this working on the first try: https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-n900.git/log/?h=omapdrm-dsi-drm-panel-5.6-rc1-wip -- Sebastian
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts index 811c8cae315b..040403049cea 100644 --- a/arch/arm/boot/dts/am437x-gp-evm.dts +++ b/arch/arm/boot/dts/am437x-gp-evm.dts @@ -91,22 +91,6 @@ backlight = <&lcd_bl>; - panel-timing { - clock-frequency = <33000000>; - hactive = <800>; - vactive = <480>; - hfront-porch = <210>; - hback-porch = <16>; - hsync-len = <30>; - vback-porch = <10>; - vfront-porch = <22>; - vsync-len = <13>; - hsync-active = <0>; - vsync-active = <0>; - de-active = <1>; - pixelclk-active = <1>; - }; - port { lcd_in: endpoint { remote-endpoint = <&dpi_out>; diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts index 078cb473fa7d..330fce060e8b 100644 --- a/arch/arm/boot/dts/am43x-epos-evm.dts +++ b/arch/arm/boot/dts/am43x-epos-evm.dts @@ -47,22 +47,6 @@ backlight = <&lcd_bl>; - panel-timing { - clock-frequency = <33000000>; - hactive = <800>; - vactive = <480>; - hfront-porch = <210>; - hback-porch = <16>; - hsync-len = <30>; - vback-porch = <10>; - vfront-porch = <22>; - vsync-len = <13>; - hsync-active = <0>; - vsync-active = <0>; - de-active = <1>; - pixelclk-active = <1>; - }; - port { lcd_in: endpoint { remote-endpoint = <&dpi_out>;
panel-simple now handled panel osd070t1718-19ts, and we no longer need the panel timings in the DT file. So remove them. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> --- arch/arm/boot/dts/am437x-gp-evm.dts | 16 ---------------- arch/arm/boot/dts/am43x-epos-evm.dts | 16 ---------------- 2 files changed, 32 deletions(-)