[PATCH 0/7] Consider G2D hardware restrictions.

[Rob Clark]

On Mon, Mar 18, 2013 at 9:32 PM, YoungJun Cho  wrote:
>
> On Mar 19, 2013 9:55 AM, "Rob Clark"  wrote:
>>
>> On Mon, Mar 18, 2013 at 8:00 PM, YoungJun Cho 
>> wrote:
>> >
>> > On Mar 19, 2013 3:01 AM, "Rob Clark"  wrote:
>> >>
>> >> Btw, what is the hw response to invalid input (ie. bottom>top, invalid
>> >> size, etc)?
>> >>
>> >
>> > Unfortunately the IOMMU page fault is happened. So we need some codes
>> > for
>> > protecting kernel.
>>
>> hmm, a page fault is not necessarily a problem.. do you have some way
>> to know which userspace client the the fault is associated with (I
>> assume so, unless you have some way to have multiple contexts active
>> at one time), and some sane way to recover?
>>
>
> When IOMMU page fault is occured, kernel oops is generated now because it is
> unrecoverable.

oh, ouch.. maybe there is someway to reset the 2d core, and move on?
If no, then I guess cmdstream checking is required.  If there is some
way to recover, that seems like a generally good thing to implement..

BR,
-R


>> I only ask this because, for an xorg/exa perspective, you can have a
>> large # of blits that effect a small # of pixels, so minimizing
>> per-blit overhead can be important for performance.  (otoh, if you
>> already have to do some cmdstream checking in the kernel to ensure
>> security, maybe it doesn't add much overhead for a few extra checks.
>> Depends on whether it can all be done in one pass and without
>> additional load (LDR) instructions from the cmdstream buffer (which is
>> presumably not in a cached buffer)
>>
>
> Right, performance is important.
> We already have checked all command lists for buffer addresses security and
> it is done in one pass.
> And this patch gathers additional data for HW restriction during previous
> checking routine.
>
> Thank you
> Best regards YJ
>
>> BR,
>> -R
>>
>> > Thank you~
>> > Best regards YJ
>> >
>> >> Ie. if it will just ignore the blit or raise an error irq which can be
>> >> handled sanely, it could be ok to avoid the overhead of the cmdstream
>> >> checking in the kernel.  The kernel part really just needs to ensure
>> >> that userspace can't cause security problems (read/write access to
>> >> non-gfx-buffers, or lock up the system, that sort of thing).  It
>> >> doesn't need to guarantee that the results are sensible.
>> >>
>> >> BR,
>> >> -R
>> >>
>> >> On Wed, Mar 13, 2013 at 5:03 AM, Inki Dae  wrote:
>> >> > This patch set checks the contents of g2d command list from user
>> >> > is valid or not according to G2D hardware restrictions. For now,
>> >> > G2D driver wasn't considered for them properly.
>> >> >
>> >> > For this, this patch set includes relevant code cleaups, fixups
>> >> > and adds a new function to get buffer size to the gem to be
>> >> > accessed by G2D dma.
>> >> >
>> >> > Inki Dae (1):
>> >> >   drm/exynos: Add a new function to get gem buffer size
>> >> >
>> >> > YoungJun Cho (6):
>> >> >   drm/exynos: Fix error routine to getting dma addr.
>> >> >   drm/exynos: clear node object type at gem unmap
>> >> >   drm/exynos: Fix G2D core mulfunctioning issue
>> >> >   drm/exynos: Clean up some G2D codes for readability
>> >> >   drm/exynos: Deal with g2d buffer info more efficiently
>> >> >   drm/exynos: Check g2d cmd list for g2d restrictions
>> >> >
>> >> >  drivers/gpu/drm/exynos/exynos_drm_g2d.c |  381
>> >> > ++-
>> >> >  drivers/gpu/drm/exynos/exynos_drm_gem.c |   21 ++
>> >> >  drivers/gpu/drm/exynos/exynos_drm_gem.h |5 +
>> >> >  3 files changed, 349 insertions(+), 58 deletions(-)
>> >> >
>> >> > --
>> >> > 1.7.4.1
>> >> >
>> >> > ___
>> >> > dri-devel mailing list
>> >> > dri-devel at lists.freedesktop.org
>> >> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> >> ___
>> >> dri-devel mailing list
>> >> dri-devel at lists.freedesktop.org
>> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] drm-intel-next

[Daniel Vetter]

On Mon, Mar 18, 2013 at 9:59 PM, Daniel Vetter  wrote:
> On Mon, Mar 18, 2013 at 8:35 PM, St?phane Marchesin
>  wrote:
>>
>>> For starters I guess we need:
>>> - drm.debug=0xe dmesg from just before that commit
>>> - same for latest 3.9-rc kernels, presuming it's not broken there
>>>
>>> Latest upstream has a minor chance to work better I think since we've
>>> improved the pfit handling in the setup and teardown sequence a bit.
>>>
>>> Generally lvds has been hit on way too many machines
>>> unfortunately with things randomly breaking and getting fixed again
>>> (e.g. one of Chris' machines works again with the new code ...). And
>>> the commit above doesn't really change much in the code itself but it
>>> does change the order (and timing) of the different enable/disable
>>> codepaths.
>>
>> So I did look at the thing a bit, and it triggers the workaround
>> if (INTEL_INFO(dev)->gen < 4 && !intel_check_plane_mapping(crtc)) {
>> which seems to be part of the problem (but not the whole problem as
>> removing that gets me a corrupted display, looks like the second pipe
>> stays enabled then).
>
> Well, that particular piece of lore took a few trials to get right.
> Can you please attach a drm.debug=0xe dmesg of the entire boot on
> latest kernels?

Also, anything in particular standing out in intel_reg_dump output on
working/broken kernels?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[pull] drm-intel-next

[Daniel Vetter]

On Mon, Mar 18, 2013 at 8:35 PM, St?phane Marchesin
 wrote:
>
>> For starters I guess we need:
>> - drm.debug=0xe dmesg from just before that commit
>> - same for latest 3.9-rc kernels, presuming it's not broken there
>>
>> Latest upstream has a minor chance to work better I think since we've
>> improved the pfit handling in the setup and teardown sequence a bit.
>>
>> Generally lvds has been hit on way too many machines
>> unfortunately with things randomly breaking and getting fixed again
>> (e.g. one of Chris' machines works again with the new code ...). And
>> the commit above doesn't really change much in the code itself but it
>> does change the order (and timing) of the different enable/disable
>> codepaths.
>
> So I did look at the thing a bit, and it triggers the workaround
> if (INTEL_INFO(dev)->gen < 4 && !intel_check_plane_mapping(crtc)) {
> which seems to be part of the problem (but not the whole problem as
> removing that gets me a corrupted display, looks like the second pipe
> stays enabled then).

Well, that particular piece of lore took a few trials to get right.
Can you please attach a drm.debug=0xe dmesg of the entire boot on
latest kernels?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 0/7] Consider G2D hardware restrictions.

[Rob Clark]

On Mon, Mar 18, 2013 at 8:00 PM, YoungJun Cho  wrote:
>
> On Mar 19, 2013 3:01 AM, "Rob Clark"  wrote:
>>
>> Btw, what is the hw response to invalid input (ie. bottom>top, invalid
>> size, etc)?
>>
>
> Unfortunately the IOMMU page fault is happened. So we need some codes for
> protecting kernel.

hmm, a page fault is not necessarily a problem.. do you have some way
to know which userspace client the the fault is associated with (I
assume so, unless you have some way to have multiple contexts active
at one time), and some sane way to recover?

I only ask this because, for an xorg/exa perspective, you can have a
large # of blits that effect a small # of pixels, so minimizing
per-blit overhead can be important for performance.  (otoh, if you
already have to do some cmdstream checking in the kernel to ensure
security, maybe it doesn't add much overhead for a few extra checks.
Depends on whether it can all be done in one pass and without
additional load (LDR) instructions from the cmdstream buffer (which is
presumably not in a cached buffer)

BR,
-R

> Thank you~
> Best regards YJ
>
>> Ie. if it will just ignore the blit or raise an error irq which can be
>> handled sanely, it could be ok to avoid the overhead of the cmdstream
>> checking in the kernel.  The kernel part really just needs to ensure
>> that userspace can't cause security problems (read/write access to
>> non-gfx-buffers, or lock up the system, that sort of thing).  It
>> doesn't need to guarantee that the results are sensible.
>>
>> BR,
>> -R
>>
>> On Wed, Mar 13, 2013 at 5:03 AM, Inki Dae  wrote:
>> > This patch set checks the contents of g2d command list from user
>> > is valid or not according to G2D hardware restrictions. For now,
>> > G2D driver wasn't considered for them properly.
>> >
>> > For this, this patch set includes relevant code cleaups, fixups
>> > and adds a new function to get buffer size to the gem to be
>> > accessed by G2D dma.
>> >
>> > Inki Dae (1):
>> >   drm/exynos: Add a new function to get gem buffer size
>> >
>> > YoungJun Cho (6):
>> >   drm/exynos: Fix error routine to getting dma addr.
>> >   drm/exynos: clear node object type at gem unmap
>> >   drm/exynos: Fix G2D core mulfunctioning issue
>> >   drm/exynos: Clean up some G2D codes for readability
>> >   drm/exynos: Deal with g2d buffer info more efficiently
>> >   drm/exynos: Check g2d cmd list for g2d restrictions
>> >
>> >  drivers/gpu/drm/exynos/exynos_drm_g2d.c |  381
>> > ++-
>> >  drivers/gpu/drm/exynos/exynos_drm_gem.c |   21 ++
>> >  drivers/gpu/drm/exynos/exynos_drm_gem.h |5 +
>> >  3 files changed, 349 insertions(+), 58 deletions(-)
>> >
>> > --
>> > 1.7.4.1
>> >
>> > ___
>> > dri-devel mailing list
>> > dri-devel at lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Stable kernel 3.8.3 appears to break displayport on intel gen4

[Daniel Vetter]

On Mon, Mar 18, 2013 at 04:59:35PM +0100, Bj?rn Mork wrote:
> Sergio Callegari  writes:
> 
> > This is just a short note to let you know that after installing 3.8.3,
> > display port stopped working on my laptop. Going back to 3.8.2 brought
> > it back to life.
> > This has been tested with the ubuntu mainline kernels that should be
> > vanilla stable kernels. Hope this is not an incorrect report due to
> > something wrong on their side. Laptop is a DELL E6500 with intel gen4
> > integrated graphics (Intel Corporation Mobile 4 Series Chipset
> > Integrated Graphics Controller (rev 07)).
> > With 3.8.3, xrandr does not report anymore the external monitor when
> > it is actually attached via displayport.
> 
> I can confirm seeing this bug on:
> 
> # lspci -nnvvvs 00:02.0
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series 
> Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA 
> controller])
> Subsystem: Lenovo Device [17aa:20e4]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> SERR-  Latency: 0
> Interrupt: pin A routed to IRQ 45
> Region 0: Memory at f000 (64-bit, non-prefetchable) [size=4M]
> Region 2: Memory at d000 (64-bit, prefetchable) [size=256M]
> Region 4: I/O ports at 1800 [size=8]
> Expansion ROM at  [disabled]
> Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
> Address: fee0300c  Data: 4152
> Capabilities: [d0] Power Management version 3
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Kernel driver in use: i915
> 
> 
> 
> Looking through the changes from v3.8.2 to v3.8.3, there weren't really
> that many suspects.  This partial (to avoid having to change any
> following patches) revert of commit 2a98104 ("drm/i915: reorder setup
> sequence to have irqs for output setup") fixes the problem for me.  I
> have no idea why, so I leave it to Daniel and the other wise men working
> on this driver to explain and cleanup :)

Already taken care of hopefully:

http://lists.freedesktop.org/archives/intel-gfx/2013-March/025767.html

My apologies to everyone who's suffering through this breakage, it looks
like I've managed to serious burn myself with an innocent looking stable
backport :(

Yours, Daniel

> 
> 
> ---
>  drivers/gpu/drm/i915/i915_dma.c |   14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 5206f24..b15b65d 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1297,21 +1297,19 @@ static int i915_load_modeset_init(struct drm_device 
> *dev)
>   if (ret)
>   goto cleanup_vga_switcheroo;
>  
> - ret = drm_irq_install(dev);
> - if (ret)
> - goto cleanup_gem_stolen;
> -
> - /* Important: The output setup functions called by modeset_init need
> -  * working irqs for e.g. gmbus and dp aux transfers. */
>   intel_modeset_init(dev);
>  
>   ret = i915_gem_init(dev);
>   if (ret)
> - goto cleanup_irq;
> + goto cleanup_gem_stolen;
> +
> + intel_modeset_gem_init(dev);
>  
>   INIT_WORK(_priv->console_resume_work, intel_console_resume);
>  
> - intel_modeset_gem_init(dev);
> + ret = drm_irq_install(dev);
> + if (ret)
> + goto cleanup_gem;
>  
>   /* Always safe in the mode setting case. */
>   /* FIXME: do pre/post-mode set stuff in core KMS code */
> 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses))

[Daniel Vetter]

On Mon, Mar 18, 2013 at 04:56:02PM +0100, Jiri Kosina wrote:
> Okay, so I think that for 3.9 we want the patch below, and if eventually 
> hardware root cause / workaround is found for GM45, we can have it merged 
> later.

I'd prefer if we dig into this for a bit more. I've been traveling last
week and only just now recovered from the mail backlog, hence my delays in
handling this.

Also the "nobody cared" showing up only very late after the last gmbus
transaction isn't too surprising: It only fires after 100k interrupts, and
apparently the irq handler is already a bit racy, so any interrupt might
push it over the edge. gmbus interrupts are apparently just help to expose
the race (presuming it's indeed the msi race already docuemented in the
code).
-Daniel

> From: Jiri Kosina 
> Subject: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips
> 
> Commit 28c70f162 ("drm/i915: use the gmbus irq for waits") switched to
> using GMBUS irqs instead of GPIO bit-banging for chipset generations 4
> and above.
> 
> It turns out though that on many systems this leads to spurious interrupts
> being generated, long after the register write to disable the IRQs has been
> issued.
> 
> Flushing of the register writes by POSTING_READ() directly after the register
> write doesn't work either.
> 
> Disable using of GMBUS IRQs on Gen4 systems before the root cause is found and
> revert back to old behavior.
> 
> Also be more careful about not issuing GMBUS4 register reads in 
> gmbus_wait_hw_status() if we are not using GMBUS IRQs.
> 
> Signed-off-by: Jiri Kosina 
> ---
>  drivers/gpu/drm/i915/intel_i2c.c |   12 ++--
>  1 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
> b/drivers/gpu/drm/i915/intel_i2c.c
> index acf8aec..8638036 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -58,12 +58,14 @@ to_intel_gmbus(struct i2c_adapter *i2c)
>   return container_of(i2c, struct intel_gmbus, adapter);
>  }
>  
> +#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
>  void
>  intel_i2c_reset(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   I915_WRITE(dev_priv->gpio_mmio_base + GMBUS0, 0);
> - I915_WRITE(dev_priv->gpio_mmio_base + GMBUS4, 0);
> + if (HAS_GMBUS_IRQ(dev))
> + I915_WRITE(dev_priv->gpio_mmio_base + GMBUS4, 0);
>  }
>  
>  static void intel_i2c_quirk_set(struct drm_i915_private *dev_priv, bool 
> enable)
> @@ -203,7 +205,6 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
>   algo->data = bus;
>  }
>  
> -#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 4)
>  static int
>  gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
>u32 gmbus2_status,
> @@ -214,6 +215,13 @@ gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
>   u32 gmbus2 = 0;
>   DEFINE_WAIT(wait);
>  
> + if (!HAS_GMBUS_IRQ(dev_priv->dev)) {
> + int ret;
> + ret = wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset)) &
> + (GMBUS_SATOER | gmbus2_status),
> + 50);
> + return ret;
> + }
>   /* Important: The hw handles only the first bit, so set only one! Since
>* we also need to check for NAKs besides the hw ready/idle signal, we
>* need to wake up periodically and check that ourselves. */
> 
> -- 
> Jiri Kosina
> SUSE Labs

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Daniel Vetter]

On Mon, Mar 18, 2013 at 10:12:49AM +0100, Jiri Kosina wrote:
> On Fri, 15 Mar 2013, Yinghai Lu wrote:
> 
> > > Just a datapoint -- I have put a trivial debugging patch in place, and it
> > > reveals that "nobody cared" for irq 16 happens long after last
> > >
> > > I915_WRITE(GMBUS4 + reg_offset, 0);
> > >
> > > has been performed in gmbus_wait_hw_status(). On the other hand, if I
> > > comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(),
> > > then it of course falls back to GPIO bit-banging, but the "nobody cared"
> > > for irq 16 is gone.
> > >
> > > So it seems like something gets severely confused by the I915_WRITE to
> > > GMBUS4 + reg_offset. So far this seems to have been reported solely on
> > > Lenovos as far as I can see (although a completely different types), so it
> > > might be some platform-specific quirk?
> > >
> > > Honestly, I still don't understand how all the GMBUS stuff relates to IRQ
> > > 16 at all.
> > 
> > that device is using
> > i915 :00:02.0: irq 44 for MSI/MSI-X
> > 
> > so can you try to boot with pci=nomsi?
> 
> Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost 
> interrupts go away.
> 
> My understanding from the other mail is that DAniel Vetter already has an 
> idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully 
> this datapoint regarding MSI will fit into it.

