e3-hacking

e3-hacking@earth.li

395 discussions

Re: [E3-hacking] [RFC][PATCH 4/5] input: serio: add supportforAmstrad Delta serial keyboard port
by witek mark 17 Dec '09

17 Dec '09

I'm sorry for my latest mail written in Polish. I wanted to consult some amstrad keyboard thing with Janusz Krzysztofik. I accidently put to many recipients. regards Witold Markowski Dnia 17-12-2009 o godz. 16:36 witek mark napisał(a): > Witam, > > > Od jakiegoś czasu obserwuję grupę dyskusyjną Amstrada. Sam posiadam > jeden egzemplarz i coś tam sobie na nim próbuję uruchomić. > Chciałem się podzielić kilkoma spostrzeżeniami dotyczącymi klawiatury. > Na razie nie odpisuję na grupę tylko do Pana. > > Zaintrygowany mailem dotyczącym klawiatury postanowiłem ją rozkręcić aby > zobaczyć co w środku jest. Okazuje się, że płytka klawiatury jest > "przyspawana" do jednej ze stron obudowy. Trzeba by wyłamać parę > zatrzasków, żeby obejrzeć te stronę płytki drukowanej, gdzie są > rozmieszczone elementy - dlatego na razie dałem sobie z tym spokój. Idąc > dalej rozkręciłem tego gamepada. Jak się ponadto okazuje ten gamepad > wpina się między amstrada a klawiaturę. Klawiatura i gamepad mają > interfejs złożony z czterech pinów i po sprawdzeniu miernikiem okazuję > się, że klawiatura i gamepad jeśli się je połączy razem do amstrada to > są one podłączone równolegle do tych pinów (jestem tego pewien na 90%). > Ponadto po rozkręceniu gamepada ukazała mi się płytka drukowana ale > niestety nie wiem co to jest za chip elektroniczny w środku, gdyż ma on > postać "czarnego okrągłego kleksa plastikowego" (szkoda, że nie zrobiłem > zdjęcia). Jedno jest pewne: na tej płytce te cztery piny interfejsu były > opisane jako GND, VCC, CLK i DATA. Czyli wnioskując musi to być jakiś > interfejs szeregowy. Ponadto wiemy już, że klawiatura i gamepad są > podłączane równolegle do amstrada, czyli musi to być interfejs > szeregowy, który niejako "wspiera" połączenie kilku urządzeń do jednej > magistrali. > Może to jest zwykły interfejs szeregowy typu rs232? > Załóżmy na chwilkę, że jest to interfejs rs232. Możemy wtedy stwierdzić, > że: > a) klawiatura generuje jakiś zestaw kodów klawiszy, > b) gamepad generuje ten sam zestaw kodów klawiszy - może i tak być, > wtedy gamepad zachowuje się jako "specjalna klawiatura na potrzeby gier" > i tak naprawdę można powiedzieć że na amstradzie gra się na klawiaturze > a gamepad tylko ułatwia "wciskanie guzików", > c) pisze Pan, że jeśli gamepad i klawiatura są podłączone jednocześnie i > jednocześnie cos na nich naciskamy to obserwuje Pan w sterowniku błędy > typu: parity check failed, invalid stop bit. O ile moja znajomość > protokołów transmisji jest dobra, to wychodzi na to, że te błędy > występują właśnie w transmisji szeregowej rs232 (chyba, że jest jakiś > inny podobny protokół transmisji). O ile naciska Pan przycisk tylko na > jednym urządzeniu to wszystko jest w porządku; urządzenie wysyła np kod > klawisza, a interfejs szeregowy dodaje jeszcze bity parzystości > (kontrola błędów) i stopu. Jeśli teraz zaczniemy coś naciskać na drugim > urządzeniu to ono również wysyła swój kod błędu, bity parzystości i bity > stopu. Wtedy może dochodzić np do kolizji (klawiatura wysyła w danym > momencie bit stopu a gamepad wysyła swój kod klawisza) i port szeregowy > w amstradzie "głupieje" i zgłasza błędy typu parity check failed, > invalid stop bit). Generalnie w porcie szeregowym typu rs232 można > podłączyć kilka urządzeń równolegle, tylko jak przynajmniej dwa zaczną > nadawać w tej samej chwili to zaczynają się kolizje. > > W sterownikach linuxa nie jestem za mocny dlatego nie mam pojęcia jak > jest napisany dotychczasowy driver. Gdybym miał oscyloskop to bym > sprawdził komunikację na tych pinach i by się okazało czy to jest > rzeczywiście transmisja typu rs232. > > > Co Pan myśli o moich tezach? A mogę dostać Pańskie logi ze sterownika? > Może coś uda się wymyślić. > > > pozdrawiam > > > Witold Markowski > > > > > > > > > > Dnia 14-12-2009 o godz. 1:11 Janusz Krzysztofik napisał(a): > > Hi Dmitry, > > > > Sunday 13 December 2009 00:20:03 Dmitry Torokhov napisał(a): > > > > > > atkbd is supposed to support PS/2 devices speaking AT keyboard protocol. > > > We also do support such devices behind dumb controllers that do not > > > allow querying the device but we expect those to at least produce the > > > standard scancodes. > > > > As far as I can understand, using the atkbd driver is not a good idea in > > this > > case because of the keyboard not producing standard scancodes, correct? > > > > Isn't the hpps2atkbd.h provided keycode table an already supported way of > > introducing exceptions to this standard scancodes requirement? Why > > couldn't > > this method be reused here? > > > > What I am afraid of is if the driver supposed to be created instead > > wouldn't > > require reiplementing most of the atkbd code. > > > > > I would need to know a bit more about the gamepad, but so far I still > > > think that current attempot of creating intermediate serio module which > > > allows to use atkbd driver is not the proper solution. > > > > I modified the serio driver to send exactly what it gets from the buffer > > and > > examined its output with serio_raw. The gamepad (can be connected > > simultaneously) appeared to send exactly the same scancodes as the > > keyboard > > did. I couldn't see how those might be destinguished whether coming from > > the > > keybord or from the gamepad. Thus, handling them both together as a single > > device would probably be the only option here. > > > > With both devices connected and keys pressed simultaneously, errors > > occure at > > the lowest level: parity check failed, invalid stop bit, etc. I don't > > think > > it would be possible to do anything about this. But this also means that > > trying to query them in order to get a sensible response would probably be > > not reliable. > > > > Any thoughts? > > > > Thanks, > > Janusz > > > > _______________________________________________ > > e3-hacking mailing list > > e3-hacking(a)earth.li > > http://www.earth.li/cgi-bin/mailman/listinfo/e3-hacking > > ---------------------------------------------------- > Kołodziej będzie miażdżył na ringu > 18 grudnia, Gala Boksu w Łodzi > Zobacz: > http://klik.wp.pl/?adr=http%3A%2F%2Fcorto.www.wp.pl%2Fas%2Fwojak18grudnia.h… > > > > _______________________________________________ > e3-hacking mailing list > e3-hacking(a)earth.li > http://www.earth.li/cgi-bin/mailman/listinfo/e3-hacking ---------------------------------------------------- Podniebny prezent świąteczny Niepowtarzalny, dla każdego Ekspresowa dostawa Sprawdź: http://klik.wp.pl/?adr=www.skacz.pl&sid=933

