Re: [PATCH v1 1/5] dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding

2021-07-26 Thread Jason-JH Lin
Hi Enric, On Mon, 2021-07-26 at 12:08 +0200, Enric Balletbo Serra wrote: > Hi Jason, > > Missatge de Jason-JH Lin del dia dl., 26 > de jul. 2021 a les 9:02: > > > > On Fri, 2021-07-23 at 13:13 +0200, Enric Balletbo Serra wrote: > > > Hi Jason, > > > > > > Thank you for your patch. > > > > >

Re: [PATCH] drm/msm: Fix display fault handling

2021-07-26 Thread Bjorn Andersson
On Wed 07 Jul 11:01 PDT 2021, Rob Clark wrote: > From: Rob Clark > > It turns out that when the display is enabled by the bootloader, we can > get some transient iommu faults from the display. Which doesn't go over > too well when we install a fault handler that is gpu specific. To avoid >

[PATCH] efi: sysfb_efi: fix build when EFI is not set

2021-07-26 Thread Randy Dunlap
/sysfb_efi.c |2 ++ 1 file changed, 2 insertions(+) --- linext-20210726.orig/drivers/firmware/efi/sysfb_efi.c +++ linext-20210726/drivers/firmware/efi/sysfb_efi.c @@ -332,6 +332,7 @@ static const struct fwnode_operations ef .add_links = efifb_add_links, }; +#ifdef CONFIG_EFI static struct

Re: [Internet]Re: [PATCH] fbcon: Out-Of-Bounds write in sys_imageblit, add range check

2021-07-26 Thread gre...@linuxfoundation.org
On Tue, Jul 27, 2021 at 01:53:13AM +, tcs_kernel(腾讯云内核开发者) wrote: > yres and vyres can be controlled by user mode paramaters, and cause p->vrows > to become a negative value. While this value be passed to real_y function, > the ypos will be out of screen range. > This is an out-of-bounds

Re: [Internet]Re: [PATCH] fbcon: Out-Of-Bounds write in sys_imageblit, add range check

2021-07-26 Thread 腾讯云内核开发者
yres and vyres can be controlled by user mode paramaters, and cause p->vrows to become a negative value. While this value be passed to real_y function, the ypos will be out of screen range. This is an out-of-bounds write bug. I think updatescrollmode is the right place to validate values

[PATCH 1/1] drm/i915/selftests: Increase timeout in i915_gem_contexts selftests

2021-07-26 Thread Matthew Brost
Like in the case of several other selftests, generating lots of requests in a loop takes a bit longer with GuC submission. Increase a timeout in i915_gem_contexts selftest to take this into account. Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 2 +- 1

[PATCH 0/1] Increase timeout in i915_gem_contexts selftests

2021-07-26 Thread Matthew Brost
Patch says it all. Seeing a failure in CI [1] and locally on certain TGL machines with GuC submission enabled. Let's fix this so we can enable CI on TGL with GuC submission. Signed-off-by: Matthew Brost [1] https://patchwork.freedesktop.org/series/92984/#rev4 Matthew Brost (1):

[PATCH 1/2] drm/i915/guc: Add fetch of hwconfig table

2021-07-26 Thread John . C . Harrison
From: John Harrison Implement support for fetching the hardware description table from the GuC. The call is made twice - once without a destination buffer to query the size and then a second time to fill in the buffer. Note that the table is only available on ADL-P and later platforms. Cc:

[PATCH 0/2] Add support for querying hw info that UMDs need

2021-07-26 Thread John . C . Harrison
From: John Harrison Various UMDs require hardware configuration information about the current platform. A bunch of static information is available in a fixed table that can be retrieved from the GuC. Test-with: 20210727002812.43469-2-john.c.harri...@intel.com UMD:

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

2021-07-26 Thread John . C . Harrison
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 consolidate the data into GuC in a way that all

[PATCH v3] drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling features

2021-07-26 Thread Nicolas Boichat
Many of the DSI flags have names opposite to their actual effects, e.g. MIPI_DSI_MODE_EOT_PACKET means that EoT packets will actually be disabled. Fix this by including _NO_ in the flag names, e.g. MIPI_DSI_MODE_NO_EOT_PACKET. Signed-off-by: Nicolas Boichat Reviewed-by: Linus Walleij

[PATCH 1/2] drm/i915/guc: Add fetch of hwconfig table

2021-07-26 Thread John . C . Harrison
From: John Harrison Implement support for fetching the hardware description table from the GuC. The call is made twice - once without a destination buffer to query the size and then a second time to fill in the buffer. Note that the table is only available on ADL-P and later platforms. Cc:

[PATCH 0/2] Add support for querying hw info that UMDs need

2021-07-26 Thread John . C . Harrison
From: John Harrison Various UMDs require hardware configuration information about the current platform. A bunch of static information is available in a fixed table that can be retrieved from the GuC. Test-with: 20210727002812.43469-2-john.c.harri...@intel.com UMD:

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

2021-07-26 Thread John . C . Harrison
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 consolidate the data into GuC in a way that all

[PATCH] drm/pl111: Remove unused including

2021-07-26 Thread Cai Huoqing
Remove including that don't need it. Signed-off-by: Cai Huoqing --- drivers/gpu/drm/pl111/pl111_display.c | 1 - drivers/gpu/drm/pl111/pl111_drv.c | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c index

Re: [Intel-gfx] [PATCH] drm/i915/userptr: Probe existence of backing struct pages upon creation

2021-07-26 Thread Matthew Auld
On Fri, 23 Jul 2021 at 18:49, Jason Ekstrand wrote: > > Are there IGTs for this anywhere? https://patchwork.freedesktop.org/series/92580/ > > On Fri, Jul 23, 2021 at 12:47 PM Jason Ekstrand wrote: > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12044 > > > > On Fri, Jul 23,

Re: [PATCH 2/2] drm/panel: Add Samsung S6E3FA2 DSI panel driver

2021-07-26 Thread Linus Walleij
Hi Alexey, I had some gmail problems and replied to the very old driver by Iskren, sorry for the mess. I overall like this driver a lot. Some of Sam's comments could be addressed especially for backlight. I think the driver should indeed handle both the physical displays like you do here. On

Re: [Intel-gfx] [PATCH 04/10] drm/i915: move intel_context slab to direct module init/exit

2021-07-26 Thread Tvrtko Ursulin
On 23/07/2021 20:29, Daniel Vetter wrote: With the global kmem_cache shrink infrastructure gone there's nothing special and we can convert them over. I'm doing this split up into each patch because there's quite a bit of noise with removing the static global.slab_ce to just a slab_ce. Cc:

Re: [RFC 6/8] drm: Document fdinfo format specification

2021-07-26 Thread Tvrtko Ursulin
On 23/07/2021 17:43, Daniel Stone wrote: Hi Tvrtko, Thanks for typing this up! On Thu, 15 Jul 2021 at 10:18, Tvrtko Ursulin wrote: +Mandatory fully standardised keys +- + +- drm-driver: + +String shall contain a fixed string uniquely identified the driver

Re: [PATCH v1 1/5] dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding

2021-07-26 Thread Jason-JH Lin
On Fri, 2021-07-23 at 13:13 +0200, Enric Balletbo Serra wrote: > Hi Jason, > > Thank you for your patch. > > Missatge de jason-jh.lin del dia dj., 22 > de jul. 2021 a les 11:26: > > > > There are 2 display hardware path in mt8195, namely vdosys0 and > > vdosys1, so add their definition in

Re: [PATCH v3 2/2] drm/panel: Add panel for Samsung Galaxy S5

2021-07-26 Thread Linus Walleij
Hi Iskren, thanks for your patch! On Mon, Feb 1, 2021 at 5:56 PM Iskren Chernev wrote: > The Samsung Galaxy S5 uses the samsung s6e3fa2 AMOLED cmd LCD panel. > > This driver was generated with [1], with the addition of > mipi_dsi_dcs_set_display_on at the end of the on method. > > [1]

Re: [Intel-gfx] [PATCH 5/8] drm/i915/gem/ttm: Only call __i915_gem_object_set_pages if needed

2021-07-26 Thread Matthew Auld
On Fri, 23 Jul 2021 at 18:22, Jason Ekstrand wrote: > > __i915_ttm_get_pages does two things. First, it calls ttm_bo_validate() > to check the given placement and migrate the BO if needed. Then, it > updates the GEM object to match, in case the object was migrated. If > no migration occured,

Re: [PATCH v3 3/3] drm/panel-simple: add Gopher 2b LCD panel

2021-07-26 Thread Paul Cercueil
Hi Artjom, Le lun., juil. 26 2021 at 01:15:27 +0300, Artjom Vejsel a écrit : The Gopher 2b LCD panel is used in Gopher 2b handhelds. It's simple panel with NewVision NV3047 driver, but SPI lines are not connected. It has no specific name, since it's unique to that handhelds. lot name at

Re: [PATCH v3 1/2] dt-bindings: panel: Add Samsung S6E3FA2 panel

2021-07-26 Thread Linus Walleij
Hi Iskren, thanks for your patch! On Mon, Feb 1, 2021 at 5:56 PM Iskren Chernev wrote: > +required: > + - compatible > + - reset-gpios > + - iovdd-supply > + - vddr-supply > + - port I do not think port should be required because the DSI framework allows panels to be put as children

[PATCH v2] drm: add logging for RMFB ioctl

2021-07-26 Thread Simon Ser
We already have logging for ADDFB2. Add some logging for RMFB as well. This can be handy when trying to find out why a CRTC gets magically disabled. v2: make log message more explicit, add log messages to drm_framebuffer_remove (Daniel) Signed-off-by: Simon Ser Cc: Daniel Vetter ---

Re: [Intel-gfx] [PATCH] drm/i915/userptr: Probe existence of backing struct pages upon creation

2021-07-26 Thread Matthew Auld
On Fri, 23 Jul 2021 at 18:48, Jason Ekstrand wrote: > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12044 Cool, is that ready to go? i.e can we start merging the kernel + IGT side. > > On Fri, Jul 23, 2021 at 6:35 AM Matthew Auld wrote: > > > > From: Chris Wilson > > > > Jason

Re: [Intel-gfx] [PATCH 0/8] drm/i915: Migrate memory to SMEM when imported cross-device (v8)

