i2c pass-through in mpsoc

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

i2c pass-through in mpsoc

Jesús Lázaro
Hi,

I am trying to pass the I2C peripherial in an mpsoc. I have been
following the example to pass the mac but I keep getting the following
error:

----
(XEN) XEN_DOMCTL_assign_dt_device: assign "/amba/i2c@ff030000" to dom1
failed (-22)
libxl: error: libxl_create.c:1424:libxl__add_dtdevs: xc_assign_dtdevice
failed: -1
libxl: error: libxl_create.c:1461:domcreate_attach_devices: unable to
add dtdev devices
----

Attached I send the config file as well as the pass-through device tree.

In the main device tree I have modified the I2C to:

i2c@ff030000 {
   compatible = "cdns,i2c-r1p14", "cdns,i2c-r1p10";
   status = "disabled";
   xen,passthrough = "1";
   interrupt-parent = <0x4>;
   interrupts = <0x0 0x12 0x4>;
   reg = <0x0 0xff030000 0x0 0x1000>;
   #address-cells = <0x1>;
   #size-cells = <0x0>;
   power-domains = <0x12>;
   clocks = <0x3 0x3e>;
   clock-frequency = <0x61a80>;
};

Any hints on where the problem is?

Regards,

Jesús

_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users

Debian.cfg (542 bytes) Download Attachment
i2c_pass.dts (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: i2c pass-through in mpsoc

Julien Grall-3
On 09/10/17 10:33, Jesús Lázaro wrote:
> Hi,

Hello,

> I am trying to pass the I2C peripherial in an mpsoc. I have been
> following the example to pass the mac but I keep getting the following
> error:
>
> ----
> (XEN) XEN_DOMCTL_assign_dt_device: assign "/amba/i2c@ff030000" to dom1
> failed (-22)
> libxl: error: libxl_create.c:1424:libxl__add_dtdevs: xc_assign_dtdevice
> failed: -1
> libxl: error: libxl_create.c:1461:domcreate_attach_devices: unable to
> add dtdev devices
> ----

This is normal. dtdev will fail when the device passthrough-ed is not
behind an SMMU.

dtdev is only necessary when your device is behind an SMMU. If you know
your device will not do DMA, then you can safely drop dtdev=... and
continue.

You might also be interested by the discussion [1] which happened on
xen-devel recently regarding the same problem.

Cheers,

[1]
https://lists.xenproject.org/archives/html/xen-devel/2017-10/msg00386.html

>
> Attached I send the config file as well as the pass-through device tree.
>
> In the main device tree I have modified the I2C to:
>
> i2c@ff030000 {
>    compatible = "cdns,i2c-r1p14", "cdns,i2c-r1p10";
>    status = "disabled";
>    xen,passthrough = "1";
>    interrupt-parent = <0x4>;
>    interrupts = <0x0 0x12 0x4>;
>    reg = <0x0 0xff030000 0x0 0x1000>;
>    #address-cells = <0x1>;
>    #size-cells = <0x0>;
>    power-domains = <0x12>;
>    clocks = <0x3 0x3e>;
>    clock-frequency = <0x61a80>;
> };
>
> Any hints on where the problem is?
>
> Regards,
>
> Jesús
>
>
> _______________________________________________
> Xen-users mailing list
> [hidden email]
> https://lists.xen.org/xen-users
>

--
Julien Grall

_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: i2c pass-through in mpsoc

Jesús Lázaro
Hi,

Avoiding the dtdev property avoids any error. Now the issue is that,
although in the devicetree/passthrough section the i2c appears, the
kernel fails to load any drivers and does not create the /dev/i2c device.

The dom0 kernel has XEN support following
https://wiki.xenproject.org/wiki/Mainline_Linux_Kernel_Configs

dmesg does not offer any messages regarding issues with the i2c.

What else should I do in order to pass-through the device?

Regards,

Jesús

On 11/10/17 14:20, Julien Grall wrote:

> On 09/10/17 10:33, Jesús Lázaro wrote:
>> Hi,
>
> Hello,
>
>> I am trying to pass the I2C peripherial in an mpsoc. I have been
>> following the example to pass the mac but I keep getting the following
>> error:
>>
>> ----
>> (XEN) XEN_DOMCTL_assign_dt_device: assign "/amba/i2c@ff030000" to dom1
>> failed (-22)
>> libxl: error: libxl_create.c:1424:libxl__add_dtdevs:
>> xc_assign_dtdevice failed: -1
>> libxl: error: libxl_create.c:1461:domcreate_attach_devices: unable to
>> add dtdev devices
>> ----
>
> This is normal. dtdev will fail when the device passthrough-ed is not
> behind an SMMU.
>
> dtdev is only necessary when your device is behind an SMMU. If you know
> your device will not do DMA, then you can safely drop dtdev=... and
> continue.
>
> You might also be interested by the discussion [1] which happened on
> xen-devel recently regarding the same problem.
>
> Cheers,
>
> [1]
> https://lists.xenproject.org/archives/html/xen-devel/2017-10/msg00386.html
>
>>
>> Attached I send the config file as well as the pass-through device tree.
>>
>> In the main device tree I have modified the I2C to:
>>
>> i2c@ff030000 {
>>    compatible = "cdns,i2c-r1p14", "cdns,i2c-r1p10";
>>    status = "disabled";
>>    xen,passthrough = "1";
>>    interrupt-parent = <0x4>;
>>    interrupts = <0x0 0x12 0x4>;
>>    reg = <0x0 0xff030000 0x0 0x1000>;
>>    #address-cells = <0x1>;
>>    #size-cells = <0x0>;
>>    power-domains = <0x12>;
>>    clocks = <0x3 0x3e>;
>>    clock-frequency = <0x61a80>;
>> };
>>
>> Any hints on where the problem is?
>>
>> Regards,
>>
>> Jesús
>>
>>
>> _______________________________________________
>> Xen-users mailing list
>> [hidden email]
>> https://lists.xen.org/xen-users
>>
>

--
-------------------------------------------------------------------------
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: [hidden email]
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
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: i2c pass-through in mpsoc

Julien Grall-3


On 13/10/17 10:55, Jesús Lázaro wrote:
> Hi,

Hello,

> Avoiding the dtdev property avoids any error. Now the issue is that,
> although in the devicetree/passthrough section the i2c appears, the
> kernel fails to load any drivers and does not create the /dev/i2c device.
>
> The dom0 kernel has XEN support following
> https://wiki.xenproject.org/wiki/Mainline_Linux_Kernel_Configs
>
> dmesg does not offer any messages regarding issues with the i2c.

I am a bit confused. You say you pass-through to a guest, but speak
about Dom0 kernel. So the dmesg is from DomU or Dom0?

Note that when doing platform device passthrough, Dom0 kernel is not
involved in the process. The guest will have full access and should
detect it via device-tree.

Make sure you have I2C built in your guest kernel.

Cheers,

--
Julien Grall

_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: i2c pass-through in mpsoc

Jesús Lázaro
Hi,

I had a typo in my previous message.

Dom0 has Xen support and I am able to launch different DomU.

DomU has also Xen support for guests following:
https://wiki.xenproject.org/wiki/Mainline_Linux_Kernel_Configs

Dom0 has knowledge, through the device tree, about the I2C but appears
as disabled and with xen,passthough property.

If instead of launching Dom0 as primary OS, I launch DomU (they both are
very similar), with the I2C in the DT to okay, it appears and can be
used, so I2C support is built into the kernel.

The issue is that when being launch as DomU from Dom0, the i2c device
does not appear. The main difference is that when in non Xen
environment, the i2c is in the amba bus but when in Xen environment, it
is in the pass-through simple bus.

The passed devicetree is:

/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 = <0x7735940>;
                 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";
                 status = "okay";
                 interrupts = <0x0 0x12 0x4>;
                 reg = <0x0 0xff030000 0x0 0x1000>;
                 #address-cells = <0x1>;
                 #size-cells = <0x0>;
                 power-domains = <0x1>;
                 clocks = <0x3 0x3e>;
                 clock-frequency = <0x61a80>;
         };
     };
};

The final result is that it does not load the i2c module and does not
create the i2c device. It looks like, since it does not find any i2c in
the amba, does not bother to load the module. There are not I2C related
messages in none of the dmesgs (Dom0, DomU).


Regards,

Jesús

On 23/10/17 12:57, Julien Grall wrote:

>
>
> On 13/10/17 10:55, Jesús Lázaro wrote:
>> Hi,
>
> Hello,
>
>> Avoiding the dtdev property avoids any error. Now the issue is that,
>> although in the devicetree/passthrough section the i2c appears, the
>> kernel fails to load any drivers and does not create the /dev/i2c device.
>>
>> The dom0 kernel has XEN support following
>> https://wiki.xenproject.org/wiki/Mainline_Linux_Kernel_Configs
>>
>> dmesg does not offer any messages regarding issues with the i2c.
>
> I am a bit confused. You say you pass-through to a guest, but speak
> about Dom0 kernel. So the dmesg is from DomU or Dom0?
>
> Note that when doing platform device passthrough, Dom0 kernel is not
> involved in the process. The guest will have full access and should
> detect it via device-tree.
>
> Make sure you have I2C built in your guest kernel.
>
> Cheers,
>

--
-------------------------------------------------------------------------
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: [hidden email]
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
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: i2c pass-through in mpsoc

Julien Grall-3


On 24/10/17 07:45, Jesús Lázaro wrote:
> Hi,

Hello,

Please avoid top-posting. I am CC-ing Edgar who might also be able to
give some feedback here.

> I had a typo in my previous message.
>
> Dom0 has Xen support and I am able to launch different DomU.
>
> DomU has also Xen support for guests following:
> https://wiki.xenproject.org/wiki/Mainline_Linux_Kernel_Configs
>
> Dom0 has knowledge, through the device tree, about the I2C but appears
> as disabled and with xen,passthough property.
>
> If instead of launching Dom0 as primary OS, I launch DomU (they both are
> very similar), with the I2C in the DT to okay, it appears and can be
> used, so I2C support is built into the kernel.
>
> The issue is that when being launch as DomU from Dom0, the i2c device
> does not appear. The main difference is that when in non Xen
> environment, the i2c is in the amba bus but when in Xen environment, it
> is in the pass-through simple bus.

I am not sure what you mean here. When I looked at the mpsoc DT
(xilinx/zynqmp.dtsi), the i2c is indeed under a node called amba.

But the name of the node is irrelevant here. However the compatible
string is "simple-bus" as used in the partial device-tree below.

Did I miss anything?

>
> The passed devicetree is:
>
> /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 = <0x7735940>;
>                  compatible = "fixed-clock";
>                  linux,phandle = <0x2>;
>                  phandle = <0x2>;
>          };
>
>          pd-i2c1 {
>                  #power-domain-cells = <0x0>;
This not does not contain any compatible string. Is it normal?

>                  pd-id = <0x26>;
>                  linux,phandle = <0x1>;
>                  phandle = <0x1>;
>          };
>
>
>          i2c@ff030000 {
>                  compatible = "cdns,i2c-r1p14", "cdns,i2c-r1p10";
>                  status = "okay";
>                  interrupts = <0x0 0x12 0x4>;
>                  reg = <0x0 0xff030000 0x0 0x1000>;
>                  #address-cells = <0x1>;
>                  #size-cells = <0x0>;
>                  power-domains = <0x1>;
>                  clocks = <0x3 0x3e>;
>                  clock-frequency = <0x61a80>;
>          };
>      };
> };
>
> The final result is that it does not load the i2c module and does not
> create the i2c device. It looks like, since it does not find any i2c in
> the amba, does not bother to load the module. There are not I2C related
> messages in none of the dmesgs (Dom0, DomU).
>
>
> Regards,
>
> Jesús
>
> On 23/10/17 12:57, Julien Grall wrote:
>>
>>
>> On 13/10/17 10:55, Jesús Lázaro wrote:
>>> Hi,
>>
>> Hello,
>>
>>> Avoiding the dtdev property avoids any error. Now the issue is that,
>>> although in the devicetree/passthrough section the i2c appears, the
>>> kernel fails to load any drivers and does not create the /dev/i2c
>>> device.
>>>
>>> The dom0 kernel has XEN support following
>>> https://wiki.xenproject.org/wiki/Mainline_Linux_Kernel_Configs
>>>
>>> dmesg does not offer any messages regarding issues with the i2c.
>>
>> I am a bit confused. You say you pass-through to a guest, but speak
>> about Dom0 kernel. So the dmesg is from DomU or Dom0?
>>
>> Note that when doing platform device passthrough, Dom0 kernel is not
>> involved in the process. The guest will have full access and should
>> detect it via device-tree.
>>
>> Make sure you have I2C built in your guest kernel.
>>
>> Cheers,
>>
>

