On Tue, Aug 02, 2011 at 02:05:46PM +0300, Heikki Krogerus wrote: > On Tue, Aug 02, 2011 at 11:44:46AM +0300, Felipe Balbi wrote: > > On Tue, Aug 02, 2011 at 10:28:21AM +0300, Heikki Krogerus wrote: > > > On Mon, Aug 01, 2011 at 05:35:46PM +0300, Felipe Balbi wrote: > > > > I would start by splitting <linux/usb/otg.h> into things which are > > > > really otg specific and things are only related to transceivers... > > > > > > Well.. I though I did, with the new struct otg and struct > > > usb_transceiver. The phy utility does not have much, and can be part > > > of <linux/usb/otg.h> if you like. > > > > my point is that you shouldn't add new stuff when there's already code > > in place to do that. So instead of adding a new struct usb_transceiver, > > just rename the one we have in place ;-) > > OK. I understand your point. I'll do it like that then. Just to be > sure, do I still introduce a new structure for otg already? The one > where we move all the otg specific stuff? Or do you think we should > first only change the name and add the state machine to it? I didn't mention adding a new structure for OTG, I said a header ;-) otg.h should be OTG-specific, but clearly, USB Transceivers aren't OTG-specific ;-) > The state machine is the thing that I feel we really should have. If > we only add it to the xceiv structure, how do we force everybody to > start using it? well, then add the state machine and convert the current users ;-) > > > > only then I would start adding the PHY layer. Also, keep in mind that > > > > this will be a gigantic amount of work and all drivers in mainline need > > > > to be changed :-( > > > > > > ..This is why I decided it's better to keep the existing > > > otg_transceiver unchanged, so there will be plenty of time for all the > > > drivers to be ported to the new utility. > > > > I don't think it's worth doing that, it won't push people to fix up > > what's already there for ages. > > OK. I'm fine with doing it like this if every one agrees. I think your > point also answers to my question above, right? > > Did you have time to review the code? Do you think the idea about > USB charging is OK? I'm trying to avoid the need to rely on the > notifiers. I think an atomic notifier is a must WRT charging. Remember that we might (more like _will_) have multiple different and unrelated ICs handling different parts of the Charging stage. Also keep in mind that we want Link to stay off until we know Transceiver is done with charger detection. We, also, need to tell some chip (in some designs it will be inside PMIC, in others it's an unrelated chip, or multiple) the bMaxPower field from our chosen configuration. We need to keep track of which port we're connected to (SDP, CDP, DCP) and handle the situation of connected to a HUB Charger which is not connected to a host at all, and suspend, resume, etc... So, it's a big problem in hand and I think an atomic notifier is the easiest way to have multiple different chips doing what they must do and telling each other about what's going on. Having certain agreed functions to be called when this or that happens isn't flexible enough IMHO. HW engineers will do funny/fuzzy things and we shall cope with them :-s -- balbi
Attachment:
signature.asc
Description: Digital signature
