Messages in this thread | | | From | Anand Moon <> | Date | Mon, 21 Jun 2021 12:45:51 +0530 | Subject | Re: [RFCv1 6/8] phy: amlogic: meson8b-usb2: Use phy reset callback function |
| |
Hi Martin
Thanks for your review comments.
On Sat, 19 Jun 2021 at 01:36, Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > > Hi Anand, > > On Fri, Jun 18, 2021 at 5:33 PM Anand Moon <linux.amoon@gmail.com> wrote: > [...] > > > For shared resets (like the one we have here) reset_control_reset will > > > only trigger the reset line once until all drivers using that reset > > > line are unloaded. > > > So effectively this new phy_ops.reset callback will be a no-op. > > > > I know his register is shared between two USB IPs, > > but I have not observed any issues. > have you checked at which point we're then actually triggering the reset? > I assume that you will find that the reset is only triggered for the > very first power_on/init call - which makes this patch effectively a > no-op (yes, we're calling reset_control_reset then, but that doesn't > mean that a reset is triggered on hardware level - see > drivers/reset/core.c at around line 346). > Ok Thanks for the inputs. got your point.
I was also looking into Amlogic source code for reset. (aml_cbus_update_bits) [0] https://github.com/khadas/linux/blob/khadas-vims-4.9.y/drivers/amlogic/usb/phy/phy-aml-new-usb.c is there some feature to iomap the USB with cbus?
> [...] > > > > - priv->reset = devm_reset_control_get_optional_shared(&pdev->dev, NULL); > > > > + priv->reset = devm_reset_control_get_optional_shared(&pdev->dev, "phy"); > > > I think this breaks compatibility with existing .dtbs and our > > > dt-bindings (as we're not documenting a "reset-names" property). > > > What is the goal of this one? > > > > > > > OK, If we pass NULL over here there is the possibility > > USB phy will not get registered. > I don't understand why - with NULL everything is working fine for me. > Also no matter which name you give to the reset line (in reset-names), > it will be the same reset line in all cases. If it's the same reset > line before and after: why is this needed? > I need to investigate this reset feature. With my setup with current changes after I update the below. - priv->reset = devm_reset_control_get_optional_shared(&pdev->dev, "phy"); + priv->reset = devm_reset_control_get_optional_shared(&pdev->dev, NULL); if (PTR_ERR(priv->reset) == -EPROBE_DEFER) return PTR_ERR(priv->reset);
Reset will break the USB initialization, see below output.
[ 1.265403] dwc2 c9040000.usb: mapped PA c9040000 to VA (ptrval) [ 1.265540] dwc2 c9040000.usb: Looking up vusb_d-supply from device tree [ 1.265554] dwc2 c9040000.usb: Looking up vusb_d-supply property in node /soc/usb@c9040000 failed [ 1.265585] dwc2 c9040000.usb: supply vusb_d not found, using dummy regulator [ 1.265717] dwc2 c9040000.usb: Looking up vusb_a-supply from device tree [ 1.265730] dwc2 c9040000.usb: Looking up vusb_a-supply property in node /soc/usb@c9040000 failed [ 1.265752] dwc2 c9040000.usb: supply vusb_a not found, using dummy regulator [ 1.265812] dwc2 c9040000.usb: registering common handler for irq35 [ 1.265867] dwc2 c9040000.usb: Looking up vbus-supply from device tree [ 1.265880] dwc2 c9040000.usb: Looking up vbus-supply property in node /soc/usb@c9040000 failed [ 1.267066] dwc2 c9040000.usb: Core Release: 3.10a (snpsid=4f54310a) [ 1.270983] dwc2 c9040000.usb: dwc2_core_reset: HANG! Soft Reset timeout GRSTCTL_CSFTRST [ 1.271319] dwc2: probe of c9040000.usb failed with error -16 [ 1.273296] dwc2 c90c0000.usb: mapped PA c90c0000 to VA (ptrval) [ 1.273426] dwc2 c90c0000.usb: Looking up vusb_d-supply from device tree [ 1.273440] dwc2 c90c0000.usb: Looking up vusb_d-supply property in node /soc/usb@c90c0000 failed [ 1.273471] dwc2 c90c0000.usb: supply vusb_d not found, using dummy regulator [ 1.273607] dwc2 c90c0000.usb: Looking up vusb_a-supply from device tree [ 1.273621] dwc2 c90c0000.usb: Looking up vusb_a-supply property in node /soc/usb@c90c0000 failed [ 1.273641] dwc2 c90c0000.usb: supply vusb_a not found, using dummy regulator [ 1.273700] dwc2 c90c0000.usb: registering common handler for irq36 [ 1.273750] dwc2 c90c0000.usb: Looking up vbus-supply from device tree [ 1.273762] dwc2 c90c0000.usb: Looking up vbus-supply property in node /soc/usb@c90c0000 failed [ 1.274966] dwc2 c90c0000.usb: Core Release: 3.10a (snpsid=4f54310a) [ 1.278888] dwc2 c90c0000.usb: dwc2_core_reset: HANG! Soft Reset timeout GRSTCTL_CSFTRST [ 1.279224] dwc2: probe of c90c0000.usb failed with error -16
> > Best regards, > Martin
Thanks -Anand
| |