[PATCH V2 1/4] EFI: Stash ROMs if they're not in the PCI BAR

[PATCH V2 1/4] EFI: Stash ROMs if they're not in the PCI BAR

[Matthew Garrett]

EFI provides support for providing PCI ROMs via means other than the ROM
BAR. This support vanishes after we've exited boot services, so add support
for stashing copies of the ROMs in setup_data if they're not otherwise
available.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Tested-by: Seth Forshee <seth.forshee@canonical.com>
---
 arch/x86/boot/compressed/eboot.c |  118 ++++++++++++++++++++++++++++++++++++++
 arch/x86/include/asm/bootparam.h |    1 +
 arch/x86/include/asm/pci.h       |   12 ++++
 include/linux/efi.h              |   71 +++++++++++++++++++++++
 4 files changed, 202 insertions(+)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index d5e4044..ea674a7 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -8,6 +8,7 @@
  * ----------------------------------------------------------------------- */
 
 #include <linux/efi.h>
+#include <linux/pci.h>
 #include <asm/efi.h>
 #include <asm/setup.h>
 #include <asm/desc.h>
@@ -243,6 +244,121 @@ static void find_bits(unsigned long mask, u8 *pos, u8 *size)
 	*size = len;
 }
 
+static efi_status_t setup_efi_pci(struct boot_params *params)
+{
+	efi_pci_io_protocol *pci;
+	efi_status_t status;
+	void **pci_handle;
+	efi_guid_t pci_proto = EFI_PCI_IO_PROTOCOL_GUID;
+	unsigned long nr_pci, size = 0;
+	int i;
+	struct setup_data *data;
+
+	data = (struct setup_data *)params->hdr.setup_data;
+
+	while (data && data->next)
+		data = (struct setup_data *)data->next;
+
+	status = efi_call_phys5(sys_table->boottime->locate_handle,
+				EFI_LOCATE_BY_PROTOCOL, &pci_proto,
+				NULL, &size, pci_handle);
+
+	if (status == EFI_BUFFER_TOO_SMALL) {
+		status = efi_call_phys3(sys_table->boottime->allocate_pool,
+					EFI_LOADER_DATA, size, &pci_handle);
+
+		if (status != EFI_SUCCESS)
+			return status;
+
+		status = efi_call_phys5(sys_table->boottime->locate_handle,
+					EFI_LOCATE_BY_PROTOCOL, &pci_proto,
+					NULL, &size, pci_handle);
+	}
+
+	if (status != EFI_SUCCESS)
+		goto free_handle;
+
+	nr_pci = size / sizeof(void *);
+	for (i = 0; i < nr_pci; i++) {
+		void *h = pci_handle[i];
+		uint64_t attributes;
+		struct pci_setup_rom *rom;
+
+		status = efi_call_phys3(sys_table->boottime->handle_protocol,
+					h, &pci_proto, &pci);
+
+		if (status != EFI_SUCCESS)
+			continue;
+
+		if (!pci)
+			continue;
+
+		status = efi_call_phys4(pci->attributes, pci,
+					EfiPciIoAttributeOperationGet, 0,
+					&attributes);
+
+		if (status != EFI_SUCCESS)
+			continue;
+
+		if (!attributes & EFI_PCI_IO_ATTRIBUTE_EMBEDDED_ROM)
+			continue;
+
+		if (!pci->romimage || !pci->romsize)
+			continue;
+
+		size = pci->romsize + sizeof(*rom);
+
+		status = efi_call_phys3(sys_table->boottime->allocate_pool,
+				EFI_LOADER_DATA, size, &rom);
+
+		if (status != EFI_SUCCESS)
+			continue;
+
+		rom->data.type = SETUP_PCI;
+		rom->data.len = size - sizeof(struct setup_data);
+		rom->data.next = 0;
+		rom->pcilen = pci->romsize;
+
+		status = efi_call_phys5(pci->pci.read, pci,
+					EfiPciIoWidthUint16, PCI_VENDOR_ID,
+					1, &(rom->vendor));
+
+		if (status != EFI_SUCCESS)
+			goto free_struct;
+
+		status = efi_call_phys5(pci->pci.read, pci,
+					EfiPciIoWidthUint16, PCI_DEVICE_ID,
+					1, &(rom->devid));
+
+		if (status != EFI_SUCCESS)
+			goto free_struct;
+
+		status = efi_call_phys5(pci->get_location, pci,
+					&(rom->segment), &(rom->bus),
+					&(rom->device), &(rom->function));
+
+		if (status != EFI_SUCCESS)
+			goto free_struct;
+
+		memcpy(rom->romdata, pci->romimage, pci->romsize);
+
+		if (data)
+			data->next = (uint64_t)rom;
+		else
+			params->hdr.setup_data = (uint64_t)rom;
+
+		data = (struct setup_data *)rom;
+
+		continue;
+free_struct:
+		efi_call_phys1(sys_table->boottime->free_pool, rom);
+	}
+
+free_handle:
+	efi_call_phys1(sys_table->boottime->free_pool, pci_handle);
+	return status;
+}
+
 /*
  * See if we have Graphics Output Protocol
  */
