* [PATCH 01/18] 32-bit ABI: introduce ARCH_32BIT_OFF_T config option
From: Chris Metcalf @ 2016-10-24 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477081997-4770-2-git-send-email-ynorov@caviumnetworks.com>
On 10/21/2016 4:33 PM, Yury Norov wrote:
> All new 32-bit architectures should have 64-bit off_t type, but existing
> architectures has 32-bit ones.
>
> [...]
> For syscalls sys_openat() and sys_open_by_handle_at() force_o_largefile()
> is called, to set O_LARGEFILE flag, and this is the only difference
> comparing to compat versions. All compat ABIs are already turned to use
> 64-bit off_t, except tile. So, compat versions for this syscalls are not
> needed anymore. Tile is handled explicitly.
>
> [...]
> --- a/arch/tile/kernel/compat.c
> +++ b/arch/tile/kernel/compat.c
> @@ -103,6 +103,9 @@ COMPAT_SYSCALL_DEFINE5(llseek, unsigned int, fd, unsigned int, offset_high,
> #define compat_sys_readahead sys32_readahead
> #define sys_llseek compat_sys_llseek
>
> +#define sys_openat compat_sys_openat
> +#define sys_open_by_handle_at compat_sys_open_by_handle_at
> +
> /* Call the assembly trampolines where necessary. */
> #define compat_sys_rt_sigreturn _compat_sys_rt_sigreturn
> #define sys_clone _sys_clone
This patch accomplishes two goals that could be completely separated.
It's confusing to have them mixed in the same patch without any
discussion of why they are in the same patch.
First, you want to modify the default <asm/unistd.h> behavior for
compat syscalls so that the default is sys_openat (etc) rather than
the existing compat_sys_openat, and then use that new behavior for
arm64 ILP32. This lets you force O_LARGEFILE for arm64 ILP32 to
support having a 64-bit off_t at all times. To do that, you fix the
asm-generic header, and then make tile have a special override.
This seems reasonable enough.
Second, you introduce ARCH_32BIT_OFF_T basically as a synonym for
"BITS_PER_WORD == 32", so that new 32-bit architectures can choose not
to enable it. This is fine in the abstract, but I'm a bit troubled by
the fact that you are not actually introducing a new 32-bit
architecture here (just a new 32-bit mode for the arm 64-bit kernel).
Shouldn't this part of the change wait until someone actually has a
new 32-bit kernel to drive this forward?
If you want to push forward the ARCH_32BIT_OFF_T change in the absence
of an architecture that supports it, I would think it would be a lot
less confusing to have these two in separate patches, and make it
clear that the ARCH_32BIT_OFF_T change is just laying groundwork
for some hypothetical future architecture.
The existing commit language itself is also confusing. You write "All
compat ABIs are already turned to use 64-bit off_t, except tile."
First, I'm not sure what you mean by "turned" here. And, tile is just
one of many compat ABIs that allow O_LARGEFILE not to be part of the
open call: see arm64's AArch32 ABI, MIPS o32, s390 31-bit emulation,
sparc64's 32-bit mode, and of course x86's 32-bit compat mode.
Presumably your point here is that tile is the only pre-existing
architecture that #includes <asm/unistd.h> to create its compat
syscall table, and so I think "all except tile" here is particularly
confusing, since there are no architectures except tile that use the
__SYSCALL_COMPAT functionality in the current tree.
--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com
^ permalink raw reply
* [PATCH] arm64: Neaten show_regs, remove KERN_CONT
From: Joe Perches @ 2016-10-24 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024113131.GH15620@leverpostej>
On Mon, 2016-10-24 at 12:31 +0100, Mark Rutland wrote:
> On Sun, Oct 23, 2016 at 01:40:49PM -0700, Joe Perches wrote:
> > commit db4b0710fae9 ("arm64: fix show_regs fallout from KERN_CONT changes")
> > corrected the KERN_CONT fallout from commit 4bcc595ccd80
> > ("printk: reinstate KERN_CONT for printing continuation lines"), but
> > the code still has unnecessary KERN_CONT uses. Remove them.
>
> Why are these unnecessary KERN_CONTs a larger problem than duplicating
> the format string for a third time? Having to duplicate it at all was
> annoying enough.
Not printing partial lines is the best solution to avoiding
message output interleaving.
> Overall, to avoid messing with the KERN_CONT mess it'd be nicer to
> format this all into a buffer (with the format string only existing the
> once) and subsequently print it with one printk call
A single printk call would get one timestamp which would
make for ragged/staggered reading.
^ permalink raw reply
* [PATCH v5 2/4] arm64: dts: add Allwinner A64 SoC .dtsi
From: Maxime Ripard @ 2016-10-24 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a0b71433-8302-8ac2-a695-60ac813b380f@arm.com>
Hi Andr?,
On Mon, Oct 24, 2016 at 12:57:04AM +0100, Andr? Przywara wrote:
> > + pio: pinctrl at 1c20800 {
> > + compatible = "allwinner,sun50i-a64-pinctrl";
> > + reg = <0x01c20800 0x400>;
> > + interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_PIO>;
> > + gpio-controller;
> > + #gpio-cells = <3>;
> > + interrupt-controller;
> > + #interrupt-cells = <3>;
> > +
> > + i2c1_pins: i2c1_pins {
> > + allwinner,pins = "PH2", "PH3";
> > + allwinner,function = "i2c1";
>
> So as Icenowy pointed out, we are missing the drive and pull properties
> here, at least as long as we don't have your patch (series) in place to
> cope with that.
Yeah sorry, we noticed first with Chen-Yu that the binding should not
need it, and then we realised that the driver was making the
assumption that they were... Sorry :/
> But if we rely on this series (which seems OK to me), shouldn't we then
> use the generic properties for pins and function here as well?
Definitely. I'll update this.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/2b6d6f3f/attachment.sig>
^ permalink raw reply
* [PATCH V7 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: Stefan Wahren @ 2016-10-24 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87twczg27x.fsf@eliezer.anholt.net>
Hi Martin,
Am 28.09.2016 um 23:10 schrieb Eric Anholt:
> kernel at martin.sperl.org writes:
>
>> From: Martin Sperl <kernel@martin.sperl.org>
>>
>> Add basic thermal driver for bcm2835 SOC.
>>
>> This driver currently relies on the firmware setting up the
>> tsense HW block and does not set it up itself.
>>
>> Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
>> Acked-by: Eric Anholt <eric@anholt.net>
>> Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
> What's the status of merging this one? I'd like to merge the other
> patches.
i think it's necessary to rebase the whole series. Maybe we could get it
into 4.10.
Stefan
^ permalink raw reply
* [PATCH 37/37] perf coresight: Removing miscellaneous debug output
From: Arnaldo Carvalho de Melo @ 2016-10-24 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477326057-24080-1-git-send-email-acme@kernel.org>
From: Mathieu Poirier <mathieu.poirier@linaro.org>
Printing the full path of the selected link is obviously not needed,
hence removing.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linux-arm-kernel at lists.infradead.org
Link: http://lkml.kernel.org/r/1476913323-6836-1-git-send-email-mathieu.poirier at linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/arch/arm/util/cs-etm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/tools/perf/arch/arm/util/cs-etm.c b/tools/perf/arch/arm/util/cs-etm.c
index 47d584da5819..dfea6b635525 100644
--- a/tools/perf/arch/arm/util/cs-etm.c
+++ b/tools/perf/arch/arm/util/cs-etm.c
@@ -575,8 +575,6 @@ static FILE *cs_device__open_file(const char *name)
snprintf(path, PATH_MAX,
"%s" CS_BUS_DEVICE_PATH "%s", sysfs, name);
- printf("path: %s\n", path);
-
if (stat(path, &st) < 0)
return NULL;
--
2.7.4
^ permalink raw reply related
* [PATCH] arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU
From: Mark Rutland @ 2016-10-24 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477323088-18768-1-git-send-email-marc.zyngier@arm.com>
Hi Marc,
On Mon, Oct 24, 2016 at 04:31:28PM +0100, Marc Zyngier wrote:
> Architecturally, TLBs are private to the (physical) CPU they're
> associated with. But when multiple vcpus from the same VM are
> being multiplexed on the same CPU, the TLBs are not private
> to the vcpus (and are actually shared across the VMID).
>
> Let's consider the following scenario:
>
> - vcpu-0 maps PA to VA
> - vcpu-1 maps PA' to VA
>
> If run on the same physical CPU, vcpu-1 can hit TLB entries generated
> by vcpu-0 accesses, and access the wrong physical page.
It might be worth noting that this could also lead to TLB conflicts and
other such fun usually associated with missing TLB maintenance,
depending on the two mappings (or the intermediate stages thereof).
> The solution to this is to keep a per-VM map of which vcpu ran last
> on each given physical CPU, and invalidate local TLBs when switching
> to a different vcpu from the same VM.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Modulo my comment on preemptiblity of kvm_arch_sched_in, everything
below is a nit. Assuming that's not preemptible, this looks right to me.
FWIW, with or without the other comments considered:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> ---
> arch/arm/include/asm/kvm_host.h | 5 +++++
> arch/arm/include/asm/kvm_hyp.h | 1 +
> arch/arm/kvm/arm.c | 35 ++++++++++++++++++++++++++++++++++-
> arch/arm/kvm/hyp/switch.c | 9 +++++++++
> arch/arm64/include/asm/kvm_host.h | 6 +++++-
> arch/arm64/kvm/hyp/switch.c | 8 ++++++++
> 6 files changed, 62 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 2d19e02..035e744 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -57,6 +57,8 @@ struct kvm_arch {
> /* VTTBR value associated with below pgd and vmid */
> u64 vttbr;
>
> + int __percpu *last_vcpu_ran;
> +
> /* Timer */
> struct arch_timer_kvm timer;
>
> @@ -174,6 +176,9 @@ struct kvm_vcpu_arch {
> /* vcpu power-off state */
> bool power_off;
>
> + /* TLBI required */
> + bool requires_tlbi;
A bit of a nit, but it's not clear which class of TLBI is required, or
why. It's probably worth a comment (and perhaps a bikeshed), like:
/*
* Local TLBs potentially contain conflicting entries from
* another vCPU within this VMID. All entries for this VMID must
* be invalidated from (local) TLBs before we run this vCPU.
*/
bool tlb_vmid_stale;
[...]
> +void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu)
> +{
> + int *last_ran;
> +
> + last_ran = per_cpu_ptr(vcpu->kvm->arch.last_vcpu_ran, cpu);
> +
> + /*
> + * If we're very unlucky and get preempted before having ran
> + * this vcpu for real, we'll end-up in a situation where any
> + * vcpu that gets scheduled will perform an invalidation (this
> + * vcpu explicitely requires it, and all the others will have
> + * a different vcpu_id).
> + */
Nit: s/explicitely/explicitly/
To bikeshed a little further, perhaps:
/*
* We might get preempted before the vCPU actually runs, but
* this is fine. Our TLBI stays pending until we actually make
* it to __activate_vm, so we won't miss a TLBI. If another vCPU
* gets scheduled, it will see our vcpu_id in last_ran, and pend
* a TLBI for itself.
*/
> + if (*last_ran != vcpu->vcpu_id) {
> + if (*last_ran != -1)
> + vcpu->arch.requires_tlbi = true;
> +
> + *last_ran = vcpu->vcpu_id;
> + }
> +}
I take it this function is run in some non-preemptible context; if so,
this looks correct to me.
If this is preemptible, then this looks racy.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 [fix]] PM / doc: Update device documentation for devices in IRQ safe PM domains
From: Lina Iyer @ 2016-10-24 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1900178.E2KGyKAlTm@vostro.rjw.lan>
On Sat, Oct 22 2016 at 18:19 -0600, Rafael J. Wysocki wrote:
>On Friday, October 21, 2016 03:52:55 PM Lina Iyer wrote:
>> Update documentation to reflect the changes made to support IRQ safe PM
>> domains.
>>
>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
>> ---
>> Changes since v3:
>> - Moved para to the end of the section
>> - Added clause for all IRQ safe devices in a domain
>> - Cleanup explanation of nested domains
>> ---
>> Documentation/power/devices.txt | 11 ++++++++++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
>> index 8ba6625..9218ce6 100644
>> --- a/Documentation/power/devices.txt
>> +++ b/Documentation/power/devices.txt
>> @@ -607,7 +607,9 @@ individually. Instead, a set of devices sharing a power resource can be put
>> into a low-power state together at the same time by turning off the shared
>> power resource. Of course, they also need to be put into the full-power state
>> together, by turning the shared power resource on. A set of devices with this
>> -property is often referred to as a power domain.
>> +property is often referred to as a power domain. A power domain may also be
>> +nested inside another power domain. The nested domain is referred to as the
>> +sub-domain of the parent domain.
>>
>> Support for power domains is provided through the pm_domain field of struct
>> device. This field is a pointer to an object of type struct dev_pm_domain,
>> @@ -629,6 +631,13 @@ support for power domains into subsystem-level callbacks, for example by
>> modifying the platform bus type. Other platforms need not implement it or take
>> it into account in any way.
>>
>> +Devices and PM domains may be defined as IRQ-safe, if they can be powered
>> +on/off even when the IRQs are disabled.
>
>What IRQ-safe means for devices is that their runtime PM callbacks may be
>invoked with interrupts disabled on the local CPU. I guess the meaning of
>IRQ-safe for PM domains is analogous, but the above isn't precise enough to me.
>
>> An IRQ-safe device in a domain will
>> +disallow power management on the domain, unless the domain is also defined as
>> +IRQ-safe. In other words, a domain containing all IRQ-safe devices must also
>> +be defined as IRQ-safe. Another restriction this framework imposes on the
>> +parent domain of an IRQ-safe domain is that the parent domain must also be
>> +defined as IRQ-safe.
>
>What about this:
>
>"Devices may be defined as IRQ-safe which indicates to the PM core that their
>runtime PM callbacks may be invoked with disabled interrupts (see
>Documentation/power/runtime_pm.txt for more information). If an IRQ-safe
>device belongs to a PM domain, the runtime PM of the domain will be disallowed,
>unless the domain itself is defined as IRQ-safe. However, a PM domain can only
>be defined as IRQ-safe if all of the devices in it are IRQ-safe.
>
This is correct. But the last line may need a bit of modification. If
all devices in a PM domain are IRQ-safe and the domain is NOT, then it
it is a valid combination just that the domain would never do runtime
PM.
> Moreover, if
>an IRQ-safe domain has a parent domain, the runtime PM of the parent is only
>allowed if the parent itself is IRQ-safe too with the additional restriction
>that all child domains of an IRQ-safe parent must also be IRQ-safe."
>
>Does it actually reflect what the code does?
>
Yes, this precisely reflects the code.
Thanks,
Lina
^ permalink raw reply
* Disabling an interrupt in the handler locks the system up
From: Mason @ 2016-10-24 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <580BF1D4.2030509@free.fr>
On 23/10/2016 01:10, Mason wrote:
> Maybe the fact that disable_irq locks the system up is an orthogonal
> issue that needs to be fixed anyway.
disable_irq_nosync() eventually calls irq_disable()
void irq_disable(struct irq_desc *desc)
{
irq_state_set_disabled(desc);
if (desc->irq_data.chip->irq_disable) {
desc->irq_data.chip->irq_disable(&desc->irq_data);
irq_state_set_masked(desc);
} else if (irq_settings_disable_unlazy(desc)) {
mask_irq(desc);
}
}
irq_disable() is a NOP on my platform, because the intc driver does
not implement irq_disable, and the second test is false as well in
this instance.
The function's description is interesting.
/**
* irq_disable - Mark interrupt disabled
* @desc: irq descriptor which should be disabled
*
* If the chip does not implement the irq_disable callback, we
* use a lazy disable approach. That means we mark the interrupt
* disabled, but leave the hardware unmasked. That's an
* optimization because we avoid the hardware access for the
* common case where no interrupt happens after we marked it
* disabled. If an interrupt happens, then the interrupt flow
* handler masks the line at the hardware level and marks it
* pending.
*
* If the interrupt chip does not implement the irq_disable callback,
* a driver can disable the lazy approach for a particular irq line by
* calling 'irq_set_status_flags(irq, IRQ_DISABLE_UNLAZY)'. This can
* be used for devices which cannot disable the interrupt at the
* device level under certain circumstances and have to use
* disable_irq[_nosync] instead.
*/
(I assume "chip" and "interrupt chip" refer to the same abstraction.)
I took a look at commit e9849777d0e27, but my brain dumped core on
the notions of "disabling unlazy" and "disabling a disable".
* IRQ_DISABLE_UNLAZY - Disable lazy irq disable
For the record, setting the IRQ_DISABLE_UNLAZY flag for this device
makes the system lock-up disappear.
Regards.
^ permalink raw reply
* [PATCH v4 4/9] clk: sunxi-ng: Add minimums for all the relevant structures and clocks
From: Maxime Ripard @ 2016-10-24 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <72be1b2a-e2db-7220-aa49-96d22860100c@arm.com>
On Fri, Oct 21, 2016 at 11:57:11PM +0100, Andr? Przywara wrote:
> Salut,
>
> On 11/10/16 15:28, Maxime Ripard wrote:
> > Modify the current clocks we have to be able to specify the minimum for
> > each clocks we support, just like we support the max.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > drivers/clk/sunxi-ng/ccu_mult.c | 7 ++++++-
> > drivers/clk/sunxi-ng/ccu_nk.c | 12 ++++++++----
> > drivers/clk/sunxi-ng/ccu_nkm.c | 18 ++++++++++++------
> > drivers/clk/sunxi-ng/ccu_nkmp.c | 16 ++++++++++++----
> > drivers/clk/sunxi-ng/ccu_nm.c | 12 ++++++++----
> > 5 files changed, 46 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/clk/sunxi-ng/ccu_mult.c b/drivers/clk/sunxi-ng/ccu_mult.c
> > index 32a1964439a2..6a02ffee5386 100644
> > --- a/drivers/clk/sunxi-ng/ccu_mult.c
> > +++ b/drivers/clk/sunxi-ng/ccu_mult.c
> > @@ -14,7 +14,7 @@
> > #include "ccu_mult.h"
> >
> > struct _ccu_mult {
> > - unsigned long mult, max;
> > + unsigned long mult, min, max;
> > };
> >
> > static void ccu_mult_find_best(unsigned long parent, unsigned long rate,
> > @@ -23,6 +23,9 @@ static void ccu_mult_find_best(unsigned long parent, unsigned long rate,
> > int _mult;
> >
> > _mult = rate / parent;
> > + if (_mult < mult->min)
> > + _mult = mult->min;
> > +
> > if (_mult > mult->max)
> > _mult = mult->max;
> >
> > @@ -37,6 +40,7 @@ static unsigned long ccu_mult_round_rate(struct ccu_mux_internal *mux,
> > struct ccu_mult *cm = data;
> > struct _ccu_mult _cm;
> >
> > + _cm.min = 1;
> > _cm.max = 1 << cm->mult.width;
> > ccu_mult_find_best(parent_rate, rate, &_cm);
> >
> > @@ -101,6 +105,7 @@ static int ccu_mult_set_rate(struct clk_hw *hw, unsigned long rate,
> > ccu_mux_helper_adjust_parent_for_prediv(&cm->common, &cm->mux, -1,
> > &parent_rate);
> >
> > + _cm.min = 1;
> > _cm.max = 1 << cm->mult.width;
> > ccu_mult_find_best(parent_rate, rate, &_cm);
> >
> > diff --git a/drivers/clk/sunxi-ng/ccu_nk.c b/drivers/clk/sunxi-ng/ccu_nk.c
> > index e7e2e75618ef..a42d870ba0ef 100644
> > --- a/drivers/clk/sunxi-ng/ccu_nk.c
> > +++ b/drivers/clk/sunxi-ng/ccu_nk.c
> > @@ -14,8 +14,8 @@
> > #include "ccu_nk.h"
> >
> > struct _ccu_nk {
> > - unsigned long n, max_n;
> > - unsigned long k, max_k;
> > + unsigned long n, min_n, max_n;
> > + unsigned long k, min_k, max_k;
> > };
> >
> > static void ccu_nk_find_best(unsigned long parent, unsigned long rate,
> > @@ -25,8 +25,8 @@ static void ccu_nk_find_best(unsigned long parent, unsigned long rate,
> > unsigned int best_k = 0, best_n = 0;
> > unsigned int _k, _n;
> >
> > - for (_k = 1; _k <= nk->max_k; _k++) {
> > - for (_n = 1; _n <= nk->max_n; _n++) {
> > + for (_k = nk->min_k; _k <= nk->max_k; _k++) {
> > + for (_n = nk->min_n; _n <= nk->max_n; _n++) {
> > unsigned long tmp_rate = parent * _n * _k;
> >
> > if (tmp_rate > rate)
> > @@ -97,7 +97,9 @@ static long ccu_nk_round_rate(struct clk_hw *hw, unsigned long rate,
> > if (nk->common.features & CCU_FEATURE_FIXED_POSTDIV)
> > rate *= nk->fixed_post_div;
> >
> > + _nk.min_n = 1;
> > _nk.max_n = 1 << nk->n.width;
> > + _nk.min_k = 1;
> > _nk.max_k = 1 << nk->k.width;
> >
> > ccu_nk_find_best(*parent_rate, rate, &_nk);
> > @@ -120,7 +122,9 @@ static int ccu_nk_set_rate(struct clk_hw *hw, unsigned long rate,
> > if (nk->common.features & CCU_FEATURE_FIXED_POSTDIV)
> > rate = rate * nk->fixed_post_div;
> >
> > + _nk.min_n = 1;
> > _nk.max_n = 1 << nk->n.width;
> > + _nk.min_k = 1;
> > _nk.max_k = 1 << nk->k.width;
> >
> > ccu_nk_find_best(parent_rate, rate, &_nk);
> > diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
> > index 0b08d000eb38..b2a5fccf2f8c 100644
> > --- a/drivers/clk/sunxi-ng/ccu_nkm.c
> > +++ b/drivers/clk/sunxi-ng/ccu_nkm.c
> > @@ -14,9 +14,9 @@
> > #include "ccu_nkm.h"
> >
> > struct _ccu_nkm {
> > - unsigned long n, max_n;
> > - unsigned long k, max_k;
> > - unsigned long m, max_m;
> > + unsigned long n, min_n, max_n;
> > + unsigned long k, min_k, max_k;
> > + unsigned long m, min_m, max_m;
> > };
> >
> > static void ccu_nkm_find_best(unsigned long parent, unsigned long rate,
> > @@ -26,9 +26,9 @@ static void ccu_nkm_find_best(unsigned long parent, unsigned long rate,
> > unsigned long best_n = 0, best_k = 0, best_m = 0;
> > unsigned long _n, _k, _m;
> >
> > - for (_k = 1; _k <= nkm->max_k; _k++) {
> > - for (_n = 1; _n <= nkm->max_n; _n++) {
> > - for (_m = 1; _n <= nkm->max_m; _m++) {
> > + for (_k = nkm->min_k; _k <= nkm->max_k; _k++) {
> > + for (_n = nkm->min_n; _n <= nkm->max_n; _n++) {
> > + for (_m = nkm->min_m; _n <= nkm->max_m; _m++) {
>
> should be _m in the condition
>
> > unsigned long tmp_rate;
> >
> > tmp_rate = parent * _n * _k / _m;
> > @@ -100,8 +100,11 @@ static unsigned long ccu_nkm_round_rate(struct ccu_mux_internal *mux,
> > struct ccu_nkm *nkm = data;
> > struct _ccu_nkm _nkm;
> >
> > + _nkm.min_n = 1;
> > _nkm.max_n = 1 << nkm->n.width;
> > + _nkm.min_k = 1;
> > _nkm.max_k = 1 << nkm->k.width;
> > + _nkm.min_m = 1;
> > _nkm.max_m = nkm->m.max ?: 1 << nkm->m.width;
> >
> > ccu_nkm_find_best(parent_rate, rate, &_nkm);
> > @@ -126,8 +129,11 @@ static int ccu_nkm_set_rate(struct clk_hw *hw, unsigned long rate,
> > unsigned long flags;
> > u32 reg;
> >
> > + _nkm.min_n = 1;
> > _nkm.max_n = 1 << nkm->n.width;
> > + _nkm.min_k = 1;
> > _nkm.max_k = 1 << nkm->k.width;
> > + _nkm.min_m = 1;
> > _nkm.max_m = nkm->m.max ?: 1 << nkm->m.width;
> >
> > ccu_nkm_find_best(parent_rate, rate, &_nkm);
> > diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c b/drivers/clk/sunxi-ng/ccu_nkmp.c
> > index 4b457d8cce11..2c1398192e48 100644
> > --- a/drivers/clk/sunxi-ng/ccu_nkmp.c
> > +++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
> > @@ -27,10 +27,10 @@ static void ccu_nkmp_find_best(unsigned long parent, unsigned long rate,
> > unsigned long best_n = 0, best_k = 0, best_m = 0, best_p = 0;
> > unsigned long _n, _k, _m, _p;
> >
> > - for (_k = 1; _k <= nkmp->max_k; _k++) {
> > - for (_n = 1; _n <= nkm->max_n; _n++) {
> > - for (_m = 1; _n <= nkm->max_m; _m++) {
> > - for (_p = 1; _p <= nkmp->max_p; _p <<= 1) {
> > + for (_k = nkmp->min_k; _k <= nkmp->max_k; _k++) {
> > + for (_n = nkmp->min_n; _n <= nkmp->max_n; _n++) {
> > + for (_m = nkmp->min_m; _n <= nkmp->max_m; _m++) {
>
> Same here: _m <= ...
>
> > + for (_p = nkmp->min_p; _p <= nkmp->max_p; _p <<= 1) {
> > unsigned long tmp_rate;
> >
> > tmp_rate = parent * _n * _k / (_m * _p);
> > @@ -107,9 +107,13 @@ static long ccu_nkmp_round_rate(struct clk_hw *hw, unsigned long rate,
> > struct ccu_nkmp *nkmp = hw_to_ccu_nkmp(hw);
> > struct _ccu_nkmp _nkmp;
> >
> > + _nkmp.min_n = 1;
> > _nkmp.max_n = 1 << nkmp->n.width;
> > + _nkmp.min_k = 1;
> > _nkmp.max_k = 1 << nkmp->k.width;
> > + _nkmp.min_m = 1;
> > _nkmp.max_m = nkmp->m.max ?: 1 << nkmp->m.width;
> > + _nkmp.min_p = 1;
> > _nkmp.max_p = nkmp->p.max ?: 1 << ((1 << nkmp->p.width) - 1);
> >
> > ccu_nkmp_find_best(*parent_rate, rate, &_nkmp);
> > @@ -125,9 +129,13 @@ static int ccu_nkmp_set_rate(struct clk_hw *hw, unsigned long rate,
> > unsigned long flags;
> > u32 reg;
> >
> > + _nkmp.min_n = 1;
> > _nkmp.max_n = 1 << nkmp->n.width;
> > + _nkmp.min_k = 1;
> > _nkmp.max_k = 1 << nkmp->k.width;
> > + _nkmp.min_m = 1;
> > _nkmp.max_m = nkmp->m.max ?: 1 << nkmp->m.width;
> > + _nkmp.min_p = 1;
> > _nkmp.max_p = nkmp->p.max ?: 1 << ((1 << nkmp->p.width) - 1);
> >
> > ccu_nkmp_find_best(parent_rate, rate, &_nkmp);
> > diff --git a/drivers/clk/sunxi-ng/ccu_nm.c b/drivers/clk/sunxi-ng/ccu_nm.c
> > index c6d652289320..2a190bc032a9 100644
> > --- a/drivers/clk/sunxi-ng/ccu_nm.c
> > +++ b/drivers/clk/sunxi-ng/ccu_nm.c
> > @@ -15,8 +15,8 @@
> > #include "ccu_nm.h"
> >
> > struct _ccu_nm {
> > - unsigned long n, max_n;
> > - unsigned long m, max_m;
> > + unsigned long n, min_n, max_n;
> > + unsigned long m, min_m, max_m;
> > };
> >
> > static void ccu_nm_find_best(unsigned long parent, unsigned long rate,
> > @@ -26,8 +26,8 @@ static void ccu_nm_find_best(unsigned long parent, unsigned long rate,
> > unsigned long best_n = 0, best_m = 0;
> > unsigned long _n, _m;
> >
> > - for (_n = 1; _n <= nm->max_n; _n++) {
> > - for (_m = 1; _n <= nm->max_m; _m++) {
> > + for (_n = nm->min_n; _n <= nm->max_n; _n++) {
> > + for (_m = nm->min_m; _n <= nm->max_m; _m++) {
>
> And here: _m <= ...
>
> Interestingly those typos were already in the code before.
Good catches, I've amended the commit in my branch (since I apparently
forgot to push...). Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/c7ee7fb8/attachment.sig>
^ permalink raw reply
* [linux-sunxi] [PATCH v5 3/4] Documentation: devicetree: add vendor prefix for Pine64
From: Maxime Ripard @ 2016-10-24 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANwerB36N8q7ppKqocRs9m62h65+vrJFn37ncc-oh+Yozz_vFQ@mail.gmail.com>
Hi Jonathan,
On Fri, Oct 21, 2016 at 11:30:01AM +1100, Jonathan Liu wrote:
> On 21 October 2016 at 05:00, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > From: Andre Przywara <andre.przywara@arm.com>
> >
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > Acked-by: Rob Herring <robh@kernel.org>
> > Acked-by: Chen-Yu Tsai <wens@csie.org>
> > [Maxime: Change title prefix to match the usual style]
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > Documentation/devicetree/bindings/vendor-prefixes.txt | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > index f0a48ea78659..4eefd1c3ff16 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > @@ -208,7 +208,7 @@ parade Parade Technologies Inc.
> > pericom Pericom Technology Inc.
> > phytec PHYTEC Messtechnik GmbH
> > picochip Picochip Ltd
> > -pixcir PIXCIR MICROELECTRONICS Co., Ltd
>
> Why is "pixcir PIXCIR MICROELECTRONICS Co., Ltd" removed?
Probably a poor rebase on my side. Good catch, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/66edcd0a/attachment.sig>
^ permalink raw reply
* [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts
From: David Lechner @ 2016-10-24 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b0022fad-a96e-86d4-71ba-2b803e5421fe@ti.com>
On 10/24/2016 06:58 AM, Sekhar Nori wrote:
> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>> This adds a device tree definition file for LEGO MINDSTORMS EV3.
>
> Thanks for the patch!
>
>>
>> What is working:
>>
>> * Pin muxing
>> * MicroSD card reader
>> * UART on input port 1
>>
>> What is partially working:
>>
>> * Buttons - working after GPIO fix
>> * LEDs - working after GPIO fix
>> * Poweroff/reset - working after GPIO fix
>
> Is the GPIO fix something that will go in v4.9-rc cycle ?
Not sure. This is still being discussed.
http://www.gossamer-threads.com/lists/linux/kernel/2550178
>
>> * Flash memory - driver loads but can't read the block devices - this is
>> probably due to the fact that we are not able to configure the SPI to
>> use DMA via device tree
>
> Hmm, I would not have expected PIO mode to be so inefficient that you
> are unable to even read the block device.
I am getting a -EIO error. I haven't been able to trace down exactly
what is causing it yet though.
>
...
>> +/ {
>> + compatible = "lego,ev3", "ti,da850";
>> + model = "LEGO MINDSTORMS EV3";
>> +
>> + soc at 1c00000 {
>> + /*
>> + * (ab)using pinctrl-single to disable all internal pullups/
>> + * pulldowns on I/O.
>> + */
>> + pinmux at 22c00c {
>> + compatible = "pinctrl-single";
>> + reg = <0x22c00c 0x4>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + pinctrl-single,bit-per-mux;
>> + pinctrl-single,register-width = <32>;
>> + pinctrl-single,function-mask = <0xf>;
>> + /*
>> + * There is a bug in pinctrl-single that prevents us
>> + * from setting function-mask to 1, so doing things
>> + * in groups of 4. Doesn't really matter since we are
>> + * disabling all at once anyway.
>> + */
>> +
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pupu_disable>;
>> +
>> + pupu_disable: pinmux_all_pins {
>> + pinctrl-single,bits = <
>> + 0x0 0x00000000 0xffffffff
>> + >;
>> + };
>
> Sigh. This is quite an abuse :)
>
> I know we don't have a good way to configure this in kernel today. And I
> am surprised we never had to care about disabling pullups so far. Can
> you clarify why you need it? I assume there is some contention you want
> to avoid, but on which interface?
The EV3 was designed with external pullup/pulldown everywhere. I know
for certain that it breaks one of the buttons if you do not disable the
internal ones. I imagine that it would have subtle effects elsewhere if
they are not disabled.
I have not gone through each pullup/pulldown bank individually, but it
would not surprise me at all if there was at least one thing on most of
them that would be adversely affected.
>
> I dont think this can be done this way using pinctrl-single. A small
> driver to handle pullup/down control for da850 may have to be added to
> drivers/pinctrl. It will be better to check with Linus Walleij on his
> thoughts using a new thread ccing the pinctrl subsystem list as well.
I will be glad to try to make a driver, but when I ran into this problem
I could not find much information on how to handle banks of
pullup/pulldown. Most of what I saw was for ones that can be
individually controlled. If anyone knows something like this already
that I could look at, it would be helpful to me.
> [...]
>
>> + in1_pins: pinmux_in1_pins {
>> + pinctrl-single,bits = <
>> + /* GP0[15] */
>> + 0x0 0x00000008 0x0000000f
>> + /* GP0[2] */
>> + 0x4 0x00800000 0x00f00000
>> + /* GP2[2] */
>> + 0x18 0x00800000 0x00f00000
>> + /* GP8[10], GP8[11] */
>> + 0x48 0x88000000 0xff000000
>> + >;
>> + };
>
> I see that this is not really used. Can you add these when you actually
> use them. Looks like that applies to some other definitions like this below.
It will be possible to uses these gpios via sysfs (until a proper driver
for input and output ports is merged). So how about I attach these to
the gpio node for now?
>
>> +&ehrpwm1 {
>> + status = "disabled";
>
> Hmm, disabled? Can you add this node when you actually use it?
Not sure why I have this disabled. Like the gpios, the pwms can be used
via sysfs, so I would like to leave them.
>
>> + pinctrl-names = "default";
>> + /* MBPWM, MAPWM */
>> + pinctrl-0 = <&ehrpwm1a_pins>, <&ehrpwm1b_pins>;
>> +};
>> +
>> +&ecap1 {
>> + status = "disabled";
>
> same here and other places below.
>
>> + pinctrl-names = "default";
>> + /* MDPWM */
>> + pinctrl-0 = <&ecap1_pins>;
>> +};
>> +
>> +&spi0 {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
>> + dmas = <&edma0 14 0>, <&edma0 15 0>;
>> + dma-names = "rx", "tx";
>> +
>> + spi-flash at 0 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "n25q128a13", "jedec,spi-nor";
>> + reg = <0>;
>> + spi-max-frequency = <50000000>;
>> + ti,spi-wdelay = <8>;
>> +
>> + partition at 0 {
>> + label = "U-Boot";
>> + reg = <0 0x40000>;
>
> Thats 256KB for U-Boot and MLO (I assume in concatenated AIS image). Is
> that sufficient for future too? Moving partitions later is tough ask
> because that means users will lose data when they upgrade the kernel
> because of partitions moving around. Just a suggestion to keep future
> U-Boot bloat in mind and not use a "just fits" number.
The MLO is on an EEPROM in the EV3, so the U-Boot partition is just
U-boot. The SoC boots from I2C, which then runs whatever is as 0x0 on
the flash memory.
This partition table matches the partition scheme used on the official
LEGO firmware that ships with the devices. Most people running their own
kernel will probably be loading it from a microSD card, leaving the
official firmware intact and therefore will always have this partition
table.
My thinking is that if someone does want to use a different partitioning
scheme, they can build their own U-Boot and configure it to modify the
device tree with a new partition table.
The way the LEGO firmware flashing utility works, it wipes out the
entire flash memory each time you flash the firmware. So, data loss is
not a concern - you will loose your data anyway.
>
>> + };
>> +
>> + partition at 40000 {
>> + label = "U-Boot Env";
>> + reg = <0x40000 0x10000>;
>> + };
>> +
>> + partition at 50000 {
>> + label = "Kernel";
>> + reg = <0x50000 0x200000>;
>> + };
>> +
>> + partition at 250000 {
>> + label = "Filesystem";
>> + reg = <0x250000 0xa50000>;
>> + };
>> +
>> + partition at cb0000 {
>> + label = "Storage";
>> + reg = <0xcb0000 0x2f0000>;
>> + };
>> + };
>> +
>> + /* TODO: ADC goes here */
>
> I would drop this comment.
ack
>
>> +};
>> +
>> +&spi1 {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&spi1_pins>, <&spi1_cs0_pin>;
>> +
>> + /* TODO: LCD Display goes here */
>
> Add this node when you actually have display working.
What if we set this up as a spidev node instead? This way the display
could be used from userspace without a driver.
^ permalink raw reply
* [PATCH 1/3] mmc: mmci: clean up header defines
From: Robin Murphy @ 2016-10-24 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477318886-24851-1-git-send-email-linus.walleij@linaro.org>
Hi Linus,
One tiny nit which stands out from a cleanup perspective...
On 24/10/16 15:21, Linus Walleij wrote:
> There was some confusion in the CPSM (Command Path State Machine)
> and DPSM (Data Path State Machine) regarding the naming of the
> registers, clarify the meaning of this acronym so the naming is
> understandable, and consistently use BIT() to define these fields.
>
> Include new definitions for a few bits found in a patch from
> Srinivas Kandagatla.
>
> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/mmc/host/mmci.c | 2 +-
> drivers/mmc/host/mmci.h | 69 +++++++++++++++++++++++++++----------------------
> 2 files changed, 39 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index df990bb8c873..79b135752d3d 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -210,7 +210,7 @@ static struct variant_data variant_qcom = {
> MCI_QCOM_CLK_SELECT_IN_FBCLK,
> .clkreg_8bit_bus_enable = MCI_QCOM_CLK_WIDEBUS_8,
> .datactrl_mask_ddrmode = MCI_QCOM_CLK_SELECT_IN_DDR_MODE,
> - .data_cmd_enable = MCI_QCOM_CSPM_DATCMD,
> + .data_cmd_enable = MCI_CPSM_QCOM_DATCMD,
> .blksz_datactrl4 = true,
> .datalength_bits = 24,
> .pwrreg_powerup = MCI_PWR_UP,
> diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
> index a1f5e4f49e2a..8952285196cd 100644
> --- a/drivers/mmc/host/mmci.h
> +++ b/drivers/mmc/host/mmci.h
> @@ -51,25 +51,27 @@
> #define MCI_QCOM_CLK_SELECT_IN_DDR_MODE (BIT(14) | BIT(15))
>
> #define MMCIARGUMENT 0x008
> -#define MMCICOMMAND 0x00c
> -#define MCI_CPSM_RESPONSE (1 << 6)
> -#define MCI_CPSM_LONGRSP (1 << 7)
> -#define MCI_CPSM_INTERRUPT (1 << 8)
> -#define MCI_CPSM_PENDING (1 << 9)
> -#define MCI_CPSM_ENABLE (1 << 10)
> -/* Argument flag extenstions in the ST Micro versions */
> -#define MCI_ST_SDIO_SUSP (1 << 11)
> -#define MCI_ST_ENCMD_COMPL (1 << 12)
> -#define MCI_ST_NIEN (1 << 13)
> -#define MCI_ST_CE_ATACMD (1 << 14)
>
> -/* Modified on Qualcomm Integrations */
> -#define MCI_QCOM_CSPM_DATCMD BIT(12)
> -#define MCI_QCOM_CSPM_MCIABORT BIT(13)
> -#define MCI_QCOM_CSPM_CCSENABLE BIT(14)
> -#define MCI_QCOM_CSPM_CCSDISABLE BIT(15)
> -#define MCI_QCOM_CSPM_AUTO_CMD19 BIT(16)
> -#define MCI_QCOM_CSPM_AUTO_CMD21 BIT(21)
> +/* The command register controls the Command Path State Machine (CPSM) */
> +#define MMCICOMMAND 0x00c
> +#define MCI_CPSM_RESPONSE BIT(6)
> +#define MCI_CPSM_LONGRSP BIT(7)
> +#define MCI_CPSM_INTERRUPT BIT(8)
> +#define MCI_CPSM_PENDING BIT(9)
> +#define MCI_CPSM_ENABLE BIT(10)
> +/* Command register flag extenstions in the ST Micro versions */
> +#define MCI_CPSM_ST_SDIO_SUSP BIT(11)
> +#define MCI_CPSM_ST_ENCMD_COMPL BIT(12)
> +#define MCI_CPSM_ST_NIEN BIT(13)
> +#define MCI_CPSM_ST_CE_ATACMD BIT(14)
> +/* Command register flag extensions in the Qualcomm versions */
> +#define MCI_CPSM_QCOM_PROGENA BIT(11)
> +#define MCI_CPSM_QCOM_DATCMD BIT(12)
> +#define MCI_CPSM_QCOM_MCIABORT BIT(13)
> +#define MCI_CPSM_QCOM_CCSENABLE BIT(14)
> +#define MCI_CPSM_QCOM_CCSDISABLE BIT(15)
> +#define MCI_CPSM_QCOM_AUTO_CMD19 BIT(16)
> +#define MCI_CPSM_QCOM_AUTO_CMD21 BIT(21)
These definitions take the format of MCI_register_{vendor_}field...
> #define MMCIRESPCMD 0x010
> #define MMCIRESPONSE0 0x014
> @@ -78,22 +80,27 @@
> #define MMCIRESPONSE3 0x020
> #define MMCIDATATIMER 0x024
> #define MMCIDATALENGTH 0x028
> +
> +/* The data control register controls the Data Path State Machine (DPSM) */
> #define MMCIDATACTRL 0x02c
> -#define MCI_DPSM_ENABLE (1 << 0)
> -#define MCI_DPSM_DIRECTION (1 << 1)
> -#define MCI_DPSM_MODE (1 << 2)
> -#define MCI_DPSM_DMAENABLE (1 << 3)
> -#define MCI_DPSM_BLOCKSIZE (1 << 4)
> +#define MCI_DPSM_ENABLE BIT(0)
> +#define MCI_DPSM_DIRECTION BIT(1)
> +#define MCI_DPSM_MODE BIT(2)
> +#define MCI_DPSM_DMAENABLE BIT(3)
> +#define MCI_DPSM_BLOCKSIZE BIT(4)
> /* Control register extensions in the ST Micro U300 and Ux500 versions */
> -#define MCI_ST_DPSM_RWSTART (1 << 8)
> -#define MCI_ST_DPSM_RWSTOP (1 << 9)
> -#define MCI_ST_DPSM_RWMOD (1 << 10)
> -#define MCI_ST_DPSM_SDIOEN (1 << 11)
> +#define MCI_ST_DPSM_RWSTART BIT(8)
> +#define MCI_ST_DPSM_RWSTOP BIT(9)
> +#define MCI_ST_DPSM_RWMOD BIT(10)
> +#define MCI_ST_DPSM_SDIOEN BIT(11)
> /* Control register extensions in the ST Micro Ux500 versions */
> -#define MCI_ST_DPSM_DMAREQCTL (1 << 12)
> -#define MCI_ST_DPSM_DBOOTMODEEN (1 << 13)
> -#define MCI_ST_DPSM_BUSYMODE (1 << 14)
> -#define MCI_ST_DPSM_DDRMODE (1 << 15)
> +#define MCI_ST_DPSM_DMAREQCTL BIT(12)
> +#define MCI_ST_DPSM_DBOOTMODEEN BIT(13)
> +#define MCI_ST_DPSM_BUSYMODE BIT(14)
> +#define MCI_ST_DPSM_DDRMODE BIT(15)
> +/* Control register extensions in the Qualcomm versions */
> +#define MCI_QCOM_DPSM_DATA_PEND BIT(17)
> +#define MCI_QCOM_DPSM_RX_DATA_PEND BIT(20)
...but these retain the previous MCI_{vendor_}register_field format - it
seems like a needless inconsistency, but if there is some good reason
then fair enough (I only have the vaguest familiarity with this IP/driver).
Robin.
>
> #define MMCIDATACNT 0x030
> #define MMCISTATUS 0x034
>
^ permalink raw reply
* [PATCH] arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU
From: Marc Zyngier @ 2016-10-24 15:31 UTC (permalink / raw)
To: linux-arm-kernel
Architecturally, TLBs are private to the (physical) CPU they're
associated with. But when multiple vcpus from the same VM are
being multiplexed on the same CPU, the TLBs are not private
to the vcpus (and are actually shared across the VMID).
Let's consider the following scenario:
- vcpu-0 maps PA to VA
- vcpu-1 maps PA' to VA
If run on the same physical CPU, vcpu-1 can hit TLB entries generated
by vcpu-0 accesses, and access the wrong physical page.
The solution to this is to keep a per-VM map of which vcpu ran last
on each given physical CPU, and invalidate local TLBs when switching
to a different vcpu from the same VM.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm/include/asm/kvm_host.h | 5 +++++
arch/arm/include/asm/kvm_hyp.h | 1 +
arch/arm/kvm/arm.c | 35 ++++++++++++++++++++++++++++++++++-
arch/arm/kvm/hyp/switch.c | 9 +++++++++
arch/arm64/include/asm/kvm_host.h | 6 +++++-
arch/arm64/kvm/hyp/switch.c | 8 ++++++++
6 files changed, 62 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 2d19e02..035e744 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -57,6 +57,8 @@ struct kvm_arch {
/* VTTBR value associated with below pgd and vmid */
u64 vttbr;
+ int __percpu *last_vcpu_ran;
+
/* Timer */
struct arch_timer_kvm timer;
@@ -174,6 +176,9 @@ struct kvm_vcpu_arch {
/* vcpu power-off state */
bool power_off;
+ /* TLBI required */
+ bool requires_tlbi;
+
/* Don't run the guest (internal implementation need) */
bool pause;
diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h
index 343135e..5850890 100644
--- a/arch/arm/include/asm/kvm_hyp.h
+++ b/arch/arm/include/asm/kvm_hyp.h
@@ -71,6 +71,7 @@
#define ICIALLUIS __ACCESS_CP15(c7, 0, c1, 0)
#define ATS1CPR __ACCESS_CP15(c7, 0, c8, 0)
#define TLBIALLIS __ACCESS_CP15(c8, 0, c3, 0)
+#define TLBIALL __ACCESS_CP15(c8, 0, c7, 0)
#define TLBIALLNSNHIS __ACCESS_CP15(c8, 4, c3, 4)
#define PRRR __ACCESS_CP15(c10, 0, c2, 0)
#define NMRR __ACCESS_CP15(c10, 0, c2, 1)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 03e9273..09942f0 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -114,11 +114,18 @@ void kvm_arch_check_processor_compat(void *rtn)
*/
int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
{
- int ret = 0;
+ int ret, cpu;
if (type)
return -EINVAL;
+ kvm->arch.last_vcpu_ran = alloc_percpu(typeof(*kvm->arch.last_vcpu_ran));
+ if (!kvm->arch.last_vcpu_ran)
+ return -ENOMEM;
+
+ for_each_possible_cpu(cpu)
+ *per_cpu_ptr(kvm->arch.last_vcpu_ran, cpu) = -1;
+
ret = kvm_alloc_stage2_pgd(kvm);
if (ret)
goto out_fail_alloc;
@@ -141,6 +148,8 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
out_free_stage2_pgd:
kvm_free_stage2_pgd(kvm);
out_fail_alloc:
+ free_percpu(kvm->arch.last_vcpu_ran);
+ kvm->arch.last_vcpu_ran = NULL;
return ret;
}
@@ -168,6 +177,9 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
{
int i;
+ free_percpu(kvm->arch.last_vcpu_ran);
+ kvm->arch.last_vcpu_ran = NULL;
+
for (i = 0; i < KVM_MAX_VCPUS; ++i) {
if (kvm->vcpus[i]) {
kvm_arch_vcpu_free(kvm->vcpus[i]);
@@ -310,6 +322,27 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
return 0;
}
+void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu)
+{
+ int *last_ran;
+
+ last_ran = per_cpu_ptr(vcpu->kvm->arch.last_vcpu_ran, cpu);
+
+ /*
+ * If we're very unlucky and get preempted before having ran
+ * this vcpu for real, we'll end-up in a situation where any
+ * vcpu that gets scheduled will perform an invalidation (this
+ * vcpu explicitely requires it, and all the others will have
+ * a different vcpu_id).
+ */
+ if (*last_ran != vcpu->vcpu_id) {
+ if (*last_ran != -1)
+ vcpu->arch.requires_tlbi = true;
+
+ *last_ran = vcpu->vcpu_id;
+ }
+}
+
void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
{
vcpu->cpu = cpu;
diff --git a/arch/arm/kvm/hyp/switch.c b/arch/arm/kvm/hyp/switch.c
index 92678b7..ab8ee3b 100644
--- a/arch/arm/kvm/hyp/switch.c
+++ b/arch/arm/kvm/hyp/switch.c
@@ -75,6 +75,15 @@ static void __hyp_text __activate_vm(struct kvm_vcpu *vcpu)
{
struct kvm *kvm = kern_hyp_va(vcpu->kvm);
write_sysreg(kvm->arch.vttbr, VTTBR);
+ if (vcpu->arch.requires_tlbi) {
+ /* Force vttbr to be written */
+ isb();
+ /* Local invalidate only for this VMID */
+ write_sysreg(0, TLBIALL);
+ dsb(nsh);
+ vcpu->arch.requires_tlbi = false;
+ }
+
write_sysreg(vcpu->arch.midr, VPIDR);
}
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index bd94e67..5b42010 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -62,6 +62,8 @@ struct kvm_arch {
/* VTTBR value associated with above pgd and vmid */
u64 vttbr;
+ int __percpu *last_vcpu_ran;
+
/* The maximum number of vCPUs depends on the used GIC model */
int max_vcpus;
@@ -252,6 +254,9 @@ struct kvm_vcpu_arch {
/* vcpu power-off state */
bool power_off;
+ /* TLBI required */
+ bool requires_tlbi;
+
/* Don't run the guest (internal implementation need) */
bool pause;
@@ -368,7 +373,6 @@ static inline void __cpu_reset_hyp_mode(unsigned long vector_ptr,
static inline void kvm_arch_hardware_unsetup(void) {}
static inline void kvm_arch_sync_events(struct kvm *kvm) {}
static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
-static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
void kvm_arm_init_debug(void);
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index 83037cd..8d9c3eb 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -131,6 +131,14 @@ static void __hyp_text __activate_vm(struct kvm_vcpu *vcpu)
{
struct kvm *kvm = kern_hyp_va(vcpu->kvm);
write_sysreg(kvm->arch.vttbr, vttbr_el2);
+ if (vcpu->arch.requires_tlbi) {
+ /* Force vttbr_el2 to be written */
+ isb();
+ /* Local invalidate only for this VMID */
+ asm volatile("tlbi vmalle1" : : );
+ dsb(nsh);
+ vcpu->arch.requires_tlbi = false;
+ }
}
static void __hyp_text __deactivate_vm(struct kvm_vcpu *vcpu)
--
2.1.4
^ permalink raw reply related
* [PATCH 2/5] ARM: davinci: Don't append git rev to local version
From: David Lechner @ 2016-10-24 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20f3efba-4f79-3675-d2ce-09efe90fb692@ti.com>
On 10/24/2016 06:35 AM, Sekhar Nori wrote:
> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>> In the davinci default configuration, don't append the git revision to
>> the local kernel version by. This seems like the more desirable default
>> value.
>
> Why? To the contrary I actually quite like the fact that the git commit
> is appended to version string. Makes it easy for me to cross-check that
> I am booting the right image.
>
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>
> Thanks,
> Sekhar
>
Each time you make a commit, you get a new version, which installs
another copy of the kernel modules on the device. This will fill up the
SD card if you are making many commits.
Also, if someone wants to build the mainline kernel using the default
configuration, it seems odd to have a git revision tacked on to the end
even though you made no revisions.
^ permalink raw reply
* [PATCH] ARM64: dts: bcm2835: Fix bcm2837 compatible string
From: Andreas Färber @ 2016-10-24 15:09 UTC (permalink / raw)
To: linux-arm-kernel
bcm2837-rpi-3-b.dts, its only in-tree user, was overriding it as
"brcm,bcm2837" already.
Fixes: 9d56c22a7861 ("ARM: bcm2835: Add devicetree for the Raspberry Pi 3.")
Cc: Eric Anholt <eric@anholt.net>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Andreas F?rber <afaerber@suse.de>
---
arch/arm64/boot/dts/broadcom/bcm2837.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi b/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
index 8216bbb29fe0..c1f719b7097a 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
+++ b/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
@@ -1,7 +1,7 @@
#include "bcm283x.dtsi"
/ {
- compatible = "brcm,bcm2836";
+ compatible = "brcm,bcm2837";
soc {
ranges = <0x7e000000 0x3f000000 0x1000000>,
--
2.6.6
^ permalink raw reply related
* 4.9 RC2 fails to boot on mk802ii with generic DT based cpufreq driver
From: Jost Menke @ 2016-10-24 15:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I ran into a problem with the recent mainline kernel on my Allwinner A10 based MK802ii. It looks like a wrong initial CPU frequency is chosen. It will boot until this point:
[3.040447] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 384000 KHz
[3.057932] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 624000 KHz
After that, it just freezes. When I compile with a different cpufreq driver, it will boot up but there doesn't seem to be any frequency scaling (/sys/devices/system/cpu/cpu0/cpufreq is empty) and I think it just remains at a very low clock speed because sysbench results are really slow.
Any ideas?
Cheers
Jost
^ permalink raw reply
* [PATCH v4 6/9] clk: sunxi-ng: Add A64 clocks
From: Maxime Ripard @ 2016-10-24 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020184601.GB26139@codeaurora.org>
Hi Stephen,
On Thu, Oct 20, 2016 at 11:46:01AM -0700, Stephen Boyd wrote:
> On 10/11, Maxime Ripard wrote:
> > diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> > new file mode 100644
> > index 000000000000..c0e96bf6d104
> > --- /dev/null
> > +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> > +
> > +static int sun50i_a64_ccu_probe(struct platform_device *pdev)
> > +{
> > + struct resource *res;
> > + void __iomem *reg;
> > + u32 val;
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + reg = devm_ioremap_resource(&pdev->dev, res);
> > + if (IS_ERR(reg)) {
> > + dev_err(&pdev->dev, "Could not map the clock registers\n");
>
> devm_ioremap_resource() should already spit out an error.
>
> > + return PTR_ERR(reg);
> > + }
> > +
> > + /* Force the PLL-Audio-1x divider to 4 */
> > + val = readl(reg + SUN50I_A64_PLL_AUDIO_REG);
> > + val &= ~GENMASK(19, 16);
> > + writel(val | (3 << 16), reg + SUN50I_A64_PLL_AUDIO_REG);
> > +
> > + writel(0x515, reg + SUN50I_A64_PLL_MIPI_REG);
> > +
> > + return sunxi_ccu_probe(pdev->dev.of_node, reg, &sun50i_a64_ccu_desc);
> > +}
> > +
> > +static const struct of_device_id sun50i_a64_ccu_ids[] = {
> > + { .compatible = "allwinner,sun50i-a64-ccu" },
> > + { },
>
> Nitpick: drop the comma
Thanks for your comments, it's fixed.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/962b7cf5/attachment.sig>
^ permalink raw reply
* [PATCH] Documentation: DMA-API: Clarify semantics of dma_set_mask_and_coherent
From: Arnd Bergmann @ 2016-10-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021150916.0d274e9f@lwn.net>
On Friday, October 21, 2016 3:09:16 PM CEST Jonathan Corbet wrote:
> On Mon, 17 Oct 2016 16:26:23 +0100
> Punit Agrawal <punit.agrawal@arm.com> wrote:
>
> > The dma mapping api howto gives the impression that using the
> > dma_set_mask_and_coherent (and related DMA APIs) will cause the kernel
> > to check all the components in the path from the device to memory for
> > addressing restrictions. In systems with address translations between
> > the device and memory (e.g., when using IOMMU), this implies that a
> > successful call to set set dma mask has checked the addressing
> > constraints of the intermediaries as well.
> >
> > For the IOMMU drivers in the tree, the check is actually performed while
> > allocating the DMA buffer rather than when the DMA mask is
> > configured. For MMUs that do not support the full device addressing
> > capability, the allocations are made from a reduced address space.
> >
> > Update the documentation to clarify that even though the call to
> > dma_set_mask_and_coherent succeeds, it may not be possible to use the
> > full addressing capability of the device.
>
> OK, so I guess I can buy this. But...
>
> > Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> > Cc: Jonathan Corbet <corbet@lwn.net>
> > ---
> > Documentation/DMA-API-HOWTO.txt | 39 +++++++++++++++++++++++----------------
> > 1 file changed, 23 insertions(+), 16 deletions(-)
> >
> > diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
> > index 979228b..240d1ee 100644
> > --- a/Documentation/DMA-API-HOWTO.txt
> > +++ b/Documentation/DMA-API-HOWTO.txt
> > @@ -159,39 +159,46 @@ support 64-bit addressing (DAC) for all transactions. And at least
> > one platform (SGI SN2) requires 64-bit consistent allocations to
> > operate correctly when the IO bus is in PCI-X mode.
> >
> > -For correct operation, you must interrogate the kernel in your device
> > -probe routine to see if the DMA controller on the machine can properly
> > -support the DMA addressing limitation your device has. It is good
> > +For correct operation, you must inform the kernel in your device probe
> > +routine to see if the DMA controller on the machine can properly
> > +support the DMA addressing capabilities your device has. It is good
>
> Here it's still saying "to see if the DMA controller on the machine can
> properly support the DMA addressing capabilities your device has". So
> you've not really changed the sense of this sentence here.
>
> If I understand things correctly, the calls in question are storing the
> device's limitations; they will only fail if the kernel is entirely
> unable to work within the indicated range, right? I don't think there's
> ever been any guarantee that the system as a whole could use the entire
> range that is addressable by the device. I have no objection to making
> that more clear, but let's actually make it more clear by saying what the
> functions are actually doing.
>
> Make sense, or am I missing something here?
The call is a two-way interface, and the existing text tries to convey
that already: The device tells the kernel whether it is limited (< 32
bit mask) or if it can support extended addresses (> 32 bit mask),
or just handles the default 32bit mask, and the kernel should come
back saying whether that mask allows a correct operation of the device
on the given platform, as well as set it up correctly that way.
What exactly happens in dma_set_mask() and the related interfaces
is highly platform specific, including:
- if the mask is smaller than the smallest memory zone and the
swiotlb bounce buffers (if any) don't fit inside it, it has to
fail
- if the device claims to support larger mask, but the bus it
connects to does not (e.g. a 32-bit PCI host), it may
also fail (or succeed if there is no RAM outside of the
intersection of the two masks)
- if the mask is large enough to cover all RAM, we can bypass
the IOMMU and use a direct mapping
- if swiotlb is enabled or an IOMMU is present, any mask that
includes the bounce buffer area (or the virtual address space
of the IOMMU) should succeed.
Arnd
^ permalink raw reply
* [PATCH] drm/sun4i: Add a few formats
From: Maxime Ripard @ 2016-10-24 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65uZFQnRme9LrRykze=a4d_7=HS=Gvu6E_eBG5tSw8nTw@mail.gmail.com>
Hi,
On Fri, Oct 21, 2016 at 11:15:32AM +0800, Chen-Yu Tsai wrote:
> On Tue, Oct 18, 2016 at 4:46 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > The planes can do more than what was previously exposed. Add support for
> > them.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > drivers/gpu/drm/sun4i/sun4i_backend.c | 20 ++++++++++++++++++++
> > drivers/gpu/drm/sun4i/sun4i_layer.c | 6 ++++++
> > 2 files changed, 26 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
> > index afb7ddf660ef..b184a476a480 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> > @@ -96,6 +96,22 @@ static int sun4i_backend_drm_format_to_layer(struct drm_plane *plane,
> > *mode = SUN4I_BACKEND_LAY_FBFMT_ARGB8888;
> > break;
> >
> > + case DRM_FORMAT_ARGB4444:
> > + *mode = SUN4I_BACKEND_LAY_FBFMT_ARGB4444;
> > + break;
> > +
> > + case DRM_FORMAT_ARGB1555:
> > + *mode = SUN4I_BACKEND_LAY_FBFMT_ARGB1555;
> > + break;
> > +
> > + case DRM_FORMAT_RGBA5551:
> > + *mode = SUN4I_BACKEND_LAY_FBFMT_RGBA5551;
> > + break;
> > +
> > + case DRM_FORMAT_RGBA4444:
> > + *mode = SUN4I_BACKEND_LAY_FBFMT_RGBA4444;
>
> The A20 manual only lists ARGB4444, not RGBA4444. There might be
> some discrepancy here. We can deal with them
Hmm, yes, that's weird. But I guess this would be part of porting it
to the A20.
> Also there are some more formats missing from the list, could you
> add them as well?
Which one do you refer to?
> > + break;
> > +
> > case DRM_FORMAT_XRGB8888:
> > *mode = SUN4I_BACKEND_LAY_FBFMT_XRGB8888;
> > break;
> > @@ -104,6 +120,10 @@ static int sun4i_backend_drm_format_to_layer(struct drm_plane *plane,
> > *mode = SUN4I_BACKEND_LAY_FBFMT_RGB888;
> > break;
> >
> > + case DRM_FORMAT_RGB565:
> > + *mode = SUN4I_BACKEND_LAY_FBFMT_RGB565;
> > + break;
> > +
> > default:
> > return -EINVAL;
> > }
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c b/drivers/gpu/drm/sun4i/sun4i_layer.c
> > index f0035bf5efea..5d53c977bca5 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_layer.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
> > @@ -73,12 +73,18 @@ static const struct drm_plane_funcs sun4i_backend_layer_funcs = {
> > static const uint32_t sun4i_backend_layer_formats_primary[] = {
> > DRM_FORMAT_ARGB8888,
> > DRM_FORMAT_RGB888,
> > + DRM_FORMAT_RGB565,
> > DRM_FORMAT_XRGB8888,
> > };
> >
> > static const uint32_t sun4i_backend_layer_formats_overlay[] = {
> > DRM_FORMAT_ARGB8888,
> > + DRM_FORMAT_ARGB4444,
> > + DRM_FORMAT_ARGB1555,
> > + DRM_FORMAT_RGBA5551,
> > + DRM_FORMAT_RGBA4444,
> > DRM_FORMAT_RGB888,
> > + DRM_FORMAT_RGB565,
> > DRM_FORMAT_XRGB8888,
>
> Could you explain in the commit log why these 2 aren't the same?
Yep, I will.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/66862cae/attachment.sig>
^ permalink raw reply
* [PATCH 3/3] RFC: mmc: mmci: add qcom specific program end support
From: Linus Walleij @ 2016-10-24 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477318886-24851-1-git-send-email-linus.walleij@linaro.org>
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
This patch adds support to programend interrupt which is very
specific to QCOM integration. This interrupt is use as busy signal
when a command forces the card to enter into programming state
like CMD6 writing to ext_csd registers.
Hopefully, this also fixes the __mmc_switch timeout issue reproted
with latest versions of the eMMC used on DB600c board.
This patch is based on a WIP patch from Srinivas Kandagatla and
augmented by Linus Walleij for another approach.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Srinivas: please test to see if this fixes your problems. Sadly
it does *NOT* solve my APQ8060 issues, but it would be nice if
the common code path works for the busy detection on your
DB600c.
---
drivers/mmc/host/mmci.c | 21 +++++++++++++++++++--
drivers/mmc/host/mmci.h | 6 ++++++
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 06e19d8359e0..c0380713df34 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -72,7 +72,10 @@ static unsigned int fmax = 515633;
* @signal_direction: input/out direction of bus signals can be indicated
* @pwrreg_clkgate: MMCIPOWER register must be used to gate the clock
* @busy_detect: true if the variant supports busy detection on DAT0.
- * @busy_dpsm_flag: bitmask enabling busy detection in the DPSM
+ * @busy_cpsm_flag: bitmask enabling busy detection in the CPSM (command
+ * path state machine)
+ * @busy_dpsm_flag: bitmask enabling busy detection in the DPSM (data path
+ * state machine)
* @busy_detect_flag: bitmask identifying the bit in the MMCISTATUS register
* indicating that the card is busy
* @busy_detect_mask: bitmask identifying the bit in the MMCIMASK0 to mask for
@@ -103,6 +106,7 @@ struct variant_data {
bool signal_direction;
bool pwrreg_clkgate;
bool busy_detect;
+ u32 busy_cpsm_flag;
u32 busy_dpsm_flag;
u32 busy_detect_flag;
u32 busy_detect_mask;
@@ -229,6 +233,10 @@ static struct variant_data variant_qcom = {
.datalength_bits = 24,
.pwrreg_powerup = MCI_PWR_UP,
.f_max = 208000000,
+ .busy_detect = true,
+ .busy_cpsm_flag = MCI_CPSM_QCOM_PROGENA,
+ .busy_detect_flag = MCI_QCOM_PROGDONE,
+ .busy_detect_mask = MCI_QCOM_PROGDONEMASK,
.explicit_mclk_control = true,
.qcom_fifo = true,
.qcom_dml = true,
@@ -903,6 +911,15 @@ mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c)
if (/*interrupt*/0)
c |= MCI_CPSM_INTERRUPT;
+ /*
+ * Enable the program end interrupt for specific commands
+ * used for busy detection.
+ */
+ if (host->variant->busy_detect &&
+ (cmd->flags & MMC_RSP_R1B) == MMC_RSP_R1B) {
+ c |= host->variant->busy_cpsm_flag;
+ }
+
if (mmc_cmd_type(cmd) == MMC_CMD_ADTC)
c |= host->variant->data_cmd_enable;
@@ -1005,7 +1022,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
return;
/*
- * ST Micro variant: handle busy detection.
+ * ST Micro and Qualcomm variants: handle busy detection.
*/
if (host->variant->busy_detect) {
bool busy_resp = !!(cmd->flags & MMC_RSP_BUSY);
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 38f6f1365ec4..99abf02f560e 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -130,6 +130,8 @@
#define MCI_ST_SDIOIT (1 << 22)
#define MCI_ST_CEATAEND (1 << 23)
#define MCI_ST_CARDBUSY (1 << 24)
+/* Extended status bits for the QCOM variants */
+#define MCI_QCOM_PROGDONE (1 << 23)
#define MMCICLEAR 0x038
#define MCI_CMDCRCFAILCLR (1 << 0)
@@ -147,6 +149,8 @@
#define MCI_ST_SDIOITC (1 << 22)
#define MCI_ST_CEATAENDC (1 << 23)
#define MCI_ST_BUSYENDC (1 << 24)
+/* Extended status bits for the QCOM variants */
+#define MCI_QCOM_PROGDONECLR (1 << 23)
#define MMCIMASK0 0x03c
#define MCI_CMDCRCFAILMASK (1 << 0)
@@ -175,6 +179,8 @@
#define MCI_ST_SDIOITMASK (1 << 22)
#define MCI_ST_CEATAENDMASK (1 << 23)
#define MCI_ST_BUSYENDMASK (1 << 24)
+/* Extended status bits for the Qualcomm variants */
+#define MCI_QCOM_PROGDONEMASK (1 << 23)
#define MMCIMASK1 0x040
#define MMCIFIFOCNT 0x048
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] mmc: mmci: refactor ST Micro busy detection
From: Linus Walleij @ 2016-10-24 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477318886-24851-1-git-send-email-linus.walleij@linaro.org>
The ST Micro-specific busy detection was made after the assumption
that only this variant supports busy detection. So when doing busy
detection, the host immediately tries to use some ST-specific
register bits.
Since the qualcomm variant also supports some busy detection
schemes, encapsulate the variant flags better in the variant struct
and prepare to add more variants by just providing some bitmasks
to the logic.
Put the entire busy detection logic within an if()-clause in the
mmci_cmd_irq() function so the code is only executed when busy
detection is enabled, and so that it is kept in (almost) one
place, and add comments describing what is going on so the
code can be understood.
Tested on the Ux500 by introducing some prints in the busy
detection path and noticing how the IRQ is enabled, used and
disabled successfully.
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/mmc/host/mmci.c | 113 +++++++++++++++++++++++++++++++++++-------------
drivers/mmc/host/mmci.h | 2 +-
2 files changed, 85 insertions(+), 30 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 79b135752d3d..06e19d8359e0 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -71,7 +71,12 @@ static unsigned int fmax = 515633;
* @f_max: maximum clk frequency supported by the controller.
* @signal_direction: input/out direction of bus signals can be indicated
* @pwrreg_clkgate: MMCIPOWER register must be used to gate the clock
- * @busy_detect: true if busy detection on dat0 is supported
+ * @busy_detect: true if the variant supports busy detection on DAT0.
+ * @busy_dpsm_flag: bitmask enabling busy detection in the DPSM
+ * @busy_detect_flag: bitmask identifying the bit in the MMCISTATUS register
+ * indicating that the card is busy
+ * @busy_detect_mask: bitmask identifying the bit in the MMCIMASK0 to mask for
+ * getting busy end detection interrupts
* @pwrreg_nopower: bits in MMCIPOWER don't controls ext. power supply
* @explicit_mclk_control: enable explicit mclk control in driver.
* @qcom_fifo: enables qcom specific fifo pio read logic.
@@ -98,6 +103,9 @@ struct variant_data {
bool signal_direction;
bool pwrreg_clkgate;
bool busy_detect;
+ u32 busy_dpsm_flag;
+ u32 busy_detect_flag;
+ u32 busy_detect_mask;
bool pwrreg_nopower;
bool explicit_mclk_control;
bool qcom_fifo;
@@ -178,6 +186,9 @@ static struct variant_data variant_ux500 = {
.signal_direction = true,
.pwrreg_clkgate = true,
.busy_detect = true,
+ .busy_dpsm_flag = MCI_ST_DPSM_BUSYMODE,
+ .busy_detect_flag = MCI_ST_CARDBUSY,
+ .busy_detect_mask = MCI_ST_BUSYENDMASK,
.pwrreg_nopower = true,
};
@@ -199,6 +210,9 @@ static struct variant_data variant_ux500v2 = {
.signal_direction = true,
.pwrreg_clkgate = true,
.busy_detect = true,
+ .busy_dpsm_flag = MCI_ST_DPSM_BUSYMODE,
+ .busy_detect_flag = MCI_ST_CARDBUSY,
+ .busy_detect_mask = MCI_ST_BUSYENDMASK,
.pwrreg_nopower = true,
};
@@ -220,6 +234,7 @@ static struct variant_data variant_qcom = {
.qcom_dml = true,
};
+/* Busy detection for the ST Micro variant */
static int mmci_card_busy(struct mmc_host *mmc)
{
struct mmci_host *host = mmc_priv(mmc);
@@ -227,7 +242,7 @@ static int mmci_card_busy(struct mmc_host *mmc)
int busy = 0;
spin_lock_irqsave(&host->lock, flags);
- if (readl(host->base + MMCISTATUS) & MCI_ST_CARDBUSY)
+ if (readl(host->base + MMCISTATUS) & host->variant->busy_detect_flag)
busy = 1;
spin_unlock_irqrestore(&host->lock, flags);
@@ -294,8 +309,8 @@ static void mmci_write_pwrreg(struct mmci_host *host, u32 pwr)
*/
static void mmci_write_datactrlreg(struct mmci_host *host, u32 datactrl)
{
- /* Keep ST Micro busy mode if enabled */
- datactrl |= host->datactrl_reg & MCI_ST_DPSM_BUSYMODE;
+ /* Keep busy mode in DPSM if enabled */
+ datactrl |= host->datactrl_reg & host->variant->busy_dpsm_flag;
if (host->datactrl_reg != datactrl) {
host->datactrl_reg = datactrl;
@@ -973,37 +988,66 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
unsigned int status)
{
void __iomem *base = host->base;
- bool sbc, busy_resp;
+ bool sbc;
if (!cmd)
return;
sbc = (cmd == host->mrq->sbc);
- busy_resp = host->variant->busy_detect && (cmd->flags & MMC_RSP_BUSY);
- if (!((status|host->busy_status) & (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT|
- MCI_CMDSENT|MCI_CMDRESPEND)))
+ /*
+ * We need to be one of these interrupts to be considered worth
+ * handling. Note that we tag on any latent IRQs postponed
+ * due to waiting for busy status.
+ */
+ if (!((status|host->busy_status) &
+ (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT|MCI_CMDSENT|MCI_CMDRESPEND)))
return;
- /* Check if we need to wait for busy completion. */
- if (host->busy_status && (status & MCI_ST_CARDBUSY))
- return;
+ /*
+ * ST Micro variant: handle busy detection.
+ */
+ if (host->variant->busy_detect) {
+ bool busy_resp = !!(cmd->flags & MMC_RSP_BUSY);
- /* Enable busy completion if needed and supported. */
- if (!host->busy_status && busy_resp &&
- !(status & (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT)) &&
- (readl(base + MMCISTATUS) & MCI_ST_CARDBUSY)) {
- writel(readl(base + MMCIMASK0) | MCI_ST_BUSYEND,
- base + MMCIMASK0);
- host->busy_status = status & (MCI_CMDSENT|MCI_CMDRESPEND);
- return;
- }
+ /* We are busy with a command, return */
+ if (host->busy_status &&
+ (status & host->variant->busy_detect_flag))
+ return;
+
+ /*
+ * We were not busy, but we now got a busy response on
+ * something that was not an error, and we double-check
+ * that the special busy status bit is still set before
+ * proceeding.
+ */
+ if (!host->busy_status && busy_resp &&
+ !(status & (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT)) &&
+ (readl(base + MMCISTATUS) & host->variant->busy_detect_flag)) {
+ /* Unmask the busy IRQ */
+ writel(readl(base + MMCIMASK0) |
+ host->variant->busy_detect_mask,
+ base + MMCIMASK0);
+ /*
+ * Now cache the last response status code (until
+ * the busy bit goes low), and return.
+ */
+ host->busy_status =
+ status & (MCI_CMDSENT|MCI_CMDRESPEND);
+ return;
+ }
- /* At busy completion, mask the IRQ and complete the request. */
- if (host->busy_status) {
- writel(readl(base + MMCIMASK0) & ~MCI_ST_BUSYEND,
- base + MMCIMASK0);
- host->busy_status = 0;
+ /*
+ * At this point we are not busy with a command, we have
+ * not recieved a new busy request, mask the busy IRQ and
+ * fall through to process the IRQ.
+ */
+ if (host->busy_status) {
+ writel(readl(base + MMCIMASK0) &
+ ~host->variant->busy_detect_mask,
+ base + MMCIMASK0);
+ host->busy_status = 0;
+ }
}
host->cmd = NULL;
@@ -1257,9 +1301,11 @@ static irqreturn_t mmci_irq(int irq, void *dev_id)
mmci_data_irq(host, host->data, status);
}
- /* Don't poll for busy completion in irq context. */
- if (host->busy_status)
- status &= ~MCI_ST_CARDBUSY;
+ /*
+ * Don't poll for busy completion in irq context.
+ */
+ if (host->variant->busy_detect && host->busy_status)
+ status &= ~host->variant->busy_detect_flag;
ret = 1;
} while (status);
@@ -1612,9 +1658,18 @@ static int mmci_probe(struct amba_device *dev,
/* We support these capabilities. */
mmc->caps |= MMC_CAP_CMD23;
+ /*
+ * Enable busy detection.
+ */
if (variant->busy_detect) {
mmci_ops.card_busy = mmci_card_busy;
- mmci_write_datactrlreg(host, MCI_ST_DPSM_BUSYMODE);
+ /*
+ * Not all variants have a flag to enable busy detection
+ * in the DPSM, but if they do, set it here.
+ */
+ if (variant->busy_dpsm_flag)
+ mmci_write_datactrlreg(host,
+ host->variant->busy_dpsm_flag);
mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY;
mmc->max_busy_timeout = 0;
}
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 8952285196cd..38f6f1365ec4 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -174,7 +174,7 @@
/* Extended status bits for the ST Micro variants */
#define MCI_ST_SDIOITMASK (1 << 22)
#define MCI_ST_CEATAENDMASK (1 << 23)
-#define MCI_ST_BUSYEND (1 << 24)
+#define MCI_ST_BUSYENDMASK (1 << 24)
#define MMCIMASK1 0x040
#define MMCIFIFOCNT 0x048
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] mmc: mmci: clean up header defines
From: Linus Walleij @ 2016-10-24 14:21 UTC (permalink / raw)
To: linux-arm-kernel
There was some confusion in the CPSM (Command Path State Machine)
and DPSM (Data Path State Machine) regarding the naming of the
registers, clarify the meaning of this acronym so the naming is
understandable, and consistently use BIT() to define these fields.
Include new definitions for a few bits found in a patch from
Srinivas Kandagatla.
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/mmc/host/mmci.c | 2 +-
drivers/mmc/host/mmci.h | 69 +++++++++++++++++++++++++++----------------------
2 files changed, 39 insertions(+), 32 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index df990bb8c873..79b135752d3d 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -210,7 +210,7 @@ static struct variant_data variant_qcom = {
MCI_QCOM_CLK_SELECT_IN_FBCLK,
.clkreg_8bit_bus_enable = MCI_QCOM_CLK_WIDEBUS_8,
.datactrl_mask_ddrmode = MCI_QCOM_CLK_SELECT_IN_DDR_MODE,
- .data_cmd_enable = MCI_QCOM_CSPM_DATCMD,
+ .data_cmd_enable = MCI_CPSM_QCOM_DATCMD,
.blksz_datactrl4 = true,
.datalength_bits = 24,
.pwrreg_powerup = MCI_PWR_UP,
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index a1f5e4f49e2a..8952285196cd 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -51,25 +51,27 @@
#define MCI_QCOM_CLK_SELECT_IN_DDR_MODE (BIT(14) | BIT(15))
#define MMCIARGUMENT 0x008
-#define MMCICOMMAND 0x00c
-#define MCI_CPSM_RESPONSE (1 << 6)
-#define MCI_CPSM_LONGRSP (1 << 7)
-#define MCI_CPSM_INTERRUPT (1 << 8)
-#define MCI_CPSM_PENDING (1 << 9)
-#define MCI_CPSM_ENABLE (1 << 10)
-/* Argument flag extenstions in the ST Micro versions */
-#define MCI_ST_SDIO_SUSP (1 << 11)
-#define MCI_ST_ENCMD_COMPL (1 << 12)
-#define MCI_ST_NIEN (1 << 13)
-#define MCI_ST_CE_ATACMD (1 << 14)
-/* Modified on Qualcomm Integrations */
-#define MCI_QCOM_CSPM_DATCMD BIT(12)
-#define MCI_QCOM_CSPM_MCIABORT BIT(13)
-#define MCI_QCOM_CSPM_CCSENABLE BIT(14)
-#define MCI_QCOM_CSPM_CCSDISABLE BIT(15)
-#define MCI_QCOM_CSPM_AUTO_CMD19 BIT(16)
-#define MCI_QCOM_CSPM_AUTO_CMD21 BIT(21)
+/* The command register controls the Command Path State Machine (CPSM) */
+#define MMCICOMMAND 0x00c
+#define MCI_CPSM_RESPONSE BIT(6)
+#define MCI_CPSM_LONGRSP BIT(7)
+#define MCI_CPSM_INTERRUPT BIT(8)
+#define MCI_CPSM_PENDING BIT(9)
+#define MCI_CPSM_ENABLE BIT(10)
+/* Command register flag extenstions in the ST Micro versions */
+#define MCI_CPSM_ST_SDIO_SUSP BIT(11)
+#define MCI_CPSM_ST_ENCMD_COMPL BIT(12)
+#define MCI_CPSM_ST_NIEN BIT(13)
+#define MCI_CPSM_ST_CE_ATACMD BIT(14)
+/* Command register flag extensions in the Qualcomm versions */
+#define MCI_CPSM_QCOM_PROGENA BIT(11)
+#define MCI_CPSM_QCOM_DATCMD BIT(12)
+#define MCI_CPSM_QCOM_MCIABORT BIT(13)
+#define MCI_CPSM_QCOM_CCSENABLE BIT(14)
+#define MCI_CPSM_QCOM_CCSDISABLE BIT(15)
+#define MCI_CPSM_QCOM_AUTO_CMD19 BIT(16)
+#define MCI_CPSM_QCOM_AUTO_CMD21 BIT(21)
#define MMCIRESPCMD 0x010
#define MMCIRESPONSE0 0x014
@@ -78,22 +80,27 @@
#define MMCIRESPONSE3 0x020
#define MMCIDATATIMER 0x024
#define MMCIDATALENGTH 0x028
+
+/* The data control register controls the Data Path State Machine (DPSM) */
#define MMCIDATACTRL 0x02c
-#define MCI_DPSM_ENABLE (1 << 0)
-#define MCI_DPSM_DIRECTION (1 << 1)
-#define MCI_DPSM_MODE (1 << 2)
-#define MCI_DPSM_DMAENABLE (1 << 3)
-#define MCI_DPSM_BLOCKSIZE (1 << 4)
+#define MCI_DPSM_ENABLE BIT(0)
+#define MCI_DPSM_DIRECTION BIT(1)
+#define MCI_DPSM_MODE BIT(2)
+#define MCI_DPSM_DMAENABLE BIT(3)
+#define MCI_DPSM_BLOCKSIZE BIT(4)
/* Control register extensions in the ST Micro U300 and Ux500 versions */
-#define MCI_ST_DPSM_RWSTART (1 << 8)
-#define MCI_ST_DPSM_RWSTOP (1 << 9)
-#define MCI_ST_DPSM_RWMOD (1 << 10)
-#define MCI_ST_DPSM_SDIOEN (1 << 11)
+#define MCI_ST_DPSM_RWSTART BIT(8)
+#define MCI_ST_DPSM_RWSTOP BIT(9)
+#define MCI_ST_DPSM_RWMOD BIT(10)
+#define MCI_ST_DPSM_SDIOEN BIT(11)
/* Control register extensions in the ST Micro Ux500 versions */
-#define MCI_ST_DPSM_DMAREQCTL (1 << 12)
-#define MCI_ST_DPSM_DBOOTMODEEN (1 << 13)
-#define MCI_ST_DPSM_BUSYMODE (1 << 14)
-#define MCI_ST_DPSM_DDRMODE (1 << 15)
+#define MCI_ST_DPSM_DMAREQCTL BIT(12)
+#define MCI_ST_DPSM_DBOOTMODEEN BIT(13)
+#define MCI_ST_DPSM_BUSYMODE BIT(14)
+#define MCI_ST_DPSM_DDRMODE BIT(15)
+/* Control register extensions in the Qualcomm versions */
+#define MCI_QCOM_DPSM_DATA_PEND BIT(17)
+#define MCI_QCOM_DPSM_RX_DATA_PEND BIT(20)
#define MMCIDATACNT 0x030
#define MMCISTATUS 0x034
--
2.7.4
^ permalink raw reply related
* [GIT PULL] SoCFPGA DTS updates for v4.10, part 1
From: Dinh Nguyen @ 2016-10-24 14:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, Olof:
Please pull in these DTS updates for SoCFPGA for v4.10.
Thanks,
Dinh
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_dts_for_v4.10_part_1
for you to fetch changes up to c96f5919e6b0d132aa9afe9f1adc872fc107d5bb:
ARM: dts: socfpga: socrates: enable qspi (2016-10-18 22:18:14 -0500)
----------------------------------------------------------------
SoCFPGA DTS update for v4.10, part 1
- Add a Macnica sodia board
- Add support for the Arria10 System resource device
- Add support for the Arria10 LEDs
- Add QSPI to the socrates board
- Update L2 cache settings, enabling arm,shared-override
----------------------------------------------------------------
Dinh Nguyen (1):
ARM: dts: socfpga: enable arm,shared-override in the pl310
Marek Vasut (1):
ARM: dts: socfpga: Add new MCVEVK manufacturer compat
Nobuhiro Iwamatsu (1):
ARM: dts: socfpga: Add Macnica sodia board
Steffen Trumtrar (2):
ARM: dts: socfpga: add qspi node
ARM: dts: socfpga: socrates: enable qspi
Thor Thayer (4):
ARM: dts: socfpga: Add SPI Master1 for Arria10 SR chip
ARM: dts: socfpga: Add Devkit A10-SR fields for Arria10
ARM: dts: socfpga: Enable GPIO parent for Arria10 SR chip
ARM: dts: socfpga: Add LED framework to A10-SR GPIO
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/socfpga.dtsi | 15 +++
arch/arm/boot/dts/socfpga_arria10.dtsi | 18 ++++
arch/arm/boot/dts/socfpga_arria10_socdk.dtsi | 49 ++++++++++
arch/arm/boot/dts/socfpga_cyclone5_mcv.dtsi | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_socrates.dts | 19 ++++
arch/arm/boot/dts/socfpga_cyclone5_sodia.dts | 123 ++++++++++++++++++++++++
8 files changed, 227 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
^ permalink raw reply
* [GIT PULL] i.MX fixes for 4.9
From: Shawn Guo @ 2016-10-24 14:06 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-fixes-4.9
for you to fetch changes up to 4edd601c5a9c5094daa714e65063e623826f3bcc:
ARM: imx: mach-imx6q: Fix the PHY ID mask for AR8031 (2016-10-24 21:26:01 +0800)
----------------------------------------------------------------
The i.MX fixes for 4.9:
- A couple of patches from Fabio to fix the GPC power domain regression
which is caused by PM Domain core change 0159ec670763dd
("PM / Domains: Verify the PM domain is present when adding a
provider"), and a related kernel crash seen with multi_v7_defconfig
build.
- Correct the PHY ID mask for AR8031 to match phy driver code.
- Apply new added timer erratum A008585 for LS1043A and LS2080A SoC.
- Correct vf610 global timer IRQ flag to avoid warning from gic driver
after commit 992345a58e0c ("irqchip/gic: WARN if setting the
interrupt type for a PPI fails").
----------------------------------------------------------------
Fabio Estevam (3):
ARM: imx: gpc: Initialize all power domains
ARM: imx: gpc: Fix the imx_gpc_genpd_init() error path
ARM: imx: mach-imx6q: Fix the PHY ID mask for AR8031
Scott Wood (1):
arm64: dts: Add timer erratum property for LS2080A and LS1043A
Stefan Agner (1):
ARM: dts: vf610: fix IRQ flag of global timer
arch/arm/boot/dts/vf500.dtsi | 2 +-
arch/arm/mach-imx/gpc.c | 15 ++++++++++++---
arch/arm/mach-imx/mach-imx6q.c | 2 +-
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 1 +
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 1 +
5 files changed, 16 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH] ARM: dt: sun8i-h3: Add sunxi-sid to dts for sun8i-h3
From: Maxime Ripard @ 2016-10-24 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161023082631.GA28485@Red>
On Sun, Oct 23, 2016 at 10:26:31AM +0200, LABBE Corentin wrote:
> On Thu, Oct 20, 2016 at 10:36:54PM +0200, Maxime Ripard wrote:
> > On Wed, Oct 19, 2016 at 09:40:16AM +0200, LABBE Corentin wrote:
> > > On Wed, Oct 05, 2016 at 12:21:30PM +0200, Jean-Francois Moine wrote:
> > > > On Wed, 5 Oct 2016 11:48:24 +0200
> > > > Corentin Labbe <clabbe.montjoie@gmail.com> wrote:
> > > >
> > > > > This patch add support for the sunxi-sid driver to the device tree for sun8i-h3.
> > > > >
> > > > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > > > ---
> > > > > arch/arm/boot/dts/sun8i-h3.dtsi | 5 +++++
> > > > > 1 file changed, 5 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> > > > > index 9f58bb4..abfd29c 100644
> > > > > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > > > > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > > > > @@ -211,6 +211,11 @@
> > > > > #size-cells = <0>;
> > > > > };
> > > > >
> > > > > + sid: eeprom at 01c14200 {
> > > > > + compatible = "allwinner,sun7i-a20-sid";
> > > > > + reg = <0x01c14200 0x200>;
> > > >
> > > > The datasheet says 1Kb starting at 0x01c14000.
> > > > Is there any reason to reduce the area and to shift the offset?
> > > >
> > >
> > > According to http://linux-sunxi.org/SID_Register_Guide "For
> > > Allwinner A83T and H3 the SID address space starts at 0x01c14000,
> > > and the e-fuses are at offset 0x200".
> > >
> > > So I use this offset, since the sunxi_sid driver need the base
> > > address of e-fuses.
> > >
> > > The easiest solution is to use 0x01c14200 since the other part of
> > > sid is not used and not known (A83T/H3 user manual doesnt give any
> > > information on all sid space, worse for A64 which reference SID only
> > > in memory map).
> > >
> > > So probably for H3/A64/A83T, there will never any usage of the rest
> > > of the SID address space.
> >
> > And since we can't know that, and we have to maintain the DT ABI,
> > using the whole address map and an offset, with a new compatible, is
> > definetely the safest thing to do.
> >
>
> I have two way of doing it, which one do you prefer ?
>
> - Adding two optionnal properties: efuses-offset and efuses-size defaulting to 0 and resourcesize.
> - Adding a subnode called efuses with its own reg=<>
>
> The first one is easy and didnt need any work on previous DT entries.
I'd prefer to have a compatible, and the size and/or offset of the
efuses associated to it.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/d93d1bab/attachment-0001.sig>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox