Re: [PATCH 6/8] xHCI: calculate HIRD

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

 



On Thu, 2011-08-11 at 09:19 -0700, Sarah Sharp wrote:
> On Thu, Aug 11, 2011 at 02:36:27PM +0800, Xu, Andiry wrote:
> > > -----Original Message-----
> > > From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx]
> > > Sent: Wednesday, August 10, 2011 12:19 AM
> > > To: Xu, Andiry
> > > Cc: linux-usb@xxxxxxxxxxxxxxx; gregkh@xxxxxxx;
> > > stern@xxxxxxxxxxxxxxxxxxx
> > > Subject: Re: [PATCH 6/8] xHCI: calculate HIRD
> > > 
> > > >
> > > > I'm converting it to HIRD(BESL), which will only be used by USB2
> > LPM.
> > > > Driver can always retrieve the host controller exit latency at any
> > > time,
> > > > like this:
> > > >
> > > > +	xhci->u2del = HCS_U2_LATENCY(xhci->hcs_params3);
> > > 
> > > True.  However, if you're not planning on sharing that value across
> > > multiple code paths, and you're not accessing it very often in a
> > > performance critical path, then why do you need to store it as a
> > > parameter in xhci_hcd?  That structure is getting awfully large.
> > > 
> > 
> > It's a host controller attribute, and HIRD/BESL needs to be set for
> > every LPM device test, so I guess it's better to calculate and store
> > it once than calculate it in every software lpm test.
> 
> It's a register read and a couple lines of math.  It's really not going
> to save you that much time to recalculate it.  The LPM device test is
> only run once, when the device is enumerated, and you won't use
> xhci->hird anywhere else, right?  It's fine if enumeration takes a
> little bit longer, because it already causes a bunch of register reads
> and commands to the xHCI host to be submitted.
> 
> However, it's not fine if an addition to the xhci_hcd structure causes
> certain highly-accessed parts of it to be not in the same cache line and
> causes, say, the transfer event IRQ handler to slow down due to cache
> misses.  I haven't optimized the xhci_hcd structure with pahole yet, but
> it's something I'd like to do, so I want to start culling the xhci_hcd
> structure for things that aren't really necessary to be in there.
> 

I see.

> Please just call the function to calculate the HIRD where ever you need
> it (and remove the xhci->hird parameter), add the comment about the new
> BESL 1.0 spec errata, change your description like Sebastian suggested
> to note that LPM can fail on some hosts and succeed on other hosts with
> the same device, and resubmit your patchset.  I think you should be good
> to go for 3.2 after that.
> 

Sure. But I think I also need to modify the HIRD/BESL setting. According
to Steve, the value is passed to device directly, so driver needs to
check the device's descriptors to determine whether HIRD or BESL should
be used.

Steve says BESL is defined in the USB2 LPM Errata. Unfortunately I can't
find it on usb.org or by Google, only USB2 LPM ECN can be found. Can
anyone point to me where I can find the USB2 LPM errata? Thanks.

Thanks,
Andiry 


--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux