Linux-ARM-Kernel Archive on lore.kernel.org

Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed

* [PATCH] clocksource: arm_arch_timer: print timer value at init time
From: Olof Johansson @ 2016-12-19 17:47 UTC (permalink / raw)
  To: linux-arm-kernel

This is useful to get an indication of how much time we spent in firmware.

It's not guaranteed that the timer started at 0 on reset, so it's just
an approximation, and might very well be invalid on some systems. But
it's still a useful metric to have access to.

Signed-off-by: Olof Johansson <olof@lixom.net>
---
 drivers/clocksource/arm_arch_timer.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 02fef68..c26078b 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -521,6 +521,8 @@ arch_timer_detect_rate(void __iomem *cntbase, struct device_node *np)
 
 static void arch_timer_banner(unsigned type)
 {
+	unsigned long cnt = arch_timer_read_counter();
+
 	pr_info("Architected %s%s%s timer(s) running at %lu.%02luMHz (%s%s%s).\n",
 		     type & ARCH_CP15_TIMER ? "cp15" : "",
 		     type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ?  " and " : "",
@@ -534,6 +536,8 @@ static void arch_timer_banner(unsigned type)
 		     type & ARCH_MEM_TIMER ?
 			arch_timer_mem_use_virtual ? "virt" : "phys" :
 			"");
+	pr_info("Initial timer value: 0x%lx: %ld.%02lds\n",
+		cnt, cnt/arch_timer_rate, (cnt/(arch_timer_rate/100)) % 100);
 }
 
 u32 arch_timer_get_rate(void)
-- 
2.8.0.rc3.29.gb552ff8

^ permalink raw reply related

* [PATCH 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
From: Laurent Pinchart @ 2016-12-19 17:18 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <C246CAC1457055469EF09E3A7AC4E11A4A65D58E@XAP-PVEXMBX01.xlnx.xilinx.com>

Hi Kedar,

On Monday 19 Dec 2016 15:39:43 Appana Durga Kedareswara Rao wrote:
> Hi Laurent Pinchart,
> 
> 	Thanks for the review...
> 
> > > +	if (!chan->idle)
> > > +		return;
> > 
> > Don't you need to perform the same check for the DMA and CDMA channels ?
> > If so, shouldn't this be moved to common code ?
> 
> Will fix it in v2...
> 
> > There's another problem (not strictly introduced by this patch) I wanted
> > to mention. The append_desc_queue() function, called from your tx_submit
> > handler, appends descriptors to the pending_list. The DMA engine API
> > states that a transfer submitted by tx_submit will not be executed until
> > .issue_pending() is called. However, if a transfer is in progress at
> > tx_submit time, I believe that the IRQ handler, at transfer completion,
> > will start the next transfer from the pending_list even if
> > .issue_pending() hasn't been called for it.
> > 
> > >  	if (list_empty(&chan->pending_list))
> > >  		return;
> 
> If user submits more than h/w limit then that case only driver will process
> The descriptors from the pending_list for other cases the pending_list will
> be Empty so driver just returns from there.

I understand that, but that's not the problem. Your .tx_submit() handler calls 
append_desc_queue() which adds the tx descriptor to the pending_list. If a 
transfer is in progress at that time, I believe the transfer completion IRQ 
handler will take the next descriptor from the pending_list and process it, 
even though issue_pending() hasn't been called for it.

> > Now that you catch busy channels with a software flag, do you still need
> > the xilinx_dma_is_running() and xilinx_dma_is_idle() checks ? Three
> > different checks for the same or very similar conditions are confusing,
> > if you really need them you should document clearly how they differ.
> 
> Will remove the xilinx_dma_is_running and xilinx_dmais_idle() checks and
> will use Chan->idle check across all the IP's. Will fix it v2...
> 
> > > @@ -1110,6 +1116,7 @@ static void xilinx_vdma_start_transfer(struct
> > > xilinx_dma_chan *chan) vdma_desc_write(chan, XILINX_DMA_REG_VSIZE,
> > > last->hw.vsize);
> > > 
> > >  	}
> > > 
> > > +	chan->idle = false;
> > 
> > (and this too)
> 
> Will fix in v2...

-- 
Regards,

Laurent Pinchart

^ permalink raw reply

* [PATCH v10 6/8] arm/arm64: vgic: Implement VGICv3 CPU interface access
From: Auger Eric @ 2016-12-19 17:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1480576187-5012-7-git-send-email-vijay.kilari@gmail.com>

Hi Vijaya, Christoffer,

On 01/12/2016 08:09, 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 VM that supports SEIs expect it on destination machine to handle
> guest aborts and hence checked for ICC_CTLR_EL1.SEIS compatibility.
> Similarly, VM that supports Affinity Level 3 that is required for AArch64
> mode, is required to be supported on destination machine. Hence checked
> for ICC_CTLR_EL1.A3V compatibility.
> 
> The arch/arm64/kvm/vgic-sys-reg-v3.c handles read and write of VGIC
> CPU registers for AArch64.
> 
> For AArch32 mode, arch/arm/kvm/vgic-v3-coproc.c file is created but
> APIs are not implemented.
> 
> Updated arch/arm/include/uapi/asm/kvm.h with new definitions
> required to compile for AArch32.
> 
> The version of VGIC v3 specification is define here
> Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> 
> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> ---
>  arch/arm/include/uapi/asm/kvm.h     |   2 +
>  arch/arm/kvm/Makefile               |   4 +-
>  arch/arm/kvm/vgic-v3-coproc.c       |  35 ++++
>  arch/arm64/include/uapi/asm/kvm.h   |   3 +
>  arch/arm64/kvm/Makefile             |   3 +-
>  arch/arm64/kvm/vgic-sys-reg-v3.c    | 338 ++++++++++++++++++++++++++++++++++++
>  include/kvm/arm_vgic.h              |   9 +
>  virt/kvm/arm/vgic/vgic-kvm-device.c |  28 +++
>  virt/kvm/arm/vgic/vgic-mmio-v3.c    |  18 ++
>  virt/kvm/arm/vgic/vgic-v3.c         |   8 +
>  virt/kvm/arm/vgic/vgic.h            |   4 +
>  11 files changed, 449 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
> index 0ae6035..98658d9d 100644
> --- a/arch/arm/include/uapi/asm/kvm.h
> +++ b/arch/arm/include/uapi/asm/kvm.h
> @@ -186,9 +186,11 @@ 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
nit: arm-vgic-v3.txt spec uses that name. To be homogeneous with other
groups, shouldn't we correct this into KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS?

Thanks

