On Tue, Apr 20, 2021 at 11:20:19PM +0200, Arnd Bergmann wrote:
> In that case, there should be no problem for you.
>
> The main issue is with system calls and ioctls that contain a misaligned
> struct member like
>
> struct s {
>u32 a;
>u64 b;
> };
>
> Passing this structure by
On Mon, Jun 24, 2019 at 07:13:17PM +, Eugeniy Paltsev wrote:
> Hi Christoph,
>
> Yep I've reviewed and tested it for both cases:
> - coherent/noncoherent dma
> - allocation from atomic_pool/regular allocation
>
> everything works fine for ARC.
Thanks. I've applied the whole series to the
On Fri, Jun 14, 2019 at 06:05:01PM +, Eugeniy Paltsev wrote:
> Hi Christoph,
>
> Regular question - do you have any public git repository with all this dma
> changes?
> I want to test it for ARC.
>
> Pretty sure the
> [PATCH 2/7] arc: remove the partial DMA_ATTR_NON_CONSISTENT support
> is
Btw, can you try wit the very latests dma-mapping-for-next tree
which has a new fix from Thierry Reding that might be related.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Thu, Dec 20, 2018 at 02:39:20PM +, Eugeniy Paltsev wrote:
> > I would be really surprised if that is caused by the patch to add
> > the zeroing.
> Me too :)
>
> > Can you check which commit caused the issue by bisecting
> > from a known good baseline?
>
> Yep. At least kernel build from
On Thu, Dec 20, 2018 at 02:32:52PM +, Eugeniy Paltsev wrote:
> Hi Christoph,
>
> I test kernel from your 'dma-alloc-always-zero' branch, and as
> I can see we have DMA peripherals (like USB) broken.
I would be really surprised if that is caused by the patch to add
the zeroing. Can you check
On Fri, Dec 14, 2018 at 12:12:00PM +, Eugeniy Paltsev wrote:
> Hi Christoph,
>
> do you have any public git repository with all your dma changes?
Most of the tree show up in my misc.git repo for testing.
This series is here:
Btw, given that I assume this is 4.20 material now, any chance we
could merge it through the dma-mapping tree? I have some major changes
pending that would clash if done in a different tree, so I'd rather
get it all together.
> We check this flag in arch_dma_alloc (which are used in non-coherent
On Fri, May 18, 2018 at 10:05:51PM +0200, Helge Deller wrote:
> This patch seems to fix the dma issues I faced on my 32bit B160L parisc box.
>
> So it leaves only one open issue on parisc:
> Now every 32 bit parisc system is unnecessarily non-coherent.
I diagree with those comments, let me
On Fri, May 18, 2018 at 02:49:36PM +, Alexey Brodkin wrote:
> So if we set aside my complaints about direction in
> arch_sync_dma_for_{device|cpu}()...
Many other architectures use the argument. Various of those look bogus,
but for now I want to be able to do straight forward conversions.
On Fri, May 18, 2018 at 01:03:46PM +, Alexey Brodkin wrote:
> Note mmc_get_dma_dir() is just "data->flags & MMC_DATA_WRITE ? DMA_TO_DEVICE
> : DMA_FROM_DEVICE".
> I.e. if we're preparing for sending data dma_noncoherent_map_sg() will have
> DMA_TO_DEVICE which
> is quite OK for passing to
On Thu, Apr 26, 2018 at 08:45:00AM +0200, h...@lst.de wrote:
> On Wed, Apr 25, 2018 at 11:17:01AM +, Alexey Brodkin wrote:
> > Which is actually strange as I would expect ARC code to be built by bots.
>
> I don't think I got any notification. Thank for the fixes!
>
> I
On Wed, Apr 25, 2018 at 11:17:01AM +, Alexey Brodkin wrote:
> Which is actually strange as I would expect ARC code to be built by bots.
I don't think I got any notification. Thank for the fixes!
I think I found the bug, based on the fact that so far all tests for
architectures that also
> > The logical question is why?
>
> 1. See that's another platform with ARC core so maybe in case of ARM
>DMA allocator already zeroes pages regardless provided flags -
>personally I didn't check that.
Yes, most architectures always clear memory returned by dma_alloc*.
Looks like a few
14 matches
Mail list logo
