* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Li Yang @ 2009-04-27 7:48 UTC (permalink / raw)
To: Ira Snyder; +Cc: linuxppc-dev, Dan Williams, linux-kernel
In-Reply-To: <20090424183517.GB23140@ovro.caltech.edu>
On Sat, Apr 25, 2009 at 2:35 AM, Ira Snyder <iws@ovro.caltech.edu> wrote:
> By default, the Freescale 83xx DMA controller uses the PCI Read Line
> command when reading data over the PCI bus. Setting the controller to use
> the PCI Read Multiple command instead allows the controller to read much
> larger bursts of data, which provides a drastic speed increase.
>
> The slowdown due to using PCI Read Line was only observed when a PCI-to-PCI
> bridge was between the devices trying to communicate.
>
> A simple test driver showed an increase from 4MB/sec to 116MB/sec when
> performing DMA over the PCI bus. Using DMA to transfer between blocks of
> local SDRAM showed no change in performance with this patch. The dmatest
> driver was also used to verify the correctness of the transfers, and showed
> no errors.
>
> Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Acked-by: Li Yang <leoli@freescale.com>
Thanks,
Leo
^ permalink raw reply
* Re: [BUG] 2.6.30-rc3: BUG triggered on some hugepage usages
From: Benjamin Herrenschmidt @ 2009-04-27 8:15 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <20090424095116.GB14283@csn.ul.ie>
On Fri, 2009-04-24 at 10:51 +0100, Mel Gorman wrote:
> I'm seeing some tests with sysbench+postgres+large pages fail on ppc64
> although a very clear pattern is not forming as to what exactly is
> causing it. However, the libhugetlbfs regression tests (make && make
> func) are triggering the following oops when calling mlock() and so
> are
> likely related.
This would be a spurrious WARN_ON().. the test I added in there should
not apply to huge pages. However, I don't see that causing a functional
problem with sysbench+postgres
Ben.
^ permalink raw reply
* RE: [PATCH] fsldma: use PCI Read Multiple command
From: Liu Dave-R63238 @ 2009-04-27 9:09 UTC (permalink / raw)
To: Ira Snyder, linux-kernel; +Cc: linuxppc-dev, Dan Williams, Zhang Wei
In-Reply-To: <20090424183517.GB23140@ovro.caltech.edu>
> By default, the Freescale 83xx DMA controller uses the PCI Read Line
> command when reading data over the PCI bus. Setting the=20
> controller to use the PCI Read Multiple command instead allows the
> controller to read much larger bursts of data, which provides a
drastic
> speed increase.
IIRC, the default for 83xx DMA controller uses the PCI mem read
command, not mem read line.
You are assuming the PCI memory space is prefetchable( no side effect)
for DMA.
Is it possible that DMA is from non-prefetchable memory space?
> The slowdown due to using PCI Read Line was only observed=20
> when a PCI-to-PCI bridge was between the devices trying to
communicate.
>=20
> A simple test driver showed an increase from 4MB/sec to 116MB/sec when
> performing DMA over the PCI bus. Using DMA to transfer between blocks
> of local SDRAM showed no change in performance with this patch.=20
> The dmatest driver was also used to verify the correctness of the
transfers,
> and showed no errors.
^ permalink raw reply
* Re: [PATCH 00/13] OF device tree handling of PHY drivers
From: David Miller @ 2009-04-27 9:54 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-dev, afleming, netdev
In-Reply-To: <20090425224458.32392.31296.stgit@localhost.localdomain>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Sat, 25 Apr 2009 16:52:34 -0600
> This series adds common code for reading PHY connection data out of
> the OpenFirmware device tree. This simplifies the network drivers
> which use the device tree and which currently implement their own
> solutions for reading the PHY data out of the device tree directly.
>
> I would like to see this series, or at least the core changes (1-4)
> plus the tested drivers (5-8 & 12, but #12 is a new driver and it
> may need more review), go into -next for 2.6.31.
>
> Due to dependencies, I think it is easiest if all of them go in via the
> same tree. David, are you willing to merge them via yours? Four of the
> patches are outside of drivers/net (patches 1 and 4 touch drivers/of/,
> and patches 9 & 10 touch arch/powerpc), but I personally have no issues
> if those changes go through you. I just need to double check with BenH.
I've applied all of these patches to net-next-2.6, thanks.
> git://git.secretlab.ca/git/linux-2.6 next-net
You know, if you had actually based this tree on net-next-2.6
I could have pulled from it. I actually tried, and I got a
lot of upstream stuff I wasn't ready to get in that tree just
yet :-/
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Li Yang @ 2009-04-27 10:16 UTC (permalink / raw)
To: Liu Dave-R63238; +Cc: linuxppc-dev, Dan Williams, linux-kernel, Ira Snyder
In-Reply-To: <D7CCA83BB0796C49BC0BB53B6AB1208928CA1D@zch01exm21.fsl.freescale.net>
On Mon, Apr 27, 2009 at 5:09 PM, Liu Dave-R63238 <DaveLiu@freescale.com> wrote:
>> By default, the Freescale 83xx DMA controller uses the PCI Read Line
>> command when reading data over the PCI bus. Setting the
>> controller to use the PCI Read Multiple command instead allows the
>> controller to read much larger bursts of data, which provides a
> drastic
>> speed increase.
>
> IIRC, the default for 83xx DMA controller uses the PCI mem read
> command, not mem read line.
>
> You are assuming the PCI memory space is prefetchable( no side effect)
> for DMA.
> Is it possible that DMA is from non-prefetchable memory space?
I guess it's not reasonable to use DMA from non-prefetchable memory.
So it's up to the driver which uses the DMA engine to prevent from
using DMA API on non-prefetchable memory.
- Leo
^ permalink raw reply
* [PATCH] powerpc: convert mace to netdev_ops (was: Re: [2.6.30-rc3] powerpc: compilation error of mace module)
From: Rogério Brito @ 2009-04-27 12:16 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, paulus, linux-kernel, netdev
In-Reply-To: <20090426.230648.254087966.davem@davemloft.net>
Hi, Dave.
On Apr 26 2009, David Miller wrote:
> Or, if you're bored, feel free to convert the mace driver over
> to netdev_ops :-)
Is this anything close to what needs to be done? It's not without
failures, because the function mace_set_timeout receives a pointer to a
struct net_device, but is marked inline and is used by mace_tx_timeout,
which receives an unsigned long (which calls mace_set_timeout).
Perhaps it would be a case of removing the inline hint to the compiler?
I guess that BenH or Paul could comment here better...
Signed-off-by: Rogério Brito <rbrito@ime.usp.br>
---
--- a/drivers/net/mace.c 2008-12-29 15:25:15.000000000 -0200
+++ b/drivers/net/mace.c 2009-04-27 08:54:16.000000000 -0300
@@ -89,6 +89,16 @@ static inline void dbdma_reset(volatile
static inline void mace_clean_rings(struct mace_data *mp);
static void __mace_set_address(struct net_device *dev, void *addr);
+/* Conversion to netdev_ops. */
+static const struct net_device_ops mace_netdev_ops = {
+ .ndo_open = mace_open,
+ .ndo_stop = mace_close,
+ .ndo_start_xmit = mace_xmit_start,
+ .ndo_tx_timeout = mace_set_timeout,
+ .ndo_set_multicast_list = mace_set_multicast,
+ .ndo_set_mac_address = mace_set_address,
+};
+
/*
* If we can't get a skbuff when we need it, we use this area for DMA.
*/
@@ -208,11 +217,7 @@ static int __devinit mace_probe(struct m
}
}
- dev->open = mace_open;
- dev->stop = mace_close;
- dev->hard_start_xmit = mace_xmit_start;
- dev->set_multicast_list = mace_set_multicast;
- dev->set_mac_address = mace_set_address;
+ dev->netdev_ops = &mace_netdev_ops;
/*
* Most of what is below could be moved to mace_open()
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
^ permalink raw reply
* Re: [PATCH] powerpc: convert mace to netdev_ops
From: David Miller @ 2009-04-27 12:42 UTC (permalink / raw)
To: rbrito; +Cc: linuxppc-dev, paulus, linux-kernel, netdev
In-Reply-To: <20090427121633.GA29608@ime.usp.br>
From: Rog=E9rio Brito <rbrito@ime.usp.br>
Date: Mon, 27 Apr 2009 09:16:33 -0300
> Is this anything close to what needs to be done? It's not without
> failures, because the function mace_set_timeout receives a pointer to=
a
> struct net_device, but is marked inline and is used by mace_tx_timeou=
t,
> which receives an unsigned long (which calls mace_set_timeout).
> =
> Perhaps it would be a case of removing the inline hint to the compile=
r?
> I guess that BenH or Paul could comment here better...
> =
> Signed-off-by: Rog=E9rio Brito <rbrito@ime.usp.br>
You can fix the mace_set_timeout() function arguments by having
a helper function that simply wraps around it and provides the
second expection of argument types.
Your patch is also wrong, it's missing a lot of netdev_ops
entries that are implicitly obtained via alloc_etherdev(),
namely:
.ndo_change_mtu =3D eth_change_mtu,
.ndo_set_mac_address =3D eth_mac_addr,
.ndo_validate_addr =3D eth_validate_addr,
^ permalink raw reply
* Re: [PATCH] [V5] Xilinx : Framebuffer Driver: Add PLB support and cleanup DCR
From: Benjamin Herrenschmidt @ 2009-04-27 12:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-fbdev-devel, adaplas, Suneel, linuxppc-dev, akonovalov,
John Linn
In-Reply-To: <200904241301.59775.arnd@arndb.de>
On Fri, 2009-04-24 at 13:01 +0200, Arnd Bergmann wrote:
> I just said in another email thread that we would need a CONFIG_DCR
> option that DCR using drivers should depend on, if it ever happened
> outside of powerpc.
>
> Well, apparently this happened earlier than I expected.
Sadly...
Cheers,
Ben.
^ permalink raw reply
* Machine check in 4xx NAND driver
From: Felix Radensky @ 2009-04-27 12:28 UTC (permalink / raw)
To: linuxppc-dev, Sean MacLennan, linux-mtd
Hi,
I've got the following error on custom board based on AMCC 405EXr
running 2.6.27 kernel, with ndfc driver back ported from 2.6.29 (to support
OF partitions on NAND). This happened once, right after reboot. I was
unable to reproduce this. The NAND device is Samsung K9K8G08U0B,
1GB with 2k page.
Oops: Machine check, sig: 7 [#1]
Modules linked in:
NIP: c0155bd0 LR: c014ff30 CTR: 0000003b
REGS: dfffdf50 TRAP: 0202 Not tainted (2.6.27)
MSR: 00029030 <EE,ME,IR,DR> CR: 44024084 XER: 00000000
TASK = df82c000[1] 'swapper' THREAD: df82a000
GPR00: 82bfe51c df82bb90 df82c000 c02c7ae0 dfade884 000000fc 000001fe 0000006b
GPR08: 00000000 e1018000 c02c7ad8 00000040 00000000 ffffffef c024c3b0 00000000
GPR16: 00000000 00000000 00000000 0000003f 00000000 dfade870 c02aa7f4 00000003
GPR24: df824040 df824000 00000100 00000008 c02c7ae0 df824000 c02c7b9c dfade870
NIP [c0155bd0] ndfc_read_buf+0x30/0x5c
LR [c014ff30] nand_read_page_hwecc+0x70/0x174
Call Trace:
[df82bb90] [c014fff8] nand_read_page_hwecc+0x138/0x174 (unreliable)
[df82bbd0] [c0152e74] nand_do_read_ops+0x15c/0x3dc
[df82bc30] [c01534bc] nand_read+0xa8/0xe4
[df82bc60] [c014800c] part_read+0x5c/0xe4
[df82bc70] [c00f2154] jffs2_flash_read+0x68/0x258
[df82bca0] [c00ebbc0] jffs2_fill_scan_buf+0x34/0x64
[df82bcc0] [c00ec0a0] jffs2_scan_medium+0x4b0/0x1204
[df82bd40] [c00eed00] jffs2_do_mount_fs+0x178/0x6c8
[df82bd80] [c00f11f8] jffs2_do_fill_super+0xc4/0x258
[df82bda0] [c00f18a0] jffs2_fill_super+0xc0/0xd4
[df82bdc0] [c0147128] get_sb_mtd_aux+0xa0/0xf0
[df82bdf0] [c0147280] get_sb_mtd+0x84/0x1c8
[df82be30] [c00f1670] jffs2_get_sb+0x1c/0x2c
[df82be40] [c0072230] vfs_kern_mount+0x58/0xe0
[df82be60] [c0072308] do_kern_mount+0x40/0xf8
[df82be80] [c008b740] do_new_mount+0x88/0xb8
[df82bea0] [c008b8f4] do_mount+0x184/0x1d4
[df82bf20] [c008b9d4] sys_mount+0x90/0xe0
[df82bf50] [c0274a04] do_mount_root+0x30/0xb8
[df82bf60] [c0274c78] mount_block_root+0xac/0x244
[df82bfb0] [c02750ac] prepare_namespace+0x18c/0x218
[df82bfd0] [c02741bc] kernel_init+0xc8/0xf4
[df82bff0] [c000dd5c] kernel_thread+0x44/0x60
Instruction dump:
7cab2b79 4c810020 38a5fffc 396bffff 2f85fffd 556bf0be 3d20c02c 396b0001
39497ad8 7d6903a6 419c0028 812a0004 <7c0004ac> 80090008 0c000000 4c00012c
Any hints what could be the problem are much appreciated.
Thanks.
Felix.
^ permalink raw reply
* Re: [PATCH 00/13] OF device tree handling of PHY drivers
From: Grant Likely @ 2009-04-27 13:07 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, afleming, netdev
In-Reply-To: <20090427.025436.68188155.davem@davemloft.net>
On Mon, Apr 27, 2009 at 3:54 AM, David Miller <davem@davemloft.net> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
> Date: Sat, 25 Apr 2009 16:52:34 -0600
>
>> This series adds common code for reading PHY connection data out of
>> the OpenFirmware device tree. =A0This simplifies the network drivers
>> which use the device tree and which currently implement their own
>> solutions for reading the PHY data out of the device tree directly.
>>
>> I would like to see this series, or at least the core changes (1-4)
>> plus the tested drivers (5-8 & 12, but #12 is a new driver and it
>> may need more review), go into -next for 2.6.31.
>>
>> Due to dependencies, I think it is easiest if all of them go in via the
>> same tree. =A0David, are you willing to merge them via yours? =A0Four of=
the
>> patches are outside of drivers/net (patches 1 and 4 touch drivers/of/,
>> and patches 9 & 10 touch arch/powerpc), but I personally have no issues
>> if those changes go through you. =A0I just need to double check with Ben=
H.
>
> I've applied all of these patches to net-next-2.6, thanks.
>
>> =A0 git://git.secretlab.ca/git/linux-2.6 next-net
>
> You know, if you had actually based this tree on net-next-2.6
> I could have pulled from it. =A0I actually tried, and I got a
> lot of upstream stuff I wasn't ready to get in that tree just
> yet :-/
I know, but the tree I based it on was what I actually tested against.
When it came to publishing, I wasn't going to rebase and push out
something untested. I hadn't expected it to get pulled so quickly!
Thanks!
g.
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: PCI changes 2.6.26 => 2.6.28
From: Benjamin Herrenschmidt @ 2009-04-27 13:17 UTC (permalink / raw)
To: Gary Thomas; +Cc: linuxppc-dev
In-Reply-To: <49F0EB6A.40000@mlbassoc.com>
On Thu, 2009-04-23 at 16:27 -0600, Gary Thomas wrote:
> I don't think any of this matters. It turns out that even
> the 2.6.26 kernel fails on an identical board with a newer
> revision of the 8347 chip. I'm sure that the problem is
> that the Coral-P fails when mapped to 0 (PCI relative).
There are macro that the PCI code uses to define the min address to
assign to devices but it's broken for us as it doesn't account
for the kind of remapping we do... I've been wanting to fix those
for some time but didn't get a chance yet, that would sort this out.
Ben.
^ permalink raw reply
* Re: Enable Serial Management Controller (SMC) in MPC8265
From: Andres F Marquez @ 2009-04-27 13:40 UTC (permalink / raw)
To: Scott Wood; +Cc: Nirmala Kakkuppi, linuxppc-dev, Haysam Rachid
In-Reply-To: <20090424160247.GA27627@ld0162-tx32.am.freescale.net>
Hello Scott,
Thank you for your support.
After struggling for several days with this issue we have finally
taken a different approach to solve our problem. We wanted to interface
our CPU (MPC8265) with a FPGA through a serial connection. Now, we are
using a parallel interface through the data bus (defining a new memory
region in uboot -an additional chip select).
We tried enabling SCC's and SMC's through the kernel configuration
in ltib, but we were always getting the same tty devices device under
"/dev". No matter how many SCC's or SMC's we enable we were always
getting only /dev/ttyCPM0 and /dev/ttyCPM1. To answer your question,
when I said it did not allow me to configure a tty port through minicom,
I meant it complained because the device was not found.
However, as I said before, we managed to enable it in uboot using
SMC2 as console. The problem we found was that for some reason in uboot
the code is organized in several places to enable either SCC or SMC (but
only as console). We could not find any configuration option to enable
SCC1 as console and SMC2 as serial port at the same time. We tried going
through the uboot code to enable both, but their configuration is
exclusive in several places (only one of them can be enabled at the same
time).
Due to time constraints, we decided to change our design approach as
stated before (parallel interface).
Thank you again for your help.
--
Andres F Marquez
EdgeAccess
Development
amarquez@edgeaccess.net
On Fri, 2009-04-24 at 11:02 -0500, Scott Wood wrote:
> On Thu, Apr 23, 2009 at 07:50:25PM -0400, Andres F Marquez wrote:
> > I am working with a MPC8265 processor for which I am compiling a
> > Kernel using LTIB.
>
> Please contact Freescale support for issues with BSPs. Around here
> you'll be told to upgrade to the latest upstream kernel. :-)
>
> > I enabled SCC1 (for the console) and SMC2 through the Kernel
> > (2.6.25) configuration tool using LTIB. I am able to run my system and
> > execute minicom to try to configure the needed serial port. I have not
> > been able to find the tty port that refers to either one of the two SMC
> > ports.
>
> All CPM serial ports (whether SCC or SMC) will be /dev/ttyCPMn.
>
> > I have tried all the tty's that I get when I do ls /dev/tty* but
> > none of them seem to work. Below, I provide the list of tty's that I am
> > getting. ttyCPM0 is being used for the console. ttyCPM1 is the only one
> > that I am allowed to configure through minicom (for the rest it says
> > device not found).
>
> Not allowed? Don't you have root access to your board?
>
> > After doing some research online, I added an entry in my
> > mpc8272ads.dts file for the smc serial controller. Below, I provide the
> > entries for the serial ports (one SCC1 and one SMC2):
> >
> > serial@11a00 {
> > device_type = "serial";
> > compatible = "fsl,mpc8280-scc-uart",
> > "fsl,cpm2-scc-uart";
> > reg = <11a00 20 8000 100>;
> > interrupts = <28 8>;
> > interrupt-parent = <&PIC>;
> > fsl,cpm-brg = <2>;
> > fsl,cpm-command = <00800000>;
> > };
> >
> > serial@11a92 {
> > device_type = "serial";
> > compatible = "fsl,mpc8280-smc-uart",
> > "fsl,cpm2-smc-uart";
> > reg = <11a92 20 88fc 2>;
> > interrupts = <5 8>;
> > interrupt-parent = <&PIC>;
> > fsl,cpm-brg = <2>;
> > fsl,cpm-command = <21200000>;
> > };
>
> Do you really have both ports on the same BRG?
>
> Change 11a92 to 11a90 -- it's the address of the register block, not the
> first register within the block.
>
> You should also change 8280 to 8265, though nothing currently cares.
>
> Finally, I think 2.6.25 is too old to support automatic allocation of SMC
> parameter RAM. Unless they've backported something in the BSP, you'll
> have to manually allocate some space, remove that chunk from the muram
> node, program SMC2_BASE yourself, and put the address of the actual
> parameter RAM in the device tree. Or, upgrade to the latest upstream
> kernel, or complain to Freescale sales and/or support that the BSP kernel
> is too old for your desired use.
>
> > For some reason in uboot, it seems like the configurations for SCC1 and
> > SMC2 are exclusive. They depend on where the console is configured
> > (SCC1 or SMC2). Either one can be configured, but not both at the same
> > time (at least based on uboot configuration definitions. They are
> > within if's and elif's...). As I said before, both of them are able to
> > run the console.
>
> I don't see any obvious pin conflict between SCC1 and SMC2. It's
> probably just a u-boot limitation -- but make sure that the pins get set
> up for SMC2 even if u-boot doesn't use it.
>
> -Scott
^ permalink raw reply
* Re: microblaze: Statically linking device tree blobs into the kernel
From: Grant Likely @ 2009-04-27 13:47 UTC (permalink / raw)
To: John Williams
Cc: Michal Simek, microblaze-uclinux, Linux Kernel list, linuxppc-dev,
John Linn
In-Reply-To: <1d3f23370904262124l444bc30dmf4178930f4a2b82f@mail.gmail.com>
On Sun, Apr 26, 2009 at 10:24 PM, John Williams
<john.williams@petalogix.com> wrote:
> To MicroBlazers and other interested parties:
>
> Currently the MicroBlaze kernel boot-time ABI requires r7 to point to
> a valid DTB, whereupon in early kernel setup the DTB is copied to a
> statically allocated 16k memory region inside the kernel. From there
> it is later queried by the platform startup code.
>
> For simple boot scenarios the ability to statically bind a DTB into
> the kernel image would clearly be useful. =A0In PPC land, this is
> achieved through the simpleboot bootloader that lives in
> arch/powerpc/boot. =A0The DTB becomes part of the simpleboot payload,
> and is passed to the kernel through the normal means.
>
> I'm not convinced duplicating this for MicroBlaze is a good idea, I
> think it would be overkill. =A0However, the make syntax that PPC uses to
> achieve DTB binding is quite nice:
>
> $ make simpleImage.<board>
>
> which binds arch/powerpc/boot/dts/<board>.dts into the boot payload.
>
> My feeling is that we should make use of the fact that the DTB region
> is statically allocated in the MicroBlaze kernel anyway. =A0From
> arch/microblaze/kernel/vmlinux.lds.S:
>
> =A0 =A0 =A0 =A0. =3D ALIGN (4) ;
> =A0 =A0 =A0 _fdt_start =3D . ; /* place for fdt blob */
> =A0 =A0 =A0 . =3D . + 0x4000;
> =A0 =A0 =A0 _fdt_end =3D . ;
>
> and in head.S, the DTB at r7 is copied into place at _fdt_start
>
> /* save fdt to kernel location */
> /* r7 stores pointer to fdt blob */
> =A0 =A0 =A0 =A0beqi =A0 =A0r7, no_fdt_arg
> =A0 =A0 =A0 =A0or =A0 =A0 =A0r11, r0, r0 /* incremment */
> =A0 =A0 =A0 =A0ori =A0 =A0 r4, r0, TOPHYS(_fdt_start) /* save bram contex=
t */
> =A0 =A0 =A0 =A0ori =A0 =A0 r3, r0, (0x4000 - 4)
> _copy_fdt:
> =A0 =A0 =A0 <simple copy loop>
> no_fdt_arg:
>
> Since this memory is already allocated in the kernel image but is
> normally just zeros, to bind a DTB to the kernel we could just store
> it in-situ. =A0This way, if a non-zero r7 is passed in at boot time,
> head.S will naturally overwrite (and thus override) the "default" DTB
> that was inside the kernel image.
>
> What I'm not so sure about is how best to achieve this in the kbuild
> sequence. =A0I see two options:
>
> =A0(a) use .incbin in a .S file, similar to how the initramfs gets
> linked in in /usr/Makefile etc, or
> =A0(b) use objcopy to manipulate vmlinux after final link, by directly
> inserting the DTB into the appropriate ELF section.
>
> (a) seems nice because it means that our standard make targets, such
> as linux.bin etc, would still work unchanged. =A0(b) seems to go a bit
> against the grain of kbuild, but maybe I'm wrong there.
>
> I've hacked around with (a) a bit, part of the problem is that it
> seems arch/microblaze/Makefile would need something like
I'm partial to (a)too , but I don't know how to achieve it in Kbuild.
Using the linker means that even large .dtb files will get handled
gracefully.
> core-y +=3D arch/microblaze/boot
>
> because the DTB "object file" must be ready before final vmlinux link.
Which works fine with the .dtb list is in the list of default targets,
but is harder for miscellaneous 'make simpleimage.<board>' usage. You
could I suppose duplicate the vmlinux target as simpleimage.% (or
whatever name makes sense) and have the kernel be relinked for each
target provided. In fact, this might be the only way to do (a).
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH V1 3/3] Rename exports in mpc5200_dma.c
From: Grant Likely @ 2009-04-27 13:48 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev
In-Reply-To: <9e4733910904262127k27db6ed1l5540e66ed65872a0@mail.gmail.com>
On Sun, Apr 26, 2009 at 10:27 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Mon, Apr 27, 2009 at 12:08 AM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
>> On Sun, Apr 26, 2009 at 1:53 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>>> Rename the public DMA exports into the global name space so that the DM=
A code can be built as a module.
>>>
>>> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
>>
>> Nack. =A0mpc5200_dma is too generic for the global namespace... (in
>> fact, I should also relook at the previous patch; I might need to nack
>> my ack). =A0Some variant of 'mpc5200_psc_snd_dma' would be more
>> appropriate. =A0Even mpc5200_psc_dma is too generic because other
>> non-sound PSC modes can use DMA also.
>
> I'll change it to mpc5200_audio_dma and resend this to the series to
> the alsa list.
>
> Does your stuff still work with these patches? I want to get these
> mechanical changes in so we can focus on the real changes in my later
> patches.
The project changed and I haven't fired up my target in quite a long time. =
:-(
g.
>
>>
>> g.
>>
>>> ---
>>> =A0sound/soc/fsl/mpc5200_dma.c =A0 =A0 | =A0 18 ++++++++++++------
>>> =A0sound/soc/fsl/mpc5200_dma.h =A0 =A0 | =A0 10 +++++-----
>>> =A0sound/soc/fsl/mpc5200_psc_i2s.c | =A0 14 +++++++-------
>>> =A03 files changed, 24 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
>>> index c82ef75..df73755 100644
>>> --- a/sound/soc/fsl/mpc5200_dma.c
>>> +++ b/sound/soc/fsl/mpc5200_dma.c
>>> @@ -113,7 +113,7 @@ static irqreturn_t psc_dma_bcom_irq(int irq, void *=
_psc_dma_stream)
>>> =A0* If this is the first stream open, then grab the IRQ and program mo=
st of
>>> =A0* the PSC registers.
>>> =A0*/
>>> -int psc_dma_startup(struct snd_pcm_substream *substream,
>>> +int mpc5200_dma_startup(struct snd_pcm_substream *substream,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct snd_soc_dai =
*dai)
>>> =A0{
>>> =A0 =A0 =A0 =A0struct snd_soc_pcm_runtime *rtd =3D substream->private_d=
ata;
>>> @@ -145,13 +145,16 @@ int psc_dma_startup(struct snd_pcm_substream *sub=
stream,
>>>
>>> =A0 =A0 =A0 =A0return 0;
>>> =A0}
>>> +EXPORT_SYMBOL_GPL(mpc5200_dma_startup);
>>>
>>> -int psc_dma_hw_free(struct snd_pcm_substream *substream,
>>> +int mpc5200_dma_hw_free(struct snd_pcm_substream *substream,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct snd_soc_dai =
*dai)
>>> =A0{
>>> =A0 =A0 =A0 =A0snd_pcm_set_runtime_buffer(substream, NULL);
>>> =A0 =A0 =A0 =A0return 0;
>>> =A0}
>>> +EXPORT_SYMBOL_GPL(mpc5200_dma_hw_free);
>>> +
>>>
>>> =A0/**
>>> =A0* psc_dma_trigger: start and stop the DMA transfer.
>>> @@ -159,7 +162,7 @@ int psc_dma_hw_free(struct snd_pcm_substream *subst=
ream,
>>> =A0* This function is called by ALSA to start, stop, pause, and resume =
the DMA
>>> =A0* transfer of data.
>>> =A0*/
>>> -int psc_dma_trigger(struct snd_pcm_substream *substream, int cmd,
>>> +int mpc5200_dma_trigger(struct snd_pcm_substream *substream, int cmd,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct snd_soc_dai =
*dai)
>>> =A0{
>>> =A0 =A0 =A0 =A0struct snd_soc_pcm_runtime *rtd =3D substream->private_d=
ata;
>>> @@ -269,13 +272,15 @@ int psc_dma_trigger(struct snd_pcm_substream *sub=
stream, int cmd,
>>>
>>> =A0 =A0 =A0 =A0return 0;
>>> =A0}
>>> +EXPORT_SYMBOL_GPL(mpc5200_dma_trigger);
>>> +
>>>
>>> =A0/**
>>> =A0* psc_dma_shutdown: shutdown the data transfer on a stream
>>> =A0*
>>> =A0* Shutdown the PSC if there are no other substreams open.
>>> =A0*/
>>> -void psc_dma_shutdown(struct snd_pcm_substream *substream,
>>> +void mpc5200_dma_shutdown(struct snd_pcm_substream *substream,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct snd_soc_=
dai *dai)
>>> =A0{
>>> =A0 =A0 =A0 =A0struct snd_soc_pcm_runtime *rtd =3D substream->private_d=
ata;
>>> @@ -303,6 +308,7 @@ void psc_dma_shutdown(struct snd_pcm_substream *sub=
stream,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0free_irq(psc_dma->playback.irq, &psc_dma=
->playback);
>>> =A0 =A0 =A0 =A0}
>>> =A0}
>>> +EXPORT_SYMBOL_GPL(mpc5200_dma_shutdown);
>>>
>>> =A0/* -----------------------------------------------------------------=
----
>>> =A0* The PSC DMA 'ASoC platform' driver
>>> @@ -448,10 +454,10 @@ static void psc_dma_pcm_free(struct snd_pcm *pcm)
>>> =A0 =A0 =A0 =A0}
>>> =A0}
>>>
>>> -struct snd_soc_platform psc_dma_pcm_soc_platform =3D {
>>> +struct snd_soc_platform mpc5200_dma_platform =3D {
>>> =A0 =A0 =A0 =A0.name =A0 =A0 =A0 =A0 =A0 =3D "mpc5200-psc-audio",
>>> =A0 =A0 =A0 =A0.pcm_ops =A0 =A0 =A0 =A0=3D &psc_dma_pcm_ops,
>>> =A0 =A0 =A0 =A0.pcm_new =A0 =A0 =A0 =A0=3D &psc_dma_pcm_new,
>>> =A0 =A0 =A0 =A0.pcm_free =A0 =A0 =A0 =3D &psc_dma_pcm_free,
>>> =A0};
>>> -
>>> +EXPORT_SYMBOL_GPL(mpc5200_dma_platform);
>>> diff --git a/sound/soc/fsl/mpc5200_dma.h b/sound/soc/fsl/mpc5200_dma.h
>>> index a33232c..e52b90e 100644
>>> --- a/sound/soc/fsl/mpc5200_dma.h
>>> +++ b/sound/soc/fsl/mpc5200_dma.h
>>> @@ -64,18 +64,18 @@ struct psc_dma {
>>> =A0};
>>>
>>>
>>> -int psc_dma_startup(struct snd_pcm_substream *substream,
>>> +int mpc5200_dma_startup(struct snd_pcm_substream *substream,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct snd_soc_dai =
*dai);
>>>
>>> -int psc_dma_hw_free(struct snd_pcm_substream *substream,
>>> +int mpc5200_dma_hw_free(struct snd_pcm_substream *substream,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct snd_soc_dai =
*dai);
>>>
>>> -void psc_dma_shutdown(struct snd_pcm_substream *substream,
>>> +void mpc5200_dma_shutdown(struct snd_pcm_substream *substream,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct snd_soc_=
dai *dai);
>>>
>>> -int psc_dma_trigger(struct snd_pcm_substream *substream, int cmd,
>>> +int mpc5200_dma_trigger(struct snd_pcm_substream *substream, int cmd,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct snd_soc_dai =
*dai);
>>>
>>> -extern struct snd_soc_platform psc_dma_pcm_soc_platform;
>>> +extern struct snd_soc_platform mpc5200_dma_platform;
>>>
>>> =A0#endif /* __SOUND_SOC_FSL_MPC5200_DMA_H__ */
>>> diff --git a/sound/soc/fsl/mpc5200_psc_i2s.c b/sound/soc/fsl/mpc5200_ps=
c_i2s.c
>>> index 12a7917..a4a439c 100644
>>> --- a/sound/soc/fsl/mpc5200_psc_i2s.c
>>> +++ b/sound/soc/fsl/mpc5200_psc_i2s.c
>>> @@ -140,11 +140,11 @@ static int psc_i2s_set_fmt(struct snd_soc_dai *cp=
u_dai, unsigned int format)
>>> =A0* psc_i2s_dai_template: template CPU Digital Audio Interface
>>> =A0*/
>>> =A0static struct snd_soc_dai_ops psc_i2s_dai_ops =3D {
>>> - =A0 =A0 =A0 .startup =A0 =A0 =A0 =A0=3D psc_dma_startup,
>>> + =A0 =A0 =A0 .startup =A0 =A0 =A0 =A0=3D mpc5200_dma_startup,
>>> =A0 =A0 =A0 =A0.hw_params =A0 =A0 =A0=3D psc_i2s_hw_params,
>>> - =A0 =A0 =A0 .hw_free =A0 =A0 =A0 =A0=3D psc_dma_hw_free,
>>> - =A0 =A0 =A0 .shutdown =A0 =A0 =A0 =3D psc_dma_shutdown,
>>> - =A0 =A0 =A0 .trigger =A0 =A0 =A0 =A0=3D psc_dma_trigger,
>>> + =A0 =A0 =A0 .hw_free =A0 =A0 =A0 =A0=3D mpc5200_dma_hw_free,
>>> + =A0 =A0 =A0 .shutdown =A0 =A0 =A0 =3D mpc5200_dma_shutdown,
>>> + =A0 =A0 =A0 .trigger =A0 =A0 =A0 =A0=3D mpc5200_dma_trigger,
>>> =A0 =A0 =A0 =A0.set_sysclk =A0 =A0 =3D psc_i2s_set_sysclk,
>>> =A0 =A0 =A0 =A0.set_fmt =A0 =A0 =A0 =A0=3D psc_i2s_set_fmt,
>>> =A0};
>>> @@ -350,10 +350,10 @@ static int __devinit psc_i2s_of_probe(struct of_d=
evice *op,
>>> =A0 =A0 =A0 =A0if (rc)
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev_info(psc_dma->dev, "error creating s=
ysfs files\n");
>>>
>>> - =A0 =A0 =A0 snd_soc_register_platform(&psc_dma_pcm_soc_platform);
>>> + =A0 =A0 =A0 snd_soc_register_platform(&mpc5200_dma_platform);
>>>
>>> =A0 =A0 =A0 =A0/* Tell the ASoC OF helpers about it */
>>> - =A0 =A0 =A0 of_snd_soc_register_platform(&psc_dma_pcm_soc_platform, o=
p->node,
>>> + =A0 =A0 =A0 of_snd_soc_register_platform(&mpc5200_dma_platform, op->n=
ode,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
&psc_dma->dai);
>>>
>>> =A0 =A0 =A0 =A0return 0;
>>> @@ -365,7 +365,7 @@ static int __devexit psc_i2s_of_remove(struct of_de=
vice *op)
>>>
>>> =A0 =A0 =A0 =A0dev_dbg(&op->dev, "psc_i2s_remove()\n");
>>>
>>> - =A0 =A0 =A0 snd_soc_unregister_platform(&psc_dma_pcm_soc_platform);
>>> + =A0 =A0 =A0 snd_soc_unregister_platform(&mpc5200_dma_platform);
>>>
>>> =A0 =A0 =A0 =A0bcom_gen_bd_rx_release(psc_dma->capture.bcom_task);
>>> =A0 =A0 =A0 =A0bcom_gen_bd_tx_release(psc_dma->playback.bcom_task);
>>>
>>>
>>
>>
>>
>> --
>> Grant Likely, B.Sc., P.Eng.
>> Secret Lab Technologies Ltd.
>>
>
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] powerpc/86xx: clean up smp init code
From: Kumar Gala @ 2009-04-27 13:59 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev
In-Reply-To: <49F064EB.5030109@gefanuc.com>
On Apr 23, 2009, at 7:54 AM, Martyn Welch wrote:
> Kumar Gala wrote:
>> Removed the need for asm/mpc86xx.h as it was only used in
>> mpc86xx_smp.c
>> and just moved the defines it cared about into there. Also fixed up
>> the ioremap to only map the one 4k page we need access to and to
>> iounmap
>> when we are done.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> ---
>> arch/powerpc/include/asm/mpc86xx.h | 33
>> ----------------------------
>> arch/powerpc/platforms/86xx/gef_ppc9a.c | 1 -
>> arch/powerpc/platforms/86xx/gef_sbc310.c | 1 -
>> arch/powerpc/platforms/86xx/gef_sbc610.c | 1 -
>> arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 1 -
>> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 1 -
>> arch/powerpc/platforms/86xx/mpc86xx_smp.c | 8 ++++++-
>> arch/powerpc/platforms/86xx/sbc8641d.c | 1 -
>> 8 files changed, 7 insertions(+), 40 deletions(-)
>> delete mode 100644 arch/powerpc/include/asm/mpc86xx.h
>>
>>
> I assume this patch relies on one of the other patches posted?
>
> Just applying this patch to my development tree (based on your main
> branch) resulted in the following on a PPC9A:
>
> mpic: requesting IPIs ...
> __ioremap(): phys addr 0x0 is RAM lr c041e5c8
> Unable to handle kernel paging request for data at address 0x00000010
> Faulting instruction address: 0xc041e5cc
> Oops: Kernel access of bad area, sig: 11 [#1]
> PREEMPT SMP NR_CPUS=2 GE Fanuc PPC9A
> Modules linked in:
> NIP: c041e5cc LR: c041e5c8 CTR: c0013d90
> REGS: ef841ea0 TRAP: 0300 Not tainted (2.6.30-rc3-00016-gabae74f)
> MSR: 00001032 <ME,IR,DR> CR: 24000022 XER: 00000000
> DAR: 00000010, DSISR: 40000000
> TASK = ef83f980[1] 'swapper' THREAD: ef840000 CPU: 0
> GPR00: c041e5c8 ef841f50 ef83f980 00000000 00001032 ffffffff
> c0480000 00004000
> GPR08: c0441a4c 00000000 ef840000 c0440000 22000042 ffffdfff
> 0ff50d00 00000001
> GPR16: ffffffff 00000000 c0440000 c0480000 c0480000 c0468000
> c0440000 c0442838
> GPR24: 00000002 c0480000 c0480000 7d5043a6 00009032 00000004
> 00000001 0000c350
> NIP [c041e5cc] smp_86xx_kick_cpu+0x70/0x11c
> LR [c041e5c8] smp_86xx_kick_cpu+0x6c/0x11c
> Call Trace:
> [ef841f50] [c041e5c8] smp_86xx_kick_cpu+0x6c/0x11c (unreliable)
>
> [ef841f70] [c0435010] __cpu_up+0xa4/0x1b0
> [ef841f90] [c04355ec] cpu_up+0x104/0x1cc
> [ef841fd0] [c0412368] kernel_init+0x1d8/0x1f0
> [ef841ff0] [c0012cb8] kernel_thread+0x4c/0x68
> Instruction dump:
> 3c80c000 61290100 38a00001 7d234b78 38843464 83690000 4bbfa7f9
> 4bbfcb21
> 38801000 38631000 4bbf91ad 7c0004ac <81230010> 0c090000 4c00012c
> 38000001
> ---[ end trace 31fd0ba7d8756001 ]---
> Kernel panic - not syncing: Attempted to kill init!
> Rebooting in 180 seconds..
I'm not able to reproduce this failure. It seems like either ioremap
is returning 0 or you are getting 0 from get_immrbase().. either way I
don't see how my change would cause what you are seeing on your board.
Are you running w/CONFIG_PHYS_64BIT=y?
- k
- k
^ permalink raw reply
* Re: [PATCH] powerpc: convert mace to netdev_ops
From: Rogério Brito @ 2009-04-27 14:20 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, paulus, linux-kernel, netdev
In-Reply-To: <20090427.054258.16622932.davem@davemloft.net>
Hi, Dave.
On Apr 27 2009, David Miller wrote:
> You can fix the mace_set_timeout() function arguments by having a
> helper function that simply wraps around it and provides the second
> expection of argument types.
Hummm, this means that I'm not that bad... The wrapper function was the
first thing that came to my mind, but I just wanted to be as least
disruptive as possible.
> Your patch is also wrong, it's missing a lot of netdev_ops
> entries that are implicitly obtained via alloc_etherdev(),
> namely:
Thanks for pointing those out. I didn't find the documentation about
netdev_ops under Documentation (a simple grep didn't turn any results).
> .ndo_change_mtu = eth_change_mtu,
> .ndo_set_mac_address = eth_mac_addr,
> .ndo_validate_addr = eth_validate_addr,
Nice. I will incorporate such things.
Thanks, Rogério Brito.
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Timur Tabi @ 2009-04-27 14:31 UTC (permalink / raw)
To: Liu Dave-R63238
Cc: Ira Snyder, linux-kernel, linuxppc-dev, Dan Williams, Zhang Wei
In-Reply-To: <D7CCA83BB0796C49BC0BB53B6AB1208928CA1D@zch01exm21.fsl.freescale.net>
On Mon, Apr 27, 2009 at 4:09 AM, Liu Dave-R63238 <DaveLiu@freescale.com> wrote:
> You are assuming the PCI memory space is prefetchable( no side effect)
> for DMA.
> Is it possible that DMA is from non-prefetchable memory space?
This should be a safe assumption for this driver. Remember, this
driver just does offload memcpy, from one region to another. So the
PCI memory that you are reading from should be just a buffer of data,
and there should be side-effect of reading it.
However, I would like to see a comment at the top of the file warning
people that copying from PCI memory will result in prefetched reads.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc/86xx: clean up smp init code
From: Martyn Welch @ 2009-04-27 15:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <8AE021A6-CA3A-462E-B3AF-61A7F7D0CBA8@kernel.crashing.org>
Kumar Gala wrote:
>
> On Apr 23, 2009, at 7:54 AM, Martyn Welch wrote:
>
>> Kumar Gala wrote:
>>> Removed the need for asm/mpc86xx.h as it was only used in mpc86xx_smp.c
>>> and just moved the defines it cared about into there. Also fixed up
>>> the ioremap to only map the one 4k page we need access to and to
>>> iounmap
>>> when we are done.
>>>
>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>> ---
>>> arch/powerpc/include/asm/mpc86xx.h | 33
>>> ----------------------------
>>> arch/powerpc/platforms/86xx/gef_ppc9a.c | 1 -
>>> arch/powerpc/platforms/86xx/gef_sbc310.c | 1 -
>>> arch/powerpc/platforms/86xx/gef_sbc610.c | 1 -
>>> arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 1 -
>>> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 1 -
>>> arch/powerpc/platforms/86xx/mpc86xx_smp.c | 8 ++++++-
>>> arch/powerpc/platforms/86xx/sbc8641d.c | 1 -
>>> 8 files changed, 7 insertions(+), 40 deletions(-)
>>> delete mode 100644 arch/powerpc/include/asm/mpc86xx.h
>>>
>>>
>> I assume this patch relies on one of the other patches posted?
>>
>> Just applying this patch to my development tree (based on your main
>> branch) resulted in the following on a PPC9A:
>>
>> mpic: requesting IPIs ...
>> __ioremap(): phys addr 0x0 is RAM lr c041e5c8
>> Unable to handle kernel paging request for data at address 0x00000010
>> Faulting instruction address: 0xc041e5cc
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> PREEMPT SMP NR_CPUS=2 GE Fanuc PPC9A
>> Modules linked in:
>> NIP: c041e5cc LR: c041e5c8 CTR: c0013d90
>> REGS: ef841ea0 TRAP: 0300 Not tainted (2.6.30-rc3-00016-gabae74f)
>> MSR: 00001032 <ME,IR,DR> CR: 24000022 XER: 00000000
>> DAR: 00000010, DSISR: 40000000
>> TASK = ef83f980[1] 'swapper' THREAD: ef840000 CPU: 0
>> GPR00: c041e5c8 ef841f50 ef83f980 00000000 00001032 ffffffff c0480000
>> 00004000
>> GPR08: c0441a4c 00000000 ef840000 c0440000 22000042 ffffdfff 0ff50d00
>> 00000001
>> GPR16: ffffffff 00000000 c0440000 c0480000 c0480000 c0468000 c0440000
>> c0442838
>> GPR24: 00000002 c0480000 c0480000 7d5043a6 00009032 00000004 00000001
>> 0000c350
>> NIP [c041e5cc] smp_86xx_kick_cpu+0x70/0x11c
>> LR [c041e5c8] smp_86xx_kick_cpu+0x6c/0x11c
>> Call Trace:
>> [ef841f50] [c041e5c8] smp_86xx_kick_cpu+0x6c/0x11c (unreliable)
>>
>> [ef841f70] [c0435010] __cpu_up+0xa4/0x1b0
>> [ef841f90] [c04355ec] cpu_up+0x104/0x1cc
>> [ef841fd0] [c0412368] kernel_init+0x1d8/0x1f0
>> [ef841ff0] [c0012cb8] kernel_thread+0x4c/0x68
>> Instruction dump:
>> 3c80c000 61290100 38a00001 7d234b78 38843464 83690000 4bbfa7f9 4bbfcb21
>> 38801000 38631000 4bbf91ad 7c0004ac <81230010> 0c090000 4c00012c
>> 38000001
>> ---[ end trace 31fd0ba7d8756001 ]---
>> Kernel panic - not syncing: Attempted to kill init!
>> Rebooting in 180 seconds..
>
> I'm not able to reproduce this failure. It seems like either ioremap
> is returning 0 or you are getting 0 from get_immrbase().. either way I
> don't see how my change would cause what you are seeing on your board.
I've just built the kernel with no local patches in case they were
causing the problem and adding this patch causes the above problem.
> Are you running w/CONFIG_PHYS_64BIT=y?
I am using the config in the kernel
("arch/powerpc/configs/68xx/gef_ppc9a_defconfig") as is, ditto for the DTS.
CONFIG_PHYS_64BIT is not set.
However, looking into it a bit further 'device_type = "soc";' is missing
from the DTS file, so I assume get_immrbase() is returning "-1".
That might explain some other weird errors I recently noticed that I
haven't managed to find the time to track down yet...
Martyn
^ permalink raw reply
* Re: Enable Serial Management Controller (SMC) in MPC8265
From: Scott Wood @ 2009-04-27 15:19 UTC (permalink / raw)
To: Andres Marquez; +Cc: Nirmala Kakkuppi, linuxppc-dev, Haysam Rachid
In-Reply-To: <1240839625.3643.19.camel@localhost.localdomain>
Andres F Marquez wrote:
> After struggling for several days with this issue we have finally
> taken a different approach to solve our problem. We wanted to interface
> our CPU (MPC8265) with a FPGA through a serial connection. Now, we are
> using a parallel interface through the data bus (defining a new memory
> region in uboot -an additional chip select).
That sounds much better.
> We tried enabling SCC's and SMC's through the kernel configuration
> in ltib,
LTIB doesn't alter device trees AFAIK... Unless you have more than two
CPM serial nodes, you won't get more than ttyCPM0 and ttyCPM1.
> but we were always getting the same tty devices device under
> "/dev". No matter how many SCC's or SMC's we enable we were always
> getting only /dev/ttyCPM0 and /dev/ttyCPM1.
Do you have a static /dev, or are you running mdev or udev? If the
latter, then any changes in the kernel or device tree are not going to
automatically show up in /dev.
-Scott
^ permalink raw reply
* Re: [PATCH v3 09/13] net: Rework ucc_geth driver to use of_mdio infrastructure
From: Grant Likely @ 2009-04-27 15:36 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: linuxppc-dev, Andy Fleming, netdev, David Miller,
linuxppc-dev-bounces+joakim.tjernlund=transmode.se
In-Reply-To: <OFD90DF3E8.3B40B9BF-ONC12575A4.0030C830-C12575A4.00317AE2@transmode.se>
On Sun, Apr 26, 2009 at 3:00 AM, Joakim Tjernlund
<Joakim.Tjernlund@transmode.se> wrote:
> Change in fixed link case, see inline.
>
>>
>> From: Grant Likely <grant.likely@secretlab.ca>
>>
>> This patch simplifies the driver by making use of more common code.
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>> Acked-by: Andy Fleming <afleming@freescale.com>
>> ---
>>
>> =A0drivers/net/ucc_geth.c | =A0 47
> ++++++++++++-----------------------------------
>> =A0drivers/net/ucc_geth.h | =A0 =A02 +-
>> =A02 files changed, 13 insertions(+), 36 deletions(-)
>>
>>
>> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
>> index d3f39e8..195b490 100644
>> --- a/drivers/net/ucc_geth.c
>> +++ b/drivers/net/ucc_geth.c
>> @@ -27,6 +27,7 @@
>> =A0#include <linux/mii.h>
>> =A0#include <linux/phy.h>
>> =A0#include <linux/workqueue.h>
>> +#include <linux/of_mdio.h>
>> =A0#include <linux/of_platform.h>
>>
>> =A0#include <asm/uaccess.h>
>> @@ -1542,12 +1543,14 @@ static int init_phy(struct net_device *dev)
>> =A0 =A0 priv->oldspeed =3D 0;
>> =A0 =A0 priv->oldduplex =3D -1;
>>
>> - =A0 phydev =3D phy_connect(dev, ug_info->phy_bus_id, &adjust_link, 0,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0priv->phy_interface);
>> + =A0 if (!ug_info->phy_node)
>> + =A0 =A0 =A0return 0;
>>
>> - =A0 if (IS_ERR(phydev)) {
>> + =A0 phydev =3D of_phy_connect(dev, ug_info->phy_node, &adjust_link, 0,
>> + =A0 =A0 =A0 =A0 =A0 =A0priv->phy_interface);
>> + =A0 if (!phydev) {
>> =A0 =A0 =A0 =A0printk("%s: Could not attach to PHY\n", dev->name);
>> - =A0 =A0 =A0return PTR_ERR(phydev);
>> + =A0 =A0 =A0return -ENODEV;
>> =A0 =A0 }
>>
>> =A0 =A0 phydev->supported &=3D (ADVERTISED_10baseT_Half |
>> @@ -3519,14 +3522,12 @@ static int ucc_geth_probe(struct of_device*
> ofdev, const struct of_device_id *ma
>> =A0{
>> =A0 =A0 struct device *device =3D &ofdev->dev;
>> =A0 =A0 struct device_node *np =3D ofdev->node;
>> - =A0 struct device_node *mdio;
>> =A0 =A0 struct net_device *dev =3D NULL;
>> =A0 =A0 struct ucc_geth_private *ugeth =3D NULL;
>> =A0 =A0 struct ucc_geth_info *ug_info;
>> =A0 =A0 struct resource res;
>> =A0 =A0 struct device_node *phy;
>> =A0 =A0 int err, ucc_num, max_speed =3D 0;
>> - =A0 const phandle *ph;
>> =A0 =A0 const u32 *fixed_link;
>> =A0 =A0 const unsigned int *prop;
>> =A0 =A0 const char *sprop;
>> @@ -3626,45 +3627,21 @@ static int ucc_geth_probe(struct of_device*
> ofdev, const struct of_device_id *ma
>> =A0 =A0 ug_info->uf_info.irq =3D irq_of_parse_and_map(np, 0);
>> =A0 =A0 fixed_link =3D of_get_property(np, "fixed-link", NULL);
>> =A0 =A0 if (fixed_link) {
>> - =A0 =A0 =A0snprintf(ug_info->phy_bus_id, sizeof(ug_info->phy_bus_id),
>> - =A0 =A0 =A0 =A0 =A0PHY_ID_FMT, "0", fixed_link[0]);
>> =A0 =A0 =A0 =A0phy =3D NULL;
>
> phy assigned to NULL ...
>
>> =A0 =A0 } else {
>> - =A0 =A0 =A0char bus_name[MII_BUS_ID_SIZE];
>> -
>> - =A0 =A0 =A0ph =3D of_get_property(np, "phy-handle", NULL);
>> - =A0 =A0 =A0phy =3D of_find_node_by_phandle(*ph);
>> -
>> + =A0 =A0 =A0phy =3D of_parse_phandle(np, "phy-handle", 0);
>> =A0 =A0 =A0 =A0if (phy =3D=3D NULL)
>> =A0 =A0 =A0 =A0 =A0 return -ENODEV;
>> -
>> - =A0 =A0 =A0/* set the PHY address */
>> - =A0 =A0 =A0prop =3D of_get_property(phy, "reg", NULL);
>> - =A0 =A0 =A0if (prop =3D=3D NULL)
>> - =A0 =A0 =A0 =A0 return -1;
>> -
>> - =A0 =A0 =A0/* Set the bus id */
>> - =A0 =A0 =A0mdio =3D of_get_parent(phy);
>> -
>> - =A0 =A0 =A0if (mdio =3D=3D NULL)
>> - =A0 =A0 =A0 =A0 return -ENODEV;
>> -
>> - =A0 =A0 =A0err =3D of_address_to_resource(mdio, 0, &res);
>> -
>> - =A0 =A0 =A0if (err) {
>> - =A0 =A0 =A0 =A0 of_node_put(mdio);
>> - =A0 =A0 =A0 =A0 return err;
>> - =A0 =A0 =A0}
>> - =A0 =A0 =A0fsl_pq_mdio_bus_name(bus_name, mdio);
>> - =A0 =A0 =A0of_node_put(mdio);
>> - =A0 =A0 =A0snprintf(ug_info->phy_bus_id, sizeof(ug_info->phy_bus_id),
>> - =A0 =A0 =A0 =A0 "%s:%02x", bus_name, *prop);
>> =A0 =A0 }
>> + =A0 ug_info->phy_node =3D phy;
>>
>> =A0 =A0 /* get the phy interface type, or default to MII */
>> =A0 =A0 prop =3D of_get_property(np, "phy-connection-type", NULL);
>> =A0 =A0 if (!prop) {
>> =A0 =A0 =A0 =A0/* handle interface property present in old trees */
>> + =A0 =A0 =A0if (!phy)
>> + =A0 =A0 =A0 =A0 return -ENODEV;
>
> .. here an error is returned. Is this intentional?
Yes, I did that intentionally because it looked like a bug to me
because of_get_property() is passed the phy value. However, I suppose
that if phy is null then of_get_property will just return NULL, so I
think I made a mistake. I'll post a patch to remove these two lines.
g.
>
>> +
>> =A0 =A0 =A0 =A0prop =3D of_get_property(phy, "interface", NULL);
>> =A0 =A0 =A0 =A0if (prop !=3D NULL) {
>> =A0 =A0 =A0 =A0 =A0 phy_interface =3D enet_to_phy_interface[*prop];
>> diff --git a/drivers/net/ucc_geth.h b/drivers/net/ucc_geth.h
>> index 2f8ee7c..bc31975 100644
>> --- a/drivers/net/ucc_geth.h
>> +++ b/drivers/net/ucc_geth.h
>> @@ -1100,7 +1100,7 @@ struct ucc_geth_info {
>> =A0 =A0 u32 eventRegMask;
>> =A0 =A0 u16 pausePeriod;
>> =A0 =A0 u16 extensionField;
>> - =A0 char phy_bus_id[BUS_ID_SIZE];
>> + =A0 struct device_node *phy_node;
>> =A0 =A0 u8 weightfactor[NUM_TX_QUEUES];
>> =A0 =A0 u8 interruptcoalescingmaxvalue[NUM_RX_QUEUES];
>> =A0 =A0 u8 l2qt[UCC_GETH_VLAN_PRIORITY_MAX];
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>>
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] net: Fix ucc_geth.c handling of phy 'interface' property.
From: Grant Likely @ 2009-04-27 15:36 UTC (permalink / raw)
To: Joakim Tjernlund, Andy Fleming, Benjamin Herrenschmidt,
David Miller, linuxppc-dev, netdev
From: Grant Likely <grant.likely@secretlab.ca>
Previous rework to ucc_geth.c to add of_mdio support (net: Rework
ucc_geth driver to use of_mdio infrastructure) added a block of
code which broke older openfirmware device trees which use an
'interface' property in the phy node to describe the connection
between the MAC and the PHY. This patch removes the offending blurb.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/net/ucc_geth.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 195b490..d805d60 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3639,9 +3639,6 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
prop = of_get_property(np, "phy-connection-type", NULL);
if (!prop) {
/* handle interface property present in old trees */
- if (!phy)
- return -ENODEV;
-
prop = of_get_property(phy, "interface", NULL);
if (prop != NULL) {
phy_interface = enet_to_phy_interface[*prop];
^ permalink raw reply related
* Re: [PATCH] powerpc/86xx: clean up smp init code
From: Kumar Gala @ 2009-04-27 15:51 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev
In-Reply-To: <49F5CA09.7090607@gefanuc.com>
On Apr 27, 2009, at 10:06 AM, Martyn Welch wrote:
> I am using the config in the kernel ("arch/powerpc/configs/68xx/
> gef_ppc9a_defconfig") as is, ditto for the DTS.
>
> CONFIG_PHYS_64BIT is not set.
>
> However, looking into it a bit further 'device_type = "soc";' is
> missing from the DTS file, so I assume get_immrbase() is returning
> "-1".
>
> That might explain some other weird errors I recently noticed that I
> haven't managed to find the time to track down yet...
I'm amazed this ever worked. If you want to send me a patch for
the .dts to add device_type = "soc" for your various .dts I'll get
that into 2.6.30
- k
^ permalink raw reply
* [PATCH] powerpc adjust oprofile_cpu_type version 3
From: Mike Wolf @ 2009-04-27 16:17 UTC (permalink / raw)
To: linuxppc-dev
Oprofile is changing the naming it is using for the compatibility modes.
Instead of having compat-power<x>, oprofile will go to family naming
convention and use ibm-compat-v<x>. Currently only ibm-compat-v1 will
be defined.
The notion of compatibility events just started with POWER6. So there is
no way that any other tool could exist that is using these
oprofile_cpu_type strings we want to change.
Signed-off-by: Mike Wolf <mjw@linux.vnet.ibm.com>
---
--- mainline.orig/arch/powerpc/kernel/cputable.c 2009-04-16 09:47:49.000000000 -0500
+++ mainline/arch/powerpc/kernel/cputable.c 2009-04-27 10:28:03.000000000 -0500
@@ -382,7 +382,8 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.machine_check = machine_check_generic,
- .oprofile_cpu_type = "ppc64/compat-power5+",
+ .oprofile_cpu_type = "ppc64/ibm-compat-v1",
+ .oprofile_type = PPC_OPROFILE_POWER4,
.platform = "power5+",
},
{ /* Power6 */
@@ -416,7 +417,8 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.machine_check = machine_check_generic,
- .oprofile_cpu_type = "ppc64/compat-power6",
+ .oprofile_cpu_type = "ppc64/ibm-compat-v1",
+ .oprofile_type = PPC_OPROFILE_POWER4,
.platform = "power6",
},
{ /* 2.06-compliant processor, i.e. Power7 "architected" mode */
@@ -429,7 +431,8 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.machine_check = machine_check_generic,
- .oprofile_cpu_type = "ppc64/compat-power7",
+ .oprofile_type = PPC_OPROFILE_POWER4,
+ .oprofile_cpu_type = "ppc64/ibm-compat-v1",
.platform = "power7",
},
{ /* Power7 */
@@ -1833,8 +1836,10 @@
* and, in that case, keep the current value for
* oprofile_cpu_type.
*/
- if (old.oprofile_cpu_type == NULL)
+ if (old.oprofile_cpu_type == NULL) {
t->oprofile_cpu_type = s->oprofile_cpu_type;
+ t->oprofile_type = s->oprofile_type;
+ }
}
*PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
^ permalink raw reply
* [PATCH] powerpc/86xx: Add device_type entry to soc for ppc9a
From: Martyn Welch @ 2009-04-27 16:24 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
The 'device_type = "soc";' line *is* needed in the DTS for get_immrbase()
to return the correct address.
Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
---
arch/powerpc/boot/dts/gef_ppc9a.dts | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_ppc9a.dts b/arch/powerpc/boot/dts/gef_ppc9a.dts
index d47ad07..53a7a62 100644
--- a/arch/powerpc/boot/dts/gef_ppc9a.dts
+++ b/arch/powerpc/boot/dts/gef_ppc9a.dts
@@ -161,6 +161,7 @@
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
+ device_type = "soc";
compatible = "fsl,mpc8641-soc", "simple-bus";
ranges = <0x0 0xfef00000 0x00100000>;
reg = <0xfef00000 0x100000>; // CCSRBAR 1M
^ permalink raw reply related
* Re: [PATCH 00/13] OF device tree handling of PHY drivers
From: Grant Likely @ 2009-04-27 17:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, afleming, David Miller, netdev
In-Reply-To: <20090427.025436.68188155.davem@davemloft.net>
Kumar,
David has pulled my phylib changes into his -next tree. However, some
of the driver changes have been compile tested only due to lack of
hardware. Who can I ask to test the changes to the following files?
arch/powerpc/platforms/82xx/ep8248e.c | 9 +-
drivers/net/fs_enet/fs_enet-main.c | 69 +--
drivers/net/fs_enet/mii-bitbang.c | 29 +-
drivers/net/fs_enet/mii-fec.c | 26 +-
drivers/net/ucc_geth.c | 47 +-
drivers/net/ucc_geth.h | 2 +-
Thanks,
g.
On Mon, Apr 27, 2009 at 3:54 AM, David Miller <davem@davemloft.net> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
> Date: Sat, 25 Apr 2009 16:52:34 -0600
>
>> This series adds common code for reading PHY connection data out of
>> the OpenFirmware device tree. =A0This simplifies the network drivers
>> which use the device tree and which currently implement their own
>> solutions for reading the PHY data out of the device tree directly.
>>
>> I would like to see this series, or at least the core changes (1-4)
>> plus the tested drivers (5-8 & 12, but #12 is a new driver and it
>> may need more review), go into -next for 2.6.31.
>>
>> Due to dependencies, I think it is easiest if all of them go in via the
>> same tree. =A0David, are you willing to merge them via yours? =A0Four of=
the
>> patches are outside of drivers/net (patches 1 and 4 touch drivers/of/,
>> and patches 9 & 10 touch arch/powerpc), but I personally have no issues
>> if those changes go through you. =A0I just need to double check with Ben=
H.
>
> I've applied all of these patches to net-next-2.6, thanks.
>
>> =A0 git://git.secretlab.ca/git/linux-2.6 next-net
>
> You know, if you had actually based this tree on net-next-2.6
> I could have pulled from it. =A0I actually tried, and I got a
> lot of upstream stuff I wasn't ready to get in that tree just
> yet :-/
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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