On 16-04-16 07:25, Edward Wingate wrote:
On Thu, Apr 14, 2016 at 10:43 PM, Mike Looijmans
<mike.looijm...@topic.nl> wrote:
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;
Neither disabled nor delete-node seem to work. CPU1 can't access the
ps7_i2c_0 unless the node is entirely defined in the device tree.
Until I figure out how to do it the right way, I'll have to leave it
like that so that it at least works, though that opens up the
possibility that something in Linux may try to access it.
The kernel "knows" about most of the clock tree in the Zynq, and it will turn
off any path that wasn't claimed by a driver (even if that clock was already
running at boot).
This leads to a 'race' with the second CPU, even if the code for that turns
the clock on at some point, the Linux kernel may still disable it later on.
Most likely the I2C clock is disabled by the kernel.
As for the clock, it just does not seem right to force-enable all clocks.
I just did this to test if it had any effect when using "incompatible"
(and "disabled" and "delete-node").
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.
How would this dummy driver ensure other Linux drivers won't access
things without also locking out CPU1 from using, say, the ps7 i2c
controller?
The driver just "registers" and enables the clocks (and power supplies, memory
ranges or whatever) the second CPU needs, and doesn't actually use them. So it
registers a memory range, some clocks, and enables these clocks. The driver
would only have a "probe" method that does this and nothing else.
If there's overlap in memory ranges for example, the kernel will complain
loudly about that.
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
