Re: [PATCH RFC] usb: dwc3: Get PHY from platform specific dwc3 dt node.

[Vivek Gautam]

Hi Kishon,


On Thu, Jan 31, 2013 at 5:04 PM, kishon <kishon@xxxxxx> wrote:
> Hi,
>

Thanks for your quick help.

>
> On Thursday 31 January 2013 04:50 PM, Vivek Gautam wrote:
>>
>> With device tree support in place for dwc3-core layer,
>> it gets PHY from "synopsis-dwc3" node.
>> Some controllers may not have separate memory maps and interrupts
>> for dwc3 core and platform glue layers. In such case only glue
>> layer's node will exist.
>
>
> Not really. As long as you have dwc3 core as a separate device, you can add
> a node for it.
> Just that the glue should create a device for dwc3 core using
> of_platform_populate.(You can have a look at drivers/usb/dwc3/dwc3-omap.c in
> usb-next)
>

Right, we should be doing this way.

>> Moreover, SoCs having multiple dwc3 controllers will have multiple
>> PHYs, which eventually be added using usb_add_phy_dev(), and not
>> using usb_add_phy(). So each dwc3 controller won't be able to
>> get PHYs by simply calling devm_usb_get_phy() also.
>
> No. We have added usb_get_phy_dev() for that purpose in the case of non-dt.
> I think, instead you can have a patch to use devm_usb_get_phy_dev() here and
> in exynos platform specific code use usb_bind_phy() to bind the phy and
> controller till you change it to dt.
>

We have dt support for dwc3-exynos, in such case we should go ahead with
of_platform_populate(), right ?
But if when i use of_platform_populate() i will not be able to set
dma_mask to dwc3->dev. :-(
And setting it in dwc3_probe() won't be good idea, isn't it ?

>> In such cases, dwc3 should expect PHYs from its parent's node.
>
> NAK.
>
> Thanks
> Kishon
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks & Regards
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/