by Maxime Coquelin

[permalink] [raw]

Subject: Re: [PATCH v2 3/3] MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture

On 07/08/2014 09:53 AM, Lee Jones wrote:
> On Tue, 08 Jul 2014, Maxime Coquelin wrote:
>> On 07/05/2014 08:25 AM, Peter Griffin wrote:
>>> Signed-off-by: Peter Griffin <[email protected]>
>>
>> Acked-by: Maxime Coquelin <[email protected]>
>
> Maxime,
> Once Acked by Felipe, I think this should go in via your tree to
> avoid conflicts with other ARM/STI ARCHITECTURE additions.

Ok

>
>>> ---
>>> MAINTAINERS | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 702ca10..269ad3b 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -1325,6 +1325,7 @@ F: drivers/pinctrl/pinctrl-st.c
>>> F: drivers/media/rc/st_rc.c
>>> F: drivers/i2c/busses/i2c-st.c
>>> F: drivers/tty/serial/st-asc.c
>>> +F: drivers/usb/dwc3/dwc3-st.c
>>>
>>> ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT
>>> M: Lennert Buytenhek <[email protected]>
>>>
>

2014-07-10 13:27:55

Hi,

On Tue, Jul 22, 2014 at 10:18:00AM +0100, Peter Griffin wrote:
> > > +static inline u32 st_dwc3_readl(void __iomem *base, u32 offset)
> > > +{
> > > + return readl_relaxed(base + offset);
> > > +}
> > > +
> > > +static inline void st_dwc3_writel(void __iomem *base, u32 offset, u32 value)
> > > +{
> > > + writel_relaxed(value, base + offset);
> > > +}
> >
> > Why are these being abstracted?
> >
> > Just use {read,write}l_relaxed() directly.
>
> Ok, unabstracted in v3

no, no... all other glues add their own local helpers for register
access. This is good for tracing, it's very easy to add a tracepoint to
this sort of function and get very low overhead tracing of every
register access.

