[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8905630a-30dc-4b22-9d6c-fd4af97728bf@sifive.com>
Date: Tue, 17 Oct 2023 12:42:37 -0500
From: Samuel Holland <samuel.holland@...ive.com>
To: Conor Dooley <conor@...nel.org>, Rob Herring <robh@...nel.org>
Cc: shravan chippa <shravan.chippa@...rochip.com>,
green.wan@...ive.com, vkoul@...nel.org,
krzysztof.kozlowski+dt@...aro.org, palmer@...belt.com,
paul.walmsley@...ive.com, conor+dt@...nel.org,
dmaengine@...r.kernel.org, devicetree@...r.kernel.org,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
nagasuresh.relli@...rochip.com, praveen.kumar@...rochip.com,
Conor Dooley <conor.dooley@...rochip.com>
Subject: Re: [PATCH v2 2/4] dt-bindings: dma: sf-pdma: add new compatible name
Hi Conor,
On 2023-10-05 5:54 AM, Conor Dooley wrote:
> On Wed, Oct 04, 2023 at 08:30:21AM -0500, Rob Herring wrote:
>> Any fallback is only useful if an OS only understanding the fallback
>> will work with the h/w. Does this h/w work without the driver changes?
>
> Yes.
> I've been hoping that someone from SiFive would come along, and in
> response to this patchset, tell us _why_ the driver does not make use of
> out-of-order transfers to begin with.
I have raised this question internally. So far I have not seen anything to
suggest we need strictly-ordered transfers either, but I still need to confirm this.
Regards,
Samuel
Powered by blists - more mailing lists