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
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,
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>
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.
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
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>
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
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
+++
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
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
---
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
+++
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
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
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
@@
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
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
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 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
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
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
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
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
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>
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
-devel/attachments/20120412/3b69494d/attachment.pgp>
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
> >
lication/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120412/e80e3833/attachment-0001.pgp>
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
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 +
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 ++
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
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.
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.
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
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
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
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
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(+),
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
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
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
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.
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:
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
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.
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
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
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
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
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
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
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:
> ? ? ?
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
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
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
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
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>
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
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
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
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;
>
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 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
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 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
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
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
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,
>
-
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>
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
>>
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
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
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
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>
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>
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
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.
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>
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
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,
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
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
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
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"
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
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
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
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
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
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
* 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
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:
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
* 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
* 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 - 100 of 158 matches
Mail list logo