Hello guys. I didn't get a response the last time so hopefully with
3.11 out I'll get one this time.
I need to be able to generate interrupts from a USB device driver while
servicing the complete() function of an interrupt URB. While I realize
that this may seem strange, the purpose is for a USB to SPI/GPIO bridge
chip (the MCP2210). When something happens on the remote device where a
chip is expecting it's interrupt out pin to trigger an interrupt on some
local (to the board) microcontroller, the MCP2210 instead receives that
signal and communicates it to the host the next time it's queried. This
is the interrupt that I need to, in effect propagate locally. Since my
spi_master and gpio_chip are all functioning now, this is the last step
to get one of my spi protocol drivers working correctly.
I've been reading up on Documentation/IRQ-domain.txt, but IRQ
controllers are all new to me and there's a lot for me to learn, so I
just want to make sure I'm going down the correct path. Is the correct
method to create an IRQ domain with irq_domain_add_linear() or some
such? I can figure it out eventually, but if somebody can point me in
the right direction, it can save me a WHOLE lot of time.
Thanks in advance
Daniel
On Mon, Sep 02, 2013 at 05:46:58PM -0500, Daniel Santos wrote:
> Hello guys. I didn't get a response the last time so hopefully with
> 3.11 out I'll get one this time.
>
> I need to be able to generate interrupts from a USB device driver while
> servicing the complete() function of an interrupt URB.
No you don't :)
> While I realize that this may seem strange, the purpose is for a USB
> to SPI/GPIO bridge chip (the MCP2210). When something happens on the
> remote device where a chip is expecting it's interrupt out pin to
> trigger an interrupt on some local (to the board) microcontroller, the
> MCP2210 instead receives that signal and communicates it to the host
> the next time it's queried. This is the interrupt that I need to, in
> effect propagate locally. Since my spi_master and gpio_chip are all
> functioning now, this is the last step to get one of my spi protocol
> drivers working correctly.
Just pass the data up the spi stack in your interrupt endpoint handler.
No need to try to create a "real" interrupt. There are other USB SPI
drivers that should give you the idea of how to do it.
thanks,
greg k-h
On 09/02/2013 06:07 PM, Greg KH wrote:
> On Mon, Sep 02, 2013 at 05:46:58PM -0500, Daniel Santos wrote:
>> Hello guys. I didn't get a response the last time so hopefully with
>> 3.11 out I'll get one this time.
>>
>> I need to be able to generate interrupts from a USB device driver while
>> servicing the complete() function of an interrupt URB.
> No you don't :)
>
>> While I realize that this may seem strange, the purpose is for a USB
>> to SPI/GPIO bridge chip (the MCP2210). When something happens on the
>> remote device where a chip is expecting it's interrupt out pin to
>> trigger an interrupt on some local (to the board) microcontroller, the
>> MCP2210 instead receives that signal and communicates it to the host
>> the next time it's queried. This is the interrupt that I need to, in
>> effect propagate locally. Since my spi_master and gpio_chip are all
>> functioning now, this is the last step to get one of my spi protocol
>> drivers working correctly.
> Just pass the data up the spi stack in your interrupt endpoint handler.
> No need to try to create a "real" interrupt. There are other USB SPI
> drivers that should give you the idea of how to do it.
Thanks for your response! I haven't been able to find these drivers, can
you please point me to one? I guess I don't know the "spi stack" well
enough to know how to propagate that notification up to the driver for
the spi device (let alone that it was called a "stack" :)
Thanks!!
Daniel
On Mon, Sep 02, 2013 at 08:40:47PM -0500, Daniel Santos wrote:
> On 09/02/2013 06:07 PM, Greg KH wrote:
> >On Mon, Sep 02, 2013 at 05:46:58PM -0500, Daniel Santos wrote:
> >>Hello guys. I didn't get a response the last time so hopefully with
> >>3.11 out I'll get one this time.
> >>
> >>I need to be able to generate interrupts from a USB device driver while
> >>servicing the complete() function of an interrupt URB.
> >No you don't :)
> >
> >>While I realize that this may seem strange, the purpose is for a USB
> >>to SPI/GPIO bridge chip (the MCP2210). When something happens on the
> >>remote device where a chip is expecting it's interrupt out pin to
> >>trigger an interrupt on some local (to the board) microcontroller, the
> >>MCP2210 instead receives that signal and communicates it to the host
> >>the next time it's queried. This is the interrupt that I need to, in
> >>effect propagate locally. Since my spi_master and gpio_chip are all
> >>functioning now, this is the last step to get one of my spi protocol
> >>drivers working correctly.
> >Just pass the data up the spi stack in your interrupt endpoint handler.
> >No need to try to create a "real" interrupt. There are other USB SPI
> >drivers that should give you the idea of how to do it.
> Thanks for your response! I haven't been able to find these drivers,
> can you please point me to one? I guess I don't know the "spi stack"
> well enough to know how to propagate that notification up to the
> driver for the spi device (let alone that it was called a "stack" :)
Hm, I thought we used to have some of them, I guess people have been
saying they would write a driver for this type of hardware for a long
time now :(
Anyway, look at the spi core, I think you want to tie into the
spi_new_device() call in your usb driver, and start sending/receiving
data through the SPI interfaces the spi core provides.
The Linux SPI mailing list should be able to help you out a lot more
here than I can.
greg k-h
On 09/03/2013 12:59 PM, Greg KH wrote:
> Hm, I thought we used to have some of them, I guess people have been
> saying they would write a driver for this type of hardware for a long
> time now :(
Well, on the bright side, we have one now, albeit in a "this is my first
driver that nobody has reviewed yet" state. :) It works (even on RPi --
well, mostly). As-is, it has a fair TODO & fix list, which I'm sure
will grow rapidly with some review. I hope that as I learn the kernel
better, I can generalize parts of this into some re-usable lib for other
USB-to-SPI/I2C/GPIO drivers.
https://github.com/daniel-santos/mcp2210-linux/
> Anyway, look at the spi core, I think you want to tie into the
> spi_new_device() call in your usb driver, and start sending/receiving
> data through the SPI interfaces the spi core provides.
I'm actually using the alternative to that call, which is the
spi_alloc_device() / spi_add_device() pair as I'm not using struct
spi_board_info at all since it doesn't (currently) have even half of the
fields I need for each device. However, struct spi_device does have the
two void * fields controller_data and controller_state -- I suppose I
can use those to pass a pointer to a add_notify() type of function. I
was just trying to seek a more generic, re-usable mechanism, but this
should at least work for now.
> The Linux SPI mailing list should be able to help you out a lot more
> here than I can.
>
> greg k-h
Thanks again for your help!
On 09/02/2013 06:07 PM, Greg KH wrote:
> On Mon, Sep 02, 2013 at 05:46:58PM -0500, Daniel Santos wrote:
>> Hello guys. I didn't get a response the last time so hopefully with
>> 3.11 out I'll get one this time.
>>
>> I need to be able to generate interrupts from a USB device driver while
>> servicing the complete() function of an interrupt URB.
> No you don't :)
Hmm, am I wrong that if I want my gpios to be poll()-able from userspace
(via /sys/class/gpio/gpio<num>/value), that I must generate an IRQ and
populate my .to_irq function of gpio_chip? Or is it cleaner to find the
dirent and directly call sysfs_notify_dirent() to facilitate this
behavior to userspace?
Of course, this will wont enable drivers that want an irq in the kernel,
but aside from this ADNS-9800, I don't need that functionality.
Thanks,
Daniel