public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Sam Edwards <cfsworks@gmail.com>
To: u-boot@lists.denx.de
Cc: Andre Przywara <andre.przywara@arm.com>,
	Jagan Teki <jagan@amarulasolutions.com>,
	Marek Vasut <marex@denx.de>, Sam Edwards <CFSworks@gmail.com>
Subject: [PATCH 2/2] usb: musb-new: sunxi: clarify the purpose of SRAM initialization
Date: Wed,  7 Jun 2023 17:16:44 -0600	[thread overview]
Message-ID: <20230607231644.28203-3-CFSworks@gmail.com> (raw)
In-Reply-To: <20230607231644.28203-1-CFSworks@gmail.com>

This is largely a cosmetic change, with one functional distinction:
We are now only setting BIT(0), and no longer clearing BIT(1).

The new comments and function name are not from any official source,
but are updated to mirror how the Linux kernel sources treat this
mystery magic bit. If we wanted to confirm that this speculation is
correct, we could verify that SRAM-D is inaccessible whenever the
bit is set, and then try clearing it again while the MUSB is in use
to see what debris gets left behind in SRAM-D.

This cleanup also adds a TODO comment about runtime discovery
of the SYSCON base, per discussion with Andre.

Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Cc: Andre Przywara <andre.przywara@arm.com>
---
 drivers/usb/musb-new/sunxi.c | 28 ++++++++++++++++++++--------
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index c05c0d5561..2b954601a0 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -173,15 +173,23 @@ static void USBC_ForceVbusValidToHigh(__iomem void *base)
 	musb_writel(base, USBC_REG_o_ISCR, reg_val);
 }
 
-static void USBC_ConfigFIFO_Base(void)
+/******************************************************************************
+ * Non-USBC register access needed for initialization
+ ******************************************************************************/
+
+/* A10(s), A13, GR8, A20:
+ * switch ownership of SRAM block 'D' to the USB-OTG controller */
+#define OFF_SUNXI_SRAMCTRL_D		(0x04)
+#define SUNXI_SRAMCTRL_D_FLAG_USBOTG	BIT(0)
+
+static void sunxi_musb_claim_sram(void)
 {
-	u32 reg_value;
+	/* TODO: Do not use hardcoded SUNXI_SRAMC_BASE; find the syscon base by
+	 * traversing this OTG device's `allwinner,sram` FDT property and
+	 * working upward to the system controller. */
 
-	/* config usb fifo, 8kb mode */
-	reg_value = readl(SUNXI_SRAMC_BASE + 0x04);
-	reg_value &= ~(0x03 << 0);
-	reg_value |= BIT(0);
-	writel(reg_value, SUNXI_SRAMC_BASE + 0x04);
+	setbits_le32(SUNXI_SRAMC_BASE + OFF_SUNXI_SRAMCTRL_D,
+		     SUNXI_SRAMCTRL_D_FLAG_USBOTG);
 }
 
 /******************************************************************************
@@ -315,7 +323,11 @@ static int sunxi_musb_init(struct musb *musb)
 	musb->isr = sunxi_musb_interrupt;
 
 	if (glue->cfg->has_sram) {
-		USBC_ConfigFIFO_Base();
+		/* This is an older USB-OTG controller that Allwinner did not
+		 * endow with a dedicated SRAM block; it instead uses SRAM
+		 * block 'D', ownership of which needs to be handed over by
+		 * the CPU */
+		sunxi_musb_claim_sram();
 	}
 
 	USBC_EnableDpDmPullUp(musb->mregs);
-- 
2.39.2


  parent reply	other threads:[~2023-06-07 23:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-07 23:16 [PATCH 0/2] sunxi, usb: Clean up SRAM initialization code Sam Edwards
2023-06-07 23:16 ` [PATCH 1/2] usb: musb-new: sunxi: only perform SRAM initialization when necessary Sam Edwards
2023-06-08 12:03   ` Andre Przywara
2023-06-09 10:00   ` Andre Przywara
2023-06-07 23:16 ` Sam Edwards [this message]
2023-06-09 10:13   ` [PATCH 2/2] usb: musb-new: sunxi: clarify the purpose of SRAM initialization Andre Przywara
2023-06-09 19:16     ` Sam Edwards
2023-06-09 19:40       ` Andre Przywara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230607231644.28203-3-CFSworks@gmail.com \
    --to=cfsworks@gmail.com \
    --cc=andre.przywara@arm.com \
    --cc=jagan@amarulasolutions.com \
    --cc=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox