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