Hi Linus,
radeon, i915 and nouveau fixes, all fixes for regressions or black
screens, or possible oopses,
I have an optional follow up to this for AMD as they have some new HW
support they'd like in, but I'm not sure how you are feeling at the
moment!
Dave.
The following changes since commi
This is support for the new AMD mullins APU, it pretty much just adds
support to the driver in the all the right places, and is pretty low risk
wrt other GPUs, however I'll leave it up to you if it fits with the
current release cycle,
Dave.
The following changes since commit 2a1235e53bed8fa11
So now I've been playing with MST I think get the feeling I might need
some explicit locking on the AUX channel, I think at the moment the
mode_config mutex implicitly defends the aux channel as the only real
paths into it are
a) from userspace connector probing,
b) from HPD irqs,
currently both
Sean,
On Tue, May 6, 2014 at 9:25 PM, Sean Paul wrote:
> On Mon, May 5, 2014 at 12:52 PM, Ajay Kumar
> wrote:
>> As of now, we can have only one bridge hanging off the encoder.
>> With this patch, we allow multiple bridges to hang onto the same encoder
>> with the use of a simple next_bridge p
Rob,
On Tue, May 6, 2014 at 9:42 PM, Rob Clark wrote:
> On Tue, May 6, 2014 at 11:55 AM, Sean Paul wrote:
>> On Mon, May 5, 2014 at 12:52 PM, Ajay Kumar
>> wrote:
>>> As of now, we can have only one bridge hanging off the encoder.
>>> With this patch, we allow multiple bridges to hang onto th
Sean,
On Tue, May 6, 2014 at 9:24 PM, Sean Paul wrote:
> On Mon, May 5, 2014 at 12:52 PM, Ajay Kumar
> wrote:
>> modify the driver to call the bridge->funcs of the next bridge
>> in the chain.
>> We assume that the bridge sitting next to ptn3460 is a bridge-panel.
>>
>> Signed-off-by: Ajay Kum
On Wed, May 7, 2014 at 1:33 AM, Sean Paul wrote:
> On Tue, May 6, 2014 at 12:45 PM, Ajay kumar wrote:
>> Sean,
>>
>>
>> On Tue, May 6, 2014 at 9:25 PM, Sean Paul wrote:
>>> On Mon, May 5, 2014 at 12:52 PM, Ajay Kumar
>>> wrote:
As of now, we can have only one bridge hanging off the encode
Hi Andrzej,
Thank you for comments.
On 05/05/2014 08:27 PM, Andrzej Hajda wrote:
> On 04/27/2014 03:50 AM, YoungJun Cho wrote:
>> The offset of register DSIM_PLLTMR_REG in Exynos5420 is different
>> from the one in Exynos4 SoC.
>>
>> In case of Exynos5420 SoC, there is no frequency band bit in
>
Hi Andrzej
Thank you for comments.
On 05/05/2014 07:35 PM, Andrzej Hajda wrote:
> On 04/27/2014 03:50 AM, YoungJun Cho wrote:
>> This patch adds DT bindings for s6e3fa0 panel.
>> The bindings describes panel resources, display timings and cpu mode timings.
>>
>> Changelog v2:
>> - Adds unit addre
he assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140507/65f2f095/attachment.html>
Hi Daniel,
On 2014? 05? 05? 00:26, Daniel Kurtz wrote:
> Mixer hardware supports offsetting dma from start of source buffer using
> the MXR_GRP_SXY register.
>
> Signed-off-by: Daniel Kurtz
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletion
On Wed, May 7, 2014 at 9:20 AM, Dave Airlie wrote:
> So now I've been playing with MST I think get the feeling I might need
> some explicit locking on the AUX channel, I think at the moment the
> mode_config mutex implicitly defends the aux channel as the only real
> paths into it are
>
> a) from
On Tue, 06 May 2014, Daniel Vetter wrote:
> On Tue, May 06, 2014 at 10:04:17PM +0200, Knut Petersen wrote:
>> On 06.05.2014 20:59, Daniel Vetter wrote:
>> >On Tue, May 06, 2014 at 04:30:45PM +0300, Jani Nikula wrote:
>> >>On Tue, 06 May 2014, Knut Petersen wrote:
>> >>>On 28.04.2014 15:26, Daniel
On 7 May 2014 15:26, Ben Skeggs wrote:
> On Wed, May 7, 2014 at 9:20 AM, Dave Airlie wrote:
>> So now I've been playing with MST I think get the feeling I might need
>> some explicit locking on the AUX channel, I think at the moment the
>> mode_config mutex implicitly defends the aux channel as t
On 05/03/2014 02:00 AM, Chris Wilson wrote:
> On Sat, May 03, 2014 at 07:08:02AM +1000, Dave Airlie wrote:
>> On 2 May 2014 18:52, Chris Wilson wrote:
>>> On Fri, May 02, 2014 at 02:39:37PM +1000, Dave Airlie wrote:
>> the GUID is only on DP 1.2 devices, so you don't get one for ever
>> port, also
This patch series includes the followings:
- Generic command mode interface
- FIMD I80 interface
- DSI command mode interface for Exynos5420 SoC
- S6E3FA0 command mode type panel driver
This patch series is based on exynos-drm-next branch.
Previous patch set,
RFC v1: http://www.spinics.net/lists/
There could be the case that the page flip operation isn't finished correctly
with some abnormal condition such as panel reset. So this patch replaces
wait_event() with wait_event_timeout() to avoid waiting for page flip completion
infinitely.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked
This configuration could be used in MIPI DSI command mode also.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
This patch adds relevant to exynos5 compatible for exynos5 SoCs.
Changelog v2:
- Changes title and description (commented by Sachin Kamat)
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
.../devicetree/bindings/arm/samsung/sysreg.txt |1 +
1 file changed, 1
To support command mode interface, the DSI host calls this handler
to notify the panel tearing effect synchronization signal to the
CRTC device manager to trigger to transfer video image.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_d
In case of using MIPI command mode interface panel,
the relevant registers should be set.
So this patch adds relevant DT bindings.
Changelog v2:
- Changes "samsung,sysreg-phandle" to "samsung,sysreg"
Changelog v3:
- Moves CPU timings relevant properties to panel DT
(commented by Laurent Pinchart
This patch is based on videomode and display_timing relevant codes.
To support command mode panel, it does not need to guide its timing
information to the display controller like video mode panel,
but it requires signal timings to transfer video data.
So this patch adds cmdmode struct, cmdmode_disp
This patch adds mipi-phy node for MIPI-DSI device.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos5420.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
in
This patch adds DT bindings for command mode display timing.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
.../bindings/video/cmdmode-display-timing.txt | 64
1 file changed, 64 insertions(+)
create mode 100644
Documentation/devicetree
This patch adds relevant to exynos5420 compatible for exynos5420 SoC support.
Changelog v2:
- Changes title, description and fixes typo (commented by Sachin Kamat)
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
.../devicetree/bindings/video/exynos_dsim.txt |
This patch adds common part of dsi node.
Changelog v2:
- Uses clock macros instead of numbers (commented by Sachin Kamat)
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos5420.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff
To support MIPI DSI command mode interface, FIMD should do followings:
- Sets LCD block configuration for I80 interface.
- Uses "lcd_sys" as an IRQ resource and sets relevant IRQ configuration.
- Implements trigger feature which transfers image date if there is
page flip request, and implements T
This patch adds sysreg device node, and sysreg property to fimd device node
which is required to use I80 interface.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos5.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/bo
This patch adds sysreg property to fimd device node which is required
to use I80 interface.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4.dtsi |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm
This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.
Changelog v2:
- Declares delay, size properties in probe routine instead of DT
Changelog v3:
- Moves CPU mode timings relevant properties from FIMD DT
(commented by Laurent Pinchart, Andrzej Hajda)
Changelog v4:
- Enhan
This patch adds helper functions to convert cmdmode
to drm_display_mode
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/drm_modes.c | 59 +++
include/drm/drm_modes.h | 12 +
2 files changed, 71 i
This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings and cpu mode timings.
Changelog v2:
- Adds unit address (commented by Sachin Kamat)
Changelog v3:
- Removes optional delay, size properties (commented by Laurent Pinchart)
- Adds OLED detection,
To support MIPI DSI command mode interface, the panel should generates
Tearing Effect synchronization signal between MCU and FB to display
video images.
And the display controller should trigger to transfer video image at
this signal.
So the panel receives the TE IRQ, then calls this handler chains
The offset of register DSIM_PLLTMR_REG in Exynos5420 is different
from the one in Exynos4 SoC.
In case of Exynos5420 SoC, there is no frequency band bit in DSIM_PLLCTRL_REG,
and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead.
So this patch adds driver data to distinguish it.
Changelog v
f the locking happens within the driver's
->transfer implementation it would still be possible for other DPCD
accesses to happen in between retries. I'm not sure if that's actually a
problem, but I can imagine that it could mess up the whole retry logic.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140507/aa53080d/attachment.sig>
On Wed, May 07, 2014 at 12:16:37AM -0700, Aaron Plattner wrote:
> On 05/03/2014 02:00 AM, Chris Wilson wrote:
> >On Sat, May 03, 2014 at 07:08:02AM +1000, Dave Airlie wrote:
> >>On 2 May 2014 18:52, Chris Wilson wrote:
> >>>On Fri, May 02, 2014 at 02:39:37PM +1000, Dave Airlie wrote:
> >>the GUID
Only gma500 is still using this, once that's converted we can kill all
this code. If that conversion doesn't happen soonish I think we should
just move this helper code into the gma500 driver itself to avoid
abuse from new drivers.
Cc: Patrik Jakobsson
Cc: Alan Cox
Cc: Thierry Reding
Signed-off
On Wed, May 07, 2014 at 09:20:41AM +1000, Dave Airlie wrote:
> So now I've been playing with MST I think get the feeling I might need
> some explicit locking on the AUX channel, I think at the moment the
> mode_config mutex implicitly defends the aux channel as the only real
> paths into it are
>
On 7 May 2014 17:16, Aaron Plattner wrote:
> On 05/03/2014 02:00 AM, Chris Wilson wrote:
>>
>> On Sat, May 03, 2014 at 07:08:02AM +1000, Dave Airlie wrote:
>>>
>>> On 2 May 2014 18:52, Chris Wilson wrote:
On Fri, May 02, 2014 at 02:39:37PM +1000, Dave Airlie wrote:
>>>
>>> the GUID is o
ee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140507/99bc613c/attachment-0001.html>
On 5 May 2014 15:14, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Wednesday 09 April 2014 03:31 PM, Sylwester Nawrocki wrote:
>> Hi,
>>
>> On 09/04/14 11:12, Rahul Sharma wrote:
>>> Idea looks good. How about keeping compatible which is independent
>>> of SoC, something like "samsung,exynos-simple-p
Use DPCD defines of drm_dp_helper.h; thus, duplicated DPCD defines
of exynos_dp_core.h can be removed. Also, DP_TEST_EDID_CHECKSUM
define is added to drm_dp_helper.h. There is no functional change.
Signed-off-by: Jingoo Han
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 98 +++--
drm_crtc.h is already included by exynos_dp_core.h.
Signed-off-by: Jingoo Han
---
drivers/gpu/drm/exynos/exynos_dp_core.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 92cfbb3..3c15e89 100644
--- a/d
From: Rahul Sharma
In case of exynos, setting dma-burst to 16Word causes permanent
tearing for very small buffers, e.g. cursor buffer. Burst Mode
switching, which is based on overlay size is not recommended as
overlay size varies a lot towards the end of the screen. This
causes unstable DMA which
From: Rahul Sharma
Allow to allocate non-contigous buffers when iommu is enabled.
Currently, it tries to allocates contigous buffer which consistently
fail for large buffers and then fall back to non contigous. Apart
from being slow, this implementation is also very noisy and fills
the screen wit
https://bugzilla.kernel.org/show_bug.cgi?id=75651
Bug ID: 75651
Summary: resume from suspend failing 3.15(rc1,rc2,rc3,rc4)
bisected
Product: Drivers
Version: 2.5
Kernel Version: 3.15
Hardware: All
OS: Li
On 05/07/2014 12:38 PM, Rahul Sharma wrote:
> On 5 May 2014 15:14, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Wednesday 09 April 2014 03:31 PM, Sylwester Nawrocki wrote:
>>> Hi,
>>>
>>> On 09/04/14 11:12, Rahul Sharma wrote:
Idea looks good. How about keeping compatible which is independen
On Wed, May 7, 2014 at 1:14 PM, Seung-Woo Kim wrote:
> Hi Daniel,
>
> On 2014? 05? 05? 00:26, Daniel Kurtz wrote:
>> Mixer hardware supports offsetting dma from start of source buffer using
>> the MXR_GRP_SXY register.
>>
>> Signed-off-by: Daniel Kurtz
>> ---
>> drivers/gpu/drm/exynos/exynos_mix
On 7 May 2014 19:06, Tomasz Stanislawski wrote:
> On 05/07/2014 12:38 PM, Rahul Sharma wrote:
>> On 5 May 2014 15:14, Kishon Vijay Abraham I wrote:
>>> Hi,
>>>
>>> On Wednesday 09 April 2014 03:31 PM, Sylwester Nawrocki wrote:
Hi,
On 09/04/14 11:12, Rahul Sharma wrote:
> Idea l
[CCing more DT-folks :)]
On 07.05.2014 16:19, Rahul Sharma wrote:
> On 7 May 2014 19:06, Tomasz Stanislawski wrote:
>> On 05/07/2014 12:38 PM, Rahul Sharma wrote:
>>> On 5 May 2014 15:14, Kishon Vijay Abraham I wrote:
Hi,
On Wednesday 09 April 2014 03:31 PM, Sylwester Nawrocki wro
On Wed, May 7, 2014 at 4:44 AM, Jingoo Han wrote:
> Use DPCD defines of drm_dp_helper.h; thus, duplicated DPCD defines
> of exynos_dp_core.h can be removed. Also, DP_TEST_EDID_CHECKSUM
> define is added to drm_dp_helper.h. There is no functional change.
>
> Signed-off-by: Jingoo Han
This is a ni
On Wednesday 07 May 2014 10:05:46 YoungJun Cho wrote:
> Hi Andrzej
>
> Thank you for comments.
>
> On 05/05/2014 07:35 PM, Andrzej Hajda wrote:
> > On 04/27/2014 03:50 AM, YoungJun Cho wrote:
> >> This patch adds DT bindings for s6e3fa0 panel.
> >> The bindings describes panel resources, display
From: Leo Liu
v2 (chk): fix image size storage
v3 (chk): fix UV size calculation
Signed-off-by: Leo Liu
---
drivers/gpu/drm/radeon/radeon.h | 3 +-
drivers/gpu/drm/radeon/radeon_vce.c | 130 +++-
2 files changed, 102 insertions(+), 31 deletions(-)
diff --
his included by distros as stable
update.
--
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/20140507/78fa430f/attachment.html>
On 05/07/2014 02:00 AM, Dave Airlie wrote:
> On 7 May 2014 17:16, Aaron Plattner wrote:
>> On 05/03/2014 02:00 AM, Chris Wilson wrote:
>>>
>>> On Sat, May 03, 2014 at 07:08:02AM +1000, Dave Airlie wrote:
On 2 May 2014 18:52, Chris Wilson wrote:
>
> On Fri, May 02, 2014 at 02:39:
On 05/07/2014 01:07 AM, Daniel Vetter wrote:
> On Wed, May 07, 2014 at 12:16:37AM -0700, Aaron Plattner wrote:
>> On 05/03/2014 02:00 AM, Chris Wilson wrote:
>>> On Sat, May 03, 2014 at 07:08:02AM +1000, Dave Airlie wrote:
On 2 May 2014 18:52, Chris Wilson wrote:
> On Fri, May 02, 2014 at
On Wed, May 7, 2014 at 12:08 PM, Christian K?nig
wrote:
> From: Leo Liu
>
> v2 (chk): fix image size storage
> v3 (chk): fix UV size calculation
>
> Signed-off-by: Leo Liu
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon.h | 3 +-
> drivers/gpu/drm/radeon/radeon_vce.c |
On Wed, May 7, 2014 at 10:26 AM, Daniel Vetter
wrote:
> Only gma500 is still using this, once that's converted we can kill all
> this code. If that conversion doesn't happen soonish I think we should
> just move this helper code into the gma500 driver itself to avoid
> abuse from new drivers.
I'
From: J?r?me Glisse
When accel is not working on device with virtual address space radeon
segfault because the ib buffer is NULL and trying to map it inside the
virtual address space trigger segfault. This patch only map the ib
buffer if accel is working.
Cc:
Signed-off-by: J?r?me Glisse
---
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/20140507/4d6c73ab/attachment.html>
On Wed, May 7, 2014 at 4:35 PM, wrote:
> From: J?r?me Glisse
>
> When accel is not working on device with virtual address space radeon
> segfault because the ib buffer is NULL and trying to map it inside the
> virtual address space trigger segfault. This patch only map the ib
> buffer if accel i
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140507/40f366ea/attachment.html>
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/20140507/d886103d/attachment.html>
> Imo trying to fix the current mess and making ->set_config work in
> atomic contexts is pointless. drm_can_sleep is trying to make that
> possible in some ways, and it's horrible since using it means
> busy-loops in atomic contexts outside of panic handlers won't get
> reported any more. Also the
64 matches
Mail list logo
