On 11/30/21 03:14, Rob Herring wrote:
On Mon, Nov 22, 2021 at 12:02:52PM +0100, Michal Simek wrote:
nit: Just spot typo in subject. It is usb2244.
On 11/22/21 08:02, Greg KH wrote:
On Mon, Nov 22, 2021 at 11:58:34AM +0530, Piyush Mehta wrote:
Microchip's USB224x family of Hi-Speed USB 2.0 flash media card controllers
provides an ultra-fast interface between a USB host controller and flash
media cards.
This patch adds a GPIO based usb-sd reset for USB2244 USB2 ultra fast
SD controller. This usb2244 driver trigger sd reset signal after soft
reset or core Reset. The SD needs to be resetted after completion of
phy initialization. After the toggling of gpio, controller gets out
form reset. USB2244 is a simple platform device driver.
As part of the reset, sets the direction of the pin to output before
toggling the pin. Delay of microseconds is added in between high and
low to meet the setup and hold time requirement of the reset.
Signed-off-by: Piyush Mehta <piyush.mehta@xxxxxxxxxx>
---
Changes for V2:
- Update reset polarity, make reset ACTIVE LOW in the usb2244 driver.
- Fix WARNING: msleep < 20ms can sleep for up to 20ms by changing msleep to
usleep_range()
---
drivers/usb/misc/Kconfig | 10 +++++++
drivers/usb/misc/Makefile | 1 +
drivers/usb/misc/usb2244.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++
This isn't really a USB driver, so maybe drivers/misc/ instead?
3 files changed, 80 insertions(+)
create mode 100644 drivers/usb/misc/usb2244.c
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 8f11443..e1c66a2 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -215,6 +215,16 @@ config USB_ISIGHTFW
driver beforehand. Tools for doing so are available at
http://bersace03.free.fr
+config USB_USB2244
+ tristate "Microchip USB2244 Ultra Fast USB 2.0 SD driver"
+ depends on GPIOLIB
+ help
+ Say Y or M here if you want to reset Microchip USB2244 Ultra Fast
+ USB 2.0 SD controller.
+ This option enables support for Microchip USB2244 Ultra Fast USB 2.0
+ SD controller. This driver reset the gpio pin makes controller out of
+ reset.
Module name?
+
config USB_YUREX
tristate "USB YUREX driver support"
help
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 5f4e598..5b4af7d 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_USB_LEGOTOWER) += legousbtower.o
obj-$(CONFIG_USB_TEST) += usbtest.o
obj-$(CONFIG_USB_EHSET_TEST_FIXTURE) += ehset.o
obj-$(CONFIG_USB_TRANCEVIBRATOR) += trancevibrator.o
+obj-$(CONFIG_USB_USB2244) += usb2244.o
obj-$(CONFIG_USB_USS720) += uss720.o
obj-$(CONFIG_USB_SEVSEG) += usbsevseg.o
obj-$(CONFIG_USB_YUREX) += yurex.o
diff --git a/drivers/usb/misc/usb2244.c b/drivers/usb/misc/usb2244.c
new file mode 100644
index 0000000..5a868c2
--- /dev/null
+++ b/drivers/usb/misc/usb2244.c
@@ -0,0 +1,69 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for the Microchip USB2244 Ultra Fast USB 2.0 Multi-Format,
+ * SD/MMC, and MS Flash Media Controllers
+ *
+ * Copyright (c) 2021 Xilinx, Inc.
+ */
+
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/gpio/consumer.h>
+#include <linux/platform_device.h>
+
+struct usb2244 {
+ struct gpio_desc *reset_gpio;
+};
Why is this structure needed?
+
+static int usb2244_init_hw(struct device *dev, struct usb2244 *data)
+{
+ data = devm_kzalloc(dev, sizeof(struct usb2244), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(data->reset_gpio)) {
+ dev_err_probe(dev, PTR_ERR(data->reset_gpio),
+ "Failed to request reset GPIO %ld, errcode",
+ PTR_ERR(data->reset_gpio));
+ return PTR_ERR(data->reset_gpio);
+ }
+
+ /* Toggle RESET_N to reset the hub. */
+ gpiod_set_value_cansleep(data->reset_gpio, 1);
+ usleep_range(5, 10);
+ gpiod_set_value_cansleep(data->reset_gpio, 0);
+ usleep_range(5000, 6000);
Why do you need a kernel driver for this at all? Why not just toggle
the pin from userspace?
It is usb-sd convertor. If you have rootfs on SD you need to get the chip
out of reset to be able to access init. There is no way how to do it via
userspace.
Then by the bootloader...
Bootloader is doing it because it needs to get access there too. And it
also need to do in our case initialization of usb5744 usb hub via i2c to
start working. And description is taken from DT.
When you get to OS it takes the same DT and start to do the job again.
It means reset usb core, reset usb hub, reset usb-sd bridge and reset
usb ULPI.
I don't think it is good way to let bootloader do it and Linux will just
rely on it. Bootloader should be decouple from OS that's why IMHO
initialization on both sides is necessary.
Maybe there could be a different way how to do it via different driver to
toggle the reset. It is dwc3 -> usb-hub(usb5744) -> usb-sd(usb2244) + usb
phys for sd2.0 and it should be also reset in the right order.
Otherwise, you need to define the whole USB hierarchy to add the GPIO
line to the USB device. Unfortunately, getting all that to work in the
kernel is not a solved problem. It's the same issue on all the
'discoverable' buses.
We have to define that hierarchy anyway for bootloader to do all resets.
And structure is fixed.
This is what we have defined. (I have updated that 2244 usb-sd convertor).
usb2244 is connected to usb5744 hub port1. Not sure if this is correct
description because maybe it should be child of it.
Can you please check this structure?
usb0: usb0@ff9d0000 {
#address-cells = <2>;
#size-cells = <2>;
compatible = "xlnx,zynqmp-dwc3";
reg = <0x0 0xff9d0000 0x0 0x100>;
clock-names = "bus_clk", "ref_clk";
power-domains = <&zynqmp_firmware PD_USB_0>;
resets = <&zynqmp_reset ZYNQMP_RESET_USB0_CORERESET>,
<&zynqmp_reset ZYNQMP_RESET_USB0_HIBERRESET>,
<&zynqmp_reset ZYNQMP_RESET_USB0_APB>;
reset-names = "usb_crst", "usb_hibrst", "usb_apbrst";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usb0_default>;
phy-names = "usb3-phy";
phys = <&psgtr 2 PHY_TYPE_USB3 0 2>;
reset-gpios = <&slg7xl45106 0 GPIO_ACTIVE_LOW>;
clocks = <&zynqmp_clk USB0_BUS_REF>, <&zynqmp_clk USB3_DUAL_REF>;
assigned-clocks = <&zynqmp_clk USB0_BUS_REF>, <&zynqmp_clk
USB3_DUAL_REF>;
assigned-clock-rates = <250000000>, <20000000>;
dr-mode = "host";
usbhub0_2_0: hub@1 {
i2c-bus = <&usbhub_i2c0>;
compatible = "usb424:2744";
reg = <1>;
reset-gpios = <&slg7xl45106 3 GPIO_ACTIVE_LOW>;
companion-hub = <&usbhub0_3_0>;
};
usbhub0_3_0: hub@2 {
i2c-bus = <&usbhub_i2c0>;
compatible = "usb424:5744";
reg = <2>;
reset-gpios = <&slg7xl45106 3 GPIO_ACTIVE_LOW>;
companion-hub = <&usbhub0_2_0>;
};
/* connected to port 1, Should it be reg 1? */
usb2244: device@3 {
compatible = "usb424:2244";
reset-gpios = <&slg7xl45106 2 GPIO_ACTIVE_LOW>;
reg = <3>;
};
dwc3_0: dwc3@fe200000 {
compatible = "snps,dwc3";
reg = <0x0 0xfe200000 0x0 0x40000>;
interrupt-parent = <&gic>;
interrupt-names = "dwc_usb3", "otg", "hiber";
interrupts = <0 65 4>, <0 69 4>, <0 75 4>;
...
};
};
