Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1391007 > unrolled thread

[RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

Back to article view | Back to linux.kernel

Contents

  [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP  booting Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-04-29 13:10 +0200
    [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader  initialization Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-04-29 13:10 +0200
      Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after  bootloader initialization Mark Brown <broonie@kernel.org> - 2016-04-29 13:40 +0200
        Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader  initialization Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-04-29 14:00 +0200
          Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after  bootloader initialization Mark Brown <broonie@kernel.org> - 2016-04-29 18:50 +0200
            Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader  initialization Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-05-02 11:50 +0200
              Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader  initialization Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-05-02 12:50 +0200
              Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after  bootloader initialization Mark Brown <broonie@kernel.org> - 2016-05-02 13:00 +0200
                Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after  bootloader initialization Rob Herring <robh@kernel.org> - 2016-05-03 20:10 +0200
                  Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader  initialization Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-05-04 14:10 +0200
                    Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after  bootloader initialization Mark Brown <broonie@kernel.org> - 2016-05-04 20:30 +0200
    Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP  booting Hans Verkuil <hverkuil@xs4all.nl> - 2016-04-30 11:50 +0200
      Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP  booting Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-05-01 15:20 +0200
        Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP  booting Hans Verkuil <hverkuil@xs4all.nl> - 2016-05-01 16:20 +0200
          Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP  booting Hans Verkuil <hverkuil@xs4all.nl> - 2016-05-01 18:10 +0200
            Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP  booting Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-05-01 18:50 +0200
              Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP  booting Hans Verkuil <hverkuil@xs4all.nl> - 2016-05-02 15:50 +0200
                Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP  booting Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-05-02 15:50 +0200
            Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP  booting Marek Szyprowski <m.szyprowski@samsung.com> - 2016-05-02 08:00 +0200

#1391007 — [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

Hi,

Patches are independent, please pick up as you wish.

However all of them are needed to solve the issue, so I am sending
everything together for easier testng.


Problem
=======
When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
the usb3503 does not show up in "lsusb". Hard-reset is required, e.g.
by suspend to RAM. The actual TFTP boot does not have to happen. Just
"usb start" from U-Boot is sufficient.


Solution
========
Perform real hardware reset (including regulator off/on) when probing.


Tested on Odroid U3 so far. Please kindly test on X2 and other
configurations and bootloaders.


Best regards,
Krzysztof

Krzysztof Kozlowski (3):
  usb: misc: usb3503: Fix HUB mode after bootloader initialization
  ARM: dts: exynos: Provide regulator for usb3503 on Odroid to fix
    device detection
  regulator: max77686: Configure enable time to properly handle
    regulator enable

 Documentation/devicetree/bindings/usb/usb3503.txt |  1 +
 arch/arm/boot/dts/exynos4412-odroidu3.dts         |  2 +
 drivers/regulator/max77686-regulator.c            |  5 ++
 drivers/usb/misc/usb3503.c                        | 81 +++++++++++++++++++++++
 4 files changed, 89 insertions(+)

-- 
1.9.1

[toc] | [next] | [standalone]

#1391008 — [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization

On Odroid U3 (Exynos4412-based) board if USB was initialized by
bootloader (in U-Boot "usb start" before tftpboot), the HUB after after
successful probing was not visible in the system ("lsusb"). Connected
devices were not visible neither.

In such case the USB3503 has to be fully reset before configuring to HUB
mode. Reset by GPIO (called RESET_N pin) and by RESET field in STCD
register are not sufficient. Instead full reset has to be done by
disabling and enabling regulator.

The USB3503 can work with different regulator configurations, however
toggling of only one is relevant in mentioned case: the VDD 3.3V.

The patch adds:
1. New binding for optional regulator (VDD33),
2. Code for toggling the regulator on/off before doing reset by GPIO,
3. Initial reset during probing before configuring HUB mode.

Patch is very loosely based on Tobias Jakobi's similar work for usb3503.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>

---

Tested on Odroid U3 so far. Please kindly test on X2 or other
configurations and bootloaders.
---
 Documentation/devicetree/bindings/usb/usb3503.txt |  1 +
 drivers/usb/misc/usb3503.c                        | 81 +++++++++++++++++++++++
 2 files changed, 82 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt b/Documentation/devicetree/bindings/usb/usb3503.txt
index c1a0a9191d26..36516ade9467 100644
--- a/Documentation/devicetree/bindings/usb/usb3503.txt
+++ b/Documentation/devicetree/bindings/usb/usb3503.txt
@@ -24,6 +24,7 @@ Optional properties:
 	pins (optional, if not provided, driver will not set rate of the
 	REFCLK signal and assume that a value from the primary reference
 	clock frequencies table is used)
+- vdd33-supply: Optional supply for VDD 3.3 V power source.
 
 Examples:
 	usb3503@08 {
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index b45cb77c0744..8905e8b2439d 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -28,6 +28,7 @@
 #include <linux/platform_device.h>
 #include <linux/platform_data/usb3503.h>
 #include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
 
 #define USB3503_VIDL		0x00
 #define USB3503_VIDM		0x01
@@ -59,6 +60,7 @@ struct usb3503 {
 	struct regmap		*regmap;
 	struct device		*dev;
 	struct clk		*clk;
+	struct regulator	*vdd_reg;
 	u8	port_off_mask;
 	int	gpio_intn;
 	int	gpio_reset;
@@ -66,8 +68,31 @@ struct usb3503 {
 	bool	secondary_ref_clk;
 };
 
+static int usb3503_regulator(struct usb3503 *hub, int state)
+{
+	int ret;
+
+	if (!hub->vdd_reg)
+		return 0;
+
+	if (state)
+		ret = regulator_enable(hub->vdd_reg);
+	else
+		ret = regulator_disable(hub->vdd_reg);
+
+	return ret;
+}
+
 static int usb3503_reset(struct usb3503 *hub, int state)
 {
+	int err;
+
+	err = usb3503_regulator(hub, state);
+	if (err) {
+		dev_err(hub->dev, "unable to %s VDD33 regulator to (%d)\n",
+			(state ? "enable" : "disable"), err);
+	}
+
 	if (!state && gpio_is_valid(hub->gpio_connect))
 		gpio_set_value_cansleep(hub->gpio_connect, 0);
 
@@ -260,6 +285,15 @@ static int usb3503_probe(struct usb3503 *hub)
 			return -EPROBE_DEFER;
 		of_property_read_u32(np, "initial-mode", &mode);
 		hub->mode = mode;
+
+		hub->vdd_reg = devm_regulator_get_optional(dev, "vdd33");
+		if (IS_ERR(hub->vdd_reg)) {
+			if (PTR_ERR(hub->vdd_reg) == -EPROBE_DEFER)
+				return -EPROBE_DEFER;
+			hub->vdd_reg = NULL;
+		} else {
+			dev_dbg(dev, "Using VDD33 regulator for full reset\n");
+		}
 	}
 
 	if (hub->port_off_mask && !hub->regmap)
@@ -299,6 +333,21 @@ static int usb3503_probe(struct usb3503 *hub)
 			return err;
 		}
 	}
+	err = usb3503_regulator(hub, true);
+	if (err) {
+		dev_err(dev, "unable to enable VDD33 regulator (%d)\n", err);
+		return err;
+	}
+
+	/*
+	 * Perform real full reset before configuring.
+	 * On some boards (e.g. on Odroid U3 board with LAN9730/SMSC95xx)
+	 * after enabling the USB by bootloader it has to be fully reset
+	 * here to be visible.
+	 */
+	usb3503_reset(hub, 0);
+	/* Settle down before powering on again */
+	usleep_range(4000, 10000);
 
 	usb3503_switch_mode(hub, hub->mode);
 
@@ -330,6 +379,21 @@ static int usb3503_i2c_probe(struct i2c_client *i2c,
 	return usb3503_probe(hub);
 }
 
+static int usb3503_i2c_remove(struct i2c_client *i2c)
+{
+	struct usb3503 *hub;
+
+	hub = i2c_get_clientdata(i2c);
+	if (hub) {
+		if (hub->clk)
+			clk_disable_unprepare(hub->clk);
+
+		usb3503_regulator(hub, false);
+	}
+
+	return 0;
+}
+
 static int usb3503_platform_probe(struct platform_device *pdev)
 {
 	struct usb3503 *hub;
@@ -342,6 +406,21 @@ static int usb3503_platform_probe(struct platform_device *pdev)
 	return usb3503_probe(hub);
 }
 
+static int usb3503_platform_remove(struct platform_device *pdev)
+{
+	struct usb3503 *hub;
+
+	hub = platform_get_drvdata(pdev);
+	if (hub) {
+		if (hub->clk)
+			clk_disable_unprepare(hub->clk);
+
+		usb3503_regulator(hub, false);
+	}
+
+	return 0;
+}
+
 #ifdef CONFIG_PM_SLEEP
 static int usb3503_i2c_suspend(struct device *dev)
 {
@@ -395,6 +474,7 @@ static struct i2c_driver usb3503_i2c_driver = {
 		.of_match_table = of_match_ptr(usb3503_of_match),
 	},
 	.probe		= usb3503_i2c_probe,
+	.remove		= usb3503_i2c_remove,
 	.id_table	= usb3503_id,
 };
 
@@ -404,6 +484,7 @@ static struct platform_driver usb3503_platform_driver = {
 		.of_match_table = of_match_ptr(usb3503_of_match),
 	},
 	.probe		= usb3503_platform_probe,
+	.remove		= usb3503_platform_remove,
 };
 
 static int __init usb3503_init(void)
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1391026 — Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization

[Multipart message — attachments visible in raw view] — view raw

On Fri, Apr 29, 2016 at 12:59:49PM +0200, Krzysztof Kozlowski wrote:

> +++ b/Documentation/devicetree/bindings/usb/usb3503.txt
> @@ -24,6 +24,7 @@ Optional properties:
>  	pins (optional, if not provided, driver will not set rate of the
>  	REFCLK signal and assume that a value from the primary reference
>  	clock frequencies table is used)
> +- vdd33-supply: Optional supply for VDD 3.3 V power source.

Supplies are only optional if they may be physically absent.  In this
case it's possible that on device regulators may be used instead, a
pattern more like that used for arizona-ldo1 where we represent those
regulators might be better as it's more clearly describing the
situation.  I'm just wondering if the supply lookup stuff there should
be factored out as this is not an uncommon pattern..

It should at least be clearly stated what's going on, ignoring failure
to get supplies is generally a bug and people will tend to blindly cut
and paste things (witness all the breakage in graphics drivers with
this).

>  static int usb3503_reset(struct usb3503 *hub, int state)
>  {
> +	int err;
> +
> +	err = usb3503_regulator(hub, state);
> +	if (err) {
> +		dev_err(hub->dev, "unable to %s VDD33 regulator to (%d)\n",
> +			(state ? "enable" : "disable"), err);
> +	}

Are we sure that the callers all balance enables and disables and we
don't ever end up going through reset more than once on the way down?

> +		hub->vdd_reg = devm_regulator_get_optional(dev, "vdd33");
> +		if (IS_ERR(hub->vdd_reg)) {
> +			if (PTR_ERR(hub->vdd_reg) == -EPROBE_DEFER)
> +				return -EPROBE_DEFER;

This should explicitly check for -ENODEV and return the error if it gets
anything else, that will mean that if the supply is needed but lookup
fails somehow due to a non-deferral error we'll handle it properly.

> +	err = usb3503_regulator(hub, true);

The naming on this function is very obscure (and there's also a couple
of other supplies).  I'd suggest just folding this into the reset
function, or at least renaming so the reader can tell what these calls
do.

[toc] | [prev] | [next] | [standalone]

#1391038 — Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization

On 04/29/2016 01:30 PM, Mark Brown wrote:
> On Fri, Apr 29, 2016 at 12:59:49PM +0200, Krzysztof Kozlowski wrote:
> 
>> +++ b/Documentation/devicetree/bindings/usb/usb3503.txt
>> @@ -24,6 +24,7 @@ Optional properties:
>>  	pins (optional, if not provided, driver will not set rate of the
>>  	REFCLK signal and assume that a value from the primary reference
>>  	clock frequencies table is used)
>> +- vdd33-supply: Optional supply for VDD 3.3 V power source.
> 
> Supplies are only optional if they may be physically absent.  In this
> case it's possible that on device regulators may be used instead, a
> pattern more like that used for arizona-ldo1 where we represent those
> regulators might be better as it's more clearly describing the
> situation.  I'm just wondering if the supply lookup stuff there should
> be factored out as this is not an uncommon pattern..
> 
> It should at least be clearly stated what's going on, ignoring failure
> to get supplies is generally a bug and people will tend to blindly cut
> and paste things (witness all the breakage in graphics drivers with
> this).

The device has four power input lines (called VBAT, VDD33, VDD_CORE and
VDD_12). Datasheet describes 4 valid configurations... but impression of
the Odroid U3 board schematics is that they used another (custom?)
configuration.

I did not add rest of regulators on purpose:
1. I don't have other configurations to test.
2. It is rather old device, so I don't expect active development.

The VDD33 is really optional. The device can work in different
configuration, e.g. only on VBAT. How the reset logic would work then? I
don't know... I would suspect that it could be exactly the same (just
replace VDD33 with VBAT) but I am not sure.

>>  static int usb3503_reset(struct usb3503 *hub, int state)
>>  {
>> +	int err;
>> +
>> +	err = usb3503_regulator(hub, state);
>> +	if (err) {
>> +		dev_err(hub->dev, "unable to %s VDD33 regulator to (%d)\n",
>> +			(state ? "enable" : "disable"), err);
>> +	}
> 
> Are we sure that the callers all balance enables and disables and we
> don't ever end up going through reset more than once on the way down?

I double checked the code and there might be in-balance if DT or
platform data sets initial mode to suspend. Otherwise it should be balanced.

I'll re-think the patch and fix this.

> 
>> +		hub->vdd_reg = devm_regulator_get_optional(dev, "vdd33");
>> +		if (IS_ERR(hub->vdd_reg)) {
>> +			if (PTR_ERR(hub->vdd_reg) == -EPROBE_DEFER)
>> +				return -EPROBE_DEFER;
> 
> This should explicitly check for -ENODEV and return the error if it gets
> anything else, that will mean that if the supply is needed but lookup
> fails somehow due to a non-deferral error we'll handle it properly.

I must admit I wasn't sure about handling the ENODEV and some other
examples (drivers) were handling this just like that.

Thanks for pointing this out.

> 
>> +	err = usb3503_regulator(hub, true);
> 
> The naming on this function is very obscure (and there's also a couple
> of other supplies).  I'd suggest just folding this into the reset
> function, or at least renaming so the reader can tell what these calls
> do.

Okay.

Thanks for feedback!

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1391291 — Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization

[Multipart message — attachments visible in raw view] — view raw

On Fri, Apr 29, 2016 at 01:55:14PM +0200, Krzysztof Kozlowski wrote:
> On 04/29/2016 01:30 PM, Mark Brown wrote:

> > Supplies are only optional if they may be physically absent.  In this
> > case it's possible that on device regulators may be used instead, a
> > pattern more like that used for arizona-ldo1 where we represent those
> > regulators might be better as it's more clearly describing the
> > situation.  I'm just wondering if the supply lookup stuff there should
> > be factored out as this is not an uncommon pattern..

> > It should at least be clearly stated what's going on, ignoring failure
> > to get supplies is generally a bug and people will tend to blindly cut
> > and paste things (witness all the breakage in graphics drivers with
> > this).

> The VDD33 is really optional. The device can work in different
> configuration, e.g. only on VBAT. How the reset logic would work then? I
> don't know... I would suspect that it could be exactly the same (just
> replace VDD33 with VBAT) but I am not sure.

What the Arizona example I mentioned does is look for the property
specifying an external supply in DT and if there isn't one assumes that
it must be using the internal regulator.  That's a bit icky but it does
the right thing and is much simpler from a user point of view.

[toc] | [prev] | [next] | [standalone]

#1392096 — Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization

On 04/29/2016 06:44 PM, Mark Brown wrote:
> On Fri, Apr 29, 2016 at 01:55:14PM +0200, Krzysztof Kozlowski wrote:
>> On 04/29/2016 01:30 PM, Mark Brown wrote:
> 
>>> Supplies are only optional if they may be physically absent.  In this
>>> case it's possible that on device regulators may be used instead, a
>>> pattern more like that used for arizona-ldo1 where we represent those
>>> regulators might be better as it's more clearly describing the
>>> situation.  I'm just wondering if the supply lookup stuff there should
>>> be factored out as this is not an uncommon pattern..
> 
>>> It should at least be clearly stated what's going on, ignoring failure
>>> to get supplies is generally a bug and people will tend to blindly cut
>>> and paste things (witness all the breakage in graphics drivers with
>>> this).
> 
>> The VDD33 is really optional. The device can work in different
>> configuration, e.g. only on VBAT. How the reset logic would work then? I
>> don't know... I would suspect that it could be exactly the same (just
>> replace VDD33 with VBAT) but I am not sure.
> 
> What the Arizona example I mentioned does is look for the property
> specifying an external supply in DT and if there isn't one assumes that
> it must be using the internal regulator.  That's a bit icky but it does
> the right thing and is much simpler from a user point of view.

Okay, that indeed looks similar... in case of lack of external supplies
the usb3503 pins should be tied to the internal regulators.

However it seems I was wrong at the beginning. We've been looking here
at the schematics and the datasheet. The design is unfortunately a
little bit confusing but finally I think we got the impression how does
it work.

This VDD regulator supply actually is not a usb3503 USB HUB regulator
supply... but a supply to the LAN attached to this HUB. Regulator off/on
is needed for LAN to show up. The hub will show up with typical reset
(which is also missing before my patchset btw).

The LAN, as a USB device, is auto-probed so it cannot take the regulator
and play with it. The simplest idea I have is to add it as "external
supply"  to the parent: usb3503.

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1392122 — Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization

On 05/02/2016 11:49 AM, Krzysztof Kozlowski wrote:
> On 04/29/2016 06:44 PM, Mark Brown wrote:
>> On Fri, Apr 29, 2016 at 01:55:14PM +0200, Krzysztof Kozlowski wrote:
>>> On 04/29/2016 01:30 PM, Mark Brown wrote:
>>
>>>> Supplies are only optional if they may be physically absent.  In this
>>>> case it's possible that on device regulators may be used instead, a
>>>> pattern more like that used for arizona-ldo1 where we represent those
>>>> regulators might be better as it's more clearly describing the
>>>> situation.  I'm just wondering if the supply lookup stuff there should
>>>> be factored out as this is not an uncommon pattern..
>>
>>>> It should at least be clearly stated what's going on, ignoring failure
>>>> to get supplies is generally a bug and people will tend to blindly cut
>>>> and paste things (witness all the breakage in graphics drivers with
>>>> this).
>>
>>> The VDD33 is really optional. The device can work in different
>>> configuration, e.g. only on VBAT. How the reset logic would work then? I
>>> don't know... I would suspect that it could be exactly the same (just
>>> replace VDD33 with VBAT) but I am not sure.
>>
>> What the Arizona example I mentioned does is look for the property
>> specifying an external supply in DT and if there isn't one assumes that
>> it must be using the internal regulator.  That's a bit icky but it does
>> the right thing and is much simpler from a user point of view.
> 
> Okay, that indeed looks similar... in case of lack of external supplies
> the usb3503 pins should be tied to the internal regulators.
> 
> However it seems I was wrong at the beginning. We've been looking here
> at the schematics and the datasheet. The design is unfortunately a
> little bit confusing but finally I think we got the impression how does
> it work.
> 
> This VDD regulator supply actually is not a usb3503 USB HUB regulator
> supply... but a supply to the LAN attached to this HUB. Regulator off/on
> is needed for LAN to show up. The hub will show up with typical reset
> (which is also missing before my patchset btw).
> 
> The LAN, as a USB device, is auto-probed so it cannot take the regulator
> and play with it. The simplest idea I have is to add it as "external
> supply"  to the parent: usb3503.

I run some more tests which adds more confusion. If the usb3503 hub does
not turn off/on the supply (LAN regulator supply in reality) it usually
does not show up as USB device (lsusb) neither. In such case sometimes
it is present, sometimes not.

"Hardware" reset with regulator fixes all the problems: with LAN and
with USB hub... It really does not match the schematics but apparently
usb3503 also needs the regulator.

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1392123 — Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization

[Multipart message — attachments visible in raw view] — view raw

On Mon, May 02, 2016 at 11:49:12AM +0200, Krzysztof Kozlowski wrote:

> This VDD regulator supply actually is not a usb3503 USB HUB regulator
> supply... but a supply to the LAN attached to this HUB. Regulator off/on
> is needed for LAN to show up. The hub will show up with typical reset
> (which is also missing before my patchset btw).

> The LAN, as a USB device, is auto-probed so it cannot take the regulator
> and play with it. The simplest idea I have is to add it as "external
> supply"  to the parent: usb3503.

This is common enough that that just isn't going to scale well I fear
without some generic handling, either walking child devices at the bus
level or at the device level with a pre-probe() callback to get the
device to power on.  The latter is more appropriate to things like
Slimbus where the device is more likely to do active management at
runtime, it's not clear people are building USB devices like that.

[toc] | [prev] | [next] | [standalone]

#1393705 — Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization

On Mon, May 02, 2016 at 11:55:01AM +0100, Mark Brown wrote:
> On Mon, May 02, 2016 at 11:49:12AM +0200, Krzysztof Kozlowski wrote:
> 
> > This VDD regulator supply actually is not a usb3503 USB HUB regulator
> > supply... but a supply to the LAN attached to this HUB. Regulator off/on
> > is needed for LAN to show up. The hub will show up with typical reset
> > (which is also missing before my patchset btw).
> 
> > The LAN, as a USB device, is auto-probed so it cannot take the regulator
> > and play with it. The simplest idea I have is to add it as "external
> > supply"  to the parent: usb3503.
> 
> This is common enough that that just isn't going to scale well I fear
> without some generic handling, either walking child devices at the bus
> level or at the device level with a pre-probe() callback to get the
> device to power on.  The latter is more appropriate to things like
> Slimbus where the device is more likely to do active management at
> runtime, it's not clear people are building USB devices like that.

There's a new binding and support in -next (.../usb/usb-device.txt) for 
USB devices that should help here. Though, how to handle a hub on USB 
and I2C buses would need to be worked out.

Rob

[toc] | [prev] | [next] | [standalone]

#1394208 — Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization

On 05/03/2016 08:00 PM, Rob Herring wrote:
> On Mon, May 02, 2016 at 11:55:01AM +0100, Mark Brown wrote:
>> On Mon, May 02, 2016 at 11:49:12AM +0200, Krzysztof Kozlowski wrote:
>>
>>> This VDD regulator supply actually is not a usb3503 USB HUB regulator
>>> supply... but a supply to the LAN attached to this HUB. Regulator off/on
>>> is needed for LAN to show up. The hub will show up with typical reset
>>> (which is also missing before my patchset btw).
>>
>>> The LAN, as a USB device, is auto-probed so it cannot take the regulator
>>> and play with it. The simplest idea I have is to add it as "external
>>> supply"  to the parent: usb3503.
>>
>> This is common enough that that just isn't going to scale well I fear
>> without some generic handling, either walking child devices at the bus
>> level or at the device level with a pre-probe() callback to get the
>> device to power on.  The latter is more appropriate to things like
>> Slimbus where the device is more likely to do active management at
>> runtime, it's not clear people are building USB devices like that.
> 
> There's a new binding and support in -next (.../usb/usb-device.txt) for 
> USB devices that should help here. Though, how to handle a hub on USB 
> and I2C buses would need to be worked out.

This binding might help, especially with other idea we have - usage of
pwrseq for the USB hub.

The USB hub, without toggling the regulator off/on, appears as USB
device only sometimes. Apparently there is some timing or other
behavior. not yet known to me.

When playing with regulator, the USB hub and child USB device (LAN) will
appear correctly.

This looks like pwrseq for MMC devices so the idea is to:
1. Move drivers/mmc/core/pwrseq* to separate directory
(drivers/power/pwrseq ?)
2. Add support for pwrseq to USB core,
3. Add new pwrseq driver (or extend existing one): toggling the regulator.
4. Add pwrseq phandle to the DT node of USB hub (to the binding
mentioned by Rob?).


Does it look sensible?

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1394604 — Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization

[Multipart message — attachments visible in raw view] — view raw

On Wed, May 04, 2016 at 02:01:57PM +0200, Krzysztof Kozlowski wrote:

> This looks like pwrseq for MMC devices so the idea is to:
> 1. Move drivers/mmc/core/pwrseq* to separate directory
> (drivers/power/pwrseq ?)
> 2. Add support for pwrseq to USB core,
> 3. Add new pwrseq driver (or extend existing one): toggling the regulator.
> 4. Add pwrseq phandle to the DT node of USB hub (to the binding
> mentioned by Rob?).

> Does it look sensible?

It certainly seems like a similar problem space, USB seems very much
like MMC in both the spec and the way it tends to get used.

[toc] | [prev] | [next] | [standalone]

#1391586

Hi Krzysztof,

On 04/29/2016 12:59 PM, Krzysztof Kozlowski wrote:
> Hi,
> 
> Patches are independent, please pick up as you wish.
> 
> However all of them are needed to solve the issue, so I am sending
> everything together for easier testng.
> 
> 
> Problem
> =======
> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
> the usb3503 does not show up in "lsusb". Hard-reset is required, e.g.
> by suspend to RAM. The actual TFTP boot does not have to happen. Just
> "usb start" from U-Boot is sufficient.
> 
> 
> Solution
> ========
> Perform real hardware reset (including regulator off/on) when probing.
> 
> 
> Tested on Odroid U3 so far. Please kindly test on X2 and other
> configurations and bootloaders.

Against which kernel git repo is this patch?

I did apply this patch series first:

http://www.spinics.net/lists/arm-kernel/msg500764.html

followed by this patch series.

I've tested with both 4.6.0-rc2 and -rc5, but in all cases (even without
applying these patches!) the boot sequence hangs here:

...
[drm] Exynos DRM: using 12c10000.mixer device for DMA mapping operations
exynos-drm exynos-drm: bound 12c10000.mixer (ops mixer_component_ops)
exynos-drm exynos-drm: bound 12d00000.hdmi (ops hdmi_component_ops)
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
Console: switching to colour frame buffer device 240x67
exynos-drm exynos-drm: fb0:  frame buffer device
[drm] Initialized exynos 1.0.0 20110530 on minor 0
brd: module loaded
loop: module loaded
s3c64xx-spi 13930000.spi: spi bus clock parent not specified, using clock
at index 0 as parent
s3c64xx-spi 13930000.spi: number of chip select lines not specified,
assuming 1 chip select line
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
usbcore: registered new interface driver asix
usbcore: registered new interface driver ax88179_178a
usbcore: registered new interface driver cdc_ether
usbcore: registered new interface driver smsc95xx
usbcore: registered new interface driver cdc_ncm
dwc2 12480000.hsotg: Specified GNPTXFDEP=1024 > 768
dwc2 12480000.hsotg: EPs: 16, dedicated fifos, 7808 entries in SPRAM
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-exynos: EHCI EXYNOS driver
exynos-ehci 12580000.ehci: EHCI Host Controller
exynos-ehci 12580000.ehci: new USB bus registered, assigned bus number 1
exynos-ehci 12580000.ehci: irq 51, io mem 0x12580000
exynos-ehci 12580000.ehci: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 4.6.0-rc5-odroid ehci_hcd
usb usb1: SerialNumber: 12580000.ehci
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci-exynos: OHCI EXYNOS driver
usbcore: registered new interface driver usb-storage
usb3503 0-0008: switched to HUB mode
usb3503 0-0008: usb3503_probe: probed in hub mode
using random self ethernet address
using random host ethernet address
usb0: HOST MAC 66:79:ef:11:72:85
usb0: MAC 1e:66:f2:66:8e:2a
using random self ethernet address
using random host ethernet address
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready
dwc2 12480000.hsotg: bound driver g_ether
mousedev: PS/2 mouse device common for all mice
max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0
i2c /dev entries driver
s5p-fimc-md camera: Entity type for entity FIMC.0 was not initialized!
usb 1-2: new high-speed USB device number 2 using exynos-ehci
usb 1-2: New USB device found, idVendor=0424, idProduct=9730
usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
smsc95xx v1.0.4
smsc95xx 1-2:1.0 eth0: register 'smsc95xx' at usb-12580000.ehci-2, smsc95xx
USB 2.0 Ethernet, c2:22:09:f2:5f:e8
usb 1-3: new high-speed USB device number 3 using exynos-ehci
usb 1-3: New USB device found, idVendor=0424, idProduct=3503
usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
hub 1-3:1.0: USB hub found
hub 1-3:1.0: 3 ports detected

No oops, no nothing. It's just sitting there.

Is this a regression that was introduced in 4.6? Or is there some special
new config that needs to be turned on first in 4.6? I've been running
4.5.0-rc3 before this, but I can't apply these patches there because there
is no drivers/regulator/max77686-regulator.c in 4.5.

Regards,

	Hans

> 
> 
> Best regards,
> Krzysztof
> 
> Krzysztof Kozlowski (3):
>   usb: misc: usb3503: Fix HUB mode after bootloader initialization
>   ARM: dts: exynos: Provide regulator for usb3503 on Odroid to fix
>     device detection
>   regulator: max77686: Configure enable time to properly handle
>     regulator enable
> 
>  Documentation/devicetree/bindings/usb/usb3503.txt |  1 +
>  arch/arm/boot/dts/exynos4412-odroidu3.dts         |  2 +
>  drivers/regulator/max77686-regulator.c            |  5 ++
>  drivers/usb/misc/usb3503.c                        | 81 +++++++++++++++++++++++
>  4 files changed, 89 insertions(+)
> 

[toc] | [prev] | [next] | [standalone]

#1391816

On Sat, Apr 30, 2016 at 11:43:44AM +0200, Hans Verkuil wrote:
> Hi Krzysztof,
> 
> On 04/29/2016 12:59 PM, Krzysztof Kozlowski wrote:
> > Hi,
> > 
> > Patches are independent, please pick up as you wish.
> > 
> > However all of them are needed to solve the issue, so I am sending
> > everything together for easier testng.
> > 
> > 
> > Problem
> > =======
> > When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
> > the usb3503 does not show up in "lsusb". Hard-reset is required, e.g.
> > by suspend to RAM. The actual TFTP boot does not have to happen. Just
> > "usb start" from U-Boot is sufficient.
> > 
> > 
> > Solution
> > ========
> > Perform real hardware reset (including regulator off/on) when probing.
> > 
> > 
> > Tested on Odroid U3 so far. Please kindly test on X2 and other
> > configurations and bootloaders.
> 
> Against which kernel git repo is this patch?
> 
> I did apply this patch series first:
> 
> http://www.spinics.net/lists/arm-kernel/msg500764.html

Indeed it is based on above patchset... and on linux-next. It touches
multiple trees so next seems the easiest base.

> 
> followed by this patch series.
> 
> I've tested with both 4.6.0-rc2 and -rc5, but in all cases (even without
> applying these patches!) the boot sequence hangs here:
> 
> ...
> [drm] Exynos DRM: using 12c10000.mixer device for DMA mapping operations
> exynos-drm exynos-drm: bound 12c10000.mixer (ops mixer_component_ops)
> exynos-drm exynos-drm: bound 12d00000.hdmi (ops hdmi_component_ops)
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [drm] No driver support for vblank timestamp query.
> Console: switching to colour frame buffer device 240x67
> exynos-drm exynos-drm: fb0:  frame buffer device
> [drm] Initialized exynos 1.0.0 20110530 on minor 0
> brd: module loaded
> loop: module loaded
> s3c64xx-spi 13930000.spi: spi bus clock parent not specified, using clock
> at index 0 as parent
> s3c64xx-spi 13930000.spi: number of chip select lines not specified,
> assuming 1 chip select line
> tun: Universal TUN/TAP device driver, 1.6
> tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
> usbcore: registered new interface driver asix
> usbcore: registered new interface driver ax88179_178a
> usbcore: registered new interface driver cdc_ether
> usbcore: registered new interface driver smsc95xx
> usbcore: registered new interface driver cdc_ncm
> dwc2 12480000.hsotg: Specified GNPTXFDEP=1024 > 768
> dwc2 12480000.hsotg: EPs: 16, dedicated fifos, 7808 entries in SPRAM
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ehci-exynos: EHCI EXYNOS driver
> exynos-ehci 12580000.ehci: EHCI Host Controller
> exynos-ehci 12580000.ehci: new USB bus registered, assigned bus number 1
> exynos-ehci 12580000.ehci: irq 51, io mem 0x12580000
> exynos-ehci 12580000.ehci: USB 2.0 started, EHCI 1.00
> usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> usb usb1: Product: EHCI Host Controller
> usb usb1: Manufacturer: Linux 4.6.0-rc5-odroid ehci_hcd
> usb usb1: SerialNumber: 12580000.ehci
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 3 ports detected
> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> ohci-exynos: OHCI EXYNOS driver
> usbcore: registered new interface driver usb-storage
> usb3503 0-0008: switched to HUB mode
> usb3503 0-0008: usb3503_probe: probed in hub mode
> using random self ethernet address
> using random host ethernet address
> usb0: HOST MAC 66:79:ef:11:72:85
> usb0: MAC 1e:66:f2:66:8e:2a
> using random self ethernet address
> using random host ethernet address
> g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
> g_ether gadget: g_ether ready
> dwc2 12480000.hsotg: bound driver g_ether
> mousedev: PS/2 mouse device common for all mice
> max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0
> i2c /dev entries driver
> s5p-fimc-md camera: Entity type for entity FIMC.0 was not initialized!
> usb 1-2: new high-speed USB device number 2 using exynos-ehci
> usb 1-2: New USB device found, idVendor=0424, idProduct=9730
> usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> smsc95xx v1.0.4
> smsc95xx 1-2:1.0 eth0: register 'smsc95xx' at usb-12580000.ehci-2, smsc95xx
> USB 2.0 Ethernet, c2:22:09:f2:5f:e8
> usb 1-3: new high-speed USB device number 3 using exynos-ehci
> usb 1-3: New USB device found, idVendor=0424, idProduct=3503
> usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> hub 1-3:1.0: USB hub found
> hub 1-3:1.0: 3 ports detected
> 
> No oops, no nothing. It's just sitting there.

