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
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
___
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
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
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
There are many bugs open on fd.o regarding missing modes that are supported on
Windows and other closed source drivers.
There are many bugs open on fd.o regarding missing modes that are supported on
Windows and other closed source drivers.
There are many bugs open on fd.o regarding missing modes that are supported on
Windows and other closed source drivers.
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_
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
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
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 wa
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 noti
> +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.
>
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 this reminds me these formats
always look a bit underspecified wrt chroma subsa
https://bugs.freedesktop.org/show_bug.cgi?id=48535
Alex Deucher changed:
What|Removed |Added
AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
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
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
;t initialised.
Attached patch should fix that high 32bit missing problem.
Yinghai
-- next part --
A non-text attachment was scrubbed...
Name: fix_i915_gma_bus_addr.patch
Type: application/octet-stream
Size: 1216 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120411/ed617df8/attachment.obj>
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
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
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
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
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
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
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
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
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
actly it
is hideous?
I'll have to investigate what an appropriate alternative would look like.
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.f
will end up in some layering fun together with
> dma_buf, which conceptually is at the same level as the dma api, which
> usually uses an underlying iommu exposed with the iommu api you're using.
That's odd. The only users of the IOMMU API that I can find in the kernel
tree are in drivers/remoteproc and drivers/media/video/omap3isp. And omap3isp
doesn't do any actual mapping at a quick glance. Can you point me to where
this is hooked up with the Intel IOMMU?
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/20120411/88505271/attachment.pgp>
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
>
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
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 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
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
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
> 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
-- 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/20120411/c56ee96f/attachment.pgp>
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
> 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
> 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
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/drm_edid.c | 37 +-
drivers/gpu/drm/drm_edid_modes.h | 101 ++
2 files changed, 136 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7e
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/drm_edid.c | 37 +-
drivers/gpu/drm/drm_edid_modes.h | 101 ++
2 files changed, 136 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7e
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/drm_edid.c | 37 +-
drivers/gpu/drm/drm_edid_modes.h | 101 ++
2 files changed, 136 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7e
e any
documentation for either the 2D nor 3D engines. Eventually a better option
might be to use stolen memory instead of remapping it through the GART.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
S
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
arately so they can be applied
independently. Should they go in via the IOMMU tree or the Tegra
tree?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://list
ilable
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120411/9e5df990/attachment.pgp>
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
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
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 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
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.reding at avionic-design.de>
> This series adds a basic DRM driver for NVIDIA Tegra 2 processors. It
> currently only supports the RGB
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
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
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 of things still need
to be worked out and there is a
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
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 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
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.
>>
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
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 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
> +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, 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
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 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 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 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 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
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
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
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/
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,
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
https://bugs.freedesktop.org/show_bug.cgi?id=48535
Alex Deucher changed:
What|Removed |Added
Attachment #59785|text/x-csrc |text/plain
mime type|
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 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
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 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
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
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 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.
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
Hi Everyone,
I am referring to this line in drm_drv.c in drm module:
DRM_IOCTL_DEF(DRM_IOCTL_DROP_MASTER, drm_dropmaster_ioctl, DRM_ROOT_ONLY)
I can understand that set_master requires root, but if the process is
already master and just want to drop itself from master, I don't see any
point wh
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
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
>
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
hat looks right, you still get 0x300?
>
> You said 'If you write 0x3 back' above, but this code writes 0x300.
> Which is right?
0x300 is right, the bits are status bits with write 1 to clear
semantics. But it looks like this one is just stuck high (probably
because port C isn't ac
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
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
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
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
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
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
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
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
1 - 100 of 135 matches
Mail list logo
