Ville also pointed out that I got a lot of the logic here wrong as well, whoops.
While I don't think anyone's likely using 3D output with nouveau, the next patch
will make nouveau_conn_mode_valid() make a lot less sense. So, let's just get
rid of it and open-code it like before, while taking care t
While I thought I had this correct (since it actually did reject modes
like I expected during testing), Ville Syrjala from Intel pointed out
that the logic here isn't correct. max_clock refers to the max data rate
supported by the DP encoder. So, limiting it to the output of ds_clock (which
refers
Just a backport of the two patches for v5.9 that you'll want to apply.
The first one was Cc'd to stable, but I forgot to Cc the second one as
well.
Lyude Paul (2):
drm/nouveau/kms/nv50-: Get rid of bogus nouveau_conn_mode_valid()
drm/nouveau/kms/nv50-: Fix clock checking algorithm in
nv50_
On Fri, 6 Nov 2020 12:48:05 +0100 "Christian König"
wrote:
> Patch "495c10cc1c0c CHROMIUM: dma-buf: restore args..."
> adds a workaround for a bug in mmap_region.
>
> As the comment states ->mmap() callback can change
> vma->vm_file and so we might call fput() on the wrong file.
>
> Revert th
Hi Lee and DRM folks.
On Fri, Nov 06, 2020 at 09:49:30PM +, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
>
> There are 5000 warnings to work through. It will take a
On Fri, Nov 06, 2020 at 09:49:35PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/mga/mga_state.c: In function ‘mga_dma_iload’:
> drivers/gpu/drm/mga/mga_state.c:945:22: warning: variable ‘buf_priv’ set but
> not used [-Wunused-but-set-variable]
>
On Fri, Nov 06, 2020 at 09:49:34PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/mga/mga_dma.c:29: warning: Cannot understand * file
> mga_dma.c
> drivers/gpu/drm/mga/mga_dma.c:455: warning: Function parameter or member
> 'dev' not described in
On Fri, Nov 06, 2020 at 09:49:32PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/r128/ati_pcigart.c:2: warning: Cannot understand * file
> ati_pcigart.c
>
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Gareth Hughes
> Cc: dri-devel@lists.freede
Fixes the following W=1 kernel build warning(s):
62 | void radeon_driver_unload_kms(struct drm_device *dev)
| ^~~~
drivers/gpu/drm/radeon/radeon_kms.c:105:5: warning: no previous prototype for
‘radeon_driver_load_kms’ [-Wmissing-prototypes]
105 | int radeon_driver_load_kms
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_kms.c:226: warning: Function parameter or member
'dev' not described in 'radeon_info_ioctl'
drivers/gpu/drm/radeon/radeon_kms.c:226: warning: Excess function parameter
'rdev' description in 'radeon_info_ioctl'
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/v3d/v3d_drv.c:73:32: warning: ‘v3d_v3d_pm_ops’ defined but not
used [-Wunused-const-variable=]
Cc: Eric Anholt
Cc: David Airlie
Cc: Daniel Vetter
Cc: Philipp Zabel
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:594: warning: Function parameter or
member 'reg_addr' not described in 'amdgpu_device_indirect_rreg'
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:624: warning: Function parameter or
member 'reg_addr' not
Place it on the heap instead.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c: In function ‘amdgpu_info_ioctl’:
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c:979:1: warning: the frame size of 1128
bytes is larger than 1024 bytes [-Wframe-larger-than=]
Cc: Al
Also rid some unused ones.
This patch solves 2000 warnings!
Fixes the following W=1 kernel build warning(s):
In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dc_types.h:33,
from drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:30,
from drivers/gpu/drm/amd/amdgpu/../d
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/atombios_crtc.c:1796: warning: Excess function
parameter 'encoder' description in 'radeon_get_shared_nondp_ppll'
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.or
Unfortunately, a suitable one didn't already exist.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_device.c:637:6: warning: no previous prototype
for ‘radeon_device_is_virtual’ [-Wmissing-prototypes]
637 | bool radeon_device_is_virtual(void)
| ^
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_kms.c:61:6: warning: no previous prototype for
‘radeon_driver_unload_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:104:5: warning: no previous prototype for
‘radeon_driver_load_kms’ [-Wmissing-prot
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_kms.c:756:5: warning: no previous prototype for
‘radeon_get_vblank_counter_kms’ [-Wmissing-prototypes]
756 | u32 radeon_get_vblank_counter_kms(struct drm_crtc *crtc)
| ^
drivers/gpu/drm/
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_drv.c:2: warning: Cannot understand * file
radeon_drv.c
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Gareth Hughes
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesk
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/omapdrm/omap_gem.c:593: warning: Function parameter or member
'file' not described in 'omap_gem_dumb_create'
drivers/gpu/drm/omapdrm/omap_gem.c:593: warning: Excess function parameter
'drm_file' description in 'omap_gem_dumb_crea
Both source files include atom.h, which seems like a reasonable
location to place an atom based function into.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_atombios.c:1791:6: warning: no previous
prototype for ‘radeon_atom_get_tv_timings’ [-Wmissing-prototypes]
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/r128/ati_pcigart.c:2: warning: Cannot understand * file
ati_pcigart.c
Cc: David Airlie
Cc: Daniel Vetter
Cc: Gareth Hughes
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/r128/ati_pcigart.c |
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
There are 5000 warnings to work through. It will take a couple more
sets. Although, ("drm/amd/display/dc/basics/fixpt31_32: Move
variables to wher
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/mga/mga_state.c: In function ‘mga_dma_iload’:
drivers/gpu/drm/mga/mga_state.c:945:22: warning: variable ‘buf_priv’ set but
not used [-Wunused-but-set-variable]
Cc: David Airlie
Cc: Daniel Vetter
Cc: by
Cc: Jeff Hartmann
Cc: K
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/ttm/ttm_range_manager.c:46: warning: cannot understand
function prototype: 'struct ttm_range_manager '
Cc: Christian Koenig
Cc: Huang Rui
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Le
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:313: warning: Function parameter or
member 'dmm' not described in 'dmm_txn_init'
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:313: warning: Function parameter or
member 'tcm' not described in 'dmm_txn_init'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/mga/mga_dma.c:29: warning: Cannot understand * file mga_dma.c
drivers/gpu/drm/mga/mga_dma.c:455: warning: Function parameter or member 'dev'
not described in 'mga_do_agp_dma_bootstrap'
drivers/gpu/drm/mga/mga_dma.c:455: warning:
There is too much data being stored on the stack.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c: In function
‘sideband_msg_req_encode_decode’:
drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c:168:1: warning: the frame
size of 1072 bytes
Fixes the following W=1 kernel build warning(s):
drivers/mtd/spi-nor/controllers/hisi-sfc.c:328: warning: Function parameter or
member 'np' not described in 'hisi_spi_nor_register'
drivers/mtd/spi-nor/controllers/hisi-sfc.c:328: warning: Function parameter or
member 'host' not described in 'hi
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
v1 => v2:
- Added tags
- Satisfied Miquel's review comments
Lee Jones (23):
mtd: mtdpart: Fix misdocumented function parameter 'mtd'
mtd: d
The pull request you sent on Fri, 6 Nov 2020 14:21:13 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-11-06-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fc7b66ef076644dd646eb9f11563684edc479649
Thank you!
--
Deet-doot-dot, I am a bot.
https://
On Fri, 06 Nov 2020, Lyude Paul wrote:
> On Thu, 2020-11-05 at 14:45 +, Lee Jones wrote:
> > The stack is too full.
> >
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c: In function
> > ‘sideband_msg_req_encode_decode’:
> > dri
On Thu, 2020-11-05 at 14:45 +, Lee Jones wrote:
> The stack is too full.
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c: In function
> ‘sideband_msg_req_encode_decode’:
> drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c:161:1: w
Hi,
On Fri, Nov 6, 2020 at 10:23 AM Stephen Boyd wrote:
>
> Reading the EDID of this panel shows that these flags should be set. Set
> them so that we match what is in the EDID.
>
> Cc: Douglas Anderson
> Cc: Bjorn Andersson
> Fixes: b0c664cc80e8 ("panel: simple: Add BOE NV133FHM-N61")
> Signed
On Wed, Nov 04, 2020 at 07:49:12PM +0300, Dmitry Osipenko wrote:
> Add devfreq support to the Tegra20 EMC driver. Memory utilization
> statistics will be periodically polled from the memory controller and
> appropriate minimum clock rate will be selected by the devfreq governor.
>
> Signed-off-by:
On Wed, Nov 04, 2020 at 07:49:11PM +0300, Dmitry Osipenko wrote:
> Now Internal and External Memory Controllers are memory interconnection
> providers. This allows us to use interconnect API for tuning of memory
> configuration. EMC driver now supports OPPs and DVFS.
>
> Signed-off-by: Dmitry Osip
On Wed, Nov 04, 2020 at 07:49:10PM +0300, Dmitry Osipenko wrote:
> EMC driver will become mandatory after turning it into interconnect
> provider because interconnect users, like display controller driver, will
> fail to probe using newer device-trees that have interconnect properties.
> Thus make
On Wed, Nov 04, 2020 at 07:49:09PM +0300, Dmitry Osipenko wrote:
> Add modularization support to the Tegra20 EMC driver, which now can be
> compiled as a loadable kernel module.
>
> Acked-by: Thierry Reding
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/memory/tegra/Kconfig | 2 +-
> d
On Wed, Nov 04, 2020 at 07:49:08PM +0300, Dmitry Osipenko wrote:
> Add common SoC-agnostic ICC framework which turns Tegra Memory Controller
> into a memory interconnection provider. This allows us to use interconnect
> API for tuning of memory configurations.
>
> Tested-by: Peter Geis
> Tested-b
On 06/11/2020 16:37, Tomi Valkeinen wrote:
> On 05/11/2020 20:56, H. Nikolaus Schaller wrote:
>>
>>> Am 05.11.2020 um 19:28 schrieb Tomi Valkeinen :
>>>
>>> On 05/11/2020 20:14, H. Nikolaus Schaller wrote:
> Am 05.11.2020 um 18:36 schrieb Tomi Valkeinen :
>
> Hi,
>
> On 05/
On Wed, Nov 04, 2020 at 07:49:07PM +0300, Dmitry Osipenko wrote:
> Add missing PTC memory client latency allowness entry to the Tegra MC
> drivers.
>
> This prevents erroneous clearing of MC_INTSTATUS 0x0 register during
> of the LA programming in tegra_mc_setup_latency_allowance() due to the
> mi
On Wed, Nov 04, 2020 at 07:49:06PM +0300, Dmitry Osipenko wrote:
> The platform_get_irq() prints error message telling that interrupt is
> missing, hence there is no need to duplicated that message in the drivers.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/memory/tegra/mc.c | 4
On Wed, Nov 04, 2020 at 07:49:05PM +0300, Dmitry Osipenko wrote:
> Use devm_platform_ioremap_resource() helper which makes code a bit
> cleaner.
>
> Acked-by: Thierry Reding
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/memory/tegra/tegra124-emc.c | 4 +---
> drivers/memory/tegra/tegra20-emc
On Wed, Nov 04, 2020 at 07:49:04PM +0300, Dmitry Osipenko wrote:
> Multiple Tegra drivers need to retrieve Memory Controller and there is
> duplication of the retrieval code among the drivers.
>
> Add new devm_tegra_memory_controller_get() helper to remove the code's
> duplication and to fix put_d
Hi Wang.
Thanks for the fix.
On Fri, Nov 06, 2020 at 10:31:19AM +0800, Wang Qing wrote:
> a6xx_gmu_get_mmio() never return null in case of error, but ERR_PTR(),
> so we should use IS_ERR() instead of null pointer check
>
> Signed-off-by: Wang Qing
In the future please put "drm/:" in the subjec
On Wed, Nov 04, 2020 at 07:48:55PM +0300, Dmitry Osipenko wrote:
> Each memory client has unique hardware ID, add these IDs.
>
> Reviewed-by: Rob Herring
> Signed-off-by: Dmitry Osipenko
> ---
> include/dt-bindings/memory/tegra124-mc.h | 68
> 1 file changed, 68 inserti
On 05/11/2020 20:56, H. Nikolaus Schaller wrote:
>
>> Am 05.11.2020 um 19:28 schrieb Tomi Valkeinen :
>>
>> On 05/11/2020 20:14, H. Nikolaus Schaller wrote:
>>>
Am 05.11.2020 um 18:36 schrieb Tomi Valkeinen :
Hi,
On 05/11/2020 19:15, H. Nikolaus Schaller wrote:
>
On Wed, Nov 04, 2020 at 07:48:54PM +0300, Dmitry Osipenko wrote:
> Each memory client has unique hardware ID, add these IDs.
>
> Acked-by: Rob Herring
> Signed-off-by: Dmitry Osipenko
> ---
> include/dt-bindings/memory/tegra30-mc.h | 67 +
> 1 file changed, 67 insertions
On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote:
> Each memory client has unique hardware ID, add these IDs.
>
> Acked-by: Rob Herring
> Signed-off-by: Dmitry Osipenko
> ---
> include/dt-bindings/memory/tegra20-mc.h | 53 +
> 1 file changed, 53 insertions
On Wed, Nov 04, 2020 at 07:48:50PM +0300, Dmitry Osipenko wrote:
> Document new OPP table and voltage regulator properties which are needed
> for supporting dynamic voltage-frequency scaling of the memory controller.
> Some boards may have a fixed core voltage regulator, hence it's optional
> becau
On Wed, Nov 04, 2020 at 07:48:52PM +0300, Dmitry Osipenko wrote:
> Most of Host1x devices have at least one memory client. These clients
> are directly connected to the memory controller. The new interconnect
> properties represent the memory client's connection to the memory
> controller.
>
> Rev
On Wed, Nov 04, 2020 at 07:48:49PM +0300, Dmitry Osipenko wrote:
> External memory controller is interconnected with memory controller and
> with external memory. Document new interconnect property which turns
> External Memory Controller into interconnect provider.
>
> Reviewed-by: Rob Herring
>
On Wed, Nov 04, 2020 at 07:48:51PM +0300, Dmitry Osipenko wrote:
> Document EMC DFS OPP table and interconnect paths that will be used
> for scaling of system's memory bandwidth based on memory utilization
> statistics. Previously ACTMON was supposed to drive EMC clock rate
> directly, but now it s
On Wed, Nov 04, 2020 at 07:48:48PM +0300, Dmitry Osipenko wrote:
> Memory controller is interconnected with memory clients and with the
> External Memory Controller. Document new interconnect property which
> turns memory controller into interconnect provider.
>
> Signed-off-by: Dmitry Osipenko
>
On Wed, Nov 04, 2020 at 07:48:47PM +0300, Dmitry Osipenko wrote:
> Document new OPP table and voltage regulator properties which are needed
> for supporting dynamic voltage-frequency scaling of the memory controller.
> Some boards may have a fixed core voltage regulator, hence it's optional
> becau
On Wed, Nov 04, 2020 at 07:48:46PM +0300, Dmitry Osipenko wrote:
> External memory controller is interconnected with memory controller and
> with external memory. Document new interconnect property which turns
> External Memory Controller into interconnect provider.
>
> Acked-by: Rob Herring
> Si
On Wed, Nov 04, 2020 at 07:48:44PM +0300, Dmitry Osipenko wrote:
> The SoC core voltage can't be changed without taking into account the
> clock rate of External Memory Controller. Document OPP table that will
> be used for dynamic voltage frequency scaling, taking into account EMC
> voltage requir
On Wed, Nov 04, 2020 at 07:48:45PM +0300, Dmitry Osipenko wrote:
> Memory controller is interconnected with memory clients and with the
> External Memory Controller. Document new interconnect property which
> turns memory controller into interconnect provider.
>
> Acked-by: Rob Herring
> Signed-o
On Wed, Nov 04, 2020 at 07:48:42PM +0300, Dmitry Osipenko wrote:
> Memory controller is interconnected with memory clients and with the
> External Memory Controller. Document new interconnect property which
> turns memory controller into interconnect provider.
>
> Acked-by: Rob Herring
> Signed-o
On Wed, Nov 04, 2020 at 07:48:43PM +0300, Dmitry Osipenko wrote:
> External Memory Controller is interconnected with memory controller and
> with external memory. Document new interconnect property which turns EMC
> into interconnect provider.
>
> Acked-by: Rob Herring
> Signed-off-by: Dmitry Osi
On Wed, Nov 04, 2020 at 07:48:41PM +0300, Dmitry Osipenko wrote:
> Tegra20 External Memory Controller talks to DRAM chips and it needs to be
> reprogrammed when memory frequency changes. Tegra Memory Controller sits
> behind EMC and these controllers are tightly coupled. This patch adds the
> new p
On Wed, Nov 04, 2020 at 07:48:40PM +0300, Dmitry Osipenko wrote:
> There is superfluous zero in the registers base address and registers
> size should be twice bigger.
>
> Acked-by: Rob Herring
> Acked-by: Thierry Reding
> Signed-off-by: Dmitry Osipenko
> ---
> .../bindings/memory-controllers/
On Wed, Nov 04, 2020 at 07:48:39PM +0300, Dmitry Osipenko wrote:
> Drivers that use tegra_sku_info and have COMPILE_TEST are failing to be
> build due to the missing stub for tegra_sku_info, thus add the missing
> stub.
>
> Signed-off-by: Dmitry Osipenko
> ---
> include/soc/tegra/fuse.h | 4
On Wed, Nov 04, 2020 at 07:48:38PM +0300, Dmitry Osipenko wrote:
> The tegra_read_ram_code() is used by EMC drivers and we're going to make
> these driver modular, hence this function needs to be exported.
>
> Acked-by: Thierry Reding
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/soc/tegra/f
On Wed, Nov 04, 2020 at 07:48:37PM +0300, Dmitry Osipenko wrote:
> We're going to modularize Tegra EMC drivers and some of the EMC-clock
> driver symbols need to be exported, let's export them.
>
> Acked-by: Thierry Reding
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/clk/tegra/clk-tegra20-e
On 05/11/2020 20:07, Lee Jones wrote:
> On Thu, 05 Nov 2020, Tomi Valkeinen wrote:
>
>> On 05/11/2020 16:45, Lee Jones wrote:
>>> Fixes the following W=1 kernel build warning(s):
>>>
>>> drivers/gpu/drm/omapdrm/dss/dsi.c: In function ‘_dsi_print_reset_status’:
>>> drivers/gpu/drm/omapdrm/dss/dsi
> -Original Message-
> From: Jason Gunthorpe
> Sent: Friday, November 06, 2020 8:40 AM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PATCH
Hi Marek,
On 11/5/20 10:45 AM, Marek Vasut wrote:
> On 11/5/20 10:39 AM, Daniel Vetter wrote:
>> On Wed, Nov 04, 2020 at 01:52:00PM +0100, Marek Vasut wrote:
>>> Enable runtime PM before registering the fbdev emulation and disable it
>>> afterward, otherwise register access to the LTDC IP during t
On Fri, 06 Nov 2020, Sam Ravnborg wrote:
> Hi Lee,
> > >
> > > Applied to drm-misc-next.
> >
> > Thanks for all these Sam.
> >
> > Any idea what happens to the other patches?
> >
> > Do they go in via a different Maintainer?
>
> I expect the respective drm maintaines to take them.
> Give them
> -Original Message-
> From: Jason Gunthorpe
> Sent: Thursday, November 05, 2020 4:09 PM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PAT
> -Original Message-
> From: Jason Gunthorpe
> Sent: Thursday, November 05, 2020 4:13 PM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PAT
Hi Thomas.
On Fri, Nov 06, 2020 at 02:16:32PM +0100, Thomas Zimmermann wrote:
> As GEM object functions are now mandatory, DRM drivers based on CMA
> helpers either set them in their implementation of gem_create_object,
> or use the default via drm_gem_cma_create_object_default_funcs().
>
> Simpl
On Fri, Nov 06, 2020 at 01:42:24PM +0100, Thomas Zimmermann wrote:
> Apparently, the function was never used at all.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
Indeed unused.
I expect you or Patrik to apply the patch.
Sam
> ---
> drivers/gpu/drm/gma500/gem.c
Hi Lee,
> >
> > Applied to drm-misc-next.
>
> Thanks for all these Sam.
>
> Any idea what happens to the other patches?
>
> Do they go in via a different Maintainer?
I expect the respective drm maintaines to take them.
Give them a few days to take action.
I look forward for the next set that
> -Original Message-
> From: Jason Gunthorpe
> Sent: Friday, November 06, 2020 4:49 AM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PATCH
Hi,
On Fri, Nov 6, 2020 at 11:15 PM Maxime Ripard wrote:
>
> Hi,
>
> Here's an attempt to removing the dma_direct_set_offset calls we have in
> numerous drivers and move all those quirks into a global notifier as suggested
> by Robin.
>
> Let me know what you think,
> Maxime
>
> Maxime Ripard (7)
Cached page mappings are now the default for SHMEM GEM objects. Remove
the obsolete create function for cached mappings.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 26 --
drivers/gpu/drm/mgag200/mgag200_drv.c | 1 -
drivers/gpu/drm/udl
SHMEM-buffer backing storage is allocated from system memory; which is
typically cachable. The default mode for SHMEM objects is writecombine
though.
Unify SHMEM semantics by defaulting to cached mappings. The exception
is pages imported via dma-buf. DMA memory is usually not cached.
DRM drivers
Shmem-allocated memory uses the system's default caching flags,
usually involving cached mappings.
By default, SHMEM GEM helpers map pages using writecombine. Only a few
drivers require this setting. Others revert it to default mappings
flags. Some could benefit from caching, but don't care.
Unif
On Fri, Nov 06, 2020 at 02:31:44PM +0100, Karol Herbst wrote:
> On Fri, Nov 6, 2020 at 3:17 AM Jeremy Cline wrote:
> >
> > Make use of the devm_drm_dev_alloc() API to bind the lifetime of
> > nouveau_drm structure to the drm_device. This is important because a
> > reference to nouveau_drm is acces
On Fri, 06 Nov 2020, Tomi Valkeinen wrote:
> On 05/11/2020 20:07, Lee Jones wrote:
> > On Thu, 05 Nov 2020, Tomi Valkeinen wrote:
> >
> >> On 05/11/2020 16:45, Lee Jones wrote:
> >>> Fixes the following W=1 kernel build warning(s):
> >>>
> >>> drivers/gpu/drm/omapdrm/dss/dsi.c: In function ‘_dsi
The pool parameter can be NULL if we free through the shrinker.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 44ec41aa78d6..1b96780b4989 1
On Sun, Nov 1, 2020 at 10:36 AM Sam Ravnborg wrote:
> On Fri, Oct 30, 2020 at 01:28:50AM +0100, Linus Walleij wrote:
> > The driver includes but doesn't use any symbols
> > from this file.
> >
> > Cc: Magnus Damm
> > Cc: Geert Uytterhoeven
> > Cc: linux-renesas-...@vger.kernel.org
> > Signed-of
On Fri, Nov 6, 2020 at 3:17 AM Jeremy Cline wrote:
>
> Make use of the devm_drm_dev_alloc() API to bind the lifetime of
> nouveau_drm structure to the drm_device. This is important because a
> reference to nouveau_drm is accessible from drm_device, which is
> provided to a number of DRM layer call
As GEM object functions are now mandatory, DRM drivers based on CMA
helpers either set them in their implementation of gem_create_object,
or use the default via drm_gem_cma_create_object_default_funcs().
Simplify this by setting the default CMA object functions for all
objects that don't have any
Apparently, the function was never used at all.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/gem.c | 6 --
drivers/gpu/drm/gma500/psb_drv.h | 2 --
2 files changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index 8f07de83b6fb.
On 2020-10-27 at 22:11:55 +0530, Anshuman Gupta wrote:
> Handle CP_IRQ in DEVICE_SERVICE_IRQ_VECTOR_ESI0
> It requires to call intel_hdcp_handle_cp_irq() in case
> of CP_IRQ is triggered by a sink in DP-MST topology.
>
> Cc: "Ville Syrjälä"
> Cc: Ramalingam C
> Reviewed-by: Uma Shankar
Reviewed
On 2020-10-27 at 22:12:08 +0530, Anshuman Gupta wrote:
> Enable HDCP 2.2 over DP MST.
> Authenticate and enable port encryption only once for
> an active HDCP 2.2 session, once port is authenticated
> and encrypted enable encryption for each stream that
> requires encryption on this port.
>
> Simi
Patch "495c10cc1c0c CHROMIUM: dma-buf: restore args..."
adds a workaround for a bug in mmap_region.
As the comment states ->mmap() callback can change
vma->vm_file and so we might call fput() on the wrong file.
Revert the workaround and proper fix this in mmap_region.
v2: drop the extra if in dm
Add the new vma_set_file() function to allow changing
vma->vm_file with the necessary refcount dance.
v2: add more users of this.
v3: add missing EXPORT_SYMBOL, rebase on mmap cleanup,
add comments why we drop the reference on two occasions.
v4: make it clear that changing an anonymous vma is
Hi Andrew,
can I get you Acked-by to merge this cleanup through the drm-misc-next branch?
The affected drivers are mostly from the DRM subsystem.
The fix for the other problem you pointed out in mmap_region() has already
shown up in that branch.
Thanks in advance,
Christian.
On 2020-10-27 at 22:12:01 +0530, Anshuman Gupta wrote:
> hdcp_port_data is specific to a port on which HDCP
> encryption is getting enabled, so encapsulate it to
> intel_digital_port.
> This will be required to enable HDCP 2.2 stream encryption.
>
> Cc: Ramalingam C
> Reviewed-by: Uma Shankar
>
On 2020-11-06 at 12:05:14 +0530, Anshuman Gupta wrote:
> On 2020-11-05 at 22:04:15 +0530, Ramalingam C wrote:
> > On 2020-10-27 at 22:12:04 +0530, Anshuman Gupta wrote:
> > > Add support for multiple mst stream in hdcp port data
> > > which will be used by RepeaterAuthStreamManage msg and
> > > HDC
On Sat, Oct 31, 2020 at 03:24:41AM -0400, Peilin Ye wrote:
> `struct console_font` is a UAPI structure, thus ideally should not be
> used for kernel internal abstraction. Remove some dummy .con_font_set,
> .con_font_default and .con_font_copy `struct consw` callback
> implementations, to make it cl
On Fri, Nov 6, 2020 at 11:01 AM Daniel Vetter wrote:
>
> On Fri, Nov 6, 2020 at 5:08 AM John Hubbard wrote:
> >
> > On 11/5/20 4:49 AM, Jason Gunthorpe wrote:
> > > On Thu, Nov 05, 2020 at 10:25:24AM +0100, Daniel Vetter wrote:
> > >>> /*
> > >>> * If we can't determine whether or not a pte is
On Fri, Nov 6, 2020 at 5:08 AM John Hubbard wrote:
>
> On 11/5/20 4:49 AM, Jason Gunthorpe wrote:
> > On Thu, Nov 05, 2020 at 10:25:24AM +0100, Daniel Vetter wrote:
> >>> /*
> >>> * If we can't determine whether or not a pte is special, then fail
> >>> immediately
> >>> * for ptes. Note, we c
On Sun, Nov 01, 2020 at 12:32:44PM +0200, Hassan Shahbazi wrote:
> On Sun, Nov 01, 2020 at 07:39:48AM +0100, Greg KH wrote:
> > On Sun, Nov 01, 2020 at 02:20:10AM +0200, Hassan Shahbazi wrote:
> > > Fix the checkpath.pl issue on fb_watterott.c. write_vmem and
> > > write_vmem_8bit functions are wit
On Wed, Nov 04, 2020 at 07:35:13PM +, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
Many of these now applied, please update the series against my
tty-testing branch a
Deferred probe is an expected return value for tegra_output_probe().
Given that the driver deals with it properly, there's no need to output
a warning that may potentially confuse users.
Signed-off-by: Jon Hunter
---
Changes since V2:
- Removed duplicate errno print
Changes since V1:
- This time,
On Fri, 06 Nov 2020, Ahmad Fatoum wrote:
> On 11/6/20 8:41 AM, Lee Jones wrote:
> > On Thu, 05 Nov 2020, Ahmad Fatoum wrote:
> >
> >> Hello Lee,
> >>
> >> On 11/5/20 3:45 PM, Lee Jones wrote:
> >>> In the macro for_each_oldnew_crtc_in_state() 'crtc_state' is provided
> >>> as a container for stat
1 - 100 of 165 matches
Mail list logo