Yep, there's a big comment in the irq handler for that chipset that we
have a gaping race with when using MSI interrupts. Although the comment
bodly claims that the race is small enough to avoid the dreaded "nobody
cared" message. Looks like gmbus is good at hitting that race - on newer
chips it already brought up a similar race in handling pch interrupts.

Can you please give the below patch a whirl? It removes the probably race
msi race avoidance code and replaces it with the same trick Paulo used to
fix pch irq handling races.

Thanks, Daniel
---
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3c7bb04..13de12e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2684,7 +2684,7 @@ static irqreturn_t i965_irq_handler(int irq, void *arg)
 {
struct drm_device *dev = (struct drm_device *) arg;
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private;
-   u32 iir, new_iir;
+   u32 iir, new_iir, ier;
u32 pipe_stats[I915_MAX_PIPES];
unsigned long irqflags;
int irq_received;
@@ -2692,9 +2692,14 @@ static irqreturn_t i965_irq_handler(int irq, void *arg)

atomic_inc(_priv->irq_received);

+   /* irq race avoidance, copy from Paulo's PCH irq fix */
+   ier = I915_READ(IER);
+   I915_WRITE(IER, 0);
+   POSTING_READ(IER);
+
iir = I915_READ(IIR);

-   for (;;) {
+   do {
bool blc_event = false;

irq_received = iir != 0;
@@ -2792,7 +2797,10 @@ static irqreturn_t i965_irq_handler(int irq, void *arg)
 * stray interrupts.
 */
iir = new_iir;
-   }
+   } while (0);
+
+   I915_WRITE(IER, ier);
+   POSTING_READ(IER);

i915_update_dri1_breadcrumb(dev);

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Chris Wilson]

On Mon, Mar 18, 2013 at 08:19:03PM +0100, Daniel Vetter wrote:
> On Mon, Mar 18, 2013 at 10:12:49AM +0100, Jiri Kosina wrote:
> > On Fri, 15 Mar 2013, Yinghai Lu wrote:
> > 
> > > > Just a datapoint -- I have put a trivial debugging patch in place, and 
> > > > it
> > > > reveals that "nobody cared" for irq 16 happens long after last
> > > >
> > > > I915_WRITE(GMBUS4 + reg_offset, 0);
> > > >
> > > > has been performed in gmbus_wait_hw_status(). On the other hand, if I
> > > > comment out both GMBUS4 register offset writes in 
> > > > gmbus_wait_hw_status(),
> > > > then it of course falls back to GPIO bit-banging, but the "nobody cared"
> > > > for irq 16 is gone.
> > > >
> > > > So it seems like something gets severely confused by the I915_WRITE to
> > > > GMBUS4 + reg_offset. So far this seems to have been reported solely on
> > > > Lenovos as far as I can see (although a completely different types), so 
> > > > it
> > > > might be some platform-specific quirk?
> > > >
> > > > Honestly, I still don't understand how all the GMBUS stuff relates to 
> > > > IRQ
> > > > 16 at all.
> > > 
> > > that device is using
> > > i915 :00:02.0: irq 44 for MSI/MSI-X
> > > 
> > > so can you try to boot with pci=nomsi?
> > 
> > Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost 
> > interrupts go away.
> > 
> > My understanding from the other mail is that DAniel Vetter already has an 
> > idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully 
> > this datapoint regarding MSI will fit into it.
> 
> Yep, there's a big comment in the irq handler for that chipset that we
> have a gaping race with when using MSI interrupts. Although the comment
> bodly claims that the race is small enough to avoid the dreaded "nobody
> cared" message. Looks like gmbus is good at hitting that race - on newer
> chips it already brought up a similar race in handling pch interrupts.
> 
> Can you please give the below patch a whirl? It removes the probably race
> msi race avoidance code and replaces it with the same trick Paulo used to
> fix pch irq handling races.

Still nobody cares about irq16.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 62434] [bisected] 3284.073] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libllvmradeon9.2.0.so: undefined symbol: lp_build_tgsi_intrinsic)

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

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

--- Comment #14 from LoneVVolf  ---
Trying to summarize

I've looked a bit more at bug #59238, and if i understand correctly the problem
with building xa tracker was that symbols were exported that are not supposed
to be visible outside of the library itself ?

By adding the VISIBILITY_CFLAGS and VISIBILITY_CXXFLAGS changes in the f70c385
commit, the troublesome symbols were removed.
A consequence however was that symbols needed for r600_dri.so to call
libllvmradeon9.2.0.so were no longer present.

Including $(top_builddir)/src/gallium/auxiliary/libgallium.la in
src/gallium/drivers/radeon/Makefile.am makes sure all needed symbols are
present, but has a size increase of libllvmradeon9.2.0 as downside.

To counter the size increase, switching to a shared libgallium is proposed.

-- 
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/20130318/64665c95/attachment.html>

[PATCH] mgag200: fix g200eh pll picking code

[Dave Airlie]

From: Dave Airlie 

This aligns this code more carefully with what is in the upstream X.org MGA
driver.

The freq is a typo, and other changes ports from the same function in the
X.org driver.

Cc: stable at vger.kernel.org
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/mgag200/mgag200_mode.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index a274b99..4d813bb 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -382,12 +382,12 @@ static int mga_g200eh_set_plls(struct mga_device *mdev, 
long clock)
m = n = p = 0;
vcomax = 80;
vcomin = 40;
-   pllreffreq = ;
+   pllreffreq = 3;

delta = 0x;
permitteddelta = clock * 5 / 1000;

-   for (testp = 16; testp > 0; testp--) {
+   for (testp = 16; testp > 0; testp >>= 1) {
if (clock * testp > vcomax)
continue;
if (clock * testp < vcomin)
@@ -404,7 +404,7 @@ static int mga_g200eh_set_plls(struct mga_device *mdev, 
long clock)
if (tmpdelta < delta) {
delta = tmpdelta;
n = testn - 1;
-   m = (testm - 1) | ((n >> 1) & 0x80);
+   m = testm - 1;
p = testp - 1;
}
if ((clock * testp) >= 60)
-- 
1.8.1.2

[Bug 62434] [bisected] 3284.073] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libllvmradeon9.2.0.so: undefined symbol: lp_build_tgsi_intrinsic)

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

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

--- Comment #13 from Fabio Pedretti  ---
Ubuntu is providing a shared libgallium, the patches are here:
http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/mesa.git;a=tree;f=debian/patches;hb=refs/heads/ubuntu%2B1

-- 
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/20130318/1b54a4a9/attachment.html>

[PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses))

[Chris Wilson]

On Mon, Mar 18, 2013 at 04:56:02PM +0100, Jiri Kosina wrote:
> Okay, so I think that for 3.9 we want the patch below, and if eventually 
> hardware root cause / workaround is found for GM45, we can have it merged 
> later.
> 
> 
> 
> From: Jiri Kosina 
> Subject: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips
> 
> Commit 28c70f162 ("drm/i915: use the gmbus irq for waits") switched to
> using GMBUS irqs instead of GPIO bit-banging for chipset generations 4
> and above.
> 
> It turns out though that on many systems this leads to spurious interrupts
> being generated, long after the register write to disable the IRQs has been
> issued.
> 
> Flushing of the register writes by POSTING_READ() directly after the register
> write doesn't work either.
> 
> Disable using of GMBUS IRQs on Gen4 systems before the root cause is found and
> revert back to old behavior.
> 
> Also be more careful about not issuing GMBUS4 register reads in 
> gmbus_wait_hw_status() if we are not using GMBUS IRQs.
> 
> Signed-off-by: Jiri Kosina 
> ---
>  drivers/gpu/drm/i915/intel_i2c.c |   12 ++--
>  1 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
> b/drivers/gpu/drm/i915/intel_i2c.c
> index acf8aec..8638036 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -58,12 +58,14 @@ to_intel_gmbus(struct i2c_adapter *i2c)
>   return container_of(i2c, struct intel_gmbus, adapter);
>  }
>  
> +#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
>  void
>  intel_i2c_reset(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   I915_WRITE(dev_priv->gpio_mmio_base + GMBUS0, 0);
> - I915_WRITE(dev_priv->gpio_mmio_base + GMBUS4, 0);
> + if (HAS_GMBUS_IRQ(dev))
> + I915_WRITE(dev_priv->gpio_mmio_base + GMBUS4, 0);

There should not be any harm in always clearing GMBUS4, it exists on all
platforms.

>  }
>  
>  static void intel_i2c_quirk_set(struct drm_i915_private *dev_priv, bool 
> enable)
> @@ -203,7 +205,6 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
>   algo->data = bus;
>  }
>  
> -#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 4)
>  static int
>  gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
>u32 gmbus2_status,
> @@ -214,6 +215,13 @@ gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
>   u32 gmbus2 = 0;
>   DEFINE_WAIT(wait);
>  
> + if (!HAS_GMBUS_IRQ(dev_priv->dev)) {
> + int ret;
> + ret = wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset)) &
> + (GMBUS_SATOER | gmbus2_status),
> + 50);

This should couple up to the normal return code that chooses the
appropriate return value based on gmbus2.

How about just using:
  if (!HAS_GMBUS_IRQ(dev_priv->dev)) gmbus4_irq_en = 0;
and the existing wait loop?

> + return ret;
> + }
>   /* Important: The hw handles only the first bit, so set only one! Since
>* we also need to check for NAKs besides the hw ready/idle signal, we
>* need to wake up periodically and check that ourselves. */

-- 
Chris Wilson, Intel Open Source Technology Centre

Stable kernel 3.8.3 appears to break displayport on intel gen4

[Bjørn Mork]

Sergio Callegari  writes:

> This is just a short note to let you know that after installing 3.8.3,
> display port stopped working on my laptop. Going back to 3.8.2 brought
> it back to life.
> This has been tested with the ubuntu mainline kernels that should be
> vanilla stable kernels. Hope this is not an incorrect report due to
> something wrong on their side. Laptop is a DELL E6500 with intel gen4
> integrated graphics (Intel Corporation Mobile 4 Series Chipset
> Integrated Graphics Controller (rev 07)).
> With 3.8.3, xrandr does not report anymore the external monitor when
> it is actually attached via displayport.

I can confirm seeing this bug on:

# lspci -nnvvvs 00:02.0
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series 
Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA 
controller])
Subsystem: Lenovo Device [17aa:20e4]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-  [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c  Data: 4152
Capabilities: [d0] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: i915



Looking through the changes from v3.8.2 to v3.8.3, there weren't really
that many suspects.  This partial (to avoid having to change any
following patches) revert of commit 2a98104 ("drm/i915: reorder setup
sequence to have irqs for output setup") fixes the problem for me.  I
have no idea why, so I leave it to Daniel and the other wise men working
on this driver to explain and cleanup :)


---
 drivers/gpu/drm/i915/i915_dma.c |   14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5206f24..b15b65d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1297,21 +1297,19 @@ static int i915_load_modeset_init(struct drm_device 
*dev)
if (ret)
goto cleanup_vga_switcheroo;

-   ret = drm_irq_install(dev);
-   if (ret)
-   goto cleanup_gem_stolen;
-
-   /* Important: The output setup functions called by modeset_init need
-* working irqs for e.g. gmbus and dp aux transfers. */
intel_modeset_init(dev);

ret = i915_gem_init(dev);
if (ret)
-   goto cleanup_irq;
+   goto cleanup_gem_stolen;
+
+   intel_modeset_gem_init(dev);

INIT_WORK(_priv->console_resume_work, intel_console_resume);

-   intel_modeset_gem_init(dev);
+   ret = drm_irq_install(dev);
+   if (ret)
+   goto cleanup_gem;

/* Always safe in the mode setting case. */
/* FIXME: do pre/post-mode set stuff in core KMS code */

[PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses))

[Jiri Kosina]

Okay, so I think that for 3.9 we want the patch below, and if eventually 
hardware root cause / workaround is found for GM45, we can have it merged 
later.



From: Jiri Kosina 
Subject: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips

Commit 28c70f162 ("drm/i915: use the gmbus irq for waits") switched to
using GMBUS irqs instead of GPIO bit-banging for chipset generations 4
and above.

It turns out though that on many systems this leads to spurious interrupts
being generated, long after the register write to disable the IRQs has been
issued.

Flushing of the register writes by POSTING_READ() directly after the register
write doesn't work either.

Disable using of GMBUS IRQs on Gen4 systems before the root cause is found and
revert back to old behavior.

Also be more careful about not issuing GMBUS4 register reads in 
gmbus_wait_hw_status() if we are not using GMBUS IRQs.

Signed-off-by: Jiri Kosina 
---
 drivers/gpu/drm/i915/intel_i2c.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index acf8aec..8638036 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -58,12 +58,14 @@ to_intel_gmbus(struct i2c_adapter *i2c)
return container_of(i2c, struct intel_gmbus, adapter);
 }

+#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
 void
 intel_i2c_reset(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
I915_WRITE(dev_priv->gpio_mmio_base + GMBUS0, 0);
-   I915_WRITE(dev_priv->gpio_mmio_base + GMBUS4, 0);
+   if (HAS_GMBUS_IRQ(dev))
+   I915_WRITE(dev_priv->gpio_mmio_base + GMBUS4, 0);
 }

 static void intel_i2c_quirk_set(struct drm_i915_private *dev_priv, bool enable)
@@ -203,7 +205,6 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
algo->data = bus;
 }

-#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 4)
 static int
 gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
 u32 gmbus2_status,
@@ -214,6 +215,13 @@ gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
u32 gmbus2 = 0;
DEFINE_WAIT(wait);

+   if (!HAS_GMBUS_IRQ(dev_priv->dev)) {
+   int ret;
+   ret = wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset)) &
+   (GMBUS_SATOER | gmbus2_status),
+   50);
+   return ret;
+   }
/* Important: The hw handles only the first bit, so set only one! Since
 * we also need to check for NAKs besides the hw ready/idle signal, we
 * need to wake up periodically and check that ourselves. */

-- 
Jiri Kosina
SUSE Labs

How to manage OMAP display drivers in the future

[Rob Clark]

On Wed, Mar 13, 2013 at 4:57 AM, Tomi Valkeinen  wrote:
> Hi Dave,
>
> I'm writing this mail to get some ideas how we should manage OMAP's
> display drivers in the future.
>
> As a short intro, we have the following players around:
>
> omapdss - omapdss handles the DSS (display subsystem) hardware. omapdss
> doesn't do any buffer management or expose any userspace API (except a
> few sysfs files), so it doesn't do anything by itself.
> (drivers/video/omap2/dss/)
>
> panel drivers - Drivers for various panel models. The panel drivers use
> omapdss API to manage the video bus. (drivers/video/omap2/displays/)
>
> omapfb - Framebuffer driver, uses omapdss to handle the HW.
> (drivers/video/omap2/omapfb/)
>
> omap_vout - V4L2 driver for showing video, uses omapdss to handle the
> HW. (drivers/media/platform/omap/)
>
> omapdrm - DRM driver, uses omapdss to handle the HW.
> (drivers/gpu/drm/omapdrm/)
>
> omapdss and the panel drivers form the lowest level layer. omapfb and
> omap_vout can be used at the same time, but omapdrm must be used alone,
> without omapfb or omap_vout.
>
> omapfb and omap_vout are not much developed anymore, even though they
> are still commonly used. Most of the development happens in omapdss,
> panel drivers and omapdrm.

I'd guess if changes in omapfb or omap_vout are mainly just updates
resulting from omapdss changes, maybe merging it all via drm tree
would make most sense..

Although I tend to think life would be easier w/ some copy/paste.. Ie.
just move a copy of omapdss into omapdrm directory and start
refactoring.. Offhand I think at least in the hdmi code, I think we
could jettison the big timings table, and avi-infoframe stuff and use
drm helpers.  Probably other places where we could get rid of code
that duplicates stuff that drm does (or could) provide helpers for..

BR,
-R

> So that's what we have now. In the distant future I see omapfb and
> omap_vout disappear totally, the panel drivers would be made generic
> using Common Display Framework, and omapdss and omapdrm would more or
> less be merged together. However, all that is still far away, and we
> need some plan to go forward for now.
>
> Most pressing question is how to get OMAP display patches merged. It
> seems that there's not really an fbdev maintainer for the time being,
> and fbdev tree has been the route for omapdss, panels and omapfb in the
> past. Now that omapdrm is the new main driver for omap display, fbdev
> would be somewhat wrong in any case.
>
> Dave, how would you feel about merging changes to all the above
> components through DRM tree? Merging all the above together would be the
> easiest way, as the changes may have dependencies to each other.
>
> As I said, most of the development should be in omapdss, panels and
> omapdrm. There would be an occasional fix for omapfb and omap_vout, or
> small changes when omapdss changes require changes elsewhere.
>
>  Tomi

Revert a bunch of patches in stable kernels

[Daniel Vetter]

On Mon, Mar 18, 2013 at 11:05 AM, Daniel Vetter  
wrote:
> Hi Greg,
>
> So a recent stable backport to fix rc6 on ilk (which is disabled by
> default and with dubious power savings at best, unlike rc6 on snb and
> later) totally blew up all over the place:
> https://bugzilla.kernel.org/show_bug.cgi?id=55291
> https://lkml.org/lkml/2013/3/14/540

This likely also is the culprit behind the ghost vga issues reported
on gm45, e.g:

https://bugzilla.redhat.com/show_bug.cgi?id=922304

Again, fixed in 3.9-rc kernels by

commit 20afbda209d708be66944907966486d0c1331cb8
Author: Daniel Vetter 
Date:   Tue Dec 11 14:05:07 2012 +0100

drm/i915: Fixup hpd irq register setup ordering