> > > + if (dwc3_data->drd_device_conf)
> > > + val |= USB_SET_PORT_DEVICE;
> > > + else
> > > + val &= USB_HOST_DEFAULT_MASK;
> > > +
> > > + return regmap_write(dwc3_data->regmap, dwc3_data->syscfg_reg_off, val);
> > > +}
> > > +
> > > +/**
> > > + * st_dwc3_init: init the controller via glue logic
> > > + * @dwc3_data: driver private structure
> > > + */
> > > +static void st_dwc3_init(struct st_dwc3 *dwc3_data)
> > > +{
> > > + u32 reg = st_dwc3_readl(dwc3_data->glue_base, USB2_CLKRST_CTRL);
> > > +
> > > + reg |= aux_clk_en(1) | ext_cfg_reset_n(1) | xhci_revision(1);
> > > + reg &= ~sw_pipew_reset_n(1);
> >
> > 1? Better to add defines for these magic numbers. What is 1 anyway?
>
> They are just bit setting macros, I've converted them over to use BIT macro now,
> so it no longer takes a parameter.

the macros are better, but make them upper case as everybody else.

> > > + st_dwc3_writel(dwc3_data->glue_base, USB2_CLKRST_CTRL, reg);
> > > +
> > > + reg = st_dwc3_readl(dwc3_data->glue_base, USB2_VBUS_MNGMNT_SEL1);
> > > + reg |= SEL_OVERRIDE_VBUSVALID(1) | SEL_OVERRIDE_POWERPRESENT(1) |
> > > + SEL_OVERRIDE_BVALID(1);
> > > + st_dwc3_writel(dwc3_data->glue_base, USB2_VBUS_MNGMNT_SEL1, reg);
> > > + udelay(100);
> >
> > Why 100?
>
> I've asked ST how this value was derirved and why. It came from validation.
> The docs don't mention that it is necessary, and removing it
> seems to have no ill effects. So I've removed this udelay in v3.

make sure to test with many, many iterations just to make sure.

> > > + reg = st_dwc3_readl(dwc3_data->glue_base, USB2_CLKRST_CTRL);
> > > + reg |= sw_pipew_reset_n(1);
> > > + st_dwc3_writel(dwc3_data->glue_base, USB2_CLKRST_CTRL, reg);
> > > +}
> > > +
> > > +static void st_dwc3_dt_get_pdata(struct platform_device *pdev,
> > > + struct st_dwc3 *dwc3_data)
> > > +{
> > > + struct device_node *np = pdev->dev.of_node;
> > > +
> > > + dwc3_data->drd_device_conf =
> > > + of_property_read_bool(np, "st,dwc3-drd-device");
> >
> > This requires a DT Ack.
>
> Ok. Do the DT folks have any comment on this?

look at the child's dr-mode property instead of adding your own.

> > > + dwc3_data->glue_base = devm_request_and_ioremap(dev, res);

use devm_ioremap_resource()

> > > + regmap = syscon_regmap_lookup_by_phandle(node, "st,syscfg");
> > > + if (IS_ERR(regmap))
> > > + return PTR_ERR(regmap);
> > > +
> > > + dwc3 = platform_device_alloc("st-dwc3", PLATFORM_DEVID_AUTO);
> > > + if (!dwc3) {
> > > + dev_err(&pdev->dev, "couldn't allocate dwc3 device\n");
> > > + return -ENOMEM;
> > > + }
> >
> > I'm confused. What is this doing? Isn't this the DWC3 driver, which
> > already had a platform device structure associated to it? Perhaps a
> > small ASCII diagram describing the layers might be useful.
>
> Your right, this was wrong. It was some legacy code which is
> unnecessary and I've removed this in v3.

if you're going for DT, why don't you create the parent and the child
from DT as omap/exynos/qcom are doing ?

> > > + dma_set_coherent_mask(&dwc3->dev, dev->coherent_dma_mask);
> > > +
> > > + dwc3->dev.parent = &pdev->dev;
> > > + dwc3->dev.dma_mask = pdev->dev.dma_mask;
> > > + dwc3->dev.dma_parms = pdev->dev.dma_parms;

stick to DT device creation. Look into dwc3-omap.c

> > > +static int st_dwc3_remove(struct platform_device *pdev)
> > > +{
> > > + struct st_dwc3 *dwc3_data = platform_get_drvdata(pdev);
> > > +
> > > + platform_device_unregister(dwc3_data->dwc3);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +#ifdef CONFIG_PM_SLEEP
> > > +static int st_dwc3_suspend(struct device *dev)
> > > +{
> > > + struct st_dwc3 *dwc3_data = dev_get_drvdata(dev);
> > > +
> > > + reset_control_assert(dwc3_data->rstc_pwrdn);
> > > +
> > > + pinctrl_pm_select_sleep_state(dev);

pinctrl will select sleep and default states automatically for you.

--
balbi

Attachments:

(No filename) (4.47 kB)
signature.asc (819.00 B)
Digital signature Download all attachments

2014-07-22 15:45:14

by Lee Jones

[permalink] [raw]

Subject: Re: [PATCH v2 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC

> > > > +static void st_dwc3_init(struct st_dwc3 *dwc3_data)
> > > > +{
> > > > + u32 reg = st_dwc3_readl(dwc3_data->glue_base, USB2_CLKRST_CTRL);
> > > > +
> > > > + reg |= aux_clk_en(1) | ext_cfg_reset_n(1) | xhci_revision(1);
> > > > + reg &= ~sw_pipew_reset_n(1);
> > >
> > > 1? Better to add defines for these magic numbers. What is 1 anyway?
> >
> > They are just bit setting macros, I've converted them over to use BIT macro now,
> > so it no longer takes a parameter.
>
> the macros are better, but make them upper case as everybody else.

When you say that the macros are better, what do you mean?

Defines do the job in a manner which is a great deal cleaner:

#define AUX_CLK_EN BIT(0)
#define SW_PIPEW_RESET_N BIT(4)
#define EXT_CFG_RESET_N BIT(8)
#define XHCI_REVISION BIT(12)

reg = AUX_CLK_EN | SW_PIPEW_RESET_N | XHCI_REVISION;
reg &= ~SW_PIPEW_RESET_N

--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

2014-07-22 15:52:00

Hi Felipe,

Thanks for reviewing, see my comments inline: -

> > > Just use {read,write}l_relaxed() directly.
> >
> > Ok, unabstracted in v3
>
> no, no... all other glues add their own local helpers for register
> access. This is good for tracing, it's very easy to add a tracepoint to
> this sort of function and get very low overhead tracing of every
> register access.

I've put the IO accessors back in for V3

> > They are just bit setting macros, I've converted them over to use BIT macro now,
> > so it no longer takes a parameter.
>
> the macros are better, but make them upper case as everybody else.

Fixed in v3.

> > I've asked ST how this value was derirved and why. It came from validation.
> > The docs don't mention that it is necessary, and removing it
> > seems to have no ill effects. So I've removed this udelay in v3.
>
> make sure to test with many, many iterations just to make sure.

Yes will do, I've been booting my board all day, and so far no failures.

> > Ok. Do the DT folks have any comment on this?
>
> look at the child's dr-mode property instead of adding your own.

Thanks for the hint, now using dr-mode binding in V3 :-)

>
> > > > + dwc3_data->glue_base = devm_request_and_ioremap(dev, res);
>
> use devm_ioremap_resource()

Fixed in V3

> > Your right, this was wrong. It was some legacy code which is
> > unnecessary and I've removed this in v3.
>
> if you're going for DT, why don't you create the parent and the child
> from DT as omap/exynos/qcom are doing ?

Now creating parent and child from DT like OMAP in v3

> > > > + reset_control_assert(dwc3_data->rstc_pwrdn);
> > > > +
> > > > + pinctrl_pm_select_sleep_state(dev);
>
> pinctrl will select sleep and default states automatically for you.

I've left this in v3, as greping around I couldn't see how that could happen automatically.

Also I just double checked with linusw on irc who confirmed that the only state which is
ever auto-selected is "default". All other states, as well as going back to default
state need to be explicitly called.

Hope thats ok.

regards,

Peter.