Apparently you have encountered different issue. sysrq with 'l' might be
useful.

> Is this a regression that was introduced in 4.6? Or is there some special
> new config that needs to be turned on first in 4.6?

I think it was like that for looong time... although I did not use
netboot before on that target.

> I've been running
> 4.5.0-rc3 before this, but I can't apply these patches there because there
> is no drivers/regulator/max77686-regulator.c in 4.5.

In that case skip the regulator patch or apply it for
drivers/regulator/max77686.c driver.

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1391825

On 05/01/2016 03:17 PM, Krzysztof Kozlowski wrote:
> On Sat, Apr 30, 2016 at 11:43:44AM +0200, Hans Verkuil wrote:
>> Hi Krzysztof,
>>
>> On 04/29/2016 12:59 PM, Krzysztof Kozlowski wrote:
>>> Hi,
>>>
>>> Patches are independent, please pick up as you wish.
>>>
>>> However all of them are needed to solve the issue, so I am sending
>>> everything together for easier testng.
>>>
>>>
>>> Problem
>>> =======
>>> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
>>> the usb3503 does not show up in "lsusb". Hard-reset is required, e.g.
>>> by suspend to RAM. The actual TFTP boot does not have to happen. Just
>>> "usb start" from U-Boot is sufficient.
>>>
>>>
>>> Solution
>>> ========
>>> Perform real hardware reset (including regulator off/on) when probing.
>>>
>>>
>>> Tested on Odroid U3 so far. Please kindly test on X2 and other
>>> configurations and bootloaders.
>>
>> Against which kernel git repo is this patch?
>>
>> I did apply this patch series first:
>>
>> http://www.spinics.net/lists/arm-kernel/msg500764.html
> 
> Indeed it is based on above patchset... and on linux-next. It touches
> multiple trees so next seems the easiest base.
> 
>>
>> followed by this patch series.
>>
>> I've tested with both 4.6.0-rc2 and -rc5, but in all cases (even without
>> applying these patches!) the boot sequence hangs here:
>>
>> ...
>> [drm] Exynos DRM: using 12c10000.mixer device for DMA mapping operations
>> exynos-drm exynos-drm: bound 12c10000.mixer (ops mixer_component_ops)
>> exynos-drm exynos-drm: bound 12d00000.hdmi (ops hdmi_component_ops)
>> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [drm] No driver support for vblank timestamp query.
>> Console: switching to colour frame buffer device 240x67
>> exynos-drm exynos-drm: fb0:  frame buffer device
>> [drm] Initialized exynos 1.0.0 20110530 on minor 0
>> brd: module loaded
>> loop: module loaded
>> s3c64xx-spi 13930000.spi: spi bus clock parent not specified, using clock
>> at index 0 as parent
>> s3c64xx-spi 13930000.spi: number of chip select lines not specified,
>> assuming 1 chip select line
>> tun: Universal TUN/TAP device driver, 1.6
>> tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
>> usbcore: registered new interface driver asix
>> usbcore: registered new interface driver ax88179_178a
>> usbcore: registered new interface driver cdc_ether
>> usbcore: registered new interface driver smsc95xx
>> usbcore: registered new interface driver cdc_ncm
>> dwc2 12480000.hsotg: Specified GNPTXFDEP=1024 > 768
>> dwc2 12480000.hsotg: EPs: 16, dedicated fifos, 7808 entries in SPRAM
>> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>> ehci-exynos: EHCI EXYNOS driver
>> exynos-ehci 12580000.ehci: EHCI Host Controller
>> exynos-ehci 12580000.ehci: new USB bus registered, assigned bus number 1
>> exynos-ehci 12580000.ehci: irq 51, io mem 0x12580000
>> exynos-ehci 12580000.ehci: USB 2.0 started, EHCI 1.00
>> usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
>> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
>> usb usb1: Product: EHCI Host Controller
>> usb usb1: Manufacturer: Linux 4.6.0-rc5-odroid ehci_hcd
>> usb usb1: SerialNumber: 12580000.ehci
>> hub 1-0:1.0: USB hub found
>> hub 1-0:1.0: 3 ports detected
>> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
>> ohci-exynos: OHCI EXYNOS driver
>> usbcore: registered new interface driver usb-storage
>> usb3503 0-0008: switched to HUB mode
>> usb3503 0-0008: usb3503_probe: probed in hub mode
>> using random self ethernet address
>> using random host ethernet address
>> usb0: HOST MAC 66:79:ef:11:72:85
>> usb0: MAC 1e:66:f2:66:8e:2a
>> using random self ethernet address
>> using random host ethernet address
>> g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
>> g_ether gadget: g_ether ready
>> dwc2 12480000.hsotg: bound driver g_ether
>> mousedev: PS/2 mouse device common for all mice
>> max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0
>> i2c /dev entries driver
>> s5p-fimc-md camera: Entity type for entity FIMC.0 was not initialized!
>> usb 1-2: new high-speed USB device number 2 using exynos-ehci
>> usb 1-2: New USB device found, idVendor=0424, idProduct=9730
>> usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
>> smsc95xx v1.0.4
>> smsc95xx 1-2:1.0 eth0: register 'smsc95xx' at usb-12580000.ehci-2, smsc95xx
>> USB 2.0 Ethernet, c2:22:09:f2:5f:e8
>> usb 1-3: new high-speed USB device number 3 using exynos-ehci
>> usb 1-3: New USB device found, idVendor=0424, idProduct=3503
>> usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
>> hub 1-3:1.0: USB hub found
>> hub 1-3:1.0: 3 ports detected
>>
>> No oops, no nothing. It's just sitting there.
> 
> Apparently you have encountered different issue. sysrq with 'l' might be
> useful.
> 
>> Is this a regression that was introduced in 4.6? Or is there some special
>> new config that needs to be turned on first in 4.6?
> 
> I think it was like that for looong time... although I did not use
> netboot before on that target.

