From: grygorii.strashko@ti•com (Grygorii Strashko)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v2 2/7] of: introduce of_dma_get_range() helper
Date: Tue, 22 Apr 2014 17:56:31 +0300 [thread overview]
Message-ID: <5356831F.40006@ti.com> (raw)
In-Reply-To: <CAL_Jsq+9dZiAndnbC3fZDjZWU90K4BBR=ckuDxfy5_mBcRL=nA@mail.gmail.com>
Hi Rob,
On 04/21/2014 06:29 PM, Rob Herring wrote:
> On Sat, Apr 19, 2014 at 9:32 AM, Santosh Shilimkar
> <santosh.shilimkar@ti•com> wrote:
>> From: Grygorii Strashko <grygorii.strashko@ti•com>
>>
>> The of_dma_get_range() allows to find "dma-range" property for
>> the specified device and parse it.
>> dma-ranges format:
>> DMA addr (dma_addr) : naddr cells
>> CPU addr (phys_addr_t) : pna cells
>> size : nsize cells
>>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation•org>
>> Cc: Russell King <linux@arm•linux.org.uk>
>> Cc: Arnd Bergmann <arnd@arndb•de>
>> Cc: Olof Johansson <olof@lixom•net>
>> Cc: Grant Likely <grant.likely@linaro•org>
>> Cc: Rob Herring <robh+dt@kernel•org>
>> Cc: Catalin Marinas <catalin.marinas@arm•com>
>> Cc: Linus Walleij <linus.walleij@linaro•org>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti•com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti•com>
>> ---
>> drivers/of/platform.c | 85 +++++++++++++++++++++++++++++++++++++++++++
>> include/linux/of_platform.h | 8 ++++
>
> This belongs in drivers/of/address.c and of_address.h.
>
>> 2 files changed, 93 insertions(+)
>>
>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>> index 404d1da..2265a55 100644
>> --- a/drivers/of/platform.c
>> +++ b/drivers/of/platform.c
>> @@ -485,4 +485,89 @@ int of_platform_populate(struct device_node *root,
>> return rc;
>> }
>> EXPORT_SYMBOL_GPL(of_platform_populate);
>> +
>> +/**
>> + * of_dma_get_range - Get DMA range info
>> + * @np: device node to get DMA range info
>> + * @dma_addr: pointer to store initial DMA address of DMA range
>> + * @paddr: pointer to store initial CPU address of DMA range
>> + * @size: pointer to store size of DMA range
>> + *
>> + * Look in bottom up direction for the first "dma-range" property
>
> dma-ranges
>
>> + * and parse it.
>> + * dma-ranges format:
>> + * DMA addr (dma_addr) : naddr cells
>> + * CPU addr (phys_addr_t) : pna cells
>> + * size : nsize cells
>> + *
>> + * It returns -ENODEV if "dma-ranges" property was not found
>> + * for this device in DT.
>> + */
>> +extern int of_dma_get_range(struct device_node *np, dma_addr_t *dma_addr,
>
> drop extern.
>
>> + phys_addr_t *paddr, phys_addr_t *size)
>> +{
>> + struct device_node *node = np;
>> + const u32 *ranges = NULL;
>
> __be32
>
>> + int len, naddr, nsize, pna;
>> + int ret = 0;
>> +
>> + if (!node)
>> + return -EINVAL;
>> +
>> + while (1) {
>> + naddr = of_n_addr_cells(node);
>> + nsize = of_n_size_cells(node);
>> + node = of_get_next_parent(node);
>> + if (!node)
>> + break;
>> +
>> + ranges = of_get_property(node, "dma-ranges", &len);
>> +
>> + /* Ignore empty ranges, they imply no translation required */
>> + if (ranges && len > 0)
>> + break;
>> +
>> + /*
>> + * At least empty ranges has to be defined for parent node if
>> + * DMA is supported
>> + */
>> + if (!ranges)
>> + break;
>
> You need an of_node_put here if you are getting the next parent.
Seems, It's not needed, because of_get_next_parent() does following:
parent = of_node_get(node->parent);
of_node_put(node);
>
>> + }
>> +
>> + if (!ranges) {
>> + pr_debug("%s: no dma-ranges found for node(%s)\n",
>> + __func__, np->full_name);
>> + ret = -ENODEV;
>> + goto out;
>> + }
>> +
>> + len /= sizeof(u32);
>> +
>> + pna = of_n_addr_cells(node);
>> +
>> + /* dma-ranges format:
>> + * DMA addr : naddr cells
>> + * CPU addr : pna cells
>> + * size : nsize cells
>> + */
>> + *dma_addr = of_read_number(ranges, naddr);
>
> You should set this after the following call succeeds.
>
>> + *paddr = of_translate_dma_address(np, ranges);
>
> This is going to search for dma-ranges again, but you have already
> done that. Is there a case that just reading the CPU addr will not
> work? I suppose we could have more than one level of translation. It
> also seems a bit abusive that the DMA address is the ranges property.
> I don't really have a better suggestion though.
I think, We need to keep using of_translate_dma_address(), because
this code intended to be generic and, as result, there is no
guarantee that we will always have one level of translations.
>
>> + if (*paddr == OF_BAD_ADDR) {
>
> As I mentioned, this is potentially a size mismatch.
Thanks for your review.
Regards,
Grygorii
next prev parent reply other threads:[~2014-04-22 14:56 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-19 14:32 [PATCH v2 0/7] of: setup dma parameters using dma-ranges and dma-coherent Santosh Shilimkar
2014-04-19 14:32 ` [PATCH v2 1/7] device: introduce per device dma_pfn_offset Santosh Shilimkar
2014-04-19 14:32 ` [PATCH v2 2/7] of: introduce of_dma_get_range() helper Santosh Shilimkar
2014-04-21 15:29 ` Rob Herring
2014-04-22 14:56 ` Grygorii Strashko [this message]
2014-04-22 4:09 ` Joel Fernandes
2014-04-19 14:32 ` [PATCH v2 3/7] of: introduce of_dma_is_coherent() helper Santosh Shilimkar
2014-04-19 14:32 ` [PATCH v2 4/7] of: configure the platform device dma parameters Santosh Shilimkar
2014-04-21 14:58 ` Rob Herring
2014-04-22 15:09 ` Grygorii Strashko
2014-04-22 14:44 ` Rob Herring
2014-04-22 15:44 ` Grygorii Strashko
2014-04-19 14:32 ` [PATCH v2 5/7] ARM: dma: Use dma_pfn_offset for dma address translation Santosh Shilimkar
2014-04-19 19:43 ` Russell King - ARM Linux
2014-04-21 13:38 ` Santosh Shilimkar
2014-04-19 14:32 ` [PATCH v2 6/7] ARM: dma: implement set_arch_dma_coherent_ops() Santosh Shilimkar
2014-04-19 14:32 ` [PATCH v2 7/7] ARM: mm: use phys_addr_t in __dma_page_[cpu_to_dev/dev_to_cpu] Santosh Shilimkar
2014-04-21 13:39 ` Santosh Shilimkar
2014-04-19 16:25 ` [PATCH v2 0/7] of: setup dma parameters using dma-ranges and dma-coherent Thomas Petazzoni
2014-04-21 13:35 ` Santosh Shilimkar
2014-04-21 18:19 ` Thomas Petazzoni
2014-04-21 19:17 ` Santosh Shilimkar
2014-04-22 14:54 ` Catalin Marinas
2014-04-22 15:02 ` Arnd Bergmann
2014-04-22 15:15 ` Santosh Shilimkar
2014-04-22 15:25 ` Catalin Marinas
2014-04-22 15:30 ` Rob Herring
2014-04-22 16:01 ` Catalin Marinas
2014-04-21 14:37 ` Rob Herring
2014-04-21 15:13 ` Santosh Shilimkar
2014-04-21 15:35 ` Rob Herring
2014-04-21 15:36 ` Santosh Shilimkar
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=5356831F.40006@ti.com \
--to=grygorii.strashko@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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