[PATCH] Documentation: DocBook: Rename drm_stub.c to drm_drv.c cause 'make xmldocs' failed

[Randy Dunlap]

On 08/08/14 12:16, Masanari Iida wrote:
> This patch fixed 'make xmldocs' failed on linus's tree and
> linux-next as of 8th/Aug,2014.
> 
> When drm merge for 3.17-rc1 happen,  a file was renamed from
> drm_stub.c to drm_drv.c.
> But Documentation/DocBook/drm.tmpl still have an old file name.
> 
> Signed-off-by: Masanari Iida 

Acked-by: Randy Dunlap 

Thanks.

Linus, please merge as it fixes a DocBook build error.


> ---
>  Documentation/DocBook/drm.tmpl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 1d3756d..bacefc5 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -315,7 +315,7 @@ char *date;
>  drm_dev_unregister() followed by a call to
>  drm_dev_unref().
>
> -!Edrivers/gpu/drm/drm_stub.c
> +!Edrivers/gpu/drm/drm_drv.c
>  
>  
>Driver Load
> 


-- 
~Randy

[PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[Guenter Roeck]

spin_is_locked() always returns false in uniprocessor configurations
and can therefore not be used with BUG_ON. Replace it with
assert_spin_locked(), which exists for that very purpose.

Signed-off-by: Guenter Roeck 
---
 drivers/gpu/drm/msm/mdp/mdp_kms.c  | 2 +-
 drivers/gpu/drm/nouveau/core/core/event.c  | 4 ++--
 drivers/gpu/drm/nouveau/core/core/notify.c | 2 +-
 drivers/gpu/drm/omapdrm/omap_irq.c | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp_kms.c
index 03455b6..92a1531 100644
--- a/drivers/gpu/drm/msm/mdp/mdp_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp_kms.c
@@ -34,7 +34,7 @@ static void update_irq(struct mdp_kms *mdp_kms)
struct mdp_irq *irq;
uint32_t irqmask = mdp_kms->vblank_mask;

-   BUG_ON(!spin_is_locked(_lock));
+   assert_spin_locked(_lock);

list_for_each_entry(irq, _kms->irq_list, node)
irqmask |= irq->irqmask;
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index 0540a48..9327117 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -26,7 +26,7 @@
 void
 nvkm_event_put(struct nvkm_event *event, u32 types, int index)
 {
-   BUG_ON(!spin_is_locked(>refs_lock));
+   assert_spin_locked(>refs_lock);
while (types) {
int type = __ffs(types); types &= ~(1 << type);
if (--event->refs[index * event->types_nr + type] == 0) {
@@ -39,7 +39,7 @@ nvkm_event_put(struct nvkm_event *event, u32 types, int index)
 void
 nvkm_event_get(struct nvkm_event *event, u32 types, int index)
 {
-   BUG_ON(!spin_is_locked(>refs_lock));
+   assert_spin_locked(>refs_lock);
while (types) {
int type = __ffs(types); types &= ~(1 << type);
if (++event->refs[index * event->types_nr + type] == 1) {
diff --git a/drivers/gpu/drm/nouveau/core/core/notify.c 
b/drivers/gpu/drm/nouveau/core/core/notify.c
index 76adb81..f70dbc4 100644
--- a/drivers/gpu/drm/nouveau/core/core/notify.c
+++ b/drivers/gpu/drm/nouveau/core/core/notify.c
@@ -98,7 +98,7 @@ nvkm_notify_send(struct nvkm_notify *notify, void *data, u32 
size)
struct nvkm_event *event = notify->event;
unsigned long flags;

-   BUG_ON(!spin_is_locked(>list_lock));
+   assert_spin_locked(>list_lock);
BUG_ON(size != notify->size);

spin_lock_irqsave(>refs_lock, flags);
diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c 
b/drivers/gpu/drm/omapdrm/omap_irq.c
index f035d2b..3eb097e 100644
--- a/drivers/gpu/drm/omapdrm/omap_irq.c
+++ b/drivers/gpu/drm/omapdrm/omap_irq.c
@@ -34,7 +34,7 @@ static void omap_irq_update(struct drm_device *dev)
struct omap_drm_irq *irq;
uint32_t irqmask = priv->vblank_mask;

-   BUG_ON(!spin_is_locked(_lock));
+   assert_spin_locked(_lock);

list_for_each_entry(irq, >irq_list, node)
irqmask |= irq->irqmask;
-- 
1.9.1

[Bug 82428] [radeonsi,R9 270X] System lockup when using mplayer/mpv with VDPAU

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=82428

--- Comment #1 from Grzegorz Kowal  ---
I should also mention that I use kernel 3.14.16.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140810/fc1f6f50/attachment.html>

CONFIG_DMA_CMA causes ttm performance problems/hangs.

[Mario Kleiner]

On 08/10/2014 01:03 PM, Thomas Hellstrom wrote:
> On 08/10/2014 05:11 AM, Mario Kleiner wrote:
>> Resent this time without HTML formatting which lkml doesn't like. Sorry.
>>
>> On 08/09/2014 03:58 PM, Thomas Hellstrom wrote:
>>> On 08/09/2014 03:33 PM, Konrad Rzeszutek Wilk wrote:
 On August 9, 2014 1:39:39 AM EDT, Thomas
 Hellstrom  wrote:
> Hi.
>
 Hey Thomas!

> IIRC I don't think the TTM DMA pool allocates coherent pages more than
> one page at a time, and _if that's true_ it's pretty unnecessary for
> the
> dma subsystem to route those allocations to CMA. Maybe Konrad could
> shed
> some light over this?
 It should allocate in batches and keep them in the TTM DMA pool for
 some time to be reused.

 The pages that it gets are in 4kb granularity though.
>>> Then I feel inclined to say this is a DMA subsystem bug. Single page
>>> allocations shouldn't get routed to CMA.
>>>
>>> /Thomas
>> Yes, seems you're both right. I read through the code a bit more and
>> indeed the TTM DMA pool allocates only one page during each
>> dma_alloc_coherent() call, so it doesn't need CMA memory. The current
>> allocators don't check for single page CMA allocations and therefore
>> try to get it from the CMA area anyway, instead of skipping to the
>> much cheaper fallback.
>>
>> So the callers of dma_alloc_from_contiguous() could need that little
>> optimization of skipping it if only one page is requested. For
>>
>> dma_generic_alloc_coherent
>> 
>> andintel_alloc_coherent
>>   this
>> seems easy to do. Looking at the arm arch variants, e.g.,
>>
>> http://lxr.free-electrons.com/source/arch/arm/mm/dma-mapping.c#L1194
>>
>> and
>>
>> http://lxr.free-electrons.com/source/arch/arm64/mm/dma-mapping.c#L44
>>
>> i'm not sure if it is that easily done, as there aren't any fallbacks
>> for such a case and the code looks to me as if that's at least
>> somewhat intentional.
>>
>> As far as TTM goes, one quick one-line fix to prevent it from using
>> the CMA at least on SWIOTLB, NOMMU and Intel IOMMU (when using the
>> above methods) would be to clear the __GFP_WAIT
>>  flag from the
>> passed gfp_t flags. That would trigger the well working fallback. So, is
>>
>> __GFP_WAIT    needed
>> for those single page allocations that go through__ttm_dma_alloc_page
>> ?
>>
>> It would be nice to have such a simple, non-intrusive one-line patch
>> that we still could get into 3.17 and then backported to older stable
>> kernels to avoid the same desktop hangs there if CMA is enabled. It
>> would be also nice for actual users of CMA to not use up lots of CMA
>> space for gpu's which don't need it. I think DMA_CMA was introduced
>> around 3.12.
>>
> I don't think that's a good idea. Omitting __GFP_WAIT would cause
> unnecessary memory allocation errors on systems under stress.
> I think this should be filed as a DMA subsystem kernel bug / regression
> and an appropriate solution should be worked out together with the DMA
> subsystem maintainers and then backported.

Ok, so it is needed. I'll file a bug report.

>> The other problem is that probably TTM does not reuse pages from the
>> DMA pool. If i trace the __ttm_dma_alloc_page
>>  and
>> __ttm_dma_free_page
>>  calls for
>> those single page allocs/frees, then over a 20 second interval of
>> tracing and switching tabs in firefox, scrolling things around etc. i
>> find about as many alloc's as i find free's, e.g., 1607 allocs vs.
>> 1648 frees.
> This is because historically the pools have been designed to keep only
> pages with nonstandard caching attributes since changing page caching
> attributes have been very slow but the kernel page allocators have been
> reasonably fast.
>
> /Thomas

Ok. A bit more ftraceing showed my hang problem case goes through the 
"if (is_cached)" paths, so the pool doesn't recycle anything and i see 
it bouncing up and down by 4 pages all the time.

But for the non-cached case, which i don't hit with my problem, could 
one of you look at line 954...

http://lxr.free-electrons.com/source/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c#L954

... and tell me why that unconditional npages = count; assignment makes sense? 
It seems to essentially disable all recycling for the dma pool whenever the 
pool isn't filled up to/beyond its maximum with free pages? When the pool is 
filled up, lots of stuff is recycled, but when it is already somewhat below 
capacity, it gets "punished" by not getting refilled? I'd just like to 
understand the logic behind that line.

thanks,
-mario


>> This bit of code 

[Bug 82428] New: [radeonsi,R9 270X] System lockup when using mplayer/mpv with VDPAU

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=82428

  Priority: medium
Bug ID: 82428
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [radeonsi,R9 270X] System lockup when using
mplayer/mpv with VDPAU
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: custos.mentis at gmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

With mesa from today's git repository I am getting hard system lockups while
trying to play a movie with mplayer/mpv configured to use hardware acceleration
(vdpau).

I was able to bisect the commit causing those lockups. The responsible commit
is 1c03a690bfc3265c7fefa7f87e69782a6672a9b2 "radeonsi: use gpu_address from
r600_resource".

There is no related message in the logs, since the lockup is immediate and hard
reset is required.

I use libdrm, glamour, mesa, and xf86-video-ati from today's git with
xorg-server-1.15.0; mpv-0.3.11 with libav-9.14 and libvdpau-0.7.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140810/3e8e6433/attachment.html>

[PATCH 1/2 v2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()

[Bruno Prémont]

On Sun, 10 August 2014 Andreas Noever  wrote:
> On Sun, Aug 10, 2014 at 11:26 AM, Bruno Pr?mont wrote:
> > On Sun, 10 August 2014 Andreas Noever wrote:
> >
> >> On Sun, Aug 10, 2014 at 2:21 AM, Andreas Noeverwrote:
> >> > I just tried to run the latest kernel.  It failed to boot and git
> >> > bisect points to this commit (MacBookPro10,1 with Nvidia
> >> > graphics).
> >> >
> >> > The (now removed) code in efifb_setup did always set default_vga, even
> >> > if it had already been set earlier. The new code in pci_fixup_video
> >> > runs only if vga_default_device() is NULL. Removing the check fixes
> >> > the regression.
> >> >
> >> >
> >> > The following calls to vga_set_default_device are made during boot:
> >> >
> >> > vga_arbiter_add_pci_device -> vga_set_default_device(intel)
> >> > pci_fixup_video -> vga_set_default_device(intel) (there are two calls
> >> > in pci_fixup_video, this one is the one near "Boot video device")
> >> > pci_fixup_video -> vga_set_default_device(nvidia) (from the "Does
> >> > firmware framebuffer belong to us?" loop, only if I remove the check)
> >> >
> >> > vga_arbiter_add_pci_device chooses intel simply because it is the
> >> > first device. Next pci_fixup_video(intel) sees that it is the default
> >> > device, sets the IORESOURCE_ROM_SHADOW flag and calls
> >> > vga_set_default_device again. And finally (if the check is removed)
> >> > pci_fixup_video(nvidia) sees that it owns the framebuffer and sets
> >> > itself as the default device which allows the system to boot again.
> >> >
> >> > Does setting the ROM_SHADOW flag on (possibly) the wrong device have
> >> > any effect?
> >> Yes it does. Removing the line changes a long standing
> >> i915 :00:02.0: Invalid ROM contents
> >> into a
> >> i915 :00:02.0: BAR 6: can't assign [??? 0x flags
> >> 0x2000] (bogus alignment).
> >>
> >> The first is logged at KERN_ERR and the second one only at KERN_INFO.
> >> We are making progress.
> >
> > How does your system behave if you change vga_arbiter_add_pci_device()
> > not to set vga_set_default_device() with the first device registered?
> >
> > That is remove the
> > #ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
> > code block in vga_arbiter_add_pci_device().
> The system does not boot.  The Intel device is still set as the
> default device in pci_fixup_video (near "Boot video device") and
> prevents the nvidia device (which is initialized later) from becoming
> the default one.
>
> > How did your system behave in the past if you did not enable efifb?
> I don't think that I ever did not enable efifb. It seems to have been
> around for quite a while?

The question here is if you system just refuses to boot as well.

The aim of my patch is to make system work (properly) when efifb is not used
(why use efifb if built-in drm drivers handle the GPU(s)?)

If you decided to replace efifb with platform-framebuffer+simplefb/simpledrm
you would probably see the same issue as that would be no efifb as well.

The presence of efifb should not be mandatory for successfully booting
and running Xorg.

> Andreas

How does you system behave with below patch on top of Linus tree?

Bruno



---
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index c61ea57..15d0068 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -367,7 +367,7 @@ static void pci_fixup_video(struct pci_dev *pdev)
}
bus = bus->parent;
}
-   if (!vga_default_device() || pdev == vga_default_device()) {
+   if (pdev == vga_default_device()) {
pci_read_config_word(pdev, PCI_COMMAND, );
if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
pdev->resource[PCI_ROM_RESOURCE].flags |= 
IORESOURCE_ROM_SHADOW;
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index d2077f0..ac44d87 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -112,10 +112,8 @@ both:
return 1;
 }

-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
 /* this is only used a cookie - it should not be dereferenced */
 static struct pci_dev *vga_default;
-#endif

 static void vga_arb_device_card_gone(struct pci_dev *pdev);

@@ -131,7 +129,6 @@ static struct vga_device *vgadev_find(struct pci_dev *pdev)
 }

 /* Returns the default VGA device (vgacon's babe) */
-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
 struct pci_dev *vga_default_device(void)
 {
return vga_default;
@@ -147,7 +144,6 @@ void vga_set_default_device(struct pci_dev *pdev)
pci_dev_put(vga_default);
vga_default = pci_dev_get(pdev);
 }
-#endif

 static inline void vga_irq_set_state(struct vga_device *vgadev, bool state)
 {
@@ -580,10 +576,10 @@ static bool vga_arbiter_add_pci_device(struct pci_dev 
*pdev)
bus = bus->parent;
}

+#if 0
/* Deal with VGA default device. Use first enabled one
 * by default if arch doesn't have it's own hook
 */
-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
if 

[Bug 42960] Display does not work when resuming from suspend

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=42960

--- Comment #46 from nb  ---
(In reply to comment #38)
> Created attachment 97562 [details] [review]
> possible fix
> 
> Does the attached patch help?

tested the patch. didn't work for me

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140810/4e8ea846/attachment-0001.html>

[Bug 81576] GPU lock-ups while playing XCOM Enemy Unknown

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=81576

Andrei Slavoiu  changed:

   What|Removed |Added

 CC||ansla80 at yahoo.com

--- Comment #3 from Andrei Slavoiu  ---
I get the same on a Kaveri (A10-7850K)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140810/49a67993/attachment.html>

CONFIG_DMA_CMA causes ttm performance problems/hangs.

[Thomas Hellstrom]

On 08/10/2014 05:11 AM, Mario Kleiner wrote:
> Resent this time without HTML formatting which lkml doesn't like. Sorry.
>
> On 08/09/2014 03:58 PM, Thomas Hellstrom wrote:
>> On 08/09/2014 03:33 PM, Konrad Rzeszutek Wilk wrote:
>>> On August 9, 2014 1:39:39 AM EDT, Thomas
>>> Hellstrom  wrote:
 Hi.

>>> Hey Thomas!
>>>
 IIRC I don't think the TTM DMA pool allocates coherent pages more than
 one page at a time, and _if that's true_ it's pretty unnecessary for
 the
 dma subsystem to route those allocations to CMA. Maybe Konrad could
 shed
 some light over this?
>>> It should allocate in batches and keep them in the TTM DMA pool for
>>> some time to be reused.
>>>
>>> The pages that it gets are in 4kb granularity though.
>> Then I feel inclined to say this is a DMA subsystem bug. Single page
>> allocations shouldn't get routed to CMA.
>>
>> /Thomas
>
> Yes, seems you're both right. I read through the code a bit more and
> indeed the TTM DMA pool allocates only one page during each
> dma_alloc_coherent() call, so it doesn't need CMA memory. The current
> allocators don't check for single page CMA allocations and therefore
> try to get it from the CMA area anyway, instead of skipping to the
> much cheaper fallback.
>
> So the callers of dma_alloc_from_contiguous() could need that little
> optimization of skipping it if only one page is requested. For
>
> dma_generic_alloc_coherent 
>  
> andintel_alloc_coherent 
>   this
> seems easy to do. Looking at the arm arch variants, e.g.,
>
> http://lxr.free-electrons.com/source/arch/arm/mm/dma-mapping.c#L1194
>
> and
>
> http://lxr.free-electrons.com/source/arch/arm64/mm/dma-mapping.c#L44
>
> i'm not sure if it is that easily done, as there aren't any fallbacks
> for such a case and the code looks to me as if that's at least
> somewhat intentional.
>
> As far as TTM goes, one quick one-line fix to prevent it from using
> the CMA at least on SWIOTLB, NOMMU and Intel IOMMU (when using the
> above methods) would be to clear the __GFP_WAIT
>  flag from the
> passed gfp_t flags. That would trigger the well working fallback. So, is
>
> __GFP_WAIT    needed
> for those single page allocations that go through__ttm_dma_alloc_page 
> ?
>
> It would be nice to have such a simple, non-intrusive one-line patch
> that we still could get into 3.17 and then backported to older stable
> kernels to avoid the same desktop hangs there if CMA is enabled. It
> would be also nice for actual users of CMA to not use up lots of CMA
> space for gpu's which don't need it. I think DMA_CMA was introduced
> around 3.12.
>

I don't think that's a good idea. Omitting __GFP_WAIT would cause
unnecessary memory allocation errors on systems under stress.
I think this should be filed as a DMA subsystem kernel bug / regression
and an appropriate solution should be worked out together with the DMA
subsystem maintainers and then backported.

>
> The other problem is that probably TTM does not reuse pages from the
> DMA pool. If i trace the __ttm_dma_alloc_page
>  and
> __ttm_dma_free_page
>  calls for
> those single page allocs/frees, then over a 20 second interval of
> tracing and switching tabs in firefox, scrolling things around etc. i
> find about as many alloc's as i find free's, e.g., 1607 allocs vs.
> 1648 frees.

This is because historically the pools have been designed to keep only
pages with nonstandard caching attributes since changing page caching
attributes have been very slow but the kernel page allocators have been
reasonably fast.

/Thomas

>
> This bit of code fromttm_dma_unpopulate
> ()  (line
> 954 in 3.16) looks suspicious:
>
> http://lxr.free-electrons.com/source/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c#L954
>
>
> Alloc's from a tt_cached cached pool ( if (is_cached)...) always get
> freed and are not given back to the cached pool. But in the uncached
> case, there's logic to make sure the pool doesn't grow forever (line
> 955, checking against _manager->options.max_size), but before that
> check in line 954 there's an uncoditional assignment of npages =
> count; which seems to force freeing all pages as well, instead of
> recycling? Is this some debug code left over, or intentional and just
> me not understanding what happens there?
>
> thanks,
> -mario
>
>
 /Thomas


 On 08/08/2014 07:42 PM, Mario Kleiner wrote:
> Hi all,
>
> there is a rather severe performance problem i accidentally found
 when
> trying to give Linux 3.16.0 a final test on a x86_64 MacBookPro 

[Bug 79575] [radeonsi] Wine's d3d8 test crashes in SITargetLowering::analyzeImmediate

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=79575

--- Comment #5 from Andrei Slavoiu  ---
BTW, I just noticed that in the latest backtrace
util_make_vertex_passthrough_shader_with_so no longer appears. Instead it
starts from util_make_empty_fragment_shader. I tried adding R600_DEBUG=fs but
no extra info was printed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140810/c093586e/attachment.html>

[PATCH 1/2 v2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()

[Andreas Noever]

On Sun, Aug 10, 2014 at 11:26 AM, Bruno Pr?mont
 wrote:
> On Sun, 10 August 2014 Andreas Noever  wrote:
>
>> On Sun, Aug 10, 2014 at 2:21 AM, Andreas Noever
>>  wrote:
>> > On Sat, Jul 5, 2014 at 7:15 PM, Bjorn Helgaas  
>> > wrote:
>> >> On Wed, Jun 25, 2014 at 12:55:01AM +0200, Bruno Pr?mont wrote:
>> >>> With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
>> >>> Matthew Garrett introduced a efifb vga_default_device() so that EFI
>> >>> systems that do not load shadow VBIOS or setup VGA get proper value for
>> >>> boot_vga PCI sysfs attribute on the corresponding PCI device.
>> >>>
>> >>> Xorg is refusing to detect devices when boot_vga=0 which is the case on
>> >>> some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and finds
>> >>> the dri device but then bails out with "no devices detected".
>> >>>
>> >>> Note: When vga_default_device() is set boot_vga PCI sysfs attribute
>> >>> reflects its state. When unset this attribute is 1 whenever
>> >>> IORESOURCE_ROM_SHADOW flag is set.
>> >>>
>> >>> With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
>> >>> while having native drivers for the GPU also makes selecting
>> >>> sysfb/efifb optional.
>> >>>
>> >>> Remove the efifb implementation of vga_default_device() and initialize
>> >>> vgaarb's vga_default_device() with the PCI GPU that matches boot
>> >>> screen_info in pci_fixup_video().
>> >>>
>> >>> Tested-by: Anibal Francisco Martinez Cortina 
>> >>> Cc: Matthew Garrett 
>> >>> Cc: stable at vger.kernel.org
>> >>> Signed-off-by: Bruno Pr?mont 
>> >>
>> >> I applied both with Matthew's ack to pci/misc for v3.17, thanks!
>> >
>> > I just tried to run the latest kernel.  It failed to boot and git
>> > bisect points to this commit (MacBookPro10,1 with Nvidia
>> > graphics).
>> >
>> > The (now removed) code in efifb_setup did always set default_vga, even
>> > if it had already been set earlier. The new code in pci_fixup_video
>> > runs only if vga_default_device() is NULL. Removing the check fixes
>> > the regression.
>> >
>> >
>> > The following calls to vga_set_default_device are made during boot:
>> >
>> > vga_arbiter_add_pci_device -> vga_set_default_device(intel)
>> > pci_fixup_video -> vga_set_default_device(intel) (there are two calls
>> > in pci_fixup_video, this one is the one near "Boot video device")
>> > pci_fixup_video -> vga_set_default_device(nvidia) (from the "Does
>> > firmware framebuffer belong to us?" loop, only if I remove the check)
>> >
>> > vga_arbiter_add_pci_device chooses intel simply because it is the
>> > first device. Next pci_fixup_video(intel) sees that it is the default
>> > device, sets the IORESOURCE_ROM_SHADOW flag and calls
>> > vga_set_default_device again. And finally (if the check is removed)
>> > pci_fixup_video(nvidia) sees that it owns the framebuffer and sets
>> > itself as the default device which allows the system to boot again.
>> >
>> > Does setting the ROM_SHADOW flag on (possibly) the wrong device have
>> > any effect?
>> Yes it does. Removing the line changes a long standing
>> i915 :00:02.0: Invalid ROM contents
>> into a
>> i915 :00:02.0: BAR 6: can't assign [??? 0x flags
>> 0x2000] (bogus alignment).
>>
>> The first is logged at KERN_ERR and the second one only at KERN_INFO.
>> We are making progress.
>
> How does your system behave if you change vga_arbiter_add_pci_device()
> not to set vga_set_default_device() with the first device registered?
>
> That is remove the
> #ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
> code block in vga_arbiter_add_pci_device().
The system does not boot.  The Intel device is still set as the
default device in pci_fixup_video (near "Boot video device") and
prevents the nvidia device (which is initialized later) from becoming
the default one.


> How did your system behave in the past if you did not enable efifb?
I don't think that I ever did not enable efifb. It seems to have been
around for quite a while?

Andreas

[PATCH 1/2 v2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()

[Bruno Prémont]

On Sun, 10 August 2014 Andreas Noever  wrote:

> On Sun, Aug 10, 2014 at 2:21 AM, Andreas Noever
>  wrote:
> > On Sat, Jul 5, 2014 at 7:15 PM, Bjorn Helgaas  
> > wrote:
> >> On Wed, Jun 25, 2014 at 12:55:01AM +0200, Bruno Pr?mont wrote:
> >>> With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
> >>> Matthew Garrett introduced a efifb vga_default_device() so that EFI
> >>> systems that do not load shadow VBIOS or setup VGA get proper value for
> >>> boot_vga PCI sysfs attribute on the corresponding PCI device.
> >>>
> >>> Xorg is refusing to detect devices when boot_vga=0 which is the case on
> >>> some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and finds
> >>> the dri device but then bails out with "no devices detected".
> >>>
> >>> Note: When vga_default_device() is set boot_vga PCI sysfs attribute
> >>> reflects its state. When unset this attribute is 1 whenever
> >>> IORESOURCE_ROM_SHADOW flag is set.
> >>>
> >>> With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
> >>> while having native drivers for the GPU also makes selecting
> >>> sysfb/efifb optional.
> >>>
> >>> Remove the efifb implementation of vga_default_device() and initialize
> >>> vgaarb's vga_default_device() with the PCI GPU that matches boot
> >>> screen_info in pci_fixup_video().
> >>>
> >>> Tested-by: Anibal Francisco Martinez Cortina 
> >>> Cc: Matthew Garrett 
> >>> Cc: stable at vger.kernel.org
> >>> Signed-off-by: Bruno Pr?mont 
> >>
> >> I applied both with Matthew's ack to pci/misc for v3.17, thanks!
> >
> > I just tried to run the latest kernel.  It failed to boot and git
> > bisect points to this commit (MacBookPro10,1 with Nvidia
> > graphics).
> >
> > The (now removed) code in efifb_setup did always set default_vga, even
> > if it had already been set earlier. The new code in pci_fixup_video
> > runs only if vga_default_device() is NULL. Removing the check fixes
> > the regression.
> >
> >
> > The following calls to vga_set_default_device are made during boot:
> >
> > vga_arbiter_add_pci_device -> vga_set_default_device(intel)
> > pci_fixup_video -> vga_set_default_device(intel) (there are two calls
> > in pci_fixup_video, this one is the one near "Boot video device")
> > pci_fixup_video -> vga_set_default_device(nvidia) (from the "Does
> > firmware framebuffer belong to us?" loop, only if I remove the check)
> >
> > vga_arbiter_add_pci_device chooses intel simply because it is the
> > first device. Next pci_fixup_video(intel) sees that it is the default
> > device, sets the IORESOURCE_ROM_SHADOW flag and calls
> > vga_set_default_device again. And finally (if the check is removed)
> > pci_fixup_video(nvidia) sees that it owns the framebuffer and sets
> > itself as the default device which allows the system to boot again.
> >
> > Does setting the ROM_SHADOW flag on (possibly) the wrong device have
> > any effect?
> Yes it does. Removing the line changes a long standing
> i915 :00:02.0: Invalid ROM contents
> into a
> i915 :00:02.0: BAR 6: can't assign [??? 0x flags
> 0x2000] (bogus alignment).
> 
> The first is logged at KERN_ERR and the second one only at KERN_INFO.
> We are making progress.

How does your system behave if you change vga_arbiter_add_pci_device()
not to set vga_set_default_device() with the first device registered?

That is remove the 
#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
code block in vga_arbiter_add_pci_device().

How did your system behave in the past if you did not enable efifb?

Bruno

[PATCH] drm/panel/simple: add optronics B101XTN01.0 (v3)

[Rob Clark]

LVDS panel, make/model described as:

AU Optronics Corporation - B101XTN01.0 (H/W:0A)

See:
http://www.encore-electronic.com/media/B101XTN01.0.pdf

Tested with panel attached to an Inforce IFC6410 board.

Signed-off-by: Rob Clark 
---
v1: original
v2: review comments from Thierry Reding
v3: rebase on drm-next (adds bpc)

 .../devicetree/bindings/panel/auo,b101xtn01.txt|  7 ++
 drivers/gpu/drm/panel/panel-simple.c   | 27 ++
 2 files changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/panel/auo,b101xtn01.txt

diff --git a/Documentation/devicetree/bindings/panel/auo,b101xtn01.txt 
b/Documentation/devicetree/bindings/panel/auo,b101xtn01.txt
new file mode 100644
index 000..889d511
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/auo,b101xtn01.txt
@@ -0,0 +1,7 @@
+AU Optronics Corporation 10.1" WXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "auo,b101xtn01"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 4ce1db0..23de22f 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -352,6 +352,30 @@ static const struct panel_desc auo_b101aw03 = {
},
 };

+static const struct drm_display_mode auo_b101xtn01_mode = {
+   .clock = 72000,
+   .hdisplay = 1366,
+   .hsync_start = 1366 + 20,
+   .hsync_end = 1366 + 20 + 70,
+   .htotal = 1366 + 20 + 70,
+   .vdisplay = 768,
+   .vsync_start = 768 + 14,
+   .vsync_end = 768 + 14 + 42,
+   .vtotal = 768 + 14 + 42,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc auo_b101xtn01 = {
+   .modes = _b101xtn01_mode,
+   .num_modes = 1,
+   .bpc = 6,
+   .size = {
+   .width = 223,
+   .height = 125,
+   },
+};
+
 static const struct drm_display_mode auo_b133xtn01_mode = {
.clock = 69500,
.hdisplay = 1366,
@@ -616,6 +640,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b101aw03",
.data = _b101aw03,
}, {
+   .compatible = "auo,b101xtn01",
+   .data = _b101xtn01,
+   }, {
.compatible = "auo,b133htn01",
.data = _b133htn01,
}, {
-- 
1.9.3

[PATCH] drm/panel/simple: add optronics B101XTN01.0 (v2)

[Rob Clark]

LVDS panel, make/model described as:

AU Optronics Corporation - B101XTN01.0 (H/W:0A)

See:
http://www.encore-electronic.com/media/B101XTN01.0.pdf

Tested with panel attached to an Inforce IFC6410 board.

Signed-off-by: Rob Clark 
---
 .../devicetree/bindings/panel/auo,b101xtn01.txt|  7 ++
 drivers/gpu/drm/panel/panel-simple.c   | 26 ++
 2 files changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/panel/auo,b101xtn01.txt

diff --git a/Documentation/devicetree/bindings/panel/auo,b101xtn01.txt 
b/Documentation/devicetree/bindings/panel/auo,b101xtn01.txt
new file mode 100644
index 000..889d511
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/auo,b101xtn01.txt
@@ -0,0 +1,7 @@
+AU Optronics Corporation 10.1" WXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "auo,b101xtn01"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index a251361..b0e81a6 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -291,6 +291,29 @@ static const struct panel_desc auo_b101aw03 = {
},
 };

+static const struct drm_display_mode auo_b101xtn01_mode = {
+   .clock = 72000,
+   .hdisplay = 1366,
+   .hsync_start = 1366 + 20,
+   .hsync_end = 1366 + 20 + 70,
+   .htotal = 1366 + 20 + 70,
+   .vdisplay = 768,
+   .vsync_start = 768 + 14,
+   .vsync_end = 768 + 14 + 42,
+   .vtotal = 768 + 14 + 42,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc auo_b101xtn01 = {
+   .modes = _b101xtn01_mode,
+   .num_modes = 1,
+   .size = {
+   .width = 223,
+   .height = 125,
+   },
+};
+
 static const struct drm_display_mode auo_b133xtn01_mode = {
.clock = 69500,
.hdisplay = 1366,
@@ -452,6 +475,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b101aw03",
.data = _b101aw03,
}, {
+   .compatible = "auo,b101xtn01",
+   .data = _b101xtn01,
+   }, {
.compatible = "auo,b133xtn01",
.data = _b133xtn01,
}, {
-- 
1.9.3

CONFIG_DMA_CMA causes ttm performance problems/hangs.

[Mario Kleiner]

Resent this time without HTML formatting which lkml doesn't like. Sorry.

On 08/09/2014 03:58 PM, Thomas Hellstrom wrote:
> On 08/09/2014 03:33 PM, Konrad Rzeszutek Wilk wrote:
>> On August 9, 2014 1:39:39 AM EDT, Thomas Hellstrom 
>>  wrote:
>>> Hi.
>>>
>> Hey Thomas!
>>
>>> IIRC I don't think the TTM DMA pool allocates coherent pages more than
>>> one page at a time, and _if that's true_ it's pretty unnecessary for
>>> the
>>> dma subsystem to route those allocations to CMA. Maybe Konrad could
>>> shed
>>> some light over this?
>> It should allocate in batches and keep them in the TTM DMA pool for some 
>> time to be reused.
>>
>> The pages that it gets are in 4kb granularity though.
> Then I feel inclined to say this is a DMA subsystem bug. Single page
> allocations shouldn't get routed to CMA.
>
> /Thomas

Yes, seems you're both right. I read through the code a bit more and 
indeed the TTM DMA pool allocates only one page during each 
dma_alloc_coherent() call, so it doesn't need CMA memory. The current 
allocators don't check for single page CMA allocations and therefore try 
to get it from the CMA area anyway, instead of skipping to the much 
cheaper fallback.

So the callers of dma_alloc_from_contiguous() could need that little 
optimization of skipping it if only one page is requested. For

dma_generic_alloc_coherent  
  
andintel_alloc_coherent  
  this seems easy 
to do. Looking at the arm arch variants, e.g.,

http://lxr.free-electrons.com/source/arch/arm/mm/dma-mapping.c#L1194

and

http://lxr.free-electrons.com/source/arch/arm64/mm/dma-mapping.c#L44

i'm not sure if it is that easily done, as there aren't any fallbacks 
for such a case and the code looks to me as if that's at least somewhat 
intentional.

As far as TTM goes, one quick one-line fix to prevent it from using the 
CMA at least on SWIOTLB, NOMMU and Intel IOMMU (when using the above 
methods) would be to clear the __GFP_WAIT 
 flag from the passed 
gfp_t flags. That would trigger the well working fallback. So, is

__GFP_WAIT    needed for 
those single page allocations that go through__ttm_dma_alloc_page  
?

It would be nice to have such a simple, non-intrusive one-line patch 
that we still could get into 3.17 and then backported to older stable 
kernels to avoid the same desktop hangs there if CMA is enabled. It 
would be also nice for actual users of CMA to not use up lots of CMA 
space for gpu's which don't need it. I think DMA_CMA was introduced 
around 3.12.


The other problem is that probably TTM does not reuse pages from the DMA 
pool. If i trace the __ttm_dma_alloc_page 
 and 
__ttm_dma_free_page 
 calls for 
those single page allocs/frees, then over a 20 second interval of 
tracing and switching tabs in firefox, scrolling things around etc. i 
find about as many alloc's as i find free's, e.g., 1607 allocs vs. 1648 
frees.

This bit of code fromttm_dma_unpopulate 
()  (line 954 
in 3.16) looks suspicious:

http://lxr.free-electrons.com/source/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c#L954

Alloc's from a tt_cached cached pool ( if (is_cached)...) always get 
freed and are not given back to the cached pool. But in the uncached 
case, there's logic to make sure the pool doesn't grow forever (line 
955, checking against _manager->options.max_size), but before that check 
in line 954 there's an uncoditional assignment of npages = count; which 
seems to force freeing all pages as well, instead of recycling? Is this 
some debug code left over, or intentional and just me not understanding 
what happens there?

thanks,
-mario


>>> /Thomas
>>>
>>>
>>> On 08/08/2014 07:42 PM, Mario Kleiner wrote:
 Hi all,

 there is a rather severe performance problem i accidentally found
>>> when
 trying to give Linux 3.16.0 a final test on a x86_64 MacBookPro under
 Ubuntu 14.04 LTS with nouveau as graphics driver.

 I was lazy and just installed the Ubuntu precompiled mainline kernel.
 That kernel happens to have CONFIG_DMA_CMA=y set, with a default CMA
 (contiguous memory allocator) size of 64 MB. Older Ubuntu kernels
 weren't compiled with CMA, so i only observed this on 3.16, but
 previous kernels would likely be affected too.

 After a few minutes of regular desktop use like switching workspaces,
 scrolling text in a terminal window, Firefox with multiple tabs open,
 Thunderbird etc. (tested with KDE/Kwin, with/without desktop
 composition), i get chunky desktop updates, then multi-second
>>> freezes,
 after a few 

CONFIG_DMA_CMA causes ttm performance problems/hangs.

[Mario Kleiner]

 ! 1873.071 us | dma_alloc_from_contiguous();
>>>>   1) ! 1874.292 us |  }
>>>>   1) ! 1875.400 us |}
>>>>   1)   | __ttm_dma_alloc_page [ttm]() {
>>>>   1)   | dma_generic_alloc_coherent() {
>>>>   1) ! 1868.372 us | dma_alloc_from_contiguous();
>>>>   1) ! 1869.586 us |  }
>>>>   1) ! 1870.053 us |}
>>>>   1)   | __ttm_dma_alloc_page [ttm]() {
>>>>   1)   | dma_generic_alloc_coherent() {
>>>>   1) ! 1871.085 us | dma_alloc_from_contiguous();
>>>>   1) ! 1872.240 us |  }
>>>>   1) ! 1872.669 us |}
>>>>   1)   | __ttm_dma_alloc_page [ttm]() {
>>>>   1)   | dma_generic_alloc_coherent() {
>>>>   1) ! 1888.934 us | dma_alloc_from_contiguous();
>>>>   1) ! 1890.179 us |  }
>>>>   1) ! 1890.608 us |}
>>>>   1)   0.048 us| ttm_set_pages_caching [ttm]();
>>>>   1) ! 7511.000 us |  }
>>>>   1) ! 7511.306 us |}
>>>>   1) ! 7511.623 us |  }
>>>>
>>>> The good case (with cma=0 kernel cmdline, so
>>>> dma_alloc_from_contiguous() no-ops,)
>>>>
>>>> 0)   |  ttm_dma_pool_get_pages
>>>> [ttm]() {
>>>>   0)   | ttm_dma_page_pool_fill_locked [ttm]() {
>>>>   0)   | ttm_dma_pool_alloc_new_pages [ttm]() {
>>>>   0)   | __ttm_dma_alloc_page [ttm]() {
>>>>   0)   | dma_generic_alloc_coherent() {
>>>>   0)   0.171 us| dma_alloc_from_contiguous();
>>>>   0)   0.849 us| __alloc_pages_nodemask();
>>>>   0)   3.029 us|  }
>>>>   0)   3.882 us|}
>>>>   0)   | __ttm_dma_alloc_page [ttm]() {
>>>>   0)   | dma_generic_alloc_coherent() {
>>>>   0)   0.037 us| dma_alloc_from_contiguous();
>>>>   0)   0.163 us| __alloc_pages_nodemask();
>>>>   0)   1.408 us|  }
>>>>   0)   1.719 us|}
>>>>   0)   | __ttm_dma_alloc_page [ttm]() {
>>>>   0)   | dma_generic_alloc_coherent() {
>>>>   0)   0.035 us| dma_alloc_from_contiguous();
>>>>   0)   0.153 us| __alloc_pages_nodemask();
>>>>   0)   1.454 us|  }
>>>>   0)   1.720 us|}
>>>>   0)   | __ttm_dma_alloc_page [ttm]() {
>>>>   0)   | dma_generic_alloc_coherent() {
>>>>   0)   0.036 us| dma_alloc_from_contiguous();
>>>>   0)   0.112 us| __alloc_pages_nodemask();
>>>>   0)   1.211 us|  }
>>>>   0)   1.541 us|}
>>>>   0)   0.035 us| ttm_set_pages_caching [ttm]();
>>>>   0) + 10.902 us   |  }
>>>>   0) + 11.577 us   |}
>>>>   0) + 11.988 us   |  }
>>>>
>>>> ___
>>>> dri-devel mailing list
>>>> dri-devel at lists.freedesktop.org
>>>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/dri-devel=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A=6cy0madhpBCtEyOKu95ucqhzU%2FjAHPP7ODVTc47UYQs%3D%0A=d2636419e1f7f56c0d270e29ffe6ab6c6e29249876a578d70d973058f9411831

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140810/002fc245/attachment-0001.html>

[Bug 82397] some GLSL demo render badly on Radeon 7870

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=82397

--- Comment #1 from Michel D?nzer  ---
Works fine for me in Iceweasel 31 on radeonsi from current Mesa Git master
built against current LLVM trunk.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140810/94745e29/attachment.html>

[PATCH 1/2 v2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()

[Andreas Noever]

On Sun, Aug 10, 2014 at 2:21 AM, Andreas Noever
 wrote:
> On Sat, Jul 5, 2014 at 7:15 PM, Bjorn Helgaas  wrote:
>> On Wed, Jun 25, 2014 at 12:55:01AM +0200, Bruno Pr?mont wrote:
>>> With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
>>> Matthew Garrett introduced a efifb vga_default_device() so that EFI
>>> systems that do not load shadow VBIOS or setup VGA get proper value for
>>> boot_vga PCI sysfs attribute on the corresponding PCI device.
>>>
>>> Xorg is refusing to detect devices when boot_vga=0 which is the case on
>>> some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and finds
>>> the dri device but then bails out with "no devices detected".
>>>
>>> Note: When vga_default_device() is set boot_vga PCI sysfs attribute
>>> reflects its state. When unset this attribute is 1 whenever
>>> IORESOURCE_ROM_SHADOW flag is set.
>>>
>>> With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
>>> while having native drivers for the GPU also makes selecting
>>> sysfb/efifb optional.
>>>
>>> Remove the efifb implementation of vga_default_device() and initialize
>>> vgaarb's vga_default_device() with the PCI GPU that matches boot
>>> screen_info in pci_fixup_video().
>>>
>>> Tested-by: Anibal Francisco Martinez Cortina 
>>> Cc: Matthew Garrett 
>>> Cc: stable at vger.kernel.org
>>> Signed-off-by: Bruno Pr?mont 
>>
>> I applied both with Matthew's ack to pci/misc for v3.17, thanks!
>
> I just tried to run the latest kernel.  It failed to boot and git
> bisect points to this commit (MacBookPro10,1 with Nvidia
> graphics).
>
> The (now removed) code in efifb_setup did always set default_vga, even
> if it had already been set earlier. The new code in pci_fixup_video
> runs only if vga_default_device() is NULL. Removing the check fixes
> the regression.
>
>
> The following calls to vga_set_default_device are made during boot:
>
> vga_arbiter_add_pci_device -> vga_set_default_device(intel)
> pci_fixup_video -> vga_set_default_device(intel) (there are two calls
> in pci_fixup_video, this one is the one near "Boot video device")
> pci_fixup_video -> vga_set_default_device(nvidia) (from the "Does
> firmware framebuffer belong to us?" loop, only if I remove the check)
>
> vga_arbiter_add_pci_device chooses intel simply because it is the
> first device. Next pci_fixup_video(intel) sees that it is the default
> device, sets the IORESOURCE_ROM_SHADOW flag and calls
> vga_set_default_device again. And finally (if the check is removed)
> pci_fixup_video(nvidia) sees that it owns the framebuffer and sets
> itself as the default device which allows the system to boot again.
>
> Does setting the ROM_SHADOW flag on (possibly) the wrong device have
> any effect?
Yes it does. Removing the line changes a long standing
i915 :00:02.0: Invalid ROM contents
into a
i915 :00:02.0: BAR 6: can't assign [??? 0x flags
0x2000] (bogus alignment).

The first is logged at KERN_ERR and the second one only at KERN_INFO.
We are making progress.

[PATCH 1/2 v2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()

[Andreas Noever]

On Sat, Jul 5, 2014 at 7:15 PM, Bjorn Helgaas  wrote:
> On Wed, Jun 25, 2014 at 12:55:01AM +0200, Bruno Pr?mont wrote:
>> With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
>> Matthew Garrett introduced a efifb vga_default_device() so that EFI
>> systems that do not load shadow VBIOS or setup VGA get proper value for
>> boot_vga PCI sysfs attribute on the corresponding PCI device.
>>
>> Xorg is refusing to detect devices when boot_vga=0 which is the case on
>> some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and finds
>> the dri device but then bails out with "no devices detected".
>>
>> Note: When vga_default_device() is set boot_vga PCI sysfs attribute
>> reflects its state. When unset this attribute is 1 whenever
>> IORESOURCE_ROM_SHADOW flag is set.
>>
>> With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
>> while having native drivers for the GPU also makes selecting
>> sysfb/efifb optional.
>>
>> Remove the efifb implementation of vga_default_device() and initialize
>> vgaarb's vga_default_device() with the PCI GPU that matches boot
>> screen_info in pci_fixup_video().
>>
>> Tested-by: Anibal Francisco Martinez Cortina 
>> Cc: Matthew Garrett 
>> Cc: stable at vger.kernel.org
>> Signed-off-by: Bruno Pr?mont 
>
> I applied both with Matthew's ack to pci/misc for v3.17, thanks!

I just tried to run the latest kernel.  It failed to boot and git
bisect points to this commit (MacBookPro10,1 with Nvidia
graphics).

The (now removed) code in efifb_setup did always set default_vga, even
if it had already been set earlier. The new code in pci_fixup_video
runs only if vga_default_device() is NULL. Removing the check fixes
the regression.


The following calls to vga_set_default_device are made during boot:

vga_arbiter_add_pci_device -> vga_set_default_device(intel)
pci_fixup_video -> vga_set_default_device(intel) (there are two calls
in pci_fixup_video, this one is the one near "Boot video device")
pci_fixup_video -> vga_set_default_device(nvidia) (from the "Does
firmware framebuffer belong to us?" loop, only if I remove the check)

vga_arbiter_add_pci_device chooses intel simply because it is the
first device. Next pci_fixup_video(intel) sees that it is the default
device, sets the IORESOURCE_ROM_SHADOW flag and calls
vga_set_default_device again. And finally (if the check is removed)
pci_fixup_video(nvidia) sees that it owns the framebuffer and sets
itself as the default device which allows the system to boot again.

Does setting the ROM_SHADOW flag on (possibly) the wrong device have
any effect? Maybe we should also move this whole detection logic to
some earlier stage to make sure that the default device is correct
from the beginning and doesn't change?


>
>> ---
>>
>> Changes since v1:
>>   Added Tested-by, Cc
>>
>>  arch/ia64/pci/fixup.c   | 21 +
>>  arch/x86/include/asm/vga.h  |  6 --
>>  arch/x86/pci/fixup.c| 21 +
>>  drivers/video/fbdev/efifb.c | 38 --
>>  4 files changed, 42 insertions(+), 44 deletions(-)
>>
>> diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
>> index eee069a..9ed5bef 100644
>> --- a/arch/ia64/pci/fixup.c
>> +++ b/arch/ia64/pci/fixup.c
>> @@ -37,6 +37,27 @@ static void pci_fixup_video(struct pci_dev *pdev)
>>   return;
>>   /* Maybe, this machine supports legacy memory map. */
>>
>> + if (!vga_default_device()) {
>> + resource_size_t start, end;
>> + int i;
>> +
>> + /* Does firmware framebuffer belong to us? */
>> + for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
>> + if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
>> + continue;
>> +
>> + start = pci_resource_start(pdev, i);
>> + end  = pci_resource_end(pdev, i);
>> +
>> + if (!start || !end)
>> + continue;
>> +
>> + if (screen_info.lfb_base >= start &&
>> + (screen_info.lfb_base + screen_info.lfb_size) 
>> < end)
>> + vga_set_default_device(pdev);
>> + }
>> + }
>> +
>>   /* Is VGA routed to us? */
>>   bus = pdev->bus;
>>   while (bus) {
>> diff --git a/arch/x86/include/asm/vga.h b/arch/x86/include/asm/vga.h
>> index 44282fb..c4b9dc2 100644
>> --- a/arch/x86/include/asm/vga.h
>> +++ b/arch/x86/include/asm/vga.h
>> @@ -17,10 +17,4 @@
>>  #define vga_readb(x) (*(x))
>>  #define vga_writeb(x, y) (*(y) = (x))
>>
>> -#ifdef CONFIG_FB_EFI
>> -#define __ARCH_HAS_VGA_DEFAULT_DEVICE
>> -extern struct pci_dev *vga_default_device(void);
>> -extern void vga_set_default_device(struct pci_dev *pdev);
>> -#endif
>> -
>>  #endif /* _ASM_X86_VGA_H */
>> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
>> index 94ae9ae..7246cf2 100644
>> --- a/arch/x86/pci/fixup.c
>> +++