* [PATCH 05/11] pa_pxp_ops: use named structure member initializers
From: Nathan Lynch @ 2007-08-09 19:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olof Johansson, Paul Mackerras
In-Reply-To: <11866871262306-git-send-email-ntl@pobox.com>
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/platforms/pasemi/pci.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pasemi/pci.c b/arch/powerpc/platforms/pasemi/pci.c
index ab1f5f6..882b571 100644
--- a/arch/powerpc/platforms/pasemi/pci.c
+++ b/arch/powerpc/platforms/pasemi/pci.c
@@ -122,8 +122,8 @@ static int pa_pxp_write_config(struct pci_bus *bus, unsigned int devfn,
}
static struct pci_ops pa_pxp_ops = {
- pa_pxp_read_config,
- pa_pxp_write_config,
+ .read = pa_pxp_read_config,
+ .write = pa_pxp_write_config,
};
static void __init setup_pa_pxp(struct pci_controller *hose)
--
1.5.2.4
^ permalink raw reply related
* [PATCH 06/11] powermac pci_ops: use named structure member initializers
From: Nathan Lynch @ 2007-08-09 19:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <11866871262306-git-send-email-ntl@pobox.com>
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/platforms/powermac/pci.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/pci.c b/arch/powerpc/platforms/powermac/pci.c
index 92586db..69d67ff 100644
--- a/arch/powerpc/platforms/powermac/pci.c
+++ b/arch/powerpc/platforms/powermac/pci.c
@@ -225,8 +225,8 @@ static int macrisc_write_config(struct pci_bus *bus, unsigned int devfn,
static struct pci_ops macrisc_pci_ops =
{
- macrisc_read_config,
- macrisc_write_config
+ .read = macrisc_read_config,
+ .write = macrisc_write_config,
};
#ifdef CONFIG_PPC32
@@ -280,8 +280,8 @@ chaos_write_config(struct pci_bus *bus, unsigned int devfn, int offset,
static struct pci_ops chaos_pci_ops =
{
- chaos_read_config,
- chaos_write_config
+ .read = chaos_read_config,
+ .write = chaos_write_config,
};
static void __init setup_chaos(struct pci_controller *hose,
@@ -456,8 +456,8 @@ static int u3_ht_write_config(struct pci_bus *bus, unsigned int devfn,
static struct pci_ops u3_ht_pci_ops =
{
- u3_ht_read_config,
- u3_ht_write_config
+ .read = u3_ht_read_config,
+ .write = u3_ht_write_config,
};
#define U4_PCIE_CFA0(devfn, off) \
@@ -561,8 +561,8 @@ static int u4_pcie_write_config(struct pci_bus *bus, unsigned int devfn,
static struct pci_ops u4_pcie_pci_ops =
{
- u4_pcie_read_config,
- u4_pcie_write_config
+ .read = u4_pcie_read_config,
+ .write = u4_pcie_write_config,
};
#endif /* CONFIG_PPC64 */
--
1.5.2.4
^ permalink raw reply related
* [PATCH 07/11] null_pci_ops: use named structure member initializers
From: Nathan Lynch @ 2007-08-09 19:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <11866871262306-git-send-email-ntl@pobox.com>
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/kernel/pci_32.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 04a3109..0e2bee4 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -1457,8 +1457,8 @@ null_write_config(struct pci_bus *bus, unsigned int devfn, int offset,
static struct pci_ops null_pci_ops =
{
- null_read_config,
- null_write_config
+ .read = null_read_config,
+ .write = null_write_config,
};
/*
--
1.5.2.4
^ permalink raw reply related
* [PATCH 08/11] efika rtas_pci_ops: use named structure member initializers
From: Nathan Lynch @ 2007-08-09 19:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sylvain Munaut, Paul Mackerras
In-Reply-To: <11866871262306-git-send-email-ntl@pobox.com>
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/platforms/52xx/efika.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/efika.c b/arch/powerpc/platforms/52xx/efika.c
index 4be6e7a..4263158 100644
--- a/arch/powerpc/platforms/52xx/efika.c
+++ b/arch/powerpc/platforms/52xx/efika.c
@@ -78,8 +78,8 @@ static int rtas_write_config(struct pci_bus *bus, unsigned int devfn,
}
static struct pci_ops rtas_pci_ops = {
- rtas_read_config,
- rtas_write_config
+ .read = rtas_read_config,
+ .write = rtas_write_config,
};
--
1.5.2.4
^ permalink raw reply related
* [PATCH 09/11] chrp pci_ops: use named structure member initializers
From: Nathan Lynch @ 2007-08-09 19:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <11866871262306-git-send-email-ntl@pobox.com>
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/platforms/chrp/pci.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/chrp/pci.c b/arch/powerpc/platforms/chrp/pci.c
index 28d1647..0c6dba9 100644
--- a/arch/powerpc/platforms/chrp/pci.c
+++ b/arch/powerpc/platforms/chrp/pci.c
@@ -86,8 +86,8 @@ int gg2_write_config(struct pci_bus *bus, unsigned int devfn, int off,
static struct pci_ops gg2_pci_ops =
{
- gg2_read_config,
- gg2_write_config
+ .read = gg2_read_config,
+ .write = gg2_write_config,
};
/*
@@ -124,8 +124,8 @@ int rtas_write_config(struct pci_bus *bus, unsigned int devfn, int offset,
static struct pci_ops rtas_pci_ops =
{
- rtas_read_config,
- rtas_write_config
+ .read = rtas_read_config,
+ .write = rtas_write_config,
};
volatile struct Hydra __iomem *Hydra = NULL;
--
1.5.2.4
^ permalink raw reply related
* [PATCH 10/11] indirect_pci_ops: use named structure member initializers
From: Nathan Lynch @ 2007-08-09 19:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <11866871262306-git-send-email-ntl@pobox.com>
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/sysdev/indirect_pci.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/indirect_pci.c b/arch/powerpc/sysdev/indirect_pci.c
index 5294560..b5d0682 100644
--- a/arch/powerpc/sysdev/indirect_pci.c
+++ b/arch/powerpc/sysdev/indirect_pci.c
@@ -144,8 +144,8 @@ indirect_write_config(struct pci_bus *bus, unsigned int devfn, int offset,
static struct pci_ops indirect_pci_ops =
{
- indirect_read_config,
- indirect_write_config
+ .read = indirect_read_config,
+ .write = indirect_write_config,
};
void __init
--
1.5.2.4
^ permalink raw reply related
* [PATCH 11/11] tsi108_direct_pci_ops: use named structure member initializers
From: Nathan Lynch @ 2007-08-09 19:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexandre Bounine, Paul Mackerras
In-Reply-To: <11866871262306-git-send-email-ntl@pobox.com>
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/sysdev/tsi108_pci.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/tsi108_pci.c b/arch/powerpc/sysdev/tsi108_pci.c
index 90db8a7..cf0bfbd 100644
--- a/arch/powerpc/sysdev/tsi108_pci.c
+++ b/arch/powerpc/sysdev/tsi108_pci.c
@@ -193,8 +193,8 @@ void tsi108_clear_pci_cfg_error(void)
}
static struct pci_ops tsi108_direct_pci_ops = {
- tsi108_direct_read_config,
- tsi108_direct_write_config
+ .read = tsi108_direct_read_config,
+ .write = tsi108_direct_write_config,
};
int __init tsi108_setup_pci(struct device_node *dev, u32 cfg_phys, int primary)
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH 05/11] pa_pxp_ops: use named structure member initializers
From: Olof Johansson @ 2007-08-09 19:57 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1186687145968-git-send-email-ntl@pobox.com>
On Thu, Aug 09, 2007 at 02:18:40PM -0500, Nathan Lynch wrote:
> Signed-off-by: Nathan Lynch <ntl@pobox.com>
Acked-by: Olof Johansson <olof@lixom.net>
Thanks!
-Olof
^ permalink raw reply
* Re: [alsa-devel] [PATCH 1/2] Xlinx ML403 AC97 Controller Reference device driver
From: Joachim Förster @ 2007-08-09 19:44 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel, Lorenz Kolb, linuxppc-embedded@ozlabs.org
In-Reply-To: <s5hsl6sws0s.wl%tiwai@suse.de>
Hi Takashi,
before posting a corrected version, I would like to ask some unclear
things (I think I understood the rest):
On Thu, 2007-08-09 at 19:13 +0200, Takashi Iwai wrote:
> (snip)
> > +static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX;
> > +static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR;
> > +static int enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE;
>
> Can the driver really support multiple instances?
> If not, better to avoid these arrays.
Well, while I wrote the driver I considered that there might be more
than one instance - though I didn't test it and I won't be able to test
it (no such hardware available - with more than one LM4550 chip).
So, shall I remove it?
> > +struct lm4550_reg lm4550_regfile[64] = {
> > + {.reg = 0x00,
> > + .flag = LM4550_REG_NOSAVE | LM4550_REG_FAKEREAD,
> > + .def = 0x0D50},
>
> Better to use C99 style initialization here, e.g.
>
> [0x00] = { .... },
> [0x02] = { .... },
> [0x7e] = { .... },
>
> so you can avoid writing empty items.
> The index value could be also AC97_XXX, such as [AC97_MASTER] =
> {...}.
>
> What is the purpose of reg field at all, BTW? I guess it's
> superfluous.
No, it's there to provide a shadow copy of the codec's (LM4550)
registers. It contains default values and (while driver is running)
current values, which were written to the hardware. I had to introduce
this, because Xilinx's AC97 Controller Reference has a very ugly bug: It
provides a "register access finish" bit, so the driver is able to tell
when a register read or write access is finished. Unfortunately this
particular bit only works in the range of 0 to 100 times since board
reset. After that many register access it just remains saying: I'm _not_
ready. But in fact, in most cases (98%) the correct value already is the
read register (assume we have just said to the control that we want to
read a register).
I thought, ok we have such RegAccessFinished bit, so use it, if we have
to, until it doesn't work anymore.
So, through a shadow copy of most registers (some cannot be shadow or it
makes no sence) I can provide the values without having to actually read
from the controller/codec. The regfile also contains info which register
might be shadowed, if values get saved at all (if written) ...
Furthermore ALSA's AC97 layer does heavy initialization access series on
the codec, which I tried to "mask out" completely
(LM4550_REG_FAKEPROBE).
> > +#define LM4550_RF_FLAG(reg) lm4550_regfile[reg / 2].flag
<snip>
> > +static void lm4550_regfile_init(void)
> > +{
> > + int i;
> > + for (i = 0; i < 128; i = i + 2)
> > + if (LM4550_RF_FLAG(i) & LM4550_REG_FAKEPROBE)
> > + LM4550_RF_VAL(i) = LM4550_RF_DEF(i);
>
> "MACRO(x) = XXX" looks a bit strange to me.
Hmmm, ok. I thought about that, too. I think, I'll spell them out?
> RATE_CONTINUOUS and RATE_KNOW are usually exclusive.
Ok, so what I want is RATE_CONTINUOUS, right? (because the LM4550
supports 4000 to 48000kHz in 1Hz steps)
BTW: What is RATE_KNOT good for?
Joachim
^ permalink raw reply
* Re: [PATCH] powerpc: fix i2c device string format
From: Segher Boessenkool @ 2007-08-09 19:45 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0708080023030.8493@poirot.grange>
>> strncpy() won't put a terminating zero on there, is everything
>> that uses the resulting string okay with that? Also, if the
>> name gets cut short, it might match some _other_ expected name.
>
> On Wed, 1 Aug 2007, Scott Wood wrote:
>
>> You could use strlcpy() instead, which always leaves a zero
>> terminator.
>
> The patch below does exactly this - uses strlcpy() to guarantee
> strings in
> i2c device type and driver_name fields are 0-terminated.
You're not checking the return values of these calls. This would
be a good function to put attribute warn_unused_result on :-)
Segher
^ permalink raw reply
* Re: [RFC/PATCH] remove gratuitous reads from maple pci config space methods
From: Olof Johansson @ 2007-08-09 20:03 UTC (permalink / raw)
To: Nathan Lynch; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <20070809010431.GF10114@localdomain>
On Wed, Aug 08, 2007 at 08:04:32PM -0500, Nathan Lynch wrote:
> Benjamin Herrenschmidt wrote:
> > On Wed, 2007-08-08 at 19:50 -0500, Nathan Lynch wrote:
> > >
> > > Remove the gratuitous reads from u3_agp_write_config,
> > > u3_ht_write_config, and u4_pcie_write_config.
> > >
> > > Signed-off-by: Nathan Lynch <ntl@pobox.com>
> >
> > Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > ---
> >
> > Thanks ! Care to fix powermac too ? :-)
>
> Sure, I'll get it tomorrow... looks like pasemi cribbed the powermac
> code too :)
Yeah, it originated either from powermac or maple so it's there too. Feel
free to fix it too while you're at it.
-Olof
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: Segher Boessenkool @ 2007-08-09 19:53 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070808011324.GD25082@localhost.localdomain>
>>>> I haven't heard or thought of anything better either. Using
>>>> "ranges"
>>>> is conceptually wrong, even ignoring the technical problems that
>>>> come
>>>> with it.
>>>
>>> Why is "ranges" conceptually wrong?
>>
>> The flash partitions aren't separate devices sitting on a
>> "flash bus", they are "sub-devices" of their parent.
>
> Well, yes, but nonetheless the partitions show up as part of the
> overall physical address space. How do you encode that other than in
> 'ranges'?
All that address space shows up in the flash node already. To
access the partitions you have to go via that "master" node
anyway (some commands have to be sent to address 0 on the flash,
or similar).
It is a very nice feature to not only be able to translate addresses
"up" the device tree, but also "down".
Also, it mimics reality, just like a good OF citizen should:
those partitions aren't actually devices at all, so they
certainly shouldn't be assigned a part of the host address
space.
>>> To be honest this looks rather to me like another case where having
>>> overlapping 'reg' and 'ranges' would actually make sense.
>>
>> It never makes sense. You should give the "master" device
>> the full "reg" range it covers, and have it define its own
>> address space; "sub-devices" can carve out their little hunk
>> from that. You don't want more than one device owning the
>> same address range in the same address space.
>
> Why not? After all, the physical address ranges of the flash
> partitions really do overlap with that of the flash device as a whole.
They don't overlap, a partition is a proper subset of the flash.
Which as usual is shown as "reg" in the child node and #a,#s in
the parent node.
Segher
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: Segher Boessenkool @ 2007-08-09 20:00 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070808015150.GC20565@localhost.localdomain>
>> For the JEDEC chips, we need a "vendor-id" and "device-id"
>> property at least (or similar names -- whatever is general
>> practice for this); both are a single byte, encoded as with
>> encode-int.
>
> Ok... should those really be separate properties, or should that go in
> compatible, i.e. something like:
> compatible = "amd,XXXXXX", "jedec,a4-b7", "jedec-flash";
Good question. I think we want the separate bytes, if nothing
else then just for the benefit of drivers that have their own
table of those already. But the "compatible" thing also has
its merits of course. I'll ask some flash gurus about what's
special about JEDEC flash, and maybe even read a datasheet or
two. We're in no hurry right, CFI flash is lots more common
nowadays ;-)
>>>> One thing though -- what _exactly_ does "read-only" signify?
>>>
>>> That's... a good question.
>>
>> Yeah. It seems to me that the way it is currently used is
>> pure policy enforcement, which doesn't belong in the device
>> tree.
>
> Well.. not really policy enforcement, but a policy hint.
So it most likely doesn't belong there. How the OS userland
wants to mount those partitions, if at all, and if they even
contain a filesystem -- that's all its own business and belongs
in /etc/fstab or whatever the newfangled thing is.
On most flash chips, you can actually write-protect some
sectors; "read-only" sounds more like that. Although
"write-protected" would be a better name.
Or maybe "read-only" is useful and I just don't see why. In
that case, please figure out what its semantics are :-)
Segher
^ permalink raw reply
* Re: [PATCH 1/2] Xlinx ML403 AC97 Controller Reference device driver
From: Joachim Förster @ 2007-08-09 20:01 UTC (permalink / raw)
To: Grant Likely
Cc: Takashi Iwai, alsa-devel, Stephen Neuendorffer, Lorenz Kolb,
linuxppc-embedded@ozlabs.org
In-Reply-To: <fa686aa40708091049m46607037jafe4b479ae52db43@mail.gmail.com>
Hi Grant,
On Thu, 2007-08-09 at 11:49 -0600, Grant Likely wrote:
> > diff --git a/sound/ppc/Makefile b/sound/ppc/Makefile
> > index eacee2d..827f2f5 100644
> > --- a/sound/ppc/Makefile
> > +++ b/sound/ppc/Makefile
>
> Couldn't this end up on MicroBlaze too? If so, sound/ppc is the wrong place.
Well, I don't know. The only arch depended calls I use (am aware of) are
in/out_be32(), so this _might_ work for mb, too. (I won't be able to
test that in the next few months ...)
On Thu, 2007-08-09 at 11:17 -0700, Stephen Neuendorffer wrote:
> I second grant here... this should eventually work on microblaze, too,
> so putting it drivers/ and using XILINX_DRIVERS instead of XILINX_VIRTEX
> (based on the patch Wolfgang recently posted) would probably be preferable.
>
> > +
> > +config SND_ML403_AC97CR
> > + tristate "Xilinx ML403 AC97 Controller Reference"
> > + depends on SND && XILINX_VIRTEX
>
> Steve
So, like Stephen Neuendorffer said, I should move it to sound/drivers,
right? Takashi?
On Thu, 2007-08-09 at 11:49 -0600, Grant Likely wrote:
> > +snd-ml403_ac97cr-objs := ml403_ac97cr.o
>
> This line is only needed if you're compiling multiple .c files into one .ko
Ah, well, then I have to rename the main .c file. But all the other ALSA
drivers seem to _not_ include the "snd-" in front of it (ok, except the
new PS3 driver and maybe other new ones?)
> I'll try adding your patches to my tree this afternoon.
I made patch against your tree, too (like a said before). Tell me, then
I post it ...
Joachim
^ permalink raw reply
* Re: [PATCH 1/2] Xlinx ML403 AC97 Controller Reference device driver
From: Grant Likely @ 2007-08-09 20:07 UTC (permalink / raw)
To: Joachim Förster
Cc: Takashi Iwai, alsa-devel, Stephen Neuendorffer, Lorenz Kolb,
linuxppc-embedded@ozlabs.org
In-Reply-To: <1186689700.28843.76.camel@localhost>
On 8/9/07, Joachim F=F6rster <mls.JOFT@gmx.de> wrote:
> Hi Grant,
>
> On Thu, 2007-08-09 at 11:49 -0600, Grant Likely wrote:
> > > diff --git a/sound/ppc/Makefile b/sound/ppc/Makefile
> > > index eacee2d..827f2f5 100644
> > > --- a/sound/ppc/Makefile
> > > +++ b/sound/ppc/Makefile
> >
> > Couldn't this end up on MicroBlaze too? If so, sound/ppc is the wrong =
place.
>
> Well, I don't know. The only arch depended calls I use (am aware of) are
> in/out_be32(), so this _might_ work for mb, too. (I won't be able to
> test that in the next few months ...)
>
> On Thu, 2007-08-09 at 11:17 -0700, Stephen Neuendorffer wrote:
> > I second grant here... this should eventually work on microblaze, too,
> > so putting it drivers/ and using XILINX_DRIVERS instead of XILINX_VIRTE=
X
> > (based on the patch Wolfgang recently posted) would probably be prefera=
ble.
> >
> > > +
> > > +config SND_ML403_AC97CR
> > > + tristate "Xilinx ML403 AC97 Controller Reference"
> > > + depends on SND && XILINX_VIRTEX
> >
> > Steve
>
> So, like Stephen Neuendorffer said, I should move it to sound/drivers,
> right? Takashi?
>
>
> On Thu, 2007-08-09 at 11:49 -0600, Grant Likely wrote:
> > > +snd-ml403_ac97cr-objs :=3D ml403_ac97cr.o
> >
> > This line is only needed if you're compiling multiple .c files into one=
.ko
>
> Ah, well, then I have to rename the main .c file. But all the other ALSA
> drivers seem to _not_ include the "snd-" in front of it (ok, except the
> new PS3 driver and maybe other new ones?)
>
> > I'll try adding your patches to my tree this afternoon.
>
> I made patch against your tree, too (like a said before). Tell me, then
> I post it ...
No, don't base against my tree. You worry about mainline; I'll worry
about my tree. :-)
My tree gets rebased periodically anyway, so it's a much harder target.
>
> Joachim
>
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH v3 1/2] [POWERPC] MPC832x_RDB: update dts to use spi, register mmc_spi stub
From: Segher Boessenkool @ 2007-08-09 20:15 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070809030752.GB8261@localhost.localdomain>
> Hrm... Freescale is using these 'fsl,device-id' properties, I'm
> guessing they're basically the same thing as the 'cell-index' used in
> the EMAC binding.
>
> We should co-ordinate better on this, if it's to become a
> convention...
That means we shouldn't coordinate on this, right?
Segher
^ permalink raw reply
* Re: [PATCH v3 0/2] SPI support for fsl_soc and mpc832x_rdb
From: Segher Boessenkool @ 2007-08-09 20:21 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070808170728.GA21118@localhost.localdomain>
> - cosmetic cleanups (@01 -> @1);
That's a correctness fix, not just cosmetics.
> - other non-mandatory (device-id, device_type, compatible, ...)
> properties removed from mmc node, today board file is using
> of_find_node_by_name(), instead of of_find_compatible_node();
That's the wrong way around -- a driver (or platform code, same
thing) isn't using "compatible", while it should, so you remove
"compatible"?
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: fix i2c device string format
From: Guennadi Liakhovetski @ 2007-08-09 20:46 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <3368b27f860fafb35d10f6352e9055bf@kernel.crashing.org>
On Thu, 9 Aug 2007, Segher Boessenkool wrote:
> > > strncpy() won't put a terminating zero on there, is everything
> > > that uses the resulting string okay with that? Also, if the
> > > name gets cut short, it might match some _other_ expected name.
> >
> > On Wed, 1 Aug 2007, Scott Wood wrote:
> >
> > > You could use strlcpy() instead, which always leaves a zero terminator.
> >
> > The patch below does exactly this - uses strlcpy() to guarantee strings in
> > i2c device type and driver_name fields are 0-terminated.
>
> You're not checking the return values of these calls. This would
> be a good function to put attribute warn_unused_result on :-)
hm... Well, the worst that could happen, if an "evil" programmer defines
too long a name, it gets truncated, and then binds to a wrong driver,
well, the worst that can happen is that your hardware gets damaged, not a
big thing. However, some might disagree, so, below is a new version...
Wrap some long lines while at that.
Signed-off-by: G. Liakhovetski <g.liakhovetski@gmx.de>
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 727453d..c0d66df 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -320,21 +320,26 @@ static struct i2c_driver_device i2c_devices[] __initdata = {
{"ricoh,rv5c387a", "rtc-rs5c372", "rv5c387a",},
};
-static int __init of_find_i2c_driver(struct device_node *node, struct i2c_board_info *info)
+static int __init of_find_i2c_driver(struct device_node *node,
+ struct i2c_board_info *info)
{
int i;
for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) {
if (!of_device_is_compatible(node, i2c_devices[i].of_device))
continue;
- strncpy(info->driver_name, i2c_devices[i].i2c_driver, KOBJ_NAME_LEN);
- strncpy(info->type, i2c_devices[i].i2c_type, I2C_NAME_SIZE);
+ if (strlcpy(info->driver_name, i2c_devices[i].i2c_driver,
+ KOBJ_NAME_LEN) >= KOBJ_NAME_LEN ||
+ strlcpy(info->type, i2c_devices[i].i2c_type,
+ I2C_NAME_SIZE) >= I2C_NAME_SIZE)
+ return -ENOMEM;
return 0;
}
return -ENODEV;
}
-static void __init of_register_i2c_devices(struct device_node *adap_node, int bus_num)
+static void __init of_register_i2c_devices(struct device_node *adap_node,
+ int bus_num)
{
struct device_node *node = NULL;
^ permalink raw reply related
* [PATCH 6/6 v2] pseries: eliminate global var
From: Linas Vepstas @ 2007-08-09 20:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev, Nathan Lynch
In-Reply-To: <20070809010224.GE10114@localdomain>
Eliminate the use of error_log_cnt as a global var shared across
differnt directories. Pass it as a subroutine arg instead.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
Respin of earlier patch, with the CONFIG_PSERIES junk removed from the
header file.
arch/powerpc/kernel/nvram_64.c | 10 +++++-----
arch/powerpc/platforms/pseries/rtasd.c | 7 ++++---
include/asm-powerpc/nvram.h | 6 ++++--
3 files changed, 13 insertions(+), 10 deletions(-)
Index: linux-2.6.22-git2/arch/powerpc/kernel/nvram_64.c
===================================================================
--- linux-2.6.22-git2.orig/arch/powerpc/kernel/nvram_64.c 2007-08-08 12:21:16.000000000 -0500
+++ linux-2.6.22-git2/arch/powerpc/kernel/nvram_64.c 2007-08-08 12:24:01.000000000 -0500
@@ -38,8 +38,6 @@ static struct nvram_partition * nvram_pa
static long nvram_error_log_index = -1;
static long nvram_error_log_size = 0;
-extern volatile int error_log_cnt;
-
struct err_log_info {
int error_type;
unsigned int seq_num;
@@ -627,7 +625,8 @@ void __exit nvram_cleanup(void)
* sequence #: The unique sequence # for each event. (until it wraps)
* error log: The error log from event_scan
*/
-int nvram_write_error_log(char * buff, int length, unsigned int err_type)
+int nvram_write_error_log(char * buff, int length,
+ unsigned int err_type, unsigned int error_log_cnt)
{
int rc;
loff_t tmp_index;
@@ -665,7 +664,8 @@ int nvram_write_error_log(char * buff, i
*
* Reads nvram for error log for at most 'length'
*/
-int nvram_read_error_log(char * buff, int length, unsigned int * err_type)
+int nvram_read_error_log(char * buff, int length,
+ unsigned int * err_type, unsigned int * error_log_cnt)
{
int rc;
loff_t tmp_index;
@@ -691,7 +691,7 @@ int nvram_read_error_log(char * buff, in
return rc;
}
- error_log_cnt = info.seq_num;
+ *error_log_cnt = info.seq_num;
*err_type = info.error_type;
return 0;
Index: linux-2.6.22-git2/include/asm-powerpc/nvram.h
===================================================================
--- linux-2.6.22-git2.orig/include/asm-powerpc/nvram.h 2007-07-08 18:32:17.000000000 -0500
+++ linux-2.6.22-git2/include/asm-powerpc/nvram.h 2007-08-09 15:41:43.000000000 -0500
@@ -63,8 +63,10 @@ struct nvram_partition {
};
-extern int nvram_write_error_log(char * buff, int length, unsigned int err_type);
-extern int nvram_read_error_log(char * buff, int length, unsigned int * err_type);
+extern int nvram_write_error_log(char * buff, int length,
+ unsigned int err_type, unsigned int err_seq);
+extern int nvram_read_error_log(char * buff, int length,
+ unsigned int * err_type, unsigned int *err_seq);
extern int nvram_clear_error_log(void);
extern struct nvram_partition *nvram_find_partition(int sig, const char *name);
Index: linux-2.6.22-git2/arch/powerpc/platforms/pseries/rtasd.c
===================================================================
--- linux-2.6.22-git2.orig/arch/powerpc/platforms/pseries/rtasd.c 2007-08-08 12:21:16.000000000 -0500
+++ linux-2.6.22-git2/arch/powerpc/platforms/pseries/rtasd.c 2007-08-08 12:50:40.000000000 -0500
@@ -56,7 +56,7 @@ static int full_rtas_msgs = 0;
/* Stop logging to nvram after first fatal error */
static int no_more_logging;
-volatile int error_log_cnt = 0;
+static int error_log_cnt;
/*
* Since we use 32 bit RTAS, the physical address of this must be below
@@ -218,7 +218,7 @@ void pSeries_log_error(char *buf, unsign
/* Write error to NVRAM */
if (!no_more_logging && !(err_type & ERR_FLAG_BOOT))
- nvram_write_error_log(buf, len, err_type);
+ nvram_write_error_log(buf, len, err_type, error_log_cnt);
/*
* rtas errors can occur during boot, and we do want to capture
@@ -412,7 +412,8 @@ static int rtasd(void *unused)
/* See if we have any error stored in NVRAM */
memset(logdata, 0, rtas_error_log_max);
- rc = nvram_read_error_log(logdata, rtas_error_log_max, &err_type);
+ rc = nvram_read_error_log(logdata, rtas_error_log_max,
+ &err_type, &error_log_cnt);
if (!rc) {
if (err_type != ERR_FLAG_ALREADY_LOGGED) {
^ permalink raw reply
* [PATCH 1/6 v2] pseries: avoid excess rtas calls
From: Linas Vepstas @ 2007-08-09 21:01 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev, Nathan Lynch
In-Reply-To: <20070808222011.GG25995@austin.ibm.com>
We don't need to look up the rtas event token once per
cpu per second. This avoids some misc device-tree lookups
and string ops and so provides some minor performance
improvement.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
Revised commit-log message.
arch/powerpc/platforms/pseries/rtasd.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
Index: linux-2.6.22-git2/arch/powerpc/platforms/pseries/rtasd.c
===================================================================
--- linux-2.6.22-git2.orig/arch/powerpc/platforms/pseries/rtasd.c 2007-07-08 18:32:17.000000000 -0500
+++ linux-2.6.22-git2/arch/powerpc/platforms/pseries/rtasd.c 2007-08-07 17:57:13.000000000 -0500
@@ -44,10 +44,13 @@ static unsigned long rtas_log_start;
static unsigned long rtas_log_size;
static int surveillance_timeout = -1;
-static unsigned int rtas_event_scan_rate;
static unsigned int rtas_error_log_max;
static unsigned int rtas_error_log_buffer_max;
+/* RTAS service tokens */
+static unsigned int event_scan;
+static unsigned int rtas_event_scan_rate;
+
static int full_rtas_msgs = 0;
extern int no_logging;
@@ -381,7 +384,7 @@ static int get_eventscan_parms(void)
return 0;
}
-static void do_event_scan(int event_scan)
+static void do_event_scan(void)
{
int error;
do {
@@ -408,7 +411,7 @@ static void do_event_scan_all_cpus(long
cpu = first_cpu(cpu_online_map);
for (;;) {
set_cpus_allowed(current, cpumask_of_cpu(cpu));
- do_event_scan(rtas_token("event-scan"));
+ do_event_scan();
set_cpus_allowed(current, CPU_MASK_ALL);
/* Drop hotplug lock, and sleep for the specified delay */
@@ -426,12 +429,11 @@ static void do_event_scan_all_cpus(long
static int rtasd(void *unused)
{
unsigned int err_type;
- int event_scan = rtas_token("event-scan");
int rc;
daemonize("rtasd");
- if (event_scan == RTAS_UNKNOWN_SERVICE || get_eventscan_parms() == -1)
+ if (get_eventscan_parms() == -1)
goto error;
rtas_log_buf = vmalloc(rtas_error_log_buffer_max*LOG_NUMBER);
@@ -486,7 +488,8 @@ static int __init rtas_init(void)
return 0;
/* No RTAS */
- if (rtas_token("event-scan") == RTAS_UNKNOWN_SERVICE) {
+ event_scan = rtas_token("event-scan");
+ if (event_scan == RTAS_UNKNOWN_SERVICE) {
printk(KERN_DEBUG "rtasd: no event-scan on system\n");
return -ENODEV;
}
^ permalink raw reply
* Re: [RFC/PATCH] remove gratuitous reads from maple pci config space methods
From: Nathan Lynch @ 2007-08-09 21:24 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <40561246eaa06210a2a607aa7ed67b02@kernel.crashing.org>
Segher Boessenkool wrote:
> >>It might be worth checking that there isn't a particular reason for
> >>these. Just because posting writes are forbidden doesn't mean a
> >>particular bridge won't screw it up...
> >
> >Well, I had already checked with Ben, who wrote the code, and my
> >understanding is that the reads are intended to work around some
> >misbehaving Apple bridges,
>
> None of the PCI interfaces on the U3 or U4 bridges have that
> problem as far as I know. I think the workaround was copied
> from code for older Apple bridges?
Okay, then the change should be fine for maple.
> >but that a sync after the write (implied by
> >releasing pci_lock in the generic pci code) should suffice for those.
>
> I don't see how a sync could help here at all, not more than
> an eieio anyway?
Alright, well, maybe take it up with Ben when I post the patch for
powermac, since that's where it could actually matter.
^ permalink raw reply
* [PATCH] remove gratuitous reads from pasemi pci config space methods
From: Nathan Lynch @ 2007-08-09 21:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olof Johansson, Paul Mackerras
The pasemi pci configuration space write method reads the written
location immediately after the write is performed, presumably in order
to flush the write. However, configuration space writes are not
allowed to be posted, making these reads gratuitous. Furthermore,
this behavior potentially causes us to violate the PCI PM spec when
changing between e.g. D0 and D3 states, because a delay of up to 10ms
may be required before the OS accesses configuration space after the
write which initiates the transition.
Remove the unnecessary reads from pa_pxp_write_config.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/platforms/pasemi/pci.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/pasemi/pci.c b/arch/powerpc/platforms/pasemi/pci.c
index ab1f5f6..f7da373 100644
--- a/arch/powerpc/platforms/pasemi/pci.c
+++ b/arch/powerpc/platforms/pasemi/pci.c
@@ -107,15 +107,12 @@ static int pa_pxp_write_config(struct pci_bus *bus, unsigned int devfn,
switch (len) {
case 1:
out_8(addr, val);
- (void) in_8(addr);
break;
case 2:
out_le16(addr, val);
- (void) in_le16(addr);
break;
default:
out_le32(addr, val);
- (void) in_le32(addr);
break;
}
return PCIBIOS_SUCCESSFUL;
--
1.5.2.4
^ permalink raw reply related
* [PATCH] remove gratuitous reads from powermac pci config space methods
From: Nathan Lynch @ 2007-08-09 21:43 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
The powermac pci configuration space write methods read the written
location immediately after the write is performed, presumably in order
to flush the write. However, configuration space writes are not
allowed to be posted, making these reads gratuitous. Furthermore,
this behavior potentially causes us to violate the PCI PM spec when
changing between e.g. D0 and D3 states, because a delay of up to 10ms
may be required before the OS accesses configuration space after the
write which initiates the transition.
Remove the unnecessary reads from macrisc_write_config,
u3_ht_write_config, and u4_pcie_write_config.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/platforms/powermac/pci.c | 9 ---------
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/pci.c b/arch/powerpc/platforms/powermac/pci.c
index 92586db..bf1f5d1 100644
--- a/arch/powerpc/platforms/powermac/pci.c
+++ b/arch/powerpc/platforms/powermac/pci.c
@@ -209,15 +209,12 @@ static int macrisc_write_config(struct pci_bus *bus, unsigned int devfn,
switch (len) {
case 1:
out_8(addr, val);
- (void) in_8(addr);
break;
case 2:
out_le16(addr, val);
- (void) in_le16(addr);
break;
default:
out_le32(addr, val);
- (void) in_le32(addr);
break;
}
return PCIBIOS_SUCCESSFUL;
@@ -440,15 +437,12 @@ static int u3_ht_write_config(struct pci_bus *bus, unsigned int devfn,
switch (len) {
case 1:
out_8(addr, val);
- (void) in_8(addr);
break;
case 2:
out_le16(addr, val);
- (void) in_le16(addr);
break;
default:
out_le32((u32 __iomem *)addr, val);
- (void) in_le32(addr);
break;
}
return PCIBIOS_SUCCESSFUL;
@@ -545,15 +539,12 @@ static int u4_pcie_write_config(struct pci_bus *bus, unsigned int devfn,
switch (len) {
case 1:
out_8(addr, val);
- (void) in_8(addr);
break;
case 2:
out_le16(addr, val);
- (void) in_le16(addr);
break;
default:
out_le32(addr, val);
- (void) in_le32(addr);
break;
}
return PCIBIOS_SUCCESSFUL;
--
1.5.2.4
^ permalink raw reply related
* Re: [alsa-devel] [PATCH 1/2] Xlinx ML403 AC97 Controller Reference device driver
From: Takashi Iwai @ 2007-08-09 22:27 UTC (permalink / raw)
To: Joachim Förster
Cc: alsa-devel, Lorenz Kolb, linuxppc-embedded@ozlabs.org
In-Reply-To: <1186688686.28843.61.camel@localhost>
At Thu, 09 Aug 2007 21:44:46 +0200,
Joachim Förster wrote:
>
> Hi Takashi,
>
> before posting a corrected version, I would like to ask some unclear
> things (I think I understood the rest):
>
> On Thu, 2007-08-09 at 19:13 +0200, Takashi Iwai wrote:
> > (snip)
> > > +static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX;
> > > +static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR;
> > > +static int enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE;
> >
> > Can the driver really support multiple instances?
> > If not, better to avoid these arrays.
>
> Well, while I wrote the driver I considered that there might be more
> than one instance - though I didn't test it and I won't be able to test
> it (no such hardware available - with more than one LM4550 chip).
> So, shall I remove it?
It's up to you. If it makes the code easier and more maintenable,
it's worth to try.
> > > +struct lm4550_reg lm4550_regfile[64] = {
> > > + {.reg = 0x00,
> > > + .flag = LM4550_REG_NOSAVE | LM4550_REG_FAKEREAD,
> > > + .def = 0x0D50},
> >
> > Better to use C99 style initialization here, e.g.
> >
> > [0x00] = { .... },
> > [0x02] = { .... },
> > [0x7e] = { .... },
> >
> > so you can avoid writing empty items.
> > The index value could be also AC97_XXX, such as [AC97_MASTER] =
> > {...}.
> >
> > What is the purpose of reg field at all, BTW? I guess it's
> > superfluous.
>
> No, it's there to provide a shadow copy of the codec's (LM4550)
> registers.
That I understood too. My question was the reg _field_. It looks
like an index but it can be even easily calculated from the pointer
address...
> It contains default values and (while driver is running)
> current values, which were written to the hardware. I had to introduce
> this, because Xilinx's AC97 Controller Reference has a very ugly bug: It
> provides a "register access finish" bit, so the driver is able to tell
> when a register read or write access is finished. Unfortunately this
> particular bit only works in the range of 0 to 100 times since board
> reset. After that many register access it just remains saying: I'm _not_
> ready. But in fact, in most cases (98%) the correct value already is the
> read register (assume we have just said to the control that we want to
> read a register).
> I thought, ok we have such RegAccessFinished bit, so use it, if we have
> to, until it doesn't work anymore.
> So, through a shadow copy of most registers (some cannot be shadow or it
> makes no sence) I can provide the values without having to actually read
> from the controller/codec. The regfile also contains info which register
> might be shadowed, if values get saved at all (if written) ...
> Furthermore ALSA's AC97 layer does heavy initialization access series on
> the codec, which I tried to "mask out" completely
> (LM4550_REG_FAKEPROBE).
>
> > > +#define LM4550_RF_FLAG(reg) lm4550_regfile[reg / 2].flag
> <snip>
> > > +static void lm4550_regfile_init(void)
> > > +{
> > > + int i;
> > > + for (i = 0; i < 128; i = i + 2)
> > > + if (LM4550_RF_FLAG(i) & LM4550_REG_FAKEPROBE)
> > > + LM4550_RF_VAL(i) = LM4550_RF_DEF(i);
> >
> > "MACRO(x) = XXX" looks a bit strange to me.
>
> Hmmm, ok. I thought about that, too. I think, I'll spell them out?
>
> > RATE_CONTINUOUS and RATE_KNOW are usually exclusive.
>
> Ok, so what I want is RATE_CONTINUOUS, right? (because the LM4550
> supports 4000 to 48000kHz in 1Hz steps)
> BTW: What is RATE_KNOT good for?
It indicates unusual non-continuous sample rates that don't match with
SNDRV_PCM_RATE_XXX bits are supported. The rates in 1Hz step is
continuous enough :)
Takashi
^ permalink raw reply
* Re: [PATCH 1/2] Xlinx ML403 AC97 Controller Reference device driver
From: Takashi Iwai @ 2007-08-09 22:30 UTC (permalink / raw)
To: Joachim Förster
Cc: alsa-devel, Stephen Neuendorffer, Lorenz Kolb,
linuxppc-embedded@ozlabs.org
In-Reply-To: <1186689700.28843.76.camel@localhost>
At Thu, 09 Aug 2007 22:01:40 +0200,
Joachim Förster wrote:
>
> Hi Grant,
>
> On Thu, 2007-08-09 at 11:49 -0600, Grant Likely wrote:
> > > diff --git a/sound/ppc/Makefile b/sound/ppc/Makefile
> > > index eacee2d..827f2f5 100644
> > > --- a/sound/ppc/Makefile
> > > +++ b/sound/ppc/Makefile
> >
> > Couldn't this end up on MicroBlaze too? If so, sound/ppc is the wrong place.
>
> Well, I don't know. The only arch depended calls I use (am aware of) are
> in/out_be32(), so this _might_ work for mb, too. (I won't be able to
> test that in the next few months ...)
>
> On Thu, 2007-08-09 at 11:17 -0700, Stephen Neuendorffer wrote:
> > I second grant here... this should eventually work on microblaze, too,
> > so putting it drivers/ and using XILINX_DRIVERS instead of XILINX_VIRTEX
> > (based on the patch Wolfgang recently posted) would probably be preferable.
> >
> > > +
> > > +config SND_ML403_AC97CR
> > > + tristate "Xilinx ML403 AC97 Controller Reference"
> > > + depends on SND && XILINX_VIRTEX
> >
> > Steve
>
> So, like Stephen Neuendorffer said, I should move it to sound/drivers,
> right? Takashi?
Well, yes, drivers appears like a more reasonable place.
> On Thu, 2007-08-09 at 11:49 -0600, Grant Likely wrote:
> > > +snd-ml403_ac97cr-objs := ml403_ac97cr.o
> >
> > This line is only needed if you're compiling multiple .c files into one .ko
>
> Ah, well, then I have to rename the main .c file. But all the other ALSA
> drivers seem to _not_ include the "snd-" in front of it (ok, except the
> new PS3 driver and maybe other new ones?)
Right. I prefer the file name should be without prefix, too.
The snd- prefix came from a historical reason, to avoid the name crash
with OSS drivers.
Takashi
^ 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