Hi all, I have added the latest patches and now it works!
But only if I either add an alias for tca8418 - or modprobe tca8418_keypad.
So there is still some confusion in the driver binding/matching/loading.
I tried to fgrep for tca8418 in the whole source tree - but did only find references to tca8418_keypad. Including my device tree.
modprobe -c also only knows tca8418_keypad
But still the kernel reports:
root@gta04:~# more /sys/devices/ocp.3/4807a000.i2c/i2c-3/3-0034/name tca8418 root@gta04:~# more /proc/device-tree/ocp/i2c@4807a000/tca8418_keypad@34/name tca8418_keypad root@gta04:~#
I don't know where the name entry in /sys/devices comes from. So I start to think there is some hidden code to strip off the _keypad from the DT node name...
Maybe something in the i2c driver is forming the name "i2c:tca8418" *and* stripping off the _keypad from the DT node name. This would be an unexpected strange side-effect of choosing a driver file name with an underscore.
So I now understand why the 0006-add-tca8418_keypad-tca8418-alias.patch makes it work as a work-around. But I don't understand why we really should need it...
Ok, after some more grepping around I found this in drivers/of/base.c:
/** * of_modalias_node - Lookup appropriate modalias for a device node * @node: pointer to a device tree node * @modalias: Pointer to buffer that modalias value will be copied into * @len: Length of modalias value * * Based on the value of the compatible property, this routine will attempt * to choose an appropriate modalias value for a particular device tree node. * It does this by stripping the manufacturer prefix (as delimited by a ',') * from the first entry in the compatible list property. * * This routine returns 0 on success, <0 on failure. */
So this means that the module name is finally formed by
"i2c:" + second_component_of(property("compatible"))
Therefore it is indeed "i2c:tca8418" what the DT loader looks for! And it is *not* the "name" property of the DT node which is what I had expected in my ignorance :)
Now, since the module has a different name, we need this alias and those people who made the driver "DT ready" did not recognise.
And I have added a comment to the device tree/driver.
Anyways, this it is a good piece of knowledge about the guts of the Linux kernel.
BR, Nikolaus
PS: sources and kernel binary are pushed
Am Sun, 26 Jan 2014 17:48:17 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
okay, I now connected the DragonAdaptor to the Pyra as well, with mixed results. Upgraded to the latest kernel.
As soon as it's connected, the serial shell spits out hundreds of messages: omap_i2c 4807a000.i2c: timeout waiting for bus ready
I guess that's what you're talking about in this post, right?
Nub buttons as well as shoulder buttons do work well, as they trigger characters.
What does NOT seem to work is mouse movement for the nubs. /proc/pandora is empty (should be nub0 and nub1 in there), and I also didn't find that anywhere else. I am not sure what settings the nubs are in and how I can change that.
Another thing I don't know about yet are the keyboard LEDs. Didn't find anything in userspace and they don't do anything on boot.
Is that what's expected?
Hi all, I have added the latest patches and now it works!
But only if I either add an alias for tca8418 - or modprobe tca8418_keypad.
So there is still some confusion in the driver binding/matching/loading.
I tried to fgrep for tca8418 in the whole source tree - but did only find references to tca8418_keypad. Including my device tree.
modprobe -c also only knows tca8418_keypad
But still the kernel reports:
root@gta04:~# more /sys/devices/ocp.3/4807a000.i2c/i2c-3/3-0034/name tca8418 root@gta04:~# root@more /proc/device-tree/ocp/i2c@4807a000/tca8418_keypad@34/name tca8418_keypad root@gta04:~#
I don't know where the name entry in /sys/devices comes from. So I start to think there is some hidden code to strip off the _keypad from the DT node name...
Maybe something in the i2c driver is forming the name "i2c:tca8418" *and* stripping off the _keypad from the DT node name. This would be an unexpected strange side-effect of choosing a driver file name with an underscore.
So I now understand why the 0006-add-tca8418_keypad-tca8418-alias.patch makes it work as a work-around. But I don't understand why we really should need it...
Ok, after some more grepping around I found this in drivers/of/base.c:
/**
- of_modalias_node - Lookup appropriate modalias for a device node
- @node: pointer to a device tree node
- @modalias: Pointer to buffer that modalias value will be
copied into
- @len: Length of modalias value
- Based on the value of the compatible property, this routine will
attempt
- to choose an appropriate modalias value for a particular device
tree node.
- It does this by stripping the manufacturer prefix (as delimited by
a ',')
- from the first entry in the compatible list property.
- This routine returns 0 on success, <0 on failure.
*/
So this means that the module name is finally formed by
"i2c:" + second_component_of(property("compatible"))
Therefore it is indeed "i2c:tca8418" what the DT loader looks for! And it is *not* the "name" property of the DT node which is what I had expected in my ignorance :)
Now, since the module has a different name, we need this alias and those people who made the driver "DT ready" did not recognise.
And I have added a comment to the device tree/driver.
Anyways, this it is a good piece of knowledge about the guts of the Linux kernel.
BR, Nikolaus
PS: sources and kernel binary are pushed _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Hi,
Am 27.01.2014 um 03:13 schrieb Michael Mrozek:
Am Sun, 26 Jan 2014 17:48:17 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
okay, I now connected the DragonAdaptor to the Pyra as well, with mixed results. Upgraded to the latest kernel.
As soon as it's connected, the serial shell spits out hundreds of messages: omap_i2c 4807a000.i2c: timeout waiting for bus ready
Hm. That should not be. Looks like a general I2C problem :(
I guess that's what you're talking about in this post, right?
Not exactly. It was about initializing the keyboard controller at all.
Nub buttons as well as shoulder buttons do work well, as they trigger characters.
What does NOT seem to work is mouse movement for the nubs. /proc/pandora is empty (should be nub0 and nub1 in there), and I also didn't find that anywhere else.
How many and which entries do you see in /dev/input/event* There should be 5 entries.
I am not sure what settings the nubs are in and how I can change that.
Another thing I don't know about yet are the keyboard LEDs. Didn't find anything in userspace and they don't do anything on boot.
They should blink right after boot.
Did you connect the USB and HDMI cables before power on? The USB cable powers the LEDs and other things.
Is that what's expected?
Only partially.
Is this reproducible that there are I2C errors? And please send me the dmesg log.
Hi all, I have added the latest patches and now it works!
But only if I either add an alias for tca8418 - or modprobe tca8418_keypad.
So there is still some confusion in the driver binding/matching/loading.
I tried to fgrep for tca8418 in the whole source tree - but did only find references to tca8418_keypad. Including my device tree.
modprobe -c also only knows tca8418_keypad
But still the kernel reports:
root@gta04:~# more /sys/devices/ocp.3/4807a000.i2c/i2c-3/3-0034/name tca8418 root@gta04:~# root@more /proc/device-tree/ocp/i2c@4807a000/tca8418_keypad@34/name tca8418_keypad root@gta04:~#
I don't know where the name entry in /sys/devices comes from. So I start to think there is some hidden code to strip off the _keypad from the DT node name...
Maybe something in the i2c driver is forming the name "i2c:tca8418" *and* stripping off the _keypad from the DT node name. This would be an unexpected strange side-effect of choosing a driver file name with an underscore.
So I now understand why the 0006-add-tca8418_keypad-tca8418-alias.patch makes it work as a work-around. But I don't understand why we really should need it...
Ok, after some more grepping around I found this in drivers/of/base.c:
/**
- of_modalias_node - Lookup appropriate modalias for a device node
- @node: pointer to a device tree node
- @modalias: Pointer to buffer that modalias value will be
copied into
- @len: Length of modalias value
- Based on the value of the compatible property, this routine will
attempt
- to choose an appropriate modalias value for a particular device
tree node.
- It does this by stripping the manufacturer prefix (as delimited by
a ',')
- from the first entry in the compatible list property.
- This routine returns 0 on success, <0 on failure.
*/
So this means that the module name is finally formed by
"i2c:" + second_component_of(property("compatible"))
Therefore it is indeed "i2c:tca8418" what the DT loader looks for! And it is *not* the "name" property of the DT node which is what I had expected in my ignorance :)
Now, since the module has a different name, we need this alias and those people who made the driver "DT ready" did not recognise.
And I have added a comment to the device tree/driver.
Anyways, this it is a good piece of knowledge about the guts of the Linux kernel.
BR, Nikolaus
PS: sources and kernel binary are pushed _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On Mon, Jan 27, 2014 at 4:13 AM, Michael Mrozek EvilDragon@openpandora.org wrote:
As soon as it's connected, the serial shell spits out hundreds of messages: omap_i2c 4807a000.i2c: timeout waiting for bus ready
I guess that's what you're talking about in this post, right?
Nub buttons as well as shoulder buttons do work well, as they trigger characters.
What does NOT seem to work is mouse movement for the nubs. /proc/pandora is empty (should be nub0 and nub1 in there), and I also didn't find that anywhere else.
Sounds like the driver failed to probe because of i2c errors, check dmesg for lines with "as5013".
Gražvydas
Am 27.01.2014 um 11:55 schrieb Grazvydas Ignotas:
On Mon, Jan 27, 2014 at 4:13 AM, Michael Mrozek EvilDragon@openpandora.org wrote:
As soon as it's connected, the serial shell spits out hundreds of messages: omap_i2c 4807a000.i2c: timeout waiting for bus ready
I guess that's what you're talking about in this post, right?
Nub buttons as well as shoulder buttons do work well, as they trigger characters.
What does NOT seem to work is mouse movement for the nubs. /proc/pandora is empty (should be nub0 and nub1 in there), and I also didn't find that anywhere else.
Sounds like the driver failed to probe because of i2c errors, check dmesg for lines with "as5013".
Yes, on my setup I have:
root@gta04:~# ls -l /proc/pandora/nub* /proc/pandora/nub0: total 0 -rw-rw-rw- 1 root root 0 Jan 27 11:00 mbutton_delay -rw-rw-rw- 1 root root 0 Jan 27 11:00 mbutton_threshold -rw-rw-rw- 1 root root 0 Jan 27 11:00 mbutton_threshold_y -rw-rw-rw- 1 root root 0 Jan 27 11:00 mode -rw-rw-rw- 1 root root 0 Jan 27 11:00 mouse_sensitivity -rw-rw-rw- 1 root root 0 Jan 27 11:00 scroll_rate -rw-rw-rw- 1 root root 0 Jan 27 11:00 scrollx_sensitivity -rw-rw-rw- 1 root root 0 Jan 27 11:00 scrolly_sensitivity
/proc/pandora/nub1: total 0 -rw-rw-rw- 1 root root 0 Jan 27 11:00 mbutton_delay -rw-rw-rw- 1 root root 0 Jan 27 11:00 mbutton_threshold -rw-rw-rw- 1 root root 0 Jan 27 11:00 mbutton_threshold_y -rw-rw-rw- 1 root root 0 Jan 27 11:00 mode -rw-rw-rw- 1 root root 0 Jan 27 11:00 mouse_sensitivity -rw-rw-rw- 1 root root 0 Jan 27 11:00 scroll_rate -rw-rw-rw- 1 root root 0 Jan 27 11:00 scrollx_sensitivity -rw-rw-rw- 1 root root 0 Jan 27 11:00 scrolly_sensitivity root@gta04:~#
BR, Nikolaus
Am Mon, 27 Jan 2014 12:02:16 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Just a quick notice: With power over USB both the nubs and the LEDs work fine on my board as well :)
The nubs REALLY are accurate :D
Hi,
now that the LEDs are working, where can I find them in the userspace to switch them on / off, change color of RGB ones, change the brightness, etc.?
HI,
Am 28.01.2014 um 04:33 schrieb Michael Mrozek:
Hi,
now that the LEDs are working, where can I find them in the userspace to switch them on / off, change color of RGB ones, change the brightness, etc.?
You can find all controllable LEDs in
/sys/class/leds
For each LED you can set
* trigger ("cat trigger" to see the available values), e.g.
cat "/sys/class/leds/test::led-l-blue/trigger" none nand-disk mmc0 mmc1 mmc2 [timer] oneshot heartbeat backlight gpio cpu0 cpu1 default-on
echo "none" > "/sys/class/leds/test::led-l-blue/trigger"
* brightness - you can read and write values 0 ... 255 * max_brightness - should be 255
Some more notes on the current circuit (can/will be changed in the final version): * RGB - you can set the red, green, blue LEDs individually * only the left RGB LED can be controlled (the right one is always blue with a dimmed red component) * the 16 keypad LEDs are 4 groups of 4 LEDs
BR, Nikolaus