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. 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. Sarah Sharp -- 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
