* Re: Freescale SEC driver with cryptoloop on MPC8567e
From: Kim Phillips @ 2008-07-08 20:28 UTC (permalink / raw)
To: mike zheng; +Cc: linuxppc-dev, linux-crypto
In-Reply-To: <5c9cd53b0807081103y583d0013ic0d22fb46490be2b@mail.gmail.com>
On Tue, 8 Jul 2008 14:03:28 -0400
"mike zheng" <mail4mz@gmail.com> wrote:
> Hello,
>
> Any one know how can I integrate the Freescale's SEC driver with
> cryptoloop in Kernel2.4 on MPC8567e? Or which version of kernel shall
> I take if it is already there?
Take Herbert's cryptodev-2.6 tree and add support in the talitos driver
for the ablkcipher algorithm you're using.
Kim
^ permalink raw reply
* Re: [PATCH] powerpc: i2c-ibm_iic register child nodes
From: Sean MacLennan @ 2008-07-08 20:22 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <20080708144609.14bae1de@lappy.seanm.ca>
Update the warp to use the new IBM IIC driver. We no longer need to
register the I2C devices in the platform code.
Also adds a small bugfix for the i2c code if the i2c read fails.
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
index 9565995..960edf8 100644
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -30,18 +30,6 @@ static __initdata struct of_device_id warp_of_bus[] = {
{},
};
-static __initdata struct i2c_board_info warp_i2c_info[] = {
- { I2C_BOARD_INFO("ad7414", 0x4a) }
-};
-
-static int __init warp_arch_init(void)
-{
- /* This should go away once support is moved to the dts. */
- i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
- return 0;
-}
-machine_arch_initcall(warp, warp_arch_init);
-
static int __init warp_device_probe(void)
{
of_platform_bus_probe(NULL, warp_of_bus, NULL);
@@ -223,7 +211,7 @@ static void pika_setup_critical_temp(struct i2c_client *client)
/* These registers are in 1 degree increments. */
i2c_smbus_write_byte_data(client, 2, 65); /* Thigh */
- i2c_smbus_write_byte_data(client, 3, 55); /* Tlow */
+ i2c_smbus_write_byte_data(client, 3, 0); /* Tlow */
np = of_find_compatible_node(NULL, NULL, "adi,ad7414");
if (np == NULL) {
@@ -289,8 +277,15 @@ found_it:
printk(KERN_INFO "PIKA DTM thread running.\n");
while (!kthread_should_stop()) {
- u16 temp = swab16(i2c_smbus_read_word_data(client, 0));
- out_be32(fpga + 0x20, temp);
+ int val;
+
+ val = i2c_smbus_read_word_data(client, 0);
+ if (val < 0)
+ dev_dbg(&client->dev, "DTM read temp failed.\n");
+ else {
+ s16 temp = swab16(val);
+ out_be32(fpga + 0x20, temp);
+ }
pika_dtm_check_fan(fpga);
^ permalink raw reply related
* [PATCH v2] Add PPC_FEATURE_PSERIES_PMU_COMPAT
From: Nathan Lynch @ 2008-07-08 20:01 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olof Johansson, Paul Mackerras
In-Reply-To: <20080703232001.GB9594@localdomain>
Background from Maynard Johnson:
As of POWER6, a set of 32 common events is defined that must be
supported on all future POWER processors. The main impetus for this
compat set is the need to support partition migration, especially from
processor P(n) to processor P(n+1), where performance software that's
running in the new partition may not be knowledgeable about processor
P(n+1). If a performance tool determines it does not support the
physical processor, but is told (via the PPC_FEATURE_PSERIES_PMU_COMPAT
bit) that the processor supports the notion of the PMU compat set,
then the performance tool can surface just those events to the user
of the tool.
PPC_FEATURE_PSERIES_PMU_COMPAT indicates that the PMU supports at
least this basic subset of events which is compatible across POWER
processor lines.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
Changes since v1:
- make name of feature bit less generic
- provide more complete changelog
arch/powerpc/kernel/cputable.c | 6 ++++--
include/asm-powerpc/cputable.h | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 817cea1..c4eb377 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -70,10 +70,12 @@ extern void __restore_cpu_power7(void);
PPC_FEATURE_SMT | PPC_FEATURE_ICACHE_SNOOP)
#define COMMON_USER_POWER6 (COMMON_USER_PPC64 | PPC_FEATURE_ARCH_2_05 |\
PPC_FEATURE_SMT | PPC_FEATURE_ICACHE_SNOOP | \
- PPC_FEATURE_TRUE_LE)
+ PPC_FEATURE_TRUE_LE | \
+ PPC_FEATURE_PSERIES_PMU_COMPAT)
#define COMMON_USER_POWER7 (COMMON_USER_PPC64 | PPC_FEATURE_ARCH_2_06 |\
PPC_FEATURE_SMT | PPC_FEATURE_ICACHE_SNOOP | \
- PPC_FEATURE_TRUE_LE)
+ PPC_FEATURE_TRUE_LE | \
+ PPC_FEATURE_PSERIES_PMU_COMPAT)
#define COMMON_USER_PA6T (COMMON_USER_PPC64 | PPC_FEATURE_PA6T |\
PPC_FEATURE_TRUE_LE | \
PPC_FEATURE_HAS_ALTIVEC_COMP)
diff --git a/include/asm-powerpc/cputable.h b/include/asm-powerpc/cputable.h
index 3171ac9..d1492a2 100644
--- a/include/asm-powerpc/cputable.h
+++ b/include/asm-powerpc/cputable.h
@@ -26,6 +26,7 @@
#define PPC_FEATURE_POWER6_EXT 0x00000200
#define PPC_FEATURE_ARCH_2_06 0x00000100
#define PPC_FEATURE_HAS_VSX 0x00000080
+#define PPC_FEATURE_PSERIES_PMU_COMPAT 0x00000040
#define PPC_FEATURE_TRUE_LE 0x00000002
#define PPC_FEATURE_PPC_LE 0x00000001
--
1.5.6.2
^ permalink raw reply related
* [PATCH] powerpc: support nand boot for rev A warps
From: Sean MacLennan @ 2008-07-08 19:00 UTC (permalink / raw)
To: linuxppc-dev
This patch is against linux-next.
Allow the Rev A Warp boards to boot from NAND.
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/platforms/44x/warp-nand.c b/arch/powerpc/platforms/44x/warp-nand.c
index 7bec281..e55746b 100644
--- a/arch/powerpc/platforms/44x/warp-nand.c
+++ b/arch/powerpc/platforms/44x/warp-nand.c
@@ -113,9 +113,14 @@ static int warp_setup_nand_flash(void)
pp = of_find_property(np, "reg", NULL);
if (pp && (pp->length == 12)) {
u32 *v = pp->value;
- if (v[2] == 0x4000000)
+ if (v[2] == 0x4000000) {
/* Rev A = 64M NAND */
- warp_nand_chip0.nr_partitions = 2;
+ warp_nand_chip0.nr_partitions = 3;
+
+ nand_parts[1].size = 0x3000000;
+ nand_parts[2].offset = 0x3200000;
+ nand_parts[2].size = 0x0e00000;
+ }
}
of_node_put(np);
}
^ permalink raw reply related
* [PATCH] powerpc: i2c-ibm_iic register child nodes
From: Sean MacLennan @ 2008-07-08 18:46 UTC (permalink / raw)
To: linuxppc-dev, Jean Delvare
This patch completes the conversion of the IBM IIC driver to an
of-platform driver.
It removes the index from the IBM IIC driver and makes it an unnumbered
driver. It then calls of_register_i2c_devices to properly register all
the child nodes in the DTS.
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
index 070f078..651f2f1 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -43,6 +43,7 @@
#include <linux/i2c.h>
#include <linux/i2c-id.h>
#include <linux/of_platform.h>
+#include <linux/of_i2c.h>
#include "i2c-ibm_iic.h"
@@ -696,7 +697,7 @@ static int __devinit iic_probe(struct of_device *ofdev,
struct device_node *np = ofdev->node;
struct ibm_iic_private *dev;
struct i2c_adapter *adap;
- const u32 *indexp, *freq;
+ const u32 *freq;
int ret;
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
@@ -707,14 +708,6 @@ static int __devinit iic_probe(struct of_device *ofdev,
dev_set_drvdata(&ofdev->dev, dev);
- indexp = of_get_property(np, "index", NULL);
- if (!indexp) {
- dev_err(&ofdev->dev, "no index specified\n");
- ret = -EINVAL;
- goto error_cleanup;
- }
- dev->idx = *indexp;
-
dev->vaddr = of_iomap(np, 0);
if (dev->vaddr == NULL) {
dev_err(&ofdev->dev, "failed to iomap device\n");
@@ -757,14 +750,16 @@ static int __devinit iic_probe(struct of_device *ofdev,
adap->class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
adap->algo = &iic_algo;
adap->timeout = 1;
- adap->nr = dev->idx;
- ret = i2c_add_numbered_adapter(adap);
+ ret = i2c_add_adapter(adap);
if (ret < 0) {
dev_err(&ofdev->dev, "failed to register i2c adapter\n");
goto error_cleanup;
}
+ /* Now register all the child nodes */
+ of_register_i2c_devices(adap, np);
+
dev_info(&ofdev->dev, "using %s mode\n",
dev->fast_mode ? "fast (400 kHz)" : "standard (100 kHz)");
^ permalink raw reply related
* Freescale SEC driver with cryptoloop on MPC8567e
From: mike zheng @ 2008-07-08 18:42 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <5c9cd53b0807081103y583d0013ic0d22fb46490be2b@mail.gmail.com>
Hello,
Any one know how can I integrate the Freescale's SEC driver with
cryptoloop in Kernel2.4 on MPC8567e? Or which version of kernel shall
I take if it is already there?
Thanks for your help,
Mike
^ permalink raw reply
* Re: [PATCH 1/2] elf loader support for auxvec base platform string
From: Steven Munroe @ 2008-07-08 18:35 UTC (permalink / raw)
To: benh
Cc: Steve Munroe, linux-kernel, linuxppc-dev, Paul Mackerras,
Nathan Lynch, Roland McGrath
In-Reply-To: <1215478091.8970.183.camel@pasglop>
On Tue, 2008-07-08 at 10:48 +1000, Benjamin Herrenschmidt wrote:
> Adding Steve to the CC list as I'd like his input from the
> glibc/powerpc side as he's the requester of that feature in the first
> place.
>
> Steve: Roland is proposing to ues dsocaps instead of AT_BASE_PLATFORM.
>
I am will to discuss better solutions with Roland. It seems like I am
finally on the air for linuxppc-dev but it seems some of my earlier
notes got lost.
So I will restate. AT_BASE_PLATFORM is proposed solution to several
problems including CPU tuned library selection. If dsocaps is better
solution for library select I am happy to consider and discuss this.
However it is not clear that dsocaps is solution to all requires we need
to address for virtualization and partition migration of applications.
This required a durable and public API accessible form any application
or library.
First the problem:
We want to support migration of running partitions (including the kernel
and all running applications) abd we have to deal with mixed platform
clusters. If we want to migrate freely between POWER5+ and POWER6 (or
POWER7) systems then we need to make sure the application and its
libraries restrict themselves to the lowest ISA Version level (2.04 in
this case).
So the hardware and hypervisor support and enforce CPU compatibility
modes. For a partition is created on a POWER6 to run in POWER5+ mode.
There are HID bits set to restrict instruction set to the POWER5+
subset. So running a program that uses new POWER6 instruction on this
partition will SIGILL.
So while this is really a POWER6 machine it is wrong for the kernel to
return AT_PLATFORM=power6. The /lib/power6/libc.so and libm.so do use
the new ISA V2.05 instructions that will SIGILL in this (POWER5+
compatible) partition.
In this case the kernel should return AT_PLATFORM=power5+
because /lib/power5+/libc.so is build --with-cpu=power5+ and only uses
the ISA V2.04 instructions.
But that introduces some new problems. The processor, internal pipeline
(micro-architecture), and performance monitor unit (PMU events have to
match the pipeline structure) have not changed (still POWER6/7). This
implications on application performance and many performance tools.
For example oProfile/PAPI/libpfm need to know what the processor really
is because miss programing the PMU get bogus results or even crash the
systems. Another example is a JVM/JIT compiler which needs to know what
supported ISA level is (from AT_PLATFORM and AT_HWCAP), but can generate
better code if, it knows that base platform is different, and what the
actual micro-architecture is. For these examples the
AT_PLATFORM/AT_HWCAP based library selection mechanism does not apply.
And except for oProfile these examples are user mode
applications/libraries that need this information from a simple and
durable and public API. To me AT_BASE_PLATFORM seems like the minimal,
simplest, and most general solution to these problem.
Ok now back to library selection and dsocaps. Running power5+ libraries
on a power6 will execute (will not SIGILL) but may not be optimal. the
best performance also require careful instruction selection and
scheduling. For example the performance of memset/memcpy/memcmp depend
on tuning to the detail timing of the Load/Store pipelines, Store Queue
depth, and L2 cache clocking. This can be very different between
processor generations.
For this power5+ compatible partitions, we would like the option to
build libraries for -mcpu=power5+ -mtune=power6! etc!. The details of
how this will work are TBD. I put forth AT_BASE_PLATFORM with thought
that it could be search modifier in addition to AT_PLATFORM
(i.e. /lib/power5+/power6/libc.so.
If dsocaps is a better mechanism for library selection I am more then
will to discuss how dsocaps works and how it can be applied to this
specific case.
^ permalink raw reply
* Freescale SEC driver with cryptoloop on MPC8567e
From: mike zheng @ 2008-07-08 18:03 UTC (permalink / raw)
To: linux-crypto, linuxppc-dev
Hello,
Any one know how can I integrate the Freescale's SEC driver with
cryptoloop in Kernel2.4 on MPC8567e? Or which version of kernel shall
I take if it is already there?
Thanks for your help,
Mike
^ permalink raw reply
* Re: [PATCH 15/16 v3] ibmvscsi: driver enablement for CMO
From: Robert Jennings @ 2008-07-08 17:41 UTC (permalink / raw)
To: Brian King; +Cc: linux-scsi, linuxppc-dev, David Darrington, paulus
In-Reply-To: <4872298D.8050802@linux.vnet.ibm.com>
* Brian King (brking@linux.vnet.ibm.com) wrote:
> Robert Jennings wrote:
> > @@ -1613,6 +1624,26 @@ static struct scsi_host_template driver_
> > };
> >
> > /**
> > + * ibmvscsi_get_desired_dma - Calculate IO entitlement needed by the driver
> > + *
> > + * @vdev: struct vio_dev for the device whose entitlement is to be returned
> > + *
> > + * Return value:
> > + * Number of bytes of IO data the driver will need to perform well.
> > + */
> > +static unsigned long ibmvscsi_get_desired_dma(struct vio_dev *vdev)
> > +{
> > + /* iu_storage data allocated in initialize_event_pool */
> > + unsigned long io_entitlement = max_requests * sizeof(union viosrp_iu);
>
> Since you are removing the use of "entitlement" in the function description,
> you should probably remove it everywhere in this patch.
I'll clean this up.
> > +
> > + /* add io space for sg data */
> > + io_entitlement += (IBMVSCSI_MAX_SECTORS_DEFAULT *
> > + IBMVSCSI_CMDS_PER_LUN_DEFAULT);
> > +
> > + return IOMMU_PAGE_ALIGN(io_entitlement);
>
> I really think this function should just return the number of bytes and
> let the caller round it up to any boundary requirements it might have.
I agree. I'll be posting a new patch after a work out another issue I'm
having. Hope to have that out soon.
--Rob Jennings
^ permalink raw reply
* [PATCH 2/2] powerpc/fsl_soc: gianfar: don't probe disabled devices
From: Anton Vorontsov @ 2008-07-08 17:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
Freescale ships MPC8315E-RDB boards in two variants:
1. With TSEC1 ethernet support and USB UTMI PHY;
2. Without TSEC1 support, but with USB ULPI PHY in addition.
For the second case U-Boot will add status = "disabled"; property
into the TSEC1 node, so Linux should not try to probe it.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/fsl_soc.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 7d4cf00..2a19769 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -296,6 +296,9 @@ static int __init gfar_of_init(void)
const phandle *ph;
int n_res = 2;
+ if (!of_device_is_available(np))
+ continue;
+
memset(r, 0, sizeof(r));
memset(&gfar_data, 0, sizeof(gfar_data));
--
1.5.5.4
^ permalink raw reply related
* [PATCH 1/2] powerpc/83xx: fix ULPI setup for MPC8315 processors
From: Anton Vorontsov @ 2008-07-08 17:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
We must not use MPC831X_SICR[HL]_* definitions for the MPC8315 processors,
because SICR USB bits locations are not compatible with MPC8313.
This patch fixes ULPI workability on MPC8315E-RDB boards.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/83xx/mpc83xx.h | 4 ++++
arch/powerpc/platforms/83xx/usb.c | 24 +++++++++++++++---------
2 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h b/arch/powerpc/platforms/83xx/mpc83xx.h
index 88a3b5c..a8dcb81 100644
--- a/arch/powerpc/platforms/83xx/mpc83xx.h
+++ b/arch/powerpc/platforms/83xx/mpc83xx.h
@@ -26,6 +26,8 @@
#define MPC834X_SICRL_USB1 0x20000000
#define MPC831X_SICRL_USB_MASK 0x00000c00
#define MPC831X_SICRL_USB_ULPI 0x00000800
+#define MPC8315_SICRL_USB_MASK 0x000000fc
+#define MPC8315_SICRL_USB_ULPI 0x00000054
#define MPC837X_SICRL_USB_MASK 0xf0000000
#define MPC837X_SICRL_USB_ULPI 0x50000000
@@ -34,6 +36,8 @@
#define MPC834X_SICRH_USB_UTMI 0x00020000
#define MPC831X_SICRH_USB_MASK 0x000000e0
#define MPC831X_SICRH_USB_ULPI 0x000000a0
+#define MPC8315_SICRH_USB_MASK 0x0000ff00
+#define MPC8315_SICRH_USB_ULPI 0x00000000
/* USB Control Register */
#define FSL_USB2_CONTROL_OFFS 0x500
diff --git a/arch/powerpc/platforms/83xx/usb.c b/arch/powerpc/platforms/83xx/usb.c
index 64bcf0a..cc99c28 100644
--- a/arch/powerpc/platforms/83xx/usb.c
+++ b/arch/powerpc/platforms/83xx/usb.c
@@ -137,15 +137,21 @@ int mpc831x_usb_cfg(void)
/* Configure pin mux for ULPI. There is no pin mux for UTMI */
if (prop && !strcmp(prop, "ulpi")) {
- temp = in_be32(immap + MPC83XX_SICRL_OFFS);
- temp &= ~MPC831X_SICRL_USB_MASK;
- temp |= MPC831X_SICRL_USB_ULPI;
- out_be32(immap + MPC83XX_SICRL_OFFS, temp);
-
- temp = in_be32(immap + MPC83XX_SICRH_OFFS);
- temp &= ~MPC831X_SICRH_USB_MASK;
- temp |= MPC831X_SICRH_USB_ULPI;
- out_be32(immap + MPC83XX_SICRH_OFFS, temp);
+ if (of_device_is_compatible(immr_node, "fsl,mpc8315-immr")) {
+ clrsetbits_be32(immap + MPC83XX_SICRL_OFFS,
+ MPC8315_SICRL_USB_MASK,
+ MPC8315_SICRL_USB_ULPI);
+ clrsetbits_be32(immap + MPC83XX_SICRH_OFFS,
+ MPC8315_SICRH_USB_MASK,
+ MPC8315_SICRH_USB_ULPI);
+ } else {
+ clrsetbits_be32(immap + MPC83XX_SICRL_OFFS,
+ MPC831X_SICRL_USB_MASK,
+ MPC831X_SICRL_USB_ULPI);
+ clrsetbits_be32(immap + MPC83XX_SICRH_OFFS,
+ MPC831X_SICRH_USB_MASK,
+ MPC831X_SICRH_USB_ULPI);
+ }
}
iounmap(immap);
--
1.5.5.4
^ permalink raw reply related
* Re: booting an ML405
From: David Baird @ 2008-07-08 17:12 UTC (permalink / raw)
To: Lorenzo T. Flores; +Cc: linuxppc-embedded
In-Reply-To: <4872C4D0.4060006@alphagolf.com>
On Mon, Jul 7, 2008 at 7:37 PM, Lorenzo T. Flores <lorenzo@alphagolf.com> wrote:
> If I stop the processor after it hangs:
>
> XMD% mrd 0xc0259fa4 10
> C0259FA4: 3C353E5B
> C0259FA8: 20202020
> C0259FAC: 302E3030
> C0259FB0: 30303030
> C0259FB4: 5D204C69
> C0259FB8: 6E757820
> C0259FBC: 76657273
> C0259FC0: 696F6E20
> C0259FC4: 322E362E
> C0259FC8: 32352D72
Since XMD is also a Tcl shell, you can easily download __log_buf like this:
set fd [open xmd.log w]
puts $fd [mrd 0xc0259fa4 10]
Then, with a little tweaking, you could use xxd or some other tool to
convert it to ASCII.
> If I cut off the 0xc0000000:
>
> XMD% mrd 0x259fa4 10
> 259FA4: FFFFFFFF
> 259FA8: FFFFFFFF
> 259FAC: FFFFFFFF
> 259FB0: FFFFFFFF
> 259FB4: FFFFFFFF
> 259FB8: FFFFFFFF
> 259FBC: FFFFFFFF
> 259FC0: FFFFFFFF
> 259FC4: FFFFFFFF
> 259FC8: FFFFFFFF
My guess is that if you issue a rst (reset) command, I think this will
take the processor out of virtual mode and then you can strip of the
0xc0000000. But looks like you got what you need anyways, so no need
for this :-)
-David
^ permalink raw reply
* powerpc: Add missing reference to coherent_dma_mask
From: Vitaly Bordug @ 2008-07-08 16:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org, David Gibson
There is dma_mask in of_device upon of_platform_device_create()
but we don't actually set coherent_dma_mask. This may cause weird
behavior of USB subsystem using of_device USB host drivers.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
arch/powerpc/kernel/of_platform.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/of_platform.c b/arch/powerpc/kernel/of_platform.c
index e79ad8a..3f37a6e 100644
--- a/arch/powerpc/kernel/of_platform.c
+++ b/arch/powerpc/kernel/of_platform.c
@@ -76,6 +76,8 @@ struct of_device* of_platform_device_create(struct device_node *np,
return NULL;
dev->dma_mask = 0xffffffffUL;
+ dev->dev.coherent_dma_mask = DMA_32BIT_MASK;
+
dev->dev.bus = &of_platform_bus_type;
/* We do not fill the DMA ops for platform devices by default.
^ permalink raw reply related
* Re: [PATCH] Restore PERR/SERR bit settings during EEH device recovery
From: Mike Mason @ 2008-07-08 16:04 UTC (permalink / raw)
To: linasvepstas, paulus, benh, linuxppc-dev
In-Reply-To: <3ae3aa420807080638t41e8851bx2ad061dd5a4e0279@mail.gmail.com>
Here's a resubmission of the patch with Linas' suggestion.
The following patch restores the PERR and SERR bits in the PCI
command register during an EEH device recovery. We have found
at least one case (an Agilent test card) where the PERR/SERR
bits are set to 1 by firmware at boot time, but are not restored
to 1 during EEH recovery. The patch fixes the Agilent card
problem. It has been tested on several other EEH-enabled cards
with no regressions.
Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
Acked-by: Linas Vepstas <linasvepstas@gmail.com>
--- linux-2.6.26-rc9/arch/powerpc/platforms/pseries/eeh.c 2008-07-07 16:06:57.000000000 -0700
+++ linux-2.6.26-rc9-new/arch/powerpc/platforms/pseries/eeh.c 2008-07-08 03:56:35.000000000 -0700
@@ -812,6 +812,7 @@
static inline void __restore_bars (struct pci_dn *pdn)
{
int i;
+ u32 cmd;
if (NULL==pdn->phb) return;
for (i=4; i<10; i++) {
@@ -832,6 +833,19 @@
/* max latency, min grant, interrupt pin and line */
rtas_write_config(pdn, 15*4, 4, pdn->config_space[15]);
+
+ /* Restore PERR & SERR bits, some devices require it,
+ don't touch the other command bits */
+ rtas_read_config(pdn, PCI_COMMAND, 4, &cmd);
+ if (pdn->config_space[1] & PCI_COMMAND_PARITY)
+ cmd |= PCI_COMMAND_PARITY;
+ else
+ cmd &= ~PCI_COMMAND_PARITY;
+ if (pdn->config_space[1] & PCI_COMMAND_SERR)
+ cmd |= PCI_COMMAND_SERR;
+ else
+ cmd &= ~PCI_COMMAND_SERR;
+ rtas_write_config(pdn, PCI_COMMAND, 4, cmd);
}
/**
^ permalink raw reply
* Re: [PATCH] Restore PERR/SERR bit settings during EEH device recovery
From: Mike Mason @ 2008-07-08 15:56 UTC (permalink / raw)
To: linasvepstas; +Cc: paulus, linuxppc-dev
In-Reply-To: <3ae3aa420807080638t41e8851bx2ad061dd5a4e0279@mail.gmail.com>
Linas Vepstas wrote:
> 2008/7/7 Mike Mason <mmlnx@us.ibm.com>:
>> The following patch restores the PERR and SERR bits in the PCI
>> command register during an EEH device recovery.
>> We have found at least one case (an Agilent test card) where the
>> PERR/SERR bits are set to 1 by firmware at boot time, but are
>> not restored to 1 during EEH recovery.
>
> Any chance they should be zero, and were accidentally set to 1?
> In which case, you'd need an else clause, below.
I suppose it's possible. I'll add your suggestion and resubmit.
Mike
>
>> The patch fixes the
>> Agilent card problem. It has been tested on several other EEH-enabled cards
>> with no regressions.
>>
>> Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
>>
>> --- linux-2.6.26-rc9/arch/powerpc/platforms/pseries/eeh.c 2008-07-07
>> 16:06:57.000000000 -0700
>> +++ linux-2.6.26-rc9-new/arch/powerpc/platforms/pseries/eeh.c 2008-07-07
>> 16:11:10.000000000 -0700
>> @@ -812,6 +812,7 @@
>> static inline void __restore_bars (struct pci_dn *pdn)
>> {
>> int i;
>> + u32 cmd;
>>
>> if (NULL==pdn->phb) return;
>> for (i=4; i<10; i++) {
>> @@ -832,6 +833,15 @@
>>
>> /* max latency, min grant, interrupt pin and line */
>> rtas_write_config(pdn, 15*4, 4, pdn->config_space[15]);
>> +
>> + /* Restore PERR & SERR bits, some devices require it,
>> + don't touch the other command bits */
>> + rtas_read_config(pdn, PCI_COMMAND, 4, &cmd);
>> + if (pdn->config_space[1] & PCI_COMMAND_PARITY)
>> + cmd |= PCI_COMMAND_PARITY;
>
> else cmd &= ~PCI_COMMAND_PARITY;
>
>> + if (pdn->config_space[1] & PCI_COMMAND_SERR)
>> + cmd |= PCI_COMMAND_SERR;
>
> else cmd &= ~PCI_COMMAND_SERR;
>
>> + rtas_write_config(pdn, PCI_COMMAND, 4, cmd);
>> }
>
> Other than that, I'll add an
>
> Acked-by: Linas Vepstas <linasvepstas@gmail.com>
>
> --linas
^ permalink raw reply
* Re: [PATCH] irda: driver for Freescale FIRI controller
From: Anton Vorontsov @ 2008-07-08 15:44 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: linuxppc-dev, netdev, Timur Tabi, Zhang Wei
In-Reply-To: <20080611222524.GA6710@sortiz.org>
On Thu, Jun 12, 2008 at 12:25:25AM +0200, Samuel Ortiz wrote:
> Hi Anton,
>
> On Wed, Jun 04, 2008 at 07:45:10PM +0400, Anton Vorontsov wrote:
> > From: Zhang Wei <wei.zhang@freescale.com>
> >
> > The driver supports SIR, MIR, FIR modes and maximum 4000000bps rate.
> >
> > Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> > [AV: few small fixes, plus had made platform ops passing via node->data
> > to avoid #ifdef stuff in the fsl_soc (think DIU). ]
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> Some comments below:
Sorry, it took me so long to answer. :-/
Much thanks for the comments, will fix them all. That is, your review
work isn't in vain, I'm much appreciated it.
Thanks again,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH v2] ibm_newemac: Add MII mode support to the EMAC RGMII bridge.
From: Stefan Roese @ 2008-07-08 15:35 UTC (permalink / raw)
To: Grant Erickson; +Cc: linuxppc-dev, jgarzik
In-Reply-To: <1215529386-12749-1-git-send-email-gerickson@nuovations.com>
On Tuesday 08 July 2008, Grant Erickson wrote:
> This patch adds support to the RGMII handler in the EMAC driver for
> the MII PHY mode such that device tree entries of the form `phy-mode =
> "mii";' are recognized and handled appropriately.
>
> While logically, in software, "gmii" and "mii" modes are the same,
> they are wired differently, so it makes sense to allow DTS authors to
> specify each explicitly.
>
> Signed-off-by: Grant Erickson <gerickson@nuovations.com>
Acked-by: Stefan Roese <sr@denx.de>
Best regards,
Stefan
^ permalink raw reply
* Re: powerpc/cell/cpufreq: add spu aware cpufreq governor
From: Dave Jones @ 2008-07-08 15:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Stephen Rothwell, cpufreq, linuxppc-dev, Jeremy Kerr, cbe-oss-dev
In-Reply-To: <200807080843.43674.arnd@arndb.de>
On Tue, Jul 08, 2008 at 08:43:43AM +0200, Arnd Bergmann wrote:
> On Monday 07 July 2008, Dave Jones wrote:
> > One question I do have though, is how userspace scripts are supposed
> > to know they're to echo cbe_spu_governor into the relevant parts of
> > sysfs. I've not used anything with a cell. Do they expose the SPUs
> > as regular CPUs, or do they show up in a different part of the tree?
>
> An SPU is very different from a CPU from the user perspective.
> SPUs show up in /sys/devices/system/spus, and if a user wants to access
> them, the "spufs" file system needs to be mounted in the system, by
> convention on /spu.
Ok, that should be fairly simple to write scripts for.
All sounds good to me.
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* [PATCH v2] ibm_newemac: Add MII mode support to the EMAC RGMII bridge.
From: Grant Erickson @ 2008-07-08 15:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sr, jgarzik
In-Reply-To: <C497F939.104DB%gerickson@nuovations.com>
This patch adds support to the RGMII handler in the EMAC driver for
the MII PHY mode such that device tree entries of the form `phy-mode = "mii";'
are recognized and handled appropriately.
While logically, in software, "gmii" and "mii" modes are the same,
they are wired differently, so it makes sense to allow DTS authors to
specify each explicitly.
Signed-off-by: Grant Erickson <gerickson@nuovations.com>
---
drivers/net/ibm_newemac/rgmii.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
index e32da3d..5acb006 100644
--- a/drivers/net/ibm_newemac/rgmii.c
+++ b/drivers/net/ibm_newemac/rgmii.c
@@ -39,6 +39,7 @@
#define RGMII_FER_RGMII(idx) (0x5 << ((idx) * 4))
#define RGMII_FER_TBI(idx) (0x6 << ((idx) * 4))
#define RGMII_FER_GMII(idx) (0x7 << ((idx) * 4))
+#define RGMII_FER_MII(idx) RGMII_FER_GMII(idx)
/* RGMIIx_SSR */
#define RGMII_SSR_MASK(idx) (0x7 << ((idx) * 8))
@@ -49,6 +50,7 @@
static inline int rgmii_valid_mode(int phy_mode)
{
return phy_mode == PHY_MODE_GMII ||
+ phy_mode == PHY_MODE_MII ||
phy_mode == PHY_MODE_RGMII ||
phy_mode == PHY_MODE_TBI ||
phy_mode == PHY_MODE_RTBI;
@@ -63,6 +65,8 @@ static inline const char *rgmii_mode_name(int mode)
return "TBI";
case PHY_MODE_GMII:
return "GMII";
+ case PHY_MODE_MII:
+ return "MII";
case PHY_MODE_RTBI:
return "RTBI";
default:
@@ -79,6 +83,8 @@ static inline u32 rgmii_mode_mask(int mode, int input)
return RGMII_FER_TBI(input);
case PHY_MODE_GMII:
return RGMII_FER_GMII(input);
+ case PHY_MODE_MII:
+ return RGMII_FER_MII(input);
case PHY_MODE_RTBI:
return RGMII_FER_RTBI(input);
default:
--
1.5.4.3
^ permalink raw reply related
* RE: booting an ML405
From: John Linn @ 2008-07-08 14:58 UTC (permalink / raw)
To: Lorenzo T. Flores, linuxppc-embedded
In-Reply-To: <486D774A.7000102@alphagolf.com>
Hi Lorenzo,
I'm assuming you're trying to use the reference design bit stream for
the ML405 that we have had out on the http://git.xilinx.com site?
Since the bootstrap loader is working, the UART appears to be OK.
Assuming you have the kernel configuration right with the 8250 driver
and the console, it sounds like something else must be wrong and you're
headed in the right direction with using the __log_buf.
The __log_buf should tell you if the kernel is really hung, or if it
booted and you just don't have a console working.
The ml405_defconfig sets up the kernel configuration so it should work
on the board just building it for the reference design.
One thing I notice is the available ram looks wrong to me for the ML405
based on my notes.
=
> avail ram: 005B0000 80000000
I had a problem once with the kernel and I found the DDR_SIZE in
xparameters.h (arch/ppc/platforms/40x/xparameters) was not right, and
this does hang the kernel in my experience.
My old kernel output shows
> avail ram: 00519000 04000000
Hope that might help,
John
> -----Original Message-----
> From: linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+john.linn=3Dxilinx.com@ozlabs.org] On Behalf Of Lorenzo T.
Flores
> Sent: Thursday, July 03, 2008 7:05 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: booting an ML405
> =
> Hey all,
> =
> I did a little preliminary poking through the thread archives, but
> didn't turn anything up. I anyone could just point me in the right
> direction as far as troubleshooting, that would be great!
> =
> I'm trying to compile the Xilinx patched kernel tree (v2.6.25-rc9) and
> run it on an ML405
> =
> So far, I get to the following point in the boot sequence:
> =
> loaded at: 00400000 005AF5A0
> board data at: 005AD524 005AD5A0
> relocated to: 00405058 004050D4
> zimage at: 00405E90 0051D6CC
> initrd at: 0051E000 005ACC0D
> avail ram: 005B0000 80000000
> =
> Linux/PPC load: console=3DttyS0,9600 ip=3Don root=3D/dev/ram rw
> Uncompressing Linux...done.
> Now booting the kernel
> =
> The system hangs after it says "Now booting the kernel."
> =
> Once again, any input would be appreciated.
> =
> thank you,
> Lorenzo
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: While(1) in kernel space
From: Chris Friesen @ 2008-07-08 14:44 UTC (permalink / raw)
To: Paolo Doz; +Cc: linuxppc-dev
In-Reply-To: <5468b7f30807080055p69571979i9a565653e523c2c0@mail.gmail.com>
Paolo Doz wrote:
> Hi folks,
> I'm developing a custom SPI driver (char device) on a MPC5200b, the
> microcontroller linked as slave implements a protocol that must follow
> strict timing constraints. I need to receive and send messages every
> 6msec.
What are your timing requirements? How much over/under 6ms can the
protocol handle?
Kernel threads might work, but then you're at the mercy of the
scheduler. You'd probably be better off using a timer or softirq.
If the latency requirements are really strict, your best bet would
probably be to use the -rt patches for the kernel. That requires
building a custom kernel though.
Chris
^ permalink raw reply
* Re: While(1) in kernel space
From: Grant Likely @ 2008-07-08 14:47 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Paolo Doz
In-Reply-To: <200807081645.31807.arnd@arndb.de>
On Tue, Jul 8, 2008 at 8:45 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 08 July 2008, Grant Likely wrote:
>
>>
>> You can use a kernel thread.
>>
>> I'm not sure how accurate this is, but here is some information about them:
>>
>> http://www.linuxquestions.org/linux/articles/Technical/Linux_Kernel_Thread
>
> Not accurate at all. New code should use kthread_create, as documented in
>
> http://lwn.net/Articles/65178/
Teach me to blindly use google. Thanks Arnd.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: While(1) in kernel space
From: Arnd Bergmann @ 2008-07-08 14:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paolo Doz
In-Reply-To: <fa686aa40807080719r4b7b01f7n7863fe1456a3e64@mail.gmail.com>
On Tuesday 08 July 2008, Grant Likely wrote:
>
> You can use a kernel thread.
>
> I'm not sure how accurate this is, but here is some information about them:
>
> http://www.linuxquestions.org/linux/articles/Technical/Linux_Kernel_Thread
Not accurate at all. New code should use kthread_create, as documented in
http://lwn.net/Articles/65178/
Arnd <><
^ permalink raw reply
* Re: AZFS file system proposal
From: Arnd Bergmann @ 2008-07-08 14:42 UTC (permalink / raw)
To: Maxim Shchetynin
Cc: Mark Nelson, Gunnar von Boehn, linux-kernel, linuxppc-dev,
Paul Mackerras, linux-fsdevel
In-Reply-To: <20080707173923.17dc6c05@mercedes-benz.boeblingen.de.ibm.com>
On Monday 07 July 2008, Maxim Shchetynin wrote:
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if=
(copy_to_user(target, (void*) pin, size)) {
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0rc =3D -EFAULT;
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0goto out;
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}
> >=20
> > Question to the powerpc folks: is copy_to_user safe for an __iomem sour=
ce?
> > Should there be two copies (memcpy_fromio and copy_to_user) instead?
>=20
> I leave this question open.
>=20
Cc:'ing some more people that might have more of a clue on this question.
_memcpy_fromio does a "sync" at the start and an "eieio" at the end.
IFAICT, neither are needed here because the source is always memory.
It also handles unaligned memory accesses, which copy_to_user should
also do correctly, so it *looks* like it should work with just a
copy_to_user, but it still feels wrong to use an __iomem pointer
as the source for a copy_to_user.
Any ideas?
Arnd <><
^ permalink raw reply
* RE: [PATCH] [V2] powerpc: Xilinx: add dts file for ML507 board
From: John Linn @ 2008-07-08 14:41 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080708031641.GA1549@yookeroo.seuss>
Thanks for the comments David. =
> -----Original Message-----
> From: David Gibson [mailto:david@gibson.dropbear.id.au]
> Sent: Monday, July 07, 2008 9:17 PM
> To: John Linn
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] [V2] powerpc: Xilinx: add dts file for ML507
board
> =
> On Mon, Jul 07, 2008 at 11:04:59AM -0700, John Linn wrote:
> > This new file adds support for the ML507 board which
> > has a Virtex 5 FXT FPGA with a 440.
> >
> > Signed-off-by: John Linn <john.linn@xilinx.com>
> > ---
> > V2
> > Converted to dts-v1 format.
> > Changed to match a newer reference design.
> >
> > arch/powerpc/boot/dts/virtex440-ml507.dts | 296
+++++++++++++++++++++++++++++
> > 1 files changed, 296 insertions(+), 0 deletions(-)
> > create mode 100644 arch/powerpc/boot/dts/virtex440-ml507.dts
> >
> > diff --git a/arch/powerpc/boot/dts/virtex440-ml507.dts
b/arch/powerpc/boot/dts/virtex440-ml507.dts
> > new file mode 100644
> > index 0000000..d10a993
> > --- /dev/null
> > +++ b/arch/powerpc/boot/dts/virtex440-ml507.dts
> > @@ -0,0 +1,296 @@
> > +/*
> > + * This file supports the Xilinx ML507 board with the 440
processor.
> > + * A reference design for the FPGA is provided at
http://git.xilinx.com.
> > + *
> > + * (C) Copyright 2008 Xilinx, Inc.
> > + *
> > + * This file is licensed under the terms of the GNU General Public
License
> > + * version 2. This program is licensed "as is" without any warranty
of any
> > + * kind, whether express or implied.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +/ {
> > + #address-cells =3D <1>;
> > + #size-cells =3D <1>;
> > + compatible =3D "xlnx,virtex440";
> > + dcr-parent =3D <&ppc440_0>;
> > + model =3D "testing";
> > + DDR2_SDRAM: memory@0 {
> > + device_type =3D "memory";
> > + reg =3D < 0 0x10000000 >;
> > + } ;
> > + chosen {
> > + bootargs =3D "console=3DttyS0 ip=3Don root=3D/dev/ram";
> =
> Bootargs like this should not typically go in the dts file.
> =
My understanding is the bootloader would also fill these in.
With the FGPA, a bootloader is not used many times so that's the =
reason we have put it into the dts file.
> > + linux,stdout-path =3D "/plb@0/serial@83e00000";
> > + } ;
> > + cpus {
> > + #address-cells =3D <1>;
> > + #cpus =3D <1>;
> > + #size-cells =3D <0>;
> > + ppc440_0: cpu@0 {
> > + clock-frequency =3D "";
> =
> Presumably this is supposed to be filled in by the bootloader. But in
> any case it shouldn't be a string.
> =
I think this was my screw-up as it should have the same value as the
timebase. =
Interesting, it's not being used for anything that stops the system from
working.
> [snip]
> > + DMA0: sdma@80 {
> > + compatible =3D "xlnx,ll-dma-1.00.a";
> > + dcr-reg =3D < 0x80 0x11 >;
> > + interrupt-parent =3D <&xps_intc_0>;
> > + interrupts =3D < 9 2 0xa 2 >;
> > + } ;
> =
> Putting devices under the cpu node is certainly... atypical. It's not
> obviously wrong, for a dcr device like this, but we probably want a
> little more discussion before establishing a convention like this.
> =
We had this discussion somewhat in a earlier message, 6/23 adding
virtex5 =
Powerpc 440 support, and Stephen answered with the following which still
seems
applicable.
>From Stephenn:
In Virtex 5 FX, the processor block (as represented in all the processor
design tools) is actually a processor block, plus a crossbar switch,
plus dma blocks. I think there's a tradeoff between modeling this
independently, or modeling it as an FPGA user sees it. From the
perspective of the FPGA user, this is the way the system looks (although
I agree that it's odd). What would be even better, is if the processor
block was modeled as a DTS I could write by hand, and to include it into
the generated DTS. (Another good use for grafting of device trees...)
> --
> David Gibson | I'll have my music baroque, and my
code
> david AT gibson.dropbear.id.au | minimalist, thank you. NOT
_the_ _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ 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