On Wed, 12 Dec 2012, Damien Lespiau wrote:
> From: Damien Lespiau
>
> It's a bit useless to print out an all null DPCD when we are
> disconnected and just clutter the debug logs.
NAK.
Please have a look at intel_dp_detect_dpcd(). There are a number of ways
to get a non-zero DPCD that lead to so
On Wed, 12 Dec 2012, Damien Lespiau wrote:
> From: Damien Lespiau
>
> Those status bits don't follow the usual pattern: _MASK (those bits are
> write 1 to clear, useful to select the value we want to read) and the
> values shifted by the same amount.
>
> Cleaned that that up when poking at the re
On Wed, 12 Dec 2012 19:50:39 +, Damien Lespiau
wrote:
> From: Damien Lespiau
>
> If you unplug the hdmi connector slowly enough, the hotplug interrupt
> fires but then the kernel code tries to read the EDID and succeeds
> (because the connector is still half connected, the HPD pin is shorte
For seqno comparison to work they have to be less than UINT32_MAX/2
apart. So when crossing the half way of seqno space, be careful not
to sync anything as this causes gpu hangs. Do real test with
syncing only when we are about to wrap.
v2: Don't spam if no rendercopy was found, only warn once
---
->cursor_move uses mostly the same facilities in drivers as
->cursor_set, so pretty much nothing to fix up:
- ast/gma500/i915: They all use per-crtc registers to update the
cursor position. ast again touches the global cursor cache, but
that's ok since there's only one crtc.
- nouveau: nv50+
With more fine-grained locking we can no longer rely on the big
mode_config lock to prevent concurrent access to mode resources
like framebuffers. Instead a framebuffer becomes accessible to
other threads as soon as it is added to the relevant lookup
structures. Hence it needs to be fully set up by
For user framebuffers it's easier to just inline the
exynos_drm_framebuffer_init helper instead of trying to adjust it -
most of the things that helper sets up need to be overwritten anyway
again due to the multiple backing storage objects support exynos has,
but does not use for the fbdev.
Signed
---
drivers/gpu/drm/shmobile/Kconfig |2 +-
drivers/staging/imx-drm/Kconfig |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/shmobile/Kconfig b/drivers/gpu/drm/shmobile/Kconfig
index 7e7d52b..1cf8566 100644
--- a/drivers/gpu/drm/shmobile/Kconfig
+++ b/
On Wed, 12 Dec 2012, Damien Lespiau wrote:
> From: Damien Lespiau
>
> If you unplug the hdmi connector slowly enough, the hotplug interrupt
> fires but then the kernel code tries to read the EDID and succeeds
> (because the connector is still half connected, the HPD pin is shorter
> than the othe
On Wed, 12 Dec 2012, Damien Lespiau wrote:
> From: Damien Lespiau
>
> Just like:
>
> commit a93cd34234db2269fa2481464ffd39263d617aed
This is your local commit id, and will be meaningless upstream.
Otherwise,
Reviewed-by: Jani Nikula
> Author: Damien Lespiau
> Date: Wed Dec 12 19:37:22
---
drivers/gpu/drm/shmobile/Kconfig |2 +-
drivers/staging/imx-drm/Kconfig |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/shmobile/Kconfig b/drivers/gpu/drm/shmobile/Kconfig
index 7e7d52b..1cf8566 100644
--- a/drivers/gpu/drm/shmobile/Kconfig
+++ b/
Noticed while reviewing the fence locking in the radeon pageflip
handler.
v2: Instead of grabbing the bdev->fence_lock in object_transfer just
move the single callsite of that function a few lines, so that it is
protected by the fence_lock. Suggested by Jerome Glisse.
v3: Fix typo in commit messa
On Wed, Dec 12, 2012 at 02:06:50PM +0100, Daniel Vetter wrote:
> *drumroll*
>
> The basic idea is to protect per-crtc state which can change without
> touching the output configuration with separate mutexes, i.e. all the
> input side state to a crtc like framebuffers, cursor settings or plane
> c
On Thu, Dec 13, 2012 at 12:38 PM, Ville Syrjälä
wrote:
>> And if we _really_ want such semantics, we can always get them by
>> introducing another pageflip mutex between the mode_config.mutex and
>> the individual crtc locks. Pageflips crossing more than one crtc
>> would then need to take
On Thu, Dec 13, 2012 at 12:43:35PM +0200, Mika Kuoppala wrote:
> For seqno comparison to work they have to be less than UINT32_MAX/2
> apart. So when crossing the half way of seqno space, be careful not
> to sync anything as this causes gpu hangs. Do real test with
> syncing only when we are about
> -Original Message-
> From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org
> [mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On
> Behalf Of Daniel Vetter
> Sent: Thursday, December 13, 2012 8:05 PM
> To: DRI Development
> Cc: Nouveau Dev; Intel Graphic
Hi Inki,
I've pushed out the latest bits to
http://cgit.freedesktop.org/~danvet/drm/log/?h=drm-kms-locking with
some hacks on top to be able to compile all the arm drivers. Testing
feedback of the entire pile would be awesome, especially since you've
had some issues with framebuffer lifecycle and
On Wed, Dec 12, 2012 at 06:15:27PM +0200, ville.syrj...@linux.intel.com wrote:
> Another month, another massive atomic patchset.
>
> I managed to clean up warts left over from the modeset-rework rebase,
> but other than that I haven't really found the time to touch this too
> much since the last t
On Thu, Dec 13, 2012 at 12:54:44PM +0100, Daniel Vetter wrote:
> On Thu, Dec 13, 2012 at 12:38 PM, Ville Syrjälä
> wrote:
> >> And if we _really_ want such semantics, we can always get them by
> >> introducing another pageflip mutex between the mode_config.mutex and
> >> the individual crtc
On Thu, Dec 13, 2012 at 03:17:38PM +0100, Daniel Vetter wrote:
> On Wed, Dec 12, 2012 at 06:15:27PM +0200, ville.syrj...@linux.intel.com wrote:
> > Another month, another massive atomic patchset.
> >
> > I managed to clean up warts left over from the modeset-rework rebase,
> > but other than that
2012/12/13 Daniel Vetter
> Hi Inki,
>
> I've pushed out the latest bits to
> http://cgit.freedesktop.org/~danvet/drm/log/?h=drm-kms-locking with
> some hacks on top to be able to compile all the arm drivers. Testing
> feedback of the entire pile would be awesome, especially since you've
> had som
From: Damien Lespiau
Those status bits don't follow the usual pattern: _MASK (those bits are
write 1 to clear, useful to select the value we want to read) and the
values shifted by the same amount.
Cleaned that that up when poking at the register for testing purposes,
might as well upstream that
From: Damien Lespiau
If you unplug the hdmi connector slowly enough, the hotplug interrupt
fires but then the kernel code tries to read the EDID and succeeds
(because the connector is still half connected, the HPD pin is shorter
than the others, and DDC works). Since EDID succeeds it thinks the
m
From: Damien Lespiau
Just like:
Author: Damien Lespiau
Date: Wed Dec 12 19:37:22 2012 +
drm/i915/hdmi: Read the HPD status before trying to read the EDID
But this time for DiplayPort.
v2: Adapt to the ibx_ name change and don't add commit hash (Chris
Wilson, Jani Nikula)
Rev
From: Damien Lespiau
Moving the DPCD just after a successful read will allow to:
- log all DPCD reads (eDP ones, changes signalled by HPD IRQ)
- don't log it if we haven't been able to read it
v2: Be sure to log the DPCD when a downstream port does not have HPD
support and the branch dev
From: Damien Lespiau
CPT+ PCHs have different bit definition to read the HPD live status. I
don't have an ILK with digital ports handy, which is why this patch is
separate from the CPT+ implementation. If the docs don't lie, it should
all be fine though.
Signed-off-by: Damien Lespiau
---
drive
From: Damien Lespiau
The function doesn't use any of the registers mentioned, nor does it
return true or false. Hard to do worse. Remove it, the function is
absolutely descriptive enough to not need any comment.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_dp.c | 7 ---
1 f
A function to make it easy to collect any file or directory needed later.
---
tools/intel_gpu_abrt | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/tools/intel_gpu_abrt b/tools/intel_gpu_abrt
index 141a524..b243a5f 100755
--- a/tools/intel_gpu_abrt
+++ b/to
---
tools/intel_gpu_abrt | 12
1 file changed, 12 insertions(+)
diff --git a/tools/intel_gpu_abrt b/tools/intel_gpu_abrt
index b243a5f..fe3684d 100755
--- a/tools/intel_gpu_abrt
+++ b/tools/intel_gpu_abrt
@@ -8,6 +8,9 @@ get(){
cp -a ${@:1:$#-1} $tardir/${@:$#} 2>/dev/null
needed by other igt tools that are collecting more usefull information.
---
tools/intel_gpu_abrt | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/intel_gpu_abrt b/tools/intel_gpu_abrt
index fe3684d..9ca58c0 100755
--- a/tools/intel_gpu_abrt
+++ b/tools/intel_gpu_abrt
@@ -1,5 +1,10 @@
checking if file has been generated and output a template for a good bug report
---
tools/intel_gpu_abrt | 32
1 file changed, 32 insertions(+)
diff --git a/tools/intel_gpu_abrt b/tools/intel_gpu_abrt
index 9ca58c0..4fbff76 100755
--- a/tools/intel_gpu_abrt
+++ b/
On Thu, Dec 13, 2012 at 4:16 PM, Inki Dae wrote:
> How about rebasing this patch to top of
> git://people.freedesktop.org/~airlied/linux.git drm-next?
> Exynos's many patches have already been merged to drm-next. Or if you are
> ok, I'd like to rebase your patch to -next and test it. I don't care
On Thu, Dec 13, 2012 at 02:11:24PM -0200, Rodrigo Vivi wrote:
> checking if file has been generated and output a template for a good bug
> report
Slurped in all patches, thanks.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Thu, Dec 13, 2012 at 11:47:47PM +0800, Zhenyu Wang wrote:
> From Ben's AGP dependence removal change, "needs_dmar" flag has not
> been properly setup for new chips using new GTT init function. This
> one adds missed setting of that flag to make sure we do pci mappings
> with IOMMU enabled.
>
>
Hi Dave,
A few leftover fixes for 3.8:
- VIC support for hdmi infoframes with the associated drm helper, fixes
some black TVs (Paulo Zanoni)
- Modeset state check (and fixup if the BIOS messed with the hw) for
lid-open. modeset-rework fallout. Somehow the original reporter went
awol, so this
2012/12/14 Daniel Vetter
> On Thu, Dec 13, 2012 at 4:16 PM, Inki Dae wrote:
> > How about rebasing this patch to top of
> > git://people.freedesktop.org/~airlied/linux.git drm-next?
> > Exynos's many patches have already been merged to drm-next. Or if you are
> > ok, I'd like to rebase your patc
On Fri, 14 Dec 2012 00:00:07 +0100
Daniel Vetter wrote:
> On Thu, Dec 13, 2012 at 11:47:47PM +0800, Zhenyu Wang wrote:
> > From Ben's AGP dependence removal change, "needs_dmar" flag has not
> > been properly setup for new chips using new GTT init function. This
> > one adds missed setting of tha
Summary
We finished a new round of kernel testing. Generally, in this circle, 4 new bug
is filed, 10 bugs are still opened, 7 bugs are closed.
Test Environment
Kernel: (drm-intel-testing)f684fa122248e3a21c9db961eddee5d7010d731b
Some additional commit info:
Merge: 97a19a2 d4b1931
Author: Da
38 matches
Mail list logo
