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.
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!
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.
Any help *greatly* appreciated and thank you in advance!
Daniel
PS: If interested, my current driver here:
https://github.com/daniel-santos/mcp2210-linux. I haven't sought review
yet because I want to finish it first.
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.
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.
> 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
> Any help *greatly* appreciated and thank you in advance!
>
> Daniel
>
> PS: If interested, my current driver here: https://github.com/daniel-santos/mcp2210-linux. I haven't sought review yet because I want to finish it first.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
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
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
On Sun, Sep 08, 2013 at 05:35:56PM -0700, Guenter Roeck wrote:
Please fix your mailer to word wrap within paragraphs, not doing this
makes your mail very hard to read. It looks like your mailer has also
reflowed Daniel's mail.
> On 09/08/2013 04:50 PM, Daniel Santos wrote:
> >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.
If it's embedded into the device that shouldn't be such a problem -
especially for something on a pluggable bus that could be used with any
architecture device tree is pretty much a secondary concern. Device
tree is far from universal and the main concern where it is used is
with avoiding static board files.
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.
> 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?
Am 09.09.2013 13:02, schrieb Mark Brown:
> On Sun, Sep 08, 2013 at 05:35:56PM -0700, Guenter Roeck wrote:
>
> Please fix your mailer to word wrap within paragraphs, not doing this
> makes your mail very hard to read. It looks like your mailer has also
> reflowed Daniel's mail.
That's just wrong. Mail readers should wrap lines, not senders. And
readers can do this since some decades.
The reason is obvious: No sender knows the line width the receiver can
display. So, for example, if the sender hard breaks lines every 80
chars, a reader with a device which just displays 60 characters at max.
will see every second line with at most 20 characters. I assume you can
guess how such does look like. Furthermore there are still a lot of
people which do like to read mails with line length as long their
display is possible to show, and hard breaking lines on the receiver
side does make such impossible.
So the correct behaviour is to not hard break lines on the sender side
and leave that to the reader on the receiving side, as only the
receiving side knows the line width.
Alexander Holler
On 09/09/2013 04:18 AM, Alexander Holler wrote:
> Am 09.09.2013 13:02, schrieb Mark Brown:
>> On Sun, Sep 08, 2013 at 05:35:56PM -0700, Guenter Roeck wrote:
>>
>> Please fix your mailer to word wrap within paragraphs, not doing this
>> makes your mail very hard to read. It looks like your mailer has also
>> reflowed Daniel's mail.
>
> That's just wrong. Mail readers should wrap lines, not senders. And readers can do this since some decades.
>
> The reason is obvious: No sender knows the line width the receiver can display. So, for example, if the sender hard breaks lines every 80 chars, a reader with a device which just displays 60 characters at max. will see every second line with at most 20 characters. I assume you can guess how such does look like. Furthermore there are still a lot of people which do like to read mails with line length as long their display is possible to show, and hard breaking lines on the receiver side does make such impossible.
>
> So the correct behaviour is to not hard break lines on the sender side and leave that to the reader on the receiving side, as only the receiving side knows the line width.
>
I am using thunderbird and/or mutt. I don't think they reflow anything,
or at least the logged mail doesn't seem to have been reflowed (nor
does the text above).
As for what I write myself, I prefer to wrap manually, meaning automatic
insertion of newlines is turned off. Guess I can not do it right for everyone.
Guenter
Am 09.09.2013 13:45, schrieb Guenter Roeck:
> On 09/09/2013 04:18 AM, Alexander Holler wrote:
>> Am 09.09.2013 13:02, schrieb Mark Brown:
>>> On Sun, Sep 08, 2013 at 05:35:56PM -0700, Guenter Roeck wrote:
>>>
>>> Please fix your mailer to word wrap within paragraphs, not doing this
>>> makes your mail very hard to read. It looks like your mailer has also
>>> reflowed Daniel's mail.
>>
>> That's just wrong. Mail readers should wrap lines, not senders. And
>> readers can do this since some decades.
>>
>> The reason is obvious: No sender knows the line width the receiver can
>> display. So, for example, if the sender hard breaks lines every 80
>> chars, a reader with a device which just displays 60 characters at
>> max. will see every second line with at most 20 characters. I assume
>> you can guess how such does look like. Furthermore there are still a
>> lot of people which do like to read mails with line length as long
>> their display is possible to show, and hard breaking lines on the
>> receiver side does make such impossible.
Uups, sorry, I meant on the sender side here. ;)
>>
>> So the correct behaviour is to not hard break lines on the sender side
>> and leave that to the reader on the receiving side, as only the
>> receiving side knows the line width.
>>
>
> I am using thunderbird and/or mutt. I don't think they reflow anything,
> or at least the logged mail doesn't seem to have been reflowed (nor
> does the text above).
>
> As for what I write myself, I prefer to wrap manually, meaning automatic
> insertion of newlines is turned off. Guess I can not do it right for
That just the right thing to do.
> everyone.
Regards,
Alexander Holler
On Mon, Sep 09, 2013 at 01:18:01PM +0200, Alexander Holler wrote:
> Am 09.09.2013 13:02, schrieb Mark Brown:
> >makes your mail very hard to read. It looks like your mailer has also
> >reflowed Daniel's mail.
> That's just wrong. Mail readers should wrap lines, not senders. And
> readers can do this since some decades.
There's a specific way for senders to request that if it's desired, set
format=flowed in the MIME type to tell the recipient that the formatting
isn't important.
> The reason is obvious: No sender knows the line width the receiver
> can display. So, for example, if the sender hard breaks lines every
> 80 chars, a reader with a device which just displays 60 characters
> at max. will see every second line with at most 20 characters. I
> assume you can guess how such does look like. Furthermore there are
> still a lot of people which do like to read mails with line length
> as long their display is possible to show, and hard breaking lines
> on the receiver side does make such impossible.
> So the correct behaviour is to not hard break lines on the sender
> side and leave that to the reader on the receiving side, as only the
> receiving side knows the line width.
This doesn't work well with lots of content (like patches) commonly
handled in technical contexts - the line breaks actually mean something
and it's hard fo the mail client to figure out what is going on unless
someone tells it.
Am 09.09.2013 15:45, schrieb Mark Brown:
> On Mon, Sep 09, 2013 at 01:18:01PM +0200, Alexander Holler wrote:
>> Am 09.09.2013 13:02, schrieb Mark Brown:
>
>>> makes your mail very hard to read. It looks like your mailer has also
>>> reflowed Daniel's mail.
>
>> That's just wrong. Mail readers should wrap lines, not senders. And
>> readers can do this since some decades.
>
> There's a specific way for senders to request that if it's desired, set
> format=flowed in the MIME type to tell the recipient that the formatting
> isn't important.
>
>> The reason is obvious: No sender knows the line width the receiver
>> can display. So, for example, if the sender hard breaks lines every
>> 80 chars, a reader with a device which just displays 60 characters
>> at max. will see every second line with at most 20 characters. I
>> assume you can guess how such does look like. Furthermore there are
>> still a lot of people which do like to read mails with line length
>> as long their display is possible to show, and hard breaking lines
>> on the receiver side does make such impossible.
>
>> So the correct behaviour is to not hard break lines on the sender
>> side and leave that to the reader on the receiving side, as only the
>> receiving side knows the line width.
>
> This doesn't work well with lots of content (like patches) commonly
> handled in technical contexts - the line breaks actually mean something
> and it's hard fo the mail client to figure out what is going on unless
> someone tells it.
I wonder what all the hard line breaks you added to your mail do mean?
Hard line breaks in paragraphs, as you've requested, doesn't mean
anything. They just make eamils extremly ugly, e.g. your one is
displayed here with a whole lot of unused white space because I'm not
using a CGA screen. And people who do read your mail on a phone with
less than 80 or 75 chars will see it as even more ugly.
And imho it just works if hard line breaks are used where they belong
too, the code or to end paragraphs or otherwise where they have a
meaning, but not just always after 75 or 80 chars.
Regards,
Alexander Holler
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
On Mon, Sep 09, 2013 at 04:12:21PM -0500, Daniel Santos wrote:
> On 09/09/2013 06:06 AM, Mark Brown wrote:
> >On Sat, Sep 07, 2013 at 07:19:06PM -0500, Daniel Santos wrote:
> >>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?
> 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.
OK, this is a lot like the plugin modules that are fairly common in
embedded reference designs. I do have some ideas for how to put an
indirection layer in front of them but I'm not sure they're that
exciting - I expect what you end up doing will be having tables of child
device configurations registered based on the vendor ID, the vendor ID
support in the USB subsystem will let you provide either an index into
an array or just a pointer to the data for the specific board.
> 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.
That doesn't seem so bad, you can just have the decode of the main
VID/PID kick off the decode of the EEPROM contents.
> 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.
Device tree is more applicable on a system level, it's not something
it's sensible to mandate for a USB device. The struct device is as much
for in kernel usage as anything else, there are helpers to make DT
transparent but it all works perfectly fine on systems that don't even
have DT support built in.
> 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.
It doesn't seem unreasonable to me, though it'd be good to review the
specifics of course.
On 09/10/2013 01:01 PM, Mark Brown wrote:
> On Mon, Sep 09, 2013 at 04:12:21PM -0500, Daniel Santos wrote:
>> 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.
> OK, this is a lot like the plugin modules that are fairly common in
> embedded reference designs. I do have some ideas for how to put an
> indirection layer in front of them but I'm not sure they're that
> exciting - I expect what you end up doing will be having tables of child
> device configurations registered based on the vendor ID, the vendor ID
> support in the USB subsystem will let you provide either an index into
> an array or just a pointer to the data for the specific board.
Hmm, I guess I was thinking about this in the other direction: A generic
mcp2210 and then the new guy's writes a driver for his specific hardware
with it's own vid/pid and he loads up mcp2210 and sends it config, but
doesn't change mcp2210. Honestly, I forget some of the dynamics of
working with the kernel that differ from other projects -- anything can
be modified at a later date to accommodate new hardware. Just adding a
new vid/pid entry with config would be much easier and lightweight.
>> 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.
> That doesn't seem so bad, you can just have the decode of the main
> VID/PID kick off the decode of the EEPROM contents.
Currently, I'm using magic. I read the first 4 bytes of the user-EEPROM
and if it's 0xc01df00d then I presume that it will feed me configuration
data in the Creek format, after re-heating of course. I left myself a 4
bit format version field as well.
>> 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.
> Device tree is more applicable on a system level, it's not something
> it's sensible to mandate for a USB device. The struct device is as much
> for in kernel usage as anything else, there are helpers to make DT
> transparent but it all works perfectly fine on systems that don't even
> have DT support built in.
Ahh, well that's fun. I want to learn about it none the less because
the hardware that we'll interact with from usb to spi/gpio/i2s/smbus,
etc. will typically be devices who's drivers are platform drivers.
Thus, I would suspect that at least some of these drivers expect to be
fed something DT or OF related? One of my motivations here is to
leverage existing drivers for such devices, although I'm having to write
fresh ones for all of the chips I'm using in my real-world, actual
money-producing project. :)
>> 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.
> It doesn't seem unreasonable to me, though it'd be good to review the
> specifics of course.
Wonderful! It is certainly a relief and I very much appreciate your
time and feedback! When I get things a little more stable and finish
putting in the IRQ code, I would be very happy to get your help in
reviewing it. :)