Hi Frank,

Actually I am able to toggle GPIO now, but the GPIO is getting reset at 
Kernel. PHY reset is suppose to happen at startup on u-boot. How can I 
toggle GPIO at startup?

Thanks,
Samer

On Tuesday, August 14, 2018 at 12:20:13 PM UTC-6, sam.a...@gmail.com wrote:
>
> 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 <sam.a...@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...@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/7223bc8c-e2da-40ca-b1c4-9f599021617a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to