* [PATCH v4 0/2] sunxi, usb: Clean up SRAM initialization code
@ 2023-06-15 19:06 Sam Edwards
2023-06-15 19:07 ` [PATCH v4 1/2] usb: musb-new: sunxi: only perform SRAM initialization when necessary Sam Edwards
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Sam Edwards @ 2023-06-15 19:06 UTC (permalink / raw)
To: u-boot; +Cc: Andre Przywara, Jagan Teki, Sam Edwards
Hi list,
Only change from v4 is that I reworded the commit message in 2/2 not to mention
the TODO comment block that I removed in v3.
Cheers,
Sam
Sam Edwards (2):
usb: musb-new: sunxi: only perform SRAM initialization when necessary
usb: musb-new: sunxi: clarify the purpose of SRAM initialization
drivers/usb/musb-new/sunxi.c | 36 +++++++++++++++++++++++++++---------
1 file changed, 27 insertions(+), 9 deletions(-)
--
2.39.2
^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH v4 1/2] usb: musb-new: sunxi: only perform SRAM initialization when necessary
2023-06-15 19:06 [PATCH v4 0/2] sunxi, usb: Clean up SRAM initialization code Sam Edwards
@ 2023-06-15 19:07 ` Sam Edwards
2023-06-15 19:07 ` [PATCH v4 2/2] usb: musb-new: sunxi: clarify the purpose of SRAM initialization Sam Edwards
2023-11-01 12:57 ` [PATCH v4 0/2] sunxi, usb: Clean up SRAM initialization code Andre Przywara
2 siblings, 0 replies; 4+ messages in thread
From: Sam Edwards @ 2023-06-15 19:07 UTC (permalink / raw)
To: u-boot; +Cc: Andre Przywara, Jagan Teki, Sam Edwards
Only the older (ca. A10, A20) sunxis need this poke for the MUSB to
function. Mimic the Linux kernel and add a `has_sram` flag to the config
structure that is only set for the specific compatibles that require
this initialization.
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/usb/musb-new/sunxi.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index c5c63249aa..1111a67eaf 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -83,6 +83,7 @@
struct sunxi_musb_config {
struct musb_hdrc_config *config;
+ bool has_sram;
};
struct sunxi_glue {
@@ -311,7 +312,10 @@ static int sunxi_musb_init(struct musb *musb)
musb->isr = sunxi_musb_interrupt;
- USBC_ConfigFIFO_Base();
+ if (glue->cfg->has_sram) {
+ USBC_ConfigFIFO_Base();
+ }
+
USBC_EnableDpDmPullUp(musb->mregs);
USBC_EnableIdPullUp(musb->mregs);
@@ -517,6 +521,7 @@ static int musb_usb_remove(struct udevice *dev)
static const struct sunxi_musb_config sun4i_a10_cfg = {
.config = &musb_config,
+ .has_sram = true,
};
static const struct sunxi_musb_config sun6i_a31_cfg = {
--
2.39.2
^ permalink raw reply related [flat|nested] 4+ messages in thread
* [PATCH v4 2/2] usb: musb-new: sunxi: clarify the purpose of SRAM initialization
2023-06-15 19:06 [PATCH v4 0/2] sunxi, usb: Clean up SRAM initialization code Sam Edwards
2023-06-15 19:07 ` [PATCH v4 1/2] usb: musb-new: sunxi: only perform SRAM initialization when necessary Sam Edwards
@ 2023-06-15 19:07 ` Sam Edwards
2023-11-01 12:57 ` [PATCH v4 0/2] sunxi, usb: Clean up SRAM initialization code Andre Przywara
2 siblings, 0 replies; 4+ messages in thread
From: Sam Edwards @ 2023-06-15 19:07 UTC (permalink / raw)
To: u-boot; +Cc: Andre Przywara, Jagan Teki, Sam Edwards
This is largely a cosmetic change, with one functional distinction:
We are now only setting BIT(0), and no longer clearing BIT(1).
The A20 manual confirms the purpose and bitwidth of this field, and we
have also been doing it this way for a while in Linux-land: The prior
narrative about this initialization being about configuring a FIFO has
pretty much been debunked for years now.
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/usb/musb-new/sunxi.c | 31 ++++++++++++++++++++++---------
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index 1111a67eaf..a8b1a8f870 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -171,15 +171,22 @@ static void USBC_ForceVbusValidToHigh(__iomem void *base)
musb_writel(base, USBC_REG_o_ISCR, reg_val);
}
-static void USBC_ConfigFIFO_Base(void)
-{
- u32 reg_value;
+/******************************************************************************
+ * Non-USBC register access needed for initialization
+ ******************************************************************************/
- /* 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);
+/*
+ * A10(s), A13, GR8, A20:
+ * switch ownership of SRAM block 'D' to the USB-OTG controller
+ */
+static void sunxi_musb_claim_sram(uintptr_t syscon_base)
+{
+ /*
+ * BIT(0) of SRAM_CTRL_REG1 (syscon+0x04) controls SRAM-D ownership:
+ * '0' -> exclusive access by CPU
+ * '1' -> exclusive access by USB0
+ */
+ setbits_le32(syscon_base + 0x04, BIT(0));
}
/******************************************************************************
@@ -313,7 +320,13 @@ 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(SUNXI_SRAMC_BASE);
}
USBC_EnableDpDmPullUp(musb->mregs);
--
2.39.2
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v4 0/2] sunxi, usb: Clean up SRAM initialization code
2023-06-15 19:06 [PATCH v4 0/2] sunxi, usb: Clean up SRAM initialization code Sam Edwards
2023-06-15 19:07 ` [PATCH v4 1/2] usb: musb-new: sunxi: only perform SRAM initialization when necessary Sam Edwards
2023-06-15 19:07 ` [PATCH v4 2/2] usb: musb-new: sunxi: clarify the purpose of SRAM initialization Sam Edwards
@ 2023-11-01 12:57 ` Andre Przywara
2 siblings, 0 replies; 4+ messages in thread
From: Andre Przywara @ 2023-11-01 12:57 UTC (permalink / raw)
To: Marek Vasut; +Cc: Sam Edwards, u-boot, Jagan Teki
On Thu, 15 Jun 2023 13:06:59 -0600
Sam Edwards <cfsworks@gmail.com> wrote:
Hi Marek,
I just saw that you were not CC:ed on this one. Both patches are fine from
my point of view.
Do you want to take them through the USB tree, or shall I do it via the
sunxi tree?
And shall I take future musb-new/sunxi.c patches in general, if you have
approved them? They are typically ports of quirks from the kernel, and new
compatible strings, maybe.
Cheers,
Andre
> Only change from v4 is that I reworded the commit message in 2/2 not to mention
> the TODO comment block that I removed in v3.
>
> Cheers,
> Sam
>
> Sam Edwards (2):
> usb: musb-new: sunxi: only perform SRAM initialization when necessary
> usb: musb-new: sunxi: clarify the purpose of SRAM initialization
>
> drivers/usb/musb-new/sunxi.c | 36 +++++++++++++++++++++++++++---------
> 1 file changed, 27 insertions(+), 9 deletions(-)
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-11-01 12:57 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-06-15 19:06 [PATCH v4 0/2] sunxi, usb: Clean up SRAM initialization code Sam Edwards
2023-06-15 19:07 ` [PATCH v4 1/2] usb: musb-new: sunxi: only perform SRAM initialization when necessary Sam Edwards
2023-06-15 19:07 ` [PATCH v4 2/2] usb: musb-new: sunxi: clarify the purpose of SRAM initialization Sam Edwards
2023-11-01 12:57 ` [PATCH v4 0/2] sunxi, usb: Clean up SRAM initialization code Andre Przywara
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox