[RFC v2] Revive the work on render-nodes branch

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

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

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,

[RFC 4/4] drm: Add NVIDIA Tegra support

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>

[git pull] drm fixes

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.

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

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

[RFC 4/4] drm: Add NVIDIA Tegra support

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>

PCI resources above 4GB

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

[PATCH 7/7] drm/edid: Fix some comment typos in the DMT mode list

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 +++

[PATCH 6/7] drm/edid: Add the reduced blanking DMT modes to the DMT list

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

[PATCH 5/7] drm/edid: Armor drm_dmt_modes_for_range for reduced blanking modes

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 ---

[PATCH 4/7] drm/edid: s/drm_gtf_modes_for_range/drm_dmt_modes_for_range/

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 +++

[PATCH 3/7] drm/edid: Allow drm_mode_find_dmt to hunt for reduced-blanking modes

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

[PATCH 2/7] drm/edid: Rewrite drm_mode_find_dmt search loop

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

[PATCH 1/7] drm/edid: Document drm_mode_find_dmt

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 @@

[PATCH 0/7] drm/edid: Add the reduced-blanking modes to the DMT list

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

PCI resources above 4GB

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

exynos broken ioctl

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; >

[RFC 4/4] drm: Add NVIDIA Tegra support

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

[RFC 4/4] drm: Add NVIDIA Tegra support

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

[PATCH] drm/radeon/si: add missing radeon_bo_unreserve in si_rlc_init()

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

[RFC 4/4] drm: Add NVIDIA Tegra support

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

[PATCH libdrm] exynos: add exynos drm support

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

[RFC 4/4] drm: Add NVIDIA Tegra support

e 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>

[git pull] updated exynos-drm-fixes

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

[RFC 4/4] drm: Add NVIDIA Tegra support

-devel/attachments/20120412/3b69494d/attachment.pgp>

[RFC 4/4] drm: Add NVIDIA Tegra support

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 > >

[RFC 4/4] drm: Add NVIDIA Tegra support

lication/pgp-signature Size: 198 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120412/e80e3833/attachment-0001.pgp>

[PATCH 3/4] drm: Add drm_format_{horz, vert}_chroma_subsampling() utility functions

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

[PATCH 2/2] tests: add render_node tests

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 +

[PATCH 1/2] libdrm: add functions for render node manipulation

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 ++

[RFC v2] libdrm part of the render-node patch series

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

[PATCH 19/19] drm: hold mutex in critical sections of render-node code

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.

[PATCH 18/19] drm: keep track of which node holds which resource

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.

[PATCH 17/19] drm: validate id list when creating a render node

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

[PATCH 16/19] drm: more elaborate check for resource count

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

[PATCH 15/19] drm: call drm_mode_group_fini on primary node

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

[PATCH 14/19] drm: properly free id_list when a render node is removed

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

[PATCH 13/19] drm: add drm_mode_group_fini function

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(+),

[PATCH 12/19] drm: allocate correct id_list size for a render node

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

[PATCH 11/19] drm: do not remove a render node in use

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

[PATCH 10/19] drm: only allow render node ioctls through control node

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

[PATCH 09/19] drm: cleanup render node ioctls

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

[PATCH 08/19] drm: separate render node descriptor from minor

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.

[PATCH 07/19] drm: initial multiple nodes ioctl work.

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:

[PATCH 06/19] drm: add support for render nodes

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

[PATCH 05/19] drm: move dev_mapping to the minor node

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.

[PATCH 04/19] drm: do not push inode down into drm_open_helper

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

[PATCH 03/19] drm: use drm_mode_group in drm_mode_getplane_res

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

[PATCH 02/19] drm: track planes in drm_mode_group structure

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

[PATCH 01/19] drm: simplify dereferencing of node type

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

[RFC v2] Revive the work on render-nodes branch

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

[RFC v2] Revive the work on render-nodes branch

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

[PATCH libdrm] exynos: add exynos drm support

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: > ? ? ?

