* [PATCH v3 6/6] ARM: dts: bcm283x: add pinctrl group to &sdhci, drop pins from &gpio
From: Stefan Wahren @ 2016-09-16 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473841415-937-7-git-send-email-kraxel@redhat.com>
Hi Gerd,
> Gerd Hoffmann <kraxel@redhat.com> hat am 14. September 2016 um 10:23
> geschrieben:
>
>
> As the alt3 group has no pins left after this
> update drop the whole alt3 group from &gpio.
sorry it won't be that simple. The references needs to removed too :-(
> grep alt3 *.dts*
bcm2835-rpi-a.dts: pinctrl-0 = <&gpioout &alt0 &i2s_alt2 &alt3>;
bcm2835-rpi-a-plus.dts: pinctrl-0 = <&gpioout &alt0 &i2s_alt0 &alt3>;
bcm2835-rpi-b.dts: pinctrl-0 = <&gpioout &alt0 &alt3>;
bcm2835-rpi-b-plus.dts: pinctrl-0 = <&gpioout &alt0 &i2s_alt0 &alt3>;
bcm2835-rpi-b-rev2.dts: pinctrl-0 = <&gpioout &alt0 &i2s_alt2 &alt3>;
bcm2835-rpi.dtsi: alt3: alt3 {
bcm2835-rpi-zero.dts: pinctrl-0 = <&gpioout &alt0 &i2s_alt0 &alt3>;
bcm2836-rpi-2-b.dts: pinctrl-0 = <&gpioout &alt0 &i2s_alt0 &alt3>;
Regards
Stefan
^ permalink raw reply
* [PATCH 5/6] arm/arm64: vgic-new: Implement VGICv3 CPU interface access
From: Vijay Kilari @ 2016-09-16 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DC0366.8060304@arm.com>
On Fri, Sep 16, 2016 at 8:06 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 16/09/16 13:20, vijay.kilari at gmail.com wrote:
>> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>>
>> VGICv3 CPU interface registers are accessed using
>> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
>> as 64-bit. The cpu MPIDR value is passed along with register id.
>> is used to identify the cpu for registers access.
>>
>> The version of VGIC v3 specification is define here
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>>
>> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> ---
>> arch/arm64/include/uapi/asm/kvm.h | 3 +
>> arch/arm64/kvm/Makefile | 1 +
>> include/linux/irqchip/arm-gic-v3.h | 30 ++++
>> virt/kvm/arm/vgic/vgic-kvm-device.c | 27 ++++
>> virt/kvm/arm/vgic/vgic-mmio-v3.c | 18 +++
>> virt/kvm/arm/vgic/vgic-sys-reg-v3.c | 296 ++++++++++++++++++++++++++++++++++++
>> virt/kvm/arm/vgic/vgic.h | 10 ++
>> 7 files changed, 385 insertions(+)
>>
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> index 56dc08d..91c7137 100644
>> --- a/arch/arm64/include/uapi/asm/kvm.h
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -206,9 +206,12 @@ struct kvm_arch_memory_slot {
>> (0xffffffffULL << KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT)
>> #define KVM_DEV_ARM_VGIC_OFFSET_SHIFT 0
>> #define KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
>> +#define KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK (0xffff)
>> #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
>> #define KVM_DEV_ARM_VGIC_GRP_CTRL 4
>> #define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
>> +#define KVM_DEV_ARM_VGIC_CPU_SYSREGS 6
>> +
>> #define KVM_DEV_ARM_VGIC_CTRL_INIT 0
>>
>> /* Device Control API on vcpu fd */
>> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
>> index d50a82a..1a14e29 100644
>> --- a/arch/arm64/kvm/Makefile
>> +++ b/arch/arm64/kvm/Makefile
>> @@ -32,5 +32,6 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-mmio-v3.o
>> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-kvm-device.o
>> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-its.o
>> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/irqchip.o
>> +kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-sys-reg-v3.o
>> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/arch_timer.o
>> kvm-$(CONFIG_KVM_ARM_PMU) += $(KVM)/arm/pmu.o
>> diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
>> index 88d83d3..d4e9c7d 100644
>> --- a/include/linux/irqchip/arm-gic-v3.h
>> +++ b/include/linux/irqchip/arm-gic-v3.h
>> @@ -355,6 +355,27 @@
>> #define ICC_CTLR_EL1_EOImode_SHIFT (1)
>> #define ICC_CTLR_EL1_EOImode_drop_dir (0U << ICC_CTLR_EL1_EOImode_SHIFT)
>> #define ICC_CTLR_EL1_EOImode_drop (1U << ICC_CTLR_EL1_EOImode_SHIFT)
>> +#define ICC_CTLR_EL1_EOImode_MASK (1 << ICC_CTLR_EL1_EOImode_SHIFT)
>> +#define ICC_CTLR_EL1_CBPR_SHIFT (0)
>> +#define ICC_CTLR_EL1_CBPR_MASK (1 << ICC_CTLR_EL1_CBPR_SHIFT)
>> +#define ICC_CTLR_EL1_PRI_BITS_SHIFT (8)
>> +#define ICC_CTLR_EL1_PRI_BITS_MASK (0x7 << ICC_CTLR_EL1_PRI_BITS_SHIFT)
>> +#define ICC_CTLR_EL1_ID_BITS_SHIFT (11)
>> +#define ICC_CTLR_EL1_ID_BITS_MASK (0x7 << ICC_CTLR_EL1_ID_BITS_SHIFT)
>> +#define ICC_CTLR_EL1_SEIS_SHIFT (14)
>> +#define ICC_CTLR_EL1_SEIS_MASK (0x1 << ICC_CTLR_EL1_SEIS_SHIFT)
>> +#define ICC_CTLR_EL1_A3V_SHIFT (15)
>> +#define ICC_CTLR_EL1_A3V_MASK (0x1 << ICC_CTLR_EL1_A3V_SHIFT)
>> +#define ICC_PMR_EL1_SHIFT (0)
>> +#define ICC_PMR_EL1_MASK (0xff << ICC_PMR_EL1_SHIFT)
>> +#define ICC_BPR0_EL1_SHIFT (0)
>> +#define ICC_BPR0_EL1_MASK (0x7 << ICC_BPR0_EL1_SHIFT)
>> +#define ICC_BPR1_EL1_SHIFT (0)
>> +#define ICC_BPR1_EL1_MASK (0x7 << ICC_BPR1_EL1_SHIFT)
>> +#define ICC_IGRPEN0_EL1_SHIFT (0)
>> +#define ICC_IGRPEN0_EL1_MASK (1 << ICC_IGRPEN0_EL1_SHIFT)
>> +#define ICC_IGRPEN1_EL1_SHIFT (0)
>> +#define ICC_IGRPEN1_EL1_MASK (1 << ICC_IGRPEN1_EL1_SHIFT)
>> #define ICC_SRE_EL1_SRE (1U << 0)
>>
>> /*
>> @@ -398,6 +419,15 @@
>> #define ICH_VMCR_ENG1_SHIFT 1
>> #define ICH_VMCR_ENG1_MASK (1 << ICH_VMCR_ENG1_SHIFT)
>>
>> +#define ICH_VTR_PRI_BITS_SHIFT 29
>> +#define ICH_VTR_PRI_BITS_MASK (7 << ICH_VTR_PRI_BITS_SHIFT)
>> +#define ICH_VTR_ID_BITS_SHIFT 23
>> +#define ICH_VTR_ID_BITS_MASK (7 << ICH_VTR_ID_BITS_SHIFT)
>> +#define ICH_VTR_SEIS_SHIFT 22
>> +#define ICH_VTR_SEIS_MASK (1 << ICH_VTR_SEIS_SHIFT)
>> +#define ICH_VTR_A3V_SHIFT 21
>> +#define ICH_VTR_A3V_MASK (1 << ICH_VTR_A3V_SHIFT)
>> +
>
> Same thing here. Please group all the additions to this file into a
> single, independent patch.
>
>> #define ICC_IAR1_EL1_SPURIOUS 0x3ff
>>
>> #define ICC_SRE_EL2_SRE (1 << 0)
>> diff --git a/virt/kvm/arm/vgic/vgic-kvm-device.c b/virt/kvm/arm/vgic/vgic-kvm-device.c
>> index a4656fc..a48101f 100644
>> --- a/virt/kvm/arm/vgic/vgic-kvm-device.c
>> +++ b/virt/kvm/arm/vgic/vgic-kvm-device.c
>> @@ -506,6 +506,14 @@ static int vgic_v3_attr_regs_access(struct kvm_device *dev,
>> if (!is_write)
>> *reg = tmp32;
>> break;
>> + case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
>> + u64 regid;
>> +
>> + regid = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK);
>> + ret = vgic_v3_cpu_sysregs_uaccess(vcpu, is_write,
>> + regid, reg);
>> + break;
>> + }
>> default:
>> ret = -EINVAL;
>> break;
>> @@ -539,6 +547,15 @@ static int vgic_v3_set_attr(struct kvm_device *dev,
>> reg = tmp32;
>> return vgic_v3_attr_regs_access(dev, attr, ®, true);
>> }
>> + case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
>> + u64 __user *uaddr = (u64 __user *)(long)attr->addr;
>> + u64 reg;
>> +
>> + if (get_user(reg, uaddr))
>> + return -EFAULT;
>> +
>> + return vgic_v3_attr_regs_access(dev, attr, ®, true);
>> + }
>> }
>> return -ENXIO;
>> }
>> @@ -565,6 +582,15 @@ static int vgic_v3_get_attr(struct kvm_device *dev,
>> tmp32 = reg;
>> return put_user(tmp32, uaddr);
>> }
>> + case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
>> + u64 __user *uaddr = (u64 __user *)(long)attr->addr;
>> + u64 reg;
>> +
>> + ret = vgic_v3_attr_regs_access(dev, attr, ®, false);
>> + if (ret)
>> + return ret;
>> + return put_user(reg, uaddr);
>> + }
>> }
>>
>> return -ENXIO;
>> @@ -583,6 +609,7 @@ static int vgic_v3_has_attr(struct kvm_device *dev,
>> break;
>> case KVM_DEV_ARM_VGIC_GRP_DIST_REGS:
>> case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS:
>> + case KVM_DEV_ARM_VGIC_CPU_SYSREGS:
>> return vgic_v3_has_attr_regs(dev, attr);
>> case KVM_DEV_ARM_VGIC_GRP_NR_IRQS:
>> return 0;
>> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> index 83dece8..af748d7 100644
>> --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> @@ -23,6 +23,7 @@
>>
>> #include "vgic.h"
>> #include "vgic-mmio.h"
>> +#include "sys_regs.h"
>>
>> /* extract @num bytes at @offset bytes offset in data */
>> unsigned long extract_bytes(u64 data, unsigned int offset,
>> @@ -639,6 +640,23 @@ int vgic_v3_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr)
>> nr_regions = ARRAY_SIZE(vgic_v3_rdbase_registers);
>> break;
>> }
>> + case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
>> + u64 reg, id;
>> + unsigned long mpidr;
>> + struct kvm_vcpu *vcpu;
>> +
>> + mpidr = (attr->attr & KVM_DEV_ARM_VGIC_V3_MPIDR_MASK) >>
>> + KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT;
>> +
>> + vcpu = kvm_mpidr_to_vcpu(dev->kvm, mpidr);
>
> No. Your "mpidr" variable is not an MPIDR. It represents the same
> thing, but not with the right format.
Ok. I will format in the form of MPIDR reg.
>
>> + if (!vcpu)
>> + return -EINVAL;
>> + if (vcpu->vcpu_id >= atomic_read(&dev->kvm->online_vcpus))
>
> How can that happen?
OK. This check can be dropped as kvm_for_each_vcpu() already checks
for only online_vcpus.
>
>> + return -EINVAL;
>> +
>> + id = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK);
>> + return vgic_v3_has_cpu_sysregs_attr(vcpu, 0, id, ®);
>> + }
>> default:
>> return -ENXIO;
>> }
>> diff --git a/virt/kvm/arm/vgic/vgic-sys-reg-v3.c b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
>> new file mode 100644
>> index 0000000..8e4f403
>> --- /dev/null
>> +++ b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
>> @@ -0,0 +1,296 @@
>> +#include <linux/irqchip/arm-gic-v3.h>
>> +#include <linux/kvm.h>
>> +#include <linux/kvm_host.h>
>> +#include <kvm/iodev.h>
>> +#include <kvm/arm_vgic.h>
>> +#include <asm/kvm_emulate.h>
>> +#include <asm/kvm_arm.h>
>> +#include <asm/kvm_mmu.h>
>> +
>> +#include "vgic.h"
>> +#include "vgic-mmio.h"
>> +#include "sys_regs.h"
>> +
>> +static bool access_gic_ctlr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> + const struct sys_reg_desc *r)
>> +{
>> + struct vgic_vmcr vmcr;
>> + u64 val;
>> + u32 ich_vtr;
>> +
>> + vgic_get_vmcr(vcpu, &vmcr);
>> + if (p->is_write) {
>> + val = p->regval;
>> + vmcr.ctlr &= ~(ICH_VMCR_CBPR_MASK | ICH_VMCR_EOIM_MASK);
>> + vmcr.ctlr |= ((val & ICC_CTLR_EL1_CBPR_MASK) >>
>> + ICC_CTLR_EL1_CBPR_SHIFT) << ICH_VMCR_CBPR_SHIFT;
>> + vmcr.ctlr |= ((val & ICC_CTLR_EL1_EOImode_MASK) >>
>> + ICC_CTLR_EL1_EOImode_SHIFT) << ICH_VMCR_EOIM_SHIFT;
>> + vgic_set_vmcr(vcpu, &vmcr);
>
> You've ignored my comments again: "What if userspace writes something
> that is incompatible with the current configuration? Wrong number of ID
> bits, or number of priorities?"
IMO, In case of incompatibility,
If ID bits and PRI bits are less than HW supported, it is ok.
If ID bits and PRI bits are greater than HW supported, then warn would be good
enough. Please suggest the behaviour that you think it should be.
>
>> + } else {
>> + ich_vtr = kvm_call_hyp(__vgic_v3_get_ich_vtr_el2);
>> +
>> + val = 0;
>> + val |= ((ich_vtr & ICH_VTR_PRI_BITS_MASK) >>
>> + ICH_VTR_PRI_BITS_SHIFT) << ICC_CTLR_EL1_PRI_BITS_SHIFT;
>> + val |= ((ich_vtr & ICH_VTR_ID_BITS_MASK) >>
>> + ICH_VTR_ID_BITS_SHIFT) << ICC_CTLR_EL1_ID_BITS_SHIFT;
>> + val |= ((ich_vtr & ICH_VTR_SEIS_MASK) >> ICH_VTR_SEIS_SHIFT)
>> + << ICC_CTLR_EL1_SEIS_SHIFT;
>> + val |= ((ich_vtr & ICH_VTR_A3V_MASK) >> ICH_VTR_A3V_SHIFT)
>> + << ICC_CTLR_EL1_A3V_SHIFT;
>> + val |= ((vmcr.ctlr & ICH_VMCR_CBPR_MASK) >>
>> + ICH_VMCR_CBPR_SHIFT) << ICC_CTLR_EL1_CBPR_SHIFT;
>> + val |= ((vmcr.ctlr & ICH_VMCR_EOIM_MASK) >>
>> + ICH_VMCR_EOIM_SHIFT) << ICC_CTLR_EL1_EOImode_SHIFT;
>> +
>> + p->regval = val;
>> + }
>> +
>> + return true;
>> +}
>> +
>> +static bool access_gic_pmr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> + const struct sys_reg_desc *r)
>> +{
>> + struct vgic_vmcr vmcr;
>> +
>> + vgic_get_vmcr(vcpu, &vmcr);
>> + if (p->is_write) {
>> + vmcr.pmr = (p->regval & ICC_PMR_EL1_MASK) >> ICC_PMR_EL1_SHIFT;
>> + vgic_set_vmcr(vcpu, &vmcr);
>> + } else {
>> + p->regval = (vmcr.pmr << ICC_PMR_EL1_SHIFT) & ICC_PMR_EL1_MASK;
>> + }
>> +
>> + return true;
>> +}
>> +
>> +static bool access_gic_bpr0(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> + const struct sys_reg_desc *r)
>> +{
>> + struct vgic_vmcr vmcr;
>> +
>> + vgic_get_vmcr(vcpu, &vmcr);
>> + if (p->is_write) {
>> + vmcr.bpr = (p->regval & ICC_BPR0_EL1_MASK) >>
>> + ICC_BPR0_EL1_SHIFT;
>> + vgic_set_vmcr(vcpu, &vmcr);
>> + } else {
>> + p->regval = (vmcr.bpr << ICC_BPR0_EL1_SHIFT) &
>> + ICC_BPR0_EL1_MASK;
>> + }
>> +
>> + return true;
>> +}
>> +
>> +static bool access_gic_bpr1(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> + const struct sys_reg_desc *r)
>> +{
>> + struct vgic_vmcr vmcr;
>> +
>> + vgic_get_vmcr(vcpu, &vmcr);
>> + if (p->is_write) {
>> + vmcr.abpr = (p->regval & ICC_BPR1_EL1_MASK) >>
>> + ICC_BPR1_EL1_SHIFT;
>> + vgic_set_vmcr(vcpu, &vmcr);
>> + } else {
>> + p->regval = (vmcr.abpr << ICC_BPR1_EL1_SHIFT) &
>> + ICC_BPR1_EL1_MASK;
>> + }
>> +
>> + return true;
>> +}
>> +
>> +static bool access_gic_grpen0(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> + const struct sys_reg_desc *r)
>> +{
>> + struct vgic_vmcr vmcr;
>> +
>> + vgic_get_vmcr(vcpu, &vmcr);
>> + if (p->is_write) {
>> + vmcr.grpen0 = (p->regval & ICC_IGRPEN0_EL1_MASK) >>
>> + ICC_IGRPEN0_EL1_SHIFT;
>> + vgic_set_vmcr(vcpu, &vmcr);
>> + } else {
>> + p->regval = (vmcr.grpen0 << ICC_IGRPEN0_EL1_SHIFT) &
>> + ICC_IGRPEN0_EL1_MASK;
>> + }
>> +
>> + return true;
>> +}
>> +
>> +static bool access_gic_grpen1(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> + const struct sys_reg_desc *r)
>> +{
>> + struct vgic_vmcr vmcr;
>> +
>> + vgic_get_vmcr(vcpu, &vmcr);
>> + if (p->is_write) {
>> + vmcr.grpen1 = (p->regval & ICC_IGRPEN1_EL1_MASK) >>
>> + ICC_IGRPEN1_EL1_SHIFT;
>> + vgic_set_vmcr(vcpu, &vmcr);
>> + } else {
>> + p->regval = (vmcr.grpen1 << ICC_IGRPEN1_EL1_SHIFT) &
>> + ICC_IGRPEN1_EL1_MASK;
>
> From the previous review comments: "Shouldn't this account for the
> ICC_CTLR_EL1.CBPR setting?"
Ok. I think this comment is for ICC_BPR1_EL1 access.
I will make a check on ICC_CTLR.EL1.CBPR for accessing ICC_BPR1_EL1.
>
>> + }
>> +
>> + return true;
>> +}
>> +
>> +static void vgic_v3_access_apr_reg(struct kvm_vcpu *vcpu,
>> + struct sys_reg_params *p, u8 apr, u8 idx)
>> +{
>> + struct vgic_v3_cpu_if *vgicv3 = &vcpu->arch.vgic_cpu.vgic_v3;
>> + uint32_t *ap_reg;
>> +
>> + if (apr)
>> + ap_reg = &vgicv3->vgic_ap1r[idx];
>> + else
>> + ap_reg = &vgicv3->vgic_ap0r[idx];
>> +
>> + if (p->is_write)
>> + *ap_reg = p->regval;
>> + else
>> + p->regval = *ap_reg;
>> +}
>> +
>> +static void access_gic_aprn(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> + const struct sys_reg_desc *r, u8 apr)
>> +{
>> + u8 num_pri_bits, idx;
>> + u32 ich_vtr = kvm_call_hyp(__vgic_v3_get_ich_vtr_el2);
>
> Maybe you should cache this once and for all? It is fairly unlikely to
> change over time...
Is it ok to cache in vgic_global struct?
^ permalink raw reply
* [PATCH 5/6] arm/arm64: vgic-new: Implement VGICv3 CPU interface access
From: Marc Zyngier @ 2016-09-16 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALicx6u-uYLY3DtDGMh3n6NbNH3kD9fn9aYHHJC=LVUQfFjTsQ@mail.gmail.com>
On 16/09/16 17:57, Vijay Kilari wrote:
> On Fri, Sep 16, 2016 at 8:06 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> On 16/09/16 13:20, vijay.kilari at gmail.com wrote:
>>> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>>>
>>> VGICv3 CPU interface registers are accessed using
>>> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
>>> as 64-bit. The cpu MPIDR value is passed along with register id.
>>> is used to identify the cpu for registers access.
>>>
>>> The version of VGIC v3 specification is define here
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>>>
>>> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
>>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>>> ---
>>> arch/arm64/include/uapi/asm/kvm.h | 3 +
>>> arch/arm64/kvm/Makefile | 1 +
>>> include/linux/irqchip/arm-gic-v3.h | 30 ++++
>>> virt/kvm/arm/vgic/vgic-kvm-device.c | 27 ++++
>>> virt/kvm/arm/vgic/vgic-mmio-v3.c | 18 +++
>>> virt/kvm/arm/vgic/vgic-sys-reg-v3.c | 296 ++++++++++++++++++++++++++++++++++++
>>> virt/kvm/arm/vgic/vgic.h | 10 ++
>>> 7 files changed, 385 insertions(+)
[...]
>>> diff --git a/virt/kvm/arm/vgic/vgic-sys-reg-v3.c b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
>>> new file mode 100644
>>> index 0000000..8e4f403
>>> --- /dev/null
>>> +++ b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
>>> @@ -0,0 +1,296 @@
>>> +#include <linux/irqchip/arm-gic-v3.h>
>>> +#include <linux/kvm.h>
>>> +#include <linux/kvm_host.h>
>>> +#include <kvm/iodev.h>
>>> +#include <kvm/arm_vgic.h>
>>> +#include <asm/kvm_emulate.h>
>>> +#include <asm/kvm_arm.h>
>>> +#include <asm/kvm_mmu.h>
>>> +
>>> +#include "vgic.h"
>>> +#include "vgic-mmio.h"
>>> +#include "sys_regs.h"
>>> +
>>> +static bool access_gic_ctlr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>>> + const struct sys_reg_desc *r)
>>> +{
>>> + struct vgic_vmcr vmcr;
>>> + u64 val;
>>> + u32 ich_vtr;
>>> +
>>> + vgic_get_vmcr(vcpu, &vmcr);
>>> + if (p->is_write) {
>>> + val = p->regval;
>>> + vmcr.ctlr &= ~(ICH_VMCR_CBPR_MASK | ICH_VMCR_EOIM_MASK);
>>> + vmcr.ctlr |= ((val & ICC_CTLR_EL1_CBPR_MASK) >>
>>> + ICC_CTLR_EL1_CBPR_SHIFT) << ICH_VMCR_CBPR_SHIFT;
>>> + vmcr.ctlr |= ((val & ICC_CTLR_EL1_EOImode_MASK) >>
>>> + ICC_CTLR_EL1_EOImode_SHIFT) << ICH_VMCR_EOIM_SHIFT;
>>> + vgic_set_vmcr(vcpu, &vmcr);
>>
>> You've ignored my comments again: "What if userspace writes something
>> that is incompatible with the current configuration? Wrong number of ID
>> bits, or number of priorities?"
>
> IMO, In case of incompatibility,
> If ID bits and PRI bits are less than HW supported, it is ok.
Yes. But you also need to track of what the guest has programmed in
order to be able to migrate it back to its original configuration.
> If ID bits and PRI bits are greater than HW supported, then warn would be good
> enough. Please suggest the behaviour that you think it should be.
No, it is an error, plain and simple. You cannot run in this condition.
>
>>
>>> + } else {
>>> + ich_vtr = kvm_call_hyp(__vgic_v3_get_ich_vtr_el2);
>>> +
>>> + val = 0;
>>> + val |= ((ich_vtr & ICH_VTR_PRI_BITS_MASK) >>
>>> + ICH_VTR_PRI_BITS_SHIFT) << ICC_CTLR_EL1_PRI_BITS_SHIFT;
>>> + val |= ((ich_vtr & ICH_VTR_ID_BITS_MASK) >>
>>> + ICH_VTR_ID_BITS_SHIFT) << ICC_CTLR_EL1_ID_BITS_SHIFT;
>>> + val |= ((ich_vtr & ICH_VTR_SEIS_MASK) >> ICH_VTR_SEIS_SHIFT)
>>> + << ICC_CTLR_EL1_SEIS_SHIFT;
>>> + val |= ((ich_vtr & ICH_VTR_A3V_MASK) >> ICH_VTR_A3V_SHIFT)
>>> + << ICC_CTLR_EL1_A3V_SHIFT;
>>> + val |= ((vmcr.ctlr & ICH_VMCR_CBPR_MASK) >>
>>> + ICH_VMCR_CBPR_SHIFT) << ICC_CTLR_EL1_CBPR_SHIFT;
>>> + val |= ((vmcr.ctlr & ICH_VMCR_EOIM_MASK) >>
>>> + ICH_VMCR_EOIM_SHIFT) << ICC_CTLR_EL1_EOImode_SHIFT;
>>> +
>>> + p->regval = val;
>>> + }
>>> +
>>> + return true;
>>> +}
>>> +
>>> +static bool access_gic_pmr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>>> + const struct sys_reg_desc *r)
>>> +{
>>> + struct vgic_vmcr vmcr;
>>> +
>>> + vgic_get_vmcr(vcpu, &vmcr);
>>> + if (p->is_write) {
>>> + vmcr.pmr = (p->regval & ICC_PMR_EL1_MASK) >> ICC_PMR_EL1_SHIFT;
>>> + vgic_set_vmcr(vcpu, &vmcr);
>>> + } else {
>>> + p->regval = (vmcr.pmr << ICC_PMR_EL1_SHIFT) & ICC_PMR_EL1_MASK;
>>> + }
>>> +
>>> + return true;
>>> +}
>>> +
>>> +static bool access_gic_bpr0(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>>> + const struct sys_reg_desc *r)
>>> +{
>>> + struct vgic_vmcr vmcr;
>>> +
>>> + vgic_get_vmcr(vcpu, &vmcr);
>>> + if (p->is_write) {
>>> + vmcr.bpr = (p->regval & ICC_BPR0_EL1_MASK) >>
>>> + ICC_BPR0_EL1_SHIFT;
>>> + vgic_set_vmcr(vcpu, &vmcr);
>>> + } else {
>>> + p->regval = (vmcr.bpr << ICC_BPR0_EL1_SHIFT) &
>>> + ICC_BPR0_EL1_MASK;
>>> + }
>>> +
>>> + return true;
>>> +}
>>> +
>>> +static bool access_gic_bpr1(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>>> + const struct sys_reg_desc *r)
>>> +{
>>> + struct vgic_vmcr vmcr;
>>> +
>>> + vgic_get_vmcr(vcpu, &vmcr);
>>> + if (p->is_write) {
>>> + vmcr.abpr = (p->regval & ICC_BPR1_EL1_MASK) >>
>>> + ICC_BPR1_EL1_SHIFT;
>>> + vgic_set_vmcr(vcpu, &vmcr);
>>> + } else {
>>> + p->regval = (vmcr.abpr << ICC_BPR1_EL1_SHIFT) &
>>> + ICC_BPR1_EL1_MASK;
>>> + }
>>> +
>>> + return true;
>>> +}
>>> +
>>> +static bool access_gic_grpen0(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>>> + const struct sys_reg_desc *r)
>>> +{
>>> + struct vgic_vmcr vmcr;
>>> +
>>> + vgic_get_vmcr(vcpu, &vmcr);
>>> + if (p->is_write) {
>>> + vmcr.grpen0 = (p->regval & ICC_IGRPEN0_EL1_MASK) >>
>>> + ICC_IGRPEN0_EL1_SHIFT;
>>> + vgic_set_vmcr(vcpu, &vmcr);
>>> + } else {
>>> + p->regval = (vmcr.grpen0 << ICC_IGRPEN0_EL1_SHIFT) &
>>> + ICC_IGRPEN0_EL1_MASK;
>>> + }
>>> +
>>> + return true;
>>> +}
>>> +
>>> +static bool access_gic_grpen1(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>>> + const struct sys_reg_desc *r)
>>> +{
>>> + struct vgic_vmcr vmcr;
>>> +
>>> + vgic_get_vmcr(vcpu, &vmcr);
>>> + if (p->is_write) {
>>> + vmcr.grpen1 = (p->regval & ICC_IGRPEN1_EL1_MASK) >>
>>> + ICC_IGRPEN1_EL1_SHIFT;
>>> + vgic_set_vmcr(vcpu, &vmcr);
>>> + } else {
>>> + p->regval = (vmcr.grpen1 << ICC_IGRPEN1_EL1_SHIFT) &
>>> + ICC_IGRPEN1_EL1_MASK;
>>
>> From the previous review comments: "Shouldn't this account for the
>> ICC_CTLR_EL1.CBPR setting?"
>
> Ok. I think this comment is for ICC_BPR1_EL1 access.
Yes, sorry about the misplaced comment.
> I will make a check on ICC_CTLR.EL1.CBPR for accessing ICC_BPR1_EL1.
The reverse is also true: you also need to account the value of
ICC_BPR1_EL1 when accessing ICC_CTLR_EL1.
>>
>>> + }
>>> +
>>> + return true;
>>> +}
>>> +
>>> +static void vgic_v3_access_apr_reg(struct kvm_vcpu *vcpu,
>>> + struct sys_reg_params *p, u8 apr, u8 idx)
>>> +{
>>> + struct vgic_v3_cpu_if *vgicv3 = &vcpu->arch.vgic_cpu.vgic_v3;
>>> + uint32_t *ap_reg;
>>> +
>>> + if (apr)
>>> + ap_reg = &vgicv3->vgic_ap1r[idx];
>>> + else
>>> + ap_reg = &vgicv3->vgic_ap0r[idx];
>>> +
>>> + if (p->is_write)
>>> + *ap_reg = p->regval;
>>> + else
>>> + p->regval = *ap_reg;
>>> +}
>>> +
>>> +static void access_gic_aprn(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>>> + const struct sys_reg_desc *r, u8 apr)
>>> +{
>>> + u8 num_pri_bits, idx;
>>> + u32 ich_vtr = kvm_call_hyp(__vgic_v3_get_ich_vtr_el2);
>>
>> Maybe you should cache this once and for all? It is fairly unlikely to
>> change over time...
>
> Is it ok to cache in vgic_global struct?
I can't see why not.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] coresight: tmc: Cleanup operation mode handling
From: Mathieu Poirier @ 2016-09-16 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473861230-5666-1-git-send-email-suzuki.poulose@arm.com>
On 14 September 2016 at 07:53, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> The mode of operation of the TMC tracked in drvdata->mode is defined
> as a local_t type. This is always checked and modified under the
> drvdata->spinlock and hence we don't need local_t for it and the
> unnecessary synchronisation instructions that comes with it. This
> change makes the code a bit more cleaner.
>
> Also fixes the order in which we update the drvdata->mode to
> CS_MODE_DISABLED. i.e, in tmc_disable_etX_sink we change the
> mode to CS_MODE_DISABLED before invoking tmc_disable_etX_hw()
> which in turn depends on the mode to decide whether to dump the
> trace to a buffer.
Thank you for the patch - just a few comments below.
Regards,
Mathieu
>
> Applies on mathieu's coresight/next tree [1]
>
> https://git.linaro.org/kernel/coresight.git next
>
> Reported-by: Venkatesh Vivekanandan <venkatesh.vivekanandan@broadcom.com>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-tmc-etf.c | 32 +++++++++++--------------
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 30 ++++++++++-------------
> drivers/hwtracing/coresight/coresight-tmc.h | 2 +-
> 3 files changed, 28 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> index d6941ea..c51ce45 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> @@ -70,7 +70,7 @@ static void tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
> * When operating in sysFS mode the content of the buffer needs to be
> * read before the TMC is disabled.
> */
> - if (local_read(&drvdata->mode) == CS_MODE_SYSFS)
> + if (drvdata->mode == CS_MODE_SYSFS)
> tmc_etb_dump_hw(drvdata);
> tmc_disable_hw(drvdata);
>
> @@ -108,7 +108,6 @@ static int tmc_enable_etf_sink_sysfs(struct coresight_device *csdev, u32 mode)
> int ret = 0;
> bool used = false;
> char *buf = NULL;
> - long val;
> unsigned long flags;
> struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> @@ -138,13 +137,12 @@ static int tmc_enable_etf_sink_sysfs(struct coresight_device *csdev, u32 mode)
> goto out;
> }
>
> - val = local_xchg(&drvdata->mode, mode);
> /*
> * In sysFS mode we can have multiple writers per sink. Since this
> * sink is already enabled no memory is needed and the HW need not be
> * touched.
> */
> - if (val == CS_MODE_SYSFS)
> + if (drvdata->mode == CS_MODE_SYSFS)
> goto out;
>
> /*
> @@ -163,6 +161,7 @@ static int tmc_enable_etf_sink_sysfs(struct coresight_device *csdev, u32 mode)
> drvdata->buf = buf;
> }
>
> + drvdata->mode = CS_MODE_SYSFS;
> tmc_etb_enable_hw(drvdata);
> out:
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
> @@ -180,7 +179,6 @@ out:
> static int tmc_enable_etf_sink_perf(struct coresight_device *csdev, u32 mode)
> {
> int ret = 0;
> - long val;
> unsigned long flags;
> struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> @@ -194,17 +192,17 @@ static int tmc_enable_etf_sink_perf(struct coresight_device *csdev, u32 mode)
> goto out;
> }
>
> - val = local_xchg(&drvdata->mode, mode);
> /*
> * In Perf mode there can be only one writer per sink. There
> * is also no need to continue if the ETB/ETR is already operated
> * from sysFS.
> */
> - if (val != CS_MODE_DISABLED) {
> + if (drvdata->mode != CS_MODE_DISABLED) {
> ret = -EINVAL;
> goto out;
> }
>
> + drvdata->mode = mode;
Given the way tmc_enable_etf_sink_perf() is called in
tmc_enable_etf_sink(), I think it is time to get rid of the 'mode'
parameter - it doesn't do anything nowadays. Same thing for
tmc_enable_etf_sink_sysfs() and ETR.
> tmc_etb_enable_hw(drvdata);
> out:
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
> @@ -227,7 +225,6 @@ static int tmc_enable_etf_sink(struct coresight_device *csdev, u32 mode)
>
> static void tmc_disable_etf_sink(struct coresight_device *csdev)
> {
> - long val;
> unsigned long flags;
> struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> @@ -237,10 +234,11 @@ static void tmc_disable_etf_sink(struct coresight_device *csdev)
> return;
> }
>
> - val = local_xchg(&drvdata->mode, CS_MODE_DISABLED);
> /* Disable the TMC only if it needs to */
> - if (val != CS_MODE_DISABLED)
> + if (drvdata->mode != CS_MODE_DISABLED) {
> tmc_etb_disable_hw(drvdata);
> + drvdata->mode = CS_MODE_DISABLED;
> + }
>
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> @@ -260,7 +258,7 @@ static int tmc_enable_etf_link(struct coresight_device *csdev,
> }
>
> tmc_etf_enable_hw(drvdata);
> - local_set(&drvdata->mode, CS_MODE_SYSFS);
> + drvdata->mode = CS_MODE_SYSFS;
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> dev_info(drvdata->dev, "TMC-ETF enabled\n");
> @@ -279,8 +277,8 @@ static void tmc_disable_etf_link(struct coresight_device *csdev,
> return;
> }
>
> + drvdata->mode = CS_MODE_DISABLED;
> tmc_etf_disable_hw(drvdata);
> - local_set(&drvdata->mode, CS_MODE_DISABLED);
I think setting the mode should come after tmc_etf_disable_hw(), as it
was before.
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> dev_info(drvdata->dev, "TMC disabled\n");
> @@ -383,7 +381,7 @@ static void tmc_update_etf_buffer(struct coresight_device *csdev,
> return;
>
> /* This shouldn't happen */
> - if (WARN_ON_ONCE(local_read(&drvdata->mode) != CS_MODE_PERF))
> + if (WARN_ON_ONCE(drvdata->mode != CS_MODE_PERF))
> return;
>
> CS_UNLOCK(drvdata->base);
> @@ -504,7 +502,6 @@ const struct coresight_ops tmc_etf_cs_ops = {
>
> int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
> {
> - long val;
> enum tmc_mode mode;
> int ret = 0;
> unsigned long flags;
> @@ -528,9 +525,8 @@ int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
> goto out;
> }
>
> - val = local_read(&drvdata->mode);
> /* Don't interfere if operated from Perf */
> - if (val == CS_MODE_PERF) {
> + if (drvdata->mode == CS_MODE_PERF) {
> ret = -EINVAL;
> goto out;
> }
> @@ -542,7 +538,7 @@ int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
> }
>
> /* Disable the TMC if need be */
> - if (val == CS_MODE_SYSFS)
> + if (drvdata->mode == CS_MODE_SYSFS)
> tmc_etb_disable_hw(drvdata);
>
> drvdata->reading = true;
> @@ -573,7 +569,7 @@ int tmc_read_unprepare_etb(struct tmc_drvdata *drvdata)
> }
>
> /* Re-enable the TMC if need be */
> - if (local_read(&drvdata->mode) == CS_MODE_SYSFS) {
> + if (drvdata->mode == CS_MODE_SYSFS) {
> /*
> * The trace run will continue with the same allocated trace
> * buffer. As such zero-out the buffer so that we don't end
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index 886ea83..cf2bf60 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -86,7 +86,7 @@ static void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
> * When operating in sysFS mode the content of the buffer needs to be
> * read before the TMC is disabled.
> */
> - if (local_read(&drvdata->mode) == CS_MODE_SYSFS)
> + if (drvdata->mode == CS_MODE_SYSFS)
> tmc_etr_dump_hw(drvdata);
> tmc_disable_hw(drvdata);
>
> @@ -97,7 +97,6 @@ static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev, u32 mode)
> {
> int ret = 0;
> bool used = false;
> - long val;
> unsigned long flags;
> void __iomem *vaddr = NULL;
> dma_addr_t paddr;
> @@ -134,13 +133,12 @@ static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev, u32 mode)
> goto out;
> }
>
> - val = local_xchg(&drvdata->mode, mode);
> /*
> * In sysFS mode we can have multiple writers per sink. Since this
> * sink is already enabled no memory is needed and the HW need not be
> * touched.
> */
> - if (val == CS_MODE_SYSFS)
> + if (drvdata->mode == CS_MODE_SYSFS)
> goto out;
>
> /*
> @@ -157,6 +155,7 @@ static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev, u32 mode)
>
> memset(drvdata->vaddr, 0, drvdata->size);
>
> + drvdata->mode = CS_MODE_SYSFS;
> tmc_etr_enable_hw(drvdata);
> out:
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
> @@ -174,7 +173,6 @@ out:
> static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, u32 mode)
> {
> int ret = 0;
> - long val;
> unsigned long flags;
> struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> @@ -188,18 +186,18 @@ static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, u32 mode)
> goto out;
> }
>
> - val = local_xchg(&drvdata->mode, mode);
> /*
> * In Perf mode there can be only one writer per sink. There
> * is also no need to continue if the ETR is already operated
> * from sysFS.
> */
> - if (val != CS_MODE_DISABLED) {
> + if (drvdata->mode == CS_MODE_DISABLED) {
> + drvdata->mode = CS_MODE_PERF;
> + tmc_etr_enable_hw(drvdata);
> + } else {
> ret = -EINVAL;
> - goto out;
> }
>
> - tmc_etr_enable_hw(drvdata);
Is there a reason for not proceeding the same way as in
tmc_enable_etr_sink_perf()? I thought that was a better approach.
> out:
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> @@ -221,7 +219,6 @@ static int tmc_enable_etr_sink(struct coresight_device *csdev, u32 mode)
>
> static void tmc_disable_etr_sink(struct coresight_device *csdev)
> {
> - long val;
> unsigned long flags;
> struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> @@ -231,10 +228,11 @@ static void tmc_disable_etr_sink(struct coresight_device *csdev)
> return;
> }
>
> - val = local_xchg(&drvdata->mode, CS_MODE_DISABLED);
> /* Disable the TMC only if it needs to */
> - if (val != CS_MODE_DISABLED)
> + if (drvdata->mode != CS_MODE_DISABLED) {
> tmc_etr_disable_hw(drvdata);
> + drvdata->mode = CS_MODE_DISABLED;
> + }
>
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> @@ -253,7 +251,6 @@ const struct coresight_ops tmc_etr_cs_ops = {
> int tmc_read_prepare_etr(struct tmc_drvdata *drvdata)
> {
> int ret = 0;
> - long val;
> unsigned long flags;
>
> /* config types are set a boot time and never change */
> @@ -266,9 +263,8 @@ int tmc_read_prepare_etr(struct tmc_drvdata *drvdata)
> goto out;
> }
>
> - val = local_read(&drvdata->mode);
> /* Don't interfere if operated from Perf */
> - if (val == CS_MODE_PERF) {
> + if (drvdata->mode == CS_MODE_PERF) {
> ret = -EINVAL;
> goto out;
> }
> @@ -280,7 +276,7 @@ int tmc_read_prepare_etr(struct tmc_drvdata *drvdata)
> }
>
> /* Disable the TMC if need be */
> - if (val == CS_MODE_SYSFS)
> + if (drvdata->mode == CS_MODE_SYSFS)
> tmc_etr_disable_hw(drvdata);
>
> drvdata->reading = true;
> @@ -303,7 +299,7 @@ int tmc_read_unprepare_etr(struct tmc_drvdata *drvdata)
> spin_lock_irqsave(&drvdata->spinlock, flags);
>
> /* RE-enable the TMC if need be */
> - if (local_read(&drvdata->mode) == CS_MODE_SYSFS) {
> + if (drvdata->mode == CS_MODE_SYSFS) {
> /*
> * The trace run will continue with the same allocated trace
> * buffer. The trace buffer is cleared in tmc_etr_enable_hw(),
> diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
> index 44b3ae3..51c0185 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc.h
> +++ b/drivers/hwtracing/coresight/coresight-tmc.h
> @@ -117,7 +117,7 @@ struct tmc_drvdata {
> void __iomem *vaddr;
> u32 size;
> u32 len;
> - local_t mode;
> + u32 mode;
> enum tmc_config_type config_type;
> enum tmc_mem_intf_width memwidth;
> u32 trigger_cntr;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v9 08/10] arm64: pmu: Detect and enable multiple PMUs in an ACPI system
From: Punit Agrawal @ 2016-09-16 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6e0b08db-2e13-be49-5208-c396bf51fe68@arm.com>
Jeremy Linton <jeremy.linton@arm.com> writes:
> Hi,
>
> On 09/16/2016 08:33 AM, Punit Agrawal wrote:
>> Jeremy Linton <jeremy.linton@arm.com> writes:
>>
>>> Its possible that an ACPI system has multiple CPU types in it
>>> with differing PMU counters. Iterate the CPU's and make a determination
>>> about how many of each type exist in the system. Then take and create
>>> a PMU platform device for each type, and assign it the interrupts parsed
>>> from the MADT. Creating a platform device is necessary because the PMUs
>>> are not described as devices in the DSDT table.
>>>
>>> This code is loosely based on earlier work by Mark Salter.
>
> (trimming)
>
>>> +
>>> + list_for_each_entry_safe(pmu, safe_temp, &pmus, list) {
>>> + if (unused_madt_entries)
>>> + pmu->cpu_count = num_possible_cpus();
>>
>> So if there is any unbooted cpu ...
>>
>>> +
>>> + res = kcalloc(pmu->cpu_count,
>>> + sizeof(struct resource), GFP_KERNEL);
>>
>> ... we allocate potentially large number (num_possible_cpus()) of
>> resources for each PMU.
>>
>> This is needlessly wasteful. Under what conditions have you found
>> reg_midr to be 0?
>
> Unused MADT entries, in place for potentially unbooted/hotplug
> CPUs.
Is linux able to deal with booting secondaries that have unused MADT
entries?
> In those cases you don't know for sure which PMU the CPU belongs
> to until it comes online and the MIDR can be read. I'm open to
> suggestions on how to deal with this, outside of pushing my luck and
> further breaking the platform device encapsulation by trying to
> reallocate the resource structure while its active. Besides its only
> wasteful for ACPI+big.little, which at the moment only applies to a
> development platform.
I don't have any ideas to solve this problem, but in the interest of
helping review, please move all the changes arising from hotplug/unused
MADT entries in this patch to the next one.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 1/3] tty: amba-pl011: define flag register bits for ZTE device
From: Timur Tabi @ 2016-09-16 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916163952.GH1041@n2100.armlinux.org.uk>
Russell King - ARM Linux wrote:
> Maybe what we should've done with ZTE is insisted that they implement
> a complete new driver, rather than trying to shoe-horn it into PL011
> even though it is in theory PL011.
When I suggested that a year ago, I was shot down:
http://www.spinics.net/lists/arm-kernel/msg455888.html
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v9 00/10] Enable PMUs in ACPI systems
From: Punit Agrawal @ 2016-09-16 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473892358-22574-1-git-send-email-jeremy.linton@arm.com>
Hi Jeremy,
Jeremy Linton <jeremy.linton@arm.com> writes:
> This patch expands and reworks the patches published by Mark Salter
> in order to clean up a few of the previous review comments, as well as
> add support for newer CPUs and big/little configurations.
>
> v9:
> Add/cleanup an additional hotplug patch I've had sitting around. This
> patch brings the ACPI PMU mostly on par with the DT functionality with
> respect to having CPUs offline during boot. This should help clarify
> some of the code structuring.
> Cleanup the list of PMU types early if we fail to allocate memory for an
> additional pmu type.
The earlier patches in the series look OK but there are still
unaddressed comments on Patch 8 from previous versions - coding style,
excessive indentation, complicated logic etc.
Additionally, I'd suggest moving hotplug/unsed MADT related changes out
of Patch 8 to later patches, i.e., add support for hotplug on top.
Thanks,
Punit
>
> v8:
> Rebase to 4.8rc4
> Assorted minor comment/hunk placement/etc tweaks per Punit Agrawal
>
> v7:
> Rebase to 4.8rc3
> Remove cpu affinity sysfs entry. While providing a CPU mask for
> ARMv8 PMU's is really helpful in big/little environments, reworking
> the PMU code to support the cpumask attribute for !arm64 PMUs is out
> of the scope of this patch set.
> Fix CPU miscount problem where an alloc failure followed by successfully
> allocating the structure can result in under counting the CPUs associated
> with the PMU. This bug was created in v6 with the conversion to a linked
> list.
> Remove initial platform device creation code by Mark Salter, and re-squash
> multiple platform device creation code together with helper routines.
> Other minor tweakage.
>
> v6:
> Added cpu affinity sysfs entry
> Converted pmu_types array, to linked list
> Restrict use of the armv8_pmu_probe_table to ACPI systems
> Rename MADT parsing routines in smp.c
> Convert sysfs PMU name to use index rather than partnum
> Remove pr_devel statements
> Other Minor cleanups
> Add Partial Ack-by Will Deacon
>
> v5:
> Remove list of CPU types for ACPI systems. We now match a generic
> event list, and use the PMCIED[01] to select events which exist on
> the given PMU. This avoids the need to update the kernel every time
> a new CPU is released.
> Update the maintainers list to include the new file.
>
> v4:
> Correct build issues with ARM (!ARM64) kernels.
> Add ThunderX to list of PMU types.
>
> v3:
> Enable ARM performance monitoring units on ACPI/arm64 machines.
>
> Jeremy Linton (8):
> arm64: pmu: Probe default hw/cache counters
> arm64: pmu: Hoist pmu platform device name
> arm64: Rename the common MADT parse routine
> arm: arm64: Add routine to determine cpuid of other cpus
> arm: arm64: pmu: Assign platform PMU CPU affinity
> arm64: pmu: Detect and enable multiple PMUs in an ACPI system
> arm: pmu: Add PMU definitions for hot-plugged CPUs
> MAINTAINERS: Tweak ARM PMU maintainers
>
> Mark Salter (2):
> arm64: pmu: add fallback probe table
> arm64: pmu: Cache PMU interrupt numbers from MADT parse
>
> MAINTAINERS | 3 +-
> arch/arm/include/asm/cputype.h | 2 +
> arch/arm64/include/asm/cputype.h | 3 +
> arch/arm64/kernel/perf_event.c | 58 ++++++++-
> arch/arm64/kernel/smp.c | 18 ++-
> drivers/perf/Kconfig | 4 +
> drivers/perf/Makefile | 1 +
> drivers/perf/arm_pmu.c | 110 ++++++++++++++--
> drivers/perf/arm_pmu_acpi.c | 264 +++++++++++++++++++++++++++++++++++++++
> include/linux/perf/arm_pmu.h | 13 ++
> 10 files changed, 452 insertions(+), 24 deletions(-)
> create mode 100644 drivers/perf/arm_pmu_acpi.c
^ permalink raw reply
* [PATCH v5 02/16] dt/bindings: Update binding for PM domain idle states
From: Kevin Hilman @ 2016-09-16 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87h99i6b5d.fsf@arm.com>
Brendan Jackman <brendan.jackman@arm.com> writes:
> On Tue, Sep 13 2016 at 20:38, Lina Iyer wrote:
>> On Tue, Sep 13 2016 at 11:50 -0600, Brendan Jackman wrote:
>>>
>>>On Mon, Sep 12 2016 at 18:09, Sudeep Holla wrote:
>>>> On 12/09/16 17:16, Lina Iyer wrote:
>>>>> On Mon, Sep 12 2016 at 09:19 -0600, Brendan Jackman wrote:
>>>>>>
>>>>>> Hi Lina,
>>>>>>
>>>>>> Sorry for the delay here, Sudeep and I were both been on holiday last
>>>>>> week.
>>>>>>
>>>>>> On Fri, Sep 02 2016 at 21:16, Lina Iyer wrote:
>>>>>>> On Fri, Sep 02 2016 at 07:21 -0700, Sudeep Holla wrote:
>>>>>> [...]
>>>>>>>> This version is *not very descriptive*. Also the discussion we had
>>>>>>>> on v3
>>>>>>>> version has not yet concluded IMO. So can I take that we agreed on what
>>>>>>>> was proposed there or not ?
>>>>>>>>
>>>>>>> Sorry, this example is not very descriptive. Pls. check the 8916 dtsi
>>>>>>> for the new changes in the following patches. Let me know if that makes
>>>>>>> sense.
>>>>
>>>> Please add all possible use-cases in the bindings. Though one can refer
>>>> the usage examples, it might not cover all usage descriptions. It helps
>>>> preventing people from defining their own when they don't see examples.
>>>> Again DT bindings are like specifications, it should be descriptive
>>>> especially this kind of generic ones.
>>>>
>>>>>>
>>>>>> The not-yet-concluded discussion Sudeep is referring to is at [1].
>>>>>>
>>>>>> In that thread we initially proposed the idea of, instead of splitting
>>>>>> state phandles between cpu-idle-states and domain-idle-states, putting
>>>>>> CPUs in their own domains and using domain-idle-states for _all_
>>>>>> phandles, deprecating cpu-idle-states. I've brought this up in other
>>>>>> threads [2] but discussion keeps petering out, and neither this example
>>>>>> nor the 8916 dtsi in this patch series reflect the idea.
>>>>>>
>>>>> Brendan, while your idea is good and will work for CPUs, I do not expect
>>>>> other domains and possibly CPU domains on some architectures to follow
>>>>> this model. There is nothing that prevents you from doing this today,
>>>
>>>As I understand it your opposition to this approach is this:
>>>
>>>There may be devices/CPUs which have idle states which do not constitute
>>>"power off". If we put those devices in their own power domain for the
>>>purpose of putting their (non-power-off) idle state phandles in
>>>domain-idle-states, we are "lying" because no true power domain exists
>>>there.
>>>
>>>Am I correct that that's your opposition?
>>>
>>>If so, it seems we essentially disagree on the definition of a power
>>>domain, i.e. you define it as a set of devices that are powered on/off
>>>together while I define it as a set of devices whose power states
>>>(including idle states, not just on/off) are tied together. I said
>>>something similar on another thread [1] which died out.
>>>
>>>Do you agree that this is basically where we disagree, or am I missing
>>>something else?
>>>
>>>[2] http://www.spinics.net/lists/devicetree/msg141050.html
>>>
>> Yes, you are right, I disagree with the definition of a domain around a
>> device.
> OK, great.
>> However, as long as you don't force SoC's to define devices in
>> the CPU PM domain to have their own virtual domains, I have no problem.
>> You are welcome to define it the way you want for Juno or any other
>> platform.
> I don't think that's true; the bindings have to work the same way for
> all platforms. If for Juno we put CPU idle state phandles in a
> domain-idle-states property for per-CPU domains then, with the current
> implementation, the CPU-level idle states would be duplicated between
> cpuidle and the CPU PM domains.
>> I don't want that to be the forced and expected out of all
>> SoCs. All I am saying here is that the current implementation would
>> handle your case as well.
>
> The current implementation certainly does cover the work I want to
> do. The suggestion of per-device power domains for devices/CPUs with
> their own idle states is simply intended to minimise the binding design,
> since we'd no longer need cpu-idle-states or device-idle-states
> (the latter was proposed elsewhere).
>
> I am fine with the bindings as they are implemented currently so long
> as:
>
> - The binding doc makes clear how idle state phandles should be split
> between cpu-idle-states and domain-idle-states. It should make it
> obvious that no phandle should ever appear in both properties. It
> would even be worth briefly going over the backward-compatibility
> implications (e.g. what happens with old-kernel/new-DT and
> new-kernel/old-DT combos if a platform has OSI and PC support and we
> move cluster-level idle state phandles out of cpu-idle-states and into
> domai-idle-states).
>
> - We have a reason against the definition of power domains as "a set of
> devices bound by a common power (including idle) state", since that
> definition would simplify the bindings. In my view, "nobody thinks
> that's what a power domain is" _is_ a compelling reason, so if others
> on the list get involved I'm convinced. I think I speak for Sudeep
> here too.
I think we're having some terminology issues...
FWIW, the kernel terminolgy is actually "PM domain", not power domain.
This was intentional because the goal of the PM domain was to group
devices that some PM features. To be very specific to the kernel, they
us the same set of PM callbacks. Today, this is most commonly used to
model power domains, where a group of devices share a power rail, but it
does not need to be limited to that.
That being said, I'm having a hard time understanding the root of the
disagreement.
It seems that you and Sudeep would like to use domain-idle-states to
replace/superceed cpu-idle-states with the primary goal (and benefit)
being that it simplifies the DT bindings. Is that correct?
The objections have come in because that means that implies that CPUs
become their own domains, which may not be the case in hardware in the
sense that they share a power rail.
However, IMO, thinking of a CPU as it's own "PM domain" may make some
sense based on the terminology above.
I think the other objection may be that using a genpd to model domain
with only a single device in it may be overkill, and I agree with that.
But, I'm not sure if making CPUs use domain-idle-states implies that
they necessarily have to use genpd is what you are proposing. Maybe
someone could clarify that?
Kevin
^ permalink raw reply
* [PATCH v6 2/3] ARM: dts: add TOPEET itop elite based board
From: Krzysztof Kozlowski @ 2016-09-16 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <865b9f84-385f-fea8-2e3d-2b31e3bfe84c@soulik.info>
On Fri, Sep 16, 2016 at 10:04:29PM +0800, ayaka wrote:
> On 09/16/2016 03:23 PM, Krzysztof Kozlowski wrote:
> >On 09/07/2016 11:58 PM, Randy Li wrote:
> >>The TOPEET itop exynos 4412 have three versions base board. The
> >>Elite version is the cheap one without too much peripheral devices
> >>on it.
> >>
> >>Currently supported are serial console, wired networking(USB),
> >>USB OTG in peripheral mode, USB host, SD storage, GPIO buttons,
> >>PWM beeper, ADC and LEDs. The WM8960 analog audio codec is also
> >>enabled.
> >>
> >>The FIMC is not used for camera currently, I enabled it just for a
> >>colorspace convertor.
> >>
> >>Signed-off-by: Randy Li <ayaka@soulik.info>
> >>---
> >> .../bindings/arm/samsung/samsung-boards.txt | 3 +
> >> arch/arm/boot/dts/Makefile | 1 +
> >> arch/arm/boot/dts/exynos4412-itop-elite.dts | 239 +++++++++++++++++++++
> >> 3 files changed, 243 insertions(+)
> >> create mode 100644 arch/arm/boot/dts/exynos4412-itop-elite.dts
> >>
> >>diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
> >>index 0ea7f14..c7159ac 100644
> >>--- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
> >>+++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
> >>@@ -22,6 +22,9 @@ Required root node properties:
> >> * FriendlyARM
> >> - "friendlyarm,tiny4412" - for Exynos4412-based FriendlyARM
> >> TINY4412 board.
> >>+ * TOPEET
> >>+ - "topeet,itop4412-elite" - for Exynos4412-based TOPEET
> >>+ Elite base board.
> >> * Google
> >> - "google,pi" - for Exynos5800-based Google Peach Pi
> >>diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >>index 207f96f..0b39d00 100644
> >>--- a/arch/arm/boot/dts/Makefile
> >>+++ b/arch/arm/boot/dts/Makefile
> >>@@ -130,6 +130,7 @@ dtb-$(CONFIG_ARCH_EXYNOS4) += \
> >> exynos4210-smdkv310.dtb \
> >> exynos4210-trats.dtb \
> >> exynos4210-universal_c210.dtb \
> >>+ exynos4412-itop-elite.dtb \
> >> exynos4412-odroidu3.dtb \
> >> exynos4412-odroidx.dtb \
> >> exynos4412-odroidx2.dtb \
> >>diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts b/arch/arm/boot/dts/exynos4412-itop-elite.dts
> >>new file mode 100644
> >>index 0000000..dd83689
> >>--- /dev/null
> >>+++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
> >>@@ -0,0 +1,239 @@
> >>+/*
> >>+ * TOPEET's Exynos4412 based itop board device tree source
> >>+ *
> >>+ * Copyright (c) 2016 SUMOMO Computer Association
> >>+ * https://www.sumomo.mobi
> >>+ * Randy Li <ayaka@soulik.info>
> >>+ *
> >>+ * Device tree source file for TOPEET iTop Exynos 4412 core board
> >>+ * which is based on Samsung's Exynos4412 SoC.
> >>+ *
> >>+ * This program is free software; you can redistribute it and/or modify
> >>+ * it under the terms of the GNU General Public License version 2 as
> >>+ * published by the Free Software Foundation.
> >>+*/
> >>+
> >>+/dts-v1/;
> >>+#include <dt-bindings/sound/samsung-i2s.h>
> >>+#include "exynos4412-itop-scp-core.dtsi"
> >>+
> >>+/ {
> >>+ model = "TOPEET iTop 4412 Elite board based on Exynos4412";
> >>+ compatible = "topeet,itop4412-elite", "samsung,exynos4412", "samsung,exynos4";
> >>+
> >>+ chosen {
> >>+ bootargs = "root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait";
> >>+ stdout-path = "serial2:115200n8";
> >>+ };
> >>+
> >>+ leds {
> >>+ compatible = "gpio-leds";
> >>+
> >>+ led2 {
> >>+ label = "red:system";
> >>+ gpios = <&gpx1 0 GPIO_ACTIVE_HIGH>;
> >>+ default-state = "off";
> >>+ linux,default-trigger = "heartbeat";
> >>+ };
> >>+
> >>+ led3 {
> >>+ label = "red:user";
> >>+ gpios = <&gpk1 1 GPIO_ACTIVE_HIGH>;
> >>+ default-state = "off";
> >>+ };
> >>+ };
> >>+
> >>+ gpio-keys {
> >>+ compatible = "gpio-keys";
> >>+
> >>+ home {
> >>+ label = "GPIO Key Home";
> >>+ linux,code = <KEY_HOME>;
> >>+ gpios = <&gpx1 1 GPIO_ACTIVE_LOW>;
> >>+ };
> >>+
> >>+ back {
> >>+ label = "GPIO Key Back";
> >>+ linux,code = <KEY_BACK>;
> >>+ gpios = <&gpx1 2 GPIO_ACTIVE_LOW>;
> >>+ };
> >>+
> >>+ sleep {
> >>+ label = "GPIO Key Sleep";
> >>+ linux,code = <KEY_POWER>;
> >>+ gpios = <&gpx3 3 GPIO_ACTIVE_LOW>;
> >>+ };
> >>+
> >>+ vol-up {
> >>+ label = "GPIO Key Vol+";
> >>+ linux,code = <KEY_UP>;
> >>+ gpios = <&gpx2 1 GPIO_ACTIVE_LOW>;
> >>+ };
> >>+
> >>+ vol-down {
> >>+ label = "GPIO Key Vol-";
> >>+ linux,code = <KEY_DOWN>;
> >>+ gpios = <&gpx2 0 GPIO_ACTIVE_LOW>;
> >>+ };
> >>+ };
> >>+
> >>+ sound {
> >>+ compatible = "simple-audio-card";
> >>+ simple-audio-card,name = "wm-sound";
> >>+
> >>+ assigned-clocks = <&clock_audss EXYNOS_MOUT_AUDSS>,
> >>+ <&clock_audss EXYNOS_MOUT_I2S>,
> >>+ <&clock_audss EXYNOS_DOUT_SRP>,
> >>+ <&clock_audss EXYNOS_DOUT_AUD_BUS>;
> >>+ assigned-clock-parents = <&clock CLK_FOUT_EPLL>,
> >>+ <&clock_audss EXYNOS_MOUT_AUDSS>;
> >>+ assigned-clock-rates = <0>,
> >>+ <0>,
> >>+ <112896000>,
> >>+ <11289600>;
> >>+
> >>+ simple-audio-card,format = "i2s";
> >>+ simple-audio-card,bitclock-master = <&link0_codec>;
> >>+ simple-audio-card,frame-master = <&link0_codec>;
> >>+
> >>+ simple-audio-card,widgets =
> >>+ "Microphone", "Mic Jack",
> >>+ "Line", "Line In",
> >>+ "Line", "Line Out",
> >>+ "Speaker", "Speaker",
> >>+ "Headphone", "Headphone Jack";
> >>+ simple-audio-card,routing =
> >>+ "Headphone Jack", "HP_L",
> >>+ "Headphone Jack", "HP_R",
> >>+ "Speaker", "SPK_LP",
> >>+ "Speaker", "SPK_LN",
> >>+ "Speaker", "SPK_RP",
> >>+ "Speaker", "SPK_RN",
> >>+ "LINPUT1", "Mic Jack",
> >>+ "LINPUT3", "Mic Jack",
> >>+ "RINPUT1", "Mic Jack",
> >>+ "RINPUT2", "Mic Jack";
> >>+
> >>+ simple-audio-card,cpu {
> >>+ sound-dai = <&i2s0 0>;
> >>+ };
> >>+
> >>+ link0_codec: simple-audio-card,codec {
> >>+ sound-dai = <&codec>;
> >>+ clocks = <&i2s0 CLK_I2S_CDCLK>;
> >>+ system-clock-frequency = <11289600>;
> >>+ };
> >>+ };
> >>+
> >>+ beep {
> >>+ compatible = "pwm-beeper";
> >>+ pwms = <&pwm 0 4000000 PWM_POLARITY_INVERTED>;
> >I have serious doubts that you run this code... if it does not even
> >compile. Sorry, I cannot accept code that does not compile and was not
> >tested.
> >
> >Please, test your DTS on top of current Linux tree, which would be one of:
> >1. Linus' master branch: v4.8-rc6,
> >2. one of my branches (for-next, next/dt etc),
> When I sent those patches, I tested in "Add linux-next specific files for
> 20160907"
OK, good, but please tell me why kbuild reported that build error?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v7 0/5] mfd: tps65218: Clean ups
From: Mark Brown @ 2016-09-16 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0a30f210-0a23-0899-51b0-28f200ddd0a4@ti.com>
On Fri, Sep 16, 2016 at 09:51:38PM +0530, Keerthy wrote:
> On Friday 16 September 2016 07:01 PM, Mark Brown wrote:
> > On Fri, Sep 16, 2016 at 05:12:38PM +0530, Keerthy wrote:
> > > Should i repost this series? I do not see this series in linux-next yet.
> > Please don't send content free pings and please allow a reasonable time
> > for review. People get busy, go on holiday, attend conferences and so
> I should have been clearer.
> The last Lee Jones conveyed that:
> "I can't take this series yet, since it relies on a change which was
> taken into Mark's Regulator tree"
> https://lkml.org/lkml/2016/8/31/312
> So wanted to check if i needed to re-base/repost this series again.
> Sorry about the confusion i think that is because of $Subject goof up in the
> 0th patch of the series.
I'm afraid I've no real idea what this series is about or what patches
it might depend on, sorry. If you're waiting for me to do something
you'll need to tell me what it is but if it's a dependency that needs
cross merging then reposting this series isn't going to be needed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160916/416ca661/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: msm8974: Add definitions for QCE & cryptobam
From: Iaroslav Gridin @ 2016-09-16 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915211842.GB5431@hector.attlocal.net>
On Thu, Sep 15, 2016 at 04:18:42PM -0500, Andy Gross wrote:
> Actually, on thinking about this more, the bam block itself only requires the
> single clock. The peripheral it is attached to has to keep its sanity during
> the duration of the transfer (crypto). The crypto requires 3 clocks, one of
> which is the same clk the bam requires.
>
> You can access the BAM registers with the bam_clk only, correct?
Not preparing bam_clk degrades QCE performance about 3x, though.
^ permalink raw reply
* [PATCH v5 02/16] dt/bindings: Update binding for PM domain idle states
From: Sudeep Holla @ 2016-09-16 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hpoo3ix80.fsf@baylibre.com>
Hi Kevin,
Thanks for looking at this and simplifying various discussions we had so
far. I was thinking of summarizing something very similar. I couldn't
due to lack of time.
On 16/09/16 18:13, Kevin Hilman wrote:
[...]
> I think we're having some terminology issues...
>
> FWIW, the kernel terminolgy is actually "PM domain", not power domain.
> This was intentional because the goal of the PM domain was to group
> devices that some PM features. To be very specific to the kernel, they
> us the same set of PM callbacks. Today, this is most commonly used to
> model power domains, where a group of devices share a power rail, but it
> does not need to be limited to that.
>
Agreed/Understood.
> That being said, I'm having a hard time understanding the root of the
> disagreement.
>
Yes. I tried to convey the same earlier, but have failed. The only
disagreement is about a small part of this DT bindings. We would like to
make it completely hierarchical up to CPU nodes. More comments on that
below.
> It seems that you and Sudeep would like to use domain-idle-states to
> replace/superceed cpu-idle-states with the primary goal (and benefit)
> being that it simplifies the DT bindings. Is that correct?
>
Correct, we want to deprecate cpu-idle-states with the introduction of
this hierarchical PM bindings. Yes IMO, it simplifies things and avoids
any ABI break we might trigger if we miss to consider some use-case now.
> The objections have come in because that means that implies that CPUs
> become their own domains, which may not be the case in hardware in the
> sense that they share a power rail.
>
Agreed.
> However, IMO, thinking of a CPU as it's own "PM domain" may make some
> sense based on the terminology above.
>
Thanks for that, we do understand that it may not be 100% correct when
we strictly considers hardware terminologies instead of above ones.
As along as we see no issues with the above terminologies it should be fine.
> I think the other objection may be that using a genpd to model domain
> with only a single device in it may be overkill, and I agree with that.
I too agree with that. Just because we represent that in DT in that way
doesn't mean we need to create a genpd to model domain. We can always
skip that if not required. That's pure implementation specifics and I
have tried to convey the same in my previous emails. I must say you have
summarized it very clearly in this email. Thanks again for that.
> But, I'm not sure if making CPUs use domain-idle-states implies that
> they necessarily have to use genpd is what you are proposing. Maybe
> someone could clarify that?
>
No, I have not proposing anything around implementation in the whole
discussion so far. I have constrained myself just to DT bindings so far.
That's the main reason why I was opposed to mentions of OS vs platform
co-ordinated modes of CPU suspend in this discussion. IMO that's
completely out of scope of this DT binding we are defining here.
Hope that helps/clarifies the misunderstanding/disagreement.
--
Regards,
Sudeep
^ permalink raw reply
* Applied "ASoC: rockchip: Support headset button function on rk3399" to the asoc tree
From: Mark Brown @ 2016-09-16 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473981006-20542-1-git-send-email-cychiang@chromium.org>
The patch
ASoC: rockchip: Support headset button function on rk3399
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 22b93eaf55edfd2f1fe9d1fc0d7338f582f12745 Mon Sep 17 00:00:00 2001
From: Cheng-Yi Chiang <cychiang@chromium.org>
Date: Fri, 16 Sep 2016 07:10:06 +0800
Subject: [PATCH] ASoC: rockchip: Support headset button function on rk3399
Set the mapping between button and media key event.
Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/rockchip/rk3399_gru_sound.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c b/sound/soc/rockchip/rk3399_gru_sound.c
index 164b6da4f2cf..ee0648927afc 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -23,6 +23,7 @@
#include <linux/of_gpio.h>
#include <linux/delay.h>
#include <linux/spi/spi.h>
+#include <linux/input.h>
#include <sound/core.h>
#include <sound/jack.h>
#include <sound/pcm.h>
@@ -209,6 +210,14 @@ static int rockchip_sound_da7219_init(struct snd_soc_pcm_runtime *rtd)
return ret;
}
+ snd_jack_set_key(rockchip_sound_jack.jack, SND_JACK_BTN_0, KEY_MEDIA);
+ snd_jack_set_key(
+ rockchip_sound_jack.jack, SND_JACK_BTN_1, KEY_VOLUMEUP);
+ snd_jack_set_key(
+ rockchip_sound_jack.jack, SND_JACK_BTN_2, KEY_VOLUMEDOWN);
+ snd_jack_set_key(
+ rockchip_sound_jack.jack, SND_JACK_BTN_3, KEY_VOICECOMMAND);
+
da7219_aad_jack_det(codec, &rockchip_sound_jack);
return 0;
--
2.8.1
^ permalink raw reply related
* [RFC PATCH 0/5] arm64: Signal context expansion
From: Dave Martin @ 2016-09-16 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ad89f920-897c-47cb-d584-4b306bc24d1c@redhat.com>
On Fri, Sep 16, 2016 at 02:10:53PM +0200, Florian Weimer wrote:
> On 09/15/2016 06:45 PM, Dave Martin wrote:
> >On Tue, Sep 13, 2016 at 06:02:45PM +0200, Florian Weimer wrote:
> >>On 09/13/2016 05:52 PM, Dave Martin wrote:
> >>
> >>>Agreed. I'll need to think some more about how this should work in
> >>>general.
> >>
> >>Thanks.
> >>
> >>Depending on some SVE implementations details (which I know nothing about, I
> >>only saw some public overview slides), we may also need additional storage
> >>space to preserve SVE registers in the dynamic linker. Due to lazy binding,
> >>this code cn be called from a signal handler, so this needs to be factored
> >>into stack size requirements as well.
> >
> >Yes and no. The kernel SIGSTKSZ constants don't care about ld.so --
> >that's userspace overhead, not kernel overhead.
>
> Well yes, so is jmp_buf. But I think you still should consider the full
> picture. :)
>
> At least the lazy binding stack overhead can be avoided with LD_BIND_NOW=1.
I am considering the wider picture, but we're a bit out of scope for the
patch series, except that I will split out the ability to grow the
signal frame out as a separate patch.
>
> >>Problematic are register width extensions used for argument passing and
> >>callee-saved registers whose width has been extended. Both are particularly
> >>challenging to deal with if existing vector instructions clear the extension
> >>part (which may be desirable for other reasons).
> >>
> >>The size of the jmp_buf type is a concern as well.
> >
> >The default PCS for SVE will not be introducing any extra save/restore
> >requirements for SVE -- i.e., everything is caller-save at public
> >interfaces, except for the FPSIMD register bits that are already callee-
> >save under the existing PCS.
>
> Is it possible to pass arguments in the register extension parts? If
> existing non-SVE code can clobber these bits, we need some adjustments in
> libc to save and restore SVE state in some places (which may need further
> stack space).
Arguments can be passed the the extended vector registers in theory, but
this is expected only at private interfaces and within compilation units
to begin with. General-purpose libraries including libc would not be
using those bits at their interfaces, at least for now.
When calling any public interface using the default PCS, all the SVE
registers can be clobbered -- the caller must compensate for this if
it cares. So, the compensation is always in the _new_ binaries where
code gen in the compiler can take care of it automatically -- not
the current and non-SVE binaries. libc needs to update for this
specifically, so long as only the default PCS is supported for all
dynamic symbols (which I think will be the case to begin with).
A similar argument applies to all libc entry points, including
setjmp()/longjmp()/jmp_buf.
Notwithstanding this, a binary built for SVE _may_ use more stack
than a binary built without SVE support. This can always happen when
compiling with different options or even after a minor compiler or
library upgrade, so any software that doesn't already have some safety
buffer in its stack allocations is running a risk even without SVE. SVE
will probably tend to grow frames rather than shrink them, so there will
be increased pressure on stack allocations, but I don't have a good
answer about the scale of the impact at this point.
For now, I don't expect to fix everything in one go.
[...]
Cheers
---Dave
^ permalink raw reply
* [PATCH 0/2] dts: arm64: db820c: adds support to pmic pins
From: Srinivas Kandagatla @ 2016-09-16 17:41 UTC (permalink / raw)
To: linux-arm-kernel
Hi Andy/Linus W,
This patchset adds support to pm8994 gpios/mpps on db820c board.
DB820c board Low Speed expansion GPIO_F is connected to PM8994_GPIO5
Its better if we take this patchset from single tree, as dts patch has
dependency on the dt-bindings include file.
Without this patchset GPIO_F on LS expansion would be at 2.7v
instead of 1.8v.
Thanks,
srini
Srinivas Kandagatla (2):
pinctrl: pm8994: add pad voltage regulator defines
dts: arm64: db820c: add pmic pins specific dts file
arch/arm64/boot/dts/qcom/apq8096-db820c-pmic-pins.dtsi | 15 +++++++++++++++
arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 2 ++
include/dt-bindings/pinctrl/qcom,pmic-gpio.h | 4 ++++
include/dt-bindings/pinctrl/qcom,pmic-mpp.h | 6 ++++++
4 files changed, 27 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/apq8096-db820c-pmic-pins.dtsi
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] pinctrl: pm8994: add pad voltage regulator defines
From: Srinivas Kandagatla @ 2016-09-16 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474047681-6821-1-git-send-email-srinivas.kandagatla@linaro.org>
This patch adds defines for internal voltage regulators used
to switch voltage levels on gpio/mpp pads.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
include/dt-bindings/pinctrl/qcom,pmic-gpio.h | 4 ++++
include/dt-bindings/pinctrl/qcom,pmic-mpp.h | 6 ++++++
2 files changed, 10 insertions(+)
diff --git a/include/dt-bindings/pinctrl/qcom,pmic-gpio.h b/include/dt-bindings/pinctrl/qcom,pmic-gpio.h
index aafa76c..d33f17c 100644
--- a/include/dt-bindings/pinctrl/qcom,pmic-gpio.h
+++ b/include/dt-bindings/pinctrl/qcom,pmic-gpio.h
@@ -89,6 +89,10 @@
#define PMA8084_GPIO_S4 2
#define PMA8084_GPIO_L6 3
+#define PM8994_GPIO_VPH 0
+#define PM8994_GPIO_S4 2
+#define PM8994_GPIO_L12 3
+
/* To be used with "function" */
#define PMIC_GPIO_FUNC_NORMAL "normal"
#define PMIC_GPIO_FUNC_PAIRED "paired"
diff --git a/include/dt-bindings/pinctrl/qcom,pmic-mpp.h b/include/dt-bindings/pinctrl/qcom,pmic-mpp.h
index a15c170..2e360d8f 100644
--- a/include/dt-bindings/pinctrl/qcom,pmic-mpp.h
+++ b/include/dt-bindings/pinctrl/qcom,pmic-mpp.h
@@ -65,6 +65,12 @@
#define PMA8084_MPP_S4 2
#define PMA8084_MPP_L6 3
+#define PM8994_MPP_VPH 0
+/* Only supported for MPP_05-MPP_08 */
+#define PM8994_MPP_L19 1
+#define PM8994_MPP_S4 2
+#define PM8994_MPP_L12 3
+
/*
* Analog Input - Set the source for analog input.
* To be used with "qcom,amux-route" property
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] dts: arm64: db820c: add pmic pins specific dts file
From: Srinivas Kandagatla @ 2016-09-16 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474047681-6821-1-git-send-email-srinivas.kandagatla@linaro.org>
This patch adds pmic specific dts which are configured specially
for db820c. One of such pin is GPIO_F on the Low Speed expansion
which has default output voltage of 2.7v. This patch fixes setup
for that pin to have an output voltage of 1.8v to comply with
96boards LS expansion specs.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
arch/arm64/boot/dts/qcom/apq8096-db820c-pmic-pins.dtsi | 15 +++++++++++++++
arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 2 ++
2 files changed, 17 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/apq8096-db820c-pmic-pins.dtsi
diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c-pmic-pins.dtsi b/arch/arm64/boot/dts/qcom/apq8096-db820c-pmic-pins.dtsi
new file mode 100644
index 0000000..0938191
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c-pmic-pins.dtsi
@@ -0,0 +1,15 @@
+
+#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
+&pm8994_gpios {
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&ls_exp_gpio_f>;
+
+ ls_exp_gpio_f: pm8916_mpp4 {
+ pinconf {
+ pins = "gpio5";
+ output-low;
+ power-source = <PM8994_GPIO_S4>; // 1.8V
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
index afb218c..422959b 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
@@ -12,7 +12,9 @@
*/
#include "msm8996.dtsi"
+#include "pm8994.dtsi"
#include "apq8096-db820c-pins.dtsi"
+#include "apq8096-db820c-pmic-pins.dtsi"
/ {
aliases {
--
2.7.4
^ permalink raw reply related
* [PATCH v9 08/10] arm64: pmu: Detect and enable multiple PMUs in an ACPI system
From: Jeremy Linton @ 2016-09-16 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87bmznu61q.fsf@e105922-lin.cambridge.arm.com>
On 09/16/2016 12:07 PM, Punit Agrawal wrote:
> Jeremy Linton <jeremy.linton@arm.com> writes:
>
>> Hi,
>>
>> On 09/16/2016 08:33 AM, Punit Agrawal wrote:
>>> Jeremy Linton <jeremy.linton@arm.com> writes:
>>>
>>>> Its possible that an ACPI system has multiple CPU types in it
>>>> with differing PMU counters. Iterate the CPU's and make a determination
>>>> about how many of each type exist in the system. Then take and create
>>>> a PMU platform device for each type, and assign it the interrupts parsed
>>>> from the MADT. Creating a platform device is necessary because the PMUs
>>>> are not described as devices in the DSDT table.
>>>>
>>>> This code is loosely based on earlier work by Mark Salter.
>>
>> (trimming)
>>
>>>> +
>>>> + list_for_each_entry_safe(pmu, safe_temp, &pmus, list) {
>>>> + if (unused_madt_entries)
>>>> + pmu->cpu_count = num_possible_cpus();
>>>
>>> So if there is any unbooted cpu ...
>>>
>>>> +
>>>> + res = kcalloc(pmu->cpu_count,
>>>> + sizeof(struct resource), GFP_KERNEL);
>>>
>>> ... we allocate potentially large number (num_possible_cpus()) of
>>> resources for each PMU.
>>>
>>> This is needlessly wasteful. Under what conditions have you found
>>> reg_midr to be 0?
>>
>> Unused MADT entries, in place for potentially unbooted/hotplug
>> CPUs.
>
> Is linux able to deal with booting secondaries that have unused MADT
> entries?
Uh, yah I think so, that is how i've been testing it, maybe we are
saying different things. When i'm talking about "unused" I mean MADT
entries that don't have started/running cpus. Obviously they stop being
unused when a cpu is booted.
>
>> In those cases you don't know for sure which PMU the CPU belongs
>> to until it comes online and the MIDR can be read. I'm open to
>> suggestions on how to deal with this, outside of pushing my luck and
>> further breaking the platform device encapsulation by trying to
>> reallocate the resource structure while its active. Besides its only
>> wasteful for ACPI+big.little, which at the moment only applies to a
>> development platform.
>
> I don't have any ideas to solve this problem, but in the interest of
> helping review, please move all the changes arising from hotplug/unused
> MADT entries in this patch to the next one.
Which is sort of the opposite of the last 3 months, of complaints about
how hard it was to review this module with multiple patches adding
features to the code...
^ permalink raw reply
* [PATCH v6 2/3] ARM: dts: add TOPEET itop elite based board
From: Javier Martinez Canillas @ 2016-09-16 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916172110.GA7511@kozik-lap>
Hello Randy,
On 09/16/2016 01:21 PM, Krzysztof Kozlowski wrote:
[snip]
>>>> +
>>>> + beep {
>>>> + compatible = "pwm-beeper";
>>>> + pwms = <&pwm 0 4000000 PWM_POLARITY_INVERTED>;
>>> I have serious doubts that you run this code... if it does not even
>>> compile. Sorry, I cannot accept code that does not compile and was not
>>> tested.
>>>
>>> Please, test your DTS on top of current Linux tree, which would be one of:
>>> 1. Linus' master branch: v4.8-rc6,
>>> 2. one of my branches (for-next, next/dt etc),
>> When I sent those patches, I tested in "Add linux-next specific files for
>> 20160907"
>
> OK, good, but please tell me why kbuild reported that build error?
>
I agree with Krzysztof, it doesn't seem that you tested the exact version
that was posted. You will need the following change to make the DTS build
in latest linux-next:
diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts b/arch/arm/boot/dts/exynos4412-itop-elite.dts
index dd83689892ff..8559f891a740 100644
--- a/arch/arm/boot/dts/exynos4412-itop-elite.dts
+++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
@@ -14,6 +14,7 @@
*/
/dts-v1/;
+#include <dt-bindings/pwm/pwm.h>
#include <dt-bindings/sound/samsung-i2s.h>
#include "exynos4412-itop-scp-core.dtsi"
So please squash that change and resend.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply related
* [PATCH] ARM: dts: msm8974: Add definitions for QCE & cryptobam
From: Andy Gross @ 2016-09-16 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916173800.r264xg5wqmer77wr@localhost>
On Fri, Sep 16, 2016 at 08:38:01PM +0300, Iaroslav Gridin wrote:
> On Thu, Sep 15, 2016 at 04:18:42PM -0500, Andy Gross wrote:
>
> > Actually, on thinking about this more, the bam block itself only requires the
> > single clock. The peripheral it is attached to has to keep its sanity during
> > the duration of the transfer (crypto). The crypto requires 3 clocks, one of
> > which is the same clk the bam requires.
> >
> > You can access the BAM registers with the bam_clk only, correct?
>
> Not preparing bam_clk degrades QCE performance about 3x, though.
If the CE2_CLK is the only required clk, that makes it the "bam_clk". I see the
crypto requires getting all three clocks: AXI (bus), AHB (iface), and CE2 (core)
If the crypto is active during DMA transfers, which it has to be, then the
performance shouldn't degrade due to the BAM not preparing the AHB.
Regards,
Andy
^ permalink raw reply
* [PATCH v2] input: touchscreen: Add support for Elan eKTF2127 touchscreen controller
From: Dmitry Torokhov @ 2016-09-16 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160902140935.GA19453@rob-hp-laptop>
On Fri, Sep 02, 2016 at 09:09:35AM -0500, Rob Herring wrote:
> On Sun, Aug 28, 2016 at 06:00:05PM +0200, Hans de Goede wrote:
> > From: Siebren Vroegindeweij <siebren.vroegindeweij@hotmail.com>
> >
> > This adds a driver for the Elan eKTF2127 touchscreen controller,
> > which speaks an i2c protocol which is distinctly different from
> > the already supported eKTH controllers.
> >
> > Signed-off-by: Michel Verlaan <michel.verl@gmail.com>
> > Signed-off-by: Siebren Vroegindeweij <siebren.vroegindeweij@hotmail.com>
> > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > ---
> > Changes in v2:
> > -Improve devicetree bindings document
> > -Use touchscreen_parse_properties and touchscreen_report_pos instead of DIY
> > -Remove a bunch of unused defines (copy and paste leftover from chipone driver)
> > -Some other minor cleanups and review comments addressed
> > -Add defines for some command / address hex-values
> > -Check packet header in interrupt handler
> > ---
> > .../bindings/input/touchscreen/ektf2127.txt | 27 ++
>
> Acked-by: Rob Herring <robh@kernel.org>
I'd like to merge the version below (factored out querying dimensions
and parsing/reporting touch), can you please give it a spin?
Thanks!
--
Dmitry
Input: touchscreen - add support for Elan eKTF2127 touchscreen controller
From: Siebren Vroegindeweij <siebren.vroegindeweij@hotmail.com>
This adds a driver for the Elan eKTF2127 touchscreen controller,
which speaks an i2c protocol which is distinctly different from
the already supported eKTH controllers.
Signed-off-by: Michel Verlaan <michel.verl@gmail.com>
Signed-off-by: Siebren Vroegindeweij <siebren.vroegindeweij@hotmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
.../bindings/input/touchscreen/ektf2127.txt | 27 ++
drivers/input/touchscreen/Kconfig | 12 +
drivers/input/touchscreen/Makefile | 1
drivers/input/touchscreen/ektf2127.c | 336 ++++++++++++++++++++
4 files changed, 376 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt
create mode 100644 drivers/input/touchscreen/ektf2127.c
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt b/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt
new file mode 100644
index 0000000..5a19f4c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt
@@ -0,0 +1,27 @@
+* Elan eKTF2127 I2C touchscreen controller
+
+Required properties:
+ - compatible : "elan,ektf2127"
+ - reg : I2C slave address of the chip (0x40)
+ - interrupt-parent : a phandle pointing to the interrupt controller
+ serving the interrupt for this chip
+ - interrupts : interrupt specification for the ektf2127 interrupt
+ - power-gpios : GPIO specification for the pin connected to the
+ ektf2127's wake input. This needs to be driven high
+ to take ektf2127 out of it's low power state
+
+For additional optional properties see: touchscreen.txt
+
+Example:
+
+i2c at 00000000 {
+ ektf2127: touchscreen at 15 {
+ compatible = "elan,ektf2127";
+ reg = <0x15>;
+ interrupt-parent = <&pio>;
+ interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>
+ power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>;
+ touchscreen-inverted-x;
+ touchscreen-swapped-x-y;
+ };
+};
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index 3b3d07a..880aa50 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -396,6 +396,18 @@ config TOUCHSCREEN_ELAN
To compile this driver as a module, choose M here: the
module will be called elants_i2c.
+config TOUCHSCREEN_EKTF2127
+ tristate "Elan eKTF2127 I2C touchscreen"
+ depends on I2C
+ help
+ Say Y here if you have an Elan eKTF2127 touchscreen
+ connected to your system.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ektf2127.
+
config TOUCHSCREEN_ELO
tristate "Elo serial touchscreens"
select SERIO
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index 57a1c09..e26ff38 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_TOUCHSCREEN_HAMPSHIRE) += hampshire.o
obj-$(CONFIG_TOUCHSCREEN_GUNZE) += gunze.o
obj-$(CONFIG_TOUCHSCREEN_EETI) += eeti_ts.o
obj-$(CONFIG_TOUCHSCREEN_ELAN) += elants_i2c.o
+obj-$(CONFIG_TOUCHSCREEN_EKTF2127) += ektf2127.o
obj-$(CONFIG_TOUCHSCREEN_ELO) += elo.o
obj-$(CONFIG_TOUCHSCREEN_EGALAX) += egalax_ts.o
obj-$(CONFIG_TOUCHSCREEN_EGALAX_SERIAL) += egalax_ts_serial.o
diff --git a/drivers/input/touchscreen/ektf2127.c b/drivers/input/touchscreen/ektf2127.c
new file mode 100644
index 0000000..31a2dd7
--- /dev/null
+++ b/drivers/input/touchscreen/ektf2127.c
@@ -0,0 +1,336 @@
+/*
+ * Driver for ELAN eKTF2127 i2c touchscreen controller
+ *
+ * For this driver the layout of the Chipone icn8318 i2c
+ * touchscreencontroller is used.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author:
+ * Michel Verlaan <michel.verl@gmail.com>
+ * Siebren Vroegindeweij <siebren.vroegindeweij@hotmail.com>
+ *
+ * Original chipone_icn8318 driver:
+ * Hans de Goede <hdegoede@redhat.com>
+ */
+
+#include <linux/gpio/consumer.h>
+#include <linux/interrupt.h>
+#include <linux/i2c.h>
+#include <linux/input.h>
+#include <linux/input/mt.h>
+#include <linux/input/touchscreen.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/delay.h>
+
+/* Packet header defines (first byte of data send / received) */
+#define EKTF2127_NOISE 0x40
+#define EKTF2127_RESPONSE 0x52
+#define EKTF2127_REQUEST 0x53
+#define EKTF2127_HELLO 0x55
+#define EKTF2127_REPORT 0x5d
+#define EKTF2127_CALIB_DONE 0x66
+
+/* Register defines (second byte of data send / received) */
+#define EKTF2127_ENV_NOISY 0x41
+#define EKTF2127_HEIGHT 0x60
+#define EKTF2127_WIDTH 0x63
+
+/* 2 bytes header + 5 * 3 bytes coordinates + 3 bytes pressure info + footer */
+#define EKTF2127_TOUCH_REPORT_SIZE 21
+#define EKTF2127_MAX_TOUCHES 5
+
+struct ektf2127_ts {
+ struct i2c_client *client;
+ struct input_dev *input;
+ struct gpio_desc *power_gpios;
+ struct touchscreen_properties prop;
+};
+
+static void ektf2127_parse_coordinates(const u8* buf, unsigned int touch_count,
+ struct input_mt_pos *touches)
+{
+ int index = 0;
+ int i;
+
+ for (i = 0; i < touch_count; i++) {
+ index = 2 + i * 3;
+
+ touches[i].x = (buf[index] & 0x0f);
+ touches[i].x <<= 8;
+ touches[i].x |= buf[index + 2];
+
+ touches[i].y = (buf[index] & 0xf0);
+ touches[i].y <<= 4;
+ touches[i].y |= buf[index + 1];
+ }
+}
+
+static void ektf2127_report_event(struct ektf2127_ts *ts, const u8 *buf)
+{
+ struct input_mt_pos touches[EKTF2127_MAX_TOUCHES];
+ int slots[EKTF2127_MAX_TOUCHES];
+ unsigned int touch_count, i;
+
+ touch_count = buf[1] & 0x07;
+ if (touch_count > EKTF2127_MAX_TOUCHES) {
+ dev_err(&ts->client->dev,
+ "Too many touches %d > %d\n",
+ touch_count, EKTF2127_MAX_TOUCHES);
+ touch_count = EKTF2127_MAX_TOUCHES;
+ }
+
+ ektf2127_parse_coordinates(buf, touch_count, touches);
+ input_mt_assign_slots(ts->input, slots, touches,
+ touch_count, 0);
+
+ for (i = 0; i < touch_count; i++) {
+ input_mt_slot(ts->input, slots[i]);
+ input_mt_report_slot_state(ts->input, MT_TOOL_FINGER, true);
+ touchscreen_report_pos(ts->input, &ts->prop,
+ touches[i].x, touches[i].y, true);
+ }
+
+ input_mt_sync_frame(ts->input);
+ input_sync(ts->input);
+}
+
+static irqreturn_t ektf2127_irq(int irq, void *dev_id)
+{
+ struct ektf2127_ts *ts = dev_id;
+ struct device *dev = &ts->client->dev;
+ char buf[EKTF2127_TOUCH_REPORT_SIZE];
+ int ret;
+
+ ret = i2c_master_recv(ts->client, buf, EKTF2127_TOUCH_REPORT_SIZE);
+ if (ret != EKTF2127_TOUCH_REPORT_SIZE) {
+ dev_err(dev, "Error reading touch data: %d\n", ret);
+ goto out;
+ }
+
+ switch (buf[0]) {
+ case EKTF2127_REPORT:
+ ektf2127_report_event(ts, buf);
+ break;
+
+ case EKTF2127_NOISE:
+ if (buf[1] == EKTF2127_ENV_NOISY)
+ dev_dbg(dev, "Environment is electrically noisy\n");
+ break;
+
+ case EKTF2127_HELLO:
+ case EKTF2127_CALIB_DONE:
+ break;
+
+ default:
+ dev_err(dev, "Unexpected packet header byte %#02x\n", buf[0]);
+ break;
+ }
+
+out:
+ return IRQ_HANDLED;
+}
+
+static int ektf2127_start(struct input_dev *dev)
+{
+ struct ektf2127_ts *ts = input_get_drvdata(dev);
+
+ enable_irq(ts->client->irq);
+ gpiod_set_value_cansleep(ts->power_gpios, 1);
+
+ return 0;
+}
+
+static void ektf2127_stop(struct input_dev *dev)
+{
+ struct ektf2127_ts *ts = input_get_drvdata(dev);
+
+ disable_irq(ts->client->irq);
+ gpiod_set_value_cansleep(ts->power_gpios, 0);
+}
+
+static int ektf2127_suspend(struct device *dev)
+{
+ struct ektf2127_ts *ts = i2c_get_clientdata(to_i2c_client(dev));
+
+ mutex_lock(&ts->input->mutex);
+ if (ts->input->users)
+ ektf2127_stop(ts->input);
+ mutex_unlock(&ts->input->mutex);
+
+ return 0;
+}
+
+static int ektf2127_resume(struct device *dev)
+{
+ struct ektf2127_ts *ts = i2c_get_clientdata(to_i2c_client(dev));
+
+ mutex_lock(&ts->input->mutex);
+ if (ts->input->users)
+ ektf2127_start(ts->input);
+ mutex_unlock(&ts->input->mutex);
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(ektf2127_pm_ops, ektf2127_suspend,
+ ektf2127_resume);
+
+static int ektf2127_query_dimension(struct i2c_client *client, bool width)
+{
+ struct device *dev = &client->dev;
+ const char *what = width ? "width" : "height";
+ u8 what_code = width ? EKTF2127_WIDTH : EKTF2127_HEIGHT;
+ u8 buf[4];
+ int ret;
+ int error;
+
+ /* Request dimension */
+ buf[0] = EKTF2127_REQUEST;
+ buf[1] = width ? EKTF2127_WIDTH : EKTF2127_HEIGHT;
+ buf[2] = 0x00;
+ buf[3] = 0x00;
+ ret = i2c_master_send(client, buf, sizeof(buf));
+ if (ret != sizeof(buf)) {
+ error = ret < 0 ? ret : -EIO;
+ dev_err(dev, "Failed to request %s: %d\n", what, error);
+ return error;
+ }
+
+ msleep(20);
+
+ /* Read response */
+ ret = i2c_master_recv(client, buf, sizeof(buf));
+ if (ret != sizeof(buf)) {
+ error = ret < 0 ? ret : -EIO;
+ dev_err(dev, "Failed to receive %s data: %d\n", what, error);
+ return error;
+ }
+
+ if (buf[0] != EKTF2127_RESPONSE || buf[1] != what_code) {
+ dev_err(dev, "Unexpected %s data: %#02x %#02x\n",
+ what, buf[0], buf[1]);
+ return -EIO;
+ }
+
+ return (((buf[3] & 0xf0) << 4) | buf[2]) - 1;
+}
+
+static int ektf2127_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct device *dev = &client->dev;
+ struct ektf2127_ts *ts;
+ struct input_dev *input;
+ u8 buf[4];
+ int max_x, max_y;
+ int error;
+
+ if (!client->irq) {
+ dev_err(dev, "Error no irq specified\n");
+ return -EINVAL;
+ }
+
+ ts = devm_kzalloc(dev, sizeof(*ts), GFP_KERNEL);
+ if (!ts)
+ return -ENOMEM;
+
+ /* This requests the gpio *and* turns on the touchscreen controller */
+ ts->power_gpios = devm_gpiod_get(dev, "power", GPIOD_OUT_HIGH);
+ if (IS_ERR(ts->power_gpios)) {
+ error = PTR_ERR(ts->power_gpios);
+ if (error != -EPROBE_DEFER)
+ dev_err(dev, "Error getting power gpio: %d\n", error);
+ return error;
+ }
+
+ input = devm_input_allocate_device(dev);
+ if (!input)
+ return -ENOMEM;
+
+ input->name = client->name;
+ input->id.bustype = BUS_I2C;
+ input->open = ektf2127_start;
+ input->close = ektf2127_stop;
+
+ ts->client = client;
+
+ /* Read hello (ignore result, depends on initial power state) */
+ msleep(20);
+ i2c_master_recv(ts->client, buf, sizeof(buf));
+
+ /* Read resolution from chip */
+ max_x = ektf2127_query_dimension(client, true);
+ if (max_x < 0)
+ return max_x;
+
+ max_y = ektf2127_query_dimension(client, false);
+ if (max_y < 0)
+ return max_y;
+
+ input_set_abs_params(input, ABS_MT_POSITION_X, 0, max_x, 0, 0);
+ input_set_abs_params(input, ABS_MT_POSITION_Y, 0, max_y, 0, 0);
+ touchscreen_parse_properties(input, true, &ts->prop);
+
+ error = input_mt_init_slots(input, EKTF2127_MAX_TOUCHES,
+ INPUT_MT_DIRECT |
+ INPUT_MT_DROP_UNUSED |
+ INPUT_MT_TRACK);
+ if (error)
+ return error;
+
+ ts->input = input;
+ input_set_drvdata(input, ts);
+
+ error = devm_request_threaded_irq(dev, client->irq,
+ NULL, ektf2127_irq,
+ IRQF_ONESHOT, client->name, ts);
+ if (error) {
+ dev_err(dev, "Error requesting irq: %d\n", error);
+ return error;
+ }
+
+ /* Stop device till opened */
+ ektf2127_stop(ts->input);
+
+ error = input_register_device(input);
+ if (error)
+ return error;
+
+ i2c_set_clientdata(client, ts);
+
+ return 0;
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id ektf2127_of_match[] = {
+ { .compatible = "elan,ektf2127" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, ektf2127_of_match);
+#endif
+
+static const struct i2c_device_id ektf2127_i2c_id[] = {
+ { "ektf2127", 0 },
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, ektf2127_i2c_id);
+
+static struct i2c_driver ektf2127_driver = {
+ .driver = {
+ .name = "elan_ektf2127",
+ .pm = &ektf2127_pm_ops,
+ .of_match_table = of_match_ptr(ektf2127_of_match),
+ },
+ .probe = ektf2127_probe,
+ .id_table = ektf2127_i2c_id,
+};
+module_i2c_driver(ektf2127_driver);
+
+MODULE_DESCRIPTION("ELAN eKTF2127 I2C Touchscreen Driver");
+MODULE_AUTHOR("Michel Verlaan, Siebren Vroegindeweij");
+MODULE_LICENSE("GPL");
^ permalink raw reply related
* [PATCH v3 0/2] KVM: ARM: Enable vtimers with user space gic
From: Alexander Graf @ 2016-09-16 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916134619.jjiaplhxgkkl5qri@kamzik.localdomain>
> Am 16.09.2016 um 15:46 schrieb Andrew Jones <drjones@redhat.com>:
>
>> On Fri, Sep 16, 2016 at 03:30:27PM +0200, Christoffer Dall wrote:
>>> On Fri, Sep 16, 2016 at 02:31:42PM +0200, Paolo Bonzini wrote:
>>>
>>>
>>> On 16/09/2016 14:30, Christoffer Dall wrote:
>>>>>>> This patch set allows user space to receive vtimer events as well as mask
>>>>>>> them, so that we can handle all vtimer related interrupt injection from user
>>>>>>> space, enabling us to use architected timer with user space gic emulation.
>>>>>>
>>>>>> I have already voiced my concerns in the past, including face to face,
>>>>>> and I'm going to repeat it: I not keen at all on adding a new userspace
>>>>>> interface that is going to bitrot extremely quickly.
>>>>>
>>>>> You don't have automated tests set up? It's not going to bitrot if you
>>>>> test it, either with kvm-unit-tests or just by smoke-testing Linux.
>>>>> It's _for_ the raspi, but it's not limited to it.
>>>>
>>>> Our automated testing situation is not great, no. Something we're
>>>> looking at, but have resource problems with.
>>>
>>> But it's not a good reason to hold back a feature...
>>
>> I didn't say that exactly, but choosing not to merge something we cannot
>> maintain and which we're not paid to look after and where there's a
>> minimal interest, is not entirely unreasonable.
>>
>> That being said, I'm not categorically against these patches, but I
>> share Marc's view that we've already seen that non-vgic support had been
>> broken for multiple versions without anyone complaining, and without
>> automated testing or substantial interest in the work, the patches
>> really are likely to bit-rot.
>>
>> But I haven't even looked at the patches in detail, I was just replying
>> to the comment about testing.
>
> This may be a great time to start encouraging feature writers to submit
> kvm-unit-tests patches at the same time as the feature (Hi Alex :-)
I actually started off implementing this with the help of kvm-unit-tests. It's awesome!
I'm lacking actual irq support to make the test reasonable though and wanted to get the kernel bits out first :). But I'll sit down on that again soon I hope.
Alex
^ permalink raw reply
* [PATCH v6 1/2] sdhci-of-arasan: Add device tree parameter xlnx-fails-without-test-cd bit
From: Rob Herring @ 2016-09-16 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473363766-12652-1-git-send-email-zach.brown@ni.com>
On Thu, Sep 08, 2016 at 02:42:45PM -0500, Zach Brown wrote:
> The sdhci controller on xilinx zynq devices will not function unless
> the CD bit is provided. http://www.xilinx.com/support/answers/61064.html
> In cases where it is impossible to provide the CD bit in hardware,
> setting the controller to test mode and then setting inserted to true
> will get the controller to function without the CD bit.
>
> The device property "xlnx-fails-without-test-cd" will let the arasan
> driver know the controller does not have the CD line wired and that the
> controller does not function without it.
>
> Signed-off-by: Zach Brown <zach.brown@ni.com>
> ---
> v2:
> * improved commit messages
> * removed fake-cd device property
> * removed fake-cd quirk
> * use broken-cd device property
> * documented new usage of broken-cd
> v3:
> * removed new usage of broken-cd
> * created fails-without-test-cd device property
> * created arasan controller specific quirk
> v4:
> * changed fails-without-test-cd to xlnx-fails-without-test-cd
> * removed extra blank line
> v5:
> * Fixed style mistake
> * Changed (1 << 0 ) to BIT(0)
> v6:
> * Fixed style mistakes
> * Condensed unnecessarily long variable names
> * Removed line wraps that were no longer necessary.
> * Rebased changes off Ulf's mmc tree's next branch.
>
>
> Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> df --gt /Documentation/devicetree/bindings/mmc/arasan,sdhci.txt b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> index 3404afa..e71f043 100644
> --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> @@ -21,6 +21,10 @@ Required Properties:
> - interrupts: Interrupt specifier
> - interrupt-parent: Phandle for the interrupt controller that services
> interrupts for this device.
> +Optional Properties:
> +- xlnx-fails-without-test-cd: when present, the controller doesn't work when
xlnx,fails...
With that,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 1/3] ipmi: add an Aspeed BT IPMI BMC driver
From: Corey Minyard @ 2016-09-16 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474022367-21029-2-git-send-email-clg@kaod.org>
On 09/16/2016 05:39 AM, C?dric Le Goater wrote:
> From: Alistair Popple <alistair@popple.id.au>
>
> This patch adds a simple device driver to expose the iBT interface on
> Aspeed SOCs (AST2400 and AST2500) as a character device. Such SOCs are
> commonly used as BMCs (BaseBoard Management Controllers) and this
> driver implements the BMC side of the BT interface.
>
> The BT (Block Transfer) interface is used to perform in-band IPMI
> communication between a host and its BMC. Entire messages are buffered
> before sending a notification to the other end, host or BMC, that
> there is data to be read. Usually, the host emits requests and the BMC
> responses but the specification provides a mean for the BMC to send
> SMS Attention (BMC-to-Host attention or System Management Software
> attention) messages.
>
> For this purpose, the driver introduces a specific ioctl on the
> device: 'BT_BMC_IOCTL_SMS_ATN' that can be used by the system running
> on the BMC to signal the host of such an event.
>
> The device name defaults to '/dev/ipmi-bt-host'
Others have reviewed this for style and such, and I have looked
at it from a protocol point of view. it looks to be sound for the
most part. I have some higher level concerns:
There appears to be no handling for multiple simultaneous users.
This interface can only be used by one task at a time, so you should
probably only allow one opener. Well, I guess the BMC could be split
into a reader and a writer task, so I'm not really sure about that, but
I would think in most situations having more than one opener is a
bug. You do call clr_b_busy() on open, for instance, which might be
an issue for multiple openers. Maybe a module parameter for
maximum number of openers? Just want to make sure this was
thought about, at least.
There is also no mutex protecting reading or writing. If multiple
threads call read or write at the same time, it probably wouldn't
work correctly. I think you need a read and a write mutex on the
interface to protect against this.
The spec says:
The BMC must not return a given response once the corresponding
Request-to-Response interval has passed. The BMC can ensure this
by maintaining its own internal list of outstanding requests through
the interface. The BMC could age and expire the entries in the list
by expiring the entries at an interval that is somewhat shorter than
the specified Request-to-Response interval....
On the write side, though, there doesn't seem to be a way to handle a
situation where the host side doesn't respond for a while and the
pending message would need to be discarded.
The spec doesn't mention much about error recovery on this interface,
but the way this is written should be fine, I think.
I'm copying Rocky Craig, who wrote the host side driver for Linux, in
case he wants to comment on this.
This is easy to read and understand, so I think v3 should be good.
Thanks,
-corey
> Signed-off-by: Alistair Popple <alistair@popple.id.au>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> [clg: - checkpatch fixes
> - added a devicetree binding documentation
> - replace 'bt_host' by 'bt_bmc' to reflect that the driver is
> the BMC side of the IPMI BT interface
> - renamed the device to 'ipmi-bt-host'
> - introduced a temporary buffer to copy_{to,from}_user
> - used platform_get_irq()
> - moved the driver under drivers/char/ipmi/ but kept it as a misc
> device
> - changed the compatible cell to "aspeed,ast2400-bt-bmc"
> ]
> Signed-off-by: C?dric Le Goater <clg@kaod.org>
> ---
>
> Changes since v1:
>
> - replace 'bt_host' by 'bt_bmc' to reflect that the driver is
> the BMC side of the IPMI BT interface
> - renamed the device to 'ipmi-bt-host'
> - introduced a temporary buffer to copy_{to,from}_user
> - used platform_get_irq()
> - moved the driver under drivers/char/ipmi/ but kept it as a misc
> device
> - changed the compatible cell to "aspeed,ast2400-bt-bmc"
>
> .../bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt | 23 +
> drivers/Makefile | 2 +-
> drivers/char/ipmi/Kconfig | 7 +
> drivers/char/ipmi/Makefile | 1 +
> drivers/char/ipmi/bt-bmc.c | 486 +++++++++++++++++++++
> include/uapi/linux/Kbuild | 1 +
> include/uapi/linux/bt-bmc.h | 18 +
> 7 files changed, 537 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
> create mode 100644 drivers/char/ipmi/bt-bmc.c
> create mode 100644 include/uapi/linux/bt-bmc.h
>
> diff --git a/Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt b/Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
> new file mode 100644
> index 000000000000..fbbacd958240
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
> @@ -0,0 +1,23 @@
> +* Aspeed BT (Block Transfer) IPMI interface
> +
> +The Aspeed SOCs (AST2400 and AST2500) are commonly used as BMCs
> +(BaseBoard Management Controllers) and the BT interface can be used to
> +perform in-band IPMI communication with their host.
> +
> +Required properties:
> +
> +- compatible : should be "aspeed,ast2400-bt-bmc"
> +- reg: physical address and size of the registers
> +
> +Optional properties:
> +
> +- interrupts: interrupt generated by the BT interface. without an
> + interrupt, the driver will operate in poll mode.
> +
> +Example:
> +
> + ibt at 1e789140 {
> + compatible = "aspeed,ast2400-bt-bmc";
> + reg = <0x1e789140 0x18>;
> + interrupts = <8>;
> + };
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 53abb4a5f736..5a9e7b6b7928 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -21,7 +21,7 @@ obj-y += video/
> obj-y += idle/
>
> # IPMI must come before ACPI in order to provide IPMI opregion support
> -obj-$(CONFIG_IPMI_HANDLER) += char/ipmi/
> +obj-y += char/ipmi/
>
> obj-$(CONFIG_ACPI) += acpi/
> obj-$(CONFIG_SFI) += sfi/
> diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
> index 5a9350b1069a..2c234e3e7513 100644
> --- a/drivers/char/ipmi/Kconfig
> +++ b/drivers/char/ipmi/Kconfig
> @@ -76,3 +76,10 @@ config IPMI_POWEROFF
> the IPMI management controller is capable of this.
>
> endif # IPMI_HANDLER
> +
> +config ASPEED_BT_IPMI_BMC
> + tristate "BT IPMI bmc driver"
> + help
> + Provides a driver for the BT (Block Transfer) IPMI interface
> + found on Aspeed SOCs (AST2400 and AST2500). The driver
> + implements the BMC side of the BT interface.
> diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
> index f3ffde1f5f1f..0d98cd91def1 100644
> --- a/drivers/char/ipmi/Makefile
> +++ b/drivers/char/ipmi/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_IPMI_SSIF) += ipmi_ssif.o
> obj-$(CONFIG_IPMI_POWERNV) += ipmi_powernv.o
> obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o
> obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
> +obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
> diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
> new file mode 100644
> index 000000000000..b96cb421e1c2
> --- /dev/null
> +++ b/drivers/char/ipmi/bt-bmc.c
> @@ -0,0 +1,486 @@
> +/*
> + * Copyright (c) 2015-2016, IBM Corporation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/moduleparam.h>
> +#include <linux/errno.h>
> +#include <linux/poll.h>
> +#include <linux/sched.h>
> +#include <linux/spinlock.h>
> +#include <linux/slab.h>
> +#include <linux/init.h>
> +#include <linux/device.h>
> +#include <linux/of.h>
> +#include <linux/of_irq.h>
> +#include <linux/platform_device.h>
> +#include <linux/io.h>
> +#include <linux/interrupt.h>
> +#include <linux/delay.h>
> +#include <linux/miscdevice.h>
> +#include <linux/timer.h>
> +#include <linux/jiffies.h>
> +#include <linux/bt-bmc.h>
> +
> +/*
> + * This is a BMC device used to communicate to the host
> + */
> +#define DEVICE_NAME "ipmi-bt-host"
> +
> +#define BT_IO_BASE 0xe4
> +#define BT_IRQ 10
> +
> +#define BT_CR0 0x0
> +#define BT_CR0_IO_BASE 16
> +#define BT_CR0_IRQ 12
> +#define BT_CR0_EN_CLR_SLV_RDP 0x8
> +#define BT_CR0_EN_CLR_SLV_WRP 0x4
> +#define BT_CR0_ENABLE_IBT 0x1
> +#define BT_CR1 0x4
> +#define BT_CR1_IRQ_H2B 0x01
> +#define BT_CR1_IRQ_HBUSY 0x40
> +#define BT_CR2 0x8
> +#define BT_CR2_IRQ_H2B 0x01
> +#define BT_CR2_IRQ_HBUSY 0x40
> +#define BT_CR3 0xc
> +#define BT_CTRL 0x10
> +#define BT_CTRL_B_BUSY 0x80
> +#define BT_CTRL_H_BUSY 0x40
> +#define BT_CTRL_OEM0 0x20
> +#define BT_CTRL_SMS_ATN 0x10
> +#define BT_CTRL_B2H_ATN 0x08
> +#define BT_CTRL_H2B_ATN 0x04
> +#define BT_CTRL_CLR_RD_PTR 0x02
> +#define BT_CTRL_CLR_WR_PTR 0x01
> +#define BT_BMC2HOST 0x14
> +#define BT_INTMASK 0x18
> +#define BT_INTMASK_B2H_IRQEN 0x01
> +#define BT_INTMASK_B2H_IRQ 0x02
> +#define BT_INTMASK_BMC_HWRST 0x80
> +
> +struct bt_bmc {
> + struct device dev;
> + struct miscdevice miscdev;
> + void __iomem *base;
> + int open_count;
> + int irq;
> + wait_queue_head_t queue;
> + struct timer_list poll_timer;
> +};
> +
> +static u8 bt_inb(struct bt_bmc *bt_bmc, int reg)
> +{
> + return ioread8(bt_bmc->base + reg);
> +}
> +
> +static void bt_outb(struct bt_bmc *bt_bmc, u8 data, int reg)
> +{
> + iowrite8(data, bt_bmc->base + reg);
> +}
> +
> +static void clr_rd_ptr(struct bt_bmc *bt_bmc)
> +{
> + bt_outb(bt_bmc, BT_CTRL_CLR_RD_PTR, BT_CTRL);
> +}
> +
> +static void clr_wr_ptr(struct bt_bmc *bt_bmc)
> +{
> + bt_outb(bt_bmc, BT_CTRL_CLR_WR_PTR, BT_CTRL);
> +}
> +
> +static void clr_h2b_atn(struct bt_bmc *bt_bmc)
> +{
> + bt_outb(bt_bmc, BT_CTRL_H2B_ATN, BT_CTRL);
> +}
> +
> +static void set_b_busy(struct bt_bmc *bt_bmc)
> +{
> + if (!(bt_inb(bt_bmc, BT_CTRL) & BT_CTRL_B_BUSY))
> + bt_outb(bt_bmc, BT_CTRL_B_BUSY, BT_CTRL);
> +}
> +
> +static void clr_b_busy(struct bt_bmc *bt_bmc)
> +{
> + if (bt_inb(bt_bmc, BT_CTRL) & BT_CTRL_B_BUSY)
> + bt_outb(bt_bmc, BT_CTRL_B_BUSY, BT_CTRL);
> +}
> +
> +static void set_b2h_atn(struct bt_bmc *bt_bmc)
> +{
> + bt_outb(bt_bmc, BT_CTRL_B2H_ATN, BT_CTRL);
> +}
> +
> +static u8 bt_read(struct bt_bmc *bt_bmc)
> +{
> + return bt_inb(bt_bmc, BT_BMC2HOST);
> +}
> +
> +static ssize_t bt_readn(struct bt_bmc *bt_bmc, u8 *buf, size_t n)
> +{
> + int i;
> +
> + for (i = 0; i < n; i++)
> + buf[i] = bt_read(bt_bmc);
> + return n;
> +}
> +
> +static void bt_write(struct bt_bmc *bt_bmc, u8 c)
> +{
> + bt_outb(bt_bmc, c, BT_BMC2HOST);
> +}
> +
> +static ssize_t bt_writen(struct bt_bmc *bt_bmc, u8 *buf, size_t n)
> +{
> + int i;
> +
> + for (i = 0; i < n; i++)
> + bt_write(bt_bmc, buf[i]);
> + return n;
> +}
> +
> +static void set_sms_atn(struct bt_bmc *bt_bmc)
> +{
> + bt_outb(bt_bmc, BT_CTRL_SMS_ATN, BT_CTRL);
> +}
> +
> +static struct bt_bmc *file_bt_bmc(struct file *file)
> +{
> + return container_of(file->private_data, struct bt_bmc, miscdev);
> +}
> +
> +static int bt_bmc_open(struct inode *inode, struct file *file)
> +{
> + struct bt_bmc *bt_bmc = file_bt_bmc(file);
> +
> + clr_b_busy(bt_bmc);
> +
> + return 0;
> +}
> +
> +#define BT_BMC_BUFFER_SIZE 256
> +
> +/*
> + * The BT (Block Transfer) interface means that entire messages are
> + * buffered by the host before a notification is sent to the BMC that
> + * there is data to be read. The first byte is the length and the
> + * message data follows. The read operation just tries to capture the
> + * whole before returning it to userspace.
> + */
> +static ssize_t bt_bmc_read(struct file *file, char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + struct bt_bmc *bt_bmc = file_bt_bmc(file);
> + u8 len;
> + int len_byte = 1;
> + u8 kbuffer[BT_BMC_BUFFER_SIZE];
> + ssize_t ret = 0;
> + ssize_t nread;
> +
> + if (!access_ok(VERIFY_WRITE, buf, count))
> + return -EFAULT;
> +
> + WARN_ON(*ppos);
> +
> + if (wait_event_interruptible(bt_bmc->queue,
> + bt_inb(bt_bmc, BT_CTRL) & BT_CTRL_H2B_ATN))
> + return -ERESTARTSYS;
> +
> + set_b_busy(bt_bmc);
> + clr_h2b_atn(bt_bmc);
> + clr_rd_ptr(bt_bmc);
> +
> + /*
> + * The BT frames start with the message length, which does not
> + * include the length byte.
> + */
> + kbuffer[0] = bt_read(bt_bmc);
> + len = kbuffer[0];
> +
> + /* We pass the length back to userspace as well */
> + if (len + 1 > count)
> + len = count - 1;
> +
> + while (len) {
> + nread = min_t(ssize_t, len, sizeof(kbuffer) - len_byte);
> +
> + bt_readn(bt_bmc, kbuffer + len_byte, nread);
> +
> + if (copy_to_user(buf, kbuffer, nread + len_byte)) {
> + ret = -EFAULT;
> + break;
> + }
> + len -= nread;
> + buf += nread + len_byte;
> + ret += nread + len_byte;
> + len_byte = 0;
> + }
> +
> + clr_b_busy(bt_bmc);
> +
> + return ret;
> +}
> +
> +static ssize_t bt_bmc_write(struct file *file, const char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + struct bt_bmc *bt_bmc = file_bt_bmc(file);
> + u8 kbuffer[BT_BMC_BUFFER_SIZE];
> + ssize_t ret = 0;
> + ssize_t nwritten;
> +
> + if (!access_ok(VERIFY_READ, buf, count))
> + return -EFAULT;
> +
> + WARN_ON(*ppos);
> +
> + /* There's no interrupt for clearing bmc busy so we have to
> + * poll
> + */
> + if (wait_event_interruptible(bt_bmc->queue,
> + !(bt_inb(bt_bmc, BT_CTRL) &
> + (BT_CTRL_H_BUSY | BT_CTRL_B2H_ATN))))
> + return -ERESTARTSYS;
> +
> + clr_wr_ptr(bt_bmc);
> +
> + while (count) {
> + nwritten = min_t(ssize_t, count, sizeof(kbuffer));
> + if (copy_from_user(&kbuffer, buf, nwritten)) {
> + ret = -EFAULT;
> + break;
> + }
> +
> + bt_writen(bt_bmc, kbuffer, nwritten);
> +
> + count -= nwritten;
> + buf += nwritten;
> + ret += nwritten;
> + }
> +
> + set_b2h_atn(bt_bmc);
> +
> + return ret;
> +}
> +
> +static long bt_bmc_ioctl(struct file *file, unsigned int cmd,
> + unsigned long param)
> +{
> + struct bt_bmc *bt_bmc = file_bt_bmc(file);
> +
> + switch (cmd) {
> + case BT_BMC_IOCTL_SMS_ATN:
> + set_sms_atn(bt_bmc);
> + return 0;
> + }
> + return -EINVAL;
> +}
> +
> +static int bt_bmc_release(struct inode *inode, struct file *file)
> +{
> + struct bt_bmc *bt_bmc = file_bt_bmc(file);
> +
> + set_b_busy(bt_bmc);
> + return 0;
> +}
> +
> +static unsigned int bt_bmc_poll(struct file *file, poll_table *wait)
> +{
> + struct bt_bmc *bt_bmc = file_bt_bmc(file);
> + unsigned int mask = 0;
> + uint8_t ctrl;
> +
> + poll_wait(file, &bt_bmc->queue, wait);
> +
> + ctrl = bt_inb(bt_bmc, BT_CTRL);
> +
> + if (ctrl & BT_CTRL_H2B_ATN)
> + mask |= POLLIN;
> +
> + if (!(ctrl & (BT_CTRL_H_BUSY | BT_CTRL_B2H_ATN)))
> + mask |= POLLOUT;
> +
> + return mask;
> +}
> +
> +static const struct file_operations bt_bmc_fops = {
> + .owner = THIS_MODULE,
> + .open = bt_bmc_open,
> + .read = bt_bmc_read,
> + .write = bt_bmc_write,
> + .release = bt_bmc_release,
> + .poll = bt_bmc_poll,
> + .unlocked_ioctl = bt_bmc_ioctl,
> +};
> +
> +static void poll_timer(unsigned long data)
> +{
> + struct bt_bmc *bt_bmc = (void *)data;
> +
> + bt_bmc->poll_timer.expires += msecs_to_jiffies(500);
> + wake_up(&bt_bmc->queue);
> + add_timer(&bt_bmc->poll_timer);
> +}
> +
> +static irqreturn_t bt_bmc_irq(int irq, void *arg)
> +{
> + struct bt_bmc *bt_bmc = arg;
> + uint32_t reg;
> +
> + reg = ioread32(bt_bmc->base + BT_CR2);
> + reg &= BT_CR2_IRQ_H2B | BT_CR2_IRQ_HBUSY;
> + if (!reg)
> + return IRQ_NONE;
> +
> + /* ack pending IRQs */
> + iowrite32(reg, bt_bmc->base + BT_CR2);
> +
> + wake_up(&bt_bmc->queue);
> + return IRQ_HANDLED;
> +}
> +
> +static int bt_bmc_config_irq(struct bt_bmc *bt_bmc,
> + struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + uint32_t reg;
> + int rc;
> +
> + bt_bmc->irq = platform_get_irq(pdev, 0);
> + if (!bt_bmc->irq)
> + return -ENODEV;
> +
> + rc = devm_request_irq(dev, bt_bmc->irq, bt_bmc_irq, IRQF_SHARED,
> + DEVICE_NAME, bt_bmc);
> + if (rc < 0) {
> + dev_warn(dev, "Unable to request IRQ %d\n", bt_bmc->irq);
> + bt_bmc->irq = 0;
> + return rc;
> + }
> +
> + /* Configure IRQs on the bmc clearing the H2B and HBUSY bits;
> + * H2B will be asserted when the bmc has data for us; HBUSY
> + * will be cleared (along with B2H) when we can write the next
> + * message to the BT buffer
> + */
> + reg = ioread32(bt_bmc->base + BT_CR1);
> + reg |= BT_CR1_IRQ_H2B | BT_CR1_IRQ_HBUSY;
> + iowrite32(reg, bt_bmc->base + BT_CR1);
> +
> + return 0;
> +}
> +
> +static int bt_bmc_probe(struct platform_device *pdev)
> +{
> + struct bt_bmc *bt_bmc;
> + struct device *dev;
> + struct resource *res;
> + int rc;
> +
> + if (!pdev || !pdev->dev.of_node)
> + return -ENODEV;
> +
> + dev = &pdev->dev;
> + dev_info(dev, "Found bt bmc device\n");
> +
> + bt_bmc = devm_kzalloc(dev, sizeof(*bt_bmc), GFP_KERNEL);
> + if (!bt_bmc)
> + return -ENOMEM;
> +
> + dev_set_drvdata(&pdev->dev, bt_bmc);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(dev, "Unable to find resources\n");
> + rc = -ENXIO;
> + goto out_free;
> + }
> +
> + bt_bmc->base = devm_ioremap_resource(&pdev->dev, res);
> + if (!bt_bmc->base) {
> + rc = -ENOMEM;
> + goto out_free;
> + }
> +
> + init_waitqueue_head(&bt_bmc->queue);
> +
> + bt_bmc->miscdev.minor = MISC_DYNAMIC_MINOR,
> + bt_bmc->miscdev.name = DEVICE_NAME,
> + bt_bmc->miscdev.fops = &bt_bmc_fops,
> + bt_bmc->miscdev.parent = dev;
> + rc = misc_register(&bt_bmc->miscdev);
> + if (rc) {
> + dev_err(dev, "Unable to register device\n");
> + goto out_unmap;
> + }
> +
> + bt_bmc_config_irq(bt_bmc, pdev);
> +
> + if (bt_bmc->irq) {
> + dev_info(dev, "Using IRQ %d\n", bt_bmc->irq);
> + } else {
> + dev_info(dev, "No IRQ; using timer\n");
> + setup_timer(&bt_bmc->poll_timer, poll_timer,
> + (unsigned long)bt_bmc);
> + bt_bmc->poll_timer.expires = jiffies + msecs_to_jiffies(10);
> + add_timer(&bt_bmc->poll_timer);
> + }
> +
> + iowrite32((BT_IO_BASE << BT_CR0_IO_BASE) |
> + (BT_IRQ << BT_CR0_IRQ) |
> + BT_CR0_EN_CLR_SLV_RDP |
> + BT_CR0_EN_CLR_SLV_WRP |
> + BT_CR0_ENABLE_IBT,
> + bt_bmc->base + BT_CR0);
> +
> + clr_b_busy(bt_bmc);
> +
> + return 0;
> +
> +out_unmap:
> + devm_iounmap(&pdev->dev, bt_bmc->base);
> +
> +out_free:
> + devm_kfree(dev, bt_bmc);
> + return rc;
> +
> +}
> +
> +static int bt_bmc_remove(struct platform_device *pdev)
> +{
> + struct bt_bmc *bt_bmc = dev_get_drvdata(&pdev->dev);
> +
> + misc_deregister(&bt_bmc->miscdev);
> + if (!bt_bmc->irq)
> + del_timer_sync(&bt_bmc->poll_timer);
> + devm_iounmap(&pdev->dev, bt_bmc->base);
> + devm_kfree(&pdev->dev, bt_bmc);
> + bt_bmc = NULL;
> +
> + return 0;
> +}
> +
> +static const struct of_device_id bt_bmc_match[] = {
> + { .compatible = "aspeed,ast2400-bt-bmc" },
> + { },
> +};
> +
> +static struct platform_driver bt_bmc_driver = {
> + .driver = {
> + .name = DEVICE_NAME,
> + .of_match_table = bt_bmc_match,
> + },
> + .probe = bt_bmc_probe,
> + .remove = bt_bmc_remove,
> +};
> +
> +module_platform_driver(bt_bmc_driver);
> +
> +MODULE_DEVICE_TABLE(of, bt_bmc_match);
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Alistair Popple <alistair@popple.id.au>");
> +MODULE_DESCRIPTION("Linux device interface to the BT interface");
> diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
> index 185f8ea2702f..17b12942c67d 100644
> --- a/include/uapi/linux/Kbuild
> +++ b/include/uapi/linux/Kbuild
> @@ -74,6 +74,7 @@ header-y += bpf_common.h
> header-y += bpf.h
> header-y += bpqether.h
> header-y += bsg.h
> +header-y += bt-bmc.h
> header-y += btrfs.h
> header-y += can.h
> header-y += capability.h
> diff --git a/include/uapi/linux/bt-bmc.h b/include/uapi/linux/bt-bmc.h
> new file mode 100644
> index 000000000000..d9ec766a63d0
> --- /dev/null
> +++ b/include/uapi/linux/bt-bmc.h
> @@ -0,0 +1,18 @@
> +/*
> + * Copyright (c) 2015-2016, IBM Corporation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#ifndef _UAPI_LINUX_BT_BMC_H
> +#define _UAPI_LINUX_BT_BMC_H
> +
> +#include <linux/ioctl.h>
> +
> +#define __BT_BMC_IOCTL_MAGIC 0xb1
> +#define BT_BMC_IOCTL_SMS_ATN _IO(__BT_BMC_IOCTL_MAGIC, 0x00)
> +
> +#endif /* _UAPI_LINUX_BT_BMC_H */
^ permalink raw reply
* [RFC PATCH 00/10] ARM: dts: exynos: Fix invalid GIC interrupt flags
From: Krzysztof Kozlowski @ 2016-09-16 19:42 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Marek (internally), Geert and Alban reported errors like:
genirq: Setting trigger mode 0 for irq 16 failed (gic_set_type+0x0/0x68)
The patchset fixes this issue.
Tested on:
1. Exynos4412: Odroid U3,
2. Exynos5410: Odroid XU,
3. Exynos5422: Odroid XU3.
Other platforms not tested so testing would be highly appreciated.
Best regards,
Krzysztof
Krzysztof Kozlowski (10):
ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos4
ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos4210
ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos4x12
ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos4415
ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos3250
ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos5
ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos5250
ARM: dts: exynos: Fix invalid GIC interrupt flags in
exynos5410/exynos542x
ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos5260
ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos5440
arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 20 +++++--
arch/arm/boot/dts/exynos3250.dtsi | 93 +++++++++++++++++-------------
arch/arm/boot/dts/exynos4.dtsi | 94 ++++++++++++++++---------------
arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 20 +++++--
arch/arm/boot/dts/exynos4210.dtsi | 36 ++++++++----
arch/arm/boot/dts/exynos4415-pinctrl.dtsi | 20 +++++--
arch/arm/boot/dts/exynos4415.dtsi | 92 +++++++++++++++++-------------
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 20 +++++--
arch/arm/boot/dts/exynos4x12.dtsi | 48 ++++++++++------
arch/arm/boot/dts/exynos5.dtsi | 60 ++++++++++++++------
arch/arm/boot/dts/exynos5250.dtsi | 80 +++++++++++++-------------
arch/arm/boot/dts/exynos5260.dtsi | 39 ++++++++-----
arch/arm/boot/dts/exynos5410.dtsi | 26 ++++-----
arch/arm/boot/dts/exynos5420.dtsi | 78 ++++++++++++-------------
arch/arm/boot/dts/exynos5440.dtsi | 48 ++++++++++------
arch/arm/boot/dts/exynos54xx.dtsi | 34 +++++------
16 files changed, 485 insertions(+), 323 deletions(-)
--
2.7.4
^ 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