Sorry, I meant the hanging issue I got in 4.6, not the ethernet issue.
I get the same problem with linux-next. Can you mail me the .config you are using?

After some more testing I don't think it is hanging, instead it seems that the mmc
isn't enabled/found and so it just sits waiting for the root partition to appear.

Weird.

Regards,

	Hans

[toc] | [prev] | [next] | [standalone]

#1391846

On 05/01/2016 04:09 PM, Hans Verkuil wrote:
> On 05/01/2016 03:17 PM, Krzysztof Kozlowski wrote:
>> On Sat, Apr 30, 2016 at 11:43:44AM +0200, Hans Verkuil wrote:
>>> Hi Krzysztof,
>>>
>>> On 04/29/2016 12:59 PM, Krzysztof Kozlowski wrote:
>>>> Hi,
>>>>
>>>> Patches are independent, please pick up as you wish.
>>>>
>>>> However all of them are needed to solve the issue, so I am sending
>>>> everything together for easier testng.
>>>>
>>>>
>>>> Problem
>>>> =======
>>>> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
>>>> the usb3503 does not show up in "lsusb". Hard-reset is required, e.g.
>>>> by suspend to RAM. The actual TFTP boot does not have to happen. Just
>>>> "usb start" from U-Boot is sufficient.
>>>>
>>>>
>>>> Solution
>>>> ========
>>>> Perform real hardware reset (including regulator off/on) when probing.
>>>>
>>>>
>>>> Tested on Odroid U3 so far. Please kindly test on X2 and other
>>>> configurations and bootloaders.
>>>
>>> Against which kernel git repo is this patch?
>>>
>>> I did apply this patch series first:
>>>
>>> http://www.spinics.net/lists/arm-kernel/msg500764.html
>>
>> Indeed it is based on above patchset... and on linux-next. It touches
>> multiple trees so next seems the easiest base.
>>
>>>
>>> followed by this patch series.
>>>
>>> I've tested with both 4.6.0-rc2 and -rc5, but in all cases (even without
>>> applying these patches!) the boot sequence hangs here:
>>>
>>> ...
>>> [drm] Exynos DRM: using 12c10000.mixer device for DMA mapping operations
>>> exynos-drm exynos-drm: bound 12c10000.mixer (ops mixer_component_ops)
>>> exynos-drm exynos-drm: bound 12d00000.hdmi (ops hdmi_component_ops)
>>> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>>> [drm] No driver support for vblank timestamp query.
>>> Console: switching to colour frame buffer device 240x67
>>> exynos-drm exynos-drm: fb0:  frame buffer device
>>> [drm] Initialized exynos 1.0.0 20110530 on minor 0
>>> brd: module loaded
>>> loop: module loaded
>>> s3c64xx-spi 13930000.spi: spi bus clock parent not specified, using clock
>>> at index 0 as parent
>>> s3c64xx-spi 13930000.spi: number of chip select lines not specified,
>>> assuming 1 chip select line
>>> tun: Universal TUN/TAP device driver, 1.6
>>> tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
>>> usbcore: registered new interface driver asix
>>> usbcore: registered new interface driver ax88179_178a
>>> usbcore: registered new interface driver cdc_ether
>>> usbcore: registered new interface driver smsc95xx
>>> usbcore: registered new interface driver cdc_ncm
>>> dwc2 12480000.hsotg: Specified GNPTXFDEP=1024 > 768
>>> dwc2 12480000.hsotg: EPs: 16, dedicated fifos, 7808 entries in SPRAM
>>> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>>> ehci-exynos: EHCI EXYNOS driver
>>> exynos-ehci 12580000.ehci: EHCI Host Controller
>>> exynos-ehci 12580000.ehci: new USB bus registered, assigned bus number 1
>>> exynos-ehci 12580000.ehci: irq 51, io mem 0x12580000
>>> exynos-ehci 12580000.ehci: USB 2.0 started, EHCI 1.00
>>> usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
>>> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
>>> usb usb1: Product: EHCI Host Controller
>>> usb usb1: Manufacturer: Linux 4.6.0-rc5-odroid ehci_hcd
>>> usb usb1: SerialNumber: 12580000.ehci
>>> hub 1-0:1.0: USB hub found
>>> hub 1-0:1.0: 3 ports detected
>>> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
>>> ohci-exynos: OHCI EXYNOS driver
>>> usbcore: registered new interface driver usb-storage
>>> usb3503 0-0008: switched to HUB mode
>>> usb3503 0-0008: usb3503_probe: probed in hub mode
>>> using random self ethernet address
>>> using random host ethernet address
>>> usb0: HOST MAC 66:79:ef:11:72:85
>>> usb0: MAC 1e:66:f2:66:8e:2a
>>> using random self ethernet address
>>> using random host ethernet address
>>> g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
>>> g_ether gadget: g_ether ready
>>> dwc2 12480000.hsotg: bound driver g_ether
>>> mousedev: PS/2 mouse device common for all mice
>>> max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0
>>> i2c /dev entries driver
>>> s5p-fimc-md camera: Entity type for entity FIMC.0 was not initialized!
>>> usb 1-2: new high-speed USB device number 2 using exynos-ehci
>>> usb 1-2: New USB device found, idVendor=0424, idProduct=9730
>>> usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
>>> smsc95xx v1.0.4
>>> smsc95xx 1-2:1.0 eth0: register 'smsc95xx' at usb-12580000.ehci-2, smsc95xx
>>> USB 2.0 Ethernet, c2:22:09:f2:5f:e8
>>> usb 1-3: new high-speed USB device number 3 using exynos-ehci
>>> usb 1-3: New USB device found, idVendor=0424, idProduct=3503
>>> usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
>>> hub 1-3:1.0: USB hub found
>>> hub 1-3:1.0: 3 ports detected
>>>
>>> No oops, no nothing. It's just sitting there.
>>
>> Apparently you have encountered different issue. sysrq with 'l' might be
>> useful.
>>
>>> Is this a regression that was introduced in 4.6? Or is there some special
>>> new config that needs to be turned on first in 4.6?
>>
>> I think it was like that for looong time... although I did not use
>> netboot before on that target.
> 
> Sorry, I meant the hanging issue I got in 4.6, not the ethernet issue.
> I get the same problem with linux-next. Can you mail me the .config you are using?

