* Re: [soc:mediatek/dt] BUILD REGRESSION 189881af810d452b592ee958db43eb4c57df9803
From: Matthias Brugger @ 2020-05-22 20:54 UTC (permalink / raw)
To: kbuild test robot, arm; +Cc: linux-arm-kernel
In-Reply-To: <5ec7b744.ZcxrA/L/3+XSTqYO%lkp@intel.com>
Hi all,
Hi Arnd and Olof,
On 22/05/2020 13:28, kbuild test robot wrote:
> tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git mediatek/dt
> branch HEAD: 189881af810d452b592ee958db43eb4c57df9803 arm: dts: mt2701: Add usb2 device nodes
>
> Error/Warning in current branch:
>
> ERROR: Input tree has errors, aborting (use -f to force output)
>
> Error/Warning ids grouped by kconfigs:
>
> recent_errors
> `-- arm-randconfig-r035-20200520
> `-- ERROR:Input-tree-has-errors-aborting-(use-f-to-force-output)
Can you please explain me how to reproduce this. I'm not able to deduce that
form this email. I can then look into this and how to fix it. Although up to now
I don't understand where the relation with my dts32 changes is.
Regards,
Matthias
>
> elapsed time: 7969m
>
> configs tested: 274
> configs skipped: 59
>
> arm defconfig
> arm allyesconfig
> arm allmodconfig
> arm allnoconfig
> arm64 allyesconfig
> arm64 defconfig
> arm64 allmodconfig
> arm64 allnoconfig
> sparc allyesconfig
> mips allyesconfig
> m68k allyesconfig
> sh sh03_defconfig
> arm vf610m4_defconfig
> h8300 defconfig
> m68k hp300_defconfig
> powerpc pq2fads_defconfig
> parisc alldefconfig
> sh sh7770_generic_defconfig
> arm mvebu_v7_defconfig
> arm u300_defconfig
> mips cavium_octeon_defconfig
> microblaze defconfig
> powerpc64 alldefconfig
> arm integrator_defconfig
> arc nsimosci_hs_defconfig
> powerpc mpc5200_defconfig
> arm clps711x_defconfig
> mips xway_defconfig
> mips maltaup_defconfig
> arm hisi_defconfig
> um defconfig
> arm davinci_all_defconfig
> sh r7780mp_defconfig
> arm sunxi_defconfig
> arm mmp2_defconfig
> mips loongson1c_defconfig
> arm ep93xx_defconfig
> arc nsimosci_defconfig
> um allnoconfig
> sh secureedge5410_defconfig
> sh apsh4ad0a_defconfig
> powerpc allmodconfig
> s390 debug_defconfig
> sh ap325rxa_defconfig
> c6x defconfig
> h8300 h8300h-sim_defconfig
> arc axs103_smp_defconfig
> mips qi_lb60_defconfig
> ia64 bigsur_defconfig
> openrisc or1ksim_defconfig
> sh lboxre2_defconfig
> powerpc chrp32_defconfig
> sh polaris_defconfig
> c6x evmc6457_defconfig
> arm corgi_defconfig
> mips cu1000-neo_defconfig
> arm ixp4xx_defconfig
> arm mps2_defconfig
> sh microdev_defconfig
> mips allnoconfig
> arm exynos_defconfig
> mips db1xxx_defconfig
> arm64 alldefconfig
> sh sh2007_defconfig
> arm bcm2835_defconfig
> sparc sparc32_defconfig
> ia64 alldefconfig
> sh ecovec24_defconfig
> arm shannon_defconfig
> riscv nommu_k210_defconfig
> powerpc ppc64e_defconfig
> parisc generic-32bit_defconfig
> arc alldefconfig
> sh sh7710voipgw_defconfig
> arm pleb_defconfig
> h8300 alldefconfig
> microblaze mmu_defconfig
> powerpc ppc44x_defconfig
> mips tb0219_defconfig
> parisc defconfig
> s390 allyesconfig
> m68k m5307c3_defconfig
> mips mtx1_defconfig
> arm mv78xx0_defconfig
> arm oxnas_v6_defconfig
> arc vdk_hs38_defconfig
> sh se7751_defconfig
> arm netwinder_defconfig
> arm iop32x_defconfig
> mips ath25_defconfig
> arm pxa_defconfig
> arm mini2440_defconfig
> alpha defconfig
> mips malta_defconfig
> arm assabet_defconfig
> m68k defconfig
> arm h3600_defconfig
> ia64 allnoconfig
> mips loongson3_defconfig
> mips malta_kvm_guest_defconfig
> arc hsdk_defconfig
> arc tb10x_defconfig
> powerpc allnoconfig
> sh sdk7786_defconfig
> arm u8500_defconfig
> sparc64 allyesconfig
> mips lasat_defconfig
> mips tb0287_defconfig
> powerpc mgcoge_defconfig
> um x86_64_defconfig
> powerpc storcenter_defconfig
> sh shmin_defconfig
> powerpc ps3_defconfig
> sparc64 defconfig
> arm keystone_defconfig
> m68k m5272c3_defconfig
> parisc allyesconfig
> mips decstation_defconfig
> mips lemote2f_defconfig
> powerpc tqm8xx_defconfig
> arm shmobile_defconfig
> arm stm32_defconfig
> powerpc holly_defconfig
> mips tb0226_defconfig
> mips rt305x_defconfig
> sh se7750_defconfig
> arm s3c6400_defconfig
> arm pcm027_defconfig
> powerpc ppc64_defconfig
> h8300 h8s-sim_defconfig
> m68k m5208evb_defconfig
> sh se7721_defconfig
> mips sb1250_swarm_defconfig
> powerpc amigaone_defconfig
> parisc generic-64bit_defconfig
> c6x dsk6455_defconfig
> arm multi_v5_defconfig
> xtensa alldefconfig
> arm spear13xx_defconfig
> sh rts7751r2dplus_defconfig
> mips nlm_xlr_defconfig
> sh migor_defconfig
> powerpc mpc512x_defconfig
> nds32 defconfig
> arm moxart_defconfig
> um allyesconfig
> mips rb532_defconfig
> arm imote2_defconfig
> i386 allnoconfig
> i386 allyesconfig
> i386 defconfig
> i386 debian-10.3
> ia64 allmodconfig
> ia64 defconfig
> ia64 allyesconfig
> m68k allmodconfig
> m68k allnoconfig
> m68k sun3_defconfig
> nios2 defconfig
> nios2 allyesconfig
> openrisc defconfig
> c6x allyesconfig
> c6x allnoconfig
> openrisc allyesconfig
> nds32 allnoconfig
> csky allyesconfig
> csky defconfig
> alpha allyesconfig
> xtensa allyesconfig
> h8300 allyesconfig
> h8300 allmodconfig
> xtensa defconfig
> arc defconfig
> arc allyesconfig
> sh allmodconfig
> sh allnoconfig
> microblaze allnoconfig
> mips allmodconfig
> parisc allnoconfig
> parisc allmodconfig
> powerpc allyesconfig
> powerpc rhel-kconfig
> powerpc defconfig
> x86_64 randconfig-a005-20200517
> x86_64 randconfig-a003-20200517
> x86_64 randconfig-a006-20200517
> x86_64 randconfig-a004-20200517
> x86_64 randconfig-a001-20200517
> x86_64 randconfig-a002-20200517
> i386 randconfig-a006-20200518
> i386 randconfig-a005-20200518
> i386 randconfig-a001-20200518
> i386 randconfig-a003-20200518
> i386 randconfig-a004-20200518
> i386 randconfig-a002-20200518
> i386 randconfig-a006-20200519
> i386 randconfig-a005-20200519
> i386 randconfig-a001-20200519
> i386 randconfig-a003-20200519
> i386 randconfig-a004-20200519
> i386 randconfig-a002-20200519
> i386 randconfig-a006-20200517
> i386 randconfig-a005-20200517
> i386 randconfig-a003-20200517
> i386 randconfig-a001-20200517
> i386 randconfig-a004-20200517
> i386 randconfig-a002-20200517
> i386 randconfig-a001-20200520
> i386 randconfig-a004-20200520
> i386 randconfig-a006-20200520
> i386 randconfig-a003-20200520
> i386 randconfig-a002-20200520
> i386 randconfig-a005-20200520
> x86_64 randconfig-a003-20200519
> x86_64 randconfig-a005-20200519
> x86_64 randconfig-a004-20200519
> x86_64 randconfig-a006-20200519
> x86_64 randconfig-a002-20200519
> x86_64 randconfig-a001-20200519
> x86_64 randconfig-a016-20200518
> x86_64 randconfig-a012-20200518
> x86_64 randconfig-a015-20200518
> x86_64 randconfig-a013-20200518
> x86_64 randconfig-a011-20200518
> x86_64 randconfig-a014-20200518
> x86_64 randconfig-a013-20200520
> x86_64 randconfig-a015-20200520
> x86_64 randconfig-a016-20200520
> x86_64 randconfig-a012-20200520
> x86_64 randconfig-a014-20200520
> x86_64 randconfig-a011-20200520
> i386 randconfig-a012-20200518
> i386 randconfig-a014-20200518
> i386 randconfig-a016-20200518
> i386 randconfig-a011-20200518
> i386 randconfig-a015-20200518
> i386 randconfig-a013-20200518
> i386 randconfig-a012-20200517
> i386 randconfig-a016-20200517
> i386 randconfig-a014-20200517
> i386 randconfig-a011-20200517
> i386 randconfig-a013-20200517
> i386 randconfig-a015-20200517
> i386 randconfig-a012-20200519
> i386 randconfig-a014-20200519
> i386 randconfig-a016-20200519
> i386 randconfig-a011-20200519
> i386 randconfig-a015-20200519
> i386 randconfig-a013-20200519
> i386 randconfig-a013-20200520
> i386 randconfig-a012-20200520
> i386 randconfig-a015-20200520
> i386 randconfig-a011-20200520
> i386 randconfig-a016-20200520
> i386 randconfig-a014-20200520
> riscv allyesconfig
> riscv allnoconfig
> riscv defconfig
> riscv allmodconfig
> s390 allnoconfig
> s390 allmodconfig
> s390 defconfig
> x86_64 defconfig
> sparc defconfig
> sparc64 allnoconfig
> sparc64 allmodconfig
> um allmodconfig
> x86_64 rhel-7.6-kselftests
> x86_64 rhel
> x86_64 rhel-7.6
> x86_64 rhel-7.2-clear
> x86_64 lkp
> x86_64 fedora-25
> x86_64 kexec
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 02/20] spi: spi-mem: allow specifying a command's extension
From: Pratyush Yadav @ 2020-05-22 20:30 UTC (permalink / raw)
To: Boris Brezillon
Cc: Alexandre Belloni, Vignesh Raghavendra, Tudor Ambarus,
Richard Weinberger, Sekhar Nori, linux-kernel, linux-spi,
Ludovic Desroches, Mark Brown, linux-mtd, Miquel Raynal,
Matthias Brugger, linux-mediatek, Mason Yang, Pratyush Yadav,
linux-arm-kernel
In-Reply-To: <20200522173254.05316d47@collabora.com>
On 22/05/20 05:32PM, Boris Brezillon wrote:
> On Fri, 22 May 2020 15:42:43 +0530
> Pratyush Yadav <p.yadav@ti.com> wrote:
>
> > In xSPI mode, flashes expect 2-byte opcodes. The second byte is called
> > the "command extension". There can be 3 types of extensions in xSPI:
> > repeat, invert, and hex. When the extension type is "repeat", the same
> > opcode is sent twice. When it is "invert", the second byte is the
> > inverse of the opcode. When it is "hex" an additional opcode byte based
> > is sent with the command whose value can be anything.
> >
> > So, make opcode a 16-bit value and add a 'nbytes', similar to how
> > multiple address widths are handled.
>
> A slightly different version of patch 5 should go before this patch,
> otherwise your series is not bisectable. By slightly different, I mean
> that you should only write one byte, but put this byte in a temporary
> var. Or maybe you can squash patch 5 in this one and mention why you do
> so in your commit message.
How about the patch below before this patch? The supports_op() will
reject multi-byte opcodes anyway, so we only care about single-byte
opcodes for now. Multi-byte opcodes can be patched and tested later.
This avoids squashing changes in this patch and having the changes split
over two patches; one before and one after.
-- 8< --
diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index 69491f3a515d..4e4292f0ee1d 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -356,6 +356,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
int nio = 1, i, ret;
u32 ss_ctrl;
u8 addr[8];
+ u8 opcode = op->cmd.opcode & 0xff;
ret = mxic_spi_set_freq(mxic, mem->spi->max_speed_hz);
if (ret)
@@ -393,7 +394,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
writel(readl(mxic->regs + HC_CFG) | HC_CFG_MAN_CS_ASSERT,
mxic->regs + HC_CFG);
- ret = mxic_spi_data_xfer(mxic, &op->cmd.opcode, NULL, 1);
+ ret = mxic_spi_data_xfer(mxic, &opcode, NULL, 1);
if (ret)
goto out;
--
Regards,
Pratyush Yadav
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 15/21] drm/rcar-du: Use GEM CMA object functions
From: Laurent Pinchart @ 2020-05-22 20:12 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: alexandre.belloni, linux-aspeed, narmstrong, airlied,
linus.walleij, liviu.dudau, stefan, philippe.cornu, paul,
benjamin.gaignard, mihail.atanassov, sam, alexandre.torgue, marex,
festevam, abrodkin, ludovic.desroches, xinliang.liu,
kong.kongxinwei, tomi.valkeinen, james.qian.wang, joel, linux-imx,
p.zabel, puck.chen, s.hauer, alison.wang, maarten.lankhorst,
mripard, john.stultz, jsarha, wens, vincent.abriou, kernel,
linux-arm-kernel, mcoquelin.stm32, noralf, bbrezillon, andrew,
dri-devel, yannick.fertre, kieran.bingham+renesas, daniel,
khilman, zourongrong, shawnguo, brian.starkey
In-Reply-To: <20200522135246.10134-16-tzimmermann@suse.de>
Hi Thomas,
Thank you for the patch.
On Fri, May 22, 2020 at 03:52:40PM +0200, Thomas Zimmermann wrote:
> The rcar-du driver uses the default implementation for CMA functions;
> except for the .dumb_create callback. The __DRM_GEM_CMA_DRIVER_OPS macro
> now sets these defaults and .dumb_create in struct drm_driver. All
> remaining operations are provided by CMA GEM object functions.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 11 +----------
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 3e67cf70f0402..3728038cec1d1 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -476,16 +476,7 @@ DEFINE_DRM_GEM_CMA_FOPS(rcar_du_fops);
>
> static struct drm_driver rcar_du_driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> - .gem_free_object_unlocked = drm_gem_cma_free_object,
> - .gem_vm_ops = &drm_gem_cma_vm_ops,
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
> - .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
> - .dumb_create = rcar_du_dumb_create,
> + __DRM_GEM_CMA_DRIVER_OPS(rcar_du_dumb_create),
Your __DRM_GEM_CMA_DRIVER_OPS is defined as
#define __DRM_GEM_CMA_DRIVER_OPS(__dumb_create) \
.gem_create_object = drm_cma_gem_create_object_default_funcs, \
.dumb_create = (__dumb_create), \
.prime_handle_to_fd = drm_gem_prime_handle_to_fd, \
.prime_fd_to_handle = drm_gem_prime_fd_to_handle, \
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table_vmap, \
.gem_prime_mmap = drm_gem_prime_mmap
The patch thus introduces several changes:
- drm_gem_cma_prime_import_sg_table_vmap() is used instead of
drm_gem_cma_prime_import_sg_table() combined with .gem_prime_vmap()
and .gem_prime_vunmap(). I believe that's fine, but splitting that
change in a separate commit, or at the very least explaining it in
details in the commit message, would make review easier.
- .gem_create_object() is now set. That seems to be OK, but I'm not sure
to grasp all the implications. This should also be explained in the
commit message, and ideally split to a separate patch.
- drm_gem_cma_prime_mmap() is replaced with drm_gem_prime_mmap(). Same
comments :-)
This patch hides way too many changes in what is documented as just
innocent refactoring. It seems other drivers are affected too.
> .fops = &rcar_du_fops,
> .name = "rcar-du",
> .desc = "Renesas R-Car Display Unit",
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 01/21] drm/cma-helper: Rework DRM_GEM_CMA_VMAP_DRIVER_OPS macro
From: Laurent Pinchart @ 2020-05-22 19:48 UTC (permalink / raw)
To: Sam Ravnborg
Cc: alexandre.belloni, linux-aspeed, narmstrong, airlied,
linus.walleij, liviu.dudau, stefan, philippe.cornu, paul,
benjamin.gaignard, mihail.atanassov, festevam, alexandre.torgue,
marex, khilman, abrodkin, ludovic.desroches, xinliang.liu,
kong.kongxinwei, tomi.valkeinen, james.qian.wang, joel, p.zabel,
linux-imx, daniel, puck.chen, s.hauer, alison.wang,
maarten.lankhorst, mripard, john.stultz, jsarha, wens,
vincent.abriou, kernel, linux-arm-kernel, mcoquelin.stm32, noralf,
bbrezillon, andrew, dri-devel, yannick.fertre,
kieran.bingham+renesas, Thomas Zimmermann, zourongrong, shawnguo,
brian.starkey
In-Reply-To: <20200522174835.GA1087580@ravnborg.org>
Hello,
On Fri, May 22, 2020 at 07:48:35PM +0200, Sam Ravnborg wrote:
> On Fri, May 22, 2020 at 03:52:26PM +0200, Thomas Zimmermann wrote:
> > Rename the macro to DRM_GEM_CMA_DRIVER_OPS to align with SHMEM
> > helpers.
>
> This part is fine, I like that the naming is somehow consistent.
>
> > An internal version is provided for drivers that override
> > the default .dumb_create callback. Adapt drivers to the changes.
> I loathe anything named __foo or __FOO. This __ signals to me
> that the author was clueless in naming - or some sort.
> I know that __ is used in some lib headers - but thats not the case
> here.
>
> But I love that we have a variant that takes a create function.
> So we do not have to escape from the nice macro.
> The macro is another way to tell me as rewiewer that this
> drivers uses all the default helpers for this.
>
>
> So critizising the name I better suggest something that
> I personally like better:
>
> DRM_GEM_CMA_DRIVER_OPS_CREATE()
>
> It would look like this:
> /* GEM Operations */
> - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> - .dumb_create = drm_sun4i_gem_dumb_create,
> + DRM_GEM_CMA_DRIVER_OPS_CREATE(drm_sun4i_gem_dumb_create),
I agree with Sam here. With this change,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Please fix zte/zx_drm_drv.c which also uses DRM_GEM_CMA_VMAP_DRIVER_OPS.
>
> The naming is a bikeshedding topic that we may not agree on, soo..
>
> With zte fixed the patch is:
> Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
>
> > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> > ---
> > drivers/gpu/drm/drm_gem_cma_helper.c | 2 +-
> > drivers/gpu/drm/sun4i/sun4i_drv.c | 3 +--
> > drivers/gpu/drm/tidss/tidss_drv.c | 2 +-
> > drivers/gpu/drm/tiny/hx8357d.c | 2 +-
> > drivers/gpu/drm/tiny/ili9225.c | 2 +-
> > drivers/gpu/drm/tiny/ili9341.c | 2 +-
> > drivers/gpu/drm/tiny/ili9486.c | 2 +-
> > drivers/gpu/drm/tiny/mi0283qt.c | 2 +-
> > drivers/gpu/drm/tiny/repaper.c | 2 +-
> > drivers/gpu/drm/tiny/st7586.c | 2 +-
> > drivers/gpu/drm/tiny/st7735r.c | 2 +-
> > include/drm/drm_gem_cma_helper.h | 24 ++++++++++++++++++++----
> > 12 files changed, 31 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c b/drivers/gpu/drm/drm_gem_cma_helper.c
> > index 12e98fb28229d..6fa4d2f2e3987 100644
> > --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> > @@ -620,7 +620,7 @@ EXPORT_SYMBOL(drm_cma_gem_create_object_default_funcs);
> > * address set. This address is released when the object is freed.
> > *
> > * This function can be used as the &drm_driver.gem_prime_import_sg_table
> > - * callback. The DRM_GEM_CMA_VMAP_DRIVER_OPS() macro provides a shortcut to set
> > + * callback. The &DRM_GEM_CMA_DRIVER_OPS macro provides a shortcut to set
> > * the necessary DRM driver operations.
> > *
> > * Returns:
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > index 328272ff77d84..012855fd89c24 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > @@ -52,8 +52,7 @@ static struct drm_driver sun4i_drv_driver = {
> > .minor = 0,
> >
> > /* GEM Operations */
> > - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> > - .dumb_create = drm_sun4i_gem_dumb_create,
> > + __DRM_GEM_CMA_DRIVER_OPS(drm_sun4i_gem_dumb_create),
> > };
> >
> > static int sun4i_drv_bind(struct device *dev)
> > diff --git a/drivers/gpu/drm/tidss/tidss_drv.c b/drivers/gpu/drm/tidss/tidss_drv.c
> > index 99edc66ebdef2..1753cdc74ebda 100644
> > --- a/drivers/gpu/drm/tidss/tidss_drv.c
> > +++ b/drivers/gpu/drm/tidss/tidss_drv.c
> > @@ -112,7 +112,7 @@ static struct drm_driver tidss_driver = {
> > .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> > .fops = &tidss_fops,
> > .release = tidss_release,
> > - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> > + DRM_GEM_CMA_DRIVER_OPS,
> > .name = "tidss",
> > .desc = "TI Keystone DSS",
> > .date = "20180215",
> > diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c
> > index b4bc358a3269a..592da71d7ca70 100644
> > --- a/drivers/gpu/drm/tiny/hx8357d.c
> > +++ b/drivers/gpu/drm/tiny/hx8357d.c
> > @@ -196,7 +196,7 @@ DEFINE_DRM_GEM_CMA_FOPS(hx8357d_fops);
> > static struct drm_driver hx8357d_driver = {
> > .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> > .fops = &hx8357d_fops,
> > - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> > + DRM_GEM_CMA_DRIVER_OPS,
> > .debugfs_init = mipi_dbi_debugfs_init,
> > .name = "hx8357d",
> > .desc = "HX8357D",
> > diff --git a/drivers/gpu/drm/tiny/ili9225.c b/drivers/gpu/drm/tiny/ili9225.c
> > index d1a5ab6747d5c..368ff6c8a1efb 100644
> > --- a/drivers/gpu/drm/tiny/ili9225.c
> > +++ b/drivers/gpu/drm/tiny/ili9225.c
> > @@ -346,7 +346,7 @@ DEFINE_DRM_GEM_CMA_FOPS(ili9225_fops);
> > static struct drm_driver ili9225_driver = {
> > .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> > .fops = &ili9225_fops,
> > - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> > + DRM_GEM_CMA_DRIVER_OPS,
> > .name = "ili9225",
> > .desc = "Ilitek ILI9225",
> > .date = "20171106",
> > diff --git a/drivers/gpu/drm/tiny/ili9341.c b/drivers/gpu/drm/tiny/ili9341.c
> > index bb819f45a5d3b..e1b9043ef7a0a 100644
> > --- a/drivers/gpu/drm/tiny/ili9341.c
> > +++ b/drivers/gpu/drm/tiny/ili9341.c
> > @@ -152,7 +152,7 @@ DEFINE_DRM_GEM_CMA_FOPS(ili9341_fops);
> > static struct drm_driver ili9341_driver = {
> > .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> > .fops = &ili9341_fops,
> > - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> > + DRM_GEM_CMA_DRIVER_OPS,
> > .debugfs_init = mipi_dbi_debugfs_init,
> > .name = "ili9341",
> > .desc = "Ilitek ILI9341",
> > diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
> > index 2702ea557d297..90a17f40fdf0c 100644
> > --- a/drivers/gpu/drm/tiny/ili9486.c
> > +++ b/drivers/gpu/drm/tiny/ili9486.c
> > @@ -165,7 +165,7 @@ DEFINE_DRM_GEM_CMA_FOPS(ili9486_fops);
> > static struct drm_driver ili9486_driver = {
> > .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> > .fops = &ili9486_fops,
> > - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> > + DRM_GEM_CMA_DRIVER_OPS,
> > .debugfs_init = mipi_dbi_debugfs_init,
> > .name = "ili9486",
> > .desc = "Ilitek ILI9486",
> > diff --git a/drivers/gpu/drm/tiny/mi0283qt.c b/drivers/gpu/drm/tiny/mi0283qt.c
> > index 08ac549ab0f7f..6624c2098fba2 100644
> > --- a/drivers/gpu/drm/tiny/mi0283qt.c
> > +++ b/drivers/gpu/drm/tiny/mi0283qt.c
> > @@ -156,7 +156,7 @@ DEFINE_DRM_GEM_CMA_FOPS(mi0283qt_fops);
> > static struct drm_driver mi0283qt_driver = {
> > .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> > .fops = &mi0283qt_fops,
> > - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> > + DRM_GEM_CMA_DRIVER_OPS,
> > .debugfs_init = mipi_dbi_debugfs_init,
> > .name = "mi0283qt",
> > .desc = "Multi-Inno MI0283QT",
> > diff --git a/drivers/gpu/drm/tiny/repaper.c b/drivers/gpu/drm/tiny/repaper.c
> > index 1c0e7169545b4..877dcece25828 100644
> > --- a/drivers/gpu/drm/tiny/repaper.c
> > +++ b/drivers/gpu/drm/tiny/repaper.c
> > @@ -946,7 +946,7 @@ DEFINE_DRM_GEM_CMA_FOPS(repaper_fops);
> > static struct drm_driver repaper_driver = {
> > .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> > .fops = &repaper_fops,
> > - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> > + DRM_GEM_CMA_DRIVER_OPS,
> > .name = "repaper",
> > .desc = "Pervasive Displays RePaper e-ink panels",
> > .date = "20170405",
> > diff --git a/drivers/gpu/drm/tiny/st7586.c b/drivers/gpu/drm/tiny/st7586.c
> > index 2a1fae422f7a2..ec84bdc51f60d 100644
> > --- a/drivers/gpu/drm/tiny/st7586.c
> > +++ b/drivers/gpu/drm/tiny/st7586.c
> > @@ -285,7 +285,7 @@ DEFINE_DRM_GEM_CMA_FOPS(st7586_fops);
> > static struct drm_driver st7586_driver = {
> > .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> > .fops = &st7586_fops,
> > - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> > + DRM_GEM_CMA_DRIVER_OPS,
> > .debugfs_init = mipi_dbi_debugfs_init,
> > .name = "st7586",
> > .desc = "Sitronix ST7586",
> > diff --git a/drivers/gpu/drm/tiny/st7735r.c b/drivers/gpu/drm/tiny/st7735r.c
> > index 0af1b15efdf8a..cfd4933f3b30c 100644
> > --- a/drivers/gpu/drm/tiny/st7735r.c
> > +++ b/drivers/gpu/drm/tiny/st7735r.c
> > @@ -157,7 +157,7 @@ DEFINE_DRM_GEM_CMA_FOPS(st7735r_fops);
> > static struct drm_driver st7735r_driver = {
> > .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> > .fops = &st7735r_fops,
> > - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> > + DRM_GEM_CMA_DRIVER_OPS,
> > .debugfs_init = mipi_dbi_debugfs_init,
> > .name = "st7735r",
> > .desc = "Sitronix ST7735R",
> > diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
> > index 947ac95eb24a9..917d42603db06 100644
> > --- a/include/drm/drm_gem_cma_helper.h
> > +++ b/include/drm/drm_gem_cma_helper.h
> > @@ -110,21 +110,37 @@ struct drm_gem_object *
> > drm_cma_gem_create_object_default_funcs(struct drm_device *dev, size_t size);
> >
> > /**
> > - * DRM_GEM_CMA_VMAP_DRIVER_OPS - CMA GEM driver operations ensuring a virtual
> > - * address on the buffer
> > + * __DRM_GEM_CMA_DRIVER_OPS - CMA GEM driver operations ensuring a
> > + * virtual address on the buffer
> > + * @__dumb_create: callback function for .dumb_create
> > *
> > * This macro provides a shortcut for setting the default GEM operations in the
> > * &drm_driver structure for drivers that need the virtual address also on
> > * imported buffers.
> > + *
> > + * This macro is a variant of DRM_GEM_CMA_DRIVER_OPS for drivers that
> > + * override the default implementation of .dumb_create. Use
> > + * DRM_GEM_CMA_DRIVER_OPS if possible.
> > */
> > -#define DRM_GEM_CMA_VMAP_DRIVER_OPS \
> > +#define __DRM_GEM_CMA_DRIVER_OPS(__dumb_create) \
> > .gem_create_object = drm_cma_gem_create_object_default_funcs, \
> > - .dumb_create = drm_gem_cma_dumb_create, \
> > + .dumb_create = (__dumb_create), \
> > .prime_handle_to_fd = drm_gem_prime_handle_to_fd, \
> > .prime_fd_to_handle = drm_gem_prime_fd_to_handle, \
> > .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table_vmap, \
> > .gem_prime_mmap = drm_gem_prime_mmap
> >
> > +/**
> > + * DRM_GEM_CMA_DRIVER_OPS - CMA GEM driver operations ensuring a virtual
> > + * address on the buffer
> > + *
> > + * This macro provides a shortcut for setting the default GEM operations in the
> > + * &drm_driver structure for drivers that need the virtual address also on
> > + * imported buffers.
> > + */
> > +#define DRM_GEM_CMA_DRIVER_OPS \
> > + __DRM_GEM_CMA_DRIVER_OPS(drm_gem_cma_dumb_create)
> > +
> > struct drm_gem_object *
> > drm_gem_cma_prime_import_sg_table_vmap(struct drm_device *drm,
> > struct dma_buf_attachment *attach,
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] remoteproc: add support for a new 64-bit trace version
From: Clément Leger @ 2020-05-22 19:28 UTC (permalink / raw)
To: s-anna
Cc: devicetree, Mathieu Poirier, Loic PALLARDY, Lokesh Vutla,
linux-remoteproc, Arnaud Pouliquen, linux-kernel, Bjorn Andersson,
Rob Herring, linux-arm-kernel
In-Reply-To: <4fab212b-a9d2-927e-d3d7-e591912fd6cf@ti.com>
Hi Suman,
----- On 22 May, 2020, at 20:59, s-anna s-anna@ti.com wrote:
> Hi Clement,
>
>> > ----- On 22 May, 2020, at 20:03, Clément Leger cleger@kalray.eu wrote:>
>>> Hi Suman,
>>>
>>> ----- On 22 May, 2020, at 19:33, Bjorn Andersson bjorn.andersson@linaro.org
>>> wrote:
>>>
>>>> On Fri 22 May 09:54 PDT 2020, Suman Anna wrote:
>>>>
>>>>> On 5/21/20 2:42 PM, Suman Anna wrote:
>>>>>> Hi Bjorn,
>>>>>>
>>>>>> On 5/21/20 1:04 PM, Bjorn Andersson wrote:
>>>>>>> On Wed 25 Mar 13:47 PDT 2020, Suman Anna wrote:
>>>> [..]
>>>>>>>> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
>>>> [..]
>>>>>>>> +struct fw_rsc_trace2 {
>>>>>>>
>>>>>>> Sounds more like fw_rsc_trace64 to me - in particular since the version
>>>>>>> of trace2 is 1...
>>>>>>
>>>>>> Yeah, will rename this.
>>>>>>
>>>>>>>
>>>>>>>> + u32 padding;
>>>>>>>> + u64 da;
>>>>>>>> + u32 len;
>>>>>>>> + u32 reserved;
>>>>>>>
>>>>>>> What's the purpose of this reserved field?
>>>>>>
>>>>>> Partly to make sure the entire resource is aligned on an 8-byte, and
>>>>>> partly copied over from fw_rsc_trace entry. I guess 32-bits is already
>>>>>> large enough of a size for trace entries irrespective of 32-bit or
>>>>>> 64-bit traces, so I doubt if we want to make the len field also a u64.
>>>>>
>>>>> Looking at this again, I can drop both padding and reserved fields, if I
>>>>> move the len field before da. Any preferences/comments?
>>>
>> Sorry, my message went a bit too fast... So as I was saying:
>>
>> Not only the in-structure alignment matters but also in the resource table.
>> Since the resource table is often packed (see [1] for instance), if a trace
>> resource is embedded in the resource table after another resource aligned
>> on 32 bits only, your 64 bits trace field will potentially end up
>> misaligned.
>
> Right. Since one can mix and match the resources of different sizes and
> include them in any order, the onus is going to be on the resource table
> constructors to ensure the inter-resource alignments, if any are
> required. The resource table format allows you to add padding fields in
> between if needed, and the remoteproc core relies on the offsets.
Agreed
>
> I can only ensure the alignment within this resource structure with
> ready-available access and conversion to/from a 64-bit type, as long as
> the resource is starting on a 64-bit boundary.
>
>>
>> To overcome this, there is multiple solutions:
>>
>> - Split the 64 bits fields into 32bits low and high parts:
>> Since all resources are aligned on 32bits, it will be ok
>
> Yes, this is one solution. At the same time, this means you need
> additional conversion logic for converting to and from 64-bit field. In
> this particular case, da is the address of the trace buffer pointer on a
> 64-bit processor, so we can directly use the address of the trace
> buffer. Guess it is a question of easier translation vs packing the
> resource table as tight as possible.
You simply have to add two wrapper such as the following:
static inline void rproc_rsc_set_addr(u32 *low, u32 *hi, u64 val)
{
*low = lower_32_bits(val);
*hi = upper_32_bits(val);
}
static inline u64 rproc_rsc_get_addr(u32 low, u32 hi)
{
return ((u64) hi << 32) | low;
}
This is not really difficult to use and will ensure your new trace
resource can be used easily without breaking 32 bits alignment.
Breaking compatibility is an option also and it is probably needed
to document it clearly if it is chosen to do so.
>
>>
>> - Use memcpy_from/to_io when reading/writing such fields
>> As I said in a previous message this should probably be used since
>> the memories that are accessed by rproc are io mem (ioremap in almost
>> all drivers).
>
> Anything running out of DDR actually doesn't need the io mem semantics,
> so we actually need to be fixing the drivers. Blindly changing the
> current memcpy to memcpy_to_io in the core loader is also not right. Any
> internal memories properties will actually depend on the processor and
> SoC. Eg: The R5 TCM interfaces in general can be treated as normal memories.
Agreed, this is most of the case indeed where the memories are actually
accessible directly. But using ioremap potentially creates a mapping that
does not support misaligned accesses and so accesses should be always aligned.
memcpy_from/to_io ensures that.
IMHO, there is probably something to be rework since the drivers are mapping
the memories but the core is accessing this memory, knowing nothing about
how it was mapped.
Regards,
Clément
>
> regards
> Suman
>
>>
>> Regards,
>>
>> Clément
>>
>> [1]
>> https://github.com/OpenAMP/open-amp/blob/master/apps/machine/zynqmp_r5/rsc_table.h
>>>
>>>
>>>
>>>
>>>>>
>>>>
>>>> Sounds good to me.
>>>>
>>>> Thanks,
> >>> Bjorn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 05/21] drm/atmel-hlcdc: Use GEM CMA object functions
From: Sam Ravnborg @ 2020-05-22 19:25 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: alexandre.belloni, linux-aspeed, narmstrong, airlied,
linus.walleij, liviu.dudau, stefan, philippe.cornu, paul,
laurent.pinchart, benjamin.gaignard, mihail.atanassov, festevam,
alexandre.torgue, marex, khilman, abrodkin, ludovic.desroches,
xinliang.liu, kong.kongxinwei, tomi.valkeinen, james.qian.wang,
joel, linux-imx, p.zabel, puck.chen, s.hauer, alison.wang,
maarten.lankhorst, mripard, john.stultz, jsarha, wens,
vincent.abriou, kernel, linux-arm-kernel, mcoquelin.stm32, noralf,
bbrezillon, andrew, dri-devel, yannick.fertre,
kieran.bingham+renesas, daniel, zourongrong, shawnguo,
brian.starkey
In-Reply-To: <20200522135246.10134-6-tzimmermann@suse.de>
Hi Thomas.
On Fri, May 22, 2020 at 03:52:30PM +0200, Thomas Zimmermann wrote:
> The atmel-hlcdc driver uses the default implementation for CMA functions. The
> DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
> All remaining operations are provided by CMA GEM object functions.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 11 +----------
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 112aa5066ceed..871293d1aeeba 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -821,16 +821,7 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
> .irq_preinstall = atmel_hlcdc_dc_irq_uninstall,
> .irq_postinstall = atmel_hlcdc_dc_irq_postinstall,
> .irq_uninstall = atmel_hlcdc_dc_irq_uninstall,
> - .gem_free_object_unlocked = drm_gem_cma_free_object,
> - .gem_vm_ops = &drm_gem_cma_vm_ops,
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
> - .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
When using DRM_GEM_CMA_DRIVER_OPS gem_prime_mmap is set to
drm_gem_prime_mmap.
Why is this the same as drm_gem_cma_prime_mmap?
Maybe this is all obvious when you know all the CMA stuff,
but this puzzeled me.
Sam
> - .dumb_create = drm_gem_cma_dumb_create,
> + DRM_GEM_CMA_DRIVER_OPS,
> .fops = &fops,
> .name = "atmel-hlcdc",
> .desc = "Atmel HLCD Controller DRM",
> --
> 2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCH] thermal: mediatek: add suspend/resume callback
From: Daniel Lezcano @ 2020-05-22 19:08 UTC (permalink / raw)
To: Michael Kao, Zhang Rui, Eduardo Valentin, Rob Herring,
Mark Rutland, Matthias Brugger, hsinyi, linux-pm, srv_heupstream
Cc: Louis Yu, devicetree, linux-mediatek, linux-kernel,
linux-arm-kernel
In-Reply-To: <20200408090558.12410-2-michael.kao@mediatek.com>
On 08/04/2020 11:05, Michael Kao wrote:
> From: Louis Yu <louis.yu@mediatek.com>
>
> Add suspend/resume callback to disable/enable Mediatek thermal sensor
> respectively. Since thermal power domain is off in suspend, thermal driver
> needs re-initialization during resume.
>
> Signed-off-by: Louis Yu <louis.yu@mediatek.com>
> Signed-off-by: Michael Kao <michael.kao@mediatek.com>
[ ... ]
> +static int __maybe_unused mtk_thermal_suspend(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct mtk_thermal *mt = platform_get_drvdata(pdev);
> + int i, ret;
> +
Why is there a multi-controller loop in the probe and resume functions
and not here?
> + for (i = 0; i < mt->conf->num_banks; i++) {
> + ret = mtk_thermal_disable_sensing(mt, i);
> + if (ret)
> + goto out;
> + }
> +
> + /* disable buffer */
> + writel(readl(mt->apmixed_base + APMIXED_SYS_TS_CON1) |
> + APMIXED_SYS_TS_CON1_BUFFER_OFF,
> + mt->apmixed_base + APMIXED_SYS_TS_CON1);
> +
> + clk_disable_unprepare(mt->clk_peri_therm);
> + clk_disable_unprepare(mt->clk_auxadc);
> +
> + return 0;
> +
> +out:
> + dev_err(&pdev->dev, "Failed to wait until bus idle\n");
> +
> + return ret;
> +}
> +
> +static int __maybe_unused mtk_thermal_resume(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct mtk_thermal *mt = platform_get_drvdata(pdev);
> + int i, ret, ctrl_id;
> +
> + ret = device_reset(&pdev->dev);
> + if (ret)
> + return ret;
> +
> + ret = clk_prepare_enable(mt->clk_auxadc);
> + if (ret) {
> + dev_err(&pdev->dev, "Can't enable auxadc clk: %d\n", ret);
> + goto err_disable_clk_auxadc;
> + }
> +
> + ret = clk_prepare_enable(mt->clk_peri_therm);
> + if (ret) {
> + dev_err(&pdev->dev, "Can't enable peri clk: %d\n", ret);
> + goto err_disable_clk_peri_therm;
> + }
> +
> + for (ctrl_id = 0; ctrl_id < mt->conf->num_controller ; ctrl_id++)
> + for (i = 0; i < mt->conf->num_banks; i++)
> + mtk_thermal_init_bank(mt, i, mt->apmixed_phys_base,
> + mt->auxadc_phys_base, ctrl_id);
> +
> + return 0;
> +
> +err_disable_clk_peri_therm:
> + clk_disable_unprepare(mt->clk_peri_therm);
> +err_disable_clk_auxadc:
> + clk_disable_unprepare(mt->clk_auxadc);
> +
> + return ret;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(mtk_thermal_pm_ops,
> + mtk_thermal_suspend, mtk_thermal_resume);
> +
> static struct platform_driver mtk_thermal_driver = {
> .probe = mtk_thermal_probe,
> .remove = mtk_thermal_remove,
> .driver = {
> .name = "mtk-thermal",
> + .pm = &mtk_thermal_pm_ops,
> .of_match_table = mtk_thermal_of_match,
> },
> };
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 21/21] drm/zte: Use GEM CMA object functions
From: Sam Ravnborg @ 2020-05-22 19:03 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: alexandre.belloni, linux-aspeed, narmstrong, airlied,
linus.walleij, liviu.dudau, stefan, philippe.cornu, paul,
laurent.pinchart, benjamin.gaignard, mihail.atanassov, festevam,
alexandre.torgue, marex, khilman, abrodkin, ludovic.desroches,
xinliang.liu, kong.kongxinwei, tomi.valkeinen, james.qian.wang,
joel, linux-imx, p.zabel, puck.chen, s.hauer, alison.wang,
maarten.lankhorst, mripard, john.stultz, jsarha, wens,
vincent.abriou, kernel, linux-arm-kernel, mcoquelin.stm32, noralf,
bbrezillon, andrew, dri-devel, yannick.fertre,
kieran.bingham+renesas, daniel, zourongrong, shawnguo,
brian.starkey
In-Reply-To: <20200522135246.10134-22-tzimmermann@suse.de>
Hi Thomas.
On Fri, May 22, 2020 at 03:52:46PM +0200, Thomas Zimmermann wrote:
> The zte driver uses the default implementation for CMA functions. The
> DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
> All remaining operations are provided by CMA GEM object functions.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/gpu/drm/zte/zx_drm_drv.c | 11 +----------
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c
> index 1141c1ed1ed04..42c59eae0ea03 100644
> --- a/drivers/gpu/drm/zte/zx_drm_drv.c
> +++ b/drivers/gpu/drm/zte/zx_drm_drv.c
> @@ -36,16 +36,7 @@ DEFINE_DRM_GEM_CMA_FOPS(zx_drm_fops);
>
> static struct drm_driver zx_drm_driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> - .gem_free_object_unlocked = drm_gem_cma_free_object,
> - .gem_vm_ops = &drm_gem_cma_vm_ops,
> - .dumb_create = drm_gem_cma_dumb_create,
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
> - .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
> + DRM_GEM_CMA_VMAP_DRIVER_OPS,
s/_VMAP// as pointed out by Emil.
Sam
> .fops = &zx_drm_fops,
> .name = "zx-vou",
> .desc = "ZTE VOU Controller DRM",
> --
> 2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/3] ARM: pxa: remove Compulab pxa2xx boards
From: Mark Brown @ 2020-05-22 19:00 UTC (permalink / raw)
To: soc, Daniel Mack, Jaroslav Kysela, Liam Girdwood, Takashi Iwai,
Robert Jarzmik, Haojian Zhuang
Cc: linux-arm-kernel, Mike Rapoport, alsa-devel, linux-kernel,
Arnd Bergmann
In-Reply-To: <20200521185140.27276-1-robert.jarzmik@free.fr>
On Thu, 21 May 2020 20:51:37 +0200, Robert Jarzmik wrote:
> As these boards have no more users nor testers, and patching them has
> become a burden, be that because of the PCI part or the MTD NAND
> support, let's remove them.
>
> The cm-x300 will for now remain and represent Compulab boards at its
> best in the PXA department.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: pxa: remove Compulab pxa2xx boards
commit: 168aac9de09551bb0ac9bd3b7a311cd681894fc3
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] remoteproc: add support for a new 64-bit trace version
From: Suman Anna @ 2020-05-22 18:59 UTC (permalink / raw)
To: Clément Leger, Bjorn Andersson
Cc: devicetree, Mathieu Poirier, Loic PALLARDY, Lokesh Vutla,
Arnaud Pouliquen, linux-remoteproc, linux-kernel, Rob Herring,
linux-arm-kernel
In-Reply-To: <1334263091.4218509.1590171014972.JavaMail.zimbra@kalray.eu>
Hi Clement,
> > ----- On 22 May, 2020, at 20:03, Clément Leger cleger@kalray.eu wrote:>
>> Hi Suman,
>>
>> ----- On 22 May, 2020, at 19:33, Bjorn Andersson bjorn.andersson@linaro.org
>> wrote:
>>
>>> On Fri 22 May 09:54 PDT 2020, Suman Anna wrote:
>>>
>>>> On 5/21/20 2:42 PM, Suman Anna wrote:
>>>>> Hi Bjorn,
>>>>>
>>>>> On 5/21/20 1:04 PM, Bjorn Andersson wrote:
>>>>>> On Wed 25 Mar 13:47 PDT 2020, Suman Anna wrote:
>>> [..]
>>>>>>> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
>>> [..]
>>>>>>> +struct fw_rsc_trace2 {
>>>>>>
>>>>>> Sounds more like fw_rsc_trace64 to me - in particular since the version
>>>>>> of trace2 is 1...
>>>>>
>>>>> Yeah, will rename this.
>>>>>
>>>>>>
>>>>>>> + u32 padding;
>>>>>>> + u64 da;
>>>>>>> + u32 len;
>>>>>>> + u32 reserved;
>>>>>>
>>>>>> What's the purpose of this reserved field?
>>>>>
>>>>> Partly to make sure the entire resource is aligned on an 8-byte, and
>>>>> partly copied over from fw_rsc_trace entry. I guess 32-bits is already
>>>>> large enough of a size for trace entries irrespective of 32-bit or
>>>>> 64-bit traces, so I doubt if we want to make the len field also a u64.
>>>>
>>>> Looking at this again, I can drop both padding and reserved fields, if I
>>>> move the len field before da. Any preferences/comments?
>>
> Sorry, my message went a bit too fast... So as I was saying:
>
> Not only the in-structure alignment matters but also in the resource table.
> Since the resource table is often packed (see [1] for instance), if a trace
> resource is embedded in the resource table after another resource aligned
> on 32 bits only, your 64 bits trace field will potentially end up
> misaligned.
Right. Since one can mix and match the resources of different sizes and
include them in any order, the onus is going to be on the resource table
constructors to ensure the inter-resource alignments, if any are
required. The resource table format allows you to add padding fields in
between if needed, and the remoteproc core relies on the offsets.
I can only ensure the alignment within this resource structure with
ready-available access and conversion to/from a 64-bit type, as long as
the resource is starting on a 64-bit boundary.
>
> To overcome this, there is multiple solutions:
>
> - Split the 64 bits fields into 32bits low and high parts:
> Since all resources are aligned on 32bits, it will be ok
Yes, this is one solution. At the same time, this means you need
additional conversion logic for converting to and from 64-bit field. In
this particular case, da is the address of the trace buffer pointer on a
64-bit processor, so we can directly use the address of the trace
buffer. Guess it is a question of easier translation vs packing the
resource table as tight as possible.
>
> - Use memcpy_from/to_io when reading/writing such fields
> As I said in a previous message this should probably be used since
> the memories that are accessed by rproc are io mem (ioremap in almost
> all drivers).
Anything running out of DDR actually doesn't need the io mem semantics,
so we actually need to be fixing the drivers. Blindly changing the
current memcpy to memcpy_to_io in the core loader is also not right. Any
internal memories properties will actually depend on the processor and
SoC. Eg: The R5 TCM interfaces in general can be treated as normal memories.
regards
Suman
>
> Regards,
>
> Clément
>
> [1] https://github.com/OpenAMP/open-amp/blob/master/apps/machine/zynqmp_r5/rsc_table.h
>>
>>
>>
>>
>>>>
>>>
>>> Sounds good to me.
>>>
>>> Thanks,
>>> Bjorn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 01/21] drm/cma-helper: Rework DRM_GEM_CMA_VMAP_DRIVER_OPS macro
From: Sam Ravnborg @ 2020-05-22 18:45 UTC (permalink / raw)
To: Emil Velikov
Cc: alexandre.belloni, linux-aspeed, Neil Armstrong, Dave Airlie,
Liviu Dudau, ML dri-devel, Paul Cercueil, Laurent Pinchart,
Mihail Atanassov, Marek Vašut, khilman, Alexey Brodkin,
Xinwei Kong, Xinliang Liu, ludovic.desroches, Tomi Valkeinen,
james qian wang (Arm Technology China), NXP Linux Team, joel,
Alexandre Torgue, Chen Feng, Sascha Hauer, Alison Wang,
Jyri Sarha, Chen-Yu Tsai, Vincent Abriou, Sascha Hauer, LAKML,
Maxime Coquelin, bbrezillon, andrew, Philippe Cornu,
Yannick Fertre, Kieran Bingham, Thomas Zimmermann, Rongrong Zou,
Shawn Guo
In-Reply-To: <CACvgo53YDOD1t4KYOWKiO-q8T639jNbMrZuyTXcbe1FBAfxP+Q@mail.gmail.com>
Hi Emil.
> > Please fix zte/zx_drm_drv.c which also uses DRM_GEM_CMA_VMAP_DRIVER_OPS.
> >
> Isn't DRM_GEM_CMA_VMAP_DRIVER_OPS introduced to zte with the last
> patch in the series?
You are right, I just applied all patches and throw them after my
build script and zte failed.
Sam
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] firmware: smccc: Add ARCH_SOC_ID support
From: Arnd Bergmann @ 2020-05-22 18:41 UTC (permalink / raw)
To: Sudeep Holla
Cc: Mark Rutland, Francois Ozog, Lorenzo Pieralisi, Jose.Marinho,
Greg Kroah-Hartman, linux-kernel@vger.kernel.org, harb,
Will Deacon, Linux ARM
In-Reply-To: <20200522165422.GA18810@bogus>
On Fri, May 22, 2020 at 6:54 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> (+ Jose (SMCCC Spec author))
>
> On Fri, May 22, 2020 at 04:46:12PM +0200, Arnd Bergmann wrote:
> > On Fri, May 22, 2020 at 2:50 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > > +
> > > + soc_id_rev = res.a0;
> > > +
> > > + soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
> > > + if (!soc_dev_attr)
> > > + return -ENOMEM;
> > > +
> > > + sprintf(soc_id_str, "0x%04x", IMP_DEF_SOC_ID(soc_id_version));
> > > + sprintf(soc_id_rev_str, "0x%08x", soc_id_rev);
> > > + sprintf(soc_id_jep106_id_str, "0x%02x%02x",
> > > + JEP106_BANK_CONT_CODE(soc_id_version),
> > > + JEP106_ID_CODE(soc_id_version));
> > > +
> > > + soc_dev_attr->soc_id = soc_id_str;
> > > + soc_dev_attr->revision = soc_id_rev_str;
> > > + soc_dev_attr->jep106_id = soc_id_jep106_id_str;
> >
> > Ok, let me try to understand how this maps the 64-bit ID into the
> > six strings in user space:
> >
> > For a chip that identifies as
> >
> > JEP106_BANK_CONT_CODE = 12
> > JEP106_ID_CODE = 34
> > IMP_DEF_SOC_ID = 5678
> > soc_id_rev = 9abcdef0
> >
> > the normal sysfs attributes contain these strings:
> >
> > machine = ""
> > family = ""
> > revision = "0x9abcdef0
> > serial_number = ""
> > soc_id = "0x5678"
> >
> > and the new attribute is
> >
> > jep106_identification_code = "0x1234"
> >
> > This still looks like a rather poorly designed interface to me, with a
> > number of downsides:
> >
> > - Nothing in those strings identifies the numbers as using jep106
> > numbers rather than some something else that might use strings
> > with hexadecimal numbers.
> >
>
> Not sure if I understand your concerns completely here.
>
> Anyways I wanted to clarify that the jep106 encoding is applicable only
> for manufacturer's id and not for SoC ID or revision. Not sure if that
> changes anything about your concerns.
The problem I see is that by looking at just the existing attributes,
you have no way of telling what namespace the strings are in,
and a script that tries pattern matching could confuse two
hexadecimal numbers from a different namespace, such as
pci vendor/device or usb vendor/device IDs that are similar
in spirit to the jep106 codes.
> > - I think we should have something unique in "family" just because
> > existing scripts can use that as the primary indentifier
This is part of the same issue: If we put just "jep106 identified SoC"
as the "family", it would be something a driver could match against.
> > How about making the contents:
> >
> > machine = "" /* could be a future addition, but board specific */
> > family = "jep106:1234"
>
> But this just indicates manufacturer id and nothing related to SoC family.
> If it is jep106:043b, all it indicates is Arm Ltd and assigning it to
> family doesn't sound right to me.
>
> I had requests for both of the above during the design of interface but
> I was told vendors were happy with the interface. I will let the authors
> speak about that.
In most cases, the existing drivers put a hardcoded string into the
family, such as
"Samsung Exynos"
"Freescale i.MX"
"Amlogic Meson"
or slightly more specific
"R-Car Gen2"
Having a numeric identifier for the SoC manufacturer here is a
bit more coarse than that, but would be similar in spirit.
> > soc_id = "jep106:1234:5678" /* duplicates family but makes it unique*/
>
> Not sure again.
> > That would work without any new properties, dropping the other patch,
> > and be easier to use for identification from user space.
> >
>
> OK, I agree on ease part. But for me, we don't have any property in the
> list to indicate the vendor/manufacturer's name. I don't see issue adding
> one, name can be fixed as jep106_identification_code is too specific.
>
> How about manufacturer with the value in the format "jep106:1234" if
> it is not normal string but jep106 encoding.
I don't think we need a real name like "Arm" or "Samsung" here,
but just a number is not enough, it should at least be something
that can be assumed to never conflict with the name of a chip
by another scheme.
jep106:5678 (the IMP_DEF_SOC_ID field in my example) would
probably be sufficient to not conflict with a another soc_device
driver, but is quite likely to clash with an ID used by another
manufacturer.
jep106:1234 (the manufacturer ID) in turn seems too broad from
the soc_id field, as that would include every chip made by one
company.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCHv3 2/2] dt-bindings: arm: coresight: Add optional property to replicators
From: Sai Prakash Ranjan @ 2020-05-22 18:36 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, Mike Leach, devicetree,
Rob Herring
Cc: linux-arm-msm, Sai Prakash Ranjan, linux-kernel, linux-arm-kernel,
Stephen Boyd
In-Reply-To: <cover.1590171891.git.saiprakash.ranjan@codeaurora.org>
Add an optional boolean property "qcom,replicator-loses-context" to
identify replicators which loses context when AMBA clocks are removed
in certain configurable replicator designs.
Reviewed-by: Mike Leach <mike.leach@linaro.org>
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
---
Documentation/devicetree/bindings/arm/coresight.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
index 846f6daae71b..b598a5f0037d 100644
--- a/Documentation/devicetree/bindings/arm/coresight.txt
+++ b/Documentation/devicetree/bindings/arm/coresight.txt
@@ -121,6 +121,12 @@ its hardware characteristcs.
* interrupts : Exactly one SPI may be listed for reporting the address
error
+* Optional property for configurable replicators:
+
+ * qcom,replicator-loses-context: boolean. Indicates that the replicator
+ will lose register context when AMBA clock is removed which is observed
+ in some replicator designs.
+
Graph bindings for Coresight
-------------------------------
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv3 1/2] coresight: replicator: Reset replicator if context is lost
From: Sai Prakash Ranjan @ 2020-05-22 18:36 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, Mike Leach, devicetree,
Rob Herring
Cc: linux-arm-msm, Sai Prakash Ranjan, linux-kernel, linux-arm-kernel,
Stephen Boyd
In-Reply-To: <cover.1590171891.git.saiprakash.ranjan@codeaurora.org>
On some QCOM SoCs, replicators in Always-On domain loses its
context as soon as the clock is disabled. Currently as a part
of pm_runtime workqueue, clock is disabled after the replicator
is initialized by amba_pm_runtime_suspend assuming that context
is not lost which is not true for replicators with such
limitations. So add a new property "qcom,replicator-loses-context"
to identify such replicators and reset them.
Suggested-by: Mike Leach <mike.leach@linaro.org>
Reviewed-by: Mike Leach <mike.leach@linaro.org>
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
---
.../coresight/coresight-replicator.c | 55 +++++++++++++------
1 file changed, 38 insertions(+), 17 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
index e7dc1c31d20d..9d3a8f915784 100644
--- a/drivers/hwtracing/coresight/coresight-replicator.c
+++ b/drivers/hwtracing/coresight/coresight-replicator.c
@@ -14,6 +14,7 @@
#include <linux/err.h>
#include <linux/slab.h>
#include <linux/pm_runtime.h>
+#include <linux/property.h>
#include <linux/clk.h>
#include <linux/of.h>
#include <linux/coresight.h>
@@ -32,12 +33,14 @@ DEFINE_CORESIGHT_DEVLIST(replicator_devs, "replicator");
* @atclk: optional clock for the core parts of the replicator.
* @csdev: component vitals needed by the framework
* @spinlock: serialize enable/disable operations.
+ * @check_idfilter_val: check if the context is lost upon clock removal.
*/
struct replicator_drvdata {
void __iomem *base;
struct clk *atclk;
struct coresight_device *csdev;
spinlock_t spinlock;
+ bool check_idfilter_val;
};
static void dynamic_replicator_reset(struct replicator_drvdata *drvdata)
@@ -66,29 +69,43 @@ static int dynamic_replicator_enable(struct replicator_drvdata *drvdata,
int inport, int outport)
{
int rc = 0;
- u32 reg;
-
- switch (outport) {
- case 0:
- reg = REPLICATOR_IDFILTER0;
- break;
- case 1:
- reg = REPLICATOR_IDFILTER1;
- break;
- default:
- WARN_ON(1);
- return -EINVAL;
- }
+ u32 id0val, id1val;
CS_UNLOCK(drvdata->base);
- if ((readl_relaxed(drvdata->base + REPLICATOR_IDFILTER0) == 0xff) &&
- (readl_relaxed(drvdata->base + REPLICATOR_IDFILTER1) == 0xff))
+ id0val = readl_relaxed(drvdata->base + REPLICATOR_IDFILTER0);
+ id1val = readl_relaxed(drvdata->base + REPLICATOR_IDFILTER1);
+
+ /*
+ * Some replicator designs lose context when AMBA clocks are removed,
+ * so have a check for this.
+ */
+ if (drvdata->check_idfilter_val && id0val == 0x0 && id1val == 0x0)
+ id0val = id1val = 0xff;
+
+ if (id0val == 0xff && id1val == 0xff)
rc = coresight_claim_device_unlocked(drvdata->base);
+ if (!rc) {
+ switch (outport) {
+ case 0:
+ id0val = 0x0;
+ break;
+ case 1:
+ id1val = 0x0;
+ break;
+ default:
+ WARN_ON(1);
+ rc = -EINVAL;
+ }
+ }
+
/* Ensure that the outport is enabled. */
- if (!rc)
- writel_relaxed(0x00, drvdata->base + reg);
+ if (!rc) {
+ writel_relaxed(id0val, drvdata->base + REPLICATOR_IDFILTER0);
+ writel_relaxed(id1val, drvdata->base + REPLICATOR_IDFILTER1);
+ }
+
CS_LOCK(drvdata->base);
return rc;
@@ -239,6 +256,10 @@ static int replicator_probe(struct device *dev, struct resource *res)
desc.groups = replicator_groups;
}
+ if (fwnode_property_present(dev_fwnode(dev),
+ "qcom,replicator-loses-context"))
+ drvdata->check_idfilter_val = true;
+
dev_set_drvdata(dev, drvdata);
pdata = coresight_get_platform_data(dev);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv3 0/2] Add support for replicators which loses context on clock removal
From: Sai Prakash Ranjan @ 2020-05-22 18:36 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, Mike Leach, devicetree,
Rob Herring
Cc: linux-arm-msm, Sai Prakash Ranjan, linux-kernel, linux-arm-kernel,
Stephen Boyd
This series is mainly to add support for replicators
which lose context on removing AMBA clock like on SC7180
SoC where replicator in AOSS domain loses context.
v2 - https://lore.kernel.org/patchwork/cover/1244340/
More discussion is found here - https://lore.kernel.org/patchwork/patch/1231182/
Changes since v2:
* Added DT maintainers which I missed in v2
* Added proper kernel-doc and header as per Mathieu
Sai Prakash Ranjan (2):
coresight: replicator: Reset replicator if context is lost
dt-bindings: arm: coresight: Add optional property to replicators
.../devicetree/bindings/arm/coresight.txt | 6 ++
.../coresight/coresight-replicator.c | 55 +++++++++++++------
2 files changed, 44 insertions(+), 17 deletions(-)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 04/19] spi: spi-mem: allow specifying a command's extension
From: Pratyush Yadav @ 2020-05-22 18:23 UTC (permalink / raw)
To: Boris Brezillon
Cc: Alexandre Belloni, Mason Yang, Vignesh Raghavendra, Tudor Ambarus,
Richard Weinberger, Sekhar Nori, linux-kernel, Ludovic Desroches,
Mark Brown, linux-mtd, Miquel Raynal, Matthias Brugger,
linux-mediatek, linux-spi, linux-arm-kernel
In-Reply-To: <20200521202256.5816eb32@collabora.com>
Hi Boris,
On 21/05/20 08:22PM, Boris Brezillon wrote:
> On Wed, 20 May 2020 22:00:38 +0530
> Pratyush Yadav <p.yadav@ti.com> wrote:
>
> As mentioned in one of my previous review, you should patch the mxic
> driver before extending the opcode field:
>
> --->8---
> diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
> index 69491f3a515d..c3f4136a7c1d 100644
> --- a/drivers/spi/spi-mxic.c
> +++ b/drivers/spi/spi-mxic.c
> @@ -356,6 +356,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
> int nio = 1, i, ret;
> u32 ss_ctrl;
> u8 addr[8];
> + u8 cmd[2];
Regarding your comment about bisect-ability, how about I change this to:
u8 cmd[sizeof(op->cmd.opcode)];
and put this patch before the change to 2-byte opcodes. This should also
make it resistent to further changes in opcode size. Does that sound
like a sane idea?
> ret = mxic_spi_set_freq(mxic, mem->spi->max_speed_hz);
> if (ret)
> @@ -393,7 +394,10 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
> writel(readl(mxic->regs + HC_CFG) | HC_CFG_MAN_CS_ASSERT,
> mxic->regs + HC_CFG);
>
> - ret = mxic_spi_data_xfer(mxic, &op->cmd.opcode, NULL, 1);
> + for (i = 0; i < op->cmd.nbytes; i++)
> + cmd[i] = op->cmd.opcode >> (8 * (op->cmd.nbytes - i - 1));
> +
> + ret = mxic_spi_data_xfer(mxic, cmd, NULL, op->cmd.nbytes);
> if (ret)
> goto out;
>
--
Regards,
Pratyush Yadav
Texas Instruments India
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 01/21] drm/cma-helper: Rework DRM_GEM_CMA_VMAP_DRIVER_OPS macro
From: Emil Velikov @ 2020-05-22 18:15 UTC (permalink / raw)
To: Sam Ravnborg
Cc: alexandre.belloni, linux-aspeed, Neil Armstrong, Dave Airlie,
Liviu Dudau, ML dri-devel, Paul Cercueil, Laurent Pinchart,
Mihail Atanassov, Marek Vašut, khilman, Alexey Brodkin,
Xinwei Kong, Xinliang Liu, ludovic.desroches, Tomi Valkeinen,
james qian wang (Arm Technology China), NXP Linux Team, joel,
Alexandre Torgue, Chen Feng, Sascha Hauer, Alison Wang,
Jyri Sarha, Chen-Yu Tsai, Vincent Abriou, Sascha Hauer, LAKML,
Maxime Coquelin, bbrezillon, andrew, Philippe Cornu,
Yannick Fertre, Kieran Bingham, Thomas Zimmermann, Rongrong Zou,
Shawn Guo
In-Reply-To: <20200522174835.GA1087580@ravnborg.org>
On Fri, 22 May 2020 at 18:48, Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Thomas.
>
> On Fri, May 22, 2020 at 03:52:26PM +0200, Thomas Zimmermann wrote:
> > Rename the macro to DRM_GEM_CMA_DRIVER_OPS to align with SHMEM
> > helpers.
> This part is fine, I like that the naming is somehow consistent.
>
> > An internal version is provided for drivers that override
> > the default .dumb_create callback. Adapt drivers to the changes.
> I loathe anything named __foo or __FOO. This __ signals to me
> that the author was clueless in naming - or some sort.
> I know that __ is used in some lib headers - but thats not the case
> here.
>
> But I love that we have a variant that takes a create function.
> So we do not have to escape from the nice macro.
> The macro is another way to tell me as rewiewer that this
> drivers uses all the default helpers for this.
>
Fwiw I share the sentiment, although I fear we're a little late. __
prefixed functions are widely common in core drm and it's helpers.
>
> So critizising the name I better suggest something that
> I personally like better:
>
> DRM_GEM_CMA_DRIVER_OPS_CREATE()
>
> It would look like this:
> /* GEM Operations */
> - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> - .dumb_create = drm_sun4i_gem_dumb_create,
> + DRM_GEM_CMA_DRIVER_OPS_CREATE(drm_sun4i_gem_dumb_create),
>
>
>
> Please fix zte/zx_drm_drv.c which also uses DRM_GEM_CMA_VMAP_DRIVER_OPS.
>
Isn't DRM_GEM_CMA_VMAP_DRIVER_OPS introduced to zte with the last
patch in the series?
-Emil
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v5 0/5] Nvidia Arm SMMUv2 Implementation
From: Krishna Reddy @ 2020-05-22 18:10 UTC (permalink / raw)
To: Thierry Reding
Cc: Thierry Reding, Bryan Huntsman, robin.murphy@arm.com,
joro@8bytes.org, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, Mikko Perttunen, Timo Alho,
Sachin Nikam, Nicolin Chen, linux-tegra@vger.kernel.org,
Yu-Huan Hsu, Pritesh Raithatha, will@kernel.org,
linux-arm-kernel@lists.infradead.org, Bitan Biswas
In-Reply-To: <20200522151444.GB2374603@ulmo>
>For the record: I don't think we should apply these because we don't have a good way of testing them. We currently have three problems that prevent us from enabling SMMU on Tegra194:
Out of three issues pointed here, I see that only issue 2) is a real blocker for enabling SMMU HW by default in upstream.
>That said, I have tested earlier versions of this patchset on top of my local branch with fixes for the above and they do seem to work as expected.
>So I'll leave it up to the IOMMU maintainers whether they're willing to merge the driver patches as is.
> But I want to clarify that I won't be applying the DTS patches until we've solved all of the above issues and therefore it should be clear that these won't be runtime tested until then.
SMMU driver patches as such are complete and can be used by nvidia with a local config change(CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n) to disable_bypass and
Protects the driver patches against kernel changes. This config disable option is tested already by Nicolin Chen and me.
Robin/Will, Can you comment if smmu driver patches alone(1,2,3 out of 5 patches) can be merged without DT enable patches? Is it reasonable to merge the driver patches alone?
>1) If we enable SMMU support, then the DMA API will automatically try
> to use SMMU domains for allocations. This means that translations
> will happen as soon as a device's IOMMU operations are initialized
> and that is typically a long time (in kernel time at least) before
> a driver is bound and has a chance of configuring the device.
> This causes problems for non-quiesced devices like display
> controllers that the bootloader might have set up to scan out a
> boot splash.
> What we're missing here is a way to:
> a) advertise reserved memory regions for boot splash framebuffers
> b) map reserved memory regions early during SMMU setup
> Patches have been floating on the public mailing lists for b) but
> a) requires changes to the bootloader (both proprietary ones and
> U-Boot for SoCs prior to Tegra194).
This happens if SMMU translations is enabled for display before reserved
Memory regions issue is fixed. This issue is not a real blocker for SMMU enable.
> 2) Even if we don't enable SMMU for a given device (by not hooking up
> the iommus property), with a default kernel configuration we get a
> bunch of faults during boot because the ARM SMMU driver faults by
> default (rather than bypass) for masters which aren't hooked up to
> the SMMU.
> We could work around that by changing the default configuration or
> overriding it on the command-line, but that's not really an option
> because it decreases security and means that Tegra194 won't work
> out-of-the-box.
This is the real issue that blocks enabling SMMU. The USF faults for devices
that don't have SMMU translations enabled should be fixed or WAR'ed before
SMMU can be enabled. We should look at keeping SID as 0x7F for the devices
that can't have SMMU enabled yet. SID 0x7f bypasses SMMU externally.
> 3) We don't properly describe the DMA hierarchy, which causes the DMA
> masks to be improperly set. As a bit of background: Tegra194 has a
> special address bit (bit 39) that causes some swizzling to happen
> within the memory controller. As a result, any I/O virtual address
> that has bit 39 set will cause this swizzling to happen on access.
> The DMA/IOMMU allocator always starts allocating from the top of
> the IOVA space, which means that the first couple of gigabytes of
> allocations will cause most devices to fail because of the
> undesired swizzling that occurs.
> We had an initial patch for SDHCI merged that hard-codes the DMA
> mask to DMA_BIT_MASK(39) on Tegra194 to work around that. However,
> the devices all do support addressing 40 bits and the restriction
> on bit 39 is really a property of the bus rather than a capability
> of the device. This means that we would have to work around this
> for every device driver by adding similar hacks. A better option is
> to properly describe the DMA hierarchy (using dma-ranges) because
> that will then automatically be applied as a constraint on each
> device's DMA mask.
> I have been working on patches to address this, but they are fairly
> involved because they require device tree bindings changes and so
> on.
Dma_mask issue is again outside SMMU driver and as long as the clients with
Dma_mask issue don't have SMMU enabled, it would be fine.
SDHCI can have SMMU enabled in upstream as soon as issue 2 is taken care.
>So before we solve all of the above issues we can't really enable SMMU on Tegra194 and hence won't be able to test it. As such we don't know if these patches even work, nor can we validate that they continue to work.
>As such, I don't think there's any use in applying these patches upstream since they will be effectively dead code until all of the above issues are resolved.
> arm64: tegra: Add DT node for T194 SMMU
> arm64: tegra: enable SMMU for SDHCI and EQOS on T194
>This one is going to cause EQOS to break because of 3) above. It might work for SDHCI because of the workaround we currently have in that driver. However, I do have a local patch that reverts the workaround and replaces it with the proper fix, which uses dma->ranges as mentioned above.
The DT patches can't be merged as of now. The enable patches can follow up later after issue 2 is fixed.
>I expect it will take at least until v5.9-rc1 before we have all the changes merged that would allow us to enable SMMU support.
Thierry
> .../devicetree/bindings/iommu/arm,smmu.yaml | 5 +
> MAINTAINERS | 2 +
> arch/arm64/boot/dts/nvidia/tegra194.dtsi | 81 ++++++
> drivers/iommu/Makefile | 2 +-
> drivers/iommu/arm-smmu-impl.c | 3 +
> drivers/iommu/arm-smmu-nvidia.c | 261 ++++++++++++++++++
> drivers/iommu/arm-smmu.c | 11 +-
> drivers/iommu/arm-smmu.h | 4 +
> 8 files changed, 366 insertions(+), 3 deletions(-) create mode
> 100644 drivers/iommu/arm-smmu-nvidia.c
>
>
> base-commit: 365f8d504da50feaebf826d180113529c9383670
> --
> 2.26.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] remoteproc: add support for a new 64-bit trace version
From: Clément Leger @ 2020-05-22 18:10 UTC (permalink / raw)
To: Bjorn Andersson
Cc: devicetree, Loic PALLARDY, Mathieu Poirier, Lokesh Vutla,
linux-remoteproc, Arnaud Pouliquen, linux-kernel, Rob Herring,
s-anna, linux-arm-kernel
In-Reply-To: <1739080680.4218297.1590170621467.JavaMail.zimbra@kalray.eu>
----- On 22 May, 2020, at 20:03, Clément Leger cleger@kalray.eu wrote:
> Hi Suman,
>
> ----- On 22 May, 2020, at 19:33, Bjorn Andersson bjorn.andersson@linaro.org
> wrote:
>
>> On Fri 22 May 09:54 PDT 2020, Suman Anna wrote:
>>
>>> On 5/21/20 2:42 PM, Suman Anna wrote:
>>> > Hi Bjorn,
>>> >
>>> > On 5/21/20 1:04 PM, Bjorn Andersson wrote:
>>> > > On Wed 25 Mar 13:47 PDT 2020, Suman Anna wrote:
>> [..]
>>> > > > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
>> [..]
>>> > > > +struct fw_rsc_trace2 {
>>> > >
>>> > > Sounds more like fw_rsc_trace64 to me - in particular since the version
>>> > > of trace2 is 1...
>>> >
>>> > Yeah, will rename this.
>>> >
>>> > >
>>> > > > + u32 padding;
>>> > > > + u64 da;
>>> > > > + u32 len;
>>> > > > + u32 reserved;
>>> > >
>>> > > What's the purpose of this reserved field?
>>> >
>>> > Partly to make sure the entire resource is aligned on an 8-byte, and
>>> > partly copied over from fw_rsc_trace entry. I guess 32-bits is already
>>> > large enough of a size for trace entries irrespective of 32-bit or
>>> > 64-bit traces, so I doubt if we want to make the len field also a u64.
>>>
>>> Looking at this again, I can drop both padding and reserved fields, if I
>>> move the len field before da. Any preferences/comments?
>
Sorry, my message went a bit too fast... So as I was saying:
Not only the in-structure alignment matters but also in the resource table.
Since the resource table is often packed (see [1] for instance), if a trace
resource is embedded in the resource table after another resource aligned
on 32 bits only, your 64 bits trace field will potentially end up
misaligned.
To overcome this, there is multiple solutions:
- Split the 64 bits fields into 32bits low and high parts:
Since all resources are aligned on 32bits, it will be ok
- Use memcpy_from/to_io when reading/writing such fields
As I said in a previous message this should probably be used since
the memories that are accessed by rproc are io mem (ioremap in almost
all drivers).
Regards,
Clément
[1] https://github.com/OpenAMP/open-amp/blob/master/apps/machine/zynqmp_r5/rsc_table.h
>
>
>
>
>>>
>>
>> Sounds good to me.
>>
>> Thanks,
> > Bjorn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 05/21] drm/atmel-hlcdc: Use GEM CMA object functions
From: Sam Ravnborg @ 2020-05-22 18:08 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: alexandre.belloni, linux-aspeed, narmstrong, airlied,
linus.walleij, liviu.dudau, stefan, philippe.cornu, paul,
laurent.pinchart, benjamin.gaignard, mihail.atanassov, festevam,
alexandre.torgue, marex, khilman, abrodkin, ludovic.desroches,
xinliang.liu, kong.kongxinwei, tomi.valkeinen, james.qian.wang,
joel, linux-imx, p.zabel, puck.chen, s.hauer, alison.wang,
maarten.lankhorst, mripard, john.stultz, jsarha, wens,
vincent.abriou, kernel, linux-arm-kernel, mcoquelin.stm32, noralf,
bbrezillon, andrew, dri-devel, yannick.fertre,
kieran.bingham+renesas, daniel, zourongrong, shawnguo,
brian.starkey
In-Reply-To: <20200522135246.10134-6-tzimmermann@suse.de>
Hi Thomas.
On Fri, May 22, 2020 at 03:52:30PM +0200, Thomas Zimmermann wrote:
> The atmel-hlcdc driver uses the default implementation for CMA functions. The
> DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
> All remaining operations are provided by CMA GEM object functions.
A nice side-effect of introducing the defualt implementation
of CMA functions is that this driver is now migrated over to use
drm_gem_object_funcs, which is why we can replace all these
helpers with a simple macro that defined only 6 helpers.
With an improved changelog:
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
And as I said in the other mail, this is really nice.
It is now much more obvious that this drivers uses
all the default helpers for CMA.
And I can drop one item from my TODO list on top of that.
Sam
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 11 +----------
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 112aa5066ceed..871293d1aeeba 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -821,16 +821,7 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
> .irq_preinstall = atmel_hlcdc_dc_irq_uninstall,
> .irq_postinstall = atmel_hlcdc_dc_irq_postinstall,
> .irq_uninstall = atmel_hlcdc_dc_irq_uninstall,
> - .gem_free_object_unlocked = drm_gem_cma_free_object,
> - .gem_vm_ops = &drm_gem_cma_vm_ops,
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
> - .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
> - .dumb_create = drm_gem_cma_dumb_create,
> + DRM_GEM_CMA_DRIVER_OPS,
> .fops = &fops,
> .name = "atmel-hlcdc",
> .desc = "Atmel HLCD Controller DRM",
> --
> 2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] remoteproc: add support for a new 64-bit trace version
From: Clément Leger @ 2020-05-22 18:03 UTC (permalink / raw)
To: Bjorn Andersson
Cc: devicetree, Loic PALLARDY, Mathieu Poirier, Lokesh Vutla,
linux-remoteproc, Arnaud Pouliquen, linux-kernel, Rob Herring,
s-anna, linux-arm-kernel
In-Reply-To: <20200522173346.GJ11847@yoga>
Hi Suman,
----- On 22 May, 2020, at 19:33, Bjorn Andersson bjorn.andersson@linaro.org wrote:
> On Fri 22 May 09:54 PDT 2020, Suman Anna wrote:
>
>> On 5/21/20 2:42 PM, Suman Anna wrote:
>> > Hi Bjorn,
>> >
>> > On 5/21/20 1:04 PM, Bjorn Andersson wrote:
>> > > On Wed 25 Mar 13:47 PDT 2020, Suman Anna wrote:
> [..]
>> > > > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> [..]
>> > > > +struct fw_rsc_trace2 {
>> > >
>> > > Sounds more like fw_rsc_trace64 to me - in particular since the version
>> > > of trace2 is 1...
>> >
>> > Yeah, will rename this.
>> >
>> > >
>> > > > + u32 padding;
>> > > > + u64 da;
>> > > > + u32 len;
>> > > > + u32 reserved;
>> > >
>> > > What's the purpose of this reserved field?
>> >
>> > Partly to make sure the entire resource is aligned on an 8-byte, and
>> > partly copied over from fw_rsc_trace entry. I guess 32-bits is already
>> > large enough of a size for trace entries irrespective of 32-bit or
>> > 64-bit traces, so I doubt if we want to make the len field also a u64.
>>
>> Looking at this again, I can drop both padding and reserved fields, if I
>> move the len field before da. Any preferences/comments?
Not only the in structure alignment matters but also in the resource table.
Since the resource table is often packed (see [1] for instance), if a
[1] https://github.com/OpenAMP/open-amp/blob/master/apps/machine/zynqmp_r5/rsc_table.h
>>
>
> Sounds good to me.
>
> Thanks,
> Bjorn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] System timer changes for omaps for v5.8
From: Tony Lindgren @ 2020-05-22 17:49 UTC (permalink / raw)
To: soc; +Cc: Tony Lindgren, linux-omap, arm, Daniel Lezcano, linux-arm-kernel
From: "Tony Lindgren" <tony@atomide.com>
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.8/timer-signed
for you to fetch changes up to 1a5428119bc36b0a882e87fe2620c769ba655763:
bus: ti-sysc: Timers no longer need legacy quirk handling (2020-05-19 09:38:05 -0700)
----------------------------------------------------------------
System timer changes for omaps for v5.8 merge window
This series of changes finally gets the legacy omap dual-mode timer and
32k counter system timer updated to use drivers/clocksource and device
tree data. And we can now remove the unused legacy platform data.
These changes are based on an immutable clocksource branch set up by
Daniel Lezcano.
----------------------------------------------------------------
Tony Lindgren (15):
clocksource/drivers/timer-ti-32k: Add support for initializing directly
clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support
clocksource/drivers/timer-ti-dm: Fix warning for set but not used
clk: ti: dm816: enable sysclk6_ck on init
bus: ti-sysc: Ignore timer12 on secure omap3
ARM: OMAP2+: Add omap_init_time_of()
ARM: dts: Configure system timers for am335x
ARM: dts: Configure system timers for am437x
ARM: dts: Configure system timers for omap4
ARM: dts: Configure system timers for omap5 and dra7
ARM: dts: Configure system timers for omap3
ARM: dts: Configure system timers for ti81xx
ARM: dts: Configure system timers for omap2
ARM: OMAP2+: Drop old timer code for dmtimer and 32k counter
bus: ti-sysc: Timers no longer need legacy quirk handling
arch/arm/boot/dts/am33xx-l4.dtsi | 6 +-
arch/arm/boot/dts/am33xx.dtsi | 20 +
arch/arm/boot/dts/am3517.dtsi | 24 +-
arch/arm/boot/dts/am4372.dtsi | 20 +
arch/arm/boot/dts/am437x-l4.dtsi | 7 +-
arch/arm/boot/dts/dm814x.dtsi | 74 ++-
arch/arm/boot/dts/dm816x.dtsi | 78 ++-
arch/arm/boot/dts/dra7-l4.dtsi | 7 +-
arch/arm/boot/dts/dra7.dtsi | 10 +
arch/arm/boot/dts/omap2.dtsi | 31 +-
arch/arm/boot/dts/omap2420.dtsi | 68 +-
arch/arm/boot/dts/omap2430.dtsi | 68 +-
arch/arm/boot/dts/omap3-beagle.dts | 33 +
arch/arm/boot/dts/omap3-devkit8000.dts | 33 +
arch/arm/boot/dts/omap3.dtsi | 134 +++-
arch/arm/boot/dts/omap4-l4.dtsi | 4 +-
arch/arm/boot/dts/omap4.dtsi | 10 +
arch/arm/boot/dts/omap5-l4.dtsi | 4 +-
arch/arm/boot/dts/omap5.dtsi | 10 +
arch/arm/mach-omap2/Makefile | 4 +-
arch/arm/mach-omap2/board-generic.c | 32 +-
arch/arm/mach-omap2/common.h | 7 +
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 20 -
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 19 -
.../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 8 -
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 47 --
.../mach-omap2/omap_hwmod_33xx_43xx_common_data.h | 2 -
.../omap_hwmod_33xx_43xx_interconnect_data.c | 8 -
.../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 62 --
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 10 -
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 146 +----
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 45 --
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 90 ---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 89 ---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 176 -----
arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 74 ---
arch/arm/mach-omap2/omap_hwmod_common_data.h | 3 -
arch/arm/mach-omap2/timer.c | 568 +---------------
drivers/bus/ti-sysc.c | 25 +-
drivers/clk/ti/clk-816x.c | 1 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-ti-32k.c | 48 +-
drivers/clocksource/timer-ti-dm-systimer.c | 727 +++++++++++++++++++++
43 files changed, 1368 insertions(+), 1485 deletions(-)
create mode 100644 drivers/clocksource/timer-ti-dm-systimer.c
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 01/21] drm/cma-helper: Rework DRM_GEM_CMA_VMAP_DRIVER_OPS macro
From: Sam Ravnborg @ 2020-05-22 17:48 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: alexandre.belloni, linux-aspeed, narmstrong, airlied,
linus.walleij, liviu.dudau, stefan, philippe.cornu, paul,
laurent.pinchart, benjamin.gaignard, mihail.atanassov, festevam,
alexandre.torgue, marex, khilman, abrodkin, ludovic.desroches,
xinliang.liu, kong.kongxinwei, tomi.valkeinen, james.qian.wang,
joel, linux-imx, p.zabel, puck.chen, s.hauer, alison.wang,
maarten.lankhorst, mripard, john.stultz, jsarha, wens,
vincent.abriou, kernel, linux-arm-kernel, mcoquelin.stm32, noralf,
bbrezillon, andrew, dri-devel, yannick.fertre,
kieran.bingham+renesas, daniel, zourongrong, shawnguo,
brian.starkey
In-Reply-To: <20200522135246.10134-2-tzimmermann@suse.de>
Hi Thomas.
On Fri, May 22, 2020 at 03:52:26PM +0200, Thomas Zimmermann wrote:
> Rename the macro to DRM_GEM_CMA_DRIVER_OPS to align with SHMEM
> helpers.
This part is fine, I like that the naming is somehow consistent.
> An internal version is provided for drivers that override
> the default .dumb_create callback. Adapt drivers to the changes.
I loathe anything named __foo or __FOO. This __ signals to me
that the author was clueless in naming - or some sort.
I know that __ is used in some lib headers - but thats not the case
here.
But I love that we have a variant that takes a create function.
So we do not have to escape from the nice macro.
The macro is another way to tell me as rewiewer that this
drivers uses all the default helpers for this.
So critizising the name I better suggest something that
I personally like better:
DRM_GEM_CMA_DRIVER_OPS_CREATE()
It would look like this:
/* GEM Operations */
- DRM_GEM_CMA_VMAP_DRIVER_OPS,
- .dumb_create = drm_sun4i_gem_dumb_create,
+ DRM_GEM_CMA_DRIVER_OPS_CREATE(drm_sun4i_gem_dumb_create),
Please fix zte/zx_drm_drv.c which also uses DRM_GEM_CMA_VMAP_DRIVER_OPS.
The naming is a bikeshedding topic that we may not agree on, soo..
With zte fixed the patch is:
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Sam
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/gpu/drm/drm_gem_cma_helper.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_drv.c | 3 +--
> drivers/gpu/drm/tidss/tidss_drv.c | 2 +-
> drivers/gpu/drm/tiny/hx8357d.c | 2 +-
> drivers/gpu/drm/tiny/ili9225.c | 2 +-
> drivers/gpu/drm/tiny/ili9341.c | 2 +-
> drivers/gpu/drm/tiny/ili9486.c | 2 +-
> drivers/gpu/drm/tiny/mi0283qt.c | 2 +-
> drivers/gpu/drm/tiny/repaper.c | 2 +-
> drivers/gpu/drm/tiny/st7586.c | 2 +-
> drivers/gpu/drm/tiny/st7735r.c | 2 +-
> include/drm/drm_gem_cma_helper.h | 24 ++++++++++++++++++++----
> 12 files changed, 31 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 12e98fb28229d..6fa4d2f2e3987 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -620,7 +620,7 @@ EXPORT_SYMBOL(drm_cma_gem_create_object_default_funcs);
> * address set. This address is released when the object is freed.
> *
> * This function can be used as the &drm_driver.gem_prime_import_sg_table
> - * callback. The DRM_GEM_CMA_VMAP_DRIVER_OPS() macro provides a shortcut to set
> + * callback. The &DRM_GEM_CMA_DRIVER_OPS macro provides a shortcut to set
> * the necessary DRM driver operations.
> *
> * Returns:
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 328272ff77d84..012855fd89c24 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -52,8 +52,7 @@ static struct drm_driver sun4i_drv_driver = {
> .minor = 0,
>
> /* GEM Operations */
> - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> - .dumb_create = drm_sun4i_gem_dumb_create,
> + __DRM_GEM_CMA_DRIVER_OPS(drm_sun4i_gem_dumb_create),
> };
>
> static int sun4i_drv_bind(struct device *dev)
> diff --git a/drivers/gpu/drm/tidss/tidss_drv.c b/drivers/gpu/drm/tidss/tidss_drv.c
> index 99edc66ebdef2..1753cdc74ebda 100644
> --- a/drivers/gpu/drm/tidss/tidss_drv.c
> +++ b/drivers/gpu/drm/tidss/tidss_drv.c
> @@ -112,7 +112,7 @@ static struct drm_driver tidss_driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> .fops = &tidss_fops,
> .release = tidss_release,
> - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> + DRM_GEM_CMA_DRIVER_OPS,
> .name = "tidss",
> .desc = "TI Keystone DSS",
> .date = "20180215",
> diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c
> index b4bc358a3269a..592da71d7ca70 100644
> --- a/drivers/gpu/drm/tiny/hx8357d.c
> +++ b/drivers/gpu/drm/tiny/hx8357d.c
> @@ -196,7 +196,7 @@ DEFINE_DRM_GEM_CMA_FOPS(hx8357d_fops);
> static struct drm_driver hx8357d_driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> .fops = &hx8357d_fops,
> - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> + DRM_GEM_CMA_DRIVER_OPS,
> .debugfs_init = mipi_dbi_debugfs_init,
> .name = "hx8357d",
> .desc = "HX8357D",
> diff --git a/drivers/gpu/drm/tiny/ili9225.c b/drivers/gpu/drm/tiny/ili9225.c
> index d1a5ab6747d5c..368ff6c8a1efb 100644
> --- a/drivers/gpu/drm/tiny/ili9225.c
> +++ b/drivers/gpu/drm/tiny/ili9225.c
> @@ -346,7 +346,7 @@ DEFINE_DRM_GEM_CMA_FOPS(ili9225_fops);
> static struct drm_driver ili9225_driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> .fops = &ili9225_fops,
> - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> + DRM_GEM_CMA_DRIVER_OPS,
> .name = "ili9225",
> .desc = "Ilitek ILI9225",
> .date = "20171106",
> diff --git a/drivers/gpu/drm/tiny/ili9341.c b/drivers/gpu/drm/tiny/ili9341.c
> index bb819f45a5d3b..e1b9043ef7a0a 100644
> --- a/drivers/gpu/drm/tiny/ili9341.c
> +++ b/drivers/gpu/drm/tiny/ili9341.c
> @@ -152,7 +152,7 @@ DEFINE_DRM_GEM_CMA_FOPS(ili9341_fops);
> static struct drm_driver ili9341_driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> .fops = &ili9341_fops,
> - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> + DRM_GEM_CMA_DRIVER_OPS,
> .debugfs_init = mipi_dbi_debugfs_init,
> .name = "ili9341",
> .desc = "Ilitek ILI9341",
> diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
> index 2702ea557d297..90a17f40fdf0c 100644
> --- a/drivers/gpu/drm/tiny/ili9486.c
> +++ b/drivers/gpu/drm/tiny/ili9486.c
> @@ -165,7 +165,7 @@ DEFINE_DRM_GEM_CMA_FOPS(ili9486_fops);
> static struct drm_driver ili9486_driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> .fops = &ili9486_fops,
> - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> + DRM_GEM_CMA_DRIVER_OPS,
> .debugfs_init = mipi_dbi_debugfs_init,
> .name = "ili9486",
> .desc = "Ilitek ILI9486",
> diff --git a/drivers/gpu/drm/tiny/mi0283qt.c b/drivers/gpu/drm/tiny/mi0283qt.c
> index 08ac549ab0f7f..6624c2098fba2 100644
> --- a/drivers/gpu/drm/tiny/mi0283qt.c
> +++ b/drivers/gpu/drm/tiny/mi0283qt.c
> @@ -156,7 +156,7 @@ DEFINE_DRM_GEM_CMA_FOPS(mi0283qt_fops);
> static struct drm_driver mi0283qt_driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> .fops = &mi0283qt_fops,
> - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> + DRM_GEM_CMA_DRIVER_OPS,
> .debugfs_init = mipi_dbi_debugfs_init,
> .name = "mi0283qt",
> .desc = "Multi-Inno MI0283QT",
> diff --git a/drivers/gpu/drm/tiny/repaper.c b/drivers/gpu/drm/tiny/repaper.c
> index 1c0e7169545b4..877dcece25828 100644
> --- a/drivers/gpu/drm/tiny/repaper.c
> +++ b/drivers/gpu/drm/tiny/repaper.c
> @@ -946,7 +946,7 @@ DEFINE_DRM_GEM_CMA_FOPS(repaper_fops);
> static struct drm_driver repaper_driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> .fops = &repaper_fops,
> - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> + DRM_GEM_CMA_DRIVER_OPS,
> .name = "repaper",
> .desc = "Pervasive Displays RePaper e-ink panels",
> .date = "20170405",
> diff --git a/drivers/gpu/drm/tiny/st7586.c b/drivers/gpu/drm/tiny/st7586.c
> index 2a1fae422f7a2..ec84bdc51f60d 100644
> --- a/drivers/gpu/drm/tiny/st7586.c
> +++ b/drivers/gpu/drm/tiny/st7586.c
> @@ -285,7 +285,7 @@ DEFINE_DRM_GEM_CMA_FOPS(st7586_fops);
> static struct drm_driver st7586_driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> .fops = &st7586_fops,
> - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> + DRM_GEM_CMA_DRIVER_OPS,
> .debugfs_init = mipi_dbi_debugfs_init,
> .name = "st7586",
> .desc = "Sitronix ST7586",
> diff --git a/drivers/gpu/drm/tiny/st7735r.c b/drivers/gpu/drm/tiny/st7735r.c
> index 0af1b15efdf8a..cfd4933f3b30c 100644
> --- a/drivers/gpu/drm/tiny/st7735r.c
> +++ b/drivers/gpu/drm/tiny/st7735r.c
> @@ -157,7 +157,7 @@ DEFINE_DRM_GEM_CMA_FOPS(st7735r_fops);
> static struct drm_driver st7735r_driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> .fops = &st7735r_fops,
> - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> + DRM_GEM_CMA_DRIVER_OPS,
> .debugfs_init = mipi_dbi_debugfs_init,
> .name = "st7735r",
> .desc = "Sitronix ST7735R",
> diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
> index 947ac95eb24a9..917d42603db06 100644
> --- a/include/drm/drm_gem_cma_helper.h
> +++ b/include/drm/drm_gem_cma_helper.h
> @@ -110,21 +110,37 @@ struct drm_gem_object *
> drm_cma_gem_create_object_default_funcs(struct drm_device *dev, size_t size);
>
> /**
> - * DRM_GEM_CMA_VMAP_DRIVER_OPS - CMA GEM driver operations ensuring a virtual
> - * address on the buffer
> + * __DRM_GEM_CMA_DRIVER_OPS - CMA GEM driver operations ensuring a
> + * virtual address on the buffer
> + * @__dumb_create: callback function for .dumb_create
> *
> * This macro provides a shortcut for setting the default GEM operations in the
> * &drm_driver structure for drivers that need the virtual address also on
> * imported buffers.
> + *
> + * This macro is a variant of DRM_GEM_CMA_DRIVER_OPS for drivers that
> + * override the default implementation of .dumb_create. Use
> + * DRM_GEM_CMA_DRIVER_OPS if possible.
> */
> -#define DRM_GEM_CMA_VMAP_DRIVER_OPS \
> +#define __DRM_GEM_CMA_DRIVER_OPS(__dumb_create) \
> .gem_create_object = drm_cma_gem_create_object_default_funcs, \
> - .dumb_create = drm_gem_cma_dumb_create, \
> + .dumb_create = (__dumb_create), \
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd, \
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle, \
> .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table_vmap, \
> .gem_prime_mmap = drm_gem_prime_mmap
>
> +/**
> + * DRM_GEM_CMA_DRIVER_OPS - CMA GEM driver operations ensuring a virtual
> + * address on the buffer
> + *
> + * This macro provides a shortcut for setting the default GEM operations in the
> + * &drm_driver structure for drivers that need the virtual address also on
> + * imported buffers.
> + */
> +#define DRM_GEM_CMA_DRIVER_OPS \
> + __DRM_GEM_CMA_DRIVER_OPS(drm_gem_cma_dumb_create)
> +
> struct drm_gem_object *
> drm_gem_cma_prime_import_sg_table_vmap(struct drm_device *drm,
> struct dma_buf_attachment *attach,
> --
> 2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] remoteproc: add support for a new 64-bit trace version
From: Bjorn Andersson @ 2020-05-22 17:33 UTC (permalink / raw)
To: Suman Anna
Cc: devicetree, Mathieu Poirier, Loic Pallardy, Lokesh Vutla,
linux-remoteproc, Arnaud Pouliquen, linux-kernel, Clement Leger,
Rob Herring, linux-arm-kernel
In-Reply-To: <f15b0c6d-eee8-b839-0c79-a5316dbbfa7b@ti.com>
On Fri 22 May 09:54 PDT 2020, Suman Anna wrote:
> On 5/21/20 2:42 PM, Suman Anna wrote:
> > Hi Bjorn,
> >
> > On 5/21/20 1:04 PM, Bjorn Andersson wrote:
> > > On Wed 25 Mar 13:47 PDT 2020, Suman Anna wrote:
[..]
> > > > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
[..]
> > > > +struct fw_rsc_trace2 {
> > >
> > > Sounds more like fw_rsc_trace64 to me - in particular since the version
> > > of trace2 is 1...
> >
> > Yeah, will rename this.
> >
> > >
> > > > + u32 padding;
> > > > + u64 da;
> > > > + u32 len;
> > > > + u32 reserved;
> > >
> > > What's the purpose of this reserved field?
> >
> > Partly to make sure the entire resource is aligned on an 8-byte, and
> > partly copied over from fw_rsc_trace entry. I guess 32-bits is already
> > large enough of a size for trace entries irrespective of 32-bit or
> > 64-bit traces, so I doubt if we want to make the len field also a u64.
>
> Looking at this again, I can drop both padding and reserved fields, if I
> move the len field before da. Any preferences/comments?
>
Sounds good to me.
Thanks,
Bjorn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] thermal: imx8mm: Add get_trend ops
From: Daniel Lezcano @ 2020-05-22 17:33 UTC (permalink / raw)
To: Anson Huang, rui.zhang, amit.kucheria, shawnguo, s.hauer, kernel,
festevam, linux-pm, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1589338689-15700-1-git-send-email-Anson.Huang@nxp.com>
On 13/05/2020 04:58, Anson Huang wrote:
> Add get_trend ops for i.MX8MM thermal to apply fast cooling
> mechanism, when temperature exceeds passive trip point, the
> highest cooling action will be applied, and when temperature
> drops to lower than the margin below passive trip point, the
> lowest cooling action will be applied.
You are not describing what is the goal of this change.
IIUC, the resulting change will be an on/off action. The thermal zone is
mitigated with the highest cooling effect, so the lowest OPP, then the
temperature trend is stable until it goes below the trip - margin where
the mitigation is stopped.
Except, I'm missing something, setting a trip point with a 10000
hysteresis and a cooling map min/max set to the highest opp will result
on the same.
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> drivers/thermal/imx8mm_thermal.c | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/thermal/imx8mm_thermal.c b/drivers/thermal/imx8mm_thermal.c
> index e6061e2..8f6a0b8 100644
> --- a/drivers/thermal/imx8mm_thermal.c
> +++ b/drivers/thermal/imx8mm_thermal.c
> @@ -38,6 +38,8 @@
> #define TMU_VER1 0x1
> #define TMU_VER2 0x2
>
> +#define IMX_TEMP_COOL_MARGIN 10000
> +
> struct thermal_soc_data {
> u32 num_sensors;
> u32 version;
> @@ -103,8 +105,33 @@ static int tmu_get_temp(void *data, int *temp)
> return tmu->socdata->get_temp(data, temp);
> }
>
> +static int tmu_get_trend(void *p, int trip, enum thermal_trend *trend)
> +{
> + struct tmu_sensor *sensor = p;
> + int trip_temp, temp, ret;
> +
> + if (!sensor->tzd)
> + return -EINVAL;
> +
> + ret = sensor->tzd->ops->get_trip_temp(sensor->tzd, trip, &trip_temp);
> + if (ret)
> + return ret;
> +
> + temp = READ_ONCE(sensor->tzd->temperature);
> +
> + if (temp > trip_temp)
> + *trend = THERMAL_TREND_RAISE_FULL;
> + else if (temp < (trip_temp - IMX_TEMP_COOL_MARGIN))
> + *trend = THERMAL_TREND_DROP_FULL;
> + else
> + *trend = THERMAL_TREND_STABLE;
> +
> + return 0;
> +}
> +
> static struct thermal_zone_of_device_ops tmu_tz_ops = {
> .get_temp = tmu_get_temp,
> + .get_trend = tmu_get_trend,
> };
>
> static void imx8mm_tmu_enable(struct imx8mm_tmu *tmu, bool enable)
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox