License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 22:07:57 +08:00
|
|
|
# SPDX-License-Identifier: GPL-2.0
|
2007-02-10 17:44:32 +08:00
|
|
|
#
|
|
|
|
|
# For a description of the syntax of this configuration file,
|
|
|
|
|
# see Documentation/kbuild/kconfig-language.txt.
|
|
|
|
|
#
|
|
|
|
|
# Auxiliary display drivers configuration.
|
|
|
|
|
#
|
|
|
|
|
|
2007-07-16 14:39:26 +08:00
|
|
|
menuconfig AUXDISPLAY
|
|
|
|
|
bool "Auxiliary Display support"
|
2007-08-18 18:56:21 +08:00
|
|
|
---help---
|
|
|
|
|
Say Y here to get to see options for auxiliary display drivers.
|
|
|
|
|
This option alone does not add any kernel code.
|
|
|
|
|
|
|
|
|
|
If you say N, all options in this submenu will be skipped and disabled.
|
2007-07-16 14:39:26 +08:00
|
|
|
|
2009-04-01 06:23:48 +08:00
|
|
|
if AUXDISPLAY
|
2007-02-10 17:44:32 +08:00
|
|
|
|
2017-03-10 22:15:21 +08:00
|
|
|
config HD44780
|
|
|
|
|
tristate "HD44780 Character LCD support"
|
|
|
|
|
depends on GPIOLIB || COMPILE_TEST
|
|
|
|
|
select CHARLCD
|
|
|
|
|
---help---
|
|
|
|
|
Enable support for Character LCDs using a HD44780 controller.
|
|
|
|
|
The LCD is accessible through the /dev/lcd char device (10, 156).
|
|
|
|
|
This code can either be compiled as a module, or linked into the
|
|
|
|
|
kernel and started at boot.
|
|
|
|
|
If you don't understand what all this is about, say N.
|
|
|
|
|
|
2007-02-10 17:44:32 +08:00
|
|
|
config KS0108
|
|
|
|
|
tristate "KS0108 LCD Controller"
|
|
|
|
|
depends on PARPORT_PC
|
|
|
|
|
default n
|
|
|
|
|
---help---
|
|
|
|
|
If you have a LCD controlled by one or more KS0108
|
|
|
|
|
controllers, say Y. You will need also another more specific
|
|
|
|
|
driver for your LCD.
|
|
|
|
|
|
|
|
|
|
Depends on Parallel Port support. If you say Y at
|
|
|
|
|
parport, you will be able to compile this as a module (M)
|
|
|
|
|
and built-in as well (Y).
|
|
|
|
|
|
|
|
|
|
To compile this as a module, choose M here:
|
|
|
|
|
the module will be called ks0108.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config KS0108_PORT
|
|
|
|
|
hex "Parallel port where the LCD is connected"
|
|
|
|
|
depends on KS0108
|
|
|
|
|
default 0x378
|
|
|
|
|
---help---
|
|
|
|
|
The address of the parallel port where the LCD is connected.
|
|
|
|
|
|
|
|
|
|
The first standard parallel port address is 0x378.
|
|
|
|
|
The second standard parallel port address is 0x278.
|
|
|
|
|
The third standard parallel port address is 0x3BC.
|
|
|
|
|
|
|
|
|
|
You can specify a different address if you need.
|
|
|
|
|
|
|
|
|
|
If you don't know what I'm talking about, load the parport module,
|
|
|
|
|
and execute "dmesg" or "cat /proc/ioports". You can see there how
|
|
|
|
|
many parallel ports are present and which address each one has.
|
|
|
|
|
|
|
|
|
|
Usually you only need to use 0x378.
|
|
|
|
|
|
|
|
|
|
If you compile this as a module, you can still override this
|
|
|
|
|
using the module parameters.
|
|
|
|
|
|
|
|
|
|
config KS0108_DELAY
|
|
|
|
|
int "Delay between each control writing (microseconds)"
|
|
|
|
|
depends on KS0108
|
|
|
|
|
default "2"
|
|
|
|
|
---help---
|
|
|
|
|
Amount of time the ks0108 should wait between each control write
|
|
|
|
|
to the parallel port.
|
|
|
|
|
|
2008-07-05 00:59:33 +08:00
|
|
|
If your LCD seems to miss random writings, increment this.
|
2007-02-10 17:44:32 +08:00
|
|
|
|
|
|
|
|
If you don't know what I'm talking about, ignore it.
|
|
|
|
|
|
|
|
|
|
If you compile this as a module, you can still override this
|
|
|
|
|
value using the module parameters.
|
|
|
|
|
|
|
|
|
|
config CFAG12864B
|
|
|
|
|
tristate "CFAG12864B LCD"
|
|
|
|
|
depends on X86
|
|
|
|
|
depends on FB
|
|
|
|
|
depends on KS0108
|
2007-06-01 15:46:45 +08:00
|
|
|
select FB_SYS_FILLRECT
|
|
|
|
|
select FB_SYS_COPYAREA
|
|
|
|
|
select FB_SYS_IMAGEBLIT
|
|
|
|
|
select FB_SYS_FOPS
|
2007-02-10 17:44:32 +08:00
|
|
|
default n
|
|
|
|
|
---help---
|
|
|
|
|
If you have a Crystalfontz 128x64 2-color LCD, cfag12864b Series,
|
|
|
|
|
say Y. You also need the ks0108 LCD Controller driver.
|
|
|
|
|
|
|
|
|
|
For help about how to wire your LCD to the parallel port,
|
|
|
|
|
check Documentation/auxdisplay/cfag12864b
|
|
|
|
|
|
|
|
|
|
Depends on the x86 arch and the framebuffer support.
|
|
|
|
|
|
|
|
|
|
The LCD framebuffer driver can be attached to a console.
|
|
|
|
|
It will work fine. However, you can't attach it to the fbdev driver
|
|
|
|
|
of the xorg server.
|
|
|
|
|
|
|
|
|
|
To compile this as a module, choose M here:
|
|
|
|
|
the modules will be called cfag12864b and cfag12864bfb.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config CFAG12864B_RATE
|
|
|
|
|
int "Refresh rate (hertz)"
|
|
|
|
|
depends on CFAG12864B
|
|
|
|
|
default "20"
|
|
|
|
|
---help---
|
|
|
|
|
Refresh rate of the LCD.
|
|
|
|
|
|
|
|
|
|
As the LCD is not memory mapped, the driver has to make the work by
|
|
|
|
|
software. This means you should be careful setting this value higher.
|
|
|
|
|
If your CPUs are really slow or you feel the system is slowed down,
|
|
|
|
|
decrease the value.
|
|
|
|
|
|
|
|
|
|
Be careful modifying this value to a very high value:
|
|
|
|
|
You can freeze the computer, or the LCD maybe can't draw as fast as you
|
|
|
|
|
are requesting.
|
|
|
|
|
|
|
|
|
|
If you don't know what I'm talking about, ignore it.
|
|
|
|
|
|
|
|
|
|
If you compile this as a module, you can still override this
|
|
|
|
|
value using the module parameters.
|
2007-07-16 14:39:26 +08:00
|
|
|
|
2016-08-26 22:17:49 +08:00
|
|
|
config IMG_ASCII_LCD
|
|
|
|
|
tristate "Imagination Technologies ASCII LCD Display"
|
2017-08-10 16:53:53 +08:00
|
|
|
depends on HAS_IOMEM
|
2018-02-10 22:14:05 +08:00
|
|
|
default y if MIPS_MALTA
|
2018-01-19 04:13:48 +08:00
|
|
|
select MFD_SYSCON
|
2016-08-26 22:17:49 +08:00
|
|
|
help
|
|
|
|
|
Enable this to support the simple ASCII LCD displays found on
|
|
|
|
|
development boards such as the MIPS Boston, MIPS Malta & MIPS SEAD3
|
|
|
|
|
from Imagination Technologies.
|
|
|
|
|
|
2016-11-07 17:56:35 +08:00
|
|
|
config HT16K33
|
|
|
|
|
tristate "Holtek Ht16K33 LED controller with keyscan"
|
|
|
|
|
depends on FB && OF && I2C && INPUT
|
2016-11-30 17:47:39 +08:00
|
|
|
select FB_SYS_FOPS
|
2016-12-27 01:58:34 +08:00
|
|
|
select FB_SYS_FILLRECT
|
|
|
|
|
select FB_SYS_COPYAREA
|
|
|
|
|
select FB_SYS_IMAGEBLIT
|
2016-11-07 17:56:35 +08:00
|
|
|
select INPUT_MATRIXKMAP
|
|
|
|
|
select FB_BACKLIGHT
|
|
|
|
|
help
|
|
|
|
|
Say yes here to add support for Holtek HT16K33, RAM mapping 16*8
|
|
|
|
|
LED controller driver with keyscan.
|
|
|
|
|
|
2017-04-05 01:25:22 +08:00
|
|
|
config ARM_CHARLCD
|
|
|
|
|
bool "ARM Ltd. Character LCD Driver"
|
|
|
|
|
depends on PLAT_VERSATILE
|
|
|
|
|
help
|
|
|
|
|
This is a driver for the character LCD found on the ARM Ltd.
|
|
|
|
|
Versatile and RealView Platform Baseboards. It doesn't do
|
|
|
|
|
very much more than display the text "ARM Linux" on the first
|
|
|
|
|
line and the Linux version on the second line, but that's
|
|
|
|
|
still useful.
|
|
|
|
|
|
2018-03-01 10:33:03 +08:00
|
|
|
endif # AUXDISPLAY
|
|
|
|
|
|
2017-04-05 01:25:21 +08:00
|
|
|
config PANEL
|
|
|
|
|
tristate "Parallel port LCD/Keypad Panel support"
|
|
|
|
|
depends on PARPORT
|
|
|
|
|
select CHARLCD
|
|
|
|
|
---help---
|
|
|
|
|
Say Y here if you have an HD44780 or KS-0074 LCD connected to your
|
|
|
|
|
parallel port. This driver also features 4 and 6-key keypads. The LCD
|
|
|
|
|
is accessible through the /dev/lcd char device (10, 156), and the
|
|
|
|
|
keypad through /dev/keypad (10, 185). This code can either be
|
|
|
|
|
compiled as a module, or linked into the kernel and started at boot.
|
|
|
|
|
If you don't understand what all this is about, say N.
|
|
|
|
|
|
|
|
|
|
if PANEL
|
|
|
|
|
|
|
|
|
|
config PANEL_PARPORT
|
|
|
|
|
int "Default parallel port number (0=LPT1)"
|
|
|
|
|
range 0 255
|
|
|
|
|
default "0"
|
|
|
|
|
---help---
|
|
|
|
|
This is the index of the parallel port the panel is connected to. One
|
|
|
|
|
driver instance only supports one parallel port, so if your keypad
|
|
|
|
|
and LCD are connected to two separate ports, you have to start two
|
|
|
|
|
modules with different arguments. Numbering starts with '0' for LPT1,
|
|
|
|
|
and so on.
|
|
|
|
|
|
|
|
|
|
config PANEL_PROFILE
|
|
|
|
|
int "Default panel profile (0-5, 0=custom)"
|
|
|
|
|
range 0 5
|
|
|
|
|
default "5"
|
|
|
|
|
---help---
|
|
|
|
|
To ease configuration, the driver supports different configuration
|
|
|
|
|
profiles for past and recent wirings. These profiles can also be
|
|
|
|
|
used to define an approximative configuration, completed by a few
|
|
|
|
|
other options. Here are the profiles :
|
|
|
|
|
|
|
|
|
|
0 = custom (see further)
|
|
|
|
|
1 = 2x16 parallel LCD, old keypad
|
|
|
|
|
2 = 2x16 serial LCD (KS-0074), new keypad
|
|
|
|
|
3 = 2x16 parallel LCD (Hantronix), no keypad
|
|
|
|
|
4 = 2x16 parallel LCD (Nexcom NSA1045) with Nexcom's keypad
|
|
|
|
|
5 = 2x40 parallel LCD (old one), with old keypad
|
|
|
|
|
|
|
|
|
|
Custom configurations allow you to define how your display is
|
|
|
|
|
wired to the parallel port, and how it works. This is only intended
|
|
|
|
|
for experts.
|
|
|
|
|
|
|
|
|
|
config PANEL_KEYPAD
|
|
|
|
|
depends on PANEL_PROFILE="0"
|
|
|
|
|
int "Keypad type (0=none, 1=old 6 keys, 2=new 6 keys, 3=Nexcom 4 keys)"
|
|
|
|
|
range 0 3
|
|
|
|
|
default 0
|
|
|
|
|
---help---
|
|
|
|
|
This enables and configures a keypad connected to the parallel port.
|
|
|
|
|
The keys will be read from character device 10,185. Valid values are :
|
|
|
|
|
|
|
|
|
|
0 : do not enable this driver
|
|
|
|
|
1 : old 6 keys keypad
|
|
|
|
|
2 : new 6 keys keypad, as used on the server at www.ant-computing.com
|
|
|
|
|
3 : Nexcom NSA1045's 4 keys keypad
|
|
|
|
|
|
|
|
|
|
New profiles can be described in the driver source. The driver also
|
|
|
|
|
supports simultaneous keys pressed when the keypad supports them.
|
|
|
|
|
|
|
|
|
|
config PANEL_LCD
|
|
|
|
|
depends on PANEL_PROFILE="0"
|
|
|
|
|
int "LCD type (0=none, 1=custom, 2=old //, 3=ks0074, 4=hantronix, 5=Nexcom)"
|
|
|
|
|
range 0 5
|
|
|
|
|
default 0
|
|
|
|
|
---help---
|
|
|
|
|
This enables and configures an LCD connected to the parallel port.
|
|
|
|
|
The driver includes an interpreter for escape codes starting with
|
|
|
|
|
'\e[L' which are specific to the LCD, and a few ANSI codes. The
|
|
|
|
|
driver will be registered as character device 10,156, usually
|
|
|
|
|
under the name '/dev/lcd'. There are a total of 6 supported types :
|
|
|
|
|
|
|
|
|
|
0 : do not enable the driver
|
|
|
|
|
1 : custom configuration and wiring (see further)
|
|
|
|
|
2 : 2x16 & 2x40 parallel LCD (old wiring)
|
|
|
|
|
3 : 2x16 serial LCD (KS-0074 based)
|
|
|
|
|
4 : 2x16 parallel LCD (Hantronix wiring)
|
|
|
|
|
5 : 2x16 parallel LCD (Nexcom wiring)
|
|
|
|
|
|
|
|
|
|
When type '1' is specified, other options will appear to configure
|
|
|
|
|
more precise aspects (wiring, dimensions, protocol, ...). Please note
|
|
|
|
|
that those values changed from the 2.4 driver for better consistency.
|
|
|
|
|
|
|
|
|
|
config PANEL_LCD_HEIGHT
|
|
|
|
|
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
|
|
|
|
|
int "Number of lines on the LCD (1-2)"
|
|
|
|
|
range 1 2
|
|
|
|
|
default 2
|
|
|
|
|
---help---
|
|
|
|
|
This is the number of visible character lines on the LCD in custom profile.
|
|
|
|
|
It can either be 1 or 2.
|
|
|
|
|
|
|
|
|
|
config PANEL_LCD_WIDTH
|
|
|
|
|
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
|
|
|
|
|
int "Number of characters per line on the LCD (1-40)"
|
|
|
|
|
range 1 40
|
|
|
|
|
default 40
|
|
|
|
|
---help---
|
|
|
|
|
This is the number of characters per line on the LCD in custom profile.
|
|
|
|
|
Common values are 16,20,24,40.
|
|
|
|
|
|
|
|
|
|
config PANEL_LCD_BWIDTH
|
|
|
|
|
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
|
|
|
|
|
int "Internal LCD line width (1-40, 40 by default)"
|
|
|
|
|
range 1 40
|
|
|
|
|
default 40
|
|
|
|
|
---help---
|
|
|
|
|
Most LCDs use a standard controller which supports hardware lines of 40
|
|
|
|
|
characters, although sometimes only 16, 20 or 24 of them are really wired
|
|
|
|
|
to the terminal. This results in some non-visible but addressable characters,
|
|
|
|
|
and is the case for most parallel LCDs. Other LCDs, and some serial ones,
|
|
|
|
|
however, use the same line width internally as what is visible. The KS0074
|
|
|
|
|
for example, uses 16 characters per line for 16 visible characters per line.
|
|
|
|
|
|
|
|
|
|
This option lets you configure the value used by your LCD in 'custom' profile.
|
|
|
|
|
If you don't know, put '40' here.
|
|
|
|
|
|
|
|
|
|
config PANEL_LCD_HWIDTH
|
|
|
|
|
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
|
|
|
|
|
int "Hardware LCD line width (1-64, 64 by default)"
|
|
|
|
|
range 1 64
|
|
|
|
|
default 64
|
|
|
|
|
---help---
|
|
|
|
|
Most LCDs use a single address bit to differentiate line 0 and line 1. Since
|
|
|
|
|
some of them need to be able to address 40 chars with the lower bits, they
|
|
|
|
|
often use the immediately superior power of 2, which is 64, to address the
|
|
|
|
|
next line.
|
|
|
|
|
|
|
|
|
|
If you don't know what your LCD uses, in doubt let 16 here for a 2x16, and
|
|
|
|
|
64 here for a 2x40.
|
|
|
|
|
|
|
|
|
|
config PANEL_LCD_CHARSET
|
|
|
|
|
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
|
|
|
|
|
int "LCD character set (0=normal, 1=KS0074)"
|
|
|
|
|
range 0 1
|
|
|
|
|
default 0
|
|
|
|
|
---help---
|
|
|
|
|
Some controllers such as the KS0074 use a somewhat strange character set
|
|
|
|
|
where many symbols are at unusual places. The driver knows how to map
|
|
|
|
|
'standard' ASCII characters to the character sets used by these controllers.
|
|
|
|
|
Valid values are :
|
|
|
|
|
|
|
|
|
|
0 : normal (untranslated) character set
|
|
|
|
|
1 : KS0074 character set
|
|
|
|
|
|
|
|
|
|
If you don't know, use the normal one (0).
|
|
|
|
|
|
|
|
|
|
config PANEL_LCD_PROTO
|
|
|
|
|
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
|
|
|
|
|
int "LCD communication mode (0=parallel 8 bits, 1=serial)"
|
|
|
|
|
range 0 1
|
|
|
|
|
default 0
|
|
|
|
|
---help---
|
|
|
|
|
This driver now supports any serial or parallel LCD wired to a parallel
|
|
|
|
|
port. But before assigning signals, the driver needs to know if it will
|
|
|
|
|
be driving a serial LCD or a parallel one. Serial LCDs only use 2 wires
|
|
|
|
|
(SDA/SCL), while parallel ones use 2 or 3 wires for the control signals
|
|
|
|
|
(E, RS, sometimes RW), and 4 or 8 for the data. Use 0 here for a 8 bits
|
|
|
|
|
parallel LCD, and 1 for a serial LCD.
|
|
|
|
|
|
|
|
|
|
config PANEL_LCD_PIN_E
|
|
|
|
|
depends on PANEL_PROFILE="0" && PANEL_LCD="1" && PANEL_LCD_PROTO="0"
|
|
|
|
|
int "Parallel port pin number & polarity connected to the LCD E signal (-17...17) "
|
|
|
|
|
range -17 17
|
|
|
|
|
default 14
|
|
|
|
|
---help---
|
|
|
|
|
This describes the number of the parallel port pin to which the LCD 'E'
|
|
|
|
|
signal has been connected. It can be :
|
|
|
|
|
|
|
|
|
|
0 : no connection (eg: connected to ground)
|
|
|
|
|
1..17 : directly connected to any of these pins on the DB25 plug
|
|
|
|
|
-1..-17 : connected to the same pin through an inverter (eg: transistor).
|
|
|
|
|
|
|
|
|
|
Default for the 'E' pin in custom profile is '14' (AUTOFEED).
|
|
|
|
|
|
|
|
|
|
config PANEL_LCD_PIN_RS
|
|
|
|
|
depends on PANEL_PROFILE="0" && PANEL_LCD="1" && PANEL_LCD_PROTO="0"
|
|
|
|
|
int "Parallel port pin number & polarity connected to the LCD RS signal (-17...17) "
|
|
|
|
|
range -17 17
|
|
|
|
|
default 17
|
|
|
|
|
---help---
|
|
|
|
|
This describes the number of the parallel port pin to which the LCD 'RS'
|
|
|
|
|
signal has been connected. It can be :
|
|
|
|
|
|
|
|
|
|
0 : no connection (eg: connected to ground)
|
|
|
|
|
1..17 : directly connected to any of these pins on the DB25 plug
|
|
|
|
|
-1..-17 : connected to the same pin through an inverter (eg: transistor).
|
|
|
|
|
|
|
|
|
|
Default for the 'RS' pin in custom profile is '17' (SELECT IN).
|
|
|
|
|
|
|
|
|
|
config PANEL_LCD_PIN_RW
|
|
|
|
|
depends on PANEL_PROFILE="0" && PANEL_LCD="1" && PANEL_LCD_PROTO="0"
|
|
|
|
|
int "Parallel port pin number & polarity connected to the LCD RW signal (-17...17) "
|
|
|
|
|
range -17 17
|
|
|
|
|
default 16
|
|
|
|
|
---help---
|
|
|
|
|
This describes the number of the parallel port pin to which the LCD 'RW'
|
|
|
|
|
signal has been connected. It can be :
|
|
|
|
|
|
|
|
|
|
0 : no connection (eg: connected to ground)
|
|
|
|
|
1..17 : directly connected to any of these pins on the DB25 plug
|
|
|
|
|
-1..-17 : connected to the same pin through an inverter (eg: transistor).
|
|
|
|
|
|
|
|
|
|
Default for the 'RW' pin in custom profile is '16' (INIT).
|
|
|
|
|
|
|
|
|
|
config PANEL_LCD_PIN_SCL
|
|
|
|
|
depends on PANEL_PROFILE="0" && PANEL_LCD="1" && PANEL_LCD_PROTO!="0"
|
|
|
|
|
int "Parallel port pin number & polarity connected to the LCD SCL signal (-17...17) "
|
|
|
|
|
range -17 17
|
|
|
|
|
default 1
|
|
|
|
|
---help---
|
|
|
|
|
This describes the number of the parallel port pin to which the serial
|
|
|
|
|
LCD 'SCL' signal has been connected. It can be :
|
|
|
|
|
|
|
|
|
|
0 : no connection (eg: connected to ground)
|
|
|
|
|
1..17 : directly connected to any of these pins on the DB25 plug
|
|
|
|
|
-1..-17 : connected to the same pin through an inverter (eg: transistor).
|
|
|
|
|
|
|
|
|
|
Default for the 'SCL' pin in custom profile is '1' (STROBE).
|
|
|
|
|
|
|
|
|
|
config PANEL_LCD_PIN_SDA
|
|
|
|
|
depends on PANEL_PROFILE="0" && PANEL_LCD="1" && PANEL_LCD_PROTO!="0"
|
|
|
|
|
int "Parallel port pin number & polarity connected to the LCD SDA signal (-17...17) "
|
|
|
|
|
range -17 17
|
|
|
|
|
default 2
|
|
|
|
|
---help---
|
|
|
|
|
This describes the number of the parallel port pin to which the serial
|
|
|
|
|
LCD 'SDA' signal has been connected. It can be :
|
|
|
|
|
|
|
|
|
|
0 : no connection (eg: connected to ground)
|
|
|
|
|
1..17 : directly connected to any of these pins on the DB25 plug
|
|
|
|
|
-1..-17 : connected to the same pin through an inverter (eg: transistor).
|
|
|
|
|
|
|
|
|
|
Default for the 'SDA' pin in custom profile is '2' (D0).
|
|
|
|
|
|
|
|
|
|
config PANEL_LCD_PIN_BL
|
|
|
|
|
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
|
|
|
|
|
int "Parallel port pin number & polarity connected to the LCD backlight signal (-17...17) "
|
|
|
|
|
range -17 17
|
|
|
|
|
default 0
|
|
|
|
|
---help---
|
|
|
|
|
This describes the number of the parallel port pin to which the LCD 'BL' signal
|
|
|
|
|
has been connected. It can be :
|
|
|
|
|
|
|
|
|
|
0 : no connection (eg: connected to ground)
|
|
|
|
|
1..17 : directly connected to any of these pins on the DB25 plug
|
|
|
|
|
-1..-17 : connected to the same pin through an inverter (eg: transistor).
|
|
|
|
|
|
|
|
|
|
Default for the 'BL' pin in custom profile is '0' (uncontrolled).
|
|
|
|
|
|
|
|
|
|
config PANEL_CHANGE_MESSAGE
|
|
|
|
|
bool "Change LCD initialization message ?"
|
|
|
|
|
default "n"
|
|
|
|
|
---help---
|
|
|
|
|
This allows you to replace the boot message indicating the kernel version
|
|
|
|
|
and the driver version with a custom message. This is useful on appliances
|
|
|
|
|
where a simple 'Starting system' message can be enough to stop a customer
|
|
|
|
|
from worrying.
|
|
|
|
|
|
|
|
|
|
If you say 'Y' here, you'll be able to choose a message yourself. Otherwise,
|
|
|
|
|
say 'N' and keep the default message with the version.
|
|
|
|
|
|
|
|
|
|
config PANEL_BOOT_MESSAGE
|
|
|
|
|
depends on PANEL_CHANGE_MESSAGE="y"
|
|
|
|
|
string "New initialization message"
|
|
|
|
|
default ""
|
|
|
|
|
---help---
|
|
|
|
|
This allows you to replace the boot message indicating the kernel version
|
|
|
|
|
and the driver version with a custom message. This is useful on appliances
|
|
|
|
|
where a simple 'Starting system' message can be enough to stop a customer
|
|
|
|
|
from worrying.
|
|
|
|
|
|
|
|
|
|
An empty message will only clear the display at driver init time. Any other
|
|
|
|
|
printf()-formatted message is valid with newline and escape codes.
|
|
|
|
|
|
|
|
|
|
endif # PANEL
|
2018-03-01 10:33:03 +08:00
|
|
|
|
|
|
|
|
config CHARLCD
|
|
|
|
|
tristate "Character LCD core support" if COMPILE_TEST
|