On Tue, Mar 24, 2026 at 11:01 AM Aaron Kling <[email protected]> wrote: > > On Tue, Mar 24, 2026 at 4:08 AM Krzysztof Kozlowski <[email protected]> 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 <[email protected]> > > > --- > > > .../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 <[email protected]> > > > + > > > +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?
Krzysztof, Any response to this? Or do I take another guess at what you want when sending a new revision? Aaron