2021-07-26 Thread Matthew Auld
On Fri, 23 Jul 2021 at 18:21, Jason Ekstrand wrote: > > This patch series fixes an issue with discrete graphics on Intel where we > allowed dma-buf import while leaving the object in local memory. This > breaks down pretty badly if the import happened on a different physical > device. > > v7: >

[PATCH] drm: document DRM_IOCTL_MODE_RMFB

2021-07-26 Thread Simon Ser
Since there's no struct to attach the docs to, document the IOCTL definition. Signed-off-by: Simon Ser Cc: Daniel Vetter Cc: Pekka Paalanen Cc: Leandro Ribeiro --- include/uapi/drm/drm.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/include/uapi/drm/drm.h

Re: [PATCH] drm: document drm_mode_get_property

2021-07-26 Thread Simon Ser
On Wednesday, July 21st, 2021 at 13:39, Daniel Vetter wrote: > I think it would be really good to link to > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#modeset-base-object-abstraction > > for all the property related ioctl. That entire class vs instance > confusion is pretty common I

Re: [RFC 6/8] drm: Document fdinfo format specification

2021-07-26 Thread Tvrtko Ursulin
On 23/07/2021 18:45, Nieto, David M wrote: [AMD Official Use Only] I just want to make a comment that with this approach (the ns) calculating the percentage will take at least two reads of the fdinfo per pid over some time. Some engines may be able to provide a single shot percentage

Re: [PATCH 2/2] drm/panel: Add Samsung S6E3FA2 DSI panel driver

2021-07-26 Thread Linus Walleij
On Sun, Jul 25, 2021 at 5:01 PM Sam Ravnborg wrote: > This driver supports two different panels: > > S6E3FA2 > EA8064G > > They differ on a lot of the tables and requires different init. > In other words there is only a little boiler plate code that is in > common. > > I think

Re: [PATCH 1/2] dt-bindings: panel: Add Samsung S6E3FA2 panel

2021-07-26 Thread Linus Walleij
On Sun, Jul 25, 2021 at 4:04 PM Alexey Minnekhanov wrote: > The Samsung S6E3FA2 AMOLED cmd LCD panel is used on Samsung Galaxy > S5 (klte) phone. > > Signed-off-by: Alexey Minnekhanov Grr gmail put this in my spam folder, sorry for confused mails. With Sam's comments addressed: Reviewed-by:

Re: [Intel-gfx] [PATCH 26/30] drm/i915: finish removal of CNL

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:11:10PM -0700, Lucas De Marchi wrote: > With all the users removed, finish removing the CNL platform definitions. > We will leave the PCI IDs around as those are exposed to userspace. > Even if mesa doesn't support CNL anymore, let's avoid build breakages > due to

Re: [PATCH 20/30] drm/i915: remove explicit CNL handling from intel_mocs.c

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:11:04PM -0700, Lucas De Marchi wrote: > Only one reference to CNL that is not needed, but code is the same for > GEN9_BC, so leave the code around and just remove the special > case for CNL. > > Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi > --- >

Re: [PATCH 11/30] drm/i915/display: remove explicit CNL handling from intel_dp.c

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:10:55PM -0700, Lucas De Marchi wrote: > The only real platform with DISPLAY_VER == 10 is GLK. We don't need to > handle CNL explicitly in intel_dp.c. > > Remove code and rename functions/macros accordingly to use ICL prefix. > > Signed-off-by: Lucas De Marchi

Re: [Intel-gfx] [PATCH 08/30] drm/i915/display: remove explicit CNL handling from intel_ddi.c

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:10:52PM -0700, Lucas De Marchi wrote: > The only real platform with DISPLAY_VER == 10 is GLK. We don't need to > handle CNL explicitly in intel_ddi.c. > > Remove code and rename functions/macros accordingly to use ICL prefix. > There's one leftover reference to cnl that

Re: [PATCH 18/30] drm/i915: remove explicit CNL handling from i915_irq.c

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:11:02PM -0700, Lucas De Marchi wrote: > Remove special handling of PORT_F in i915_irq.c and only do it for > DISPLAY_VER == 11. oh! ignore my previous thought about removing the port F... > > Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi > --- >

Re: [Intel-gfx] [PATCH 13/30] drm/i915/display: remove explicit CNL handling from intel_vdsc.c

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:10:57PM -0700, Lucas De Marchi wrote: > Only one reference to CNL that is not needed, but code is the same for > DISPLAY_VER >= 11, so leave the code around and just remove the special > case for CNL. > > Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi >

Re: [Intel-gfx] [PATCH 28/30] drm/i915: rename/remove CNL registers

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:11:12PM -0700, Lucas De Marchi wrote: > Remove registers that are not used anymore due to CNL removal and rename > those that are. > > Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/i915_reg.h | 192

Re: [Intel-gfx] [PATCH 30/30] drm/i915: switch num_scalers/num_sprites to consider DISPLAY_VER

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:11:14PM -0700, Lucas De Marchi wrote: > The numbers of scalers and sprites depend on the display version, so use > it instead of GRAPHICS_VER. We were mixing both, which let me confused > while removing CNL and GRAPHICS_VER == 10. > > Signed-off-by: Lucas De Marchi >

