On 04/12/2012 11:44 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 04/12/2012 12:50 AM, Thierry Reding wrote:
>>> drm {
>>> compatible = "nvidia,tegra20-drm";
>>
>> I'm don't think having an explicit "drm" node is the right approach; drm
>> is after all a SW term and the
On 04/11/2012 05:48 AM, Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote:
This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
currently has rudimentary GEM support and can run a console on the
framebuffer as well as X using the xf86-video-modese
On Thu, Apr 12, 2012 at 02:19:25PM -0400, Ilija Hadzic wrote:
> The following set of patches is the reword of the series
> sent two weeks ago [2] that will revive the drm-render-nodes [1]
> branch. Details of the original series are described in [2].
>
> Patches in this series have been reworked (
Hi Ajax and Takashi,
Thanks for your comments.
> The intent here is great, but I don't like the way this is phrased, or
> the implementation.
To be honest I don't like this implementation as well. I just tried to
follow the way it wasa already there.
> CVT monitors _must_ accept GTF as well, ED
ta field is where everybody would expect it. Furthermore
> > this wouldn't be relevant if we decided not to support non-DT setups.
>
> Drivers are expected to use pre-existing platform data, if provided.
> This might happen in order to work around bugs in device tree content.
Okay I see. I'll have to store it in a separate field in the private
structure then.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120412/c6d1bc9b/attachment.pgp>
Am 12.04.2012 14:23, schrieb Ville Syrjälä:
> On Wed, Apr 11, 2012 at 08:53:08PM +0200, Roland Scheidegger wrote:
>> Am 05.04.2012 20:35, schrieb ville.syrj...@linux.intel.com:
>>> From: Ville Syrjälä
>>>
>>> These functions return the chroma subsampling factors for the specified
>>> pixel format.
Hi Linus,
mostly exynos and intel,
intel has 3 regression fixers (more info in intel merge commit), along
with some other make hw work fixes,
exynos has some cleanups and an ioctl fix
couple of radeon fixes, couple of build fixes, and a savage userspace
interface possible overflow fix.
Dave.
At Wed, 11 Apr 2012 21:59:28 -0300,
Rodrigo Vivi wrote:
>
> There are many bugs open on fd.o regarding missing modes that are supported
> on Windows and other closed source drivers.
> >From EDID spec we can (might?) infer modes using GTF and CVT when monitor
> >allows it trough range limited fla
promising option and it seems to have
quite a lot of momentum. Of course I'll need to get the DRM driver up and
running properly first.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120412/c6528e7d/attachment.pgp>
On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu wrote:
> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury
> wrote:
> > Thanks, that fixed it! :) I had a similar patch I've been working on
> > but I had my fix in the wrong place!
> >
> > In the working case, initially the BIOS has set GMA to within
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index 4be9c1a..ab3a051 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers
Copied from the list in xserver.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h | 94 +-
1 files changed, 93 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index a91ffb1..4be9
Require that the monitor support rb for rb modes to be added.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 83c51d6..0fc63ca 100644
--- a/dri
Slightly more honest naming.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4f52103..83c51d6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers
It won't find any, yet. Fix up callers to match: standard mode codes
will look prefer r-b modes for a given size if present, EST3 mode codes
will look for exactly the r-b-ness mentioned in the mode code. This
might mean fewer modes matched for EST3 mode codes between now and when
the DMT mode lis
No functional change, but will make an upcoming change clearer.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 79a3637..0a23ee5 10
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5a18b0d..79a3637 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@
These should have been there since day one.
This series cleans up the few places that touch the DMT list to handle rb
modes correctly, and then imports the modes from xserver's list, along with
a few cosmetic changes.
- ajax
On Thu, 12 Apr 2012, 12:22:34 BST, Steven Newbury
wrote:
> I've attempted to modify probe.c to disable 64-bit BARs not allocated
> above 4G so they get reallocated above when possible later.? It seemed
> to work, but again broke GMA despite the BAR originally containing an
> invalid address as m
Oh, I am sorry. I fixed it and now you can pull.
Thanks,
Inki Dae.
2012? 4? 12? ?? 4:20, Dave Airlie ?? ?:
> please before submitting ioctl's can someone review them to make sure
> they have no pointers in them ever.
>
> struct drm_exynos_vidi_connection {
>unsigned int connection;
>
On Thu, Apr 12, 2012 at 11:18:19AM +, Arnd Bergmann wrote:
> On Thursday 12 April 2012, Marek Szyprowski wrote:
> > Scatter lists were initially designed for the disk based block io
> > operations,
> > hence the presence of the in-page offsets and lengths for each chunk. For
> > multimedia u
Hi Thierry,
On Thursday, April 12, 2012 3:42 PM Thierry Reding wrote:
> > > Also this doesn't yet solve the vmap() problem that is needed for the
> > > kernel
> > > virtual mapping. I did try using dma_alloc_writecombine(), but that only
> > > works for chunks of 2 MB or smaller, unless I use
>
From: Alex Deucher
Forget to unreserve after pinning. This can lead to problems in
soft reset and resume.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/si.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon
On 04/12/2012 11:44 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 04/12/2012 12:50 AM, Thierry Reding wrote:
>>> drm {
>>> compatible = "nvidia,tegra20-drm";
>>
>> I'm don't think having an explicit "drm" node is the right approach; drm
>> is after all a SW term and the
Please, give me any comments and I hope this patch would be applied to
libdrm if there is any problem.
Thanks,
Inki Dae.
2012? 4? 2? ?? 9:08, Inki Dae ?? ?:
> this patch adds libdrm_exynos helper layer that inclues some intefaces
> for exynos specific gem and virtual display driver and also adds
Am Mittwoch, den 11.04.2012, 15:18 + schrieb Arnd Bergmann:
> On Wednesday 11 April 2012, Thierry Reding wrote:
> > * Daniel Vetter wrote:
> > > On Wed, Apr 11, 2012 at 03:23:26PM +0200, Thierry Reding wrote:
> > > > * Daniel Vetter wrote:
> > > > > On Wed, Apr 11, 2012 at 02:10:30PM +0200, T
Hi Ajax and Takashi,
Thanks for your comments.
> The intent here is great, but I don't like the way this is phrased, or
> the implementation.
To be honest I don't like this implementation as well. I just tried to
follow the way it wasa already there.
> CVT monitors _must_ accept GTF as well, ED
uously then there wouldn't be any need for the IOMMU,
right?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120412/4adecf64/attachment.pgp>
Hi Dave,
Please pull from
git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-fixes
this branch is based on git repository below:
git://people.freedesktop.org/~airlied/linux.git drm-fixes
commit-id: 62fb376e214d3c1bfdf6fbb77dac162f6da04d7e
this patch set include
The refactoring of the nv50 logic, introduced in 8663bc7c, modified the
test for the special lane map used on some Apple computers with Nvidia
chipsets. The tested MBA3,1 would still boot, but resume from suspend
stopped working. This patch restores the old test, which fixes the problem.
Signed-of
s/dri-devel/attachments/20120412/3b69494d/attachment.pgp>
Hi Arnd,
On Thursday, April 12, 2012 1:18 PM Arnd Bergmann wrote:
> On Thursday 12 April 2012, Marek Szyprowski wrote:
> > Scatter lists were initially designed for the disk based block io
> > operations,
> > hence the presence of the in-page offsets and lengths for each chunk. For
> > multimedi
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120412/e80e3833/attachment-0001.pgp>
On Wed, Apr 11, 2012 at 08:53:08PM +0200, Roland Scheidegger wrote:
> Am 05.04.2012 20:35, schrieb ville.syrjala at linux.intel.com:
> > From: Ville Syrj?l?
> >
> > These functions return the chroma subsampling factors for the specified
> > pixel format.
> Hmm not really related but looking at it
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index 4be9c1a..ab3a051 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers
Copied from the list in xserver.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h | 94 +-
1 files changed, 93 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index a91ffb1..4be9
Require that the monitor support rb for rb modes to be added.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 83c51d6..0fc63ca 100644
--- a/dri
Slightly more honest naming.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4f52103..83c51d6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers
It won't find any, yet. Fix up callers to match: standard mode codes
will look prefer r-b modes for a given size if present, EST3 mode codes
will look for exactly the r-b-ness mentioned in the mode code. This
might mean fewer modes matched for EST3 mode codes between now and when
the DMT mode lis
No functional change, but will make an upcoming change clearer.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 79a3637..0a23ee5 10
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5a18b0d..79a3637 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@
These should have been there since day one.
This series cleans up the few places that touch the DMT list to handle rb
modes correctly, and then imports the modes from xserver's list, along with
a few cosmetic changes.
- ajax
___
dri-devel mailing list
Add two simple programs (render_node_add and render_node_rm)
that can be used to add and remove render nodes from a shell
command or a script.
v2: - add planes
Signed-off-by: Ilija Hadzic
---
.gitignore |2 +
configure.ac |1 +
tests/Mak
Implement the user-space side of drm_render_node_create
and drm_render_node_remove ioctls. The new functions
are drmCreateRenderNode and drmRemoveRenderNode.
v2: - add planes
Signed-off-by: Ilija Hadzic
---
include/drm/drm.h |2 +
include/drm/drm_mode.h | 17 ++
xf86drm.c
The following two patches are the rework of the patch series sent two weeks
ago [1] that add libdrm support for render node manipulation. All notes
described in [1] apply. A new option to render_node_add utility has
been added to specify the number of planes and plane IDs are supposed to
be the las
Critical sections are parts of the code where we claim or
release resources (we don't want two render-node create or
remove ioctl called in the context of different processes
to claim part of requested resources because of the race).
Another critical section is manipulating the render node
list. We
Add fields to drm_crtc, drm_encoder, drm_connector, and drm_plane
that keep track of which render node owns it. Assign ownership
when resource is added and revoke it when resource is destroyed.
Do not allow creation of a node that tries to claim resources
that are already in use by another node.
v
Render node ioctl requires a list of DRM mode objects
in specific order: first all CRTCs, then all encoders,
followed by all connectors. Check that the IDs passed
from userland are in conformance with this requirement
and that they are consistent with specified num_crtc,
num_encoder and num_connect
User space can send us all kinds of nonsense for num_crtc, num_encoder,
num_connector, or num_plane. So far, we have been checking only for
presence of at least one CRTC/encoder/connector (barring the trivial
case of a render node with no display resources, i.e., GPGPU node).
This patch makes the
In drm_put_dev, the whole device is being destroyed, so id_list
of the primary (legacy) node should also be cleaned up.
This plugs a memory leak that has probably existed even without
the render-node work.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_stub.c |1 +
1 files changed, 1 in
id_list is dynamically allocated when a render node is
created. Consequently, if must be freed when the render node
is removed, otherwise we have a memory leak.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_stub.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git
This is the opposite function of drm_mode_group_init. It will
be needed to properly cleanup the render node after removing it.
v2: - add planes
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc.c | 11 +++
include/drm/drm_crtc.h |1 +
2 files changed, 12 insertions(+),
When a new render node is created, the number of elements
of id_list allocated in drm_mode_group_init function should
not be the sum of all CRTCs, encoders, and connectors that
the device has, but the one specified by the ioctl that
created the node.
v2: - add planes
Signed-off-by: Ilija Hadzic
Keep track of per-node open count and do not allow removal
of a render node in use.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_fops.c |2 ++
drivers/gpu/drm/drm_stub.c |2 ++
include/drm/drmP.h |1 +
3 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/driv
The render-node manipulation ioctls are supposed to be
issued through control node only. Add a check and return
-EPERM to user space if access is attempted through a
node other than a control node.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_stub.c |8
1 files changed, 8 ins
Fix a few bugs in render node create and destroy ioctl
(mostly handling of error cases). Also separate some
common code into a new function for destroying
the render node.
v2: - support planes
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_stub.c | 81 +++-
drm_minor structure had a list_head pointer that was
used only for render nodes. control and primary nodes
do not live in the list and had this list pointer unused.
Create a separate drm_render_node structure that is used
to build the render node list and that points to the
coresponding minor. Thi
From: Dave Airlie
just adds some unchecked ioctls to setup the nodes.
Signed-off-by: Dave Airlie
v2: - original ioctl numbers are now taken, use next available
- resolve some trivial conflicts due to bit-rot that
occurred since the original patch was created
v3: - added planes to AB
Add support for creating multiple render nodes on the same
physical GPU.
Patch derived from 7c5cc4f63556e351e9e5980ed22accad410e3fdc
originally authored by Dave Airlie.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc.c |1 +
drivers/gpu/drm/drm_stub.c | 32 +++
Make dev_mapping per-minor instead of per device. This is
a preparatory patch for introducing render nodes. This
will allow per-node instead of per-device mapping range,
once we introduce render nodes.
Patch derived from 7c5cc4f63556e351e9e5980ed22accad410e3fdc
originally authored by Dave Airlie.
Push minor number instead. This is a preparatory
patch for introducing render nodes. It has been derived
from 7c5cc4f63556e351e9e5980ed22accad410e3fdc originally
created by Dave Airlie.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_fops.c | 19 ++-
1 files changed, 10 ins
drm_mode_group structure now tracks planes, so use it in
in drm_mode_getplane_res(ources) IOCTL.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc.c | 46 +--
1 files changed, 35 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_crt
drm_mode_group structure (meant for subgrouping) of display
resources didn't include planes, which made it impossible to
do any subgrouping of planes. This patch rectifies the problem.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc.c |8
include/drm/drm_crtc.h |2 +
file_priv->master->minor is equivalent to file_priv->minor
http://lists.freedesktop.org/archives/dri-devel/2011-October/015511.html
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_crt
The following set of patches is the reword of the series
sent two weeks ago [2] that will revive the drm-render-nodes [1]
branch. Details of the original series are described in [2].
Patches in this series have been reworked (and a few prep patches
have been added) to address the comment about the
On Thu, 12 Apr 2012, Ville [iso-8859-1] Syrj?l? wrote:
> Didn't have time for a detailed look yet, but at least one thing
> missing from your patch set is handling of possible_crtcs and
> possible_clones for getplane and getencoder ioctls.
Yes I agree and I know. That is still work in progress.
From: Alex Deucher
Forget to unreserve after pinning. This can lead to problems in
soft reset and resume.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/si.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon
On Mon, Apr 2, 2012 at 7:08 AM, Inki Dae wrote:
> this patch adds libdrm_exynos helper layer that inclues some intefaces
> for exynos specific gem and virtual display driver and also adds exynos
> module name to modtest and vbltest.
>
> this patch is based on a link below:
> ? ? ? ?git://anongit.f
On Thu, 12 Apr 2012, 01:57:17 BST, Yinghai Lu wrote:
> On Tue, Apr 10, 2012 at 2:19 PM, Steven Newbury
> wrote:
> > Another thought, normally the integrated graphics has an "AGP"
> > aperture of 256M @0xe000, which is detected by agpgart-intel, this
> > will need to be moved up above 4G to f
On Thu, 12 Apr 2012, Ville [iso-8859-1] Syrjälä wrote:
Didn't have time for a detailed look yet, but at least one thing
missing from your patch set is handling of possible_crtcs and
possible_clones for getplane and getencoder ioctls.
Yes I agree and I know. That is still work in progress. Th
RIVER, 348500, 2560, 2760,
> +3032, 3504, 0, 1600, 1603, 1609, 1658, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
lol no. Nobody does a size this large without also doing reduced
blanking.
I have a patch somewhere to fix the DMT list to re-include the
On Thu, Apr 12, 2012 at 02:19:25PM -0400, Ilija Hadzic wrote:
> The following set of patches is the reword of the series
> sent two weeks ago [2] that will revive the drm-render-nodes [1]
> branch. Details of the original series are described in [2].
>
> Patches in this series have been reworked (
On 04/11/2012 05:48 AM, Daniel Vetter wrote:
> On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote:
>> This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
>> currently has rudimentary GEM support and can run a console on the
>> framebuffer as well as X using the xf86-vide
https://bugs.freedesktop.org/show_bug.cgi?id=48599
Bug #: 48599
Summary: Fix compiler warnings in tests/radeon/radeon_ttm.c
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: Other
OS/Version: All
St
Add two simple programs (render_node_add and render_node_rm)
that can be used to add and remove render nodes from a shell
command or a script.
v2: - add planes
Signed-off-by: Ilija Hadzic
---
.gitignore |2 +
configure.ac |1 +
tests/Mak
Implement the user-space side of drm_render_node_create
and drm_render_node_remove ioctls. The new functions
are drmCreateRenderNode and drmRemoveRenderNode.
v2: - add planes
Signed-off-by: Ilija Hadzic
---
include/drm/drm.h |2 +
include/drm/drm_mode.h | 17 ++
xf86drm.c
The following two patches are the rework of the patch series sent two weeks
ago [1] that add libdrm support for render node manipulation. All notes
described in [1] apply. A new option to render_node_add utility has
been added to specify the number of planes and plane IDs are supposed to
be the las
Critical sections are parts of the code where we claim or
release resources (we don't want two render-node create or
remove ioctl called in the context of different processes
to claim part of requested resources because of the race).
Another critical section is manipulating the render node
list. We
Add fields to drm_crtc, drm_encoder, drm_connector, and drm_plane
that keep track of which render node owns it. Assign ownership
when resource is added and revoke it when resource is destroyed.
Do not allow creation of a node that tries to claim resources
that are already in use by another node.
v
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120412/52537508/attachment.pgp>
Render node ioctl requires a list of DRM mode objects
in specific order: first all CRTCs, then all encoders,
followed by all connectors. Check that the IDs passed
from userland are in conformance with this requirement
and that they are consistent with specified num_crtc,
num_encoder and num_connect
User space can send us all kinds of nonsense for num_crtc, num_encoder,
num_connector, or num_plane. So far, we have been checking only for
presence of at least one CRTC/encoder/connector (barring the trivial
case of a render node with no display resources, i.e., GPGPU node).
This patch makes the
In drm_put_dev, the whole device is being destroyed, so id_list
of the primary (legacy) node should also be cleaned up.
This plugs a memory leak that has probably existed even without
the render-node work.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_stub.c |1 +
1 files changed, 1 in
id_list is dynamically allocated when a render node is
created. Consequently, if must be freed when the render node
is removed, otherwise we have a memory leak.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_stub.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git
This is the opposite function of drm_mode_group_init. It will
be needed to properly cleanup the render node after removing it.
v2: - add planes
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc.c | 11 +++
include/drm/drm_crtc.h |1 +
2 files changed, 12 insertions(+),
Keep track of per-node open count and do not allow removal
of a render node in use.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_fops.c |2 ++
drivers/gpu/drm/drm_stub.c |2 ++
include/drm/drmP.h |1 +
3 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/driv
When a new render node is created, the number of elements
of id_list allocated in drm_mode_group_init function should
not be the sum of all CRTCs, encoders, and connectors that
the device has, but the one specified by the ioctl that
created the node.
v2: - add planes
Signed-off-by: Ilija Hadzic
The render-node manipulation ioctls are supposed to be
issued through control node only. Add a check and return
-EPERM to user space if access is attempted through a
node other than a control node.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_stub.c |8
1 files changed, 8 ins
Fix a few bugs in render node create and destroy ioctl
(mostly handling of error cases). Also separate some
common code into a new function for destroying
the render node.
v2: - support planes
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_stub.c | 81 +++-
drm_minor structure had a list_head pointer that was
used only for render nodes. control and primary nodes
do not live in the list and had this list pointer unused.
Create a separate drm_render_node structure that is used
to build the render node list and that points to the
coresponding minor. Thi
From: Dave Airlie
just adds some unchecked ioctls to setup the nodes.
Signed-off-by: Dave Airlie
v2: - original ioctl numbers are now taken, use next available
- resolve some trivial conflicts due to bit-rot that
occurred since the original patch was created
v3: - added planes to AB
Add support for creating multiple render nodes on the same
physical GPU.
Patch derived from 7c5cc4f63556e351e9e5980ed22accad410e3fdc
originally authored by Dave Airlie.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc.c |1 +
drivers/gpu/drm/drm_stub.c | 32 +++
Make dev_mapping per-minor instead of per device. This is
a preparatory patch for introducing render nodes. This
will allow per-node instead of per-device mapping range,
once we introduce render nodes.
Patch derived from 7c5cc4f63556e351e9e5980ed22accad410e3fdc
originally authored by Dave Airlie.
Push minor number instead. This is a preparatory
patch for introducing render nodes. It has been derived
from 7c5cc4f63556e351e9e5980ed22accad410e3fdc originally
created by Dave Airlie.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_fops.c | 19 ++-
1 files changed, 10 ins
drm_mode_group structure now tracks planes, so use it in
in drm_mode_getplane_res(ources) IOCTL.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc.c | 46 +--
1 files changed, 35 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_crt
drm_mode_group structure (meant for subgrouping) of display
resources didn't include planes, which made it impossible to
do any subgrouping of planes. This patch rectifies the problem.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc.c |8
include/drm/drm_crtc.h |2 +
file_priv->master->minor is equivalent to file_priv->minor
http://lists.freedesktop.org/archives/dri-devel/2011-October/015511.html
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_crt
On Wed, Apr 11, 2012 at 12:12:14PM -0600, Stephen Warren wrote:
> On 04/11/2012 06:10 AM, Thierry Reding wrote:
> > This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
> > currently has rudimentary GEM support and can run a console on the
> > framebuffer as well as X using the xf86-v
The following set of patches is the reword of the series
sent two weeks ago [2] that will revive the drm-render-nodes [1]
branch. Details of the original series are described in [2].
Patches in this series have been reworked (and a few prep patches
have been added) to address the comment about the
Forwarding the pull request to Dave to intel-gfx and dri-devel, I've
fumbled the cc list on the original mail.
-Daniel
-- Forwarded message --
From: Daniel Vetter
Date: Thu, Apr 12, 2012 at 11:17
Subject: [pull] drm-intel-next for 3.5
To: Dave Airlie
Hi Dave
First pull request
1 - 100 of 169 matches
Mail list logo