* Re: [PATCH v2 1/2] mm/page_ext: support to record the last stack of page
From: Walter Wu @ 2019-09-10 1:07 UTC (permalink / raw)
To: David Hildenbrand
Cc: Qian Cai, wsd_upstream, Arnd Bergmann, linux-mm, Andrey Konovalov,
linux-mediatek, linux-kernel, kasan-dev, Michal Hocko,
Martin Schwidefsky, Alexander Potapenko, linux-arm-kernel,
Matthias Brugger, Andrey Ryabinin, Andrew Morton, Will Deacon,
Thomas Gleixner, Dmitry Vyukov
In-Reply-To: <36b5a8e0-2783-4c0e-4fc7-78ea652ba475@redhat.com>
On Mon, 2019-09-09 at 12:57 +0200, David Hildenbrand wrote:
> On 09.09.19 10:53, Walter Wu wrote:
> > KASAN will record last stack of page in order to help programmer
> > to see memory corruption caused by page.
> >
> > What is difference between page_owner and our patch?
> > page_owner records alloc stack of page, but our patch is to record
> > last stack(it may be alloc or free stack of page).
> >
> > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> > ---
> > mm/page_ext.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/mm/page_ext.c b/mm/page_ext.c
> > index 5f5769c7db3b..7ca33dcd9ffa 100644
> > --- a/mm/page_ext.c
> > +++ b/mm/page_ext.c
> > @@ -65,6 +65,9 @@ static struct page_ext_operations *page_ext_ops[] = {
> > #if defined(CONFIG_IDLE_PAGE_TRACKING) && !defined(CONFIG_64BIT)
> > &page_idle_ops,
> > #endif
> > +#ifdef CONFIG_KASAN
> > + &page_stack_ops,
> > +#endif
> > };
> >
> > static unsigned long total_usage;
> >
>
> Are you sure this patch compiles?
>
This is patchsets, it need another patch2.
We have verified it by running KASAN UT on Qemu.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] regulator: uniphier: Add Pro5 USB3 VBUS support
From: Kunihiko Hayashi @ 2019-09-10 1:51 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Mark Rutland,
Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-kernel,
Jassi Brar, linux-arm-kernel
Pro5 SoC has same scheme of USB3 VBUS as Pro4, so the data for Pro5 is
equivalent to Pro4.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
Documentation/devicetree/bindings/regulator/uniphier-regulator.txt | 5 +++--
drivers/regulator/uniphier-regulator.c | 4 ++++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/uniphier-regulator.txt b/Documentation/devicetree/bindings/regulator/uniphier-regulator.txt
index c9919f4..94fd38b 100644
--- a/Documentation/devicetree/bindings/regulator/uniphier-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/uniphier-regulator.txt
@@ -13,6 +13,7 @@ this layer. These clocks and resets should be described in each property.
Required properties:
- compatible: Should be
"socionext,uniphier-pro4-usb3-regulator" - for Pro4 SoC
+ "socionext,uniphier-pro5-usb3-regulator" - for Pro5 SoC
"socionext,uniphier-pxs2-usb3-regulator" - for PXs2 SoC
"socionext,uniphier-ld20-usb3-regulator" - for LD20 SoC
"socionext,uniphier-pxs3-usb3-regulator" - for PXs3 SoC
@@ -20,12 +21,12 @@ Required properties:
- clocks: A list of phandles to the clock gate for USB3 glue layer.
According to the clock-names, appropriate clocks are required.
- clock-names: Should contain
- "gio", "link" - for Pro4 SoC
+ "gio", "link" - for Pro4 and Pro5 SoCs
"link" - for others
- resets: A list of phandles to the reset control for USB3 glue layer.
According to the reset-names, appropriate resets are required.
- reset-names: Should contain
- "gio", "link" - for Pro4 SoC
+ "gio", "link" - for Pro4 and Pro5 SoCs
"link" - for others
See Documentation/devicetree/bindings/regulator/regulator.txt
diff --git a/drivers/regulator/uniphier-regulator.c b/drivers/regulator/uniphier-regulator.c
index 9026d5a..2311924 100644
--- a/drivers/regulator/uniphier-regulator.c
+++ b/drivers/regulator/uniphier-regulator.c
@@ -186,6 +186,10 @@ static const struct of_device_id uniphier_regulator_match[] = {
.data = &uniphier_pro4_usb3_data,
},
{
+ .compatible = "socionext,uniphier-pro5-usb3-regulator",
+ .data = &uniphier_pro4_usb3_data,
+ },
+ {
.compatible = "socionext,uniphier-pxs2-usb3-regulator",
.data = &uniphier_pxs2_usb3_data,
},
--
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] reset: uniphier-glue: Add Pro5 USB3 support
From: Kunihiko Hayashi @ 2019-09-10 1:55 UTC (permalink / raw)
To: Philipp Zabel, Rob Herring, Mark Rutland, Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-kernel,
Jassi Brar, linux-arm-kernel
Pro5 SoC has same scheme of USB3 reset as Pro4, so the data for Pro5 is
equivalent to Pro4.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
Documentation/devicetree/bindings/reset/uniphier-reset.txt | 5 +++--
drivers/reset/reset-uniphier-glue.c | 4 ++++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/reset/uniphier-reset.txt b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
index ea00517..e320a8c 100644
--- a/Documentation/devicetree/bindings/reset/uniphier-reset.txt
+++ b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
@@ -130,6 +130,7 @@ this layer. These clocks and resets should be described in each property.
Required properties:
- compatible: Should be
"socionext,uniphier-pro4-usb3-reset" - for Pro4 SoC USB3
+ "socionext,uniphier-pro5-usb3-reset" - for Pro5 SoC USB3
"socionext,uniphier-pxs2-usb3-reset" - for PXs2 SoC USB3
"socionext,uniphier-ld20-usb3-reset" - for LD20 SoC USB3
"socionext,uniphier-pxs3-usb3-reset" - for PXs3 SoC USB3
@@ -141,12 +142,12 @@ Required properties:
- clocks: A list of phandles to the clock gate for the glue layer.
According to the clock-names, appropriate clocks are required.
- clock-names: Should contain
- "gio", "link" - for Pro4 SoC
+ "gio", "link" - for Pro4 and Pro5 SoCs
"link" - for others
- resets: A list of phandles to the reset control for the glue layer.
According to the reset-names, appropriate resets are required.
- reset-names: Should contain
- "gio", "link" - for Pro4 SoC
+ "gio", "link" - for Pro4 and Pro5 SoCs
"link" - for others
Example:
diff --git a/drivers/reset/reset-uniphier-glue.c b/drivers/reset/reset-uniphier-glue.c
index a45923f..2b188b3bb 100644
--- a/drivers/reset/reset-uniphier-glue.c
+++ b/drivers/reset/reset-uniphier-glue.c
@@ -141,6 +141,10 @@ static const struct of_device_id uniphier_glue_reset_match[] = {
.data = &uniphier_pro4_data,
},
{
+ .compatible = "socionext,uniphier-pro5-usb3-reset",
+ .data = &uniphier_pro4_data,
+ },
+ {
.compatible = "socionext,uniphier-pxs2-usb3-reset",
.data = &uniphier_pxs2_data,
},
--
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] arm64: dts: imx8mn: Add "fsl, imx8mq-src" as src's fallback compatible
From: Anson Huang @ 2019-09-10 14:39 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
leonard.crestez, daniel.baluta, devicetree, linux-arm-kernel,
linux-kernel
Cc: Linux-imx
i.MX8MN can reuse i.MX8MQ's src driver, add "fsl,imx8mq-src" as
src's fallback compatible to enable it.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 785f4c4..d94db95 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -371,7 +371,7 @@
};
src: reset-controller@30390000 {
- compatible = "fsl,imx8mn-src", "syscon";
+ compatible = "fsl,imx8mn-src", "fsl,imx8mq-src", "syscon";
reg = <0x30390000 0x10000>;
interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
#reset-cells = <1>;
--
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 v1 1/1] ARM: dts: rockchip: set crypto default disabled on rk3288
From: Elon Zhang @ 2019-09-10 2:45 UTC (permalink / raw)
To: Heiko Stuebner
Cc: mark.rutland, devicetree, linux-kernel, linux-rockchip, robh+dt,
linux-arm-kernel
In-Reply-To: <3345609.Z0LLm6LDBC@phil>
Hi Heiko,
On 9/1/2019 07:04, Heiko Stuebner wrote:
> Hi Elon,
>
> Am Donnerstag, 29. August 2019, 13:31:00 CEST schrieb Elon Zhang:
>> On 8/27/2019 22:28, Heiko Stuebner wrote:
>>> Am Dienstag, 27. August 2019, 09:14:39 CEST schrieb Elon Zhang:
>>>> Not every board needs to enable crypto node, so the node should
>>>> be set default disabled in rk3288.dtsi and enabled in specific
>>>> board dts file.
>>> Can you give a bit more rationale here? There would need to be a very
>>> specific reason because of the following:
>>>
>>> The crypto module is not wired to some board-specific components,
>>> so its usability does not depend on the specific board at all.
>>> Instead every board can just use it out of the box and the devicetree
>>> is supposed to describe the hardware and is _not_ meant as a space
>>> for user configuration.
>> Right for almost all normal hardware modules but the crypto module was
>> designed
>>
>> for secure world. As a result, the crypto module will become
>> inaccessible for linux kernel if secure world enable it.
>>
>> We plan to enable the crypto module in secure world so we should set
>> crypto module default disabled in linux kernel.
> ok ... I'm halfway convinced ;-) .
>
> The big thing I want to see is that secure setting in the actual firmware.
> Aka right now you probably have that in your Rockchip-specific ATF fork
> and I really want to see the relevant change for public uboot or ATF.
>
> I don't necessarily require it to be fully merged before taking this, but
> I really want to see the change either on a mailing list or atf gerrit
> instance [that makes the crypto engine secure only].
>
> Rationale behind this is that we don't care very much about private stuff
> that the general ecosystem doesn't benefit from.
Now the crypto security property setting is done in the rockchip private
code, which is not
opensource. So if you don't care about private stuff and the change in
private stuff will not
affect the upstream kernel, the crypto can be enabled in upstream kernel?
>
>
> Thanks
> Heiko
>
>
>>> So in fact the status property should probably go away completely from
>>> the crypto node, as it's usable out of the box in all cases.
>>>
>>>
>>> Heiko
>>>
>>>
>>>
>>>> Signed-off-by: Elon Zhang <zhangzj@rock-chips.com>
>>>> ---
>>>> arch/arm/boot/dts/rk3288.dtsi | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
>>>> index cc893e154fe5..d509aa24177c 100644
>>>> --- a/arch/arm/boot/dts/rk3288.dtsi
>>>> +++ b/arch/arm/boot/dts/rk3288.dtsi
>>>> @@ -984,7 +984,7 @@
>>>> clock-names = "aclk", "hclk", "sclk", "apb_pclk";
>>>> resets = <&cru SRST_CRYPTO>;
>>>> reset-names = "crypto-rst";
>>>> - status = "okay";
>>>> + status = "disabled";
>>>> };
>>>>
>>>> iep_mmu: iommu@ff900800 {
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
>
>
_______________________________________________
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] clk: imx: lpcg: write twice when writing lpcg regs
From: Anson Huang @ 2019-09-10 2:47 UTC (permalink / raw)
To: Dong Aisheng, Stephen Boyd, Peng Fan
Cc: Aisheng Dong, Peng Fan, Jacky Bai, festevam@gmail.com,
mturquette@baylibre.com, linux-kernel@vger.kernel.org,
linux-clk@vger.kernel.org, dl-linux-imx, kernel@pengutronix.de,
shawnguo@kernel.org, s.hauer@pengutronix.de,
linux-arm-kernel@lists.infradead.org, Abel Vesa
In-Reply-To: <CAA+hA=To9B0H1z6Hh1eSZN9_rcextT_Oe-CTMmz9fC9CDNUBTQ@mail.gmail.com>
> On Sat, Sep 7, 2019 at 9:47 PM Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > Quoting Peng Fan (2019-08-27 01:17:50)
> > > From: Peng Fan <peng.fan@nxp.com>
> > >
> > > There is hardware issue that:
> > > The output clock the LPCG cell will not turn back on as expected,
> > > even though a read of the IPG registers in the LPCG indicates that
> > > the clock should be enabled.
> > >
> > > The software workaround is to write twice to enable the LPCG clock
> > > output.
> > >
> > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> >
> > Does this need a Fixes tag?
>
> Not sure as it's not code logic issue but a hardware bug.
> And 4.19 LTS still have not this driver support.
Looks like there is an errata for this issue, and Ranjani just sent a patch for review internally,
Back-to-back LPCG writes can be ignored by the LPCG register due to a
HW bug. The writes need to be separated by atleast 4 cycles of the gated clock.
The workaround is implemented as follows:
1. For clocks running greater than 50MHz no delay is required as the
delay in accessing the LPCG register is sufficient.
2. For clocks running greater than 23MHz, a read followed by the write
will provide the sufficient delay.
3. For clocks running below 23MHz, LPCG is not used.
Need double check?
Anson.
_______________________________________________
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/2] arm64: dts: imx8mn: Add system counter node
From: Anson Huang @ 2019-09-10 15:25 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
leonard.crestez, daniel.baluta, devicetree, linux-arm-kernel,
linux-kernel
Cc: Linux-imx
Add i.MX8MN system counter node to enable timer-imx-sysctr
broadcast timer driver.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index d94db95..0166f8c 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -428,6 +428,14 @@
#pwm-cells = <2>;
status = "disabled";
};
+
+ system_counter: timer@306a0000 {
+ compatible = "nxp,sysctr-timer";
+ reg = <0x306a0000 0x20000>;
+ interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&osc_24m>;
+ clock-names = "per";
+ };
};
aips3: bus@30800000 {
--
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/2] arm64: dts: imx8mn: Enable cpu-idle driver
From: Anson Huang @ 2019-09-10 15:25 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
leonard.crestez, daniel.baluta, devicetree, linux-arm-kernel,
linux-kernel
Cc: Linux-imx
In-Reply-To: <1568129118-31114-1-git-send-email-Anson.Huang@nxp.com>
Enable i.MX8MN cpu-idle using generic ARM cpu-idle driver, 2 states
are supported, details as below:
root@imx8mnevk:~# cat /sys/devices/system/cpu/cpu0/cpuidle/state0/name
WFI
root@imx8mnevk:~# cat /sys/devices/system/cpu/cpu0/cpuidle/state0/usage
3098
root@imx8mnevk:~# cat /sys/devices/system/cpu/cpu0/cpuidle/state1/name
cpu-pd-wait
root@imx8mnevk:~# cat /sys/devices/system/cpu/cpu0/cpuidle/state1/usage
3078
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 0166f8c..e4efe8d 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -43,6 +43,19 @@
#address-cells = <1>;
#size-cells = <0>;
+ idle-states {
+ entry-method = "psci";
+
+ cpu_pd_wait: cpu-pd-wait {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x0010033>;
+ local-timer-stop;
+ entry-latency-us = <1000>;
+ exit-latency-us = <700>;
+ min-residency-us = <2700>;
+ };
+ };
+
A53_0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a53";
@@ -54,6 +67,7 @@
operating-points-v2 = <&a53_opp_table>;
nvmem-cells = <&cpu_speed_grade>;
nvmem-cell-names = "speed_grade";
+ cpu-idle-states = <&cpu_pd_wait>;
};
A53_1: cpu@1 {
@@ -65,6 +79,7 @@
enable-method = "psci";
next-level-cache = <&A53_L2>;
operating-points-v2 = <&a53_opp_table>;
+ cpu-idle-states = <&cpu_pd_wait>;
};
A53_2: cpu@2 {
@@ -76,6 +91,7 @@
enable-method = "psci";
next-level-cache = <&A53_L2>;
operating-points-v2 = <&a53_opp_table>;
+ cpu-idle-states = <&cpu_pd_wait>;
};
A53_3: cpu@3 {
@@ -87,6 +103,7 @@
enable-method = "psci";
next-level-cache = <&A53_L2>;
operating-points-v2 = <&a53_opp_table>;
+ cpu-idle-states = <&cpu_pd_wait>;
};
A53_L2: l2-cache0 {
--
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] arm64: fix unreachable code issue with cmpxchg
From: Nathan Chancellor @ 2019-09-10 3:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, Catalin Marinas, linux-kernel, clang-built-linux,
Andrew Murray, Will Deacon, linux-arm-kernel
In-Reply-To: <20190909202153.144970-1-arnd@arndb.de>
On Mon, Sep 09, 2019 at 10:21:35PM +0200, Arnd Bergmann wrote:
> On arm64 build with clang, sometimes the __cmpxchg_mb is not inlined
> when CONFIG_OPTIMIZE_INLINING is set.
> Clang then fails a compile-time assertion, because it cannot tell at
> compile time what the size of the argument is:
>
> mm/memcontrol.o: In function `__cmpxchg_mb':
> memcontrol.c:(.text+0x1a4c): undefined reference to `__compiletime_assert_175'
> memcontrol.c:(.text+0x1a4c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `__compiletime_assert_175'
>
> Mark all of the cmpxchg() style functions as __always_inline to
> ensure that the compiler can see the result.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
_______________________________________________
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 V2 4/6] platform: mtk-isp: Add Mediatek DIP driver
From: Tomasz Figa @ 2019-09-10 3:45 UTC (permalink / raw)
To: Frederic Chen
Cc: yuzhao@chromium.org, linux-mediatek@lists.infradead.org,
zwisler@chromium.org, matthias.bgg@gmail.com, mchehab@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1567761407.31117.12.camel@mtksdccf07>
On Fri, Sep 6, 2019 at 6:17 PM Frederic Chen <frederic.chen@mediatek.com> wrote:
>
> Hi Tomasz,
>
> Thank you for your comments.
>
>
> On Fri, 2019-08-30 at 16:14 +0900, Tomasz Figa wrote:
> > Hi Frederic,
> >
> > On Tue, Aug 27, 2019 at 12:16 PM Frederic Chen
> > <frederic.chen@mediatek.com> wrote:
> > >
> > > Dear Tomasz,
> > >
> > > I appreciate your comment. I will collaborate more closely with Jungo
> > > to solve the common issues in DIP and Pass 1(CAM) drivers.
> > >
> >
> > Thank you!
> >
> > Also thanks for replying to all the comments, it's very helpful.
> > Please check my replies inline. I've snipped out the parts that I
> > don't have further comments on.
> >
> > >
> > > On Wed, 2019-07-31 at 15:10 +0800, Tomasz Figa wrote:
> > > > Hi Frederic,
> > > >
> > > > On Mon, Jul 08, 2019 at 07:04:58PM +0800, frederic.chen@mediatek.com wrote:
> >
> > [snip]
> >
> > > >
> > > > > + dev_buf->vbb.vb2_buf.timestamp =
> > > > > + in_buf->vbb.vb2_buf.timestamp;
> > > > > +
> > > > > + vb2_buffer_done(&dev_buf->vbb.vb2_buf, vbf_state);
> > > > > +
> > > > > + node = mtk_dip_vbq_to_node(dev_buf->vbb.vb2_buf.vb2_queue);
> > > > > + spin_lock(&node->buf_list_lock);
> > > > > + list_del(&dev_buf->list);
> > > > > + spin_unlock(&node->buf_list_lock);
> > > > > +
> > > > > + dev_dbg(&pipe->dip_dev->pdev->dev,
> > > > > + "%s:%s: return buf, idx(%d), state(%d)\n",
> > > > > + pipe->desc->name, node->desc->name,
> > > > > + dev_buf->vbb.vb2_buf.index, vbf_state);
> > > > > + }
> > > >
> > > > This looks almost the same as what's being done inside
> > > > mtk_dip_hw_streamoff(). Could we just call this function from the loop
> > > > there?
> > >
> > > I would like to call the function from mtk_dip_hw_streamoff(). The only
> > > difference is mtk_dip_pipe_job_finish() also remove the buffer from the
> > > node's internal list.
> > >
> >
> > Would anything wrong happen if we also remove the buffer from the
> > node's internal list in mtk_dip_hw_streamoff()?
> >
> > Actually, do we need that internal node list? If we have a list of
> > requests and each request stores its buffer, wouldn't that be enough?
> >
>
> We use the buffer list in the following cases:
> 1. media_pipeline_start() failed when streaming on video device
> 2. Video device stream off
>
> If the some video device is streamed on ,but the entire pipe has not
> started streaming (for example, MDP 0 is streamed on, but RAW input has
> not been streamed on), we use the list to return the buffers.
>
> Should we handle this cases? or we expect that the user will request
> buffers again to ensure all buffers are removed from the video device in
> this error case.
>
However, if we only support the Request API, there wouldn't be any
buffers outside of any request. For a request that isn't queued, the
buffers are not passed to the driver, so it doesn't need to do
anything. The only thing left to handle is when there are some
requests queued and those requests already include the buffer request
objects inside, so we can handle them without a separate internal
buffer list.
> > > > > +/* Plane size that is accepted by MDP HW */
> > > > > +static u32
> > > > > +dip_mdp_fmt_get_plane_size(const struct mtk_dip_dev_format *fmt,
> > > > > + u32 stride, u32 height,
> > > > > + unsigned int plane)
> > > > > +{
> > > > > + enum mdp_color c = fmt->mdp_color;
> > > > > + u32 bytesperline;
> > > > > +
> > > > > + bytesperline = (stride * fmt->row_depth[0])
> > > > > + / MDP_COLOR_BITS_PER_PIXEL(c);
> > > >
> > > > Hmm, stride and bytesperline should be exactly the same thing. Could you
> > > > explain what's happening here?
> > >
> > > The stride here is specific for MDP hardware (which uses the same MDP
> > > stride setting for NV12 and NV12M):
> > >
> > > bytesperline = width * row_depth / 8
> > > MDP stride = width * MDP_COLOR_BITS_PER_PIXEL /8
> > >
> > > Therfore,
> > >
> > > bytesperline = MDP stride * row_depth / MDP_COLOR_BITS_PER_PIXEL
> > > MDP stride = bytesperline * MDP_COLOR_BITS_PER_PIXEL/ row_depth
> > >
> >
> > I'm sorry I'm still confused. Is there an intermediate buffer between
> > DIP and MDP that has stride of |MDP stride| and then MDP writes to the
> > final buffer that has the stride of |bytesperline|?
> >
>
> No, there is no intermediate buffer between DIP and MDP that has stride
> of |MDP stride|. DIP connects to MDP in hardware level, so MDP writes
> the buffer with |MDP stride|.
>
> As I know, V4L2's bytesperline means bytes per line of the first
> plane(*), but mdp hw needs y, u, v stride (it is different from V4L2).
> Therefore we calculate the |MDP stride| here.
>
> *:
> https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/pixfmt-v4l2.html#c.v4l2_pix_format
> "When the image format is planar the bytesperline value applies to the
> first plane and is divided by the same factor as the width field for the
> other planes."
However, we're using v4l2_pix_fmt_mplane, not v4l2_pix_format. If the
pixelformat is the M variant (e.g. V4L2_PIX_FMT_NV12M), the
v4l2_pix_fmt_mplane::planes[] contains bytesperline and sizeimage for
each plane separately. That's the reason I'm strongly suggesting
abandoning the non-M formats and supporting only the M ones.
>
> > [snip]
> >
> > > >
> > > > > + u32 sizeimage;
> > > > > +
> > > > > + if (bpl < min_bpl)
> > > > > + bpl = min_bpl;
> > > > > +
> > > > > + sizeimage = (bpl * mfmt_to_fill->height * dev_fmt->depth[i])
> > > > > + / dev_fmt->row_depth[i];
> > > >
> > > > Shouldn't this be bpl * fmt->height?
> > >
> > > Row_depth is the bits of the pixel.
> > > Depth means the bytes per pixel of the image format.
> > >
> > > For example,
> > > Image: 640 * 480
> > > YV12: row_depth = 8, depth = 12
> >
> > YV12 has 3 planes of 8 bits per pixel. Not sure where does this 12 come from.
> >
>
> Let me elaborate more about the 12 depth.
>
> depth: pixel bit number
>
> For 420,
>
> y = w * h
> u = (w/2) * (h/2)
> v = (w/2) * (h/2)
>
> Therefore,
>
> y = 8,
> u = 8/2/2 = 2
> v = 8/2/2 = 2
>
> depth (y + u + v) = 8 + 2 + 2 = 12
>
Yes, that's what I understood, but it is by no means associated with
any physical depth. It's more like "total_bits_per_pixel". That's
however a very error prone way to express pixel formats, as for
example it can't handle the case when plane strides alignments are not
proportional.
Please see the v4l2_format_info struct for the recommended way of
describing pixel formats. Actually, the struct itself could be reused
in this driver, even if we don't end up using the helpers for some
reason.
>
> > > Bytes per line = width * row_depth / 8 = 640 * 8/ 8 = 640
> > > Image size = Bytes per line * height * (depth/ row_depth)
> > > = 640 * 480 * 1.5
> > >
> >
> > I think we might be having some terminology issue here. "row" is
> > normally the same as "line", which consists of |width| pixels +
> > padding, which is |bytesperline| bytes in total.
> >
> > Perhaps you want to store a bits_per_pixel[] and vertical and
> > horizontal subsampling arrays for all planes of the formats in the
> > format descriptor.
> >
> > By the way, have you considered using the V4L2 format helpers [1]?
> >
> > [1] https://elixir.bootlin.com/linux/v5.3-rc6/source/drivers/media/v4l2-core/v4l2-common.c#L561
>
> Would it be possible to keep row_depth and depth? It is already used in
> MDP drivers.
>
> https://elixir.bootlin.com/linux/v5.3-rc6/source/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
>
I'd suggest cleaning up the MDP driver instead. :)
(Could be done as a follow up later, of course.)
Best regards,
Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] mm/pgtable/debug: Add test validating architecture page table helpers
From: Anshuman Khandual @ 2019-09-10 3:56 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Mark Rutland, linux-ia64, linux-sh, Tetsuo Handa, James Hogan,
Heiko Carstens, Michal Hocko, linux-mm, Dave Hansen,
Paul Mackerras, sparclinux, Thomas Gleixner, linux-s390,
Michael Ellerman, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Jason Gunthorpe, Vlastimil Babka, linux-snps-arc,
Kees Cook, Masahiro Yamada, Mark Brown, Dan Williams,
Gerald Schaefer, linux-arm-kernel, Sri Krishna chowdary,
Ard Biesheuvel, Greg Kroah-Hartman, linux-mips, Ralf Baechle,
linux-kernel, Peter Zijlstra, Mike Rapoport, Paul Burton,
Vineet Gupta, Martin Schwidefsky, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <20190909151344.ghfypjbgxyosjdk3@box>
On 09/09/2019 08:43 PM, Kirill A. Shutemov wrote:
> On Mon, Sep 09, 2019 at 11:56:50AM +0530, Anshuman Khandual wrote:
>>
>>
>> On 09/07/2019 12:33 AM, Gerald Schaefer wrote:
>>> On Fri, 6 Sep 2019 11:58:59 +0530
>>> Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>>>
>>>> On 09/05/2019 10:36 PM, Gerald Schaefer wrote:
>>>>> On Thu, 5 Sep 2019 14:48:14 +0530
>>>>> Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>>>>>
>>>>>>> [...]
>>>>>>>> +
>>>>>>>> +#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
>>>>>>>> +static void pud_clear_tests(pud_t *pudp)
>>>>>>>> +{
>>>>>>>> + memset(pudp, RANDOM_NZVALUE, sizeof(pud_t));
>>>>>>>> + pud_clear(pudp);
>>>>>>>> + WARN_ON(!pud_none(READ_ONCE(*pudp)));
>>>>>>>> +}
>>>>>>>
>>>>>>> For pgd/p4d/pud_clear(), we only clear if the page table level is present
>>>>>>> and not folded. The memset() here overwrites the table type bits, so
>>>>>>> pud_clear() will not clear anything on s390 and the pud_none() check will
>>>>>>> fail.
>>>>>>> Would it be possible to OR a (larger) random value into the table, so that
>>>>>>> the lower 12 bits would be preserved?
>>>>>>
>>>>>> So the suggestion is instead of doing memset() on entry with RANDOM_NZVALUE,
>>>>>> it should OR a large random value preserving lower 12 bits. Hmm, this should
>>>>>> still do the trick for other platforms, they just need non zero value. So on
>>>>>> s390, the lower 12 bits on the page table entry already has valid value while
>>>>>> entering this function which would make sure that pud_clear() really does
>>>>>> clear the entry ?
>>>>>
>>>>> Yes, in theory the table entry on s390 would have the type set in the last
>>>>> 4 bits, so preserving those would be enough. If it does not conflict with
>>>>> others, I would still suggest preserving all 12 bits since those would contain
>>>>> arch-specific flags in general, just to be sure. For s390, the pte/pmd tests
>>>>> would also work with the memset, but for consistency I think the same logic
>>>>> should be used in all pxd_clear_tests.
>>>>
>>>> Makes sense but..
>>>>
>>>> There is a small challenge with this. Modifying individual bits on a given
>>>> page table entry from generic code like this test case is bit tricky. That
>>>> is because there are not enough helpers to create entries with an absolute
>>>> value. This would have been easier if all the platforms provided functions
>>>> like __pxx() which is not the case now. Otherwise something like this should
>>>> have worked.
>>>>
>>>>
>>>> pud_t pud = READ_ONCE(*pudp);
>>>> pud = __pud(pud_val(pud) | RANDOM_VALUE (keeping lower 12 bits 0))
>>>> WRITE_ONCE(*pudp, pud);
>>>>
>>>> But __pud() will fail to build in many platforms.
>>>
>>> Hmm, I simply used this on my system to make pud_clear_tests() work, not
>>> sure if it works on all archs:
>>>
>>> pud_val(*pudp) |= RANDOM_NZVALUE;
>>
>> Which compiles on arm64 but then fails on x86 because of the way pmd_val()
>> has been defined there.
>
> Use instead
>
> *pudp = __pud(pud_val(*pudp) | RANDOM_NZVALUE);
Agreed.
As I had mentioned before this would have been really the cleanest approach.
>
> It *should* be more portable.
Not really, because not all the platforms have __pxx() definitions right now.
Going with these will clearly cause build failures on affected platforms. Lets
examine __pud() for instance. It is defined only on these platforms.
arch/arm64/include/asm/pgtable-types.h: #define __pud(x) ((pud_t) { (x) } )
arch/mips/include/asm/pgtable-64.h: #define __pud(x) ((pud_t) { (x) })
arch/powerpc/include/asm/pgtable-be-types.h: #define __pud(x) ((pud_t) { cpu_to_be64(x) })
arch/powerpc/include/asm/pgtable-types.h: #define __pud(x) ((pud_t) { (x) })
arch/s390/include/asm/page.h: #define __pud(x) ((pud_t) { (x) } )
arch/sparc/include/asm/page_64.h: #define __pud(x) ((pud_t) { (x) } )
arch/sparc/include/asm/page_64.h: #define __pud(x) (x)
arch/x86/include/asm/pgtable.h: #define __pud(x) native_make_pud(x)
Similarly for __pmd()
arch/alpha/include/asm/page.h: #define __pmd(x) ((pmd_t) { (x) } )
arch/arm/include/asm/page-nommu.h: #define __pmd(x) (x)
arch/arm/include/asm/pgtable-2level-types.h: #define __pmd(x) ((pmd_t) { (x) } )
arch/arm/include/asm/pgtable-2level-types.h: #define __pmd(x) (x)
arch/arm/include/asm/pgtable-3level-types.h: #define __pmd(x) ((pmd_t) { (x) } )
arch/arm/include/asm/pgtable-3level-types.h: #define __pmd(x) (x)
arch/arm64/include/asm/pgtable-types.h: #define __pmd(x) ((pmd_t) { (x) } )
arch/m68k/include/asm/page.h: #define __pmd(x) ((pmd_t) { { (x) }, })
arch/mips/include/asm/pgtable-64.h: #define __pmd(x) ((pmd_t) { (x) } )
arch/nds32/include/asm/page.h: #define __pmd(x) (x)
arch/parisc/include/asm/page.h: #define __pmd(x) ((pmd_t) { (x) } )
arch/parisc/include/asm/page.h: #define __pmd(x) (x)
arch/powerpc/include/asm/pgtable-be-types.h: #define __pmd(x) ((pmd_t) { cpu_to_be64(x) })
arch/powerpc/include/asm/pgtable-types.h: #define __pmd(x) ((pmd_t) { (x) })
arch/riscv/include/asm/pgtable-64.h: #define __pmd(x) ((pmd_t) { (x) })
arch/s390/include/asm/page.h: #define __pmd(x) ((pmd_t) { (x) } )
arch/sh/include/asm/pgtable-3level.h: #define __pmd(x) ((pmd_t) { (x) } )
arch/sparc/include/asm/page_32.h: #define __pmd(x) ((pmd_t) { { (x) }, })
arch/sparc/include/asm/page_32.h: #define __pmd(x) ((pmd_t) { { (x) }, })
arch/sparc/include/asm/page_64.h: #define __pmd(x) ((pmd_t) { (x) } )
arch/sparc/include/asm/page_64.h: #define __pmd(x) (x)
arch/um/include/asm/page.h: #define __pmd(x) ((pmd_t) { (x) } )
arch/um/include/asm/page.h: #define __pmd(x) ((pmd_t) { (x) } )
arch/x86/include/asm/pgtable.h: #define __pmd(x) native_make_pmd(x)
Similarly for __pgd()
arch/alpha/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
arch/alpha/include/asm/page.h: #define __pgd(x) (x)
arch/arc/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
arch/arc/include/asm/page.h: #define __pgd(x) (x)
arch/arm/include/asm/pgtable-3level-types.h: #define __pgd(x) ((pgd_t) { (x) } )
arch/arm/include/asm/pgtable-3level-types.h: #define __pgd(x) (x)
arch/arm64/include/asm/pgtable-types.h: #define __pgd(x) ((pgd_t) { (x) } )
arch/csky/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
arch/hexagon/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
arch/m68k/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
arch/mips/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
arch/nds32/include/asm/page.h: #define __pgd(x) (x)
arch/nios2/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
arch/openrisc/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
arch/parisc/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
arch/parisc/include/asm/page.h: #define __pgd(x) (x)
arch/powerpc/include/asm/pgtable-be-types.h: #define __pgd(x) ((pgd_t) { cpu_to_be64(x) })
arch/powerpc/include/asm/pgtable-types.h: #define __pgd(x) ((pgd_t) { (x) })
arch/riscv/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
arch/s390/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
arch/sh/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
arch/sparc/include/asm/page_32.h: #define __pgd(x) ((pgd_t) { (x) } )
arch/sparc/include/asm/page_32.h: #define __pgd(x) (x)
arch/sparc/include/asm/page_64.h: #define __pgd(x) ((pgd_t) { (x) } )
arch/sparc/include/asm/page_64.h: #define __pgd(x) (x)
arch/um/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
arch/unicore32/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
arch/unicore32/include/asm/page.h: #define __pgd(x) (x)
arch/x86/include/asm/pgtable.h: #define __pgd(x) native_make_pgd(x)
arch/xtensa/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
Similarly for __p4d()
arch/s390/include/asm/page.h: #define __p4d(x) ((p4d_t) { (x) } )
arch/x86/include/asm/pgtable.h: #define __p4d(x) native_make_p4d(x)
The search pattern here has been "#define __pxx(". Unless I am missing something,
I dont see how we can use these without risking build failures.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] tty: serial: owl: Fix the link time qualifier of 'owl_uart_exit()'
From: Christophe JAILLET @ 2019-09-10 4:11 UTC (permalink / raw)
To: gregkh, jslaby, afaerber, manivannan.sadhasivam
Cc: Christophe JAILLET, kernel-janitors, linux-arm-kernel,
linux-serial, linux-kernel
'exit' functions should be marked as __exit, not __init.
Fixes: fc60a8b675bd ("tty: serial: owl: Implement console driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/tty/serial/owl-uart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/owl-uart.c b/drivers/tty/serial/owl-uart.c
index 03963af77b15..d2d8b3494685 100644
--- a/drivers/tty/serial/owl-uart.c
+++ b/drivers/tty/serial/owl-uart.c
@@ -740,7 +740,7 @@ static int __init owl_uart_init(void)
return ret;
}
-static void __init owl_uart_exit(void)
+static void __exit owl_uart_exit(void)
{
platform_driver_unregister(&owl_uart_platform_driver);
uart_unregister_driver(&owl_uart_driver);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC PATCH V3 4/5] platform: mtk-isp: Add Mediatek DIP driver
From: Tomasz Figa @ 2019-09-10 4:04 UTC (permalink / raw)
To: Frederic Chen (陳俊元)
Cc: Shik Chen, devicetree, Sean Cheng (鄭昇弘),
Laurent Pinchart, Rynn Wu (吳育恩),
Christie Yu (游雅惠), srv_heupstream,
Allan Yang (楊智鈞),
Holmes Chiou (邱挺), suleiman, Jerry-ch Chen,
Jungo Lin (林明俊), Sj Huang, yuzhao,
Hans Verkuil, zwisler, Matthias Brugger,
moderated list:ARM/Mediatek SoC support, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
In-Reply-To: <20190909192244.9367-5-frederic.chen@mediatek.com>
Hi Frederic,
On Tue, Sep 10, 2019 at 4:23 AM <frederic.chen@mediatek.com> wrote:
>
> From: Frederic Chen <frederic.chen@mediatek.com>
>
> This patch adds the driver of Digital Image Processing (DIP)
> unit in Mediatek ISP system, providing image format
> conversion, resizing, and rotation features.
>
> The mtk-isp directory will contain drivers for multiple IP
> blocks found in Mediatek ISP system. It will include ISP
> Pass 1 driver(CAM), sensor interface driver, DIP driver and
> face detection driver.
>
> Signed-off-by: Frederic Chen <frederic.chen@mediatek.com>
> ---
> drivers/media/platform/mtk-isp/Makefile | 7 +
> .../media/platform/mtk-isp/isp_50/Makefile | 7 +
> .../platform/mtk-isp/isp_50/dip/Makefile | 18 +
> .../platform/mtk-isp/isp_50/dip/mtk_dip-dev.c | 650 +++++
> .../platform/mtk-isp/isp_50/dip/mtk_dip-dev.h | 566 +++++
> .../platform/mtk-isp/isp_50/dip/mtk_dip-hw.h | 156 ++
> .../platform/mtk-isp/isp_50/dip/mtk_dip-sys.c | 521 ++++
> .../mtk-isp/isp_50/dip/mtk_dip-v4l2.c | 2255 +++++++++++++++++
> 8 files changed, 4180 insertions(+)
> create mode 100644 drivers/media/platform/mtk-isp/Makefile
> create mode 100644 drivers/media/platform/mtk-isp/isp_50/Makefile
> create mode 100644 drivers/media/platform/mtk-isp/isp_50/dip/Makefile
> create mode 100644 drivers/media/platform/mtk-isp/isp_50/dip/mtk_dip-dev.c
> create mode 100644 drivers/media/platform/mtk-isp/isp_50/dip/mtk_dip-dev.h
> create mode 100644 drivers/media/platform/mtk-isp/isp_50/dip/mtk_dip-hw.h
> create mode 100644 drivers/media/platform/mtk-isp/isp_50/dip/mtk_dip-sys.c
> create mode 100644 drivers/media/platform/mtk-isp/isp_50/dip/mtk_dip-v4l2.c
>
Thanks for sending v3!
I'm going to do a full review a bit later, but please check one
comment about power handling below.
Other than that one comment, from a quick look, I think we only have a
number of style issues left. Thanks for the hard work!
[snip]
> +static void dip_runner_func(struct work_struct *work)
> +{
> + struct mtk_dip_request *req = mtk_dip_hw_mdp_work_to_req(work);
> + struct mtk_dip_dev *dip_dev = req->dip_pipe->dip_dev;
> + struct img_config *config_data =
> + (struct img_config *)req->working_buf->config_data.vaddr;
> +
> + /*
> + * Call MDP/GCE API to do HW excecution
> + * Pass the framejob to MDP driver
> + */
> + pm_runtime_get_sync(dip_dev->dev);
> + mdp_cmdq_sendtask(dip_dev->mdp_pdev, config_data,
> + &req->img_fparam.frameparam, NULL, false,
> + dip_mdp_cb_func, req);
> +}
[snip]
> +static void dip_composer_workfunc(struct work_struct *work)
> +{
> + struct mtk_dip_request *req = mtk_dip_hw_fw_work_to_req(work);
> + struct mtk_dip_dev *dip_dev = req->dip_pipe->dip_dev;
> + struct img_ipi_param ipi_param;
> + struct mtk_dip_hw_subframe *buf;
> + int ret;
> +
> + down(&dip_dev->sem);
> +
> + buf = mtk_dip_hw_working_buf_alloc(req->dip_pipe->dip_dev);
> + if (!buf) {
> + dev_err(req->dip_pipe->dip_dev->dev,
> + "%s:%s:req(%p): no free working buffer available\n",
> + __func__, req->dip_pipe->desc->name, req);
> + }
> +
> + req->working_buf = buf;
> + mtk_dip_wbuf_to_ipi_img_addr(&req->img_fparam.frameparam.subfrm_data,
> + &buf->buffer);
> + memset(buf->buffer.vaddr, 0, DIP_SUB_FRM_SZ);
> + mtk_dip_wbuf_to_ipi_img_sw_addr(&req->img_fparam.frameparam.config_data,
> + &buf->config_data);
> + memset(buf->config_data.vaddr, 0, DIP_COMP_SZ);
> +
> + if (!req->img_fparam.frameparam.tuning_data.present) {
> + /*
> + * When user enqueued without tuning buffer,
> + * it would use driver internal buffer.
> + */
> + dev_dbg(dip_dev->dev,
> + "%s: frame_no(%d) has no tuning_data\n",
> + __func__, req->img_fparam.frameparam.frame_no);
> +
> + mtk_dip_wbuf_to_ipi_tuning_addr
> + (&req->img_fparam.frameparam.tuning_data,
> + &buf->tuning_buf);
> + memset(buf->tuning_buf.vaddr, 0, DIP_TUNING_SZ);
> + }
> +
> + mtk_dip_wbuf_to_ipi_img_sw_addr(&req->img_fparam.frameparam.self_data,
> + &buf->frameparam);
> + memcpy(buf->frameparam.vaddr, &req->img_fparam.frameparam,
> + sizeof(req->img_fparam.frameparam));
> + ipi_param.usage = IMG_IPI_FRAME;
> + ipi_param.frm_param.handle = req->id;
> + ipi_param.frm_param.scp_addr = (u32)buf->frameparam.scp_daddr;
> +
> + mutex_lock(&dip_dev->hw_op_lock);
> + atomic_inc(&dip_dev->num_composing);
> + ret = scp_ipi_send(dip_dev->scp_pdev, SCP_IPI_DIP, &ipi_param,
> + sizeof(ipi_param), 0);
We're not holding the pm_runtime enable count here
(pm_runtime_get_sync() wasn't called), so rproc_shutdown() might have
been called. Wouldn't that affect the ability for this IPI to run?
We had a related discussion with Jerry on the FD series and I think
the conclusion is:
a) if there is any state that needs to be preserved between jobs, that
would be cleared by rproc_shutdown() then we need to call
rproc_boot/shutdown() when we start/stop streaming.
b) it there is no such state, we can keep them inside runtime PM
callbacks, but we need to call pm_runtime_get_sync() before sending an
IPI and pm_runtime_mark_last_busy() + pm_runtime_put_autosuspend()
after the SCP signals completion. In this case the runtime PM
autosuspend delay should be set to around 2-3 times the delay needed
for rproc_shutdown() + rproc_boot() to complete.
Best regards,
Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] tty: serial: rda: Fix the link time qualifier of 'rda_uart_exit()'
From: Christophe JAILLET @ 2019-09-10 4:17 UTC (permalink / raw)
To: manivannan.sadhasivam, gregkh, jslaby
Cc: kernel-janitors, linux-kernel, linux-unisoc, Christophe JAILLET,
linux-serial, linux-arm-kernel
'exit' functions should be marked as __exit, not __init.
Fixes: c10b13325ced ("tty: serial: Add RDA8810PL UART driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/tty/serial/rda-uart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/rda-uart.c b/drivers/tty/serial/rda-uart.c
index c1b0d7662ef9..ff9a27d48bca 100644
--- a/drivers/tty/serial/rda-uart.c
+++ b/drivers/tty/serial/rda-uart.c
@@ -815,7 +815,7 @@ static int __init rda_uart_init(void)
return ret;
}
-static void __init rda_uart_exit(void)
+static void __exit rda_uart_exit(void)
{
platform_driver_unregister(&rda_uart_platform_driver);
uart_unregister_driver(&rda_uart_driver);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/1] mm/pgtable/debug: Add test validating architecture page table helpers
From: Christophe Leroy @ 2019-09-10 4:45 UTC (permalink / raw)
To: Anshuman Khandual, Kirill A. Shutemov
Cc: Mark Rutland, linux-ia64, linux-sh, Tetsuo Handa, James Hogan,
Heiko Carstens, Michal Hocko, linux-mm, Paul Mackerras,
sparclinux, Dan Williams, linux-s390, x86,
Russell King - ARM Linux, Matthew Wilcox, Steven Price,
Jason Gunthorpe, Gerald Schaefer, linux-snps-arc, Kees Cook,
Mark Brown, Thomas Gleixner, Vlastimil Babka, linux-arm-kernel,
Sri Krishna chowdary, Masahiro Yamada, Greg Kroah-Hartman,
Ard Biesheuvel, Dave Hansen, linux-mips, Ralf Baechle,
linux-kernel, Peter Zijlstra, Mike Rapoport, Paul Burton,
Vineet Gupta, Martin Schwidefsky, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <5883d41a-8299-1584-aa3d-fac89b3d9b5b@arm.com>
On 09/10/2019 03:56 AM, Anshuman Khandual wrote:
>
>
> On 09/09/2019 08:43 PM, Kirill A. Shutemov wrote:
>> On Mon, Sep 09, 2019 at 11:56:50AM +0530, Anshuman Khandual wrote:
>>>
>>>
>>> On 09/07/2019 12:33 AM, Gerald Schaefer wrote:
>>>> On Fri, 6 Sep 2019 11:58:59 +0530
>>>> Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>>>>
>>>>> On 09/05/2019 10:36 PM, Gerald Schaefer wrote:
>>>>>> On Thu, 5 Sep 2019 14:48:14 +0530
>>>>>> Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>>>>>>
>>>>>>>> [...]
>>>>>>>>> +
>>>>>>>>> +#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
>>>>>>>>> +static void pud_clear_tests(pud_t *pudp)
>>>>>>>>> +{
>>>>>>>>> + memset(pudp, RANDOM_NZVALUE, sizeof(pud_t));
>>>>>>>>> + pud_clear(pudp);
>>>>>>>>> + WARN_ON(!pud_none(READ_ONCE(*pudp)));
>>>>>>>>> +}
>>>>>>>>
>>>>>>>> For pgd/p4d/pud_clear(), we only clear if the page table level is present
>>>>>>>> and not folded. The memset() here overwrites the table type bits, so
>>>>>>>> pud_clear() will not clear anything on s390 and the pud_none() check will
>>>>>>>> fail.
>>>>>>>> Would it be possible to OR a (larger) random value into the table, so that
>>>>>>>> the lower 12 bits would be preserved?
>>>>>>>
>>>>>>> So the suggestion is instead of doing memset() on entry with RANDOM_NZVALUE,
>>>>>>> it should OR a large random value preserving lower 12 bits. Hmm, this should
>>>>>>> still do the trick for other platforms, they just need non zero value. So on
>>>>>>> s390, the lower 12 bits on the page table entry already has valid value while
>>>>>>> entering this function which would make sure that pud_clear() really does
>>>>>>> clear the entry ?
>>>>>>
>>>>>> Yes, in theory the table entry on s390 would have the type set in the last
>>>>>> 4 bits, so preserving those would be enough. If it does not conflict with
>>>>>> others, I would still suggest preserving all 12 bits since those would contain
>>>>>> arch-specific flags in general, just to be sure. For s390, the pte/pmd tests
>>>>>> would also work with the memset, but for consistency I think the same logic
>>>>>> should be used in all pxd_clear_tests.
>>>>>
>>>>> Makes sense but..
>>>>>
>>>>> There is a small challenge with this. Modifying individual bits on a given
>>>>> page table entry from generic code like this test case is bit tricky. That
>>>>> is because there are not enough helpers to create entries with an absolute
>>>>> value. This would have been easier if all the platforms provided functions
>>>>> like __pxx() which is not the case now. Otherwise something like this should
>>>>> have worked.
>>>>>
>>>>>
>>>>> pud_t pud = READ_ONCE(*pudp);
>>>>> pud = __pud(pud_val(pud) | RANDOM_VALUE (keeping lower 12 bits 0))
>>>>> WRITE_ONCE(*pudp, pud);
>>>>>
>>>>> But __pud() will fail to build in many platforms.
>>>>
>>>> Hmm, I simply used this on my system to make pud_clear_tests() work, not
>>>> sure if it works on all archs:
>>>>
>>>> pud_val(*pudp) |= RANDOM_NZVALUE;
>>>
>>> Which compiles on arm64 but then fails on x86 because of the way pmd_val()
>>> has been defined there.
>>
>> Use instead
>>
>> *pudp = __pud(pud_val(*pudp) | RANDOM_NZVALUE);
>
> Agreed.
>
> As I had mentioned before this would have been really the cleanest approach.
>
>>
>> It *should* be more portable.
>
> Not really, because not all the platforms have __pxx() definitions right now.
> Going with these will clearly cause build failures on affected platforms. Lets
> examine __pud() for instance. It is defined only on these platforms.
>
> arch/arm64/include/asm/pgtable-types.h: #define __pud(x) ((pud_t) { (x) } )
> arch/mips/include/asm/pgtable-64.h: #define __pud(x) ((pud_t) { (x) })
> arch/powerpc/include/asm/pgtable-be-types.h: #define __pud(x) ((pud_t) { cpu_to_be64(x) })
> arch/powerpc/include/asm/pgtable-types.h: #define __pud(x) ((pud_t) { (x) })
> arch/s390/include/asm/page.h: #define __pud(x) ((pud_t) { (x) } )
> arch/sparc/include/asm/page_64.h: #define __pud(x) ((pud_t) { (x) } )
> arch/sparc/include/asm/page_64.h: #define __pud(x) (x)
> arch/x86/include/asm/pgtable.h: #define __pud(x) native_make_pud(x)
You missed:
arch/x86/include/asm/paravirt.h:static inline pud_t __pud(pudval_t val)
include/asm-generic/pgtable-nop4d-hack.h:#define __pud(x)
((pud_t) { __pgd(x) })
include/asm-generic/pgtable-nopud.h:#define __pud(x)
((pud_t) { __p4d(x) })
>
> Similarly for __pmd()
>
> arch/alpha/include/asm/page.h: #define __pmd(x) ((pmd_t) { (x) } )
> arch/arm/include/asm/page-nommu.h: #define __pmd(x) (x)
> arch/arm/include/asm/pgtable-2level-types.h: #define __pmd(x) ((pmd_t) { (x) } )
> arch/arm/include/asm/pgtable-2level-types.h: #define __pmd(x) (x)
> arch/arm/include/asm/pgtable-3level-types.h: #define __pmd(x) ((pmd_t) { (x) } )
> arch/arm/include/asm/pgtable-3level-types.h: #define __pmd(x) (x)
> arch/arm64/include/asm/pgtable-types.h: #define __pmd(x) ((pmd_t) { (x) } )
> arch/m68k/include/asm/page.h: #define __pmd(x) ((pmd_t) { { (x) }, })
> arch/mips/include/asm/pgtable-64.h: #define __pmd(x) ((pmd_t) { (x) } )
> arch/nds32/include/asm/page.h: #define __pmd(x) (x)
> arch/parisc/include/asm/page.h: #define __pmd(x) ((pmd_t) { (x) } )
> arch/parisc/include/asm/page.h: #define __pmd(x) (x)
> arch/powerpc/include/asm/pgtable-be-types.h: #define __pmd(x) ((pmd_t) { cpu_to_be64(x) })
> arch/powerpc/include/asm/pgtable-types.h: #define __pmd(x) ((pmd_t) { (x) })
> arch/riscv/include/asm/pgtable-64.h: #define __pmd(x) ((pmd_t) { (x) })
> arch/s390/include/asm/page.h: #define __pmd(x) ((pmd_t) { (x) } )
> arch/sh/include/asm/pgtable-3level.h: #define __pmd(x) ((pmd_t) { (x) } )
> arch/sparc/include/asm/page_32.h: #define __pmd(x) ((pmd_t) { { (x) }, })
> arch/sparc/include/asm/page_32.h: #define __pmd(x) ((pmd_t) { { (x) }, })
> arch/sparc/include/asm/page_64.h: #define __pmd(x) ((pmd_t) { (x) } )
> arch/sparc/include/asm/page_64.h: #define __pmd(x) (x)
> arch/um/include/asm/page.h: #define __pmd(x) ((pmd_t) { (x) } )
> arch/um/include/asm/page.h: #define __pmd(x) ((pmd_t) { (x) } )
> arch/x86/include/asm/pgtable.h: #define __pmd(x) native_make_pmd(x)
You missed:
arch/x86/include/asm/paravirt.h:static inline pmd_t __pmd(pmdval_t val)
include/asm-generic/page.h:#define __pmd(x) ((pmd_t) { (x) } )
include/asm-generic/pgtable-nopmd.h:#define __pmd(x)
((pmd_t) { __pud(x) } )
>
> Similarly for __pgd()
>
> arch/alpha/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
> arch/alpha/include/asm/page.h: #define __pgd(x) (x)
> arch/arc/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
> arch/arc/include/asm/page.h: #define __pgd(x) (x)
> arch/arm/include/asm/pgtable-3level-types.h: #define __pgd(x) ((pgd_t) { (x) } )
> arch/arm/include/asm/pgtable-3level-types.h: #define __pgd(x) (x)
> arch/arm64/include/asm/pgtable-types.h: #define __pgd(x) ((pgd_t) { (x) } )
> arch/csky/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
> arch/hexagon/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
> arch/m68k/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
> arch/mips/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
> arch/nds32/include/asm/page.h: #define __pgd(x) (x)
> arch/nios2/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
> arch/openrisc/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
> arch/parisc/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
> arch/parisc/include/asm/page.h: #define __pgd(x) (x)
> arch/powerpc/include/asm/pgtable-be-types.h: #define __pgd(x) ((pgd_t) { cpu_to_be64(x) })
> arch/powerpc/include/asm/pgtable-types.h: #define __pgd(x) ((pgd_t) { (x) })
> arch/riscv/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
> arch/s390/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
> arch/sh/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
> arch/sparc/include/asm/page_32.h: #define __pgd(x) ((pgd_t) { (x) } )
> arch/sparc/include/asm/page_32.h: #define __pgd(x) (x)
> arch/sparc/include/asm/page_64.h: #define __pgd(x) ((pgd_t) { (x) } )
> arch/sparc/include/asm/page_64.h: #define __pgd(x) (x)
> arch/um/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
> arch/unicore32/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
> arch/unicore32/include/asm/page.h: #define __pgd(x) (x)
> arch/x86/include/asm/pgtable.h: #define __pgd(x) native_make_pgd(x)
> arch/xtensa/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
You missed:
arch/x86/include/asm/paravirt.h:static inline pgd_t __pgd(pgdval_t val)
include/asm-generic/page.h:#define __pgd(x) ((pgd_t) { (x) } )
>
> Similarly for __p4d()
>
> arch/s390/include/asm/page.h: #define __p4d(x) ((p4d_t) { (x) } )
> arch/x86/include/asm/pgtable.h: #define __p4d(x) native_make_p4d(x)
You missed:
arch/x86/include/asm/paravirt.h:static inline p4d_t __p4d(p4dval_t val)
include/asm-generic/5level-fixup.h:#define __p4d(x)
__pgd(x)
include/asm-generic/pgtable-nop4d.h:#define __p4d(x)
((p4d_t) { __pgd(x) })
>
> The search pattern here has been "#define __pxx(". Unless I am missing something,
> I dont see how we can use these without risking build failures.
>
I guess you missed that arches not defining them fall back on the
definitions in include/asm-generic
Christophe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] mm/pgtable/debug: Add test validating architecture page table helpers
From: Anshuman Khandual @ 2019-09-10 5:43 UTC (permalink / raw)
To: Christophe Leroy, Kirill A. Shutemov
Cc: Mark Rutland, linux-ia64, linux-sh, Tetsuo Handa, James Hogan,
Heiko Carstens, Michal Hocko, linux-mm, Paul Mackerras,
sparclinux, Dan Williams, linux-s390, x86,
Russell King - ARM Linux, Matthew Wilcox, Steven Price,
Jason Gunthorpe, Gerald Schaefer, linux-snps-arc, Kees Cook,
Mark Brown, Thomas Gleixner, Vlastimil Babka, linux-arm-kernel,
Sri Krishna chowdary, Masahiro Yamada, Greg Kroah-Hartman,
Ard Biesheuvel, Dave Hansen, linux-mips, Ralf Baechle,
linux-kernel, Peter Zijlstra, Mike Rapoport, Paul Burton,
Vineet Gupta, Martin Schwidefsky, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <94029d96-47c4-3020-57a8-4e03de1b4fc8@c-s.fr>
On 09/10/2019 10:15 AM, Christophe Leroy wrote:
>
>
> On 09/10/2019 03:56 AM, Anshuman Khandual wrote:
>>
>>
>> On 09/09/2019 08:43 PM, Kirill A. Shutemov wrote:
>>> On Mon, Sep 09, 2019 at 11:56:50AM +0530, Anshuman Khandual wrote:
>>>>
>>>>
>>>> On 09/07/2019 12:33 AM, Gerald Schaefer wrote:
>>>>> On Fri, 6 Sep 2019 11:58:59 +0530
>>>>> Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>>>>>
>>>>>> On 09/05/2019 10:36 PM, Gerald Schaefer wrote:
>>>>>>> On Thu, 5 Sep 2019 14:48:14 +0530
>>>>>>> Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>>>>>>>
>>>>>>>>> [...]
>>>>>>>>>> +
>>>>>>>>>> +#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
>>>>>>>>>> +static void pud_clear_tests(pud_t *pudp)
>>>>>>>>>> +{
>>>>>>>>>> + memset(pudp, RANDOM_NZVALUE, sizeof(pud_t));
>>>>>>>>>> + pud_clear(pudp);
>>>>>>>>>> + WARN_ON(!pud_none(READ_ONCE(*pudp)));
>>>>>>>>>> +}
>>>>>>>>>
>>>>>>>>> For pgd/p4d/pud_clear(), we only clear if the page table level is present
>>>>>>>>> and not folded. The memset() here overwrites the table type bits, so
>>>>>>>>> pud_clear() will not clear anything on s390 and the pud_none() check will
>>>>>>>>> fail.
>>>>>>>>> Would it be possible to OR a (larger) random value into the table, so that
>>>>>>>>> the lower 12 bits would be preserved?
>>>>>>>>
>>>>>>>> So the suggestion is instead of doing memset() on entry with RANDOM_NZVALUE,
>>>>>>>> it should OR a large random value preserving lower 12 bits. Hmm, this should
>>>>>>>> still do the trick for other platforms, they just need non zero value. So on
>>>>>>>> s390, the lower 12 bits on the page table entry already has valid value while
>>>>>>>> entering this function which would make sure that pud_clear() really does
>>>>>>>> clear the entry ?
>>>>>>>
>>>>>>> Yes, in theory the table entry on s390 would have the type set in the last
>>>>>>> 4 bits, so preserving those would be enough. If it does not conflict with
>>>>>>> others, I would still suggest preserving all 12 bits since those would contain
>>>>>>> arch-specific flags in general, just to be sure. For s390, the pte/pmd tests
>>>>>>> would also work with the memset, but for consistency I think the same logic
>>>>>>> should be used in all pxd_clear_tests.
>>>>>>
>>>>>> Makes sense but..
>>>>>>
>>>>>> There is a small challenge with this. Modifying individual bits on a given
>>>>>> page table entry from generic code like this test case is bit tricky. That
>>>>>> is because there are not enough helpers to create entries with an absolute
>>>>>> value. This would have been easier if all the platforms provided functions
>>>>>> like __pxx() which is not the case now. Otherwise something like this should
>>>>>> have worked.
>>>>>>
>>>>>>
>>>>>> pud_t pud = READ_ONCE(*pudp);
>>>>>> pud = __pud(pud_val(pud) | RANDOM_VALUE (keeping lower 12 bits 0))
>>>>>> WRITE_ONCE(*pudp, pud);
>>>>>>
>>>>>> But __pud() will fail to build in many platforms.
>>>>>
>>>>> Hmm, I simply used this on my system to make pud_clear_tests() work, not
>>>>> sure if it works on all archs:
>>>>>
>>>>> pud_val(*pudp) |= RANDOM_NZVALUE;
>>>>
>>>> Which compiles on arm64 but then fails on x86 because of the way pmd_val()
>>>> has been defined there.
>>>
>>> Use instead
>>>
>>> *pudp = __pud(pud_val(*pudp) | RANDOM_NZVALUE);
>>
>> Agreed.
>>
>> As I had mentioned before this would have been really the cleanest approach.
>>
>>>
>>> It *should* be more portable.
>>
>> Not really, because not all the platforms have __pxx() definitions right now.
>> Going with these will clearly cause build failures on affected platforms. Lets
>> examine __pud() for instance. It is defined only on these platforms.
>>
>> arch/arm64/include/asm/pgtable-types.h: #define __pud(x) ((pud_t) { (x) } )
>> arch/mips/include/asm/pgtable-64.h: #define __pud(x) ((pud_t) { (x) })
>> arch/powerpc/include/asm/pgtable-be-types.h: #define __pud(x) ((pud_t) { cpu_to_be64(x) })
>> arch/powerpc/include/asm/pgtable-types.h: #define __pud(x) ((pud_t) { (x) })
>> arch/s390/include/asm/page.h: #define __pud(x) ((pud_t) { (x) } )
>> arch/sparc/include/asm/page_64.h: #define __pud(x) ((pud_t) { (x) } )
>> arch/sparc/include/asm/page_64.h: #define __pud(x) (x)
>> arch/x86/include/asm/pgtable.h: #define __pud(x) native_make_pud(x)
>
> You missed:
> arch/x86/include/asm/paravirt.h:static inline pud_t __pud(pudval_t val)
> include/asm-generic/pgtable-nop4d-hack.h:#define __pud(x) ((pud_t) { __pgd(x) })
> include/asm-generic/pgtable-nopud.h:#define __pud(x) ((pud_t) { __p4d(x) })
>
>>
>> Similarly for __pmd()
>>
>> arch/alpha/include/asm/page.h: #define __pmd(x) ((pmd_t) { (x) } )
>> arch/arm/include/asm/page-nommu.h: #define __pmd(x) (x)
>> arch/arm/include/asm/pgtable-2level-types.h: #define __pmd(x) ((pmd_t) { (x) } )
>> arch/arm/include/asm/pgtable-2level-types.h: #define __pmd(x) (x)
>> arch/arm/include/asm/pgtable-3level-types.h: #define __pmd(x) ((pmd_t) { (x) } )
>> arch/arm/include/asm/pgtable-3level-types.h: #define __pmd(x) (x)
>> arch/arm64/include/asm/pgtable-types.h: #define __pmd(x) ((pmd_t) { (x) } )
>> arch/m68k/include/asm/page.h: #define __pmd(x) ((pmd_t) { { (x) }, })
>> arch/mips/include/asm/pgtable-64.h: #define __pmd(x) ((pmd_t) { (x) } )
>> arch/nds32/include/asm/page.h: #define __pmd(x) (x)
>> arch/parisc/include/asm/page.h: #define __pmd(x) ((pmd_t) { (x) } )
>> arch/parisc/include/asm/page.h: #define __pmd(x) (x)
>> arch/powerpc/include/asm/pgtable-be-types.h: #define __pmd(x) ((pmd_t) { cpu_to_be64(x) })
>> arch/powerpc/include/asm/pgtable-types.h: #define __pmd(x) ((pmd_t) { (x) })
>> arch/riscv/include/asm/pgtable-64.h: #define __pmd(x) ((pmd_t) { (x) })
>> arch/s390/include/asm/page.h: #define __pmd(x) ((pmd_t) { (x) } )
>> arch/sh/include/asm/pgtable-3level.h: #define __pmd(x) ((pmd_t) { (x) } )
>> arch/sparc/include/asm/page_32.h: #define __pmd(x) ((pmd_t) { { (x) }, })
>> arch/sparc/include/asm/page_32.h: #define __pmd(x) ((pmd_t) { { (x) }, })
>> arch/sparc/include/asm/page_64.h: #define __pmd(x) ((pmd_t) { (x) } )
>> arch/sparc/include/asm/page_64.h: #define __pmd(x) (x)
>> arch/um/include/asm/page.h: #define __pmd(x) ((pmd_t) { (x) } )
>> arch/um/include/asm/page.h: #define __pmd(x) ((pmd_t) { (x) } )
>> arch/x86/include/asm/pgtable.h: #define __pmd(x) native_make_pmd(x)
>
> You missed:
> arch/x86/include/asm/paravirt.h:static inline pmd_t __pmd(pmdval_t val)
> include/asm-generic/page.h:#define __pmd(x) ((pmd_t) { (x) } )
> include/asm-generic/pgtable-nopmd.h:#define __pmd(x) ((pmd_t) { __pud(x) } )
>
>
>>
>> Similarly for __pgd()
>>
>> arch/alpha/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
>> arch/alpha/include/asm/page.h: #define __pgd(x) (x)
>> arch/arc/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
>> arch/arc/include/asm/page.h: #define __pgd(x) (x)
>> arch/arm/include/asm/pgtable-3level-types.h: #define __pgd(x) ((pgd_t) { (x) } )
>> arch/arm/include/asm/pgtable-3level-types.h: #define __pgd(x) (x)
>> arch/arm64/include/asm/pgtable-types.h: #define __pgd(x) ((pgd_t) { (x) } )
>> arch/csky/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
>> arch/hexagon/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
>> arch/m68k/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
>> arch/mips/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
>> arch/nds32/include/asm/page.h: #define __pgd(x) (x)
>> arch/nios2/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
>> arch/openrisc/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
>> arch/parisc/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
>> arch/parisc/include/asm/page.h: #define __pgd(x) (x)
>> arch/powerpc/include/asm/pgtable-be-types.h: #define __pgd(x) ((pgd_t) { cpu_to_be64(x) })
>> arch/powerpc/include/asm/pgtable-types.h: #define __pgd(x) ((pgd_t) { (x) })
>> arch/riscv/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
>> arch/s390/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
>> arch/sh/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
>> arch/sparc/include/asm/page_32.h: #define __pgd(x) ((pgd_t) { (x) } )
>> arch/sparc/include/asm/page_32.h: #define __pgd(x) (x)
>> arch/sparc/include/asm/page_64.h: #define __pgd(x) ((pgd_t) { (x) } )
>> arch/sparc/include/asm/page_64.h: #define __pgd(x) (x)
>> arch/um/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
>> arch/unicore32/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) })
>> arch/unicore32/include/asm/page.h: #define __pgd(x) (x)
>> arch/x86/include/asm/pgtable.h: #define __pgd(x) native_make_pgd(x)
>> arch/xtensa/include/asm/page.h: #define __pgd(x) ((pgd_t) { (x) } )
>
> You missed:
> arch/x86/include/asm/paravirt.h:static inline pgd_t __pgd(pgdval_t val)
> include/asm-generic/page.h:#define __pgd(x) ((pgd_t) { (x) } )
>
>
>>
>> Similarly for __p4d()
>>
>> arch/s390/include/asm/page.h: #define __p4d(x) ((p4d_t) { (x) } )
>> arch/x86/include/asm/pgtable.h: #define __p4d(x) native_make_p4d(x)
>
> You missed:
> arch/x86/include/asm/paravirt.h:static inline p4d_t __p4d(p4dval_t val)
> include/asm-generic/5level-fixup.h:#define __p4d(x) __pgd(x)
> include/asm-generic/pgtable-nop4d.h:#define __p4d(x) ((p4d_t) { __pgd(x) })
>
>
>>
>> The search pattern here has been "#define __pxx(". Unless I am missing something,
>> I dont see how we can use these without risking build failures.
>>
>
> I guess you missed that arches not defining them fall back on the definitions in include/asm-generic
You are right. I was confused whether these generic definitions were really
applicable for all those platforms as fallback (with so many page table
level folding combinations available) when they dont define. Sure will take
this approach and try to build them on multiple platforms.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] arm64: alpine: select AL_POS
From: Shenhar, Talel @ 2019-09-10 6:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, mjourdan, Catalin Marinas, Linus Walleij,
linux-kernel@vger.kernel.org, jonnyc, Mauro Carvalho Chehab,
ronenk, Will Deacon, Benjamin Herrenschmidt, DTML, Maxime Ripard,
Rob Herring, Santosh Shilimkar, Thomas Gleixner, hanochu,
Linux ARM, barakw, hhhawa, gregkh, paul.kocialkowski,
Patrick Venture, Olof Johansson, David Miller, David Woodhouse
In-Reply-To: <CAK8P3a0RUHxcpyUJU5bpd8nqpm0Sqhy4aJaoh7K9jVn8zJC6aQ@mail.gmail.com>
On 9/9/2019 6:08 PM, Arnd Bergmann wrote:
> On Mon, Sep 9, 2019 at 3:59 PM Shenhar, Talel <talel@amazon.com> wrote:
>> On 9/9/2019 4:45 PM, Arnd Bergmann wrote:
>>
>> Its not that something will get broken. its error event detector for POS
>> events which allows seeing bad accesses to registers.
>>
>> What is the general rule of which configs to put under select and which
>> under defconfig?
>>
>> I was thinking that "general" SoC support is good under select - those
>> things that we always want.
> I generally want as little as possible to be selected, basically only
> things that are required for linking the kernel and booting it without
> potentially destroying the hardware.
>
> In particular, I want most drivers to be enabled as loadable modules
> if possible. When you have general-purpose distributions support
> your platform, there is no need to have this module built-in while
> running on a different chip, even if you always want to load the
> module when it's running on yours.
>
>> And specific features, e.g. RAID support or features that supported only
>> on specific HW shall go under defconfig.
>>
>> Similar, I see ARCH_LAYERSCAPE selecting EDAC_SUPPORT.
> I think this was done to avoid a link failure. It's also possible that this
> is a mistake and just did not get caught in review.
>
> Arnd
I see.
Will remove this from v2.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 0/3] Add new binding regulator-fixed-clock to regulator-fixed
From: Philippe Schenker @ 2019-09-10 6:21 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, Mark Brown, Shawn Guo, Sascha Hauer,
Liam Girdwood
Cc: Mark Rutland, devicetree@vger.kernel.org, Luka Pivk, Stefan Agner,
Marcel Ziswiler, Philippe Schenker, Rob Herring, NXP Linux Team,
Max Krummenacher, Fabio Estevam, Pengutronix Kernel Team,
linux-arm-kernel@lists.infradead.org
Our hardware has a FET that is switching power rail of the ethernet PHY
on and off. This switching enable signal is a clock from the SoC.
There is no possibility in regulator subsystem to have this hardware
reflected in software.
I already discussed with Mark Brown about possible solutions and he
suggested to create at least a new compatible. [1]
This discussion includes also a better explanation of our circuit as
well as schematics. So please refer to that link if you have questions
about that.
In this first attempt I created a new binding "regulator-fixed-clock"
that can take a clock from devicetree. This is a simple addition to
regulator-fixed. If the binding regulator-fixed-clock is given, the
clock is simply enabled on regulator enable and disabled on regulator
disable.
To be able to have multiple consumers a counter variable is also given
that tells how many consumers need power from this regulator.
Best regards,
Philippe
[1] https://lkml.org/lkml/2019/8/7/78
Changes in v2:
- return priv->clk_enable_counter > 0 directly.
- Change select: to if:
- Change items: to enum:
- Defined how many clocks should be given
Philippe Schenker (3):
regulator: fixed: add possibility to enable by clock
ARM: dts: imx6ull-colibri: add phy-supply and respective regulator
dt-bindings: regulator: add regulator-fixed-clock binding
.../bindings/regulator/fixed-regulator.yaml | 19 ++++-
arch/arm/boot/dts/imx6ull-colibri.dtsi | 12 +++
drivers/regulator/fixed.c | 83 ++++++++++++++++++-
3 files changed, 110 insertions(+), 4 deletions(-)
--
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
* [PATCH v2 2/3] ARM: dts: imx6ull-colibri: add phy-supply and respective regulator
From: Philippe Schenker @ 2019-09-10 6:21 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, Mark Brown, Shawn Guo, Sascha Hauer,
Liam Girdwood
Cc: Mark Rutland, devicetree@vger.kernel.org, Luka Pivk, Stefan Agner,
Marcel Ziswiler, Philippe Schenker, Rob Herring, NXP Linux Team,
Max Krummenacher, Fabio Estevam, Pengutronix Kernel Team,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190910062103.39641-1-philippe.schenker@toradex.com>
This adds regulator-fixed-clock, a fixed-regulator that turns on and
off with a clock and add it to the phy.
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
---
Changes in v2: None
arch/arm/boot/dts/imx6ull-colibri.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ull-colibri.dtsi b/arch/arm/boot/dts/imx6ull-colibri.dtsi
index d56728f03c35..76021b842a97 100644
--- a/arch/arm/boot/dts/imx6ull-colibri.dtsi
+++ b/arch/arm/boot/dts/imx6ull-colibri.dtsi
@@ -47,6 +47,17 @@
states = <1800000 0x1 3300000 0x0>;
vin-supply = <®_module_3v3>;
};
+
+ reg_eth_phy: regulator-eth-phy {
+ compatible = "regulator-fixed-clock";
+ regulator-boot-on;
+ regulator-name = "eth_phy";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ clocks = <&clks IMX6UL_CLK_ENET2_REF_125M>;
+ startup-delay-us = <150000>;
+ vin-supply = <®_module_3v3>;
+ };
};
&adc1 {
@@ -66,6 +77,7 @@
pinctrl-0 = <&pinctrl_enet2>;
phy-mode = "rmii";
phy-handle = <ðphy1>;
+ phy-supply = <®_eth_phy>;
status = "okay";
mdio {
--
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/3] soc: amazon: al-pos: Introduce Amazon's Annapurna Labs POS driver
From: Shenhar, Talel @ 2019-09-10 6:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, mjourdan, Catalin Marinas, Linus Walleij,
linux-kernel@vger.kernel.org, jonnyc, Mauro Carvalho Chehab,
ronenk, Will Deacon, Benjamin Herrenschmidt, DTML, Maxime Ripard,
Rob Herring, Santosh Shilimkar, Thomas Gleixner, hanochu,
Linux ARM, barakw, hhhawa, gregkh, paul.kocialkowski,
Patrick Venture, Olof Johansson, David Miller, David Woodhouse
In-Reply-To: <CAK8P3a1fbK-qoK+K1ZsWsU3rkxxZgZGaK8ywFAcM4va1GRn_FQ@mail.gmail.com>
On 9/9/2019 6:16 PM, Arnd Bergmann wrote:
> On Mon, Sep 9, 2019 at 4:11 PM Shenhar, Talel <talel@amazon.com> wrote:
>> On 9/9/2019 4:41 PM, Arnd Bergmann wrote:
>>
>> In current implementation of v1, I am not doing any read barrier, Hence,
>> using the non-relaxed will add unneeded memory barrier.
>>
>> I have no strong objection moving to the non-relaxed version and have an
>> unneeded memory barrier, as this path is not "hot" one.
> Ok, then please add it.
ok, shall be part of v2
>
>> Beside of avoiding the unneeded memory barrier, I would be happy to keep
>> common behavior for our drivers:
>>
>> e.g.
>>
>> https://github.com/torvalds/linux/blob/master/drivers/irqchip/irq-al-fic.c#L49
>>
>>
>> So what do you think we should go with? relaxed or non-relaxed?
> The al_fic_set_trigger() function is clearly a slow-path and should use the
> non-relaxed functions. In case of al_fic_irq_handler(), the extra barrier
> might introduce a measurable overhead, but at the same time I'm
> not sure if that one is correct without the barrier:
>
> If you have an MSI-type interrupt for notifying a device driver of
> a DMA completion, there might not be any other barrier between
> the arrival of the MSI message and the CPU accessing the data.
> Depending on how strict the hardware implements MSI and how
> the IRQ is chained, this could lead to data corruption.
>
> If the interrupt is only used for level or edge triggered interrupts,
> this is ok since you already need another register read in
> the driver before it can safely access a DMA buffer.
>
> In either case, if you can prove that it's safe to use the relaxed
> version here and you think that it may help, it would be good to
> add a comment explaining the reasoning.
Decided to go with the non-relaxed version as this is not hot path and
likely be more clear to the common reader to have non relaxed version.
>
> Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] coresight: etm4x: Add support for ThunderX2
From: Tanmay Vilas Kumar Jagdale @ 2019-09-10 6:25 UTC (permalink / raw)
To: mathieu.poirier@linaro.org
Cc: Ganapatrao Kulkarni, Tomasz Nowicki, suzuki.poulose@arm.com,
Jayachandran Chandrasekharan Nair, Tanmay Vilas Kumar Jagdale,
linux-arm-kernel@lists.infradead.org
Add ETMv4 periperhal ID for Marvell's ThunderX2 chip.
This chip contains ETMv4.1 version.
Signed-off-by: Tanmay Jagdale <tanmay@marvell.com>
---
Changes since v1:
- Updated commit message.
- Use UCI to identify ETMv4.
- Remove addition of ETMv4.1 version checks.
drivers/hwtracing/coresight/coresight-etm4x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index a128b5063f46..47839b4a8bc0 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -1211,6 +1211,7 @@ static const struct amba_id etm4_ids[] = {
CS_AMBA_UCI_ID(0x000f0211, uci_id_etm4),/* Qualcomm Kryo */
CS_AMBA_ID(0x000bb802), /* Qualcomm Kryo 385 Cortex-A55 */
CS_AMBA_ID(0x000bb803), /* Qualcomm Kryo 385 Cortex-A75 */
+ CS_AMBA_UCI_ID(0x000cc0af, uci_id_etm4),/* Marvell ThunderX2 */
{},
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v12 11/12] open: openat2(2) syscall
From: Ingo Molnar @ 2019-09-10 6:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-ia64, Linux-sh list, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, Linux List Kernel Mailing, David Howells,
open list:KERNEL SELFTEST FRAMEWORK, sparclinux, Shuah Khan,
linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai, Jiri Olsa,
Alexander Shishkin, Ingo Molnar, Linux ARM, linux-mips,
linux-xtensa, Kees Cook, Arnd Bergmann, Jann Horn, Aleksa Sarai,
Al Viro, Andy Lutomirski, Shuah Khan, Namhyung Kim,
David Drysdale, Christian Brauner, J. Bruce Fields, linux-parisc,
linux-m68k, Linux API, Chanho Min, Jeff Layton, Oleg Nesterov,
Andy Lutomirski, Eric Biederman, alpha, linux-fsdevel,
Andrew Morton, linuxppc-dev, Linux Containers
In-Reply-To: <CAHk-=whe90Ec_RRrMRLE0=bJOHNS9YmVwcytVxmrfK3oCuZF6A@mail.gmail.com>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Sat, Sep 7, 2019 at 10:42 AM Andy Lutomirski <luto@amacapital.net> wrote:
> >
> > Linus, you rejected resolveat() because you wanted a *nice* API
>
> No. I rejected resoveat() because it was a completely broken garbage
> API that couldn't do even basic stuff right (like O_CREAT).
>
> We have a ton of flag space in the new openat2() model, we might as
> well leave the old flags alone that people are (a) used to and (b) we
> have code to support _anyway_.
>
> Making up a new flag namespace is only going to cause us - and users -
> more work, and more confusion. For no actual advantage. It's not going
> to be "cleaner". It's just going to be worse.
I suspect there is a "add a clean new flags namespace" analogy to the
classic "add a clean new standard" XKCD:
https://xkcd.com/927/
Thanks,
Ingo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v7 1/7] dt-bindings: rtc: mediatek: add missing mt6397 rtc
From: Frank Wunderlich @ 2019-09-10 7:04 UTC (permalink / raw)
To: linux-mediatek
Cc: linux-rtc, devicetree, Alexandre Belloni, Sean Wang,
Alessandro Zummo, linux-pm, Frank Wunderlich, Josef Friedl,
linux-kernel, Tianping Fang, Rob Herring, Sebastian Reichel,
Matthias Brugger, Mark Rutland, Eddie Huang, Lee Jones,
linux-arm-kernel
In-Reply-To: <20190910070446.639-1-frank-w@public-files.de>
From: Josef Friedl <josef.friedl@speed.at>
add missing devicetree-binding document for mt6397 rtc
in later patch driver is extended with mt6323 chip
Suggested-By: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Reviewed-by: Rob Herring <robh@kernel.org>
---
changes since v6: none
changes since v5: none
changes since v4: use relative path
changes since v3: moved SOB
changes since v2: splitted rtc-mt6397.txt from first patch
---
.../devicetree/bindings/rtc/rtc-mt6397.txt | 29 +++++++++++++++++++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mt6397.txt
diff --git a/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt b/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt
new file mode 100644
index 000000000000..55a0c8874c03
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt
@@ -0,0 +1,29 @@
+Device-Tree bindings for MediaTek PMIC based RTC
+
+MediaTek PMIC based RTC is an independent function of MediaTek PMIC that works
+as a type of multi-function device (MFD). The RTC can be configured and set up
+with PMIC wrapper bus which is a common resource shared with the other
+functions found on the same PMIC.
+
+For MediaTek PMIC MFD bindings, see:
+../mfd/mt6397.txt
+
+For MediaTek PMIC wrapper bus bindings, see:
+../soc/mediatek/pwrap.txt
+
+Required properties:
+- compatible: Should be one of follows
+ "mediatek,mt6323-rtc": for MT6323 PMIC
+ "mediatek,mt6397-rtc": for MT6397 PMIC
+
+Example:
+
+ pmic {
+ compatible = "mediatek,mt6323";
+
+ ...
+
+ rtc {
+ compatible = "mediatek,mt6323-rtc";
+ };
+ };
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v7 2/7] rtc: mt6397: move some common definitions into rtc.h
From: Frank Wunderlich @ 2019-09-10 7:04 UTC (permalink / raw)
To: linux-mediatek
Cc: linux-rtc, devicetree, Alexandre Belloni, Sean Wang,
Alessandro Zummo, linux-pm, Frank Wunderlich, Josef Friedl,
linux-kernel, Tianping Fang, Rob Herring, Sebastian Reichel,
Matthias Brugger, Mark Rutland, Eddie Huang, Lee Jones,
linux-arm-kernel
In-Reply-To: <20190910070446.639-1-frank-w@public-files.de>
From: Josef Friedl <josef.friedl@speed.at>
move code to separate header-file to reuse definitions later
in poweroff-driver (drivers/power/reset/mt6323-poweroff.c)
Suggested-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
---
changes since v6: updated copyright
changes since v5: none
changes since v4: none
changes since v3: none
changes since v2: add missing commit-message
---
drivers/rtc/rtc-mt6397.c | 55 +-------------------------
include/linux/mfd/mt6397/rtc.h | 71 ++++++++++++++++++++++++++++++++++
2 files changed, 72 insertions(+), 54 deletions(-)
create mode 100644 include/linux/mfd/mt6397/rtc.h
diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
index b46ed4dc7015..c08ee5edf865 100644
--- a/drivers/rtc/rtc-mt6397.c
+++ b/drivers/rtc/rtc-mt6397.c
@@ -9,60 +9,7 @@
#include <linux/module.h>
#include <linux/regmap.h>
#include <linux/rtc.h>
-#include <linux/irqdomain.h>
-#include <linux/platform_device.h>
-#include <linux/of_address.h>
-#include <linux/of_irq.h>
-#include <linux/io.h>
-#include <linux/mfd/mt6397/core.h>
-
-#define RTC_BBPU 0x0000
-#define RTC_BBPU_CBUSY BIT(6)
-
-#define RTC_WRTGR 0x003c
-
-#define RTC_IRQ_STA 0x0002
-#define RTC_IRQ_STA_AL BIT(0)
-#define RTC_IRQ_STA_LP BIT(3)
-
-#define RTC_IRQ_EN 0x0004
-#define RTC_IRQ_EN_AL BIT(0)
-#define RTC_IRQ_EN_ONESHOT BIT(2)
-#define RTC_IRQ_EN_LP BIT(3)
-#define RTC_IRQ_EN_ONESHOT_AL (RTC_IRQ_EN_ONESHOT | RTC_IRQ_EN_AL)
-
-#define RTC_AL_MASK 0x0008
-#define RTC_AL_MASK_DOW BIT(4)
-
-#define RTC_TC_SEC 0x000a
-/* Min, Hour, Dom... register offset to RTC_TC_SEC */
-#define RTC_OFFSET_SEC 0
-#define RTC_OFFSET_MIN 1
-#define RTC_OFFSET_HOUR 2
-#define RTC_OFFSET_DOM 3
-#define RTC_OFFSET_DOW 4
-#define RTC_OFFSET_MTH 5
-#define RTC_OFFSET_YEAR 6
-#define RTC_OFFSET_COUNT 7
-
-#define RTC_AL_SEC 0x0018
-
-#define RTC_PDN2 0x002e
-#define RTC_PDN2_PWRON_ALARM BIT(4)
-
-#define RTC_MIN_YEAR 1968
-#define RTC_BASE_YEAR 1900
-#define RTC_NUM_YEARS 128
-#define RTC_MIN_YEAR_OFFSET (RTC_MIN_YEAR - RTC_BASE_YEAR)
-
-struct mt6397_rtc {
- struct device *dev;
- struct rtc_device *rtc_dev;
- struct mutex lock;
- struct regmap *regmap;
- int irq;
- u32 addr_base;
-};
+#include <linux/mfd/mt6397/rtc.h>
static int mtk_rtc_write_trigger(struct mt6397_rtc *rtc)
{
diff --git a/include/linux/mfd/mt6397/rtc.h b/include/linux/mfd/mt6397/rtc.h
new file mode 100644
index 000000000000..f84b9163c0ee
--- /dev/null
+++ b/include/linux/mfd/mt6397/rtc.h
@@ -0,0 +1,71 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2014-2019 MediaTek Inc.
+ *
+ * Author: Tianping.Fang <tianping.fang@mediatek.com>
+ * Sean Wang <sean.wang@mediatek.com>
+ */
+
+#ifndef _LINUX_MFD_MT6397_RTC_H_
+#define _LINUX_MFD_MT6397_RTC_H_
+
+#include <linux/jiffies.h>
+#include <linux/mutex.h>
+#include <linux/regmap.h>
+#include <linux/rtc.h>
+
+#define RTC_BBPU 0x0000
+#define RTC_BBPU_CBUSY BIT(6)
+#define RTC_BBPU_KEY (0x43 << 8)
+
+#define RTC_WRTGR 0x003c
+
+#define RTC_IRQ_STA 0x0002
+#define RTC_IRQ_STA_AL BIT(0)
+#define RTC_IRQ_STA_LP BIT(3)
+
+#define RTC_IRQ_EN 0x0004
+#define RTC_IRQ_EN_AL BIT(0)
+#define RTC_IRQ_EN_ONESHOT BIT(2)
+#define RTC_IRQ_EN_LP BIT(3)
+#define RTC_IRQ_EN_ONESHOT_AL (RTC_IRQ_EN_ONESHOT | RTC_IRQ_EN_AL)
+
+#define RTC_AL_MASK 0x0008
+#define RTC_AL_MASK_DOW BIT(4)
+
+#define RTC_TC_SEC 0x000a
+/* Min, Hour, Dom... register offset to RTC_TC_SEC */
+#define RTC_OFFSET_SEC 0
+#define RTC_OFFSET_MIN 1
+#define RTC_OFFSET_HOUR 2
+#define RTC_OFFSET_DOM 3
+#define RTC_OFFSET_DOW 4
+#define RTC_OFFSET_MTH 5
+#define RTC_OFFSET_YEAR 6
+#define RTC_OFFSET_COUNT 7
+
+#define RTC_AL_SEC 0x0018
+
+#define RTC_PDN2 0x002e
+#define RTC_PDN2_PWRON_ALARM BIT(4)
+
+#define RTC_MIN_YEAR 1968
+#define RTC_BASE_YEAR 1900
+#define RTC_NUM_YEARS 128
+#define RTC_MIN_YEAR_OFFSET (RTC_MIN_YEAR - RTC_BASE_YEAR)
+
+#define MTK_RTC_POLL_DELAY_US 10
+#define MTK_RTC_POLL_TIMEOUT (jiffies_to_usecs(HZ))
+
+struct mt6397_rtc {
+ struct device *dev;
+ struct rtc_device *rtc_dev;
+
+ /* Protect register access from multiple tasks */
+ struct mutex lock;
+ struct regmap *regmap;
+ int irq;
+ u32 addr_base;
+};
+
+#endif /* _LINUX_MFD_MT6397_RTC_H_ */
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v7 4/7] rtc: mt6397: add compatible for mt6323
From: Frank Wunderlich @ 2019-09-10 7:04 UTC (permalink / raw)
To: linux-mediatek
Cc: linux-rtc, devicetree, Alexandre Belloni, Sean Wang,
Alessandro Zummo, linux-pm, Frank Wunderlich, Josef Friedl,
linux-kernel, Tianping Fang, Rob Herring, Sebastian Reichel,
Matthias Brugger, Mark Rutland, Eddie Huang, Lee Jones,
linux-arm-kernel
In-Reply-To: <20190910070446.639-1-frank-w@public-files.de>
From: Josef Friedl <josef.friedl@speed.at>
use mt6397 rtc driver also for mt6323 but with different
base/size see "mfd: mt6323: add mt6323 rtc+pwrc"
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
changes since v6: none
changes since v5: none
changes since v4: none
changes since v3: moved (was part 5)
changes since v2: splitted this from v2.3 suggested-by Alexandre Belloni
---
drivers/rtc/rtc-mt6397.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
index 9370b7fc9f81..21cd9cc8b4c7 100644
--- a/drivers/rtc/rtc-mt6397.c
+++ b/drivers/rtc/rtc-mt6397.c
@@ -325,6 +325,7 @@ static SIMPLE_DEV_PM_OPS(mt6397_pm_ops, mt6397_rtc_suspend,
mt6397_rtc_resume);
static const struct of_device_id mt6397_rtc_of_match[] = {
+ { .compatible = "mediatek,mt6323-rtc", },
{ .compatible = "mediatek,mt6397-rtc", },
{ }
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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