On 09/08/2013 04:50 PM, Daniel Santos wrote:
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!
Yes, one of the issues with mfd is its lack of documentation. I am sure the
maintainer
will appreciate if you solve that problem by writing it :).
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.
You should really use devicetree anyway. How you get it loaded on demand is
another question. Lack of storage is not a reason.
Custom data will likely not be accepted upstream, if you had that in mind.
On the other side, we'll need PC/x86 support as well (or at least I do), so
support for platform data based initialization
data will be necessary as well.
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! :)
Let me know when you have something to test. I just ordered an evaluation board
for that chip, so I'll need it soon ;).
Guenter
--
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/
