On Tue, Jun 23, 2015 at 10:43:28AM +0300, Roger Quadros wrote: > > > > > > If the dr_mode was "otg" for such case and we want OTG disabled then it is really the DT fault. > > > > It's ID pin detect for dual role switch as many current OTG controllers have. > > not DT fault, its dt only has a dr_mode = "otg". > > > > > We don't need to tackle this case. Just fix up the DT to dr_mode = "peripheral" if > > > OTG behaviour is not needed. > > > > > OTG behaviour is not needed, so we need disable HNP/SRP/ADP. but dr_mode = > > "otg" as it already works fine with ID pin detect. > > Do you know which platform has plain non-otg dual-role working as of today > with dr_mode set to "otg"? I don't know. The dt property dr_mode is already there, and currently there are some platforms as its user, so I assume those platforms either are non-otg dual-role, or real OTG with HNP supported, I guess most are the former cases; chipidea is the later case. > For TI platforms none of them have it working currently. > So for Ti platforms, some enables non-otg dual-role function but do not use dr_mode = "otg"? For those only have non-otg dual-role platforms, no matter using dr_mode or not, we need keep it's real OTG disabled for legacy users after it's controller driver adds real OTG later. > > > > > > > > > > How I make one decision in of_usb_updade_otg_caps() > > > > for above 2 cases?(the otg-rev is 0 for both). > > > > > > > > > > For case 3. otg-rev passed by controller is not 0. otg-rev is just not present in DT. > > > > > > > Current OTG situation is not so simple, so that we can not use one simple > > rule to handle legacy cases in a common place, but for a particular controller > > driver, make decision on this is a simple work, I think. > > OK. Let's continue with your apporach. Maybe USB maintainers can give their opinion > as well. > If some simple handling for all legacy platforms can be accepted, I am happy to follow it in of_usb_update_otg_caps(). Felipe, Peter, any comments on this? Li Jun > Later if more controllers are trying to do the same thing then we can introduce a helper > function for those controllers. > Agree. > cheers, > -roger -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
