It looks like panel.c belongs to auxdisplay subsystem.
Move it to drivers/auxdisplay folder.
No functional changes intended.
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/auxdisplay/Kconfig | 280 +++++++++++++++++++++++++++++++++++
drivers/auxdisplay/Makefile | 1 +
drivers/{misc => auxdisplay}/panel.c | 0
drivers/misc/Kconfig | 280 -----------------------------------
drivers/misc/Makefile | 1 -
5 files changed, 281 insertions(+), 281 deletions(-)
rename drivers/{misc => auxdisplay}/panel.c (100%)
diff --git a/drivers/auxdisplay/Kconfig b/drivers/auxdisplay/Kconfig
index c317dc515617..ad83a0598c67 100644
--- a/drivers/auxdisplay/Kconfig
+++ b/drivers/auxdisplay/Kconfig
@@ -156,3 +156,283 @@ config HT16K33
LED controller driver with keyscan.
endif # AUXDISPLAY
+
+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 http://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
diff --git a/drivers/auxdisplay/Makefile b/drivers/auxdisplay/Makefile
index fcefa686be0f..58c25e5ece84 100644
--- a/drivers/auxdisplay/Makefile
+++ b/drivers/auxdisplay/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_CFAG12864B) += cfag12864b.o cfag12864bfb.o
obj-$(CONFIG_IMG_ASCII_LCD) += img-ascii-lcd.o
obj-$(CONFIG_HD44780) += hd44780.o
obj-$(CONFIG_HT16K33) += ht16k33.o
+obj-$(CONFIG_PANEL) += panel.o
diff --git a/drivers/misc/panel.c b/drivers/auxdisplay/panel.c
similarity index 100%
rename from drivers/misc/panel.c
rename to drivers/auxdisplay/panel.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index fb933b0b9297..2438466c15ac 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -492,286 +492,6 @@ config VEXPRESS_SYSCFG
bus. System Configuration interface is one of the possible means
of generating transactions on this bus.
-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 http://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
-
config ASPEED_LPC_CTRL
depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 4925ea8e1952..9a9f7e72aa54 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -53,7 +53,6 @@ obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
obj-$(CONFIG_CXL_BASE) += cxl/
-obj-$(CONFIG_PANEL) += panel.o
obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
lkdtm-$(CONFIG_LKDTM) += lkdtm_core.o
--
2.11.0
It looks like arm-charlcd.c belongs to auxdisplay subsystem.
Move it to drivers/auxdisplay folder.
No functional changes intended.
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/auxdisplay/Kconfig | 10 ++++++++++
drivers/auxdisplay/Makefile | 1 +
drivers/{misc => auxdisplay}/arm-charlcd.c | 0
drivers/misc/Kconfig | 10 ----------
drivers/misc/Makefile | 1 -
5 files changed, 11 insertions(+), 11 deletions(-)
rename drivers/{misc => auxdisplay}/arm-charlcd.c (100%)
diff --git a/drivers/auxdisplay/Kconfig b/drivers/auxdisplay/Kconfig
index ad83a0598c67..9ae6681c90ad 100644
--- a/drivers/auxdisplay/Kconfig
+++ b/drivers/auxdisplay/Kconfig
@@ -157,6 +157,16 @@ config HT16K33
endif # AUXDISPLAY
+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.
+
config PANEL
tristate "Parallel port LCD/Keypad Panel support"
depends on PARPORT
diff --git a/drivers/auxdisplay/Makefile b/drivers/auxdisplay/Makefile
index 58c25e5ece84..2b8af3dc5e42 100644
--- a/drivers/auxdisplay/Makefile
+++ b/drivers/auxdisplay/Makefile
@@ -3,6 +3,7 @@
#
obj-$(CONFIG_CHARLCD) += charlcd.o
+obj-$(CONFIG_ARM_CHARLCD) += arm-charlcd.o
obj-$(CONFIG_KS0108) += ks0108.o
obj-$(CONFIG_CFAG12864B) += cfag12864b.o cfag12864bfb.o
obj-$(CONFIG_IMG_ASCII_LCD) += img-ascii-lcd.o
diff --git a/drivers/misc/arm-charlcd.c b/drivers/auxdisplay/arm-charlcd.c
similarity index 100%
rename from drivers/misc/arm-charlcd.c
rename to drivers/auxdisplay/arm-charlcd.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 2438466c15ac..39d1acb27452 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -419,16 +419,6 @@ config VMWARE_BALLOON
To compile this driver as a module, choose M here: the
module will be called vmw_balloon.
-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.
-
config PCH_PHUB
tristate "Intel EG20T PCH/LAPIS Semicon IOH(ML7213/ML7223/ML7831) PHUB"
select GENERIC_NET_UTILS
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 9a9f7e72aa54..4c4d6dc03181 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -37,7 +37,6 @@ obj-y += eeprom/
obj-y += cb710/
obj-$(CONFIG_SPEAR13XX_PCIE_GADGET) += spear13xx_pcie_gadget.o
obj-$(CONFIG_VMWARE_BALLOON) += vmw_balloon.o
-obj-$(CONFIG_ARM_CHARLCD) += arm-charlcd.o
obj-$(CONFIG_PCH_PHUB) += pch_phub.o
obj-y += ti-st/
obj-y += lis3lv02d/
--
2.11.0
Hi Andy,
On Fri, Mar 24, 2017 at 3:06 PM, Andy Shevchenko
<[email protected]> wrote:
> It looks like panel.c belongs to auxdisplay subsystem.
>
> Move it to drivers/auxdisplay folder.
> No functional changes intended.
I didn't move it to drivers/auxdisplay/ because it not only provides
auxdisplay functionality, but also keypad functionality.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Fri, 2017-03-24 at 15:19 +0100, Geert Uytterhoeven wrote:
> Hi Andy,
>
> On Fri, Mar 24, 2017 at 3:06 PM, Andy Shevchenko
> <[email protected]> wrote:
> > It looks like panel.c belongs to auxdisplay subsystem.
> >
> > Move it to drivers/auxdisplay folder.
> > No functional changes intended.
>
> I didn't move it to drivers/auxdisplay/ because it not only provides
> auxdisplay functionality, but also keypad functionality.
Yes, I have noticed this. But keypad functionality is optional while
panel is main one. I think you would agree on this.
--
Andy Shevchenko <[email protected]>
Intel Finland Oy
On Fri, Mar 24, 2017 at 3:06 PM, Andy Shevchenko
<[email protected]> wrote:
> It looks like arm-charlcd.c belongs to auxdisplay subsystem.
>
> Move it to drivers/auxdisplay folder.
> No functional changes intended.
>
> Signed-off-by: Andy Shevchenko <[email protected]>
It does.
Reviewed-by: Linus Walleij <[email protected]>
Yours,
Linus Walleij
Hi Andy,
On Fri, Mar 24, 2017 at 3:29 PM, Andy Shevchenko
<[email protected]> wrote:
> On Fri, 2017-03-24 at 15:19 +0100, Geert Uytterhoeven wrote:
>> On Fri, Mar 24, 2017 at 3:06 PM, Andy Shevchenko
>> <[email protected]> wrote:
>> > It looks like panel.c belongs to auxdisplay subsystem.
>> >
>> > Move it to drivers/auxdisplay folder.
>> > No functional changes intended.
>>
>> I didn't move it to drivers/auxdisplay/ because it not only provides
>> auxdisplay functionality, but also keypad functionality.
>
> Yes, I have noticed this. But keypad functionality is optional while
> panel is main one. I think you would agree on this.
I don't care that much, though. Willy?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Fri, Mar 24, 2017 at 04:19:43PM +0100, Geert Uytterhoeven wrote:
> Hi Andy,
>
> On Fri, Mar 24, 2017 at 3:29 PM, Andy Shevchenko
> <[email protected]> wrote:
> > On Fri, 2017-03-24 at 15:19 +0100, Geert Uytterhoeven wrote:
> >> On Fri, Mar 24, 2017 at 3:06 PM, Andy Shevchenko
> >> <[email protected]> wrote:
> >> > It looks like panel.c belongs to auxdisplay subsystem.
> >> >
> >> > Move it to drivers/auxdisplay folder.
> >> > No functional changes intended.
> >>
> >> I didn't move it to drivers/auxdisplay/ because it not only provides
> >> auxdisplay functionality, but also keypad functionality.
> >
> > Yes, I have noticed this. But keypad functionality is optional while
> > panel is main one. I think you would agree on this.
>
> I don't care that much, though. Willy?
Well, as long as it continues to work, I don't really care either. The
only thing to keep in mind is that it can be difficult to split the
driver in two since in some cases it's possible to use the same lines
for keypad and lcd.
Willy
On Mon, Mar 27, 2017 at 10:11 AM, Willy TARREAU <[email protected]> wrote:
> On Fri, Mar 24, 2017 at 04:19:43PM +0100, Geert Uytterhoeven wrote:
>> On Fri, Mar 24, 2017 at 3:29 PM, Andy Shevchenko
>> <[email protected]> wrote:
>> > On Fri, 2017-03-24 at 15:19 +0100, Geert Uytterhoeven wrote:
>> >> On Fri, Mar 24, 2017 at 3:06 PM, Andy Shevchenko
>> >> <[email protected]> wrote:
>> >> > It looks like panel.c belongs to auxdisplay subsystem.
>> >> >
>> >> > Move it to drivers/auxdisplay folder.
>> >> > No functional changes intended.
>> >>
>> >> I didn't move it to drivers/auxdisplay/ because it not only provides
>> >> auxdisplay functionality, but also keypad functionality.
>> >
>> > Yes, I have noticed this. But keypad functionality is optional while
>> > panel is main one. I think you would agree on this.
>>
>> I don't care that much, though. Willy?
>
> Well, as long as it continues to work, I don't really care either. The
> only thing to keep in mind is that it can be difficult to split the
> driver in two since in some cases it's possible to use the same lines
> for keypad and lcd.
Ideally, it should be replaced by a glue driver using charlcd, matrix-keypad,
and (still to be written?) gpio-parport ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Mon, Mar 27, 2017 at 10:26:07AM +0200, Geert Uytterhoeven wrote:
> On Mon, Mar 27, 2017 at 10:11 AM, Willy TARREAU <[email protected]> wrote:
> > On Fri, Mar 24, 2017 at 04:19:43PM +0100, Geert Uytterhoeven wrote:
> >> On Fri, Mar 24, 2017 at 3:29 PM, Andy Shevchenko
> >> <[email protected]> wrote:
> >> > On Fri, 2017-03-24 at 15:19 +0100, Geert Uytterhoeven wrote:
> >> >> On Fri, Mar 24, 2017 at 3:06 PM, Andy Shevchenko
> >> >> <[email protected]> wrote:
> >> >> > It looks like panel.c belongs to auxdisplay subsystem.
> >> >> >
> >> >> > Move it to drivers/auxdisplay folder.
> >> >> > No functional changes intended.
> >> >>
> >> >> I didn't move it to drivers/auxdisplay/ because it not only provides
> >> >> auxdisplay functionality, but also keypad functionality.
> >> >
> >> > Yes, I have noticed this. But keypad functionality is optional while
> >> > panel is main one. I think you would agree on this.
> >>
> >> I don't care that much, though. Willy?
> >
> > Well, as long as it continues to work, I don't really care either. The
> > only thing to keep in mind is that it can be difficult to split the
> > driver in two since in some cases it's possible to use the same lines
> > for keypad and lcd.
>
> Ideally, it should be replaced by a glue driver using charlcd, matrix-keypad,
> and (still to be written?) gpio-parport ;-)
It would still not be enough because the same GPIO line may be used both for
LCD and keypad, so there's a need for being able to share the same line. The
typical use case is when you connect the buttons to the D0-D7 data lines of
the parport and feed them back to one entry like ACK, BUSY or PE. When data
are sent to the LCD, if a button is pressed, it will act on the input signal
but we don't care because the keypad driver is not watching. And conversely,
when the keypad driver scans the buttons, it will change the data lines state
but the LCD doesn't care because its E line remains low.
In fact here the output signals should be seen as a shared bus with multiple
chip select signals. Note that in some designs it's even possible that pressing
multiple buttons will cause crap to be sent to the LCD by short-circuiting
the lines (if no diodes are used) but it might be acceptable for many designs,
especially the DIY field where the principle is "don't do it".
Cheers,
Willy
Hi Arnd,
On Mon, Mar 27, 2017 at 4:12 PM, Arnd Bergmann <[email protected]> wrote:
> On a related note, how about moving arm-charlcd there as well,
> and finding a new place for the various ALS drivers?
That's "[PATCH v1 2/2] auxdisplay: Move arm-charlcd.c to drivers/auxdisplay
folder" in Andy's series ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Fri, Mar 24, 2017 at 4:19 PM, Geert Uytterhoeven
<[email protected]> wrote:
> Hi Andy,
>
> On Fri, Mar 24, 2017 at 3:29 PM, Andy Shevchenko
> <[email protected]> wrote:
>> On Fri, 2017-03-24 at 15:19 +0100, Geert Uytterhoeven wrote:
>>> On Fri, Mar 24, 2017 at 3:06 PM, Andy Shevchenko
>>> <[email protected]> wrote:
>>> > It looks like panel.c belongs to auxdisplay subsystem.
>>> >
>>> > Move it to drivers/auxdisplay folder.
>>> > No functional changes intended.
>>>
>>> I didn't move it to drivers/auxdisplay/ because it not only provides
>>> auxdisplay functionality, but also keypad functionality.
>>
>> Yes, I have noticed this. But keypad functionality is optional while
>> panel is main one. I think you would agree on this.
>
> I don't care that much, though. Willy?
I think moving all of it to drivers/auxdisplay as it is today, and doing
any further cleanup on the driver over there is a good idea.
On a related note, how about moving arm-charlcd there as well,
and finding a new place for the various ALS drivers?
Arnd
On Mon, 2017-03-27 at 11:01 +0200, Willy TARREAU wrote:
> On Mon, Mar 27, 2017 at 10:26:07AM +0200, Geert Uytterhoeven wrote:
> > On Mon, Mar 27, 2017 at 10:11 AM, Willy TARREAU <[email protected]
> > m> wrote:
> > > On Fri, Mar 24, 2017 at 04:19:43PM +0100, Geert Uytterhoeven
> > > wrote:
> > > > On Fri, Mar 24, 2017 at 3:29 PM, Andy Shevchenko
> > > > <[email protected]> wrote:
> > > > > On Fri, 2017-03-24 at 15:19 +0100, Geert Uytterhoeven wrote:
> > > > > > On Fri, Mar 24, 2017 at 3:06 PM, Andy Shevchenko
> > > > > > <[email protected]> wrote:
> In fact here the output signals should be seen as a shared bus with
> multiple
> chip select signals. Note that in some designs it's even possible that
> pressing
> multiple buttons will cause crap to be sent to the LCD by short-
> circuiting
> the lines (if no diodes are used) but it might be acceptable for many
> designs,
> especially the DIY field where the principle is "don't do it".
So, summarizing the comments are we okay to proceed or there is a clear
objection?
P.S. Note, that there is at least one driver under drivers/auxdisplay
which supports key buttons.
--
Andy Shevchenko <[email protected]>
Intel Finland Oy
On Fri, Mar 24, 2017 at 3:06 PM, Andy Shevchenko
<[email protected]> wrote:
> It looks like panel.c belongs to auxdisplay subsystem.
>
> Move it to drivers/auxdisplay folder.
> No functional changes intended.
>
> Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Thu, Mar 30, 2017 at 02:27:06PM +0300, Andy Shevchenko wrote:
> On Mon, 2017-03-27 at 11:01 +0200, Willy TARREAU wrote:
> > On Mon, Mar 27, 2017 at 10:26:07AM +0200, Geert Uytterhoeven wrote:
> > > On Mon, Mar 27, 2017 at 10:11 AM, Willy TARREAU <[email protected]
> > > m> wrote:
> > > > On Fri, Mar 24, 2017 at 04:19:43PM +0100, Geert Uytterhoeven
> > > > wrote:
> > > > > On Fri, Mar 24, 2017 at 3:29 PM, Andy Shevchenko
> > > > > <[email protected]> wrote:
> > > > > > On Fri, 2017-03-24 at 15:19 +0100, Geert Uytterhoeven wrote:
> > > > > > > On Fri, Mar 24, 2017 at 3:06 PM, Andy Shevchenko
> > > > > > > <[email protected]> wrote:
>
> > In fact here the output signals should be seen as a shared bus with
> > multiple
> > chip select signals. Note that in some designs it's even possible that
> > pressing
> > multiple buttons will cause crap to be sent to the LCD by short-
> > circuiting
> > the lines (if no diodes are used) but it might be acceptable for many
> > designs,
> > especially the DIY field where the principle is "don't do it".
>
> So, summarizing the comments are we okay to proceed or there is a clear
> objection?
I don't know all the impacts, but as long as it continues to work I'm
totally fine with seeing the code being changed and refactored. It
already got a nice improvement with this series. Furthermore I can
occasionally give it a try if that helps :-)
Willy
On Thu, 2017-03-30 at 14:54 +0200, Willy TARREAU wrote:
> On Thu, Mar 30, 2017 at 02:27:06PM +0300, Andy Shevchenko wrote:
> > On Mon, 2017-03-27 at 11:01 +0200, Willy TARREAU wrote:
> > > On Mon, Mar 27, 2017 at 10:26:07AM +0200, Geert Uytterhoeven
> > > wrote:
> > > > On Mon, Mar 27, 2017 at 10:11 AM, Willy TARREAU <wtarreau@haprox
> > > > y.co
> > > > m> wrote:
> > > > > On Fri, Mar 24, 2017 at 04:19:43PM +0100, Geert Uytterhoeven
> > > > > wrote:
> > > > > > On Fri, Mar 24, 2017 at 3:29 PM, Andy Shevchenko
> > > > > > <[email protected]> wrote:
> > > > > > > On Fri, 2017-03-24 at 15:19 +0100, Geert Uytterhoeven
> > > > > > > wrote:
> > > > > > > > On Fri, Mar 24, 2017 at 3:06 PM, Andy Shevchenko
> > > > > > > > <[email protected]> wrote:
> > > In fact here the output signals should be seen as a shared bus
> > > with
> > > multiple
> > > chip select signals. Note that in some designs it's even possible
> > > that
> > > pressing
> > > multiple buttons will cause crap to be sent to the LCD by short-
> > > circuiting
> > > the lines (if no diodes are used) but it might be acceptable for
> > > many
> > > designs,
> > > especially the DIY field where the principle is "don't do it".
> >
> > So, summarizing the comments are we okay to proceed or there is a
> > clear
> > objection?
>
> I don't know all the impacts, but as long as it continues to work I'm
> totally fine with seeing the code being changed and refactored. It
> already got a nice improvement with this series. Furthermore I can
> occasionally give it a try if that helps :-)
It will.
I'm about to send v2 with tags applied so far.
--
Andy Shevchenko <[email protected]>
Intel Finland Oy