The R-Car H2 and M2 SoCs come with an xHCI controller that requires
some specific initilization related to the firmware downloading and
some specific registers. This patch adds the support for this special
configuration as an xHCI quirk executed during probe and start.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/usb/host/Kconfig | 8 ++
drivers/usb/host/Makefile | 3 +
drivers/usb/host/xhci-plat.c | 18 +++++
drivers/usb/host/xhci-rcar.c | 182 ++++++++++++++++++++++++++++++++++++++++++
drivers/usb/host/xhci-rcar.h | 28 +++++++
5 files changed, 239 insertions(+)
create mode 100644 drivers/usb/host/xhci-rcar.c
create mode 100644 drivers/usb/host/xhci-rcar.h
Hi Shimoda-san,
On Mon, May 19, 2014 at 12:08 PM, Yoshihiro Shimoda
[off-list ref] wrote:
The R-Car H2 and M2 SoCs come with an xHCI controller that requires
some specific initilization related to the firmware downloading and
some specific registers. This patch adds the support for this special
configuration as an xHCI quirk executed during probe and start.
@@ -39,6 +40,12 @@ static int xhci_plat_setup(struct usb_hcd *hcd) static int xhci_plat_start(struct usb_hcd *hcd) {+ struct device_node *of_node = hcd->self.controller->of_node;++ if (of_device_is_compatible(of_node, "renesas,r8a7790-xhci") ||+ of_device_is_compatible(of_node, "renesas,r8a7790-xhci"))
r8a7791, as Magnus already pointed out.
+ xhci_rcar_start(hcd);
If CONFIG_USB_XHCI_RCAR is not defined, xhci_rcar_start() is a dummy
function, but the of_device_is_compatible() checks will still be compiled in.
Hence perhaps an #ifdef CONFIG_USB_XHCI_RCAR is warranted here,
possibly combined with inclusion of a C-source file, like is done in
drivers/usb/host/ohci-hcd.c? It's up to the USB maintainer to decide this,
though.
quoted hunk
+
return xhci_run(hcd);
}
@@ -165,6 +172,15 @@ static int xhci_plat_probe(struct platform_device *pdev) goto unmap_registers; }+ if (of_device_is_compatible(pdev->dev.of_node,+ "renesas,r8a7790-xhci") ||+ of_device_is_compatible(pdev->dev.of_node,+ "renesas,r8a7791-xhci")) {+ ret = xhci_rcar_init_quirk(pdev);
Same here.
+ if (ret)
+ goto disable_clk;
+ }
+
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto disable_clk;
This is your custom get_unaligned_le32(), to avoid reading beyond the end
of the buffer if its size is not a multiple of 4 bytes?
Is there some way to just use get_unaligned_le32()?
If you want to keep it, I would rewrite it as
for (data = 0, j = 3; j >= 0; j--) {
if ((j + index) < fw->size)
data |= fw->data[index + j] << (8 * j);
}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torval
From: Sergei Shtylyov <hidden> Date: 2014-05-19 12:14:52
Hello.
On 19-05-2014 14:08, Yoshihiro Shimoda wrote:
The R-Car H2 and M2 SoCs come with an xHCI controller that requires
some specific initilization related to the firmware downloading and
some specific registers. This patch adds the support for this special
configuration as an xHCI quirk executed during probe and start.
Hi Geert-san,
(2014/05/19 20:58), Geert Uytterhoeven wrote:
Hi Shimoda-san,
On Mon, May 19, 2014 at 12:08 PM, Yoshihiro Shimoda
[off-list ref] wrote:
< snip >
quoted
+config USB_XHCI_RCAR
+ tristate "xHCI support for Renesas R-Car SoCs"
+ select USB_XHCI_PLATFORM
+ depends on ARCH_SHMOBILE || COMPILE_TEST
+ ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ found in Renesas R-Car ARM SoCs.
Does R-Car Gen1 also have xHCI, and is it compatible?
If not, you may want to call this driver USB_XHCI_RCAR2.
R-Car Gen1 doesn't have xHCI.
However, next generation of R-Car may have xHCI. (But, I don't know it is compatible.)
If we call this driver "USB_XHCI_RCAR2", should we also change filename to "xhci-rcar2.[ch]"?
< snip >
If CONFIG_USB_XHCI_RCAR is not defined, xhci_rcar_start() is a dummy
function, but the of_device_is_compatible() checks will still be compiled in.
Hence perhaps an #ifdef CONFIG_USB_XHCI_RCAR is warranted here,
possibly combined with inclusion of a C-source file, like is done in
drivers/usb/host/ohci-hcd.c? It's up to the USB maintainer to decide this,
though.
This implementation is similar with the following patch. And the patch already got
"Acked-by" from Mathias Nyman of USB XHCI DRIVER's maintainer.
http://marc.info/?l=linux-usb&m=140014933101775&w=2
< snip >
quoted
@@ -165,6 +172,15 @@ static int xhci_plat_probe(struct platform_device *pdev) goto unmap_registers; }+ if (of_device_is_compatible(pdev->dev.of_node,+ "renesas,r8a7790-xhci") ||+ of_device_is_compatible(pdev->dev.of_node,+ "renesas,r8a7791-xhci")) {+ ret = xhci_rcar_init_quirk(pdev);
Same here.
Same above.
< snip >
quoted
--- /dev/null+++ b/drivers/usb/host/xhci-rcar.c
quoted
+/* USB3.0 Configuraion */
Configuration
I ran the "aspell -c" command, and I found other 2 typos. ("Initilization" and "Porariy")
So, I will correct these typos.
< snip >
quoted
+ for (index = 0; index < fw->size; index += 4) {
+ for (data = 0, j = 3; j >= 0; j--) {
+ if ((j + index) >= fw->size)
+ continue;
+ data |= fw->data[index + j] << (8 * j);
+ }
This is your custom get_unaligned_le32(), to avoid reading beyond the end
of the buffer if its size is not a multiple of 4 bytes?
Yes, I would like to avoid it.
Is there some way to just use get_unaligned_le32()?
Yes, I will remove the custom get_unaligned_le32() and add the following code.
Do you think that this code is good?
int i;
u32 data;
u8 buf[4];
< snip >
for (i = 0; i < fw->size; i += 4) {
memset(buf, 0, sizeof(buf));
memcpy(buf, &fw->data[i], min(sizeof(buf), fw->size - i));
data = get_unaligned_le32(buf);
Best regards,
Yoshihiro Shimoda
If you want to keep it, I would rewrite it as
for (data = 0, j = 3; j >= 0; j--) {
if ((j + index) < fw->size)
data |= fw->data[index + j] << (8 * j);
}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torval
Need empty line here... and should perhaps return error if hcd->regs NULL?
I will add empty line.
If this function returns error and xhci_plat_start() also returns error,
the xhci driver was not able to work.
So, I will change the prototype of this function to "void".
Best regards,
Yoshihiro Shimoda
Like the drivers before, this is way more than a quirk, and deserves to
be its own driver. It would be better to have an abstract way to split
out soc specific xhci front-ends and export functions from the xhci-platform
code.
Arnd
Like the drivers before, this is way more than a quirk, and deserves to
be its own driver. It would be better to have an abstract way to split
out soc specific xhci front-ends and export functions from the xhci-platform
code.
Thank you for your comment. But, I couldn't understand your comment...
Did you mean that xhci-rcar.c should call of_device_is_compatible(of_node, "renesas,...")?
If so, I will modify this patch.
Best regards,
Yoshihiro Shimoda