Re: [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT

[Lorenzo Pieralisi]

On Wed, Nov 29, 2023 at 03:12:40PM -0400, Jason Gunthorpe wrote:
> On Wed, Nov 29, 2023 at 01:55:04PM +0100, Lorenzo Pieralisi wrote:
> 
> > I don't think it should be done this way. Is the goal compile testing
> > IORT code ? 
> 
> Yes
> 
> > If so, why are we forcing it through the SMMU (only because
> > it can be compile tested while eg SMMUv3 driver can't ?) menu entry ?
> 
> Because something needs to select it, and SMMU is one of the places
> that are implicitly using it.
> 
> It isn't (and shouldn't be) a user selectable kconfig. Currently the
> only thing that selects it is the ARM64 master kconfig.

I never said it should be a user selectable kconfig. I said that
I don't like using the SMMU entry (only) to select it just because
that entry allows COMPILE_TEST.

> > This looks a bit artificial (and it is unclear from the Kconfig
> > file why only that driver selects IORT, it looks like eg the SMMUv3
> > does not have the same dependency - there is also the SMMUv3 perf
> > driver to consider).
> 
> SMMUv3 doesn't COMPILE_TEST so it picks up the dependency transitivity
> through ARM64. I'm not sure why IORT was put as a global ARM64 kconfig
> dependency and not put in the places that directly need it.

Because IORT is used by few ARM64 system IPs (that are enabled by
default, eg GIC), it makes sense to have a generic ARM64 select (if ACPI).

> "perf driver" ? There is a bunch of GIC stuff that uses this too but I
> don't know if it compile tests.

"SMMUv3 perf driver" drivers/perf/arm_smmuv3_pmu.c

> > Maybe we can move IORT code into drivers/acpi and add a silent config
> > option there with a dependency on ARM64 || COMPILE_TEST.
> 
> That seems pretty weird to me, this is the right way to approach it,
> IMHO. Making an entire directory condition is pretty incompatible with
> COMPILE_TEST as a philosophy.

That's not what I was suggesting. I was suggesting to move iort.c (or
some portions of it) into drivers/acpi if we care enough to compile test
it on arches !ARM64.

It is also weird to have a file in drivers/acpi/arm64 that you want
to compile test on other arches IMO (and I don't think it is very useful
to compile test it either).

> > Don't know but at least it is clearer. As for the benefits of compile
> > testing IORT code - yes the previous patch is a warning to fix but
> > I am not so sure about the actual benefits.
> 
> IMHO COMPILE_TEST is an inherently good thing. It makes development
> easier for everyone because you have a less fractured code base to
> work with.

I am talking about IORT code, not COMPILE_TEST as a whole.

I am not sure what "less fractured" means in this context.

Anyway - it is not a big deal either way but I don't like selecting
ACPI_IORT only on kconfig entries that allow COMPILE_TEST to implicitly
compile test it so *if* we want to do it we will have to do it
differently.

Thanks,
Lorenzo

