Re: [PATCH] matroxfb: add Matrox MGA-G200eW board support

Hi Am 28.01.20 um 19:58 schrieb Rich Felker: > On Mon, Jan 27, 2020 at 08:36:07AM +0100, Thomas Zimmermann wrote: >> Hi >> >> Am 25.01.20 um 20:55 schrieb Rich Felker: >>> Signed-off-by: Rich Felker >>> -- >>> I've had this lying around a while and figure I should send it >>> upsteam; it's

[PULL] nouveau-fixes 5.6

Hey Dave, A couple of OOPS fixes, fixes for TU1xx if firmware isn't available, better behaviour in the face of GPU faults, and a patch to make HD audio work again after runpm changes. Ben. The following changes since commit ee8642162a9edd40daafd3fb894e3fd3f909e361: drm/nouveau: fix build

[PATCH v1 5/6] drm/msm/gpu: Add ttbr0 to the memptrs

Targets that support per-instance pagetable switching will have to keep track of which pagetable belongs to each instance to be able to recover for preemption. Signed-off-by: Jordan Crouse --- drivers/gpu/drm/msm/msm_ringbuffer.h | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v1 0/6] iommu/arm-smmu: Auxiliary domain and per instance pagetables

Some clients have a requirement to sandbox memory mappings for security and advanced features like SVM. This series adds support to enable per-instance pagetables as auxiliary domains in the arm-smmu driver and adds per-instance support for the Adreno GPU. This patchset builds on the split

[PATCH v1 3/6] drm/msm/adreno: ADd support for IOMMU auxiliary domains

Add support for creating a auxiliary domain from the IOMMU device to implement per-instance pagetables. Also add a helper function to return the pagetable base address (ttbr) and asid to the caller so that the GPU target code can set up the pagetable switch. Signed-off-by: Jordan Crouse ---

[PATCH v1 4/6] drm/msm: Add support to create target specific address spaces

Add support to create a GPU target specific address space for a context. For those targets that support per-instance pagetables they will return a new address space set up for the instance if possible otherwise just use the global device pagetable. Signed-off-by: Jordan Crouse ---

[PATCH v1 6/6] drm/msm/a6xx: Support per-instance pagetables

Add support for per-instance pagetables for a6xx targets. Add support to handle split pagetables and create a new instance if the needed IOMMU support exists and insert the necessary PM4 commands to trigger a pagetable switch at the beginning of a user command. Signed-off-by: Jordan Crouse ---

Re: [PATCH v2] dt-bindings: display: Convert etnaviv to json-schema

On Tue, Jan 28, 2020 at 1:58 PM Benjamin GAIGNARD wrote: > > > On 1/28/20 8:35 PM, Rob Herring wrote: > > On Tue, Jan 28, 2020 at 6:31 AM Benjamin GAIGNARD > > wrote: > >> > >> On 1/28/20 1:06 PM, Maxime Ripard wrote: > >>> Hi Benjamin, > >>> > >>> On Tue, Jan 28, 2020 at 09:20:13AM +0100,

[PATCH v5 0/5] iommu/arm-smmu: Split pagetable support for arm-smmu-v2

This is another iteration for the split pagetable support based on the suggestions from Robin and Will [1]. Background: In order to support per-context pagetables the GPU needs to enable split tables so that we can store global buffers in the TTBR1 space leaving the GPU free to program the TTBR0

[PATCH v5 4/5] drm/msm: Refactor address space initialization

Refactor how address space initialization works. Instead of having the address space function create the MMU object (and thus require separate but equal functions for gpummu and iommu) use a single function and pass the MMU struct in. Make the generic code cleaner by using target specific

[PATCH v5 5/5] drm/msm/a6xx: Support split pagetables

Attempt to enable split pagetables if the arm-smmu driver supports it. This will move the default address space from the default region to the address range assigned to TTBR1. The behavior should be transparent to the driver for now but it gets the default buffers out of the way when we want to

[PATCH v5 3/5] drm/msm: Attach the IOMMU device during initialization

Everywhere an IOMMU object is created by msm_gpu_create_address_space the IOMMU device is attached immediately after. Instead of carrying around the infrastructure to do the attach from the device specific code do it directly in the msm_iommu_init() function. This gets it out of the way for more

