Re: "Virtual" Interrupts -- Need help please

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/09/2013 06:06 AM, Mark Brown wrote:
On Sat, Sep 07, 2013 at 07:19:06PM -0500, Daniel Santos wrote:

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?
Unless you have a particular reason for using something else you should
be using a linear domain - that's the default, it's very simple to work
with.

Cool, thank you.

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.
Could you be more specific about what you mean by "integrate" here?

Hmm. Well one shortcoming of my driver has been lacking a way to tell the spi protocol driver which IRQ to use for interrupts. Yet another oversight on my behalf, as struct spi_device contains an int irq field just for this purpose. *sigh* Well, at least that's one problem put to rest, but I should probably elaborate further on this. Sorry in advance for the long response.

One of my original requirements for this driver is that it is reusable for different devices that use the MCP2210, not just my own hardware. There are a number of ways to accomplish this, but I'm still new to Linux device drivers, so I don't know how an "abstract driver" would work other than just making it a library that doesn't register its self as a driver. The theory is that you should be able to specify your own USB vid/pid and have your driver probe on that, then feed the generic MCP2210 driver/library your board wiring information and any parameters your other drivers need (spi or gpio-driven peripherals on the board) and let the MCP2210 driver/library do potentially everything else for you, unless your device has some needs that aren't covered.

Another requirement is for my specific device to vary its hardware somewhat, but (possibly) use the same vid/pid for these. Maybe this is some cardinal sin and a unique pid and model number for each variant is called for (like I said, I'm still new to this stuff). None the less, I've dealt with these two problems by creating an encoding scheme (which I've dubbed "Creek", since I figured I was up one if it didn't work) that compresses the data so that it will fit easily in the 256 bytes of user-EEPROM on the chip.

At the time I wrote this, I knew very little about the device tree and nothing about this Open Firmware format, so now I want to make sure I'm not re-inventing some wheel or circumventing a standard unnecessarily. Then, as I was working on figuring out how to propagate IRQs, I noticed that the irq_domain_add_linear() accepted a pointer to struct device_node and didn't not accept NULL. This made me think that I was missing something.

So basically, it's a can of worms. :) I wanted to get the interrupts working first so I could confront this once I had a fully working driver, but I suppose there's no time like the present.

So more specifically, on the EEPROM, I'm now storing the following (basically, everything in my struct board_config: https://github.com/daniel-santos/mcp2210-linux/blob/master/mcp2210.h#L483): * an optional name for the device or pin (for GPIOs, this is the name they get exported with) * an optional modalias for spi devices (defaults to "spidev") -- which of course I know mixes OS with hardware, but should be easily translatable for drivers for lessor operating systems. * for spi devices, mode, min & max bitrate and timing requirements (various delay values) * for gpios and the MCP2210's dedicated "interrupt counter" pin, an optional interrupt offset for producing IRQs * for gpios, the interrupt edge type (the dedicated interrupt counter manages this elsewhere) * how often it wants to have it's gpios and the "interrupt counter" polled (if applicable) * and soon to be added: an interrupt offset for SPI devices that want to consume IRQs (but only those generated by this MCP2210 device)

So in summary, I need to make sure that what I'm doing 1.) makes sense, 2.) adheres to standards (unless the standard fails to fulfill the real-world requirements) and 3.) doesn't unnecessarily introduce a new way to do something that's already done better elsewhere.

Thanks,
Daniel
--
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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux