Re: [Xenomai-help] How can I make Xenomai share a mii bus with the kernel?

[Michael Galea <michaelgalea@domain.hid>]

Philippe Gerum wrote:
> Michael Galea wrote:
>> I wonder if someone can suggest an approach to the following problem.
>>
>> We need to use xenomai to manage devices on the mii bus.  The mii bus 
>> has PHYs managed by linux. What is the best way of providing access to 
>> both linux and xenomai?
>>
>> I know that before xenomai "loads", I can simply access the mii bus from 
>> linux.  But after xenomai loads, is the right answer to make the linux 
>> function that reads the phy migrate into the xenomai domain and contend 
>> for the bus there?
>>
> 
> Problem is that Xenomai does not really compete with Linux, it preempts it
> bluntly and rudely when it needs so, regardless of the Linux locking. So regular
> Linux users of the PHY layer would start having problems, and your board would
> happily jump out of the window.
> 
> Therefore, you would have to analyze and fix every callee from net/phy (and on)
> to use Xenomai locking, instead of plain Linux locking constructs, at the very
> least. Aside of the fact that this may be quite time-consuming and error-prone,
> this would also de facto make the critical sections defined in the phy code
> non-preemptible RT-wise, which may have some impact on the worst-case latency as
> well. Sorry, this is co-kernel neighbourhood: we fancy behaving as masochistic
> zombies around here.
> 
> Question: Is the Xenomai code calling into the phy layer a real-time beast, with
> actual deadlines to be met, or not?
> 
Yes, it is.  We will be notified via interrupt that the part needs 
servicing and have to access it from xenomai.  Linux could be using the 
bus but mii operations are very quick, and for us, quite rare after boot.

> If yes, then you have no other choice than "ironing" the phy management code, so
> that it can be entered from both the Linux and real-time spaces in a mutually
> exclusive manner.
> 
The system in question is Freescale 8360 based and the mii bus is used 
to manage 5 Marvell 88e1111 Ethernet PHYs, never more, never less.  On 
my system its ucc_geth_phy that manages the bus.  I have looked at that 
and at the Marvell PHY driver source and neither use it doesn't use 
spinlocks.  Is that enough to predict that "ironing" the code is just an 
  ipipe_spinlock?

Where can I learn more about ipipe_spinlock?  I can only see the 
prototype in spinlock_types.h.


> If there are no deadlines (lucky you), then you probably want to issue a request
> (_not_ a function call, but some kind of APC) to the Linux space from your
> Xenomai task (see rthal_apc_alloc and friends). But in the latter case, the
> Xenomai task would lose any RT properties, because your code would likely want
> to wait for completion of that request on the Linux side, most of the time.
> 
> The description above assumes your code lives in kernel space. In case that code
> could live in userland, then you could use a more straightforward
> implementation, based on a small RTDM driver forwarding PHY requests and sending
> back the results to userland. Since Xenomai tasks in user-space may switch
> automatically back and forth between the Linux and Xenomai domains, you would
> not need to handle the quirks of APC handling. Still, you would not have any RT
> guarantees for the call site, but maybe that's acceptable.
>