Re: [PATCH] radeon: insert 10ms sleep in dce5_crtc_load_lut

On Tue, Jan 28, 2020 at 4:21 PM Alex Deucher wrote: > > On Tue, Jan 28, 2020 at 11:10 AM Daniel Vetter wrote: > > > > Per at least one tester this is enough magic to recover the regression > > introduced for some people (but not all) in > > > > commit b8e2b0199cc377617dc238f5106352c06dcd3fa2 > >

Re: [PATCH] radeon: insert 10ms sleep in dce5_crtc_load_lut

On Tue, Jan 28, 2020 at 11:10 AM Daniel Vetter wrote: > > Per at least one tester this is enough magic to recover the regression > introduced for some people (but not all) in > > commit b8e2b0199cc377617dc238f5106352c06dcd3fa2 > Author: Peter Rosin > Date: Tue Jul 4 12:36:57 2017 +0200 > >

Re: [PATCH] drm/amd/display: fix spelling mistake link_integiry_check -> link_integrity_check

On Tue, Jan 28, 2020 at 6:28 AM Colin King wrote: > > From: Colin Ian King > > There is a spelling mistake on the struct field name link_integiry_check, > fix this by renaming it. > > Signed-off-by: Colin Ian King Applied. Thanks! Alex > --- >

Re: [v4] arm64: dts: sc7180: add display dt nodes

Hi, On Tue, Jan 28, 2020 at 06:54:44PM +0530, Harigovindan P wrote: > Add display, DSI hardware DT nodes for sc7180. > > Signed-off-by: Harigovindan P > --- > > Changes in v1: > -Added display DT nodes for sc7180 > Changes in v2: > -Renamed node names > -Corrected code

Re: [v1] arm64: dts: sc7180: add dsi controller and phy entries for idp dts

Hi, On Tue, Jan 28, 2020 at 07:06:57PM +0530, Harigovindan P wrote: > Adding dsi controller and phy entries for idp dt. > > Signed-off-by: Harigovindan P > --- > arch/arm64/boot/dts/qcom/sc7180-idp.dts | 56 > + > 1 file changed, 56 insertions(+) > > diff

Re: [PATCH v2] dt-bindings: display: Convert etnaviv to json-schema

On Tue, Jan 28, 2020 at 6:31 AM Benjamin GAIGNARD wrote: > > > On 1/28/20 1:06 PM, Maxime Ripard wrote: > > Hi Benjamin, > > > > On Tue, Jan 28, 2020 at 09:20:13AM +0100, Benjamin Gaignard wrote: > >> Convert etnaviv bindings to yaml format. > >> > >> Signed-off-by: Benjamin Gaignard > >> --- >

[Intel-gfx] [PATCH v5 13/21] drm/i915/display/hdmi: Make WARN* drm specific where drm_device ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_device or drm_i915_private struct pointer is readily available. The conversion

[Intel-gfx] [PATCH v5 05/21] drm/i915/display/ddi: Make WARN* drm specific where drm_device ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_device or drm_i915_private struct pointer is readily available. The conversion

[Intel-gfx] [PATCH v5 03/21] drm/i915/display/cdclk: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done

[Intel-gfx] [PATCH v5 21/21] drm/i915/gvt: Make WARN* drm specific where vgpu ptr is available

Drm specific drm_WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_device struct pointer is readily available. The conversion was done

[Intel-gfx] [PATCH v5 18/21] drm/i915/display/tc: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done

[Intel-gfx] [PATCH v5 20/21] drm/i915/gvt: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done

[Intel-gfx] [PATCH v5 19/21] drm/i915/display: Make WARN* drm specific where drm_device ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_device or drm_i915_private struct pointer is readily available. The conversion

[Intel-gfx] [PATCH v5 17/21] drm/i915/display/sdvo: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gem: initial conversion to new logging macros using coccinelle