Cheers, Daniel

> There might be more, I'm still recovering from mail floods due to
> traveling last week. I think the right course of action is to revert
> the offending patch (plus anything depending upon it) and give up on
> rc6 on ilk in 3.8 - too messy. All bug reports confirmed that 3.9-rc
> kernels work as expected. Upstream commits to revert:
>
> 15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9 drm/i915: enable irqs earlier
> when resuming
> 52d7ecedac3f96fb562cb482c139015372728638 drm/i915: reorder setup
> sequence to have irqs for output setup
>
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 60407] [configure.ac] allow tests programs to be installed

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

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

Benjamin Gaignard  changed:

   What|Removed |Added

Version|unspecified |XOrg CVS

-- 
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/20130318/9d252e5d/attachment.html>

[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Yinghai Lu]

On Mon, Mar 18, 2013 at 3:05 PM, Jiri Kosina  wrote:
> On Mon, 18 Mar 2013, Yinghai Lu wrote:
>
>> > Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost
>> > interrupts go away.
>> >
>> > My understanding from the other mail is that DAniel Vetter already has an
>> > idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully
>> > this datapoint regarding MSI will fit into it.
>>
>> What is /proc/interrupts difference between with and without pci=nomsi ?
>>
>> drm is forced to share irq 16?
>
> Yup, IRQ 16 is being shared, and one of the owners is i915.

the vga report strange INTx status...

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA
controller])
Subsystem: Lenovo Device 20e4
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
SERR-  [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0100c  Data: 4142
Capabilities: [d0] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: i915
Kernel modules: i915

it should be INTx-, after we have set DisINTx+ in control.

So INTx can not be disabled after it get enabled before ?

the VGA on my T420 looks right.

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
Core Processor Family Integrated Graphics Controller (rev 09) (prog-if
00 [VGA controller])
Subsystem: Lenovo Device 21ce
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
SERR- 

[Bug 62434] [bisected] 3284.073] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libllvmradeon9.2.0.so: undefined symbol: lp_build_tgsi_intrinsic)

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

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

--- Comment #12 from Maarten Lankhorst  ---
Reverting the gallium fix would reopen bug #59238

-- 
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/20130318/409b7b61/attachment.html>

[PATCH] vesa: Prevent loading if we conflict with a previously loaded driver

[Chris Wilson]

vesa is presumed to be the generic hardware agnostic fallback framebuffer
driver for standard VGA that conflicts with the real drivers. Those
drivers already check and remove vesafb if it is previously loaded, but
in the reverse case where vesafb is loaded afterwards, the VESA driver
will proceed to clobber hardware state and corrupt the displays.

References: 
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1156077
Signed-off-by: Chris Wilson 
---
 drivers/video/fbmem.c  |   31 +++
 drivers/video/vesafb.c |   22 ++
 include/linux/fb.h |2 ++
 3 files changed, 55 insertions(+)

diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 7c25408..786cec8 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1722,6 +1722,37 @@ void remove_conflicting_framebuffers(struct 
apertures_struct *a,
 }
 EXPORT_SYMBOL(remove_conflicting_framebuffers);

+bool has_conflicting_framebuffer(struct apertures_struct *a, bool primary)
+{
+   bool ret = false;
+   int i;
+
+   mutex_lock(_lock);
+
+   for (i = 0 ; i < FB_MAX; i++) {
+   struct apertures_struct *gen_aper;
+
+   if (!registered_fb[i])
+   continue;
+
+   if (!(registered_fb[i]->flags & FBINFO_MISC_FIRMWARE))
+   continue;
+
+   gen_aper = registered_fb[i]->apertures;
+   if (fb_do_apertures_overlap(gen_aper, a) ||
+   (primary && gen_aper && gen_aper->count &&
+gen_aper->ranges[0].base == VGA_FB_PHYS)) {
+   ret = true;
+   break;
+   }
+   }
+
+   mutex_unlock(_lock);
+
+   return ret;
+}
+EXPORT_SYMBOL(has_conflicting_framebuffer);
+
 /**
  * register_framebuffer - registers a frame buffer device
  * @fb_info: frame buffer info structure
diff --git a/drivers/video/vesafb.c b/drivers/video/vesafb.c
index 501b340..51adc4c1 100644
--- a/drivers/video/vesafb.c
+++ b/drivers/video/vesafb.c
@@ -226,6 +226,25 @@ static int __init vesafb_setup(char *options)
return 0;
 }

+static bool aperture_already_claimed(void)
+{
+   struct apertures_struct *ap;
+   bool ret;
+
+   ap = alloc_apertures(1);
+   if (!ap)
+   return true;
+
+   ap->ranges[0].base = screen_info.lfb_base;
+   ap->ranges[0].size = size_total;
+
+   ret = has_conflicting_framebuffer(ap, true);
+
+   kfree(ap);
+
+   return ret;
+}
+
 static int __init vesafb_probe(struct platform_device *dev)
 {
struct fb_info *info;
@@ -237,6 +256,9 @@ static int __init vesafb_probe(struct platform_device *dev)
if (screen_info.orig_video_isVGA != VIDEO_TYPE_VLFB)
return -ENODEV;

+   if (aperture_already_claimed())
+   return -ENODEV;
+
vga_compat = (screen_info.capabilities & 2) ? 0 : 1;
vesafb_fix.smem_start = screen_info.lfb_base;
vesafb_defined.bits_per_pixel = screen_info.lfb_depth;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 58b9860..7dfd964 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -611,6 +611,8 @@ extern ssize_t fb_sys_write(struct fb_info *info, const 
char __user *buf,
 extern int register_framebuffer(struct fb_info *fb_info);
 extern int unregister_framebuffer(struct fb_info *fb_info);
 extern int unlink_framebuffer(struct fb_info *fb_info);
+extern bool has_conflicting_framebuffer(struct apertures_struct *a,
+   bool primary);
 extern void remove_conflicting_framebuffers(struct apertures_struct *a,
const char *name, bool primary);
 extern int fb_prepare_logo(struct fb_info *fb_info, int rotate);
-- 
1.7.10.4

[PATCH 5/5] videomode: rename fields

[Tomi Valkeinen]

On 2013-03-18 10:00, Daniel Vetter wrote:
> On Tue, Mar 12, 2013 at 03:40:14PM +0200, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 2013-03-12 15:37, Laurent Pinchart wrote:
>>> Hi Tomi,
>>>
>>> Thanks for the patch.
>>>
>>> On Tuesday 12 March 2013 12:19:38 Tomi Valkeinen wrote:
>>>> Structs videomode and display_timing have rather long field names for
>>>> the timing values. Nothing wrong with that as such, but this patch
>>>> changes them to abbreviations for the following reasons:
>>>>
>>>> * The timing values often need to be used in calculations, and long
>>>>   field names makes their direct use clumsier.
>>>>
>>>> * The current names are a bit of a mishmash: some words are used as
>>>>   such, some are shortened, and for some only first letter is used. Some
>>>>   names use underscode, some don't. All this makes it difficult to
>>>>   remember what the field names are.
>>>>
>>>> * The abbreviations used in this patch are very common, and there
>>>>   shouldn't be any misunderstanding about their meaning.
>>>>
>>>> Signed-off-by: Tomi Valkeinen 
>>>> Cc: Steffen Trumtrar 
>>>> ---
>>>
>>> I have no strong opinion on this, but I find the existing names easier to 
>>> read. I might be biased by having read them often though.
>>
>> Yes, the last patch was a bit of a "teaser" =). I found myself typoing
>> them a lot, using helper local variables to shorten the code lines, and
>> as I mention in the description, I find them a bit of a mishmash. So,
>> while they're not used in any drivers yet, I thought it'd be worth a
>> shot to change them.
> 
> Imo the new names look quite a bit more ugly and less readable, for very
> few saved chars. And at least for i915.ko development it's been a long
> time since I've last had to type them ... Maybe the real problem is that
> we have a few too many video mode structures and can't properly share
> them?

I guess it's a matter of taste. But I've received three "I don't like
the new names" comments, and no positive comments, so I'm dropping the
last patch. The first four should be fine, though.

And yes, we should definitely try to use only this new videomode struct
in the future everywhere in the kernel. It sure would make me remember
the names better =).

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130318/b7c1a942/attachment.pgp>

[Bug 62434] [bisected] 3284.073] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libllvmradeon9.2.0.so: undefined symbol: lp_build_tgsi_intrinsic)

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

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

--- Comment #11 from Maarten Lankhorst  ---
The fix is correct, despite the size increase.

-- 
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/20130318/fb35ae05/attachment.html>

[PATCH 0/7] Consider G2D hardware restrictions.

[Rob Clark]

Btw, what is the hw response to invalid input (ie. bottom>top, invalid
size, etc)?

Ie. if it will just ignore the blit or raise an error irq which can be
handled sanely, it could be ok to avoid the overhead of the cmdstream
checking in the kernel.  The kernel part really just needs to ensure
that userspace can't cause security problems (read/write access to
non-gfx-buffers, or lock up the system, that sort of thing).  It
doesn't need to guarantee that the results are sensible.

BR,
-R

On Wed, Mar 13, 2013 at 5:03 AM, Inki Dae  wrote:
> This patch set checks the contents of g2d command list from user
> is valid or not according to G2D hardware restrictions. For now,
> G2D driver wasn't considered for them properly.
>
> For this, this patch set includes relevant code cleaups, fixups
> and adds a new function to get buffer size to the gem to be
> accessed by G2D dma.
>
> Inki Dae (1):
>   drm/exynos: Add a new function to get gem buffer size
>
> YoungJun Cho (6):
>   drm/exynos: Fix error routine to getting dma addr.
>   drm/exynos: clear node object type at gem unmap
>   drm/exynos: Fix G2D core mulfunctioning issue
>   drm/exynos: Clean up some G2D codes for readability
>   drm/exynos: Deal with g2d buffer info more efficiently
>   drm/exynos: Check g2d cmd list for g2d restrictions
>
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c |  381 
> ++-
>  drivers/gpu/drm/exynos/exynos_drm_gem.c |   21 ++
>  drivers/gpu/drm/exynos/exynos_drm_gem.h |5 +
>  3 files changed, 349 insertions(+), 58 deletions(-)
>
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62466] r600g hyperz lockups with KSP 0.19

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

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

Alex Deucher  changed:

   What|Removed |Added

Summary|KSP 0.19 causes GPU lockups |r600g hyperz lockups with
   |on r600g|KSP 0.19

-- 
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/20130318/6490febd/attachment.html>

[Bug 62466] KSP 0.19 causes GPU lockups on r600g

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

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

--- Comment #2 from Knut Andre Tidemann  ---
Disabling hyperz does indeed fix the issue. Tried a quick spin for ~15-20 mins
wit no issues now.

With hyperz enabled, I get lockups after a few minutes.

-- 
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/20130318/251ddbba/attachment.html>

Revert a bunch of patches in stable kernels

[Greg KH]

On Mon, Mar 18, 2013 at 11:05:26AM +0100, Daniel Vetter wrote:
> Hi Greg,
> 
> So a recent stable backport to fix rc6 on ilk (which is disabled by
> default and with dubious power savings at best, unlike rc6 on snb and
> later) totally blew up all over the place:
> https://bugzilla.kernel.org/show_bug.cgi?id=55291
> https://lkml.org/lkml/2013/3/14/540
> 
> There might be more, I'm still recovering from mail floods due to
> traveling last week. I think the right course of action is to revert
> the offending patch (plus anything depending upon it) and give up on
> rc6 on ilk in 3.8 - too messy. All bug reports confirmed that 3.9-rc
> kernels work as expected. Upstream commits to revert:
> 
> 15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9 drm/i915: enable irqs earlier
> when resuming
> 52d7ecedac3f96fb562cb482c139015372728638 drm/i915: reorder setup
> sequence to have irqs for output setup

Thanks for tracking this down, I've reverted both of these patches now,
which should hopefully fix the issues reported.

greg k-h

[Bug 62434] [bisected] 3284.073] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libllvmradeon9.2.0.so: undefined symbol: lp_build_tgsi_intrinsic)

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

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

--- Comment #10 from Andreas Boll  ---
(In reply to comment #8)
> (In reply to comment #5)
> > Possible patch
> 
> This seems less than ideal, as it makes libllvmradeon duplicate lots of
> stuff from the driver *.so, and it grows from ~500K to ~10M for me.

Hmm we definitely need a shared libgallium.
That would reduce the size of all gallium drivers.

Or we could remove/revert the visibility flags from
src/gallium/auxiliary/Makefile.am

-- 
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/20130318/41ae6b54/attachment.html>

[Bug 62466] KSP 0.19 causes GPU lockups on r600g

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

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

--- Comment #1 from Alex Deucher  ---
Does disabling hyperz help?  Set env var:
R600_DEBUG=nohyperz

-- 
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/20130318/3923500c/attachment.html>

[Bug 62434] [bisected] 3284.073] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libllvmradeon9.2.0.so: undefined symbol: lp_build_tgsi_intrinsic)

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

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

--- Comment #9 from LoneVVolf  ---
That appears to be correct,
in a git version build on march 11
libllvmradeon9.2.0.so is just 39 Kib .
Build with the patch it's size increases to 1.8 Mib !

-- 
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/20130318/5cc44395/attachment.html>

[pull] drm-intel-next

[Stéphane Marchesin]

-lkml

On Sun, Mar 17, 2013 at 12:46 PM, Daniel Vetter  wrote:
> On Fri, Mar 15, 2013 at 3:11 AM, St?phane Marchesin
>  wrote:
>>>   drm/i915: read out the modeset hw state at load and resume time
>> This commit regresses modeset on the samsung series 5 chromebook (it
>> is basically a pineview machine with an lvds panel). I don't seem to
>> be able to set any mode on it any longer.
>
> Does that mean the kernel refuses to set the mode, or that you get a
> black screen?
>

I get a black screen.

> For starters I guess we need:
> - drm.debug=0xe dmesg from just before that commit
> - same for latest 3.9-rc kernels, presuming it's not broken there
>
> Latest upstream has a minor chance to work better I think since we've
> improved the pfit handling in the setup and teardown sequence a bit.
>
> Generally lvds has been hit on way too many machines
> unfortunately with things randomly breaking and getting fixed again
> (e.g. one of Chris' machines works again with the new code ...). And
> the commit above doesn't really change much in the code itself but it
> does change the order (and timing) of the different enable/disable
> codepaths.

So I did look at the thing a bit, and it triggers the workaround
if (INTEL_INFO(dev)->gen < 4 && !intel_check_plane_mapping(crtc)) {
which seems to be part of the problem (but not the whole problem as
removing that gets me a corrupted display, looks like the second pipe
stays enabled then).

St?phane

[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Yinghai Lu]

On Mon, Mar 18, 2013 at 2:12 AM, Jiri Kosina  wrote:
> On Fri, 15 Mar 2013, Yinghai Lu wrote:
>
>> > Just a datapoint -- I have put a trivial debugging patch in place, and it
>> > reveals that "nobody cared" for irq 16 happens long after last
>> >
>> > I915_WRITE(GMBUS4 + reg_offset, 0);
>> >
>> > has been performed in gmbus_wait_hw_status(). On the other hand, if I
>> > comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(),
>> > then it of course falls back to GPIO bit-banging, but the "nobody cared"
>> > for irq 16 is gone.
>> >
>> > So it seems like something gets severely confused by the I915_WRITE to
>> > GMBUS4 + reg_offset. So far this seems to have been reported solely on
>> > Lenovos as far as I can see (although a completely different types), so it
>> > might be some platform-specific quirk?
>> >
>> > Honestly, I still don't understand how all the GMBUS stuff relates to IRQ
>> > 16 at all.
>>
>> that device is using
>> i915 :00:02.0: irq 44 for MSI/MSI-X
>>
>> so can you try to boot with pci=nomsi?
>
> Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost
> interrupts go away.
>
> My understanding from the other mail is that DAniel Vetter already has an
> idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully
> this datapoint regarding MSI will fit into it.

What is /proc/interrupts difference between with and without pci=nomsi ?

drm is forced to share irq 16?

Thanks

Yinghai

[Bug 62434] [bisected] 3284.073] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libllvmradeon9.2.0.so: undefined symbol: lp_build_tgsi_intrinsic)

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

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

--- Comment #8 from Michel D?nzer  ---
(In reply to comment #5)
> Possible patch

This seems less than ideal, as it makes libllvmradeon duplicate lots of stuff
from the driver *.so, and it grows from ~500K to ~10M 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/20130318/17ea303c/attachment.html>

[Bug 62466] New: KSP 0.19 causes GPU lockups on r600g

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

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

  Priority: medium
Bug ID: 62466
  Assignee: dri-devel at lists.freedesktop.org
   Summary: KSP 0.19 causes GPU lockups on r600g
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: knut.tidemann at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 76678
  --> https://bugs.freedesktop.org/attachment.cgi?id=76678=edit
dmesg output

When trying out Kerbal Space Program for linux (version 0.19 was just released
with native linux support) I get GPU lockups when constructing rockets.

Everything worked well at first, but after a few minutes I got the first GPU
lockup and after that it seem to lock up every 5 seconds or so, so I had to
kill the game.

This happens every time I run the game. MSAA and vsync were not enabled.

I'm running mesa from git: 
Mesa 9.2.0 (git-2da8ee1) on a Radeon HD 5670

and the arch linxu kernel: 
Linux none 3.8.3-2-ARCH #1 SMP PREEMPT Sun Mar 17 13:04:22 CET 2013 x86_64
GNU/Linux

I've attached a full dmesg log.

I'm running KDE and have two monitors set up. The lockups happened both with
and without desktop effects enabled.

-- 
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/20130318/061c4a44/attachment-0001.html>

Revert a bunch of patches in stable kernels

[Daniel Vetter]

Hi Greg,

So a recent stable backport to fix rc6 on ilk (which is disabled by
default and with dubious power savings at best, unlike rc6 on snb and
later) totally blew up all over the place:
https://bugzilla.kernel.org/show_bug.cgi?id=55291
https://lkml.org/lkml/2013/3/14/540

There might be more, I'm still recovering from mail floods due to
traveling last week. I think the right course of action is to revert
the offending patch (plus anything depending upon it) and give up on
rc6 on ilk in 3.8 - too messy. All bug reports confirmed that 3.9-rc
kernels work as expected. Upstream commits to revert:

15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9 drm/i915: enable irqs earlier
when resuming
52d7ecedac3f96fb562cb482c139015372728638 drm/i915: reorder setup
sequence to have irqs for output setup

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm: Destroy property blobs at mode config cleanup time

[Laurent Pinchart]

Hi Daniel,

On Monday 18 March 2013 09:06:21 Daniel Vetter wrote:
> On Tue, Mar 12, 2013 at 03:31:11PM +0100, Laurent Pinchart wrote:
> > Property blob objects need to be destroyed when cleaning up to avoid
> > memory leaks. Go through the list of all blobs in the
> > drm_mode_config_cleanup() function and destroy them.
> > 
> > The drm_mode_config_cleanup() function needs to be moved after the
> > drm_property_destroy_blob() declaration. Move drm_mode_config_init() as
> > well to keep the functions together.
> 
> Imo moving drm_mode_config_init looks a bit superflous in this patch,
> since there's still some other init code left around at the old place.

It's not mandatory indeed, but it's a step in the right direction in my 
opinion. Maybe a separate patch that just moves functions around in drm_crtc.c 
would be a better idea :-)

> Drop that code movement?

I have no strong opinion, I can drop it if that's preferred.

> Otherwise Reviewed-by: Daniel Vetter 

Thank you.

-- 
Regards,

Laurent Pinchart

[PATCH 4/4] drm/mgag200: Bug fix: Modified pll algorithm for EH project

[Julia Lemire]

While testing the mgag200 kms driver on the HP ProLiant Gen8, a
bug was seen.  Once the bootloader would load the selected kernel,
the screen would go black.  At first it was assumed that the
mgag200 kms driver was hanging.  But after setting up the grub
serial output, it was seen that the driver was being loaded
properly.  After trying serval monitors, one finaly displayed
the message "Frequency Out of Range".  By comparing the kms pll
algorithm with the previous mgag200 xorg driver pll algorithm,
discrepencies were found.  Once the kms pll algorithm was
modified, the expected pll values were produced.  This fix was
tested on several monitors of varying native resolutions.

Signed-off-by: Julia Lemire 
---
 drivers/gpu/drm/mgag200/mgag200_mode.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 6b5db83..7337013 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -382,19 +382,19 @@ static int mga_g200eh_set_plls(struct mga_device *mdev, 
long clock)
m = n = p = 0;
vcomax = 80;
vcomin = 40;
-   pllreffreq = ;
+   pllreffreq = 3;

delta = 0x;
permitteddelta = clock * 5 / 1000;

-   for (testp = 16; testp > 0; testp--) {
+   for (testp = 16; testp > 0; testp >>= 1) {
if (clock * testp > vcomax)
continue;
if (clock * testp < vcomin)
continue;

for (testm = 1; testm < 33; testm++) {
-   for (testn = 1; testn < 257; testn++) {
+   for (testn = 17; testn < 257; testn++) {
computed = (pllreffreq * testn) /
(testm * testp);
if (computed > clock)
@@ -404,11 +404,11 @@ static int mga_g200eh_set_plls(struct mga_device *mdev, 
long clock)
if (tmpdelta < delta) {
delta = tmpdelta;
n = testn - 1;
-   m = (testm - 1) | ((n >> 1) & 0x80);
+   m = (testm - 1);
p = testp - 1;
}
if ((clock * testp) >= 60)
-   p |= 80;
+   p |= 0x80;
}
}
}
-- 
1.7.12.4

[PATCH 3/4] drm/mgag200: Remove extra variable assigns

[Christopher Harvey]

These two variables are set again immediately in 'mgag200_modeset_init'

Signed-off-by: Christopher Harvey 
---
 drivers/gpu/drm/mgag200/mgag200_main.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c 
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 64297c7..b762bfb 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -234,8 +234,6 @@ int mgag200_driver_load(struct drm_device *dev, unsigned 
long flags)

drm_mode_config_init(dev);
dev->mode_config.funcs = (void *)_mode_funcs;
-   dev->mode_config.min_width = 0;
-   dev->mode_config.min_height = 0;
dev->mode_config.preferred_depth = 24;
dev->mode_config.prefer_shadow = 1;

-- 
1.7.12.4

[PATCH 2/4] drm/mgag200: Pass driver specific mga_device in driver functions

[Christopher Harvey]

Signed-off-by: Christopher Harvey 
---
 drivers/gpu/drm/mgag200/mgag200_mode.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index a274b99..6b5db83 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1261,9 +1261,8 @@ static const struct drm_crtc_helper_funcs 
mga_helper_funcs = {
 };

 /* CRTC setup */
