This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3505: MDIO bitbanging alongside Linux driver

Other Parts Discussed in Thread: AM3505

Hey,

My CPU AM3505 is connected to a 3-port Micrel switch via an MDIO interface. This way I can access chip's PHY registers and my davinci linux driver is Ok for the basic L2 operation of the switch. In order to access all chip's mapped regs I require to use an SMI (Micrel's proprietary) protocol which ... not standard and could be achieved by bitbanging of the mdio/mdc lines, configured as gpio.

I am looking for a "kernel implementation" advise to understand how to combine bitbanging and the mdio control. Have tried to run the mdio-gpio.c plat-driver that is using the mdio-bitbang.c, set the pins to mux-mode4 and actually saw the bitbang SMI is working on the scope. Of course, by that, I have completely killed the davinci_mdio operation and with it, the link to the switch, as the mdio controller should be configured by the davinci driver. From the other hand, when I am running davinci with mdio/mdc in mux-mode0, the bitbang driver is muted. 

To test that, I've used a simple MII reg access using ioctl to the mdio_read/write routines, which in first case belong to the bitbang and in the second - to the davinci.

Please advise,

Best regards

Yakir

  • Hi Yakir,

    As I see it the only possibility will be to use the bit-bang interface before the Ethernet driver starts, and I don't know if your use case will allow this. Once the Ethernet driver starts the MDIO interface is continuously used for polling the PHY.

  • In my use-case I want to access the chip during run-time, same as davinci.

    It is true the phy is being polled every second or so but may it be possible to do the following on every read/write:

    1. Switch from mux-0 to mux-4 

    iowrite16(OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT, &mux[0]); //set as GPIO_107
    iowrite16(OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT, &mux[1]); //set as GPIO_108

    2. Bit bang the GPIOs

    3. Switch back

    ?

    First, not sure if both drivers can "sit" properly on the same bus (??) so using both of them might not seem as a valid option.

    Second, as an alternative, I've considered to enhance the read/write functions by a bit-bang addition into them. The lowest phy regs addresses are common and can be accessed by davinci normal bits whereas the higher (only accessible by the SMI) regs will bitbang. May it work?

    Regards

  • What you are suggesting, dynamic pinmuxing, isn't supported. 

    Have you investigated the USERACCESSn functionality? If the functionality of the embedded MDIO polling state machine is insufficient for your needs, it may make more sense to just disable it and dedicate 2 GPIOs for you to bit bang the interface manually. This should allow you to access any PHY address directly, in any manner desired. Keep in mind that in doing so, that you will need to manually (periodically) ensure that the MAC configuration matches that of the PHY since the MDIO state machine is no longer doing so.

  • Thanks for this clarification, it was really useful! 

    By looking into USERACCESSn I find to still be still a standard MDIO while in my protocol the WRITE and READ are both 00 and some other cmd bits are different as well, so I doubt it'll work. 

    I'll try to replace the legs of davinci_mdio with the gpio bitbang functionality as up to now I understand that is my only choice here.

    Do you happen to know similar developments that went 'out of the standard' over the davinci_mdio or some similar mdio drivers?

  • Hi Yakir,

    It is good to know that you have made SMI proprietary mode of MDIO working via AM3505 Board for a Micrel chip. I am having a AM335X CPU and want to bit bang for the SMI proprietary mode of MDIO on KSZ8863 chip. Can you please share your code developed for AM3505 for reference and the procedure to implement a bit banging so that I can also implement the same.

    Thank you.

    With Regards,
    N.Raghu Raman.