Re: [2*PATCH] alpha I/O access and mb()
Before of all I want to publicly apologize with Richard as never my intention was to exacerbate him. > > On Sun, Dec 10, 2000 at 10:23:20PM +0100, Abramo Bagnara wrote: > > asm/io.h uses out of line function only when CONFIG_ALPHA_GENERIC is > > defined, otherwise it uses (take writel as an example) __raw_writel that > > IMHO need to be defined in core_t2.h. > > Perhaps you should _show_ an actual failure rather than just guessing. I've not access to this specific hardware but I was trying to fix the alpha case wrt write[bwlq] function as I've had a lot of trouble with ALSA drivers and 2.2 (that still now is broken wrt mb() and I've sent a patch to Alpha Processor guys). This is the reason why I've given a look to 2.4. > > You are wildly incorrect asserting that out of line functions are used > only with CONFIG_ALPHA_GENERIC. You should examine > > #ifndef __raw_writel > # define __raw_writel(v,a) ___raw_writel((v),(unsigned long)(a)) > #endif > > and suchlike definitions. Now I understand, thanks. I see that some core*.h leaves out of line some functions because they are more complex than a choosen threshold. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2*PATCH] alpha I/O access and mb()
On Sun, Dec 10, 2000 at 10:23:20PM +0100, Abramo Bagnara wrote: > asm/io.h uses out of line function only when CONFIG_ALPHA_GENERIC is > defined, otherwise it uses (take writel as an example) __raw_writel that > IMHO need to be defined in core_t2.h. Perhaps you should _show_ an actual failure rather than just guessing. You are wildly incorrect asserting that out of line functions are used only with CONFIG_ALPHA_GENERIC. You should examine #ifndef __raw_writel # define __raw_writel(v,a) ___raw_writel((v),(unsigned long)(a)) #endif and suchlike definitions. > core_t2.h is the only core_*.h file that does not define it and this is > why I've proposed that patch. FOR THE NTH TIME, NO IT IS NOT! How often do I have to point you at the other files that do not define (all of) these macros before you will believe me? Jesus H Christ! Look at some preprocessor output why don't you? Better yet, compile the kernel with CONFIG_ALPHA_T2. Notice how it does not fail with undefined symbol errors. Notice how there are non-trivial bit fiddling insns implementing the functions in alpha/lib/io.o. That's the quickest way to see that I'm right and you aren't. End of discussion. r~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2*PATCH] alpha I/O access and mb()
Richard Henderson wrote: > > On Sun, Dec 10, 2000 at 08:04:07PM +0100, Abramo Bagnara wrote: > > ... the only missing things from core_t2.h are some defines to > > permit to it to work when CONFIG_ALPHA_T2 is defined. > > Have you tried it? I did. It works fine. > > What _is_ defined in asm/core_t2.h is enough for alpha/lib/io.c to > define out of line functions that asm/io.h then uses. asm/io.h uses out of line function only when CONFIG_ALPHA_GENERIC is defined, otherwise it uses (take writel as an example) __raw_writel that IMHO need to be defined in core_t2.h. core_t2.h is the only core_*.h file that does not define it and this is why I've proposed that patch. Perhaps there is a reason I don't understand and in this case I want to apologize and I'd like to ask you to explain me what I'm missing. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2*PATCH] alpha I/O access and mb()
On Sun, Dec 10, 2000 at 08:04:07PM +0100, Abramo Bagnara wrote: > ... the only missing things from core_t2.h are some defines to > permit to it to work when CONFIG_ALPHA_T2 is defined. Have you tried it? I did. It works fine. What _is_ defined in asm/core_t2.h is enough for alpha/lib/io.c to define out of line functions that asm/io.h then uses. This same mechanism is used on cia, mcpcia, lca, and jensen. It has been in place in just this fashion since 2.1.something. r~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2*PATCH] alpha I/O access and mb()
Richard Henderson wrote: > > On Sun, Dec 10, 2000 at 10:40:12AM +0100, Abramo Bagnara wrote: > > And this would be the only core_*.h files where this intention is > > expressed? > > Not at all. See core_lca.h, jensen.h, core_cia.h, core_mcpcia.h. I think you're confusing the issues: the only missing things from core_t2.h are some defines to permit to it to work when CONFIG_ALPHA_T2 is defined. The with or without mb() issue is handled in io.h and it's common for all cores. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2*PATCH] alpha I/O access and mb()
On Sun, Dec 10, 2000 at 10:40:12AM +0100, Abramo Bagnara wrote: > And this would be the only core_*.h files where this intention is > expressed? Not at all. See core_lca.h, jensen.h, core_cia.h, core_mcpcia.h. r~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2*PATCH] alpha I/O access and mb()
Richard Henderson wrote: > > On Sat, Dec 09, 2000 at 09:43:00AM +0100, Abramo Bagnara wrote: > > alpha-mb-2.4.diff add missing defines from core_t2.h for non generic > > kernel (against 2.4.0test11) > > These are not "missing". They are intentionally not present > so that stuff will be done out of line. And this would be the only core_*.h files where this intention is expressed? It's hard to believe, without you explain why ;-) -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2*PATCH] alpha I/O access and mb()
On Sat, Dec 09, 2000 at 09:43:00AM +0100, Abramo Bagnara wrote: > alpha-mb-2.4.diff add missing defines from core_t2.h for non generic > kernel (against 2.4.0test11) These are not "missing". They are intentionally not present so that stuff will be done out of line. r~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2*PATCH] alpha I/O access and mb()
On Sat, 9 Dec 2000, Abramo Bagnara wrote: > Gérard Roudier wrote: > > > > > > Based on that, let me claim that most of blind barriers inserted this way > > are useless (thus sob-optimal) and may band-aid useful barriers that are > > missing. The result is subtle bugs, hidden most of the time, that we will > > have to suffer for decades. > > > > The only way to do things right regarding ordering it to have device > > drivers _aware_ of such issues. Now, if we are happy with broken portable > > or platform-independant drivers that rely on broken hidden ordering > > alchemy rather than on correctness, then it is another story. > > I see perfectly your point and this is the reason why we have > __raw_write[bwlq] in 2.4, but write[bwlq] expected semantic is to ensure > that write *happens* and are visible by other agents. Ordering and flushing are different issues. Hardware may flush in order to guarantee some order, but if nothing is to order it may not. A memory barrier does not guarantee you that a write will go faster to the system BUS. Basically, if no other agent does need the data and the data is cacheable, the flushing is just useless. Confusing ordering and flushing is a serious mistake in my humble opinion. Speaking about MMIO which is not cacheable, indeed we want the data targetting the MMIO area to be flushed quickly. But we also want the device to have a consistent vue of the data in memory for all IOs it is provided with. Usually, we have to deal with the following: 1) Prepare some DATA in cachable memory (DMA related) 2) Ensure ordering: i.e. may insert a MEMORY BARRIER 3) Tell the device about the IO to perform: write to MMIO Drivers that are unaware of (2) _are_ broken. Or: 1) Read device status register to know about IO that completed. 2) Ensure ordering of speculative reads against DMA from the device. i.e. may insert a MEMORY (READ) BARRIER. 3) Look into memory for IOs that have completed. Drivers that are unaware of (2) _are_ broken. Since the hidden BUS stuff just puts its implicit barriers at the wrong place regarding the above, any device driver that does DMA and that does not use explicit barriers is likely to be broken even if it uses normal IOs. Reason is that the PCI specifications also allow host bridges to post IO transactions and thus assuming 15 years old ISA-like behaviour is plain wrong. > You can tell me that almost nobody uses __raw_write now and this is bad > and I agree with you, but sometime this is not a perfect world ;-) The various BUS abstractions I have to suffer of are indeed a great demonstration of our world being not perfect. ;-) Hehe... I read so often that most drivers are broken that shoe-horning bunches or barriers, bus things and other band-aidings is probably the only way to have some of them mostly usable. ;-) Or could it be that current O/S guys are still ISA-bussed. ;-) By the way, given our real world, your patch is probably quite reasonnable. My point was not to disagree with it, in particular. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2*PATCH] alpha I/O access and mb()
Gérard Roudier wrote: > > > Based on that, let me claim that most of blind barriers inserted this way > are useless (thus sob-optimal) and may band-aid useful barriers that are > missing. The result is subtle bugs, hidden most of the time, that we will > have to suffer for decades. > > The only way to do things right regarding ordering it to have device > drivers _aware_ of such issues. Now, if we are happy with broken portable > or platform-independant drivers that rely on broken hidden ordering > alchemy rather than on correctness, then it is another story. I see perfectly your point and this is the reason why we have __raw_write[bwlq] in 2.4, but write[bwlq] expected semantic is to ensure that write *happens* and are visible by other agents. You can tell me that almost nobody uses __raw_write now and this is bad and I agree with you, but sometime this is not a perfect world ;-) -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2*PATCH] alpha I/O access and mb()
On Sat, 9 Dec 2000, Abramo Bagnara wrote: > > Here you are two patches: > > alpha-mb-2.2.diff add the missing mb() to the cores that still lack it > (against 2.2.18pre25) > > alpha-mb-2.4.diff add missing defines from core_t2.h for non generic > kernel (against 2.4.0test11) > > Please apply on your trees. > > I've also noted that 2.4 uses mb() after read[bwlq] while 2.2 don't. > Who's right? Let me howl for a minute. :-) The actual issue regarding ordering is generally to ensure something to happen (i.e. to be seen to happen by other agents) _before_ something else. As a result, what we have in mind is to insert a barrier _before_ this `something else'. However, everything I seem to see about this issue on our planet and that applies to IO subsystems is blindly inserting barriers _after_ the 'something'. Is software getting sci. fi. ? ;-) Based on that, let me claim that most of blind barriers inserted this way are useless (thus sob-optimal) and may band-aid useful barriers that are missing. The result is subtle bugs, hidden most of the time, that we will have to suffer for decades. The only way to do things right regarding ordering it to have device drivers _aware_ of such issues. Now, if we are happy with broken portable or platform-independant drivers that rely on broken hidden ordering alchemy rather than on correctness, then it is another story. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/