PCI resources above 4GB

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

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

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 reduced blanking modes (as should have been done in the

[RFC 4/4] drm: Add NVIDIA Tegra support

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

[Bug 48599] New: Fix compiler warnings in tests/radeon/radeon_ttm.c

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

[RFC 4/4] drm: Add NVIDIA Tegra support

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>

[RFC 4/4] drm: Add NVIDIA Tegra support

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

Fwd: [pull] drm-intel-next for 3.5

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

[RFC 4/4] drm: Add NVIDIA Tegra support

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

[PATCH 3/7] DRM: add sdrm layer for general embedded system support

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; >

[PATCH 1/4] drm/radeon: make radeon_gpu_is_lockup a per ring function

2012/4/11 Christian K?nig : > Different rings have different criteria to test > if they are stuck. > > Signed-off-by: Christian K?nig For the series: Reviewed-by: Alex Deucher > --- > ?drivers/gpu/drm/radeon/radeon.h ? ? ? | ? ?4 +- > ?drivers/gpu/drm/radeon/radeon_asic.c ?| ? 36

[RFC 4/4] drm: Add NVIDIA Tegra support

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

[RFC 4/4] drm: Add NVIDIA Tegra support

On Thu, Apr 12, 2012 at 10:09 AM, Alex Deucher wrote: > On Thu, Apr 12, 2012 at 9:25 AM, Thierry Reding > wrote: >> * Alex Deucher wrote: >>> On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding >>> wrote: >>> > In other words I would like to use the Tegra hardware to render content >>> > into >>>

[RFC 4/4] drm: Add NVIDIA Tegra support

On Thu, Apr 12, 2012 at 9:25 AM, Thierry Reding wrote: > * Alex Deucher wrote: >> On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding >> 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

[RFC 4/4] drm: Add NVIDIA Tegra support

On 04/12/2012 12:50 AM, Thierry Reding wrote: > * 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

[pull] drm-intel-fixes for 3.4-rc3

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

[PATCH libdrm] exynos: add exynos drm support

2012/4/12 InKi Dae : > Please, give me any comments and I hope this patch would be applied to > libdrm if there is any problem. Looks good to me. Reviewed-by: Alex Deucher If you need an fdo account, you can request one here: http://www.freedesktop.org/wiki/AccountRequests Alex > > Thanks, >

[RFC 4/4] drm: Add NVIDIA Tegra support

- 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/f028839a/attachment.pgp>

[RFC 4/4] drm: Add NVIDIA Tegra support

On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding 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 that each of them can >>

PCI resources above 4GB

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 the low system > DRAM 0xC000 obviously invalid. ?This

[Intel-gfx] [PATCH] drm/i915: clear fencing tracking state when retiring request

On Thu, Apr 12, 2012 at 12:38:09AM +0100, Chris Wilson wrote: > On Thu, 12 Apr 2012 01:27:57 +0200, Daniel Vetter > wrote: > > This fixes a regression introduce in > s/introduce/introduced/ > > > commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba > > Author: Chris Wilson > > Date: Wed Mar 21

[RFC 3/4] drm: fixed: Add dfixed_frac() macro

can do that. Though I'll have to remove the Chromium-specific tags. 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/at

[RFC 2/4] iommu: tegra/gart: Add device tree support

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/9c62bb0d/attachment-0001.pgp>

[RFC 4/4] drm: Add NVIDIA Tegra support

ds to use it. > > Instead, the active platform data should probably be stored in a > tegra_drm struct that's stored in the dev's private data. > tegra_drm_probe() might then look more like: > > struct tegra_drm *tdev; > > tdev = devm_kzalloc(); > tdev->pdata = pdev->dev.platform_data; > if (!tdev->pdata) > tdev->pdata = tegra_drm_parse_dt(); > if (!tdev->pdata) > return -EINVAL; > > dev_set_drvdata(dev, tdev); > > This is safe, since probe() will never assume that dev_get_drvdata() > might contain something valid before probe() sets it. I prefer my approach over storing the data in an extra field because the device platform_data field is where everybody would expect it. Furthermore this wouldn't be relevant if we decided not to support non-DT setups. 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/100bb9d6/attachment.pgp>

exynos broken ioctl

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; unsigned int extensions; uint64_t *edid; }; gets passed into DRM_EXYNOS_VIDI_CONNECTION ioctl. Can you

[Bug 48535] Spurious GL_INVALID_OPERATION error generated by glColor()

https://bugs.freedesktop.org/show_bug.cgi?id=48535 Alex Deucher changed: What|Removed |Added AssignedTo|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop.

[PATCH] gma500: Don't needlessly include version.h in mdfld_dsi_output.h

t attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120412/322c0391/attachment.pgp>

[PATCH 4/8 v7] drm/i915/intel_i2c: use WAIT cycle, not STOP

On Wed, Apr 11, 2012 at 5:34 AM, Chris Wilson wrote: > On Tue, 10 Apr 2012 17:03:04 +0200, Daniel Vetter wrote: >> On Tue, Apr 10, 2012 at 06:56:15PM +0800, Daniel Kurtz wrote: >> > On Tue, Apr 10, 2012 at 6:41 PM, Daniel Vetter wrote: >> > > On Tue, Apr 10, 2012 at 12:37:46PM +0200, Daniel

[PATCH 4/8 v7] drm/i915/intel_i2c: use WAIT cycle, not STOP

On Tue, Apr 10, 2012 at 11:03 PM, Daniel Vetter wrote: > On Tue, Apr 10, 2012 at 06:56:15PM +0800, Daniel Kurtz wrote: >> On Tue, Apr 10, 2012 at 6:41 PM, Daniel Vetter wrote: >> > On Tue, Apr 10, 2012 at 12:37:46PM +0200, Daniel Vetter wrote: >> >> On Fri, Mar 30, 2012 at 07:46:39PM +0800,

[PATCH] drm/i915: clear fencing tracking state when retiring requests

