* RE: Help with device tree binding for SMC serial
From: Rune Torgersen @ 2008-01-11 14:13 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B03D9A042@ismail.innsys.innovsys.com>
> From: Rune Torgersen
> Finally got it (sort-of) working.
> Turned out that for some reason the console init is setting=20
> the baudrate
> to 9600
> the options string passed in to the console init fuunction is NULL.
>=20
> Any idea oon how this should be passed in from u-boot?
Ok, needed a valid console=3D line on the command line. WHen we tried
that, we had a typo, so it was not recognized.
Our old 2.6.18 arch/ppc kernel didn't need a console parameter, it got
the baudrate from u-boot somehow.
Anyway of doing that here too?
^ permalink raw reply
* Re: libfdt: Add fdt_set_name() function
From: Josh Boyer @ 2008-01-11 14:30 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <E1JDKBV-0007Hq-Dm@jdl.com>
On Fri, 11 Jan 2008 07:44:33 -0600
Jon Loeliger <jdl@jdl.com> wrote:
> So, like, the other day David Gibson mumbled:
> > This patch adds an fdt_set_name() function to libfdt, mirroring
> > fdt_get_name(). This is a r/w function which alters the name of a
> > given device tree node.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> Applied.
Awesome. Now if we could just get that into the kernel and usable in
the wrappers... :)
josh
^ permalink raw reply
* Re: libfdt: Add fdt_set_name() function
From: Jon Loeliger @ 2008-01-11 14:38 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20080111083003.38b556d6@zod.rchland.ibm.com>
So, like, the other day Josh Boyer mumbled:
> On Fri, 11 Jan 2008 07:44:33 -0600
> Jon Loeliger <jdl@jdl.com> wrote:
>
> > So, like, the other day David Gibson mumbled:
> > > This patch adds an fdt_set_name() function to libfdt, mirroring
> > > fdt_get_name(). This is a r/w function which alters the name of a
> > > given device tree node.
> > >
> > > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> >
> > Applied.
>
> Awesome. Now if we could just get that into the kernel and usable in
> the wrappers... :)
I've pushed it out now.
I guess we'll try to get the real v1.1.0 into the kernel then?
Maybe at 2.6.25?
jdl
^ permalink raw reply
* Re: PPC vs POWERPC
From: Grant Likely @ 2008-01-11 14:52 UTC (permalink / raw)
To: samppa@sundmangroup.com; +Cc: linuxppc-embedded
In-Reply-To: <23145.147.11.3.128.1200054808.squirrel@www.sundmangroup.com>
On 1/11/08, samppa@sundmangroup.com <samppa@sundmangroup.com> wrote:
> Hi,
> I want to port a board ( WRS SBC8265 ) from the PPC branch to the POWERPC
> branch in the Linux Kernel -- do you have any good starting points that
> describes what I need to pay attention to?
>
> I've already made a port of U-boot-1.3.1 and enabled CONFIG_OF_LIBFDT.
>
> So I need to create a DTS file, compile it with the DTC compiler and port
> the current PPC branch to the POWERPC branch to my understanding.
Yes, you're exactly right. Use one of the dts files in
arch/powerpc/boot/dts as a starting point and read
Documentation/powerpc/booting-without-of.txt to find out what is
expected in the device tree.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2] [ALSA] Add ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-11 15:08 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, alsa-devel, david
In-Reply-To: <20080111002450.GA13291@lixom.net>
Olof Johansson wrote:
> Having been in a similar situation myself (needing to share resources
> between DMA, ethernet and function offload), I recommend creating a
> separate small library that all those drivers use, instead of making
> some sort of dependency between drivers in completely different parts
> of the kernel.
Well, the DMA driver should be in soon. Actually, it should be in now, because
I saw a blurb in this month's Linux Journal about it. As soon as I find it :-),
I'll post a new patch that adds arbitration.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: PCI Failed to allocate mem for PCI ROM
From: Kumar Gala @ 2008-01-11 15:41 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Greg KH, linux-pci, LKML, linuxppc-dev list
In-Reply-To: <47873333.5020202@gmail.com>
On Jan 11, 2008, at 3:13 AM, Jiri Slaby wrote:
> On 01/11/2008 10:07 AM, Kumar Gala wrote:
>> On Jan 11, 2008, at 2:41 AM, Jiri Slaby wrote:
>>> On 01/11/2008 09:29 AM, Kumar Gala wrote:
>>>> Greg,
>>>> I'm getting the following message from the kernel on an embedded
>>>> ppc32 system:
>>>> PCI: Failed to allocate mem resource #9:100000@e0000000 for
>>>> 0000:00:00.0
>>>> The HW setup is a PCIe host controller and an e1000 NIC card. It
>>>> appears that pci_bus_assign_resources() is trying to call
>>>> pci_assign_resource() for the ROM and the resource for the ROM is
>>>> [100000:1fffff] where the PHB is [c0000000:dfffffff].
>>>> It seems like the resno that pci_assign_resource is getting
>>>> called with is wrong and thus pci_update_resource() doesn't get
>>>> called.
>>>> any ideas?
>>>
>>> Kernel version, please.
>> Sorry, its 2.6.24-rc7 + some ppc patches queued for 2.6.25
>
> Could you try this patch?
> http://git.kernel.org/?p=linux/kernel/git/gregkh/patches.git;a=blob_plain;f=pci/pci-remove-default-pci-expansion-rom-memory-allocation.patch
>
> Greg: is this 2.6.25 material, please? We need this for SP2.
I saw that patch, but if you notice that its just x86 specific and I'm
having the issue on a powerpc 32-bit system.
- k
^ permalink raw reply
* Re: [i2c] [PATCH 0/5] Version 17, series to add device tree naming to i2c
From: Jon Smirl @ 2008-01-11 15:52 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, i2c, linux-kernel
In-Reply-To: <20080111095638.775670ed@hyperion.delvare>
On 1/11/08, Jean Delvare <khali@linux-fr.org> wrote:
> Hi Jon,
>
> On Wed, 19 Dec 2007 23:41:36 -0500, Jon Smirl wrote:
> > Since copying i2c-mpc.c to maintain support for the ppc architecture seems to be an issue; instead rework i2c-mpc.c to use CONFIG_PPC_MERGE #ifdefs to support both the ppc and powerpc architecture. When ppc is deleted in six months these #ifdefs will need to be removed.
> >
> > Another rework of the i2c for powerpc device tree patch. This version implements standard alias naming only on the powerpc platform and only for the device tree names. The old naming mechanism of i2c_client.name,driver_name is left in place and not changed for non-powerpc platforms. This patch is fully capable of dynamically loading the i2c modules. You can modprobe in the i2c-mpc driver and the i2c modules described in the device tree will be automatically loaded. Modules also work if compiled in.
> >
> > The follow on patch to module-init-tools is also needed since the i2c subsystem has never implemented dynamic loading.
> >
> > The following series implements standard linux module aliasing for i2c modules on arch=powerpc. It then converts the mpc i2c driver from being a platform driver to an open firmware one. I2C device names are picked up from the device tree. Module aliasing is used to translate from device tree names into to linux kernel names. Several i2c drivers are updated to use the new aliasing.
>
> Now that I have read all the previous versions of this patch series
> and, more importantly, all objections that were raised on the way, I
> can start reviewing the latest iteration of your patches. I'll also do
> some testing, although I have no powerpc stuff here, but at least I
> want to make sure that there are no regressions introduced by your
> patches on x86.
Various people were worried about x86. Around version 15 I altered the
patches so that they only impacted PowerPC. If they impact x86 in
current form that is a bug.
When x86 is ready for it I do think dynamic module loading should be
implemented there also.
>
> --
> Jean Delvare
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH for 2.6.24][NET] fs_enet: check for phydev existence in the ethtool handlers
From: Sergej Stepanov @ 2008-01-11 16:01 UTC (permalink / raw)
To: hs; +Cc: Scott Wood, linuxppc-dev, Jeff Garzik
In-Reply-To: <478666C6.2030104@denx.de>
Am Donnerstag, den 10.01.2008, 19:41 +0100 schrieb Heiko Schocher:
> Hello Scott,
>
> Scott Wood wrote:
> > Heiko Schocher wrote:
> >> diff --git a/drivers/net/fs_enet/fs_enet-main.c
> >> b/drivers/net/fs_enet/fs_enet-main.c
> >> index f2a4d39..f432a18 100644
> >> --- a/drivers/net/fs_enet/fs_enet-main.c
> >> +++ b/drivers/net/fs_enet/fs_enet-main.c
> >> @@ -810,6 +810,10 @@ static int fs_enet_open(struct net_device *dev)
> >> if (fep->fpi->use_napi)
> >> napi_enable(&fep->napi);
> >>
> >> + /* to initialize the fep->cur_rx,... */
> >> + /* not doing this, will cause a crash in fs_enet_rx_napi */
> >> + fs_init_bds(fep->ndev);
> >
> > We should do this just before napi_enable() rather than just after, to
> > eliminate any chance of a race window.
>
> Yes, you are right.
> Here is the new patch:
>
It works fine.
Sergej.
^ permalink raw reply
* Re: [i2c] [PATCH 0/5] Version 17, series to add device tree naming to i2c
From: Jochen Friedrich @ 2008-01-11 16:05 UTC (permalink / raw)
To: Jon Smirl; +Cc: Jean Delvare, linuxppc-dev, i2c, linux-kernel
In-Reply-To: <9e4733910801110752k57f1fd7crd5f143900fc64f0b@mail.gmail.com>
Hi Jon,
>>> The following series implements standard linux module aliasing for i2c modules on arch=powerpc. It then converts the mpc i2c driver from being a platform driver to an open firmware one. I2C device names are picked up from the device tree. Module aliasing is used to translate from device tree names into to linux kernel names. Several i2c drivers are updated to use the new aliasing.
>> Now that I have read all the previous versions of this patch series
>> and, more importantly, all objections that were raised on the way, I
>> can start reviewing the latest iteration of your patches. I'll also do
>> some testing, although I have no powerpc stuff here, but at least I
>> want to make sure that there are no regressions introduced by your
>> patches on x86.
> Various people were worried about x86. Around version 15 I altered the
> patches so that they only impacted PowerPC. If they impact x86 in
> current form that is a bug.
I can only second this. The latest version of i2c-cpm
(http://patchwork.ozlabs.org/linuxppc/patch?person=1023&id=15902) makes
use of this patch, as well. On the dbox2, loading and unloading of
modules in any order just works fine.
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH 0/2] [PPC 4xx] L2-cache synchronization for ppc44x
From: Yuri Tikhonov @ 2008-01-11 15:24 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev, sr, dzu
In-Reply-To: <20071128195037.GB22325@gate.ebshome.net>
Hello, Eugene,
The h/w snooping mechanism you are talking about is limited to the Low
Latency (LL) segment of the PLB bus in ppc440sp and ppc440spe chips (see
section "7.2.7 L2 Cache Coherency" of the ppc440spe spec), whereas DMA and
XOR engines use the High Bandwidth (HB) segment of PLB bus (see
section "1.1.2 Internal Buses" of the ppc440spe spec).
Thus, the h/w snooping mechanism is not able to trace the results of
operations performed by DMA and XOR engines and keep L2-cache coherent with
SDRAM, because the data flow through the HB PLB segment. This leads to, for
example, incorrect results of RAID-parity calculations if one uses the h/w
accelerated ppc440spe ADMA driver with L2-cache enabled.
The s/w synchronization algorithms proposed in my patches has no LL PLB
limitations as opposed to h/w snooping, but, probably, this is not the best
way of how it might be implemented. Even though with these patches the h/w
accelerated RAID starts to operate correctly (with L2-cache enabled) there is
a performance degradation (induced by loops in the L2-cache synchronization
routines) observed in the most cases. So, as a result, there is no benefit
from using L2-cache for these, RAID, cases at all.
Regards, Yuri
On Wednesday 28 November 2007 22:50, Eugene Surovegin wrote:
> On Wed, Nov 07, 2007 at 01:40:10AM +0300, Yuri Tikhonov wrote:
> >
> > Hello all,
> >
> > Here is a patch-set for support L2-cache synchronization routines for
> > the ppc44x processors family. I know that the "ppc" branch is for
bug-fixing only, thus
> > the patch-set is just FYI [though enabled but non-coherent L2-cache may
appear as a bug for
> > someone who uses one of the boards listed below :)].
> >
> > [PATCH 1/2] [PPC 4xx] invalidate_l2cache_range() implementation for
ppc44x;
> > [PATCH 2/2] [PPC 44x] enable L2-cache for the following ppc44x-based
boards: ALPR,
> > Katmai, Ocotea, and Taishan.
>
> Why is this all needed?
>
> IIRC ibm440gx_l2c_enable() configures 64G snoop region for L2C.
>
> Did AMCC made non-only-coherent L2C chips recently?
>
> --
> Eugene
>
>
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
^ permalink raw reply
* Re: [PATCH 1/5] Warp Base Platform
From: Sean MacLennan @ 2008-01-11 16:26 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080111210237.5636d0c3.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> I don't where that function is actually defined - I assume it is in one
> of the other recent patch sets.
>
> /me searches ...
> /me reads "ad7414 driver" email ...
> /me notes spaces missing there as well :-)
>
>
I didn't write the ad7414 driver and wanted to change the original code
as little as possible.
> Tricky. You have something that can only be built in (pika_dtm_thread in
> warp.c) calling something that might be a module ... I think you need to
> think of a new way of organizing these pieces.
>
The DTM is a very small, but important part of the taco. Basically it
controls the fan. I could have wrapped it in a CONFIG_AD7414, but I
would rather have a compile time error and ship people the ad7414.c.
That said, I could just slam a CONFIG_AD7414 around the DTM code. It
would just mean that the fan would run at high speed all the time if you
didn't have it.
I really don't want to have to write a driver just to get one register
from the temperature chip. And we want the DTM running ASAP on startup.
I think forcing taco users to build in the i2c and ad7414 drivers is not
a hardship. And we do ship a working kernel with the taco.
And as a special bonus to readers of this thread, an exclusive, never
before seen, picture of tigger, my development taco. I have to point out
it is a development prototype and not the final product.
ftp://ftp.seanm.ca/stuff/tigger.jpg or
http://ftp.seanm.ca/stuff/tigger.jpg .
Cheers,
Sean
^ permalink raw reply
* RFC: Only deal with apple fix if res is memory
From: Kumar Gala @ 2008-01-11 16:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Ben,
Will this impact the apple fix? I'm getting some _IO cases hitting this.
- k
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index d394d41..42a9dab 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -807,6 +807,7 @@ static void __devinit __pcibios_fixup_bus(struct pci_bus *bus)
* their size is smaller than 1M.
*/
if (res->start == hose->pci_mem_offset &&
+ res->flags & IORESOURCE_MEM &&
res->end < 0x100000) {
printk(KERN_INFO
"PCI: Closing bogus Apple Firmware"
^ permalink raw reply related
* Re: PCI Failed to allocate mem for PCI ROM
From: Jiri Slaby @ 2008-01-11 16:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: Greg KH, linux-pci, LKML, linuxppc-dev list
In-Reply-To: <FB6DCE73-5D8A-42AC-AE5C-0C1AD095B50B@kernel.crashing.org>
Kumar Gala napsal(a):
> I saw that patch, but if you notice that its just x86 specific and I'm
> having the issue on a powerpc 32-bit system.
My bad, sorry.
^ permalink raw reply
* Re: [PATCH 1/8] pseries: phyp dump: Docmentation
From: Linas Vepstas @ 2008-01-11 16:57 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, lkessler, mahuja, Olof Johansson, strosake
In-Reply-To: <20080111012641.GX14201@localdomain>
On 10/01/2008, Nathan Lynch <ntl@pobox.com> wrote:
> Mike Strosaker wrote:
> >
> > At the risk of repeating what others have already said, the PHYP-assistance
> > method provides some advantages that the kexec method cannot:
> > - Availability of the system for production use before the dump data is
> > collected. As was mentioned before, some production systems may choose not
> > to operate with the limited memory initially available after the reboot,
> > but it sure is nice to provide the option.
>
> I'm more concerned that this design encourages the user to resume a
> workload *which is almost certainly known to result in a system crash*
> before collection of crash data is complete. Maybe the gamble will
> pay off most of the time, but I wouldn't want to be working support
> when it doesn't.
Workloads that cause crashes within hours of startup tend to be
weeded-out/discovered during pre-production test of the system
to be deployed. Since its pre-production test, dumps can be
taken in a leisurely manner. Heck, even a session at the
xmon prompt can be contemplated.
The problem is when the crash only reproduces after days or
weeks of uptime, on a production machine. Since the machine
is in production, its got to be brought back up ASAP. Since
its crashing only after days/weeks, the dump should have
plenty of time to complete. (And if it crashes quickly after
that reboot ... well, support people always welcome ways
in which a bug can be reproduced more quickly/easily).
--linas
^ permalink raw reply
* Re: Help with device tree binding for SMC serial
From: Scott Wood @ 2008-01-11 17:24 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B03D9A092@ismail.innsys.innovsys.com>
Rune Torgersen wrote:
> Ok, needed a valid console= line on the command line. WHen we tried
> that, we had a typo, so it was not recognized.
> Our old 2.6.18 arch/ppc kernel didn't need a console parameter, it got
> the baudrate from u-boot somehow.
> Anyway of doing that here too?
You could add something to the cuboot code to fill in current-speed
based on the value in the bd_t.
-Scott
^ permalink raw reply
* Re: 2.6.22-ppc8xx fec.c bugs
From: Scott Wood @ 2008-01-11 17:27 UTC (permalink / raw)
To: raul.moreno; +Cc: linuxppc-embedded
In-Reply-To: <OF431AD1B5.8B0529FD-ONC12573CD.002EB1C5-C12573CD.0030B37E@abengoa.com>
raul.moreno@telvent.abengoa.com wrote:
> I didn't know ppc was deprecated. Why is it so?
Having separate 32 and 64 bit powerpc trees was a maintenance headache.
The way arch/ppc is structured was a maintenance headache.
> I have been using this architecture since I started with Linux (not too
> long ago) because I manage a mpc866 processor.
mpc866 chips are supported in arch/powerpc.
> Do you mean that I should port to arch/powerpc?
Yes.
-Scott
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
From: Eugene Surovegin @ 2008-01-11 17:48 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <200801051338.17957.sr@denx.de>
On Sat, Jan 05, 2008 at 01:38:17PM +0100, Stefan Roese wrote:
> On Saturday 05 January 2008, Benjamin Herrenschmidt wrote:
> > On Sat, 2008-01-05 at 10:50 +0100, Stefan Roese wrote:
> > > Performance tests done by AMCC have shown that 256 buffer increase the
> > > performance of the Linux EMAC driver. So let's update the default
> > > values to match this setup.
> > >
> > > Signed-off-by: Stefan Roese <sr@denx.de>
> > > ---
> >
> > Do we have the numbers ? Did they also measure latency ?
>
> I hoped this question would not come. ;) No, unfortunately I don't have any
> numbers. Just the recommendation from AMCC to always use 256 buffers.
This cannot be true for all chips. Default numbers I selected weren't
random. In particular, 256 for Tx doesn't make a lot of sense for 405.
You just gonna waste memory.
I'd be quite reluctant to follow such advices from AMCC without actual
details.
--
Eugene
^ permalink raw reply
* Re: [PATCH 0/2] [PPC 4xx] L2-cache synchronization for ppc44x
From: Eugene Surovegin @ 2008-01-11 17:41 UTC (permalink / raw)
To: Yuri Tikhonov; +Cc: linuxppc-dev, sr, dzu
In-Reply-To: <200801111824.46920.yur@emcraft.com>
On Fri, Jan 11, 2008 at 06:24:46PM +0300, Yuri Tikhonov wrote:
>
> Hello, Eugene,
>
> The h/w snooping mechanism you are talking about is limited to the Low
> Latency (LL) segment of the PLB bus in ppc440sp and ppc440spe chips (see
> section "7.2.7 L2 Cache Coherency" of the ppc440spe spec), whereas DMA and
> XOR engines use the High Bandwidth (HB) segment of PLB bus (see
> section "1.1.2 Internal Buses" of the ppc440spe spec).
>
> Thus, the h/w snooping mechanism is not able to trace the results of
> operations performed by DMA and XOR engines and keep L2-cache coherent with
> SDRAM, because the data flow through the HB PLB segment. This leads to, for
> example, incorrect results of RAID-parity calculations if one uses the h/w
> accelerated ppc440spe ADMA driver with L2-cache enabled.
>
> The s/w synchronization algorithms proposed in my patches has no LL PLB
> limitations as opposed to h/w snooping, but, probably, this is not the best
> way of how it might be implemented. Even though with these patches the h/w
> accelerated RAID starts to operate correctly (with L2-cache enabled) there is
> a performance degradation (induced by loops in the L2-cache synchronization
> routines) observed in the most cases. So, as a result, there is no benefit
> from using L2-cache for these, RAID, cases at all.
Thanks a lot for explanation, Yuri. I'd never imagine they were so
stupid to make new chips with such behaviour.
--
Eugene
^ permalink raw reply
* Re: PCI Failed to allocate mem for PCI ROM
From: Greg KH @ 2008-01-11 17:49 UTC (permalink / raw)
To: Jiri Slaby; +Cc: linuxppc-dev list, linux-pci, LKML
In-Reply-To: <47873333.5020202@gmail.com>
On Fri, Jan 11, 2008 at 10:13:23AM +0100, Jiri Slaby wrote:
> On 01/11/2008 10:07 AM, Kumar Gala wrote:
>> On Jan 11, 2008, at 2:41 AM, Jiri Slaby wrote:
>>> On 01/11/2008 09:29 AM, Kumar Gala wrote:
>>>> Greg,
>>>> I'm getting the following message from the kernel on an embedded ppc32
>>>> system:
>>>> PCI: Failed to allocate mem resource #9:100000@e0000000 for 0000:00:00.0
>>>> The HW setup is a PCIe host controller and an e1000 NIC card. It
>>>> appears that pci_bus_assign_resources() is trying to call
>>>> pci_assign_resource() for the ROM and the resource for the ROM is
>>>> [100000:1fffff] where the PHB is [c0000000:dfffffff].
>>>> It seems like the resno that pci_assign_resource is getting called with
>>>> is wrong and thus pci_update_resource() doesn't get called.
>>>> any ideas?
>>>
>>> Kernel version, please.
>> Sorry, its 2.6.24-rc7 + some ppc patches queued for 2.6.25
>
> Could you try this patch?
> http://git.kernel.org/?p=linux/kernel/git/gregkh/patches.git;a=blob_plain;f=pci/pci-remove-default-pci-expansion-rom-memory-allocation.patch
>
> Greg: is this 2.6.25 material, please? We need this for SP2.
Yes, this is queued up for 2.6.25, and I have no objection to adding it
for SLE10 SP2 if needed. But I think there is another patch in the
series that also goes with this, ask IBM, they know what is needed here.
thanks,
greg k-h
^ permalink raw reply
* Re: PCI Failed to allocate mem for PCI ROM
From: Greg KH @ 2008-01-11 17:50 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, linux-pci, LKML
In-Reply-To: <1B75C5A8-E512-40CB-A6F3-351640701D0D@kernel.crashing.org>
On Fri, Jan 11, 2008 at 02:29:28AM -0600, Kumar Gala wrote:
> Greg,
>
> I'm getting the following message from the kernel on an embedded ppc32
> system:
>
> PCI: Failed to allocate mem resource #9:100000@e0000000 for 0000:00:00.0
>
> The HW setup is a PCIe host controller and an e1000 NIC card. It appears
> that pci_bus_assign_resources() is trying to call pci_assign_resource() for
> the ROM and the resource for the ROM is [100000:1fffff] where the PHB is
> [c0000000:dfffffff].
>
> It seems like the resno that pci_assign_resource is getting called with is
> wrong and thus pci_update_resource() doesn't get called.
>
> any ideas?
Nope, sorry, any help debugging this is appreciated, pci resource
allocation is "tricky" :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/5] Warp Base Platform
From: Josh Boyer @ 2008-01-11 17:51 UTC (permalink / raw)
To: Sean MacLennan; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <47871675.6030602@pikatech.com>
On Fri, 11 Jan 2008 02:10:45 -0500
Sean MacLennan <smaclennan@pikatech.com> wrote:
>
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
> ---
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 66a3d8c..b3e4c35 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -469,7 +469,7 @@ config MCA
> config PCI
> bool "PCI support" if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_86xx \
> || PPC_MPC52xx || (EMBEDDED && (PPC_PSERIES || PPC_ISERIES)) \
> - || PPC_PS3
> + || PPC_PS3 || 44x
> default y if !40x && !CPM2 && !8xx && !PPC_83xx \
> && !PPC_85xx && !PPC_86xx
> default PCI_PERMEDIA if !4xx && !CPM2 && !8xx
> diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
> index d248013..a95409e 100644
> --- a/arch/powerpc/platforms/44x/Kconfig
> +++ b/arch/powerpc/platforms/44x/Kconfig
> @@ -53,6 +53,19 @@ config RAINIER
> help
> This option enables support for the AMCC PPC440GRX evaluation board.
>
> +config WARP
> + bool "PIKA Warp"
> + depends on 44x
> + default n
> + select 440EP
> + help
> + This option enables support for the PIKA Warp(tm) Appliance. The Warp
> + is a small computer replacement with up to 9 ports of FXO/FXS plus VOIP
> + stations and trunks.
> +
> + See http://www.pikatechnologies.com/ and follow the "PIKA for Computer
> + Telephony Developers" link for more information.
> +
> #config LUAN
> # bool "Luan"
> # depends on 44x
> @@ -75,6 +88,7 @@ config 440EP
> select PPC_FPU
> select IBM440EP_ERR42
> select IBM_NEW_EMAC_ZMII
> + select USB_ARCH_HAS_OHCI
>
> config 440EPX
> bool
> diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
> index a2a0dc1..c1733c0 100644
> --- a/arch/powerpc/platforms/44x/Makefile
> +++ b/arch/powerpc/platforms/44x/Makefile
> @@ -5,3 +5,4 @@ obj-$(CONFIG_BAMBOO) += bamboo.o
> obj-$(CONFIG_SEQUOIA) += sequoia.o
> obj-$(CONFIG_KATMAI) += katmai.o
> obj-$(CONFIG_RAINIER) += rainier.o
> +obj-$(CONFIG_WARP) += warp.o
> --- /dev/null 2005-11-20 22:22:37.000000000 -0500
> +++ arch/powerpc/platforms/44x/warp.c 2008-01-11 02:08:20.000000000 -0500
> @@ -0,0 +1,244 @@
> +/*
> + * PIKA Warp(tm) board specific routines
> + *
> + * Copyright (c) 2008 PIKA Technologies
> + * Sean MacLennan <smaclennan@pikatech.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +#include <linux/init.h>
> +#include <linux/of_platform.h>
> +#include <linux/kthread.h>
> +
> +#include <asm/machdep.h>
> +#include <asm/prom.h>
> +#include <asm/udbg.h>
> +#include <asm/time.h>
> +#include <asm/uic.h>
> +
> +#include "44x.h"
> +
> +#define WARP_GPIO_BASE 0xEF600B00ULL
This should be in the device tree...
> +
> +/* This is for the power LEDs 1 = on, 0 = off, -1 = leave alone */
> +void warp_set_power_leds(int green, int red)
> +{
> + static void *gpio_base = NULL;
> + unsigned leds;
> +
> + if (gpio_base == NULL) {
> + gpio_base = ioremap(WARP_GPIO_BASE, 0x148);
... and you should get the resource for it from there instead of using
the #define.
> + if (gpio_base == NULL) {
> + printk("ERROR: Unable to remap GPIO base.\n");
> + return;
> + }
> + }
> +
> + leds = readl(gpio_base + 0x100);
Do you really want readl here? That will byte-swap.
> +
> + switch(green) {
> + case 0: leds &= ~0x80; break;
> + case 1: leds |= 0x80; break;
> + }
> + switch(red) {
> + case 0: leds &= ~0x40; break;
> + case 1: leds |= 0x40; break;
> + }
> +
> + writel(leds, gpio_base + 0x100);
Same here.
> +}
> +EXPORT_SYMBOL(warp_set_power_leds);
Hm... does this really need to be exported?
> +// SAM not yet #define NAND_FLASH
> +#ifdef NAND_FLASH
> +/* --- All of this code is for the NAND flash */
Perhaps you could split this out into warp-nand.c instead of ifdefing
it here. That way it can be left uncompiled until we figure out the
NAND situation in general.
josh
^ permalink raw reply
* Re: [PATCH 2/5] Warp Base Platform - dts
From: Josh Boyer @ 2008-01-11 17:54 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <47870994.9010009@pikatech.com>
On Fri, 11 Jan 2008 01:15:48 -0500
Sean MacLennan <smaclennan@pikatech.com> wrote:
> David Gibson wrote:
> > Or possibly what you actually want is:
> > fpga@2,0 {
> > reg = <2 0 2200>;
> > ...
> > };
> >
> That is what I want. I was missing a call to
> ibm4xx_fixup_ebc_ranges("/plb/opb/ebc"); (see updated patch3/5 to follow.
>
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
This looks pretty darn good, minus the missing GPIO node (see comment
in patch 1).
josh
^ permalink raw reply
* Re: [PATCH 3/5] Warp Base Platform
From: Josh Boyer @ 2008-01-11 17:56 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <47870A0F.7060905@pikatech.com>
On Fri, 11 Jan 2008 01:17:51 -0500
Sean MacLennan <smaclennan@pikatech.com> wrote:
> Update based on fixes to warp.dts.
>
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
Looks good.
josh
^ permalink raw reply
* RE: Help with device tree binding for SMC serial
From: Rune Torgersen @ 2008-01-11 18:11 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <4787A663.2020902@freescale.com>
> From: Scott Wood=20
>=20
> You could add something to the cuboot code to fill in current-speed=20
> based on the value in the bd_t.
>=20
Ahh.. That was what I'm missing.
Where in the devicetree is that supposed to be at?
^ permalink raw reply
* Re: Help with device tree binding for SMC serial
From: Scott Wood @ 2008-01-11 18:15 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B03D9A37A@ismail.innsys.innovsys.com>
Rune Torgersen wrote:
>> From: Scott Wood
>>
>> You could add something to the cuboot code to fill in current-speed
>> based on the value in the bd_t.
>>
>
> Ahh.. That was what I'm missing.
> Where in the devicetree is that supposed to be at?
In the serial node.
-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