* [PATCH 3/3] clk: at91: propagate rate change on system clks
From: Boris BREZILLON @ 2014-02-03 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391426731-9392-1-git-send-email-b.brezillon@overkiz.com>
System clks are just gates, and thus do not provide any rate operations.
Authorize clk rate change to be propagated to system clk parents.
Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
---
drivers/clk/at91/clk-system.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/at91/clk-system.c b/drivers/clk/at91/clk-system.c
index 8f7c043..a98557b 100644
--- a/drivers/clk/at91/clk-system.c
+++ b/drivers/clk/at91/clk-system.c
@@ -84,7 +84,8 @@ at91_clk_register_system(struct at91_pmc *pmc, const char *name,
* (see drivers/memory) which would request and enable the ddrck clock.
* When this is done we will be able to remove CLK_IGNORE_UNUSED flag.
*/
- init.flags = CLK_IGNORE_UNUSED;
+ init.flags = CLK_SET_RATE_GATE | CLK_SET_RATE_PARENT |
+ CLK_IGNORE_UNUSED;
sys->id = id;
sys->hw.init = &init;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/3] clk: at91: replace prog clk round_rate with determine_rate
From: Boris BREZILLON @ 2014-02-03 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391426731-9392-1-git-send-email-b.brezillon@overkiz.com>
Implement the determine_rate callback to choose the best parent clk that
fulfills the requested rate.
Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
---
drivers/clk/at91/clk-programmable.c | 56 +++++++++++++++++------------------
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
index 02f62a0..8e242c7 100644
--- a/drivers/clk/at91/clk-programmable.c
+++ b/drivers/clk/at91/clk-programmable.c
@@ -105,40 +105,40 @@ static unsigned long clk_programmable_recalc_rate(struct clk_hw *hw,
return parent_rate >> prog->pres;
}
-static long clk_programmable_round_rate(struct clk_hw *hw, unsigned long rate,
- unsigned long *parent_rate)
+static long clk_programmable_determine_rate(struct clk_hw *hw,
+ unsigned long rate,
+ unsigned long *best_parent_rate,
+ struct clk **best_parent_clk)
{
- unsigned long best_rate = *parent_rate;
- unsigned long best_diff;
- unsigned long new_diff;
- unsigned long cur_rate;
- int shift = shift;
-
- if (rate > *parent_rate)
- return *parent_rate;
- else
- best_diff = *parent_rate - rate;
-
- if (!best_diff)
- return best_rate;
+ struct clk *parent = NULL;
+ long best_rate = -EINVAL;
+ unsigned long parent_rate;
+ unsigned long tmp_rate;
+ int shift;
+ int i;
- for (shift = 1; shift < PROG_PRES_MASK; shift++) {
- cur_rate = *parent_rate >> shift;
+ for (i = 0; i < __clk_get_num_parents(hw->clk); i++) {
+ parent = clk_get_parent_by_index(hw->clk, i);
+ if (!parent)
+ continue;
- if (cur_rate > rate)
- new_diff = cur_rate - rate;
- else
- new_diff = rate - cur_rate;
+ parent_rate = __clk_get_rate(parent);
+ for (shift = 0; shift < PROG_PRES_MASK; shift++) {
+ tmp_rate = parent_rate >> shift;
+ if (tmp_rate <= rate)
+ break;
+ }
- if (!new_diff)
- return cur_rate;
+ if (tmp_rate > rate)
+ continue;
- if (new_diff < best_diff) {
- best_diff = new_diff;
- best_rate = cur_rate;
+ if (best_rate < 0 || (rate - tmp_rate) < (rate - best_rate)) {
+ best_rate = tmp_rate;
+ *best_parent_rate = parent_rate;
+ *best_parent_clk = parent;
}
- if (rate > cur_rate)
+ if (!best_rate)
break;
}
@@ -231,7 +231,7 @@ static const struct clk_ops programmable_ops = {
.prepare = clk_programmable_prepare,
.is_prepared = clk_programmable_is_ready,
.recalc_rate = clk_programmable_recalc_rate,
- .round_rate = clk_programmable_round_rate,
+ .determine_rate = clk_programmable_determine_rate,
.get_parent = clk_programmable_get_parent,
.set_parent = clk_programmable_set_parent,
.set_rate = clk_programmable_set_rate,
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/3] clk: at91: fix programmable clk irq handling
From: Boris BREZILLON @ 2014-02-03 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391426731-9392-1-git-send-email-b.brezillon@overkiz.com>
The prog irq is a level irq reflecting the prog clk status. As a result the
irq line will stay high when the prog clk is ready and the system will
hang.
Disable the irq when it is handled to avoid this problem.
Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
---
drivers/clk/at91/clk-programmable.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
index fd792b2..02f62a0 100644
--- a/drivers/clk/at91/clk-programmable.c
+++ b/drivers/clk/at91/clk-programmable.c
@@ -55,6 +55,7 @@ static irqreturn_t clk_programmable_irq_handler(int irq, void *dev_id)
struct clk_programmable *prog = (struct clk_programmable *)dev_id;
wake_up(&prog->wait);
+ disable_irq_nosync(prog->irq);
return IRQ_HANDLED;
}
@@ -74,8 +75,10 @@ static int clk_programmable_prepare(struct clk_hw *hw)
pmc_write(pmc, AT91_PMC_PCKR(id), tmp);
- while (!(pmc_read(pmc, AT91_PMC_SR) & mask))
+ while (!(pmc_read(pmc, AT91_PMC_SR) & mask)) {
+ enable_irq(prog->irq);
wait_event(prog->wait, pmc_read(pmc, AT91_PMC_SR) & mask);
+ }
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/3] clk: at91: various fixes and improvements
From: Boris BREZILLON @ 2014-02-03 11:25 UTC (permalink / raw)
To: linux-arm-kernel
Hello Mike,
This series fixes a bug in the prog clk prepare function (the platform hangs
when preparing a prog clk).
It also implements the determine_rate callback for these prog clks and allow
system clk to propagate the rate change to its parent.
These modifications are needed to get the atmel_wm8904 driver working (this
driver make use of prog clks), and if possible, should be merged in the next
3.14 release (at least the first patch of this series).
Let me know if this is not possible.
Thanks.
Best Regards,
Boris
Boris BREZILLON (3):
clk: at91: fix programmable clk irq handling
clk: at91: replace prog clk round_rate with determine_rate
clk: at91: propagate rate change on system clks
drivers/clk/at91/clk-programmable.c | 61 ++++++++++++++++++-----------------
drivers/clk/at91/clk-system.c | 3 +-
2 files changed, 34 insertions(+), 30 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH v2 2/3] ARM/ARM64: KVM: Add support for PSCI v0.2 emulation
From: Anup Patel @ 2014-02-03 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMwBHsbQ_5tGNuHC=OBs7+CxZ4xJ-s6HHEX04ZKo4FtofpgGgA@mail.gmail.com>
On Mon, Feb 3, 2014 at 4:46 PM, Anup Patel <apatel@apm.com> wrote:
> Hi Mark,
>
> On Mon, Feb 3, 2014 at 4:24 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>> On Thu, Jan 30, 2014 at 10:41:18AM +0000, Anup Patel wrote:
>>> Currently, the in-kernel PSCI emulation provides PSCI v0.1 interface to
>>> VCPUs. This patch extends current in-kernel PSCI emulation to provide
>>> PSCI v0.2 interface to VCPUs.
>>>
>>> By default, ARM/ARM64 KVM will always provide PSCI v0.1 interface for
>>> keeping the ABI backward-compatible.
>>>
>>> To select PSCI v0.2 interface for VCPUs, the user space (i.e. QEMU or
>>> KVMTOOL) will have to set KVM_ARM_VCPU_PSCI_0_2 feature when doing VCPU
>>> init using KVM_ARM_VCPU_INIT ioctl.
>>
>> I have an issue with this. PSCI 0.2 makes all but two functions (MIGRATE
>> and MIGRATE_INFO_CPU_UP) mandatory, and hence not allowed to return
>> NOT_SUPPORTED.
>>
>> Additionally, for correct behaviour across a kexec in future, we'll
>> require AFFINITY_INFO for PSCI 0.2+ systems to determint when a CPU is
>> actually dead (and cannot affect the cache hierarchy). I'd very much
>> like to make that a hard requirement to ensure correctness.
>>
>> I would very much like to see at least trivial implementations of those
>> mandatory functions, so that we don't need a
>> KVM_ARM_VCPU_PSCI_REALLY_0_2 or similar in future. As it stands this
>> series does not implement PSCI 0.2.
>
> The intention behind this series was to provide a base implementation of
> PSCI v0.2 which can be extended by subsequent patches that implement
> other PSCI v0.2 functions.
>
> I already have a patch series that implement PSCI v0.2 SYSTEM_OFF and
> SYSTEM_RESET based on this series.
>
> Regards,
> Anup
>
>>
>> Thanks,
>> Mark.
>>
>>>
>>> Signed-off-by: Anup Patel <anup.patel@linaro.org>
>>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
>>> ---
>>> arch/arm/include/asm/kvm_host.h | 2 +-
>>> arch/arm/include/asm/kvm_psci.h | 4 ++
>>> arch/arm/include/uapi/asm/kvm.h | 35 ++++++++++++++-
>>> arch/arm/kvm/arm.c | 1 +
>>> arch/arm/kvm/psci.c | 85 +++++++++++++++++++++++++++++++------
>>> arch/arm64/include/asm/kvm_host.h | 2 +-
>>> arch/arm64/include/asm/kvm_psci.h | 4 ++
>>> arch/arm64/include/uapi/asm/kvm.h | 35 ++++++++++++++-
>>> 8 files changed, 152 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
>>> index bce6d32..dc4e3ed 100644
>>> --- a/arch/arm/include/asm/kvm_host.h
>>> +++ b/arch/arm/include/asm/kvm_host.h
>>> @@ -36,7 +36,7 @@
>>> #define KVM_COALESCED_MMIO_PAGE_OFFSET 1
>>> #define KVM_HAVE_ONE_REG
>>>
>>> -#define KVM_VCPU_MAX_FEATURES 1
>>> +#define KVM_VCPU_MAX_FEATURES 2
>>>
>>> #include <kvm/arm_vgic.h>
>>>
>>> diff --git a/arch/arm/include/asm/kvm_psci.h b/arch/arm/include/asm/kvm_psci.h
>>> index 9a83d98..4c0e3e1 100644
>>> --- a/arch/arm/include/asm/kvm_psci.h
>>> +++ b/arch/arm/include/asm/kvm_psci.h
>>> @@ -18,6 +18,10 @@
>>> #ifndef __ARM_KVM_PSCI_H__
>>> #define __ARM_KVM_PSCI_H__
>>>
>>> +#define KVM_ARM_PSCI_0_1 1
>>> +#define KVM_ARM_PSCI_0_2 2
>>> +
>>> +int kvm_psci_version(struct kvm_vcpu *vcpu);
>>> bool kvm_psci_call(struct kvm_vcpu *vcpu);
>>>
>>> #endif /* __ARM_KVM_PSCI_H__ */
>>> diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
>>> index c498b60..bf860e2 100644
>>> --- a/arch/arm/include/uapi/asm/kvm.h
>>> +++ b/arch/arm/include/uapi/asm/kvm.h
>>> @@ -83,6 +83,7 @@ struct kvm_regs {
>>> #define KVM_VGIC_V2_CPU_SIZE 0x2000
>>>
>>> #define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */
>>> +#define KVM_ARM_VCPU_PSCI_0_2 1 /* CPU uses PSCI v0.2 */
>>>
>>> struct kvm_vcpu_init {
>>> __u32 target;
>>> @@ -164,7 +165,7 @@ struct kvm_arch_memory_slot {
>>> /* Highest supported SPI, from VGIC_NR_IRQS */
>>> #define KVM_ARM_IRQ_GIC_MAX 127
>>>
>>> -/* PSCI interface */
>>> +/* PSCI v0.1 interface */
>>> #define KVM_PSCI_FN_BASE 0x95c1ba5e
>>> #define KVM_PSCI_FN(n) (KVM_PSCI_FN_BASE + (n))
>>>
>>> @@ -173,9 +174,41 @@ struct kvm_arch_memory_slot {
>>> #define KVM_PSCI_FN_CPU_ON KVM_PSCI_FN(2)
>>> #define KVM_PSCI_FN_MIGRATE KVM_PSCI_FN(3)
>>>
>>> +/* PSCI v0.2 interface */
>>> +#define KVM_PSCI_0_2_FN_BASE 0x84000000
>>> +#define KVM_PSCI_0_2_FN(n) (KVM_PSCI_0_2_FN_BASE + (n))
>>> +#define KVM_PSCI_0_2_FN64_BASE 0xC4000000
>>> +#define KVM_PSCI_0_2_FN64(n) (KVM_PSCI_0_2_FN64_BASE + (n))
>>> +
>>> +#define KVM_PSCI_0_2_FN_PSCI_VERSION KVM_PSCI_0_2_FN(0)
>>> +#define KVM_PSCI_0_2_FN_CPU_SUSPEND KVM_PSCI_0_2_FN(1)
>>> +#define KVM_PSCI_0_2_FN_CPU_OFF KVM_PSCI_0_2_FN(2)
>>> +#define KVM_PSCI_0_2_FN_CPU_ON KVM_PSCI_0_2_FN(3)
>>> +#define KVM_PSCI_0_2_FN_AFFINITY_INFO KVM_PSCI_0_2_FN(4)
>>> +#define KVM_PSCI_0_2_FN_MIGRATE KVM_PSCI_0_2_FN(5)
>>> +#define KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE \
>>> + KVM_PSCI_0_2_FN(6)
>>> +#define KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU \
>>> + KVM_PSCI_0_2_FN(7)
>>> +#define KVM_PSCI_0_2_FN_SYSTEM_OFF KVM_PSCI_0_2_FN(8)
>>> +#define KVM_PSCI_0_2_FN_SYSTEM_RESET KVM_PSCI_0_2_FN(9)
>>> +
>>> +#define KVM_PSCI_0_2_FN64_CPU_SUSPEND KVM_PSCI_0_2_FN64(1)
>>> +#define KVM_PSCI_0_2_FN64_CPU_ON KVM_PSCI_0_2_FN64(3)
>>> +#define KVM_PSCI_0_2_FN64_AFFINITY_INFO KVM_PSCI_0_2_FN64(4)
>>> +#define KVM_PSCI_0_2_FN64_MIGRATE KVM_PSCI_0_2_FN64(5)
>>> +#define KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU \
>>> + KVM_PSCI_0_2_FN64(7)
>>> +
>>> +/* PSCI return values */
>>> #define KVM_PSCI_RET_SUCCESS 0
>>> #define KVM_PSCI_RET_NI ((unsigned long)-1)
>>> #define KVM_PSCI_RET_INVAL ((unsigned long)-2)
>>> #define KVM_PSCI_RET_DENIED ((unsigned long)-3)
>>> +#define KVM_PSCI_RET_ALREADY_ON ((unsigned long)-4)
>>> +#define KVM_PSCI_RET_ON_PENDING ((unsigned long)-5)
>>> +#define KVM_PSCI_RET_INTERNAL_FAILURE ((unsigned long)-6)
>>> +#define KVM_PSCI_RET_NOT_PRESENT ((unsigned long)-7)
>>> +#define KVM_PSCI_RET_DISABLED ((unsigned long)-8)
>>>
>>> #endif /* __ARM_KVM_H__ */
>>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>>> index 151eb91..e508125 100644
>>> --- a/arch/arm/kvm/arm.c
>>> +++ b/arch/arm/kvm/arm.c
>>> @@ -193,6 +193,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>>> case KVM_CAP_DESTROY_MEMORY_REGION_WORKS:
>>> case KVM_CAP_ONE_REG:
>>> case KVM_CAP_ARM_PSCI:
>>> + case KVM_CAP_ARM_PSCI_0_2:
>>> r = 1;
>>> break;
>>> case KVM_CAP_COALESCED_MMIO:
>>> diff --git a/arch/arm/kvm/psci.c b/arch/arm/kvm/psci.c
>>> index 448f60e..7fdc881 100644
>>> --- a/arch/arm/kvm/psci.c
>>> +++ b/arch/arm/kvm/psci.c
>>> @@ -85,17 +85,57 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
>>> return KVM_PSCI_RET_SUCCESS;
>>> }
>>>
>>> -/**
>>> - * kvm_psci_call - handle PSCI call if r0 value is in range
>>> - * @vcpu: Pointer to the VCPU struct
>>> - *
>>> - * Handle PSCI calls from guests through traps from HVC instructions.
>>> - * The calling convention is similar to SMC calls to the secure world where
>>> - * the function number is placed in r0 and this function returns true if the
>>> - * function number specified in r0 is withing the PSCI range, and false
>>> - * otherwise.
>>> - */
>>> -bool kvm_psci_call(struct kvm_vcpu *vcpu)
>>> +int kvm_psci_version(struct kvm_vcpu *vcpu)
>>> +{
>>> + if (test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features))
>>> + return KVM_ARM_PSCI_0_2;
>>> +
>>> + return KVM_ARM_PSCI_0_1;
>>> +}
>>> +
>>> +static bool kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
>>> +{
>>> + unsigned long psci_fn = *vcpu_reg(vcpu, 0) & ~((u32) 0);
>>> + unsigned long val;
>>> +
>>> + switch (psci_fn) {
>>> + case KVM_PSCI_0_2_FN_PSCI_VERSION:
>>> + /*
>>> + * Bits[31:16] = Major Version = 0
>>> + * Bits[15:0] = Minor Version = 2
>>> + */
>>> + val = 2;
>>> + break;
>>> + case KVM_PSCI_0_2_FN_CPU_OFF:
>>> + kvm_psci_vcpu_off(vcpu);
>>> + val = KVM_PSCI_RET_SUCCESS;
>>> + break;
>>> + case KVM_PSCI_0_2_FN_CPU_ON:
>>> + case KVM_PSCI_0_2_FN64_CPU_ON:
>>> + val = kvm_psci_vcpu_on(vcpu);
>>> + break;
>>> + case KVM_PSCI_0_2_FN_CPU_SUSPEND:
>>> + case KVM_PSCI_0_2_FN_AFFINITY_INFO:
>>> + case KVM_PSCI_0_2_FN_MIGRATE:
>>> + case KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE:
>>> + case KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU:
>>> + case KVM_PSCI_0_2_FN_SYSTEM_OFF:
>>> + case KVM_PSCI_0_2_FN_SYSTEM_RESET:
>>> + case KVM_PSCI_0_2_FN64_CPU_SUSPEND:
>>> + case KVM_PSCI_0_2_FN64_AFFINITY_INFO:
>>> + case KVM_PSCI_0_2_FN64_MIGRATE:
>>> + case KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
>>> + val = KVM_PSCI_RET_NI;
>>> + break;
>>> + default:
>>> + return false;
>>> + }
>>> +
>>> + *vcpu_reg(vcpu, 0) = val;
>>> + return true;
>>> +}
>>> +
>>> +static bool kvm_psci_0_1_call(struct kvm_vcpu *vcpu)
>>> {
>>> unsigned long psci_fn = *vcpu_reg(vcpu, 0) & ~((u32) 0);
>>> unsigned long val;
>>> @@ -112,7 +152,6 @@ bool kvm_psci_call(struct kvm_vcpu *vcpu)
>>> case KVM_PSCI_FN_MIGRATE:
>>> val = KVM_PSCI_RET_NI;
>>> break;
>>> -
>>> default:
>>> return false;
>>> }
>>> @@ -120,3 +159,25 @@ bool kvm_psci_call(struct kvm_vcpu *vcpu)
>>> *vcpu_reg(vcpu, 0) = val;
>>> return true;
>>> }
>>> +
>>> +/**
>>> + * kvm_psci_call - handle PSCI call if r0 value is in range
>>> + * @vcpu: Pointer to the VCPU struct
>>> + *
>>> + * Handle PSCI calls from guests through traps from HVC instructions.
>>> + * The calling convention is similar to SMC calls to the secure world where
>>> + * the function number is placed in r0 and this function returns true if the
>>> + * function number specified in r0 is withing the PSCI range, and false
>>> + * otherwise.
>>> + */
>>> +bool kvm_psci_call(struct kvm_vcpu *vcpu)
>>> +{
>>> + switch (kvm_psci_version(vcpu)) {
>>> + case KVM_ARM_PSCI_0_2:
>>> + return kvm_psci_0_2_call(vcpu);
>>> + case KVM_ARM_PSCI_0_1:
>>> + return kvm_psci_0_1_call(vcpu);
>>> + default:
>>> + return false;
>>> + };
>>> +}
>>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>>> index 0a1d697..92242ce 100644
>>> --- a/arch/arm64/include/asm/kvm_host.h
>>> +++ b/arch/arm64/include/asm/kvm_host.h
>>> @@ -39,7 +39,7 @@
>>> #include <kvm/arm_vgic.h>
>>> #include <kvm/arm_arch_timer.h>
>>>
>>> -#define KVM_VCPU_MAX_FEATURES 2
>>> +#define KVM_VCPU_MAX_FEATURES 3
>>>
>>> struct kvm_vcpu;
>>> int kvm_target_cpu(void);
>>> diff --git a/arch/arm64/include/asm/kvm_psci.h b/arch/arm64/include/asm/kvm_psci.h
>>> index e301a48..e25c658 100644
>>> --- a/arch/arm64/include/asm/kvm_psci.h
>>> +++ b/arch/arm64/include/asm/kvm_psci.h
>>> @@ -18,6 +18,10 @@
>>> #ifndef __ARM64_KVM_PSCI_H__
>>> #define __ARM64_KVM_PSCI_H__
>>>
>>> +#define KVM_ARM_PSCI_0_1 1
>>> +#define KVM_ARM_PSCI_0_2 2
>>> +
>>> +int kvm_psci_version(struct kvm_vcpu *vcpu);
>>> bool kvm_psci_call(struct kvm_vcpu *vcpu);
>>>
>>> #endif /* __ARM64_KVM_PSCI_H__ */
>>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>>> index d9f026b..b7555d3 100644
>>> --- a/arch/arm64/include/uapi/asm/kvm.h
>>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>>> @@ -77,6 +77,7 @@ struct kvm_regs {
>>>
>>> #define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */
>>> #define KVM_ARM_VCPU_EL1_32BIT 1 /* CPU running a 32bit VM */
>>> +#define KVM_ARM_VCPU_PSCI_0_2 2 /* CPU uses PSCI v0.2 */
>>>
>>> struct kvm_vcpu_init {
>>> __u32 target;
>>> @@ -150,7 +151,7 @@ struct kvm_arch_memory_slot {
>>> /* Highest supported SPI, from VGIC_NR_IRQS */
>>> #define KVM_ARM_IRQ_GIC_MAX 127
>>>
>>> -/* PSCI interface */
>>> +/* PSCI v0.1 interface */
>>> #define KVM_PSCI_FN_BASE 0x95c1ba5e
>>> #define KVM_PSCI_FN(n) (KVM_PSCI_FN_BASE + (n))
>>>
>>> @@ -159,10 +160,42 @@ struct kvm_arch_memory_slot {
>>> #define KVM_PSCI_FN_CPU_ON KVM_PSCI_FN(2)
>>> #define KVM_PSCI_FN_MIGRATE KVM_PSCI_FN(3)
>>>
>>> +/* PSCI v0.2 interface */
>>> +#define KVM_PSCI_0_2_FN_BASE 0x84000000
>>> +#define KVM_PSCI_0_2_FN(n) (KVM_PSCI_0_2_FN_BASE + (n))
>>> +#define KVM_PSCI_0_2_FN64_BASE 0xC4000000
>>> +#define KVM_PSCI_0_2_FN64(n) (KVM_PSCI_0_2_FN64_BASE + (n))
>>> +
>>> +#define KVM_PSCI_0_2_FN_PSCI_VERSION KVM_PSCI_0_2_FN(0)
>>> +#define KVM_PSCI_0_2_FN_CPU_SUSPEND KVM_PSCI_0_2_FN(1)
>>> +#define KVM_PSCI_0_2_FN_CPU_OFF KVM_PSCI_0_2_FN(2)
>>> +#define KVM_PSCI_0_2_FN_CPU_ON KVM_PSCI_0_2_FN(3)
>>> +#define KVM_PSCI_0_2_FN_AFFINITY_INFO KVM_PSCI_0_2_FN(4)
>>> +#define KVM_PSCI_0_2_FN_MIGRATE KVM_PSCI_0_2_FN(5)
>>> +#define KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE \
>>> + KVM_PSCI_0_2_FN(6)
>>> +#define KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU \
>>> + KVM_PSCI_0_2_FN(7)
>>> +#define KVM_PSCI_0_2_FN_SYSTEM_OFF KVM_PSCI_0_2_FN(8)
>>> +#define KVM_PSCI_0_2_FN_SYSTEM_RESET KVM_PSCI_0_2_FN(9)
>>> +
>>> +#define KVM_PSCI_0_2_FN64_CPU_SUSPEND KVM_PSCI_0_2_FN64(1)
>>> +#define KVM_PSCI_0_2_FN64_CPU_ON KVM_PSCI_0_2_FN64(3)
>>> +#define KVM_PSCI_0_2_FN64_AFFINITY_INFO KVM_PSCI_0_2_FN64(4)
>>> +#define KVM_PSCI_0_2_FN64_MIGRATE KVM_PSCI_0_2_FN64(5)
>>> +#define KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU \
>>> + KVM_PSCI_0_2_FN64(7)
>>> +
>>> +/* PSCI return values */
>>> #define KVM_PSCI_RET_SUCCESS 0
>>> #define KVM_PSCI_RET_NI ((unsigned long)-1)
>>> #define KVM_PSCI_RET_INVAL ((unsigned long)-2)
>>> #define KVM_PSCI_RET_DENIED ((unsigned long)-3)
>>> +#define KVM_PSCI_RET_ALREADY_ON ((unsigned long)-4)
>>> +#define KVM_PSCI_RET_ON_PENDING ((unsigned long)-5)
>>> +#define KVM_PSCI_RET_INTERNAL_FAILURE ((unsigned long)-6)
>>> +#define KVM_PSCI_RET_NOT_PRESENT ((unsigned long)-7)
>>> +#define KVM_PSCI_RET_DISABLED ((unsigned long)-8)
>>>
>>> #endif
>>>
>>> --
>>> 1.7.9.5
>>>
>>>
>> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
>> is for the sole use of the intended recipient(s) and contains information
>> that is confidential and proprietary to Applied Micro Circuits Corporation or its subsidiaries.
>> It is to be used solely for the purpose of furthering the parties' business relationship.
>> All unauthorized review, use, disclosure or distribution is prohibited.
>> If you are not the intended recipient, please contact the sender by reply e-mail
>> and destroy all copies of the original message.
>>
I accidentally used wrong email-id for my last reply.
Please ignore this confidentiality notice.
Sorry for the noise.
Regards,
Anup
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
^ permalink raw reply
* [PATCH V2] arm64: add DSB after icache flush in __flush_icache_all()
From: Will Deacon @ 2014-02-03 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131104850.GG15937@n2100.arm.linux.org.uk>
Hi Nico, Russell,
Thanks for the replies.
On Fri, Jan 31, 2014 at 10:48:50AM +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 31, 2014 at 12:16:48AM +0000, Will Deacon wrote:
> > On Thu, Jan 30, 2014 at 09:42:29PM +0000, Nicolas Pitre wrote:
> > > I don't think they would be reordered at all with the
> > > volatile qualifiers.
> >
> > Whilst that may be the case in current compilers (i.e. I've not actually
> > seen the above sequence get re-ordered), the GCC documentation states that:
> >
> > Similarly, you can't expect a sequence of volatile asm instructions to remain
> > perfectly consecutive. If you want consecutive output, use a single asm. Also,
> > GCC performs some optimizations across a volatile asm instruction; GCC does not
> > `forget everything' when it encounters a volatile asm instruction the way some
> > other compilers do.
> >
> > so I really think that the "memory" clobbers are needed to ensure strict
> > ordering. This matches my understanding from discussions with the compiler
> > engineers at ARM.
>
> What it means is that the compiler may introduce additional instructions
> between your consecutive asm() statements. So there's no guarantee that
> the ISB will immediately follow the MSR instruction - there may be other
> instructions which the compiler may decide to schedule between the two.
>
> For example, instructions to load the address of the variable(s) may be
> inserted between the assembly specified in the asm() statements which
> may involve loading from a literal pool.
That matches what Nicolas said and, to be honest, makes a lot of sense. I'm
just slightly concerned that it doesn't match the explanation I received
from some compiler guys, but I can chase that down separately.
Vinayak: sorry for leading you down the garden path on this. Please can you
stick with your original patch, but adding something equivalent for
arch/arm?
Cheers,
Will
^ permalink raw reply
* [PATCH v2 2/3] ARM/ARM64: KVM: Add support for PSCI v0.2 emulation
From: Anup Patel @ 2014-02-03 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203105409.GF30209@e106331-lin.cambridge.arm.com>
Hi Mark,
On Mon, Feb 3, 2014 at 4:24 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Thu, Jan 30, 2014 at 10:41:18AM +0000, Anup Patel wrote:
>> Currently, the in-kernel PSCI emulation provides PSCI v0.1 interface to
>> VCPUs. This patch extends current in-kernel PSCI emulation to provide
>> PSCI v0.2 interface to VCPUs.
>>
>> By default, ARM/ARM64 KVM will always provide PSCI v0.1 interface for
>> keeping the ABI backward-compatible.
>>
>> To select PSCI v0.2 interface for VCPUs, the user space (i.e. QEMU or
>> KVMTOOL) will have to set KVM_ARM_VCPU_PSCI_0_2 feature when doing VCPU
>> init using KVM_ARM_VCPU_INIT ioctl.
>
> I have an issue with this. PSCI 0.2 makes all but two functions (MIGRATE
> and MIGRATE_INFO_CPU_UP) mandatory, and hence not allowed to return
> NOT_SUPPORTED.
>
> Additionally, for correct behaviour across a kexec in future, we'll
> require AFFINITY_INFO for PSCI 0.2+ systems to determint when a CPU is
> actually dead (and cannot affect the cache hierarchy). I'd very much
> like to make that a hard requirement to ensure correctness.
>
> I would very much like to see at least trivial implementations of those
> mandatory functions, so that we don't need a
> KVM_ARM_VCPU_PSCI_REALLY_0_2 or similar in future. As it stands this
> series does not implement PSCI 0.2.
The intention behind this series was to provide a base implementation of
PSCI v0.2 which can be extended by subsequent patches that implement
other PSCI v0.2 functions.
I already have a patch series that implement PSCI v0.2 SYSTEM_OFF and
SYSTEM_RESET based on this series.
Regards,
Anup
>
> Thanks,
> Mark.
>
>>
>> Signed-off-by: Anup Patel <anup.patel@linaro.org>
>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
>> ---
>> arch/arm/include/asm/kvm_host.h | 2 +-
>> arch/arm/include/asm/kvm_psci.h | 4 ++
>> arch/arm/include/uapi/asm/kvm.h | 35 ++++++++++++++-
>> arch/arm/kvm/arm.c | 1 +
>> arch/arm/kvm/psci.c | 85 +++++++++++++++++++++++++++++++------
>> arch/arm64/include/asm/kvm_host.h | 2 +-
>> arch/arm64/include/asm/kvm_psci.h | 4 ++
>> arch/arm64/include/uapi/asm/kvm.h | 35 ++++++++++++++-
>> 8 files changed, 152 insertions(+), 16 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
>> index bce6d32..dc4e3ed 100644
>> --- a/arch/arm/include/asm/kvm_host.h
>> +++ b/arch/arm/include/asm/kvm_host.h
>> @@ -36,7 +36,7 @@
>> #define KVM_COALESCED_MMIO_PAGE_OFFSET 1
>> #define KVM_HAVE_ONE_REG
>>
>> -#define KVM_VCPU_MAX_FEATURES 1
>> +#define KVM_VCPU_MAX_FEATURES 2
>>
>> #include <kvm/arm_vgic.h>
>>
>> diff --git a/arch/arm/include/asm/kvm_psci.h b/arch/arm/include/asm/kvm_psci.h
>> index 9a83d98..4c0e3e1 100644
>> --- a/arch/arm/include/asm/kvm_psci.h
>> +++ b/arch/arm/include/asm/kvm_psci.h
>> @@ -18,6 +18,10 @@
>> #ifndef __ARM_KVM_PSCI_H__
>> #define __ARM_KVM_PSCI_H__
>>
>> +#define KVM_ARM_PSCI_0_1 1
>> +#define KVM_ARM_PSCI_0_2 2
>> +
>> +int kvm_psci_version(struct kvm_vcpu *vcpu);
>> bool kvm_psci_call(struct kvm_vcpu *vcpu);
>>
>> #endif /* __ARM_KVM_PSCI_H__ */
>> diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
>> index c498b60..bf860e2 100644
>> --- a/arch/arm/include/uapi/asm/kvm.h
>> +++ b/arch/arm/include/uapi/asm/kvm.h
>> @@ -83,6 +83,7 @@ struct kvm_regs {
>> #define KVM_VGIC_V2_CPU_SIZE 0x2000
>>
>> #define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */
>> +#define KVM_ARM_VCPU_PSCI_0_2 1 /* CPU uses PSCI v0.2 */
>>
>> struct kvm_vcpu_init {
>> __u32 target;
>> @@ -164,7 +165,7 @@ struct kvm_arch_memory_slot {
>> /* Highest supported SPI, from VGIC_NR_IRQS */
>> #define KVM_ARM_IRQ_GIC_MAX 127
>>
>> -/* PSCI interface */
>> +/* PSCI v0.1 interface */
>> #define KVM_PSCI_FN_BASE 0x95c1ba5e
>> #define KVM_PSCI_FN(n) (KVM_PSCI_FN_BASE + (n))
>>
>> @@ -173,9 +174,41 @@ struct kvm_arch_memory_slot {
>> #define KVM_PSCI_FN_CPU_ON KVM_PSCI_FN(2)
>> #define KVM_PSCI_FN_MIGRATE KVM_PSCI_FN(3)
>>
>> +/* PSCI v0.2 interface */
>> +#define KVM_PSCI_0_2_FN_BASE 0x84000000
>> +#define KVM_PSCI_0_2_FN(n) (KVM_PSCI_0_2_FN_BASE + (n))
>> +#define KVM_PSCI_0_2_FN64_BASE 0xC4000000
>> +#define KVM_PSCI_0_2_FN64(n) (KVM_PSCI_0_2_FN64_BASE + (n))
>> +
>> +#define KVM_PSCI_0_2_FN_PSCI_VERSION KVM_PSCI_0_2_FN(0)
>> +#define KVM_PSCI_0_2_FN_CPU_SUSPEND KVM_PSCI_0_2_FN(1)
>> +#define KVM_PSCI_0_2_FN_CPU_OFF KVM_PSCI_0_2_FN(2)
>> +#define KVM_PSCI_0_2_FN_CPU_ON KVM_PSCI_0_2_FN(3)
>> +#define KVM_PSCI_0_2_FN_AFFINITY_INFO KVM_PSCI_0_2_FN(4)
>> +#define KVM_PSCI_0_2_FN_MIGRATE KVM_PSCI_0_2_FN(5)
>> +#define KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE \
>> + KVM_PSCI_0_2_FN(6)
>> +#define KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU \
>> + KVM_PSCI_0_2_FN(7)
>> +#define KVM_PSCI_0_2_FN_SYSTEM_OFF KVM_PSCI_0_2_FN(8)
>> +#define KVM_PSCI_0_2_FN_SYSTEM_RESET KVM_PSCI_0_2_FN(9)
>> +
>> +#define KVM_PSCI_0_2_FN64_CPU_SUSPEND KVM_PSCI_0_2_FN64(1)
>> +#define KVM_PSCI_0_2_FN64_CPU_ON KVM_PSCI_0_2_FN64(3)
>> +#define KVM_PSCI_0_2_FN64_AFFINITY_INFO KVM_PSCI_0_2_FN64(4)
>> +#define KVM_PSCI_0_2_FN64_MIGRATE KVM_PSCI_0_2_FN64(5)
>> +#define KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU \
>> + KVM_PSCI_0_2_FN64(7)
>> +
>> +/* PSCI return values */
>> #define KVM_PSCI_RET_SUCCESS 0
>> #define KVM_PSCI_RET_NI ((unsigned long)-1)
>> #define KVM_PSCI_RET_INVAL ((unsigned long)-2)
>> #define KVM_PSCI_RET_DENIED ((unsigned long)-3)
>> +#define KVM_PSCI_RET_ALREADY_ON ((unsigned long)-4)
>> +#define KVM_PSCI_RET_ON_PENDING ((unsigned long)-5)
>> +#define KVM_PSCI_RET_INTERNAL_FAILURE ((unsigned long)-6)
>> +#define KVM_PSCI_RET_NOT_PRESENT ((unsigned long)-7)
>> +#define KVM_PSCI_RET_DISABLED ((unsigned long)-8)
>>
>> #endif /* __ARM_KVM_H__ */
>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>> index 151eb91..e508125 100644
>> --- a/arch/arm/kvm/arm.c
>> +++ b/arch/arm/kvm/arm.c
>> @@ -193,6 +193,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>> case KVM_CAP_DESTROY_MEMORY_REGION_WORKS:
>> case KVM_CAP_ONE_REG:
>> case KVM_CAP_ARM_PSCI:
>> + case KVM_CAP_ARM_PSCI_0_2:
>> r = 1;
>> break;
>> case KVM_CAP_COALESCED_MMIO:
>> diff --git a/arch/arm/kvm/psci.c b/arch/arm/kvm/psci.c
>> index 448f60e..7fdc881 100644
>> --- a/arch/arm/kvm/psci.c
>> +++ b/arch/arm/kvm/psci.c
>> @@ -85,17 +85,57 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
>> return KVM_PSCI_RET_SUCCESS;
>> }
>>
>> -/**
>> - * kvm_psci_call - handle PSCI call if r0 value is in range
>> - * @vcpu: Pointer to the VCPU struct
>> - *
>> - * Handle PSCI calls from guests through traps from HVC instructions.
>> - * The calling convention is similar to SMC calls to the secure world where
>> - * the function number is placed in r0 and this function returns true if the
>> - * function number specified in r0 is withing the PSCI range, and false
>> - * otherwise.
>> - */
>> -bool kvm_psci_call(struct kvm_vcpu *vcpu)
>> +int kvm_psci_version(struct kvm_vcpu *vcpu)
>> +{
>> + if (test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features))
>> + return KVM_ARM_PSCI_0_2;
>> +
>> + return KVM_ARM_PSCI_0_1;
>> +}
>> +
>> +static bool kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
>> +{
>> + unsigned long psci_fn = *vcpu_reg(vcpu, 0) & ~((u32) 0);
>> + unsigned long val;
>> +
>> + switch (psci_fn) {
>> + case KVM_PSCI_0_2_FN_PSCI_VERSION:
>> + /*
>> + * Bits[31:16] = Major Version = 0
>> + * Bits[15:0] = Minor Version = 2
>> + */
>> + val = 2;
>> + break;
>> + case KVM_PSCI_0_2_FN_CPU_OFF:
>> + kvm_psci_vcpu_off(vcpu);
>> + val = KVM_PSCI_RET_SUCCESS;
>> + break;
>> + case KVM_PSCI_0_2_FN_CPU_ON:
>> + case KVM_PSCI_0_2_FN64_CPU_ON:
>> + val = kvm_psci_vcpu_on(vcpu);
>> + break;
>> + case KVM_PSCI_0_2_FN_CPU_SUSPEND:
>> + case KVM_PSCI_0_2_FN_AFFINITY_INFO:
>> + case KVM_PSCI_0_2_FN_MIGRATE:
>> + case KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE:
>> + case KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU:
>> + case KVM_PSCI_0_2_FN_SYSTEM_OFF:
>> + case KVM_PSCI_0_2_FN_SYSTEM_RESET:
>> + case KVM_PSCI_0_2_FN64_CPU_SUSPEND:
>> + case KVM_PSCI_0_2_FN64_AFFINITY_INFO:
>> + case KVM_PSCI_0_2_FN64_MIGRATE:
>> + case KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
>> + val = KVM_PSCI_RET_NI;
>> + break;
>> + default:
>> + return false;
>> + }
>> +
>> + *vcpu_reg(vcpu, 0) = val;
>> + return true;
>> +}
>> +
>> +static bool kvm_psci_0_1_call(struct kvm_vcpu *vcpu)
>> {
>> unsigned long psci_fn = *vcpu_reg(vcpu, 0) & ~((u32) 0);
>> unsigned long val;
>> @@ -112,7 +152,6 @@ bool kvm_psci_call(struct kvm_vcpu *vcpu)
>> case KVM_PSCI_FN_MIGRATE:
>> val = KVM_PSCI_RET_NI;
>> break;
>> -
>> default:
>> return false;
>> }
>> @@ -120,3 +159,25 @@ bool kvm_psci_call(struct kvm_vcpu *vcpu)
>> *vcpu_reg(vcpu, 0) = val;
>> return true;
>> }
>> +
>> +/**
>> + * kvm_psci_call - handle PSCI call if r0 value is in range
>> + * @vcpu: Pointer to the VCPU struct
>> + *
>> + * Handle PSCI calls from guests through traps from HVC instructions.
>> + * The calling convention is similar to SMC calls to the secure world where
>> + * the function number is placed in r0 and this function returns true if the
>> + * function number specified in r0 is withing the PSCI range, and false
>> + * otherwise.
>> + */
>> +bool kvm_psci_call(struct kvm_vcpu *vcpu)
>> +{
>> + switch (kvm_psci_version(vcpu)) {
>> + case KVM_ARM_PSCI_0_2:
>> + return kvm_psci_0_2_call(vcpu);
>> + case KVM_ARM_PSCI_0_1:
>> + return kvm_psci_0_1_call(vcpu);
>> + default:
>> + return false;
>> + };
>> +}
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index 0a1d697..92242ce 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -39,7 +39,7 @@
>> #include <kvm/arm_vgic.h>
>> #include <kvm/arm_arch_timer.h>
>>
>> -#define KVM_VCPU_MAX_FEATURES 2
>> +#define KVM_VCPU_MAX_FEATURES 3
>>
>> struct kvm_vcpu;
>> int kvm_target_cpu(void);
>> diff --git a/arch/arm64/include/asm/kvm_psci.h b/arch/arm64/include/asm/kvm_psci.h
>> index e301a48..e25c658 100644
>> --- a/arch/arm64/include/asm/kvm_psci.h
>> +++ b/arch/arm64/include/asm/kvm_psci.h
>> @@ -18,6 +18,10 @@
>> #ifndef __ARM64_KVM_PSCI_H__
>> #define __ARM64_KVM_PSCI_H__
>>
>> +#define KVM_ARM_PSCI_0_1 1
>> +#define KVM_ARM_PSCI_0_2 2
>> +
>> +int kvm_psci_version(struct kvm_vcpu *vcpu);
>> bool kvm_psci_call(struct kvm_vcpu *vcpu);
>>
>> #endif /* __ARM64_KVM_PSCI_H__ */
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> index d9f026b..b7555d3 100644
>> --- a/arch/arm64/include/uapi/asm/kvm.h
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -77,6 +77,7 @@ struct kvm_regs {
>>
>> #define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */
>> #define KVM_ARM_VCPU_EL1_32BIT 1 /* CPU running a 32bit VM */
>> +#define KVM_ARM_VCPU_PSCI_0_2 2 /* CPU uses PSCI v0.2 */
>>
>> struct kvm_vcpu_init {
>> __u32 target;
>> @@ -150,7 +151,7 @@ struct kvm_arch_memory_slot {
>> /* Highest supported SPI, from VGIC_NR_IRQS */
>> #define KVM_ARM_IRQ_GIC_MAX 127
>>
>> -/* PSCI interface */
>> +/* PSCI v0.1 interface */
>> #define KVM_PSCI_FN_BASE 0x95c1ba5e
>> #define KVM_PSCI_FN(n) (KVM_PSCI_FN_BASE + (n))
>>
>> @@ -159,10 +160,42 @@ struct kvm_arch_memory_slot {
>> #define KVM_PSCI_FN_CPU_ON KVM_PSCI_FN(2)
>> #define KVM_PSCI_FN_MIGRATE KVM_PSCI_FN(3)
>>
>> +/* PSCI v0.2 interface */
>> +#define KVM_PSCI_0_2_FN_BASE 0x84000000
>> +#define KVM_PSCI_0_2_FN(n) (KVM_PSCI_0_2_FN_BASE + (n))
>> +#define KVM_PSCI_0_2_FN64_BASE 0xC4000000
>> +#define KVM_PSCI_0_2_FN64(n) (KVM_PSCI_0_2_FN64_BASE + (n))
>> +
>> +#define KVM_PSCI_0_2_FN_PSCI_VERSION KVM_PSCI_0_2_FN(0)
>> +#define KVM_PSCI_0_2_FN_CPU_SUSPEND KVM_PSCI_0_2_FN(1)
>> +#define KVM_PSCI_0_2_FN_CPU_OFF KVM_PSCI_0_2_FN(2)
>> +#define KVM_PSCI_0_2_FN_CPU_ON KVM_PSCI_0_2_FN(3)
>> +#define KVM_PSCI_0_2_FN_AFFINITY_INFO KVM_PSCI_0_2_FN(4)
>> +#define KVM_PSCI_0_2_FN_MIGRATE KVM_PSCI_0_2_FN(5)
>> +#define KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE \
>> + KVM_PSCI_0_2_FN(6)
>> +#define KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU \
>> + KVM_PSCI_0_2_FN(7)
>> +#define KVM_PSCI_0_2_FN_SYSTEM_OFF KVM_PSCI_0_2_FN(8)
>> +#define KVM_PSCI_0_2_FN_SYSTEM_RESET KVM_PSCI_0_2_FN(9)
>> +
>> +#define KVM_PSCI_0_2_FN64_CPU_SUSPEND KVM_PSCI_0_2_FN64(1)
>> +#define KVM_PSCI_0_2_FN64_CPU_ON KVM_PSCI_0_2_FN64(3)
>> +#define KVM_PSCI_0_2_FN64_AFFINITY_INFO KVM_PSCI_0_2_FN64(4)
>> +#define KVM_PSCI_0_2_FN64_MIGRATE KVM_PSCI_0_2_FN64(5)
>> +#define KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU \
>> + KVM_PSCI_0_2_FN64(7)
>> +
>> +/* PSCI return values */
>> #define KVM_PSCI_RET_SUCCESS 0
>> #define KVM_PSCI_RET_NI ((unsigned long)-1)
>> #define KVM_PSCI_RET_INVAL ((unsigned long)-2)
>> #define KVM_PSCI_RET_DENIED ((unsigned long)-3)
>> +#define KVM_PSCI_RET_ALREADY_ON ((unsigned long)-4)
>> +#define KVM_PSCI_RET_ON_PENDING ((unsigned long)-5)
>> +#define KVM_PSCI_RET_INTERNAL_FAILURE ((unsigned long)-6)
>> +#define KVM_PSCI_RET_NOT_PRESENT ((unsigned long)-7)
>> +#define KVM_PSCI_RET_DISABLED ((unsigned long)-8)
>>
>> #endif
>>
>> --
>> 1.7.9.5
>>
>>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
> is for the sole use of the intended recipient(s) and contains information
> that is confidential and proprietary to Applied Micro Circuits Corporation or its subsidiaries.
> It is to be used solely for the purpose of furthering the parties' business relationship.
> All unauthorized review, use, disclosure or distribution is prohibited.
> If you are not the intended recipient, please contact the sender by reply e-mail
> and destroy all copies of the original message.
>
^ permalink raw reply
* [PATCH] arm: document "mach-virt" platform.
From: Ian Campbell @ 2014-02-03 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203045638.GB4167@cbox>
On Sun, 2014-02-02 at 20:56 -0800, Christoffer Dall wrote:
> On Thu, Jan 30, 2014 at 11:54:46AM -0500, Christopher Covington wrote:
> > Hi Ian,
> >
> > On 01/30/2014 11:11 AM, Ian Campbell wrote:
> > > mach-virt has existed for a while but it is not written down what it actually
> > > consists of. Although it seems a bit unusual to document a binding for an
> > > entire platform since mach-virt is entirely virtual it is helpful to have
> > > something to refer to in the absence of a single concrete implementation.
> > >
> > > I've done my best to capture the requirements based on the git log and my
> > > memory/understanding.
> > >
> > > While here remove the xenvm dts example, the Xen tools will now build a
> > > suitable mach-virt compatible dts when launching the guest.
> >
>
> [...]
>
> > > +The platform may also provide hypervisor specific functionality
> > > +(e.g. PV I/O), if it does so then this functionality must be
> > > +discoverable (directly or indirectly) via device tree.
> >
> > I think it would be informative to provide pointers here to commonly used
> > paravirtualized devices, especially VirtIO PCI/MMIO.
> >
>
> I disagree: that would only encourage limited testing or assumptions
> about these specific devices when really this platform is just a
> bare-bones platform driven by device tree which should make no
> preference, whatsoever, about which devices are used with the platform.
Thanks, I think this is exactly what I was failing to express coherently
last week ;-)
Ian.
^ permalink raw reply
* [PATCH 2/3 RESEND] mfd: tc3589x: Reform device tree probing
From: Lee Jones @ 2014-02-03 11:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaX7AO3C-N+OMCqtQvFUmHmVRfMhPqGY2LciZQHT7iq+g@mail.gmail.com>
> >> > Patch looks good to me. Is there any reason why we should rush this in
> >> > for v3.14, or is it okay to go to -next?
> >>
> >> No rush, but it's been on review like forever so unless there is
> >> some noise from the DT people at -rc1 I'd be very happy if you
> >> could apply patches 1 & 2 by then.
> >
> > I'm just waiting for their Ack. If I don't have it soon I'll review it
> > myself and any changes will have to come in via subsequent patch
> > submissions.
> >
> > I think it's sensible to head for v3.15 for this set.
>
> So now that v3.14-rc1 is out can we queue this stuff?
Queued.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 2/3 RESEND] mfd: tc3589x: Reform device tree probing
From: Lee Jones @ 2014-02-03 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390481008-23900-1-git-send-email-linus.walleij@linaro.org>
> This changes the following mechanisms in the TC3589x device tree
> probing path:
>
> - Use the .of_match_table in struct device_driver to match the
> device in the device tree.
> - Add matches for the proper compatible strings "toshiba,..."
> and all sub-variants, just as is done for the .id matches.
> - Move over all the allocation of platform data etc to the
> tc3589x_of_probe() function and follow the pattern of passing
> a platform data pointer back, or an error pointer on error,
> as found in the STMPE driver.
> - Match the new (proper) compatible strings for the GPIO and
> keypad MFD cells.
> - Use of_device_is_compatible() rather than just !strcmp()
> to discover which cells to instantiate.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/mfd/tc3589x.c | 84 ++++++++++++++++++++++++++++++++++++---------------
> 1 file changed, 59 insertions(+), 25 deletions(-)
Looks good, applied.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2 2/3] ARM/ARM64: KVM: Add support for PSCI v0.2 emulation
From: Mark Rutland @ 2014-02-03 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391078479-7406-3-git-send-email-anup.patel@linaro.org>
On Thu, Jan 30, 2014 at 10:41:18AM +0000, Anup Patel wrote:
> Currently, the in-kernel PSCI emulation provides PSCI v0.1 interface to
> VCPUs. This patch extends current in-kernel PSCI emulation to provide
> PSCI v0.2 interface to VCPUs.
>
> By default, ARM/ARM64 KVM will always provide PSCI v0.1 interface for
> keeping the ABI backward-compatible.
>
> To select PSCI v0.2 interface for VCPUs, the user space (i.e. QEMU or
> KVMTOOL) will have to set KVM_ARM_VCPU_PSCI_0_2 feature when doing VCPU
> init using KVM_ARM_VCPU_INIT ioctl.
I have an issue with this. PSCI 0.2 makes all but two functions (MIGRATE
and MIGRATE_INFO_CPU_UP) mandatory, and hence not allowed to return
NOT_SUPPORTED.
Additionally, for correct behaviour across a kexec in future, we'll
require AFFINITY_INFO for PSCI 0.2+ systems to determint when a CPU is
actually dead (and cannot affect the cache hierarchy). I'd very much
like to make that a hard requirement to ensure correctness.
I would very much like to see at least trivial implementations of those
mandatory functions, so that we don't need a
KVM_ARM_VCPU_PSCI_REALLY_0_2 or similar in future. As it stands this
series does not implement PSCI 0.2.
Thanks,
Mark.
>
> Signed-off-by: Anup Patel <anup.patel@linaro.org>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
> ---
> arch/arm/include/asm/kvm_host.h | 2 +-
> arch/arm/include/asm/kvm_psci.h | 4 ++
> arch/arm/include/uapi/asm/kvm.h | 35 ++++++++++++++-
> arch/arm/kvm/arm.c | 1 +
> arch/arm/kvm/psci.c | 85 +++++++++++++++++++++++++++++++------
> arch/arm64/include/asm/kvm_host.h | 2 +-
> arch/arm64/include/asm/kvm_psci.h | 4 ++
> arch/arm64/include/uapi/asm/kvm.h | 35 ++++++++++++++-
> 8 files changed, 152 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index bce6d32..dc4e3ed 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -36,7 +36,7 @@
> #define KVM_COALESCED_MMIO_PAGE_OFFSET 1
> #define KVM_HAVE_ONE_REG
>
> -#define KVM_VCPU_MAX_FEATURES 1
> +#define KVM_VCPU_MAX_FEATURES 2
>
> #include <kvm/arm_vgic.h>
>
> diff --git a/arch/arm/include/asm/kvm_psci.h b/arch/arm/include/asm/kvm_psci.h
> index 9a83d98..4c0e3e1 100644
> --- a/arch/arm/include/asm/kvm_psci.h
> +++ b/arch/arm/include/asm/kvm_psci.h
> @@ -18,6 +18,10 @@
> #ifndef __ARM_KVM_PSCI_H__
> #define __ARM_KVM_PSCI_H__
>
> +#define KVM_ARM_PSCI_0_1 1
> +#define KVM_ARM_PSCI_0_2 2
> +
> +int kvm_psci_version(struct kvm_vcpu *vcpu);
> bool kvm_psci_call(struct kvm_vcpu *vcpu);
>
> #endif /* __ARM_KVM_PSCI_H__ */
> diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
> index c498b60..bf860e2 100644
> --- a/arch/arm/include/uapi/asm/kvm.h
> +++ b/arch/arm/include/uapi/asm/kvm.h
> @@ -83,6 +83,7 @@ struct kvm_regs {
> #define KVM_VGIC_V2_CPU_SIZE 0x2000
>
> #define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */
> +#define KVM_ARM_VCPU_PSCI_0_2 1 /* CPU uses PSCI v0.2 */
>
> struct kvm_vcpu_init {
> __u32 target;
> @@ -164,7 +165,7 @@ struct kvm_arch_memory_slot {
> /* Highest supported SPI, from VGIC_NR_IRQS */
> #define KVM_ARM_IRQ_GIC_MAX 127
>
> -/* PSCI interface */
> +/* PSCI v0.1 interface */
> #define KVM_PSCI_FN_BASE 0x95c1ba5e
> #define KVM_PSCI_FN(n) (KVM_PSCI_FN_BASE + (n))
>
> @@ -173,9 +174,41 @@ struct kvm_arch_memory_slot {
> #define KVM_PSCI_FN_CPU_ON KVM_PSCI_FN(2)
> #define KVM_PSCI_FN_MIGRATE KVM_PSCI_FN(3)
>
> +/* PSCI v0.2 interface */
> +#define KVM_PSCI_0_2_FN_BASE 0x84000000
> +#define KVM_PSCI_0_2_FN(n) (KVM_PSCI_0_2_FN_BASE + (n))
> +#define KVM_PSCI_0_2_FN64_BASE 0xC4000000
> +#define KVM_PSCI_0_2_FN64(n) (KVM_PSCI_0_2_FN64_BASE + (n))
> +
> +#define KVM_PSCI_0_2_FN_PSCI_VERSION KVM_PSCI_0_2_FN(0)
> +#define KVM_PSCI_0_2_FN_CPU_SUSPEND KVM_PSCI_0_2_FN(1)
> +#define KVM_PSCI_0_2_FN_CPU_OFF KVM_PSCI_0_2_FN(2)
> +#define KVM_PSCI_0_2_FN_CPU_ON KVM_PSCI_0_2_FN(3)
> +#define KVM_PSCI_0_2_FN_AFFINITY_INFO KVM_PSCI_0_2_FN(4)
> +#define KVM_PSCI_0_2_FN_MIGRATE KVM_PSCI_0_2_FN(5)
> +#define KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE \
> + KVM_PSCI_0_2_FN(6)
> +#define KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU \
> + KVM_PSCI_0_2_FN(7)
> +#define KVM_PSCI_0_2_FN_SYSTEM_OFF KVM_PSCI_0_2_FN(8)
> +#define KVM_PSCI_0_2_FN_SYSTEM_RESET KVM_PSCI_0_2_FN(9)
> +
> +#define KVM_PSCI_0_2_FN64_CPU_SUSPEND KVM_PSCI_0_2_FN64(1)
> +#define KVM_PSCI_0_2_FN64_CPU_ON KVM_PSCI_0_2_FN64(3)
> +#define KVM_PSCI_0_2_FN64_AFFINITY_INFO KVM_PSCI_0_2_FN64(4)
> +#define KVM_PSCI_0_2_FN64_MIGRATE KVM_PSCI_0_2_FN64(5)
> +#define KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU \
> + KVM_PSCI_0_2_FN64(7)
> +
> +/* PSCI return values */
> #define KVM_PSCI_RET_SUCCESS 0
> #define KVM_PSCI_RET_NI ((unsigned long)-1)
> #define KVM_PSCI_RET_INVAL ((unsigned long)-2)
> #define KVM_PSCI_RET_DENIED ((unsigned long)-3)
> +#define KVM_PSCI_RET_ALREADY_ON ((unsigned long)-4)
> +#define KVM_PSCI_RET_ON_PENDING ((unsigned long)-5)
> +#define KVM_PSCI_RET_INTERNAL_FAILURE ((unsigned long)-6)
> +#define KVM_PSCI_RET_NOT_PRESENT ((unsigned long)-7)
> +#define KVM_PSCI_RET_DISABLED ((unsigned long)-8)
>
> #endif /* __ARM_KVM_H__ */
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 151eb91..e508125 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -193,6 +193,7 @@ int kvm_dev_ioctl_check_extension(long ext)
> case KVM_CAP_DESTROY_MEMORY_REGION_WORKS:
> case KVM_CAP_ONE_REG:
> case KVM_CAP_ARM_PSCI:
> + case KVM_CAP_ARM_PSCI_0_2:
> r = 1;
> break;
> case KVM_CAP_COALESCED_MMIO:
> diff --git a/arch/arm/kvm/psci.c b/arch/arm/kvm/psci.c
> index 448f60e..7fdc881 100644
> --- a/arch/arm/kvm/psci.c
> +++ b/arch/arm/kvm/psci.c
> @@ -85,17 +85,57 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
> return KVM_PSCI_RET_SUCCESS;
> }
>
> -/**
> - * kvm_psci_call - handle PSCI call if r0 value is in range
> - * @vcpu: Pointer to the VCPU struct
> - *
> - * Handle PSCI calls from guests through traps from HVC instructions.
> - * The calling convention is similar to SMC calls to the secure world where
> - * the function number is placed in r0 and this function returns true if the
> - * function number specified in r0 is withing the PSCI range, and false
> - * otherwise.
> - */
> -bool kvm_psci_call(struct kvm_vcpu *vcpu)
> +int kvm_psci_version(struct kvm_vcpu *vcpu)
> +{
> + if (test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features))
> + return KVM_ARM_PSCI_0_2;
> +
> + return KVM_ARM_PSCI_0_1;
> +}
> +
> +static bool kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
> +{
> + unsigned long psci_fn = *vcpu_reg(vcpu, 0) & ~((u32) 0);
> + unsigned long val;
> +
> + switch (psci_fn) {
> + case KVM_PSCI_0_2_FN_PSCI_VERSION:
> + /*
> + * Bits[31:16] = Major Version = 0
> + * Bits[15:0] = Minor Version = 2
> + */
> + val = 2;
> + break;
> + case KVM_PSCI_0_2_FN_CPU_OFF:
> + kvm_psci_vcpu_off(vcpu);
> + val = KVM_PSCI_RET_SUCCESS;
> + break;
> + case KVM_PSCI_0_2_FN_CPU_ON:
> + case KVM_PSCI_0_2_FN64_CPU_ON:
> + val = kvm_psci_vcpu_on(vcpu);
> + break;
> + case KVM_PSCI_0_2_FN_CPU_SUSPEND:
> + case KVM_PSCI_0_2_FN_AFFINITY_INFO:
> + case KVM_PSCI_0_2_FN_MIGRATE:
> + case KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE:
> + case KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU:
> + case KVM_PSCI_0_2_FN_SYSTEM_OFF:
> + case KVM_PSCI_0_2_FN_SYSTEM_RESET:
> + case KVM_PSCI_0_2_FN64_CPU_SUSPEND:
> + case KVM_PSCI_0_2_FN64_AFFINITY_INFO:
> + case KVM_PSCI_0_2_FN64_MIGRATE:
> + case KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
> + val = KVM_PSCI_RET_NI;
> + break;
> + default:
> + return false;
> + }
> +
> + *vcpu_reg(vcpu, 0) = val;
> + return true;
> +}
> +
> +static bool kvm_psci_0_1_call(struct kvm_vcpu *vcpu)
> {
> unsigned long psci_fn = *vcpu_reg(vcpu, 0) & ~((u32) 0);
> unsigned long val;
> @@ -112,7 +152,6 @@ bool kvm_psci_call(struct kvm_vcpu *vcpu)
> case KVM_PSCI_FN_MIGRATE:
> val = KVM_PSCI_RET_NI;
> break;
> -
> default:
> return false;
> }
> @@ -120,3 +159,25 @@ bool kvm_psci_call(struct kvm_vcpu *vcpu)
> *vcpu_reg(vcpu, 0) = val;
> return true;
> }
> +
> +/**
> + * kvm_psci_call - handle PSCI call if r0 value is in range
> + * @vcpu: Pointer to the VCPU struct
> + *
> + * Handle PSCI calls from guests through traps from HVC instructions.
> + * The calling convention is similar to SMC calls to the secure world where
> + * the function number is placed in r0 and this function returns true if the
> + * function number specified in r0 is withing the PSCI range, and false
> + * otherwise.
> + */
> +bool kvm_psci_call(struct kvm_vcpu *vcpu)
> +{
> + switch (kvm_psci_version(vcpu)) {
> + case KVM_ARM_PSCI_0_2:
> + return kvm_psci_0_2_call(vcpu);
> + case KVM_ARM_PSCI_0_1:
> + return kvm_psci_0_1_call(vcpu);
> + default:
> + return false;
> + };
> +}
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 0a1d697..92242ce 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -39,7 +39,7 @@
> #include <kvm/arm_vgic.h>
> #include <kvm/arm_arch_timer.h>
>
> -#define KVM_VCPU_MAX_FEATURES 2
> +#define KVM_VCPU_MAX_FEATURES 3
>
> struct kvm_vcpu;
> int kvm_target_cpu(void);
> diff --git a/arch/arm64/include/asm/kvm_psci.h b/arch/arm64/include/asm/kvm_psci.h
> index e301a48..e25c658 100644
> --- a/arch/arm64/include/asm/kvm_psci.h
> +++ b/arch/arm64/include/asm/kvm_psci.h
> @@ -18,6 +18,10 @@
> #ifndef __ARM64_KVM_PSCI_H__
> #define __ARM64_KVM_PSCI_H__
>
> +#define KVM_ARM_PSCI_0_1 1
> +#define KVM_ARM_PSCI_0_2 2
> +
> +int kvm_psci_version(struct kvm_vcpu *vcpu);
> bool kvm_psci_call(struct kvm_vcpu *vcpu);
>
> #endif /* __ARM64_KVM_PSCI_H__ */
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index d9f026b..b7555d3 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -77,6 +77,7 @@ struct kvm_regs {
>
> #define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */
> #define KVM_ARM_VCPU_EL1_32BIT 1 /* CPU running a 32bit VM */
> +#define KVM_ARM_VCPU_PSCI_0_2 2 /* CPU uses PSCI v0.2 */
>
> struct kvm_vcpu_init {
> __u32 target;
> @@ -150,7 +151,7 @@ struct kvm_arch_memory_slot {
> /* Highest supported SPI, from VGIC_NR_IRQS */
> #define KVM_ARM_IRQ_GIC_MAX 127
>
> -/* PSCI interface */
> +/* PSCI v0.1 interface */
> #define KVM_PSCI_FN_BASE 0x95c1ba5e
> #define KVM_PSCI_FN(n) (KVM_PSCI_FN_BASE + (n))
>
> @@ -159,10 +160,42 @@ struct kvm_arch_memory_slot {
> #define KVM_PSCI_FN_CPU_ON KVM_PSCI_FN(2)
> #define KVM_PSCI_FN_MIGRATE KVM_PSCI_FN(3)
>
> +/* PSCI v0.2 interface */
> +#define KVM_PSCI_0_2_FN_BASE 0x84000000
> +#define KVM_PSCI_0_2_FN(n) (KVM_PSCI_0_2_FN_BASE + (n))
> +#define KVM_PSCI_0_2_FN64_BASE 0xC4000000
> +#define KVM_PSCI_0_2_FN64(n) (KVM_PSCI_0_2_FN64_BASE + (n))
> +
> +#define KVM_PSCI_0_2_FN_PSCI_VERSION KVM_PSCI_0_2_FN(0)
> +#define KVM_PSCI_0_2_FN_CPU_SUSPEND KVM_PSCI_0_2_FN(1)
> +#define KVM_PSCI_0_2_FN_CPU_OFF KVM_PSCI_0_2_FN(2)
> +#define KVM_PSCI_0_2_FN_CPU_ON KVM_PSCI_0_2_FN(3)
> +#define KVM_PSCI_0_2_FN_AFFINITY_INFO KVM_PSCI_0_2_FN(4)
> +#define KVM_PSCI_0_2_FN_MIGRATE KVM_PSCI_0_2_FN(5)
> +#define KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE \
> + KVM_PSCI_0_2_FN(6)
> +#define KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU \
> + KVM_PSCI_0_2_FN(7)
> +#define KVM_PSCI_0_2_FN_SYSTEM_OFF KVM_PSCI_0_2_FN(8)
> +#define KVM_PSCI_0_2_FN_SYSTEM_RESET KVM_PSCI_0_2_FN(9)
> +
> +#define KVM_PSCI_0_2_FN64_CPU_SUSPEND KVM_PSCI_0_2_FN64(1)
> +#define KVM_PSCI_0_2_FN64_CPU_ON KVM_PSCI_0_2_FN64(3)
> +#define KVM_PSCI_0_2_FN64_AFFINITY_INFO KVM_PSCI_0_2_FN64(4)
> +#define KVM_PSCI_0_2_FN64_MIGRATE KVM_PSCI_0_2_FN64(5)
> +#define KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU \
> + KVM_PSCI_0_2_FN64(7)
> +
> +/* PSCI return values */
> #define KVM_PSCI_RET_SUCCESS 0
> #define KVM_PSCI_RET_NI ((unsigned long)-1)
> #define KVM_PSCI_RET_INVAL ((unsigned long)-2)
> #define KVM_PSCI_RET_DENIED ((unsigned long)-3)
> +#define KVM_PSCI_RET_ALREADY_ON ((unsigned long)-4)
> +#define KVM_PSCI_RET_ON_PENDING ((unsigned long)-5)
> +#define KVM_PSCI_RET_INTERNAL_FAILURE ((unsigned long)-6)
> +#define KVM_PSCI_RET_NOT_PRESENT ((unsigned long)-7)
> +#define KVM_PSCI_RET_DISABLED ((unsigned long)-8)
>
> #endif
>
> --
> 1.7.9.5
>
>
^ permalink raw reply
* [PATCH V3 5/5] ARM CoreSight: ETM: Add PID control support
From: Will Deacon @ 2014-02-03 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391098270-8867-6-git-send-email-adrienverge@gmail.com>
On Thu, Jan 30, 2014 at 04:11:10PM +0000, Adrien Verg? wrote:
> In the same manner as for enabling tracing, an entry is created in
> sysfs to set the PID that triggers tracing. This change is effective
> only if CONFIG_PID_IN_CONTEXTIDR is set.
>
> When using PID namespaces, the virtual PID given by the user is
> converted to the globally unique ID (task_pid_nr) that is present
> in the Context ID register.
Hmm, I wonder whether debugfs would be more suitable for this?
Will
^ permalink raw reply
* [PATCH v5 13/14] ARM: sun4i: dts: Add ahci / sata support
From: Hans de Goede @ 2014-02-03 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131134505.GG2950@lukather>
Hi,
On 01/31/2014 02:45 PM, Maxime Ripard wrote:
> Hi Hans,
>
> On Wed, Jan 22, 2014 at 08:04:48PM +0100, Hans de Goede wrote:
>> From: Oliver Schinagl <oliver@schinagl.nl>
>>
>> This patch adds sunxi sata support to A10 boards that have such a connector.
>> Some boards also feature a regulator via a GPIO and support for this is also
>> added.
>>
>> Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> arch/arm/boot/dts/sun4i-a10-a1000.dts | 4 ++++
>> arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 6 +++++
>> arch/arm/boot/dts/sun4i-a10.dtsi | 8 +++++++
>> arch/arm/boot/dts/sunxi-ahci-reg.dtsi | 38 ++++++++++++++++++++++++++++++
>
> I'm still half convinced about this at the moment, given the number of
> platforms we support, we can always change it back if things become too messy.
I assume that this == sunxi-ahci-reg.dtsi ? To be sure I understand you correctly,
you're ok with going this route for now, right ?
How about the same for the usb ohci/ehci controller dts patches ? Currently they
are still using the put a regulator node in each dts file model, which leads to
a lot of boilerplate code. So I would like to move to the same model as I'm
using here for the sata supply.
>
>> 4 files changed, 56 insertions(+)
>> create mode 100644 arch/arm/boot/dts/sunxi-ahci-reg.dtsi
>>
>> diff --git a/arch/arm/boot/dts/sun4i-a10-a1000.dts b/arch/arm/boot/dts/sun4i-a10-a1000.dts
>> index aef8207..3fb7305 100644
>> --- a/arch/arm/boot/dts/sun4i-a10-a1000.dts
>> +++ b/arch/arm/boot/dts/sun4i-a10-a1000.dts
>> @@ -48,6 +48,10 @@
>> status = "okay";
>> };
>>
>> + ahci: sata at 01c18000 {
>> + status = "okay";
>> + };
>> +
>> pinctrl at 01c20800 {
>> mmc0_cd_pin_a1000: mmc0_cd_pin at 0 {
>> allwinner,pins = "PH1";
>> diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
>> index f50fb2b..6ae1110 100644
>> --- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
>> +++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
>> @@ -12,6 +12,7 @@
>>
>> /dts-v1/;
>> /include/ "sun4i-a10.dtsi"
>> +/include/ "sunxi-ahci-reg.dtsi"
>>
>> / {
>> model = "Cubietech Cubieboard";
>> @@ -51,6 +52,11 @@
>> status = "okay";
>> };
>>
>> + ahci: sata at 01c18000 {
>> + target-supply = <®_ahci_5v>;
>> + status = "okay";
>> + };
>> +
>> pinctrl at 01c20800 {
>> mmc0_cd_pin_cubieboard: mmc0_cd_pin at 0 {
>> allwinner,pins = "PH1";
>> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
>> index 4736dd2..198dcda 100644
>> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
>> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
>> @@ -331,6 +331,14 @@
>> status = "disabled";
>> };
>>
>> + ahci: sata at 01c18000 {
>> + compatible = "allwinner,sun4i-a10-ahci";
>
> To be consistent with the rest of the sun4i devices compatible, It
> should be sun4i-ahci.
>
> However, since these devices don't use the same compatible pattern as
> their own machine compatible, and are consisent with the rest of the
> compatibles for the other SoCs, we can probably make this a go to
> transition progressively to this pattern.
Ack, I think it would be good to be consistent and try to use
sun?i-aXX-foo everywhere. I noticed that we already use that in various
places, so I thought it would be good to do that for all new dts bindings.
> I'll cook up some patches for the other devices.
Thanks.
>
>> + reg = <0x01c18000 0x1000>;
>> + interrupts = <56>;
>> + clocks = <&pll6 0>, <&ahb_gates 25>;
>> + status = "disabled";
>> + };
>> +
>> intc: interrupt-controller at 01c20400 {
>> compatible = "allwinner,sun4i-ic";
>> reg = <0x01c20400 0x400>;
>> diff --git a/arch/arm/boot/dts/sunxi-ahci-reg.dtsi b/arch/arm/boot/dts/sunxi-ahci-reg.dtsi
>> new file mode 100644
>> index 0000000..955b197
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sunxi-ahci-reg.dtsi
>> @@ -0,0 +1,38 @@
>> +/*
>> + * sunxi boards sata target power supply common code
>> + *
>> + * Copyright 2014 - Hans de Goede <hdegoede@redhat.com>
>> + *
>> + * The code contained herein is licensed under the GNU General Public
>> + * License. You may obtain a copy of the GNU General Public License
>> + * Version 2 or later at the following locations:
>> + *
>> + * http://www.opensource.org/licenses/gpl-license.html
>> + * http://www.gnu.org/copyleft/gpl.html
>> + */
>> +
>> +/ {
>> + soc at 01c00000 {
>> + ahci_pwr_pin_a: ahci_pwr_pin at 0 {
>> + allwinner,pins = "PB8";
>> + allwinner,function = "gpio_out";
>> + allwinner,drive = <0>;
>> + allwinner,pull = <0>;
>> + };
>
> This should be under the pinctrl node.
Fixed already locally.
Regards,
Hans
^ permalink raw reply
* [PATCH v4 2/5] arm: add new asm macro update_sctlr
From: Will Deacon @ 2014-02-03 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130131247.GG11329@bivouac.eciton.net>
On Thu, Jan 30, 2014 at 01:12:47PM +0000, Leif Lindholm wrote:
> Oh, that's neat - thanks!
>
> Well, given that, I can think of two less horrible options:
> 1)
> .macro update_sctlr, tmp:req, set=, clear=
> mrc p15, 0, \tmp, c1, c0, 0
> .ifnc \set,
> orr \tmp, \set
> .endif
> .ifnc \clear,
> mvn \clear, \clear
> and \tmp, \tmp, \clear
Can't you use bic here?
> .endif
> mcr p15, 0, \tmp, c1, c0, 0
> .endm
>
> With the two call sites in uefi_phys.S as:
>
> ldr r5, =(CR_M)
> update_sctlr r12, , r5
> and
> ldr r4, =(CR_I | CR_C | CR_M)
> update_sctlr r12, r4
These ldr= could be movs, right?
If so, I definitely prefer this to putting an ldr = into the macro itself
(option 2).
Cheers,
Will
^ permalink raw reply
* [PATCH 2/3 RESEND] mfd: tc3589x: Reform device tree probing
From: Linus Walleij @ 2014-02-03 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123151123.GE8586@lee--X1>
On Thu, Jan 23, 2014 at 4:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>> > Patch looks good to me. Is there any reason why we should rush this in
>> > for v3.14, or is it okay to go to -next?
>>
>> No rush, but it's been on review like forever so unless there is
>> some noise from the DT people at -rc1 I'd be very happy if you
>> could apply patches 1 & 2 by then.
>
> I'm just waiting for their Ack. If I don't have it soon I'll review it
> myself and any changes will have to come in via subsequent patch
> submissions.
>
> I think it's sensible to head for v3.15 for this set.
So now that v3.14-rc1 is out can we queue this stuff?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] [RFC] ARM: ixp4xx: fix timer latch calculation
From: Uwe Kleine-König @ 2014-02-03 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140113194259.GG29475@pengutronix.de>
In commit f0402f9b4711 ("ARM: ixp4xx: stop using <mach/timex.h>")
I didn't intend to implement a functional change, but as Olof noticed I
failed---at least a bit. Before this commit the following was used to
determine the latch value used:
#define IXP4XX_TIMER_FREQ 66666000
#define CLOCK_TICK_RATE \
(((IXP4XX_TIMER_FREQ / HZ & ~IXP4XX_OST_RELOAD_MASK) + 1) * HZ)
#define LATCH ((CLOCK_TICK_RATE + HZ/2) / HZ)
The complicated calculation was done "b/c the timer register ignores the
bottom 2 bits of the LATCH value." With HZ=100 CLOCK_TICK_RATE used to
calculate to 66666100 and so LATCH to 666661. In ixp4xx_set_mode the
term
LATCH & ~IXP4XX_OST_RELOAD_MASK
was used to write to the relevant register (with IXP4XX_OST_RELOAD_MASK
being 3) and so effectively 666660 was used.
In commit f0402f9b4711 I translated that to:
#define IXP4XX_TIMER_FREQ 66666000
#define IXP4XX_LATCH DIV_ROUND_CLOSEST(IXP4XX_TIMER_FREQ, HZ)
which results in the same register writes, but still doesn't bear in
mind that the two least significant bits cannot be specified (which is
relevant only when HZ or IXP4XX_TIMER_FREQ are changed).
Instead of reverting back to the old approach use a more obvious and
also more correct way to calculate LATCH. (Regarding the more
correct claim: With IXP4XX_TIMER_FREQ == 66665999, the old code resulted
in LATCH = 666657 corresponding to a cycle time of 0.009999940149400597
seconds (error: -6.0e-8 s) while the new approach results in LATCH =
666660 and so a cycle time of 0.010000000150001503 seconds
(error: 1.5e-10 s).)
Fixes: f0402f9b4711 ("ARM: ixp4xx: stop using <mach/timex.h>")
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
Hello,
I didn't hear anything back from the ixp4xx maintainers, I didn't find a
reference manual and I don't have an ixp4xx machine to test this patch.
Still I'm confident it works as expected and results in a more exact
clock calculation than both before and after my patch.
Olof requested this to be a seperate patch to not need to reverify the
rest of the series. Does this make the series ready to be merged for
3.15 now? If so, should I send a new pull request with this patch
applied on top of the old request or do you handle that yourself?
Best regards
Uwe
arch/arm/mach-ixp4xx/common.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c
index 20b62aa30086..37e6cdac1642 100644
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -45,7 +45,15 @@
#include <asm/mach/time.h>
#define IXP4XX_TIMER_FREQ 66666000
-#define IXP4XX_LATCH DIV_ROUND_CLOSEST(IXP4XX_TIMER_FREQ, HZ)
+
+/*
+ * The timer register doesn't allow to specify the two least significant bits of
+ * the timeout value and assumes them being zero. So make sure IXP4XX_LATCH is
+ * the best value with the two least significant bits unset.
+ */
+#define IXP4XX_LATCH DIV_ROUND_CLOSEST(IXP4XX_TIMER_FREQ, \
+ (IXP4XX_OST_RELOAD_MASK + 1) * HZ) * \
+ (IXP4XX_OST_RELOAD_MASK + 1)
static void __init ixp4xx_clocksource_init(void);
static void __init ixp4xx_clockevent_init(void);
--
1.8.5.3
^ permalink raw reply related
* [PATCH 16/18] charger: max14577: Add support for MAX77836 charger
From: Lee Jones @ 2014-02-03 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390911522-28209-17-git-send-email-k.kozlowski@samsung.com>
On Tue, 28 Jan 2014, Krzysztof Kozlowski wrote:
> Add support for MAX77836 charger to the max14577 driver. The MAX77836
> charger is almost the same as 14577 model except:
> - No dead-battery detection;
> - Support for special charger (like in max77693);
> - Support for DX over-voltage protection (like in max77693);
> - Lower values of charging current (two times lower current for
> slow/fast charge, much lower EOC current);
> - Slightly different values in ChgTyp field of STATUS2 register. On
> MAX14577 0x6 is reserved and 0x7 dead battery. On the MAX77836 the
> 0x6 means special charger and 0x7 is reserved. Regardless of these
> differences the driver maps them to one enum maxim_muic_charger_type.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Anton Vorontsov <anton@enomsg.org>
> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> ---
> drivers/extcon/extcon-max14577.c | 2 +-
> drivers/power/max14577_charger.c | 81 +++++++++++++++++++++++++++-------
> include/linux/mfd/max14577-private.h | 57 +++++++++++++++++-------
> 3 files changed, 106 insertions(+), 34 deletions(-)
For the MFD changes:
Acked-by: Lee Jones <lee.jones@linaro.org>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 15/18] regulator: max14577: Add support for max77836 regulators
From: Lee Jones @ 2014-02-03 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390911522-28209-16-git-send-email-k.kozlowski@samsung.com>
On Tue, 28 Jan 2014, Krzysztof Kozlowski wrote:
> Add support for MAX77836 chipset and its additional two LDO regulators.
> These LDO regulators are controlled by the PMIC block with additional
> regmap (different I2C slave address).
>
> The MAX77836 charger and safeout regulators are almost identical to
> MAX14577. The registry layout is the same, except values for charger's
> current. The patch adds simple mapping between device type and supported
> current by the charger regulator.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/regulator/max14577.c | 275 +++++++++++++++++++++++++++++-----
> include/linux/mfd/max14577-private.h | 32 +++-
> include/linux/mfd/max14577.h | 10 ++
> 3 files changed, 281 insertions(+), 36 deletions(-)
For the MFD changes:
Acked-by: Lee Jones <lee.jones@linaro.org>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 14/18] extcon: max14577: Add support for max77836
From: Lee Jones @ 2014-02-03 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390911522-28209-15-git-send-email-k.kozlowski@samsung.com>
On Tue, 28 Jan 2014, Krzysztof Kozlowski wrote:
> Add support for MAX77836 chipset to the max14577 extcon driver. The
> MAX77836 MUIC has additional interrupts (VIDRM, ADC1K) so IRQ handling
> is split up into two functions: max14577_parse_irq() and
> max77836_parse_irq().
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/extcon/extcon-max14577.c | 107 ++++++++++++++++++++++++++++------
> drivers/mfd/max14577.c | 1 +
> include/linux/mfd/max14577-private.h | 3 +
> 3 files changed, 93 insertions(+), 18 deletions(-)
For the MFD changes:
Acked-by: Lee Jones <lee.jones@linaro.org>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 13/18] mfd: max77836: Add max77836 support to max14577 driver
From: Lee Jones @ 2014-02-03 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390911522-28209-14-git-send-email-k.kozlowski@samsung.com>
On Tue, 28 Jan 2014, Krzysztof Kozlowski wrote:
> Add Maxim 77836 support to max14577 driver. The chipsets have same MUIC
> component so the extcon, charger and regulators are almost the same. The
> max77836 however has also PMIC and Fuel Gauge.
>
> The MAX77836 uses three I2C slave addresses and has additional interrupts
> (related to PMIC and Fuel Gauge). It has also Interrupt Source register,
> just like MAX77686 and MAX77693.
>
> The MAX77836 PMIC's TOPSYS and INTSRC interrupts are reported in the
> PMIC block. The PMIC block has different I2C slave address and uses own
> regmap so another regmap_irq_chip is needed.
>
> Since we have two regmap_irq_chip, use shared interrupts on MAX77836.
>
> This patch adds additional defines and functions to the max14577 MFD core
> driver so the driver will handle both chipsets.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/mfd/max14577.c | 215 ++++++++++++++++++++++++++++++++--
> include/linux/mfd/max14577-private.h | 85 +++++++++++++-
> include/linux/mfd/max14577.h | 7 +-
> 3 files changed, 296 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/mfd/max14577.c b/drivers/mfd/max14577.c
> index 224aba8c5b3f..5b10f6f89834 100644
> --- a/drivers/mfd/max14577.c
> +++ b/drivers/mfd/max14577.c
> @@ -1,7 +1,7 @@
> /*
> - * max14577.c - mfd core driver for the Maxim 14577
> + * max14577.c - mfd core driver for the Maxim 14577/77836
We may wish to consider changing the name of this file at a later
date.
> - * Copyright (C) 2013 Samsung Electrnoics
> + * Copyright (C) 2013,2014 Samsung Electrnoics
You can remove the the '2013' completely now.
> * Chanwoo Choi <cw00.choi@samsung.com>
> * Krzysztof Kozlowski <k.kozlowski@samsung.com>
> *
> @@ -37,11 +37,31 @@ static struct mfd_cell max14577_devs[] = {
> { .name = "max14577-charger", },
> };
>
> +static struct mfd_cell max77836_devs[] = {
> + {
> + .name = "max77836-muic",
> + .of_compatible = "maxim,max77836-muic",
> + },
> + {
> + .name = "max77836-regulator",
> + .of_compatible = "maxim,max77836-regulator",
> + },
> + { .name = "max77836-charger", },
Why doesn't the charger require a compatible string?
> + {
> + .name = "max77836-battery",
> + .of_compatible = "maxim,max77836-battery",
> + },
> +};
> +
> @@ -56,6 +76,29 @@ static bool max14577_muic_volatile_reg(struct device *dev, unsigned int reg)
> return false;
> }
>
> +static bool max77836_muic_volatile_reg(struct device *dev, unsigned int reg)
> +{
> + /* Any max14577 volatile registers are also max77836 volatile. */
> + if (max14577_muic_volatile_reg(dev, reg))
> + return true;
New line here please.
> + switch (reg) {
> + case MAX77836_FG_REG_VCELL_MSB ... MAX77836_FG_REG_SOC_LSB:
> + case MAX77836_FG_REG_CRATE_MSB ... MAX77836_FG_REG_CRATE_LSB:
> + case MAX77836_FG_REG_STATUS_H ... MAX77836_FG_REG_STATUS_L:
> + /* fall through */
It's okay not to have these here. We know how switch statements
work. ;)
> + case MAX77836_PMIC_REG_INTSRC:
> + /* fall through */
> + case MAX77836_PMIC_REG_TOPSYS_INT:
> + /* fall through */
> + case MAX77836_PMIC_REG_TOPSYS_STAT:
> + return true;
> + default:
> + break;
> + }
> + return false;
> +}
> +
> +
Superfluous new line here.
> +static const struct regmap_irq_chip max77836_muic_irq_chip = {
> + .name = "max77836-muic",
> + .status_base = MAXIM_MUIC_REG_INT1,
> + .mask_base = MAXIM_MUIC_REG_INTMASK1,
> + .mask_invert = 1,
I'd prefer the use of 'true' or 'false' for bools.
> + .num_regs = 3,
> + .irqs = max77836_muic_irqs,
> + .num_irqs = ARRAY_SIZE(max77836_muic_irqs),
> +};
> +
<snip>
> +static const struct regmap_irq_chip max77836_pmic_irq_chip = {
> + .name = "max77836-pmic",
> + .status_base = MAX77836_PMIC_REG_TOPSYS_INT,
> + .mask_base = MAX77836_PMIC_REG_TOPSYS_INT_MASK,
> + .mask_invert = 0,
'false' please.
> + .num_regs = 1,
> + .irqs = max77836_pmic_irqs,
> + .num_irqs = ARRAY_SIZE(max77836_pmic_irqs),
> +};
> +
<snip>
> +static int max77836_init(struct maxim_core *maxim_core)
> +{
> + int ret;
> + u8 intsrc_mask;
> +
> + maxim_core->i2c_pmic = i2c_new_dummy(maxim_core->i2c->adapter,
> + I2C_ADDR_PMIC);
> + if (!maxim_core->i2c_pmic) {
> + dev_err(maxim_core->dev, "Failed to register PMIC I2C device\n");
> + return -EPERM;
Not sure this is the best errno to return.
Perhaps -ENODEV would be more suitable?
<snip>
> #define MAXIM_STATUS2_CHGTYP_MASK (0x7 << MAXIM_STATUS2_CHGTYP_SHIFT)
> #define MAXIM_STATUS2_CHGDETRUN_MASK (0x1 << MAXIM_STATUS2_CHGDETRUN_SHIFT)
> #define MAXIM_STATUS2_DCDTMR_MASK (0x1 << MAXIM_STATUS2_DCDTMR_SHIFT)
> #define MAXIM_STATUS2_DBCHG_MASK (0x1 << MAXIM_STATUS2_DBCHG_SHIFT)
> #define MAXIM_STATUS2_VBVOLT_MASK (0x1 << MAXIM_STATUS2_VBVOLT_SHIFT)
> +#define MAX77836_STATUS2_VIDRM_MASK (0x1 << MAX77836_STATUS2_VIDRM_SHIFT)
It's up to you, but all of these "0x1 <<"s can be replaced with the
BIT() macro if you so wished.
> /* MAX14577 STATUS3 register */
> #define MAXIM_STATUS3_EOC_SHIFT 0
> @@ -232,6 +242,70 @@ enum maxim_muic_charger_type {
>
>
>
Do all of these extra new lines really exist, or is it just a patch
thing? If they do, can you get rid of them please?
> +/* Slave addr = 0x46: PMIC */
> +enum max77836_pmic_reg {
> + MAX77836_COMP_REG_COMP1 = 0x60,
> +
> + MAX77836_LDO_REG_CNFG1_LDO1 = 0x51,
> + MAX77836_LDO_REG_CNFG2_LDO1 = 0x52,
> + MAX77836_LDO_REG_CNFG1_LDO2 = 0x53,
> + MAX77836_LDO_REG_CNFG2_LDO2 = 0x54,
> + MAX77836_LDO_REG_CNFG_LDO_BIAS = 0x55,
> +
> + MAX77836_PMIC_REG_PMIC_ID = 0x20,
> + MAX77836_PMIC_REG_PMIC_REV = 0x21,
> + MAX77836_PMIC_REG_INTSRC = 0x22,
> + MAX77836_PMIC_REG_INTSRC_MASK = 0x23,
> + MAX77836_PMIC_REG_TOPSYS_INT = 0x24,
> + MAX77836_PMIC_REG_TOPSYS_INT_MASK = 0x26,
> + MAX77836_PMIC_REG_TOPSYS_STAT = 0x28,
> + MAX77836_PMIC_REG_MRSTB_CNTL = 0x2A,
> + MAX77836_PMIC_REG_LSCNFG = 0x2B,
> +
> + MAX77836_PMIC_REG_END,
> +};
Any reason why these aren't in numerical order?
<snip>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v4 1/1] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif
From: Ivan Khoronzhuk @ 2014-02-03 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E9D23D.2080506@ti.com>
I've sent v5.
Please, look at it http://www.spinics.net/lists/arm-kernel/msg303953.html
On 01/30/2014 06:17 AM, Sekhar Nori wrote:
> On Wednesday 29 January 2014 08:50 PM, Ivan Khoronzhuk wrote:
>> Hi Sekhar,
>>
>> Do you want me to correct it?
> Yes, please!
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH 10/18] mfd: max14577: Add detection of device type
From: Lee Jones @ 2014-02-03 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390911522-28209-11-git-send-email-k.kozlowski@samsung.com>
> This patch continues the preparation for adding support for max77836
> device to existing max14577 driver.
>
> Add enum for types of devices supported by this driver. The device type
> will be detected by matching of_device_id, or i2c_device_id as a
> fallback.
>
> The patch also moves to separate function the code related to displaying
> DeviceID register values.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/mfd/max14577.c | 61 +++++++++++++++++++++++-----------
> include/linux/mfd/max14577-private.h | 12 ++++---
> 2 files changed, 50 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/mfd/max14577.c b/drivers/mfd/max14577.c
> index 1d8104213b3e..224aba8c5b3f 100644
> --- a/drivers/mfd/max14577.c
> +++ b/drivers/mfd/max14577.c
> @@ -20,6 +20,7 @@
<snip>
> +static void max14577_print_dev_type(struct maxim_core *maxim_core)
> +{
> + u8 reg_data, vendor_id, device_id;
> + int ret = max14577_read_reg(maxim_core->regmap_muic,
> + MAXIM_MUIC_REG_DEVICEID, ®_data);
I'm not a big fan of declaring variables whilst feeding them with
function return values. Can you separate the two please?
> + if (ret) {
> + dev_err(maxim_core->dev, "Failed to read DEVICEID
> register: %d\n",
I think this is too many chars.
> + ret);
> + return;
> + }
> +
<snip>
> - ret = max14577_read_reg(maxim_core->regmap_muic,
> - MAXIM_MUIC_REG_DEVICEID, ®_data);
> - if (ret) {
> - dev_err(maxim_core->dev, "Device not found on this channel: %d\n",
> - ret);
> - return ret;
> + if (np) {
> + const struct of_device_id *of_id =
> + of_match_device(max14577_dt_match, &i2c->dev);
Again this is a bit messy. Bring it down onto a separate line.
> + if (of_id)
> + maxim_core->dev_type = (unsigned int)of_id->data;
> + } else {
> + maxim_core->dev_type = id->driver_data;
> }
<snip>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 09/18] mfd: max14577: Add "muic" suffix to regmap and irq_chip
From: Lee Jones @ 2014-02-03 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390911522-28209-10-git-send-email-k.kozlowski@samsung.com>
> This patch continues the preparation for adding support for max77836
> device to existing max14577 driver.
>
> Add "muic" suffix to regmap and irq_data fields in maxim_core state
> container to prepare for max77836 support.
> This is only a rename-like patch, new code is not added.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/extcon/extcon-max14577.c | 17 +++++++++--------
> drivers/mfd/max14577.c | 22 +++++++++++-----------
> drivers/power/max14577_charger.c | 8 ++++----
> drivers/regulator/max14577.c | 2 +-
> include/linux/mfd/max14577-private.h | 4 ++--
> 5 files changed, 27 insertions(+), 26 deletions(-)
Happy to apply this with maintainer Acks.
Acked-by: Lee Jones <lee.jones@linaro.org>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* NFS client broken in Linus' tip
From: Takashi Iwai @ 2014-02-03 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391378678.8123.5.camel@leira.trondhjem.org>
At Sun, 02 Feb 2014 17:04:38 -0500,
Trond Myklebust wrote:
>
> On Sun, 2014-02-02 at 12:27 +0000, Russell King - ARM Linux wrote:
> > On Sat, Feb 01, 2014 at 01:03:28AM +0000, Russell King - ARM Linux wrote:
> > > On Fri, Jan 31, 2014 at 03:59:30PM -0500, Trond Myklebust wrote:
> > > > On Thu, 2014-01-30 at 15:38 +0000, Russell King - ARM Linux wrote:
> > > > > On Thu, Jan 30, 2014 at 06:32:08AM -0800, Christoph Hellwig wrote:
> > > > > > On Thu, Jan 30, 2014 at 02:27:52PM +0000, Russell King - ARM Linux wrote:
> > > > > > > Yes and no. I still end up with an empty /etc/mtab, but the file now
> > > > > > > exists. However, I can create and echo data into /etc/mtab, but it seems
> > > > > > > that can't happen at boot time.
> > > > > >
> > > > > > Odd. Can you disable CONFIG_NFSD_V3_ACL for now to isolate the issue?
> > > > >
> > > > > Unfortunately, that results in some problem at boot time, which
> > > > > ultimately ends up with the other three CPUs being stopped, and
> > > > > hence the original reason scrolls off the screen before it can be
> > > > > read... even at 1920p.
> > > > >
> > > > Hi Russell,
> > > >
> > > > The following patch fixes the issue for me.
> > >
> > > It doesn't entirely fix the issue for me, instead we've got even weirder
> > > behaviour:
> > >
> > > root at cubox-i4:~# ls -al test
> > > ls: cannot access test: No such file or directory
> > > root at cubox-i4:~# touch test
> > > root at cubox-i4:~# ls -al test
> > > -rw-r--r-- 1 root root 0 Feb 1 01:01 test
> > > root at cubox-i4:~# echo foo > test
> > > root at cubox-i4:~# ls -al test
> > > -rw-r--r-- 1 root root 4 Feb 1 01:01 test
> > > root at cubox-i4:~# cat test
> > > foo
> > > root at cubox-i4:~# rm test
> > > root at cubox-i4:~# echo foo > test
> > > -bash: test: Operation not supported
> > > root at cubox-i4:~# ls -al test
> > > -rw-r--r-- 1 root root 0 Feb 1 01:01 test
> >
> > FYI, I just tested Linus' tip, and NFS is still broken.
> >
> Hi Russell,
>
> The following patch should fix the above problem. It needs to be applied
> on top of the one I sent you previously.
I've hit the same problem, and your two patches seem fixing it.
I tested them on top of 3.14-rc1. Feel free to take my tested-by tag
Tested-by: Takashi Iwai <tiwai@suse.de>
> In addition, you will want to
> apply Noah Massey's patch from
> http://lkml.kernel.org/r/1391135472-9639-1-git-send-email-Noah.Massey at gmail.com
Do I still need to test this one, too?
Thanks!
Takashi
^ permalink raw reply
* [PATCH 08/18] mfd: max14577: Rename state container to maxim_core
From: Lee Jones @ 2014-02-03 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390911522-28209-9-git-send-email-k.kozlowski@samsung.com>
> This patch continues the preparation for adding support for max77836
> device to existing max14577 driver.
>
> The patch renames the struct "max14577" state container to "maxim_core".
> This is only a rename-like patch, new code is not added.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/extcon/extcon-max14577.c | 22 +++++------
> drivers/mfd/max14577.c | 68 +++++++++++++++++-----------------
> drivers/power/max14577_charger.c | 16 ++++----
> drivers/regulator/max14577.c | 6 +--
> include/linux/mfd/max14577-private.h | 5 ++-
> 5 files changed, 60 insertions(+), 57 deletions(-)
Need some more maintainer Acks here.
> -struct max14577 {
> +/*
> + * State container for max14577-like drivers.
> + */
I don't think this comment is required.
Besides that, the code looks fine:
Acked-by: Lee Jones <lee.jones@linaro.org>
> +struct maxim_core {
> struct device *dev;
> struct i2c_client *i2c; /* Slave addr = 0x4A */
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ 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