On 12/22/06, Franck Bui-Huu <[EMAIL PROTECTED]> wrote:
Well thinking more about it, this wouldn't work for all cache types.
For example, if your cache is not a direct maped one, this workaround
won't work. So this is definitely not a portable solution.
From asking peterz on #mm, I think
On 12/22/06, Franck Bui-Huu [EMAIL PROTECTED] wrote:
Well thinking more about it, this wouldn't work for all cache types.
For example, if your cache is not a direct maped one, this workaround
won't work. So this is definitely not a portable solution.
From asking peterz on #mm, I think
On 12/20/06, Franck Bui-Huu <[EMAIL PROTECTED]> wrote:
- when mmaping your frame buffer , be sure that the virtual
address returned by mmap() to the application shares the
same cache lines than the ones the kernel
is using.
Well thinking more about it, this wouldn't work
On 12/20/06, Franck Bui-Huu [EMAIL PROTECTED] wrote:
- when mmaping your frame buffer , be sure that the virtual
address returned by mmap() to the application shares the
same cache lines than the ones the kernel
is using.
Well thinking more about it, this wouldn't work
On 12/17/06, Jaya Kumar <[EMAIL PROTECTED]> wrote:
Ok. I now see what you mean. In typical cases, only one path is used
to write. Meaning an app will decide to use the mmap path or the slow
write path and the kernel only ever reads from its pte entry (unless
fbcon is used which is not suited for
On 12/17/06, Jaya Kumar [EMAIL PROTECTED] wrote:
Ok. I now see what you mean. In typical cases, only one path is used
to write. Meaning an app will decide to use the mmap path or the slow
write path and the kernel only ever reads from its pte entry (unless
fbcon is used which is not suited for
On 12/13/06, Franck Bui-Huu <[EMAIL PROTECTED]> wrote:
On 12/12/06, Jaya Kumar <[EMAIL PROTECTED]> wrote:
> I think that PTEs set up by vmalloc are marked cacheable and via the
> above nopage end up as cacheable. I'm not doing DMA. So the accesses
> are through the cache so I don't think cache
On 12/13/06, Franck Bui-Huu [EMAIL PROTECTED] wrote:
On 12/12/06, Jaya Kumar [EMAIL PROTECTED] wrote:
I think that PTEs set up by vmalloc are marked cacheable and via the
above nopage end up as cacheable. I'm not doing DMA. So the accesses
are through the cache so I don't think cache aliasing
On 12/12/06, Jaya Kumar <[EMAIL PROTECTED]> wrote:
I think that PTEs set up by vmalloc are marked cacheable and via the
above nopage end up as cacheable. I'm not doing DMA. So the accesses
are through the cache so I don't think cache aliasing is an issue for
this case. Please let me know if I
On 12/12/06, Jaya Kumar [EMAIL PROTECTED] wrote:
I think that PTEs set up by vmalloc are marked cacheable and via the
above nopage end up as cacheable. I'm not doing DMA. So the accesses
are through the cache so I don't think cache aliasing is an issue for
this case. Please let me know if I
On 12/11/06, Franck Bui-Huu <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> + atomic_t ref_count;
> + atomic_t vma_count;
what purpose do these counters deserve ?
You are right. I can remove them.
> +
> +void hcb_wait_for_ack(struct hecubafb_par *par)
> +{
> +
> + int
Hi,
[EMAIL PROTECTED] wrote:
> Hi Geert, James, FBdev, MM folk,
>
> Appended is my attempt to support the Hecuba/E-Ink display. I've added
> some code to do deferred IO. This is there in order to hide the latency
> associated with updating the display (500ms to 800ms). The method used
> is to
Hi Geert, James, FBdev, MM folk,
Appended is my attempt to support the Hecuba/E-Ink display. I've added
some code to do deferred IO. This is there in order to hide the latency
associated with updating the display (500ms to 800ms). The method used
is to fake a framebuffer in memory. Then use
Hi Geert, James, FBdev, MM folk,
Appended is my attempt to support the Hecuba/E-Ink display. I've added
some code to do deferred IO. This is there in order to hide the latency
associated with updating the display (500ms to 800ms). The method used
is to fake a framebuffer in memory. Then use
Hi,
[EMAIL PROTECTED] wrote:
Hi Geert, James, FBdev, MM folk,
Appended is my attempt to support the Hecuba/E-Ink display. I've added
some code to do deferred IO. This is there in order to hide the latency
associated with updating the display (500ms to 800ms). The method used
is to fake a
On 12/11/06, Franck Bui-Huu [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
+ atomic_t ref_count;
+ atomic_t vma_count;
what purpose do these counters deserve ?
You are right. I can remove them.
+
+void hcb_wait_for_ack(struct hecubafb_par *par)
+{
+
+ int timeout;
+
16 matches
Mail list logo
