* Re: About mdio_bus for 82xx based board
From: Scott Wood @ 2007-07-26 15:29 UTC (permalink / raw)
To: Alexandros Kostopoulos; +Cc: linuxppc-dev
In-Reply-To: <op.tv2nbmkonhx3hy@phoenix>
Alexandros Kostopoulos wrote:
> Well, I've downloaded the latest git from Paul's tree, and some patches
> still fail (and the mpc8272_ads config doesn't compile). Must I get
> some other revision of the tree (if yes, how's that done in git - my
> first time with it )
They don't apply on top of Paul's current tree -- they apply to his tree
as of the time the patchset was posted. I should have a revised
patchset in a week or two (the delay mainly being to add and test a
couple new boards).
-Scott
^ permalink raw reply
* Re: [PATCH] POWERPC: Fix definition of global-utilites structure for 86xx
From: Kumar Gala @ 2007-07-26 15:29 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <46A8BA58.4010208@freescale.com>
On Jul 26, 2007, at 10:14 AM, Timur Tabi wrote:
> Kumar Gala wrote:
>
>> Why don't we remove this completely, nothing uses it?
>
> Should I respin the patch to include updates to mpc86xx_restart()
> to use it?
I'm wondering if we should change to code to use a #define GUT_RSTCR
offset value since it only needs one register.
- k
^ permalink raw reply
* Re: DTC 1.0.0 Release Coming?
From: Jon Loeliger @ 2007-07-26 15:21 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070726142739.GB18684@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> > > Only thing I'm not really happy with in the current release is the
> > > versioning stuff. For starters, it always reports my builds as
> > > -dirty, even when they're not.
> >
> > I think it won't do that once there is a tag available.
>
> Your 1.0.0-rc1 tag is there, still showing as dirty.
Hmmm.. Seems to work here. Is your working directory really clean?
jdl.com 872 % make clean
CLEAN (libfdt)
CLEAN (tests)
CLEAN
jdl.com 873 % make
LEX lex.yy.c
BISON dtc-parser.tab.c
---- Expect 2 s/r and 2 r/r. ----
dtc-parser.y: conflicts: 2 shift/reduce, 2 reduce/reduce
CHK version_gen.h
UPD version_gen.h
CC dtc.o
CC flattree.o
[ snip ]
CC tests/del_node.o
CC tests/truncated_property.o
AS tests/trees.o
DUMPTREES
jdl.com 874 % ./dtc -v
Version: DTC 1.0.0-rc1
I hve also verified that at least one other independent build
using this approach produces a correct version string for them
as well.
> > That is essentially what is there now. We just need a tag!
>
> Um... no. The base version comes from the numbers specified in the
> Makefile, not from the git tag.
Ah, ok. I understand what you mean now. That part.
So run it the other way instead. So perhaps have the
Makefile generate the tag using those versioning parts
instead using some "make tagged_release" target?
> > I would like to keep the current version mechanism as it
> > is really quite similar to what is in the Kernel now.
>
> First, I don't think it really is - except in superficial aspect of
> how the version number is partitioned
I lifted the code from the Kernel's Makefile directly, and tweaked
it slightly for lack of Kconfig aspects.
I don't want to tie the code and build mechanism to git too much.
Specifically, we need to be able to support stand-alone tarball
based builds. For example, I've spoken to the Debian package
maintainer on this issue, and he likes this approach as well as
he says it will make packaging it much easier.
*sigh*
jdl
^ permalink raw reply
* RE: support for MPC8220?
From: Leisner, Martin @ 2007-07-26 15:17 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linuxppc-embedded
In-Reply-To: <20070724211104.GL1678@pengutronix.de>
=20
actually, it's there -- you have to find it (I saw it once, I can't
find it again). (other search engines seem to do a better job).
I think MPC8220 runs well without MMU -- the montavista PRO 3.1 the
freescale
site discusses 2.4.20...
We ran an 8220 at one time on 2.4.20 -- I recall there was some
flakiness, and we used
a montavista system, so it must have been 3.1...
marty
> -----Original Message-----
> From: Robert Schwebel [mailto:rsc@pengutronix.de] On Behalf=20
> Of Robert Schwebel
> Sent: Tuesday, July 24, 2007 5:11 PM
> To: Leisner, Martin
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: support for MPC8220?
>=20
> On Mon, Jul 23, 2007 at 11:27:00AM -0400, Leisner, Martin wrote:
> > Is there support for MPC8220 in current kernels?
>=20
> 8220? Are you sure? That part doesn't exist on the freescale site.
>=20
> Robert=20
> --=20
> Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
> Pengutronix - Linux Solutions for Science and Industry
> Handelsregister: Amtsgericht Hildesheim, HRA 2686
> Hannoversche Str. 2, 31134 Hildesheim, Germany
> Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
>=20
>=20
^ permalink raw reply
* Re: [PATCH] POWERPC: Fix definition of global-utilites structure for 86xx
From: Timur Tabi @ 2007-07-26 15:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <8CEA1441-8408-48A9-A023-F072FBC3EEE2@kernel.crashing.org>
Kumar Gala wrote:
> Why don't we remove this completely, nothing uses it?
Should I respin the patch to include updates to mpc86xx_restart() to use it?
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: DTC 1.0.0 Release Coming?
From: David Gibson @ 2007-07-26 14:27 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IE314-0000qF-5x@jdl.com>
On Thu, Jul 26, 2007 at 08:04:30AM -0500, Jon Loeliger wrote:
> So, like, the other day David Gibson mumbled:
> > On Wed, Jul 25, 2007 at 11:12:00AM -0500, Jon Loeliger wrote:
> > > Folks,
> > >
> > > I'd like to make an official DTC Version 1.0.0 release soon!
> >
> > It would certainly be great to have a release, since dtc is becoming
> > necessary for more and more kernel builds.
> >
> > Only thing I'm not really happy with in the current release is the
> > versioning stuff. For starters, it always reports my builds as
> > -dirty, even when they're not.
>
> I think it won't do that once there is a tag available.
Your 1.0.0-rc1 tag is there, still showing as dirty.
> > It also seems a bit hideously
> > complicated for what it does. I'd prefer to see something simpler
> > using git-describe to derive the version strings directly from the git
> > tags themselves.
>
> That is essentially what is there now. We just need a tag!
Um... no. The base version comes from the numbers specified in the
Makefile, not from the git tag.
> > Obviously we need some sort of cacheing mechanism to
> > make the versioning work for tarball releases without the git history,
> > but I think we can handle that with a suitable "make dist" target.
>
> Sure.
>
> > I'll see if I can make a patch or two in the next few days.
>
> I would like to keep the current version mechanism as it
> is really quite similar to what is in the Kernel now.
First, I don't think it really is - except in superficial aspect of
how the version number is partitioned - the kernel has no auto version
generating thing of this type. Second, I don't see that being similar
to the kernel's approach has any particular usefulness here, anyway.
--
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
^ permalink raw reply
* Re: ping command
From: Ben Warren @ 2007-07-26 14:09 UTC (permalink / raw)
To: Nethra; +Cc: linuxppc-embedded
In-Reply-To: <11779249.post@talk.nabble.com>
Nethra,
On Wed, 2007-07-25 at 02:29 -0700, Nethra wrote:
> hi,
>
> I m using custom board same as eval board MPC8272ADS board.
>
> IP assigned for both ethernets are...
>
> ifconfig eth1 192.168.33.135 up
> ifconfig eth1 netmask 255.255.248.0
> route add default gw 192.168.32.47 eth1
>
>
> ifconfig eth0 192.168.178.89 up
> ifconfig eth0netmask 255.255.255.0
> route add default gw 192.168.178.47 eth0
>
> but if i try for ping 192.168.33.135 command pails by the server of 178
> series
> similarly ping 192.168.178.89 command pails by the server of 33 series..
>
> what is the problem..and whre i m going wrong..?
What does your routing table show? (route -n). It wouldn't hurt to
also post the output of ifconfig for both interfaces.
regards,
Ben
^ permalink raw reply
* [PATCH] mpc832x_rdb.c: prevent using uninitialized variable
From: Anton Vorontsov @ 2007-07-26 14:01 UTC (permalink / raw)
To: linuxppc-dev
If CONFIG_PCI undefined, np will be used uninitialized, thereby
find_node_by_name(np, "par_io") will fail.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index c5463c7..b16dce2 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -79,14 +79,14 @@ device_initcall(mpc83xx_spi_devices_init);
static void __init mpc832x_rdb_setup_arch(void)
{
#if defined(CONFIG_PCI) || defined(CONFIG_QUICC_ENGINE)
- struct device_node *np;
+ struct device_node *np = NULL;
#endif
if (ppc_md.progress)
ppc_md.progress("mpc832x_rdb_setup_arch()", 0);
#ifdef CONFIG_PCI
- for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
+ for (; (np = of_find_node_by_type(np, "pci")) != NULL;)
mpc83xx_add_bridge(np);
ppc_md.pci_exclude_device = mpc83xx_exclude_device;
--
1.5.0.6
^ permalink raw reply related
* [RFC][PATCH] MPC832x_RDB: update dts to use spi, register mmc_spi stub
From: Anton Vorontsov @ 2007-07-26 13:57 UTC (permalink / raw)
To: linuxppc-dev
mmc_spi already tested to work. When it will hit mainline
the only change that would be needed is replacing "spidev"
by "mmc_spi", and adding trivial platform data to mmc_spi
driver.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc832x_rdb.dts | 33 ++++++++++++++++++++-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 46 +++++++++++++++++++++++++++++
2 files changed, 78 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index 7c4beff..5dcbdd3 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -183,6 +183,21 @@
1 c 1 0 1 0 /* TX_EN */
1 d 2 0 1 0>; /* CRS */
};
+ spi1pio:spi_pin@01 {
+ pio-map = <
+ /* port pin dir open_drain assignment has_irq */
+ 3 0 3 0 1 0 /* SPI1 MOSI, I/O */
+ 3 1 3 0 1 0 /* SPI1 MISO, I/O */
+ 3 2 3 0 1 0 /* SPI1 CLK, I/O */
+ 3 3 2 0 1 0>; /* SPI1 SEL, I */
+ };
+ mmc1pio:mmc_pin@01 {
+ pio-map = <
+ /* port pin dir open_drain assignment has_irq */
+ 3 d 1 0 0 0 /* !SD_CS */
+ 3 e 2 0 0 0 /* SD_INSERT */
+ 3 f 2 0 0 0>; /* SD_PROTECT */
+ };
};
};
@@ -207,20 +222,36 @@
spi@4c0 {
device_type = "spi";
+ device-id = <1>;
compatible = "fsl_spi";
reg = <4c0 40>;
interrupts = <2>;
interrupt-parent = <&qeic>;
- mode = "cpu";
+ mode = "qe";
+ sysclk = <5f5e100>; /* 100000000 Hz */
+ max-chipselect = <1>;
+ pio-handle = <&spi1pio>;
+
+ mmc@01 {
+ device_type = "mmc";
+ compatible = "mmc-spi";
+ device-id = <1>;
+ max-speed-hz = <bebc20>; /* 12500000 Hz */
+ chip-select = <0>;
+ pio-handle = <&mmc1pio>;
+ };
};
spi@500 {
device_type = "spi";
+ device-id = <2>;
compatible = "fsl_spi";
reg = <500 40>;
interrupts = <1>;
interrupt-parent = <&qeic>;
mode = "cpu";
+ sysclk = <5f5e100>; /* 100000000 Hz */
+ max_chipselect = <1>;
};
ucc@3000 {
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index b2b28a4..c5463c7 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -15,6 +15,7 @@
*/
#include <linux/pci.h>
+#include <linux/spi/spi.h>
#include <asm/of_platform.h>
#include <asm/time.h>
@@ -24,6 +25,7 @@
#include <asm/qe_ic.h>
#include "mpc83xx.h"
+#include "../../sysdev/fsl_soc.h"
#undef DEBUG
#ifdef DEBUG
@@ -32,6 +34,43 @@
#define DBG(fmt...)
#endif
+extern int par_io_data_set(u8 port, u8 pin, u8 val);
+
+static void mpc83xx_spi_activate_cs(u8 cs, u8 polarity)
+{
+ pr_debug("%s %d %d\n", __func__, cs, polarity);
+ par_io_data_set(3, 13, polarity);
+}
+
+static void mpc83xx_spi_deactivate_cs(u8 cs, u8 polarity)
+{
+ pr_debug("%s %d %d\n", __func__, cs, polarity);
+ par_io_data_set(3, 13, !polarity);
+}
+
+static int __init mpc83xx_spi_devices_init(void)
+{
+ struct spi_board_info spi_bi = {
+ .bus_num = 1,
+ /*
+ * XXX: This is spidev (spi in userspace) stub, should
+ * be replaced by "mmc_spi" when mmc_spi will hit mainline.
+ */
+ .modalias = "spidev",
+ };
+ struct device_node *np = NULL;
+
+ np = of_find_compatible_node(np, "mmc", "mmc-spi");
+ if (!np)
+ return 0;
+
+ spi_bi.max_speed_hz = *((u32 *)of_get_property(np, "max-speed-hz", NULL));
+ spi_bi.chip_select = *((u32 *)of_get_property(np, "chip-select", NULL));
+
+ return spi_register_board_info(&spi_bi, 1);
+}
+device_initcall(mpc83xx_spi_devices_init);
+
/* ************************************************************************
*
* Setup the architecture
@@ -62,8 +101,15 @@ static void __init mpc832x_rdb_setup_arch(void)
for (np = NULL; (np = of_find_node_by_name(np, "ucc")) != NULL;)
par_io_of_config(np);
+ for (np = NULL; (np = of_find_node_by_name(np, "spi")) != NULL;)
+ par_io_of_config(np);
+ for (np = NULL; (np = of_find_node_by_name(np, "mmc")) != NULL;)
+ par_io_of_config(np);
}
#endif /* CONFIG_QUICC_ENGINE */
+
+ fsl_spi_activate_cs = mpc83xx_spi_activate_cs;
+ fsl_spi_deactivate_cs = mpc83xx_spi_deactivate_cs;
}
static struct of_device_id mpc832x_ids[] = {
--
1.5.0.6
^ permalink raw reply related
* [RFC][PATCH] fsl_soc: add support for fsl_spi
From: Anton Vorontsov @ 2007-07-26 13:56 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/fsl_soc.c | 76 +++++++++++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/fsl_soc.h | 3 ++
2 files changed, 79 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3289fab..0599851 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -1125,3 +1125,79 @@ err:
arch_initcall(cpm_smc_uart_of_init);
#endif /* CONFIG_8xx */
+
+void (*fsl_spi_activate_cs)(u8 cs, u8 polarity) = NULL;
+EXPORT_SYMBOL(fsl_spi_activate_cs);
+void (*fsl_spi_deactivate_cs)(u8 cs, u8 polarity) = NULL;
+EXPORT_SYMBOL(fsl_spi_deactivate_cs);
+
+static int __init fsl_spi_of_init(void)
+{
+ struct device_node *np;
+ unsigned int i;
+
+ for (np = NULL, i = 1;
+ (np = of_find_compatible_node(np, "spi", "fsl_spi")) != NULL;
+ i++) {
+ int ret = 0;
+ const char *devid, *sysclk, *mode, *max_cs;
+ struct resource res[2];
+ struct platform_device *pdev = NULL;
+ struct fsl_spi_platform_data pdata = {
+ .activate_cs = fsl_spi_activate_cs,
+ .deactivate_cs = fsl_spi_deactivate_cs,
+ };
+
+ memset(res, 0, sizeof(res));
+
+ devid = of_get_property(np, "device-id", NULL);
+ sysclk = of_get_property(np, "sysclk", NULL);
+ mode = of_get_property(np, "mode", NULL);
+ max_cs = of_get_property(np, "max-chipselect", NULL);
+ if (!devid || !sysclk || !mode || !max_cs)
+ goto err;
+
+ pdata.bus_num = *(u32 *)devid;
+ pdata.sysclk = *(u32 *)sysclk;
+ pdata.max_chipselect = *(u32 *)max_cs;
+ if (!strcmp(mode, "qe"))
+ pdata.qe_mode = 1;
+
+ ret = of_address_to_resource(np, 0, &res[0]);
+ if (ret)
+ goto err;
+
+ res[1].start = res[2].end = irq_of_parse_and_map(np, 0);
+ if (res[1].start == NO_IRQ)
+ goto err;
+
+ res[1].name = "mpc83xx_spi";
+ res[1].flags = IORESOURCE_IRQ;;
+
+ pdev = platform_device_alloc("mpc83xx_spi", i);
+ if (!pdev)
+ goto err;
+
+ ret = platform_device_add_data(pdev, &pdata, sizeof(pdata));
+ if (ret)
+ goto unreg;
+
+ ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
+ if (ret)
+ goto unreg;
+
+ ret = platform_device_register(pdev);
+ if (ret)
+ goto unreg;
+
+ continue;
+unreg:
+ platform_device_del(pdev);
+err:
+ continue;
+ }
+
+ return 0;
+}
+
+arch_initcall(fsl_spi_of_init);
diff --git a/arch/powerpc/sysdev/fsl_soc.h b/arch/powerpc/sysdev/fsl_soc.h
index 04e145b..c9de2a2 100644
--- a/arch/powerpc/sysdev/fsl_soc.h
+++ b/arch/powerpc/sysdev/fsl_soc.h
@@ -8,5 +8,8 @@ extern phys_addr_t get_immrbase(void);
extern u32 get_brgfreq(void);
extern u32 get_baudrate(void);
+extern void (*fsl_spi_activate_cs)(u8 cs, u8 polarity);
+extern void (*fsl_spi_deactivate_cs)(u8 cs, u8 polarity);
+
#endif
#endif
--
1.5.0.6
^ permalink raw reply related
* [PATCH 3/3] [POWERPC][SPI] spi_mpc83xx: add support for loopback mode
From: Anton Vorontsov @ 2007-07-26 13:51 UTC (permalink / raw)
To: spi-devel-general; +Cc: linuxppc-dev
In-Reply-To: <20070726134754.GA3539@localhost.localdomain>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/spi/spi_mpc83xx.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
index 458075a..e9582d3 100644
--- a/drivers/spi/spi_mpc83xx.c
+++ b/drivers/spi/spi_mpc83xx.c
@@ -39,6 +39,7 @@ struct mpc83xx_spi_reg {
};
/* SPI Controller mode register definitions */
+#define SPMODE_LOOP (1 << 30)
#define SPMODE_CI_INACTIVEHIGH (1 << 29)
#define SPMODE_CP_BEGIN_EDGECLK (1 << 28)
#define SPMODE_DIV16 (1 << 27)
@@ -155,7 +156,7 @@ static void mpc83xx_spi_chipselect(struct spi_device *spi, int value)
/* mask out bits we are going to set */
regval &= ~(SPMODE_CP_BEGIN_EDGECLK | SPMODE_CI_INACTIVEHIGH |
SPMODE_LEN(0xF) | SPMODE_DIV16 | SPMODE_PM(0xF) | \
- SPMODE_REV);
+ SPMODE_REV | SPMODE_LOOP);
if (spi->mode & SPI_CPHA)
regval |= SPMODE_CP_BEGIN_EDGECLK;
@@ -163,6 +164,8 @@ static void mpc83xx_spi_chipselect(struct spi_device *spi, int value)
regval |= SPMODE_CI_INACTIVEHIGH;
if (!(spi->mode & SPI_LSB_FIRST))
regval |= SPMODE_REV;
+ if (spi->mode & SPI_LOOP)
+ regval |= SPMODE_LOOP;
regval |= SPMODE_LEN(len);
@@ -273,7 +276,8 @@ int mpc83xx_spi_setup_transfer(struct spi_device *spi, struct spi_transfer *t)
}
/* the spi->mode bits understood by this driver: */
-#define MODEBITS (SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | SPI_LSB_FIRST)
+#define MODEBITS (SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | SPI_LSB_FIRST | \
+ SPI_LOOP)
static int mpc83xx_spi_setup(struct spi_device *spi)
{
--
1.5.0.6
^ permalink raw reply related
* [PATCH 2/3] [SPI] Add new mode: SPI_LOOP
From: Anton Vorontsov @ 2007-07-26 13:50 UTC (permalink / raw)
To: spi-devel-general; +Cc: linuxppc-dev
In-Reply-To: <20070726134754.GA3539@localhost.localdomain>
Loopback mode is supported by various controllers, this mode
is useful for testing, especially in conjunction with spidev
driver.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/spi/spidev.c | 2 +-
include/linux/spi/spi.h | 1 +
include/linux/spi/spidev.h | 1 +
3 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index 4c51a61..24c8d4d 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -57,7 +57,7 @@ static unsigned long minors[N_SPI_MINORS / BITS_PER_LONG];
/* Bit masks for spi_device.mode management */
#define SPI_MODE_MASK (SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | \
- SPI_LSB_FIRST | SPI_3WIRE)
+ SPI_LSB_FIRST | SPI_3WIRE | SPI_LOOP)
struct spidev_data {
struct device dev;
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 302b81d..e180615 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -77,6 +77,7 @@ struct spi_device {
#define SPI_CS_HIGH 0x04 /* chipselect active high? */
#define SPI_LSB_FIRST 0x08 /* per-word bits-on-wire */
#define SPI_3WIRE 0x10 /* SI/SO signals shared */
+#define SPI_LOOP 0x20 /* loopback mode */
u8 bits_per_word;
int irq;
void *controller_state;
diff --git a/include/linux/spi/spidev.h b/include/linux/spi/spidev.h
index 369d42e..c93ef9d 100644
--- a/include/linux/spi/spidev.h
+++ b/include/linux/spi/spidev.h
@@ -38,6 +38,7 @@
#define SPI_CS_HIGH 0x04
#define SPI_LSB_FIRST 0x08
#define SPI_3WIRE 0x10
+#define SPI_LOOP 0x20
/*---------------------------------------------------------------------------*/
--
1.5.0.6
^ permalink raw reply related
* [PATCH 1/3] [SPI] Sync spidev.{h,c} with spi.h
From: Anton Vorontsov @ 2007-07-26 13:50 UTC (permalink / raw)
To: spi-devel-general; +Cc: linuxppc-dev
In-Reply-To: <20070726134754.GA3539@localhost.localdomain>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/spi/spidev.c | 4 ++--
include/linux/spi/spidev.h | 3 +++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index 38b60ad..4c51a61 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -56,8 +56,8 @@ static unsigned long minors[N_SPI_MINORS / BITS_PER_LONG];
/* Bit masks for spi_device.mode management */
-#define SPI_MODE_MASK (SPI_CPHA | SPI_CPOL)
-
+#define SPI_MODE_MASK (SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | \
+ SPI_LSB_FIRST | SPI_3WIRE)
struct spidev_data {
struct device dev;
diff --git a/include/linux/spi/spidev.h b/include/linux/spi/spidev.h
index 7d700be..369d42e 100644
--- a/include/linux/spi/spidev.h
+++ b/include/linux/spi/spidev.h
@@ -35,6 +35,9 @@
#define SPI_MODE_2 (SPI_CPOL|0)
#define SPI_MODE_3 (SPI_CPOL|SPI_CPHA)
+#define SPI_CS_HIGH 0x04
+#define SPI_LSB_FIRST 0x08
+#define SPI_3WIRE 0x10
/*---------------------------------------------------------------------------*/
--
1.5.0.6
^ permalink raw reply related
* [PATCH 0/3] [SPI] loopback mode support, [POWERPC] loopback mode for spi_mpc83xx
From: Anton Vorontsov @ 2007-07-26 13:47 UTC (permalink / raw)
To: spi-devel-general; +Cc: linuxppc-dev
Hi all,
Here are three patches:
1. syncing spidev driver with new modes of spi subsystem;
2. spi subsystem support for loopback mode;
3. loopback mode support for spi_mpc83xx.
Because patch 3 depends on 1 and 2, I'm Cc'ing both lists
for all three patches.
They're based on Linus' tree as of today.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH 4/4] [POWERPC][SPI] spi_mpc83xx: fix LSB mode shifts
From: Anton Vorontsov @ 2007-07-26 13:14 UTC (permalink / raw)
To: spi-devel-general; +Cc: linuxppc-dev
In-Reply-To: <20070726131134.GA3309@localhost.localdomain>
spi_mpc83xx should use other shifts when running in QE+LSB mode.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/spi/spi_mpc83xx.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
index 7e17c8b..458075a 100644
--- a/drivers/spi/spi_mpc83xx.c
+++ b/drivers/spi/spi_mpc83xx.c
@@ -237,6 +237,14 @@ int mpc83xx_spi_setup_transfer(struct spi_device *spi, struct spi_transfer *t)
} else
return -EINVAL;
+ if (mpc83xx_spi->qe_mode && spi->mode & SPI_LSB_FIRST) {
+ mpc83xx_spi->tx_shift = 0;
+ if (bits_per_word <= 8)
+ mpc83xx_spi->rx_shift = 8;
+ else
+ mpc83xx_spi->rx_shift = 0;
+ }
+
/* nsecs = (clock period)/2 */
if (!hz)
hz = spi->max_speed_hz;
--
1.5.0.6
^ permalink raw reply related
* [PATCH 3/4] [POWERPC][SPI] spi_mpc83xx: support for lsb mode switching
From: Anton Vorontsov @ 2007-07-26 13:14 UTC (permalink / raw)
To: spi-devel-general; +Cc: linuxppc-dev
In-Reply-To: <20070726131134.GA3309@localhost.localdomain>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/spi/spi_mpc83xx.c | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
index e2d8dbc..7e17c8b 100644
--- a/drivers/spi/spi_mpc83xx.c
+++ b/drivers/spi/spi_mpc83xx.c
@@ -154,12 +154,15 @@ static void mpc83xx_spi_chipselect(struct spi_device *spi, int value)
/* mask out bits we are going to set */
regval &= ~(SPMODE_CP_BEGIN_EDGECLK | SPMODE_CI_INACTIVEHIGH |
- SPMODE_LEN(0xF) | SPMODE_DIV16 | SPMODE_PM(0xF));
+ SPMODE_LEN(0xF) | SPMODE_DIV16 | SPMODE_PM(0xF) | \
+ SPMODE_REV);
if (spi->mode & SPI_CPHA)
regval |= SPMODE_CP_BEGIN_EDGECLK;
if (spi->mode & SPI_CPOL)
regval |= SPMODE_CI_INACTIVEHIGH;
+ if (!(spi->mode & SPI_LSB_FIRST))
+ regval |= SPMODE_REV;
regval |= SPMODE_LEN(len);
@@ -248,9 +251,11 @@ int mpc83xx_spi_setup_transfer(struct spi_device *spi, struct spi_transfer *t)
regval = mpc83xx_spi_read_reg(&mpc83xx_spi->base->mode);
- /* Mask out bits_per_wordgth */
- regval &= ~SPMODE_LEN(0xF);
+ /* mask out bits we are going to set */
+ regval &= ~(SPMODE_LEN(0xF) | SPMODE_REV);
regval |= SPMODE_LEN(bits_per_word);
+ if (!(spi->mode & SPI_LSB_FIRST))
+ regval |= SPMODE_REV;
/* Turn off SPI unit prior changing mode */
mpc83xx_spi_write_reg(&mpc83xx_spi->base->mode, 0);
@@ -260,7 +265,7 @@ int mpc83xx_spi_setup_transfer(struct spi_device *spi, struct spi_transfer *t)
}
/* the spi->mode bits understood by this driver: */
-#define MODEBITS (SPI_CPOL | SPI_CPHA | SPI_CS_HIGH)
+#define MODEBITS (SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | SPI_LSB_FIRST)
static int mpc83xx_spi_setup(struct spi_device *spi)
{
--
1.5.0.6
^ permalink raw reply related
* [PATCH 2/4] [POWERPC][SPI] spi_mpc83xx: get rid of magic numbers
From: Anton Vorontsov @ 2007-07-26 13:14 UTC (permalink / raw)
To: spi-devel-general; +Cc: linuxppc-dev
In-Reply-To: <20070726131134.GA3309@localhost.localdomain>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/spi/spi_mpc83xx.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
index 0b99fd9..e2d8dbc 100644
--- a/drivers/spi/spi_mpc83xx.c
+++ b/drivers/spi/spi_mpc83xx.c
@@ -153,7 +153,8 @@ static void mpc83xx_spi_chipselect(struct spi_device *spi, int value)
len = len - 1;
/* mask out bits we are going to set */
- regval &= ~0x38ff0000;
+ regval &= ~(SPMODE_CP_BEGIN_EDGECLK | SPMODE_CI_INACTIVEHIGH |
+ SPMODE_LEN(0xF) | SPMODE_DIV16 | SPMODE_PM(0xF));
if (spi->mode & SPI_CPHA)
regval |= SPMODE_CP_BEGIN_EDGECLK;
@@ -248,7 +249,7 @@ int mpc83xx_spi_setup_transfer(struct spi_device *spi, struct spi_transfer *t)
regval = mpc83xx_spi_read_reg(&mpc83xx_spi->base->mode);
/* Mask out bits_per_wordgth */
- regval &= 0xff0fffff;
+ regval &= ~SPMODE_LEN(0xF);
regval |= SPMODE_LEN(bits_per_word);
/* Turn off SPI unit prior changing mode */
--
1.5.0.6
^ permalink raw reply related
* [PATCH 1/4] [POWERPC][SPI] spi_mpc83xx.c: should turn off SPI unit while switching any mode.
From: Anton Vorontsov @ 2007-07-26 13:13 UTC (permalink / raw)
To: spi-devel-general; +Cc: linuxppc-dev
In-Reply-To: <20070726131134.GA3309@localhost.localdomain>
Documentation clearly states, that mode should not be changed
till SPMODE_ENABLE bit set. I've seen hangs w/o this patch.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/spi/spi_mpc83xx.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
index 3295cfc..0b99fd9 100644
--- a/drivers/spi/spi_mpc83xx.c
+++ b/drivers/spi/spi_mpc83xx.c
@@ -176,6 +176,8 @@ static void mpc83xx_spi_chipselect(struct spi_device *spi, int value)
regval |= SPMODE_PM(pm);
}
+ /* Turn off SPI unit prior changing mode */
+ mpc83xx_spi_write_reg(&mpc83xx_spi->base->mode, 0);
mpc83xx_spi_write_reg(&mpc83xx_spi->base->mode, regval);
if (mpc83xx_spi->activate_cs)
mpc83xx_spi->activate_cs(spi->chip_select, pol);
@@ -249,6 +251,8 @@ int mpc83xx_spi_setup_transfer(struct spi_device *spi, struct spi_transfer *t)
regval &= 0xff0fffff;
regval |= SPMODE_LEN(bits_per_word);
+ /* Turn off SPI unit prior changing mode */
+ mpc83xx_spi_write_reg(&mpc83xx_spi->base->mode, 0);
mpc83xx_spi_write_reg(&mpc83xx_spi->base->mode, regval);
return 0;
--
1.5.0.6
^ permalink raw reply related
* [PATCH 0/4] Few spi_mpc83xx.c fixes and improvements
From: Anton Vorontsov @ 2007-07-26 13:11 UTC (permalink / raw)
To: spi-devel-general; +Cc: linuxppc-dev
Hi all,
These patches based on Linus' tree, as of today.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [Trace how to] Kernel Bug when entering something after login
From: Juergen Beisert @ 2007-07-26 12:45 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linux-rt-users
In-Reply-To: <f87351060707260534k2f87ff47rdcfd0b787d5a0132@mail.gmail.com>
On Thursday 26 July 2007 14:34, Pradyumna Sampath wrote:
> Hi Everyone,
>
> On 7/26/07, Juergen Beisert <juergen127@kreuzholzen.de> wrote:
> > On Wednesday 25 July 2007 21:06, Thomas Gleixner wrote:
> > > Solution below
> >
> > Seems to work now. Thanks.
> >
> > Juergen
> > -
>
> First of all very sorry to cross post.
>
> I discovered the same problem on our MPC5200 and it after patching, it
> now works. But I could somehow not get the call trace and hence could
> not report the bug.
>
> I compiled the kernel with "CONFIG_FUNCTION_TRACE" and then I get
> undefined references on "early_printk". Is there something I am doing
> wrong in the kernel config or was there an additional patch to enable
> this support for MPC5200 ?
>
> I see more bugs when I run "stress" but I cant solve them or even
> report them, because I cant see the trace information.
Activate "General setup" -> "Configure standard kernel features (for small
systems)" -> "Load all symbols for debugging/ksymoops"
Juergen
^ permalink raw reply
* Re: DTC 1.0.0 Release Coming?
From: Jon Loeliger @ 2007-07-26 13:04 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070726030550.GA1149@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> On Wed, Jul 25, 2007 at 11:12:00AM -0500, Jon Loeliger wrote:
> > Folks,
> >
> > I'd like to make an official DTC Version 1.0.0 release soon!
>
> It would certainly be great to have a release, since dtc is becoming
> necessary for more and more kernel builds.
>
> Only thing I'm not really happy with in the current release is the
> versioning stuff. For starters, it always reports my builds as
> -dirty, even when they're not.
I think it won't do that once there is a tag available.
> It also seems a bit hideously
> complicated for what it does. I'd prefer to see something simpler
> using git-describe to derive the version strings directly from the git
> tags themselves.
That is essentially what is there now. We just need a tag!
> Obviously we need some sort of cacheing mechanism to
> make the versioning work for tarball releases without the git history,
> but I think we can handle that with a suitable "make dist" target.
Sure.
> I'll see if I can make a patch or two in the next few days.
I would like to keep the current version mechanism as it
is really quite similar to what is in the Kernel now.
Thanks,
jdl
^ permalink raw reply
* [Trace how to] Kernel Bug when entering something after login
From: Pradyumna Sampath @ 2007-07-26 12:34 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linux-rt-users, linuxppc-embedded
In-Reply-To: <200707261000.25465.juergen127@kreuzholzen.de>
Hi Everyone,
On 7/26/07, Juergen Beisert <juergen127@kreuzholzen.de> wrote:
> On Wednesday 25 July 2007 21:06, Thomas Gleixner wrote:
> > Solution below
>
> Seems to work now. Thanks.
>
> Juergen
> -
First of all very sorry to cross post.
I discovered the same problem on our MPC5200 and it after patching, it
now works. But I could somehow not get the call trace and hence could
not report the bug.
I compiled the kernel with "CONFIG_FUNCTION_TRACE" and then I get
undefined references on "early_printk". Is there something I am doing
wrong in the kernel config or was there an additional patch to enable
this support for MPC5200 ?
I see more bugs when I run "stress" but I cant solve them or even
report them, because I cant see the trace information.
thanks in advance
regards
/prady
--
htp://prady.livejournal.com
^ permalink raw reply
* Re: About mdio_bus for 82xx based board
From: Alexandros Kostopoulos @ 2007-07-26 12:22 UTC (permalink / raw)
To: Alexandros Kostopoulos, Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <op.tv2kmbgqnhx3hy@phoenix>
Well, I've downloaded the latest git from Paul's tree, and some patches
still fail (and the mpc8272_ads config doesn't compile). Must I get some
other revision of the tree (if yes, how's that done in git - my first time
with it )
thanks
alex
On Thu, 26 Jul 2007 14:24:01 +0300, Alexandros Kostopoulos
<akostop@inaccessnetworks.com> wrote:
> Oops! I've just noticed in your previous mail that I need to apply the
> patches to Paul's tree...Sorry 'bout that... my mistake
>
> alex
>
>
> On Thu, 26 Jul 2007 13:42:46 +0300, Alexandros Kostopoulos
> <akostop@inaccessnetworks.com> wrote:
>
>> Hello Scott,
>>
>> Thanks for your response. I'm trying to apply your patches to vanilla
>> 2.6.22.1 kernel, but unfortunately some patches fail, namely:
>>
>> patching file arch/powerpc/boot/dts/mpc8272ads.dts
>> Hunk #1 FAILED at 10.
>>
>> patching file arch/powerpc/boot/Makefile
>> Hunk #1 FAILED at 44.
>>
>> patching file arch/powerpc/boot/Makefile
>> Hunk #1 FAILED at 48.
>>
>> patching file arch/powerpc/platforms/Kconfig
>> Hunk #1 FAILED at 19.
>>
>> and others, and also some patches appear to be already applied.
>>
>> Maybe I'm patching the wrong kernel version?
>>
>> thanks
>>
>> Alex
>>
>> On Wed, 25 Jul 2007 19:23:05 +0300, Scott Wood
>> <scottwood@freescale.com> wrote:
>>
>>> On Wed, Jul 25, 2007 at 05:22:40PM +0300, Alexandros Kostopoulos wrote:
>>>> 1) When mdiobus_register() called from mii-bitbang.c
>>>> (fs_enet_mdio_probe()
>>>> function) attemps to do a device_register for the mdio bus, it
>>>> actually
>>>> registers the device with a bus_id in the form [0|1|...]:<phy_addr>,
>>>> that
>>>> is the first part a simple integer. This, of course, happens because
>>>> fs_enet_of_init() (fsl_soc.c) does a
>>>> platform_device_register_simple("fsl-bb-mdio", i, NULL, 0); with i
>>>> being
>>>> the first part of the bus, starting from 0. Unfortunately, when
>>>> fs_init_phy() (fs_enet_main.c) calls phy_connect() and therefore
>>>> phy_attach() (phy_device.c), the latter attempts to find the device
>>>> in the
>>>> mdio bus, but it searches using the bus_id registered in the
>>>> net_device
>>>> struct, which is in the form of <resource address>:<phy_addr>, eg.
>>>> f0000000:0, and therefore it fails... I don't know if I am doing
>>>> something
>>>> wrong here, so any hint would be greatly appreciated.
>>>
>>> The code is broken. Try applying the set of 61 patches I posted a week
>>> or so ago (you'll need to apply them to Paul's tree from around the
>>> same
>>> time, not the current tree).
>>>
>>>> 2) Since there are two ethernet@<address> nodes in my device tree,
>>>> fs_of_enet_init() calls
>>>> platform_device_register_simple("fsl-bb-mdio",...)
>>>> twice, therefore creating two mdio busses, 0 and 1, each having the
>>>> same
>>>> two devices. For example, if I have two PHYs with addresses 1 and 5, I
>>>> will get two mdio busses and 4 devices, 0:1, 0:5, 1:1 and 1:5. Well,
>>>> this
>>>> doesn't sound right to me, although I am not sure if this is a fatal
>>>> issue. Any comments?
>>>
>>> It's not right -- my patchset gets rid of all of this mess.
>>>
>>>> 3) Also, if I don't want to enter the phy interrupt in the device tree
>>>> (there is not one or I want to use PHY_POLL), what should I do? dtc
>>>> seems
>>>> to not allow -1 as a value in the reg property.
>>>
>>> Leave the property out altogether.
>>>
>>> -Scott
>>
>
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-07-26 12:10 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get some bug-fixes for powerpc, as listed below.
Thanks,
Paul.
arch/powerpc/Kconfig.debug | 2 -
arch/powerpc/boot/dts/kuroboxHD.dts | 18 +++++---
arch/powerpc/boot/dts/kuroboxHG.dts | 19 +++++---
arch/powerpc/boot/dts/mpc7448hpc2.dts | 2 -
arch/powerpc/boot/dts/mpc8544ds.dts | 8 ++++
arch/powerpc/boot/dts/mpc8568mds.dts | 6 +++
arch/powerpc/kernel/head_64.S | 7 ++-
arch/powerpc/kernel/iomap.c | 8 +++-
arch/powerpc/kernel/irq.c | 8 ++--
arch/powerpc/kernel/pci-common.c | 25 +++++++++++
arch/powerpc/kernel/pci_32.c | 20 ++++++++-
arch/powerpc/kernel/process.c | 4 ++
arch/powerpc/kernel/prom_parse.c | 2 -
arch/powerpc/kernel/setup-common.c | 4 ++
arch/powerpc/kernel/udbg.c | 2 -
arch/powerpc/mm/lmb.c | 4 +-
arch/powerpc/platforms/cell/spufs/context.c | 3 +
arch/powerpc/platforms/cell/spufs/run.c | 4 ++
arch/powerpc/platforms/cell/spufs/sched.c | 4 --
arch/powerpc/platforms/iseries/lpevents.c | 2 -
arch/powerpc/platforms/maple/pci.c | 3 +
arch/powerpc/sysdev/fsl_pci.c | 4 +-
arch/powerpc/sysdev/fsl_soc.c | 61 +++++++++++++++++++++++++++
arch/powerpc/sysdev/indirect_pci.c | 1
include/asm-powerpc/pci-bridge.h | 20 +++++++++
include/asm-powerpc/ppc_asm.h | 12 +++++
include/asm-powerpc/vio.h | 5 ++
27 files changed, 221 insertions(+), 37 deletions(-)
Alan Curry (1):
[POWERPC] Fix Pegasos keyboard detection
Benjamin Herrenschmidt (3):
[POWERPC] Add function to check if address is an IO port
[POWERPC] Make pci_iounmap actually unmap things
[POWERPC] Fix Maple platform ISA bus
Christoph Hellwig (1):
[POWERPC] spusched: Fix initial timeslice calculation
Guennadi Liakhovetski (2):
[POWERPC] Add of_register_i2c_devices()
[POWERPC] Fix RTC and device tree on linkstation machines
Kumar Gala (6):
[POWERPC] Fix PCI indirect for big-endian cfg_addr
[POWERPC] Don't try to allocate resources for a Freescale POWERPC PHB
[POWERPC] Fix ethernet PHY support on MPC8544 DS
[POWREPC] Fixup a number of modpost warnings on ppc32
[POWERPC] Only allow building of BootX text support on PPC_MULTIPLATFORM
[POWERPC] Fix register labels on show_regs() message for 4xx/Book-E
Manish Ahuja (1):
[POWERPC] Fix loop with unsigned long counter variable
Masato Noguchi (1):
[POWERPC] spufs: Fix incorrect initialization of cbe_spu_info.spus
Paul Mackerras (1):
Revert "[POWERPC] Don't complain if size-cells == 0 in prom_parse()"
Roy Zang (2):
[POWERPC] Fix mpc7448hpc2 tsi108 device_type bug
[POWERPC] Fix the ability to reset on MPC8544 DS and MPC8568 MDS boards
Stephen Rothwell (3):
[POWERPC] iSeries: We need vio_enable_interrupts
[POWERPC] iSeries: Fix section mismatch warnings
[POWERPC] iSeries: Fix section mismatch warning in lpevents
^ permalink raw reply
* Re: About mdio_bus for 82xx based board
From: Alexandros Kostopoulos @ 2007-07-26 11:24 UTC (permalink / raw)
To: Alexandros Kostopoulos, Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <op.tv2in7f5nhx3hy@phoenix>
Oops! I've just noticed in your previous mail that I need to apply the
patches to Paul's tree...Sorry 'bout that... my mistake
alex
On Thu, 26 Jul 2007 13:42:46 +0300, Alexandros Kostopoulos
<akostop@inaccessnetworks.com> wrote:
> Hello Scott,
>
> Thanks for your response. I'm trying to apply your patches to vanilla
> 2.6.22.1 kernel, but unfortunately some patches fail, namely:
>
> patching file arch/powerpc/boot/dts/mpc8272ads.dts
> Hunk #1 FAILED at 10.
>
> patching file arch/powerpc/boot/Makefile
> Hunk #1 FAILED at 44.
>
> patching file arch/powerpc/boot/Makefile
> Hunk #1 FAILED at 48.
>
> patching file arch/powerpc/platforms/Kconfig
> Hunk #1 FAILED at 19.
>
> and others, and also some patches appear to be already applied.
>
> Maybe I'm patching the wrong kernel version?
>
> thanks
>
> Alex
>
> On Wed, 25 Jul 2007 19:23:05 +0300, Scott Wood <scottwood@freescale.com>
> wrote:
>
>> On Wed, Jul 25, 2007 at 05:22:40PM +0300, Alexandros Kostopoulos wrote:
>>> 1) When mdiobus_register() called from mii-bitbang.c
>>> (fs_enet_mdio_probe()
>>> function) attemps to do a device_register for the mdio bus, it actually
>>> registers the device with a bus_id in the form [0|1|...]:<phy_addr>,
>>> that
>>> is the first part a simple integer. This, of course, happens because
>>> fs_enet_of_init() (fsl_soc.c) does a
>>> platform_device_register_simple("fsl-bb-mdio", i, NULL, 0); with i
>>> being
>>> the first part of the bus, starting from 0. Unfortunately, when
>>> fs_init_phy() (fs_enet_main.c) calls phy_connect() and therefore
>>> phy_attach() (phy_device.c), the latter attempts to find the device in
>>> the
>>> mdio bus, but it searches using the bus_id registered in the net_device
>>> struct, which is in the form of <resource address>:<phy_addr>, eg.
>>> f0000000:0, and therefore it fails... I don't know if I am doing
>>> something
>>> wrong here, so any hint would be greatly appreciated.
>>
>> The code is broken. Try applying the set of 61 patches I posted a week
>> or so ago (you'll need to apply them to Paul's tree from around the same
>> time, not the current tree).
>>
>>> 2) Since there are two ethernet@<address> nodes in my device tree,
>>> fs_of_enet_init() calls
>>> platform_device_register_simple("fsl-bb-mdio",...)
>>> twice, therefore creating two mdio busses, 0 and 1, each having the
>>> same
>>> two devices. For example, if I have two PHYs with addresses 1 and 5, I
>>> will get two mdio busses and 4 devices, 0:1, 0:5, 1:1 and 1:5. Well,
>>> this
>>> doesn't sound right to me, although I am not sure if this is a fatal
>>> issue. Any comments?
>>
>> It's not right -- my patchset gets rid of all of this mess.
>>
>>> 3) Also, if I don't want to enter the phy interrupt in the device tree
>>> (there is not one or I want to use PHY_POLL), what should I do? dtc
>>> seems
>>> to not allow -1 as a value in the reg property.
>>
>> Leave the property out altogether.
>>
>> -Scott
>
^ 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