public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Simon Glass <sjg@chromium.org>
Cc: u-boot@lists.denx.de, etienne.carriere@st.com,
	michal.simek@amd.com, linus.walleij@linaro.org,
	Oleksii_Moisieiev@epam.com
Subject: Re: [RFC 4/6] gpio: add scmi driver based on pinctrl
Date: Mon, 11 Sep 2023 14:38:23 +0900	[thread overview]
Message-ID: <ZP6nz+sZkNiB+7+v@octopus> (raw)
In-Reply-To: <CAPnjgZ3Va35FLk6xF8iyoKtSe5_F_o8Ym7o8jdgXtGMUS6MJ3w@mail.gmail.com>

Hi Simon,

On Sun, Sep 10, 2023 at 01:13:24PM -0600, Simon Glass wrote:
> Hi,
> 
> On Thu, 7 Sept 2023 at 22:32, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
> >
> > Hi Simon,
> >
> > On Thu, Sep 07, 2023 at 06:23:05AM -0600, Simon Glass wrote:
> > > Hi AKASHI,
> > >
> > > On Tue, 5 Sept 2023 at 20:41, AKASHI Takahiro
> > > <takahiro.akashi@linaro.org> wrote:
> > > >
> > > > This DM-compliant driver deals with SCMI pinctrl protocol and presents
> > > > gpio devices exposed by SCMI firmware (server).
> > > >
> > > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > > ---
> > > >  drivers/pinctrl/pinctrl-scmi.c | 544 ++++++++++++++++++++++++++++++++-
> > > >  1 file changed, 539 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/pinctrl/pinctrl-scmi.c b/drivers/pinctrl/pinctrl-scmi.c
> > > > index 3ebdad57b86c..73d385bdbfcc 100644
> > > > --- a/drivers/pinctrl/pinctrl-scmi.c
> > > > +++ b/drivers/pinctrl/pinctrl-scmi.c
> > > > @@ -11,21 +11,20 @@
> > > >  #include <malloc.h>
> > > >  #include <scmi_agent.h>
> > > >  #include <scmi_protocols.h>
> > > > +#include <asm-generic/gpio.h>
> > > >  #include <dm/device_compat.h>
> > > > +#include <dm/device-internal.h>
> > > > +#include <dm/lists.h>
> > > >  #include <dm/pinctrl.h>
> > > >
> > > [..]
> > >
> > > > +
> > > > +U_BOOT_DRIVER(scmi_gpio) = {
> > > > +       .name = "scmi_gpio",
> > > > +       .id = UCLASS_GPIO,
> > > > +       .of_match = scmi_gpio_ids,
> > > > +       .of_to_plat = scmi_gpio_probe,
> > > > +       .ops = &scmi_gpio_ops,
> > > > +       .plat_auto = sizeof(struct scmi_pinctrl_gpio_plat),
> > > > +};
> > > > +
> > > > +/**
> > > > + * scmi_gpiochip_register - Create a pinctrl-controlled gpio device
> > > > + * @parent:    SCMI pinctrl device
> > > > + *
> > > > + * Create a pinctrl-controlled gpio device
> > > > + *
> > > > + * Return:     0 on success, error code on failure
> > > > + */
> > > > +static int scmi_gpiochip_register(struct udevice *parent)
> > > > +{
> > > > +       ofnode node;
> > > > +       struct driver *drv;
> > > > +       struct udevice *gpio_dev;
> > > > +       int ret;
> > > > +
> > > > +       /* TODO: recovery if failed */
> > > > +       dev_for_each_subnode(node, parent) {
> > > > +               if (!ofnode_is_enabled(node))
> > > > +                       continue;
> > >
> > > Can we not rely on the normal driver model binding to bind these
> > > devices? Why does it need to be done manually here?
> >
> > First, please take a look at the cover letter.
> > In this RFC, I basically assume two patterns of DT bindings,
> > (A) and (B) in the cover letter (or sandbox's test.dts in patch#5).
> >
> > In (B), a DT node as a gpio device, which is essentially a child
> > of pinctrl device, is located *under* a pinctrl device. It need
> > to be probed manually as there is no implicit method to enumerate
> > it as a DM device automatically.
> 
> You could add a post_bind() method to the pinctrl uclass to call
> dm_scan_fdt_dev() as we do with TPM.

Okay, but in that case, defining "compatible" property will become
mandatory, while I invented (B) so that we don't need extra bindings.

Please note that no discussion started about the binding of gpio devices.

-Takahiro Akashi

> >
> > On the other hand, in (A), the same node can be put anywhere in a DT
> > as it contains a "compatible" property to identify itself.
> > So if we want to only support (A), scmi_gpiochip_register() and
> > scmi_pinctrl_bind() are not necessary.
> >
> > Since there is no discussion about bindings for GPIO managed by SCMI
> > pinctrl device yet on the kernel side, I have left two solutions
> > in this RFC.
> 
> 
> OK.
> 
> [..]
> 
> Regards,
> Simon

  reply	other threads:[~2023-09-11  5:38 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-06  2:40 [RFC 0/6] firmware: scmi: add SCMI pinctrl protocol support AKASHI Takahiro
2023-09-06  2:40 ` [RFC 1/6] firmware: scmi: fix protocol enumeration logic AKASHI Takahiro
2023-09-10 19:13   ` Simon Glass
2023-09-11  4:58     ` AKASHI Takahiro
2023-09-06  2:40 ` [RFC 2/6] firmware: scmi: add pinctrl protocol support AKASHI Takahiro
2023-09-06  2:40 ` [RFC 3/6] pinctrl: add scmi driver AKASHI Takahiro
2023-09-10 19:13   ` Simon Glass
2023-09-11  5:14     ` AKASHI Takahiro
2023-09-06  2:40 ` [RFC 4/6] gpio: add scmi driver based on pinctrl AKASHI Takahiro
2023-09-06 14:56   ` Michal Simek
2023-09-06 23:37     ` AKASHI Takahiro
2023-09-07 12:23   ` Simon Glass
2023-09-08  4:32     ` AKASHI Takahiro
2023-09-10 19:13       ` Simon Glass
2023-09-11  5:38         ` AKASHI Takahiro [this message]
2023-09-06  2:40 ` [RFC 5/6] firmware: scmi: add pseudo pinctrl protocol support on sandbox AKASHI Takahiro
2023-09-10 19:13   ` Simon Glass
2023-09-11  5:23     ` AKASHI Takahiro
2023-09-06  2:40 ` [RFC 6/6] test: dm: add SCMI pinctrl test AKASHI Takahiro
2023-09-10 19:13   ` Simon Glass
2023-09-11  5:47     ` AKASHI Takahiro
2023-09-22 18:27       ` Simon Glass
2023-09-06  3:09 ` [RFC 0/6] firmware: scmi: add SCMI pinctrl protocol support Fabio Estevam
2023-09-07  9:58   ` AKASHI Takahiro
2023-09-08 12:14     ` Peng Fan

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=ZP6nz+sZkNiB+7+v@octopus \
    --to=takahiro.akashi@linaro.org \
    --cc=Oleksii_Moisieiev@epam.com \
    --cc=etienne.carriere@st.com \
    --cc=linus.walleij@linaro.org \
    --cc=michal.simek@amd.com \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.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: 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