From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Dooks Subject: Re: [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB Date: Fri, 9 Sep 2016 18:21:14 +0100 Message-ID: References: <20160904213152.25837-1-martin.blumenstingl@googlemail.com> <20160904213152.25837-5-martin.blumenstingl@googlemail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-clk-owner@vger.kernel.org To: Martin Blumenstingl , Kevin Hilman Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, gregkh@linuxfoundation.org, johnyoun@synopsys.com, will.deacon@arm.com, mturquette@baylibre.com, linux-usb@vger.kernel.org, sboyd@codeaurora.org, kishon@ti.com, robh+dt@kernel.org, catalin.marinas@arm.com, carlo@caione.org, linux-amlogic@lists.infradead.org, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, jbrunet@baylibre.com List-Id: devicetree@vger.kernel.org On 09/09/16 17:14, Martin Blumenstingl wrote: > On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman wrote: >> However, the problem with all of the solutions proposed (runtime PM ones >> included) is that we're forcing a board-specific design issue (2 devices >> sharing a reset line) into a driver that should not have any >> board-specific assumptions in it. >> >> For example, if this driver is used on another platform where different >> PHYs have different reset lines, then one of them (the unlucky one who >> is not probed first) will never get reset. So any form of per-device >> ref-counting is not a portable solution. > maybe we should also consider Ben's solution: he played with the USB > PHY on his Meson8b board. His approach was to have only one USB PHY > driver instance which exposes two PHYs. > The downside of this: the driver would have to know the offset of the > PHYs (0x0 for the first PHY, 0x20 for the second), but we could handle > the reset using runtime PM without any hacks. > > I checked the USB PHY reference driver: it seems that there will be a > new USB PHY with the GXL/GXM SoCs. > So maybe we could live with the assumption that the PHYs are at > consecutive addresses. > >> I'm not sure yet how the reset framework is supposed to handle shared >> reset lines, but that needs some investigation. I quick glance and it >> seems that reset controllers can have shared lines, so that should be >> investigated. > unfortunately shared resets are not allowed to use reset_control_reset, see [0] > > > [0] http://lxr.free-electrons.com/source/drivers/reset/core.c#L102 If we didn't have the shared reset, we'd have one of node per phy and not have to have two sub-nodes... I don't think any other bits of the PHY framework are shared. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius From mboxrd@z Thu Jan 1 00:00:00 1970 From: ben.dooks@codethink.co.uk (Ben Dooks) Date: Fri, 9 Sep 2016 18:21:14 +0100 Subject: [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB In-Reply-To: References: <20160904213152.25837-1-martin.blumenstingl@googlemail.com> <20160904213152.25837-5-martin.blumenstingl@googlemail.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 09/09/16 17:14, Martin Blumenstingl wrote: > On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman wrote: >> However, the problem with all of the solutions proposed (runtime PM ones >> included) is that we're forcing a board-specific design issue (2 devices >> sharing a reset line) into a driver that should not have any >> board-specific assumptions in it. >> >> For example, if this driver is used on another platform where different >> PHYs have different reset lines, then one of them (the unlucky one who >> is not probed first) will never get reset. So any form of per-device >> ref-counting is not a portable solution. > maybe we should also consider Ben's solution: he played with the USB > PHY on his Meson8b board. His approach was to have only one USB PHY > driver instance which exposes two PHYs. > The downside of this: the driver would have to know the offset of the > PHYs (0x0 for the first PHY, 0x20 for the second), but we could handle > the reset using runtime PM without any hacks. > > I checked the USB PHY reference driver: it seems that there will be a > new USB PHY with the GXL/GXM SoCs. > So maybe we could live with the assumption that the PHYs are at > consecutive addresses. > >> I'm not sure yet how the reset framework is supposed to handle shared >> reset lines, but that needs some investigation. I quick glance and it >> seems that reset controllers can have shared lines, so that should be >> investigated. > unfortunately shared resets are not allowed to use reset_control_reset, see [0] > > > [0] http://lxr.free-electrons.com/source/drivers/reset/core.c#L102 If we didn't have the shared reset, we'd have one of node per phy and not have to have two sub-nodes... I don't think any other bits of the PHY framework are shared. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius From mboxrd@z Thu Jan 1 00:00:00 1970 From: ben.dooks@codethink.co.uk (Ben Dooks) Date: Fri, 9 Sep 2016 18:21:14 +0100 Subject: [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB In-Reply-To: References: <20160904213152.25837-1-martin.blumenstingl@googlemail.com> <20160904213152.25837-5-martin.blumenstingl@googlemail.com> Message-ID: To: linus-amlogic@lists.infradead.org List-Id: linus-amlogic.lists.infradead.org On 09/09/16 17:14, Martin Blumenstingl wrote: > On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman wrote: >> However, the problem with all of the solutions proposed (runtime PM ones >> included) is that we're forcing a board-specific design issue (2 devices >> sharing a reset line) into a driver that should not have any >> board-specific assumptions in it. >> >> For example, if this driver is used on another platform where different >> PHYs have different reset lines, then one of them (the unlucky one who >> is not probed first) will never get reset. So any form of per-device >> ref-counting is not a portable solution. > maybe we should also consider Ben's solution: he played with the USB > PHY on his Meson8b board. His approach was to have only one USB PHY > driver instance which exposes two PHYs. > The downside of this: the driver would have to know the offset of the > PHYs (0x0 for the first PHY, 0x20 for the second), but we could handle > the reset using runtime PM without any hacks. > > I checked the USB PHY reference driver: it seems that there will be a > new USB PHY with the GXL/GXM SoCs. > So maybe we could live with the assumption that the PHYs are at > consecutive addresses. > >> I'm not sure yet how the reset framework is supposed to handle shared >> reset lines, but that needs some investigation. I quick glance and it >> seems that reset controllers can have shared lines, so that should be >> investigated. > unfortunately shared resets are not allowed to use reset_control_reset, see [0] > > > [0] http://lxr.free-electrons.com/source/drivers/reset/core.c#L102 If we didn't have the shared reset, we'd have one of node per phy and not have to have two sub-nodes... I don't think any other bits of the PHY framework are shared. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius