Villie:
What is Intel's plan for the colorkey patch? Does Intel have any plan to
review and release?
If I go with custom ioctl, and my custom ioctl will only used in Baytrail
product, could it be atomic for Baytrail only?
Thanks,
Jim
Caterpillar: Confidential Green
-Original Message--
- On Apr 9, 2019, at 1:55 PM, paulmck paul...@linux.ibm.com wrote:
[...]
> The current state is not horrible, so my thought would be to give it
> some time to see if better thoughts arise.
>
> Either way, cleanup_srcu_struct() keeps its current checks for callbacks
> still being in flight, whi
Hello,
On Tuesday, 09 April 2019 at 16:44, Hans de Goede wrote:
> Hi,
>
> On 09-04-19 14:05, Patrik Jakobsson wrote:
> > On Tue, Apr 9, 2019 at 12:20 PM Hans de Goede wrote:
> > >
> > > Hi,
> > >
> > > On 09-04-19 11:47, Patrik Jakobsson wrote:
> > > > On Tue, Apr 9, 2019 at 8:51 AM Hans de Go
Once I pre-configure the colorkey, am I able to enable and disable it? If
colorkey can be enabled/disabled after that might meet my requirement
Thanks,
Jim
Caterpillar: Confidential Green
-Original Message-
From: Ville Syrjälä
Sent: Tuesday, April 9, 2019 8:57 AM
To: Jim Zhang
Cc:
On 20-03-19, 15:19, Rajendra Nayak wrote:
> This is a v2 of the RFC posted earlier by Stephen Boyd [1]
>
> As part of v2 I still follow the same approach of dev_pm_opp_set_rate()
> API using clk framework to round the frequency passed and making it
> accept 0 as a valid frequency indicating the fr
From: Alastair D'Silva
With the wider display format, it can become hard to identify how many
bytes into the line you are looking at.
The patch adds new flags to hex_dump_to_buffer() and print_hex_dump() to
print vertical lines to separate every N groups of bytes.
eg.
buf:: 454d414e 434
If I go with pre-configured colorkey, do I need port your kernel patch to i915
driver at kernel 3.10.61 ?
Thanks,
Jim
Caterpillar: Confidential Green
-Original Message-
From: Ville Syrjälä
Sent: Tuesday, April 9, 2019 10:02 AM
To: Jim Zhang
Cc: intel-...@lists.freedesktop.org; dri
the ttm_bo_add_move_fence takes a reference to the struct dma_fence, but
failed to release it on the error path, leading to a memory leak.
add dma_fence_put before return when error occur.
Signed-off-by: Lin Yi
---
drivers/gpu/drm/ttm/ttm_bo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletio
On Tue, Apr 09, 2019 at 11:56:03AM -0400, Mathieu Desnoyers wrote:
> - On Apr 9, 2019, at 11:40 AM, Joel Fernandes, Google
> j...@joelfernandes.org wrote:
>
> > On Mon, Apr 08, 2019 at 01:24:47PM -0400, Mathieu Desnoyers wrote:
> >> - On Apr 8, 2019, at 11:46 AM, paulmck paul...@linux.ibm
On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote:
> Amlogic G12A SoC supports the same set of Video Planes, but now
> are handled by the new OSD plane blender module.
>
> This patch uses the same VD1 plane for G12A, using the exact same scaler
> and VD11 setup registers, except using the ne
On Tue, Apr 09, 2019 at 12:45:25PM -0400, Mathieu Desnoyers wrote:
> - On Apr 9, 2019, at 12:40 PM, paulmck paul...@linux.ibm.com wrote:
>
> > On Tue, Apr 09, 2019 at 11:56:03AM -0400, Mathieu Desnoyers wrote:
> >> - On Apr 9, 2019, at 11:40 AM, Joel Fernandes, Google
> >> j...@joelfernan
On Tue, 2019-04-09 at 10:43 +0200, Jerome Brunet wrote:
> On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote:
> > The Meson G12A SoCs uses the exact same CVBS encoder except a simple
> > CVBS DAC register offset and settings delta.
> >
> > Signed-off-by: Neil Armstrong
> > ---
> > drivers/
On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote:
> While switching to the Common Clock Framework is still Work In Progress,
> this patch adds the corresponding G12A HDMI PLL setup to be on-par
> with the other SoCs support.
>
> The G12A has only a single tweak about the high frequency setu
On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote:
> The Meson G12A SoCs uses the exact same CVBS encoder except a simple
> CVBS DAC register offset and settings delta.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/meson/meson_venc.c | 11 +--
> drivers/gpu/drm/mes
On Mon, Apr 08, 2019 at 01:24:47PM -0400, Mathieu Desnoyers wrote:
> - On Apr 8, 2019, at 11:46 AM, paulmck paul...@linux.ibm.com wrote:
>
> > On Mon, Apr 08, 2019 at 10:49:32AM -0400, Mathieu Desnoyers wrote:
> >> - On Apr 8, 2019, at 10:22 AM, paulmck paul...@linux.ibm.com wrote:
> >>
>
On Tue, Apr 09, 2019 at 02:04:11PM -0400, Mathieu Desnoyers wrote:
> - On Apr 9, 2019, at 1:55 PM, paulmck paul...@linux.ibm.com wrote:
> [...]
> > The current state is not horrible, so my thought would be to give it
> > some time to see if better thoughts arise.
> >
> > Either way, cleanup_sr
On Wed, 2019-04-10 at 13:17 +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> Some buffers may only be partially filled with useful data, while the
> rest
> is padded (typically with 0x00 or 0xff).
>
This patch introduces flags which allow lines of padding bytes to be
> suppressed, mak
From: Alastair D'Silva
With modern high resolution screens, we can display more data, which makes
life a bit easier when debugging.
Allow 64 bytes to be dumped per line.
Signed-off-by: Alastair D'Silva
---
lib/hexdump.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
dif
On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote:
> Amlogic G12A SoC needs a different VIU setup code,
> handle it.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/meson/meson_viu.c | 72 ---
> 1 file changed, 67 insertions(+), 5 deletions(-)
>
> dif
Ville:
Yes, if this patch is needed by kernel 3.10.61, please get somebody to review
it. What do I need do to speed up the review process?
Please generate a patch against kernel 3.10.61 if possible.
Thanks,
Jim
Caterpillar: Confidential Green
-Original Message-
From: Jim Zhang
Sen
On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote:
> The Amlogic G12A SoC offers very close Video Display
> functionnalities with it's older GXBB, GXL & GXM predecessors.
>
> The main differences are :
> - G12A Support now 3 "real" OSD planes with a new Blender module
> - Instead of having a
On Tue, Apr 09, 2019 at 11:56:03AM -0400, Mathieu Desnoyers wrote:
> - On Apr 9, 2019, at 11:40 AM, Joel Fernandes, Google
> j...@joelfernandes.org wrote:
>
> > On Mon, Apr 08, 2019 at 01:24:47PM -0400, Mathieu Desnoyers wrote:
> >> - On Apr 8, 2019, at 11:46 AM, paulmck paul...@linux.ibm
On 20-03-19, 15:19, Rajendra Nayak wrote:
> On some qualcomm platforms DPU needs to express a perforamnce state
> requirement on a power domain depennding on the clock rates.
> Use OPP table from DT to register with OPP framework and use
> dev_pm_opp_set_rate() to set the clk/perf state.
>
> Signe
From: Alastair D'Silva
In order to support additional features in hex_dump_to_buffer, replace
the ascii bool parameter with flags.
Signed-off-by: Alastair D'Silva
---
drivers/gpu/drm/i915/intel_engine_cs.c| 2 +-
drivers/isdn/hardware/mISDN/mISDNisar.c | 6 --
drive
What about if I disable interrupt when changing the colorkey? This will solve
the atomic issue. I think we only change colorkey or enable/disable colorkey
once a while. If disabling interrupt work, I will disable interrupt and change
colorkey. That performance affection could be acceptable
Th
- On Apr 9, 2019, at 11:40 AM, Joel Fernandes, Google
j...@joelfernandes.org wrote:
> On Mon, Apr 08, 2019 at 01:24:47PM -0400, Mathieu Desnoyers wrote:
>> - On Apr 8, 2019, at 11:46 AM, paulmck paul...@linux.ibm.com wrote:
>>
>> > On Mon, Apr 08, 2019 at 10:49:32AM -0400, Mathieu Desnoy
- On Apr 9, 2019, at 12:40 PM, paulmck paul...@linux.ibm.com wrote:
> On Tue, Apr 09, 2019 at 11:56:03AM -0400, Mathieu Desnoyers wrote:
>> - On Apr 9, 2019, at 11:40 AM, Joel Fernandes, Google
>> j...@joelfernandes.org
>> wrote:
>>
>> > On Mon, Apr 08, 2019 at 01:24:47PM -0400, Mathieu
From: Alastair D'Silva
Apologies for the large CC list, it's a heads up for those responsible
for subsystems where a prototype change in generic code causes a change
in those subsystems.
This series enhances hexdump.
These improve the readability of the dumped data in certain situations
(eg. wi
Nice, do you have any sample code for it?
Thanks,
Jim
Caterpillar: Confidential Green
-Original Message-
From: Ville Syrjälä
Sent: Tuesday, April 9, 2019 8:57 AM
To: Jim Zhang
Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] colorkey supp
On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote:
> This patch adds support for the new OSD+VD Plane blending module
> in the CRTC code by adding the G12A code to manage the blending
> module and setting the right OSD1 & VD1 plane registers.
>
> Signed-off-by: Neil Armstrong
> ---
> drive
From: Alastair D'Silva
Some buffers may only be partially filled with useful data, while the rest
is padded (typically with 0x00 or 0xff).
This patch introduces flags which allow lines of padding bytes to be
suppressed, making the output easier to interpret: HEXDUMP_SUPPRESS_0X00,
HEXDUMP_SUPPRE
Hi,
On 09-04-19 21:31, Dominik 'Rathann' Mierzejewski wrote:
Hello,
On Tuesday, 09 April 2019 at 16:44, Hans de Goede wrote:
Hi,
On 09-04-19 14:05, Patrik Jakobsson wrote:
On Tue, Apr 9, 2019 at 12:20 PM Hans de Goede wrote:
Hi,
On 09-04-19 11:47, Patrik Jakobsson wrote:
On Tue, Apr 9,
https://bugs.freedesktop.org/show_bug.cgi?id=110371
--- Comment #1 from Michel Dänzer ---
Please attach the corresponding full output of dmesg.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-dev
Some drivers (for example qxl) support neither import nor export of
dma-bufs. But you can still use dma-bufs to pass buffer references
from one process to another; drm_gem_prime_import() will figure the
dma-buf came from the same driver and just takes a reference in that
case instead of doing a fu
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs.h | 6 +-
drivers/gpu/drm/bochs/bochs_kms.c | 178 +-
2 files changed, 53 insertions(+), 131 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index a7f6723bebdd..
https://bugs.freedesktop.org/show_bug.cgi?id=110376
Bug ID: 110376
Summary: [CI][SHARDS]
igt@kms_cursor_legacy@nonblocking-modeset-vs-cursor-at
omic - dmesg-warn - *ERROR* Failed to enable hdcp
(-110)
Pro
https://bugs.freedesktop.org/show_bug.cgi?id=110376
Martin Peres changed:
What|Removed |Added
Whiteboard||ReadyForDev
Priority|medium
https://bugs.freedesktop.org/show_bug.cgi?id=110376
--- Comment #1 from CI Bug Log ---
The CI Bug Log issue associated to this bug has been updated.
### New filters associated
* KBL: igt@kms_cursor_legacy@nonblocking-modeset-vs-cursor-atomic - dmesg-warn
- *ERROR* Failed to enable hdcp (-110)
On Wed, Apr 10, 2019 at 9:27 AM Hans de Goede wrote:
>
> Hi,
>
> On 09-04-19 21:31, Dominik 'Rathann' Mierzejewski wrote:
> > Hello,
> >
> > On Tuesday, 09 April 2019 at 16:44, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 09-04-19 14:05, Patrik Jakobsson wrote:
> >>> On Tue, Apr 9, 2019 at 12:20 PM
Hi,
On 10-04-19 11:00, Patrik Jakobsson wrote:
On Wed, Apr 10, 2019 at 9:27 AM Hans de Goede wrote:
Hi,
On 09-04-19 21:31, Dominik 'Rathann' Mierzejewski wrote:
Hello,
On Tuesday, 09 April 2019 at 16:44, Hans de Goede wrote:
Hi,
On 09-04-19 14:05, Patrik Jakobsson wrote:
On Tue, Apr 9,
https://bugs.freedesktop.org/show_bug.cgi?id=110360
--- Comment #3 from jian-h...@endlessm.com ---
Created attachment 143916
--> https://bugs.freedesktop.org/attachment.cgi?id=143916&action=edit
The dmesg of disabled amdgpu's runpm
(In reply to Alex Deucher from comment #2)
> Does booting with
Den 10.04.2019 08.38, skrev Gerd Hoffmann:
> Not all archs have the __io_virt() macro, so cirrus can't simply convert
> pointers that way. The drm format helpers have to use memcpy_toio()
> instead.
>
> This patch makes drm_fb_memcpy_dstclip() accept a __iomem dst pointer
> and use memcpy_toio(
Den 10.04.2019 08.38, skrev Gerd Hoffmann:
> Not all archs have the __io_virt() macro, so cirrus can't simply convert
> pointers that way. The drm format helpers have to use memcpy_toio()
> instead.
>
> This patch makes drm_fb_xrgb_to_rgb888_dstclip() accept a __iomem
> dst pointer and use
Den 10.04.2019 08.38, skrev Gerd Hoffmann:
> Not all archs have the __io_virt() macro, so cirrus can't simply convert
> pointers that way. The drm format helpers have to use memcpy_toio()
> instead.
>
> This patch makes drm_fb_xrgb_to_rgb565_dstclip() accept a __iomem
> dst pointer and use
When we increment the counter we need to increment the pointer as well.
Signed-off-by: Christian König
Fixes: e16858a7e6e7 drm/ttm: fix start page for huge page check in
ttm_put_pages()
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --gi
Hi Al,
I wonder if it would be possible to extend anon_inodes to return just an
anonymous inode, thereby allowing the drm filesystem to be removed in favour
of just using an anon_inode.
David
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
ht
On 2019-04-10 11:45 a.m., Christian König wrote:
> When we increment the counter we need to increment the pointer as well.
>
> Signed-off-by: Christian König
> Fixes: e16858a7e6e7 drm/ttm: fix start page for huge page check in
> ttm_put_pages()
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 4 +
On Wed, Apr 10, 2019 at 11:00:23AM +0200, Patrik Jakobsson wrote:
> On Wed, Apr 10, 2019 at 9:27 AM Hans de Goede wrote:
> >
> > Hi,
> >
> > On 09-04-19 21:31, Dominik 'Rathann' Mierzejewski wrote:
> > > Hello,
> > >
> > > On Tuesday, 09 April 2019 at 16:44, Hans de Goede wrote:
> > >> Hi,
> > >>
Add new properties to specify width and height for writeback.
Signed-off-by: Ben Davis
---
drivers/gpu/drm/drm_atomic_uapi.c | 8
drivers/gpu/drm/drm_writeback.c | 28
include/drm/drm_connector.h | 4
include/drm/drm_mode_config.h | 10 +++
The phase setting part of malidp_crtc_atomic_check_scaling is refactored
to allow use in writeback scaling.
Also the enable_memwrite function prototype is simplified by directely
passing mw_state.
Signed-off-by: Ben Davis
---
drivers/gpu/drm/arm/malidp_crtc.c | 49 --
driver
Add support for scaling on writeback. To do this add writeback_w and
writeback_h as writeback connector properties to specify the desired
output dimensions.
Then implement downscaling on writeback for Malidp-550 and Malidp-650
(upscaling on writeback is not supported on these devices).
Ben Davis (
https://bugs.freedesktop.org/show_bug.cgi?id=109294
Lakshmi changed:
What|Removed |Added
Resolution|NOTABUG |---
Assignee|tvrtko.ursulin@linux.i
On Wed, Apr 10, 2019 at 1:18 PM Dominik 'Rathann' Mierzejewski
wrote:
>
> On Wednesday, 10 April 2019 at 11:08, Hans de Goede wrote:
> > On 10-04-19 11:00, Patrik Jakobsson wrote:
> > > On Wed, Apr 10, 2019 at 9:27 AM Hans de Goede wrote:
> > > > On 09-04-19 21:31, Dominik 'Rathann' Mierzejewski
On Wed, Apr 10, 2019 at 12:43 PM Ville Syrjälä
wrote:
>
> On Wed, Apr 10, 2019 at 11:00:23AM +0200, Patrik Jakobsson wrote:
> > On Wed, Apr 10, 2019 at 9:27 AM Hans de Goede wrote:
> > >
> > > Hi,
> > >
> > > On 09-04-19 21:31, Dominik 'Rathann' Mierzejewski wrote:
> > > > Hello,
> > > >
> > > >
On Wed, Apr 10, 2019 at 11:09 AM Hans de Goede wrote:
>
> Hi,
>
> On 10-04-19 11:00, Patrik Jakobsson wrote:
> > On Wed, Apr 10, 2019 at 9:27 AM Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 09-04-19 21:31, Dominik 'Rathann' Mierzejewski wrote:
> >>> Hello,
> >>>
> >>> On Tuesday, 09 April 2019
Hi folks,
Revisited the old VIRTIO_GPU_CMD_RESOURCE_CREATE_V2 approach and figured
this is maybe not the best way to go forward. I think it is much more
useful to separate memory and resource management (see patch #2).
VIRTIO_GPU_CMD_RESOURCE_CREATE_V2 is still there (see patch #3).
For now I
Add new command VIRTIO_GPU_CMD_RESOURCE_CREATE_V2 to create resources.
It adds (a) support planar resources and (b) returns stride and size of
the resource planes. The later will be needed in case we support
mapping host resources into the guest some day.
Signed-off-by: Gerd Hoffmann
---
includ
Introduce the concept of memory regions to virtio-gpu. Initially only
memory regions composed of guest pages are supported (pretty much like
current backing storage for resources). I expect support for other
memory types will be added later on.
VIRTIO_GPU_CMD_MEMORY_CREATE:
creates a new mem
Add comments to the existing feature flags,
documenting which commands belong to them.
Signed-off-by: Gerd Hoffmann
---
include/uapi/linux/virtio_gpu.h | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gp
Op 10-04-2019 om 13:11 schreef Ben Davis:
> Add new properties to specify width and height for writeback.
>
> Signed-off-by: Ben Davis
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 8
> drivers/gpu/drm/drm_writeback.c | 28
> include/drm/drm_connector.h
On Wed, 10 Apr 2019 at 12:20, Steven Price wrote:
>
> On 08/04/2019 22:04, Rob Herring wrote:
> > On Fri, Apr 5, 2019 at 7:30 AM Steven Price wrote:
> >>
> >> On 01/04/2019 08:47, Rob Herring wrote:
> >>> This adds the initial driver for panfrost which supports Arm Mali
> >>> Midgard and Bifrost
On Fri, 5 Apr 2019 at 11:20, Noralf Trønnes wrote:
>
>
>
> Den 05.04.2019 07.28, skrev Joel Stanley:
> > When building this driver for architectures where CMA is not available.
> >
> > Fixes: 4f2a8f5898ec ("drm: Add ASPEED GFX driver")
> > Reported-by: Stephen Rothwell
> > Reported-by: kernel tes
Due to copy/paste error, the fbdev format was changed to 32bpp = XRGB
which is an emulated format for the RGB565 drivers. Revert to to using the
fallback which is dev->mode_config.preferred_depth for the drivers that
set it or 32bpp for those that don't (repaper, st7586).
Fixes: 3eba3922819f (
Den 10.04.2019 09.48, skrev Gerd Hoffmann:
> Signed-off-by: Gerd Hoffmann
> ---
Acked-by: Noralf Trønnes
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 10/04/2019 14:43, Noralf Trønnes wrote:
> Due to copy/paste error, the fbdev format was changed to 32bpp = XRGB
> which is an emulated format for the RGB565 drivers. Revert to to using the
> fallback which is dev->mode_config.preferred_depth for the drivers that
> set it or 32bpp for those t
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville
>Syrjälä
>Sent: Monday, April 8, 2019 9:38 PM
>To: Shankar, Uma
>Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; seanp...@chromium.or
https://bugs.freedesktop.org/show_bug.cgi?id=110381
Bug ID: 110381
Summary: Failed to updateMST allocation table forpipe idx:0
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: n
On Mon, Apr 08, 2019 at 10:11:26AM +0200, Maxime Ripard wrote:
> On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote:
> > On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> > > Hi,
> > >
> > > We've had for quite some time to hack around in our drivers to take into
> > > accou
Am 09.04.19 um 18:42 schrieb Grodzovsky, Andrey:
On 4/9/19 10:50 AM, Christian König wrote:
Am 08.04.19 um 18:08 schrieb Andrey Grodzovsky:
Also reject TDRs if another one already running.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 94
https://bugs.freedesktop.org/show_bug.cgi?id=109692
--- Comment #31 from Andrey Grodzovsky ---
(In reply to mikhail.v.gavrilov from comment #30)
> Created attachment 143908 [details]
> dmesg without patches
>
> Without patches backtrace are looks like initial deadlock backtrace.
OK, seems the p
On 4/10/19 10:06 AM, Christian König wrote:
> Am 09.04.19 um 18:42 schrieb Grodzovsky, Andrey:
>> On 4/9/19 10:50 AM, Christian König wrote:
>>> Am 08.04.19 um 18:08 schrieb Andrey Grodzovsky:
Also reject TDRs if another one already running.
Signed-off-by: Andrey Grodzovsky
--
On Wed, Apr 10, 2019 at 09:01:28AM -0500, Rob Herring wrote:
> On Mon, Apr 08, 2019 at 10:11:26AM +0200, Maxime Ripard wrote:
> > On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote:
> > > On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> > > > Hi,
> > > >
> > > > We've had f
Am 10.04.19 um 16:28 schrieb Grodzovsky, Andrey:
On 4/10/19 10:06 AM, Christian König wrote:
Am 09.04.19 um 18:42 schrieb Grodzovsky, Andrey:
On 4/9/19 10:50 AM, Christian König wrote:
Am 08.04.19 um 18:08 schrieb Andrey Grodzovsky:
Also reject TDRs if another one already running.
Signed-off
Hi Christoph,
Am Mittwoch, 10. April 2019, 16:10:44 CEST schrieb Christoph Muellner:
> On our RK3399-Q7 EVK base board we have the option to connect an arbitrary
> monitor via DP cable. The actual monitor is therefore not known in advance.
> This means, we don't have any panel information besides
Generated using make headers_install from the drm-next
tree - git://anongit.freedesktop.org/drm/drm
branch - drm-next
commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
The changes were as follows :-
core: (drm.h, drm_fourcc.h, drm_mode.h)
- Added 'struct drm_syncobj_transfer', 'struct drm_syncobj
On 4/10/19 10:41 AM, Christian König wrote:
> Am 10.04.19 um 16:28 schrieb Grodzovsky, Andrey:
>> On 4/10/19 10:06 AM, Christian König wrote:
>>> Am 09.04.19 um 18:42 schrieb Grodzovsky, Andrey:
On 4/9/19 10:50 AM, Christian König wrote:
> Am 08.04.19 um 18:08 schrieb Andrey Grodzovsky:
>
Am 10.04.19 um 17:05 schrieb Grodzovsky, Andrey:
> On 4/10/19 10:41 AM, Christian König wrote:
>> Am 10.04.19 um 16:28 schrieb Grodzovsky, Andrey:
>>> On 4/10/19 10:06 AM, Christian König wrote:
Am 09.04.19 um 18:42 schrieb Grodzovsky, Andrey:
> On 4/9/19 10:50 AM, Christian König wrote:
>
Generated using make headers_install from the drm-next
tree - git://anongit.freedesktop.org/drm/drm
branch - drm-next
commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
The changes were as follows :-
core: (drm.h, drm_fourcc.h, drm_mode.h)
- Added 'struct drm_syncobj_transfer', 'struct drm_syncobj
On Wed, Apr 10, 2019 at 03:23:27PM +0100, Ian Jackson wrote:
> From: Wei Liu
>
> Empirically, on stretch armhf:
>
> drivers/gpu/host1x/cdma.c: In function `host1x_pushbuffer_init':
> drivers/gpu/host1x/cdma.c:94:48: error: passing argument 3 of
> `dma_alloc_wc' from incompatible pointer typ
On Wed, Apr 10, 2019 at 01:20:44PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> >Of Ville
> >Syrjälä
> >Sent: Monday, April 8, 2019 9:38 PM
> >To: Shankar, Uma
> >Cc: dcasta...@chromium.org; intel-..
https://bugs.freedesktop.org/show_bug.cgi?id=109607
--- Comment #10 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- fi-kbl-7560u fi-icl-u2, fi-icl-u3: random tests - incomplete -}
{+ fi-kbl-7560u fi-icl-u2, fi-icl-u3: random tests - incomplete +}
New failures
https://bugs.freedesktop.org/show_bug.cgi?id=110360
Alex Deucher changed:
What|Removed |Added
Attachment #143916|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=110360
Alex Deucher changed:
What|Removed |Added
See Also||https://bugzilla.kernel.org
On Tue, Apr 09, 2019 at 03:08:55PM -0700, Andrew Morton wrote:
> On Tue, 26 Mar 2019 12:47:39 -0400 jgli...@redhat.com wrote:
>
> > From: Jérôme Glisse
> >
> > (Andrew this apply on top of my HMM patchset as otherwise you will have
> > conflict with changes to mm/hmm.c)
> >
> > Changes since v
On Thu, Apr 04, 2019 at 12:04:11AM +0800, Wen Yang wrote:
> The call to of_get_child_by_name returns a node pointer with refcount
> incremented thus it must be explicitly decremented after the last
> usage.
>
> Detected by coccinelle with the following warnings:
> drivers/gpu/drm/msm/adreno/a5xx_g
On Wed, Apr 10, 2019 at 01:48:51PM +0200, Maarten Lankhorst wrote:
> Op 10-04-2019 om 13:11 schreef Ben Davis:
> > Add new properties to specify width and height for writeback.
> >
> > Signed-off-by: Ben Davis
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 8
> > drivers/gpu/drm/drm_wr
Op 10-04-2019 om 18:46 schreef Ben Davis:
> On Wed, Apr 10, 2019 at 01:48:51PM +0200, Maarten Lankhorst wrote:
>> Op 10-04-2019 om 13:11 schreef Ben Davis:
>>> Add new properties to specify width and height for writeback.
>>>
>>> Signed-off-by: Ben Davis
>>> ---
>>> drivers/gpu/drm/drm_atomic_uap
Add CONFIG_DRM_MSM_GPU_STATE to conditionally compile Adreno GPU state
code depending on the availability of the dependencies.
Reported-by: Hulk Robot
Reported-by: YueHaibing
Fixes: 1707add81551 ("drm/msm/a6xx: Add a6xx gpu state")
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/Kconfig
On Thu, Apr 04, 2019 at 10:02:07AM +0800, YueHaibing wrote:
> On 2019/4/3 23:36, Jordan Crouse wrote:
> > On Wed, Apr 03, 2019 at 02:48:11PM +0800, Yue Haibing wrote:
> >> From: YueHaibing
> >>
> >> When building CONFIG_DEBUG_FS is not set
> >> gcc warn this:
> >>
> >> drivers/gpu/drm/msm/adreno/a
https://bugs.freedesktop.org/show_bug.cgi?id=110370
--- Comment #2 from andrew.m.mcma...@gmail.com ---
I don't seem to suffer with poor performance even on an obsolete Phenom II x4
955. But now that you've mentioned when I notice a very slight bit of this
shimmering effect on my R9 285, admittedly
Hi Dave, Daniel,
A few fixes for 5.1:
- Cursor fixes
- Add missing picasso pci id to KFD
- XGMI fix
- Shadow buffer handling fix for GPU reset
The following changes since commit d939f44d4a7f910755165458da20407d2139f581:
drm/amdgpu: remove unnecessary rlc reset function on gfx9 (2019-04-02
16:
https://bugs.freedesktop.org/show_bug.cgi?id=109692
--- Comment #32 from Andrey Grodzovsky ---
(In reply to mikhail.v.gavrilov from comment #30)
> Created attachment 143908 [details]
> dmesg without patches
>
> Without patches backtrace are looks like initial deadlock backtrace.
Can you please
Hi Da.*,
Another week, another PR. A bit less to digest this week from last, but still
very dense when looking at LoC/patch.
drm-misc-next-2019-04-10:
drm-misc-next for 5.2:
UAPI Changes:
- None
Cross-subsystem Changes:
-MAINTAINERS: Add moderation flag for lima mailing list (Randy)
-dt-bindin
https://bugs.freedesktop.org/show_bug.cgi?id=109692
--- Comment #33 from Andrey Grodzovsky ---
Another thing - I noted a regression in existing driver code - can you manually
apply this patch and test ?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7c8930d9e8b188c
https://bugs.freedesktop.org/show_bug.cgi?id=109692
--- Comment #34 from Andrey Grodzovsky ---
(In reply to Andrey Grodzovsky from comment #33)
> Another thing - I noted a regression in existing driver code - can you
> manually apply this patch and test ?
> https://git.kernel.org/pub/scm/linux/ke
Hi Gerd.
>
> #include
>
> @@ -69,9 +70,8 @@ struct bochs_device {
> struct edid *edid;
>
> /* drm */
> - struct drm_device *dev;
> - struct drm_crtc crtc;
> - struct drm_encoder encoder;
> + struct drm_device *dev;
> + struct drm_simple_display_pipe pipe;
>
On Wed, 10 Apr 2019 at 06:23, Lyude Paul wrote:
>
> For a while, we've had the problem of i2c bus access not grabbing
> a runtime PM ref when it's being used in userspace by i2c-dev, resulting
> in nouveau spamming the kernel log with errors if anything attempts to
> access the i2c bus while the G
In case the IOMMU API is not available compiling host1x fails with
the following error:
In file included from drivers/gpu/host1x/hw/host1x06.c:27:
drivers/gpu/host1x/hw/channel_hw.c: In function ‘host1x_channel_set_streamid’:
drivers/gpu/host1x/hw/channel_hw.c:118:30: error: implicit declarat
https://bugs.freedesktop.org/show_bug.cgi?id=110293
djip.per...@free.fr changed:
What|Removed |Added
Priority|medium |high
Severity|normal
On Tue, Mar 26, 2019 at 12:47:46PM -0400, Jerome Glisse wrote:
> From: Jérôme Glisse
>
> CPU page table update can happens for many reasons, not only as a result
> of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
> as a result of kernel activities (memory compression, reclai
1 - 100 of 129 matches
Mail list logo
