* Re: [PATCH 2/2] ehca: correction include order according kernel coding style
From: Roland Dreier @ 2007-07-29 3:39 UTC (permalink / raw)
To: Hoang-Nam Nguyen
Cc: linuxppc-dev, raisch, stefan.roscher, linux-kernel, general
In-Reply-To: <200707271255.19456.hnguyen@linux.vnet.ibm.com>
thanks, I applied this by hand since it was so trivial.
^ permalink raw reply
* Re: [ofa-general] [PATCH 1/2] ehca: remove checkpatch.pl's warnings "externs should be avoided in .c files"
From: Roland Dreier @ 2007-07-29 3:39 UTC (permalink / raw)
To: Hoang-Nam Nguyen; +Cc: linuxppc-dev, stefan.roscher, linux-kernel, general
In-Reply-To: <200707271254.51055.hnguyen@linux.vnet.ibm.com>
the patch looks fine except your mailer seems to have mangled
it... can you resend so I can apply it?
thanks...
^ permalink raw reply
* Re: [2.6 patch] arch/powerpc/Kconfig: fix the EMBEDDED6xx dependencies
From: Adrian Bunk @ 2007-07-28 15:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Andrew Morton, linuxppc-dev, linux-kernel
In-Reply-To: <17779.37050.4039.942954@cargo.ozlabs.ibm.com>
On Mon, Dec 04, 2006 at 02:06:34PM +1100, Paul Mackerras wrote:
> Adrian Bunk writes:
>
> > This patch changes the EMBEDDED6xx dependencies to the equivalent
> > dependency that seems to have been intended.
>
> Nack - CONFIG_EMBEDDED6xx is going away entirely, soon.
Still there - and still with this strange dependency.
> Paul.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: EST's VisionClick debugger fixes for Elf files from GNU tools
From: Richard Danter @ 2007-07-28 11:20 UTC (permalink / raw)
To: Chong, Zhia Howe; +Cc: linuxppc-embedded
In-Reply-To: <ED3AB1534F018544848A18EE0E01E0AC117CCB@pgsmsx414.gar.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 636 bytes --]
On 25/07/07, Chong, Zhia Howe <zhia.howe.chong@intel.com> wrote:
>
> Hi,
>
> I am currently learning to use VisionClick with the VisionICE
> II debugger. Are you aware of using it in Linux? I can only use in VxWorks
> OS. If you know how to use in Linux, mind show me some steps in doing it?
>
Yes, depending on what version of vClick and vICE firmware you have it is
possible to debug some things in Linux. What are you trying to do exactly?
Debug the kernel, modules, applications? What is the target? vClick is old
now, Wind River has newer and much better JTAG/BDM tools (Workbench OCD) for
working with Linux.
Rich
[-- Attachment #2: Type: text/html, Size: 1258 bytes --]
^ permalink raw reply
* Re: [patch 07/35] pasemi_mac: stop using the pci config space accessors for register read/writes
From: Olof Johansson @ 2007-07-28 8:35 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <46A91130.8000907@semihalf.com>
Hi,
On Thu, Jul 26, 2007 at 11:25:04PM +0200, Marian Balakowicz wrote:
>
> Olof,
>
> Olof Johansson wrote:
> > Move away from using the pci config access functions for simple register
> > access. Our device has all of the registers in the config space (hey,
> > from the hardware point of view it looks reasonable :-), so we need to
> > somehow get to it. Newer firmwares have it in the device tree such that
> > we can just get it and ioremap it there (in case it ever moves in future
> > products). For now, provide a hardcoded fallback for older firmwares.
>
> I have recently tried to apply a group of your MAC patches that
> includes the one from this email. Strangely, I got a pretty random
> kernel panics (or kernel freezes) when this patch is included. Panics
> happen in a random, places and have random causes. What I observed is
> that replacing newly introduced mac->iob_regs with the corresponding
> offset from (already ioremapped) hose->cfg_data removed the problem. So,
> it seems that dereferencing pointers based on a second ioremap on a
> subset of 0xe000_0000 addresses is problematic.
The problem is that the IOB register range is 8K, not 4K. I have since
fixed that bug but I didn't repost the patch series. It does cause weird
and strange errors to happen since register writes into the second 4K
would really go to another mapping somewhere else.
So, the quick fix is to always map 0x2000 in map_one_reg, the slightly better
one is to check the PCI dev and only map 2K for the IOB.
> Here are the questions that come to my mind:
>
> - I am testing on a A2 hw, what what your testing setup, anything
> newer than this (something closer B0 maybe), did you have a chance to
> try that on a A2 board?
I'm doing all of my work on A2 hardware at the moment.
> - Is there any particular patch or set of patches/updates that this
> patch may depend on?
There's a fix, but with the description above you should be able to handle it on your
own as well. I'm currently travelling on vacation, but I'll try to post something within
a few days.
> Switching from pci accessors to direct in_* out_* calls drops the
> guard pci spinlock. Initially, I thought that this may be the reason,
> but it's not, adding the spinlock is not solving the problem. But anyway,
> shouldn't we be using it to coordinate access?
The very point of this patch is to avoid doing the spinlock. There's no need
for one in this case, it's pure overhead.
-Olof
^ permalink raw reply
* Re: [PATCH 12/68] 0 -> NULL, for arch/powerpc
From: Paul Mackerras @ 2007-07-27 23:48 UTC (permalink / raw)
To: Yoann Padioleau; +Cc: linuxppc-dev, akpm, kernel-janitors, linux-kernel
In-Reply-To: <200707270945.LAA17267@ifs.emn.fr>
Yoann Padioleau writes:
> When comparing a pointer, it's clearer to compare it to NULL than to 0.
As other people have said, if you're going to spend time on this,
testing (!buf) is more idiomatic in the kernel than (buf == NULL).
Paul.
^ permalink raw reply
* Re: [PATCH] Re: 2.6.22-git hangs during PCMCIA on PowerBook G3 in 0.0 seconds
From: Kim Phillips @ 2007-07-27 23:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1185575207.5495.257.camel@localhost.localdomain>
On Sat, 28 Jul 2007 08:26:47 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Sat, 2007-07-28 at 00:11 +0200, Rutger Nijlunsing wrote:
> > > Kim
> > >
> > > p.s. should the stable team be notified to fix 2.6.22 for
> > > Lombard-nvram-style machines?
> >
> > Logically, yes.
> >
> Two ! Paulus has one :-) Though I'm not sure he uses it often nowadays.
>
I sent the two revert requests to the stable team.
Kim
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] Add support of platforms without PHY to gianfar driver
From: Vitaly Bordug @ 2007-07-27 23:10 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev, Jeff Garzik
In-Reply-To: <20070726190417.de30bed6.kim.phillips@freescale.com>
On Thu, 26 Jul 2007 19:04:17 -0500
Kim Phillips wrote:
> On Wed, 25 Jul 2007 21:43:12 +0400
> Vitaly Bordug <vitb@kernel.crashing.org> wrote:
>
> >
> > Gianfar driver is now able to work without real phy subnode,
> > that is necessary to cope with fixed-link situation, when
> > SoC is connected to the Ethernet inteface or embedded switch
> > without any PHY. In this case, fixed-speed property will
> > describe such a situation for gianfar driver.
> >
> > The property is in form <duplexity speed>
> >
> > Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> >
> > ---
> >
> > arch/powerpc/sysdev/fsl_soc.c | 39
> > +++++++++++++++++++++++----------------
> > drivers/net/gianfar.c | 17 ++++++++++++++---
>
> please run this through checkpatch.pl until it passes.
>
> <snip>
> > + bus_id = of_get_property(np,
> > "fixed_speed",NULL);
>
> hyphens are preferred for new properties. Plus, isn't fixed-link a
> better name? unless you instead want to put speed first and make
> duplexity an optional second, or possibly even a string.
>
> Also, can we get this new property documented in b-w-of in a separate
> patch?
>
yes, fixed-link is better name.
I'll redo the patch, thx
> Kim
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 4/5] 8xx: Remove unnecessary loops_per_jiffy initialization code.
From: Vitaly Bordug @ 2007-07-27 23:06 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1185560699.8055.177.camel@ld0161-tx32>
On Fri, 27 Jul 2007 13:24:59 -0500
Jon Loeliger wrote:
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
Acked-by: Vitaly Bordug <vitb@kernel.crashing.org>
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH] Re: 2.6.22-git hangs during PCMCIA on PowerBook G3 in 0.0 seconds
From: Benjamin Herrenschmidt @ 2007-07-27 22:26 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070727221131.GA18273@nospam.com>
On Sat, 2007-07-28 at 00:11 +0200, Rutger Nijlunsing wrote:
> > Kim
> >
> > p.s. should the stable team be notified to fix 2.6.22 for
> > Lombard-nvram-style machines?
>
> Logically, yes.
>
> Practically it does not matter that much it seems. I've got the
> feeling the Lombard-users-group-size is about one person which is
> going to drop to zero if he doesn't get any further in being able to
> use _any_ PCMCIA card in his machine ;-)
Two ! Paulus has one :-) Though I'm not sure he uses it often nowadays.
> For example, PCMCIA (non-cardbus) does not work on Lombard since
> ~2.6.12 (2 years old bug instantly crashing the kernel!) according to
> own experiences, Google and own git-bisecting down to 2.6.13,
> compiling and running different kernels. 2.6.12 appears to require the
> 'old-style' PCMCIA tools, which I do not have installed and is
> therefore impossible for me to test.
Hrm. If Paul brings his Lombard to work next week, I can have a look.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 5/5] embedded6xx: Remove unnecessary loops_per_jiffy initialization code.
From: Mark A. Greer @ 2007-07-27 22:28 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1185560709.8055.178.camel@ld0161-tx32>
On Fri, Jul 27, 2007 at 01:25:09PM -0500, Jon Loeliger wrote:
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
FWIW for the prpmc2800 part...
Acked-by: Mark A. Greer <mgreer@mvista.com>
^ permalink raw reply
* Re: [PATCH] Re: 2.6.22-git hangs during PCMCIA on PowerBook G3 in 0.0 seconds
From: Rutger Nijlunsing @ 2007-07-27 22:11 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070726162921.a60c76ae.kim.phillips@freescale.com>
> Kim
>
> p.s. should the stable team be notified to fix 2.6.22 for
> Lombard-nvram-style machines?
Logically, yes.
Practically it does not matter that much it seems. I've got the
feeling the Lombard-users-group-size is about one person which is
going to drop to zero if he doesn't get any further in being able to
use _any_ PCMCIA card in his machine ;-)
For example, PCMCIA (non-cardbus) does not work on Lombard since
~2.6.12 (2 years old bug instantly crashing the kernel!) according to
own experiences, Google and own git-bisecting down to 2.6.13,
compiling and running different kernels. 2.6.12 appears to require the
'old-style' PCMCIA tools, which I do not have installed and is
therefore impossible for me to test.
Links:
2.6.12 works with PCMCIA on Lombard:
http://www.mascanc.net/~vieri/gnumela.html
2.6.13 dead
(checked with git)
2.6.15 dead (Lombard PCMCIA problems in FC5):
http://forums.fedoraforum.org/archive/index.php/t-110657.html
2.6.18 dead, 2.6.12 works:
http://lists.infradead.org/pipermail/linux-pcmcia/2006-October/004051.html
2.6.19 dead (own bug report):
http://ozlabs.org/pipermail/linuxppc-dev/2006-November/028617.html
2.6.20 dead:
http://lists.infradead.org/pipermail/linux-pcmcia/2007-April/004500.html
2.6.22 dead (own bug report #2):
http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039863.html
The initial reason to bisect to the now-reverting patch was to get a
working Lombard. I'd like to get this working or to help out in any
way, but I don't know how to proceed...
--
Rutger Nijlunsing ---------------------------------- eludias ed dse.nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------
^ permalink raw reply
* Re: [RFC 0/1] lro: Generic Large Receive Offload for TCP traffic
From: Andrew Gallatin @ 2007-07-27 19:47 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Christoph Raisch, Marcus Eder,
Stefan Roscher, David Miller
In-Reply-To: <200707271418.49781.ossthema@de.ibm.com>
Jan-Bernd Themann wrote:
> On Wednesday 25 July 2007 19:17, Andrew Gallatin wrote:
>> 3) Padded frames.
>>
>> I may be missing something, but I don't see where you
>> either strip padding from frames or reject padded frames.
>> (see the pskb_trim_rcsum() in net/ipv4/ip_input.c:ip_rcv()
>>
> I think I missed something :-) Will fix that.
> In lro_tcp_ip_check we check for the "SKB aggregation interface"
> the skb->len against ip->tot_len. This catches padded frames as
> eth_type_trans(skb, dev) reduces the length of the SKB.
> However, the possible VLAN header is not taken into account.
> And for the "receive in pages" interface a wrong length is passed
> as argument as well.
>
> I'd suggest to reject padded frames for aggregation as we do now
> (when bugs are fixed) and thus keep the code simple.
> I guess that padded frames don't occur too often in high load
> situations. If we detect a real performance issue we can still
> change that later.
The one case where performance may be at issue is in aggregating Acks
on connections w/o TCP timestamps where a frame size of 54 bytes is
padded out to 60. I did some very quick measurements using netperf
-tTCP_SENDFILE on the same athlons mentioned earlier using our 1.3.1
driver. I see a roughly 8% CPU increase (~17% -> ~25%) when I disable
LRO (and hence Ack aggregation) on the sender. This works out to an
increase in service demand from ~0.3 to ~0.44 according to netperf.
With LRO enabled, our counters show we're aggregating acks at a
roughly 3:1 ratio. This is probably an optimization that can be done
later, but it is helpful.
This reminds me.. what would you think about adding some sort of
counters, ideally per-interface, to expose how well LRO is working?
At the simplest level, you could add them to the lro mgr struct and
let drivers export them via ethtool. I think a central approach might
be more appropriate. At any rate, I'd prefer the final
version to at least have counters to indicate how many packets were
aggregated, how many packets were flushed, and how many times we
failed to aggregate something due to insufficient net_lro_desc
descriptors.
Thanks again for taking the lead on this,
Drew
^ permalink raw reply
* Re: help with ppc sections?
From: Chris Friesen @ 2007-07-27 18:55 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40707261255x23b06ff4y5fe1527f72c09c5b@mail.gmail.com>
Grant Likely wrote:
> Mild question; What the *@*#^$! are you doing trying to backport to a
> 2 year old kernel?!? :-)
That's what happens in the embedded space. It's the current version
from our distro vendor. It's also the version that all our different
board suppliers could agree to provide support for.
Of course, it's also a royal pain.
>> Unfortunately for me, ppc doesn't have a ".section" line in that macro,
>> so I'm at a bit of a loss.
> Just add the section. Should be trivial to do. You might have to add
> it to the linker script as well.
I've done the linker script part already. As for the processor.h bit,
does this seem reasonable? It seems to do the trick based on the
function addresses, but I may be missing something and I haven't
actually booted it yet.
The ppc64 version appends ',"a"' to the kprobes.text section line. Is
this needed here as well? Could someone elaborate on exactly what its
purpose is?
Thanks,
Chris
Index: linux-ias/include/asm-ppc/processor.h
===================================================================
--- linux-ias.orig/include/asm-ppc/processor.h
+++ linux-ias/include/asm-ppc/processor.h
@@ -38,6 +38,13 @@
#define _GLOBAL(n)\
.stabs __stringify(n:F-1),N_FUN,0,0,n;\
+ .section ".text"; \
+ .globl n;\
+n:
+
+#define _KPROBE(n)\
+ .stabs __stringify(n:F-1),N_FUN,0,0,n;\
+ .section ".kprobes.text","a"; \
.globl n;\
n:
^ permalink raw reply
* [PATCH 5/5] embedded6xx: Remove unnecessary loops_per_jiffy initialization code.
From: Jon Loeliger @ 2007-07-27 18:25 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/embedded6xx/holly.c | 12 ------------
arch/powerpc/platforms/embedded6xx/prpmc2800.c | 7 -------
2 files changed, 0 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/platforms/embedded6xx/holly.c b/arch/powerpc/platforms/embedded6xx/holly.c
index 6292e36..7662091 100644
--- a/arch/powerpc/platforms/embedded6xx/holly.c
+++ b/arch/powerpc/platforms/embedded6xx/holly.c
@@ -113,23 +113,11 @@ static void holly_remap_bridge(void)
static void __init holly_setup_arch(void)
{
- struct device_node *cpu;
struct device_node *np;
if (ppc_md.progress)
ppc_md.progress("holly_setup_arch():set_bridge", 0);
- cpu = of_find_node_by_type(NULL, "cpu");
- if (cpu) {
- const unsigned int *fp;
-
- fp = of_get_property(cpu, "clock-frequency", NULL);
- if (fp)
- loops_per_jiffy = *fp / HZ;
- else
- loops_per_jiffy = 50000000 / HZ;
- of_node_put(cpu);
- }
tsi108_csr_vir_base = get_vir_csrbase();
/* setup PCI host bridge */
diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
index 5342095..5467564 100644
--- a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
+++ b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
@@ -44,7 +44,6 @@ static void __init prpmc2800_setup_arch(void)
struct device_node *np;
phys_addr_t paddr;
const unsigned int *reg;
- const unsigned int *prop;
/*
* ioremap mpp and gpp registers in case they are later
@@ -62,12 +61,6 @@ static void __init prpmc2800_setup_arch(void)
of_node_put(np);
mv64x60_gpp_reg_base = ioremap(paddr, reg[1]);
- np = of_find_node_by_type(NULL, "cpu");
- prop = of_get_property(np, "clock-frequency", NULL);
- if (prop)
- loops_per_jiffy = *prop / HZ;
- of_node_put(np);
-
#ifdef CONFIG_PCI
mv64x60_pci_init();
#endif
--
1.5.0.3
^ permalink raw reply related
* [PATCH 4/5] 8xx: Remove unnecessary loops_per_jiffy initialization code.
From: Jon Loeliger @ 2007-07-27 18:24 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 14 --------------
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 14 --------------
2 files changed, 0 insertions(+), 28 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/mpc86xads_setup.c b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
index cf0e7bc..d881647 100644
--- a/arch/powerpc/platforms/8xx/mpc86xads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
@@ -254,20 +254,6 @@ int platform_device_skip(const char *model, int id)
static void __init mpc86xads_setup_arch(void)
{
- struct device_node *cpu;
-
- cpu = of_find_node_by_type(NULL, "cpu");
- if (cpu != 0) {
- const unsigned int *fp;
-
- fp = of_get_property(cpu, "clock-frequency", NULL);
- if (fp != 0)
- loops_per_jiffy = *fp / HZ;
- else
- loops_per_jiffy = 50000000 / HZ;
- of_node_put(cpu);
- }
-
cpm_reset();
mpc86xads_board_setup();
diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
index 5a808d6..bd5ff7a 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
@@ -406,20 +406,6 @@ int platform_device_skip(const char *model, int id)
static void __init mpc885ads_setup_arch(void)
{
- struct device_node *cpu;
-
- cpu = of_find_node_by_type(NULL, "cpu");
- if (cpu != 0) {
- const unsigned int *fp;
-
- fp = of_get_property(cpu, "clock-frequency", NULL);
- if (fp != 0)
- loops_per_jiffy = *fp / HZ;
- else
- loops_per_jiffy = 50000000 / HZ;
- of_node_put(cpu);
- }
-
cpm_reset();
mpc885ads_board_setup();
--
1.5.0.3
^ permalink raw reply related
* [PATCH 3/5] 52xx: Remove unnecessary loops_per_jiffy initialization code.
From: Jon Loeliger @ 2007-07-27 18:24 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/52xx/lite5200.c | 13 ++-----------
1 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/lite5200.c b/arch/powerpc/platforms/52xx/lite5200.c
index 5c46e89..84bd3da 100644
--- a/arch/powerpc/platforms/52xx/lite5200.c
+++ b/arch/powerpc/platforms/52xx/lite5200.c
@@ -109,22 +109,13 @@ static void lite5200_resume_finish(void __iomem *mbar)
static void __init lite5200_setup_arch(void)
{
+#ifdef CONFIG_PCI
struct device_node *np;
+#endif
if (ppc_md.progress)
ppc_md.progress("lite5200_setup_arch()", 0);
- np = of_find_node_by_type(NULL, "cpu");
- if (np) {
- const unsigned int *fp =
- of_get_property(np, "clock-frequency", NULL);
- if (fp != 0)
- loops_per_jiffy = *fp / HZ;
- else
- loops_per_jiffy = 50000000 / HZ;
- of_node_put(np);
- }
-
/* CPU & Port mux setup */
mpc52xx_setup_cpu(); /* Generic */
lite5200_setup_cpu(); /* Platorm specific */
--
1.5.0.3
^ permalink raw reply related
* [PATCH 2/5] 85xx: Remove unnecessary loops_per_jiffy initialization code.
From: Jon Loeliger @ 2007-07-27 18:24 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 13 -------------
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 13 -------------
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 11 -----------
3 files changed, 0 insertions(+), 37 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
index 40a8286..c22bc1c 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
@@ -192,7 +192,6 @@ void init_fcc_ioports(struct fs_platform_info *fpi)
static void __init mpc85xx_ads_setup_arch(void)
{
- struct device_node *cpu;
#ifdef CONFIG_PCI
struct device_node *np;
#endif
@@ -200,18 +199,6 @@ static void __init mpc85xx_ads_setup_arch(void)
if (ppc_md.progress)
ppc_md.progress("mpc85xx_ads_setup_arch()", 0);
- cpu = of_find_node_by_type(NULL, "cpu");
- if (cpu != 0) {
- const unsigned int *fp;
-
- fp = of_get_property(cpu, "clock-frequency", NULL);
- if (fp != 0)
- loops_per_jiffy = *fp / HZ;
- else
- loops_per_jiffy = 50000000 / HZ;
- of_node_put(cpu);
- }
-
#ifdef CONFIG_CPM2
cpm2_reset();
#endif
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
index 6a171e9..44f9cdb 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -266,7 +266,6 @@ device_initcall(mpc85xx_cds_8259_attach);
*/
static void __init mpc85xx_cds_setup_arch(void)
{
- struct device_node *cpu;
#ifdef CONFIG_PCI
struct device_node *np;
#endif
@@ -274,18 +273,6 @@ static void __init mpc85xx_cds_setup_arch(void)
if (ppc_md.progress)
ppc_md.progress("mpc85xx_cds_setup_arch()", 0);
- cpu = of_find_node_by_type(NULL, "cpu");
- if (cpu != 0) {
- const unsigned int *fp;
-
- fp = of_get_property(cpu, "clock-frequency", NULL);
- if (fp != 0)
- loops_per_jiffy = *fp / HZ;
- else
- loops_per_jiffy = 500000000 / HZ;
- of_node_put(cpu);
- }
-
cadmus = ioremap(CADMUS_BASE, CADMUS_SIZE);
cds_pci_slot = ((cadmus[CM_CSR] >> 6) & 0x3) + 1;
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index e8003bf..d0e3153 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -73,17 +73,6 @@ static void __init mpc85xx_mds_setup_arch(void)
if (ppc_md.progress)
ppc_md.progress("mpc85xx_mds_setup_arch()", 0);
- np = of_find_node_by_type(NULL, "cpu");
- if (np != NULL) {
- const unsigned int *fp =
- of_get_property(np, "clock-frequency", NULL);
- if (fp != NULL)
- loops_per_jiffy = *fp / HZ;
- else
- loops_per_jiffy = 50000000 / HZ;
- of_node_put(np);
- }
-
/* Map BCSR area */
np = of_find_node_by_name(NULL, "bcsr");
if (np != NULL) {
--
1.5.0.3
^ permalink raw reply related
* [PATCH 1/5] 86xx: Remove unnecessary loops_per_jiffy initialization code.
From: Jon Loeliger @ 2007-07-27 18:24 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Note -- This is a rebased version of an earlier patch
from July 17. That one can be dropped.
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 14 ++------------
1 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index e9eaa07..de90e6a 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -327,23 +327,13 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AL, 0x5249, early_uli5249);
static void __init
mpc86xx_hpcn_setup_arch(void)
{
+#ifdef CONFIG_PCI
struct device_node *np;
+#endif
if (ppc_md.progress)
ppc_md.progress("mpc86xx_hpcn_setup_arch()", 0);
- np = of_find_node_by_type(NULL, "cpu");
- if (np != 0) {
- const unsigned int *fp;
-
- fp = of_get_property(np, "clock-frequency", NULL);
- if (fp != 0)
- loops_per_jiffy = *fp / HZ;
- else
- loops_per_jiffy = 50000000 / HZ;
- of_node_put(np);
- }
-
#ifdef CONFIG_PCI
for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;) {
struct resource rsrc;
--
1.5.0.3
^ permalink raw reply related
* [PATCH 0/5] Remove unnecessary loops_per_jiffy initialization code
From: Jon Loeliger @ 2007-07-27 18:23 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
This patch series removes lingering jiffies initialization
code from several platforms. Note that the first patch in
this series for the 86xx has been rebased to current top of
Paul's repository and replaces an earlier version.
arch/powerpc/platforms/52xx/lite5200.c | 13 ++-----------
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 13 -------------
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 13 -------------
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 11 -----------
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 14 ++------------
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 14 --------------
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 14 --------------
arch/powerpc/platforms/embedded6xx/holly.c | 12 ------------
arch/powerpc/platforms/embedded6xx/prpmc2800.c | 7 -------
9 files changed, 4 insertions(+), 107 deletions(-)
^ permalink raw reply
* Re: a question about mpc8xx linux
From: Scott Wood @ 2007-07-27 17:56 UTC (permalink / raw)
To: Scott Wood; +Cc: poorbeyond, Linux-ppc mail list
In-Reply-To: <46AA3127.4060806@freescale.com>
Scott Wood wrote:
> poorbeyond wrote:
>
>>my cpu is MPC860, use u-boot-1.1.4, linux-2.6.20.14
>>
>>i use the "tftp 300000 uImage" command download kernel image,
>>
>>then use the "bootm 300000" command boot the image.
>
>
> You'll need either a device-tree-aware u-boot or 8xx cuImage support;
> you can get the latter from the patchset I posted recently.
Sorry, I missed that you're using arch/ppc rather than arch/powerpc.
arch/ppc doesn't require a device tree, though it would be good to
switch to arch/powerpc once my 8xx fixes go in -- arch/ppc is deprecated.
-Scott
^ permalink raw reply
* Re: a question about mpc8xx linux
From: Scott Wood @ 2007-07-27 17:53 UTC (permalink / raw)
To: poorbeyond; +Cc: Linux-ppc mail list
In-Reply-To: <200707272111187341027@163.com>
poorbeyond wrote:
> my cpu is MPC860, use u-boot-1.1.4, linux-2.6.20.14
>
> i use the "tftp 300000 uImage" command download kernel image,
>
> then use the "bootm 300000" command boot the image.
You'll need either a device-tree-aware u-boot or 8xx cuImage support;
you can get the latter from the patchset I posted recently.
> i found the bootm cmd entered the /arch/ppc/kernel/head_8xx.s, stop at the instruction "rfi".
> is it right? after the instruction, where does the code go normally ? what should i do now?
The rfi transfers control to start_here:
-Scott
^ permalink raw reply
* Re: pq2fads support...
From: Scott Wood @ 2007-07-27 17:45 UTC (permalink / raw)
To: Alexandros Kostopoulos; +Cc: linuxppc-dev
In-Reply-To: <op.tv4vfiaunhx3hy@phoenix>
Alexandros Kostopoulos wrote:
> Thanks for your reply, Scott,
>
> one question though: I am NOT using the bootwrapper, I'm instead
> feeding dtb and uImage directly to u-boot. This probably means that
> I should fill in lots of stuff manually into dts, right?
No, u-boot should fill in the same stuff. It may require the empty
fields to be there, though (it definitely requires it if you're using
the old, non-libfdt code -- if you are, you should also remove the
/chosen node, or else you'll get two of them).
> But, (and please forgive my ignorance) who does actually fill in
> stuff (like e.g. clock-frequency or bus-frequency), except, of
> course, from the trivial modifications u-boot does to dtb? The
> wrapper script seems to do nothing more that simply running dtc on
> dts.
In the bootwrapper case, it's the code in cuboot-pq2.c and devtree.c.
In the no-bootwrapper case, it's u-boot.
-Scott
^ permalink raw reply
* Re: pq2fads support...
From: Alexandros Kostopoulos @ 2007-07-27 17:12 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070727163529.GA26893@ld0162-tx32.am.freescale.net>
Thanks for your reply, Scott,
one question though: I am NOT using the bootwrapper, I'm instead feeding
dtb and uImage directly to u-boot. This probably means that I should fill
in lots of stuff manually into dts, right? But, (and please forgive my
ignorance) who does actually fill in stuff (like e.g. clock-frequency or
bus-frequency), except, of course, from the trivial modifications u-boot
does to dtb? The wrapper script seems to do nothing more that simply
running dtc on dts.
Thanks again
Alex
On Fri, 27 Jul 2007 19:35:29 +0300, Scott Wood <scottwood@freescale.com>
wrote:
> On Fri, Jul 27, 2007 at 03:24:08PM +0300, Alexandros Kostopoulos wrote:
>> In your patch for the pq2fads support, the device tree seems to be
>> missing
>> a memory node, for which dtc complains loudly. Is this board tested to
>> boot with these patches (because I'm now using this as a template for my
>> board - with your patchset applied to Paul's git)
>
> Sorry about that -- dtc complains about a lot of silly things, falsely
> assuming that the result is intended to be a complete tree ready for
> passing to Linux (which is rarely true). I'd been running with a patch
> to remove some of those checks, but it got rejected, and I forgot to
> stick the templates back into the dts.
>
> The next patchset will have a dts that works with current dtc; in the
> meantime, you can add the -f flag to dtc in arch/powerpc/boot/wrapper, or
> add the missing nodes based on the mpc8272ads device tree (the actual
> information will be filled in by the bootwrapper).
>
>> PS. What's about this new cpm-serial driver? is this supposed to be a
>> replacement for cpm_uart?
>
> No, it's a minimal driver for the bootwrapper.
>
> -Scott
^ permalink raw reply
* Re: [RFC][PATCH] MPC832x_RDB: update dts to use spi, register mmc_spi stub
From: Scott Wood @ 2007-07-27 16:40 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070727114559.GB11463@localhost.localdomain>
On Fri, Jul 27, 2007 at 03:45:59PM +0400, Anton Vorontsov wrote:
> Sure, technically nothing prevents this. But, QE specs names
> SPIs by these ids. Plus, from the kernel side spi name will be
> not pretty, it will be spi1216.1. Reg value making little sense
> to the userspace (or kernel-side SPI layer). Still want get
> rid of device-id?
Naming devices for human consumption is a more general problem than
device-id addresses; I'd like to see a standard "label" property added to
the device tree spec that software could use to present a human-friendly
label that corresponds to markings on the case, position on the board,
etc.
-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