@@ -1023,6 +1139,8 @@ struct boot_params *efi_main(void *handle, efi_system_table_t *_table,
 
 	setup_graphics(boot_params);
 
+	setup_efi_pci(boot_params);
+
 	status = efi_call_phys3(sys_table->boottime->allocate_pool,
 				EFI_LOADER_DATA, sizeof(*gdt),
 				(void **)&gdt);
diff --git a/arch/x86/include/asm/bootparam.h b/arch/x86/include/asm/bootparam.h
index 2ad874c..92862cd 100644
--- a/arch/x86/include/asm/bootparam.h
+++ b/arch/x86/include/asm/bootparam.h
@@ -13,6 +13,7 @@
 #define SETUP_NONE			0
 #define SETUP_E820_EXT			1
 #define SETUP_DTB			2
+#define SETUP_PCI			3
 
 /* extensible setup data list node */
 struct setup_data {
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index df75d07..11491d1 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -171,4 +171,16 @@ cpumask_of_pcibus(const struct pci_bus *bus)
 }
 #endif
 
+struct pci_setup_rom {
+	struct setup_data data;
+	uint16_t vendor;
+	uint16_t devid;
+	uint64_t pcilen;
+	unsigned long segment;
+	unsigned long bus;
+	unsigned long device;
+	unsigned long function;
+	uint8_t romdata[0];
+};
+
 #endif /* _ASM_X86_PCI_H */
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 103adc6..e4be085 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -196,6 +196,77 @@ typedef struct {
 	void *create_event_ex;
 } efi_boot_services_t;
 
+typedef enum {
+	EfiPciIoWidthUint8,
+	EfiPciIoWidthUint16,
+	EfiPciIoWidthUint32,
+	EfiPciIoWidthUint64,
+	EfiPciIoWidthFifoUint8,
+	EfiPciIoWidthFifoUint16,
+	EfiPciIoWidthFifoUint32,
+	EfiPciIoWidthFifoUint64,
+	EfiPciIoWidthFillUint8,
+	EfiPciIoWidthFillUint16,
+	EfiPciIoWidthFillUint32,
+	EfiPciIoWidthFillUint64,
+	EfiPciIoWidthMaximum
+} EFI_PCI_IO_PROTOCOL_WIDTH;
+
+typedef enum {
+	EfiPciIoAttributeOperationGet,
+	EfiPciIoAttributeOperationSet,
+	EfiPciIoAttributeOperationEnable,
+	EfiPciIoAttributeOperationDisable,
+	EfiPciIoAttributeOperationSupported,
+	EfiPciIoAttributeOperationMaximum
+} EFI_PCI_IO_PROTOCOL_ATTRIBUTE_OPERATION;
+
+
+typedef struct {
+	void *read;
+	void *write;
+} efi_pci_io_protocol_access_t;
+
+typedef struct {
+	void *poll_mem;
+	void *poll_io;
+	efi_pci_io_protocol_access_t mem;
+	efi_pci_io_protocol_access_t io;
+	efi_pci_io_protocol_access_t pci;
+	void *copy_mem;
+	void *map;
+	void *unmap;
+	void *allocate_buffer;
+	void *free_buffer;
+	void *flush;
+	void *get_location;
+	void *attributes;
+	void *get_bar_attributes;
+	void *set_bar_attributes;
+	uint64_t romsize;
+	void *romimage;
+} efi_pci_io_protocol;
+
+#define EFI_PCI_IO_ATTRIBUTE_ISA_MOTHERBOARD_IO 0x0001
+#define EFI_PCI_IO_ATTRIBUTE_ISA_IO 0x0002
+#define EFI_PCI_IO_ATTRIBUTE_VGA_PALETTE_IO 0x0004
+#define EFI_PCI_IO_ATTRIBUTE_VGA_MEMORY 0x0008
+#define EFI_PCI_IO_ATTRIBUTE_VGA_IO 0x0010
+#define EFI_PCI_IO_ATTRIBUTE_IDE_PRIMARY_IO 0x0020
+#define EFI_PCI_IO_ATTRIBUTE_IDE_SECONDARY_IO 0x0040
+#define EFI_PCI_IO_ATTRIBUTE_MEMORY_WRITE_COMBINE 0x0080
+#define EFI_PCI_IO_ATTRIBUTE_IO 0x0100
+#define EFI_PCI_IO_ATTRIBUTE_MEMORY 0x0200
+#define EFI_PCI_IO_ATTRIBUTE_BUS_MASTER 0x0400
+#define EFI_PCI_IO_ATTRIBUTE_MEMORY_CACHED 0x0800
+#define EFI_PCI_IO_ATTRIBUTE_MEMORY_DISABLE 0x1000
+#define EFI_PCI_IO_ATTRIBUTE_EMBEDDED_DEVICE 0x2000
+#define EFI_PCI_IO_ATTRIBUTE_EMBEDDED_ROM 0x4000
+#define EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE 0x8000
+#define EFI_PCI_IO_ATTRIBUTE_ISA_IO_16 0x10000
+#define EFI_PCI_IO_ATTRIBUTE_VGA_PALETTE_IO_16 0x20000
+#define EFI_PCI_IO_ATTRIBUTE_VGA_IO_16 0x40000
+
 /*
  * Types and defines for EFI ResetSystem
  */
-- 
1.7.10.4

[PATCH V2 2/4] PCI: Add pcibios_add_device

[Matthew Garrett]

Platforms may want to provide architecture-specific functionality during
PCI enumeration. Add a pcibios_add_device() call that architectures can
override to do so.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Tested-by: Seth Forshee <seth.forshee@canonical.com>
---
 drivers/pci/bus.c   |    5 +++++
 drivers/pci/pci.c   |   13 +++++++++++++
 include/linux/pci.h |    1 +
 3 files changed, 19 insertions(+)

diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 4b0970b..e2f447e 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -166,6 +166,11 @@ int pci_bus_add_device(struct pci_dev *dev)
 	int retval;
 
 	pci_fixup_device(pci_fixup_final, dev);
+
+	retval = pcibios_add_device(dev);
+	if (retval)
+		return retval;
+
 	retval = device_add(&dev->dev);
 	if (retval)
 		return retval;
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index f3ea977..fec3a92 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1385,6 +1385,19 @@ void pcim_pin_device(struct pci_dev *pdev)
 		dr->pinned = 1;
 }
 
