diff mbox

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

Message ID 1343407934-459-1-git-send-email-mjg@redhat.com
State Superseded
Headers show

Commit Message

Matthew Garrett July 27, 2012, 4:52 p.m. UTC
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(+)

Comments

Greg Kroah-Hartman July 31, 2012, 10:32 p.m. UTC | #1
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
--
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
Matthew Garrett Aug. 1, 2012, 4:54 p.m. UTC | #2
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.
Greg Kroah-Hartman Aug. 1, 2012, 11:21 p.m. UTC | #3
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
--
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
Seth Forshee Aug. 2, 2012, 4:02 a.m. UTC | #4
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

--
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
Greg Kroah-Hartman Aug. 2, 2012, 10:34 a.m. UTC | #5
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
--
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
Francois Rigaut Aug. 2, 2012, 2:57 p.m. UTC | #6
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

--
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
Seth Forshee Aug. 2, 2012, 4:12 p.m. UTC | #7
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

--
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
Francois Rigaut Aug. 2, 2012, 10:40 p.m. UTC | #8
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

--
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
Francois Rigaut Aug. 2, 2012, 10:54 p.m. UTC | #9
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

--
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
Seth Forshee Aug. 3, 2012, 4:53 a.m. UTC | #10
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

--
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
Francois Rigaut Aug. 4, 2012, 5:44 a.m. UTC | #11
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

--
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
Seth Forshee Aug. 6, 2012, 1:49 p.m. UTC | #12
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

--
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
Francois Rigaut Aug. 6, 2012, 10:50 p.m. UTC | #13
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
--
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
diff mbox

Patch

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
  */