Never mind.

> After some more testing I don't think it is hanging, instead it seems that the mmc
> isn't enabled/found and so it just sits waiting for the root partition to appear.

That was fun. There are two problems that both caused the boot to end at the same
place: first of all the root partition is now called mmcblk1p1 instead of mmcblk0p1
in 4.6, so it was just waiting for the root partition to appear. Nothing to do with
your patch series, just unexpected.

The second is that enabling CONFIG_VIDEO_S5P_FIMC causes the boot to hang at that
same place. I suspect there is a deadlock somewhere. I'm digging deeper into that
but again, unrelated to your patch series.

Anyway, after disabling that config option I was finally able to test your patch
series:

Tested-by: Hans Verkuil <hans.verkuil@cisco.com>

Thanks!

	Hans

[toc] | [prev] | [next] | [standalone]

#1391850

On Sun, May 01, 2016 at 06:01:08PM +0200, Hans Verkuil wrote:
> > Sorry, I meant the hanging issue I got in 4.6, not the ethernet issue.
> > I get the same problem with linux-next. Can you mail me the .config you are using?
> 
> Never mind.
> 
> > After some more testing I don't think it is hanging, instead it seems that the mmc
> > isn't enabled/found and so it just sits waiting for the root partition to appear.
> 
> That was fun. There are two problems that both caused the boot to end at the same
> place: first of all the root partition is now called mmcblk1p1 instead of mmcblk0p1
> in 4.6, so it was just waiting for the root partition to appear. Nothing to do with
> your patch series, just unexpected.