-static void mga_crtc_init(struct drm_device *dev)
+static void mga_crtc_init(struct mga_device *mdev)
 {
-   struct mga_device *mdev = dev->dev_private;
struct mga_crtc *mga_crtc;
int i;

@@ -1274,7 +1273,7 @@ static void mga_crtc_init(struct drm_device *dev)
if (mga_crtc == NULL)
return;

-   drm_crtc_init(dev, _crtc->base, _crtc_funcs);
+   drm_crtc_init(mdev->dev, _crtc->base, _crtc_funcs);

drm_mode_crtc_set_gamma_size(_crtc->base, MGAG200_LUT_SIZE);
mdev->mode_info.crtc = mga_crtc;
@@ -1529,7 +1528,7 @@ int mgag200_modeset_init(struct mga_device *mdev)

mdev->dev->mode_config.fb_base = mdev->mc.vram_base;

-   mga_crtc_init(mdev->dev);
+   mga_crtc_init(mdev);

encoder = mga_encoder_init(mdev->dev);
if (!encoder) {
-- 
1.7.12.4

[PATCH 1/4] drm/mgag200: Remove pointless call to drm_fb_get_bpp_depth

[Christopher Harvey]

Signed-off-by: Christopher Harvey 
---
 drivers/gpu/drm/mgag200/mgag200_fb.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c 
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index d2253f6..a5a1f34 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
@@ -105,12 +105,9 @@ static int mgag200fb_create_object(struct mga_fbdev 
*afbdev,
   struct drm_gem_object **gobj_p)
 {
struct drm_device *dev = afbdev->helper.dev;
-   u32 bpp, depth;
u32 size;
struct drm_gem_object *gobj;
-
int ret = 0;
-   drm_fb_get_bpp_depth(mode_cmd->pixel_format, , );

size = mode_cmd->pitches[0] * mode_cmd->height;
ret = mgag200_gem_create(dev, size, true, );
-- 
1.7.12.4

[PATCH 0/4] mgag200 fix and cleanup

[Christopher Harvey]

Just a bit of cleanup from me (resubmitted). The important patch comes
from Julia. Julia's patch conflicts with the following:
1363594270-22137-1-git-send-email-airlied at gmail.com

it fixes
https://bugzilla.kernel.org/show_bug.cgi?id=46591

Christopher Harvey (3):
  drm/mgag200: Remove pointless call to drm_fb_get_bpp_depth
  drm/mgag200: Pass driver specific mga_device in driver functions
  drm/mgag200: Remove extra variable assigns

Julia Lemire (1):
  drm/mgag200: Bug fix: Modified pll algorithm for EH project

 drivers/gpu/drm/mgag200/mgag200_fb.c   |  3 ---
 drivers/gpu/drm/mgag200/mgag200_main.c |  2 --
 drivers/gpu/drm/mgag200/mgag200_mode.c | 17 -
 3 files changed, 8 insertions(+), 14 deletions(-)

-- 
1.7.12.4

[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Jiri Kosina]

On Fri, 15 Mar 2013, Yinghai Lu wrote:

> > Just a datapoint -- I have put a trivial debugging patch in place, and it
> > reveals that "nobody cared" for irq 16 happens long after last
> >
> > I915_WRITE(GMBUS4 + reg_offset, 0);
> >
> > has been performed in gmbus_wait_hw_status(). On the other hand, if I
> > comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(),
> > then it of course falls back to GPIO bit-banging, but the "nobody cared"
> > for irq 16 is gone.
> >
> > So it seems like something gets severely confused by the I915_WRITE to
> > GMBUS4 + reg_offset. So far this seems to have been reported solely on
> > Lenovos as far as I can see (although a completely different types), so it
> > might be some platform-specific quirk?
> >
> > Honestly, I still don't understand how all the GMBUS stuff relates to IRQ
> > 16 at all.
> 
> that device is using
> i915 :00:02.0: irq 44 for MSI/MSI-X
> 
> so can you try to boot with pci=nomsi?

Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost 
interrupts go away.

My understanding from the other mail is that DAniel Vetter already has an 
idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully 
this datapoint regarding MSI will fit into it.

-- 
Jiri Kosina
SUSE Labs

drm/i915: new warning (regression) in 3.7.10 and 3.8.3

[Daniel Vetter]

On Sat, Mar 16, 2013 at 01:28:50PM +0100, Richard Cochran wrote:
> 
> I have an Acer Aspire One netbook, and on it I get the following
> warning when closing and opening the lid. I think this warning first
> appeared in 3.7.
> 
> Does this need fixing? If so, who can do it?

Another pesky BIOS which changes the display state behind our back on lid
closing! Should be duct-tapped over with

commit 45e2b5f640b3766da3eda48f6c35f088155c06f3
Author: Daniel Vetter 
Date:   Fri Nov 23 18:16:34 2012 +0100

drm/i915: force restore on lid open

which is in 3.8.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Bug report: i915 screens stay blank with 3.8.3, ok with 3.8.2

[Daniel Vetter]

On Sat, Mar 16, 2013 at 01:04:34PM +0100, Stephan Boettcher wrote:
> 
> Moin,
> 
> [1.] One line summary of the problem:
> 
>Both screens stay blank during boot with 3.8.3.
> 
> [2.] Full description of the problem/report:
> 
>When booting the screens go blank soon after showing the grub menu.  
>Starting X11 does not bring the screens up either.
>In /var/log/dmesg two lines appear (diff -u):
> 
> @@ -432,8 +434,10 @@
>  [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>  [drm] Driver supports precise vblank timestamp query.
>  vgaarb: device changed decodes: 
> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> +i915 :00:02.0: No connectors reported connected with modes
> +[drm] Cannot find any crtc or sizes - going 1024x768
>  fbcon: inteldrmfb (fb0) is primary device
> -Console: switching to colour frame buffer device 240x75
> +Console: switching to colour frame buffer device 128x48
>  i915 :00:02.0: fb0: inteldrmfb frame buffer device
>  i915 :00:02.0: registered panic notifier
>  i915: No ACPI video bus found

Can you please file a bug report against bugs.freedesktop.org. Please boot
both broken and working kernel with drm.debug=0xe added to your kernel
cmdline and attach the complete dmesg of each to the bug report.

If you can do a quick bisect to figure out the offending commit, that
would be good, too. And can you please also check whether the latest
3.9-rc kernel is affect? We need to know that since stable rules mandate
that regressions in stable kernels can only be fixed once upstream is
known to work.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Daniel Vetter]

On Fri, Mar 15, 2013 at 08:47:39AM -0700, Greg KH wrote:
> On Fri, Mar 15, 2013 at 04:37:56PM +0100, Jiri Kosina wrote:
> > On Fri, 15 Mar 2013, Greg KH wrote:
> > 
> > > > > I have the same problem on my Lenovo T500. I think the graphics card 
> > > > > is
> > > > > involved.
> > > > > 
> > > > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
> > > > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 
> > > > > 16:
> > > > > nobody cared" during boot, not when I boot with the ATI card.
> > > > 
> > > > Confirming this. After a lot of hassle, I have bisected this reliably to
> > > > 
> > > > commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6
> > > > Author: Daniel Vetter 
> > > > Date:   Sat Dec 1 13:53:45 2012 +0100
> > > > 
> > > > drm/i915: use the gmbus irq for waits
> > > > 
> > > > Adding Daniel, Imre and Daniel to CC while I will try to figure out 
> > > > what's 
> > > > happening in parallel.
> > > 
> > > Wasn't this fixed by the merge from David
> > > (2cc79544bd0aabb4b3cf467ead5df526d9134c64)?
> > 
> > Why do you think it should, please?
> 
> The line:
>   - Fix PCH irq handling race which resulted in missed gmbus/dp
> aux irqs and subsequent fallout (Paulo)
> 
> > (I am seeing this with a2362d247 still).
> 
> Ok, I guess it isn't still fixed properly, just was guessing :)

Yeah, the above fix is for pch split platforms, whereas these reports here
are for gm45 (which doesn't have the pch display split). Acking of gmbus
interrupts works differently on those, I'm testing right now whether I can
reproduce this fail.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm: Destroy property blobs at mode config cleanup time

[Daniel Vetter]

On Tue, Mar 12, 2013 at 03:31:11PM +0100, Laurent Pinchart wrote:
> Property blob objects need to be destroyed when cleaning up to avoid
> memory leaks. Go through the list of all blobs in the
> drm_mode_config_cleanup() function and destroy them.
> 
> The drm_mode_config_cleanup() function needs to be moved after the
> drm_property_destroy_blob() declaration. Move drm_mode_config_init() as
> well to keep the functions together.

Imo moving drm_mode_config_init looks a bit superflous in this patch,
since there's still some other init code left around at the old place.
Drop that code movement?

Otherwise Reviewed-by: Daniel Vetter 

> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/drm_crtc.c | 208 
> +++--
>  1 file changed, 107 insertions(+), 101 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index cf4ce3d..b597734 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1120,44 +1120,6 @@ int drm_mode_create_dirty_info_property(struct 
> drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_mode_create_dirty_info_property);
>  
> -/**
> - * drm_mode_config_init - initialize DRM mode_configuration structure
> - * @dev: DRM device
> - *
> - * Initialize @dev's mode_config structure, used for tracking the graphics
> - * configuration of @dev.
> - *
> - * Since this initializes the modeset locks, no locking is possible. Which 
> is no
> - * problem, since this should happen single threaded at init time. It is the
> - * driver's problem to ensure this guarantee.
> - *
> - */
> -void drm_mode_config_init(struct drm_device *dev)
> -{
> - mutex_init(>mode_config.mutex);
> - mutex_init(>mode_config.idr_mutex);
> - mutex_init(>mode_config.fb_lock);
> - INIT_LIST_HEAD(>mode_config.fb_list);
> - INIT_LIST_HEAD(>mode_config.crtc_list);
> - INIT_LIST_HEAD(>mode_config.connector_list);
> - INIT_LIST_HEAD(>mode_config.encoder_list);
> - INIT_LIST_HEAD(>mode_config.property_list);
> - INIT_LIST_HEAD(>mode_config.property_blob_list);
> - INIT_LIST_HEAD(>mode_config.plane_list);
> - idr_init(>mode_config.crtc_idr);
> -
> - drm_modeset_lock_all(dev);
> - drm_mode_create_standard_connector_properties(dev);
> - drm_modeset_unlock_all(dev);
> -
> - /* Just to be sure */
> - dev->mode_config.num_fb = 0;
> - dev->mode_config.num_connector = 0;
> - dev->mode_config.num_crtc = 0;
> - dev->mode_config.num_encoder = 0;
> -}
> -EXPORT_SYMBOL(drm_mode_config_init);
> -
>  int drm_mode_group_init(struct drm_device *dev, struct drm_mode_group *group)
>  {
>   uint32_t total_objects = 0;
> @@ -1203,69 +1165,6 @@ int drm_mode_group_init_legacy_group(struct drm_device 
> *dev,
>  EXPORT_SYMBOL(drm_mode_group_init_legacy_group);
>  
>  /**
> - * drm_mode_config_cleanup - free up DRM mode_config info
> - * @dev: DRM device
> - *
> - * Free up all the connectors and CRTCs associated with this DRM device, then
> - * free up the framebuffers and associated buffer objects.
> - *
> - * Note that since this /should/ happen single-threaded at driver/device
> - * teardown time, no locking is required. It's the driver's job to ensure 
> that
> - * this guarantee actually holds true.
> - *
> - * FIXME: cleanup any dangling user buffer objects too
> - */
> -void drm_mode_config_cleanup(struct drm_device *dev)
> -{
> - struct drm_connector *connector, *ot;
> - struct drm_crtc *crtc, *ct;
> - struct drm_encoder *encoder, *enct;
> - struct drm_framebuffer *fb, *fbt;
> - struct drm_property *property, *pt;
> - struct drm_plane *plane, *plt;
> -
> - list_for_each_entry_safe(encoder, enct, >mode_config.encoder_list,
> -  head) {
> - encoder->funcs->destroy(encoder);
> - }
> -
> - list_for_each_entry_safe(connector, ot,
> -  >mode_config.connector_list, head) {
> - connector->funcs->destroy(connector);
> - }
> -
> - list_for_each_entry_safe(property, pt, >mode_config.property_list,
> -  head) {
> - drm_property_destroy(dev, property);
> - }
> -
> - /*
> -  * Single-threaded teardown context, so it's not required to grab the
> -  * fb_lock to protect against concurrent fb_list access. Contrary, it
> -  * would actually deadlock with the drm_framebuffer_cleanup function.
> -  *
> -  * Also, if there are any framebuffers left, that's a driver leak now,
> -  * so politely WARN about this.
> -  */
> - WARN_ON(!list_empty(>mode_config.fb_list));
> - list_for_each_entry_safe(fb, fbt, >mode_config.fb_list, head) {
> - drm_framebuffer_remove(fb);
> - }
> -
> - list_for_each_entry_safe(plane, plt, >mode_config.plane_list,
> -  head) {
> - plane->funcs->destroy(plane);
> - 

[PATCH 5/5] videomode: rename fields

[Daniel Vetter]

On Tue, Mar 12, 2013 at 03:40:14PM +0200, Tomi Valkeinen wrote:
> Hi,
> 
> On 2013-03-12 15:37, Laurent Pinchart wrote:
> > Hi Tomi,
> > 
> > Thanks for the patch.
> > 
> > On Tuesday 12 March 2013 12:19:38 Tomi Valkeinen wrote:
> >> Structs videomode and display_timing have rather long field names for
> >> the timing values. Nothing wrong with that as such, but this patch
> >> changes them to abbreviations for the following reasons:
> >>
> >> * The timing values often need to be used in calculations, and long
> >>   field names makes their direct use clumsier.
> >>
> >> * The current names are a bit of a mishmash: some words are used as
> >>   such, some are shortened, and for some only first letter is used. Some
> >>   names use underscode, some don't. All this makes it difficult to
> >>   remember what the field names are.
> >>
> >> * The abbreviations used in this patch are very common, and there
> >>   shouldn't be any misunderstanding about their meaning.
> >>
> >> Signed-off-by: Tomi Valkeinen 
> >> Cc: Steffen Trumtrar 
> >> ---
> > 
> > I have no strong opinion on this, but I find the existing names easier to 
> > read. I might be biased by having read them often though.
> 
> Yes, the last patch was a bit of a "teaser" =). I found myself typoing
> them a lot, using helper local variables to shorten the code lines, and
> as I mention in the description, I find them a bit of a mishmash. So,
> while they're not used in any drivers yet, I thought it'd be worth a
> shot to change them.

Imo the new names look quite a bit more ugly and less readable, for very
few saved chars. And at least for i915.ko development it's been a long
time since I've last had to type them ... Maybe the real problem is that
we have a few too many video mode structures and can't properly share
them?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Thomas Meyer]

My laptop is an Acer 1810T. I see this error message each boot.

Kind regards
Thomas

Jiri Kosina  schrieb:

>On Fri, 15 Mar 2013, Jiri Kosina wrote:
>
>> > I have the same problem on my Lenovo T500. I think the graphics card is
>> > involved.
>> > 
>> > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
>> > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16:
>> > nobody cared" during boot, not when I boot with the ATI card.
>> 
>> Confirming this. After a lot of hassle, I have bisected this reliably to
>> 
>>  commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6
>>  Author: Daniel Vetter 
>>  Date:   Sat Dec 1 13:53:45 2012 +0100
>> 
>>  drm/i915: use the gmbus irq for waits
>> 
>> Adding Daniel, Imre and Daniel to CC while I will try to figure out what's 
>> happening in parallel.
>> 
>> Attaching dmesg.txt from the machine with 28c70f162a as head, with 
>> drm.debug=0xe.
>
>Just a datapoint -- I have put a trivial debugging patch in place, and it 
>reveals that "nobody cared" for irq 16 happens long after last
>
>   I915_WRITE(GMBUS4 + reg_offset, 0);
>
>has been performed in gmbus_wait_hw_status(). On the other hand, if I 
>comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(), 
>then it of course falls back to GPIO bit-banging, but the "nobody cared" 
>for irq 16 is gone. 
>
>So it seems like something gets severely confused by the I915_WRITE to 
>GMBUS4 + reg_offset. So far this seems to have been reported solely on 
>Lenovos as far as I can see (although a completely different types), so it 
>might be some platform-specific quirk?
>
>Honestly, I still don't understand how all the GMBUS stuff relates to IRQ 
>16 at all. 
>
>-- 
>Jiri Kosina
>SUSE Labs

[Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer

[Dave Airlie]

On Mon, Mar 18, 2013 at 7:40 AM, Chris Wilson  
wrote:
> On Sun, Mar 17, 2013 at 08:50:03PM +0100, Daniel Vetter wrote:
>> On Sat, Mar 16, 2013 at 11:19 AM, Chris Wilson  
>> wrote:
>> > If *userspace* doesn't request either IOC_IN | IOC_OUT in their ioctl
>> > command (which are seperate from the ioctl number), then kdata is set to
>> > NULL.
>>
>> Doesn't that mean that we need these checks everywhere? Or at least a
>> fixup in drm core proper?
>
> That's my conclusion. We either add a flag to ask drm_ioctl to prevent
> passing NULL pointers (as the existing behaviour may be useful
> somewhere, and I have not checked all callees) or saturate our callbacks
> with NULL checks.

Do we have the kernel's expected IOC_IN/IOC_OUT flags at that point as well?

we could check them and block NULL in that case.

Dave.

[Bug 60802] Corruption with DMA ring on cayman

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

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

--- Comment #67 from Alexandre Demers  ---
(In reply to comment #66)
> Pushed:
> http://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=4409758a046a47b09cdd339f97afd22107c68f0c

It seems ok over here. Thank you.

-- 
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/20130318/85dbd506/attachment.html>

Re: [3.9.0-rc2] nouveau deadlock when HDMI TV is connected

[Lijo Antony]

On 03/16/2013 10:29 PM, Lijo Antony wrote:


But looking at 65b5f42e2a9eb9c8383fb67698bf8c27657f8c14, it looks I
might have done some mistake in bisecting.


My bisecting was indeed incorrect. Issue started even before 3.9.0-rc1.
Attempting a proper bisect this time...

-lijo

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

Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Shawn Starr]

On Friday, March 15, 2013 12:14:28 PM Yinghai Lu wrote:
 On Fri, Mar 15, 2013 at 8:14 AM, Jiri Kosina jkos...@suse.cz wrote:
  Just a datapoint -- I have put a trivial debugging patch in place, and it
  reveals that nobody cared for irq 16 happens long after last
  
  I915_WRITE(GMBUS4 + reg_offset, 0);
  
  has been performed in gmbus_wait_hw_status(). On the other hand, if I
  comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(),
  then it of course falls back to GPIO bit-banging, but the nobody cared
  for irq 16 is gone.
  
  So it seems like something gets severely confused by the I915_WRITE to
  GMBUS4 + reg_offset. So far this seems to have been reported solely on
  Lenovos as far as I can see (although a completely different types), so it
  might be some platform-specific quirk?
  
  Honestly, I still don't understand how all the GMBUS stuff relates to IRQ
  16 at all.
 
 that device is using
 i915 :00:02.0: irq 44 for MSI/MSI-X
 
 so can you try to boot with pci=nomsi?

I can try disabling MSI with 3.9.0-0.rc2.git0.4.fc20. -rc3 is not yet 
available in rawhide.

thanks,
Shawn___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] videomode: rename fields

[Daniel Vetter]

On Tue, Mar 12, 2013 at 03:40:14PM +0200, Tomi Valkeinen wrote:
 Hi,
 
 On 2013-03-12 15:37, Laurent Pinchart wrote:
  Hi Tomi,
  
  Thanks for the patch.
  
  On Tuesday 12 March 2013 12:19:38 Tomi Valkeinen wrote:
  Structs videomode and display_timing have rather long field names for
  the timing values. Nothing wrong with that as such, but this patch
  changes them to abbreviations for the following reasons:
 
  * The timing values often need to be used in calculations, and long
field names makes their direct use clumsier.
 
  * The current names are a bit of a mishmash: some words are used as
such, some are shortened, and for some only first letter is used. Some
names use underscode, some don't. All this makes it difficult to
remember what the field names are.
 
  * The abbreviations used in this patch are very common, and there
shouldn't be any misunderstanding about their meaning.
 
  Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
  Cc: Steffen Trumtrar s.trumt...@pengutronix.de
  ---
  
  I have no strong opinion on this, but I find the existing names easier to 
  read. I might be biased by having read them often though.
 
 Yes, the last patch was a bit of a teaser =). I found myself typoing
 them a lot, using helper local variables to shorten the code lines, and
 as I mention in the description, I find them a bit of a mishmash. So,
 while they're not used in any drivers yet, I thought it'd be worth a
 shot to change them.

Imo the new names look quite a bit more ugly and less readable, for very
few saved chars. And at least for i915.ko development it's been a long
time since I've last had to type them ... Maybe the real problem is that
we have a few too many video mode structures and can't properly share
them?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Destroy property blobs at mode config cleanup time

[Daniel Vetter]

On Tue, Mar 12, 2013 at 03:31:11PM +0100, Laurent Pinchart wrote:
 Property blob objects need to be destroyed when cleaning up to avoid
 memory leaks. Go through the list of all blobs in the
 drm_mode_config_cleanup() function and destroy them.
 
 The drm_mode_config_cleanup() function needs to be moved after the
 drm_property_destroy_blob() declaration. Move drm_mode_config_init() as
 well to keep the functions together.

Imo moving drm_mode_config_init looks a bit superflous in this patch,
since there's still some other init code left around at the old place.
Drop that code movement?

Otherwise Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch

 Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
 ---
  drivers/gpu/drm/drm_crtc.c | 208 
 +++--
  1 file changed, 107 insertions(+), 101 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index cf4ce3d..b597734 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -1120,44 +1120,6 @@ int drm_mode_create_dirty_info_property(struct 
 drm_device *dev)
  }
  EXPORT_SYMBOL(drm_mode_create_dirty_info_property);
  
 -/**
 - * drm_mode_config_init - initialize DRM mode_configuration structure
 - * @dev: DRM device
 - *
 - * Initialize @dev's mode_config structure, used for tracking the graphics
 - * configuration of @dev.
 - *
 - * Since this initializes the modeset locks, no locking is possible. Which 
 is no
 - * problem, since this should happen single threaded at init time. It is the
 - * driver's problem to ensure this guarantee.
 - *
 - */
 -void drm_mode_config_init(struct drm_device *dev)
 -{
 - mutex_init(dev-mode_config.mutex);
 - mutex_init(dev-mode_config.idr_mutex);
 - mutex_init(dev-mode_config.fb_lock);
 - INIT_LIST_HEAD(dev-mode_config.fb_list);
 - INIT_LIST_HEAD(dev-mode_config.crtc_list);
 - INIT_LIST_HEAD(dev-mode_config.connector_list);
 - INIT_LIST_HEAD(dev-mode_config.encoder_list);
 - INIT_LIST_HEAD(dev-mode_config.property_list);
 - INIT_LIST_HEAD(dev-mode_config.property_blob_list);
 - INIT_LIST_HEAD(dev-mode_config.plane_list);
 - idr_init(dev-mode_config.crtc_idr);
 -
 - drm_modeset_lock_all(dev);
 - drm_mode_create_standard_connector_properties(dev);
 - drm_modeset_unlock_all(dev);
 -
 - /* Just to be sure */
 - dev-mode_config.num_fb = 0;
 - dev-mode_config.num_connector = 0;
 - dev-mode_config.num_crtc = 0;
 - dev-mode_config.num_encoder = 0;
 -}
 -EXPORT_SYMBOL(drm_mode_config_init);
 -
  int drm_mode_group_init(struct drm_device *dev, struct drm_mode_group *group)
  {
   uint32_t total_objects = 0;
 @@ -1203,69 +1165,6 @@ int drm_mode_group_init_legacy_group(struct drm_device 
 *dev,
  EXPORT_SYMBOL(drm_mode_group_init_legacy_group);
  
  /**
 - * drm_mode_config_cleanup - free up DRM mode_config info
 - * @dev: DRM device
 - *
 - * Free up all the connectors and CRTCs associated with this DRM device, then
 - * free up the framebuffers and associated buffer objects.
 - *
 - * Note that since this /should/ happen single-threaded at driver/device
 - * teardown time, no locking is required. It's the driver's job to ensure 
 that
 - * this guarantee actually holds true.
 - *
 - * FIXME: cleanup any dangling user buffer objects too
 - */
 -void drm_mode_config_cleanup(struct drm_device *dev)
 -{
 - struct drm_connector *connector, *ot;
 - struct drm_crtc *crtc, *ct;
 - struct drm_encoder *encoder, *enct;
 - struct drm_framebuffer *fb, *fbt;
 - struct drm_property *property, *pt;
 - struct drm_plane *plane, *plt;
 -
 - list_for_each_entry_safe(encoder, enct, dev-mode_config.encoder_list,
 -  head) {
 - encoder-funcs-destroy(encoder);
 - }
 -
 - list_for_each_entry_safe(connector, ot,
 -  dev-mode_config.connector_list, head) {
 - connector-funcs-destroy(connector);
 - }
 -
 - list_for_each_entry_safe(property, pt, dev-mode_config.property_list,
 -  head) {
 - drm_property_destroy(dev, property);
 - }
 -
 - /*
 -  * Single-threaded teardown context, so it's not required to grab the
 -  * fb_lock to protect against concurrent fb_list access. Contrary, it
 -  * would actually deadlock with the drm_framebuffer_cleanup function.
 -  *
 -  * Also, if there are any framebuffers left, that's a driver leak now,
 -  * so politely WARN about this.
 -  */
 - WARN_ON(!list_empty(dev-mode_config.fb_list));
 - list_for_each_entry_safe(fb, fbt, dev-mode_config.fb_list, head) {
 - drm_framebuffer_remove(fb);
 - }
 -
 - list_for_each_entry_safe(plane, plt, dev-mode_config.plane_list,
 -  head) {
 - plane-funcs-destroy(plane);
 - }
 -
 - list_for_each_entry_safe(crtc, ct, 

[PATCH] mgag200: fix g200eh pll picking code

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

This aligns this code more carefully with what is in the upstream X.org MGA
driver.

The freq is a typo, and other changes ports from the same function in the
X.org driver.

Cc: sta...@vger.kernel.org
Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/mgag200/mgag200_mode.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index a274b99..4d813bb 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -382,12 +382,12 @@ static int mga_g200eh_set_plls(struct mga_device *mdev, 
long clock)
m = n = p = 0;
vcomax = 80;
vcomin = 40;
-   pllreffreq = ;
+   pllreffreq = 3;
 
delta = 0x;
permitteddelta = clock * 5 / 1000;
 
-   for (testp = 16; testp  0; testp--) {
+   for (testp = 16; testp  0; testp = 1) {
if (clock * testp  vcomax)
continue;
if (clock * testp  vcomin)
@@ -404,7 +404,7 @@ static int mga_g200eh_set_plls(struct mga_device *mdev, 
long clock)
if (tmpdelta  delta) {
delta = tmpdelta;
n = testn - 1;
-   m = (testm - 1) | ((n  1)  0x80);
+   m = testm - 1;
p = testp - 1;
}
if ((clock * testp) = 60)
-- 
1.8.1.2

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

Re: Bug report: i915 screens stay blank with 3.8.3, ok with 3.8.2

[Daniel Vetter]

On Sat, Mar 16, 2013 at 01:04:34PM +0100, Stephan Boettcher wrote:
 
 Moin,
 
 [1.] One line summary of the problem:
 
Both screens stay blank during boot with 3.8.3.
 
 [2.] Full description of the problem/report:
 
When booting the screens go blank soon after showing the grub menu.  
Starting X11 does not bring the screens up either.
In /var/log/dmesg two lines appear (diff -u):
 
 @@ -432,8 +434,10 @@
  [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
  [drm] Driver supports precise vblank timestamp query.
  vgaarb: device changed decodes: 
 PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
 +i915 :00:02.0: No connectors reported connected with modes
 +[drm] Cannot find any crtc or sizes - going 1024x768
  fbcon: inteldrmfb (fb0) is primary device
 -Console: switching to colour frame buffer device 240x75
 +Console: switching to colour frame buffer device 128x48
  i915 :00:02.0: fb0: inteldrmfb frame buffer device
  i915 :00:02.0: registered panic notifier
  i915: No ACPI video bus found

Can you please file a bug report against bugs.freedesktop.org. Please boot
both broken and working kernel with drm.debug=0xe added to your kernel
cmdline and attach the complete dmesg of each to the bug report.

If you can do a quick bisect to figure out the offending commit, that
would be good, too. And can you please also check whether the latest
3.9-rc kernel is affect? We need to know that since stable rules mandate
that regressions in stable kernels can only be fixed once upstream is
known to work.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/i915: new warning (regression) in 3.7.10 and 3.8.3

[Daniel Vetter]

On Sat, Mar 16, 2013 at 01:28:50PM +0100, Richard Cochran wrote:
 
 I have an Acer Aspire One netbook, and on it I get the following
 warning when closing and opening the lid. I think this warning first
 appeared in 3.7.
 
 Does this need fixing? If so, who can do it?

Another pesky BIOS which changes the display state behind our back on lid
closing! Should be duct-tapped over with

commit 45e2b5f640b3766da3eda48f6c35f088155c06f3
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:   Fri Nov 23 18:16:34 2012 +0100

drm/i915: force restore on lid open

which is in 3.8.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Jiri Kosina]

On Fri, 15 Mar 2013, Yinghai Lu wrote:

  Just a datapoint -- I have put a trivial debugging patch in place, and it
  reveals that nobody cared for irq 16 happens long after last
 
  I915_WRITE(GMBUS4 + reg_offset, 0);
 
  has been performed in gmbus_wait_hw_status(). On the other hand, if I
  comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(),
  then it of course falls back to GPIO bit-banging, but the nobody cared
  for irq 16 is gone.
 
  So it seems like something gets severely confused by the I915_WRITE to
  GMBUS4 + reg_offset. So far this seems to have been reported solely on
  Lenovos as far as I can see (although a completely different types), so it
  might be some platform-specific quirk?
 
  Honestly, I still don't understand how all the GMBUS stuff relates to IRQ
  16 at all.
 
 that device is using
 i915 :00:02.0: irq 44 for MSI/MSI-X
 
 so can you try to boot with pci=nomsi?

Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost 
interrupts go away.

My understanding from the other mail is that DAniel Vetter already has an 
idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully 
this datapoint regarding MSI will fit into it.

-- 
Jiri Kosina
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Destroy property blobs at mode config cleanup time

[Laurent Pinchart]

Hi Daniel,

On Monday 18 March 2013 09:06:21 Daniel Vetter wrote:
 On Tue, Mar 12, 2013 at 03:31:11PM +0100, Laurent Pinchart wrote:
  Property blob objects need to be destroyed when cleaning up to avoid
  memory leaks. Go through the list of all blobs in the
  drm_mode_config_cleanup() function and destroy them.
  
  The drm_mode_config_cleanup() function needs to be moved after the
  drm_property_destroy_blob() declaration. Move drm_mode_config_init() as
  well to keep the functions together.
 
 Imo moving drm_mode_config_init looks a bit superflous in this patch,
 since there's still some other init code left around at the old place.

It's not mandatory indeed, but it's a step in the right direction in my 
opinion. Maybe a separate patch that just moves functions around in drm_crtc.c 
would be a better idea :-)

 Drop that code movement?

I have no strong opinion, I can drop it if that's preferred.

 Otherwise Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch

Thank you.

-- 
Regards,

Laurent Pinchart

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

Revert a bunch of patches in stable kernels

[Daniel Vetter]

Hi Gregall,

So a recent stable backport to fix rc6 on ilk (which is disabled by
default and with dubious power savings at best, unlike rc6 on snb and
later) totally blew up all over the place:
https://bugzilla.kernel.org/show_bug.cgi?id=55291
https://lkml.org/lkml/2013/3/14/540

There might be more, I'm still recovering from mail floods due to
traveling last week. I think the right course of action is to revert
the offending patch (plus anything depending upon it) and give up on
rc6 on ilk in 3.8 - too messy. All bug reports confirmed that 3.9-rc
kernels work as expected. Upstream commits to revert:

15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9 drm/i915: enable irqs earlier
when resuming
52d7ecedac3f96fb562cb482c139015372728638 drm/i915: reorder setup
sequence to have irqs for output setup

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62466] New: KSP 0.19 causes GPU lockups on r600g

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 62466
  Assignee: dri-devel@lists.freedesktop.org
   Summary: KSP 0.19 causes GPU lockups on r600g
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: knut.tidem...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 76678
  -- https://bugs.freedesktop.org/attachment.cgi?id=76678action=edit
dmesg output

When trying out Kerbal Space Program for linux (version 0.19 was just released
with native linux support) I get GPU lockups when constructing rockets.

Everything worked well at first, but after a few minutes I got the first GPU
lockup and after that it seem to lock up every 5 seconds or so, so I had to
kill the game.

This happens every time I run the game. MSAA and vsync were not enabled.

I'm running mesa from git: 
Mesa 9.2.0 (git-2da8ee1) on a Radeon HD 5670

and the arch linxu kernel: 
Linux none 3.8.3-2-ARCH #1 SMP PREEMPT Sun Mar 17 13:04:22 CET 2013 x86_64
GNU/Linux

I've attached a full dmesg log.

I'm running KDE and have two monitors set up. The lockups happened both with
and without desktop effects enabled.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62434] [bisected] 3284.073] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libllvmradeon9.2.0.so: undefined symbol: lp_build_tgsi_intrinsic)

[bugzilla-daemon]

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

--- Comment #8 from Michel Dänzer mic...@daenzer.net ---
(In reply to comment #5)
 Possible patch

This seems less than ideal, as it makes libllvmradeon duplicate lots of stuff
from the driver *.so, and it grows from ~500K to ~10M for me.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62434] [bisected] 3284.073] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libllvmradeon9.2.0.so: undefined symbol: lp_build_tgsi_intrinsic)

[bugzilla-daemon]

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

--- Comment #9 from LoneVVolf lonew...@xs4all.nl ---
That appears to be correct,
in a git version build on march 11
libllvmradeon9.2.0.so is just 39 Kib .
Build with the patch it's size increases to 1.8 Mib !

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62466] KSP 0.19 causes GPU lockups on r600g

[bugzilla-daemon]

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

--- Comment #1 from Alex Deucher ag...@yahoo.com ---
Does disabling hyperz help?  Set env var:
R600_DEBUG=nohyperz

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62434] [bisected] 3284.073] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libllvmradeon9.2.0.so: undefined symbol: lp_build_tgsi_intrinsic)