--
Julien Grall

_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: i2c pass-through in mpsoc

Jesús Lázaro
On 24/10/17 16:05, Julien Grall wrote:

>
>
> On 24/10/17 07:45, Jesús Lázaro wrote:
>> Hi,
>
> Hello,
>
> Please avoid top-posting. I am CC-ing Edgar who might also be able to
> give some feedback here.
>
>> I had a typo in my previous message.
>>
>> Dom0 has Xen support and I am able to launch different DomU.
>>
>> DomU has also Xen support for guests following:
>> https://wiki.xenproject.org/wiki/Mainline_Linux_Kernel_Configs
>>
>> Dom0 has knowledge, through the device tree, about the I2C but appears
>> as disabled and with xen,passthough property.
>>
>> If instead of launching Dom0 as primary OS, I launch DomU (they both
>> are very similar), with the I2C in the DT to okay, it appears and can
>> be used, so I2C support is built into the kernel.
>>
>> The issue is that when being launch as DomU from Dom0, the i2c device
>> does not appear. The main difference is that when in non Xen
>> environment, the i2c is in the amba bus but when in Xen environment,
>> it is in the pass-through simple bus.
>
> I am not sure what you mean here. When I looked at the mpsoc DT
> (xilinx/zynqmp.dtsi), the i2c is indeed under a node called amba.
>
> But the name of the node is irrelevant here. However the compatible
> string is "simple-bus" as used in the partial device-tree below.
>
> Did I miss anything?
>
>>
>> The passed devicetree is:
>>
>> /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 = <0x7735940>;
>>                  compatible = "fixed-clock";
>>                  linux,phandle = <0x2>;
>>                  phandle = <0x2>;
>>          };
>>
>>          pd-i2c1 {
>>                  #power-domain-cells = <0x0>;
> This not does not contain any compatible string. Is it normal?
>
>>                  pd-id = <0x26>;
>>                  linux,phandle = <0x1>;
>>                  phandle = <0x1>;
>>          };
>>
>>
>>          i2c@ff030000 {
>>                  compatible = "cdns,i2c-r1p14", "cdns,i2c-r1p10";
>>                  status = "okay";
>>                  interrupts = <0x0 0x12 0x4>;
>>                  reg = <0x0 0xff030000 0x0 0x1000>;
>>                  #address-cells = <0x1>;
>>                  #size-cells = <0x0>;
>>                  power-domains = <0x1>;
>>                  clocks = <0x3 0x3e>;
>>                  clock-frequency = <0x61a80>;
>>          };
>>      };
>> };
>>
>> The final result is that it does not load the i2c module and does not
>> create the i2c device. It looks like, since it does not find any i2c
>> in the amba, does not bother to load the module. There are not I2C
>> related messages in none of the dmesgs (Dom0, DomU).
>>
>>
>> Regards,
>>
>> Jesús
>>
>> On 23/10/17 12:57, Julien Grall wrote:
>>>
>>>
>>> On 13/10/17 10:55, Jesús Lázaro wrote:
>>>> Hi,
>>>
>>> Hello,
>>>
>>>> Avoiding the dtdev property avoids any error. Now the issue is that,
>>>> although in the devicetree/passthrough section the i2c appears, the
>>>> kernel fails to load any drivers and does not create the /dev/i2c
>>>> device.
>>>>
>>>> The dom0 kernel has XEN support following
>>>> https://wiki.xenproject.org/wiki/Mainline_Linux_Kernel_Configs
>>>>
>>>> dmesg does not offer any messages regarding issues with the i2c.
>>>
>>> I am a bit confused. You say you pass-through to a guest, but speak
>>> about Dom0 kernel. So the dmesg is from DomU or Dom0?
>>>
>>> Note that when doing platform device passthrough, Dom0 kernel is not
>>> involved in the process. The guest will have full access and should
>>> detect it via device-tree.
>>>
>>> Make sure you have I2C built in your guest kernel.
>>>
>>> Cheers,
>>>
>>
>

Hi,

I have added the compatibility for pd-i2c1 (compatible =
"xlnx,zynqmp-genpd";) but the result is the same. I do not know if it
should be there or not, I was following the example by Xilinx for the
gem and it is not there.

