diff mbox series

[v2,1/4] dt-bindings: display: panel: samsung,atna33xc20: Document ATNA45AF01

Message ID 20240715-x1e80100-crd-backlight-v2-1-31b7f2f658a3@linaro.org (mailing list archive)
State New, archived
Headers show
Series drm/panel: atna33xc20: Fix the Samsung ATNA45AF01 panel | expand

Commit Message

Stephan Gerhold July 15, 2024, 12:15 p.m. UTC
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(-)

Comments

Neil Armstrong July 15, 2024, 12:39 p.m. UTC | #1
On 15/07/2024 14:15, 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>
> ---
>   .../devicetree/bindings/display/panel/samsung,atna33xc20.yaml     | 8 +++++++-
>   1 file changed, 7 insertions(+), 1 deletion(-)
> 
> 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
> 

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Doug Anderson July 15, 2024, 1:42 p.m. UTC | #2
Hi,

Reviewed-by: Douglas Anderson <dianders@chromium.org>


On Mon, Jul 15, 2024 at 5:16 AM Stephan Gerhold
<stephan.gerhold@linaro.org> 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>
> ---
>  .../devicetree/bindings/display/panel/samsung,atna33xc20.yaml     | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> 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
>
> --
> 2.44.1
>
Conor Dooley July 15, 2024, 3:31 p.m. UTC | #3
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>
Doug Anderson July 18, 2024, 12:21 a.m. UTC | #4
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
Krzysztof Kozlowski July 18, 2024, 6:19 a.m. UTC | #5
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
Doug Anderson July 18, 2024, 2:45 p.m. UTC | #6
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
Conor Dooley July 18, 2024, 2:56 p.m. UTC | #7
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?
Doug Anderson July 18, 2024, 2:59 p.m. UTC | #8
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
Doug Anderson July 19, 2024, 5:07 p.m. UTC | #9
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
Conor Dooley July 19, 2024, 7:26 p.m. UTC | #10
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.
Doug Anderson July 22, 2024, 3:45 p.m. UTC | #11
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 mbox series

Patch

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