From: Sam Edwards <cfsworks@gmail.com>
To: Andre Przywara <andre.przywara@arm.com>
Cc: u-boot@lists.denx.de, Jagan Teki <jagan@amarulasolutions.com>,
Marek Vasut <marex@denx.de>, John Watts <contact@jookia.org>
Subject: Re: [PATCH v2 2/2] usb: musb-new: sunxi: make compatible with UDC/DM gadget model
Date: Thu, 27 Jun 2024 17:25:57 -0600 [thread overview]
Message-ID: <9716fa71-d010-4444-979f-d120c558426c@gmail.com> (raw)
In-Reply-To: <20240627160639.2353fd1e@donnerap.manchester.arm.com>
On 6/27/24 09:06, Andre Przywara wrote:
> On Thu, 8 Jun 2023 13:56:31 -0600
> Sam Edwards <cfsworks@gmail.com> wrote:
>
> Hi,
>
> John asked me have a look at this.
Hi Andre, it's good to hear from you again,
I'd first like to make sure you're aware that the date on this patch is
June *2023,* not June 2024. It's possible things have changed
substantially in the past year. I do not know if this patch is still a
necessity; though if John is nudging about it, it probably is.
>
>> Since many sunxi boards do not implement a `board_usb_init`, it's
>
> I am confused, what has this have to do with gadget support? *No* sunxi
> board build provides board_usb_init(), but apparently this works fine for
> now.
> I am all for this converting to DM part, but the rationale seems a bit
> off.
For context, board_usb_init() is (was?) the non-DM entry point for USB
functionality; it is (was?) *the* implementation of
usb_gadget_initialize() when !DM_USB_GADGET.
>
> Also can you give some reason for this patch? What does this fix or
> improve? "it's better" is a bit thin, "complying with DM" would already be
> sufficient, but maybe there is more?
Eh, yeah, "better" is something of a question-begging word isn't it? :)
The main point is to be compatible with DM's view of UDC, which as you
said is a worthy goal in itself. It's "better" because this allows using
DM's all-purpose implementation of usb_gadget_initialize(), which is
(was?) necessary for those targets lacking board_usb_init().
>
>> better if we just make the sunxi USB driver compatible with the
>> DM gadget model, as many other musb-new variants already are.
>>
>> This change has been verified working on a T113s.
>>
>> Signed-off-by: Sam Edwards <CFSworks@gmail.com>
>> ---
>> drivers/usb/musb-new/sunxi.c | 50 +++++++++++++++++++++++-------------
>> 1 file changed, 32 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
>> index 510b254f7d..6658cd995d 100644
>> --- a/drivers/usb/musb-new/sunxi.c
>> +++ b/drivers/usb/musb-new/sunxi.c
>> @@ -444,6 +444,16 @@ static struct musb_hdrc_config musb_config_h3 = {
>> .ram_bits = SUNXI_MUSB_RAM_BITS,
>> };
>>
>> +#if CONFIG_IS_ENABLED(DM_USB_GADGET)
>
> Please no more #ifdef's. Is there any reason to *not* force
> DM_USB_GADGET now, for all sunxi boards, in Kconfig?
> Either by "select"ing it in the USB Kconfig, or in arch/arm/Kconfig, like
> other platforms do.
> Then you don't need to care about the !DM_USB_GADGET definition of this
> function and can drop the #ifdef.
I wouldn't be the one to ask. I can't think of any such reason myself.
But to me it sounds like since *no sunxi board provides
board_usb_init()* the only way USB gadgets *could* work is with
DM_USB_GADGET? That'd be reason enough to force it.
>
>> +int dm_usb_gadget_handle_interrupts(struct udevice *dev) {
>
> coding style
Sentence fragments are harder to understand. I am assuming you are
saying, "Please put the opening '{' on its own line."
>
>> + struct sunxi_glue *glue = dev_get_priv(dev);
>> + struct musb_host_data *host = &glue->mdata;
>> +
>> + host->host->isr(0, host->host);
>> + return 0;
>> +}
>> +#endif
>> +
>> static int musb_usb_probe(struct udevice *dev)
>> {
>> struct sunxi_glue *glue = dev_get_priv(dev);
>> @@ -452,10 +462,6 @@ static int musb_usb_probe(struct udevice *dev)
>> void *base = dev_read_addr_ptr(dev);
>> int ret;
>>
>> -#ifdef CONFIG_USB_MUSB_HOST
>> - struct usb_bus_priv *priv = dev_get_uclass_priv(dev);
>> -#endif
>> -
>> if (!base)
>> return -EINVAL;
>>
>> @@ -486,23 +492,31 @@ static int musb_usb_probe(struct udevice *dev)
>> pdata.platform_ops = &sunxi_musb_ops;
>> pdata.config = glue->cfg->config;
>>
>> -#ifdef CONFIG_USB_MUSB_HOST
>> - priv->desc_before_addr = true;
>> + if (IS_ENABLED(CONFIG_USB_MUSB_HOST)) {
>> + struct usb_bus_priv *priv = dev_get_uclass_priv(dev);
>> + priv->desc_before_addr = true;
>>
>> - pdata.mode = MUSB_HOST;
>> - host->host = musb_init_controller(&pdata, &glue->dev, base);
>> - if (!host->host)
>> - return -EIO;
>> + pdata.mode = MUSB_HOST;
>> + host->host = musb_init_controller(&pdata, &glue->dev, base);
>> + if (!host->host)
>> + return -EIO;
>>
>> - return musb_lowlevel_init(host);
>> -#else
>> - pdata.mode = MUSB_PERIPHERAL;
>> - host->host = musb_register(&pdata, &glue->dev, base);
>> - if (IS_ERR_OR_NULL(host->host))
>> - return -EIO;
>> + return musb_lowlevel_init(host);
>> + } else if (CONFIG_IS_ENABLED(DM_USB_GADGET)) {
>> + pdata.mode = MUSB_PERIPHERAL;
>> + host->host = musb_init_controller(&pdata, &glue->dev, base);
>> + if (!host->host)
>> + return -EIO;
>>
>> - return 0;
>> -#endif
>> + return usb_add_gadget_udc(&glue->dev, &host->host->g);
>> + } else {
>> + pdata.mode = MUSB_PERIPHERAL;
>> + host->host = musb_register(&pdata, &glue->dev, base);
>> + if (IS_ERR_OR_NULL(host->host))
>> + return -EIO;
>> +
>> + return 0;
>> + }
>
> That looks like a good cleanup! Just need to test it briefly, but it seems
> like the gist of this patch is fine.
I think it would be wise to test it a little better than "briefly" given
the age of the patch. I'm not well-equipped to do any testing myself
right now or I'd volunteer.
>
> Cheers,
> Andre
Likewise,
Sam
>
>
>> }
>>
>> static int musb_usb_remove(struct udevice *dev)
>
next prev parent reply other threads:[~2024-06-27 23:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-08 19:56 [PATCH v2 0/2] sunxi, usb: UDC/DM gadget model support Sam Edwards
2023-06-08 19:56 ` [PATCH v2 1/2] usb: musb-new: sunxi: remove unwanted printfs Sam Edwards
2023-06-08 19:56 ` [PATCH v2 2/2] usb: musb-new: sunxi: make compatible with UDC/DM gadget model Sam Edwards
2024-06-27 15:06 ` Andre Przywara
2024-06-27 23:25 ` Sam Edwards [this message]
2024-06-28 15:17 ` Andre Przywara
2024-06-28 16:22 ` John Watts
2024-07-14 22:23 ` Andre Przywara
2024-04-11 6:45 ` [PATCH v2 0/2] sunxi, usb: UDC/DM gadget model support John Watts
[not found] ` <CAH5Ym4gEJi693VRtrdgQAUmqQuQCCmQ1ASYJofQw92M6nBHyXA@mail.gmail.com>
[not found] ` <ZheThnKWQJ3Zah-t@titan>
2024-04-11 21:53 ` Sam Edwards
2024-04-11 23:34 ` John Watts
2024-04-16 12:46 ` John Watts
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=9716fa71-d010-4444-979f-d120c558426c@gmail.com \
--to=cfsworks@gmail.com \
--cc=andre.przywara@arm.com \
--cc=contact@jookia.org \
--cc=jagan@amarulasolutions.com \
--cc=marex@denx.de \
--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