Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[PATCH 3/4] vgaarb: Fix VGA Arbiter to accept PCI Domains other than 0

6 views
Skip to first unread message

Mike Travis

unread,
Jan 18, 2010, 1:40:02 PM1/18/10
to
update-vgaarb

Mike Travis

unread,
Jan 18, 2010, 1:40:01 PM1/18/10
to
update-uv-using-bios

Mike Travis

unread,
Jan 18, 2010, 1:40:01 PM1/18/10
to
update-pci

Mike Travis

unread,
Jan 18, 2010, 1:40:02 PM1/18/10
to
update-vga-max-cards

Andrew Morton

unread,
Jan 25, 2010, 7:00:02 PM1/25/10
to
On Mon, 18 Jan 2010 12:34:14 -0600
Mike Travis <tra...@sgi.com> wrote:

> @@ -717,4 +744,7 @@

Please use `diff -p'.

This is within `void __init uv_system_init(void)'

> uv_cpu_init();
> uv_scir_register_cpu_notifier();
> proc_mkdir("sgi_uv", NULL);
> +
> + /* register Legacy VGA I/O redirection handler */
> + pci_register_set_vga_state(uv_set_vga_state);
> }

So pci_register_set_vga_state() could/should have been __init?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andrew Morton

unread,
Jan 25, 2010, 7:00:02 PM1/25/10
to
On Mon, 18 Jan 2010 12:34:13 -0600
Mike Travis <tra...@sgi.com> wrote:

> Update pci_set_vga_state to call arch dependent functions to enable
> Legacy VGA I/O transactions to be redirected to correct target.
>

Changelog doesn't explain the reason for doing this, but it looks like
that becomes clearer in later patches.

>
> +/* Some architectures require additional programming to enable VGA */
> +static arch_set_vga_state_t arch_set_vga_state;
> +
> +void pci_register_set_vga_state(arch_set_vga_state_t func)
> +{
> + arch_set_vga_state = func; /* NULL disables */
> +}
> +
> +static int pci_set_vga_state_arch(struct pci_dev *dev, bool decode,
> + unsigned int command_bits, bool change_bridge)
> +{
> + if (arch_set_vga_state)
> + return arch_set_vga_state(dev, decode, command_bits,
> + change_bridge);
> + return 0;
> +}

hm, that's not terribly elegant. It's racy too, although it seems
unlikely that an arch will call pci_set_vga_state_arch() more than
once.

Still, a neater solution might be

int arch_pci_set_vga_state(...) __weak
{
return 0;
}

and then resolve it at linkage time?

Mike Travis

unread,
Jan 25, 2010, 7:10:02 PM1/25/10
to
Andrew Morton wrote:
> On Mon, 18 Jan 2010 12:34:14 -0600
> Mike Travis <tra...@sgi.com> wrote:
>
>> @@ -717,4 +744,7 @@
>
> Please use `diff -p'.
>
> This is within `void __init uv_system_init(void)'
>
>> uv_cpu_init();
>> uv_scir_register_cpu_notifier();
>> proc_mkdir("sgi_uv", NULL);
>> +
>> + /* register Legacy VGA I/O redirection handler */
>> + pci_register_set_vga_state(uv_set_vga_state);
>> }
>
> So pci_register_set_vga_state() could/should have been __init?

Good catch. Do you want me to update and resubmit?

Mike Travis

unread,
Jan 25, 2010, 7:20:02 PM1/25/10
to
Andrew Morton wrote:
> On Mon, 18 Jan 2010 12:34:13 -0600
> Mike Travis <tra...@sgi.com> wrote:
>
>> Update pci_set_vga_state to call arch dependent functions to enable
>> Legacy VGA I/O transactions to be redirected to correct target.
>>
>
> Changelog doesn't explain the reason for doing this, but it looks like
> that becomes clearer in later patches.

You're right, I should have carried more from the intro page into the
actual patch.


>
>>
>> +/* Some architectures require additional programming to enable VGA */
>> +static arch_set_vga_state_t arch_set_vga_state;
>> +
>> +void pci_register_set_vga_state(arch_set_vga_state_t func)
>> +{
>> + arch_set_vga_state = func; /* NULL disables */
>> +}
>> +
>> +static int pci_set_vga_state_arch(struct pci_dev *dev, bool decode,
>> + unsigned int command_bits, bool change_bridge)
>> +{
>> + if (arch_set_vga_state)
>> + return arch_set_vga_state(dev, decode, command_bits,
>> + change_bridge);
>> + return 0;
>> +}
>
> hm, that's not terribly elegant. It's racy too, although it seems
> unlikely that an arch will call pci_set_vga_state_arch() more than
> once.

Yes, it's only set (once) if it is a UV system.

>
> Still, a neater solution might be
>
> int arch_pci_set_vga_state(...) __weak
> {
> return 0;
> }
>
> and then resolve it at linkage time?
>
>

Wouldn't the linked in stronger function then need to surround
the UV register updating with "if (uv_system)"?

Thanks for the comments Andrew.

Andrew Morton

unread,
Jan 25, 2010, 7:20:02 PM1/25/10
to
On Mon, 25 Jan 2010 16:09:52 -0800
Mike Travis <tra...@sgi.com> wrote:

> >
> > Still, a neater solution might be
> >
> > int arch_pci_set_vga_state(...) __weak
> > {
> > return 0;
> > }
> >
> > and then resolve it at linkage time?
> >
> >
>
> Wouldn't the linked in stronger function then need to surround
> the UV register updating with "if (uv_system)"?

If the file which implements arch_pci_set_vga_state() is present in
vmlinux on non-uv systems then yes.

Presumably that file is arch/x86/kernel/apic/x2apic_uv_x.c, although
that might later become a problem if other sub-architectures a) want to
get at this hook and b) can be linked into vmlinux along with
arch/x86/kernel/apic/x2apic_uv_x.o. But such a kernel wouldn't
actually link, so we'll need to address it at that stage.


If this is a UV-specific hack which other architectures and
sub-architectures are unlikely to need (seems that way?) then I'd be
going for something whcih is simple and minimal.

H. Peter Anvin

unread,
Jan 25, 2010, 7:40:02 PM1/25/10
to
On 01/25/2010 04:05 PM, Mike Travis wrote:
>>
>> So pci_register_set_vga_state() could/should have been __init?
>
> Good catch. Do you want me to update and resubmit?

Please. This patchset is still on my review queue, FWIW.

-hpa

Mike Travis

unread,
Jan 26, 2010, 1:00:02 PM1/26/10
to
H. Peter Anvin wrote:
> On 01/25/2010 04:05 PM, Mike Travis wrote:
>>> So pci_register_set_vga_state() could/should have been __init?
>> Good catch. Do you want me to update and resubmit?
>
> Please. This patchset is still on my review queue, FWIW.
>
> -hpa

Looks like Andrew added a fix-it patch to the stream.

0 new messages