From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE7CCC48BDF for ; Mon, 14 Jun 2021 00:25:00 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 637916135F for ; Mon, 14 Jun 2021 00:25:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 637916135F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=/1gASCFx+yO0v31oMWLRpDefiMz1MDDY0akv/baHrL4=; b=EOCX2k9R0W+3Hg cQbZV4lsh3+2z2Tad6IMr73MrU9bYwO0lZLeWdP+0KUqDMIGsHZZOVMdoq+XVzCUSs3QJOCPF686U kZdCZkxlL3WyAJrlOchnut3AjsVNTjV641XD6n8WMIT2nkA0Aj5e+vUcyjrr2c1DqEpFl4rCUV6SI bHE/5jg7qLSmAewh/7w9kerrznfSFZ74sfSnz0ofyR/jfCxz3fiPQSmPgWdlHIldi2gZu1bc340eh zZgj1OSbvlvXELBJpyw4Ei0wsGNjMFqyGk2rSd9nXysPJ8ZK4SMPhY6Ylm6/BFkyejqLigVKbOFHF K2hXpvJuETyn0Y1Lkrvw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lsaLn-00BkJn-0o; Mon, 14 Jun 2021 00:21:11 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lsaLi-00BkIc-Pf; Mon, 14 Jun 2021 00:21:09 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 18D0D6D; Sun, 13 Jun 2021 17:21:01 -0700 (PDT) Received: from slackpad.fritz.box (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EBCBA3F70D; Sun, 13 Jun 2021 17:20:58 -0700 (PDT) Date: Mon, 14 Jun 2021 01:20:47 +0100 From: Andre Przywara To: Chen-Yu Tsai Cc: Maxime Ripard , Jernej Skrabec , Rob Herring , Icenowy Zheng , Samuel Holland , Ondrej Jirman , linux-arm-kernel , linux-sunxi , linux-sunxi@lists.linux.dev, linux-kernel , Kishon Vijay Abraham I , Vinod Koul , linux-phy@lists.infradead.org, linux-usb Subject: Re: [linux-sunxi] Re: [PATCH v6 12/17] phy: sun4i-usb: Introduce port2 SIDDQ quirk Message-ID: <20210614012047.37774ca8@slackpad.fritz.box> In-Reply-To: References: <20210519104152.21119-1-andre.przywara@arm.com> <20210519104152.21119-13-andre.przywara@arm.com> <20210524115946.jwsasjbr3biyixhz@gilmour> <20210525122901.778bfccd@slackpad.fritz.box> <20210607132255.7fa75a7k7ud2g7ux@gilmour> <20210607151742.2f05ff95@slackpad.fritz.box> Organization: Arm Ltd. X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.31; x86_64-slackware-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210613_172106_973579_1F697B86 X-CRM114-Status: GOOD ( 46.20 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 7 Jun 2021 22:26:02 +0800 Chen-Yu Tsai wrote: Hi Chen-Yu, > On Mon, Jun 7, 2021 at 10:17 PM Andre Przywara wrote: > > > > On Mon, 7 Jun 2021 15:22:55 +0200 > > Maxime Ripard wrote: > > > > Hi Maxime, > > > > > On Tue, May 25, 2021 at 12:29:01PM +0100, Andre Przywara wrote: > > > > On Mon, 24 May 2021 13:59:46 +0200 > > > > Maxime Ripard 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 > > > > > > > > > > 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. > > > > > > Ok > > > > > > > > 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'm not sure we need a separate device node, we could just register the > > > phy driver as a genpd provider, and then with an arg (so with > > > of_genpd_add_provider_onecell?) the index of the USB controller we want > > > to power up. > > > > Yeah, I figured that myself meanwhile ;-) I now have a fairly nice > > implementation, which does away with the extra clocks and resets from > > the EHCI/OHCI nodes, and just adds one extra clock to the PHY node. The > > rest is power domains properties. > > I'm wondering, since SIDDQ refers to the analog power for USB, it shouldn't > really affect the HCIs, only the PHYs. Is there any way to model it like > this and test it? That is actually a good point: it is indeed solely a PHY property. The HCIs already connect to their PHYs, among other reasons to power them on, so it should really be an internal PHY affair. Which is actually what this patch here does. So I can combine the best of both approaches: we already have the PHY2 clock and reset references in the PHY node, so can just reach out and enable them as well, alongside the actually associated PHY clock. This allows us to get rid of the bogus PHY2 clock references from all HCIs. So all of this H616 quirk can be fully contained within the PHY driver, with no impact on the HCI parts and no extra DT properties (power-domains, clocks) needed there. Seems to work on a quick test. I will send a version ASAP. Thanks! Andre > > ChenYu > > > > > 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? > > > > > > Using what I described above should be fairly simple, so if we can fit > > > in an available and relevant abstraction, yeah, I guess :) > > > > Thanks! > > I will post what I have, just need to find some solution for the RTC > > clock bits. > > > > Cheers, > > Andre > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel