Re: [PATCH v3 1/3] drm/msm/dp: revise timing engine programming to support widebus feature

On 04/02/2022 21:36, Kuogee Hsieh wrote: Widebus feature will transmit two pixel data per pixel clock to interface. Timing engine provides driving force for this purpose. This patch base on HPG (Hardware Programming Guide) to revise timing engine register setting to accommodate both widebus and

Re: [PATCH 04/12] drm/msm/dpu: add changes to support writeback in hw_ctl

On 05/02/2022 00:17, Abhinav Kumar wrote: Add changes to support writeback module in the dpu_hw_ctl interface. In addition inroduce a reset_intf_cfg op to reset the interface bits for the currently active interfaces in the ctl path. Signed-off-by: Abhinav Kumar ---

Re: [PATCH 12/12] drm/msm/dpu: add writeback blocks to the display snapshot

On 05/02/2022 00:17, Abhinav Kumar wrote: Add writeback block information while capturing the display snapshot. Signed-off-by: Abhinav Kumar Reviewed-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 5 + 1 file changed, 5 insertions(+) diff --git

Re: [v5 1/3] dt-bindings: msm/dsi: Add 10nm dsi phy tuning properties

On Mon, 31 Jan 2022 01:45:17 +0530, Rajeev Nandan wrote: > In most cases, the default values of DSI PHY tuning registers should be > sufficient as they are fully optimized. However, in some cases where > extreme board parasitics cause the eye shape to degrade, the override > bits can be used to

Re: [PATCH 01/12] drm/msm/dpu: add writeback blocks to the sm8250 DPU catalog

On 05/02/2022 00:17, Abhinav Kumar wrote: Add writeback blocks to the sm8250 DPU hardware catalog. Other chipsets support writeback too but add it to sm8250 to prototype the feature so that it can be easily extended to other chipsets. Signed-off-by: Abhinav Kumar Reviewed-by: Dmitry

Re: [PATCH v6 4/4] dt-bindings: drm/bridge: anx7625: Add aux-bus node

On Thu, 03 Feb 2022 22:10:23 +0800, Hsin-Yi Wang wrote: > List panel under aux-bus node if it's connected to anx7625's aux bus. > > Signed-off-by: Hsin-Yi Wang > --- > .../display/bridge/analogix,anx7625.yaml| 17 + > 1 file changed, 17 insertions(+) > Reviewed-by: Rob

Re: [PATCH 10/12] drm/msm/dpu: initialize dpu encoder and connector for writeback

On 05/02/2022 00:17, Abhinav Kumar wrote: Initialize dpu encoder and connector for writeback if the target supports it in the catalog. Signed-off-by: Abhinav Kumar --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 37 - drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 62

Re: [PATCH 11/12] drm/msm/dpu: gracefully handle null fb commits for writeback

On 05/02/2022 00:17, Abhinav Kumar wrote: kms_writeback test cases also verify with a null fb for the writeback connector job. In addition there are also other commit paths which can result in kickoffs without a valid framebuffer like while closing the fb which results in the callback to

Re: [PATCH 02/12] drm/msm/dpu: add dpu_hw_wb abstraction for writeback blocks

On 05/02/2022 00:17, Abhinav Kumar wrote: Add the dpu_hw_wb abstraction to program registers related to the writeback block. These will be invoked once all the configuration is set and ready to be programmed to the registers. Reviewed-by: Dmitry Baryshkov Few minor comments bellow.

Re: [PATCH v6 3/4] drm/bridge: anx7625: Support reading edid through aux channel

Hi Hsin-Yi, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm/drm-next] [cannot apply to robh/for-next drm-intel/for-linux-next v5.17-rc2] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base'

Re: [PATCH v2] drm/dp: Fix off-by-one in register cache size

Ping. This is a OOB read fix. Can something send this to Linus please? -Kees On Wed, Jan 05, 2022 at 09:33:10AM -0800, Kees Cook wrote: > The pcon_dsc_dpcd array holds 13 registers (0x92 through 0x9E). Fix the > math to calculate the max size. Found from a -Warray-bounds build: > >

Re: [PATCH] drm/dp: Remove common Post Cursor2 register handling

Ping, This is a OOB read fix. Can someone please pick this up? -Kees On Wed, Jan 05, 2022 at 09:35:07AM -0800, Kees Cook wrote: > The link_status array was not large enough to read the Adjust Request > Post Cursor2 register, so remove the common helper function to avoid > an OOB read, found

Re: [BUG] gpu: drm: radeon: two possible deadlocks involving locking and waiting

