[Bug 197925] [amdgpu_dc][carrizo] multiple monitor handling errors

https://bugzilla.kernel.org/show_bug.cgi?id=197925 --- Comment #5 from kwka...@gmx.com --- Half fixes #2: On first idle and resume from idle after boot, everything works. Internal monitor backlight shuts off, both screens turn back on. The second time, the internal backlight stays on upon

Re: [PATCH v3 1/5] drm/bridge/synopsys: stop clobbering drvdata

Hi Nickey, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm/drm-next] [also build test ERROR on v4.15-rc1 next-20171201] [cannot apply to rockchip/for-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

[Bug 197925] [amdgpu_dc][carrizo] multiple monitor handling errors

https://bugzilla.kernel.org/show_bug.cgi?id=197925 Miłosz Rachwał (kbz...@milek7.pl) changed: What|Removed |Added CC||kbz...@milek7.pl ---

[Bug 103829] [CI] igt@gem_busy@close-race - fail - Failed assertion: gem_bo_busy(fd, object[0].handle)

https://bugs.freedesktop.org/show_bug.cgi?id=103829 Chris Wilson changed: What|Removed |Added QA Contact|intel-gfx-bugs@lists.freede |

Re: [PATCH 0/4] Move DP phy switch to PHY driver

Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson: > Hi, > > On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong wrote: > > Hi Doug > > > > Thank you for mentioning this patch. > > > > I think the focus of the discussion is: can we put the grf control bit to > > dts.

Re: [PATCH 0/4] Move DP phy switch to PHY driver

Hi, On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong wrote: > Hi Doug > > Thank you for mentioning this patch. > > I think the focus of the discussion is: can we put the grf control bit to > dts. > > The RK3399 has 2 Type-C phy, but only one DP controller, this "uphy_dp_sel" > >

Re: [PATCH 1/1] drm/amdkfd: Do not ignore requested queue size during allocation

On 2017-11-30 06:51 PM, Jan Vesely wrote: > > It's not a userspace queue that stops. I'm using kernel dbgdev to issue > wave_resume commands. (waves are halted after executing > s_sendmsg_halt). > I bumped KFD_KERNEL_QUEUE_SIZE to 16KB to make sure all 320 resume > commads fit (otherwise I get

Re: [PATCH v2 6/8] drm/i915: Add function to output Aksv over GMBUS

On Fri, Dec 01, 2017 at 02:17:19PM -0500, Sean Paul wrote: > On Fri, Dec 1, 2017 at 2:06 PM, Ville Syrjälä > wrote: > > On Fri, Dec 01, 2017 at 12:20:28PM -0500, Sean Paul wrote: > >> Once the Aksv is available in the PCH, we need to get it on the wire to > >> the

Re: [PATCH 1/3] drm/panel: Add DT bindings for Ilitek ILI9322

On Fri, Dec 1, 2017 at 10:16 AM, Linus Walleij wrote: > This adds device tree bindings for the Ilitek ILI9322 > 320x240 TFT panel driver. > > Cc: David Lechner > Cc: Stefano Babic > Cc: Ben Dooks > Cc:

Re: [PATCH v2 6/8] drm/i915: Add function to output Aksv over GMBUS

On Fri, Dec 1, 2017 at 2:06 PM, Ville Syrjälä wrote: > On Fri, Dec 01, 2017 at 12:20:28PM -0500, Sean Paul wrote: >> Once the Aksv is available in the PCH, we need to get it on the wire to >> the receiver via DDC. The hardware doesn't allow us to read the value >>

Re: [PATCH v2 6/8] drm/i915: Add function to output Aksv over GMBUS

On Fri, Dec 01, 2017 at 12:20:28PM -0500, Sean Paul wrote: > Once the Aksv is available in the PCH, we need to get it on the wire to > the receiver via DDC. The hardware doesn't allow us to read the value > directly, so we need to tell GMBUS to source the Aksv internally and > send it to the right

Re: [PATCH v2 0/8] drm/i915: Implement HDCP

On Fri, Dec 1, 2017 at 1:47 PM, Hans Verkuil wrote: > Hi Sean, > > On 12/01/2017 06:20 PM, Sean Paul wrote: >> Ok, here's v2 of the HDCP patchset, no longer RFC since I've tackled the TODO >> list I set out in the first version (Annotated below for convenience). >> >> The big

[Bug 197925] [amdgpu_dc][carrizo] multiple monitor handling errors

https://bugzilla.kernel.org/show_bug.cgi?id=197925 --- Comment #3 from kwka...@gmx.com --- running very recent kernel, 4.15.0-rc1-00396-ga0651c7fa2c0 (as automatically labelled), with recent AMD_DC fixes. Fixes 1 - backlight now shuts off. Makes 3 worse - It put my internal monitor in a state

Re: [PATCH v2 0/8] drm/i915: Implement HDCP

Hi Sean, On 12/01/2017 06:20 PM, Sean Paul wrote: > Ok, here's v2 of the HDCP patchset, no longer RFC since I've tackled the TODO > list I set out in the first version (Annotated below for convenience). > > The big changes to take note of in v2 is locking. To account for atomic async > + > the

Re: [PATCH v4 1/3] drm/bridge/synopsys: dsi: stop clobbering drvdata

On 1 December 2017 at 08:32, Philippe CORNU wrote: > Dear Nickey, > > Many thanks for your patch. > > I am sorry to say that but you can not add my "Acked-by" to this patch > because this code is different from the "original" one from Brian (which > got my "Acked-by"). >

Re: [PATCH v1 2/2] drm/tinydrm: add driver for ILI9225 panels

(cc: Thierry) Den 01.12.2017 15.03, skrev Linus Walleij: On Wed, Nov 8, 2017 at 4:52 AM, David Lechner wrote: This adds a new driver for display panels based on the Ilitek ILI9225 controller. This was developed for a no-name panel with a red PCB that is commonly

Re: [PATCH v4 2/3] dt-bindings: display: rockchip: update DSI controller

On Fri, Dec 01, 2017 at 11:58:04AM +0800, Nickey Yang wrote: > This patch update describe panel/port links, including > unit addresses in documentation of device tree bindings > for the rockchip DSI controller based on the Synopsys > DesignWare MIPI DSI host controller. > > Signed-off-by: Nickey

Re: [PATCH v7 0/7] drm/fbdev: Panel orientation connector property support

On Saturday, November 25, 2017 08:35:46 PM Hans de Goede wrote: > Here is v7 of my series to add a "panel orientation" property to > the drm-connector for the LCD panel to let userspace know about LCD > panels which are not mounted upright, as well as detecting upside-down > panels without needing

Re: [Intel-gfx] [PATCH v2 2/8] drm/i915: Add more control to wait_for routines

On Fri, Dec 1, 2017 at 12:57 PM, Chris Wilson wrote: > Quoting Chris Wilson (2017-12-01 17:55:15) >> Quoting Sean Paul (2017-12-01 17:48:17) >> > On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson >> > wrote: >> > > The current wait_for() is a

Re: [Intel-gfx] [PATCH v2 2/8] drm/i915: Add more control to wait_for routines

Quoting Chris Wilson (2017-12-01 17:55:15) > Quoting Sean Paul (2017-12-01 17:48:17) > > On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson > > wrote: > > > The current wait_for() is a little more complicated nowadays (variable > > > W). > > > > > > > Hmm, am I based off

Re: [PATCH] drm/panel: support Innolux P097PFG panel

On 30 November 2017 at 06:13, Lin Huang wrote: > Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, > it refactor Innolux P079ZCA panel driver, let it support > multi panel, and add support P097PFG panel in this driver. > Couple of drive-by suggestions: Split the refactor

Re: [Intel-gfx] [PATCH v2 2/8] drm/i915: Add more control to wait_for routines

Quoting Sean Paul (2017-12-01 17:48:17) > On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson > wrote: > > Quoting Sean Paul (2017-12-01 17:20:24) > >> /** > >> - * _wait_for - magic (register) wait macro > >> + * __wait_for - magic wait macro > >> * > >> - * Does the

Re: [Intel-gfx] [PATCH v2 2/8] drm/i915: Add more control to wait_for routines

On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson wrote: > Quoting Sean Paul (2017-12-01 17:20:24) >> /** >> - * _wait_for - magic (register) wait macro >> + * __wait_for - magic wait macro >> * >> - * Does the right thing for modeset paths when run under kdgb or similar

Re: [Intel-gfx] [PATCH v2 2/8] drm/i915: Add more control to wait_for routines

Quoting Sean Paul (2017-12-01 17:20:24) > /** > - * _wait_for - magic (register) wait macro > + * __wait_for - magic wait macro > * > - * Does the right thing for modeset paths when run under kdgb or similar > atomic > - * contexts. Note that it's important that we check the condition again

Re: [PATCH 1/1] drm/amdkfd: Do not ignore requested queue size during allocation

DIQ is the debug interface queue. Are you running a GPU debugger? Otherwise I would not expect to even see a DIQ. Are you not seeing any compute queues in mqds? If there are no compute queues in mqds, that means your queue has been destroyed. That would explain why the read pointer is not

Re: [PATCH v3 0/4] Fixes for omapdrm on OpenPandora and GTA04

On Thursday, November 30, 2017 12:54:07 PM Tomi Valkeinen wrote: > On 28/11/17 17:48, H. Nikolaus Schaller wrote: > > Changes V3: > > * stay compatible with old DTB files which still use "toppoly" (suggested > > by Tomi Valkeinen) > > * replaced MODULE_ALIAS entries by MODULE_DEVICE_TABLE

[PATCH v2 4/8] drm: Add some HDCP related #defines

In preparation for implementing HDCP in i915, add some HDCP related register offsets and defines. The dpcd register offsets will go in drm_dp_helper.h whereas the ddc offsets along with generic HDCP stuff will get stuffed in drm_hdcp.h, which is new. Changes in v2: - drm_hdcp.h gets MIT license

[PATCH v2 3/8] drm: Add Content Protection property

This patch adds a new optional connector property to allow userspace to enable protection over the content it is displaying. This will typically be implemented by the driver using HDCP. The property is a tri-state with the following values: - OFF: Self explanatory, no content protection -

[PATCH v2 8/8] drm/i915: Implement HDCP for DisplayPort

This patch adds HDCP support for DisplayPort connectors by implementing the intel_hdcp_shim. Most of this is straightforward read/write from/to DPCD registers. One thing worth pointing out is the Aksv output bit. It wasn't easily separable like it's HDMI counterpart, so it's crammed in with the

[PATCH v2 6/8] drm/i915: Add function to output Aksv over GMBUS

Once the Aksv is available in the PCH, we need to get it on the wire to the receiver via DDC. The hardware doesn't allow us to read the value directly, so we need to tell GMBUS to source the Aksv internally and send it to the right offset on the receiver. The way we do this is to initiate an

[PATCH v2 5/8] drm/i915: Add HDCP framework + base implementation

This patch adds the framework required to add HDCP support to intel connectors. It implements Aksv loading from fuse, and parts 1/2/3 of the HDCP authentication scheme. Note that without shim implementations, this does not actually implement HDCP. That will come in subsequent patches. Changes in

[PATCH v2 7/8] drm/i915: Implement HDCP for HDMI

This patch adds HDCP support for HDMI connectors by implementing the intel_hdcp_shim. Nothing too special, just a bunch of DDC reads/writes. Changes in v2: - Rebased on drm-intel-next Signed-off-by: Sean Paul --- drivers/gpu/drm/i915/i915_reg.h | 1 +

[PATCH v2 2/8] drm/i915: Add more control to wait_for routines

This patch adds a little more control to a couple wait_for routines such that we can avoid open-coding read/wait/timeout patterns which: - need the value of the register after the wait_for - run arbitrary operation for the read portion This patch also chooses the correct sleep function (based

[PATCH v2 1/8] drm: Fix link-status kerneldoc line lengths

I'm adding some stuff below it and it's killing my editor's vibe. Changes in v2: - Added to the series Cc: Manasi Navare Acked-by: Daniel Vetter Signed-off-by: Sean Paul --- drivers/gpu/drm/drm_connector.c | 9

[PATCH v2 0/8] drm/i915: Implement HDCP

Ok, here's v2 of the HDCP patchset, no longer RFC since I've tackled the TODO list I set out in the first version (Annotated below for convenience). The big changes to take note of in v2 is locking. To account for atomic async + the property's mutability, I'm using a dedicated mutex and moved

Re: [PATCH 1/1] drm/amdkfd: Do not ignore requested queue size during allocation

To answer your questions about decoding MQDs, take a look at struct vi_mqd in drivers/gpu/drm/amd/include/vi_structs.h. What you're looking at is a binary dump of that structure, one per queue. The information in the MQD may not always be up to date, because the MQD represents an unmapped queue.

Re: [PATCH 09/27] drm/etnaviv: don't flush workqueue in etnaviv_gpu_wait_obj_inactive

Hi Russell, Am Freitag, den 01.12.2017, 16:59 + schrieb Russell King - ARM Linux: > On Fri, Dec 01, 2017 at 11:36:06AM +0100, Lucas Stach wrote: > > There is no need to synchronize with oustanding retire jobs if the object > > has gone idle. Retire jobs only ever change the object state from

Re: [PATCH 06/27] drm/etnaviv: get rid of userptr worker

Am Freitag, den 01.12.2017, 16:51 + schrieb Russell King - ARM Linux: > On Fri, Dec 01, 2017 at 05:38:51PM +0100, Philipp Zabel wrote: > > On Fri, 2017-12-01 at 11:36 +0100, Lucas Stach wrote: > > > All code paths which populate userptr BOs are fine with the > > > get_pages > > > function

Re: [PATCH 13/27] drm/etnaviv: add lockdep annotations to buffer manipulation functions

On Fri, 2017-12-01 at 11:36 +0100, Lucas Stach wrote: > When manipulating the kernel command buffer the GPU mutex must be held, as > otherwise different callers might try to replace the same part of the > buffer, wrecking havok in the GPU execution. > > Signed-off-by: Lucas Stach

Re: [PATCH 14/27] drm/etnaviv: simplify submit_create

On Fri, 2017-12-01 at 11:36 +0100, Lucas Stach wrote: > Use kzalloc so other code doesn't need to worry about uninitialized members. > Drop the non-standard GFP flags, as we really don't want to fail the submit > when under slight memory pressure. Remove one level of indentation by using > an

Re: [PATCH 12/27] drm/etnaviv: hold GPU lock while inserting END command

On Fri, 2017-12-01 at 11:36 +0100, Lucas Stach wrote: > Inserting the END command when suspending the GPU is changing the > command buffer state, which requires the GPU to be held. > > Signed-off-by: Lucas Stach Reviewed-by: Philipp Zabel

Re: [PATCH 11/27] drm/etnaviv: move workqueue to be per GPU

On Fri, 2017-12-01 at 11:36 +0100, Lucas Stach wrote: > While the etnaviv workqueue needs to be ordered, as we rely on work items > being executed in queuing order, this is only true for a single GPU. > Having a shared workqueue for all GPUs in the system limits concurrency > artificially. > >

Re: [PATCH 10/27] drm/etnaviv: remove switch_context member from etnaviv_gpu

On Fri, 2017-12-01 at 11:36 +0100, Lucas Stach wrote: > There is no need to store this in the gpu struct. MMU flushes are triggered > correctly in reaction to MMU maps and unmaps, independent of the current ctx > and required pipe switches can be infered from the current and the desired > GPU exec

Re: [PATCH 09/27] drm/etnaviv: don't flush workqueue in etnaviv_gpu_wait_obj_inactive

On Fri, 2017-12-01 at 11:36 +0100, Lucas Stach wrote: > There is no need to synchronize with oustanding retire jobs if the object > has gone idle. Retire jobs only ever change the object state from active to > idle, not the other way around. > > The IOVA put race is uncritical, as the GEM_WAIT

Re: [PATCH 07/27] drm/etnaviv: remove -EAGAIN handling from submit path

On Fri, 2017-12-01 at 11:36 +0100, Lucas Stach wrote: > Now that the userptr BO handling doesn't rely on the userspace restarting > the submit after object population, there is no need to special case the > -EAGAIN return value anymore. > > Signed-off-by: Lucas Stach

Re: [PATCH 06/27] drm/etnaviv: get rid of userptr worker

On Fri, 2017-12-01 at 11:36 +0100, Lucas Stach wrote: > All code paths which populate userptr BOs are fine with the get_pages > function taking the mmap_sem lock. This allows to get rid of the pretty > involved architecture with a worker being scheduled if the mmap_sem > needs to be taken, but

[Bug 104003] [IGT] pm_sseu@full-enable fails with assertion: gem.spinfunc

https://bugs.freedesktop.org/show_bug.cgi?id=104003 Chris Wilson changed: What|Removed |Added QA Contact|intel-gfx-bugs@lists.freede |

[PATCH 2/3] drm/panel: Add Ilitek ILI9322 driver

This adds support for the Ilitek ILI9322 QVGA (320x240) TFT panel driver. This panel driver supports serial or parallel RGB or YUV input and also ITU-T BT.656 input streams. The controller is combined with a physical panel and configured through the device tree. Cc: David Lechner

[PATCH 3/3] ARM: dts: Add TVE/TVC and ILI9322 panel to DIR-685

This adds the TVE200/TVC TV-encoder and the Ilitek ILI9322 panel to the DIR-685 device tree. This brings graphics to this funky router and it is possible to even run a console on its tiny screen. Incidentally this requires us to disable the access to the parallel (NOR) flash, as the

[PATCH 1/3] drm/panel: Add DT bindings for Ilitek ILI9322

This adds device tree bindings for the Ilitek ILI9322 320x240 TFT panel driver. Cc: David Lechner Cc: Stefano Babic Cc: Ben Dooks Cc: devicet...@vger.kernel.org Signed-off-by: Linus Walleij ---

Re: [PATCH 0/2] Move scheduler out of AMDGPU

Am Freitag, den 01.12.2017, 16:55 +0100 schrieb Christian König: > Am 01.12.2017 um 16:28 schrieb Lucas Stach: > > Hi all, > > > > so this is the first step to make the marvelous AMDGPU scheduler > > useable > > for other drivers. I have a (mostly) working prototype of Etnaviv > > using > > the

Re: [PATCH 0/2] Move scheduler out of AMDGPU

Am 01.12.2017 um 16:28 schrieb Lucas Stach: Hi all, so this is the first step to make the marvelous AMDGPU scheduler useable for other drivers. I have a (mostly) working prototype of Etnaviv using the scheduler, but those patches need to keep baking for a while. I'm sending this out as I want

Re: [PATCH] drm/etnaviv: make THERMAL selectable

On 1 December 2017 at 15:35, Lucas Stach wrote: > Hi Emil, > > Am Freitag, den 01.12.2017, 14:56 + schrieb Emil Velikov: >> Hi Philipp, >> >> On 1 December 2017 at 14:30, Philipp Zabel >> wrote: >> > Depending on THERMAL || !THERMAL caused a

Re: [PATCH] drm/etnaviv: make THERMAL selectable

Hi Emil, Am Freitag, den 01.12.2017, 14:56 + schrieb Emil Velikov: > Hi Philipp, > > On 1 December 2017 at 14:30, Philipp Zabel > wrote: > > Depending on THERMAL || !THERMAL caused a Kconfig dependency loop > > on > > x86_64: > > > >  

[PATCH 2/2] drm/sched: move fence slab handling to module init/exit

This is the only part of the scheduler which must not be called from different drivers. Move it to module init/exit so it is done a single time when loading the scheduler. Signed-off-by: Lucas Stach --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8

[PATCH 1/2] drm: move amd_gpu_scheduler into common location

This moves and renames the AMDGPU scheduler to a common location in DRM in order to facilitate re-use by other drivers. This is mostly a straight forward rename with no code changes. One notable exception is the function to_drm_sched_fence(), which is no longer a inline header function to avoid

[PATCH 0/2] Move scheduler out of AMDGPU

Hi all, so this is the first step to make the marvelous AMDGPU scheduler useable for other drivers. I have a (mostly) working prototype of Etnaviv using the scheduler, but those patches need to keep baking for a while. I'm sending this out as I want to avoid rebasing this change too much and

[Bug 103788] [DC] Screen goes blank after screen sleep and will not come back on

https://bugs.freedesktop.org/show_bug.cgi?id=103788 --- Comment #6 from Harry Wentland --- This should be fixed in Dave Airlie's drm-fixes-for-v4.15-rc2 branch. -- You are receiving this mail because: You are the assignee for the

[PATCH v3] drm/etnaviv: make THERMAL selectable

The etnaviv driver causes a link failure if it is built-in but THERMAL is built as a module: drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind': etnaviv_gpu.c:(.text+0x4c4): undefined reference to `thermal_of_cooling_device_register' etnaviv_gpu.c:(.text+0x600):

Re: [PATCH] drm/etnaviv: make THERMAL selectable

Hi Philipp, On 1 December 2017 at 14:30, Philipp Zabel wrote: > Depending on THERMAL || !THERMAL caused a Kconfig dependency loop on > x86_64: > > drivers/gpu/drm/tve200/Kconfig:1:error: recursive dependency detected! > For a resolution refer to

[PATCH v2] drm/etnaviv: make THERMAL selectable

The etnaviv driver causes a link failure if it is built-in but THERMAL is built as a module: drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind': etnaviv_gpu.c:(.text+0x4c4): undefined reference to `thermal_of_cooling_device_register' etnaviv_gpu.c:(.text+0x600):

Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()

On 30 November 2017 at 23:49, Sudip Mukherjee wrote: > Hi Daniel, > > On Wed, Nov 29, 2017 at 10:56:34AM +0100, Daniel Vetter wrote: >> On Tue, Nov 28, 2017 at 12:30:30PM +, Sudip Mukherjee wrote: >> > On Tue, Nov 28, 2017 at 12:32:38PM +0100, Greg KH wrote: >> > >

Re: linux-next: build failure after merge of the etnaviv tree

Hi Stephen, Lucas, On Thu, 2017-11-30 at 10:53 +1100, Stephen Rothwell wrote: > Hi Lucas, > > On Tue, 28 Nov 2017 11:44:46 +1100 Stephen Rothwell > wrote: > > > > After merging the etnaviv tree, today's linux-next build (x86_64 > > allmodconfig) failed like this: > > >

Re: [PATCH] drm: Fix link-status kerneldoc line lengths

On Fri, Dec 1, 2017 at 2:24 AM, Daniel Vetter wrote: > On Thu, Nov 30, 2017 at 01:22:20PM -0500, Sean Paul wrote: >> I'm adding some stuff below it and it's killing my editor's vibe. >> >> Cc: Manasi Navare >> Signed-off-by: Sean Paul

[PATCH] drm/etnaviv: make THERMAL selectable

Depending on THERMAL || !THERMAL caused a Kconfig dependency loop on x86_64: drivers/gpu/drm/tve200/Kconfig:1:error: recursive dependency detected! For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations"

[Bug 103987] [DC] drm:drm_atomic_helper_wait_for_dependencies - flip_done timed out

https://bugs.freedesktop.org/show_bug.cgi?id=103987 --- Comment #4 from Harry Wentland --- Thanks for testing. I'll queue it up for the next set of 4.15 fixes. -- You are receiving this mail because: You are the assignee for the

Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

On Fri, Dec 1, 2017 at 2:36 AM, Daniel Vetter wrote: > On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote: >> Sean, >> >> IMHO, it will good if we can have all generic hdcp1.4 authentication flow in >> drm helpers and all interested display drivers to use them. >> >>

Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

On Fri, Dec 1, 2017 at 3:36 AM, Ramalingam C wrote: > > > > On Friday 01 December 2017 01:06 PM, Daniel Vetter wrote: >> >> On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote: >>> >>> Sean, >>> >>> IMHO, it will good if we can have all generic hdcp1.4

Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

On Fri, Dec 1, 2017 at 2:36 AM, Daniel Vetter wrote: > On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote: > > Sean, > > > > IMHO, it will good if we can have all generic hdcp1.4 authentication > flow in > > drm helpers and all interested display drivers to use them. >

Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()

On Fri, Dec 01, 2017 at 08:19:16AM +0100, Daniel Vetter wrote: > On Thu, Nov 30, 2017 at 11:49:53PM +, Sudip Mukherjee wrote: > > Hi Daniel, > > > > > > > > > > > > > > > > > > Greg? > > > > > > > > > > Yes, if no one is working to get it out of staging, that means no one > > > > > cares

Re: [PATCH v1 2/2] drm/tinydrm: add driver for ILI9225 panels

On Wed, Nov 8, 2017 at 4:52 AM, David Lechner wrote: > This adds a new driver for display panels based on the Ilitek ILI9225 > controller. > > This was developed for a no-name panel with a red PCB that is commonly > marketed for Arduino. See

Re: [PATCH v2 1/4] dt-bindings: Add vendor prefix for ilitek

On Sun, Nov 19, 2017 at 9:12 PM, David Lechner wrote: > This adds the vendor prefix ilitek for ILI Technology Corporation (ILITEK). > > This prefix is already used several places and I will be adding more. > > Signed-off-by: David Lechner > --- > > v2

[PATCH 1/7] drm/omap: Use devm_kzalloc() to allocate omap_drm_private

It makes the cleanup paths a bit cleaner. Signed-off-by: Peter Ujfalusi --- drivers/gpu/drm/omapdrm/omap_drv.c | 19 +++ 1 file changed, 7 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c

[PATCH 7/7] drm/omap: Add kernel parameter to specify the desired display order

omapdrm.displays (int array) can be used to reorder the displays by id if needed. It can be also used to disable display. If the board have two active displays: 0 - LCD 1 - HDMI then: omapdrm.displays=0,1 - represents the original order (LCD, HDMI) omapdrm.displays=1,0 - represents reverse order

[PATCH 4/7] drm/omap: Separate the dssdevs array setup from the connect function

In order to ease up on the logic, break the current code to gather the dssdevs: first get all available dssdevs, then call connect on each dssdev. As the last step remove the dssdevs which failed to connect from the available dssdev list. Signed-off-by: Peter Ujfalusi ---

[PATCH 2/7] drm/omap: Allocate drm_device earlier and unref it as last step

If we allocate the drm_device earlier we can just return the error code without the need to use goto. Do the unref of the drm_device as a last step when cleaning up. This will make the drm_device available longer for us and makes sure that we only free up the memory when all other cleanups have

[PATCH 6/7] drm/omap: dss: Remove display ordering from dss/display.c

The previous patch implements the ordering of the dss_devices based on DT aliases in omap_drm.c, so there is no need to do the ordering in dss/display.c anymore. At the same time remove the alias member of the omap_dss_device struct since it is no longer needed. The only place it was used is in

[PATCH 3/7] drm/omap: Manage the usable omap_dss_device list within omap_drm_private

Instead of reaching back to DSS to iterate through the dss_devices every time, use an internal array where we store the available and usable dss_devices. At the same time remove the omapdss_device_is_connected() check from omap_modeset_init() as it became irrelevant: We are not adding dssdevs if

[PATCH 0/7] drm/omap: Module parameter for display order configuration

Hi, Changes since RFC: - Comments from Laurent have been addressed: - Get alias ID once and store it for later use in sorting - Commit message updated for 'drm/omap: Manage the usable omap_dss_device list within omap_drm_private' patch - I have kept the first patch to convert to use

[PATCH 5/7] drm/omap: Do dss_device (display) ordering in omap_drv.c

Sort the dssdev array based on DT aliases. With this change we can remove the panel ordering from dss/display.c and have all sorting related to dssdevs in one place. Signed-off-by: Peter Ujfalusi --- drivers/gpu/drm/omapdrm/dss/display.c | 2 ++

Re: [PATCH v2 0/4] DRM driver for ILI9225 display panels

Den 19.11.2017 21.12, skrev David Lechner: This is a new driver for ILI9225 based display panels. Thanks, applied to drm-misc. Noralf. v2 changes: * New patch for ilitek vendor prefix. * Use "ilitek" instead of "generic" in dt-bindings * New patch to export 2 mipi_dbi_* functions * Clean

Re: [PATCH 0/4] drm/omap: DMM: Error handling

 Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 29/09/17 14:49, Peter Ujfalusi wrote: > Hi, > > the following series adds basic error handling and reporting for the dmm/tiler > driver. > > With the error

Re: [PATCH v3 5/6] dt-bindings: add the rockchip, dual-channel for dw-mipi-dsi

On 11/30/2017 11:02 PM, Nickey Yang wrote: Hi Archit, On 2017年10月26日 12:53, Archit Taneja wrote: On 10/25/2017 09:21 AM, Nickey Yang wrote: Configure dsi slave channel when driving a panel which needs 2 DSI links. Signed-off-by: Nickey Yang ---

Re: [PATCHv1 00/14] omapdrm: DSI command mode panel support

Hi, On 24/07/17 20:32, Sebastian Reichel wrote: > Hi, > > This adds support for command mode DSI panels to > omapdrm. I tested the patches on Nokia N950 (omap3) > and Motorola Droid 4 (omap4). This is basically > PATCHv3 of my series adding N950 display support, > but I started from scratch

Re: [PATCH 00/48] omapdrm: Merge omapdrm and omapdss

Hi, On 13/10/17 17:58, Laurent Pinchart wrote: > Hello, > > This patch series merges the omapdrm and omapdss drivers into a single driver > called omapdrm. The split in two drivers was historical, in order to support > the FBDEV, V4L2 and DRM/KMS APIs. Now that the driver supports DRM/KMS only >

Re: [PATCHv1 01/14] drm/omap: remove unused function defines

On 24/07/17 20:32, Sebastian Reichel wrote: > Remove driver (un)register API defines. They do not even exist > anymore. > > Signed-off-by: Sebastian Reichel > --- > drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 --- > 1 file changed, 3 deletions(-) > > diff --git

Re: [PATCHv1 08/14] drm/omap: panel-dsi-cm: fix driver

Hi, On 24/07/17 20:33, Sebastian Reichel wrote: > From: Tony Lindgren > > This adds support for get_timings() and check_timings() > to get the driver working and properly initializes the > timing information from DT. I don't know if it matters much, but the timings added to

Re: [PATCHv1 03/14] drm/omap: plane: update fifo size on ovl setup

On 24/07/17 20:33, Sebastian Reichel wrote: > This is a workaround for a hardware bug occuring on OMAP3 > with manually updated panels. Details about the HW bug are > unknown to me, but without this fix the panel refresh does > not work at all on Nokia N950. > > Signed-off-by: Sebastian Reichel

Re: [PATCH v3 0/3] drm/omap: Support for dispc memory bandwidth limit

On 30/11/17 14:12, Peter Ujfalusi wrote: > Hi, > > Changes since v2: > - Rebased on drm-next (v2 was based on drm-next and my > 'drm/omap: Module parameter for display order configuration' series, thus it > was not applying cleanly. > - Added Acked-by from Rob to the dt-binding changes > >

[PATCH] arm64: dts: exynos: increase bus frequency for MHL chip

sii8620 supports 1MHz clock, it allows faster transmissions and according to extensive tests allows to mitigate some obscure bugs in I2C client logic of the chip. Signed-off-by: Andrzej Hajda --- arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 1 + 1 file changed, 1

Re: [PATCH 05/27] drm/etnaviv: change return type of etnaviv_gem_obj_add to void

On Fri, 2017-12-01 at 11:36 +0100, Lucas Stach wrote: > This function never fails, as it does nothing more than adding the GEM > object to the global device list. Making this explicit through the void > return type allows to drop some unnecessary error handling. > > Signed-off-by: Lucas Stach

Re: [PATCH 04/27] drm/etnaviv: fold __etnaviv_gem_new into caller

On Fri, 2017-12-01 at 11:36 +0100, Lucas Stach wrote: > This function has only one caller and it isn't expected that there will > be any more in the future. Folding this function into the caller is > helping the readability. > > Signed-off-by: Lucas Stach Reviewed-by:

Re: [PATCH 02/27] drm/etnaviv: split obj locks in different classes depending on the obj type

On Fri, 2017-12-01 at 11:35 +0100, Lucas Stach wrote: > Userptr, prime and shmem buffer objects have different lock ordering > requirements. This is mostly due to the fact that we don't allow to mmap > userptr buffers, so we won't ever end up in our fault handler for those, > so some of the code

Re: [PATCH 01/27] drm/etnaviv: fix GPU vs sync point race

On Fri, 2017-12-01 at 11:35 +0100, Lucas Stach wrote: > If the FE is restarted before the sync point event is cleared, the GPU > might trigger a completion IRQ for the next sync point before corrupting > the state of the currently running worker. I don't understand this explanation. That sounds

[PATCH] dma-buf: add some lockdep asserts to the reservation object implementation

This adds lockdep asserts to the reservation functions which state in their documentation that obj->lock must be held. Allows builds with PROVE_LOCKING enabled to check that the locking requirements are met. Signed-off-by: Lucas Stach --- drivers/dma-buf/reservation.c |

[PATCH 25/27] drm/etnaviv: move GPU active handling to bo pin/unpin

The active count is used to check if the BO is idle, where idle is defined as not active on the GPU and all VM mappings and reference counts dropped to the initial state. As the idling of the mappings and references now only happens in the submit cleanup, the active state handling must be moved to

[PATCH 26/27] drm/etnaviv: couple runtime PM management to submit object lifetime

As long as there is an active submit, we want the GPU to stay awake. This is slightly complicated by the fact that we really want to wake the GPU at the last possible moment to achieve maximum power savings. Signed-off-by: Lucas Stach ---

[PATCH 27/27] drm/etnaviv: re-enable perfmon support

Now that the PMR lifetime issues are solved we can safely re-enable performance counter profiling support. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git

[PATCH 00/27] Etnaviv job lifetime issue fixes

Hi all, this series fixes the job (submit) lifetime issues exposed by the addition of the performance counter sampling. After this series the submits are properly reference counted and cleanup is moved to one central location, which makes reasoning about the GPU submit path much easier. Lifetime

[PATCH 16/27] drm/etnaviv: rename submit fence to out_fence

This is the fence passed out on a sucessful GPU submit. Make the name more clear. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_gem.h| 2 +- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 12 ++-- drivers/gpu/drm/etnaviv/etnaviv_gpu.c

  1   2   >