Re: [RFC 0/4] ARM: dts: exynos: Prepare Spring
On Tue, Jul 1, 2014 at 9:18 PM, Andreas Färber wrote: > Am 23.06.2014 23:24, schrieb Andreas Färber: >> Am 23.06.2014 22:11, schrieb Benson Leung: >>> On Mon, Jun 23, 2014 at 12:57 PM, Doug Anderson >>> wrote: > Also when the screen stayed on, the embedded controller's keymap seems > hardcoded to US English with system settings not taking effect; but > surely we don't want per-keyboard device tree files to remedy that. +Benson may be able to answer this. I believe generally non-US keyboard layouts are handled at a higher level. >>> >>> There's no such thing as a notion of US versus non-US keyboard layouts >>> at the embedded controller level or even in the kernel. Indeed, this >>> should all be handled in user space. >>> >>> The chromeos firmware and kernel should return the correct key codes >>> for every key pressed on keyboards with the ANSI layout (US based), or >>> ISO (UK and most other countries). >>> >>> The only differences are : >>> * the ISO keyboard has an extra key, which is immediately to the right >>> of the Left Shift key. This must return KEY_102ND key code from the >>> input layer. >>> * the ISO keyboard has a different location for the | \ key, which >>> accomodates the upside L shaped Enter key on the right side of the >>> keyboard. The keycode for this key is KEY_BACKSLASH. >>> >>> Basically, all of this should be verified using evtest to test that >>> the ec and kernel have the keys right. >> >> Hm, we may be talking about two different things here? I have been doing >> a minimum system bring-up for 3.16, with openSUSE userspace. >> My YaST-selected system keymap (German with deadkeys) is not taking >> effect on German Spring at the *framebuffer console* (tty1) - evdev is >> not involved at that level AIUI. >> >> Backspace and L-shaped enter keys work okay. The keymap here should be >> identical to that in the original German device and seemed to match that >> in the exynos5250-snow.dts file. >> >> I just checked (w/ dp-controller, hdmi, fimd commented out in my patch): >> * An external USB keyboard does not work correctly either. >> * In X11 (xdm), both internal and USB keyboard work as expected. > > Another observation: Ctrl+o does not work on the Chromebook keyboard, > whereas o and Shift+o or Ctrl+x do work as expected. On an external USB > keyboard it works just fine. Same at the console and in X11. > > Testcases are nano (saving) and gEdit (opening). > > I tried the new cros-ec-keyboard.dtsi, no change; and given that the key > itself works okay, I assume it's not the dt linux,keymap. > > Anyone any suggestion how to debug? I guess Ctrl+U is not working either. That's the combination of 2 factors : a. a magic feature on Spring b. a pre-existing bug in the cros_ec_keyb keyboard driver a. On Spring, the AC adapter events are exported as a virtual key in the keyboard matrix (mapped as KEY_BATTERY in the ChromeOS kernel) b. the de-ghosting algorithm in the driver is slightly wrong. In your case, the driver is seeing a (non existing) ghost when Ctrl + O + KEY_BATTERY are pressed, and discarding the key press. As KEY_BATTERY is a virtual key, this ghost obviously cannot exist. To verify that hypothesis, you can try to disconnect your charger (or connect it), and see if the key combination is now working. We might need to upstream a patch similar to : https://chromium-review.googlesource.com/#/c/178539/ to fix the de-ghosting and exclude KEY_BATTERY. >> Similar situation in ChromeOS IIRC, with keymap correct at graphical >> login but not on the right-arrow console - although I don't know the >> ChromeOS userland too well to judge if it was configured correctly. >> >>> If you are having other problems with keyboard layout being stuck to >>> US QWERTY, please check your user space. >> >> On my Raspberry Pi for instance, the equivalent openSUSE Factory works >> just fine with German keymap for USB keyboard. Might any related kernel >> config options be missing in exynos_defconfig? Anything in particular I >> should check in user space? >> >> Cheers, >> Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] ARM: dts: exynos: Prepare Spring
Am 23.06.2014 23:24, schrieb Andreas Färber: > Am 23.06.2014 22:11, schrieb Benson Leung: >> On Mon, Jun 23, 2014 at 12:57 PM, Doug Anderson >> wrote: Also when the screen stayed on, the embedded controller's keymap seems hardcoded to US English with system settings not taking effect; but surely we don't want per-keyboard device tree files to remedy that. >>> >>> +Benson may be able to answer this. I believe generally non-US >>> keyboard layouts are handled at a higher level. >> >> There's no such thing as a notion of US versus non-US keyboard layouts >> at the embedded controller level or even in the kernel. Indeed, this >> should all be handled in user space. >> >> The chromeos firmware and kernel should return the correct key codes >> for every key pressed on keyboards with the ANSI layout (US based), or >> ISO (UK and most other countries). >> >> The only differences are : >> * the ISO keyboard has an extra key, which is immediately to the right >> of the Left Shift key. This must return KEY_102ND key code from the >> input layer. >> * the ISO keyboard has a different location for the | \ key, which >> accomodates the upside L shaped Enter key on the right side of the >> keyboard. The keycode for this key is KEY_BACKSLASH. >> >> Basically, all of this should be verified using evtest to test that >> the ec and kernel have the keys right. > > Hm, we may be talking about two different things here? I have been doing > a minimum system bring-up for 3.16, with openSUSE userspace. > My YaST-selected system keymap (German with deadkeys) is not taking > effect on German Spring at the *framebuffer console* (tty1) - evdev is > not involved at that level AIUI. > > Backspace and L-shaped enter keys work okay. The keymap here should be > identical to that in the original German device and seemed to match that > in the exynos5250-snow.dts file. > > I just checked (w/ dp-controller, hdmi, fimd commented out in my patch): > * An external USB keyboard does not work correctly either. > * In X11 (xdm), both internal and USB keyboard work as expected. Another observation: Ctrl+o does not work on the Chromebook keyboard, whereas o and Shift+o or Ctrl+x do work as expected. On an external USB keyboard it works just fine. Same at the console and in X11. Testcases are nano (saving) and gEdit (opening). I tried the new cros-ec-keyboard.dtsi, no change; and given that the key itself works okay, I assume it's not the dt linux,keymap. Anyone any suggestion how to debug? Thanks, Andreas > Similar situation in ChromeOS IIRC, with keymap correct at graphical > login but not on the right-arrow console - although I don't know the > ChromeOS userland too well to judge if it was configured correctly. > >> If you are having other problems with keyboard layout being stuck to >> US QWERTY, please check your user space. > > On my Raspberry Pi for instance, the equivalent openSUSE Factory works > just fine with German keymap for USB keyboard. Might any related kernel > config options be missing in exynos_defconfig? Anything in particular I > should check in user space? > > Cheers, > Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] ARM: dts: exynos: Prepare Spring
Vincent and Doug, Am 25.06.2014 01:44, schrieb Vincent Palatin: > On Tue, Jun 24, 2014 at 4:18 PM, Andreas Färber wrote: >> Am 23.06.2014 03:21, schrieb Andreas Färber: >>> The display goes dark unfortunately (drm bridge series not yet tested), >>> but I am able to log in via ssh over USB ethernet adapter okay. >> >> Tracked this down to the dp-controller@145B node: The pinctrl seems >> irrelevant, only commenting out the whole node helps keep the display. >> That is, hdmi and fimd nodes don't interfere. >> >> Adding a pwm backlight node like on snow did not help. > > On this board, the backlight is driven by the Parade PS8622 DP-to-LVDS > bridge (rather than a SoC PWM as on Snow). > You need to ensure that the PS8622 GPIOs (Reset/Sleep) are correctly driven > oh, it seems that the PS8622 DRM bridge driver is still in-flight : > https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32243.html Yeah, that's the one I meant with "drm bridge series" above. :) Thanks for confirming. Cheers, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] ARM: dts: exynos: Prepare Spring
On Tue, Jun 24, 2014 at 4:18 PM, Andreas Färber wrote: > Am 23.06.2014 03:21, schrieb Andreas Färber: >> The display goes dark unfortunately (drm bridge series not yet tested), >> but I am able to log in via ssh over USB ethernet adapter okay. > > Tracked this down to the dp-controller@145B node: The pinctrl seems > irrelevant, only commenting out the whole node helps keep the display. > That is, hdmi and fimd nodes don't interfere. > > Adding a pwm backlight node like on snow did not help. On this board, the backlight is driven by the Parade PS8622 DP-to-LVDS bridge (rather than a SoC PWM as on Snow). You need to ensure that the PS8622 GPIOs (Reset/Sleep) are correctly driven oh, it seems that the PS8622 DRM bridge driver is still in-flight : https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32243.html > If it's supposed > to work from GNOME's display brightness slider, it doesn't seem to work. > The 3.8 tree had no backlight node at all. > > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] ARM: dts: exynos: Prepare Spring
Andreas, On Tue, Jun 24, 2014 at 4:18 PM, Andreas Färber wrote: > Am 23.06.2014 03:21, schrieb Andreas Färber: >> The display goes dark unfortunately (drm bridge series not yet tested), >> but I am able to log in via ssh over USB ethernet adapter okay. > > Tracked this down to the dp-controller@145B node: The pinctrl seems > irrelevant, only commenting out the whole node helps keep the display. > That is, hdmi and fimd nodes don't interfere. Adding Rahul from Samsung. I don't know that he's ever tested things on exynos5250-spring but he might be able to point you in the right direction. > Adding a pwm backlight node like on snow did not help. If it's supposed > to work from GNOME's display brightness slider, it doesn't seem to work. > The 3.8 tree had no backlight node at all. I do know that we don't want the exynos pwm backlight for spring. On spring the backlight is controlled completely by the bridge chip which has a PWM on it. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] ARM: dts: exynos: Prepare Spring
Am 23.06.2014 03:21, schrieb Andreas Färber: > The display goes dark unfortunately (drm bridge series not yet tested), > but I am able to log in via ssh over USB ethernet adapter okay. Tracked this down to the dp-controller@145B node: The pinctrl seems irrelevant, only commenting out the whole node helps keep the display. That is, hdmi and fimd nodes don't interfere. Adding a pwm backlight node like on snow did not help. If it's supposed to work from GNOME's display brightness slider, it doesn't seem to work. The 3.8 tree had no backlight node at all. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] ARM: dts: exynos: Prepare Spring
Am 23.06.2014 22:11, schrieb Benson Leung: > On Mon, Jun 23, 2014 at 12:57 PM, Doug Anderson wrote: >>> Also when the screen stayed on, the embedded controller's keymap seems >>> hardcoded to US English with system settings not taking effect; but >>> surely we don't want per-keyboard device tree files to remedy that. >> >> +Benson may be able to answer this. I believe generally non-US >> keyboard layouts are handled at a higher level. > > There's no such thing as a notion of US versus non-US keyboard layouts > at the embedded controller level or even in the kernel. Indeed, this > should all be handled in user space. > > The chromeos firmware and kernel should return the correct key codes > for every key pressed on keyboards with the ANSI layout (US based), or > ISO (UK and most other countries). > > The only differences are : > * the ISO keyboard has an extra key, which is immediately to the right > of the Left Shift key. This must return KEY_102ND key code from the > input layer. > * the ISO keyboard has a different location for the | \ key, which > accomodates the upside L shaped Enter key on the right side of the > keyboard. The keycode for this key is KEY_BACKSLASH. > > Basically, all of this should be verified using evtest to test that > the ec and kernel have the keys right. Hm, we may be talking about two different things here? I have been doing a minimum system bring-up for 3.16, with openSUSE userspace. My YaST-selected system keymap (German with deadkeys) is not taking effect on German Spring at the *framebuffer console* (tty1) - evdev is not involved at that level AIUI. Backspace and L-shaped enter keys work okay. The keymap here should be identical to that in the original German device and seemed to match that in the exynos5250-snow.dts file. I just checked (w/ dp-controller, hdmi, fimd commented out in my patch): * An external USB keyboard does not work correctly either. * In X11 (xdm), both internal and USB keyboard work as expected. Similar situation in ChromeOS IIRC, with keymap correct at graphical login but not on the right-arrow console - although I don't know the ChromeOS userland too well to judge if it was configured correctly. > If you are having other problems with keyboard layout being stuck to > US QWERTY, please check your user space. On my Raspberry Pi for instance, the equivalent openSUSE Factory works just fine with German keymap for USB keyboard. Might any related kernel config options be missing in exynos_defconfig? Anything in particular I should check in user space? Cheers, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] ARM: dts: exynos: Prepare Spring
On Mon, Jun 23, 2014 at 12:57 PM, Doug Anderson wrote: >> Also when the screen stayed on, the embedded controller's keymap seems >> hardcoded to US English with system settings not taking effect; but >> surely we don't want per-keyboard device tree files to remedy that. > > +Benson may be able to answer this. I believe generally non-US > keyboard layouts are handled at a higher level. There's no such thing as a notion of US versus non-US keyboard layouts at the embedded controller level or even in the kernel. Indeed, this should all be handled in user space. The chromeos firmware and kernel should return the correct key codes for every key pressed on keyboards with the ANSI layout (US based), or ISO (UK and most other countries). The only differences are : * the ISO keyboard has an extra key, which is immediately to the right of the Left Shift key. This must return KEY_102ND key code from the input layer. * the ISO keyboard has a different location for the | \ key, which accomodates the upside L shaped Enter key on the right side of the keyboard. The keycode for this key is KEY_BACKSLASH. Basically, all of this should be verified using evtest to test that the ec and kernel have the keys right. If you are having other problems with keyboard layout being stuck to US QWERTY, please check your user space. -- Benson Leung Software Engineer, Chrom* OS ble...@chromium.org -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] ARM: dts: exynos: Prepare Spring
Andreas, On Sun, Jun 22, 2014 at 6:21 PM, Andreas Färber wrote: > From: Andreas Färber > > Hello, > > Based on the preinstalled 3.8 based ChromeOS kernel and previous 3.15 > based attempts by Stephan and me that broke for 3.16, I've prepared a > device tree for the HP Chromebook 11 aka Google Spring. > > The first three patches should be good to go and contain documentation > fixes found while comparing exynos5250-snow.dts vs. /proc/device-tree. > > The main patch was tested using a chained non-verified U-Boot (simplefb) > and a rootfs on USB-attached SD card. > The display goes dark unfortunately (drm bridge series not yet tested), > but I am able to log in via ssh over USB ethernet adapter okay. > > Audio support is likely missing as my focus was getting USB booting. > Not included is touchpad support, as "atmel,atmel_mxt_tp" is not > documented to be available upstream. And no /dev/mmcblk0 or Wifi yet. > Also when the screen stayed on, the embedded controller's keymap seems > hardcoded to US English with system settings not taking effect; but > surely we don't want per-keyboard device tree files to remedy that. +Benson may be able to answer this. I believe generally non-US keyboard layouts are handled at a higher level. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/4] ARM: dts: exynos: Prepare Spring
From: Andreas Färber Hello, Based on the preinstalled 3.8 based ChromeOS kernel and previous 3.15 based attempts by Stephan and me that broke for 3.16, I've prepared a device tree for the HP Chromebook 11 aka Google Spring. The first three patches should be good to go and contain documentation fixes found while comparing exynos5250-snow.dts vs. /proc/device-tree. The main patch was tested using a chained non-verified U-Boot (simplefb) and a rootfs on USB-attached SD card. The display goes dark unfortunately (drm bridge series not yet tested), but I am able to log in via ssh over USB ethernet adapter okay. Audio support is likely missing as my focus was getting USB booting. Not included is touchpad support, as "atmel,atmel_mxt_tp" is not documented to be available upstream. And no /dev/mmcblk0 or Wifi yet. Also when the screen stayed on, the embedded controller's keymap seems hardcoded to US English with system settings not taking effect; but surely we don't want per-keyboard device tree files to remedy that. I'd appreciate if we can get a core .dts sorted out and consider incremental changes from there. Regards, Andreas Andreas Färber (4): Documentation: devicetree: Fix s2mps11 and s5m8767 typos Documentation: devicetree: Fix s2mps11 example syntax Documentation: devicetree: Fix tps65090 typos ARM: dts: exynos5250: Add Spring device tree Documentation/devicetree/bindings/mfd/s2mps11.txt | 4 +- .../bindings/regulator/s5m8767-regulator.txt | 2 +- .../devicetree/bindings/regulator/tps65090.txt | 4 +- arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/exynos5250-spring.dts| 556 + 5 files changed, 562 insertions(+), 5 deletions(-) create mode 100644 arch/arm/boot/dts/exynos5250-spring.dts -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
