RE: [PATCH v2] USB: ehci-pci: USB host controller support for Intel Quark X1000

[Chen, Alvin]

> > > The EHCI packet buffer in/out threshold is programmable for Intel
> > > Quark X1000 USB host controller, and the default value is 0x20
> > > dwords. The in/out threshold can be programmed to 0x80 dwords, but
> > > only when isochronous/interrupt transactions are not initiated by
> > > the USB host controller. This patch is to reconfigure the packet
> > > buffer in/out threshold as maximal as possible, and it is 0x7F dwords since
> the USB host controller initiates isochronous/interrupt transactions.
> >
> > So, what is the reason to set the value as 0x80?
> >   1. The default value 0x20 makes some problems such as...
> >   2. To maximize the performance, ...
> >   3. Both
> > Please add the reason why 0x80 is necessary, as possible.
> >
> > Then, 0x7F means 508 bytes? 'Intel Quark X1000 USB host controller'
> > can support 0x80 (512bytes), however, in this case,
> > isochronous/interrupt transactions cannot be initiated by 'Intel Quark X1000
> USB host controller'.
> > Right?
> >
> > So, 0x79 (508bytes?) should be used, because the isochronous/interrupt
> > transactions can be initiated by 'Intel Quark X1000 USB host controller'.
> > Right?
> >
Yes, to maximize the performance, we set the threshold as maximal as possible. Intel Quark X1000 can support 0x80 dwords (512Bytes), but 0x7F dwords (508 Bytes) should be used since the isochronous/interrupt
transactions can be initiated by Intel Quark X1000 USB host controller. I will update the descriptions.

> > > /*------------------------------------------------------------------
> > > -------*/
> > > +#define PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC		0x0939
> > > +static inline bool usb_is_intel_quark_x1000(struct pci_dev *pdev) {
> > > +	return pdev->vendor == PCI_VENDOR_ID_INTEL &&
> > > +		pdev->device == PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC;
> > > +
> >
> > Please don't add this unnecessary line.
OK, I will remove it.

> >
> > > +}
> > > +
> > > +/* Register offset of in/out threshold */
> > > +#define EHCI_INSNREG01		    0x84
> > > +/* The maximal threshold is 0x80 Dword */
> > > +#define EHCI_MAX_THRESHOLD      0X80
> >
> > s/0X80/0x80
> >
> > 0x80 means 512 bytes. So, how about mentioning '0x80 means 512 bytes'
> > in this comment or the commit message?
> >
> > Maybe, how about the following?
> >
> > /* The maximal threshold value is 0x80, which means 512 bytes */
> > #define EHCI_THRESHOLD_512BYTES		0x80
> >
> > > +/* Lower word is 'in' threshold, and higher word is 'out'
> > > +threshold*/ #define EHCI_INSNREG01_THRESH \
> > > +	((EHCI_MAX_THRESHOLD - 1)<<16 | (EHCI_MAX_THRESHOLD - 1))
> >
> > Um, how about the following?
> >
> > /* Register offset of in/out threshold */
> > #define EHCI_INSNREG01			0x84
> > /* The maximal threshold value is 0x80, which means 512 bytes */
> > #define EHCI_THRESHOLD_512BYTES		0x80
> > #define EHCI_THRESHOLD_508BYTES		0x79
> > #define EHCI_THRESHOLD_OUT_SHIFT		16
> > #define EHCI_THRESHOLD_IN_SHIFT		0
> >
> > 	......
> >
> > 	/*
> > 	 * In order to support the isochronous/interrupt transactions,
> > 	 * 508 bytes should be used as max threshold values */
> > 	 */
> > 	val = 	((EHCI_THRESHOLD_512BYTES - 1) <<
> EHCI_THRESHOLD_OUT_SHIFT |
> > 		(EHCI_THRESHOLD_512BYTES - 1) << EHCI_THRESHOLD_IN_SHIFT);
> > 	writel(val, op_reg_base + EHCI_INSNREG01);
> 
> Sorry, please refer to the following.
> 
> /* Register offset of in/out threshold */
> #define EHCI_INSNREG01			0x84
> /* The maximal threshold value is 0x80, which means 512 bytes */
> #define EHCI_THRESHOLD_512BYTES		0x80
> #define EHCI_THRESHOLD_508BYTES		0x79
> #define EHCI_THRESHOLD_OUT_SHIFT		16
> #define EHCI_THRESHOLD_IN_SHIFT		0
> 
>  	......
> 
>  	/*
> 	 * In order to support the isochronous/interrupt transactions,
> 	 * 508 bytes should be used as max threshold values */
> 	 */
> 	val = 	(EHCI_THRESHOLD_508BYTES <<
> EHCI_THRESHOLD_OUT_SHIFT |
> 		(EHCI_THRESHOLD_508BYTES << EHCI_THRESHOLD_IN_SHIFT);
> 	writel(val, op_reg_base + EHCI_INSNREG01);
> 
I will improve the according to your suggestions.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/