[PATCH] musb: sunxi: Ignore VBus errors in host-only mode

[Hans de Goede]

For some unclear reason sometimes we get VBus errors in host-only mode,
even though we do not have any vbus-detection then. Ignore these.

Signed-off-by: Hans de Goede <hdeg...@redhat.com>
---
drivers/usb/musb/sunxi.c | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index f9f6304..34ce5df 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -194,6 +194,10 @@ static irqreturn_t sunxi_musb_interrupt(int irq, void *__hci)
musb_writeb(musb->mregs, MUSB_FADDR, 0);
}

+ /* Ignore Vbus errors when in host only mode */
+ if (musb->port_mode == MUSB_PORT_MODE_HOST)
+ musb->int_usb &= ~MUSB_INTR_VBUSERROR;
+
musb->int_tx = readw(musb->mregs + SUNXI_MUSB_INTRTX);
if (musb->int_tx)
writew(musb->int_tx, musb->mregs + SUNXI_MUSB_INTRTX);
--
2.4.3

[Felipe Balbi]

On Tue, Aug 04, 2015 at 11:25:53PM +0200, Hans de Goede wrote:
> For some unclear reason sometimes we get VBus errors in host-only mode,
> even though we do not have any vbus-detection then. Ignore these.
>
> Signed-off-by: Hans de Goede <hdeg...@redhat.com>
> ---
> drivers/usb/musb/sunxi.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
> index f9f6304..34ce5df 100644
> --- a/drivers/usb/musb/sunxi.c
> +++ b/drivers/usb/musb/sunxi.c
> @@ -194,6 +194,10 @@ static irqreturn_t sunxi_musb_interrupt(int irq, void *__hci)
> musb_writeb(musb->mregs, MUSB_FADDR, 0);
> }
>
> + /* Ignore Vbus errors when in host only mode */
> + if (musb->port_mode == MUSB_PORT_MODE_HOST)
> + musb->int_usb &= ~MUSB_INTR_VBUSERROR;

check with a scope if VBUS is really dropping. Host does VBUS detection
indeed, at a minimum, for overcurrent protection. You might have
something causing VBUS to drop and that something needs to be found,
rather than masked.

--
balbi

[Hans de Goede]

Hi,

The boards in question do not have any vbus detection, the usb-phy on
allwinner boards do not have a vbus sense pin, instead a gpio is used
in designs which use otg. Designs which use host-only mode typically
do not have any form of vbus detection at all. In this case we always
report vbus as being valid to the musb core, so I've no idea why
the musb core is still generating vbus errors.

Regards,

Hans

[Felipe Balbi]

Hi,

PHY must tell MUSB about VBUS level using either ULPI or UTMI+. I'd
check to see if the PHY is at fault, at least.

--
balbi

[Hans de Goede]

Hi,

Right, and the phy code has:

if (data->id_det_gpio) {
/* OTG mode, force ISCR and cable state updates */
data->id_det = -1;
data->vbus_det = -1;
queue_delayed_work(system_wq, &data->detect, 0);
} else {
/* Host only mode */
sun4i_usb_phy0_set_id_detect(_phy, 0);
sun4i_usb_phy0_set_vbus_detect(_phy, 1);
}

Where we enter the host only path (no id-pin in host only mode) and
then sun4i_usb_phy0_set_vbus_detect updates the ISCR register of
the phy to make it report vbus valid. I've done an mmio-dump of
the iscr register while running Linux, and this code does the right
thing.

I agree with you that this is weird, but atm I see no other way
to fix this then the submitted patch.

Regards,

Hans


>

[Olliver Schinagl]

Hey Hans,

I've tried getting your musb stuff working on a cubietruck, but i don't
seem to see this patch on your linux-sunxi/sunxi-wip branch on github?
Is your github branch fully functional at the moment?

What I have done so far, is build the kernel using sunxi_defconfig and
enabled USB_MUSB_SUNXI with its dependancies (musb isn't enabled there
by default): USB_SUPPORT [=y] && USB_MUSB_HDRC [=y] && ARCH_SUNXI [=y]
&& NOP_USB_XCEIV [=y] && PHY_SUN4I_USB [=y] && EXTCON [=y] &&
GENERIC_PHY [=y] Selects: SUNXI_SRAM [=y]