Eric
>  #define   KVM_DEV_ARM_VGIC_CTRL_INIT    0
>  
>  /* KVM_IRQ_LINE irq field index values */
> diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile
> index d571243..68fb023 100644
> --- a/arch/arm/kvm/Makefile
> +++ b/arch/arm/kvm/Makefile
> @@ -7,7 +7,7 @@ ifeq ($(plus_virt),+virt)
>  	plus_virt_def := -DREQUIRES_VIRT=1
>  endif
>  
> -ccflags-y += -Iarch/arm/kvm
> +ccflags-y += -Iarch/arm/kvm -Ivirt/kvm/arm/vgic
>  CFLAGS_arm.o := -I. $(plus_virt_def)
>  CFLAGS_mmu.o := -I.
>  
> @@ -20,7 +20,7 @@ kvm-arm-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o $(KVM)/vf
>  obj-$(CONFIG_KVM_ARM_HOST) += hyp/
>  obj-y += kvm-arm.o init.o interrupts.o
>  obj-y += arm.o handle_exit.o guest.o mmu.o emulate.o reset.o
> -obj-y += coproc.o coproc_a15.o coproc_a7.o mmio.o psci.o perf.o
> +obj-y += coproc.o coproc_a15.o coproc_a7.o mmio.o psci.o perf.o vgic-v3-coproc.o
>  obj-y += $(KVM)/arm/aarch32.o
>  
>  obj-y += $(KVM)/arm/vgic/vgic.o
> diff --git a/arch/arm/kvm/vgic-v3-coproc.c b/arch/arm/kvm/vgic-v3-coproc.c
> new file mode 100644
> index 0000000..f41abf7
> --- /dev/null
> +++ b/arch/arm/kvm/vgic-v3-coproc.c
> @@ -0,0 +1,35 @@
> +/*
> + * VGIC system registers handling functions for AArch32 mode
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/kvm.h>
> +#include <linux/kvm_host.h>
> +#include <asm/kvm_emulate.h>
> +#include "vgic.h"
> +
> +int vgic_v3_has_cpu_sysregs_attr(struct kvm_vcpu *vcpu, bool is_write, u64 id,
> +				 u64 *reg)
> +{
> +	/*
> +	 * TODO: Implement for AArch32
> +	 */
> +	return -ENXIO;
> +}
> +
> +int vgic_v3_cpu_sysregs_uaccess(struct kvm_vcpu *vcpu, bool is_write, u64 id,
> +				u64 *reg)
> +{
> +	/*
> +	 * TODO: Implement for AArch32
> +	 */
> +	return -ENXIO;
> +}
> 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..d89aa50 100644
> --- a/arch/arm64/kvm/Makefile
> +++ b/arch/arm64/kvm/Makefile
> @@ -2,7 +2,7 @@
>  # Makefile for Kernel-based Virtual Machine module
>  #
>  
> -ccflags-y += -Iarch/arm64/kvm
> +ccflags-y += -Iarch/arm64/kvm -Ivirt/kvm/arm/vgic
>  CFLAGS_arm.o := -I.
>  CFLAGS_mmu.o := -I.
>  
> @@ -19,6 +19,7 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(ARM)/psci.o $(ARM)/perf.o
>  kvm-$(CONFIG_KVM_ARM_HOST) += inject_fault.o regmap.o
>  kvm-$(CONFIG_KVM_ARM_HOST) += hyp.o hyp-init.o handle_exit.o
>  kvm-$(CONFIG_KVM_ARM_HOST) += guest.o debug.o reset.o sys_regs.o sys_regs_generic_v8.o
> +kvm-$(CONFIG_KVM_ARM_HOST) += vgic-sys-reg-v3.o
>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/aarch32.o
>  
>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic.o
> diff --git a/arch/arm64/kvm/vgic-sys-reg-v3.c b/arch/arm64/kvm/vgic-sys-reg-v3.c
> new file mode 100644
> index 0000000..76663f9
> --- /dev/null
> +++ b/arch/arm64/kvm/vgic-sys-reg-v3.c
> @@ -0,0 +1,338 @@
> +/*
> + * VGIC system registers handling functions for AArch64 mode
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/irqchip/arm-gic-v3.h>
> +#include <linux/kvm.h>
> +#include <linux/kvm_host.h>
> +#include <asm/kvm_emulate.h>
> +#include "vgic.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)
> +{
> +	u32 host_pri_bits, host_id_bits, host_seis, host_a3v, seis, a3v;
> +	struct vgic_cpu *vgic_v3_cpu = &vcpu->arch.vgic_cpu;
> +	struct vgic_vmcr vmcr;
> +	u64 val;
> +
> +	vgic_get_vmcr(vcpu, &vmcr);
> +	if (p->is_write) {
> +		val = p->regval;
> +
> +		/*
> +		 * Disallow restoring VM state if not supported by this
> +		 * hardware.
> +		 */
> +		host_pri_bits = ((val & ICC_CTLR_EL1_PRI_BITS_MASK) >>
> +				 ICC_CTLR_EL1_PRI_BITS_SHIFT) + 1;
> +		if (host_pri_bits > vgic_v3_cpu->num_pri_bits)
> +			return false;
> +
> +		vgic_v3_cpu->num_pri_bits = host_pri_bits;
> +
> +		host_id_bits = (val & ICC_CTLR_EL1_ID_BITS_MASK) >>
> +				ICC_CTLR_EL1_ID_BITS_SHIFT;
> +		if (host_id_bits > vgic_v3_cpu->num_id_bits)
> +			return false;
> +
> +		vgic_v3_cpu->num_id_bits = host_id_bits;
> +
> +		host_seis = ((kvm_vgic_global_state.ich_vtr_el2 &
> +			     ICH_VTR_SEIS_MASK) >> ICH_VTR_SEIS_SHIFT);
> +		seis = (val & ICC_CTLR_EL1_SEIS_MASK) >>
> +			ICC_CTLR_EL1_SEIS_SHIFT;
> +		if (host_seis != seis)
> +			return false;
> +
> +		host_a3v = ((kvm_vgic_global_state.ich_vtr_el2 &
> +			    ICH_VTR_A3V_MASK) >> ICH_VTR_A3V_SHIFT);
> +		a3v = (val & ICC_CTLR_EL1_A3V_MASK) >> ICC_CTLR_EL1_A3V_SHIFT;
> +		if (host_a3v != a3v)
> +			return false;
> +
> +		vmcr.ctlr = val & ICC_CTLR_EL1_CBPR_MASK;
> +		vmcr.ctlr |= val & ICC_CTLR_EL1_EOImode_MASK;
> +		vgic_set_vmcr(vcpu, &vmcr);
> +	} else {
> +		val = 0;
> +		val |= (vgic_v3_cpu->num_pri_bits - 1) <<
> +			ICC_CTLR_EL1_PRI_BITS_SHIFT;
> +		val |= vgic_v3_cpu->num_id_bits << ICC_CTLR_EL1_ID_BITS_SHIFT;
> +		val |= ((kvm_vgic_global_state.ich_vtr_el2 &
> +			ICH_VTR_SEIS_MASK) >> ICH_VTR_SEIS_SHIFT) <<
> +			ICC_CTLR_EL1_SEIS_SHIFT;
> +		val |= ((kvm_vgic_global_state.ich_vtr_el2 &
> +			ICH_VTR_A3V_MASK) >> ICH_VTR_A3V_SHIFT) <<
> +			ICC_CTLR_EL1_A3V_SHIFT;
> +		val |= vmcr.ctlr & ICC_CTLR_EL1_CBPR_MASK;
> +		val |= vmcr.ctlr & ICC_CTLR_EL1_EOImode_MASK;
> +
> +		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;
> +
> +	if (!p->is_write)
> +		p->regval = 0;
> +
> +	vgic_get_vmcr(vcpu, &vmcr);
> +	if (!((vmcr.ctlr & ICH_VMCR_CBPR_MASK) >> ICH_VMCR_CBPR_SHIFT)) {
> +		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;
> +		}
> +	} else {
> +		if (!p->is_write)
> +			p->regval = min((vmcr.bpr + 1), 7U);
> +	}
> +
> +	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;
> +	}
> +
> +	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 bool access_gic_aprn(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> +			    const struct sys_reg_desc *r, u8 apr)
> +{
> +	struct vgic_cpu *vgic_v3_cpu = &vcpu->arch.vgic_cpu;
> +	u8 idx = r->Op2 & 3;
> +
> +	/*
> +	 * num_pri_bits are initialized with HW supported values.
> +	 * We can rely safely on num_pri_bits even if VM has not
> +	 * restored ICC_CTLR_EL1 before restoring APnR registers.
> +	 */
> +	switch (vgic_v3_cpu->num_pri_bits) {
> +	case 7:
> +		vgic_v3_access_apr_reg(vcpu, p, apr, idx);
> +		break;
> +	case 6:
> +		if (idx > 1)
> +			goto err;
> +		vgic_v3_access_apr_reg(vcpu, p, apr, idx);
> +		break;
> +	default:
> +		if (idx > 0)
> +			goto err;
> +		vgic_v3_access_apr_reg(vcpu, p, apr, idx);
> +	}
> +
> +	return true;
> +err:
> +	if (!p->is_write)
> +		p->regval = 0;
> +
> +	return false;
> +}
> +
> +static bool access_gic_ap0r(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> +			    const struct sys_reg_desc *r)
> +
> +{
> +	return access_gic_aprn(vcpu, p, r, 0);
> +}
> +
> +static bool access_gic_ap1r(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> +			    const struct sys_reg_desc *r)
> +{
> +	return access_gic_aprn(vcpu, p, r, 1);
> +}
> +
> +static bool access_gic_sre(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> +			   const struct sys_reg_desc *r)
> +{
> +	struct vgic_v3_cpu_if *vgicv3 = &vcpu->arch.vgic_cpu.vgic_v3;
> +
> +	/* Validate SRE bit */
> +	if (p->is_write) {
> +		if (!(p->regval & ICC_SRE_EL1_SRE))
> +			return false;
> +	} else {
> +		p->regval = vgicv3->vgic_sre;
> +	}
> +
> +	return true;
> +}
> +static const struct sys_reg_desc gic_v3_icc_reg_descs[] = {
> +	/* ICC_PMR_EL1 */
> +	{ Op0(3), Op1(0), CRn(4), CRm(6), Op2(0), access_gic_pmr },
> +	/* ICC_BPR0_EL1 */
> +	{ Op0(3), Op1(0), CRn(12), CRm(8), Op2(3), access_gic_bpr0 },
> +	/* ICC_AP0R0_EL1 */
> +	{ Op0(3), Op1(0), CRn(12), CRm(8), Op2(4), access_gic_ap0r },
> +	/* ICC_AP0R1_EL1 */
> +	{ Op0(3), Op1(0), CRn(12), CRm(8), Op2(5), access_gic_ap0r },
> +	/* ICC_AP0R2_EL1 */
> +	{ Op0(3), Op1(0), CRn(12), CRm(8), Op2(6), access_gic_ap0r },
> +	/* ICC_AP0R3_EL1 */
> +	{ Op0(3), Op1(0), CRn(12), CRm(8), Op2(7), access_gic_ap0r },
> +	/* ICC_AP1R0_EL1 */
> +	{ Op0(3), Op1(0), CRn(12), CRm(9), Op2(0), access_gic_ap1r },
> +	/* ICC_AP1R1_EL1 */
> +	{ Op0(3), Op1(0), CRn(12), CRm(9), Op2(1), access_gic_ap1r },
> +	/* ICC_AP1R2_EL1 */
> +	{ Op0(3), Op1(0), CRn(12), CRm(9), Op2(2), access_gic_ap1r },
> +	/* ICC_AP1R3_EL1 */
> +	{ Op0(3), Op1(0), CRn(12), CRm(9), Op2(3), access_gic_ap1r },
> +	/* ICC_BPR1_EL1 */
> +	{ Op0(3), Op1(0), CRn(12), CRm(12), Op2(3), access_gic_bpr1 },
> +	/* ICC_CTLR_EL1 */
> +	{ Op0(3), Op1(0), CRn(12), CRm(12), Op2(4), access_gic_ctlr },
> +	/* ICC_SRE_EL1 */
> +	{ Op0(3), Op1(0), CRn(12), CRm(12), Op2(5), access_gic_sre },
> +	/* ICC_IGRPEN0_EL1 */
> +	{ Op0(3), Op1(0), CRn(12), CRm(12), Op2(6), access_gic_grpen0 },
> +	/* ICC_GRPEN1_EL1 */
> +	{ Op0(3), Op1(0), CRn(12), CRm(12), Op2(7), access_gic_grpen1 },
> +};
> +
> +int vgic_v3_has_cpu_sysregs_attr(struct kvm_vcpu *vcpu, bool is_write, u64 id,
> +				u64 *reg)
> +{
> +	struct sys_reg_params params;
> +	u64 sysreg = (id & KVM_DEV_ARM_VGIC_SYSREG_MASK) | KVM_REG_SIZE_U64;
> +
> +	params.regval = *reg;
> +	params.is_write = is_write;
> +	params.is_aarch32 = false;
> +	params.is_32bit = false;
> +
> +	if (find_reg_by_id(sysreg, &params, gic_v3_icc_reg_descs,
> +			      ARRAY_SIZE(gic_v3_icc_reg_descs)))
> +		return 0;
> +
> +	return -ENXIO;
> +}
> +
> +int vgic_v3_cpu_sysregs_uaccess(struct kvm_vcpu *vcpu, bool is_write, u64 id,
> +				u64 *reg)
> +{
> +	struct sys_reg_params params;
> +	const struct sys_reg_desc *r;
> +	u64 sysreg = (id & KVM_DEV_ARM_VGIC_SYSREG_MASK) | KVM_REG_SIZE_U64;
> +
> +	if (is_write)
> +		params.regval = *reg;
> +	params.is_write = is_write;
> +	params.is_aarch32 = false;
> +	params.is_32bit = false;
> +
> +	r = find_reg_by_id(sysreg, &params, gic_v3_icc_reg_descs,
> +			   ARRAY_SIZE(gic_v3_icc_reg_descs));
> +	if (!r)
> +		return -ENXIO;
> +
> +	if (!r->access(vcpu, &params, r))
> +		return -EINVAL;
> +
> +	if (!is_write)
> +		*reg = params.regval;
> +
> +	return 0;
> +}
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index 002f092..730a18a 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -71,6 +71,9 @@ struct vgic_global {
>  
>  	/* GIC system register CPU interface */
>  	struct static_key_false gicv3_cpuif;
> +
> +	/* Cache ICH_VTR_EL2 reg value */
> +	u32			ich_vtr_el2;
>  };
>  
>  extern struct vgic_global kvm_vgic_global_state;
> @@ -269,6 +272,12 @@ struct vgic_cpu {
>  	u64 pendbaser;
>  
>  	bool lpis_enabled;
> +
> +	/* Cache guest priority bits */
> +	u32 num_pri_bits;
> +
> +	/* Cache guest interrupt ID bits */
> +	u32 num_id_bits;
>  };
>  
>  extern struct static_key_false vgic_v2_cpuif_trap;
> diff --git a/virt/kvm/arm/vgic/vgic-kvm-device.c b/virt/kvm/arm/vgic/vgic-kvm-device.c
> index bc7de95..b6266fe 100644
> --- a/virt/kvm/arm/vgic/vgic-kvm-device.c
> +++ b/virt/kvm/arm/vgic/vgic-kvm-device.c
> @@ -16,6 +16,7 @@
>  #include <linux/kvm_host.h>
>  #include <kvm/arm_vgic.h>
>  #include <linux/uaccess.h>
> +#include <asm/kvm_emulate.h>
>  #include <asm/kvm_mmu.h>
>  #include "vgic.h"
>  
> @@ -501,6 +502,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;
> @@ -534,6 +543,15 @@ static int vgic_v3_set_attr(struct kvm_device *dev,
>  		reg = tmp32;
>  		return vgic_v3_attr_regs_access(dev, attr, &reg, 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, &reg, true);
> +	}
>  	}
>  	return -ENXIO;
>  }
> @@ -560,6 +578,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, &reg, false);
> +		if (ret)
> +			return ret;
> +		return put_user(reg, uaddr);
> +	}
>  	}
>  
>  	return -ENXIO;
> @@ -578,6 +605,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 e4799ae..51439c9 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> @@ -642,6 +642,24 @@ 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 vgic_mpidr, mpidr_reg;
> +		struct kvm_vcpu *vcpu;
> +
> +		vgic_mpidr = (attr->attr & KVM_DEV_ARM_VGIC_V3_MPIDR_MASK) >>
> +			      KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT;
> +
> +		/* Convert plain mpidr value to MPIDR reg format */
> +		mpidr_reg = VGIC_TO_MPIDR(vgic_mpidr);
> +
> +		vcpu = kvm_mpidr_to_vcpu(dev->kvm, mpidr_reg);
> +		if (!vcpu)
> +			return -EINVAL;
> +
> +		id = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK);
> +		return vgic_v3_has_cpu_sysregs_attr(vcpu, 0, id, &reg);
> +	}
>  	default:
>  		return -ENXIO;
>  	}
> diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
> index c21968b..c98a1c5 100644
> --- a/virt/kvm/arm/vgic/vgic-v3.c
> +++ b/virt/kvm/arm/vgic/vgic-v3.c
> @@ -238,6 +238,13 @@ void vgic_v3_enable(struct kvm_vcpu *vcpu)
>  		vgic_v3->vgic_sre = 0;
>  	}
>  
> +	vcpu->arch.vgic_cpu.num_id_bits = (kvm_vgic_global_state.ich_vtr_el2 &
> +					   ICH_VTR_ID_BITS_MASK) >>
> +					   ICH_VTR_ID_BITS_SHIFT;
> +	vcpu->arch.vgic_cpu.num_pri_bits = ((kvm_vgic_global_state.ich_vtr_el2 &
> +					    ICH_VTR_PRI_BITS_MASK) >>
> +					    ICH_VTR_PRI_BITS_SHIFT) + 1;
> +
>  	/* Get the show on the road... */
>  	vgic_v3->vgic_hcr = ICH_HCR_EN;
>  }
> @@ -338,6 +345,7 @@ int vgic_v3_probe(const struct gic_kvm_info *info)
>  	 */
>  	kvm_vgic_global_state.nr_lr = (ich_vtr_el2 & 0xf) + 1;
>  	kvm_vgic_global_state.can_emulate_gicv2 = false;
> +	kvm_vgic_global_state.ich_vtr_el2 = ich_vtr_el2;
>  
>  	if (!info->vcpu.start) {
>  		kvm_info("GICv3: no GICV resource entry\n");
> diff --git a/virt/kvm/arm/vgic/vgic.h b/virt/kvm/arm/vgic/vgic.h
> index 9232791..eac272c 100644
> --- a/virt/kvm/arm/vgic/vgic.h
> +++ b/virt/kvm/arm/vgic/vgic.h
> @@ -140,6 +140,10 @@ int vgic_v3_dist_uaccess(struct kvm_vcpu *vcpu, bool is_write,
>  			 int offset, u32 *val);
>  int vgic_v3_redist_uaccess(struct kvm_vcpu *vcpu, bool is_write,
>  			 int offset, u32 *val);
> +int vgic_v3_cpu_sysregs_uaccess(struct kvm_vcpu *vcpu, bool is_write,
> +			 u64 id, u64 *val);
> +int vgic_v3_has_cpu_sysregs_attr(struct kvm_vcpu *vcpu, bool is_write, u64 id,
> +				u64 *reg);
>  int kvm_register_vgic_device(unsigned long type);
>  void vgic_set_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr);
>  void vgic_get_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr);
> 

^ permalink raw reply

* [PATCH] drm: tilcdc: simplify the recovery from sync lost error on rev1
From: Jyri Sarha @ 2016-12-19 16:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAMpxmJVHXoP0BokfbPwQmC=eBaNfS5yfG77EB_MnScmSbUVAdA@mail.gmail.com>

On 12/19/16 16:19, Bartosz Golaszewski wrote:
>> I would add here:
>> +               if ((tilcdc_read(dev, LCDC_RASTER_CTRL_REG) &
>> +                               LCDC_RASTER_ENABLE)) {
>>
>>> +                     tilcdc_clear(dev,
>>> +                                  LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
>>> +                     tilcdc_set(dev,
>>> +                                LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
>> +               }
>>
>> Just in case the interrupt is for some reason handled right after the
>> crtc is disabled.
>>
>> With this addition I could send a pull request for this fix still today,
>> if you agree with the change.
> I'm not sure this can really happen, but it won't hurt either, so I'll
> send a v2.

Well, in theory it is quite possible. If the driver clears the raster
enable at the same time when sync lost interrupt is generated, then the
irq routine handles the irq before the interrupts are disabled. Then it
happens that rastere remains on but the driver thinks it has already
turned it off.

In practice this is of course terribly unlikely, but a race is a race
and should be avoided.

Anyway, my vacation has already been started so I won't send a pull
request now. I do not like the idea of doing something like that and
then vanishing for two weeks. I hope they still take fixes for 4.10 in
4th Jan.

Best regards,
Jyri

^ permalink raw reply

* [PATCH v2 03/10] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU
From: Rob Herring @ 2016-12-19 16:37 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1481129759-159533-1-git-send-email-anurup.m@huawei.com>

On Wed, Dec 07, 2016 at 11:55:59AM -0500, Anurup M wrote:
> 1) Device tree bindings for Hisilicon SoC PMU.
> 2) Add example for Hisilicon L3 cache and MN PMU.
> 3) Add child nodes of L3C and MN in djtag bindings example.
> 
> Signed-off-by: Anurup M <anurup.m@huawei.com>
> Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
> ---
>  .../devicetree/bindings/arm/hisilicon/djtag.txt    | 25 ++++++
>  .../devicetree/bindings/arm/hisilicon/pmu.txt      | 98 ++++++++++++++++++++++
>  2 files changed, 123 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> index 733498e..c885507 100644
> --- a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> @@ -27,6 +27,31 @@ Example 1: Djtag for CPU die
>  		scl-id = <0x02>;
>  
>  		/* All connecting components will appear as child nodes */
> +
> +		pmul3c0 {
> +			compatible = "hisilicon,hisi-pmu-l3c-v1";
> +			module-id = <0x04 0x02>;
> +		};
> +
> +		pmul3c1 {
> +			compatible = "hisilicon,hisi-pmu-l3c-v1";
> +			module-id = <0x04 0x04>;
> +		};
> +
> +		pmul3c2 {
> +			compatible = "hisilicon,hisi-pmu-l3c-v1";
> +			module-id = <0x04 0x01>;
> +		};
> +
> +		pmul3c3 {
> +			compatible = "hisilicon,hisi-pmu-l3c-v1";
> +			module-id = <0x04 0x08>;
> +		};
> +
> +		pmumn0 {
> +			compatible = "hisilicon,hisi-pmu-mn-v1";
> +			module-id = <0x0b>;
> +		};
>  	};
>  
>  Example 2: Djtag for IO die
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
> new file mode 100644
> index 0000000..e2160ad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
> @@ -0,0 +1,98 @@
> +Hisilicon SoC HiP05/06/07 ARMv8 PMU
> +===================================
> +
> +The Hisilicon SoC chips like HiP05/06/07 etc. consist of various independent
> +system device PMUs such as L3 cache (L3C) and Miscellaneous Nodes(MN). These
> +PMU devices are independent and have hardware logic to gather statistics and
> +performance information.
> +
> +HiSilicon SoC chip is encapsulated by multiple CPU and IO dies. The CPU die
> +is called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every SCCL
> +in HiP05/06/07 chips are further grouped as CPU clusters (CCL) which includes
> +4 cpu-cores each.
> +e.g. In the case of HiP05/06/07, each SCCL has 1 L3 cache and 1 MN PMU device.
> +The L3 cache is further grouped as 4 L3 cache banks in a SCCL.
> +
> +The Hisilicon SoC PMU DT node bindings for uncore PMU devices are as below.
> +For PMU devices like L3 cache. MN etc. which are accessed using the djtag,
> +the parent node will be the djtag node of the corresponding CPU die (SCCL).
> +
> +L3 cache
> +---------
> +The L3 cache is dedicated for each SCCL. Each SCCL in HiP05/06/07 chips have 4
> +L3 cache banks. Each L3 cache bank have separate DT nodes.
> +
> +Required properties:
> +
> +	- compatible : This value should be as follows
> +		(a) "hisilicon,hisi-pmu-l3c-v1" for v1 hw in HiP05/06 chips
> +		(b) "hisilicon,hisi-pmu-l3c-v2" for v2 hw in HiP07 chip

Use SoC specific compatible strings.

> +
> +	- module-id : This property is a combination of two values in the below order.
> +		      a) Module ID: The module identifier for djtag.
> +		      b) Instance or Bank ID: This will identify the L3 cache bank
> +			 or instance.

Needs a vendor prefix.

> +
> +Optional properties:
> +
> +	- interrupt-parent : A phandle indicating which interrupt controller
> +		this PMU signals interrupts to.
> +
> +	- interrupts : Interrupt lines used by this L3 cache bank.

How many interrupts and what are they?

> +
> +	*The counter overflow IRQ is not supported in v1 hardware (HiP05/06).
> +
> +Miscellaneous Node
> +------------------
> +The MN is dedicated for each SCCL and hence there are separate DT nodes for MN
> +for each SCCL.

Similar comments here.

> +
> +Required properties:
> +
> +	- compatible : This value should be as follows
> +		(a) "hisilicon,hisi-pmu-mn-v1" for v1 hw in HiP05/06 chips
> +		(b) "hisilicon,hisi-pmu-mn-v2" for v2 hw in HiP07 chip
> +
> +	- module-id : Module ID to input for djtag.
> +
> +Optional properties:
> +
> +	- interrupt-parent : A phandle indicating which interrupt controller
> +		this PMU signals interrupts to.
> +
> +	- interrupts : Interrupt lines used by this PMU.
> +
> +	*The counter overflow IRQ is not supported in v1 hardware (HiP05/06).
> +
> +Example:
> +
> +	djtag0: djtag at 80010000 {
> +		compatible = "hisilicon,hisi-djtag-v1";
> +		reg = <0x0 0x80010000 0x0 0x10000>;
> +		scl-id = <0x02>;
> +
> +		pmul3c0 {
> +			compatible = "hisilicon,hisi-pmu-l3c-v1";
> +			module-id = <0x04 0x02>;
> +		};
> +
> +		pmul3c1 {
> +			compatible = "hisilicon,hisi-pmu-l3c-v1";
> +			module-id = <0x04 0x04>;
> +		};
> +
> +		pmul3c2 {
> +			compatible = "hisilicon,hisi-pmu-l3c-v1";
> +			module-id = <0x04 0x01>;
> +		};
> +
> +		pmul3c3 {
> +			compatible = "hisilicon,hisi-pmu-l3c-v1";
> +			module-id = <0x04 0x08>;
> +		};
> +
> +		pmumn0 {
> +			compatible = "hisilicon,hisi-pmu-mn-v1";
> +			module-id = <0x0b>;
> +		};
> +	};
> -- 
> 2.1.4
> 

