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:	Fri, 27 Oct 2006 20:38:15 +0000
From:	"Miguel Ojeda" <maxextreme@...il.com>
To:	"Franck Bui-Huu" <vagabon.xyz@...il.com>
Cc:	akpm@...l.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.19-rc1 full] drivers: add LCD support

On 10/27/06, Franck Bui-Huu <vagabon.xyz@...il.com> wrote:
> On 10/26/06, Miguel Ojeda <maxextreme@...il.com> wrote:
> > No way. Each controller would have different wirings, pins, in-outs,
> > specifications (...) You will need to code an almost whole new fbdev
> > driver (althought maybe it will be so similar to cfag12864b so you
> > only need to make few little changes, but that is unsure).
> >
>
> that's what I was trying to point out. I was wondering if you could
> make your driver a little more generic so another lcd could use your
> driver as is.
>

Hum... Others LCDs has different pinouts, different timings, different
timings... It would be a really hard work, and maybe the result
wouldn't be good.

I will think about it, but I think it would lead to a really complex
generic driver (something like the fbdev API). Also, we would need
many kinds of LCDs to know what can be a common factor between all of
them, what can't, etc.

Really, I coded 2 drivers. The generic driver is ks0108, which it can
be used with a lot more LCDs drivers. But the cfag12864b driver is
really specific, as all the LCDs are different (as different as the
user (wiring) and the builder (timings, pinout, commands...) wants).
In the other hand, LCD controllers like ks0108 are industry-standard.

> > Well, you were right about mmaping, but you weren't about
> > "info->fix.smem_start". smem_start expects a physical address. RAM
> > addresses can't be mmapped as usual
>
> Sorry I don't understand your last sentence. Can you explain please ?
>

Sorry, I meant: You can't mmap a RAM address using functions like the
usual remap_pfn_range (as such functions doesn't like physical RAM
addresses, they want I/O ports for example, like 0x378). So, you can't
use smem_start. You need to code your own mmap & nopage function. (It
is explained in LDD3 very well).

> --
>                Franck
>
-
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/