I changed the dts from dr_mode='otg' to dr_mode='host', a) we only need
host mode anyway (the id pin isn't properly connected) and b) I got an
error about an known dr_mode before and this was the quick and easy way.

Dmesg produces the following related to musb.

[ 1.691062] usb_phy_generic.0.auto supply vcc not found, using dummy
regulator
[ 1.691445] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk
combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
[ 1.691453] musb-hdrc: MHDRC RTL version 0.0
[ 1.691467] musb-hdrc: 11/11 max ep, 5184/8192 memory
[ 1.691543] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver
[ 1.691553] musb-hdrc musb-hdrc.1.auto: new USB bus registered,
assigned bus number 5
[ 1.692470] hub 5-0:1.0: USB hub found
[ 1.692529] hub 5-0:1.0: 1 port detected
[ 1.699956] sunxi-rtc 1c20d00.rtc: setting system clock to 2015-08-06
07:59:08 UTC (1438847948)
[ 1.704733] usb0-vbus: disabling
[ 1.765695] ldo4: disabling
[ 1.808351] ldo3: disabling
[ 1.848769] vcc5v0: disabling
[ 1.848774] vcc3v0: disabling

The usb_phy_generic missing shouldn't be too bad? But the usb0-vbus
being disabled obviously might be related to the musb port not working?
What causes this though? I went through all the musb patch series mails
but don't recall seing anything special being needed.

If there are fixes missing in the sunxi-next stuff that could explain
this, could you be so kind and push your latest work so I can try it?
Thanks Hans!

Olliver

[Hans de Goede]

Hi,

On 06-08-15 10:22, Olliver Schinagl wrote:
> Hey Hans,
>
> I've tried getting your musb stuff working on a cubietruck, but i don't seem to see this patch on your linux-sunxi/sunxi-wip branch on github? Is your github branch fully functional at the moment?
>
> What I have done so far, is build the kernel using sunxi_defconfig and enabled USB_MUSB_SUNXI with its dependancies (musb isn't enabled there by default): USB_SUPPORT [=y] && USB_MUSB_HDRC [=y] && ARCH_SUNXI [=y] && NOP_USB_XCEIV [=y] && PHY_SUN4I_USB [=y] && EXTCON [=y] && GENERIC_PHY [=y] Selects: SUNXI_SRAM [=y]
>
> I changed the dts from dr_mode='otg' to dr_mode='host', a) we only need host mode anyway (the id pin isn't properly connected)

If you change the dr_mode to host then you _must_ also remove any id_det and vbus_det
gpio settings from the usb_phy node in the dts, as the sun4i phy code detects
host vs otg mode by checking for the presence of these.

> and b) I got an error about an known dr_mode before and this was the quick and easy way.
>
> Dmesg produces the following related to musb.
>
> [ 1.691062] usb_phy_generic.0.auto supply vcc not found, using dummy regulator
> [ 1.691445] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
> [ 1.691453] musb-hdrc: MHDRC RTL version 0.0
> [ 1.691467] musb-hdrc: 11/11 max ep, 5184/8192 memory
> [ 1.691543] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver
> [ 1.691553] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 5
> [ 1.692470] hub 5-0:1.0: USB hub found
> [ 1.692529] hub 5-0:1.0: 1 port detected
> [ 1.699956] sunxi-rtc 1c20d00.rtc: setting system clock to 2015-08-06 07:59:08 UTC (1438847948)
> [ 1.704733] usb0-vbus: disabling
> [ 1.765695] ldo4: disabling
> [ 1.808351] ldo3: disabling
> [ 1.848769] vcc5v0: disabling
> [ 1.848774] vcc3v0: disabling
>
> The usb_phy_generic missing shouldn't be too bad? But the usb0-vbus being disabled obviously might be related to the musb port not working?

Correct.

For starters I would try the dts changes I suggested above.

Regards,

Hans

[Olliver Schinagl]

Hey Hans,

On 06-08-15 16:35, Hans de Goede wrote:
> Hi,
>
> On 06-08-15 10:22, Olliver Schinagl wrote:
>> Hey Hans,
>>
>> I've tried getting your musb stuff working on a cubietruck, but i
>> don't seem to see this patch on your linux-sunxi/sunxi-wip branch on
>> github? Is your github branch fully functional at the moment?
>>
>> What I have done so far, is build the kernel using sunxi_defconfig
>> and enabled USB_MUSB_SUNXI with its dependancies (musb isn't enabled
>> there by default): USB_SUPPORT [=y] && USB_MUSB_HDRC [=y] &&
>> ARCH_SUNXI [=y] && NOP_USB_XCEIV [=y] && PHY_SUN4I_USB [=y] && EXTCON
>> [=y] && GENERIC_PHY [=y] Selects: SUNXI_SRAM [=y]
>>
>> I changed the dts from dr_mode='otg' to dr_mode='host', a) we only
>> need host mode anyway (the id pin isn't properly connected)
>
> If you change the dr_mode to host then you _must_ also remove any
> id_det and vbus_det
> gpio settings from the usb_phy node in the dts, as the sun4i phy code
> detects
> host vs otg mode by checking for the presence of these.

Yes, this fixes it and makes it work. Thanks.

Also I apologize for not noticing this patch in your queue before :)
Looks like everything is all ready in your WIP branch.

