On Mon, May 30, 2011 at 05:28:52PM +0200, sdaau wrote: > >It could just be an option to the existing ftdi_sio driver that is > >enabled somehow for a specific device, right? > > > > Well, I wish it was so - but unfortunately, it is not that way currently. > > The thing is, I'm not really an expert in programming, and even less > in kernel drivers. So, for the time that I had at my disposal, the > only thing I could have done is try to understand ALSA driver > architecture a bit better - while the USB part is completely > "abstracted". > > What I mean by that, is that the main driver file > (ftdi_sio-audard.c) is first and foremost a copy of ftdi_sio.c from > 2.6.32 kernel; then it includes a 'snd_ftdi_audard.h' file, which is > here not a traditional header; it simply contains additional > functions which 'add' the ALSA interface to ftdi_sio.c. > > Finally, the two architectures are connected, such that the ftdi's > callbacks also call the ALSA related callbacks, in particular: > > * ftdi_sio's ftdi_process_packet (raised on incoming USB data) calls > ALSA-related audard_xfer_buf function (and so the audio capture > direction is handled) > * ALSA related snd_card_audard_pcm_timer_function calls ftdi_sio's > ftdi_write function (which controls outgoing USB data - and so the > audio playback direction is handled). > > I've just posted a diff on the SVN repository between the current > ftdi_sio-audard.c and the original ftdi_sio.c from kernel 2.6.32: > > http://sdaaubckp.svn.sourceforge.net/viewvc/sdaaubckp/audard/snd_ftdi_audard-an8m/sio2.6.32-audard.diff?revision=211&view=markup > > ... the link should show syntax coloring, so it maybe gets easier to > see what's going on there. Care to email it? That way we can review it here and see how to structure it. > In essence, this driver keeps everything ftdi_sio has (so you still > get a /dev/ttyUSB0; you can still 'cat' from or 'echo' to this > device node as usual) - except that, additionally, data is passed > also to the ALSA-related memory structures (i.e. the dma_area of a > particular ALSA substream). > > Initially, I really wanted to essentially keep ftdi_sio as is, so > that I wouldn't have to worry about changes to its code; but as the > ALSA interface requires new functions, I couldn't find a way how to > selectively #include these functions based on a driver option. One > could use #defines, maybe, but that's still compile-time handling, > not run-time handling. And so, I decided to focus instead on > problems that I had a chance of solving (such as wrapping data for > the ALSA ring buffers). And just today I discovered that the driver > needs a couple of changes, that were implemented in ftdi_sio.c since > 2.6.32, so that it would compile for 2.6.38 (I have now added > comments related to this is the source file up on SVN). > > > However, if there is some sort of a tutorial/guide (or even a > specific existing driver file example) that I could refer to, so as > to turn the current architecture into an option-based one, such that > I avoid messing with ftdi_sio.c directly -- I'd definitely love to > try and do that; so please let me know if there is some sort of a > recommended reading for this. I don't think there is a "tutorial" for something like this, but we would be glad to help you out here to do this. So, care to post the code here? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
