On Thu, Mar 13, 2014 at 12:30:39AM +0100, Pavel Machek wrote:
> Hi!
>
> This cost me two half-written mails...
>
> So far it happened once, so it may be very infrequent; but I do not
> think I seen similar failure from i915 before, so it may be an
> regression. Well...
It's a userspace use-after
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140312/c3fbccf7/attachment.html>
Signed-off-by: Ilia Mirkin
---
nouveau/nouveau.c | 29 -
nouveau/private.h | 3 ++-
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
index ee7893b..72c31cf 100644
--- a/nouveau/nouveau.c
+++ b/nouveau/nouveau.c
@@ -
On Wed, Mar 12, 2014 at 9:24 PM, Emil Velikov
wrote:
> On 13/03/14 01:05, Ilia Mirkin wrote:
> [snip]
>
>>
>> Not really. drm->drm_version will be 0 if ver fails.
>>
> Indeed, dev is calloc'ated by its callers, and if they mess around with
> that's their own fault.
The callers? It's calloc'd ins
On Wed, Mar 12, 2014 at 9:04 PM, Emil Velikov
wrote:
> On 13/03/14 00:45, Ilia Mirkin wrote:
>>
>> On Wed, Mar 12, 2014 at 4:45 PM, Emil Velikov
>> wrote:
>>>
>>> In theory it's possible for any of the nouveau_getparam calls to
>>> fail whist the last one being successful.
>>>
>>> Thus at least
On Wed, Mar 12, 2014 at 4:45 PM, Emil Velikov
wrote:
> Cc: Rob Clark
Thanks,
Reviewed-by: Rob Clark
> Signed-off-by: Emil Velikov
> ---
> freedreno/freedreno_device.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/freedreno/freedreno_device.c b/freedreno/freedreno_device.c
> inde
On Wed, Mar 12, 2014 at 4:45 PM, Emil Velikov
wrote:
> Current handling relies on atoi which does not detect errors
> additionally, any integer value will be considered as a valid
> percent.
>
> Resolve that by using strtol and limiting the value within
> the 5-100 (percent) range.
>
> Signed-off
Cc: Rob Clark
Signed-off-by: Emil Velikov
---
freedreno/freedreno_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/freedreno/freedreno_device.c b/freedreno/freedreno_device.c
index 598bdfb..c34963c 100644
--- a/freedreno/freedreno_device.c
+++ b/freedreno/freedreno_device.c
@@ -98,6
Current handling relies on atoi which does not detect errors
additionally, any integer value will be considered as a valid
percent.
Resolve that by using strtol and limiting the value within
the 5-100 (percent) range.
Signed-off-by: Emil Velikov
---
nouveau/nouveau.c | 24 +++---
In theory it's possible for any of the nouveau_getparam calls to
fail whist the last one being successful.
Thus at least one of the following (hard requirements) drmVersion,
chipset and vram/gart memory size will be filled with garbage and
sent to the userspace drivers.
Signed-off-by: Emil Veliko
On Wed, Mar 12, 2014 at 4:45 PM, Emil Velikov
wrote:
> In theory it's possible for any of the nouveau_getparam calls to
> fail whist the last one being successful.
>
> Thus at least one of the following (hard requirements) drmVersion,
> chipset and vram/gart memory size will be filled with garbag
Dave,
Rob's fix for oops on invalidate_caches() and a fix for a
performance regression.
/Thomas
The following changes since commit 45db98e54242f3ae94bdcfbfe754e743252eb168:
Merge branch 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux
into drm-fixes (2014-03-07 09:27:22 +1000)
From: Rob Clark
A few of the simpler TTM drivers (cirrus, ast, mgag200) do not implement
this function. Yet can end up somehow with an evicted bo:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [< (null)>] (null)
PGD 16e761067 PUD 16e6cf06
Hi Tomasz,
On Wed, Mar 12, 2014 at 8:19 AM, Tomasz Figa wrote:
> Hi Shirish,
>
>
> On 10.03.2014 04:44, Shirish S wrote:
>>
>> now that the drm_display_mode also provides aspect
>> ratio for all resolutions, this patch adds its usage
>> to set the active aspect ratio of AVI info frame
>> packets
On 03/12/2014 03:59 PM, Rob Clark wrote:
> From: Rob Clark
>
> A few of the simpler TTM drivers (cirrus, ast, mgag200) do not implement
> this function. Yet can end up somehow with an evicted bo:
>
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: [< (
l/attachments/20140312/e0d55077/attachment.html>
Dave,
Please hold this. I'll incorporate Rob Clark's fix and resend
/Thomas
On 03/12/2014 02:16 PM, Thomas Hellstrom wrote:
> Dave,
> A single fix for a performance regression.
>
> The following changes since commit 45db98e54242f3ae94bdcfbfe754e743252eb168:
>
> Merge branch 'drm-fixes-3.14' o
Hi Tomasz,
Thanks for the review comments,
On Wed, Mar 12, 2014 at 8:26 AM, Tomasz Figa wrote:
>
> Hi Shirish,
>
>
> On 10.03.2014 15:17, Shirish S wrote:
>>
>> below is list of pixel clocks and resoluitons
>> this patch adds:
>>
>> 7100 - 1280x800 at 60Hz RB
>> 7325 - 800x600 at 120H
2014-03-07 19:00 GMT+09:00 Andrzej Hajda :
> On 03/05/2014 03:56 AM, Inki Dae wrote:
>> Hi Andrzej,
>>
>> Thanks for your contributions.
>>
>> 2014-02-12 20:31 GMT+09:00 Andrzej Hajda :
>>> Hi,
>>>
>>> This patchset adds drivers and bindings to the following devices:
>>> - Exynos DSI master,
>>> -
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/20140312/2e9dd0dc/attachment.html>
libz.so.1 => /usr/lib32/libz.so.1 (0xf4be8000)
libffi.so.6 => /usr/lib32/libffi.so.6 (0xf4be)
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesk
ktop.org/archives/dri-devel/attachments/20140312/e7dafc72/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #13 from Tom Yan ---
Unfortunately, no.
Yet it seems that now (with kernel 3.13.6) disconnecting HDMI and DVI doesn't
shows a problem anymore. Only DisplayPort still got issue. (Though, if I don't
have anything connected before boot,
340 M configure.ac
--
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/20140312/7f17882e/attachment.html>
Hi Shirish,
On 11.03.2014 12:26, Shirish S wrote:
> This patch implements the power on/off sequence
> (and its dependant functions) of HDMI exynos5250
> as provided by the hardware team.
>
> Signed-off-by: Shirish S
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 137
>
es* get re-enabled on resume.
--
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/20140312/b444374d/attachment.html>
Hi Shirish,
On 10.03.2014 15:17, Shirish S wrote:
> below is list of pixel clocks and resoluitons
> this patch adds:
>
> 7100 - 1280x800 at 60Hz RB
> 7325 - 800x600 at 120Hz RB
> 8875 - 1440x900 at 60Hz RB
> 11550 - 1024x768 at 120Hz RB
> 11900 - 1680x1050 at 60Hz RB
>
> wit
One more fix on top:
drm/radeon/cik: properly set compute ring status on disable
When we disable the rings, set the status properly. If
not other code pathes may try and use the rings which are
not functional at this point.
On Wed, Mar 12, 2014 at 4:05 PM, Alex Deucher wrote:
When we disable the rings, set the status properly. If
not other code pathes may try and use the rings which are
not functional at this point.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/cik.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
di
Hi Shirish,
On 10.03.2014 04:44, Shirish S wrote:
> now that the drm_display_mode also provides aspect
> ratio for all resolutions, this patch adds its usage
> to set the active aspect ratio of AVI info frame
> packets as per CEA-861-D standard's Table 9.
>
> This is also needed to abide by the 7-
Hi Dave,
A few more radeon fixes.
The following changes since commit 45db98e54242f3ae94bdcfbfe754e743252eb168:
Merge branch 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux
into drm-fixes (2014-03-07 09:27:22 +1000)
are available in the git repository at:
git://people.fre
We always stop the rings when disabling the engines so just
call the stop functions directly from the sdma enable function.
This way the rings' status is set correctly on suspend so
there are no problems on resume. Fixes resume failures that
result in acceleration getting disabled.
Signed-off-by:
When we disable the rings, set the status properly. If
not other code pathes may try and use the rings which are
not functional at this point.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/cik_sdma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/dr
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140312/08abc773/attachment.html>
Hi,
On 03/12/2014 02:16 PM, David Herrmann wrote:
> Hi
>
You didn't miss any patches. It was I who missed the usage in drm_crtc.c.
I guess this, and Daniel's reply prompts a discussion about control
nodes and the master concept.
First I'd like to give some background about
Hi
>>> You didn't miss any patches. It was I who missed the usage in drm_crtc.c.
>>> I guess this, and Daniel's reply prompts a discussion about control
>>> nodes and the master concept.
>>>
>>> First I'd like to give some background about the use-case: I'd like to
>>> use the control node for a d
Dave,
A single fix for a performance regression.
The following changes since commit 45db98e54242f3ae94bdcfbfe754e743252eb168:
Merge branch 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux
into drm-fixes (2014-03-07 09:27:22 +1000)
are available in the git repository at:
git:/
On 03/12/2014 10:45 AM, David Herrmann wrote:
> Hi
>
>> You didn't miss any patches. It was I who missed the usage in drm_crtc.c.
>> I guess this, and Daniel's reply prompts a discussion about control
>> nodes and the master concept.
>>
>> First I'd like to give some background about the use-case:
A performance regression was introduced in TTM in linux 3.13 when we started
using
VM_PFNMAP for shared mappings. In theory this should've been faster due to
less page book-keeping but it appears like VM_PFNMAP + x86 PAT + write-combine
is a particularly cpu-hungry combination, as seen by largely
enum {
>> > #define PSB_AUX_RESOURCE0
>> > #define PSB_GATT_RESOURCE 2
>> > #define PSB_GTT_RESOURCE3
>> > +
>> > /*
>> > * PCI configuration
>> > */
>> > @@ -88,26 +97,24 @@ enum {
>> > #define _PSB_PGETBL_ENABLED 0x0001
>> > #define PSB_SGX_2D_SLAVE_PORT 0x4000
>> >
>> > -/* To get rid of */
>> > +/* TODO: To get rid of */
>> > #define PSB_TT_PRIV0_LIMIT (256*1024*1024)
>> > #define PSB_TT_PRIV0_PLIMIT (PSB_TT_PRIV0_LIMIT >> PAGE_SHIFT)
>> >
>> > /*
>> > - * SGX side MMU definitions (these can probably go)
>> > - */
>> > -
>> > -/*
>> > * Flags for external memory type field.
>> > */
>> > #define PSB_MMU_CACHED_MEMORY0x0001/* Bind to MMU only */
>> > #define PSB_MMU_RO_MEMORY0x0002/* MMU RO memory */
>> > #define PSB_MMU_WO_MEMORY0x0004/* MMU WO memory */
>> > +
>> > /*
>> > * PTE's and PDE's
>> > */
>> > #define PSB_PDE_MASK 0x003F
>> > #define PSB_PDE_SHIFT22
>> > #define PSB_PTE_SHIFT12
>> > +
>> > /*
>> > * Cache control
>> > */
>> > @@ -286,7 +293,6 @@ struct intel_gmbus {
>> > /*
>> > * Register offset maps
>> > */
>> > -
>> > struct psb_offset {
>> > u32 fp0;
>> > u32 fp1;
>> > @@ -485,7 +491,6 @@ struct drm_psb_private {
>> > /*
>> > * Register base
>> > */
>> > -
>> > uint8_t __iomem *sgx_reg;
>> > uint8_t __iomem *vdc_reg;
>> > uint8_t __iomem *aux_reg; /* Auxillary vdc pipe regs */
>> > @@ -494,7 +499,6 @@ struct drm_psb_private {
>> > /*
>> > * Fencing / irq.
>> > */
>> > -
>> > uint32_t vdc_irq_mask;
>> > uint32_t pipestat[PSB_NUM_PIPE];
>> >
>> > @@ -503,7 +507,6 @@ struct drm_psb_private {
>> > /*
>> > * Power
>> > */
>> > -
>> > bool suspended;
>> > bool display_power;
>> > int display_count;
>> > @@ -526,7 +529,6 @@ struct drm_psb_private {
>> > /*
>> > * Sizes info
>> > */
>> > -
>> > u32 fuse_reg_value;
>> > u32 video_device_fuse;
>> >
>> > @@ -585,7 +587,6 @@ struct drm_psb_private {
>> > /*
>> > * Register state
>> > */
>> > -
>> > struct psb_save_area regs;
>> >
>> > /* MSI reg save */
>> > @@ -595,7 +596,6 @@ struct drm_psb_private {
>> > /*
>> > * Hotplug handling
>> > */
>> > -
>> > struct work_struct hotplug_work;
>> >
>> > /*
>> > @@ -609,7 +609,6 @@ struct drm_psb_private {
>> > /*
>> > * Watchdog
>> > */
>> > -
>> > uint32_t apm_reg;
>> > uint16_t apm_base;
>> >
>> > @@ -667,7 +666,6 @@ struct drm_psb_private {
>> > /*
>> > * Operations for each board type
>> > */
>> > -
>> > struct psb_ops {
>> > const char *name;
>> > unsigned int accel_2d:1;
>> > @@ -726,7 +724,6 @@ static inline struct drm_psb_private
>> *psb_priv(struct drm_device *dev)
>> > /*
>> > * MMU stuff.
>> > */
>> > -
>> > extern struct psb_mmu_driver *psb_mmu_driver_init(uint8_t __iomem *
>> registers,
>> > int trap_pagefaults,
>> > int invalid_type,
>> > @@ -754,8 +751,6 @@ extern int psb_mmu_virtual_to_pfn(struct psb_mmu_pd
>> *pd, uint32_t virtual,
>> > /*
>> > * Enable / disable MMU for different requestors.
>> > */
>> > -
>> > -
>> > extern void psb_mmu_set_pd_context(struct psb_mmu_pd *pd, int
>> hw_context);
>> > extern int psb_mmu_insert_pages(struct psb_mmu_pd *pd, struct page
>> **pages,
>> > unsigned long address, uint32_t
>> num_pages,
>> > @@ -766,9 +761,8 @@ extern void psb_mmu_remove_pages(struct psb_mmu_pd
>> *pd,
>> > uint32_t desired_tile_stride,
>> > uint32_t hw_tile_stride);
>> > /*
>> > - *psb_irq.c
>> > + * psb_irq.c
>> > */
>> > -
>> > extern irqreturn_t psb_irq_handler(int irq, void *arg);
>> > extern int psb_irq_enable_dpst(struct drm_device *dev);
>> > extern int psb_irq_disable_dpst(struct drm_device *dev);
>> > @@ -808,7 +802,6 @@ extern void psb_spank(struct drm_psb_private
>> *dev_priv);
>> > /*
>> > * psb_reset.c
>> > */
>> > -
>> > extern void psb_lid_timer_init(struct drm_psb_private *dev_priv);
>> > extern void psb_lid_timer_takedown(struct drm_psb_private *dev_priv);
>> > extern void psb_print_pagefault(struct drm_psb_private *dev_priv);
>> > @@ -888,7 +881,6 @@ extern int drm_idle_check_interval;
>> > /*
>> > * Utilities
>> > */
>> > -
>> > static inline u32 MRST_MSG_READ32(uint port, uint offset)
>> > {
>> > int mcr = (0xD0<<24) | (port << 16) | (offset << 8);
>> > --
>> > 1.9.0
>> >
>>
>
>
>
> --
> Arthur Borsboom
> 11 Rue du Manerick
> 44740 Batz Sur Mer, France
> Mob: +33785927118
> Email: arthurborsboom at gmail.com
> Skype: Arthur Borsboom, The Hague, The Netherlands
>
> [image: View Arthur's LinkedIn
> profile]<http://uk.linkedin.com/in/arthurborsboom>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140312/56693a34/attachment-0001.html>
On 12.03.2014 11:08, Inki Dae wrote:
> 2014-03-07 19:00 GMT+09:00 Andrzej Hajda :
>> On 03/05/2014 03:56 AM, Inki Dae wrote:
>>> Hi Andrzej,
>>>
>>> Thanks for your contributions.
>>>
>>> 2014-02-12 20:31 GMT+09:00 Andrzej Hajda :
Hi,
This patchset adds drivers and bindings to the fo
On Wed, Mar 12, 2014 at 10:59:37AM -0400, Rob Clark wrote:
> From: Rob Clark
>
> A few of the simpler TTM drivers (cirrus, ast, mgag200) do not implement
> this function. Yet can end up somehow with an evicted bo:
>
> BUG: unable to handle kernel NULL pointer dereference at (null)
>
From: Rob Clark
A few of the simpler TTM drivers (cirrus, ast, mgag200) do not implement
this function. Yet can end up somehow with an evicted bo:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [< (null)>] (null)
PGD 16e761067 PUD 16e6cf06
Hi
> You didn't miss any patches. It was I who missed the usage in drm_crtc.c.
> I guess this, and Daniel's reply prompts a discussion about control
> nodes and the master concept.
>
> First I'd like to give some background about the use-case: I'd like to
> use the control node for a daemon that t
w boards, but that is causing major headaches
and I want to get rid of it.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140312/f3b90cfd/attachment-0001.pgp>
On Tue, Mar 11, 2014 at 04:45:00PM -0700, Bob Paauwe wrote:
> On Fri, 7 Mar 2014 16:03:17 -0800
> Matt Roper wrote:
...
> > +static int drm_mode_create_standard_plane_properties(struct drm_device
> > *dev)
> > +{
> > + struct drm_property *type;
> > +
> > + /*
> > +* Standard properties (
userspace or in a kernel module?
Sorry for my poor english and thanks for every answer - Robert
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140312/f7ed08c5/attachment.html>
On Wed, Mar 12, 2014 at 8:12 AM, Thomas Hellstrom
wrote:
> A performance regression was introduced in TTM in linux 3.13 when we started
> using
> VM_PFNMAP for shared mappings. In theory this should've been faster due to
> less page book-keeping but it appears like VM_PFNMAP + x86 PAT + write-co
On Wed, Mar 12, 2014 at 5:40 AM, Robert Kuhn wrote:
> Hi,
>
> I am using a Beaglebone black with a HDMI monitor. As far as I see the
> beaglebone uses the tilcdc driver for framebuffer (I am using the
> linux-dev-3.13.6-bone7 kernel).
>
> When I am correct this driver does not implement the FBIO_W
L attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140312/5a6235bd/attachment.html>
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/20140312/0fa6787e/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140312/80cdc827/attachment.html>
nts/20140312/78667ccd/attachment-0001.html>
On Tue, Mar 11, 2014 at 12:22 PM, Arthur Borsboom
wrote:
> drm/gma500: Cleanup of code by following i915 constant/variable names and
> ordering
> drm/gma500: Cleanup of code by following directions from kernel
> documentation: Codingstyle
> drm/gma500: Cleanup of code by following directions fro
54 matches
Mail list logo