1 0

Re: [E3-hacking] [RFC][PATCH 4/5] input: serio: add support forAmstrad Delta serial keyboard port
by witek mark 17 Dec '09

17 Dec '09

Witam, Od jakiegoś czasu obserwuję grupę dyskusyjną Amstrada. Sam posiadam jeden egzemplarz i coś tam sobie na nim próbuję uruchomić. Chciałem się podzielić kilkoma spostrzeżeniami dotyczącymi klawiatury. Na razie nie odpisuję na grupę tylko do Pana. Zaintrygowany mailem dotyczącym klawiatury postanowiłem ją rozkręcić aby zobaczyć co w środku jest. Okazuje się, że płytka klawiatury jest "przyspawana" do jednej ze stron obudowy. Trzeba by wyłamać parę zatrzasków, żeby obejrzeć te stronę płytki drukowanej, gdzie są rozmieszczone elementy - dlatego na razie dałem sobie z tym spokój. Idąc dalej rozkręciłem tego gamepada. Jak się ponadto okazuje ten gamepad wpina się między amstrada a klawiaturę. Klawiatura i gamepad mają interfejs złożony z czterech pinów i po sprawdzeniu miernikiem okazuję się, że klawiatura i gamepad jeśli się je połączy razem do amstrada to są one podłączone równolegle do tych pinów (jestem tego pewien na 90%). Ponadto po rozkręceniu gamepada ukazała mi się płytka drukowana ale niestety nie wiem co to jest za chip elektroniczny w środku, gdyż ma on postać "czarnego okrągłego kleksa plastikowego" (szkoda, że nie zrobiłem zdjęcia). Jedno jest pewne: na tej płytce te cztery piny interfejsu były opisane jako GND, VCC, CLK i DATA. Czyli wnioskując musi to być jakiś interfejs szeregowy. Ponadto wiemy już, że klawiatura i gamepad są podłączane równolegle do amstrada, czyli musi to być interfejs szeregowy, który niejako "wspiera" połączenie kilku urządzeń do jednej magistrali. Może to jest zwykły interfejs szeregowy typu rs232? Załóżmy na chwilkę, że jest to interfejs rs232. Możemy wtedy stwierdzić, że: a) klawiatura generuje jakiś zestaw kodów klawiszy, b) gamepad generuje ten sam zestaw kodów klawiszy - może i tak być, wtedy gamepad zachowuje się jako "specjalna klawiatura na potrzeby gier" i tak naprawdę można powiedzieć że na amstradzie gra się na klawiaturze a gamepad tylko ułatwia "wciskanie guzików", c) pisze Pan, że jeśli gamepad i klawiatura są podłączone jednocześnie i jednocześnie cos na nich naciskamy to obserwuje Pan w sterowniku błędy typu: parity check failed, invalid stop bit. O ile moja znajomość protokołów transmisji jest dobra, to wychodzi na to, że te błędy występują właśnie w transmisji szeregowej rs232 (chyba, że jest jakiś inny podobny protokół transmisji). O ile naciska Pan przycisk tylko na jednym urządzeniu to wszystko jest w porządku; urządzenie wysyła np kod klawisza, a interfejs szeregowy dodaje jeszcze bity parzystości (kontrola błędów) i stopu. Jeśli teraz zaczniemy coś naciskać na drugim urządzeniu to ono również wysyła swój kod błędu, bity parzystości i bity stopu. Wtedy może dochodzić np do kolizji (klawiatura wysyła w danym momencie bit stopu a gamepad wysyła swój kod klawisza) i port szeregowy w amstradzie "głupieje" i zgłasza błędy typu parity check failed, invalid stop bit). Generalnie w porcie szeregowym typu rs232 można podłączyć kilka urządzeń równolegle, tylko jak przynajmniej dwa zaczną nadawać w tej samej chwili to zaczynają się kolizje. W sterownikach linuxa nie jestem za mocny dlatego nie mam pojęcia jak jest napisany dotychczasowy driver. Gdybym miał oscyloskop to bym sprawdził komunikację na tych pinach i by się okazało czy to jest rzeczywiście transmisja typu rs232. Co Pan myśli o moich tezach? A mogę dostać Pańskie logi ze sterownika? Może coś uda się wymyślić. pozdrawiam Witold Markowski Dnia 14-12-2009 o godz. 1:11 Janusz Krzysztofik napisał(a): > Hi Dmitry, > > Sunday 13 December 2009 00:20:03 Dmitry Torokhov napisał(a): > > > > atkbd is supposed to support PS/2 devices speaking AT keyboard protocol. > > We also do support such devices behind dumb controllers that do not > > allow querying the device but we expect those to at least produce the > > standard scancodes. > > As far as I can understand, using the atkbd driver is not a good idea in > this > case because of the keyboard not producing standard scancodes, correct? > > Isn't the hpps2atkbd.h provided keycode table an already supported way of > introducing exceptions to this standard scancodes requirement? Why > couldn't > this method be reused here? > > What I am afraid of is if the driver supposed to be created instead > wouldn't > require reiplementing most of the atkbd code. > > > I would need to know a bit more about the gamepad, but so far I still > > think that current attempot of creating intermediate serio module which > > allows to use atkbd driver is not the proper solution. > > I modified the serio driver to send exactly what it gets from the buffer > and > examined its output with serio_raw. The gamepad (can be connected > simultaneously) appeared to send exactly the same scancodes as the > keyboard > did. I couldn't see how those might be destinguished whether coming from > the > keybord or from the gamepad. Thus, handling them both together as a single > device would probably be the only option here. > > With both devices connected and keys pressed simultaneously, errors > occure at > the lowest level: parity check failed, invalid stop bit, etc. I don't > think > it would be possible to do anything about this. But this also means that > trying to query them in order to get a sensible response would probably be > not reliable. > > Any thoughts? > > Thanks, > Janusz > > _______________________________________________ > e3-hacking mailing list > e3-hacking(a)earth.li > http://www.earth.li/cgi-bin/mailman/listinfo/e3-hacking ---------------------------------------------------- Kołodziej będzie miażdżył na ringu 18 grudnia, Gala Boksu w Łodzi Zobacz: http://klik.wp.pl/?adr=http%3A%2F%2Fcorto.www.wp.pl%2Fas%2Fwojak18grudnia.h…