Yes, annoying issue and unfortunately this is known... recommended
solution is to use root=PARTUUID=xxxx (you can get the PARTUUID with
blkid)... or replace the mmc device.

> The second is that enabling CONFIG_VIDEO_S5P_FIMC causes the boot to hang at that
> same place. I suspect there is a deadlock somewhere. I'm digging deeper into that
> but again, unrelated to your patch series.
> 
> Anyway, after disabling that config option I was finally able to test your patch
> series:
> 
> Tested-by: Hans Verkuil <hans.verkuil@cisco.com>

Thanks!

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1392217

On 05/01/16 18:42, Krzysztof Kozlowski wrote:
> On Sun, May 01, 2016 at 06:01:08PM +0200, Hans Verkuil wrote:
>>> Sorry, I meant the hanging issue I got in 4.6, not the ethernet issue.
>>> I get the same problem with linux-next. Can you mail me the .config you are using?
>>
>> Never mind.
>>
>>> After some more testing I don't think it is hanging, instead it seems that the mmc
>>> isn't enabled/found and so it just sits waiting for the root partition to appear.
>>
>> That was fun. There are two problems that both caused the boot to end at the same
>> place: first of all the root partition is now called mmcblk1p1 instead of mmcblk0p1
>> in 4.6, so it was just waiting for the root partition to appear. Nothing to do with
>> your patch series, just unexpected.
> 
> Yes, annoying issue and unfortunately this is known... recommended
> solution is to use root=PARTUUID=xxxx (you can get the PARTUUID with
> blkid)... or replace the mmc device.
> 
>> The second is that enabling CONFIG_VIDEO_S5P_FIMC causes the boot to hang at that
>> same place. I suspect there is a deadlock somewhere. I'm digging deeper into that
>> but again, unrelated to your patch series.
>>
>> Anyway, after disabling that config option I was finally able to test your patch
>> series:
>>
>> Tested-by: Hans Verkuil <hans.verkuil@cisco.com>

