* Re: arm64/acpi: NULL dereference reports from UBSAN at boot
From: Ard Biesheuvel @ 2020-06-01 22:28 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Mark Rutland, Lorenzo Pieralisi, Peter Collingbourne,
Rafael J. Wysocki, LKML, Alexander Potapenko, Dmitry Vyukov,
Hanjun Guo, Will Deacon, Linux ARM
In-Reply-To: <CAKwvOdnz-=GD9-taLQt6LDhs2Q-xgWmywCUA6skB0NJhubB+nw@mail.gmail.com>
On Tue, 2 Jun 2020 at 00:19, Nick Desaulniers <ndesaulniers@google.com> wrote:
>
> On Mon, Jun 1, 2020 at 2:57 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Mon, 1 Jun 2020 at 23:52, Nick Desaulniers <ndesaulniers@google.com> wrote:
> > >
> > > Anyways, it looks like the address of member from NULL subexpression
> > > looks problematic. I wonder if offsetof can be used here?
> > >
> > > #define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (offsetof(d, f), (void *) 0)
> > >
> > > Seems to work in my basic test case. Untested in the kernel.
> > >
> > > IIUC, ACPI_OFFSET is trying to calculate the difference between the
> > > offset of a member of a struct and 0? Isn't that the tautology `x - 0
> > > == x`?
> >
> > No. ACPI_OFFSET() is just a poor person's version of offsetof().
> >
> > (Note that it calculates the difference between &(((d *) 0)->f) and
> > (void *)0x0, so the 0x0 term is there on both sides)
>
> Got it. So we're trying to avoid including stddef.h? Can
> __builtin_offsetof be used here?
> #define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (__builtin_offsetof(d, f), (void *) 0)
Drop the 0x0:
#define ACPI_OFFSET __builtin_offsetof
should be all we need.
> The oldest version of GCC in godbolt.org (4.1) supports this builtin.
Yeah I think that should be fine.
Alternatively, using any arbitrary address other than 0x0 on both
sides should work as well to get rid of the undefined behavior
(assuming the use of NULL pointers is what is causing it), but I don't
see why we need to invent our own helper here.
BTW some other macros looks dodgy as well.
761f0b82393353507930b6721ae4311a9df2ca36 provides a nice set of
candidates to go and clean up.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] arm64 updates for 5.8
From: pr-tracker-bot @ 2020-06-01 22:40 UTC (permalink / raw)
To: Will Deacon
Cc: peterz, catalin.marinas, linux-kernel, bp, maz, torvalds,
linux-arm-kernel
In-Reply-To: <20200601171309.GA6390@willie-the-truck>
The pull request you sent on Mon, 1 Jun 2020 18:13:10 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-upstream
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/533b220f7be4e461a5222a223d169b42856741ef
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] clk: imx: vf610: add CAAM clock
From: Andrey Smirnov @ 2020-06-01 23:06 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Horia Geantă, Andrey Smirnov, Shawn Guo, linux-kernel,
linux-imx, Fabio Estevam, Chris Healy
According to Vybrid Security RM, CCM_CCGR11[CG176] can be used to gate
CAAM ipg clock.
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Chris Healy <cphealy@gmail.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-imx@nxp.com
---
drivers/clk/imx/clk-vf610.c | 1 +
include/dt-bindings/clock/vf610-clock.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-vf610.c b/drivers/clk/imx/clk-vf610.c
index cd04e7dc1878..5129ef8e1d6e 100644
--- a/drivers/clk/imx/clk-vf610.c
+++ b/drivers/clk/imx/clk-vf610.c
@@ -438,6 +438,7 @@ static void __init vf610_clocks_init(struct device_node *ccm_node)
clk[VF610_CLK_SNVS] = imx_clk_gate2("snvs-rtc", "ipg_bus", CCM_CCGR6, CCM_CCGRx_CGn(7));
clk[VF610_CLK_DAP] = imx_clk_gate("dap", "platform_bus", CCM_CCSR, 24);
clk[VF610_CLK_OCOTP] = imx_clk_gate("ocotp", "ipg_bus", CCM_CCGR6, CCM_CCGRx_CGn(5));
+ clk[VF610_CLK_CAAM] = imx_clk_gate2("caam", "ipg_bus", CCM_CCGR11, CCM_CCGRx_CGn(0));
imx_check_clocks(clk, ARRAY_SIZE(clk));
diff --git a/include/dt-bindings/clock/vf610-clock.h b/include/dt-bindings/clock/vf610-clock.h
index 95394f35a74a..0f2d60e884dc 100644
--- a/include/dt-bindings/clock/vf610-clock.h
+++ b/include/dt-bindings/clock/vf610-clock.h
@@ -195,6 +195,7 @@
#define VF610_CLK_WKPU 186
#define VF610_CLK_TCON0 187
#define VF610_CLK_TCON1 188
-#define VF610_CLK_END 189
+#define VF610_CLK_CAAM 189
+#define VF610_CLK_END 190
#endif /* __DT_BINDINGS_CLOCK_VF610_H */
--
2.21.3
_______________________________________________
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 04/20] arm64: dts: arm: vexpress: Move fixed devices out of bus node
From: Rob Herring @ 2020-06-01 23:12 UTC (permalink / raw)
To: André Przywara
Cc: Mark Rutland, devicetree, Lorenzo Pieralisi, Liviu Dudau,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Sudeep Holla, Guenter Roeck
In-Reply-To: <22687572-becf-7b4e-9759-cfba44677a1d@arm.com>
On Mon, Jun 1, 2020 at 4:15 AM André Przywara <andre.przywara@arm.com> wrote:
>
> On 28/05/2020 14:30, André Przywara wrote:
>
> Hi,
>
> > On 28/05/2020 03:48, Guenter Roeck wrote:
> >
> > Hi Guenter,
> >
> >> On Wed, May 13, 2020 at 11:30:00AM +0100, Andre Przywara wrote:
> >>> The devicetree compiler complains when DT nodes without a reg property
> >>> live inside a (simple) bus node:
> >>> Warning (simple_bus_reg): Node /bus@8000000/motherboard-bus/refclk32khz
> >>> missing or empty reg/ranges property
> >>>
> >>> Move the fixed clocks, the fixed regulator, the leds and the config bus
> >>> subtree to the root node, since they do not depend on any busses.
> >>>
> >>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> >>
> >> This patch results in tracebacks when booting the vexpress-a15 machine
> >> with vexpress-v2p-ca15-tc1 devicetree file in qemu. Reverting it as well
> >> as the subsequent patches affecting the same file (to avoid revert
> >> conflicts) fixes the problem.
> >
> > Many thanks for the heads up! I was able to reproduce it here. On the
> > first glance it looks like the UART is probed before the clocks now,
> > because the traversal of the changed DT leads to a different probe
> > order. I will look into how to fix this.
>
> Turned out to be a bit more complicated:
> The arm,vexpress,config-bus driver walks up the device tree to find a
> arm,vexpress,site property [1]. With this patch the first parent node
> with that property it finds is now the root node, with the wrong site ID
> (0xf instead of 0x0). So it queries the wrong clocks (those IDs are
> actually reserved there), and QEMU reports back "0", consequently [2].
> Finding a clock frequency in the range of [0, 0] won't get very far.
>
> Possible solutions are:
> 1) Just keep the mcc and its children at where it is in mainline right
> now, so *partly* reverting this patch. This has the problem of still
> producing a dtc warning, so kind of defeats the purpose of this patch.
>
> 2) Add a "arm,vexpress,site = <0>;" line to the "mcc" node itself.
> Works, but looks somewhat dodgy, as the mcc node should really be a
> child of the motherboard node, and we should not hack around this.
>
> 3) Dig deeper and fix the DT in a way that makes dtc happy. Might
> involve (dummy?) ranges or reg properties. My gut feeling is that
> arm,vexpress-sysreg,func should really have been "reg" in the first
> place, but that's too late to change now, anyway.
>
> I will post 2) as a fix if 3) turns out to be not feasible.
I would just do 1).
To some extent, the warnings are for avoiding poor design on new
bindings. We need a way to distinguish between existing boards and new
ones. Maybe dts needs to learn some warning disable annotations or we
need per target warning settings (DTC_FLAGS_foo.dtb ?). Or maybe this
check is just too strict.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ACPICA: fix UBSAN warning using __builtin_offsetof
From: Nick Desaulniers @ 2020-06-01 23:18 UTC (permalink / raw)
To: Robert Moore, Erik Kaneda, Rafael J. Wysocki, Len Brown
Cc: mark.rutland, lorenzo.pieralisi, will, rjw, ndesaulniers,
linux-kernel, stable, linux-acpi, glider, dvyukov, guohanjun, pcc,
Ard Biesheuvel, linux-arm-kernel, devel
In-Reply-To: <CAMj1kXErFuvOoG=DB6sz5HBvDuHDiKwWD8uOyLuxaX-u8-+dbA@mail.gmail.com>
Will reported UBSAN warnings:
UBSAN: null-ptr-deref in drivers/acpi/acpica/tbfadt.c:459:37
UBSAN: null-ptr-deref in arch/arm64/kernel/smp.c:596:6
Looks like the emulated offsetof macro ACPI_OFFSET is causing these. We
can avoid this by using the compiler builtin, __builtin_offsetof.
The non-kernel runtime of UBSAN would print:
runtime error: member access within null pointer of type
for this macro.
Link: https://lore.kernel.org/lkml/20200521100952.GA5360@willie-the-truck/
Cc: stable@vger.kernel.org
Reported-by: Will Deacon <will@kernel.org>
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
include/acpi/actypes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
index 4defed58ea33..04359c70b198 100644
--- a/include/acpi/actypes.h
+++ b/include/acpi/actypes.h
@@ -508,7 +508,7 @@ typedef u64 acpi_integer;
#define ACPI_TO_POINTER(i) ACPI_CAST_PTR (void, (acpi_size) (i))
#define ACPI_TO_INTEGER(p) ACPI_PTR_DIFF (p, (void *) 0)
-#define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (&(((d *) 0)->f), (void *) 0)
+#define ACPI_OFFSET(d, f) __builtin_offsetof(d, f)
#define ACPI_PHYSADDR_TO_PTR(i) ACPI_TO_POINTER(i)
#define ACPI_PTR_TO_PHYSADDR(i) ACPI_TO_INTEGER(i)
--
2.27.0.rc2.251.g90737beb825-goog
_______________________________________________
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] ACPICA: fix UBSAN warning using __builtin_offsetof
From: Peter Collingbourne @ 2020-06-01 23:37 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Mark Rutland, Erik Kaneda, Rafael J. Wysocki, rjw, Robert Moore,
stable, Linux Kernel Mailing List, linux-acpi, lorenzo.pieralisi,
Alexander Potapenko, Linux ARM, guohanjun, devel, Will Deacon,
Ard Biesheuvel, Dmitry Vyukov, Len Brown
In-Reply-To: <20200601231805.207441-1-ndesaulniers@google.com>
On Mon, Jun 1, 2020 at 4:18 PM Nick Desaulniers <ndesaulniers@google.com> wrote:
>
> Will reported UBSAN warnings:
> UBSAN: null-ptr-deref in drivers/acpi/acpica/tbfadt.c:459:37
> UBSAN: null-ptr-deref in arch/arm64/kernel/smp.c:596:6
>
> Looks like the emulated offsetof macro ACPI_OFFSET is causing these. We
> can avoid this by using the compiler builtin, __builtin_offsetof.
Would it be better to s/ACPI_OFFSET/offsetof/g the existing users of
this macro and remove it? It looks like offsetof is already being used
pervasively in the kernel, and its definition comes from
<linux/stddef.h>.
Peter
Peter
> The non-kernel runtime of UBSAN would print:
> runtime error: member access within null pointer of type
> for this macro.
>
> Link: https://lore.kernel.org/lkml/20200521100952.GA5360@willie-the-truck/
> Cc: stable@vger.kernel.org
> Reported-by: Will Deacon <will@kernel.org>
> Suggested-by: Ard Biesheuvel <ardb@kernel.org>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> ---
> include/acpi/actypes.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
> index 4defed58ea33..04359c70b198 100644
> --- a/include/acpi/actypes.h
> +++ b/include/acpi/actypes.h
> @@ -508,7 +508,7 @@ typedef u64 acpi_integer;
>
> #define ACPI_TO_POINTER(i) ACPI_CAST_PTR (void, (acpi_size) (i))
> #define ACPI_TO_INTEGER(p) ACPI_PTR_DIFF (p, (void *) 0)
> -#define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (&(((d *) 0)->f), (void *) 0)
> +#define ACPI_OFFSET(d, f) __builtin_offsetof(d, f)
> #define ACPI_PHYSADDR_TO_PTR(i) ACPI_TO_POINTER(i)
> #define ACPI_PTR_TO_PHYSADDR(i) ACPI_TO_INTEGER(i)
>
> --
> 2.27.0.rc2.251.g90737beb825-goog
>
_______________________________________________
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] ACPICA: fix UBSAN warning using __builtin_offsetof
From: Nick Desaulniers @ 2020-06-01 23:48 UTC (permalink / raw)
To: Peter Collingbourne
Cc: Mark Rutland, Erik Kaneda, Rafael J. Wysocki, Rafael J. Wysocki,
Robert Moore, # 3.4.x, Linux Kernel Mailing List, linux-acpi,
Lorenzo Pieralisi, Alexander Potapenko, Linux ARM, Hanjun Guo,
devel, Will Deacon, Ard Biesheuvel, Dmitry Vyukov, Len Brown
In-Reply-To: <CAMn1gO7MrbgpEzaAYZ3vNnbWPdSsHhMkDNXq9rZajur+sqtBsw@mail.gmail.com>
On Mon, Jun 1, 2020 at 4:37 PM Peter Collingbourne <pcc@google.com> wrote:
>
> On Mon, Jun 1, 2020 at 4:18 PM Nick Desaulniers <ndesaulniers@google.com> wrote:
> >
> > Will reported UBSAN warnings:
> > UBSAN: null-ptr-deref in drivers/acpi/acpica/tbfadt.c:459:37
> > UBSAN: null-ptr-deref in arch/arm64/kernel/smp.c:596:6
> >
> > Looks like the emulated offsetof macro ACPI_OFFSET is causing these. We
> > can avoid this by using the compiler builtin, __builtin_offsetof.
>
> Would it be better to s/ACPI_OFFSET/offsetof/g the existing users of
> this macro and remove it? It looks like offsetof is already being used
> pervasively in the kernel, and its definition comes from
> <linux/stddef.h>.
I count only 9 uses in the tree, so not too bad a yak shave. Good
idea; I'll send tomorrow short of any other feedback. I still think
we want the builtin, since we don't want to include stddef.h in the
kernel, I think.
--
Thanks,
~Nick Desaulniers
_______________________________________________
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] ACPICA: fix UBSAN warning using __builtin_offsetof
From: Kaneda, Erik @ 2020-06-02 0:02 UTC (permalink / raw)
To: Nick Desaulniers, Moore, Robert, Wysocki, Rafael J, Len Brown
Cc: mark.rutland@arm.com, lorenzo.pieralisi@arm.com, will@kernel.org,
rjw@rjwysocki.net, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, linux-acpi@vger.kernel.org,
glider@google.com, dvyukov@google.com, guohanjun@huawei.com,
pcc@google.com, Ard Biesheuvel,
linux-arm-kernel@lists.infradead.org, devel@acpica.org
In-Reply-To: <20200601231805.207441-1-ndesaulniers@google.com>
> -----Original Message-----
> From: Nick Desaulniers <ndesaulniers@google.com>
> Sent: Monday, June 1, 2020 4:18 PM
> To: Moore, Robert <robert.moore@intel.com>; Kaneda, Erik
> <erik.kaneda@intel.com>; Wysocki, Rafael J <rafael.j.wysocki@intel.com>;
> Len Brown <lenb@kernel.org>
> Cc: Ard Biesheuvel <ardb@kernel.org>; dvyukov@google.com;
> glider@google.com; guohanjun@huawei.com; linux-arm-
> kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> lorenzo.pieralisi@arm.com; mark.rutland@arm.com;
> ndesaulniers@google.com; pcc@google.com; rjw@rjwysocki.net;
> will@kernel.org; stable@vger.kernel.org; linux-acpi@vger.kernel.org;
> devel@acpica.org
> Subject: [PATCH] ACPICA: fix UBSAN warning using __builtin_offsetof
>
Hi,
> Will reported UBSAN warnings:
> UBSAN: null-ptr-deref in drivers/acpi/acpica/tbfadt.c:459:37
> UBSAN: null-ptr-deref in arch/arm64/kernel/smp.c:596:6
>
> Looks like the emulated offsetof macro ACPI_OFFSET is causing these. We
> can avoid this by using the compiler builtin, __builtin_offsetof.
I'll take a look at this tomorrow
>
> The non-kernel runtime of UBSAN would print:
> runtime error: member access within null pointer of type for this macro.
actypes.h is owned by ACPICA so we typically do not allow compiler-specific
extensions because the code is intended to be compiled using the C99 standard
without compiler extensions. We could allow this sort of thing in a Linux-specific
header file like include/acpi/platform/aclinux.h but I'll take a look at the error as well..
Erik
>
> Link: https://lore.kernel.org/lkml/20200521100952.GA5360@willie-the-truck/
> Cc: stable@vger.kernel.org
> Reported-by: Will Deacon <will@kernel.org>
> Suggested-by: Ard Biesheuvel <ardb@kernel.org>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> ---
> include/acpi/actypes.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index
> 4defed58ea33..04359c70b198 100644
> --- a/include/acpi/actypes.h
> +++ b/include/acpi/actypes.h
> @@ -508,7 +508,7 @@ typedef u64 acpi_integer;
>
> #define ACPI_TO_POINTER(i) ACPI_CAST_PTR (void, (acpi_size) (i))
> #define ACPI_TO_INTEGER(p) ACPI_PTR_DIFF (p, (void *) 0)
> -#define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (&(((d *) 0)->f), (void *)
> 0)
> +#define ACPI_OFFSET(d, f) __builtin_offsetof(d, f)
> #define ACPI_PHYSADDR_TO_PTR(i) ACPI_TO_POINTER(i)
> #define ACPI_PTR_TO_PHYSADDR(i) ACPI_TO_INTEGER(i)
>
> --
> 2.27.0.rc2.251.g90737beb825-goog
_______________________________________________
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 v5 3/6] PM / devfreq: exynos-bus: Add registration of interconnect child device
From: Chanwoo Choi @ 2020-06-02 0:50 UTC (permalink / raw)
To: Sylwester Nawrocki, Chanwoo Choi
Cc: devicetree, linux-samsung-soc, Bartlomiej Zolnierkiewicz,
Seung-Woo Kim, Artur Świgoń, Krzysztof Kozlowski,
linux-kernel, inki.dae, Rob Herring, MyungJoo Ham, dri-devel,
Georgi Djakov, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <8a977716-9e0e-5daf-fb22-32d943da42e5@samsung.com>
Hi Sylwester,
On 6/1/20 7:04 PM, Sylwester Nawrocki wrote:
> Cc: Rob, devicetree ML
>
> On 31.05.2020 01:57, Chanwoo Choi wrote:
>> On Sat, May 30, 2020 at 1:33 AM Sylwester Nawrocki
>> <s.nawrocki@samsung.com> wrote:
>>>
>>> This patch adds registration of a child platform device for the exynos
>>> interconnect driver. It is assumed that the interconnect provider will
>>> only be needed when #interconnect-cells property is present in the bus
>>> DT node, hence the child device will be created only when such a property
>>> is present.
>>>
>>> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>>>
>>> Changes for v5:
>>> - new patch.
>>> ---
>>> drivers/devfreq/exynos-bus.c | 17 +++++++++++++++++
>>> 1 file changed, 17 insertions(+)
>>>
>>> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
>>> index 8fa8eb5..856e37d 100644
>>> --- a/drivers/devfreq/exynos-bus.c
>>> +++ b/drivers/devfreq/exynos-bus.c
>>> @@ -24,6 +24,7 @@
>>>
>>> struct exynos_bus {
>>> struct device *dev;
>>> + struct platform_device *icc_pdev;
>>>
>>> struct devfreq *devfreq;
>>> struct devfreq_event_dev **edev;
>>> @@ -156,6 +157,8 @@ static void exynos_bus_exit(struct device *dev)
>>> if (ret < 0)
>>> dev_warn(dev, "failed to disable the devfreq-event devices\n");
>>>
>>> + platform_device_unregister(bus->icc_pdev);
>>> +
>>> dev_pm_opp_of_remove_table(dev);
>>> clk_disable_unprepare(bus->clk);
>>> if (bus->opp_table) {
>>> @@ -168,6 +171,8 @@ static void exynos_bus_passive_exit(struct device *dev)
>>> {
>>> struct exynos_bus *bus = dev_get_drvdata(dev);
>>>
>>> + platform_device_unregister(bus->icc_pdev);
>>> +
>>> dev_pm_opp_of_remove_table(dev);
>>> clk_disable_unprepare(bus->clk);
>>> }
>>> @@ -431,6 +436,18 @@ static int exynos_bus_probe(struct platform_device *pdev)
>>> if (ret < 0)
>>> goto err;
>>>
>>> + /* Create child platform device for the interconnect provider */
>>> + if (of_get_property(dev->of_node, "#interconnect-cells", NULL)) {
>>> + bus->icc_pdev = platform_device_register_data(
>>> + dev, "exynos-generic-icc",
>>> + PLATFORM_DEVID_AUTO, NULL, 0);
>>> +
>>> + if (IS_ERR(bus->icc_pdev)) {
>>> + ret = PTR_ERR(bus->icc_pdev);
>>> + goto err;
>>> + }
>>> + }
>>> +
>>> max_state = bus->devfreq->profile->max_state;
>>> min_freq = (bus->devfreq->profile->freq_table[0] / 1000);
>>> max_freq = (bus->devfreq->profile->freq_table[max_state - 1] / 1000);
>>> --
>>> 2.7.4
>>>
>>
>> It looks like very similar like the registering the interconnect
>> device of imx-bus.c
>> and I already reviewed and agreed this approach.
>>
>> Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
>>
>> nitpick: IMHO, I think that 'exynos-icc' is proper and simple without
>> 'generic' word.
>> If we need to add new icc compatible int the future, we will add
>> 'exynosXXXX-icc' new compatible.
>> But, I'm not forcing it. just opinion. Anyway, I agree this approach.
>
> Thanks for review. I will change the name to exynos-icc in next version,
> as I commented at other patch, it is not part of any DT binding,
> it is just for device/driver matching between devfreq and interconnect.
Thanks. I have not any objection to use either 'exynos-generic-icc'
or 'exynos-icc'. It is just my opinion. And on next version,
please add linux-pm mailing list to Cc.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
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 10/15] PCI: altera: Use pci_host_probe() to register host
From: Tan, Ley Foon @ 2020-06-02 1:02 UTC (permalink / raw)
To: Rob Herring, Lorenzo Pieralisi
Cc: Bjorn Helgaas, linux-pci@vger.kernel.org,
rfi@lists.rocketboards.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20200522234832.954484-11-robh@kernel.org>
> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: Saturday, May 23, 2020 7:48 AM
> To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>; linux-pci@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; Tan, Ley Foon
> <ley.foon.tan@intel.com>; rfi@lists.rocketboards.org
> Subject: [PATCH 10/15] PCI: altera: Use pci_host_probe() to register host
>
> The altera host driver does the same host registration and bus scanning calls
> as pci_host_probe, so let's use it instead.
>
> The only difference is pci_assign_unassigned_bus_resources() was called
> instead of pci_bus_size_bridges() and pci_bus_assign_resources(). This
> should be the same.
>
> Cc: Ley Foon Tan <ley.foon.tan@intel.com>
> Cc: rfi@lists.rocketboards.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> drivers/pci/controller/pcie-altera.c | 17 +----------------
> 1 file changed, 1 insertion(+), 16 deletions(-)
>
Reviewed-by: Ley Foon Tan <ley.foon.tan@intel.com>
Regards
Ley Foon
_______________________________________________
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/4] firmware: imx: add resource management api
From: Aisheng Dong @ 2020-06-02 2:41 UTC (permalink / raw)
To: Peng Fan, shawnguo@kernel.org, s.hauer@pengutronix.de
Cc: festevam@gmail.com, Joakim Zhang, linux@rempel-privat.de,
linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de,
Leonard Crestez, Daniel Baluta, linux-kernel@vger.kernel.org,
dl-linux-imx
In-Reply-To: <DB6PR0402MB276084207EDE5111E624938D888A0@DB6PR0402MB2760.eurprd04.prod.outlook.com>
> From: Peng Fan <peng.fan@nxp.com>
> Sent: Monday, June 1, 2020 8:40 PM
> >
> > > From: Peng Fan <peng.fan@nxp.com>
> > > Sent: Friday, April 24, 2020 9:12 AM
> > > >
> > > > > From: Peng Fan <peng.fan@nxp.com>
> > > > > Sent: Thursday, April 23, 2020 6:57 PM
> > > > > > > From: Peng Fan <peng.fan@nxp.com>
> > > > > > > Sent: Thursday, April 23, 2020 3:00 PM
> > > > > > >
> > > > > > > Add resource management API, when we have multiple partition
> > > > > > > running together, resources not owned to current partition
> > > > > > > should not be
> > > > used.
> > > > > > >
> > > > > > > Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com>
> > > > > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > > >
> > > > > > Right now I'm still not quite understand if we really need this.
> > > > > > As current resource is bound to power domains, if it's not
> > > > > > owned by one specific SW execution environment, power on will also
> fail.
> > > > > > Can you clarify if any exceptions?
> > > > >
> > > > > There will be lots of failures when boot Linux domu if no check.
> > > > >
> > > >
> > > > What kind of features did you mean?
> > > > Could you clarify a bit more? I'd like to understand this issue better.
> > >
> > > When supporting hypervisor with dual Linux running, 1st Linux and
> > > the 2nd Linux will have their own dedicated resources.
> > >
> > > If no resource check, that means 1st/2nd Linux will register all the
> > > resources, then both will see fail logs when register resources not
> > > owned to
> > itself.
> > >
> > > Same to partitioned m4 case.
> > >
> > > Would it be better without the failure log?
> > >
> >
> > Is it power up failure?
> > If yes, it's expected because we actually use power up to check if
> > resources are owned by this partition. It functions the same as
> > calling resource check API.
> > That's current design.
> >
> > Or it's other failures? Log?
> Sorry for long late reply.
>
> Part of my XEN DomU log, there are lots of failure log. I think better not have
> such logs by add a resource own check.
Those error logs are intended.
Resource owner check actually behaves the same as power up.
So not quite necessary to add a double check.
If we're concerning about the error log, we can change it to dev_dbg().
BTW, as resource management will be needed by seco drivers later,
So I will continue to review the patch.
Regards
Aisheng
>
> [ 2.034774] imx6q-pcie 5f000000.pcie: IO 0x6ff80000..0x6ff8ffff ->
> 0x00000000
> [ 2.034801] imx6q-pcie 5f000000.pcie: MEM 0x60000000..0x6fefffff ->
> 0x60000000
> [ 2.035072] sdhc1: failed to power up resource 249 ret -13
> [ 2.035619] sdhc2: failed to power up resource 250 ret -13
> [ 2.036126] enet0: failed to power up resource 251 ret -13
> [ 2.036584] enet1: failed to power up resource 252 ret -13
> [ 2.037040] mlb0: failed to power up resource 253 ret -13
> [ 2.037495] nand: failed to power up resource 265 ret -13
> [ 2.037951] nand: failed to power up resource 265 ret -13
> [ 2.038416] pwm0: failed to power up resource 191 ret -13
> [ 2.038868] pwm1: failed to power up resource 192 ret -13
> [ 2.039320] pwm2: failed to power up resource 193 ret -13
> [ 2.039786] pwm3: failed to power up resource 194 ret -13
> [ 2.040239] pwm4: failed to power up resource 195 ret -13
> [ 2.040692] pwm5: failed to power up resource 196 ret -13
> [ 2.041142] pwm6: failed to power up resource 197 ret -13
> [ 2.041596] pwm7: failed to power up resource 198 ret -13
> [ 2.042073] amix: failed to power up resource 458 ret -13
> [ 2.042558] lpspi0: failed to power up resource 53 ret -13
> [ 2.043033] lpspi1: failed to power up resource 54 ret -13
> [ 2.043501] lpspi2: failed to power up resource 55 ret -13
> [ 2.043992] lpspi3: failed to power up resource 56 ret -13
> [ 2.044460] lpuart0: failed to power up resource 57 ret -13
> [ 2.044935] lpuart2: failed to power up resource 59 ret -13
> [ 2.045409] lpuart3: failed to power up resource 60 ret -13
> [ 2.055014] sim0: failed to power up resource 62 ret -13
> [ 2.055510] adc0: failed to power up resource 101 ret -13
> [ 2.056467] lpi2c0: failed to power up resource 96 ret -13
> [ 2.056946] lpi2c1: failed to power up resource 97 ret -13
> [ 2.057424] lpi2c2: failed to power up resource 98 ret -13
> [ 2.057898] lpi2c3: failed to power up resource 99 ret -13
> [ 2.058371] can0: failed to power up resource 105 ret -13
> [ 2.059289] can1: failed to power up resource 106 ret -13
> [ 2.059801] can2: failed to power up resource 107 ret -13
> [ 2.060281] nand: failed to power up resource 265 ret -13
> [ 2.062764] dpu-core 56180000.dpu: driver probed
>
> Thanks,
> Peng.
>
> >
> > Regards
> > Aisheng
> >
> > > Thanks,
> > > Peng.
> > >
> > >
> > > >
> > > > Regards
> > > > Aisheng
> > > >
> > > > > Thanks,
> > > > > Peng.
> > > > >
> > > > > >
> > > > > > Regards
> > > > > > Aisheng
> > > > > >
> > > > > > > ---
> > > > > > > drivers/firmware/imx/Makefile | 2 +-
> > > > > > > drivers/firmware/imx/rm.c | 40
> > > > +++++++++++++++++++++
> > > > > > > include/linux/firmware/imx/sci.h | 1 +
> > > > > > > include/linux/firmware/imx/svc/rm.h | 69
> > > > > > > +++++++++++++++++++++++++++++++++++++
> > > > > > > 4 files changed, 111 insertions(+), 1 deletion(-) create
> > > > > > > mode
> > > > > > > 100644 drivers/firmware/imx/rm.c create mode 100644
> > > > > > > include/linux/firmware/imx/svc/rm.h
> > > > > > >
> > > > > > > diff --git a/drivers/firmware/imx/Makefile
> > > > > > > b/drivers/firmware/imx/Makefile index
> > > > > > > 08bc9ddfbdfb..17ea3613e142
> > > > > > > 100644
> > > > > > > --- a/drivers/firmware/imx/Makefile
> > > > > > > +++ b/drivers/firmware/imx/Makefile
> > > > > > > @@ -1,4 +1,4 @@
> > > > > > > # SPDX-License-Identifier: GPL-2.0
> > > > > > > obj-$(CONFIG_IMX_DSP) += imx-dsp.o
> > > > > > > -obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o
> > > > > > > +obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o
> > rm.o
> > > > > > > obj-$(CONFIG_IMX_SCU_PD) += scu-pd.o
> > > > > > > diff --git a/drivers/firmware/imx/rm.c
> > > > > > > b/drivers/firmware/imx/rm.c new file mode 100644 index
> > > > > > > 000000000000..7b0334de5486
> > > > > > > --- /dev/null
> > > > > > > +++ b/drivers/firmware/imx/rm.c
> > > > > > > @@ -0,0 +1,40 @@
> > > > > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > > > > +/*
> > > > > > > + * Copyright 2020 NXP
> > > > > > > + *
> > > > > > > + * File containing client-side RPC functions for the RM service.
> > > > > > > +These
> > > > > > > + * function are ported to clients that communicate to the SC.
> > > > > > > + */
> > > > > > > +
> > > > > > > +#include <linux/firmware/imx/svc/rm.h>
> > > > > > > +
> > > > > > > +struct imx_sc_msg_rm_rsrc_owned {
> > > > > > > + struct imx_sc_rpc_msg hdr;
> > > > > > > + u16 resource;
> > > > > > > +} __packed __aligned(4);
> > > > > > > +
> > > > > > > +/*
> > > > > > > + * This function check @resource is owned by current
> > > > > > > +partition or not
> > > > > > > + *
> > > > > > > + * @param[in] ipc IPC handle
> > > > > > > + * @param[in] resource resource the control is
> > associated
> > > > with
> > > > > > > + *
> > > > > > > + * @return Returns 0 for success and < 0 for errors.
> > > > > > > + */
> > > > > > > +bool imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc,
> > > > > > > +u16
> > > > > > > +resource) {
> > > > > > > + struct imx_sc_msg_rm_rsrc_owned msg;
> > > > > > > + struct imx_sc_rpc_msg *hdr = &msg.hdr;
> > > > > > > +
> > > > > > > + hdr->ver = IMX_SC_RPC_VERSION;
> > > > > > > + hdr->svc = IMX_SC_RPC_SVC_RM;
> > > > > > > + hdr->func = IMX_SC_RM_FUNC_IS_RESOURCE_OWNED;
> > > > > > > + hdr->size = 2;
> > > > > > > +
> > > > > > > + msg.resource = resource;
> > > > > > > +
> > > > > > > + imx_scu_call_rpc(ipc, &msg, true);
> > > > > > > +
> > > > > > > + return hdr->func;
> > > > > > > +}
> > > > > > > +EXPORT_SYMBOL(imx_sc_rm_is_resource_owned);
> > > > > > > diff --git a/include/linux/firmware/imx/sci.h
> > > > > > > b/include/linux/firmware/imx/sci.h
> > > > > > > index 17ba4e405129..b5c5a56f29be 100644
> > > > > > > --- a/include/linux/firmware/imx/sci.h
> > > > > > > +++ b/include/linux/firmware/imx/sci.h
> > > > > > > @@ -15,6 +15,7 @@
> > > > > > >
> > > > > > > #include <linux/firmware/imx/svc/misc.h> #include
> > > > > > > <linux/firmware/imx/svc/pm.h>
> > > > > > > +#include <linux/firmware/imx/svc/rm.h>
> > > > > > >
> > > > > > > int imx_scu_enable_general_irq_channel(struct device *dev);
> > > > > > > int imx_scu_irq_register_notifier(struct notifier_block
> > > > > > > *nb); diff --git a/include/linux/firmware/imx/svc/rm.h
> > > > > > > b/include/linux/firmware/imx/svc/rm.h
> > > > > > > new file mode 100644
> > > > > > > index 000000000000..fc6ea62d9d0e
> > > > > > > --- /dev/null
> > > > > > > +++ b/include/linux/firmware/imx/svc/rm.h
> > > > > > > @@ -0,0 +1,69 @@
> > > > > > > +/* SPDX-License-Identifier: GPL-2.0+ */
> > > > > > > +/*
> > > > > > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > > > > > + * Copyright 2017-2019 NXP
> > > > > > > + *
> > > > > > > + * Header file containing the public API for the System
> > > > > > > +Controller
> > > > > > > +(SC)
> > > > > > > + * Power Management (PM) function. This includes functions
> > > > > > > +for power state
> > > > > > > + * control, clock control, reset control, and wake-up event control.
> > > > > > > + *
> > > > > > > + * RM_SVC (SVC) Resource Management Service
> > > > > > > + *
> > > > > > > + * Module for the Resource Management (RM) service.
> > > > > > > + */
> > > > > > > +
> > > > > > > +#ifndef _SC_RM_API_H
> > > > > > > +#define _SC_RM_API_H
> > > > > > > +
> > > > > > > +#include <linux/firmware/imx/sci.h>
> > > > > > > +
> > > > > > > +/*
> > > > > > > + * This type is used to indicate RPC RM function calls.
> > > > > > > + */
> > > > > > > +enum imx_sc_rm_func {
> > > > > > > + IMX_SC_RM_FUNC_UNKNOWN = 0,
> > > > > > > + IMX_SC_RM_FUNC_PARTITION_ALLOC = 1,
> > > > > > > + IMX_SC_RM_FUNC_SET_CONFIDENTIAL = 31,
> > > > > > > + IMX_SC_RM_FUNC_PARTITION_FREE = 2,
> > > > > > > + IMX_SC_RM_FUNC_GET_DID = 26,
> > > > > > > + IMX_SC_RM_FUNC_PARTITION_STATIC = 3,
> > > > > > > + IMX_SC_RM_FUNC_PARTITION_LOCK = 4,
> > > > > > > + IMX_SC_RM_FUNC_GET_PARTITION = 5,
> > > > > > > + IMX_SC_RM_FUNC_SET_PARENT = 6,
> > > > > > > + IMX_SC_RM_FUNC_MOVE_ALL = 7,
> > > > > > > + IMX_SC_RM_FUNC_ASSIGN_RESOURCE = 8,
> > > > > > > + IMX_SC_RM_FUNC_SET_RESOURCE_MOVABLE = 9,
> > > > > > > + IMX_SC_RM_FUNC_SET_SUBSYS_RSRC_MOVABLE = 28,
> > > > > > > + IMX_SC_RM_FUNC_SET_MASTER_ATTRIBUTES = 10,
> > > > > > > + IMX_SC_RM_FUNC_SET_MASTER_SID = 11,
> > > > > > > + IMX_SC_RM_FUNC_SET_PERIPHERAL_PERMISSIONS = 12,
> > > > > > > + IMX_SC_RM_FUNC_IS_RESOURCE_OWNED = 13,
> > > > > > > + IMX_SC_RM_FUNC_GET_RESOURCE_OWNER = 33,
> > > > > > > + IMX_SC_RM_FUNC_IS_RESOURCE_MASTER = 14,
> > > > > > > + IMX_SC_RM_FUNC_IS_RESOURCE_PERIPHERAL = 15,
> > > > > > > + IMX_SC_RM_FUNC_GET_RESOURCE_INFO = 16,
> > > > > > > + IMX_SC_RM_FUNC_MEMREG_ALLOC = 17,
> > > > > > > + IMX_SC_RM_FUNC_MEMREG_SPLIT = 29,
> > > > > > > + IMX_SC_RM_FUNC_MEMREG_FRAG = 32,
> > > > > > > + IMX_SC_RM_FUNC_MEMREG_FREE = 18,
> > > > > > > + IMX_SC_RM_FUNC_FIND_MEMREG = 30,
> > > > > > > + IMX_SC_RM_FUNC_ASSIGN_MEMREG = 19,
> > > > > > > + IMX_SC_RM_FUNC_SET_MEMREG_PERMISSIONS = 20,
> > > > > > > + IMX_SC_RM_FUNC_IS_MEMREG_OWNED = 21,
> > > > > > > + IMX_SC_RM_FUNC_GET_MEMREG_INFO = 22,
> > > > > > > + IMX_SC_RM_FUNC_ASSIGN_PAD = 23,
> > > > > > > + IMX_SC_RM_FUNC_SET_PAD_MOVABLE = 24,
> > > > > > > + IMX_SC_RM_FUNC_IS_PAD_OWNED = 25,
> > > > > > > + IMX_SC_RM_FUNC_DUMP = 27,
> > > > > > > +};
> > > > > > > +
> > > > > > > +#if IS_ENABLED(CONFIG_IMX_SCU) bool
> > > > > > > +imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16
> > > > > > > +resource); #else static inline bool
> > > > > > > +imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16
> > resource) {
> > > > > > > + return true;
> > > > > > > +}
> > > > > > > +#endif
> > > > > > > +#endif
> > > > > > > --
> > > > > > > 2.16.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] driver core: platform: expose numa_node to users in sysfs
From: Barry Song @ 2020-06-02 3:01 UTC (permalink / raw)
To: gregkh, rafael
Cc: Barry Song, linux-kernel, linuxarm, iommu, Prime Zeng,
Robin Murphy, linux-arm-kernel
For some platform devices like iommu, particually ARM smmu, users may
care about the numa locality. for example, if threads and drivers run
near iommu, they may get much better performance on dma_unmap_sg.
For other platform devices, users may still want to know the hardware
topology.
Cc: Prime Zeng <prime.zeng@hisilicon.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
---
drivers/base/platform.c | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index b27d0f6c18c9..7794b9a38d82 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1062,13 +1062,37 @@ static ssize_t driver_override_show(struct device *dev,
}
static DEVICE_ATTR_RW(driver_override);
+static ssize_t numa_node_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%d\n", dev_to_node(dev));
+}
+static DEVICE_ATTR_RO(numa_node);
+
+static umode_t platform_dev_attrs_visible(struct kobject *kobj, struct attribute *a,
+ int n)
+{
+ struct device *dev = container_of(kobj, typeof(*dev), kobj);
+
+ if (a == &dev_attr_numa_node.attr &&
+ dev_to_node(dev) == NUMA_NO_NODE)
+ return 0;
+
+ return a->mode;
+}
static struct attribute *platform_dev_attrs[] = {
&dev_attr_modalias.attr,
+ &dev_attr_numa_node.attr,
&dev_attr_driver_override.attr,
NULL,
};
-ATTRIBUTE_GROUPS(platform_dev);
+
+static struct attribute_group platform_dev_group = {
+ .attrs = platform_dev_attrs,
+ .is_visible = platform_dev_attrs_visible,
+};
+__ATTRIBUTE_GROUPS(platform_dev);
static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
{
--
2.23.0
_______________________________________________
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 2/4] firmware: imx: add resource management api
From: Aisheng Dong @ 2020-06-02 3:07 UTC (permalink / raw)
To: Peng Fan, shawnguo@kernel.org, s.hauer@pengutronix.de
Cc: festevam@gmail.com, Joakim Zhang, linux@rempel-privat.de,
linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de,
Leonard Crestez, Daniel Baluta, linux-kernel@vger.kernel.org,
dl-linux-imx
In-Reply-To: <1587625174-32668-3-git-send-email-peng.fan@nxp.com>
> From: Peng Fan <peng.fan@nxp.com>
> Sent: Thursday, April 23, 2020 3:00 PM
>
> Add resource management API, when we have multiple partition running
> together, resources not owned to current partition should not be used.
>
> Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/firmware/imx/Makefile | 2 +-
> drivers/firmware/imx/rm.c | 40 +++++++++++++++++++++
> include/linux/firmware/imx/sci.h | 1 +
> include/linux/firmware/imx/svc/rm.h | 69
> +++++++++++++++++++++++++++++++++++++
> 4 files changed, 111 insertions(+), 1 deletion(-) create mode 100644
> drivers/firmware/imx/rm.c create mode 100644
> include/linux/firmware/imx/svc/rm.h
>
> diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
> index 08bc9ddfbdfb..17ea3613e142 100644
> --- a/drivers/firmware/imx/Makefile
> +++ b/drivers/firmware/imx/Makefile
> @@ -1,4 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-$(CONFIG_IMX_DSP) += imx-dsp.o
> -obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o
> +obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o rm.o
> obj-$(CONFIG_IMX_SCU_PD) += scu-pd.o
> diff --git a/drivers/firmware/imx/rm.c b/drivers/firmware/imx/rm.c new file
> mode 100644 index 000000000000..7b0334de5486
> --- /dev/null
> +++ b/drivers/firmware/imx/rm.c
> @@ -0,0 +1,40 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2020 NXP
> + *
> + * File containing client-side RPC functions for the RM service. These
> + * function are ported to clients that communicate to the SC.
> + */
> +
> +#include <linux/firmware/imx/svc/rm.h>
> +
> +struct imx_sc_msg_rm_rsrc_owned {
> + struct imx_sc_rpc_msg hdr;
> + u16 resource;
> +} __packed __aligned(4);
> +
> +/*
> + * This function check @resource is owned by current partition or not
> + *
> + * @param[in] ipc IPC handle
> + * @param[in] resource resource the control is associated with
> + *
> + * @return Returns 0 for success and < 0 for errors.
> + */
> +bool imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16 resource)
> +{
> + struct imx_sc_msg_rm_rsrc_owned msg;
> + struct imx_sc_rpc_msg *hdr = &msg.hdr;
> +
> + hdr->ver = IMX_SC_RPC_VERSION;
> + hdr->svc = IMX_SC_RPC_SVC_RM;
> + hdr->func = IMX_SC_RM_FUNC_IS_RESOURCE_OWNED;
> + hdr->size = 2;
> +
> + msg.resource = resource;
> +
> + imx_scu_call_rpc(ipc, &msg, true);
No need check err return?
> +
> + return hdr->func;
> +}
> +EXPORT_SYMBOL(imx_sc_rm_is_resource_owned);
> diff --git a/include/linux/firmware/imx/sci.h b/include/linux/firmware/imx/sci.h
> index 17ba4e405129..b5c5a56f29be 100644
> --- a/include/linux/firmware/imx/sci.h
> +++ b/include/linux/firmware/imx/sci.h
> @@ -15,6 +15,7 @@
>
> #include <linux/firmware/imx/svc/misc.h> #include
> <linux/firmware/imx/svc/pm.h>
> +#include <linux/firmware/imx/svc/rm.h>
>
> int imx_scu_enable_general_irq_channel(struct device *dev); int
> imx_scu_irq_register_notifier(struct notifier_block *nb); diff --git
> a/include/linux/firmware/imx/svc/rm.h b/include/linux/firmware/imx/svc/rm.h
> new file mode 100644
> index 000000000000..fc6ea62d9d0e
> --- /dev/null
> +++ b/include/linux/firmware/imx/svc/rm.h
> @@ -0,0 +1,69 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Copyright 2017-2019 NXP
Update copyright
> + *
> + * Header file containing the public API for the System Controller (SC)
> + * Power Management (PM) function. This includes functions for power
> +state
> + * control, clock control, reset control, and wake-up event control.
Fix the code comments
Otherwise, I'm fine with this patch.
Regards
Aisheng
> + *
> + * RM_SVC (SVC) Resource Management Service
> + *
> + * Module for the Resource Management (RM) service.
> + */
> +
> +#ifndef _SC_RM_API_H
> +#define _SC_RM_API_H
> +
> +#include <linux/firmware/imx/sci.h>
> +
> +/*
> + * This type is used to indicate RPC RM function calls.
> + */
> +enum imx_sc_rm_func {
> + IMX_SC_RM_FUNC_UNKNOWN = 0,
> + IMX_SC_RM_FUNC_PARTITION_ALLOC = 1,
> + IMX_SC_RM_FUNC_SET_CONFIDENTIAL = 31,
> + IMX_SC_RM_FUNC_PARTITION_FREE = 2,
> + IMX_SC_RM_FUNC_GET_DID = 26,
> + IMX_SC_RM_FUNC_PARTITION_STATIC = 3,
> + IMX_SC_RM_FUNC_PARTITION_LOCK = 4,
> + IMX_SC_RM_FUNC_GET_PARTITION = 5,
> + IMX_SC_RM_FUNC_SET_PARENT = 6,
> + IMX_SC_RM_FUNC_MOVE_ALL = 7,
> + IMX_SC_RM_FUNC_ASSIGN_RESOURCE = 8,
> + IMX_SC_RM_FUNC_SET_RESOURCE_MOVABLE = 9,
> + IMX_SC_RM_FUNC_SET_SUBSYS_RSRC_MOVABLE = 28,
> + IMX_SC_RM_FUNC_SET_MASTER_ATTRIBUTES = 10,
> + IMX_SC_RM_FUNC_SET_MASTER_SID = 11,
> + IMX_SC_RM_FUNC_SET_PERIPHERAL_PERMISSIONS = 12,
> + IMX_SC_RM_FUNC_IS_RESOURCE_OWNED = 13,
> + IMX_SC_RM_FUNC_GET_RESOURCE_OWNER = 33,
> + IMX_SC_RM_FUNC_IS_RESOURCE_MASTER = 14,
> + IMX_SC_RM_FUNC_IS_RESOURCE_PERIPHERAL = 15,
> + IMX_SC_RM_FUNC_GET_RESOURCE_INFO = 16,
> + IMX_SC_RM_FUNC_MEMREG_ALLOC = 17,
> + IMX_SC_RM_FUNC_MEMREG_SPLIT = 29,
> + IMX_SC_RM_FUNC_MEMREG_FRAG = 32,
> + IMX_SC_RM_FUNC_MEMREG_FREE = 18,
> + IMX_SC_RM_FUNC_FIND_MEMREG = 30,
> + IMX_SC_RM_FUNC_ASSIGN_MEMREG = 19,
> + IMX_SC_RM_FUNC_SET_MEMREG_PERMISSIONS = 20,
> + IMX_SC_RM_FUNC_IS_MEMREG_OWNED = 21,
> + IMX_SC_RM_FUNC_GET_MEMREG_INFO = 22,
> + IMX_SC_RM_FUNC_ASSIGN_PAD = 23,
> + IMX_SC_RM_FUNC_SET_PAD_MOVABLE = 24,
> + IMX_SC_RM_FUNC_IS_PAD_OWNED = 25,
> + IMX_SC_RM_FUNC_DUMP = 27,
> +};
> +
> +#if IS_ENABLED(CONFIG_IMX_SCU)
> +bool imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16 resource);
> +#else static inline bool imx_sc_rm_is_resource_owned(struct imx_sc_ipc
> +*ipc, u16 resource) {
> + return true;
> +}
> +#endif
> +#endif
> --
> 2.16.4
_______________________________________________
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] Convert i.MX/MXS mmc binding to json-schema
From: Anson Huang @ 2020-06-02 3:37 UTC (permalink / raw)
To: ulf.hansson, robh+dt, shawnguo, s.hauer, kernel, festevam, mpa,
linux-mmc, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
This patch series converts i.MX and MXS mmc binding to json-schema,
fix some minor issues in original binding doc, such as node name should
be 'mmc', compatible name for i.MX27, reg/interrupts should be required
properties etc..
Anson Huang (3):
dt-bindings: mmc: Convert imx esdhc to json-schema
dt-bindings: mmc: Convert imx mmc to json-schema
dt-bindings: mmc: Convert mxs mmc to json-schema
.../devicetree/bindings/mmc/fsl-imx-esdhc.txt | 67 -----------
.../devicetree/bindings/mmc/fsl-imx-esdhc.yaml | 122 +++++++++++++++++++++
.../devicetree/bindings/mmc/fsl-imx-mmc.txt | 23 ----
.../devicetree/bindings/mmc/fsl-imx-mmc.yaml | 51 +++++++++
Documentation/devicetree/bindings/mmc/mxs-mmc.txt | 27 -----
Documentation/devicetree/bindings/mmc/mxs-mmc.yaml | 56 ++++++++++
6 files changed, 229 insertions(+), 117 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
create mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
delete mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
create mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml
delete mode 100644 Documentation/devicetree/bindings/mmc/mxs-mmc.txt
create mode 100644 Documentation/devicetree/bindings/mmc/mxs-mmc.yaml
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] dt-bindings: mmc: Convert imx esdhc to json-schema
From: Anson Huang @ 2020-06-02 3:37 UTC (permalink / raw)
To: ulf.hansson, robh+dt, shawnguo, s.hauer, kernel, festevam, mpa,
linux-mmc, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1591069066-12727-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX ESDHC binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/mmc/fsl-imx-esdhc.txt | 67 -----------
.../devicetree/bindings/mmc/fsl-imx-esdhc.yaml | 122 +++++++++++++++++++++
2 files changed, 122 insertions(+), 67 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
create mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
deleted file mode 100644
index de1b8bd..0000000
--- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-* Freescale Enhanced Secure Digital Host Controller (eSDHC) for i.MX
-
-The Enhanced Secure Digital Host Controller on Freescale i.MX family
-provides an interface for MMC, SD, and SDIO types of memory cards.
-
-This file documents differences between the core properties described
-by mmc.txt and the properties used by the sdhci-esdhc-imx driver.
-
-Required properties:
-- compatible : Should be "fsl,<chip>-esdhc", the supported chips include
- "fsl,imx25-esdhc"
- "fsl,imx35-esdhc"
- "fsl,imx51-esdhc"
- "fsl,imx53-esdhc"
- "fsl,imx6q-usdhc"
- "fsl,imx6sl-usdhc"
- "fsl,imx6sx-usdhc"
- "fsl,imx6ull-usdhc"
- "fsl,imx7d-usdhc"
- "fsl,imx7ulp-usdhc"
- "fsl,imx8mq-usdhc"
- "fsl,imx8mm-usdhc"
- "fsl,imx8mn-usdhc"
- "fsl,imx8mp-usdhc"
- "fsl,imx8qm-usdhc"
- "fsl,imx8qxp-usdhc"
-
-Optional properties:
-- fsl,wp-controller : Indicate to use controller internal write protection
-- fsl,delay-line : Specify the number of delay cells for override mode.
- This is used to set the clock delay for DLL(Delay Line) on override mode
- to select a proper data sampling window in case the clock quality is not good
- due to signal path is too long on the board. Please refer to eSDHC/uSDHC
- chapter, DLL (Delay Line) section in RM for details.
-- voltage-ranges : Specify the voltage range in case there are software
- transparent level shifters on the outputs of the controller. Two cells are
- required, first cell specifies minimum slot voltage (mV), second cell
- specifies maximum slot voltage (mV). Several ranges could be specified.
-- fsl,tuning-start-tap: Specify the start dealy cell point when send first CMD19
- in tuning procedure.
-- fsl,tuning-step: Specify the increasing delay cell steps in tuning procedure.
- The uSDHC use one delay cell as default increasing step to do tuning process.
- This property allows user to change the tuning step to more than one delay
- cells which is useful for some special boards or cards when the default
- tuning step can't find the proper delay window within limited tuning retries.
-- fsl,strobe-dll-delay-target: Specify the strobe dll control slave delay target.
- This delay target programming host controller loopback read clock, and this
- property allows user to change the delay target for the strobe input read clock.
- If not use this property, driver default set the delay target to value 7.
- Only eMMC HS400 mode need to take care of this property.
-
-Examples:
-
-esdhc@70004000 {
- compatible = "fsl,imx51-esdhc";
- reg = <0x70004000 0x4000>;
- interrupts = <1>;
- fsl,wp-controller;
-};
-
-esdhc@70008000 {
- compatible = "fsl,imx51-esdhc";
- reg = <0x70008000 0x4000>;
- interrupts = <2>;
- cd-gpios = <&gpio1 6 0>; /* GPIO1_6 */
- wp-gpios = <&gpio1 5 0>; /* GPIO1_5 */
-};
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
new file mode 100644
index 0000000..7d0ea27
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/fsl-imx-esdhc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Enhanced Secure Digital Host Controller (eSDHC) for i.MX
+
+maintainers:
+ - Shawn Guo <shawn.guo@linaro.org>
+
+allOf:
+ - $ref: "mmc-controller.yaml"
+
+description: |
+ The Enhanced Secure Digital Host Controller on Freescale i.MX family
+ provides an interface for MMC, SD, and SDIO types of memory cards.
+
+ This file documents differences between the core properties described
+ by mmc.txt and the properties used by the sdhci-esdhc-imx driver.
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx25-esdhc
+ - fsl,imx35-esdhc
+ - fsl,imx51-esdhc
+ - fsl,imx53-esdhc
+ - fsl,imx6q-usdhc
+ - fsl,imx6sl-usdhc
+ - fsl,imx6sx-usdhc
+ - fsl,imx6ull-usdhc
+ - fsl,imx7d-usdhc
+ - fsl,imx7ulp-usdhc
+ - fsl,imx8mq-usdhc
+ - fsl,imx8mm-usdhc
+ - fsl,imx8mn-usdhc
+ - fsl,imx8mp-usdhc
+ - fsl,imx8qm-usdhc
+ - fsl,imx8qxp-usdhc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ fsl,wp-controller:
+ description: |
+ boolean, if present, indicate to use controller internal write protection.
+ type: boolean
+
+ fsl,delay-line:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Specify the number of delay cells for override mode.
+ This is used to set the clock delay for DLL(Delay Line) on override mode
+ to select a proper data sampling window in case the clock quality is not good
+ due to signal path is too long on the board. Please refer to eSDHC/uSDHC
+ chapter, DLL (Delay Line) section in RM for details.
+ default: 0
+
+ voltage-ranges:
+ $ref: '/schemas/types.yaml#/definitions/uint32-matrix'
+ description: |
+ Specify the voltage range in case there are software
+ transparent level shifters on the outputs of the controller. Two cells are
+ required, first cell specifies minimum slot voltage (mV), second cell
+ specifies maximum slot voltage (mV). Several ranges could be specified.
+ items:
+ items:
+ - description: value for minimum slot voltage
+ - description: value for maximum slot voltage
+ maxItems: 1
+
+ fsl,tuning-start-tap:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Specify the start dealy cell point when send first CMD19 in tuning procedure.
+ default: 0
+
+ fsl,tuning-step:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Specify the increasing delay cell steps in tuning procedure.
+ The uSDHC use one delay cell as default increasing step to do tuning process.
+ This property allows user to change the tuning step to more than one delay
+ cells which is useful for some special boards or cards when the default
+ tuning step can't find the proper delay window within limited tuning retries.
+ default: 0
+
+ fsl,strobe-dll-delay-target:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Specify the strobe dll control slave delay target.
+ This delay target programming host controller loopback read clock, and this
+ property allows user to change the delay target for the strobe input read clock.
+ If not use this property, driver default set the delay target to value 7.
+ Only eMMC HS400 mode need to take care of this property.
+ default: 0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+ mmc@70004000 {
+ compatible = "fsl,imx51-esdhc";
+ reg = <0x70004000 0x4000>;
+ interrupts = <1>;
+ fsl,wp-controller;
+ };
+
+ mmc@70008000 {
+ compatible = "fsl,imx51-esdhc";
+ reg = <0x70008000 0x4000>;
+ interrupts = <2>;
+ cd-gpios = <&gpio1 6 0>; /* GPIO1_6 */
+ wp-gpios = <&gpio1 5 0>; /* GPIO1_5 */
+ };
--
2.7.4
_______________________________________________
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] dt-bindings: mmc: Convert mxs mmc to json-schema
From: Anson Huang @ 2020-06-02 3:37 UTC (permalink / raw)
To: ulf.hansson, robh+dt, shawnguo, s.hauer, kernel, festevam, mpa,
linux-mmc, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1591069066-12727-1-git-send-email-Anson.Huang@nxp.com>
Convert the MXS MMC binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Documentation/devicetree/bindings/mmc/mxs-mmc.txt | 27 -----------
Documentation/devicetree/bindings/mmc/mxs-mmc.yaml | 56 ++++++++++++++++++++++
2 files changed, 56 insertions(+), 27 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mmc/mxs-mmc.txt
create mode 100644 Documentation/devicetree/bindings/mmc/mxs-mmc.yaml
diff --git a/Documentation/devicetree/bindings/mmc/mxs-mmc.txt b/Documentation/devicetree/bindings/mmc/mxs-mmc.txt
deleted file mode 100644
index 515addc..0000000
--- a/Documentation/devicetree/bindings/mmc/mxs-mmc.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* Freescale MXS MMC controller
-
-The Freescale MXS Synchronous Serial Ports (SSP) can act as a MMC controller
-to support MMC, SD, and SDIO types of memory cards.
-
-This file documents differences between the core properties in mmc.txt
-and the properties used by the mxsmmc driver.
-
-Required properties:
-- compatible: Should be "fsl,<chip>-mmc". The supported chips include
- imx23 and imx28.
-- interrupts: Should contain ERROR interrupt number
-- dmas: DMA specifier, consisting of a phandle to DMA controller node
- and SSP DMA channel ID.
- Refer to dma.txt and fsl-mxs-dma.txt for details.
-- dma-names: Must be "rx-tx".
-
-Examples:
-
-ssp0: ssp@80010000 {
- compatible = "fsl,imx28-mmc";
- reg = <0x80010000 2000>;
- interrupts = <96>;
- dmas = <&dma_apbh 0>;
- dma-names = "rx-tx";
- bus-width = <8>;
-};
diff --git a/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml b/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml
new file mode 100644
index 0000000..8fb9e59
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/mxs-mmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MXS MMC controller
+
+maintainers:
+ - Shawn Guo <shawn.guo@linaro.org>
+
+description: |
+ The Freescale MXS Synchronous Serial Ports (SSP) can act as a MMC controller
+ to support MMC, SD, and SDIO types of memory cards.
+
+ This file documents differences between the core properties in mmc.txt
+ and the properties used by the mxsmmc driver.
+
+allOf:
+ - $ref: "mmc-controller.yaml"
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx23-mmc
+ - fsl,imx28-mmc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ const: rx-tx
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - dmas
+ - dma-names
+
+examples:
+ - |
+ mmc@80010000 {
+ compatible = "fsl,imx28-mmc";
+ reg = <0x80010000 2000>;
+ interrupts = <96>;
+ dmas = <&dma_apbh 0>;
+ dma-names = "rx-tx";
+ bus-width = <8>;
+ };
--
2.7.4
_______________________________________________
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 2/3] dt-bindings: mmc: Convert imx mmc to json-schema
From: Anson Huang @ 2020-06-02 3:37 UTC (permalink / raw)
To: ulf.hansson, robh+dt, shawnguo, s.hauer, kernel, festevam, mpa,
linux-mmc, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1591069066-12727-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX MMC binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/mmc/fsl-imx-mmc.txt | 23 ----------
.../devicetree/bindings/mmc/fsl-imx-mmc.yaml | 51 ++++++++++++++++++++++
2 files changed, 51 insertions(+), 23 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
create mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
deleted file mode 100644
index 184ccff..0000000
--- a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-* Freescale Secure Digital Host Controller for i.MX2/3 series
-
-This file documents differences to the properties defined in mmc.txt.
-
-Required properties:
-- compatible : Should be "fsl,<chip>-mmc", chip can be imx21 or imx31
-
-Optional properties:
-- dmas: One DMA phandle with arguments as defined by the devicetree bindings
- of the used DMA controller.
-- dma-names: Has to be "rx-tx".
-
-Example:
-
-sdhci1: sdhci@10014000 {
- compatible = "fsl,imx27-mmc", "fsl,imx21-mmc";
- reg = <0x10014000 0x1000>;
- interrupts = <11>;
- dmas = <&dma 7>;
- dma-names = "rx-tx";
- bus-width = <4>;
- cd-gpios = <&gpio3 29>;
-};
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml
new file mode 100644
index 0000000..777a732
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/fsl-imx-mmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Secure Digital Host Controller for i.MX2/3 series
+
+maintainers:
+ - Markus Pargmann <mpa@pengutronix.de>
+
+allOf:
+ - $ref: "mmc-controller.yaml"
+
+properties:
+ compatible:
+ oneOf:
+ - const: fsl,imx21-mmc
+ - const: fsl,imx31-mmc
+ - items:
+ - const: fsl,imx27-mmc
+ - const: fsl,imx21-mmc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ const: rx-tx
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+ mmc@10014000 {
+ compatible = "fsl,imx27-mmc", "fsl,imx21-mmc";
+ reg = <0x10014000 0x1000>;
+ interrupts = <11>;
+ dmas = <&dma 7>;
+ dma-names = "rx-tx";
+ bus-width = <4>;
+ cd-gpios = <&gpio3 29>;
+ };
--
2.7.4
_______________________________________________
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 v10] mfd: mt6360: add pmic mt6360 driver
From: Gene Chen @ 2020-06-02 3:55 UTC (permalink / raw)
To: lee.jones, matthias.bgg
Cc: gene_chen, linux-kernel, cy_huang, linux-mediatek, Wilma.Wu,
linux-arm-kernel, shufan_lee
From: Gene Chen <gene_chen@richtek.com>
Add MFD driver for mt6360 pmic chip include Battery Charger/
USB_PD/Flash, LED/RGB and LED/LDO/Buck
Signed-off-by: Gene Chen <gene_chen@richtek.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/Kconfig | 12 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/mt6360-core.c | 424 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/mfd/mt6360.h | 240 +++++++++++++++++++++++++
4 files changed, 677 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
changelogs between v9 & v10
- fix duplicate define of kbuild test reboot initializer-overrides
- sync commit message format
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 0a59249..3f8a0a0 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -870,6 +870,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 f935d10..01fa149 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -239,6 +239,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..db8cdf5
--- /dev/null
+++ b/drivers/mfd/mt6360-core.c
@@ -0,0 +1,424 @@
+// 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_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
_______________________________________________
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] driver core: platform: expose numa_node to users in sysfs
From: Greg KH @ 2020-06-02 4:23 UTC (permalink / raw)
To: Barry Song
Cc: rafael, linuxarm, linux-kernel, iommu, Prime Zeng, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20200602030139.73012-1-song.bao.hua@hisilicon.com>
On Tue, Jun 02, 2020 at 03:01:39PM +1200, Barry Song wrote:
> For some platform devices like iommu, particually ARM smmu, users may
> care about the numa locality. for example, if threads and drivers run
> near iommu, they may get much better performance on dma_unmap_sg.
> For other platform devices, users may still want to know the hardware
> topology.
>
> Cc: Prime Zeng <prime.zeng@hisilicon.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
> ---
> drivers/base/platform.c | 26 +++++++++++++++++++++++++-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index b27d0f6c18c9..7794b9a38d82 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -1062,13 +1062,37 @@ static ssize_t driver_override_show(struct device *dev,
> }
> static DEVICE_ATTR_RW(driver_override);
>
> +static ssize_t numa_node_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%d\n", dev_to_node(dev));
> +}
> +static DEVICE_ATTR_RO(numa_node);
> +
> +static umode_t platform_dev_attrs_visible(struct kobject *kobj, struct attribute *a,
> + int n)
> +{
> + struct device *dev = container_of(kobj, typeof(*dev), kobj);
> +
> + if (a == &dev_attr_numa_node.attr &&
> + dev_to_node(dev) == NUMA_NO_NODE)
> + return 0;
> +
> + return a->mode;
> +}
>
> static struct attribute *platform_dev_attrs[] = {
> &dev_attr_modalias.attr,
> + &dev_attr_numa_node.attr,
> &dev_attr_driver_override.attr,
> NULL,
> };
> -ATTRIBUTE_GROUPS(platform_dev);
> +
> +static struct attribute_group platform_dev_group = {
> + .attrs = platform_dev_attrs,
> + .is_visible = platform_dev_attrs_visible,
> +};
> +__ATTRIBUTE_GROUPS(platform_dev);
>
> static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
> {
Platform devices are NUMA? That's crazy, and feels like a total abuse
of platform devices and drivers that really should belong on a "real"
bus.
What drivers in the kernel today have this issue?
thanks,
greg k-h
_______________________________________________
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] driver core: platform: expose numa_node to users in sysfs
From: Greg KH @ 2020-06-02 4:24 UTC (permalink / raw)
To: Barry Song
Cc: rafael, linuxarm, linux-kernel, iommu, Prime Zeng, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20200602030139.73012-1-song.bao.hua@hisilicon.com>
On Tue, Jun 02, 2020 at 03:01:39PM +1200, Barry Song wrote:
> For some platform devices like iommu, particually ARM smmu, users may
> care about the numa locality. for example, if threads and drivers run
> near iommu, they may get much better performance on dma_unmap_sg.
> For other platform devices, users may still want to know the hardware
> topology.
>
> Cc: Prime Zeng <prime.zeng@hisilicon.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
> ---
> drivers/base/platform.c | 26 +++++++++++++++++++++++++-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index b27d0f6c18c9..7794b9a38d82 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -1062,13 +1062,37 @@ static ssize_t driver_override_show(struct device *dev,
> }
> static DEVICE_ATTR_RW(driver_override);
>
> +static ssize_t numa_node_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%d\n", dev_to_node(dev));
> +}
> +static DEVICE_ATTR_RO(numa_node);
> +
> +static umode_t platform_dev_attrs_visible(struct kobject *kobj, struct attribute *a,
> + int n)
> +{
> + struct device *dev = container_of(kobj, typeof(*dev), kobj);
> +
> + if (a == &dev_attr_numa_node.attr &&
> + dev_to_node(dev) == NUMA_NO_NODE)
> + return 0;
> +
> + return a->mode;
> +}
>
> static struct attribute *platform_dev_attrs[] = {
> &dev_attr_modalias.attr,
> + &dev_attr_numa_node.attr,
> &dev_attr_driver_override.attr,
> NULL,
> };
> -ATTRIBUTE_GROUPS(platform_dev);
> +
> +static struct attribute_group platform_dev_group = {
> + .attrs = platform_dev_attrs,
> + .is_visible = platform_dev_attrs_visible,
> +};
> +__ATTRIBUTE_GROUPS(platform_dev);
>
> static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
> {
Also you forgot a new entry in Documentation/ABI/ :(
_______________________________________________
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] driver core: platform: expose numa_node to users in sysfs
From: Song Bao Hua (Barry Song) @ 2020-06-02 4:42 UTC (permalink / raw)
To: Greg KH
Cc: rafael@kernel.org, Linuxarm, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, Zengtao (B), Robin Murphy,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20200602042340.GA2130884@kroah.com>
> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Tuesday, June 2, 2020 4:24 PM
> To: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>
> Cc: rafael@kernel.org; iommu@lists.linux-foundation.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; Linuxarm
> <linuxarm@huawei.com>; Zengtao (B) <prime.zeng@hisilicon.com>; Robin
> Murphy <robin.murphy@arm.com>
> Subject: Re: [PATCH] driver core: platform: expose numa_node to users in sysfs
>
> On Tue, Jun 02, 2020 at 03:01:39PM +1200, Barry Song wrote:
> > For some platform devices like iommu, particually ARM smmu, users may
> > care about the numa locality. for example, if threads and drivers run
> > near iommu, they may get much better performance on dma_unmap_sg.
> > For other platform devices, users may still want to know the hardware
> > topology.
> >
> > Cc: Prime Zeng <prime.zeng@hisilicon.com>
> > Cc: Robin Murphy <robin.murphy@arm.com>
> > Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
> > ---
> > drivers/base/platform.c | 26 +++++++++++++++++++++++++-
> > 1 file changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index b27d0f6c18c9..7794b9a38d82 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -1062,13 +1062,37 @@ static ssize_t driver_override_show(struct
> device *dev,
> > }
> > static DEVICE_ATTR_RW(driver_override);
> >
> > +static ssize_t numa_node_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + return sprintf(buf, "%d\n", dev_to_node(dev));
> > +}
> > +static DEVICE_ATTR_RO(numa_node);
> > +
> > +static umode_t platform_dev_attrs_visible(struct kobject *kobj, struct
> attribute *a,
> > + int n)
> > +{
> > + struct device *dev = container_of(kobj, typeof(*dev), kobj);
> > +
> > + if (a == &dev_attr_numa_node.attr &&
> > + dev_to_node(dev) == NUMA_NO_NODE)
> > + return 0;
> > +
> > + return a->mode;
> > +}
> >
> > static struct attribute *platform_dev_attrs[] = {
> > &dev_attr_modalias.attr,
> > + &dev_attr_numa_node.attr,
> > &dev_attr_driver_override.attr,
> > NULL,
> > };
> > -ATTRIBUTE_GROUPS(platform_dev);
> > +
> > +static struct attribute_group platform_dev_group = {
> > + .attrs = platform_dev_attrs,
> > + .is_visible = platform_dev_attrs_visible,
> > +};
> > +__ATTRIBUTE_GROUPS(platform_dev);
> >
> > static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
> > {
>
> Platform devices are NUMA? That's crazy, and feels like a total abuse
> of platform devices and drivers that really should belong on a "real"
> bus.
I am not sure if it is an abuse of platform device. But smmu is a platform device,
drivers/iommu/arm-smmu-v3.c is a platform driver.
In a typical ARM server, there are maybe multiple SMMU devices which can support
IO virtual address and page tables for other devices on PCI-like busses.
Each different SMMU device might be close to different NUMA node. There is
really a hardware topology.
If you have multiple CPU packages in a NUMA server, some platform devices might
Belong to CPU0, some other might belong to CPU1.
-barry
>
> What drivers in the kernel today have this issue?
>
> thanks,
>
> greg k-h
_______________________________________________
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/4] firmware: imx: add resource management api
From: Peng Fan @ 2020-06-02 4:50 UTC (permalink / raw)
To: Aisheng Dong, shawnguo@kernel.org, s.hauer@pengutronix.de
Cc: festevam@gmail.com, Joakim Zhang, linux@rempel-privat.de,
linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de,
Leonard Crestez, Daniel Baluta, linux-kernel@vger.kernel.org,
dl-linux-imx
In-Reply-To: <AM6PR04MB4966614B0277757E98BF24C9808B0@AM6PR04MB4966.eurprd04.prod.outlook.com>
> Subject: RE: [PATCH 2/4] firmware: imx: add resource management api
>
> > From: Peng Fan <peng.fan@nxp.com>
> > Sent: Monday, June 1, 2020 8:40 PM
> > >
> > > > From: Peng Fan <peng.fan@nxp.com>
> > > > Sent: Friday, April 24, 2020 9:12 AM
> > > > >
> > > > > > From: Peng Fan <peng.fan@nxp.com>
> > > > > > Sent: Thursday, April 23, 2020 6:57 PM
> > > > > > > > From: Peng Fan <peng.fan@nxp.com>
> > > > > > > > Sent: Thursday, April 23, 2020 3:00 PM
> > > > > > > >
> > > > > > > > Add resource management API, when we have multiple
> > > > > > > > partition running together, resources not owned to current
> > > > > > > > partition should not be
> > > > > used.
> > > > > > > >
> > > > > > > > Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com>
> > > > > > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > > > >
> > > > > > > Right now I'm still not quite understand if we really need this.
> > > > > > > As current resource is bound to power domains, if it's not
> > > > > > > owned by one specific SW execution environment, power on
> > > > > > > will also
> > fail.
> > > > > > > Can you clarify if any exceptions?
> > > > > >
> > > > > > There will be lots of failures when boot Linux domu if no check.
> > > > > >
> > > > >
> > > > > What kind of features did you mean?
> > > > > Could you clarify a bit more? I'd like to understand this issue better.
> > > >
> > > > When supporting hypervisor with dual Linux running, 1st Linux and
> > > > the 2nd Linux will have their own dedicated resources.
> > > >
> > > > If no resource check, that means 1st/2nd Linux will register all
> > > > the resources, then both will see fail logs when register
> > > > resources not owned to
> > > itself.
> > > >
> > > > Same to partitioned m4 case.
> > > >
> > > > Would it be better without the failure log?
> > > >
> > >
> > > Is it power up failure?
> > > If yes, it's expected because we actually use power up to check if
> > > resources are owned by this partition. It functions the same as
> > > calling resource check API.
> > > That's current design.
> > >
> > > Or it's other failures? Log?
> > Sorry for long late reply.
> >
> > Part of my XEN DomU log, there are lots of failure log. I think better
> > not have such logs by add a resource own check.
>
> Those error logs are intended.
> Resource owner check actually behaves the same as power up.
If resource is not owned, it will not register the power domain.
Without resource own check, it will continue register the power domain
and hook it into genpd list.
I prefer we not expose the power domain not owned to current
partition and keep the err msg for people to easy
see where it goes wrong.
Regards,
Peng.
> So not quite necessary to add a double check.
> If we're concerning about the error log, we can change it to dev_dbg().
>
> BTW, as resource management will be needed by seco drivers later, So I will
> continue to review the patch.
>
> Regards
> Aisheng
>
> >
> > [ 2.034774] imx6q-pcie 5f000000.pcie: IO 0x6ff80000..0x6ff8ffff ->
> > 0x00000000
> > [ 2.034801] imx6q-pcie 5f000000.pcie: MEM 0x60000000..0x6fefffff
> ->
> > 0x60000000
> > [ 2.035072] sdhc1: failed to power up resource 249 ret -13
> > [ 2.035619] sdhc2: failed to power up resource 250 ret -13
> > [ 2.036126] enet0: failed to power up resource 251 ret -13
> > [ 2.036584] enet1: failed to power up resource 252 ret -13
> > [ 2.037040] mlb0: failed to power up resource 253 ret -13
> > [ 2.037495] nand: failed to power up resource 265 ret -13
> > [ 2.037951] nand: failed to power up resource 265 ret -13
> > [ 2.038416] pwm0: failed to power up resource 191 ret -13
> > [ 2.038868] pwm1: failed to power up resource 192 ret -13
> > [ 2.039320] pwm2: failed to power up resource 193 ret -13
> > [ 2.039786] pwm3: failed to power up resource 194 ret -13
> > [ 2.040239] pwm4: failed to power up resource 195 ret -13
> > [ 2.040692] pwm5: failed to power up resource 196 ret -13
> > [ 2.041142] pwm6: failed to power up resource 197 ret -13
> > [ 2.041596] pwm7: failed to power up resource 198 ret -13
> > [ 2.042073] amix: failed to power up resource 458 ret -13
> > [ 2.042558] lpspi0: failed to power up resource 53 ret -13
> > [ 2.043033] lpspi1: failed to power up resource 54 ret -13
> > [ 2.043501] lpspi2: failed to power up resource 55 ret -13
> > [ 2.043992] lpspi3: failed to power up resource 56 ret -13
> > [ 2.044460] lpuart0: failed to power up resource 57 ret -13
> > [ 2.044935] lpuart2: failed to power up resource 59 ret -13
> > [ 2.045409] lpuart3: failed to power up resource 60 ret -13
> > [ 2.055014] sim0: failed to power up resource 62 ret -13
> > [ 2.055510] adc0: failed to power up resource 101 ret -13
> > [ 2.056467] lpi2c0: failed to power up resource 96 ret -13
> > [ 2.056946] lpi2c1: failed to power up resource 97 ret -13
> > [ 2.057424] lpi2c2: failed to power up resource 98 ret -13
> > [ 2.057898] lpi2c3: failed to power up resource 99 ret -13
> > [ 2.058371] can0: failed to power up resource 105 ret -13
> > [ 2.059289] can1: failed to power up resource 106 ret -13
> > [ 2.059801] can2: failed to power up resource 107 ret -13
> > [ 2.060281] nand: failed to power up resource 265 ret -13
> > [ 2.062764] dpu-core 56180000.dpu: driver probed
> >
> > Thanks,
> > Peng.
> >
> > >
> > > Regards
> > > Aisheng
> > >
> > > > Thanks,
> > > > Peng.
> > > >
> > > >
> > > > >
> > > > > Regards
> > > > > Aisheng
> > > > >
> > > > > > Thanks,
> > > > > > Peng.
> > > > > >
> > > > > > >
> > > > > > > Regards
> > > > > > > Aisheng
> > > > > > >
> > > > > > > > ---
> > > > > > > > drivers/firmware/imx/Makefile | 2 +-
> > > > > > > > drivers/firmware/imx/rm.c | 40
> > > > > +++++++++++++++++++++
> > > > > > > > include/linux/firmware/imx/sci.h | 1 +
> > > > > > > > include/linux/firmware/imx/svc/rm.h | 69
> > > > > > > > +++++++++++++++++++++++++++++++++++++
> > > > > > > > 4 files changed, 111 insertions(+), 1 deletion(-) create
> > > > > > > > mode
> > > > > > > > 100644 drivers/firmware/imx/rm.c create mode 100644
> > > > > > > > include/linux/firmware/imx/svc/rm.h
> > > > > > > >
> > > > > > > > diff --git a/drivers/firmware/imx/Makefile
> > > > > > > > b/drivers/firmware/imx/Makefile index
> > > > > > > > 08bc9ddfbdfb..17ea3613e142
> > > > > > > > 100644
> > > > > > > > --- a/drivers/firmware/imx/Makefile
> > > > > > > > +++ b/drivers/firmware/imx/Makefile
> > > > > > > > @@ -1,4 +1,4 @@
> > > > > > > > # SPDX-License-Identifier: GPL-2.0
> > > > > > > > obj-$(CONFIG_IMX_DSP) += imx-dsp.o
> > > > > > > > -obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o
> > > > > > > > +obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o
> imx-scu-irq.o
> > > rm.o
> > > > > > > > obj-$(CONFIG_IMX_SCU_PD) += scu-pd.o
> > > > > > > > diff --git a/drivers/firmware/imx/rm.c
> > > > > > > > b/drivers/firmware/imx/rm.c new file mode 100644 index
> > > > > > > > 000000000000..7b0334de5486
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/drivers/firmware/imx/rm.c
> > > > > > > > @@ -0,0 +1,40 @@
> > > > > > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > > > > > +/*
> > > > > > > > + * Copyright 2020 NXP
> > > > > > > > + *
> > > > > > > > + * File containing client-side RPC functions for the RM service.
> > > > > > > > +These
> > > > > > > > + * function are ported to clients that communicate to the SC.
> > > > > > > > + */
> > > > > > > > +
> > > > > > > > +#include <linux/firmware/imx/svc/rm.h>
> > > > > > > > +
> > > > > > > > +struct imx_sc_msg_rm_rsrc_owned {
> > > > > > > > + struct imx_sc_rpc_msg hdr;
> > > > > > > > + u16 resource;
> > > > > > > > +} __packed __aligned(4);
> > > > > > > > +
> > > > > > > > +/*
> > > > > > > > + * This function check @resource is owned by current
> > > > > > > > +partition or not
> > > > > > > > + *
> > > > > > > > + * @param[in] ipc IPC handle
> > > > > > > > + * @param[in] resource resource the control is
> > > associated
> > > > > with
> > > > > > > > + *
> > > > > > > > + * @return Returns 0 for success and < 0 for errors.
> > > > > > > > + */
> > > > > > > > +bool imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc,
> > > > > > > > +u16
> > > > > > > > +resource) {
> > > > > > > > + struct imx_sc_msg_rm_rsrc_owned msg;
> > > > > > > > + struct imx_sc_rpc_msg *hdr = &msg.hdr;
> > > > > > > > +
> > > > > > > > + hdr->ver = IMX_SC_RPC_VERSION;
> > > > > > > > + hdr->svc = IMX_SC_RPC_SVC_RM;
> > > > > > > > + hdr->func = IMX_SC_RM_FUNC_IS_RESOURCE_OWNED;
> > > > > > > > + hdr->size = 2;
> > > > > > > > +
> > > > > > > > + msg.resource = resource;
> > > > > > > > +
> > > > > > > > + imx_scu_call_rpc(ipc, &msg, true);
> > > > > > > > +
> > > > > > > > + return hdr->func;
> > > > > > > > +}
> > > > > > > > +EXPORT_SYMBOL(imx_sc_rm_is_resource_owned);
> > > > > > > > diff --git a/include/linux/firmware/imx/sci.h
> > > > > > > > b/include/linux/firmware/imx/sci.h
> > > > > > > > index 17ba4e405129..b5c5a56f29be 100644
> > > > > > > > --- a/include/linux/firmware/imx/sci.h
> > > > > > > > +++ b/include/linux/firmware/imx/sci.h
> > > > > > > > @@ -15,6 +15,7 @@
> > > > > > > >
> > > > > > > > #include <linux/firmware/imx/svc/misc.h> #include
> > > > > > > > <linux/firmware/imx/svc/pm.h>
> > > > > > > > +#include <linux/firmware/imx/svc/rm.h>
> > > > > > > >
> > > > > > > > int imx_scu_enable_general_irq_channel(struct device
> > > > > > > > *dev); int imx_scu_irq_register_notifier(struct
> > > > > > > > notifier_block *nb); diff --git
> > > > > > > > a/include/linux/firmware/imx/svc/rm.h
> > > > > > > > b/include/linux/firmware/imx/svc/rm.h
> > > > > > > > new file mode 100644
> > > > > > > > index 000000000000..fc6ea62d9d0e
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/include/linux/firmware/imx/svc/rm.h
> > > > > > > > @@ -0,0 +1,69 @@
> > > > > > > > +/* SPDX-License-Identifier: GPL-2.0+ */
> > > > > > > > +/*
> > > > > > > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > > > > > > + * Copyright 2017-2019 NXP
> > > > > > > > + *
> > > > > > > > + * Header file containing the public API for the System
> > > > > > > > +Controller
> > > > > > > > +(SC)
> > > > > > > > + * Power Management (PM) function. This includes
> > > > > > > > +functions for power state
> > > > > > > > + * control, clock control, reset control, and wake-up event
> control.
> > > > > > > > + *
> > > > > > > > + * RM_SVC (SVC) Resource Management Service
> > > > > > > > + *
> > > > > > > > + * Module for the Resource Management (RM) service.
> > > > > > > > + */
> > > > > > > > +
> > > > > > > > +#ifndef _SC_RM_API_H
> > > > > > > > +#define _SC_RM_API_H
> > > > > > > > +
> > > > > > > > +#include <linux/firmware/imx/sci.h>
> > > > > > > > +
> > > > > > > > +/*
> > > > > > > > + * This type is used to indicate RPC RM function calls.
> > > > > > > > + */
> > > > > > > > +enum imx_sc_rm_func {
> > > > > > > > + IMX_SC_RM_FUNC_UNKNOWN = 0,
> > > > > > > > + IMX_SC_RM_FUNC_PARTITION_ALLOC = 1,
> > > > > > > > + IMX_SC_RM_FUNC_SET_CONFIDENTIAL = 31,
> > > > > > > > + IMX_SC_RM_FUNC_PARTITION_FREE = 2,
> > > > > > > > + IMX_SC_RM_FUNC_GET_DID = 26,
> > > > > > > > + IMX_SC_RM_FUNC_PARTITION_STATIC = 3,
> > > > > > > > + IMX_SC_RM_FUNC_PARTITION_LOCK = 4,
> > > > > > > > + IMX_SC_RM_FUNC_GET_PARTITION = 5,
> > > > > > > > + IMX_SC_RM_FUNC_SET_PARENT = 6,
> > > > > > > > + IMX_SC_RM_FUNC_MOVE_ALL = 7,
> > > > > > > > + IMX_SC_RM_FUNC_ASSIGN_RESOURCE = 8,
> > > > > > > > + IMX_SC_RM_FUNC_SET_RESOURCE_MOVABLE = 9,
> > > > > > > > + IMX_SC_RM_FUNC_SET_SUBSYS_RSRC_MOVABLE = 28,
> > > > > > > > + IMX_SC_RM_FUNC_SET_MASTER_ATTRIBUTES = 10,
> > > > > > > > + IMX_SC_RM_FUNC_SET_MASTER_SID = 11,
> > > > > > > > + IMX_SC_RM_FUNC_SET_PERIPHERAL_PERMISSIONS = 12,
> > > > > > > > + IMX_SC_RM_FUNC_IS_RESOURCE_OWNED = 13,
> > > > > > > > + IMX_SC_RM_FUNC_GET_RESOURCE_OWNER = 33,
> > > > > > > > + IMX_SC_RM_FUNC_IS_RESOURCE_MASTER = 14,
> > > > > > > > + IMX_SC_RM_FUNC_IS_RESOURCE_PERIPHERAL = 15,
> > > > > > > > + IMX_SC_RM_FUNC_GET_RESOURCE_INFO = 16,
> > > > > > > > + IMX_SC_RM_FUNC_MEMREG_ALLOC = 17,
> > > > > > > > + IMX_SC_RM_FUNC_MEMREG_SPLIT = 29,
> > > > > > > > + IMX_SC_RM_FUNC_MEMREG_FRAG = 32,
> > > > > > > > + IMX_SC_RM_FUNC_MEMREG_FREE = 18,
> > > > > > > > + IMX_SC_RM_FUNC_FIND_MEMREG = 30,
> > > > > > > > + IMX_SC_RM_FUNC_ASSIGN_MEMREG = 19,
> > > > > > > > + IMX_SC_RM_FUNC_SET_MEMREG_PERMISSIONS = 20,
> > > > > > > > + IMX_SC_RM_FUNC_IS_MEMREG_OWNED = 21,
> > > > > > > > + IMX_SC_RM_FUNC_GET_MEMREG_INFO = 22,
> > > > > > > > + IMX_SC_RM_FUNC_ASSIGN_PAD = 23,
> > > > > > > > + IMX_SC_RM_FUNC_SET_PAD_MOVABLE = 24,
> > > > > > > > + IMX_SC_RM_FUNC_IS_PAD_OWNED = 25,
> > > > > > > > + IMX_SC_RM_FUNC_DUMP = 27, };
> > > > > > > > +
> > > > > > > > +#if IS_ENABLED(CONFIG_IMX_SCU) bool
> > > > > > > > +imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16
> > > > > > > > +resource); #else static inline bool
> > > > > > > > +imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16
> > > resource) {
> > > > > > > > + return true;
> > > > > > > > +}
> > > > > > > > +#endif
> > > > > > > > +#endif
> > > > > > > > --
> > > > > > > > 2.16.4
_______________________________________________
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] driver core: platform: expose numa_node to users in sysfs
From: Song Bao Hua (Barry Song) @ 2020-06-02 5:09 UTC (permalink / raw)
To: Greg KH
Cc: rafael@kernel.org, Linuxarm, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, Zengtao (B), Robin Murphy,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20200602042340.GA2130884@kroah.com>
> >
> > Platform devices are NUMA? That's crazy, and feels like a total abuse
> > of platform devices and drivers that really should belong on a "real"
> > bus.
>
> I am not sure if it is an abuse of platform device. But smmu is a platform
> device,
> drivers/iommu/arm-smmu-v3.c is a platform driver.
> In a typical ARM server, there are maybe multiple SMMU devices which can
> support
> IO virtual address and page tables for other devices on PCI-like busses.
> Each different SMMU device might be close to different NUMA node. There is
> really a hardware topology.
>
> If you have multiple CPU packages in a NUMA server, some platform devices
> might
> Belong to CPU0, some other might belong to CPU1.
Those devices are populated by acpi_iort for an ARM server:
drivers/acpi/arm64/iort.c:
static const struct iort_dev_config iort_arm_smmu_v3_cfg __initconst = {
.name = "arm-smmu-v3",
.dev_dma_configure = arm_smmu_v3_dma_configure,
.dev_count_resources = arm_smmu_v3_count_resources,
.dev_init_resources = arm_smmu_v3_init_resources,
.dev_set_proximity = arm_smmu_v3_set_proximity,
};
void __init acpi_iort_init(void)
{
acpi_status status;
status = acpi_get_table(ACPI_SIG_IORT, 0, &iort_table);
...
iort_check_id_count_workaround(iort_table);
iort_init_platform_devices();
}
static void __init iort_init_platform_devices(void)
{
...
for (i = 0; i < iort->node_count; i++) {
if (iort_node >= iort_end) {
pr_err("iort node pointer overflows, bad table\n");
return;
}
iort_enable_acs(iort_node);
ops = iort_get_dev_cfg(iort_node);
if (ops) {
fwnode = acpi_alloc_fwnode_static();
if (!fwnode)
return;
iort_set_fwnode(iort_node, fwnode);
ret = iort_add_platform_device(iort_node, ops);
if (ret) {
iort_delete_fwnode(iort_node);
acpi_free_fwnode_static(fwnode);
return;
}
}
...
}
...
}
NUMA node is got from ACPI:
static int __init arm_smmu_v3_set_proximity(struct device *dev,
struct acpi_iort_node *node)
{
struct acpi_iort_smmu_v3 *smmu;
smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
if (smmu->flags & ACPI_IORT_SMMU_V3_PXM_VALID) {
int dev_node = acpi_map_pxm_to_node(smmu->pxm);
...
set_dev_node(dev, dev_node);
...
}
return 0;
}
Barry
_______________________________________________
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/4] firmware: imx: add resource management api
From: Peng Fan @ 2020-06-02 5:23 UTC (permalink / raw)
To: Aisheng Dong, shawnguo@kernel.org, s.hauer@pengutronix.de
Cc: festevam@gmail.com, Joakim Zhang, linux@rempel-privat.de,
linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de,
Leonard Crestez, Daniel Baluta, linux-kernel@vger.kernel.org,
dl-linux-imx
In-Reply-To: <AM6PR04MB4966DA95F44FA63CDEF7E4F5808B0@AM6PR04MB4966.eurprd04.prod.outlook.com>
> Subject: RE: [PATCH 2/4] firmware: imx: add resource management api
>
> > From: Peng Fan <peng.fan@nxp.com>
> > Sent: Thursday, April 23, 2020 3:00 PM
> >
> > Add resource management API, when we have multiple partition running
> > together, resources not owned to current partition should not be used.
> >
> > Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com>
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > drivers/firmware/imx/Makefile | 2 +-
> > drivers/firmware/imx/rm.c | 40 +++++++++++++++++++++
> > include/linux/firmware/imx/sci.h | 1 +
> > include/linux/firmware/imx/svc/rm.h | 69
> > +++++++++++++++++++++++++++++++++++++
> > 4 files changed, 111 insertions(+), 1 deletion(-) create mode 100644
> > drivers/firmware/imx/rm.c create mode 100644
> > include/linux/firmware/imx/svc/rm.h
> >
> > diff --git a/drivers/firmware/imx/Makefile
> > b/drivers/firmware/imx/Makefile index 08bc9ddfbdfb..17ea3613e142
> > 100644
> > --- a/drivers/firmware/imx/Makefile
> > +++ b/drivers/firmware/imx/Makefile
> > @@ -1,4 +1,4 @@
> > # SPDX-License-Identifier: GPL-2.0
> > obj-$(CONFIG_IMX_DSP) += imx-dsp.o
> > -obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o
> > +obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o rm.o
> > obj-$(CONFIG_IMX_SCU_PD) += scu-pd.o
> > diff --git a/drivers/firmware/imx/rm.c b/drivers/firmware/imx/rm.c new
> > file mode 100644 index 000000000000..7b0334de5486
> > --- /dev/null
> > +++ b/drivers/firmware/imx/rm.c
> > @@ -0,0 +1,40 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright 2020 NXP
> > + *
> > + * File containing client-side RPC functions for the RM service.
> > +These
> > + * function are ported to clients that communicate to the SC.
> > + */
> > +
> > +#include <linux/firmware/imx/svc/rm.h>
> > +
> > +struct imx_sc_msg_rm_rsrc_owned {
> > + struct imx_sc_rpc_msg hdr;
> > + u16 resource;
> > +} __packed __aligned(4);
> > +
> > +/*
> > + * This function check @resource is owned by current partition or not
> > + *
> > + * @param[in] ipc IPC handle
> > + * @param[in] resource resource the control is associated with
> > + *
> > + * @return Returns 0 for success and < 0 for errors.
> > + */
> > +bool imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16
> > +resource) {
> > + struct imx_sc_msg_rm_rsrc_owned msg;
> > + struct imx_sc_rpc_msg *hdr = &msg.hdr;
> > +
> > + hdr->ver = IMX_SC_RPC_VERSION;
> > + hdr->svc = IMX_SC_RPC_SVC_RM;
> > + hdr->func = IMX_SC_RM_FUNC_IS_RESOURCE_OWNED;
> > + hdr->size = 2;
> > +
> > + msg.resource = resource;
> > +
> > + imx_scu_call_rpc(ipc, &msg, true);
>
> No need check err return?
No. it use hdr->func as the resource owner bool.
However imx_scu_call_rpc also use hdr->func
to check error value or not.
When hdr->func is 1, imx_sc_to_linux_errno
will report it -EINVAL. However here 1 means
not owned.
>
> > +
> > + return hdr->func;
> > +}
> > +EXPORT_SYMBOL(imx_sc_rm_is_resource_owned);
> > diff --git a/include/linux/firmware/imx/sci.h
> > b/include/linux/firmware/imx/sci.h
> > index 17ba4e405129..b5c5a56f29be 100644
> > --- a/include/linux/firmware/imx/sci.h
> > +++ b/include/linux/firmware/imx/sci.h
> > @@ -15,6 +15,7 @@
> >
> > #include <linux/firmware/imx/svc/misc.h> #include
> > <linux/firmware/imx/svc/pm.h>
> > +#include <linux/firmware/imx/svc/rm.h>
> >
> > int imx_scu_enable_general_irq_channel(struct device *dev); int
> > imx_scu_irq_register_notifier(struct notifier_block *nb); diff --git
> > a/include/linux/firmware/imx/svc/rm.h
> > b/include/linux/firmware/imx/svc/rm.h
> > new file mode 100644
> > index 000000000000..fc6ea62d9d0e
> > --- /dev/null
> > +++ b/include/linux/firmware/imx/svc/rm.h
> > @@ -0,0 +1,69 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + * Copyright 2017-2019 NXP
>
> Update copyright
ok
>
> > + *
> > + * Header file containing the public API for the System Controller
> > +(SC)
> > + * Power Management (PM) function. This includes functions for power
> > +state
> > + * control, clock control, reset control, and wake-up event control.
>
> Fix the code comments
>
> Otherwise, I'm fine with this patch.
Ok.
Thanks,
Peng.
>
> Regards
> Aisheng
>
> > + *
> > + * RM_SVC (SVC) Resource Management Service
> > + *
> > + * Module for the Resource Management (RM) service.
> > + */
> > +
> > +#ifndef _SC_RM_API_H
> > +#define _SC_RM_API_H
> > +
> > +#include <linux/firmware/imx/sci.h>
> > +
> > +/*
> > + * This type is used to indicate RPC RM function calls.
> > + */
> > +enum imx_sc_rm_func {
> > + IMX_SC_RM_FUNC_UNKNOWN = 0,
> > + IMX_SC_RM_FUNC_PARTITION_ALLOC = 1,
> > + IMX_SC_RM_FUNC_SET_CONFIDENTIAL = 31,
> > + IMX_SC_RM_FUNC_PARTITION_FREE = 2,
> > + IMX_SC_RM_FUNC_GET_DID = 26,
> > + IMX_SC_RM_FUNC_PARTITION_STATIC = 3,
> > + IMX_SC_RM_FUNC_PARTITION_LOCK = 4,
> > + IMX_SC_RM_FUNC_GET_PARTITION = 5,
> > + IMX_SC_RM_FUNC_SET_PARENT = 6,
> > + IMX_SC_RM_FUNC_MOVE_ALL = 7,
> > + IMX_SC_RM_FUNC_ASSIGN_RESOURCE = 8,
> > + IMX_SC_RM_FUNC_SET_RESOURCE_MOVABLE = 9,
> > + IMX_SC_RM_FUNC_SET_SUBSYS_RSRC_MOVABLE = 28,
> > + IMX_SC_RM_FUNC_SET_MASTER_ATTRIBUTES = 10,
> > + IMX_SC_RM_FUNC_SET_MASTER_SID = 11,
> > + IMX_SC_RM_FUNC_SET_PERIPHERAL_PERMISSIONS = 12,
> > + IMX_SC_RM_FUNC_IS_RESOURCE_OWNED = 13,
> > + IMX_SC_RM_FUNC_GET_RESOURCE_OWNER = 33,
> > + IMX_SC_RM_FUNC_IS_RESOURCE_MASTER = 14,
> > + IMX_SC_RM_FUNC_IS_RESOURCE_PERIPHERAL = 15,
> > + IMX_SC_RM_FUNC_GET_RESOURCE_INFO = 16,
> > + IMX_SC_RM_FUNC_MEMREG_ALLOC = 17,
> > + IMX_SC_RM_FUNC_MEMREG_SPLIT = 29,
> > + IMX_SC_RM_FUNC_MEMREG_FRAG = 32,
> > + IMX_SC_RM_FUNC_MEMREG_FREE = 18,
> > + IMX_SC_RM_FUNC_FIND_MEMREG = 30,
> > + IMX_SC_RM_FUNC_ASSIGN_MEMREG = 19,
> > + IMX_SC_RM_FUNC_SET_MEMREG_PERMISSIONS = 20,
> > + IMX_SC_RM_FUNC_IS_MEMREG_OWNED = 21,
> > + IMX_SC_RM_FUNC_GET_MEMREG_INFO = 22,
> > + IMX_SC_RM_FUNC_ASSIGN_PAD = 23,
> > + IMX_SC_RM_FUNC_SET_PAD_MOVABLE = 24,
> > + IMX_SC_RM_FUNC_IS_PAD_OWNED = 25,
> > + IMX_SC_RM_FUNC_DUMP = 27,
> > +};
> > +
> > +#if IS_ENABLED(CONFIG_IMX_SCU)
> > +bool imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16
> > +resource); #else static inline bool
> > +imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16 resource) {
> > + return true;
> > +}
> > +#endif
> > +#endif
> > --
> > 2.16.4
_______________________________________________
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] dt-bindings: mailbox: imx-mu: support i.MX8M
From: Oleksij Rempel @ 2020-06-02 5:24 UTC (permalink / raw)
To: peng.fan
Cc: aisheng.dong, devicetree, sboyd, daniel.baluta, linux-kernel,
linux, jaswinder.singh, robh+dt, linux-imx, kernel, fabio.estevam,
leonard.crestez, shawnguo, linux-clk, linux-arm-kernel, l.stach
In-Reply-To: <1590999602-29482-2-git-send-email-peng.fan@nxp.com>
[-- Attachment #1.1: Type: text/plain, Size: 1661 bytes --]
On Mon, Jun 01, 2020 at 04:20:00PM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Add i.MX8MQ/M/N/P compatible string to support i.MX8M SoCs
>
> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> index 26b7a88c2fea..906377acf2cd 100644
> --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> @@ -18,7 +18,8 @@ Messaging Unit Device Node:
> Required properties:
> -------------------
> - compatible : should be "fsl,<chip>-mu", the supported chips include
> - imx6sx, imx7s, imx8qxp, imx8qm.
> + imx6sx, imx7s, imx8qxp, imx8qm, imx8mq, imx8mm, imx8mn,
> + imx8mp.
> The "fsl,imx6sx-mu" compatible is seen as generic and should
> be included together with SoC specific compatible.
> There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu"
> --
> 2.16.4
>
>
Hi Peng,
The fsl,mu.yaml was already taken by Rob, so one or other patch will
break by merge. I assume you should drop this change.
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: 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
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