* Re: [PATCH 10/21] drm/komeda: Use GEM CMA object functions
From: Liviu Dudau @ 2020-05-26 23:33 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: alexandre.belloni, linux-aspeed, narmstrong, airlied,
linus.walleij, stefan, philippe.cornu, paul, laurent.pinchart,
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-11-tzimmermann@suse.de>
On Fri, May 22, 2020 at 03:52:35PM +0200, Thomas Zimmermann wrote:
> The komeda 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>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 11 +----------
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> index 6b85d5f4caa85..bdfbcbc416260 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> @@ -61,16 +61,7 @@ static irqreturn_t komeda_kms_irq_handler(int irq, void *data)
> static struct drm_driver komeda_kms_driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> .lastclose = drm_fb_helper_lastclose,
> - .gem_free_object_unlocked = drm_gem_cma_free_object,
> - .gem_vm_ops = &drm_gem_cma_vm_ops,
> - .dumb_create = komeda_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_DRIVER_OPS(komeda_gem_cma_dumb_create),
> .fops = &komeda_cma_fops,
> .name = "komeda",
> .desc = "Arm Komeda Display Processor driver",
> --
> 2.26.2
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
_______________________________________________
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 11/21] drm/malidp: Use GEM CMA object functions
From: Liviu Dudau @ 2020-05-26 23:33 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: alexandre.belloni, linux-aspeed, narmstrong, airlied,
linus.walleij, stefan, philippe.cornu, paul, laurent.pinchart,
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-12-tzimmermann@suse.de>
On Fri, May 22, 2020 at 03:52:36PM +0200, Thomas Zimmermann wrote:
> The malidp 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>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/malidp_drv.c | 11 +----------
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
> index def8c9ffafcaf..92e0bca6aa2f4 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -563,16 +563,7 @@ static void malidp_debugfs_init(struct drm_minor *minor)
>
> static struct drm_driver malidp_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 = malidp_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_DRIVER_OPS(malidp_dumb_create),
> #ifdef CONFIG_DEBUG_FS
> .debugfs_init = malidp_debugfs_init,
> #endif
> --
> 2.26.2
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
_______________________________________________
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 1/2] clk: bcm2835: Fix return type of bcm2835_register_gate
From: Stephen Boyd @ 2020-05-26 23:42 UTC (permalink / raw)
To: Michael Turquette, Nathan Chancellor
Cc: linux-arm-kernel, Florian Fainelli, Scott Branden, Ray Jui,
linux-kernel, clang-built-linux, bcm-kernel-feedback-list,
linux-rpi-kernel, Sami Tolvanen, Nathan Chancellor, linux-clk,
Nicolas Saenz Julienne
In-Reply-To: <20200516080806.1459784-1-natechancellor@gmail.com>
Quoting Nathan Chancellor (2020-05-16 01:08:06)
> bcm2835_register_gate is used as a callback for the clk_register member
> of bcm2835_clk_desc, which expects a struct clk_hw * return type but
> bcm2835_register_gate returns a struct clk *.
>
> This discrepancy is hidden by the fact that bcm2835_register_gate is
> cast to the typedef bcm2835_clk_register by the _REGISTER macro. This
> turns out to be a control flow integrity violation, which is how this
> was noticed.
>
> Change the return type of bcm2835_register_gate to be struct clk_hw *
> and use clk_hw_register_gate to do so. This should be a non-functional
> change as clk_register_gate calls clk_hw_register_gate anyways but this
> is needed to avoid issues with further changes.
>
> Fixes: b19f009d4510 ("clk: bcm2835: Migrate to clk_hw based registration and OF APIs")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1028
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
Thanks. Applied to clk-next.
>
> base-commit: bdecf38f228bcca73b31ada98b5b7ba1215eb9c9
Please don't base on some random linux-next commit though.
_______________________________________________
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] clk: bcm2835: Remove casting to bcm2835_clk_register
From: Stephen Boyd @ 2020-05-26 23:42 UTC (permalink / raw)
To: Michael Turquette, Nathan Chancellor
Cc: linux-arm-kernel, Florian Fainelli, Scott Branden, Ray Jui,
linux-kernel, clang-built-linux, bcm-kernel-feedback-list,
linux-rpi-kernel, Sami Tolvanen, Nathan Chancellor, linux-clk,
Nicolas Saenz Julienne
In-Reply-To: <20200516080806.1459784-2-natechancellor@gmail.com>
Quoting Nathan Chancellor (2020-05-16 01:08:07)
> There are four different callback functions that are used for the
> clk_register callback that all have different second parameter types.
>
> bcm2835_register_pll -> struct bcm2835_pll_data
> bcm2835_register_pll_divider -> struct bcm2835_pll_divider_data
> bcm2835_register_clock -> struct bcm2835_clock_data
> bcm2835_register_date -> struct bcm2835_gate_data
>
> These callbacks are cast to bcm2835_clk_register so that there is no
> error about incompatible pointer types. Unfortunately, this is a control
> flow integrity violation, which verifies that the callback function's
> types match the prototypes exactly before jumping.
>
> [ 0.857913] CFI failure (target: 0xffffff9334a81820):
> [ 0.857977] WARNING: CPU: 3 PID: 35 at kernel/cfi.c:29 __cfi_check_fail+0x50/0x58
> [ 0.857985] Modules linked in:
> [ 0.858007] CPU: 3 PID: 35 Comm: kworker/3:1 Not tainted 4.19.123-v8-01301-gdbb48f16956e4-dirty #1
> [ 0.858015] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
> [ 0.858031] Workqueue: events 0xffffff9334a925c8
> [ 0.858046] pstate: 60000005 (nZCv daif -PAN -UAO)
> [ 0.858058] pc : __cfi_check_fail+0x50/0x58
> [ 0.858070] lr : __cfi_check_fail+0x50/0x58
> [ 0.858078] sp : ffffff800814ba90
> [ 0.858086] x29: ffffff800814ba90 x28: 000fffffffdfff3d
> [ 0.858101] x27: 00000000002000c2 x26: ffffff93355fdb18
> [ 0.858116] x25: 0000000000000000 x24: ffffff9334a81820
> [ 0.858131] x23: ffffff93357f3580 x22: ffffff9334af1000
> [ 0.858146] x21: a79b57e88f8ebc81 x20: ffffff93357f3580
> [ 0.858161] x19: ffffff9334a81820 x18: fffffff679769070
> [ 0.858175] x17: 0000000000000000 x16: 0000000000000000
> [ 0.858190] x15: 0000000000000004 x14: 000000000000003c
> [ 0.858205] x13: 0000000000003044 x12: 0000000000000000
> [ 0.858220] x11: b57e91cd641bae00 x10: b57e91cd641bae00
> [ 0.858235] x9 : b57e91cd641bae00 x8 : b57e91cd641bae00
> [ 0.858250] x7 : 0000000000000000 x6 : ffffff933591d4e5
> [ 0.858264] x5 : 0000000000000000 x4 : 0000000000000000
> [ 0.858279] x3 : ffffff800814b718 x2 : ffffff9334a84818
> [ 0.858293] x1 : ffffff9334bba66c x0 : 0000000000000029
> [ 0.858308] Call trace:
> [ 0.858321] __cfi_check_fail+0x50/0x58
> [ 0.858337] __cfi_check+0x3ab3c/0x4467c
> [ 0.858351] bcm2835_clk_probe+0x210/0x2dc
> [ 0.858369] platform_drv_probe+0xb0/0xfc
> [ 0.858380] really_probe+0x4a0/0x5a8
> [ 0.858391] driver_probe_device+0x68/0x104
> [ 0.858403] __device_attach_driver+0x100/0x148
> [ 0.858418] bus_for_each_drv+0xb0/0x12c
> [ 0.858431] __device_attach.llvm.17225159516306086099+0xc0/0x168
> [ 0.858443] bus_probe_device+0x44/0xfc
> [ 0.858455] deferred_probe_work_func+0xa0/0xe0
> [ 0.858472] process_one_work+0x210/0x538
> [ 0.858485] worker_thread+0x2e8/0x478
> [ 0.858500] kthread+0x154/0x164
> [ 0.858515] ret_from_fork+0x10/0x18
>
> To fix this, change the second parameter of all functions void * and use
> a local variable with the correct type so that everything works
> properly. With this, the only use of bcm2835_clk_register is in struct
> bcm2835_clk_desc so we can just remove it and use the type directly.
>
> Fixes: 56eb3a2ed972 ("clk: bcm2835: remove use of BCM2835_CLOCK_COUNT in driver")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1028
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
Applied to clk-next
_______________________________________________
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 1/2] clk: bcm2835: Fix return type of bcm2835_register_gate
From: Nathan Chancellor @ 2020-05-26 23:53 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel, Florian Fainelli, Scott Branden, Ray Jui,
Michael Turquette, linux-kernel, clang-built-linux,
bcm-kernel-feedback-list, linux-rpi-kernel, Sami Tolvanen,
linux-clk, Nicolas Saenz Julienne
In-Reply-To: <159053652408.88029.5210144839543172586@swboyd.mtv.corp.google.com>
On Tue, May 26, 2020 at 04:42:04PM -0700, Stephen Boyd wrote:
> Quoting Nathan Chancellor (2020-05-16 01:08:06)
> > bcm2835_register_gate is used as a callback for the clk_register member
> > of bcm2835_clk_desc, which expects a struct clk_hw * return type but
> > bcm2835_register_gate returns a struct clk *.
> >
> > This discrepancy is hidden by the fact that bcm2835_register_gate is
> > cast to the typedef bcm2835_clk_register by the _REGISTER macro. This
> > turns out to be a control flow integrity violation, which is how this
> > was noticed.
> >
> > Change the return type of bcm2835_register_gate to be struct clk_hw *
> > and use clk_hw_register_gate to do so. This should be a non-functional
> > change as clk_register_gate calls clk_hw_register_gate anyways but this
> > is needed to avoid issues with further changes.
> >
> > Fixes: b19f009d4510 ("clk: bcm2835: Migrate to clk_hw based registration and OF APIs")
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1028
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> > ---
>
> Thanks. Applied to clk-next.
>
> >
> > base-commit: bdecf38f228bcca73b31ada98b5b7ba1215eb9c9
>
> Please don't base on some random linux-next commit though.
Sorry, should have just used clk-next directly instead of the HEAD of
linux-next at the time. Just hard to keep track of all of the different
maintainer trees so it is easier to just use linux-next.
I do forget to use the output of --scm from
get_maintainer.pl though, I should use that more often.
Thank you for picking it up!
Nathan
_______________________________________________
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 09/21] drm/ingenic: Use GEM CMA object functions
From: Paul Cercueil @ 2020-05-27 0:28 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: alexandre.belloni, linux-aspeed, narmstrong, airlied,
linus.walleij, liviu.dudau, stefan, philippe.cornu,
laurent.pinchart, 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-10-tzimmermann@suse.de>
Hi Thomas,
Le ven. 22 mai 2020 à 15:52, Thomas Zimmermann <tzimmermann@suse.de> a
écrit :
> The ingenic 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>
Tested-by: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Cheers,
-Paul
> ---
> drivers/gpu/drm/ingenic/ingenic-drm.c | 13 +------------
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
> b/drivers/gpu/drm/ingenic/ingenic-drm.c
> index eff57a1f70fb0..1c1cee367b752 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
> @@ -519,18 +519,7 @@ static struct drm_driver ingenic_drm_driver_data
> = {
> .patchlevel = 0,
>
> .fops = &ingenic_drm_fops,
> -
> - .dumb_create = drm_gem_cma_dumb_create,
> - .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,
> + DRM_GEM_CMA_DRIVER_OPS,
>
> .irq_handler = ingenic_drm_irq_handler,
> };
> --
> 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 v2 1/4] drivers: clk: zynqmp: Limit bestdiv with maxdiv
From: Stephen Boyd @ 2020-05-27 1:01 UTC (permalink / raw)
To: Jolly Shah, arm, linux-clk, michal.simek, mturquette, olof
Cc: Jolly Shah, Rajan Vaja, rajanv, linux-kernel, linux-arm-kernel
In-Reply-To: <1583185843-20707-2-git-send-email-jolly.shah@xilinx.com>
Quoting Jolly Shah (2020-03-02 13:50:40)
> From: Rajan Vaja <rajan.vaja@xilinx.com>
>
> Clock divider value should not be greater than maximum divider value.
> So use minimum of best divider or maximum divider value.
>
> Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com>
> ---
Applied to clk-next
_______________________________________________
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 v2 2/4] drivers: clk: zynqmp: Fix divider2 calculation
From: Stephen Boyd @ 2020-05-27 1:01 UTC (permalink / raw)
To: Jolly Shah, arm, linux-clk, michal.simek, mturquette, olof
Cc: Tejas Patel, Jolly Shah, rajanv, linux-kernel, linux-arm-kernel
In-Reply-To: <1583185843-20707-3-git-send-email-jolly.shah@xilinx.com>
Quoting Jolly Shah (2020-03-02 13:50:41)
> From: Tejas Patel <tejas.patel@xilinx.com>
>
> zynqmp_get_divider2_val() calculates, divider value of type DIV2 clock,
> considering best possible combination of DIV1 and DIV2.
>
> To find best possible values of DIV1 and DIV2, DIV1's parent rate
> should be consider and not DIV2's parent rate since it would rate of
> div1 clock. Consider a below topology,
>
> out_clk->div2_clk->div1_clk->fixed_parent
>
> where out_clk = (fixed_parent/div1_clk) / div2_clk, so parent clock
> of div1_clk (i.e. out_clk) should be divided by div1_clk and div2_clk.
>
> Existing code divides parent rate of div2_clk's clock instead of
> div1_clk's parent rate, which is wrong.
>
> Fix the same by considering div1's parent clock rate.
>
> Fixes: 4ebd92d2e228 ("clk: zynqmp: Fix divider calculation")
> Signed-off-by: Tejas Patel <tejas.patel@xilinx.com>
> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com>
> ---
Applied to clk-next
_______________________________________________
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 v2 3/4] drivers: clk: zynqmp: Fix invalid clock name queries
From: Stephen Boyd @ 2020-05-27 1:01 UTC (permalink / raw)
To: Jolly Shah, arm, linux-clk, michal.simek, mturquette, olof
Cc: Tejas Patel, Rajan Vaja, linux-kernel, rajanv, Jolly Shah,
linux-arm-kernel
In-Reply-To: <1583185843-20707-4-git-send-email-jolly.shah@xilinx.com>
Quoting Jolly Shah (2020-03-02 13:50:42)
> From: Rajan Vaja <rajan.vaja@xilinx.com>
>
> The clock driver makes EEMI call to get the name of invalid clk
> when executing versal_get_clock_info() function. This results in
> error messages.
> Added check for validating clock before saving clock attribute and
> calling zynqmp_pm_clock_get_name() in versal_get_clock_info() function.
>
> Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
> Signed-off-by: Tejas Patel <tejas.patel@xilinx.com>
> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com>
> ---
Applied to clk-next
_______________________________________________
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 v2 4/4] drivers: clk: zynqmp: fix memory leak in zynqmp_register_clocks
From: Stephen Boyd @ 2020-05-27 1:01 UTC (permalink / raw)
To: Jolly Shah, arm, linux-clk, michal.simek, mturquette, olof
Cc: Tejas Patel, linux-kernel, rajanv, Jolly Shah, Quanyang Wang,
linux-arm-kernel
In-Reply-To: <1583185843-20707-5-git-send-email-jolly.shah@xilinx.com>
Quoting Jolly Shah (2020-03-02 13:50:43)
> From: Quanyang Wang <quanyang.wang@windriver.com>
>
> This is detected by kmemleak running on zcu102 board:
>
> unreferenced object 0xffffffc877e48180 (size 128):
> comm "swapper/0", pid 1, jiffies 4294892909 (age 315.436s)
> hex dump (first 32 bytes):
> 64 70 5f 76 69 64 65 6f 5f 72 65 66 5f 64 69 76 dp_video_ref_div
> 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1...............
> backtrace:
> [<00000000c9be883b>] __kmalloc_track_caller+0x200/0x380
> [<00000000f02c3809>] kvasprintf+0x7c/0x100
> [<00000000e51dde4d>] kasprintf+0x60/0x80
> [<0000000092298b05>] zynqmp_register_clocks+0x29c/0x398
> [<00000000faaff182>] zynqmp_clock_probe+0x3cc/0x4c0
> [<000000005f5986f0>] platform_drv_probe+0x58/0xa8
> [<00000000d5810136>] really_probe+0xd8/0x2a8
> [<00000000f5b671be>] driver_probe_device+0x5c/0x100
> [<0000000038f91fcf>] __device_attach_driver+0x98/0xb8
> [<000000008a3f2ac2>] bus_for_each_drv+0x74/0xd8
> [<000000001cb2783d>] __device_attach+0xe0/0x140
> [<00000000c268031b>] device_initial_probe+0x24/0x30
> [<000000006998de4b>] bus_probe_device+0x9c/0xa8
> [<00000000647ae6ff>] device_add+0x3c0/0x610
> [<0000000071c14bb8>] of_device_add+0x40/0x50
> [<000000004bb5d132>] of_platform_device_create_pdata+0xbc/0x138
>
> This is because that when num_nodes is larger than 1, clk_out is
> allocated using kasprintf for these nodes but only the last node's
> clk_out is freed.
>
> Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> Signed-off-by: Tejas Patel <tejas.patel@xilinx.com>
> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com>
> ---
Applied to clk-next
_______________________________________________
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 v2 2/2] drivers: clk: zynqmp: Update fraction clock check from custom type flags
From: Stephen Boyd @ 2020-05-27 1:01 UTC (permalink / raw)
To: Jolly Shah, arm, linux-clk, michal.simek, mturquette, olof
Cc: Tejas Patel, Rajan Vaja, linux-kernel, rajanv, Jolly Shah,
linux-arm-kernel
In-Reply-To: <1584048699-24186-3-git-send-email-jolly.shah@xilinx.com>
Quoting Jolly Shah (2020-03-12 14:31:39)
> From: Tejas Patel <tejas.patel@xilinx.com>
>
> Older firmware version sets BIT(13) in clkflag to mark a
> divider as fractional divider. Updated firmware version sets BIT(4)
> in type flags to mark a divider as fractional divider since
> BIT(13) is defined as CLK_DUTY_CYCLE_PARENT in the common clk
> framework flags.
>
> To support both old and new firmware version, consider BIT(13) from
> clkflag and BIT(4) from type_flag to check if divider is fractional
> or not.
>
> To maintain compatibility BIT(13) of clkflag in firmware will not be
> used in future for any purpose and will be marked as unused.
>
> Signed-off-by: Tejas Patel <tejas.patel@xilinx.com>
> Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com>
> ---
Applied to clk-next
_______________________________________________
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 v2 1/2] drivers: clk: zynqmp: Add support for custom type flags
From: Stephen Boyd @ 2020-05-27 1:01 UTC (permalink / raw)
To: Jolly Shah, arm, linux-clk, michal.simek, mturquette, olof
Cc: Tejas Patel, Rajan Vaja, linux-kernel, rajanv, Jolly Shah,
linux-arm-kernel
In-Reply-To: <1584048699-24186-2-git-send-email-jolly.shah@xilinx.com>
Quoting Jolly Shah (2020-03-12 14:31:38)
> From: Rajan Vaja <rajan.vaja@xilinx.com>
>
> Store extra custom type flags received from firmware.
>
> Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
> Signed-off-by: Tejas Patel <tejas.patel@xilinx.com>
> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [arm:cex7 88/106] arch/sh/include/asm/io.h:32:43: warning: 'px_is' may be used uninitialized in this function
From: kbuild test robot @ 2020-05-27 1:00 UTC (permalink / raw)
To: Peng Ma; +Cc: Russell King, kbuild-all, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 4249 bytes --]
tree: git://git.armlinux.org.uk/~rmk/linux-arm.git cex7
head: 96bd73e4644e76befe9ab998e070a679ae08388c
commit: 04d1ec3ed831580aadbdac12b36b6158ad80dad4 [88/106] ahci: qoriq: workaround for errata A-379364 on lx2160a
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 04d1ec3ed831580aadbdac12b36b6158ad80dad4
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=sh
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>, old ones prefixed by <<):
In file included from drivers/ata/ahci_qoriq.c:19:
drivers/ata/ahci.h:384:16: warning: initialized field overwritten [-Woverride-init]
384 | .can_queue = AHCI_MAX_CMDS, | ^~~~~~~~~~~~~
drivers/ata/ahci_qoriq.c:304:2: note: in expansion of macro 'AHCI_SHT'
304 | AHCI_SHT(DRV_NAME),
| ^~~~~~~~
drivers/ata/ahci.h:384:16: note: (near initialization for 'ahci_qoriq_sht.can_queue')
384 | .can_queue = AHCI_MAX_CMDS, | ^~~~~~~~~~~~~
drivers/ata/ahci_qoriq.c:304:2: note: in expansion of macro 'AHCI_SHT'
304 | AHCI_SHT(DRV_NAME),
| ^~~~~~~~
drivers/ata/ahci.h:388:17: warning: initialized field overwritten [-Woverride-init]
388 | .sdev_attrs = ahci_sdev_attrs
| ^~~~~~~~~~~~~~~
drivers/ata/ahci_qoriq.c:304:2: note: in expansion of macro 'AHCI_SHT'
304 | AHCI_SHT(DRV_NAME),
| ^~~~~~~~
drivers/ata/ahci.h:388:17: note: (near initialization for 'ahci_qoriq_sht.sdev_attrs')
388 | .sdev_attrs = ahci_sdev_attrs
| ^~~~~~~~~~~~~~~
drivers/ata/ahci_qoriq.c:304:2: note: in expansion of macro 'AHCI_SHT'
304 | AHCI_SHT(DRV_NAME),
| ^~~~~~~~
In file included from include/linux/io.h:13,
from include/linux/of_address.h:7,
from drivers/ata/ahci_qoriq.c:14:
drivers/ata/ahci_qoriq.c: In function 'ahci_qoriq_hardreset':
>> arch/sh/include/asm/io.h:32:43: warning: 'px_is' may be used uninitialized in this function [-Wmaybe-uninitialized]
32 | #define __raw_writel(v,a) (__chk_io_ptr(a), *(volatile u32 __force *)(a) = (v))
| ^
drivers/ata/ahci_qoriq.c:229:14: note: 'px_is' was declared here
229 | u32 px_cmd, px_is, px_val;
| ^~~~~
In file included from include/linux/io.h:13,
from include/linux/of_address.h:7,
from drivers/ata/ahci_qoriq.c:14:
>> arch/sh/include/asm/io.h:32:43: warning: 'px_cmd' may be used uninitialized in this function [-Wmaybe-uninitialized]
32 | #define __raw_writel(v,a) (__chk_io_ptr(a), *(volatile u32 __force *)(a) = (v))
| ^
drivers/ata/ahci_qoriq.c:229:6: note: 'px_cmd' was declared here
229 | u32 px_cmd, px_is, px_val;
| ^~~~~~
vim +/px_is +32 arch/sh/include/asm/io.h
b66c1a3919abb4 include/asm-sh/io.h Paul Mundt 2006-01-16 29
14866543ad2201 arch/sh/include/asm/io.h Paul Mundt 2008-10-04 30 #define __raw_writeb(v,a) (__chk_io_ptr(a), *(volatile u8 __force *)(a) = (v))
14866543ad2201 arch/sh/include/asm/io.h Paul Mundt 2008-10-04 31 #define __raw_writew(v,a) (__chk_io_ptr(a), *(volatile u16 __force *)(a) = (v))
14866543ad2201 arch/sh/include/asm/io.h Paul Mundt 2008-10-04 @32 #define __raw_writel(v,a) (__chk_io_ptr(a), *(volatile u32 __force *)(a) = (v))
14866543ad2201 arch/sh/include/asm/io.h Paul Mundt 2008-10-04 33 #define __raw_writeq(v,a) (__chk_io_ptr(a), *(volatile u64 __force *)(a) = (v))
14866543ad2201 arch/sh/include/asm/io.h Paul Mundt 2008-10-04 34
:::::: The code at line 32 was first introduced by commit
:::::: 14866543ad22014a0b12e10657a917eb6b487248 sh: More I/O routine overhauling.
:::::: TO: Paul Mundt <lethal@linux-sh.org>
:::::: CC: Paul Mundt <lethal@linux-sh.org>
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 53892 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 v2 2/2] drivers: clk: zynqmp: Update fraction clock check from custom type flags
From: Stephen Boyd @ 2020-05-27 1:08 UTC (permalink / raw)
To: Jolly Shah, arm, linux-clk, michal.simek, mturquette, olof
Cc: Tejas Patel, Rajan Vaja, linux-kernel, rajanv, Jolly Shah,
linux-arm-kernel
In-Reply-To: <1584048699-24186-3-git-send-email-jolly.shah@xilinx.com>
Quoting Jolly Shah (2020-03-12 14:31:39)
> From: Tejas Patel <tejas.patel@xilinx.com>
>
> Older firmware version sets BIT(13) in clkflag to mark a
> divider as fractional divider. Updated firmware version sets BIT(4)
> in type flags to mark a divider as fractional divider since
> BIT(13) is defined as CLK_DUTY_CYCLE_PARENT in the common clk
> framework flags.
>
> To support both old and new firmware version, consider BIT(13) from
> clkflag and BIT(4) from type_flag to check if divider is fractional
> or not.
>
> To maintain compatibility BIT(13) of clkflag in firmware will not be
> used in future for any purpose and will be marked as unused.
Why are we mixing the firmware flags with the ccf flags? They shouldn't
be the same. The firmware should have its own 'flag numberspace' that is
distinct from the common clk framework's 'flag numberspace'. Please fix
the code.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [RFC PATCH v12 03/11] psci: export smccc conduit get helper.
From: Jianyong Wu @ 2020-05-27 1:18 UTC (permalink / raw)
To: Sudeep Holla
Cc: Mark Rutland, kvm@vger.kernel.org, will@kernel.org,
kvmarm@lists.cs.columbia.edu, Justin He, Wei Chen, maz@kernel.org,
Steven Price, Kaly Xin, Suzuki Poulose, richardcochran@gmail.com,
yangbo.lu@nxp.com, john.stultz@linaro.org, tglx@linutronix.de, nd,
linux-arm-kernel@lists.infradead.org, Steve Capper,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
sean.j.christopherson@intel.com, Sudeep Holla,
pbonzini@redhat.com
In-Reply-To: <20200526101019.GB11414@bogus>
Hi Sudeep,
> -----Original Message-----
> From: Sudeep Holla <sudeep.holla@arm.com>
> Sent: Tuesday, May 26, 2020 6:10 PM
> To: Jianyong Wu <Jianyong.Wu@arm.com>
> Cc: netdev@vger.kernel.org; yangbo.lu@nxp.com; john.stultz@linaro.org;
> tglx@linutronix.de; pbonzini@redhat.com; sean.j.christopherson@intel.com;
> maz@kernel.org; richardcochran@gmail.com; Mark Rutland
> <Mark.Rutland@arm.com>; will@kernel.org; Suzuki Poulose
> <Suzuki.Poulose@arm.com>; Steven Price <Steven.Price@arm.com>; Justin
> He <Justin.He@arm.com>; Wei Chen <Wei.Chen@arm.com>;
> kvm@vger.kernel.org; Steve Capper <Steve.Capper@arm.com>; linux-
> kernel@vger.kernel.org; Kaly Xin <Kaly.Xin@arm.com>; nd <nd@arm.com>;
> Sudeep Holla <Sudeep.Holla@arm.com>; kvmarm@lists.cs.columbia.edu;
> linux-arm-kernel@lists.infradead.org
> Subject: Re: [RFC PATCH v12 03/11] psci: export smccc conduit get helper.
>
> On Mon, May 25, 2020 at 01:37:56AM +0000, Jianyong Wu wrote:
> > Hi Sudeep,
> >
> > > -----Original Message-----
> > > From: Sudeep Holla <sudeep.holla@arm.com>
> > > Sent: Friday, May 22, 2020 9:12 PM
> > > To: Jianyong Wu <Jianyong.Wu@arm.com>
> > > Cc: netdev@vger.kernel.org; yangbo.lu@nxp.com;
> > > john.stultz@linaro.org; tglx@linutronix.de; pbonzini@redhat.com;
> > > sean.j.christopherson@intel.com; maz@kernel.org;
> > > richardcochran@gmail.com; Mark Rutland <Mark.Rutland@arm.com>;
> > > will@kernel.org; Suzuki Poulose <Suzuki.Poulose@arm.com>; Steven
> > > Price <Steven.Price@arm.com>; Justin He <Justin.He@arm.com>; Wei
> > > Chen <Wei.Chen@arm.com>; kvm@vger.kernel.org; Steve Capper
> > > <Steve.Capper@arm.com>; linux- kernel@vger.kernel.org; Kaly Xin
> > > <Kaly.Xin@arm.com>; nd <nd@arm.com>; Sudeep Holla
> > > <Sudeep.Holla@arm.com>; kvmarm@lists.cs.columbia.edu;
> > > linux-arm-kernel@lists.infradead.org
> > > Subject: Re: [RFC PATCH v12 03/11] psci: export smccc conduit get helper.
> > >
> > > On Fri, May 22, 2020 at 04:37:16PM +0800, Jianyong Wu wrote:
> > > > Export arm_smccc_1_1_get_conduit then modules can use smccc
> helper
> > > > which adopts it.
> > > >
> > > > Acked-by: Mark Rutland <mark.rutland@arm.com>
> > > > Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
> > > > ---
> > > > drivers/firmware/psci/psci.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/firmware/psci/psci.c
> > > > b/drivers/firmware/psci/psci.c index 2937d44b5df4..fd3c88f21b6a
> > > > 100644
> > > > --- a/drivers/firmware/psci/psci.c
> > > > +++ b/drivers/firmware/psci/psci.c
> > > > @@ -64,6 +64,7 @@ enum arm_smccc_conduit
> > > > arm_smccc_1_1_get_conduit(void)
> > > >
> > > > return psci_ops.conduit;
> > > > }
> > > > +EXPORT_SYMBOL(arm_smccc_1_1_get_conduit);
> > > >
> > >
> > > I have moved this into drivers/firmware/smccc/smccc.c [1] Please
> > > update this accordingly.
> >
> > Ok, I will remove this patch next version.
>
> You may need it still, just that this patch won't apply as the function is moved
> to a new file.
>
Yeah, Thanks for remainder!
Thanks
Jianyong
> --
> Regards,
> Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/3] misc: xilinx-sdfec: convert get_user_pages() --> pin_user_pages()
From: John Hubbard @ 2020-05-27 1:26 UTC (permalink / raw)
To: LKML
Cc: Arnd Bergmann, John Hubbard, Dragan Cvetic, Michal Simek,
Souptick Joarder, Greg Kroah-Hartman, Derek Kiernan,
linux-arm-kernel
Hi,
There are also a couple of tiny cleanup patches, just to fix up a few
minor issues that I spotted while converting from get_user_pages_fast()
to pin_user_pages_fast().
Note that I have only compile-tested these patches, although that does
also include cross-compiling for a few other arches. Any run-time
testing would be greatly appreciated!
Cc: Derek Kiernan <derek.kiernan@xilinx.com>
Cc: Dragan Cvetic <dragan.cvetic@xilinx.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: linux-arm-kernel@lists.infradead.org
John Hubbard (3):
misc: xilinx-sdfec: improve get_user_pages_fast() error handling
misc: xilinx-sdfec: cleanup return value in xsdfec_table_write()
misc: xilinx-sdfec: convert get_user_pages() --> pin_user_pages()
drivers/misc/xilinx_sdfec.c | 30 +++++++++++++++++-------------
1 file changed, 17 insertions(+), 13 deletions(-)
base-commit: 9cb1fd0efd195590b828b9b865421ad345a4a145
--
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
* [PATCH 2/3] misc: xilinx-sdfec: cleanup return value in xsdfec_table_write()
From: John Hubbard @ 2020-05-27 1:26 UTC (permalink / raw)
To: LKML
Cc: Arnd Bergmann, John Hubbard, Dragan Cvetic, Michal Simek,
Souptick Joarder, Greg Kroah-Hartman, Derek Kiernan,
linux-arm-kernel
In-Reply-To: <20200527012628.1100649-1-jhubbard@nvidia.com>
Return 0 for success, rather than the value of an incrementing
"reg" index. The reg value was never actually used, so this
simplifies the caller slightly.
Cc: Derek Kiernan <derek.kiernan@xilinx.com>
Cc: Dragan Cvetic <dragan.cvetic@xilinx.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
drivers/misc/xilinx_sdfec.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
index e2766aad9e14..7e2ee3e547f2 100644
--- a/drivers/misc/xilinx_sdfec.c
+++ b/drivers/misc/xilinx_sdfec.c
@@ -648,7 +648,7 @@ static int xsdfec_table_write(struct xsdfec_dev *xsdfec, u32 offset,
((reg * XSDFEC_REG_WIDTH_JUMP) % PAGE_SIZE));
put_page(pages[i]);
}
- return reg;
+ return 0;
}
static int xsdfec_add_ldpc(struct xsdfec_dev *xsdfec, void __user *arg)
@@ -727,8 +727,6 @@ static int xsdfec_add_ldpc(struct xsdfec_dev *xsdfec, void __user *arg)
ret = xsdfec_table_write(xsdfec, 4 * ldpc->qc_off, ldpc->qc_table,
ldpc->nqc, XSDFEC_LDPC_QC_TABLE_ADDR_BASE,
XSDFEC_QC_TABLE_DEPTH);
- if (ret > 0)
- ret = 0;
err_out:
kfree(ldpc);
return ret;
--
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 related
* [PATCH 1/3] misc: xilinx-sdfec: improve get_user_pages_fast() error handling
From: John Hubbard @ 2020-05-27 1:26 UTC (permalink / raw)
To: LKML
Cc: Arnd Bergmann, John Hubbard, Dragan Cvetic, Michal Simek,
Souptick Joarder, Greg Kroah-Hartman, Derek Kiernan,
linux-arm-kernel
In-Reply-To: <20200527012628.1100649-1-jhubbard@nvidia.com>
This fixes the case of get_user_pages_fast() returning a -errno.
The result needs to be stored in a signed integer. And for safe
signed/unsigned comparisons, it's best to keep everything signed.
And get_user_pages_fast() also expects a signed value for number
of pages to pin.
Therefore, change most relevant variables, from u32 to int. Leave
"n" unsigned, for convenience in checking for overflow. And provide
a WARN_ON_ONCE() and early return, if overflow occurs.
Also, as long as we're tidying up: rename the page array from page,
to pages, in order to match the conventions used in most other call
sites.
Fixes: 20ec628e8007e ("misc: xilinx_sdfec: Add ability to configure LDPC")
Cc: Derek Kiernan <derek.kiernan@xilinx.com>
Cc: Dragan Cvetic <dragan.cvetic@xilinx.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
drivers/misc/xilinx_sdfec.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
index 71bbaa56bdb5..e2766aad9e14 100644
--- a/drivers/misc/xilinx_sdfec.c
+++ b/drivers/misc/xilinx_sdfec.c
@@ -602,10 +602,10 @@ static int xsdfec_table_write(struct xsdfec_dev *xsdfec, u32 offset,
const u32 depth)
{
u32 reg = 0;
- u32 res;
- u32 n, i;
+ int res, i, nr_pages;
+ u32 n;
u32 *addr = NULL;
- struct page *page[MAX_NUM_PAGES];
+ struct page *pages[MAX_NUM_PAGES];
/*
* Writes that go beyond the length of
@@ -622,15 +622,22 @@ static int xsdfec_table_write(struct xsdfec_dev *xsdfec, u32 offset,
if ((len * XSDFEC_REG_WIDTH_JUMP) % PAGE_SIZE)
n += 1;
- res = get_user_pages_fast((unsigned long)src_ptr, n, 0, page);
- if (res < n) {
- for (i = 0; i < res; i++)
- put_page(page[i]);
+ if (WARN_ON_ONCE(n > INT_MAX))
+ return -EINVAL;
+
+ nr_pages = n;
+
+ res = get_user_pages_fast((unsigned long)src_ptr, nr_pages, 0, pages);
+ if (res < nr_pages) {
+ if (res > 0) {
+ for (i = 0; i < res; i++)
+ put_page(pages[i]);
+ }
return -EINVAL;
}
- for (i = 0; i < n; i++) {
- addr = kmap(page[i]);
+ for (i = 0; i < nr_pages; i++) {
+ addr = kmap(pages[i]);
do {
xsdfec_regwrite(xsdfec,
base_addr + ((offset + reg) *
@@ -639,7 +646,7 @@ static int xsdfec_table_write(struct xsdfec_dev *xsdfec, u32 offset,
reg++;
} while ((reg < len) &&
((reg * XSDFEC_REG_WIDTH_JUMP) % PAGE_SIZE));
- put_page(page[i]);
+ put_page(pages[i]);
}
return reg;
}
--
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 related
* [PATCH 3/3] misc: xilinx-sdfec: convert get_user_pages() --> pin_user_pages()
From: John Hubbard @ 2020-05-27 1:26 UTC (permalink / raw)
To: LKML
Cc: Arnd Bergmann, John Hubbard, Dragan Cvetic, Michal Simek,
Souptick Joarder, Greg Kroah-Hartman, Derek Kiernan,
linux-arm-kernel
In-Reply-To: <20200527012628.1100649-1-jhubbard@nvidia.com>
This code was using get_user_pages*(), in approximately a "Case 1"
scenario (Direct IO), using the categorization from [1]. That means
that it's time to convert the get_user_pages*() + put_page() calls to
pin_user_pages*() + unpin_user_pages() calls.
There is some helpful background in [2]: basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
Cc: Derek Kiernan <derek.kiernan@xilinx.com>
Cc: Dragan Cvetic <dragan.cvetic@xilinx.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
drivers/misc/xilinx_sdfec.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
index 7e2ee3e547f2..cda3559025d5 100644
--- a/drivers/misc/xilinx_sdfec.c
+++ b/drivers/misc/xilinx_sdfec.c
@@ -627,12 +627,11 @@ static int xsdfec_table_write(struct xsdfec_dev *xsdfec, u32 offset,
nr_pages = n;
- res = get_user_pages_fast((unsigned long)src_ptr, nr_pages, 0, pages);
+ res = pin_user_pages_fast((unsigned long)src_ptr, nr_pages, 0, pages);
if (res < nr_pages) {
- if (res > 0) {
- for (i = 0; i < res; i++)
- put_page(pages[i]);
- }
+ if (res > 0)
+ unpin_user_pages(pages, res);
+
return -EINVAL;
}
@@ -646,7 +645,7 @@ static int xsdfec_table_write(struct xsdfec_dev *xsdfec, u32 offset,
reg++;
} while ((reg < len) &&
((reg * XSDFEC_REG_WIDTH_JUMP) % PAGE_SIZE));
- put_page(pages[i]);
+ unpin_user_page(pages[i]);
}
return 0;
}
--
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 related
* Re: [PATCH][V3] arm64: perf: Get the wrong PC value in REGS_ABI_32 mode
From: Jiping Ma @ 2020-05-27 1:30 UTC (permalink / raw)
To: Will Deacon, Mark Rutland
Cc: zhe.he, bruce.ashfield, yue.tao, will.deacon, linux-kernel,
paul.gortmaker, catalin.marinas, linux-arm-kernel
In-Reply-To: <20200526195419.GB2206@willie-the-truck>
On 05/27/2020 03:54 AM, Will Deacon wrote:
> On Tue, May 26, 2020 at 11:26:11AM +0100, Mark Rutland wrote:
>> On Mon, May 11, 2020 at 10:52:07AM +0800, Jiping Ma wrote:
>>> Modified the patch subject and the change description.
>>>
>>> PC value is get from regs[15] in REGS_ABI_32 mode, but correct PC
>>> is regs->pc(regs[PERF_REG_ARM64_PC]) in arm64 kernel, which caused
>>> that perf can not parser the backtrace of app with dwarf mode in the
>>> 32bit system and 64bit kernel.
>>>
>>> Signed-off-by: Jiping Ma <jiping.ma2@windriver.com>
>> Thanks for this.
>>
>>
>>> ---
>>> arch/arm64/kernel/perf_regs.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/arch/arm64/kernel/perf_regs.c b/arch/arm64/kernel/perf_regs.c
>>> index 0bbac61..0ef2880 100644
>>> --- a/arch/arm64/kernel/perf_regs.c
>>> +++ b/arch/arm64/kernel/perf_regs.c
>>> @@ -32,6 +32,10 @@ u64 perf_reg_value(struct pt_regs *regs, int idx)
>>> if ((u32)idx == PERF_REG_ARM64_PC)
>>> return regs->pc;
>>>
>>> + if (perf_reg_abi(current) == PERF_SAMPLE_REGS_ABI_32
>>> + && idx == 15)
>>> + return regs->pc;
>> I think there are some more issues here, and we may need a more
>> substantial rework. For a compat thread, we always expose
>> PERF_SAMPLE_REGS_ABI_32 via per_reg_abi(), but for some reason
>> perf_reg_value() also munges the compat SP/LR into their ARM64
>> equivalents, which don't exist in the 32-bit sample ABI. We also don't
>> zero the regs that don't exist in 32-bit (including the aliasing PC).
> I think this was for the case where you have a 64-bit perf profiling a
> 32-bit task, and it was passing the registers off to libunwind. Won't that
> break if we follow your suggestion?
Yes, it is for 64-bit perf profiling a 32-bit task, not for a compat thread.
>
> Will
>
_______________________________________________
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] arm64: perf: Get the wrong PC value in REGS_ABI_32 mode
From: Jiping Ma @ 2020-05-27 1:33 UTC (permalink / raw)
To: Mark Rutland
Cc: zhe.he, bruce.ashfield, yue.tao, will.deacon, linux-kernel,
paul.gortmaker, catalin.marinas, linux-arm-kernel
In-Reply-To: <20200526102611.GA1363@C02TD0UTHF1T.local>
On 05/26/2020 06:26 PM, Mark Rutland wrote:
> On Mon, May 11, 2020 at 10:52:07AM +0800, Jiping Ma wrote:
>> Modified the patch subject and the change description.
>>
>> PC value is get from regs[15] in REGS_ABI_32 mode, but correct PC
>> is regs->pc(regs[PERF_REG_ARM64_PC]) in arm64 kernel, which caused
>> that perf can not parser the backtrace of app with dwarf mode in the
>> 32bit system and 64bit kernel.
>>
>> Signed-off-by: Jiping Ma <jiping.ma2@windriver.com>
> Thanks for this.
>
>
>> ---
>> arch/arm64/kernel/perf_regs.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/perf_regs.c b/arch/arm64/kernel/perf_regs.c
>> index 0bbac61..0ef2880 100644
>> --- a/arch/arm64/kernel/perf_regs.c
>> +++ b/arch/arm64/kernel/perf_regs.c
>> @@ -32,6 +32,10 @@ u64 perf_reg_value(struct pt_regs *regs, int idx)
>> if ((u32)idx == PERF_REG_ARM64_PC)
>> return regs->pc;
>>
>> + if (perf_reg_abi(current) == PERF_SAMPLE_REGS_ABI_32
>> + && idx == 15)
>> + return regs->pc;
> I think there are some more issues here, and we may need a more
> substantial rework. For a compat thread, we always expose
> PERF_SAMPLE_REGS_ABI_32 via per_reg_abi(), but for some reason
> perf_reg_value() also munges the compat SP/LR into their ARM64
> equivalents, which don't exist in the 32-bit sample ABI. We also don't
> zero the regs that don't exist in 32-bit (including the aliasing PC).
>
> I reckon what we should do is have seperate functions for the two ABIs,
> to ensure we don't conflate them, e.g.
>
> u64 perf_reg_value_abi32(struct pt_regs *regs, int idx)
> {
> if ((u32)idx > PERF_REG_ARM32_PC)
> return 0;
> if (idx == PERF_REG_ARM32_PC)
> return regs->pc;
>
> /*
> * Compat SP and LR already in-place
> */
> return regs->regs[idx];
> }
>
> u64 perf_reg_value_abi64(struct pt_regs *regs, int idx)
> {
> if ((u32)idx > PERF_REG_ARM64_MAX)
> return 0;
> if ((u32)idx == PERF_REG_ARM64_SP)
> return regs->sp;
> if ((u32)idx == PERF_REG_ARM64_PC)
> return regs->pc;
>
> reutrn regs->regs[idx];
> }
>
> u64 perf_reg_value(struct pt_regs *regs, int idx)
> {
> if (compat_user_mode(regs))
> return perf_reg_value_abi32(regs, idx);
> else
> return perf_reg_value_abi64(regs, idx);
> }
This modification can not fix our issue, we need
perf_reg_abi(current) == PERF_SAMPLE_REGS_ABI_32 to judge if it is
32-bit task or not,
then return the correct PC value.
> 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
* [PATCH] [v2] i2c: stm32f7: Fix runtime PM imbalance on error
From: Dinghao Liu @ 2020-05-27 1:38 UTC (permalink / raw)
To: dinghao.liu, kjlu
Cc: Alexandre Torgue, linux-kernel, Pierre-Yves MORDRET, linux-i2c,
Maxime Coquelin, linux-stm32, linux-arm-kernel
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
---
Changelog:
v2: - Use pm_runtime_put_noidle() instead of
pm_runtime_put_autosuspend(). Fix 5 more
similar cases within this dirver.
---
drivers/i2c/busses/i2c-stm32f7.c | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index 330ffed011e0..822fd1f5b5ae 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -1620,8 +1620,10 @@ static int stm32f7_i2c_xfer(struct i2c_adapter *i2c_adap,
f7_msg->smbus = false;
ret = pm_runtime_get_sync(i2c_dev->dev);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put_noidle(i2c_dev->dev);
return ret;
+ }
ret = stm32f7_i2c_wait_free_bus(i2c_dev);
if (ret)
@@ -1666,8 +1668,10 @@ static int stm32f7_i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr,
f7_msg->smbus = true;
ret = pm_runtime_get_sync(dev);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put_noidle(dev);
return ret;
+ }
ret = stm32f7_i2c_wait_free_bus(i2c_dev);
if (ret)
@@ -1767,8 +1771,10 @@ static int stm32f7_i2c_reg_slave(struct i2c_client *slave)
return ret;
ret = pm_runtime_get_sync(dev);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put_noidle(dev);
return ret;
+ }
if (!stm32f7_i2c_is_slave_registered(i2c_dev))
stm32f7_i2c_enable_wakeup(i2c_dev, true);
@@ -1837,8 +1843,10 @@ static int stm32f7_i2c_unreg_slave(struct i2c_client *slave)
WARN_ON(!i2c_dev->slave[id]);
ret = pm_runtime_get_sync(i2c_dev->dev);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put_noidle(i2c_dev->dev);
return ret;
+ }
if (id == 0) {
mask = STM32F7_I2C_OAR1_OA1EN;
@@ -2182,8 +2190,10 @@ static int stm32f7_i2c_regs_backup(struct stm32f7_i2c_dev *i2c_dev)
struct stm32f7_i2c_regs *backup_regs = &i2c_dev->backup_regs;
ret = pm_runtime_get_sync(i2c_dev->dev);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put_noidle(i2c_dev->dev);
return ret;
+ }
backup_regs->cr1 = readl_relaxed(i2c_dev->base + STM32F7_I2C_CR1);
backup_regs->cr2 = readl_relaxed(i2c_dev->base + STM32F7_I2C_CR2);
@@ -2204,8 +2214,10 @@ static int stm32f7_i2c_regs_restore(struct stm32f7_i2c_dev *i2c_dev)
struct stm32f7_i2c_regs *backup_regs = &i2c_dev->backup_regs;
ret = pm_runtime_get_sync(i2c_dev->dev);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put_noidle(i2c_dev->dev);
return ret;
+ }
cr1 = readl_relaxed(i2c_dev->base + STM32F7_I2C_CR1);
if (cr1 & STM32F7_I2C_CR1_PE)
--
2.17.1
_______________________________________________
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 v5 5/8] clk: stm32: Fix stm32f429's ltdc driver hang in set clock rate, fix duplicated ltdc clock register to 'clk_core' case ltdc's clock turn off by clk_disable_unused()
From: Stephen Boyd @ 2020-05-27 1:44 UTC (permalink / raw)
To: broonie, dillon.minfei, linus.walleij
Cc: devicetree, linux-clk, linux-kernel, dri-devel, linux-spi,
dillon min, linux-stm32, linux-arm-kernel
In-Reply-To: <1590378348-8115-6-git-send-email-dillon.minfei@gmail.com>
Quoting dillon.minfei@gmail.com (2020-05-24 20:45:45)
> From: dillon min <dillon.minfei@gmail.com>
>
> ltdc set clock rate crashed
> 'post_div_data[]''s pll_num is PLL_I2S, PLL_SAI (number is 1,2). but,
Please write "post_div_data[]'s" if it is possessive. "But" doesn't
start a sentence. This is one sentence, not two.
> as pll_num is offset of 'clks[]' input to clk_register_pll_div(), which
> is FCLK, CLK_LSI, defined in 'include/dt-bindings/clock/stm32fx-clock.h'
> so, this is a null object at the register time.
> then, in ltdc's clock is_enabled(), enable(), will call to_clk_gate().
> will return a null object, cause kernel crashed.
> need change pll_num to PLL_VCO_I2S, PLL_VCO_SAI for 'post_div_data[]'
>
> duplicated ltdc clock
> 'stm32f429_gates[]' has a member 'ltdc' register to 'clk_core', but no
> upper driver use it, ltdc driver use the lcd-tft defined in
> 'stm32f429_aux_clk[]'. after system startup, as stm32f429_gates[]'s ltdc
> enable_count is zero, so turn off by clk_disable_unused()
I sort of follow this. Is this another patch? Seems like two things are
going on here.
>
> Changes since V3:
> 1 drop last wrong changes about 'CLK_IGNORE_UNUSED' patch
> 2 fix PLL_SAI mismatch with PLL_VCO_SAI
This change log goes under the --- below.
>
> Signed-off-by: dillon min <dillon.minfei@gmail.com>
Any Fixes tag?
_______________________________________________
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 -next] clk: zynqmp: Make zynqmp_clk_get_max_divisor static
From: Stephen Boyd @ 2020-05-27 1:45 UTC (permalink / raw)
To: m.tretter, michal.simek, mturquette, rajan.vaja, tejas.patel,
yuehaibing
Cc: linux-clk, linux-arm-kernel, linux-kernel
In-Reply-To: <20200403083040.37748-1-yuehaibing@huawei.com>
Quoting YueHaibing (2020-04-03 01:30:40)
> Fix sparse warning:
>
> drivers/clk/zynqmp/divider.c:259:5: warning:
> symbol 'zynqmp_clk_get_max_divisor' was not declared. Should it be static?
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
Applied to clk-next
_______________________________________________
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 v9] mfd: mt6360: add pmic mt6360 driver
From: Gene Chen @ 2020-05-27 1:47 UTC (permalink / raw)
To: Lee Jones, matthias.bgg
Cc: Gene Chen, linux-kernel, cy_huang, linux-mediatek, Wilma.Wu,
linux-arm-kernel, shufan_lee
In-Reply-To: <1587641093-25441-1-git-send-email-gene.chen.richtek@gmail.com>
Gene Chen <gene.chen.richtek@gmail.com> 於 2020年4月23日 週四 下午7:25寫道：
>
> Add mfd driver for mt6360 pmic chip include
> Battery Charger/USB_PD/Flash LED/RGB LED/LDO/Buck
>
> Signed-off-by: Gene Chen <gene_chen@richtek.com>
> Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/mfd/Kconfig | 12 ++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/mt6360-core.c | 425 +++++++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/mt6360.h | 240 +++++++++++++++++++++++++
> 4 files changed, 678 insertions(+)
> create mode 100644 drivers/mfd/mt6360-core.c
> create mode 100644 include/linux/mfd/mt6360.h
>
> changelogs between v1 & v2
> - include missing header file
>
> changelogs between v2 & v3
> - add changelogs
>
> changelogs between v3 & v4
> - fix Kconfig description
> - replace mt6360_pmu_info with mt6360_pmu_data
> - replace probe with probe_new
> - remove unnecessary irq_chip variable
> - remove annotation
> - replace MT6360_MFD_CELL with OF_MFD_CELL
>
> changelogs between v4 & v5
> - remove unnecessary parse dt function
> - use devm_i2c_new_dummy_device
> - add base-commit message
>
> changelogs between v5 & v6
> - review return value
> - remove i2c id_table
> - use GPL license v2
>
> changelogs between v6 & v7
> - add author description
> - replace MT6360_REGMAP_IRQ_REG by REGMAP_IRQ_REG_LINE
> - remove mt6360-private.h
>
> changelogs between v7 & v8
> - fix kbuild auto reboot by include interrupt header
>
> changelogs between v8 & v9
> - fix GPL license out of date
> - add commit message about Acked-for-MFD-by
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 2b20329..0f8c341 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -857,6 +857,18 @@ config MFD_MAX8998
> additional drivers must be enabled in order to use the functionality
> of the device.
>
> +config MFD_MT6360
> + tristate "Mediatek MT6360 SubPMIC"
> + select MFD_CORE
> + select REGMAP_I2C
> + select REGMAP_IRQ
> + depends on I2C
> + help
> + Say Y here to enable MT6360 PMU/PMIC/LDO functional support.
> + PMU part includes Charger, Flashlight, RGB LED
> + PMIC part includes 2-channel BUCKs and 2-channel LDOs
> + LDO part includes 4-channel LDOs
> +
> config MFD_MT6397
> tristate "MediaTek MT6397 PMIC Support"
> select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index b83f172..8c35816 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -238,6 +238,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI) += intel_soc_pmic_chtdc_ti.o
> +obj-$(CONFIG_MFD_MT6360) += mt6360-core.o
> mt6397-objs := mt6397-core.o mt6397-irq.o
> obj-$(CONFIG_MFD_MT6397) += mt6397.o
> obj-$(CONFIG_INTEL_SOC_PMIC_MRFLD) += intel_soc_pmic_mrfld.o
> diff --git a/drivers/mfd/mt6360-core.c b/drivers/mfd/mt6360-core.c
> new file mode 100644
> index 0000000..9bb63e0
> --- /dev/null
> +++ b/drivers/mfd/mt6360-core.c
> @@ -0,0 +1,425 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 MediaTek Inc.
> + *
> + * Author: Gene Chen <gene_chen@richtek.com>
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/core.h>
> +#include <linux/module.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/version.h>
> +
> +#include <linux/mfd/mt6360.h>
> +
> +/* reg 0 -> 0 ~ 7 */
> +#define MT6360_CHG_TREG_EVT (4)
> +#define MT6360_CHG_AICR_EVT (5)
> +#define MT6360_CHG_MIVR_EVT (6)
> +#define MT6360_PWR_RDY_EVT (7)
> +/* REG 1 -> 8 ~ 15 */
> +#define MT6360_CHG_BATSYSUV_EVT (9)
> +#define MT6360_FLED_CHG_VINOVP_EVT (11)
> +#define MT6360_CHG_VSYSUV_EVT (12)
> +#define MT6360_CHG_VSYSOV_EVT (13)
> +#define MT6360_CHG_VBATOV_EVT (14)
> +#define MT6360_CHG_VBUSOV_EVT (15)
> +/* REG 2 -> 16 ~ 23 */
> +/* REG 3 -> 24 ~ 31 */
> +#define MT6360_WD_PMU_DET (25)
> +#define MT6360_WD_PMU_DONE (26)
> +#define MT6360_CHG_TMRI (27)
> +#define MT6360_CHG_ADPBADI (29)
> +#define MT6360_CHG_RVPI (30)
> +#define MT6360_OTPI (31)
> +/* REG 4 -> 32 ~ 39 */
> +#define MT6360_CHG_AICCMEASL (32)
> +#define MT6360_CHGDET_DONEI (34)
> +#define MT6360_WDTMRI (35)
> +#define MT6360_SSFINISHI (36)
> +#define MT6360_CHG_RECHGI (37)
> +#define MT6360_CHG_TERMI (38)
> +#define MT6360_CHG_IEOCI (39)
> +/* REG 5 -> 40 ~ 47 */
> +#define MT6360_PUMPX_DONEI (40)
> +#define MT6360_BAT_OVP_ADC_EVT (41)
> +#define MT6360_TYPEC_OTP_EVT (42)
> +#define MT6360_ADC_WAKEUP_EVT (43)
> +#define MT6360_ADC_DONEI (44)
> +#define MT6360_BST_BATUVI (45)
> +#define MT6360_BST_VBUSOVI (46)
> +#define MT6360_BST_OLPI (47)
> +/* REG 6 -> 48 ~ 55 */
> +#define MT6360_ATTACH_I (48)
> +#define MT6360_DETACH_I (49)
> +#define MT6360_QC30_STPDONE (51)
> +#define MT6360_QC_VBUSDET_DONE (52)
> +#define MT6360_HVDCP_DET (53)
> +#define MT6360_CHGDETI (54)
> +#define MT6360_DCDTI (55)
> +/* REG 7 -> 56 ~ 63 */
> +#define MT6360_FOD_DONE_EVT (56)
> +#define MT6360_FOD_OV_EVT (57)
> +#define MT6360_CHRDET_UVP_EVT (58)
> +#define MT6360_CHRDET_OVP_EVT (59)
> +#define MT6360_CHRDET_EXT_EVT (60)
> +#define MT6360_FOD_LR_EVT (61)
> +#define MT6360_FOD_HR_EVT (62)
> +#define MT6360_FOD_DISCHG_FAIL_EVT (63)
> +/* REG 8 -> 64 ~ 71 */
> +#define MT6360_USBID_EVT (64)
> +#define MT6360_APWDTRST_EVT (65)
> +#define MT6360_EN_EVT (66)
> +#define MT6360_QONB_RST_EVT (67)
> +#define MT6360_MRSTB_EVT (68)
> +#define MT6360_OTP_EVT (69)
> +#define MT6360_VDDAOV_EVT (70)
> +#define MT6360_SYSUV_EVT (71)
> +/* REG 9 -> 72 ~ 79 */
> +#define MT6360_FLED_STRBPIN_EVT (72)
> +#define MT6360_FLED_TORPIN_EVT (73)
> +#define MT6360_FLED_TX_EVT (74)
> +#define MT6360_FLED_LVF_EVT (75)
> +#define MT6360_FLED2_SHORT_EVT (78)
> +#define MT6360_FLED1_SHORT_EVT (79)
> +/* REG 10 -> 80 ~ 87 */
> +#define MT6360_FLED2_STRB_EVT (80)
> +#define MT6360_FLED1_STRB_EVT (81)
> +#define MT6360_FLED2_STRB_TO_EVT (82)
> +#define MT6360_FLED1_STRB_TO_EVT (83)
> +#define MT6360_FLED2_TOR_EVT (84)
> +#define MT6360_FLED1_TOR_EVT (85)
> +/* REG 11 -> 88 ~ 95 */
> +/* REG 12 -> 96 ~ 103 */
> +#define MT6360_BUCK1_PGB_EVT (96)
> +#define MT6360_BUCK1_OC_EVT (100)
> +#define MT6360_BUCK1_OV_EVT (101)
> +#define MT6360_BUCK1_UV_EVT (102)
> +/* REG 13 -> 104 ~ 111 */
> +#define MT6360_BUCK2_PGB_EVT (104)
> +#define MT6360_BUCK2_OC_EVT (108)
> +#define MT6360_BUCK2_OV_EVT (109)
> +#define MT6360_BUCK2_UV_EVT (110)
> +/* REG 14 -> 112 ~ 119 */
> +#define MT6360_LDO1_OC_EVT (113)
> +#define MT6360_LDO2_OC_EVT (114)
> +#define MT6360_LDO3_OC_EVT (115)
> +#define MT6360_LDO5_OC_EVT (117)
> +#define MT6360_LDO6_OC_EVT (118)
> +#define MT6360_LDO7_OC_EVT (119)
> +/* REG 15 -> 120 ~ 127 */
> +#define MT6360_LDO1_PGB_EVT (121)
> +#define MT6360_LDO2_PGB_EVT (122)
> +#define MT6360_LDO3_PGB_EVT (123)
> +#define MT6360_LDO5_PGB_EVT (125)
> +#define MT6360_LDO6_PGB_EVT (126)
> +#define MT6360_LDO7_PGB_EVT (127)
> +
> +static const struct regmap_irq mt6360_pmu_irqs[] = {
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_TREG_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_AICR_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_MIVR_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_PWR_RDY_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_BATSYSUV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED_CHG_VINOVP_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_VSYSUV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_VSYSOV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_VBATOV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_VBUSOV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_WD_PMU_DET, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_WD_PMU_DONE, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_TMRI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_ADPBADI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_RVPI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_OTPI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_AICCMEASL, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHGDET_DONEI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_WDTMRI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_SSFINISHI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_RECHGI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_TERMI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_IEOCI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_PUMPX_DONEI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_TREG_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BAT_OVP_ADC_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_TYPEC_OTP_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_ADC_WAKEUP_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_ADC_DONEI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BST_BATUVI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BST_VBUSOVI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BST_OLPI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_ATTACH_I, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_DETACH_I, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_QC30_STPDONE, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_QC_VBUSDET_DONE, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_HVDCP_DET, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHGDETI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_DCDTI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FOD_DONE_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FOD_OV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHRDET_UVP_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHRDET_OVP_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHRDET_EXT_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FOD_LR_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FOD_HR_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FOD_DISCHG_FAIL_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_USBID_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_APWDTRST_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_EN_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_QONB_RST_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_MRSTB_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_OTP_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_VDDAOV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_SYSUV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED_STRBPIN_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED_TORPIN_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED_TX_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED_LVF_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED2_SHORT_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED1_SHORT_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED2_STRB_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED1_STRB_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED2_STRB_TO_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED1_STRB_TO_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED2_TOR_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED1_TOR_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BUCK1_PGB_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BUCK1_OC_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BUCK1_OV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BUCK1_UV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BUCK2_PGB_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BUCK2_OC_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BUCK2_OV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BUCK2_UV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO1_OC_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO2_OC_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO3_OC_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO5_OC_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO6_OC_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO7_OC_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO1_PGB_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO2_PGB_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO3_PGB_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO5_PGB_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO6_PGB_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO7_PGB_EVT, 8),
> +};
> +
> +static int mt6360_pmu_handle_post_irq(void *irq_drv_data)
> +{
> + struct mt6360_pmu_data *mpd = irq_drv_data;
> +
> + return regmap_update_bits(mpd->regmap,
> + MT6360_PMU_IRQ_SET, MT6360_IRQ_RETRIG, MT6360_IRQ_RETRIG);
> +}
> +
> +static struct regmap_irq_chip mt6360_pmu_irq_chip = {
> + .irqs = mt6360_pmu_irqs,
> + .num_irqs = ARRAY_SIZE(mt6360_pmu_irqs),
> + .num_regs = MT6360_PMU_IRQ_REGNUM,
> + .mask_base = MT6360_PMU_CHG_MASK1,
> + .status_base = MT6360_PMU_CHG_IRQ1,
> + .ack_base = MT6360_PMU_CHG_IRQ1,
> + .init_ack_masked = true,
> + .use_ack = true,
> + .handle_post_irq = mt6360_pmu_handle_post_irq,
> +};
> +
> +static const struct regmap_config mt6360_pmu_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = MT6360_PMU_MAXREG,
> +};
> +
> +static const struct resource mt6360_adc_resources[] = {
> + DEFINE_RES_IRQ_NAMED(MT6360_ADC_DONEI, "adc_donei"),
> +};
> +
> +static const struct resource mt6360_chg_resources[] = {
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_TREG_EVT, "chg_treg_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_PWR_RDY_EVT, "pwr_rdy_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_BATSYSUV_EVT, "chg_batsysuv_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VSYSUV_EVT, "chg_vsysuv_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VSYSOV_EVT, "chg_vsysov_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VBATOV_EVT, "chg_vbatov_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VBUSOV_EVT, "chg_vbusov_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_AICCMEASL, "chg_aiccmeasl"),
> + DEFINE_RES_IRQ_NAMED(MT6360_WDTMRI, "wdtmri"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_RECHGI, "chg_rechgi"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_TERMI, "chg_termi"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_IEOCI, "chg_ieoci"),
> + DEFINE_RES_IRQ_NAMED(MT6360_PUMPX_DONEI, "pumpx_donei"),
> + DEFINE_RES_IRQ_NAMED(MT6360_ATTACH_I, "attach_i"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHRDET_EXT_EVT, "chrdet_ext_evt"),
> +};
> +
> +static const struct resource mt6360_led_resources[] = {
> + DEFINE_RES_IRQ_NAMED(MT6360_FLED_CHG_VINOVP_EVT, "fled_chg_vinovp_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_FLED_LVF_EVT, "fled_lvf_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_FLED2_SHORT_EVT, "fled2_short_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_FLED1_SHORT_EVT, "fled1_short_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_FLED2_STRB_TO_EVT, "fled2_strb_to_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_FLED1_STRB_TO_EVT, "fled1_strb_to_evt"),
> +};
> +
> +static const struct resource mt6360_pmic_resources[] = {
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_PGB_EVT, "buck1_pgb_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_OC_EVT, "buck1_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_OV_EVT, "buck1_ov_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_UV_EVT, "buck1_uv_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_PGB_EVT, "buck2_pgb_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_OC_EVT, "buck2_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_OV_EVT, "buck2_ov_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_UV_EVT, "buck2_uv_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO6_OC_EVT, "ldo6_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO7_OC_EVT, "ldo7_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO6_PGB_EVT, "ldo6_pgb_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO7_PGB_EVT, "ldo7_pgb_evt"),
> +};
> +
> +static const struct resource mt6360_ldo_resources[] = {
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO1_OC_EVT, "ldo1_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO2_OC_EVT, "ldo2_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO3_OC_EVT, "ldo3_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO5_OC_EVT, "ldo5_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO1_PGB_EVT, "ldo1_pgb_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO2_PGB_EVT, "ldo2_pgb_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO3_PGB_EVT, "ldo3_pgb_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO5_PGB_EVT, "ldo5_pgb_evt"),
> +};
> +
> +static const struct mfd_cell mt6360_devs[] = {
> + OF_MFD_CELL("mt6360_adc", mt6360_adc_resources,
> + NULL, 0, 0, "mediatek,mt6360_adc"),
> + OF_MFD_CELL("mt6360_chg", mt6360_chg_resources,
> + NULL, 0, 0, "mediatek,mt6360_chg"),
> + OF_MFD_CELL("mt6360_led", mt6360_led_resources,
> + NULL, 0, 0, "mediatek,mt6360_led"),
> + OF_MFD_CELL("mt6360_pmic", mt6360_pmic_resources,
> + NULL, 0, 0, "mediatek,mt6360_pmic"),
> + OF_MFD_CELL("mt6360_ldo", mt6360_ldo_resources,
> + NULL, 0, 0, "mediatek,mt6360_ldo"),
> + OF_MFD_CELL("mt6360_tcpc", NULL,
> + NULL, 0, 0, "mediatek,mt6360_tcpc"),
> +};
> +
> +static const unsigned short mt6360_slave_addr[MT6360_SLAVE_MAX] = {
> + MT6360_PMU_SLAVEID,
> + MT6360_PMIC_SLAVEID,
> + MT6360_LDO_SLAVEID,
> + MT6360_TCPC_SLAVEID,
> +};
> +
> +static int mt6360_pmu_probe(struct i2c_client *client)
> +{
> + struct mt6360_pmu_data *mpd;
> + unsigned int reg_data;
> + int i, ret;
> +
> + mpd = devm_kzalloc(&client->dev, sizeof(*mpd), GFP_KERNEL);
> + if (!mpd)
> + return -ENOMEM;
> +
> + mpd->dev = &client->dev;
> + i2c_set_clientdata(client, mpd);
> +
> + mpd->regmap = devm_regmap_init_i2c(client, &mt6360_pmu_regmap_config);
> + if (IS_ERR(mpd->regmap)) {
> + dev_err(&client->dev, "Failed to register regmap\n");
> + return PTR_ERR(mpd->regmap);
> + }
> +
> + ret = regmap_read(mpd->regmap, MT6360_PMU_DEV_INFO, ®_data);
> + if (ret) {
> + dev_err(&client->dev, "Device not found\n");
> + return ret;
> + }
> +
> + mpd->chip_rev = reg_data & CHIP_REV_MASK;
> + if (mpd->chip_rev != CHIP_VEN_MT6360) {
> + dev_err(&client->dev, "Device not supported\n");
> + return -ENODEV;
> + }
> +
> + mt6360_pmu_irq_chip.irq_drv_data = mpd;
> + ret = devm_regmap_add_irq_chip(&client->dev, mpd->regmap, client->irq,
> + IRQF_TRIGGER_FALLING, 0,
> + &mt6360_pmu_irq_chip, &mpd->irq_data);
> + if (ret) {
> + dev_err(&client->dev, "Failed to add Regmap IRQ Chip\n");
> + return ret;
> + }
> +
> + mpd->i2c[0] = client;
> + for (i = 1; i < MT6360_SLAVE_MAX; i++) {
> + mpd->i2c[i] = devm_i2c_new_dummy_device(&client->dev,
> + client->adapter,
> + mt6360_slave_addr[i]);
> + if (IS_ERR(mpd->i2c[i])) {
> + dev_err(&client->dev,
> + "Failed to get new dummy I2C device for address 0x%x",
> + mt6360_slave_addr[i]);
> + return PTR_ERR(mpd->i2c[i]);
> + }
> + i2c_set_clientdata(mpd->i2c[i], mpd);
> + }
> +
> + ret = devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_AUTO,
> + mt6360_devs, ARRAY_SIZE(mt6360_devs), NULL,
> + 0, regmap_irq_get_domain(mpd->irq_data));
> + if (ret) {
> + dev_err(&client->dev,
> + "Failed to register subordinate devices\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int __maybe_unused mt6360_pmu_suspend(struct device *dev)
> +{
> + struct i2c_client *i2c = to_i2c_client(dev);
> +
> + if (device_may_wakeup(dev))
> + enable_irq_wake(i2c->irq);
> +
> + return 0;
> +}
> +
> +static int __maybe_unused mt6360_pmu_resume(struct device *dev)
> +{
> +
> + struct i2c_client *i2c = to_i2c_client(dev);
> +
> + if (device_may_wakeup(dev))
> + disable_irq_wake(i2c->irq);
> +
> + return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(mt6360_pmu_pm_ops,
> + mt6360_pmu_suspend, mt6360_pmu_resume);
> +
> +static const struct of_device_id __maybe_unused mt6360_pmu_of_id[] = {
> + { .compatible = "mediatek,mt6360_pmu", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, mt6360_pmu_of_id);
> +
> +static struct i2c_driver mt6360_pmu_driver = {
> + .driver = {
> + .pm = &mt6360_pmu_pm_ops,
> + .of_match_table = of_match_ptr(mt6360_pmu_of_id),
> + },
> + .probe_new = mt6360_pmu_probe,
> +};
> +module_i2c_driver(mt6360_pmu_driver);
> +
> +MODULE_AUTHOR("Gene Chen <gene_chen@richtek.com>");
> +MODULE_DESCRIPTION("MT6360 PMU I2C Driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/mfd/mt6360.h b/include/linux/mfd/mt6360.h
> new file mode 100644
> index 0000000..ea13040
> --- /dev/null
> +++ b/include/linux/mfd/mt6360.h
> @@ -0,0 +1,240 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2020 MediaTek Inc.
> + */
> +
> +#ifndef __MT6360_H__
> +#define __MT6360_H__
> +
> +#include <linux/regmap.h>
> +
> +enum {
> + MT6360_SLAVE_PMU = 0,
> + MT6360_SLAVE_PMIC,
> + MT6360_SLAVE_LDO,
> + MT6360_SLAVE_TCPC,
> + MT6360_SLAVE_MAX,
> +};
> +
> +#define MT6360_PMU_SLAVEID (0x34)
> +#define MT6360_PMIC_SLAVEID (0x1A)
> +#define MT6360_LDO_SLAVEID (0x64)
> +#define MT6360_TCPC_SLAVEID (0x4E)
> +
> +struct mt6360_pmu_data {
> + struct i2c_client *i2c[MT6360_SLAVE_MAX];
> + struct device *dev;
> + struct regmap *regmap;
> + struct regmap_irq_chip_data *irq_data;
> + unsigned int chip_rev;
> +};
> +
> +/* PMU register defininition */
> +#define MT6360_PMU_DEV_INFO (0x00)
> +#define MT6360_PMU_CORE_CTRL1 (0x01)
> +#define MT6360_PMU_RST1 (0x02)
> +#define MT6360_PMU_CRCEN (0x03)
> +#define MT6360_PMU_RST_PAS_CODE1 (0x04)
> +#define MT6360_PMU_RST_PAS_CODE2 (0x05)
> +#define MT6360_PMU_CORE_CTRL2 (0x06)
> +#define MT6360_PMU_TM_PAS_CODE1 (0x07)
> +#define MT6360_PMU_TM_PAS_CODE2 (0x08)
> +#define MT6360_PMU_TM_PAS_CODE3 (0x09)
> +#define MT6360_PMU_TM_PAS_CODE4 (0x0A)
> +#define MT6360_PMU_IRQ_IND (0x0B)
> +#define MT6360_PMU_IRQ_MASK (0x0C)
> +#define MT6360_PMU_IRQ_SET (0x0D)
> +#define MT6360_PMU_SHDN_CTRL (0x0E)
> +#define MT6360_PMU_TM_INF (0x0F)
> +#define MT6360_PMU_I2C_CTRL (0x10)
> +#define MT6360_PMU_CHG_CTRL1 (0x11)
> +#define MT6360_PMU_CHG_CTRL2 (0x12)
> +#define MT6360_PMU_CHG_CTRL3 (0x13)
> +#define MT6360_PMU_CHG_CTRL4 (0x14)
> +#define MT6360_PMU_CHG_CTRL5 (0x15)
> +#define MT6360_PMU_CHG_CTRL6 (0x16)
> +#define MT6360_PMU_CHG_CTRL7 (0x17)
> +#define MT6360_PMU_CHG_CTRL8 (0x18)
> +#define MT6360_PMU_CHG_CTRL9 (0x19)
> +#define MT6360_PMU_CHG_CTRL10 (0x1A)
> +#define MT6360_PMU_CHG_CTRL11 (0x1B)
> +#define MT6360_PMU_CHG_CTRL12 (0x1C)
> +#define MT6360_PMU_CHG_CTRL13 (0x1D)
> +#define MT6360_PMU_CHG_CTRL14 (0x1E)
> +#define MT6360_PMU_CHG_CTRL15 (0x1F)
> +#define MT6360_PMU_CHG_CTRL16 (0x20)
> +#define MT6360_PMU_CHG_AICC_RESULT (0x21)
> +#define MT6360_PMU_DEVICE_TYPE (0x22)
> +#define MT6360_PMU_QC_CONTROL1 (0x23)
> +#define MT6360_PMU_QC_CONTROL2 (0x24)
> +#define MT6360_PMU_QC30_CONTROL1 (0x25)
> +#define MT6360_PMU_QC30_CONTROL2 (0x26)
> +#define MT6360_PMU_USB_STATUS1 (0x27)
> +#define MT6360_PMU_QC_STATUS1 (0x28)
> +#define MT6360_PMU_QC_STATUS2 (0x29)
> +#define MT6360_PMU_CHG_PUMP (0x2A)
> +#define MT6360_PMU_CHG_CTRL17 (0x2B)
> +#define MT6360_PMU_CHG_CTRL18 (0x2C)
> +#define MT6360_PMU_CHRDET_CTRL1 (0x2D)
> +#define MT6360_PMU_CHRDET_CTRL2 (0x2E)
> +#define MT6360_PMU_DPDN_CTRL (0x2F)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL1 (0x30)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL2 (0x31)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL3 (0x32)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL4 (0x33)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL5 (0x34)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL6 (0x35)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL7 (0x36)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL8 (0x37)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL9 (0x38)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL10 (0x39)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL11 (0x3A)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL12 (0x3B)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL13 (0x3C)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL14 (0x3D)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL15 (0x3E)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL16 (0x3F)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL17 (0x40)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL18 (0x41)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL19 (0x42)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL20 (0x43)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL21 (0x44)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL22 (0x45)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL23 (0x46)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL24 (0x47)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL25 (0x48)
> +#define MT6360_PMU_BC12_CTRL (0x49)
> +#define MT6360_PMU_CHG_STAT (0x4A)
> +#define MT6360_PMU_RESV1 (0x4B)
> +#define MT6360_PMU_TYPEC_OTP_TH_SEL_CODEH (0x4E)
> +#define MT6360_PMU_TYPEC_OTP_TH_SEL_CODEL (0x4F)
> +#define MT6360_PMU_TYPEC_OTP_HYST_TH (0x50)
> +#define MT6360_PMU_TYPEC_OTP_CTRL (0x51)
> +#define MT6360_PMU_ADC_BAT_DATA_H (0x52)
> +#define MT6360_PMU_ADC_BAT_DATA_L (0x53)
> +#define MT6360_PMU_IMID_BACKBST_ON (0x54)
> +#define MT6360_PMU_IMID_BACKBST_OFF (0x55)
> +#define MT6360_PMU_ADC_CONFIG (0x56)
> +#define MT6360_PMU_ADC_EN2 (0x57)
> +#define MT6360_PMU_ADC_IDLE_T (0x58)
> +#define MT6360_PMU_ADC_RPT_1 (0x5A)
> +#define MT6360_PMU_ADC_RPT_2 (0x5B)
> +#define MT6360_PMU_ADC_RPT_3 (0x5C)
> +#define MT6360_PMU_ADC_RPT_ORG1 (0x5D)
> +#define MT6360_PMU_ADC_RPT_ORG2 (0x5E)
> +#define MT6360_PMU_BAT_OVP_TH_SEL_CODEH (0x5F)
> +#define MT6360_PMU_BAT_OVP_TH_SEL_CODEL (0x60)
> +#define MT6360_PMU_CHG_CTRL19 (0x61)
> +#define MT6360_PMU_VDDASUPPLY (0x62)
> +#define MT6360_PMU_BC12_MANUAL (0x63)
> +#define MT6360_PMU_CHGDET_FUNC (0x64)
> +#define MT6360_PMU_FOD_CTRL (0x65)
> +#define MT6360_PMU_CHG_CTRL20 (0x66)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL26 (0x67)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL27 (0x68)
> +#define MT6360_PMU_RESV2 (0x69)
> +#define MT6360_PMU_USBID_CTRL1 (0x6D)
> +#define MT6360_PMU_USBID_CTRL2 (0x6E)
> +#define MT6360_PMU_USBID_CTRL3 (0x6F)
> +#define MT6360_PMU_FLED_CFG (0x70)
> +#define MT6360_PMU_RESV3 (0x71)
> +#define MT6360_PMU_FLED1_CTRL (0x72)
> +#define MT6360_PMU_FLED_STRB_CTRL (0x73)
> +#define MT6360_PMU_FLED1_STRB_CTRL2 (0x74)
> +#define MT6360_PMU_FLED1_TOR_CTRL (0x75)
> +#define MT6360_PMU_FLED2_CTRL (0x76)
> +#define MT6360_PMU_RESV4 (0x77)
> +#define MT6360_PMU_FLED2_STRB_CTRL2 (0x78)
> +#define MT6360_PMU_FLED2_TOR_CTRL (0x79)
> +#define MT6360_PMU_FLED_VMIDTRK_CTRL1 (0x7A)
> +#define MT6360_PMU_FLED_VMID_RTM (0x7B)
> +#define MT6360_PMU_FLED_VMIDTRK_CTRL2 (0x7C)
> +#define MT6360_PMU_FLED_PWSEL (0x7D)
> +#define MT6360_PMU_FLED_EN (0x7E)
> +#define MT6360_PMU_FLED_Hidden1 (0x7F)
> +#define MT6360_PMU_RGB_EN (0x80)
> +#define MT6360_PMU_RGB1_ISNK (0x81)
> +#define MT6360_PMU_RGB2_ISNK (0x82)
> +#define MT6360_PMU_RGB3_ISNK (0x83)
> +#define MT6360_PMU_RGB_ML_ISNK (0x84)
> +#define MT6360_PMU_RGB1_DIM (0x85)
> +#define MT6360_PMU_RGB2_DIM (0x86)
> +#define MT6360_PMU_RGB3_DIM (0x87)
> +#define MT6360_PMU_RESV5 (0x88)
> +#define MT6360_PMU_RGB12_Freq (0x89)
> +#define MT6360_PMU_RGB34_Freq (0x8A)
> +#define MT6360_PMU_RGB1_Tr (0x8B)
> +#define MT6360_PMU_RGB1_Tf (0x8C)
> +#define MT6360_PMU_RGB1_TON_TOFF (0x8D)
> +#define MT6360_PMU_RGB2_Tr (0x8E)
> +#define MT6360_PMU_RGB2_Tf (0x8F)
> +#define MT6360_PMU_RGB2_TON_TOFF (0x90)
> +#define MT6360_PMU_RGB3_Tr (0x91)
> +#define MT6360_PMU_RGB3_Tf (0x92)
> +#define MT6360_PMU_RGB3_TON_TOFF (0x93)
> +#define MT6360_PMU_RGB_Hidden_CTRL1 (0x94)
> +#define MT6360_PMU_RGB_Hidden_CTRL2 (0x95)
> +#define MT6360_PMU_RESV6 (0x97)
> +#define MT6360_PMU_SPARE1 (0x9A)
> +#define MT6360_PMU_SPARE2 (0xA0)
> +#define MT6360_PMU_SPARE3 (0xB0)
> +#define MT6360_PMU_SPARE4 (0xC0)
> +#define MT6360_PMU_CHG_IRQ1 (0xD0)
> +#define MT6360_PMU_CHG_IRQ2 (0xD1)
> +#define MT6360_PMU_CHG_IRQ3 (0xD2)
> +#define MT6360_PMU_CHG_IRQ4 (0xD3)
> +#define MT6360_PMU_CHG_IRQ5 (0xD4)
> +#define MT6360_PMU_CHG_IRQ6 (0xD5)
> +#define MT6360_PMU_QC_IRQ (0xD6)
> +#define MT6360_PMU_FOD_IRQ (0xD7)
> +#define MT6360_PMU_BASE_IRQ (0xD8)
> +#define MT6360_PMU_FLED_IRQ1 (0xD9)
> +#define MT6360_PMU_FLED_IRQ2 (0xDA)
> +#define MT6360_PMU_RGB_IRQ (0xDB)
> +#define MT6360_PMU_BUCK1_IRQ (0xDC)
> +#define MT6360_PMU_BUCK2_IRQ (0xDD)
> +#define MT6360_PMU_LDO_IRQ1 (0xDE)
> +#define MT6360_PMU_LDO_IRQ2 (0xDF)
> +#define MT6360_PMU_CHG_STAT1 (0xE0)
> +#define MT6360_PMU_CHG_STAT2 (0xE1)
> +#define MT6360_PMU_CHG_STAT3 (0xE2)
> +#define MT6360_PMU_CHG_STAT4 (0xE3)
> +#define MT6360_PMU_CHG_STAT5 (0xE4)
> +#define MT6360_PMU_CHG_STAT6 (0xE5)
> +#define MT6360_PMU_QC_STAT (0xE6)
> +#define MT6360_PMU_FOD_STAT (0xE7)
> +#define MT6360_PMU_BASE_STAT (0xE8)
> +#define MT6360_PMU_FLED_STAT1 (0xE9)
> +#define MT6360_PMU_FLED_STAT2 (0xEA)
> +#define MT6360_PMU_RGB_STAT (0xEB)
> +#define MT6360_PMU_BUCK1_STAT (0xEC)
> +#define MT6360_PMU_BUCK2_STAT (0xED)
> +#define MT6360_PMU_LDO_STAT1 (0xEE)
> +#define MT6360_PMU_LDO_STAT2 (0xEF)
> +#define MT6360_PMU_CHG_MASK1 (0xF0)
> +#define MT6360_PMU_CHG_MASK2 (0xF1)
> +#define MT6360_PMU_CHG_MASK3 (0xF2)
> +#define MT6360_PMU_CHG_MASK4 (0xF3)
> +#define MT6360_PMU_CHG_MASK5 (0xF4)
> +#define MT6360_PMU_CHG_MASK6 (0xF5)
> +#define MT6360_PMU_QC_MASK (0xF6)
> +#define MT6360_PMU_FOD_MASK (0xF7)
> +#define MT6360_PMU_BASE_MASK (0xF8)
> +#define MT6360_PMU_FLED_MASK1 (0xF9)
> +#define MT6360_PMU_FLED_MASK2 (0xFA)
> +#define MT6360_PMU_FAULTB_MASK (0xFB)
> +#define MT6360_PMU_BUCK1_MASK (0xFC)
> +#define MT6360_PMU_BUCK2_MASK (0xFD)
> +#define MT6360_PMU_LDO_MASK1 (0xFE)
> +#define MT6360_PMU_LDO_MASK2 (0xFF)
> +#define MT6360_PMU_MAXREG (MT6360_PMU_LDO_MASK2)
> +
> +/* MT6360_PMU_IRQ_SET */
> +#define MT6360_PMU_IRQ_REGNUM (MT6360_PMU_LDO_IRQ2 - MT6360_PMU_CHG_IRQ1 + 1)
> +#define MT6360_IRQ_RETRIG BIT(2)
> +
> +#define CHIP_VEN_MASK (0xF0)
> +#define CHIP_VEN_MT6360 (0x50)
> +#define CHIP_REV_MASK (0x0F)
> +
> +#endif /* __MT6360_H__ */
> --
> 2.7.4
>
Hi Lee,
i run checkpatch have 3 warning, but i think 1/2 can be ignored, i can
prepare devicetree binding document first.
does anything i can do when waiting review?
1. WARNING: Non-standard signature: Acked-for-mfd-by:
#10:
Acked-for-mfd-by: Lee Jones <lee.jones@linaro.org>
2. WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#92:
new file mode 100644.
3. WARNING: DT compatible string "mediatek,mt6360_pmu" appears
un-documented -- check ./Documentation/devicetree/bindings/
#505: FILE: drivers/mfd/mt6360-core.c:409:
+ { .compatible = "mediatek,mt6360_pmu", },
_______________________________________________
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