mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Sascha Hauer <sha@pengutronix.de>
Cc: barebox@lists.infradead.org, lst@pengutronix.de
Subject: Re: [PATCH RFC 09/12] of: populate new device_d::dma_coherent attribute
Date: Thu, 11 Jan 2024 08:05:24 +0100	[thread overview]
Message-ID: <3f24753c-ca82-4a27-97a2-938f4bf0863a@pengutronix.de> (raw)
In-Reply-To: <20230227104116.GL32097@pengutronix.de>

Hello Sascha,

(apologies for the late answer. Device was only debricked recently).

On 27.02.23 11:41, Sascha Hauer wrote:
>> +		coherent = dev_is_dma_coherent(dev);
>> +		if (coherent >= 0)
>> +			printf("DMA Coherent: %s\n", coherent ? "true" : "false");
> 
> '>=' doesn't seem to be quite right here.

Negative error code means here that it's unknown whether device is coherent or not.
I have reworked this for v2 to make dev_is_dma_coherent return a boolean.

>> +	/*! This particular device is dma coherent, even if the
>> +         * architecture supports non-coherent devices.
>> +	 */
>> +#ifdef CONFIG_OF_DMA_COHERENCY
>> +	bool dma_coherent:1;
>> +#endif
> 
> I think this patch could be easier when we add the dma_coherent field
> unconditionally.

There's an overhead to determining coherency from the DT, which I would like to
skip if we don't require that support, because all devices are either coherent
or aren't. This is still the case in v2, but dma_coherent is now defined
unconditionally with a DEV_DMA_COHERENCY_DEFAULT value if no OF walk happens.

>> +static inline int dev_is_dma_coherent(struct device *dev)
>> +{
>> +	if (!dev_of_node(dev))
>> +		return -EINVAL;
>> +
>> +	return __dev_is_dma_coherent(dev);
>> +}
> 
> This should return bool. Either a device is DMA coherent or not.

Or we don't know, but in that case we can fall back to the architecture
default. Fixed in v2.

> 
> You seem to assume that a device is not cache coherent when you don't
> know:
> 
> -       dma_sync_single_for_device(addr, size, dir);
> +       if (dev_is_dma_coherent(dev) <= 0)
> +               dma_sync_single_for_device(addr, size, dir);

Yes, but when printing the attribute in devinfo, I didn't want to print

DMA-Coherent: false

when actually we don't know. For v2, I only print it now when the value
differs from the default for non-OF devices.

> This assumption seems to make sense as an unnecessary cache synchronisation
> shouldn't hurt, right?

It hurts when the device turns out to be coherent. In that case, the device
may have written to the cache and we invalidate the cache thinking that
the device has written to memory. With v2 and dev_is_dma_coherent becoming
a boolean, the code is now much more readable IMO.

Thanks for the review.

Cheers,
Ahmad



> 
> Sascha
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |




  reply	other threads:[~2024-01-11  7:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-21  8:05 [PATCH RFC 00/12] ARM64: layerscape: make LS1046 DMA coherent Ahmad Fatoum
2023-02-21  8:05 ` [PATCH RFC 01/12] usb: dwc3: populate parent of xHCI dev Ahmad Fatoum
2023-02-21  8:05 ` [PATCH RFC 02/12] usb: xhci: pass physical device to DMA API Ahmad Fatoum
2023-02-21  8:05 ` [PATCH RFC 03/12] net: rtl8169: pass physical device for " Ahmad Fatoum
2023-02-21  8:05 ` [PATCH RFC 04/12] firmware: zynqmp-fpga: pass physical device to " Ahmad Fatoum
2023-02-21  8:05 ` [PATCH RFC 05/12] net: designware: eqos: " Ahmad Fatoum
2023-02-21  8:05 ` [PATCH RFC 06/12] x86: select OF_DMA_DEFAULT_COHERENT Ahmad Fatoum
2023-02-21  8:05 ` [PATCH RFC 07/12] dma: define CONFIG_OF_DMA_COHERENCY Ahmad Fatoum
2023-02-21  8:05 ` [PATCH RFC 08/12] RISC-V: StarFive: J7100: set /soc/dma-noncoherent Ahmad Fatoum
2023-02-21  8:05 ` [PATCH RFC 09/12] of: populate new device_d::dma_coherent attribute Ahmad Fatoum
2023-02-27 10:41   ` Sascha Hauer
2024-01-11  7:05     ` Ahmad Fatoum [this message]
2023-02-21  8:05 ` [PATCH RFC 10/12] dma: fix dma_sync when not all device DMA is equally coherent Ahmad Fatoum
2023-02-21  8:05 ` [PATCH RFC 11/12] dma: provide of_dma_coherent_fixup helper Ahmad Fatoum
2023-02-21  8:05 ` [PATCH RFC 12/12] ARM64: layerscape: configure all DMA masters to be cache-coherent Ahmad Fatoum

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=3f24753c-ca82-4a27-97a2-938f4bf0863a@pengutronix.de \
    --to=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=lst@pengutronix.de \
    --cc=sha@pengutronix.de \
    /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