Re: [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT

[Lorenzo Pieralisi]

On Tue, Nov 28, 2023 at 08:48:06PM -0400, Jason Gunthorpe wrote:
> The arm-smmu driver can COMPILE_TEST on x86, so expand this to also
> enable the IORT code so it can be COMPILE_TEST'd too.
> 
> Signed-off-by: Jason Gunthorpe 
> ---
>  drivers/acpi/Kconfig| 2 --
>  drivers/acpi/Makefile   | 2 +-
>  drivers/acpi/arm64/Kconfig  | 1 +
>  drivers/acpi/arm64/Makefile | 2 +-
>  drivers/iommu/Kconfig   | 1 +
>  5 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index f819e760ff195a..3b7f77b227d13a 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -541,9 +541,7 @@ config ACPI_PFRUT
> To compile the drivers as modules, choose M here:
> the modules will be called pfr_update and pfr_telemetry.
>  
> -if ARM64
>  source "drivers/acpi/arm64/Kconfig"
> -endif
>  
>  config ACPI_PPTT
>   bool
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index eaa09bf52f1760..4e77ae37b80726 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -127,7 +127,7 @@ obj-y += pmic/
>  video-objs   += acpi_video.o video_detect.o
>  obj-y+= dptf/
>  
> -obj-$(CONFIG_ARM64)  += arm64/
> +obj-y+= arm64/
>  
>  obj-$(CONFIG_ACPI_VIOT)  += viot.o
>  
> diff --git a/drivers/acpi/arm64/Kconfig b/drivers/acpi/arm64/Kconfig
> index b3ed6212244c1e..537d49d8ace69e 100644
> --- a/drivers/acpi/arm64/Kconfig
> +++ b/drivers/acpi/arm64/Kconfig
> @@ -11,6 +11,7 @@ config ACPI_GTDT
>  
>  config ACPI_AGDI
>   bool "Arm Generic Diagnostic Dump and Reset Device Interface"
> + depends on ARM64
>   depends on ARM_SDE_INTERFACE
>   help
> Arm Generic Diagnostic Dump and Reset Device Interface (AGDI) is
> diff --git a/drivers/acpi/arm64/Makefile b/drivers/acpi/arm64/Makefile
> index 143debc1ba4a9d..71d0e635599390 100644
> --- a/drivers/acpi/arm64/Makefile
> +++ b/drivers/acpi/arm64/Makefile
> @@ -4,4 +4,4 @@ obj-$(CONFIG_ACPI_IORT)   += iort.o
>  obj-$(CONFIG_ACPI_GTDT)  += gtdt.o
>  obj-$(CONFIG_ACPI_APMT)  += apmt.o
>  obj-$(CONFIG_ARM_AMBA)   += amba.o
> -obj-y+= dma.o init.o
> +obj-$(CONFIG_ARM64)  += dma.o init.o
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 7673bb82945b6c..309378e76a9bc9 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -318,6 +318,7 @@ config ARM_SMMU
>   select IOMMU_API
>   select IOMMU_IO_PGTABLE_LPAE
>   select ARM_DMA_USE_IOMMU if ARM
> + select ACPI_IORT if ACPI
>   help
> Support for implementations of the ARM System MMU architecture
> versions 1 and 2.
> -- 

I don't think it should be done this way. Is the goal compile testing
IORT code ? If so, why are we forcing it through the SMMU (only because
it can be compile tested while eg SMMUv3 driver can't ?) menu entry ?

This looks a bit artificial (and it is unclear from the Kconfig
file why only that driver selects IORT, it looks like eg the SMMUv3
does not have the same dependency - there is also the SMMUv3 perf
driver to consider).

Maybe we can move IORT code into drivers/acpi and add a silent config
option there with a dependency on ARM64 || COMPILE_TEST.

Don't know but at least it is clearer. As for the benefits of compile
testing IORT code - yes the previous patch is a warning to fix but
I am not so sure about the actual benefits.

Thanks,
Lorenzo

Re: (subset) [PATCH v1 00/11] Get rid of [devm_]gpiod_get_from_of_node() public APIs

[Lorenzo Pieralisi]

On Sun, 4 Sep 2022 23:30:52 -0700, Dmitry Torokhov wrote:
> I would like to stop exporting OF-specific [devm_]gpiod_get_from_of_node()
> so that gpiolib can be cleaned a bit. We can do that by switching drivers
> to use generic fwnode API ([devm_]fwnode_gpiod_get()). By doing so we open
> the door to augmenting device tree and ACPI information through secondary
> software properties (once we teach gpiolib how to handle those).
> 
> I hope that relevant maintainers will take patches through their trees and
> then we could merge the last one some time after -rc1.
> 
> [...]

Applied to pci/tegra, thanks!

[01/11] PCI: tegra: switch to using devm_fwnode_gpiod_get
https://git.kernel.org/lpieralisi/pci/c/16e3f4077965

Thanks,
Lorenzo

Re: [PATCH v11 00/11] PCI: brcmstb: enable PCIe for STB chips

[Lorenzo Pieralisi]

On Mon, Sep 07, 2020 at 11:29:06AM -0700, Florian Fainelli wrote:
> 
> 
> On 9/7/2020 10:43 AM, Jim Quinlan wrote:
> > On Mon, Sep 7, 2020 at 5:16 AM Lorenzo Pieralisi
> >  wrote:
> > > 
> > > On Thu, Aug 27, 2020 at 09:29:59AM -0400, Jim Quinlan wrote:
> > > > On Thu, Aug 27, 2020 at 2:35 AM Christoph Hellwig  wrote:
> > > > > 
> > > > > On Tue, Aug 25, 2020 at 10:40:27AM -0700, Florian Fainelli wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On 8/24/2020 12:30 PM, Jim Quinlan wrote:
> > > > > > > 
> > > > > > > Patchset Summary:
> > > > > > > Enhance a PCIe host controller driver.  Because of its 
> > > > > > > unusual design
> > > > > > > we are foced to change dev->dma_pfn_offset into a more 
> > > > > > > general role
> > > > > > > allowing multiple offsets.  See the 'v1' notes below for more 
> > > > > > > info.
> > > > > > 
> > > > > > We are version 11 and counting, and it is not clear to me whether 
> > > > > > there is
> > > > > > any chance of getting these patches reviewed and hopefully merged 
> > > > > > for the
> > > > > > 5.10 merge window.
> > > > > > 
> > > > > > There are a lot of different files being touched, so what would be 
> > > > > > the
> > > > > > ideal way of routing those changes towards inclusion?
> > > > > 
> > > > > FYI, I offered to take the dma-mapping bits through the dma-mapping 
> > > > > tree.
> > > > > I have a bit of a backlog, but plan to review and if Jim is ok with 
> > > > > that
> > > > > apply the current version.
> > > > Sounds good to me.
> > > 
> > > Hi Jim,
> > > 
> > > is the dependency now solved ? Should we review/take this series as
> > > is for v5.10 through the PCI tree ?
> > Hello Lorenzo,
> > 
> > We are still working out a regression with the DMA offset commit on
> > the RaspberryPi.  Nicolas has found the root cause and we are now
> > devising a solution.
> 
> Maybe we can parallelize the PCIe driver review while the DMA changes
> are being worked on in Christoph's branch. Lorenzo, are you fine with
> the PCIe changes proper?

I will have a look - the main contentious point was about the DMA
changes - if Christoph is happy with them I am OK with them
too - I hope there is not anything controversial in the host
bridge driver itself but I will look into it.

Lorenzo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v11 00/11] PCI: brcmstb: enable PCIe for STB chips

[Lorenzo Pieralisi]

On Thu, Aug 27, 2020 at 09:29:59AM -0400, Jim Quinlan wrote:
> On Thu, Aug 27, 2020 at 2:35 AM Christoph Hellwig  wrote:
> >
> > On Tue, Aug 25, 2020 at 10:40:27AM -0700, Florian Fainelli wrote:
> > > Hi,
> > >
> > > On 8/24/2020 12:30 PM, Jim Quinlan wrote:
> > >>
> > >> Patchset Summary:
> > >>Enhance a PCIe host controller driver.  Because of its unusual design
> > >>we are foced to change dev->dma_pfn_offset into a more general role
> > >>allowing multiple offsets.  See the 'v1' notes below for more info.
> > >
> > > We are version 11 and counting, and it is not clear to me whether there is
> > > any chance of getting these patches reviewed and hopefully merged for the
> > > 5.10 merge window.
> > >
> > > There are a lot of different files being touched, so what would be the
> > > ideal way of routing those changes towards inclusion?
> >
> > FYI, I offered to take the dma-mapping bits through the dma-mapping tree.
> > I have a bit of a backlog, but plan to review and if Jim is ok with that
> > apply the current version.
> Sounds good to me.

Hi Jim,

is the dependency now solved ? Should we review/take this series as
is for v5.10 through the PCI tree ?

Thanks,
Lorenzo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/4] ARM: dts: imx6sx: Add DISPLAY power domain support

[Lorenzo Pieralisi]

On Mon, Oct 08, 2018 at 06:06:18PM +, Leonard Crestez wrote:
> Now that mxsfb has functional runtime_pm support we can enable power
> gating for the DISPLAY power domain on imx6sx.
> 
> Since pci-imx doesn't support runtime power gating this is still
> always-on unless PCI is disabled/unused. But it's reasonable for an imx
> board to not have PCI.
> 
> The current pd_pcie is actually only for PCIE_PHY, the PCIE ip block is
> actually inside the DISPLAY domain. This is handled by adding the pcie
> node in both power domains, using multi-pd support.
> 
> Series is against linux-next. The last patch needs runtime PM in all
> drivers or it will cause hangs. This means Shawn should hold back on it
> until the PCI and mxsfb dependencies get merged (both might take a long
> time). So you can just review that patch and I will resend it later,
> perhaps in another cycle.
> 
> ---
> 
> Changes since v1:
> * Document multi-pd in imx6q-pcie bindings and add DT list
> * Don't refer to "DISPLAY" as "DISPMIX" because the Reference Manual
> doesn't do that.
> * Link to v1: https://lore.kernel.org/patchwork/cover/994092/
> 
> This is independent of other imx6-pci PM patches such as this one:
> * https://lore.kernel.org/patchwork/patch/996806/
> Device links are quite nice!
> 
> Link to mxsfb thread: https://lkml.org/lkml/2018/9/26/1185
> 
> Leonard Crestez (4):
>   soc: imx: gpc: Increase GPC_CLK_MAX to 7
>   dt-bindings: imx6q-pcie: Add multi-pd bindings for imx6sx
>   PCI: imx: Add multi-pd support
>   ARM: dts: imx6sx: Add DISPLAY power domain support
> 
>  .../bindings/pci/fsl,imx6q-pcie.txt   |  4 +-
>  arch/arm/boot/dts/imx6sx.dtsi | 19 +++-
>  drivers/pci/controller/dwc/pci-imx6.c | 48 +++
>  drivers/soc/imx/gpc.c |  2 +-
>  4 files changed, 70 insertions(+), 3 deletions(-)