+/*
+ * pcibios_add_device - provide arch specific hooks when adding device dev
+ * @dev: the PCI device being added
+ *
+ * Permits the platform to provide architecture specific functionality when
+ * devices are added. This is the default implementation. Architecture
+ * implementations can override this.
+ */
+int __weak pcibios_add_device(struct pci_dev *dev)
+{
+	return 0;
+}
+
 /**
  * pcibios_disable_device - disable arch specific PCI resources for device dev
  * @dev: the PCI device to disable
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 5faa831..6a2625c 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1582,6 +1582,7 @@ void pcibios_disable_device(struct pci_dev *dev);
 void pcibios_set_master(struct pci_dev *dev);
 int pcibios_set_pcie_reset_state(struct pci_dev *dev,
 				 enum pcie_reset_state state);
+int pcibios_add_device(struct pci_dev *dev);
 
 #ifdef CONFIG_PCI_MMCONFIG
 extern void __init pci_mmcfg_early_init(void);
-- 
1.7.10.4

[PATCH V2 3/4] PCI: Add support for non-BAR ROMs

[Matthew Garrett]

Platforms may provide their own mechanisms for obtaining ROMs. Add support
for using data provided by the platform in that case.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Tested-by: Seth Forshee <seth.forshee@canonical.com>
---
 drivers/pci/rom.c   |    9 ++++++++-
 include/linux/pci.h |    2 ++
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
index 48ebdb2..f913ce3 100644
--- a/drivers/pci/rom.c
+++ b/drivers/pci/rom.c
@@ -126,6 +126,12 @@ void __iomem *pci_map_rom(struct pci_dev *pdev, size_t *size)
 		/* primary video rom always starts here */
 		start = (loff_t)0xC0000;
 		*size = 0x20000; /* cover C000:0 through E000:0 */
+	/*
+	 * Some devices may provide ROMs via a source other than the BAR
+	 */
+	} else if (pdev->rom && pdev->romlen) {
+		*size = pdev->romlen;
+		return (void __iomem *)phys_to_virt(pdev->rom);
 	} else {
 		if (res->flags &
 			(IORESOURCE_ROM_COPY | IORESOURCE_ROM_BIOS_COPY)) {
@@ -219,7 +225,8 @@ void pci_unmap_rom(struct pci_dev *pdev, void __iomem *rom)
 	if (res->flags & (IORESOURCE_ROM_COPY | IORESOURCE_ROM_BIOS_COPY))
 		return;
 
-	iounmap(rom);
+	if (!pdev->rom || !pdev->romlen)
+		iounmap(rom);
 
 	/* Disable again before continuing, leave enabled if pci=rom */
 	if (!(res->flags & (IORESOURCE_ROM_ENABLE | IORESOURCE_ROM_SHADOW)))
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 6a2625c..2668bb9 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -355,6 +355,8 @@ struct pci_dev {
 	};
 	struct pci_ats	*ats;	/* Address Translation Service */
 #endif
+	void *rom; /* Physical pointer to ROM if it's not from the BAR */
+	size_t romlen; /* Length of ROM if it's not from the BAR */
 };
 
 static inline struct pci_dev *pci_physfn(struct pci_dev *dev)
-- 
1.7.10.4

[PATCH V2 4/4] X86: Use PCI setup data

[Matthew Garrett]

EFI can provide PCI ROMs out of band via boot services, which may not be
available after boot. Add support for using the data handed off to us by
the boot stub or bootloader.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Tested-by: Seth Forshee <seth.forshee@canonical.com>
---
 arch/x86/pci/common.c |   33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 720e973f..3d2752f 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -17,6 +17,7 @@
 #include <asm/io.h>
 #include <asm/smp.h>
 #include <asm/pci_x86.h>
+#include <asm/setup.h>
 
 unsigned int pci_probe = PCI_PROBE_BIOS | PCI_PROBE_CONF1 | PCI_PROBE_CONF2 |
 				PCI_PROBE_MMCONF;
@@ -608,6 +609,38 @@ unsigned int pcibios_assign_all_busses(void)
 	return (pci_probe & PCI_ASSIGN_ALL_BUSSES) ? 1 : 0;
 }
 