Hi Christian, Thanks for the reply :) On 2022/2/1 15:56, Christian König wrote: Hi Jia-Ju, interesting that you have found those issues with an automated tool. And yes that is a well design flaw within the radeon driver which can happen on hardware faults, e.g. when radeon_ring_backup()

Re: [PATCH v4 3/3] fbcon: Add option to enable legacy hardware acceleration

Hi Helge, Thanks for your patch! On Wed, Feb 2, 2022 at 8:05 PM Helge Deller wrote: > Add a config option CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION to > enable bitblt and fillrect hardware acceleration in the framebuffer > console. If disabled, such acceleration will not be used, even if

Re: [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c

Hi Daniel, Thanks for your patch! On Tue, Feb 1, 2022 at 9:50 PM Daniel Vetter wrote: > Well except when the olpc dcon fbdev driver is enabled, that thing > digs around in there in rather unfixable ways. Can't the actual frame buffer driver (which one?) used on olpc export a pointer to its

Re: [PATCH 5/6] dma-buf: add dma_fence_chain_contained helper

On Fri, 2022-02-04 at 11:04 +0100, Christian König wrote: > It's a reoccurring pattern that we need to extract the fence > from a dma_fence_chain object. Add a helper for this. > > Signed-off-by: Christian König I thought I'd reviewed this one already, but in case I didn't Reviewed-by: Thomas

Re: [PATCH v3 2/2] drm/i915/uapi: Add query for hwconfig table

On Wed, Jan 19, 2022 at 9:35 PM wrote: > > From: Rodrigo Vivi > > GuC contains a consolidated table with a bunch of information about the > current device. > > Previously, this information was spread and hardcoded to all the components > including GuC, i915 and various UMDs. The goal here is to

Re: [PATCH 04/21] fbcon: delete a few unneeded forward decl

On Tue, Feb 1, 2022 at 9:50 PM Daniel Vetter wrote: > I didn't bother with any code movement to fix the others, these just > got a bit in the way. > > Signed-off-by: Daniel Vetter Reviewed-by: Geert Uytterhoeven Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven --

Re: [PATCH v4 3/3] fbcon: Add option to enable legacy hardware acceleration

Hello Geert, On 2/4/22 09:37, Geert Uytterhoeven wrote: > On Wed, Feb 2, 2022 at 8:05 PM Helge Deller wrote: >> Add a config option CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION to >> enable bitblt and fillrect hardware acceleration in the framebuffer >> console. If disabled, such acceleration

Re: [PATCH v4 3/3] fbcon: Add option to enable legacy hardware acceleration

Hi Helge, On Fri, Feb 4, 2022 at 11:17 AM Helge Deller wrote: > On 2/4/22 09:37, Geert Uytterhoeven wrote: > > On Wed, Feb 2, 2022 at 8:05 PM Helge Deller wrote: > >> Add a config option CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION to > >> enable bitblt and fillrect hardware acceleration in

Re: Add warning for nesting dma_fence containers

On Fri, 2022-02-04 at 11:04 +0100, Christian König wrote: > Hi everyone, > > Since some operations can then lead to recursive handling nesting > dma_fence containers into each other is only allowed under some > restrictions. > > dma_fence_array containers can be attached to dma_fence_chain >

Re: [PATCH v2] drm/bridge: dw-hdmi: use safe format when first in bridge chain

Hi, On 19/01/2022 13:28, Neil Armstrong wrote: When the dw-hdmi bridge is in first place of the bridge chain, this means there is no way to select an input format of the dw-hdmi HW component. Since introduction of display-connector, negotiation was broken since the dw-hdmi negotiation code

Re: [PATCH] HPE BMC GXP SUPPORT

On 03/02/2022 18:07, Verdun, Jean-Marie wrote: > >> Maybe it does not look like, but this is actually a v2. Nick was asked >> to change the naming for the nodes already in v1. Unfortunately it did >> not happen, so we have vuart, spifi, vic and more. > >> It is a waste of

[PATCH 5/6] dma-buf: add dma_fence_chain_contained helper

It's a reoccurring pattern that we need to extract the fence from a dma_fence_chain object. Add a helper for this. Signed-off-by: Christian König --- drivers/dma-buf/dma-fence-chain.c | 6 ++ include/linux/dma-fence-chain.h | 15 +++ 2 files changed, 17 insertions(+), 4

[PATCH 6/6] drm/amdgpu: use dma_fence_chain_contained

Instead of manually extracting the fence. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c index

[PATCH 3/6] dma-buf: Warn about dma_fence_chain container rules v2

Chaining of dma_fence_chain objects is only allowed through the prev fence and not through the contained fence. Warn about that when we create a dma_fence_chain. v2: fix comment style Signed-off-by: Christian König Reviewed-by: Daniel Vetter Reviewed-by: Thomas Hellström ---

Add warning for nesting dma_fence containers

Hi everyone, Since some operations can then lead to recursive handling nesting dma_fence containers into each other is only allowed under some restrictions. dma_fence_array containers can be attached to dma_fence_chain containers and dma_fence_chain containers by chaining them together. In all

[PATCH 1/6] dma-buf: consolidate dma_fence subclass checking

Consolidate the wrapper functions to check for dma_fence subclasses in the dma_fence header. This makes it easier to document and also check the different requirements for fence containers in the subclasses. Signed-off-by: Christian König --- include/linux/dma-fence-array.h | 15 +

[PATCH 2/6] dma-buf: warn about dma_fence_array container rules v2

It's not allowed to nest another dma_fence container into a dma_fence_array or otherwise we can run into recursion. Warn about that when we create a dma_fence_array. v2: fix comment style and typo in the warning pointed out by Thomas Signed-off-by: Christian König Reviewed-by: Daniel Vetter

[PATCH 4/6] dma-buf: warn about containers in dma_resv object

Drivers should not add containers as shared fences to the dma_resv object, instead each fence should be added individually. Signed-off-by: Christian König Reviewed-by: Daniel Vetter Reviewed-by: Thomas Hellström --- drivers/dma-buf/dma-resv.c | 5 + 1 file changed, 5 insertions(+) diff

Re: [PATCH 1/6] dma-buf: consolidate dma_fence subclass checking

On Fri, 2022-02-04 at 11:04 +0100, Christian König wrote: > Consolidate the wrapper functions to check for dma_fence > subclasses in the dma_fence header. > > This makes it easier to document and also check the different > requirements for fence containers in the subclasses. > > Signed-off-by:

[PATCH v4] dma-buf-map: Rename to iosys-map

Rename struct dma_buf_map to struct iosys_map and corresponding APIs. Over time dma-buf-map grew up to more functionality than the one used by dma-buf: in fact it's just a shim layer to abstract system memory, that can be accessed via regular load and store, from IO memory that needs to be acessed

Re: [PATCH v2 1/4] drm/format-helper: Add drm_fb_{xrgb8888,gray8}_to_mono_reversed()

Hi Am 04.02.22 um 14:43 schrieb Javier Martinez Canillas: Add support to convert XR24 and 8-bit grayscale to reversed monochrome for drivers that control monochromatic panels, that only have 1 bit per pixel. The drm_fb_gray8_to_mono_reversed() helper was based on the function that does the

Re: [PATCH v2 1/4] drm/format-helper: Add drm_fb_{xrgb8888,gray8}_to_mono_reversed()

Am 04.02.22 um 16:52 schrieb Thomas Zimmermann: [...] +/** + * drm_fb_xrgb_to_mono_reversed - Convert XRGB to reversed monochrome + * @dst: reversed monochrome destination buffer + * @dst_pitch: Number of bytes between two consecutive scanlines within dst + * @src: XRGB source

Re: [PATCH] drm/amdgpu: Fix recursive locking warning

Am 04.02.22 um 17:23 schrieb Felix Kuehling: Am 2022-02-04 um 02:13 schrieb Christian König: Am 04.02.22 um 04:11 schrieb Rajneesh Bhardwaj: Noticed the below warning while running a pytorch workload on vega10 GPUs. Change to trylock to avoid conflicts with already held reservation locks.

[PATCH v5 3/5] drm/i915/gt: Re-work reset_csb

Use drm_clflush_virt_range instead of directly invoking clflush. This will prevent compiler errors when building for non-x86 architectures. v2(Michael Cheng): Remove extra clflush v3(Michael Cheng): Remove memory barrier since drm_clflush_virt_range takes care of it.

[PATCH v5 4/5] drm/i915/: Re-work clflush_write32

Use drm_clflush_virt_range instead of clflushopt and remove the memory barrier, since drm_clflush_virt_range takes care of that. Signed-off-by: Michael Cheng --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git

[PATCH v5 0/5] Use drm_clflush* instead of clflush

This patch series re-work a few i915 functions to use drm_clflush_virt_range instead of calling clflush or clflushopt directly. This will prevent errors when building for non-x86 architectures. v2: s/PAGE_SIZE/sizeof(value) for Re-work intel_write_status_page and added more patches to convert

[PATCH v5 1/5] drm/i915/gt: Re-work intel_write_status_page

Re-work intel_write_status_page to use drm_clflush_virt_range. This will prevent compiler errors when building for non-x86 architectures. Signed-off-by: Michael Cheng --- drivers/gpu/drm/i915/gt/intel_engine.h | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git

Re: [PATCH v2 0/4] drm/tiny: Add driver for Solomon SSD1307 OLED displays

Hello Geert, On 2/4/22 15:31, Geert Uytterhoeven wrote: > Hi Javier, > > On Fri, Feb 4, 2022 at 2:43 PM Javier Martinez Canillas > wrote: >> This patch series adds a DRM driver for the Solomon OLED SSD1305, SSD1306, >> SSD1307 and SSD1309 displays. It is a port of the ssd1307fb fbdev driver. >

[PATCH v5 2/5] drm/i915/gt: Drop invalidate_csb_entries

Drop invalidate_csb_entries and directly call drm_clflush_virt_range. This allows for one less function call, and prevent complier errors when building for non-x86 architectures. v2(Michael Cheng): Drop invalidate_csb_entries function and directly invoke drm_clflush_virt_range.

[PATCH v5 5/5] drm/i915/gt: replace cache_clflush_range

Replace all occurance of cache_clflush_range with drm_clflush_virt_range. This will prevent compile errors on non-x86 platforms. Signed-off-by: Michael Cheng --- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 12 ++-- drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-

Re: [PATCH 6/6] drm/amdgpu: use dma_fence_chain_contained

On Fri, Feb 4, 2022 at 5:04 AM Christian König wrote: > > Instead of manually extracting the fence. > > Signed-off-by: Christian König Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git

Re: [PATCH] drm/amdgpu: Fix recursive locking warning

Am 2022-02-04 um 02:13 schrieb Christian König: Am 04.02.22 um 04:11 schrieb Rajneesh Bhardwaj: Noticed the below warning while running a pytorch workload on vega10 GPUs. Change to trylock to avoid conflicts with already held reservation locks. [  +0.03] WARNING: possible recursive

Re: [PATCH] HPE BMC GXP SUPPORT

Hi, On Wed, Feb 02, 2022 at 10:52:50AM -0600, nick.hawk...@hpe.com wrote: > diff --git a/arch/arm/mach-hpe/Makefile b/arch/arm/mach-hpe/Makefile > new file mode 100644 > index ..8b0a91234df4 > --- /dev/null > +++ b/arch/arm/mach-hpe/Makefile > @@ -0,0 +1 @@ >

Re: [PATCH] HPE BMC GXP SUPPORT

> > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > It's normal to list all linux/ includes before asm/ includes. Please > rearrange. Hi Nick Since you are new to the kernel, please let me point out, you should consider Russell comments

Re: [PATCH v2 2/4] drm/tiny: Add driver for Solomon SSD130X OLED displays

On Fri, Feb 04, 2022 at 02:43:45PM +0100, Javier Martinez Canillas wrote: > Add a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon OLED > controllers that can be programmed via an I2C interface. This is a port > of the ssd1307fb driver that already supports these devices. > > A Device

[PATCH v3] drm/bridge: dw-hdmi: use safe format when first in bridge chain

When the dw-hdmi bridge is in first place of the bridge chain, this means there is no way to select an input format of the dw-hdmi HW component. Since introduction of display-connector, negotiation was broken since the dw-hdmi negotiation code only worked when the dw-hdmi bridge was in last

Re: [PATCH v2 3/4] MAINTAINERS: Add entry for Solomon SSD130X OLED displays DRM driver

On 2/4/22 15:28, Andy Shevchenko wrote: > On Fri, Feb 04, 2022 at 03:12:17PM +0100, Javier Martinez Canillas wrote: >> On 2/4/22 14:57, Andy Shevchenko wrote: >>> On Fri, Feb 04, 2022 at 02:43:46PM +0100, Javier Martinez Canillas wrote: > > ... > >>> Stray change? >> >> Sigh, I'm not sure how

Re: [PATCH] HPE BMC GXP SUPPORT

On Fri, 2022-02-04 at 12:05 +, Russell King (Oracle) wrote: > On Wed, Feb 02, 2022 at 10:52:50AM -0600, nick.hawk...@hpe.com wrote: [] > > diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile [] > > +static irqreturn_t gxp_time_interrupt(int irq, void *dev_id) > > +{ > > +

Re: [PATCH v11 5/5] drm/amdgpu: add drm buddy support to amdgpu

Am 04.02.22 um 12:22 schrieb Arunpravin: On 28/01/22 7:48 pm, Matthew Auld wrote: On Thu, 27 Jan 2022 at 14:11, Arunpravin wrote: - Remove drm_mm references and replace with drm buddy functionalities - Add res cursor support for drm buddy v2(Matthew Auld): - replace spinlock with mutex as

Re: [PATCH v2 0/4] drm/tiny: Add driver for Solomon SSD1307 OLED displays

Hi Javier, On Fri, Feb 4, 2022 at 2:43 PM Javier Martinez Canillas wrote: > This patch series adds a DRM driver for the Solomon OLED SSD1305, SSD1306, > SSD1307 and SSD1309 displays. It is a port of the ssd1307fb fbdev driver. [...] > This is a v2 that addresses all the issues pointed in v1,

Re: [PATCH v2 5/8] drm/i915/dp: rewrite DP 2.0 128b/132b link training based on errata

On Thu, Feb 03, 2022 at 11:03:54AM +0200, Jani Nikula wrote: > The DP 2.0 errata completely overhauls the 128b/132b link training, with > no provisions for backward compatibility with the original DP 2.0 > specification. > > The changes are too intrusive to consider reusing the same code for both

Re: Add warning for nesting dma_fence containers

Am 04.02.22 um 11:40 schrieb Thomas Hellström: On Fri, 2022-02-04 at 11:04 +0100, Christian König wrote: Hi everyone, Since some operations can then lead to recursive handling nesting dma_fence containers into each other is only allowed under some restrictions. dma_fence_array containers

Re: [PATCH] HPE BMC GXP SUPPORT

On Fri, 2022-02-04 at 12:31 +, Russell King (Oracle) wrote: > On Fri, Feb 04, 2022 at 04:18:24AM -0800, Joe Perches wrote: > > On Fri, 2022-02-04 at 12:05 +, Russell King (Oracle) wrote: > > > On Wed, Feb 02, 2022 at 10:52:50AM -0600, nick.hawk...@hpe.com wrote: > > > > + if

Re: [PATCH v2] drm/bridge: dw-hdmi: use safe format when first in bridge chain

Hi, On 04/02/2022 15:05, Robert Foss wrote: On Wed, 19 Jan 2022 at 13:28, Neil Armstrong wrote: When the dw-hdmi bridge is in first place of the bridge chain, this means there is no way to select an input format of the dw-hdmi HW component. Since introduction of display-connector,

Re: [PATCH v11 5/5] drm/amdgpu: add drm buddy support to amdgpu

On 28/01/22 7:48 pm, Matthew Auld wrote: > On Thu, 27 Jan 2022 at 14:11, Arunpravin > wrote: >> >> - Remove drm_mm references and replace with drm buddy functionalities >> - Add res cursor support for drm buddy >> >> v2(Matthew Auld): >> - replace spinlock with mutex as we call

Re: [PATCH v2 3/4] MAINTAINERS: Add entry for Solomon SSD130X OLED displays DRM driver

On Fri, Feb 04, 2022 at 02:43:46PM +0100, Javier Martinez Canillas wrote: > To make sure that tools like the get_maintainer.pl script will suggest > to Cc me if patches are posted for this driver. > > Also include the Device Tree binding for the old ssd1307fb fbdev driver > since the new DRM

Re: [PATCH v2] drm/bridge: dw-hdmi: use safe format when first in bridge chain

On Wed, 19 Jan 2022 at 13:28, Neil Armstrong wrote: > > When the dw-hdmi bridge is in first place of the bridge chain, this > means there is no way to select an input format of the dw-hdmi HW > component. > > Since introduction of display-connector, negotiation was broken since > the dw-hdmi

Re: [PATCH v2 3/4] MAINTAINERS: Add entry for Solomon SSD130X OLED displays DRM driver

Hello Andy, On 2/4/22 14:57, Andy Shevchenko wrote: > On Fri, Feb 04, 2022 at 02:43:46PM +0100, Javier Martinez Canillas wrote: >> To make sure that tools like the get_maintainer.pl script will suggest >> to Cc me if patches are posted for this driver. >> >> Also include the Device Tree binding

Re: [PATCH v2 3/4] MAINTAINERS: Add entry for Solomon SSD130X OLED displays DRM driver

On Fri, Feb 04, 2022 at 03:12:17PM +0100, Javier Martinez Canillas wrote: > On 2/4/22 14:57, Andy Shevchenko wrote: > > On Fri, Feb 04, 2022 at 02:43:46PM +0100, Javier Martinez Canillas wrote: ... > > Stray change? > > Sigh, I'm not sure how added that change. Just ignore it, I'll fix it > on

Re: [PATCH] HPE BMC GXP SUPPORT

On Fri, Feb 04, 2022 at 04:18:24AM -0800, Joe Perches wrote: > On Fri, 2022-02-04 at 12:05 +, Russell King (Oracle) wrote: > > On Wed, Feb 02, 2022 at 10:52:50AM -0600, nick.hawk...@hpe.com wrote: > > > + if (readb_relaxed(timer->control) & MASK_TCS_TC) { > > > +

[PATCH v2 3/4] MAINTAINERS: Add entry for Solomon SSD130X OLED displays DRM driver

To make sure that tools like the get_maintainer.pl script will suggest to Cc me if patches are posted for this driver. Also include the Device Tree binding for the old ssd1307fb fbdev driver since the new DRM driver was made compatible with the existing binding. Signed-off-by: Javier Martinez

[PATCH v2 2/4] drm/tiny: Add driver for Solomon SSD130X OLED displays

Add a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon OLED controllers that can be programmed via an I2C interface. This is a port of the ssd1307fb driver that already supports these devices. A Device Tree binding is not added because the DRM driver is compatible with the existing

[PATCH v2 0/4] drm/tiny: Add driver for Solomon SSD1307 OLED displays

This patch series adds a DRM driver for the Solomon OLED SSD1305, SSD1306, SSD1307 and SSD1309 displays. It is a port of the ssd1307fb fbdev driver. Using the DRM fb emulation, all the tests from Geert Uytterhoeven's fbtest (https://git.kernel.org/pub/scm/linux/kernel/git/geert/fbtest.git)

[PATCH v2 1/4] drm/format-helper: Add drm_fb_{xrgb8888, gray8}_to_mono_reversed()

Add support to convert XR24 and 8-bit grayscale to reversed monochrome for drivers that control monochromatic panels, that only have 1 bit per pixel. The drm_fb_gray8_to_mono_reversed() helper was based on the function that does the same in the drivers/gpu/drm/tiny/repaper.c driver.

[PATCH v2 4/4] dt-bindings: display: ssd1307fb: Add myself as binding co-maintainer

The ssd130x DRM driver also makes use of this Device Tree binding to allow existing users of the fbdev driver to migrate without the need to change their Device Trees. Add myself as another maintainer of the binding, to make sure that I will be on Cc when patches are proposed for it.

[RFC PATCH 2/3] drm/amd: Convert amdgpu to use suballocation helper.

Now that the suballocation helper is generic, we can use it in amdgpu. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 29 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 21 +-

[RFC PATCH 1/3] drm: Extract amdgpu_sa.c as a generic suballocation helper

Suballocating a buffer object is something that is not driver generic, and is useful for other drivers as well. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/Makefile | 4 +- drivers/gpu/drm/drm_suballoc.c | 424 + include/drm/drm_suballoc.h |

[RFC PATCH 0/3] drm/helpers: Make the suballocation manager drm generic.

The suballocation manager itself is not dependent on any implementation detail, and can be made generic. I want to potentially use it inside i915, as it looks like a clean implementation to do so. :) Looking for feedback and some testing, as I don't have a amdgpu/radeon myself. Only compile

[RFC PATCH 3/3] drm/radeon: Use the drm suballocation manager implementation.

Use the generic suballocation helper lifted from amdgpu. Note that the generic suballocator only allows a single alignment, so we may waste a few more bytes for radeon_semaphore, shouldn't be a big deal, could be re-added if needed. Signed-off-by: Maarten Lankhorst ---

Re: [PATCH 03/19] iosys-map: Add a few more helpers

Hi Am 04.02.22 um 18:44 schrieb Lucas De Marchi: First the simplest ones: - iosys_map_memset(): when abstracting system and I/O memory, just like the memcpy() use case, memset() also has dedicated functions to be called for using IO memory. -

Re: [PATCH 07/19] drm/i915/guc: Convert golden context init to iosys_map

Hi Am 04.02.22 um 18:44 schrieb Lucas De Marchi: Now the map is saved during creation, so use it to initialize the golden context, reading from shmem and writing to either system or IO memory. Cc: Matt Roper Cc: Thomas Hellström Cc: Daniel Vetter Cc: John Harrison Cc: Matthew Brost Cc:

Re: [PATCH v2 2/4] drm/tiny: Add driver for Solomon SSD130X OLED displays

Hello Andy, Thanks for your feedback. On 2/4/22 15:26, Andy Shevchenko wrote: > On Fri, Feb 04, 2022 at 02:43:45PM +0100, Javier Martinez Canillas wrote: >> Add a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon OLED >> controllers that can be programmed via an I2C interface. This is

Re: [RFC PATCH 1/3] drm: Extract amdgpu_sa.c as a generic suballocation helper

Hi Am 04.02.22 um 19:29 schrieb Christian König: Oh, that's on my TODO list for years! Am 04.02.22 um 18:48 schrieb Maarten Lankhorst: Suballocating a buffer object is something that is not driver generic, and is useful for other drivers as well. Signed-off-by: Maarten Lankhorst ---  

Re: [PATCH 15/21] fbcon: Consistently protect deferred_takeover with console_lock()

On Mon, Jan 31, 2022 at 10:05:46PM +0100, Daniel Vetter wrote: > This shouldn't be a problem in practice since until we've actually > taken over the console there's nothing we've registered with the > console/vt subsystem, so the exit/unbind path that check this can't > do the wrong thing. But

Re: [PATCH v3 2/2] drm/i915/uapi: Add query for hwconfig table

On 2/4/2022 01:55, Daniel Vetter wrote: On Wed, Jan 19, 2022 at 9:35 PM wrote: From: Rodrigo Vivi GuC contains a consolidated table with a bunch of information about the current device. Previously, this information was spread and hardcoded to all the components including GuC, i915 and

Re: [PATCH 16/21] fbcon: Move console_lock for register/unlink/unregister

Hi Daniel. On Mon, Jan 31, 2022 at 10:05:47PM +0100, Daniel Vetter wrote: > Ideally console_lock becomes an implementation detail of fbcon.c and > doesn't show up anywhere in fbmem.c. We're still pretty far from that, > but at least the register/unregister code is there now. > > With this the

[Important!] 2022 X.Org Foundation Membership deadline for voting in the election

The 2022 X.Org Foundation elections are rapidly approaching. We will be forwarding instructions on the nomination process to membership in the near future. Please note that only current members can vote in the upcoming election, and that the deadline for new memberships or renewals to vote in the

[PATCH 06/19] drm/i915/guc: Add read/write helpers for ADS blob

Add helpers on top of iosys_map_read_field() / iosys_map_write_field() functions so they always use the right arguments and make code easier to read. Cc: Matt Roper Cc: Thomas Hellström Cc: Daniel Vetter Cc: John Harrison Cc: Matthew Brost Cc: Daniele Ceraolo Spurio Signed-off-by: Lucas De

[PATCH 08/19] drm/i915/guc: Convert policies update to iosys_map

Use iosys_map to write the policies update so access to IO and system memory is abstracted away. Cc: Matt Roper Cc: Thomas Hellström Cc: Daniel Vetter Cc: John Harrison Cc: Matthew Brost Cc: Daniele Ceraolo Spurio Signed-off-by: Lucas De Marchi ---

[PATCH 07/19] drm/i915/guc: Convert golden context init to iosys_map

Now the map is saved during creation, so use it to initialize the golden context, reading from shmem and writing to either system or IO memory. Cc: Matt Roper Cc: Thomas Hellström Cc: Daniel Vetter Cc: John Harrison Cc: Matthew Brost Cc: Daniele Ceraolo Spurio Signed-off-by: Lucas De Marchi

[PATCH 12/19] drm/i915/guc: Replace check for golden context size

In the other places in this function, guc->ads_map is being protected from access when it's not yet set. However the last check is actually about guc->ads_golden_ctxt_size been set before. These checks should always match as the size is initialized on the first call to guc_prep_golden_context(),

[PATCH 19/19] drm/i915/guc: Remove plain ads_blob pointer

Now we have the access to content of GuC ADS either using iosys_map API or using a temporary buffer. Remove guc->ads_blob as there shouldn't be updates using the bare pointer anymore. Cc: Matt Roper Cc: Thomas Hellström Cc: Daniel Vetter Cc: John Harrison Cc: Matthew Brost Cc: Daniele

[PATCH 10/19] drm/i915/guc: Convert guc_ads_private_data_reset to iosys_map

Use iosys_map_memset() to zero the private data as ADS may be either on system or IO memory. Cc: Matt Roper Cc: Thomas Hellström Cc: Daniel Vetter Cc: John Harrison Cc: Matthew Brost Cc: Daniele Ceraolo Spurio Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c |

[PATCH 17/19] drm/i915/guc: Convert guc_mmio_reg_state_init to iosys_map

Now that the regset list is prepared, convert guc_mmio_reg_state_init() to use iosys_map to copy the array to the final location and initialize additional fields in ads.reg_state_list. Cc: Matt Roper Cc: Thomas Hellström Cc: Daniel Vetter Cc: John Harrison Cc: Matthew Brost Cc: Daniele

[PATCH 14/19] drm/i915/guc: Convert capture list to iosys_map

Use iosys_map to write the fields ads.capture_*. Cc: Matt Roper Cc: Thomas Hellström Cc: Daniel Vetter Cc: John Harrison Cc: Matthew Brost Cc: Daniele Ceraolo Spurio Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 10 +- 1 file changed, 5

[PATCH 15/19] drm/i915/guc: Prepare for error propagation

Currently guc_mmio_reg_add() relies on having enough memory available in the array to add a new slot. It uses `GEM_BUG_ON(count >= regset->size);` to protect going above the threshold. In order to allow guc_mmio_reg_add() to handle the memory allocation by itself, it must return an error in case

[PATCH 18/19] drm/i915/guc: Convert __guc_ads_init to iosys_map

Now that all the called functions from __guc_ads_init() are converted to use ads_map, stop using ads_blob in __guc_ads_init(). Cc: Matt Roper Cc: Thomas Hellström Cc: Daniel Vetter Cc: John Harrison Cc: Matthew Brost Cc: Daniele Ceraolo Spurio Signed-off-by: Lucas De Marchi ---

[PATCH 13/19] drm/i915/guc: Convert mapping table to iosys_map

Use iosys_map to write the fields system_info.mapping_table[][]. Since we already have the info_map around where needed, just use it instead of going through guc->ads_map. Cc: Matt Roper Cc: Thomas Hellström Cc: Daniel Vetter Cc: John Harrison Cc: Matthew Brost Cc: Daniele Ceraolo Spurio

[PATCH 16/19] drm/i915/guc: Use a single pass to calculate regset

The ADS initialitazion was using 2 passes to calculate the regset sent to GuC to initialize each engine: the first pass to just have the final object size and the second to set each register in place in the final gem object. However in order to maintain an ordered set of registers to pass to guc,

[PATCH 09/19] drm/i915/guc: Convert engine record to iosys_map

Use iosys_map to read fields from the dma_blob so access to IO and system memory is abstracted away. Cc: Matt Roper Cc: Thomas Hellström Cc: Daniel Vetter Cc: John Harrison Cc: Matthew Brost Cc: Daniele Ceraolo Spurio Signed-off-by: Lucas De Marchi ---

[PATCH 11/19] drm/i915/guc: Convert golden context prep to iosys_map

Use the saved ads_map to prepare the golden context. One difference from the init context is that this function can be called before there is a gem object (and thus the guc->ads_map) to calculare the size of the golden context that should be allocated for that object. So in this case the function

[PATCH] drm/nouveau/backlight: Fix LVDS backlight detection on some laptops

It seems that some laptops will report having both an eDP and LVDS connector, even though only the LVDS connector is actually hooked up. This can lead to issues with backlight registration if the eDP connector ends up getting registered before the LVDS connector, as the backlight device will then

Re: [RFC PATCH 1/3] drm: Extract amdgpu_sa.c as a generic suballocation helper

Oh, that's on my TODO list for years! Am 04.02.22 um 18:48 schrieb Maarten Lankhorst: Suballocating a buffer object is something that is not driver generic, and is useful for other drivers as well. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/Makefile | 4 +-

[PATCH v3 2/3] drm/msm/dp: revise timing engine programming to support compression (DSC)

Divides horizontal width by 3 at timing engine of interface. There are major part of compression (DSC) programming have to be done at DSC controller which is not covered by this patch. Signed-off-by: Kuogee Hsieh --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 22 ++

[PATCH v3 3/3] drm/msm/dp: enable widebus feature for display port

Widebus feature will transmit two pixel data per pixel clock to interface. This feature now is required to be enabled to easy migrant to higher resolution applications in future. However since some legacy chipsets does not support this feature, this feature is enabled base on chip's hardware

[PATCH v3 0/3] enable widebus feature base on chip hardware revision

split into 3 patches 1) widebus timing engine programming 2) dsc timing engine 3) enable widebus feature base on chip hardware revision Kuogee Hsieh (3): drm/msm/dp: revise timing engine programming to support widebus feature drm/msm/dp: revise timing engine programming to support

[PATCH v3 1/3] drm/msm/dp: revise timing engine programming to support widebus feature

Widebus feature will transmit two pixel data per pixel clock to interface. Timing engine provides driving force for this purpose. This patch base on HPG (Hardware Programming Guide) to revise timing engine register setting to accommodate both widebus and non widebus application. Also horizontal

Re: [PATCH 04/19] drm/i915/gt: Add helper for shmem copy to iosys_map

Hi Am 04.02.22 um 18:44 schrieb Lucas De Marchi: Add a variant of shmem_read() that takes a iosys_map pointer rather than a plain pointer as argument. It's mostly a copy __shmem_rw() but adapting the api and removing the write support since there's currently only need to use iosys_map as

  1   2   >