[bugzilla-daemon]

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

--- Comment #10 from Andreas Boll andreas.boll@gmail.com ---
(In reply to comment #8)
 (In reply to comment #5)
  Possible patch
 
 This seems less than ideal, as it makes libllvmradeon duplicate lots of
 stuff from the driver *.so, and it grows from ~500K to ~10M for me.

Hmm we definitely need a shared libgallium.
That would reduce the size of all gallium drivers.

Or we could remove/revert the visibility flags from
src/gallium/auxiliary/Makefile.am

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62466] KSP 0.19 causes GPU lockups on r600g

[bugzilla-daemon]

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

--- Comment #2 from Knut Andre Tidemann knut.tidem...@gmail.com ---
Disabling hyperz does indeed fix the issue. Tried a quick spin for ~15-20 mins
wit no issues now.

With hyperz enabled, I get lockups after a few minutes.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62466] r600g hyperz lockups with KSP 0.19

[bugzilla-daemon]

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

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

Summary|KSP 0.19 causes GPU lockups |r600g hyperz lockups with
   |on r600g|KSP 0.19

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/4] mgag200 fix and cleanup

[Christopher Harvey]

Just a bit of cleanup from me (resubmitted). The important patch comes
from Julia. Julia's patch conflicts with the following:
1363594270-22137-1-git-send-email-airl...@gmail.com

