* Re: [PATCH v2 2/8] dt-bindings: olpc,ap-sp: add GPIO lines
From: Pavel Machek @ 2018-11-04 11:49 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Dmitry Torokhov, Michael Turquette, Rob Herring, Mark Rutland,
Stephen Boyd, James Cameron, linux-input, devicetree,
linux-kernel, linux-clk
In-Reply-To: <20181010142504.233467-3-lkundrak@v3.sk>
[-- Attachment #1: Type: text/plain, Size: 867 bytes --]
On Wed 2018-10-10 16:24:58, Lubomir Rintel wrote:
> Add properties describing the GPIO lines used by the keyboard controller.
> The olpc-apsp driver will do happily without them, but they are still part
> of the hardware description. The driver could still reserve the lines,
> so that nothing else touches them.
>
> This makes the device node almost compatible with "ps2-gpio". I'm not
> adding a compatible property, because ps2-gpio would use a different
> interrupt, so that we'd need to name it. And I haven't actually tried it.
>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Acked-by: Pavel Machek <pavel@ucw.cz>
Again, Rob, could you apply this one?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v2 4/8] clk: mmp2: add SP clock
From: Pavel Machek @ 2018-11-04 11:48 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Dmitry Torokhov, Michael Turquette, Rob Herring, Mark Rutland,
Stephen Boyd, James Cameron, linux-input, devicetree,
linux-kernel, linux-clk
In-Reply-To: <20181010142504.233467-5-lkundrak@v3.sk>
[-- Attachment #1: Type: text/plain, Size: 853 bytes --]
On Wed 2018-10-10 16:25:00, Lubomir Rintel wrote:
> The "security processor", sometimes referred to as "wireless trusted
> module" or "generic encrypt unit" is a low-power core present on MMP2,
> that has nothing to do with security, wireless, trust or encryption.
>
> On an OLPC machine it runs CForth and serves as a keyboard controller:
> http://dev.laptop.org/git/users/wmb/cforth/tree/src/app/arm-xo-1.75/ps2.fth
>
> The register address was obtained from the OLPC kernel, since the
> datasheet seems to be the Marvell's most important business secret.
>
> Acked-by: Stephen Boyd <sboyd@kernel.org>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Acked-by: Pavel Machek <pavel@ucw.cz>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/8] dt-bindings: marvell,mmp2: Add clock id for the SP clock
From: Pavel Machek @ 2018-11-04 11:48 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Dmitry Torokhov, Michael Turquette, Rob Herring, Mark Rutland,
Stephen Boyd, James Cameron, linux-input, devicetree,
linux-kernel, linux-clk
In-Reply-To: <20181010142504.233467-4-lkundrak@v3.sk>
[-- Attachment #1: Type: text/plain, Size: 434 bytes --]
On Wed 2018-10-10 16:24:59, Lubomir Rintel wrote:
> This is the clock for the "security processor" core.
>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Acked-by: Stephen Boyd <sboyd@kernel.org>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Acked-by: Pavel Machek <pavel@ucw.cz>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/8] dt-bindings: olpc,ap-sp: add clock
From: Pavel Machek @ 2018-11-04 11:41 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Dmitry Torokhov, Michael Turquette, Rob Herring, Mark Rutland,
Stephen Boyd, James Cameron, linux-input, devicetree,
linux-kernel, linux-clk
In-Reply-To: <20181010142504.233467-2-lkundrak@v3.sk>
[-- Attachment #1: Type: text/plain, Size: 695 bytes --]
On Wed 2018-10-10 16:24:57, Lubomir Rintel wrote:
> The clock is necessary for the device operation, hence it's required.
> Its name, "sp", stands for "Security Processor". It is one of several
> names that are used for the processor that serves as the keyboard
> controller on an OLPC and is consistent with the node name.
>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Acked-by: Pavel Machek <pavel@ucw.cz>
One thing that surprise me... Rob maintains these files, so he should
apply it?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] HID: asus: fix build warning wiht CONFIG_ASUS_WMI disabled
From: Geert Uytterhoeven @ 2018-11-03 22:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jiri Kosina, benjamin.tissoires, Hans de Goede, Colin King,
peter.hutterer, mustafakuscu, Daniel Drake, linux-input,
Linux Kernel Mailing List
In-Reply-To: <20181102151443.758229-1-arnd@arndb.de>
On Fri, Nov 2, 2018 at 4:16 PM Arnd Bergmann <arnd@arndb.de> wrote:
> asus_wmi_evaluate_method() is an empty dummy function when CONFIG_ASUS_WMI
> is disabled, or not reachable from a built-in device driver. This leads to
> a theoretical evaluation of an uninitialized variable that the compiler
> complains about, failing to check that the hardcoded return value makes
> this an unreachable code path:
>
> In file included from include/linux/printk.h:336,
> from include/linux/kernel.h:14,
> from include/linux/list.h:9,
> from include/linux/dmi.h:5,
> from drivers/hid/hid-asus.c:29:
> drivers/hid/hid-asus.c: In function 'asus_input_configured':
> include/linux/dynamic_debug.h:135:3: error: 'value' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> __dynamic_dev_dbg(&descriptor, dev, fmt, \
> ^~~~~~~~~~~~~~~~~
> drivers/hid/hid-asus.c:359:6: note: 'value' was declared here
> u32 value;
> ^~~~~
>
> With an extra IS_ENABLED() check, the warning goes away.
>
> Fixes: 3b692c55e58d ("HID: asus: only support backlight when it's not driven by WMI")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
^ permalink raw reply
* Re: [PATCH 6/8] Input: olpc_apsp: check FIFO status on open(), not probe()
From: Pavel Machek @ 2018-11-02 22:16 UTC (permalink / raw)
To: Lubomir Rintel
Cc: linux-kernel, linux-clk, devicetree, linux-input, Rob Herring,
Mark Rutland, Dmitry Torokhov, Michael Turquette, Stephen Boyd
In-Reply-To: <20180910112654.42061-7-lkundrak@v3.sk>
[-- Attachment #1: Type: text/plain, Size: 460 bytes --]
On Mon 2018-09-10 13:26:52, Lubomir Rintel wrote:
> Let's defer the FIFO status checking until open().
>
> When we'll get a clk handle, this will allow us to defer clock enablement
> until the device is actually used.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Acked-by: Pavel Machek <pavel@ucw.cz>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] Fix display off hotkey on Asus machines
From: Andy Shevchenko @ 2018-11-02 19:35 UTC (permalink / raw)
To: João Paulo Rechi Vita
Cc: Corentin Chary, Darren Hart, Andy Shevchenko, acpi4asus-user,
Platform Driver, Bastien Nocera, Dmitry Torokhov, linux-input,
Linux Kernel Mailing List, linux, João Paulo Rechi Vita
In-Reply-To: <20181101002128.28884-1-jprvita@endlessm.com>
On Thu, Nov 1, 2018 at 2:21 AM João Paulo Rechi Vita <jprvita@gmail.com> wrote:
>
> Asus laptops have a hotkey function on the F7 key to turn the display
> backlight OFF, labeled with a screen with a X inside, as shown on
> https://dlcdnimgs.asus.com/websites/global/products/Xep1ZcSY8dyWXK11/images/keyboard.png
>
> This hotkey worked on very few Asus models, where the EC acts on the
> backlight and input events are generated only to notify userspace of the
> backlight status. On these machines the first hotkey press turns the
> display backlight OFF and notifies the OS with 0x34, which asus-nb-wmi
> forwards to userspace as KEY_DISPLAY_OFF, and a second press turns it
> back ON and notifies the OS with 0x33, which asus-nb-wmi forwards to
> userspace as KEY_DISPLAYTOGGLE. No other keys turn the display backlight
> back ON, but their input is forwarded normally to the application under
> focus.
>
> But for the majority of models, the EC actually does not act on the
> backlight and we simply get a 0x33 notification every time the key is
> pressed, or alternating values of 0x33 / 0x34. We have confirmed this
> behavior on the following models: E203NAS, GL553VE, X441NC, X441UVK,
> X541UVK, X555DG, X555UB, X555UQ, X560UD, X570ZD and X705FD, and the DSDT
> on these machines and the working one (only confirmed on N552VW) is the
> same for the query involved here.
>
> After trying to get information from Asus for quite some time on how
> this works on Windows, we finally recently got a contact that was able
> to give us a definitive answer and a specification for this feature.
> According this contact the 0x33 / 0x34 is an old behavior and all newer
> machines should only be notifying the OS with 0x35 instead, as newer ECs
> don't control the backlight anymore. When a 0x35 notification is
> received the OS should act on the display backlight. From the spec
> (machine-translated from Chinese):
>
> 1.4 Fn+F7
> Function introduction
>
> After the user presses Fn + F7, the screen will be closed through the
> Windows API. The user will immediately open the screen with the mouse
> and keyboard.
> The API used can be found in the Sample URL:
> https://code.msdn.microsoft.com/windowsdesktop/Coalescable-Timer-Sample-d9da954c
> BIOS implementation
> Increase Notify code
> LCD On: 0x33 (display OSD)
> LCD Off: 0x34 (display OSD)
> LCD Switch: 0x35 (using API switch)
>
> The behavior on Windows with the ATKACPI driver from Asus installed
> matches what is described above, with the hotkey turning OFF the
> backlight of all connected displays with a fading effect, and any cursor
> input or key press turning the backlight back ON. The key press or
> cursor input is passed through to the application under focus or under
> the cursor.
>
> With this information from the spec, a simple analysis of the DSDT
> (pasted on the first commit of this series) shows that in order to have
> the firmware notify the OS with 0x35 and have the OS act on the
> backlight, we need to call WMNB(ASUS_WMI_DEVID_BACKLIGHT==0x00050011, 2)
> on the _WDG device. Then we can simply map that scan code to the
> appropriate key code in the driver.
>
> In include/uapi/linux/input-event-codes.h KEY_DISPLAY_OFF is defined as
> "display device to off state", but it is not actually handled by
> userspace on a GNOME+Xorg stack. There are also KEY_SCREENSAVER and
> KEY_SCREENLOCK / KEY_COFFEE. The former seems to be ignored by userspace
> as well (and its value is higher than 255 so it can't be handled by Xorg
> IIUC), and the later is mapped to XF86ScreenSaver by Xorg and triggers
> the lock screen action on GNOME. KEY_SCREENLOCK seems to be what closest
> matches the behavior described above in a Xorg world. I am not sure if
> any of this changes with Wayland, so any clarifications in that regard
> would be greatly appreciated.
>
Pushed to my review and testing queue, thanks!
> João Paulo Rechi Vita (3):
> asus-wmi: Tell the EC the OS will handle the display off hotkey
> asus-nb-wmi: Map 0x35 to KEY_SCREENLOCK
> asus-nb-wmi: Drop mapping of 0x33 and 0x34 scan codes
>
> drivers/platform/x86/asus-nb-wmi.c | 3 +--
> drivers/platform/x86/asus-wmi.c | 3 ++-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> --
> 2.19.1
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] HID: asus: fix build warning wiht CONFIG_ASUS_WMI disabled
From: Arnd Bergmann @ 2018-11-02 15:14 UTC (permalink / raw)
To: Jiri Kosina
Cc: Arnd Bergmann, Benjamin Tissoires, Hans de Goede, Colin Ian King,
Peter Hutterer, Mustafa Kuscu, Daniel Drake, linux-input,
linux-kernel
asus_wmi_evaluate_method() is an empty dummy function when CONFIG_ASUS_WMI
is disabled, or not reachable from a built-in device driver. This leads to
a theoretical evaluation of an uninitialized variable that the compiler
complains about, failing to check that the hardcoded return value makes
this an unreachable code path:
In file included from include/linux/printk.h:336,
from include/linux/kernel.h:14,
from include/linux/list.h:9,
from include/linux/dmi.h:5,
from drivers/hid/hid-asus.c:29:
drivers/hid/hid-asus.c: In function 'asus_input_configured':
include/linux/dynamic_debug.h:135:3: error: 'value' may be used uninitialized in this function [-Werror=maybe-uninitialized]
__dynamic_dev_dbg(&descriptor, dev, fmt, \
^~~~~~~~~~~~~~~~~
drivers/hid/hid-asus.c:359:6: note: 'value' was declared here
u32 value;
^~~~~
With an extra IS_ENABLED() check, the warning goes away.
Fixes: 3b692c55e58d ("HID: asus: only support backlight when it's not driven by WMI")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/hid/hid-asus.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index dc6d6477e961..a1fa2fc8c9b5 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -359,6 +359,9 @@ static bool asus_kbd_wmi_led_control_present(struct hid_device *hdev)
u32 value;
int ret;
+ if (!IS_ENABLED(CONFIG_ASUS_WMI))
+ return false;
+
ret = asus_wmi_evaluate_method(ASUS_WMI_METHODID_DSTS2,
ASUS_WMI_DEVID_KBD_BACKLIGHT, 0, &value);
hid_dbg(hdev, "WMI backlight check: rc %d value %x", ret, value);
--
2.18.0
^ permalink raw reply related
* [PATCH] driver: input: fix UBSAN warning in input_defuzz_abs_event
From: liujian @ 2018-11-02 13:48 UTC (permalink / raw)
To: dmitry.torokhov, linux-input; +Cc: linux-kernel, liujian56
syzkaller triggered a UBCAN warning:
[ 196.188950] UBSAN: Undefined behaviour in drivers/input/input.c:62:23
[ 196.188958] signed integer overflow:
[ 196.188964] -2147483647 - 104 cannot be represented in type 'int [2]'
[ 196.188973] CPU: 7 PID: 4763 Comm: syz-executor Not tainted
4.19.0-514.55.6.9.x86_64+ #7
[ 196.188977] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 196.188979] Call Trace:
[ 196.189001] dump_stack+0x91/0xeb
[ 196.189014] ubsan_epilogue+0x9/0x7c
[ 196.189020] handle_overflow+0x1d7/0x22c
[ 196.189028] ? __ubsan_handle_negate_overflow+0x18f/0x18f
[ 196.189038] ? __mutex_lock+0x213/0x13f0
[ 196.189053] ? drop_futex_key_refs+0xa0/0xa0
[ 196.189070] ? __might_fault+0xef/0x1b0
[ 196.189096] input_handle_event+0xe1b/0x1290
[ 196.189108] input_inject_event+0x1d7/0x27e
[ 196.189119] evdev_write+0x2cf/0x3f0
[ 196.189129] ? evdev_pass_values+0xd40/0xd40
[ 196.189157] ? mark_held_locks+0x160/0x160
[ 196.189171] ? __vfs_write+0xe0/0x6c0
[ 196.189175] ? evdev_pass_values+0xd40/0xd40
[ 196.189179] __vfs_write+0xe0/0x6c0
[ 196.189186] ? kernel_read+0x130/0x130
[ 196.189204] ? _cond_resched+0x15/0x30
[ 196.189214] ? __inode_security_revalidate+0xb8/0xe0
[ 196.189222] ? selinux_file_permission+0x354/0x430
[ 196.189233] vfs_write+0x160/0x440
[ 196.189242] ksys_write+0xc1/0x190
[ 196.189248] ? __ia32_sys_read+0xb0/0xb0
[ 196.189259] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 196.189267] ? do_syscall_64+0x22/0x4a0
[ 196.189276] do_syscall_64+0xa5/0x4a0
[ 196.189287] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 196.189293] RIP: 0033:0x44e7c9
[ 196.189299] Code: fc ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00
the syzkaller reproduce script(but can't reproduce it every time):
r0 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x2,
0x1)
write$binfmt_elf64(r0, &(0x7f0000000240)={{0x7f, 0x45, 0x4c, 0x46, 0x40,
0x2, 0x2, 0xffffffff, 0xffffffffffff374c, 0x3, 0x0, 0x80000001, 0x103,
0x40, 0x22e, 0x26, 0x1, 0x38, 0x2, 0xa23, 0x1, 0x2}, [{0x6474e557, 0x5,
0x6, 0x2, 0x9, 0x9, 0x6c3, 0x1ff}], "", [[], [], [], []]}, 0x478)
ioctl$EVIOCGSW(0xffffffffffffffff, 0x8040451b, &(0x7f0000000040)=""/7)
syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x2, 0x1)
r1 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x2,
0x1)
openat$smack_task_current(0xffffffffffffff9c,
&(0x7f0000000040)='/proc/self/attr/current\x00', 0x2, 0x0)
ioctl$EVIOCSABS0(r1, 0x401845c0, &(0x7f0000000000)={0x4, 0x10000, 0x4,
0xd1, 0x81, 0x3})
eventfd(0x1ff)
syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x2,
0x200)
syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x2, 0x1)
syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x2, 0x1)
syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x2, 0x1)
syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x2, 0x1)
Typecast int to long to fix the issue.
Signed-off-by: liujian <liujian56@huawei.com>
---
drivers/input/input.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 3304aaa..24615ef 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -59,14 +59,17 @@ static inline int is_event_supported(unsigned int code,
static int input_defuzz_abs_event(int value, int old_val, int fuzz)
{
if (fuzz) {
- if (value > old_val - fuzz / 2 && value < old_val + fuzz / 2)
+ if (value > (long)old_val - fuzz / 2 &&
+ value < (long)old_val + fuzz / 2)
return old_val;
- if (value > old_val - fuzz && value < old_val + fuzz)
- return (old_val * 3 + value) / 4;
+ if (value > (long)old_val - fuzz &&
+ value < (long)old_val + fuzz)
+ return ((long)old_val * 3 + value) / 4;
- if (value > old_val - fuzz * 2 && value < old_val + fuzz * 2)
- return (old_val + value) / 2;
+ if (value > (long)old_val - fuzz * 2 &&
+ value < (long)old_val + fuzz * 2)
+ return ((long)old_val + value) / 2;
}
return value;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 0/8] OLPC 1.75 Keyboard/Touchpad fixes
From: Pavel Machek @ 2018-11-01 21:56 UTC (permalink / raw)
To: Lubomir Rintel
Cc: linux-kernel, linux-clk, devicetree, linux-input, Rob Herring,
Mark Rutland, Dmitry Torokhov, Michael Turquette, Stephen Boyd
In-Reply-To: <20180910112654.42061-1-lkundrak@v3.sk>
[-- Attachment #1: Type: text/plain, Size: 308 bytes --]
Hi!
> This makes keyboard/touchpad work on a DT MMP2 platform.
For the series:
Acked-by: Pavel Machek <pavel@ucw.cz>
Tested-by: Pavel Machek <pavel@ucw.cz>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH] input: atkbd: clean up indentation issue, add missing tab in an if statement
From: Colin King @ 2018-11-01 15:12 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to clean up indentation issues, add missing tab
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/input/keyboard/atkbd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index 7e75835e220f..850bb259c20e 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -841,7 +841,7 @@ static int atkbd_select_set(struct atkbd *atkbd, int target_set, int allow_extra
if (param[0] != 3) {
param[0] = 2;
if (ps2_command(ps2dev, param, ATKBD_CMD_SSCANSET))
- return 2;
+ return 2;
}
ps2_command(ps2dev, param, ATKBD_CMD_SETALL_MBR);
--
2.19.1
^ permalink raw reply related
* Re: [PATCH v2 0/8] OLPC 1.75 Keyboard/Touchpad fixes
From: Pavel Machek @ 2018-11-01 13:47 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Dmitry Torokhov, Michael Turquette, Rob Herring, Mark Rutland,
Stephen Boyd, James Cameron, linux-input, devicetree,
linux-kernel, linux-clk
In-Reply-To: <2761d7e31cf7118492e466a5249303c92f68049b.camel@v3.sk>
[-- Attachment #1: Type: text/plain, Size: 610 bytes --]
Hi!
> > > > https://github.com/hackerspace/olpc-xo175-linux/wiki/How-to-run-an-up-to-date-Linux-on-a-XO-1.75
> > > >
Huh. You see that crazy sed magic script?
sed "s/^\(0*20: .... .... .... .... .... ....\) $BEFORE/\1 $AFTER/" |
Do this with the regular expression. My xxd actually has different
number of leading zeros, and so fails...
And with that fixed, I have self-compiled kernel that actually
boots. Yuppie!
Thanks!
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH 3/3] asus-nb-wmi: Drop mapping of 0x33 and 0x34 scan codes
From: João Paulo Rechi Vita @ 2018-11-01 0:21 UTC (permalink / raw)
To: Corentin Chary, Darren Hart, Andy Shevchenko, acpi4asus-user,
platform-driver-x86
Cc: hadess, Dmitry Torokhov, linux-input, linux-kernel, linux,
João Paulo Rechi Vita
In-Reply-To: <20181101002128.28884-1-jprvita@endlessm.com>
According to Asus firmware engineers, the meaning of these codes is only
to notify the OS that the screen brightness has been turned on/off by
the EC. This does not match the meaning of KEY_DISPLAYTOGGLE /
KEY_DISPLAY_OFF, where userspace is expected to change the display
brightness.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
---
drivers/platform/x86/asus-nb-wmi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index 5a00a7665f9b..b6f2ff95c3ed 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -442,8 +442,6 @@ static const struct key_entry asus_nb_wmi_keymap[] = {
{ KE_KEY, 0x30, { KEY_VOLUMEUP } },
{ KE_KEY, 0x31, { KEY_VOLUMEDOWN } },
{ KE_KEY, 0x32, { KEY_MUTE } },
- { KE_KEY, 0x33, { KEY_DISPLAYTOGGLE } }, /* LCD on */
- { KE_KEY, 0x34, { KEY_DISPLAY_OFF } }, /* LCD off */
{ KE_KEY, 0x35, { KEY_SCREENLOCK } },
{ KE_KEY, 0x40, { KEY_PREVIOUSSONG } },
{ KE_KEY, 0x41, { KEY_NEXTSONG } },
--
2.19.1
^ permalink raw reply related
* [PATCH 2/3] asus-nb-wmi: Map 0x35 to KEY_SCREENLOCK
From: João Paulo Rechi Vita @ 2018-11-01 0:21 UTC (permalink / raw)
To: Corentin Chary, Darren Hart, Andy Shevchenko, acpi4asus-user,
platform-driver-x86
Cc: hadess, Dmitry Torokhov, linux-input, linux-kernel, linux,
João Paulo Rechi Vita
In-Reply-To: <20181101002128.28884-1-jprvita@endlessm.com>
When the OS registers to handle events from the display off hotkey the
EC will send a notification with 0x35 for every key press, independent
of the backlight state.
The behavior of this key on Windows, with the ATKACPI driver from Asus
installed, is turning off the backlight of all connected displays with a
fading effect, and any cursor input or key press turning the backlight
back on. The key press or cursor input that wakes up the display is also
passed through to the application under the cursor or under focus.
The key that matches this behavior the closest is KEY_SCREENLOCK.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
---
drivers/platform/x86/asus-nb-wmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index db2af09067db..5a00a7665f9b 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -444,6 +444,7 @@ static const struct key_entry asus_nb_wmi_keymap[] = {
{ KE_KEY, 0x32, { KEY_MUTE } },
{ KE_KEY, 0x33, { KEY_DISPLAYTOGGLE } }, /* LCD on */
{ KE_KEY, 0x34, { KEY_DISPLAY_OFF } }, /* LCD off */
+ { KE_KEY, 0x35, { KEY_SCREENLOCK } },
{ KE_KEY, 0x40, { KEY_PREVIOUSSONG } },
{ KE_KEY, 0x41, { KEY_NEXTSONG } },
{ KE_KEY, 0x43, { KEY_STOPCD } }, /* Stop/Eject */
--
2.19.1
^ permalink raw reply related
* [PATCH 1/3] asus-wmi: Tell the EC the OS will handle the display off hotkey
From: João Paulo Rechi Vita @ 2018-11-01 0:21 UTC (permalink / raw)
To: Corentin Chary, Darren Hart, Andy Shevchenko, acpi4asus-user,
platform-driver-x86
Cc: hadess, Dmitry Torokhov, linux-input, linux-kernel, linux,
João Paulo Rechi Vita
In-Reply-To: <20181101002128.28884-1-jprvita@endlessm.com>
In the past, Asus firmwares would change the panel backlight directly
through the EC when the display off hotkey (Fn+F7) was pressed, and
only notify the OS of such change, with 0x33 when the LCD was ON and
0x34 when the LCD was OFF. These are currently mapped to
KEY_DISPLAYTOGGLE and KEY_DISPLAY_OFF, respectively.
Most recently the EC on Asus most machines lost ability to toggle the
LCD backlight directly, but unless the OS informs the firmware it is
going to handle the display toggle hotkey events, the firmware still
tries change the brightness through the EC, to no effect. The end result
is a long list (at Endless we counted 11) of Asus laptop models where
the display toggle hotkey does not perform any action. Our firmware
engineers contacts at Asus were surprised that there were still machines
out there with the old behavior.
Calling WMNB(ASUS_WMI_DEVID_BACKLIGHT==0x00050011, 2) on the _WDG device
tells the firmware that it should let the OS handle the display toggle
event, in which case it will simply notify the OS of a key press with
0x35, as shown by the DSDT excerpts bellow.
Scope (_SB)
{
(...)
Device (ATKD)
{
(...)
Name (_WDG, Buffer (0x28)
{
/* 0000 */ 0xD0, 0x5E, 0x84, 0x97, 0x6D, 0x4E, 0xDE, 0x11,
/* 0008 */ 0x8A, 0x39, 0x08, 0x00, 0x20, 0x0C, 0x9A, 0x66,
/* 0010 */ 0x4E, 0x42, 0x01, 0x02, 0x35, 0xBB, 0x3C, 0x0B,
/* 0018 */ 0xC2, 0xE3, 0xED, 0x45, 0x91, 0xC2, 0x4C, 0x5A,
/* 0020 */ 0x6D, 0x19, 0x5D, 0x1C, 0xFF, 0x00, 0x01, 0x08
})
Method (WMNB, 3, Serialized)
{
CreateDWordField (Arg2, Zero, IIA0)
CreateDWordField (Arg2, 0x04, IIA1)
Local0 = (Arg1 & 0xFFFFFFFF)
(...)
If ((Local0 == 0x53564544))
{
(...)
If ((IIA0 == 0x00050011))
{
If ((IIA1 == 0x02))
{
^^PCI0.SBRG.EC0.SPIN (0x72, One)
^^PCI0.SBRG.EC0.BLCT = One
}
Return (One)
}
}
(...)
}
(...)
}
(...)
}
(...)
Scope (_SB.PCI0.SBRG.EC0)
{
(...)
Name (BLCT, Zero)
(...)
Method (_Q10, 0, NotSerialized) // _Qxx: EC Query
{
If ((BLCT == Zero))
{
Local0 = One
Local0 = RPIN (0x72)
Local0 ^= One
SPIN (0x72, Local0)
If (ATKP)
{
Local0 = (0x34 - Local0)
^^^^ATKD.IANE (Local0)
}
}
ElseIf ((BLCT == One))
{
If (ATKP)
{
^^^^ATKD.IANE (0x35)
}
}
}
(...)
}
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
---
drivers/platform/x86/asus-wmi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index b52b192a4f16..c25b946bb602 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -2150,7 +2150,8 @@ static int asus_wmi_add(struct platform_device *pdev)
err = asus_wmi_backlight_init(asus);
if (err && err != -ENODEV)
goto fail_backlight;
- }
+ } else
+ err = asus_wmi_set_devstate(ASUS_WMI_DEVID_BACKLIGHT, 2, NULL);
status = wmi_install_notify_handler(asus->driver->event_guid,
asus_wmi_notify, asus);
--
2.19.1
^ permalink raw reply related
* [PATCH 0/3] Fix display off hotkey on Asus machines
From: João Paulo Rechi Vita @ 2018-11-01 0:21 UTC (permalink / raw)
To: Corentin Chary, Darren Hart, Andy Shevchenko, acpi4asus-user,
platform-driver-x86
Cc: hadess, Dmitry Torokhov, linux-input, linux-kernel, linux,
João Paulo Rechi Vita
Asus laptops have a hotkey function on the F7 key to turn the display
backlight OFF, labeled with a screen with a X inside, as shown on
https://dlcdnimgs.asus.com/websites/global/products/Xep1ZcSY8dyWXK11/images/keyboard.png
This hotkey worked on very few Asus models, where the EC acts on the
backlight and input events are generated only to notify userspace of the
backlight status. On these machines the first hotkey press turns the
display backlight OFF and notifies the OS with 0x34, which asus-nb-wmi
forwards to userspace as KEY_DISPLAY_OFF, and a second press turns it
back ON and notifies the OS with 0x33, which asus-nb-wmi forwards to
userspace as KEY_DISPLAYTOGGLE. No other keys turn the display backlight
back ON, but their input is forwarded normally to the application under
focus.
But for the majority of models, the EC actually does not act on the
backlight and we simply get a 0x33 notification every time the key is
pressed, or alternating values of 0x33 / 0x34. We have confirmed this
behavior on the following models: E203NAS, GL553VE, X441NC, X441UVK,
X541UVK, X555DG, X555UB, X555UQ, X560UD, X570ZD and X705FD, and the DSDT
on these machines and the working one (only confirmed on N552VW) is the
same for the query involved here.
After trying to get information from Asus for quite some time on how
this works on Windows, we finally recently got a contact that was able
to give us a definitive answer and a specification for this feature.
According this contact the 0x33 / 0x34 is an old behavior and all newer
machines should only be notifying the OS with 0x35 instead, as newer ECs
don't control the backlight anymore. When a 0x35 notification is
received the OS should act on the display backlight. From the spec
(machine-translated from Chinese):
1.4 Fn+F7
Function introduction
After the user presses Fn + F7, the screen will be closed through the
Windows API. The user will immediately open the screen with the mouse
and keyboard.
The API used can be found in the Sample URL:
https://code.msdn.microsoft.com/windowsdesktop/Coalescable-Timer-Sample-d9da954c
BIOS implementation
Increase Notify code
LCD On: 0x33 (display OSD)
LCD Off: 0x34 (display OSD)
LCD Switch: 0x35 (using API switch)
The behavior on Windows with the ATKACPI driver from Asus installed
matches what is described above, with the hotkey turning OFF the
backlight of all connected displays with a fading effect, and any cursor
input or key press turning the backlight back ON. The key press or
cursor input is passed through to the application under focus or under
the cursor.
With this information from the spec, a simple analysis of the DSDT
(pasted on the first commit of this series) shows that in order to have
the firmware notify the OS with 0x35 and have the OS act on the
backlight, we need to call WMNB(ASUS_WMI_DEVID_BACKLIGHT==0x00050011, 2)
on the _WDG device. Then we can simply map that scan code to the
appropriate key code in the driver.
In include/uapi/linux/input-event-codes.h KEY_DISPLAY_OFF is defined as
"display device to off state", but it is not actually handled by
userspace on a GNOME+Xorg stack. There are also KEY_SCREENSAVER and
KEY_SCREENLOCK / KEY_COFFEE. The former seems to be ignored by userspace
as well (and its value is higher than 255 so it can't be handled by Xorg
IIUC), and the later is mapped to XF86ScreenSaver by Xorg and triggers
the lock screen action on GNOME. KEY_SCREENLOCK seems to be what closest
matches the behavior described above in a Xorg world. I am not sure if
any of this changes with Wayland, so any clarifications in that regard
would be greatly appreciated.
João Paulo Rechi Vita (3):
asus-wmi: Tell the EC the OS will handle the display off hotkey
asus-nb-wmi: Map 0x35 to KEY_SCREENLOCK
asus-nb-wmi: Drop mapping of 0x33 and 0x34 scan codes
drivers/platform/x86/asus-nb-wmi.c | 3 +--
drivers/platform/x86/asus-wmi.c | 3 ++-
2 files changed, 3 insertions(+), 3 deletions(-)
--
2.19.1
^ permalink raw reply
* Re: Logitech high-resolution scrolling..
From: Nestor Lopez Casado @ 2018-10-31 13:47 UTC (permalink / raw)
To: hcutts
Cc: Linus Torvalds, peter.hutterer, jikos, Benjamin Tissoires,
open list:HID CORE LAYER, linux-kernel
In-Reply-To: <CA+jURctDNnVjKEZD6jm3ACv1r8_Me9f+6T_aRiApR=Nd_+upvw@mail.gmail.com>
Hi guys,
I've read the discussion, I think I understand the problem and I'll
get back to this thread with more information as soon as I've got some
internal feedback.
BTW, lovely to see so many MX Anywhere 2 users :)
-nestor
On Tue, Oct 30, 2018 at 6:48 PM Harry Cutts <hcutts@chromium.org> wrote:
>
> Thanks for the analysis, Peter.
>
> On Mon, 29 Oct 2018 at 23:27, Peter Hutterer <peter.hutterer@who-t.net> wrote:
> > IMO this is a lost battle because you cannot know when the ratchet is
> > enabled or not (at least not on all mice). Users switch between ratchet and
> > freewheeling time and once you're out of one mode, you have no reference
> > to the other mode's reset point anymore.
>
> It would be a lost battle, if it weren't for the fact that on all the
> mice I've tested, putting the wheel back into clicky mode causes the
> wheel to jump to the nearest notch resting point, which should mean
> that the remainder resets to 0 (or maybe ±1 if the mechanism is worn).
>
> > So my suggestion is to combine Linus' reset with your approach and use the
> > center-point for the trigger. This gives us a few events to slide and still
> > do the right thing, and any direction change will reset anyway. Biggest
> > drawback is that the first event after a direction change is triggered
> > faster than the next event. Otherwise it feels correct to me, both in
> > free-wheeling and in ratchet mode now.
>
> This sounds like a reasonable approach if we find that we can't keep
> the triggering point consistent.
>
> > Also, WTF moment: I managed to get the mouse into a state where it would
> > only give me 1 hi-res event per notch movement but failed to reproduce that
> > again.
>
> Interesting; let me know if you manage to reliably reproduce it. The
> only time I've encountered this in the past was when connecting to the
> mouse over BLE, where we don't seem to be able to detect if the mouse
> is power cycled (meaning that the mouse resets to low-res mode but the
> kernel is still expecting high-res reports). I held off on enabling
> high-res scrolling over Bluetooth for this reason.
>
> On Tue, 30 Oct 2018 at 09:29, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > I wonder if there's some docs on what Logitech does internally in the
> > mouse. It might involve a timeout (ie "if not moving for a while, do
> > the rounding _and_ reset), which would probably be too expensive to do
> > on the host side.
>
> I've been wondering this as well. Nestor (CCed), is there anything you
> can tell us about this?
>
> Harry Cutts
> Chrome OS Touch/Input team
^ permalink raw reply
* Re: [PATCH v2 0/8] OLPC 1.75 Keyboard/Touchpad fixes
From: Pavel Machek @ 2018-10-31 12:46 UTC (permalink / raw)
To: James Cameron
Cc: Lubomir Rintel, Dmitry Torokhov, Michael Turquette, Rob Herring,
Mark Rutland, Stephen Boyd, linux-input, devicetree, linux-kernel,
linux-clk
In-Reply-To: <20181031033746.GF8698@us.netrek.org>
[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]
Hi!
> > https://github.com/hackerspace/olpc-xo175-buildroot/releases
> >
> > Here's a SD card image that works for me. The topmost commit in the
> > same repository is the build configuration that was used to generate
> > it:
> >
> > https://github.com/hackerspace/olpc-xo175-buildroot/commit/71783d599.patch
> >
> > Note it is only going to boot off the SD card, because the root=
> > argument is hardwired in the devicetree. Sorry about that -- I built
> > the image before I noticed you're booting off an USB stick and I don't
> > have the resources to regenerate the image at the moment.
>
> Your image does boot for me - after changing features on
> filesystem.
>
> http://dev.laptop.org/~quozl/y/1gHh5m.txt (dmesg)
>
> dumpe2fs of your image filesystem features; has_journal ext_attr
> resize_inode dir_index filetype flex_bg sparse_super large_file
> huge_file dir_nlink extra_isize metadata_csum, and flags;
> signed_directory_hash.
>
> dumpe2fs of my image filesystem features; has_journal ext_attr
> resize_inode dir_index filetype extent flex_bg sparse_super uninit_bg
> dir_nlink extra_isize, and flags; unsigned_directory_hash.
>
> Our OLPC OS builder uses "mkfs.ext4 -O dir_index,^huge_file", from
> e2fsprogs 1.42.5.
>
> I'll look at the microSD card errors; by trying another one.
Success, too... after re-doing the filesystem with local mkfs.
One thing I noticed: olpc-battery/voltage_max_design is lower than
voltage normally reported by voltage_now.
I'll play with it some more
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/8] OLPC 1.75 Keyboard/Touchpad fixes
From: Pavel Machek @ 2018-10-31 12:29 UTC (permalink / raw)
To: James Cameron
Cc: Lubomir Rintel, Dmitry Torokhov, Michael Turquette, Rob Herring,
Mark Rutland, Stephen Boyd, linux-input, devicetree, linux-kernel,
linux-clk
In-Reply-To: <20181030235430.GF30863@us.netrek.org>
[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]
Hi!
> > But I don't get kernel messages during boot:
> >
> > OLPC 1B1, 512 MiB memory...
> > OpenFirmware Q4C02 EC Frimware 0.3.02
> >
> > Type any key to interrupt...
> > (but keys do not interrupt anything, ouch).
> > Warning... partition type is 0xb...
> > Boot device: /usb/disk:\boot\olpc.fth Arguments:
> > Boot device ....
> > Warning... partition type is 0xb...
>
> That firmware has problems with USB drives. Please upgrade to Q4D38.
> Quickest tested method is http://wiki.laptop.org/go/Upgrading_firmware
Let me try that... Upgrading firmware said "USB drive" so I placed
bootfw.zip on usb drive. It did quite a show, but I believe it said
that my firmware is up to date?
It all ended with "activation lease not found" message. Let me retry?
Same result.
Let me try "upgrading firmware" with SD card. It seems to work with SD
card. Holding down both "yes" and "no" keys during boot results in
more useful messages... good. I have now updated firmware, and it even
fixed my previous boot problem. Good.
Thanks!
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/8] OLPC 1.75 Keyboard/Touchpad fixes
From: Pavel Machek @ 2018-10-31 11:54 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Dmitry Torokhov, Michael Turquette, Rob Herring, Mark Rutland,
Stephen Boyd, James Cameron, linux-input, devicetree,
linux-kernel, linux-clk
In-Reply-To: <2761d7e31cf7118492e466a5249303c92f68049b.camel@v3.sk>
[-- Attachment #1: Type: text/plain, Size: 3250 bytes --]
Hi!
> > > > https://github.com/hackerspace/olpc-xo175-linux/wiki/How-to-run-an-up-to-date-Linux-on-a-XO-1.75
> > > >
> > > > I didn't test it yet -- will do when I get home in the evening.
> > > > But
> > > > chances are it's good enough and I guess you'd be able to get it
> > > > working even if I messed up some details.
> >
> > Instruction say make, but you really need to do make zImage and make
> > mmp2-olpc-xo-1-75.dtb .
>
> Have you tried? I'm typically doing just a plain "make".
>
> According to "make help", a plain "make" (assuming it's equivalent to
> "make all") includes "zImage" and "dtbs" targets.
I believe I did, but not 100% sure.
> > Instructions say "make -j", which is nice way to crash a machine. I
> > suggest "make -j 8" :-).
>
> Holy... what sort of a machine do you have?
Thinkpad X220. Is it too big or too small? :-). 4 threads, so I
usually use -j 5, but -j 8 should be for my notebook and also bigger
servers.
> > Ok, I think I followed the instructions. I am using empty root
> > filesystem, just with /boot -- want to see kernel messages first
> > before I mess with the userland.
> >
> > But I don't get kernel messages during boot:
> >
> > OLPC 1B1, 512 MiB memory...
> > OpenFirmware Q4C02 EC Frimware 0.3.02
>
> "Frimware" -- I assume you don't have a serial console hooked on? :)
Not :-(. Altrough.. maybe I do have that cable somewhere, I just never
used it.
> > Type any key to interrupt...
> > (but keys do not interrupt anything, ouch).
>
> In my version of the OLPC OF the routine is replaced with one that only
> accepts the Escape key, because kids like to press random keys without
> really wanting a shell. Maybe try that one?
Ok, will try.
> > And that's it, cursor and no kernel messages.
> >
> > Any ideas?
> >
> > Could I get prepared binary zImage for testing?
>
> https://github.com/hackerspace/olpc-xo175-buildroot/releases
>
> Here's a SD card image that works for me. The topmost commit in the
> same repository is the build configuration that was used to generate
> it:
Kernel works for me with this one. (First boot userland boots, then
blinking cursor; next boot filesystem is corrupted. Hmm.) Feel free to
add "Tested-by:" to patches this uses.
> Note it is only going to boot off the SD card, because the root=
> argument is hardwired in the devicetree. Sorry about that -- I built
> the image before I noticed you're booting off an USB stick and I don't
> have the resources to regenerate the image at the moment.
No problem, I have SD cards here, too.
> If this won't boot for you, we may need fixes for older FW. Until then
> it might be a good idea if you just update to the latest one (it is as
> easy as booting the last version of the stock distro with a charged
> battery pack).
I'd need more instructions for firmware update. Or maybe ... lets
ignore that. SD card is fine, and I don't want to brick it.
I already broken it enough that keys need to be held during boot (or
it does not boot).
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/8] OLPC 1.75 Keyboard/Touchpad fixes
From: James Cameron @ 2018-10-31 3:37 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Pavel Machek, Dmitry Torokhov, Michael Turquette, Rob Herring,
Mark Rutland, Stephen Boyd, linux-input, devicetree, linux-kernel,
linux-clk
In-Reply-To: <2761d7e31cf7118492e466a5249303c92f68049b.camel@v3.sk>
G'day,
Success, see below.
On Tue, Oct 30, 2018 at 08:40:38PM +0100, Lubomir Rintel wrote:
> Hello Pavel,
>
> On Tue, 2018-10-30 at 11:26 +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > https://github.com/hackerspace/olpc-xo175-linux/wiki/How-to-run-an-up-to-date-Linux-on-a-XO-1.75
> > > >
> > > > I didn't test it yet -- will do when I get home in the evening.
> > > > But
> > > > chances are it's good enough and I guess you'd be able to get it
> > > > working even if I messed up some details.
> >
> > [...]
> > Could I get prepared binary zImage for testing?
>
> https://github.com/hackerspace/olpc-xo175-buildroot/releases
>
> Here's a SD card image that works for me. The topmost commit in the
> same repository is the build configuration that was used to generate
> it:
>
> https://github.com/hackerspace/olpc-xo175-buildroot/commit/71783d599.patch
>
> Note it is only going to boot off the SD card, because the root=
> argument is hardwired in the devicetree. Sorry about that -- I built
> the image before I noticed you're booting off an USB stick and I don't
> have the resources to regenerate the image at the moment.
Your image does boot for me - after changing features on
filesystem.
http://dev.laptop.org/~quozl/y/1gHh5m.txt (dmesg)
dumpe2fs of your image filesystem features; has_journal ext_attr
resize_inode dir_index filetype flex_bg sparse_super large_file
huge_file dir_nlink extra_isize metadata_csum, and flags;
signed_directory_hash.
dumpe2fs of my image filesystem features; has_journal ext_attr
resize_inode dir_index filetype extent flex_bg sparse_super uninit_bg
dir_nlink extra_isize, and flags; unsigned_directory_hash.
Our OLPC OS builder uses "mkfs.ext4 -O dir_index,^huge_file", from
e2fsprogs 1.42.5.
I'll look at the microSD card errors; by trying another one.
Fantastic progress though, thanks! Wish I were a full time kernel
developer, but so much else to do now.
> If this won't boot for you, we may need fixes for older FW.
Let me know what you need there; with a patch, and if it isn't too
extensive I could spin a new build. We're not producing these models,
so I don't _have_ to keep the factory test code working.
https://github.com/quozl/openfirmware
--
James Cameron
http://quozl.netrek.org/
^ permalink raw reply
* Re: [PATCH v2 0/8] OLPC 1.75 Keyboard/Touchpad fixes
From: James Cameron @ 2018-10-30 23:54 UTC (permalink / raw)
To: Pavel Machek
Cc: Lubomir Rintel, Dmitry Torokhov, Michael Turquette, Rob Herring,
Mark Rutland, Stephen Boyd, linux-input, devicetree, linux-kernel,
linux-clk
In-Reply-To: <20181030102610.GC21529@amd>
G'day Pavel,
On Tue, Oct 30, 2018 at 11:26:10AM +0100, Pavel Machek wrote:
> Hi!
>
> > > https://github.com/hackerspace/olpc-xo175-linux/wiki/How-to-run-an-up-to-date-Linux-on-a-XO-1.75
> > >
> > > I didn't test it yet -- will do when I get home in the evening. But
> > > chances are it's good enough and I guess you'd be able to get it
> > > working even if I messed up some details.
>
> Instruction say make, but you really need to do make zImage and make
> mmp2-olpc-xo-1-75.dtb .
>
> Instructions say "make -j", which is nice way to crash a machine. I
> suggest "make -j 8" :-).
>
> Ok, I think I followed the instructions. I am using empty root
> filesystem, just with /boot -- want to see kernel messages first
> before I mess with the userland.
>
> But I don't get kernel messages during boot:
>
> OLPC 1B1, 512 MiB memory...
> OpenFirmware Q4C02 EC Frimware 0.3.02
>
> Type any key to interrupt...
> (but keys do not interrupt anything, ouch).
> Warning... partition type is 0xb...
> Boot device: /usb/disk:\boot\olpc.fth Arguments:
> Boot device ....
> Warning... partition type is 0xb...
That firmware has problems with USB drives. Please upgrade to Q4D38.
Quickest tested method is http://wiki.laptop.org/go/Upgrading_firmware
I'm firmware releaser and signer.
> And that's it, cursor and no kernel messages.
>
> Any ideas?
>
> Could I get prepared binary zImage for testing?
>
> Thanks,
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
James Cameron
http://quozl.netrek.org/
^ permalink raw reply
* Re: [PATCH v2 0/8] OLPC 1.75 Keyboard/Touchpad fixes
From: Lubomir Rintel @ 2018-10-30 19:40 UTC (permalink / raw)
To: Pavel Machek
Cc: Dmitry Torokhov, Michael Turquette, Rob Herring, Mark Rutland,
Stephen Boyd, James Cameron, linux-input, devicetree,
linux-kernel, linux-clk
In-Reply-To: <20181030102610.GC21529@amd>
Hello Pavel,
On Tue, 2018-10-30 at 11:26 +0100, Pavel Machek wrote:
> Hi!
>
> > > https://github.com/hackerspace/olpc-xo175-linux/wiki/How-to-run-an-up-to-date-Linux-on-a-XO-1.75
> > >
> > > I didn't test it yet -- will do when I get home in the evening.
> > > But
> > > chances are it's good enough and I guess you'd be able to get it
> > > working even if I messed up some details.
>
> Instruction say make, but you really need to do make zImage and make
> mmp2-olpc-xo-1-75.dtb .
Have you tried? I'm typically doing just a plain "make".
According to "make help", a plain "make" (assuming it's equivalent to
"make all") includes "zImage" and "dtbs" targets.
>
> Instructions say "make -j", which is nice way to crash a machine. I
> suggest "make -j 8" :-).
Holy... what sort of a machine do you have?
> Ok, I think I followed the instructions. I am using empty root
> filesystem, just with /boot -- want to see kernel messages first
> before I mess with the userland.
>
> But I don't get kernel messages during boot:
>
> OLPC 1B1, 512 MiB memory...
> OpenFirmware Q4C02 EC Frimware 0.3.02
"Frimware" -- I assume you don't have a serial console hooked on? :)
Doesn't matter though, your OF doesn't seem to even get to load the
kernel anyways. And the framebuffer console (though only by the means
of a hacked pxa168fb for the time being, no armada drm yet) works.
Here's my bootup banner:
OLPC 1B1, 800 MHz, 512 MiB memory, 4 GB internal storage...
OpenFirmware Q4D38 EC Firmware 1.0.01 2018-10-30 19:11:36 UTC
I seem to have a bit newer OF.
> Type any key to interrupt...
> (but keys do not interrupt anything, ouch).
In my version of the OLPC OF the routine is replaced with one that only
accepts the Escape key, because kids like to press random keys without
really wanting a shell. Maybe try that one?
Although my prompt is also a bit different: "Type the Esc key to
interrupt automatic startup"
> Warning... partition type is 0xb...
> Boot device: /usb/disk:\boot\olpc.fth Arguments:
> Boot device ....
> Warning... partition type is 0xb...
Maybe the older version wouldn't support a VFAT volume, hence the
complains about the id=0xb volume? Try ext3?
>
> And that's it, cursor and no kernel messages.
>
> Any ideas?
>
> Could I get prepared binary zImage for testing?
https://github.com/hackerspace/olpc-xo175-buildroot/releases
Here's a SD card image that works for me. The topmost commit in the
same repository is the build configuration that was used to generate
it:
https://github.com/hackerspace/olpc-xo175-buildroot/commit/71783d599.patch
Note it is only going to boot off the SD card, because the root=
argument is hardwired in the devicetree. Sorry about that -- I built
the image before I noticed you're booting off an USB stick and I don't
have the resources to regenerate the image at the moment.
If this won't boot for you, we may need fixes for older FW. Until then
it might be a good idea if you just update to the latest one (it is as
easy as booting the last version of the stock distro with a charged
battery pack).
> Thanks.
>
>
> Pavel
Take care
Lubo
^ permalink raw reply
* Re: [PATCH v5 3/8] dt-bindings: regulator: document stpmic1 pmic regulators
From: Rob Herring @ 2018-10-30 19:34 UTC (permalink / raw)
To: Pascal PAILLET-LME
Cc: dmitry.torokhov@gmail.com, mark.rutland@arm.com,
lee.jones@linaro.org, lgirdwood@gmail.com, broonie@kernel.org,
wim@linux-watchdog.org, linux@roeck-us.net,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-watchdog@vger.kernel.org,
benjamin.gaignard@linaro.org, eballetbo@gmail.com,
axel.lin@ingics.com
In-Reply-To: <1540830122-2577-4-git-send-email-p.paillet@st.com>
On Mon, Oct 29, 2018 at 04:22:05PM +0000, Pascal PAILLET-LME wrote:
> The STPMIC1 regulators supply power to the application processor as well as
> to the external system peripherals such as DDR, Flash memories and system
> devices.
>
> Signed-off-by: Pascal Paillet <p.paillet@st.com>
> ---
> changes in v5:
> * describe regulator-active-discharge is available for power switches
> * remove interrupt parents
>
> .../bindings/regulator/st,stpmic1-regulator.txt | 67 ++++++++++++++++++++++
> 1 file changed, 67 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt
>
> diff --git a/Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt b/Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt
> new file mode 100644
> index 0000000..5adc938
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt
> @@ -0,0 +1,67 @@
> +STMicroelectronics STPMIC1 Voltage regulators
> +
> +Regulator Nodes are optional depending on needs.
> +
> +Available Regulators in STPMIC1 device are:
> + - buck1 for Buck BUCK1
> + - buck2 for Buck BUCK2
> + - buck3 for Buck BUCK3
> + - buck4 for Buck BUCK4
> + - ldo1 for LDO LDO1
> + - ldo2 for LDO LDO2
> + - ldo3 for LDO LDO3
> + - ldo4 for LDO LDO4
> + - ldo5 for LDO LDO5
> + - ldo6 for LDO LDO6
> + - vref_ddr for LDO Vref DDR
> + - boost for Buck BOOST
> + - pwr_sw1 for VBUS_OTG switch
> + - pwr_sw2 for SW_OUT switch
> +
> +Switches are fixed voltage regulators with only enable/disable capability.
> +
> +Optional properties:
> +- st,mask-reset: mask reset for this regulator: the regulator configuration
> + is maintained during pmic reset.
> +- regulator-pull-down: enable high pull down
> + if not specified light pull down is used
> +- regulator-over-current-protection:
> + if set, all regulators are switched off in case of over-current detection
> + on this regulator,
> + if not set, the driver only sends an over-current event.
> +- interrupt-parent: phandle to the parent interrupt controller
This is not needed as the parent is a parent node with
'interrupt-controller' property.
Otherwise,
Reviewed-by: Rob Herring <robh@kernel.org>
> +- interrupts: index of current limit detection interrupt
> +- <regulator>-supply: phandle to the parent supply/regulator node
> + each regulator supply can be described except vref_ddr.
> +- regulator-active-discharge: can be used on pwr_sw1 and pwr_sw2.
> +
> +Example:
> +regulators {
> + compatible = "st,stpmic1-regulators";
> +
> + ldo6-supply = <&v3v3>;
> +
> + vdd_core: buck1 {
> + regulator-name = "vdd_core";
> + interrupts = <IT_CURLIM_BUCK1 0>;
> + st,mask-reset;
> + regulator-pull-down;
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1200000>;
> + };
> +
> + v3v3: buck4 {
> + regulator-name = "v3v3";
> + interrupts = <IT_CURLIM_BUCK4 0>;
> +
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + v1v8: ldo6 {
> + regulator-name = "v1v8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-over-current-protection;
> + };
> +};
> --
> 1.9.1
^ permalink raw reply
* Re: [PATCH v5 1/8] dt-bindings: mfd: document stpmic1
From: Rob Herring @ 2018-10-30 19:32 UTC (permalink / raw)
To: Pascal PAILLET-LME
Cc: dmitry.torokhov@gmail.com, robh+dt@kernel.org,
mark.rutland@arm.com, lee.jones@linaro.org, lgirdwood@gmail.com,
broonie@kernel.org, wim@linux-watchdog.org, linux@roeck-us.net,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-watchdog@vger.kernel.org,
benjamin.gaignard@linaro.org, eballetbo@gmail.com,
axel.lin@ingics.com
In-Reply-To: <1540830122-2577-2-git-send-email-p.paillet@st.com>
On Mon, 29 Oct 2018 16:22:04 +0000, Pascal PAILLET-LME wrote:
> stpmic1 is a pmic from STMicroelectronics. The STPMIC1 integrates 10
> regulators, 3 power switches, a watchdog and an input for a power on key.
>
> Signed-off-by: Pascal Paillet <p.paillet@st.com>
> ---
> changes in v5:
> * removed st properties
> * added buck modes definitions in the header
>
> .../devicetree/bindings/mfd/st,stpmic1.txt | 61 ++++++++++++++++++++++
> include/dt-bindings/mfd/st,stpmic1.h | 50 ++++++++++++++++++
> 2 files changed, 111 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/st,stpmic1.txt
> create mode 100644 include/dt-bindings/mfd/st,stpmic1.h
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox