On 09/07/2013 07:52 PM, Guenter Roeck wrote:
On 09/07/2013 05:19 PM, Daniel Santos wrote:
I've posted a number of requests for aid on this and have gotten very
little responses and none that were helpful. I have spent at least 24
hours of research time on this and just a little direction from
somebody who knows this subsystem can help me immensely as the IRQ
subsystem is new to me.
This is for the MCP2210 driver (a USB to SPI/GPIO bridge) and my
driver is the first of its class for the Linux kernel, giving me less
to look at as an example. I intend to use standard drivers for
whatever I have connected at the other end. For this to work, I need
to supply interrupts for some of these drivers to work correctly.
How do I do this? Every thing else on this driver is ready to go and
my handler functions for this are empty and waiting for some code.
Not really. Have a look at https://github.com/groeck/diolan even
though the SPI part there
still isn't working and it is far from being acceptable upstream in
its current form.
It also doesn't support interrupts.
Oh, this is wonderful to know! While I like breaking new ground, I
certainly don't enjoy doing it when I'm trying to write my first device
driver and having to learn so many new things.
It is modeled as mfd driver, which I think you might want to consider
as well.
So do i create an IRQ domain and then call generic_handle_irq() from
my URB complete() function? If so, which type of IRQ Domain is
appropriate for this? Unlike typical platform devices, these are
dynamically added and removed throughout the life of the kernel,
adding to the challenge. So, if I understand correctly, my base IRQ
number needs to be dynamically generated. How should I manage this?
Finally, if you have any example drivers that are doing something
similar, that would be SO very helpful as well!
There are several drivers in drivers/mfd solving the same problem, ie
using
irq domains to pass interrupts to client drivers. Look for
irq_domain_add_simple().
drivers/mfd/tc3589x.c seems to be a good example.
Ahh, wonderful! I was looking at a lot of the code in mfd, but it
contains so many things that I don't understand yet, so it's been harder
to be clear on what the driver is doing and why w/o extensive
examination & study of the subsystems it's using. This will help!
I have some secondary (and less important) questions about how to
integrate this with device drivers that want a DT / open firmware
config (which I know almost nothing about at this time), but that can
wait.
If you look into the mfd subsystem, you may notice that it handles at
least some of the complexity
of interrupt handling as well as devicetree integration. One more
reason to use it.
Guenter
Even better, thank you very much!! If this thing had more EEPROM storage
I would consider using the OF format for it's settings, but I only have
256 bytes to play with so I'm using a custom compression/encoding.
I'm hoping to present this for an initial review in a month or so. I'm
sure you guys will shred it, but I'm excited about it anyway! :)
Thanks again!
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
