* Stephen Warren wrote:
On 04/11/2012 06:10 AM, Thierry Reding wrote:
This commit adds device tree support for the GART hardware available on
NVIDIA Tegra 20 SoCs.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
arch/arm/boot/dts/tegra20.dtsi |6 ++
Hi Dave
3 regression fixes:
- disable gmbus again, too broken for 3.4, we'll try again for 3.5
- dp bandwidth computation fix, we've lost the 6bpc dithering flag
sometimes, this is a 3.3 regression (maybe even earlier for some
configurations).
- fix resume regression caused by the gen2/3
Oh, I am sorry. I fixed it and now you can pull.
Thanks,
Inki Dae.
2012년 4월 12일 오후 4:20, Dave Airlie airl...@gmail.com님의 말:
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
On Wed, Apr 11, 2012 at 09:22:47PM +0100, Alan Cox wrote:
+static int sdrm_suspend(struct drm_device *drm, pm_message_t state)
+{
+ /* TODO */
+
+ return 0;
+}
+
+static int sdrm_resume(struct drm_device *drm)
+{
+ /* TODO */
+
+ return 0;
+}
These probably
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 dan...@ffwll.ch
Date: Thu, Apr 12, 2012 at 11:17
Subject: [pull] drm-intel-next for 3.5
To: Dave Airlie
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
* Sascha Hauer wrote:
You might want to have a look at the sdrm patches I recently posted to
dri-devel and arm Linux Kernel. Among other things they allow to
register crtcs/connectors/encoders seperately so that each of them can
have its own representation in the devicetree. I haven't looked
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 use cases providing an array of struct pages and asking
dma-mapping
to map
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
On Thu, 12 Apr 2012, 01:57:17 BST, Yinghai Lu ying...@kernel.org wrote:
On Tue, Apr 10, 2012 at 2:19 PM, Steven Newbury st...@snewbury.org.uk
wrote:
Another thought, normally the integrated graphics has an AGP
aperture of 256M @0xe000, which is detected by agpgart-intel, this
will
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ä ville.syrj...@linux.intel.com
These functions return the chroma subsampling factors for the specified
pixel format.
Hmm not really related
On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
* Sascha Hauer wrote:
You might want to have a look at the sdrm patches I recently posted to
dri-devel and arm Linux Kernel. Among other things they allow to
register crtcs/connectors/encoders seperately so
* Alex Deucher wrote:
On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
In other words I would like to use the Tegra hardware to render content into
a framebuffer (using potentially the 3D engine or HW accelerated video
decoding blocks) but display
* Marek Szyprowski wrote:
[...]
We already have dma_map_page() and dma_map_single() which are very similar.
Maybe adding dma_map_pages() won't be such a bad idea?
If not maybe we should provide some kind of helper functions which converts
page array to scatterlist and then maps them.
Hi Thierry,
On Thursday, April 12, 2012 9:18 AM Thierry Reding wrote:
* Arnd Bergmann wrote:
On Wednesday 11 April 2012, Thierry Reding wrote:
Daniel Vetter wrote:
Well, you use the iommu api to map/unmap memory into the iommu for
tegra,
whereas usually device drivers just use
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
multimedia use
On Thu, Apr 12, 2012 at 9:25 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
* Alex Deucher wrote:
On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
In other words I would like to use the Tegra hardware to render content
into
a framebuffer
On Thu, Apr 12, 2012 at 10:09 AM, Alex Deucher alexdeuc...@gmail.com wrote:
On Thu, Apr 12, 2012 at 9:25 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
* Alex Deucher wrote:
On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
In other words I
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 use cases
2012/4/11 Christian König deathsim...@vodafone.de:
Different rings have different criteria to test
if they are stuck.
Signed-off-by: Christian König deathsim...@vodafone.de
For the series:
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
drivers/gpu/drm/radeon/radeon.h |
On Wed, 2012-04-11 at 21:59 -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 flag...
On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury st...@snewbury.org.uk 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 the low system
DRAM 0xC000 obviously
* Alex Deucher wrote:
On Thu, Apr 12, 2012 at 10:09 AM, Alex Deucher alexdeuc...@gmail.com wrote:
On Thu, Apr 12, 2012 at 9:25 AM, Thierry Reding
Then again, having user-space control this may be more flexible.
Performance-
wise both should be about the same, right? What I don't quite
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 flag...
On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu ying...@kernel.org wrote:
On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury st...@snewbury.org.uk
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
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.
* 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 DT should be describing HW. Having some
kind of top-level
On Mon, Apr 2, 2012 at 7:08 AM, Inki Dae inki@samsung.com 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:
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
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 ihad...@research.bell-labs.com
---
drivers/gpu/drm/drm_crtc.c |8
drm_mode_group structure now tracks planes, so use it in
in drm_mode_getplane_res(ources) IOCTL.
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/drm_crtc.c | 46 +--
1 files changed, 35 insertions(+), 11 deletions(-)
diff
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 ihad...@research.bell-labs.com
---
drivers/gpu/drm/drm_fops.c | 19
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.
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.
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 ihad...@research.bell-labs.com
---
drivers/gpu/drm/drm_stub.c | 81
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 ihad...@research.bell-labs.com
---
drivers/gpu/drm/drm_stub.c |8
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 ihad...@research.bell-labs.com
---
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
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 ihad...@research.bell-labs.com
---
drivers/gpu/drm/drm_crtc.c | 11 +++
include/drm/drm_crtc.h |1 +
2
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 ihad...@research.bell-labs.com
---
drivers/gpu/drm/drm_stub.c |6 ++
1 files changed, 6
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 ihad...@research.bell-labs.com
---
drivers/gpu/drm/drm_stub.c
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
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.
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.
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
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 ihad...@research.bell-labs.com
---
include/drm/drm.h |2 +
include/drm/drm_mode.h |
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 ihad...@research.bell-labs.com
---
.gitignore |2 +
configure.ac
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 (and
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 alexander.deuc...@amd.com
Forget to unreserve after pinning. This can lead to problems in
soft reset and resume.
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
drivers/gpu/drm/radeon/si.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git
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
Slightly more honest naming.
Signed-off-by: Adam Jackson a...@redhat.com
---
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
---
Require that the monitor support rb for rb modes to be added.
Signed-off-by: Adam Jackson a...@redhat.com
---
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
Copied from the list in xserver.
Signed-off-by: Adam Jackson a...@redhat.com
---
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
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.
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, EDID
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, Thierry Reding
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ä ville.syrj...@linux.intel.com
These functions return the chroma subsampling factors for the specified
101 - 158 of 158 matches
Mail list logo
