On 11/19/2012 04:33 PM, Maarten Lankhorst wrote:
Op 19-11-12 16:04, Thomas Hellstrom schreef:
On 11/19/2012 03:17 PM, Thomas Hellstrom wrote:
Hi,
This patch looks mostly good, although I think ttm_bo_cleanup_refs becomes
overly complicated:
Could this do, or am I missing something?
Actually
On 11/19/2012 03:10 PM, Maarten Lankhorst wrote:
Op 19-11-12 14:33, Thomas Hellstrom schreef:
On 11/12/2012 03:00 PM, Maarten Lankhorst wrote:
Just use the return error from ttm_mem_evict_first instead.
Here driver need to be able to evict a memory type completely, because they
might shut dow
All right. I guess you might already have this, just sent this to make
things clear.
On 11/20/2012 03:37 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Nov 20, 2012 at 03:26:16PM +0800, Mark Zhang wrote:
>> This patch is based on Thierry's drm patch for Tegra20:
>> - [PATC
On Tue, Nov 20, 2012 at 03:26:16PM +0800, Mark Zhang wrote:
> This patch is based on Thierry's drm patch for Tegra20:
> - [PATCH v2 0/6] Device tree updates for host1x support
> - [PATCH v3 0/2] NVIDIA Tegra DRM driver
>
> It adds the support for NVIDIA Tegra30.
>
> Signed-off-by: Mark Zhang
Hi
Hi Dave,
This patch set adds iommu support, userptr feature to g2d, minor fixups
and code cleanups.
And the iommu feature has dependency of the below patches related to
dma mapping framework.
For this, ccing DMA Mapping framework maintainer, Marek Szyprowski.
Marek, please give me ack.
comm
Stephen & Thierry,
I downloaded all patches from patchwork so right now it should not have
space issues.
Mark
On 11/20/2012 03:26 PM, Mark Zhang wrote:
> This patch is based on Thierry's drm patch for Tegra20:
> - [PATCH v2 0/6] Device tree updates for host1x support
> - [PATCH v3 0/2] NVIDIA Teg
core/device.h was included twice.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/nouveau/core/subdev/device/base.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/device/base.c
b/drivers/gpu/drm/nouveau/core/subdev/device/base.c
inde
nouveau_ttm.h was included twice.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/nouveau/nouveau_drm.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 0910125..a1e3fed 100644
--- a/dri
CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.
Signed-off-by: Bill Pemberton
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/shmob
CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.
Signed-off-by: Bill Pemberton
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +-
drivers/gpu/drm/exynos/exynos_dr
255:
-
Tested. It fixes the last reported problem. Only enabled crtc are restored.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20
CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.
Signed-off-by: Bill Pemberton
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/ast/ast_drv.c| 2 +-
drivers/gpu/drm/cirrus/cirrus_drv.c | 2 +-
drivers/gpu/drm/exynos/exynos_dr
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: Bill Pemberton
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/d
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: Bill Pemberton
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/exynos/exynos_ddc.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
drivers/gpu/drm/exynos/exynos_
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: Bill Pemberton
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/shm
This patch is based on Thierry's drm patch for Tegra20:
- [PATCH v2 0/6] Device tree updates for host1x support
- [PATCH v3 0/2] NVIDIA Tegra DRM driver
It adds the support for NVIDIA Tegra30.
Signed-off-by: Mark Zhang
---
drivers/gpu/drm/tegra/dc.c |1 +
drivers/gpu/drm/tegra/host1x.c
On 11/20/2012 07:19 AM, Dave Airlie wrote:
On Tue, Nov 6, 2012 at 9:31 PM, Thomas Hellstrom wrote:
The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during normal operation.
Since
On 11/20/12, Prathyush K wrote:
> On Mon, Nov 19, 2012 at 3:14 PM, Kyungmin Park
> wrote:
>
>> Hi,
>>
>> On 11/15/12, Prathyush K wrote:
>> > The 'pages' structure is not required since we can use the 'sgt'. Even
>> for
>> > CONTIG buffers, a SGT is created (which will have just one sgl). This
>
On Mon, Nov 19, 2012 at 3:14 PM, Kyungmin Park wrote:
> Hi,
>
> On 11/15/12, Prathyush K wrote:
> > The 'pages' structure is not required since we can use the 'sgt'. Even
> for
> > CONTIG buffers, a SGT is created (which will have just one sgl). This SGT
> > can be used during mmap instead of 'p
On Tue, Nov 6, 2012 at 9:31 PM, Thomas Hellstrom wrote:
> The mostly used lookup+get put+potential_destroy path of TTM objects
> is converted to use RCU locks. This will substantially decrease the amount
> of locked bus cycles during normal operation.
> Since we use kfree_rcu to free the objects,
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #40 from Alexandre Demers ---
In evergreen_reg.h, /* CRTC blocks at 0x6df0, 0x79f0, 0x105f0, 0x111f0,
0x11df0, 0x129f0 */ is not used to define the registers following this comment
it. It seems to correspond to display controller offs
d...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121119/9bae06a4/attachment.html>
The Intel 82855PM host bridge / Mobility FireGL 9000 RV250 combination
in an (outdated) ThinkPad T41 needs AGPMode 1 for suspend/resume (under
KMS, that is). So add a quirk for it.
(Change R250 to RV250 in comment for preceding quirk too.)
Signed-off-by: Paul Bolle
---
0) Last tested on v3.6.7.
Could you please re-send this patch updating like below?
For example,
[PATCH ] drm/exynos: fix memory leak to edid
some comments.
Thanks,
Inki Dae
2012/11/20 Egbert Eich
> Signed-off-by: Egbert Eich
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c |1 +
> 1 files changed, 1 insertions(+),
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121119/3b29156e/attachment.html>
Applied.
Thanks,
Inki Dae
> -Original Message-
> From: Sachin Kamat [mailto:sachin.kamat at linaro.org]
> Sent: Monday, November 19, 2012 6:53 PM
> To: dri-devel at lists.freedesktop.org
> Cc: inki.dae at samsung.com; jy0922.shim at samsung.com;
sachin.kamat at linaro.org;
> patches at li
> -Original Message-
> From: Sachin Kamat [mailto:sachin.kamat at linaro.org]
> Sent: Monday, November 19, 2012 6:56 PM
> To: Inki Dae
> Cc: dri-devel at lists.freedesktop.org; jy0922.shim at samsung.com;
> patches at linaro.org
> Subject: Re: [PATCH 1/1] drm/exynos: Fix potential NULL po
Hi,
On 11/19/12, Prathyush K wrote:
> Changelog v3:
>
> Passing the actual buffer size instead of vm_size to dma_mmap_attrs.
>
> Changelog v2:
>
> Extracting the private data from fb_info structure to obtain the exynos
> gem buffer structure. Now, dma address is obtained from the exynos gem
> buf
Please, combine these patches.
Thanks,
Inki Dae
> -Original Message-
> From: Sachin Kamat [mailto:sachin.kamat at linaro.org]
> Sent: Monday, November 19, 2012 5:38 PM
> To: dri-devel at lists.freedesktop.org
> Cc: inki.dae at samsung.com; jy0922.shim at samsung.com;
sachin.kamat at linar
> -Original Message-
> From: Sachin Kamat [mailto:sachin.kamat at linaro.org]
> Sent: Monday, November 19, 2012 6:21 PM
> To: dri-devel at lists.freedesktop.org
> Cc: inki.dae at samsung.com; jy0922.shim at samsung.com;
sachin.kamat at linaro.org;
> patches at linaro.org
> Subject: [PATCH
Hi,
On 11/15/12, Prathyush K wrote:
> The 'pages' structure is not required since we can use the 'sgt'. Even for
> CONTIG buffers, a SGT is created (which will have just one sgl). This SGT
> can be used during mmap instead of 'pages'. The 'page_size' element of the
> structure is also not used an
On Fri, Nov 16, 2012 at 02:40:09PM -0300, Tomas M wrote:
> I sent this to the lkml but i got no reply. maybe im missing something
> obvious? my report lacks information? or this list is the apropiate
> place to send ;)
I tend to not read lkml, too much stuff there ;-) Anyway, please boot with
drm.
Hi Dave,
This pull request fixes minor issues and includes code cleanup.
If there is any problem, please let me know.
Thanks,
Inki Dae
The following changes since commit 6f755116c93ca35f496ccf1910dcd28cd16713e3:
Merge branch 'drm-intel-fixes' of
git://people.freedesktop.org/~danvet/drm-inte
2012/11/19 Kyungmin Park
> Hi,
>
> On 11/19/12, Prathyush K wrote:
> > Changelog v3:
> >
> > Passing the actual buffer size instead of vm_size to dma_mmap_attrs.
> >
> > Changelog v2:
> >
> > Extracting the private data from fb_info structure to obtain the exynos
> > gem buffer structure. Now, d
uf exported from out own gem
> increases
> +* refcount on gem itself instead of f_count of
> dmabuf.
> +*/
> drm_gem_object_reference(obj);
> + dma_buf_put(buffer);
> return obj;
> }
> }
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121119/0573a19d/attachment.html>
On Mon, Nov 19, 2012 at 02:48:06PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 19, 2012 at 04:32:36PM +0200, Ville Syrj?l? wrote:
> > On Thu, Nov 15, 2012 at 02:39:41PM +, Arnd Bergmann wrote:
> > > On Thursday 15 November 2012, Rob Clark wrote:
> > > > > I still haven't heard a conclu
Hi Maarten,
On 2012년 11월 19일 19:27, Maarten Lankhorst wrote:
> Op 15-11-12 04:52, Seung-Woo Kim schreef:
>> Increasing ref counts of both dma-buf and gem for imported dma-buf
>> come from gem makes memory leak. release function of dma-buf cannot
>> be called because f_count of dma-buf increased by
Op 19-11-12 16:04, Thomas Hellstrom schreef:
> On 11/19/2012 03:17 PM, Thomas Hellstrom wrote:
>> Hi,
>>
>> This patch looks mostly good, although I think ttm_bo_cleanup_refs becomes
>> overly complicated:
>> Could this do, or am I missing something?
>>
>
> Actually, my version is bad, because ttm
On Thu, Nov 15, 2012 at 02:39:41PM +, Arnd Bergmann wrote:
> On Thursday 15 November 2012, Rob Clark wrote:
> > > I still haven't heard a conclusive argument why we need to use get_user()
> > > rather than copy_from_user() in the DRM code. Is this about a fast path
> > > where you want to shave
;
reassigning.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121119/dae9f0cf/attachment.html>
On 11/19/2012 03:17 PM, Thomas Hellstrom wrote:
> Hi,
>
> This patch looks mostly good, although I think ttm_bo_cleanup_refs
> becomes overly complicated:
> Could this do, or am I missing something?
>
Actually, my version is bad, because ttm_bo_wait() is called with the
lru lock held.
/Thomas
On 19 November 2012 15:30, Inki Dae wrote:
>
>
>> -Original Message-
>> From: Sachin Kamat [mailto:sachin.kamat at linaro.org]
>> Sent: Monday, November 19, 2012 6:56 PM
>> To: Inki Dae
>> Cc: dri-devel at lists.freedesktop.org; jy0922.shim at samsung.com;
>> patches at linaro.org
>> Subje
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #39 from Alexandre Demers ---
Comment on attachment 70255
--> https://bugs.freedesktop.org/attachment.cgi?id=70255
fix save for real
Review of attachment 70255:
-
Tes
On 19 November 2012 15:15, Inki Dae wrote:
> Please, combine these patches.
OK. I will re-send.
>
> Thanks,
> Inki Dae
>
>> -Original Message-
>> From: Sachin Kamat [mailto:sachin.kamat at linaro.org]
>> Sent: Monday, November 19, 2012 5:38 PM
>> To: dri-devel at lists.freedesktop.org
>>
Hi Inki,
Thanks for your review. My comments inline.
On 19 November 2012 15:14, Inki Dae wrote:
>
>
>> -Original Message-
>> From: Sachin Kamat [mailto:sachin.kamat at linaro.org]
>> Sent: Monday, November 19, 2012 6:21 PM
>> To: dri-devel at lists.freedesktop.org
>> Cc: inki.dae at sams
Signed-off-by: Egbert Eich
---
include/drm/drm_crtc.h |8
include/drm/drm_edid.h |9 +
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 171aa33..06254bc 100644
--- a/include/drm/drm_crtc.h
+++ b/include/d
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/mgag200/mgag200_mode.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index d3d99a2..f89a0c1 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/gma500/cdv_intel_dp.c|1 +
drivers/gpu/drm/gma500/oaktrail_lvds.c |1 +
drivers/gpu/drm/gma500/psb_intel_modes.c |1 +
3 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c
b/drivers/g
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/ast/ast_mode.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 7fc9f72..c27aa8d 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_m
So far it was only possible to load an EDID for a single connector (unless
no connector was specified at all in which case the same EDID file was used
for all).
This patch extends the EDID loader so that EDID files can be specified for
more than one connector. A semicolon is used to separate the di
Consolidate the null_edid_counter and the bad_edid_counter
into EDID error state flags which for the last EDID read
are accessible from user.
Errors are looged it the same error has not been present
in the previous read of the EDID. This will reset the
EDID error status for example when the monitor
There is no point to call krealloc() to shrink the amount of
memory for EDID blocks: the implementation of krealloc() will
ignore the size change and return the same chunk of memory
anyway.
So far we failed reading EDIDs when krealloc() failed.
This may happen if the size required to store an EDID
According the the VESA specs there can be up to 254 EEDID extension blocks.
Since we may read the EDID (including extensions) in 10 second intervals to
probe for display hotplugging (at least in cases where no hardware hotplug
detection exists) and I2C transfer is rather slow we may end up consumin
Firmware supplied EDIDs where fed in in
drm_helper_probe_single_connector_modes()
in place of calling the driver supplied get_modes() function.
This has two problems:
1. Drivers don't call drm_get_edid() only from within get_modes().
2. The get_modes() replacement in drm_load_edid_firmware() provi
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/drm_edid.c | 77 ---
drivers/gpu/drm/drm_edid_load.c | 54 ++-
include/drm/drm_edid.h |1 +
3 files changed, 77 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu
EDIDs are an integral concept of connectors, connectors are a concept
of drm core also drm_edid.o is already part of this drm core.
Overridden, 'firmware-supplied' EDIDs should be treated exactly the
same as device supplied ones.
Therefore move drm_edid_load from the helper level to the drm core.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/exynos/exynos_hdmi.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2c115f8..bc87bca 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/
EEDID v1.3 mandates map blocks if more than one EDID extension block
is used while in v1.4 they are optional.
If the extension count has been changed (because some extension
blocks were not readable) those map blocks need fixing.
In case of v1.4 or higher we simply eliminate all map blocks as
this
There are displays which announce EDID extension blocks in the
Extension Flag of the EDID base block although they are not EDDC
capable (ie. take a segment address at I2C slave address 0x30).
We test this by looking for an EDID header which is only possible
in the base block.
If the segment address
If I2C readout fails for an extension block but we have read a
valid base block, don't fail completely but at least return the
base block.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/drm_edid.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_
This patch is a bit cosmetic as the variable size will truncate
the start address anyway but for readability it should be made
explicite that the lowest bit in the EDID block number determines
the I2C start address.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/drm_edid.c |2 +-
1 files cha
This patchset fixes issues about EDID and EDID Extension block handling:
1. We currently don't return any EDID information if there are issues with
reading extension blocks. There are devices however which announce to
have EDID extension blocks although these are not readable.
If reading
Fixes the following sparse warnings:
drivers/gpu/drm/exynos/exynos_drm_fimd.c:65:25: warning:
symbol 'exynos4_fimd_driver_data' was not declared. Should it be static?
drivers/gpu/drm/exynos/exynos_drm_fimd.c:69:25: warning:
symbol 'exynos5_fimd_driver_data' was not declared. Should it be static?
S
Hi,
This patch looks mostly good, although I think ttm_bo_cleanup_refs
becomes overly complicated:
Could this do, or am I missing something?
static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
bool interruptible,
bool no_wait_reserve,
On 11/19/2012 02:45 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Mon, Nov 19, 2012 at 02:18:51PM +0800, Mark Zhang wrote:
>> On 11/17/2012 12:29 AM, Stephen Warren wrote:
>>> On 11/15/2012 09:58 PM, Mark Zhang wrote:
This patch is based on Thierry's drm patch for Tegra20:
kfree on a null argument is a no-op.
Silences the following smatch warning:
drivers/gpu/drm/drm_stub.c:496 drm_put_dev() info:
redundant null check on dev->devname calling kfree()
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/drm_stub.c |5 +
1 files changed, 1 insertions(+), 4 deletio
kcalloc returns NULL on failure. Hence check for the return value
and exit on error to avoid NULL pointer dereference.
Fixes the following smatch errors:
drivers/gpu/drm/drm_fb_helper.c:1271 drm_setup_crtcs() error:
potential null dereference 'modes'. (kcalloc returns null)
drivers/gpu/drm/drm_fb
drm_property_create_blob() could return NULL in which case NULL pointer
dereference error (on connector->edid_blob_ptr) is possible. Return if
connector->edid_blob_ptr is NULL.
Fixes the following smatch error:
drivers/gpu/drm/drm_crtc.c:3186 drm_mode_connector_update_edid_property()
error: potent
kfree() on a NULL input is a no-op. Hence remove the check.
Signed-off-by: Sachin Kamat
---
This series is build tested on the latest linux-next (20121115).
---
drivers/gpu/drm/drm_crtc.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/d
On 11/19/2012 03:03 PM, Maarten Lankhorst wrote:
> Op 19-11-12 14:26, Thomas Hellstrom schreef:
>> Hi,
>>
>> On 11/12/2012 03:00 PM, Maarten Lankhorst wrote:
>>> move to release_list instead
>> Can you describe why this change is made? cleanup? reorder locks in a later
>> patch?
>> Also please des
Op 19-11-12 14:33, Thomas Hellstrom schreef:
> On 11/12/2012 03:00 PM, Maarten Lankhorst wrote:
>> Just use the return error from ttm_mem_evict_first instead.
>
> Here driver need to be able to evict a memory type completely, because they
> might shut down
> the memory type or clear it for some le
Op 19-11-12 14:26, Thomas Hellstrom schreef:
> Hi,
>
> On 11/12/2012 03:00 PM, Maarten Lankhorst wrote:
>> move to release_list instead
>
> Can you describe why this change is made? cleanup? reorder locks in a later
> patch?
> Also please describe why you need move_notify and ttm unbind / destroy
Check overlay_ops is not NULL as checked in the previous 'if' condition.
Fixes the following smatch error:
drivers/gpu/drm/exynos/exynos_drm_encoder.c:509
exynos_drm_encoder_plane_disable()
error: we previously assumed 'overlay_ops' could be null (see line 499)
Signed-off-by: Sachin Kamat
---
d
On Mon, Nov 19, 2012 at 04:32:36PM +0200, Ville Syrj?l? wrote:
> On Thu, Nov 15, 2012 at 02:39:41PM +, Arnd Bergmann wrote:
> > On Thursday 15 November 2012, Rob Clark wrote:
> > > > I still haven't heard a conclusive argument why we need to use
> > > > get_user()
> > > > rather than copy_from
On 11/12/2012 03:00 PM, Maarten Lankhorst wrote:
> Just use the return error from ttm_mem_evict_first instead.
Here driver need to be able to evict a memory type completely, because
they might shut down
the memory type or clear it for some legacy usage, suspending or
whatever, so returning 0 on
Hi,
On 11/12/2012 03:00 PM, Maarten Lankhorst wrote:
> move to release_list instead
Can you describe why this change is made? cleanup? reorder locks in a
later patch?
Also please describe why you need move_notify and ttm unbind / destroy
to be outside of
reservation, because that's the main cha
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121119/edc3475b/attachment.html>
On 11/17/2012 12:29 AM, Stephen Warren wrote:
> On 11/15/2012 09:58 PM, Mark Zhang wrote:
>> This patch is based on Thierry's drm patch for Tegra20:
>> - [PATCH v2 0/6] Device tree updates for host1x support
>> - [PATCH v3 0/2] NVIDIA Tegra DRM driver
>>
>> It adds the support for NVIDIA Tegra30.
>
a printk just before this check to output its
value).
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121119/9d04f2e1/attachment-0001.html>
Fixes the following sparse warning:
drivers/gpu/drm/exynos/exynos_drm_fimd.c:69:25: warning:
symbol 'exynos5_fimd_driver_data' was not declared. Should it be static?
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(
Fixes the following sparse warning:
drivers/gpu/drm/exynos/exynos_drm_fimd.c:65:25: warning:
symbol 'exynos4_fimd_driver_data' was not declared. Should it be static?
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(
on my patch, let me know.
That issue is fixed in attachment 69573 which is already upstream.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121119/107aa960/attachment.html>
Changelog v3:
Passing the actual buffer size instead of vm_size to dma_mmap_attrs.
Changelog v2:
Extracting the private data from fb_info structure to obtain the exynos
gem buffer structure. Now, dma address is obtained from the exynos gem
buffer structure and not from smem_start. Also calling d
https://bugzilla.kernel.org/show_bug.cgi?id=50431
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #20 from Alex Deucher ---
(In reply to comment #19)
> Even if I would succeed in finding the bad commit how would you fix
> it if you can not reproduce the problem?
It will help narrow down what's causing the problem and give us a pl
CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.
Signed-off-by: Bill Pemberton
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sh
CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.
Signed-off-by: Bill Pemberton
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +-
drivers/gpu/drm/exynos/exynos
CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.
Signed-off-by: Bill Pemberton
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/ast/ast_drv.c| 2 +-
drivers/gpu/drm/cirrus/cirrus_drv.c | 2 +-
drivers/gpu/drm/exynos/exynos
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: Bill Pemberton
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: Bill Pemberton
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gp
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: Bill Pemberton
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/exynos/exynos_ddc.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
drivers/gpu/drm/exynos/exyn
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/mgag200/mgag200_mode.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index d3d99a2..f89a0c1 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.
Signed-off-by: Egbert Eich
---
include/drm/drm_crtc.h |8
include/drm/drm_edid.h |9 +
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 171aa33..06254bc 100644
--- a/include/drm/drm_crtc.h
+++ b/include/d
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/gma500/cdv_intel_dp.c|1 +
drivers/gpu/drm/gma500/oaktrail_lvds.c |1 +
drivers/gpu/drm/gma500/psb_intel_modes.c |1 +
3 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c
b/drivers/g
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/ast/ast_mode.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 7fc9f72..c27aa8d 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_m
So far it was only possible to load an EDID for a single connector (unless
no connector was specified at all in which case the same EDID file was used
for all).
This patch extends the EDID loader so that EDID files can be specified for
more than one connector. A semicolon is used to separate the di
Consolidate the null_edid_counter and the bad_edid_counter
into EDID error state flags which for the last EDID read
are accessible from user.
Errors are looged it the same error has not been present
in the previous read of the EDID. This will reset the
EDID error status for example when the monitor
According the the VESA specs there can be up to 254 EEDID extension blocks.
Since we may read the EDID (including extensions) in 10 second intervals to
probe for display hotplugging (at least in cases where no hardware hotplug
detection exists) and I2C transfer is rather slow we may end up consumin
There is no point to call krealloc() to shrink the amount of
memory for EDID blocks: the implementation of krealloc() will
ignore the size change and return the same chunk of memory
anyway.
So far we failed reading EDIDs when krealloc() failed.
This may happen if the size required to store an EDID
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/drm_edid.c | 77 ---
drivers/gpu/drm/drm_edid_load.c | 54 ++-
include/drm/drm_edid.h |1 +
3 files changed, 77 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu
1 - 100 of 167 matches
Mail list logo
