🚀 go-pugleaf

"elonica.pl" <bartlomiej.grzeskowiak@gmail.com> writes:

> Mam napisaną własną część sterownika 8250. Dodatkowe kości 16C550
> podłączone są przez GPIO. Problem jest taki, ze sterownik gubi mi
> część znaków przesyłanych na /dev/ttySX (pojawia sie tylko jakies
> 20%). Podczas deboggowania wyszło, ze kiedy wstawię printk na początku
> w funkcji write_byte(...). Problem znika.

A co to za scalak?
Teoretycznie jest szansa, ze samo opoznienie cos powoduje (np.
w przypadku wadliwych operacji I/O), ale bardziej prawdopodobne jest, ze
udelay() tworzy bariery, ktore zapobiegaja "wyoptymalizowaniu" rzekomo
zbednego kodu, albo np. zmianie kolejnosci kodu. Domyslam sie ze
SoCreg() to jakis *(volatile *)... co to za kompilator? Przyjrzalbym sie
wersji assemblerowej w obu przypadkach. Np. gcc 2.6.x jest znany z tego,
ze potrafi wyoptymalizowac niektore rzeczy tak, jakby nie byly volatile.

> Próbowałem już kilkanaście razy zmieniać delaye, ale nic. Jedyne co mi
> jeszcze przychodzi do głowy to fakt, ze funkcje read i write nie sa
> sekcjami krytycznymi. Czy to dobry trop ?

Mam delikatne wrazenie, ze driver 8250 wykonuje tylko jedna operacje
w danej chwili (sam uzywa spinlocka), co by sugerowalo, ze te funkcje
nie musza byc "atomic". Ale oczywiscie tak jest tylko pod warunkiem, ze
zaden inny kod (np. inny driver) ich nie uzywa.

Plik .s (a wlasciwie dwa pliki) powinny rozjasnic sprawe.
-- 
Krzysztof Halasa