* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Segher Boessenkool @ 2007-06-07 15:32 UTC (permalink / raw)
To: David Woodhouse; +Cc: ppcdev, linux-mtd, Milton Miller
In-Reply-To: <1181227676.2785.47.camel@pmac.infradead.org>
>> That's the way the cookie crumbles in Linux MTD for now. It's
>> *always* detecting this by probing -- you only can say what [not] to
>> probe.
>
> You could hook it up to the chip drivers directly if you want, and
> bypass the probe code. I'm not sure it's worth it.
In most cases it is probably not worth it. It is good
to hear that the option to bypass the probe if needed
is available though.
Segher
^ permalink raw reply
* Re: [RFC] 85XX: Allow 8259 cascade to share an MPIC interrupt line.
From: Jon Loeliger @ 2007-06-07 15:30 UTC (permalink / raw)
To: Randy Vinson; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <466755AC.40201@mvista.com>
On Wed, 2007-06-06 at 19:47, Randy Vinson wrote:
> The Freescale MPC8555CDS and MPC8548CDS reference hardware has a legacy
> 8259 interrupt controller pair contained within a VIA VT82C686B Southbridge
> on the main carrier board. The processor complex plugs into the carrier
> card using a PCI slot which limits the available interrupts to the
> INTA-INTD PCI interrupts. The output of the 8259 cascade pair is routed
> through a gate array and connected to the PCI INTA interrupt line.
> The normal interrupt chaining hook (set_irq_chained_handler) does
> not allow sharing of the chained interrupt which prevents the
> use of PCI INTA by PCI devices. This patch allows the 8259 cascade
> pair to share their interrupt line with PCI devices.
>
> Signed-off-by: Randy Vinson <rvinson@mvista.com>
> ---
> Note that there may very well be a better way of accomplishing this. If someone
> has a better alternative, I'm open to it. This was just the simplest way I could
> get this to work.
>
> Also, the addition of the .end routine for the MPIC is not strictly necessary for
> this patch. It's there so this code will run from within the threaded interrupt
> context used by the Real Time patch.
Hmm. I feel that at least the last paragraph here needs
to be above the --- line for future patch readers. Otherwise
it's relationship to the rest of the patch details will be
intermixed and lost.
Thanks,
jdl
^ permalink raw reply
* Re: MPC8349ea Random Device Generator driver
From: Olof Johansson @ 2007-06-07 15:36 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, sl, Philippe Lachenal
In-Reply-To: <46682233.7060601@freescale.com>
On Thu, Jun 07, 2007 at 10:20:19AM -0500, Timur Tabi wrote:
> Ok, I understand that, too. I just don't understand absolutist statements like "you can
> never assign a __le16 type to any other integer type" when our code is full of example of
> doing just that.
Because you're doing it wrong, and your code is broken. Try running
it through sparse and watch the spew. I get 68 sparse warnings on
arch/powerpc/sysdev/*
You have some work to do!
-Olof
^ permalink raw reply
* Re: MPC8349ea Random Device Generator driver
From: Timur Tabi @ 2007-06-07 15:20 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, sl, Philippe Lachenal
In-Reply-To: <20070607152041.GA2851@lixom.net>
Olof Johansson wrote:
> No. in_le16 exists so you can read a little-endian 16 bit register on
> a device, and store it to a regular 16-bit integer variable. It
> has nothing to do with assignment.
What? Reading from a register and storing the value into a variable *is* assignment. If
I have code like this:
A = B;
I'm assigning B to A.
For the record, I understand the concepts you're talking about, I'm only confused about
about some of things I'm reading.
> __le16 is just a type with hints for the programmer: "Hey, this is a
> 16-bit variable, but we're storing it in little-endian format. So if you
> need to use it as a native data type, you need to swap it by hand first",
> and sparse is able to help you find places where you didn't.
I understand that.
> If you use the accessors to read/write hardware (as you are supposed to
> do), then you don't need special types in your structs, just make sure
> you use the right accessors.
Ok, I understand that, too. I just don't understand absolutist statements like "you can
never assign a __le16 type to any other integer type" when our code is full of example of
doing just that.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: MPC8349ea Random Device Generator driver
From: Olof Johansson @ 2007-06-07 15:20 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, sl, Philippe Lachenal
In-Reply-To: <466814E7.3090101@freescale.com>
On Thu, Jun 07, 2007 at 09:23:35AM -0500, Timur Tabi wrote:
> Olof Johansson wrote:
> >On Wed, Jun 06, 2007 at 05:32:19PM -0500, Timur Tabi wrote:
> >>Olof Johansson wrote:
> >>
> >>> - you can never assign a __le16 type to any other integer type or any
> >>> other bitwise type. You'd get a warnign about incompatible types.
> >>> Makes sense, no?
> >>Then why do the in_be functions return an unsigned int instead of a __be
> >>type? Isn't that effectively removing the endian-ness from the type?
> >
> >Because they read a big endian register and returns the contents in the
> >native byte order for the machine.
>
> In other words, the in_le16() function exists so that we can "assign a
> __le16 type to any other integer type or any other bitwise type."
No. in_le16 exists so you can read a little-endian 16 bit register on
a device, and store it to a regular 16-bit integer variable. It
has nothing to do with assignment.
__le16 is just a type with hints for the programmer: "Hey, this is a
16-bit variable, but we're storing it in little-endian format. So if you
need to use it as a native data type, you need to swap it by hand first",
and sparse is able to help you find places where you didn't.
If you use the accessors to read/write hardware (as you are supposed to
do), then you don't need special types in your structs, just make sure
you use the right accessors.
-Olof
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: David Woodhouse @ 2007-06-07 15:08 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <4666AB89.1010206@ru.mvista.com>
On Wed, 2007-06-06 at 16:41 +0400, Sergei Shtylyov wrote:
> > if (*part++ & 1) /* bit 0 set signifies read only partition */
> > (*parts)[i].mask_flags = MTD_WRITEABLE;
>
> > Doesn't that make it RW if bit 0 is set?
What do you get if you mask out the WRITEABLE flag?
--
dwmw2
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: David Woodhouse @ 2007-06-07 15:00 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-mtd, Milton Miller
In-Reply-To: <466323EF.5040807@ru.mvista.com>
On Mon, 2007-06-04 at 00:26 +0400, Sergei Shtylyov wrote:
> Erm, FSL boards seem to generally have dual 16-bit NOR flash chips
> interleaved -- and that's seems quite a common case, not only in PPC world.
Yes, it's something we've seen quite frequently. It's a common way of
improving read/write/erase speed.
> Perhaps... those interleaved chips could really be merged (abstracted)
> into a single one, with the bus width being a sum of two?
That's how Linux deals with it, as I'm sure you're aware. Other
operating systems do likewise. If two 'separate' flash chips hold
alternate bytes of a given address range, you really don't gain much by
representing them as two separate devices to the system.
Any representation of flash devices in the device-tree should ideally
have 'bus width' and 'interleave' properties to contain this
information.
The 'bus width' cannot necessarily be inferred, especially where a given
bus can be configured to allow multiple sizes of access. It's purely a
function of how the flash chips are wired up. That's why we actually
call it 'bank width', not 'bus width' in the Linux code.
--
dwmw2
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: David Woodhouse @ 2007-06-07 14:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppcdev, linux-mtd, Milton Miller
In-Reply-To: <1180904670.31677.18.camel@localhost.localdomain>
On Mon, 2007-06-04 at 07:04 +1000, Benjamin Herrenschmidt wrote:
> So you are saying that because the current linux MTD stuff can only
> probe (which doesn't always work), we should not put the proper chip
> interface type in the device-tree ?
>
> Your argument makes no sense to me.
>
> Put the proper interface informations in the device-tree, maybe some OS
> smarter than linux will make good use on it and maybe linux will be
> fixed at one point too (not by you, of course, you gave us that line
> often enough about not being paid to do the right thing).
In general, Linux is doing the right thing by probing.
There are two major command sets for NOR flash -- the Intel/Sharp
command set, and the AMD/Fujitsu command set.
There are also two major ways to detect flash chips -- the JEDEC probe
with magic numbers for mfr/chip ident, and the CFI ('Common Flash
Interface') probe which gets you tables of information about the chip,
including what optional command set extensions it has, etc.
You _can_ bypass the probe and pass straight through to the 'back-end'
chip driver. But unless you provide the CFI information you won't get to
use any of the optional chip features (or blacklist some of the
known-broken features). It doesn't make a lot of sense to try using the
back-end chip drivers directly. Just go through the normal probe
process, really.
If you really want to bypass the probe, then I suspect you want the full
CFI tables to be present in your OF properties.
--
dwmw2
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: David Woodhouse @ 2007-06-07 14:47 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ppcdev, linux-mtd, Milton Miller
In-Reply-To: <46630256.8050909@ru.mvista.com>
On Sun, 2007-06-03 at 22:03 +0400, Sergei Shtylyov wrote:
> That's the way the cookie crumbles in Linux MTD for now. It's
> *always* detecting this by probing -- you only can say what [not] to
> probe.
You could hook it up to the chip drivers directly if you want, and
bypass the probe code. I'm not sure it's worth it.
--
dwmw2
^ permalink raw reply
* Re: [patch 05/18] PS3: Fix sparse warnings
From: Geoff Levand @ 2007-06-07 14:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, linuxppc-dev, Paul Mackerras, Noguchi, Masato
In-Reply-To: <200706061621.59963.arnd@arndb.de>
Arnd Bergmann wrote:
> On Wednesday 06 June 2007, Geoff Levand wrote:
>> -=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BDspu->l=
ocal_store =3D ioremap(spu->local_store_phys, LS_SIZE);
>> +=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BDspu->l=
ocal_store =3D (__force void *)ioremap(spu->local_store_phys,
>> +=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=
=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=
=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=
=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=
=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=
=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD =EF=BF=BD LS_SIZE)=
;
>=20
> I haven't noticed this before, but it seems to be a preexisting bug:
> You map the local_store as with the guarded page table bit set, which
> causes a performance degradation when accessing the memory from kernel
> space.
>=20
> If you're lucky, your hypervisor knows this and will fix it up for
> you, but I would replace the ioremap call with an
> ioremap_flags(..., _PAGE_NO_CACHE); to be on the safe side.
>=20
> If you want to measure the impact, I'd suggest timing a user space
> read() on the mem file of a running SPU context.
Hi Arnd,
I asked Noguchi-san to check the performance and below is his
report and test program. I'll add the change into my patch set.
-Geoff
-------- Original Message --------
Subject: RE: [patch 05/18] PS3: Fix sparse warnings
Date: Thu, 7 Jun 2007 05:39:43 -0700
From: Noguchi, Masato <Masato.Noguchi@jp.sony.com>
To: Levand, Geoff <Geoffrey.Levand@am.sony.com>
<< A time to read a whole of LS by read system call >>
not patched: avg. 21053.7800 tick ( 263.831830 microseconds )
patched: avg. 20809.2412 tick ( 260.767434 microseconds )
about 1% faster.=20
I think it's a valid difference. (not a measurement error.)
FYI,=20
The attached file is source code to measure it.
I run it 10000 times and calc an average.
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/mman.h>
#include <sys/wait.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <signal.h>
#include <string.h>
#include <stdint.h>
#include <stdlib.h>
#include <pthread.h>
#define __NR_spe_run 278
#define __NR_spe_create 279
#define LS_SIZE 0x40000
#define SPENODE "/spu/stoplooptest"
#define MFTB(RA) __asm__ volatile("mftb %0":"=3Dr"(RA))
long long do_test(void)
{
int spefd =3D -1, lsfd =3D -1;
int npc, status;
long long ret =3D -1;
char buf[LS_SIZE];
int n;
uint32_t t1, t2;
/* create context */
spefd =3D syscall(__NR_spe_create, SPENODE, 0,
S_IRUSR | S_IWUSR | S_IXUSR);
if (spefd < 0) goto out;
/* run once to assign physical spe */
npc =3D 0;
syscall(__NR_spe_run, spefd, &npc, &status);
/* get /mem file descriptor */
lsfd =3D open(SPENODE "/mem", O_RDWR,
S_IRUSR | S_IWUSR);
if (lsfd < 0) goto out;
/* read mem */
MFTB(t1);
if (read(lsfd, buf, LS_SIZE) !=3D LS_SIZE) {
goto out;
}
MFTB(t2);
ret =3D t2 - t1;
out:
if ( lsfd >=3D 0 ) close(lsfd);
if ( spefd >=3D 0 ) close(spefd);
return ret;
}
int main(int argc, char *argv[])
{
long long r;
r =3D do_test();
printf("%lld\n", r);
return 0;
}
^ permalink raw reply
* Re: MPC8349ea Random Device Generator driver
From: Timur Tabi @ 2007-06-07 14:23 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, sl, Philippe Lachenal
In-Reply-To: <20070606235440.GA28400@lixom.net>
Olof Johansson wrote:
> On Wed, Jun 06, 2007 at 05:32:19PM -0500, Timur Tabi wrote:
>> Olof Johansson wrote:
>>
>>> - you can never assign a __le16 type to any other integer type or any
>>> other bitwise type. You'd get a warnign about incompatible types. Makes
>>> sense, no?
>> Then why do the in_be functions return an unsigned int instead of a __be type? Isn't that
>> effectively removing the endian-ness from the type?
>
> Because they read a big endian register and returns the contents in the
> native byte order for the machine.
In other words, the in_le16() function exists so that we can "assign a __le16 type to any
other integer type or any other bitwise type."
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: a question on "iowrite32()"
From: Arnd Bergmann @ 2007-06-07 14:09 UTC (permalink / raw)
To: Ming Liu; +Cc: domen.puncer, linuxppc-embedded
In-Reply-To: <BAY138-F35699348E26C40AED449B3B2260@phx.gbl>
On Thursday 07 June 2007, Ming Liu wrote:
> >Since of_iomap() is rather new and hardly used by any drivers, we
> >could still redefine it so that you would use iowrite32{,be}() instead
> >of out_{be,le}32, but currently that doesn't work.
>
> So if I am correct, your suggestion is to use iowrite32be() in my device
> driver, right?
What I was saying is that iowrite32be is broken for other reasons, as it
is only defined for PCI and ISA devices and you should _not_ use it,
even if it solves the endianess problem.
What you should use is out_be32().
> However, I cannot find such a function defined in my 2.6.10 kernel.
> Isn't iowrite32be() a standard IO function like iowrite32(), or there is
> a patch to export this function?
It's a standard function, is was added less than two years ago.
You should really consider upgrading to a recent kernel version for
a number of reasons, but they are all unrelated to your current problem ;-)
Arnd <><
^ permalink raw reply
* Re: MPC8349ea Random Number Generator driver
From: Arnd Bergmann @ 2007-06-07 14:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sl, Philippe Lachenal
In-Reply-To: <BAY122-F20901751968A5E85E76FBB85260@phx.gbl>
On Thursday 07 June 2007, Philippe Lachenal wrote:
> +-
> +-=A0=A0=A0=A0=A0=A0return ioremap(res.start, 1 + res.end - res.start);
> +-}
>=20
>=20
> why is there a =A01+ res.end-res.start ? Am I wrong in not adding one in =
my=20
> code ?
>=20
Yes. The res.start is the first byte in the area, res.end is the last one.
=46or example, in a two byte range, start could be 100, and end 101.
res.end - res.start would therefore be one, not two as ioremap expects.
Arnd <><
^ permalink raw reply
* Re: [PATCH] Simple driver for Xilinx SPI controler.
From: Andrei Konovalov @ 2007-06-07 13:50 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Neuendorffer, Wolfgang Reissnegger, linuxppc-embedded
In-Reply-To: <fa686aa40706061255w2e589980tf89f3ba763bb9f54@mail.gmail.com>
IMHO the Kconfig stuff is off topic on spi-devel-general list, so I've removed
them from the distribution list. OK?
Grant Likely wrote:
> On 6/6/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>> > Why still have XILINX_EDK? I thought you meant replace
>> > XILINX_EDK with XILINX_DRIVERS.
>>
>> Yes, that's what I was suggesting.
>> But I think that Andrei still wants to use XILINX_EDK to pull in the
>> stuff in drivers/xilinx_common.
Correct,
>> # The Xilinx OS common code
>> obj-$(CONFIG_XILINX_EDK) += xbasic_types.o xpacket_fifo_l_v2_00_a.o \
>> xpacket_fifo_v2_00_a.o xversion.o \
>> xdma_channel.o xdma_channel_sg.o
>>
.. but not exactly this way.
See
http://source.mvista.com/git/gitweb.cgi?p=linux-xilinx-26.git;a=commitdiff;h=e5b35cc7fdef280b7dd7e592a57c6dd823c62ea1
http://source.mvista.com/git/gitweb.cgi?p=linux-xilinx-26.git;a=commitdiff;h=b03eb158a0c1b4a8dd32940df02431bdd5ffcef9
>> Which you wouldn't want if you were able to build a kernel completely
>> from 'non-edk' drivers.
>
> Fair enough, but that's only an issue for vendor trees. None of this
> code will be going into mainline. Any of it that does get into good
> shape should probably go under drivers/misc, and have the drivers
At the moment I have this stuff in arch/ppc/syslib/xilinx.
drivers/misc seems a better place indeed.
Anyone objects I move arch/ppc/syslib/xilinx/* to drivers/misc/xilinx/* ?
> select only the pieces that are needed (with finer-grain CONFIG_
> items).
Yes, my current implementation is:
--- a/arch/ppc/platforms/4xx/Kconfig
+++ b/arch/ppc/platforms/4xx/Kconfig
@@ -229,6 +229,16 @@ config XILINX_VIRTEX_4_FX
config XILINX_VIRTEX
bool
+# The options selected by EDK based drivers. Not visible from [menu]config.
+config XILINX_EDK
+ bool
+config XILINX_IPIF_V123B
+ bool
+config XILINX_FIFO_V200A
+ bool
+config XILINX_DMA_V300A
+ bool
+
config STB03xxx
--- /dev/null
+++ b/arch/ppc/syslib/xilinx/Makefile
@@ -0,0 +1,10 @@
+#
+# Makefile for generic hardware blocks that could be incorporated into
+# various IP blocks: IPIF, FIFO, SGDMA.
+#
+
+obj-$(CONFIG_XILINX_EDK) += xbasic_types.o
+obj-$(CONFIG_XILINX_IPIF_V123B) += xipif_v1_23_b.o
+obj-$(CONFIG_XILINX_FIFO_V200A) += xpacket_fifo_v2_00_a.o \
+ xpacket_fifo_l_v2_00_a.o
+obj-$(CONFIG_XILINX_DMA_V300A) += xdmav3.o xdmav3_intr.o xdmav3_sg.o
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2330,6 +2330,18 @@ config ATL1
To compile this driver as a module, choose M here. The module
will be called atl1.
+config XILINX_TEMAC
+ tristate "Xilinx 10/100/1000 Mbit TEMAC support"
+ depends on XILINX_VIRTEX
+ select PHYLIB
+ select XILINX_EDK
+# select XILINX_IPIF_V123B
+ select XILINX_FIFO_V200A
+ select XILINX_DMA_V300A
+ help
+ This driver supports Tri-Mode, 10/100/1000 Mbit EMAC IP
+ from Xilinx EDK.
+
endif # NETDEV_1000
Is it better?
(Except for CONFIG_XILINX_EDK which should be better renamed to CONFIG_XILINX_COMMON
or CONFIG_XILINX_COMMON_V100A as per the level 1 driver name in the EDK:
sw/XilinxProcessrIPLib/drivers/common_v1_00_a/src)
> A blanked CONFIG_XILINX_EDK for random stuff is not a good
> idea.
Agreed
Thanks,
Andrei
> Cheers,
> g.
>
>>
>> Steve
>>
>>
>>
>
>
^ permalink raw reply
* Re: [PATCH] add rtc-on-i2c node to two linkstation device-trees
From: Segher Boessenkool @ 2007-06-07 13:32 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.60.0706042159090.3653@poirot.grange>
> If approved here, this patch will follow the previous one for i2c-of
> definitions to the -mm tree, to fix linkstation breakage caused by
> converting rtc-rs5c372 driver to the new i2c api.
The changes look good to me.
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Segher Boessenkool @ 2007-06-07 13:30 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070606023939.GC8182@localhost.localdomain>
> Whatever Segher says, I think it's fine to have the partition
> information here.
It's nonsense to have it *inside that device node*. I
understand if you want to express it elsewhere.
> It may not be hardware information, but it is
> (often) firmware information;
Only part of it is. The rest should *not* be dictated
by the firmware; for example, if a new OS image for
the device needs different flash partition sizes, you
would have to reflash the firmware! Obviously less than
ideal, and we can't have that kind of stuff in a more-
or-less generic device tree binding.
> there are plenty precedents for things
> like this in the device tree and it doesn't get in the way of any real
> hardware information.
There is plenty of precedent for putting stuff that
is not configuration info for some OS in the device
tree, yes -- like describing the flash region used
by firmware code (as a subnode of the flash node,
perhaps). A "generic" (i.e., specific to the current
implementation of linux-mtd) partition map is no such
thing.
> That said, I'm a bit dubious about the encoding of the RO/RW bit into
> the partition length (which I only just realised was used now).
Quite.
>> So, what should the DT look like for this thing? And, what should
>> phymap_of.c be doing?
I think we want to define a binding for a "cfi-flash"
device, instead.
Segher
^ permalink raw reply
* Re: [PATCH] Create add_rtc() function to enable the RTC CMOS driver
From: Segher Boessenkool @ 2007-06-07 13:11 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200706070044.35056.arnd@arndb.de>
>> +=A0=A0=A0=A0=A0=A0=A0np =3D of_find_compatible_node(NULL, NULL, =
"pnpPNP,b00");
> Doesn't this conflict with a potential isapnp driver for the same
> device? If you have multiple isapnp devices, it may be better
> to add a bus driver for the isapnp host, and use device drivers
> for that bus instead of platform devices.
"pnpPNP" devices are not ISA PNP devices; indeed, they
are exactly those legacy PC ISA devices that are not
ISA PNP.
Segher
^ permalink raw reply
* Re: [PATCH] When checking I8042 io port, use of_find_compatible_node() instead of of_find_node_by_type()
From: Segher Boessenkool @ 2007-06-07 13:05 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-dev, paulus
In-Reply-To: <1181148145.5674.121.camel@rhino>
> In check_legacy_ioport(), instead of using of_find_node_by_type() to
> find the 8042 node, use of_find_compatible_node() to find either the
> keyboard or mouse node.
Why?
> switch(base_port) {
> case I8042_DATA_REG:
> - np = of_find_node_by_type(NULL, "8042");
> + np = of_find_compatible_node(NULL, NULL, "pnpPNP,303");
> + if (!np)
> + np = of_find_compatible_node(NULL, NULL, "pnpPNP,f03");
> + if (np) {
> + parent = of_get_parent(np);
> + of_node_put(np);
> + np = parent;
> + }
This breaks other boards using 8042, if those exist --
if this code is board-specific, it is in the wrong file.
Segher
^ permalink raw reply
* Re: [PATCH] Fix the LPC47M192 SuperIO on the MPC8641 HPCN
From: Segher Boessenkool @ 2007-06-07 13:03 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200706070039.51541.arnd@arndb.de>
>> +=A0=A0=A0=A0=A0=A0=A0/* LPC47M192 Super I/O configuration */
>> +=A0=A0=A0=A0=A0=A0=A0outb(0x55, 0x4e);=A0=A0=A0=A0=A0=A0=A0/* enter =
superio config mode */
>> +
>> +=A0=A0=A0=A0=A0=A0=A0/* Enable keyboard and mouse */
>> +=A0=A0=A0=A0=A0=A0=A0outb(0x07, 0x4e);=A0=A0=A0=A0=A0=A0=A0/* device =
selector register */
>> +=A0=A0=A0=A0=A0=A0=A0outb(0x07, 0x4f);=A0=A0=A0=A0=A0=A0=A0/* select =
keyboard registers (device=20
>> 7) */
>> +=A0=A0=A0=A0=A0=A0=A0outb(0x30, 0x4e);=A0=A0=A0=A0=A0=A0=A0/* =
keyboard activation register */
>> +=A0=A0=A0=A0=A0=A0=A0outb(0x01, 0x4f);=A0=A0=A0=A0=A0=A0=A0/* =
activate keyboard */
>
> Hardcoded I/O port numbers always worry me a little. I know that this=20=
> is
> supposed to work in general, but can't you read the I/O port range =
from
> a device tree property?
This code is writing hardcoded values into IRQ#
and address window registers, the superio configuration
address should be the least of your worries ;-)
Segher
^ permalink raw reply
* Re: [PATCH] Fix the LPC47M192 SuperIO on the MPC8641 HPCN
From: Segher Boessenkool @ 2007-06-07 13:01 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-dev, paulus
In-Reply-To: <1181147415.5674.108.camel@rhino>
> + /* enable superio @ 0x4e and keyboard/mouse address decoding */
> + pci_write_config_byte(dev, 0x63, 0x90);
I doubt that comment is accurate.
> + outb(0x07, 0x4e); /* device selector register */
> + outb(0x07, 0x4f); /* select keyboard registers (device 7) */
Please abstract out the 4e,4f access sequence, so
you can just say write_sio(0x30, 1); or similar.
> + /* Enable superio runtime registers for gpio in pci i/o space */
> + outb(0x20, 0x4e); /* device id register */
This write is superfluous as far as I can see.
Segher
^ permalink raw reply
* Re: 83xx GPIO/EXT int in arch/powerpc/
From: Segher Boessenkool @ 2007-06-07 12:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1181169093.31677.260.camel@localhost.localdomain>
>> - You can do it in your interrupt-map. That's probably the cleanest
>>> way
>>> to do it.
>>
>> Not really. If the device interrupt is physically connected
>> directly to a GPIO or a PIC or whatever, if it doesn't go
>> through the PCI bus; then it shouldn't be represented in
>> the device tree as if it did. The higher-up bridge has
>> nothing whatsoever to do with this device's interrupt.
>>
>> It's a simple hack of course, it can be useful sometimes.
>> It's not "clean" at all however.
>
> I disagree :-)
I think you didn't notice that I was talking about
pretending the IRQ signal of a device on PCI bus #1
being routed through PCI bus #0, the grandparent bus
of the device instead of the parent bus. If it were
about the direct parent bus than anything could be
handled with an interrupt-map just fine, in the current
situation it is just ugly and wrong and it cannot work
in slightly more general situations, either.
> The interrupt-map simply provides for each slot where the interrupt
> goes. It's perfectly fine and clean to use it when those interrupts are
> hooked to GPIOs and has been a common practice. I really don't see a
> problem with that.
You shouldn't map interrupts from devices on your
children's busses, that's the problem.
>> Depending on the rest of the tree, this would often mean
>> you have to do a much bigger interrupt-map-mask than
>> without this hack, and the corresponding explosion in
>> interrupt-map size.
>
> Not really again. Besides, devices normally use only int#A, only
> bridges
> use more.
Again, in the case under discussion, PCI bus# needs to
be part of the map-mask, and you can't do swizzling (or
a simple direct translation, whatever is appropriate)
for the bus-bus connection -- you have to spell out every
source deep down the domain.
> Segher, I feel here that your inability to resist arguing about
> everything in that case is confusing what is a fairly simple issue in
> the first place :-)
It isn't simple. It is also wrong. If a bus does
not deliver interrupts from its children to its
parent, than the device tree should not pretend it
does.
> Poor guy trying to figure out the right way to do
> his stuff will run away screaming and go back hard coding his number in
> his platform code before we are finished :-)
Heh I hope not.
> So I would say, taking a dicator hat, that the right way to fix his
> problem is also the simplest, which is to make sure the interrupt-map
> entry for that slot points to the right GPIO interrupt :-)
It's wrong and not simple. Let me show you with some
pictures. A device X on PCI bus P1, interrupt goes
straight to interrupt controller I.
Here's what you say is right:
P0 interrupt-map < ...reg 19000 irq IRQ -> I... >
|
P1
|
X@12 reg <19000>
interrupt-parent <P0>
interrupt <IRQ>
And here is my version:
P0
|
P1 interrupt-map < ... reg 9000 irq IRQ -> I ... >
|
X@12 reg <19000>
interrupt-parent <P0>
interrupt <IRQ>
> Easy isn't it ?
Yes, it's only hard if you're trying to avoid doing
mapping properties where they are necessary, including
stand-alone interrupt nexus nodes (not needed in this
case btw, not needed most simple cases).
Segher
^ permalink raw reply
* Please pull powerpc.git master branch
From: Paul Mackerras @ 2007-06-07 12:51 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master
There is a series of bug-fixes for the Cell port, plus a boot wrapper
fix from me, a pasemi fix from Olof and a couple of documentation
updates.
Thanks,
Paul.
Documentation/powerpc/booting-without-of.txt | 59 +++++++++-
arch/powerpc/boot/crt0.S | 1
arch/powerpc/kernel/of_platform.c | 2
arch/powerpc/platforms/cell/cbe_cpufreq.c | 33 ++++-
arch/powerpc/platforms/cell/spufs/context.c | 4 -
arch/powerpc/platforms/cell/spufs/file.c | 57 +++++----
arch/powerpc/platforms/cell/spufs/inode.c | 62 ++++------
arch/powerpc/platforms/cell/spufs/sched.c | 161 +++++++++++++-------------
arch/powerpc/platforms/cell/spufs/spufs.h | 2
arch/powerpc/platforms/celleb/Makefile | 2
arch/powerpc/platforms/pasemi/iommu.c | 8 -
11 files changed, 224 insertions(+), 167 deletions(-)
commit f40e524eaec9697d1515564fd5b961d839d2dc4f
Author: Paul Mackerras <paulus@samba.org>
Date: Thu Jun 7 22:21:31 2007 +1000
[POWERPC] Fix building of COFF zImages
The COFF zImage (for booting oldworld powermacs) wasn't being built
correctly because the procedure descriptor in crt0.S for the zImage
entry point wasn't declared as .globl, and therefore wasn't getting
pulled in from wrapper.a by the linker. This adds the necessary
.globl statement.
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 87873c86802ba7ff9d9550d06459a6e99d72c5eb
Author: Sebastian Siewior <bigeasy@linux.vnet.ibm.com>
Date: Wed Jun 6 14:03:58 2007 +1000
[POWERPC] spufs: Fix error handling in spufs_fill_dir()
The error path in spufs_fill_dir() is broken. If d_alloc_name() or
spufs_new_file() fails, spufs_prune_dir() is getting called. At this time
dir->inode is not set and a NULL pointer is dereferenced by mutex_lock().
This bugfix replaces spufs_prune_dir() with a shorter version that does
not touch dir->inode but simply removes all children.
Signed-off-by: Sebastian Siewior <bigeasy@linux.vnet.ibm.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 5e1e9ba690a2e2135a8f997242f9c46d2b8ac033
Author: Stuart Yoder <stuart.yoder@freescale.com>
Date: Wed Jun 6 04:29:14 2007 +1000
[POWERPC] Add table of contents to booting-without-of.txt
Add table of contents.
Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit e5c0b9ec538a86433ddd725f675e0a5a2117b9ed
Author: Christoph Hellwig <hch@lst.de>
Date: Tue Jun 5 11:25:59 2007 +1000
[POWERPC] spufs: Don't yield nosched context
Nosched context sould never be scheduled out, thus we must not
deactivate them in spu_yield ever.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit d30ac1242bf842fe28501a78a460a43910ef2dba
Author: Stuart Yoder <stuart.yoder@freescale.com>
Date: Tue Jun 5 07:16:15 2007 +1000
[POWERPC] Fix typo in booting-without-of-txt section numbering
Fix typo in section numbering.
Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 6dcbf164dcf4042bcbe9f56d94f65acd10b0e1f6
Author: Christoph Hellwig <hch@lst.de>
Date: Tue Jun 5 04:14:41 2007 +1000
[POWERPC] scc_sio: Fix link failure
scc_sio.o should only be built if the txx9 serial driver is actually
built into the kernel.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
--
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 1552cb923efcd0f5499104256010d2ace437581d
Author: Thomas Renninger <trenn@suse.de>
Date: Tue Jun 5 04:14:40 2007 +1000
[POWERPC] cbe_cpufreq: Limit frequency via cpufreq notifier chain
... and get rid of cpufreq_set_policy call that caused a build
failure due interfering commits.
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit e7c40012b84f670ba57fe4a3f453ddecc8813e9b
Author: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Date: Tue Jun 5 04:14:39 2007 +1000
[POWERPC] Fix pci_setup_phb_io_dynamic for pci_iomap
We had a problem on a system with only dynamically allocated
PCI buses (using of_pci_phb_driver) in combination with libata.
This setup ended up having no "primary" phb, which means
that pci_io_base never got initialized and all IO port
numbers are 64 bit numbers, which is larger than the
PIO_MASK limit.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit bb5db29aa0379f0f3ef857a3a3715f17261c611b
Author: Christoph Hellwig <hch@lst.de>
Date: Mon Jun 4 23:26:51 2007 +1000
[POWERPC] spufs scheduler: Fix wakeup races
Fix the race between checking for contexts on the runqueue and actually
waking them in spu_deactive and spu_yield.
The guts of spu_reschedule are split into a new helper called
grab_runnable_context which shows if there is a runnable thread below
a specified priority and if yes removes if from the runqueue and uses
it. This function is used by the new __spu_deactivate hepler shared
by preemption and spu_yield to grab a new context before deactivating
a specified priority and if yes removes if from the runqueue and uses
it. This function is used by the new __spu_deactivate hepler shared
by preemption and spu_yield to grab a new context before deactivating
the old one.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 47d3a5faa3f72186f769ed9579c630afb8433f2b
Author: Christoph Hellwig <hch@lst.de>
Date: Mon Jun 4 23:26:51 2007 +1000
[POWERPC] spufs: Synchronize pte invalidation vs ps close
Make sure the mapping_lock also protects access to the various address_space
pointers used for tearing down the ptes on a spu context switch.
Because unmap_mapping_range can sleep we need to turn mapping_lock from
a spinlock into a sleeping mutex.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 89df00855beabfa700f9a9ed52f0983bdc4b021d
Author: Sebastian Siewior <bigeasy@linux.vnet.ibm.com>
Date: Mon Jun 4 23:26:51 2007 +1000
[POWERPC] spufs: Free mm if spufs_fill_dir() failed
In case spufs_fill_dir() fails only put_spu_context()
gets called for cleanup and the acquired mm_struct never gets freed.
Signed-off-by: Sebastian Siewior <bigeasy@linux.vnet.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 877907d37da9694a34adc9dc3e2ce09400148cb5
Author: Jeremy Kerr <jk@ozlabs.org>
Date: Mon Jun 4 23:26:51 2007 +1000
[POWERPC] spufs: Fix gang destroy leaks
Previously, closing a SPE gang that still has contexts would trigger
a WARN_ON, and leak the allocated gang.
This change fixes the problem by using the gang's reference counts to
destroy the gang instead. The gangs will persist until their last
reference (be it context or open file handle) is gone.
Also, avoid using statements with side-effects in a WARN_ON().
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit ce92987baba60bc082b9eedddfaf4ae3f8435dac
Author: Christoph Hellwig <hch@lst.de>
Date: Mon Jun 4 23:26:51 2007 +1000
[POWERPC] spufs: Hook up spufs_release_mem
Currently spufs_mem_release and the mem file doesn't have any release
method hooked up, leading to leaks everytime is used.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 8f18a158192ef6dc63a572bdbbdf5613cfbbe2e4
Author: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Date: Mon Jun 4 23:26:51 2007 +1000
[POWERPC] spufs: Refuse to load the module when not running on cell
As noticed by David Woodhouse, it's currently possible to mount
spufs on any machine, which means that it actually will get
mounted by fedora.
This refuses to load the module on platforms that have no
support for SPUs.
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 6291ed3c04d5c83c26e77d4fa47e06d0416be81d
Author: Olof Johansson <olof@lixom.net>
Date: Mon Jun 4 10:49:05 2007 +1000
[POWERPC] pasemi: Fix iommu + 64K PAGE_SIZE bug
The powerpc iommu code was refactored by Linas back in the 2.6.20 time
frame to map 4K pages from the generic code, but I had forgotten to go
back and fix my platform driver before submitting it.
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* [PATCH] Fix per-cpu allocation on oldworld SMP powermacs
From: Paul Mackerras @ 2007-06-07 12:42 UTC (permalink / raw)
To: linuxppc-dev
The per-cpu area(a) for the secondary CPU(s) isn't getting allocated
on old SMP powermacs that don't have the secondary CPU(s) listed in
the device tree, as per-cpu areas are now only allocated for CPUs in
the cpu_possible_map, and we aren't setting the bits for the secondary
CPU(s) until smp_prepare_cpus(), which is after per-cpu allocation.
Therefore this sets the bits for CPUs 1..3 in cpu_possible_map in
pmac_setup_arch, so they get per-cpu data allocated.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
index 07b1c4e..c519b2a 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -363,8 +363,19 @@ static void __init pmac_setup_arch(void)
smp_ops = &core99_smp_ops;
}
#ifdef CONFIG_PPC32
- else
+ else {
+ /*
+ * We have to set bits in cpu_possible_map here since the
+ * secondary CPU(s) aren't in the device tree, and
+ * setup_per_cpu_areas only allocates per-cpu data for
+ * CPUs in the cpu_possible_map.
+ */
+ int cpu;
+
+ for (cpu = 1; cpu < 4 && cpu < NR_CPUS; ++cpu)
+ cpu_set(cpu, cpu_possible_map);
smp_ops = &psurge_smp_ops;
+ }
#endif
#endif /* CONFIG_SMP */
diff --git a/arch/powerpc/platforms/powermac/smp.c b/arch/powerpc/platforms/powermac/smp.c
index 686ed82..cb2d894 100644
--- a/arch/powerpc/platforms/powermac/smp.c
+++ b/arch/powerpc/platforms/powermac/smp.c
@@ -317,7 +317,6 @@ static int __init smp_psurge_probe(void)
ncpus = NR_CPUS;
for (i = 1; i < ncpus ; ++i) {
cpu_set(i, cpu_present_map);
- cpu_set(i, cpu_possible_map);
set_hard_smp_processor_id(i, i);
}
^ permalink raw reply related
* Re: [RFC/PATCH 4/4] Add support for MSI on Axon-based Cell systems
From: Jean-Christophe Dubois @ 2007-06-07 12:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1181217341.14818.48.camel@localhost.localdomain>
On Thursday 07 June 2007 13:55:41 Benjamin Herrenschmidt wrote:
> On Thu, 2007-06-07 at 10:10 +0200, Jean-Christophe Dubois wrote:
> > The CAB (or other derived products) can be set in RC mode (via a jumper).
> > In this case the MSI could be supported.
>
> Is there any plan to have CABs based on AXON DD >= 2.0
Sure, There are several at Mercury (based on Axon 2.1) and I have one. And I
believe it will be based on Axon 3.0 when available.
> I still think the right approach is to have the right properties set by
> the firmware if the Axon version supports MSIs reliably. Do you see any
> problem with this approach ?
Once again SLOF firmware is out of my influence realm. I work with what IBM is
delivering for CAB ... So if the firmware has some deficiencies I must make
sure we can work around them.
JC
> Ben.
^ permalink raw reply
* Re: [RFC/PATCH 4/4] Add support for MSI on Axon-based Cell systems
From: Benjamin Herrenschmidt @ 2007-06-07 11:55 UTC (permalink / raw)
To: Jean-Christophe Dubois; +Cc: linuxppc-dev
In-Reply-To: <200706071010.05172.jdubois@mc.com>
On Thu, 2007-06-07 at 10:10 +0200, Jean-Christophe Dubois wrote:
> The CAB (or other derived products) can be set in RC mode (via a jumper). In
> this case the MSI could be supported.
Is there any plan to have CABs based on AXON DD >= 2.0
I still think the right approach is to have the right properties set by
the firmware if the Axon version supports MSIs reliably. Do you see any
problem with this approach ?
Ben.
^ 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