On Thu, Dec 24, 2015 at 01:46:53PM +0300, Peter Mamonov wrote:
> On Wed, 23 Dec 2015 20:46:02 +0100
> Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote:
>
> > Hi Peter,
> >
> > On Wed, Dec 23, 2015 at 07:10:58PM +0300, Peter Mamonov wrote:
> > > Dear All,
> > >
> > > I've ported an UHCI driver from the u-boot to the barebox (WIP). To
> > > interoperate with the EHCI driver, the UHCI driver should be probed
> > > ater the EHCI driver. Both drivers are binded via the device tree
> > > mechanism. How can i achieve the correct probe order?
> >
> > Do you have an example binding to look at? Normally I would assume
> > that the binding makes sure somehow that the uhci driver has to be
> > probed.
>
>
> At the moment the binding is quite straightforward:
>
> ehci: ehci@1ba00200 {
> compatible = "generic-ehci";
> reg = <0x00000000 0x20 0x00000000 0x100>;
> status = "disabled";
> };
>
> uhci: uhci@1ba00000 {
> compatible = "generic-uhci";
> reg = <0x00000000 0x200>;
> status = "disabled";
> };
>
> Probably, we can add "companion = <&ehci>;" into the uhci node and
> check if the ehci has been probed by calling of_find_device_by_node(),
> as Alexander Aring proposed.
>
I mentioned the -EPROBE_DEFER because we do the same way at handling rpi
power domains, which requires the firmware module at first. See [0].
There we use:
fw_np = of_parse_phandle(pdev->dev.of_node, "firmware", 0);
in you case it would be:
ehci_np = of_parse_phandle(pdev->dev.of_node, "companion", 0);
where "pdev->dev.of_node" is uhci device node.
If this fails then we return -ENODEV, but you better don't do nothing
then because "companion" is optional then.
Back to Linux solution at [0]:
After that function "rpi_firmware_get" tries to get some driver data and
this driver data is available only when the firmware is successful probed.
Means: return -EPROBE_DEFER when function "rpi_firmware_get" returns
NULL, otherwise you can be sure that ehci is probed.
Note:
This is the linux way and I don't know if this works under barebox. :-)
Maybe there exists a better way, what Sascha said, that the device-tree
will do low-level handling of -EPROBE_DEFER somehow. I know that some
subsystems e.g. power domains will do that somehow in special
power-domain device-tree handling and magic handle the device probing in
the correct order (but at the end it's really some handling with
-EPROBE_DEFER).
- Alex
[0] https://github.com/anholt/linux/blob/b936d16077b18a575c5b892c8fe21a6ca67fc31a/arch/arm/mach-bcm/raspberrypi-power.c#L175
[1] https://github.com/anholt/linux/blob/rpi-4.2.y/drivers/firmware/raspberrypi.c#L251
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
