Hi Kishon,
On Fri, Feb 1, 2013 at 10:51 AM, kishon <kis...@ti.com> wrote:
> Hi,
>
>
> On Thursday 31 January 2013 09:08 PM, Felipe Balbi wrote:
>>
>> On Thu, Jan 31, 2013 at 09:00:37PM +0530, Vivek Gautam wrote:
>>>
>>> Hi Felipe,
>>>
>>>
>>> On Thu, Jan 31, 2013 at 8:55 PM, Felipe Balbi <ba...@ti.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Thu, Jan 31, 2013 at 08:53:27PM +0530, Vivek Gautam wrote:
>>>>>>>
>>>>>>> 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. :-(
>
>
> You can do something like this
>
> static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
>
> static int dwc3_exynos_set_dmamask(struct device *dev, void *c)
> {
> dev->dma_mask = &dwc3_exynos_dma_mask;
>
> return 0;
> }
>
> And in your probe after of_platform_populate, you can add
>
> device_for_each_child(&pdev->dev, NULL, dwc3_exynos_set_dmamask);
>
> Here pdev is the platform device of dwc3-exynos. By this way all the
> children of dwc3-exynos will have dma_mask set to the required value.
>
Nice idea, thanks :-)
hmm.. so i can patch this now, and get things working ;-)
> I'm not sure if there is any other better way to achieve the same (without
> patching of.c ;-))
>
--
Thanks & Regards
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
