[meta-xilinx] Fwd: PS I2C access by CPU1

Mike Looijmans mike.looijmans at topic.nl
Mon Apr 18 03:42:41 PDT 2016


On 16-04-16 07:25, Edward Wingate wrote:
> On Thu, Apr 14, 2016 at 10:43 PM, Mike Looijmans
> <mike.looijmans at 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.looijmans at topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail








More information about the meta-xilinx mailing list