Re: [PATCH v3 1/2] dt-bindings: display: panel: Add ChipWealth CH13726A AMOLED driver

[Aaron Kling <webgeek1234@gmail.com>]

On Tue, Mar 24, 2026 at 4:08 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Mon, Mar 23, 2026 at 12:08:32PM -0500, Aaron Kling wrote:
> > The Chip Wealth Technology CH13726A AMOLED driver is a single chip
> > solution for MIPI-DSI. This is used for the AYN Thor bottom panel.
> >
> > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > ---
> >  .../display/panel/chipwealth,ch13726a.yaml         | 65 ++++++++++++++++++++++
> >  1 file changed, 65 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/panel/chipwealth,ch13726a.yaml b/Documentation/devicetree/bindings/display/panel/chipwealth,ch13726a.yaml
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..5d964900795653401a871994bcf6403cdeaad64f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/chipwealth,ch13726a.yaml
> > @@ -0,0 +1,65 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/chipwealth,ch13726a.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Chip Wealth Technology CH13726A AMOLED driver
> > +
> > +maintainers:
> > +  - Neil Armstrong <neil.armstrong@linaro.org>
> > +
> > +description:
> > +  Chip Wealth Technology CH13726A is a single-chip solution
> > +  for AMOLED connected using a MIPI-DSI video interface.
>
> Here you describe the hardware, including what I asked last time -
> explain why this is ayntec thor panel, but not chipwealth,ch13726a.
>
> Then also name the file as the compatible. If you do not know the part
> (model?) number, then why do you think filename should be called
> ch13726a?

The vendor source release for the AYN Thor calls the 'panel' ch13726a,
but per the data sheet for said part, it's a chip used in various
panels, not a panel itself. The handling for various panels using this
chip will share a lot of similarities since the chip is what the
kernel driver will talk to. The alternative would be having separate
drivers and bindings for every panel that will be mostly duplicated.
This is the case for multiple things supported in the kernel already,
such as the vtdr6130 which is currently described as a unique panel
but is in fact the part number for a ddic. And I will need to refactor
that for another device I have in the pipeline. In fact, all the
device panels I need to submit in this context reference ddic's and
not unique panel models. I'm waiting to see what gets approved for
this series before sending the rest of those in.

If I add something to the description like 'This chip is not a panel
itself, but is used to control various panels', would that be
sufficient? Or does the kernel need a new way to describe ddic's
separately from panels, since this seems to be common now?

Aaron