it fixes
https://bugzilla.kernel.org/show_bug.cgi?id=46591

Christopher Harvey (3):
  drm/mgag200: Remove pointless call to drm_fb_get_bpp_depth
  drm/mgag200: Pass driver specific mga_device in driver functions
  drm/mgag200: Remove extra variable assigns

Julia Lemire (1):
  drm/mgag200: Bug fix: Modified pll algorithm for EH project

 drivers/gpu/drm/mgag200/mgag200_fb.c   |  3 ---
 drivers/gpu/drm/mgag200/mgag200_main.c |  2 --
 drivers/gpu/drm/mgag200/mgag200_mode.c | 17 -
 3 files changed, 8 insertions(+), 14 deletions(-)

-- 
1.7.12.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] drm/mgag200: Remove pointless call to drm_fb_get_bpp_depth

[Christopher Harvey]

Signed-off-by: Christopher Harvey char...@matrox.com
---
 drivers/gpu/drm/mgag200/mgag200_fb.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c 
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index d2253f6..a5a1f34 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
@@ -105,12 +105,9 @@ static int mgag200fb_create_object(struct mga_fbdev 
*afbdev,
   struct drm_gem_object **gobj_p)
 {
struct drm_device *dev = afbdev-helper.dev;
-   u32 bpp, depth;
u32 size;
struct drm_gem_object *gobj;
-
int ret = 0;
-   drm_fb_get_bpp_depth(mode_cmd-pixel_format, depth, bpp);
 
size = mode_cmd-pitches[0] * mode_cmd-height;
ret = mgag200_gem_create(dev, size, true, gobj);
-- 
1.7.12.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/4] drm/mgag200: Pass driver specific mga_device in driver functions

[Christopher Harvey]

Signed-off-by: Christopher Harvey char...@matrox.com
---
 drivers/gpu/drm/mgag200/mgag200_mode.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index a274b99..6b5db83 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1261,9 +1261,8 @@ static const struct drm_crtc_helper_funcs 
mga_helper_funcs = {
 };
 
 /* CRTC setup */
-static void mga_crtc_init(struct drm_device *dev)
+static void mga_crtc_init(struct mga_device *mdev)
 {
-   struct mga_device *mdev = dev-dev_private;
struct mga_crtc *mga_crtc;
int i;
 
@@ -1274,7 +1273,7 @@ static void mga_crtc_init(struct drm_device *dev)
if (mga_crtc == NULL)
return;
 
-   drm_crtc_init(dev, mga_crtc-base, mga_crtc_funcs);
+   drm_crtc_init(mdev-dev, mga_crtc-base, mga_crtc_funcs);
 
drm_mode_crtc_set_gamma_size(mga_crtc-base, MGAG200_LUT_SIZE);
mdev-mode_info.crtc = mga_crtc;
@@ -1529,7 +1528,7 @@ int mgag200_modeset_init(struct mga_device *mdev)
 
mdev-dev-mode_config.fb_base = mdev-mc.vram_base;
 
-   mga_crtc_init(mdev-dev);
+   mga_crtc_init(mdev);
 
encoder = mga_encoder_init(mdev-dev);
if (!encoder) {
-- 
1.7.12.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/4] drm/mgag200: Remove extra variable assigns

[Christopher Harvey]

These two variables are set again immediately in 'mgag200_modeset_init'

Signed-off-by: Christopher Harvey char...@matrox.com
---
 drivers/gpu/drm/mgag200/mgag200_main.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c 
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 64297c7..b762bfb 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -234,8 +234,6 @@ int mgag200_driver_load(struct drm_device *dev, unsigned 
long flags)
 
drm_mode_config_init(dev);
dev-mode_config.funcs = (void *)mga_mode_funcs;
-   dev-mode_config.min_width = 0;
-   dev-mode_config.min_height = 0;
dev-mode_config.preferred_depth = 24;
dev-mode_config.prefer_shadow = 1;
 
-- 
1.7.12.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/4] drm/mgag200: Bug fix: Modified pll algorithm for EH project

[Julia Lemire]

While testing the mgag200 kms driver on the HP ProLiant Gen8, a
bug was seen.  Once the bootloader would load the selected kernel,
the screen would go black.  At first it was assumed that the
mgag200 kms driver was hanging.  But after setting up the grub
serial output, it was seen that the driver was being loaded
properly.  After trying serval monitors, one finaly displayed
the message Frequency Out of Range.  By comparing the kms pll
algorithm with the previous mgag200 xorg driver pll algorithm,
discrepencies were found.  Once the kms pll algorithm was
modified, the expected pll values were produced.  This fix was
tested on several monitors of varying native resolutions.

Signed-off-by: Julia Lemire jlem...@matrox.com
---
 drivers/gpu/drm/mgag200/mgag200_mode.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 6b5db83..7337013 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -382,19 +382,19 @@ static int mga_g200eh_set_plls(struct mga_device *mdev, 
long clock)
m = n = p = 0;
vcomax = 80;
vcomin = 40;
-   pllreffreq = ;
+   pllreffreq = 3;
 
delta = 0x;
permitteddelta = clock * 5 / 1000;
 
-   for (testp = 16; testp  0; testp--) {
+   for (testp = 16; testp  0; testp = 1) {
if (clock * testp  vcomax)
continue;
if (clock * testp  vcomin)
continue;
 
for (testm = 1; testm  33; testm++) {
-   for (testn = 1; testn  257; testn++) {
+   for (testn = 17; testn  257; testn++) {
computed = (pllreffreq * testn) /
(testm * testp);
if (computed  clock)
@@ -404,11 +404,11 @@ static int mga_g200eh_set_plls(struct mga_device *mdev, 
long clock)
if (tmpdelta  delta) {
delta = tmpdelta;
n = testn - 1;
-   m = (testm - 1) | ((n  1)  0x80);
+   m = (testm - 1);
p = testp - 1;
}
if ((clock * testp) = 60)
-   p |= 80;
+   p |= 0x80;
}
}
}
-- 
1.7.12.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62434] [bisected] 3284.073] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libllvmradeon9.2.0.so: undefined symbol: lp_build_tgsi_intrinsic)

[bugzilla-daemon]

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

--- Comment #11 from Maarten Lankhorst m.b.lankho...@gmail.com ---
The fix is correct, despite the size increase.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] vesa: Prevent loading if we conflict with a previously loaded driver

[Chris Wilson]

vesa is presumed to be the generic hardware agnostic fallback framebuffer
driver for standard VGA that conflicts with the real drivers. Those
drivers already check and remove vesafb if it is previously loaded, but
in the reverse case where vesafb is loaded afterwards, the VESA driver
will proceed to clobber hardware state and corrupt the displays.

References: 
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1156077
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/video/fbmem.c  |   31 +++
 drivers/video/vesafb.c |   22 ++
 include/linux/fb.h |2 ++
 3 files changed, 55 insertions(+)

diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 7c25408..786cec8 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1722,6 +1722,37 @@ void remove_conflicting_framebuffers(struct 
apertures_struct *a,
 }
 EXPORT_SYMBOL(remove_conflicting_framebuffers);
 
+bool has_conflicting_framebuffer(struct apertures_struct *a, bool primary)
+{
+   bool ret = false;
+   int i;
+
+   mutex_lock(registration_lock);
+
+   for (i = 0 ; i  FB_MAX; i++) {
+   struct apertures_struct *gen_aper;
+
+   if (!registered_fb[i])
+   continue;
+
+   if (!(registered_fb[i]-flags  FBINFO_MISC_FIRMWARE))
+   continue;
+
+   gen_aper = registered_fb[i]-apertures;
+   if (fb_do_apertures_overlap(gen_aper, a) ||
+   (primary  gen_aper  gen_aper-count 
+gen_aper-ranges[0].base == VGA_FB_PHYS)) {
+   ret = true;
+   break;
+   }
+   }
+
+   mutex_unlock(registration_lock);
+
+   return ret;
+}
+EXPORT_SYMBOL(has_conflicting_framebuffer);
+
 /**
  * register_framebuffer - registers a frame buffer device
  * @fb_info: frame buffer info structure
diff --git a/drivers/video/vesafb.c b/drivers/video/vesafb.c
index 501b340..51adc4c1 100644
--- a/drivers/video/vesafb.c
+++ b/drivers/video/vesafb.c
@@ -226,6 +226,25 @@ static int __init vesafb_setup(char *options)
return 0;
 }
 
+static bool aperture_already_claimed(void)
+{
+   struct apertures_struct *ap;
+   bool ret;
+
+   ap = alloc_apertures(1);
+   if (!ap)
+   return true;
+
+   ap-ranges[0].base = screen_info.lfb_base;
+   ap-ranges[0].size = size_total;
+
+   ret = has_conflicting_framebuffer(ap, true);
+
+   kfree(ap);
+
+   return ret;
+}
+
 static int __init vesafb_probe(struct platform_device *dev)
 {
struct fb_info *info;
@@ -237,6 +256,9 @@ static int __init vesafb_probe(struct platform_device *dev)
if (screen_info.orig_video_isVGA != VIDEO_TYPE_VLFB)
return -ENODEV;
 
+   if (aperture_already_claimed())
+   return -ENODEV;
+
vga_compat = (screen_info.capabilities  2) ? 0 : 1;
vesafb_fix.smem_start = screen_info.lfb_base;
vesafb_defined.bits_per_pixel = screen_info.lfb_depth;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 58b9860..7dfd964 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -611,6 +611,8 @@ extern ssize_t fb_sys_write(struct fb_info *info, const 
char __user *buf,
 extern int register_framebuffer(struct fb_info *fb_info);
 extern int unregister_framebuffer(struct fb_info *fb_info);
 extern int unlink_framebuffer(struct fb_info *fb_info);
+extern bool has_conflicting_framebuffer(struct apertures_struct *a,
+   bool primary);
 extern void remove_conflicting_framebuffers(struct apertures_struct *a,
const char *name, bool primary);
 extern int fb_prepare_logo(struct fb_info *fb_info, int rotate);
-- 
1.7.10.4

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

[Bug 62434] [bisected] 3284.073] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libllvmradeon9.2.0.so: undefined symbol: lp_build_tgsi_intrinsic)

[bugzilla-daemon]

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

--- Comment #12 from Maarten Lankhorst m.b.lankho...@gmail.com ---
Reverting the gallium fix would reopen bug #59238

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Revert a bunch of patches in stable kernels

[Daniel Vetter]

On Mon, Mar 18, 2013 at 11:05 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 Hi Gregall,

 So a recent stable backport to fix rc6 on ilk (which is disabled by
 default and with dubious power savings at best, unlike rc6 on snb and
 later) totally blew up all over the place:
 https://bugzilla.kernel.org/show_bug.cgi?id=55291
 https://lkml.org/lkml/2013/3/14/540

This likely also is the culprit behind the ghost vga issues reported
on gm45, e.g:

https://bugzilla.redhat.com/show_bug.cgi?id=922304

Again, fixed in 3.9-rc kernels by

commit 20afbda209d708be66944907966486d0c1331cb8
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:   Tue Dec 11 14:05:07 2012 +0100

drm/i915: Fixup hpd irq register setup ordering

Cheers, Daniel

 There might be more, I'm still recovering from mail floods due to
 traveling last week. I think the right course of action is to revert
 the offending patch (plus anything depending upon it) and give up on
 rc6 on ilk in 3.8 - too messy. All bug reports confirmed that 3.9-rc
 kernels work as expected. Upstream commits to revert:

 15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9 drm/i915: enable irqs earlier
 when resuming
 52d7ecedac3f96fb562cb482c139015372728638 drm/i915: reorder setup
 sequence to have irqs for output setup

 Cheers, Daniel
 --
 Daniel Vetter
 Software Engineer, Intel Corporation
 +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses))

[Jiri Kosina]

Okay, so I think that for 3.9 we want the patch below, and if eventually 
hardware root cause / workaround is found for GM45, we can have it merged 
later.



From: Jiri Kosina jkos...@suse.cz
Subject: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips

Commit 28c70f162 (drm/i915: use the gmbus irq for waits) switched to
using GMBUS irqs instead of GPIO bit-banging for chipset generations 4
and above.

It turns out though that on many systems this leads to spurious interrupts
being generated, long after the register write to disable the IRQs has been
issued.

Flushing of the register writes by POSTING_READ() directly after the register
write doesn't work either.

Disable using of GMBUS IRQs on Gen4 systems before the root cause is found and
revert back to old behavior.

Also be more careful about not issuing GMBUS4 register reads in 
gmbus_wait_hw_status() if we are not using GMBUS IRQs.

Signed-off-by: Jiri Kosina jkos...@suse.cz
---
 drivers/gpu/drm/i915/intel_i2c.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index acf8aec..8638036 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -58,12 +58,14 @@ to_intel_gmbus(struct i2c_adapter *i2c)
return container_of(i2c, struct intel_gmbus, adapter);
 }
 
+#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)-gen = 5)
 void
 intel_i2c_reset(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
I915_WRITE(dev_priv-gpio_mmio_base + GMBUS0, 0);
-   I915_WRITE(dev_priv-gpio_mmio_base + GMBUS4, 0);
+   if (HAS_GMBUS_IRQ(dev))
+   I915_WRITE(dev_priv-gpio_mmio_base + GMBUS4, 0);
 }
 
 static void intel_i2c_quirk_set(struct drm_i915_private *dev_priv, bool enable)
@@ -203,7 +205,6 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
algo-data = bus;
 }
 
-#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)-gen = 4)
 static int
 gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
 u32 gmbus2_status,
@@ -214,6 +215,13 @@ gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
u32 gmbus2 = 0;
DEFINE_WAIT(wait);
 
+   if (!HAS_GMBUS_IRQ(dev_priv-dev)) {
+   int ret;
+   ret = wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset)) 
+   (GMBUS_SATOER | gmbus2_status),
+   50);
+   return ret;
+   }
/* Important: The hw handles only the first bit, so set only one! Since
 * we also need to check for NAKs besides the hw ready/idle signal, we
 * need to wake up periodically and check that ourselves. */

