devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Timur Tabi <timur@codeaurora.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, sdharia@codeaurora.org,
	shankerd@codeaurora.org, vikrams@codeaurora.org,
	cov@codeaurora.org, gavidov@codeaurora.org, robh+dt@kernel.org,
	andrew@lunn.ch, bjorn.andersson@linaro.org, mlangsdo@redhat.com,
	jcm@redhat.com, agross@codeaurora.org, davem@davemloft.net,
	f.fainelli@gmail.com
Subject: Re: [PATCH] [v6] net: emac: emac gigabit ethernet controller driver
Date: Wed, 29 Jun 2016 07:17:29 -0500	[thread overview]
Message-ID: <5773BC59.5010404@codeaurora.org> (raw)
In-Reply-To: <5301045.3F9gkJcz60@wuerfel>

Arnd Bergmann wrote:
> On Friday, June 24, 2016 6:46:48 PM CEST Timur Tabi wrote:
>> >+       /* The EMAC itself is capable of 64-bit DMA. If the SOC limits that
>> >+        * range, then we expect platform code to adjust the mask accordingly.
>> >+        */
>> >+       ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
>> >+       if (ret) {
>> >+               dev_err(&pdev->dev, "could not set DMA mask\n");
>> >+               return ret;
>> >+       }
>> >
> The comment does not match the code: if the platform has no IOMMU
> and the bus limit is smaller than the memory, dma_set_mask_and_coherent()
> will fail, and the driver should instead ensure that the buffers are
> allocated from the 32-bit area.
>
> Alternatively, adjust the comment to explain that this is a limitation
> in the driver that can be lifted if necessary.

I'm not sure I understand.  The EMAC hardware is capable of 64-bit DMA. 
  This is true on every platform -- the hardware registers that take bus 
addresses are 64-bit.  The driver itself has no limitations.

And that's what the dma_set_mask_and_coherent() does.  It tells the 
kernel what the device is capable of.

However, on some SOCs, only a subset of those address lines are 
connected to the memory bus.  So for instance, some platforms only have 
32 bits connected.

There's no way for the EMAC driver to know this, so it expects other 
code in the kernel to adjust.  I'm not exactly sure what this code is 
supposed to be, because I get conflicting information.  At one point, I 
thought that the dma-ranges property would handle that.  The kernel 
would parse that property, see that the DMA range is limited to 32 bits, 
and adjust the DMA mask accordingly.  However, with dma-ranges in the 
parent node, I don't see how that can work.

So my question is, how do I handle the situation where a subset of the 
DMA address lines are masked off by the SOC?  I've seen code like this:

ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
if (ret)
	ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));

But this has never made any sense to me.  If DMA_BIT_MASK(64) fails, 
then how can DMA_BIT_MASK(32) succeed?
	
-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.

  reply	other threads:[~2016-06-29 12:17 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-24 23:46 [PATCH] [v6] net: emac: emac gigabit ethernet controller driver Timur Tabi
2016-06-28 20:56 ` Rob Herring
2016-06-29  7:55 ` David Miller
2016-06-29  8:17 ` Arnd Bergmann
2016-06-29 12:17   ` Timur Tabi [this message]
2016-06-29 14:07     ` Arnd Bergmann
2016-06-29 14:33       ` Timur Tabi
2016-06-29 15:04         ` Arnd Bergmann
2016-06-29 15:10           ` Timur Tabi
2016-06-29 15:34             ` Arnd Bergmann
2016-06-29 15:46               ` Timur Tabi
2016-06-29 19:45                 ` Arnd Bergmann
2016-06-29 20:16                   ` Timur Tabi
2016-07-01 13:54                     ` Arnd Bergmann
2016-08-03 21:24                       ` Timur Tabi
2016-08-04  9:21                         ` Arnd Bergmann
2016-08-04 14:24                           ` Timur Tabi
2016-07-03 23:04 ` Lino Sanfilippo
2016-07-28 19:12   ` Timur Tabi
2016-07-30 10:26     ` Lino Sanfilippo
2016-08-02 17:59       ` Timur Tabi
2016-08-03 20:00         ` Timur Tabi

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=5773BC59.5010404@codeaurora.org \
    --to=timur@codeaurora.org \
    --cc=agross@codeaurora.org \
    --cc=andrew@lunn.ch \
    --cc=arnd@arndb.de \
    --cc=bjorn.andersson@linaro.org \
    --cc=cov@codeaurora.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=gavidov@codeaurora.org \
    --cc=jcm@redhat.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=mlangsdo@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sdharia@codeaurora.org \
    --cc=shankerd@codeaurora.org \
    --cc=vikrams@codeaurora.org \
    /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).