|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] i2c pass-through in mpsoc
Hi,
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.
Cheers,
Andre.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
https://lists.xen.org/xen-users
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |