On Mon, Mar 22, 2010 at 10:20 AM, Vladimir Pantelic <p...@nt.tu-darmstadt.de> wrote: > 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?
So I guess you agree with our current standing that all HW access should be on the linux side then? >> 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? That's a good question. It is a bit of a hypothetical situation so I can't say for sure in this case. I guess what I'm trying to get across is that we would prefer to not write linux driver code since having alot of custom Linux driver code has burned us in the past. We would prefer to use existing code bases and drivers and work to make those existing drivers stable with patches (that we post back upstream). >> 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 This 'proxy driver' would be one that grabs the platform resources and does nothing else then? Are there existing examples of proxy drivers like this? >> 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 You're absolutely right, we would need to maintain the board setup routine anyways. It isn't the cost of maintenance of the setup routine that worries us but the potential for power management schemes to change or some other kernel (runtime) interaction that we can't predict; however, I think your suggestion of a proxy driver may relieve some of the concerns. >> 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. I see. Thank you kindly for your input. We greatly appreciate it. Best Regards, Ben Gardiner _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
