* Tegra baseline test results for v4.8
From: Jon Hunter @ 2016-10-03 14:59 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic Tegra test results for Linux v4.8.
Logs and other details at:
https://nvtb.github.io//linux/test_v4.8/20161002170103/
Test summary
------------
Build: zImage:
Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig
Build: Image:
Pass: ( 1/ 1): defconfig
Boot to userspace: defconfig:
Pass: ( 4/ 4): qemu-vexpress64, tegra132-norrin,
tegra210-p2371-0000, tegra210-smaug
Boot to userspace: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
Boot to userspace: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
vmlinux object size
(delta in bytes from test_v4.8-rc8 (08895a8b6b06ed2323cd97a36ee40a116b3db8ed)):
text data bss total kernel
+4 0 0 +4 defconfig
+156 0 0 +156 multi_v7_defconfig
+220 0 0 +220 tegra_defconfig
Boot-time memory difference
(delta in bytes from test_v4.8-rc8 (08895a8b6b06ed2323cd97a36ee40a116b3db8ed))
avail rsrvd high freed board kconfig dtb
. . . . qemu-vexpress64 defconfig __internal
. . . . tegra114-dalmore-a04 multi_v7_defconfig tegra114-dalmore
. . . . tegra114-dalmore-a04 tegra_defconfig tegra114-dalmore
. . . . tegra124-jetson-tk1 multi_v7_defconfig tegra124-jetson-tk1
. . . . tegra124-jetson-tk1 tegra_defconfig tegra124-jetson-tk1
. . . . tegra124-nyan-big multi_v7_defconfig tegra124-nyan-big
. . . . tegra124-nyan-big tegra_defconfig tegra124-nyan-big
. . . . tegra132-norrin defconfig tegra132-norrin
. . . . tegra20-trimslice multi_v7_defconfig tegra20-trimslice
. . . . tegra20-trimslice tegra_defconfig tegra20-trimslice
. . . . tegra210-p2371-0000 defconfig tegra210-p2371-0000
. . . . tegra210-smaug defconfig tegra210-smaug
. . . . tegra30-beaver multi_v7_defconfig tegra30-beaver
. . . . tegra30-beaver tegra_defconfig tegra30-beaver
--
nvpublic
^ permalink raw reply
* [PATCH v2 0/2] Improve DMA chaining for ahash requests
From: Romain Perier @ 2016-10-03 15:17 UTC (permalink / raw)
To: linux-arm-kernel
This series contain performance improvement regarding ahash requests.
So far, ahash requests were systematically not chained at the DMA level.
However, in some case, like this is the case by using IPSec, some ahash
requests can be processed directly by the engine, and don't have
intermediaire partial update states.
This series firstly re-work the way outer IVs are copied from the SRAM
into the dma pool. To do so, we introduce a common dma pool for all type
of requests that contains outer results (like IV or digest). Then, for
ahash requests that can be processed directly by the engine, outer
results are copied from the SRAM into the common dma pool. These requests
are then allowed to be chained at the DMA level.
Benchmarking results with iperf throught IPSec
==============================================
ESP AH
Before 343 Mbits/s 492 Mbits/s
After 392 Mbits/s 557 Mbits/s
Improvement +14% +13%
Romain Perier (2):
crypto: marvell - Use an unique pool to copy results of requests
crypto: marvell - Don't break chain for computable last ahash requests
drivers/crypto/marvell/cesa.c | 4 ---
drivers/crypto/marvell/cesa.h | 5 ++-
drivers/crypto/marvell/cipher.c | 6 ++--
drivers/crypto/marvell/hash.c | 79 +++++++++++++++++++++++++++++++++--------
drivers/crypto/marvell/tdma.c | 17 +++++----
5 files changed, 78 insertions(+), 33 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH v2 1/2] crypto: marvell - Use an unique pool to copy results of requests
From: Romain Perier @ 2016-10-03 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161003151739.11615-1-romain.perier@free-electrons.com>
So far, we used a dedicated dma pool to copy the result of outer IV for
cipher requests. Instead of using a dma pool per outer data, we prefer
use the op dma pool that contains all part of the request from the SRAM.
Then, the outer data that is likely to be used by the 'complete'
operation, is copied later. In this way, any type of result can be
retrieved by DMA for cipher or ahash requests.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
Changes in v2:
- Use the dma pool "op" to retrieve outer data intead of introducing
a new one.
drivers/crypto/marvell/cesa.c | 4 ----
drivers/crypto/marvell/cesa.h | 5 ++---
drivers/crypto/marvell/cipher.c | 8 +++++---
drivers/crypto/marvell/tdma.c | 17 ++++++++---------
4 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 37dadb2..6e7a5c7 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -375,10 +375,6 @@ static int mv_cesa_dev_dma_init(struct mv_cesa_dev *cesa)
if (!dma->padding_pool)
return -ENOMEM;
- dma->iv_pool = dmam_pool_create("cesa_iv", dev, 16, 1, 0);
- if (!dma->iv_pool)
- return -ENOMEM;
-
cesa->dma = dma;
return 0;
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index e423d33..a768da7 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -277,7 +277,7 @@ struct mv_cesa_op_ctx {
#define CESA_TDMA_DUMMY 0
#define CESA_TDMA_DATA 1
#define CESA_TDMA_OP 2
-#define CESA_TDMA_IV 3
+#define CESA_TDMA_RESULT 3
/**
* struct mv_cesa_tdma_desc - TDMA descriptor
@@ -393,7 +393,6 @@ struct mv_cesa_dev_dma {
struct dma_pool *op_pool;
struct dma_pool *cache_pool;
struct dma_pool *padding_pool;
- struct dma_pool *iv_pool;
};
/**
@@ -839,7 +838,7 @@ mv_cesa_tdma_desc_iter_init(struct mv_cesa_tdma_chain *chain)
memset(chain, 0, sizeof(*chain));
}
-int mv_cesa_dma_add_iv_op(struct mv_cesa_tdma_chain *chain, dma_addr_t src,
+int mv_cesa_dma_add_result_op(struct mv_cesa_tdma_chain *chain, dma_addr_t src,
u32 size, u32 flags, gfp_t gfp_flags);
struct mv_cesa_op_ctx *mv_cesa_dma_add_op(struct mv_cesa_tdma_chain *chain,
diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
index d19dc96..098871a 100644
--- a/drivers/crypto/marvell/cipher.c
+++ b/drivers/crypto/marvell/cipher.c
@@ -212,7 +212,8 @@ mv_cesa_ablkcipher_complete(struct crypto_async_request *req)
struct mv_cesa_req *basereq;
basereq = &creq->base;
- memcpy(ablkreq->info, basereq->chain.last->data, ivsize);
+ memcpy(ablkreq->info, basereq->chain.last->op->ctx.blkcipher.iv,
+ ivsize);
} else {
memcpy_fromio(ablkreq->info,
engine->sram + CESA_SA_CRYPT_IV_SRAM_OFFSET,
@@ -373,8 +374,9 @@ static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
/* Add output data for IV */
ivsize = crypto_ablkcipher_ivsize(crypto_ablkcipher_reqtfm(req));
- ret = mv_cesa_dma_add_iv_op(&basereq->chain, CESA_SA_CRYPT_IV_SRAM_OFFSET,
- ivsize, CESA_TDMA_SRC_IN_SRAM, flags);
+ ret = mv_cesa_dma_add_result_op(&basereq->chain, CESA_SA_CFG_SRAM_OFFSET,
+ CESA_SA_DATA_SRAM_OFFSET,
+ CESA_TDMA_SRC_IN_SRAM, flags);
if (ret)
goto err_free_tdma;
diff --git a/drivers/crypto/marvell/tdma.c b/drivers/crypto/marvell/tdma.c
index 9fd7a5f..2e15f19 100644
--- a/drivers/crypto/marvell/tdma.c
+++ b/drivers/crypto/marvell/tdma.c
@@ -69,8 +69,8 @@ void mv_cesa_dma_cleanup(struct mv_cesa_req *dreq)
if (type == CESA_TDMA_OP)
dma_pool_free(cesa_dev->dma->op_pool, tdma->op,
le32_to_cpu(tdma->src));
- else if (type == CESA_TDMA_IV)
- dma_pool_free(cesa_dev->dma->iv_pool, tdma->data,
+ else if (type == CESA_TDMA_RESULT)
+ dma_pool_free(cesa_dev->dma->op_pool, tdma->op,
le32_to_cpu(tdma->dst));
tdma = tdma->next;
@@ -209,29 +209,28 @@ mv_cesa_dma_add_desc(struct mv_cesa_tdma_chain *chain, gfp_t flags)
return new_tdma;
}
-int mv_cesa_dma_add_iv_op(struct mv_cesa_tdma_chain *chain, dma_addr_t src,
+int mv_cesa_dma_add_result_op(struct mv_cesa_tdma_chain *chain, dma_addr_t src,
u32 size, u32 flags, gfp_t gfp_flags)
{
-
struct mv_cesa_tdma_desc *tdma;
- u8 *iv;
+ struct mv_cesa_op_ctx *result;
dma_addr_t dma_handle;
tdma = mv_cesa_dma_add_desc(chain, gfp_flags);
if (IS_ERR(tdma))
return PTR_ERR(tdma);
- iv = dma_pool_alloc(cesa_dev->dma->iv_pool, gfp_flags, &dma_handle);
- if (!iv)
+ result = dma_pool_alloc(cesa_dev->dma->op_pool, gfp_flags, &dma_handle);
+ if (!result)
return -ENOMEM;
tdma->byte_cnt = cpu_to_le32(size | BIT(31));
tdma->src = src;
tdma->dst = cpu_to_le32(dma_handle);
- tdma->data = iv;
+ tdma->op = result;
flags &= (CESA_TDMA_DST_IN_SRAM | CESA_TDMA_SRC_IN_SRAM);
- tdma->flags = flags | CESA_TDMA_IV;
+ tdma->flags = flags | CESA_TDMA_RESULT;
return 0;
}
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/2] crypto: marvell - Don't break chain for computable last ahash requests
From: Romain Perier @ 2016-10-03 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161003151739.11615-1-romain.perier@free-electrons.com>
Currently, the driver breaks chain for all kind of hash requests in order to
don't override intermediate states of partial ahash updates. However, some final
ahash requests can be directly processed by the engine, and so without
intermediate state. This is typically the case for most for the HMAC requests
processed via IPSec.
This commits adds a TDMA descriptor to copy outer data for these of requests
into the "op" dma pool, then it allow to chain these requests at the DMA level.
The 'complete' operation is also updated to retrieve the MAC digest from the
right location.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
Changes in v2:
- Replaced BUG_ON by an error
- Add a variable "break_chain", with "type" to break the chain
with ahash requests. It improves code readability.
drivers/crypto/marvell/cipher.c | 10 +++---
drivers/crypto/marvell/hash.c | 79 +++++++++++++++++++++++++++++++++--------
drivers/crypto/marvell/tdma.c | 4 +--
3 files changed, 71 insertions(+), 22 deletions(-)
diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
index 098871a..8bc52bf 100644
--- a/drivers/crypto/marvell/cipher.c
+++ b/drivers/crypto/marvell/cipher.c
@@ -212,8 +212,7 @@ mv_cesa_ablkcipher_complete(struct crypto_async_request *req)
struct mv_cesa_req *basereq;
basereq = &creq->base;
- memcpy(ablkreq->info, basereq->chain.last->op->ctx.blkcipher.iv,
- ivsize);
+ memcpy(ablkreq->info, basereq->chain.last->data, ivsize);
} else {
memcpy_fromio(ablkreq->info,
engine->sram + CESA_SA_CRYPT_IV_SRAM_OFFSET,
@@ -374,9 +373,10 @@ static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
/* Add output data for IV */
ivsize = crypto_ablkcipher_ivsize(crypto_ablkcipher_reqtfm(req));
- ret = mv_cesa_dma_add_result_op(&basereq->chain, CESA_SA_CFG_SRAM_OFFSET,
- CESA_SA_DATA_SRAM_OFFSET,
- CESA_TDMA_SRC_IN_SRAM, flags);
+ ret = mv_cesa_dma_add_result_op(&basereq->chain,
+ CESA_SA_CRYPT_IV_SRAM_OFFSET,
+ ivsize,
+ CESA_TDMA_SRC_IN_SRAM, flags);
if (ret)
goto err_free_tdma;
diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index 9f28468..35baf4f 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -312,24 +312,53 @@ static void mv_cesa_ahash_complete(struct crypto_async_request *req)
int i;
digsize = crypto_ahash_digestsize(crypto_ahash_reqtfm(ahashreq));
- for (i = 0; i < digsize / 4; i++)
- creq->state[i] = readl_relaxed(engine->regs + CESA_IVDIG(i));
- if (creq->last_req) {
+ if (mv_cesa_req_get_type(&creq->base) == CESA_DMA_REQ &&
+ !(creq->base.chain.last->flags & CESA_TDMA_BREAK_CHAIN)) {
+ struct mv_cesa_tdma_desc *tdma = NULL;
+ __le32 *data = NULL;
+
+ for (tdma = creq->base.chain.first; tdma; tdma = tdma->next) {
+ u32 type = tdma->flags & CESA_TDMA_TYPE_MSK;
+ if (type == CESA_TDMA_RESULT)
+ break;
+ }
+
+ if (!tdma) {
+ dev_err(cesa_dev->dev, "Failed to retrieve tdma "
+ "descriptor for outer data\n");
+ return;
+ }
+
/*
- * Hardware's MD5 digest is in little endian format, but
- * SHA in big endian format
+ * Result is already in the correct endianess when the SA is
+ * used
*/
- if (creq->algo_le) {
- __le32 *result = (void *)ahashreq->result;
+ data = tdma->data;
+ for (i = 0; i < digsize / 4; i++)
+ creq->state[i] = cpu_to_le32(data[i]);
- for (i = 0; i < digsize / 4; i++)
- result[i] = cpu_to_le32(creq->state[i]);
- } else {
- __be32 *result = (void *)ahashreq->result;
+ memcpy(ahashreq->result, data, digsize);
+ } else {
+ for (i = 0; i < digsize / 4; i++)
+ creq->state[i] = readl_relaxed(engine->regs +
+ CESA_IVDIG(i));
+ if (creq->last_req) {
+ /*
+ * Hardware's MD5 digest is in little endian format, but
+ * SHA in big endian format
+ */
+ if (creq->algo_le) {
+ __le32 *result = (void *)ahashreq->result;
+
+ for (i = 0; i < digsize / 4; i++)
+ result[i] = cpu_to_le32(creq->state[i]);
+ } else {
+ __be32 *result = (void *)ahashreq->result;
- for (i = 0; i < digsize / 4; i++)
- result[i] = cpu_to_be32(creq->state[i]);
+ for (i = 0; i < digsize / 4; i++)
+ result[i] = cpu_to_be32(creq->state[i]);
+ }
}
}
@@ -504,6 +533,12 @@ mv_cesa_ahash_dma_last_req(struct mv_cesa_tdma_chain *chain,
CESA_SA_DESC_CFG_LAST_FRAG,
CESA_SA_DESC_CFG_FRAG_MSK);
+ ret = mv_cesa_dma_add_result_op(chain,
+ CESA_SA_MAC_DIG_SRAM_OFFSET,
+ 32,
+ CESA_TDMA_SRC_IN_SRAM, flags);
+ if (ret)
+ return ERR_PTR(-ENOMEM);
return op;
}
@@ -564,6 +599,8 @@ static int mv_cesa_ahash_dma_req_init(struct ahash_request *req)
struct mv_cesa_op_ctx *op = NULL;
unsigned int frag_len;
int ret;
+ u32 type;
+ bool break_chain = true;
basereq->chain.first = NULL;
basereq->chain.last = NULL;
@@ -635,6 +672,16 @@ static int mv_cesa_ahash_dma_req_init(struct ahash_request *req)
goto err_free_tdma;
}
+ /*
+ * If results are copied via DMA, this means that this
+ * request can be directly processed by the engine,
+ * without partial updates. So we can chain it at the
+ * DMA level with other requests.
+ */
+ type = basereq->chain.last->flags & CESA_TDMA_TYPE_MSK;
+ if (type == CESA_TDMA_RESULT)
+ break_chain = false;
+
if (op) {
/* Add dummy desc to wait for crypto operation end */
ret = mv_cesa_dma_add_dummy_end(&basereq->chain, flags);
@@ -648,8 +695,10 @@ static int mv_cesa_ahash_dma_req_init(struct ahash_request *req)
else
creq->cache_ptr = 0;
- basereq->chain.last->flags |= (CESA_TDMA_END_OF_REQ |
- CESA_TDMA_BREAK_CHAIN);
+ basereq->chain.last->flags |= CESA_TDMA_END_OF_REQ;
+
+ if (break_chain)
+ basereq->chain.last->flags |= CESA_TDMA_BREAK_CHAIN;
return 0;
diff --git a/drivers/crypto/marvell/tdma.c b/drivers/crypto/marvell/tdma.c
index 2e15f19..8d33003 100644
--- a/drivers/crypto/marvell/tdma.c
+++ b/drivers/crypto/marvell/tdma.c
@@ -70,7 +70,7 @@ void mv_cesa_dma_cleanup(struct mv_cesa_req *dreq)
dma_pool_free(cesa_dev->dma->op_pool, tdma->op,
le32_to_cpu(tdma->src));
else if (type == CESA_TDMA_RESULT)
- dma_pool_free(cesa_dev->dma->op_pool, tdma->op,
+ dma_pool_free(cesa_dev->dma->op_pool, tdma->data,
le32_to_cpu(tdma->dst));
tdma = tdma->next;
@@ -227,7 +227,7 @@ int mv_cesa_dma_add_result_op(struct mv_cesa_tdma_chain *chain, dma_addr_t src,
tdma->byte_cnt = cpu_to_le32(size | BIT(31));
tdma->src = src;
tdma->dst = cpu_to_le32(dma_handle);
- tdma->op = result;
+ tdma->data = result;
flags &= (CESA_TDMA_DST_IN_SRAM | CESA_TDMA_SRC_IN_SRAM);
tdma->flags = flags | CESA_TDMA_RESULT;
--
2.9.3
^ permalink raw reply related
* [PATCH v6 1/6] of: Add vendor prefix for Engicam s.r.l company
From: Rob Herring @ 2016-10-03 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474917937-29336-1-git-send-email-jteki@openedev.com>
On Mon, Sep 26, 2016 at 2:25 PM, Jagan Teki <jteki@openedev.com> wrote:
> From: Jagan Teki <jagan@amarulasolutions.com>
>
> Engicam providing design services of electronic systems with
> high content of technology, relying on a long experience in
> electronic design.
>
> For more info visit
> http://www.engicam.com/en/
>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Matteo Lisi <matteo.lisi@engicam.com>
> Cc: Michael Trimarchi <michael@amarulasolutions.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
I've applied this patch to the DT tree to avoid any conflicts with
sorting vendor-prefixes.txt.
Rob
^ permalink raw reply
* [PATCH v6 1/6] of: Add vendor prefix for Engicam s.r.l company
From: Jagan Teki @ 2016-10-03 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqL9ewVsWL1HUtPuMHvcSP+nW=d=F3++ibLhOF64xz8YwQ@mail.gmail.com>
On Mon, Oct 3, 2016 at 9:06 PM, Rob Herring <robh@kernel.org> wrote:
> On Mon, Sep 26, 2016 at 2:25 PM, Jagan Teki <jteki@openedev.com> wrote:
>> From: Jagan Teki <jagan@amarulasolutions.com>
>>
>> Engicam providing design services of electronic systems with
>> high content of technology, relying on a long experience in
>> electronic design.
>>
>> For more info visit
>> http://www.engicam.com/en/
>>
>> Cc: Sascha Hauer <kernel@pengutronix.de>
>> Cc: Fabio Estevam <fabio.estevam@nxp.com>
>> Cc: Shawn Guo <shawnguo@kernel.org>
>> Cc: Matteo Lisi <matteo.lisi@engicam.com>
>> Cc: Michael Trimarchi <michael@amarulasolutions.com>
>> Acked-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>
> I've applied this patch to the DT tree to avoid any conflicts with
> sorting vendor-prefixes.txt.
Thanks.
Shawn - can you pick this series.
thanks!
--
Jagan Teki
Free Software Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply
* [PATCH v3] drm: tilcdc: add a da850-specific compatible string
From: Bartosz Golaszewski @ 2016-10-03 15:45 UTC (permalink / raw)
To: linux-arm-kernel
Due to some potential tweaks for the da850 LCDC (for example: the
required memory bandwith settings) we need a separate compatible
for the IP present on the da850 boards.
Suggested-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
v1 -> v2:
- added the new compatible to the bindings documentation
v2 -> v3:
- made the documentation more detailed
Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt | 6 ++++--
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
index a83abd7..6fddb4f 100644
--- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
@@ -1,7 +1,9 @@
Device-Tree bindings for tilcdc DRM driver
Required properties:
- - compatible: value should be "ti,am33xx-tilcdc".
+ - compatible: value should be one of the following:
+ - "ti,am33xx-tilcdc" for AM335x based boards
+ - "ti,da850-tilcdc" for DA850/AM18x/OMAP-L138 based boards
- interrupts: the interrupt number
- reg: base address and size of the LCDC device
@@ -51,7 +53,7 @@ Optional nodes:
Example:
fb: fb at 4830e000 {
- compatible = "ti,am33xx-tilcdc";
+ compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
reg = <0x4830e000 0x1000>;
interrupt-parent = <&intc>;
interrupts = <36>;
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index a694977..231f2c7 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -723,6 +723,7 @@ static int tilcdc_pdev_remove(struct platform_device *pdev)
static struct of_device_id tilcdc_of_match[] = {
{ .compatible = "ti,am33xx-tilcdc", },
+ { .compatible = "ti,da850-tilcdc", },
{ },
};
MODULE_DEVICE_TABLE(of, tilcdc_of_match);
--
2.9.3
^ permalink raw reply related
* [PATCH v2] drm: tilcdc: add a da850-specific compatible string
From: Bartosz Golaszewski @ 2016-10-03 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <12dad169-de04-ce7d-0422-94c57074c839@ti.com>
2016-10-01 11:30 GMT+02:00 Sekhar Nori <nsekhar@ti.com>:
> On Friday 30 September 2016 07:22 PM, Bartosz Golaszewski wrote:
>> Due to some potential tweaks for the da850 LCDC (for example: the
>> required memory bandwith settings) we need a separate compatible
>> for the IP present on the da850 boards.
>>
>
> This documentation does not help much :( It should be on the lines of:
>
> compatible: value should be "ti,am33xx-tilcdc" for AM335x based boards
> value should be "ti,da850-tilcdc" for DA850/AM18x/OMAP-L138
> based boards
>
> There are many existing examples of the way compatible strings are
> documented. You can take a look at them too. Also, since you are
> introducing a new device-tree compatible, please keep the devicetree
> list and maintainers in CC too. I don't think it shows up in
> get_maintainer.pl, so you will have to remember to do it.
>
Hi Sekhar,
sorry for that, hope v3 is good.
Thanks,
Bartosz
^ permalink raw reply
* [PATCH v2 0/2] Improve DMA chaining for ahash requests
From: Romain Perier @ 2016-10-03 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161003151739.11615-1-romain.perier@free-electrons.com>
Hello,
Le 03/10/2016 17:17, Romain Perier a ?crit :
> This series contain performance improvement regarding ahash requests.
> So far, ahash requests were systematically not chained at the DMA level.
> However, in some case, like this is the case by using IPSec, some ahash
> requests can be processed directly by the engine, and don't have
> intermediaire partial update states.
>
> This series firstly re-work the way outer IVs are copied from the SRAM
> into the dma pool. To do so, we introduce a common dma pool for all type
> of requests that contains outer results (like IV or digest). Then, for
> ahash requests that can be processed directly by the engine, outer
> results are copied from the SRAM into the common dma pool. These requests
> are then allowed to be chained at the DMA level.
>
>
> Benchmarking results with iperf throught IPSec
> ==============================================
> ESP AH
>
> Before 343 Mbits/s 492 Mbits/s
> After 392 Mbits/s 557 Mbits/s
> Improvement +14% +13%
>
> Romain Perier (2):
> crypto: marvell - Use an unique pool to copy results of requests
> crypto: marvell - Don't break chain for computable last ahash requests
>
> drivers/crypto/marvell/cesa.c | 4 ---
> drivers/crypto/marvell/cesa.h | 5 ++-
> drivers/crypto/marvell/cipher.c | 6 ++--
> drivers/crypto/marvell/hash.c | 79 +++++++++++++++++++++++++++++++++--------
> drivers/crypto/marvell/tdma.c | 17 +++++----
> 5 files changed, 78 insertions(+), 33 deletions(-)
>
After an internal discussion, we can handle things differently. Instead
of allocating a new mv_cesa_op_ctx in the op_pool, we can just allocate
a new descriptor which points to the first op ctx of the chain, and then
copy outer data.
Please ignore this series.
Regards,
--
Romain Perier, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] drm/sun4i: Check that the plane coordinates are not negative
From: Boris Brezillon @ 2016-10-03 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161003125811.GH5228@lukather>
On Mon, 3 Oct 2016 14:58:11 +0200
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> Hi Boris,
>
> On Fri, Sep 30, 2016 at 06:08:26PM +0200, Boris Brezillon wrote:
> > On Fri, 30 Sep 2016 16:33:20 +0200
> > Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> >
> > > Our planes cannot be set at negative coordinates. Make sure we reject such
> > > configuration.
> > >
> > > Reported-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > > ---
> > > drivers/gpu/drm/sun4i/sun4i_layer.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c b/drivers/gpu/drm/sun4i/sun4i_layer.c
> > > index f0035bf5efea..f5463c4c2cde 100644
> > > --- a/drivers/gpu/drm/sun4i/sun4i_layer.c
> > > +++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
> > > @@ -29,6 +29,9 @@ struct sun4i_plane_desc {
> > > static int sun4i_backend_layer_atomic_check(struct drm_plane *plane,
> > > struct drm_plane_state *state)
> > > {
> > > + if ((state->crtc_x < 0) || (state->crtc_y < 0))
> > > + return -EINVAL;
> > > +
> >
> > Hm, I think it's a perfectly valid use case from the DRM framework and
> > DRM user PoV: you may want to place your plane at a negative CRTC
> > offset (which means part of the plane will be hidden).
> >
> > Maybe I'm wrong, but it seems you can support that by adapting the
> > start address of your framebuffer pointer and the layer size.
>
> Indeed, that would probably work. This is even somewhat what we've
> been using to implement the VGA hack we use on the CHIP.
>
> Can you send that patch?
Actually, Ville suggested a slightly different approach: use the
->src and ->dst in drm_plane_state.
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: add bindings doc for ZTE VOU display controller
From: Rob Herring @ 2016-10-03 17:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474727185-24180-2-git-send-email-shawn.guo@linaro.org>
On Sat, Sep 24, 2016 at 10:26:24PM +0800, Shawn Guo wrote:
> It adds initial bindings doc for ZTE VOU display controller. HDMI is
> the only supported output device right now.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
> .../devicetree/bindings/display/zte,vou.txt | 86 ++++++++++++++++++++++
> 1 file changed, 86 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/zte,vou.txt
>
> diff --git a/Documentation/devicetree/bindings/display/zte,vou.txt b/Documentation/devicetree/bindings/display/zte,vou.txt
> new file mode 100644
> index 000000000000..d03ba4c4810c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/zte,vou.txt
> @@ -0,0 +1,86 @@
> +ZTE VOU Display Controller
> +
> +This is a display controller found on ZTE ZX296718 SoC. It includes multiple
> +Graphic Layer (GL) and Video Layer (VL), two Mixers/Channels, and a few blocks
> +handling scaling, color space conversion etc. VOU also integrates the support
> +for typical output devices, like HDMI, TV Encoder, VGA, and RGB LCD.
> +
> +* Master VOU node
> +
> +It must be the parent node of all the sub-device nodes.
> +
> +Required properties:
> + - compatible: should be "zte,zx296718-vou"
> + - #address-cells: should be <1>
> + - #size-cells: should be <1>
> + - reg: Physical base address and length of the whole VOU IO region
> + - ranges: to allow probing of sub-devices
> +
> +* VOU DPC device
> +
> +Required properties:
> + - compatible: should be "zte,zx296718-dpc"
> + - reg: Physical base address and length of DPC register regions, one for each
> + entry in 'reg-names'
> + - reg-names: The names of register regions. The following regions are required:
> + "osd"
> + "timing_ctrl"
> + "dtrc"
> + "vou_ctrl"
> + "otfppu"
> + - interrupts: VOU DPC interrupt number to CPU
> + - clocks: A list of phandle + clock-specifier pairs, one for each entry
> + in 'clock-names'
> + - clock-names: A list of clock names. The following clocks are required:
> + "aclk"
> + "ppu_wclk"
> + "main_wclk"
> + "aux_wclk"
> +
> +* HDMI output device
> +
> +Required properties:
> + - compatible: should be "zte,zx296718-hdmi"
> + - reg: Physical base address and length of the HDMI device IO region
> + - interrupts : HDMI interrupt number to CPU
> + - clocks: A list of phandle + clock-specifier pairs, one for each entry
> + in 'clock-names'
> + - clock-names: A list of clock names. The following clocks are required:
> + "osc_cec"
> + "osc_clk"
> + "xclk"
> +
> +Example:
> +
> +vou: vou at 1440000 {
> + compatible = "zte,zx296718-vou";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x1440000 0x10000>;
> + ranges;
You still have overlapping addresses. Explicitly list the sub ranges in
reg here used by the VOU driver if the driver usage doesn't overlap. If
there is overlap (2 drivers accessing the same range), then you need
some APIs between the components (or possibly regmap).
Also, don't do an empty ranges here. Fill it in so the child nodes are
just offsets of 0x1440000
> +
> + dpc: dpc at 1440000 {
> + compatible = "zte,zx296718-dpc";
> + reg = <0x1440000 0x1000>, <0x1441000 0x1000>,
> + <0x1445000 0x1000>, <0x1446000 0x1000>,
> + <0x144a000 0x1000>;
> + reg-names = "osd", "timing_ctrl",
> + "dtrc", "vou_ctrl",
> + "otfppu";
> + interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&topcrm VOU_ACLK>, <&topcrm VOU_PPU_WCLK>,
> + <&topcrm VOU_MAIN_WCLK>, <&topcrm VOU_AUX_WCLK>;
> + clock-names = "aclk", "ppu_wclk",
> + "main_wclk", "aux_wclk";
> + };
> +
> + hdmi: hdmi at 144c000 {
> + compatible = "zte,zx296718-hdmi";
> + reg = <0x144c000 0x4000>;
> + interrupts = <GIC_SPI 82 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&topcrm HDMI_OSC_CEC>,
> + <&topcrm HDMI_OSC_CLK>,
> + <&topcrm HDMI_XCLK>;
> + clock-names = "osc_cec", "osc_clk", "xclk";
> + };
> +};
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH v1 1/2] ARM: dts: vfxxx: Enable DMA for DSPI on Vybrid
From: Stefan Agner @ 2016-10-03 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <63fc108e2df00d2297a9b7014955f203bc802f34.1475498805.git.maitysanchayan@gmail.com>
On 2016-10-03 05:50, Sanchayan Maity wrote:
> Enable DMA for DSPI on Vybrid.
Hm, we have that in 4.4 already, is that meant for 4.1?
>
> Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
> ---
> arch/arm/boot/dts/vf-colibri.dtsi | 4 ++++
> arch/arm/boot/dts/vfxxx.dtsi | 6 ++++++
> 2 files changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/vf-colibri.dtsi
> b/arch/arm/boot/dts/vf-colibri.dtsi
> index b741709..21bfef9 100644
> --- a/arch/arm/boot/dts/vf-colibri.dtsi
> +++ b/arch/arm/boot/dts/vf-colibri.dtsi
> @@ -108,6 +108,10 @@
> status = "okay";
> };
>
> +&edma1 {
> + status = "okay";
> +};
> +
> &esdhc1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_esdhc1>;
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index 2c13ec6..eac4213 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -194,6 +194,9 @@
> clocks = <&clks VF610_CLK_DSPI0>;
> clock-names = "dspi";
> spi-num-chipselects = <6>;
> + dmas = <&edma1 1 12>,
> + <&edma1 1 13>;
> + dma-names = "rx", "tx";
> status = "disabled";
> };
>
> @@ -206,6 +209,9 @@
> clocks = <&clks VF610_CLK_DSPI1>;
> clock-names = "dspi";
> spi-num-chipselects = <4>;
> + dmas = <&edma1 1 14>,
> + <&edma1 1 15>;
> + dma-names = "rx", "tx";
> status = "disabled";
> };
^ permalink raw reply
* [PATCH v5] devicetree: bindings: uart: Add new compatible string for ZynqMP
From: Rob Herring @ 2016-10-03 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474898801-36571-1-git-send-email-navam@xilinx.com>
On Mon, Sep 26, 2016 at 07:36:41PM +0530, Nava kishore Manne wrote:
> From: Nava kishore Manne <nava.manne@xilinx.com>
>
> This patch Adds the new compatible string for ZynqMP SoC.
>
> Signed-off-by: Nava kishore Manne <navam@xilinx.com>
> ---
> Changes for v5:
> -Fixed some minor comments.
Not a useful changelog. The point of these comments is to remind the
reviewers of what they commented on.
> Changes for v4:
> -Modified the ChangeLog comment.
> Changes for v3:
> -Added changeLog comment.
> Changes for v2:
> -None
>
> Documentation/devicetree/bindings/serial/cdns,uart.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.txt b/Documentation/devicetree/bindings/serial/cdns,uart.txt
> index a3eb154..30c885c 100644
> --- a/Documentation/devicetree/bindings/serial/cdns,uart.txt
> +++ b/Documentation/devicetree/bindings/serial/cdns,uart.txt
> @@ -1,7 +1,9 @@
> Binding for Cadence UART Controller
>
> Required properties:
> -- compatible : should be "cdns,uart-r1p8", or "xlnx,xuartps"
> +- compatible :
> + Use "cdns,uart-r1p8", or "xlnx,xuartps" for Zynq-7xxx SoC.
This is still not right. It was wrong before, but you are touching it so
make it right.
OR doesn't match the dts files. It is AND and the opposite order.
xlnx,xuartps wasn't the best naming, but it's in use so we'll have to
live with it for zynq-7xxx.
> + Use "cdns,uart-r1p12" for Zynq Ultrascale+ MPSoC.
What I meant here was this should have something like "xlnx,mpsoc-uart"
as the first compatible with "cdns,uart-r1p12" as the second. Not sure
if "mpsoc" is the best name here.
Rob
^ permalink raw reply
* [PATCH 0/4] staging: Fix build of VCHIQ driver.
From: Eric Anholt @ 2016-10-03 18:52 UTC (permalink / raw)
To: linux-arm-kernel
This is a series of fixes for the vchiq driver that Greg recently
added to his staging-testing branch.
A full tree with nasty patches to add the other drivers necessary to
do "vcdbg log msg" is available at:
https://github.com/anholt/linux/tree/vchiq
Eric Anholt (4):
staging/vchi: Convert to current get_user_pages() arguments.
staging/vchi: Update for rename of page_cache_release() to put_page().
ARM: bcm2835: Add #define for VCHIQ property message.
drivers/vchi: Remove dependency on CONFIG_BROKEN.
drivers/staging/vc04_services/Kconfig | 2 +-
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 6 +++---
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 5 ++---
include/soc/bcm2835/raspberrypi-firmware.h | 2 ++
4 files changed, 8 insertions(+), 7 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH 1/4] staging/vchi: Convert to current get_user_pages() arguments.
From: Eric Anholt @ 2016-10-03 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161003185209.27733-1-eric@anholt.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
---
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 2 +-
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index c29040fdf9a7..18f268ee6d4b 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -420,7 +420,7 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
*need_release = 0; /* do not try and release vmalloc pages */
} else {
down_read(&task->mm->mmap_sem);
- actual_pages = get_user_pages(task, task->mm,
+ actual_pages = get_user_pages(
(unsigned long)buf & ~(PAGE_SIZE - 1),
num_pages,
(type == PAGELIST_READ) /*Write */ ,
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index e11c0e07471b..56c2c48f6801 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -1473,8 +1473,7 @@ dump_phys_mem(void *virt_addr, uint32_t num_bytes)
}
down_read(¤t->mm->mmap_sem);
- rc = get_user_pages(current, /* task */
- current->mm, /* mm */
+ rc = get_user_pages(
(unsigned long)virt_addr, /* start */
num_pages, /* len */
0, /* write */
--
2.9.3
^ permalink raw reply related
* [PATCH 2/4] staging/vchi: Update for rename of page_cache_release() to put_page().
From: Eric Anholt @ 2016-10-03 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161003185209.27733-1-eric@anholt.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
---
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 4 ++--
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index 18f268ee6d4b..4cb5bff23728 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -439,7 +439,7 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
while (actual_pages > 0)
{
actual_pages--;
- page_cache_release(pages[actual_pages]);
+ put_page(pages[actual_pages]);
}
kfree(pagelist);
if (actual_pages == 0)
@@ -578,7 +578,7 @@ free_pagelist(PAGELIST_T *pagelist, int actual)
offset = 0;
set_page_dirty(pg);
}
- page_cache_release(pg);
+ put_page(pg);
}
}
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 56c2c48f6801..47df1af2219d 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -1512,7 +1512,7 @@ dump_phys_mem(void *virt_addr, uint32_t num_bytes)
kunmap(page);
for (page_idx = 0; page_idx < num_pages; page_idx++)
- page_cache_release(pages[page_idx]);
+ put_page(pages[page_idx]);
kfree(pages);
}
--
2.9.3
^ permalink raw reply related
* [PATCH 3/4] ARM: bcm2835: Add #define for VCHIQ property message.
From: Eric Anholt @ 2016-10-03 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161003185209.27733-1-eric@anholt.net>
This comes from the downstream tree and is needed for the new VCHIQ
driver in staging.
Signed-off-by: Eric Anholt <eric@anholt.net>
---
include/soc/bcm2835/raspberrypi-firmware.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index 3fb357193f09..a06baffdf580 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -109,6 +109,8 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_FRAMEBUFFER_SET_OVERSCAN = 0x0004800a,
RPI_FIRMWARE_FRAMEBUFFER_SET_PALETTE = 0x0004800b,
+ RPI_FIRMWARE_VCHIQ_INIT = 0x00048010,
+
RPI_FIRMWARE_GET_COMMAND_LINE = 0x00050001,
RPI_FIRMWARE_GET_DMA_CHANNELS = 0x00060001,
};
--
2.9.3
^ permalink raw reply related
* [PATCH 4/4] drivers/vchi: Remove dependency on CONFIG_BROKEN.
From: Eric Anholt @ 2016-10-03 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161003185209.27733-1-eric@anholt.net>
The driver builds now.
Signed-off-by: Eric Anholt <eric@anholt.net>
---
drivers/staging/vc04_services/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vc04_services/Kconfig b/drivers/staging/vc04_services/Kconfig
index 9676fb29075a..db8e1beb89f9 100644
--- a/drivers/staging/vc04_services/Kconfig
+++ b/drivers/staging/vc04_services/Kconfig
@@ -1,6 +1,6 @@
config BCM2708_VCHIQ
tristate "Videocore VCHIQ"
- depends on RASPBERRYPI_FIRMWARE && BROKEN
+ depends on RASPBERRYPI_FIRMWARE
default y
help
Kernel to VideoCore communication interface for the
--
2.9.3
^ permalink raw reply related
* [PATCH 4/8] pinctrl: aspeed-g5: Fix pin association of SPI1 function
From: Rob Herring @ 2016-10-03 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bdd34f8c4bfabbc1d3cd05a66ac8734da514b1e5.1474986045.git-series.andrew@aj.id.au>
On Wed, Sep 28, 2016 at 12:20:16AM +0930, Andrew Jeffery wrote:
> The SPI1 function was associated with the wrong pins: The functions that
> those pins provide is either an SPI debug or passthrough function
> coupled to SPI1. Make the SPI1 mux function configure the relevant pins
> and associate new SPI1DEBUG and SPI1PASSTHRU functions with the pins
> that were already defined.
>
> The notation used in the datasheet's multi-function pin table for the SoC is
> often creative: in this case the SYS* signals are enabled by a single bit,
> which is nothing unusual on its own, but in this case the bit was also
> participating in a multi-bit bitfield and therefore represented multiple
> functions. This fact was overlooked in the original patch.
>
> Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver)
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 4 +-
Acked-by: Rob Herring <robh@kernel.org>
> drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 86 ++++++-
> 2 files changed, 81 insertions(+), 9 deletions(-)
^ permalink raw reply
* [PATCH v3 2/7] i2c: bcm2835: Protect against unexpected TXW/RXR interrupts
From: Eric Anholt @ 2016-10-03 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0c943ee9-d152-79c4-2ad7-8a88c2d9c960@tronnes.org>
Noralf Tr?nnes <noralf@tronnes.org> writes:
> Den 29.09.2016 07:37, skrev Stefan Wahren:
>>> Noralf Tr?nnes <noralf@tronnes.org> hat am 29. September 2016 um 00:22
>>> geschrieben:
>>>
>>>
>>>
>>> Den 29.09.2016 00:00, skrev Eric Anholt:
>>>> Noralf Tr?nnes <noralf@tronnes.org> writes:
>>>>
>>>>> If an unexpected TXW or RXR interrupt occurs (msg_buf_remaining == 0),
>>>>> the driver has no way to fill/drain the FIFO to stop the interrupts.
>>>>> In this case the controller has to be disabled and the transfer
>>>>> completed to avoid hang.
>>>>>
>>>>> (CLKT | ERR) and DONE interrupts are completed in their own paths, and
>>>>> the controller is disabled in the transfer function after completion.
>>>>> Unite the code paths and do disabling inside the interrupt routine.
>>>>>
>>>>> Clear interrupt status bits in the united completion path instead of
>>>>> trying to do it on every interrupt which isn't necessary.
>>>>> Only CLKT, ERR and DONE can be cleared that way.
>>>>>
>>>>> Add the status value to the error value in case of TXW/RXR errors to
>>>>> distinguish them from the other S_LEN error.
>>>> I was surprised that not writing the TXW/RXR bits on handling their
>>>> interrupts was OK, given that we were doing so before, but it's a level
>>>> interrupt and those bits are basically ignored on write.
>>>>
>>>> This patch and 3, 4, and 6 are:
>>>>
>>>> Reviewed-by: Eric Anholt <eric@anholt.net>
>>>>
>>>> Patch 5 is:
>>>>
>>>> Acked-by: Eric Anholt <eric@anholt.net>
>>>>
>>>> Note for future debug: The I2C_C_CLEAR on errors will take some time to
>>>> resolve -- if you were in non-idle state and I2C_C_READ, it sets an
>>>> abort_rx flag and runs through the state machine to send a NACK and a
>>>> STOP, I think. Since we're setting CLEAR without I2CEN, that NACK will
>>>> be hanging around queued up for next time we start the engine.
>>> Maybe you're able to explain the issues I had with reset:
>>> https://github.com/raspberrypi/linux/issues/1653
>>>
>>> Should we put your note into the commit message?
>>> It will most likely be lost if it just stays in this email.
>> I prefer to have this kind of information as a code comment.
>
> Eric, does this look good to you as a code comment:
>
> /*
> * Note about I2C_C_CLEAR on error:
> * The I2C_C_CLEAR on errors will take some time to resolve -- if you
> were in
> * non-idle state and I2C_C_READ, it sets an abort_rx flag and runs through
> * the state machine to send a NACK and a STOP. Since we're setting CLEAR
> * without I2CEN, that NACK will be hanging around queued up for next time
> * we start the engine.
> */
>
>
> If it is, I'll resend the series with this change and add all the ack's
> and r-b's.
Looks good to me. Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161003/29b87d31/attachment.sig>
^ permalink raw reply
* [PATCH] bus: qcom-ebi2: depend on HAS_IOMEM
From: Stephen Boyd @ 2016-10-03 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475445239-25006-1-git-send-email-linus.walleij@linaro.org>
On 10/02/2016 02:53 PM, Linus Walleij wrote:
> After being asked to not depend on ARCH_QCOM* or similar,
> unsurprisingly compilation fails on UM as it has no I/O
> memory:
We could have depends on ARCH_QCOM || COMPILE_TEST and then life is
good. The HAS_IOMEM would of course stick around for compile testing.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 7/8] pinctrl: aspeed-g4: Add mux configuration for all pins
From: Rob Herring @ 2016-10-03 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e0d8fa6cd444972e6f048f98da98f0439e6ca39b.1474986045.git-series.andrew@aj.id.au>
On Wed, Sep 28, 2016 at 12:20:19AM +0930, Andrew Jeffery wrote:
> The patch introducing the g4 pinctrl driver implemented a smattering of
> pins to flesh out the implementation of the core and provide bare-bones
> support for some OpenPOWER platforms. Now, update the bindings document
> to reflect the complete functionality and implement the necessary pin
> configuration tables in the driver.
We prefer bindings to be complete if possible where as drivers can be
expanded over time.
>
> Cc: Timothy Pearson <tpearson@raptorengineering.com>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 19 +-
Acked-by: Rob Herring <robh@kernel.org>
> drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 1094 ++++++-
> 2 files changed, 1093 insertions(+), 20 deletions(-)
^ permalink raw reply
* [RFC] arm64: Enforce observed order for spinlock and data
From: bdegraaf at codeaurora.org @ 2016-10-03 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161001181101.GA17554@remoulade>
On 2016-10-01 14:11, Mark Rutland wrote:
> Hi Brent,
>
> Evidently my questions weren't sufficiently clear; even with your
> answers it's
> not clear to me what precise issue you're attempting to solve. I've
> tried to be
> more specific this time.
>
> At a high-level, can you clarify whether you're attempting to solve is:
>
> (a) a functional correctness issue (e.g. data corruption)
> (b) a performance issue
>
> And whether this was seen in practice, or found through code
> inspection?
>
> On Sat, Oct 01, 2016 at 12:11:36PM -0400, bdegraaf at codeaurora.org
> wrote:
>> On 2016-09-30 15:32, Mark Rutland wrote:
>> >On Fri, Sep 30, 2016 at 01:40:57PM -0400, Brent DeGraaf wrote:
>> >>+ * so LSE needs an explicit barrier here as well. Without this, the
>> >>+ * changed contents of the area protected by the spinlock could be
>> >>+ * observed prior to the lock.
>> >>+ */
>> >
>> >By whom? We generally expect that if data is protected by a lock, you take
>> >the lock before accessing it. If you expect concurrent lockless readers,
>> >then there's a requirement on the writer side to explicitly provide the
>> >ordering it requires -- spinlocks are not expected to provide that.
>>
>> More details are in my response to Robin, but there is an API arm64
>> supports
>> in spinlock.h which is used by lockref to determine whether a lock is
>> free or
>> not. For that code to work properly without adding these barriers,
>> that API
>> needs to take the lock.
>
> Can you please provide a concrete example of a case where things go
> wrong,
> citing the code (or access pattern) in question? e.g. as in the commit
> messages
> for:
>
> 8e86f0b409a44193 ("arm64: atomics: fix use of acquire + release for
> full barrier semantics)
> 859b7a0e89120505 ("mm/slub: fix lockups on PREEMPT && !SMP kernels")
>
> (for the latter, I messed up the register -> var mapping in one
> paragraph, but
> the style and reasoning is otherwise sound).
>
> In the absence of a concrete example as above, it's very difficult to
> reason
> about what the underlying issue is, and what a valid fix would be for
> said
> issue.
>
>> >What pattern of accesses are made by readers and writers such that there is
>> >a problem?
>
> Please note here I was asking specifically w.r.t. the lockref code,
> e.g. which
> loads could see stale data, and what does the code do based on this
> value such
> that there is a problem.
>
>> I added the barriers to the readers/writers because I do not know
>> these are
>> not similarly abused. There is a lot of driver code out there, and
>> ensuring
>> order is the safest way to be sure we don't get burned by something
>> similar
>> to the lockref access.
>
> Making the architecture-provided primitives overly strong harms
> performance and
> efficiency (in general), makes the code harder to maintain and optimise
> in
> future, and only masks the issue (which could crop up on other
> architectures,
> for instance).
>
> Thanks,
> Mark.
Thinking about this, as the reader/writer code has no known "abuse"
case, I'll
remove it from the patchset, then provide a v2 patchset with a detailed
explanation for the lockref problem using the commits you provided as an
example,
as well as performance consideration.
Brent
^ permalink raw reply
* [PATCH v3 2/7] i2c: bcm2835: Protect against unexpected TXW/RXR interrupts
From: Eric Anholt @ 2016-10-03 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d93a0590-1783-b913-9362-007628cb17d6@tronnes.org>
Noralf Tr?nnes <noralf@tronnes.org> writes:
> Den 29.09.2016 00:00, skrev Eric Anholt:
>> Noralf Tr?nnes <noralf@tronnes.org> writes:
>>
>>> If an unexpected TXW or RXR interrupt occurs (msg_buf_remaining == 0),
>>> the driver has no way to fill/drain the FIFO to stop the interrupts.
>>> In this case the controller has to be disabled and the transfer
>>> completed to avoid hang.
>>>
>>> (CLKT | ERR) and DONE interrupts are completed in their own paths, and
>>> the controller is disabled in the transfer function after completion.
>>> Unite the code paths and do disabling inside the interrupt routine.
>>>
>>> Clear interrupt status bits in the united completion path instead of
>>> trying to do it on every interrupt which isn't necessary.
>>> Only CLKT, ERR and DONE can be cleared that way.
>>>
>>> Add the status value to the error value in case of TXW/RXR errors to
>>> distinguish them from the other S_LEN error.
>> I was surprised that not writing the TXW/RXR bits on handling their
>> interrupts was OK, given that we were doing so before, but it's a level
>> interrupt and those bits are basically ignored on write.
>>
>> This patch and 3, 4, and 6 are:
>>
>> Reviewed-by: Eric Anholt <eric@anholt.net>
>>
>> Patch 5 is:
>>
>> Acked-by: Eric Anholt <eric@anholt.net>
>>
>> Note for future debug: The I2C_C_CLEAR on errors will take some time to
>> resolve -- if you were in non-idle state and I2C_C_READ, it sets an
>> abort_rx flag and runs through the state machine to send a NACK and a
>> STOP, I think. Since we're setting CLEAR without I2CEN, that NACK will
>> be hanging around queued up for next time we start the engine.
>
> Maybe you're able to explain the issues I had with reset:
> https://github.com/raspberrypi/linux/issues/1653
One of the questions I think you might have is "what state does the
controller end up in after the various interrupts?"
ERR:
- produced if we get a nack that's not at the end of a read.
- Proceeds to repeated start if BCM2835_I2C_C_ST is queued, otherwise
stop.
CLKT:
- Triggered by a counter outside of the state machine when stretching
happens and then times out.
- Sets cs_override, which causes proceeding through the state machine as
if the clock wasn't getting stretched, until the end of the next byte
sent/received.
- According to Wolfram we shouldn't be timing out on clock stretching
for i2c, just on the transfer as a whole
(https://patchwork.kernel.org/patch/9148431/), so I wrote
https://github.com/anholt/linux/commit/894200276239d2e4c60b378bdc52164fcb13af8d.
However, I don't see an obvious way to get back to IDLE while the
slave is still stretching, without triggering the clock stretching
timeout path.
DONE:
- Signaled at STOP, and just moves to IDLE state which keeps scl/sda
high and waits for a BCM2835_I2C_C_ST while we're not clearing the
FIFOs (if you do signal start while the fifos are clearing, the start
will hang around until the fifo clear is done). This is the only way
to get to IDLE.
I'm don't think I have an answer to the "what should I do?" question you
had, but hopefully this helps.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161003/0b6762c3/attachment.sig>
^ permalink raw reply
* [PATCH] i2c: bcm2835: Set up the clock stretching timeout at boot.
From: Eric Anholt @ 2016-10-03 19:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160722072740.GG1605@katana>
Wolfram Sang <wsa@the-dreams.de> writes:
> On Sun, Jul 03, 2016 at 06:02:32PM -0700, Eric Anholt wrote:
>> Wolfram Sang <wsa@the-dreams.de> writes:
>>
>> >> + /*
>> >> + * SMBUS says "Devices participating in a transfer will
>> >> + * timeout when any clock low exceeds the value of
>> >> + * T_TIMEOUT,MIN of 25 ms."
>> >> + */
>> >
>> > SMBus has that timeout, but I2C doesn't. How about disabling the timeout
>> > simply? Or using the max value if you want to keep the timeout
>> > detection?
>>
>> Disabling the timeout seems fine to me. We still have a 1-second
>> timeout around the entire transfer. I'll be back on my DSI branch this
>> week and test it out then.
>
> Did it work?
Sorry for the long-delayed feedback: It turned out that the reason I was
getting timeouts and looking into i2c in the first place was that the
firmware was driving that controller behind my back, so I couldn't do
useful testing anyway.
I put together a patch
(https://github.com/anholt/linux/commit/894200276239d2e4c60b378bdc52164fcb13af8d)
but I'm a bit concerned by it: I don't see a way to get the controller
back to its idle state without continuing through the I2C state machine,
and if the clock is still being stretched it doesn't continue unless CLK
is triggered.
What is supposed to happen when adap->timeout times out while the clock
is being stretched? Should we be able to try starting a fresh new I2C
transaction cleanly?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161003/880af017/attachment.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