+int pcibios_add_device(struct pci_dev *dev)
+{
+	struct setup_data *data;
+	struct pci_setup_rom *rom;
+	u64 pa_data;
+
+	if (boot_params.hdr.version < 0x0209)
+		return 0;
+
+	pa_data = boot_params.hdr.setup_data;
+	while (pa_data) {
+		data = phys_to_virt(pa_data);
+
+		if (data->type == SETUP_PCI) {
+			rom = (struct pci_setup_rom *)data;
+
+			if ((pci_domain_nr(dev->bus) == rom->segment) &&
+			    (dev->bus->number == rom->bus) &&
+			    (PCI_SLOT(dev->devfn) == rom->device) &&
+			    (PCI_FUNC(dev->devfn) == rom->function) &&
+			    (dev->vendor == rom->vendor) &&
+			    (dev->device == rom->devid)) {
+				dev->rom = (void *)(pa_data +
+				      offsetof(struct pci_setup_rom, romdata));
+				dev->romlen = rom->pcilen;
+			}
+		}
+		pa_data = data->next;
+	}
+	return 0;
+}
+
 int pcibios_enable_device(struct pci_dev *dev, int mask)
 {
 	int err;
-- 
1.7.10.4

[PATCH] Fix priority of non-BAR ROM data

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]

If we've obtained the ROM data through other means (such as from EFI),
we don't want to ignore it just because the IORESOURCE_ROM_SHADOW bit has
got set. This fixes the Radeon ROM handling on my MacBookPro8,3 when booted
via grub1-efi.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
---
This fixes patch 3/4 'PCI: Add support for non-BAR ROMs' for me.

 drivers/pci/rom.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
index 7ebaab6..4d437b5 100644
--- a/drivers/pci/rom.c
+++ b/drivers/pci/rom.c
@@ -118,6 +118,13 @@ void __iomem *pci_map_rom(struct pci_dev *pdev, size_t *size)
 	void __iomem *rom;
 
 	/*
+	 * Some devices may provide ROMs via a source other than the BAR
+	 */
+	if (pdev->rom && pdev->romlen) {
+		*size = pdev->romlen;
+		return phys_to_virt(pdev->rom);
+	}
+	/*
 	 * IORESOURCE_ROM_SHADOW set on x86, x86_64 and IA64 supports legacy
 	 * memory map if the VGA enable bit of the Bridge Control register is
 	 * set for embedded VGA.
@@ -126,12 +133,6 @@ void __iomem *pci_map_rom(struct pci_dev *pdev, size_t *size)
 		/* primary video rom always starts here */
 		start = (loff_t)0xC0000;
 		*size = 0x20000; /* cover C000:0 through E000:0 */
