.
--
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/20150803/e3240f32/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150803/7554c683/attachment.html>
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/20150803/45557620/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150803/fa59e356/attachment.html>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150803/89c9903a/attachment-0001.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150803/b994505b/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150803/677027f7/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150803/4429d487/attachment.html>
org/archives/dri-devel/attachments/20150803/16ed80bc/attachment.html>
On 2015ë
07ì 31ì¼ 09:32, Krzysztof Kozlowski wrote:
> On 28.07.2015 17:51, Joonyoung Shim wrote:
>> This is simplest solution about reported problem[1]. It's no problem to
>> clear channel only when iommu is enabled, if we consider that we cannot
>> recognize iommu errors when iommu is disable
On Mon, Aug 03, 2015 at 08:37:41AM -0600, Jonathan Corbet wrote:
> On Mon, 3 Aug 2015 10:23:19 +0200
> Daniel Vetter wrote:
>
> > > I'm wondering if we need a kernel summit session on commenting
> > > conventions, markdown-in-kerneldoc, etc? Maybe I'll stick a proposal out
> > > there.
> >
>
On Thu, Jul 30, 2015 at 11:50:29AM -0400, Theodore Ts'o wrote:
> On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
> > I have 4 patches in git://people.freedesktop.org/~danvet/drm fixes-stuff
> > but I couldn't test them yet since no dp mst here and I didn't find
> > anything that woul
We've had a few issues with atomic where subtle bugs in the encoder
picking logic lead to accidental self-stealing of the encoder,
resulting in a NULL connector_state->crtc in update_connector_routing
and subsequent.
Linus applied some duct-tape for an mst regression in
commit 27667f4744fc5a0f3e5
Apparently been in there since forever and fairly easy to hit when
hotplugging really fast. I can do that since my mst hub has a manual
button to flick the hpd line for reprobing. The resulting WARNING spam
isn't pretty.
Cc: Dave Airlie
Cc: stable at vger.kernel.org
Signed-off-by: Daniel Vetter
In
commit 8c7b5ccb729870e606321b3703e2c2e698c49a95
Author: Ander Conselvan de Oliveira
Date: Tue Apr 21 17:13:19 2015 +0300
drm/i915: Use atomic helpers for computing changed flags
we've switched over to the atomic version to compute the
crtc->encoder->connector routing from the i915 vari
With legacy helpers all the routing was already set up when calling
best_encoder and so could be inspected. But with atomic it's staged,
hence we need a new atomic compliant callback for drivers which need
to inspect the requested state and can't just decided the best encoder
statically.
This is n
On Mon, Aug 03, 2015 at 12:54:33PM +0200, Daniel Vetter wrote:
> On Mon, Aug 03, 2015 at 02:56:42PM +0530, Sudip Mukherjee wrote:
> > On Thu, Jul 23, 2015 at 07:36:12PM +0530, Sudip Mukherjee wrote:
> > > debugfs files are not necessary for the usual operation of the driver
> > > and the device. No
Hi Gustavo,
For 1 through 9 merged. And I guess you have the rest we have to review
but this patch series doesn't have consistency of previous, v2.
So please, post the rest again re-basing on top of exynos-drm-next.
Thanks,
Inki Dae
On 2015ë
07ì 30ì¼ 05:11, Gustavo Padovan wrote:
> Hi Inki
the driver uses (pitch >>
6) it looks like it could work).
--
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/20150803/d15705cb/attachment.html>
From: Gustavo Padovan
struct exynos_drm_encoder was justing wrapping struct drm_encoder, it had
only a drm_encoder member and the internal exynos_drm_encoders ops that
was directly mapped to the drm_encoder helper funcs.
So now exynos DRM uses struct drm_encoder directly, this removes
completely
From: Gustavo Padovan
As we are removing the exynos encoder move the encoder setup operation
directly inside the exynos_drm_load()
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 12 ++--
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 13 -
d
From: Gustavo Padovan
This functions was just hiding the encoder and connector creation in
a way that was less clean than if we get rid of it. For example,
exynos_encoder ops had .create_connector() defined only because we were
handing off the encoder and connector creation to
exynos_drm_create_e
From: Gustavo Padovan
.commit() is not used anymore, Exynos encoders now follow the
.enable()/.disable() semantics from drm atomic core, so remove this
callback.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 --
drivers/gpu/drm/exynos/exynos_drm_encoder.c |
From: Gustavo Padovan
exynos_dp_commit() was getting called twice by exynos encoder core, once
inside the .enable() call and another time by .commit() itself.
The remove of the second call caused the wake of a bug, the operations
orders inside exynos_dp_commit was wrong and we had to move
exynos
From: Gustavo Padovan
hdmi_commit() was getting called twice by exynos encoder core, once inside
the .enable() call and another time by .commit() itself.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
From: Gustavo Padovan
This struct was just representing encoder information, it was a member of
struct exynos_drm_encoder, so any code trying to access encoder data would
have to go through the encoder struct, get the display struct and then get
the data it want.
During this patchset we also rea
From: Gustavo Padovan
All CRTCs can only be LCD, HDMI or VIDI, so basically all CRTCs will be a
possible CRTCs. This patch removes an extra function with switch that was
only checking if the CRTC type was one of those three above.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exyno
From: Gustavo Padovan
These two display_ops are not used anywhere, remove them.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
From: Gustavo Padovan
phy_power_on() and phy_power_off() already checks for NULL pointer.
This patch removes the wrappers exynos_dp_phy_init() and
exynos_dp_phy_exit() since the only think they were doing was a check for
NULL phy.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exyno
From: Gustavo Padovan
The DRM Core doesn't have a dpms() operation anymore, everything
now is enable() or disable().
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 37
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 36
drivers/
From: Gustavo Padovan
Hi,
This patchset is another important step in the exynos clean up, it removes
two exynos internal structs in favor of wider use of struct drm_encoder.
Structs exynos_drm_display and exynos_drm_encoder were doing exactly what
struct drm_encoder does so remove them makes th
t part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150803/33f2ecd2/attachment.html>
On Sat, Aug 1, 2015 at 9:55 AM, Nicolas Iooss
wrote:
> gfx_v7_0_print_status contains a for loop on variable queue which does
> not update this variable between each iteration. This is bug is
> reported by clang while building allmodconfig LLVMLinux on x86_64:
>
> drivers/gpu/drm/amd/amdgpu/g
archives/dri-devel/attachments/20150803/b38c527d/attachment.html>
On Thu, Jul 23, 2015 at 07:36:12PM +0530, Sudip Mukherjee wrote:
> debugfs files are not necessary for the usual operation of the driver
> and the device. No need to check for the return values from the debugfs
> file creation. Even if one debugfs file fails to create we try with the
> next debugfs
On Mon, Aug 03, 2015 at 10:24:53AM -0700, Linus Torvalds wrote:
> On Mon, Aug 3, 2015 at 9:25 AM, Theodore Ts'o wrote:
> >
> > I've just tried pulling in your updated fixes-stuff, and it avoids the
> > oops and allows external the monitor to work correctly.
>
> Good. Have either of you tested the
From: Vincent Abriou
Better fit STI hardware structure.
Planes are no more responsible of updating mixer information such
as z-order and status. It is now up to the CRTC atomic flush to
do it. Plane actions (enable or disable) are performed atomically.
Disabling of a plane is synchronize with the
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150803/0f268638/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150803/4f848e3a/attachment.html>
Hi,
On 07/31/2015 04:48 PM, Rob Clark wrote:
> On Fri, Jul 31, 2015 at 8:58 AM, Boris Brezillon
> wrote:
>> Hi Rob,
>>
>> On Fri, 31 Jul 2015 08:13:59 -0400
>> Rob Clark wrote:
>>
(...)
>>
>> Another problem I've seen with some drm bridge drivers is that they
>> directly create their own conne
From: David Zhang
Signed-off-by: David Zhang
Reviewed-by: Alex Deucher
Reviewed-by: Jammy Zhou
Reviewed-by: Christian K?nig
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/
VCE on fiji is single pipe only.
Reviewed-by: David Zhang
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 5 +
drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 7 +++
drivers/gpu/drm/amd/amdgpu/vi.c | 7 +++
3 files changed, 19 insertions(+)
diff --git a/
From: David Zhang
Signed-off-by: David Zhang
Reviewed-by: Alex Deucher
Reviewed-by: Jammy Zhou
Reviewed-by: Christian K?nig
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 5 +
drivers/gpu/drm/amd/amdgpu/vi.c | 7 +++
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/
From: David Zhang
Signed-off-by: David Zhang
Reviewed-by: Alex Deucher
Reviewed-by: Jammy Zhou
Reviewed-by: Christian K?nig
---
drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 31 +++
drivers/gpu/drm/amd/amdgpu/vi.c| 7 +++
2 files changed, 38 insertions(+)
v2: agd5f: fix the rb setup.
Signed-off-by: David Zhang
Reviewed-by: Alex Deucher
Reviewed-by: Jammy Zhou
Reviewed-by: Christian K?nig
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 109 +-
drivers/gpu/drm/amd/amdgpu/vi.c | 7 +++
2 files changed, 115 inse
From: David Zhang
v2: agd5f: fix up XDMA golden settings
Signed-off-by: David Zhang
Reviewed-by: Alex Deucher
Reviewed-by: Jammy Zhou
Reviewed-by: Christian K?nig
---
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 23 +++
drivers/gpu/drm/amd/amdgpu/vi.c| 7 +++
2
From: David Zhang
v2: agd5f: prepare for release
Signed-off-by: David Zhang
Reviewed-by: Alex Deucher
Reviewed-by: Jammy Zhou
Reviewed-by: Christian K?nig
---
drivers/gpu/drm/amd/amdgpu/Makefile | 1 +
drivers/gpu/drm/amd/amdgpu/fiji_dpm.c| 181 +++
drivers/gpu/drm/amd/amdgpu
From: David Zhang
v2: agd5f: prepare for release
Signed-off-by: David Zhang
Reviewed-by: Alex Deucher
Reviewed-by: Jammy Zhou
Reviewed-by: Christian K?nig
---
.../gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_d.h | 1246
.../drm/amd/include/asic_reg/smu/smu_7_1_3_enum.h | 1282 +
...
From: David Zhang
Signed-off-by: David Zhang
Reviewed-by: Alex Deucher
Reviewed-by: Jammy Zhou
Reviewed-by: Christian K?nig
---
drivers/gpu/drm/amd/amdgpu/vi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index b
From: David Zhang
Signed-off-by: David Zhang
Reviewed-by: Alex Deucher
Reviewed-by: Jammy Zhou
Reviewed-by: Christian K?nig
---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 25 +
drivers/gpu/drm/amd/amdgpu/vi.c | 9 -
2 files changed, 33 insertions(+), 1 del
From: David Zhang
Signed-off-by: David Zhang
Reviewed-by: Alex Deucher
Reviewed-by: Jammy Zhou
Reviewed-by: Christian K?nig
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++
drivers/gpu/drm/amd/amdgpu/vi.c| 34 ++
drivers/gpu/drm/amd/include/amd_
This patch set adds Fiji support to the open source amdgpu
driver. The relevant mesa and ddx changes have also been
sent out the their respective mailing lists. Support for
Fiji is complete (GFX, SDMA, UVD, VCE, etc.) except for
power management. Power management for dGPUs is still
in progress a
On 08/03/2015 12:59 PM, Randy Dunlap wrote:
> On 07/31/15 14:06, Danilo Cesar Lemes de Paula wrote:
>> Describing arguments at top of a struct definition works fine
>> for small/medium size structs, but it definitely doesn't work well
>> for struct with a huge list of elements.
>>
>> Keeping the
On Mon, Aug 03, 2015 at 02:56:42PM +0530, Sudip Mukherjee wrote:
> On Thu, Jul 23, 2015 at 07:36:12PM +0530, Sudip Mukherjee wrote:
> > debugfs files are not necessary for the usual operation of the driver
> > and the device. No need to check for the return values from the debugfs
> > file creation
On Mon, Aug 03, 2015 at 05:27:29PM +0200, Daniel Vetter wrote:
>
> Ok I updated fixes-stuff with just 2 patches which seem to be enough to
> fix it. Plus a patch to convert Linus' hack into something we can keep
> plus a drive-by WARNING fix in mst that got in the way for me.
>
> Seems to work he
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/drm_atomic_helper.c
between commit:
27667f4744fc ("i915: temporary fix for DP MST docking station NULL pointer
dereference")
from Linus' tree and commit:
fc596660dd4e ("drm/atomic: add connectors_c
u 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/20150803/6295279e/attachment.html>
On 07/28/2015 08:57 AM, Bjorn Andersson wrote:
> On Sun 26 Jul 23:16 PDT 2015, Archit Taneja wrote:
>
>> From: Lars-Peter Clausen
>>
> [..]
>> diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
>
> [..]
>
>>
>> +static const struct of_device_id adv7511_of_ids[] = {
>> +
From: Tvrtko Ursulin
Sync up with new kernel features as per commits:
e3eb3250d84ef97b766312345774367b6a310db8
93b81f5102a7cd270a305c2741b17c8d44bb0629
b5ff6e1637b683d5996ae11ac29afe406c0bee90
8c4f83fb1e8bf317e894f62d17a63c32b7a6b75e
570655b09b065d2fff1b8ab9bdb8308f4c5a05a3
Signed-off-by: Tvrtk
On Mon, Aug 3, 2015 at 9:25 AM, Theodore Ts'o wrote:
>
> I've just tried pulling in your updated fixes-stuff, and it avoids the
> oops and allows external the monitor to work correctly.
Good. Have either of you tested the suspend/resume behavior? Is that fixed too?
> However
On Sat, Aug 01, 2015 at 01:22:10PM +0200, Jonathan Corbet wrote:
> On Fri, 31 Jul 2015 18:06:45 -0300
> Danilo Cesar Lemes de Paula wrote:
>
> > Describing arguments at top of a struct definition works fine
> > for small/medium size structs, but it definitely doesn't work well
> > for struct with
On Mon, Aug 3, 2015 at 8:03 AM, Andrzej Hajda wrote:
> Hi,
>
> On 07/31/2015 04:48 PM, Rob Clark wrote:
>> On Fri, Jul 31, 2015 at 8:58 AM, Boris Brezillon
>> wrote:
>>> Hi Rob,
>>>
>>> On Fri, 31 Jul 2015 08:13:59 -0400
>>> Rob Clark wrote:
>>>
>
> (...)
>
>>>
>>> Another problem I've seen with
On Fri, Jul 31, 2015 at 08:53:04AM -0700, Sinclair Yeh wrote:
> This patch: Reviewed-by: Sinclair Yeh
>
> On Fri, Jul 31, 2015 at 02:08:24PM +0530, Viresh Kumar wrote:
> > IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there
> > is no need to do that again from its callers. Dro
On Fri, Jul 17, 2015 at 10:26 AM, Laurent Pinchart
wrote:
> The DU0 clock is an MSTP clock, child of the CPG ZX clock.
>
> Signed-off-by: Laurent Pinchart
Acked-by: by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond i
On 07/31/15 14:06, Danilo Cesar Lemes de Paula wrote:
> Describing arguments at top of a struct definition works fine
> for small/medium size structs, but it definitely doesn't work well
> for struct with a huge list of elements.
>
> Keeping the arguments list inside the struct body makes it easie
On Mon, 3 Aug 2015 10:23:19 +0200
Daniel Vetter wrote:
> > I'm wondering if we need a kernel summit session on commenting
> > conventions, markdown-in-kerneldoc, etc? Maybe I'll stick a proposal out
> > there.
>
> Might be useful, but I'm not sure how many people really would actively
> work
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/20150803/ece6ef9a/attachment.html>
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/20150803/4be2079d/attachment.html>
rver: (1.16.4-1 => 1.17.2-4)
xorg-server-common: (1.16.4-1 => 1.17.2-4)
xorg-server-devel: (1.16.4-1 => 1.17.2-4)
--
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/20150803/b5bd00d9/attachment.html>
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/20150803/0b4f192a/attachment-0001.html>
dri-devel/attachments/20150803/3db947fa/attachment.html>
file a bug against libelf1.
--
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/20150803/d3d522d5/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150803/3f698895/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150803/49ea2da9/attachment.html>
On 31/07/15 19:11, Bryan O'Donoghue wrote:
> On 31/07/15 17:43, Bryan O'Donoghue wrote:
>> On 31/07/15 17:36, Ilia Mirkin wrote:
>>> Do you have a reproducible way of achieving the multiple buffer on
>>> validation list thing?
Ilia, Peter.
I've filed a bug for you here :
https://bugs.freedesktop
75 matches
Mail list logo