^ permalink raw reply

* [PATCH v2 02/10] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings
From: Rob Herring @ 2016-12-19 16:31 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1481129719-159487-1-git-send-email-anurup.m@huawei.com>

On Wed, Dec 07, 2016 at 11:55:19AM -0500, Anurup M wrote:
> From: Tan Xiaojun <tanxiaojun@huawei.com>
> 
> Add Hisilicon HiP05/06/07 Djtag dts bindings for CPU and IO Die
> 
> Signed-off-by: Tan Xiaojun <tanxiaojun@huawei.com>
> Signed-off-by: Anurup M <anurup.m@huawei.com>
> ---
>  .../devicetree/bindings/arm/hisilicon/djtag.txt    | 41 ++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> new file mode 100644
> index 0000000..733498e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> @@ -0,0 +1,41 @@
> +The Hisilicon Djtag is an independent component which connects with some other
> +components in the SoC by Debug Bus. The djtag is available in CPU and IO dies
> +in the chip. The djtag controls access to connecting modules of CPU and IO
> +dies.
> +The various connecting components in CPU die (like L3 cache, L3 cache PMU etc.)
> +are accessed by djtag during real time debugging. In IO die there are connecting
> +components like RSA. These components appear as devices atatched to djtag bus.
> +
> +Hisilicon HiP05/06 djtag for CPU and HiP05 IO die
> +Required properties:
> +  - compatible : "hisilicon,hisi-djtag-v1"

These need SoC specific compatible strings. They probably should 
also include cpu or io in the compatible string. I would expect there 
are things like events, triggers, or component connections for debug 
that are SoC specifc.

> +  - reg : Register address and size
> +  - scl-id : The Super Cluster ID for CPU or IO die
> +
> +Hisilicon HiP06 djtag for IO die and HiP07 djtag for CPU and IO die
> +Required properties:
> +  - compatible : "hisilicon,hisi-djtag-v2"

Same here.

> +  - reg : Register address and size
> +  - scl-id : The Super Cluster ID for CPU or IO die
> +
> +Example 1: Djtag for CPU die
> +
> +	/* for Hisilicon HiP05 djtag for CPU Die */
> +	djtag0: djtag at 80010000 {
> +		compatible = "hisilicon,hisi-djtag-v1";
> +		reg = <0x0 0x80010000 0x0 0x10000>;
> +		scl-id = <0x02>;
> +
> +		/* All connecting components will appear as child nodes */
> +	};
> +
> +Example 2: Djtag for IO die
> +
> +	/* for Hisilicon HiP05 djtag for IO Die */
> +	djtag1: djtag at d0000000 {
> +		compatible = "hisilicon,hisi-djtag-v1";
> +		reg = <0x0 0xd0000000 0x0 0x10000>;
> +		scl-id = <0x01>;
> +
> +		/* All connecting components will appear as child nodes */
> +	};
> -- 
> 2.1.4
> 

^ permalink raw reply

* Problems to Allwinner H3's eFUSE/SID
From: Hans de Goede @ 2016-12-19 16:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <13032681482164747@web30h.yandex.ru>

Hi,

On 19-12-16 17:25, Icenowy Zheng wrote:
>
>
> 20.12.2016, 00:17, "Hans de Goede" <hdegoede@redhat.com>:
>> Hi,
>>
>> On 19-12-16 17:06, Icenowy Zheng wrote:
>>>  19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
>>>>  Hi,
>>>>
>>>>  On 19-12-16 16:22, Icenowy Zheng wrote:
>>>>>   Hi everyone,
>>>>>
>>>>>   Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>>>>>   controller of H3 (incl. H2+).
>>>>>
>>>>>   See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>>>>
>>>>>   Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
>>>>>   directly access 0x01c14200.
>>>>>
>>>>>   From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
>>>>>   the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
>>>>>   legacy kernel).
>>>>>
>>>>>   According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
>>>>>   byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
>>>>>   0x58 is H3D (currently not known SoC) )
>>>>>
>>>>>   However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
>>>>>   with 0x02004620, which do not match this rule.
>>>>>
>>>>>   The readout by devmem2 is satisfying this rule: their first word is
>>>>>   0x02c00081, matches H3.
>>>>>
>>>>>   Then I found the SID-reading code from BSP U-Boot[2], which is based on
>>>>>   register operations. With this kind of code (I wrote one prototype in
>>>>>   userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
>>>>>   my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
>>>>>   And, after accessing to the SID by registers, the value of *0x01c14200 become
>>>>>   also "02c00081".
>>>>>
>>>>>   With direct access to 0x01c14200 after boot with mainline kernel, I got also
>>>>>   "02004620".
>>>>>
>>>>>   Then I altered the program to do the register operations with sunxi-fel, the
>>>>>   result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>>>>>
>>>>>   Summary:
>>>>>
>>>>>   +-----------------------------------------------+----------------+
>>>>>   | Read situation | The first word |
>>>>>   +-----------------------------------------------+----------------+
>>>>>   | Direct read by sunxi-fel | 02004620 |
>>>>>   | Direct read in mainline /dev/mem | 02004620 |
>>>>>   | Direct read in legacy /dev/mem | 02c00081 |
>>>>>   | Register access in FEL | 02c00081 |
>>>>>   | Register access in mainline | 02c00081 |
>>>>>   | Direct read after register access in FEL | 02c00081 |
>>>>>   | Direct read after register access in mainline | 02c00081 |
>>>>>   +-----------------------------------------------+----------------+
>>>>>
>>>>>   According to some facts:
>>>>>   - The register based access to SID is weird: it needs ~5 register
>>>>>     operations per word of SID.
>>>>>   - Reading via register access will change the value when reading by accessing
>>>>>     0x01c14200.
>>>>>   - In the u-boot code[2] there's some functions which read out the SID by
>>>>>     registers and then abandoned the value.
>>>>>   - This mismatch do not exist on A64.
>>>>>
>>>>>   I think that: Allwinner designed a "cache" to the SID to make the simplify the
>>>>>   code to read it, and it automatically loaded the cache when booting; however,
>>>>>   when doing first cache on H3, some byte shifts occured, and the value become
>>>>>   wrong. A manual read on H3 can make the cache right again. This is a silicon
>>>>>   bug, and fixed in A64.
>>>>>
>>>>>   This raises a problem: currently many systems has used the misread SID value to
>>>>>   generated lots of MAC addresses, and workaround this SID bug will change them.
>>>>>
>>>>>   However, if this bug is not workarounded, the sun8i-ths driver won't work well
>>>>>   (as some calibartion value lies in eFUSE). I think some early user of this
>>>>>   driver has already experienced bad readout value.
>>>>>   (The calibration value differs on my opi1 and KotCzarny's opipc)
>>>>>
>>>>>   And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
>>>>>   think sunxi-fel must have the workaround)
>>>>>
>>>>>   Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
>>>>>   at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>>>>
>>>>>   Furthermore, A83T may also have this problem, testers are welcome!
>>>>>
>>>>>   [1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>>>>>   [2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>>>>
>>>>>   Experiments:
>>>>>   - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>>>>>     A SID readout shell script via FEL with register access.
>>>>>   - https://31.135.195.151:20281/d/efuse/
>>>>>     A SID readout program via /dev/mem with register access by KotCzarny.
>>>>>     (with statically compiled binary)
>>>>
>>>>  Good detective work!
>>>>
>>>>  I believe this would best be fixed by making u-boot use the register access
>>>>  method to get the SID on affected chips, and make sure u-boot reads the
>>>>  SID at-least once.
>>>
>>>  Yes.
>>>
>>>  However, what I considered is that fixing this bug will change H3 devices'
>>>  MAC addresses, as they are derived from SID.
>>
>> I know, but I think we will just need to accept this onetime change
>> of the fixed MAC addresses to fix this bug. I don't think this is
>> a big problem since the driver for the H3 ethernet has not been
>> merged into the mainline kernel yet.
>>
>>>  Maybe we should add #ifdef's to MAC generation code after this fix.
>>
>> I would rather not see #ifdefs for this, see above, but that is no
>> longer my call, see below.
>>
>>>  (This is why I will create this discussion)
>>>
>>>  P.S. Are you still the maintainer of sunxi boards support of u-boot? The
>>>  MAINTAINER file in board/sunxi indicates this.
>>
>> No I'm no longer the maintainer, I'm still the MAINTAINER file because
>> I have a lot of boards and as such I'm still the point of contact for
>> those boards (if there are any board specific issues / questions), but
>> as indicated in the main MAINTAINERS file Jagan Teki <jagan@openedev.com>
>> is the maintainer now.
>
> But the current status of the file will indicates you are the maintainer of boards
> support of sunxi.

No it indicates that I'm the maintainer for the defconfig files for a whole list
of boards, nothing more and nothing less.

If you think it needs to be clarified, feel free to submit a patch to make this
more clear.

Regards,

Hans

^ permalink raw reply

* Problems to Allwinner H3's eFUSE/SID
From: Icenowy Zheng @ 2016-12-19 16:25 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <12fa0112-b0e2-21e0-f369-7372944153d5@redhat.com>



20.12.2016, 00:17, "Hans de Goede" <hdegoede@redhat.com>:
> Hi,
>
> On 19-12-16 17:06, Icenowy Zheng wrote:
>> ?19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
>>> ?Hi,
>>>
>>> ?On 19-12-16 16:22, Icenowy Zheng wrote:
>>>> ??Hi everyone,
>>>>
>>>> ??Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>>>> ??controller of H3 (incl. H2+).
>>>>
>>>> ??See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>>>
>>>> ??Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
>>>> ??directly access 0x01c14200.
>>>>
>>>> ??From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
>>>> ??the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
>>>> ??legacy kernel).
>>>>
>>>> ??According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
>>>> ??byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
>>>> ??0x58 is H3D (currently not known SoC) )
>>>>
>>>> ??However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
>>>> ??with 0x02004620, which do not match this rule.
>>>>
>>>> ??The readout by devmem2 is satisfying this rule: their first word is
>>>> ??0x02c00081, matches H3.
>>>>
>>>> ??Then I found the SID-reading code from BSP U-Boot[2], which is based on
>>>> ??register operations. With this kind of code (I wrote one prototype in
>>>> ??userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
>>>> ??my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
>>>> ??And, after accessing to the SID by registers, the value of *0x01c14200 become
>>>> ??also "02c00081".
>>>>
>>>> ??With direct access to 0x01c14200 after boot with mainline kernel, I got also
>>>> ??"02004620".
>>>>
>>>> ??Then I altered the program to do the register operations with sunxi-fel, the
>>>> ??result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>>>>
>>>> ??Summary:
>>>>
>>>> ??+-----------------------------------------------+----------------+
>>>> ??| Read situation | The first word |
>>>> ??+-----------------------------------------------+----------------+
>>>> ??| Direct read by sunxi-fel | 02004620 |
>>>> ??| Direct read in mainline /dev/mem | 02004620 |
>>>> ??| Direct read in legacy /dev/mem | 02c00081 |
>>>> ??| Register access in FEL | 02c00081 |
>>>> ??| Register access in mainline | 02c00081 |
>>>> ??| Direct read after register access in FEL | 02c00081 |
>>>> ??| Direct read after register access in mainline | 02c00081 |
>>>> ??+-----------------------------------------------+----------------+
>>>>
>>>> ??According to some facts:
>>>> ??- The register based access to SID is weird: it needs ~5 register
>>>> ????operations per word of SID.
>>>> ??- Reading via register access will change the value when reading by accessing
>>>> ????0x01c14200.
>>>> ??- In the u-boot code[2] there's some functions which read out the SID by
>>>> ????registers and then abandoned the value.
>>>> ??- This mismatch do not exist on A64.
>>>>
>>>> ??I think that: Allwinner designed a "cache" to the SID to make the simplify the
>>>> ??code to read it, and it automatically loaded the cache when booting; however,
>>>> ??when doing first cache on H3, some byte shifts occured, and the value become
>>>> ??wrong. A manual read on H3 can make the cache right again. This is a silicon
>>>> ??bug, and fixed in A64.
>>>>
>>>> ??This raises a problem: currently many systems has used the misread SID value to
>>>> ??generated lots of MAC addresses, and workaround this SID bug will change them.
>>>>
>>>> ??However, if this bug is not workarounded, the sun8i-ths driver won't work well
>>>> ??(as some calibartion value lies in eFUSE). I think some early user of this
>>>> ??driver has already experienced bad readout value.
>>>> ??(The calibration value differs on my opi1 and KotCzarny's opipc)
>>>>
>>>> ??And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
>>>> ??think sunxi-fel must have the workaround)
>>>>
>>>> ??Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
>>>> ??at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>>>
>>>> ??Furthermore, A83T may also have this problem, testers are welcome!
>>>>
>>>> ??[1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>>>> ??[2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>>>
>>>> ??Experiments:
>>>> ??- https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>>>> ????A SID readout shell script via FEL with register access.
>>>> ??- https://31.135.195.151:20281/d/efuse/
>>>> ????A SID readout program via /dev/mem with register access by KotCzarny.
>>>> ????(with statically compiled binary)
>>>
>>> ?Good detective work!
>>>
>>> ?I believe this would best be fixed by making u-boot use the register access
>>> ?method to get the SID on affected chips, and make sure u-boot reads the
>>> ?SID at-least once.
>>
>> ?Yes.
>>
>> ?However, what I considered is that fixing this bug will change H3 devices'
>> ?MAC addresses, as they are derived from SID.
>
> I know, but I think we will just need to accept this onetime change
> of the fixed MAC addresses to fix this bug. I don't think this is
> a big problem since the driver for the H3 ethernet has not been
> merged into the mainline kernel yet.
>
>> ?Maybe we should add #ifdef's to MAC generation code after this fix.
>
> I would rather not see #ifdefs for this, see above, but that is no
> longer my call, see below.
>
>> ?(This is why I will create this discussion)
>>
>> ?P.S. Are you still the maintainer of sunxi boards support of u-boot? The
>> ?MAINTAINER file in board/sunxi indicates this.
>
> No I'm no longer the maintainer, I'm still the MAINTAINER file because
> I have a lot of boards and as such I'm still the point of contact for
> those boards (if there are any board specific issues / questions), but
> as indicated in the main MAINTAINERS file Jagan Teki <jagan@openedev.com>
> is the maintainer now.

But the current status of the file will indicates you are the maintainer of boards
support of sunxi.

>
> Regards,
>
> Hans

^ permalink raw reply

* Problems to Allwinner H3's eFUSE/SID
From: Hans de Goede @ 2016-12-19 16:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <8758581482163602@web22j.yandex.ru>

Hi,

On 19-12-16 17:06, Icenowy Zheng wrote:
>
>
> 19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
>> Hi,
>>
>> On 19-12-16 16:22, Icenowy Zheng wrote:
>>>  Hi everyone,
>>>
>>>  Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>>>  controller of H3 (incl. H2+).
>>>
>>>  See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>>
>>>  Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
>>>  directly access 0x01c14200.
>>>
>>>  From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
>>>  the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
>>>  legacy kernel).
>>>
>>>  According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
>>>  byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
>>>  0x58 is H3D (currently not known SoC) )
>>>
>>>  However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
>>>  with 0x02004620, which do not match this rule.
>>>
>>>  The readout by devmem2 is satisfying this rule: their first word is
>>>  0x02c00081, matches H3.
>>>
>>>  Then I found the SID-reading code from BSP U-Boot[2], which is based on
>>>  register operations. With this kind of code (I wrote one prototype in
>>>  userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
>>>  my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
>>>  And, after accessing to the SID by registers, the value of *0x01c14200 become
>>>  also "02c00081".
>>>
>>>  With direct access to 0x01c14200 after boot with mainline kernel, I got also
>>>  "02004620".
>>>
>>>  Then I altered the program to do the register operations with sunxi-fel, the
>>>  result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>>>
>>>  Summary:
>>>
>>>  +-----------------------------------------------+----------------+
>>>  | Read situation | The first word |
>>>  +-----------------------------------------------+----------------+
>>>  | Direct read by sunxi-fel | 02004620 |
>>>  | Direct read in mainline /dev/mem | 02004620 |
>>>  | Direct read in legacy /dev/mem | 02c00081 |
>>>  | Register access in FEL | 02c00081 |
>>>  | Register access in mainline | 02c00081 |
>>>  | Direct read after register access in FEL | 02c00081 |
>>>  | Direct read after register access in mainline | 02c00081 |
>>>  +-----------------------------------------------+----------------+
>>>
>>>  According to some facts:
>>>  - The register based access to SID is weird: it needs ~5 register
>>>    operations per word of SID.
>>>  - Reading via register access will change the value when reading by accessing
>>>    0x01c14200.
>>>  - In the u-boot code[2] there's some functions which read out the SID by
>>>    registers and then abandoned the value.
>>>  - This mismatch do not exist on A64.
>>>
>>>  I think that: Allwinner designed a "cache" to the SID to make the simplify the
>>>  code to read it, and it automatically loaded the cache when booting; however,
>>>  when doing first cache on H3, some byte shifts occured, and the value become
>>>  wrong. A manual read on H3 can make the cache right again. This is a silicon
>>>  bug, and fixed in A64.
>>>
>>>  This raises a problem: currently many systems has used the misread SID value to
>>>  generated lots of MAC addresses, and workaround this SID bug will change them.
>>>
>>>  However, if this bug is not workarounded, the sun8i-ths driver won't work well
>>>  (as some calibartion value lies in eFUSE). I think some early user of this
>>>  driver has already experienced bad readout value.
>>>  (The calibration value differs on my opi1 and KotCzarny's opipc)
>>>
>>>  And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
>>>  think sunxi-fel must have the workaround)
>>>
>>>  Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
>>>  at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>>
>>>  Furthermore, A83T may also have this problem, testers are welcome!
>>>
>>>  [1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>>>  [2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>>
>>>  Experiments:
>>>  - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>>>    A SID readout shell script via FEL with register access.
>>>  - https://31.135.195.151:20281/d/efuse/
>>>    A SID readout program via /dev/mem with register access by KotCzarny.
>>>    (with statically compiled binary)
>>
>> Good detective work!
>>
>> I believe this would best be fixed by making u-boot use the register access
>> method to get the SID on affected chips, and make sure u-boot reads the
>> SID at-least once.
>
> Yes.
>
> However, what I considered is that fixing this bug will change H3 devices'
> MAC addresses, as they are derived from SID.

I know, but I think we will just need to accept this onetime change
of the fixed MAC addresses to fix this bug. I don't think this is
a big problem since the driver for the H3 ethernet has not been
merged into the mainline kernel yet.

> Maybe we should add #ifdef's to MAC generation code after this fix.

I would rather not see #ifdefs for this, see above, but that is no
longer my call, see below.

>
> (This is why I will create this discussion)
>
> P.S. Are you still the maintainer of sunxi boards support of u-boot? The
> MAINTAINER file in board/sunxi indicates this.

No I'm no longer the maintainer, I'm still the MAINTAINER file because
I have a lot of boards and as such I'm still the point of contact for
those boards (if there are any board specific issues / questions), but
as indicated in the main MAINTAINERS file Jagan Teki <jagan@openedev.com>
is the maintainer now.

Regards,

Hans

^ permalink raw reply

* [PATCH] ARM: ep93xx: Disable TS-72xx watchdog before uncompressing
From: Hartley Sweeten @ 2016-12-19 16:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <6d58631d-37a2-8362-e9aa-0c360fac4509@gmail.com>

On Sunday, December 18, 2016 7:08 PM, Florian Fainelli wrote:
> Le 12/11/16 ? 11:16, Florian Fainelli a ?crit :
>> The TS-72xx/73xx boards have a CPLD watchdog which is configured to
>> reset the board after 8 seconds, if the kernel is large enough that this
>> takes about this time to decompress the kernel, we will encounter a
>> spurious reboot.
>> 
>> Do not pull ts72xx.h, but instead locally define what we need to disable
>> the watchdog.
>> 
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Hartley, Ryan, do you guys maintain a git tree with EP93xx patches, or
> should I submit them through RMK's patch system once you are okay with them?

Ryan has an old tree on github but it has not been updated since Oct 14, 2013.  I'm
not sure if he is doing any active development at this time.

This patch will have to go through RMK's patch system or some other tree.

Thanks,
Hartley

^ permalink raw reply

* Problems to Allwinner H3's eFUSE/SID
From: Icenowy Zheng @ 2016-12-19 16:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <a2e87cff-d92c-37e3-e380-48ce1710ec08@redhat.com>



19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
> Hi,
>
> On 19-12-16 16:22, Icenowy Zheng wrote:
>> ?Hi everyone,
>>
>> ?Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>> ?controller of H3 (incl. H2+).
>>
>> ?See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>
>> ?Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
>> ?directly access 0x01c14200.
>>
>> ?From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
>> ?the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
>> ?legacy kernel).
>>
>> ?According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
>> ?byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
>> ?0x58 is H3D (currently not known SoC) )
>>
>> ?However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
>> ?with 0x02004620, which do not match this rule.
>>
>> ?The readout by devmem2 is satisfying this rule: their first word is
>> ?0x02c00081, matches H3.
>>
>> ?Then I found the SID-reading code from BSP U-Boot[2], which is based on
>> ?register operations. With this kind of code (I wrote one prototype in
>> ?userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
>> ?my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
>> ?And, after accessing to the SID by registers, the value of *0x01c14200 become
>> ?also "02c00081".
>>
>> ?With direct access to 0x01c14200 after boot with mainline kernel, I got also
>> ?"02004620".
>>
>> ?Then I altered the program to do the register operations with sunxi-fel, the
>> ?result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>>
>> ?Summary:
>>
>> ?+-----------------------------------------------+----------------+
>> ?| Read situation | The first word |
>> ?+-----------------------------------------------+----------------+
>> ?| Direct read by sunxi-fel | 02004620 |
>> ?| Direct read in mainline /dev/mem | 02004620 |
>> ?| Direct read in legacy /dev/mem | 02c00081 |
>> ?| Register access in FEL | 02c00081 |
>> ?| Register access in mainline | 02c00081 |
>> ?| Direct read after register access in FEL | 02c00081 |
>> ?| Direct read after register access in mainline | 02c00081 |
>> ?+-----------------------------------------------+----------------+
>>
>> ?According to some facts:
>> ?- The register based access to SID is weird: it needs ~5 register
>> ???operations per word of SID.
>> ?- Reading via register access will change the value when reading by accessing
>> ???0x01c14200.
>> ?- In the u-boot code[2] there's some functions which read out the SID by
>> ???registers and then abandoned the value.
>> ?- This mismatch do not exist on A64.
>>
>> ?I think that: Allwinner designed a "cache" to the SID to make the simplify the
>> ?code to read it, and it automatically loaded the cache when booting; however,
>> ?when doing first cache on H3, some byte shifts occured, and the value become
>> ?wrong. A manual read on H3 can make the cache right again. This is a silicon
>> ?bug, and fixed in A64.
>>
>> ?This raises a problem: currently many systems has used the misread SID value to
>> ?generated lots of MAC addresses, and workaround this SID bug will change them.
>>
>> ?However, if this bug is not workarounded, the sun8i-ths driver won't work well
>> ?(as some calibartion value lies in eFUSE). I think some early user of this
>> ?driver has already experienced bad readout value.
>> ?(The calibration value differs on my opi1 and KotCzarny's opipc)
>>
>> ?And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
>> ?think sunxi-fel must have the workaround)
>>
>> ?Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
>> ?at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>
>> ?Furthermore, A83T may also have this problem, testers are welcome!
>>
>> ?[1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>> ?[2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>
>> ?Experiments:
>> ?- https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>> ???A SID readout shell script via FEL with register access.
>> ?- https://31.135.195.151:20281/d/efuse/
>> ???A SID readout program via /dev/mem with register access by KotCzarny.
>> ???(with statically compiled binary)
>
> Good detective work!
>
> I believe this would best be fixed by making u-boot use the register access
> method to get the SID on affected chips, and make sure u-boot reads the
> SID at-least once.

Yes.

However, what I considered is that fixing this bug will change H3 devices'
MAC addresses, as they are derived from SID.

Maybe we should add #ifdef's to MAC generation code after this fix.

(This is why I will create this discussion)

P.S. Are you still the maintainer of sunxi boards support of u-boot? The
MAINTAINER file in board/sunxi indicates this.

I've sent out a new board support several days ago (Orange Pi Zero), and got
one "Reviewd-By". Could you look at it?


>
> Can you write a patch for this ?
>
> Regards,
>
> Hans

^ permalink raw reply

* [PATCH 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma
From: Appana Durga Kedareswara Rao @ 2016-12-19 15:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <30884836.ckISXSrEvA@avalon>

Hi Laurent Pinchart,

	Thanks for the review...

> > +		int i = 0, j = 0;
> >
> >  		if (chan->desc_submitcount < chan->num_frms)
> >  			i = chan->desc_submitcount;
> 
> I don't get this. i seems to index into a segment start address array, but gets
> initialized with a variable documented as "Descriptor h/w submitted count". I'm
> not familiar with the hardware, but it makes no sense to me.

Here i is the h/w buffer address. 
For ex: If the h/w is configured for 3 frame buffers and user submits 4 desc's
Then we need to submit only 3 frame buffers to the h/w and the next desc will be submitted
After there is a room for buffers I mean when the free buffer is available.

> 
> > -		list_for_each_entry(segment, &desc->segments, node) {
> > -			if (chan->ext_addr)
> > -				vdma_desc_write_64(chan,
> > -
> 	XILINX_VDMA_REG_START_ADDRESS_64(i++),
> > -					segment->hw.buf_addr,
> > -					segment->hw.buf_addr_msb);
> > -			else
> > -				vdma_desc_write(chan,
> > -
> 	XILINX_VDMA_REG_START_ADDRESS(i++),
> > -					segment->hw.buf_addr);
> > -
> > -			last = segment;
> 
> Isn't it an issue to write the descriptors only after calling
> xilinx_dma_start() ?

Until writing to the VSIZE h/w won't get started...

> 
> > +		for (j = 0; j < chan->num_frms; ) {
> > +			list_for_each_entry(segment, &desc->segments, node)
> {
> > +				if (chan->ext_addr)
> > +					vdma_desc_write_64(chan,
> > +
> XILINX_VDMA_REG_START_ADDRESS_64(i++),
> > +					  segment->hw.buf_addr,
> > +					  segment->hw.buf_addr_msb);
> > +				else
> > +					vdma_desc_write(chan,
> > +
> XILINX_VDMA_REG_START_ADDRESS(i++),
> > +					    segment->hw.buf_addr);
> 
> I assume the size of the start address array to be limited by the hardware, but I
> don't see how this code prevents from overflowing this.
> 
> The whole function is very difficult to understand, it probably requires a rewrite.

Will fix it in v2...

> 
> > +				last = segment;
> > +			}
> > +			list_del(&desc->node);
> > +			list_add_tail(&desc->node, &chan->active_list);
> > +			j++;
> > +			if (list_empty(&chan->pending_list))
> > +				break;
> > +			desc = list_first_entry(&chan->pending_list,
> > +						struct
> xilinx_dma_tx_descriptor,
> > +						node);
> >  		}
> >  	if (!chan->has_sg) {
> > -		list_del(&desc->node);
> > -		list_add_tail(&desc->node, &chan->active_list);
> > -		chan->desc_submitcount++;
> > -		chan->desc_pendingcount--;
> >  		if (chan->desc_submitcount == chan->num_frms)
> >  			chan->desc_submitcount = 0;
> >  	} else {
> 
> While at it, can you merge this into the previous if (chan->has_sg) { ... } else { ... }
> ? Having them separate is confusing.

Ok sure will fix in v2...

Regards,
Kedar.

> 
> 
> --
> Regards,
> 
> Laurent Pinchart

^ permalink raw reply

* [PATCH 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma
From: Appana Durga Kedareswara Rao @ 2016-12-19 15:40 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <689b1077-6ee3-60d0-1fdf-0a125003a479@synopsys.com>

Hi Jose Miguel Abreu,

	Thanks for the review... 

> >
> >>> -			last = segment;
> >>> +		for (j = 0; j < chan->num_frms; ) {
> >>> +			list_for_each_entry(segment, &desc->segments, node)
> >> {
> >>> +				if (chan->ext_addr)
> >>> +					vdma_desc_write_64(chan,
> >>> +
> >> XILINX_VDMA_REG_START_ADDRESS_64(i++),
> >>> +					  segment->hw.buf_addr,
> >>> +					  segment->hw.buf_addr_msb);
> >>> +				else
> >>> +					vdma_desc_write(chan,
> >>> +
> >> XILINX_VDMA_REG_START_ADDRESS(i++),
> >>> +					    segment->hw.buf_addr);
> >>> +
> >>> +				last = segment;
> >> Hmm, is it possible to submit more than one segment? If so, then i
> >> and j will get out of sync.
> > If h/w is configured for more than 1 frame buffer and user submits
> > more than one frame buffer We can submit more than one frame/ segment to
> hw right??
> 
> I'm not sure. When I used VDMA driver I always submitted only one segment and
> multiple descriptors. But the problem is, for example:
> 
> If you have:
> descriptor1 (2 segments)
> descriptor2 (2 segments)
> 
> And you have 3 frame buffers in the HW.
> 
> Then:
> 1st frame buffer will have: descriptor1 -> segment1 2nd frame buffer will have:
> descriptor1 -> segment2 3rd frame buffer will have: descriptor2 -> segment1
> but, 4th frame buffer will have: descriptor2 -> segment2 <---- INVALID because
> there is only 3 frame buffers
> 
> So, maybe a check inside the loop "list_for_each_entry(segment, &desc-
> >segments, node)" could be a nice to have.

With the current driver flow user can submit only 1 segment per descriptor
That's why didn't checked the list_for_each_entry for each descriptors...
Hope it clarifies your query...

> 
> >
> >>> +			}
> >>> +			list_del(&desc->node);
> >>> +			list_add_tail(&desc->node, &chan->active_list);
> >>> +			j++;
> >> But if i is non zero and pending_list has more than num_frms then i
> >> will not wrap-around as it should and will write to invalid framebuffer
> location, right?
> > Yep will fix in v2...
> >
> > 	If (if (list_empty(&chan->pending_list)) || (i == chan->num_frms)
> > 		break;
> >
> > Above condition is sufficient right???
> 
> Looks ok.

Thanks...

> >>> @@ -1114,14 +1124,13 @@ static void
> >>> xilinx_vdma_start_transfer(struct
> >> xilinx_dma_chan *chan)
> >>>  		vdma_desc_write(chan, XILINX_DMA_REG_FRMDLY_STRIDE,
> >>>  				last->hw.stride);
> >>>  		vdma_desc_write(chan, XILINX_DMA_REG_VSIZE, last-
> hw.vsize);
> >> Maybe a check that all framebuffers contain valid addresses should be
> >> done before programming vsize so that VDMA does not try to write to
> >> invalid addresses.
> > Do we really need to check for valid address???
> > I didn't get you what to do you mean by invalid address could you please
> explain???
> > In the driver we are reading form the pending_list which will be
> > updated by pep_interleaved_dma Call so we are under assumption that user
> sends the proper address right???
> 
> What I mean by valid address is to check that i variable has already been
> incremented by num_frms at least once since a VDMA reset. This way you know
> that you have programmed all the addresses of the frame buffers with an
> address and they are non-zero.

Ok Sure will fix in v2...

Regards,
Kedar.

> 
> Best regards,
> Jose Miguel Abreu
> 

^ permalink raw reply

* [PATCH] ARM: dts: imx: Pass an empty 'chosen' node
From: Uwe Kleine-König @ 2016-12-19 15:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1482161298-32624-1-git-send-email-fabio.estevam@nxp.com>

On Mon, Dec 19, 2016 at 01:28:18PM -0200, Fabio Estevam wrote:
> Commit 7f107887d199 ("ARM: dts: imx: Remove skeleton.dtsi") causes boot
> issues when the bootloader does not create a 'chosen' node if such node
> is not present in the dtb.
> 
> The reason for the boot failure is well explained by Javier Martinez
> Canillas: "the decompressor relies on a pre-existing chosen node to be
> available to insert the command line and merge other ATAGS info."
> 
> , so pass an empty 'chosen' node to fix the boot problem.
> 
> This issue has been seen in the kernelci reports with Barebox as
> bootloader.
> 
> Fixes: 7f107887d199 ("ARM: dts: imx: Remove skeleton.dtsi")
> Reported-by: kernelci.org bot <bot@kernelci.org>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>

There is also a patch on the barebox list that makes barebox fix a dt
accordingly. It seems it's not in the repository though.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply

* [PATCH 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
From: Appana Durga Kedareswara Rao @ 2016-12-19 15:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5248247.n0rV8xBPrZ@avalon>

Hi Laurent Pinchart,

	Thanks for the review...

> >
> > +	if (!chan->idle)
> > +		return;
> 
> Don't you need to perform the same check for the DMA and CDMA channels ? If
> so, shouldn't this be moved to common code ?

Will fix it in v2...

> 
> There's another problem (not strictly introduced by this patch) I wanted to
> mention. The append_desc_queue() function, called from your tx_submit
> handler, appends descriptors to the pending_list. The DMA engine API states
> that a transfer submitted by tx_submit will not be executed until .issue_pending()
> is called. However, if a transfer is in progress at tx_submit time, I believe that
> the IRQ handler, at transfer completion, will start the next transfer from the
> pending_list even if .issue_pending() hasn't been called for it.
> 
> >  	if (list_empty(&chan->pending_list))
> >  		return;


If user submits more than h/w limit then that case only driver will process
The descriptors from the pending_list for other cases the pending_list will be 
Empty so driver just returns from there.

> 
> Now that you catch busy channels with a software flag, do you still need the
> xilinx_dma_is_running() and xilinx_dma_is_idle() checks ? Three different checks
> for the same or very similar conditions are confusing, if you really need them
> you should document clearly how they differ.

Will remove the xilinx_dma_is_running and xilinx_dmais_idle() checks and will use
Chan->idle check across all the IP's. Will fix it v2...

> 
> > @@ -1110,6 +1116,7 @@ static void xilinx_vdma_start_transfer(struct
> > xilinx_dma_chan *chan) vdma_desc_write(chan, XILINX_DMA_REG_VSIZE,
> > last->hw.vsize);
> >  	}
> >
> > +	chan->idle = false;
> 
> (and this too)

Will fix in v2...

Regards,
Kedar.

^ permalink raw reply

* [PATCH] ARM: dts: imx: Pass an empty 'chosen' node
From: Javier Martinez Canillas @ 2016-12-19 15:33 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1482161298-32624-1-git-send-email-fabio.estevam@nxp.com>

Hello Fabio,

On 12/19/2016 12:28 PM, Fabio Estevam wrote:
> Commit 7f107887d199 ("ARM: dts: imx: Remove skeleton.dtsi") causes boot
> issues when the bootloader does not create a 'chosen' node if such node
> is not present in the dtb.
> 
> The reason for the boot failure is well explained by Javier Martinez
> Canillas: "the decompressor relies on a pre-existing chosen node to be
> available to insert the command line and merge other ATAGS info."
> 
> , so pass an empty 'chosen' node to fix the boot problem.
> 
> This issue has been seen in the kernelci reports with Barebox as
> bootloader.
> 
> Fixes: 7f107887d199 ("ARM: dts: imx: Remove skeleton.dtsi")
> Reported-by: kernelci.org bot <bot@kernelci.org>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---

Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

^ permalink raw reply

* Problems to Allwinner H3's eFUSE/SID
From: Hans de Goede @ 2016-12-19 15:30 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <136061482160932@web34j.yandex.ru>

Hi,

On 19-12-16 16:22, Icenowy Zheng wrote:
> Hi everyone,
>
> Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
> controller of H3 (incl. H2+).
>
> See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>
> Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
> directly access 0x01c14200.
>
> From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
> the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
> legacy kernel).
>
> According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
> byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
> 0x58 is H3D (currently not known SoC) )
>
> However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
> with 0x02004620, which do not match this rule.
>
> The readout by devmem2 is satisfying this rule: their first word is
> 0x02c00081, matches H3.
>
> Then I found the SID-reading code from BSP U-Boot[2], which is based on
> register operations. With this kind of code (I wrote one prototype in
> userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
> my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
> And, after accessing to the SID by registers, the value of *0x01c14200 become
> also "02c00081".
>
> With direct access to 0x01c14200 after boot with mainline kernel, I got also
> "02004620".
>
> Then I altered the program to do the register operations with sunxi-fel, the
> result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>
> Summary:
>
> +-----------------------------------------------+----------------+
> | Read situation                                | The first word |
> +-----------------------------------------------+----------------+
> | Direct read by sunxi-fel                      | 02004620       |
> | Direct read in mainline /dev/mem              | 02004620       |
> | Direct read in legacy /dev/mem                | 02c00081       |
> | Register access in FEL                        | 02c00081       |
> | Register access in mainline                   | 02c00081       |
> | Direct read after register access in FEL      | 02c00081       |
> | Direct read after register access in mainline | 02c00081       |
> +-----------------------------------------------+----------------+
>
> According to some facts:
> - The register based access to SID is weird: it needs ~5 register
>   operations per word of SID.
> - Reading via register access will change the value when reading by accessing
>   0x01c14200.
> - In the u-boot code[2] there's some functions which read out the SID by
>   registers and then abandoned the value.
> - This mismatch do not exist on A64.
>
> I think that: Allwinner designed a "cache" to the SID to make the simplify the
> code to read it, and it automatically loaded the cache when booting; however,
> when doing first cache on H3, some byte shifts occured, and the value become
> wrong. A manual read on H3 can make the cache right again. This is a silicon
> bug, and fixed in A64.
>
> This raises a problem: currently many systems has used the misread SID value to
> generated lots of MAC addresses, and workaround this SID bug will change them.
>
> However, if this bug is not workarounded, the sun8i-ths driver won't work well
> (as some calibartion value lies in eFUSE). I think some early user of this
> driver has already experienced bad readout value.
> (The calibration value differs on my opi1 and KotCzarny's opipc)
>
> And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
> think sunxi-fel must have the workaround)
>
> Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
> at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>
> Furthermore, A83T may also have this problem, testers are welcome!
>
> [1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
> [2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>
> Experiments:
> - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>   A SID readout shell script via FEL with register access.
> - https://31.135.195.151:20281/d/efuse/
>   A SID readout program via /dev/mem with register access by KotCzarny.
>   (with statically compiled binary)

Good detective work!

I believe this would best be fixed by making u-boot use the register access
method to get the SID on affected chips, and make sure u-boot reads the
SID at-least once.

Can you write a patch for this ?

Regards,

Hans

^ permalink raw reply

* [PATCH] ARM: dts: imx: Pass an empty 'chosen' node
From: Fabio Estevam @ 2016-12-19 15:28 UTC (permalink / raw)
  To: linux-arm-kernel

Commit 7f107887d199 ("ARM: dts: imx: Remove skeleton.dtsi") causes boot
issues when the bootloader does not create a 'chosen' node if such node
is not present in the dtb.

The reason for the boot failure is well explained by Javier Martinez
Canillas: "the decompressor relies on a pre-existing chosen node to be
available to insert the command line and merge other ATAGS info."

, so pass an empty 'chosen' node to fix the boot problem.

This issue has been seen in the kernelci reports with Barebox as
bootloader.

Fixes: 7f107887d199 ("ARM: dts: imx: Remove skeleton.dtsi")
Reported-by: kernelci.org bot <bot@kernelci.org>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
 arch/arm/boot/dts/imx1.dtsi    | 1 +
 arch/arm/boot/dts/imx23.dtsi   | 1 +
 arch/arm/boot/dts/imx25.dtsi   | 1 +
 arch/arm/boot/dts/imx27.dtsi   | 1 +
 arch/arm/boot/dts/imx28.dtsi   | 1 +
 arch/arm/boot/dts/imx31.dtsi   | 1 +
 arch/arm/boot/dts/imx35.dtsi   | 1 +
 arch/arm/boot/dts/imx50.dtsi   | 1 +
 arch/arm/boot/dts/imx51.dtsi   | 1 +
 arch/arm/boot/dts/imx53.dtsi   | 1 +
 arch/arm/boot/dts/imx6qdl.dtsi | 1 +
 arch/arm/boot/dts/imx6sl.dtsi  | 1 +
 arch/arm/boot/dts/imx6sx.dtsi  | 1 +
 arch/arm/boot/dts/imx6ul.dtsi  | 1 +
 arch/arm/boot/dts/imx7s.dtsi   | 1 +
 15 files changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/imx1.dtsi b/arch/arm/boot/dts/imx1.dtsi
index b792eee..a9581b5 100644
--- a/arch/arm/boot/dts/imx1.dtsi
+++ b/arch/arm/boot/dts/imx1.dtsi
@@ -18,6 +18,7 @@
 / {
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen {};
 
 	aliases {
 		gpio0 = &gpio1;
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index ac2a9da..d00bc55 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -14,6 +14,7 @@
 / {
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen {};
 
 	interrupt-parent = <&icoll>;
 
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index 831d09a..a0348b0 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -14,6 +14,7 @@
 / {
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen {};
 
 	aliases {
 		ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index 9d8b596..84652eb 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -19,6 +19,7 @@
 / {
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen {};
 
 	aliases {
 		ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 3aabf65..6635213 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -15,6 +15,7 @@
 / {
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen {};
 
 	interrupt-parent = <&icoll>;
 
diff --git a/arch/arm/boot/dts/imx31.dtsi b/arch/arm/boot/dts/imx31.dtsi
index 685916e..8a1ea22 100644
--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -12,6 +12,7 @@
 / {
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen {};
 
 	aliases {
 		serial0 = &uart1;
diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index 9f40e62..4c67438 100644
--- a/arch/arm/boot/dts/imx35.dtsi
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -13,6 +13,7 @@
 / {
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen {};
 
 	aliases {
 		ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
index fe0221e..6e947bd 100644
--- a/arch/arm/boot/dts/imx50.dtsi
+++ b/arch/arm/boot/dts/imx50.dtsi
@@ -17,6 +17,7 @@
 / {
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen {};
 
 	aliases {
 		ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 33526ca..d1f8b93 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -19,6 +19,7 @@
 / {
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen {};
 
 	aliases {
 		ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index ca51dc0..ea308b0 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -19,6 +19,7 @@
 / {
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen {};
 
 	aliases {
 		ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 53e6e63..c9efd45 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -16,6 +16,7 @@
 / {
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen {};
 
 	aliases {
 		ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 4fd6de2..4cd16f2 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -14,6 +14,7 @@
 / {
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen {};
 
 	aliases {
 		ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 076a30f..9bb1563 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -15,6 +15,7 @@
 / {
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen {};
 
 	aliases {
 		can0 = &flexcan1;
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 39845a7..a910fa3 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -15,6 +15,7 @@
 / {
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen {};
 
 	aliases {
 		ethernet0 = &fec1;
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 8ff2cbdd..6408b9d 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -50,6 +50,7 @@
 / {
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen {};
 
 	aliases {
 		gpio0 = &gpio1;
-- 
1.9.1

^ permalink raw reply related

* Problems to Allwinner H3's eFUSE/SID
From: Icenowy Zheng @ 2016-12-19 15:22 UTC (permalink / raw)
  To: linux-arm-kernel

Hi everyone,

Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
controller of H3 (incl. H2+).

See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .

Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
directly access 0x01c14200.

>From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
legacy kernel).

According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
0x58 is H3D (currently not known SoC) )

However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
with 0x02004620, which do not match this rule.

The readout by devmem2 is satisfying this rule: their first word is
0x02c00081, matches H3.

Then I found the SID-reading code from BSP U-Boot[2], which is based on
register operations. With this kind of code (I wrote one prototype in
userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
And, after accessing to the SID by registers, the value of *0x01c14200 become
also "02c00081".

With direct access to 0x01c14200 after boot with mainline kernel, I got also
"02004620".

Then I altered the program to do the register operations with sunxi-fel, the
result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".

Summary:

+-----------------------------------------------+----------------+
| Read situation                                | The first word |
+-----------------------------------------------+----------------+
| Direct read by sunxi-fel                      | 02004620       |
| Direct read in mainline /dev/mem              | 02004620       |
| Direct read in legacy /dev/mem                | 02c00081       |
| Register access in FEL                        | 02c00081       |
| Register access in mainline                   | 02c00081       |
| Direct read after register access in FEL      | 02c00081       |
| Direct read after register access in mainline | 02c00081       |
+-----------------------------------------------+----------------+

According to some facts:
- The register based access to SID is weird: it needs ~5 register
  operations per word of SID.
- Reading via register access will change the value when reading by accessing
  0x01c14200.
- In the u-boot code[2] there's some functions which read out the SID by
  registers and then abandoned the value.
- This mismatch do not exist on A64.

I think that: Allwinner designed a "cache" to the SID to make the simplify the
code to read it, and it automatically loaded the cache when booting; however,
when doing first cache on H3, some byte shifts occured, and the value become
wrong. A manual read on H3 can make the cache right again. This is a silicon
bug, and fixed in A64.

This raises a problem: currently many systems has used the misread SID value to
generated lots of MAC addresses, and workaround this SID bug will change them.

However, if this bug is not workarounded, the sun8i-ths driver won't work well
(as some calibartion value lies in eFUSE). I think some early user of this
driver has already experienced bad readout value.
(The calibration value differs on my opi1 and KotCzarny's opipc)

And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
think sunxi-fel must have the workaround)

Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
at 0x01c14000, which is a OTP memory implemented by eFUSE technique.

Furthermore, A83T may also have this problem, testers are welcome!

[1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
[2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c

Experiments:
- https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
  A SID readout shell script via FEL with register access.
- https://31.135.195.151:20281/d/efuse/
  A SID readout program via /dev/mem with register access by KotCzarny.
  (with statically compiled binary)

Regards,
Icenowy

^ permalink raw reply

* [PATCH net-next v4 2/4] dt-bindings: net: add EEE capability constants
From: Jerome Brunet @ 2016-12-19 15:16 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161205143942.f3w6nmp3jvmrk5es@rob-hp-laptop>

Hi Rob,

First, Thx for this information and sorry for this late reply
As you may have seen yourself, there was little bit of confusion while
discussing this patch series.

The point is the v3 was applied before your reply (patches 2 and 3 not
combined unfortunately).
Because of this confusion, the series needed a few fixes witch removes
the previously added bindings [0].
This time, I made sure to modify (remove) the bindings along with the
documentation.

[0]:?http://lkml.kernel.org/r/1482159938-13239-1-git-send-email-jbrunet
@baylibre.com

Cheers
Jerome

On Mon, 2016-12-05 at 08:39 -0600, Rob Herring wrote:
> On Mon, Nov 28, 2016 at 04:50:26PM +0100, Jerome Brunet wrote:
> > 
> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> > Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
> > Tested-by: Andreas F?rber <afaerber@suse.de>
> > Tested-by: Neil Armstrong <narmstrong@baylibre.com>
> > ---
> > ?include/dt-bindings/net/mdio.h | 19 +++++++++++++++++++
> > ?1 file changed, 19 insertions(+)
> > ?create mode 100644 include/dt-bindings/net/mdio.h
> 
> Seems changes are wanted on this, but patches 2 and 3 should be?
> combined. The header is part of the binding doc.
> 
> Rob

^ permalink raw reply

* [PATCH 1/4] net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address 0x1
From: Andrew Lunn @ 2016-12-19 15:07 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CABHmqqDqhJa6N=Ayu-GFNyp4g90dXzTje6o8qfCEP2DacCFWdQ@mail.gmail.com>

On Mon, Dec 19, 2016 at 04:04:32PM +0100, Volodymyr Bendiuga wrote:
> Hi Andrew,
> 
> No, it did not get accepted. Or at least I did not see
> David accepting it. Let me know if I should resubmit it.

Hi Volodymyr

Please do resend it. Probably netdev will reopen sometime after the
25th.

Don't forget to include the reviewed-by i gave.

Thanks

	Andrew

^ permalink raw reply

* [PATCH net 3/3] dt: bindings: net: use boolean dt properties for eee broken modes
From: Jerome Brunet @ 2016-12-19 15:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1482159938-13239-1-git-send-email-jbrunet@baylibre.com>

The patches regarding eee-broken-modes was merged before all people
involved could find an agreement on the best way to move forward.

While we agreed on having a DT property to mark particular modes as broken,
the value used for eee-broken-modes mapped the phy register in very direct
way. Because of this, the concern is that it could be used to implement
configuration policies instead of describing a broken HW.

In the end, having a boolean property for each mode seems to be preferred
over one bit field value mapping the register (too) directly.

Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
 Documentation/devicetree/bindings/net/phy.txt | 10 ++++++++--
 include/dt-bindings/net/mdio.h                | 19 -------------------
 2 files changed, 8 insertions(+), 21 deletions(-)
 delete mode 100644 include/dt-bindings/net/mdio.h

diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
index 54749b60a466..ff1bc4b1bb3b 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -38,8 +38,14 @@ Optional Properties:
 - enet-phy-lane-swap: If set, indicates the PHY will swap the TX/RX lanes to
   compensate for the board being designed with the lanes swapped.
 
-- eee-broken-modes: Bits to clear in the MDIO_AN_EEE_ADV register to
-  disable EEE broken modes.
+- eee-broken-100tx:
+- eee-broken-1000t:
+- eee-broken-10gt:
+- eee-broken-1000kx:
+- eee-broken-10gkx4:
+- eee-broken-10gkr:
+  Mark the corresponding energy efficient ethernet mode as broken and
+  request the ethernet to stop advertising it.
 
 Example:
 
diff --git a/include/dt-bindings/net/mdio.h b/include/dt-bindings/net/mdio.h
deleted file mode 100644
index 99c6d903d439..000000000000
--- a/include/dt-bindings/net/mdio.h
+++ /dev/null
@@ -1,19 +0,0 @@
-/*
- * This header provides generic constants for ethernet MDIO bindings
- */
-
-#ifndef _DT_BINDINGS_NET_MDIO_H
-#define _DT_BINDINGS_NET_MDIO_H
-
-/*
- * EEE capability Advertisement
- */
-
-#define MDIO_EEE_100TX		0x0002	/* 100TX EEE cap */
-#define MDIO_EEE_1000T		0x0004	/* 1000T EEE cap */
-#define MDIO_EEE_10GT		0x0008	/* 10GT EEE cap */
-#define MDIO_EEE_1000KX		0x0010	/* 1000KX EEE cap */
-#define MDIO_EEE_10GKX4		0x0020	/* 10G KX4 EEE cap */
-#define MDIO_EEE_10GKR		0x0040	/* 10G KR EEE cap */
-
-#endif
-- 
2.7.4

^ permalink raw reply related

* [PATCH net 2/3] net: phy: use boolean dt properties for eee broken modes
From: Jerome Brunet @ 2016-12-19 15:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1482159938-13239-1-git-send-email-jbrunet@baylibre.com>

The patches regarding eee-broken-modes was merged before all people
involved could find an agreement on the best way to move forward.

While we agreed on having a DT property to mark particular modes as broken,
the value used for eee-broken-modes mapped the phy register in very direct
way. Because of this, the concern is that it could be used to implement
configuration policies instead of describing a broken HW.

In the end, having a boolean property for each mode seems to be preferred
over one bit field value mapping the register (too) directly.

Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
 drivers/net/phy/phy_device.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index ee5ebadb1463..92b08383cafa 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1665,7 +1665,7 @@ static void of_set_phy_supported(struct phy_device *phydev)
 static void of_set_phy_eee_broken(struct phy_device *phydev)
 {
 	struct device_node *node = phydev->mdio.dev.of_node;
-	u32 broken;
+	u32 broken = 0;
 
 	if (!IS_ENABLED(CONFIG_OF_MDIO))
 		return;
@@ -1673,8 +1673,20 @@ static void of_set_phy_eee_broken(struct phy_device *phydev)
 	if (!node)
 		return;
 
-	if (!of_property_read_u32(node, "eee-broken-modes", &broken))
-		phydev->eee_broken_modes = broken;
+	if (of_property_read_bool(node, "eee-broken-100tx"))
+		broken |= MDIO_EEE_100TX;
+	if (of_property_read_bool(node, "eee-broken-1000t"))
+		broken |= MDIO_EEE_1000T;
+	if (of_property_read_bool(node, "eee-broken-10gt"))
+		broken |= MDIO_EEE_10GT;
+	if (of_property_read_bool(node, "eee-broken-1000kx"))
+		broken |= MDIO_EEE_1000KX;
+	if (of_property_read_bool(node, "eee-broken-10gkx4"))
+		broken |= MDIO_EEE_10GKX4;
+	if (of_property_read_bool(node, "eee-broken-10gkr"))
+		broken |= MDIO_EEE_10GKR;
+
+	phydev->eee_broken_modes = broken;
 }
 
 /**
-- 
2.7.4

^ permalink raw reply related

* [PATCH net 1/3] net: phy: fix sign type error in genphy_config_eee_advert
From: Jerome Brunet @ 2016-12-19 15:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1482159938-13239-1-git-send-email-jbrunet@baylibre.com>

In genphy_config_eee_advert, the return value of phy_read_mmd_indirect is
checked to know if the register could be accessed but the result is
assigned to a 'u32'.
Changing to 'int' to correctly get errors from phy_read_mmd_indirect.

Fixes: d853d145ea3e ("net: phy: add an option to disable EEE advertisement")
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
 drivers/net/phy/phy_device.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 9c06f8028f0c..ee5ebadb1463 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1187,8 +1187,8 @@ static int genphy_config_advert(struct phy_device *phydev)
  */
 static int genphy_config_eee_advert(struct phy_device *phydev)
 {
-	u32 broken = phydev->eee_broken_modes;
-	u32 old_adv, adv;
+	int broken = phydev->eee_broken_modes;
+	int old_adv, adv;
 
 	/* Nothing to disable */
 	if (!broken)
-- 
2.7.4

^ permalink raw reply related

* [PATCH net 0/3] Fix integration of eee-broken-modes
From: Jerome Brunet @ 2016-12-19 15:05 UTC (permalink / raw)
  To: linux-arm-kernel

The purpose of this series is to fix the integration of the ethernet phy
property "eee-broken-modes" [0]

The v3 of this series has been merged, missing a fix (error reported by
kbuild robot) available in the v4 [1]

More importantly, Florian opposed adding a DT property mapping a device
register this directly [2]. The concern was that the property could be
abused to implement platform configuration policy. After discussing it,
I think we agreed that such information about the HW (defect) should appear
in the platform DT. However, the preferred way is to add a boolean property
for each EEE broken mode.

[0]: http://lkml.kernel.org/r/1480326409-25419-1-git-send-email-jbrunet at baylibre.com
[1]: http://lkml.kernel.org/r/1480348229-25672-1-git-send-email-jbrunet at baylibre.com
[2]: http://lkml.kernel.org/r/e14a3b0c-dc34-be14-48b3-518a0ad0c080 at gmail.com

Jerome Brunet (3):
  net: phy: fix sign type error in genphy_config_eee_advert
  net: phy: use boolean dt properties for eee broken modes
  dt: bindings: net: use boolean dt properties for eee broken modes

 Documentation/devicetree/bindings/net/phy.txt | 10 ++++++++--
 drivers/net/phy/phy_device.c                  | 22 +++++++++++++++++-----
 include/dt-bindings/net/mdio.h                | 19 -------------------
 3 files changed, 25 insertions(+), 26 deletions(-)
 delete mode 100644 include/dt-bindings/net/mdio.h

-- 
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