On Thu, 12 Apr 2018 12:32:54 +0200,
Robin Murphy wrote:
>
> On 12/04/18 09:27, Takashi Iwai wrote:
> > On Thu, 12 Apr 2018 10:19:05 +0200,
> > Takashi Iwai wrote:
> >>
> >> On Thu, 12 Apr 2018 10:03:56 +0200,
> >> Takashi Iwai wrote:
> >>>
> >>> On Thu, 12 Apr 2018 08:02:27 +0200,
> >>> Christoph
On 12/04/18 09:27, Takashi Iwai wrote:
On Thu, 12 Apr 2018 10:19:05 +0200,
Takashi Iwai wrote:
On Thu, 12 Apr 2018 10:03:56 +0200,
Takashi Iwai wrote:
On Thu, 12 Apr 2018 08:02:27 +0200,
Christoph Hellwig wrote:
On Wed, Apr 11, 2018 at 09:28:54AM +0200, Takashi Iwai wrote:
But we should tr
On Thu, 12 Apr 2018 10:19:05 +0200,
Takashi Iwai wrote:
>
> On Thu, 12 Apr 2018 10:03:56 +0200,
> Takashi Iwai wrote:
> >
> > On Thu, 12 Apr 2018 08:02:27 +0200,
> > Christoph Hellwig wrote:
> > >
> > > On Wed, Apr 11, 2018 at 09:28:54AM +0200, Takashi Iwai wrote:
> > > > > But we should try a G
On Thu, 12 Apr 2018 10:03:56 +0200,
Takashi Iwai wrote:
>
> On Thu, 12 Apr 2018 08:02:27 +0200,
> Christoph Hellwig wrote:
> >
> > On Wed, Apr 11, 2018 at 09:28:54AM +0200, Takashi Iwai wrote:
> > > > But we should try a GFP_DMA32 allocation first, so this is a bit
> > > > surprising.
> > >
> >
On Thu, 12 Apr 2018 08:02:27 +0200,
Christoph Hellwig wrote:
>
> On Wed, Apr 11, 2018 at 09:28:54AM +0200, Takashi Iwai wrote:
> > > But we should try a GFP_DMA32 allocation first, so this is a bit
> > > surprising.
> >
> > Hm, do we really try that?
> > Through a quick glance, dma_alloc_coherent
On Wed, Apr 11, 2018 at 09:28:54AM +0200, Takashi Iwai wrote:
> > But we should try a GFP_DMA32 allocation first, so this is a bit
> > surprising.
>
> Hm, do we really try that?
> Through a quick glance, dma_alloc_coherent_gfp_flags() gives GFP_DMA32
> only when coherent mask <= DMA_BIT_MASK(32);
On Tue, 10 Apr 2018 20:10:20 +0200,
Christoph Hellwig wrote:
>
> On Tue, Apr 10, 2018 at 06:50:04PM +0100, Robin Murphy wrote:
> > In the first one, the machine appears to have enough RAM that most of it is
> > beyond the device's 36-bit DMA mask, thus it's fairly likely for the
> > initial dire
On Tue, Apr 10, 2018 at 06:50:04PM +0100, Robin Murphy wrote:
> In the first one, the machine appears to have enough RAM that most of it is
> beyond the device's 36-bit DMA mask, thus it's fairly likely for the
> initial direct alloc to come back with something unsuitable.
But we should try a GF
On 10/04/18 18:07, Takashi Iwai wrote:
On Tue, 10 Apr 2018 19:06:15 +0200,
Christoph Hellwig wrote:
On Tue, Apr 10, 2018 at 07:05:13PM +0200, Takashi Iwai wrote:
The code refactoring by commit 0176adb00406 ("swiotlb: refactor
coherent buffer allocation") made swiotlb_alloc_buffer() almost alwa
On Tue, 10 Apr 2018 19:06:15 +0200,
Christoph Hellwig wrote:
>
> On Tue, Apr 10, 2018 at 07:05:13PM +0200, Takashi Iwai wrote:
> > The code refactoring by commit 0176adb00406 ("swiotlb: refactor
> > coherent buffer allocation") made swiotlb_alloc_buffer() almost always
> > failing due to a thinko:
The code refactoring by commit 0176adb00406 ("swiotlb: refactor
coherent buffer allocation") made swiotlb_alloc_buffer() almost always
failing due to a thinko: namely, the function evaluates the
dma_coherent_ok() call incorrectly and dealing as if it's invalid.
This ends up with weird errors like i
On Tue, Apr 10, 2018 at 07:05:13PM +0200, Takashi Iwai wrote:
> The code refactoring by commit 0176adb00406 ("swiotlb: refactor
> coherent buffer allocation") made swiotlb_alloc_buffer() almost always
> failing due to a thinko: namely, the function evaluates the
> dma_coherent_ok() call incorrectly
12 matches
Mail list logo