-- 
Jiri Kosina
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 60407] [configure.ac] allow tests programs to be installed

[bugzilla-daemon]

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

Benjamin Gaignard benjamin.gaign...@linaro.org changed:

   What|Removed |Added

Version|unspecified |XOrg CVS

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses))

[Chris Wilson]

On Mon, Mar 18, 2013 at 04:56:02PM +0100, Jiri Kosina wrote:
 Okay, so I think that for 3.9 we want the patch below, and if eventually 
 hardware root cause / workaround is found for GM45, we can have it merged 
 later.
 
 
 
 From: Jiri Kosina jkos...@suse.cz
 Subject: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips
 
 Commit 28c70f162 (drm/i915: use the gmbus irq for waits) switched to
 using GMBUS irqs instead of GPIO bit-banging for chipset generations 4
 and above.
 
 It turns out though that on many systems this leads to spurious interrupts
 being generated, long after the register write to disable the IRQs has been
 issued.
 
 Flushing of the register writes by POSTING_READ() directly after the register
 write doesn't work either.
 
 Disable using of GMBUS IRQs on Gen4 systems before the root cause is found and
 revert back to old behavior.
 
 Also be more careful about not issuing GMBUS4 register reads in 
 gmbus_wait_hw_status() if we are not using GMBUS IRQs.
 
 Signed-off-by: Jiri Kosina jkos...@suse.cz
 ---
  drivers/gpu/drm/i915/intel_i2c.c |   12 ++--
  1 files changed, 10 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
 b/drivers/gpu/drm/i915/intel_i2c.c
 index acf8aec..8638036 100644
 --- a/drivers/gpu/drm/i915/intel_i2c.c
 +++ b/drivers/gpu/drm/i915/intel_i2c.c
 @@ -58,12 +58,14 @@ to_intel_gmbus(struct i2c_adapter *i2c)
   return container_of(i2c, struct intel_gmbus, adapter);
  }
  
 +#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)-gen = 5)
  void
  intel_i2c_reset(struct drm_device *dev)
  {
   struct drm_i915_private *dev_priv = dev-dev_private;
   I915_WRITE(dev_priv-gpio_mmio_base + GMBUS0, 0);
 - I915_WRITE(dev_priv-gpio_mmio_base + GMBUS4, 0);
 + if (HAS_GMBUS_IRQ(dev))
 + I915_WRITE(dev_priv-gpio_mmio_base + GMBUS4, 0);

There should not be any harm in always clearing GMBUS4, it exists on all
platforms.

  }
  
  static void intel_i2c_quirk_set(struct drm_i915_private *dev_priv, bool 
 enable)
 @@ -203,7 +205,6 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
   algo-data = bus;
  }
  
 -#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)-gen = 4)
  static int
  gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
u32 gmbus2_status,
 @@ -214,6 +215,13 @@ gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
   u32 gmbus2 = 0;
   DEFINE_WAIT(wait);
  
 + if (!HAS_GMBUS_IRQ(dev_priv-dev)) {
 + int ret;
 + ret = wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset)) 
 + (GMBUS_SATOER | gmbus2_status),
 + 50);

This should couple up to the normal return code that chooses the
appropriate return value based on gmbus2.

How about just using:
  if (!HAS_GMBUS_IRQ(dev_priv-dev)) gmbus4_irq_en = 0;
and the existing wait loop?

 + return ret;
 + }
   /* Important: The hw handles only the first bit, so set only one! Since
* we also need to check for NAKs besides the hw ready/idle signal, we
* need to wake up periodically and check that ourselves. */

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62434] [bisected] 3284.073] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libllvmradeon9.2.0.so: undefined symbol: lp_build_tgsi_intrinsic)

[bugzilla-daemon]

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

--- Comment #13 from Fabio Pedretti fabio@libero.it ---
Ubuntu is providing a shared libgallium, the patches are here:
http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/mesa.git;a=tree;f=debian/patches;hb=refs/heads/ubuntu%2B1

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/7] Consider G2D hardware restrictions.

[Rob Clark]

Btw, what is the hw response to invalid input (ie. bottomtop, invalid
size, etc)?

Ie. if it will just ignore the blit or raise an error irq which can be
handled sanely, it could be ok to avoid the overhead of the cmdstream
checking in the kernel.  The kernel part really just needs to ensure
that userspace can't cause security problems (read/write access to
non-gfx-buffers, or lock up the system, that sort of thing).  It
doesn't need to guarantee that the results are sensible.

BR,
-R

On Wed, Mar 13, 2013 at 5:03 AM, Inki Dae inki@samsung.com wrote:
 This patch set checks the contents of g2d command list from user
 is valid or not according to G2D hardware restrictions. For now,
 G2D driver wasn't considered for them properly.

 For this, this patch set includes relevant code cleaups, fixups
 and adds a new function to get buffer size to the gem to be
 accessed by G2D dma.

 Inki Dae (1):
   drm/exynos: Add a new function to get gem buffer size

 YoungJun Cho (6):
   drm/exynos: Fix error routine to getting dma addr.
   drm/exynos: clear node object type at gem unmap
   drm/exynos: Fix G2D core mulfunctioning issue
   drm/exynos: Clean up some G2D codes for readability
   drm/exynos: Deal with g2d buffer info more efficiently
   drm/exynos: Check g2d cmd list for g2d restrictions

  drivers/gpu/drm/exynos/exynos_drm_g2d.c |  381 
 ++-
  drivers/gpu/drm/exynos/exynos_drm_gem.c |   21 ++
  drivers/gpu/drm/exynos/exynos_drm_gem.h |5 +
  3 files changed, 349 insertions(+), 58 deletions(-)

 --
 1.7.4.1

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

Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Yinghai Lu]

On Mon, Mar 18, 2013 at 2:12 AM, Jiri Kosina jkos...@suse.cz wrote:
 On Fri, 15 Mar 2013, Yinghai Lu wrote:

  Just a datapoint -- I have put a trivial debugging patch in place, and it
  reveals that nobody cared for irq 16 happens long after last
 
  I915_WRITE(GMBUS4 + reg_offset, 0);
 
  has been performed in gmbus_wait_hw_status(). On the other hand, if I
  comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(),
  then it of course falls back to GPIO bit-banging, but the nobody cared
  for irq 16 is gone.
 
  So it seems like something gets severely confused by the I915_WRITE to
  GMBUS4 + reg_offset. So far this seems to have been reported solely on
  Lenovos as far as I can see (although a completely different types), so it
  might be some platform-specific quirk?
 
  Honestly, I still don't understand how all the GMBUS stuff relates to IRQ
  16 at all.

 that device is using
 i915 :00:02.0: irq 44 for MSI/MSI-X

 so can you try to boot with pci=nomsi?

 Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost
 interrupts go away.

 My understanding from the other mail is that DAniel Vetter already has an
 idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully
 this datapoint regarding MSI will fit into it.

What is /proc/interrupts difference between with and without pci=nomsi ?

drm is forced to share irq 16?

Thanks

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Thomas Meyer]

My laptop is an Acer 1810T. I see this error message each boot.

Kind regards
Thomas

Jiri Kosina jkos...@suse.cz schrieb:

On Fri, 15 Mar 2013, Jiri Kosina wrote:

  I have the same problem on my Lenovo T500. I think the graphics card is
  involved.
  
  This laptop has hybrid graphics - one Intel GMA 4500MHD and one ATI
  Mobility Radeon HD 3650. When I boot with the Intel card, I get irq 16:
  nobody cared during boot, not when I boot with the ATI card.
 
 Confirming this. After a lot of hassle, I have bisected this reliably to
 
  commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6
  Author: Daniel Vetter daniel.vet...@ffwll.ch
  Date:   Sat Dec 1 13:53:45 2012 +0100
 
  drm/i915: use the gmbus irq for waits
 
 Adding Daniel, Imre and Daniel to CC while I will try to figure out what's 
 happening in parallel.
 
 Attaching dmesg.txt from the machine with 28c70f162a as head, with 
 drm.debug=0xe.

Just a datapoint -- I have put a trivial debugging patch in place, and it 
reveals that nobody cared for irq 16 happens long after last

   I915_WRITE(GMBUS4 + reg_offset, 0);

has been performed in gmbus_wait_hw_status(). On the other hand, if I 
comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(), 
then it of course falls back to GPIO bit-banging, but the nobody cared 
for irq 16 is gone. 

So it seems like something gets severely confused by the I915_WRITE to 
GMBUS4 + reg_offset. So far this seems to have been reported solely on 
Lenovos as far as I can see (although a completely different types), so it 
might be some platform-specific quirk?

Honestly, I still don't understand how all the GMBUS stuff relates to IRQ 
16 at all. 

-- 
Jiri Kosina
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] videomode: rename fields

[Tomi Valkeinen]

On 2013-03-18 10:00, Daniel Vetter wrote:
 On Tue, Mar 12, 2013 at 03:40:14PM +0200, Tomi Valkeinen wrote:
 Hi,

 On 2013-03-12 15:37, Laurent Pinchart wrote:
 Hi Tomi,

 Thanks for the patch.

 On Tuesday 12 March 2013 12:19:38 Tomi Valkeinen wrote:
 Structs videomode and display_timing have rather long field names for
 the timing values. Nothing wrong with that as such, but this patch
 changes them to abbreviations for the following reasons:

 * The timing values often need to be used in calculations, and long
   field names makes their direct use clumsier.

 * The current names are a bit of a mishmash: some words are used as
   such, some are shortened, and for some only first letter is used. Some
   names use underscode, some don't. All this makes it difficult to
   remember what the field names are.

 * The abbreviations used in this patch are very common, and there
   shouldn't be any misunderstanding about their meaning.

 Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: Steffen Trumtrar s.trumt...@pengutronix.de
 ---

 I have no strong opinion on this, but I find the existing names easier to 
 read. I might be biased by having read them often though.

 Yes, the last patch was a bit of a teaser =). I found myself typoing
 them a lot, using helper local variables to shorten the code lines, and
 as I mention in the description, I find them a bit of a mishmash. So,
 while they're not used in any drivers yet, I thought it'd be worth a
 shot to change them.
 
 Imo the new names look quite a bit more ugly and less readable, for very
 few saved chars. And at least for i915.ko development it's been a long
 time since I've last had to type them ... Maybe the real problem is that
 we have a few too many video mode structures and can't properly share
 them?

I guess it's a matter of taste. But I've received three I don't like
the new names comments, and no positive comments, so I'm dropping the
last patch. The first four should be fine, though.

And yes, we should definitely try to use only this new videomode struct
in the future everywhere in the kernel. It sure would make me remember
the names better =).

 Tomi




signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Stable kernel 3.8.3 appears to break displayport on intel gen4

[Bjørn Mork]

Sergio Callegari sergio.calleg...@gmail.com writes:

 This is just a short note to let you know that after installing 3.8.3,
 display port stopped working on my laptop. Going back to 3.8.2 brought
 it back to life.
 This has been tested with the ubuntu mainline kernels that should be
 vanilla stable kernels. Hope this is not an incorrect report due to
 something wrong on their side. Laptop is a DELL E6500 with intel gen4
 integrated graphics (Intel Corporation Mobile 4 Series Chipset
 Integrated Graphics Controller (rev 07)).
 With 3.8.3, xrandr does not report anymore the external monitor when
 it is actually attached via displayport.

I can confirm seeing this bug on:

# lspci -nnvvvs 00:02.0
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series 
Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA 
controller])
Subsystem: Lenovo Device [17aa:20e4]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 45
Region 0: Memory at f000 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at d000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 1800 [size=8]
Expansion ROM at unassigned [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c  Data: 4152
Capabilities: [d0] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: i915



Looking through the changes from v3.8.2 to v3.8.3, there weren't really
that many suspects.  This partial (to avoid having to change any
following patches) revert of commit 2a98104 (drm/i915: reorder setup
sequence to have irqs for output setup) fixes the problem for me.  I
have no idea why, so I leave it to Daniel and the other wise men working
on this driver to explain and cleanup :)


---
 drivers/gpu/drm/i915/i915_dma.c |   14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5206f24..b15b65d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1297,21 +1297,19 @@ static int i915_load_modeset_init(struct drm_device 
*dev)
if (ret)
goto cleanup_vga_switcheroo;
 
-   ret = drm_irq_install(dev);
-   if (ret)
-   goto cleanup_gem_stolen;
-
-   /* Important: The output setup functions called by modeset_init need
-* working irqs for e.g. gmbus and dp aux transfers. */
intel_modeset_init(dev);
 
ret = i915_gem_init(dev);
if (ret)
-   goto cleanup_irq;
+   goto cleanup_gem_stolen;
+
+   intel_modeset_gem_init(dev);
 
INIT_WORK(dev_priv-console_resume_work, intel_console_resume);
 
-   intel_modeset_gem_init(dev);
+   ret = drm_irq_install(dev);
+   if (ret)
+   goto cleanup_gem;
 
/* Always safe in the mode setting case. */
/* FIXME: do pre/post-mode set stuff in core KMS code */


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

Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Daniel Vetter]

On Mon, Mar 18, 2013 at 10:12:49AM +0100, Jiri Kosina wrote:
 On Fri, 15 Mar 2013, Yinghai Lu wrote:
 
   Just a datapoint -- I have put a trivial debugging patch in place, and it
   reveals that nobody cared for irq 16 happens long after last
  
   I915_WRITE(GMBUS4 + reg_offset, 0);
  
   has been performed in gmbus_wait_hw_status(). On the other hand, if I
   comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(),
   then it of course falls back to GPIO bit-banging, but the nobody cared
   for irq 16 is gone.
  
   So it seems like something gets severely confused by the I915_WRITE to
   GMBUS4 + reg_offset. So far this seems to have been reported solely on
   Lenovos as far as I can see (although a completely different types), so it
   might be some platform-specific quirk?
  
   Honestly, I still don't understand how all the GMBUS stuff relates to IRQ
   16 at all.
  
  that device is using
  i915 :00:02.0: irq 44 for MSI/MSI-X
  
  so can you try to boot with pci=nomsi?
 
 Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost 
 interrupts go away.
 
 My understanding from the other mail is that DAniel Vetter already has an 
 idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully 
 this datapoint regarding MSI will fit into it.

Yep, there's a big comment in the irq handler for that chipset that we
have a gaping race with when using MSI interrupts. Although the comment
bodly claims that the race is small enough to avoid the dreaded nobody
cared message. Looks like gmbus is good at hitting that race - on newer
chips it already brought up a similar race in handling pch interrupts.

Can you please give the below patch a whirl? It removes the probably race
msi race avoidance code and replaces it with the same trick Paulo used to
fix pch irq handling races.

