Hi Daniel,
Thank you for the patch.
On Friday 11 April 2014 23:36:07 Daniel Vetter wrote:
> To get rid of the dev->bus->get_irq callback we need to pass in the
> desired irq explicitly into drm_irq_install. To avoid having to do the
> same for drm_irq_unistall just track it internally. That leave
Hi YoungJun,
Thank you for the patch.
On Wednesday 16 April 2014 13:38:57 YoungJun Cho wrote:
> This patch adds DT bindings for s6e3fa0 panel.
> The bindings describes panel resources, display timings, delays
> and physical size.
>
> Changelog v2:
> - Adds unit address (commented by Sachin Kamat
Hi YoungJun,
Thank you for the patch.
On Tuesday 15 April 2014 14:47:33 YoungJun Cho wrote:
> In case of using CPU interface panel, the relevant registers should be set.
> So this patch adds relevant dt bindings.
>
> Signed-off-by: YoungJun Cho
> Signed-off-by: Inki Dae
> Signed-off-by: Kyungm
uld probably be more accurate. There is no error here.
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/20140416/3701191c/attachment.sig>
attach ptn3460 connector to drm_panel and support drm_panel routines,
if a valid drm_panel object is passed to ptn3460_init.
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/bridge/Kconfig | 1 +
drivers/gpu/drm/bridge/ptn3460.c| 17 -
drivers/gpu/drm/exynos/exynos
From: Rahul Sharma
Add DRM_CONNECTOR_POLL_HPD to the set of connector flags while
registering drm_connector for ptn3460.
Signed-off-by: Rahul Sharma
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/bridge/ptn3460.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/ptn346
This patch attaches the dp connector to exynos_dp_panel, and adds
calls to drm_panel functions to control panel power sequence.
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/exynos/Kconfig | 1 +
drivers/gpu/drm/exynos/exynos_dp_core.c | 19 +++
drivers/gpu/drm/exynos/e
Register exynos_dp_panel before the list of exynos crtcs and
connectors are probed.
This is needed because exynos_dp_panel should be registered to
the drm_panel list via panel-exynos-dp probe, i.e much before
exynos_dp_bind calls of_drm_find_panel().
Signed-off-by: Ajay Kumar
---
drivers/gpu/dr
This patch adds a simple driver to handle all the LCD and LED
powerup/down routines needed to support eDP/eDP-LVDS panels
supported on exynos boards.
Most of the eDP/LVDS panels need this sequence for powerup:
-- LCD unit powerup/LCD_EN
-- video data on
-- LED unit powerup/
Most of the panels need an init sequence as mentioned below:
-- poweron LCD unit/LCD_EN
-- start video data
-- poweron LED unit/BL_EN
With existing callbacks for drm panel, we cannot accomodate such
panels, since only one callback, i.e "panel_enable" is supported.
This patc
From: Andrew Bresticker
Certain bridge chips use a GPIO to indicate the cable status instead
of the I_DP_HPD pin. This adds an optional device-tree property,
"samsung,hpd-gpio", to the exynos-dp controller which indicates that
the specified GPIO should be used for hotplug detection.
The GPIO is
This series is based on exynos-drm-next-todo branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
This set of drm patches are needed to support bridge chips and
eDP/LVDS panels with exynos_dp.
For testing, I have used exynos5250-snow board along with a
this is a typo vs the ums driver, fix to check correct value.
Found initially by Coverity.
Reported-by: Daniel Vetter
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ast/ast_post.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/d
On Wed, Apr 16, 2014 at 12:07:20PM +0200, Christian K?nig wrote:
> Hi Borislav,
>
> thanks for the logs, those were indeed quite helpful.
>
> Attached are two patches, the first one tries to solve the problem by
> increasing the accuracy of the parameters if we don't match exactly and the
> secon
On Wed, Apr 16, 2014 at 10:27 AM, Tomi Valkeinen
wrote:
> On 16/04/14 11:15, Daniel Vetter wrote:
>
>> I don't mind how this is getting fixed, I just don't like when regression
>> caused by my patches are left lingering too long ;-)
>>
>> Have you merged your patch for 3.14-rc already so that I c
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
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 |7 +++
drivers/gpu/drm/exynos/exynos_mixer.c |3 +++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/e
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 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 |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/driver
This patch continues shift of DRM EXYNOS to DT-only configuration.
The usage of the old structure for HDMI's platform data is
removed.
Signed-off-by: Tomasz Stanislawski
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 30 --
1 file changed, 8 insertions(+), 22 deletions(
Hi everyone,
This patchset adds 5 fixes/updates to EXYNOS DRM driver for
HDMI subsystem.
All comments are welcome.
Regards,
Tomasz Stanislawski
Changelog:
v3:
* remove usage of s5p_hdmi_platform_data
* return MODE_CLOCK_HIGH instead of MODE_CLOCK_BAD
v2:
* fix check with gpio_is_valid()
* use
Some drivers need to be able to have a perfect race-free fbcon setup.
Current drivers only enable hotplug processing after the call to
drm_fb_helper_initial_config which leaves a tiny but important race.
This race is especially noticable on embedded platforms where the
driver itself enables the vo
||
--
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/20140416/07163351/attachment.html>
use:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/09d3b8a9/attachment.html>
Added both patches to my 3.15 queue.
Thanks,
Christian.
Am 16.04.2014 15:42, schrieb Alex Deucher:
> Avoid a possible segfault.
>
> Noticed-by: Dan Carpenter
> Signed-off-by: Alex Deucher
> Cc: stable at vger.kernel.org
> ---
> drivers/gpu/drm/radeon/si.c | 4 +++-
> 1 file changed, 3 insert
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/20140416/41e27c90/attachment-0001.html>
On Wed, Mar 26, 2014 at 1:27 PM, Ben Skeggs wrote:
> On Tue, Mar 25, 2014 at 9:10 AM, Thierry Reding
> wrote:
>> On Mon, Mar 24, 2014 at 05:42:33PM +0900, Alexandre Courbot wrote:
>>> GK20A does not embed a dedicated COPY engine and thus cannot allocate
>>> the copy channel that nouveau_accel_ini
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
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos5420.dtsi | 15 +++
1 file changed, 15 insertion
This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings, delays
and physical size.
Changelog v2:
- Adds unit address (commented by Sachin Kamat)
Signed-off-by: YoungJun Cho
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
.../devicetree/b
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
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
.../devicetree/bindings/video/exynos_dsim.tx
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
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
.../devicetree/bindings/arm/samsung/sysreg.txt |1 +
1 file c
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/7becd308/attachment.html>
Hi,
On Monday 14 April 2014 06:06 PM, Tomi Valkeinen wrote:
> On 11/04/14 10:23, Archit Taneja wrote:
>> The vblank_cb callback and the page_flip ioctl can occur together in
>> different
>> CPU contexts. vblank_cb uses takes tje drm device's event_lock spinlock when
>> sending the vblank event an
t; guys.
>
> Thanks.
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-improve-PLL-params-if-we-don-t-match-exac.patch
Type: text/x-diff
Size: 2003 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachment
ubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/6dc12e7d/attachment-0001.sig>
Borislav Petkov wrote:
> On Tue, Apr 15, 2014 at 10:32:56PM +, Deucher, Alexander wrote:
>> Turning off modesetting basically disables the driver.
>
> Well, in my case, I was using the radeon.modeset=0 variant to rule out
> issues in x.org. And in my case x.org did start still, albeit with a
>
sts.freedesktop.org/archives/dri-devel/attachments/20140416/9c995462/attachment-0001.sig>
Am 16.04.2014 10:32, schrieb Kertesz Laszlo:
> Borislav Petkov wrote:
>> On Tue, Apr 15, 2014 at 10:32:56PM +, Deucher, Alexander wrote:
>>> Turning off modesetting basically disables the driver.
>>
>> Well, in my case, I was using the radeon.modeset=0 variant to rule out
>> issues in x.org. An
On Mon, Apr 14, 2014 at 09:26:14AM +0300, Tomi Valkeinen wrote:
> Hi,
>
> On 12/04/14 00:35, Daniel Vetter wrote:
> > Dave accidentally merged the wrong version of the patch in
> >
> > commit fd3c02531461924853db65f2664db361b53a70d3
> > Author: Daniel Vetter
> > Date: Wed Dec 11 11:34:26 2013
Avoid a possible segfault.
Noticed-by: Dan Carpenter
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/cik.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 7e43045..199eb
Avoid a possible segfault.
Noticed-by: Dan Carpenter
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/si.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 86f8c9c..ac708e0
user
experience ;)
--
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/20140416/8acc769b/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/20140416/679db5e8/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/4498ca62/attachment.html>
On 15 April 2014 19:59, Tomasz Stanislawski wrote:
> On 04/15/2014 03:42 PM, Rahul Sharma wrote:
>> On 15 April 2014 18:41, Tomasz Stanislawski
>> wrote:
>>> On 04/15/2014 11:42 AM, Rahul Sharma wrote:
Hi Tomasz,
On 15 April 2014 14:57, Tomasz Stanislawski
wrote:
> Adds
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/01132ffc/attachment.html>
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/70cef762/attachment-0001.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/407d666b/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/9101f59b/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/0ff457b4/attachment.html>
m doing; or
some other severe problem.
--
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/20140416/6d5a3e24/attachment.html>
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/60c483ba/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/d58980ab/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140416/86a062c4/attachment-0001.html>
Borislav Petkov wrote:
> On Tue, Apr 15, 2014 at 09:02:35PM +0300, Kertesz Laszlo wrote:
>> Honestly didnt try that but i assume yes, since the screens go black
>> when it should change resolution.
>
> Pls try it and let us know whether you see the machine booting further,
> albeit without modesett
On Tue, Apr 15, 2014 at 10:32:56PM +, Deucher, Alexander wrote:
> Turning off modesetting basically disables the driver.
Well, in my case, I was using the radeon.modeset=0 variant to rule out
issues in x.org. And in my case x.org did start still, albeit with a
jacked-up resolution.
But in Las
On Tue, Apr 15, 2014 at 3:30 PM, Tomi Valkeinen
wrote:
>
> It looks to me like drm_mode_setplane() doesn't really presume that the
> update_plane would set plane->fb or plane->crtc, as it does that itself
> (and only if update_plane has succeeded).
Yeah that's a bit of historical hilarity. ->set
57 matches
Mail list logo