As agreed with Shawn, I have applied patches 2-3 to pci/dwc for v4.21,
thanks.

Lorenzo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/4] PCI: imx: Add multi-pd support

[Lorenzo Pieralisi]

On Mon, Oct 08, 2018 at 06:06:21PM +, Leonard Crestez wrote:
> On some chips the PCIE and PCIE_PHY blocks are in separate power domains
> which can be power-gated independently. The pci driver needs to handle
> this by keeping both domain active.
> 
> This is intended for imx6sx where PCIE is in DISPLAY and PCIE_PHY in
> it's own domain. Defining the DISPLAY domain requires a way for pcie to
> keep it active or it will break when displays are off.
> 
> The power-domains on imx6sx are meant to look like this:
>   power-domains = <_disp>, <_pci>;
>   power-domain-names = "pcie", "pcie_phy";
> 
> Signed-off-by: Leonard Crestez 
> Reviewed-by: Ulf Hansson 
> ---
>  drivers/pci/controller/dwc/pci-imx6.c | 48 +++
>  1 file changed, 48 insertions(+)

I expect Shawn to pick the whole series up and therefore I am dropping
this series from the PCI tree.

Acked-by: Lorenzo Pieralisi 

> diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
> b/drivers/pci/controller/dwc/pci-imx6.c
> index 6171171db1fc..a482f86b02e6 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -25,10 +25,12 @@
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include "pcie-designware.h"
>  
>  #define to_imx6_pcie(x)  dev_get_drvdata((x)->dev)
>  
> @@ -57,10 +59,15 @@ struct imx6_pcie {
>   u32 tx_deemph_gen2_6db;
>   u32 tx_swing_full;
>   u32 tx_swing_low;
>   int link_gen;
>   struct regulator*vpcie;
> +
> + /* power domain for pcie */
> + struct device   *pd_pcie;
> + /* power domain for pcie phy */
> + struct device   *pd_pcie_phy;
>  };
>  
>  /* Parameters for the waiting for PCIe PHY PLL to lock on i.MX7 */
>  #define PHY_PLL_LOCK_WAIT_MAX_RETRIES2000
>  #define PHY_PLL_LOCK_WAIT_USLEEP_MIN 50
> @@ -290,10 +297,47 @@ static int imx6q_pcie_abort_handler(unsigned long addr,
>   }
>  
>   return 1;
>  }
>  
> +static int imx6_pcie_attach_pd(struct device *dev)
> +{
> + struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
> + struct device_link *link;
> +
> + /* Do nothing when in a single power domain */
> + if (dev->pm_domain)
> + return 0;
> +
> + imx6_pcie->pd_pcie = dev_pm_domain_attach_by_name(dev, "pcie");
> + if (IS_ERR(imx6_pcie->pd_pcie))
> + return PTR_ERR(imx6_pcie->pd_pcie);
> + link = device_link_add(dev, imx6_pcie->pd_pcie,
> + DL_FLAG_STATELESS |
> + DL_FLAG_PM_RUNTIME |
> + DL_FLAG_RPM_ACTIVE);
> + if (IS_ERR(link)) {
> + dev_err(dev, "Failed to add device_link to pcie pd: %ld\n", 
> PTR_ERR(link));
> + return PTR_ERR(link);
> + }
> +
> + imx6_pcie->pd_pcie_phy = dev_pm_domain_attach_by_name(dev, "pcie_phy");
> + if (IS_ERR(imx6_pcie->pd_pcie_phy))
> + return PTR_ERR(imx6_pcie->pd_pcie_phy);
> +
> + device_link_add(dev, imx6_pcie->pd_pcie_phy,
> + DL_FLAG_STATELESS |
> + DL_FLAG_PM_RUNTIME |
> + DL_FLAG_RPM_ACTIVE);
> + if (IS_ERR(link)) {
> + dev_err(dev, "Failed to add device_link to pcie_phy pd: %ld\n", 
> PTR_ERR(link));
> + return PTR_ERR(link);
> + }
> +
> + return 0;
> +}
> +
>  static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
>  {
>   struct device *dev = imx6_pcie->pci->dev;
>  
>   switch (imx6_pcie->variant) {
> @@ -1013,10 +1057,14 @@ static int imx6_pcie_probe(struct platform_device 
> *pdev)
>   imx6_pcie->vpcie = NULL;
>   }
>  
>   platform_set_drvdata(pdev, imx6_pcie);
>  
> + ret = imx6_pcie_attach_pd(dev);
> + if (ret)
> + return ret;
> +
>   ret = imx6_add_pcie_port(imx6_pcie, pdev);
>   if (ret < 0)
>   return ret;
>  
>   return 0;
> -- 
> 2.17.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/4] ARM: dts: imx6sx: Add DISPLAY power domain support

