Re: [Xen-users] i2c pass-through in mpsoc

[Jesús Lázaro <jesus.lazaro@xxxxxxx>]

Hi,



On 25/10/17 11:31, Andre Przywara wrote:
> On 25/10/17 08:18, Jesús Lázaro wrote:
> > On 24/10/17 16:05, Julien Grall wrote:
...
> So it looks like the I2C driver misses its clock (see below).
>
> It requires a power-domain, which points to pd-i2c1, and that looks
> fine. But that also means that it's not optional, so you need the
> compatible in the pd-i2c1 node.
I have added the compatibility, copied from the Dom0 device tree, but no 
apparent change.

...

> So you have a 125 MHz oscillator(?) here, using phandle 2.
That is correct, the amba clock is 125 MHz

...

> Just for checking again: Failing to provide a working power-domain is
> fatal to the device probe process, AFAIK. So are you positive that the
> PD is working?
Every peripheral has its own power domain, so I do not know how to test 
if it is working in the DomU.

> >                          compatible = "cdns,i2c-r1p14", "cdns,i2c-r1p10";
> >                          clocks = <0x3 0x3e>;
> And here it references clock 62 in phandle 3, which I can't find
> anywhere. The only clock you have is fixed clock, with #clock-cells = 0,
> so it can't be referenced like above.
> So I guess there must be another clock (divider, PLL?), which takes the
> oscillator as an input and provides a clock 62.
Those clocks are defined in the Dom0 devicetree. I have tried to add the 
clock-names property to that of Dom0 but no change.
> So either you are missing the clock node or are not showing it here? And
> is there any debug output from the driver? From a brief look I see that
> the probe should complain about missing properties. The only thing that
> can fail silently is the MMIO mapping.
> In general it might be helpful to add pr_info() calls to understand
> where it's failing.
xl dmesg output complains about some writes to IACTIVER:

(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ 0000000000080000
(XEN) Loading ramdisk from boot module @ 000000000145a000
(XEN) Allocating 1:1 mappings totalling 768MB for dom0:
(XEN) BANK[0] 0x00000020000000-0x00000040000000 (512MB)
(XEN) BANK[1] 0x00000060000000-0x00000070000000 (256MB)
(XEN) Grant table range: 0x0000007fe00000-0x0000007fe56000
(XEN) Loading zImage from 0000000000080000 to 
0000000020080000-0000000023180000
(XEN) Loading dom0 initrd from 000000000145a000 to 
0x0000000028200000-0x000000002bda58da
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading dom0 DTB to 0x0000000028000000-0x00000000280087f7
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch 
input to Xen)
(XEN) Freed 272kB init memory.
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER4
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER8
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER12
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER16
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER20
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER0
(XEN) eemi: fn=19 No access to MMIO write fd1a00c4
(XEN) zynqmp-pm: fn=13 No access to node 15
(XEN) zynqmp-pm: fn=13 No access to node 16
(XEN) zynqmp-pm: fn=13 No access to node 17
(XEN) zynqmp-pm: fn=13 No access to node 18
(XEN) d1v0: vGICD: unhandled word write 0xffffffff to ICACTIVER4
(XEN) d1v0: vGICD: unhandled word write 0xffffffff to ICACTIVER0


> >                          status = "okay";
> >                          #address-cells = <0x1>;
> >                          interrupts = <0x0 0x12 0x4>;
> >                          #size-cells = <0x0>;
> >                          reg = <0x0 0xff030000 0x0 0x1000>;
> >                          clock-frequency = <0x61a80>;
> That is the 400KHz I2C bus *output* frequency, in case you wonder. So
> it's no substitute to the input frequency.
>
> >                  };
> >
> >                  pd-i2c1 {
> >                          compatible = "xlnx,zynqmp-genpd";
> I can't find this compatible in the Linux tree. Do you have a driver for
> that? Does it probe?
When launching without XEN, the i2c works, so it should be somewhere, 
although I cannot find it.
If I modify the passthrough device tree to resemble the power domain 
part in the Dom0:

        power-domains {
                compatible = "xlnx,zynqmp-genpd";
                pd-i2c1 {
                        #power-domain-cells = <0x0>;
                        pd-id = <0x26>;
                        linux,phandle = <0x1>;
                        phandle = <0x1>;
                };
        };


Then there is an error in the PM domain:
[    2.025089] cdns-i2c ff030000.i2c: failed to add to PM domain 
pd-i2c1: -19

...

> > I have also tried to change the i2c clocks part to <0x2 0x2> to match
> > the misc clock phandle, but the result is the same.
> That doesn't help, because phandle 2 is a fixed clock with
> #clock-cells = <0>, so it doesn't take an argument.
> You need some clock with #clock-cells = <1>, or replace that clock
> specifier with a single <0x2> (though I doubt that this works correctly,
> unless the clock is already enabled).
Since the clock is used by other peripherals (and is in the Dom0 
devicetree) it should be running.
> Cheers,
> Andre.
Regards,

Jesús

--
-------------------------------------------------------------------------
Jesús Lázaro Arrotegui Universidad del País Vasco
Tecnología Electrónica
Departamento de Tecnología Electrónica
Escuela de Ingeniería de Bilbao
Email: jesus.lazaro@xxxxxxx
WWW:   det.bi.ehu.eus/~apert
Pl. Ingeniero Torres Quevedo 1     Tel.: 34 - 94 - 601 73 44
48013 BILBAO (SPAIN)                   Fax.: 34 - 94 - 601 39 07
-------------------------------------------------------------------------

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
https://lists.xen.org/xen-users