Hi
On Sat, Apr 12, 2014 at 12:07 AM, Andy Lutomirski
wrote:
> I bet this is missing from lots of places. For example, I can't find
> any write_access stuff in the rdma code.
>
> I suspect that the VM_DENYWRITE code is just generally racy.
So what does S_IMMUTABLE do to prevent such races? I so
ves/dri-devel/attachments/20140414/e9df2ec0/attachment.html>
This patch series cleans up exynos drm framework and kms sub drivers
using the component framework[1]
[1] http://lists.freedesktop.org/archives/dri-devel/2014-January/051249.html
Previous patches,
RFC: http://comments.gmane.org/gmane.comp.video.dri.devel/101200
v1: http://lists.freedesktop.org/ar
When connector is created, if connector->polled is
DRM_CONNECTOR_POLL_CONNECT then drm_kms_helper_hotplug_event
function isn't called at drm_helper_hpd_irq_event because the
function will be called only in case of DRM_CONNECTOR_POLL_HPD.
So this patch sets always DRM_CONNECTOR_POLL_HPD flag to
con
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4210-trats.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 02c6768..a41c109 100644
--- a/arch/arm/boot/dts/exyno
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4412-trats2.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 53c717b..115b9ed 100644
--- a/arch/arm/boot/dts/ex
From: Andrzej Hajda
The patch separates dpi related routines from fimd.
Changelog v2:
- Rename ctx->dpi to ctx->display
Signed-off-by: Andrzej Hajda
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 40 +--
drivers/gpu/drm/exynos/exynos_drm_drv.h | 15 ++--
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 40 +++
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index cdd74e2..1d1c604 100644
--- a/driver
This patch adds bindings for Exynos drm display subsystem.
The bindings describes ports containing a list of phandles
pointing to display controller, image enhancer, and display
interfaces nodes.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
.../bindings/drm/exynos/samsung-exynos-drm
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4210-universal_c210.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 0a80a72..5351ac4 100644
--
subdrv_probe callback of virtual display driver will be
called by exynos_drm_device_subdrv_probe() to create crtc
and encoder/connector for virtual display driver.
So it fixes comments to exynos_drm_device_subdrv probe call.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/d
This patch adds super device support to bind sub drivers
using device tree.
For this, you should add a super device node to each machine dt files
like belows,
In case of using MIPI-DSI,
display-subsystem {
compatible = "samsung,exynos-display-subsystem";
po
op 11-04-14 21:30, Thomas Hellstrom schreef:
> Hi!
>
> On 04/11/2014 08:09 PM, Maarten Lankhorst wrote:
>> op 11-04-14 12:11, Thomas Hellstrom schreef:
>>> On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:
op 11-04-14 10:38, Thomas Hellstrom schreef:
> Hi, Maarten.
>
> Here I believ
dri-devel/attachments/20140414/6aa89895/attachment.html>
op 11-04-14 21:35, Thomas Hellstrom schreef:
> On 04/11/2014 08:09 PM, Maarten Lankhorst wrote:
>> op 11-04-14 12:11, Thomas Hellstrom schreef:
>>> On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:
op 11-04-14 10:38, Thomas Hellstrom schreef:
> Hi, Maarten.
>
> Here I believe we enc
On 04/14/2014 09:42 AM, Maarten Lankhorst wrote:
> op 11-04-14 21:35, Thomas Hellstrom schreef:
>> On 04/11/2014 08:09 PM, Maarten Lankhorst wrote:
>>> op 11-04-14 12:11, Thomas Hellstrom schreef:
On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:
> op 11-04-14 10:38, Thomas Hellstrom schree
On Fri, Apr 11, 2014 at 5:34 PM, Alexandre Courbot
wrote:
> On 04/11/2014 04:31 PM, Ben Skeggs wrote:
>>
>> On Fri, Apr 11, 2014 at 12:46 PM, Alexandre Courbot
>> wrote:
>>>
>>> On Wed, Mar 26, 2014 at 1:19 PM, Ben Skeggs wrote:
On Tue, Mar 25, 2014 at 7:54 AM, Thierry Reding
wr
On 04/12/2014 04:18 PM, Inki Dae wrote:
> Hi Andrzej,
>
> Thanks for your contributions.
>
> 2014-04-11 23:11 GMT+09:00 Andrzej Hajda :
>> Hi Inki,
>>
>> This patchset refactors drm device initialization. Details are described
>> in respective patches. It is an alternative to DT supernode concept.
y objective
testing. And number of hangs just correlates with frequency of video playing.
--
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/at
On Mon, Apr 14, 2014 at 10:42:32AM +0200, Lucas Stach wrote:
> Am Sonntag, den 13.04.2014, 15:58 +0100 schrieb Russell King - ARM
> Linux:
> > On Fri, Apr 11, 2014 at 04:13:33PM +0200, Lucas Stach wrote:
> > > Make sure that we probe for a display on detect regardless
> > > of previous hotplug even
Hi,
Resending three patches for qemu emulated hardware. One little cleanup,
and two adding power management callbacks to bochs and cirrus drivers,
so you have working video after resuming your virtual machine from S3.
I've already sent them months ago, nobody raised any concerns and I've
assum
cirrus kms driver lacks power management support, thus
the vga display doesn't work any more after S3 resume.
Fix this by adding suspend and resume functions.
Also make the mode_set function unblank the screen.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/cirrus/cirrus_drv.c | 42 +
bochs kms driver lacks power management support, thus
the vga display doesn't work any more after S3 resume.
Fix this by adding suspend and resume functions.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs.h | 1 +
drivers/gpu/drm/bochs/bochs_drv.c | 44 +++
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs.h | 2 --
drivers/gpu/drm/bochs/bochs_fbdev.c | 1 -
2 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index 4608205..7eb52dd 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++
Am Montag, den 14.04.2014, 10:10 +0100 schrieb Russell King - ARM Linux:
> On Mon, Apr 14, 2014 at 10:42:32AM +0200, Lucas Stach wrote:
> > Am Sonntag, den 13.04.2014, 15:58 +0100 schrieb Russell King - ARM
> > Linux:
> > > On Fri, Apr 11, 2014 at 04:13:33PM +0200, Lucas Stach wrote:
> > > > Make s
This patch eliminates redundant checks while retrieving HPD gpio from DT during
HDMI's probe().
Signed-off-by: Tomasz Stanislawski
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/
On Mon, Apr 14, 2014 at 11:38:43AM +0200, Lucas Stach wrote:
> Am Montag, den 14.04.2014, 10:10 +0100 schrieb Russell King - ARM Linux:
> > On Mon, Apr 14, 2014 at 10:42:32AM +0200, Lucas Stach wrote:
> > > Am Sonntag, den 13.04.2014, 15:58 +0100 schrieb Russell King - ARM
> > > Linux:
> > > > On F
https://bugzilla.kernel.org/show_bug.cgi?id=50091
--- Comment #34 from Dzianis Kahanovich ---
OOPS! Crushed now. No fix ;(
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Monday 14 April 2014 02:55 PM, Tomi Valkeinen wrote:
> On 11/04/14 10:23, Archit Taneja wrote:
>> The drm ioctl DRM_IOCTL_MODE_ADDFB2 doesn't let us allocate buffers which are
>> greater than what is specified in the driver through dev->mode_config.
>>
>> Create helpers for DISPC which return th
Am Montag, den 14.04.2014, 11:09 +0100 schrieb Russell King - ARM Linux:
> On Mon, Apr 14, 2014 at 11:38:43AM +0200, Lucas Stach wrote:
> > Am Montag, den 14.04.2014, 10:10 +0100 schrieb Russell King - ARM Linux:
> > > On Mon, Apr 14, 2014 at 10:42:32AM +0200, Lucas Stach wrote:
> > > > Am Sonntag,
On Fri, Apr 11, 2014 at 3:23 AM, Archit Taneja wrote:
> The drm ioctl DRM_IOCTL_MODE_ADDFB2 doesn't let us allocate buffers which are
> greater than what is specified in the driver through dev->mode_config.
>
> Create helpers for DISPC which return the max manager width and height
> supported
> b
> -Original Message-
> From: Andrzej Hajda [mailto:a.hajda at samsung.com]
> Sent: Monday, April 14, 2014 5:55 PM
> To: Inki Dae
> Cc: dri-devel at lists.freedesktop.org; moderated list:ARM/S5P EXYNOS AR...;
> Kyungmin Park; Marek Szyprowski
> Subject: Re: [PATCH RFC 0/2] drm/exynos: refa
On Monday 14 April 2014 04:00 PM, Tomi Valkeinen wrote:
> On 14/04/14 13:18, Archit Taneja wrote:
>> On Monday 14 April 2014 02:55 PM, Tomi Valkeinen wrote:
>>> On 11/04/14 10:23, Archit Taneja wrote:
The drm ioctl DRM_IOCTL_MODE_ADDFB2 doesn't let us allocate buffers
which are
great
Hi Inki,
On 14.04.2014 13:04, Inki Dae wrote:
>
>
>> -Original Message-
>> From: Andrzej Hajda [mailto:a.hajda at samsung.com]
>> Sent: Monday, April 14, 2014 5:55 PM
>> To: Inki Dae
>> Cc: dri-devel at lists.freedesktop.org; moderated list:ARM/S5P EXYNOS AR...;
>> Kyungmin Park; Marek Szy
Hi Tomasz,
On 04/14/2014 07:07 PM, Tomasz Stanislawski wrote:
> This patch eliminates redundant checks while retrieving HPD gpio from DT
> during
> HDMI's probe().
>
> Signed-off-by: Tomasz Stanislawski
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 13 -
> 1 file changed, 4 ins
On 04/14/2014 02:41 PM, One Thousand Gnomes wrote:
>> throw out all GPU memory on master drop and block ioctls requiring
>> authentication until master becomes active again.
> If you have a per driver method then the driver can implement whatever is
> optimal (possibly including throwing it all out
On Mon, Apr 14, 2014 at 8:56 AM, Thomas Hellstrom
wrote:
> On 04/14/2014 02:41 PM, One Thousand Gnomes wrote:
>>> throw out all GPU memory on master drop and block ioctls requiring
>>> authentication until master becomes active again.
>> If you have a per driver method then the driver can impleme
Hi Tomasz,
Always thanks for your opinions.
> -Original Message-
> From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc-
> owner at vger.kernel.org] On Behalf Of Tomasz Figa
> Sent: Monday, April 14, 2014 8:32 PM
> To: Inki Dae; 'Andrzej Hajda'
> Cc: 'Kyungmin Park';
On 14.04.2014 15:55, Inki Dae wrote:
> Hi Tomasz,
>
> Always thanks for your opinions.
>
>> -Original Message-
>> From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc-
>> owner at vger.kernel.org] On Behalf Of Tomasz Figa
>> Sent: Monday, April 14, 2014 8:32 PM
>> To:
https://bugzilla.kernel.org/show_bug.cgi?id=73901
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #2 fr
https://bugzilla.kernel.org/show_bug.cgi?id=73931
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
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/20140414/9779f7f7/attachment.html>
Hi everyone,
This patchset adds 4 fixes/updates to EXYNOS DRM driver for
HDMI subsystem.
All comments are welcome.
Regards,
Tomasz Stanislawski
Tomasz Stanislawski (4):
drm: exynos: hdmi: simplify extracting hpd-gpio from DT
drm: exynos: mixer: fix using usleep() in atomic context
drm: exy
This patch eliminates redundant checks while retrieving HPD gpio from DT during
HDMI's probe().
Signed-off-by: Tomasz Stanislawski
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/
This patch fixes calling usleep_range() after taking reg_slock
using spin_lock_irqsave(). The mdelay() is used instead.
Waiting in atomic context is not the best idea in general.
Hopefully, waiting occurs only when Video Processor fails
to reset correctly.
Signed-off-by: Tomasz Stanislawski
---
This patch add proper compatibles for Mixer and HDMI chip
available on exynos4210 SoCs.
Signed-off-by: Tomasz Stanislawski
---
drivers/gpu/drm/exynos/exynos_hdmi.c |3 +++
drivers/gpu/drm/exynos/exynos_mixer.c |3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/exynos
Adds support for limitation of maximal pixel clock of HDMI
signal. This feature is needed on boards that contains
lines or bridges with frequency limitations.
Signed-off-by: Tomasz Stanislawski
---
.../devicetree/bindings/video/exynos_hdmi.txt |4
drivers/gpu/drm/exynos/exynos_hdmi
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dp.c
b/drivers/staging/imx-drm/ipu-v3/ipu-dp.c
index 6980fa1..d90f82a 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dp.c
+++ b/driv
Wait for the DC Frame Complete or DP Sync Flow End interrupts
before disabling DC channels.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 71 +++--
1 file changed, 50 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/imx-drm/ipu
Disabling the DMFC module while there is still data in the FIFOs could
cause the "new frame before end of frame" error state when the DMFC is
enabled again.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c | 25 +++--
1 file changed, 23 insertions(+)
Now that ipu_dc_disable_channel correctly waits for the channel to finish,
we can reorder the enable/disable order to first stop the DC and DI and
only then disable the IDMAC. Enabling is done the other way around: IDMAC
first, then DC, then DI.
This avoids an issue where sometimes the channel wou
The former has to be done before disabling the DMFC, the latter has to be
done afterwards. Otherwise the DMFC FIFOs never get cleared properly.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 2 +
drivers/staging/imx-drm/ipu-v3/ipu-dp.c | 68 ++
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 22 ++
drivers/staging/imx-drm/ipu-v3/ipu-prv.h| 3 +++
2 files changed, 25 insertions(+)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
b/drivers/staging/imx-drm/ipu-v3/ipu-common.
This allows to request the DC related interrupts.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 1 +
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 19 +--
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/imx-drm/ipu
Repeatedly enabling and disabling the display currently can lead to a state
in which the IPU doesn't produce a valid signal anymore because we disable
IPU submodules before they can finish their interaction.
This series reorders the enable/disable sequence so that we first wait for the
DC/DP to fi
https://bugzilla.kernel.org/show_bug.cgi?id=73901
--- Comment #3 from Pali Roh?r ---
Created attachment 132211
--> https://bugzilla.kernel.org/attachment.cgi?id=132211&action=edit
dmesg output
I'm using version 3.14 (as specified in bugzilla). Dmesg output from kernel
without any radeon params
https://bugzilla.kernel.org/show_bug.cgi?id=73901
Pali Roh?r changed:
What|Removed |Added
Attachment #132211|application/octet-stream|text/plain
mime type|
On 04/14/2014 05:00 PM, Tomasz Stanislawski wrote:
> This patch eliminates redundant checks while retrieving HPD gpio from DT
> during
> HDMI's probe().
>
> Signed-off-by: Tomasz Stanislawski
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 13 -
> 1 file changed, 4 insertions(+), 9
https://bugzilla.kernel.org/show_bug.cgi?id=73931
--- Comment #2 from Pali Roh?r ---
Created attachment 132221
--> https://bugzilla.kernel.org/attachment.cgi?id=132221&action=edit
syslog output after modprobe radeon
Yes, your patch fixing original problem. Maybe this is candidate for stable
re
https://bugzilla.kernel.org/show_bug.cgi?id=73931
--- Comment #3 from Alex Deucher ---
Created attachment 132231
--> https://bugzilla.kernel.org/attachment.cgi?id=132231&action=edit
possible fix
Does this help in the second case?
--
You are receiving this mail because:
You are watching the a
https://bugzilla.kernel.org/show_bug.cgi?id=73901
--- Comment #4 from Alex Deucher ---
Your system does not appear to have the ATPX acpi methods that are required for
runtime pm to work properly (required to power off the dGPU). You should see
something like:
ATPX version X, functions 0x
https://bugzilla.kernel.org/show_bug.cgi?id=73901
--- Comment #5 from Pali Roh?r ---
So I cannot turn off dGPU when it is not used?
Also I think that kernel should not crash when booting with (maybe incorrect?)
param runpm.
--
You are receiving this mail because:
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=73901
--- Comment #6 from Pali Roh?r ---
Btw, I looked into DSDT/SSDT acpi tables and there is ATPX method (in SSDT7,
scope \_SB.PCI0.GFX0).
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=73901
--- Comment #7 from Alex Deucher ---
(In reply to Pali Roh?r from comment #5)
> So I cannot turn off dGPU when it is not used?
>
Correct. The driver requires that method to power on/off the dGPU.
> Also I think that kernel should not crash whe
https://bugzilla.kernel.org/show_bug.cgi?id=73901
--- Comment #8 from Pali Roh?r ---
(In reply to Alex Deucher from comment #7)
> (In reply to Pali Roh?r from comment #6)
> > Btw, I looked into DSDT/SSDT acpi tables and there is ATPX method (in SSDT7,
> > scope \_SB.PCI0.GFX0).
>
> Did you enabl
https://bugzilla.kernel.org/show_bug.cgi?id=73931
--- Comment #4 from Pali Roh?r ---
No does not help, kernel still crashing. But now I cannot provide syslog
output, because userspace rsyslog daemon does not read log from kernel and
write data to disk.. Plus output on framebuffer screen is very q
https://bugzilla.kernel.org/show_bug.cgi?id=73931
--- Comment #5 from Pali Roh?r ---
Created attachment 132251
--> https://bugzilla.kernel.org/attachment.cgi?id=132251&action=edit
pstore log
Now I found pstore and its efi backend...
I modprobed efi-pstore before rmmoding radeon and dmesg logs
fyi, I have this patch applied locally (well, actually the previous
one with slightly amended subject line).. was just waiting a bit to
see if any other fixes turned up before sending a fixes pull. Thanks!
BR,
-R
On Mon, Apr 14, 2014 at 2:40 PM, Micah Richert
wrote:
> Signed-off-by: Micah Riche
u have any idea how to expose this knob securely?
Root could disable
PPGTT for all processes, but I don't see how we should securely handle
the authorisation
for an application to disable the PPGTT without some serious work...
As you can see, there is some work to be done before expos
On Mon, Apr 14, 2014 at 05:21:28PM +0200, Philipp Zabel wrote:
> Repeatedly enabling and disabling the display currently can lead to a state
> in which the IPU doesn't produce a valid signal anymore because we disable
> IPU submodules before they can finish their interaction.
Well done at finding
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/20140414/cbf7ce3f/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=73931
Alex Deucher changed:
What|Removed |Added
Attachment #132231|0 |1
is obsolete|
On 04/04/2014 04:31 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> BIT_WORD() truncates rather than rounds, so the loops in
> syncpt_thresh_isr() and _host1x_intr_disable_all_syncpt_intrs() use <=
> rather than < in an attempt to process the correct number of registers
> when rounding of th
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140414/936a27e1/attachment.sig>
On Mon, Apr 14, 2014 at 12:24:45PM +0200, Lucas Stach wrote:
> Am Montag, den 14.04.2014, 11:09 +0100 schrieb Russell King - ARM Linux:
> > Now *you* please go back and read what you said about kms/userspace being
> > able to poll the connector, thereby causing an EDID read attempt while
> > HPD ma
> I don't see this in linux-next yet.
I've queued this locally but haven't pushed anything out yet.
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/20140414/58ec45bf/attachment.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=73931
--- Comment #7 from Pali Roh?r ---
Created attachment 132281
--> https://bugzilla.kernel.org/attachment.cgi?id=132281&action=edit
pstore log
Ok, now kernel does not crash after loading radeon module again. I modprobed &
rmmoded it more times, t
On Mon, Apr 14, 2014 at 05:21:28PM +0200, Philipp Zabel wrote:
> Repeatedly enabling and disabling the display currently can lead to a state
> in which the IPU doesn't produce a valid signal anymore because we disable
> IPU submodules before they can finish their interaction.
I'm afraid to say tha
https://bugzilla.kernel.org/show_bug.cgi?id=73931
--- Comment #8 from Pali Roh?r ---
Created attachment 132291
--> https://bugzilla.kernel.org/attachment.cgi?id=132291&action=edit
dmesg plymouth log
Similar/same problem happends if I start plymouth splash screen (which using
intel fb) and then
On Mon, Apr 14, 2014 at 05:21:32PM +0200, Philipp Zabel wrote:
> Wait for the DC Frame Complete or DP Sync Flow End interrupts
> before disabling DC channels.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 71
> +++--
> 1 file chan
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 2 ++
drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 14 --
drivers/staging/imx-drm/ipuv3-crtc.c| 8 ++--
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/imx-drm
Disabling the DMFC module while there is still data in the FIFOs could
cause the "new frame before end of frame" error state when the DMFC is
enabled again.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c | 25 +++--
1 file changed, 23 insertions(+)
Now that ipu_dc_disable_channel correctly waits for the channel to finish,
we can reorder the enable/disable order to first stop the DC and DI and
only then disable the IDMAC. Enabling is done the other way around: IDMAC
first, then DC, then DI.
This avoids an issue where sometimes the channel wou
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dp.c
b/drivers/staging/imx-drm/ipu-v3/ipu-dp.c
index 6980fa1..d90f82a 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dp.c
+++ b/driv
The former has to be done before disabling the DMFC, the latter has to be
done afterwards. Otherwise the DMFC FIFOs never get cleared properly.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 2 +
drivers/staging/imx-drm/ipu-v3/ipu-dp.c | 68 ++
Repeatedly enabling and disabling the display currently can lead to a state
in which the IPU doesn't produce a valid signal anymore because we disable
IPU submodules before they can finish their interaction.
This series reorders the enable/disable sequence so that we first wait for the
DC/DP to fi
Wait for the DC Frame Complete or DP Sync Flow End interrupts
before disabling DC channels.
Signed-off-by: Philipp Zabel
---
Changes since v1:
- Moved disable_irq() out of dc_irq_handler()
---
drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 71 +++--
1 file changed, 50 ins
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 22 ++
drivers/staging/imx-drm/ipu-v3/ipu-prv.h| 3 +++
2 files changed, 25 insertions(+)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
b/drivers/staging/imx-drm/ipu-v3/ipu-common.
This allows to request the DC related interrupts.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 1 +
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 19 +--
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/imx-drm/ipu
> -Original Message-
> From: Christoph Jaeger [mailto:christophjaeger at linux.com]
> Sent: Monday, April 14, 2014 6:10 PM
> To: Deucher, Alexander; Koenig, Christian; airlied at linux.ie
> Cc: dri-devel at lists.freedesktop.org; linux-kernel at vger.kernel.org;
> Christoph
> Jaeger
> Subj
https://bugzilla.kernel.org/show_bug.cgi?id=73901
--- Comment #9 from Pali Roh?r ---
I looked into radeon_atpx_handler.c code and I found reason why radeon kernel
driver does not detect ATPX...
First here is lspci output:
00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core
P
On Mon, Apr 14, 2014 at 11:53:15PM +0200, Philipp Zabel wrote:
> Repeatedly enabling and disabling the display currently can lead to a state
> in which the IPU doesn't produce a valid signal anymore because we disable
> IPU submodules before they can finish their interaction.
Yes, this appears to
https://bugzilla.kernel.org/show_bug.cgi?id=73901
--- Comment #10 from Alex Deucher ---
Created attachment 132301
--> https://bugzilla.kernel.org/attachment.cgi?id=132301&action=edit
fix ATPX detection on non-VGA dGPUs
Thanks for sorting this out.
--
You are receiving this mail because:
You
https://bugzilla.kernel.org/show_bug.cgi?id=73901
--- Comment #11 from Alex Deucher ---
Created attachment 132311
--> https://bugzilla.kernel.org/attachment.cgi?id=132311&action=edit
avoid a possible crash when runpm is forced on non-ATPX systems
Fix runpm=1 handling on non-PX systems.
--
Yo
ment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140414/a3428db8/attachment.sig>
omap_fbdev_create() takes a reference to the fb's gem object with
omap_gem_get_paddr(). However, it never releases it with
omap_gem_put_paddr().
This patch adds the missing omap_gem_put_paddr() to omap_fbdev_free().
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_fbdev.c | 3 +++
Greetings,
I'm facing a dpm regression in 3.14 on my radeon TURKS (pci id 1002:6840).
Upon loading the radeon module with dpm enabled, the screen goes black and the
computer locks up.
The problem first appeared at 6c7bccea390853bdec5b76fe31fc50f3b36f75d5
drm/radeon/pm: move pm handling into th
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140414/e1ff7448/attachment.sig>
ears it.
> __drm_framebuffer_unregister() drops the "idr reference" taken in
> drm_framebuffer_init().
What's "idr"?
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: m.log
Type: text/x-log
Size: 23295 bytes
Desc: not avai
Print a warning when the user tries to rotate a non-TILER framebuffer.
Also set the rotation to 0, to avoid constant flood of the warnings in
case of page flipping.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_fb.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/dri
1 - 100 of 107 matches
Mail list logo
