Re: Raspberry Pi support for Rev-2 & BL
Markus Dolze <[email protected]> Thu, 17 Jan 2013 20:42:29 +0100
| Newsgroups | gmane.comp.sysutils.lcdproc |
|---|---|
| Message-ID | <[email protected]> |
On 15.01.2013 00:50, paul_c wrote:
>
> Hi Markus
>
> On Monday 14 January 2013, Markus Dolze wrote:
>> In the meantime you may receive notice that the revision detection
>> fails on recent models (my revision is 'f'). The line that reads in
>> the revision number should read hex vales ('x' modifier) not
>> integers.
>
> I should have dug in to the kernel sources to check (it is indeed
> printed as a hex value) - It would appear that the "Revision" string is
> common to all ARM boards, and most worryingly, it is a command line
> parameter. In effect, the test can not be relied upon to verify the
> revision. An element of trust on the part of the user is required.. The
> parameter, bcm2708.boardrev, would appear to be passed by the firmware
> on power-on, but it can be overridden in /boot/cmdline.txt.
>
> Could check for /sys/module/bcm2708/parameters/boardrev, but again, we
> would have to trust that the user has not given a false value. At the
> moment, I'm reluctant to rely on the sysfs tree until the Raspberry Pi
> is supported in the mainline kernel (looks like it may be around 3.9.x
> or 3.10.x).
>
> Regards, Paul.
>
Hi,
attached is a version of the driver I will commit if no one has objections.
Changes
=======
* Most important: I renamed the whole thing to be connection type
'raspberrypi'. I prefer this to the mnemonic 'rpi'.
* Build system: The use of __ARMEL__ actually prevented cross-building
on my system. So I replaced it with a custom preprocessor flag.
I think about to making this driver 'always on' as it uses standard
header and functions only. This is subject to change.
* Cosmetic changes: Pass the whole thing through indent, re-organize
comments, re-format driver output messages.
* Remove the getkeypad stub function. There is no need for this.
* Fix the problem in board detection.
* Split the configuration check for the pins and actual enabling them
into two functions (check_pin and setup_gpio). Splitting this make some
error handling/cleanup in init unnecessary.
* Use a programmatic approach for checking for already configured pins.
This also gets rid of the global variable previously used.
* Rename the 'cleanup' function to something used elsewhere.
* Rename the 'enable' pin in struct rpi_gpio_map to just 'en'. This is
more consistent with the other pin names.
* Remove the 'BL' pin from that struct and use 'backlight_bit' which is
already there for exactly that purpose.
* Prefix the _SIZE macros with RPI_ as there was some conflict during
cross-compilation on my system if libusb was enabled.
* Add a note that the pointer to gpio_map is of type (int). Use integer
instead of hex register offsets (if I read hex, I almost automatically
think of bytes, which is incorrect here).
TODO
====
1. There may be a memory leak in setup_io due to the pre-allocation and
alignment of 'gpio_mem'. The recent example code on [1] removed this,
too. Check if we can do the same.
[1] http://elinux.org/Rpi_Low-level_peripherals
2. Check if we can get rid of the global variable 'gpio_map'.
3. End user documentation.
Regards,
Markus
_______________________________________________
LCDproc mailing list
[email protected]
http://lists.omnipotent.net/mailman/listinfo/lcdproc
lcdproc-hd44780_rpi-rev5.zip
(application/zip, 6.2 KB) - not displayed