* Re: [PATCH] serial: bcm2835: Use devm_platform_ioremap_resource() in bcm2835aux_serial_probe()
From: Florian Fainelli @ 2019-09-20 17:51 UTC (permalink / raw)
To: Markus Elfring, linux-serial, linux-rpi-kernel, linux-arm-kernel,
bcm-kernel-feedback-list, Eric Anholt, Florian Fainelli,
Greg Kroah-Hartman, Jiri Slaby, Martin Sperl, Ray Jui,
Scott Branden, Stefan Wahren, Stephen Boyd
Cc: Bartosz Golaszewski, kernel-janitors, LKML, Himanshu Jha
In-Reply-To: <fcb34c72-89c7-9993-fc0a-ba3a61708bec@web.de>
On 9/18/19 1:12 PM, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Wed, 18 Sep 2019 22:00:14 +0200
>
> Simplify this function implementation by using a known wrapper function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Kirill A. Shutemov @ 2019-09-20 17:00 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Mark Rutland, Catalin Marinas, linux-mm, Punit Agrawal,
Will Deacon, Alex Van Brunt, Jia He, Marc Zyngier,
Anshuman Khandual, Kaly Xin, hejianet, Ralph Campbell,
Suzuki Poulose, Jérôme Glisse, Thomas Gleixner, nd,
linux-arm-kernel, linux-kernel, James Morse, Andrew Morton,
Robin Murphy, Kirill A. Shutemov
In-Reply-To: <20190920155300.GC15392@bombadil.infradead.org>
On Fri, Sep 20, 2019 at 08:53:00AM -0700, Matthew Wilcox wrote:
> On Fri, Sep 20, 2019 at 09:54:37PM +0800, Jia He wrote:
> > -static inline void cow_user_page(struct page *dst, struct page *src, unsigned long va, struct vm_area_struct *vma)
> > +static inline int cow_user_page(struct page *dst, struct page *src,
> > + struct vm_fault *vmf)
> > {
>
> Can we talk about the return type here?
>
> > + } else {
> > + /* Other thread has already handled the fault
> > + * and we don't need to do anything. If it's
> > + * not the case, the fault will be triggered
> > + * again on the same address.
> > + */
> > + pte_unmap_unlock(vmf->pte, vmf->ptl);
> > + return -1;
> ...
> > + return 0;
> > }
>
> So -1 for "try again" and 0 for "succeeded".
>
> > + if (cow_user_page(new_page, old_page, vmf)) {
>
> Then we use it like a bool. But it's kind of backwards from a bool because
> false is success.
>
> > + /* COW failed, if the fault was solved by other,
> > + * it's fine. If not, userspace would re-fault on
> > + * the same address and we will handle the fault
> > + * from the second attempt.
> > + */
> > + put_page(new_page);
> > + if (old_page)
> > + put_page(old_page);
> > + return 0;
>
> And we don't use the return value; in fact we invert it.
>
> Would this make more sense:
>
> static inline bool cow_user_page(struct page *dst, struct page *src,
> struct vm_fault *vmf)
> ...
> pte_unmap_unlock(vmf->pte, vmf->ptl);
> return false;
> ...
> return true;
> ...
> if (!cow_user_page(new_page, old_page, vmf)) {
>
> That reads more sensibly for me.
I like this idea too.
--
Kirill A. Shutemov
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH V2 1/2] clk: imx8mm: Move 1443X/1416X PLL clock structure to common place
From: Stephen Boyd @ 2019-09-20 16:55 UTC (permalink / raw)
To: S.j. Wang, festevam@gmail.com, kernel@pengutronix.de,
l.stach@pengutronix.de, linux-arm-kernel@lists.infradead.org,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
mturquette@baylibre.com, s.hauer@pengutronix.de,
sfr@canb.auug.org.au, shawnguo@kernel.org, Abel Vesa,
Aisheng Dong, Anson Huang, Fancy Fang, Jacky Bai, Leonard Crestez,
Peng Fan
Cc: dl-linux-imx
In-Reply-To: <AM6PR0402MB39110BCD655C354F8A295621F5880@AM6PR0402MB3911.eurprd04.prod.outlook.com>
Quoting Anson Huang (2019-09-19 18:27:39)
> Gentle ping...
>
Merge window is open. I expect Shawn to pick this up for v5.5 in a week
or two.
_______________________________________________
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] clk: meson: clk-pll: always enable a critical PLL when setting the rate
From: Stephen Boyd @ 2019-09-20 16:52 UTC (permalink / raw)
To: Jerome Brunet, Neil Armstrong
Cc: linux-amlogic, linux-clk, linux-arm-kernel, linux-kernel
In-Reply-To: <2551a729-5379-e039-4d5a-a83fa877fb14@baylibre.com>
Quoting Neil Armstrong (2019-09-20 01:06:58)
> Hi Stephen,
>
> On 19/09/2019 19:06, Stephen Boyd wrote:
> > Quoting Jerome Brunet (2019-09-19 06:01:28)
> >> On Thu 19 Sep 2019 at 11:38, Neil Armstrong <narmstrong@baylibre.com> wrote:
> >>
> >>> Make sure we always enable a PLL on a set_rate() when the PLL is
> >>> flagged as critical.
> >>>
> >>> This fixes the case when the Amlogic G12A SYS_PLL gets disabled by the
> >>> PSCI firmware when resuming from suspend-to-memory, in the case
> >>> where the CPU was not clocked by the SYS_PLL, but by the fixed PLL
> >>> fixed divisors.
> >>> In this particular case, when changing the PLL rate, CCF doesn't handle
> >>> the fact the PLL could have been disabled in the meantime and set_rate()
> >>> only changes the rate and never enables it again.
> >>>
> >>> Fixes: d6e81845b7d9 ("clk: meson: clk-pll: check if the clock is already enabled')
> >>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> >>> ---
> >>> drivers/clk/meson/clk-pll.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
> >>> index ddb1e5634739..8c5adccb7959 100644
> >>> --- a/drivers/clk/meson/clk-pll.c
> >>> +++ b/drivers/clk/meson/clk-pll.c
> >>> @@ -379,7 +379,7 @@ static int meson_clk_pll_set_rate(struct clk_hw *hw, unsigned long rate,
> >>> }
> >>>
> >>> /* If the pll is stopped, bail out now */
> >>> - if (!enabled)
> >>> + if (!(hw->init->flags & CLK_IS_CRITICAL) && !enabled)
> >>
> >> This is surely a work around to the issue at hand but:
> >>
> >> * Enabling the clock, critical or not, should not be done but the
> >> set_rate() callback. This is not the purpose of this callback.
> >>
> >> * Enabling the clock in such way does not walk the tree. So, if there is
> >> ever another PSCI Fw which disable we would get into the same issue
> >> again. IOW, This is not specific to the PLL driver so it should not have
> >> to deal with this.
> >
> > Exactly.
> >
> >>
> >> Since this clock can change out of CCF maybe it should be marked with
> >> CLK_GET_RATE_NOCACHE ?
> >
> > Yes, or figure out a way to make the clk state match what PSCI leaves it
> > in on resume from suspend.
> >
> >
> >>
> >> When CCF hits a clock with CLK_GET_RATE_NOCACHE while walking the tree,
> >> in addition to to calling get_rate(), CCF could also call is_enabled()
> >> if the clock has CLK_IS_CRITICAL and possibly .enable() ?
> >
> > This logic should go under a new flag. The CLK_GET_RATE_NOCACHE flag
> > specifically means get rate shouldn't be a cached operation. It doesn't
> > relate to the enable state. I hope that you can implement some sort of
> > resume hook that synchronizes the state though so that you don't need to
> > rely on clk_set_rate() or clk_get_rate() to trigger a sync.
> >
>
> It's exactly the goal of [1] where I resync a clock tree after a resume.
Ok. I haven't looked at that series yet. We can move this discussion
there if you like.
>
> But I don't check the enable state, would you mean that:
> if core->ops->enable && core->enable_count > 0 && !clk_core_is_enabled(core)
> core->ops->enable(core->hw)
>
> along the parent/rate resync ?
>
> Isn't that dangerous ?
>
Why is it dangerous? If the clk state is lost across suspend/resume we
need to restore the state of the clk somehow. One way would be to have
the clk driver tell the framework that this clk is now off and to drop
the enable counts for any consumers. Then consumers will need to call
clk_enable() again to turn the clk back on in the consumer resume
callback. Or we can try to be smarter/nicer and restore the clk state to
what the consumer is expecting across suspend/resume. I haven't thought
about what is better or worse.
On the one hand, device drivers already handle some things not being
saved/restored during system low power modes. But on the other hand I
don't know what the policy is for external resources that a device uses,
such as clks or regulators or pinctrl muxing, etc.
_______________________________________________
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 4/4] mt76: mt7615: sync with mt7603 rate control changes
From: Gustavo A. R. Silva @ 2019-09-20 23:44 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless, Lorenzo Bianconi, Roy Luo,
Kalle Valo, David S. Miller, Matthias Brugger, Networking,
linux-arm-kernel, linux-mediatek, Linux Kernel Mailing List,
Ryder Lee
In-Reply-To: <20190704155324.56693-4-nbd@nbd.name>
Hi all,
On 7/4/19 10:53, Felix Fietkau wrote:
[..]
> + for (i = 0, idx = first_idx; count && idx <= last_idx; idx++) {
> + struct ieee80211_tx_rate *cur_rate;
> + int cur_count;
>
> - info->status.rates[i].count = cur_count;
> - final_idx = i;
> + cur_rate = &rs->rates[idx / 2];
> + cur_count = min_t(int, MT7615_RATE_RETRY, count);
> count -= cur_count;
> +
> + if (idx && (cur_rate->idx != info->status.rates[i].idx ||
> + cur_rate->flags != info->status.rates[i].flags)) {
> + i++;
> + if (i == ARRAY_SIZE(info->status.rates))
Is this actually possible ^^^^^^^ ?? in case it is, see my comments below...
> + break;
> +
> + info->status.rates[i] = *cur_rate;
> + info->status.rates[i].count = 0;
> + }
> +
> + info->status.rates[i].count += cur_count;
> }
>
> out:
> - final_rate_flags = info->status.rates[final_idx].flags;
> + final_rate_flags = info->status.rates[i].flags;
There is an out-of-bounds access here........^^^ and see below...
>
> switch (FIELD_GET(MT_TX_RATE_MODE, final_rate)) {
> case MT_PHY_TYPE_CCK:
> @@ -713,8 +778,8 @@ static bool mt7615_fill_txs(struct mt7615_dev *dev, struct mt7615_sta *sta,
> return false;
> }
>
> - info->status.rates[final_idx].idx = final_rate;
> - info->status.rates[final_idx].flags = final_rate_flags;
> + info->status.rates[i].idx = final_rate;
> + info->status.rates[i].flags = final_rate_flags;
here too ............... ^^^^
>
> return true;
> }
--
Gustavo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: update Kconfig to better handle CMDLINE
From: ja.kaisrlik @ 2019-09-20 16:42 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: catalin.marinas, Jan Kaisrlik, will
From: Jan Kaisrlik <ja.kaisrlik@gmail.com>
Added a menu to choose how to CMDLINE will be handled. Config strings
were copied from arm32 port.
Signed-off-by: Jan Kaisrlik <ja.kaisrlik@gmail.com>
---
arch/arm64/Kconfig | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3adcec05b1f6..b1dd948f9665 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1538,6 +1538,23 @@ config CMDLINE
entering them here. As a minimum, you should specify the the
root device (e.g. root=/dev/nfs).
+choice
+ prompt "Kernel command line type" if CMDLINE != ""
+ default CMDLINE_FROM_BOOTLOADER
+
+config CMDLINE_FROM_BOOTLOADER
+ bool "Use bootloader kernel arguments if available"
+ help
+ Uses the command-line options passed by the boot loader. If
+ the boot loader doesn't provide any, the default kernel command
+ string provided in CMDLINE will be used.
+
+config CMDLINE_EXTEND
+ bool "Extend bootloader kernel arguments"
+ help
+ The command-line arguments provided by the boot loader will be
+ appended to the default kernel command string.
+
config CMDLINE_FORCE
bool "Always use the default kernel command string"
help
@@ -1545,6 +1562,7 @@ config CMDLINE_FORCE
loader passes other arguments to the kernel.
This is useful if you cannot or don't want to change the
command-line options your boot loader passes to the kernel.
+endchoice
config EFI_STUB
bool
--
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: ARM core blob list
From: Stefan Wahren @ 2019-09-20 16:36 UTC (permalink / raw)
To: Sergey Brutyan, linux-arm-kernel
In-Reply-To: <7c52fab5-825a-b019-ec46-6fb731336cfe@ehayq.am>
Hi Sergey,
Am 20.09.19 um 12:15 schrieb Sergey Brutyan:
> Dear all we are company of hard/soft design and integration mostly based
> on ARM cores.
> We are currently working on Libre Linux development for ARM based SBC.
>
> And ready to put professional effort for having complete blob-free Linux
> kernel, as we have done research there is most problem with bootloaders
> and Mali or PowerVR GPU units in SoC.
>
> We are looking forward to cooperate and now have several need of
> information.
>
> Can you send us list for blob drivers for this SoC:
>
> Allwinner A20
> Allwinner R40
> Broadcom BCM2837
here is the list for Linux 5.3:
cpufreq/raspberrypi-cpufreq.c
gpio/gpio-raspberrypi-exp.c
clk/bcm/clk-raspberrypi.c
staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
staging/vc04_services/bcm2835-camera/mmal-vchiq.c
firmware/raspberrypi.c
hwmon/raspberrypi-hwmon.c
soc/bcm/raspberrypi-power.c (*)
(*) There is already a blob-free driver called soc/bcm/bcm2835-power.c,
but it still needs improvements.
Since the ARM cores doesn't have full access, it may not possible to
replace all these drivers. An alternative approach for blob-freeness on
BCM2837 would be an open VC4 firmware [1].
[1] - https://github.com/christinaa/rpi-open-firmware
Good luck
Stefan
> Realtek RTD1395
> MediaTek MT7623N
>
>
> And also please offer us which is the best SoC for blob-free linux
> development.
>
> Best regards. Sergey.
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 2/2] dt-bindings: arm: samsung: Convert Exynos PMU bindings to json-schema
From: Krzysztof Kozlowski @ 2019-09-20 16:26 UTC (permalink / raw)
To: Kukjin Kim, Krzysztof Kozlowski, Rob Herring, Mark Rutland,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel
In-Reply-To: <20190920162600.7486-1-krzk@kernel.org>
Convert Samsung Exynos Power Management Unit (PMU) bindings to DT schema
format using json-schema.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Changes since v2:
1. Use select to skip other syscon nodes,
2. Indent example with four spaces (more readable),
3. Use pattern for clkoutN property,
4. Include header with clock IDs in example to bring it closer to real DTS.
Changes since v1:
1. Fix clock-names to match all elements against schema (any number of
any clkoutN values).
This currently fails:
properties:clock-names:items: {'enum': ['clkout0', 'clkout1', 'clkout2',
'clkout3', 'clkout4', 'clkout5', 'clkout6', 'clkout7', 'clkout8',
'clkout9', 'clkout10', 'clkout11', 'clkout12', 'clkout13', 'clkout14',
'clkout15', 'clkout16']} is not of type 'array
2. Add syscon reboot and poweroff nodes.
---
.../devicetree/bindings/arm/samsung/pmu.txt | 72 ------------
.../devicetree/bindings/arm/samsung/pmu.yaml | 105 ++++++++++++++++++
2 files changed, 105 insertions(+), 72 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/samsung/pmu.txt
create mode 100644 Documentation/devicetree/bindings/arm/samsung/pmu.yaml
diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
deleted file mode 100644
index 433bfd7593ac..000000000000
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ /dev/null
@@ -1,72 +0,0 @@
-SAMSUNG Exynos SoC series PMU Registers
-
-Properties:
- - compatible : should contain two values. First value must be one from following list:
- - "samsung,exynos3250-pmu" - for Exynos3250 SoC,
- - "samsung,exynos4210-pmu" - for Exynos4210 SoC,
- - "samsung,exynos4412-pmu" - for Exynos4412 SoC,
- - "samsung,exynos5250-pmu" - for Exynos5250 SoC,
- - "samsung,exynos5260-pmu" - for Exynos5260 SoC.
- - "samsung,exynos5410-pmu" - for Exynos5410 SoC,
- - "samsung,exynos5420-pmu" - for Exynos5420 SoC.
- - "samsung,exynos5433-pmu" - for Exynos5433 SoC.
- - "samsung,exynos7-pmu" - for Exynos7 SoC.
- second value must be always "syscon".
-
- - reg : offset and length of the register set.
-
- - #clock-cells : must be <1>, since PMU requires once cell as clock specifier.
- The single specifier cell is used as index to list of clocks
- provided by PMU, which is currently:
- 0 : SoC clock output (CLKOUT pin)
-
- - clock-names : list of clock names for particular CLKOUT mux inputs in
- following format:
- "clkoutN", where N is a decimal number corresponding to
- CLKOUT mux control bits value for given input, e.g.
- "clkout0", "clkout7", "clkout15".
-
- - clocks : list of phandles and specifiers to all input clocks listed in
- clock-names property.
-
-Optional properties:
-
-Some PMUs are capable of behaving as an interrupt controller (mostly
-to wake up a suspended PMU). In which case, they can have the
-following properties:
-
-- interrupt-controller: indicate that said PMU is an interrupt controller
-
-- #interrupt-cells: must be identical to the that of the parent interrupt
- controller.
-
-
-Optional nodes:
-
-- nodes defining the restart and poweroff syscon children
-
-
-Example :
-pmu_system_controller: system-controller@10040000 {
- compatible = "samsung,exynos5250-pmu", "syscon";
- reg = <0x10040000 0x5000>;
- interrupt-controller;
- #interrupt-cells = <3>;
- interrupt-parent = <&gic>;
- #clock-cells = <1>;
- clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
- "clkout4", "clkout8", "clkout9";
- clocks = <&clock CLK_OUT_DMC>, <&clock CLK_OUT_TOP>,
- <&clock CLK_OUT_LEFTBUS>, <&clock CLK_OUT_RIGHTBUS>,
- <&clock CLK_OUT_CPU>, <&clock CLK_XXTI>,
- <&clock CLK_XUSBXTI>;
-};
-
-Example of clock consumer :
-
-usb3503: usb3503@8 {
- /* ... */
- clock-names = "refclk";
- clocks = <&pmu_system_controller 0>;
- /* ... */
-};
diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.yaml b/Documentation/devicetree/bindings/arm/samsung/pmu.yaml
new file mode 100644
index 000000000000..73b56fc5bf58
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.yaml
@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/samsung/pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Exynos SoC series Power Management Unit (PMU)
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+# Custom select to avoid matching all nodes with 'syscon'
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynos3250-pmu
+ - samsung,exynos4210-pmu
+ - samsung,exynos4412-pmu
+ - samsung,exynos5250-pmu
+ - samsung,exynos5260-pmu
+ - samsung,exynos5410-pmu
+ - samsung,exynos5420-pmu
+ - samsung,exynos5433-pmu
+ - samsung,exynos7-pmu
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - samsung,exynos3250-pmu
+ - samsung,exynos4210-pmu
+ - samsung,exynos4412-pmu
+ - samsung,exynos5250-pmu
+ - samsung,exynos5260-pmu
+ - samsung,exynos5410-pmu
+ - samsung,exynos5420-pmu
+ - samsung,exynos5433-pmu
+ - samsung,exynos7-pmu
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ clock-names:
+ description:
+ List of clock names for particular CLKOUT mux inputs
+ minItems: 1
+ maxItems: 32
+ items:
+ pattern: '^clkout([0-9]|[12][0-9]|3[0-1])$'
+
+ clocks:
+ minItems: 1
+ maxItems: 32
+
+ interrupt-controller:
+ description:
+ Some PMUs are capable of behaving as an interrupt controller (mostly
+ to wake up a suspended PMU).
+
+ '#interrupt-cells':
+ description:
+ Must be identical to the that of the parent interrupt controller.
+ const: 3
+
+ syscon-poweroff:
+ $ref: "../../power/reset/syscon-poweroff.yaml#"
+ type: object
+ description:
+ Node for power off method
+
+ syscon-reboot:
+ $ref: "../../power/reset/syscon-reboot.yaml#"
+ type: object
+ description:
+ Node for reboot method
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - clock-names
+ - clocks
+
+examples:
+ - |
+ #include <dt-bindings/clock/exynos5250.h>
+
+ pmu_system_controller: system-controller@10040000 {
+ compatible = "samsung,exynos5250-pmu", "syscon";
+ reg = <0x10040000 0x5000>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ interrupt-parent = <&gic>;
+ #clock-cells = <1>;
+ clock-names = "clkout16";
+ clocks = <&clock CLK_FIN_PLL>;
+ };
--
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 v3 1/2] dt-bindings: arm: samsung: Convert Exynos System Registers bindings to json-schema
From: Krzysztof Kozlowski @ 2019-09-20 16:25 UTC (permalink / raw)
To: Kukjin Kim, Krzysztof Kozlowski, Rob Herring, Mark Rutland,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel
Convert Samsung Exynos System Registers (SYSREG) bindings to DT schema
format using json-schema.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Changes since v2:
1. Use select to skip other syscon nodes,
2. Indent example with four spaces (more readable),
---
.../bindings/arm/samsung/sysreg.txt | 19 --------
.../bindings/arm/samsung/sysreg.yaml | 45 +++++++++++++++++++
2 files changed, 45 insertions(+), 19 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/samsung/sysreg.txt
create mode 100644 Documentation/devicetree/bindings/arm/samsung/sysreg.yaml
diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
deleted file mode 100644
index 4fced6e9d5e4..000000000000
--- a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-SAMSUNG S5P/Exynos SoC series System Registers (SYSREG)
-
-Properties:
- - compatible : should contain two values. First value must be one from following list:
- - "samsung,exynos4-sysreg" - for Exynos4 based SoCs,
- - "samsung,exynos5-sysreg" - for Exynos5 based SoCs.
- second value must be always "syscon".
- - reg : offset and length of the register set.
-
-Example:
- syscon@10010000 {
- compatible = "samsung,exynos4-sysreg", "syscon";
- reg = <0x10010000 0x400>;
- };
-
- syscon@10050000 {
- compatible = "samsung,exynos5-sysreg", "syscon";
- reg = <0x10050000 0x5000>;
- };
diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.yaml b/Documentation/devicetree/bindings/arm/samsung/sysreg.yaml
new file mode 100644
index 000000000000..3b7811804cb4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/samsung/sysreg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung S5P/Exynos SoC series System Registers (SYSREG)
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+# Custom select to avoid matching all nodes with 'syscon'
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynos4-sysreg
+ - samsung,exynos5-sysreg
+ required:
+ - compatible
+
+properties:
+ compatible:
+ allOf:
+ - items:
+ - enum:
+ - samsung,exynos4-sysreg
+ - samsung,exynos5-sysreg
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+examples:
+ - |
+ syscon@10010000 {
+ compatible = "samsung,exynos4-sysreg", "syscon";
+ reg = <0x10010000 0x400>;
+ };
+
+ syscon@10050000 {
+ compatible = "samsung,exynos5-sysreg", "syscon";
+ reg = <0x10050000 0x5000>;
+ };
--
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 2/2] arm64: dts: exynos: Rename Multi Core Timer node to just timer
From: Krzysztof Kozlowski @ 2019-09-20 16:24 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kukjin Kim, Krzysztof Kozlowski,
devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel
In-Reply-To: <20190920162456.7294-1-krzk@kernel.org>
The device node name should reflect generic class of a device so rename
the Multi Core Timer node from "mct" to "timer". This will be also in
sync with upcoming DT schema. No functional change.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index a76f620f7f35..8baf3c645eae 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -754,7 +754,7 @@
status = "disabled";
};
- mct@101c0000 {
+ timer@101c0000 {
compatible = "samsung,exynos4210-mct";
reg = <0x101c0000 0x800>;
interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
--
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 1/2] ARM: dts: exynos: Rename Multi Core Timer node to just timer
From: Krzysztof Kozlowski @ 2019-09-20 16:24 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kukjin Kim, Krzysztof Kozlowski,
devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel
The device node name should reflect generic class of a device so rename
the Multi Core Timer node from "mct" to "timer". This will be also in
sync with upcoming DT schema. No functional change.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm/boot/dts/exynos3250.dtsi | 2 +-
arch/arm/boot/dts/exynos4210.dtsi | 2 +-
arch/arm/boot/dts/exynos4412.dtsi | 2 +-
arch/arm/boot/dts/exynos5250.dtsi | 2 +-
arch/arm/boot/dts/exynos5260.dtsi | 2 +-
arch/arm/boot/dts/exynos54xx.dtsi | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index 784818490376..d122fb52d3d4 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -265,7 +265,7 @@
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
};
- mct@10050000 {
+ timer@10050000 {
compatible = "samsung,exynos4210-mct";
reg = <0x10050000 0x800>;
interrupts = <GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH>,
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index f220716239db..6d3f19562aab 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -106,7 +106,7 @@
arm,data-latency = <2 2 1>;
};
- mct: mct@10050000 {
+ mct: timer@10050000 {
compatible = "samsung,exynos4210-mct";
reg = <0x10050000 0x800>;
interrupt-parent = <&mct_map>;
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index d20db2dfe8e2..8b6d5875c75d 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -243,7 +243,7 @@
clock-names = "aclk200", "aclk400_mcuisp";
};
- mct@10050000 {
+ timer@10050000 {
compatible = "samsung,exynos4412-mct";
reg = <0x10050000 0x800>;
interrupt-parent = <&mct_map>;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index fc966c10cf49..7a01349317a3 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -233,7 +233,7 @@
power-domains = <&pd_mau>;
};
- mct@101c0000 {
+ timer@101c0000 {
compatible = "samsung,exynos4210-mct";
reg = <0x101C0000 0x800>;
interrupt-controller;
diff --git a/arch/arm/boot/dts/exynos5260.dtsi b/arch/arm/boot/dts/exynos5260.dtsi
index 3581b57fbbf7..b0811dbbb362 100644
--- a/arch/arm/boot/dts/exynos5260.dtsi
+++ b/arch/arm/boot/dts/exynos5260.dtsi
@@ -180,7 +180,7 @@
reg = <0x10000000 0x100>;
};
- mct: mct@100b0000 {
+ mct: timer@100b0000 {
compatible = "samsung,exynos4210-mct";
reg = <0x100B0000 0x1000>;
clocks = <&fin_pll>, <&clock_peri PERI_CLK_MCT>;
diff --git a/arch/arm/boot/dts/exynos54xx.dtsi b/arch/arm/boot/dts/exynos54xx.dtsi
index 9c3b63b7cac6..247d23872384 100644
--- a/arch/arm/boot/dts/exynos54xx.dtsi
+++ b/arch/arm/boot/dts/exynos54xx.dtsi
@@ -64,7 +64,7 @@
};
};
- mct: mct@101c0000 {
+ mct: timer@101c0000 {
compatible = "samsung,exynos4210-mct";
reg = <0x101c0000 0xb00>;
interrupt-parent = <&mct_map>;
--
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 v2 5/8] dt-bindings: watchdog: Convert Samsung SoC watchdog bindings to json-schema
From: Krzysztof Kozlowski @ 2019-09-20 16:23 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Thierry Reding, Matt Mackall,
Herbert Xu, Wim Van Sebroeck, Guenter Roeck, linux-clk,
devicetree, linux-kernel@vger.kernel.org, dri-devel, linux-leds,
linux-arm-kernel, linux-samsung-soc@vger.kernel.org, linux-pwm,
linux-tegra, bcm-kernel-feedback-list, linux-rpi-kernel,
linux-amlogic, linux-mediatek, linux-rockchip, linux-riscv,
linux-stm32, linux-crypto, linux-watchdog
In-Reply-To: <20190918173141.4314-5-krzk@kernel.org>
On Wed, 18 Sep 2019 at 19:32, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> Convert Samsung S3C/S5P/Exynos watchdog bindings to DT schema format
> using json-schema.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> Changes since v1:
> 1. Indent example with four spaces (more readable),
> 2. Remove unneeded timeout-sec description.
Superseded by v3 (although named v2...).
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: watchdog: Convert Samsung SoC watchdog bindings to json-schema
From: Krzysztof Kozlowski @ 2019-09-20 16:23 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Mark Rutland,
Kevin Hilman, linux-watchdog, devicetree, linux-arm-kernel,
linux-amlogic, linux-kernel@vger.kernel.org
In-Reply-To: <20190920162124.7036-1-krzk@kernel.org>
On Fri, 20 Sep 2019 at 18:21, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> Convert Samsung S3C/S5P/Exynos watchdog bindings to DT schema format
> using json-schema.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> Changes since v1:
> 1. Indent example with four spaces (more readable),
> 2. Remove unneeded timeout-sec description and include generic bindings.
My bad, this is actually v3.
Best regards,
Krzysztof
_______________________________________________
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 3/3] dt-bindings: watchdog: meson-gxbb-wdt: Include generic watchdog bindings
From: Krzysztof Kozlowski @ 2019-09-20 16:21 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Mark Rutland,
Kevin Hilman, linux-watchdog, devicetree, linux-arm-kernel,
linux-amlogic, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20190920162124.7036-1-krzk@kernel.org>
Include generic watchdog DT schema bindings in Amlogic GXBB Watchdog
bindings.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
.../devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml b/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml
index d7352f709b37..4ddae6feef3b 100644
--- a/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml
@@ -10,6 +10,9 @@ title: Meson GXBB SoCs Watchdog timer
maintainers:
- Neil Armstrong <narmstrong@baylibre.com>
+allOf:
+ - $ref: watchdog.yaml#
+
properties:
compatible:
enum:
--
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 v2 2/3] dt-bindings: watchdog: Add missing clocks requirement in Samsung SoC watchdog
From: Krzysztof Kozlowski @ 2019-09-20 16:21 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Mark Rutland,
Kevin Hilman, linux-watchdog, devicetree, linux-arm-kernel,
linux-amlogic, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20190920162124.7036-1-krzk@kernel.org>
The Samsung SoC watchdog driver always required providing a clock
(either through platform data or from DT). However when bindings were
added in commit 9487a9cc7140 ("watchdog: s3c2410: Add support for device
tree based probe"), they missed the requirement of clock.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes since v1:
1. Indent example with four spaces (more readable),
2. Add also missing required entries for clocks.
---
.../devicetree/bindings/watchdog/samsung-wdt.yaml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
index 5a3a3cec8e20..2fa40d8864b2 100644
--- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
@@ -26,6 +26,13 @@ properties:
reg:
maxItems: 1
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: watchdog
+
interrupts:
maxItems: 1
@@ -37,6 +44,8 @@ properties:
required:
- compatible
+ - clocks
+ - clock-names
- interrupts
- reg
--
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 v2 1/3] dt-bindings: watchdog: Convert Samsung SoC watchdog bindings to json-schema
From: Krzysztof Kozlowski @ 2019-09-20 16:21 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Mark Rutland,
Kevin Hilman, linux-watchdog, devicetree, linux-arm-kernel,
linux-amlogic, linux-kernel
Cc: Krzysztof Kozlowski
Convert Samsung S3C/S5P/Exynos watchdog bindings to DT schema format
using json-schema.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Changes since v1:
1. Indent example with four spaces (more readable),
2. Remove unneeded timeout-sec description and include generic bindings.
---
.../bindings/watchdog/samsung-wdt.txt | 35 ----------
.../bindings/watchdog/samsung-wdt.yaml | 65 +++++++++++++++++++
2 files changed, 65 insertions(+), 35 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
create mode 100644 Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
deleted file mode 100644
index 46dcb48e75b4..000000000000
--- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-* Samsung's Watchdog Timer Controller
-
-The Samsung's Watchdog controller is used for resuming system operation
-after a preset amount of time during which the WDT reset event has not
-occurred.
-
-Required properties:
-- compatible : should be one among the following
- - "samsung,s3c2410-wdt" for S3C2410
- - "samsung,s3c6410-wdt" for S3C6410, S5PV210 and Exynos4
- - "samsung,exynos5250-wdt" for Exynos5250
- - "samsung,exynos5420-wdt" for Exynos5420
- - "samsung,exynos7-wdt" for Exynos7
-
-- reg : base physical address of the controller and length of memory mapped
- region.
-- interrupts : interrupt number to the cpu.
-- samsung,syscon-phandle : reference to syscon node (This property required only
- in case of compatible being "samsung,exynos5250-wdt" or "samsung,exynos5420-wdt".
- In case of Exynos5250 and 5420 this property points to syscon node holding the PMU
- base address)
-
-Optional properties:
-- timeout-sec : contains the watchdog timeout in seconds.
-
-Example:
-
-watchdog@101d0000 {
- compatible = "samsung,exynos5250-wdt";
- reg = <0x101D0000 0x100>;
- interrupts = <0 42 0>;
- clocks = <&clock 336>;
- clock-names = "watchdog";
- samsung,syscon-phandle = <&pmu_syscon>;
-};
diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
new file mode 100644
index 000000000000..5a3a3cec8e20
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/samsung-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung SoC Watchdog Timer Controller
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description: |+
+ The Samsung's Watchdog controller is used for resuming system operation
+ after a preset amount of time during which the WDT reset event has not
+ occurred.
+
+properties:
+ compatible:
+ enum:
+ - samsung,s3c2410-wdt # for S3C2410
+ - samsung,s3c6410-wdt # for S3C6410, S5PV210 and Exynos4
+ - samsung,exynos5250-wdt # for Exynos5250
+ - samsung,exynos5420-wdt # for Exynos5420
+ - samsung,exynos7-wdt # for Exynos7
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ samsung,syscon-phandle:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the PMU system controller node (in case of Exynos5250
+ and Exynos5420).
+
+required:
+ - compatible
+ - interrupts
+ - reg
+
+allOf:
+ - $ref: watchdog.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynos5250-wdt
+ - samsung,exynos5420-wdt
+ then:
+ required:
+ - samsung,syscon-phandle
+
+examples:
+ - |
+ watchdog@101d0000 {
+ compatible = "samsung,exynos5250-wdt";
+ reg = <0x101D0000 0x100>;
+ interrupts = <0 42 0>;
+ clocks = <&clock 336>;
+ clock-names = "watchdog";
+ samsung,syscon-phandle = <&pmu_syscon>;
+ };
--
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] spi: atmel: Fix crash when using more than 4 gpio CS
From: Mark Brown @ 2019-09-20 15:54 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Alexandre Belloni, stable, linux-kernel, Ludovic Desroches,
Thomas Petazzoni, linux-spi, linux-arm-kernel
In-Reply-To: <87a7az7zt6.fsf@FE-laptop>
[-- Attachment #1.1: Type: text/plain, Size: 372 bytes --]
On Fri, Sep 20, 2019 at 05:27:49PM +0200, Gregory CLEMENT wrote:
> But after going further in the details of the driver, this patch could
> cause a regression for on the old controllers.
> I also found other issues in this driver in the chip select
> management. So I will send a new series fixing all of it.
OK, great - glad at least one of us spotted a real problem!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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
* Re: [PATCH v7 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Matthew Wilcox @ 2019-09-20 15:53 UTC (permalink / raw)
To: Jia He
Cc: Mark Rutland, Kaly Xin, Ralph Campbell, Andrew Morton,
Suzuki Poulose, Catalin Marinas, Anshuman Khandual, linux-kernel,
linux-mm, Jérôme Glisse, James Morse, linux-arm-kernel,
Punit Agrawal, Marc Zyngier, hejianet, Thomas Gleixner, nd,
Will Deacon, Alex Van Brunt, Kirill A. Shutemov, Robin Murphy
In-Reply-To: <20190920135437.25622-4-justin.he@arm.com>
On Fri, Sep 20, 2019 at 09:54:37PM +0800, Jia He wrote:
> -static inline void cow_user_page(struct page *dst, struct page *src, unsigned long va, struct vm_area_struct *vma)
> +static inline int cow_user_page(struct page *dst, struct page *src,
> + struct vm_fault *vmf)
> {
Can we talk about the return type here?
> + } else {
> + /* Other thread has already handled the fault
> + * and we don't need to do anything. If it's
> + * not the case, the fault will be triggered
> + * again on the same address.
> + */
> + pte_unmap_unlock(vmf->pte, vmf->ptl);
> + return -1;
...
> + return 0;
> }
So -1 for "try again" and 0 for "succeeded".
> + if (cow_user_page(new_page, old_page, vmf)) {
Then we use it like a bool. But it's kind of backwards from a bool because
false is success.
> + /* COW failed, if the fault was solved by other,
> + * it's fine. If not, userspace would re-fault on
> + * the same address and we will handle the fault
> + * from the second attempt.
> + */
> + put_page(new_page);
> + if (old_page)
> + put_page(old_page);
> + return 0;
And we don't use the return value; in fact we invert it.
Would this make more sense:
static inline bool cow_user_page(struct page *dst, struct page *src,
struct vm_fault *vmf)
...
pte_unmap_unlock(vmf->pte, vmf->ptl);
return false;
...
return true;
...
if (!cow_user_page(new_page, old_page, vmf)) {
That reads more sensibly for me. We could also go with returning a
vm_fault_t, but that would be more complex than needed today, I think.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 8/8] dt-bindings: pwm: Convert Samsung PWM bindings to json-schema
From: Rob Herring @ 2019-09-20 15:50 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, Linux PWM List, dri-devel, Thierry Reding,
linux-riscv, linux-stm32, Linux LED Subsystem, linux-samsung-soc,
Herbert Xu, linux-clk, open list:ARM/Rockchip SoC...,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, Guenter Roeck,
devicetree, LINUX-WATCHDOG,
moderated list:ARM/Mediatek SoC support,
moderated list:BROADCOM BCM2835 ARM ARCHITECTURE, Matt Mackall,
linux-tegra, linux-amlogic, Wim Van Sebroeck,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel@vger.kernel.org,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE
In-Reply-To: <20190918173141.4314-8-krzk@kernel.org>
On Wed, Sep 18, 2019 at 12:32 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> Convert Samsung PWM (S3C, S5P and Exynos SoCs) bindings to DT schema
> format using json-schema.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> Changes since v1:
> 1. Indent example with four spaces (more readable),
> 2. Fix samsung,pwm-outputs after review,
> 3. Remove double-quotes from clock names.
> ---
> .../devicetree/bindings/pwm/pwm-samsung.txt | 51 ---------
> .../devicetree/bindings/pwm/pwm-samsung.yaml | 107 ++++++++++++++++++
> 2 files changed, 107 insertions(+), 51 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-samsung.txt
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
> deleted file mode 100644
> index 5538de9c2007..000000000000
> --- a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
> +++ /dev/null
> @@ -1,51 +0,0 @@
> -* Samsung PWM timers
> -
> -Samsung SoCs contain PWM timer blocks which can be used for system clock source
> -and clock event timers, as well as to drive SoC outputs with PWM signal. Each
> -PWM timer block provides 5 PWM channels (not all of them can drive physical
> -outputs - see SoC and board manual).
> -
> -Be aware that the clocksource driver supports only uniprocessor systems.
> -
> -Required properties:
> -- compatible : should be one of following:
> - samsung,s3c2410-pwm - for 16-bit timers present on S3C24xx SoCs
> - samsung,s3c6400-pwm - for 32-bit timers present on S3C64xx SoCs
> - samsung,s5p6440-pwm - for 32-bit timers present on S5P64x0 SoCs
> - samsung,s5pc100-pwm - for 32-bit timers present on S5PC100, S5PV210,
> - Exynos4210 rev0 SoCs
> - samsung,exynos4210-pwm - for 32-bit timers present on Exynos4210,
> - Exynos4x12, Exynos5250 and Exynos5420 SoCs
> -- reg: base address and size of register area
> -- interrupts: list of timer interrupts (one interrupt per timer, starting at
> - timer 0)
> -- clock-names: should contain all following required clock names:
> - - "timers" - PWM base clock used to generate PWM signals,
> - and any subset of following optional clock names:
> - - "pwm-tclk0" - first external PWM clock source,
> - - "pwm-tclk1" - second external PWM clock source.
> - Note that not all IP variants allow using all external clock sources.
> - Refer to SoC documentation to learn which clock source configurations
> - are available.
> -- clocks: should contain clock specifiers of all clocks, which input names
> - have been specified in clock-names property, in same order.
> -- #pwm-cells: should be 3. See pwm.txt in this directory for a description of
> - the cells format. The only third cell flag supported by this binding is
> - PWM_POLARITY_INVERTED.
> -
> -Optional properties:
> -- samsung,pwm-outputs: list of PWM channels used as PWM outputs on particular
> - platform - an array of up to 5 elements being indices of PWM channels
> - (from 0 to 4), the order does not matter.
> -
> -Example:
> - pwm@7f006000 {
> - compatible = "samsung,s3c6400-pwm";
> - reg = <0x7f006000 0x1000>;
> - interrupt-parent = <&vic0>;
> - interrupts = <23>, <24>, <25>, <27>, <28>;
> - clocks = <&clock 67>;
> - clock-names = "timers";
> - samsung,pwm-outputs = <0>, <1>;
> - #pwm-cells = <3>;
> - }
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
> new file mode 100644
> index 000000000000..06d11faabff6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
> @@ -0,0 +1,107 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pwm/pwm-samsung.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung SoC PWM timers
> +
> +maintainers:
> + - Thierry Reding <thierry.reding@gmail.com>
> + - Krzysztof Kozlowski <krzk@kernel.org>
> +
> +description: |+
> + Samsung SoCs contain PWM timer blocks which can be used for system clock source
> + and clock event timers, as well as to drive SoC outputs with PWM signal. Each
> + PWM timer block provides 5 PWM channels (not all of them can drive physical
> + outputs - see SoC and board manual).
> +
> + Be aware that the clocksource driver supports only uniprocessor systems.
> +
> +allOf:
> + - $ref: pwm.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - samsung,s3c2410-pwm # 16-bit, S3C24xx
> + - samsung,s3c6400-pwm # 32-bit, S3C64xx
> + - samsung,s5p6440-pwm # 32-bit, S5P64x0
> + - samsung,s5pc100-pwm # 32-bit, S5PC100, S5PV210, Exynos4210 rev0 SoCs
> + - samsung,exynos4210-pwm # 32-bit, Exynos
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + minItems: 1
> + maxItems: 3
> +
> + clock-names:
> + description: |
> + Should contain all following required clock names:
> + - "timers" - PWM base clock used to generate PWM signals,
> + and any subset of following optional clock names:
> + - "pwm-tclk0" - first external PWM clock source,
> + - "pwm-tclk1" - second external PWM clock source.
> + Note that not all IP variants allow using all external clock sources.
> + Refer to SoC documentation to learn which clock source configurations
> + are available.
> + oneOf:
> + - items:
> + - const: timers
> + - items:
> + - const: timers
> + - const: pwm-tclk0
> + - items:
> + - const: timers
> + - const: pwm-tclk1
> + - items:
> + - const: timers
> + - const: pwm-tclk0
> + - const: pwm-tclk1
> +
> + interrupts:
> + description:
> + One interrupt per timer, starting at timer 0.
> + minItems: 1
> + maxItems: 5
> +
> + "#pwm-cells":
> + description:
> + The only third cell flag supported by this binding
> + is PWM_POLARITY_INVERTED.
> + const: 3
> +
> + samsung,pwm-outputs:
> + description:
> + A list of PWM channels used as PWM outputs on particular platform.
> + It is an array of up to 5 elements being indices of PWM channels
> + (from 0 to 4), the order does not matter.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + - uniqueItems: true
> + - items:
> + minimum: 0
> + maximum: 4
> +
> +required:
> + - clocks
> + - clock-names
> + - compatible
> + - interrupts
> + - "#pwm-cells"
> + - reg
additionalProperties: false
should work here. And in the rng binding too.
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] clk: at91: avoid sleeping early
From: Alexandre Belloni @ 2019-09-20 15:39 UTC (permalink / raw)
To: Stephen Boyd
Cc: Alexandre Belloni, Michael Turquette, linux-kernel,
Uwe Kleine-König, Claudiu Beznea, linux-clk,
linux-arm-kernel
It is not allowed to sleep to early in the boot process and this may lead
to kernel issues if the bootloader didn't prepare the slow clock and main
clock.
This results in the following error and dump stack on the AriettaG25:
bad: scheduling from the idle thread!
Ensure it is possible to sleep, else simply have a delay.
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
Note that this was already discussed a while ago and Arnd said this approach was
reasonable:
https://lore.kernel.org/lkml/6120818.MyeJZ74hYa@wuerfel/
drivers/clk/at91/clk-main.c | 5 ++++-
drivers/clk/at91/sckc.c | 20 ++++++++++++++++----
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/at91/clk-main.c b/drivers/clk/at91/clk-main.c
index f607ee702c83..ccd48e7a3d74 100644
--- a/drivers/clk/at91/clk-main.c
+++ b/drivers/clk/at91/clk-main.c
@@ -293,7 +293,10 @@ static int clk_main_probe_frequency(struct regmap *regmap)
regmap_read(regmap, AT91_CKGR_MCFR, &mcfr);
if (mcfr & AT91_PMC_MAINRDY)
return 0;
- usleep_range(MAINF_LOOP_MIN_WAIT, MAINF_LOOP_MAX_WAIT);
+ if (system_state < SYSTEM_RUNNING)
+ udelay(MAINF_LOOP_MIN_WAIT);
+ else
+ usleep_range(MAINF_LOOP_MIN_WAIT, MAINF_LOOP_MAX_WAIT);
} while (time_before(prep_time, timeout));
return -ETIMEDOUT;
diff --git a/drivers/clk/at91/sckc.c b/drivers/clk/at91/sckc.c
index 9bfe9a28294a..fac0ca56d42d 100644
--- a/drivers/clk/at91/sckc.c
+++ b/drivers/clk/at91/sckc.c
@@ -76,7 +76,10 @@ static int clk_slow_osc_prepare(struct clk_hw *hw)
writel(tmp | osc->bits->cr_osc32en, sckcr);
- usleep_range(osc->startup_usec, osc->startup_usec + 1);
+ if (system_state < SYSTEM_RUNNING)
+ udelay(osc->startup_usec);
+ else
+ usleep_range(osc->startup_usec, osc->startup_usec + 1);
return 0;
}
@@ -187,7 +190,10 @@ static int clk_slow_rc_osc_prepare(struct clk_hw *hw)
writel(readl(sckcr) | osc->bits->cr_rcen, sckcr);
- usleep_range(osc->startup_usec, osc->startup_usec + 1);
+ if (system_state < SYSTEM_RUNNING)
+ udelay(osc->startup_usec);
+ else
+ usleep_range(osc->startup_usec, osc->startup_usec + 1);
return 0;
}
@@ -288,7 +294,10 @@ static int clk_sam9x5_slow_set_parent(struct clk_hw *hw, u8 index)
writel(tmp, sckcr);
- usleep_range(SLOWCK_SW_TIME_USEC, SLOWCK_SW_TIME_USEC + 1);
+ if (system_state < SYSTEM_RUNNING)
+ udelay(SLOWCK_SW_TIME_USEC);
+ else
+ usleep_range(SLOWCK_SW_TIME_USEC, SLOWCK_SW_TIME_USEC + 1);
return 0;
}
@@ -533,7 +542,10 @@ static int clk_sama5d4_slow_osc_prepare(struct clk_hw *hw)
return 0;
}
- usleep_range(osc->startup_usec, osc->startup_usec + 1);
+ if (system_state < SYSTEM_RUNNING)
+ udelay(osc->startup_usec);
+ else
+ usleep_range(osc->startup_usec, osc->startup_usec + 1);
osc->prepared = true;
return 0;
--
2.21.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
* [RFC PATCH] arm: dts: integratorap: Remove top level dma-ranges
From: Rob Herring @ 2019-09-20 15:36 UTC (permalink / raw)
To: Linus Walleij; +Cc: devicetree, linux-arm-kernel
'dma-ranges' at the top level doesn't make sense. 'dma-ranges' implies
there is a parent bus node with '#address-cells' and '#size-cells' which
is impossible here.
Likely this translation needs to be moved down to sub-nodes that need
it.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
This probably worked due to bugs in dma-ranges address translations (or
lack of).
AFAICT, only PCI needs dma-ranges. The TRM says inbound PCI addresses
are 1:1. So a translation from child address 0x80000000 to cpu address
0x0 seems wrong. The v3 PCI driver also fails to look at parent nodes
for dma-ranges.
arch/arm/boot/dts/integratorap.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/integratorap.dts b/arch/arm/boot/dts/integratorap.dts
index 94d2ff9836d0..198d66181c50 100644
--- a/arch/arm/boot/dts/integratorap.dts
+++ b/arch/arm/boot/dts/integratorap.dts
@@ -9,7 +9,6 @@
/ {
model = "ARM Integrator/AP";
compatible = "arm,integrator-ap";
- dma-ranges = <0x80000000 0x0 0x80000000>;
cpus {
#address-cells = <1>;
--
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] spi: atmel: Fix crash when using more than 4 gpio CS
From: Gregory CLEMENT @ 2019-09-20 15:27 UTC (permalink / raw)
To: Mark Brown, Alexandre Belloni
Cc: stable, linux-kernel, Ludovic Desroches, Thomas Petazzoni,
linux-spi, linux-arm-kernel
In-Reply-To: <20190920105101.GA3822@sirena.co.uk>
Hello Mark,
> On Thu, Sep 19, 2019 at 07:23:50PM +0200, Alexandre Belloni wrote:
>> On 19/09/2019 17:03:15+0100, Mark Brown wrote:
>
>> > This is going to break any system where we use both a GPIO chip select
>> > and chip select 0. Ideally we'd try to figure out an unused chip select
>> > to use here...
>
>> The point is that this use case is already broken and this patch fixes
>> the crash and is easily backportable.
>
>> Fixing the CS + gpio CS should probably be done in a separate patch.
>
> If the GPIO is overlaid on any of the existing slots (except GPIO 0)
> then it'll cause GPIO 0 to start toggling. I'm not convinced that the
> code doesn't currently support that.
Actually, the current code is not designed to mix CS and gpio CS, so
this patch doesn't introduce any regression on this side.
But after going further in the details of the driver, this patch could
cause a regression for on the old controllers.
I also found other issues in this driver in the chip select
management. So I will send a new series fixing all of it.
Gregory
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.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: [PATCH] drm: sun8i-ui/vi: Fix layer zpos change/atomic modesetting
From: Maxime Ripard @ 2019-09-20 15:11 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Chen-Yu Tsai, dri-devel,
linux-arm-kernel, linux-kernel
In-Reply-To: <20190919131244.35hmnp7jizegltp7@core.my.home>
On Thu, Sep 19, 2019 at 03:12:44PM +0200, Ondřej Jirman wrote:
> On Thu, Sep 19, 2019 at 02:20:58PM +0200, megous hlavni wrote:
> > On Wed, Sep 18, 2019 at 10:16:17PM +0200, Maxime Ripard wrote:
> > > On Wed, Sep 18, 2019 at 05:23:09PM +0200, Ondřej Jirman wrote:
> > > > Hi,
> > > >
> > > > On Wed, Sep 18, 2019 at 04:17:34PM +0200, Maxime Ripard wrote:
> > > > > Hi,
> > > > >
> > > > > On Sun, Sep 15, 2019 at 12:03:37AM +0200, megous@megous.com wrote:
> > > > > > From: Ondrej Jirman <megous@megous.com>
> > > > > >
> > > > > > There are various issues that this re-work of sun8i_[uv]i_layer_enable
> > > > > > function fixes:
> > > > > >
> > > > > > - Make sure that we re-initialize zpos on reset
> > > > > > - Minimize register updates by doing them only when state changes
> > > > > > - Fix issue where DE pipe might get disabled even if it is no longer
> > > > > > used by the layer that's currently calling sun8i_ui_layer_enable
> > > > > > - .atomic_disable callback is not really needed because .atomic_update
> > > > > > can do the disable too, so drop the duplicate code
> > > > > >
> > > > > > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > > > >
> > > > > It looks like these fixes should be in separate patches. Is there any
> > > > > reason it's not the case?
> > > >
> > > > Bullet points just describe the resulting effect/benefits of the change to fix
> > > > the pipe control register update issue (see the referenced e-mail).
> > >
> > > It's definitely ok to have multiple patches needed to address a single
> > > perceived issue.
> >
> > Yes, but I can't simply split the patch. In order for each change to work on its
> > own, they'd have to be done differently than the final result.
> >
> > I wouldn't mind at all if it was just a simple splitting, but you're asking
> > for too much work, this time, for no benefit that I can see.
> >
> > > A commit is not about what you're fixing but what you're changing. And
> > > the fact that you have tha bullet list in the first place proves that
> > > you have multiple logical changes in your patch.
> > >
> > > And even then, your commit log mentions that you're fixing multiple
> > > issues (without explaining them).
> >
> > I can reword the commit message if that helps, and skip the bullet list if it
> > is confusing. There's a single core issue and that is that the driver doesn't
> > update the pipe/channel configuration correctly leading to disabling of
> > arbitrary layers (not even those being updated - update of UI layer may disable
> > VI layer as a side effect for example) at wrong times. And only changes
> > necessary to debug/fix this are included.
>
> How about this:
>
> A problem was found where identical configuration of planes leads
> to different register settings at the HW layer when using a X server
> with modesetting driver and one plane marked as a cursor.
We don't have a cursor plane.
> On first run of the X server, only the black screen and the layer
> containing the cursor is visible. Switching to console and back
> corrects the situation.
>
> I have dumped registers, and found out this:
>
> (In both cases there are two enabled planes, plane 1 with zpos 0 and
> plane 3 with zpos 1).
>
> 1) First Xorg run:
>
> 0x01101000 : 00000201
> 0x01101080 : 00000030
>
> BLD_FILL_COLOR_CTL: (aka SUN8I_MIXER_BLEND_PIPE_CTL)
> P1_EN
>
> BLD_CH_RTCTL: (aka SUN8I_MIXER_BLEND_ROUTE)
> P0_RTCTL channel0
> P1_RTCTL channel3
>
> 2) After switch to console and back to Xorg:
>
> 0x01101000 : 00000301
> 0x01101080 : 00000031
>
> BLD_FILL_COLOR_CTL:
> P1_EN and P0_EN
>
> BLD_CH_RTCTL:
> P0_RTCTL channel1
> P1_RTCTL channel3
>
> What happens is that sun8i_ui_layer_enable() function may disable
> blending pipes even if it is no longer assigned to its layer, because
> of incorrect state/zpos tracking in the driver.
>
> In particular, layer 1 is configured to zpos 0 and thus uses pipe 0.
> When layer 3 is enabled by X server, sun8i_ui_layer_enable() will get
> called with old_zpos=0 zpos=1, which will lead to disabling of pipe 0.
>
> In general this issue can happen to any layer during enable or zpos
> changes on multiple layers at once.
>
> To correct this we now pass previous enabled/disabled state of the
> layer, and pass real previous zpos of the layer to
> sun8i_ui_layer_enable() and rework the sun8i_ui_layer_enable() function
> to react to the state changes correctly. In order to not complicate
> the atomic_disable callback with all of the above changes, we simply
> remove it and implement all the chanes as part of atomic_update, which
> also reduces the code duplication.
I'm not even sure why we need that old state. Can't we just reset
completely the whole thing and do the configuration all over again?
That description just looks to me like the reset is not done properly,
and now we have to deal with the fallouts later on.
> To make this all work, initial zpos positions of all layers need to be
> restored to initial values on reset.
And this also fixes a whole other bunch of issues, and can be made
very trivially in a separate patch.
Maxime
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] irqchip/stm32-exti: Use the hwspin_lock_timeout_in_atomic() API
From: Fabien Dessenne @ 2019-09-20 15:00 UTC (permalink / raw)
To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Maxime Coquelin,
Alexandre Torgue, linux-kernel, linux-stm32, linux-arm-kernel
Cc: Fabien Dessenne
Now that the hwspin_lock_timeout_in_atomic() API is available use it.
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
---
drivers/irqchip/irq-stm32-exti.c | 65 +++++++++++++---------------------------
1 file changed, 20 insertions(+), 45 deletions(-)
diff --git a/drivers/irqchip/irq-stm32-exti.c b/drivers/irqchip/irq-stm32-exti.c
index e00f2fa..7fc0d1f 100644
--- a/drivers/irqchip/irq-stm32-exti.c
+++ b/drivers/irqchip/irq-stm32-exti.c
@@ -25,7 +25,6 @@
#define IRQS_PER_BANK 32
#define HWSPNLCK_TIMEOUT 1000 /* usec */
-#define HWSPNLCK_RETRY_DELAY 100 /* usec */
struct stm32_exti_bank {
u32 imr_ofst;
@@ -277,55 +276,24 @@ static int stm32_exti_set_type(struct irq_data *d,
return 0;
}
-static int stm32_exti_hwspin_lock(struct stm32_exti_chip_data *chip_data)
-{
- int ret, timeout = 0;
-
- if (!chip_data->host_data->hwlock)
- return 0;
-
- /*
- * Use the x_raw API since we are under spin_lock protection.
- * Do not use the x_timeout API because we are under irq_disable
- * mode (see __setup_irq())
- */
- do {
- ret = hwspin_trylock_raw(chip_data->host_data->hwlock);
- if (!ret)
- return 0;
-
- udelay(HWSPNLCK_RETRY_DELAY);
- timeout += HWSPNLCK_RETRY_DELAY;
- } while (timeout < HWSPNLCK_TIMEOUT);
-
- if (ret == -EBUSY)
- ret = -ETIMEDOUT;
-
- if (ret)
- pr_err("%s can't get hwspinlock (%d)\n", __func__, ret);
-
- return ret;
-}
-
-static void stm32_exti_hwspin_unlock(struct stm32_exti_chip_data *chip_data)
-{
- if (chip_data->host_data->hwlock)
- hwspin_unlock_raw(chip_data->host_data->hwlock);
-}
-
static int stm32_irq_set_type(struct irq_data *d, unsigned int type)
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
struct stm32_exti_chip_data *chip_data = gc->private;
const struct stm32_exti_bank *stm32_bank = chip_data->reg_bank;
+ struct hwspinlock *hwlock = chip_data->host_data->hwlock;
u32 rtsr, ftsr;
int err;
irq_gc_lock(gc);
- err = stm32_exti_hwspin_lock(chip_data);
- if (err)
- goto unlock;
+ if (hwlock) {
+ err = hwspin_lock_timeout_in_atomic(hwlock, HWSPNLCK_TIMEOUT);
+ if (err) {
+ pr_err("%s can't get hwspinlock (%d)\n", __func__, err);
+ goto unlock;
+ }
+ }
rtsr = irq_reg_readl(gc, stm32_bank->rtsr_ofst);
ftsr = irq_reg_readl(gc, stm32_bank->ftsr_ofst);
@@ -338,7 +306,8 @@ static int stm32_irq_set_type(struct irq_data *d, unsigned int type)
irq_reg_writel(gc, ftsr, stm32_bank->ftsr_ofst);
unspinlock:
- stm32_exti_hwspin_unlock(chip_data);
+ if (hwlock)
+ hwspin_unlock_in_atomic(hwlock);
unlock:
irq_gc_unlock(gc);
@@ -504,15 +473,20 @@ static int stm32_exti_h_set_type(struct irq_data *d, unsigned int type)
{
struct stm32_exti_chip_data *chip_data = irq_data_get_irq_chip_data(d);
const struct stm32_exti_bank *stm32_bank = chip_data->reg_bank;
+ struct hwspinlock *hwlock = chip_data->host_data->hwlock;
void __iomem *base = chip_data->host_data->base;
u32 rtsr, ftsr;
int err;
raw_spin_lock(&chip_data->rlock);
- err = stm32_exti_hwspin_lock(chip_data);
- if (err)
- goto unlock;
+ if (hwlock) {
+ err = hwspin_lock_timeout_in_atomic(hwlock, HWSPNLCK_TIMEOUT);
+ if (err) {
+ pr_err("%s can't get hwspinlock (%d)\n", __func__, err);
+ goto unlock;
+ }
+ }
rtsr = readl_relaxed(base + stm32_bank->rtsr_ofst);
ftsr = readl_relaxed(base + stm32_bank->ftsr_ofst);
@@ -525,7 +499,8 @@ static int stm32_exti_h_set_type(struct irq_data *d, unsigned int type)
writel_relaxed(ftsr, base + stm32_bank->ftsr_ofst);
unspinlock:
- stm32_exti_hwspin_unlock(chip_data);
+ if (hwlock)
+ hwspin_unlock_in_atomic(hwlock);
unlock:
raw_spin_unlock(&chip_data->rlock);
--
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 v2] arm64: tegra: Add CPU and cache topology for Tegra194
From: Thierry Reding @ 2019-09-20 14:56 UTC (permalink / raw)
To: Thierry Reding; +Cc: linux-tegra, Joseph Lo, linux-arm-kernel, Jon Hunter
From: Thierry Reding <treding@nvidia.com>
Tegra194 has four CPU clusters, each with their own cache hierarchy.
This patch creates the CPU map for these clusters and adds the second-
and third-level caches and associates them with the CPUs.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v2:
- fix reg properties for CPU nodes and update unit-address to match
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 156 +++++++++++++++++++++--
1 file changed, 144 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index adebbbf36bd0..27bf0b7c3f6b 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -1442,60 +1442,192 @@
#address-cells = <1>;
#size-cells = <0>;
- cpu@0 {
+ cpu0_0: cpu@0 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
- reg = <0x10000>;
+ reg = <0x000>;
enable-method = "psci";
+ i-cache-size = <131072>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <512>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2c_0>;
};
- cpu@1 {
+ cpu0_1: cpu@1 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
- reg = <0x10001>;
+ reg = <0x001>;
enable-method = "psci";
+ i-cache-size = <131072>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <512>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2c_0>;
};
- cpu@2 {
+ cpu1_0: cpu@100 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
reg = <0x100>;
enable-method = "psci";
+ i-cache-size = <131072>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <512>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2c_1>;
};
- cpu@3 {
+ cpu1_1: cpu@101 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
reg = <0x101>;
enable-method = "psci";
+ i-cache-size = <131072>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <512>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2c_1>;
};
- cpu@4 {
+ cpu2_0: cpu@200 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
reg = <0x200>;
enable-method = "psci";
+ i-cache-size = <131072>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <512>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2c_2>;
};
- cpu@5 {
+ cpu2_1: cpu@201 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
reg = <0x201>;
enable-method = "psci";
+ i-cache-size = <131072>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <512>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2c_2>;
};
- cpu@6 {
+ cpu3_0: cpu@300 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
- reg = <0x10300>;
+ reg = <0x300>;
enable-method = "psci";
+ i-cache-size = <131072>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <512>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2c_3>;
};
- cpu@7 {
+ cpu3_1: cpu@301 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
- reg = <0x10301>;
+ reg = <0x301>;
enable-method = "psci";
+ i-cache-size = <131072>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <512>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2c_3>;
+ };
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0_0>;
+ };
+
+ core1 {
+ cpu = <&cpu0_1>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&cpu1_0>;
+ };
+
+ core1 {
+ cpu = <&cpu1_1>;
+ };
+ };
+
+ cluster2 {
+ core0 {
+ cpu = <&cpu2_0>;
+ };
+
+ core1 {
+ cpu = <&cpu2_1>;
+ };
+ };
+
+ cluster3 {
+ core0 {
+ cpu = <&cpu3_0>;
+ };
+
+ core1 {
+ cpu = <&cpu3_1>;
+ };
+ };
+ };
+
+ l2c_0: l2-cache0 {
+ cache-size = <2097152>;
+ cache-line-size = <64>;
+ cache-sets = <2048>;
+ next-level-cache = <&l3c>;
+ };
+
+ l2c_1: l2-cache1 {
+ cache-size = <2097152>;
+ cache-line-size = <64>;
+ cache-sets = <2048>;
+ next-level-cache = <&l3c>;
+ };
+
+ l2c_2: l2-cache2 {
+ cache-size = <2097152>;
+ cache-line-size = <64>;
+ cache-sets = <2048>;
+ next-level-cache = <&l3c>;
+ };
+
+ l2c_3: l2-cache3 {
+ cache-size = <2097152>;
+ cache-line-size = <64>;
+ cache-sets = <2048>;
+ next-level-cache = <&l3c>;
+ };
+
+ l3c: l3-cache {
+ cache-size = <4194304>;
+ cache-line-size = <64>;
+ cache-sets = <4096>;
};
};
--
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
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