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

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



Hi Jesús,

On 26 October 2017 at 16:57, Jesús Lázaro <jesus.lazaro@xxxxxxx> wrote:
Hi,

First of all, thanks for your effort.

On 25/10/17 13:27, Andre Przywara wrote:
Hi,
...

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?


I am using Xilinx provided BSP (Petalinux) for a custom board.

...


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


If I removed this line, IRQ errors appear:

[    2.025183] i2c /dev entries driver
[    2.025304] cdns-i2c ff030000.i2c: cannot get irq -6
[    2.025333] cdns-i2c: probe of ff030000.i2c failed with error -22

...


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

...

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.


Most likely this is the root of the error. In a working I2C, /sys/kernel/debug/clk/clk_summary shows for the I2C:

i2c1_ref_mux           0        1  1499999985          0 0
    i2c1_ref_div0      0        1    99999999          0 0
        i2c1_ref_div1  0        1    99999999          0 0
        i2c1_ref       0        1    99999999          0 0

But when Dom0 has the i2c disabled, even with clk_ignore_unused, they turn to:
i2c1_ref_mux           0        0  1499999985          0 0
    i2c1_ref_div0      0        0    99999999          0 0
        i2c1_ref_div1  0        0    99999999          0 0
        i2c1_ref       0        0    99999999          0 0


I have modified the passthrough dtc to:
---------------------------------------------
/dts-v1/;
/ {
   #address-cells = <0x2>;
   #size-cells = <0x2>;


    passthrough {
        compatible = "simple-bus";
        ranges;
        #address-cells = <0x2>;
        #size-cells = <0x2>;

        misc_clk {
                #clock-cells = <0x0>;
                clock-frequency = <0x5F5E0FF>;
                compatible = "fixed-clock";
                linux,phandle = <0x2>;
                phandle = <0x2>;
        };

        pd-i2c1 {
                #power-domain-cells = <0x0>;
                pd-id = <0x26>;
                linux,phandle = <0x1>;
                phandle = <0x1>;
        };


        i2c@ff030000 {
                compatible = "cdns,i2c-r1p14", "cdns,i2c-r1p10";
                interrupt-parent = <0x1>;
                status = "okay";
                interrupts = <0x0 0x12 0x4>;
                reg = <0x0 0xff030000 0x0 0x1000>;
                #address-cells = <0x1>;
                #size-cells = <0x0>;
                power-domains = <0x1>;
                clock-names = "i2c1_ref", "pclk";
                clocks = <0x2 0x2>;
                clock-frequency = <0x61a80>;
        };
    };
};
---------------------------------------------

It does not work, but know the i2c has a correct clock frequency and in clock-names, it has the clocks that should be enabled in Dom0 so that they work in the guest.

I am not sure I see why they should be enabled.
 


Enabling things in fsbl/uboot and hoping for DomU not to change anything looks risky. Should XEN enable the clock-names that are passed using the passthrough?

Xen can't, because only the Dom0 clock driver knows how. We are hitting this thing more often now, and I will raise this problem on some Linux list ASAP. We would like to have something where we can specify *certain* clocks that should stay enabled, short of the clk_ignore_unused sledge hammer. Then Xen could just list those clocks in some DT node.
Another solution would be to let Dom0 explicitly enable the clocks, but this has to be done in the kernel and I am not aware of an interface to userland to trigger that from the Xen tool side.
So if you somehow can find the register that enables this clock and manipulate this in U-Boot, then pass clk_ignore_unused, it should work. I did a similar thing in the past (using md.l and mw.l on the U-Boot prompt).
  

In the example provided by Xilinx for the networking, there is no mention to the manually starting any clock, only to the DMA that must be configured to issue NS DMA. Also in the example in https://xenbits.xen.org/docs/unstable/misc/arm/passthrough.txt there is no mention to the clocks.

In this example we get somewhat lucky, because this network device does not need any clock to be specified in the DT. There is probably a clock, but it's always on.

Cheers,
Andre.



Regards,

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

 


Rackspace

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