linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-mips@vger.kernel.org, "Rafał Miłecki" <rafal@milecki.pl>,
	"Linus Walleij" <linus.walleij@linaro.org>
Subject: Re: [PATCH] bcma: get SoC device struct & assign dma_mask
Date: Mon, 10 Jan 2022 10:13:08 -0800	[thread overview]
Message-ID: <bcae2722-c2c5-5cb9-805e-8e8a06bccd2a@gmail.com> (raw)
In-Reply-To: <20220110090955.GA7422@lst.de>

On 1/10/22 1:09 AM, Christoph Hellwig wrote:
> On Thu, Jan 06, 2022 at 08:17:44PM -0800, Florian Fainelli wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>>
>> For bus devices to be fully usable it's required to set their DMA
>> parameters.
>>
>> For years it has been missing and remained unnoticed because of
>> mips_dma_alloc_coherent() silently handling the empty coherent_dma_mask.
>> Kernel 4.19 came with a lot of DMA changes and caused a regression on
>> the bcm47xx. Starting with the commit f8c55dc6e828 ("MIPS: use generic
>> dma noncoherent ops for simple noncoherent platforms") DMA coherent
>> allocations just fail. Example:
>> [    1.114914] bgmac_bcma bcma0:2: Allocation of TX ring 0x200 failed
>> [    1.121215] bgmac_bcma bcma0:2: Unable to alloc memory for DMA
>> [    1.127626] bgmac_bcma: probe of bcma0:2 failed with error -12
>> [    1.133838] bgmac_bcma: Broadcom 47xx GBit MAC driver loaded
>>
>> This change fixes above regression in addition to the MIPS bcm47xx
>> commit 321c46b91550 ("MIPS: BCM47XX: Setup struct device for the SoC").
> 
> How did it take so long to notice this?
> 
>> I don't know if this is what you had in mind. I am also not sure if we
>> should have the bcma_bus_type implement .dma_configure and set it to
>> platform_dma_configure?
> 
> Unless you have an OF tree that declares DMA limitations there is no
> need to call platform_dma_configure.

OK, so we may have to implement that callback then because on ARM-based
Devices we have BCMA plus Device Tree being used. Although none of those
ARM platforms define any DMA apertures or restrictions, I suppose

> 
>> --- a/drivers/bcma/host_soc.c
>> +++ b/drivers/bcma/host_soc.c
>> @@ -191,6 +191,8 @@ int __init bcma_host_soc_init(struct bcma_soc *soc)
>>  	struct bcma_bus *bus = &soc->bus;
>>  	int err;
>>  
>> +	bus->dev = soc->dev;
>> +
>>  	/* Scan bus and initialize it */
>>  	err = bcma_bus_early_register(bus);
>>  	if (err)
>> diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
>> index 8e7ca3e4c8c4..6793c2ff60fd 100644
>> --- a/drivers/bcma/main.c
>> +++ b/drivers/bcma/main.c
>> @@ -253,6 +253,8 @@ void bcma_prepare_core(struct bcma_bus *bus, struct bcma_device *core)
>>  		if (IS_ENABLED(CONFIG_OF) && bus->dev) {
>>  			core->dma_dev = bus->dev;
>>  		} else {
>> +			if (!core->dev.coherent_dma_mask)
>> +				core->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> 
> Is there any way coherent_dma_mask could already be set here?

On MIPS-based devices (not using Device Tree), I don't see a way this
could be set, however on ARM based devices, since they use Device Tree,
maybe this value could be different than 0. I will run some tests on
both types of devices and post an updated patch if relevant.

Thanks!

> 
>>  			core->dev.dma_mask = &core->dev.coherent_dma_mask;
>>  			core->dma_dev = &core->dev;
> 
> Not really needed for the quick fix, but pointing the dma_mask to the
> coherent_dma_mask is a bad idea as it removes the often used feature
> to use a different mask for the cohernent allocations vs the streaming
> mappings.

OK.
-- 
Florian

      parent reply	other threads:[~2022-01-10 18:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-07  4:17 [PATCH] bcma: get SoC device struct & assign dma_mask Florian Fainelli
2022-01-10  9:09 ` Christoph Hellwig
2022-01-10  9:20   ` Rafał Miłecki
2022-01-10 18:13   ` Florian Fainelli [this message]

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=bcae2722-c2c5-5cb9-805e-8e8a06bccd2a@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=hch@lst.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=rafal@milecki.pl \
    /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).