Thanks, Daniel
---
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3c7bb04..13de12e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2684,7 +2684,7 @@ static irqreturn_t i965_irq_handler(int irq, void *arg)
 {
struct drm_device *dev = (struct drm_device *) arg;
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
-   u32 iir, new_iir;
+   u32 iir, new_iir, ier;
u32 pipe_stats[I915_MAX_PIPES];
unsigned long irqflags;
int irq_received;
@@ -2692,9 +2692,14 @@ static irqreturn_t i965_irq_handler(int irq, void *arg)
 
atomic_inc(dev_priv-irq_received);
 
+   /* irq race avoidance, copypasta from Paulo's PCH irq fix */
+   ier = I915_READ(IER);
+   I915_WRITE(IER, 0);
+   POSTING_READ(IER);
+
iir = I915_READ(IIR);
 
-   for (;;) {
+   do {
bool blc_event = false;
 
irq_received = iir != 0;
@@ -2792,7 +2797,10 @@ static irqreturn_t i965_irq_handler(int irq, void *arg)
 * stray interrupts.
 */
iir = new_iir;
-   }
+   } while (0);
+
+   I915_WRITE(IER, ier);
+   POSTING_READ(IER);
 
i915_update_dri1_breadcrumb(dev);
 
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Stable kernel 3.8.3 appears to break displayport on intel gen4

[Daniel Vetter]

On Mon, Mar 18, 2013 at 04:59:35PM +0100, Bjørn Mork wrote:
 Sergio Callegari sergio.calleg...@gmail.com writes:
 
  This is just a short note to let you know that after installing 3.8.3,
  display port stopped working on my laptop. Going back to 3.8.2 brought
  it back to life.
  This has been tested with the ubuntu mainline kernels that should be
  vanilla stable kernels. Hope this is not an incorrect report due to
  something wrong on their side. Laptop is a DELL E6500 with intel gen4
  integrated graphics (Intel Corporation Mobile 4 Series Chipset
  Integrated Graphics Controller (rev 07)).
  With 3.8.3, xrandr does not report anymore the external monitor when
  it is actually attached via displayport.
 
 I can confirm seeing this bug on:
 
 # lspci -nnvvvs 00:02.0
 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series 
 Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA 
 controller])
 Subsystem: Lenovo Device [17aa:20e4]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- 
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 0
 Interrupt: pin A routed to IRQ 45
 Region 0: Memory at f000 (64-bit, non-prefetchable) [size=4M]
 Region 2: Memory at d000 (64-bit, prefetchable) [size=256M]
 Region 4: I/O ports at 1800 [size=8]
 Expansion ROM at unassigned [disabled]
 Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
 Address: fee0300c  Data: 4152
 Capabilities: [d0] Power Management version 3
 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
 PME(D0-,D1-,D2-,D3hot-,D3cold-)
 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
 Kernel driver in use: i915
 
 
 
 Looking through the changes from v3.8.2 to v3.8.3, there weren't really
 that many suspects.  This partial (to avoid having to change any
 following patches) revert of commit 2a98104 (drm/i915: reorder setup
 sequence to have irqs for output setup) fixes the problem for me.  I
 have no idea why, so I leave it to Daniel and the other wise men working
 on this driver to explain and cleanup :)

Already taken care of hopefully:

http://lists.freedesktop.org/archives/intel-gfx/2013-March/025767.html

My apologies to everyone who's suffering through this breakage, it looks
like I've managed to serious burn myself with an innocent looking stable
backport :(

Yours, Daniel

 
 
 ---
  drivers/gpu/drm/i915/i915_dma.c |   14 ++
  1 file changed, 6 insertions(+), 8 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
 index 5206f24..b15b65d 100644
 --- a/drivers/gpu/drm/i915/i915_dma.c
 +++ b/drivers/gpu/drm/i915/i915_dma.c
 @@ -1297,21 +1297,19 @@ static int i915_load_modeset_init(struct drm_device 
 *dev)
   if (ret)
   goto cleanup_vga_switcheroo;
  
 - ret = drm_irq_install(dev);
 - if (ret)
 - goto cleanup_gem_stolen;
 -
 - /* Important: The output setup functions called by modeset_init need
 -  * working irqs for e.g. gmbus and dp aux transfers. */
   intel_modeset_init(dev);
  
   ret = i915_gem_init(dev);
   if (ret)
 - goto cleanup_irq;
 + goto cleanup_gem_stolen;
 +
 + intel_modeset_gem_init(dev);
  
   INIT_WORK(dev_priv-console_resume_work, intel_console_resume);
  
 - intel_modeset_gem_init(dev);
 + ret = drm_irq_install(dev);
 + if (ret)
 + goto cleanup_gem;
  
   /* Always safe in the mode setting case. */
   /* FIXME: do pre/post-mode set stuff in core KMS code */
 
 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [pull] drm-intel-next

[Stéphane Marchesin]

-lkml

On Sun, Mar 17, 2013 at 12:46 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Fri, Mar 15, 2013 at 3:11 AM, Stéphane Marchesin
 stephane.marche...@gmail.com wrote:
   drm/i915: read out the modeset hw state at load and resume time
 This commit regresses modeset on the samsung series 5 chromebook (it
 is basically a pineview machine with an lvds panel). I don't seem to
 be able to set any mode on it any longer.

 Does that mean the kernel refuses to set the mode, or that you get a
 black screen?


I get a black screen.

 For starters I guess we need:
 - drm.debug=0xe dmesg from just before that commit
 - same for latest 3.9-rc kernels, presuming it's not broken there

 Latest upstream has a minor chance to work better I think since we've
 improved the pfit handling in the setup and teardown sequence a bit.

 Generally lvds has been hitmiss on way too many machines
 unfortunately with things randomly breaking and getting fixed again
 (e.g. one of Chris' machines works again with the new code ...). And
 the commit above doesn't really change much in the code itself but it
 does change the order (and timing) of the different enable/disable
 codepaths.

So I did look at the thing a bit, and it triggers the workaround
if (INTEL_INFO(dev)-gen  4  !intel_check_plane_mapping(crtc)) {
which seems to be part of the problem (but not the whole problem as
removing that gets me a corrupted display, looks like the second pipe
stays enabled then).

Stéphane
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62434] [bisected] 3284.073] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libllvmradeon9.2.0.so: undefined symbol: lp_build_tgsi_intrinsic)

[bugzilla-daemon]

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

--- Comment #14 from LoneVVolf lonew...@xs4all.nl ---
Trying to summarize

I've looked a bit more at bug #59238, and if i understand correctly the problem
with building xa tracker was that symbols were exported that are not supposed
to be visible outside of the library itself ?

By adding the VISIBILITY_CFLAGS and VISIBILITY_CXXFLAGS changes in the f70c385
commit, the troublesome symbols were removed.
A consequence however was that symbols needed for r600_dri.so to call
libllvmradeon9.2.0.so were no longer present.

Including $(top_builddir)/src/gallium/auxiliary/libgallium.la in
src/gallium/drivers/radeon/Makefile.am makes sure all needed symbols are
present, but has a size increase of libllvmradeon9.2.0 as downside.

To counter the size increase, switching to a shared libgallium is proposed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Chris Wilson]

On Mon, Mar 18, 2013 at 08:19:03PM +0100, Daniel Vetter wrote:
 On Mon, Mar 18, 2013 at 10:12:49AM +0100, Jiri Kosina wrote:
  On Fri, 15 Mar 2013, Yinghai Lu wrote:
  
Just a datapoint -- I have put a trivial debugging patch in place, and 
it
reveals that nobody cared for irq 16 happens long after last
   
I915_WRITE(GMBUS4 + reg_offset, 0);
   
has been performed in gmbus_wait_hw_status(). On the other hand, if I
comment out both GMBUS4 register offset writes in 
gmbus_wait_hw_status(),
then it of course falls back to GPIO bit-banging, but the nobody cared
for irq 16 is gone.
   
So it seems like something gets severely confused by the I915_WRITE to
GMBUS4 + reg_offset. So far this seems to have been reported solely on
Lenovos as far as I can see (although a completely different types), so 
it
might be some platform-specific quirk?
   
Honestly, I still don't understand how all the GMBUS stuff relates to 
IRQ
16 at all.
   
   that device is using
   i915 :00:02.0: irq 44 for MSI/MSI-X
   
   so can you try to boot with pci=nomsi?
  
  Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost 
  interrupts go away.
  
  My understanding from the other mail is that DAniel Vetter already has an 
  idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully 
  this datapoint regarding MSI will fit into it.
 
 Yep, there's a big comment in the irq handler for that chipset that we
 have a gaping race with when using MSI interrupts. Although the comment
 bodly claims that the race is small enough to avoid the dreaded nobody
 cared message. Looks like gmbus is good at hitting that race - on newer
 chips it already brought up a similar race in handling pch interrupts.
 
 Can you please give the below patch a whirl? It removes the probably race
 msi race avoidance code and replaces it with the same trick Paulo used to
 fix pch irq handling races.

Still nobody cares about irq16.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: How to manage OMAP display drivers in the future

[Rob Clark]

On Wed, Mar 13, 2013 at 4:57 AM, Tomi Valkeinen to...@iki.fi wrote:
 Hi Dave,

 I'm writing this mail to get some ideas how we should manage OMAP's
 display drivers in the future.

 As a short intro, we have the following players around:

 omapdss - omapdss handles the DSS (display subsystem) hardware. omapdss
 doesn't do any buffer management or expose any userspace API (except a
 few sysfs files), so it doesn't do anything by itself.
 (drivers/video/omap2/dss/)

 panel drivers - Drivers for various panel models. The panel drivers use
 omapdss API to manage the video bus. (drivers/video/omap2/displays/)

 omapfb - Framebuffer driver, uses omapdss to handle the HW.
 (drivers/video/omap2/omapfb/)

 omap_vout - V4L2 driver for showing video, uses omapdss to handle the
 HW. (drivers/media/platform/omap/)

 omapdrm - DRM driver, uses omapdss to handle the HW.
 (drivers/gpu/drm/omapdrm/)

 omapdss and the panel drivers form the lowest level layer. omapfb and
 omap_vout can be used at the same time, but omapdrm must be used alone,
 without omapfb or omap_vout.

 omapfb and omap_vout are not much developed anymore, even though they
 are still commonly used. Most of the development happens in omapdss,
 panel drivers and omapdrm.

I'd guess if changes in omapfb or omap_vout are mainly just updates
resulting from omapdss changes, maybe merging it all via drm tree
would make most sense..

Although I tend to think life would be easier w/ some copy/paste.. Ie.
just move a copy of omapdss into omapdrm directory and start
refactoring.. Offhand I think at least in the hdmi code, I think we
could jettison the big timings table, and avi-infoframe stuff and use
drm helpers.  Probably other places where we could get rid of code
that duplicates stuff that drm does (or could) provide helpers for..

BR,
-R

 So that's what we have now. In the distant future I see omapfb and
 omap_vout disappear totally, the panel drivers would be made generic
 using Common Display Framework, and omapdss and omapdrm would more or
 less be merged together. However, all that is still far away, and we
 need some plan to go forward for now.

 Most pressing question is how to get OMAP display patches merged. It
 seems that there's not really an fbdev maintainer for the time being,
 and fbdev tree has been the route for omapdss, panels and omapfb in the
 past. Now that omapdrm is the new main driver for omap display, fbdev
 would be somewhat wrong in any case.

 Dave, how would you feel about merging changes to all the above
 components through DRM tree? Merging all the above together would be the
 easiest way, as the changes may have dependencies to each other.

 As I said, most of the development should be in omapdss, panels and
 omapdrm. There would be an occasional fix for omapfb and omap_vout, or
 small changes when omapdss changes require changes elsewhere.

  Tomi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Revert a bunch of patches in stable kernels

[Greg KH]

On Mon, Mar 18, 2013 at 11:05:26AM +0100, Daniel Vetter wrote:
 Hi Gregall,
 
 So a recent stable backport to fix rc6 on ilk (which is disabled by
 default and with dubious power savings at best, unlike rc6 on snb and
 later) totally blew up all over the place:
 https://bugzilla.kernel.org/show_bug.cgi?id=55291
 https://lkml.org/lkml/2013/3/14/540
 
 There might be more, I'm still recovering from mail floods due to
 traveling last week. I think the right course of action is to revert
 the offending patch (plus anything depending upon it) and give up on
 rc6 on ilk in 3.8 - too messy. All bug reports confirmed that 3.9-rc
 kernels work as expected. Upstream commits to revert:
 
 15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9 drm/i915: enable irqs earlier
 when resuming
 52d7ecedac3f96fb562cb482c139015372728638 drm/i915: reorder setup
 sequence to have irqs for output setup

Thanks for tracking this down, I've reverted both of these patches now,
which should hopefully fix the issues reported.

greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [pull] drm-intel-next

[Daniel Vetter]

On Mon, Mar 18, 2013 at 8:35 PM, Stéphane Marchesin
stephane.marche...@gmail.com wrote:

 For starters I guess we need:
 - drm.debug=0xe dmesg from just before that commit
 - same for latest 3.9-rc kernels, presuming it's not broken there

 Latest upstream has a minor chance to work better I think since we've
 improved the pfit handling in the setup and teardown sequence a bit.

 Generally lvds has been hitmiss on way too many machines
 unfortunately with things randomly breaking and getting fixed again
 (e.g. one of Chris' machines works again with the new code ...). And
 the commit above doesn't really change much in the code itself but it
 does change the order (and timing) of the different enable/disable
 codepaths.

 So I did look at the thing a bit, and it triggers the workaround
 if (INTEL_INFO(dev)-gen  4  !intel_check_plane_mapping(crtc)) {
 which seems to be part of the problem (but not the whole problem as
 removing that gets me a corrupted display, looks like the second pipe
 stays enabled then).

Well, that particular piece of lore took a few trials to get right.
Can you please attach a drm.debug=0xe dmesg of the entire boot on
latest kernels?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Jiri Kosina]

On Mon, 18 Mar 2013, Yinghai Lu wrote:

  Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost
  interrupts go away.
 
  My understanding from the other mail is that DAniel Vetter already has an
  idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully
  this datapoint regarding MSI will fit into it.
 
 What is /proc/interrupts difference between with and without pci=nomsi ?
 
 drm is forced to share irq 16?

Yup, IRQ 16 is being shared, and one of the owners is i915.

-- 
Jiri Kosina
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Yinghai Lu]

On Mon, Mar 18, 2013 at 3:05 PM, Jiri Kosina jkos...@suse.cz wrote:
 On Mon, 18 Mar 2013, Yinghai Lu wrote:

  Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost
  interrupts go away.
 
  My understanding from the other mail is that DAniel Vetter already has an
  idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully
  this datapoint regarding MSI will fit into it.

 What is /proc/interrupts difference between with and without pci=nomsi ?

 drm is forced to share irq 16?

 Yup, IRQ 16 is being shared, and one of the owners is i915.

the vga report strange INTx status...

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA
controller])
Subsystem: Lenovo Device 20e4
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR- INTx+
Latency: 0
Interrupt: pin A routed to IRQ 44
Region 0: Memory at f200 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at d000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 1800 [size=8]
Expansion ROM at unassigned [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0100c  Data: 4142
Capabilities: [d0] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: i915
Kernel modules: i915

it should be INTx-, after we have set DisINTx+ in control.

So INTx can not be disabled after it get enabled before ?

the VGA on my T420 looks right.

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
Core Processor Family Integrated Graphics Controller (rev 09) (prog-if
00 [VGA controller])
Subsystem: Lenovo Device 21ce
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR- INTx-

Thanks

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/7] Consider G2D hardware restrictions.

[YoungJun Cho]

On Mar 19, 2013 3:01 AM, Rob Clark robdcl...@gmail.com wrote:

 Btw, what is the hw response to invalid input (ie. bottomtop, invalid
 size, etc)?


Unfortunately the IOMMU page fault is happened. So we need some codes for
protecting kernel.

Thank you~
Best regards YJ

 Ie. if it will just ignore the blit or raise an error irq which can be
 handled sanely, it could be ok to avoid the overhead of the cmdstream
 checking in the kernel.  The kernel part really just needs to ensure
 that userspace can't cause security problems (read/write access to
 non-gfx-buffers, or lock up the system, that sort of thing).  It
 doesn't need to guarantee that the results are sensible.

 BR,
 -R

 On Wed, Mar 13, 2013 at 5:03 AM, Inki Dae inki@samsung.com wrote:
  This patch set checks the contents of g2d command list from user
  is valid or not according to G2D hardware restrictions. For now,
  G2D driver wasn't considered for them properly.
 
  For this, this patch set includes relevant code cleaups, fixups
  and adds a new function to get buffer size to the gem to be
  accessed by G2D dma.
 
  Inki Dae (1):
drm/exynos: Add a new function to get gem buffer size
 
  YoungJun Cho (6):
drm/exynos: Fix error routine to getting dma addr.
drm/exynos: clear node object type at gem unmap
drm/exynos: Fix G2D core mulfunctioning issue
drm/exynos: Clean up some G2D codes for readability
drm/exynos: Deal with g2d buffer info more efficiently
drm/exynos: Check g2d cmd list for g2d restrictions
 
   drivers/gpu/drm/exynos/exynos_drm_g2d.c |  381
++-
   drivers/gpu/drm/exynos/exynos_drm_gem.c |   21 ++
   drivers/gpu/drm/exynos/exynos_drm_gem.h |5 +
   3 files changed, 349 insertions(+), 58 deletions(-)
 
  --
  1.7.4.1
 
  ___
  dri-devel mailing list
  dri-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/dri-devel
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel