* Re: [PATCH v3] Create add_rtc() function to enable the RTC CMOS driver
From: Segher Boessenkool @ 2007-06-22 7:56 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070622033158.GA21419@localhost.localdomain>
> Hrm. It seems rather specific. Can we do this more generally, by
> creating an of_platform device which binds to rtc nodes, then
> registers an appropriate platform device for each so that the generic
> rtc drivers pick them up. Obviously we'd need some sort of table
> mapping the device node compatible properties to the appropriate
> platform device names.
>> + * RTC_PORT(x) is hardcoded in asm/mc146818rtc.h. Verify that the
>> + * address provided by the device node matches.
>> + */
>> + if (res.start != RTC_PORT(0)) {
>> + of_node_put(np);
>> + return -ENODEV;
>> + }
>
> This looks totally bogus. If we have a device tree we should be using
> the address information from there, not using hardcoded magic. Sounds
> like asm/mc146818rtc.h needs some serious fixing.
Both of your comments would be nice extensions (and the right
way forwards), but Wade's patch is good as-is already.
Segher
^ permalink raw reply
* Re: [RFC] Device tree for new desktop platform in arch/powerpc
From: Benjamin Herrenschmidt @ 2007-06-22 8:16 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: list, David Gibson
In-Reply-To: <be8290e4a9e76608b8ede05deaaf91af@kernel.crashing.org>
On Fri, 2007-06-22 at 09:52 +0200, Segher Boessenkool wrote:
> >> The "#address-cells" property should be completely absent,
> >> even; for interrupt matching, that means "treat as 0, no
> >> unit address used in interrupt mapping, just the interrupt
> >> number", and for the "normal" purpose (defining the format
> >> of devices on the bus rooted at / represented by this node)
> >> it means "there is no such bus" -- this is different from
> >> #address-cells = 0.
> >
> > I'd rather have it present and explicitely set to 0,
>
> It is not the "right thing" to do, but should be harmless
> in most situations.
It's pretty much the right thing to do in that case imho... based on the
assumption that a common practice is worth 10 standards :-)
(I think I could even quote Linus on that one, let's just say that I
totally agree with him on those matters, I'd rather have people
"standardize" around existing common practices that happen to also work
well with existing code rather than doing differently because that's
what a 10 yrs old unmaintained piece of pdf says should be done :-)
Ben.
^ permalink raw reply
* Re: [RFC] Device tree for new desktop platform in arch/powerpc
From: Segher Boessenkool @ 2007-06-22 9:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: list, David Gibson
In-Reply-To: <1182500191.24740.49.camel@localhost.localdomain>
>>>> The "#address-cells" property should be completely absent,
>>>> even; for interrupt matching, that means "treat as 0, no
>>>> unit address used in interrupt mapping, just the interrupt
>>>> number", and for the "normal" purpose (defining the format
>>>> of devices on the bus rooted at / represented by this node)
>>>> it means "there is no such bus" -- this is different from
>>>> #address-cells = 0.
>>>
>>> I'd rather have it present and explicitely set to 0,
>>
>> It is not the "right thing" to do, but should be harmless
>> in most situations.
>
> It's pretty much the right thing to do in that case imho... based on
> the
> assumption that a common practice is worth 10 standards :-)
It is of course "defensive programming", in that a device
tree like that also works with badly broken OS code.
So perhaps we should indeed recommend this for Linux flat
device trees.
Which is not to say that the Linux parsing code shouldn't
be fixed (if it is broken at all, who knows).
> (I think I could even quote Linus on that one, let's just say that I
> totally agree with him on those matters, I'd rather have people
> "standardize" around existing common practices that happen to also work
> well with existing code rather than doing differently because that's
> what a 10 yrs old unmaintained piece of pdf says should be done :-)
OTOH, you need a few people doing the "interesting" cases,
so you can find and fix the flaws in your OS code :-)
Segher
^ permalink raw reply
* Re: [RFC] clocksouce implementation for powerpc
From: Sergei Shtylyov @ 2007-06-22 12:42 UTC (permalink / raw)
To: Tony Breeds
Cc: Andrew Morton, Daniel Walker, john stultz, LKML, LinuxPPC-dev,
Thomas Gleixner, Ingo Molnar
In-Reply-To: <20070622061047.GW9768@bakeyournoodle.com>
Tony Breeds wrote:
> Thanks for taking the time to look over my patch.
>> I guess it's been based on the prior work by John Stultz (and me too :-)?
> At some level I guess so. John did send me a patch a while ago.
>> If you mean the init. part, this has been already done by me -- I've
>>implemented read_persistent_clock() and got rid of xtime setting. What's
>>left is to implemet update_persistent_clock() and get rid of
>>timer_check_rtc()...
> Actually I think that comment is redundant. and should be removed
> sorry.
I guess you haven't looked thru the -rt patch? There's much more than
John's initial patch there now, including the clockevents driver.
>>>+ .mult = 0, /* To be filled in */
>>>+ .read = NULL, /* To be filled in */
>>>+ .settimeofday = NULL, /* To be filled in */
>>
>> I don't quite understand why not just init them right away? The values
>>are fixed anyways.
> Well at least mult needs to be calculated at runtime, and I prefer to
I was talking about the method intializers specifically.
> have the structure near the top of the file at which stage the
> read/settimeofday functions aren't defined.
I don't think it's justified anyway.
> Yours Tony
WBR, Sergei
^ permalink raw reply
* Re: [RFC] Device tree for new desktop platform in arch/powerpc
From: Gerhard Pircher @ 2007-06-22 13:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1182468169.24740.15.camel@localhost.localdomain>
-------- Original-Nachricht --------
Datum: Fri, 22 Jun 2007 09:22:49 +1000
Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
An: Gerhard Pircher <gerhard_pircher@gmx.net>
CC: linuxppc-dev@ozlabs.org
Betreff: Re: [RFC] Device tree for new desktop platform in arch/powerpc
> Do you have the recommended practice "interrupt mapping" standard ?
Yes, downloaded it right now.
> It also allowed to make it optional to have nodes for the PCI devices in
> slots, you can provide the mapping of all 4 INT# lines in the bridge
> node and linux can use it when probing for devices, so your bootwrapper
> doesn't have to know what's in the slots and doesn't have to create
> device nodes for those.
I would like to have PCI nodes only for the PCI host and PCI2ISA bridge.
The interrupt mapping of the INT# lines can be configured within U-boot,
thus I would avoid to specify it somewhere in the device tree, if it isn't
really necessary.
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* RFC: Add indirect variants to pci indirect
From: Kumar Gala @ 2007-06-22 13:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Wei.Zhang
Ben,
I wanted to get your feedback on this approach for handling the variants
of pci indirect that we have on Freescale parts.
The idea is hose->indirect_type is a bit mask of 'features'. I'm not sure
if PPC_INDIRECT_TYPE_PHB_IS_ZERO is the best name and if we could get ride
of bus_offset all together.
It was pointed out that a system that doesn't care about X that has
multiple PHBs may assign PCI bus # as hose0: bus0-4, hose1: 0-3.
- k
diff --git a/arch/powerpc/sysdev/indirect_pci.c b/arch/powerpc/sysdev/indirect_pci.c
index e4f6c67..b18fa53 100644
--- a/arch/powerpc/sysdev/indirect_pci.c
+++ b/arch/powerpc/sysdev/indirect_pci.c
@@ -33,6 +33,7 @@ indirect_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
struct pci_controller *hose = bus->sysdata;
volatile void __iomem *cfg_data;
u8 cfg_type = 0;
+ u32 bus_no, reg;
if (ppc_md.pci_exclude_device)
if (ppc_md.pci_exclude_device(hose, bus->number, devfn))
@@ -42,9 +43,18 @@ indirect_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
if (bus->number != hose->first_busno)
cfg_type = 1;
- PCI_CFG_OUT(hose->cfg_addr,
- (0x80000000 | ((bus->number - hose->bus_offset) << 16)
- | (devfn << 8) | ((offset & 0xfc) | cfg_type)));
+ if (hose->indirect_type & PPC_INDIRECT_TYPE_PHB_IS_ZERO)
+ bus_no = bus->number == hose->first_busno ? 0 : bus->number;
+ else
+ bus_no = bus->number - hose->bus_offset;
+
+ if (hose->set_cfg_type & PPC_INDIRECT_TYPE_EXT_REG)
+ reg = ((offset & 0xf00) << 16) | (offset & 0xfc);
+ else
+ reg = offset & 0xfc;
+
+ PCI_CFG_OUT(hose->cfg_addr,
+ (0x80000000 | bus_no | (devfn << 8) | reg | cfg_type));
/*
* Note: the caller has already checked that offset is
@@ -72,6 +82,7 @@ indirect_write_config(struct pci_bus *bus, unsigned int devfn, int offset,
struct pci_controller *hose = bus->sysdata;
volatile void __iomem *cfg_data;
u8 cfg_type = 0;
+ u32 bus_no, reg;
if (ppc_md.pci_exclude_device)
if (ppc_md.pci_exclude_device(hose, bus->number, devfn))
@@ -81,9 +92,23 @@ indirect_write_config(struct pci_bus *bus, unsigned int devfn, int offset,
if (bus->number != hose->first_busno)
cfg_type = 1;
- PCI_CFG_OUT(hose->cfg_addr,
- (0x80000000 | ((bus->number - hose->bus_offset) << 16)
- | (devfn << 8) | ((offset & 0xfc) | cfg_type)));
+ if (hose->indirect_type & PPC_INDIRECT_TYPE_PHB_IS_ZERO)
+ bus_no = bus->number == hose->first_busno ? 0 : bus->number;
+ else
+ bus_no = bus->number - hose->bus_offset;
+
+ if (hose->set_cfg_type & PPC_INDIRECT_TYPE_EXT_REG)
+ reg = ((offset & 0xf00) << 16) | (offset & 0xfc);
+ else
+ reg = offset & 0xfc;
+
+ PCI_CFG_OUT(hose->cfg_addr,
+ (0x80000000 | bus_no | (devfn << 8) | reg | cfg_type));
+
+ if (hose->indirect_type & PPC_INDIRECT_TYPE_FSL_PCIE_HACK)
+ if ((offset == PCI_PRIMARY_BUS) &&
+ (bus->number == hose->first_busno))
+ val &= 0xffffff00;
/*
* Note: the caller has already checked that offset is
diff --git a/include/asm-ppc/pci-bridge.h b/include/asm-ppc/pci-bridge.h
index 4d35b84..2f6651d 100644
--- a/include/asm-ppc/pci-bridge.h
+++ b/include/asm-ppc/pci-bridge.h
@@ -66,6 +66,15 @@ struct pci_controller {
*/
int set_cfg_type;
+ /*
+ * If set, indirect method will set the cfg_type bit as
+ * needed to generate type 1 configuration transactions.
+ */
+#define PPC_INDIRECT_TYPE_PHB_IS_ZERO (0x00000001)
+#define PPC_INDIRECT_TYPE_EXT_REG (0x00000002)
+#define PPC_INDIRECT_TYPE_FSL_PCIE_HACK (0x00000004)
+ u32 indirect_type;
+
/* Currently, we limit ourselves to 1 IO range and 3 mem
* ranges since the common pci_bus structure can't handle more
*/
^ permalink raw reply related
* Re: [RFC] Device tree for new desktop platform in arch/powerpc
From: Benjamin Herrenschmidt @ 2007-06-22 13:40 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070622131201.313400@gmx.net>
On Fri, 2007-06-22 at 15:12 +0200, Gerhard Pircher wrote:
> I would like to have PCI nodes only for the PCI host and PCI2ISA
> bridge.
> The interrupt mapping of the INT# lines can be configured within
> U-boot,
> thus I would avoid to specify it somewhere in the device tree, if it
> isn't
> really necessary.
You still need to provide the IRQ mapping for the PCI slots, but you can
do that from the interrupt-map property of the PCI host bridge node.
Ben.
^ permalink raw reply
* Re: [PATCH v2 0/9] Add Generic PCI-E support to 8641HPCN
From: Kumar Gala @ 2007-06-22 13:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <BE8C03AC-BA36-4A65-AFC6-A548E04A0359@kernel.crashing.org>
On Jun 21, 2007, at 5:29 PM, Kumar Gala wrote:
>
> On Jun 21, 2007, at 4:23 PM, Jon Loeliger wrote:
>
>> On Mon, 2007-06-04 at 17:29, Jon Loeliger wrote:
>>> Paul,
>>>
>>> This 8-part patch set combines the two previous patch
>>> sets, 5 from Zheng Wei, and 3 from me, along with one
>>> from Wade Farnsworth into one nice-n-happy set, all
>>> designed to re-enable PCI-Express on the MPC8641HPCN board.
>>>
>>> This is version 2 of the patch set and incorporates
>>> improvements suggested by list reviewers.
>>
>>
>> Paul,
>>
>> I hadn't seen any further comment on this series of
>> patches for PCI on 8641. Any chance we could get them
>> applied to your repo?
>
> I've got a "cleaner" version of the float bus patch that I need to
> post and will apply the others to my tree.
I've posted a RFC for a change to pci indirect that should address
our float bus problem.
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/038263.html
- k
^ permalink raw reply
* Re: [PATCH v2 3/9] 8641HPCN: Add PCI-Express link training status check
From: Kumar Gala @ 2007-06-22 13:48 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <1180996203.9632.71.camel@ld0161-tx32>
On Jun 4, 2007, at 5:30 PM, Jon Loeliger wrote:
> From: Zhang Wei <wei.zhang@freescale.com>
>
> Avoid system halt while the link training is fault.
>
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> Acked-by: Roy Zang <tie-fei.zang@freescale.com>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
> ---
> arch/powerpc/platforms/86xx/pci.c | 12 +++++++++++-
> 1 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/86xx/pci.c b/arch/powerpc/
> platforms/86xx/pci.c
> index 7efae7c..07ff52c 100644
> --- a/arch/powerpc/platforms/86xx/pci.c
> +++ b/arch/powerpc/platforms/86xx/pci.c
> @@ -122,7 +122,6 @@ static void __init
> mpc86xx_setup_pcie(struct pci_controller *hose, u32 pcie_offset,
> u32 pcie_size)
> {
> u16 cmd;
> - unsigned int temps;
>
> DBG("PCIE host controller register offset 0x%08x, size 0x%08x.\n",
> pcie_offset, pcie_size);
> @@ -140,6 +139,9 @@ int mpc86xx_exclude_device(u_char bus, u_char
> devfn)
> return PCIBIOS_SUCCESSFUL;
> }
>
> +#define PCIE_LTSSM 0x04000004 /* PCIe Link Training and Status */
> +#define PCIE_LTSSM_L0 0x16 /* L0 state */
> +
> int __init add_bridge(struct device_node *dev)
> {
> int len;
> @@ -148,12 +150,20 @@ int __init add_bridge(struct device_node *dev)
> const int *bus_range;
> int has_address = 0;
> int primary = 0;
> + void *pcicfg_addr;
>
> DBG("Adding PCIE host bridge %s\n", dev->full_name);
>
> /* Fetch host bridge registers address */
> has_address = (of_address_to_resource(dev, 0, &rsrc) == 0);
>
> + /* Probe the hose link training status */
> + pcicfg_addr = ioremap(rsrc.start, 0x1000);
> + out_be32(pcicfg_addr, 0x80000000 | PCIE_LTSSM);
> + if (in_le16(pcicfg_addr + 4) < PCIE_LTSSM_L0)
> + return -ENXIO;
> + iounmap(pcicfg_addr);
Is there a reason we don't do this with early_read_config_word, while
it requires we alloc the hose, it seems cleaner. If this fails, I
think the memory wasted on the hose is a minor concern. (assuming my
other patch to support extended regs in pci indirect).
- k
^ permalink raw reply
* Re: [PATCH v2 9/9] Created quirk_mpc8641_transparent() to initialize bridge resources.
From: Kumar Gala @ 2007-06-22 13:50 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <1180996227.9632.77.camel@ld0161-tx32>
On Jun 4, 2007, at 5:30 PM, Jon Loeliger wrote:
> The 8641 RC poses as a transparent bridge, but does not implement the
> IO_BASE or IO_LIMIT registers in the config space. This means that
> the code which initializes the bridge resources ends up setting the
> IO resources erroneously.
>
> This change sets RC of mpc8641 to be a transparent bridge
> for legacy I/O access and initializes the RC bridge resources
> from the device tree.
>
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
> ---
>
> Incorporates review suggestions from Milton.
>
> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 76 +++++++++++++++++
> +++++++++++
> 1 files changed, 76 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/
> powerpc/platforms/86xx/mpc86xx_hpcn.c
> index a82da4b..83a2c28 100644
> --- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
> +++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
> @@ -318,6 +318,7 @@ static void __devinit quirk_uli5288(struct
> pci_dev *dev)
> static void __devinit quirk_uli5229(struct pci_dev *dev)
> {
> unsigned short temp;
> +
> pci_write_config_word(dev, 0x04, 0x0405);
> dev->class &= ~0x5;
> pci_read_config_word(dev, 0x4a, &temp);
> @@ -325,6 +326,75 @@ static void __devinit quirk_uli5229(struct
> pci_dev *dev)
> pci_write_config_word(dev, 0x4a, temp);
> }
>
> +static void __devinit quirk_mpc8641_transparent(struct pci_dev *dev)
> +{
Shouldn't we put this in fsl_pcie.c since it will be need by everyone
using an 85xx/86xx pci-e controller?
[snip]
> +}
- k
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 1/5] cell: pmi remove support for mutiple devices.
From: Christian Krafft @ 2007-06-22 14:10 UTC (permalink / raw)
To: Akinobu Mita; +Cc: linuxppc-dev@ozlabs.org, cbe-oss-dev@ozlabs.org
In-Reply-To: <20070621140731.GA24496@ps3linux.grid.fixstars.com>
[-- Attachment #1: Type: text/plain, Size: 980 bytes --]
Hi,
On Thu, 21 Jun 2007 23:07:31 +0900
Akinobu Mita <mita@fixstars.com> wrote:
> >
> > - kfree(dev->dev.driver_data);
> > + kfree(data);
>
> Shouldn't it set data = NULL here?
>
> I guess we will get "pmi: driver has already been initialized" message
> and -EBUSY on reloading pmi driver.
>
> >
> > return 0;
> > }
That problem did actually not occur.
Anyway, I added the line for completeness and consistency.
But while testing I found another bug that occurred when freeing the irq. The dev_id when requesting the irq was NULL,
but not when freeing the irq. I'm resending the patch as a reply to the first version.
--
Mit freundlichen Gruessen,
kind regards,
Christian Krafft
IBM Systems & Technology Group,
Linux Kernel Development
IT Specialist
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Herbert Kircher
Sitz der Gesellschaft: Boeblingen
Registriergericht: Amtsgericht Stuttgart, HRB 243294
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Split out asm-ppc/mmu.h portions for PowerPC 8xx
From: Scott Wood @ 2007-06-22 14:56 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070622045855.GA11775@localhost.localdomain>
On Fri, Jun 22, 2007 at 02:58:55PM +1000, David Gibson wrote:
> arch/powerpc still relies on asm-ppc/mmu.h for some 32-bit MMU types.
> This patch is another step towards fixing this. It takes the portions
> of asm-ppc/mmu.h related to 8xx embedded CPUs which are still relevant
> in arch/powerpc and puts them in a new asm-powerpc/mmu-8xx.h,
> included when appropriate from asm-powerpc/mmu.h.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>
> This applies on top of my earlier patch splitting out the Freescale
> Book-E portions of mmu.h. I've compiled this (with
> mpc866_ads_defconfig) but can someone with access to an 8xx system
> give it a whirl?
I tested it on an 885 board; it seems fine.
-Scott
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Vladislav Buzov @ 2007-06-22 15:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1182429443.24740.8.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
>On Fri, 2007-06-15 at 14:20 -0700, Mark A. Greer wrote:
>
>
>>On Fri, Jun 15, 2007 at 10:14:24AM +0200, Segher Boessenkool wrote:
>>
>>
>>
>>>>I've double checked this. All processors considered 7450 in the kernel
>>>>are covered by MPC7450 RISC Microprocessor Family Reference Manual
>>>>where hardware cache flushing procedure is described.
>>>>
>>>>
>>>Nice. Now all that remains to be done is for the patch to
>>>be tested on actual hardware for at least a few of those
>>>other CPUs. Any volunteers?
>>>
>>>
>>I just booted & played around on a prpmc2800e (7447A, 512MB) with
>>this patch and it seemed to work fine.
>>
>>I *may* have some old sandpoint 745x modules that still work but
>>I'll have to get the sandpoint working in arch/powerpc again.
>>I'll try to get to that in a week or so.
>>
>>
>
>The thing that needs torture is the powerbook sleep/wakeup code. That's
>where all the cache flushing issues have been biting in the past.
>
>Ben.
>
>
Note that 745x processors have L3 cache installed and may have the same
problem requiring similar code modifications to use L3 hardware flushing
mechanism.
So, my patch may not cure the cache flushing problem at all on such
processors.
Vlad.
>
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* Resend: [patch 1/5] cell: pmi remove support for mutiple devices.
From: Christian Krafft @ 2007-06-22 16:00 UTC (permalink / raw)
To: Christian Krafft; +Cc: linuxppc-dev@ozlabs.org, cbe-oss-dev@ozlabs.org
In-Reply-To: <20070621131644.03a8ec31@localhost>
[-- Attachment #1: Type: text/plain, Size: 8721 bytes --]
Subject: cell: pmi remove support for mutiple devices.
From: Christian Krafft <krafft@de.ibm.com>
The pmi driver got simplified by removing support for multiple devices.
As there is no more than one pmi device per maschine, there is no need to
specify the device for listening and sending messages.
This way the caller (cbe_cpufreq) doesn't need to scan the device tree.
When registering the handler on a board without a pmi
interface, pmi.c will just return -ENODEV.
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Index: linux-2.6.22-rc5/arch/powerpc/platforms/cell/cbe_cpufreq.c
===================================================================
--- linux-2.6.22-rc5.orig/arch/powerpc/platforms/cell/cbe_cpufreq.c
+++ linux-2.6.22-rc5/arch/powerpc/platforms/cell/cbe_cpufreq.c
@@ -68,12 +68,14 @@ static u64 MIC_Slow_Next_Timer_table[] =
};
static unsigned int pmi_frequency_limit = 0;
+
/*
* hardware specific functions
*/
-static struct of_device *pmi_dev;
+static bool cbe_cpufreq_has_pmi;
+#ifdef CONFIG_PPC_PMI
static int set_pmode_pmi(int cpu, unsigned int pmode)
{
int ret;
@@ -90,7 +92,7 @@ static int set_pmode_pmi(int cpu, unsign
time = (u64) get_cycles();
#endif
- pmi_send_message(pmi_dev, pmi_msg);
+ pmi_send_message(pmi_msg);
ret = pmi_msg.data2;
pr_debug("PMI returned slow mode %d\n", ret);
@@ -102,7 +104,7 @@ static int set_pmode_pmi(int cpu, unsign
#endif
return ret;
}
-
+#endif
static int get_pmode(int cpu)
{
@@ -156,14 +158,16 @@ static int set_pmode_reg(int cpu, unsign
return 0;
}
-static int set_pmode(int cpu, unsigned int slow_mode) {
- if (pmi_dev)
+static int set_pmode(int cpu, unsigned int slow_mode)
+{
+#ifdef CONFIG_PPC_PMI
+ if (cbe_cpufreq_has_pmi)
return set_pmode_pmi(cpu, slow_mode);
- else
- return set_pmode_reg(cpu, slow_mode);
+#endif
+ return set_pmode_reg(cpu, slow_mode);
}
-static void cbe_cpufreq_handle_pmi(struct of_device *dev, pmi_message_t pmi_msg)
+static void cbe_cpufreq_handle_pmi(pmi_message_t pmi_msg)
{
u8 cpu;
u8 cbe_pmode_new;
@@ -250,7 +254,7 @@ static int cbe_cpufreq_cpu_init(struct c
cpufreq_frequency_table_get_attr(cbe_freqs, policy->cpu);
- if (pmi_dev) {
+ if (cbe_cpufreq_has_pmi) {
/* frequency might get limited later, initialize limit with max_freq */
pmi_frequency_limit = max_freq;
cpufreq_register_notifier(&pmi_notifier_block, CPUFREQ_POLICY_NOTIFIER);
@@ -262,7 +266,7 @@ static int cbe_cpufreq_cpu_init(struct c
static int cbe_cpufreq_cpu_exit(struct cpufreq_policy *policy)
{
- if (pmi_dev)
+ if (cbe_cpufreq_has_pmi)
cpufreq_unregister_notifier(&pmi_notifier_block, CPUFREQ_POLICY_NOTIFIER);
cpufreq_frequency_table_put_attr(policy->cpu);
@@ -323,27 +327,20 @@ static struct cpufreq_driver cbe_cpufreq
static int __init cbe_cpufreq_init(void)
{
- struct device_node *np;
-
if (!machine_is(cell))
return -ENODEV;
- np = of_find_node_by_type(NULL, "ibm,pmi");
-
- pmi_dev = of_find_device_by_node(np);
-
- if (pmi_dev)
- pmi_register_handler(pmi_dev, &cbe_pmi_handler);
+ cbe_cpufreq_has_pmi = pmi_register_handler(&cbe_pmi_handler) == 0;
return cpufreq_register_driver(&cbe_cpufreq_driver);
}
static void __exit cbe_cpufreq_exit(void)
{
- if (pmi_dev)
- pmi_unregister_handler(pmi_dev, &cbe_pmi_handler);
-
cpufreq_unregister_driver(&cbe_cpufreq_driver);
+
+ if (cbe_cpufreq_has_pmi)
+ pmi_unregister_handler(&cbe_pmi_handler);
}
module_init(cbe_cpufreq_init);
Index: linux-2.6.22-rc5/arch/powerpc/sysdev/pmi.c
===================================================================
--- linux-2.6.22-rc5.orig/arch/powerpc/sysdev/pmi.c
+++ linux-2.6.22-rc5/arch/powerpc/sysdev/pmi.c
@@ -48,15 +48,13 @@ struct pmi_data {
struct work_struct work;
};
+static struct pmi_data *data;
static int pmi_irq_handler(int irq, void *dev_id)
{
- struct pmi_data *data;
u8 type;
int rc;
- data = dev_id;
-
spin_lock(&data->pmi_spinlock);
type = ioread8(data->pmi_reg + PMI_READ_TYPE);
@@ -111,16 +109,13 @@ MODULE_DEVICE_TABLE(of, pmi_match);
static void pmi_notify_handlers(struct work_struct *work)
{
- struct pmi_data *data;
struct pmi_handler *handler;
- data = container_of(work, struct pmi_data, work);
-
spin_lock(&data->handler_spinlock);
list_for_each_entry(handler, &data->handler, node) {
pr_debug(KERN_INFO "pmi: notifying handler %p\n", handler);
if (handler->type == data->msg.type)
- handler->handle_pmi_message(data->dev, data->msg);
+ handler->handle_pmi_message(data->msg);
}
spin_unlock(&data->handler_spinlock);
}
@@ -129,9 +124,14 @@ static int pmi_of_probe(struct of_device
const struct of_device_id *match)
{
struct device_node *np = dev->node;
- struct pmi_data *data;
int rc;
+ if (data) {
+ printk(KERN_ERR "pmi: driver has already been initialized.\n");
+ rc = -EBUSY;
+ goto out;
+ }
+
data = kzalloc(sizeof(struct pmi_data), GFP_KERNEL);
if (!data) {
printk(KERN_ERR "pmi: could not allocate memory.\n");
@@ -154,7 +154,6 @@ static int pmi_of_probe(struct of_device
INIT_WORK(&data->work, pmi_notify_handlers);
- dev->dev.driver_data = data;
data->dev = dev;
data->irq = irq_of_parse_and_map(np, 0);
@@ -164,7 +163,7 @@ static int pmi_of_probe(struct of_device
goto error_cleanup_iomap;
}
- rc = request_irq(data->irq, pmi_irq_handler, 0, "pmi", data);
+ rc = request_irq(data->irq, pmi_irq_handler, 0, "pmi", NULL);
if (rc) {
printk(KERN_ERR "pmi: can't request IRQ %d: returned %d\n",
data->irq, rc);
@@ -187,12 +186,9 @@ out:
static int pmi_of_remove(struct of_device *dev)
{
- struct pmi_data *data;
struct pmi_handler *handler, *tmp;
- data = dev->dev.driver_data;
-
- free_irq(data->irq, data);
+ free_irq(data->irq, NULL);
iounmap(data->pmi_reg);
spin_lock(&data->handler_spinlock);
@@ -202,7 +198,8 @@ static int pmi_of_remove(struct of_devic
spin_unlock(&data->handler_spinlock);
- kfree(dev->dev.driver_data);
+ kfree(data);
+ data = NULL;
return 0;
}
@@ -226,13 +223,13 @@ static void __exit pmi_module_exit(void)
}
module_exit(pmi_module_exit);
-void pmi_send_message(struct of_device *device, pmi_message_t msg)
+int pmi_send_message(pmi_message_t msg)
{
- struct pmi_data *data;
unsigned long flags;
DECLARE_COMPLETION_ONSTACK(completion);
- data = device->dev.driver_data;
+ if (!data)
+ return -ENODEV;
mutex_lock(&data->msg_mutex);
@@ -256,30 +253,26 @@ void pmi_send_message(struct of_device *
data->completion = NULL;
mutex_unlock(&data->msg_mutex);
+
+ return 0;
}
EXPORT_SYMBOL_GPL(pmi_send_message);
-void pmi_register_handler(struct of_device *device,
- struct pmi_handler *handler)
+int pmi_register_handler(struct pmi_handler *handler)
{
- struct pmi_data *data;
- data = device->dev.driver_data;
-
if (!data)
- return;
+ return -ENODEV;
spin_lock(&data->handler_spinlock);
list_add_tail(&handler->node, &data->handler);
spin_unlock(&data->handler_spinlock);
+
+ return 0;
}
EXPORT_SYMBOL_GPL(pmi_register_handler);
-void pmi_unregister_handler(struct of_device *device,
- struct pmi_handler *handler)
+void pmi_unregister_handler(struct pmi_handler *handler)
{
- struct pmi_data *data;
- data = device->dev.driver_data;
-
if (!data)
return;
Index: linux-2.6.22-rc5/include/asm-powerpc/pmi.h
===================================================================
--- linux-2.6.22-rc5.orig/include/asm-powerpc/pmi.h
+++ linux-2.6.22-rc5/include/asm-powerpc/pmi.h
@@ -55,13 +55,13 @@ typedef struct {
struct pmi_handler {
struct list_head node;
u8 type;
- void (*handle_pmi_message) (struct of_device *, pmi_message_t);
+ void (*handle_pmi_message) (pmi_message_t);
};
-void pmi_register_handler(struct of_device *, struct pmi_handler *);
-void pmi_unregister_handler(struct of_device *, struct pmi_handler *);
+int pmi_register_handler(struct pmi_handler *);
+void pmi_unregister_handler(struct pmi_handler *);
-void pmi_send_message(struct of_device *, pmi_message_t);
+int pmi_send_message(pmi_message_t);
#endif /* __KERNEL__ */
#endif /* _POWERPC_PMI_H */
--
Mit freundlichen Gruessen,
kind regards,
Christian Krafft
IBM Systems & Technology Group,
Linux Kernel Development
IT Specialist
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Herbert Kircher
Sitz der Gesellschaft: Boeblingen
Registriergericht: Amtsgericht Stuttgart, HRB 243294
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v2 9/9] Created quirk_mpc8641_transparent() to initialize bridge resources.
From: Jon Loeliger @ 2007-06-22 16:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, Wei Zhang
In-Reply-To: <062E6779-8D69-4700-896C-FE06A5F8947E@kernel.crashing.org>
On Fri, 2007-06-22 at 08:50, Kumar Gala wrote:
> Shouldn't we put this in fsl_pcie.c since it will be need by everyone
> using an 85xx/86xx pci-e controller?
> - k
IIRC, Ww are trying to eliminate the need for fsl_pcie.c
and converge on the more generic code instead.
If we can ever get the PCI-E patches accepted, the
8641 boards won't use the fsl_pcie.c file at all. :-)
jdl
^ permalink raw reply
* Re: [PATCH v2 9/9] Created quirk_mpc8641_transparent() to initialize bridge resources.
From: Kumar Gala @ 2007-06-22 16:35 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org list, Wei Zhang
In-Reply-To: <1182529202.29873.7.camel@ld0161-tx32>
On Jun 22, 2007, at 11:20 AM, Jon Loeliger wrote:
> On Fri, 2007-06-22 at 08:50, Kumar Gala wrote:
>
>> Shouldn't we put this in fsl_pcie.c since it will be need by everyone
>> using an 85xx/86xx pci-e controller?
>
>> - k
>
> IIRC, Ww are trying to eliminate the need for fsl_pcie.c
> and converge on the more generic code instead.
> If we can ever get the PCI-E patches accepted, the
> 8641 boards won't use the fsl_pcie.c file at all. :-)
Where do we plan on putting the freescale generic pci code?
- k
^ permalink raw reply
* [PATCH v2] [2.6.23] edac: pasemi_edac backend driver
From: Olof Johansson @ 2007-06-22 17:11 UTC (permalink / raw)
To: norsk5; +Cc: linuxppc-dev, egor, bluesmoke-devel
In-Reply-To: <20070425204309.GA19781@lixom.net>
EDAC driver for the memory controllers on PA Semi PA6T-1682M.
Signed-off-by: Egor Martovetsky <egor@pasemi.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
---
Changes since last submission:
* Rebased on top of 2.6.22-rc4-mm2 with the EDAC changes merged there.
* Minor checkpatch.pl cleanups
* Renamed ctl_name
* Added dev_name
* edac_mc.h -> edac_core.h
Index: mm/drivers/edac/pasemi_edac.c
===================================================================
--- /dev/null
+++ mm/drivers/edac/pasemi_edac.c
@@ -0,0 +1,298 @@
+/*
+ * Copyright (C) 2006-2007 PA Semi, Inc
+ *
+ * Author: Egor Martovetsky <egor@pasemi.com>
+ * Maintained by: Olof Johansson <olof@lixom.net>
+ *
+ * Driver for the PWRficient onchip memory controllers
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/pci.h>
+#include <linux/pci_ids.h>
+#include <linux/slab.h>
+#include "edac_core.h"
+
+#define MODULE_NAME "pasemi_edac"
+
+#define MCCFG_MCEN 0x300
+#define MCCFG_MCEN_MMC_EN 0x00000001
+#define MCCFG_ERRCOR 0x388
+#define MCCFG_ERRCOR_RNK_FAIL_DET_EN 0x00000100
+#define MCCFG_ERRCOR_ECC_GEN_EN 0x00000010
+#define MCCFG_ERRCOR_ECC_CRR_EN 0x00000001
+#define MCCFG_SCRUB 0x384
+#define MCCFG_SCRUB_RGLR_SCRB_EN 0x00000001
+#define MCDEBUG_ERRCTL1 0x728
+#define MCDEBUG_ERRCTL1_RFL_LOG_EN 0x00080000
+#define MCDEBUG_ERRCTL1_MBE_LOG_EN 0x00040000
+#define MCDEBUG_ERRCTL1_SBE_LOG_EN 0x00020000
+#define MCDEBUG_ERRSTA 0x730
+#define MCDEBUG_ERRSTA_RFL_STATUS 0x00000004
+#define MCDEBUG_ERRSTA_MBE_STATUS 0x00000002
+#define MCDEBUG_ERRSTA_SBE_STATUS 0x00000001
+#define MCDEBUG_ERRCNT1 0x734
+#define MCDEBUG_ERRCNT1_SBE_CNT_OVRFLO 0x00000080
+#define MCDEBUG_ERRLOG1A 0x738
+#define MCDEBUG_ERRLOG1A_MERR_TYPE_M 0x30000000
+#define MCDEBUG_ERRLOG1A_MERR_TYPE_NONE 0x00000000
+#define MCDEBUG_ERRLOG1A_MERR_TYPE_SBE 0x10000000
+#define MCDEBUG_ERRLOG1A_MERR_TYPE_MBE 0x20000000
+#define MCDEBUG_ERRLOG1A_MERR_TYPE_RFL 0x30000000
+#define MCDEBUG_ERRLOG1A_MERR_BA_M 0x00700000
+#define MCDEBUG_ERRLOG1A_MERR_BA_S 20
+#define MCDEBUG_ERRLOG1A_MERR_CS_M 0x00070000
+#define MCDEBUG_ERRLOG1A_MERR_CS_S 16
+#define MCDEBUG_ERRLOG1A_SYNDROME_M 0x0000ffff
+#define MCDRAM_RANKCFG 0x114
+#define MCDRAM_RANKCFG_EN 0x00000001
+#define MCDRAM_RANKCFG_TYPE_SIZE_M 0x000001c0
+#define MCDRAM_RANKCFG_TYPE_SIZE_S 6
+
+#define PASEMI_EDAC_NR_CSROWS 8
+#define PASEMI_EDAC_NR_CHANS 1
+#define PASEMI_EDAC_ERROR_GRAIN 64
+
+static int last_page_in_mmc;
+static int system_mmc_id;
+
+
+static u32 pasemi_edac_get_error_info(struct mem_ctl_info *mci)
+{
+ struct pci_dev *pdev = to_pci_dev(mci->dev);
+ u32 tmp;
+
+ pci_read_config_dword(pdev, MCDEBUG_ERRSTA,
+ &tmp);
+
+ tmp &= (MCDEBUG_ERRSTA_RFL_STATUS | MCDEBUG_ERRSTA_MBE_STATUS
+ | MCDEBUG_ERRSTA_SBE_STATUS);
+
+ if (tmp) {
+ if (tmp & MCDEBUG_ERRSTA_SBE_STATUS)
+ pci_write_config_dword(pdev, MCDEBUG_ERRCNT1,
+ MCDEBUG_ERRCNT1_SBE_CNT_OVRFLO);
+ pci_write_config_dword(pdev, MCDEBUG_ERRSTA, tmp);
+ }
+
+ return tmp;
+}
+
+static void pasemi_edac_process_error_info(struct mem_ctl_info *mci, u32 errsta)
+{
+ struct pci_dev *pdev = to_pci_dev(mci->dev);
+ u32 errlog1a;
+ u32 cs;
+
+ if (!errsta)
+ return;
+
+ pci_read_config_dword(pdev, MCDEBUG_ERRLOG1A, &errlog1a);
+
+ cs = (errlog1a & MCDEBUG_ERRLOG1A_MERR_CS_M) >>
+ MCDEBUG_ERRLOG1A_MERR_CS_S;
+
+ /* uncorrectable/multi-bit errors */
+ if (errsta & (MCDEBUG_ERRSTA_MBE_STATUS |
+ MCDEBUG_ERRSTA_RFL_STATUS)) {
+ edac_mc_handle_ue(mci, mci->csrows[cs].first_page, 0,
+ cs, mci->ctl_name);
+ }
+
+ /* correctable/single-bit errors */
+ if (errsta & MCDEBUG_ERRSTA_SBE_STATUS) {
+ edac_mc_handle_ce(mci, mci->csrows[cs].first_page, 0,
+ 0, cs, 0, mci->ctl_name);
+ }
+}
+
+static void pasemi_edac_check(struct mem_ctl_info *mci)
+{
+ u32 errsta;
+
+ errsta = pasemi_edac_get_error_info(mci);
+ if (errsta)
+ pasemi_edac_process_error_info(mci, errsta);
+}
+
+static int pasemi_edac_init_csrows(struct mem_ctl_info *mci,
+ struct pci_dev *pdev,
+ enum edac_type edac_mode)
+{
+ struct csrow_info *csrow;
+ u32 rankcfg;
+ int index;
+
+ for (index = 0; index < mci->nr_csrows; index++) {
+ csrow = &mci->csrows[index];
+
+ pci_read_config_dword(pdev,
+ MCDRAM_RANKCFG + (index * 12),
+ &rankcfg);
+
+ if (!(rankcfg & MCDRAM_RANKCFG_EN))
+ continue;
+
+ switch ((rankcfg & MCDRAM_RANKCFG_TYPE_SIZE_M) >>
+ MCDRAM_RANKCFG_TYPE_SIZE_S) {
+ case 0:
+ csrow->nr_pages = 128 << (20 - PAGE_SHIFT);
+ break;
+ case 1:
+ csrow->nr_pages = 256 << (20 - PAGE_SHIFT);
+ break;
+ case 2:
+ case 3:
+ csrow->nr_pages = 512 << (20 - PAGE_SHIFT);
+ break;
+ case 4:
+ csrow->nr_pages = 1024 << (20 - PAGE_SHIFT);
+ break;
+ case 5:
+ csrow->nr_pages = 2048 << (20 - PAGE_SHIFT);
+ break;
+ default:
+ edac_mc_printk(mci, KERN_ERR,
+ "Unrecognized Rank Config\n");
+ return -EINVAL;
+ }
+
+ csrow->first_page = last_page_in_mmc;
+ csrow->last_page = csrow->first_page + csrow->nr_pages - 1;
+ last_page_in_mmc += csrow->nr_pages;
+ csrow->page_mask = 0;
+ csrow->grain = PASEMI_EDAC_ERROR_GRAIN;
+ csrow->mtype = MEM_DDR;
+ csrow->dtype = DEV_UNKNOWN;
+ csrow->edac_mode = edac_mode;
+ }
+ return 0;
+}
+
+static int __devinit pasemi_edac_probe(struct pci_dev *pdev,
+ const struct pci_device_id *ent)
+{
+ struct mem_ctl_info *mci = NULL;
+ u32 errctl1, errcor, scrub, mcen;
+
+ pci_read_config_dword(pdev, MCCFG_MCEN, &mcen);
+ if (!(mcen & MCCFG_MCEN_MMC_EN))
+ return -ENODEV;
+
+ /*
+ * We should think about enabling other error detection later on
+ */
+
+ pci_read_config_dword(pdev, MCDEBUG_ERRCTL1, &errctl1);
+ errctl1 |= MCDEBUG_ERRCTL1_SBE_LOG_EN |
+ MCDEBUG_ERRCTL1_MBE_LOG_EN |
+ MCDEBUG_ERRCTL1_RFL_LOG_EN;
+ pci_write_config_dword(pdev, MCDEBUG_ERRCTL1, errctl1);
+
+ mci = edac_mc_alloc(0, PASEMI_EDAC_NR_CSROWS, PASEMI_EDAC_NR_CHANS);
+
+ if (mci == NULL)
+ return -ENOMEM;
+
+ pci_read_config_dword(pdev, MCCFG_ERRCOR, &errcor);
+ errcor |= MCCFG_ERRCOR_RNK_FAIL_DET_EN |
+ MCCFG_ERRCOR_ECC_GEN_EN |
+ MCCFG_ERRCOR_ECC_CRR_EN;
+
+ mci->dev = &pdev->dev;
+ mci->mtype_cap = MEM_FLAG_DDR | MEM_FLAG_RDDR;
+ mci->edac_ctl_cap = EDAC_FLAG_NONE | EDAC_FLAG_EC | EDAC_FLAG_SECDED;
+ mci->edac_cap = (errcor & MCCFG_ERRCOR_ECC_GEN_EN) ?
+ ((errcor & MCCFG_ERRCOR_ECC_CRR_EN) ?
+ (EDAC_FLAG_EC | EDAC_FLAG_SECDED) : EDAC_FLAG_EC) :
+ EDAC_FLAG_NONE;
+ mci->mod_name = MODULE_NAME;
+ mci->dev_name = pci_name(pdev);
+ mci->ctl_name = "pasemi,1682m-mc";
+ mci->edac_check = pasemi_edac_check;
+ mci->ctl_page_to_phys = NULL;
+ pci_read_config_dword(pdev, MCCFG_SCRUB, &scrub);
+ mci->scrub_cap = SCRUB_FLAG_HW_PROG | SCRUB_FLAG_HW_SRC;
+ mci->scrub_mode =
+ ((errcor & MCCFG_ERRCOR_ECC_CRR_EN) ? SCRUB_FLAG_HW_SRC : 0) |
+ ((scrub & MCCFG_SCRUB_RGLR_SCRB_EN) ? SCRUB_FLAG_HW_PROG : 0);
+
+ if (pasemi_edac_init_csrows(mci, pdev,
+ (mci->edac_cap & EDAC_FLAG_SECDED) ?
+ EDAC_SECDED :
+ ((mci->edac_cap & EDAC_FLAG_EC) ?
+ EDAC_EC : EDAC_NONE)))
+ goto fail;
+
+ /*
+ * Clear status
+ */
+ pasemi_edac_get_error_info(mci);
+
+ if (edac_mc_add_mc(mci, system_mmc_id++)) {
+ goto fail;
+ }
+
+ /* get this far and it's successful */
+ return 0;
+
+fail:
+ edac_mc_free(mci);
+ return -ENODEV;
+}
+
+static void __devexit pasemi_edac_remove(struct pci_dev *pdev)
+{
+ struct mem_ctl_info *mci = edac_mc_del_mc(&pdev->dev);
+
+ if (!mci)
+ return;
+
+ edac_mc_free(mci);
+}
+
+
+static const struct pci_device_id pasemi_edac_pci_tbl[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_PASEMI, 0xa00a) },
+};
+
+MODULE_DEVICE_TABLE(pci, pasemi_edac_pci_tbl);
+
+static struct pci_driver pasemi_edac_driver = {
+ .name = MODULE_NAME,
+ .probe = pasemi_edac_probe,
+ .remove = __devexit_p(pasemi_edac_remove),
+ .id_table = pasemi_edac_pci_tbl,
+};
+
+static int __init pasemi_edac_init(void)
+{
+ return pci_register_driver(&pasemi_edac_driver);
+}
+
+static void __exit pasemi_edac_exit(void)
+{
+ pci_unregister_driver(&pasemi_edac_driver);
+}
+
+module_init(pasemi_edac_init);
+module_exit(pasemi_edac_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Egor Martovetsky <egor@pasemi.com>");
+MODULE_DESCRIPTION("MC support for PA Semi PA6T-1682M memory controller");
Index: mm/drivers/edac/Kconfig
===================================================================
--- mm.orig/drivers/edac/Kconfig
+++ mm/drivers/edac/Kconfig
@@ -9,7 +9,7 @@
menuconfig EDAC
tristate "EDAC - error detection and reporting (EXPERIMENTAL)"
depends on HAS_IOMEM
- depends on X86 && EXPERIMENTAL
+ depends on (X86 || PPC) && EXPERIMENTAL
help
EDAC is designed to report errors in the core system.
These are low-level errors that are reported in the CPU or
@@ -116,4 +116,12 @@ config EDAC_I5000
Support for error detection and correction the Intel
Greekcreek/Blackford chipsets.
+config EDAC_PASEMI
+ tristate "PA Semi PWRficient"
+ depends on EDAC_MM_EDAC && PCI
+ help
+ Support for error detection and correction on PA Semi
+ PWRficient.
+
+
endif # EDAC
Index: mm/drivers/edac/Makefile
===================================================================
--- mm.orig/drivers/edac/Makefile
+++ mm/drivers/edac/Makefile
@@ -26,4 +26,5 @@ obj-$(CONFIG_EDAC_I82875P) += i82875p_e
obj-$(CONFIG_EDAC_I3000) += i3000_edac.o
obj-$(CONFIG_EDAC_I82860) += i82860_edac.o
obj-$(CONFIG_EDAC_R82600) += r82600_edac.o
+obj-$(CONFIG_EDAC_PASEMI) += pasemi_edac.o
^ permalink raw reply
* Re: version control for dts/dtb?
From: Jon Loeliger @ 2007-06-22 17:24 UTC (permalink / raw)
To: marty; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <000301c7b03e$0e2a42a0$9700a8c0@hplaptop>
On Sat, 2007-06-16 at 12:44, marty wrote:
> Is there a wy to figure out the version of the dtb file I'm using?
> At a minimum, it would be useful to have a node with the conversion time
> stuck somewhere...
>
> I ran dtc to convert binary to source, but that isn't necessarily what I
> wanted to look at -- just a single date
> code would be sufficient...
>
> marty
There is currently no direct version stamp in the
DTS or DTB files. You may be able to derive some
knowledge by running a DTB file through the DTC
with the input file as "dtb" and looking at an
output file of DTS, though. That is, "-I dtb -O dts"
and looking at it.
HTH,
jdl
^ permalink raw reply
* [patch] powerpc: sysfs fix compiler warning
From: Christian Krafft @ 2007-06-22 17:48 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]
From: Christian Krafft <krafft@de.ibm.com>
This patch fixes the following compiler warning:
arch/powerpc/kernel/sysfs.c:385: warning: ignoring return value of
`sysfs_create_group',
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Index: linux-2.6.22-rc5/arch/powerpc/kernel/sysfs.c
===================================================================
--- linux-2.6.22-rc5.orig/arch/powerpc/kernel/sysfs.c
+++ linux-2.6.22-rc5/arch/powerpc/kernel/sysfs.c
@@ -380,16 +380,23 @@ int cpu_add_sysdev_attr_group(struct att
{
int cpu;
struct sys_device *sysdev;
+ int error;
mutex_lock(&cpu_mutex);
for_each_possible_cpu(cpu) {
sysdev = get_cpu_sysdev(cpu);
- sysfs_create_group(&sysdev->kobj, attrs);
+ error |= sysfs_create_group(&sysdev->kobj, attrs);
}
+ if(error)
+ for_each_possible_cpu(cpu) {
+ sysdev = get_cpu_sysdev(cpu);
+ sysfs_remove_group(&sysdev->kobj, attrs);
+ }
+
mutex_unlock(&cpu_mutex);
- return 0;
+ return error;
}
EXPORT_SYMBOL_GPL(cpu_add_sysdev_attr_group);
--
Mit freundlichen Gruessen,
kind regards,
Christian Krafft
IBM Systems & Technology Group,
Linux Kernel Development
IT Specialist
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Herbert Kircher
Sitz der Gesellschaft: Boeblingen
Registriergericht: Amtsgericht Stuttgart, HRB 243294
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Follow up on 4 Gig of DDR on MPC8548E
From: Morrison, Tom @ 2007-06-22 17:49 UTC (permalink / raw)
To: linuxppc-dev, ltib, linuxppc-embedded
In-Reply-To: <mailman.1956.1182519826.2671.linuxppc-dev@ozlabs.org>
All,
We are running into a very strange problem that I=20
am hoping someone here might have some insight upon.
Setup:
1) 4 Gig of DDR RAM (at physical addresses 0-0xF_FFFF_FFFF)
2) LTIB/Linux Kernel (2.6.11++) - I know we are behind the
times, but it was too risky to go with latest/greatest.
3) U-boot passes a Max MEM of 3 GIG to the kernel at boot...
But, we are using on the bootcmd =3D=3D> mem=3D2 GIG + a few pages
Symptoms:
a) Kernel boots - but fails / and hangs when it attempts to=20
open the initial console:
>> EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
>> VFS: Mounted root (ext2 filesystem).
>> 316k init
>> EXT2-fs error (device sda1): ext2_check_page: bad entry in directory
#2: >> unaligned directory entry - offset=3D0, inode=3D128,
rec_len=3D8961,name_len=3D69
>> Warning: unable to open an initial console.
--- a little debugging indicates that it is trying to open the ----
--- /dev/console device - and one of first physical pages allocated ----
--- is above the 2 GIG boundary (0x80000000) ----
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dfurther =
tests=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
b) if we pass a 'mem=3D2GIG' or less (even though 4 GIG of DDR) -=20
it works correctly, and we boot up normally...
d) Further, If we do #b, and ioremap a physical address=20
above the 2GIG and read/write those addresses - it works.....
=3D=3D> This tells me the memory is working...
My gut tells me this might be something to do with the 2=20
Gig boundary and specifically a "signed" versus "unsigned"=20
address/offsets mismatch maybe somewhere in the file system??
We are debugging this - but it is painful and slow process=20
to narrow the root problem - I am hoping somebody around=20
here has some knowledge of this type of failure and can help us!
All the Best~!
Tom Morrison
Principal S/W Engineer
Empirix, Inc (www.empirix.com)
tmorrison@empirix.com
(781) 266 - 3567
^ permalink raw reply
* Memory coherency on MPC8272
From: Dmitri Petchkine @ 2007-06-22 17:28 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I am working on a user-space application interacting with the security
engine on MPC8272, which runs Linux 2.6.10_mvl401 (Montavista Pro
4.0.1). The driver (version 1.2 22-Feb-2006) for the security engine is
written by Freescale.
The application calls the driver through ioctl() to perform a crypto
operation. It is non-blocking call, so the app sits and waits for the
result when it becomes available. Once the driver notifies the app via a
signal, the latter does another ioctl() to get the result back to the
user space from the kernel-space.
Sometimes the returned buffer is just all zeroes which is incorrect.
Here is the piece of code in the driver which copies the data back to
the user space:
sec1_ioctl.c:
int SEC1_ioctl(struct inode *nd,
struct file *fil,
unsigned int ioctlCode,
unsigned long param)
{
...
case IOCTL_COPYTO:
mem = (MALLOC_REQ *)param;
mem->pid = current->pid;
copy_to_user(mem->to, mem->from, mem->sz);
status = SEC1_SUCCESS;
break;
...
}
The definition of MALLOC_REQ (file Sec1.h):
typedef struct
{
unsigned long sz; /* Number of bytes to allocate
Zero means to use the default. A value
of zero can be used to avoid fragmentation. */
void *ptr; /* Pointer to the adress that is to
be returned by a call to KernelMalloc()
or a pointer to an address that is to
be freed when calling KernelFree() */
char *to; /* copy to pointer */
char *from; /* copy from pointer*/
int pid; /* pid of requestor */
} MALLOC_REQ;
The problem goes away if I add printing of some buffer (it can be
mem->to or mem->from, or even another, unrelated buffer) AFTER the call
to copy_to_user(), i.e.:
case IOCTL_COPYTO:
{ char garbage[128]; /* new line */
mem = (MALLOC_REQ *)param;
mem->pid = current->pid;
copy_to_user(mem->to, mem->from, mem->sz);
PRINT_HEX( garbage, 128 ); /* new line */
status = SEC1_SUCCESS;
break;
}
My understanding that the security hardware of MPC8272 uses DMA to write
results into the memory which may cause a coherency problem.
My exposure to such hardware issues is very limited, so I appreciate any
advice on how to fix it.
Thanks in advance,
Dmitri Pechkin
^ permalink raw reply
* RE: version control for dts/dtb?
From: Leisner, Martin @ 2007-06-22 18:08 UTC (permalink / raw)
To: Jon Loeliger, marty; +Cc: Lund, Nathan, linuxppc-embedded
In-Reply-To: <1182533095.29873.30.camel@ld0161-tx32>
I made a node "revision" which was tied into rcs...
...
compatible =3D "mpc74xx";
revision =3D "$Revision: 1.7 $";
#address-cells =3D <1>;
#size-cells =3D <1>;
linux,phandle =3D <100>;
...
This seems to do what I wanted, I can then see in /proc/device-tree what
dts I'm running...
marty
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+martin.leisner=3Dxerox.com@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces+martin.leisner=3Dxerox.com@ozl
> abs.org] On Behalf Of Jon Loeliger
> Sent: Friday, June 22, 2007 1:25 PM
> To: marty
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: version control for dts/dtb?
>=20
> On Sat, 2007-06-16 at 12:44, marty wrote:
> > Is there a wy to figure out the version of the dtb file I'm using?
> > At a minimum, it would be useful to have a node with the=20
> conversion time=20
> > stuck somewhere...
> >=20
> > I ran dtc to convert binary to source, but that isn't=20
> necessarily what I=20
> > wanted to look at -- just a single date
> > code would be sufficient...
> >=20
> > marty
>=20
>=20
> There is currently no direct version stamp in the
> DTS or DTB files. You may be able to derive some
> knowledge by running a DTB file through the DTC
> with the input file as "dtb" and looking at an
> output file of DTS, though. That is, "-I dtb -O dts"
> and looking at it.
>=20
> HTH,
> jdl
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ permalink raw reply
* Re: [patch] powerpc: sysfs fix compiler warning
From: Josh Boyer @ 2007-06-22 18:38 UTC (permalink / raw)
To: Christian Krafft; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20070622194853.72fb652a@localhost>
On Fri, 2007-06-22 at 19:48 +0200, Christian Krafft wrote:
> From: Christian Krafft <krafft@de.ibm.com>
>
> This patch fixes the following compiler warning:
> arch/powerpc/kernel/sysfs.c:385: warning: ignoring return value of
> `sysfs_create_group',
>
> Signed-off-by: Christian Krafft <krafft@de.ibm.com>
>
> Index: linux-2.6.22-rc5/arch/powerpc/kernel/sysfs.c
> ===================================================================
> --- linux-2.6.22-rc5.orig/arch/powerpc/kernel/sysfs.c
> +++ linux-2.6.22-rc5/arch/powerpc/kernel/sysfs.c
> @@ -380,16 +380,23 @@ int cpu_add_sysdev_attr_group(struct att
> {
> int cpu;
> struct sys_device *sysdev;
> + int error;
>
> mutex_lock(&cpu_mutex);
>
> for_each_possible_cpu(cpu) {
> sysdev = get_cpu_sysdev(cpu);
> - sysfs_create_group(&sysdev->kobj, attrs);
> + error |= sysfs_create_group(&sysdev->kobj, attrs);
Why are you or'ing the return value with whatever is in the
uninitialized variable?
josh
^ permalink raw reply
* Re: [patch] powerpc: sysfs fix compiler warning
From: Sergei Shtylyov @ 2007-06-22 18:57 UTC (permalink / raw)
To: Christian Krafft; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1182537519.1554.14.camel@weaponx.rchland.ibm.com>
Hello.
Josh Boyer wrote:
>>From: Christian Krafft <krafft@de.ibm.com>
>>This patch fixes the following compiler warning:
>>arch/powerpc/kernel/sysfs.c:385: warning: ignoring return value of
>>`sysfs_create_group',
>>Signed-off-by: Christian Krafft <krafft@de.ibm.com>
>>Index: linux-2.6.22-rc5/arch/powerpc/kernel/sysfs.c
>>===================================================================
>>--- linux-2.6.22-rc5.orig/arch/powerpc/kernel/sysfs.c
>>+++ linux-2.6.22-rc5/arch/powerpc/kernel/sysfs.c
>>@@ -380,16 +380,23 @@ int cpu_add_sysdev_attr_group(struct att
>> {
>> int cpu;
>> struct sys_device *sysdev;
>>+ int error;
>>
>> mutex_lock(&cpu_mutex);
>>
>> for_each_possible_cpu(cpu) {
>> sysdev = get_cpu_sysdev(cpu);
>>- sysfs_create_group(&sysdev->kobj, attrs);
>>+ error |= sysfs_create_group(&sysdev->kobj, attrs);
>
>
> Why are you or'ing the return value with whatever is in the
> uninitialized variable?
To make it always fail, no doubt. ;-)
ISO accumulation error, it makes more sense to start cleanup created
groups right after the first creation failure -- although with the callers opf
this function ignoring the result anyway, who cares. :-)
> josh
WBR, Sergei
^ permalink raw reply
* Re: Virtex 4 Avnet Mini-Module Networking.
From: Glenn.G.Hart @ 2007-06-22 19:02 UTC (permalink / raw)
To: linuxppc-embedded
Has anybody or know of anybody that has got the ethernet to work on the=
Avnet V4 Mini-Module with Linux?
My closest came with EDK 8.2iSP3 and Linux 2.6.19. I was able to ping =
the
computers on the network, but I could not fully trasnfer data. Capturn=
ing
the packets using Ethereal showed the TCP checksum was incorrect while =
the
IP checksum was correct. I has a lot of trouble get the DMA to attempt=
to
run with thei statement.
I have now tried upgrading to EDK 9.1iSP2 and Linux-2.6.21 from Grant's=
git
server. Now I do not see any packets using thernet evrything else seem=
s
the same. When I try to ping another computer, I see activity on the
switch, but no packets are transmitted. Samething happens using FIFO o=
r
DMA Below is the kernel output when booting.
[ 4.186714] XTemac: using sgDMA mode.
[ 4.230800] XTemac: using TxDRE mode
[ 4.273829] XTemac: using RxDRE mode
[ 4.316805] XTemac: buffer descriptor size: 32768 (0x8000)
[ 4.383980] XTemac: (buffer_descriptor_init) phy: 0x5c8000, virt:
0xff100000, size: 0x8000
[ 4.494600] eth%d: XTemac: PHY detected at address 4.
[ 4.557994] eth0: Xilinx TEMAC #0 at 0x81200000 mapped to 0xC5000000=
,
irq=3D0
[ 4.641808] eth0: XTemac id 1.0f, block id 5, type 8
[ 4.703065] mice: PS/2 mouse device common for all mice
[ 4.766425] TCP cubic registered
[ 4.805581] NET: Registered protocol family 1
[ 4.858089] NET: Registered protocol family 17
[ 4.914484] RAMDISK: Compressed image found at block 0
[ 7.190462] VFS: Mounted root (ext2 filesystem).
[ 7.246742] Freeing unused kernel memory: 92k init
[ 7.445413] eth0: XTemac: Options: 0xb8f2
[ 12.986126] eth0: XTemac: We renegotiated the speed to: 1000
[ 13.054001] eth0: XTemac: speed set to 1000Mb/s
[ 13.120469] eth0: XTemac: Send Threshold =3D 16, Receive Threshold =3D=
2
[ 13.212064] eth0: XTemac: Send Wait bound =3D 1, Receive Wait bound =
=3D 1
Any ideas/comments. It would be great to hear from somebody that this =
has
a chance of working because you got it wokrking.
Thanks,
Glenn
Mohammad Sadegh Sadri wrote:
>
> very interesting
>
> the provided xps project from xapp941 results 230Mbits but your custo=
me
system is 83.0Mbits, yes?
yes
> just, are you sure the ppc core has the same core clock frequency in =
both
designs? I mean may be the xapp941 is running at 300MHz but yours at
100MHz.
both run at 300MHz
> And what about a custom system with 9.1SP2? does that gives the same
performance?
haven't tried this yet
> Finally If possible please release the test results for TCP streams. =
(
9.1 no SP and 9.1 SP2 )
The TEMAC driver is from EDK 9.1.02 (IOW, SP2).
bitstream made by myself with EDK 9.1.00:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
root@192.168.119.11:~/netperf-2.4.1/src# ./netperf -l 30 -H 192.168.119=
.1
-i 10, 2 -I 99,10 -t TCP_STREAM -- -m 32768 -s 262144
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.119.1
(192.168.119.1) port 0 AF_INET : =B15.0% @ 99% conf.
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 217088 32768 30.00 41.66
bitstream from XAPP941:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
root@192.168.119.11:~/netperf-2.4.1/src# ./netperf -l 30 -H 192.168.119=
.1
-i 10, 2 -I 99,10 -t TCP_STREAM -- -m 32768 -s 262144
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.119.1
(192.168.119.1) port 0 AF_INET : =B15.0% @ 99% conf.
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 217088 32768 30.00 111.86
And I didn't test ML405 receive performance.
Thanks,
Andrei
> thanks
>
>
>
> ----------------------------------------
>> Date: Thu, 21 Jun 2007 18:53:49 +0400
>> From: akonovalov@ru.mvista.com
>> To: mamsadegh@hotmail.com
>> CC: linuxppc-embedded@ozlabs.org; kashiwagi@co-nss.co.jp;
glenn.g.hart@us.westinghouse.com
>> Subject: Re: Virtex 4 Avnet Mini-Module Networking.
>>
>> Mohammad Sadegh Sadri wrote:
>>> I'm wondering where are the original developers of TEMAC driver the=
se
days, I have not seen any posts from any of andrei
>>> nor grant in the recent weeks. may be they are involved in other
projects.
>> As for me - no, not until the end of this week..
>>
>> I am puzzled with the following:
>>
>> I've got ML405 recently. There is a prebuilt bitstream with TEMAC in=
SGDMA mode for this board made by Xilinx (XAPP941).
>> With the TEMAC driver from EDK 9.1SP2 and the XAPP941 bitstream I've=
got
(no jumbo frames):
>>
>> XTemac: using sgDMA mode.
>> XTemac: using TxDRE mode
>> XTemac: using RxDRE mode
>> XTemac: buffer descriptor size: 32768 (0x8000)
>> XTemac: (buffer_descriptor_init) phy: 0x3cf8000, virt: 0xff100000=
,
size: 0x8000
>> eth%d: XTemac: PHY detected at address 7.
>> eth0: Xilinx TEMAC #0 at 0x80000000 mapped to 0xC5060000, irq=3D0=
>> eth0: XTemac id 1.0f, block id 5, type 8
>>
>> eth0: XTemac: Options: 0xb8f2
>> eth0: XTemac: We renegotiated the speed to: 1000
>> eth0: XTemac: speed set to 1000Mb/s
>> eth0: XTemac: Send Threshold =3D 16, Receive Threshold =3D 2
>> eth0: XTemac: Send Wait bound =3D 1, Receive Wait bound =3D 1
>>
>> root@192.168.119.11:~/netperf-2.4.1/src# ./netperf -l 30 -H
192.168.119.1 -i 10,
>> 2 -I 99,10 -t UDP_STREAM -- -m 32768 -s 262144
>> UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INE=
T to
192.168.11
>> 9.1 (192.168.119.1) port 0 AF_INET : =B15.0% @ 99% conf.
>> Socket Message Elapsed Messages
>> Size Size Time Okay Errors Throughput
>> bytes bytes secs # # 10^6bits/sec
>>
>> 217088 32768 30.00 26391 0 230.60
>> 107520 30.00 26377 230.48
>>
>> Not that bad for this setup.
>>
>> With xps (EDK 9.1 without any SPs) I've tried creating exact the sam=
e
design.
>> So that exact the same kernel etc could be used for the both bitstre=
ams.
>> And with the self-made one I see exact the same output with the only=
difference:
>>
>> root@192.168.119.11:~/netperf-2.4.1/src# ./netperf -l 30 -H
192.168.119.1 -i 10,
>> 2 -I 99,10 -t UDP_STREAM -- -m 32768 -s 262144
>> UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INE=
T to
192.168.11
>> 9.1 (192.168.119.1) port 0 AF_INET : =B15.0% @ 99% conf.
>> Socket Message Elapsed Messages
>> Size Size Time Okay Errors Throughput
>> bytes bytes secs # # 10^6bits/sec
>>
>> 217088 32768 30.00 9593 0 83.82
>> 107520 30.00 9586 83.76
>>
>> :o(
>>
>> Rebuilding the XAPP941 project with EDK 9.1.00 still leaves 230Mb/se=
c.
>> I also pulled the additional timing constraints from XAPP941's
data/system.ucf
>> into the self-made data/system.ucf, but this haven't change anything=
.
>>
>> I've run out of ideas, and switched from TEMAC to other Xilinx stuff=
for
a while.
>>
>>
>> Thanks,
>> Andrei
>
> _________________________________________________________________
> Connect to the next generation of MSN Messenger
>
http://imagine-msn.com/messenger/launch80/default.aspx?locale=3Den-us&s=
ource=3Dwlmailtagline
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
=
^ 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