Ben Gardiner wrote:
This email to the list was spurred by the post "davinci: da8xx/omapl
EVM: Specify reserved channels/slots" by Sudhakar Rajashekhara.
Previous to this post my colleagues and I were under the impression
that any and all HW access should be done on the Linux side. Linux
provides a nice interface which makes our programs portable, access
control which makes our programs stable, and a plethora of facilities
for debugging and experiment which makes our programmers happy. But
there are sometimes applications (of which ours is an example, so we
believe) where the framework of the Linux kernel impedes our
development and threatens our portability.
We noticed in the recent post by Sudhakar that it is somehow
'supported' to handle DMA events on the DSP side. This makes a lot of
sense in retrospect and it spurs us to reconsider whether we can or
cannot access HW in general from the DSP side.
Are you really really sure you need to have that?
For the sake of discussion let's say that we would like to use the SPI
controller from the DSP. I think this is a good example since there
are clearly Linux drivers for this device and also ready userspace
access. If we wanted to read data from the SPI controller on some
interrupt we could register an interrupt handler in DSP/BIOS and have
rock-solid interrupt latencies without patching the kernel with
real-time support or doing any fancy driver writing for linux. Our
interrupt handler could do some heavy filtering and then pass the
bytes on to userspace via dsplink.
So, the SPI data ends up in linux user space anyway. So are you really
sure you cannot achieve your latencies with linux only?
> It doesn't seem safe to just
blindly access the SPI controller while it is registered with linux
since the /dev/spi devices could cause hardware access which at the
whim of anyone logged in to the host with access to the /dev/ entry --
so we would need to prevent that SPI controller from getting a linux
driver.
well, yes you have to unconfigure the kernel from using that SPI port
you also have to take it out of any PM going on on the linux side, so
you might need a proxy driver that at least keep this SPI port from
being power managed by linux
We had reasoned that although it might be possible to create
our own board setup routine that simply does not register the SPI
controller platform resources it might result in an unmaintainable
position in the future when we update kernel sources. We thought that
Why? you would have to adapt your board file to future kernel changes
anyway, non using a SPI port does not seems to much of a change
the davinci-linux kernel was geared for hardware access exclusively
from the Linux side and that we couldn't predict the effects of that
assumption on future versions of the kernel.
see above, I dont think that is a big issue.
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
