attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140328/ad74ba7b/attachment.html>
Hi Rob,
On Tuesday 24 December 2013 12:58:01 Laurent Pinchart wrote:
> The connectors list iterator returns the list head when the list is
> empty. Fix it by returning NULL in that case.
>
> Signed-off-by: Laurent Pinchart
Could you please take this patch in your tree ?
> ---
> drivers/gpu/dr
On Tue, Mar 18, 2014 at 05:22:57PM -0700, Matt Roper wrote:
> Add cursor plane as a parameter to drm_crtc_init() and update all
> existing DRM drivers to use a helper-provided primary plane. Passing
> NULL for this parameter indicates that there is no hardware cursor
> supported by the driver and
2014-03-27 23:46 GMT+09:00 Philipp Zabel :
> Hi Inki,
>
> Am Donnerstag, den 27.03.2014, 21:43 +0900 schrieb Inki Dae:
>> 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,
>>
>>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140328/ed9afd8f/attachment.html>
Sorry for typo.
2014-03-28 19:46 GMT+09:00 Inki Dae :
> Hi Philipp,
>
>
> 2014-03-27 23:46 GMT+09:00 Philipp Zabel :
>> Hi Inki,
>>
>> Am Donnerstag, den 27.03.2014, 21:43 +0900 schrieb Inki Dae:
>>> This patch adds super device support to bind sub drivers
>>> using device tree.
>>>
>>> For this,
Hi Philipp,
2014-03-27 23:46 GMT+09:00 Philipp Zabel :
> Hi Inki,
>
> Am Donnerstag, den 27.03.2014, 21:43 +0900 schrieb Inki Dae:
>> 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
On Fri, Mar 28, 2014 at 5:56 PM, Laurent Pinchart
wrote:
> Hi Rob,
>
> On Tuesday 24 December 2013 12:58:01 Laurent Pinchart wrote:
>> The connectors list iterator returns the list head when the list is
>> empty. Fix it by returning NULL in that case.
>>
>> Signed-off-by: Laurent Pinchart
>
> Cou
On Thu, Mar 27, 2014 at 05:44:35PM -0700, Matt Roper wrote:
> Add a new drm_crtc_init_with_planes() to allow drivers to provide
> specific primary and cursor planes at CRTC initialization. The existing
> drm_crtc_init() interface remains to avoid driver churn in existing
> drivers; it will initial
On Fri, Mar 28, 2014 at 04:48:42PM +0100, Laurent Pinchart wrote:
> On Friday 28 March 2014 09:32:06 Daniel Vetter wrote:
> > On Thu, Mar 27, 2014 at 05:44:31PM -0700, Matt Roper wrote:
> > > When we expose non-overlay planes to userspace, they will become
> > > accessible via standard userspace pl
On Fri, Mar 28, 2014 at 06:52:50PM +0100, Daniel Vetter wrote:
> On Fri, Mar 28, 2014 at 04:50:13PM +0100, Laurent Pinchart wrote:
> > Hi Matt,
> >
> > Thank you for the patch.
> >
> > On Thursday 27 March 2014 17:44:29 Matt Roper wrote:
> > > Ensure that existing driver loops over all planes do
On Fri, Mar 28, 2014 at 04:50:13PM +0100, Laurent Pinchart wrote:
> Hi Matt,
>
> Thank you for the patch.
>
> On Thursday 27 March 2014 17:44:29 Matt Roper wrote:
> > Ensure that existing driver loops over all planes do not change behavior
> > when we begin adding new types of planes (primary and
On Fri, Mar 28, 2014 at 12:49:26PM +0200, Jani Nikula wrote:
> On Fri, 28 Mar 2014, Christoph Jaeger wrote:
> > DRM_DEBUG_KMS includes printing the function name.
> >
> > Signed-off-by: Christoph Jaeger
>
> Reviewed-by: Jani Nikula
Queued for -next, thanks for the patch.
-Daniel
>
>
> > ---
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140328/0114611f/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140328/a6196b96/attachment-0001.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140328/e4d93568/attachment.html>
g/archives/dri-devel/attachments/20140328/4a92064c/attachment.html>
op.org/archives/dri-devel/attachments/20140328/99e01759/attachment.html>
;t more people have these problems?
If I know which values for fb,ref and post to use for 23.976fps I can hard code
these In a patch and test if it indeed works.
So which values are save to get a clock of 74.2MHz?
--
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/20140328/dba7afc7/attachment.html>
Hi Matt,
Thank you for the patch.
On Thursday 27 March 2014 17:44:29 Matt Roper wrote:
> Ensure that existing driver loops over all planes do not change behavior
> when we begin adding new types of planes (primary and cursor) to the DRM
> plane list in future patches.
>
> Cc: Laurent Pinchart
>
On Friday 28 March 2014 09:32:06 Daniel Vetter wrote:
> On Thu, Mar 27, 2014 at 05:44:31PM -0700, Matt Roper wrote:
> > When we expose non-overlay planes to userspace, they will become
> > accessible via standard userspace plane API's. We should be able to
> > handle the standard plane operations
ll_out_max and pll->pll_out_min.
I think the problem is that we don't try to choose a good value to match the
target frequency as close as possible in avivo_get_post_div, but just a value
that either matches the maximum or minimum VCO frequency.
--
You are receiving this mail because:
Y
the
> > numbers without toasting the hardware.
>
> So that would mean for example using fb=29.7 Ref=2 post=10?
>
> Or would that fry the hardware?
That should work. You aren't likely to fry the hw. You just don't want to set
a 400 Mhz clock as you monitor properly
; numbers without toasting the hardware.
So that would mean for example using fb=29.7 Ref=2 post=10?
Or would that fry the hardware?
Why must it exactly match? Because for fgrlx it seems roughly 30% higher than
needed
--
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/20140328/ab29126a/attachment.html>
eed to dig into that and try to improve the
numbers without toasting the hardware.
--
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/20140328/3f397ae9/attachment.html>
se are the exact values that are currently being used
--
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/20140328/423b2042/attachment-0001.html>
Dave,
vmwgfx render-node support and drm + ttm changes it depends upon.
The following changes since commit 60f2b4af1258c05e6b037af866be81abc24438f7:
drm/i915: fix build warning on 32-bit (v2) (2014-03-28 13:40:48 +1000)
are available in the git repository at:
git://people.freedesktop.org/~
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140328/9d429cd8/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/20140328/e0b7d2b9/attachment.html>
the target clock.
--
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/20140328/54a1fde8/attachment.html>
Hi
On Fri, Mar 28, 2014 at 12:52 PM, Thomas Hellstrom
wrote:
> Thanks. Want a Reviewed-By: or Acked-By: added?
Oh, sure:
Reviewed-by: David Herrmann
Thanks
David
On Tue, Mar 25, 2014 at 4:35 PM, Inki Dae wrote:
> 2014-03-25 0:53 GMT+09:00 Damien Lespiau :
>> As patch 8/11 explains, I noticed that we where evaluating the arguments to
>> drm_ut_debug_printk() even when drm.debug was 0, doing some work for no good
>> reason. By pulling the test on drm_debug b
> -Original Message-
> From: Damien Lespiau [mailto:damien.lespiau at intel.com]
> Sent: Friday, March 28, 2014 8:31 AM
> To: dri-devel at lists.freedesktop.org
> Cc: intel-gfx at lists.freedesktop.org; Sagar Kamble; Chris Wilson; Deucher,
> Alexander; Imre Deak
> Subject: [PATCH] drm: Spec
The patch changes fimd node status to OK.
Signed-off-by: Andrzej Hajda
---
arch/arm/boot/dts/exynos4412-trats2.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index f7070e9..53c717b 100644
--- a/arch/a
The patch changes fimd node status to OK.
Signed-off-by: Andrzej Hajda
---
arch/arm/boot/dts/exynos4210-trats.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 996c7e3..02c6768 100644
--- a/arch/arm/
The patch adds s6e8aa0 panel node for trats2.
It adds also trats2 specific properties for DSI
and regulator required by panel.
Signed-off-by: Andrzej Hajda
---
arch/arm/boot/dts/exynos4412-trats2.dts | 66 +
1 file changed, 66 insertions(+)
diff --git a/arch/arm/
The patch adds s6e8aa0 panel node for trats.
It adds also trats specific properties for DSI.
Signed-off-by: Andrzej Hajda
---
arch/arm/boot/dts/exynos4210-trats.dts | 57 ++
1 file changed, 57 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/a
This is a common part of DSI node for all Exynos4 boards.
Signed-off-by: Andrzej Hajda
---
arch/arm/boot/dts/exynos4.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 08452e1..3d14cdb 100644
--- a/arch/a
The patch adds MIPI-DSI based S6E8AA0 AMOLED LCD panel driver.
Driver uses mipi_dsi bus to communicate with panel and exposes drm_panel
interface.
Signed-off-by: Andrzej Hajda
---
v2
- added bus error handling,
- set maxmimum DSI packet size on init,
- removed unsupported brightness drm_panel cal
The patch adds bindings for s6e8aa0 panel.
Bindings describes panel resources, boot delays,
display timings, orientation and physical size.
Signed-off-by: Andrzej Hajda
---
v2
- removed samsung prefix from panel physical size props,
- renamed file to follow convention of panel bindings
v3
- rese
The patch adds driver for Exynos DSI master (DSIM). It is a platform driver
which is registered as exynos_drm_display sub-driver of exynos_drm framework
and implements DRM encoder/connector pair.
It is also MIPI-DSI host driver and provides DSI bus for panels.
It interacts with its panel(s) using d
The patch adds DT bindings for Exynos DSI Master. DSIM follows rules
for DSI bus host bindings [1].
Properties describes its resources: memory, interrupt, clocks,
phy, regulators, frequencies of clocks and video interfaces.
[1]: Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
Signed-o
This patch adds explicit check if there is a connector with
connected status before fbdev initialization. It prevents creation
of default fbdev 1024x768 which is unusable on panels with bigger resolutions.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 21 ++
MIPI DSI host node can contain child nodes which are not DSI devices.
Checking for existence of reg property can be used to distinguish such nodes.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/drm_mipi_dsi.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu
This patch adds flags field to mipi_dsi_msg structure and two flags:
- MIPI_DSI_MSG_REQ_ACK - request ACK from peripheral for given message,
- MIPI_DSI_MSG_USE_LPM - use Low Power Mode to transmit message.
The first flag is usually helpful during DSI diagnostic, the second
flag is required by some
Hi,
This patchset adds drivers and bindings to the following devices:
- Exynos DSI master,
- S6E8AA0 DSI panel,
It adds also display support in DTS files for the following boards:
- Exynos4210/Trats,
- Exynos4412/Trats2.
The patchset is based on exynos_drm_next branch.
It is the 3rd iteration o
On 03/28/2014 12:23 PM, David Herrmann wrote:
> Hi
>
> On Fri, Mar 28, 2014 at 10:34 AM, Thomas Hellstrom
> wrote:
>> The master management was previously protected by the
>> drm_device::struct_mutex.
>> In order to avoid locking order violations in a reworked dropped master
>> security check in
On Fri, 28 Mar 2014, Christoph Jaeger wrote:
> DRM_DEBUG_KMS includes printing the function name.
>
> Signed-off-by: Christoph Jaeger
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/dvo_ns2501.c | 22 --
> 1 file changed, 8 insertions(+), 14 deletions(-)
>
> diff --
On Fri, Mar 28, 2014 at 12:31:05PM +, Damien Lespiau wrote:
> Earlier this week, there was a bit of confusion about those new
> capabilities, to the point I think it's better to document the intention
> and API contract.
>
> The comment documents the current situation:
> - the radeon driver r
The 800x600 (SVGA) screen resolution was lacking in the set of
built-in selectable EDID screen resolutions that can be used to
repair misbehaving monitor firmware.
This patch adds the related data set and expands the documentation.
Note that the SVGA bit occupies a different byte to all the existi
Earlier this week, there was a bit of confusion about those new
capabilities, to the point I think it's better to document the intention
and API contract.
The comment documents the current situation:
- the radeon driver returns the only valid size for the hw
- i915 returns the maximun cursor siz
Hi
On Fri, Mar 28, 2014 at 10:34 AM, Thomas Hellstrom
wrote:
> The master management was previously protected by the
> drm_device::struct_mutex.
> In order to avoid locking order violations in a reworked dropped master
> security check in the vmwgfx driver, break it out into a separate
> master
l because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140328/e851ec36/attachment.html>
dri-devel/attachments/20140328/4c126adb/attachment.html>
On Fri, Mar 28, 2014 at 10:45 AM, Christopher Friedt
wrote:
> Previously, the vmwgfx_fb driver would allow users to call FBIOSET_VINFO, but
> it would not adjust
> the FINFO properly, resulting in distorted screen rendering. The patch
> corrects that behaviour.
>
> See https://bugs.gentoo.org/sh
This fixes an issue where the DRM planes do not support the same pixel
formats.
The current implementation selects a DRM plane without checking whether
the pixel format is supported or not. As a consequence modetest may try
to set up a plane not supporting the user request-format, which fails.
Mode
On 03/28/2014 01:19 AM, David Herrmann wrote:
> Hi
>
>
>
> I also don't quite understand why you move the struct_mutex locking
> into drm_master_destroy() instead of requiring callers to lock it as
> before? I mean, the whole function is protected by the lock..
Before, struct_mutex was required ou
The master management was previously protected by the drm_device::struct_mutex.
In order to avoid locking order violations in a reworked dropped master
security check in the vmwgfx driver, break it out into a separate master_mutex.
Locking order is master_mutex -> struct_mutex.
Also remove drm_mas
DRM_DEBUG_KMS includes printing the function name.
Signed-off-by: Christoph Jaeger
---
drivers/gpu/drm/i915/dvo_ns2501.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c
b/drivers/gpu/drm/i915/dvo_ns2501.c
index 954acb
Thanks for review.
This patch obsoletes patch "drm/i915: use __func__ instead of
__FUNCTION__".
Best,
Chris
On Fri, Mar 28, 2014 at 1:44 AM, Matt Roper
wrote:
> Add a new drm_crtc_init_with_planes() to allow drivers to provide
> specific primary and cursor planes at CRTC initialization. The existing
> drm_crtc_init() interface remains to avoid driver churn in existing
> drivers; it will initialize the
Hi Dave,
drm-intel-next-2014-03-21:
- Inherit/reuse firmwar framebuffers (for real this time) from Jesse, less
flicker for fastbooting.
- More flexible cloning for hdmi (Ville).
- Some PPGTT fixes from Ben.
- Ring init fixes from Naresh Kumar.
- set_cache_level regression fixes for the vma conve
Hi, again!
I've looked through the code again and have some answers to your
questions. Will post an updated patch soon.
On 03/28/2014 01:19 AM, David Herrmann wrote:
> Hi
>
> On Thu, Mar 27, 2014 at 9:23 PM, Thomas Hellstrom
> wrote:
>> The master management was previously protected by the
>>
On Fri, Mar 28, 2014 at 02:46:11AM +, Dave Airlie wrote:
>
> Hi Linus,
>
> didn't want these to wait for stable cycle, the nouveau and radeon ones
> are the same problem, where the runtime pm stuff broke non-runtime pm
> managed secondary GPUs, udl is an oops on unplug, and i915 is a regress
On Thu, Mar 27, 2014 at 05:44:37PM -0700, Matt Roper wrote:
> Now that CRTC's have a primary plane, there's no need to track the
> framebuffer in the CRTC. Replace all references to the CRTC fb with the
> primary plane's fb.
>
> This patch was generated by the Coccinelle semantic patching tool us
On Thu, Mar 27, 2014 at 05:44:31PM -0700, Matt Roper wrote:
> When we expose non-overlay planes to userspace, they will become
> accessible via standard userspace plane API's. We should be able to
> handle the standard plane operations against primary planes in a generic
> way via the modeset hand
On Thu, Mar 27, 2014 at 05:44:34PM -0700, Matt Roper wrote:
> Some hardware has different size limits for different planes (e.g.,
> sprites/overlays can't always be as large as the upper bound for the
> primary plane). Adding read-only plane properties allows userspace
> to check these limits. By
On Thu, Mar 27, 2014 at 05:44:25PM -0700, Matt Roper wrote:
> Previous series revisions & explanation at [1], [2], and [3]
>
> This version of the patch series focuses on isolating the DRM core changes
> from
> individual driver changes to (hopefully) make this a bit easier to merge. New
> plane
Hi, David.
Thanks for reviewing.
I'll try to address all your concerns and resend.
/Thomas
On 03/28/2014 01:19 AM, David Herrmann wrote:
> Hi
>
> On Thu, Mar 27, 2014 at 9:23 PM, Thomas Hellstrom
> wrote:
>> The master management was previously protected by the
>> drm_device::struct_mutex.
>
On Fri, 28 Mar 2014, Christoph Jaeger wrote:
> __FUNCTION__ is gcc specific; use __func__ instead.
I acknowledge the patch is correct and functionally the same as
before. However the correct fix would be to drop __FUNCTION__ and the
corresponding "%s: " altogether as DRM_DEBUG_KMS includes printi
problem exists in latest stable branch 10.0.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/20140328/4bfbfd1d/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140328/499d8348/attachment.html>
Hi Linus,
didn't want these to wait for stable cycle, the nouveau and radeon ones
are the same problem, where the runtime pm stuff broke non-runtime pm
managed secondary GPUs, udl is an oops on unplug, and i915 is a regression
fix on Sandybridge even though it may break haswell (regression wins
Hi
On Thu, Mar 27, 2014 at 9:23 PM, Thomas Hellstrom
wrote:
> The master management was previously protected by the
> drm_device::struct_mutex.
> In order to avoid locking order violations in a reworked dropped master
> security check in the vmwgfx driver, break it out into a separate
> master
Hi
On Wed, Mar 26, 2014 at 9:40 PM, Thomas Hellstrom
wrote:
>> - Why don't add a spin-lock to "drm_file" instead? Use that one to
>> manage master contexts, but keep "struct_mutex" whenever calling into
>> driver callbacks (set_master/drop_master)
>
> See above. We can't have a lock in the drm_
__FUNCTION__ is gcc specific; use __func__ instead.
Signed-off-by: Christoph Jaeger
---
drivers/gpu/drm/i915/dvo_ns2501.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c
b/drivers/gpu/drm/i915/dvo_ns2501.c
index 954acb2..e40c
; dmesg.log"
--
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/20140328/96179c6f/attachment.html>
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140328/1813dda0/attachment.html>
78 matches
Mail list logo
