[PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB

Martin Blumenstingl martin.blumenstingl at googlemail.com
Fri Sep 9 13:37:25 PDT 2016

On Fri, Sep 9, 2016 at 7:21 PM, Ben Dooks <ben.dooks at codethink.co.uk> wrote:
> On 09/09/16 17:14, Martin Blumenstingl wrote:
>> On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman <khilman at baylibre.com> 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.
okay, sounds reasonable - so we should try to get this scenario
supported through by the reset framework -> see my other mail.

More information about the linux-amlogic mailing list