linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: heiko@sntech.de (Heiko Stuebner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] dt-bindings: phy: phy-rockchip-typec: add usb3 otg reset
Date: Sat, 10 Feb 2018 20:55:45 +0100	[thread overview]
Message-ID: <1907466.pgqOKPpIkg@phil> (raw)
In-Reply-To: <d05fb977-cd6c-4875-25be-9212e75b7e39@rock-chips.com>

Hi Wulf,

Am Montag, 22. Januar 2018, 12:33:05 CET schrieb wlf:
> ? 2018?01?20? 05:49, Rob Herring ??:
> > On Thu, Jan 18, 2018 at 09:47:50AM -0800, Brian Norris wrote:
> >> On Thu, Jan 18, 2018 at 06:20:09PM +0100, Enric Balletbo Serra wrote:
> >>> As Brian said commit 06c47e6286d5 'usb: dwc3: of-simple: Add support
> >>> to get resets for the device' introduced the support to get the resets
> >>> from dwc3-of-simple and the queued commit 'b7e63d95c14d arm64: dts:
> >>> rockchip: add reset property for dwc3 controllers on rk3399' started
> >>> using it. Without the latest I get errors like this doing bind/unbind
> >>> tests.
> >>>
> >>>     dwc3: probe of fe900000.dwc3 failed with error -110
> >>>
> >>> I just tested these series on top of mainline, I reverted my patch
> >>> because otherwise two drivers are requesting the same reset and fails,
> >>> and I did some of the bind/unbind test. They just worked fine, and
> >>> seems that this is right way, so this makes me think some questions.
> >> Actually, this was intended to coexist with DWC3 optionally controlling
> >> the same reset. It was written before the reset framework was rewritten
> >> to have shared and exclusive resets. Should this be rewritten to use
> >> shared resets? We'd have to modify both dwc3 core and the PHY driver.
> > Seems like abuse of DT to me. If you need to control the controller's
> > reset from the phy driver, then get the reset out of the controller
> > node. The phy node should describe the connections to the phy.
> I try to get the reset out of the controller, but I don't find a good
> way to get the reset ofthe controller associated with the given phy
> device node.  Is there an API like theof_usb_get_dr_mode_by_phy() to
> get 'dr_mode' of the controller?

I guess the easiest way would be taking the of_usb_get_dr_mode_by_phy()
function move the part above the "finish" label into a separate function
like of_usb_get_node_by_phy (or possibly move that to an even more general
place as it is not usb-related at all) and use that function in
of_usb_get_dr_mode_by_phy() and also use it to get the reset you want via
something like:

node = of_usb_get_node_by_phy(...);
rst = of_reset_control_get(node, ...);

> And we're trying to find another method to fix the RK3399 tcphy power
> on fail issue.If we get another proper method, we may not need these
> phy patch series.

Did you find any different solution for that yet?

Heiko

  parent reply	other threads:[~2018-02-10 19:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-12 10:08 [PATCH 0/3] Reset USB3 controller before initializing Type-C PHY on rk3399 William Wu
2018-01-12 10:08 ` [PATCH 1/3] dt-bindings: phy: phy-rockchip-typec: add usb3 otg reset William Wu
2018-01-17 22:07   ` Brian Norris
2018-01-18 17:20     ` Enric Balletbo Serra
2018-01-18 17:47       ` Brian Norris
2018-01-19 21:49         ` Rob Herring
     [not found]           ` <d05fb977-cd6c-4875-25be-9212e75b7e39@rock-chips.com>
2018-02-10 19:55             ` Heiko Stuebner [this message]
2018-02-12 16:40               ` wlf
2018-01-12 10:08 ` [PATCH 2/3] arm64: dts: rockchip: add USB3 OTG reset for Type-C PHY on rk3399 William Wu
2018-01-18 17:21   ` Enric Balletbo Serra
2018-01-12 10:08 ` [PATCH 3/3] phy: rockchip-typec: reset USB3 controller before initializing PHY William Wu
2018-01-18 17:22   ` Enric Balletbo Serra

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=1907466.pgqOKPpIkg@phil \
    --to=heiko@sntech.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).