Now, I see that Chen-Yu found the same problems here:
http://permalink.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/17843

So far, with your mentioned changes to remove the id and vbus gpio's you
can have my

Tested-by: Olliver Schinagl <o.sch...@ultimaker.com>

Yep that fixed it.
>
> Regards,
>
> Hans

[Olliver Schinagl]

Hey Hans,

On 07-08-15 10:45, Olliver Schinagl wrote:
> <snip>

>> If you change the dr_mode to host then you _must_ also remove any
>> id_det and vbus_det
>> gpio settings from the usb_phy node in the dts, as the sun4i phy code
>> detects
>> host vs otg mode by checking for the presence of these.
> Yes, this fixes it and makes it work. Thanks.
>

I've been going back to this and am wondering if this is something I can
look into to fix properly? E.g. if the dts sets dr_mode = host, can we
simply ignore the pins and treat them as unset?

Reason why I'm asking, the board we are using, the Lime2 has all the
stuff required for regular otg mode. The cables however that we connect
to the miniusb however do not force host only mode via the id pin, which
would have been the preferred way. We use a 'shield' for our lime with
various connections and thus have a dts for this shield, which includes
the lime2 dts. In the lime2 dts you want the otg pins enabled and set in
the generic usbphy section.

In my overlay, I ideally don't want to unset the pins, but do want to
set dr_mode (as i can't force it from userspace can I?). The logical
thing in my mind, would be to then just ignore those pins even when set,
right?

Olliver

[Hans de Goede]

Hi,

On 04-09-15 08:43, Olliver Schinagl wrote:
> Hey Hans,
>
> On 07-08-15 10:45, Olliver Schinagl wrote:
>> <snip>
>>> If you change the dr_mode to host then you _must_ also remove any id_det and vbus_det
>>> gpio settings from the usb_phy node in the dts, as the sun4i phy code detects
>>> host vs otg mode by checking for the presence of these.
>> Yes, this fixes it and makes it work. Thanks.
>>
> I've been going back to this and am wondering if this is something I can look into to fix properly? E.g. if the dts sets dr_mode = host, can we simply ignore the pins and treat them as unset?

AFAIK you cannot unset something in dts. The only solution I
can comeup with is to add a dr_mode argument to the phy like
we already have for the otg controller itself.

This is something which we likely need to do anyways to add
support for peripheral only mode, which we seem to need for
some "hdmi sticks".

Patches doing this are welcome from my pov.

Regards,

Hans

[Maxime Ripard]

I haven't really followed the rest of the discussion, so sorry if you
already talked about that, but why can't you just set the dr_mode to
peripheral in such a case?

Maxime

--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Hans de Goede]

Hi,

This is about the usbphy code not the musb-controller code, which are
2 different dts nodes, atm only the musb-controller node has a
dr_mode property, and the phy code decides between host-only
and otg mode based on whether an id pin is assigned or not.

My proposal is to get rid of the id-pin hack to determine the mode
and add a dr_mode property to the usbphy dts node.

Regards,

Hans

[Bin Liu]

Hi,

I would try to avoid adding dr_mode in the usbphy node if possible,
since it is already specified in the controller node.

Since the phy node is referenced in the controller node, is it
possible that the phy driver looks up the controller of properties to
find its dr_mode setting?