Quoting Jani Nikula (2020-01-28 13:48:10) > On Tue, 28 Jan 2020, Tvrtko Ursulin wrote: > >> -DRM_DEBUG( > >> +drm_dbg(>drm, > > > > This changes DRM_UT_CORE to DRM_UT_DRIVER so our typical drm.debug=0xe > > becomes much more spammy. > > This is what I've instructed Wambui to do in i915. It's my

[Intel-gfx] [PATCH v5 12/21] drm/i915/display/hdcp: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done

[Intel-gfx] [PATCH v5 09/21] drm/i915/display/dpll_mgr: Make WARN* drm specific where drm_device ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_device or drm_i915_private struct pointer is readily available. The conversion

[Intel-gfx] [PATCH v5 16/21] drm/i915/display/psr: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done

[Intel-gfx] [PATCH v5 15/21] drm/i915/display/panel: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done

[Intel-gfx] [PATCH v5 10/21] drm/i915/display/fbc: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done

[Intel-gfx] [PATCH v5 11/21] drm/i915/fbdev: Make WARN* drm specific where drm_device ptr is available

Drm specific drm_WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_device struct pointer is readily available. The conversion was done

[Intel-gfx] [PATCH v5 14/21] drm/i915/display/overlay: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done

[Intel-gfx] [PATCH v5 07/21] drm/i915/display/power: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done

[Intel-gfx] [PATCH v5 08/21] drm/i915/display/dp: Make WARN* drm specific where drm_device ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_device or drm_i915_private struct pointer is readily available. The conversion

[Intel-gfx] [PATCH v5 00/21] drm: Introduce struct drm_device based WARN* and use them in i915

Device specific dev_WARN and dev_WARN_ONCE macros available in kernel include device information in the backtrace, so we know what device the warnings originate from. Similar to this, add new struct drm_device based drm_WARN* macros. These macros include device information in the backtrace, so we

[Intel-gfx] [PATCH v5 06/21] drm/i915/display/display: Make WARN* drm specific where drm_device ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_device or drm_i915_private struct pointer is readily available. The conversion

[Intel-gfx] [PATCH v5 04/21] drm/i915/display/crt: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done

[Intel-gfx] [PATCH v5 01/21] drm/i915/display/icl_dsi: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done

[Intel-gfx] [PATCH v5 02/21] drm/i915/display/audio: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done

Re: [PATCH] fbdev: wait for references go away

On Tue, Jan 28, 2020 at 5:44 PM Daniel Vetter wrote: > > On Tue, Jan 28, 2020 at 5:39 PM Daniel Vetter wrote: > > > > On Mon, Jan 20, 2020 at 11:00 AM Gerd Hoffmann wrote: > > > > > > Problem: do_unregister_framebuffer() might return before the device is > > > fully cleaned up, due to userspace

Re: [PATCH v2] dt-bindings: display: Convert etnaviv to json-schema

Hi Benjamin, On 1/28/20 1:31 PM, Benjamin GAIGNARD wrote: > > On 1/28/20 1:06 PM, Maxime Ripard wrote: >> Hi Benjamin, >> >> On Tue, Jan 28, 2020 at 09:20:13AM +0100, Benjamin Gaignard wrote: >>> Convert etnaviv bindings to yaml format. >>> >>> Signed-off-by: Benjamin Gaignard >>> --- >>>

Re: [PATCH] fbdev: wait for references go away

On Tue, Jan 28, 2020 at 5:39 PM Daniel Vetter wrote: > > On Mon, Jan 20, 2020 at 11:00 AM Gerd Hoffmann wrote: > > > > Problem: do_unregister_framebuffer() might return before the device is > > fully cleaned up, due to userspace having a file handle for /dev/fb0 > > open. Which can result in

Re: [PATCH] fbdev: wait for references go away

On Mon, Jan 20, 2020 at 11:00 AM Gerd Hoffmann wrote: > > Problem: do_unregister_framebuffer() might return before the device is > fully cleaned up, due to userspace having a file handle for /dev/fb0 > open. Which can result in drm driver not being able to grab resources > (and fail

Re: [PATCH 1/8] drm/edid: Check the number of detailed timing descriptors in the CEA ext block

On Tue, Jan 28, 2020 at 05:18:34PM +0100, Daniel Vetter wrote: > On Tue, Jan 28, 2020 at 5:15 PM Ville Syrjälä > wrote: > > > > On Tue, Jan 28, 2020 at 04:17:58PM +0100, Daniel Vetter wrote: > > > On Fri, Jan 24, 2020 at 10:02:24PM +0200, Ville Syrjala wrote: > > > > From: Ville Syrjälä > > > >

Re: [PATCH 1/8] drm/edid: Check the number of detailed timing descriptors in the CEA ext block

On Tue, Jan 28, 2020 at 5:15 PM Ville Syrjälä wrote: > > On Tue, Jan 28, 2020 at 04:17:58PM +0100, Daniel Vetter wrote: > > On Fri, Jan 24, 2020 at 10:02:24PM +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > CEA-861 says : > > > "d = offset for the byte following the reserved

Re: [PATCH 1/8] drm/edid: Check the number of detailed timing descriptors in the CEA ext block

On Tue, Jan 28, 2020 at 04:17:58PM +0100, Daniel Vetter wrote: > On Fri, Jan 24, 2020 at 10:02:24PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > CEA-861 says : > > "d = offset for the byte following the reserved data block. > > If no data is provided in the reserved data block,

[PATCH] radeon: insert 10ms sleep in dce5_crtc_load_lut

Per at least one tester this is enough magic to recover the regression introduced for some people (but not all) in commit b8e2b0199cc377617dc238f5106352c06dcd3fa2 Author: Peter Rosin Date: Tue Jul 4 12:36:57 2017 +0200 drm/fb-helper: factor out pseudo-palette which for radeon had the

[Bug 58981] [BISECTED] boot failure with Radeon 9250 PCI 256MB + KMS

https://bugzilla.kernel.org/show_bug.cgi?id=58981 James Dietrich (jdiet...@fastmail.fm) changed: What|Removed |Added Summary|[BUISECTED] boot failure|[BISECTED] boot

Re: [PATCH] drm/crc: Actually allow to change the crc source

On Thu, Aug 22, 2019 at 2:20 PM Ville Syrjälä wrote: > > On Wed, Aug 21, 2019 at 10:38:35PM +0200, Daniel Vetter wrote: > > Oops. > > > > Fixes: 9edbf1fa600a ("drm: Add API for capturing frame CRCs") > > Cc: Tomeu Vizoso > > Cc: Emil Velikov > > Cc: Benjamin Gaignard > > Signed-off-by: Daniel

Re: [PATCH v2] arm64: dts: qcom: sc7180: Add A618 gpu dt blob

On Mon, Jan 27, 2020 at 02:29:53PM -0800, Doug Anderson wrote: > Hi, > > On Mon, Jan 27, 2020 at 1:30 AM Sharat Masetty > wrote: > > > > This patch adds the required dt nodes and properties > > to enabled A618 GPU. > > > > Signed-off-by: Sharat Masetty > > --- > >

Re: [PATCH] fbdev: wait for references go away

On 1/21/20 6:53 AM, Gerd Hoffmann wrote: > Hi, > >>> open. Which can result in drm driver not being able to grab resources >>> (and fail initialization) because the firmware framebuffer still holds >>> them. Reportedly plymouth can trigger this. >> >> Could you please describe issue some

Re: [PATCH 1/8] drm/edid: Check the number of detailed timing descriptors in the CEA ext block

On Fri, Jan 24, 2020 at 10:02:24PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > CEA-861 says : > "d = offset for the byte following the reserved data block. > If no data is provided in the reserved data block, then d=4. > If no DTDs are provided, then d=0." > > So let's not look for

Re: [PATCH v4 01/15] drm: Initialize struct drm_crtc_state.no_vblank from device settings

On Mon, Jan 27, 2020 at 07:42:27PM +0100, Thomas Zimmermann wrote: > Hi Emil > > Am 27.01.20 um 19:12 schrieb Emil Velikov: > > Hi Thomas, > > > > On Thu, 23 Jan 2020 at 09:21, Thomas Zimmermann wrote: > > > >> @@ -174,12 +174,22 @@ struct drm_crtc_state { > >> * @no_vblank: > >>

Re: [Intel-gfx] [PATCH 1/4] drm: Complain if drivers still use the ->load callback

On Tue, Jan 28, 2020 at 10:47:59AM +, Chris Wilson wrote: > Quoting Daniel Vetter (2020-01-28 10:45:58) > > Kinda time to get this sorted. The locking around this really is not > > nice. > > > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/drm_drv.c | 6 ++ > >

Re: [PATCH 4/4] drm: Nerv drm_global_mutex BKL for good drivers

On Tue, Jan 28, 2020 at 11:00:32AM +, Chris Wilson wrote: > Quoting Daniel Vetter (2020-01-28 10:46:01) > > This catches the majority of drivers (unfortunately not if we take > > users into account, because all the big drivers have at least a > > lastclose hook). > > Yeah, that lastclose for

Re: KASAN: slab-out-of-bounds Write in vgacon_scroll

On 1/28/20 1:49 PM, Petr Mladek wrote: > On Tue 2020-01-28 18:23:46, anon anon wrote: >> Dear Linux kernel developers, >> >> I found the crash "KASAN: slab-out-of-bounds Write in vgacon_scroll" >> when running syzkaller, hope it's unknown: >> >> Linux version: Linux v4.17-rc4 (75bc37fefc44) >>

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gem: initial conversion to new logging macros using coccinelle

On 28/01/2020 13:48, Jani Nikula wrote: On Tue, 28 Jan 2020, Tvrtko Ursulin wrote: -DRM_DEBUG( +drm_dbg(>drm, This changes DRM_UT_CORE to DRM_UT_DRIVER so our typical drm.debug=0xe becomes much more spammy. This is what I've instructed Wambui to do in i915. It's my mistake that I haven't

Re: [PATCH 2/4] drm/fbdev-helper: don't force restores

On Tue, Jan 28, 2020 at 12:52:05PM +0100, Noralf Trønnes wrote: > > > Den 28.01.2020 11.45, skrev Daniel Vetter: > > Instead check for master status, in case we've raced. > > > > This is the last exception to the general rule that we restore fbcon > > only when there's no master active.

Re: [PATCH 1/4] drm: Complain if drivers still use the ->load callback

On Tue, Jan 28, 2020 at 02:41:06PM +0100, Thomas Zimmermann wrote: > Hi > > Am 28.01.20 um 11:45 schrieb Daniel Vetter: > > Kinda time to get this sorted. The locking around this really is not > > nice. > > > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/drm_drv.c | 6 ++ > >

Re: [PATCH 03/10] drm/atmel: plane_state->fb iff plane_state->crtc

On Fri, Dec 13, 2019 at 08:53:30PM +0100, Sam Ravnborg wrote: > Hi Daniel. > > On Fri, Dec 13, 2019 at 06:26:05PM +0100, Daniel Vetter wrote: > > Checking both is one too much, so wrap a WARN_ON around it to stope > > the copypasta. > > > > Signed-off-by: Daniel Vetter > > Cc: Sam Ravnborg > >

[PATCH v10 12/12] ARM: dts: imx: imx51-zii-rdu1: Fix the display pipeline definition

The current definition does not represent the exact display pipeline we have on the board: the LVDS panel is actually connected through a parallel -> LVDS bridge. Let's fix that so the driver can select the proper bus format on the CRTC end. Signed-off-by: Boris Brezillon --- v2 -> v10: * No

[PATCH v10 11/12] drm/panel: simple: Fix the lt089ac29000 bus_format

The lt089ac29000 panel is an LVDS panel, not a DPI one. Fix the definition to reflect this fact. v10: * Add changelog to the commit message v8 -> v9: * No changes v7: * New patch Signed-off-by: Boris Brezillon Suggested-by: Laurent Pinchart --- drivers/gpu/drm/panel/panel-simple.c | 2 +- 1

[PATCH v10 06/12] drm/bridge: Add the necessary bits to support bus format negotiation

drm_bridge_state is extended to describe the input and output bus configurations. These bus configurations are exposed through the drm_bus_cfg struct which encodes the configuration of a physical bus between two components in an output pipeline, usually between two bridges, an encoder and a

[PATCH v10 05/12] drm/bridge: Add an ->atomic_check() hook

So that bridge drivers have a way to check/reject an atomic operation. The drm_atomic_bridge_chain_check() (which is just a wrapper around the ->atomic_check() hook) is called in place of drm_bridge_chain_mode_fixup() (when ->atomic_check() is not implemented, the core falls back on

[PATCH v10 04/12] drm/bridge: Patch atomic hooks to take a drm_bridge_state

This way the drm_bridge_funcs interface is consistent with the rest of the subsystem. The drivers implementing those hooks are patched too. v10: * Add changelog to the commit message v8 -> v9: * No changes v7: * Adjust things to the bridge_state changes v6: * Also fixed rcar-du/rcar_lvds.c

[PATCH v10 10/12] drm/bridge: panel: Propage bus format/flags

So that the previous bridge element in the chain knows which input format the panel bridge expects. v10: * Add changelog to the commit message v8 -> v9: * No changes v7: * Set atomic state hooks explicitly v4 -> v6: * Not part of the series v3: * Adjust things to match the new bus-format

[PATCH v10 07/12] drm/imx: pd: Use bus format/flags provided by the bridge when available

Now that bridges can expose the bus format/flags they expect, we can use those instead of the relying on the display_info provided by the connector (which is only valid if the encoder is directly connected to bridge element driving the panel/display). We also explicitly expose the bus formats

[PATCH v10 08/12] drm/bridge: lvds-codec: Implement basic bus format negotiation

Some DPI -> LVDS encoders might support several input bus width. Add a DT property to describe the bus width used on a specific design. v10: * Add changelog to the commit message v8 -> v9: * No changes v7: * Fix a use-after-release problem * Get rid of the data-mapping parsing * Use kmalloc

[PATCH v10 00/12] drm: Add support for bus-format negotiation

Hello, This patch series aims at adding support for runtime bus-format negotiation between all elements of the 'encoder -> bridges -> connector/display' section of the pipeline. In order to support that, we need drm bridges to fully take part in the atomic state validation process, which

[PATCH v10 01/12] drm/bridge: Add a drm_bridge_state object

One of the last remaining objects to not have its atomic state. This is being motivated by our attempt to support runtime bus-format negotiation between elements of the bridge chain. This patch just paves the road for such a feature by adding a new drm_bridge_state object inheriting from

[PATCH v10 09/12] dt-bindings: display: bridge: lvds-codec: Add new bus-width prop

Add the bus-width property to describe the input bus format. v10: * Add changelog to the commit message * Add Rob's R-b v8 -> v9: * No changes v7: * Rebase on top of lvds-codec changes * Drop the data-mapping property v4 -> v6: * Not part of the series v3: * New patch Signed-off-by: Boris

[PATCH v10 02/12] drm/rcar-du: Plug atomic state hooks to the default implementation

This is needed to pass a bridge state to all atomic hooks, if we don't do that, the core can't duplicate/create bridge states. v10: * Add changelog to the commit message v9: * Add Neil's R-b * Move earlier in the series v8: * No changes v7: * New patch Signed-off-by: Boris Brezillon

[PATCH v10 03/12] drm/bridge: analogix: Plug atomic state hooks to the default implementation

This is needed to pass a bridge state to all atomic hooks, if we don't do that, the core can't duplicate/create bridge states. v10: * Add changelog to the commit message v9: * Add Neil's R-b * Move earlier in the series v8: * No changes v7: * New patch Signed-off-by: Boris Brezillon

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gem: initial conversion to new logging macros using coccinelle

On Tue, 28 Jan 2020, Tvrtko Ursulin wrote: >> -DRM_DEBUG( >> +drm_dbg(>drm, > > This changes DRM_UT_CORE to DRM_UT_DRIVER so our typical drm.debug=0xe > becomes much more spammy. This is what I've instructed Wambui to do in i915. It's my mistake that I haven't requested this to be pointed out

Re: [PATCH 1/4] drm: Complain if drivers still use the ->load callback

Hi Am 28.01.20 um 11:45 schrieb Daniel Vetter: > Kinda time to get this sorted. The locking around this really is not > nice. > > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/drm_drv.c | 6 ++ > include/drm/drm_drv.h | 3 +++ > 2 files changed, 9 insertions(+) > > diff --git

Re: [Intel-gfx] [PATCH libdrm v2] intel: drm_intel_bo_gem_create_from_* on platforms w/o HW tiling

On Wed, Jan 22, 2020 at 11:31:22AM +0200, Imre Deak wrote: > Platforms without a HW detiler doesn't support the get_tiling IOCTL. > Fix the drm_intel_bo_gem_create_from_* functions assuming the default > no-tiling, no-swizzling setting for the GEM buffer in this case. > > v2: > - Add the missing

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gem: initial conversion to new logging macros using coccinelle

On 22/01/2020 12:57, Wambui Karuga wrote: First pass of conversion to the new struct drm_based device logging macros in the drm/i915/gem directory. This conversion was achieved using the following coccinelle script that transforms based on the existence of a straightforward struct

Re: [PATCH] drm/etnaviv: only reject timeouts with tv_nsec >= 2 seconds

On Fri, Jan 24, 2020 at 9:56 AM Guido Günther wrote: > On Wed, Jan 22, 2020 at 10:35:53AM +, Russell King - ARM Linux admin > wrote: > > On Wed, Jan 22, 2020 at 11:30:34AM +0100, Guido Günther wrote: > > I think it would probably be better for the kernel to print a > > warning once when

[PATCH] Revert "drm/etnaviv: reject timeouts with tv_nsec >= NSEC_PER_SEC"

This reverts commit 172a216ff334ad869b0d74188a70763e4167fd9e. Guido Günther reported issues with this patch that broke existing user space. Let's revert it for now and fix it properly later on. Link: https://patchwork.kernel.org/patch/11291089/

Re: [PATCH 2/4] drm/fbdev-helper: don't force restores

Den 28.01.2020 11.45, skrev Daniel Vetter: > Instead check for master status, in case we've raced. > > This is the last exception to the general rule that we restore fbcon > only when there's no master active. Compositors are supposed to drop > their master status before they switch to a

Re: [PATCH 7/8] drm/edid: Constify lots of things

On Mon, Jan 27, 2020 at 05:38:15PM -0500, Alex Deucher wrote: > On Fri, Jan 24, 2020 at 3:03 PM Ville Syrjala > wrote: > > > > From: Ville Syrjälä > > > > Let's try to make a lot more stuff const in the edid parser. > > > > The "downside" is that we can no longer mangle the EDID in the > >

Re: [PATCH 5/8] drm/edid: Document why we don't bounds check the DispID CEA block start/end

On Mon, Jan 27, 2020 at 05:30:42PM -0500, Alex Deucher wrote: > On Fri, Jan 24, 2020 at 3:03 PM Ville Syrjala > wrote: > > > > From: Ville Syrjälä > > > > After much head scratching I managed to convince myself that > > for_each_displayid_db() has already done the bounds checks for > > the

[PATCH] drm/amd/display: fix spelling mistake link_integiry_check -> link_integrity_check

From: Colin Ian King There is a spelling mistake on the struct field name link_integiry_check, fix this by renaming it. Signed-off-by: Colin Ian King --- drivers/gpu/drm/amd/display/modules/hdcp/hdcp.h | 2 +- .../gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c| 8

Re: [PATCH v5 17/52] drm: Add helper to create a connector for a chain of bridges

Hi Laurent, On 24/01/2020 05:54, Laurent Pinchart wrote: +struct drm_connector *drm_bridge_connector_init(struct drm_device *drm, + struct drm_encoder *encoder) +{ + struct drm_bridge_connector *bridge_connector; + struct drm_connector

Re: [Intel-gfx] [PATCH 1/4] drm: Complain if drivers still use the ->load callback

Quoting Chris Wilson (2020-01-28 10:47:59) > Quoting Daniel Vetter (2020-01-28 10:45:58) > > Kinda time to get this sorted. The locking around this really is not > > nice. > > > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/drm_drv.c | 6 ++ > > include/drm/drm_drv.h | 3

Re: [PATCH 4/4] drm: Nerv drm_global_mutex BKL for good drivers

Quoting Daniel Vetter (2020-01-28 10:46:01) > This catches the majority of drivers (unfortunately not if we take > users into account, because all the big drivers have at least a > lastclose hook). Yeah, that lastclose for switching back to fbcon, and ensuring that switch is started before the

Re: [PATCH 3/4] drm: Push drm_global_mutex locking in drm_open

Quoting Daniel Vetter (2020-01-28 10:46:00) > We want to only take the BKL on crap drivers, but to know whether > we have a crap driver we first need to look it up. Split this shuffle > out from the main BKL-disabling patch, for more clarity. > > Since the minors are refcounted drm_minor_acquire

Re: [Intel-gfx] [PATCH 1/4] drm: Complain if drivers still use the ->load callback

Quoting Daniel Vetter (2020-01-28 10:45:58) > Kinda time to get this sorted. The locking around this really is not > nice. > > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/drm_drv.c | 6 ++ > include/drm/drm_drv.h | 3 +++ > 2 files changed, 9 insertions(+) > > diff --git

[PATCH 4/4] drm: Nerv drm_global_mutex BKL for good drivers

This catches the majority of drivers (unfortunately not if we take users into account, because all the big drivers have at least a lastclose hook). With the prep patches out of the way all drm state is fully protected and either prevents or can deal with the races from dropping the BKL around

[PATCH 3/4] drm: Push drm_global_mutex locking in drm_open

We want to only take the BKL on crap drivers, but to know whether we have a crap driver we first need to look it up. Split this shuffle out from the main BKL-disabling patch, for more clarity. Since the minors are refcounted drm_minor_acquire is purely internal and this does not have a driver

[PATCH 1/4] drm: Complain if drivers still use the ->load callback

Kinda time to get this sorted. The locking around this really is not nice. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_drv.c | 6 ++ include/drm/drm_drv.h | 3 +++ 2 files changed, 9 insertions(+) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index

[PATCH 2/4] drm/fbdev-helper: don't force restores

Instead check for master status, in case we've raced. This is the last exception to the general rule that we restore fbcon only when there's no master active. Compositors are supposed to drop their master status before they switch to a different console back to text mode (or just switch to text

Re: Interfacing mipi-lvds bridge with rk3399

On 27.01.2020 17:18, Mika Penttilä wrote: > Hi, > > We are developing a custom board, in which we are using the rk3399 soc. > We have LVDS displays, and use TI SN65dsi84 bridge as a mipi-lvds bridge. > The bridge demands the DSI data lanes be in LP-11 state (stop state). We > developed support

Re: [PATCH v3 1/2] dt-bindings: display: bridge: Add documentation for Toshiba tc358768

Hi Rob, On 27/01/2020 20.49, Rob Herring wrote: > On Mon, Jan 27, 2020 at 12:56:33PM +0200, Peter Ujfalusi wrote: >> TC358768/TC358778 is a Parallel RGB to MIPI DSI bridge. >> >> Signed-off-by: Peter Ujfalusi >> --- >> .../display/bridge/toshiba,tc358768.yaml | 158 ++ >> 1

[radeon-alex:amd-19.50 2027/2713] include/kcl/kcl_fence.h:129:20: error: redefinition of 'dma_fence_set_error'

Hi Flora, FYI, the error/warning still remains. tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50 head: f9a0b7ad3447d7766dda9923e63a5f4d0be7ce47 commit: c53ae0e01db63d1b142681add947781668e3319c [2027/2713] drm/amdkcl: drop kcl_dma_fence_set_error config: i386-allyesconfig

Re: [PATCH v2 2/2] dt-bindings: one file of all simple DSI panels

Le mer. 8 janv. 2020 à 10:41, Benjamin Gaignard a écrit : > > Le mar. 7 janv. 2020 à 18:05, Rob Herring a écrit : > > > > On Tue, Jan 7, 2020 at 9:44 AM Benjamin Gaignard > > wrote: > > > > > > Le jeu. 2 janv. 2020 à 11:17, Sam Ravnborg a écrit : > > > > > > > > To complement

Re: [PATCH] Revert "drm/sun4i: drv: Allow framebuffer modifiers in mode config"

On Mon, Jan 27, 2020 at 09:14:19AM +0100, Paul Kocialkowski wrote: > Hi Jernej, > > On Sun 26 Jan 20, 07:59, Jernej Skrabec wrote: > > This reverts commit 9db9c0cf5895e4ddde2814360cae7bea9282edd2. > > > > Setting mode_config.allow_fb_modifiers manually is completely > > unnecessary. It is set

Re: [PATCH] drm: Parse Colorimetry data block from EDID

Quoting Abhinav Kumar (2020-01-23 14:40:45) > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index 99769d6..148bfa4 100644 > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -4199,6 +4200,57 @@ static void fixup_detailed_cea_mode_clock(struct >

  1   2   >