I tried with Kernel V4.14, but I am still not able to toggle gpio. When i run "dtc -o out.dts am335x-boneblack.dtb" I get following warnings, but I am not sure what to look for here.
debian@beaglebone:~/dtb-rebuilder-4.14.x/src/arm$ dtc -o out.dts am335x-boneblac k.dtb out.dts: Warning (unit_address_vs_reg): Node /ocp/i2c@44e0b000/tda19988 has a re g or ranges property, but no unit name out.dts: Warning (unit_address_vs_reg): Node /ocp/i2c@44e0b000/tda19988/ports/po rt@0 has a unit name, but no reg property out.dts: Warning (unit_address_vs_reg): Node /ocp/i2c@44e0b000/tda19988/ports/po rt@0/endpoint@0 has a unit name, but no reg property out.dts: Warning (unit_address_vs_reg): Node /ocp/ethernet@4a100000/mdio@4a10100 0/@cpsw_emac0 has a unit name, but no reg property out.dts: Warning (unit_address_vs_reg): Node /ocp/ethernet@4a100000/slave@4a1002 00 has a unit name, but no reg property out.dts: Warning (unit_address_vs_reg): Node /ocp/ethernet@4a100000/slave@4a1003 00 has a unit name, but no reg property out.dts: Warning (unit_address_vs_reg): Node /ocp/lcdc@4830e000/port/endpoint@0 has a unit name, but no reg property out.dts: Warning (unit_address_vs_reg): Node /bone_capemgr/baseboardmaps/board@0 has a unit name, but no reg property out.dts: Warning (unit_address_vs_reg): Node /bone_capemgr/baseboardmaps/board@1 has a unit name, but no reg property Thank you, Samer On Friday, August 10, 2018 at 1:08:40 PM UTC-6, Frank Hunleth wrote: > > On Fri, Aug 10, 2018 at 2:51 PM <[email protected] <javascript:>> 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 <[email protected]> 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 <[email protected]> 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 [email protected] <javascript:>. > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/461f1f3e-422a-4370-ba2b-4bbed90a8616%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