I am currently doing the same thing for musb_dsps.
Experienmenting...since I don't much about dts handling yet.

Regards,
-Bin.

>
>
> Regards,
>
> Hans
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majo...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html

[Hans de Goede]

Hi,

That is possible, but it very much goes against how devicetree normally
works, where every node is more or less a standalone unit which
contains enough info for the associated driver to do its work.

Currently there is no link from the phy node to the controller node
(only the other way around) and adding such a link requires more code
then simple having a duplicate dr_mode.

Regards,

Hans

[Bin Liu]

Hi,

I guess you are right, but duplicating dr_mode would cause more
trouble for end user.

Felipe, could you please give your comments on this issue? I have to
do the similar change for musb_dsps.

>
> Currently there is no link from the phy node to the controller node
> (only the other way around) and adding such a link requires more code
> then simple having a duplicate dr_mode.

I guess I did not make my previous comment clearly, we don't need to
add the link from the phy node to the controller node. We don't need
to change the current dts, just in the phy driver to look up dr_mode
of the controller node, if possible.

Regards,
-Bin.

>
> Regards,
>
> Hans
>

[Hans de Goede]

Hi,

The user already needs to set up regulators, vbus-det and id-det
for otg mode in the usbphy node. Although there are 2 nodes in dts /
2 separate hardware blocks involved in reality the 2 are closely
related and the user already must take care to have the settings match.

Besides that writing dts files is not something which end users do,
so a normal user will never see this.

> Felipe, could you please give your comments on this issue? I have to
> do the similar change for musb_dsps.
>
>>
>> Currently there is no link from the phy node to the controller node
>> (only the other way around) and adding such a link requires more code
>> then simple having a duplicate dr_mode.
>
> I guess I did not make my previous comment clearly, we don't need to
> add the link from the phy node to the controller node. We don't need
> to change the current dts, just in the phy driver to look up dr_mode
> of the controller node, if possible.

And how does the phy code now where the controller node lives without
having a link to it in its node? Hardcode the full path to the
controller node ? That is both ugly and error prone.

Regards,

Hans

[Bin Liu]

Hi,

This is my first time looking at dts handling in drivers, so I might
be completely wrong, but I am thinking that since the controller node
links to the phy node, so the controller node is the parent of the phy
node, so if there is an of api can look it up?

Regards,
-Bin.

>
> Regards,
>
> Hans

[Hans de Goede]

Hi,

If the phy is a child of the controller, then yes this would work,
but in the case of sunxi the phy is a built-in mmio mapped peripheral
just like the controller, so they sit at the same level and have no
parent child relation.

Regards,

Hans

[Bin Liu]

Hi,

musb_dsps dts is the same.

sun8i-a33.dtsi:

soc {
usb_otg: {
phys = <&usbphy 0>;
}
usbphy: {
}
}

As in the example above, usb_otg node refers to usbphy node, so I am
wondering if there is an of api to look up the usb_otg properties in
the usbphy driver.

Regards,
-Bin.

>
> Regards,
>
> Hans

[Hans de Goede]

Hi,

On 14-09-15 19:53, Bin Liu wrote:

<snip>

>>> This is my first time looking at dts handling in drivers, so I might
>>> be completely wrong, but I am thinking that since the controller node
>>> links to the phy node, so the controller node is the parent of the phy
>>> node, so if there is an of api can look it up?
>>
>>
>> If the phy is a child of the controller, then yes this would work,
>> but in the case of sunxi the phy is a built-in mmio mapped peripheral
>> just like the controller, so they sit at the same level and have no
>> parent child relation.
>
> musb_dsps dts is the same.
>
> sun8i-a33.dtsi:
>
> soc {
> usb_otg: {
> phys = <&usbphy 0>;
> }
> usbphy: {
> }
> }
>
> As in the example above, usb_otg node refers to usbphy node, so I am
> wondering if there is an of api to look up the usb_otg properties in
> the usbphy driver.

That would boil down to hardcoding the node name / path compatible
which is not acceptable from a devicetree pov.

Really having to duplicate the dr_mode is not that bad / such big
a deal.

Regards,

Hans

[Bin Liu]

Hi,

Okay, I got this sorted out - querying dr_mode in the phy driver:

struct device_node *p;
struct device_node *t = NULL;
const char *dr_mode_str;
enum usb_dr_mode dr_mode;

