From: Chen-Yu Tsai <wenst@chromium.org> To: Doug Anderson <dianders@chromium.org> Cc: Rob Herring <robh+dt@kernel.org>, Frank Rowand <frowand.list@gmail.com>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Matthias Brugger <matthias.bgg@gmail.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, Hsin-Yi Wang <hsinyi@chromium.org>, Dmitry Torokhov <dmitry.torokhov@gmail.com>, andriy.shevchenko@linux.intel.com, Jiri Kosina <jikos@kernel.org>, linus.walleij@linaro.org, broonie@kernel.org, gregkh@linuxfoundation.org, hdegoede@redhat.com, james.clark@arm.com, james@equiv.tech, keescook@chromium.org, rafael@kernel.org, tglx@linutronix.de, Jeff LaBundy <jeff@labundy.com>, linux-input@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, Johan Hovold <johan@kernel.org> Subject: Re: [RFC PATCH v2 0/7] of: Introduce hardware prober driver Date: Tue, 14 Nov 2023 16:44:10 +0800 [thread overview] Message-ID: <CAGXv+5GHFn_Xr0ta7b5M9WMBJzCE6NJWo_PR+XOYXO0oaoPeaQ@mail.gmail.com> (raw) In-Reply-To: <CAD=FV=WZCyp1aaSmpF-_TQ0CTWG1ZuvPZVw4mR=wJH=NTkKqqg@mail.gmail.com> On Sat, Nov 11, 2023 at 8:22 AM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Thu, Nov 9, 2023 at 2:06 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > The driver as > > implemented currently doesn't deal with regulators or GPIO pins, > > since in the existing device trees they are either always on for > > regulators, or have GPIO hogs or pinmux and pinconfig directly > > tied to the pin controller. > > I guess I won't object too much about this limitation for v1, but IMO > it would be good to get this sorted out since I think part of the > power of having the HW Prober is specifically that it can handle this > type of use case. You have a little bit of board-specific code that > knows how to turn on the regulators / GPIOs and can then probe the > devices. > > Note: even if this is "board specific", it doesn't mean you couldn't > share code between boards. For instance, you could have a helper > function that would turn on regulators/GPIOs based on some type of > table and that helper function could be used across a whole pile of > Chromebooks. If a Chromebook is sufficiently different that it > couldn't use the helper function then it could call its own function, > but presumably it wouldn't be hard to support a bunch of boards > without much code. I agree this part is fairly generic and should be implemented. We probably don't even need such a table. If these components share a common connection to the mainboard, they certainly will have the same GPIO lines and regulator supplies. The prober could just scan the nodes looking for -gpio and -supply properties, de-duplicate them, and turn them on. The reason this isn't implemented in this version is because the devices I'm currently using do not have these resources togglable. The supply is always on, and the GPIO line is disconnected from the SoC. So I have no way of testing it yet. > As part of this, I think that your main "HW Prober" for Chromebooks > should be in "drivers/platform/chrome/". I think that the only things > that should be in the "drivers/of" directory should be helper > functions used by the Chromebook HW Probers. Sound like what Rob wants. ChenYu
WARNING: multiple messages have this Message-ID (diff)
From: Chen-Yu Tsai <wenst@chromium.org> To: Doug Anderson <dianders@chromium.org> Cc: Rob Herring <robh+dt@kernel.org>, Frank Rowand <frowand.list@gmail.com>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Matthias Brugger <matthias.bgg@gmail.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, Hsin-Yi Wang <hsinyi@chromium.org>, Dmitry Torokhov <dmitry.torokhov@gmail.com>, andriy.shevchenko@linux.intel.com, Jiri Kosina <jikos@kernel.org>, linus.walleij@linaro.org, broonie@kernel.org, gregkh@linuxfoundation.org, hdegoede@redhat.com, james.clark@arm.com, james@equiv.tech, keescook@chromium.org, rafael@kernel.org, tglx@linutronix.de, Jeff LaBundy <jeff@labundy.com>, linux-input@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, Johan Hovold <johan@kernel.org> Subject: Re: [RFC PATCH v2 0/7] of: Introduce hardware prober driver Date: Tue, 14 Nov 2023 16:44:10 +0800 [thread overview] Message-ID: <CAGXv+5GHFn_Xr0ta7b5M9WMBJzCE6NJWo_PR+XOYXO0oaoPeaQ@mail.gmail.com> (raw) In-Reply-To: <CAD=FV=WZCyp1aaSmpF-_TQ0CTWG1ZuvPZVw4mR=wJH=NTkKqqg@mail.gmail.com> On Sat, Nov 11, 2023 at 8:22 AM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Thu, Nov 9, 2023 at 2:06 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > The driver as > > implemented currently doesn't deal with regulators or GPIO pins, > > since in the existing device trees they are either always on for > > regulators, or have GPIO hogs or pinmux and pinconfig directly > > tied to the pin controller. > > I guess I won't object too much about this limitation for v1, but IMO > it would be good to get this sorted out since I think part of the > power of having the HW Prober is specifically that it can handle this > type of use case. You have a little bit of board-specific code that > knows how to turn on the regulators / GPIOs and can then probe the > devices. > > Note: even if this is "board specific", it doesn't mean you couldn't > share code between boards. For instance, you could have a helper > function that would turn on regulators/GPIOs based on some type of > table and that helper function could be used across a whole pile of > Chromebooks. If a Chromebook is sufficiently different that it > couldn't use the helper function then it could call its own function, > but presumably it wouldn't be hard to support a bunch of boards > without much code. I agree this part is fairly generic and should be implemented. We probably don't even need such a table. If these components share a common connection to the mainboard, they certainly will have the same GPIO lines and regulator supplies. The prober could just scan the nodes looking for -gpio and -supply properties, de-duplicate them, and turn them on. The reason this isn't implemented in this version is because the devices I'm currently using do not have these resources togglable. The supply is always on, and the GPIO line is disconnected from the SoC. So I have no way of testing it yet. > As part of this, I think that your main "HW Prober" for Chromebooks > should be in "drivers/platform/chrome/". I think that the only things > that should be in the "drivers/of" directory should be helper > functions used by the Chromebook HW Probers. Sound like what Rob wants. ChenYu _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-11-14 8:44 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-11-09 10:05 [RFC PATCH v2 0/7] of: Introduce hardware prober driver Chen-Yu Tsai 2023-11-09 10:05 ` Chen-Yu Tsai 2023-11-09 10:05 ` [RFC PATCH v2 1/7] of: base: Add of_device_is_fail Chen-Yu Tsai 2023-11-09 10:05 ` Chen-Yu Tsai 2023-11-09 10:05 ` [RFC PATCH v2 2/7] of: Introduce hardware prober driver Chen-Yu Tsai 2023-11-09 10:05 ` Chen-Yu Tsai 2023-11-09 15:13 ` Rob Herring 2023-11-09 15:13 ` Rob Herring 2023-11-14 8:30 ` Chen-Yu Tsai 2023-11-14 8:30 ` Chen-Yu Tsai 2023-11-09 17:54 ` Andy Shevchenko 2023-11-09 17:54 ` Andy Shevchenko 2023-11-14 8:26 ` Chen-Yu Tsai 2023-11-14 8:26 ` Chen-Yu Tsai 2023-11-09 10:06 ` [RFC PATCH v2 3/7] arm64: dts: mediatek: mt8173-elm-hana: Mark touchscreens and trackpads as fail Chen-Yu Tsai 2023-11-09 10:06 ` Chen-Yu Tsai 2023-11-09 10:06 ` [RFC PATCH v2 4/7] arm64: dts: mediatek: mt8173-elm-hana: Add G2touch G7500 touchscreen Chen-Yu Tsai 2023-11-09 10:06 ` Chen-Yu Tsai 2023-11-09 10:06 ` [RFC PATCH v2 5/7] of: hw_prober: Support Chromebook SKU ID based component selection Chen-Yu Tsai 2023-11-09 10:06 ` Chen-Yu Tsai 2023-11-10 21:07 ` Rob Herring 2023-11-10 21:07 ` Rob Herring 2023-11-09 10:06 ` [RFC PATCH v2 6/7] dt-bindings: arm: mediatek: Remove SKU specific compatibles for Google Krane Chen-Yu Tsai 2023-11-09 10:06 ` Chen-Yu Tsai 2023-11-10 21:04 ` Rob Herring 2023-11-10 21:04 ` Rob Herring 2023-11-11 0:29 ` Doug Anderson 2023-11-11 0:29 ` Doug Anderson 2023-11-09 10:06 ` [RFC PATCH v2 7/7] arm64: dts: mediatek: mt8183-kukui: Merge Krane device trees Chen-Yu Tsai 2023-11-09 10:06 ` Chen-Yu Tsai 2023-11-09 10:54 ` [RFC PATCH v2 0/7] of: Introduce hardware prober driver AngeloGioacchino Del Regno 2023-11-09 10:54 ` AngeloGioacchino Del Regno 2023-11-09 13:51 ` Rob Herring 2023-11-09 13:51 ` Rob Herring 2023-11-11 0:12 ` Doug Anderson 2023-11-11 0:12 ` Doug Anderson 2023-11-15 19:28 ` Rob Herring 2023-11-15 19:28 ` Rob Herring 2023-11-15 20:44 ` Doug Anderson 2023-11-15 20:44 ` Doug Anderson 2023-11-15 21:34 ` Rob Herring 2023-11-15 21:34 ` Rob Herring 2023-11-15 22:13 ` Doug Anderson 2023-11-15 22:13 ` Doug Anderson 2023-11-16 5:11 ` Chen-Yu Tsai 2023-11-16 5:11 ` Chen-Yu Tsai 2023-11-19 14:34 ` Rob Herring 2023-11-19 14:34 ` Rob Herring 2023-11-16 5:07 ` Chen-Yu Tsai 2023-11-16 5:07 ` Chen-Yu Tsai 2023-11-14 7:05 ` Chen-Yu Tsai 2023-11-14 7:05 ` Chen-Yu Tsai 2023-11-14 8:57 ` Chen-Yu Tsai 2023-11-14 8:57 ` Chen-Yu Tsai 2023-11-14 10:04 ` AngeloGioacchino Del Regno 2023-11-14 10:04 ` AngeloGioacchino Del Regno 2023-11-11 0:22 ` Doug Anderson 2023-11-11 0:22 ` Doug Anderson 2023-11-14 8:44 ` Chen-Yu Tsai [this message] 2023-11-14 8:44 ` Chen-Yu Tsai
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=CAGXv+5GHFn_Xr0ta7b5M9WMBJzCE6NJWo_PR+XOYXO0oaoPeaQ@mail.gmail.com \ --to=wenst@chromium.org \ --cc=andriy.shevchenko@linux.intel.com \ --cc=angelogioacchino.delregno@collabora.com \ --cc=broonie@kernel.org \ --cc=conor+dt@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=dianders@chromium.org \ --cc=dmitry.torokhov@gmail.com \ --cc=frowand.list@gmail.com \ --cc=gregkh@linuxfoundation.org \ --cc=hdegoede@redhat.com \ --cc=hsinyi@chromium.org \ --cc=james.clark@arm.com \ --cc=james@equiv.tech \ --cc=jeff@labundy.com \ --cc=jikos@kernel.org \ --cc=johan@kernel.org \ --cc=keescook@chromium.org \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-input@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mediatek@lists.infradead.org \ --cc=matthias.bgg@gmail.com \ --cc=rafael@kernel.org \ --cc=robh+dt@kernel.org \ --cc=tglx@linutronix.de \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.