| Message ID | 20210710192602.2186370-1-colin.foster@in-advantage.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add support for VSC7511-7514 chips over SPI | expand |
On Sat, Jul 10, 2021 at 12:25:54PM -0700, Colin Foster wrote: > 1. The first probe of the internal MDIO bus fails. I suspect this is related to > power supplies / grounding issues that would not appear on standard hardware. Where and with what error code does it fail exactly? I don't understand the concept of "the first probe"? You mean that there is an -EPROBE_DEFER and it tries again immediately afterwards? Or you need to unbind and rebind the driver to the device, or what? > 2. Communication to the CPU bus doesn't seem to function properly. I suspect > this is due to the fact that ocelot / felix assumes it is using the built-in CPU > / NPI port for forwarding, though I am not positive. What is the CPU bus and what doesn't function properly about it? > Nonetheless, these two issues likely won't require a large architecture change, > and perhaps those who know much more about the ocelot chips than I could chime > in. I guess you don't know if that's the case or not until you know what the problem is...
On 10/07/2021 12:25:54-0700, Colin Foster wrote: > Add support for configuration and control of the VSC7511, VSC7512, VSC7513, and > VSC7514 chips over a SPI interface. The intent is to control these chips from an > external CPU. The expectation is to have most of the features of the > net/ethernet/mscc/ocelot_vsc7514 driver. > > I have tried to heed all the advice from my first patch RFC. Thanks to everyone > for all the feedback. > > The current status is that there are two functional "bugs" that need > investigation: > 1. The first probe of the internal MDIO bus fails. I suspect this is related to > power supplies / grounding issues that would not appear on standard hardware. Did you properly reset the internal phys? mdio-mscc-miim.c does that.
On Sat, Jul 10, 2021 at 10:47:55PM +0300, Vladimir Oltean wrote: > On Sat, Jul 10, 2021 at 12:25:54PM -0700, Colin Foster wrote: > > 1. The first probe of the internal MDIO bus fails. I suspect this is related to > > power supplies / grounding issues that would not appear on standard hardware. > > Where and with what error code does it fail exactly? I don't understand > the concept of "the first probe"? You mean that there is an > -EPROBE_DEFER and it tries again immediately afterwards? Or you need to > unbind and rebind the driver to the device, or what? My hardware I'm using for test / dev is a bit of a hack. Beaglebone jumped to a VSC7512 dev board SPI lines after some modifications. I believe I'm seeing grounding-related issues as a result of this. For instance, if I power on the dev board before powering on the Beaglebone, the BB will be held in reset. The same thing will happen if I reset the BB when the Microsemi dev board has been powered on, but left unconfigured. When I run "modprobe mscc_ocelot_spi" the first time the driver fails to enumerate swp1-3 with "failed to connect to port X: -19" message. But after doing that, I can reset the BB to my heart's content. Future boots will be able to successfully find those at initial mod insertion. And reloading / rebinding the driver successfully registers the ports at spi0.0-imdio:0X > > > 2. Communication to the CPU bus doesn't seem to function properly. I suspect > > this is due to the fact that ocelot / felix assumes it is using the built-in CPU > > / NPI port for forwarding, though I am not positive. > > What is the CPU bus and what doesn't function properly about it? I'm still learning a lot about how the chip functions, especially now that I have attained some functionality from the driver. There's a CPU bus that can be utilized when you're running internally, and I believe that can be configured as the NPI bus if you're running through PCIe. When controlling through SPI I'm not convinced we'll have access to that bus, and if the Ocelot driver relies on that functionality I've got some more work in front of me. > > > Nonetheless, these two issues likely won't require a large architecture change, > > and perhaps those who know much more about the ocelot chips than I could chime > > in. > > I guess you don't know if that's the case or not until you know what the > problem is... True
On Sat, Jul 10, 2021 at 10:01:45PM +0200, Alexandre Belloni wrote: > On 10/07/2021 12:25:54-0700, Colin Foster wrote: > > Add support for configuration and control of the VSC7511, VSC7512, VSC7513, and > > VSC7514 chips over a SPI interface. The intent is to control these chips from an > > external CPU. The expectation is to have most of the features of the > > net/ethernet/mscc/ocelot_vsc7514 driver. > > > > I have tried to heed all the advice from my first patch RFC. Thanks to everyone > > for all the feedback. > > > > The current status is that there are two functional "bugs" that need > > investigation: > > 1. The first probe of the internal MDIO bus fails. I suspect this is related to > > power supplies / grounding issues that would not appear on standard hardware. > > Did you properly reset the internal phys? mdio-mscc-miim.c does that. That code looks familiar to what I wrote, but the mdio-mscc-miim.c implementation has the 500ms delay. That might be all I need...