On Fri, Sep 9, 2016 at 7:21 PM, Ben Dooks <ben.dooks@xxxxxxxxxxxxxxx> wrote: > On 09/09/16 17:14, Martin Blumenstingl wrote: >> >> On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman <khilman@xxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
