Hi, On Friday 12 of July 2013 09:48:54 Jingoo Han wrote: > On Friday, July 12, 2013 6:46 AM, Julius Werner wrote: > > Hi Jingoo, > > > > Yeah, I followed that discussion back then, but it seems to have > > stalled a little (at least the HSIC patches haven't been picked up in > > any kernel.org repo yet to my knowledge). > > > > The problem is that I think these approaches cannot work reliably. I > > agree that it would be nice to control the HSIC device from its own > > driver, and have spent quite some time playing around with the > > usb/misc/usb3503.c driver to try to make this work... but there's a > > timing dependency here that you just can't model correctly with > > independent drivers. > > > > If the HSIC device is already active during boot (e.g. because it was > > used by firmware), there's always a chance that the USB stack will > > come up before the driver that resets it does. The device will be > > enumerated as normal, and when the other driver later pulls the reset > > signal the USB stack will not notice because there is no real > > disconnect detection on HSIC. Only when you eventually try to send > > another transfer to the device will you start to get timeouts, and the > > newly reset device will not be able to reenumerate because the host > > never asks it to. > > > > I really don't see how you could solve this without putting some kind > > of synchronization mechanism in the USB drivers. So this leaves > > ehci-s5p and phy-samsung-usb2 as the only possible places, and I chose > > the latter since all the host-side HSIC initialization is also there > > already. I think if you think of it as "reset whatever is on the other > > side of this PHY", it's okay to put it as an optional feature into the > > PHY driver. > > CC'ed Tomasz Figa, Dongjin Kim, Yulgon Kim > > > Hi Tomasz, Dongjin, > > Julius Werner wants to put 'SMSC 3503 hub reset on Arndale board' > to 'phy-samsung-usb*.c' files, because there is a timing dependency > above mentioned. > The following is the original patch sent by Julius Werner two day ago. > (http://www.spinics.net/lists/linux-samsung-soc/msg20250.html) Well, I think this is simply broken. Following are the reasons why I think so: a) you can use the smsc3503 chip on any USB/HSIC controller and with any USB/HSIC PHY, so you would have to add such reset GPIO to _every_ PHY or controller driver, b) you might want to use other USB/HSIC hubs like this one that requires some initialization sequence, other than just toggling a GPIO, so you would have to add cases for all of those hubs or other chips in _every_ PHY or controller driver. > Previously, Olof mentioned that 'drivers/platform/arm/' would be used. > (http://patches.linaro.org/16856/) > > Also, another way was mentioned by Fabio Estevam, using > 'drivers/reset/gpio-reset.c' which is not merged yet. > (http://permalink.gmane.org/gmane.linux.drivers.devicetree/36830) > > I think that 'phy-samsung-usb*.c' files are not a good place. > However, Julius Werner's comment looks reasonable enough. I can see this problem almost equivalent to the problem with on-board WLAN adapters connected using SDIO. Those adapters require some kind of power on sequence before they can be enumerated using standard MMC/SDIO mechanisms and so does this USB/HSIC hub. So basically this is a thing that we should consider on a more generic level, not just for this particular single chip. CCing some extra people to increase chance of getting more opinions on this. Best regards, Tomasz -- 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
 |