* Re: [RFC/PATCH 4/7] Powerpc MSI implementation
From: Benjamin Herrenschmidt @ 2006-11-08 2:08 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Matthew Wilcox, Greg Kroah-Hartman, Ingo Molnar, Russell King,
linuxppc-dev, Thomas Gleixner, linux-pci, David S.Miller
In-Reply-To: <m1ac327mer.fsf@ebiederm.dsl.xmission.com>
On Tue, 2006-11-07 at 18:33 -0700, Eric W. Biederman wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> >> For message signalled interrupts and hyptertransport interrupts we probably
> > want
> >> to add an additional field for pointing to their per irq state. Per device
> >> interrupt controllers are truly peculiar.
> >
> > A per-irq addition field for the MSI data might indeed be useful. I
> > still want to store it in the pci_dev, but it would be good to have a
> > pointer to it in the irq_desc.
>
> The msi_info in pci_dev is reasonable. But storing all 4096 possible
> msi_desc's in pci_dev seems a little much.
My initial idea was that the msi_info structure would have a variable
lenght, that is, would end with msi_desc[0] and would be allocated to
the the right size, but it might suck a bit :-)
> Hopefully I can look at this a little more this evening and see what we
> need to do to harmonize the two msi implementations.
Thanks !
Ben.
^ permalink raw reply
* Re: [PATCH] PowerPC: clockevents and HRT support
From: Benjamin Herrenschmidt @ 2006-11-08 2:06 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, tglx, greg.weeks
In-Reply-To: <20061108011930.GA18955@mag.az.mvista.com>
On Tue, 2006-11-07 at 18:19 -0700, Mark A. Greer wrote:
> On Wed, Nov 08, 2006 at 11:18:51AM +1100, Benjamin Herrenschmidt wrote:
> >
> > > Whatever. I don't care about that feature. I did my best to solve this
> > > gracefully.
> >
> > Very typical of Montavista to not care about doing the right thing.
> >
> > Ben
>
> Hmmm...
Yeah, ok, maybe not -everybody- there :-)
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: force 4k update_flash block and list sizes
From: Michael Neuling @ 2006-11-08 2:06 UTC (permalink / raw)
To: John Rose; +Cc: External List, Paul Mackerras
In-Reply-To: <1162943615.13499.15.camel@sinatra.austin.ibm.com>
> +
> + if (flash_block_cache) {
> + rc = kmem_cache_destroy(flash_block_cache);
> + if (rc)
> + printk(KERN_WARNING "%s: cache memory leak\n",
> + __FUNCTION__);
> + }
kmem_cache_destroy doesn't return anything. Hence we get:
arch/powerpc/kernel/rtas_flash.c: In function 'rtas_flash_cleanup':
arch/powerpc/kernel/rtas_flash.c:835: error: void value not ignored as it ought to be
Mikey
^ permalink raw reply
* Re: [PATCH] PowerPC: clockevents and HRT support
From: Paul Mackerras @ 2006-11-08 2:00 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: tglx, greg.weeks, linuxppc-dev
In-Reply-To: <45510C58.3010707@ru.mvista.com>
Sergei Shtylyov writes:
> Arch-specific accounting hooks which this feature makes use of can't be
> called from the generic clockevents code.
Which hooks specifically?
The deterministic accounting is an essential feature; there's no way
I'll accept a patch which disables it.
Paul.
^ permalink raw reply
* mpc7448hpc2 u-boot
From: Zang Roy-r61911 @ 2006-11-08 1:53 UTC (permalink / raw)
To: linuxppc-dev list
The mpc7448hpc2 board u-boot is available at:
http://opensource.freescale.com/git?p=u-boot-7448hpc2.git;a=summary
It can be cloned by
git clone http://opensource.freescale.com/pub/scm/u-boot-7448hpc2.git
The current u-boot supports the mpc7448hpc2 board in arch/powerpc in kernel.
I hope the board user can be benefit from it :-).
Cheers.
Roy
^ permalink raw reply
* why need disable icache
From: Jackson @ 2006-11-08 1:51 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 213 bytes --]
Hi, all
I have been confused by cache recently.
1. why need we disable icache and dcache at the beginning of the u-boot code?
2. when can we enable them ?
Thank you for the help.
Best regards
Jackson
[-- Attachment #2: Type: text/html, Size: 826 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH 4/7] Powerpc MSI implementation
From: Eric W. Biederman @ 2006-11-08 1:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Matthew Wilcox, Greg Kroah-Hartman, Ingo Molnar, Russell King,
linuxppc-dev, Thomas Gleixner, linux-pci, David S.Miller
In-Reply-To: <1162944905.28571.551.camel@localhost.localdomain>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>> For message signalled interrupts and hyptertransport interrupts we probably
> want
>> to add an additional field for pointing to their per irq state. Per device
>> interrupt controllers are truly peculiar.
>
> A per-irq addition field for the MSI data might indeed be useful. I
> still want to store it in the pci_dev, but it would be good to have a
> pointer to it in the irq_desc.
The msi_info in pci_dev is reasonable. But storing all 4096 possible
msi_desc's in pci_dev seems a little much.
Hopefully I can look at this a little more this evening and see what we
need to do to harmonize the two msi implementations.
Eric
^ permalink raw reply
* Re: [PATCH] PowerPC: clockevents and HRT support
From: Mark A. Greer @ 2006-11-08 1:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, tglx, greg.weeks
In-Reply-To: <1162945131.28571.553.camel@localhost.localdomain>
On Wed, Nov 08, 2006 at 11:18:51AM +1100, Benjamin Herrenschmidt wrote:
>
> > Whatever. I don't care about that feature. I did my best to solve this
> > gracefully.
>
> Very typical of Montavista to not care about doing the right thing.
>
> Ben
Hmmm...
^ permalink raw reply
* IDMA on MPC82xx
From: john ke @ 2006-11-08 0:53 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 987 bytes --]
Any one who has any experience when using IDMA on mpc82xx?
Currently, the status what I have got is, memory-to-memory mode, both Data bus had been set to 60x-bus,which means DDTB and SDTB are working on 60x-bus. if set DMA_WRAP in DCM as 64-byte, SS_MAX,STS and DTS in (IDMA Parameter RAM) all to 32 Bytes, there woking good!
But if set DMA_WRAP more than 64-byte(i.e 256-bytes) ,SS_MAX,STS and DTS in (IDMA Parameter RAM) all to 7*32 Bytes when WRAP = 256 . then got some issues:
1.some bytes in a packet had been changed oddly. for example if some bytes in the packet is "20 0f 17 2c...." after
IDMA transmission , the bytes will be changed as "20 1d 17 2c", there is a slightly different with "17" and "1d".
2. some bytes had been swapped , for example "20 0f 17 2c" , after transmission , the bytes in packet was "2c 17 0f 20".
any ideas?
---------------------------------
Sponsored Link
Try Netflix today! With plans starting at only $5.99 a month what are you waiting for?
[-- Attachment #2: Type: text/html, Size: 1080 bytes --]
^ permalink raw reply
* Re: build problems with powerpc allmodconfig
From: Stephen Rothwell @ 2006-11-08 0:58 UTC (permalink / raw)
To: Judith Lebzelter; +Cc: linuxppc-dev
In-Reply-To: <20061107180937.GB1339@shell0.pdx.osdl.net>
[-- Attachment #1: Type: text/plain, Size: 402 bytes --]
On Tue, 7 Nov 2006 10:09:37 -0800 Judith Lebzelter <judith@osdl.org> wrote:
>
> How about just adding an 'ifndef' in the Makefile, as in the patch below?
> This compiles ibmvscsic.o fine.
Looks good. Please resend with a comment (both for the commit and in the
Makefile) and a Signed-off-by line.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] PowerPC: clockevents and HRT support
From: Benjamin Herrenschmidt @ 2006-11-08 0:18 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, tglx, greg.weeks
In-Reply-To: <455114F9.2010503@ru.mvista.com>
> Whatever. I don't care about that feature. I did my best to solve this
> gracefully.
Very typical of Montavista to not care about doing the right thing.
Ben
^ permalink raw reply
* Re: [RFC/PATCH 4/7] Powerpc MSI implementation
From: Benjamin Herrenschmidt @ 2006-11-08 0:15 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Matthew Wilcox, Greg Kroah-Hartman, Ingo Molnar, Russell King,
linuxppc-dev, Thomas Gleixner, linux-pci, David S.Miller
In-Reply-To: <m1mz727syy.fsf@ebiederm.dsl.xmission.com>
> For message signalled interrupts and hyptertransport interrupts we probably want
> to add an additional field for pointing to their per irq state. Per device
> interrupt controllers are truly peculiar.
A per-irq addition field for the MSI data might indeed be useful. I
still want to store it in the pci_dev, but it would be good to have a
pointer to it in the irq_desc.
Ben.
^ permalink raw reply
* 2.6.18 fails in call_usermodedata() on 8xx
From: Robin Gilks @ 2006-11-08 0:14 UTC (permalink / raw)
To: ppc embedded list
Greetings
Having (sort of) mastered the bdi2000, I'm trying to bring up a 8xx card
thats been debugged and working with a 2.4 kernel for the last 3 years
but is failing miserably on a 2.6.18 kernel.
My initial problems in dma_alloc_init I seem to have fixed by moving
CONFIG_CONSISTENT_START to 0xa0000000 from the default of 0xff100000 but
now I'm failing in call_usermodedata(). Any attempt to check the values
of structures (eg. current->fs->root) results in an error of the form:
(gdb) print *current
Cannot access memory at address 0xc01e27a8
so I'm a bit stuck with further debugging.
Is there anything I should be looking out for in particular with an 8xx
CPU and a late 2.6 kernel? My understanding was that it now worked but
the config documentation is a bit thin on the ground :-(
Cheers
--
Robin
=======================================================================
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================
^ permalink raw reply
* [PATCH] powerpc: force 4k update_flash block and list sizes
From: John Rose @ 2006-11-07 23:53 UTC (permalink / raw)
To: External List; +Cc: Paul Mackerras
The enablement of 64k pages on POWER platforms exposed a quirk in the RTAS
mechanism for updating firmware. RTAS assumes 4k for flash block and list
sizes, and use of any other sizes results in a failure.
This patch changes the rtas_flash module to force the use of 4k memory block
and list sizes when preparing and sending a firmware image to RTAS. It also
changes rtas_flash to use a slab cache to ensure 4k alignment of flash block
data. Such alignment is a documented requirement.
Signed-off-by: John Rose <johnrose@austin.ibm.com>
___
Intended for inclusion for 2.6.20, if appropriate. Thanks!
John
---
uf_4k-johnrose/arch/powerpc/kernel/rtas_flash.c | 52 +++++++++++++++++++-----
1 files changed, 42 insertions(+), 10 deletions(-)
diff -puN arch/powerpc/kernel/rtas_flash.c~uf_4k_alt2 arch/powerpc/kernel/rtas_flash.c
--- uf_4k/arch/powerpc/kernel/rtas_flash.c~uf_4k_alt2 2006-11-06 16:59:27.000000000 -0600
+++ uf_4k-johnrose/arch/powerpc/kernel/rtas_flash.c 2006-11-06 17:02:31.000000000 -0600
@@ -72,6 +72,10 @@
#define VALIDATE_BUF_SIZE 4096
#define RTAS_MSG_MAXLEN 64
+/* Quirk - RTAS requires 4k list length and block size */
+#define RTAS_BLKLIST_LENGTH 4096
+#define RTAS_BLK_SIZE 4096
+
struct flash_block {
char *data;
unsigned long length;
@@ -83,7 +87,7 @@ struct flash_block {
* into a version/length and translate the pointers
* to absolute.
*/
-#define FLASH_BLOCKS_PER_NODE ((PAGE_SIZE - 16) / sizeof(struct flash_block))
+#define FLASH_BLOCKS_PER_NODE ((RTAS_BLKLIST_LENGTH - 16) / sizeof(struct flash_block))
struct flash_block_list {
unsigned long num_blocks;
struct flash_block_list *next;
@@ -96,6 +100,9 @@ struct flash_block_list_header { /* just
static struct flash_block_list_header rtas_firmware_flash_list = {0, NULL};
+/* Use slab cache to guarantee 4k alignment */
+static kmem_cache_t *flash_block_cache = NULL;
+
#define FLASH_BLOCK_LIST_VERSION (1UL)
/* Local copy of the flash block list.
@@ -153,7 +160,7 @@ static int flash_list_valid(struct flash
return FLASH_IMG_NULL_DATA;
}
block_size = f->blocks[i].length;
- if (block_size <= 0 || block_size > PAGE_SIZE) {
+ if (block_size <= 0 || block_size > RTAS_BLK_SIZE) {
return FLASH_IMG_BAD_LEN;
}
image_size += block_size;
@@ -177,9 +184,9 @@ static void free_flash_list(struct flash
while (f) {
for (i = 0; i < f->num_blocks; i++)
- free_page((unsigned long)(f->blocks[i].data));
+ kmem_cache_free(flash_block_cache, f->blocks[i].data);
next = f->next;
- free_page((unsigned long)f);
+ kmem_cache_free(flash_block_cache, f);
f = next;
}
}
@@ -278,6 +285,12 @@ static ssize_t rtas_flash_read(struct fi
return msglen;
}
+/* constructor for flash_block_cache */
+void rtas_block_ctor(void *ptr, kmem_cache_t *cache, unsigned long flags)
+{
+ memset(ptr, 0, RTAS_BLK_SIZE);
+}
+
/* We could be much more efficient here. But to keep this function
* simple we allocate a page to the block list no matter how small the
* count is. If the system is low on memory it will be just as well
@@ -302,7 +315,7 @@ static ssize_t rtas_flash_write(struct f
* proc file
*/
if (uf->flist == NULL) {
- uf->flist = (struct flash_block_list *) get_zeroed_page(GFP_KERNEL);
+ uf->flist = kmem_cache_alloc(flash_block_cache, GFP_KERNEL);
if (!uf->flist)
return -ENOMEM;
}
@@ -313,21 +326,21 @@ static ssize_t rtas_flash_write(struct f
next_free = fl->num_blocks;
if (next_free == FLASH_BLOCKS_PER_NODE) {
/* Need to allocate another block_list */
- fl->next = (struct flash_block_list *)get_zeroed_page(GFP_KERNEL);
+ fl->next = kmem_cache_alloc(flash_block_cache, GFP_KERNEL);
if (!fl->next)
return -ENOMEM;
fl = fl->next;
next_free = 0;
}
- if (count > PAGE_SIZE)
- count = PAGE_SIZE;
- p = (char *)get_zeroed_page(GFP_KERNEL);
+ if (count > RTAS_BLK_SIZE)
+ count = RTAS_BLK_SIZE;
+ p = kmem_cache_alloc(flash_block_cache, GFP_KERNEL);
if (!p)
return -ENOMEM;
if(copy_from_user(p, buffer, count)) {
- free_page((unsigned long)p);
+ kmem_cache_free(flash_block_cache, p);
return -EFAULT;
}
fl->blocks[next_free].data = p;
@@ -791,6 +804,16 @@ int __init rtas_flash_init(void)
goto cleanup;
rtas_flash_term_hook = rtas_flash_firmware;
+
+ flash_block_cache = kmem_cache_create("rtas_flash_cache",
+ RTAS_BLK_SIZE, RTAS_BLK_SIZE, 0,
+ rtas_block_ctor, NULL);
+ if (!flash_block_cache) {
+ printk(KERN_ERR "%s: failed to create block cache\n",
+ __FUNCTION__);
+ rc = -ENOMEM;
+ goto cleanup;
+ }
return 0;
cleanup:
@@ -804,7 +827,16 @@ cleanup:
void __exit rtas_flash_cleanup(void)
{
+ int rc;
+
rtas_flash_term_hook = NULL;
+
+ if (flash_block_cache) {
+ rc = kmem_cache_destroy(flash_block_cache);
+ if (rc)
+ printk(KERN_WARNING "%s: cache memory leak\n",
+ __FUNCTION__);
+ }
remove_flash_pde(firmware_flash_pde);
remove_flash_pde(firmware_update_pde);
remove_flash_pde(validate_pde);
_
^ permalink raw reply
* Re: ethernet interface problem with kernel 2.6.14 on MPC8343E
From: Luong Ngo @ 2006-11-07 23:30 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-embedded
In-Reply-To: <2E3AE2D7-49C3-40BB-B939-7FE821EA8C2A@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]
Hi,
It is working now. Thanks for the help. I am just curious that linux kernel
does not know 1 interface's connection is down and check the other interface
to see if it can reaches the destination with other interfaces?
Thanks,
l.ngo
On 11/7/06, Andy Fleming <afleming@freescale.com> wrote:
>
>
> On Nov 6, 2006, at 17:51, Luong Ngo wrote:
>
> > Hello,
> >
> > I am having a problem with the interfaces eth0 and eth1 when
> > running 2.6.14 kernel on a board with MPC8343E. The problem I
> > encounters is only one of the eth interface is really working. Only
> > the one that is configured first, using "ifconfig eth[0/1]
> > 192.168.1.1 netmask 255.255.255.0" can ping and be pinged from
> > another host. I wonder if there is setup difference between the
> > TSEC1 and TSEC2 or this is not related to hardware but rather
> > something in the kernel. When I ping from other host, from within
> > the Gianfar driver, I can see the packet is received on both
> > interfaces but only one responds. When pinging from the system
> > itself, only the working interface sending out packet, the other
> > interface does not send anything. Please advise me what I am doing
> > wrong or missing.
> >
>
> It sounds like both work for you, but not at the same time?
>
> If you set them both to the same IP address, it won't work.
> Actually, it won't work if you set them to different IP addresses on
> the same subnet (as defined by their netmasks).
>
> I think you are trying to get Linux to do something that it doesn't
> do. Try setting them to different IP addresses, like 192.168.1.1 and
> 192.168.2.1
>
> Andy
>
[-- Attachment #2: Type: text/html, Size: 2149 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH 4/7] Powerpc MSI implementation
From: Eric W. Biederman @ 2006-11-07 23:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Matthew Wilcox, Greg Kroah-Hartman, Ingo Molnar, Russell King,
linuxppc-dev, Thomas Gleixner, linux-pci, David S.Miller
In-Reply-To: <1162938562.28571.531.camel@localhost.localdomain>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>> I guess we'll just have to add __force casts all over the code. ;(
>
> Or just do it in a single accessor function/macro...
Or treat struct irq_desc like struct page and have a members that
depend on features that you enable or disable depending on the architecture
dependent tradeoffs.
We already have a few members depend on things like SMP.
With the cache line alignment of each array entry we take up a fair amount of
space, so we don't have to micro optimize just do a decent job of not having
anything to terrible.
For message signalled interrupts and hyptertransport interrupts we probably want
to add an additional field for pointing to their per irq state. Per device
interrupt controllers are truly peculiar.
Eric
^ permalink raw reply
* [PATCH] Do a single one-line printk in bad_page_fault()
From: Michael Ellerman @ 2006-11-07 23:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
bad_page_fault() prints a message telling the user what type of bad
fault we took. The first line of this message is currently implemented
as two separate printks. This has the unfortunate effect that if
several cpus simultaneously take a bad fault, the first and second parts
of the printk get jumbled up, which looks dodge and is hard to read.
So do a single one-line printk for each fault type.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/mm/fault.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
Index: to-merge/arch/powerpc/mm/fault.c
===================================================================
--- to-merge.orig/arch/powerpc/mm/fault.c
+++ to-merge/arch/powerpc/mm/fault.c
@@ -426,18 +426,21 @@ void bad_page_fault(struct pt_regs *regs
/* kernel has accessed a bad area */
- printk(KERN_ALERT "Unable to handle kernel paging request for ");
switch (regs->trap) {
- case 0x300:
- case 0x380:
- printk("data at address 0x%08lx\n", regs->dar);
- break;
- case 0x400:
- case 0x480:
- printk("instruction fetch\n");
- break;
- default:
- printk("unknown fault\n");
+ case 0x300:
+ case 0x380:
+ printk(KERN_ALERT "Unable to handle kernel paging request for "
+ "data at address 0x%08lx\n", regs->dar);
+ break;
+ case 0x400:
+ case 0x480:
+ printk(KERN_ALERT "Unable to handle kernel paging request for "
+ "instruction fetch\n");
+ break;
+ default:
+ printk(KERN_ALERT "Unable to handle kernel paging request for "
+ "unknown fault\n");
+ break;
}
printk(KERN_ALERT "Faulting instruction address: 0x%08lx\n",
regs->nip);
^ permalink raw reply
* Re: [PATCH] PowerPC: clockevents and HRT support
From: Sergei Shtylyov @ 2006-11-07 23:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, tglx, greg.weeks
In-Reply-To: <1162940684.28571.537.camel@localhost.localdomain>
Hello.
Benjamin Herrenschmidt wrote:
>> That's not equivalent. What I wanted to cover with this option was 970
>>weirdness of the decrementer interrupts being level triggered and effectively
>>tied to the MSB of the decremeneter register...
>> Also, 40x decrementer is not Book E compatible.
> Well... Is this specific to the 970 or also happens on all
> POWER4..5..6 ? (I don't remember off the top of my head). It should
> probably be a runtime check then.
I don't have the docs on POWER[456], so can't say anything.
>>>Also, what's the problem with ppc64 deterministic accounting that you
>>>can't fix it ?
>> Arch-specific accounting hooks which this feature makes use of can't be
>>called from the generic clockevents code.
> Then the generic clockevent code will have to be fixed or powerpc not
> ported to it.
Whatever. I don't care about that feature. I did my best to solve this
gracefully.
> Ben.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] PowerPC: clockevents and HRT support
From: Benjamin Herrenschmidt @ 2006-11-07 23:04 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, tglx, greg.weeks
In-Reply-To: <45510C58.3010707@ru.mvista.com>
> That's not equivalent. What I wanted to cover with this option was 970
> weirdness of the decrementer interrupts being level triggered and effectively
> tied to the MSB of the decremeneter register...
> Also, 40x decrementer is not Book E compatible.
Well... Is this specific to the 970 or also happens on all
POWER4..5..6 ? (I don't remember off the top of my head). It should
probably be a runtime check then.
> > Also, what's the problem with ppc64 deterministic accounting that you
> > can't fix it ?
>
> Arch-specific accounting hooks which this feature makes use of can't be
> called from the generic clockevents code.
Then the generic clockevent code will have to be fixed or powerpc not
ported to it.
Ben.
^ permalink raw reply
* [PATCH] of_irq_to_resource now returns the virq
From: Andy Fleming @ 2006-11-07 22:57 UTC (permalink / raw)
To: linuxppc-dev, Paul Mackerras, Benjamin Herrenschmidt
Mostly this is to allow for error checking (check the return for NO_IRQ)
Added a check that the resource is non-NULL, too
Signed-off-by: Andrew Fleming <afleming@freescale.com>
---
include/asm-powerpc/prom.h | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/include/asm-powerpc/prom.h b/include/asm-powerpc/prom.h
index 933ba27..0afee17 100644
--- a/include/asm-powerpc/prom.h
+++ b/include/asm-powerpc/prom.h
@@ -334,10 +334,18 @@ extern int of_irq_map_one(struct device_
struct pci_dev;
extern int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq);
-static inline void of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
+static inline int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
{
- r->start = r->end = irq_of_parse_and_map(dev, index);
- r->flags = IORESOURCE_IRQ;
+ int irq = irq_of_parse_and_map(dev, index);
+
+ /* Only dereference the resource if both the
+ * resource and the irq are valid. */
+ if (r && irq != NO_IRQ) {
+ r->start = r->end = irq;
+ r->flags = IORESOURCE_IRQ;
+ }
+
+ return irq;
}
--
1.4.2.3
^ permalink raw reply related
* Re: [PATCH] PowerPC: clockevents and HRT support
From: Sergei Shtylyov @ 2006-11-07 22:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, tglx, greg.weeks
In-Reply-To: <1162938997.28571.534.camel@localhost.localdomain>
Hello.
Benjamin Herrenschmidt wrote:
>>+#ifdef CONFIG_PPC_MULTIPLATFORM
>>+ /*
>>+ * We must write a positive value to the decrementer to clear
>>+ * the interrupt on the IBM 970 CPU series. In periodic mode,
>>+ * this happens when the decrementer gets reloaded later, but
>>+ * in one-shot mode, we have to do it here since an event handler
>>+ * may skip loading the new value...
>>+ */
>>+ if (per_cpu(decrementers, cpu).mode != CLOCK_EVT_PERIODIC)
>>+ set_dec(DECREMENTER_MAX);
>>+#endif
> PPC_MULTIPLATFORM is going away soon (or will be set for all CPU types
> in arch/powerpc). Just make up a macro at the top of the file around the
> lines of
> #if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
> #define PPC_BOOKE_DECREMENTER
> #endif
> And use #if(n)def PPC_BOOKE_DECREMENTER in the rest of the code.
That's not equivalent. What I wanted to cover with this option was 970
weirdness of the decrementer interrupts being level triggered and effectively
tied to the MSB of the decremeneter register...
Also, 40x decrementer is not Book E compatible.
> Also, what's the problem with ppc64 deterministic accounting that you
> can't fix it ?
Arch-specific accounting hooks which this feature makes use of can't be
called from the generic clockevents code.
> Ben.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] adding ROM chips to device tree: respin
From: Sergei Shtylyov @ 2006-11-07 22:40 UTC (permalink / raw)
To: Vitaly Wool; +Cc: linuxppc-embedded
In-Reply-To: <1162937920.2680.10.camel@barja>
Hello.
Vitaly Wool wrote:
>> We don't have any actual registers (at least "physmap" doesn't know about
>>them anyway) I think, just a memory range. What registers are you talking about?
> We do have registers there, in query mode. The CFI registers.
Aren't they accessed thru the range we're giving to the mapping layer?
What else do you need? Who cares about the exact offsets at the mapping level
(or at the level of the bus)?
>>>Okay, probably we can go you way naming of_device by what it's
>>>compatible with. So that "physmap" compatible would be called
>>>"physmap-flash", "nand"-compatible would be called "nand-flash" etc.
>> Actually, Generic Names spec tells to use the most generic user-parsable
>>names, just like I used initally ("flash")...
>>>Does that work for you?
>> No. Getting rid of "physmap" completely and using of_find_node_by_type()
>>does. :-)
> That's effectively what I'm talking about. Find the device by type and
> register it with the name which depends on what it's compatible with.
I stand enlightened. It have finally occured to me that this of_device
stuff wasn't worth the effort of using it and moving the code into
drivers/mtd/. This move doesn't buy you much -- you still have to walk the
device tree stupidly in search for the "known" devices... unless you're making
up the names for of_platform bus like this. And what for? Those names aren't
used to select the correct driver anyway... Crap. :-(
We could also try using "device_type" or "name" properties to name the
of_device -- this name doesn't matter much anyway...
> Vitaly
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] PowerPC: clockevents and HRT support
From: Benjamin Herrenschmidt @ 2006-11-07 22:36 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, tglx, greg.weeks
In-Reply-To: <200611080005.08633.sshtylyov@ru.mvista.com>
> +#ifdef CONFIG_PPC_MULTIPLATFORM
> + /*
> + * We must write a positive value to the decrementer to clear
> + * the interrupt on the IBM 970 CPU series. In periodic mode,
> + * this happens when the decrementer gets reloaded later, but
> + * in one-shot mode, we have to do it here since an event handler
> + * may skip loading the new value...
> + */
> + if (per_cpu(decrementers, cpu).mode != CLOCK_EVT_PERIODIC)
> + set_dec(DECREMENTER_MAX);
> +#endif
PPC_MULTIPLATFORM is going away soon (or will be set for all CPU types
in arch/powerpc). Just make up a macro at the top of the file around the
lines of
#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
#define PPC_BOOKE_DECREMENTER
#endif
And use #if(n)def PPC_BOOKE_DECREMENTER in the rest of the code.
Also, what's the problem with ppc64 deterministic accounting that you
can't fix it ?
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 4/7] Powerpc MSI implementation
From: Benjamin Herrenschmidt @ 2006-11-07 22:29 UTC (permalink / raw)
To: Russell King
Cc: Matthew Wilcox, Greg Kroah-Hartman, Ingo Molnar, linuxppc-dev,
Thomas Gleixner, Eric W.Biederman, linux-pci, David S.Miller
In-Reply-To: <20061107222514.GG9533@flint.arm.linux.org.uk>
> I guess we'll just have to add __force casts all over the code. ;(
Or just do it in a single accessor function/macro...
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 4/7] Powerpc MSI implementation
From: Russell King @ 2006-11-07 22:25 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Greg Kroah-Hartman, Ingo Molnar, linuxppc-dev, Thomas Gleixner,
Eric W.Biederman, linux-pci, David S.Miller
In-Reply-To: <20061107210202.GA27140@parisc-linux.org>
On Tue, Nov 07, 2006 at 02:02:02PM -0700, Matthew Wilcox wrote:
> On Tue, Nov 07, 2006 at 08:48:53PM +0000, Russell King wrote:
> > On Tue, Nov 07, 2006 at 01:44:32PM -0700, Matthew Wilcox wrote:
> > > On Tue, Nov 07, 2006 at 08:14:36PM +0000, Russell King wrote:
> > > > Bah. chip_data is supposed to be __iomem. I bet if you build ARM
> > > > with sparse it'll kick out lots of warnings as a result of that loss.
> > >
> > > Erm, since when? When I introduced it (back in January 2005 [1]), it
> > > was called handler_data and pointed to a struct which is chip-type
> > > dependent.
> >
> > Since before the generic irq merge. If I was more expert with git
> > I'd post a URL, but I'm not so I won't. But I'm sure you can find
> > it - look at the history of include/asm-arm/mach/irq.h.
>
> OK. Looks like the first mention of this is in
> 4a2581a080098ca3a0c4e416d7a282e96c75ebf8 from July 2006
> which is signed-off by you, Ingo Molnar and Thomas Gleixner:
>
> - void __iomem *base;
> [...]
> +#define set_irq_chipdata(irq, d) set_irq_chip_data(irq, d)
> +#define get_irq_chipdata(irq) get_irq_chip_data(irq)
> -#define set_irq_chipdata(irq,d) do { irq_desc[irq].base = d; } while (0)
> -#define get_irq_chipdata(irq) (irq_desc[irq].base)
Yes and now I'm regretting having switched ARM over to the generic IRQ
stuff - the old stuff did _precisely_ what we wanted the way we wanted.
None of these compromises.
> As other architectures, you could embed the iomem pointer in a
> struct (would it be useful to you to have more than an iomem pointer
> in your handlers?), or you could put the cast adding __iomem in
> get_irq_chipdata().
That's extremely wasteful - the only way to do that would be to kmalloc
some memory, and that's 32 bytes minimum, just to store 4 bytes of
pointer. There's no other information which needs to be stored.
I guess we'll just have to add __force casts all over the code. ;(
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox