* [PATCH v2 0/6] Support PWM polarity control
From: Stefan Agner @ 2016-10-05 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004094805.466ebc6d@jawa>
Hi Lukasz,
On 2016-10-04 00:48, Lukasz Majewski wrote:
> Dear Bhuvanchandra,
>
> Thank you for your effort to send those patches to ML.
>
>> Changes since v2:
>>
>> - Picked the stalled patchset[1] from Lothar Wassmann which adds the
>> basic support for polarity control on imx-pwm driver and adds
>> backward compatibility support for devices which does not have
>> polarity control feature.
>>
>> Changes since Lothars v6:
>>
>> - Squash Lukasz patch[2].
>>
>> [1] http://thread.gmane.org/gmane.linux.pwm/1621
>> [2] https://www.spinics.net/lists/arm-kernel/msg530818.html
>>
>> Bhuvanchandra DV (3):
>> arm: dts: imx7: Update #pwm-cells for PWM polarity control
>> arm: dts: imx7-colibri: Use pwm polarity control
>> arm: dts: imx7-colibri: Use enable-gpios for BL_ON
>>
>> Lothar Wassmann (3):
>> pwm: print error messages with pr_err() instead of pr_debug()
>> pwm: core: make the PWM_POLARITY flag in DTB optional
>> pwm: imx: support output polarity inversion
>
> For some reason this patchset works differently than the one developed
> by Lothar.
>
> The difference is with the brightness level control.
>
> My brightness definition in DTS:
>
> pwms = <&pwm2 0 5000000 PWM_POLARITY_INVERTED>;
>
> brightness-levels = < 0 1 2 3 4 5 6 7 8 9
>
> .. ............
> 250 251 252 253 254 255>;
> default-brightness-level = <50>;
> enable-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
>
If you are using something else than i.MX 7 you also want to update the
SoC level device tree, specifically change the pwm-cells property:
#pwm-cells = <3>;
> When I go to the backlight sysfs entry:
>
> cd /sys/devices/soc0/backlight/backlight/backlight
>
> It seems like the brightness level control is inverted - i.e.
> 'echo 20 > brightness" makes picture on the screen very bright, and
> 'echo 200 > brightness' makes the picture diminish.
>
> With my "internal" patches the situation is opposite (and I've checked it with
> my HW connections).
Just to check whether the driver actually applies the polarity you can
add a #define DEBUG at the top of the driver (drivers/pwm/pwm-imx.c) and
pass ignore_loglevel as kernel command line. This should give you "PWM
supports output inversion" at startup and a "... polarity set to .."
message whenever the polarity is set.
--
Stefan
>
> Could you check on your setup if similar situation takes place? I mean
> if the brightness control works as expected?
>
> Thanks in advance,
> ?ukasz Majewski
>
>>
>> Documentation/devicetree/bindings/pwm/imx-pwm.txt | 6 +--
>> arch/arm/boot/dts/imx7-colibri.dtsi | 12 +++++-
>> arch/arm/boot/dts/imx7s.dtsi | 8 ++--
>> drivers/pwm/core.c | 31 ++++++++------
>> drivers/pwm/pwm-imx.c | 51
>> +++++++++++++++++++++-- 5 files changed, 83 insertions(+), 25
>> deletions(-)
>>
^ permalink raw reply
* [PATCH 5/7] arm64/kvm: hyp: tlb: use __tlbi() helper
From: Matthias Brugger @ 2016-10-05 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473761769-30572-6-git-send-email-punit.agrawal@arm.com>
On 13/09/16 12:16, Punit Agrawal wrote:
> From: Mark Rutland <mark.rutland@arm.com>
>
> Now that we have a __tlbi() helper, make use of this in the arm64 KVM hyp
> code to get rid of asm() boilerplate. At the same time, we simplify
> __tlb_flush_vm_context by using __flush_icache_all(), as this has the
> appropriate instruction cache maintenance and barrier.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> [ rename tlbi -> __tlbi, convert additional sites, update commit log ]
> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
> arch/arm64/kvm/hyp/tlb.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/tlb.c b/arch/arm64/kvm/hyp/tlb.c
> index be8177c..4cda100 100644
> --- a/arch/arm64/kvm/hyp/tlb.c
> +++ b/arch/arm64/kvm/hyp/tlb.c
> @@ -16,6 +16,7 @@
> */
>
> #include <asm/kvm_hyp.h>
> +#include <asm/tlbflush.h>
>
> static void __hyp_text __tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
> {
> @@ -32,7 +33,7 @@ static void __hyp_text __tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
> * whole of Stage-1. Weep...
> */
> ipa >>= 12;
> - asm volatile("tlbi ipas2e1is, %0" : : "r" (ipa));
> + __tlbi(ipas2e1is, ipa);
>
> /*
> * We have to ensure completion of the invalidation at Stage-2,
> @@ -41,7 +42,7 @@ static void __hyp_text __tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
> * the Stage-1 invalidation happened first.
> */
> dsb(ish);
> - asm volatile("tlbi vmalle1is" : : );
> + __tlbi(vmalle1is);
> dsb(ish);
> isb();
>
> @@ -60,7 +61,7 @@ static void __hyp_text __tlb_flush_vmid(struct kvm *kvm)
> write_sysreg(kvm->arch.vttbr, vttbr_el2);
> isb();
>
> - asm volatile("tlbi vmalls12e1is" : : );
> + __tlbi(vmalls12e1is);
> dsb(ish);
> isb();
>
> @@ -72,9 +73,8 @@ __alias(__tlb_flush_vmid) void __kvm_tlb_flush_vmid(struct kvm *kvm);
> static void __hyp_text __tlb_flush_vm_context(void)
> {
> dsb(ishst);
> - asm volatile("tlbi alle1is \n"
> - "ic ialluis ": : );
> - dsb(ish);
> + __tlbi(alle1is);
> + __flush_icache_all(); /* contains a dsb(ish) */
> }
>
> __alias(__tlb_flush_vm_context) void __kvm_flush_vm_context(void);
>
^ permalink raw reply
* [PATCH v2] arm: Added support for getcpu() vDSO using TPIDRURW
From: Fredrik Markström @ 2016-10-05 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKdL+dS4_My6hyMEGNc65mzDapia_tMiVzZ9DMw=ddZM+XiwAw@mail.gmail.com>
The approach I suggested below with the vDSO data page will obviously
not work on smp, so suggestions are welcome.
/Fredrik
On Wed, Oct 5, 2016 at 2:25 PM, Fredrik Markstr?m
<fredrik.markstrom@gmail.com> wrote:
> On Tue, Oct 4, 2016 at 7:08 PM Mark Rutland <mark.rutland@arm.com> wrote:
>>
>> On Tue, Oct 04, 2016 at 05:35:33PM +0200, Fredrik Markstrom wrote:
>> > This makes getcpu() ~1000 times faster, this is very useful when
>> > implementing per-cpu buffers in userspace (to avoid cache line
>> > bouncing). As an example lttng ust becomes ~30% faster.
>> >
>> > The patch will break applications using TPIDRURW (which is context switched
>> > since commit 4780adeefd042482f624f5e0d577bf9cdcbb760 ("ARM: 7735/2:
>>
>> It looks like you dropped the leading 'a' from the commit ID. For
>> everyone else's benefit, the full ID is:
>>
>> a4780adeefd042482f624f5e0d577bf9cdcbb760
>
>
> Sorry for that and thanks for fixing it.
>
>>
>>
>> Please note that arm64 has done similar for compat tasks since commit:
>>
>> d00a3810c16207d2 ("arm64: context-switch user tls register tpidr_el0 for
>> compat tasks")
>>
>> > Preserve the user r/w register TPIDRURW on context switch and fork")) and
>> > is therefore made configurable.
>>
>> As you note above, this is an ABI break and *will* break some existing
>> applications. That's generally a no-go.
>
>
> Ok, I wasn't sure this was considered an ABI (but I'm not entirely
> surprised ;) ). The way I was
> trying to defend the breakage was by reasoning that that if it was an
> ABI we broke it both with a4780ad
> and with 6a1c531, and since we don't break ABI:s, it can't be one.
>
> But hey, I'm humble here and ready to back off.
>
>>
>> This also leaves arm64's compat with the existing behaviour, differing
>> from arm.
>>
>> I was under the impression that other mechanisms were being considered
>> for fast userspace access to per-cpu data structures, e.g. restartable
>> sequences. What is the state of those? Why is this better?
>>
>> If getcpu() specifically is necessary, is there no other way to
>> implement it?
>
> If you are referring to the user space stuff can probably be
> implemented other ways,
> it's just convenient since the interface is there and it will speed up
> stuff like lttng without
> modifications (well, except glibc). It's also already implemented as a
> vDSO on other
> major architectures (like x86, x86_64, ppc32 and ppc64).
>
> If you are referring to the implementation of the vdso call, there are
> other possibilities, but
> I haven't found any that doesn't introduce overhead in context switching.
>
> But if TPIDRURW is definitely a no go, I can work on a patch that does
> this with a thread notifier
> and the vdso data page. Would that be a viable option ?
>
>>
>> > +notrace int __vdso_getcpu(unsigned int *cpup, unsigned int *nodep,
>> > + struct getcpu_cache *tcache)
>> > +{
>> > + unsigned long node_and_cpu;
>> > +
>> > + asm("mrc p15, 0, %0, c13, c0, 2\n" : "=r"(node_and_cpu));
>> > +
>> > + if (nodep)
>> > + *nodep = cpu_to_node(node_and_cpu >> 16);
>> > + if (cpup)
>> > + *cpup = node_and_cpu & 0xffffUL;
>>
>> Given this is directly user-accessible, this format is a de-facto ABI,
>> even if it's not documented as such. Is this definitely the format you
>> want long-term?
>
> Yes, this (the interface) is indeed the important part and therefore I
> tried not to invent anything
> on my own.
> This is the interface used by ppc32, ppc64, x86, x86_64. It's also this is
> how the getcpu(2) system call is documented.
>
> /Fredrik
>
>
>>
>>
>> Thanks,
>> Mark.
--
/Fredrik
^ permalink raw reply
* [PATCH v2] ARM: dts: rockchip: Reserve unusable memory region on rk3066
From: =?UTF-8?q?Pawe=C5=82=20Jarosz?= @ 2016-10-05 16:18 UTC (permalink / raw)
To: linux-arm-kernel
For some reason accessing memory region above 0x9F000000 freezes
system on rk3066. There is similiar bug on later rockchip soc (rk3288)
solved same way.
Signed-off-by: Pawe? Jarosz <paweljarosz3691@gmail.com>
---
Changes in v2:
- updated commit message.
arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 0d0dae3..44c8956 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -93,6 +93,19 @@
};
};
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ /*
+ * The rk3066 cannot use the memory area above 0x9F000000
+ * for some unknown reason.
+ */
+ unusable at 9F000000 {
+ reg = <0x9F000000 0x1000000>;
+ };
+ };
+
i2s0: i2s at 10118000 {
compatible = "rockchip,rk3066-i2s";
reg = <0x10118000 0x2000>;
--
2.7.4
^ permalink raw reply related
* [PATCH] mfd: axp20x-i2c: Add i2c-ids to fix module auto-loading
From: Hans de Goede @ 2016-10-05 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005155112.13774-1-hdegoede@redhat.com>
The i2c subsys does not load modules by compatible, only by
i2c-id, with e.g. a modalias of: "i2c:axp209".
Populate the axp20x_i2c_id[] table with supported ids, so that
module auto-loading will work.
Reported-by: Dennis Gilmore <dennis@ausil.us>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/mfd/axp20x-i2c.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/axp20x-i2c.c b/drivers/mfd/axp20x-i2c.c
index b1b8658..d35a5fe 100644
--- a/drivers/mfd/axp20x-i2c.c
+++ b/drivers/mfd/axp20x-i2c.c
@@ -69,10 +69,11 @@ static const struct of_device_id axp20x_i2c_of_match[] = {
};
MODULE_DEVICE_TABLE(of, axp20x_i2c_of_match);
-/*
- * This is useless for OF-enabled devices, but it is needed by I2C subsystem
- */
static const struct i2c_device_id axp20x_i2c_id[] = {
+ { "axp152", 0 },
+ { "axp202", 0 },
+ { "axp209", 0 },
+ { "axp221", 0 },
{ },
};
MODULE_DEVICE_TABLE(i2c, axp20x_i2c_id);
--
2.9.3
^ permalink raw reply related
* [PATCH 0/1] mfd: axp20x-i2c: Add i2c-ids to fix module auto-loading
From: Hans de Goede @ 2016-10-05 15:51 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Dennis Gilmore (in the Cc) reports that axp20x-i2c does not auto-load
on e.g. the CHIP. I believe this is caused by the i2c-ids table not being
populated.
I believe the patch in the next mail should fix this.
Regards,
Hans
^ permalink raw reply
* [PATCH] arm64: dts: marvell: Add definition for the Globalscale Marvell ESPRESSOBin Board
From: Gregory CLEMENT @ 2016-10-05 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005172837.5ea130a1@free-electrons.com>
Hi Thomas,
On mer., oct. 05 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Wed, 05 Oct 2016 17:14:49 +0200, Gregory CLEMENT wrote:
>
>> > + memory {
>> > + device_type = "memory";
>>
>>
>> According to the kickstarter page the boards will came with different
>> amount of memory (from 512MB to 2GB). So we could put a comment
>> here about tuning this value depending of the board.
>
> U-Boot does this tuning automatically, so there is no need for the user
> to tune anything here.
Great!
It was not the case with the first Armada XP and 370 boards, but at this
time we appended the dtb to the kernel and the U-Boot on these board was
not dt capable.
Thanks,
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [RFC] arm64: Enforce observed order for spinlock and data
From: bdegraaf at codeaurora.org @ 2016-10-05 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005151057.GJ3142@twins.programming.kicks-ass.net>
On 2016-10-05 11:10, Peter Zijlstra wrote:
> On Wed, Oct 05, 2016 at 10:55:57AM -0400, bdegraaf at codeaurora.org
> wrote:
>> On 2016-10-04 15:12, Mark Rutland wrote:
>> >Hi Brent,
>> >
>> >Could you *please* clarify if you are trying to solve:
>> >
>> >(a) a correctness issue (e.g. data corruption) seen in practice.
>> >(b) a correctness issue (e.g. data corruption) found by inspection.
>> >(c) A performance issue, seen in practice.
>> >(d) A performance issue, found by inspection.
>> >
>> >Any one of these is fine; we just need to know in order to be able to
>> >help effectively, and so far it hasn't been clear.
>
> Brent, you forgot to state which: 'a-d' is the case here.
>
>> I found the problem.
>>
>> Back in September of 2013, arm64 atomics were broken due to missing
>> barriers
>> in certain situations, but the problem at that time was undiscovered.
>>
>> Will Deacon's commit d2212b4dce596fee83e5c523400bf084f4cc816c went in
>> at
>> that
>> time and changed the correct cmpxchg64 in lockref.c to
>> cmpxchg64_relaxed.
>>
>> d2212b4 appeared to be OK at that time because the additional barrier
>> requirements of this specific code sequence were not yet discovered,
>> and
>> this change was consistent with the arm64 atomic code of that time.
>>
>> Around February of 2014, some discovery led Will to correct the
>> problem with
>> the atomic code via commit 8e86f0b409a44193f1587e87b69c5dcf8f65be67,
>> which
>> has an excellent explanation of potential ordering problems with the
>> same
>> code sequence used by lockref.c.
>>
>> With this updated understanding, the earlier commit
>> (d2212b4dce596fee83e5c523400bf084f4cc816c) should be reverted.
>>
>> Because acquire/release semantics are insufficient for the full
>> ordering,
>> the single barrier after the store exclusive is the best approach,
>> similar
>> to Will's atomic barrier fix.
>
> This again does not in fact describe the problem.
>
> What is the problem with lockref, and how (refer the earlier a-d
> multiple choice answer) was this found.
>
> Now, I have been looking, and we have some idea what you _might_ be
> alluding to, but please explain which accesses get reordered how and
> cause problems.
Sorry for the confusion, this was a "b" item (correctness fix based on
code
inspection. I had sent an answer to this yesterday, but didn't realize
that
it was in a separate, private email thread.
I'll work out the before/after problem scenarios and send them along
once
I've hashed them out (it may take a while for me to paint a clear
picture).
In the meantime, however, consider that even without the spinlock code
in
the picture, lockref needs to treat the cmpxchg as a full system-level
atomic,
because multiple agents could access the value in a variety of timings.
Since
atomics similar to this are barriered on arm64 since 8e86f0b, the access
to
lockref should be similar.
Brent
^ permalink raw reply
* [PATCH] arm64: dts: marvell: Add definition for the Globalscale Marvell ESPRESSOBin Board
From: Thomas Petazzoni @ 2016-10-05 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fuoaygie.fsf@free-electrons.com>
Hello,
On Wed, 05 Oct 2016 17:14:49 +0200, Gregory CLEMENT wrote:
> > + memory {
> > + device_type = "memory";
>
>
> According to the kickstarter page the boards will came with different
> amount of memory (from 512MB to 2GB). So we could put a comment
> here about tuning this value depending of the board.
U-Boot does this tuning automatically, so there is no need for the user
to tune anything here.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [RESEND PATCH v2 3/3] dt-bindings: reset: oxnas: Update for OX820
From: Neil Armstrong @ 2016-10-05 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005152710.2898-1-narmstrong@baylibre.com>
Add new compatible string for reset and sys-ctrl for the Oxford
Semiconductor OX820 Support.
Drop the OX810SE indices since they moved in a dedicated include file.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../devicetree/bindings/reset/oxnas,reset.txt | 44 +++++-----------------
1 file changed, 9 insertions(+), 35 deletions(-)
diff --git a/Documentation/devicetree/bindings/reset/oxnas,reset.txt b/Documentation/devicetree/bindings/reset/oxnas,reset.txt
index 6f06db9..d27ccb5 100644
--- a/Documentation/devicetree/bindings/reset/oxnas,reset.txt
+++ b/Documentation/devicetree/bindings/reset/oxnas,reset.txt
@@ -5,45 +5,19 @@ Please also refer to reset.txt in this directory for common reset
controller binding usage.
Required properties:
-- compatible: Should be "oxsemi,ox810se-reset"
+- compatible: For OX810SE, should be "oxsemi,ox810se-reset"
+ For OX820, should be "oxsemi,ox820-reset"
- #reset-cells: 1, see below
Parent node should have the following properties :
-- compatible: Should be "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"
+- compatible: For OX810SE, should be :
+ "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"
+ For OX820, should be :
+ "oxsemi,ox820-sys-ctrl", "syscon", "simple-mfd"
-For OX810SE, the indices are :
- - 0 : ARM
- - 1 : COPRO
- - 2 : Reserved
- - 3 : Reserved
- - 4 : USBHS
- - 5 : USBHSPHY
- - 6 : MAC
- - 7 : PCI
- - 8 : DMA
- - 9 : DPE
- - 10 : DDR
- - 11 : SATA
- - 12 : SATA_LINK
- - 13 : SATA_PHY
- - 14 : Reserved
- - 15 : NAND
- - 16 : GPIO
- - 17 : UART1
- - 18 : UART2
- - 19 : MISC
- - 20 : I2S
- - 21 : AHB_MON
- - 22 : UART3
- - 23 : UART4
- - 24 : SGDMA
- - 25 : Reserved
- - 26 : Reserved
- - 27 : Reserved
- - 28 : Reserved
- - 29 : Reserved
- - 30 : Reserved
- - 31 : BUS
+Reset indices are in dt-bindings include files :
+- For OX810SE: include/dt-bindings/reset/oxsemi,ox810se.h
+- For OX820: include/dt-bindings/reset/oxsemi,ox820.h
example:
--
2.7.0
^ permalink raw reply related
* [RESEND PATCH v2 2/3] dt-bindings: reset: oxnas: Add include file with reset indexes
From: Neil Armstrong @ 2016-10-05 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005152710.2898-1-narmstrong@baylibre.com>
Add DT include file for Oxford Semiconductor OX810SE and OX820 reset
controller support.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
include/dt-bindings/reset/oxsemi,ox810se.h | 53 ++++++++++++++++++++++++++++++
include/dt-bindings/reset/oxsemi,ox820.h | 53 ++++++++++++++++++++++++++++++
2 files changed, 106 insertions(+)
create mode 100644 include/dt-bindings/reset/oxsemi,ox810se.h
create mode 100644 include/dt-bindings/reset/oxsemi,ox820.h
diff --git a/include/dt-bindings/reset/oxsemi,ox810se.h b/include/dt-bindings/reset/oxsemi,ox810se.h
new file mode 100644
index 0000000..960c26e
--- /dev/null
+++ b/include/dt-bindings/reset/oxsemi,ox810se.h
@@ -0,0 +1,53 @@
+/*
+ * Copyright (C) 2016 Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef DT_RESET_OXSEMI_OX810SE_H
+#define DT_RESET_OXSEMI_OX810SE_H
+
+#define RESET_ARM 0
+#define RESET_COPRO 1
+/* Reserved 2 */
+/* Reserved 3 */
+#define RESET_USBHS 4
+#define RESET_USBHSPHY 5
+#define RESET_MAC 6
+#define RESET_PCI 7
+#define RESET_DMA 8
+#define RESET_DPE 9
+#define RESET_DDR 10
+#define RESET_SATA 11
+#define RESET_SATA_LINK 12
+#define RESET_SATA_PHY 13
+ /* Reserved 14 */
+#define RESET_NAND 15
+#define RESET_GPIO 16
+#define RESET_UART1 17
+#define RESET_UART2 18
+#define RESET_MISC 19
+#define RESET_I2S 20
+#define RESET_AHB_MON 21
+#define RESET_UART3 22
+#define RESET_UART4 23
+#define RESET_SGDMA 24
+/* Reserved 25 */
+/* Reserved 26 */
+/* Reserved 27 */
+/* Reserved 28 */
+/* Reserved 29 */
+/* Reserved 30 */
+#define RESET_BUS 31
+
+#endif /* DT_RESET_OXSEMI_OX810SE_H */
diff --git a/include/dt-bindings/reset/oxsemi,ox820.h b/include/dt-bindings/reset/oxsemi,ox820.h
new file mode 100644
index 0000000..cc6797b
--- /dev/null
+++ b/include/dt-bindings/reset/oxsemi,ox820.h
@@ -0,0 +1,53 @@
+/*
+ * Copyright (C) 2016 Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef DT_RESET_OXSEMI_OX820_H
+#define DT_RESET_OXSEMI_OX820_H
+
+#define RESET_SCU 0
+#define RESET_LEON 1
+#define RESET_ARM0 2
+#define RESET_ARM1 3
+#define RESET_USBHS 4
+#define RESET_USBPHYA 5
+#define RESET_MAC 6
+#define RESET_PCIEA 7
+#define RESET_SGDMA 8
+#define RESET_CIPHER 9
+#define RESET_DDR 10
+#define RESET_SATA 11
+#define RESET_SATA_LINK 12
+#define RESET_SATA_PHY 13
+#define RESET_PCIEPHY 14
+#define RESET_NAND 15
+#define RESET_GPIO 16
+#define RESET_UART1 17
+#define RESET_UART2 18
+#define RESET_MISC 19
+#define RESET_I2S 20
+#define RESET_SD 21
+#define RESET_MAC_2 22
+#define RESET_PCIEB 23
+#define RESET_VIDEO 24
+#define RESET_DDR_PHY 25
+#define RESET_USBPHYB 26
+#define RESET_USBDEV 27
+/* Reserved 29 */
+#define RESET_ARMDBG 29
+#define RESET_PLLA 30
+#define RESET_PLLB 31
+
+#endif /* DT_RESET_OXSEMI_OX820_H */
--
2.7.0
^ permalink raw reply related
* [RESEND PATCH v2 1/3] reset: oxnas: Add OX820 support
From: Neil Armstrong @ 2016-10-05 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005152710.2898-1-narmstrong@baylibre.com>
In order to support the Oxford Semiconductor OX820 SoC, add a new
compatible string.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/reset/reset-oxnas.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/reset/reset-oxnas.c b/drivers/reset/reset-oxnas.c
index 9449805..0d9036d 100644
--- a/drivers/reset/reset-oxnas.c
+++ b/drivers/reset/reset-oxnas.c
@@ -80,6 +80,7 @@ static const struct reset_control_ops oxnas_reset_ops = {
static const struct of_device_id oxnas_reset_dt_ids[] = {
{ .compatible = "oxsemi,ox810se-reset", },
+ { .compatible = "oxsemi,ox820-reset", },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, oxnas_reset_dt_ids);
--
2.7.0
^ permalink raw reply related
* [RESEND PATCH v2 0/3]
From: Neil Armstrong @ 2016-10-05 15:27 UTC (permalink / raw)
To: linux-arm-kernel
This is a resend of v2 with the actual changes on patch number 3.
This patchset adds support for the reset controller in the Oxford
Semiconductor OX820 SoC, big brother of the OX810SE.
Since this driver uses a regmap access, it's important to tag each
compatible SoC since the regmap offset could differ in later SoCs.
This patchet also moves the reset indices to a clean DT include file.
Changes since v1 at: http://lkml.kernel.org/r/20160909131955.27334-1-narmstrong at baylibre.com
- Reformat bindings
- Add reference to include files in bindings
Neil Armstrong (3):
reset: oxnas: Add OX820 support
dt-bindings: reset: oxnas: Add include file with reset indexes
dt-bindings: reset: oxnas: Update for OX820
.../devicetree/bindings/reset/oxnas,reset.txt | 44 ++++--------------
drivers/reset/reset-oxnas.c | 1 +
include/dt-bindings/reset/oxsemi,ox810se.h | 53 ++++++++++++++++++++++
include/dt-bindings/reset/oxsemi,ox820.h | 53 ++++++++++++++++++++++
4 files changed, 116 insertions(+), 35 deletions(-)
create mode 100644 include/dt-bindings/reset/oxsemi,ox810se.h
create mode 100644 include/dt-bindings/reset/oxsemi,ox820.h
--
2.7.0
^ permalink raw reply
* [PATCH v2 3/3] dt-bindings: reset: oxnas: Update for OX820
From: Neil Armstrong @ 2016-10-05 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005152336.467-1-narmstrong@baylibre.com>
Add new compatible string for reset and sys-ctrl for the Oxford
Semiconductor OX820 Support.
Drop the OX810SE indices since they moved in a dedicated include file.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../devicetree/bindings/reset/oxnas,reset.txt | 39 ++--------------------
1 file changed, 3 insertions(+), 36 deletions(-)
diff --git a/Documentation/devicetree/bindings/reset/oxnas,reset.txt b/Documentation/devicetree/bindings/reset/oxnas,reset.txt
index 6f06db9..df0488e 100644
--- a/Documentation/devicetree/bindings/reset/oxnas,reset.txt
+++ b/Documentation/devicetree/bindings/reset/oxnas,reset.txt
@@ -5,45 +5,12 @@ Please also refer to reset.txt in this directory for common reset
controller binding usage.
Required properties:
-- compatible: Should be "oxsemi,ox810se-reset"
+- compatible: Should be "oxsemi,ox810se-reset" or "oxsemi,ox820-reset"
- #reset-cells: 1, see below
Parent node should have the following properties :
-- compatible: Should be "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"
-
-For OX810SE, the indices are :
- - 0 : ARM
- - 1 : COPRO
- - 2 : Reserved
- - 3 : Reserved
- - 4 : USBHS
- - 5 : USBHSPHY
- - 6 : MAC
- - 7 : PCI
- - 8 : DMA
- - 9 : DPE
- - 10 : DDR
- - 11 : SATA
- - 12 : SATA_LINK
- - 13 : SATA_PHY
- - 14 : Reserved
- - 15 : NAND
- - 16 : GPIO
- - 17 : UART1
- - 18 : UART2
- - 19 : MISC
- - 20 : I2S
- - 21 : AHB_MON
- - 22 : UART3
- - 23 : UART4
- - 24 : SGDMA
- - 25 : Reserved
- - 26 : Reserved
- - 27 : Reserved
- - 28 : Reserved
- - 29 : Reserved
- - 30 : Reserved
- - 31 : BUS
+- compatible: Should be "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd" or
+ "oxsemi,ox820-sys-ctrl", "syscon", "simple-mfd"
example:
--
2.7.0
^ permalink raw reply related
* [PATCH v2 2/3] dt-bindings: reset: oxnas: Add include file with reset indexes
From: Neil Armstrong @ 2016-10-05 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005152336.467-1-narmstrong@baylibre.com>
Add DT include file for Oxford Semiconductor OX810SE and OX820 reset
controller support.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
include/dt-bindings/reset/oxsemi,ox810se.h | 53 ++++++++++++++++++++++++++++++
include/dt-bindings/reset/oxsemi,ox820.h | 53 ++++++++++++++++++++++++++++++
2 files changed, 106 insertions(+)
create mode 100644 include/dt-bindings/reset/oxsemi,ox810se.h
create mode 100644 include/dt-bindings/reset/oxsemi,ox820.h
diff --git a/include/dt-bindings/reset/oxsemi,ox810se.h b/include/dt-bindings/reset/oxsemi,ox810se.h
new file mode 100644
index 0000000..960c26e
--- /dev/null
+++ b/include/dt-bindings/reset/oxsemi,ox810se.h
@@ -0,0 +1,53 @@
+/*
+ * Copyright (C) 2016 Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef DT_RESET_OXSEMI_OX810SE_H
+#define DT_RESET_OXSEMI_OX810SE_H
+
+#define RESET_ARM 0
+#define RESET_COPRO 1
+/* Reserved 2 */
+/* Reserved 3 */
+#define RESET_USBHS 4
+#define RESET_USBHSPHY 5
+#define RESET_MAC 6
+#define RESET_PCI 7
+#define RESET_DMA 8
+#define RESET_DPE 9
+#define RESET_DDR 10
+#define RESET_SATA 11
+#define RESET_SATA_LINK 12
+#define RESET_SATA_PHY 13
+ /* Reserved 14 */
+#define RESET_NAND 15
+#define RESET_GPIO 16
+#define RESET_UART1 17
+#define RESET_UART2 18
+#define RESET_MISC 19
+#define RESET_I2S 20
+#define RESET_AHB_MON 21
+#define RESET_UART3 22
+#define RESET_UART4 23
+#define RESET_SGDMA 24
+/* Reserved 25 */
+/* Reserved 26 */
+/* Reserved 27 */
+/* Reserved 28 */
+/* Reserved 29 */
+/* Reserved 30 */
+#define RESET_BUS 31
+
+#endif /* DT_RESET_OXSEMI_OX810SE_H */
diff --git a/include/dt-bindings/reset/oxsemi,ox820.h b/include/dt-bindings/reset/oxsemi,ox820.h
new file mode 100644
index 0000000..cc6797b
--- /dev/null
+++ b/include/dt-bindings/reset/oxsemi,ox820.h
@@ -0,0 +1,53 @@
+/*
+ * Copyright (C) 2016 Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef DT_RESET_OXSEMI_OX820_H
+#define DT_RESET_OXSEMI_OX820_H
+
+#define RESET_SCU 0
+#define RESET_LEON 1
+#define RESET_ARM0 2
+#define RESET_ARM1 3
+#define RESET_USBHS 4
+#define RESET_USBPHYA 5
+#define RESET_MAC 6
+#define RESET_PCIEA 7
+#define RESET_SGDMA 8
+#define RESET_CIPHER 9
+#define RESET_DDR 10
+#define RESET_SATA 11
+#define RESET_SATA_LINK 12
+#define RESET_SATA_PHY 13
+#define RESET_PCIEPHY 14
+#define RESET_NAND 15
+#define RESET_GPIO 16
+#define RESET_UART1 17
+#define RESET_UART2 18
+#define RESET_MISC 19
+#define RESET_I2S 20
+#define RESET_SD 21
+#define RESET_MAC_2 22
+#define RESET_PCIEB 23
+#define RESET_VIDEO 24
+#define RESET_DDR_PHY 25
+#define RESET_USBPHYB 26
+#define RESET_USBDEV 27
+/* Reserved 29 */
+#define RESET_ARMDBG 29
+#define RESET_PLLA 30
+#define RESET_PLLB 31
+
+#endif /* DT_RESET_OXSEMI_OX820_H */
--
2.7.0
^ permalink raw reply related
* [PATCH v2 1/3] reset: oxnas: Add OX820 support
From: Neil Armstrong @ 2016-10-05 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005152336.467-1-narmstrong@baylibre.com>
In order to support the Oxford Semiconductor OX820 SoC, add a new
compatible string.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/reset/reset-oxnas.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/reset/reset-oxnas.c b/drivers/reset/reset-oxnas.c
index 9449805..0d9036d 100644
--- a/drivers/reset/reset-oxnas.c
+++ b/drivers/reset/reset-oxnas.c
@@ -80,6 +80,7 @@ static const struct reset_control_ops oxnas_reset_ops = {
static const struct of_device_id oxnas_reset_dt_ids[] = {
{ .compatible = "oxsemi,ox810se-reset", },
+ { .compatible = "oxsemi,ox820-reset", },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, oxnas_reset_dt_ids);
--
2.7.0
^ permalink raw reply related
* [PATCH v2 0/3] reset: Add support for OX820 SoC
From: Neil Armstrong @ 2016-10-05 15:23 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds support for the reset controller in the Oxford
Semiconductor OX820 SoC, big brother of the OX810SE.
Since this driver uses a regmap access, it's important to tag each
compatible SoC since the regmap offset could differ in later SoCs.
This patchet also moves the reset indices to a clean DT include file.
Changes since v1 at: http://lkml.kernel.org/r/20160909131955.27334-1-narmstrong at baylibre.com
- Reformat bindings
- Add reference to include files in bindings
Neil Armstrong (3):
reset: oxnas: Add OX820 support
dt-bindings: reset: oxnas: Add include file with reset indexes
dt-bindings: reset: oxnas: Update for OX820
.../devicetree/bindings/reset/oxnas,reset.txt | 39 ++--------------
drivers/reset/reset-oxnas.c | 1 +
include/dt-bindings/reset/oxsemi,ox810se.h | 53 ++++++++++++++++++++++
include/dt-bindings/reset/oxsemi,ox820.h | 53 ++++++++++++++++++++++
4 files changed, 110 insertions(+), 36 deletions(-)
create mode 100644 include/dt-bindings/reset/oxsemi,ox810se.h
create mode 100644 include/dt-bindings/reset/oxsemi,ox820.h
--
2.7.0
^ permalink raw reply
* [PATCH 0/2] ARM: davinci: initial infrastructure for LCDC
From: Karl Beldan @ 2016-10-05 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475672732-17111-1-git-send-email-bgolaszewski@baylibre.com>
On Wed, Oct 05, 2016 at 03:05:30PM +0200, Bartosz Golaszewski wrote:
> After discussing the matter with Laurent Pinchart it turned out that
> using ti,tilcdc,panel was wrong and we should go with the new
> simple-vga-dac driver proposed by Maxime Ripard and currently being
> reviewed.
>
> The da850-lcdk board on which I'm working has a THS8135 video DAC for
> which the new driver seems to be best suited and we'll be able to
> query the connected display for supported modes instead of hardcoding
> them in the dt as is needed for the panel driver.
>
I meant to point to these new changes but then it slipped my mind, it is
clearly the way to go.
Regards,
Karl
> In the meantime I'm posting two patches based on Karl Beldan's
> previous work that can already be merged.
>
> The first one adds OF_DEV_AUXDATA entry to da8xx-dt.c. I changed the
> compatible string to the new one we're introducing in the tilcdc
> driver.
>
> The second adds the lcd pins and the display node to da850.dtsi. As
> suggested by Sekhar: I moved the pins node, which was previously in
> da850-lcdk.dts, to da850.dtsi. I also squashed Karl's two patches and
> removed the panel node.
>
> Tested on a da850-lcdk with an LCD display connected over VGA with
> two patches already posted to the drm mailing list:
>
> drm: tilcdc: add a da850-specific compatible string
> drm: tilcdc: add a workaround for failed clk_set_rate()
>
> and some additional work-in-progress/hacks on top of that.
>
> Karl Beldan (2):
> ARM: davinci: da8xx-dt: add OF_DEV_AUXDATA entry for lcdc
> ARM: dts: da850: add a node for the LCD controller
>
> arch/arm/boot/dts/da850.dtsi | 29 +++++++++++++++++++++++++++++
> arch/arm/mach-davinci/da8xx-dt.c | 1 +
> 2 files changed, 30 insertions(+)
>
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH] arm64: dts: marvell: Add definition for the Globalscale Marvell ESPRESSOBin Board
From: Gregory CLEMENT @ 2016-10-05 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005142734.18995-1-romain.perier@free-electrons.com>
Hi Romain,
On mer., oct. 05 2016, Romain Perier <romain.perier@free-electrons.com> wrote:
> This adds a basic definition for this board.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> ---
> arch/arm64/boot/dts/marvell/Makefile | 1 +
> .../boot/dts/marvell/armada-3720-espressobin.dts | 78 ++++++++++++++++++++++
> 2 files changed, 79 insertions(+)
> create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
>
> diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
> index 308468d..392eeb6 100644
> --- a/arch/arm64/boot/dts/marvell/Makefile
> +++ b/arch/arm64/boot/dts/marvell/Makefile
> @@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-stb.dtb
>
> # Mvebu SoC Family
> dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb
> +dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += armada-7040-db.dtb
>
> always := $(dtb-y)
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
> new file mode 100644
> index 0000000..57035a3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
> @@ -0,0 +1,78 @@
> +/*
> + * Device Tree file for Globalscale Marvell ESPRESSOBin Board
> + * Copyright (C) 2016 Marvell
> + *
> + * Romain Perier <romain.perier@free-electrons.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "armada-372x.dtsi"
> +
> +/ {
> + model = "Globalscale Marvell ESPRESSOBin Board";
> + compatible = "globalscale,espressobin", "marvell,armada3720", "marvell,armada3710";
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory {
> + device_type = "memory";
According to the kickstarter page the boards will came with different
amount of memory (from 512MB to 2GB). So we could put a comment
here about tuning this value depending of the board.
> + reg = <0x00000000 0x00000000 0x00000000 0x20000000>;
> + };
> +};
> +
Could you add information about the connector for each of the following
interfaces?
You can have a look on the armada-3720-db.dts to see the kind of info I
expect.
Thanks,
Gregory
> +&pcie0 {
> + status = "okay";
> +};
> +
> +&sata {
> + status = "okay";
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> +
> +&usb3 {
> + status = "okay";
> +};
> --
> 2.9.3
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 02/11] DOCUMENTATION: dt-bindings: Document the STM32 USART bindings
From: Rob Herring @ 2016-10-05 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dd28f224-3e3b-0a00-f978-16861b946fd1@st.com>
On Wed, Oct 5, 2016 at 9:09 AM, Gerald Baeza <gerald.baeza@st.com> wrote:
> On 09/23/2016 05:29 PM, Rob Herring wrote:
>>
>> On Thu, Sep 15, 2016 at 06:42:34PM +0200, Alexandre TORGUE wrote:
>>>
>>> This adds documentation of device tree bindings for the
>>> STM32 USART
>>
>>
>> Please make your subject prefixes consistent and drop "DOCUMENTATION".
>>
>
> Ok, thanks
>
>>>
>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
>>>
>>> diff --git a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
>>> b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
>>> new file mode 100644
>>> index 0000000..75b1400
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
>>> @@ -0,0 +1,34 @@
>>> +* STMicroelectronics STM32 USART
>>> +
>>> +Required properties:
>>> +- compatible: Can be either "st,stm32-usart", "st,stm32-uart",
>>> +"st,stm32f7-usart" or "st,stm32f7-uart" depending on whether
>>> +the device supports synchronous mode and is compatible with
>>> +stm32(f4) or stm32f7.
>>
>>
>> Why not put f4 in the compatible string. stm32 is too generic.
>
>
> The initial binding is not in current kernel so it has been put in this
> serie as PATCH 07/11. It will be squashed with this one, as you requested.
>
> But the driver tty/serial/stm32-usart.c was already upstreamed and it
> already mentions the "st,stm32-usart" and "st,stm32-uart" for stm32f4 so I
> kept this as it for backward compatibility for those who already use the
> driver.
>
> I do not have the history to explain this inconsistency but can you confirm
> that keeping the existing compatible values from the driver is the good
> approach please?
Yes, keep it as it. Please reformat 1 valid combination per line.
>> What determines sync mode or not? If it is IP configuration fixed in the
>> design, then this is fine. If it is user choice or board dependent, then
>> use a separate property.
>
>
> This is IP configuration fixed in the design, indeed.
>
>>> +- reg: The address and length of the peripheral registers space
>>> +- interrupts: The interrupt line of the USART instance
>>> +- clocks: The input clock of the USART instance
>>> +
>>> +Optional properties:
>>> +- pinctrl: The reference on the pins configuration
>>> +- st,hw-flow-ctrl: bool flag to enable hardware flow control.
>>> +
>>> +Examples:
>>> +usart4: serial at 40004c00 {
>>> + compatible = "st,stm32-uart";
>>> + reg = <0x40004c00 0x400>;
>>> + interrupts = <52>;
>>> + clocks = <&clk_pclk1>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&pinctrl_usart4>;
>>> +};
>>> +
>>> +usart2: serial at 40004400 {
>>> + compatible = "st,stm32-usart", "st,stm32-uart";
>>
>>
>> What are valid combinations? usart is sync only, not sync and async?
>
>
> usart (sync and async) is a superset of uart (async).
> But the current driver does not use the synchronous mode, so the distinction
> is just here to be consistent with the reference manual instances naming (so
> configuration).
Okay, but this point is not clear in the compatible text. The
description should allow me to validate the example or a dts file.
Rob
^ permalink raw reply
* [RFC] arm64: Enforce observed order for spinlock and data
From: bdegraaf at codeaurora.org @ 2016-10-05 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <54b18de220f61747bf1c3cdf2a1b9447@codeaurora.org>
On 2016-10-05 10:55, bdegraaf at codeaurora.org wrote:
> On 2016-10-04 15:12, Mark Rutland wrote:
>> Hi Brent,
>>
>> Could you *please* clarify if you are trying to solve:
>>
>> (a) a correctness issue (e.g. data corruption) seen in practice.
>> (b) a correctness issue (e.g. data corruption) found by inspection.
>> (c) A performance issue, seen in practice.
>> (d) A performance issue, found by inspection.
>>
>> Any one of these is fine; we just need to know in order to be able to
>> help effectively, and so far it hasn't been clear.
>>
>> On Tue, Oct 04, 2016 at 01:53:35PM -0400, bdegraaf at codeaurora.org
>> wrote:
>>> After looking at this, the problem is not with the lockref code per
>>> se: it is a problem with arch_spin_value_unlocked(). In the
>>> out-of-order case, arch_spin_value_unlocked() can return TRUE for a
>>> spinlock that is in fact locked but the lock is not observable yet
>>> via
>>> an ordinary load.
>>
>> Given arch_spin_value_unlocked() doesn't perform any load itself, I
>> assume the ordinary load that you are referring to is the READ_ONCE()
>> early in CMPXCHG_LOOP().
>>
>> It's worth noting that even if we ignore ordering and assume a
>> sequentially-consistent machine, READ_ONCE() can give us a stale
>> value.
>> We could perform the read, then another agent can acquire the lock,
>> then
>> we can move onto the cmpxchg(), i.e.
>>
>> CPU0 CPU1
>> old = READ_ONCE(x.lock_val)
>> spin_lock(x.lock)
>> cmpxchg(x.lock_val, old, new)
>> spin_unlock(x.lock)
>>
>> If the 'old' value is stale, the cmpxchg *must* fail, and the cmpxchg
>> should return an up-to-date value which we will then retry with.
>>
>>> Other than ensuring order on the locking side (as the prior patch
>>> did), there is a way to make arch_spin_value_unlock's TRUE return
>>> value deterministic,
>>
>> In general, this cannot be made deterministic. As above, there is a
>> race
>> that cannot be avoided.
>>
>>> but it requires that it does a write-back to the lock to ensure we
>>> didn't observe the unlocked value while another agent was in process
>>> of writing back a locked value.
>>
>> The cmpxchg gives us this guarantee. If it successfully stores, then
>> the
>> value it observed was the same as READ_ONCE() saw, and the update was
>> atomic.
>>
>> There *could* have been an intervening sequence between the READ_ONCE
>> and cmpxchg (e.g. put(); get()) but that's not problematic for
>> lockref.
>> Until you've taken your reference it was possible that things changed
>> underneath you.
>>
>> Thanks,
>> Mark.
>
> Mark,
>
> I found the problem.
>
> Back in September of 2013, arm64 atomics were broken due to missing
> barriers
> in certain situations, but the problem at that time was undiscovered.
>
> Will Deacon's commit d2212b4dce596fee83e5c523400bf084f4cc816c went in
> at that
> time and changed the correct cmpxchg64 in lockref.c to
> cmpxchg64_relaxed.
>
> d2212b4 appeared to be OK at that time because the additional barrier
> requirements of this specific code sequence were not yet discovered,
> and
> this change was consistent with the arm64 atomic code of that time.
>
> Around February of 2014, some discovery led Will to correct the problem
> with
> the atomic code via commit 8e86f0b409a44193f1587e87b69c5dcf8f65be67,
> which
> has an excellent explanation of potential ordering problems with the
> same
> code sequence used by lockref.c.
>
> With this updated understanding, the earlier commit
> (d2212b4dce596fee83e5c523400bf084f4cc816c) should be reverted.
>
> Because acquire/release semantics are insufficient for the full
> ordering,
> the single barrier after the store exclusive is the best approach,
> similar
> to Will's atomic barrier fix.
>
> Best regards,
> Brent
FYI, this is a "b" type fix (correctness fix based on code inspection).
^ permalink raw reply
* [RFC] arm64: Enforce observed order for spinlock and data
From: Peter Zijlstra @ 2016-10-05 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <54b18de220f61747bf1c3cdf2a1b9447@codeaurora.org>
On Wed, Oct 05, 2016 at 10:55:57AM -0400, bdegraaf at codeaurora.org wrote:
> On 2016-10-04 15:12, Mark Rutland wrote:
> >Hi Brent,
> >
> >Could you *please* clarify if you are trying to solve:
> >
> >(a) a correctness issue (e.g. data corruption) seen in practice.
> >(b) a correctness issue (e.g. data corruption) found by inspection.
> >(c) A performance issue, seen in practice.
> >(d) A performance issue, found by inspection.
> >
> >Any one of these is fine; we just need to know in order to be able to
> >help effectively, and so far it hasn't been clear.
Brent, you forgot to state which: 'a-d' is the case here.
> I found the problem.
>
> Back in September of 2013, arm64 atomics were broken due to missing barriers
> in certain situations, but the problem at that time was undiscovered.
>
> Will Deacon's commit d2212b4dce596fee83e5c523400bf084f4cc816c went in at
> that
> time and changed the correct cmpxchg64 in lockref.c to cmpxchg64_relaxed.
>
> d2212b4 appeared to be OK at that time because the additional barrier
> requirements of this specific code sequence were not yet discovered, and
> this change was consistent with the arm64 atomic code of that time.
>
> Around February of 2014, some discovery led Will to correct the problem with
> the atomic code via commit 8e86f0b409a44193f1587e87b69c5dcf8f65be67, which
> has an excellent explanation of potential ordering problems with the same
> code sequence used by lockref.c.
>
> With this updated understanding, the earlier commit
> (d2212b4dce596fee83e5c523400bf084f4cc816c) should be reverted.
>
> Because acquire/release semantics are insufficient for the full ordering,
> the single barrier after the store exclusive is the best approach, similar
> to Will's atomic barrier fix.
This again does not in fact describe the problem.
What is the problem with lockref, and how (refer the earlier a-d
multiple choice answer) was this found.
Now, I have been looking, and we have some idea what you _might_ be
alluding to, but please explain which accesses get reordered how and
cause problems.
^ permalink raw reply
* [PATCH 6/6] dt-bindings: clk: oxnas,stdclk: Add OX820 bindings
From: Neil Armstrong @ 2016-10-05 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005150752.22618-1-narmstrong@baylibre.com>
Add OX820 bindings and remove clock indices from bindings since they are present
in the dt-bindings headers files.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../devicetree/bindings/clock/oxnas,stdclk.txt | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/oxnas,stdclk.txt b/Documentation/devicetree/bindings/clock/oxnas,stdclk.txt
index 208cca6..b652f3f 100644
--- a/Documentation/devicetree/bindings/clock/oxnas,stdclk.txt
+++ b/Documentation/devicetree/bindings/clock/oxnas,stdclk.txt
@@ -5,22 +5,15 @@ Please also refer to clock-bindings.txt in this directory for common clock
bindings usage.
Required properties:
-- compatible: Should be "oxsemi,ox810se-stdclk"
+- compatible: For OX810SE, should be "oxsemi,ox810se-stdclk"
+ For OX820, should be "oxsemi,ox820-stdclk"
- #clock-cells: 1, see below
Parent node should have the following properties :
-- compatible: Should be "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"
-
-For OX810SE, the clock indices are :
- - 0: LEON
- - 1: DMA_SGDMA
- - 2: CIPHER
- - 3: SATA
- - 4: AUDIO
- - 5: USBMPH
- - 6: ETHA
- - 7: PCIA
- - 8: NAND
+- compatible: For OX810SE, should be
+ "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"
+ For OX820, should be
+ "oxsemi,ox820-sys-ctrl", "syscon", "simple-mfd"
example:
--
2.7.0
^ permalink raw reply related
* [PATCH 5/6] clk: oxnas: Add OX820 Gate clocks
From: Neil Armstrong @ 2016-10-05 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005150752.22618-1-narmstrong@baylibre.com>
Add support for the Oxford Semiconductor OX820 SoC gate clocks
along the OX810SE SoC support.
This rework on concerns the gate clocks since they are different.
Future PLL handling code will be added for OX820.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/clk/clk-oxnas.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/drivers/clk/clk-oxnas.c b/drivers/clk/clk-oxnas.c
index b1ef3ea9..e51e002 100644
--- a/drivers/clk/clk-oxnas.c
+++ b/drivers/clk/clk-oxnas.c
@@ -27,6 +27,7 @@
#include <linux/mfd/syscon.h>
#include <dt-bindings/clock/oxsemi,ox810se.h>
+#include <dt-bindings/clock/oxsemi,ox820.h>
/* Standard regmap gate clocks */
struct clk_oxnas_gate {
@@ -130,6 +131,38 @@ static struct clk_oxnas_gate *ox810se_gates[] = {
&ox810se_nand,
};
+static OXNAS_GATE(ox820_leon, 0, osc_parents);
+static OXNAS_GATE(ox820_dma_sgdma, 1, osc_parents);
+static OXNAS_GATE(ox820_cipher, 2, osc_parents);
+static OXNAS_GATE(ox820_sd, 3, osc_parents);
+static OXNAS_GATE(ox820_sata, 4, osc_parents);
+static OXNAS_GATE(ox820_audio, 5, osc_parents);
+static OXNAS_GATE(ox820_usbmph, 6, osc_parents);
+static OXNAS_GATE(ox820_etha, 7, eth_parents);
+static OXNAS_GATE(ox820_pciea, 8, osc_parents);
+static OXNAS_GATE(ox820_nand, 9, osc_parents);
+static OXNAS_GATE(ox820_ethb, 10, eth_parents);
+static OXNAS_GATE(ox820_pcieb, 11, osc_parents);
+static OXNAS_GATE(ox820_ref600, 12, osc_parents);
+static OXNAS_GATE(ox820_usbdev, 13, osc_parents);
+
+static struct clk_oxnas_gate *ox820_gates[] = {
+ &ox820_leon,
+ &ox820_dma_sgdma,
+ &ox820_cipher,
+ &ox820_sd,
+ &ox820_sata,
+ &ox820_audio,
+ &ox820_usbmph,
+ &ox820_etha,
+ &ox820_pciea,
+ &ox820_nand,
+ &ox820_etha,
+ &ox820_pciea,
+ &ox820_ref600,
+ &ox820_usbdev,
+};
+
static struct clk_hw_onecell_data ox810se_hw_onecell_data = {
.hws = {
[CLK_810_LEON] = &ox810se_leon.hw,
@@ -145,6 +178,25 @@ static struct clk_hw_onecell_data ox810se_hw_onecell_data = {
.num = ARRAY_SIZE(ox810se_gates),
};
+static struct clk_hw_onecell_data ox820_hw_onecell_data = {
+ .hws = {
+ [CLK_820_LEON] = &ox820_leon.hw,
+ [CLK_820_DMA_SGDMA] = &ox820_dma_sgdma.hw,
+ [CLK_820_CIPHER] = &ox820_cipher.hw,
+ [CLK_820_SD] = &ox820_sd.hw,
+ [CLK_820_SATA] = &ox820_sata.hw,
+ [CLK_820_AUDIO] = &ox820_audio.hw,
+ [CLK_820_USBMPH] = &ox820_usbmph.hw,
+ [CLK_820_ETHA] = &ox820_etha.hw,
+ [CLK_820_PCIEA] = &ox820_pciea.hw,
+ [CLK_820_NAND] = &ox820_nand.hw,
+ [CLK_820_ETHB] = &ox820_ethb.hw,
+ [CLK_820_PCIEB] = &ox820_pcieb.hw,
+ [CLK_820_REF600] = &ox820_ref600.hw,
+ [CLK_820_USBDEV] = &ox820_usbdev.hw,
+ },
+ .num = ARRAY_SIZE(ox820_gates),
+};
static struct oxnas_stdclk_data ox810se_stdclk_data = {
.onecell_data = &ox810se_hw_onecell_data,
@@ -152,9 +204,15 @@ static struct oxnas_stdclk_data ox810se_stdclk_data = {
.ngates = ARRAY_SIZE(ox810se_gates),
};
+static struct oxnas_stdclk_data ox820_stdclk_data = {
+ .onecell_data = &ox820_hw_onecell_data,
+ .gates = ox820_gates,
+ .ngates = ARRAY_SIZE(ox820_gates),
+};
static const struct of_device_id oxnas_stdclk_dt_ids[] = {
{ .compatible = "oxsemi,ox810se-stdclk", &ox810se_stdclk_data },
+ { .compatible = "oxsemi,ox820-stdclk", &ox820_stdclk_data },
{ }
};
--
2.7.0
^ permalink raw reply related
* [PATCH 4/6] clk: oxnas: Refactor to make use of devm_clk_hw_register()
From: Neil Armstrong @ 2016-10-05 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005150752.22618-1-narmstrong@baylibre.com>
Make usage of static tables identified by the OF match table to
feed devm_clk_hw_register() and use of_clk_add_hw_provider().
This structure is cleaner and simplifies adding new SoC support while
having common probe and gate ops code.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/clk/clk-oxnas.c | 148 +++++++++++++++++++++++++++---------------------
1 file changed, 84 insertions(+), 64 deletions(-)
diff --git a/drivers/clk/clk-oxnas.c b/drivers/clk/clk-oxnas.c
index a76c7fb..b1ef3ea9 100644
--- a/drivers/clk/clk-oxnas.c
+++ b/drivers/clk/clk-oxnas.c
@@ -20,18 +20,29 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/stringify.h>
#include <linux/regmap.h>
#include <linux/mfd/syscon.h>
+#include <dt-bindings/clock/oxsemi,ox810se.h>
+
/* Standard regmap gate clocks */
struct clk_oxnas_gate {
struct clk_hw hw;
- signed char bit;
+ unsigned int bit;
struct regmap *regmap;
};
+struct oxnas_stdclk_data {
+ struct clk_hw_onecell_data *onecell_data;
+ struct clk_oxnas_gate **gates;
+ unsigned int ngates;
+ struct clk_oxnas_pll **plls;
+ unsigned int nplls;
+};
+
/* Regmap offsets */
#define CLK_STAT_REGOFFSET 0x24
#define CLK_SET_REGOFFSET 0x2c
@@ -77,7 +88,7 @@ static const struct clk_ops oxnas_clk_gate_ops = {
.is_enabled = oxnas_clk_gate_is_enabled,
};
-static const char *const oxnas_clk_parents[] = {
+static const char *const osc_parents[] = {
"oscillator",
};
@@ -85,63 +96,81 @@ static const char *const eth_parents[] = {
"gmacclk",
};
-#define DECLARE_STD_CLKP(__clk, __parent) \
-static const struct clk_init_data clk_##__clk##_init = { \
- .name = __stringify(__clk), \
- .ops = &oxnas_clk_gate_ops, \
- .parent_names = __parent, \
- .num_parents = ARRAY_SIZE(__parent), \
+#define OXNAS_GATE(_name, _bit, _parents) \
+struct clk_oxnas_gate _name = { \
+ .bit = (_bit), \
+ .hw.init = &(struct clk_init_data) { \
+ .name = #_name, \
+ .ops = &oxnas_clk_gate_ops, \
+ .parent_names = _parents, \
+ .num_parents = ARRAY_SIZE(_parents), \
+ .flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED), \
+ }, \
}
-#define DECLARE_STD_CLK(__clk) DECLARE_STD_CLKP(__clk, oxnas_clk_parents)
+static OXNAS_GATE(ox810se_leon, 0, osc_parents);
+static OXNAS_GATE(ox810se_dma_sgdma, 1, osc_parents);
+static OXNAS_GATE(ox810se_cipher, 2, osc_parents);
+static OXNAS_GATE(ox810se_sata, 4, osc_parents);
+static OXNAS_GATE(ox810se_audio, 5, osc_parents);
+static OXNAS_GATE(ox810se_usbmph, 6, osc_parents);
+static OXNAS_GATE(ox810se_etha, 7, eth_parents);
+static OXNAS_GATE(ox810se_pciea, 8, osc_parents);
+static OXNAS_GATE(ox810se_nand, 9, osc_parents);
+
+static struct clk_oxnas_gate *ox810se_gates[] = {
+ &ox810se_leon,
+ &ox810se_dma_sgdma,
+ &ox810se_cipher,
+ &ox810se_sata,
+ &ox810se_audio,
+ &ox810se_usbmph,
+ &ox810se_etha,
+ &ox810se_pciea,
+ &ox810se_nand,
+};
-/* Hardware Bit - Clock association */
-struct clk_oxnas_init_data {
- unsigned long bit;
- const struct clk_init_data *clk_init;
+static struct clk_hw_onecell_data ox810se_hw_onecell_data = {
+ .hws = {
+ [CLK_810_LEON] = &ox810se_leon.hw,
+ [CLK_810_DMA_SGDMA] = &ox810se_dma_sgdma.hw,
+ [CLK_810_CIPHER] = &ox810se_cipher.hw,
+ [CLK_810_SATA] = &ox810se_sata.hw,
+ [CLK_810_AUDIO] = &ox810se_audio.hw,
+ [CLK_810_USBMPH] = &ox810se_usbmph.hw,
+ [CLK_810_ETHA] = &ox810se_etha.hw,
+ [CLK_810_PCIEA] = &ox810se_pciea.hw,
+ [CLK_810_NAND] = &ox810se_nand.hw,
+ },
+ .num = ARRAY_SIZE(ox810se_gates),
};
-/* Clk init data declaration */
-DECLARE_STD_CLK(leon);
-DECLARE_STD_CLK(dma_sgdma);
-DECLARE_STD_CLK(cipher);
-DECLARE_STD_CLK(sata);
-DECLARE_STD_CLK(audio);
-DECLARE_STD_CLK(usbmph);
-DECLARE_STD_CLKP(etha, eth_parents);
-DECLARE_STD_CLK(pciea);
-DECLARE_STD_CLK(nand);
-
-/* Table index is clock indice */
-static const struct clk_oxnas_init_data clk_oxnas_init[] = {
- [0] = {0, &clk_leon_init},
- [1] = {1, &clk_dma_sgdma_init},
- [2] = {2, &clk_cipher_init},
- /* Skip & Do not touch to DDR clock */
- [3] = {4, &clk_sata_init},
- [4] = {5, &clk_audio_init},
- [5] = {6, &clk_usbmph_init},
- [6] = {7, &clk_etha_init},
- [7] = {8, &clk_pciea_init},
- [8] = {9, &clk_nand_init},
+
+static struct oxnas_stdclk_data ox810se_stdclk_data = {
+ .onecell_data = &ox810se_hw_onecell_data,
+ .gates = ox810se_gates,
+ .ngates = ARRAY_SIZE(ox810se_gates),
};
-struct clk_oxnas_data {
- struct clk_oxnas_gate clk_oxnas[ARRAY_SIZE(clk_oxnas_init)];
- struct clk_onecell_data onecell_data[ARRAY_SIZE(clk_oxnas_init)];
- struct clk *clks[ARRAY_SIZE(clk_oxnas_init)];
+
+static const struct of_device_id oxnas_stdclk_dt_ids[] = {
+ { .compatible = "oxsemi,ox810se-stdclk", &ox810se_stdclk_data },
+ { }
};
static int oxnas_stdclk_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
- struct clk_oxnas_data *clk_oxnas;
+ const struct oxnas_stdclk_data *data;
+ const struct of_device_id *id;
struct regmap *regmap;
+ int ret;
int i;
- clk_oxnas = devm_kzalloc(&pdev->dev, sizeof(*clk_oxnas), GFP_KERNEL);
- if (!clk_oxnas)
- return -ENOMEM;
+ id = of_match_device(oxnas_stdclk_dt_ids, &pdev->dev);
+ if (!id)
+ return -ENODEV;
+ data = id->data;
regmap = syscon_node_to_regmap(of_get_parent(np));
if (IS_ERR(regmap)) {
@@ -149,32 +178,23 @@ static int oxnas_stdclk_probe(struct platform_device *pdev)
return PTR_ERR(regmap);
}
- for (i = 0; i < ARRAY_SIZE(clk_oxnas_init); i++) {
- struct clk_oxnas_gate *_clk;
+ for (i = 0 ; i < data->ngates ; ++i)
+ data->gates[i]->regmap = regmap;
- _clk = &clk_oxnas->clk_oxnas[i];
- _clk->bit = clk_oxnas_init[i].bit;
- _clk->hw.init = clk_oxnas_init[i].clk_init;
- _clk->regmap = regmap;
+ for (i = 0; i < data->onecell_data->num; i++) {
+ if (!data->onecell_data->hws[i])
+ continue;
- clk_oxnas->clks[i] =
- devm_clk_register(&pdev->dev, &_clk->hw);
- if (WARN_ON(IS_ERR(clk_oxnas->clks[i])))
- return PTR_ERR(clk_oxnas->clks[i]);
+ ret = devm_clk_hw_register(&pdev->dev,
+ data->onecell_data->hws[i]);
+ if (ret)
+ return ret;
}
- clk_oxnas->onecell_data->clks = clk_oxnas->clks;
- clk_oxnas->onecell_data->clk_num = ARRAY_SIZE(clk_oxnas_init);
-
- return of_clk_add_provider(np, of_clk_src_onecell_get,
- clk_oxnas->onecell_data);
+ return of_clk_add_hw_provider(np, of_clk_hw_onecell_get,
+ data->onecell_data);
}
-static const struct of_device_id oxnas_stdclk_dt_ids[] = {
- { .compatible = "oxsemi,ox810se-stdclk" },
- { }
-};
-
static struct platform_driver oxnas_stdclk_driver = {
.probe = oxnas_stdclk_probe,
.driver = {
--
2.7.0
^ 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