[PATCH v2] drm/vc4: Enable selection in Kconfig on any 32-bit BCM platform.

With the Cygnus port, we needed to add at least "|| ARCH_BCM_CYGNUS" to let the module get built on a cygnus-only kernel. However, I anticipate having a port for Kona soon, so just present the module on all of BCM. v2: Keep allowing selection with ARCH_BCM2835, since ARCH_BCM doesn't exist

[RFC] drm: add unref_fb ioctl

Similar to rmfb but does not have the side effect of shutting down any pipes that are scanning out the fb. Advantages compared to rmfb: * slightly easier userspace, it doesn't have to track fb-id's until they come of the screen * it might be desirable to keep existing layers on screen

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

https://bugs.freedesktop.org/show_bug.cgi?id=100919 --- Comment #5 from Harry Wentland --- Nikola, this line from the patch should take care of your concern: + if (dc_is_dvi_signal(stream->signal) && Other signal types shouldn't be affected. -- You are receiving

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

https://bugs.freedesktop.org/show_bug.cgi?id=100919 Harry Wentland changed: What|Removed |Added Attachment #131276|0 |1 is

[Bug 100618] Dead Island crash after starting a new game

https://bugs.freedesktop.org/show_bug.cgi?id=100618 at...@t-online.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

amdgpu display corruption and hang on AMD A10-9620P

Hi, We are working with new laptops that have the AMD Bristol Ridge chipset with this SoC: AMD A10-9620P RADEON R5, 10 COMPUTE CORES 4C+6G I think this is the Bristol Ridge chipset. During boot, the display becomes unusable at the point where the amdgpu driver loads. You can see at least two

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

https://bugs.freedesktop.org/show_bug.cgi?id=100919 --- Comment #4 from Nikola Forró --- Comment on attachment 131276 --> https://bugs.freedesktop.org/attachment.cgi?id=131276 Patch to fix this (hopefully) Review of attachment 131276:

Re: [PATCH] tinydrm: mipi-dbi: Use seq_putc() in mipi_dbi_debugfs_command_show()

Den 08.05.2017 13.54, skrev SF Markus Elfring: From: Markus Elfring Date: Mon, 8 May 2017 13:42:03 +0200 A single character (line break) should be put into a sequence. Thus use the corresponding function "seq_putc". This issue was detected by using the

Re: [PATCH v2 0/3] drm/amd/display: add HDMI Stereo 3D support

Series is Reviewed-by: Harry Wentland Harry On 2017-05-08 12:35 PM, Jeff Smith wrote: Changes: I have broken one patch into three. Note: this only covers the display (not amdgpu) portion and does not include the code to make it work over the card's DVI port. I

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

https://bugs.freedesktop.org/show_bug.cgi?id=100919 --- Comment #6 from Alex Deucher --- what about the else case? Shouldn't the logic be: if (dc_is_dvi_signal(stream->signal)) { if (stream->public.timing.pix_clk_khz >

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

https://bugs.freedesktop.org/show_bug.cgi?id=100919 --- Comment #7 from Nikola Forró --- Hi Alex, yes, that's exactly what I meant. Sorry for not being clear. Nikola -- You are receiving this mail because: You are the assignee for the

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

https://bugs.freedesktop.org/show_bug.cgi?id=100919 --- Comment #9 from Nikola Forró --- Thanks Harry, I've just tested the patch and I can confirm it fixes the problem. -- You are receiving this mail because: You are the assignee for the

Re: [PATCHv2 0/3] Intel FPGA VIP Frame Buffer II DRM Driver

"Ong, Hean Loong" writes: > On Mon, 2017-05-08 at 09:03 -0700, Eric Anholt wrote: >> "Ong, Hean Loong" writes: >> >> > >> > On Thu, 2017-05-04 at 10:11 -0700, Eric Anholt wrote: >> > > >> > > "Ong, Hean Loong"

Re: [PATCH] drm/msm: gpu: Enable zap shader for A5XX

Hi Jordan, [auto build test ERROR on robclark/msm-next] [also build test ERROR on v4.11 next-20170509] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jordan-Crouse/drm-msm-gpu-Enable-zap-shader

Re: [PATCH 1/6] drm/omap: add new connector types

On 08/05/17 19:21, Laurent Pinchart wrote: > Hi Tomi, > > On Monday 08 May 2017 17:35:50 Tomi Valkeinen wrote: >> On 08/05/17 17:21, Laurent Pinchart wrote: >>> On Thursday 27 Apr 2017 13:27:49 Tomi Valkeinen wrote: We have been using DRM_MODE_CONNECTOR_Unknown for many of our outputs

[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

https://bugs.freedesktop.org/show_bug.cgi?id=99553 --- Comment #10 from M. Edward (Ed) Borasky --- clpeak - various symptoms over the past months but now a solid crash: https://bugzilla.redhat.com/show_bug.cgi?id=1433632 https://github.com/krrishnarraj/clpeak/issues/32

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

On Mon, 08 May 2017 08:29:30 -0700 Keith Packard wrote: > Pekka Paalanen writes: > > > Thinking again, I believe we have to have a way to override > > database entries somehow. If we ship catch-all entries for, say, > > all Sony TVs, we are bound to get

Re: [linux-sunxi] [PATCH v6 11/13] ARM: dts: sun8i: add DE2 nodes for V3s SoC

1;4601;0c On Fri, May 05, 2017 at 08:34:16PM +0800, Icenowy Zheng wrote: > > > 于 2017年5月5日 GMT+08:00 下午8:30:35, Maxime Ripard > 写到: > >On Fri, May 05, 2017 at 04:53:43PM +0800, icen...@aosc.io wrote: > >> > > + de2_clocks: clock@100 { > >> >

Re: [PATCH v6 08/13] drm/sun4i: add support for Allwinner DE2 mixers

On Fri, May 05, 2017 at 08:39:31PM +0800, Icenowy Zheng wrote: > >> > > + /* Set base coordinates */ > >> > > + DRM_DEBUG_DRIVER("Layer coordinates X: %d Y: %d\n", > >> > > + state->crtc_x, state->crtc_y); > >> > > + regmap_write(mixer->engine.regs, > >> > > +

Re: [PATCH v2] drm/pl111: Register the clock divider and use it.

Linus Walleij writes: > On Mon, May 8, 2017 at 9:33 PM, Eric Anholt wrote: > >> This is required for the panel to work on bcm911360, where CLCDCLK is >> the fixed 200Mhz AXI41 clock. The rate set is still passed up to the >> CLCDCLK, for platforms

Re: [PATCH] tinydrm: mipi-dbi: Use seq_putc() in mipi_dbi_debugfs_command_show()

On Tue, 2017-05-09 at 19:29 +0200, Noralf Trønnes wrote: > Den 08.05.2017 13.54, skrev SF Markus Elfring: > > A single character (line break) should be put into a sequence. > > Thus use the corresponding function "seq_putc". Markus, I know this is hard for you, but think more before sending

Re: [PATCH] gpu: drm: amd: amdgpu: remove dead code

On 2017-05-09 08:53 AM, Alex Deucher wrote: On Mon, May 8, 2017 at 1:01 PM, Gustavo A. R. Silva wrote: Local variable use_doorbell is assigned to a constant value and it is never updated again. Remove this variable and the dead code it guards. Addresses-Coverity-ID:

Re: [PATCH] drm/vgem: Convert to a struct drm_device subclass

On 05/08/2017 06:22 AM, Chris Wilson wrote: With Laura's introduction of the fake platform device for importing dmabuf, we add a second static that is logically tied to the vgem_device. Convert vgem over to using the struct drm_device subclassing, so that the platform device is stored inside its

RE: amdgpu display corruption and hang on AMD A10-9620P

> -Original Message- > From: Daniel Drake [mailto:dr...@endlessm.com] > Sent: Tuesday, May 09, 2017 12:55 PM > To: dri-devel; amd-...@lists.freedesktop.org; Deucher, Alexander > Cc: Chris Chiu; Linux Upstreaming Team > Subject: amdgpu display corruption and hang on AMD A10-9620P > > Hi, >

[Bug 100618] Dead Island crash after starting a new game

https://bugs.freedesktop.org/show_bug.cgi?id=100618 --- Comment #14 from John Brooks --- (In reply to at46n from comment #13) > Seems like its a glsl compiler bug and not a radeonsi bug. With "prlimit > --pid PIDofDeadIsland -n65535" I am able to start and play

Re: Soliciting DRM feedback on latest DC rework

On 2017-05-09 04:24 AM, Daniel Vetter wrote: On Mon, May 08, 2017 at 02:54:22PM -0400, Harry Wentland wrote: Hi Daniel, Thanks for taking the time to look at DC. I had a couple more questions/comments in regard to the patch you posted on IRC: http://paste.debian.net/plain/930704 My

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

https://bugs.freedesktop.org/show_bug.cgi?id=100979 --- Comment #1 from Przemek --- Created attachment 131281 --> https://bugs.freedesktop.org/attachment.cgi?id=131281=edit system log after clean boot -- You are receiving this mail because: You are the assignee for the

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

https://bugs.freedesktop.org/show_bug.cgi?id=100979 --- Comment #4 from Przemek --- Created attachment 131284 --> https://bugs.freedesktop.org/attachment.cgi?id=131284=edit system log after first suspend -- You are receiving this mail because: You are the assignee for the

Re: [PATCH v2 07/28] drm: omapdrm: dpi: Remove platform driver

Hi Tomi, On Tuesday 09 May 2017 12:06:58 Tomi Valkeinen wrote: > On 08/05/17 14:32, Laurent Pinchart wrote: > > No device is ever registered that binds with the driver, the DPI port is > > handled manually. Remove the DPI platform driver. > > You could add a bit more details: the DPI platform

Re: [PATCH v2 22/28] drm: omapdrm: Move shutdown() handler from core to dss

Hi Tomi, On Tuesday 09 May 2017 14:38:39 Tomi Valkeinen wrote: > On 08/05/17 14:32, Laurent Pinchart wrote: > > In preparation for removal of the core module, move the shutdown() > > handler from core to dss. > > > > Signed-off-by: Laurent Pinchart > > --- > >

Re: [PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code

Hi Tomi, On Tuesday 09 May 2017 15:10:40 Tomi Valkeinen wrote: > On 08/05/17 14:32, Laurent Pinchart wrote: > > Hello, > > > > This patch series is a second, extended version of the code previously > > posted as "[PATCH/RFC 0/7] Remove the omapdrm device from platform code". > As this is a long

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

https://bugs.freedesktop.org/show_bug.cgi?id=100979 --- Comment #2 from Przemek --- Created attachment 131282 --> https://bugs.freedesktop.org/attachment.cgi?id=131282=edit system log after performing hibernate -- You are receiving this mail because: You are the assignee

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

https://bugs.freedesktop.org/show_bug.cgi?id=100979 --- Comment #3 from Przemek --- Created attachment 131283 --> https://bugs.freedesktop.org/attachment.cgi?id=131283=edit kernel config file -- You are receiving this mail because: You are the assignee for the

Re: [PATCH v2 10/28] drm: omapdrm: dsi: Handle pin muxing internally

Hi Tomi, On Tuesday 09 May 2017 12:37:36 Tomi Valkeinen wrote: > On 08/05/17 14:32, Laurent Pinchart wrote: > > Don't rely on callback functions provided by the platform, but access > > the syscon internally to mux the DSI pins. > > > > Signed-off-by: Laurent Pinchart

Re: [PATCH v2 11/28] drm: omapdrm: dss: Select features based on compatible string

Hi Tomi, On Tuesday 09 May 2017 12:41:26 Tomi Valkeinen wrote: > On 08/05/17 14:32, Laurent Pinchart wrote: > > Use the compatible string instead of the OMAP SoC revision to determine > > device features. The various OMAP3-based SoCs can be told apart from the > > compatible string, use

Re: [PATCH v2 13/28] drm: omapdrm: dss: Initialize DSS internal features at probe time

Hi Tomi, On Tuesday 09 May 2017 12:48:57 Tomi Valkeinen wrote: > On 08/05/17 14:32, Laurent Pinchart wrote: > > The DSS internal features are derived from the platform device > > compatible string which is available at probe time. Don't delay > > initialization until bind time. This prepares for

Re: [PATCH v2 23/28] drm: omapdrm: Merge the dss_features and omap_dss_features structures

Hi Tomi, On Tuesday 09 May 2017 15:02:36 Tomi Valkeinen wrote: > On 08/05/17 14:32, Laurent Pinchart wrote: > > Both structures describe features of a particular OMAP DSS version, > > there's no reason to keep them separate. Merge them together, allowing > > initialization of the features based

[Bug 100306] System randomly freezes or crashes to the login screen, glitches until rebooted

https://bugs.freedesktop.org/show_bug.cgi?id=100306 --- Comment #20 from MirceaKitsune --- The same freeze happened again today, after a two week period of not seeing the problem any more. This is reaching the point where it's becoming outright ridiculous:

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

https://bugs.freedesktop.org/show_bug.cgi?id=100979 Bug ID: 100979 Summary: Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend Product: DRI Version: DRI git Hardware: x86-64 (AMD64)

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

https://bugs.freedesktop.org/show_bug.cgi?id=100979 --- Comment #5 from Przemek --- Created attachment 131285 --> https://bugs.freedesktop.org/attachment.cgi?id=131285=edit system log after second suspend and hard lockup -- You are receiving this mail because: You are the

Re: [PATCH 1/5] drm: introduce sync objects

On Mon, May 8, 2017 at 7:26 PM, Dave Airlie wrote: > On 4 May 2017 at 18:16, Chris Wilson wrote: > > On Wed, Apr 26, 2017 at 01:28:29PM +1000, Dave Airlie wrote: > >> +#include > > > > I wonder if Daniel has already split everything used here into

Re: [PATCH 1/2] drm/omap: add omap_gem_put_paddr_locked()

On 05/08/17 11:51, Tomi Valkeinen wrote: > Add omap_gem_put_paddr_locked() which is a version of > omap_gem_put_paddr() that expects the caller to hold the struct_mutex. > > Signed-off-by: Tomi Valkeinen Looks trivial enough. Reviewed-by: Jyri Sarha >

Re: PROBLEM: EDID regression results in color banding on Lenovo G50 series laptops [fix proposition]

On Mon, 08 May 2017, Tomasz Papież wrote: > Since the introduction of kernel 4.8 I've been experiencing color > banding on my Lenovo G50-80 notebook. I also had reports of the same > symptoms on the G50-70 model. > > I figured out that the problem had been introduced by commit

Re: [PATCH v2 02/28] drm: omapdrm: Drop support for non-DT devices

Hi Tomi, On Tuesday 09 May 2017 11:40:01 Tomi Valkeinen wrote: > On 08/05/17 14:32, Laurent Pinchart wrote: > > All OMAP platforms use DT nowadays, drop support for non-DT devices. > > > > Signed-off-by: Laurent Pinchart > > --- > > > >

Re: [PATCH v2 02/28] drm: omapdrm: Drop support for non-DT devices

On 08/05/17 14:32, Laurent Pinchart wrote: > All OMAP platforms use DT nowadays, drop support for non-DT devices. > > Signed-off-by: Laurent Pinchart > --- > drivers/gpu/drm/omapdrm/dss/display.c | 19 ++- > drivers/gpu/drm/omapdrm/dss/dsi.c | 93 >

RE: [PATCH v2 0/2] rcar-du, vsp1: rcar-gen3: Add support for colorkey alpha blending

Hello Daniel, Eric, On Mon, Monday, May 8, 2017 9:29 PM +0200, Daniel Vetter wrote: > -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > Vetter > Sent: 8 mai 2017 21:30 > To: Eric Anholt > Cc: Gheorghe, Alexandru

Re: [PATCH 3/6] drm/omap: remove ovl_set_channel_out

On 08/05/17 17:26, Laurent Pinchart wrote: > Hi Tomi, > > Thank you for the patch. > > On Thursday 27 Apr 2017 13:27:51 Tomi Valkeinen wrote: >> At the moment we have ovl_set_channel_out() to configure the output >> channel of an overlay. It makes sense to have this configuration as part >> of

Re: [PATCH v3 0/6] omapdrm: fences and zpos

On 09/05/17 01:27, Laurent Pinchart wrote: > Hello, > > This patch series is the third version of the omapdrm fences and zpos support. > It contains two completely unrelated features that just happen to have been > developed one right after the other. Thanks, looks good. I'll apply this series.

Re: [PATCH 1/6 v2] drm/omap: add new connector types

On 09/05/17 10:36, Jyri Sarha wrote: > On 05/09/17 10:16, Tomi Valkeinen wrote: >> We have been using DRM_MODE_CONNECTOR_Unknown for many of our outputs >> because there has not been a proper connector type for them. >> >> We now have connector type for DPI so let's take it into use. At the >>

Re: GPU-DRM-STI: Fine-tuning for some function implementations

2017-05-06 19:00 GMT+02:00 SF Markus Elfring : >>> 1. I suggest to combine a few functions into fewer ones. >>>* Do you spot any programming mistakes in these concrete cases? >> >> Not in the patches I skimmed. > > Thanks for such feedback. > > >> However, your

Re: [PATCH v2 00/10] omapdrm: GEM objects fixes

On 21/04/17 00:33, Laurent Pinchart wrote: > Hello, > > This patch series updates and extends the previously posted "[PATCH 1/7] > omapdrm: Fix GEM objects DMA unmapping" series. Thanks, I have applied this series (with the PATCH v2.1 10/10). Tomi signature.asc Description: OpenPGP digital

Re: [PATCH 03/11] drm: parse ycbcr 420 vdb block

Regards Shashank On 5/8/2017 10:39 PM, Ville Syrjälä wrote: On Mon, May 08, 2017 at 10:11:53PM +0530, Sharma, Shashank wrote: Regards Shashank On 5/8/2017 9:54 PM, Ville Syrjälä wrote: On Fri, Apr 07, 2017 at 07:39:20PM +0300, Shashank Sharma wrote: From: Jose Abreu

Re: [PATCH v2 03/28] drm: omapdrm: Remove unused dss_get_core_pdev() function

On 08/05/17 14:32, Laurent Pinchart wrote: > The dss_get_core_pdev() function is unused, remove it. > > Signed-off-by: Laurent Pinchart > --- > drivers/gpu/drm/omapdrm/dss/core.c | 5 - > drivers/gpu/drm/omapdrm/dss/dss.h | 1 - > 2 files changed, 6

Re: [PATCH v2 06/28] drm: omapdrm: dispc: Select features based on compatible string

On 08/05/17 14:32, Laurent Pinchart wrote: > Use the compatible string instead of the OMAP SoC revision to determine > device features. On OMAP34xx the features depend on the ES revision that > can not be determined from the compatible string. Use soc_device_match() > in that case. > >

Re: [PATCH v2 08/28] drm: omapdrm: dpi: Replace OMAP SoC model checks with DSS device type

On 08/05/17 14:32, Laurent Pinchart wrote: > The DPI code only needs to differentiate between major OMAP revisions, > which can be obtained from the DSS compatible string. Replace the OMAP > SoC model checks to prepare for removal of the OMAP SoC version platform > data. > > Signed-off-by:

Re: [PATCH v2 01/28] drm: omapdrm: Remove duplicate error messages when mapping memory

On 08/05/17 16:55, Laurent Pinchart wrote: > Hi Tomi, > > On Monday 08 May 2017 15:52:07 Tomi Valkeinen wrote: >> On 08/05/17 14:32, Laurent Pinchart wrote: >>> The devm_ioremap_resource() call can handle being given a NULL resource, >>> and prints an error message when mapping fails. Switch

Re: [PATCH v2 26/28] ARM: OMAP2+: Remove unused omapdrm platform device

Hi Tony, On Monday 08 May 2017 10:09:06 Tony Lindgren wrote: > * Laurent Pinchart [170508 04:36]: > > The omapdrm platform device is unused, as a replacement is now > > registered in the omapdss driver. Remove it. > > > > Signed-off-by: Laurent Pinchart

Re: [PATCH v2 07/28] drm: omapdrm: dpi: Remove platform driver

On 08/05/17 14:32, Laurent Pinchart wrote: > No device is ever registered that binds with the driver, the DPI port is > handled manually. Remove the DPI platform driver. You could add a bit more details: the DPI platform device was used for non-DT booting, which can now be removed. >

[PATCH 1/6 v2] drm/omap: add new connector types

We have been using DRM_MODE_CONNECTOR_Unknown for many of our outputs because there has not been a proper connector type for them. We now have connector type for DPI so let's take it into use. At the same time, add better connector types for the remaining outputs too. This patch sets the

Re: [PATCH 1/6 v2] drm/omap: add new connector types

On 05/09/17 10:16, Tomi Valkeinen wrote: > We have been using DRM_MODE_CONNECTOR_Unknown for many of our outputs > because there has not been a proper connector type for them. > > We now have connector type for DPI so let's take it into use. At the > same time, add better connector types for the

Re: [PATCH 04/11] drm: parse ycbcr420 vcb block

Regards Shashank On 5/8/2017 10:28 PM, Ville Syrjälä wrote: On Fri, Apr 07, 2017 at 07:39:21PM +0300, Shashank Sharma wrote: HDMI 2.0 spec adds support for ycbcr420 subsampled output. CEA-861-F adds two new blocks in EDID, to provide information about sink's support for ycbcr420 output. One

Re: Soliciting DRM feedback on latest DC rework

On Mon, May 08, 2017 at 03:50:36PM -0400, Harry Wentland wrote: > > > On 2017-05-08 03:07 PM, Dave Airlie wrote: > > On 9 May 2017 at 04:54, Harry Wentland wrote: > > > Hi Daniel, > > > > > > Thanks for taking the time to look at DC. > > > > > > I had a couple more

Re: Soliciting DRM feedback on latest DC rework

On Mon, May 08, 2017 at 02:54:22PM -0400, Harry Wentland wrote: > Hi Daniel, > > Thanks for taking the time to look at DC. > > I had a couple more questions/comments in regard to the patch you posted on > IRC: http://paste.debian.net/plain/930704 > > My impression is that this item is the most

Re: [PATCH v2 04/28] drm: omapdrm: Remove unused default display name support

On 08/05/17 14:32, Laurent Pinchart wrote: > The default display name is both unused and never set by platform data. > Remove default display name module parameter, platform data field and > runtime infrastructure. > > Signed-off-by: Laurent Pinchart > --- >

Re: [PATCH v2 05/28] drm: omapdrm: Infer the OMAP version from the SoC family

On 08/05/17 14:32, Laurent Pinchart wrote: > The omapdrm exposes the SoC version to userspace through an integer that > contains the OMAP model (e.g. 0x3430 for the OMAP3430). This is an > unfortunate choice of userspace API as it's both conceptually wrong > (userspace nowadays should use

Re: [PATCH 1/5] drm: introduce sync objects

On Tue, May 09, 2017 at 12:26:34PM +1000, Dave Airlie wrote: > On 4 May 2017 at 18:16, Chris Wilson wrote: > > On Wed, Apr 26, 2017 at 01:28:29PM +1000, Dave Airlie wrote: > >> +#include > > > > I wonder if Daniel has already split everything used here into its own > >

[PATCH] drm: mediatek: change the variable type of rdma threshold

For some greater resolution, the rdma threshold variable will overflow. Signed-off-by: Bibby Hsieh --- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c

[Bug 99029] VCE VAAPI segfault using ffmpeg

https://bugs.freedesktop.org/show_bug.cgi?id=99029 --- Comment #3 from Andy Furniss --- Hmm, I haven't tested yet, but if you hit the division by zero, I guess there is something special about thet file (or ffmpeg/something changed since I last looked). Before reading your

Re: [PATCH v2 08/28] drm: omapdrm: dpi: Replace OMAP SoC model checks with DSS device type

Hi Tomi, On Wednesday 10 May 2017 01:24:52 Laurent Pinchart wrote: > On Tuesday 09 May 2017 12:23:13 Tomi Valkeinen wrote: > > On 08/05/17 14:32, Laurent Pinchart wrote: > > > The DPI code only needs to differentiate between major OMAP revisions, > > > which can be obtained from the DSS

Re: [PATCH v2 19/28] drm: omapdrm: sdi: Remove platform driver

On 08/05/17 14:32, Laurent Pinchart wrote: > No device is ever registered that binds with the driver, the SDI port is > handled manually. Remove the SDI platform driver. Same comment here as for DPI: this was for non-DT. Other than that: Reviewed-by: Tomi Valkeinen Tomi

Re: [PATCH] gpu: drm: amd: amdgpu: remove dead code

Am 08.05.2017 um 18:41 schrieb Gustavo A. R. Silva: Local variable use_doorbell is assigned to a constant value and it is never updated again. Remove this variable and the dead code it guards. Addresses-Coverity-ID: 1401837 Signed-off-by: Gustavo A. R. Silva

Re: [PATCH v2 11/28] drm: omapdrm: dss: Select features based on compatible string

On 08/05/17 14:32, Laurent Pinchart wrote: > Use the compatible string instead of the OMAP SoC revision to determine > device features. The various OMAP3-based SoCs can be told apart from the > compatible string, use soc_device_match() to tell them apart. Here, and in a comment below, you

Re: [PATCH v2 13/28] drm: omapdrm: dss: Initialize DSS internal features at probe time

On 08/05/17 14:32, Laurent Pinchart wrote: > The DSS internal features are derived from the platform device > compatible string which is available at probe time. Don't delay > initialization until bind time. This prepares for the merge of the two > DSS features structures that will be needed

Re: [PATCH v2 15/28] drm: omapdrm: hdmi: Store PHY features in HDMI transmitter drivers

On 08/05/17 14:32, Laurent Pinchart wrote: > The HDMI PHY features are dependent on the HDMI transmitter model. The > PHY driver contains features for all supported transmitters, and selects > the appropriate features based on the OMAP SoC version. > > It makes more sense to store the features in

Re: [PATCH v2 20/28] drm: omapdrm: Don't forward set_min_bus_tput() to no-op platform code

On 08/05/17 14:32, Laurent Pinchart wrote: > The OMAP implementation of the set_min_bus_tput() API is a no-op. > There's no point in forwarding the driver calls to the platform code. > Remove the use of the related platform data callback, but keep the > internal function as a reminder that the

Re: [PATCH v2 22/28] drm: omapdrm: Move shutdown() handler from core to dss

On 08/05/17 14:32, Laurent Pinchart wrote: > In preparation for removal of the core module, move the shutdown() > handler from core to dss. > > Signed-off-by: Laurent Pinchart > --- > drivers/gpu/drm/omapdrm/dss/core.c | 20 >

Re: [PATCH v2 09/28] drm: omapdrm: dsi: Store DSI type and PLL hardware data in OF data

On 08/05/17 14:32, Laurent Pinchart wrote: > The DSI PLL hardware data and DSS channels are selected based on the > OMAP SoC model. There's no need for fine-grained model information, as > the driver only needs to differentiate between OMAP3, OMAP4 and OMAP5. > As this can be done through the DSI

Re: [PATCH v2 10/28] drm: omapdrm: dsi: Handle pin muxing internally

On 08/05/17 14:32, Laurent Pinchart wrote: > Don't rely on callback functions provided by the platform, but access > the syscon internally to mux the DSI pins. > > Signed-off-by: Laurent Pinchart > --- > drivers/gpu/drm/omapdrm/dss/core.c | 20 -- >

Re: GPU-DRM-STI: Fine-tuning for some function implementations

2017-05-09 10:03 GMT+02:00 Benjamin Gaignard : > 2017-05-06 19:00 GMT+02:00 SF Markus Elfring : 1. I suggest to combine a few functions into fewer ones. * Do you spot any programming mistakes in these concrete cases? >>> >>>

Re: [PATCH 1/1] drm/sti: use seq_puts to display a string

2017-03-31 21:25 GMT+02:00 Nicolas Iooss : > gdp_dbg_ctl() uses seq_printf() to display a color format name even > though there is no format string. When using -Wformat-string, gcc > reports the following warning: > > drivers/gpu/drm/sti/sti_gdp.c: In function

Re: [Intel-gfx] [PATCH 8/8] drm: Remove redundant NULL check during atomic plane commit

On Wed, Apr 26, 2017 at 06:44:53PM +0300, Ville Syrjälä wrote: > On Wed, Apr 26, 2017 at 04:40:13PM +0300, Imre Deak wrote: > > plane_state can't be NULL anywhere in this function, so the NULL check > > at the end is redundant, remove it. > > > > Cc: dri-devel@lists.freedesktop.org > >

Re: [RFC v2 1/2] drm/exynos: Add Picture Processor framework

Hi Emil, On 2017-05-08 15:43, Emil Velikov wrote: Hi Marek, A couple of small nitpicks from UAPI POV. Thanks for your comments! On 8 May 2017 at 10:11, Marek Szyprowski wrote: --- a/include/uapi/drm/exynos_drm.h +++ b/include/uapi/drm/exynos_drm.h +struct

Re: [PATCH v2 14/28] drm: omapdrm: hdmi: Store PHY features in PHY data structure

On 08/05/17 14:32, Laurent Pinchart wrote: > PHY features are stored in a global variable, while they should be > properties of the PHY object. As existing OMAP platforms have a single > HDMI PHY this doesn't cause any issue, but doesn't follow the driver > model. > > Move the PHY features to the

Re: [PATCH v2 21/28] drm: omapdrm: Move all debugfs code from core to dss

On 08/05/17 14:32, Laurent Pinchart wrote: > debugfs code is spread between the core and dss drivers. In preparation > for removal of the core driver, move it all to the dss driver. > > Signed-off-by: Laurent Pinchart > --- > drivers/gpu/drm/omapdrm/dss/core.c

Re: [PATCH 03/11] drm: parse ycbcr 420 vdb block

Regards Shashank On 5/9/2017 8:58 PM, Ville Syrjälä wrote: On Tue, May 09, 2017 at 02:04:55PM +0530, Sharma, Shashank wrote: Regards Shashank On 5/8/2017 10:39 PM, Ville Syrjälä wrote: On Mon, May 08, 2017 at 10:11:53PM +0530, Sharma, Shashank wrote: Regards Shashank On 5/8/2017 9:54

[Bug 100983] qupzilla

https://bugs.freedesktop.org/show_bug.cgi?id=100983 Francesco Turco changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 100984] QupZilla crashes at startup after mesa upgrade

https://bugs.freedesktop.org/show_bug.cgi?id=100984 Bug ID: 100984 Summary: QupZilla crashes at startup after mesa upgrade Product: Mesa Version: 17.1 Hardware: x86-64 (AMD64) OS: All Status: NEW

[Bug 100984] QupZilla crashes at startup after mesa upgrade

https://bugs.freedesktop.org/show_bug.cgi?id=100984 --- Comment #2 from Francesco Turco --- Created attachment 131291 --> https://bugs.freedesktop.org/attachment.cgi?id=131291=edit gdb backtrace (full version) I used the "thread apply all bt full" gdb command. -- You are

[Bug 100984] QupZilla crashes at startup after mesa upgrade

https://bugs.freedesktop.org/show_bug.cgi?id=100984 --- Comment #1 from Francesco Turco --- Created attachment 131290 --> https://bugs.freedesktop.org/attachment.cgi?id=131290=edit gdb backtrace (basic version) I used the "bt" gdb command. -- You are receiving this mail

Re: [RFC 0/4] Exynos DRM: add Picture Processor extension

Hi Everyone, On Wed, May 10, 2017 at 9:24 AM, Inki Dae wrote: > > > 2017년 04월 26일 07:21에 Sakari Ailus 이(가) 쓴 글: >> Hi Marek, >> >> On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski wrote: >>> Hi Laurent, >>> >>> On 2017-04-20 12:25, Laurent Pinchart wrote: Hi

Re: [RFC v2 0/7] drm: asynchronous atomic plane update

On Thu, Apr 27, 2017 at 12:15:12PM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > Hi, > > Second take of Asynchronous Plane Updates over Atomic. Here I looked > to msm, vc4 and i915 to identify a common pattern to create atomic helpers > for async

[PATCH 2/5] drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestamp

It's overkill to have a flag parameter which is essentially used just as a boolean. This takes care of core + adjusting drivers. Adjusting the scanout position callback is a bit harder, since radeon also supplies it's own driver-private flags in there. v2: Fixup misplaced hunks (Neil). v3:

[PATCH 1/5] drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool

There's really no reason for anything more: - Calling this while the crtc vblank stuff isn't set up is a driver bug. Those places alrready DRM_ERROR. - Calling this when the crtc is off is either a driver bug (calling drm_crtc_handle_vblank at the wrong time) or a core bug (for anything

[PATCH 4/5] drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos

If we restrict this helper to only kms drivers (which is the case) we can look up the correct mode easily ourselves. But it's a bit tricky: - All legacy drivers look at crtc->hwmode. But that is updated already at the beginning of the modeset helper, which means when we disable a pipe. Hence

[PATCH 5/5] drm/vblank: Lock down vblank->hwmode more

In the previous patch we've implemented hwmode tracking a la i915 for the vblank timestamp calculations. But that was just the basic semantics, i915 has some nice sanity checks to make sure we keep getting this right. Move them over too. v2: - WARN_ON_ONCE to avoid excessive spam (Ville) - Really

[PATCH 3/5] drm/vblank: Add FIXME comments about moving the vblank ts hooks

This is going to be a bit too much, but good to have at least a small note about where this should all head towards. Acked-by: Ville Syrjälä Reviewed-by: Neil Armstrong Signed-off-by: Daniel Vetter ---

[Bug 99029] VCE VAAPI segfault using ffmpeg

https://bugs.freedesktop.org/show_bug.cgi?id=99029 Martin Bednar changed: What|Removed |Added Version|13.0|17.1 --- Comment #2

Re: [PATCH v2] drm/vc4: Enable selection in Kconfig on any 32-bit BCM platform.

Florian Fainelli writes: > On 05/09/2017 11:15 AM, Eric Anholt wrote: >> With the Cygnus port, we needed to add at least "|| ARCH_BCM_CYGNUS" >> to let the module get built on a cygnus-only kernel. However, I >> anticipate having a port for Kona soon, so just present the

Re: [PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code

* Tomi Valkeinen [170509 04:56]: > On 08/05/17 20:07, Tony Lindgren wrote: > > * Laurent Pinchart [170508 04:36]: > >> The next step is to remove the omapdss platform driver (for the virtual > >> omapdss platform device, also known as

[PATCH v3 2/2] v4l: vsp1: Provide a writeback video device

When the VSP1 is used in an active display pipeline, the output of the WPF can supply the LIF entity directly and simultaneously write to memory. Support this functionality in the VSP1 driver, by extending the WPF source pads, and establishing a V4L2 video device node connected to the new source.

  1   2   >