Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
Alan Cox <[EMAIL PROTECTED]> wrote: > > Some are part of the CPU core and affect things like CPU core itself, CPU > > caches, MMU/TLB and exceptions/interrupts. Others are on-silicon devices > > such as the serial ports, the bus controller, the SDRAM controller. > > How are they addressed - as CPU registers or as memory/IO space ? Well, they're all accessed as memory locations within a special range of addresses (all of 0xCxxx and 0xDxxx). This includes the magic CPU registers. This is hard coded by the CPU before the MMU gets its hands on the addresses, AFAIK. I also wondered what about the boot wrapper (the kernel decompressor): Is that permitted to use readb() and co? David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
Alan Cox [EMAIL PROTECTED] wrote: Some are part of the CPU core and affect things like CPU core itself, CPU caches, MMU/TLB and exceptions/interrupts. Others are on-silicon devices such as the serial ports, the bus controller, the SDRAM controller. How are they addressed - as CPU registers or as memory/IO space ? Well, they're all accessed as memory locations within a special range of addresses (all of 0xCxxx and 0xDxxx). This includes the magic CPU registers. This is hard coded by the CPU before the MMU gets its hands on the addresses, AFAIK. I also wondered what about the boot wrapper (the kernel decompressor): Is that permitted to use readb() and co? David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
On Sat, Nov 10, 2007 at 11:43:20AM -0800, Andrew Morton wrote: > On Sat, 10 Nov 2007 12:18:50 + David Howells <[EMAIL PROTECTED]> wrote: >... > > has a couple of examples on it's front page. If you work through the menus > > of > > modern Panasonic tellies, you might find a URL pointing somewhere on this > > website that isn't reachable by linking from the index page of the website. > > > > I don't know who else uses this CPU, but it's possible MEI sell them to > > other > > companies. > > If it is indeed the case that this architecture is used internally by a > single organisation then perhaps it doesn't make sense for us to merge it. > > One of the main reasons we put code into the kernel is as a means of > distribution: to get it into the hands of people who need it. But in this > situation there is no advantage to *anyone* from this merge apart from MEI. > > IOW, the submitter gains and everyone else loses. It's a curious situation. >... You miss the point that we want people to be able to use Linux in such situations. There are basically two choices: - Either tell them code won't get merged and offer some degree of API stability in exchange or - allow all code with >= 1 users to enter the kernel. [1] With the current development model (and the mere amount of changes merged), the first choice is not possible. The only reason for not merging it [1] would be if it would be unmaintained and bitrot, but considering that David is already doing a good job at maintaining the frv port that's not an issue here. cu Adrian [1] assuming the code itself is considered OK -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
> Some are part of the CPU core and affect things like CPU core itself, CPU > caches, MMU/TLB and exceptions/interrupts. Others are on-silicon devices such > as the serial ports, the bus controller, the SDRAM controller. How are they addressed - as CPU registers or as memory/IO space ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
Alan Cox <[EMAIL PROTECTED]> wrote: > Ok so these are not addresses but magic registers in the processor ? Then > I guess volatile makes complete sense. They are such magic registers, though of various grades. Some are part of the CPU core and affect things like CPU core itself, CPU caches, MMU/TLB and exceptions/interrupts. Others are on-silicon devices such as the serial ports, the bus controller, the SDRAM controller. > For PIO (virtual DMA or otherwise) the locking does that. Because > spin_unlock and spin_lock are compiler barriers the need to use volatile > shouldn't normally be there. If you are doing it via asm without locks > then I would expect atomic_t because the sematics of volatile are > horribly vague on their own ? Using memory barriers ought to be good enough for the ring buffer. There aren't actually any atomic ops available other than bit-set and bit-clear. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
> So you would say change the global h/w register variables[*] to be addresses > instead, and change all the references to be readX and writeX? I'm wary of Ok so these are not addresses but magic registers in the processor ? Then I guess volatile makes complete sense. > > Similarly spin_lock/unlock are store barriers so for ring buffers should > > be sufficient unless you have cache management requirements in which case > > the dma_* APIs will handle those bits. > > I don't actually need locks, but sticking smp_rmb()/smp_wmb() is probably the > right thing to do now that I know how to use them. This code was written five > or six years ago and I haven't really thought about changing that since. > > I don't see how the dma_* APIs would help. The buffer is filled by a higher > priority interrupt routine that does 'virtual DMA'. It's not actually done by > real DMA. Normal interrupt disablement doesn't really disable interrupts, it > justs excludes normal priority interrupts. For real DMA the dma_ APIs keep coherency > The virtual DMA is done is ASM as it has to be really quick. It's > unfortunate, > but, the on-chip serial ports don't have a FIFO. For PIO (virtual DMA or otherwise) the locking does that. Because spin_unlock and spin_lock are compiler barriers the need to use volatile shouldn't normally be there. If you are doing it via asm without locks then I would expect atomic_t because the sematics of volatile are horribly vague on their own ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
Alan Cox <[EMAIL PROTECTED]> wrote: > memory mapped registers should be read with readw and friends and that > should contain the volatile not the public code. Actually, I can think of a good reason for *not* doing that. What I have at the moment encodes the size of the register to be accessed in the type. What you're suggesting does not. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
Alan Cox <[EMAIL PROTECTED]> wrote: > memory mapped registers should be read with readw and friends and that > should contain the volatile not the public code. So you would say change the global h/w register variables[*] to be addresses instead, and change all the references to be readX and writeX? I'm wary of doing that in case some special logic needs to be inserted in there to handle funny buses differently. I used to have code like that in there, though there's none at the moment. On the other hand, since the CPU addresses are for the most part constants, I can probably do something clever with __builtin_const_p() if it comes to that. [*] This includes auxiliary CPU control registers, though I suppose that doesn't make any difference. > Similarly spin_lock/unlock are store barriers so for ring buffers should > be sufficient unless you have cache management requirements in which case > the dma_* APIs will handle those bits. I don't actually need locks, but sticking smp_rmb()/smp_wmb() is probably the right thing to do now that I know how to use them. This code was written five or six years ago and I haven't really thought about changing that since. I don't see how the dma_* APIs would help. The buffer is filled by a higher priority interrupt routine that does 'virtual DMA'. It's not actually done by real DMA. Normal interrupt disablement doesn't really disable interrupts, it justs excludes normal priority interrupts. The virtual DMA is done is ASM as it has to be really quick. It's unfortunate, but, the on-chip serial ports don't have a FIFO. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
Andrew Morton <[EMAIL PROTECTED]> wrote: > If it is indeed the case that this architecture is used internally by a > single organisation then perhaps it doesn't make sense for us to merge it. I don't know that this is so. I can ask them, but I don't know if they'll tell me that. Furthermore, it's better to have the code upstream[*]. That way the person wanting to make a sweeping change across all arches who knows how the change should be made can have a go at making the change, rather than someone who's constantly playing catchup and may not understand fully. [*] As people keep saying. Constantly playing catchup really isn't fun, as I'm sure you appreciate with maintaining the -mm tree. You, after all, do it on a much larger scale than everyone else. > I guess if it were possible to install a self-built kernel into a Panasonic > gadget then we could look at it on that basis. Do you know if that's the > case? I don't, no. Besides, I *do* have Panasonic devices I can install random software and hardware on to:-) But it's not COTS stuff. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
Andrew Morton [EMAIL PROTECTED] wrote: If it is indeed the case that this architecture is used internally by a single organisation then perhaps it doesn't make sense for us to merge it. I don't know that this is so. I can ask them, but I don't know if they'll tell me that. Furthermore, it's better to have the code upstream[*]. That way the person wanting to make a sweeping change across all arches who knows how the change should be made can have a go at making the change, rather than someone who's constantly playing catchup and may not understand fully. [*] As people keep saying. Constantly playing catchup really isn't fun, as I'm sure you appreciate with maintaining the -mm tree. You, after all, do it on a much larger scale than everyone else. I guess if it were possible to install a self-built kernel into a Panasonic gadget then we could look at it on that basis. Do you know if that's the case? I don't, no. Besides, I *do* have Panasonic devices I can install random software and hardware on to:-) But it's not COTS stuff. David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
Alan Cox [EMAIL PROTECTED] wrote: memory mapped registers should be read with readw and friends and that should contain the volatile not the public code. So you would say change the global h/w register variables[*] to be addresses instead, and change all the references to be readX and writeX? I'm wary of doing that in case some special logic needs to be inserted in there to handle funny buses differently. I used to have code like that in there, though there's none at the moment. On the other hand, since the CPU addresses are for the most part constants, I can probably do something clever with __builtin_const_p() if it comes to that. [*] This includes auxiliary CPU control registers, though I suppose that doesn't make any difference. Similarly spin_lock/unlock are store barriers so for ring buffers should be sufficient unless you have cache management requirements in which case the dma_* APIs will handle those bits. I don't actually need locks, but sticking smp_rmb()/smp_wmb() is probably the right thing to do now that I know how to use them. This code was written five or six years ago and I haven't really thought about changing that since. I don't see how the dma_* APIs would help. The buffer is filled by a higher priority interrupt routine that does 'virtual DMA'. It's not actually done by real DMA. Normal interrupt disablement doesn't really disable interrupts, it justs excludes normal priority interrupts. The virtual DMA is done is ASM as it has to be really quick. It's unfortunate, but, the on-chip serial ports don't have a FIFO. David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
Alan Cox [EMAIL PROTECTED] wrote: memory mapped registers should be read with readw and friends and that should contain the volatile not the public code. Actually, I can think of a good reason for *not* doing that. What I have at the moment encodes the size of the register to be accessed in the type. What you're suggesting does not. David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
So you would say change the global h/w register variables[*] to be addresses instead, and change all the references to be readX and writeX? I'm wary of Ok so these are not addresses but magic registers in the processor ? Then I guess volatile makes complete sense. Similarly spin_lock/unlock are store barriers so for ring buffers should be sufficient unless you have cache management requirements in which case the dma_* APIs will handle those bits. I don't actually need locks, but sticking smp_rmb()/smp_wmb() is probably the right thing to do now that I know how to use them. This code was written five or six years ago and I haven't really thought about changing that since. I don't see how the dma_* APIs would help. The buffer is filled by a higher priority interrupt routine that does 'virtual DMA'. It's not actually done by real DMA. Normal interrupt disablement doesn't really disable interrupts, it justs excludes normal priority interrupts. For real DMA the dma_ APIs keep coherency The virtual DMA is done is ASM as it has to be really quick. It's unfortunate, but, the on-chip serial ports don't have a FIFO. For PIO (virtual DMA or otherwise) the locking does that. Because spin_unlock and spin_lock are compiler barriers the need to use volatile shouldn't normally be there. If you are doing it via asm without locks then I would expect atomic_t because the sematics of volatile are horribly vague on their own ? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
Alan Cox [EMAIL PROTECTED] wrote: Ok so these are not addresses but magic registers in the processor ? Then I guess volatile makes complete sense. They are such magic registers, though of various grades. Some are part of the CPU core and affect things like CPU core itself, CPU caches, MMU/TLB and exceptions/interrupts. Others are on-silicon devices such as the serial ports, the bus controller, the SDRAM controller. For PIO (virtual DMA or otherwise) the locking does that. Because spin_unlock and spin_lock are compiler barriers the need to use volatile shouldn't normally be there. If you are doing it via asm without locks then I would expect atomic_t because the sematics of volatile are horribly vague on their own ? Using memory barriers ought to be good enough for the ring buffer. There aren't actually any atomic ops available other than bit-set and bit-clear. David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
Some are part of the CPU core and affect things like CPU core itself, CPU caches, MMU/TLB and exceptions/interrupts. Others are on-silicon devices such as the serial ports, the bus controller, the SDRAM controller. How are they addressed - as CPU registers or as memory/IO space ? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
On Sat, Nov 10, 2007 at 11:43:20AM -0800, Andrew Morton wrote: On Sat, 10 Nov 2007 12:18:50 + David Howells [EMAIL PROTECTED] wrote: ... has a couple of examples on it's front page. If you work through the menus of modern Panasonic tellies, you might find a URL pointing somewhere on this website that isn't reachable by linking from the index page of the website. I don't know who else uses this CPU, but it's possible MEI sell them to other companies. If it is indeed the case that this architecture is used internally by a single organisation then perhaps it doesn't make sense for us to merge it. One of the main reasons we put code into the kernel is as a means of distribution: to get it into the hands of people who need it. But in this situation there is no advantage to *anyone* from this merge apart from MEI. IOW, the submitter gains and everyone else loses. It's a curious situation. ... You miss the point that we want people to be able to use Linux in such situations. There are basically two choices: - Either tell them code won't get merged and offer some degree of API stability in exchange or - allow all code with = 1 users to enter the kernel. [1] With the current development model (and the mere amount of changes merged), the first choice is not possible. The only reason for not merging it [1] would be if it would be unmaintained and bitrot, but considering that David is already doing a good job at maintaining the frv port that's not an issue here. cu Adrian [1] assuming the code itself is considered OK -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
> The vast majority of which are either memory-mapped hardware registers or > interrupt-routine-filled ring buffers. memory mapped registers should be read with readw and friends and that should contain the volatile not the public code. Similarly spin_lock/unlock are store barriers so for ring buffers should be sufficient unless you have cache management requirements in which case the dma_* APIs will handle those bits. Knocking these sort of things on the head does want doing, we are still having to clean up ancient drivers/platforms that don't do this and frequently break as a result. > | WARNING: do not add new typedefs > | #27265: FILE: include/asm-mn10300/types.h:30: > | +typedef unsigned int __u32; > > Pah! Send bugs to the maintainer. You've triggered a new case - adding an arch and it gets the wrong idea. > > | #29191: FILE: include/asm-mn10300/user.h:50: > | +#define HOST_TEXT_START_ADDR +(u.start_code) > | ^ > | > | ERROR: need consistent spacing around '+' (ctx:WxV) > > Doesn't checkpatch know a unary plus when it sees one? No - its rather dumb on rule handling and will need a rewrite someday to handle typedefs as well. > #1269: FILE: arch/mn10300/boot/compressed/head.S:38: > > Should be: > > arch/mn10300/boot/compressed/head.S:38: > > Yes, I know there's a --emacs flag, but that only affects references into the > patch, not references into the files the patch refers to. Send patches... Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
> If it is indeed the case that this architecture is used internally by a > single organisation then perhaps it doesn't make sense for us to merge it. Disagree, as does history. We merged the AP1000 ... > distribution: to get it into the hands of people who need it. But in this > situation there is no advantage to *anyone* from this merge apart from MEI. Or anyone who wants to hack an MEI device. If just three people do then it beats voyager ;) Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
On Sat, 10 Nov 2007 12:18:50 + David Howells <[EMAIL PROTECTED]> wrote: > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > ho hum, I've seen worse-looking code ;). There's quite a bit of the usual > > stuff in there: use of SPIN_LOCK_UNLOCKED, a forest of fishy-looking > > volatiles > > The vast majority of which are either memory-mapped hardware registers or > interrupt-routine-filled ring buffers. So? Those are very common things and most drivers don't resort to `volatile' to access them. > > but I don't need to sit here and emulate checkpatch.pl. > > No, it should be deleted: > > shred -fu scripts/checkpatch.pl > > will do the trick quite nicely. checkpatch is quite accurate now - Ingo has been following this quite carefully. If you were to use it there would be improvements in the exceptionally high number of mistakes in your patches. > | WARNING: do not add new typedefs > | #27265: FILE: include/asm-mn10300/types.h:30: > | +typedef unsigned int __u32; > > Pah! Bug reports against checkpath should be sent to apw, not used as an excuse to put incorrectly laid-out code into the kernel and for increasing my workload. > > I googled a bit but most of the mn10300 info pertains to linux kernel and > > gcc. Who is using this CPU and in what applications? > > This CPU is MEI/Matsushita/Panasonic's own CPU. If you've bought a Panasonic > telly, say, in the last few years, the odds are rather good that it's got one > of these CPUs in it running Linux. How did you know I had a Panasonic flat screen? ;) > http://www.am-linux.jp/ > > has a couple of examples on it's front page. If you work through the menus of > modern Panasonic tellies, you might find a URL pointing somewhere on this > website that isn't reachable by linking from the index page of the website. > > I don't know who else uses this CPU, but it's possible MEI sell them to other > companies. > If it is indeed the case that this architecture is used internally by a single organisation then perhaps it doesn't make sense for us to merge it. One of the main reasons we put code into the kernel is as a means of distribution: to get it into the hands of people who need it. But in this situation there is no advantage to *anyone* from this merge apart from MEI. IOW, the submitter gains and everyone else loses. It's a curious situation. I guess if it were possible to install a self-built kernel into a Panasonic gadget then we could look at it on that basis. Do you know if that's the case? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
Andrew Morton <[EMAIL PROTECTED]> wrote: > ho hum, I've seen worse-looking code ;). There's quite a bit of the usual > stuff in there: use of SPIN_LOCK_UNLOCKED, a forest of fishy-looking > volatiles The vast majority of which are either memory-mapped hardware registers or interrupt-routine-filled ring buffers. > but I don't need to sit here and emulate checkpatch.pl. No, it should be deleted: shred -fu scripts/checkpatch.pl will do the trick quite nicely. | WARNING: do not add new typedefs | #27265: FILE: include/asm-mn10300/types.h:30: | +typedef unsigned int __u32; Pah! | #29191: FILE: include/asm-mn10300/user.h:50: | +#define HOST_TEXT_START_ADDR +(u.start_code) | ^ | | ERROR: need consistent spacing around '+' (ctx:WxV) Doesn't checkpatch know a unary plus when it sees one? In this particular case this is so this macro can be used in assembly without causing problems there. Without the plus, the assembler thinks it has to treat the (xxx) as a memory access, with the plus it thinks +(xxx) is an immediate operand. Unfortunately, whoever set up MN10300 assembly didn't include an immediate-operand marker. Furthermore, the program also puts out the line references for its error messages in a non-standard format, thus preventing things like emacs's compilation mode from being able to step through them. #1269: FILE: arch/mn10300/boot/compressed/head.S:38: Should be: arch/mn10300/boot/compressed/head.S:38: Yes, I know there's a --emacs flag, but that only affects references into the patch, not references into the files the patch refers to. > I googled a bit but most of the mn10300 info pertains to linux kernel and > gcc. Who is using this CPU and in what applications? This CPU is MEI/Matsushita/Panasonic's own CPU. If you've bought a Panasonic telly, say, in the last few years, the odds are rather good that it's got one of these CPUs in it running Linux. http://www.am-linux.jp/ has a couple of examples on it's front page. If you work through the menus of modern Panasonic tellies, you might find a URL pointing somewhere on this website that isn't reachable by linking from the index page of the website. I don't know who else uses this CPU, but it's possible MEI sell them to other companies. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
Andrew Morton [EMAIL PROTECTED] wrote: ho hum, I've seen worse-looking code ;). There's quite a bit of the usual stuff in there: use of SPIN_LOCK_UNLOCKED, a forest of fishy-looking volatiles The vast majority of which are either memory-mapped hardware registers or interrupt-routine-filled ring buffers. but I don't need to sit here and emulate checkpatch.pl. No, it should be deleted: shred -fu scripts/checkpatch.pl will do the trick quite nicely. | WARNING: do not add new typedefs | #27265: FILE: include/asm-mn10300/types.h:30: | +typedef unsigned int __u32; Pah! | #29191: FILE: include/asm-mn10300/user.h:50: | +#define HOST_TEXT_START_ADDR +(u.start_code) | ^ | | ERROR: need consistent spacing around '+' (ctx:WxV) Doesn't checkpatch know a unary plus when it sees one? In this particular case this is so this macro can be used in assembly without causing problems there. Without the plus, the assembler thinks it has to treat the (xxx) as a memory access, with the plus it thinks +(xxx) is an immediate operand. Unfortunately, whoever set up MN10300 assembly didn't include an immediate-operand marker. Furthermore, the program also puts out the line references for its error messages in a non-standard format, thus preventing things like emacs's compilation mode from being able to step through them. #1269: FILE: arch/mn10300/boot/compressed/head.S:38: Should be: arch/mn10300/boot/compressed/head.S:38: Yes, I know there's a --emacs flag, but that only affects references into the patch, not references into the files the patch refers to. I googled a bit but most of the mn10300 info pertains to linux kernel and gcc. Who is using this CPU and in what applications? This CPU is MEI/Matsushita/Panasonic's own CPU. If you've bought a Panasonic telly, say, in the last few years, the odds are rather good that it's got one of these CPUs in it running Linux. http://www.am-linux.jp/ has a couple of examples on it's front page. If you work through the menus of modern Panasonic tellies, you might find a URL pointing somewhere on this website that isn't reachable by linking from the index page of the website. I don't know who else uses this CPU, but it's possible MEI sell them to other companies. David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
On Sat, 10 Nov 2007 12:18:50 + David Howells [EMAIL PROTECTED] wrote: Andrew Morton [EMAIL PROTECTED] wrote: ho hum, I've seen worse-looking code ;). There's quite a bit of the usual stuff in there: use of SPIN_LOCK_UNLOCKED, a forest of fishy-looking volatiles The vast majority of which are either memory-mapped hardware registers or interrupt-routine-filled ring buffers. So? Those are very common things and most drivers don't resort to `volatile' to access them. but I don't need to sit here and emulate checkpatch.pl. No, it should be deleted: shred -fu scripts/checkpatch.pl will do the trick quite nicely. checkpatch is quite accurate now - Ingo has been following this quite carefully. If you were to use it there would be improvements in the exceptionally high number of mistakes in your patches. | WARNING: do not add new typedefs | #27265: FILE: include/asm-mn10300/types.h:30: | +typedef unsigned int __u32; Pah! Bug reports against checkpath should be sent to apw, not used as an excuse to put incorrectly laid-out code into the kernel and for increasing my workload. I googled a bit but most of the mn10300 info pertains to linux kernel and gcc. Who is using this CPU and in what applications? This CPU is MEI/Matsushita/Panasonic's own CPU. If you've bought a Panasonic telly, say, in the last few years, the odds are rather good that it's got one of these CPUs in it running Linux. How did you know I had a Panasonic flat screen? ;) http://www.am-linux.jp/ has a couple of examples on it's front page. If you work through the menus of modern Panasonic tellies, you might find a URL pointing somewhere on this website that isn't reachable by linking from the index page of the website. I don't know who else uses this CPU, but it's possible MEI sell them to other companies. If it is indeed the case that this architecture is used internally by a single organisation then perhaps it doesn't make sense for us to merge it. One of the main reasons we put code into the kernel is as a means of distribution: to get it into the hands of people who need it. But in this situation there is no advantage to *anyone* from this merge apart from MEI. IOW, the submitter gains and everyone else loses. It's a curious situation. I guess if it were possible to install a self-built kernel into a Panasonic gadget then we could look at it on that basis. Do you know if that's the case? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
If it is indeed the case that this architecture is used internally by a single organisation then perhaps it doesn't make sense for us to merge it. Disagree, as does history. We merged the AP1000 ... distribution: to get it into the hands of people who need it. But in this situation there is no advantage to *anyone* from this merge apart from MEI. Or anyone who wants to hack an MEI device. If just three people do then it beats voyager ;) Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
The vast majority of which are either memory-mapped hardware registers or interrupt-routine-filled ring buffers. memory mapped registers should be read with readw and friends and that should contain the volatile not the public code. Similarly spin_lock/unlock are store barriers so for ring buffers should be sufficient unless you have cache management requirements in which case the dma_* APIs will handle those bits. Knocking these sort of things on the head does want doing, we are still having to clean up ancient drivers/platforms that don't do this and frequently break as a result. | WARNING: do not add new typedefs | #27265: FILE: include/asm-mn10300/types.h:30: | +typedef unsigned int __u32; Pah! Send bugs to the maintainer. You've triggered a new case - adding an arch and it gets the wrong idea. | #29191: FILE: include/asm-mn10300/user.h:50: | +#define HOST_TEXT_START_ADDR +(u.start_code) | ^ | | ERROR: need consistent spacing around '+' (ctx:WxV) Doesn't checkpatch know a unary plus when it sees one? No - its rather dumb on rule handling and will need a rewrite someday to handle typedefs as well. #1269: FILE: arch/mn10300/boot/compressed/head.S:38: Should be: arch/mn10300/boot/compressed/head.S:38: Yes, I know there's a --emacs flag, but that only affects references into the patch, not references into the files the patch refers to. Send patches... Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
On Fri, 09 Nov 2007 15:34:58 + David Howells <[EMAIL PROTECTED]> wrote: > Add architecture support for the MN10300/AM33 CPUs produced by MEI to the > kernel. hm, kprobes and gdb support. ho hum, I've seen worse-looking code ;). There's quite a bit of the usual stuff in there: use of SPIN_LOCK_UNLOCKED, a forest of fishy-looking volatiles, but I don't need to sit here and emulate checkpatch.pl. I googled a bit but most of the mn10300 info pertains to linux kernel and gcc. Who is using this CPU and in what applications? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
On Fri, 09 Nov 2007 15:34:58 + David Howells [EMAIL PROTECTED] wrote: Add architecture support for the MN10300/AM33 CPUs produced by MEI to the kernel. hm, kprobes and gdb support. ho hum, I've seen worse-looking code ;). There's quite a bit of the usual stuff in there: use of SPIN_LOCK_UNLOCKED, a forest of fishy-looking volatiles, but I don't need to sit here and emulate checkpatch.pl. I googled a bit but most of the mn10300 info pertains to linux kernel and gcc. Who is using this CPU and in what applications? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
