| Message ID | 20240715-x1e80100-crd-backlight-v2-1-31b7f2f658a3@linaro.org |
|---|---|
| State | Accepted |
| Commit | b6f7d984ebf826069d3dc6fa187b4d1cfb90f965 |
| Headers | show |
| Series | drm/panel: atna33xc20: Fix the Samsung ATNA45AF01 panel | expand |
Conor (and/or) Krzysztof and Rob, On Mon, Jul 15, 2024 at 8:31 AM Conor Dooley <conor@kernel.org> wrote: > > On Mon, Jul 15, 2024 at 02:15:37PM +0200, Stephan Gerhold wrote: > > The Samsung ATNA45AF01 panel is an AMOLED eDP panel that has backlight > > control over the DP AUX channel. While it works almost correctly with the > > generic "edp-panel" compatible, the backlight needs special handling to > > work correctly. It is similar to the existing ATNA33XC20 panel, just with > > a larger resolution and size. > > > > Add a new "samsung,atna45af01" compatible to describe this panel in the DT. > > Use the existing "samsung,atna33xc20" as fallback compatible since existing > > drivers should work as-is, given that resolution and size are discoverable > > through the eDP link. > > > > Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> > > Acked-by: Conor Dooley <conor.dooley@microchip.com> Can you comment on whether you would consider this bindings a "Fix" since it's a dependency for later patches in this series (which are "Fix"es) to pass dtbs_check? See: https://lore.kernel.org/r/4bca316a-2334-425b-87a6-e1bb241d26b5@linaro.org -Doug
On 18/07/2024 02:21, Doug Anderson wrote: > Conor (and/or) Krzysztof and Rob, > > On Mon, Jul 15, 2024 at 8:31 AM Conor Dooley <conor@kernel.org> wrote: >> >> On Mon, Jul 15, 2024 at 02:15:37PM +0200, Stephan Gerhold wrote: >>> The Samsung ATNA45AF01 panel is an AMOLED eDP panel that has backlight >>> control over the DP AUX channel. While it works almost correctly with the >>> generic "edp-panel" compatible, the backlight needs special handling to >>> work correctly. It is similar to the existing ATNA33XC20 panel, just with >>> a larger resolution and size. >>> >>> Add a new "samsung,atna45af01" compatible to describe this panel in the DT. >>> Use the existing "samsung,atna33xc20" as fallback compatible since existing >>> drivers should work as-is, given that resolution and size are discoverable >>> through the eDP link. >>> >>> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> >> >> Acked-by: Conor Dooley <conor.dooley@microchip.com> > > Can you comment on whether you would consider this bindings a "Fix" > since it's a dependency for later patches in this series (which are > "Fix"es) to pass dtbs_check? See: > > https://lore.kernel.org/r/4bca316a-2334-425b-87a6-e1bb241d26b5@linaro.org The patch itself is not a fix, for sure, but it might be a dependency of a fix (which you wrote above), thus could be pulled to stable as a dependency. I do not care about dtbs_check warnings in stable kernels, mostly because dtbs_check warnings depend heavily on dtschema and dtschema follows mainline kernel. Basically if you had warnings-free v6.8 but try to run dtbs_check now with latest dtschema, your results will differ. At some point in the future, I could imagine "no new dtbs_check warnings in stable kernels" requirement or at least preference, but so far I don't think there is any benefit. Best regards, Krzysztof
Hi, On Wed, Jul 17, 2024 at 11:19 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On 18/07/2024 02:21, Doug Anderson wrote: > > Conor (and/or) Krzysztof and Rob, > > > > On Mon, Jul 15, 2024 at 8:31 AM Conor Dooley <conor@kernel.org> wrote: > >> > >> On Mon, Jul 15, 2024 at 02:15:37PM +0200, Stephan Gerhold wrote: > >>> The Samsung ATNA45AF01 panel is an AMOLED eDP panel that has backlight > >>> control over the DP AUX channel. While it works almost correctly with the > >>> generic "edp-panel" compatible, the backlight needs special handling to > >>> work correctly. It is similar to the existing ATNA33XC20 panel, just with > >>> a larger resolution and size. > >>> > >>> Add a new "samsung,atna45af01" compatible to describe this panel in the DT. > >>> Use the existing "samsung,atna33xc20" as fallback compatible since existing > >>> drivers should work as-is, given that resolution and size are discoverable > >>> through the eDP link. > >>> > >>> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> > >> > >> Acked-by: Conor Dooley <conor.dooley@microchip.com> > > > > Can you comment on whether you would consider this bindings a "Fix" > > since it's a dependency for later patches in this series (which are > > "Fix"es) to pass dtbs_check? See: > > > > https://lore.kernel.org/r/4bca316a-2334-425b-87a6-e1bb241d26b5@linaro.org > > The patch itself is not a fix, for sure, but it might be a dependency of > a fix (which you wrote above), thus could be pulled to stable as a > dependency. > > I do not care about dtbs_check warnings in stable kernels, mostly > because dtbs_check warnings depend heavily on dtschema and dtschema > follows mainline kernel. Basically if you had warnings-free v6.8 but try > to run dtbs_check now with latest dtschema, your results will differ. > > At some point in the future, I could imagine "no new dtbs_check warnings > in stable kernels" requirement or at least preference, but so far I > don't think there is any benefit. In this case it's not about whether it makes it to the stable kernel but about which main kernel it goes through. If we land the bindings in drm-misc-next right now then it'll be a long time before it makes it into Linus's tree because of the way that drm-misc-next merges. It will make it to Linus's tree at 6.12. You can see the drm-misc merging strategy at: https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html If we land the dts change (a fix) through the Qualcomm tree as a fix then it should target 6.11. This means that the 6.11 tree will have a dtbs_check error because it has the dts change (a fix) but not the bindings change (not a fix). One way to resolve this would be to treat this bindings as a "fix" and land it through "drm-misc-fixes". That would make the bindings and device tree change meet up in Linux 6.11. Did I get that all correct? -Doug
On Thu, Jul 18, 2024 at 07:45:57AM -0700, Doug Anderson wrote: > Hi, > > On Wed, Jul 17, 2024 at 11:19 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > On 18/07/2024 02:21, Doug Anderson wrote: > > > Conor (and/or) Krzysztof and Rob, > > > > > > On Mon, Jul 15, 2024 at 8:31 AM Conor Dooley <conor@kernel.org> wrote: > > >> > > >> On Mon, Jul 15, 2024 at 02:15:37PM +0200, Stephan Gerhold wrote: > > >>> The Samsung ATNA45AF01 panel is an AMOLED eDP panel that has backlight > > >>> control over the DP AUX channel. While it works almost correctly with the > > >>> generic "edp-panel" compatible, the backlight needs special handling to > > >>> work correctly. It is similar to the existing ATNA33XC20 panel, just with > > >>> a larger resolution and size. > > >>> > > >>> Add a new "samsung,atna45af01" compatible to describe this panel in the DT. > > >>> Use the existing "samsung,atna33xc20" as fallback compatible since existing > > >>> drivers should work as-is, given that resolution and size are discoverable > > >>> through the eDP link. > > >>> > > >>> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> > > >> > > >> Acked-by: Conor Dooley <conor.dooley@microchip.com> > > > > > > Can you comment on whether you would consider this bindings a "Fix" > > > since it's a dependency for later patches in this series (which are > > > "Fix"es) to pass dtbs_check? See: > > > > > > https://lore.kernel.org/r/4bca316a-2334-425b-87a6-e1bb241d26b5@linaro.org > > > > The patch itself is not a fix, for sure, but it might be a dependency of > > a fix (which you wrote above), thus could be pulled to stable as a > > dependency. > > > > I do not care about dtbs_check warnings in stable kernels, mostly > > because dtbs_check warnings depend heavily on dtschema and dtschema > > follows mainline kernel. Basically if you had warnings-free v6.8 but try > > to run dtbs_check now with latest dtschema, your results will differ. > > > > At some point in the future, I could imagine "no new dtbs_check warnings > > in stable kernels" requirement or at least preference, but so far I > > don't think there is any benefit. > > In this case it's not about whether it makes it to the stable kernel > but about which main kernel it goes through. > > If we land the bindings in drm-misc-next right now then it'll be a > long time before it makes it into Linus's tree because of the way that > drm-misc-next merges. It will make it to Linus's tree at 6.12. You can > see the drm-misc merging strategy at: > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html > > If we land the dts change (a fix) through the Qualcomm tree as a fix > then it should target 6.11. > > This means that the 6.11 tree will have a dtbs_check error because it > has the dts change (a fix) but not the bindings change (not a fix). > > One way to resolve this would be to treat this bindings as a "fix" and > land it through "drm-misc-fixes". That would make the bindings and > device tree change meet up in Linux 6.11. > > Did I get that all correct? Is not not fairly established that a dependency for a fix can go onto a fixes branch even if it is not a fix in and of itself?
Hi, On Thu, Jul 18, 2024 at 7:56 AM Conor Dooley <conor@kernel.org> wrote: > > On Thu, Jul 18, 2024 at 07:45:57AM -0700, Doug Anderson wrote: > > Hi, > > > > On Wed, Jul 17, 2024 at 11:19 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > > > On 18/07/2024 02:21, Doug Anderson wrote: > > > > Conor (and/or) Krzysztof and Rob, > > > > > > > > On Mon, Jul 15, 2024 at 8:31 AM Conor Dooley <conor@kernel.org> wrote: > > > >> > > > >> On Mon, Jul 15, 2024 at 02:15:37PM +0200, Stephan Gerhold wrote: > > > >>> The Samsung ATNA45AF01 panel is an AMOLED eDP panel that has backlight > > > >>> control over the DP AUX channel. While it works almost correctly with the > > > >>> generic "edp-panel" compatible, the backlight needs special handling to > > > >>> work correctly. It is similar to the existing ATNA33XC20 panel, just with > > > >>> a larger resolution and size. > > > >>> > > > >>> Add a new "samsung,atna45af01" compatible to describe this panel in the DT. > > > >>> Use the existing "samsung,atna33xc20" as fallback compatible since existing > > > >>> drivers should work as-is, given that resolution and size are discoverable > > > >>> through the eDP link. > > > >>> > > > >>> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> > > > >> > > > >> Acked-by: Conor Dooley <conor.dooley@microchip.com> > > > > > > > > Can you comment on whether you would consider this bindings a "Fix" > > > > since it's a dependency for later patches in this series (which are > > > > "Fix"es) to pass dtbs_check? See: > > > > > > > > https://lore.kernel.org/r/4bca316a-2334-425b-87a6-e1bb241d26b5@linaro.org > > > > > > The patch itself is not a fix, for sure, but it might be a dependency of > > > a fix (which you wrote above), thus could be pulled to stable as a > > > dependency. > > > > > > I do not care about dtbs_check warnings in stable kernels, mostly > > > because dtbs_check warnings depend heavily on dtschema and dtschema > > > follows mainline kernel. Basically if you had warnings-free v6.8 but try > > > to run dtbs_check now with latest dtschema, your results will differ. > > > > > > At some point in the future, I could imagine "no new dtbs_check warnings > > > in stable kernels" requirement or at least preference, but so far I > > > don't think there is any benefit. > > > > In this case it's not about whether it makes it to the stable kernel > > but about which main kernel it goes through. > > > > If we land the bindings in drm-misc-next right now then it'll be a > > long time before it makes it into Linus's tree because of the way that > > drm-misc-next merges. It will make it to Linus's tree at 6.12. You can > > see the drm-misc merging strategy at: > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html > > > > If we land the dts change (a fix) through the Qualcomm tree as a fix > > then it should target 6.11. > > > > This means that the 6.11 tree will have a dtbs_check error because it > > has the dts change (a fix) but not the bindings change (not a fix). > > > > One way to resolve this would be to treat this bindings as a "fix" and > > land it through "drm-misc-fixes". That would make the bindings and > > device tree change meet up in Linux 6.11. > > > > Did I get that all correct? > > Is not not fairly established that a dependency for a fix can go onto a > fixes branch even if it is not a fix in and of itself? That would certainly be my take on it, but DT folks confirmation was requested by Neil in: https://lore.kernel.org/all/4bca316a-2334-425b-87a6-e1bb241d26b5@linaro.org/ -Doug
Hi, On Thu, Jul 18, 2024 at 7:59 AM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Thu, Jul 18, 2024 at 7:56 AM Conor Dooley <conor@kernel.org> wrote: > > > > On Thu, Jul 18, 2024 at 07:45:57AM -0700, Doug Anderson wrote: > > > Hi, > > > > > > On Wed, Jul 17, 2024 at 11:19 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > > > > > On 18/07/2024 02:21, Doug Anderson wrote: > > > > > Conor (and/or) Krzysztof and Rob, > > > > > > > > > > On Mon, Jul 15, 2024 at 8:31 AM Conor Dooley <conor@kernel.org> wrote: > > > > >> > > > > >> On Mon, Jul 15, 2024 at 02:15:37PM +0200, Stephan Gerhold wrote: > > > > >>> The Samsung ATNA45AF01 panel is an AMOLED eDP panel that has backlight > > > > >>> control over the DP AUX channel. While it works almost correctly with the > > > > >>> generic "edp-panel" compatible, the backlight needs special handling to > > > > >>> work correctly. It is similar to the existing ATNA33XC20 panel, just with > > > > >>> a larger resolution and size. > > > > >>> > > > > >>> Add a new "samsung,atna45af01" compatible to describe this panel in the DT. > > > > >>> Use the existing "samsung,atna33xc20" as fallback compatible since existing > > > > >>> drivers should work as-is, given that resolution and size are discoverable > > > > >>> through the eDP link. > > > > >>> > > > > >>> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> > > > > >> > > > > >> Acked-by: Conor Dooley <conor.dooley@microchip.com> > > > > > > > > > > Can you comment on whether you would consider this bindings a "Fix" > > > > > since it's a dependency for later patches in this series (which are > > > > > "Fix"es) to pass dtbs_check? See: > > > > > > > > > > https://lore.kernel.org/r/4bca316a-2334-425b-87a6-e1bb241d26b5@linaro.org > > > > > > > > The patch itself is not a fix, for sure, but it might be a dependency of > > > > a fix (which you wrote above), thus could be pulled to stable as a > > > > dependency. > > > > > > > > I do not care about dtbs_check warnings in stable kernels, mostly > > > > because dtbs_check warnings depend heavily on dtschema and dtschema > > > > follows mainline kernel. Basically if you had warnings-free v6.8 but try > > > > to run dtbs_check now with latest dtschema, your results will differ. > > > > > > > > At some point in the future, I could imagine "no new dtbs_check warnings > > > > in stable kernels" requirement or at least preference, but so far I > > > > don't think there is any benefit. > > > > > > In this case it's not about whether it makes it to the stable kernel > > > but about which main kernel it goes through. > > > > > > If we land the bindings in drm-misc-next right now then it'll be a > > > long time before it makes it into Linus's tree because of the way that > > > drm-misc-next merges. It will make it to Linus's tree at 6.12. You can > > > see the drm-misc merging strategy at: > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html > > > > > > If we land the dts change (a fix) through the Qualcomm tree as a fix > > > then it should target 6.11. > > > > > > This means that the 6.11 tree will have a dtbs_check error because it > > > has the dts change (a fix) but not the bindings change (not a fix). > > > > > > One way to resolve this would be to treat this bindings as a "fix" and > > > land it through "drm-misc-fixes". That would make the bindings and > > > device tree change meet up in Linux 6.11. > > > > > > Did I get that all correct? > > > > Is not not fairly established that a dependency for a fix can go onto a > > fixes branch even if it is not a fix in and of itself? > > That would certainly be my take on it, but DT folks confirmation was > requested by Neil in: > > https://lore.kernel.org/all/4bca316a-2334-425b-87a6-e1bb241d26b5@linaro.org/ FWIW, I'd rather not let this stagnate too long. I'm fairly confident in my assertion that this should go into drm-misc-fixes. I'll give it until Monday and then I'm just going to land this bindings change in drm-misc-fixes. Shout soon if you feel strongly that I shouldn't do this. If someone wants to flame me after the fact then so be it. -Doug
On Fri, Jul 19, 2024 at 10:07:29AM -0700, Doug Anderson wrote: > Hi, > > On Thu, Jul 18, 2024 at 7:59 AM Doug Anderson <dianders@chromium.org> wrote: > > > > Hi, > > > > On Thu, Jul 18, 2024 at 7:56 AM Conor Dooley <conor@kernel.org> wrote: > > > > > > On Thu, Jul 18, 2024 at 07:45:57AM -0700, Doug Anderson wrote: > > > > Hi, > > > > > > > > On Wed, Jul 17, 2024 at 11:19 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > > > > > > > On 18/07/2024 02:21, Doug Anderson wrote: > > > > > > Conor (and/or) Krzysztof and Rob, > > > > > > > > > > > > On Mon, Jul 15, 2024 at 8:31 AM Conor Dooley <conor@kernel.org> wrote: > > > > > >> > > > > > >> On Mon, Jul 15, 2024 at 02:15:37PM +0200, Stephan Gerhold wrote: > > > > > >>> The Samsung ATNA45AF01 panel is an AMOLED eDP panel that has backlight > > > > > >>> control over the DP AUX channel. While it works almost correctly with the > > > > > >>> generic "edp-panel" compatible, the backlight needs special handling to > > > > > >>> work correctly. It is similar to the existing ATNA33XC20 panel, just with > > > > > >>> a larger resolution and size. > > > > > >>> > > > > > >>> Add a new "samsung,atna45af01" compatible to describe this panel in the DT. > > > > > >>> Use the existing "samsung,atna33xc20" as fallback compatible since existing > > > > > >>> drivers should work as-is, given that resolution and size are discoverable > > > > > >>> through the eDP link. > > > > > >>> > > > > > >>> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> > > > > > >> > > > > > >> Acked-by: Conor Dooley <conor.dooley@microchip.com> > > > > > > > > > > > > Can you comment on whether you would consider this bindings a "Fix" > > > > > > since it's a dependency for later patches in this series (which are > > > > > > "Fix"es) to pass dtbs_check? See: > > > > > > > > > > > > https://lore.kernel.org/r/4bca316a-2334-425b-87a6-e1bb241d26b5@linaro.org > > > > > > > > > > The patch itself is not a fix, for sure, but it might be a dependency of > > > > > a fix (which you wrote above), thus could be pulled to stable as a > > > > > dependency. > > > > > > > > > > I do not care about dtbs_check warnings in stable kernels, mostly > > > > > because dtbs_check warnings depend heavily on dtschema and dtschema > > > > > follows mainline kernel. Basically if you had warnings-free v6.8 but try > > > > > to run dtbs_check now with latest dtschema, your results will differ. > > > > > > > > > > At some point in the future, I could imagine "no new dtbs_check warnings > > > > > in stable kernels" requirement or at least preference, but so far I > > > > > don't think there is any benefit. > > > > > > > > In this case it's not about whether it makes it to the stable kernel > > > > but about which main kernel it goes through. > > > > > > > > If we land the bindings in drm-misc-next right now then it'll be a > > > > long time before it makes it into Linus's tree because of the way that > > > > drm-misc-next merges. It will make it to Linus's tree at 6.12. You can > > > > see the drm-misc merging strategy at: > > > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html > > > > > > > > If we land the dts change (a fix) through the Qualcomm tree as a fix > > > > then it should target 6.11. > > > > > > > > This means that the 6.11 tree will have a dtbs_check error because it > > > > has the dts change (a fix) but not the bindings change (not a fix). > > > > > > > > One way to resolve this would be to treat this bindings as a "fix" and > > > > land it through "drm-misc-fixes". That would make the bindings and > > > > device tree change meet up in Linux 6.11. > > > > > > > > Did I get that all correct? > > > > > > Is not not fairly established that a dependency for a fix can go onto a > > > fixes branch even if it is not a fix in and of itself? > > > > That would certainly be my take on it, but DT folks confirmation was > > requested by Neil in: > > > > https://lore.kernel.org/all/4bca316a-2334-425b-87a6-e1bb241d26b5@linaro.org/ > > FWIW, I'd rather not let this stagnate too long. I dunno if you were waiting for me (or Krzk/Rob) to reply, but I didn't cos I figured I'd already pretty much said there was nothing wrong with the prereq being on -fixes too. > I'm fairly confident > in my assertion that this should go into drm-misc-fixes. I'll give it > until Monday and then I'm just going to land this bindings change in > drm-misc-fixes. Shout soon if you feel strongly that I shouldn't do > this. If someone wants to flame me after the fact then so be it.
Hi, On Fri, Jul 19, 2024 at 10:07 AM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Thu, Jul 18, 2024 at 7:59 AM Doug Anderson <dianders@chromium.org> wrote: > > > > Hi, > > > > On Thu, Jul 18, 2024 at 7:56 AM Conor Dooley <conor@kernel.org> wrote: > > > > > > On Thu, Jul 18, 2024 at 07:45:57AM -0700, Doug Anderson wrote: > > > > Hi, > > > > > > > > On Wed, Jul 17, 2024 at 11:19 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > > > > > > > On 18/07/2024 02:21, Doug Anderson wrote: > > > > > > Conor (and/or) Krzysztof and Rob, > > > > > > > > > > > > On Mon, Jul 15, 2024 at 8:31 AM Conor Dooley <conor@kernel.org> wrote: > > > > > >> > > > > > >> On Mon, Jul 15, 2024 at 02:15:37PM +0200, Stephan Gerhold wrote: > > > > > >>> The Samsung ATNA45AF01 panel is an AMOLED eDP panel that has backlight > > > > > >>> control over the DP AUX channel. While it works almost correctly with the > > > > > >>> generic "edp-panel" compatible, the backlight needs special handling to > > > > > >>> work correctly. It is similar to the existing ATNA33XC20 panel, just with > > > > > >>> a larger resolution and size. > > > > > >>> > > > > > >>> Add a new "samsung,atna45af01" compatible to describe this panel in the DT. > > > > > >>> Use the existing "samsung,atna33xc20" as fallback compatible since existing > > > > > >>> drivers should work as-is, given that resolution and size are discoverable > > > > > >>> through the eDP link. > > > > > >>> > > > > > >>> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> > > > > > >> > > > > > >> Acked-by: Conor Dooley <conor.dooley@microchip.com> > > > > > > > > > > > > Can you comment on whether you would consider this bindings a "Fix" > > > > > > since it's a dependency for later patches in this series (which are > > > > > > "Fix"es) to pass dtbs_check? See: > > > > > > > > > > > > https://lore.kernel.org/r/4bca316a-2334-425b-87a6-e1bb241d26b5@linaro.org > > > > > > > > > > The patch itself is not a fix, for sure, but it might be a dependency of > > > > > a fix (which you wrote above), thus could be pulled to stable as a > > > > > dependency. > > > > > > > > > > I do not care about dtbs_check warnings in stable kernels, mostly > > > > > because dtbs_check warnings depend heavily on dtschema and dtschema > > > > > follows mainline kernel. Basically if you had warnings-free v6.8 but try > > > > > to run dtbs_check now with latest dtschema, your results will differ. > > > > > > > > > > At some point in the future, I could imagine "no new dtbs_check warnings > > > > > in stable kernels" requirement or at least preference, but so far I > > > > > don't think there is any benefit. > > > > > > > > In this case it's not about whether it makes it to the stable kernel > > > > but about which main kernel it goes through. > > > > > > > > If we land the bindings in drm-misc-next right now then it'll be a > > > > long time before it makes it into Linus's tree because of the way that > > > > drm-misc-next merges. It will make it to Linus's tree at 6.12. You can > > > > see the drm-misc merging strategy at: > > > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html > > > > > > > > If we land the dts change (a fix) through the Qualcomm tree as a fix > > > > then it should target 6.11. > > > > > > > > This means that the 6.11 tree will have a dtbs_check error because it > > > > has the dts change (a fix) but not the bindings change (not a fix). > > > > > > > > One way to resolve this would be to treat this bindings as a "fix" and > > > > land it through "drm-misc-fixes". That would make the bindings and > > > > device tree change meet up in Linux 6.11. > > > > > > > > Did I get that all correct? > > > > > > Is not not fairly established that a dependency for a fix can go onto a > > > fixes branch even if it is not a fix in and of itself? > > > > That would certainly be my take on it, but DT folks confirmation was > > requested by Neil in: > > > > https://lore.kernel.org/all/4bca316a-2334-425b-87a6-e1bb241d26b5@linaro.org/ > > FWIW, I'd rather not let this stagnate too long. I'm fairly confident > in my assertion that this should go into drm-misc-fixes. I'll give it > until Monday and then I'm just going to land this bindings change in > drm-misc-fixes. Shout soon if you feel strongly that I shouldn't do > this. If someone wants to flame me after the fact then so be it. Landed in drm-misc-next fixes as per the flow chart [1] since the "samsung,atna33xc20.yaml" split from "panel-simple.yaml" is in mainline linux but not in any "rc" candidates yet. [1/4] dt-bindings: display: panel: samsung,atna33xc20: Document ATNA45AF01 commit: b6f7d984ebf826069d3dc6fa187b4d1cfb90f965 [1] https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#where-do-i-apply-my-patch -Doug
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml b/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml index 765ca155c83a..5192c93fbd67 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml @@ -14,7 +14,13 @@ allOf: properties: compatible: - const: samsung,atna33xc20 + oneOf: + # Samsung 13.3" FHD (1920x1080 pixels) eDP AMOLED panel + - const: samsung,atna33xc20 + # Samsung 14.5" WQXGA+ (2880x1800 pixels) eDP AMOLED panel + - items: + - const: samsung,atna45af01 + - const: samsung,atna33xc20 enable-gpios: true port: true
The Samsung ATNA45AF01 panel is an AMOLED eDP panel that has backlight control over the DP AUX channel. While it works almost correctly with the generic "edp-panel" compatible, the backlight needs special handling to work correctly. It is similar to the existing ATNA33XC20 panel, just with a larger resolution and size. Add a new "samsung,atna45af01" compatible to describe this panel in the DT. Use the existing "samsung,atna33xc20" as fallback compatible since existing drivers should work as-is, given that resolution and size are discoverable through the eDP link. Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> --- .../devicetree/bindings/display/panel/samsung,atna33xc20.yaml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)