linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Conor Dooley <conor@kernel.org>
To: yang tylor <tylor_yang@himax.corp-partner.google.com>
Cc: Conor Dooley <conor.dooley@microchip.com>,
	dmitry.torokhov@gmail.com, robh+dt@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
	jikos@kernel.org, benjamin.tissoires@redhat.com,
	linux-input@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	poyuan_chang@himax.corp-partner.google.com, hbarnor@chromium.org,
	"jingyliang@chromium.org" <jingyliang@chromium.org>,
	wuxy23@lenovo.com, luolm1@lenovo.com,
	hung poyu <poyu_hung@himax.corp-partner.google.com>
Subject: Re: [PATCH V2 1/2] dt-bindings: input: Introduce Himax HID-over-SPI device
Date: Mon, 9 Oct 2023 18:52:26 +0100	[thread overview]
Message-ID: <20231009-pentagram-clamshell-b14ff00743fd@spud> (raw)
In-Reply-To: <CAGD2q_b1gn8XAfgfzuNn3Jo6gEguBEacxERyRM5ms-V=+hWS+g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3374 bytes --]

On Mon, Oct 02, 2023 at 06:44:41PM +0800, yang tylor wrote:
> On Fri, Sep 29, 2023 at 12:56 AM Conor Dooley <conor@kernel.org> wrote:
> >
> > On Thu, Sep 28, 2023 at 10:12:41AM +0800, yang tylor wrote:
> > > On Tue, Sep 26, 2023 at 8:53 PM Conor Dooley <conor@kernel.org> wrote:
> > > > On Tue, Sep 26, 2023 at 05:52:39PM +0800, yang tylor wrote:
> > > > > On Tue, Sep 26, 2023 at 5:02 PM Conor Dooley <conor@kernel.org> wrote:
> > > > > > On Mon, Sep 25, 2023 at 06:16:29PM +0800, yang tylor wrote:
> > > > > > > On Mon, Sep 25, 2023 at 4:41 PM Conor Dooley <conor.dooley@microchip.com> wrote:
> > > > > > > We have a default prefix firmware name(like himax_xxxx.bin) in the driver code.
> > > > > >
> > > > > > How do you intend generating the name of the firmware file? I assume the
> > > > > > same firmware doesn't work on every IC, so you'll need to pick a
> > > > > > different one depending on the compatible?
> > > > > >
> > > > > If considering a firmware library line-up for all the incoming panels
> > > > > of this driver.
> > > > > We would use PID as part of the file name. Because all the support panels would
> > > > > have a unique PID associated. Which will make the firmware name like
> > > > > himax_xxx_{$PID}.bin. The problem is, we need to know PID before firmware load
> > > > > at no flash condition. Thus PID information is required in dts when
> > > > > no-flash-flag
> > > > > is specified.
> > > >
> > > > Firstly, where does the "xxx" come from?
> > > > And you're making it sound more like having firmware-name is suitable
> > > > for this use case, given you need to determine the name of the file to
> > > > use based on something that is hardware specific but is not
> > > > dynamically detectable.
> > > Current driver patch uses a prefix name "himax_i2chid" which comes
> > > from the previous project
> > >  and seems not suitable for this condition, so I use "xxx" and plan to
> > > replace it in the next version.
> > > For finding firmware, I think both solutions are reasonable.
> > > - provide firmware name directly: implies no-flash and use user
> > > specified firmware, no PID info.
> > > - provide no-flash-flag and PID info: loading firmware from organized
> > > names with PID info.
> > > I prefer the 2nd solution, but it needs more properties in dts. 1st
> > > has less properties and more
> > > intuitive.
> > >
> > > I don't know which one is more acceptable by the community, as you
> > > know I'm a newbie here.
> >
> > To be honest, I am not all that sure either! Does the panel id have
> > value in its own right, or is that only used to determine the firmware
> > filename?
> Currently, PID stands for Panel/Project ID and is used for determining
> the firmware filename only. We haven't come up with any new attribute that
> may attach to it. The differences between panels are handled in firmware
> dedicated to its PID.
> 
> > Also, if it does have value in its own right, rather than a "pid",
> > should the panel be a child node of this hid device with its own
> > compatible?
> It may need a child node if we find it necessary to add attributes to each PID.
> But currently we have no idea about it.

To be honest, it seems to me like you are using "PID" in place of a
compatible for the panel, since it needs to be provided via DT anyway.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2023-10-09 17:52 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-19  2:49 [PATCH V2 0/2] HID: touchscreen: add himax hid-over-spi driver Tylor Yang
2023-09-19  2:49 ` [PATCH V2 1/2] dt-bindings: input: Introduce Himax HID-over-SPI device Tylor Yang
2023-09-19  8:41   ` Conor Dooley
     [not found]     ` <CAGD2q_anfBP78jck6AbMNtgAggjOgaB3P6dkmq9tONHP45adFA@mail.gmail.com>
2023-09-19 11:09       ` Conor Dooley
2023-09-22  7:56         ` yang tylor
2023-09-22  9:22           ` Conor Dooley
2023-09-22  9:43             ` yang tylor
2023-09-22 15:31               ` Conor Dooley
2023-09-25  1:44                 ` yang tylor
2023-09-25  8:41                   ` Conor Dooley
2023-09-25 10:16                     ` yang tylor
2023-09-26  9:02                       ` Conor Dooley
2023-09-26  9:52                         ` yang tylor
2023-09-26 12:53                           ` Conor Dooley
2023-09-28  2:12                             ` yang tylor
2023-09-28 16:56                               ` Conor Dooley
2023-10-02 10:44                                 ` yang tylor
2023-10-09 17:52                                   ` Conor Dooley [this message]
2023-10-12  2:30                                     ` yang tylor
2023-10-12 15:24                                       ` Conor Dooley
2023-10-13  2:15                                         ` yang tylor
2023-09-19 18:17   ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231009-pentagram-clamshell-b14ff00743fd@spud \
    --to=conor@kernel.org \
    --cc=benjamin.tissoires@redhat.com \
    --cc=conor+dt@kernel.org \
    --cc=conor.dooley@microchip.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=hbarnor@chromium.org \
    --cc=jikos@kernel.org \
    --cc=jingyliang@chromium.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luolm1@lenovo.com \
    --cc=poyu_hung@himax.corp-partner.google.com \
    --cc=poyuan_chang@himax.corp-partner.google.com \
    --cc=robh+dt@kernel.org \
    --cc=tylor_yang@himax.corp-partner.google.com \
    --cc=wuxy23@lenovo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).