Re: [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP
On Tue, Jan 20, 2015 at 09:43:07PM +0100, Andrew Lunn wrote: On Tue, Jan 20, 2015 at 09:30:28PM +0100, Maxime Ripard wrote: Hi Andrew, On Mon, Jan 19, 2015 at 10:35:07PM +0100, Andrew Lunn wrote: On Mon, Jan 19, 2015 at 02:01:11PM +0100, Maxime Ripard wrote: Hi all, This serie enables the Armada 385 AP XHCI controller. Since the controller uses a GPIO-controlled VBUS, we used the phy-generic driver, and made the needed additions to the xhci-plat driver to retrieve a USB phy. Unfortunately, some glitches were also found along the way, mostly because of the probe deferring that was introduced by this phy retrieval. Since the introduction of the Armada 38x support in 3.16, the driver was attempting to write into registers while the clock wasn't enabled yet. This was working because the bootloader left it enabled, but in the case of a deferred probing, the clock would have been disabled by the error path of our driver, and this would fail. This should go in 3.19, and any stable kernel for 3.16+. The two patches remaining are regular patches, and are aimed at 3.20. The last patch depend on my previous serie to introduce support for the the A385 AP board. Hi Maxime I assume you want me to take 3/3? Any other route is not simple, since this file only exists in mvebu/dt and maybe a staging branch of arm-soc. What route do you think the other patches will take? There should be no merge dependency, but merging the third patch alone will probably result on a boot breakage. I don't think it really matters though, since this is a new board, so I guess it can go through the USB-PHY tree. Hi Maxime Humm, maybe i'm wrong, but i think arch/arm/boot/dts/armada-385-db-ap.dts only exists in the mvebu tree? At least, i don't see it here: https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/tree/arch/arm/boot/dts?h=next Yeah, but my point was that if you merge the DT bits, without having the PHY driver quirks fix in your tree, you'll result in a kernel that doesn't boot at all on that board. But again, since this is a new board, I don't really see why you would want to bisect that. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP
Hi Andrew, On Mon, Jan 19, 2015 at 10:35:07PM +0100, Andrew Lunn wrote: On Mon, Jan 19, 2015 at 02:01:11PM +0100, Maxime Ripard wrote: Hi all, This serie enables the Armada 385 AP XHCI controller. Since the controller uses a GPIO-controlled VBUS, we used the phy-generic driver, and made the needed additions to the xhci-plat driver to retrieve a USB phy. Unfortunately, some glitches were also found along the way, mostly because of the probe deferring that was introduced by this phy retrieval. Since the introduction of the Armada 38x support in 3.16, the driver was attempting to write into registers while the clock wasn't enabled yet. This was working because the bootloader left it enabled, but in the case of a deferred probing, the clock would have been disabled by the error path of our driver, and this would fail. This should go in 3.19, and any stable kernel for 3.16+. The two patches remaining are regular patches, and are aimed at 3.20. The last patch depend on my previous serie to introduce support for the the A385 AP board. Hi Maxime I assume you want me to take 3/3? Any other route is not simple, since this file only exists in mvebu/dt and maybe a staging branch of arm-soc. What route do you think the other patches will take? There should be no merge dependency, but merging the third patch alone will probably result on a boot breakage. I don't think it really matters though, since this is a new board, so I guess it can go through the USB-PHY tree. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP
On Tue, Jan 20, 2015 at 09:30:28PM +0100, Maxime Ripard wrote: Hi Andrew, On Mon, Jan 19, 2015 at 10:35:07PM +0100, Andrew Lunn wrote: On Mon, Jan 19, 2015 at 02:01:11PM +0100, Maxime Ripard wrote: Hi all, This serie enables the Armada 385 AP XHCI controller. Since the controller uses a GPIO-controlled VBUS, we used the phy-generic driver, and made the needed additions to the xhci-plat driver to retrieve a USB phy. Unfortunately, some glitches were also found along the way, mostly because of the probe deferring that was introduced by this phy retrieval. Since the introduction of the Armada 38x support in 3.16, the driver was attempting to write into registers while the clock wasn't enabled yet. This was working because the bootloader left it enabled, but in the case of a deferred probing, the clock would have been disabled by the error path of our driver, and this would fail. This should go in 3.19, and any stable kernel for 3.16+. The two patches remaining are regular patches, and are aimed at 3.20. The last patch depend on my previous serie to introduce support for the the A385 AP board. Hi Maxime I assume you want me to take 3/3? Any other route is not simple, since this file only exists in mvebu/dt and maybe a staging branch of arm-soc. What route do you think the other patches will take? There should be no merge dependency, but merging the third patch alone will probably result on a boot breakage. I don't think it really matters though, since this is a new board, so I guess it can go through the USB-PHY tree. Hi Maxime Humm, maybe i'm wrong, but i think arch/arm/boot/dts/armada-385-db-ap.dts only exists in the mvebu tree? At least, i don't see it here: https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/tree/arch/arm/boot/dts?h=next Andrew -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP
On Mon, Jan 19, 2015 at 02:01:11PM +0100, Maxime Ripard wrote: Hi all, This serie enables the Armada 385 AP XHCI controller. Since the controller uses a GPIO-controlled VBUS, we used the phy-generic driver, and made the needed additions to the xhci-plat driver to retrieve a USB phy. Unfortunately, some glitches were also found along the way, mostly because of the probe deferring that was introduced by this phy retrieval. Since the introduction of the Armada 38x support in 3.16, the driver was attempting to write into registers while the clock wasn't enabled yet. This was working because the bootloader left it enabled, but in the case of a deferred probing, the clock would have been disabled by the error path of our driver, and this would fail. This should go in 3.19, and any stable kernel for 3.16+. The two patches remaining are regular patches, and are aimed at 3.20. The last patch depend on my previous serie to introduce support for the the A385 AP board. Hi Maxime I assume you want me to take 3/3? Any other route is not simple, since this file only exists in mvebu/dt and maybe a staging branch of arm-soc. What route do you think the other patches will take? Thanks Andrew -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
