On Fri, Aug 10, 2012 at 11:46 AM, Felipe Balbi <balbi@xxxxxx> wrote: > HI, > > On Fri, Aug 10, 2012 at 11:17:29AM +0530, Praveen Paneri wrote: >> On Fri, Aug 10, 2012 at 7:03 AM, Joonyoung Shim <jy0922.shim@xxxxxxxxxxx> wrote: >> > Hi, Praveen. >> > >> > >> > On 08/08/2012 04:40 PM, Praveen Paneri wrote: >> >> >> >> Changes from v2: >> >> Changed the driver filenames to samsung-usbphy >> >> Changed 's3c' to 'samsung' for platform device as well as platform data >> >> Moved platform data structure to a separate file >> >> Rectified coding style related errors >> >> >> >> Changes from v1: >> >> Rebased patches to latest usb-next branch >> >> Changed the name 'sec_usbphy' to 'samsung_usbphy' >> >> >> >> This patch set introduces a phy driver for samsung SoCs. It uses the >> >> existing >> >> transceiver infrastructure to provide phy control functions. Use of this >> >> driver >> >> can be extended for usb host phy as well. >> > >> > >> > How can you support usb host phy? I cannot choose to use which phy when >> > call init or shutdown of phy at current phy framework. > > correct. Curretly that's not supported. We are trying to come up with > proper DeviceTree bindings to allow that. Kishon has been working on > providing devm_usb_get_phy_by_phandle() would should help achieving what > you need. > >> If you are talking about choosing between PHY0 (for device) and PHY1 >> (for host), I think you can make use of the flags available in usb_phy >> to pass that information to phy driver and that can be handled there. > > I rather you didn't do it that way. Those flags are used to pass > features to the PHY. See drivers/usb/otg/ulpi.c, for instance. > >> This is just one way I have successfully implement two different phy >> control. There might be a better way to do that. > > I guess using DT phandles is the way to go here. off-course! That is why I haven't included host support as of now. Praveen > > -- > balbi -- 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
 |