Conversation
|
Pushed some fixes Now everything fails here: |
|
Since you have placed the nodes inside the soc simple-bus node, can you also remove the 0x18 from the USB and USB phy nodes?
So that usb2_phy would be ***@***.*** and ehci would be ***@***.***
I think that's what the error was about?
|
|
Oh cool the email has screwed up the node addresses I was suggesting and interpreted them as emails ??
Another try,So usb phy node would at 140200 and ehci would be at 21000
The same should also go for addresses inside the reg properties I think
|
I tried both - moving inside bus node, moving out, left bus offset instead of full address - neither worked. I'll return to this problem later |
|
Not great... maybe the order should be other way around in reg property. So like `reg = <0x180210a4 0x14>, <0x18140200 0x14>; I think for the time being we should avoid placing it under soc node until we can make it work |
That's what I did, and it worked - there was resource overlap between usb driver and usb phy nodes So now it fails in I would suggest you be more careful with registers endianess - I think it would be better if you will look at your code again. Feel free to use (or discard) any changes from me |
Right yeah,
Good notice, i didn't give them much about |
jameywine
force-pushed
the
rtl9607c-dev-usb
branch
from
8a1c22a to
a7596ba
Compare
Included your fixes with some adjustments and added the utmi set and wait functions as suggested earlier |
jameywine
force-pushed
the
rtl9607c-dev-usb
branch
from
a7596ba to
eb80740
Compare
|
Included most of the things from your reviews The UTMI REG situation is yet to be improved but that should come after usb is confirmed working |
|
Btw, I've tested actual driver version, and problem is still same |
|
By "actual usb version", are you talking about the USB driver from GPL code?
|
No, I meant content of this branch after fixes (endianess, set_bits) |
|
Can you share the bootlogs? My gut tells me that it is from a ioremap of utmi reg (which is at ehci base + 0xa4) because it is within the ehci reg region (ehci base + 0x200) which also needs to be ioremaped and so.. there may be conflict here?
|
|
Full bootlog with some debug patches BootlogPatch |
|
More debug logs I does not know anything about USB controllers, but unaligned address seems... pretty wrong |
|
Anything on the usb phy driver side? Is it run from the Something tells me that we need to create custom function that will be used in place of ehci_setup through the overrides Similar way it is done in the xhci usb driver for the closed rtl8198c pull request?
I also don't know much about the usb stuff but looking at ehci_setup, it is adding something to regs |
|
Other avenues to explores: There is ehci-pci load during the oem reboot, maybe enabling will help somehow? Perhaps we can do something similar to bcma-hcd and alike that deals with platform_device struct? |
|
Figured out which driver was used in SDK: DetailsIt's
I believe that's the case when OEMs don't cares about disabling unneeded SDKs defaults
Didn't get you
Seems like simple workaround for PHY initializing. Anyway, what are we gonna do in custom .reset? |
Ah so that is what happens with static struct resource bsp_usb_ehci_resource[] = {
[0] = {
.start = PADDR(BSP_EHCI_BASE),
.end = PADDR(BSP_EHCI_BASE) + BSP_EHCI_SIZE - 1,
.flags = IORESOURCE_MEM,
},
[1] = {
.start = BSP_USB_2_IRQ,
.end = BSP_USB_2_IRQ,
.flags = IORESOURCE_IRQ,
}
};
static struct platform_device bsp_usb_ehci_device = {
//.name = "rtl86xx-ehci",
.name = "ehci-platform",
.id = 0,
.num_resources = ARRAY_SIZE(bsp_usb_ehci_resource),
.resource = bsp_usb_ehci_resource,
.dev = {
.dma_mask = &bsp_usb_dmamask,
.coherent_dma_mask = 0xFFFFFFFFUL,
}
};
static struct platform_device *bsp_usb_devs0[] __initdata = {
#ifdef CONFIG_USB_OHCI_HCD
&bsp_usb_ohci_device,
#endif
#ifdef CONFIG_USB_EHCI_HCD
&bsp_usb_ehci_device,
#endif
};
Good point, since we are doing phy init through a proper phy driver, i don't think we need it So, we just need to instigate what is so different about the |
|
@ProMix0 I think i found the potential reason for this? Browsing through the patches of the realtek's edited linux from GPL archive versus the vanilla linux, i stumbled upon this diff -urN linux-5.10.226/drivers/usb/host/ehci.h rtl9607-u2.2_GP3000/rtl9607-u2.2/linux-5.10.x/drivers/usb/host/ehci.h
--- linux-5.10.226/drivers/usb/host/ehci.h 2024-09-12 14:06:51.000000000 +0500
+++ rtl9607-u2.2_GP3000/rtl9607-u2.2/linux-5.10.x/drivers/usb/host/ehci.h 2025-06-11 07:42:22.000000000 +0500
@@ -739,6 +739,9 @@
static inline unsigned int ehci_readl(const struct ehci_hcd *ehci,
__u32 __iomem *regs)
{
+#if defined(CONFIG_RTK_MIPS_SOC)
+ return (le32_to_cpu((*(volatile unsigned long *)(regs))));
+#else
#ifdef CONFIG_USB_EHCI_BIG_ENDIAN_MMIO
return ehci_big_endian_mmio(ehci) ?
readl_be(regs) :
@@ -746,6 +749,7 @@
#else
return readl(regs);
#endif
+#endif
}
#ifdef CONFIG_SOC_IMX28
@@ -763,6 +767,9 @@
static inline void ehci_writel(const struct ehci_hcd *ehci,
const unsigned int val, __u32 __iomem *regs)
{
+#if defined(CONFIG_RTK_MIPS_SOC)
+ ((*(volatile unsigned long *)(regs))=cpu_to_le32(val));
+#else
#ifdef CONFIG_USB_EHCI_BIG_ENDIAN_MMIO
ehci_big_endian_mmio(ehci) ?
writel_be(val, regs) :
@@ -773,6 +780,7 @@
else
writel(val, regs);
#endif
+#endif
}So realtek has simply changed how ehci reads and writes are done and used |
|
Thing is, There is The only solution I see right now - define P.S. With correct endianess |
|
Tested driver with both revision, seems to be working for me (still usb sticks read and write, XHCI not tested) |
jameywine
force-pushed
the
rtl9607c-dev-usb
branch
from
1f36672 to
93b9ddf
Compare
jameywine
force-pushed
the
rtl9607c-dev
branch
3 times, most recently
from
546214c to
c1a27b2
Compare
jameywine
force-pushed
the
rtl9607c-dev-usb
branch
from
93b9ddf to
bcdc86e
Compare
jameywine
force-pushed
the
rtl9607c-dev-usb
branch
from
bcdc86e to
3688ea8
Compare
jameywine
force-pushed
the
rtl9607c-dev-usb
branch
from
3688ea8 to
7e18a5e
Compare
|
This should be in a good shape to send upstream. For now i will only send the usb2 phy part as these are the ones that we have tested and confirmed to be working. I am still not sure about ehci/ohci quirks but i guess it wouldn't hurt to send it for comments at the very least and hear opinions of usb maintainers. Also, @ProMix0 as you were helping with quite a bit with usb2 phy part, are you okay if i add you as co-developed-by? |
|
Okay. I'm interested in upstream guys opinion about all that endianess stuff |
|
patch has been sent :) https://lore.kernel.org/linux-phy/20260326193419.48419-1-adilov@disroot.org/ |
jameywine
force-pushed
the
rtl9607c-dev-usb
branch
from
7e18a5e to
ce839d6
Compare
jameywine
force-pushed
the
rtl9607c-dev-usb
branch
from
ce839d6 to
ac6c486
Compare
jameywine
force-pushed
the
rtl9607c-dev-usb
branch
from
ac6c486 to
1974f88
Compare
jameywine
force-pushed
the
rtl9607c-dev-usb
branch
from
1974f88 to
de0c50c
Compare
This commit adds support for EHCI and OHCI controller on RTL9607. It uses the generic ehci-platform and ohci-platform drivers and due to endian issues a quirk patch was added that adds "force little endian" property which rtl9607 needs for its EHCI and OCHI controller. There is also a patch which adds support for USB2 PHY on RTL9607 to the existing phy-rtk-usb2 driver. Co-developed-by: ProMix0 <misha.zavertkin@mail.ru> Signed-off-by: ProMix0 <misha.zavertkin@mail.ru> Signed-off-by: Rustam Adilov <adilov@tutamail.com>
This commit adds support for XHCI controller on RTL9607 with the help of generic-xhci driver. There is also a patch that adds support for rtl9607 to the existing phy-rtk-usb3 driver. Signed-off-by: Rustam Adilov <adilov@tutamail.com>
jameywine
force-pushed
the
rtl9607c-dev-usb
branch
from
de0c50c to
aa737bd
Compare
|
I am thinking of whether it would be better to use |
|
I think it's better to tell why we are doing that ( On the other side, there is |
My main thoughts are just to solve the errors that come from using these Explaining the reason behind these would be the same as with At the very least,
I think it is fine and there has been a hefty conversation chain on it. |
2 participants
This commit adds support for EHCI controller on RTL9607.
That also includes 2 patches for addition of ehci driver and usb2 phy driver for it. There is also XHCI controller but it is yet to be developed.
This is yet to be tested and to potentially be improved.