* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Benjamin Herrenschmidt @ 2007-05-19 0:13 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linux-kernel, linuxppc-dev, Dave Liu, mingo, tglx
In-Reply-To: <51b3a75638604c9dd7ed60a10f0ed934@kernel.crashing.org>
On Sat, 2007-05-19 at 01:49 +0200, Segher Boessenkool wrote:
> > I find it extremely silly to implement it as edge anyway. The EE line
> > is
> > level triggered, and having a mix of edge and level on the same
> > exception without a clean way to retrigger the DEC one other than
> > waiting one tick is just causing trouble.
>
> It isn't edge triggered, it just automatically clears the
> decrementer exception condition at its source when taken
Which is exactly the same thing software-wise as edge triggered...
Ben.
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Segher Boessenkool @ 2007-05-19 0:17 UTC (permalink / raw)
To: Matt Sealey; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <464E3F18.5010700@genesi-usa.com>
> Linux doesn't but it might be nice to specify this kind of thing in a
> way that other operating systems might or may support.
>
> Essentially I think since there are a lot of ways to support I2C
> (including bitbanging a GPIO pair), the only real way to support it
> is to do something like;
>
> i2c@blah {
> name = "i2c"
> compatible = "mpc52xx-i2c,someother-i2c"
> regs = "address:range"
> }
Yes, all devices should be in the device tree. That's
what it's for.
> You're not ever going to be able to specify in the device tree
> exactly how to handle a driver, encompassing both implementation,
> bugs in revisions, quirks of board design, but you can specify
> for a driver a very accurate, very educated guess on it (any
> quirks, bugs or implementation differences would be board/chip
> specific, and are easily derived from the other device nodes
> like the cpu node, soc node, and so on)
Actually, you can, and should. All this information is
contained in the "compatible" and "model" properties.
"Quirks of board design" can be described too, on a case-
by-case basis.
All the knowledge about how to drive the device resides
in the kernel, but the device tree describes exactly what
device this is, so the kernel can match a driver to it
uniquely, and the driver can know exactly what revision
chip this is and what quirks to apply.
Segher
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Albert Cahalan @ 2007-05-19 1:45 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, tglx, linux-kernel
In-Reply-To: <464DBDBA.3060801@ru.mvista.com>
On 5/18/07, Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:
> Albert Cahalan wrote:
> >>> Sure, but is there any utility in registering more than the
> >>> decrementer on PPC?
>
> >> Not yet. I'm not sure I know any other PPC CPU facility fitting
> >> for clockevents. In theory, FIT could be used -- but its period
> >> is measured in powers of 2, IIRC.
>
> > I'd really like to have that as an option. It would allow oprofile
> > to safely use hardware events on the MPC74xx "G4" processors.
> > Alternately it would allow thermal events. It is safe to use at
> > most one of the three (decrementer,profiling,thermal) interrupts.
> > If two were to hit at the same time, badness happens.
>
> Unfortunately, FIT exists only on Book E CPUs and MPC74xx aren't Book E, IIUC.
By the name "FIT" perhaps, but MPC74xx has essentially
the same thing.
> > It's possible to wrapper the interrupt in something that divides
> > down, calling the normal code only some of the time. I think one
> > of the FIT choices is about 4 kHz on my system, which would be OK.
>
> Erm, are you sure you have FIT (or is your system not MPC74xx based)?
Set MMCR0[TBEE], set MMCR0[PMXE], and choose a TBL bit via MMCR0[TBSEL].
TBSEL is a 2-bit field which selects a timebase bit to use. The timebase
bits that can be chosen are numbered 15, 19, 23, and 31. In the notation
used by every other CPU vendor those would be bits 0, 8, 12, and 16.
Example: My system uses a TBL frequency of 24907667. This gives choices
of 12453833, 48648, 3040, and 190 Hz. The lowest three of those could
be useful, with 48648 only for profiling and extreme real-time.
It's also possible to trigger on the CPU cycle counter, but this would
cost one of the performance counters. MPC7400 has 4, later CPUs have 6
or more, and I think xPC7x0 had only 2. This method is a bit nicer,
since then one could trigger interrupts on arbitrary clock cycles
without needing to write the timebase register.
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Paul Mackerras @ 2007-05-19 3:33 UTC (permalink / raw)
To: Daniel Walker; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <1179502773.20519.56.camel@imap.mvista.com>
Daniel Walker writes:
> On Fri, 2007-05-18 at 19:06 +0400, Sergei Shtylyov wrote:
> > Well, the decrementer frequency may change, at least in theory (if the bus
> > clock changes).
>
> Does that happen very often?
If it did, gettimeofday would start reporting seriously wrong values,
since the timebase and the decrementer count at the same rate, and we
don't have any provision for fixing things up if that rate changed.
Fortunately there are no powerpc platforms where the rate is
variable.
Paul.
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Paul Mackerras @ 2007-05-19 3:34 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-kernel, linuxppc-dev, Dave Liu, tglx, mingo
In-Reply-To: <464DAD06.2060504@ru.mvista.com>
Sergei Shtylyov writes:
> Yeah, the classic decrementer is programmed off-by-one.
Actually it's programmed off by slightly less than one half on
average, but it doesn't matter since the error doesn't accumulate.
Paul.
^ permalink raw reply
* [PATCH] Add missing pmc_type fields in cpu_table
From: Anton Blanchard @ 2007-05-19 5:22 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
A number of cpu_table entries were missing the pmc_type field. Add them.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Candidate for stable.
Considering the number of places missed, I wonder if it makes sense for
the fallback case to be PPC_PMC_IBM.
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 9cb24d2..e054409 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -235,6 +235,7 @@ static struct cpu_spec cpu_specs[] = {
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
+ .pmc_type = PPC_PMC_IBM,
.cpu_setup = __setup_cpu_ppc970,
.cpu_restore = __restore_cpu_ppc970,
.oprofile_cpu_type = "ppc64/970MP",
@@ -251,6 +252,7 @@ static struct cpu_spec cpu_specs[] = {
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
+ .pmc_type = PPC_PMC_IBM,
.cpu_setup = __setup_cpu_ppc970MP,
.cpu_restore = __restore_cpu_ppc970,
.oprofile_cpu_type = "ppc64/970MP",
@@ -317,6 +320,7 @@ static struct cpu_spec cpu_specs[] = {
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 6,
+ .pmc_type = PPC_PMC_IBM,
.oprofile_cpu_type = "ppc64/power6",
.oprofile_type = PPC_OPROFILE_POWER4,
.oprofile_mmcra_sihv = POWER6_MMCRA_SIHV,
@@ -335,6 +339,7 @@ static struct cpu_spec cpu_specs[] = {
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 6,
+ .pmc_type = PPC_PMC_IBM,
.oprofile_cpu_type = "ppc64/power6",
.oprofile_type = PPC_OPROFILE_POWER4,
.oprofile_mmcra_sihv = POWER6_MMCRA_SIHV,
^ permalink raw reply related
* Simple Question about ML403 VGA (TFT) Controller
From: Mohammad Sadegh Sadri @ 2007-05-19 8:48 UTC (permalink / raw)
To: Linux PPC Linux PPC
Hi all
I have seen many linux 2.6 drivers for VGA controller for ML403 but I do no=
t know the answer to a very simple question about it,
How should I add the VGA controller module to my system in XPS?=20
The base system builder wizard ( EDK 9.1 SP! ) does not provide any option =
for this, and when I look at the IP repository I do not find any suitable m=
odules to be added to the design.
Thanks
_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx=
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Segher Boessenkool @ 2007-05-19 12:28 UTC (permalink / raw)
To: Albert Cahalan; +Cc: linuxppc-dev, tglx, linux-kernel
In-Reply-To: <787b0d920705181845h355eed4fk2bf93323332a9d90@mail.gmail.com>
>> Unfortunately, FIT exists only on Book E CPUs and MPC74xx aren't Book
>> E, IIUC.
>
> By the name "FIT" perhaps, but MPC74xx has essentially
> the same thing.
> Set MMCR0[TBEE], set MMCR0[PMXE], and choose a TBL bit via
> MMCR0[TBSEL].
That's the performance monitor, which could very well be
in use already (for performance monitoring stuff, who
would have guessed).
> It's also possible to trigger on the CPU cycle counter, but this would
> cost one of the performance counters. MPC7400 has 4, later CPUs have 6
> or more, and I think xPC7x0 had only 2.
7xx has at least four as well.
Segher
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Matt Sealey @ 2007-05-19 13:41 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <2087d135c4139e94e0b2c8826d808292@kernel.crashing.org>
Segher Boessenkool wrote:
>
> Yes, all devices should be in the device tree. That's
> what it's for.
>
>> You're not ever going to be able to specify in the device tree
>> exactly how to handle a driver, encompassing both implementation,
>> bugs in revisions, quirks of board design, but you can specify
>> for a driver a very accurate, very educated guess on it (any
>> quirks, bugs or implementation differences would be board/chip
>> specific, and are easily derived from the other device nodes
>> like the cpu node, soc node, and so on)
>
> Actually, you can, and should. All this information is
> contained in the "compatible" and "model" properties.
> "Quirks of board design" can be described too, on a case-
> by-case basis.
>
> All the knowledge about how to drive the device resides
> in the kernel, but the device tree describes exactly what
> device this is, so the kernel can match a driver to it
> uniquely, and the driver can know exactly what revision
> chip this is and what quirks to apply.
That's what I said wasn't it?
If you have a buggy i2c controller or one that has a strange
quirk, but it's present as fsl-i2c in those device trees,
would you specify that it is fsl-i2c-less-bugs later?
Would you add property after property to describe errata,
quirks in the nodes themselves?
I don't see the point in that, when such information is
nearly always derivable from other parts of the device
tree. An ATA node does not contain the timings for devices
on that bus. The driver usually has to work that out. If
there is a quirk to be implemented, this will be described
by the PVR/SVR and other system information already in the
device tree. The clock distribution module in the MPC52xx
changed some bit settings between the original and B versions,
I don't see any benefit in having a property or a name
change (from mpc5200-cdm or so in this example) when the
differences are well documented and also easy to work out
from the device tree without additional properties, or
name changes. If the register location changes, the register
property handles it. If the operation changes this is defined
by both the soc svr, possibly a board model, and also
possibly by the pvr (cache sizes etc.).
I'll take an example of putting useless information in
the device tree - how about the CPU node? It has all the
information for cache sizes etc. but does Linux use it?
No.. the only ONLY chip I have seen this information be
relevant on is the MPC7447/MPC7457 where it is impossible
to determine by PVR which chip you have, and even then
impossible to determine the L3 cache size. And Linux
does not even handle this; the firmware sets it up and
the L3 registers are already there for Linux to pick up
on.
This is what I mean by 'describing exactly what the device
is' being rather a tedious and time-wasting concept.
I might be a little less noisy about it if there was
some kind of edict for devices never to wander outside
of their own node in the device tree, but there isn't.
You have the entire board description available and when
that information doesn't exist, it is usually in the
chip or board itself.
I don't think the device tree has much use beyond the
advertisement and authorisation of use of system devices,
and as the most basic and essential automatic driver
processes (probe and initialisation). It is quite another
matter to make it a kind of Linux-programmers errata
replacement framework and artificially recreate already
easily-accessible information.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: Fixed PHY problems
From: Hammond Christian-r55079 @ 2007-05-19 14:42 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 463 bytes --]
Hi Vitaly,
I was pointed in the direction of message chain "Fixed PHY problems" for
interfacing a fixed PHY to a 83xx UEC. Could you please forward on the
patch you mentioned in the trail?
Any ideas if the implementation succeeded in the end?
Christian Hammond
NCSG Applications Engineer
Tel: +44 1355 355962
Fax: +44 1355 261790
Freescale Semiconductor
Kelvin Industrial Estate
East Kilbride
Glasgow G75 0TG
United Kingdom
[-- Attachment #2: Type: text/html, Size: 1952 bytes --]
^ permalink raw reply
* Re: gcc-4.2.0 breakage on powerpc?
From: Segher Boessenkool @ 2007-05-19 16:11 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev list, Mikael Pettersson, lkml Mailing List
In-Reply-To: <023132a5c5a4f07ec2d46b0515a55d4b@kernel.crashing.org>
>>>> and we'll end up
>>>> having major kernel releases which don't build on i386 with major
>>>> gcc
>>>> releases, which isn't altogether desirable.
>>>
>>> Yeah, like 4.2.0 with powerpc. Seems like no one tested it :-(
>>
>> Details please. What exactly are the gcc-4.2.0 problems on powerpc?
>
> http://gcc.gnu.org/PR31490 . Most stuff using named
> sections won't build; that includes CONFIG_MODULES.
> There is no viable workaround. The problem is being
> handled. I'll post a patch for the kernel refusing
> to build with this combination soon.
[Cc:ing the PowerPC list]
Oh btw, most likely this is a problem on 64-bit only.
Segher
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Segher Boessenkool @ 2007-05-19 16:25 UTC (permalink / raw)
To: Matt Sealey; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <464EFE96.3000801@genesi-usa.com>
>> Actually, you can, and should. All this information is
>> contained in the "compatible" and "model" properties.
>> "Quirks of board design" can be described too, on a case-
>> by-case basis.
>>
>> All the knowledge about how to drive the device resides
>> in the kernel, but the device tree describes exactly what
>> device this is, so the kernel can match a driver to it
>> uniquely, and the driver can know exactly what revision
>> chip this is and what quirks to apply.
>
> That's what I said wasn't it?
Not at all, no.
> If you have a buggy i2c controller or one that has a strange
> quirk, but it's present as fsl-i2c in those device trees,
> would you specify that it is fsl-i2c-less-bugs later?
> Would you add property after property to describe errata,
> quirks in the nodes themselves?
No. All this can be easily derived from the "model"
properties in the relevant nodes.
> I'll take an example of putting useless information in
> the device tree - how about the CPU node? It has all the
> information for cache sizes etc. but does Linux use it?
It *should* use it though. But it cannot really do that,
since many/most device trees are broken in this respect.
Linux *does* use some of the "cpu" properties though.
Maybe in the future it will use more.
> This is what I mean by 'describing exactly what the device
> is' being rather a tedious and time-wasting concept.
This is equivalent to stating the device tree is a useless
concept. You are free to your opinion of course.
> I might be a little less noisy about it if there was
> some kind of edict for devices never to wander outside
> of their own node in the device tree, but there isn't.
I'm not sure what you mean here. It is best practice
for device nodes to be reasonably self-contained though.
Of course not completely; every node always has to refer
to its parent bus, etc. Device drivers will sometimes
have to refer to board model for board-specific workarounds.
> I don't think the device tree has much use beyond the
> advertisement and authorisation of use of system devices,
> and as the most basic and essential automatic driver
> processes (probe and initialisation).
Again, you are free to your own opinion.
> It is quite another
> matter to make it a kind of Linux-programmers errata
> replacement framework and artificially recreate already
> easily-accessible information.
No one is proposing that I hope. This information indeed
is already easily available in most cases -- namely, in
the device tree.
Segher
^ permalink raw reply
* [PATCH 2/2] powerpc: Refuse to build 64-bit with GCC-4.2.0 and CONFIG_MODULES
From: Segher Boessenkool @ 2007-05-19 16:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sam
In-Reply-To: <f7ff5aadda1b2962d6c45123ff944e9af6879306.1179593209.git.segher@kernel.crashing.org>
...since this won't work (compiler bug, see <http://gcc.gnu.org/PR31490>).
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
---
arch/powerpc/Makefile | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 6238b58..1447c83 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -202,6 +202,14 @@ checkbin:
false; \
fi ; \
fi
+ @if test "$(call cc-fullversion)" = "040200" \
+ && test "x${CONFIG_MODULES}${CONFIG_PPC64}" = "xyy" ; then \
+ echo -n '*** GCC-4.2.0 cannot compile the 64-bit powerpc ' ; \
+ echo 'kernel with modules enabled.' ; \
+ echo -n '*** Please use a different GCC version or ' ; \
+ echo 'disable kernel modules' ; \
+ false ; \
+ fi
@if ! /bin/echo dssall | $(AS) -many -o $(TOUT) >/dev/null 2>&1 ; then \
echo -n '*** ${VERSION}.${PATCHLEVEL} kernels no longer build ' ; \
echo 'correctly with old versions of binutils.' ; \
--
1.5.2.rc0.g4342-dirty
^ permalink raw reply related
* [PATCH 1/2] kbuild: New 'cc-fullversion' macro
From: Segher Boessenkool @ 2007-05-19 16:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sam
Prints a six-digit string including the GCC patchlevel. Also fix
the 'usage' comment for cc-version.
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
---
scripts/Kbuild.include | 7 ++++++-
scripts/gcc-version.sh | 15 ++++++++++++---
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 06c1a37..677bc6c 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -100,9 +100,14 @@ cc-option-align = $(subst -functions=0,,\
$(call cc-option,-falign-functions=0,-malign-functions=0))
# cc-version
-# Usage gcc-ver := $(call cc-version,$(CC))
+# Usage gcc-ver := $(call cc-version)
cc-version = $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-version.sh $(CC))
+# cc-fullversion
+# Usage gcc-ver := $(call cc-fullversion)
+cc-fullversion = $(shell $(CONFIG_SHELL) \
+ $(srctree)/scripts/gcc-version.sh -p $(CC))
+
# cc-ifversion
# Usage: EXTRA_CFLAGS += $(call cc-ifversion, -lt, 0402, -O1)
cc-ifversion = $(shell [ $(call cc-version, $(CC)) $(1) $(2) ] && echo $(3))
diff --git a/scripts/gcc-version.sh b/scripts/gcc-version.sh
index bb4fbea..8a1d187 100644
--- a/scripts/gcc-version.sh
+++ b/scripts/gcc-version.sh
@@ -1,14 +1,23 @@
#!/bin/sh
#
-# gcc-version gcc-command
+# gcc-version [-p] gcc-command
#
# Prints the gcc version of `gcc-command' in a canonical 4-digit form
# such as `0295' for gcc-2.95, `0303' for gcc-3.3, etc.
#
+# With the -p option, prints the patchlevel as well, for example `029503' for
+# gcc-2.95.3, `030301' for gcc-3.3.1, etc.
+#
+
+if [ $1 = "-p" ] ; then with_patchlevel=1; shift; fi
compiler="$*"
MAJOR=$(echo __GNUC__ | $compiler -E -xc - | tail -n 1)
MINOR=$(echo __GNUC_MINOR__ | $compiler -E -xc - | tail -n 1)
-printf "%02d%02d\\n" $MAJOR $MINOR
-
+if [ "x$with_patchlevel" != "x" ] ; then
+ PATCHLEVEL=$(echo __GNUC_PATCHLEVEL__ | $compiler -E -xc - | tail -n 1)
+ printf "%02d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
+else
+ printf "%02d%02d\\n" $MAJOR $MINOR
+fi
--
1.5.2.rc0.g4342-dirty
^ permalink raw reply related
* [PATCH] MMCR0_PMA0 != MMCR0_PMAO
From: Anton Blanchard @ 2007-05-19 17:13 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
pmc.c has:
#ifndef MMCR0_PMA0
#define MMCR0_PMA0 0
This one took a while to find. Unfortunately its the wrong define
(number 0 vs letter O). Its probably worth removing this override, since
if our includes get screwed up we will have the same (hard to debug)
failure.
Fix it simply for now, so that we can backport to stable.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Candidate for stable.
Index: kernel/arch/powerpc/kernel/pmc.c
===================================================================
--- kernel.orig/arch/powerpc/kernel/pmc.c 2007-05-19 11:57:57.000000000 -0500
+++ kernel/arch/powerpc/kernel/pmc.c 2007-05-19 11:58:32.000000000 -0500
@@ -20,8 +20,8 @@
#include <asm/cputable.h>
#include <asm/pmc.h>
-#ifndef MMCR0_PMA0
-#define MMCR0_PMA0 0
+#ifndef MMCR0_PMAO
+#define MMCR0_PMAO 0
#endif
static void dummy_perf(struct pt_regs *regs)
@@ -30,7 +30,7 @@ static void dummy_perf(struct pt_regs *r
mtpmr(PMRN_PMGC0, mfpmr(PMRN_PMGC0) & ~PMGC0_PMIE);
#elif defined(CONFIG_PPC64) || defined(CONFIG_6xx)
if (cur_cpu_spec->pmc_type == PPC_PMC_IBM)
- mtspr(SPRN_MMCR0, mfspr(SPRN_MMCR0) & ~(MMCR0_PMXE|MMCR0_PMA0));
+ mtspr(SPRN_MMCR0, mfspr(SPRN_MMCR0) & ~(MMCR0_PMXE|MMCR0_PMAO));
#else
mtspr(SPRN_MMCR0, mfspr(SPRN_MMCR0) & ~MMCR0_PMXE);
#endif
^ permalink raw reply
* Re: gcc-4.2.0 breakage on powerpc?
From: Mikael Pettersson @ 2007-05-19 17:28 UTC (permalink / raw)
To: segher; +Cc: linuxppc-dev, mikpe, linux-kernel
On Sat, 19 May 2007 18:11:20 +0200, Segher Boessenkool wrote:
> >>>> and we'll end up
> >>>> having major kernel releases which don't build on i386 with major
> >>>> gcc
> >>>> releases, which isn't altogether desirable.
> >>>
> >>> Yeah, like 4.2.0 with powerpc. Seems like no one tested it :-(
> >>
> >> Details please. What exactly are the gcc-4.2.0 problems on powerpc?
> >
> > http://gcc.gnu.org/PR31490 . Most stuff using named
> > sections won't build; that includes CONFIG_MODULES.
> > There is no viable workaround. The problem is being
> > handled. I'll post a patch for the kernel refusing
> > to build with this combination soon.
>
> [Cc:ing the PowerPC list]
>
> Oh btw, most likely this is a problem on 64-bit only.
I believe so too. PR31490 mostly talks about ppc64,
and I've built both ppc32 kernels and complex ppc32
user-space programs with gcc-4.2.0 without noticing
any regressions.
/Mikael
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Albert Cahalan @ 2007-05-19 18:22 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, tglx, linux-kernel
In-Reply-To: <fa84736ae121902d4bee24eb23ca1d0b@kernel.crashing.org>
On 5/19/07, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> [Albert Cahalan]
> > Set MMCR0[TBEE], set MMCR0[PMXE], and choose a TBL bit via
> > MMCR0[TBSEL].
>
> That's the performance monitor, which could very well be
> in use already (for performance monitoring stuff, who
> would have guessed).
It is the performance monitor, which sadly can not be used
very well unless the decrementer is disabled. The hardware
is buggy. As long as we use the decrementer for timekeeping,
we can not safely generate performance monitor interrupts.
I'd like to have the performance monitor available. It's NOT
available unless we use part of it for timekeeping. That's the
choice the hardware gives us.
We can get TBL bit flip interrupts for free. We don't even need
to give up one of the event counters. If we do give up one of the
event counters (a rather reasonable idea), then we can count
one of those TBL bit flips or the cycle counter.
^ permalink raw reply
* BUG: sleeping function called from invalid context at kernel/rwsem.c
From: Christian Kujau @ 2007-05-19 18:51 UTC (permalink / raw)
To: linuxppc-dev
Hi list,
I'm tracking vanilla 2.6-git on this iBook/G4 and sometimes, when
closing the lid to put it to sleep and opening again to wake it up, the
kernel barfs with:
[10606.436379] BUG: sleeping function called from invalid context at kernel/rwsem.c:20
[10606.436393] in_atomic():1, irqs_disabled():1
[10606.436399] Call Trace:
[10606.436405] [e79c9d10] [c0008d00] show_stack+0x3c/0x194 (unreliable)
[10606.436436] [e79c9d40] [c0027b28] __might_sleep+0xd4/0xe8
[10606.436463] [e79c9d50] [c00484b4] down_read+0x24/0x5c
[10606.436484] [e79c9d70] [c003ccec] __blocking_notifier_call_chain+0x38/0x74
[10606.436502] [e79c9d90] [c0167664] fb_notifier_call_chain+0x24/0x34
[10606.436531] [e79c9da0] [c0167cbc] fb_set_suspend+0x58/0x6c
[10606.436544] [e79c9dc0] [c0194968] radeonfb_pci_resume+0x1fc/0x3e8
[10606.436572] [e79c9de0] [c0194b78] radeonfb_early_resume+0x24/0x40
[10606.436585] [e79c9e00] [c001ac54] pmac_call_early_video_resume+0x2c/0x3c
[10606.436607] [e79c9e10] [c01f63dc] pmu_ioctl+0x7f8/0xc24
[10606.436629] [e79c9eb0] [c00924a0] do_ioctl+0x9c/0xa8
[10606.436645] [e79c9ed0] [c0092530] vfs_ioctl+0x84/0x490
[10606.436656] [e79c9f10] [c009297c] sys_ioctl+0x40/0x74
[10606.436668] [e79c9f40] [c0011930] ret_from_syscall+0x0/0x38
[10606.436690] --- Exception: c01 at 0xfee32a8
[10606.436722] LR = 0xfee3240
This happened with 2.6.22-rc1 but has happened with 2.6.22-rc1-git7
(reproduced just now). However, the suspend works and so does waking up.
I just wonder if I should be worried by this message.
Please finde more details and config here:
http://nerdbynature.de/bits/2.6.2x-powerpc/
Oh, speaking of "messages to worry about": lockdep says:
"142 out of 218 testcases failed, as expected." ...why is this
"expected"?
Thanks,
Christian.
--
BOFH excuse #297:
Too many interrupts
^ permalink raw reply
* [PATCH] power-management elements for 603e/fsl (version 2)
From: Guennadi Liakhovetski @ 2007-05-19 19:22 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Johannes Berg, Paul Mackerras
Hi all
Below is the second version of the standby patch for ppc linkstation
systems, which also introduces suspend / resume methods for Freescale
CPUs. It is now based on a recent (post .22-rc1) powerpc.git snapshot, and
it depends on the "don't link timer.o for powerpc systems using generic
rtc" patch (sorry, didn't cc maintainers on that one)
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036319.html. Also
addressed comments from Johannes Berg. Please, consider for inclusion.
Paul, sorry, I called it standby, if you don't mind... Somehow I don't
quite feel like calling this STR.
Thanks
Guennadi
---
Guennadi Liakhovetski
linkstation: implement standby for linkstation ppc.
We put the PCI bus and the core to SLEEP and wait for a button to be
pressed for wake up. Requires
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036319.html as we use
generic rtc and its suspend/resume code. Note: PM is not enabled by
default in linkstation_defconfig.
Signed-off-by: G. Liakhovetski <g.liakhovetski@gmx.de>
diff --git a/arch/powerpc/platforms/embedded6xx/linkstation.c b/arch/powerpc/platforms/embedded6xx/linkstation.c
index b412f00..a37ae97 100644
--- a/arch/powerpc/platforms/embedded6xx/linkstation.c
+++ b/arch/powerpc/platforms/embedded6xx/linkstation.c
@@ -11,15 +11,15 @@
*/
#include <linux/kernel.h>
-#include <linux/pci.h>
#include <linux/initrd.h>
#include <linux/mtd/physmap.h>
+#include <linux/serial_reg.h>
+#include <sysdev/fsl_soc.h>
#include <asm/time.h>
#include <asm/prom.h>
#include <asm/mpic.h>
#include <asm/mpc10x.h>
-#include <asm/pci-bridge.h>
static struct mtd_partition linkstation_physmap_partitions[] = {
{
@@ -134,6 +134,7 @@ static void __init linkstation_init_IRQ(void)
extern void avr_uart_configure(void);
extern void avr_uart_send(const char);
+extern int avr_uart_ier_swap(const char, char *);
static void linkstation_restart(char *cmd)
{
@@ -197,3 +198,73 @@ define_machine(linkstation){
.halt = linkstation_halt,
.calibrate_decr = generic_calibrate_decr,
};
+
+#ifdef CONFIG_PM
+
+static int ls_pm_valid(suspend_state_t state)
+{
+ switch (state) {
+ case PM_SUSPEND_STANDBY:
+ return 1;
+ default:
+ return 0;
+ }
+}
+
+static int ls_pm_enter(suspend_state_t state)
+{
+ char ier;
+ int ret = 0;
+ u64 tb;
+
+ /* Stop preemption */
+ preempt_disable();
+
+ if ((ret = fsl_suspend(state)) < 0) {
+ preempt_enable();
+ return ret;
+ }
+
+ local_irq_disable();
+
+ avr_uart_configure();
+ ret = avr_uart_ier_swap(UART_IER_RDI | UART_IER_RLSI/* | UART_IER_THRI*/, &ier);
+ if (ret < 0)
+ goto fail;
+
+ /* Get timebase */
+ tb = get_tb();
+
+ /* go zzzzz... (re-enabling interrupts) */
+ fsl_low_sleep();
+
+ local_irq_disable();
+
+ set_tb(tb >> 32, tb & 0xfffffffful);
+
+ (void)avr_uart_ier_swap(ier, NULL);
+fail:
+
+ /* Re-enable local CPU interrupts */
+ local_irq_enable();
+
+ preempt_enable();
+
+ fsl_resume(state);
+
+ return ret;
+}
+
+static struct pm_ops ls_pm_ops = {
+ .valid = ls_pm_valid,
+ .enter = ls_pm_enter,
+};
+
+static int __init ls_pm_init(void)
+{
+ pm_set_ops(&ls_pm_ops);
+ return 0;
+}
+
+device_initcall(ls_pm_init);
+#endif
diff --git a/arch/powerpc/platforms/embedded6xx/ls_uart.c b/arch/powerpc/platforms/embedded6xx/ls_uart.c
index d0bee9f..b1086e9 100644
--- a/arch/powerpc/platforms/embedded6xx/ls_uart.c
+++ b/arch/powerpc/platforms/embedded6xx/ls_uart.c
@@ -1,3 +1,14 @@
+/*
+ * AVR power-management chip interface for the Buffalo Linkstation /
+ * Kurobox Platform.
+ *
+ * Author: 2006 (c) G. Liakhovetski
+ * g.liakhovetski@gmx.de
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of
+ * any kind, whether express or implied.
+ */
#include <linux/workqueue.h>
#include <linux/string.h>
#include <linux/delay.h>
@@ -11,6 +22,7 @@
static void __iomem *avr_addr;
static unsigned long avr_clock;
+static unsigned int avr_virq;
static struct work_struct wd_work;
@@ -42,6 +54,37 @@ static void wd_stop(struct work_struct *unused)
printk("\n");
}
+static irqreturn_t avr_handler(int irq, void *id)
+{
+ (void) in_8(avr_addr + UART_LSR);
+ (void) in_8(avr_addr + UART_RX);
+ (void) in_8(avr_addr + UART_IIR);
+ (void) in_8(avr_addr + UART_MSR);
+
+ return IRQ_HANDLED;
+}
+
+int avr_uart_ier_swap(const char new, char *old)
+{
+ int ret = 0;
+
+ if (!avr_addr || !avr_clock || avr_virq == NO_IRQ)
+ return -EIO;
+
+ if (old)
+ ret = request_irq(avr_virq, avr_handler, 0, "avr_wakeup", NULL);
+ else
+ free_irq(avr_virq, NULL);
+
+ if (ret >= 0) {
+ if (old)
+ *old = in_8(avr_addr + UART_IER);
+ out_8(avr_addr + UART_IER, new);
+ }
+
+ return ret;
+}
+
#define AVR_QUOT(clock) ((clock) + 8 * 9600) / (16 * 9600)
void avr_uart_configure(void)
@@ -104,7 +147,7 @@ static int __init ls_uarts_init(void)
{
struct device_node *avr;
phys_addr_t phys_addr;
- int len;
+ int len, irq;
avr = of_find_node_by_path("/soc10x/serial@80004500");
if (!avr)
@@ -112,10 +155,15 @@ static int __init ls_uarts_init(void)
avr_clock = *(u32*)of_get_property(avr, "clock-frequency", &len);
phys_addr = ((u32*)of_get_property(avr, "reg", &len))[0];
+ irq = ((u32*)get_property(avr, "interrupts", &len))[0];
if (!avr_clock || !phys_addr)
return -EINVAL;
+ avr_virq = irq_find_mapping(NULL, irq);
+ if (avr_virq == NO_IRQ)
+ return -EIO;
+
avr_addr = ioremap(phys_addr, 32);
if (!avr_addr)
return -EFAULT;
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index c3ce0bd..745c6f6 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -13,6 +13,9 @@ obj-$(CONFIG_PPC_PMI) += pmi.o
obj-$(CONFIG_U3_DART) += dart_iommu.o
obj-$(CONFIG_MMIO_NVRAM) += mmio_nvram.o
obj-$(CONFIG_FSL_SOC) += fsl_soc.o
+ifeq ($(CONFIG_PM),y)
+obj-$(CONFIG_FSL_SOC) += fsl_pm.o
+endif
obj-$(CONFIG_FSL_PCIE) += fsl_pcie.o
obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index cad1757..9588b60 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -1103,3 +1103,65 @@ err:
arch_initcall(cpm_smc_uart_of_init);
#endif /* CONFIG_8xx */
+
+#ifdef CONFIG_PM
+#include <linux/pci.h>
+#include <asm/pci-bridge.h>
+
+#define MPC10X_LP_REF_EN (1<<12)
+#define MPC10X_PM (1<<7)
+#define MPC10X_DOZE (1<<5)
+#define MPC10X_NAP (1<<4)
+#define MPC10X_SLEEP (1<<3)
+
+int fsl_suspend(suspend_state_t state)
+{
+ struct pci_dev *bridge;
+ unsigned long flags;
+ u16 pmcr1;
+
+ bridge = pci_find_slot(0, 0);
+ if (!bridge)
+ return -ENODEV;
+
+ pci_read_config_word(bridge, 0x70, &pmcr1);
+ local_irq_save(flags);
+ /* Apparently, MacOS uses NAP mode for Grackle ??? */
+ pmcr1 &= ~(MPC10X_DOZE | MPC10X_NAP);
+ pmcr1 |= MPC10X_PM | MPC10X_SLEEP | MPC10X_LP_REF_EN;
+ pci_write_config_word(bridge, 0x70, pmcr1);
+ local_irq_restore(flags);
+
+ /* Make sure the decrementer won't interrupt us */
+ asm volatile("mtdec %0" : : "r" (0x7fffffff));
+ /* Make sure any pending DEC interrupt occurring while we did
+ * the above didn't re-enable the DEC */
+ mb();
+ asm volatile("mtdec %0" : : "r" (0x7fffffff)); /* 8 seconds */
+
+ return 0;
+}
+
+int fsl_resume(suspend_state_t state)
+{
+ struct pci_dev *bridge;
+ unsigned long flags;
+ u16 pmcr1;
+
+ bridge = pci_find_slot(0, 0);
+ if (!bridge)
+ return -ENODEV;
+
+ local_irq_save(flags);
+ /* We're awake again, stop grackle PM */
+ pci_read_config_word(bridge, 0x70, &pmcr1);
+ pmcr1 &= ~(MPC10X_PM | MPC10X_DOZE | MPC10X_SLEEP | MPC10X_NAP | MPC10X_LP_REF_EN);
+ pci_write_config_word(bridge, 0x70, pmcr1);
+ local_irq_restore(flags);
+
+ /* Restart jiffies & scheduling */
+ wakeup_decrementer();
+
+ return 0;
+}
+#endif
diff --git a/arch/powerpc/sysdev/fsl_soc.h b/arch/powerpc/sysdev/fsl_soc.h
index 04e145b..9853913 100644
--- a/arch/powerpc/sysdev/fsl_soc.h
+++ b/arch/powerpc/sysdev/fsl_soc.h
@@ -8,5 +8,12 @@ extern phys_addr_t get_immrbase(void);
extern u32 get_brgfreq(void);
extern u32 get_baudrate(void);
+#ifdef CONFIG_PM
+#include <linux/pm.h>
+extern int fsl_suspend(suspend_state_t state);
+extern int fsl_resume(suspend_state_t state);
+extern void fsl_low_sleep(void);
+#endif
+
#endif
#endif
diff -u /dev/null b/arch/powerpc/sysdev/fsl_pm.S
--- /dev/null 2005-08-21 16:20:22.000000000 +0200
+++ b/arch/powerpc/sysdev/fsl_pm.S 2007-05-18 19:34:22.000000000 +0200
@@ -0,0 +1,19 @@
+#include <asm/reg.h>
+#include <asm/ppc_asm.h>
+
+_GLOBAL(fsl_low_sleep)
+ isync /* Set the HID0 and MSR for sleep. */
+ mfspr r3,SPRN_HID0
+ rlwinm r3,r3,0,10,7 /* clear doze, nap */
+ oris r3,r3,HID0_SLEEP@h /* r3 |= HID0_SLEEP & (0xffff << 16) */
+ sync
+ isync
+ mtspr SPRN_HID0,r3
+ sync
+ mfmsr r3
+ ori r3,r3,MSR_EE /* Enable interrupts to wake us up */
+ oris r3,r3,MSR_POW@h
+ sync
+ mtmsr r3
+ isync
+ blr
^ permalink raw reply related
* Badness at drivers/base/core.c
From: Christian Kujau @ 2007-05-19 20:19 UTC (permalink / raw)
To: linuxppc-dev
Hi again,
tracking 2.6-git is fun, here's what I get when I do rmmod(8) on a
loaded module:
[14240.857547] Device 'windfarm.0' does not have a release() function,
it is broken and must be fixed.
[14240.857647] ------------[ cut here ]------------
[14240.857659] Badness at drivers/base/core.c:107
[14240.857669] Call Trace:
[14240.857676] [eea5fd20] [c0008d00] show_stack+0x3c/0x194 (unreliable)
[14240.857705] [eea5fd50] [c0142764] report_bug+0x84/0xf4
[14240.857722] [eea5fd60] [c0010280] program_check_exception+0xbc/0x530
[14240.857742] [eea5fd90] [c0011f8c] ret_from_except_full+0x0/0x4c
[14240.857757] --- Exception: 700 at device_release+0x80/0x88
[14240.857784] LR = device_release+0x80/0x88
[14240.857791] [eea5fe60] [c0143a24] kobject_cleanup+0x70/0xac
[14240.857806] [eea5fe80] [c0144b20] kref_put+0x54/0x6c
[14240.857820] [eea5fe90] [c01439a4] kobject_put+0x24/0x34
[14240.857833] [eea5fea0] [c01df3b8] put_device+0x1c/0x2c
[14240.857848] [eea5feb0] [c01e513c] platform_device_put+0x1c/0x2c
[14240.857868] [eea5fec0] [f2143d30] windfarm_core_exit+0x2c/0x70c [windfarm_core]
[14240.857893] [eea5fed0] [c0053450] sys_delete_module+0x19c/0x200
[14240.857910] [eea5ff40] [c0011930] ret_from_syscall+0x0/0x38
[14240.857923] --- Exception: c01 at 0xff783d8
[14240.857951] LR = 0x10001424
This one is for windfarm_core @ 2.6.22-rc1-git7. However this seems to
happen for *some* (but not all) other modules as well, I've seen this on
the same iBook/G4 for the kafs module @ 2.6.20-15-powerpc (ubuntu):
[ 1941.063663] kAFS: Red Hat AFS client v0.1 registering.
[ 1941.064601] kAFS: Started kafstimod 11857
[ 1941.064923] kAFS: Started kafsasyncd 11858
[ 1941.065234] <== afs_fs_init() = 0
[ 1945.170279] kAFS: Red Hat AFS client v0.1 unregistering.
[ 1945.171269] ------------[ cut here ]------------
[ 1945.172065] Badness at fs/proc/generic.c:732
[ 1945.172820] Call Trace:
[ 1945.172824] [CF5C9D20] [C0008BB0] show_stack+0x3c/0x194 (unreliable)
[ 1945.172844] [CF5C9D50] [C0110400] report_bug+0x84/0xf4
[ 1945.172855] [CF5C9D60] [C0011ED4] program_check_exception+0xd4/0x520
[ 1945.172869] [CF5C9DB0] [C0013B4C] ret_from_except_full+0x0/0x4c
[ 1945.172878] --- Exception: 700 at remove_proc_entry+0xec/0x1b0
[ 1945.172892] LR = remove_proc_entry+0x68/0x1b0
[ 1945.172896] [CF5C9EB0] [F2655074] afs_proc_cleanup+0x30/0x40 [kafs]
[ 1945.172926] [CF5C9EC0] [F2659290] afs_exit+0x38/0x48 [kafs]
[ 1945.172935] [CF5C9ED0] [C00517F4] sys_delete_module+0x190/0x1f4
[ 1945.172946] [CF5C9F40] [C00134F0] ret_from_syscall+0x0/0x38
[ 1945.172952] --- Exception: c01 at 0xff783d8
[ 1945.172980] LR = 0x10001424
However, the module unloads and loads again just fine, machine seems to
be stable. To be honest, I don't really care because I hardly ever use
rmmod(8) and I just stumbled over these messages when playing around
with bcm43xx. I just want to let you know...
details and .config: http://nerdbynature.de/bits/2.6.2x-powerpc/
thanks,
Christian.
--
BOFH excuse #64:
CPU needs recalibration
^ permalink raw reply
* Re: Simple Question about ML403 VGA (TFT) Controller
From: Grant Likely @ 2007-05-19 22:56 UTC (permalink / raw)
To: Mohammad Sadegh Sadri; +Cc: Linux PPC Linux PPC
In-Reply-To: <BAY115-W21F59EB26847913D2C56FB2310@phx.gbl>
On 5/19/07, Mohammad Sadegh Sadri <mamsadegh@hotmail.com> wrote:
> How should I add the VGA controller module to my system in XPS?
>
> The base system builder wizard ( EDK 9.1 SP! ) does not provide any option for this, and when I look at the IP repository I do not find any suitable modules to be added to the design.
The VGA controller is not supported by Base system builder. If you
want to add it to your own design, you need to extract the files from
the ml403 reference design and add them manually to your project.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Daniel Walker @ 2007-05-20 2:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <17998.28659.702653.237011@cargo.ozlabs.ibm.com>
On Sat, 2007-05-19 at 13:33 +1000, Paul Mackerras wrote:
> Daniel Walker writes:
>
> > On Fri, 2007-05-18 at 19:06 +0400, Sergei Shtylyov wrote:
> > > Well, the decrementer frequency may change, at least in theory (if the bus
> > > clock changes).
> >
> > Does that happen very often?
>
> If it did, gettimeofday would start reporting seriously wrong values,
> since the timebase and the decrementer count at the same rate, and we
> don't have any provision for fixing things up if that rate changed.
> Fortunately there are no powerpc platforms where the rate is
> variable.
In terms of clocksources, gettimeofday() would have to switch to another
clocksource if the decrementer started to act that way .. That's why it
is possible to register more than one clocksource, to allow for the
switching. The decrementer frequency doesn't change even with cpufreq?
Daniel
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Benjamin Herrenschmidt @ 2007-05-20 3:03 UTC (permalink / raw)
To: Daniel Walker; +Cc: linuxppc-dev, tglx, Paul Mackerras, mingo, linux-kernel
In-Reply-To: <1179628991.20925.2.camel@imap.mvista.com>
On Sat, 2007-05-19 at 19:43 -0700, Daniel Walker wrote:
> In terms of clocksources, gettimeofday() would have to switch to another
> clocksource if the decrementer started to act that way .. That's why it
> is possible to register more than one clocksource, to allow for the
> switching. The decrementer frequency doesn't change even with cpufreq?
It's more than just gettimeofday. The linux ppc kernel port has strong
assumptions all over the place that the timbase and decrementer (which
always tick at the same rate) have a constant frequency. It might be
possible to "fix" those assumptions but right now, that is the case.
For example, nowadays, udelay() also uses the timebase. Not only
gettimeofday() & friends. The scheduler ticking too. The precise process
accounting as well, etc...
In fact, while it's never worded explicitely in the spec, it's always
been strongly in the "spirit" of the architecture that the timebase and
decrementer have a constant frequency. This is why processors like the
970 allow for an external sourcing for when they are used in setups
where the various clocks are slewed for power management.
Ben.
^ permalink raw reply
* Re: Fixed PHY problems
From: Joakim Tjernlund @ 2007-05-20 10:17 UTC (permalink / raw)
To: Hammond Christian-r55079; +Cc: linuxppc-dev
In-Reply-To: <14B28267C4526A42BA5AC7DAA07B783866B655@zuk35exm20.fsl.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 813 bytes --]
On Sat, 2007-05-19 at 15:42 +0100, Hammond Christian-r55079 wrote:
> Hi Vitaly,
>
> I was pointed in the direction of message chain "Fixed PHY problems"
> for interfacing a fixed PHY to a 83xx UEC. Could you please forward on
> the patch you mentioned in the trail?
Vitaly sent me the patch, had to do some minor tweaking to make it
compile. Attaching the patch.
>
> Any ideas if the implementation succeeded in the end?
No, the fixed PHY is on another bus than what ucc_geth expects.
See msg from me titled "Fixed PHY and MPC832x based boards don't work"
from about a week ago.
Jocke
>
> Christian Hammond
>
> NCSG Applications Engineer
>
> Tel: +44 1355 355962
> Fax: +44 1355 261790
>
> Freescale Semiconductor
> Kelvin Industrial Estate
> East Kilbride
> Glasgow G75 0TG
> United Kingdom
[-- Attachment #2: fixed_driver.patch --]
[-- Type: text/x-patch, Size: 3463 bytes --]
PHY fixed driver: reworked error handling and release path
device_bind_driver() error code returning has been fixed.
release() function has been written, so that to free resources
in correct way.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
drivers/net/phy/fixed.c | 72 +++++++++++++++++++++++++++--------------------
1 files changed, 41 insertions(+), 31 deletions(-)
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
index 68c99b4..0d77805 100644
--- a/drivers/net/phy/fixed.c
+++ b/drivers/net/phy/fixed.c
@@ -187,6 +187,19 @@ static struct phy_driver fixed_mdio_driver = {
.driver = { .owner = THIS_MODULE,},
};
+static void fixed_mdio_release (struct device * dev)
+{
+ struct phy_device *phydev = container_of(dev, struct phy_device, dev);
+ struct mii_bus *bus = phydev->bus;
+ struct fixed_info *fixed = bus->priv;
+
+ kfree(phydev);
+ kfree(bus->dev);
+ kfree(bus);
+ kfree(fixed->regs);
+ kfree(fixed);
+}
+
/*-----------------------------------------------------------------------------
* This func is used to create all the necessary stuff, bind
* the fixed phy driver and register all it on the mdio_bus_type.
@@ -221,6 +234,12 @@ static int fixed_mdio_register_device(int number, int speed, int duplex)
}
fixed->regs = kzalloc(MII_REGS_NUM*sizeof(int), GFP_KERNEL);
+ if (NULL == fixed->regs) {
+ kfree(dev);
+ kfree(new_bus);
+ kfree(fixed);
+ return -ENOMEM;
+ }
fixed->regs_num = MII_REGS_NUM;
fixed->phy_status.speed = speed;
fixed->phy_status.duplex = duplex;
@@ -249,8 +268,11 @@ static int fixed_mdio_register_device(int number, int speed, int duplex)
fixed->phydev = phydev;
if(NULL == phydev) {
- err = -ENOMEM;
- goto device_create_fail;
+ kfree(dev);
+ kfree(new_bus);
+ kfree(fixed->regs);
+ kfree(fixed);
+ return -ENOMEM;
}
phydev->irq = PHY_IGNORE_INTERRUPT;
@@ -262,44 +284,32 @@ static int fixed_mdio_register_device(int number, int speed, int duplex)
else
snprintf(phydev->dev.bus_id, BUS_ID_SIZE,
"fixed@%d:%d", speed, duplex);
+
phydev->bus = new_bus;
+ phydev->dev.driver = &fixed_mdio_driver.driver;
+ phydev->dev.release = fixed_mdio_release;
+
+ err = phydev->dev.driver->probe(&phydev->dev);
+ if(err < 0) {
+ printk(KERN_ERR "Phy %s: problems with fixed driver\n",
+ phydev->dev.bus_id);
+ kfree(phydev);
+ kfree(dev);
+ kfree(new_bus);
+ kfree(fixed->regs);
+ kfree(fixed);
+ return err;
+ }
+
+ down_write(&phydev->dev.bus->subsys.rwsem);
err = device_register(&phydev->dev);
if(err) {
printk(KERN_ERR "Phy %s failed to register\n",
phydev->dev.bus_id);
- goto bus_register_fail;
- }
-
- /*
- the mdio bus has phy_id match... In order not to do it
- artificially, we are binding the driver here by hand;
- it will be the same for all the fixed phys anyway.
- */
- phydev->dev.driver = &fixed_mdio_driver.driver;
-
- err = phydev->dev.driver->probe(&phydev->dev);
- if(err < 0) {
- printk(KERN_ERR "Phy %s: problems with fixed driver\n",phydev->dev.bus_id);
- goto probe_fail;
}
- err = device_bind_driver(&phydev->dev);
- if (err)
- goto probe_fail;
-
return 0;
-
-probe_fail:
- device_unregister(&phydev->dev);
-bus_register_fail:
- kfree(phydev);
-device_create_fail:
- kfree(dev);
- kfree(new_bus);
- kfree(fixed);
-
- return err;
}
^ permalink raw reply related
* Re: 2.6.22-rc1-mm1
From: Sam Ravnborg @ 2007-05-20 10:21 UTC (permalink / raw)
To: Mariusz Kozlowski; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <200705201212.50810.m.kozlowski@tuxland.pl>
On Sun, May 20, 2007 at 12:12:50PM +0200, Mariusz Kozlowski wrote:
> Hello,
>
> I tried it on iMac G3. I got a bunch of warnings
> and finally it failed to build.
>
> WARNING: "fee_restarts" [arch/powerpc/kernel/built-in] is COMMON symbol
> WARNING: "ee_restarts" [arch/powerpc/kernel/built-in] is COMMON symbol
> WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from dt_string_start (offset 0x8)
....
Most - but not all of these warnings should be gone when
Linus pulls kbuild-fix.git.
When -rc3 is ready can you then please post the result of a build.
Then I can take a look at the remaining section mismatch warnings.
Sam
^ 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