On Wed, Aug 03, 2011 at 10:19:12AM +0300, Heikki Krogerus wrote: > On Wed, Aug 03, 2011 at 12:05:44AM +0300, Felipe Balbi wrote: > > > 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 ;-) > > Now who's the sarcastic one. > > Let me ask you this, just to make sure. Do you agree that having a > common state machine is a good thing? Instead of embedding it into > every driver, the utility would provide it? > > > 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 > > Nobody is removing the notifiers? If there is truly such a fuzzy > platform that simply has to have customized way of handling charging > then by all means, use them. > > About the parts involved. In USB side you have the contoller, > transceiver and the charger detection, right? The charging side is > handled by battery drivers or chargers like BQ, or some proprietary > user space magic. Am I correct so far? > > Now _everything_ needs a handle to otg_transceiver if we want to use > the notifiers. Including the battery drivers or chargers which are > usually power_supplies. So what is preventing us from formalizing the > process? > > Instead of otg_transceiver, you would have usb_transceiver, and the > battery and charging drivers loose the need to be hooked to USB. Even > the proprietary user space things would benefit. You always have the > same sysfs interfaces provided by power supply class. Like I said, if > there truly is need for the notifiers for some weird case, you can > still use them. > > About bMaxPower, the charger types and the USB state, dude, you did > not read the code :(. > > -- > heikki > -- > 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 > After reading heikki's code, I think separate transcevicer function from otg is a good thing. - Most OTG utilities are only in embedded, and currently, most of embedded devices with otg port are device-only function, and most of customers refuse to use otg function if their products are device-only, as otg is complicated, and easy to produce bugs. So they only use udc driver, and not touch otg, but udc driver also needs to touch transceiver when system boot, system suspend/resume, and usb run-time suspend/resume. - Now, more and more embedded devices use usb charger, usb detection is different with different transcevicers, and usb charger is a power supplier for system, it is no relationship with otg driver. -- Best Regards, Peter Chen -- 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
