On 06/29/2017 08:13 PM, Philippe CORNU wrote:
On 06/28/2017 08:44 AM, Archit Taneja wrote:
On 06/19/2017 09:58 PM, Philippe CORNU wrote:
Add a Synopsys Designware MIPI DSI host DRM bridge driver, based on the
Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.
Signed-off
On 06/28/2017 02:35 PM, Andrzej Hajda wrote:
On 28.06.2017 08:44, Archit Taneja wrote:
On 06/19/2017 09:58 PM, Philippe CORNU wrote:
Add a Synopsys Designware MIPI DSI host DRM bridge driver, based on the
Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.
Signed-off-by: Ph
https://bugs.freedesktop.org/show_bug.cgi?id=100399
--- Comment #3 from Michel Dänzer ---
FWIW, I don't think unbinding is supposed to be possible while Xorg (or
anything else) is using the GPU. Sounds like there's something missing
somewhere to prevent that.
--
You are receiving this mail beca
https://bugs.freedesktop.org/show_bug.cgi?id=101499
--- Comment #24 from Michel Dänzer ---
(In reply to Harry Wentland from comment #23)
> Not sure even what that really means for DC. Is that scatter/gather?
Yes, exactly.
--
You are receiving this mail because:
You are the assignee for the bug
Hi Chen-Yu and Maxime,
On 30 June 2017 at 13:16, Chen-Yu Tsai wrote:
> On Fri, Jun 30, 2017 at 6:22 AM, Jonathan Liu wrote:
>> Hi Maxime,
>>
>> On 30 June 2017 at 01:56, Maxime Ripard
>> wrote:
>>> On Wed, Jun 28, 2017 at 08:39:33PM +1000, Jonathan Liu wrote:
>> + u32 int_status;
Add driver for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480)
TFT with Touch-Panel.
Datasheet available at:
http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf
Seiko 43WVF1G panel has two power supplies: avdd and dvdd and they
require a specific power on/down sequence.
For this reason the si
ttm_place are not supposed to change at runtime. All functions
working with ttm_place provided by work
with const ttm_place. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
3485 184 2643933 f5d drivers/gpu/drm/qxl/qxl_t
Hi Maxime,
On 30 June 2017 at 19:58, Jonathan Liu wrote:
> Hi Maxime,
>
> On 30 June 2017 at 19:34, Maxime Ripard
> wrote:
>> Hi,
>>
>> On Fri, Jun 30, 2017 at 08:22:13AM +1000, Jonathan Liu wrote:
>>> Hi Maxime,
>>>
>>> On 30 June 2017 at 01:56, Maxime Ripard
>>> wrote:
>>> > On Wed, Jun 28, 2
ttm_place are not supposed to change at runtime. All functions
working with ttm_place provided by work
with const ttm_place. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
dif
Hi Maxime,
On 30 June 2017 at 19:34, Maxime Ripard
wrote:
> Hi,
>
> On Fri, Jun 30, 2017 at 08:22:13AM +1000, Jonathan Liu wrote:
>> Hi Maxime,
>>
>> On 30 June 2017 at 01:56, Maxime Ripard
>> wrote:
>> > On Wed, Jun 28, 2017 at 08:39:33PM +1000, Jonathan Liu wrote:
>> >> >> + u32 int_status
Hi,
On Fri, Jun 30, 2017 at 11:47:55AM +0300, Tomi Valkeinen wrote:
> > So, I don't know... I guess I need to try to invent some horrible hacks
> > around the driver to somehow manage the omap3 problems. Perhaps
> > disabling/enabling the outputs when sync lost happens...
>
> Well, I tried that (
Hi,
On Fri, Jun 30, 2017 at 09:41:35AM +0300, Tomi Valkeinen wrote:
> On 29/06/17 21:50, Aaro Koskinen wrote:
> > On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote:
> >> On 15/06/17 01:11, Aaro Koskinen wrote:
> >>> When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and ther
ttm_place are not supposed to change at runtime. All functions
working with ttm_place provided by work
with const ttm_place. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
9235 344 136971525f3 drivers/gpu/drm/radeon/ra
drm_prop_enum_lists are not supposed to change at runtime. All functions
working with drm_prop_enum_list provided by work
with
const drm_prop_enum_list. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
9629 744 0 1037328
dma_buf_ops are not supposed to change at runtime. All functions
working with dma_buf_ops provided by work with
const dma_buf_ops. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
1240 112 01352 548
drivers/gpu/drm/om
On Fri, Jun 30, 2017 at 6:22 AM, Jonathan Liu wrote:
> Hi Maxime,
>
> On 30 June 2017 at 01:56, Maxime Ripard
> wrote:
>> On Wed, Jun 28, 2017 at 08:39:33PM +1000, Jonathan Liu wrote:
>>> >> + u32 int_status;
>>> >> + u32 fifo_status;
>>> >> + /* Read needs empty flag unset, write nee
ttm_place are not supposed to change at runtime. All functions
working with ttm_place provided by work
with const ttm_place. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
2315 184 02499 9c3 drivers/gpu/drm/virtio/vi
The documentation for drm_do_get_edid in drivers/gpu/drm/drm_edid.c states:
"As in the general case the DDC bus is accessible by the kernel at the I2C
level, drivers must make all reasonable efforts to expose it as an I2C
adapter and use drm_get_edid() instead of abusing this function."
Exposing t
ttm_place are not supposed to change at runtime. All functions
working with ttm_place provided by work
with const ttm_place. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
3172 796 163984 f90 drivers/gpu/drm/vmwgfx/vm
drm_prop_enum_lists are not supposed to change at runtime. All functions
working with drm_prop_enum_list provided by work
with
const drm_prop_enum_list. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
3594 176 03770 e
* Aaro Koskinen [170629 11:50]:
> Is it just me or do other OMAP users fail to see omapdrm changes being
> posted to linux-omap for testing or review purposes?
Yeah Cc:ing linux-omap in addition to the drm list is a good idea. Hopefully
we get few more people to review changes that way.
What als
drmMalloc will zero out the memory for us
---
xf86drm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 2ac3f26..879f85b 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -866,8 +866,6 @@ drmVersionPtr drmGetVersion(int fd)
drmVersionPtr retval;
drm_version_t *ve
dma_buf_ops are not supposed to change at runtime. All functions
working with dma_buf_ops provided by work with
const dma_buf_ops. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
2002 112 02114 842 drivers/gpu/drm/udl
drm_prop_enum_lists are not supposed to change at runtime. All functions
working with drm_prop_enum_list provided by work with
const drm_prop_enum_list. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
18276 384 0 1866048
Hi Kieran
> -static void rcar_du_vsp_complete(void *private)
> +static void rcar_du_vsp_complete(void *private, bool completed)
> {
> struct rcar_du_crtc *crtc = private;
>
> - rcar_du_crtc_finish_page_flip(crtc);
> + if (crtc->vblank_enable)
> + drm_crtc_handle_vblan
The current drm_fb_helper_sys helpers referenced in fb_ops assume that the
video memory is in system RAM. This is not the case for sparc which uses direct
physical memory accesses for IO memory and causes the bochs_drm module to panic
immediately upon startup as it tries to initialise the framebuff
Hi James,
Am Sonntag, den 02.07.2017, 19:36 +0100 schrieb James Courtier-Dutton:
> Hi,
>
> I have a Utilite Pro PC that uses the "Freescale i.MX 6 Quad".
> I am running Linux kernel 4.11.8
>
> I get the following messages:
> [5.234054] etnaviv gpu-subsystem: bound 134000.gpu (ops gpu_ops
> [
https://bugs.freedesktop.org/show_bug.cgi?id=101499
--- Comment #23 from Harry Wentland ---
Michel, I don't remember trying GTT scanout. Not sure even what that really
means for DC. Is that scatter/gather?
--
You are receiving this mail because:
You are the assignee for the bug.
2017-06-26 15:41 GMT+02:00 Lucas Stach :
> Am Freitag, den 09.06.2017, 12:26 +0200 schrieb Christian Gmeiner:
>> With 'sync points' we can sample the reqeustes perform signals
>> before and/or after the submited command buffer.
>>
>> Signed-off-by: Christian Gmeiner
>> ---
>> drivers/gpu/drm/etna
Hi,
I have a Utilite Pro PC that uses the "Freescale i.MX 6 Quad".
I am running Linux kernel 4.11.8
I get the following messages:
[5.234054] etnaviv gpu-subsystem: bound 134000.gpu (ops gpu_ops [etnaviv])
[5.234124] etnaviv gpu-subsystem: bound 13.gpu (ops gpu_ops [etnaviv])
[5.23
https://bugs.freedesktop.org/show_bug.cgi?id=101672
--- Comment #7 from MirceaKitsune ---
Created attachment 132397
--> https://bugs.freedesktop.org/attachment.cgi?id=132397&action=edit
mesa_err.log
I was able to find an important clue, while running Xonotic using the following
environment var
Hi Morimoto-san,
On Friday 30 Jun 2017 08:32:04 Kuninori Morimoto wrote:
> Hi Kieran
>
> > -static void rcar_du_vsp_complete(void *private)
> > +static void rcar_du_vsp_complete(void *private, bool completed)
> > {
> > struct rcar_du_crtc *crtc = private;
> >
> > - rcar_du_crtc_finish_pag
2017-06-26 15:30 GMT+02:00 Lucas Stach :
> Am Freitag, den 09.06.2017, 12:21 +0200 schrieb Christian Gmeiner:
>> In order to support performance counters in a sane way we need to
>> provide
>> a method to sync the GPU with the CPU. The GPU can process multpile
>> command
>> buffers/events per irq.
https://bugzilla.kernel.org/show_bug.cgi?id=196247
Mathias (mat...@yahoo.de) changed:
What|Removed |Added
Attachment #257291|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=196247
--- Comment #2 from Mathias (mat...@yahoo.de) ---
Comment on attachment 257291
--> https://bugzilla.kernel.org/attachment.cgi?id=257291
Output of command lspci -vvv
00:00.0 Host bridge: Intel Corporation Sky Lake Host Bridge/DRAM Registers (rev
On Sat, Jul 1, 2017 at 1:13 PM, John Brooks wrote:
> amd_powerplay_destroy() expects a handle pointing to a struct pp_instance.
> On chips without PowerPlay, pp_handle points to a struct amdgpu_device. The
> resulting attempt to kfree() fields of the wrong struct ends in fire:
>
> [ 91.560405] B
https://bugzilla.kernel.org/show_bug.cgi?id=196247
mat...@yahoo.de changed:
What|Removed |Added
Summary|AMD FirePro W5130M (Dell|AMD FirePro W5130M - Radeon
https://bugzilla.kernel.org/show_bug.cgi?id=196247
mat...@yahoo.de changed:
What|Removed |Added
Hardware|All |x86-64
Kernel Version|4.10.
https://bugzilla.kernel.org/show_bug.cgi?id=196247
--- Comment #1 from mat...@yahoo.de ---
Created attachment 257291
--> https://bugzilla.kernel.org/attachment.cgi?id=257291&action=edit
Output of command lspci -vvv
--
You are receiving this mail because:
You are watching the assignee of the bu
https://bugzilla.kernel.org/show_bug.cgi?id=196247
mat...@yahoo.de changed:
What|Removed |Added
Attachment #257289|dmesg output|Output of dmesg
description|
https://bugzilla.kernel.org/show_bug.cgi?id=196247
Bug ID: 196247
Summary: AMD FirePro W5130M (Dell 3510 notebook) - radeon
driver - ring 0 stalled
Product: Drivers
Version: 2.5
Kernel Version: 4.10.
Hardware: All
On some R-Car SoCs a single VSP can serve multiple DU channels through
multiple LIF instances in the VSP. The current DT bindings don't support
specifying that kind of SoC integration scheme. Extend them with a VSP
channel index.
Backward compatibility can be ensured in drivers by checking the len
Am 02.07.2017 um 11:13 schrieb Arvind Yadav:
ttm_place are not supposed to change at runtime. All functions
working with ttm_place provided by work
with const ttm_place. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
Reviewed-by: Christian König
---
drivers/gpu/drm/
Am 02.07.2017 um 11:06 schrieb Arvind Yadav:
ttm_place are not supposed to change at runtime. All functions
working with ttm_place provided by work
with const ttm_place. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
9235
Am 01.07.2017 um 19:13 schrieb John Brooks:
amd_powerplay_destroy() expects a handle pointing to a struct pp_instance.
On chips without PowerPlay, pp_handle points to a struct amdgpu_device. The
resulting attempt to kfree() fields of the wrong struct ends in fire:
[ 91.560405] BUG: unable to h
Am 01.07.2017 um 19:13 schrieb John Brooks:
We unref the man->move fence in ttm_bo_clean_mm() and then call
ttm_bo_force_list_clean() which waits on it, except the refcount is now
zero so a warning is generated (or worse):
[149492.279301] refcount_t: increment on 0; use-after-free.
[149492.27930
https://bugs.freedesktop.org/show_bug.cgi?id=101651
--- Comment #4 from Gregor Münch ---
Can confirm the bug on SI (Radeon HD 7970) and Borderlands: The Pre-Sequel
LLVM 5.0.0svn_r306967
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=99762
Gregor Münch changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
Status|NEW
2017-06-26 15:18 GMT+02:00 Lucas Stach :
> Am Freitag, den 09.06.2017, 12:21 +0200 schrieb Christian Gmeiner:
>> All performance monitor requests will be validated during this phase.
>>
>> Signed-off-by: Christian Gmeiner
>> ---
>> drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 68
>>
2017-06-26 15:02 GMT+02:00 Lucas Stach :
> Am Freitag, den 09.06.2017, 12:21 +0200 schrieb Christian Gmeiner:
>> This commits extends etnaviv_gpu_cmdbuf_new(..) to define the number
>> of struct etnaviv_perfmon elements gets stored.
>>
>> Signed-off-by: Christian Gmeiner
>> ---
>> drivers/gpu/drm
2017-06-26 14:56 GMT+02:00 Lucas Stach :
> Am Freitag, den 09.06.2017, 12:21 +0200 schrieb Christian Gmeiner:
>> Sadly we can not read any registers via command stream so we need
>> to extend the drm_etnaviv_gem_submit struct with performance monitor
>> requests. Those requests gets process before
51 matches
Mail list logo
