Re: [PATCH v6] usb: common: add API to set usb otg capabilities by device tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Mon, 22 Jun 2015 18:56:18 +0800
Li Jun <b47624@xxxxxxxxxxxxx> wrote:

> On Mon, Jun 22, 2015 at 12:43:37PM +0300, Roger Quadros wrote:
> > On Thu, 18 Jun 2015 16:47:48 +0800
> > Li Jun <b47624@xxxxxxxxxxxxx> wrote:
> > 
> > > On Thu, Jun 18, 2015 at 10:36:50AM +0300, Roger Quadros wrote:
> > > > Lin,
> > > > 
> > > > You can use --in-reply-to "message id of v5 of this path" so that it appears together
> > > > with the other patches in peoples mailboxes.
> > > > 
> > > > > + * the passed properties in DT.
> > > > > + * @np: Pointer to the given device_node
> > > > > + * @otg_caps: Pointer to the target usb_otg_caps to be set
> > > > > + *
> > > > > + * The function gets and sets the otg capabilities
> > > > > + */
> > > > > +void of_usb_set_otg_caps(struct device_node *np, struct usb_otg_caps *otg_caps)
> > > > > +{
> > > > > +	u32 otg_rev;
> > > > > +
> > > > > +	if (!otg_caps)
> > > > > +		return;
> > > > > +
> > > > > +	if (!of_property_read_u32(np, "otg-rev", &otg_rev))
> > > > > +		otg_caps->otg_rev = otg_rev;
> > > > 
> > > > should we check if otg_rev is in correct format?
> > > > anything non BCD and greater than 0x9999 is invalid.
> > > > 
> > > > Also if otg-rev is not passed then we need to treat it as legacy
> > > > platform right? How is this taken care of?
> > > > 
> > > Missed this comment
> > > This handling rely on controller driver, cannot decided here.
> > > There are several cases we need take care:
> > > 1) otg-rev is not passed, but all 3 disable flags passed, this is
> > >   valid, means user want to disable whole OTG, so only "otg-rev"
> > >   not passed, cannot treat as legacy platform.
> > > 2) Legacy platform means: none of 4 properties is present.
> > 
> > OK this was our difference in understanding. I was thinking that for non
> > legacy code otg-rev _must_ be passed. without otg-rev the disable flags
> > will be ignored. It makes life much easier no?
> > 
> 
> I have to consider ID pint detect case, this is a most common usage,
> after controller driver use otg_caps and enable OTG HNP/SRP, some
> platform still just want ID pin detect, no more otg feature required,
> it need disable OTG HNP/SRP/ADP, the dt should be:
> dr_mode = "otg";
> adp-disable;
> hnp-disable;
> srp-didable;
> 
> in this case, we cannot require DT user still pass a otg-rev, right?

Right. Although I'm beginning to think if we should add "drd-only" flag
to explicitly state DRD feature as it might be more common than OTG.

But for current patches I think we can safely assume that
if the 3 flags are not passed and otg-rev is not passed then it is
legacy DT requiring OTG with HNP/SRP.

> 
> > why do you want otg-rev to be optional for non-legacy DT?
> > 
> 
> For above ID pin detect case.

Got it.

cheers,
-roger

> 
> > > 3) Some controller drivers already support OTG HNP/SRP, then change
> > >   to utilize those new flags, still should support OTG HNP/SRP w/o
> > >   any dt change, so OTG caps should be enabled for legacy platforms.
> > > 4) Some controller drivers does not support any OTG, after add OTG
> > >   functions and utilize those new flags, should keep OTG disabled
> > >   for legacy platforms.
> > > 
> > 
> > cheers,
> > -roger
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux