On 9/3/2020 2:42 PM, Andrew Lunn wrote:
On Thu, Sep 03, 2020 at 03:28:22PM -0600, Rob Herring wrote:
What if a device requires clocks enabled in a certain order or timing?
It's not just clocks, you could have some GPIOs or a regulator that
need enabling first. It's device specific, so really needs a per
device solution. This is not just an issue with MDIO. I think we
really need some sort of pre-probe hook in the driver model in order
to do any non-discoverable init for discoverable buses.
Hi Rob
How do you solve the chicken/egg of knowing what device specific init
is needed before you can discover what device you have on the bus?
For MDIO since we have a fixed number of devices on the bus, we could
pre-populate the MDIO map for all addresses, and free up the devices
that we did not probe.
When using DT we can first parse the address, create a mdio_device
there, and then turn on clocks/regulators/GPIOs whatever since we now
have a device reference. Only then do we bind the device with its driver.
If we are using the DT scanning loop because the node did not provide a
"reg" property, then the PHY must be in a functional state to be probed,
we cannot guess what we do not know.
All of this uses MDIO implementation knowledge though.
Or perhaps forcing probe when there are devices defined in DT if
they're not discovered by normal means.
The PHY subsystem has this. You came specify in DT the ID of the
device which we would normally read during bus discovery. The correct
driver is then loaded and probed. But it is good practice to avoid
this. OEMs are known to change the PHY in order to perform cost
optimisation. So we prefer to do discover and do the right thing if
the PHY has changed.
As for GPIOS and regulators, i expect this code will expand pretty
soon after being merged to handle those. There are users wanting
it. We already have some standard properties defined, in terms of
gpios, delay while off, delay after turning it on. As for ordering, i
guess it would make sense to enable the clocks and then hit it with a
reset? If there is a device which cannot be handled like this, it can
always hard code its ID in device tree, and fully control its
resources in the driver.
Andrew
--
Florian
