* Re: PCI IO range limitation
From: Matt Sealey @ 2007-06-29 17:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Marian Balakowicz
In-Reply-To: <1183075997.5521.292.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> On Fri, 2007-06-29 at 00:38 +0100, Matt Sealey wrote:
>> Benjamin Herrenschmidt wrote:
>>> On Thu, 2007-06-28 at 12:20 +0200, Marian Balakowicz wrote:
>>>> Hi,
>>>>
>>>> Trying to change PCI IO window base for 52xx target I found that
>>>> we are pretty much limited to a "0" offset only.
>>> We just fixed that for 64 bits but 32 bits still has the limitation.
>>> Note that it's not a very good idea to have your IO range at !0 if
>>> you're going to use anything ISA-like, such as a VGA video card or other
>>> legacy devices behind a PCI southbridge or SuperIO.
>> The chances of that on an MPC52xx platform are practically zero, aren't
>> they?
>
> Euh... don't you use VGA video cards on Efika ? :-)
Define "legacy device"? What should that entail? You mean like mapping
most of those registers to the first couple of kilobytes of "IO"?
If they're just left as their own on their own as PCI devices, why would
it matter what the window was?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH] Schedule removal of arch/ppc
From: Mark A. Greer @ 2007-06-29 17:23 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, paulus
In-Reply-To: <1183130082.1170.344.camel@pmac.infradead.org>
On Fri, Jun 29, 2007 at 04:14:42PM +0100, David Woodhouse wrote:
> On Fri, 2007-06-29 at 10:13 -0500, Josh Boyer wrote:
> > That's it? I'm scheduling the demise of an entire architecture
> > sub-tree and the only comment you can make is about a superfluous
> > apostrophe? ;)
>
> Sorry, allow me to rephrase...
>
> http://www.angryflower.com/itsits.gif
> DIE arch/ppc DIE!
I second that motion. ;)
^ permalink raw reply
* Re: for-2.6.23 branch in powerpc.git created
From: Scott Wood @ 2007-06-29 17:35 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0706282058100.5368@poirot.grange>
On Thu, Jun 28, 2007 at 09:01:58PM +0200, Guennadi Liakhovetski wrote:
> Sure, no problem, will repost with a description and a Signed-off-by...
> but, not giving Scott Wood credit for that patch doesn't seem right.
> Scott, is it ok with you if I repost that patch with your "Signed-off-by"
> first and mine second?
Sure.
-Scott
^ permalink raw reply
* [PATCH] ucc_geth.c, make PHY device optional.
From: Joakim Tjernlund @ 2007-06-29 18:49 UTC (permalink / raw)
To: 'linuxppc-dev Development', Netdev, Li Yang-r58472
This patch makes the PHY optional for ucc_geth.c ethernet driver.
This is useful to support a direct mii to mii connection to, for example,
a onboard swicth.
Signed-off-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
----
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 32bb748..8630294 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -2273,7 +2273,8 @@ static void ucc_geth_stop(struct ucc_geth_private *ugeth)
ugeth_disable(ugeth, COMM_DIR_RX_AND_TX);
/* Tell the kernel the link is down */
- phy_stop(phydev);
+ if (phydev)
+ phy_stop(phydev);
/* Mask all interrupts */
out_be32(ugeth->uccf->p_ucce, 0x00000000);
@@ -3687,14 +3688,16 @@ static int ucc_geth_open(struct net_device *dev)
dev->dev_addr[5],
&ugeth->ug_regs->macstnaddr1,
&ugeth->ug_regs->macstnaddr2);
-
- err = init_phy(dev);
+ err = 0;
+ if (ugeth->ug_info->mdio_bus != ~0)
+ err = init_phy(dev);
if (err) {
ugeth_err("%s: Cannot initialize PHY, aborting.", dev->name);
return err;
}
- phy_start(ugeth->phydev);
+ if (ugeth->phydev)
+ phy_start(ugeth->phydev);
err =
request_irq(ugeth->ug_info->uf_info.irq, ucc_geth_irq_handler, 0,
@@ -3726,8 +3729,9 @@ static int ucc_geth_close(struct net_device *dev)
ugeth_vdbg("%s: IN", __FUNCTION__);
ucc_geth_stop(ugeth);
-
- phy_disconnect(ugeth->phydev);
+
+ if (ugeth->phydev)
+ phy_disconnect(ugeth->phydev);
ugeth->phydev = NULL;
netif_stop_queue(dev);
@@ -3807,17 +3811,16 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
ug_info->uf_info.irq = irq_of_parse_and_map(np, 0);
ph = of_get_property(np, "phy-handle", NULL);
- phy = of_find_node_by_phandle(*ph);
-
- if (phy == NULL)
- return -ENODEV;
-
- /* set the PHY address */
- prop = of_get_property(phy, "reg", NULL);
- if (prop == NULL)
- return -1;
- ug_info->phy_address = *prop;
-
+ if (ph != NULL) {
+ phy = of_find_node_by_phandle(*ph);
+ if (phy == NULL)
+ return -ENODEV;
+ /* set the PHY address */
+ prop = of_get_property(phy, "reg", NULL);
+ if (prop == NULL)
+ return -1;
+ ug_info->phy_address = *prop;
+ }
/* get the phy interface type, or default to MII */
prop = of_get_property(np, "phy-connection-type", NULL);
if (!prop) {
@@ -3857,19 +3860,22 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
ug_info->uf_info.utftt = UCC_GETH_UTFTT_GIGA_INIT;
}
- /* Set the bus id */
- mdio = of_get_parent(phy);
+ ug_info->mdio_bus = ~0; /* Means no MDIO bus */
+ if (ph) {
+ /* Set the bus id */
+ mdio = of_get_parent(phy);
- if (mdio == NULL)
- return -1;
+ if (mdio == NULL)
+ return -1;
- err = of_address_to_resource(mdio, 0, &res);
- of_node_put(mdio);
+ err = of_address_to_resource(mdio, 0, &res);
+ of_node_put(mdio);
- if (err)
- return -1;
+ if (err)
+ return -1;
- ug_info->mdio_bus = res.start;
+ ug_info->mdio_bus = res.start;
+ }
printk(KERN_INFO "ucc_geth: UCC%1d at 0x%8x (irq = %d) \n",
ug_info->uf_info.ucc_num + 1, ug_info->uf_info.regs,
^ permalink raw reply related
* [PATCH] powerpc: Add of_register_i2c_devices()
From: Guennadi Liakhovetski @ 2007-06-29 19:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
Add of_register_i2c_devices(), which scans the children of the specified
I2C adapter node, and registers them with the I2C code.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: G. Liakhovetski <g.liakhovetski@gmx.de>
diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse.c
index 3786dcc..9caf96d 100644
--- a/arch/powerpc/kernel/prom_parse.c
+++ b/arch/powerpc/kernel/prom_parse.c
@@ -1067,3 +1067,49 @@ void __iomem *of_iomap(struct device_node *np, int index)
return ioremap(res.start, 1 + res.end - res.start);
}
EXPORT_SYMBOL(of_iomap);
+
+#ifdef CONFIG_I2C
+#include <linux/i2c.h>
+
+void of_register_i2c_devices(struct device_node *adap_node, int bus_num)
+{
+ struct device_node *node = NULL;
+
+ while ((node = of_get_next_child(adap_node, node))) {
+ struct i2c_board_info info;
+ const u32 *addr;
+ const char *name, *model;
+ int len;
+
+ addr = of_get_property(node, "reg", &len);
+ if (!addr || len < sizeof(int) || *addr > 0xffff)
+ continue;
+
+ info.irq = irq_of_parse_and_map(node, 0);
+ if (info.irq == NO_IRQ)
+ info.irq = -1;
+
+ name = of_get_property(node, "compatible", NULL);
+ if (!name)
+ name = node->name;
+ if (!name)
+ continue;
+
+ model = of_get_property(node, "model", NULL);
+ if (!model)
+ model = name;
+
+ /* FIXME: the i2c code should allow drivers to specify
+ * multiple match names; board code shouldn't need to
+ * know what driver will handle a given type.
+ */
+
+ snprintf(info.driver_name, KOBJ_NAME_LEN, name);
+ snprintf(info.type, KOBJ_NAME_LEN, model);
+ info.platform_data = NULL;
+ info.addr = *addr;
+
+ i2c_register_board_info(bus_num, &info, 1);
+ }
+}
+#endif /* CONFIG_I2C */
diff --git a/include/asm-powerpc/prom.h b/include/asm-powerpc/prom.h
index 6845af9..ed085e1 100644
--- a/include/asm-powerpc/prom.h
+++ b/include/asm-powerpc/prom.h
@@ -305,6 +305,7 @@ extern int of_irq_map_raw(struct device_node *parent, const u32 *intspec,
u32 ointsize, const u32 *addr,
struct of_irq *out_irq);
+void of_register_i2c_devices(struct device_node *adap_node, int bus_num);
/**
* of_irq_map_one - Resolve an interrupt for a device
^ permalink raw reply related
* Re: for-2.6.23 branch in powerpc.git created
From: Guennadi Liakhovetski @ 2007-06-29 19:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18051.22185.374607.755419@cargo.ozlabs.ibm.com>
On Thu, 28 Jun 2007, Paul Mackerras wrote:
> Guennadi Liakhovetski writes:
>
> > These two i2c patches:
> >
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037327.html
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037328.html
> >
> > also would be nice to get in, although, they only make sense with an ack
> > from Scott Wood and another patch from him, as explained in links above...
>
> Looks OK, but the first of those two patches doesn't have a
> Signed-off-by: line, and the description is not suitable.
>
> Please repost that patch with a nice description that describes what
> the patch does and why, without references to other web pages. You
> don't need to describe what is different from previous patches or who
> suggested those changes.
Ok, just reposted. I even used the original subject line and the
description from Scott's email. I also removed the part for
drivers/i2c/busses/i2c-mpc.c - it is a separate patch
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036079.html and I hope
it'll make it in either via ppc or via i2c tree (it was cc'ed) as well as
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036333.html (sorry,
Paul, for links again).
Speaking about i2c@lm-sensors.org - which way should these patches go? Is
it the usual separation drivers/i2c goes via i2c and arch/powerpc via ppc?
Or should I also email i2c folks to tell them not to use the original
patch from Scott?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: [PATCH v2] Fix VDSO gettimeofday() when called with NULL struct timeval.
From: Will Schmidt @ 2007-06-29 20:39 UTC (permalink / raw)
To: Tony Breeds, will_schmidt; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <20070625235032.GH9768@bakeyournoodle.com>
On Tue, 2007-06-26 at 09:50 +1000, Tony Breeds wrote:
> Updated to include feedback from Ben and Segher, also reposition the
> compare in the 64bit VDSO to catch all the references to tv.
> --- working.orig/arch/powerpc/kernel/vdso64/gettimeofday.S
> +++ working/arch/powerpc/kernel/vdso64/gettimeofday.S
<snippage>
> @@ -32,6 +31,8 @@ V_FUNCTION_BEGIN(__kernel_gettimeofday)
> mr r11,r3 /* r11 holds tv */
> mr r10,r4 /* r10 holds tz */
> bl V_LOCAL_FUNC(__get_datapage) /* get data page */
> + cmpldi r10,0 /* check if tv is NULL */
Whoops! r10 holds tz value, not tv. This should be r11.
As is, a (64-bit) userspace app calling gettimeofday(&tv,NULL); will
"silently fail", and the application is left using whatever old data
happens to be in the tv structure.
This affected my G5 (gentoo), most noticable when apps like 'ping' and
nfs-mounts quit working properly. :-)
patch follows momentarily...
> + beq 2f
> bl V_LOCAL_FUNC(__do_get_xsec) /* get xsec from tb & kernel */
> lis r7,15 /* r7 = 1000000 = USEC_PER_SEC */
> ori r7,r7,16960
> @@ -43,8 +44,8 @@ V_FUNCTION_BEGIN(__kernel_gettimeofday)
> * XSEC_PER_SEC
> */
> rldicl r0,r0,44,20
> - cmpldi cr0,r10,0 /* check if tz is NULL */
> std r0,TVAL64_TV_USEC(r11) /* store usec in tv */
> +2: cmpldi r10,0 /* check if tz is NULL */
> beq 1f
> lwz r4,CFG_TZ_MINUTEWEST(r3)/* fill tz */
> lwz r5,CFG_TZ_DSTTIME(r3)
>
> Yours Tony
>
> linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
> Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: 2.6.22-rc6-mm1
From: Andrew Morton @ 2007-06-29 20:47 UTC (permalink / raw)
To: Mariusz Kozlowski, Jason Wessel, Michal Marek
Cc: xfs-masters, xfs, paulus, linux-kernel, linuxppc-dev
In-Reply-To: <200706291432.10128.m.kozlowski@tuxland.pl>
On Fri, 29 Jun 2007 14:32:09 +0200
Mariusz Kozlowski <m.kozlowski@tuxland.pl> wrote:
> Hello,
>
> allmodconfig on powerpc (iMac g3) fails due to
> git-kgdb.patch. allmodconfig defaults should be changed?
>
> CC arch/powerpc/kernel/kgdb.o
> arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB selected
> in .config. Unselect one of them.
> make[1]: *** [arch/powerpc/kernel/kgdb.o] Blad 1
> make: *** [arch/powerpc/kernel] Blad 2
Jason cc'ed
> anyway after unselecting XMON we can see:
>
> CC [M] fs/xfs/linux-2.6/xfs_ioctl32.o
> fs/xfs/linux-2.6/xfs_ioctl32.c: In function 'xfs_ioc_bulkstat_compat':
> fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: 'xfs_inumbers_fmt_compat'
> undeclared (first use in this function)
> fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: (Each undeclared identifier is
> reported only once
> fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: for each function it appears in.)
> make[2]: *** [fs/xfs/linux-2.6/xfs_ioctl32.o] Blad 1
> make[1]: *** [fs/xfs] Blad 2
>
> This is just allmodconfig - not a .config that's used daily by users but I'm
> used to compiling the kernel using it anyway 8)
>
Michal cc'ed. I think this is the one which was already reported but
I haven't seen a fix yet?
^ permalink raw reply
* [PATCH v2.1 ] Fix VDSO gettimeofday() when called with NULL struct timeval.
From: Will Schmidt @ 2007-06-29 20:49 UTC (permalink / raw)
To: willschm; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <1183149584.22547.51.camel@farscape.rchland.ibm.com>
The vdso64 portion of patch 74609f4536f2b8fd6a48381bbbe3cd37da20a527 for
fixing problems with NULL gettimeofday input mistakenly checks for a
null tz field twice, when it should be checking for null tz once, and
null tv once; by way of a r10/r11 typo.
Any application calling gettimeofday(&tv,NULL) will "fail".
This corrects that typo, and makes my G5 happy.
tested on G5.
Signed-off-by: Will Schmidt <will_schmidt@vnet.ibm.com>
cc: Tony Breeds <tony@bakeyournoodle.com>
cc: Ben Herrenschmidt <benh@kernel.crashing.org>
---
diff --git a/arch/powerpc/kernel/vdso64/gettimeofday.S b/arch/powerpc/kernel/vdso64/gettimeofday.S
index 2d7a510..c6401f9 100644
--- a/arch/powerpc/kernel/vdso64/gettimeofday.S
+++ b/arch/powerpc/kernel/vdso64/gettimeofday.S
@@ -31,7 +31,7 @@ V_FUNCTION_BEGIN(__kernel_gettimeofday)
mr r11,r3 /* r11 holds tv */
mr r10,r4 /* r10 holds tz */
bl V_LOCAL_FUNC(__get_datapage) /* get data page */
- cmpldi r10,0 /* check if tv is NULL */
+ cmpldi r11,0 /* check if tv is NULL */
beq 2f
bl V_LOCAL_FUNC(__do_get_xsec) /* get xsec from tb & kernel */
lis r7,15 /* r7 = 1000000 = USEC_PER_SEC */
^ permalink raw reply related
* Re: [PATCH v2.1 ] Fix VDSO gettimeofday() when called with NULL struct timeval.
From: Segher Boessenkool @ 2007-06-29 22:45 UTC (permalink / raw)
To: will_schmidt; +Cc: willschm, LinuxPPC-dev, Paul Mackerras
In-Reply-To: <1183150190.22547.62.camel@farscape.rchland.ibm.com>
> The vdso64 portion of patch 74609f4536f2b8fd6a48381bbbe3cd37da20a527
> for
> fixing problems with NULL gettimeofday input mistakenly checks for a
> null tz field twice, when it should be checking for null tz once, and
> null tv once; by way of a r10/r11 typo.
>
> Any application calling gettimeofday(&tv,NULL) will "fail".
>
> This corrects that typo, and makes my G5 happy.
>
> tested on G5.
>
>
> Signed-off-by: Will Schmidt <will_schmidt@vnet.ibm.com>
Obviously correct, how could we all have missed this :-(
Thanks Will.
Segher
^ permalink raw reply
* Re: PCI IO range limitation
From: Benjamin Herrenschmidt @ 2007-06-29 23:14 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Marian Balakowicz
In-Reply-To: <46853CA2.2040203@genesi-usa.com>
> Define "legacy device"? What should that entail? You mean like mapping
> most of those registers to the first couple of kilobytes of "IO"?
Anything that hard-decodes IOs in the low ISA range yes. That includes
VGA video cards.
> If they're just left as their own on their own as PCI devices, why would
> it matter what the window was?
Because quite a few of those things hard decodes (can't be moved around,
so -have- to be able to generate cycles to those low addresses to hit
them) and sometimes don't even fully decode the 32 bits addresses
(though that's more rare).
For example, a VGA video card in text mode hard decodes both IO and
Memory at the legacy VGA ranges.
Ben.
^ permalink raw reply
* Re: 83xx: requesting external interrupts
From: Andy Fleming @ 2007-06-29 23:54 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-embedded
In-Reply-To: <1183116892.20673.66.camel@gentoo-jocke.transmode.se>
On Jun 29, 2007, at 06:34, Joakim Tjernlund wrote:
> mdio@2320 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <2320 18>;
> device_type = "mdio";
> compatible = "ucc_geth_phy";
>
> phy1: ethernet-phy@0 {
> interrupt-parent = <&ipic>;
> interrupts = <12 2>; //EXT IRQ2
> reg = <0>; // 0
> device_type = "ethernet-phy";
> interface = <3>; //ENET_100_MII
> };
>
> Now the things is that the IRQ works with and without the
> /* All external IRQs + Generic timer IRQs must be initialized by
> BSP */
> const int bsp_irqs[] = {48, 17, 18, 19, 20, 21, 22, 23, 90, 78,
> 84, 72};
> for (i=0;i<sizeof(bsp_irqs)/sizeof(bsp_irqs[0]);i++)
> virq = irq_create_mapping(NULL, bsp_irqs[i]);
This isn't how to use the device tree. That is, you *aren't* using
the device tree. You want to read the node of every device you want
to set up, and create the mapping. Look at irq_of_parse_and_map().
Look in include/asm-powerpc/prom.h, at of_irq_to_resource(), which
maps an irq in the device tree.
Andy
^ permalink raw reply
* Re: [PATCH 09/15] [POWERPC] 86xx: Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Andy Fleming @ 2007-06-30 0:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <66B07304-BE33-4A9E-8C9C-BEC0BCEC79F8@kernel.crashing.org>
On Jun 27, 2007, at 17:51, Kumar Gala wrote:
>
>>>> What is the relationship between (in the example) the address
>>>> ranges x'f800_0000+1000 and x'f800_1000+ff000?
>>>
>>> uugh, not sure what that's all about.
>>
>> Reading back I see that the CCSR region is 1MB, and only the
>> first 4kB are for this PHB. What is the rest of this range
>> used for -- devices on this PCI bus, other SoC devices, ...?
>
> No, the first 4kB are SOC/platform level config registers (high
> level window setup, CCSR location, etc).
>
> The PHB registers are somewhere in the middle (0x8000, I think).
> All the children devices (enet, PHBs, etc) live in the 1M block.
>
> I think my original idea was the reg property on the SOC node was
> for the first 4k block that held the SOC config registers. I think
> what Wade did is correct since the reg property on the SOC node
> isnt going to get translated through the ranges property and that
> they should be mutually exclusive.
Ok, I'm thinking we don't need the reg property at all, or that it
can be of size 0 or 4 (the CCSRBAR, itself). If we need to access
registers in the first 4k, we can define reg properties for the
submodules which are in the CCSR space.
My issue with the submitted option is that the first 4k don't really
belong to an SOC "device", they are just the first 4k of registers.
In this case, they are the Local Access Window registers. It sort of
feels like we're arbitrarily deciding assigning the first 4k to the
"SOC". If that's what we want to do, I'd like if we put it in
booting-without-of.txt. Actually, it should go there, anyway.
Andy
^ permalink raw reply
* a question for ac97 driver interrupt
From: silicom @ 2007-06-30 1:13 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 254 bytes --]
Hi
I'm just adding interrupt function for my ac97 driver,but I don't know how to clear interrupt status in the interrupt handler,so it will cause nesting interrupt,can any one give me some advice about the structure of interrupt handle function?
[-- Attachment #2: Type: text/html, Size: 636 bytes --]
^ permalink raw reply
* A question about map_page
From: kang shuo @ 2007-06-30 3:31 UTC (permalink / raw)
To: linuxppc-embedded
hi:
I had read some ppc code in linux-2.6.20. There is a question
about map_page function. map_page seems to implement the map between
virtual address and physical address. But I can not understand how the
tlb entry operation is done in the code in map_page. The map_page is
as the following:
int
map_page(unsigned long va, phys_addr_t pa, int flags)
{
pmd_t *pd;
pte_t *pg;
int err = -ENOMEM;
/* Use upper 10 bits of VA to index the first level map */
pd = pmd_offset(pgd_offset_k(va), va);
/* Use middle 10 bits of VA to index the second-level map */
pg = pte_alloc_kernel(pd, va);
if (pg != 0) {
err = 0;
set_pte_at(&init_mm, va, pg, pfn_pte(pa >> PAGE_SHIFT,
__pgprot(flags)));
if (mem_init_done)
flush_HPTE(0, va, pmd_val(*pd));
}
return err;
}
Could anyone give me some hints about where and when tlb entry
is setup according to map_page function. That is very appreciate.
-- Thanks
-- Michael.Kang
^ permalink raw reply
* current-speed property in serial devices causes kernel panic
From: Timur Tabi @ 2007-06-30 4:26 UTC (permalink / raw)
To: linuxppc-dev list
I see this code in function of_platform_serial_setup():
static int __devinit of_platform_serial_setup(struct of_device *ofdev,
int type, struct uart_port *port)
{
struct resource resource;
struct device_node *np = ofdev->node;
const unsigned int *clk, *spd;
int ret;
memset(port, 0, sizeof *port);
spd = of_get_property(np, "current-speed", NULL);
...
port->custom_divisor = *clk / (16 * (*spd));
return 0;
}
There is no check in this code to make sure spd is not null. And sure enough, in most DTS files, current-speed does not exist. So whenever this function is called on a node like this, the kernel panics.
I'm adding support for a new 86xx platform, and I'm also creating a driver for a new SOC device. In my platform driver, I have this code:
static struct of_device_id mpc86xx_ids[] = {
{ .type = "soc", },
{}
};
static int __init mpc86xx_declare_of_platform_devices(void)
{
printk(KERN_ALERT "%s\n", __FUNCTION__);
if (!machine_is(mpc86xx_hpcn))
return 0;
of_platform_bus_probe(NULL, mpc86xx_ids, NULL);
return 0;
}
device_initcall(mpc86xx_declare_of_platform_devices);
The kernel panic occurs only if I call of_platform_bus_probe().
If you look at the code for the 836x platform, you'll see that it also has serial SOC devices and it also calls of_platform_bus_probe(), but it doesn't experience kernel panics.
Is the call to of_platform_bus_probe() effectively trying to probe the serial devices twice? I just don't understand why this code isn't working.
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Paul Mackerras @ 2007-06-30 6:57 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, Arnd Bergmann, amodra
In-Reply-To: <jelke2ss3n.fsf@sykes.suse.de>
Andreas Schwab writes:
> The assembler should be called with -a64, which has the effect of
> defaulting to -mppc64.
Yes, the assembler is called with -a64, but that doesn't appear to
have the effect of defaulting to -mppc64.
[Alan: this thread is about the fact that compiling C code with "gcc
-m64 -mcpu=powerpc64" will give assembler errors, complaining about
instructions like sldi, whereas compiling with "gcc -m64" doesn't.]
Paul.
^ permalink raw reply
* Re: [PATCH] Schedule removal of arch/ppc
From: Michael Ellerman @ 2007-06-30 7:58 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, paulus
In-Reply-To: <1183128867.1170.341.camel@pmac.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 544 bytes --]
On Fri, 2007-06-29 at 15:54 +0100, David Woodhouse wrote:
> On Wed, 2007-06-27 at 08:49 -0500, Josh Boyer wrote:
> > + remain in bug-fix only mode until it's scheduled removal. Platforms
>
> http://www.angryflower.com/itsits.gif
Hahaha. Is there one for your as well?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Andreas Schwab @ 2007-06-30 8:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann, amodra
In-Reply-To: <18053.65260.136499.154352@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Andreas Schwab writes:
>
>> The assembler should be called with -a64, which has the effect of
>> defaulting to -mppc64.
>
> Yes, the assembler is called with -a64, but that doesn't appear to
> have the effect of defaulting to -mppc64.
Is your assembler older than 4 years?
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Paul Mackerras @ 2007-06-30 8:14 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, Arnd Bergmann, amodra
In-Reply-To: <jeir95j21k.fsf@sykes.suse.de>
Andreas Schwab writes:
> Is your assembler older than 4 years?
No, well, at least not unless Debian sid is seriously behind the
times. It's version 2.17 from the Debian binutils 2.17-3 package.
Paul.
^ permalink raw reply
* Re: [PATCH] Schedule removal of arch/ppc
From: David Woodhouse @ 2007-06-30 8:18 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, paulus
In-Reply-To: <1183190301.21968.4.camel@concordia.ozlabs.ibm.com>
On Sat, 2007-06-30 at 17:58 +1000, Michael Ellerman wrote:
> On Fri, 2007-06-29 at 15:54 +0100, David Woodhouse wrote:
> > On Wed, 2007-06-27 at 08:49 -0500, Josh Boyer wrote:
> > > + remain in bug-fix only mode until it's scheduled removal. Platforms
> >
> > http://www.angryflower.com/itsits.gif
>
> Hahaha. Is there one for your as well?
Not unless you think that bobsqu.gif or destro.gif covers it, I believe.
--
dwmw2
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Andreas Schwab @ 2007-06-30 8:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann, amodra
In-Reply-To: <18054.4311.784767.549009@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Andreas Schwab writes:
>
>> Is your assembler older than 4 years?
>
> No, well, at least not unless Debian sid is seriously behind the
> times. It's version 2.17 from the Debian binutils 2.17-3 package.
Probably some debian patches messed it up. I'd suggest reporting that
to them. FWIW, the unmodified assembler gives this error when operating
in 32bit mode:
$ echo 'sldi 0,0,10' | as
{standard input}: Assembler messages:
{standard input}:1: Error: Unrecognized opcode: `rldicr'
But just addding -many (which gcc always passes) will let the assembler
accept this.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: powerpc stacktrace and lockdep support
From: Christoph Hellwig @ 2007-06-30 8:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, Christoph Hellwig
In-Reply-To: <1183047642.3735.0.camel@johannes.berg>
On Thu, Jun 28, 2007 at 06:20:42PM +0200, Johannes Berg wrote:
> This one doesn't break 32-bit build by simply disabling irqtrace for
> 32-bit.
This looks really cool to me. I'd love to see this in 2.6.23.
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Alan Modra @ 2007-06-30 10:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Arnd Bergmann, linuxppc-dev
In-Reply-To: <18053.65260.136499.154352@cargo.ozlabs.ibm.com>
On Sat, Jun 30, 2007 at 04:57:48PM +1000, Paul Mackerras wrote:
> Andreas Schwab writes:
>
> > The assembler should be called with -a64, which has the effect of
> > defaulting to -mppc64.
>
> Yes, the assembler is called with -a64, but that doesn't appear to
> have the effect of defaulting to -mppc64.
>
> [Alan: this thread is about the fact that compiling C code with "gcc
> -m64 -mcpu=powerpc64" will give assembler errors, complaining about
> instructions like sldi, whereas compiling with "gcc -m64" doesn't.]
Eh? For a long time, powerpc gcc has passed "-many" to the assembler,
which should avoid this sort of problem. Broken toolchain, I'd say.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply
* RE: 83xx: requesting external interrupts
From: Joakim Tjernlund @ 2007-06-30 14:02 UTC (permalink / raw)
To: 'Andy Fleming'; +Cc: linuxppc-embedded
In-Reply-To: <1B23F0C1-3BDF-434B-BF90-E75BB4C3994B@freescale.com>
> -----Original Message-----
> From: Andy Fleming [mailto:afleming@freescale.com]
> Sent: den 30 juni 2007 01:55
> To: Joakim Tjernlund
> Cc: bwarren@qstreams.com; linuxppc-embedded@ozlabs.org
> Subject: Re: 83xx: requesting external interrupts
>
>
> On Jun 29, 2007, at 06:34, Joakim Tjernlund wrote:
> > mdio@2320 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > reg = <2320 18>;
> > device_type = "mdio";
> > compatible = "ucc_geth_phy";
> >
> > phy1: ethernet-phy@0 {
> > interrupt-parent = <&ipic>;
> > interrupts = <12 2>; //EXT IRQ2
> > reg = <0>; // 0
> > device_type = "ethernet-phy";
> > interface = <3>; //ENET_100_MII
> > };
> >
> > Now the things is that the IRQ works with and without the
> > /* All external IRQs + Generic timer IRQs must be initialized by
> > BSP */
> > const int bsp_irqs[] = {48, 17, 18, 19, 20, 21, 22, 23, 90, 78,
> > 84, 72};
> > for (i=0;i<sizeof(bsp_irqs)/sizeof(bsp_irqs[0]);i++)
> > virq = irq_create_mapping(NULL, bsp_irqs[i]);
>
>
> This isn't how to use the device tree. That is, you *aren't* using
> the device tree. You want to read the node of every device you want
> to set up, and create the mapping. Look at irq_of_parse_and_map().
> Look in include/asm-powerpc/prom.h, at of_irq_to_resource(), which
> maps an irq in the device tree.
I use both!
I see that ipic.c does all the work for me, so I should just drop
the above code. It is strange though that the virq # changes if
I keep the code.
hmm, maybe if I sort the bsp_irqs[] list numerically it will be the same?
Am at home ATM so I can't verify.
Jocke
^ 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