do {
t = of_find_node_with_property(t, "phys");
if (!t)
goto end;

p = of_parse_phandle(t, "phys", 0);
if (p == pdev->dev.of_node)
break;
while (true);

of_property_read_string(t, "dr_mode", &dr_mode_str);
dr_mode = of_usb_get_dr_mode(dr_mode_str);

end:

Regards,
-Bin.

[Maxime Ripard]

I agree that we should get rid of that hack, especially since a lack
of an ID pin might also be used on a peripheral-only device.

However, we already have that information in the musb node, and
duplicating the info seems error prone. We already have a custom
function, maybe that's a case for another one, and that would allow to
handle "hard" cases more easily (like CONFIG_USB_MUSB_HOST selected,
with the otg node set to otg).

[Hans de Goede]

Hi,

AFAIK the musb / phy maintainers really want to avoid adding more
custom functions ...

Felipe, Kishon any comments on this ?

Regards,

Hans

[Bin Liu]

Hi,

I add a function called of_usb_get_dr_mode_by_phy() in usb/common.c,
so that other phy drivers can call it to get dr_mode of the
controller. I will send the patch tomorrow morning for review.

Regards,
-Bin.

>
> Felipe, Kishon any comments on this ?
>
>
> Regards,
>
> Hans

[Olliver Schinagl]

Hey Hans,

On 10-09-15 20:23, Hans de Goede wrote:
> Hi,
>
> On 04-09-15 08:43, Olliver Schinagl wrote:
>> Hey Hans,
>>
>> On 07-08-15 10:45, Olliver Schinagl wrote:
>>> <snip>
>>>> If you change the dr_mode to host then you _must_ also remove any
>>>> id_det and vbus_det
>>>> gpio settings from the usb_phy node in the dts, as the sun4i phy
>>>> code detects
>>>> host vs otg mode by checking for the presence of these.
>>> Yes, this fixes it and makes it work. Thanks.
>>>
>> I've been going back to this and am wondering if this is something I
>> can look into to fix properly? E.g. if the dts sets dr_mode = host,
>> can we simply ignore the pins and treat them as unset?
>
> AFAIK you cannot unset something in dts. The only solution I
> can comeup with is to add a dr_mode argument to the phy like
> we already have for the otg controller itself.

Actually, it seems that you can :)


&usbphy {
/* Unset otg detect pins as we force dr_mode */
/delete-property/ usb0_id_det-gpio;
/delete-property/ usb0_vbus_det-gpio;
};

is what i am using at the moment.

>
> This is something which we likely need to do anyways to add
> support for peripheral only mode, which we seem to need for
> some "hdmi sticks".
>
> Patches doing this are welcome from my pov.

While my plate is uite fullish too, i may look into it :)
>
> Regards,
>
> Hans
>

[Stefan Monnier]

> &usbphy {
> /* Unset otg detect pins as we force dr_mode */
> /delete-property/ usb0_id_det-gpio;
> /delete-property/ usb0_vbus_det-gpio;
> };

Side question [ wearing my "contributor to Emacs's dts-mode" hat ]:

How should this piece of syntax be parsed? Is

/<something>/ blabla;

a general syntax accepted in DTS files, with various possible
<something> in there? Could someone point me to some documentation
explaining/describing this syntax?


Stefan

[Hans de Goede]

Hi,

It is probably best to start a new thread about this on <devic...@vger.kernel.org>,
that way people who may actually know the answer will see the mail :)

Regards,

Hans

[Christo Radev]

Hi to All,

Sorry, for posting on this old thread but I am new here and do not know how to address other people's attention to help me.

I have just open a new thread about my problem to use USB OTG on A20-Olinuxino-Lime2-eMMC with mainline kernel 4.5.2.

Please, help me to solve my problem.

Best regards

Chris

[Michal Suchanek]

On 14 September 2015 at 22:25, Maxime Ripard

Hello,

was this solved somehow?

What problem is there with referencing the phy node?

Just like pinmux setting nodes and whatnot it can be named and
referenced by name.

Thanks

Michal

[Christo Radev]

Thanks Michal,

I will test proposed solution and will post the results.
But in general I prefer to get full USB OTG functionality.

For the moment:

