lkml.org 
[lkml]   [2005]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: pci_enable_msi() for everyone?
Benjamin Herrenschmidt wrote:
>> pci_enable(info on what to enable)
>>
>>so that drivers can specify ahead of time "don't enable PIO, only MMIO",
>>"don't enable MMIO, only PIO", "don't use MSI", etc. and add a
>>pci_disable() to undo all of that.
>>
>>The more we add singleton functions like pci_enable_msi(),
>>pci_set_master(), etc. the more I wish for a single function that
>>handled all those details at one atomic point. There is a lot of
>>standard patterns that are hand-coded into every PCI driver's probe
>>functions.
>
>
> Agreed, with the proper arch hook to deal with arch brokenness of
> course.
>
> That could be a bitmap. What I'm not 100% confident at this point is
> wether we want a bit per BAR or an "IO" bit and an "MMIO" bit. I think
> I'd rather go for the first one.

A bitmap is what I would start with. But I would implement it as

struct pci_enable_info {
unsigned long flags;
};

because I guarantee we'll want more flexibility as time goes on.

Honestly I can think of situations where one driver would want a bit per
BAR, and many others would just need a single MMIO bit. Don't forget
legacy decoding too: with -only- a bit per BAR, the driver cannot tell
the PCI layer that disabling IO means disabling a legacy ISA region
that's not listed in the PCI BARs.

Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-06-04 02:18    [W:0.239 / U:2.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site