All of lore.kernel.org
 help / color / mirror / Atom feed
From: oliver+list@schinagl.nl (Olliver Schinagl)
To: linux-arm-kernel@lists.infradead.org
Subject: [linux-sunxi] [PATCH] musb: sunxi: Ignore VBus errors in host-only mode
Date: Fri, 04 Sep 2015 08:43:24 +0200	[thread overview]
Message-ID: <55E93D8C.9020804@schinagl.nl> (raw)
In-Reply-To: <55C47041.3000603@schinagl.nl>

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

  reply	other threads:[~2015-09-04  6:43 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-04 21:25 [PATCH] musb: sunxi: Ignore VBus errors in host-only mode Hans de Goede
2015-08-04 21:35 ` Felipe Balbi
2015-08-04 22:05   ` Hans de Goede
2015-08-04 22:57     ` Felipe Balbi
2015-08-05 13:30       ` Hans de Goede
2015-08-06  8:22 ` [linux-sunxi] " Olliver Schinagl
2015-08-06 14:35   ` Hans de Goede
2015-08-07  8:45     ` Olliver Schinagl
2015-09-04  6:43       ` Olliver Schinagl [this message]
2015-09-10 18:23         ` Hans de Goede
2015-09-10 18:30           ` Maxime Ripard
2015-09-10 18:38             ` Hans de Goede
2015-09-14 14:44               ` Bin Liu
2015-09-14 14:59                 ` Hans de Goede
2015-09-14 16:58                   ` Bin Liu
2015-09-14 17:08                     ` Hans de Goede
2015-09-14 17:14                       ` Bin Liu
2015-09-14 17:25                         ` Hans de Goede
2015-09-14 17:53                           ` Bin Liu
2015-09-14 17:56                             ` Hans de Goede
2015-09-14 19:06                               ` Bin Liu
2015-09-14 20:25               ` Maxime Ripard
2015-09-15  2:54                 ` Hans de Goede
2015-09-15  4:20                   ` Bin Liu
2016-05-04 10:25                 ` Michal Suchanek
     [not found]                   ` <706aa130-3ace-4059-a7c9-44147cd56c28@googlegroups.com>
     [not found]                     ` <af013a0a-9257-4936-9e66-cb38f2e46369@googlegroups.com>
     [not found]                       ` <0106707e-21f3-4aec-92ca-8b951af8a34e@googlegroups.com>
2017-05-12  9:16                         ` Maxime Ripard
2015-09-26 12:50           ` Olliver Schinagl
     [not found]             ` <jwvmvw7zzg5.fsf-monnier+gmane.comp.hardware.netbook.arm.sunxi@gnu.org>
2015-09-28  7:04               ` [linux-sunxi] " Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55E93D8C.9020804@schinagl.nl \
    --to=oliver+list@schinagl.nl \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.