Dear Alan Stern, > On Tue, 15 May 2012, Marek Vasut wrote: > > > I'm not sure I really understand the purpose of all this. Why does the > > > PHY driver need to know about every IRQ the host driver receives? > > > > I use the .notify_event in ci13xxx to filter out this kind of event, read > > the EHCI host register and then notify the PHY about the state of USB > > PCD. > > Which state changes are you interested in? The PCD bit getting flipped. > > Could the ehci-hcd driver include a hook to call the appropriate PHY > driver at the right times? But that sounds like quite unsystematic hack. I'd like to avoid poluting the code only because one stupid controller needs it. > > > And why can't it call the PHY driver directly? > > > > I don't want to pull any PHY code into the ci13xxx host driver, it's > > completely separate hardware. > > You don't have to pull code from anywhere. Just add a hook for a > method call at the appropriate place. > > Really, in the end this will depend on how the PHY drivers get > integrated with the rest of the USB stack. There will be controllers > with no kernel-visible PHY, controllers with a single PHY, and maybe > controllers with a separate PHY for each port. How can we describe > these settings in a way that lets the HCD provide the PHY driver with > the information it needs, using minimal overhead? Actually, check here: http://www.spinics.net/lists/arm-kernel/msg175154.html http://www.spinics.net/lists/arm-kernel/msg175152.html The first link is the notifier implementation in the ci13xxx binding code. It simply reads the STS register, filters out everything but the PCD bit and calls the PHY notify. Then the second link shows how this is implemented in the MXS PHY code. Check mxs_usb_phy_notify() function there. It's really quick. > Somehow, I don't think that filtering every interrupt through one or > more PHY drivers is the best approach. I'd gladly find a better solution, I'm open to suggestions. So please, guide me :) > > Alan Stern Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
