One would normally add a status="disabled"; instead of changing the compatible.
You can also completely remove the node using:
/delete-node/ &ps7_i2c_0;
I stopped using the PS7 I2C controller, it's just broken and doesn't work
reliably if you need to transmit more than a few bytes. Use one in logic or
just bitbang the lines.
As for the clock, it just does not seem right to force-enable all clocks.
I would instantiate a "dummy" platform driver that doesn't really do anything,
but manages the resources that the FreeRTOS part needs, such as clocks and
memory ranges. That ensures that other drivers won't access it.
On 14-04-16 18:59, Edward Wingate wrote:
I'm using Zynq 7020 AMP config with Linux on CPU0 and FreeRTOS on
CPU1. ps7_i2c_0 is to be used by CPU1. What is the proper device
tree setting to use for ps7_i2c_0 in this case?
1) ps7_i2c_0: ps7-i2c@e0004000 { compatible = "invalid"; };
or
2) ps7_i2c_0: ps7-i2c@e0004000 {
bus-id = <0>;
clocks = <&clkc 38>;
compatible = "cdns,i2c-r1p10", "xlnx,ps7-i2c-1.00.a";
interrupt-parent = <&ps7_scugic_0>;
interrupts = <0 25 4>;
reg = <0xe0004000 0x1000>;
i2c-clk = <400000>;
#address-cells = <1>;
#size-cells = <0>; } ;
It seems if I use #1, the i2c port does not respond to CPU1, even
though I am using "clk_ignore_unused" kernel parameter to ensure i2c
clock is not disabled.
If I use #2, i2c port responds to CPU1, but then I would need to be
vigilant that nothing on Linux is trying to use that i2c port?
I am using #2 since #1 doesn't work, but is there a more proper way to
do this so that Linux/CPU0 doesn't have access to the i2c port?
Thanks for your help.
Ed
Kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
--
_______________________________________________
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