1 0

Re: [E3-hacking] [RFC][PATCH 4/5] input: serio: add support for Amstrad Delta serial keyboard port
by Janusz Krzysztofik 14 Dec '09

14 Dec '09

Friday 11 December 2009 03:36:58 Dmitry Torokhov napisał(a): > On Thu, Dec 10, 2009 at 09:07:50PM +0100, Janusz Krzysztofik wrote: > > + > > +/* > > + * This table converts the amstrad mailboard scancodes to normal PC- > > AT scancodes > > + * The diagram below shows the amstrad keyboard, with the raw > > scancodes > > + * > > + * (70) (7A) (46) (7C) (77) Amstrad (72) (69) (1A) (2A) > > (1C) (15) > > + * [ 71][1:74][2:73][3:6B][4:22][5:1B][6:1D][7:1E][8:79][9:7D] > > [0:75][ 6C] > > + * [Q:21][W:23][E:24][R:26][T:52][Y:5D][U:0D][I:0E][O:32][P:34] | > > return| > > + * [A:31][S:33][D:35][F:36][G:29][H:5B][J:03][K:76][L:3A][@:3B] > > > > | 2C| > > > > + * [ 3C][Z:3D][X:4E][C:54][V:0B][B:05][N:41][M:42][.:43][ 3E] > > [ 55] > > + * [ 83][ 06][ 49][ 4B ][,:44][ 16][ 2E] > > [ 09] > > + * > > + * These scancodes are then translated to AT scancodes using the > > following table > > + * The amstrad keyboard does not produce any extended scancodes, > > but we need to > > + * translate some amstrad scancodes to a AT extended scancode, > > hence the 16bit > > + * value for the translated scancode > > + * > > No, please write a proper keyboard driver instead of creating this > Frankenstain monster. It is not a generic serio-style data source so it > should not use serio, should reside in drivers/input/keyboard and create > input device by itself. > > Thanks. Hi Dmitry, Thanks for your opinion. Lack of support for Amstrad Delta external keybord is not a problem for me, since I use the machine as an IP phone, not a network terminal. I just thought it would be nice for other users to have this old but perfectly working driver integrated into the mainline. But if it is that bad as you say, I have no problem with dropping it. I'll see if I'm able to create a proper driver myself when I find some spare time. Thanks, Janusz

2 4

[Blatant advert] E3s for sale...
by Matt Evans 13 Dec '09

13 Dec '09

Howdy all! I do hope this isn't too bad form but I've put two of my E3s up on ebay -- the reason I mention it is they are fairly old, and I believe their PBL version dates from before the one requiring authentication, so ripe for hacking. They're as new, boxed and unopened; bought a few years back & unfortunately haven't had time to tinker with them. http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=120504355860 http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=120504356035 I have a couple of E2s to get rid of also; if I don't get utterly flamed for this email I'll post when I've put them up for sale. :-) I'd prefer to see them go to a hacker of course. Thanks, Matt

1 0

Please help in collecting more information on the mailboard interface
by Janusz Krzysztofik 12 Dec '09

12 Dec '09

Hi, Before I get to work on inventing a driver for the E3 mailboard that could be accepted upstream, I'd like to learn more about the keyboard interface. In 2006, Jasmine Strong wrote: > > Huh --- I did look at the defconfig file, but it never occurred to me to > > look at that bit (after all, the mailboard is most decidedly *not* a PC AT > > keyboard)... > > Actually, it is- it's a PS/2 device. It just happens to be connected to > some IO lines, rather than a FIFO, like it ought to be. Jasmine (I hope you still read this ML), or anyone else who knows anything more about that, could you please provide me with as much information on that matter as possible? Can it be proved in any way that the keyboard is a PS/2 device? For me, the fact that Matt's serio driver interacts correctly with a standard atkbd keyboard driver means that reusing atkbd is not as wrong solution as Dmitry suggests saying a new keyboard driver should be created. Maybe just removing the scancode translation functionality from the Matt's serio driver and somehow pushing a custom keymap for E3 into the atkbd instead could be an acceptable solution here? But before I take this way, I think I have to be able to prove that this keyboard is not really different from a standard AT keyboard, and writing a separate keyboard driver for it, just because the E3 has a non-standard keyboard port, may not be a good idea. Thanks, Janusz

2 2

Fwd: [RFC][PATCH 0/5] omap1: Amstrad Delta: add support for external keyboard
by Janusz Krzysztofik 10 Dec '09

10 Dec '09

Hi, I forgot to CC: e3-hacking on submission, here is a copy, and a link: http://www.spinics.net/lists/linux-omap/msg22001.html. I'll try to remember about adding to CC: when replying to comments if any. Thanks, Janusz ---------- Original message ---------- Subject: [RFC][PATCH 0/5] omap1: Amstrad Delta: add support for external keyboard Date: Thursday, 10 December 2009 From: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> To: linux-omap(a)vger.kernel.org This series of patches adds support for an external keyboard (called mailboard) connected to the Amstrad Delta (E3) videophone. The series is based on a patch by Matt Callow, created against linux-omap-2.6.19[1], initially submitted to the e3-hacking mailing list in April 2006[2]. Since the keyboard serial clock line is connected to a GPIO line, it generates interrupts every single bit received. In order to handle this correctly, the code makes use of a FIQ hardware feature. Since all MPU GPIO generated interrupts would be converted to FIQ, the handler must include support for all supported MPU GPIO connected devices: the keyboard, a modem and a hook switch. My modifications to the original patch include: - split into several patches, - refresh against a recent linux version, - a lot of cleanups, mainly to get rid of checkpatch reported issues, - add support for also handling interrupts generated by a GPIO line that the recently added hook switch hangs off. Created and tested against linux-omap for-next, commit 82f1d8f22f2c65e70206e40a6f17688bf64a892c dated 2009-12-02. Janusz Krzysztofik(5) omap1: Amstrad Delta: add FIQ handler for serial keyboard port interrupt processing omap1: Amstrad Delta: add a handler for processing interrupts generated by the FIQ routine omap1: Amstrad Delta: use FIQ for processing MPU GPIO interrupts input: serio: add support for Amstrad Delta serial keyboard port omap1: Amstrad Delta: modify defconfig for external keyboard support arch/arm/configs/ams_delta_defconfig | 2 arch/arm/mach-omap1/Kconfig | 8 arch/arm/mach-omap1/Makefile | 3 arch/arm/mach-omap1/ams-delta-fiq-handler.S | 342 +++++++++++++++++++++++ arch/arm/mach-omap1/ams-delta-fiq.c | 175 +++++++++++ arch/arm/mach-omap1/board-ams-delta.c | 6 arch/arm/mach-omap1/include/mach/ams-delta-fiq.h | 56 +++ arch/arm/plat-omap/include/plat/irqs.h | 4 drivers/input/serio/Kconfig | 9 drivers/input/serio/Makefile | 1 drivers/input/serio/ams_delta_keyboard.c | 240 ++++++++++++++++ 11 files changed, 845 insertions(+), 1 deletion(-) [1] http://the.earth.li/pub/e3/2.6.19/ams-delta-keyboard.patch [2] http://www.earth.li/pipermail/e3-hacking/2006-April/000453.html --- There is one minor issue that I have not dealt with yet: when built with CONFIG_OMAP_RESET_CLOCKS=y, the keyboard driver stops working. I have no idea how I could find which clock I should enable to get it working regardless of boot loader used. Any suggestions? Thanks, Janusz -------------------------------------------------------

1 0

Adding the keyboard (mailboard) support
by Janusz Krzysztofik 30 Nov '09

30 Nov '09

Hi, I have managed to refresh Matt's Amstrad Delta keyboard patch, created against linux-omap-2.6.16-omap2. Now it applies cleanly on top of curent linux-omap for-next, and seems to work flawlessly. I have also made some modifications in order to avoid breaking support for the hook switch that has been added recently (thanks to what you discovered about it a few years ago). Matt (I hope you still read the e3-hacking list), don't you mind if I submit the modified patch to the linux-omap mailing list in order to get it included in the linux-omap tree first and then pushed into the mainline? Jonathan, can you remember why the keyboard patch never found it's way into the linux-omap tree? If you know of any isues with it, I could try to solve them before submitting. Thanks, Janusz

3 4

Amstrad E3 support status for 2.6.32
by Janusz Krzysztofik 15 Nov '09

15 Nov '09

Hi, The kernel release 2.6.32 is almost out. I have just downloaded and tested 2.6.32-rc7 successfully (I hope there will be no more fixes required). After unpacking it, I run: ARCH=arm make ams_delta_defconfig then build the kernel in a usual way. Using old E3_release_v2.tar.gz with uImage replaced with the one just built (arch/arm/boot/uImage), I was able to boot the machine, log into the install-initrd, both from ttyS0 and framebuffer console, get access to a USB stick, verify on-board flash is accessible. I did not proceed with ams_delta_install, but I think it would run without problems. Compared to that old 2.6.16-omap1 with ams_delta patches, 2.6.32 mainline kernel doesn't yet support the detachable keyboard (mailboard) and doesn't provide a driver for LCD contrast and backlight setting, but it has LED support introduced in 2.6.17. There is still no support for the camera (it was present once in 2.6.19). Full framebuffer/LCD driver, frozen in the OMAP tree for a long time, finally found it's wat into the mainline. Old sound driver has been replaced with a new one, ASoC based. Both ALSA and OSS interface are fully usable. The new driver supports full duplex and handset/speakerphone switching using the hook switch and/or a mixer control. To get those features working, ldattach utility (sadly not present on the old initramfs) must be used in order to load a line discipline #19 onto the modem line (has been moved to ttyS3). The hook switch state can be simply detrmined by examining /sys/class/gpio/gpio4/value file contents, it also generates regular input events over the /dev/input/event1 device interface. The kernel with ams_delta_defconfig applied supports both old distributions, like Familiar that E3_release_v2 was based on, and new, like Angstrom, that may require EABI + Thumb instructions turned on. Power management is turned on by default with not much visible results yet. Starting with this kernel release, the machine, equipped with a network adapter and a suitable userspace software, can ultimately be used as an IP phone. Personally, I use asterisk combined with lirc for the purpose. Thanks, Janusz

1 1

Re: [E3-hacking] [PATCH 3/8] omap1: Amstrad Delta defconfig fixes
by Janusz Krzysztofik 11 Nov '09

11 Nov '09

Wednesday 11 November 2009 04:00:57 Tony Lindgren napisał(a): > From: Janusz Krzysztofik <jkrzysz(a)tis.icnet.pl> > > The patch provides the following fixes: > > - keep kernel small enough to boot with standard tools, > - ensure compatibility with both new and legacy distros, > - turn on support for recently added or fixed hardware features. > > Created and tested against linux-2.6.32-rc5. > > Signed-off-by: Janusz Krzysztofik <jkrzysz(a)tis.icnet.pl> > Signed-off-by: Tony Lindgren <tony(a)atomide.com> Tony, Please do not apply this patch yet, or revert it if already applied. It would exhibit the LCD DMA not working bug when CONFIG_PM=y, as I tried to state while submitting v2 of my fix that corrected the issue (http://www.spinics.net/lists/linux-omap/msg19963.html). Sorry for not stating that again with this submission (or not waiting with the submission after the bug is fixed first). That happened after I misinterpreted your comment "Sounds good to me." (http://www.spinics.net/lists/linux-omap/msg19965.html) as your acceptance for the patch v2 as posted, with my self proposed changes, that resulted in v3 submission directly (http://www.spinics.net/lists/linux-omap/msg20059.html), that has been objected by you next. Thanks, Janusz > --- > arch/arm/configs/ams_delta_defconfig | 24 +++++++++++++++++------- > 1 files changed, 17 insertions(+), 7 deletions(-) > > diff --git a/arch/arm/configs/ams_delta_defconfig > b/arch/arm/configs/ams_delta_defconfig index 7647325..e8f7380 100644 > --- a/arch/arm/configs/ams_delta_defconfig > +++ b/arch/arm/configs/ams_delta_defconfig > @@ -55,10 +55,10 @@ CONFIG_BLK_DEV_INITRD=y > CONFIG_INITRAMFS_SOURCE="" > CONFIG_CC_OPTIMIZE_FOR_SIZE=y > CONFIG_SYSCTL=y > -# CONFIG_EMBEDDED is not set > +CONFIG_EMBEDDED=y > CONFIG_UID16=y > CONFIG_SYSCTL_SYSCALL=y > -CONFIG_KALLSYMS=y > +# CONFIG_KALLSYMS is not set > # CONFIG_KALLSYMS_ALL is not set > # CONFIG_KALLSYMS_EXTRA_PASS is not set > CONFIG_HOTPLUG=y > @@ -224,7 +224,7 @@ CONFIG_CPU_CP15_MMU=y > # > # Processor Features > # > -# CONFIG_ARM_THUMB is not set > +CONFIG_ARM_THUMB=y > # CONFIG_CPU_ICACHE_DISABLE is not set > # CONFIG_CPU_DCACHE_DISABLE is not set > CONFIG_CPU_DCACHE_WRITETHROUGH=y > @@ -248,7 +248,7 @@ CONFIG_CPU_DCACHE_WRITETHROUGH=y > # CONFIG_HIGH_RES_TIMERS is not set > CONFIG_PREEMPT=y > CONFIG_HZ=100 > -# CONFIG_AEABI is not set > +CONFIG_AEABI=y > # CONFIG_ARCH_DISCONTIGMEM_ENABLE is not set > CONFIG_SELECT_MEMORY_MODEL=y > CONFIG_FLATMEM_MANUAL=y > @@ -299,7 +299,9 @@ CONFIG_BINFMT_ELF=y > # > # Power management options > # > -# CONFIG_PM is not set > +CONFIG_PM=y > +# CONFIG_SUSPEND is not set > +CONFIG_PM_RUNTIME=y > > # > # Networking > @@ -670,7 +672,7 @@ CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 > CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 > # CONFIG_INPUT_JOYDEV is not set > # CONFIG_INPUT_TSDEV is not set > -# CONFIG_INPUT_EVDEV is not set > +CONFIG_INPUT_EVDEV=y > # CONFIG_INPUT_EVBUG is not set > > # > @@ -784,6 +786,7 @@ CONFIG_I2C_OMAP=y > # > # CONFIG_SPI is not set > # CONFIG_SPI_MASTER is not set > +CONFIG_GPIO_SYSFS=y > > # > # Dallas's 1-wire bus > @@ -820,6 +823,7 @@ CONFIG_LEDS_AMS_DELTA=y > CONFIG_LEDS_TRIGGERS=y > CONFIG_LEDS_TRIGGER_TIMER=y > CONFIG_LEDS_TRIGGER_HEARTBEAT=y > +CONFIG_LEDS_TRIGGER_DEFAULT_ON=y > > # > # Multimedia devices > @@ -896,7 +900,13 @@ CONFIG_LOGO_LINUX_CLUT224=y > # > # Sound > # > -# CONFIG_SOUND is not set > +CONFIG_SOUND=y > +CONFIG_SND=y > +CONFIG_SND_MIXER_OSS=y > +CONFIG_SND_PCM_OSS=y > +CONFIG_SND_SOC=y > +CONFIG_SND_OMAP_SOC=y > +CONFIG_SND_OMAP_SOC_AMS_DELTA=y > > # > # HID Devices > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html

2 1

[PATCH] ASoC: Amstrad Delta: add info about the line discipline requirement to Kconfig help text
by Janusz Krzysztofik 25 Oct '09

25 Oct '09

I thought it could be usefull to add some information on how to get the device fully supported by loading a line discipline on the modem line. Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- As you could probably notice, I am not a native English, so please feel free to correct my poor language if desired. --- linux-2.6.32-rc5/sound/soc/omap/Kconfig.orig 2009-10-16 02:41:50.000000000 +0200 +++ linux-2.6.32-rc5/sound/soc/omap/Kconfig 2009-10-24 00:01:26.000000000 +0200 @@ -21,7 +21,18 @@ config SND_OMAP_SOC_AMS_DELTA select SND_OMAP_SOC_MCBSP select SND_SOC_CX20442 help - Say Y if you want to add support for SoC audio on Amstrad Delta. + Say Y if you want to add support for SoC audio device connected to + a handset and a speakerphone found on Amstrad E3 (Delta) videophone. + + Note that in order to get those devices fully supported, you have to + build the kernel with standard serial port driver included and + configured for at least 4 ports. Then, from userspace, you must load + a line discipline #19 on the modem (ttyS3) serial line. The simplest + way to achieve this is to install util-linux-ng and use the included + ldattach utility. This can be started automatically from udev, + a simple rule like this one should do the trick (it does for me): + ACTION=="add", KERNEL=="controlC0", \ + RUN+="/usr/sbin/ldattach 19 /dev/ttyS3" config SND_OMAP_SOC_OSK5912 tristate "SoC Audio support for omap osk5912"

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
40
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

e3-hacking