On Wed, May 27, 2009 at 11:00 PM, Sean MacLennan
wrote:
> On Wed, 27 May 2009 21:42:18 -0600
> Grant Likely wrote:
>
>> Make your driver use a platform device or an of_platform device. It's
>> not at all hard.
>
> Here is my first shot any other fields that I need to fill in so I
> don't hav
On Wed, 27 May 2009 21:42:18 -0600
Grant Likely wrote:
> Make your driver use a platform device or an of_platform device. It's
> not at all hard.
Here is my first shot any other fields that I need to fill in so I
don't have any gotchas?
/* This must exist */
static void warp_device_release
On Thu, 2009-05-28 at 00:11 -0400, Sean MacLennan wrote:
> On Thu, 28 May 2009 13:52:29 +1000
> Benjamin Herrenschmidt wrote:
>
> > Can't you set ISA_DMA_THRESHOLD = ~0L from your warp.c platform file ?
>
> I actually set it in the driver proper since it is faster to test, but
> it works. I am j
On Thu, 28 May 2009 13:52:29 +1000
Benjamin Herrenschmidt wrote:
> Can't you set ISA_DMA_THRESHOLD = ~0L from your warp.c platform file ?
I actually set it in the driver proper since it is faster to test, but
it works. I am just wondering how kosher that is.
The advantage of the platform_device
On Wed, 2009-05-27 at 23:34 -0400, Sean MacLennan wrote:
> On Mon, 25 May 2009 14:33:43 +1000
../..
You can just make it a platform device I suppose. In the meantime...
> Maybe set ISA_DMA_THRESHOLD somewhere? Some platforms seem to set it:
>
> ./platforms/52xx/efika.c: ISA_DMA_THRESHOL
On Wed, May 27, 2009 at 9:34 PM, Sean MacLennan wrote:
> On Mon, 25 May 2009 14:33:43 +1000
> Benjamin Herrenschmidt wrote:
>
>> This is going to .30 if nobody hollers. I've done some testing here
>> and it seems to be fine, but more eyes at this stage are much welcome.
>
> Sigh, I didn't get a c
On Mon, 25 May 2009 14:33:43 +1000
Benjamin Herrenschmidt wrote:
> This is going to .30 if nobody hollers. I've done some testing here
> and it seems to be fine, but more eyes at this stage are much welcome.
Sigh, I didn't get a chance to look at this until tonight. I use
__dma_alloc_coherent in
--- El lun, 25/5/09, Benjamin Herrenschmidt escribió:
> (Please, Kumar, have a good look,
> especially my change to FIXMAP_TOP,
> was there any reason it wasn't a constant in the first
> place ?)
>
> This is going to .30 if nobody hollers. I've done some
> testing here
> and it seems to be fine
On Sun, 2009-05-24 at 23:50 -0600, Grant Likely wrote:
> It would also be nice for comprehension if the file move and the
> modification were separate commits. As it is I had to generate the
> diff manually, but I'm not concerned.
Right, I though about that... too late :-) might break it up tomor
On Sun, May 24, 2009 at 10:33 PM, Benjamin Herrenschmidt
wrote:
> This is going to .30 if nobody hollers. I've done some testing here
> and it seems to be fine, but more eyes at this stage are much welcome.
Looks okay to me; but I'm not an expert in this area. Boots fine on
Xilinx Virtex 440 and
(Please, Kumar, have a good look, especially my change to FIXMAP_TOP,
was there any reason it wasn't a constant in the first place ?)
This is going to .30 if nobody hollers. I've done some testing here
and it seems to be fine, but more eyes at this stage are much welcome.
From: Benjamin Herrensch
On Mon, 2009-05-25 at 02:43 +0100, Arnd Bergmann wrote:
> I might be missing too much context here, but can't we make drivers
> that
> need this allocate an uncached memory range at setup time and call
> dma_declare_coherent_memory() on that to make a later
> dma_alloc_coherent()
> succeed without
On Monday 25 May 2009, Benjamin Herrenschmidt wrote:
> Note that I still think the right approach in the long run is to ban the
> consistent allocs from atomic contexts generically in linux, though that
> will be a hard nut to crack.
I might be missing too much context here, but can't we make driv
On Sun, 2009-05-24 at 20:21 +1000, Benjamin Herrenschmidt wrote:
> We need to see if we can get the vmalloc allocator safe for GFP_ATOMIC
> context, might be doable.
>
> As for free, unfortunately, even the old allocator won't help with SMP,
> since that needs to do IPIs for cross TLB invalidates
On Sun, 2009-05-24 at 00:47 -0600, Grant Likely wrote:
> Ilya, any comment on this? Can a fix be made quickly, or should this
> patch be reverted until a more robust version can be crafted?
>
> g.
Nasty...
We need to see if we can get the vmalloc allocator safe for GFP_ATOMIC
context, might be
Ilya, any comment on this? Can a fix be made quickly, or should this
patch be reverted until a more robust version can be crafted?
g.
On Thu, May 21, 2009 at 10:50 AM, Albert Herranz
wrote:
>
> Hello list,
>
> Commit 33f00dcedb0e22cdb156a23632814fc580fcfcf8 seems to have broken DMA
> coherent
Hello list,
Commit 33f00dcedb0e22cdb156a23632814fc580fcfcf8 seems to have broken DMA
coherent allocations for CONFIG_NOT_COHERENT_CACHE platforms.
The problems seem to be that the new __dma_alloc_coherent() and
__dma_free_coherent() implementations:
- don't respect anymore the passed gfp flag
17 matches
Mail list logo
