linux-kernel - Re: [PATCH 2.6.19-rc1 full] drivers: add LCD support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 30 Oct 2006 15:11:21 +0100
From:	"Miguel Ojeda" <maxextreme@...il.com>
To:	"Paulo Marques" <pmarques@...popie.com>
Cc:	Franck <vagabon.xyz@...il.com>, akpm@...l.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.19-rc1 full] drivers: add LCD support

On 10/30/06, Paulo Marques <pmarques@...popie.com> wrote:
> It is not *that* bad. If nothing has changed, the driver only pays the
> cost of a 1024 bytes memcmp. Even more, there are no current users for
> anything other than a PC, so I think we shouldn't overdesign at this point.
>

I really can't imagine a smartphone with a PC parallel port ;-)

> >   - All accesses to the device depend on the previous behaviour whereas
> >     write(), read() syscall could be synchrone and easier to use for
> >     fast writing of image sets. Actually the refresh stuff is really
> >     needed only if you mmap the device. And it seems not really used
> >     for now since it was broken on your last patch.
>
> That is not entirely true. If a user-space application misbehaves and
> starts writing faster than what can actually be seen, not having a fixed
> refresh rate means that your CPU will be *very* busy writing garbage
> that the user won't be able to see.
>
> A fixed refresh rate is a maximum CPU usage tunable that prevents
> applications (that are not aware that this is an external slow device)
> to write more than what they should.
>
> This can be improved, however.
>
> We could have the concept of a "dirty" buffer. Any write or nopage call
> would set the dirty flag and set a timer to refresh the display in one
> refresh period from now.
>
> When doing the actual refresh, the "dirty" flag would be cleared and the
> buffer unmapped.
>
> In this case, if nothing was ever written to the display, the CPU usage
> would be _zero_ (as it should), and it would work nicely with dynticks
> and such.
>

Hum, interesting. But what happens if...

1. For example, the userspace app maps the fb (nopage is called, dirty
flag set, timer created), and then the app doesn't use the fb. The
timer will refresh the LCD, without anything new to refresh, so we are
wasting CPU time. After refreshing, the driver clears the dirty flag
and unmap the buffer.

2. After some seconds, the userspace app decides to write the buffer.
As it is not mmaped anymore, it will simply get a segmentation fault,
right? AFAIK nopage() is not called again because we have destroyed
the mmapping information, and Linux can't know what are the nopage()
ops to call to.

3. We mmap the device, timer is created, we start writing to the
buffer, the timer calls our refreshing function but we didn't finish
filling the buffer with our information: The LCD will have only some
of the screen.

And so on, am I right?

Thanks,
       Miguel Ojeda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/