* Re: [spi-devel-general] [PATCH 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on MPC85xx
From: David Brownell @ 2007-09-25 16:58 UTC (permalink / raw)
To: galak, avorontsov; +Cc: spi-devel-general, linuxppc-dev
In-Reply-To: <20070925151819.GA6757@localhost.localdomain>
> >> - depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
> >> + depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
> >
> > Should that really be just PPC_83xx || QUICC_ENGINE?
>
> Well, I thought about that. By now I'm unsure if every QE
> implementation will be compatible with further ones.
How many other QE implementations exist? Is that sort of
gratuitous breakage something Freescale makes a habit of?
> So far
> I've tested this driver on MPC8323 and MPC8568. If we'll see
> more and more compatible QE SPI controllers, of course we
> may just do || QUICC_ENGINE.
>
> PPC_83xx || PPC_85xx
> PPC_83xx || QUICC_ENGINE
>
> Today first option saves us four bytes. ;-)
It'd be good if someone would look at the relevant docs.
I'll wait for a PPC signoff before I forward this for
merge with SPI stuff...
_ Dave
^ permalink raw reply
* RE: EBC peripheral, access causing Machine Check
From: Dave Cogley @ 2007-09-25 16:44 UTC (permalink / raw)
To: 'Josh Boyer'; +Cc: linuxppc-embedded
In-Reply-To: <20070924184210.484d39b3@vader.jdub.homelinux.org>
[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]
Yes I thought it might be a problem with the TLB. Where does the TLB
initialization take place in the Linux kernel? I am able to access any
other peripherals on the chip as there TLB entries appear to be properly
allocated. I am remapping the physical address for all peripherals that I am
working with. I have attached the driver code for reference.
Dave
-----Original Message-----
From: Josh Boyer [mailto:jwboyer@jdub.homelinux.org]
Sent: Monday, September 24, 2007 4:42 PM
To: Dave Cogley
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: EBC peripheral, access causing Machine Check
On Mon, 24 Sep 2007 12:19:01 -0700
"Dave Cogley" <dcogley@uslinc.com> wrote:
> Good Afternoon,
>
>
>
> I am using an AMCC 440EPx processor with an FPGA peripheral attached to
the
> EBC. I am doing the entire bank configuration in the u-boot boot loader
> before Linux is loaded. I can directly read and write registers using
> memory read and write (md, nm) within area 0xC0000000 to 0xC000FFFF direct
> memory I/O within the context of u-boot without any faults. When I
attempt
> to access any register in area 0xC000000 within the context of my Linux
> device driver I get a Machine Check fault (attached text) which appears to
> be an access permission violation. I am currently running the DENX ELDK
> 2.6.19.2 platform that was specific to the "Sequoia" platform.
>
>
>
> I have configured the EBC access permissions and control resisters as
> follows for bank 1:
>
>
>
> PB1CR: 0xC003C000
>
> PB1AP: 0x80040380
You need proper TLB entries set up before you can access things. Linux
discards the MMU settings that U-Boot does. So your driver needs to call
ioremap on the physical address.
Other than that, we can't help you much without your driver code.
josh
[-- Attachment #2: banjodecoder.tar.gz --]
[-- Type: application/x-gzip, Size: 4159 bytes --]
^ permalink raw reply
* Re: [PATCH 4/7] [POWERPC] QE pario: support for MPC85xx layout
From: Kim Phillips @ 2007-09-25 16:41 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070925143440.GD5323@localhost.localdomain>
On Tue, 25 Sep 2007 18:34:40 +0400
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> 8 bytes padding required to match MPC85xx registers layout.
<sigh>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Reviewed-by: Kim Phillips <kim.phillips@freescale.com>
Kim
^ permalink raw reply
* Re: jffs2 file system on MPC8272ADS board
From: Vitaly Bordug @ 2007-09-25 16:22 UTC (permalink / raw)
To: Nethra; +Cc: linuxppc-dev
In-Reply-To: <12873530.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 2592 bytes --]
Hello Nethra,
On Mon, 24 Sep 2007 22:47:38 -0700 (PDT)
Nethra wrote:
>
> hi everyone,
>
> I m using custom board similar to MPC8272ADS board...
>
> 1) For the first time it boots up properly in case if we overwrite any
> existing binaries using nfs mounted file system on the board, after
> rebooting it displays fallowing message...
>
> Further such events for this erase block will not be printed
> Eep. Child "null" (ino #1346) of dir ino #3 doesn't exist!
> Eep. Child "autocomm" (ino #463) of dir ino #461 doesn't exist!
> Eep. Child "calibration" (ino #464) of dir ino #461 doesn't exist!
> Eep. Child "coredsp_driver.ko" (ino #939) of dir ino #336 doesn't exist!
> Inode #1307 was a directory with children - removing those too...
> Inode #564 was a directory with children - removing those too...
> Inode #565 was a directory with children - removing those too...
> Inode #1112 was a directory with children - removing those too...
> Inode #1115 was a directory with children - removing those too...
> Inode #1118 was a directory with children - removing those too...
> Inode #1123 was a directory with children - removing those too...
>
> after this board boots up properly....but it not be having overwritten files
>
Have you created jffs2 file system on flash prior to mounting it?
> 2) while booting up for the first time itself it will display the falowing
> message..
>
> modprobe: FATAL: Could not load
> /lib/modules/2.6.10_mvl401-8272ads/modules.dep: No such file or dire
> ctory
>
> but after this also board boots up properly
>
You are missing modules.dep, since haven't run depmod. Issue in from target and it will get cured.
> 3) when board is running properly in between it starts printing on console
> repeatedly...
>
Do the proper MTD partitions setup, erase the partition and create jffs2 filesystem on it.
If after all those steps you're still getting output, that is prolly flakey flash.
> Header CRC failed on REF_PRISTINE node at 0x00638a6c: Read 0xffffffff,
> calculated 0x44660075
> Node totlen on flash (0xffffffff) != totlen from node ref (0x00000254)
> Header CRC failed on REF_PRISTINE node at 0x00638cc0: Read 0xffffffff,
> calculated 0x44660075
[...]
> and
>
> file system is created using fallowing command..
>
> mkfs.jffs2 -r RFS_NEW/ -e 0x20000 -o /tftpboot/jffs2_img -b
>
I am recalling playing with the options upper also cured the jffs2 warnings (not as many as yours but anyway)
> do we need padding or not..?
I'd say that we do not. but it depends
--
Vitaly
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: MPC8560 CPM2 SCC(UART) Driver CPM_UART_CONSOLE
From: Vitaly Bordug @ 2007-09-25 15:59 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070925104704.M46195@cdotd.ernet.in>
Hello Deepak,
On Tue, 25 Sep 2007 17:33:59 +0630
Deepak Gaur wrote:
> Hi all,
>
> I am writing a kernel module which is required to parse the characters received from a
> device attached to MPC8560 SCC2 (UART slave mode) on serial interface. This SCC is
> required to be configured for single-buffer, character based operation. Moreover on
> another SCC (SCC1 UART master mode) the board debug interface(console) is connected.
>
> While trying to figure out CPM UART device driver interface available in file
> drivers/serial/cpm_uart/cpm_uart_core.c for my kernel module I found that some of the
> functions are available when CPM_UART_CONSOLE is enabled.
>
> My doubt is regarding status of this flag for my hardware setup. Should this flag be
> enabled or not. If it is required to be enabled for supporting SCC1 then how SCC2 will
> be handled?
>
well, console is normally initialized early, before actual uart driver, that's why those bits are hidden
behind CPM_UART_CONSOLE.
I suppose you'll just have to get SCC2 uart to work and use ttyCPM1... or if you application is more specific, write another driver
using cpm_uart_core.c as a reference. But I would not recommend using CPM_UART_CONSOLE stuff - it's pretty restricted and assumes very early triggering, with plenty of stuff not initialized.
> As I am a novice in this area , I shall be grateful if you please guide me in
> understanding this driver code.
>
> with regards,
>
> Deepak Gaur
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Sincerely, Vitaly
^ permalink raw reply
* Re: MPC8560 CPM2 SCC(UART) Driver CPM_UART_CONSOLE
From: Scott Wood @ 2007-09-25 15:43 UTC (permalink / raw)
To: Deepak Gaur; +Cc: linuxppc-dev
In-Reply-To: <20070925104704.M46195@cdotd.ernet.in>
On Tue, Sep 25, 2007 at 05:33:59PM +0630, Deepak Gaur wrote:
> I am writing a kernel module which is required to parse the characters received from a
> device attached to MPC8560 SCC2 (UART slave mode) on serial interface. This SCC is
> required to be configured for single-buffer, character based operation. Moreover on
> another SCC (SCC1 UART master mode) the board debug interface(console) is connected.
>
> While trying to figure out CPM UART device driver interface available in file
> drivers/serial/cpm_uart/cpm_uart_core.c for my kernel module I found that some of the
> functions are available when CPM_UART_CONSOLE is enabled.
>
> My doubt is regarding status of this flag for my hardware setup. Should this flag be
> enabled or not. If it is required to be enabled for supporting SCC1 then how SCC2 will
> be handled?
That flag should only be set on the actual console. What is it that you
need to do with the other port that the driver won't currently do?
-Scott
^ permalink raw reply
* Re: jffs2 file system on MPC8272ADS
From: Scott Wood @ 2007-09-25 15:23 UTC (permalink / raw)
To: Nethra; +Cc: linuxppc-embedded
In-Reply-To: <12873633.post@talk.nabble.com>
On Mon, Sep 24, 2007 at 11:01:55PM -0700, Nethra wrote:
[snip]
> Header CRC failed on REF_PRISTINE node at 0x0063b24c: Read 0xffffffff,
> calculated 0x44660075
> Node totlen on flash (0xffffffff) != totlen from node ref (0x000002b4)
> Header CRC failed on REF_PRISTINE node at 0x0063b500: Read 0xffffffff,
> calculated 0x44660075
> Node totlen on flash (0xffffffff) != totlen from node ref (0x000002c8)
> Header CRC failed on REF_PRISTINE node at 0x0063b7c8: Read 0xffffffff,
> calculated 0x44660075
>
> are they debug messages or warnings...?
They are errors.
> # CONFIG_MTD_MAP_BANK_WIDTH_1 is not set
> # CONFIG_MTD_MAP_BANK_WIDTH_2 is not set
> CONFIG_MTD_MAP_BANK_WIDTH_4=y
> # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
> # CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
> # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
> # CONFIG_MTD_CFI_I1 is not set
> CONFIG_MTD_CFI_I2=y
> # CONFIG_MTD_CFI_I4 is not set
> # CONFIG_MTD_CFI_I8 is not set
[snip]
> #
> # Mapping drivers for chip access
> #
> # CONFIG_MTD_COMPLEX_MAPPINGS is not set
> CONFIG_MTD_PHYSMAP=y
> CONFIG_MTD_PHYSMAP_START=0xFC000000
> CONFIG_MTD_PHYSMAP_LEN=0x4000000CONFIG_MTD_PHYSMAP_BANKWIDTH=4
> # CONFIG_MTD_MULTI_PHYSMAP is not set
> # CONFIG_MTD_SBC8240 is not set
> CONFIG_MTD_PQ2FADS=y
> # CONFIG_MTD_PLATRAM is not set
Are you using a non-standard flash SIMM? The one that comes with the
board (that I've seen, at least) have interleave 4, and are mapped at
0xfe000000.
Was it the physmap driver or the pq2fads driver that found the flash?
Which kernel are you using, and are you using arch/ppc or arch/powerpc?
-Scott
^ permalink raw reply
* Re: PaSemi DMA API for Linux
From: Olof Johansson @ 2007-09-25 15:22 UTC (permalink / raw)
To: Samuel Zahnd; +Cc: linuxppc-embedded
In-Reply-To: <005401c7ff6f$d24ea290$4c0112ac@scsad.scs.ch>
On Tue, Sep 25, 2007 at 02:30:13PM +0200, Samuel Zahnd wrote:
> Hi embedded people,
>
> we have a PaSemi (PA6T-1682) CPU is use with Linux and CFE. I wonder if
> anybody has experience with the DMA engine of the device. Some examples or
> an API would be particularly usefull.
The network driver uses the DMA engine, besides that there's not much
example code out there.
The DMA has alot of features, just what are you looking to do? Just DMA
copy offload, or other functions?
-Olof
^ permalink raw reply
* Re: [spi-devel-general] [PATCH 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on MPC85xx
From: Anton Vorontsov @ 2007-09-25 15:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <16E78F0E-B57B-4084-887E-5D2F9C1D0331@kernel.crashing.org>
On Tue, Sep 25, 2007 at 10:04:41AM -0500, Kumar Gala wrote:
>
> On Sep 25, 2007, at 9:35 AM, Anton Vorontsov wrote:
>
>> MPC85xx's QE SPI controller is almost the same comparing to MPC83xx.
>> Thus lets use that driver. Tested to work in loopback mode.
>>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>> ---
>> drivers/spi/Kconfig | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>> index b915711..14f0d0d 100644
>> --- a/drivers/spi/Kconfig
>> +++ b/drivers/spi/Kconfig
>> @@ -125,7 +125,7 @@ config SPI_MPC52xx_PSC
>>
>> config SPI_MPC83xx
>> tristate "Freescale MPC83xx SPI controller"
>> - depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
>> + depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
>> select SPI_BITBANG
>> help
>> This enables using the Freescale MPC83xx SPI controller in master
>
> Should that really be just PPC_83xx || QUICC_ENGINE?
Well, I thought about that. By now I'm unsure if every QE
implementation will be compatible with further ones. So far
I've tested this driver on MPC8323 and MPC8568. If we'll see
more and more compatible QE SPI controllers, of course we
may just do || QUICC_ENGINE.
PPC_83xx || PPC_85xx
PPC_83xx || QUICC_ENGINE
Today first option saves us four bytes. ;-)
^ permalink raw reply
* Re: [PATCH4/4] [POWERPC] Fix cpm_uart driver
From: Scott Wood @ 2007-09-25 15:11 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <46F8FA5F.3050907@scram.de>
On Tue, Sep 25, 2007 at 02:09:03PM +0200, Jochen Friedrich wrote:
> In cpm_uart_core.c, the operation "pinfo->rx_bd_base - DPRAM_BASE" is
> used to calculate the DPRAM offset. So DPRAM_BASE must be relative to
> dpram_vbase in commproc.c as well. However, cpm_uart_cpm1.h uses cpmp in
> commproc.c to initialize DPRAM_BASE.
>
> On ARCH=ppc, cpmp is a physical address with 1:1 virtual mapping ("well
> known address"). On ARC=powerpc, this is an address obtained by
> ioremap(), however it's a different ioremap() call than dpram_vbase is
> obtained from, so noone can guarantee
> cpmp is always the same as dpram_vbase even on ARCH=powerpc.
I have patches submitted in which they're from the same ioremap, but
I agree that using cpm_dpram_addr(0) is a more robust way.
-Scott
^ permalink raw reply
* Re: [spi-devel-general] [PATCH 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on MPC85xx
From: Kumar Gala @ 2007-09-25 15:04 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <20070925143531.GG5323@localhost.localdomain>
On Sep 25, 2007, at 9:35 AM, Anton Vorontsov wrote:
> MPC85xx's QE SPI controller is almost the same comparing to MPC83xx.
> Thus lets use that driver. Tested to work in loopback mode.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/spi/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index b915711..14f0d0d 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -125,7 +125,7 @@ config SPI_MPC52xx_PSC
>
> config SPI_MPC83xx
> tristate "Freescale MPC83xx SPI controller"
> - depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
> + depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
> select SPI_BITBANG
> help
> This enables using the Freescale MPC83xx SPI controller in master
Should that really be just PPC_83xx || QUICC_ENGINE?
- k
^ permalink raw reply
* [PATCH v2 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on MPC85xx
From: Anton Vorontsov @ 2007-09-25 15:02 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <874phiol7j.fsf@macbook.be.48ers.dk>
On Tue, Sep 25, 2007 at 04:48:00PM +0200, Peter Korsgaard wrote:
> >>>>> "Anton" == Anton Vorontsov <avorontsov@ru.mvista.com> writes:
>
> Hi,
>
> Anton> config SPI_MPC83xx
> Anton> tristate "Freescale MPC83xx SPI controller"
> Anton> - depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
> Anton> + depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
> Anton> select SPI_BITBANG
> Anton> help
> Anton> This enables using the Freescale MPC83xx SPI controller in master
>
> Please also update the help text.
Oops. Thanks, fixed.
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Subject: [PATCH v2] [POWERPC][SPI] spi_mpc83xx: allow use on MPC85xx
MPC85xx's QE SPI controller is almost the same comparing to MPC83xx.
Thus lets use that driver. Tested to work in loopback mode.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/spi/Kconfig | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index b915711..7a7a42c 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -124,16 +124,17 @@ config SPI_MPC52xx_PSC
Controller in master SPI mode.
config SPI_MPC83xx
- tristate "Freescale MPC83xx SPI controller"
- depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
+ tristate "Freescale MPC83xx/MPC85xx SPI controller"
+ depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
select SPI_BITBANG
help
- This enables using the Freescale MPC83xx SPI controller in master
- mode.
+ This enables using the Freescale MPC83xx/MPC85xx SPI controller in
+ master mode.
Note, this driver uniquely supports the SPI controller on the MPC83xx
- family of PowerPC processors. The MPC83xx uses a simple set of shift
- registers for data (opposed to the CPM based descriptor model).
+ and MPC85xx family of PowerPC processors. The MPC83xx/MPC85xx uses a
+ simple set of shift registers for data (opposed to the CPM based
+ descriptor model).
config SPI_OMAP_UWIRE
tristate "OMAP1 MicroWire"
--
1.5.0.6
^ permalink raw reply related
* Re: [PATCH 4/5] ibmebus: Move to of_device and of_platform_driver, match eHCA and eHEA drivers
From: Arnd Bergmann @ 2007-09-25 14:42 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, Jan-Bernd Themann, Paul Mackerras, Joachim Fenkes,
LKML, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <200709251412.59904.fenkes@de.ibm.com>
On Tuesday 25 September 2007, Joachim Fenkes wrote:
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
This is missing a description, but the patch looks good.
Arnd <><
^ permalink raw reply
* Re: [PATCH 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on MPC85xx
From: Peter Korsgaard @ 2007-09-25 14:48 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <20070925143531.GG5323@localhost.localdomain>
>>>>> "Anton" == Anton Vorontsov <avorontsov@ru.mvista.com> writes:
Hi,
Anton> config SPI_MPC83xx
Anton> tristate "Freescale MPC83xx SPI controller"
Anton> - depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
Anton> + depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
Anton> select SPI_BITBANG
Anton> help
Anton> This enables using the Freescale MPC83xx SPI controller in master
Please also update the help text.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 3/5] ibmebus: Add device creation and bus probing based on of_device
From: Arnd Bergmann @ 2007-09-25 14:39 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, Jan-Bernd Themann, Paul Mackerras, Joachim Fenkes,
LKML, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <200709251412.27896.fenkes@de.ibm.com>
On Tuesday 25 September 2007, Joachim Fenkes wrote:
> The devtree root is now searched for devices matching a built-in whitelist
> during boot, so these devices appear on the bus from the beginning. It is
> still possible to manually add/remove devices to/from the bus by using the
> probe/remove sysfs interface. Also, when a device driver registers itself,
> the devtree is matched against its matchlist.
>
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
> ---
> arch/powerpc/kernel/ibmebus.c | 97 ++++++++++++++++++++++++++++++++++-------
> 1 files changed, 81 insertions(+), 16 deletions(-)
>
> diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
> index cc80f84..c506e0d 100644
> --- a/arch/powerpc/kernel/ibmebus.c
> +++ b/arch/powerpc/kernel/ibmebus.c
> @@ -51,6 +51,15 @@ static struct device ibmebus_bus_device = { /* fake "parent" device */
>
> struct bus_type ibmebus_bus_type;
>
> +/* These devices will automatically be added to the bus during init */
> +static struct of_device_id builtin_matches[] = {
> + { .name = "lhca" },
> + { .compatible = "IBM,lhca" },
> + { .name = "lhea" },
> + { .compatible = "IBM,lhea" },
> + {},
> +};
> +
Hmm, do you have devices that only have the matching name property
but not the compatible property? If not, I'd suggest only looking
for compatible, so you have less chance of false positives.
> +static int ibmebus_create_device(struct device_node *dn)
> +{
> + struct of_device *dev;
> + int ret;
> +
> + dev = of_device_alloc(dn, NULL, &ibmebus_bus_device);
> + if (!dev)
> + return -ENOMEM;
> +
> + dev->dev.bus = &ibmebus_bus_type;
> + dev->dev.archdata.dma_ops = &ibmebus_dma_ops;
> +
> + ret = of_device_register(dev);
> + if (ret) {
> + of_device_free(dev);
> + return ret;
> + }
> +
> + return 0;
> +}
nice!
> @@ -219,9 +276,9 @@ static ssize_t ibmebus_store_probe(struct bus_type *bus,
> }
>
> if ((dn = of_find_node_by_path(path))) {
> -/* dev = ibmebus_register_device_node(dn); */
> + rc = ibmebus_create_device(dn);
> of_node_put(dn);
> - rc = IS_ERR(dev) ? PTR_ERR(dev) : count;
> + rc = rc ? rc : count;
the last line looks a bit silly. Maybe instead do
rc = ibmebus_create_device(dn);
of_node_put(dn);
}
kfree(path);
if (rc)
return rc;
return count;
}
^ permalink raw reply
* Re: [PATCH 2/5] ibmebus: Remove bus match/probe/remove functions
From: Arnd Bergmann @ 2007-09-25 14:29 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, Jan-Bernd Themann, Paul Mackerras, Joachim Fenkes,
LKML, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <200709251411.54465.fenkes@de.ibm.com>
On Tuesday 25 September 2007, Joachim Fenkes wrote:
> ibmebus_{,un}register_driver() are replaced by dummy functions because
> ibmebus is temporarily unusable in this transitional state.
>=20
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
> ---
> =A0arch/powerpc/kernel/ibmebus.c | =A0199 ++-----------------------------=
=2D---------
> =A01 files changed, 6 insertions(+), 193 deletions(-)
>=20
Great diffstat!
The description makes it sound like a git-bisect would get broken
by this patch, which should never happen. If the patch indeed
ends up with a broken kernel, it would be better to merge it with
the later patch that fixes the code again.
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/5] PowerPC: Move of_device allocation into of_device.[ch]
From: Arnd Bergmann @ 2007-09-25 14:27 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, Jan-Bernd Themann, Paul Mackerras, Joachim Fenkes,
LKML, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <200709251411.27755.fenkes@de.ibm.com>
On Tuesday 25 September 2007, Joachim Fenkes wrote:
> Extract generic of_device allocation code from of_platform_device_create()
> and move it into of_device.[ch], called of_device_alloc(). Also, there's =
now
> of_device_free() which puts the device node.
>=20
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
> ---
> =A0include/asm-powerpc/of_device.h =A0 | =A0 =A04 ++
> =A0include/linux/of_device.h =A0 =A0 =A0 =A0 | =A0 =A05 ++
> =A0arch/powerpc/kernel/of_device.c =A0 | =A0 80 +++++++++++++++++++++++++=
++++++++++++
> =A0arch/powerpc/kernel/of_platform.c | =A0 70 +--------------------------=
=2D----
> =A04 files changed, 91 insertions(+), 68 deletions(-)
>=20
Sorry I didn't review the patches earlier when you sent them in private.
The patch looks good to me, especially since you did exactly what I
suggested ;-)
Maybe the description should have another sentence in it about what
the change is good for. You have that in the 0/5 mail, but that does
not go into the changelog, so the information gets lost in the process.
Arnd <><
^ permalink raw reply
* [PATCH 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on MPC85xx
From: Anton Vorontsov @ 2007-09-25 14:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: spi-devel-general
In-Reply-To: <20070925143126.GA30013@localhost.localdomain>
MPC85xx's QE SPI controller is almost the same comparing to MPC83xx.
Thus lets use that driver. Tested to work in loopback mode.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/spi/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index b915711..14f0d0d 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -125,7 +125,7 @@ config SPI_MPC52xx_PSC
config SPI_MPC83xx
tristate "Freescale MPC83xx SPI controller"
- depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
+ depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
select SPI_BITBANG
help
This enables using the Freescale MPC83xx SPI controller in master
--
1.5.0.6
^ permalink raw reply related
* [PATCH 6/7] [POWERPC] mpc85xx_mds: reset UCC ethernet properly
From: Anton Vorontsov @ 2007-09-25 14:35 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070925143126.GA30013@localhost.localdomain>
Apart from that the current code doesn't compile it's also
meaningless with regard to the MPC8568E-MDS' BCSR.
This patch used to reset UCCs properly.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 28 ++++++++++++++++------------
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index c379286..5de409b 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -107,18 +107,22 @@ static void __init mpc85xx_mds_setup_arch(void)
}
if (bcsr_regs) {
- u8 bcsr_phy;
-
- /* Reset the Ethernet PHY */
- bcsr_phy = in_be8(&bcsr_regs[9]);
- bcsr_phy &= ~0x20;
- out_be8(&bcsr_regs[9], bcsr_phy);
-
- udelay(1000);
-
- bcsr_phy = in_be8(&bcsr_regs[9]);
- bcsr_phy |= 0x20;
- out_be8(&bcsr_regs[9], bcsr_phy);
+#define BCSR_UCC1_GETH_EN (0x1 << 7)
+#define BCSR_UCC2_GETH_EN (0x1 << 7)
+#define BCSR_UCC1_MODE_MSK (0x3 << 4)
+#define BCSR_UCC2_MODE_MSK (0x3 << 0)
+
+ /* Turn off UCC1 & UCC2 */
+ clrbits8(&bcsr_regs[8], BCSR_UCC1_GETH_EN);
+ clrbits8(&bcsr_regs[9], BCSR_UCC2_GETH_EN);
+
+ /* Mode is RGMII, all bits clear */
+ clrbits8(&bcsr_regs[11], BCSR_UCC1_MODE_MSK |
+ BCSR_UCC2_MODE_MSK);
+
+ /* Turn UCC1 & UCC2 on */
+ setbits8(&bcsr_regs[8], BCSR_UCC1_GETH_EN);
+ setbits8(&bcsr_regs[9], BCSR_UCC2_GETH_EN);
iounmap(bcsr_regs);
}
--
1.5.0.6
^ permalink raw reply related
* [PATCH 5/7] [POWERPC] mpc8568mds: update dts to be able to use UCCs
From: Anton Vorontsov @ 2007-09-25 14:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070925143126.GA30013@localhost.localdomain>
1. UCC1's RX_DV pin is 16, not 15;
2. UCC1's phy is at 0x7, not 0x1. Schematics says 0x7, and recent
u-boot also using 0x7.
3. Use gianfar's (eTSEC) mdio bus. This is hardware default setup.
4. tx-clock should be CLK16 (GE125, PB31);
5. phy-connection-type is RGMII-ID;
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8568mds.dts | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index c472a4b..1d082fb 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -95,10 +95,10 @@
device_type = "mdio";
compatible = "gianfar";
reg = <24520 20>;
- phy0: ethernet-phy@0 {
+ phy0: ethernet-phy@7 {
interrupt-parent = <&mpic>;
interrupts = <1 1>;
- reg = <0>;
+ reg = <7>;
device_type = "ethernet-phy";
};
phy1: ethernet-phy@1 {
@@ -286,7 +286,7 @@
4 1a 2 0 2 0 /* RxD7 */
4 0b 1 0 2 0 /* TX_EN */
4 18 1 0 2 0 /* TX_ER */
- 4 0f 2 0 2 0 /* RX_DV */
+ 4 10 2 0 2 0 /* RX_DV */
4 1e 2 0 2 0 /* RX_ER */
4 11 2 0 2 0 /* RX_CLK */
4 13 1 0 2 0 /* GTX_CLK */
@@ -377,10 +377,10 @@
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = <0>;
- tx-clock = <19>;
- phy-handle = <&qe_phy0>;
- phy-connection-type = "gmii";
+ tx-clock = <20>;
pio-handle = <&pio1>;
+ phy-handle = <&phy0>;
+ phy-connection-type = "rgmii-id";
};
ucc@3000 {
@@ -399,10 +399,10 @@
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = <0>;
- tx-clock = <14>;
- phy-handle = <&qe_phy1>;
- phy-connection-type = "gmii";
+ tx-clock = <20>;
pio-handle = <&pio2>;
+ phy-handle = <&phy1>;
+ phy-connection-type = "rgmii-id";
};
mdio@2120 {
@@ -414,10 +414,10 @@
/* These are the same PHYs as on
* gianfar's MDIO bus */
- qe_phy0: ethernet-phy@00 {
+ qe_phy0: ethernet-phy@07 {
interrupt-parent = <&mpic>;
interrupts = <1 1>;
- reg = <0>;
+ reg = <7>;
device_type = "ethernet-phy";
};
qe_phy1: ethernet-phy@01 {
--
1.5.0.6
^ permalink raw reply related
* [PATCH 4/7] [POWERPC] QE pario: support for MPC85xx layout
From: Anton Vorontsov @ 2007-09-25 14:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070925143126.GA30013@localhost.localdomain>
8 bytes padding required to match MPC85xx registers layout.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/qe_lib/qe_io.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe_io.c b/arch/powerpc/sysdev/qe_lib/qe_io.c
index e32b45b..d566e89 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_io.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_io.c
@@ -36,6 +36,9 @@ struct port_regs {
__be32 cpdir2; /* Direction register */
__be32 cppar1; /* Pin assignment register */
__be32 cppar2; /* Pin assignment register */
+#ifdef CONFIG_MPC85xx
+ u8 pad[8];
+#endif
};
static struct port_regs *par_io = NULL;
--
1.5.0.6
^ permalink raw reply related
* [PATCH 3/7] [POWERPC] QEIC: implement low+high multiplexed IRQ chained handler
From: Anton Vorontsov @ 2007-09-25 14:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070925143126.GA30013@localhost.localdomain>
For MPC8568E low and high QEIC lines routed to the single MPIC
input, thus low and high sources should be demultiplexed.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/qe_lib/qe_ic.c | 34 ++++++++++++++++++++++++++++------
1 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.c b/arch/powerpc/sysdev/qe_lib/qe_ic.c
index 8e743e0..0ecb614 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_ic.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_ic.c
@@ -345,6 +345,22 @@ void qe_ic_cascade_high(unsigned int irq, struct irq_desc *desc)
desc->chip->end(irq);
}
+static void qe_ic_cascade_muxed(unsigned int irq, struct irq_desc *desc)
+{
+ struct qe_ic *qe_ic = desc->handler_data;
+ unsigned int cascade_irq;
+
+ cascade_irq = qe_ic_get_high_irq(qe_ic);
+ if (cascade_irq == NO_IRQ)
+ cascade_irq = qe_ic_get_low_irq(qe_ic);
+
+ if (cascade_irq != NO_IRQ)
+ generic_handle_irq(cascade_irq);
+
+ if (desc->chip->end)
+ desc->chip->end(irq);
+}
+
void __init qe_ic_init(struct device_node *node, unsigned int flags)
{
struct qe_ic *qe_ic;
@@ -404,12 +420,18 @@ void __init qe_ic_init(struct device_node *node, unsigned int flags)
qe_ic_write(qe_ic->regs, QEIC_CICR, temp);
- set_irq_data(qe_ic->virq_low, qe_ic);
- set_irq_chained_handler(qe_ic->virq_low, qe_ic_cascade_low);
-
- if (qe_ic->virq_high != NO_IRQ) {
- set_irq_data(qe_ic->virq_high, qe_ic);
- set_irq_chained_handler(qe_ic->virq_high, qe_ic_cascade_high);
+ if (qe_ic->virq_high == qe_ic->virq_low) {
+ set_irq_data(qe_ic->virq_low, qe_ic);
+ set_irq_chained_handler(qe_ic->virq_low, qe_ic_cascade_muxed);
+ } else {
+ set_irq_data(qe_ic->virq_low, qe_ic);
+ set_irq_chained_handler(qe_ic->virq_low, qe_ic_cascade_low);
+
+ if (qe_ic->virq_high != NO_IRQ) {
+ set_irq_data(qe_ic->virq_high, qe_ic);
+ set_irq_chained_handler(qe_ic->virq_high,
+ qe_ic_cascade_high);
+ }
}
printk("QEIC (%d IRQ sources) at %p\n", NR_QE_IC_INTS, qe_ic->regs);
--
1.5.0.6
^ permalink raw reply related
* [PATCH 2/7] [POWERPC] Fix QEIC->MPIC cascading
From: Anton Vorontsov @ 2007-09-25 14:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070925143126.GA30013@localhost.localdomain>
set_irq_chained_handler overwrites MPIC's handle_irq function
(handle_fasteoi_irq) thus MPIC never gets eoi event from the
cascaded IRQ. This situation hangs MPIC on MPC8568E.
Patch adds flow level "end" handler to the MPIC, and QEIC calls
it when QEIC's interrupt processing finished.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/mpic.c | 3 +++
arch/powerpc/sysdev/qe_lib/qe_ic.c | 6 ++++++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 8de29f2..bee2d5b 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -846,6 +846,7 @@ static struct irq_chip mpic_irq_chip = {
.mask = mpic_mask_irq,
.unmask = mpic_unmask_irq,
.eoi = mpic_end_irq,
+ .end = mpic_end_irq,
.set_type = mpic_set_irq_type,
};
@@ -854,6 +855,7 @@ static struct irq_chip mpic_ipi_chip = {
.mask = mpic_mask_ipi,
.unmask = mpic_unmask_ipi,
.eoi = mpic_end_ipi,
+ .end = mpic_end_ipi,
};
#endif /* CONFIG_SMP */
@@ -864,6 +866,7 @@ static struct irq_chip mpic_irq_ht_chip = {
.mask = mpic_mask_irq,
.unmask = mpic_unmask_ht_irq,
.eoi = mpic_end_ht_irq,
+ .end = mpic_end_ht_irq,
.set_type = mpic_set_irq_type,
};
#endif /* CONFIG_MPIC_U3_HT_IRQS */
diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.c b/arch/powerpc/sysdev/qe_lib/qe_ic.c
index 55e6f39..8e743e0 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_ic.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_ic.c
@@ -328,6 +328,9 @@ void qe_ic_cascade_low(unsigned int irq, struct irq_desc *desc)
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
+
+ if (desc->chip->end)
+ desc->chip->end(irq);
}
void qe_ic_cascade_high(unsigned int irq, struct irq_desc *desc)
@@ -337,6 +340,9 @@ void qe_ic_cascade_high(unsigned int irq, struct irq_desc *desc)
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
+
+ if (desc->chip->end)
+ desc->chip->end(irq);
}
void __init qe_ic_init(struct device_node *node, unsigned int flags)
--
1.5.0.6
^ permalink raw reply related
* [PATCH 1/7] [POWERPC] mpc85xx_mds: select QUICC_ENGINE
From: Anton Vorontsov @ 2007-09-25 14:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070925143126.GA30013@localhost.localdomain>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/85xx/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index b8476b2..cf815b2 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -25,7 +25,7 @@ config MPC85xx_CDS
config MPC85xx_MDS
bool "Freescale MPC85xx MDS"
select DEFAULT_UIMAGE
-# select QUICC_ENGINE
+ select QUICC_ENGINE
help
This option enables support for the MPC85xx MDS board
--
1.5.0.6
^ permalink raw reply related
* MPC85xx_MDS: Patches to support QE, UCCs and SPI
From: Anton Vorontsov @ 2007-09-25 14:31 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
These patches needed to make QE, UCCs and SPI work on MPC8568E-MDS.
Patchset is against galak/powerpc.git master branch.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ 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