From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Felipe Balbi <balbi@kernel.org>, linux-usb@vger.kernel.org
Cc: Greg KH <greg@kroah.com>, Joel Stanley <joel@jms.id.au>,
Andrew Jeffery <andrew@aj.id.au>
Subject: [v4,2/2] usb/gadget: Add driver for Aspeed SoC virtual hub
Date: Thu, 15 Mar 2018 08:03:49 +1100 [thread overview]
Message-ID: <1521061429.16434.139.camel@kernel.crashing.org> (raw)
On Wed, 2018-03-14 at 10:54 +0200, Felipe Balbi wrote:
> Hi,
>
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> > On Tue, 2018-03-13 at 09:35 +1100, Benjamin Herrenschmidt wrote:
> > > On Fri, 2018-03-09 at 11:20 +0200, Felipe Balbi wrote:
> > > >
> > > > > diff --git a/drivers/usb/gadget/udc/aspeed-vhub/core.c b/drivers/usb/gadget/udc/aspeed-vhub/core.c
> > > > > new file mode 100644
> > > > > index 000000000000..31ed2b6e241b
> > > > > --- /dev/null
> > > > > +++ b/drivers/usb/gadget/udc/aspeed-vhub/core.c
> > > > > @@ -0,0 +1,429 @@
> > > >
> > > > missing SPDX license identifier (all files)
> > >
> > > Ah yup, the driver predates me knowing about them, I'll fix.
> > >
> > > > > +static bool force_usb1 = false;
> > > > > +static bool no_dma_desc = false;
> > > > > +
> > > > > +module_param_named(force_usb1, force_usb1, bool, 0644);
> > > > > +MODULE_PARM_DESC(force_usb1, "Set to true to force to USB1 speed");
> > > > > +module_param_named(no_dma_desc, no_dma_desc, bool, 0644);
> > > > > +MODULE_PARM_DESC(no_dma_desc, "Set to true to disable use of DMA descriptors");
> > > >
> > > > module parameters? Sorry, but no.
> > >
> > > Why ? Any suggestion then for the two above ? They are mostly meant as
> > > diagnostic/debug features if something doesn't work (for example, the
> > > board has some sub-standard wiring making USB2 unreliable, or a driver
> > > bug with DMA descriptors).
> > >
> > > I can just take them out completely but it feels like module parameters
> > > are the right thing to do in that specific case.
> >
> > I've taken out the second one, it isn't that useful. I've left in the
> > first one however. This is the right thing to do. That setting (force
> > USB1 mode) needs to be applied as soon as the vhub gets initialized
> > at driver load time, regardless of what gadgets might be attached to
> > it later on.
>
> we have DT binding for passing maximum speed. A module parameter is
> global, whereas DT binding (or device property) is per-device.
Hrm, ok I could do that. Less practical for diagnostics, you can't
always easily change the DT (or tell a user to do so over email), but
it would work.
> > > > > +void ast_vhub_init_hw(struct ast_vhub *vhub)
> > > > > +{
> > > > > + u32 ctrl;
> > > > > +
> > > > > + UDCDBG(vhub,"(Re)Starting HW ...\n");
> > > > > +
> > > > > + /* Enable PHY */
> > > > > + ctrl = VHUB_CTRL_PHY_CLK |
> > > > > + VHUB_CTRL_PHY_RESET_DIS;
> > > > > +
> > > > > +#if 0 /*
> > > > > + * This causes registers to become inaccessible during
> > > > > + * suspend. Need to figure out how to bring the controller
> > > > > + * back into life to issue a wakeup.
> > > > > + */
> > > > > + ctrl |= VHUB_CTRL_CLK_STOP_SUSPEND;
> > > > > +#endif
> > > >
> > > > no commented code.
> > >
> > > Why ? This documents a HW issue ... ie, one would normally want to set
> > > this bit but you can't because in practice you can't bring the HW back
> > > short of doing a full reset.
> >
> > So I don't want to lose the "HW documentation" part of that, I've
> > turned the above into a comment:
> >
> > /*
> > * We do *NOT* set the VHUB_CTRL_CLK_STOP_SUSPEND bit
> > * to stop the logic clock during suspend because
> > * it causes the registers to become inaccessible and
> > * we haven't yet figured out a good wayt to bring the
> > * controller back into life to issue a wakeup.
> > */
>
> this is good
>
> > It will be in v5 when I post it (I'll test a bit more and wait
> > for other replies from you, if I don't hear back I'll probably send
> > it by end of week or next week).
>
> okay
>
> > > > > + /*
> > > > > + * Set some ISO & split control bits according to Aspeed
> > > > > + * recommendation
> > > > > + *
> > > > > + * VHUB_CTRL_ISO_RSP_CTRL: When set tells the HW to respond
> > > > > + * with 0 bytes data packet to ISO IN endpoints when no data
> > > > > + * is available.
> > > > > + *
> > > > > + * VHUB_CTRL_SPLIT_IN: This makes a SOF complete a split IN
> > > > > + * transaction.
> > > > > + */
> > > > > + ctrl |= VHUB_CTRL_ISO_RSP_CTRL | VHUB_CTRL_SPLIT_IN;
> > > > > + writel(ctrl, vhub->regs + AST_VHUB_CTRL);
> > > > > + udelay(1);
> > > > > +
> > > > > + /* Set descriptor ring size */
> > > > > +#if AST_VHUB_DESCS_COUNT == 256
> > > > > + ctrl |= VHUB_CTRL_LONG_DESC;
> > > > > + writel(ctrl, vhub->regs + AST_VHUB_CTRL);
> > > > > +#elif AST_VHUB_DESCS_COUNT != 32
> > > > > + #error Invalid AST_VHUB_DESCS_COUNT
> > > > > +#endif
> > > >
> > > > find a better way for this. No ifdefs
> > >
> > > Ugh ? What's that rule ? I could do a module parameter but you hate
> > > that too and honestly keeping that an ifdef makes things easier. It's
> > > not meant to be changed unless a hardware or performance issues shows
> > > up, I wanted to keep both mode of operations available.
> >
> > Oh well, I've just made it an if () and kept the #define, and the
> > #error turns into a BUILD_BUG_ON(). Same principle... but I don't
> > like those arbitrary "rules", I try to avoid them for things I
> > maintain (granted, not much anymore these days).
>
> they're not arbitrary, actually, and have been around for a long time ;-)
>
> > Do you have more comments for the rest of the driver or that's it ?
>
> so far, that's it.
Ok. I'll re-send.
Thanks !
Cheers,
Ben.
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next reply other threads:[~2018-03-14 21:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-14 21:03 Benjamin Herrenschmidt [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-03-20 4:36 [v4,2/2] usb/gadget: Add driver for Aspeed SoC virtual hub Benjamin Herrenschmidt
2018-03-17 13:50 Alan Stern
2018-03-17 0:40 Benjamin Herrenschmidt
2018-03-17 0:38 Benjamin Herrenschmidt
2018-03-17 0:29 Benjamin Herrenschmidt
2018-03-16 20:56 Alan Stern
2018-03-16 7:23 Felipe Balbi
2018-03-16 0:40 Benjamin Herrenschmidt
2018-03-14 8:54 Felipe Balbi
2018-03-14 3:53 Benjamin Herrenschmidt
2018-03-12 22:35 Benjamin Herrenschmidt
2018-03-09 9:20 Felipe Balbi
2018-01-26 0:01 Benjamin Herrenschmidt
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=1521061429.16434.139.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=andrew@aj.id.au \
--cc=balbi@kernel.org \
--cc=greg@kroah.com \
--cc=joel@jms.id.au \
--cc=linux-usb@vger.kernel.org \
/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).