[2/3] powerpc: Enable boot_vga sysfs attribute for graphics adapters on Power

Initialize dev->dev.type such that the PCI group attributes for boot_vga
and SR-IOV can be displayed if appropriate. This fixes an issue seen on
Power preventing X from auto initializing a graphics adapter when using KMS.

Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---

 arch/powerpc/kernel/pci_of_scan.c |    1 +
 1 file changed, 1 insertion(+)

On Thu, Apr 4, 2013 at 3:58 PM, Brian King <brking@linux.vnet.ibm.com> wrote:
>
> Initialize dev->dev.type such that the PCI group attributes for boot_vga
> and SR-IOV can be displayed if appropriate. This fixes an issue seen on
> Power preventing X from auto initializing a graphics adapter when using KMS.
>
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
> ---
>
>  arch/powerpc/kernel/pci_of_scan.c |    1 +
>  1 file changed, 1 insertion(+)
>
> diff -puN arch/powerpc/kernel/pci_of_scan.c~powerpc_set_pci_dev_type arch/powerpc/kernel/pci_of_scan.c
> --- linux/arch/powerpc/kernel/pci_of_scan.c~powerpc_set_pci_dev_type    2013-04-03 09:43:19.000000000 -0500
> +++ linux-bjking1/arch/powerpc/kernel/pci_of_scan.c     2013-04-03 09:43:19.000000000 -0500
> @@ -141,6 +141,7 @@ struct pci_dev *of_create_pci_dev(struct
>         dev->dev.of_node = of_node_get(node);
>         dev->dev.parent = bus->bridge;
>         dev->dev.bus = &pci_bus_type;
> +       dev->dev.type = &pci_dev_type;
>         dev->devfn = devfn;
>         dev->multifunction = 0;         /* maybe a lie? */
>         dev->needs_freset = 0;          /* pcie fundamental reset required */

I think sparc has the same issue in its own copy of of_create_pci_dev().

Of course, both of_create_pci_dev() implementations are basically
copies of the generic pci_setup_device() that most arches use.  That's
the reason why I wish sparc and powerpc had used config space
accessors that hid the OF mangling internally so they could use the
generic pci_setup_device() instead of cloning it.

Of course, they don't, and that's too much work for fixing this issue,
but if anybody wanted to work on that, I think it would be an
interesting project.

But what if you set dev->dev.type in alloc_pci_dev()?  I think if you
did that, you wouldn't need to export "pci_dev_type," and  it should
fix this for both powerpc and sparc.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Fri, 2013-04-05 at 14:11 -0600, Bjorn Helgaas wrote:
> 
> I think sparc has the same issue in its own copy of
> of_create_pci_dev().
> 
> Of course, both of_create_pci_dev() implementations are basically
> copies of the generic pci_setup_device() that most arches use.  That's
> the reason why I wish sparc and powerpc had used config space
> accessors that hid the OF mangling internally so they could use the
> generic pci_setup_device() instead of cloning it.

I disagree :-) I want the config space accessors to actually do the
config space access (it might be necessary for some reasons, if anything
for diagnostic). Also one of the reasons we create devices that way
originally iirc, is that on older pre-PCIe setups, we could have cases
of a bridge showing up at function N > 0 without anything at function
0. 

We are also not allowed to mess with bridge BARs on old EADS bridges,
and similar issues where the hypervisor can get upset.

A "filtering" config space code would be a lot messier than just
creating them like we do.

However we could/should probably make the code more common between
powerpc and sparc and maybe move the bulk of it to a generic place more
easily grepped by the PCI folks.

> Of course, they don't, and that's too much work for fixing this issue,
> but if anybody wanted to work on that, I think it would be an
> interesting project.
> 
> But what if you set dev->dev.type in alloc_pci_dev()?  I think if you
> did that, you wouldn't need to export "pci_dev_type," and  it should
> fix this for both powerpc and sparc.

Cheers,
Ben.


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

On Sat, Apr 6, 2013 at 2:00 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Fri, 2013-04-05 at 14:11 -0600, Bjorn Helgaas wrote:
>>
>> I think sparc has the same issue in its own copy of
>> of_create_pci_dev().
>>
>> Of course, both of_create_pci_dev() implementations are basically
>> copies of the generic pci_setup_device() that most arches use.  That's
>> the reason why I wish sparc and powerpc had used config space
>> accessors that hid the OF mangling internally so they could use the
>> generic pci_setup_device() instead of cloning it.
>
> I disagree :-) I want the config space accessors to actually do the
> config space access (it might be necessary for some reasons, if anything
> for diagnostic). Also one of the reasons we create devices that way
> originally iirc, is that on older pre-PCIe setups, we could have cases
> of a bridge showing up at function N > 0 without anything at function
> 0.
>
> We are also not allowed to mess with bridge BARs on old EADS bridges,
> and similar issues where the hypervisor can get upset.
>
> A "filtering" config space code would be a lot messier than just
> creating them like we do.

