* [PATCH 8/9] net: thunderx: Support for XDP header adjustment
From: sunil.kovvuri at gmail.com @ 2017-05-02 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493730418-24606-1-git-send-email-sunil.kovvuri@gmail.com>
From: Sunil Goutham <sgoutham@cavium.com>
When in XDP mode reserve XDP_PACKET_HEADROOM bytes at the start
of receive buffer for XDP program to modify headers and adjust
packet start. Additional code changes done to handle such packets.
Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
---
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 63 ++++++++++++++++------
drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 9 +++-
2 files changed, 55 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index bb13dee..d6477af 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -502,13 +502,15 @@ static int nicvf_init_resources(struct nicvf *nic)
}
static inline bool nicvf_xdp_rx(struct nicvf *nic, struct bpf_prog *prog,
- struct cqe_rx_t *cqe_rx, struct snd_queue *sq)
+ struct cqe_rx_t *cqe_rx, struct snd_queue *sq,
+ struct sk_buff **skb)
{
struct xdp_buff xdp;
struct page *page;
u32 action;
- u16 len;
+ u16 len, offset = 0;
u64 dma_addr, cpu_addr;
+ void *orig_data;
/* Retrieve packet buffer's DMA address and length */
len = *((u16 *)((void *)cqe_rx + (3 * sizeof(u64))));
@@ -517,17 +519,47 @@ static inline bool nicvf_xdp_rx(struct nicvf *nic, struct bpf_prog *prog,
cpu_addr = nicvf_iova_to_phys(nic, dma_addr);
if (!cpu_addr)
return false;
+ cpu_addr = (u64)phys_to_virt(cpu_addr);
+ page = virt_to_page((void *)cpu_addr);
- xdp.data = phys_to_virt(cpu_addr);
+ xdp.data_hard_start = page_address(page);
+ xdp.data = (void *)cpu_addr;
xdp.data_end = xdp.data + len;
+ orig_data = xdp.data;
rcu_read_lock();
action = bpf_prog_run_xdp(prog, &xdp);
rcu_read_unlock();
+ /* Check if XDP program has changed headers */
+ if (orig_data != xdp.data) {
+ len = xdp.data_end - xdp.data;
+ offset = orig_data - xdp.data;
+ dma_addr -= offset;
+ }
+
switch (action) {
case XDP_PASS:
- /* Pass on packet to network stack */
+ /* Check if it's a recycled page, if not
+ * unmap the DMA mapping.
+ *
+ * Recycled page holds an extra reference.
+ */
+ if (page_ref_count(page) == 1) {
+ dma_addr &= PAGE_MASK;
+ dma_unmap_page_attrs(&nic->pdev->dev, dma_addr,
+ RCV_FRAG_LEN + XDP_PACKET_HEADROOM,
+ DMA_FROM_DEVICE,
+ DMA_ATTR_SKIP_CPU_SYNC);
+ }
+
+ /* Build SKB and pass on packet to network stack */
+ *skb = build_skb(xdp.data,
+ RCV_FRAG_LEN - cqe_rx->align_pad + offset);
+ if (!*skb)
+ put_page(page);
+ else
+ skb_put(*skb, len);
return false;
case XDP_TX:
nicvf_xdp_sq_append_pkt(nic, sq, (u64)xdp.data, dma_addr, len);
@@ -537,7 +569,6 @@ static inline bool nicvf_xdp_rx(struct nicvf *nic, struct bpf_prog *prog,
case XDP_ABORTED:
trace_xdp_exception(nic->netdev, prog, action);
case XDP_DROP:
- page = virt_to_page(xdp.data);
/* Check if it's a recycled page, if not
* unmap the DMA mapping.
*
@@ -546,7 +577,8 @@ static inline bool nicvf_xdp_rx(struct nicvf *nic, struct bpf_prog *prog,
if (page_ref_count(page) == 1) {
dma_addr &= PAGE_MASK;
dma_unmap_page_attrs(&nic->pdev->dev, dma_addr,
- RCV_FRAG_LEN, DMA_FROM_DEVICE,
+ RCV_FRAG_LEN + XDP_PACKET_HEADROOM,
+ DMA_FROM_DEVICE,
DMA_ATTR_SKIP_CPU_SYNC);
}
put_page(page);
@@ -654,7 +686,7 @@ static void nicvf_rcv_pkt_handler(struct net_device *netdev,
struct napi_struct *napi,
struct cqe_rx_t *cqe_rx, struct snd_queue *sq)
{
- struct sk_buff *skb;
+ struct sk_buff *skb = NULL;
struct nicvf *nic = netdev_priv(netdev);
struct nicvf *snic = nic;
int err = 0;
@@ -676,15 +708,17 @@ static void nicvf_rcv_pkt_handler(struct net_device *netdev,
}
/* For XDP, ignore pkts spanning multiple pages */
- if (nic->xdp_prog && (cqe_rx->rb_cnt == 1))
- if (nicvf_xdp_rx(snic, nic->xdp_prog, cqe_rx, sq))
+ if (nic->xdp_prog && (cqe_rx->rb_cnt == 1)) {
+ /* Packet consumed by XDP */
+ if (nicvf_xdp_rx(snic, nic->xdp_prog, cqe_rx, sq, &skb))
return;
+ } else {
+ skb = nicvf_get_rcv_skb(snic, cqe_rx,
+ nic->xdp_prog ? true : false);
+ }
- skb = nicvf_get_rcv_skb(snic, cqe_rx, nic->xdp_prog ? true : false);
- if (!skb) {
- netdev_dbg(nic->netdev, "Packet not received\n");
+ if (!skb)
return;
- }
if (netif_msg_pktdata(nic)) {
netdev_info(nic->netdev, "%s: skb 0x%p, len=%d\n", netdev->name,
@@ -1672,9 +1706,6 @@ static int nicvf_xdp_setup(struct nicvf *nic, struct bpf_prog *prog)
return -EOPNOTSUPP;
}
- if (prog && prog->xdp_adjust_head)
- return -EOPNOTSUPP;
-
/* ALL SQs attached to CQs i.e same as RQs, are treated as
* XDP Tx queues and more Tx queues are allocated for
* network stack to send pkts out.
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
index ec234b6..43428ce 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
@@ -164,6 +164,11 @@ static inline int nicvf_alloc_rcv_buffer(struct nicvf *nic, struct rbdr *rbdr,
}
nic->rb_page_offset = 0;
+
+ /* Reserve space for header modifications by BPF program */
+ if (rbdr->is_xdp)
+ buf_len += XDP_PACKET_HEADROOM;
+
/* Check if it's recycled */
if (pgcache)
nic->rb_page = pgcache->page;
@@ -183,7 +188,7 @@ static inline int nicvf_alloc_rcv_buffer(struct nicvf *nic, struct rbdr *rbdr,
return -ENOMEM;
}
if (pgcache)
- pgcache->dma_addr = *rbuf;
+ pgcache->dma_addr = *rbuf + XDP_PACKET_HEADROOM;
nic->rb_page_offset += buf_len;
}
@@ -1575,6 +1580,8 @@ static void nicvf_unmap_rcv_buffer(struct nicvf *nic, u64 dma_addr,
*/
if (page_ref_count(page) != 1)
return;
+
+ len += XDP_PACKET_HEADROOM;
/* Receive buffers in XDP mode are mapped from page start */
dma_addr &= PAGE_MASK;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 9/9] net: thunderx: Optimize page recycling for XDP
From: sunil.kovvuri at gmail.com @ 2017-05-02 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493730418-24606-1-git-send-email-sunil.kovvuri@gmail.com>
From: Sunil Goutham <sgoutham@cavium.com>
Driver follows a method of taking one extra reference on the
page for recycling which is fine in usual packet path where
each 64KB page is segmented into multiple receive buffers.
But in XDP mode since there is just one receive buffer per
page taking extra page reference itself becomes big bottleneck
consuming ~50% of CPU cycles due to atomic operations.
This patch adds a internal ref count in pgcache for each
page and additional page references are taken in a batch
instead of just one at a time. Internal i.e 'pgcache->ref_count'
and page's i.e 'page->_refcount' counters are compared to check
page's recyclability.
Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
---
drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 57 +++++++++++++++++++---
drivers/net/ethernet/cavium/thunder/nicvf_queues.h | 1 +
2 files changed, 51 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
index 43428ce..2b18176 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
@@ -82,6 +82,8 @@ static void nicvf_free_q_desc_mem(struct nicvf *nic, struct q_desc_mem *dmem)
dmem->base = NULL;
}
+#define XDP_PAGE_REFCNT_REFILL 256
+
/* Allocate a new page or recycle one if possible
*
* We cannot optimize dma mapping here, since
@@ -90,9 +92,10 @@ static void nicvf_free_q_desc_mem(struct nicvf *nic, struct q_desc_mem *dmem)
* and not idx into RBDR ring, so can't refer to saved info.
* 3. There are multiple receive buffers per page
*/
-static struct pgcache *nicvf_alloc_page(struct nicvf *nic,
- struct rbdr *rbdr, gfp_t gfp)
+static inline struct pgcache *nicvf_alloc_page(struct nicvf *nic,
+ struct rbdr *rbdr, gfp_t gfp)
{
+ int ref_count;
struct page *page = NULL;
struct pgcache *pgcache, *next;
@@ -100,8 +103,23 @@ static struct pgcache *nicvf_alloc_page(struct nicvf *nic,
pgcache = &rbdr->pgcache[rbdr->pgidx];
page = pgcache->page;
/* Check if page can be recycled */
- if (page && (page_ref_count(page) != 1))
- page = NULL;
+ if (page) {
+ ref_count = page_ref_count(page);
+ /* Check if this page has been used once i.e 'put_page'
+ * called after packet transmission i.e internal ref_count
+ * and page's ref_count are equal i.e page can be recycled.
+ */
+ if (rbdr->is_xdp && (ref_count == pgcache->ref_count))
+ pgcache->ref_count--;
+ else
+ page = NULL;
+
+ /* In non-XDP mode, page's ref_count needs to be '1' for it
+ * to be recycled.
+ */
+ if (!rbdr->is_xdp && (ref_count != 1))
+ page = NULL;
+ }
if (!page) {
page = alloc_pages(gfp | __GFP_COMP | __GFP_NOWARN, 0);
@@ -120,11 +138,30 @@ static struct pgcache *nicvf_alloc_page(struct nicvf *nic,
/* Save the page in page cache */
pgcache->page = page;
pgcache->dma_addr = 0;
+ pgcache->ref_count = 0;
rbdr->pgalloc++;
}
- /* Take extra page reference for recycling */
- page_ref_add(page, 1);
+ /* Take additional page references for recycling */
+ if (rbdr->is_xdp) {
+ /* Since there is single RBDR (i.e single core doing
+ * page recycling) per 8 Rx queues, in XDP mode adjusting
+ * page references atomically is the biggest bottleneck, so
+ * take bunch of references at a time.
+ *
+ * So here, below reference counts defer by '1'.
+ */
+ if (!pgcache->ref_count) {
+ pgcache->ref_count = XDP_PAGE_REFCNT_REFILL;
+ page_ref_add(page, XDP_PAGE_REFCNT_REFILL);
+ }
+ } else {
+ /* In non-XDP case, single 64K page is divided across multiple
+ * receive buffers, so cost of recycling is less anyway.
+ * So we can do with just one extra reference.
+ */
+ page_ref_add(page, 1);
+ }
rbdr->pgidx++;
rbdr->pgidx &= (rbdr->pgcnt - 1);
@@ -327,8 +364,14 @@ static void nicvf_free_rbdr(struct nicvf *nic, struct rbdr *rbdr)
head = 0;
while (head < rbdr->pgcnt) {
pgcache = &rbdr->pgcache[head];
- if (pgcache->page && page_ref_count(pgcache->page) != 0)
+ if (pgcache->page && page_ref_count(pgcache->page) != 0) {
+ if (!rbdr->is_xdp) {
+ put_page(pgcache->page);
+ continue;
+ }
+ page_ref_sub(pgcache->page, pgcache->ref_count - 1);
put_page(pgcache->page);
+ }
head++;
}
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
index a07d5b4..5785852 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
@@ -216,6 +216,7 @@ struct q_desc_mem {
struct pgcache {
struct page *page;
+ int ref_count;
u64 dma_addr;
};
--
2.7.4
^ permalink raw reply related
* [PATCH 0/5] KVM/ARM: Fixes for 4.12-rc1
From: Marc Zyngier @ 2017-05-02 13:30 UTC (permalink / raw)
To: linux-arm-kernel
Here's a handful of random fixes I've queued locally that didn't have
a chance to make it in 4.11.
The first two patches avoid stack-protector messing with the HYP code,
as this ends up being a complete disaster.
The following two patches fix a bug introduced in the new vgic, where
we may queue HW interrupts with the Pending+Active state, which is
illegal.
The final patch fixes a misinterpretation of the spec, where we
compute the number of APxRn register based on the number of priorities
instead of using the number of preemption levels.
I've tagged the first 4 patches for stable, given that we're doing
something potentially harmful. The last patch is more of a theoretical
issue at this stage, so probably need for a backport.
Marc Zyngier (5):
arm64: KVM: Do not use stack-protector to compile EL2 code
arm: KVM: Do not use stack-protector to compile HYP code
KVM: arm/arm64: vgic-v2: Do not use Active+Pending state for a HW
interrupt
KVM: arm/arm64: vgic-v3: Do not use Active+Pending state for a HW
interrupt
KVM: arm/arm64: vgic-v3: Use PREbits to infer the number of
ICH_APxRn_EL2 registers
arch/arm/kvm/hyp/Makefile | 2 ++
arch/arm64/kvm/hyp/Makefile | 2 ++
virt/kvm/arm/hyp/vgic-v3-sr.c | 18 +++++++++---------
virt/kvm/arm/vgic/vgic-v2.c | 7 +++++++
virt/kvm/arm/vgic/vgic-v3.c | 7 +++++++
5 files changed, 27 insertions(+), 9 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 1/5] arm64: KVM: Do not use stack-protector to compile EL2 code
From: Marc Zyngier @ 2017-05-02 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170502133041.10980-1-marc.zyngier@arm.com>
We like living dangerously. Nothing explicitely forbids stack-protector
to be used in the EL2 code, while distributions routinely compile their
kernel with it. We're just lucky that no code actually triggers the
instrumentation.
Let's not try our luck for much longer, and disable stack-protector
for code living at EL2.
Cc: stable at vger.kernel.org
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/kvm/hyp/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/kvm/hyp/Makefile b/arch/arm64/kvm/hyp/Makefile
index aaf42ae8d8c3..14c4e3b14bcb 100644
--- a/arch/arm64/kvm/hyp/Makefile
+++ b/arch/arm64/kvm/hyp/Makefile
@@ -2,6 +2,8 @@
# Makefile for Kernel-based Virtual Machine module, HYP part
#
+ccflags-y += -fno-stack-protector
+
KVM=../../../../virt/kvm
obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v2-sr.o
--
2.11.0
^ permalink raw reply related
* [PATCH 2/5] arm: KVM: Do not use stack-protector to compile HYP code
From: Marc Zyngier @ 2017-05-02 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170502133041.10980-1-marc.zyngier@arm.com>
We like living dangerously. Nothing explicitely forbids stack-protector
to be used in the HYP code, while distributions routinely compile their
kernel with it. We're just lucky that no code actually triggers the
instrumentation.
Let's not try our luck for much longer, and disable stack-protector
for code living at HYP.
Cc: stable at vger.kernel.org
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm/kvm/hyp/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
index 3023bb530edf..8679405b0b2b 100644
--- a/arch/arm/kvm/hyp/Makefile
+++ b/arch/arm/kvm/hyp/Makefile
@@ -2,6 +2,8 @@
# Makefile for Kernel-based Virtual Machine module, HYP part
#
+ccflags-y += -fno-stack-protector
+
KVM=../../../../virt/kvm
obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v2-sr.o
--
2.11.0
^ permalink raw reply related
* [PATCH 3/5] KVM: arm/arm64: vgic-v2: Do not use Active+Pending state for a HW interrupt
From: Marc Zyngier @ 2017-05-02 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170502133041.10980-1-marc.zyngier@arm.com>
When an interrupt is injected with the HW bit set (indicating that
deactivation should be propagated to the physical distributor),
special care must be taken so that we never mark the corresponding
LR with the Active+Pending state (as the pending state is kept in
the physycal distributor).
Cc: stable at vger.kernel.org
Fixes: 140b086dd197 ("KVM: arm/arm64: vgic-new: Add GICv2 world switch backend")
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/vgic/vgic-v2.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/virt/kvm/arm/vgic/vgic-v2.c b/virt/kvm/arm/vgic/vgic-v2.c
index a65757aab6d3..504b4bd0d651 100644
--- a/virt/kvm/arm/vgic/vgic-v2.c
+++ b/virt/kvm/arm/vgic/vgic-v2.c
@@ -149,6 +149,13 @@ void vgic_v2_populate_lr(struct kvm_vcpu *vcpu, struct vgic_irq *irq, int lr)
if (irq->hw) {
val |= GICH_LR_HW;
val |= irq->hwintid << GICH_LR_PHYSID_CPUID_SHIFT;
+ /*
+ * Never set pending+active on a HW interrupt, as the
+ * pending state is kept@the physical distributor
+ * level.
+ */
+ if (irq->active && irq_is_pending(irq))
+ val &= ~GICH_LR_PENDING_BIT;
} else {
if (irq->config == VGIC_CONFIG_LEVEL)
val |= GICH_LR_EOI;
--
2.11.0
^ permalink raw reply related
* [PATCH 4/5] KVM: arm/arm64: vgic-v3: Do not use Active+Pending state for a HW interrupt
From: Marc Zyngier @ 2017-05-02 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170502133041.10980-1-marc.zyngier@arm.com>
When an interrupt is injected with the HW bit set (indicating that
deactivation should be propagated to the physical distributor),
special care must be taken so that we never mark the corresponding
LR with the Active+Pending state (as the pending state is kept in
the physycal distributor).
Cc: stable at vger.kernel.org
Fixes: 59529f69f504 ("KVM: arm/arm64: vgic-new: Add GICv3 world switch backend")
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/vgic/vgic-v3.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
index df1503650300..393779ebe87c 100644
--- a/virt/kvm/arm/vgic/vgic-v3.c
+++ b/virt/kvm/arm/vgic/vgic-v3.c
@@ -127,6 +127,13 @@ void vgic_v3_populate_lr(struct kvm_vcpu *vcpu, struct vgic_irq *irq, int lr)
if (irq->hw) {
val |= ICH_LR_HW;
val |= ((u64)irq->hwintid) << ICH_LR_PHYS_ID_SHIFT;
+ /*
+ * Never set pending+active on a HW interrupt, as the
+ * pending state is kept@the physical distributor
+ * level.
+ */
+ if (irq->active && irq_is_pending(irq))
+ val &= ~ICH_LR_PENDING_BIT;
} else {
if (irq->config == VGIC_CONFIG_LEVEL)
val |= ICH_LR_EOI;
--
2.11.0
^ permalink raw reply related
* [PATCH 5/5] KVM: arm/arm64: vgic-v3: Use PREbits to infer the number of ICH_APxRn_EL2 registers
From: Marc Zyngier @ 2017-05-02 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170502133041.10980-1-marc.zyngier@arm.com>
The GICv3 documentation is extremely confusing, as it talks about
the number of priorities represented by the ICH_APxRn_EL2 registers,
while it should really talk about the number of preemption levels.
This leads to a bug where we may access undefined ICH_APxRn_EL2
registers, since PREbits is allowed to be smaller than PRIbits.
Thankfully, nobody seem to have taken this path so far...
The fix is to use ICH_VTR_EL2.PREbits instead.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/hyp/vgic-v3-sr.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/virt/kvm/arm/hyp/vgic-v3-sr.c b/virt/kvm/arm/hyp/vgic-v3-sr.c
index bce6037cf01d..32c3295929b0 100644
--- a/virt/kvm/arm/hyp/vgic-v3-sr.c
+++ b/virt/kvm/arm/hyp/vgic-v3-sr.c
@@ -22,7 +22,7 @@
#include <asm/kvm_hyp.h>
#define vtr_to_max_lr_idx(v) ((v) & 0xf)
-#define vtr_to_nr_pri_bits(v) (((u32)(v) >> 29) + 1)
+#define vtr_to_nr_pre_bits(v) (((u32)(v) >> 26) + 1)
static u64 __hyp_text __gic_v3_get_lr(unsigned int lr)
{
@@ -135,13 +135,13 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
if (used_lrs) {
int i;
- u32 nr_pri_bits;
+ u32 nr_pre_bits;
cpu_if->vgic_elrsr = read_gicreg(ICH_ELSR_EL2);
write_gicreg(0, ICH_HCR_EL2);
val = read_gicreg(ICH_VTR_EL2);
- nr_pri_bits = vtr_to_nr_pri_bits(val);
+ nr_pre_bits = vtr_to_nr_pre_bits(val);
for (i = 0; i < used_lrs; i++) {
if (cpu_if->vgic_elrsr & (1 << i))
@@ -152,7 +152,7 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
__gic_v3_set_lr(0, i);
}
- switch (nr_pri_bits) {
+ switch (nr_pre_bits) {
case 7:
cpu_if->vgic_ap0r[3] = read_gicreg(ICH_AP0R3_EL2);
cpu_if->vgic_ap0r[2] = read_gicreg(ICH_AP0R2_EL2);
@@ -162,7 +162,7 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
cpu_if->vgic_ap0r[0] = read_gicreg(ICH_AP0R0_EL2);
}
- switch (nr_pri_bits) {
+ switch (nr_pre_bits) {
case 7:
cpu_if->vgic_ap1r[3] = read_gicreg(ICH_AP1R3_EL2);
cpu_if->vgic_ap1r[2] = read_gicreg(ICH_AP1R2_EL2);
@@ -198,7 +198,7 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
u64 used_lrs = vcpu->arch.vgic_cpu.used_lrs;
u64 val;
- u32 nr_pri_bits;
+ u32 nr_pre_bits;
int i;
/*
@@ -217,12 +217,12 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
}
val = read_gicreg(ICH_VTR_EL2);
- nr_pri_bits = vtr_to_nr_pri_bits(val);
+ nr_pre_bits = vtr_to_nr_pre_bits(val);
if (used_lrs) {
write_gicreg(cpu_if->vgic_hcr, ICH_HCR_EL2);
- switch (nr_pri_bits) {
+ switch (nr_pre_bits) {
case 7:
write_gicreg(cpu_if->vgic_ap0r[3], ICH_AP0R3_EL2);
write_gicreg(cpu_if->vgic_ap0r[2], ICH_AP0R2_EL2);
@@ -232,7 +232,7 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
write_gicreg(cpu_if->vgic_ap0r[0], ICH_AP0R0_EL2);
}
- switch (nr_pri_bits) {
+ switch (nr_pre_bits) {
case 7:
write_gicreg(cpu_if->vgic_ap1r[3], ICH_AP1R3_EL2);
write_gicreg(cpu_if->vgic_ap1r[2], ICH_AP1R2_EL2);
--
2.11.0
^ permalink raw reply related
* [PATCH v2 29/30] dt-bindings: add vendor prefix for bananapi
From: Rob Herring @ 2017-05-02 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493621880.32195.13.camel@mtkswgap22>
+arm-soc
On Mon, May 1, 2017 at 1:58 AM, Sean Wang <sean.wang@mediatek.com> wrote:
> On Fri, 2017-04-28 at 15:37 -0500, Rob Herring wrote:
>> On Wed, Apr 26, 2017 at 05:26:13PM +0800, sean.wang at mediatek.com wrote:
>> > From: Sean Wang <sean.wang@mediatek.com>
>> >
>> > Banana Pi team in Sinovoip Co., Limited which are dedicated to
>> > design and manufacture open hardware product.
>> >
>> > Website: http://www.banana-pi.org/
>> >
>> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
>> > ---
>> > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>> > 1 file changed, 1 insertion(+)
>> >
>> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> > index ec0bfb9..8ca0f3c 100644
>> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> > @@ -44,6 +44,7 @@ avia avia semiconductor
>> > avic Shanghai AVIC Optoelectronics Co., Ltd.
>> > axentia Axentia Technologies AB
>> > axis Axis Communications AB
>> > +bananapi Banana Pi SINOVOP CO., LIMITED
>>
>> s/SINOVOP/SINOVOIP/
>
> Hi Rob,
>
> thanks for your careful reviewing , i will correct it in the next
> version.
>
> BTW, Could those related dts changes go through your tree if everything
> looks good? Because I find Matthias have been inactive for a while and
> the latest branch in his tree seems still staying on 4.10.
Happy to take binding doc changes, but I don't take dts changes
because those go thru arm-soc. If the platform maintainer is not
responsive, then we should replace or add maintainers.
Rob
^ permalink raw reply
* fsl, imx-parallel-display Question
From: Adam Ford @ 2017-05-02 13:55 UTC (permalink / raw)
To: linux-arm-kernel
I am trying to use a parallel LCD with an i.MX6Q board using the
device tree, but I was hoping to do it in the device tree itself
instead of modifying the "panel-simple" driver that most imx6q devices
appear to use. I have an omap product with the LCD, and I was hoping
to just re-use the panel timings, etc.
I found imx6q-tx6q-1010-comtft.dts didn't use "panel-simple", but
using that as an example doesn't work, for me yet I can get it working
with "panel-simple"
Looking at the driver for parallel-display.c, I states that "port at 1"
is the output port which is consistent with most of the boards that
use "panel-simple" but imx6q-tx6q-1010-comtft.dts does not have this.
The other thing I noticed is that "panel-simple" devices have an gpio
enable which I need, but but imx6q-tx6q-1010-comtft.dts does not have
this either.
Is "panel-simple" the only solution, or is there a way to integrate
the display info into the device tree and keep the enable-gpios stuff?
Is imx6q-tx6q-1010-comtft.dts doing something wrong?
adam
^ permalink raw reply
* [PATCH 3/4] net: macb: Add hardware PTP support
From: Rafal Ozieblo @ 2017-05-02 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414182850.GB7751@localhost.localdomain>
> From: Richard Cochran [mailto:richardcochran at gmail.com]
> Sent: 14 kwietnia 2017 20:29
> To: Rafal Ozieblo <rafalo@cadence.com>
> Cc: David Miller <davem@davemloft.net>; nicolas.ferre at atmel.com;
> netdev at vger.kernel.org; linux-kernel at vger.kernel.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> harinikatakamlinux at gmail.com; harini.katakam at xilinx.com;
> Andrei.Pistirica at microchip.com
> Subject: Re: [PATCH 3/4] net: macb: Add hardware PTP support
>
> On Thu, Apr 13, 2017 at 02:39:23PM +0100, Rafal Ozieblo wrote:
(...)
> > +static int gem_tsu_get_time(struct macb *bp, struct timespec64 *ts)
> > +{
> > + long first, second;
> > + u32 secl, sech;
> > + unsigned long flags;
> > +
> > + if (!bp || !ts)
> > + return -EINVAL;
>
> Useless test.
Sorry for me being too carefulness, I'll remove all tests.
>
(...)
> > +static int gem_ptp_gettime(struct ptp_clock_info *ptp, struct timespec64
> *ts)
> > +{
> > + struct macb *bp = container_of(ptp, struct macb, ptp_clock_info);
> > +
> > + if (!ptp || !ts)
> > + return -EINVAL;
>
> Useles test.
>
> What is the point of this wrapper function anyhow? Please remove it.
gem_ptp_gettime() is assigned in ptp_clock_info and it has to have
ptp_clock_info pointer as first parameter. gem_tsu_get_time() is used in
the source code but with macb pointer.
Do you want me to do something like:
gem_ptp_gettime(macb->ptp, ts);
and first would be getting macb pointer from ptp ?
struct macb *bp = container_of(ptp, struct macb, ptp_clock_info);
>
> > +
> > + gem_tsu_get_time(bp, ts);
> > + return 0;
> > +}
> > +
> > +static int gem_ptp_settime(struct ptp_clock_info *ptp,
> > + const struct timespec64 *ts)
> > +{
> > + struct macb *bp = container_of(ptp, struct macb, ptp_clock_info);
> > +
> > + if (!ptp || !ts)
> > + return -EINVAL;
>
> Another useless function.
ditto
>
> > + gem_tsu_set_time(bp, ts);
> > + return 0;
> > +}
> > +
> > +static int gem_ptp_enable(struct ptp_clock_info *ptp,
> > + struct ptp_clock_request *rq, int on)
> > +{
> > + struct macb *bp = container_of(ptp, struct macb, ptp_clock_info);
> > +
> > + if (!ptp || !rq)
> > + return -EINVAL;
>
> Sigh.
>
> > +
> > + switch (rq->type) {
> > + case PTP_CLK_REQ_EXTTS: /* Toggle TSU match interrupt */
> > + if (on)
> > + macb_writel(bp, IER, MACB_BIT(TCI));
>
> No locking to protect IER and IDE?
There is no need.
>
> > + else
> > + macb_writel(bp, IDR, MACB_BIT(TCI));
> > + break;
> > + case PTP_CLK_REQ_PEROUT: /* Toggle Periodic output */
> > + return -EOPNOTSUPP;
> > + /* break; */
> > + case PTP_CLK_REQ_PPS: /* Toggle TSU periodic (second)
> interrupt */
> > + if (on)
> > + macb_writel(bp, IER, MACB_BIT(SRI));
> > + else
> > + macb_writel(bp, IDR, MACB_BIT(SRI));
> > + break;
> > + default:
> > + break;
> > + }
> > + return 0;
> > +}
> > +
(...)
> > --
> > 2.4.5
> >
>
> Thanks,
> Richard
^ permalink raw reply
* [RESEND PATCH] spi: bcm63xx-hsspi: Export OF device ID table as module aliases
From: Jonas Gorski @ 2017-05-02 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170501201338.5368-1-andresgalacho@gmail.com>
On 1 May 2017 at 22:13, Andres Galacho <andresgalacho@gmail.com> wrote:
> The device table is required to load modules based on
> modaliases. After adding MODULE_DEVICE_TABLE, below entries
> for example will be added to module.alias:
> alias: of:N*T*Cbrcm,bcm6328-hsspiC*
> alias: of:N*T*Cbrcm,bcm6328-hsspi
>
> Signed-off-by: Andres Galacho <andresgalacho@gmail.com>
Not that it matters much with a trivial patch like this, but
Acked-by: Jonas Gorski <jonas.gorski@gmail.com>
also thanks for doing it.
Regards
Jonas
^ permalink raw reply
* [PATCH] arm: pmu: Get PMU working when the A53 is run in 32 bit mode
From: Al Cooper @ 2017-05-02 14:01 UTC (permalink / raw)
To: linux-arm-kernel
From: Al Cooper <al.cooper@broadcom.com>
When the A53 is run in A15 (32 bit) mode, the registers used to
access the counters are A15 style registers, but the actual
counters are the A53 counters not A15 counters. This patch will
select a PMU counters map for the A53 if the device tree pmu
"compatible" property includes "arm,cortex-a53-pmu".
Signed-off-by: Al Cooper <alcooperx@gmail.com>
---
arch/arm/kernel/perf_event_v7.c | 105 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 105 insertions(+)
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index ab6522b..f714a28 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -147,6 +147,49 @@
#define SCORPION_ITLB_MISS 0x12021
+/* ARMV8 A53 events when running in A15 mode. */
+#define ARMV8_PMUV3_PERFCTR_INST_RETIRED 0x08
+#define ARMV8_PMUV3_PERFCTR_PC_WRITE_RETIRED 0x0C
+
+#define ARMV8_PMUV3_PERFCTR_SW_INCR 0x00
+#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL 0x03
+#define ARMV8_PMUV3_PERFCTR_L1D_CACHE 0x04
+#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED 0x10
+#define ARMV8_PMUV3_PERFCTR_CPU_CYCLES 0x11
+#define ARMV8_PMUV3_PERFCTR_BR_PRED 0x12
+
+#define ARMV8_PMUV3_PERFCTR_L1I_CACHE_REFILL 0x01
+#define ARMV8_PMUV3_PERFCTR_L1I_TLB_REFILL 0x02
+#define ARMV8_PMUV3_PERFCTR_L1D_TLB_REFILL 0x05
+#define ARMV8_PMUV3_PERFCTR_MEM_ACCESS 0x13
+#define ARMV8_PMUV3_PERFCTR_L1I_CACHE 0x14
+#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_WB 0x15
+#define ARMV8_PMUV3_PERFCTR_L2D_CACHE 0x16
+#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL 0x17
+#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_WB 0x18
+#define ARMV8_PMUV3_PERFCTR_BUS_ACCESS 0x19
+#define ARMV8_PMUV3_PERFCTR_MEMORY_ERROR 0x1A
+#define ARMV8_PMUV3_PERFCTR_BUS_CYCLES 0x1D
+#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_ALLOCATE 0x1F
+#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_ALLOCATE 0x20
+#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED_RETIRED 0x22
+#define ARMV8_PMUV3_PERFCTR_STALL_FRONTEND 0x23
+#define ARMV8_PMUV3_PERFCTR_STALL_BACKEND 0x24
+#define ARMV8_PMUV3_PERFCTR_L1D_TLB 0x25
+#define ARMV8_PMUV3_PERFCTR_L1I_TLB 0x26
+#define ARMV8_PMUV3_PERFCTR_L2I_CACHE 0x27
+#define ARMV8_PMUV3_PERFCTR_L2I_CACHE_REFILL 0x28
+#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_ALLOCATE 0x29
+#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_REFILL 0x2A
+#define ARMV8_PMUV3_PERFCTR_L3D_CACHE 0x2B
+#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_WB 0x2C
+#define ARMV8_PMUV3_PERFCTR_L2D_TLB_REFILL 0x2D
+#define ARMV8_PMUV3_PERFCTR_L2I_TLB_REFILL 0x2E
+#define ARMV8_PMUV3_PERFCTR_L2D_TLB 0x2F
+#define ARMV8_PMUV3_PERFCTR_L2I_TLB 0x30
+
+#define ARMV8_A53_PERFCTR_PREF_LINEFILL 0xC2
+
/*
* Cortex-A8 HW events mapping
*
@@ -340,6 +383,48 @@
};
/*
+ * Cortex-A53 HW events mapping when running the A53 in A15 mode
+ */
+static const unsigned armv7_a53_perf_map[PERF_COUNT_HW_MAX] = {
+ PERF_MAP_ALL_UNSUPPORTED,
+ [PERF_COUNT_HW_CPU_CYCLES] = ARMV8_PMUV3_PERFCTR_CPU_CYCLES,
+ [PERF_COUNT_HW_INSTRUCTIONS] = ARMV8_PMUV3_PERFCTR_INST_RETIRED,
+ [PERF_COUNT_HW_CACHE_REFERENCES] = ARMV8_PMUV3_PERFCTR_L1D_CACHE,
+ [PERF_COUNT_HW_CACHE_MISSES] = ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL,
+ [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = ARMV8_PMUV3_PERFCTR_PC_WRITE_RETIRED,
+ [PERF_COUNT_HW_BRANCH_MISSES] = ARMV8_PMUV3_PERFCTR_BR_MIS_PRED,
+ [PERF_COUNT_HW_BUS_CYCLES] = ARMV8_PMUV3_PERFCTR_BUS_CYCLES,
+};
+
+static const unsigned armv7_a53_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
+ [PERF_COUNT_HW_CACHE_OP_MAX]
+ [PERF_COUNT_HW_CACHE_RESULT_MAX] = {
+ PERF_CACHE_MAP_ALL_UNSUPPORTED,
+
+ [C(L1D)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L1D_CACHE,
+ [C(L1D)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL,
+ [C(L1D)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L1D_CACHE,
+ [C(L1D)][C(OP_WRITE)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL,
+ [C(L1D)][C(OP_PREFETCH)][C(RESULT_MISS)] = ARMV8_A53_PERFCTR_PREF_LINEFILL,
+
+ [C(L1I)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L1I_CACHE,
+ [C(L1I)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L1I_CACHE_REFILL,
+
+ [C(LL)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE,
+ [C(LL)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL,
+ [C(LL)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE,
+ [C(LL)][C(OP_WRITE)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL,
+
+ [C(DTLB)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L1D_TLB_REFILL,
+ [C(ITLB)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L1I_TLB_REFILL,
+
+ [C(BPU)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_BR_PRED,
+ [C(BPU)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_BR_MIS_PRED,
+ [C(BPU)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_BR_PRED,
+ [C(BPU)][C(OP_WRITE)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_BR_MIS_PRED,
+};
+
+/*
* Cortex-A7 HW events mapping
*/
static const unsigned armv7_a7_perf_map[PERF_COUNT_HW_MAX] = {
@@ -1129,6 +1214,12 @@ static int armv7_a15_map_event(struct perf_event *event)
&armv7_a15_perf_cache_map, 0xFF);
}
+static int armv7_a53_map_event(struct perf_event *event)
+{
+ return armpmu_map_event(event, &armv7_a53_perf_map,
+ &armv7_a53_perf_cache_map, 0xFF);
+}
+
static int armv7_a7_map_event(struct perf_event *event)
{
return armpmu_map_event(event, &armv7_a7_perf_map,
@@ -1240,6 +1331,19 @@ static int armv7_a15_pmu_init(struct arm_pmu *cpu_pmu)
return armv7_probe_num_events(cpu_pmu);
}
+static int armv7_a53_pmu_init(struct arm_pmu *cpu_pmu)
+{
+ armv7pmu_init(cpu_pmu);
+ cpu_pmu->name = "armv7_cortex_a15_on_a53";
+ cpu_pmu->map_event = armv7_a53_map_event;
+ cpu_pmu->set_event_filter = armv7pmu_set_event_filter;
+ cpu_pmu->attr_groups[ARMPMU_ATTR_GROUP_EVENTS] =
+ &armv7_pmuv2_events_attr_group;
+ cpu_pmu->attr_groups[ARMPMU_ATTR_GROUP_FORMATS] =
+ &armv7_pmu_format_attr_group;
+ return armv7_probe_num_events(cpu_pmu);
+}
+
static int armv7_a7_pmu_init(struct arm_pmu *cpu_pmu)
{
armv7pmu_init(cpu_pmu);
@@ -2000,6 +2104,7 @@ static int scorpion_mp_pmu_init(struct arm_pmu *cpu_pmu)
}
static const struct of_device_id armv7_pmu_of_device_ids[] = {
+ {.compatible = "arm,cortex-a53-pmu", .data = armv7_a53_pmu_init},
{.compatible = "arm,cortex-a17-pmu", .data = armv7_a17_pmu_init},
{.compatible = "arm,cortex-a15-pmu", .data = armv7_a15_pmu_init},
{.compatible = "arm,cortex-a12-pmu", .data = armv7_a12_pmu_init},
--
1.9.0.138.g2de3478
^ permalink raw reply related
* [v6,10/23] drivers/fsi: Add device read/write/peek API
From: Eddie James @ 2017-05-02 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d0d2932a-e69e-bda5-5731-f1bd46fca265@linux.vnet.ibm.com>
On Apr 10, 2017, at 3:46 PM, Christopher Bostic
<cbostic@linux.vnet.ibm.com> wrote:
> From: Jeremy Kerr <jk@ozlabs.org>
>
> This change introduces the fsi device API: simple read, write and peek
> accessors for the devices' address spaces.
>
> Includes contributions from Chris Bostic <cbostic@linux.vnet.ibm.com>
> and Edward A. James <eajames@us.ibm.com>.
>
> Signed-off-by: Edward A. James <eajames@us.ibm.com>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
> Signed-off-by: Chris Bostic <cbostic@linux.vnet.ibm.com>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> drivers/fsi/fsi-core.c | 33 +++++++++++++++++++++++++++++++++
> include/linux/fsi.h | 7 ++++++-
> 2 files changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
> index a8faa89..4da0b030 100644
> --- a/drivers/fsi/fsi-core.c
> +++ b/drivers/fsi/fsi-core.c
> @@ -32,6 +32,8 @@
> #define FSI_SLAVE_CONF_CRC_MASK 0x0000000f
> #define FSI_SLAVE_CONF_DATA_BITS 28
>
> +#define FSI_PEEK_BASE 0x410
> +
> static const int engine_page_size = 0x400;
>
> #define FSI_SLAVE_BASE 0x800
> @@ -73,9 +75,40 @@ static int fsi_master_read(struct fsi_master
> *master, int link,
> uint8_t slave_id, uint32_t addr, void *val, size_t size);
> static int fsi_master_write(struct fsi_master *master, int link,
> uint8_t slave_id, uint32_t addr, const void *val, size_t size);
> +static int fsi_slave_read(struct fsi_slave *slave, uint32_t addr,
> + void *val, size_t size);
> +static int fsi_slave_write(struct fsi_slave *slave, uint32_t addr,
> + const void *val, size_t size);
>
> /* FSI endpoint-device support */
>
> +int fsi_device_read(struct fsi_device *dev, uint32_t addr, void *val,
> + size_t size)
> +{
> + if (addr > dev->size || size > dev->size || addr > dev->size - size)
> + return -EINVAL;
> +
> + return fsi_slave_read(dev->slave, dev->addr + addr, val, size);
> +}
> +EXPORT_SYMBOL_GPL(fsi_device_read);
> +
> +int fsi_device_write(struct fsi_device *dev, uint32_t addr, const
> void *val,
> + size_t size)
> +{
> + if (addr > dev->size || size > dev->size || addr > dev->size - size)
> + return -EINVAL;
> +
> + return fsi_slave_write(dev->slave, dev->addr + addr, val, size);
> +}
> +EXPORT_SYMBOL_GPL(fsi_device_write);
> +
> +int fsi_device_peek(struct fsi_device *dev, void *val)
> +{
> + uint32_t addr = FSI_PEEK_BASE + ((dev->unit - 2) *
> sizeof(uint32_t));
> +
> + return fsi_slave_read(dev->slave, addr, val, sizeof(uint32_t));
> +}
> +
> static void fsi_device_release(struct device *_device)
> {
> struct fsi_device *device = to_fsi_dev(_device);
> diff --git a/include/linux/fsi.h b/include/linux/fsi.h
> index efa55ba..66bce48 100644
> --- a/include/linux/fsi.h
> +++ b/include/linux/fsi.h
> @@ -27,6 +27,12 @@ struct fsi_device {
> uint32_t size;
> };
>
> +extern int fsi_device_read(struct fsi_device *dev, uint32_t addr,
> + void *val, size_t size);
> +extern int fsi_device_write(struct fsi_device *dev, uint32_t addr,
> + const void *val, size_t size);
> +extern int fsi_device_peek(struct fsi_device *dev, void *val);
> +
> struct fsi_device_id {
> u8 engine_type;
> u8 version;
> @@ -40,7 +46,6 @@ struct fsi_device_id {
> #define FSI_DEVICE_VERSIONED(t, v) \
> .engine_type = (t), .version = (v),
>
> -
> struct fsi_driver {
> struct device_driver drv;
> const struct fsi_device_id *id_table;
>
I also wrote a driver against this API (an i2c algorithm). Everything
looks good and working well.
Edward (Eddie) James <eajames@linux.vnet.ibm.com>
^ permalink raw reply
* [PATCH v4 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Rob Herring @ 2017-05-02 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <60b3c062-d4bb-6502-61be-ada830cf58f7@collabora.com>
On Tue, May 2, 2017 at 6:23 AM, Guillaume Tucker
<guillaume.tucker@collabora.com> wrote:
> Hi Rob,
>
> On 28/04/17 20:27, Rob Herring wrote:
>>
>> On Tue, Apr 25, 2017 at 02:16:16PM +0100, Guillaume Tucker wrote:
>
>
>>> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>>> b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>>> new file mode 100644
>>> index 000000000000..547ddeceb498
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>>> @@ -0,0 +1,82 @@
>>> +ARM Mali Midgard GPU
>>> +====================
>>> +
>>> +Required properties:
>>> +
>>> +- compatible :
>>> + * Must be one of the following:
>>> + + "arm,mali-t60x"
>>> + + "arm,mali-t62x"
>>
>>
>> Don't use wildcards.
>
>
> Sure, old habits die hard... I'll fix it in patch v5.
>
>>> + + "arm,mali-t720"
>>> + + "arm,mali-t760"
>>> + + "arm,mali-t820"
>>> + + "arm,mali-t830"
>>> + + "arm,mali-t860"
>>> + + "arm,mali-t880"
>>> + * And, optionally, one of the vendor specific compatible:
>>
>>
>> IMO, these should not be optional.
>
>
> Well, vendor compatible strings are clearly optional for the
> Utgard GPU series for which the bindings docs were recently
> merged. It seems that whether these should be optional or not,
> the documentation should be consistent between at least all
> similar types of devices like Midgard and Utgard GPUs. They have
> different architectures but from a device tree point of view,
> they both have the same kind of SoC-specific integration (clocks,
> irqs, regulators...).
Clocks should not vary by SoC. There is often variation because clocks
get driven by same source or are not s/w controlled, but really there
should not be that variation. I noticed Utgard has 2 clocks. So is
Midgard really just 1 clock? The DT should have all the clocks listed
in the TRMs.
> So was this was overlooked in the Utgard case and should it
> ideally be fixed there as well as non-optional? Or, is it OK to
> keep these optional on a second thought?
Probably should be required in the Utgard case as well.
Rob
^ permalink raw reply
* fsl, imx-parallel-display Question
From: Lothar Waßmann @ 2017-05-02 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xLNgy77ocUM04--11vUBsL198+3_g_ur+Yj8jTtj3SNNQ@mail.gmail.com>
Hi,
On Tue, 2 May 2017 08:55:20 -0500 Adam Ford wrote:
> I am trying to use a parallel LCD with an i.MX6Q board using the
> device tree, but I was hoping to do it in the device tree itself
> instead of modifying the "panel-simple" driver that most imx6q devices
> appear to use. I have an omap product with the LCD, and I was hoping
> to just re-use the panel timings, etc.
>
> I found imx6q-tx6q-1010-comtft.dts didn't use "panel-simple", but
> using that as an example doesn't work, for me yet I can get it working
> with "panel-simple"
>
> Looking at the driver for parallel-display.c, I states that "port at 1"
> is the output port which is consistent with most of the boards that
> use "panel-simple" but imx6q-tx6q-1010-comtft.dts does not have this.
> The other thing I noticed is that "panel-simple" devices have an gpio
> enable which I need, but but imx6q-tx6q-1010-comtft.dts does not have
> this either.
>
> Is "panel-simple" the only solution, or is there a way to integrate
> the display info into the device tree and keep the enable-gpios stuff?
> Is imx6q-tx6q-1010-comtft.dts doing something wrong?
>
You can specify the display timings in the 'display-timings' subnode of
the display at di0 node. The active timing can be selected by setting the
'native-mode' property appropriately.
Lothar Wa?mann
^ permalink raw reply
* fsl, imx-parallel-display Question
From: Lucas Stach @ 2017-05-02 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xLNgy77ocUM04--11vUBsL198+3_g_ur+Yj8jTtj3SNNQ@mail.gmail.com>
Am Dienstag, den 02.05.2017, 08:55 -0500 schrieb Adam Ford:
> I am trying to use a parallel LCD with an i.MX6Q board using the
> device tree, but I was hoping to do it in the device tree itself
> instead of modifying the "panel-simple" driver that most imx6q devices
> appear to use. I have an omap product with the LCD, and I was hoping
> to just re-use the panel timings, etc.
>
> I found imx6q-tx6q-1010-comtft.dts didn't use "panel-simple", but
> using that as an example doesn't work, for me yet I can get it working
> with "panel-simple"
>
> Looking at the driver for parallel-display.c, I states that "port at 1"
> is the output port which is consistent with most of the boards that
> use "panel-simple" but imx6q-tx6q-1010-comtft.dts does not have this.
> The other thing I noticed is that "panel-simple" devices have an gpio
> enable which I need, but but imx6q-tx6q-1010-comtft.dts does not have
> this either.
>
> Is "panel-simple" the only solution, or is there a way to integrate
> the display info into the device tree and keep the enable-gpios stuff?
Please use the panel-simple option. It's the agreed solution to describe
the panels in DT and is the only option that is acceptable if you ever
try to upstream your DT.
> Is imx6q-tx6q-1010-comtft.dts doing something wrong?
It's using the deprecated way of describing the attached panel, by
putting the timings in the DT. This is not acceptable for new DTs, so
please don't try to replicate this.
Regards,
Lucas
^ permalink raw reply
* [PATCH] arm: pmu: Get PMU working when the A53 is run in 32 bit mode
From: Marc Zyngier @ 2017-05-02 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493733691-43814-1-git-send-email-alcooperx@gmail.com>
Hi Al,
On 02/05/17 15:01, Al Cooper wrote:
> From: Al Cooper <al.cooper@broadcom.com>
>
> When the A53 is run in A15 (32 bit) mode, the registers used to
> access the counters are A15 style registers, but the actual
> counters are the A53 counters not A15 counters. This patch will
> select a PMU counters map for the A53 if the device tree pmu
> "compatible" property includes "arm,cortex-a53-pmu".
I wasn't aware of an "A15 mode"! Is there an ARM3 mode, while we're at
it? ;-)
More seriously, you seem to take the problem from the wrong end. If you
have an ARMv8 core, you should use the PMUv3 driver (because that is
what your A53 has), and not the ARMv7 PMU.
To that affect, I've posted this[1] a while ago. Can you please give it
a go?
Thanks,
M.
[1]: https://www.spinics.net/lists/arm-kernel/msg571476.html
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 1/5] arm64: KVM: Do not use stack-protector to compile EL2 code
From: Catalin Marinas @ 2017-05-02 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170502133041.10980-2-marc.zyngier@arm.com>
On Tue, May 02, 2017 at 02:30:37PM +0100, Marc Zyngier wrote:
> We like living dangerously. Nothing explicitely forbids stack-protector
> to be used in the EL2 code, while distributions routinely compile their
> kernel with it. We're just lucky that no code actually triggers the
> instrumentation.
>
> Let's not try our luck for much longer, and disable stack-protector
> for code living at EL2.
>
> Cc: stable at vger.kernel.org
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm64/kvm/hyp/Makefile | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/kvm/hyp/Makefile b/arch/arm64/kvm/hyp/Makefile
> index aaf42ae8d8c3..14c4e3b14bcb 100644
> --- a/arch/arm64/kvm/hyp/Makefile
> +++ b/arch/arm64/kvm/hyp/Makefile
> @@ -2,6 +2,8 @@
> # Makefile for Kernel-based Virtual Machine module, HYP part
> #
>
> +ccflags-y += -fno-stack-protector
> +
While you are at it, should we have a -fpic here as well? The hyp code
runs at a different location than the rest of the kernel.
--
Catalin
^ permalink raw reply
* [PATCH 0/5] KVM/ARM: Fixes for 4.12-rc1
From: Paolo Bonzini @ 2017-05-02 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170502133041.10980-1-marc.zyngier@arm.com>
On 02/05/2017 15:30, Marc Zyngier wrote:
> Here's a handful of random fixes I've queued locally that didn't have
> a chance to make it in 4.11.
>
> The first two patches avoid stack-protector messing with the HYP code,
> as this ends up being a complete disaster.
>
> The following two patches fix a bug introduced in the new vgic, where
> we may queue HW interrupts with the Pending+Active state, which is
> illegal.
>
> The final patch fixes a misinterpretation of the spec, where we
> compute the number of APxRn register based on the number of priorities
> instead of using the number of preemption levels.
>
> I've tagged the first 4 patches for stable, given that we're doing
> something potentially harmful. The last patch is more of a theoretical
> issue at this stage, so probably need for a backport.
Would you like me to apply them, or are you looking for reviews and
going to send them in a pull request?
I can wait a couple days before sending my own pull request to Linus.
Paolo
^ permalink raw reply
* [PATCH] ARM: imx_v6_v7_defconfig: Enable cpufreq governors
From: Leonard Crestez @ 2017-05-02 14:46 UTC (permalink / raw)
To: linux-arm-kernel
Enable more common cpufreq governors in imx defconfig because this is
very useful for testing. In particular you can't use cpufreq-set -f
$FREQ without explicitly defining CONFIG_CPU_FREQ_GOV_USERSPACE=y.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
It might make sense for all governors to be enabled by default from
drivers/cpufreq/Kconfig and allow defconfigs to be shorter.
Right now the descriptions for some of them includes a line that says
"If in doubt, say Y" but the config options don't have actually have a
default value defined and they effectively default to N.
Cycling via savedefconfig on shawnguo/for-next also generates some
reordering for some newly added options CONFIG_TOUCHSCREEN_MAX11801=y
and CONFIG_HID_MULTITOUCH=y. Those were not included but it's strange
that this happens. Maybe those options were inserted manually, or
otherwise there is an annoying bug in kconfig?
arch/arm/configs/imx_v6_v7_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index bb6fa56..bf1e7e3 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -55,6 +55,9 @@ CONFIG_CMDLINE="noinitrd console=ttymxc0,115200"
CONFIG_KEXEC=y
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_CPU_FREQ_GOV_POWERSAVE=y
+CONFIG_CPU_FREQ_GOV_USERSPACE=y
+CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
CONFIG_ARM_IMX6Q_CPUFREQ=y
CONFIG_CPU_IDLE=y
CONFIG_VFP=y
--
2.7.4
^ permalink raw reply related
* [PATCH 1/5] arm64: KVM: Do not use stack-protector to compile EL2 code
From: Ard Biesheuvel @ 2017-05-02 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170502144029.GB29224@e104818-lin.cambridge.arm.com>
On 2 May 2017 at 15:40, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Tue, May 02, 2017 at 02:30:37PM +0100, Marc Zyngier wrote:
>> We like living dangerously. Nothing explicitely forbids stack-protector
>> to be used in the EL2 code, while distributions routinely compile their
>> kernel with it. We're just lucky that no code actually triggers the
>> instrumentation.
>>
>> Let's not try our luck for much longer, and disable stack-protector
>> for code living at EL2.
>>
>> Cc: stable at vger.kernel.org
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>> arch/arm64/kvm/hyp/Makefile | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm64/kvm/hyp/Makefile b/arch/arm64/kvm/hyp/Makefile
>> index aaf42ae8d8c3..14c4e3b14bcb 100644
>> --- a/arch/arm64/kvm/hyp/Makefile
>> +++ b/arch/arm64/kvm/hyp/Makefile
>> @@ -2,6 +2,8 @@
>> # Makefile for Kernel-based Virtual Machine module, HYP part
>> #
>>
>> +ccflags-y += -fno-stack-protector
>> +
>
> While you are at it, should we have a -fpic here as well? The hyp code
> runs at a different location than the rest of the kernel.
>
-fpic almost guarantees you will get position dependent but runtime
relocatable code (i.e., symbol references indirected via GOT entries
which need to be fixed up at runtime etc), unless you play around with
hidden visibility etc. For the same reason, the EFI stub does not
support being built with -fpic either.
Adding -mcmodel=small explicitly is much more likely to do anything
meaningful here, but only in case we need to set it to 'large'
globally in the future.
^ permalink raw reply
* [PATCH v4 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Guillaume Tucker @ 2017-05-02 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqK8rjvFW=LFb7==Qho-MHVew-O_vAJ+M6wcFJGfVD6r1A@mail.gmail.com>
On 02/05/17 15:13, Rob Herring wrote:
> On Tue, May 2, 2017 at 6:23 AM, Guillaume Tucker
> <guillaume.tucker@collabora.com> wrote:
>> Hi Rob,
>>
>> On 28/04/17 20:27, Rob Herring wrote:
>>>
>>> On Tue, Apr 25, 2017 at 02:16:16PM +0100, Guillaume Tucker wrote:
>>
>>
>>>> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>>>> b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>>>> new file mode 100644
>>>> index 000000000000..547ddeceb498
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>>>> @@ -0,0 +1,82 @@
>>>> +ARM Mali Midgard GPU
>>>> +====================
>>>> +
>>>> +Required properties:
>>>> +
>>>> +- compatible :
>>>> + * Must be one of the following:
>>>> + + "arm,mali-t60x"
>>>> + + "arm,mali-t62x"
>>>
>>>
>>> Don't use wildcards.
>>
>>
>> Sure, old habits die hard... I'll fix it in patch v5.
>>
>>>> + + "arm,mali-t720"
>>>> + + "arm,mali-t760"
>>>> + + "arm,mali-t820"
>>>> + + "arm,mali-t830"
>>>> + + "arm,mali-t860"
>>>> + + "arm,mali-t880"
>>>> + * And, optionally, one of the vendor specific compatible:
>>>
>>>
>>> IMO, these should not be optional.
>>
>>
>> Well, vendor compatible strings are clearly optional for the
>> Utgard GPU series for which the bindings docs were recently
>> merged. It seems that whether these should be optional or not,
>> the documentation should be consistent between at least all
>> similar types of devices like Midgard and Utgard GPUs. They have
>> different architectures but from a device tree point of view,
>> they both have the same kind of SoC-specific integration (clocks,
>> irqs, regulators...).
>
> Clocks should not vary by SoC. There is often variation because clocks
> get driven by same source or are not s/w controlled, but really there
> should not be that variation. I noticed Utgard has 2 clocks. So is
> Midgard really just 1 clock? The DT should have all the clocks listed
> in the TRMs.
I meant to say that the clock sources are different in each SoC,
but yes the same clock input is always needed by the GPU.
The TRM is confidential but to the best of my knowledge and based
on existing device trees and the out-of-tree kernel driver, the
Midgard GPU has only one clock input.
>> So was this was overlooked in the Utgard case and should it
>> ideally be fixed there as well as non-optional? Or, is it OK to
>> keep these optional on a second thought?
>
> Probably should be required in the Utgard case as well.
OK, so I'll make the vendor compatible strings required (for
Midgard) in patch v5.
Guillaume
^ permalink raw reply
* [PATCH 1/5] arm64: KVM: Do not use stack-protector to compile EL2 code
From: Marc Zyngier @ 2017-05-02 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170502144029.GB29224@e104818-lin.cambridge.arm.com>
On 02/05/17 15:40, Catalin Marinas wrote:
> On Tue, May 02, 2017 at 02:30:37PM +0100, Marc Zyngier wrote:
>> We like living dangerously. Nothing explicitely forbids stack-protector
>> to be used in the EL2 code, while distributions routinely compile their
>> kernel with it. We're just lucky that no code actually triggers the
>> instrumentation.
>>
>> Let's not try our luck for much longer, and disable stack-protector
>> for code living at EL2.
>>
>> Cc: stable at vger.kernel.org
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>> arch/arm64/kvm/hyp/Makefile | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm64/kvm/hyp/Makefile b/arch/arm64/kvm/hyp/Makefile
>> index aaf42ae8d8c3..14c4e3b14bcb 100644
>> --- a/arch/arm64/kvm/hyp/Makefile
>> +++ b/arch/arm64/kvm/hyp/Makefile
>> @@ -2,6 +2,8 @@
>> # Makefile for Kernel-based Virtual Machine module, HYP part
>> #
>>
>> +ccflags-y += -fno-stack-protector
>> +
>
> While you are at it, should we have a -fpic here as well? The hyp code
> runs at a different location than the rest of the kernel.
We definitely should. I've just tried this, and this doesn't seem to
work very well. At least this seems to break our jump label
implementation. I need to page in that part of the code base and see
what happens.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2 1/9] dt-bindings: display: sun4i: Add component endpoint ID numbering scheme
From: Maxime Ripard @ 2017-05-02 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170428134841.cc5jrqhunh2rxhog@rob-hp-laptop>
Hi,
On Fri, Apr 28, 2017 at 08:48:41AM -0500, Rob Herring wrote:
> On Fri, Apr 21, 2017 at 04:38:49PM +0800, Chen-Yu Tsai wrote:
> > The Allwinner display pipeline contains many hardware components, some
> > of which can consume data from one of multiple upstream components.
> > The numbering scheme of these components must be encoded into the device
> > tree so the driver can figure out which component out of two or more of
> > the same type it is supposed to use or program.
> >
> > This patch adds the constraint that local endpoint IDs must be the index
> > or number of the remote endpoint's hardware block, for all components
> > in the display pipeline up to the TCONs.
> >
> > Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> > ---
> > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > index 57a8d0610062..7acdbf14ae1c 100644
> > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > @@ -4,6 +4,16 @@ Allwinner A10 Display Pipeline
> > The Allwinner A10 Display pipeline is composed of several components
> > that are going to be documented below:
> >
> > +For the input port of all components up to the TCON in the display
> > +pipeline, if there are multiple components, the local endpoint IDs
> > +must correspond to the index of the upstream block. For example, if
> > +the remote endpoint is Frontend 1, then the local endpoint ID must
> > +be 1.
> > +
> > +Conversely, for the output ports of the same group, the remote endpoint
> > +ID must be the index of the local hardware block. If the local backend
> > +is backend 1, then the remote endpoint ID must be 1.
>
> It would be clearer if you just explicitly listed IDs and their
> connections. From how this is worded, it would not work if you had
> connections like this:
>
> DevA 0
> DevA 1
> DevB 0
> DevB 1
>
> These would need to be endpoints 0-3 in TCON, and that doesn't reflect
> the remote devices' index.
Chen-Yu, can you send a patch to rephrase the doc that way?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170502/841b73a4/attachment-0001.sig>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox