From: Larry L. <lar...@gm...> - 2011-01-30 15:24:56
|
Hello! I'm running Ubuntu 10.10 using a 2.6.37-12 kernel on my Asus S1-AT5NM10E (http://www.asus.com/product.aspx?P_ID=PBY1wFg4r0bOWE5O&templete=2). uname -a: Linux htpc 2.6.37-12-generic #26-Ubuntu SMP Wed Jan 5 18:38:48 UTC 2011 x86_64 GNU/Linux The barebone has an integrated ir-receiver. Running the "lspnp | grep NTN0530" command returns: 00:0a NTN0530 (unknown) NTN0530 seems to be the CIR device, so I think the Nuvoton driver shpuld be the correct one for my device. lshal contains the following lines: udi = '/org/freedesktop/Hal/devices/pnp_NTN0530' info.parent = '/org/freedesktop/Hal/devices/computer' (string) info.product = 'PnP Device (NTN0530)' (string) info.subsystem = 'pnp' (string) info.udi = '/org/freedesktop/Hal/devices/pnp_NTN0530' (string) linux.hotplug_type = 2 (0x2) (int) linux.subsystem = 'pnp' (string) linux.sysfs_path = '/sys/devices/pnp0/00:0a' (string) pnp.id = 'NTN0530' (string) lsmod | grep nuvoton returns nuvoton_cir 21940 0 ir_core 26463 8 ir_lirc_codec,dvb_usb,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,ir_nec_decoder,nuvoton_cir nuvoton_cir module seems to be loaded. modinfo nuvoton_cir returns: filename: /lib/modules/2.6.37-12-generic/kernel/drivers/media/IR/nuvoton-cir.ko license: GPL author: Jarod Wilson <ja...@re...> description: Nuvoton W83667HG-A & W83677HG-I CIR driver srcversion: 98C832A95EDC5626195F2C2 alias: acpi*:NTN0530:* alias: pnp:dNTN0530* alias: acpi*:WEC0530:* alias: pnp:dWEC0530* depends: ir-core vermagic: 2.6.37-12-generic SMP mod_unload modversions parm: debug:Enable debugging output (int) lircd -v: lircd 0.8.7-pre3 I've read this mailing list discussion: http://web.archiveorange.com/archive/v/Xn95HuDMoxZsBijQErRL Jaros said that it looks like the driver didn't find any device to bind to. I don't have a /dev/lirc0 device, too... there is just a /dev/lircd. Maybe that's the reason why it doesn't work? Does the nuvoton_cir driver not recognize my device although it's a NTN0530 like the ASRock ION330HT has? Do you have any ideas and/or recommendations? I four need any further information just let me know. Thanks for your help. Kind regards Larry Lobster |
From: Jarod W. <ja...@wi...> - 2011-01-30 17:21:07
|
On Jan 30, 2011, at 10:24 AM, Larry Lobster wrote: > Hello! > > I'm running Ubuntu 10.10 using a 2.6.37-12 kernel on my Asus S1-AT5NM10E > (http://www.asus.com/product.aspx?P_ID=PBY1wFg4r0bOWE5O&templete=2). > > uname -a: > Linux htpc 2.6.37-12-generic #26-Ubuntu SMP Wed Jan 5 18:38:48 UTC 2011 > x86_64 GNU/Linux > > The barebone has an integrated ir-receiver. Running the "lspnp | grep > NTN0530" command returns: > 00:0a NTN0530 (unknown) > > NTN0530 seems to be the CIR device, so I think the Nuvoton driver shpuld > be the correct one for my device. > > lshal contains the following lines: > udi = '/org/freedesktop/Hal/devices/pnp_NTN0530' > info.parent = '/org/freedesktop/Hal/devices/computer' (string) > info.product = 'PnP Device (NTN0530)' (string) > info.subsystem = 'pnp' (string) > info.udi = '/org/freedesktop/Hal/devices/pnp_NTN0530' (string) > linux.hotplug_type = 2 (0x2) (int) > linux.subsystem = 'pnp' (string) > linux.sysfs_path = '/sys/devices/pnp0/00:0a' (string) > pnp.id = 'NTN0530' (string) > > > lsmod | grep nuvoton returns > nuvoton_cir 21940 0 > ir_core 26463 8 > ir_lirc_codec,dvb_usb,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,ir_nec_decoder,nuvoton_cir > > nuvoton_cir module seems to be loaded. > > modinfo nuvoton_cir returns: > filename: > /lib/modules/2.6.37-12-generic/kernel/drivers/media/IR/nuvoton-cir.ko > license: GPL > author: Jarod Wilson <ja...@re...> > description: Nuvoton W83667HG-A & W83677HG-I CIR driver > srcversion: 98C832A95EDC5626195F2C2 > alias: acpi*:NTN0530:* > alias: pnp:dNTN0530* > alias: acpi*:WEC0530:* > alias: pnp:dWEC0530* > depends: ir-core > vermagic: 2.6.37-12-generic SMP mod_unload modversions > parm: debug:Enable debugging output (int) > > lircd -v: > lircd 0.8.7-pre3 > > I've read this mailing list discussion: > http://web.archiveorange.com/archive/v/Xn95HuDMoxZsBijQErRL > Jaros said that it looks like the driver didn't find any device to bind > to. I don't have a /dev/lirc0 device, too... there is just a /dev/lircd. > Maybe that's the reason why it doesn't work? > > Does the nuvoton_cir driver not recognize my device although it's a > NTN0530 like the ASRock ION330HT has? > > Do you have any ideas and/or recommendations? I four need any further > information just let me know. Unload nuvoton-cir, then reload it, using 'modprobe nuvoton-cir debug=3' and send along the output from dmesg after doing that. -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2011-01-30 18:39:58
|
On Jan 30, 2011, at 1:18 PM, Larry Lobster wrote: > nuvoton_cir: w836x7hg: chip id: 0xa5 0x13 Please keep your replies on the mailing list, and please don't top-post, both have a tendency to reduce my desire to reply. :) So this is a completely new and unexpected Chip ID. The driver is looking for 0xb4 0x72 and 0xb4 0x73, and refuses to load otherwise, returning an -ENODEV. Even without module debugging enabled, dmesg should contain a line something like this: nuvoton_cir: w836x7hg: unsupported chip, id: 0xa5 0x13 I have no idea if this hardware is meaningfully different than the chips the driver does claim to support, but it would be trivial to test if the driver works or not by simply commenting out the section of nvt_hw_detect() in nuvoton-cir.c that checks chip ID. I can drop a line to my contact at Nuvoton as well to get official word on what's different, but for now, there's why its not working. > Am 30.01.2011 18:20, schrieb Jarod Wilson: >> On Jan 30, 2011, at 10:24 AM, Larry Lobster wrote: >> >>> Hello! >>> >>> I'm running Ubuntu 10.10 using a 2.6.37-12 kernel on my Asus S1-AT5NM10E >>> (http://www.asus.com/product.aspx?P_ID=PBY1wFg4r0bOWE5O&templete=2). >>> >>> uname -a: >>> Linux htpc 2.6.37-12-generic #26-Ubuntu SMP Wed Jan 5 18:38:48 UTC 2011 >>> x86_64 GNU/Linux >>> >>> The barebone has an integrated ir-receiver. Running the "lspnp | grep >>> NTN0530" command returns: >>> 00:0a NTN0530 (unknown) ... >>> Does the nuvoton_cir driver not recognize my device although it's a >>> NTN0530 like the ASRock ION330HT has? >>> >>> Do you have any ideas and/or recommendations? I four need any further >>> information just let me know. >> Unload nuvoton-cir, then reload it, using 'modprobe nuvoton-cir debug=3' and >> send along the output from dmesg after doing that. -- Jarod Wilson ja...@wi... |
From: Larry L. <lar...@gm...> - 2011-01-30 19:08:46
|
> Please keep your replies on the mailing list, and please don't top-post, > both have a tendency to reduce my desire to reply. :) I'm sorry, I hope everything is fine this way :-) > So this is a completely new and unexpected Chip ID. The driver is looking > for 0xb4 0x72 and 0xb4 0x73, and refuses to load otherwise, returning an > -ENODEV. Even without module debugging enabled, dmesg should contain a > line something like this: > > nuvoton_cir: w836x7hg: unsupported chip, id: 0xa5 0x13 > > I have no idea if this hardware is meaningfully different than the chips > the driver does claim to support, but it would be trivial to test if the > driver works or not by simply commenting out the section of nvt_hw_detect() > in nuvoton-cir.c that checks chip ID. I can drop a line to my contact at > Nuvoton as well to get official word on what's different, but for now, > there's why its not working. Thanks for explaining the reason why it's not working. Are there any tutorials or how-tos how to get, change and recompile the sources? Unfortunately I'm not that famliar in doing these things as I'm I'm just a dumb Linux end-user. I really like to provide more information in order to help you adjusting the driver. |
From: Jarod W. <ja...@wi...> - 2011-01-30 20:02:26
|
On Jan 30, 2011, at 2:08 PM, Larry Lobster wrote: > >> Please keep your replies on the mailing list, and please don't top-post, >> both have a tendency to reduce my desire to reply. :) > I'm sorry, I hope everything is fine this way :-) Yes, much better, thank you. >> So this is a completely new and unexpected Chip ID. The driver is looking >> for 0xb4 0x72 and 0xb4 0x73, and refuses to load otherwise, returning an >> -ENODEV. Even without module debugging enabled, dmesg should contain a >> line something like this: >> >> nuvoton_cir: w836x7hg: unsupported chip, id: 0xa5 0x13 >> >> I have no idea if this hardware is meaningfully different than the chips >> the driver does claim to support, but it would be trivial to test if the >> driver works or not by simply commenting out the section of nvt_hw_detect() >> in nuvoton-cir.c that checks chip ID. I can drop a line to my contact at >> Nuvoton as well to get official word on what's different, but for now, >> there's why its not working. > Thanks for explaining the reason why it's not working. > > Are there any tutorials or how-tos how to get, change and recompile the > sources? Unfortunately I'm not that famliar in doing these things as I'm > I'm just a dumb Linux end-user. > > I really like to provide more information in order to help you adjusting > the driver. Well, there are a few ways to go about this... 1) download upstream kernel source, edit drivers/media/rc/nuvoton-cir.c, and then compile kernel, install and boot the new kernel 2) get your distro kernel's source, unpack it, make the same edit, and with the matching linux-headers (or whatever its called on Ubuntu), compile just the bits under drivers/media/rc/ against the running kernel's headers, manually copy them into place, reboot 3) use linuxtv.org media_build infra to get a module tree that'll work with your currently running kernel, edit linux/drivers/media/rc/nuvoton-cir.c and then compile modules, install, reboot #3 should be fairly well documented here, its what I'd recommend: http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers -- Jarod Wilson ja...@wi... |
From: Larry L. <lar...@gm...> - 2011-01-31 19:00:48
|
> Well, there are a few ways to go about this... > > 1) download upstream kernel source, edit drivers/media/rc/nuvoton-cir.c, and > then compile kernel, install and boot the new kernel > > 2) get your distro kernel's source, unpack it, make the same edit, and with the > matching linux-headers (or whatever its called on Ubuntu), compile just the bits > under drivers/media/rc/ against the running kernel's headers, manually copy them > into place, reboot > > 3) use linuxtv.org media_build infra to get a module tree that'll work with > your currently running kernel, edit linux/drivers/media/rc/nuvoton-cir.c and > then compile modules, install, reboot > > > #3 should be fairly well documented here, its what I'd recommend: > > http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers > Ok, I have edited drivers/media/IR/nuvoton-cir.h and as a quick fix for my box I redefined some constants: /* Chip IDs found in CR_CHIP_ID_{HI,LO} */ #define CHIP_ID_HIGH 0xa5 #define CHIP_ID_LOW 0x13 #define CHIP_ID_LOW2 0x13 After building and rebooting dmesg | grep uvoton shows this: [ 5.103115] input: Nuvoton w836x7hg Infrared Remote Transceiver as /devices/virtual/rc/rc0/input4 [ 5.104241] rc0: Nuvoton w836x7hg Infrared Remote Transceiver as /devices/virtual/rc/rc0 [ 5.104253] nuvoton_cir: driver has been successfully loaded [ 5.765267] rc rc0: lirc_dev: driver ir-lirc-codec (nuvoton-cir) registered at minor = 0 Great! Ok, cat /proc/bus/input/devices returns I: Bus=0019 Vendor=1050 Product=00a5 Version=0013 N: Name="Nuvoton w836x7hg Infrared Remote Transceiver" P: Phys= S: Sysfs=/devices/virtual/rc/rc0/input4 U: Uniq= H: Handlers=kbd event4 B: EV=100013 B: KEY=fff 0 108fc326 217605100000000 0 700158000 419000100001 9e968000000000 10000000 B: MSC=10 Now it could be time to paste my lirc-config: This is my /etc/lirc/hardware.conf: REMOTE="Linux input layer (/dev/input/eventX)" REMOTE_MODULES="" REMOTE_DRIVER="devinput" REMOTE_DEVICE="/dev/input/event4" REMOTE_SOCKET="" REMOTE_LIRCD_CONF="devinput/lircd.conf.devinput" REMOTE_LIRCD_ARGS="" TRANSMITTER="None" TRANSMITTER_MODULES="" TRANSMITTER_DRIVER="" TRANSMITTER_DEVICE="" TRANSMITTER_SOCKET="" TRANSMITTER_LIRCD_CONF="" TRANSMITTER_LIRCD_ARGS="" START_LIRCD="true" START_LIRCMD="" LOAD_MODULES="" LIRCMD_CONF="" FORCE_NONINTERACTIVE_RECONFIGURATION="false" And my lircd.conf include "/usr/share/lirc/remotes/devinput/lircd.conf.devinput" ps aux | grep lirc returns: /usr/sbin/lircd --output=/var/run/lirc/lircd --driver=devinput --device=/dev/input/event4 I tried "irw" and pushed some buttons on my remote control .. and nothing happens :-( For sure there might be several reasons: First of all I would like to make sure the configuration is correct. I use a Harmony 600 Remote control and I'm not sure what's the correct profile to choose. Currently i try to use the MicrosoftWindows Media Center profile. Thanks for the help so far! |
From: Jarod W. <ja...@wi...> - 2011-01-31 19:59:36
|
On Jan 31, 2011, at 2:00 PM, Larry Lobster wrote: > >> Well, there are a few ways to go about this... >> >> 1) download upstream kernel source, edit drivers/media/rc/nuvoton-cir.c, and >> then compile kernel, install and boot the new kernel >> >> 2) get your distro kernel's source, unpack it, make the same edit, and with the >> matching linux-headers (or whatever its called on Ubuntu), compile just the bits >> under drivers/media/rc/ against the running kernel's headers, manually copy them >> into place, reboot >> >> 3) use linuxtv.org media_build infra to get a module tree that'll work with >> your currently running kernel, edit linux/drivers/media/rc/nuvoton-cir.c and >> then compile modules, install, reboot >> >> >> #3 should be fairly well documented here, its what I'd recommend: >> >> http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers >> > Ok, I have edited drivers/media/IR/nuvoton-cir.h and as a quick fix for > my box I redefined some constants: > /* Chip IDs found in CR_CHIP_ID_{HI,LO} */ > #define CHIP_ID_HIGH 0xa5 > #define CHIP_ID_LOW 0x13 > #define CHIP_ID_LOW2 0x13 > > After building and rebooting dmesg | grep uvoton shows this: > [ 5.103115] input: Nuvoton w836x7hg Infrared Remote Transceiver as > /devices/virtual/rc/rc0/input4 > [ 5.104241] rc0: Nuvoton w836x7hg Infrared Remote Transceiver as > /devices/virtual/rc/rc0 > [ 5.104253] nuvoton_cir: driver has been successfully loaded > [ 5.765267] rc rc0: lirc_dev: driver ir-lirc-codec (nuvoton-cir) > registered at minor = 0 > > Great! Cool, progress. > Ok, cat /proc/bus/input/devices returns > I: Bus=0019 Vendor=1050 Product=00a5 Version=0013 > N: Name="Nuvoton w836x7hg Infrared Remote Transceiver" > P: Phys= > S: Sysfs=/devices/virtual/rc/rc0/input4 > U: Uniq= > H: Handlers=kbd event4 > B: EV=100013 > B: KEY=fff 0 108fc326 217605100000000 0 700158000 419000100001 > 9e968000000000 10000000 > B: MSC=10 > > Now it could be time to paste my lirc-config: > > This is my /etc/lirc/hardware.conf: > REMOTE="Linux input layer (/dev/input/eventX)" > REMOTE_MODULES="" > REMOTE_DRIVER="devinput" > REMOTE_DEVICE="/dev/input/event4" > REMOTE_SOCKET="" > REMOTE_LIRCD_CONF="devinput/lircd.conf.devinput" > REMOTE_LIRCD_ARGS="" > TRANSMITTER="None" > TRANSMITTER_MODULES="" > TRANSMITTER_DRIVER="" > TRANSMITTER_DEVICE="" > TRANSMITTER_SOCKET="" > TRANSMITTER_LIRCD_CONF="" > TRANSMITTER_LIRCD_ARGS="" > START_LIRCD="true" > START_LIRCMD="" > LOAD_MODULES="" > LIRCMD_CONF="" > FORCE_NONINTERACTIVE_RECONFIGURATION="false" > > And my lircd.conf > include "/usr/share/lirc/remotes/devinput/lircd.conf.devinput" > > ps aux | grep lirc returns: > /usr/sbin/lircd --output=/var/run/lirc/lircd --driver=devinput > --device=/dev/input/event4 > > I tried "irw" and pushed some buttons on my remote control > .. and nothing happens :-( > > For sure there might be several reasons: First of all I would like to > make sure the configuration is correct. It looks sane, from what I can tell, but lets have you try something else first. Stop lircd and run mode2. Press some buttons on the remote and see if mode2 spits anything out (it should). You should also be able to run the driver in debug mode to get some additional data out of it via dmesg. Results from this testing ought to give us a better idea whether or not we're at least getting some data from the hardware. -- Jarod Wilson ja...@wi... |
From: Larry L. <lar...@gm...> - 2011-01-31 21:25:04
|
> It looks sane, from what I can tell, but lets have you try something > else first. Stop lircd and run mode2. Press some buttons on the remote > and see if mode2 spits anything out (it should). You should also be > able to run the driver in debug mode to get some additional data out > of it via dmesg. Results from this testing ought to give us a better > idea whether or not we're at least getting some data from the hardware. > I stopped lirc and tried mode2 --device=/dev/lirc0 : No reaction on button presses I reloaded the driver in debug mode, this is the dmesg output: [ 69.747399] nuvoton_cir: w836x7hg: chip id: 0xa5 0x13 [ 69.747431] nuvoton_cir: CIR initialized, base io port address: 0x240, irq: 3 [ 69.747474] nuvoton_cir: CIR Wake initialized, base io port address: 0x250, irq: 3 [ 69.880088] Registered IR keymap rc-rc6-mce [ 69.880540] rc rc0: lirc_dev: driver ir-lirc-codec (nuvoton-cir) registered at minor = 0 [ 69.880669] input: Nuvoton w836x7hg Infrared Remote Transceiver as /devices/virtual/rc/rc0/input5 [ 69.880797] rc0: Nuvoton w836x7hg Infrared Remote Transceiver as /devices/virtual/rc/rc0 [ 69.880803] nuvoton_cir: driver has been successfully loaded [ 69.880814] nuvoton_cir: nuvoton-cir: Dump CIR logical device registers: [ 69.880821] nuvoton_cir: * CR CIR ACTIVE : 0x1 [ 69.880831] nuvoton_cir: * CR CIR BASE ADDR: 0x240 [ 69.880837] nuvoton_cir: * CR CIR IRQ NUM: 0x3 [ 69.880842] nuvoton_cir: nuvoton-cir: Dump CIR registers: [ 69.880848] nuvoton_cir: * IRCON: 0x36 [ 69.880853] nuvoton_cir: * IRSTS: 0x0 [ 69.880858] nuvoton_cir: * IREN: 0x60 [ 69.880862] nuvoton_cir: * RXFCONT: 0x0 [ 69.880867] nuvoton_cir: * CP: 0x0 [ 69.880872] nuvoton_cir: * CC: 0x0 [ 69.880877] nuvoton_cir: * SLCH: 0x7 [ 69.880882] nuvoton_cir: * SLCL: 0xd0 [ 69.880887] nuvoton_cir: * FIFOCON: 0x23 [ 69.880892] nuvoton_cir: * IRFIFOSTS: 0x96 [ 69.880897] nuvoton_cir: * SRXFIFO: 0x0 [ 69.880902] nuvoton_cir: * TXFCONT: 0x0 [ 69.880906] nuvoton_cir: * STXFIFO: 0x0 [ 69.880911] nuvoton_cir: * FCCH: 0x0 [ 69.880916] nuvoton_cir: * FCCL: 0x0 [ 69.880921] nuvoton_cir: * IRFSM: 0x14 [ 69.880931] nuvoton_cir: nuvoton-cir: Dump CIR WAKE logical device registers: [ 69.880938] nuvoton_cir: * CR CIR WAKE ACTIVE : 0x1 [ 69.880947] nuvoton_cir: * CR CIR WAKE BASE ADDR: 0x250 [ 69.880954] nuvoton_cir: * CR CIR WAKE IRQ NUM: 0x3 [ 69.880960] nuvoton_cir: nuvoton-cir: Dump CIR WAKE registers [ 69.880965] nuvoton_cir: * IRCON: 0x3e [ 69.880970] nuvoton_cir: * IRSTS: 0x1 [ 69.880975] nuvoton_cir: * IREN: 0x0 [ 69.880980] nuvoton_cir: * FIFO CMP DEEP: 0x43 [ 69.880985] nuvoton_cir: * FIFO CMP TOL: 0x5 [ 69.880990] nuvoton_cir: * FIFO COUNT: 0x0 [ 69.880995] nuvoton_cir: * SLCH: 0x7 [ 69.881001] nuvoton_cir: * SLCL: 0xd0 [ 69.881006] nuvoton_cir: * FIFOCON: 0x0 [ 69.881011] nuvoton_cir: * SRXFSTS: 0x20 [ 69.881016] nuvoton_cir: * SAMPLE RX FIFO: 0x0 [ 69.881021] nuvoton_cir: * WR FIFO DATA: 0xff [ 69.881026] nuvoton_cir: * RD FIFO ONLY: 0x8 [ 69.881031] nuvoton_cir: * RD FIFO ONLY IDX: 0x2 [ 69.881036] nuvoton_cir: * FIFO IGNORE: 0x25 [ 69.881041] nuvoton_cir: * IRFSM: 0x11 [ 69.881047] nuvoton_cir: nuvoton-cir: Dump CIR WAKE FIFO (len 0) [ 69.881051] nuvoton_cir: * Contents = Kind regards |
From: Jarod W. <ja...@wi...> - 2011-02-01 04:17:54
|
On Jan 31, 2011, at 4:24 PM, Larry Lobster wrote: >> It looks sane, from what I can tell, but lets have you try something >> else first. Stop lircd and run mode2. Press some buttons on the remote >> and see if mode2 spits anything out (it should). You should also be >> able to run the driver in debug mode to get some additional data out >> of it via dmesg. Results from this testing ought to give us a better >> idea whether or not we're at least getting some data from the hardware. >> > I stopped lirc and tried mode2 --device=/dev/lirc0 : > No reaction on button presses Okay, that plus the complete lack of evidence that nvt_cir_isr is ever firing says there are further code changes required to support this hardware. Not a clue where to begin with them though. I'll try to ping my Nuvoton contact and see if I can get some info. -- Jarod Wilson ja...@wi... |
From: Larry L. <lar...@gm...> - 2011-02-01 17:50:05
|
> Okay, that plus the complete lack of evidence that nvt_cir_isr is ever > firing says there are further code changes required to support this > hardware. Not a clue where to begin with them though. I'll try to ping > my Nuvoton contact and see if I can get some info. > Ok, thanks for the great support so far. If you don't have such a chip to test, just let me know. I will support you as good as I can do. |
From: Larry L. <lar...@gm...> - 2011-02-02 17:55:01
|
>> Okay, that plus the complete lack of evidence that nvt_cir_isr is ever >> firing says there are further code changes required to support this >> hardware. Not a clue where to begin with them though. I'll try to ping >> my Nuvoton contact and see if I can get some info. >> > Ok, thanks for the great support so far. If you don't have such a chip > to test, just let me know. I will support you as good as I can do. > On its website Asus offers Windows CIR drivers (XP, Vista, 7) for the Asus S1-AT5NM10E. Maybe it helps you to port it to Linux. You can get the drivers here: http://www.asus.com/product.aspx?P_ID=PBY1wFg4r0bOWE5O&templete=2 Choose the "Download" tab and select an Operating System. Under "Utilities" you can find "Winbond CIR Driver V2.1.2009.619". I recommend the China mirror for downloading the drivers. |
From: Jarod W. <ja...@wi...> - 2011-02-02 19:05:56
|
On Feb 2, 2011, at 12:54 PM, Larry Lobster wrote: > >>> Okay, that plus the complete lack of evidence that nvt_cir_isr is ever >>> firing says there are further code changes required to support this >>> hardware. Not a clue where to begin with them though. I'll try to ping >>> my Nuvoton contact and see if I can get some info. >>> >> Ok, thanks for the great support so far. If you don't have such a chip >> to test, just let me know. I will support you as good as I can do. >> > On its website Asus offers Windows CIR drivers (XP, Vista, 7) for the > Asus S1-AT5NM10E. Maybe it helps you to port it to Linux. Unless there's source code there too, it doesn't help me at all, its just a binary blob, and I don't have the Asus hardware to run it on. I'm still waiting to hear back from Nuvoton, spec sheets really are the best thing to have here. -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2011-02-09 16:55:50
|
On Feb 2, 2011, at 2:05 PM, Jarod Wilson wrote: > On Feb 2, 2011, at 12:54 PM, Larry Lobster wrote: > >> >>>> Okay, that plus the complete lack of evidence that nvt_cir_isr is ever >>>> firing says there are further code changes required to support this >>>> hardware. Not a clue where to begin with them though. I'll try to ping >>>> my Nuvoton contact and see if I can get some info. >>>> >>> Ok, thanks for the great support so far. If you don't have such a chip >>> to test, just let me know. I will support you as good as I can do. >>> >> On its website Asus offers Windows CIR drivers (XP, Vista, 7) for the >> Asus S1-AT5NM10E. Maybe it helps you to port it to Linux. > > Unless there's source code there too, it doesn't help me at all, its just > a binary blob, and I don't have the Asus hardware to run it on. I'm still > waiting to hear back from Nuvoton, spec sheets really are the best thing > to have here. I've got spec sheets and some additional info from Nuvoton. This is actually an *older* chip. The currently supported ones are W83677HG, this is a W83667HG. There are definitely some functional differences, but not a huge amount, so I'm hopeful I'll be able to add support for the 667, but I don't have a timeline for it yet. -- Jarod Wilson ja...@wi... |
From: Larry L. <lar...@gm...> - 2011-02-12 01:47:30
|
> I've got spec sheets and some additional info from Nuvoton. This is > actually an *older* chip. The currently supported ones are W83677HG, > this is a W83667HG. There are definitely some functional differences, > but not a huge amount, so I'm hopeful I'll be able to add support for > the 667, but I don't have a timeline for it yet. > Thanks for providing this information. I can provide some information,too. I talked to the guy in the xbmc forum who got the ir receiver working. Obviously his chipset has the same id as the one I use (0xa5 0x13). The old lirc_wb677 driver seems not be be that restrictive. It expects 0xb4, but it accepts 0xa4 as well. Link: http://forum.xbmc.org/showpost.php?p=717398&postcount=43 Good luck in adjusting the Nuvoton driver! If you need someone to test your implementation, just let me know. PS Sorry Jared, I accidently sent the mail to you directly. |
From: Larry L. <lar...@gm...> - 2011-03-30 15:33:41
|
Hi Jarod, is there any progress concerning this chipset? Kind regards > I've got spec sheets and some additional info from Nuvoton. This is > actually an *older* chip. The currently supported ones are W83677HG, > this is a W83667HG. There are definitely some functional differences, > but not a huge amount, so I'm hopeful I'll be able to add support for > the 667, but I don't have a timeline for it yet. > |
From: Jarod W. <ja...@wi...> - 2011-03-30 21:00:54
|
On Mar 30, 2011, at 11:33 AM, Larry Lobster wrote: > Hi Jarod, > > is there any progress concerning this chipset? Sadly, no. I printed out relevant chunks of the datasheets, for for reasons beyond my comprehension, the printer spit out unintelligible junk where there was supposed to be text, and I haven't got around to trying to figure that one out (well, I did figure out that one of the other printers here prints just fine, I just haven't reprinted the necessary bits for this task...). > Kind regards >> I've got spec sheets and some additional info from Nuvoton. This is >> actually an *older* chip. The currently supported ones are W83677HG, >> this is a W83667HG. There are definitely some functional differences, >> but not a huge amount, so I'm hopeful I'll be able to add support for >> the 667, but I don't have a timeline for it yet. >> -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2011-03-31 21:33:35
|
On Mar 30, 2011, at 5:00 PM, Jarod Wilson wrote: > On Mar 30, 2011, at 11:33 AM, Larry Lobster wrote: >>> >>> I've got spec sheets and some additional info from Nuvoton. This is >>> actually an *older* chip. The currently supported ones are W83677HG, >>> this is a W83667HG. There are definitely some functional differences, >>> but not a huge amount, so I'm hopeful I'll be able to add support for >>> the 667, but I don't have a timeline for it yet. >> Hi Jarod, >> >> is there any progress concerning this chipset? > > Sadly, no. I printed out relevant chunks of the datasheets, for for > reasons beyond my comprehension, the printer spit out unintelligible > junk where there was supposed to be text, and I haven't got around to > trying to figure that one out (well, I did figure out that one of the > other printers here prints just fine, I just haven't reprinted the > necessary bits for this task...). Finally got the relevant parts of the W83667HG datasheet printed out, but I've compared them directly with the 677 datasheet, and can't find any differences anywhere that should matter so far. The only thing I can think of is that perhaps the 667 requires the slightly more inefficient interrupt setup that was used in that old lirc driver. Given that we're never seeing the interrupt service routine fire on your hardware, it could be that additional interrupt bits need to be enabled and handled. If I'm thinking clearly, the old driver used CIR_IREN_RDR (Rx Data Ready) predominantly, which I found was a lot less efficient than using CIR_IREN_RTR (Rx Trigger Level Reached) and CIR_IREN_PE (Packet End). If you're up to it, try setting iren in nvt_set_cir_iren() to include CIR_IREN_RDR, load the resulting nuvoton-cir in debug mode, and see if the interrupt routine doesn't start firing... -- Jarod Wilson ja...@wi... |
From: Larry L. <lar...@gm...> - 2011-04-03 15:51:21
|
> Finally got the relevant parts of the W83667HG datasheet printed out, > but I've compared them directly with the 677 datasheet, and can't find > any differences anywhere that should matter so far. > > The only thing I can think of is that perhaps the 667 requires the > slightly more inefficient interrupt setup that was used in that old > lirc driver. Given that we're never seeing the interrupt service > routine fire on your hardware, it could be that additional interrupt > bits need to be enabled and handled. If I'm thinking clearly, the > old driver used CIR_IREN_RDR (Rx Data Ready) predominantly, which I > found was a lot less efficient than using CIR_IREN_RTR (Rx Trigger > Level Reached) and CIR_IREN_PE (Packet End). > > If you're up to it, try setting iren in nvt_set_cir_iren() to include > CIR_IREN_RDR, load the resulting nuvoton-cir in debug mode, and see > if the interrupt routine doesn't start firing... Ok, I've edited this line: iren = CIR_IREN_RTR | CIR_IREN_PE; to this line: iren = CIR_IREN_RDR | CIR_IREN_RTR | CIR_IREN_PE; This is the dmesg debug output: [ 157.827783] nuvoton_cir: w836x7hg: chip id: 0xa5 0x13 [ 157.827814] nuvoton_cir: CIR initialized, base io port address: 0x240, irq: 3 [ 157.827854] nuvoton_cir: CIR Wake initialized, base io port address: 0x250, irq: 3 [ 157.890062] Registered IR keymap rc-rc6-mce [ 157.890545] rc rc0: lirc_dev: driver ir-lirc-codec (nuvoton-cir) registered at minor = 0 [ 157.890693] input: Nuvoton w836x7hg Infrared Remote Transceiver as /devices/virtual/rc/rc0/input5 [ 157.890815] rc0: Nuvoton w836x7hg Infrared Remote Transceiver as /devices/virtual/rc/rc0 [ 157.890821] nuvoton_cir: driver has been successfully loaded [ 157.890831] nuvoton_cir: nuvoton-cir: Dump CIR logical device registers: [ 157.890838] nuvoton_cir: * CR CIR ACTIVE : 0x1 [ 157.890848] nuvoton_cir: * CR CIR BASE ADDR: 0x240 [ 157.890854] nuvoton_cir: * CR CIR IRQ NUM: 0x3 [ 157.890859] nuvoton_cir: nuvoton-cir: Dump CIR registers: [ 157.890865] nuvoton_cir: * IRCON: 0x36 [ 157.890870] nuvoton_cir: * IRSTS: 0x0 [ 157.890875] nuvoton_cir: * IREN: 0xe0 [ 157.890880] nuvoton_cir: * RXFCONT: 0x0 [ 157.890885] nuvoton_cir: * CP: 0x0 [ 157.890890] nuvoton_cir: * CC: 0x0 [ 157.890894] nuvoton_cir: * SLCH: 0x7 [ 157.890900] nuvoton_cir: * SLCL: 0xd0 [ 157.890905] nuvoton_cir: * FIFOCON: 0x23 [ 157.890909] nuvoton_cir: * IRFIFOSTS: 0x96 [ 157.890914] nuvoton_cir: * SRXFIFO: 0x0 [ 157.890919] nuvoton_cir: * TXFCONT: 0x0 [ 157.890924] nuvoton_cir: * STXFIFO: 0x0 [ 157.890930] nuvoton_cir: * FCCH: 0x0 [ 157.890936] nuvoton_cir: * FCCL: 0x0 [ 157.890942] nuvoton_cir: * IRFSM: 0x14 [ 157.890953] nuvoton_cir: nuvoton-cir: Dump CIR WAKE logical device registers: [ 157.890962] nuvoton_cir: * CR CIR WAKE ACTIVE : 0x1 [ 157.890972] nuvoton_cir: * CR CIR WAKE BASE ADDR: 0x250 [ 157.890980] nuvoton_cir: * CR CIR WAKE IRQ NUM: 0x3 [ 157.891016] nuvoton_cir: nuvoton-cir: Dump CIR WAKE registers [ 157.891023] nuvoton_cir: * IRCON: 0x3e [ 157.891030] nuvoton_cir: * IRSTS: 0x1 [ 157.891036] nuvoton_cir: * IREN: 0x0 [ 157.891042] nuvoton_cir: * FIFO CMP DEEP: 0x43 [ 157.891048] nuvoton_cir: * FIFO CMP TOL: 0x5 [ 157.891055] nuvoton_cir: * FIFO COUNT: 0x0 [ 157.891061] nuvoton_cir: * SLCH: 0x7 [ 157.891067] nuvoton_cir: * SLCL: 0xd0 [ 157.891074] nuvoton_cir: * FIFOCON: 0x0 [ 157.891080] nuvoton_cir: * SRXFSTS: 0x20 [ 157.891086] nuvoton_cir: * SAMPLE RX FIFO: 0x0 [ 157.891092] nuvoton_cir: * WR FIFO DATA: 0xff [ 157.891099] nuvoton_cir: * RD FIFO ONLY: 0x89 [ 157.891105] nuvoton_cir: * RD FIFO ONLY IDX: 0x1 [ 157.891111] nuvoton_cir: * FIFO IGNORE: 0x25 [ 157.891117] nuvoton_cir: * IRFSM: 0x10 [ 157.891124] nuvoton_cir: nuvoton-cir: Dump CIR WAKE FIFO (len 0) [ 157.891129] nuvoton_cir: * Contents = irw still doesn't react. Kind regards Larry Lobster |
From: Jarod W. <ja...@wi...> - 2011-04-04 15:15:41
|
On Apr 3, 2011, at 11:51 AM, Larry Lobster wrote: >> Finally got the relevant parts of the W83667HG datasheet printed out, >> but I've compared them directly with the 677 datasheet, and can't find >> any differences anywhere that should matter so far. >> >> The only thing I can think of is that perhaps the 667 requires the >> slightly more inefficient interrupt setup that was used in that old >> lirc driver. Given that we're never seeing the interrupt service >> routine fire on your hardware, it could be that additional interrupt >> bits need to be enabled and handled. If I'm thinking clearly, the >> old driver used CIR_IREN_RDR (Rx Data Ready) predominantly, which I >> found was a lot less efficient than using CIR_IREN_RTR (Rx Trigger >> Level Reached) and CIR_IREN_PE (Packet End). >> >> If you're up to it, try setting iren in nvt_set_cir_iren() to include >> CIR_IREN_RDR, load the resulting nuvoton-cir in debug mode, and see >> if the interrupt routine doesn't start firing... > > Ok, I've edited this line: > iren = CIR_IREN_RTR | CIR_IREN_PE; > > to this line: > iren = CIR_IREN_RDR | CIR_IREN_RTR | CIR_IREN_PE; > > This is the dmesg debug output: > [ 157.827783] nuvoton_cir: w836x7hg: chip id: 0xa5 0x13 > [ 157.827814] nuvoton_cir: CIR initialized, base io port address: > 0x240, irq: 3 > [ 157.827854] nuvoton_cir: CIR Wake initialized, base io port address: > 0x250, irq: 3 > [ 157.890062] Registered IR keymap rc-rc6-mce > [ 157.890545] rc rc0: lirc_dev: driver ir-lirc-codec (nuvoton-cir) > registered at minor = 0 > [ 157.890693] input: Nuvoton w836x7hg Infrared Remote Transceiver as > /devices/virtual/rc/rc0/input5 > [ 157.890815] rc0: Nuvoton w836x7hg Infrared Remote Transceiver as > /devices/virtual/rc/rc0 > [ 157.890821] nuvoton_cir: driver has been successfully loaded > [ 157.890831] nuvoton_cir: nuvoton-cir: Dump CIR logical device registers: > [ 157.890838] nuvoton_cir: * CR CIR ACTIVE : 0x1 > [ 157.890848] nuvoton_cir: * CR CIR BASE ADDR: 0x240 > [ 157.890854] nuvoton_cir: * CR CIR IRQ NUM: 0x3 > [ 157.890859] nuvoton_cir: nuvoton-cir: Dump CIR registers: > [ 157.890865] nuvoton_cir: * IRCON: 0x36 > [ 157.890870] nuvoton_cir: * IRSTS: 0x0 > [ 157.890875] nuvoton_cir: * IREN: 0xe0 > [ 157.890880] nuvoton_cir: * RXFCONT: 0x0 > [ 157.890885] nuvoton_cir: * CP: 0x0 > [ 157.890890] nuvoton_cir: * CC: 0x0 > [ 157.890894] nuvoton_cir: * SLCH: 0x7 > [ 157.890900] nuvoton_cir: * SLCL: 0xd0 > [ 157.890905] nuvoton_cir: * FIFOCON: 0x23 > [ 157.890909] nuvoton_cir: * IRFIFOSTS: 0x96 > [ 157.890914] nuvoton_cir: * SRXFIFO: 0x0 > [ 157.890919] nuvoton_cir: * TXFCONT: 0x0 > [ 157.890924] nuvoton_cir: * STXFIFO: 0x0 > [ 157.890930] nuvoton_cir: * FCCH: 0x0 > [ 157.890936] nuvoton_cir: * FCCL: 0x0 > [ 157.890942] nuvoton_cir: * IRFSM: 0x14 > [ 157.890953] nuvoton_cir: nuvoton-cir: Dump CIR WAKE logical device > registers: > [ 157.890962] nuvoton_cir: * CR CIR WAKE ACTIVE : 0x1 > [ 157.890972] nuvoton_cir: * CR CIR WAKE BASE ADDR: 0x250 > [ 157.890980] nuvoton_cir: * CR CIR WAKE IRQ NUM: 0x3 > [ 157.891016] nuvoton_cir: nuvoton-cir: Dump CIR WAKE registers > [ 157.891023] nuvoton_cir: * IRCON: 0x3e > [ 157.891030] nuvoton_cir: * IRSTS: 0x1 > [ 157.891036] nuvoton_cir: * IREN: 0x0 > [ 157.891042] nuvoton_cir: * FIFO CMP DEEP: 0x43 > [ 157.891048] nuvoton_cir: * FIFO CMP TOL: 0x5 > [ 157.891055] nuvoton_cir: * FIFO COUNT: 0x0 > [ 157.891061] nuvoton_cir: * SLCH: 0x7 > [ 157.891067] nuvoton_cir: * SLCL: 0xd0 > [ 157.891074] nuvoton_cir: * FIFOCON: 0x0 > [ 157.891080] nuvoton_cir: * SRXFSTS: 0x20 > [ 157.891086] nuvoton_cir: * SAMPLE RX FIFO: 0x0 > [ 157.891092] nuvoton_cir: * WR FIFO DATA: 0xff > [ 157.891099] nuvoton_cir: * RD FIFO ONLY: 0x89 > [ 157.891105] nuvoton_cir: * RD FIFO ONLY IDX: 0x1 > [ 157.891111] nuvoton_cir: * FIFO IGNORE: 0x25 > [ 157.891117] nuvoton_cir: * IRFSM: 0x10 > [ 157.891124] nuvoton_cir: nuvoton-cir: Dump CIR WAKE FIFO (len 0) > [ 157.891129] nuvoton_cir: * Contents = > > > irw still doesn't react. I wouldn't expect it to yet, as the interrupt handler isn't wired up to actually do anything specific with the RDR interrupts. What I'm looking for is whether or not the interrupt handler is at least firing with that change. So when you press buttons on the remote, do you get any "nvt_cir_isr firing" spew in dmesg? -- Jarod Wilson ja...@wi... |
From: Douglas C. <dcl...@op...> - 2011-04-05 22:27:35
|
Hi Jarod, I too have the ASUS barebones with this hardware, so I am also interested in this solution. I am running a MythTV frontend on Fedora 14. I have tried (and so far failed) to build the drivers, with a view to participating in this effort. I have also downloaded the kernel source and built it. While there are no errors, there are over 200 warnings which I have yet to review. I expect that I will patch that kernel and try to boot it. If there's something else you would like, let me know. If you want access to the box, it can be arranged although I am in UTC+10 so keypresses might be difficult. Cheers, Douglas |
From: Jarod W. <ja...@wi...> - 2011-04-06 14:35:41
|
On Apr 5, 2011, at 6:26 PM, Douglas Clowes wrote: > Hi Jarod, > > I too have the ASUS barebones with this hardware, so I am also > interested in this solution. > > I am running a MythTV frontend on Fedora 14. I have tried (and so far > failed) to build the drivers, with a view to participating in this effort. > > I have also downloaded the kernel source and built it. While there are > no errors, there are over 200 warnings which I have yet to review. > > I expect that I will patch that kernel and try to boot it. > > If there's something else you would like, let me know. If you want > access to the box, it can be arranged although I am in UTC+10 so > keypresses might be difficult. I don't know that access without a way to deliver keypresses will be of any use just yet, but its something I'll keep in mind. If you did happen to have a transmitter laying about though, something could be rigged up that could be used entirely remotely (pun not intended) without an actual ... remote. :) (The fact its a system running Fedora helps too, much more comfortable there than anywhere else, for obvious reasons). -- Jarod Wilson ja...@wi... |
From: Douglas C. <dcl...@op...> - 2011-04-07 00:06:11
|
On 2011-04-07 00:35, Jarod Wilson wrote: > On Apr 5, 2011, at 6:26 PM, Douglas Clowes wrote: > >> Hi Jarod, >> >> I too have the ASUS barebones with this hardware, so I am also >> interested in this solution. >> >> I am running a MythTV frontend on Fedora 14. I have tried (and so far >> failed) to build the drivers, with a view to participating in this effort. >> >> I have also downloaded the kernel source and built it. While there are >> no errors, there are over 200 warnings which I have yet to review. >> >> I expect that I will patch that kernel and try to boot it. >> >> If there's something else you would like, let me know. If you want >> access to the box, it can be arranged although I am in UTC+10 so >> keypresses might be difficult. > I don't know that access without a way to deliver keypresses will be > of any use just yet, but its something I'll keep in mind. If you did > happen to have a transmitter laying about though, something could be > rigged up that could be used entirely remotely (pun not intended) > without an actual ... remote. :) (The fact its a system running Fedora > helps too, much more comfortable there than anywhere else, for obvious > reasons). > I have managed to build the drivers (after removing the text from ite-cir something) and have now generated the relevant patches. It's just an Atom so building is nostalgic (Yawn). As for transmitters, I have an MCE USB thingy that advertises itself as a Phillips eHome and has two 3.5mm sockets on the back. I also have an Intel DG45-ID with a CIR (Consumer InfraRed) input and output on the mobo. I have a USB serial port. I also have a bunch of antique IR remotes in the garage which, I suspect, contain componentry that could be used to cobble up something transmittery if I had the pinouts and/or a circuit diagram. If you like any of those, let me know (or if anyone else would like to tell me how to make them up:)). My remote is the Leadtek Y04G0051 which has an MCE mode that I assume should work with the Nuvoton in the ASUS. I can press keys during your earlier morning or alternatively late afternoon or early evening (and Saturday is comming up, yay). It looks like the patches are installed but there is no apparent interrupt activity. [ 5205.894482] nuvoton_cir: nvt_cir_isr firing [ 5205.894503] nuvoton_cir: IRQ 0xff (IREN 0xff) : RDR RTR PE RFO TE TTR TFU GH [ 5205.894520] nuvoton_cir: nvt_cir_isr done [ 5205.894531] nuvoton_cir: nvt_cir_wake_isr firing [ 5205.894543] nuvoton_cir: nvt_cir_wake_isr exiting, wake not enabled [ 5205.894594] rc rc4: lirc_dev: driver ir-lirc-codec (nuvoton-cir) unregistered from minor = 0 [ 5205.894602] rc rc4: lirc_dev (ir-lirc-codec (nuvoton-cir)[0]): cleaning up [ 5212.785973] nuvoton_cir: nvt_cir_isr firing [ 5212.785997] nuvoton_cir: IRQ 0xff (IREN 0xff) : RDR RTR PE RFO TE TTR TFU GH [ 5212.786017] nuvoton_cir: nvt_cir_isr done [ 5212.786034] nuvoton_cir: nvt_cir_wake_isr firing [ 5212.786049] nuvoton_cir: nvt_cir_wake_isr exiting, wake not enabled [ 5212.786068] nuvoton_cir: w836x7hg: chip id: 0xa5 0x13 [ 5212.786100] nuvoton_cir: CIR initialized, base io port address: 0x240, irq: 3 [ 5212.786144] nuvoton_cir: CIR Wake initialized, base io port address: 0x250, irq: 3 [ 5212.786182] Registered IR keymap rc-rc6-mce [ 5212.788098] input: Nuvoton w836x7hg Infrared Remote Transceiver as /devices/virtual/rc/rc5/input10 [ 5212.799128] rc5: Nuvoton w836x7hg Infrared Remote Transceiver as /devices/virtual/rc/rc5 [ 5212.799339] rc rc5: lirc_dev: lirc_register_driver: sample_rate: 0 [ 5212.799721] rc rc5: lirc_dev: driver ir-lirc-codec (nuvoton-cir) registered at minor = 0 [ 5212.799735] nuvoton_cir: driver has been successfully loaded [ 5212.799748] nuvoton_cir: nuvoton-cir: Dump CIR logical device registers: [ 5212.799757] nuvoton_cir: * CR CIR ACTIVE : 0x1 [ 5212.799768] nuvoton_cir: * CR CIR BASE ADDR: 0x240 [ 5212.799777] nuvoton_cir: * CR CIR IRQ NUM: 0x3 [ 5212.799785] nuvoton_cir: nuvoton-cir: Dump CIR registers: [ 5212.799792] nuvoton_cir: * IRCON: 0x36 [ 5212.799799] nuvoton_cir: * IRSTS: 0x0 [ 5212.799806] nuvoton_cir: * IREN: 0xe0 [ 5212.799813] nuvoton_cir: * RXFCONT: 0x0 [ 5212.799819] nuvoton_cir: * CP: 0x0 [ 5212.799826] nuvoton_cir: * CC: 0x0 [ 5212.799833] nuvoton_cir: * SLCH: 0x7 [ 5212.799839] nuvoton_cir: * SLCL: 0xd0 [ 5212.799846] nuvoton_cir: * FIFOCON: 0x23 [ 5212.799853] nuvoton_cir: * IRFIFOSTS: 0x96 [ 5212.799860] nuvoton_cir: * SRXFIFO: 0x0 [ 5212.799867] nuvoton_cir: * TXFCONT: 0x0 [ 5212.799874] nuvoton_cir: * STXFIFO: 0x0 [ 5212.799880] nuvoton_cir: * FCCH: 0x0 [ 5212.799886] nuvoton_cir: * FCCL: 0x0 [ 5212.799892] nuvoton_cir: * IRFSM: 0x14 [ 5212.799902] nuvoton_cir: nuvoton-cir: Dump CIR WAKE logical device registers: [ 5212.799910] nuvoton_cir: * CR CIR WAKE ACTIVE : 0x1 [ 5212.799920] nuvoton_cir: * CR CIR WAKE BASE ADDR: 0x250 [ 5212.799927] nuvoton_cir: * CR CIR WAKE IRQ NUM: 0x3 [ 5212.799933] nuvoton_cir: nuvoton-cir: Dump CIR WAKE registers [ 5212.799939] nuvoton_cir: * IRCON: 0x3e [ 5212.799945] nuvoton_cir: * IRSTS: 0x1 [ 5212.799950] nuvoton_cir: * IREN: 0x0 [ 5212.799956] nuvoton_cir: * FIFO CMP DEEP: 0x41 [ 5212.799961] nuvoton_cir: * FIFO CMP TOL: 0x5 [ 5212.799967] nuvoton_cir: * FIFO COUNT: 0x0 [ 5212.799972] nuvoton_cir: * SLCH: 0x7 [ 5212.799978] nuvoton_cir: * SLCL: 0xd0 [ 5212.799983] nuvoton_cir: * FIFOCON: 0x0 [ 5212.799989] nuvoton_cir: * SRXFSTS: 0x20 [ 5212.799994] nuvoton_cir: * SAMPLE RX FIFO: 0x0 [ 5212.800001] nuvoton_cir: * WR FIFO DATA: 0xff [ 5212.800007] nuvoton_cir: * RD FIFO ONLY: 0x11 [ 5212.800013] nuvoton_cir: * RD FIFO ONLY IDX: 0x6 [ 5212.800018] nuvoton_cir: * FIFO IGNORE: 0x25 [ 5212.800024] nuvoton_cir: * IRFSM: 0x10 [ 5212.800030] nuvoton_cir: nuvoton-cir: Dump CIR WAKE FIFO (len 0) [ 5212.800036] nuvoton_cir: * Contents = [dcl@family media_build]$ Douglas |
From: Jarod W. <ja...@wi...> - 2011-04-07 22:02:35
|
On Apr 6, 2011, at 8:05 PM, Douglas Clowes wrote: > On 2011-04-07 00:35, Jarod Wilson wrote: >> On Apr 5, 2011, at 6:26 PM, Douglas Clowes wrote: >> >>> Hi Jarod, >>> >>> I too have the ASUS barebones with this hardware, so I am also >>> interested in this solution. >>> >>> I am running a MythTV frontend on Fedora 14. I have tried (and so far >>> failed) to build the drivers, with a view to participating in this effort. >>> >>> I have also downloaded the kernel source and built it. While there are >>> no errors, there are over 200 warnings which I have yet to review. >>> >>> I expect that I will patch that kernel and try to boot it. >>> >>> If there's something else you would like, let me know. If you want >>> access to the box, it can be arranged although I am in UTC+10 so >>> keypresses might be difficult. >> I don't know that access without a way to deliver keypresses will be >> of any use just yet, but its something I'll keep in mind. If you did >> happen to have a transmitter laying about though, something could be >> rigged up that could be used entirely remotely (pun not intended) >> without an actual ... remote. :) (The fact its a system running Fedora >> helps too, much more comfortable there than anywhere else, for obvious >> reasons). >> > I have managed to build the drivers (after removing the text from ite-cir something) and have now generated the relevant patches. It's just an Atom so building is nostalgic (Yawn). > > As for transmitters, I have an MCE USB thingy that advertises itself as a Phillips eHome and has two 3.5mm sockets on the back. That would do the job, if you have a tx cable for it. > My remote is the Leadtek Y04G0051 which has an MCE mode that I assume should work with the Nuvoton in the ASUS. At least in the 677 case, its a raw IR receiver, so any IR signal should work just fine, so long as it can be decoded. I've used both rc6 and nec signal remotes with my hardware, no problem. > I can press keys during your earlier morning or alternatively late afternoon or early evening (and Saturday is comming up, yay). Coordination might be interesting... The mceusb route would probably be the way to go. My free time to work on this comes and goes, and isn't all that predictable either. > It looks like the patches are installed but there is no apparent interrupt activity. > [ 5205.894482] nuvoton_cir: nvt_cir_isr firing This much is good... > [ 5205.894503] nuvoton_cir: IRQ 0xff (IREN 0xff) : RDR RTR PE RFO TE TTR TFU GH But this is odd. We shouldn't be showing all interrupt bits set. Your CIR register dump from init time looks correct, with IREN showing 0xe0, so that 0xff is troubling... Unless that's from really early on during init?... Was not expecting to see it fire until *after* CIR was actually initialized, but maybe that's not actually a problem here. > [ 5212.785973] nuvoton_cir: nvt_cir_isr firing > [ 5212.785997] nuvoton_cir: IRQ 0xff (IREN 0xff) : RDR RTR PE RFO TE TTR TFU GH > [ 5212.786017] nuvoton_cir: nvt_cir_isr done > [ 5212.786034] nuvoton_cir: nvt_cir_wake_isr firing > [ 5212.786049] nuvoton_cir: nvt_cir_wake_isr exiting, wake not enabled > [ 5212.786068] nuvoton_cir: w836x7hg: chip id: 0xa5 0x13 > [ 5212.786100] nuvoton_cir: CIR initialized, base io port address: 0x240, irq: 3 > [ 5212.786144] nuvoton_cir: CIR Wake initialized, base io port address: 0x250, irq: 3 > [ 5212.786182] Registered IR keymap rc-rc6-mce > [ 5212.788098] input: Nuvoton w836x7hg Infrared Remote Transceiver as /devices/virtual/rc/rc5/input10 > [ 5212.799128] rc5: Nuvoton w836x7hg Infrared Remote Transceiver as /devices/virtual/rc/rc5 > [ 5212.799339] rc rc5: lirc_dev: lirc_register_driver: sample_rate: 0 > [ 5212.799721] rc rc5: lirc_dev: driver ir-lirc-codec (nuvoton-cir) registered at minor = 0 > [ 5212.799735] nuvoton_cir: driver has been successfully loaded > [ 5212.799748] nuvoton_cir: nuvoton-cir: Dump CIR logical device registers: > [ 5212.799757] nuvoton_cir: * CR CIR ACTIVE : 0x1 > [ 5212.799768] nuvoton_cir: * CR CIR BASE ADDR: 0x240 > [ 5212.799777] nuvoton_cir: * CR CIR IRQ NUM: 0x3 > [ 5212.799785] nuvoton_cir: nuvoton-cir: Dump CIR registers: > [ 5212.799792] nuvoton_cir: * IRCON: 0x36 > [ 5212.799799] nuvoton_cir: * IRSTS: 0x0 > [ 5212.799806] nuvoton_cir: * IREN: 0xe0 -- Jarod Wilson ja...@wi... |
From: Douglas C. <dcl...@op...> - 2011-04-11 13:54:47
|
On 2011-04-08 08:02, Jarod Wilson wrote: > On Apr 6, 2011, at 8:05 PM, Douglas Clowes wrote: > >> On 2011-04-07 00:35, Jarod Wilson wrote: >>> On Apr 5, 2011, at 6:26 PM, Douglas Clowes wrote: >>> >>>> Hi Jarod, >>>> >>>> I too have the ASUS barebones with this hardware, so I am also >>>> interested in this solution. >>>> >>>> I am running a MythTV frontend on Fedora 14. I have tried (and so far >>>> failed) to build the drivers, with a view to participating in this effort. >>>> >>>> I have also downloaded the kernel source and built it. While there are >>>> no errors, there are over 200 warnings which I have yet to review. >>>> >>>> I expect that I will patch that kernel and try to boot it. >>>> >>>> If there's something else you would like, let me know. If you want >>>> access to the box, it can be arranged although I am in UTC+10 so >>>> keypresses might be difficult. >>> I don't know that access without a way to deliver keypresses will be >>> of any use just yet, but its something I'll keep in mind. If you did >>> happen to have a transmitter laying about though, something could be >>> rigged up that could be used entirely remotely (pun not intended) >>> without an actual ... remote. :) (The fact its a system running Fedora >>> helps too, much more comfortable there than anywhere else, for obvious >>> reasons). >>> >> I have managed to build the drivers (after removing the text from ite-cir something) and have now generated the relevant patches. It's just an Atom so building is nostalgic (Yawn). >> >> As for transmitters, I have an MCE USB thingy that advertises itself as a Phillips eHome and has two 3.5mm sockets on the back. > That would do the job, if you have a tx cable for it. > Well, I now have a Tx cable for it. >> My remote is the Leadtek Y04G0051 which has an MCE mode that I assume should work with the Nuvoton in the ASUS. > At least in the 677 case, its a raw IR receiver, so any IR signal should > work just fine, so long as it can be decoded. I've used both rc6 and nec > signal remotes with my hardware, no problem. > > >> I can press keys during your earlier morning or alternatively late afternoon or early evening (and Saturday is comming up, yay). > Coordination might be interesting... The mceusb route would probably be > the way to go. My free time to work on this comes and goes, and isn't > all that predictable either. > > >> It looks like the patches are installed but there is no apparent interrupt activity. >> [ 5205.894482] nuvoton_cir: nvt_cir_isr firing > This much is good... > >> [ 5205.894503] nuvoton_cir: IRQ 0xff (IREN 0xff) : RDR RTR PE RFO TE TTR TFU GH > But this is odd. We shouldn't be showing all interrupt bits set. > Your CIR register dump from init time looks correct, with IREN > showing 0xe0, so that 0xff is troubling... Unless that's from > really early on during init?... Was not expecting to see it fire > until *after* CIR was actually initialized, but maybe that's > not actually a problem here. > > Wrote a little program to set the top two bits of CR 0x2C to "10" and interrupts all over the place. Seems the CIR pins (75 and 76) have to be enabled on this chip. Looks like that could belong in nvt_cir_ldev_init where you do the output pin selection. I can cat event2 and I get garbage when I press a key so something is happening. Sometimes event2 disappears and I have to reload the module for it to reappear. Interrupts keep happening and the rc is still in /sys/class/rc showing event2. Not sure what makes that happen. Not sure of the plumbing and how to get messages to ircat and irw, but I'll keep plugging. Cheers, Douglas |
From: Douglas C. <dcl...@op...> - 2011-04-12 13:19:35
|
On 2011-04-11 23:53, Douglas Clowes wrote: > > Wrote a little program to set the top two bits of CR 0x2C to "10" and > interrupts all over the place. Seems the CIR pins (75 and 76) have to be > enabled on this chip. Looks like that could belong in nvt_cir_ldev_init > where you do the output pin selection. I have added that code to the driver and it's looking good. > I can cat event2 and I get garbage when I press a key so something is > happening. > The IR signal seems a little noisy, with numerous 50uS spikes and decreasing frequency of 100uS, 150uS, 200uS and even a few 250uS in the log. They appear as: Apr 12 21:42:33 family kernel: [26576.095591] nvt_dump_rx_buf (len 17): 0x85 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x80 where there is a spike followed by a long space, sometimes containing another spike like: Apr 12 18:40:59 family kernel: [15681.980100] nvt_dump_rx_buf (len 24): 0x84 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x43 0x82 0x7f 0x7f 0x4d 0x82 0x7f 0x7f where the 0x84 is the primary spike and the 0x82 ones are secondary. I have covered the sensor and it doesn't seem to make a difference, so probably not ambient noise. While probably not a major issue in a running system, irrecord takes them as keypresses and gets confused. Speaking of irrecord, it doesn't seem to like the stream, even after filtering sub-200uS pulses. Can't learn, can't handle repeats. Works much more better on the Philips eHome although the pulse train is remarkably similar. Major difference, from what I can see, is that the eHome has a leading 100000 space and trailing 600 pulse: space 100000 pulse 9000 space 4350 pulse 650 space 1600 pulse 600 space 1600 ... pulse 650 space 1600 pulse 600 space 39550 pulse 8950 space 2200 pulse 600 whilst the nuvoton has a leading 9000 pulse and a trailing long space: pulse 9000 space 4450 pulse 600 space 1600 pulse 600 space 1650 ... pulse 600 space 1600 pulse 600 space 39700 pulse 9000 space 2200 pulse 600 space 95650 pulse 9000 space 2200 pulse 600 space 95250 with the 9000/2200 pair being the repeat codes in both cases. Curious! The eHome is on a standard Fedora 14 while the nuvoton is on the built drivers. The eHome appears in /dev/input/by-id but the nuvoton does not. > Sometimes event2 disappears and I have to reload the module for it to > reappear. Interrupts keep happening and the rc is still in /sys/class/rc > showing event2. Not sure what makes that happen. > That seems to be related to trying to dump the event in various ways. Maybe something deletes it when it closes it. Seems stable now that I've stopped doing that. > Not sure of the plumbing and how to get messages to ircat and irw, but > I'll keep plugging. > Seems that events are popping up on /dev/input/eventN and /dev/lirc0 and in mode2 and *something* is happening in irrecord, but nothing on irw yet. This same remote looks remarkably different through the AF9015 and the nuvoton and eHome but remarkably similar through the eHome and nuvoton. Just an observation. > Cheers, > > Douglas > |