PCI Parport-Karte DMA zuweisen?

[Jan 'RedBully' Seiffert]

Jan-Benedict Glaw schrieb:
> On Mon, 2010-03-01 16:43:27 +0100, Jan 'RedBully' Seiffert <redbully at cc.hs-owl.de> wrote:
>> Jan-Benedict Glaw schrieb:
>>> On Mon, 2010-02-22 21:00:38 +0100, Stefan U. Hegner <stefan at hegner-online.de> wrote:
>>>> Jan 'RedBully' Seiffert schrieb:
>>>>> Ist es denn irgendwie zu langsam fuer deinen Anwendungsfall?
>>>>  Nicht direkt.
>>>>
>>>> Will damit unter lenny (amd64) einen alten Batronix Parport Eprommer ans
>>>> Rennen bekommen. Am Notebook (lenny, i686; das hat noch einen
>>>> ISA-Parport) tut das Ding. Einziger augenscheinlicher Unterschied war
>>>> die Parport Konfiguration und da, dass am Notebook ein DMA-Kanal belegt war.
>>>>
>>>> Jedenfalls wolle zprommer (http://www.zut.de/zprommer.html) und
>>>
>>> zprommer: Die machen direkt inb()/outb(), kein DMA. (Und dummerweise
>>> fummeln die direkt an der Hardware rum, sind nicht portabel und
>>> nichts, statt einfach mal die ppdev API zu nutzen.)
>>
>> Jupp, deshalb hab ich zprommer mal grad auf ppdev umgeschrieben
>> -> keine besserung
> 
> Das ist schonmal ein Anfang. Die Frage ist immernoch, wo denn die
> ganze Zeit bleibt, oder ob das so einfach okay ist.
> 

Nagut, man hat durch das ppdev-ioctl-gehampel etwas syscall overhaed, aber
Stefan hatte den ppdev code auf dem notebook ausprobiert: genauso schnell wie
mit outb/inb.
Es muss also irgendwo anders bleiben.
Das strace (allen ungenauigkeiten zum troz) zeigt das die ioctl nur so
durchschnurren.
Das einzige was "raussteht" ist eben genau diese Verzoegerung beim
zurueckschalten auf SCHED_OTHER.

>> Daten landen da wo sie sollen, es dauert aber immer noch ewigkeiten.
>> [snip]
>> Nach meinung des Authors sollte man wohl mal ein blick darauf werfen:
>>
>>    	sched_setscheduler(0,SCHED_FIFO,&schedhigh);
>>     	nanosleep(&waitxns,&restwait);
>>     	sched_setscheduler(0,SCHED_OTHER,&schednormal);
> 
> Für Scheduler-Spielereien könntest Du mal Jörg Schilling befragen. :=)
> 

Soll ich noch Con Kovalis dazurufen?
*hust*
nicht wenn es sich vermeiden laesst...
Ich ahne es schon, ich darf den Scheduler auseinader nehmen oder was...
Wieder irgendwas mit fair_waiter oder sowas?
Ich hasse es wenn ich in Hornissennester trete..

Was damit die Frage aufwirft:

Stefan, welche Kernel Versionen?

> Aber im Ernst, ich würds erstmal ohne alles probieren.

Patch an Stefan ist raus.

> Solange die Kiste an sich idle ist, solltest Du mit der Zeit keine Probleme
> haben.

Sicher, man sieht ja das da Spielraum drin ist, das nanosleep schlaeft ja nicht
wirklich die geforderten 120ns, sondern mehr, trozdem "gehts" (as in: Die
richten Daten landen im Baustein).

> Und für "unter Last" kann man sich dann ja nochmal was
> überlegen.

Aber was...

> Mit Scheduler-Foo hab' ich allerdings auch noch nicht so
> wirklich 'rumgespielt...
>

Was, der JBG hat irgendwas im Kernel noch nicht von links nach rechts gedreht?
;)

> MfG, JBG
> 

Gruss
	Jan

-- 
/home
sweet
/home