BTW, one thing I noticed is that to have u-boot detect the network device I
need to call 'usb reset' twice. This is with u-boot 2016.1 release.

Not a big deal, but I wondered if you see the same.

Regards,

	Hans

[toc] | [prev] | [next] | [standalone]

#1392219

On 05/02/2016 03:40 PM, Hans Verkuil wrote:
>>> Anyway, after disabling that config option I was finally able to test your patch
>>> series:
>>>
>>> Tested-by: Hans Verkuil <hans.verkuil@cisco.com>
> 
> BTW, one thing I noticed is that to have u-boot detect the network device I
> need to call 'usb reset' twice. This is with u-boot 2016.1 release.
> 
> Not a big deal, but I wondered if you see the same.

Yes, I also have to do it twice.

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1391992

Hi Hans,


On 2016-05-01 18:01, Hans Verkuil wrote:
> On 05/01/2016 04:09 PM, Hans Verkuil wrote:
>> On 05/01/2016 03:17 PM, Krzysztof Kozlowski wrote:
>>> On Sat, Apr 30, 2016 at 11:43:44AM +0200, Hans Verkuil wrote:
>>>> Hi Krzysztof,
>>>>
>>>> On 04/29/2016 12:59 PM, Krzysztof Kozlowski wrote:
>>>>> Hi,
>>>>>
>>>>> Patches are independent, please pick up as you wish.
>>>>>
>>>>> However all of them are needed to solve the issue, so I am sending
>>>>> everything together for easier testng.
>>>>>
>>>>>
>>>>> Problem
>>>>> =======
>>>>> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
>>>>> the usb3503 does not show up in "lsusb". Hard-reset is required, e.g.
>>>>> by suspend to RAM. The actual TFTP boot does not have to happen. Just
>>>>> "usb start" from U-Boot is sufficient.
>>>>>
>>>>>
>>>>> Solution
>>>>> ========
>>>>> Perform real hardware reset (including regulator off/on) when probing.
>>>>>
>>>>>
>>>>> Tested on Odroid U3 so far. Please kindly test on X2 and other
>>>>> configurations and bootloaders.
>>>> Against which kernel git repo is this patch?
>>>>
>>>> I did apply this patch series first:
>>>>
>>>> http://www.spinics.net/lists/arm-kernel/msg500764.html
>>> Indeed it is based on above patchset... and on linux-next. It touches
>>> multiple trees so next seems the easiest base.
>>>
>>>> followed by this patch series.
>>>>
>>>> I've tested with both 4.6.0-rc2 and -rc5, but in all cases (even without
>>>> applying these patches!) the boot sequence hangs here:
>>>>
>>>> ...
>>>> [drm] Exynos DRM: using 12c10000.mixer device for DMA mapping operations
>>>> exynos-drm exynos-drm: bound 12c10000.mixer (ops mixer_component_ops)
>>>> exynos-drm exynos-drm: bound 12d00000.hdmi (ops hdmi_component_ops)
>>>> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>>>> [drm] No driver support for vblank timestamp query.
>>>> Console: switching to colour frame buffer device 240x67
>>>> exynos-drm exynos-drm: fb0:  frame buffer device
>>>> [drm] Initialized exynos 1.0.0 20110530 on minor 0
>>>> brd: module loaded
>>>> loop: module loaded
>>>> s3c64xx-spi 13930000.spi: spi bus clock parent not specified, using clock
>>>> at index 0 as parent
>>>> s3c64xx-spi 13930000.spi: number of chip select lines not specified,
>>>> assuming 1 chip select line
>>>> tun: Universal TUN/TAP device driver, 1.6
>>>> tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
>>>> usbcore: registered new interface driver asix
>>>> usbcore: registered new interface driver ax88179_178a
>>>> usbcore: registered new interface driver cdc_ether
>>>> usbcore: registered new interface driver smsc95xx
>>>> usbcore: registered new interface driver cdc_ncm
>>>> dwc2 12480000.hsotg: Specified GNPTXFDEP=1024 > 768
>>>> dwc2 12480000.hsotg: EPs: 16, dedicated fifos, 7808 entries in SPRAM
>>>> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>>>> ehci-exynos: EHCI EXYNOS driver
>>>> exynos-ehci 12580000.ehci: EHCI Host Controller
>>>> exynos-ehci 12580000.ehci: new USB bus registered, assigned bus number 1
>>>> exynos-ehci 12580000.ehci: irq 51, io mem 0x12580000
>>>> exynos-ehci 12580000.ehci: USB 2.0 started, EHCI 1.00
>>>> usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
>>>> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
>>>> usb usb1: Product: EHCI Host Controller
>>>> usb usb1: Manufacturer: Linux 4.6.0-rc5-odroid ehci_hcd
>>>> usb usb1: SerialNumber: 12580000.ehci
>>>> hub 1-0:1.0: USB hub found
>>>> hub 1-0:1.0: 3 ports detected
>>>> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
>>>> ohci-exynos: OHCI EXYNOS driver
>>>> usbcore: registered new interface driver usb-storage
>>>> usb3503 0-0008: switched to HUB mode
>>>> usb3503 0-0008: usb3503_probe: probed in hub mode
>>>> using random self ethernet address
>>>> using random host ethernet address
>>>> usb0: HOST MAC 66:79:ef:11:72:85
>>>> usb0: MAC 1e:66:f2:66:8e:2a
>>>> using random self ethernet address
>>>> using random host ethernet address
>>>> g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
>>>> g_ether gadget: g_ether ready
>>>> dwc2 12480000.hsotg: bound driver g_ether
>>>> mousedev: PS/2 mouse device common for all mice
>>>> max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0
>>>> i2c /dev entries driver
>>>> s5p-fimc-md camera: Entity type for entity FIMC.0 was not initialized!
>>>> usb 1-2: new high-speed USB device number 2 using exynos-ehci
>>>> usb 1-2: New USB device found, idVendor=0424, idProduct=9730
>>>> usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
>>>> smsc95xx v1.0.4
>>>> smsc95xx 1-2:1.0 eth0: register 'smsc95xx' at usb-12580000.ehci-2, smsc95xx
>>>> USB 2.0 Ethernet, c2:22:09:f2:5f:e8
>>>> usb 1-3: new high-speed USB device number 3 using exynos-ehci
>>>> usb 1-3: New USB device found, idVendor=0424, idProduct=3503
>>>> usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
>>>> hub 1-3:1.0: USB hub found
>>>> hub 1-3:1.0: 3 ports detected
>>>>
>>>> No oops, no nothing. It's just sitting there.
>>> Apparently you have encountered different issue. sysrq with 'l' might be
>>> useful.
>>>
>>>> Is this a regression that was introduced in 4.6? Or is there some special
>>>> new config that needs to be turned on first in 4.6?
>>> I think it was like that for looong time... although I did not use
>>> netboot before on that target.
>> Sorry, I meant the hanging issue I got in 4.6, not the ethernet issue.
>> I get the same problem with linux-next. Can you mail me the .config you are using?
> Never mind.
>
>> After some more testing I don't think it is hanging, instead it seems that the mmc
>> isn't enabled/found and so it just sits waiting for the root partition to appear.
> That was fun. There are two problems that both caused the boot to end at the same
> place: first of all the root partition is now called mmcblk1p1 instead of mmcblk0p1
> in 4.6, so it was just waiting for the root partition to appear. Nothing to do with
> your patch series, just unexpected.

This is known "issue", it has been reported several times. This is 
caused by some
changes in mmc core. The best workaround is to use PARTUUID instead of 
hardcoding
root device path.

>
> The second is that enabling CONFIG_VIDEO_S5P_FIMC causes the boot to hang at that
> same place. I suspect there is a deadlock somewhere. I'm digging deeper into that
> but again, unrelated to your patch series.

I've posted a fix a few days ago: https://patchwork.linuxtv.org/patch/34117/
A change to media device core causes deadlock on driver registration.

> Anyway, after disabling that config option I was finally able to test your patch
> series:
>
> Tested-by: Hans Verkuil <hans.verkuil@cisco.com>

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web