From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: devicetree@vger.kernel.org, vinod.koul@intel.com, jcm@redhat.com,
patches@apm.com, Mayuresh Chitale <mchitale@apm.com>,
ddutile@redhat.com, dmaengine@vger.kernel.org,
dan.j.williams@intel.com
Subject: Re: [PATCH 4/4] dma: X-Gene PCIE DMA Driver
Date: Wed, 07 Jan 2015 09:35:57 +0100 [thread overview]
Message-ID: <4187918.PUaMnn04Vq@wuerfel> (raw)
In-Reply-To: <1420608537-12296-5-git-send-email-mchitale@apm.com>
On Wednesday 07 January 2015 10:58:57 Mayuresh Chitale wrote:
> This patch implements DMA engine API for DMA controller on APM
> X-Gene PCIe controller. DMA engine can support up to 4 channels per port
> and up to 2048 outstanding requests per channel. This is intended
> to be used on ports that are configured in EP mode or to transfer
> data from a RC port that is connected to a X-Gene EP port.
Linux currently does not support PCIe endpoints. Do you plan to submit
a driver for that as well?
> +
> +static void xpdma_setup_dma_dev(struct dma_device *dev)
> +{
> + dma_cap_zero(dev->cap_mask);
> + dma_cap_set(DMA_SLAVE, dev->cap_mask);
> + dma_cap_set(DMA_PRIVATE, dev->cap_mask);
> +
> + dev->device_alloc_chan_resources = xpdma_alloc_chan_resources;
> + dev->device_free_chan_resources = xpdma_free_chan_resources;
> + dev->device_tx_status = xpdma_tx_status;
> + dev->device_issue_pending = xpdma_issue_pending;
> + dev->device_prep_slave_sg = xpdma_prep_slave_sg;
> + dev->device_control = xpdma_device_control;
> +}
You are setting up DMA_SLAVE here but do not use the DT binding
for slave DMA. Can your driver handle slave DMA? If it can,
you should use the appropriate binding, if not then don't
set DMA_SLAVE here.
> +static int xpdma_setup_dma_channel(struct platform_device *pdev,
> + struct xpdma_port *port)
> +{
> + int i, ret = 0;
> + struct xpdma_chan *chan;
> + resource_size_t dma_base;
> +
> + dma_base = MAKE_U64(readl(port->cfg + PORT_CFG_HI), readl(port->cfg)) +
> + CHAN_REG_BASE;
> + port->dma = devm_ioremap(&pdev->dev, dma_base,
> + CHAN_REG_SIZE * MAX_DMA_CHAN);
> + if (port->dma == NULL) {
> + dev_err(&pdev->dev, "Could not get base addressc$\n");
> + return -ENOMEM;
> + }
The registers are not listed in the 'reg' property. Why is that?
You should probably use devm_request_mem_region or devm_ioremap_resource
here to ensure manage the mmio range.
> +static int xpdma_probe(struct platform_device *pdev)
> +{
> + int err;
> + u32 mask;
> + struct resource *res;
> + struct xpdma_port *port;
> +
> + port = devm_kzalloc(&pdev->dev, sizeof(*port), GFP_KERNEL);
> + if (!port)
> + return -ENOMEM;
> +
> + port->dma_dev.dev = &pdev->dev;
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(&pdev->dev, "No cfg resource\n");
> + return -EINVAL;
> + }
> +
> + port->cfg = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> + if (IS_ERR(port->cfg))
> + return PTR_ERR(port->cfg);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + if (!res) {
> + dev_err(&pdev->dev, "No intr resource\n");
> + return -EINVAL;
> + }
from binding, these two register ranges look like they are part of
another device. Which device is that:
+ reg = < 0x0 0x1f2b0154 0x0 0xc
+ 0x0 0x1f2b0058 0x0 0x8>;
Is this some kind of syscon node that contains all sorts of
registers munged together, or is this the same register set that
is used for the channels?
In the former case, better use a syscon reference instead of 'reg'
and use syscon_regmap_lookup_by_phandle to get the regmap, in the
second case, just list the entire registers.
> +
> + xpdma_setup_dma_dev(&port->dma_dev);
> + /* Setup DMA mask - 32 for 32-bit system and 64 for 64-bit system */
> + err = dma_set_mask_and_coherent(&pdev->dev,
> + DMA_BIT_MASK(8*sizeof(void *)));
> + if (err) {
> + dev_err(&pdev->dev, "Unable to set dma mask\n");
> + return err;
> + }
Just use a 64-bit dma-mask all the time, and fall back to a 32-bit
mask if that doesn't work, the dma mask is completely independent
of the word size of the CPU.
You also have to make sure that the parent of the device contains
a proper dma-ranges property that allows a 64-bit mask. We currently
have a bug in the kernel that makes dma_set_mask_and_coherent
always succeed, and we need to fix that so it fails if you have
a 64-bit dma capable device on a 32-bit wide bus.
> +static const struct of_device_id xpdma_match_table[] = {
> + {.compatible = "apm,xgene-pciedma",},
> + {},
> +};
This is a rather generic compatible string. Is this device present
in identical form on all xgene variants?
As xgene is a marketing name and you have now announce the speciifc
model numbers, better use the first model that has this hardware.
Arnd
next prev parent reply other threads:[~2015-01-07 8:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-07 5:28 [PATCH 0/4] APM X-Gene PCIe DMA driver Mayuresh Chitale
2015-01-07 5:28 ` [PATCH 1/4] MAINTAINERS: Add entry for X-Gene PCIE " Mayuresh Chitale
2015-01-07 5:28 ` [PATCH 2/4] Documentation: dt-bindings: Add the binding info for APM X-Gene PCIe " Mayuresh Chitale
2015-01-07 8:30 ` Arnd Bergmann
2015-01-07 10:42 ` Mayuresh Chitale
2015-01-07 5:28 ` [PATCH 3/4] arm64: dts: Add APM X-Gene PCIe DMA device tree nodes Mayuresh Chitale
[not found] ` <1420608537-12296-4-git-send-email-mchitale-qTEPVZfXA3Y@public.gmane.org>
2015-01-07 8:37 ` Arnd Bergmann
2015-01-07 10:45 ` Mayuresh Chitale
[not found] ` <CAL-zptPDU2qoot-aZMDwRmPQ_4QoCsqtQZ=kc-fN-Ts68qrVDQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-07 11:28 ` Arnd Bergmann
2015-01-07 5:28 ` [PATCH 4/4] dma: X-Gene PCIE DMA Driver Mayuresh Chitale
2015-01-07 8:35 ` Arnd Bergmann [this message]
2015-01-07 11:25 ` Mayuresh Chitale
2015-01-07 12:46 ` Arnd Bergmann
2015-01-07 16:05 ` Mayuresh Chitale
2015-01-07 16:22 ` Arnd Bergmann
2015-01-08 6:30 ` Mayuresh Chitale
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=4187918.PUaMnn04Vq@wuerfel \
--to=arnd@arndb.de \
--cc=dan.j.williams@intel.com \
--cc=ddutile@redhat.com \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=jcm@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mchitale@apm.com \
--cc=patches@apm.com \
--cc=vinod.koul@intel.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).