root@egpr:~# cat /boot/config-4.5.2-sunxi | grep CONFIG_USB_MUSB_HOST
# CONFIG_USB_MUSB_HOST is not set

and:

                usb@01c13000 {
                        compatible = "allwinner,sun4i-a10-musb";
                        reg = <0x1c13000 0x400>;
                        clocks = <0x3 0x0>;
                        interrupts = <0x0 0x26 0x4>;
                        interrupt-names = "mc";
                        phys = <0x23 0x0>;
                        phy-names = "usb";
                        extcon = <0x23 0x0>;
                        allwinner,sram = <0x24 0x1>;
                        status = "okay";
                        dr_mode = "host";
                };

                phy@01c13400 {
                        #phy-cells = <0x1>;
                        compatible = "allwinner,sun7i-a20-usb-phy";
                        reg = <0x1c13400 0x10 0x1c14800 0x4 0x1c1c800 0x4>;
                        reg-names = "phy_ctrl", "pmu1", "pmu2";
                        clocks = <0x25 0x8>;
                        clock-names = "usb_phy";
                        resets = <0x25 0x0 0x25 0x1 0x25 0x2>;
                        reset-names = "usb0_reset", "usb1_reset", "usb2_reset";
                        status = "okay";
                        pinctrl-names = "default";
                        pinctrl-0 = <0x26 0x27>;
                        usb0_id_det-gpio = <0x1e 0x7 0x4 0x0>;
                        usb0_vbus_det-gpio = <0x1e 0x7 0x5 0x0>;
                        usb0_vbus-supply = <0x28>;
                        usb1_vbus-supply = <0x29>;
                        usb2_vbus-supply = <0x2a>;
                        linux,phandle = <0x23>;
                        phandle = <0x23>;
                };


                pinctrl@01c20800 {
...
                        usb0_id_detect_pin@0 {
                                allwinner,pins = "PH4";
                                allwinner,function = "gpio_in";
                                allwinner,drive = <0x0>;
                                allwinner,pull = <0x1>;
                                linux,phandle = <0x26>;
                                phandle = <0x26>;
                        };

                        usb0_vbus_detect_pin@0 {
                                allwinner,pins = "PH5";
                                allwinner,function = "gpio_in";
                                allwinner,drive = <0x0>;
                                allwinner,pull = <0x2>;
                                linux,phandle = <0x27>;
                                phandle = <0x27>;
                        };
                };
...
        usb0-vbus {
                compatible = "regulator-fixed";
                pinctrl-names = "default";
                pinctrl-0 = <0x3d>;
                regulator-name = "usb0-vbus";
                regulator-min-microvolt = <0x4c4b40>;
                regulator-max-microvolt = <0x4c4b40>;
                enable-active-high;
                gpio = <0x1e 0x2 0x11 0x0>;
                status = "okay";
                linux,phandle = <0x28>;
                phandle = <0x28>;
        };

sorry for the above code but I have used re-compiled dtb file for testing purposes.

Best regards
Chris

[Christo Radev]

Thanks again Michal,

Proposed solution makes USB OTG to work in host only mode.
"usb0-vbus: disabling" message is gone and usb0-vbus goes hi at boot.

Unfortunately, it solves the problem on a half.
Where could be the rest of the problem - USB OTG to work as device at dr_mode = "otg"?

Thanks a lot and best regards

Chris

On Wednesday, May 4, 2016 at 1:26:14 PM UTC+3, Michal Suchanek wrote:

[Christo Radev]

Hi to All,

There you are the final patch I have used against kernel 4.5.2 to enable 'host' only mode on USB OTG on A20-Olinuxino-Lime2-eMMC:

diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index d5c796c..d09cebe 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -215,20 +215,6 @@
         allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
     };
 
-    usb0_id_detect_pin: usb0_id_detect_pin@0 {
-        allwinner,pins = "PH4";
-        allwinner,function = "gpio_in";
-        allwinner,drive = <SUN4I_PINCTRL_10_MA>;
-        allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
-    };
-
-    usb0_vbus_detect_pin: usb0_vbus_detect_pin@0 {
-        allwinner,pins = "PH5";
-        allwinner,function = "gpio_in";
-        allwinner,drive = <SUN4I_PINCTRL_10_MA>;
-        allwinner,pull = <SUN4I_PINCTRL_PULL_DOWN>;
-    };
-
     usb0_vbus_pin_lime2: usb0_vbus_pin@0 {
         allwinner,pins = "PC17";
         allwinner,function = "gpio_out";
@@ -264,15 +250,11 @@
 };
 
 &usb_otg {
-    dr_mode = "otg";
+    dr_mode = "host";
     status = "okay";
 };
 
 &usbphy {
-    pinctrl-names = "default";
-    pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
-    usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
-    usb0_vbus_det-gpio = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
     usb0_vbus-supply = <&reg_usb0_vbus>;
     usb1_vbus-supply = <&reg_usb1_vbus>;
     usb2_vbus-supply = <&reg_usb2_vbus>;

Corresponding boot messages:

[    3.917976] usb_phy_generic.0.auto supply vcc not found, using dummy regulator
[    3.918578] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver
[    3.918598] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 5
[    3.918979] usb usb5: New USB device found, idVendor=1d6b, idProduct=0002
[    3.918993] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.919004] usb usb5: Product: MUSB HDRC host driver
[    3.919013] usb usb5: Manufacturer: Linux 4.5.2-sunxi musb-hcd
[    3.919022] usb usb5: SerialNumber: musb-hdrc.1.auto

And messages after connecting of USB Flash via USB OTG to Host cable:

[ 1356.542871] usb 5-1: new high-speed USB device number 2 using musb-hdrc
[ 1356.684880] usb 5-1: New USB device found, idVendor=090c, idProduct=1000
[ 1356.684917] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1356.684935] usb 5-1: Product: Flash Voyager
[ 1356.684952] usb 5-1: Manufacturer: Corsair
[ 1356.684968] usb 5-1: SerialNumber: AA00000000001460
[ 1356.686555] usb-storage 5-1:1.0: USB Mass Storage device detected
[ 1356.689189] scsi host1: usb-storage 5-1:1.0
[ 1356.755118] usbcore: registered new interface driver uas

Any ideas how to enable full USB OTG functionality?

Best regards
Chris

[Maxime Ripard]

Hi,

On Thu, May 11, 2017 at 02:45:11PM -0700, Bim Overbohm wrote:
> Hi All,
>
> I had a similar problem running a mainline 4.11 kernel on an A33 tablet
> (marked "Q8-2.4G 20140918". It came from a company called Trimeo and is
> simply called 7". It contains an APX223 power controller, RTL8189ETV WiFi
> controller, 2x Nanya NT5CB128M15FP-DY DRAM chips (2x256MB), a Hynix
> H27UCG8T2BTR-BC NAND-flash chip and a Goodix GT818 touch controller.
> Display resolution is 1024x600). The self-compiled u-boot dtb would
> initialize the USB, but the kernel dtb would not work.

U-Boot doesn't use the DT for this USB setup.

> The kernel messages were something along the lines of "[ 9.366994]
> sun4i-usb-phy 1c19400.phy: could not find pctldev for node
> /soc@01c00000/pinctrl@01c20800/usb0_id_detect_pin@0, deferring
> probe".

That's not likely to be your issue. The probe should be deferred, and
reattempted later.

> I found no way to activate the pinctrl devices, so I fixed this by
> decompiling the dts, removing all the USB id detect pin and vbus
> settings and recompiling the dts (diff at end of message). The
> device boots into LXDE now and I can use an USB keyboard and
> mouse. I still have no WiFi though...
>
> Pastebin of unpatched dts file: https://pastebin.com/kL6WELuC
>
> A couple of questions:
>
> - Is there a proper way to make the pinctrls and OTG dual mode work
> on the device?! I suspect they are needed to activate WiFi too...

As I said, that's probably not your issue. Are you sure of your
micro-USB cable? Is it setting the ID pin to the ground as it's
supposed to?

> - Is this a bug I should report for sunxi-next?

sunxi-next is just a merge of various upstream branches. It doesn't
make sense to report bugs there. You've found the right place already.

> - Is there a driver for the GT818 in the mainline kernel or a way to
> make that device work?

It doesn't look like there is.

> - Is there a driver for the RTL8189ETV in the mainline kernel or a way to
> make that device work?

https://linux-sunxi.org/Wifi#RTL8189ES_.2F_RTL8189ETV

Maxime

--
Maxime Ripard, Free Electrons

Embedded Linux and Kernel engineering
http://free-electrons.com

