| Message ID | 20230925150010.1.Iff672233861bcc4cf25a7ad0a81308adc3bda8a4@changeid (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/panel: Move AUX B116XW03 out of panel-edp back to panel-simple | expand |
Il 26/09/23 00:00, Douglas Anderson ha scritto: > In commit 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of > panel-simple") I moved a pile of panels out of panel-simple driver > into the newly created panel-edp driver. One of those panels, however, > shouldn't have been moved. > > As is clear from commit e35e305eff0f ("drm/panel: simple: Add AUO > B116XW03 panel support"), AUX B116XW03 is an LVDS panel. It's used in > exynos5250-snow and exynos5420-peach-pit where it's clear that the > panel is hooked up with LVDS. Furthermore, searching for datasheets I > found one that makes it clear that this panel is LVDS. > > As far as I can tell, I got confused because in commit 88d3457ceb82 > ("drm/panel: auo,b116xw03: fix flash backlight when power on") Jitao > Shi added "DRM_MODE_CONNECTOR_eDP". That seems wrong. Looking at the > downstream ChromeOS trees, it seems like some Mediatek boards are > using a panel that they call "auo,b116xw03" that's an eDP panel. The > best I can guess is that they actually have a different panel that has > similar timing. If so then the proper panel should be used or they > should switch to the generic "edp-panel" compatible. > > When moving this back to panel-edp, I wasn't sure what to use for > .bus_flags and .bus_format and whether to add the extra "enable" delay > from commit 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash > backlight when power on"). I've added formats/flags/delays based on my > (inexpert) analysis of the datasheet. These are untested. > > NOTE: if/when this is backported to stable, we might run into some > trouble. Specifically, before 474c162878ba ("arm64: dts: mt8183: > jacuzzi: Move panel under aux-bus") this panel was used by > "mt8183-kukui-jacuzzi", which assumed it was an eDP panel. I don't > know what to suggest for that other than someone making up a bogus > panel for jacuzzi that's just for the stable channel. > > Fixes: 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power on") > Fixes: 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of panel-simple") > Signed-off-by: Douglas Anderson <dianders@chromium.org> > --- > I haven't had a snow or peach-pit hooked up for debugging / testing > for years. I presume that they must be broken and hope that this fixes > them. We could avoid backport breakages by avoiding to backport this to any kernel that doesn't contain commit 474c162878ba ("arm64: dts: mt8183: jacuzzi: Move panel under aux-bus")... because creating a dummy panel to get two wrongs right is definitely not ok. Cheers, Angelo > > drivers/gpu/drm/panel/panel-edp.c | 29 ----------------------- > drivers/gpu/drm/panel/panel-simple.c | 35 ++++++++++++++++++++++++++++ > 2 files changed, 35 insertions(+), 29 deletions(-) > > diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c > index feb665df35a1..95c8472d878a 100644 > --- a/drivers/gpu/drm/panel/panel-edp.c > +++ b/drivers/gpu/drm/panel/panel-edp.c > @@ -976,32 +976,6 @@ static const struct panel_desc auo_b116xak01 = { > }, > }; > > -static const struct drm_display_mode auo_b116xw03_mode = { > - .clock = 70589, > - .hdisplay = 1366, > - .hsync_start = 1366 + 40, > - .hsync_end = 1366 + 40 + 40, > - .htotal = 1366 + 40 + 40 + 32, > - .vdisplay = 768, > - .vsync_start = 768 + 10, > - .vsync_end = 768 + 10 + 12, > - .vtotal = 768 + 10 + 12 + 6, > - .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC, > -}; > - > -static const struct panel_desc auo_b116xw03 = { > - .modes = &auo_b116xw03_mode, > - .num_modes = 1, > - .bpc = 6, > - .size = { > - .width = 256, > - .height = 144, > - }, > - .delay = { > - .enable = 400, > - }, > -}; > - > static const struct drm_display_mode auo_b133han05_mode = { > .clock = 142600, > .hdisplay = 1920, > @@ -1725,9 +1699,6 @@ static const struct of_device_id platform_of_match[] = { > }, { > .compatible = "auo,b116xa01", > .data = &auo_b116xak01, > - }, { > - .compatible = "auo,b116xw03", > - .data = &auo_b116xw03, > }, { > .compatible = "auo,b133han05", > .data = &auo_b133han05, > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c > index bb89e6d047bc..439d26928938 100644 > --- a/drivers/gpu/drm/panel/panel-simple.c > +++ b/drivers/gpu/drm/panel/panel-simple.c > @@ -919,6 +919,38 @@ static const struct panel_desc auo_b101xtn01 = { > }, > }; > > +static const struct drm_display_mode auo_b116xw03_mode = { > + .clock = 70589, > + .hdisplay = 1366, > + .hsync_start = 1366 + 40, > + .hsync_end = 1366 + 40 + 40, > + .htotal = 1366 + 40 + 40 + 32, > + .vdisplay = 768, > + .vsync_start = 768 + 10, > + .vsync_end = 768 + 10 + 12, > + .vtotal = 768 + 10 + 12 + 6, > + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC, > +}; > + > +static const struct panel_desc auo_b116xw03 = { > + .modes = &auo_b116xw03_mode, > + .num_modes = 1, > + .bpc = 6, > + .size = { > + .width = 256, > + .height = 144, > + }, > + .delay = { > + .prepare = 1, > + .enable = 200, > + .disable = 200, > + .unprepare = 500, > + }, > + .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG, > + .bus_flags = DRM_BUS_FLAG_DE_HIGH, > + .connector_type = DRM_MODE_CONNECTOR_LVDS, > +}; > + > static const struct display_timing auo_g070vvn01_timings = { > .pixelclock = { 33300000, 34209000, 45000000 }, > .hactive = { 800, 800, 800 }, > @@ -4128,6 +4160,9 @@ static const struct of_device_id platform_of_match[] = { > }, { > .compatible = "auo,b101xtn01", > .data = &auo_b101xtn01, > + }, { > + .compatible = "auo,b116xw03", > + .data = &auo_b116xw03, > }, { > .compatible = "auo,g070vvn01", > .data = &auo_g070vvn01,
Hi, On Tue, Sep 26, 2023 at 1:06 AM AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> wrote: > > Il 26/09/23 00:00, Douglas Anderson ha scritto: > > In commit 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of > > panel-simple") I moved a pile of panels out of panel-simple driver > > into the newly created panel-edp driver. One of those panels, however, > > shouldn't have been moved. > > > > As is clear from commit e35e305eff0f ("drm/panel: simple: Add AUO > > B116XW03 panel support"), AUX B116XW03 is an LVDS panel. It's used in > > exynos5250-snow and exynos5420-peach-pit where it's clear that the > > panel is hooked up with LVDS. Furthermore, searching for datasheets I > > found one that makes it clear that this panel is LVDS. > > > > As far as I can tell, I got confused because in commit 88d3457ceb82 > > ("drm/panel: auo,b116xw03: fix flash backlight when power on") Jitao > > Shi added "DRM_MODE_CONNECTOR_eDP". That seems wrong. Looking at the > > downstream ChromeOS trees, it seems like some Mediatek boards are > > using a panel that they call "auo,b116xw03" that's an eDP panel. The > > best I can guess is that they actually have a different panel that has > > similar timing. If so then the proper panel should be used or they > > should switch to the generic "edp-panel" compatible. > > > > When moving this back to panel-edp, I wasn't sure what to use for > > .bus_flags and .bus_format and whether to add the extra "enable" delay > > from commit 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash > > backlight when power on"). I've added formats/flags/delays based on my > > (inexpert) analysis of the datasheet. These are untested. > > > > NOTE: if/when this is backported to stable, we might run into some > > trouble. Specifically, before 474c162878ba ("arm64: dts: mt8183: > > jacuzzi: Move panel under aux-bus") this panel was used by > > "mt8183-kukui-jacuzzi", which assumed it was an eDP panel. I don't > > know what to suggest for that other than someone making up a bogus > > panel for jacuzzi that's just for the stable channel. > > > > Fixes: 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power on") > > Fixes: 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of panel-simple") > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > > --- > > I haven't had a snow or peach-pit hooked up for debugging / testing > > for years. I presume that they must be broken and hope that this fixes > > them. > > We could avoid backport breakages by avoiding to backport this to any kernel > that doesn't contain commit 474c162878ba ("arm64: dts: mt8183: jacuzzi: Move > panel under aux-bus")... because creating a dummy panel to get two wrongs > right is definitely not ok. Sure, except that leaves us with ... a breakage. :-P Although I haven't tested it, I have a hard time believing that exynos5250-snow and exynos5420-peach-pit will work properly with the panel defined as an eDP panel. That means that they will be broken. If someone cared to get those fixed in a stable backport then we'd be stuck deciding who to break. If you have any brilliant ideas then I'm all ears. ...then again, I presume this has been broken since commit 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power on"). That was a little over 3 years ago. Maybe I'm wrong and somehow things still limp along and sorta work even though the panel is defined incorrectly? -Doug
Hi, On Tue, Sep 26, 2023 at 7:01 AM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Tue, Sep 26, 2023 at 1:06 AM AngeloGioacchino Del Regno > <angelogioacchino.delregno@collabora.com> wrote: > > > > Il 26/09/23 00:00, Douglas Anderson ha scritto: > > > In commit 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of > > > panel-simple") I moved a pile of panels out of panel-simple driver > > > into the newly created panel-edp driver. One of those panels, however, > > > shouldn't have been moved. > > > > > > As is clear from commit e35e305eff0f ("drm/panel: simple: Add AUO > > > B116XW03 panel support"), AUX B116XW03 is an LVDS panel. It's used in > > > exynos5250-snow and exynos5420-peach-pit where it's clear that the > > > panel is hooked up with LVDS. Furthermore, searching for datasheets I > > > found one that makes it clear that this panel is LVDS. > > > > > > As far as I can tell, I got confused because in commit 88d3457ceb82 > > > ("drm/panel: auo,b116xw03: fix flash backlight when power on") Jitao > > > Shi added "DRM_MODE_CONNECTOR_eDP". That seems wrong. Looking at the > > > downstream ChromeOS trees, it seems like some Mediatek boards are > > > using a panel that they call "auo,b116xw03" that's an eDP panel. The > > > best I can guess is that they actually have a different panel that has > > > similar timing. If so then the proper panel should be used or they > > > should switch to the generic "edp-panel" compatible. > > > > > > When moving this back to panel-edp, I wasn't sure what to use for > > > .bus_flags and .bus_format and whether to add the extra "enable" delay > > > from commit 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash > > > backlight when power on"). I've added formats/flags/delays based on my > > > (inexpert) analysis of the datasheet. These are untested. > > > > > > NOTE: if/when this is backported to stable, we might run into some > > > trouble. Specifically, before 474c162878ba ("arm64: dts: mt8183: > > > jacuzzi: Move panel under aux-bus") this panel was used by > > > "mt8183-kukui-jacuzzi", which assumed it was an eDP panel. I don't > > > know what to suggest for that other than someone making up a bogus > > > panel for jacuzzi that's just for the stable channel. > > > > > > Fixes: 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power on") > > > Fixes: 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of panel-simple") > > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > > > --- > > > I haven't had a snow or peach-pit hooked up for debugging / testing > > > for years. I presume that they must be broken and hope that this fixes > > > them. > > > > We could avoid backport breakages by avoiding to backport this to any kernel > > that doesn't contain commit 474c162878ba ("arm64: dts: mt8183: jacuzzi: Move > > panel under aux-bus")... because creating a dummy panel to get two wrongs > > right is definitely not ok. > > Sure, except that leaves us with ... a breakage. :-P > > Although I haven't tested it, I have a hard time believing that > exynos5250-snow and exynos5420-peach-pit will work properly with the > panel defined as an eDP panel. That means that they will be broken. If > someone cared to get those fixed in a stable backport then we'd be > stuck deciding who to break. If you have any brilliant ideas then I'm > all ears. > > ...then again, I presume this has been broken since commit > 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power > on"). That was a little over 3 years ago. Maybe I'm wrong and somehow > things still limp along and sorta work even though the panel is > defined incorrectly? I dug out a exynos5250-snow out of my pile and booted postmarket OS on it, which was shockingly easy/pleasant (kudos to those involved!). I found that it was booting a kernel based on 6.1.24. Digging into sysfs, I found that indeed it appeared to be using the "panel-edp" driver, so I guess it is limping along with the wrong driver and wrong flags... It wasn't totally clear for me how to build a new kernel and deploy it for postmarket OS, so I wasn't able to confirm this change. I've CCed the person listed on the postmarket OS wiki though to see if they have any insight. In any case, it sounds as if things are working well enough on older OSes, so maybe we can just skip trying to do any stable backport on this. It still seems like we should land it, though, since the current state of the world seems pretty broken. Anyone willing to give a Reviewed-by or Acked-by tag? -Doug
On Thu, Oct 5, 2023 at 11:11 AM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Tue, Sep 26, 2023 at 7:01 AM Doug Anderson <dianders@chromium.org> wrote: > > > > Hi, > > > > On Tue, Sep 26, 2023 at 1:06 AM AngeloGioacchino Del Regno > > <angelogioacchino.delregno@collabora.com> wrote: > > > > > > Il 26/09/23 00:00, Douglas Anderson ha scritto: > > > > In commit 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of > > > > panel-simple") I moved a pile of panels out of panel-simple driver > > > > into the newly created panel-edp driver. One of those panels, however, > > > > shouldn't have been moved. > > > > > > > > As is clear from commit e35e305eff0f ("drm/panel: simple: Add AUO > > > > B116XW03 panel support"), AUX B116XW03 is an LVDS panel. It's used in > > > > exynos5250-snow and exynos5420-peach-pit where it's clear that the > > > > panel is hooked up with LVDS. Furthermore, searching for datasheets I > > > > found one that makes it clear that this panel is LVDS. > > > > > > > > As far as I can tell, I got confused because in commit 88d3457ceb82 > > > > ("drm/panel: auo,b116xw03: fix flash backlight when power on") Jitao > > > > Shi added "DRM_MODE_CONNECTOR_eDP". That seems wrong. Looking at the > > > > downstream ChromeOS trees, it seems like some Mediatek boards are > > > > using a panel that they call "auo,b116xw03" that's an eDP panel. The > > > > best I can guess is that they actually have a different panel that has > > > > similar timing. If so then the proper panel should be used or they > > > > should switch to the generic "edp-panel" compatible. > > > > > > > > When moving this back to panel-edp, I wasn't sure what to use for > > > > .bus_flags and .bus_format and whether to add the extra "enable" delay > > > > from commit 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash > > > > backlight when power on"). I've added formats/flags/delays based on my > > > > (inexpert) analysis of the datasheet. These are untested. > > > > > > > > NOTE: if/when this is backported to stable, we might run into some > > > > trouble. Specifically, before 474c162878ba ("arm64: dts: mt8183: > > > > jacuzzi: Move panel under aux-bus") this panel was used by > > > > "mt8183-kukui-jacuzzi", which assumed it was an eDP panel. I don't > > > > know what to suggest for that other than someone making up a bogus > > > > panel for jacuzzi that's just for the stable channel. > > > > > > > > Fixes: 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power on") > > > > Fixes: 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of panel-simple") > > > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > > > > --- > > > > I haven't had a snow or peach-pit hooked up for debugging / testing > > > > for years. I presume that they must be broken and hope that this fixes > > > > them. > > > > > > We could avoid backport breakages by avoiding to backport this to any kernel > > > that doesn't contain commit 474c162878ba ("arm64: dts: mt8183: jacuzzi: Move > > > panel under aux-bus")... because creating a dummy panel to get two wrongs > > > right is definitely not ok. > > > > Sure, except that leaves us with ... a breakage. :-P > > > > Although I haven't tested it, I have a hard time believing that > > exynos5250-snow and exynos5420-peach-pit will work properly with the > > panel defined as an eDP panel. That means that they will be broken. If > > someone cared to get those fixed in a stable backport then we'd be > > stuck deciding who to break. If you have any brilliant ideas then I'm > > all ears. > > > > ...then again, I presume this has been broken since commit > > 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power > > on"). That was a little over 3 years ago. Maybe I'm wrong and somehow > > things still limp along and sorta work even though the panel is > > defined incorrectly? > > I dug out a exynos5250-snow out of my pile and booted postmarket OS on > it, which was shockingly easy/pleasant (kudos to those involved!). I > found that it was booting a kernel based on 6.1.24. Digging into > sysfs, I found that indeed it appeared to be using the "panel-edp" > driver, so I guess it is limping along with the wrong driver and wrong > flags... > > It wasn't totally clear for me how to build a new kernel and deploy it > for postmarket OS, so I wasn't able to confirm this change. I've CCed > the person listed on the postmarket OS wiki though to see if they have > any insight. > > In any case, it sounds as if things are working well enough on older > OSes, so maybe we can just skip trying to do any stable backport on > this. It still seems like we should land it, though, since the current > state of the world seems pretty broken. Anyone willing to give a > Reviewed-by or Acked-by tag? > Acked-by: Hsin-Yi Wang <hsinyi@chromium.org> > -Doug
On 10/5/23 21:10, Doug Anderson wrote: > Hi, > > On Tue, Sep 26, 2023 at 7:01 AM Doug Anderson <dianders@chromium.org> wrote: >> Hi, >> >> On Tue, Sep 26, 2023 at 1:06 AM AngeloGioacchino Del Regno >> <angelogioacchino.delregno@collabora.com> wrote: >>> Il 26/09/23 00:00, Douglas Anderson ha scritto: >>>> In commit 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of >>>> panel-simple") I moved a pile of panels out of panel-simple driver >>>> into the newly created panel-edp driver. One of those panels, however, >>>> shouldn't have been moved. >>>> >>>> As is clear from commit e35e305eff0f ("drm/panel: simple: Add AUO >>>> B116XW03 panel support"), AUX B116XW03 is an LVDS panel. It's used in >>>> exynos5250-snow and exynos5420-peach-pit where it's clear that the >>>> panel is hooked up with LVDS. Furthermore, searching for datasheets I >>>> found one that makes it clear that this panel is LVDS. >>>> >>>> As far as I can tell, I got confused because in commit 88d3457ceb82 >>>> ("drm/panel: auo,b116xw03: fix flash backlight when power on") Jitao >>>> Shi added "DRM_MODE_CONNECTOR_eDP". That seems wrong. Looking at the >>>> downstream ChromeOS trees, it seems like some Mediatek boards are >>>> using a panel that they call "auo,b116xw03" that's an eDP panel. The >>>> best I can guess is that they actually have a different panel that has >>>> similar timing. If so then the proper panel should be used or they >>>> should switch to the generic "edp-panel" compatible. >>>> >>>> When moving this back to panel-edp, I wasn't sure what to use for >>>> .bus_flags and .bus_format and whether to add the extra "enable" delay >>>> from commit 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash >>>> backlight when power on"). I've added formats/flags/delays based on my >>>> (inexpert) analysis of the datasheet. These are untested. >>>> >>>> NOTE: if/when this is backported to stable, we might run into some >>>> trouble. Specifically, before 474c162878ba ("arm64: dts: mt8183: >>>> jacuzzi: Move panel under aux-bus") this panel was used by >>>> "mt8183-kukui-jacuzzi", which assumed it was an eDP panel. I don't >>>> know what to suggest for that other than someone making up a bogus >>>> panel for jacuzzi that's just for the stable channel. >>>> >>>> Fixes: 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power on") >>>> Fixes: 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of panel-simple") >>>> Signed-off-by: Douglas Anderson <dianders@chromium.org> >>>> --- >>>> I haven't had a snow or peach-pit hooked up for debugging / testing >>>> for years. I presume that they must be broken and hope that this fixes >>>> them. >>> We could avoid backport breakages by avoiding to backport this to any kernel >>> that doesn't contain commit 474c162878ba ("arm64: dts: mt8183: jacuzzi: Move >>> panel under aux-bus")... because creating a dummy panel to get two wrongs >>> right is definitely not ok. >> Sure, except that leaves us with ... a breakage. :-P >> >> Although I haven't tested it, I have a hard time believing that >> exynos5250-snow and exynos5420-peach-pit will work properly with the >> panel defined as an eDP panel. That means that they will be broken. If >> someone cared to get those fixed in a stable backport then we'd be >> stuck deciding who to break. If you have any brilliant ideas then I'm >> all ears. >> >> ...then again, I presume this has been broken since commit >> 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power >> on"). That was a little over 3 years ago. Maybe I'm wrong and somehow >> things still limp along and sorta work even though the panel is >> defined incorrectly? > I dug out a exynos5250-snow out of my pile and booted postmarket OS on > it, which was shockingly easy/pleasant (kudos to those involved!). I > found that it was booting a kernel based on 6.1.24. Digging into > sysfs, I found that indeed it appeared to be using the "panel-edp" > driver, so I guess it is limping along with the wrong driver and wrong > flags... Hi. I'm the maintainer of chromebooks (including exynos 5 ones) in postmarketOS. We are indeed on 6.1.24 yet, but we will upgrade it to the latest LTS soon. > It wasn't totally clear for me how to build a new kernel and deploy it > for postmarket OS, so I wasn't able to confirm this change. I've CCed > the person listed on the postmarket OS wiki though to see if they have > any insight. The recommended way to build kernel is envkernel, see https://wiki.postmarketos.org/wiki/Compiling_kernels_with_envkernel.sh. This way you can build kernel, package it and sideload it to your device, so it will get installed including updating /lib/modules and flashing chrome os kernel partition. You would need to source envkernel.sh in your kernel tree, place kernel config at .output/.config, build it and perform: pmbootstrap build --envkernel linux-postmarketos-exynos5 pmbootstrap sideload --install-key --host <ip> linux-postmarketos-exynos5 We use lts branch of https://gitlab.com/exynos5-mainline/linux with this config: https://gitlab.com/postmarketOS/pmaports/-/blob/master/device/community/linux-postmarketos-exynos5/config-postmarketos-exynos5.armv7 > > In any case, it sounds as if things are working well enough on older > OSes, so maybe we can just skip trying to do any stable backport on > this. It still seems like we should land it, though, since the current > state of the world seems pretty broken. Anyone willing to give a > Reviewed-by or Acked-by tag? > > -Doug > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 10/5/23 21:10, Doug Anderson wrote: > Hi, > > On Tue, Sep 26, 2023 at 7:01 AM Doug Anderson <dianders@chromium.org> wrote: >> Hi, >> >> On Tue, Sep 26, 2023 at 1:06 AM AngeloGioacchino Del Regno >> <angelogioacchino.delregno@collabora.com> wrote: >>> Il 26/09/23 00:00, Douglas Anderson ha scritto: >>>> In commit 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of >>>> panel-simple") I moved a pile of panels out of panel-simple driver >>>> into the newly created panel-edp driver. One of those panels, however, >>>> shouldn't have been moved. >>>> >>>> As is clear from commit e35e305eff0f ("drm/panel: simple: Add AUO >>>> B116XW03 panel support"), AUX B116XW03 is an LVDS panel. It's used in >>>> exynos5250-snow and exynos5420-peach-pit where it's clear that the >>>> panel is hooked up with LVDS. Furthermore, searching for datasheets I >>>> found one that makes it clear that this panel is LVDS. >>>> >>>> As far as I can tell, I got confused because in commit 88d3457ceb82 >>>> ("drm/panel: auo,b116xw03: fix flash backlight when power on") Jitao >>>> Shi added "DRM_MODE_CONNECTOR_eDP". That seems wrong. Looking at the >>>> downstream ChromeOS trees, it seems like some Mediatek boards are >>>> using a panel that they call "auo,b116xw03" that's an eDP panel. The >>>> best I can guess is that they actually have a different panel that has >>>> similar timing. If so then the proper panel should be used or they >>>> should switch to the generic "edp-panel" compatible. >>>> >>>> When moving this back to panel-edp, I wasn't sure what to use for >>>> .bus_flags and .bus_format and whether to add the extra "enable" delay >>>> from commit 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash >>>> backlight when power on"). I've added formats/flags/delays based on my >>>> (inexpert) analysis of the datasheet. These are untested. >>>> >>>> NOTE: if/when this is backported to stable, we might run into some >>>> trouble. Specifically, before 474c162878ba ("arm64: dts: mt8183: >>>> jacuzzi: Move panel under aux-bus") this panel was used by >>>> "mt8183-kukui-jacuzzi", which assumed it was an eDP panel. I don't >>>> know what to suggest for that other than someone making up a bogus >>>> panel for jacuzzi that's just for the stable channel. >>>> >>>> Fixes: 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power on") >>>> Fixes: 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of panel-simple") >>>> Signed-off-by: Douglas Anderson <dianders@chromium.org> >>>> --- >>>> I haven't had a snow or peach-pit hooked up for debugging / testing >>>> for years. I presume that they must be broken and hope that this fixes >>>> them. >>> We could avoid backport breakages by avoiding to backport this to any kernel >>> that doesn't contain commit 474c162878ba ("arm64: dts: mt8183: jacuzzi: Move >>> panel under aux-bus")... because creating a dummy panel to get two wrongs >>> right is definitely not ok. >> Sure, except that leaves us with ... a breakage. :-P >> >> Although I haven't tested it, I have a hard time believing that >> exynos5250-snow and exynos5420-peach-pit will work properly with the >> panel defined as an eDP panel. That means that they will be broken. If >> someone cared to get those fixed in a stable backport then we'd be >> stuck deciding who to break. If you have any brilliant ideas then I'm >> all ears. >> >> ...then again, I presume this has been broken since commit >> 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power >> on"). That was a little over 3 years ago. Maybe I'm wrong and somehow >> things still limp along and sorta work even though the panel is >> defined incorrectly? > I dug out a exynos5250-snow out of my pile and booted postmarket OS on > it, which was shockingly easy/pleasant (kudos to those involved!). I > found that it was booting a kernel based on 6.1.24. Digging into > sysfs, I found that indeed it appeared to be using the "panel-edp" > driver, so I guess it is limping along with the wrong driver and wrong > flags... > > It wasn't totally clear for me how to build a new kernel and deploy it > for postmarket OS, so I wasn't able to confirm this change. I've CCed > the person listed on the postmarket OS wiki though to see if they have > any insight. Tested it on peach-pit using linux-next with this patch applied. Panel still works and "dmesg | grep panel" returns panel_simple instead of panel_edp. Tested-by: Anton Bambura <jenneron@postmarketos.org> > > In any case, it sounds as if things are working well enough on older > OSes, so maybe we can just skip trying to do any stable backport on > this. It still seems like we should land it, though, since the current > state of the world seems pretty broken. Anyone willing to give a > Reviewed-by or Acked-by tag? > > -Doug > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi, On Sun, Oct 8, 2023 at 1:52 PM Anton Bambura <jenneron@postmarketos.org> wrote: > > > On 10/5/23 21:10, Doug Anderson wrote: > > Hi, > > > > On Tue, Sep 26, 2023 at 7:01 AM Doug Anderson <dianders@chromium.org> wrote: > >> Hi, > >> > >> On Tue, Sep 26, 2023 at 1:06 AM AngeloGioacchino Del Regno > >> <angelogioacchino.delregno@collabora.com> wrote: > >>> Il 26/09/23 00:00, Douglas Anderson ha scritto: > >>>> In commit 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of > >>>> panel-simple") I moved a pile of panels out of panel-simple driver > >>>> into the newly created panel-edp driver. One of those panels, however, > >>>> shouldn't have been moved. > >>>> > >>>> As is clear from commit e35e305eff0f ("drm/panel: simple: Add AUO > >>>> B116XW03 panel support"), AUX B116XW03 is an LVDS panel. It's used in > >>>> exynos5250-snow and exynos5420-peach-pit where it's clear that the > >>>> panel is hooked up with LVDS. Furthermore, searching for datasheets I > >>>> found one that makes it clear that this panel is LVDS. > >>>> > >>>> As far as I can tell, I got confused because in commit 88d3457ceb82 > >>>> ("drm/panel: auo,b116xw03: fix flash backlight when power on") Jitao > >>>> Shi added "DRM_MODE_CONNECTOR_eDP". That seems wrong. Looking at the > >>>> downstream ChromeOS trees, it seems like some Mediatek boards are > >>>> using a panel that they call "auo,b116xw03" that's an eDP panel. The > >>>> best I can guess is that they actually have a different panel that has > >>>> similar timing. If so then the proper panel should be used or they > >>>> should switch to the generic "edp-panel" compatible. > >>>> > >>>> When moving this back to panel-edp, I wasn't sure what to use for > >>>> .bus_flags and .bus_format and whether to add the extra "enable" delay > >>>> from commit 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash > >>>> backlight when power on"). I've added formats/flags/delays based on my > >>>> (inexpert) analysis of the datasheet. These are untested. > >>>> > >>>> NOTE: if/when this is backported to stable, we might run into some > >>>> trouble. Specifically, before 474c162878ba ("arm64: dts: mt8183: > >>>> jacuzzi: Move panel under aux-bus") this panel was used by > >>>> "mt8183-kukui-jacuzzi", which assumed it was an eDP panel. I don't > >>>> know what to suggest for that other than someone making up a bogus > >>>> panel for jacuzzi that's just for the stable channel. > >>>> > >>>> Fixes: 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power on") > >>>> Fixes: 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of panel-simple") > >>>> Signed-off-by: Douglas Anderson <dianders@chromium.org> > >>>> --- > >>>> I haven't had a snow or peach-pit hooked up for debugging / testing > >>>> for years. I presume that they must be broken and hope that this fixes > >>>> them. > >>> We could avoid backport breakages by avoiding to backport this to any kernel > >>> that doesn't contain commit 474c162878ba ("arm64: dts: mt8183: jacuzzi: Move > >>> panel under aux-bus")... because creating a dummy panel to get two wrongs > >>> right is definitely not ok. > >> Sure, except that leaves us with ... a breakage. :-P > >> > >> Although I haven't tested it, I have a hard time believing that > >> exynos5250-snow and exynos5420-peach-pit will work properly with the > >> panel defined as an eDP panel. That means that they will be broken. If > >> someone cared to get those fixed in a stable backport then we'd be > >> stuck deciding who to break. If you have any brilliant ideas then I'm > >> all ears. > >> > >> ...then again, I presume this has been broken since commit > >> 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power > >> on"). That was a little over 3 years ago. Maybe I'm wrong and somehow > >> things still limp along and sorta work even though the panel is > >> defined incorrectly? > > I dug out a exynos5250-snow out of my pile and booted postmarket OS on > > it, which was shockingly easy/pleasant (kudos to those involved!). I > > found that it was booting a kernel based on 6.1.24. Digging into > > sysfs, I found that indeed it appeared to be using the "panel-edp" > > driver, so I guess it is limping along with the wrong driver and wrong > > flags... > > > > It wasn't totally clear for me how to build a new kernel and deploy it > > for postmarket OS, so I wasn't able to confirm this change. I've CCed > > the person listed on the postmarket OS wiki though to see if they have > > any insight. > Tested it on peach-pit using linux-next with this patch applied. Panel > still works and "dmesg | grep panel" returns panel_simple instead of > panel_edp. > > Tested-by: Anton Bambura <jenneron@postmarketos.org> Pushed to drm-misc-fixes: ad3e33fe071d drm/panel: Move AUX B116XW03 out of panel-edp back to panel-simple -Doug
diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c index feb665df35a1..95c8472d878a 100644 --- a/drivers/gpu/drm/panel/panel-edp.c +++ b/drivers/gpu/drm/panel/panel-edp.c @@ -976,32 +976,6 @@ static const struct panel_desc auo_b116xak01 = { }, }; -static const struct drm_display_mode auo_b116xw03_mode = { - .clock = 70589, - .hdisplay = 1366, - .hsync_start = 1366 + 40, - .hsync_end = 1366 + 40 + 40, - .htotal = 1366 + 40 + 40 + 32, - .vdisplay = 768, - .vsync_start = 768 + 10, - .vsync_end = 768 + 10 + 12, - .vtotal = 768 + 10 + 12 + 6, - .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC, -}; - -static const struct panel_desc auo_b116xw03 = { - .modes = &auo_b116xw03_mode, - .num_modes = 1, - .bpc = 6, - .size = { - .width = 256, - .height = 144, - }, - .delay = { - .enable = 400, - }, -}; - static const struct drm_display_mode auo_b133han05_mode = { .clock = 142600, .hdisplay = 1920, @@ -1725,9 +1699,6 @@ static const struct of_device_id platform_of_match[] = { }, { .compatible = "auo,b116xa01", .data = &auo_b116xak01, - }, { - .compatible = "auo,b116xw03", - .data = &auo_b116xw03, }, { .compatible = "auo,b133han05", .data = &auo_b133han05, diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index bb89e6d047bc..439d26928938 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -919,6 +919,38 @@ static const struct panel_desc auo_b101xtn01 = { }, }; +static const struct drm_display_mode auo_b116xw03_mode = { + .clock = 70589, + .hdisplay = 1366, + .hsync_start = 1366 + 40, + .hsync_end = 1366 + 40 + 40, + .htotal = 1366 + 40 + 40 + 32, + .vdisplay = 768, + .vsync_start = 768 + 10, + .vsync_end = 768 + 10 + 12, + .vtotal = 768 + 10 + 12 + 6, + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC, +}; + +static const struct panel_desc auo_b116xw03 = { + .modes = &auo_b116xw03_mode, + .num_modes = 1, + .bpc = 6, + .size = { + .width = 256, + .height = 144, + }, + .delay = { + .prepare = 1, + .enable = 200, + .disable = 200, + .unprepare = 500, + }, + .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG, + .bus_flags = DRM_BUS_FLAG_DE_HIGH, + .connector_type = DRM_MODE_CONNECTOR_LVDS, +}; + static const struct display_timing auo_g070vvn01_timings = { .pixelclock = { 33300000, 34209000, 45000000 }, .hactive = { 800, 800, 800 }, @@ -4128,6 +4160,9 @@ static const struct of_device_id platform_of_match[] = { }, { .compatible = "auo,b101xtn01", .data = &auo_b101xtn01, + }, { + .compatible = "auo,b116xw03", + .data = &auo_b116xw03, }, { .compatible = "auo,g070vvn01", .data = &auo_g070vvn01,
In commit 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of panel-simple") I moved a pile of panels out of panel-simple driver into the newly created panel-edp driver. One of those panels, however, shouldn't have been moved. As is clear from commit e35e305eff0f ("drm/panel: simple: Add AUO B116XW03 panel support"), AUX B116XW03 is an LVDS panel. It's used in exynos5250-snow and exynos5420-peach-pit where it's clear that the panel is hooked up with LVDS. Furthermore, searching for datasheets I found one that makes it clear that this panel is LVDS. As far as I can tell, I got confused because in commit 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power on") Jitao Shi added "DRM_MODE_CONNECTOR_eDP". That seems wrong. Looking at the downstream ChromeOS trees, it seems like some Mediatek boards are using a panel that they call "auo,b116xw03" that's an eDP panel. The best I can guess is that they actually have a different panel that has similar timing. If so then the proper panel should be used or they should switch to the generic "edp-panel" compatible. When moving this back to panel-edp, I wasn't sure what to use for .bus_flags and .bus_format and whether to add the extra "enable" delay from commit 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power on"). I've added formats/flags/delays based on my (inexpert) analysis of the datasheet. These are untested. NOTE: if/when this is backported to stable, we might run into some trouble. Specifically, before 474c162878ba ("arm64: dts: mt8183: jacuzzi: Move panel under aux-bus") this panel was used by "mt8183-kukui-jacuzzi", which assumed it was an eDP panel. I don't know what to suggest for that other than someone making up a bogus panel for jacuzzi that's just for the stable channel. Fixes: 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power on") Fixes: 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of panel-simple") Signed-off-by: Douglas Anderson <dianders@chromium.org> --- I haven't had a snow or peach-pit hooked up for debugging / testing for years. I presume that they must be broken and hope that this fixes them. drivers/gpu/drm/panel/panel-edp.c | 29 ----------------------- drivers/gpu/drm/panel/panel-simple.c | 35 ++++++++++++++++++++++++++++ 2 files changed, 35 insertions(+), 29 deletions(-)