Re: [Intel-gfx] [PATCH 22/30] drm/i915: remove explicit CNL handling from intel_wopcm.c

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:11:06PM -0700, Lucas De Marchi wrote: > Consider the new WOPCM size as starting in ICL rather than CNL since the > latter is being removed from the driver. > > Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_wopcm.c | 10

Re: [Intel-gfx] [PATCH 19/30] drm/i915: remove explicit CNL handling from intel_pm.c

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:11:03PM -0700, Lucas De Marchi wrote: > Remove support for CNL as it's highly untested, probably broken, and > there is no real platform that requires this code. This is part of CNL > removal from i915. > > Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi >

Re: [PATCH] drm/fourcc: Add modifier definitions for Arm Fixed Rate Compression

2021-07-26 Thread Liviu Dudau
On Thu, Jul 01, 2021 at 06:07:09PM +0100, Normunds Rieksts wrote: > Arm Fixed Rate Compression (AFRC) is a proprietary fixed rate image > compression protocol and format. > It is designed to provide guaranteed bandwidth and memory footprint > reductions in graphics and media use-cases. > > This

[PATCH v2 0/3] Error out if 'pixclock' equals zero

2021-07-26 Thread Zheyu Ma
Zheyu Ma (3): video: fbdev: asiliantfb: Error out if 'pixclock' equals zero video: fbdev: kyro: Error out if 'pixclock' equals zero video: fbdev: riva: Error out if 'pixclock' equals zero drivers/video/fbdev/asiliantfb.c | 3 +++ drivers/video/fbdev/kyro/fbdev.c | 3 +++

[PATCH v2 1/3] video: fbdev: asiliantfb: Error out if 'pixclock' equals zero

2021-07-26 Thread Zheyu Ma
The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of 'pixclock', it may cause divide error. Fix this by checking whether 'pixclock' is zero first. The following log reveals it: [ 43.861711] divide error: [#1]

[PATCH v2 3/3] video: fbdev: riva: Error out if 'pixclock' equals zero

2021-07-26 Thread Zheyu Ma
The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of 'pixclock', it may cause divide error. Fix this by checking whether 'pixclock' is zero first. The following log reveals it: [ 33.396850] divide error: [#1]

[PATCH v2 2/3] video: fbdev: kyro: Error out if 'pixclock' equals zero

2021-07-26 Thread Zheyu Ma
The userspace program could pass any values to the driver through ioctl() interface. if the driver doesn't check the value of 'pixclock', it may cause divide error because the value of 'lineclock' and 'frameclock' will be zero. Fix this by checking whether 'pixclock' is zero in

Re: [PATCH 29/30] drm/i915: replace random CNL comments

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:11:13PM -0700, Lucas De Marchi wrote: > Cleanup remaining cases that we find CNL in the codebase. > > Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/display/intel_bios.c | 2 +- >

Re: [Intel-gfx] [PATCH 14/30] drm/i915/display: remove explicit CNL handling from skl_universal_plane.c

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:10:58PM -0700, Lucas De Marchi wrote: > The only real platform with DISPLAY_VER == 10 is GLK. We don't need to > handle CNL explicitly in skl_universal_plane.c. > > Remove code and rename functions/macros accordingly to use ICL prefix. > > Signed-off-by: Lucas De

Re: [PATCH 24/30] drm/i915: rename CNL references in intel_dram.c

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:11:08PM -0700, Lucas De Marchi wrote: > With the removal of CNL, let's consider ICL as the first platform using > those constants. > > Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/i915_reg.h | 24 +++ >

Re: [PATCH v4 5/7] drm/panfrost: Add a new ioctl to submit batches

2021-07-26 Thread Boris Brezillon
On Thu, 8 Jul 2021 14:10:45 +0200 Christian König wrote: > >> --- a/drivers/gpu/drm/panfrost/panfrost_job.c > >> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c > >> @@ -254,6 +254,9 @@ static int panfrost_acquire_object_fences(struct > >> panfrost_job *job) > >>return

Aw: Re: Re: [PATCH] soc: mediatek: mmsys: fix HDMI output on mt7623/bananapi-r2

2021-07-26 Thread Frank Wunderlich
Hi > Gesendet: Montag, 26. Juli 2021 um 02:27 Uhr > Von: "Chun-Kuang Hu" > As I've discussed in [1], SOUT has many bits and need to be cleared > before set new value. Of course, write only could do the clear, but > for MOUT, it clear the bits that should not be cleared. If you want to > use the

Re: [PATCH 12/30] drm/i915/display: remove explicit CNL handling from intel_dpll_mgr.c

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:10:56PM -0700, Lucas De Marchi wrote: > The only real platform with DISPLAY_VER == 10 is GLK. We don't need to > handle CNL explicitly in intel_ddi.c. > > A lot of special code for CNL can be removed. There were some > __cnl.*() functions that were created to share the

Re: [Intel-gfx] [PATCH 10/30] drm/i915/display: remove explicit CNL handling from intel_dmc.c

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:10:54PM -0700, Lucas De Marchi wrote: > Remove DMC firmware for CNL. > > Signed-off-by: Lucas De Marchi Cc: Anusha Srivatsa We need to remove the binary from linux-firmware.git as well > --- > drivers/gpu/drm/i915/display/intel_dmc.c | 9 - > 1 file

Re: [Intel-gfx] [PATCH 27/30] drm/i915: remove GRAPHICS_VER == 10

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:11:11PM -0700, Lucas De Marchi wrote: > Replace all remaining handling of GRAPHICS_VER {==,>=} 10 with > {==,>=} 11. With the removal of CNL, there is no platform with graphics > version equals 10. > > Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi > --- >

Re: [PATCH v1 1/5] dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding

2021-07-26 Thread Enric Balletbo Serra
Hi Jason, Missatge de Jason-JH Lin del dia dl., 26 de jul. 2021 a les 9:02: > > On Fri, 2021-07-23 at 13:13 +0200, Enric Balletbo Serra wrote: > > Hi Jason, > > > > Thank you for your patch. > > > > Missatge de jason-jh.lin del dia dj., 22 > > de jul. 2021 a les 11:26: > > > > > > There are 2

Re: [Intel-gfx] [PATCH 15/30] drm/i915/display: remove explicit CNL handling from intel_display_power.c

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:10:59PM -0700, Lucas De Marchi wrote: > The only real platform with DISPLAY_VER == 10 is GLK. We don't need to > handle CNL explicitly in intel_display_power.c. > > Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi > --- >

Re: [PATCH 25/30] drm/i915/gt: rename CNL references in intel_engine.h

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:11:09PM -0700, Lucas De Marchi wrote: > With the removal of CNL, let's consider ICL as the first platform using > that index. > > Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi ( I got myself thinking that some patches like this could be squashed into

Re: [Intel-gfx] [PATCH 16/30] drm/i915/display: remove CNL ddi buf translation tables

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:11:00PM -0700, Lucas De Marchi wrote: > The only real platform with DISPLAY_VER == 10 is GLK. We don't need to > handle CNL explicitly. > > Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/display/intel_ddi.c | 12 +- >

Re: [Intel-gfx] [PATCH 09/30] drm/i915/display: remove explicit CNL handling from intel_display_debugfs.c

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:10:53PM -0700, Lucas De Marchi wrote: > Only one reference to CNL that is not needed, but code is the same for > DISPLAY_VER >= 11, so leave the code around and just remove the special > case for CNL. > > Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi >

Re: [PATCH 0/3] add checks against divide error

2021-07-26 Thread Zheyu Ma
On Mon, Jul 26, 2021 at 4:18 AM Sam Ravnborg wrote: > > Hi Zheyu, > > On Sun, Jul 25, 2021 at 02:10:51AM +, Zheyu Ma wrote: > > Zheyu Ma (3): > > video: fbdev: kyro: add a check against divide error > > video: fbdev: riva: add a check against divide error > > video: fbdev: asiliantfb:

Re: [PATCH 17/30] drm/i915/display: rename CNL references in skl_scaler.c

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:11:01PM -0700, Lucas De Marchi wrote: > With the removal of CNL, let's consider GLK as the first platform using > those constants since GLK has DISPLAY_VER == 10. > > Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi > --- >

Re: [Intel-gfx] [PATCH 21/30] drm/i915: remove explicit CNL handling from intel_pch.c

2021-07-26 Thread Rodrigo Vivi
On Fri, Jul 23, 2021 at 05:11:05PM -0700, Lucas De Marchi wrote: > Remove references for CNL from pch detection. for a moment I almost thought you were removing the CNP support... > > Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_pch.c | 5

Re: [Intel-gfx] [PATCH 02/30] drm/i915/display: split DISPLAY_VER 9 and 10 in intel_setup_outputs()

2021-07-26 Thread Rodrigo Vivi
On Sat, Jul 24, 2021 at 10:02:15PM -0700, Lucas De Marchi wrote: > On Sat, Jul 24, 2021 at 06:41:21PM +0100, Christoph Hellwig wrote: > > Still tests fine: > > > > Tested-by: Christoph Hellwig > > I just pushed this to drm-intel-next as part of another series and > added your Tested-by. > >

Re: [PATCH v3 3/3] drm/panel-simple: add Gopher 2b LCD panel

2021-07-26 Thread Artjom Vejsel
Hello, Paul! Thanks for your investigation. But while this two panels are compatible with the timing set in the driver, their timing ranges are different ([1], [2]) and therefore should have different compatible strings. [1]: https://wendangmao.net/doc/753b5635102de2bd960588e2-51.html

Re: [PATCH] fbcon: Out-Of-Bounds write in sys_imageblit, add range check

2021-07-26 Thread gre...@linuxfoundation.org
On Mon, Jul 26, 2021 at 11:32:37AM +, tcs_kernel(腾讯云内核开发者) wrote: > yres and vyres can be controlled by user mode paramaters, and cause p->vrows > to become a negative value. While this value be passed to real_y function, > the ypos will be out of screen range. > This is an out-of-bounds

Re: [Intel-gfx] [PATCH 04/10] drm/i915: move intel_context slab to direct module init/exit

2021-07-26 Thread Jason Ekstrand
On Mon, Jul 26, 2021 at 3:35 AM Tvrtko Ursulin wrote: > > > On 23/07/2021 20:29, Daniel Vetter wrote: > > With the global kmem_cache shrink infrastructure gone there's nothing > > special and we can convert them over. > > > > I'm doing this split up into each patch because there's quite a bit of

Re: [PATCH v5 02/15] mei: pxp: export pavp client to me client bus

2021-07-26 Thread Daniele Ceraolo Spurio
On 7/26/2021 8:04 AM, Winkler, Tomas wrote: From: Vitaly Lubart Export PAVP client to work with i915 driver, for binding it uses kernel component framework. Signed-off-by: Vitaly Lubart Signed-off-by: Tomas Winkler Signed-off-by: Daniele Ceraolo Spurio Reviewed-by: Rodrigo Vivi ---

Re: [PATCH 08/10] drm/i915: move scheduler slabs to direct module init/exit

2021-07-26 Thread Jason Ekstrand
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote: > > With the global kmem_cache shrink infrastructure gone there's nothing > special and we can convert them over. > > I'm doing this split up into each patch because there's quite a bit of > noise with removing the static

Re: [PATCH 10/10] drm/i915: Remove i915_globals

2021-07-26 Thread Jason Ekstrand
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote: > > No longer used. > > Cc: Jason Ekstrand > Signed-off-by: Daniel Vetter Reviewed-by: Jason Ekstrand But, also, tvrtko is right that dumping all that stuff in i915_pci.c isn't great. Mind typing a quick follow-on that moves

Re: [PATCH 1/3] drm/amdgpu: create amdgpu_vkms (v2)

2021-07-26 Thread Alex Deucher
On Fri, Jul 23, 2021 at 10:07 PM Chen, Guchun wrote: > > [Public] > > Look copy right statement is missed in both amdgpu_vkms.c and amdgpu_vkms.h. It's there, it just uses the newer SPDX license identifier. Alex > > Regards, > Guchun > > -Original Message- > From: amd-gfx On Behalf

Re: [PATCH 1/3] drm/amdgpu: create amdgpu_vkms (v2)

2021-07-26 Thread Taylor, Ryan
[AMD Official Use Only] Sounds good, Thanks for clarifying. Thanks for the input Guchun. Best, Ryan From: Alex Deucher Sent: Monday, July 26, 2021 9:58 AM To: Taylor, Ryan Cc: Chen, Guchun ; kernel test robot ; Daniel Vetter ; Siqueira, Rodrigo ; amd-gfx list

Re: [Intel-gfx] [PATCH 6/8] drm/i915/gem: Always call obj->ops->migrate unless can_migrate fails

2021-07-26 Thread Matthew Auld
On Fri, 23 Jul 2021 at 18:22, Jason Ekstrand wrote: > > Without TTM, we have no such hook so we exit early but this is fine > because we use TTM on all LMEM platforms and, on integrated platforms, > there is no real migration. If we do have the hook, it's better to just > let TTM handle the

Re: [PATCH] drm/i915/userptr: Probe existence of backing struct pages upon creation

2021-07-26 Thread Maarten Lankhorst
Op 23-07-2021 om 13:34 schreef Matthew Auld: > From: Chris Wilson > > Jason Ekstrand requested a more efficient method than userptr+set-domain > to determine if the userptr object was backed by a complete set of pages > upon creation. To be more efficient than simply populating the userptr >

Re: [PATCH 03/10] drm/i915: move i915_buddy slab to direct module init/exit

2021-07-26 Thread Jason Ekstrand
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote: > > With the global kmem_cache shrink infrastructure gone there's nothing > special and we can convert them over. > > I'm doing this split up into each patch because there's quite a bit of > noise with removing the static global.slab_blocks to

Re: [PATCH 07/10] drm/i915: move request slabs to direct module init/exit

2021-07-26 Thread Jason Ekstrand
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote: > > With the global kmem_cache shrink infrastructure gone there's nothing > special and we can convert them over. > > I'm doing this split up into each patch because there's quite a bit of > noise with removing the static

Re: [PATCH 09/10] drm/i915: move vma slab to direct module init/exit

2021-07-26 Thread Jason Ekstrand
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote: > > With the global kmem_cache shrink infrastructure gone there's nothing > special and we can convert them over. > > I'm doing this split up into each patch because there's quite a bit of > noise with removing the static global.slab_vmas to

Re: [PATCH 1/3] drm/amdgpu: create amdgpu_vkms (v2)

2021-07-26 Thread Taylor, Ryan
[AMD Official Use Only] Given that amdgpu_vkms contains code from both dce_virtual and vkms should the identifier be changed to GPL-2.0+ OR MIT like in amdgpu_res_cursor.h? Best, Ryan From: Alex Deucher Sent: Monday, July 26, 2021 9:21 AM To: Chen, Guchun Cc:

Re: [Intel-gfx] [PATCH 0/8] drm/i915: Migrate memory to SMEM when imported cross-device (v8)

2021-07-26 Thread Matthew Auld
On Mon, 26 Jul 2021 at 16:11, Jason Ekstrand wrote: > > On Mon, Jul 26, 2021 at 3:12 AM Matthew Auld > wrote: > > > > On Fri, 23 Jul 2021 at 18:21, Jason Ekstrand wrote: > > > > > > This patch series fixes an issue with discrete graphics on Intel where we > > > allowed dma-buf import while

Re: [Intel-gfx] [PATCH 0/8] drm/i915: Migrate memory to SMEM when imported cross-device (v8)

2021-07-26 Thread Jason Ekstrand
On Mon, Jul 26, 2021 at 10:29 AM Matthew Auld wrote: > > On Mon, 26 Jul 2021 at 16:11, Jason Ekstrand wrote: > > > > On Mon, Jul 26, 2021 at 3:12 AM Matthew Auld > > wrote: > > > > > > On Fri, 23 Jul 2021 at 18:21, Jason Ekstrand wrote: > > > > > > > > This patch series fixes an issue with

Re: [PATCH 05/10] drm/i915: move gem_context slab to direct module init/exit

2021-07-26 Thread Jason Ekstrand
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote: > > With the global kmem_cache shrink infrastructure gone there's nothing > special and we can convert them over. > > I'm doing this split up into each patch because there's quite a bit of > noise with removing the static global.slab_luts to

Re: [PATCH 06/10] drm/i915: move gem_objects slab to direct module init/exit

2021-07-26 Thread Jason Ekstrand
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote: > > With the global kmem_cache shrink infrastructure gone there's nothing > special and we can convert them over. > > I'm doing this split up into each patch because there's quite a bit of > noise with removing the static global.slab_objects to

Re: [Intel-gfx] [PATCH 04/10] drm/i915: move intel_context slab to direct module init/exit

2021-07-26 Thread Jason Ekstrand
On Mon, Jul 26, 2021 at 10:30 AM Jason Ekstrand wrote: > > On Mon, Jul 26, 2021 at 3:35 AM Tvrtko Ursulin > wrote: > > > > > > On 23/07/2021 20:29, Daniel Vetter wrote: > > > With the global kmem_cache shrink infrastructure gone there's nothing > > > special and we can convert them over. > > > >

Re: [Intel-gfx] [PATCH 01/33] drm/i915/guc: GuC virtual engines

2021-07-26 Thread Daniele Ceraolo Spurio
On 7/24/2021 4:13 PM, Matthew Brost wrote: On Fri, Jul 23, 2021 at 05:47:45PM -0700, Daniele Ceraolo Spurio wrote: On 7/22/2021 4:53 PM, Matthew Brost wrote: Implement GuC virtual engines. Rather simple implementation, basically just allocate an engine, setup context enter / exit function

Re: [Intel-gfx] [PATCH 0/8] drm/i915: Migrate memory to SMEM when imported cross-device (v8)

2021-07-26 Thread Matthew Auld
On Mon, 26 Jul 2021 at 16:32, Jason Ekstrand wrote: > > On Mon, Jul 26, 2021 at 10:29 AM Matthew Auld > wrote: > > > > On Mon, 26 Jul 2021 at 16:11, Jason Ekstrand wrote: > > > > > > On Mon, Jul 26, 2021 at 3:12 AM Matthew Auld > > > wrote: > > > > > > > > On Fri, 23 Jul 2021 at 18:21, Jason

Re: [Intel-gfx] [PATCH 04/10] drm/i915: move intel_context slab to direct module init/exit

2021-07-26 Thread Tvrtko Ursulin
On 26/07/2021 16:42, Jason Ekstrand wrote: On Mon, Jul 26, 2021 at 10:30 AM Jason Ekstrand wrote: On Mon, Jul 26, 2021 at 3:35 AM Tvrtko Ursulin wrote: On 23/07/2021 20:29, Daniel Vetter wrote: With the global kmem_cache shrink infrastructure gone there's nothing special and we can

Re: [PATCH] drm/i915/userptr: Probe existence of backing struct pages upon creation

2021-07-26 Thread Tvrtko Ursulin
On 26/07/2021 16:14, Jason Ekstrand wrote: On Mon, Jul 26, 2021 at 3:31 AM Maarten Lankhorst wrote: Op 23-07-2021 om 13:34 schreef Matthew Auld: From: Chris Wilson Jason Ekstrand requested a more efficient method than userptr+set-domain to determine if the userptr object was backed by a

Re: [Intel-gfx] [PATCH 04/10] drm/i915: move intel_context slab to direct module init/exit

2021-07-26 Thread Jason Ekstrand
On Mon, Jul 26, 2021 at 11:08 AM Tvrtko Ursulin wrote: > On 26/07/2021 16:42, Jason Ekstrand wrote: > > On Mon, Jul 26, 2021 at 10:30 AM Jason Ekstrand > > wrote: > >> > >> On Mon, Jul 26, 2021 at 3:35 AM Tvrtko Ursulin > >> wrote: > >>> > >>> > >>> On 23/07/2021 20:29, Daniel Vetter wrote: >

Re: [Intel-gfx] [PATCH 04/10] drm/i915: move intel_context slab to direct module init/exit

2021-07-26 Thread Tvrtko Ursulin
On 26/07/2021 17:20, Jason Ekstrand wrote: On Mon, Jul 26, 2021 at 11:08 AM Tvrtko Ursulin wrote: On 26/07/2021 16:42, Jason Ekstrand wrote: On Mon, Jul 26, 2021 at 10:30 AM Jason Ekstrand wrote: On Mon, Jul 26, 2021 at 3:35 AM Tvrtko Ursulin wrote: On 23/07/2021 20:29, Daniel Vetter

linux-next: manual merge of the drm tree with the qcom/for-next tree

2021-07-26 Thread Mark Brown
Hi all, Today's linux-next merge of the drm tree got a conflict in: drivers/firmware/Makefile between commit: b42000e4b874 ("firmware: qcom_scm: Allow qcom_scm driver to be loadable as a permenent module") from the qcom/for-next tree and commits: 8633ef82f101 ("drivers/firmware:

Re: [PATCH 1/3] drm/amdgpu: create amdgpu_vkms (v2)

2021-07-26 Thread Alex Deucher
On Mon, Jul 26, 2021 at 12:39 PM Taylor, Ryan wrote: > > [AMD Official Use Only] > > > Given that amdgpu_vkms contains code from both dce_virtual and vkms should > the identifier be changed to GPL-2.0+ OR MIT like in amdgpu_res_cursor.h? Most of the code is from vkms so match vkms. Alex > >

Re: [PATCH v3 3/3] drm/panel-simple: add Gopher 2b LCD panel

2021-07-26 Thread Sam Ravnborg
Hi Paul, On Mon, Jul 26, 2021 at 10:02:08AM +0100, Paul Cercueil wrote: > Hi Artjom, > > Le lun., juil. 26 2021 at 01:15:27 +0300, Artjom Vejsel > a écrit : > > The Gopher 2b LCD panel is used in Gopher 2b handhelds. > > It's simple panel with NewVision NV3047 driver, but SPI lines are not > >

[PATCH V2 2/2] drm/bridge: lvds-codec: Add support for LVDS data mapping select

2021-07-26 Thread Marek Vasut
Decoder input LVDS format is a property of the decoder chip or even its strapping. Handle data-mapping the same way lvds-panel does. In case data-mapping is not present, do nothing, since there are still legacy bindings which do not specify this property. Signed-off-by: Marek Vasut Cc: Laurent

[PATCH V2 1/2] dt-bindings: display: bridge: lvds-codec: Document LVDS data mapping select

2021-07-26 Thread Marek Vasut
Decoder input LVDS format is a property of the decoder chip or even its strapping. Add DT property data-mapping the same way lvds-panel does, to define the LVDS data mapping. Signed-off-by: Marek Vasut Cc: Laurent Pinchart Cc: Rob Herring Cc: Sam Ravnborg Cc: devicet...@vger.kernel.org To:

Re: [PATCH v5] drm/msm/dp: add logs across DP driver for ease of debugging

2021-07-26 Thread Stephen Boyd
Quoting maitreye (2021-07-26 10:36:26) > From: Maitreyee Rao > > Add trace points across the MSM DP driver to help debug > interop issues. > > Changes in v2: > - Got rid of redundant log messages. > - Added %#x instead of 0x%x wherever required. > - Got rid of __func__ calls in debug messages.

Re: [PATCH v2] drm/msm/dp: signal audio plugged change at dp_pm_resume

2021-07-26 Thread Stephen Boyd
Quoting Kuogee Hsieh (2021-07-23 09:55:39) > There is a scenario that dp cable is unplugged from DUT during system > suspended will cause audio option state does not match real connection > state. Fix this problem by Signaling audio plugged change with realtime > connection status at

Re: [PATCH 1/5] drm/vmwgfx: unbind in vmw_ttm_unpopulate

2021-07-26 Thread Christian König
Am 26.07.21 um 02:03 schrieb Dave Airlie: [SNIP] But you know, normal human: Only equipped with one head and two hands and not cloneable. I'm the same, but I'm not seeing where this problem happens at all, do we have any backtraces or demos for this? I've stumbled over this while working on

Re: [PATCH v2 0/3] Error out if 'pixclock' equals zero

2021-07-26 Thread Sam Ravnborg
Hi Zheyu, On Mon, Jul 26, 2021 at 10:03:52AM +, Zheyu Ma wrote: > Zheyu Ma (3): > video: fbdev: asiliantfb: Error out if 'pixclock' equals zero > video: fbdev: kyro: Error out if 'pixclock' equals zero > video: fbdev: riva: Error out if 'pixclock' equals zero Thanks for the quick

[PATCH V2] drm: mxsfb: Use bus_format from the nearest bridge if present

2021-07-26 Thread Marek Vasut
In case there is a bridge connected to the LCDIF, use bus_format from the bridge, otherwise behave as before and use bus_format from the connector. This way, even if there are multiple bridges in the display pipeline, the LCDIF will use the correct format. Reviewed-by: Lucas Stach Signed-off-by:

Re: [PATCH 1/2] dt-bindings: display: simple: Add AUO B133HAN05 & B140HAN06

2021-07-26 Thread Sam Ravnborg
Hi Björn, On Mon, Jul 26, 2021 at 10:32:59AM -0700, Bjorn Andersson wrote: > Add bindings for the two AUO panels B133HAN05 and B140HAN06, both > 1920x1080 panels with 16.7M colors, first being 13.3" and the latter > 14.0". > > Signed-off-by: Bjorn Andersson Thanks, both patches applied to

  1   2   3   >