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 10
Please, give me any comments and I hope this patch would be applied to
libdrm if there is any problem.
Thanks,
Inki Dae.
2012년 4월 2일 오후 9:08, Inki Dae 님의 말:
> this patch adds libdrm_exynos helper layer that inclues some intefaces
> for exynos specific gem and virtual display driver and also adds
* 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
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"
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
* 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 RG
* 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
* 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
> > ---
> > arch/arm/boot/dts/tegra20.dtsi |6 ++
> > arch/arm/mach-
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 fenci
Oh, I am sorry. I fixed it and now you can pull.
Thanks,
Inki Dae.
2012년 4월 12일 오후 4:20, Dave Airlie 님의 말:
> please before submitting ioctl's can someone review them to make sure
> they have no pointers in them ever.
>
> struct drm_exynos_vidi_connection {
>unsigned int connection;
>
On 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;
> >
Forwarding the pull request to Dave to intel-gfx and dri-devel, I've
fumbled the cc list on the original mail.
-Daniel
-- Forwarded message --
From: Daniel Vetter
Date: Thu, Apr 12, 2012 at 11:17
Subject: [pull] drm-intel-next for 3.5
To: Dave Airlie
Hi Dave
First pull request
On Wed, Apr 11, 2012 at 12:12:14PM -0600, Stephen Warren wrote:
> On 04/11/2012 06:10 AM, Thierry Reding wrote:
> > This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
> > currently has rudimentary GEM support and can run a console on the
> > framebuffer as well as X using the xf86-v
* 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 looke
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
https://bugs.freedesktop.org/show_bug.cgi?id=48599
Bug #: 48599
Summary: Fix compiler warnings in tests/radeon/radeon_ttm.c
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: Other
OS/Version: All
St
On Thu, 12 Apr 2012, 01:57:17 BST, Yinghai Lu wrote:
> On Tue, Apr 10, 2012 at 2:19 PM, Steven Newbury
> wrote:
> > Another thought, normally the integrated graphics has an "AGP"
> > aperture of 256M @0xe000, which is detected by agpgart-intel, this
> > will need to be moved up above 4G to f
On Wed, Apr 11, 2012 at 08:53:08PM +0200, Roland Scheidegger wrote:
> Am 05.04.2012 20:35, schrieb ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä
> >
> > These functions return the chroma subsampling factors for the specified
> > pixel format.
> Hmm not really related but looking at it th
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
>>
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,
>
* 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 accelerated video
> > decoding blocks) but display that framebuffer with a CRTC
* 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.
* Marek Szyprowski wrote:
> Hi Thierry,
>
> On Thursday, April 12, 2012 9:18 AM 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 smalle
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
Hi Arnd,
On Thursday, April 12, 2012 1:18 PM Arnd Bergmann wrote:
> On Thursday 12 April 2012, Marek Szyprowski wrote:
> > Scatter lists were initially designed for the disk based block io
> > operations,
> > hence the presence of the in-page offsets and lengths for each chunk. For
> > multimedi
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 accelerated
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
>>> >
On Thu, Apr 12, 2012 at 11:18:19AM +, Arnd Bergmann wrote:
> On Thursday 12 April 2012, Marek Szyprowski wrote:
> > Scatter lists were initially designed for the disk based block io
> > operations,
> > hence the presence of the in-page offsets and lengths for each chunk. For
> > multimedia u
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 +
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
>
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 t
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... o
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 conflic
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 me
* Alex Deucher wrote:
> On Thu, Apr 12, 2012 at 10:09 AM, Alex Deucher 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 understand
At Wed, 11 Apr 2012 21:59:28 -0300,
Rodrigo Vivi wrote:
>
> There are many bugs open on fd.o regarding missing modes that are supported
> on Windows and other closed source drivers.
> >From EDID spec we can (might?) infer modes using GTF and CVT when monitor
> >allows it trough range limited fla
On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu wrote:
> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury
> wrote:
> > Thanks, that fixed it! :) I had a similar patch I've been working on
> > but I had my fix in the wrong place!
> >
> > In the working case, initially the BIOS has set GMA to within
Hi Linus,
mostly exynos and intel,
intel has 3 regression fixers (more info in intel merge commit), along
with some other make hw work fixes,
exynos has some cleanups and an ioctl fix
couple of radeon fixes, couple of build fixes, and a savage userspace
interface possible overflow fix.
Dave.
* 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 t
On Mon, Apr 2, 2012 at 7:08 AM, Inki Dae wrote:
> this patch adds libdrm_exynos helper layer that inclues some intefaces
> for exynos specific gem and virtual display driver and also adds exynos
> module name to modtest and vbltest.
>
> this patch is based on a link below:
> git://anongit.f
The following set of patches is the reword of the series
sent two weeks ago [2] that will revive the drm-render-nodes [1]
branch. Details of the original series are described in [2].
Patches in this series have been reworked (and a few prep patches
have been added) to address the comment about the
file_priv->master->minor is equivalent to file_priv->minor
http://lists.freedesktop.org/archives/dri-devel/2011-October/015511.html
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_crt
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 +
drm_mode_group structure now tracks planes, so use it in
in drm_mode_getplane_res(ources) IOCTL.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc.c | 46 +--
1 files changed, 35 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_crt
Push minor number instead. This is a preparatory
patch for introducing render nodes. It has been derived
from 7c5cc4f63556e351e9e5980ed22accad410e3fdc originally
created by Dave Airlie.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_fops.c | 19 ++-
1 files changed, 10 ins
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.
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 +++
From: Dave Airlie
just adds some unchecked ioctls to setup the nodes.
Signed-off-by: Dave Airlie
v2: - original ioctl numbers are now taken, use next available
- resolve some trivial conflicts due to bit-rot that
occurred since the original patch was created
v3: - added planes to AB
drm_minor structure had a list_head pointer that was
used only for render nodes. control and primary nodes
do not live in the list and had this list pointer unused.
Create a separate drm_render_node structure that is used
to build the render node list and that points to the
coresponding minor. Thi
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 +++-
The render-node manipulation ioctls are supposed to be
issued through control node only. Add a check and return
-EPERM to user space if access is attempted through a
node other than a control node.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_stub.c |8
1 files changed, 8 ins
When a new render node is created, the number of elements
of id_list allocated in drm_mode_group_init function should
not be the sum of all CRTCs, encoders, and connectors that
the device has, but the one specified by the ioctl that
created the node.
v2: - add planes
Signed-off-by: Ilija Hadzic
Keep track of per-node open count and do not allow removal
of a render node in use.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_fops.c |2 ++
drivers/gpu/drm/drm_stub.c |2 ++
include/drm/drmP.h |1 +
3 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/driv
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(+),
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
In drm_put_dev, the whole device is being destroyed, so id_list
of the primary (legacy) node should also be cleaned up.
This plugs a memory leak that has probably existed even without
the render-node work.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_stub.c |1 +
1 files changed, 1 in
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
Render node ioctl requires a list of DRM mode objects
in specific order: first all CRTCs, then all encoders,
followed by all connectors. Check that the IDs passed
from userland are in conformance with this requirement
and that they are consistent with specified num_crtc,
num_encoder and num_connect
Add fields to drm_crtc, drm_encoder, drm_connector, and drm_plane
that keep track of which render node owns it. Assign ownership
when resource is added and revoke it when resource is destroyed.
Do not allow creation of a node that tries to claim resources
that are already in use by another node.
v
Critical sections are parts of the code where we claim or
release resources (we don't want two render-node create or
remove ioctl called in the context of different processes
to claim part of requested resources because of the race).
Another critical section is manipulating the render node
list. We
The following two patches are the rework of the patch series sent two weeks
ago [1] that add libdrm support for render node manipulation. All notes
described in [1] apply. A new option to render_node_add utility has
been added to specify the number of planes and plane IDs are supposed to
be the las
Implement the user-space side of drm_render_node_create
and drm_render_node_remove ioctls. The new functions
are drmCreateRenderNode and drmRemoveRenderNode.
v2: - add planes
Signed-off-by: Ilija Hadzic
---
include/drm/drm.h |2 +
include/drm/drm_mode.h | 17 ++
xf86drm.c
Add two simple programs (render_node_add and render_node_rm)
that can be used to add and remove render nodes from a shell
command or a script.
v2: - add planes
Signed-off-by: Ilija Hadzic
---
.gitignore |2 +
configure.ac |1 +
tests/Mak
On Thu, Apr 12, 2012 at 02:19:25PM -0400, Ilija Hadzic wrote:
> The following set of patches is the reword of the series
> sent two weeks ago [2] that will revive the drm-render-nodes [1]
> branch. Details of the original series are described in [2].
>
> Patches in this series have been reworked (
On Thu, 12 Apr 2012, Ville [iso-8859-1] Syrjälä wrote:
Didn't have time for a detailed look yet, but at least one thing
missing from your patch set is handling of possible_crtcs and
possible_clones for getplane and getencoder ioctls.
Yes I agree and I know. That is still work in progress. Th
From: Alex Deucher
Forget to unreserve after pinning. This can lead to problems in
soft reset and resume.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/si.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon
These should have been there since day one.
This series cleans up the few places that touch the DMT list to handle rb
modes correctly, and then imports the modes from xserver's list, along with
a few cosmetic changes.
- ajax
___
dri-devel mailing list
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
@@
No functional change, but will make an upcoming change clearer.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 79a3637..0a23ee5 10
It won't find any, yet. Fix up callers to match: standard mode codes
will look prefer r-b modes for a given size if present, EST3 mode codes
will look for exactly the r-b-ness mentioned in the mode code. This
might mean fewer modes matched for EST3 mode codes between now and when
the DMT mode lis
Slightly more honest naming.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4f52103..83c51d6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers
Require that the monitor support rb for rb modes to be added.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 83c51d6..0fc63ca 100644
--- a/dri
Copied from the list in xserver.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h | 94 +-
1 files changed, 93 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index a91ffb1..4be9
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index 4be9c1a..ab3a051 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers
The refactoring of the nv50 logic, introduced in 8663bc7c, modified the
test for the special lane map used on some Apple computers with Nvidia
chipsets. The tested MBA3,1 would still boot, but resume from suspend
stopped working. This patch restores the old test, which fixes the problem.
Signed-of
Hi Ajax and Takashi,
Thanks for your comments.
> The intent here is great, but I don't like the way this is phrased, or
> the implementation.
To be honest I don't like this implementation as well. I just tried to
follow the way it wasa already there.
> CVT monitors _must_ accept GTF as well, ED
Am Mittwoch, den 11.04.2012, 15:18 + schrieb Arnd Bergmann:
> On Wednesday 11 April 2012, Thierry Reding wrote:
> > * Daniel Vetter wrote:
> > > On Wed, Apr 11, 2012 at 03:23:26PM +0200, Thierry Reding wrote:
> > > > * Daniel Vetter wrote:
> > > > > On Wed, Apr 11, 2012 at 02:10:30PM +0200, T
Am 12.04.2012 14:23, schrieb Ville Syrjälä:
> On Wed, Apr 11, 2012 at 08:53:08PM +0200, Roland Scheidegger wrote:
>> Am 05.04.2012 20:35, schrieb ville.syrj...@linux.intel.com:
>>> From: Ville Syrjälä
>>>
>>> These functions return the chroma subsampling factors for the specified
>>> pixel format.
On 04/11/2012 05:48 AM, Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote:
This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
currently has rudimentary GEM support and can run a console on the
framebuffer as well as X using the xf86-video-modese
On 04/12/2012 11:44 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 04/12/2012 12:50 AM, Thierry Reding wrote:
>>> drm {
>>> compatible = "nvidia,tegra20-drm";
>>
>> I'm don't think having an explicit "drm" node is the right approach; drm
>> is after all a SW term and the
On 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 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 Vet
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
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 gen
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.
-
A non-text 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>
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: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 10
Please, give me any comments and I hope this patch would be applied to
libdrm if there is any problem.
Thanks,
Inki Dae.
2012? 4? 2? ?? 9:08, Inki Dae ?? ?:
> this patch adds libdrm_exynos helper layer that inclues some intefaces
> for exynos specific gem and virtual display driver and also adds
and dig
in some more.
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/f028839a/attachment.pgp>
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"
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
zeroed in case drm_platform_init() fails as well.
> * Module is re-inserted, finds that dev->platform_data!=NULL and
> proceeds 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>
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-dev
rt --
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/9c62bb0d/attachment-0001.pgp>
1 - 100 of 169 matches
Mail list logo
