From: Vinod Koul <vinod.koul@intel.com>
To: "Horia Geantă" <horia.geanta@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
Dan Douglass <dan.douglass@nxp.com>,
Shawn Guo <shawnguo@kernel.org>, Radu Alexe <radu.alexe@nxp.com>,
dmaengine@vger.kernel.org, linux-crypto@vger.kernel.org,
devicetree@vger.kernel.org,
Tudor Ambarus <tudor-dan.ambarus@nxp.com>,
Rajiv Vishwakarma <rajiv.vishwakarma@nxp.com>
Subject: Re: [PATCH RESEND 4/4] dma: caam: add dma memcpy driver
Date: Tue, 31 Oct 2017 17:34:23 +0530 [thread overview]
Message-ID: <20171031120423.GS3187@localhost> (raw)
In-Reply-To: <20171030134654.13729-5-horia.geanta@nxp.com>
On Mon, Oct 30, 2017 at 03:46:54PM +0200, Horia Geantă wrote:
> @@ -600,6 +600,23 @@ config ZX_DMA
> help
> Support the DMA engine for ZTE ZX family platform devices.
>
> +config CRYPTO_DEV_FSL_CAAM_DMA
File is sorted alphabetically
> + tristate "CAAM DMA engine support"
> + depends on CRYPTO_DEV_FSL_CAAM_JR
> + default y
why should it be default?
> --- /dev/null
> +++ b/drivers/dma/caam_dma.c
> @@ -0,0 +1,444 @@
> +/*
> + * caam support for SG DMA
> + *
> + * Copyright 2016 Freescale Semiconductor, Inc
> + * Copyright 2017 NXP
> + */
that is interesting, no license text?
> +
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/interrupt.h>
why do you need this
> +#include <linux/slab.h>
> +#include <linux/debugfs.h>
i didn't see any debugfs code, why do you need this
alphabetical sort pls
> +
> +#include <linux/dmaengine.h>
> +#include "dmaengine.h"
> +
> +#include "../crypto/caam/regs.h"
> +#include "../crypto/caam/jr.h"
> +#include "../crypto/caam/error.h"
> +#include "../crypto/caam/intern.h"
> +#include "../crypto/caam/desc_constr.h"
ah that puts very hard assumptions on locations of the subsystems. Please do
not do that and move the required stuff into common header location in
include/
> +/* This is max chunk size of a DMA transfer. If a buffer is larger than this
> + * value it is internally broken into chunks of max CAAM_DMA_CHUNK_SIZE bytes
> + * and for each chunk a DMA transfer request is issued.
> + * This value is the largest number on 16 bits that is a multiple of 256 bytes
> + * (the largest configurable CAAM DMA burst size).
> + */
Kernel comments style we follow is:
/*
* this is for
* multi line comment
*/
Pls fix this in the file
> +#define CAAM_DMA_CHUNK_SIZE 65280
> +
> +struct caam_dma_sh_desc {
sh?
> +struct caam_dma_ctx {
> + struct dma_chan chan;
> + struct list_head node;
> + struct device *jrdev;
> + struct list_head submit_q;
call it pending
> +static struct dma_device *dma_dev;
> +static struct caam_dma_sh_desc *dma_sh_desc;
> +static LIST_HEAD(dma_ctx_list);
why do you need so many globals?
> +static dma_cookie_t caam_dma_tx_submit(struct dma_async_tx_descriptor *tx)
> +{
> + struct caam_dma_edesc *edesc = NULL;
> + struct caam_dma_ctx *ctx = NULL;
> + dma_cookie_t cookie;
> +
> + edesc = container_of(tx, struct caam_dma_edesc, async_tx);
> + ctx = container_of(tx->chan, struct caam_dma_ctx, chan);
> +
> + spin_lock_bh(&ctx->edesc_lock);
why _bh, i didnt see any irqs or tasklets here which is actually odd, so
what is going on
> +
> + cookie = dma_cookie_assign(tx);
> + list_add_tail(&edesc->node, &ctx->submit_q);
> +
> + spin_unlock_bh(&ctx->edesc_lock);
> +
> + return cookie;
> +}
we have a virtual channel wrapper where we do the same stuff as above, so
consider reusing that
> +static void caam_dma_memcpy_init_job_desc(struct caam_dma_edesc *edesc)
> +{
> + u32 *jd = edesc->jd;
> + u32 *sh_desc = dma_sh_desc->desc;
> + dma_addr_t desc_dma = dma_sh_desc->desc_dma;
> +
> + /* init the job descriptor */
> + init_job_desc_shared(jd, desc_dma, desc_len(sh_desc), HDR_REVERSE);
> +
> + /* set SEQIN PTR */
> + append_seq_in_ptr(jd, edesc->src_dma, edesc->src_len, 0);
> +
> + /* set SEQOUT PTR */
> + append_seq_out_ptr(jd, edesc->dst_dma, edesc->dst_len, 0);
> +
> +#ifdef DEBUG
> + print_hex_dump(KERN_ERR, "caam dma desc@" __stringify(__LINE__) ": ",
> + DUMP_PREFIX_ADDRESS, 16, 4, jd, desc_bytes(jd), 1);
ah this make you compile kernel. Consider the dynamic printk helpers for
printing
> +/* This function can be called in an interrupt context */
> +static void caam_dma_issue_pending(struct dma_chan *chan)
> +{
> + struct caam_dma_ctx *ctx = container_of(chan, struct caam_dma_ctx,
> + chan);
> + struct caam_dma_edesc *edesc, *_edesc;
> +
> + spin_lock_bh(&ctx->edesc_lock);
> + list_for_each_entry_safe(edesc, _edesc, &ctx->submit_q, node) {
> + if (caam_jr_enqueue(ctx->jrdev, edesc->jd,
> + caam_dma_done, edesc) < 0)
what does the caam_jr_enqueue() do?
> +static int caam_dma_jr_chan_bind(void)
> +{
> + struct device *jrdev;
> + struct caam_dma_ctx *ctx;
> + int bonds = 0;
> + int i;
> +
> + for (i = 0; i < caam_jr_driver_probed(); i++) {
> + jrdev = caam_jridx_alloc(i);
> + if (IS_ERR(jrdev)) {
> + pr_err("job ring device %d allocation failed\n", i);
> + continue;
> + }
> +
> + ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> + if (!ctx) {
> + caam_jr_free(jrdev);
> + continue;
you want to continue?
> + dma_dev->dev = dev;
> + dma_dev->residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
> + dma_cap_set(DMA_MEMCPY, dma_dev->cap_mask);
> + dma_cap_set(DMA_PRIVATE, dma_dev->cap_mask);
> + dma_dev->device_tx_status = dma_cookie_status;
> + dma_dev->device_issue_pending = caam_dma_issue_pending;
> + dma_dev->device_prep_dma_memcpy = caam_dma_prep_memcpy;
> + dma_dev->device_free_chan_resources = caam_dma_free_chan_resources;
> +
> + err = dma_async_device_register(dma_dev);
> + if (err) {
> + dev_err(dev, "Failed to register CAAM DMA engine\n");
> + goto jr_bind_err;
> + }
> +
> + dev_info(dev, "caam dma support with %d job rings\n", bonds);
that is very noisy
> +MODULE_LICENSE("Dual BSD/GPL");
> +MODULE_DESCRIPTION("NXP CAAM support for SG DMA");
> +MODULE_AUTHOR("NXP Semiconductors");
No MODULE_ALIAS, how did you load the driver
--
~Vinod
next prev parent reply other threads:[~2017-10-31 12:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-30 13:46 [PATCH RESEND 0/4] add CAAM DMA memcpy driver Horia Geantă
2017-10-30 13:46 ` [PATCH RESEND 1/4] crypto: caam: add caam-dma node to SEC4.0 device tree binding Horia Geantă
[not found] ` <20171030134654.13729-2-horia.geanta-3arQi8VN3Tc@public.gmane.org>
2017-10-30 14:24 ` Kim Phillips
2017-11-09 11:54 ` Radu Andrei Alexe
[not found] ` <VI1PR04MB1325BAD68A7CC8C7A302D9A48A570-mr6QIVyDiCGGEpojCloM0M9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-11-09 16:34 ` Kim Phillips
2017-11-10 8:02 ` Radu Andrei Alexe
2017-11-10 16:44 ` Kim Phillips
2017-11-13 8:32 ` Horia Geantă
2017-11-13 15:21 ` Kim Phillips
2017-11-13 9:44 ` Radu Andrei Alexe
2017-11-13 15:22 ` Kim Phillips
[not found] ` <20171110104430.28b2f56f910b7514d778c4b2-5wv7dgnIgG8@public.gmane.org>
2017-11-16 6:24 ` Vinod Koul
2017-11-16 6:18 ` Vinod Koul
2017-10-30 13:46 ` [PATCH RESEND 2/4] arm64: dts: ls1012a: add caam-dma node Horia Geantă
[not found] ` <20171030134654.13729-1-horia.geanta-3arQi8VN3Tc@public.gmane.org>
2017-10-30 13:46 ` [PATCH RESEND 3/4] crypto: caam: add functionality used by the caam_dma driver Horia Geantă
2017-10-30 13:46 ` [PATCH RESEND 4/4] dma: caam: add dma memcpy driver Horia Geantă
2017-10-31 12:04 ` Vinod Koul [this message]
2017-11-08 14:36 ` Radu Andrei Alexe
[not found] ` <VI1PR04MB1325358D7898120FC0BCEBE88A560-mr6QIVyDiCGGEpojCloM0M9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-11-16 6:11 ` Vinod Koul
[not found] ` <20171030134654.13729-5-horia.geanta-3arQi8VN3Tc@public.gmane.org>
2017-11-02 10:16 ` kbuild test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171031120423.GS3187@localhost \
--to=vinod.koul@intel.com \
--cc=dan.douglass@nxp.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=horia.geanta@nxp.com \
--cc=linux-crypto@vger.kernel.org \
--cc=radu.alexe@nxp.com \
--cc=rajiv.vishwakarma@nxp.com \
--cc=shawnguo@kernel.org \
--cc=tudor-dan.ambarus@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).