MSI(-X) interface RFC (was: MSI prototype)

Matthew Dillon dillon at apollo.backplane.com
Sun Feb 26 14:12:54 PST 2006


:
:On 2/26/06, Matthew Dillon <dillon at xxxxxxxxxxxxxxxxxxxx> wrote:
:[re: extra args to bus_setup_intr()]
:...
:>     Hmm.  I think that might be a bit too messy, not so much because of
:>     the extra arguments, but because the arguments aren't really all that
:>     generic and only apply to MSI(X) vectors.
:>
:>     I have an idea.
:>
:>     Have bus_alloc_resource() allocate the container that represents all
:>     the vectors, just as you describe, but then create a
:>     bus_alloc_sub_resource() procedure to separately allocate each vector
:>     within that container.   Then call bus_setup_intr() for each vector
:>     individually.  The driver needs to have a loop of some sort anyway
:>     and this way we would actually have a resource descriptor for
:>     each individual vector and we wouldn't have to hack up bus_setup_intr().
:
:I like this idea alot! There still needs to be a way for
:bus_setup_intr to know which MSI-X table entry to fill with the vector
:info gleaned from bus_alloc_sub_resource(). Two thoughts come to mind:
:
:1) encode the table entry in bus_setup_intr()'s flag parameter similar
:to how aligment restrictions get passed into bus_alloc_resource with
:rman_make_alignment_flags()

    Just have bus_alloc_sub_resource() store the information in
    the interrupt record it returns as the resource.  Then bus_setup_intr()
    can simply access the information without any other changes.

:2) define a bus function that assigns a table entry number to the
:resource. This would only be used for MSI-X as IRQ and MSI only have a
:single entry for their interrupt info. I think this would be similar
:in nature to BUS_CONFIG_INTR(9).
:
:---chuck

    I was assuming bus_alloc_sub_resource() would be where the table entry
    number is specified / allocated / reserved.  But bus_setup_intr() would
    be responsible for actually installing it.
    
					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>





More information about the Kernel mailing list