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 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: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: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: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: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: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: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: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: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: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: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: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: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: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: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: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 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: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
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: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
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: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: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 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: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 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: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: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: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:
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 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
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
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://
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
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
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/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_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/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 |
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
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
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/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
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
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
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/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/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
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
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
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: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]
>
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, 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
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_
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
101 - 165 of 165 matches
Mail list logo
