e the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140327/3d1cd226/attachment.html>
From: Sagar Kamble
v2: Added description for "src-color" and "constant-alpha" property.
[Review by Laurent Pinchart]
v3: Fixed typos. [Review by David Herrmann]
v4: Additional formatting and modified description. [Review by David Herrmann]
Cc: rob at landley.net
Cc: airlied at redhat.com
C
ou seeing performance issues with pi->mclk_dpm_key_disabled = 1; as well?
--
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/20
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 477208d..7c0eec8 100644
--
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 477208d..7c0eec8 100644
--
This patch removes platform_driver_register() calls from
exynos_drm_drv module, and calls module_platform_driver()
at each kms sub drivers instead.
Previous RFC patch,
http://www.spinics.net/lists/dri-devel/msg54672.html
Changelog since RFC patch:
- remove unnecessary platform_driver decl
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,
exynos-drm {
compatible = "samsung,exynos-drm";
crtcs = <&fimd>;
This patch series cleans up exynos drm framework and kms sub drivers
using the component framework[1].
And this patch series had been posted for RFC[2].
Thanks,
Inki Dae
[1] http://lists.freedesktop.org/archives/dri-devel/2014-January/051249.html
[2] http://comments.gmane.org/gmane.comp.video.dr
If using legacy (non-prime) surface sharing, only allow surfaces
to be shared between clients with the same master. This will block
malicious clients from peeking at contents at surfaces from other
(possibly vt-switched) masters.
v2:
s/legacy_client/primary_client/
Signed-off-by: Thomas Hellstrom
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.
Also remove drm_master::blocked since it's not used.
v2: Add an i
Add a drm_is_legacy() helper, constify argument to drm_is_render_client(),
and use / change helpers where appropriate.
v2: s/drm_is_legacy/drm_is_legacy_client/ and adapt to new code context.
v3: s/legacy_client/primary_client/
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
driver
Resending only those patches that were commented on (4, 6) and one that
was affected by a change in 4 (12).
If there are no objections, I'll include this in a vmwgfx-next pull request.
Thanks,
Thomas
kernel
> involved as well? How would I begin to debug this issue?
>
> Thanks in advance,
> Sandeep
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140327/8d357554/attachment-0001.html>
the kernel involved as
well? How would I begin to debug this issue?
Thanks in advance,
Sandeep
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140327/a4b00c29/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140327/a973c017/attachment-0001.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/20140327/5bee1dd9/attachment.html>
ail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140327/dee968dd/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140327/267fa365/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140327/b9b83c23/attachment.html>
vel/attachments/20140327/16cbecb0/attachment.html>
h fglrx and radeon? E.g., xrandr
--verbose.
--
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/20140327/ca53c35c/attachment.html>
Signed-off-by: Matt Roper
---
include/drm/drm_crtc.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e7ed766..282f823 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -311,9 +311,6 @@ struct drm_crtc {
struct d
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 using
the following rules:
@@ struct drm_crtc C; @@
-
Use drm_universal_plane_init() and drm_crtc_init_with_planes() rather
than the legacy drm_plane_init() / drm_crtc_init(). This will ensure
that the proper primary plane is registered with the DRM (and eventually
exposed to userspace in future patches).
Cc: Rob Clark
Signed-off-by: Matt Roper
--
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 CRTC with a plane helper-created primary
plane and no cursor
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 default, mode_config.max_{width,height} are
used for non-cursor pla
Add a plane type property to allow userspace to distinguish plane types.
v2: Driver-specific churn eliminated now that drm_plane_init() and
drm_universal_plane_init() were separated out in a previous patch.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_crtc.c | 23 ++
Add a new plane initialization interface for universal plane support
that allows a specific plane type (primary, cursor, or overlay) to
be specified.
drm_plane_init() remains as a compatibility API to reduce churn in
existing drivers. The 'bool priv' parameter has been changed to
'bool is_primary
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 handler.
Drivers that can program primary planes more efficiently, that
This function will be used by the universal plane helpers and may also
be useful for individual drivers.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_crtc.c | 20 +---
include/drm/drm_crtc.h | 4
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drive
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
Signed-off-by: Matt Roper
---
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 2 +-
1 file changed, 1
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.
v2: Switch to using drm_for_each_legacy_plane()
Cc: Intel Graphics Development
Signed-off-by: Matt Roper
---
drivers/g
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.
v2: Switch to using drm_for_each_legacy_plane()
Cc: Inki Dae
Signed-off-by: Matt Roper
---
drivers/gpu/drm/exynos/exyn
The DRM core currently only tracks "overlay"-style planes. Start
refactoring the plane handling to allow other plane types (primary and
cursor) to also be placed on the DRM plane list.
v2: Add drm_for_each_legacy_plane() iterator to smooth transition
of drivers with plane loops.
Signed-off-b
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 and crtc initialization functions have been added to allow drivers to
mi
L2 does seem to be used as it does not change. PPLL1 has different values
than with the radeon OSS driver. What does this mean?
--
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/20140327/c9d9c9b6/attachment.html>
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,
>
> In case of using MIPI-DSI,
> exynos-drm {
>
From: Sagar Kamble
v2: Added description for "src-color" and "constant-alpha" property.
[Review by Laurent Pinchart]
v3: Fixed typos. [Review by David Herrmann]
Cc: Rob Landley
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Laurent Pinchart
Cc: David Herrmann
Cc: Alex Deucher
Cc: "Ville Syrj?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/20140327/466d4d12/attachment.html>
|--- |FIXED
--
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/20140327/f5d0f40b/attachment.html>
dying!
Thanks for taking a look Alex.
--
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/20140327/5930a1e0/attachment.html>
bbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140327/ff8d804a/attachment.html>
From: Sagar Kamble
v2: Added description for "src-color" and "constant-alpha" property.
[Review by Laurent Pinchart]
v3: Fixed typos. [Review by David Hermann]
Cc: Rob Landley
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Laurent Pinchart
Cc: David Herrmann
Cc: Alex Deucher
Cc: "Ville Syrj?l?
From: Dave Airlie
For runtime pm we'd never suspend with the modesetting hw turned on,
so don't try and resume the modesetting hw, as that path will take
locks that the interface that is causing us to wake up might also
take.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_device.
From: Dave Airlie
Same fix as for nouveau, when we fail with EINVAL, subsequent
gets fail hard, causing the device not to open.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_drv.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/
Hi
On Thu, Mar 27, 2014 at 10:50 AM, wrote:
> From: Sagar Kamble
>
> v2: Added description for "src-color" and "constant-alpha" property.
> [Review by Laurent Pinchart]
>
> v3: Fixed typos. [Review by David Herrmann]
>
> Cc: Rob Landley
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Laurent
On Wed, Mar 26, 2014 at 7:33 PM, Lucas Stach wrote:
>> > It does so by doing the necessary manual cache flushes/invalidates on
>> > buffer access, so costs some performance. To avoid this you really want
>> > to get writecombined mappings into the kernel<->userspace interface.
>> > Simply mapping
Hi Laurent,
On Wed, 26 Mar 2014 18:33:09 +0100
Laurent Pinchart wrote:
> That could work in your case, but I don't really like that.
>
> We need to describe the hardware topology, that might be the only point we
> all
> agree on. There are various hardware topologies we need to support with
I have tested this patch. I can confirm that now nouveau loads
correctly without errors.
Thank you
2014-03-27 0:37 GMT+01:00 Ilia Mirkin :
> There appear to be a crop of new hardware where the vbios is not
> available from PROM/PRAMIN, but there is a valid _ROM method in ACPI.
> The data read from
On Mon, Mar 24, 2014 at 4:04 PM, Bjorn Helgaas wrote:
> On Sat, Mar 22, 2014 at 9:18 AM, Andy Lutomirski
> wrote:
>> On Fri, Mar 21, 2014 at 9:37 AM, Bjorn Helgaas
>> wrote:
>>> On Fri, Mar 21, 2014 at 9:49 AM, Andy Lutomirski
>>> wrote:
On Fri, Mar 21, 2014 at 7:41 AM, Alex Deucher
>
On Thu, Mar 27, 2014 at 10:37 AM, Ilya Faenson wrote:
> I knew it was not run-of-the-mill request. :-)
>
> Is the work you've mentioned publicly available? If so, could you publish
> its whereabouts?
Well its what you would call public but unloved, its also 4 years old,
and very unlikely to clean
On Thu, Mar 27, 2014 at 2:02 AM, Ilya Faenson wrote:
> Dear DRM Experts,
>
> My assignment is to make sure the more or less standard HDMI-connected
> monitor is visible and accessible to a single (our own) OpenGL application
> only. That monitor is part of the larger device so it does not make sen
On Thu, Mar 27, 2014 at 9:37 AM, Ilia Mirkin wrote:
> There appear to be a crop of new hardware where the vbios is not
> available from PROM/PRAMIN, but there is a valid _ROM method in ACPI.
> The data read from PCIROM almost invariably contains invalid
> instructions (still has the x86 opcodes),
53 matches
Mail list logo
