On 26 Jan, Andrew Morton wrote:
> arm:
>
> drivers/firewire/fw-device.c: In function `fw_device_init':
> drivers/firewire/fw-device.c:495: warning: implicit declaration of function
> `cmpxchg'
>
>
> We can't use cmpxchg
On Tue, 23 Jan 2007 22:48:15 -0500
"Kristian Høgsberg" <[EMAIL PROTECTED]> wrote:
> I've moved the new FireWire stack to an in-tree git repository and
> moved over the missing patches from my out-of-tree version.
arm:
drivers/firewire/fw-device.c: In function `fw_device_init':
drivers/firewire/f
Robert Crocombe wrote:
On 1/25/07, Pieter Palmers <[EMAIL PROTECTED]> wrote:
I'd like to make one note here:
We should have a way to use smaller DMA buffers than one page size. If I
remember correctly, the page size on my system is 4096 bytes, being 1024
quadlets. If we assume a 4 channel audio
On 1/25/07, Pieter Palmers <[EMAIL PROTECTED]> wrote:
I'd like to make one note here:
We should have a way to use smaller DMA buffers than one page size. If I
remember correctly, the page size on my system is 4096 bytes, being 1024
quadlets. If we assume a 4 channel audio stream, this corresponds
Kristian Høgsberg wrote:
On 1/24/07, Pieter Palmers <[EMAIL PROTECTED]> wrote:
Kristian Høgsberg wrote:
Changes since the merge into the linux1394 tree include:
- gap count optimization
- full bus management
- loopback for async requests to the local node
- a bug fix for a problem exposed
On Wed, 2007-01-24 at 19:30 -0500, Kristian Høgsberg wrote:
> The problem isn't packets that are too big, the problem is we can get
> unexpected / too many empty packets, which will then cause the DMA
> engine to move on to the next descriptor before the payload buffer has
> been completely filled
Kristian Høgsberg wrote:
- Always allocate a page for headers and a page for the payload.
This method would not really be acceptable as a replacement for
video1394, since video buffers can often be many tens of megabytes.
Doubling the space requirement would be a big deal and may cause the
Kristian Høgsberg wrote:
> Hosting this on freedesktop.org should be fine,
> though kernel.org may be more appropriate :)
At the moment, a host outside of kernel.org is actually better for
gitweb lurkers. (But I trust that kernel.org will get up to speed again
soon.)
> Stefan, I'm still not sure
Kristian Høgsberg wrote:
Changes since the merge into the linux1394 tree include:
- gap count optimization
- full bus management
- loopback for async requests to the local node
- a bug fix for a problem exposed by VIA 6306 controllers
- a typo fix from the bitfield -> mask+shift conversion.
9 matches
Mail list logo
