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

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


First of all, thanks for your effort.

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

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.


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:
/ {
   #address-cells = <0x2>;
   #size-cells = <0x2>;

    passthrough {
        compatible = "simple-bus";
        #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.

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?

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.



Xen-users mailing list



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