On Wed, 4 May 2011, Jan Andersson wrote:
> This patch adds support for the UHCI part of the GRLIB GRUSBHC controller
> found on some LEON/GRLIB SoCs.
>
> The UHCI HCD previously only supported controllers connected over PCI.
> This patch adds support for the first non-PCI UHCI HC. I have tried to
> replicate the solution used in ehci-hcd.c.
>
> This patch also extends the uhci_{read,write}* functions to allow accesses
> to registers not mapped into PCI I/O space. This extension also includes
> the addition of a void __iomem pointer to the uhci structure.
I would prefer to see the new functions and the __iomem pointer added
as a separate preliminary patch. They are logically separate from the
GRUSBHC support.
> Tested on GR-LEON4-ITX board (LEON4/GRLIB with GRUSBHC) and x86 with Intel
> UHCI HC.
>
> Signed-off-by: Jan Andersson <jan@xxxxxxxxxxx>
> ---
>
> Right now the choice of I/O function to use when supporting non-PCI is
> (for instance):
>
> static inline u16 uhci_readw(struct uhci_hcd *uhci, int reg)
> {
> if (uhci_has_pci_registers(uhci))
> return inw(uhci->io_addr + reg);
> else
> return readw(uhci->regs + reg);
> }
>
> Another solution would be to use:
>
> static inline u16 uhci_readw(struct uhci_hcd *uhci, int reg)
> {
> return uhci->readw(uhci, reg);
> }
>
> where uhci->readw is a function pointer that could be setup by
> a probe function to either point at ehci_pciio_readw (which would
> containt an 'inw') or ehci_memio_readw (which would contain a readw).
"ehci"?
> I did not implement this as it leads to more code being added. When/If
> support for big endian registers is added then perhaps it would be better
> to use function pointers when supporting non-PCI hosts.
Seems like a reasonable choice.
> +config USB_UHCI_SUPPORT_NON_PCI_HC
> + bool
> + depends on USB_UHCI_HCD
> + default y if SPARC_LEON
> + default n
This last line is not necessary. n is the "default" default. :-)
Alan Stern
--
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