[Lorenzo Pieralisi]

On Wed, Oct 31, 2018 at 12:17:50PM +, Leonard Crestez wrote:
> On 10/31/2018 8:12 AM, Shawn Guo wrote:
> > On Mon, Oct 08, 2018 at 06:06:23PM +, Leonard Crestez wrote:
> >> This was implemented in the driver but not actually defined and
> >> referenced in dts. This makes it always on.
> >>
> >>  From reference manual in section "10.4.1.4.1 Power Distribution":
> >>
> >> "Display domain - The DISPLAY domain contains GIS, CSI, PXP, LCDIF,
> >> PCIe, DCIC, and LDB. It is supplied by internal regulator."
> >>
> >> The current pd_pcie is actually only for PCIE_PHY, the PCIE ip block is
> >> actually inside the DISPLAY domain. Handle this by adding the pcie node
> >> in both power domains.
> >>
> >> Signed-off-by: Leonard Crestez 
> > 
> > Applied, thanks.
> 
> As mentioned in the cover letter this requires multi-PD support in 
> imx-pci to be implemented, specifically PATCH 3/4 of this series:
> 
>   https://lore.kernel.org/patchwork/patch/996810/
> 
> Unless that also gets merged soon via pci I expect issues in linux-next. 

I do not know what you mean by "issues in linux-next" (I assume you mean
when Shawn sends the patches to linux-next in preparation for v4.21); we
have not planned any other PCI pull request for v4.20-rc1 material.

> The patch already has reviewed-by tags so "merging it soon" is not 
> unreasonable.

I can ACK it if Shawn wants to pull it, it may take a while to see it
in -next if it has to go through the PCI tree, I think it is better
to queue the series without splitting the patches across multiple
channels though.

Lorenzo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter

[Lorenzo Pieralisi]

On Thu, Aug 17, 2017 at 09:30:28PM +1000, Daniel Axtens wrote:
> A system without PCI legacy resources (e.g. ARM64) may find that no
> default/boot VGA device has been marked, because the VGA arbiter
> checks for legacy resource decoding before marking a card as default.

I do not understand this paragraph, in particular:

- "A system without PCI legacy resources (e.g. ARM64)". What does this
  mean ? I take this as "ARM64 does not support IO space"; if a PCI host
  bridge supports IO space, there is nothing from an architectural
  point of view that prevents an MMIO based IO space implementation to
  work on ARM64. It is PCI bridge specific, not arch specific.
- "the VGA arbiter checks for legacy resources". Do you mean it checks
  if a VGA class device enabled IO/MEM address spaces (and if the
  bridges upstream forwards those address spaces), correct ?

The assumption relying on ARM64 not supporting IO space (if that's what
you mean by "a system without PCI legacy resources") is not correct.

Thanks,
Lorenzo

> Split the small bit of code that does default VGA handling out from
> the arbiter. Add a Kconfig option to allow the kernel to be built
> with just the default handling, or the arbiter and default handling.
> 
> Add handling for devices that should be marked as default but aren't
> handled by the vga arbiter by adding a late initcall and a class
> enable hook. If there is no default from vgaarb then the first card
> that is enabled, has a driver bound, and can decode memory or I/O
> will be marked as default.
> 
> Signed-off-by: Daniel Axtens 
> 
> ---
> 
> v2: Tested on:
>  - x86_64 laptop
>  - arm64 D05 board with hibmc card
>  - qemu powerpc with tcg and bochs std-vga
> 
> I know this adds another config option and that's a bit sad, but
> we can't include it unconditionally as it depends on PCI.
> Suggestions welcome.
> ---
>  arch/ia64/pci/fixup.c|   2 +-
>  arch/powerpc/kernel/pci-common.c |   2 +-
>  arch/x86/pci/fixup.c |   2 +-
>  arch/x86/video/fbdev.c   |   2 +-
>  drivers/gpu/vga/Kconfig  |  12 +++
>  drivers/gpu/vga/Makefile |   1 +
>  drivers/gpu/vga/vga_default.c| 159 
> +++
>  drivers/gpu/vga/vga_switcheroo.c |   2 +-
>  drivers/gpu/vga/vgaarb.c |  41 +-
>  drivers/pci/pci-sysfs.c  |   2 +-
>  include/linux/vga_default.h  |  44 +++
>  include/linux/vgaarb.h   |  14 
>  12 files changed, 225 insertions(+), 58 deletions(-)
>  create mode 100644 drivers/gpu/vga/vga_default.c
>  create mode 100644 include/linux/vga_default.h
> 
> diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
> index 41caa99add51..b35d1cf4501a 100644
> --- a/arch/ia64/pci/fixup.c
> +++ b/arch/ia64/pci/fixup.c
> @@ -5,7 +5,7 @@
>  
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  
>  #include 
> diff --git a/arch/powerpc/kernel/pci-common.c 
> b/arch/powerpc/kernel/pci-common.c
> index 341a7469cab8..4fd890a51d18 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -31,7 +31,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #include 
>  #include 
> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> index 11e407489db0..b1254bc09a45 100644
> --- a/arch/x86/pci/fixup.c
> +++ b/arch/x86/pci/fixup.c
> @@ -5,7 +5,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/arch/x86/video/fbdev.c b/arch/x86/video/fbdev.c
> index 9fd24846d094..62cfa74ea86e 100644
> --- a/arch/x86/video/fbdev.c
> +++ b/arch/x86/video/fbdev.c
> @@ -9,7 +9,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  int fb_is_primary_device(struct fb_info *info)
>  {
> diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig
> index 29437eabe095..81d4105aecf6 100644
> --- a/drivers/gpu/vga/Kconfig
> +++ b/drivers/gpu/vga/Kconfig
> @@ -1,3 +1,14 @@
> +config VGA_DEFAULT
> + bool "VGA Default Device Support" if EXPERT
> + default y
> + depends on PCI
> + help
> +   Some programs find it helpful to know what VGA device is the default.
> +   On platforms like x86 this means the device used by the BIOS to show
> +   early boot messages. On other platforms this may be an arbitrary PCI
> +   graphics card. Select this to have a default device recorded within
> +   the kernel and exposed to userspace through sysfs.
> +
>  config VGA_ARB
>   bool "VGA Arbitration" if EXPERT
>   default y
> @@ -22,6 +33,7 @@ config VGA_SWITCHEROO
>   depends on X86
>   depends on ACPI
>   select VGA_ARB
> + select VGA_DEFAULT
>   help
> Many laptops released in 2008/9/10 have two GPUs with a multiplexer
> to switch between them. This adds support for dynamic switching when
> diff --git a/drivers/gpu/vga/Makefile b/drivers/gpu/vga/Makefile
> index