Re: Updated MSI Patches

[Greg KH <greg@kroah.com>]

On Fri, Aug 08, 2003 at 12:33:01PM -0700, long wrote:
> >pcihpd-discuss?  Don't you mean the linux-pci mailing list instead?
> pcihpd-discuss is my first assumption of what you mean the linux-pci
> mailing list. Please forward me the email address of the linux-pci
> mailing list.

linux-pci@vger.kernel.org

Also, please wrap your emails at a sane size, you have lines here that
are longer than 900 characters long...  I've reformatted them here to be
able to quote them properly.

> > - Is there any way to dynamically detect if hardware can support MSI?
> The MSI patch dynamically detects whether hardware devices can support
> MSI once the CONFIG_PCI_MSI is set during kernel built.

So why would we ever want CONFIG_PCI_MSI to not be set?  I'm just trying
to make options dynamically happen without users having to worry about
setting a kernel option or not.

> > - If you enable this option, will boxes that do not support it stop
> > working?
> Once users enable this option, all devices that do not support MSI are
> still working. These devices are by default using IRQ pin assertion as
> interrupt generated mechanism since all pre-assigned vectors to any
> enabled IOxAPICs are reserved.

Good, so we can always enable this option, so it doesn't even need to be
an option :)

> >A driver has to be modified to use this option, right?  Do you have any
> >drivers that have been modified?  Without that, I don't think we can
> >test this patch out, right?
> MSI support may be transparent to some device drivers.

Yet you provide an api for drivers to use, right?  Why would a driver
want to use this api instead of just having the hardware work properly
on its own?  I guess I'm confused as to how to modify drivers to support
this, or if that's even needed to be done.

> > +++ linux-2.6.0-test2-create-vectorbase/include/asm-i386/mach-default/irq_vectors.h	2003-08-05 09:25:54.000000000 -0400
> > @@ -76,9 +76,14 @@
> >   * Since vectors 0x00-0x1f are used/reserved for the CPU,
> >   * the usable vector space is 0x20-0xff (224 vectors)
> >   */
> > +#define NR_VECTORS 256
> 
> >Will this _always_ be the value?  Can boxes have bigger numbers (I
> >haven't seen the spec, so I don't know...)
> Yes, this will always be 256 since the current CPU architecture
> supports a maximum of 256 vectors.

The "current" one does.  What happens in a few months when I go to help
bring up the next gen hardware platform?  Will I run into the problem
that this number needs to be increased?  Can we determine it at
run-time?

> > +++ linux-2.6.0-test2-create-msi/arch/i386/kernel/i386_ksyms.c	2003-08-05 09:45:25.000000000 -0400
> > @@ -166,6 +166,11 @@
> >  EXPORT_SYMBOL(IO_APIC_get_PCI_irq_vector);
> >  #endif
> >  
> > +#ifdef CONFIG_PCI_MSI
> > +EXPORT_SYMBOL(msix_alloc_vectors);
> > +EXPORT_SYMBOL(msix_free_vectors);
> > +#endif
> > +
> >  #ifdef CONFIG_MCA
> >  EXPORT_SYMBOL(machine_id);
> >  #endif
> 
> >Put the EXPORT_SYMBOL in the files that have the functions.  Don't
> >clutter up the ksyms.c files anymore.
> Agree. Will put these EXPORT_SYMBOL(s) in the file
> ../include/asm-i386/hw_irq.h where these functions are declared as
> extern. Thanks.

No, it needs to go into the .c file where the function is.

> > +u32 device_nomsi_list[DRIVER_NOMSI_MAX] = {0, };
> 
> >Shouldn't this be static?
> 
> > +u32 device_msi_list[DRIVER_NOMSI_MAX] = {0, };
> 
> >Same with this one?
> 
> In the initial design draft, I am thinking of defining
> DRIVER_NOMSI_MAX as 32 since it may be impossible to have more than 32
> MSI capable devices populated in the same system. I will add some
> comments to it and look forward for your comments.

Um, I ment the variable is in the global symbol table, and it doesn't
look like it needs to be.

But your comment about number of devices is also a good one.  Any way we
can figure that out at run-time too?  What happens when I hot-add the 33
MSI capable device?  Or just boot with that many devices (I've seen
boxes with 100s of pci devices all attached to one system)?

thanks,

greg k-h