-	/*
-	 * Some devices may provide ROMs via a source other than the BAR
-	 */
-	} else if (pdev->rom && pdev->romlen) {
-		*size = pdev->romlen;
-		return phys_to_virt(pdev->rom);
 	} else {
 		if (res->flags &
 			(IORESOURCE_ROM_COPY | IORESOURCE_ROM_BIOS_COPY)) {
-- 
1.7.11.2



-- 
dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]

Re: [PATCH] Fix priority of non-BAR ROM data

[Matthew Garrett]

On Sun, Jul 29, 2012 at 10:49:42PM +0100, David Woodhouse wrote:
> +	 * Some devices may provide ROMs via a source other than the BAR
> +	 */
> +	if (pdev->rom && pdev->romlen) {
> +		*size = pdev->romlen;
> +		return phys_to_virt(pdev->rom);

Needs casting. My mistake.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH V2 1/4] EFI: Stash ROMs if they're not in the PCI BAR

[Greg KH]

On Fri, Jul 27, 2012 at 12:52:11PM -0400, Matthew Garrett wrote:
> EFI provides support for providing PCI ROMs via means other than the ROM
> BAR. This support vanishes after we've exited boot services, so add support
> for stashing copies of the ROMs in setup_data if they're not otherwise
> available.
> 
> Signed-off-by: Matthew Garrett <mjg@redhat.com>
> Tested-by: Seth Forshee <seth.forshee@canonical.com>
> ---
>  arch/x86/boot/compressed/eboot.c |  118 ++++++++++++++++++++++++++++++++++++++
>  arch/x86/include/asm/bootparam.h |    1 +
>  arch/x86/include/asm/pci.h       |   12 ++++
>  include/linux/efi.h              |   71 +++++++++++++++++++++++
>  4 files changed, 202 insertions(+)

With this series, does the latest MacBook work properly for the Intel
graphics driver?  Or is this to resolve some other hardware issue?

thanks,

greg k-h

Re: [PATCH] Fix priority of non-BAR ROM data

[Bjorn Helgaas]

On Sun, Jul 29, 2012 at 3:53 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Sun, Jul 29, 2012 at 10:49:42PM +0100, David Woodhouse wrote:
>> +      * Some devices may provide ROMs via a source other than the BAR
>> +      */
>> +     if (pdev->rom && pdev->romlen) {
>> +             *size = pdev->romlen;
>> +             return phys_to_virt(pdev->rom);
>
> Needs casting. My mistake.

Matthew, are you going to fold this into your patch and repost your
series, or is this a logically separate issue?

Re: [PATCH] Fix priority of non-BAR ROM data

[Matthew Garrett]

On Wed, Aug 01, 2012 at 08:20:15AM -0600, Bjorn Helgaas wrote:
> On Sun, Jul 29, 2012 at 3:53 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > On Sun, Jul 29, 2012 at 10:49:42PM +0100, David Woodhouse wrote:
> >> +      * Some devices may provide ROMs via a source other than the BAR
> >> +      */
> >> +     if (pdev->rom && pdev->romlen) {
> >> +             *size = pdev->romlen;
> >> +             return phys_to_virt(pdev->rom);
> >
> > Needs casting. My mistake.
> 
> Matthew, are you going to fold this into your patch and repost your
> series, or is this a logically separate issue?

I can fold it in.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH V2 1/4] EFI: Stash ROMs if they're not in the PCI BAR

[Matthew Garrett]

On Tue, Jul 31, 2012 at 03:32:40PM -0700, Greg KH wrote:

> With this series, does the latest MacBook work properly for the Intel
> graphics driver?  Or is this to resolve some other hardware issue?

Apple only seem to provide the ROM for the radeon. Intel normally 
stands a much better chance of working without a ROM - the only thing it 
really uses it for is the VBT, and I'm thinking about a couple of ways 
of handlng that.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH V2 1/4] EFI: Stash ROMs if they're not in the PCI BAR

[Greg KH]

On Wed, Aug 01, 2012 at 05:54:00PM +0100, Matthew Garrett wrote:
> On Tue, Jul 31, 2012 at 03:32:40PM -0700, Greg KH wrote:
> 
> > With this series, does the latest MacBook work properly for the Intel
> > graphics driver?  Or is this to resolve some other hardware issue?
> 
> Apple only seem to provide the ROM for the radeon. Intel normally 
> stands a much better chance of working without a ROM - the only thing it 
> really uses it for is the VBT, and I'm thinking about a couple of ways 
> of handlng that.

Ok, thanks for letting me know.  For some reason, the gmux isn't working
on the latest MacBook Pro so I can't get the vga switched to the Intel
PCI device.  Rumor has it the osx tool at
http://codykrieger.com/gfxCardStatus will switch into the Intel chip
until the laptop is hard powered off, so it is possible, just need to
figure out how to make the hardware do the switch...

greg k-h

Re: [PATCH V2 1/4] EFI: Stash ROMs if they're not in the PCI BAR

[Seth Forshee]

On Wed, Aug 01, 2012 at 04:21:47PM -0700, Greg KH wrote:
> On Wed, Aug 01, 2012 at 05:54:00PM +0100, Matthew Garrett wrote:
> > On Tue, Jul 31, 2012 at 03:32:40PM -0700, Greg KH wrote:
> > 
> > > With this series, does the latest MacBook work properly for the Intel
> > > graphics driver?  Or is this to resolve some other hardware issue?
> > 
> > Apple only seem to provide the ROM for the radeon. Intel normally 
> > stands a much better chance of working without a ROM - the only thing it 
> > really uses it for is the VBT, and I'm thinking about a couple of ways 
> > of handlng that.
> 
> Ok, thanks for letting me know.  For some reason, the gmux isn't working
> on the latest MacBook Pro so I can't get the vga switched to the Intel
> PCI device.  Rumor has it the osx tool at
> http://codykrieger.com/gfxCardStatus will switch into the Intel chip
> until the laptop is hard powered off, so it is possible, just need to
> figure out how to make the hardware do the switch...

There's a tool that enables some verbose logging which records all the
I/O to the gmux. It works for me with a Macbook Pro 8,2 running OS X
Lion, so you might give it a try.

All you need to do is clone https://github.com/ah-/switcher.git, build,
and run switcher. If it works you'll see messages prefixed with AGC in
dmesg. Then you can use gfxCardStatus to force some switches between the
integrated and discrete cards. After that you'll want to grab
/var/log/kern.log to get the full logs of everything that happened.

If you try this and it works, I'd appreciate it if you could send me a
copy of kern.log so I can apply the information towards getting graphics
switching into apple-gmux.

Seth

Re: [PATCH V2 1/4] EFI: Stash ROMs if they're not in the PCI BAR

[Greg KH]

On Wed, Aug 01, 2012 at 11:02:42PM -0500, Seth Forshee wrote:
> On Wed, Aug 01, 2012 at 04:21:47PM -0700, Greg KH wrote:
> > On Wed, Aug 01, 2012 at 05:54:00PM +0100, Matthew Garrett wrote:
> > > On Tue, Jul 31, 2012 at 03:32:40PM -0700, Greg KH wrote:
> > > 
> > > > With this series, does the latest MacBook work properly for the Intel
> > > > graphics driver?  Or is this to resolve some other hardware issue?
> > > 
> > > Apple only seem to provide the ROM for the radeon. Intel normally 
> > > stands a much better chance of working without a ROM - the only thing it 
> > > really uses it for is the VBT, and I'm thinking about a couple of ways 
> > > of handlng that.
> > 
> > Ok, thanks for letting me know.  For some reason, the gmux isn't working
> > on the latest MacBook Pro so I can't get the vga switched to the Intel
> > PCI device.  Rumor has it the osx tool at
> > http://codykrieger.com/gfxCardStatus will switch into the Intel chip
> > until the laptop is hard powered off, so it is possible, just need to
> > figure out how to make the hardware do the switch...
> 
> There's a tool that enables some verbose logging which records all the
> I/O to the gmux. It works for me with a Macbook Pro 8,2 running OS X
> Lion, so you might give it a try.
> 
> All you need to do is clone https://github.com/ah-/switcher.git, build,
> and run switcher. If it works you'll see messages prefixed with AGC in
> dmesg. Then you can use gfxCardStatus to force some switches between the
> integrated and discrete cards. After that you'll want to grab
> /var/log/kern.log to get the full logs of everything that happened.
> 
> If you try this and it works, I'd appreciate it if you could send me a
> copy of kern.log so I can apply the information towards getting graphics
> switching into apple-gmux.

Francois, any chance you can ty this and let Seth know the results?  I
don't have OSX on my machine anymore to do this myself.

thanks,

greg k-h

Re: [PATCH V2 1/4] EFI: Stash ROMs if they're not in the PCI BAR

[Francois Rigaut]

Greg, Seth,

Here is what the message.log shows:

switching to the HD4000 (integrated):

Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: CGXMuxAcknowledge: Posting glitchless acknowledge
Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: MPAccessSurfaceForDisplayDevice: Set up page flip mode on display 0x042803c0 device: 0x10c678320  isBackBuffered: 0 numComp: 1 numDisp: 3
Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003d
Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003e
Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003f

switching to the nvidia (discrete):

Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003d
Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003e
Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003f
Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: CGXMuxAcknowledge: Posting glitchless acknowledge
Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: MPAccessSurfaceForDisplayDevice: Set up page flip mode on display 0x042803c0 device: 0x10c678320  isBackBuffered: 0 numComp: 1 numDisp: 3
Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0

Hope that helps.
Francois



On 02/08/12 20:34, Greg KH wrote:
> On Wed, Aug 01, 2012 at 11:02:42PM -0500, Seth Forshee wrote:
>> On Wed, Aug 01, 2012 at 04:21:47PM -0700, Greg KH wrote:
>>> On Wed, Aug 01, 2012 at 05:54:00PM +0100, Matthew Garrett wrote:
>>>> On Tue, Jul 31, 2012 at 03:32:40PM -0700, Greg KH wrote:
>>>>
>>>>> With this series, does the latest MacBook work properly for the Intel
>>>>> graphics driver?  Or is this to resolve some other hardware issue?
>>>> Apple only seem to provide the ROM for the radeon. Intel normally
>>>> stands a much better chance of working without a ROM - the only thing it
>>>> really uses it for is the VBT, and I'm thinking about a couple of ways
>>>> of handlng that.
>>> Ok, thanks for letting me know.  For some reason, the gmux isn't working
>>> on the latest MacBook Pro so I can't get the vga switched to the Intel
>>> PCI device.  Rumor has it the osx tool at
>>> http://codykrieger.com/gfxCardStatus will switch into the Intel chip
>>> until the laptop is hard powered off, so it is possible, just need to
>>> figure out how to make the hardware do the switch...
>> There's a tool that enables some verbose logging which records all the
>> I/O to the gmux. It works for me with a Macbook Pro 8,2 running OS X
>> Lion, so you might give it a try.
>>
>> All you need to do is clone https://github.com/ah-/switcher.git, build,
>> and run switcher. If it works you'll see messages prefixed with AGC in
>> dmesg. Then you can use gfxCardStatus to force some switches between the
>> integrated and discrete cards. After that you'll want to grab
>> /var/log/kern.log to get the full logs of everything that happened.
>>
>> If you try this and it works, I'd appreciate it if you could send me a
>> copy of kern.log so I can apply the information towards getting graphics
>> switching into apple-gmux.
> Francois, any chance you can ty this and let Seth know the results?  I
> don't have OSX on my machine anymore to do this myself.
>
> thanks,
>
> greg k-h

Re: [PATCH V2 1/4] EFI: Stash ROMs if they're not in the PCI BAR

[Seth Forshee]

On Fri, Aug 03, 2012 at 12:57:33AM +1000, Francois Rigaut wrote:
> Greg, Seth,
> 
> Here is what the message.log shows:
> 
> switching to the HD4000 (integrated):
> 
> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: CGXMuxAcknowledge: Posting glitchless acknowledge
> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: MPAccessSurfaceForDisplayDevice: Set up page flip mode on display 0x042803c0 device: 0x10c678320  isBackBuffered: 0 numComp: 1 numDisp: 3
> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003d
> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003e
> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003f
> 
> switching to the nvidia (discrete):
> 
> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003d
> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003e
> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003f
> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: CGXMuxAcknowledge: Posting glitchless acknowledge
> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: MPAccessSurfaceForDisplayDevice: Set up page flip mode on display 0x042803c0 device: 0x10c678320  isBackBuffered: 0 numComp: 1 numDisp: 3
> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
> 
> Hope that helps.

Thanks for trying it out, but it's not really what I was hoping for. I
get a bunch of messages similar to these in /var/log/kernel.log, mixed
in with a lot of other stuff.

 AGC:: setMuxRegister:1666 (728, 1, 1)
 AGC:: setMuxRegister:1666 (710, 1, 4)
 AGC:: getMuxRegister:1647 (716, 1) = 1

I don't even have message.log. You don't have a kernel.log? Do you see
any messages like those if you run dmesg?

Seth

Re: [PATCH V2 1/4] EFI: Stash ROMs if they're not in the PCI BAR

[Francois Rigaut]

Hi Seth,

Sorry for the belated response. On Oz time here.
I don't have a /var/log/kernel.log !
Let me make sure of something:
This switcher code is to be run on osx, no? That's where gfxcardstatus 
lives and where I can effect the card switch. Just to make sure.
So I'm running osx mountain lion, and the only thing I see in the logs 
when I switch cards (using gfxcardstatus) is what I pasted below. and 
you're right, it was not in message.log, but system.log (it was late). I 
just went through the whole thing again.
Am I missing something?
Cheers,
Francois

On 03/08/12 02:12, Seth Forshee wrote:
> On Fri, Aug 03, 2012 at 12:57:33AM +1000, Francois Rigaut wrote:
>> Greg, Seth,
>>
>> Here is what the message.log shows:
>>
>> switching to the HD4000 (integrated):
>>
>> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
>> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: CGXMuxAcknowledge: Posting glitchless acknowledge
>> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: MPAccessSurfaceForDisplayDevice: Set up page flip mode on display 0x042803c0 device: 0x10c678320  isBackBuffered: 0 numComp: 1 numDisp: 3
>> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
>> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003d
>> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003e
>> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003f
>>
>> switching to the nvidia (discrete):
>>
>> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
>> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003d
>> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003e
>> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003f
>> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: CGXMuxAcknowledge: Posting glitchless acknowledge
>> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: MPAccessSurfaceForDisplayDevice: Set up page flip mode on display 0x042803c0 device: 0x10c678320  isBackBuffered: 0 numComp: 1 numDisp: 3
>> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
>>
>> Hope that helps.
> Thanks for trying it out, but it's not really what I was hoping for. I
> get a bunch of messages similar to these in /var/log/kernel.log, mixed
> in with a lot of other stuff.
>
>   AGC:: setMuxRegister:1666 (728, 1, 1)
>   AGC:: setMuxRegister:1666 (710, 1, 4)
>   AGC:: getMuxRegister:1647 (716, 1) = 1
>
> I don't even have message.log. You don't have a kernel.log? Do you see
> any messages like those if you run dmesg?
>
> Seth

Re: [PATCH V2 1/4] EFI: Stash ROMs if they're not in the PCI BAR

[Francois Rigaut]

Seth,

I have put the osx system.log, which is the only file where I can see 
mux and AGC related message, at http://maumae.net/retina/system.log
Thanks,
Francois

On 03/08/12 08:40, Francois Rigaut wrote:
> Hi Seth,
>
> Sorry for the belated response. On Oz time here.
> I don't have a /var/log/kernel.log !
> Let me make sure of something:
> This switcher code is to be run on osx, no? That's where gfxcardstatus 
> lives and where I can effect the card switch. Just to make sure.
> So I'm running osx mountain lion, and the only thing I see in the logs 
> when I switch cards (using gfxcardstatus) is what I pasted below. and 
> you're right, it was not in message.log, but system.log (it was late). 
> I just went through the whole thing again.
> Am I missing something?
> Cheers,
> Francois
>
> On 03/08/12 02:12, Seth Forshee wrote:
>> On Fri, Aug 03, 2012 at 12:57:33AM +1000, Francois Rigaut wrote:
>>> Greg, Seth,
>>>
>>> Here is what the message.log shows:
>>>
>>> switching to the HD4000 (integrated):
>>>
>>> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received 
>>> display connect changed for display 0x42803c0
>>> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: 
>>> CGXMuxAcknowledge: Posting glitchless acknowledge
>>> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: 
>>> MPAccessSurfaceForDisplayDevice: Set up page flip mode on display 
>>> 0x042803c0 device: 0x10c678320  isBackBuffered: 0 numComp: 1 numDisp: 3
>>> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received 
>>> display connect changed for display 0x42803c0
>>> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received 
>>> display connect changed for display 0x3f003d
>>> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received 
>>> display connect changed for display 0x3f003e
>>> Aug  3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received 
>>> display connect changed for display 0x3f003f
>>>
>>> switching to the nvidia (discrete):
>>>
>>> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received 
>>> display connect changed for display 0x42803c0
>>> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received 
>>> display connect changed for display 0x3f003d
>>> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received 
>>> display connect changed for display 0x3f003e
>>> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received 
>>> display connect changed for display 0x3f003f
>>> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: 
>>> CGXMuxAcknowledge: Posting glitchless acknowledge
>>> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: 
>>> MPAccessSurfaceForDisplayDevice: Set up page flip mode on display 
>>> 0x042803c0 device: 0x10c678320  isBackBuffered: 0 numComp: 1 numDisp: 3
>>> Aug  3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received 
>>> display connect changed for display 0x42803c0
>>>
>>> Hope that helps.
>> Thanks for trying it out, but it's not really what I was hoping for. I
>> get a bunch of messages similar to these in /var/log/kernel.log, mixed
>> in with a lot of other stuff.
>>
>>   AGC:: setMuxRegister:1666 (728, 1, 1)
>>   AGC:: setMuxRegister:1666 (710, 1, 4)
>>   AGC:: getMuxRegister:1647 (716, 1) = 1
>>
>> I don't even have message.log. You don't have a kernel.log? Do you see
>> any messages like those if you run dmesg?
>>
>> Seth

Re: [PATCH V2 1/4] EFI: Stash ROMs if they're not in the PCI BAR

[Seth Forshee]

On Fri, Aug 03, 2012 at 08:54:46AM +1000, Francois Rigaut wrote:
> Seth,
> 
> I have put the osx system.log, which is the only file where I can
> see mux and AGC related message, at
> http://maumae.net/retina/system.log

That does seem to contain the kernel log messages, but unfortunately I'm
not seeing what I'm looking for there.

> Thanks,
> Francois
> 
> On 03/08/12 08:40, Francois Rigaut wrote:
> >Hi Seth,
> >
> >Sorry for the belated response. On Oz time here.
> >I don't have a /var/log/kernel.log !
> >Let me make sure of something:
> >This switcher code is to be run on osx, no? That's where
> >gfxcardstatus lives and where I can effect the card switch. Just
> >to make sure.
> >So I'm running osx mountain lion, and the only thing I see in the
> >logs when I switch cards (using gfxcardstatus) is what I pasted
> >below. and you're right, it was not in message.log, but system.log
> >(it was late). I just went through the whole thing again.
> >Am I missing something?

Yes, it's to be run on OS X. So apparently something has changed and
this technique no longer works for getting a log of the gmux I/O.

We've got one of these machines on order, so I'll see if I can turn
anything up when I get a chance to play with it.

Thanks,
Seth

Re: [PATCH V2 1/4] EFI: Stash ROMs if they're not in the PCI BAR

[Francois Rigaut]

Seth,

[CC'd people, sorry we exchanged a few emails with Seth outside of the 
lists, I passed him the acpi tables and here are gmux dumps]

Allright. thanks for gmux-dump. There seems to be progress, as I can see 
the gmux dumps for the nividia-selected and intel-selected are clearly 
different (I did it twice to be sure, it checks out).
The 2 dumps are at
http://maumae.net/retina/gmux-dump_intel.dat
and
http://maumae.net/retina/gmux-dump_nvidia_only.dat
I hope you'll be able to get something from these.
Francois



On 04/08/12 13:58, Seth Forshee wrote:
> On Sat, Aug 04, 2012 at 11:34:21AM +1000, Francois Rigaut wrote:
>> Seth,
>>
>> I've put the acpi table dump in http://maumae.net/retina/acpi_tables.tgz
> The ACPI stuff for the gmux looks exactly the same as for the machine
> I've got. The I/O range is still 0x700 to 0x7ff.
>
>> As far as the mem dump, I've done it but can not see any difference
>> (between case where one or the other graphic card are selected) in
>> the first 3000 bytes. Not sure I'm doing that well though. I'm just
>> dd'ing /dev/mem with
>> dd bs=1000 count=3 if=/dev/mem of=some_file
>> Am I addressing the right memory or is the switch going to be (or
>> likely to be) somewhere else?
> That's going to access sytem memory, not the I/O space for the gmux. Try
> the attached instead. It's going to output the raw binary, so if you
> want to view the output do something like
>
>   gmux-dump | xxd -g1
>
> Seth

Re: [PATCH V2 1/4] EFI: Stash ROMs if they're not in the PCI BAR

[Seth Forshee]

On Sat, Aug 04, 2012 at 03:44:14PM +1000, Francois Rigaut wrote:
> Seth,
> 
> [CC'd people, sorry we exchanged a few emails with Seth outside of
> the lists, I passed him the acpi tables and here are gmux dumps]
> 
> Allright. thanks for gmux-dump. There seems to be progress, as I can
> see the gmux dumps for the nividia-selected and intel-selected are
> clearly different (I did it twice to be sure, it checks out).
> The 2 dumps are at
> http://maumae.net/retina/gmux-dump_intel.dat
> and
> http://maumae.net/retina/gmux-dump_nvidia_only.dat
> I hope you'll be able to get something from these.

It looks like you're not really getting data from the gmux in those
dumps. The address range should be correct based on your ACPI tables. I
have some ideas, but it won't be much longer until I can play with one
of these machines myself so it's probably easier if I try them out then.

Thanks,
Seth

Re: [PATCH V2 1/4] EFI: Stash ROMs if they're not in the PCI BAR

[Francois Rigaut]

On Mon 06 Aug 2012 23:49:33 EST, Seth Forshee wrote:
> On Sat, Aug 04, 2012 at 03:44:14PM +1000, Francois Rigaut wrote:
>> Seth,
>>
>> [CC'd people, sorry we exchanged a few emails with Seth outside of
>> the lists, I passed him the acpi tables and here are gmux dumps]
>>
>> Allright. thanks for gmux-dump. There seems to be progress, as I can
>> see the gmux dumps for the nividia-selected and intel-selected are
>> clearly different (I did it twice to be sure, it checks out).
>> The 2 dumps are at
>> http://maumae.net/retina/gmux-dump_intel.dat
>> and
>> http://maumae.net/retina/gmux-dump_nvidia_only.dat
>> I hope you'll be able to get something from these.
>
> It looks like you're not really getting data from the gmux in those
> dumps. The address range should be correct based on your ACPI tables. I
> have some ideas, but it won't be much longer until I can play with one
> of these machines myself so it's probably easier if I try them out then.

allright, no worries. Delivery time can be quite long for these 
machines, I waited for mine 5 long weeks.
Hope you get yours faster.
Cheers,
Francois
PS: I'm working with Daniel Vetter [intel-fgx] for a of fix the video 
mode (corrupted), another problem for the use of the i915 driver
>
> Thanks,
> Seth