These support the flat device tree. We want to use the dev_read_..()
prefix for functions that support both flat tree and live tree. So rename
the existing functions to avoid confusion.
In the end we will have:
1. dev_read_addr...() - works on devices, supports flat/live tree
2. devfdt_get_addr...() - current functions, flat tree only
3. of_get_address() etc. - new functions, live tree only
All drivers will be written to use 1. That function will in turn call
either 2 or 3 depending on whether the flat or live tree is in use.
Note this involves changing some dead code - the imx_lpi2c.c file.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present devices use a simple integer offset to record the device tree
node associated with the device. In preparation for supporting a live
device tree, which uses a node pointer instead, refactor existing code to
access this field through an inline function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Creating multiple entries of "config FOO" often gives us bad
experiences. In this case, we should specify "default X86"
as platforms that want this keyboard by default.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Marek Vasut <marex@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add one more step into the init sequence. This fixes the keyboard on samus,
which otherwise does not work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
This adds support for detecting a few inputs exported by the TWL6030.
Currently-supported inputs are the power button, USB and charger presence.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
We need to add the base tables before adding the function tables. Fix the
init order so the keyboard scans keys correctly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
The console includes a global variable and several functions that are only
used by a small subset of U-Boot files. Before adding more functions, move
the definitions into their own header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
When 'Num Lock' is not on, we should not send these digit numbers
(0-9 and dot) to the output buffer.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
When sending LED update command to an i8042 compatible keyboard,
bit1 is 'Num Lock' and bit2 is 'Caps Lock' in the data byte. But
input library defines bit1 as 'Caps Lock' and bit2 as 'Num Lock'.
This causes a wrong LED to be set on an i8042 compatible keyboard.
Change the LED state bits to be i8042 compatible, and change the
keyboard flags as well.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
We should request keyboard to turn on/off its LED when detecting
any changes on the LEDs.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Minor changes to allow this to build without CONFIG_DM_KEYBOARD:
Signed-off-by: Simon Glass <sjg@chromium.org>
Currently keyboard's LED state is wrongly saved to config->leds in
process_modifier(). It should really be config->flags.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
This has duplicated scan code tables and logic. We can use the input
library to implement most of the features here.
This needs testing. The only supported board appears to be TQM5200.
Unfortunately no maintainer is listed for this board.
Signed-off-by: Simon Glass <sjg@chromium.org>
Sometimes we seem to get 0xaa twice which causes the config read to fail.
This causes chromebook_link to fail to set up the keyboard.
Add a check for this and read the config again when detected.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Adjust this driver to support driver model. The only users are x86 boards
so this should be safe.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Add a new option CONFIG_I8042_KEYB which will replace the current
CONFIG_I8042_KBD. This new name fits better with existing drivers.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present the i8042 driver has its own logic and keymaps. In an effort to
unify the code, move it over to use the input library. This changes most of
the keycode-processing logic since it is now in that library. The main
responsibilities of the driver are now to handle the LEDs, deal with the
PS/2 extended keycodes and initialise the the keyboard.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Add a function which returns a new keyboard LED value when the LEDs need
updating.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When caps lock is enabled we should convert lower case to upper case. Add
this to the input key processing so that caps lock works correctly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Move all the '!release' code into one block so that it is clear that it only
applies on key release.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add support for the German keymap, taken from i8042.c. This can be selected
when the input library it initialised.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Generally the input library handles processing of a list of scanned keys.
Repeated keys need to be generated based on a timer in this case, since all
that is provided is a list of keys current depressed.
Keyboards which do their own scanning will resend codes when they want to
inject a repeating key. Provide a function which tells the input library to
accept repeating keys and not to try to second-guess the caller.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Most keyboards can be scanned to produce a list of the keycodes which are
depressed. With the i8042 keyboard this scanning is done internally and
only the processed results are returned.
In this case, when a key is pressed, a 'make' code is sent. When the key
is released a 'break' code is sent. This means that the driver needs to
keep track of which keys are pressed. It also means that any protocol error
can lead to stuck keys.
In order to support this type of keyboard, add a function when can be used
to provide a single keycode and either add it to the list of what is pressed
or remove it from the list. Then the normal input_send_keycodes() function
can be used to actually do the decoding work.
Add debugging to display the ASCII characters written to the input queue
also.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Modify i8042_kbd_init() so that the normal pass is sucessful init and
failure exits early. This will make the code easier to extend and is easier
to read.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Rather than lots of 'return' statements, use goto to a single return.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present the register access in kbd_reset() is quite primitive. This makes
it hard to follow.
Create functions to read and write data, both to a single register, and via
the command/data approach.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-on: Intel Crown Bay and QEMU
Tested-by: Bin Meng <bmeng.cn@gmail.com>
CONFIG_CONSOLE_CURSOR, CONFIG_SYS_CONSOLE_BLINK_COUNT and
CONFIG_CONSOLE_TIME are not used by any board. The implementation is not
great and stands in the way of a refactor of i8042. Drop these for now.
They can be re-introduced quite easily later, perhaps with driver-model
real-time-clock (RTC) support.
When reintroducing, it might be useful to make a few changes:
- Blink time would be more useful than blink count
- The confusing #ifdefs should be avoided
- The time functions should support driver model
- It would be best keyed off console_tstc() or some similar idle loop
rather than a particular input driver (i8042 in this case)
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Adjust the cros_ec keyboard driver to support driver model. Make this the
default for all Exynos boards so that those that use a keyboard will build
correctly with this driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
Adjust the tegra keyboard driver to support driver model, using the new
uclass. Make this the default for all Tegra boards so that those that use
a keyboard will build correctly with this driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
In preparation for converting the cros_ec keyboard driver to driver model,
adjust the cros_ec functions it will use to use a normal struct udevice.
Signed-off-by: Simon Glass <sjg@chromium.org>
Require the caller to add the keycode translation tables separately so that
it can select which ones to use. In a later patch we will add the option to
add German tables.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Return a useful error instead of -1 when something goes wrong.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a uclass for keyboard input, mirroring the existing stdio methods.
This is enabled by a new CONFIG_DM_KEYBOARD option.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The existing i8042 keyboard controller driver has some issues.
First of all, it does not issue a self-test command (0xaa) to the
controller at the very beginning. Without this, the controller
does not respond to any command at all. Secondly, it initializes
the configuration byte register to turn on the keyboard's interrupt,
as U-Boot does not normally allow interrupts to be processed.
Finally, at the end of the initialization routine, it wrongly
sets the controller to disable all interfaces including both
keyboard and mouse.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
- Rename CamelCase variables to conform U-Boot coding convention
- Rename wait_until_kbd_output_full() to kbd_output_full()
- Change to use macros for i8042 command and control register bits
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Reorder those static function so that their declarations
can be removed.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
We have flipped CONFIG_SPL_DISABLE_OF_CONTROL. We have cleansing
devices, $(SPL_) and CONFIG_IS_ENABLED(), so we are ready to clear
away the ugly logic in include/fdtdec.h:
#ifdef CONFIG_OF_CONTROL
# if defined(CONFIG_SPL_BUILD) && !defined(SPL_OF_CONTROL)
# define OF_CONTROL 0
# else
# define OF_CONTROL 1
# endif
#else
# define OF_CONTROL 0
#endif
Now CONFIG_IS_ENABLED(OF_CONTROL) is the substitute. It refers to
CONFIG_OF_CONTROL for U-boot proper and CONFIG_SPL_OF_CONTROL for
SPL.
Also, we no longer have to cancel CONFIG_OF_CONTROL in
include/config_uncmd_spl.h and scripts/Makefile.spl.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
This allows scanning the twl4030 keypad, storing the result in a 64-byte long
matrix with the twl4030_keypad_scan function.
Detecting a key at a given column and row is made easier with the
twl4030_keypad_key function.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
This adds support for detecting a few inputs exported by the TWL4030.
Currently-supported inputs are the power button, USB and charger presence.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
This code appears to be missing a piece that is needed on some keyboards
to enable the keyboard. Add this in.
This makes the keyboard work correctly on chromebook_link.
Signed-off-by: Simon Glass <sjg@chromium.org>
The U-Boot device trees are slightly different in a few places. Adjust them
to remove most of the differences. Note that U-Boot does not support the
concept of interrupts as distinct from GPIOs, so this difference remains.
For sandbox, use the same keyboard file as for ARM boards and drop the
host emulation bus which seems redundant.
Signed-off-by: Simon Glass <sjg@chromium.org>
Since both I2C and SPI are converted to Kconfig, we can convert cros_ec
to Kconfig for these buses.
LPC will need to wait until driver mode PCI is available.
Signed-off-by: Simon Glass <sjg@chromium.org>
The ChromeOS EC keyboard is used by various different chromebooks. Peach
pi being the third board in the u-boot tree to use it (snow and peach
pit the other two). Rather then embedding the same big DT node in the
peach-pi DT again, copy the dtsi snippit & bindings documentation from
linux and include it in all 3 boards.
This slightly changes the dt bindings in u-boot:
* google,key-rows becomes keypad,num-rows
* google,key-colums becomes keypad,num-colums
* google,repeat-delay-ms and google,repeat-rate-ms are no longer used
and replaced by hardcoded values (similar to tegra kbc)
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