[Bim Overbohm]

Hi All,

I had a similar problem running a mainline 4.11 kernel on an A33 tablet (marked "Q8-2.4G 20140918". It came from a company called Trimeo and is simply called 7". It contains an APX223 power controller, RTL8189ETV WiFi controller, 2x Nanya NT5CB128M15FP-DY DRAM chips (2x256MB), a Hynix H27UCG8T2BTR-BC NAND-flash chip and a Goodix GT818 touch controller. Display resolution is 1024x600). The self-compiled u-boot dtb would initialize the USB, but the kernel dtb would not work. The kernel messages were something along the lines of "[ 9.366994] sun4i-usb-phy 1c19400.phy: could not find pctldev for node /soc@01c00000/pinctrl@01c20800/usb0_id_detect_pin@0, deferring probe". I found no way to activate the pinctrl devices, so I fixed this by decompiling the dts, removing all the USB id detect pin and vbus settings and recompiling the dts (diff at end of message). The device boots into LXDE now and I can use an USB keyboard and mouse. I still have no WiFi though...

Pastebin of unpatched dts file: https://pastebin.com/kL6WELuC

A couple of questions:
- Is there a proper way to make the pinctrls and OTG dual mode work on the device?! I suspect they are needed to activate WiFi too...

- Is this a bug I should report for sunxi-next?

- Is there a driver for the GT818 in the mainline kernel or a way to make that device work?

- Is there a driver for the RTL8189ETV in the mainline kernel or a way to make that device work?

DIFF of the two dts files:
204c204
<             dr_mode = "otg";
---
>             dr_mode = "host";
217,219d216
<             pinctrl-names = "default";
<             pinctrl-0 = <0xe>;
<             usb0_id_det-gpio = <0x9 0x7 0x8 0x0>;
363,376d359
<             usb1_vbus_pin@0 {
<                 pins = "PH6";
<                 function = "gpio_out";
<                 linux,phandle = <0x38>;
<                 phandle = <0x38>;
<             };
<
<             usb2_vbus_pin@0 {
<                 pins = "PH3";
<                 function = "gpio_out";
<                 linux,phandle = <0x39>;
<                 phandle = <0x39>;
<             };
<
392,398d374
<             usb0_id_detect_pin@0 {
<                 pins = "PH8";
<                 function = "gpio_in";
<                 bias-pull-up;
<                 linux,phandle = <0xe>;
<                 phandle = <0xe>;
<             };

[ 1356.684968] usb 5<span style="color: #660;" class="style

[Bim Overbohm]

Thanks for the info, Maxime.

Will try out the WiFi driver. I've seen a GT9xx driver mentioned in the wiki (http://linux-sunxi.org/Touchscreen#Goodix). Maybe that could be hacked into working with the GT818. Or the GT818 driver from sunxi-3.4...

About the USB-Problem: I have tried two OTG cables which both work on a different tablet, so I'm pretty sure they work. I have uploaded a paste of kern.log here: https://pastebin.com/CV5cQZJA Maybe this will shed some more light on what's wrong. I could also deliver more info or try patches if necessary...

Best Regards,
Bim

[Mahesh Nanavalla]

hi...

can u any body suggest for OTG Dual Role on NanoPi Neo .

On Wednesday, August 5, 2015 at 2:56:18 AM UTC+5:30, Hans de Goede wrote:

For some unclear reason sometimes we get VBus errors in host-only mode,
even though we do not have any vbus-detection then. Ignore these.

Signed-off-by: Hans de Goede <hdeg...@redhat.com>
---
 drivers/usb/musb/sunxi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index f9f6304..34ce5df 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -194,6 +194,10 @@ static irqreturn_t sunxi_musb_interrupt(int irq, void *__hci)
                 musb_writeb(musb->mregs, MUSB_FADDR, 0);
         }
 
+        /*  Ignore Vbus errors when in host only mode */
+        if (musb->port_mode == MUSB_PORT_MODE_HOST)
+                musb->int_usb &= ~MUSB_INTR_VBUSERROR;
+
         musb->int_tx = readw(musb->mregs + SUNXI_MUSB_INTRTX);
         if (musb->int_tx)
                 writew(musb->int_tx, musb->mregs + SUNXI_MUSB_INTRTX);
--
2.4.3