From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: "Stanley Chang[昌育德]" <stanley_chang@realtek.com>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] usb: dwc3: add Realtek DHC RTD SoC dwc3 glue layer driver
Date: Mon, 7 Aug 2023 23:56:42 +0000 [thread overview]
Message-ID: <20230807235636.mlos5tpeg5foymnz@synopsys.com> (raw)
In-Reply-To: <ae619edfcce545b78697c6bcdadfff27@realtek.com>
On Mon, Aug 07, 2023, Stanley Chang[昌育德] wrote:
> Hi Thinh,
>
> > > > > > > +static int dwc3_rtk_setup_role_switch(struct dwc3_rtk *rtk)
> > > > > >
> > > > > > Any reason why we're doing the role switch here and not what's
> > > > > > implemented from the core?
> > > > > >
> > > > > Because we have to set the usb 2.0 phy mode through
> > > > > switch_usb2_dr_mode
> > > > in the function dwc3_rtk_set_dr_mode.
> > > > > In fact, switch_dwc3_dr_mode will use the role switching
> > > > > implemented by
> > > > core.
> > > > >
> > > >
> > > > I don't think this is a good way to go about it. Do you (the glue
> > > > driver) create a role switch structure and register to the same role
> > > > switch device that the dwc3 core would register later? I did not
> > > > expect that to work at all.
> > > >
> > > In our application, this role switch in the glue driver works fine.
> >
> > Is the order of operation between the switch from the core vs the glue
> > determinate? Also, which operation should happen first? It's not clear how you
> > handle it here.
>
> We have a type c driver that first calls role switch in glue.
> The role switching function in glue will call the role switching function in core.
How do we know that? You're registering to the same switch device,
wouldn't the switch event notify the switch work in both the glue and
the core? Perhaps I'm missing something here, but is there some
mechanism that waits for the switch work from the glue to complete
before the core.
>
> Type c driver setting switch role function:
> |----> Set role in the glue
> |----> Set roles in the core
> |----> switch_usb2_dr_mode in glue
>
> > >
> > > > How about we create a couple ops callbacks to dwc3 structure. One to
> > > > initialize gadget and the other for host. Should any platform
> > > > specific device need some intialization before initializing the
> > > > specific role, we can invoke these callbacks.
> > > >
> > > > e.g.:
> > > >
> > > > struct dwc3_glue_ops {
> > > > int (*init_gadget)(struct dwc3 *dwc);
> > > > int (*init_host)(struct dwc3 *dwc); }
> > > >
> > > > struct dwc3 {
> > > > ..
> > > > const struct dwc3_glue_ops *ops;
> > > > }
> > > >
> > > >
> > > > static int dwc3_glue_init_gadget(struct dwc3 *dwc) {
> > > > if (!dwc->ops->init_gadget)
> > > > return 0;
> > > >
> > > > return dwc->ops->init_gadget(dwc); }
> > > >
> > > > static int dwc3_glue_init_host(struct dwc3 *dwc) {
> > > > if (!dwc->ops->init_host)
> > > > return 0;
> > > >
> > > > return dwc->ops->init_host(dwc); }
> > > >
> > > >
> > > > Your glue driver would implement these callbacks. In
> > > > dwc3_gadget_init() and dwc3_host_init(), we can call these callbacks
> > > > at start. I admit that this may not be the greatest solution since
> > > > it would require the glue driver to alloc and register a dwc3
> > > > platform device. But I think should be ok. If anyone else can chime in for
> > more idea, it'd be great.
> > >
> > >
> > > Thanks for your advice.
> > > Here is a solution. As you're concerned, it must register callbacks with the
> > core driver. It looks a bit complicated.
> > > I noticed the phy_set_mode api.
> > > Maybe I can try to move switch_usb2_dr_mode to phy driver.
> > >
> > > phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_HOST);
> > > phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_DEVICE);
> > >
> >
> > I'm concern if there are other unwanted side effects this may have to other
> > platforms.
>
>
> I didn't add any new phy_set_mode to dwc3/core.
> I mean use existing callback, as follows
> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v6.4.8/source/drivers/usb/dwc3/core.c*L203__;Iw!!A4F2R9G_pg!dOK1h9Z03CfmtwWlNePk-TiEdHQjaP8qMmY4BgMfYm0yTi5NThLqK_POOzdM89tSz2zDRkfGG9BSzb78zkLFhttxoefU5w$
>
Ah ok, this seems like a better option.
Thanks,
Thinh
next prev parent reply other threads:[~2023-08-07 23:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-01 9:25 [PATCH v2 1/2] usb: dwc3: add Realtek DHC RTD SoC dwc3 glue layer driver Stanley Chang
2023-08-01 9:25 ` [PATCH v2 2/2] dt-bindings: usb: dwc3: Add Realtek DHC RTD SoC DWC3 USB Stanley Chang
2023-08-02 1:14 ` [PATCH v2 1/2] usb: dwc3: add Realtek DHC RTD SoC dwc3 glue layer driver Thinh Nguyen
2023-08-02 5:27 ` Greg Kroah-Hartman
2023-08-02 23:03 ` Thinh Nguyen
2023-08-02 8:26 ` Stanley Chang[昌育德]
2023-08-03 0:04 ` Thinh Nguyen
2023-08-03 6:55 ` Stanley Chang[昌育德]
2023-08-03 23:11 ` Thinh Nguyen
2023-08-07 9:07 ` Stanley Chang[昌育德]
2023-08-07 23:56 ` Thinh Nguyen [this message]
2023-08-08 2:58 ` Stanley Chang[昌育德]
2023-08-08 23:37 ` Thinh Nguyen
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=20230807235636.mlos5tpeg5foymnz@synopsys.com \
--to=thinh.nguyen@synopsys.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=stanley_chang@realtek.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