* [PATCHv4 00/15] clk: ti: add support for hwmod clocks
From: Stephen Boyd @ 2016-12-13 0:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148156710975.37646.2957511113527634913@resonance>
On 12/12, Michael Turquette wrote:
> Quoting Tero Kristo (2016-12-02 00:15:53)
> > On 29/10/16 02:37, Stephen Boyd wrote:
> > > On 10/28, Tero Kristo wrote:
> > >> Eventually that should happen. However, we have plenty of legacy
> > >> code still in place which depend on clk_get functionality within
> > >> kernel. The major contributing factor is the hwmod codebase, for
> > >> which we have plans to:
> > >>
> > >> - get this clock driver merged
> > >> - implement a new interconnect driver for OMAP family SoCs
> > >> - interconnect driver will use DT handles for fetching clocks,
> > >> rather than clock aliases
> > >> - reset handling will be implemented as part of the interconnect
> > >> driver somehow (no prototype / clear plans for that as of yet)
> > >> - all the hwmod stuff can be dropped
> > >>
> > >> The clock alias handling is still needed as a transition phase until
> > >> all the above is done, then we can start dropping them. Basically
> > >> anything that is using omap_hwmod depends on the clock aliases right
> > >> now.
> > >
> > > Ok, sounds good. Thanks.
> >
> > Stephen, any final comments on this series? I guess its too late to push
> > for 4.10, but I would like to get this merged early for 4.11 window.
>
> Hi Tero,
>
> No final comments from me. I needed to go back and forth with Tony about
> the clockdomain modeling, but it seems sensible to create clock
> providers from the clock domains if you want to pass those struct clk
> objects down to the drivers.
>
> One thing I wasn't able to follow exactly in the code is how the
> clockdomains are linking parent clocks from cm1, cm2, etc to the clock
> domains. Are the clockdomain providers calling clk_get() on the clocks
> that it *consumes*, or are the clockdomain providers never calling
> clk_get() on those clocks and just establishing the tree hierarchy at
> clk_register() time?
>
> Unless Stephen has any more review comments we can merge this into a
> clk-next based on v4.10-rc1 when that drops.
>
I spent a bunch of time looking at this again today. From a DT
perspective we don't want to have clocks or clockdomains nodes
below the cm1/cm2/prm dt nodes. That's getting to the point of
describing individual elements of a device that should be
described in the driver instead of DT.
I'd also prefer we didn't have cm1/cm2/prm nodes and just had one
prcm node as the clock provider (#clock-cells) because that's the
aligned register address space that's visible on the bus. From
my perspective cm1/cm2/prm look like macros that are put inside
the prcm container and they're at least aligned on some register
address boundary so I'm not too worried if we keep describing
down to the level of these modules in DT. Anything beyond that is
not good though.
Finally we come to using clock providers or genpds for the clock
domains. If we don't put clockdomains into DT (because I don't
want clockdomain nodes) then this problem almost goes away. At
least, I don't really care what happens here because it will be
an internal TI prcm driver question of implementation. A clk
consumer will just see a provider that outputs some sort of clk.
If that happens to go through a clockdomain and we need to toggle
some bits inside the domain registers to make the clk actually
output a signal, that's fine. The prcm driver can take care of it
behind the scenes. Or at a later date we can model the domain as
a genpd and have the framework turn on/off genpds attached to
certain clocks. There's a lot of freedom here as long as we don't
put things in DT.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH net-next 19/27] net/bpf_jit: ARM: split VLAN_PRESENT bit handling from VLAN_TCI
From: Michał Mirosław @ 2016-12-13 0:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1481586602.git.mirq-linux@rere.qmqm.pl>
Signed-off-by: Micha? Miros?aw <mirq-linux@rere.qmqm.pl>
---
arch/arm/net/bpf_jit_32.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index 93d0b6d..6dbc602 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -915,17 +915,20 @@ static int build_body(struct jit_ctx *ctx)
emit(ARM_LDR_I(r_A, r_skb, off), ctx);
break;
case BPF_ANC | SKF_AD_VLAN_TAG:
- case BPF_ANC | SKF_AD_VLAN_TAG_PRESENT:
ctx->seen |= SEEN_SKB;
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, vlan_tci) != 2);
off = offsetof(struct sk_buff, vlan_tci);
emit(ARM_LDRH_I(r_A, r_skb, off), ctx);
- if (code == (BPF_ANC | SKF_AD_VLAN_TAG))
- OP_IMM3(ARM_AND, r_A, r_A, ~VLAN_TAG_PRESENT, ctx);
- else {
- OP_IMM3(ARM_LSR, r_A, r_A, 12, ctx);
- OP_IMM3(ARM_AND, r_A, r_A, 0x1, ctx);
- }
+#ifdef VLAN_TAG_PRESENT
+ OP_IMM3(ARM_AND, r_A, r_A, ~VLAN_TAG_PRESENT, ctx);
+#endif
+ break;
+ case BPF_ANC | SKF_AD_VLAN_TAG_PRESENT:
+ off = PKT_VLAN_PRESENT_OFFSET();
+ emit(ARM_LDRB_I(r_A, r_skb, off), ctx);
+ if (PKT_VLAN_PRESENT_BIT)
+ OP_IMM3(ARM_LSR, r_A, r_A, PKT_VLAN_PRESENT_BIT, ctx);
+ OP_IMM3(ARM_AND, r_A, r_A, 0x1, ctx);
break;
case BPF_ANC | SKF_AD_PKTTYPE:
ctx->seen |= SEEN_SKB;
--
2.10.2
^ permalink raw reply related
* [PATCH net-next 18/27] net/skbuff: add macros for VLAN_PRESENT bit
From: Michał Mirosław @ 2016-12-13 0:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1481586602.git.mirq-linux@rere.qmqm.pl>
Signed-off-by: Micha? Miros?aw <mirq-linux@rere.qmqm.pl>
---
include/linux/skbuff.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 332e767..4a85a1f 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -768,6 +768,12 @@ struct sk_buff {
__u32 priority;
int skb_iif;
__u32 hash;
+#define PKT_VLAN_PRESENT_BIT 4 // CFI (12-th bit) in TCI
+#ifdef __BIG_ENDIAN
+#define PKT_VLAN_PRESENT_OFFSET() offsetof(struct sk_buff, vlan_tci)
+#else
+#define PKT_VLAN_PRESENT_OFFSET() (offsetof(struct sk_buff, vlan_tci) + 1)
+#endif
__be16 vlan_proto;
__u16 vlan_tci;
#if defined(CONFIG_NET_RX_BUSY_POLL) || defined(CONFIG_XPS)
--
2.10.2
^ permalink raw reply related
* [PATCH 2/4] dt-bindings: mfd: Remove TPS65217 interrupts
From: Milo Kim @ 2016-12-12 23:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212172511.5nj7whzytpkmrk7z@rob-hp-laptop>
On 12/13/2016 02:25 AM, Rob Herring wrote:
> On Fri, Dec 09, 2016 at 03:28:31PM +0900, Milo Kim wrote:
>> Interrupt numbers are from the datasheet, so no need to keep them in
>> the ABI. Use the number in the DT file.
> I don't see the purpose of ripping this out. The headers have always
> been for convienence, not whether the values come from the datasheet or
> not.
My understanding is it's a same rule as other interrupt controllers.
I'd like to have Arnd's opinion for this.
Best regards,
Milo
^ permalink raw reply
* [PATCH] ARM: dts: sun8i: Support DTB build for NanoPi M1
From: Milo Kim @ 2016-12-12 23:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212154903.wy3vgp3grr3y3bs3@lukather>
On 12/13/2016 12:49 AM, Maxime Ripard wrote:
> Hi,
>
> On Fri, Dec 09, 2016 at 10:47:58AM +0900, Milo Kim wrote:
>> The commit 10efbf5f1633 introduced NanoPi M1 board but it's missing in
>> Allwinner H3 DTB build.
>>
>> Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
>
> checkpatch reports an error on this one (commit format), please fix
> and resend.
Thanks! I need to run the script automatically prior to sending patches.
Best regards,
Milo
^ permalink raw reply
* [PATCH resend] ARM: dts: sun8i: Support DTB build for NanoPi M1
From: Milo Kim @ 2016-12-12 23:18 UTC (permalink / raw)
To: linux-arm-kernel
The commit 10efbf5f1633 ("ARM: dts: sun8i: Add dts file for NanoPi M1 SBC")
introduced NanoPi M1 board but it's missing in Allwinner H3 DTB build.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cccdbcb..359041f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -845,6 +845,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
sun8i-a83t-cubietruck-plus.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
+ sun8i-h3-nanopi-m1.dtb \
sun8i-h3-nanopi-neo.dtb \
sun8i-h3-orangepi-2.dtb \
sun8i-h3-orangepi-lite.dtb \
--
2.9.3
^ permalink raw reply related
* [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range
From: Heinrich Schuchardt @ 2016-12-12 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212101801.28491-1-narmstrong@baylibre.com>
On 12/12/2016 11:18 AM, Neil Armstrong wrote:
> The Amlogic Meson GXBB secure monitor uses part of the memory space, this
> patch adds these reserved zones and redefines the usable memory range for
> each boards.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 21 +++++++++++++++++++++
> .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 2 +-
> .../boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 2 +-
> .../boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts | 2 +-
> .../boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 2 +-
> .../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 2 +-
> .../arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 +-
> 11 files changed, 31 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> index 7a078be..ac40b2d 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> @@ -56,7 +56,7 @@
>
> memory at 0 {
> device_type = "memory";
> - reg = <0x0 0x0 0x0 0x80000000>;
> + reg = <0x0 0x1000000 0x0 0x7f000000>;
> };
>
> vddio_boot: regulator-vddio_boot {
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> index fc033c0..e085588 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> @@ -55,6 +55,27 @@
> #address-cells = <2>;
> #size-cells = <2>;
>
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + secos: secos {
> + reg = <0x0 0x05300000 0x0 0x2000000>;
> + no-map;
> + };
Hello Neil,
In
https://github.com/hardkernel/linux/blob/odroidc2-3.14.y/arch/arm64/boot/dts/meson64_odroidc2.dts
the secos region does not exist. In linux-next I find no reference to
the secos label. Where is the consumer of the region defined?
> +
> + pstore: pstore {
> + reg = <0x0 0x07300000 0x0 0x100000>;
> + no-map;
> + };
In
https://github.com/hardkernel/linux/blob/odroidc2-3.14.y/arch/arm64/boot/dts/amlogic/gxbb_skt.dts
and other files pstore uses a different position
(reg = <0x0 0x20000000 0x0 0x100000>;).
Why are we moving this?
Should this region be marked
compatible = "ramoops"; ?
Cf. Documentation/devicetree/bindings/reserved-memory/ramoops.txt.
It would be nice if you could add a short description of each reserved
area to the commit message.
Regards
Heinrich Schuchardt
> +
> + secmon: secmon {
> + reg = <0x0 0x10000000 0x0 0x200000>;
> + no-map;
> + };
> + };
> +
> cpus {
> #address-cells = <0x2>;
> #size-cells = <0x0>;
^ permalink raw reply
* [PATCH v3 11/12] arm64: dts: marvell: add sdhci support for Armada 7K/8K
From: Marcin Wojtas @ 2016-12-12 21:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212191651.GV14217@n2100.armlinux.org.uk>
Hi Gregory,
2016-12-12 20:16 GMT+01:00 Russell King - ARM Linux <linux@armlinux.org.uk>:
> On Mon, Dec 12, 2016 at 05:37:56PM +0100, Gregory CLEMENT wrote:
>> Hi Russell King,
>>
>> On ven., d?c. 09 2016, Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
>>
>> > On Fri, Dec 09, 2016 at 11:30:07AM +0100, Gregory CLEMENT wrote:
>> >> Also enable it on the Armada 7040 DB board
>> >>
>> >> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> >
>> > Hi,
>> >
>> > Can this also be added to the cp110 on the 7k/8k SoCs as well, or does
>> > it rely on other unmerged support?
>>
>> I did not add this one because until now I had not the hardware setup
>> available to test it.
>>
>> But at least I can add the ressources in the device tree and now I can
>> test it partially.
>
> There's another option: add the DT resources in a separate patch, send
> it out for someone else to test. When it comes back with a tested-by,
> then it can be included along with the rest of the patch set.
I work on A7040-DB with SD slot from AP and CP eMMC. If you have the
board, you can use eMMC module from A3720-DB and plug it to CON11.
Some small soldering may be required. Anyway, you can also just let me
test it:)
Best regards,
Marcin
^ permalink raw reply
* [PATCH v2] usb: dwc3: omap: fix race of pm runtime with irq handler in probe
From: Tony Lindgren @ 2016-12-12 21:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212193752.32029-1-grygorii.strashko@ti.com>
* Grygorii Strashko <grygorii.strashko@ti.com> [161212 11:38]:
> Now races can happen between interrupt handler execution and PM runtime in
> error handling code path in probe and in dwc3_omap_remove() which will lead
> to system crash:
>
> in probe:
> ...
> err1:
> pm_runtime_put_sync(dev);
> ^^ PM runtime can race with IRQ handler when deferred probing happening
> due to extcon
> pm_runtime_disable(dev);
>
> return ret;
>
> in dwc3_omap_remove:
> ...
> dwc3_omap_disable_irqs(omap);
> ^^ IRQs are disabled in HW, but handler may still run
> of_platform_depopulate(omap->dev);
> pm_runtime_put_sync(&pdev->dev);
> ^^ PM runtime can race with IRQ handler
> pm_runtime_disable(&pdev->dev);
>
> return 0;
>
> So, OMAP DWC3 IRQ need to be disabled before calling
> pm_runtime_put() in probe and in dwc3_omap_remove().
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM.
From: Richard Cochran @ 2016-12-12 21:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <07C910AB6AC6C345A093D5A08F5AF568CB74D84D@CHN-SV-EXMX03.mchp-main.com>
On Mon, Dec 12, 2016 at 10:22:43AM +0000, Andrei.Pistirica at microchip.com wrote:
> Richard, are you agree with this?
Yes, but please trim your replies next time. Scrolling through pages
of quoted headers and stale content in order to read one line is very
annoying.
Thanks,
Richard
^ permalink raw reply
* [PATCH 0/2] ARM: v7-A !MMU fixes for fun (&fame)
From: Peter Korsgaard @ 2016-12-12 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212184429.GA5219@afzalpc>
>>>>> "Afzal" == Afzal Mohammed <afzal.mohd.ma@gmail.com> writes:
> Hi,
> On Sun, Dec 11, 2016 at 06:40:28PM +0530, Afzal Mohammed wrote:
>> Kernel reached the stage of invoking user space init & panicked, though
>> it could not reach till prompt for want of user space executables
>>
>> So far i have not come across a toolchain (or a way to create toolchain)
>> to create !MMU user space executables for Cortex-A.
> Now able to reach prompt using buildroot initramfs, Thanks to
> Peter Korsgaard for suggesting the way to create user space executables
> for !MMU Cortex-A.
Great, thats nice to hear!
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH v3 11/12] arm64: dts: marvell: add sdhci support for Armada 7K/8K
From: Thomas Petazzoni @ 2016-12-12 20:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212191651.GV14217@n2100.armlinux.org.uk>
Hello,
On Mon, 12 Dec 2016 19:16:51 +0000, Russell King - ARM Linux wrote:
> I'd send something, but I don't know what the GIC interrupt number
> would be without using the CP110's ICU (which isn't supported in
> mainline yet.)
For now, mainline relies on a static mapping of CP interrupts to GIC
interrupts, via an ICU configuration done in ATF. It's pretty
straightforward to figure out the CP interrupts to GIC interrupt
mapping if you have access to the ATF source code. If you don't, I can
provide the necessary details.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 16/16] drivers/fsi: Add GPIO based FSI master
From: Christopher Bostic @ 2016-12-12 19:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6a39f4d9-0f20-a146-3122-86d3f75c58fa@ozlabs.org>
On Thu, Dec 8, 2016 at 10:12 PM, Jeremy Kerr <jk@ozlabs.org> wrote:
> Hi Chris,
>
>> +static ssize_t store_scan(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf,
>> + size_t count)
>> +{
>> + struct fsi_master_gpio *master = dev_get_drvdata(dev);
>> +
>> + fsi_master_gpio_init(master);
>> +
>> + /* clear out any old scan data if present */
>> + fsi_master_unregister(&master->master);
>> + fsi_master_register(&master->master);
>> +
>> + return count;
>> +}
>> +
>> +static DEVICE_ATTR(scan, 0200, NULL, store_scan);
>
> I think it would make more sense to have the scan attribute populated by
> the fsi core; we want this on all masters, not just GPIO.
>
Hi Jeremy,
Sure, will move that to the core.
> Currently, the only GPIO-master-specific functionality here is the
> fsi_master_gpio_init() - but isn't this something that we can do at
> probe time instead?
>
Yes that can be done at probe time. Will change.
>> +static int fsi_master_gpio_probe(struct platform_device *pdev)
>> +{
>> + struct fsi_master_gpio *master;
>> + struct gpio_desc *gpio;
>> +
>> + master = devm_kzalloc(&pdev->dev, sizeof(*master), GFP_KERNEL);
>> + if (!master)
>> + return -ENOMEM;
>
> We should be populating master->dev.parent, see
>
> https://github.com/jk-ozlabs/linux/commit/5225d6c47
>
>
Will make the change.
>> + /* Optional pins */
>> +
>> + gpio = devm_gpiod_get(&pdev->dev, "trans", 0);
>> + if (IS_ERR(gpio))
>> + dev_dbg(&pdev->dev, "probe: failed to get trans pin\n");
>> + else
>> + master->gpio_trans = gpio;
>
> I found devm_gpiod_get_optional(), which might make this a little
> neater.
Will make this change.
Thanks,
Chris
>
> Cheers,
>
>
> Jeremy
^ permalink raw reply
* [PATCH 3/3] clk: keystone: Add sci-clk driver support
From: Stephen Boyd @ 2016-12-12 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22dacb0c-a3bc-50ce-e4b9-f74a0c706f20@ti.com>
On 12/09, Tero Kristo wrote:
> On 08/12/16 23:10, Stephen Boyd wrote:
> >On 12/08, Tero Kristo wrote:
> >>On 08/12/16 02:13, Stephen Boyd wrote:
> >>>On 10/21, Tero Kristo wrote:
> >>>>diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c
> >>>>new file mode 100644
> >>>>index 0000000..f6af5bd
> >>>>--- /dev/null
> >>>>+++ b/drivers/clk/keystone/sci-clk.c
> >>
> >>>
> >>>>+
> >>>>+ handle = devm_ti_sci_get_handle(dev);
> >>>>+ if (IS_ERR(handle))
> >>>>+ return PTR_ERR(handle);
> >>>>+
> >>>>+ provider = devm_kzalloc(dev, sizeof(*provider), GFP_KERNEL);
> >>>>+ if (!provider)
> >>>>+ return -ENOMEM;
> >>>>+
> >>>>+ provider->clocks = data;
> >>>>+
> >>>>+ provider->sci = handle;
> >>>>+ provider->ops = &handle->ops.clk_ops;
> >>>>+ provider->dev = dev;
> >>>>+
> >>>>+ ti_sci_init_clocks(provider);
> >>>
> >>>And if this fails?
> >>
> >>Yea this is kind of controversial. ti_sci_init_clocks() can fail if
> >>any of the clocks registered will fail. I decided to have it this
> >>way so that at least some clocks might work in failure cause, and
> >>you might have a booting device instead of total lock-up.
> >>
> >>Obviously it could be done so that if any clock fails, we would
> >>de-register all clocks at that point, but personally I think this is
> >>a worse option.
> >>
> >>ti_sci_init_clocks could probably be modified to continue
> >>registering clocks when a single clock fails though. Currently it
> >>aborts at first failure.
> >>
> >
> >That sounds like a better approach if we don't care about
> >failures to register a clock. Returning a value from a function
> >and not using it isn't really a great design.
> >
> >I worry that if we start returning errors from clk_hw_register()
> >that something will go wrong though, so really I don't know why
> >we want to ignore errors at all. Just for debugging a boot hang?
> >Can't we use early console to at least see that this driver is
> >failing to probe and debug that way?
>
> Early console can be used to debug that, but it is kind of annoying
> to recompile most of the kernel when you suddenly need to use it.
I thought SERIAL_EARLYCON was selected by drivers that support
it? So there shouldn't be any rebuilding required.
>
> How about modifying the ti_sci_init_clocks func to print an error
> for each failed clock?
Ok that's fine too. I'd prefer the function had a return type of
void if we're not planning on using the return value, that's all.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2] usb: dwc3: omap: fix race of pm runtime with irq handler in probe
From: Grygorii Strashko @ 2016-12-12 19:37 UTC (permalink / raw)
To: linux-arm-kernel
Now races can happen between interrupt handler execution and PM runtime in
error handling code path in probe and in dwc3_omap_remove() which will lead
to system crash:
in probe:
...
err1:
pm_runtime_put_sync(dev);
^^ PM runtime can race with IRQ handler when deferred probing happening
due to extcon
pm_runtime_disable(dev);
return ret;
in dwc3_omap_remove:
...
dwc3_omap_disable_irqs(omap);
^^ IRQs are disabled in HW, but handler may still run
of_platform_depopulate(omap->dev);
pm_runtime_put_sync(&pdev->dev);
^^ PM runtime can race with IRQ handler
pm_runtime_disable(&pdev->dev);
return 0;
So, OMAP DWC3 IRQ need to be disabled before calling
pm_runtime_put() in probe and in dwc3_omap_remove().
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
Link on v1:
http://www.spinics.net/lists/linux-omap/msg133846.html
drivers/usb/dwc3/dwc3-omap.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 29e80cc..eb1b9cb 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -19,6 +19,7 @@
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/slab.h>
+#include <linux/irq.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
#include <linux/platform_data/dwc3-omap.h>
@@ -510,7 +511,7 @@ static int dwc3_omap_probe(struct platform_device *pdev)
/* check the DMA Status */
reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
-
+ irq_set_status_flags(omap->irq, IRQ_NOAUTOEN);
ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
dwc3_omap_interrupt_thread, IRQF_SHARED,
"dwc3-omap", omap);
@@ -531,7 +532,7 @@ static int dwc3_omap_probe(struct platform_device *pdev)
}
dwc3_omap_enable_irqs(omap);
-
+ enable_irq(omap->irq);
return 0;
err2:
@@ -552,6 +553,7 @@ static int dwc3_omap_remove(struct platform_device *pdev)
extcon_unregister_notifier(omap->edev, EXTCON_USB, &omap->vbus_nb);
extcon_unregister_notifier(omap->edev, EXTCON_USB_HOST, &omap->id_nb);
dwc3_omap_disable_irqs(omap);
+ disable_irq(omap->irq);
of_platform_depopulate(omap->dev);
pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
--
2.10.1
^ permalink raw reply related
* [RESEND PATCH V6 0/6] Add support for privileged mappings
From: Sricharan @ 2016-12-12 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ad7a90ce-c1cd-856e-8573-394c05fda6e4@arm.com>
Hi Robin,
>Hi Robin,
>
>>>> Hi Sricharan,
>>>>
>>>> On 02/12/16 14:55, Sricharan R wrote:
>>>>> This series is a resend of the V5 that Mitch sent sometime back [2]
>>>>> All the patches are the same and i have just rebased. Not sure why this
>>>>> finally did not make it last time. The last patch in the previous
>>>>> series does not apply now [3], so just redid that. Also Copied the tags
>>>>> that he had from last time as well.
>>>>
>>>> Heh, I was assuming this would be down to me to pick up. Vinod did have
>>>> some complaints last time about the commit message on the PL330 patch -
>>>> I did get as far as rewriting that and reworking onto my SMMU
>>>> changes[1], I just hadn't got round to sending it, so it fell onto the
>>>> "after the next merge window" pile.
>>>>
>>>> I'd give some review comments, but they'd essentially be a diff against
>>>> that branch :)
>>>>
>>>
>>> Sure, i did not knew that you were on this already. I can repost with the diff
>>> from your branch taken in or wait for you as well. I am fine with either ways
>>> that you suggest.
>>>
>>> I checked the patches against your branch, i see that the changes are,
>>>
>>> 1) one patch for implementing it for armv7s descriptor
>>> 2) Changes on pl330 patch commit logs and
>>> 3) One patch for doing the revert on arm-smmuv3 as well.
>>
>>If you want to pick up my short-descriptor and SMMUv3 patches and run
>>with them you're more than welcome - the rest is just cosmetic stuff
>>which doesn't really matter, especially as it's picking up acks as-is.
>>
>
>Sure, i will repost with additional stuff picked up from your branch and
>the acks as well.
Posted V7 [1], while i tested the additional short descriptor changes,
but was not able to get hold of board with arm-smmuv3 in it.
[1] https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1291140.html
Regards,
Sricharan
^ permalink raw reply
* [PATCH v6 5/8] IIO: add bindings for STM32 timer trigger driver
From: Rob Herring @ 2016-12-12 19:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481292919-26587-6-git-send-email-benjamin.gaignard@st.com>
On Fri, Dec 09, 2016 at 03:15:16PM +0100, Benjamin Gaignard wrote:
> Define bindings for STM32 timer trigger
>
> version 4:
> - remove triggers enumeration from DT
> - add reg parameter
>
> version 3:
> - change file name
> - add cross reference with mfd bindings
>
> version 2:
> - only keep one compatible
> - add DT parameters to set lists of the triggers:
> one list describe the triggers created by the device
> another one give the triggers accepted by the device
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../bindings/iio/timer/stm32-timer-trigger.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
Other than same comments I made in the other patches for the example,
looks fine.
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] clk: bcm: Fix 'maybe-uninitialized' warning in bcm2835_clock_choose_div_and_prate()
From: Stephen Boyd @ 2016-12-12 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481529653-28133-1-git-send-email-boris.brezillon@free-electrons.com>
On 12/12, Boris Brezillon wrote:
> best_rate is reported as potentially uninitialized by gcc.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> Fixes: 155e8b3b0ee3 ("clk: bcm: Support rate change propagation on bcm2835 clocks")
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 11/12] arm64: dts: marvell: add sdhci support for Armada 7K/8K
From: Russell King - ARM Linux @ 2016-12-12 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87bmwhdrx7.fsf@free-electrons.com>
On Mon, Dec 12, 2016 at 05:37:56PM +0100, Gregory CLEMENT wrote:
> Hi Russell King,
>
> On ven., d?c. 09 2016, Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
>
> > On Fri, Dec 09, 2016 at 11:30:07AM +0100, Gregory CLEMENT wrote:
> >> Also enable it on the Armada 7040 DB board
> >>
> >> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> >
> > Hi,
> >
> > Can this also be added to the cp110 on the 7k/8k SoCs as well, or does
> > it rely on other unmerged support?
>
> I did not add this one because until now I had not the hardware setup
> available to test it.
>
> But at least I can add the ressources in the device tree and now I can
> test it partially.
There's another option: add the DT resources in a separate patch, send
it out for someone else to test. When it comes back with a tested-by,
then it can be included along with the rest of the patch set.
I'd send something, but I don't know what the GIC interrupt number
would be without using the CP110's ICU (which isn't supported in
mainline yet.) I've already tested your previous patch set (along with
ICU support + needed DT bits) on the SR Macchiatobin board... it seems
to work fine.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v6 3/8] PWM: add pwm-stm32 DT bindings
From: Rob Herring @ 2016-12-12 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481292919-26587-4-git-send-email-benjamin.gaignard@st.com>
On Fri, Dec 09, 2016 at 03:15:14PM +0100, Benjamin Gaignard wrote:
> Define bindings for pwm-stm32
>
> version 6:
> - change st,breakinput parameter format to make it usuable on stm32f7 too.
>
> version 2:
> - use parameters instead of compatible of handle the hardware configuration
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> new file mode 100644
> index 0000000..866f222
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> @@ -0,0 +1,33 @@
> +STMicroelectronics STM32 Timers PWM bindings
> +
> +Must be a sub-node of an STM32 Timers device tree node.
> +See ../mfd/stm32-timers.txt for details about the parent node.
> +
> +Required parameters:
> +- compatible: Must be "st,stm32-pwm".
> +- pinctrl-names: Set to "default".
> +- pinctrl-0: List of phandles pointing to pin configuration nodes for PWM module.
> + For Pinctrl properties see ../pinctrl/pinctrl-bindings.txt
> +
> +Optional parameters:
> +- st,breakinput: Arrays of three u32 <index level filter> to describe break input configurations.
> + "index" indicates on which break input the configuration should be applied.
> + "level" gives the active level (0=low or 1=high) for this configuration.
> + "filter" gives the filtering value to be applied.
> +
> +Example:
> + timers at 40010000 {
timer at ...
With that,
Acked-by: Rob Herring <robh@kernel.org>
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + pinctrl-0 = <&pwm1_pins>;
> + pinctrl-names = "default";
> + st,breakinput = <0 1 5>;
> + };
> + };
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH v6 7/8] ARM: dts: stm32: add Timers driver for stm32f429 MCU
From: Rob Herring @ 2016-12-12 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481292919-26587-8-git-send-email-benjamin.gaignard@st.com>
On Fri, Dec 09, 2016 at 03:15:18PM +0100, Benjamin Gaignard wrote:
> Add Timers and it sub-nodes into DT for stm32f429 family.
>
> version 6:
> - split patch in two: one for SoC family and one for stm32f469
> discovery board.
>
> version 5:
> - rename gptimer node to timers
> - re-order timers node par addresses
>
> version 4:
> - remove unwanted indexing in pwm@ and timer@ node name
> - use "reg" instead of additional parameters to set timer
> configuration
>
> version 3:
> - use "st,stm32-timer-trigger" in DT
>
> version 2:
> - use parameters to describe hardware capabilities
> - do not use references for pwm and iio timer subnodes
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> arch/arm/boot/dts/stm32f429.dtsi | 275 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 275 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index bca491d..d0fb9cc 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -355,6 +355,21 @@
> slew-rate = <2>;
> };
> };
> +
> + pwm1_pins: pwm at 1 {
No reg prop, so should not have a unit-address. Given the names in the
define below, seems like "timer1" would be appropriate.
> + pins {
> + pinmux = <STM32F429_PA8_FUNC_TIM1_CH1>,
> + <STM32F429_PB13_FUNC_TIM1_CH1N>,
> + <STM32F429_PB12_FUNC_TIM1_BKIN>;
> + };
> + };
> +
> + pwm3_pins: pwm at 3 {
> + pins {
> + pinmux = <STM32F429_PB4_FUNC_TIM3_CH1>,
> + <STM32F429_PB5_FUNC_TIM3_CH2>;
> + };
> + };
> };
>
> rcc: rcc at 40023810 {
> @@ -426,6 +441,266 @@
> interrupts = <80>;
> clocks = <&rcc 0 38>;
> };
> +
> + timers2: timers at 40000000 {
timer at ...
It may be more than just a timer, there's not a better generic name.
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40000000 0x400>;
> + clocks = <&rcc 0 128>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <1>;
> + status = "disabled";
> + };
> + };
> +
> + timers3: timers at 40000400 {
ditto
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40000400 0x400>;
> + clocks = <&rcc 0 129>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <2>;
> + status = "disabled";
> + };
> + };
> +
> + timers4: timers at 40000800 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40000800 0x400>;
> + clocks = <&rcc 0 130>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <3>;
> + status = "disabled";
> + };
> + };
> +
> + timers5: timers at 40000C00 {
timer at ...
And use lowercase hex.
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40000C00 0x400>;
ditto
> + clocks = <&rcc 0 131>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <4>;
> + status = "disabled";
> + };
> + };
> +
> + timers6: timers at 40001000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40001000 0x400>;
> + clocks = <&rcc 0 132>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <5>;
> + status = "disabled";
> + };
> + };
> +
> + timers7: timers at 40001400 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40001400 0x400>;
> + clocks = <&rcc 0 133>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <6>;
> + status = "disabled";
> + };
> + };
> +
> + timers12: timers at 40001800 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40001800 0x400>;
> + clocks = <&rcc 0 134>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <9>;
> + status = "disabled";
> + };
> + };
> +
> + timers13: timers at 40001C00 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40001C00 0x400>;
> + clocks = <&rcc 0 135>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> + };
> +
> + timers14: timers at 40002000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40002000 0x400>;
> + clocks = <&rcc 0 136>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> + };
> +
> + timers1: timers at 40010000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <0>;
> + status = "disabled";
> + };
> + };
> +
> + timers8: timers at 40010400 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40010400 0x400>;
> + clocks = <&rcc 0 161>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <7>;
> + status = "disabled";
> + };
> + };
> +
> + timers9: timers at 40014000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40014000 0x400>;
> + clocks = <&rcc 0 176>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <8>;
> + status = "disabled";
> + };
> + };
> +
> + timers10: timers at 40014400 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40014400 0x400>;
> + clocks = <&rcc 0 177>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> + };
> +
> + timers11: timers at 40014800 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40014800 0x400>;
> + clocks = <&rcc 0 178>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> + };
> };
> };
>
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH v6 1/8] MFD: add bindings for STM32 Timers driver
From: Rob Herring @ 2016-12-12 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481292919-26587-2-git-send-email-benjamin.gaignard@st.com>
On Fri, Dec 09, 2016 at 03:15:12PM +0100, Benjamin Gaignard wrote:
> Add bindings information for STM32 Timers
>
> version 6:
> - rename stm32-gtimer to stm32-timers
> - change compatible
> - add description about the IPs
>
> version 2:
> - rename stm32-mfd-timer to stm32-gptimer
> - only keep one compatible string
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../devicetree/bindings/mfd/stm32-timers.txt | 46 ++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> new file mode 100644
> index 0000000..b30868e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> @@ -0,0 +1,46 @@
> +STM32 Timers driver bindings
> +
> +This IP provides 3 types of timer along with PWM functionality:
> +- advanced-control timers consist of a 16-bit auto-reload counter driven by a programmable
> + prescaler, break input feature, PWM outputs and complementary PWM ouputs channels.
> +- general-purpose timers consist of a 16-bit or 32-bit auto-reload counter driven by a
> + programmable prescaler and PWM outputs.
> +- basic timers consist of a 16-bit auto-reload counter driven by a programmable prescaler.
> +
> +Required parameters:
> +- compatible: must be "st,stm32-timers"
> +
> +- reg: Physical base address and length of the controller's
> + registers.
> +- clock-names: Set to "clk_int".
'clk' is redundant. Also, you don't really need -names when there is
only one of them.
> +- clocks: Phandle to the clock used by the timer module.
> + For Clk properties, please refer to ../clock/clock-bindings.txt
> +
> +Optional parameters:
> +- resets: Phandle to the parent reset controller.
> + See ../reset/st,stm32-rcc.txt
> +
> +Optional subnodes:
> +- pwm: See ../pwm/pwm-stm32.txt
> +- timer: See ../iio/timer/stm32-timer-trigger.txt
> +
> +Example:
> + timers at 40010000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + pinctrl-0 = <&pwm1_pins>;
> + pinctrl-names = "default";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <0>;
You don't need reg here as there is only one. In turn, you don't need
#address-cells or #size-cells.
> + };
> + };
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 0/2] ARM: v7-A !MMU fixes for fun (&fame)
From: Afzal Mohammed @ 2016-12-12 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211131028.3019-1-afzal.mohd.ma@gmail.com>
Hi,
On Sun, Dec 11, 2016 at 06:40:28PM +0530, Afzal Mohammed wrote:
> Kernel reached the stage of invoking user space init & panicked, though
> it could not reach till prompt for want of user space executables
>
> So far i have not come across a toolchain (or a way to create toolchain)
> to create !MMU user space executables for Cortex-A.
Now able to reach prompt using buildroot initramfs, Thanks to
Peter Korsgaard for suggesting the way to create user space executables
for !MMU Cortex-A.
> multi_v7_defconfig was used & all platforms except TI OMAP/AM/DM/DRA &
> Freescale i.MX family was deselected. ARM_MPU option was disabled as
> Vladimir had given an early warning. DRAM_BASE was set to 0x80000000.
> During the course of bringup, futex was causing issues, hence FUTEX was
> removed. L1 & L2 caches were disabled in config. High vectors were
> disabled & vectors were made to remap to base of RAM. An additional OMAP
> specific change to avoid one ioremap was also required.
For the sake of completeness,
SMP was disabled & flat binary support enabled in Kernel.
Regards
afzal
^ permalink raw reply
* [PATCH v2 04/11] Documentation: DT: binding: axp20x_usb_power: add axp223 compatible
From: Rob Herring @ 2016-12-12 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209110419.28981-5-quentin.schulz@free-electrons.com>
On Fri, Dec 09, 2016 at 12:04:12PM +0100, Quentin Schulz wrote:
> This adds the "x-powers,axp223-usb-power-supply" to the list of
> compatibles for AXP20X VBUS power supply driver.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
>
> v2:
> - adding small explanation on AXP223 variation compared to the AXP221,
>
> Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt | 5 +++++
> 1 file changed, 5 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH V7 8/8] iommu/arm-smmu: Revert "iommu/arm-smmu: Set PRIVCFG in stage 1 STEs"
From: Sricharan R @ 2016-12-12 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481567927-14791-1-git-send-email-sricharan@codeaurora.org>
From: Robin Murphy <robin.murphy@arm.com>
Now that proper privileged mappings can be requested via IOMMU_PRIV,
unconditionally overriding the incoming PRIVCFG becomes the wrong thing
to do, so stop it.
This reverts commit df5e1a0f2a2d779ad467a691203bcbc74d75690e.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/arm-smmu-v3.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 257a6a3..0eca0553 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -269,9 +269,6 @@
#define STRTAB_STE_1_SHCFG_INCOMING 1UL
#define STRTAB_STE_1_SHCFG_SHIFT 44
-#define STRTAB_STE_1_PRIVCFG_UNPRIV 2UL
-#define STRTAB_STE_1_PRIVCFG_SHIFT 48
-
#define STRTAB_STE_2_S2VMID_SHIFT 0
#define STRTAB_STE_2_S2VMID_MASK 0xffffUL
#define STRTAB_STE_2_VTCR_SHIFT 32
@@ -1073,9 +1070,7 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_device *smmu, u32 sid,
#ifdef CONFIG_PCI_ATS
STRTAB_STE_1_EATS_TRANS << STRTAB_STE_1_EATS_SHIFT |
#endif
- STRTAB_STE_1_STRW_NSEL1 << STRTAB_STE_1_STRW_SHIFT |
- STRTAB_STE_1_PRIVCFG_UNPRIV <<
- STRTAB_STE_1_PRIVCFG_SHIFT);
+ STRTAB_STE_1_STRW_NSEL1 << STRTAB_STE_1_STRW_SHIFT);
if (smmu->features & ARM_SMMU_FEAT_STALLS)
dst[1] |= cpu_to_le64(STRTAB_STE_1_S1STALLD);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ 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