What I mean by the node name is that the same kernel+rootfs, if launched
normally (with its own devicetree) recognizes the i2c. When launched by
Dom0, the only difference is the devicetree and does not load it.

The resulting deviceetree for Dom0, when inside Xen is:

#########################################################
/dts-v1/;

/ {
         compatible = "xen,xenvm-4.8", "xen,xenvm";
         model = "XENVM-4.8";
         interrupt-parent = <0xfde8>;
         #address-cells = <0x2>;
         #size-cells = <0x2>;

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

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

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

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

         memory@40000000 {
                 device_type = "memory";
                 reg = <0x0 0x40000000 0x0 0x10000000>;
         };

         psci {
                 compatible = "arm,psci-0.2", "arm,psci";
                 cpu_on = <0x2>;
                 cpu_off = <0x1>;
                 method = "hvc";
         };

         interrupt-controller@3001000 {
                 compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
                 #interrupt-cells = <0x3>;
                 #address-cells = <0x0>;
                 phandle = <0xfde8>;
                 reg = <0x0 0x3001000 0x0 0x1000 0x0 0x3002000 0x0 0x2000>;
                 linux,phandle = <0xfde8>;
                 interrupt-controller;
         };

         chosen {
                 bootargs = "console=hvc0 rdinit=/sbin/init";
         };

         timer {
                 compatible = "arm,armv8-timer";
                 interrupt-parent = <0xfde8>;
                 interrupts = <0x1 0xd 0xf08 0x1 0xe 0xf08 0x1 0xb 0xf08>;
         };

         cpus {
                 #address-cells = <0x1>;
                 #size-cells = <0x0>;

                 cpu@0 {
                         compatible = "arm,armv8";
                         device_type = "cpu";
                         enable-method = "psci";
                         reg = <0x0>;
                 };
         };

         hypervisor {
                 compatible = "xen,xen-4.8", "xen,xen";
                 interrupt-parent = <0xfde8>;
                 interrupts = <0x1 0xf 0xf08>;
                 reg = <0x0 0x38000000 0x0 0x1000000>;
         };
};
#########################################################


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.

Regards,

Jesús

_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: i2c pass-through in mpsoc

Andre Przywara-2
Hi,

On 25/10/17 08:18, Jesús Lázaro wrote:
> On 24/10/17 16:05, Julien Grall wrote:

....

> I have added the compatibility for pd-i2c1 (compatible =
> "xlnx,zynqmp-genpd";) but the result is the same. I do not know if it
> should be there or not, I was following the example by Xilinx for the
> gem and it is not there.

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.

> What I mean by the node name is that the same kernel+rootfs, if launched
> normally (with its own devicetree) recognizes the i2c. When launched by
> Dom0, the only difference is the devicetree and does not load it.
>
> The resulting deviceetree for Dom0, when inside Xen is:
>
> #########################################################
> /dts-v1/;
>
> / {
>         compatible = "xen,xenvm-4.8", "xen,xenvm";
>         model = "XENVM-4.8";
>         interrupt-parent = <0xfde8>;
>         #address-cells = <0x2>;
>         #size-cells = <0x2>;
>
>         passthrough {
>                 compatible = "simple-bus";
>                 ranges;
>                 #address-cells = <0x2>;
>                 #size-cells = <0x2>;
>
>                 misc_clk {
>                         compatible = "fixed-clock";
>                         #clock-cells = <0x0>;
>                         phandle = <0x2>;
>                         clock-frequency = <0x7735940>;
>                         linux,phandle = <0x2>;
>                 };

So you have a 125 MHz oscillator(?) here, using phandle 2.

>
>                 i2c@ff030000 {
>                         power-domains = <0x1>;

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?

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

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.

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

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

>                 };
>         };
>
>         memory@40000000 {
>                 device_type = "memory";
>                 reg = <0x0 0x40000000 0x0 0x10000000>;
>         };
>
>         psci {
>                 compatible = "arm,psci-0.2", "arm,psci";
>                 cpu_on = <0x2>;
>                 cpu_off = <0x1>;
>                 method = "hvc";
>         };
>
>         interrupt-controller@3001000 {
>                 compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
>                 #interrupt-cells = <0x3>;
>                 #address-cells = <0x0>;
>                 phandle = <0xfde8>;
>                 reg = <0x0 0x3001000 0x0 0x1000 0x0 0x3002000 0x0 0x2000>;
>                 linux,phandle = <0xfde8>;
>                 interrupt-controller;
>         };
>
>         chosen {
>                 bootargs = "console=hvc0 rdinit=/sbin/init";
>         };
>
>         timer {
>                 compatible = "arm,armv8-timer";
>                 interrupt-parent = <0xfde8>;
>                 interrupts = <0x1 0xd 0xf08 0x1 0xe 0xf08 0x1 0xb 0xf08>;
>         };
>
>         cpus {
>                 #address-cells = <0x1>;
>                 #size-cells = <0x0>;
>
>                 cpu@0 {
>                         compatible = "arm,armv8";
>                         device_type = "cpu";
>                         enable-method = "psci";
>                         reg = <0x0>;
>                 };
>         };
>
>         hypervisor {
>                 compatible = "xen,xen-4.8", "xen,xen";
>                 interrupt-parent = <0xfde8>;
>                 interrupts = <0x1 0xf 0xf08>;
>                 reg = <0x0 0x38000000 0x0 0x1000000>;
>         };
> };
> #########################################################
>
>
> 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).

Cheers,
Andre.

_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: i2c pass-through in mpsoc

Jesús Lázaro
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: [hidden email]
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
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: i2c pass-through in mpsoc

Andre Przywara-2
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
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: i2c pass-through in mpsoc

Jesús Lázaro
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.


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.


Regards,

Jesús

_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: i2c pass-through in mpsoc

Andre Przywara-2
Hi Jesús,

On 26 October 2017 at 16:57, Jesús Lázaro <[hidden email]> 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
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: i2c pass-through in mpsoc

Jesús Lázaro
Hi Andre,


On 26/10/17 23:05, Andre Przywara wrote:
> Hi Jesús,
...

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

I have tried to have i2c running before Dom0 is launched. In the mpsoc,
there is a fist stage bootloader that is in charge of configuring hw
related parts. This FSBL should have all the clocks running. I have
accessed all relevant registers from uboot and they look fine. If I try
to access the other i2c core (which is disabled) uboot hangs.

 From within Dom0, I have tried to use devmem to read the i2c registers.
Here I have two different results. If i2c is enabled in the DT, linux
hangs. If disabled and with the passthrough I have the following error:

Unhandled fault: ttbr address size fault (0x92000000) at 0x0000007f875b6000

If trying to access the disabled i2c, it always hangs.

So I think that the I2C core I want to passthrough is active, has clock
and is operational. But Dom0 thinks that the clock is disabled (possibly
because reading the DT that clock is not used and the kernel does not
check all the internal registers to find out what is on or off).

If I change the clocks in the DT for the I2C (without xen) and point
them to a clock that is stopped, the driver complains about irq not
functioning. But when doing a passthorugh it does not complain. The
message is the same as when not having any active i2c device in the DT.

...


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

I have tried the networking example by Xilinx and I think that it does
not work. Without doing the uboot modification for the DMA, the result
is the same as for I2C. No module is loaded. If doing the DMA
modifications, kernel panic when launching Dom0

(XEN) GICv2: Adjusting CPU interface base to 0xf902f000
(XEN) GICv2: 192 lines, 4 cpus, secure (IID 0200143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Bad mode in Error handler detected
(XEN) ESR=0xbf000000:  EC=2f, IL=1, ISS=1000000
(XEN) ----[ Xen-4.8.1-pre  arm64  debug=n   Not tainted ]----
(XEN) CPU:    0
(XEN) PC:     00000000002823a8 start_xen+0x8e0/0xbd0
(XEN) LR:     00000000002823a0
(XEN) SP:     00000000002afe20
(XEN) CPSR:   00000249 MODE:64-bit EL2h (Hypervisor, handler)
...
(XEN) Xen call trace:
(XEN)    [<00000000002823a8>] start_xen+0x8e0/0xbd0 (PC)
(XEN)    [<00000000002823a0>] start_xen+0x8d8/0xbd0 (LR)
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) bad mode
(XEN) ****************************************


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: [hidden email]
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
[hidden email]
https://lists.xen.org/xen-users