Yeah, maybe so.  I guess it's just hard for me to let go of ideas
until I've tried myself and failed :)

Anyway, I hope putting a little more into alloc_pci_dev() will resolve
this particular issue.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Fri, Apr 05, 2013 at 02:11:01PM -0600, Bjorn Helgaas wrote:
> On Thu, Apr 4, 2013 at 3:58 PM, Brian King <brking@linux.vnet.ibm.com> wrote:
> >
> > Initialize dev->dev.type such that the PCI group attributes for boot_vga
> > and SR-IOV can be displayed if appropriate. This fixes an issue seen on
> > Power preventing X from auto initializing a graphics adapter when using KMS.
> >
> > Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
> > ---
> >
> >  arch/powerpc/kernel/pci_of_scan.c |    1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff -puN arch/powerpc/kernel/pci_of_scan.c~powerpc_set_pci_dev_type arch/powerpc/kernel/pci_of_scan.c
> > --- linux/arch/powerpc/kernel/pci_of_scan.c~powerpc_set_pci_dev_type    2013-04-03 09:43:19.000000000 -0500
> > +++ linux-bjking1/arch/powerpc/kernel/pci_of_scan.c     2013-04-03 09:43:19.000000000 -0500
> > @@ -141,6 +141,7 @@ struct pci_dev *of_create_pci_dev(struct
> >         dev->dev.of_node = of_node_get(node);
> >         dev->dev.parent = bus->bridge;
> >         dev->dev.bus = &pci_bus_type;
> > +       dev->dev.type = &pci_dev_type;
> >         dev->devfn = devfn;
> >         dev->multifunction = 0;         /* maybe a lie? */
> >         dev->needs_freset = 0;          /* pcie fundamental reset required */
> 
> I think sparc has the same issue in its own copy of of_create_pci_dev().
> 
> Of course, both of_create_pci_dev() implementations are basically
> copies of the generic pci_setup_device() that most arches use.  That's
> the reason why I wish sparc and powerpc had used config space
> accessors that hid the OF mangling internally so they could use the
> generic pci_setup_device() instead of cloning it.
> 
> Of course, they don't, and that's too much work for fixing this issue,
> but if anybody wanted to work on that, I think it would be an
> interesting project.
> 
> But what if you set dev->dev.type in alloc_pci_dev()?  I think if you
> did that, you wouldn't need to export "pci_dev_type," and  it should
> fix this for both powerpc and sparc.

That sounds good, Brian can you confirm that works and send a new series
using that technique.

cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 04/08/2013 12:25 AM, Michael Ellerman wrote:
> On Fri, Apr 05, 2013 at 02:11:01PM -0600, Bjorn Helgaas wrote:
>> On Thu, Apr 4, 2013 at 3:58 PM, Brian King <brking@linux.vnet.ibm.com> wrote:
>>>
>>> Initialize dev->dev.type such that the PCI group attributes for boot_vga
>>> and SR-IOV can be displayed if appropriate. This fixes an issue seen on
>>> Power preventing X from auto initializing a graphics adapter when using KMS.
>>>
>>> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
>>> ---
>>>
>>>  arch/powerpc/kernel/pci_of_scan.c |    1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff -puN arch/powerpc/kernel/pci_of_scan.c~powerpc_set_pci_dev_type arch/powerpc/kernel/pci_of_scan.c
>>> --- linux/arch/powerpc/kernel/pci_of_scan.c~powerpc_set_pci_dev_type    2013-04-03 09:43:19.000000000 -0500
>>> +++ linux-bjking1/arch/powerpc/kernel/pci_of_scan.c     2013-04-03 09:43:19.000000000 -0500
>>> @@ -141,6 +141,7 @@ struct pci_dev *of_create_pci_dev(struct
>>>         dev->dev.of_node = of_node_get(node);
>>>         dev->dev.parent = bus->bridge;
>>>         dev->dev.bus = &pci_bus_type;
>>> +       dev->dev.type = &pci_dev_type;
>>>         dev->devfn = devfn;
>>>         dev->multifunction = 0;         /* maybe a lie? */
>>>         dev->needs_freset = 0;          /* pcie fundamental reset required */
>>
>> I think sparc has the same issue in its own copy of of_create_pci_dev().
>>
>> Of course, both of_create_pci_dev() implementations are basically
>> copies of the generic pci_setup_device() that most arches use.  That's
>> the reason why I wish sparc and powerpc had used config space
>> accessors that hid the OF mangling internally so they could use the
>> generic pci_setup_device() instead of cloning it.
>>
>> Of course, they don't, and that's too much work for fixing this issue,
>> but if anybody wanted to work on that, I think it would be an
>> interesting project.
>>
>> But what if you set dev->dev.type in alloc_pci_dev()?  I think if you
>> did that, you wouldn't need to export "pci_dev_type," and  it should
>> fix this for both powerpc and sparc.
> 
> That sounds good, Brian can you confirm that works and send a new series
> using that technique.

It does indeed work. I've sent a new series using this technique.

Thanks,

Brian