lkml.org 
[lkml]   [2021]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v6 12/17] phy: sun4i-usb: Introduce port2 SIDDQ quirk
    On Mon, 24 May 2021 13:59:46 +0200
    Maxime Ripard <maxime@cerno.tech> wrote:

    Hi Maxime,

    > On Wed, May 19, 2021 at 11:41:47AM +0100, Andre Przywara wrote:
    > > At least the Allwinner H616 SoC requires a weird quirk to make most
    > > USB PHYs work: Only port2 works out of the box, but all other ports
    > > need some help from this port2 to work correctly: The CLK_BUS_PHY2 and
    > > RST_USB_PHY2 clock and reset need to be enabled, and the SIDDQ bit in
    > > the PMU PHY control register needs to be cleared. For this register to
    > > be accessible, CLK_BUS_ECHI2 needs to be ungated. Don't ask ....
    > >
    > > Instead of disguising this as some generic feature, do exactly that
    > > in our PHY init:
    > > If the quirk bit is set, and we initialise a PHY other than PHY2, ungate
    > > this one special clock, and clear the SIDDQ bit. We can pull in the
    > > other required clocks via the DT.
    > >
    > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    >
    > What is this SIDDQ bit doing exactly?

    I probably know as much as you do, but as Jernej pointed out, in some
    Rockchip code it's indeed documented as some analogue PHY supply switch:
    ($ git grep -i siddq drivers/phy/rockchip)

    In fact we had this pin/bit for ages, it was just hidden as BIT(1) in
    our infamous PMU_UNK1 register. Patch 10/17 drags that into the light.

    > I guess we could also expose this using a power-domain if it's relevant?

    Mmmh, interesting idea. So are you thinking about registering a genpd
    provider in sun4i_usb_phy_probe(), then having a power-domains property
    in the ehci/ohci nodes, pointing to the PHY node? And if yes, should
    the provider be a subnode of the USB PHY node, with a separate
    compatible? That sounds a bit more involved, but would have the
    advantage of allowing us to specify the resets and clocks from PHY2
    there, and would look a bit cleaner than hacking them into the
    other EHCI/OHCI nodes.

    I would not touch the existing SoCs (even though it seems to apply to
    them as well, just not in the exact same way), but I can give it a
    try for the H616. It seems like the other SIDDQ bits (in the other
    PHYs) are still needed for operation, but the PD provide could actually
    take care of this as well.

    Does that make sense or is this a bit over the top for just clearing an
    extra bit?

    Cheers,
    Andre

    \
     
     \ /
      Last update: 2021-05-25 13:29    [W:4.761 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site