Problem w sterowniku 8250 - printk pomaga, brak sekcji krytycznej - Thread - go-pugleaf

Thread View: pl.comp.os.linux.programowanie

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by elonica.pl Thu, 27 Oct 2011 08:44

Problem w sterowniku 8250 - printk pomaga, brak sekcji krytycznej

#72373

Author: elonica.pl
Date: Thu, 27 Oct 2011 08:44

35 lines
2451 bytes

Witam,

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.

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 ? Jak najlepiej jest wrzucić
sekcje krytyczna w tym przypadku ?

void write_byte(u16 address, u8 value)
{
	printk("+write_byte 0x%x <- %x \n",address,value);
	//udelay(1);

	//CRITICAL_SECTION_ENTER();
	// set adress "EBA8".."EBA4"
	ebireg1 = (ebireg1 & 0x60) | ((address >> 4) & 0x1F);		// set address
hi nibble
	// "XEBI-D*" as output (data bits)
	SoCreg(GPIO39_24_DIR) |= 0x000000FF; // GPIO39_24_DIR
'b*.****.oooo.oooo
	//  ebireg1 to be written to "XEBI-D*" (databits)
	SoCreg(GPIO39_24_DATA) = ( SoCreg(GPIO39_24_DATA) & 0xFFFFFF00 ) |
0x80 | ebireg1;
	// stobe signal U19.Pin11 = 0 ("XEBI-D7"==1);
[...]
	//CRITICAL_SECTION_LEAVE();
}

Pozdrawiam
Bartlomiej Grzeskowiak

Re: Problem w sterowniku 8250 - printk pomaga, brak sekcji krytycznej

#72374

Author: Krzysztof Halasa
Date: Thu, 27 Oct 2011 23:19

29 lines
2298 bytes

"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

Re: Problem w sterowniku 8250 - printk pomaga, brak sekcji krytycznej

#72375

Author: elonica.pl
Date: Fri, 04 Nov 2011 13:53

71 lines
4128 bytes

On 28 Paź, 00:19, Krzysztof Halasa <k...@pm.waw.pl> wrote:
> "elonica.pl" <bartlomiej.grzeskow...@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.
>

Witam,

Scalak to architektura mips-el (Mips little endian).
SoCreg: #define SoCreg(n)		(*((volatile u32 *)(n)))
kompilator: buildroot-gcc342/bin/mipsel-linux-uclibc-gcc

Jak wspominałem udelay nie pomaga, pomaga za to printk wstawiony w
kod.

> > 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

Rozumiem, ze chodzi o porównanie plików s "przed" i "po" zmianie.
Mozna je uzyskać stosując -save-temps w wywołaniu kompilatora.
Hmmm... Jak dla mnie zmiany wyglądają niegroźnie. W dzialajacym pliku
(z wywoalniem printk) Doszły dodatkowe wstawki:

Na początku - deklaracja stringa:

	.section	.rodata.str1.4
	.align	2
$LC20:
	.ascii	"+write_byte 0x%x <- %x \n\000"
	.text

I w funkcji write byte:

	.loc 1 404 0
	lui	$4,%hi($LC20)
	move	$5,$16
	move	$6,$17
	.set	noreorder
	.set	nomacro
	jal	printk
	addiu	$4,$4,%lo($LC20)
	.set	macro
	.set	reorder

Dla ścisłości poprzesuwały się tez indeksy $LCXX większe od 20 o jeden
do góry, ale to logiczne.

--
Bartlomiej Grzeskowiak

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads