On Fri, Aug 10, 2018 at 2:51 PM <sam.abb...@gmail.com> wrote: > > Hi Frank, > > I tried modifying am335x-bone-common.dtsi but it did not toggle the gpio pin. > > I was also not able to find gpiod_set_valud_cansleep, in my mdio_bus.c.
Maybe we're using different Linux versions? I'm using Linux 4.14. This is what I see: https://elixir.bootlin.com/linux/v4.14.62/source/drivers/net/phy/mdio_bus.c#L357 Then lines 365 and 367 for the actual toggling of the GPIO. -Frank > > Following is my _mdiobus_register function: > > int __mdiobus_register(struct mii_bus *bus, struct module *owner) > { > int i, err; > > > if (NULL == bus || NULL == bus->name || > NULL == bus->read || NULL == bus->write) > return -EINVAL; > > > BUG_ON(bus->state != MDIOBUS_ALLOCATED && > bus->state != MDIOBUS_UNREGISTERED); > > > bus->owner = owner; > bus->dev.parent = bus->parent; > bus->dev.class = &mdio_bus_class; > bus->dev.groups = NULL; > dev_set_name(&bus->dev, "%s", bus->id); > > > err = device_register(&bus->dev); > if (err) { > pr_err("mii_bus %s failed to register\n", bus->id); > put_device(&bus->dev); > return -EINVAL; > } > > > mutex_init(&bus->mdio_lock); > > > if (bus->reset) > bus->reset(bus); > > > for (i = 0; i < PHY_MAX_ADDR; i++) { > if ((bus->phy_mask & (1 << i)) == 0) { > struct phy_device *phydev; > > > phydev = mdiobus_scan(bus, i); > if (IS_ERR(phydev)) { > err = PTR_ERR(phydev); > goto error; > } > } > } > > > bus->state = MDIOBUS_REGISTERED; > pr_info("%s: probed\n", bus->name); > return 0; > > > error: > while (--i >= 0) { > struct phy_device *phydev = bus->phy_map[i]; > if (phydev) { > phy_device_remove(phydev); > phy_device_free(phydev); > } > } > device_del(&bus->dev); > return err; > } > EXPORT_SYMBOL(__mdiobus_register); > > > > > Thank you, > Samer > > > On Thursday, August 9, 2018 at 8:28:16 AM UTC-6, Frank Hunleth wrote: >> >> Hi Samer, >> >> On Wed, Aug 8, 2018 at 11:43 AM <sam.a...@gmail.com> wrote: >> > Where exactly do I need to put this code in the device tree? >> >> In my setup, I didn't modify am33xx.dtsi. I modified the main .dts >> file for my board by adding the fragment that I posted. The analogous >> file for the beaglebones is am335x-bone-common.dtsi and if you look >> down in it, you can see the existing reference to davinci_mdio. >> >> I get confused frequently with what is actually in device tree files, >> so I almost always run `dtc -o out.dts am335x-<name>.dtb` to decompile >> the device tree and see what actually got added to it. >> >> My other idea for you is to try adding printk's to >> <kernel>/drivers/net/phy/mdio_bus.c to verify that the phy reset code >> is being called. If you open mdio_bus.c and search for the >> __mdiobus_register function, there's a line about it getting the >> "reset" GPIO from the device tree and then if it's successful, you can >> see calls to gpiod_set_valud_cansleep. I put 'printk(KERN_ERR >> "Resetting phy!!!");` calls throughout this code when I didn't see the >> gpio working. At least this way, you can know whether the GPIO is >> actually being toggled in software. >> >> -Frank >> >> > >> > I tried adding this code in am33xx.dtsi, but my GPIO is not getting >> > triggered. It looks like this: >> > >> > mac: ethernet@4a100000 { >> > compatible = "ti,am335x-cpsw","ti,cpsw"; >> > ti,hwmods = "cpgmac0"; >> > clocks = <&cpsw_125mhz_gclk>, <&cpsw_cpts_rft_clk>; >> > clock-names = "fck", "cpts"; >> > cpdma_channels = <8>; >> > ale_entries = <1024>; >> > bd_ram_size = <0x2000>; >> > mac_control = <0x20>; >> > slaves = <2>; >> > active_slave = <0>; >> > cpts_clock_mult = <0x80000000>; >> > cpts_clock_shift = <29>; >> > reg = <0x4a100000 0x800 >> > 0x4a101200 0x100>; >> > #address-cells = <1>; >> > #size-cells = <1>; >> > /* >> > * c0_rx_thresh_pend >> > * c0_rx_pend >> > * c0_tx_pend >> > * c0_misc_pend >> > */ >> > interrupts = <40 41 42 43>; >> > ranges; >> > syscon = <&scm_conf>; >> > status = "disabled"; >> > >> > davinci_mdio: mdio@4a101000 { >> > compatible = "ti,cpsw-mdio","ti,davinci_mdio"; >> > #address-cells = <1>; >> > #size-cells = <0>; >> > ti,hwmods = "davinci_mdio"; >> > bus_freq = <1000000>; >> > reg = <0x4a101000 0x100>; >> > >> > status = "disabled"; >> > }; >> > &davinci_mdio { >> > pinctrl-names = "default", "sleep"; >> > pinctrl-0 = <&davinci_mdio_default>; >> > pinctrl-1 = <&davinci_mdio_sleep>; >> > status = "okay"; >> > >> > reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>; >> > reset-delay-us = <100>; >> > ethphy0: @cpsw_emac0 {}; >> > }; >> > >> > cpsw_emac0: slave@4a100200 { >> > /* Filled in by U-Boot */ >> > mac-address = [ 00 00 00 00 00 00 ]; >> > }; >> > >> > cpsw_emac1: slave@4a100300 { >> > /* Filled in by U-Boot */ >> > mac-address = [ 00 00 00 00 00 00 ]; >> > }; >> > >> > phy_sel: cpsw-phy-sel@44e10650 { >> > compatible = "ti,am3352-cpsw-phy-sel"; >> > reg= <0x44e10650 0x4>; >> > reg-names = "gmii-sel"; >> > }; >> > }; >> > >> > Thank you, >> > Samer >> > >> > On Tuesday, August 7, 2018 at 9:28:45 PM UTC-6, Frank Hunleth wrote: >> >> >> >> On Tue, Aug 7, 2018 at 8:29 PM <sam.a...@gmail.com> wrote: >> >> > >> >> > So I cut the trace for reset pin on Lan8710 and jumpered a wire to a >> >> > gpio pin. And I added the reset gpio/reset-delay-us as shown in this >> >> > link: >> >> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/mdio.txt >> >> > >> >> > I added following commands in am335x.dtsi on line 1057 >> >> > >> >> > reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>; >> >> > reset-delay-us = <100>; >> >> > >> >> >> >> I had a similar problem. I believe that you need to specify the phy as >> >> a child node to trigger the reset GPIO logic in the mdio driver. >> >> Here's the relevant section of my device tree: >> >> >> >> &davinci_mdio { >> >> pinctrl-names = "default", "sleep"; >> >> pinctrl-0 = <&davinci_mdio_default>; >> >> pinctrl-1 = <&davinci_mdio_sleep>; >> >> status = "okay"; >> >> >> >> reset-gpios = <&gpio3 21 GPIO_ACTIVE_LOW>; >> >> reset-delay-us = <100>; >> >> ethphy0: @cpsw_emac0 {}; >> >> }; >> >> >> >> I've only done some quick tests, but it appears to be working. >> >> >> >> -Frank >> > > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/aa9139f7-3b95-48b9-96c9-380932f0cbe7%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Frank Hunleth Troodon Software LLC Embedded Software Development http://troodon-software.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CA%2B-urNTBQu1YheR-dpEFt1p2QvHkip0fV%2BcxaZuknED2M3opJw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
