During initialization of a drm device a struct drm_mode_group is
filled with the encoder/connector/crtc ids from the corresponding
lists, so the drm_mode_group contains the same data as already is
in the lists. Then in drm_mode_getresources either the lists or
the drm_mode_group are used. As both c
Having a 1:1 relationship between an encoder and a connector is a
very common case. This patch allows for registering a combination
of both in a single device. It should allow implementing all
necessary callbacks for both the encoder and the connector, but
most calls are optional leaving the simple
Signed-off-by: Sascha Hauer
---
arch/arm/mach-imx/pcm970-baseboard.c | 78 +-
1 file changed, 77 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/pcm970-baseboard.c
b/arch/arm/mach-imx/pcm970-baseboard.c
index 99afbc3..17758f8 100644
--- a/arch/arm/m
From: Philipp Zabel
This adds a sdrm driver for the PXA LCDC controller.
Currently only the base framebuffer is supported, no overlay.
There is no support for smart panels and so far only RGB565
pixel format is supported.
Tested on PHYTEC PCM-990 development board.
Also adds EOFINT and SOFINT bi
Hi All,
The following series adds support for a new set of drm helpers called
sdrm. It is targeted to ease the implementation of drivers for embedded
systems. The basic idea is that instead of handling a comlete drm device
in each driver we introduce helpers which take care of the drm device
and m
This patch adds support for creating simple drm devices. The
basic idea of this patch is that drm drivers using the sdrm layer
no longer have to implement a full drm device but instead only
register crtcs, encoders and connectors with the sdrm layer. The
sdrm layer then registers a drm device with
On Wed, 11 Apr 2012 08:29:22 +0200
Michel Dänzer wrote:
> On Die, 2012-04-10 at 11:34 -0700, Jesse Barnes wrote:
> > On Tue, 10 Apr 2012 20:11:29 +0200
> > Jiri Slaby wrote:
> >
> > > On 04/10/2012 06:26 PM, Jesse Barnes wrote:
> > > > So port hotplug is always reporting that port C has a hotp
https://bugs.freedesktop.org/show_bug.cgi?id=45366
--- Comment #8 from Ernst Sjöstrand 2012-04-11 09:56:11 PDT
---
(In reply to comment #6)
> I can now reproduce this consistenly I think:
> Install Ubuntu Precise
> Add xorg-edgers ppa
> Create a 2:nd user
> Log in as user 1
> Switch to user 2
>
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.
Hmm not really related but looking at it this reminds me these formats
always look a bit underspecified wrt chroma subsampl
On poniedziałek, 2 kwietnia 2012 o 21:05:23 Daniel Vetter wrote:
> On Mon, Apr 02, 2012 at 09:00:11PM +0200, Maciej Rutecki wrote:
> > On poniedziałek, 2 kwietnia 2012 o 19:54:02 Daniel Vetter wrote:
> > > On Mon, Apr 02, 2012 at 07:39:39PM +0200, Maciej Rutecki wrote:
> > > > Last known good: 3.3
On Wed, Apr 11, 2012 at 21:35, Maciej Rutecki wrote:
>> > > Patch:
>> > > http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixes
>> > > &id= 55a254ac63a3ac1867d1501030e7fba69c7d4aeb
>> > >
>> > > Please test whether this fixes your issue. You can also try adding
>> > > i915.i915_e
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
> ---
> arch/arm/boot/dts/tegra20.dtsi |6 ++
> arch/arm/mach-tegra/board-dt-tegra20.c |1 +
> dri
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.
___
dri-devel mailing li
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, Danie
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 is supported. Quite a lot
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 Vett
On Thu, Apr 12, 2012 at 02:16:45AM +0800, Daniel Kurtz wrote:
> On Tue, Apr 10, 2012 at 11:03 PM, Daniel Vetter wrote:
> > - atm the debug output is too noisy. I think we can leave the fallback to
> > gpio bitbanging at info (or maybe error) level, but all the other
> > messages should be tuned
> +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 need to call into the sdrm device specific handling.
>
On Thu, 12 Apr 2012 02:17:46 +0800, Daniel Kurtz wrote:
> On Wed, Apr 11, 2012 at 5:34 AM, Chris Wilson
> wrote:
> > The last major item on the wishlist is solving how to drive the SDVO i2c
> > over gmbus. I think it is just a matter of massaging in the channel
> > switch as msg[0].
>
> I notic
On Thu, 12 Apr 2012 02:16:45 +0800, Daniel Kurtz wrote:
> On Tue, Apr 10, 2012 at 11:03 PM, Daniel Vetter wrote:
> > - Chris Wilson suggested on irc that we should wait for HW_READY even for
> > Â zero-length writes (and also reads), currently we don't.
>
> I don't think so. We just need to wai
https://bugs.freedesktop.org/show_bug.cgi?id=28940
--- Comment #5 from Keivan 2012-04-11 14:33:36 PDT ---
it's a very long time I'm wrestling with the very same issue with my mobility
x1400. Today I found a workaround to did problem. I'm in kernel 3.2 of LMDE.
To solve this problem I forced my
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
b/drivers/gpu/drm/gma500/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
___
dri-devel mailing list
dri-devel@lists.freedesk
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 glBegin
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 th
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 th
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 ge
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 free up 0xe000 for the
> radeon, assuming the "agp_bridge" has
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... obviously limiting by the range.
>From our code:
* EDID spec
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... obviously limiting by the range.
>From our code:
* EDID spec
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... obviously limiting by the range.
>From our code:
* EDID spec
https://bugs.freedesktop.org/show_bug.cgi?id=48535
Alex Deucher changed:
What|Removed |Added
AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
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 ' - so don't.
>
> Signed-off-by: Jesper Juhl
Acked-by: Kirill A. Shutemov
--
Kirill A. Shutemov
signature.asc
Description: Digital signature
___
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
Hi Tomasz,
How about to add this program to tools directory? tools/drm or tools/media?
Thank you,
Kyungmin Park
On Wed, Apr 11, 2012 at 1:13 AM, Tomasz Stanislawski
wrote:
> Hi Everyone,
> This email contains a test application showing DMABUF sharing
> between DRM/KMS display and capture node i
On 04/10/2012 11:53 AM, Jiri Slaby wrote:
> in today's -next I see:
> BUG: unable to handle kernel NULL pointer dereference at (null)
Forget about that, it was some fuzz. I cannot reproduce with today's -next.
thanks,
--
js
___
dri-devel ma
Hi Laurent,
Thank you for review. Your comments are very helpful :).
Take a look on the comments below.
On 04/06/2012 05:02 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> On Thursday 05 April 2012 16:00:05 Tomasz Stanislawski wrote:
>> From: Andrzej Pietrasiewicz
>>
>> This patch introduces usage
On Tue, Apr 10, 2012 at 01:34:11PM -0700, Jesse Barnes wrote:
> On Tue, 10 Apr 2012 22:32:12 +0200
> Daniel Vetter wrote:
>
> > On Tue, Apr 10, 2012 at 09:52:40PM +0200, Jiri Slaby wrote:
> > > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> > > SERR- > >
> > > I tried 3.2 and
It makes no sense at all to have more than one flag.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/r100.c |1 -
drivers/gpu/drm/radeon/r300.c |1 -
drivers/gpu/drm/radeon/radeon.h|1 -
drivers/gpu/drm/radeon/radeon_device.c |1 -
drivers/gpu/
Removing all the different error messages and
having just one standard behaviour over all
chipset generations.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/evergreen.c |7 ++-
drivers/gpu/drm/radeon/ni.c |7 ++-
drivers/gpu/drm/radeon/r100.c|7
Different rings have different criteria to test
if they are stuck.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_asic.c | 36 +---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
3 files changed,
Just register the debugfs files on init instead of
checking the chipset type multiple times.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ring.c | 31 +++
1 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeon/rad
On 04/06/2012 03:29 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> On Thursday 05 April 2012 16:00:00 Tomasz Stanislawski wrote:
>> From: Sumit Semwal
>>
>> This patch adds support for DMABUF memory type in videobuf2. It calls
>> relevant APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.
>>
From: Vandana Salve
Pass the correct gart device pointer.
Reviewed-by: Vandana Salve
Tested-by: Vandana Salve
Reviewed-by: Hiroshi Doyu
Reviewed-by: Bharat Nihalani
Signed-off-by: Hiroshi DOYU
---
drivers/iommu/tegra-gart.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
This commit is taken from the Chromium tree and was originally written
by Robert Morell.
Signed-off-by: Thierry Reding
---
include/drm/drm_fixed.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h
index 4a08a66..0ead502 100644
--- a/include/
This commit adds device tree support for the GART hardware available on
NVIDIA Tegra 20 SoCs.
Signed-off-by: Thierry Reding
---
arch/arm/boot/dts/tegra20.dtsi |6 ++
arch/arm/mach-tegra/board-dt-tegra20.c |1 +
drivers/iommu/tegra-gart.c | 10 ++
3 files
This series adds a basic DRM driver for NVIDIA Tegra 2 processors. It
currently only supports the RGB output and I've successfully tested it
against the fbcon kernel module and the xf86-video-modesetting driver.
The code uses the Tegra's IOMMU/GART to remap non-contiguous memory.
This means that cu
Hi Laurent,
Thanks for review.
On 04/06/2012 05:12 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> On Thursday 05 April 2012 16:00:08 Tomasz Stanislawski wrote:
>> From: Sumit Semwal
>>
>> This patch makes changes for adding dma-contig as a dma_buf user. It
>> provides function implementations for
On Wed, 11 Apr 2012 14:10:26 +0200
Thierry Reding wrote:
> This series adds a basic DRM driver for NVIDIA Tegra 2 processors. It
> currently only supports the RGB output and I've successfully tested it
> against the fbcon kernel module and the xf86-video-modesetting driver.
> The code uses the Te
https://bugs.freedesktop.org/show_bug.cgi?id=48535
Alex Deucher changed:
What|Removed |Added
Attachment #59785|text/x-csrc |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=48535
--- Comment #1 from Alex Deucher 2012-04-11 05:43:45 PDT ---
What card and version of mesa are you using? Please attach your xorg log and
dmesg output.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
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-modesetting driver.
> Only the RGB output is supp
* 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-modesetting driver
* Hiroshi Doyu wrote:
> From: Thierry Reding
[...]
> > Thierry Reding (3):
> > iommu: tegra/gart: Add device tree support
> > drm: fixed: Add dfixed_frac() macro
> > drm: Add NVIDIA Tegra support
> >
> > Vandana Salve (1):
> > iommu: tegra/gart: use correct gart_device
>
> I guess that t
From: Thierry Reding
Subject: [RFC 0/4] Add NVIDIA Tegra DRM support
Date: Wed, 11 Apr 2012 14:10:26 +0200
Message-ID:
<1334146230-1795-1-git-send-email-thierry.red...@avionic-design.de>
> This series adds a basic DRM driver for NVIDIA Tegra 2 processors. It
> currently only supports the RGB ou
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 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
* Alan Cox wrote:
> On Wed, 11 Apr 2012 14:10:26 +0200
> Thierry Reding wrote:
>
> > This series adds a basic DRM driver for NVIDIA Tegra 2 processors. It
> > currently only supports the RGB output and I've successfully tested it
> > against the fbcon kernel module and the xf86-video-modesetting
* 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 wrote:
> > > > This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
> > > > currently has rudimentary GEM
On Wed, Apr 11, 2012 at 04:11:08PM +0200, 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 wrote:
> > > > > This commit adds a very basic D
> Hm, in that case it looks like your iommu works more like the gtt on intel
> chips
Don't overgeneralize there - on the GMA500/600 the GTT doesn't allow CPU
side access of the GTT map (ie you can't use it to linearise pages for
CPU view) and the 3600 is even stranger
Alan
__
On Wed, Apr 11, 2012 at 03:43:09PM +0100, Alan Cox wrote:
> > Hm, in that case it looks like your iommu works more like the gtt on intel
> > chips
>
> Don't overgeneralize there - on the GMA500/600 the GTT doesn't allow CPU
> side access of the GTT map (ie you can't use it to linearise pages for
> Maybe your question is answered by my reply to Alan's comment. The mapping
> is actually done to get a linear view for the display controller which
> doesn't support SG transfers. The kernel and user-space already have virtual
> linear buffers.
The framebuffer currently needs a physically contig
* Daniel Vetter wrote:
> On Wed, Apr 11, 2012 at 04:11:08PM +0200, 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 wrote:
> > > >
> Heh, vmap() is exactly what I do. =) Would you mind explaining why exactly it
> is hideous?
On x86 we don't have a vast amount of address space available for virtual
remappings and the framebuffer then eats over 8MB of it.
The ideal case is that the fb layer can be taught to do page/offset
addr
* Alan Cox wrote:
> > Maybe your question is answered by my reply to Alan's comment. The mapping
> > is actually done to get a linear view for the display controller which
> > doesn't support SG transfers. The kernel and user-space already have virtual
> > linear buffers.
>
> The framebuffer curre
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 wrote:
> > > > > This commit adds a very basic DRM driver fo
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_crtc.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index b14496e..75f66a5 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3108,6 +3108,11 @@ int
This adds a sdrm driver for the Freescale i.MX LCDC controller. It
is found on i.MX1, i.MX21, i.MX25 and i.MX27. Currently only the
base framebuffer is supported, no overlay. This has been tested
on an i.MX27 custom board with the xf86 modesetting driver.
Signed-off-by: Sascha Hauer
---
arch/arm
Hi Tomasz,
How about to add this program to tools directory? tools/drm or tools/media?
Thank you,
Kyungmin Park
On Wed, Apr 11, 2012 at 1:13 AM, Tomasz Stanislawski
wrote:
> Hi Everyone,
> This email contains a test application showing DMABUF sharing
> between DRM/KMS display and capture node i
On 04/10/2012 11:53 AM, Jiri Slaby wrote:
> in today's -next I see:
> BUG: unable to handle kernel NULL pointer dereference at (null)
Forget about that, it was some fuzz. I cannot reproduce with today's -next.
thanks,
--
js
___
dri-devel ma
Hi Laurent,
Thank you for review. Your comments are very helpful :).
Take a look on the comments below.
On 04/06/2012 05:02 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> On Thursday 05 April 2012 16:00:05 Tomasz Stanislawski wrote:
>> From: Andrzej Pietrasiewicz
>>
>> This patch introduces usage
On Tue, Apr 10, 2012 at 01:34:11PM -0700, Jesse Barnes wrote:
> On Tue, 10 Apr 2012 22:32:12 +0200
> Daniel Vetter wrote:
>
> > On Tue, Apr 10, 2012 at 09:52:40PM +0200, Jiri Slaby wrote:
> > > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> > > SERR- > >
> > > I tried 3.2 and
It makes no sense at all to have more than one flag.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/r100.c |1 -
drivers/gpu/drm/radeon/r300.c |1 -
drivers/gpu/drm/radeon/radeon.h|1 -
drivers/gpu/drm/radeon/radeon_device.c |1 -
drivers/gpu/
Removing all the different error messages and
having just one standard behaviour over all
chipset generations.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/evergreen.c |7 ++-
drivers/gpu/drm/radeon/ni.c |7 ++-
drivers/gpu/drm/radeon/r100.c|7
Different rings have different criteria to test
if they are stuck.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_asic.c | 36 +---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
3 files changed,
Just register the debugfs files on init instead of
checking the chipset type multiple times.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ring.c | 31 +++
1 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeon/rad
On 04/06/2012 03:29 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> On Thursday 05 April 2012 16:00:00 Tomasz Stanislawski wrote:
>> From: Sumit Semwal
>>
>> This patch adds support for DMABUF memory type in videobuf2. It calls
>> relevant APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.
>>
From: Vandana Salve
Pass the correct gart device pointer.
Reviewed-by: Vandana Salve
Tested-by: Vandana Salve
Reviewed-by: Hiroshi Doyu
Reviewed-by: Bharat Nihalani
Signed-off-by: Hiroshi DOYU
---
drivers/iommu/tegra-gart.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
This commit is taken from the Chromium tree and was originally written
by Robert Morell.
Signed-off-by: Thierry Reding
---
include/drm/drm_fixed.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h
index 4a08a66..0ead502 100644
--- a/include/
This commit adds device tree support for the GART hardware available on
NVIDIA Tegra 20 SoCs.
Signed-off-by: Thierry Reding
---
arch/arm/boot/dts/tegra20.dtsi |6 ++
arch/arm/mach-tegra/board-dt-tegra20.c |1 +
drivers/iommu/tegra-gart.c | 10 ++
3 files
This series adds a basic DRM driver for NVIDIA Tegra 2 processors. It
currently only supports the RGB output and I've successfully tested it
against the fbcon kernel module and the xf86-video-modesetting driver.
The code uses the Tegra's IOMMU/GART to remap non-contiguous memory.
This means that cu
Hi Laurent,
Thanks for review.
On 04/06/2012 05:12 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> On Thursday 05 April 2012 16:00:08 Tomasz Stanislawski wrote:
>> From: Sumit Semwal
>>
>> This patch makes changes for adding dma-contig as a dma_buf user. It
>> provides function implementations for
On Wed, 11 Apr 2012 14:10:26 +0200
Thierry Reding wrote:
> This series adds a basic DRM driver for NVIDIA Tegra 2 processors. It
> currently only supports the RGB output and I've successfully tested it
> against the fbcon kernel module and the xf86-video-modesetting driver.
> The code uses the Te
https://bugs.freedesktop.org/show_bug.cgi?id=48535
Alex Deucher changed:
What|Removed |Added
Attachment #59785|text/x-csrc |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=48535
--- Comment #1 from Alex Deucher 2012-04-11 05:43:45 PDT ---
What card and version of mesa are you using? Please attach your xorg log and
dmesg output.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
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-modesetting driver.
> Only the RGB output is supp
* 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-modesetting driver
* Hiroshi Doyu wrote:
> From: Thierry Reding
[...]
> > Thierry Reding (3):
> > iommu: tegra/gart: Add device tree support
> > drm: fixed: Add dfixed_frac() macro
> > drm: Add NVIDIA Tegra support
> >
> > Vandana Salve (1):
> > iommu: tegra/gart: use correct gart_device
>
> I guess that t
From: Thierry Reding
Subject: [RFC 0/4] Add NVIDIA Tegra DRM support
Date: Wed, 11 Apr 2012 14:10:26 +0200
Message-ID:
<1334146230-1795-1-git-send-email-thierry.red...@avionic-design.de>
> This series adds a basic DRM driver for NVIDIA Tegra 2 processors. It
> currently only supports the RGB ou
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 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
* Alan Cox wrote:
> On Wed, 11 Apr 2012 14:10:26 +0200
> Thierry Reding wrote:
>
> > This series adds a basic DRM driver for NVIDIA Tegra 2 processors. It
> > currently only supports the RGB output and I've successfully tested it
> > against the fbcon kernel module and the xf86-video-modesetting
* 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 wrote:
> > > > This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
> > > > currently has rudimentary GEM
On Wed, Apr 11, 2012 at 04:11:08PM +0200, 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 wrote:
> > > > > This commit adds a very basic D
> Hm, in that case it looks like your iommu works more like the gtt on intel
> chips
Don't overgeneralize there - on the GMA500/600 the GTT doesn't allow CPU
side access of the GTT map (ie you can't use it to linearise pages for
CPU view) and the 3600 is even stranger
Alan
__
On Wed, Apr 11, 2012 at 03:43:09PM +0100, Alan Cox wrote:
> > Hm, in that case it looks like your iommu works more like the gtt on intel
> > chips
>
> Don't overgeneralize there - on the GMA500/600 the GTT doesn't allow CPU
> side access of the GTT map (ie you can't use it to linearise pages for
> Maybe your question is answered by my reply to Alan's comment. The mapping
> is actually done to get a linear view for the display controller which
> doesn't support SG transfers. The kernel and user-space already have virtual
> linear buffers.
The framebuffer currently needs a physically contig
* Daniel Vetter wrote:
> On Wed, Apr 11, 2012 at 04:11:08PM +0200, 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 wrote:
> > > >
> Heh, vmap() is exactly what I do. =) Would you mind explaining why exactly it
> is hideous?
On x86 we don't have a vast amount of address space available for virtual
remappings and the framebuffer then eats over 8MB of it.
The ideal case is that the fb layer can be taught to do page/offset
addr
* Alan Cox wrote:
> > Maybe your question is answered by my reply to Alan's comment. The mapping
> > is actually done to get a linear view for the display controller which
> > doesn't support SG transfers. The kernel and user-space already have virtual
> > linear buffers.
>
> The framebuffer curre
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 wrote:
> > > > > This commit adds a very basic DRM driver fo
1 - 100 of 408 matches
Mail list logo