This fixes a regression uncovered by commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba Author: Chris Wilson Date: Wed Mar 21 10:48:18 2012 + drm/i915: Mark untiled BLT commands as fenced on gen2/3 which fixed fencing tracking for untiled blt commands. A side effect of that patch was

[PATCH] drm/i915: clear fencing tracking state when retiring request

This fixes a regression introduce in commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba Author: Chris Wilson Date: Wed Mar 21 10:48:18 2012 + drm/i915: Mark untiled BLT commands as fenced on gen2/3 which fixed fencing tracking for untiled blt commands. A side effect of that patch was

[Intel-gfx] [PATCH] drm/i915: clear fencing tracking state when retiring request

On Thu, 12 Apr 2012 01:27:57 +0200, Daniel Vetter wrote: > This fixes a regression introduce in s/introduce/introduced/ > commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba > Author: Chris Wilson > Date: Wed Mar 21 10:48:18 2012 + > > drm/i915: Mark untiled BLT commands as fenced on

[Bug 28940] rv515 (Mobility x1400) Display corruption after some time

https://bugs.freedesktop.org/show_bug.cgi?id=28940 --- Comment #6 from Michel D?nzer 2012-04-12 00:20:12 UTC --- (In reply to comment #5) > it's a very long time I'm wrestling with the very same issue with my mobility > x1400. I don't think it's the very same issue: > Option "EXAPixmaps"

No subject

No subject

No subject

[PATCH] gma500: Don't needlessly include version.h in mdfld_dsi_output.h

drivers/gpu/drm/gma500/mdfld_dsi_output.h does not need to '#include ' - so don't. Signed-off-by: Jesper Juhl --- drivers/gpu/drm/gma500/mdfld_dsi_output.h |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.h

[PATCH] gma500: Don't needlessly include version.h in mdfld_dsi_output.h

On Thu, 12 Apr 2012 00:05:29 +0200 (CEST) Jesper Juhl wrote: > drivers/gpu/drm/gma500/mdfld_dsi_output.h does not need to > '#include ' - so don't. > > Signed-off-by: Jesper Juhl Acked-by: Alan Cox

[Bug 48535] Spurious GL_INVALID_OPERATION error generated by glColor()

https://bugs.freedesktop.org/show_bug.cgi?id=48535 --- Comment #2 from Vadim 2012-04-11 16:08:59 PDT --- I guess it's a mesa core problem. Debug build of the mesa also prints the following error message when running the attached test app: "Mesa: User error: GL_INVALID_OPERATION in Inside

Re: [PATCH] gma500: Don't needlessly include version.h in mdfld_dsi_output.h

On Thu, Apr 12, 2012 at 12:05:29AM +0200, Jesper Juhl wrote: drivers/gpu/drm/gma500/mdfld_dsi_output.h does not need to '#include linux/version.h' - so don't. Signed-off-by: Jesper Juhl j...@chaosbits.net Acked-by: Kirill A. Shutemov kirill.shute...@linux.intel.com -- Kirill A. Shutemov

[git pull] updated exynos-drm-fixes

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

Re: [Intel-gfx] [PATCH] drm/i915: clear fencing tracking state when retiring request

On Thu, Apr 12, 2012 at 12:38:09AM +0100, Chris Wilson wrote: On Thu, 12 Apr 2012 01:27:57 +0200, Daniel Vetter daniel.vet...@ffwll.ch wrote: This fixes a regression introduce in s/introduce/introduced/ commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba Author: Chris Wilson

Re: [PATCH libdrm] exynos: add exynos drm support

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 inki@samsung.com님의 말: this patch adds libdrm_exynos helper layer that inclues some intefaces for exynos specific gem and virtual display

Re: [RFC 4/4] drm: Add NVIDIA Tegra support

* 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 the dma api to do that. The usual interface is dma_map_sg/dma_unmap_sg, but

[Bug 28940] rv515 (Mobility x1400) Display corruption after some time

https://bugs.freedesktop.org/show_bug.cgi?id=28940 --- Comment #6 from Michel Dänzer mic...@daenzer.net 2012-04-12 00:20:12 UTC --- (In reply to comment #5) it's a very long time I'm wrestling with the very same issue with my mobility x1400. I don't think it's the very same issue:

exynos broken ioctl

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; unsigned int extensions; uint64_t *edid; }; gets passed into DRM_EXYNOS_VIDI_CONNECTION ioctl. Can you

Re: [RFC 4/4] drm: Add NVIDIA Tegra support

* 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-video-modesetting driver. Only the RGB output

Re: [RFC 3/4] drm: fixed: Add dfixed_frac() macro

* Stephen Warren wrote: On 04/11/2012 06:10 AM, Thierry Reding wrote: This commit is taken from the Chromium tree and was originally written by Robert Morell. Maybe just cherry-pick it from there? That way, the git authorship will show up as Robert. I can do that. Though I'll have to

  1   2   >