* [PATCH] ARM: dts: r8a7794: Fix W=1 dtc warnings
From: Geert Uytterhoeven @ 2016-10-04 13:31 UTC (permalink / raw)
To: linux-arm-kernel
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,dvc/dvc at 0 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,dvc/dvc at 1 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,mix/mix at 0 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,mix/mix at 1 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,ctu/ctu at 0 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,ctu/ctu at 1 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,ctu/ctu at 2 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,ctu/ctu at 3 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,ctu/ctu at 4 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,ctu/ctu at 5 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,ctu/ctu at 6 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,ctu/ctu at 7 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,src/src at 0 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,src/src at 1 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,src/src at 2 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,src/src at 3 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,src/src at 4 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,src/src at 5 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,src/src at 6 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,ssi/ssi at 0 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,ssi/ssi at 1 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,ssi/ssi at 2 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,ssi/ssi at 3 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,ssi/ssi at 4 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,ssi/ssi at 5 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,ssi/ssi at 6 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,ssi/ssi at 7 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,ssi/ssi at 8 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,ssi/ssi at 9 has a unit name, but no reg property
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r8a7794.dtsi | 58 +++++++++++++++++++++---------------------
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index f53c75b2b0d33de2..7bfa57f357d4ad2a 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -1502,62 +1502,62 @@
status = "disabled";
rcar_sound,dvc {
- dvc0: dvc at 0 {
+ dvc0: dvc-0 {
dmas = <&audma0 0xbc>;
dma-names = "tx";
};
- dvc1: dvc at 1 {
+ dvc1: dvc-1 {
dmas = <&audma0 0xbe>;
dma-names = "tx";
};
};
rcar_sound,mix {
- mix0: mix at 0 { };
- mix1: mix at 1 { };
+ mix0: mix-0 { };
+ mix1: mix-1 { };
};
rcar_sound,ctu {
- ctu00: ctu at 0 { };
- ctu01: ctu at 1 { };
- ctu02: ctu at 2 { };
- ctu03: ctu at 3 { };
- ctu10: ctu at 4 { };
- ctu11: ctu at 5 { };
- ctu12: ctu at 6 { };
- ctu13: ctu at 7 { };
+ ctu00: ctu-0 { };
+ ctu01: ctu-1 { };
+ ctu02: ctu-2 { };
+ ctu03: ctu-3 { };
+ ctu10: ctu-4 { };
+ ctu11: ctu-5 { };
+ ctu12: ctu-6 { };
+ ctu13: ctu-7 { };
};
rcar_sound,src {
- src at 0 {
+ src-0 {
status = "disabled";
};
- src1: src at 1 {
+ src1: src-1 {
interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x87>, <&audma0 0x9c>;
dma-names = "rx", "tx";
};
- src2: src at 2 {
+ src2: src-2 {
interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x89>, <&audma0 0x9e>;
dma-names = "rx", "tx";
};
- src3: src at 3 {
+ src3: src-3 {
interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x8b>, <&audma0 0xa0>;
dma-names = "rx", "tx";
};
- src4: src at 4 {
+ src4: src-4 {
interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x8d>, <&audma0 0xb0>;
dma-names = "rx", "tx";
};
- src5: src at 5 {
+ src5: src-5 {
interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x8f>, <&audma0 0xb2>;
dma-names = "rx", "tx";
};
- src6: src at 6 {
+ src6: src-6 {
interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x91>, <&audma0 0xb4>;
dma-names = "rx", "tx";
@@ -1565,61 +1565,61 @@
};
rcar_sound,ssi {
- ssi0: ssi at 0 {
+ ssi0: ssi-0 {
interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x01>, <&audma0 0x02>,
<&audma0 0x15>, <&audma0 0x16>;
dma-names = "rx", "tx", "rxu", "txu";
};
- ssi1: ssi at 1 {
+ ssi1: ssi-1 {
interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x03>, <&audma0 0x04>,
<&audma0 0x49>, <&audma0 0x4a>;
dma-names = "rx", "tx", "rxu", "txu";
};
- ssi2: ssi at 2 {
+ ssi2: ssi-2 {
interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x05>, <&audma0 0x06>,
<&audma0 0x63>, <&audma0 0x64>;
dma-names = "rx", "tx", "rxu", "txu";
};
- ssi3: ssi at 3 {
+ ssi3: ssi-3 {
interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x07>, <&audma0 0x08>,
<&audma0 0x6f>, <&audma0 0x70>;
dma-names = "rx", "tx", "rxu", "txu";
};
- ssi4: ssi at 4 {
+ ssi4: ssi-4 {
interrupts = <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x09>, <&audma0 0x0a>,
<&audma0 0x71>, <&audma0 0x72>;
dma-names = "rx", "tx", "rxu", "txu";
};
- ssi5: ssi at 5 {
+ ssi5: ssi-5 {
interrupts = <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x0b>, <&audma0 0x0c>,
<&audma0 0x73>, <&audma0 0x74>;
dma-names = "rx", "tx", "rxu", "txu";
};
- ssi6: ssi at 6 {
+ ssi6: ssi-6 {
interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x0d>, <&audma0 0x0e>,
<&audma0 0x75>, <&audma0 0x76>;
dma-names = "rx", "tx", "rxu", "txu";
};
- ssi7: ssi at 7 {
+ ssi7: ssi-7 {
interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x0f>, <&audma0 0x10>,
<&audma0 0x79>, <&audma0 0x7a>;
dma-names = "rx", "tx", "rxu", "txu";
};
- ssi8: ssi at 8 {
+ ssi8: ssi-8 {
interrupts = <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x11>, <&audma0 0x12>,
<&audma0 0x7b>, <&audma0 0x7c>;
dma-names = "rx", "tx", "rxu", "txu";
};
- ssi9: ssi at 9 {
+ ssi9: ssi-9 {
interrupts = <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x13>, <&audma0 0x14>,
<&audma0 0x7d>, <&audma0 0x7e>;
--
1.9.1
^ permalink raw reply related
* [PATCH v26 0/7] arm64: add kdump support
From: Manish Jaggi @ 2016-10-04 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57F38A30.2050200@arm.com>
On 10/04/2016 04:23 PM, James Morse wrote:
> Hi Manish,
>
> On 04/10/16 11:05, Manish Jaggi wrote:
>> On 10/04/2016 03:16 PM, James Morse wrote:
>>> On 03/10/16 13:41, Manish Jaggi wrote:
>>>> On 10/03/2016 04:34 PM, AKASHI Takahiro wrote:
>>>>> On Mon, Oct 03, 2016 at 01:24:34PM +0530, Manish Jaggi wrote:
>>>>>> First kernel is booted with mem=2G crashkernel=1G command line option.
>>>>>> While the system has 64G memory.
>>>
>>>>> Are you saying that "mem=..." doesn't have any effect?
>>>> What I am saying it that If the first kernel is booted using mem= option and crashkernel= option
>>>> the memory for second kernel has to be withing the crashkernel size.
>>>> As per /proc/iomem System RAM the information is correct, but the /proc/meminfo is showing total memory
>>>> much more than the first kernel had in first place.
>>>
>>> So your second crashkernel has 63G of memory? Unless you provide the same 'mem='
>>> to the kdump kernel, this is the expected behaviour. The
>>> DT:/reserved-memory/crash_dump describes the memory not to use.
>>>
>>> On your first boot with 'mem=2G' memblock_mem_limit_remove_map() called from
>>> arm64_memblock_init() removed the top 62G of memory. Neither the first kernel
>>> nor kexec-tools know about the top 62G.
>>> When you run kexec-tools, it describes what it sees in /proc/iomem in the
>>> DT:/reserved-memory/crash_dump, which is just the remaining 1G of memory.
>>>
>>> When we crash and reboot, the crash kernel discovers all 64G of memory from the
>>> EFI memory map.
>
>> So the iomem and meminfo should be same or different for the second kernel?
>> Also i assumed that crashkernel=1G should restrict the second kernels to 1G.
>
> Not with v26 of this series. What should it do with the 62G of memory that was
> removed by booting with 'mem=2G'? It isn't part of the crashkernel reserved
> area, and it isn't part of the vmcore described in elfcorehdr either...
>
>
>> This is my understanding from the description. It should not require a second mem= option
>
>>> kexec-tools described the 1G of memory that the first kernel was using in the
>>> DT:/reserved-memory/crash_dump node, so early_init_fdt_scan_reserved_mem()
>>> reserves the 1G of memory the first kernel used. This leaves us with 63G of memory.
>>>
>>> This may change with the next version of kdump if it switches back to using
>>> DT:/chosen/linux,usable-memory-range.
>>> If you need v26 to avoid the top 62G of memory, you need to provide the same
>>> 'mem=' to the first and second kernel.
>
>> If I provide for second kernel, I dont see any prints after Bye.
>> Have you tired this anytime?
>
> Yes, on juno-r1 passing 'mem=2G' to both the first and second kernel causes only
> the first 2G of memory to be used with this pattern:
> first kernel: [1G used for linux] [1G reserved for Crash kernel] [6G memory
> hidden]
> kdump kernel: [1G vmcore] [1G used for linux] [6G memory hidden]
>
>
Oh, ok!
I was giving mem=1G to crashkernel to test. with mem=2G it works.
>>>>>> 1.2 Live crash dump fails with error
>>>
>>> ... do we expect this to work? I don't think it has anything to do with this
>>> series...
>>>
>> Why it should not?
>> I saved the vmcore file while in second kernel. Since crash without vmcore file didnt run,
>> Tried with vmcore file and it worked. Its just that if you want to boot a second kernel
>> with read only file system without network live crash dump analysis is handy.
>
> Ah, you want to run /usr/bin/crash with the kdump boot of linux. You still need
> to tell it where to find the memory image: "crash /path/to/vmlinux /proc/vmcore"
> should do the trick.
>
We should fix the documentation of kdump them.
Since it is not supported, it should be removed.
>
> Thanks,
>
> James
>
^ permalink raw reply
* [PATCH 2/2] ARM: shmobile: r8a7793/gose: Add board part number to DT bindings
From: Geert Uytterhoeven @ 2016-10-04 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475587248-13670-1-git-send-email-geert+renesas@glider.be>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/devicetree/bindings/arm/shmobile.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index 6c3ffc2ebeaa346a..18a20a7689c52342 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -47,7 +47,7 @@ Boards:
compatible = "renesas,bockw", "renesas,r8a7778"
- Genmai (RTK772100BC00000BR)
compatible = "renesas,genmai", "renesas,r7s72100"
- - Gose
+ - Gose (RTP0RC7793SEB00010S)
compatible = "renesas,gose", "renesas,r8a7793"
- H3ULCB (RTP0RC7795SKB00010S)
compatible = "renesas,h3ulcb", "renesas,r8a7795";
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] ARM: shmobile: r8a7794/alt: Add board part number to DT bindings
From: Geert Uytterhoeven @ 2016-10-04 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475587248-13670-1-git-send-email-geert+renesas@glider.be>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/devicetree/bindings/arm/shmobile.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index 19f0a9e4302b508c..6c3ffc2ebeaa346a 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -35,7 +35,7 @@ SoCs:
Boards:
- - Alt
+ - Alt (RTP0RC7794SEB00010S)
compatible = "renesas,alt", "renesas,r8a7794"
- APE6-EVM
compatible = "renesas,ape6evm", "renesas,r8a73a4"
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] ARM: shmobile: alt/gose: Add board part number to DT bindings
From: Geert Uytterhoeven @ 2016-10-04 13:20 UTC (permalink / raw)
To: linux-arm-kernel
Hi Simon, Magnus,
This series at the missing board part numbers for r8a7794/alt and
r8a7793/gose to the DT binding documentation, like is done for the other
boards.
Thanks for applying!
Geert Uytterhoeven (2):
ARM: shmobile: r8a7794/alt: Add board part number to DT bindings
ARM: shmobile: r8a7793/gose: Add board part number to DT bindings
Documentation/devicetree/bindings/arm/shmobile.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v3 1/2] crypto: marvell - Use an unique pool to copy results of requests
From: Boris Brezillon @ 2016-10-04 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004125720.3347-2-romain.perier@free-electrons.com>
On Tue, 4 Oct 2016 14:57:19 +0200
Romain Perier <romain.perier@free-electrons.com> wrote:
> 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 v3:
> - Don't allocate a new op ctx for the last tdma descriptor. Instead
> we point to the last op ctx in the tdma chain, and copy the context
> of the current request to this location.
>
> 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 | 28 ++++++++++++++--------------
> 4 files changed, 21 insertions(+), 24 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..991dc3f 100644
> --- a/drivers/crypto/marvell/tdma.c
> +++ b/drivers/crypto/marvell/tdma.c
> @@ -69,9 +69,6 @@ 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,
> - le32_to_cpu(tdma->dst));
>
> tdma = tdma->next;
> dma_pool_free(cesa_dev->dma->tdma_desc_pool, old_tdma,
> @@ -209,29 +206,32 @@ 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;
> - dma_addr_t dma_handle;
> + struct mv_cesa_tdma_desc *tdma, *op_desc;
>
> 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)
> - return -ENOMEM;
Can you add a comment explaining what you're doing here?
/* We re-use an existing op_desc object to retrieve the context
* and result instead of allocating a new one.
* There is at least one object of this type in a CESA crypto
* req, just pick the first one in the chain.
*/
Once this is addressed, you can add my
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> + for (op_desc = chain->first; op_desc; op_desc = op_desc->next) {
> + u32 type = op_desc->flags & CESA_TDMA_TYPE_MSK;
> +
> + if (type == CESA_TDMA_OP)
> + break;
> + }
> +
> + if (!op_desc)
> + return -EIO;
>
> tdma->byte_cnt = cpu_to_le32(size | BIT(31));
> tdma->src = src;
> - tdma->dst = cpu_to_le32(dma_handle);
> - tdma->data = iv;
> + tdma->dst = op_desc->src;
> + tdma->op = op_desc->op;
>
> 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;
> }
>
^ permalink raw reply
* [PATCH 06/14] ASoC: Add sun8i digital audio codec
From: Thomas Petazzoni @ 2016-10-04 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004130727.srmaielkvd2z5k3s@sirena.org.uk>
Hello,
On Tue, 4 Oct 2016 15:07:27 +0200, Mark Brown wrote:
> > /*
> > * ...
> > */
>
> I don't care, IIRC that's something from CodingStyle which checkpatch
> moans about.
Correct. The
/* ..
* ..
*/
style is mandatory for net/ and crypto code, but not in the rest of the
kernel.
> > I'm probably missing something, but in the sun4i-codec.c driver, those
> > fields are initialized directly in the snd_soc_codec_driver structure,
> > not in the .component_driver sub-structure.
>
> We're in the process of pushing everything out to component level, this
> update should be made in the old code if it's not happened already.
OK.
> > > + if (clk_prepare_enable(scodec->clk_module))
> > > + pr_err("err:open failed;\n");
>
> > Grr, pr_err, not good. Plus you want to return with an error from the
> > probe() function.
>
> Also when printing an error message use dev_err().
That's why I said "Grr, pr_err, not good" :)
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 4/4] ARM: dts: dra72-evm-revc: fix correct phy delay
From: Andrew Lunn @ 2016-10-04 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004125607.10569-5-mugunthanvnm@ti.com>
On Tue, Oct 04, 2016 at 06:26:07PM +0530, Mugunthan V N wrote:
> The current delay settings of the phy are not the optimal value,
> fix it with correct values.
This should be a separate patch, since it has nothing to do with impedance.
Andrew
>
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> ---
> arch/arm/boot/dts/dra72-evm-revc.dts | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
> index d626cd7..8472a8c 100644
> --- a/arch/arm/boot/dts/dra72-evm-revc.dts
> +++ b/arch/arm/boot/dts/dra72-evm-revc.dts
> @@ -59,16 +59,16 @@
> &davinci_mdio {
> dp83867_0: ethernet-phy at 2 {
> reg = <2>;
> - ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
> - ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
> + ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
> + ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
> ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
> ti,min-output-imepdance;
> };
>
> dp83867_1: ethernet-phy at 3 {
> reg = <3>;
> - ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
> - ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
> + ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
> + ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
> ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
> ti,min-output-imepdance;
> };
> --
> 2.10.0.372.g6fe1b14
>
^ permalink raw reply
* [PATCH v2 3/4] ARM: dts: dra72-evm-revc: fix correct phy delay and impedance settings
From: Andrew Lunn @ 2016-10-04 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004125607.10569-4-mugunthanvnm@ti.com>
On Tue, Oct 04, 2016 at 06:26:06PM +0530, Mugunthan V N wrote:
> The default impedance settings of the phy is not the optimal
> value, due to this the second ethernet is not working. Fix it
> with correct values which makes the second ethernet port to work.
>
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> ---
> arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
> index f9cfd3b..d626cd7 100644
> --- a/arch/arm/boot/dts/dra72-evm-revc.dts
> +++ b/arch/arm/boot/dts/dra72-evm-revc.dts
> @@ -62,6 +62,7 @@
> ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
> ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
> ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
> + ti,min-output-imepdance;
And there is my answer :-(
Andrew
^ permalink raw reply
* [PATCH v2 3/4] ARM: dts: dra72-evm-revc: fix correct phy delay and impedance settings
From: Lokesh Vutla @ 2016-10-04 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004125607.10569-4-mugunthanvnm@ti.com>
On Tuesday 04 October 2016 06:26 PM, Mugunthan V N wrote:
> The default impedance settings of the phy is not the optimal
> value, due to this the second ethernet is not working. Fix it
> with correct values which makes the second ethernet port to work.
>
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> ---
> arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
> index f9cfd3b..d626cd7 100644
> --- a/arch/arm/boot/dts/dra72-evm-revc.dts
> +++ b/arch/arm/boot/dts/dra72-evm-revc.dts
> @@ -62,6 +62,7 @@
> ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
> ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
> ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
> + ti,min-output-imepdance;
s/imepdance/impedance
> };
>
> dp83867_1: ethernet-phy at 3 {
> @@ -69,5 +70,6 @@
> ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
> ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
> ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
> + ti,min-output-imepdance;
same here.
Thanks and regards,
Lokesh
> };
> };
>
^ permalink raw reply
* [PATCH v2 2/4] net: phy: dp83867: add support for MAC impedance configuration
From: Andrew Lunn @ 2016-10-04 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004125607.10569-3-mugunthanvnm@ti.com>
> + if (of_property_read_bool(of_node, "ti,max-output-imepdance"))
> + dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
> + else if (of_property_read_bool(of_node, "ti,min-output-imepdance"))
Did you really test this? Or did you make the same typos in your device
tree file?
Andrew
^ permalink raw reply
* [PATCH v2 2/4] net: phy: dp83867: add support for MAC impedance configuration
From: Lokesh Vutla @ 2016-10-04 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004125607.10569-3-mugunthanvnm@ti.com>
On Tuesday 04 October 2016 06:26 PM, Mugunthan V N wrote:
> Add support for programmable MAC impedance configuration
>
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> ---
> drivers/net/phy/dp83867.c | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
> index 91177a4..795ae17 100644
> --- a/drivers/net/phy/dp83867.c
> +++ b/drivers/net/phy/dp83867.c
> @@ -33,6 +33,7 @@
> /* Extended Registers */
> #define DP83867_RGMIICTL 0x0032
> #define DP83867_RGMIIDCTL 0x0086
> +#define DP83867_IO_MUX_CFG 0x0170
>
> #define DP83867_SW_RESET BIT(15)
> #define DP83867_SW_RESTART BIT(14)
> @@ -62,10 +63,17 @@
> /* RGMIIDCTL bits */
> #define DP83867_RGMII_TX_CLK_DELAY_SHIFT 4
>
> +/* IO_MUX_CFG bits */
> +#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL 0x1f
> +
> +#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX 0x0
> +#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN 0x1f
> +
> struct dp83867_private {
> int rx_id_delay;
> int tx_id_delay;
> int fifo_depth;
> + int io_impedance;
> };
>
> static int dp83867_ack_interrupt(struct phy_device *phydev)
> @@ -111,6 +119,14 @@ static int dp83867_of_init(struct phy_device *phydev)
> if (!of_node)
> return -ENODEV;
>
> + dp83867->io_impedance = -EINVAL;
> +
> + /* Optional configuration */
> + if (of_property_read_bool(of_node, "ti,max-output-imepdance"))
s/imepdance/impedance
> + dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
> + else if (of_property_read_bool(of_node, "ti,min-output-imepdance"))
s/imepdance/impedance
Thanks and regards,
Lokesh
> + dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
> +
> ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
> &dp83867->rx_id_delay);
> if (ret)
> @@ -184,6 +200,18 @@ static int dp83867_config_init(struct phy_device *phydev)
>
> phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
> DP83867_DEVADDR, delay);
> +
> + if (dp83867->io_impedance >= 0) {
> + val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
> + DP83867_DEVADDR);
> +
> + val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
> + val |= dp83867->io_impedance &
> + DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
> +
> + phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
> + DP83867_DEVADDR, val);
> + }
> }
>
> return 0;
>
^ permalink raw reply
* [PATCH 06/14] ASoC: Add sun8i digital audio codec
From: Mark Brown @ 2016-10-04 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004144008.0d07d18c@free-electrons.com>
On Tue, Oct 04, 2016 at 02:40:08PM +0200, Thomas Petazzoni wrote:
> > +/* CODEC_OFFSET represents the offset of the codec registers
> > + * and not all the DAI registers
> > + */
> This is not the proper comment style I believe for audio code, it
> should be:
> /*
> * ...
> */
I don't care, IIRC that's something from CodingStyle which checkpatch
moans about.
> > + /* pcm operations */
> > + .ops = &sun8i_codec_dai_ops,
> > +};
> > +EXPORT_SYMBOL(sun8i_codec_dai);
> This EXPORT_SYMBOL looks wrong. First because it doesn't seem to be
> used outside of this module. And second because using EXPORT_SYMBOL on
> a function defined as static doesn't make much sense, as the "static"
> qualifier limits the visibility of the symbol to the current
> compilation unit.
Also all the ASoC code is _GPL so a non-GPL export is an issue.
> > + .component_driver = {
> > + .dapm_widgets = sun8i_codec_dapm_widgets,
> > + .num_dapm_widgets = ARRAY_SIZE(sun8i_codec_dapm_widgets),
> > + .dapm_routes = sun8i_codec_dapm_routes,
> > + .num_dapm_routes = ARRAY_SIZE(sun8i_codec_dapm_routes),
> I'm probably missing something, but in the sun4i-codec.c driver, those
> fields are initialized directly in the snd_soc_codec_driver structure,
> not in the .component_driver sub-structure.
We're in the process of pushing everything out to component level, this
update should be made in the old code if it's not happened already.
> > + if (clk_prepare_enable(scodec->clk_module))
> > + pr_err("err:open failed;\n");
> Grr, pr_err, not good. Plus you want to return with an error from the
> probe() function.
Also when printing an error message use dev_err().
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161004/4287ed0a/attachment.sig>
^ permalink raw reply
* [PATCH 6/6] ARM: da850: adjust memory settings for tilcdc
From: Kevin Hilman @ 2016-10-04 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0125defa-5c34-85d0-f62a-133235c5094c@ti.com>
Peter Ujfalusi <peter.ujfalusi@ti.com> writes:
> On 10/01/16 12:24, Sekhar Nori wrote:
[...]
>> In any case, to configure the PBBR, you will have to introduce a driver
>> for it in drivers/memory. Then you can set it up per board using a DT
>> parameter.
>
> and we can reuse the introduced bindings for am335x and OMAP1/2 as well. On
> OMAP the legacy DMA API provided a call to raise the priority of the sDMA in
> EMIF :o That needs to be removed and replaced.
Can you point us to the bindings you're referring to?
Also, a new driver in drivers/memory is fine for setting the PBBR, but
what about the SYSCFG0 registers. Are you OK with leaving those in the
init code as proposed in $SUBJECT patch?
Kevin
^ permalink raw reply
* [PATCH v3 2/2] crypto: marvell - Don't break chain for computable last ahash requests
From: Romain Perier @ 2016-10-04 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004125720.3347-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 context 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 v3:
- Copy the whole context back to RAM and not just the digest. Also
fixed a rebase issue ^^ (whoops)
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/hash.c | 79 +++++++++++++++++++++++++++++++++++--------
1 file changed, 64 insertions(+), 15 deletions(-)
diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index 9f28468..b36f196 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->op->ctx.hash.hash;
+ 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_CFG_SRAM_OFFSET,
+ CESA_SA_DATA_SRAM_OFFSET,
+ 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;
--
2.9.3
^ permalink raw reply related
* [PATCH v3 1/2] crypto: marvell - Use an unique pool to copy results of requests
From: Romain Perier @ 2016-10-04 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004125720.3347-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 v3:
- Don't allocate a new op ctx for the last tdma descriptor. Instead
we point to the last op ctx in the tdma chain, and copy the context
of the current request to this location.
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 | 28 ++++++++++++++--------------
4 files changed, 21 insertions(+), 24 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..991dc3f 100644
--- a/drivers/crypto/marvell/tdma.c
+++ b/drivers/crypto/marvell/tdma.c
@@ -69,9 +69,6 @@ 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,
- le32_to_cpu(tdma->dst));
tdma = tdma->next;
dma_pool_free(cesa_dev->dma->tdma_desc_pool, old_tdma,
@@ -209,29 +206,32 @@ 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;
- dma_addr_t dma_handle;
+ struct mv_cesa_tdma_desc *tdma, *op_desc;
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)
- return -ENOMEM;
+ for (op_desc = chain->first; op_desc; op_desc = op_desc->next) {
+ u32 type = op_desc->flags & CESA_TDMA_TYPE_MSK;
+
+ if (type == CESA_TDMA_OP)
+ break;
+ }
+
+ if (!op_desc)
+ return -EIO;
tdma->byte_cnt = cpu_to_le32(size | BIT(31));
tdma->src = src;
- tdma->dst = cpu_to_le32(dma_handle);
- tdma->data = iv;
+ tdma->dst = op_desc->src;
+ tdma->op = op_desc->op;
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 v3 0/2] Improve DMA chaining for ahash requests
From: Romain Perier @ 2016-10-04 12:57 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 422 Mbits/s 577 Mbits/s
Improvement +23% +17%
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 | 8 +++--
drivers/crypto/marvell/hash.c | 79 +++++++++++++++++++++++++++++++++--------
drivers/crypto/marvell/tdma.c | 28 +++++++--------
5 files changed, 85 insertions(+), 39 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH v2 4/4] ARM: dts: dra72-evm-revc: fix correct phy delay
From: Mugunthan V N @ 2016-10-04 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004125607.10569-1-mugunthanvnm@ti.com>
The current delay settings of the phy are not the optimal value,
fix it with correct values.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/boot/dts/dra72-evm-revc.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
index d626cd7..8472a8c 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -59,16 +59,16 @@
&davinci_mdio {
dp83867_0: ethernet-phy at 2 {
reg = <2>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
ti,min-output-imepdance;
};
dp83867_1: ethernet-phy at 3 {
reg = <3>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
ti,min-output-imepdance;
};
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* [PATCH v2 3/4] ARM: dts: dra72-evm-revc: fix correct phy delay and impedance settings
From: Mugunthan V N @ 2016-10-04 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004125607.10569-1-mugunthanvnm@ti.com>
The default impedance settings of the phy is not the optimal
value, due to this the second ethernet is not working. Fix it
with correct values which makes the second ethernet port to work.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
index f9cfd3b..d626cd7 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -62,6 +62,7 @@
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
+ ti,min-output-imepdance;
};
dp83867_1: ethernet-phy at 3 {
@@ -69,5 +70,6 @@
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
+ ti,min-output-imepdance;
};
};
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* [PATCH v2 2/4] net: phy: dp83867: add support for MAC impedance configuration
From: Mugunthan V N @ 2016-10-04 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004125607.10569-1-mugunthanvnm@ti.com>
Add support for programmable MAC impedance configuration
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/phy/dp83867.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 91177a4..795ae17 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -33,6 +33,7 @@
/* Extended Registers */
#define DP83867_RGMIICTL 0x0032
#define DP83867_RGMIIDCTL 0x0086
+#define DP83867_IO_MUX_CFG 0x0170
#define DP83867_SW_RESET BIT(15)
#define DP83867_SW_RESTART BIT(14)
@@ -62,10 +63,17 @@
/* RGMIIDCTL bits */
#define DP83867_RGMII_TX_CLK_DELAY_SHIFT 4
+/* IO_MUX_CFG bits */
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL 0x1f
+
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX 0x0
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN 0x1f
+
struct dp83867_private {
int rx_id_delay;
int tx_id_delay;
int fifo_depth;
+ int io_impedance;
};
static int dp83867_ack_interrupt(struct phy_device *phydev)
@@ -111,6 +119,14 @@ static int dp83867_of_init(struct phy_device *phydev)
if (!of_node)
return -ENODEV;
+ dp83867->io_impedance = -EINVAL;
+
+ /* Optional configuration */
+ if (of_property_read_bool(of_node, "ti,max-output-imepdance"))
+ dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
+ else if (of_property_read_bool(of_node, "ti,min-output-imepdance"))
+ dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
+
ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
&dp83867->rx_id_delay);
if (ret)
@@ -184,6 +200,18 @@ static int dp83867_config_init(struct phy_device *phydev)
phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
DP83867_DEVADDR, delay);
+
+ if (dp83867->io_impedance >= 0) {
+ val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+ DP83867_DEVADDR);
+
+ val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+ val |= dp83867->io_impedance &
+ DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+
+ phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+ DP83867_DEVADDR, val);
+ }
}
return 0;
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* [PATCH v2 1/4] net: phy: dp83867: Add documentation for optional impedance control
From: Mugunthan V N @ 2016-10-04 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004125607.10569-1-mugunthanvnm@ti.com>
Add documention of ti,impedance-control which can be used to
correct MAC impedance mismatch using phy extended registers.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
Documentation/devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt
index 5d21141..85bf945 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
@@ -9,6 +9,18 @@ Required properties:
- ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
for applicable values
+Optional property:
+ - ti,min-output-impedance - MAC Interface Impedance control to set
+ the programmable output impedance to
+ minimum value (35 ohms).
+ - ti,max-output-impedance - MAC Interface Impedance control to set
+ the programmable output impedance to
+ maximum value (70 ohms).
+
+Note: ti,min-output-impedance and ti,max-output-impedance are mutually
+ exclusive. When both properties are present ti,max-output-impedance
+ takes precedence.
+
Default child nodes are standard Ethernet PHY device
nodes as described in Documentation/devicetree/bindings/net/phy.txt
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* [PATCH v2 0/4] add support for impedance control for TI dp83867 phy and fix 2nd ethernet on dra72 rev C evm
From: Mugunthan V N @ 2016-10-04 12:56 UTC (permalink / raw)
To: linux-arm-kernel
Add support for configurable impedance control for TI dp83867
phy via devicetree. More documentation in [1].
CPSW second ethernet is not working, fix it by enabling
impedance configuration on the phy.
Verified the patch on DRA72 Rev C evm, logs at [2]. Also pushed
a branch [3] for others to test.
Changes from initial version:
* As per Sekhar's comment, instead of passing impedance values,
change to max and min impedance from DT
* Adopted phy_read_mmd_indirect() to cunnrent implementation.
* Corrected the phy delay timings to the optimal value.
[1] - http://www.ti.com/lit/ds/symlink/dp83867ir.pdf
[2] - http://pastebin.ubuntu.com/23274616/
[3] - git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git dp83867-v2
Mugunthan V N (4):
net: phy: dp83867: Add documentation for optional impedance control
net: phy: dp83867: add support for MAC impedance configuration
ARM: dts: dra72-evm-revc: fix correct phy delay and impedance settings
ARM: dts: dra72-evm-revc: fix correct phy delay
.../devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++
arch/arm/boot/dts/dra72-evm-revc.dts | 10 ++++----
drivers/net/phy/dp83867.c | 28 ++++++++++++++++++++++
3 files changed, 46 insertions(+), 4 deletions(-)
--
2.10.0.372.g6fe1b14
^ permalink raw reply
* Coresight ETF trace dump failed in Juno r1 with 4.8-rc8
From: Sudeep Holla @ 2016-10-04 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGhh56HHbpLAmsu0z9xMPgq9m0qGBHdr6Kj2xw3vhNYu+fUONA@mail.gmail.com>
On 04/10/16 13:14, Venkatesh Vivekanandan wrote:
> On Tue, Oct 4, 2016 at 4:00 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 04/10/16 06:37, Venkatesh Vivekanandan wrote:
>>>
>>> On Mon, Oct 3, 2016 at 6:44 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>
>>>> Hi Venkatesh,
>>>>
>>>> On 03/10/16 12:36, Venkatesh Vivekanandan wrote:
>>>>>
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I am trying to collect ETF trace from Juno R1 and could see "cpu
>>>>> stall" while dumping the trace. Attached is the log of sequence
>>>>> followed. Was trying to collect the trace data from hardware and see
>>>>> if it is any valid data. Am I missing anything here?.
>>>>>
>>>>
>>>> There are few fixes from me and Suzuki queued for v4.9.
>>>> Can you check if this issue persists even on linux-next ?
>>>
>>>
>>> Issue is the same in linux-next as well. Please find the attached log.
>>>
>>
>> OK, what do you mean by the issue still being present. I no longer see
>> any ETM failures or messages. Does the system hang when you try to read
>> /dev/<addr>.etf ?
> Yes, system hangs while reading /dev/<addr>.etf. Most of the times, it
> gives RCU stall and sometimes just hangs and I have to reboot in both
> case.
OK, I am unable reproduce the issue hence suspecting the firmware to be
very old.
>>
>> Also the RCU stalls could be related to CPUIdle. Are you using latest
>> versions of trusted firmware ?
> Firmware is the one that came along with the board. Didn't update to
> anything latest.
>
> From bootlog,
>
> [ 0.000000] Boot CPU: AArch64 Processor [411fd071]
> [ 0.000000] earlycon: pl11 at MMIO 0x000000007ff80000 (options '')
> [ 0.000000] bootconsole [pl11] enabled
> [ 0.000000] efi: Getting EFI parameters from FDT:
> [ 0.000000] efi: EFI v2.50 by ARM Juno EFI Nov 24 2015 17:54:31
> [ 0.000000] efi: ACPI=0xfe720000 ACPI 2.0=0xfe720014 PROP=0xfe773f30
>
No, I was referring to the ones very early in the boot, something like:
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v1.2(release):a5a423100822
NOTICE: BL1: Built : 11:42:57, Sep 30 2016
NOTICE: BL1: Booting BL2
NOTICE: BL2: v1.2(release):a5a423100822
NOTICE: BL2: Built : 11:42:58, Sep 30 2016
NOTICE: BL1: Booting BL31
NOTICE: BL31: v1.2(release):a5a423100822
NOTICE: BL31: Built : 11:43:06, Sep 30 2016
UEFI firmware (version built at 11:42:39 on Sep 30 2016)
Ignore the dates here as I have build one last week.
> Please let me know, if the firmware needs to be updated to specific
> version. Any pointers on that would be appreciated.
>
Yes always better as they will have bug fixes. You can get one from [1]
or just follow instructions @[2].
[1]
http://snapshots.linaro.org/member-builds/armlt-platforms-release/32/juno-uefi.zip
[2] https://community.arm.com/docs/DOC-11395
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 2/2] tty: serial: Makefile: move kgdb to be initialized last
From: Nicolae Rosia @ 2016-10-04 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475585177-28777-1-git-send-email-nicolae.rosia.oss@gmail.com>
From: Nicolae Rosia <nicolae_rosia@mentor.com>
fsl_lpuart cannot be used with kgdb because the kgdb
initcall is called before the driver's init.
Move kgdb to be initialized after all serial drivers
have been inited.
Signed-off-by: Nicolae Rosia <nicolae_rosia@mentor.com>
Signed-off-by: Stefan Golinschi <stefan.golinschi@gmail.com>
---
drivers/tty/serial/Makefile | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index 1278d37..8016ef9 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -62,13 +62,11 @@ obj-$(CONFIG_SERIAL_ATMEL) += atmel_serial.o
obj-$(CONFIG_SERIAL_UARTLITE) += uartlite.o
obj-$(CONFIG_SERIAL_MSM) += msm_serial.o
obj-$(CONFIG_SERIAL_NETX) += netx-serial.o
-obj-$(CONFIG_SERIAL_KGDB_NMI) += kgdb_nmi.o
obj-$(CONFIG_SERIAL_KS8695) += serial_ks8695.o
obj-$(CONFIG_SERIAL_OMAP) += omap-serial.o
obj-$(CONFIG_SERIAL_ALTERA_UART) += altera_uart.o
obj-$(CONFIG_SERIAL_ST_ASC) += st-asc.o
obj-$(CONFIG_SERIAL_TILEGX) += tilegx.o
-obj-$(CONFIG_KGDB_SERIAL_CONSOLE) += kgdboc.o
obj-$(CONFIG_SERIAL_QE) += ucc_uart.o
obj-$(CONFIG_SERIAL_TIMBERDALE) += timbuart.o
obj-$(CONFIG_SERIAL_GRLIB_GAISLER_APBUART) += apbuart.o
@@ -96,3 +94,6 @@ obj-$(CONFIG_SERIAL_MPS2_UART) += mps2-uart.o
# GPIOLIB helpers for modem control lines
obj-$(CONFIG_SERIAL_MCTRL_GPIO) += serial_mctrl_gpio.o
+
+obj-$(CONFIG_SERIAL_KGDB_NMI) += kgdb_nmi.o
+obj-$(CONFIG_KGDB_SERIAL_CONSOLE) += kgdboc.o
--
2.5.5
^ permalink raw reply related
* [PATCH 1/2] tty: serial: fsl_lpuart: add polled console functions
From: Nicolae Rosia @ 2016-10-04 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475585177-28777-1-git-send-email-nicolae.rosia.oss@gmail.com>
From: Nicolae Rosia <nicolae_rosia@mentor.com>
This adds polling functions as used by kgdb.
Signed-off-by: Nicolae Rosia <nicolae_rosia@mentor.com>
Signed-off-by: Stefan Golinschi <stefan.golinschi@gmail.com>
---
drivers/tty/serial/fsl_lpuart.c | 66 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 66 insertions(+)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index de9d510..49d7526 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -431,6 +431,67 @@ static void lpuart_flush_buffer(struct uart_port *port)
}
}
+#if defined(CONFIG_CONSOLE_POLL)
+
+static int lpuart_poll_init(struct uart_port *port)
+{
+ struct lpuart_port *sport = container_of(port,
+ struct lpuart_port, port);
+ unsigned long flags;
+ unsigned char temp;
+
+ sport->port.fifosize = 0;
+
+ spin_lock_irqsave(&sport->port.lock, flags);
+ /* Disable Rx & Tx */
+ writeb(0, sport->port.membase + UARTCR2);
+
+ temp = readb(sport->port.membase + UARTPFIFO);
+ /* Enable Rx and Tx FIFO */
+ writeb(temp | UARTPFIFO_RXFE | UARTPFIFO_TXFE,
+ sport->port.membase + UARTPFIFO);
+
+ /* flush Tx and Rx FIFO */
+ writeb(UARTCFIFO_TXFLUSH | UARTCFIFO_RXFLUSH,
+ sport->port.membase + UARTCFIFO);
+
+ /* explicitly clear RDRF */
+ if (readb(sport->port.membase + UARTSR1) & UARTSR1_RDRF) {
+ readb(sport->port.membase + UARTDR);
+ writeb(UARTSFIFO_RXUF, sport->port.membase + UARTSFIFO);
+ }
+
+ writeb(0, sport->port.membase + UARTTWFIFO);
+ writeb(1, sport->port.membase + UARTRWFIFO);
+
+ /* Enable Rx and Tx */
+ writeb(UARTCR2_RE | UARTCR2_TE, sport->port.membase + UARTCR2);
+ spin_unlock_irqrestore(&sport->port.lock, flags);
+
+ return 0;
+}
+
+static void lpuart_poll_put_char(struct uart_port *port, unsigned char c)
+{
+ unsigned int status;
+
+ /* drain */
+ while (!(readb(port->membase + UARTSR1) & UARTSR1_TDRE))
+ barrier();
+
+ writeb(c, port->membase + UARTDR);
+}
+
+static int lpuart_poll_get_char(struct uart_port *port)
+{
+ if (!(readb(port->membase + UARTSR1) & UARTSR1_RDRF))
+ return NO_POLL_CHAR;
+
+ return readb(port->membase + UARTDR);
+}
+
+#endif
+
static inline void lpuart_transmit_buffer(struct lpuart_port *sport)
{
struct circ_buf *xmit = &sport->port.state->xmit;
@@ -1596,6 +1657,11 @@ static const struct uart_ops lpuart_pops = {
.config_port = lpuart_config_port,
.verify_port = lpuart_verify_port,
.flush_buffer = lpuart_flush_buffer,
+#if defined(CONFIG_CONSOLE_POLL)
+ .poll_init = lpuart_poll_init,
+ .poll_get_char = lpuart_poll_get_char,
+ .poll_put_char = lpuart_poll_put_char,
+#endif
};
static const struct uart_ops lpuart32_pops = {
--
2.5.5
^ permalink raw reply related
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