From: robh@kernel.org (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 03/22] usb: ulpi: Support device discovery via device properties
Date: Sun, 17 Jul 2016 21:23:55 -0500 [thread overview]
Message-ID: <20160718022355.GA8568@rob-hp-laptop> (raw)
In-Reply-To: <20160707222114.1673-4-stephen.boyd@linaro.org>
On Thu, Jul 07, 2016 at 03:20:54PM -0700, Stephen Boyd wrote:
> The qcom HSIC ULPI phy doesn't have any bits set in the vendor or
> product ID registers. This makes it impossible to make a ULPI
> driver match against the ID registers. Add support to discover
> the ULPI phys via DT/device properties to help alleviate this
> problem. In the DT case, we'll look for a ULPI bus node
> underneath the device registering the ULPI viewport (or the
> parent of that device to support chipidea's device layout) and
> then match up the phy node underneath that with the ULPI device
> that's created.
>
> The side benefit of this is that we can use standard properties
> in the phy node like clks, regulators, gpios, etc. because we
> don't have firmware like ACPI to turn these things on for us. And
> we can use the DT phy binding to point our phy consumer to the
> phy provider.
>
> Furthermore, this avoids any problems with reading the ID
> registers before the phy is powered up. The ULPI bus supports
> native enumeration by reading the vendor ID and product ID
> registers at device creation time, but we can't be certain that
> those register reads will succeed if the phy is not powered.
>
> If the ULPI spec had some generic power sequencing for these
> registers we could put that into the ULPI bus layer and power up
> the device before reading the ID registers. Unfortunately this
> doesn't exist and the power sequence is usually device specific.
> By having the vendor and product ID properties in ACPI or DT, we
> can match up devices with drivers without having to read the
> hardware before it's powered up and avoid this problem.
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> Cc: <devicetree@vger.kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> ---
> Documentation/devicetree/bindings/usb/ulpi.txt | 35 ++++++++++++
> drivers/usb/common/ulpi.c | 74 +++++++++++++++++++++++++-
> 2 files changed, 107 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/usb/ulpi.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/ulpi.txt b/Documentation/devicetree/bindings/usb/ulpi.txt
> new file mode 100644
> index 000000000000..c649ca5b0996
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/ulpi.txt
> @@ -0,0 +1,35 @@
> +ULPI bus binding
> +----------------
> +
> +Phys that are behind a ULPI connection can be described with the following
> +binding. The host controller shall have a "ulpi" named node as a child, and
> +that node shall have one enabled node underneath it representing the ulpi
> +device on the bus.
> +
> +PROPERTIES
> +----------
> +
> +- ulpi-vendor:
> + Usage: optional
> + Value type: <u16>
> + Definition: The USB-IF assigned vendor id for this device
> +
> +- ulpi-product:
> + Usage: required if ulpi-vendor is present
> + Value type: <u16>
> + Definition: The vendor assigned product id for this device
> +
> +EXAMPLE
> +-------
> +
> +usb {
> + compatible = "vendor,usb-controller";
> +
> + ulpi {
> + phy {
> + compatible = "vendor,phy";
> + ulpi-vendor = /bits/ 16 <0x1d6b>;
> + ulpi-product = /bits/ 16 <0x0002>;
> + };
> + };
I'm still having concerns about describing both phys and devices. If I
have a controller with 2 ports and 2 devices attached, I'd have
something like this under the USB controller:
ulpi {
phy at 1 {
};
phy at 2 {
};
};
dev at 1 {
...
};
dev at 2 {
...
};
That doesn't seem the best, but I don't have a better suggestion. Maybe
the device nodes need to go under the phy nodes?
Rob
next prev parent reply other threads:[~2016-07-18 2:23 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-07 22:20 [PATCH v2 00/22] Support qcom's HSIC USB and rewrite USB2 HS phy support Stephen Boyd
2016-07-07 22:20 ` [PATCH v2 01/22] of: device: Support loading a module with OF based modalias Stephen Boyd
2016-07-07 22:20 ` [PATCH v2 02/22] of: device: Export of_device_{get_modalias, uvent_modalias} to modules Stephen Boyd
2016-07-07 22:20 ` [PATCH v2 03/22] usb: ulpi: Support device discovery via device properties Stephen Boyd
2016-07-08 9:04 ` Peter Chen
2016-08-05 21:27 ` Stephen Boyd
2016-08-23 19:58 ` Stephen Boyd
2016-08-24 7:31 ` Heikki Krogerus
2016-08-26 18:54 ` Stephen Boyd
2016-07-18 2:23 ` Rob Herring [this message]
2016-08-05 21:40 ` Stephen Boyd
2016-08-23 20:00 ` Stephen Boyd
2016-08-23 23:06 ` Rob Herring
2016-08-24 1:06 ` Stephen Boyd
2016-07-07 22:20 ` [PATCH v2 04/22] usb: chipidea: Only read/write OTGSC from one place Stephen Boyd
2016-07-08 9:14 ` Peter Chen
2016-08-05 21:41 ` Stephen Boyd
2016-08-06 7:42 ` Peter Chen
2016-07-07 22:20 ` [PATCH v2 05/22] usb: chipidea: Handle extcon events properly Stephen Boyd
2016-07-07 22:20 ` [PATCH v2 06/22] usb: chipidea: Add platform flag for wrapper phy management Stephen Boyd
2016-07-08 9:25 ` Peter Chen
2016-08-05 21:46 ` Stephen Boyd
2016-08-06 7:59 ` Peter Chen
2016-08-08 23:46 ` Stephen Boyd
2016-08-09 0:36 ` Peter Chen
2016-07-07 22:20 ` [PATCH v2 07/22] usb: chipidea: Notify events when switching host mode Stephen Boyd
2016-07-08 9:29 ` Peter Chen
2016-07-07 22:20 ` [PATCH v2 08/22] usb: chipidea: Remove locking in ci_udc_start() Stephen Boyd
2016-07-08 9:45 ` Peter Chen
2016-08-05 21:53 ` Stephen Boyd
2016-08-06 7:54 ` Peter Chen
2016-08-08 23:47 ` Stephen Boyd
2016-08-09 0:42 ` Peter Chen
2016-07-07 22:21 ` [PATCH v2 09/22] usb: chipidea: Kick OTG state machine for AVVIS with vbus extcon Stephen Boyd
2016-07-11 2:25 ` Peter Chen
2016-07-07 22:21 ` [PATCH v2 10/22] usb: chipidea: Add support for ULPI PHY bus Stephen Boyd
2016-07-11 3:10 ` Peter Chen
2016-07-11 22:02 ` Stephen Boyd
2016-07-07 22:21 ` [PATCH v2 11/22] usb: chipidea: msm: Mark device as runtime pm active Stephen Boyd
2016-07-11 3:19 ` Peter Chen
2016-07-07 22:21 ` [PATCH v2 12/22] usb: chipidea: msm: Rely on core to override AHBBURST Stephen Boyd
2016-07-11 3:24 ` Peter Chen
2016-07-07 22:21 ` [PATCH v2 13/22] usb: chipidea: msm: Use hw_write_id_reg() instead of writel Stephen Boyd
2016-07-07 22:21 ` [PATCH v2 14/22] usb: chipidea: msm: Add proper clk and reset support Stephen Boyd
2016-07-11 4:32 ` Peter Chen
2016-07-07 22:21 ` [PATCH v2 15/22] usb: chipidea: msm: Mux over secondary phy at the right time Stephen Boyd
2016-07-11 4:43 ` Peter Chen
2016-07-11 22:03 ` Stephen Boyd
2016-07-12 1:07 ` Peter Chen
2016-07-07 22:21 ` [PATCH v2 16/22] usb: chipidea: msm: Restore wrapper settings after reset Stephen Boyd
2016-07-11 5:24 ` Peter Chen
2016-07-07 22:21 ` [PATCH v2 17/22] usb: chipidea: msm: Make platform data driver local instead of global Stephen Boyd
2016-07-11 5:26 ` Peter Chen
2016-07-07 22:21 ` [PATCH v2 18/22] usb: chipidea: msm: Add reset controller for PHY POR bit Stephen Boyd
2016-07-11 5:32 ` Peter Chen
2016-07-11 22:07 ` Stephen Boyd
2016-07-12 1:09 ` Peter Chen
2016-07-07 22:21 ` [PATCH v2 19/22] usb: chipidea: msm: Handle phy power states Stephen Boyd
2016-07-11 5:38 ` Peter Chen
2016-07-07 22:21 ` [PATCH v2 20/22] usb: chipidea: msm: Be silent on probe defer errors Stephen Boyd
2016-07-11 5:39 ` Peter Chen
2016-07-07 22:21 ` [PATCH v2 21/22] phy: Add support for Qualcomm's USB HSIC phy Stephen Boyd
2016-07-18 2:27 ` Rob Herring
2016-07-07 22:21 ` [PATCH v2 22/22] phy: Add support for Qualcomm's USB HS phy Stephen Boyd
2016-07-18 2:28 ` Rob Herring
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=20160718022355.GA8568@rob-hp-laptop \
--to=robh@kernel.org \
--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).