[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


On 25/10/17 11:20, Jesús Lázaro wrote:
> 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 does your Linux kernel have a driver which matches
"xlnx,zynqmp-genpd"? Because I can't find that string in mainline Linux.

Or are you using some Xilinx provided BSP kernel here?

>> 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.

"power-domains =" is a generic DT property handled by the Linux driver
framework. It should be possible to just remove that line, in case the
power-domain is already enabled.

>>>                          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.

Well, I think you are stumbling upon a general problem here: The device
driver needs a SoC specific clock, but you can't expose the whole SoC
clock device, because Dom0 needs this to drive all the other peripherals
and you don't want a DomU to mess with that.
As a quick hack you could learn the rate of that clock in Dom0:
# cat /sys/kernel/debug/clk/clk_summary
and then inject a fixed-clock with that frequency and refer to that from
the i2c node:
        i2c0_clk {
                compatible = "fixed-clock";
                #clock-cells = <0>;
                clock-frequency = <the-frequency-here>;
                phandle = <3>;

        i2c@ff030000 {
                clocks = <3>;

That should make the probe routine happy, but still doesn't mean that
your clock is enabled :-(
Chances are the Dom0 clock driver explicitly disables unused clocks. You
could try to add "clk_ignore_unused" to the Dom0 kernel command line,
but that would only take care of *not disabling* it, it would not enable
the clock explicitly. If you know how, you could try to enable the clock
from firmware (U-Boot command line, for instance).

>> 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:

This is expected and totally unrelated, please ignore them. We can
hopefully remove them soonish.

But in fact I was hoping for the DomU dmesg, to see if the driver's
probe routine complains and what it says.

> (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

That is interesting, though. But again I can't find anything in mainline
Xen which would produce this output, so are you using a vendor Xen tree?
In this case I am afraid I have to stop here, because I can't reason
about a hacked code base and don't have the time to dive into this. You
have to take this with the provider of this tree, I guess.

>>>                          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

Yes, this is because there is apparently no power-domain driver loaded
(because nothing knows about "xlnx,zynqmp-genpd"), so the device
framework stops loading the i2c driver.
Try to remove the power-domains line from the i2c node.

>>> 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.

Well, the whole clock *device* is used by other peripherals, but unless
you actually use the I2C device in Dom0, I guess its clock will be disabled.


Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.