* [PATCH] [POWERPC] iSeries: fix sparse warnings in setup.c
From: Stephen Rothwell @ 2007-11-19 6:10 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
arch/powerpc/platforms/iseries/setup.c:111:27: warning: constant 0x100000000 is so big it is long
arch/powerpc/platforms/iseries/setup.c:113:23: warning: constant 0x100000000 is so big it is long
arch/powerpc/platforms/iseries/setup.c:117:27: warning: constant 0x000fffffffffffff is so big it is long
arch/powerpc/platforms/iseries/setup.c:127:28: warning: constant 0x100000000 is so big it is long
arch/powerpc/platforms/iseries/setup.c:129:24: warning: constant 0x100000000 is so big it is long
arch/powerpc/platforms/iseries/setup.c:233:5: warning: constant 0x000fffffffffffff is so big it is long
arch/powerpc/platforms/iseries/setup.c:235:5: warning: constant 0x000fffffffffffff is so big it is long
arch/powerpc/platforms/iseries/setup.c:319:6: warning: symbol 'mschunks_alloc' was not declared. Should it be static?
arch/powerpc/platforms/iseries/setup.c:661:6: warning: symbol 'iSeries_early_setup' was not declared. Should it be static?
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/setup.c | 16 ++++++++--------
arch/powerpc/platforms/iseries/setup.h | 1 +
2 files changed, 9 insertions(+), 8 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/platforms/iseries/setup.c b/arch/powerpc/platforms/iseries/setup.c
index 8a652da..2175a71 100644
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -108,13 +108,13 @@ static unsigned long iSeries_process_Condor_mainstore_vpd(
* correctly.
*/
mb_array[0].logicalStart = 0;
- mb_array[0].logicalEnd = 0x100000000;
+ mb_array[0].logicalEnd = 0x100000000UL;
mb_array[0].absStart = 0;
- mb_array[0].absEnd = 0x100000000;
+ mb_array[0].absEnd = 0x100000000UL;
if (holeSize) {
numMemoryBlocks = 2;
- holeStart = holeStart & 0x000fffffffffffff;
+ holeStart = holeStart & 0x000fffffffffffffUL;
holeStart = addr_to_chunk(holeStart);
holeFirstChunk = holeStart;
holeSize = addr_to_chunk(holeSize);
@@ -124,9 +124,9 @@ static unsigned long iSeries_process_Condor_mainstore_vpd(
mb_array[0].logicalEnd = holeFirstChunk;
mb_array[0].absEnd = holeFirstChunk;
mb_array[1].logicalStart = holeFirstChunk;
- mb_array[1].logicalEnd = 0x100000000 - holeSizeChunks;
+ mb_array[1].logicalEnd = 0x100000000UL - holeSizeChunks;
mb_array[1].absStart = holeFirstChunk + holeSizeChunks;
- mb_array[1].absEnd = 0x100000000;
+ mb_array[1].absEnd = 0x100000000UL;
}
return numMemoryBlocks;
}
@@ -230,9 +230,9 @@ static unsigned long iSeries_process_Regatta_mainstore_vpd(
mb_array[i].logicalEnd,
mb_array[i].absStart, mb_array[i].absEnd);
mb_array[i].absStart = addr_to_chunk(mb_array[i].absStart &
- 0x000fffffffffffff);
+ 0x000fffffffffffffUL);
mb_array[i].absEnd = addr_to_chunk(mb_array[i].absEnd &
- 0x000fffffffffffff);
+ 0x000fffffffffffffUL);
mb_array[i].logicalStart =
addr_to_chunk(mb_array[i].logicalStart);
mb_array[i].logicalEnd = addr_to_chunk(mb_array[i].logicalEnd);
@@ -316,7 +316,7 @@ struct mschunks_map mschunks_map = {
};
EXPORT_SYMBOL(mschunks_map);
-void mschunks_alloc(unsigned long num_chunks)
+static void mschunks_alloc(unsigned long num_chunks)
{
klimit = _ALIGN(klimit, sizeof(u32));
mschunks_map.mapping = (u32 *)klimit;
diff --git a/arch/powerpc/platforms/iseries/setup.h b/arch/powerpc/platforms/iseries/setup.h
index 0a47ac5..729754b 100644
--- a/arch/powerpc/platforms/iseries/setup.h
+++ b/arch/powerpc/platforms/iseries/setup.h
@@ -17,6 +17,7 @@
#ifndef __ISERIES_SETUP_H__
#define __ISERIES_SETUP_H__
+extern void *iSeries_early_setup(void);
extern unsigned long iSeries_get_boot_time(void);
extern int iSeries_set_rtc_time(struct rtc_time *tm);
extern void iSeries_get_rtc_time(struct rtc_time *tm);
--
1.5.3.5
^ permalink raw reply related
* [PATCH] [POWERPC] iSeries: declare iSeries_pci_final_fixup in pci.h
From: Stephen Rothwell @ 2007-11-19 6:06 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Fixes sparse warning:
arch/powerpc/platforms/iseries/pci.c:169:13: warning: symbol 'iSeries_pci_final_fixup' was not declared. Should it be static?
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/pci.h | 5 +++++
arch/powerpc/platforms/iseries/setup.c | 6 +-----
2 files changed, 6 insertions(+), 5 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/platforms/iseries/pci.h b/arch/powerpc/platforms/iseries/pci.h
index 33a8489..730986b 100644
--- a/arch/powerpc/platforms/iseries/pci.h
+++ b/arch/powerpc/platforms/iseries/pci.h
@@ -59,5 +59,10 @@ static inline u64 iseries_ds_addr(struct device_node *node)
}
extern void iSeries_Device_Information(struct pci_dev*, int);
+#ifdef CONFIG_PCI
+extern void iSeries_pci_final_fixup(void);
+#else
+static void iSeries_pci_final_fixup(void) { }
+#endif
#endif /* _PLATFORMS_ISERIES_PCI_H */
diff --git a/arch/powerpc/platforms/iseries/setup.c b/arch/powerpc/platforms/iseries/setup.c
index 0877a88..8a652da 100644
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -63,6 +63,7 @@
#include "main_store.h"
#include "call_sm.h"
#include "call_hpt.h"
+#include "pci.h"
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
@@ -74,11 +75,6 @@
static unsigned long build_iSeries_Memory_Map(void);
static void iseries_shared_idle(void);
static void iseries_dedicated_idle(void);
-#ifdef CONFIG_PCI
-extern void iSeries_pci_final_fixup(void);
-#else
-static void iSeries_pci_final_fixup(void) { }
-#endif
struct MemoryBlock {
--
1.5.3.5
^ permalink raw reply related
* [PATCH] [POWERPC] iSeries: mark two functions __init
From: Stephen Rothwell @ 2007-11-19 6:03 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/pci.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/platforms/iseries/pci.c b/arch/powerpc/platforms/iseries/pci.c
index da87162..a74d1e1 100644
--- a/arch/powerpc/platforms/iseries/pci.c
+++ b/arch/powerpc/platforms/iseries/pci.c
@@ -87,7 +87,7 @@ static DEFINE_SPINLOCK(iomm_table_lock);
* - CurrentIndex is incremented to keep track of the last entry.
* - Builds the resource entry for allocated BARs.
*/
-static void iomm_table_allocate_entry(struct pci_dev *dev, int bar_num)
+static void __init iomm_table_allocate_entry(struct pci_dev *dev, int bar_num)
{
struct resource *bar_res = &dev->resource[bar_num];
long bar_size = pci_resource_len(dev, bar_num);
@@ -130,7 +130,7 @@ static void iomm_table_allocate_entry(struct pci_dev *dev, int bar_num)
* - Loops through The Bar resources(0 - 5) including the ROM
* is resource(6).
*/
-static void allocate_device_bars(struct pci_dev *dev)
+static void __init allocate_device_bars(struct pci_dev *dev)
{
int bar_num;
--
1.5.3.5
^ permalink raw reply related
* [PATCH] [POWERPC] make global_phb_number static
From: Stephen Rothwell @ 2007-11-19 5:56 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/pci-common.c | 2 +-
include/asm-powerpc/ppc-pci.h | 1 -
2 files changed, 1 insertions(+), 2 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 0d89350..252dd1e 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -48,7 +48,7 @@
static DEFINE_SPINLOCK(hose_spinlock);
/* XXX kill that some day ... */
-int global_phb_number; /* Global phb counter */
+static int global_phb_number; /* Global phb counter */
/* ISA Memory physical address (or 0 if none) */
resource_size_t isa_mem_base = 0;
diff --git a/include/asm-powerpc/ppc-pci.h b/include/asm-powerpc/ppc-pci.h
index d41645e..854ab71 100644
--- a/include/asm-powerpc/ppc-pci.h
+++ b/include/asm-powerpc/ppc-pci.h
@@ -22,7 +22,6 @@ extern void pci_setup_phb_io_dynamic(struct pci_controller *hose, int primary);
extern struct list_head hose_list;
-extern int global_phb_number;
extern void find_and_init_phbs(void);
--
1.5.3.5
^ permalink raw reply related
* Re: MPC880: i2cer register says tx is done but tx buf descriptor is still ready
From: Ankur Maheshwari @ 2007-11-19 5:52 UTC (permalink / raw)
To: DI BACCO ANTONIO - technolabs; +Cc: linuxppc-embedded
In-Reply-To: <F1F6EC0C8B75034F9E3A79FC85122E8E2649F4@aquib01a>
Hi Antonio,
Check how is your tx_buf is allocated, if its 2.4 kernel , then try
allocating using following function
tx_buf = (u_char *)m8xx_cpm_hostalloc(512);
512 is the size, also dump and check the difference in start address.
I more recommendation, check how your Serial/Network driver has
allocated memory, try using same method.
thanks,
Ankur
DI BACCO ANTONIO - technolabs wrote:
>
> A porting of the driver included in kernel 2.4.
>
> Here is an excerpt of the method to send bytes over the i2c bus:
> ________________________________________________________________________
> i2c->i2c_i2cmr = 0x00; /* Disable I2C interupts */
> i2c->i2c_i2cer = 0xff;
> i2c->i2c_i2mod |= 1; /* Enable */
> i2c->i2c_i2com |= 0x80; /* Begin transmission */
> tmo = jiffies + 1*HZ;
> /* Busy wait, with a timeout */
> while(!(i2c->i2c_i2cer & 0x12 || time_after(jiffies, tmo)));
>
>
> if (signal_pending(current) || !tmo){
> force_close(algo_8xx_data);
> if (!tmo)
> printk("IIC write: timeout!\n");
>
> return -EIO;
> }
>
> if ((tbdf[0]->cbd_sc | tbdf[1]->cbd_sc) & BD_SC_NAK) {
> printk(KERN_INFO "IIC write; no ack\n");
> if (cpm_debug > 0)
> printk("tx0 sc %04x, tx1 sc %04x\n",
> tbdf[0]->cbd_sc,tbdf[1]->cbd_sc);
>
> return 0;
> }
>
> if ((tbdf[0]->cbd_sc | tbdf[1]->cbd_sc) & BD_SC_READY) {
> printk(KERN_INFO "IIC write; complete but tbuf ready\n");
> if (cpm_debug > 0)
> printk("tx0 sc %04x, tx1 sc %04x\n",
> tbdf[0]->cbd_sc,tbdf[1]->cbd_sc);
>
> return 0;
> }
>
>
> -----Original Message-----
> From: Jochen Friedrich [mailto:jochen@scram.de]
> Sent: Sat 17/11/2007 19.32
> To: DI BACCO ANTONIO - technolabs
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: MPC880: i2cer register says tx is done but tx buf
> descriptor is still ready
>
> Hi Antonio,
>
> > How could it be possible? It happens during the first i2c transactions
> > and then no more.
> >
>
> What linux version? Which driver?
>
> Thanks,
> Jochen
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH v2] [POWERPC] vdso: Fixes for cache block sizes
From: Olof Johansson @ 2007-11-19 4:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: dwmw2, linuxppc-dev
In-Reply-To: <18241.3066.346441.180033@cargo.ozlabs.ibm.com>
On Mon, Nov 19, 2007 at 03:07:22PM +1100, Paul Mackerras wrote:
> Olof Johansson writes:
>
> > [POWERPC] vdso: Fixes for cache line sizes
> >
> > Current VDSO implementation is hardcoded to 128 byte cache blocks,
> > which are only used on IBM's 64-bit processors.
> >
> > Convert it to get the blocks sizes out of vdso_data instead, similar
> > to how the ppc64 in-kernel cache flush does it.
>
> OK, but you have removed a "crclr cr0*4+so" instruction in a couple of
> places. They are there so that the functions follow the convention
> for system calls, where cr0.SO set on return indicates an error, and
> clear indicates no error. Was there any special reason why you
> removed them? If not, please put them back (after the last cmp or
> dot-form instruction).
Good catch. They must have fallen off when I copied over the in-kernel
versions. I'll repost tomorrow.
Thanks,
-Olof
^ permalink raw reply
* Re: [PATCH v2] [POWERPC] vdso: Fixes for cache block sizes
From: Paul Mackerras @ 2007-11-19 4:07 UTC (permalink / raw)
To: Olof Johansson; +Cc: dwmw2, linuxppc-dev
In-Reply-To: <20071114212823.GA3044@lixom.net>
Olof Johansson writes:
> [POWERPC] vdso: Fixes for cache line sizes
>
> Current VDSO implementation is hardcoded to 128 byte cache blocks,
> which are only used on IBM's 64-bit processors.
>
> Convert it to get the blocks sizes out of vdso_data instead, similar
> to how the ppc64 in-kernel cache flush does it.
OK, but you have removed a "crclr cr0*4+so" instruction in a couple of
places. They are there so that the functions follow the convention
for system calls, where cr0.SO set on return indicates an error, and
clear indicates no error. Was there any special reason why you
removed them? If not, please put them back (after the last cmp or
dot-form instruction).
Paul.
^ permalink raw reply
* Re: [PATCH] 2.6.24-rc2-mm1 powerpc (iseries)- build failure - mm/stab.c
From: Stephen Rothwell @ 2007-11-19 2:38 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, akpm, anton, paulus, linux-kernel
In-Reply-To: <20071114105410.GA16846@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 427 bytes --]
Hi Kamalesh,
On Wed, 14 Nov 2007 16:24:10 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
> +#ifdef CONFIG_PPC_ISERIES
> +#include <asm/iseries/hv_call.h>
> +#endif /* CONFIG_PPC_ISERIES */
You should not need the #ifdef and we prefer not to ifdef include unless
necessary. Please resubmit.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix buglets in mpc5200 FEC code that are corrupting memory.
From: Jon Smirl @ 2007-11-19 1:49 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list, Jeff Garzik, Domen Puncer, netdev
In-Reply-To: <fa686aa40711090557u1b6cb29ex388b82efcbad7c18@mail.gmail.com>
On 11/9/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 11/9/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> > On 09/11/07 00:31 -0500, Jon Smirl wrote:
> > > This is the reason I couldn't get user space started or connect to my
> > > nfs server. Patch is against current linus git.
> > >
> > > mpc5200 fec driver is corrupting memory. This patch fixes two bugs
> > > where the wrong skb buffer was being referenced.
> > >
> > > Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
> >
> > Acked-by: Domen Puncer <domen.puncer@telargo.com>
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>
> Jeff, can you please pick this up for .24?
This is didn't make it into rc3. Without this patch this driver is broken.
>
> Thanks,
> g.
>
> >
> > I can't test it at the moment, but the patch is obviously correct,
> > mapped buffer should be the _same_ as submitted.
> >
> > >
> > > ---
> > >
> > > drivers/net/fec_mpc52xx.c | 4 ++--
> > > 1 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > >
> > > diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
> > > index a8a0ee2..ddfcc0b 100644
> > > --- a/drivers/net/fec_mpc52xx.c
> > > +++ b/drivers/net/fec_mpc52xx.c
> > > @@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> > > irq, void *dev_id)
> > >
> > > rskb =3D bcom_retrieve_buffer(priv->rx_dmatsk, &status,
> > > (struct bcom_bd **)&bd);
> > > - dma_unmap_single(&dev->dev, bd->skb_pa, skb->len, DMA_F=
ROM_DEVICE);
> > > + dma_unmap_single(&dev->dev, bd->skb_pa, rskb->len, DMA_=
FROM_DEVICE);
> > >
> > > /* Test for errors in received frame */
> > > if (status & BCOM_FEC_RX_BD_ERRORS) {
> > > @@ -467,7 +467,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> > > irq, void *dev_id)
> > > bcom_prepare_next_buffer(priv->rx_dmatsk);
> > >
> > > bd->status =3D FEC_RX_BUFFER_SIZE;
> > > - bd->skb_pa =3D dma_map_single(&dev->dev, rskb->data,
> > > + bd->skb_pa =3D dma_map_single(&dev->dev, skb->data,
> > > FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
> > >
> > > bcom_submit_next_buffer(priv->rx_dmatsk, skb);
> > >
> > >
> > > --
> > > Jon Smirl
> > > jonsmirl@gmail.com
> >
> > --
> > Domen Puncer | Research & Development
> > .......................................................................=
......................
> > Telargo d.o.o. | Zagreb=9Aka cesta 20 | 2000 Maribor | Slovenia
> > .......................................................................=
......................
> > www.telargo.com
> >
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-19 0:22 UTC (permalink / raw)
To: Matt Sealey, PowerPC dev list
In-Reply-To: <20071119001209.GD20794@localhost.localdomain>
On 11/18/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Sun, Nov 18, 2007 at 11:31:13PM +0000, Matt Sealey wrote:
> > Matt Sealey wrote:
> > > Jon Smirl wrote:
> > >
> > > If you require the codec to be subservient to some "fabric" then I
> > > suggest you make a "sound" node with a compatible entry which is
> > > defined as something specific to your board (digispeaker,audio) and
> > > let your driver pick that up and then switch on the model (rather like
> > > Apple's layout-id) of that device to pick out the specifics of that
> > > fabric. If it needs an audio codec (ac97 or i2s) and a control
> > > interface (i2c or spi) then it knows which ones it is looking for
> > > based on the model.
> >
> > Sigh, I suck, I forgot the example :D
> >
> > And I forgot the rant you guys usually get - for god's sake, why isn't
> > anyone using the "model" property? Do I have to whine about this some
> > more to get your attention, guys? name, device_type, compatible and
> > model are your tools for building device trees and detecting
> > things. That's FOUR unique properties.
> >
> > How come I only see device trees defined using "name", with the same
> > device_type, and "compatible"? This is braindead design.
>
> Gah! For the benefit of others on this list who may be misled.
>
> *Neither* of you correctly understands the device tree, what I've seen
> of *both* your suggested approaches is crap.
I'm awaiting guidance on how to do the device tree. I just want to
figure out some way of getting my drivers loaded. I make no claim to
having any expertise in device tree design.
There are two classes of codecs, ones where control/data is combined
and one where they are separate. Common examples - combined: ac97, hda
- separate i2s + i2c. Then there is this fabric stuff which glues a
generic codec driver into a specific board layout. While a generic
AC97 design may not need a fabric driver, most other designs need it.
If someone were to put an example into the Docmentation file, I'd follow it.
>
> The device tree describes the _hardware_. If you start reasoning
> about how to lay out the device tree based on your driver model,
> you're already wrong.
>
> Matt, the various properties you list do not mean what you think they
> mean.
>
> name - should be named according to the generic names convention.
> It's pretty much arbitrary, meant for human readability of the device
> tree. Drivers should not depend on it (some do, historically, but new
> drivers and trees should not).
>
> device_type - indicates the open firmware method interface for the
> device. Therefore, meaningless in flattened trees. No new driver
> should use this.
>
> compatible - *this* is the one for driver selection. It describes the
> hardware level interface(s) of the device.
>
> model - usually just for debugging / diagnosis / human-readable
> purposes, describes exact model / revision of the hardware. It can be
> used to enable driver quirks / workarounds for when various devices
> are supposed to be compatible (as encoded in 'compatible') but
> aren't, due to hardware bugs. However, you should never aim to use it
> this way in design.
>
> --
> David Gibson | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: David Gibson @ 2007-11-19 0:12 UTC (permalink / raw)
To: Matt Sealey; +Cc: PowerPC dev list
In-Reply-To: <4740CB41.8030101@genesi-usa.com>
On Sun, Nov 18, 2007 at 11:31:13PM +0000, Matt Sealey wrote:
> Matt Sealey wrote:
> > Jon Smirl wrote:
> >
> > If you require the codec to be subservient to some "fabric" then I
> > suggest you make a "sound" node with a compatible entry which is
> > defined as something specific to your board (digispeaker,audio) and
> > let your driver pick that up and then switch on the model (rather like
> > Apple's layout-id) of that device to pick out the specifics of that
> > fabric. If it needs an audio codec (ac97 or i2s) and a control
> > interface (i2c or spi) then it knows which ones it is looking for
> > based on the model.
>
> Sigh, I suck, I forgot the example :D
>
> And I forgot the rant you guys usually get - for god's sake, why isn't
> anyone using the "model" property? Do I have to whine about this some
> more to get your attention, guys? name, device_type, compatible and
> model are your tools for building device trees and detecting
> things. That's FOUR unique properties.
>
> How come I only see device trees defined using "name", with the same
> device_type, and "compatible"? This is braindead design.
Gah! For the benefit of others on this list who may be misled.
*Neither* of you correctly understands the device tree, what I've seen
of *both* your suggested approaches is crap.
The device tree describes the _hardware_. If you start reasoning
about how to lay out the device tree based on your driver model,
you're already wrong.
Matt, the various properties you list do not mean what you think they
mean.
name - should be named according to the generic names convention.
It's pretty much arbitrary, meant for human readability of the device
tree. Drivers should not depend on it (some do, historically, but new
drivers and trees should not).
device_type - indicates the open firmware method interface for the
device. Therefore, meaningless in flattened trees. No new driver
should use this.
compatible - *this* is the one for driver selection. It describes the
hardware level interface(s) of the device.
model - usually just for debugging / diagnosis / human-readable
purposes, describes exact model / revision of the hardware. It can be
used to enable driver quirks / workarounds for when various devices
are supposed to be compatible (as encoded in 'compatible') but
aren't, due to hardware bugs. However, you should never aim to use it
this way in design.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-18 23:47 UTC (permalink / raw)
To: Matt Sealey; +Cc: PowerPC dev list
In-Reply-To: <4740CB41.8030101@genesi-usa.com>
On 11/18/07, Matt Sealey <matt@genesi-usa.com> wrote:
> I'd suggest something like this:
>
> sound@0 {
> \\ this is our magic audio fabric
> device_type = "digispeaker,flinger";
>
> \\ it's actually just an i2s pcm codec
> compatible = "mpc5200-psc-i2s";
>
> \\ and this defines the layout Jon picked for the DACs
> \\ just like Apple's layout-id value
> model = "flinger,2"
>
> codec@15 {
> compatible = "TXN,tas5504";
> codec-control = <&codec-control>;
> }
>
> \\ and every i2s driver on the planet will just ignore these
> \\ unless it's one of our boards
> digispeaker,amp-control = <&-control>
> }
This forces a single fabric driver for audio buses that can support
more than one device (like ac97). I can live with that, but is it ok
for the design?
> Then you control the fabric for your boards and get to attach
> whatever the hell you want to those codecs, control interfaces
> and special little tweak features you always wanted.
>
> Be careful cross-referencing devices with each other,
> for instance in your example you made the i2c codec device
> point back to an i2s handle - it's a good idea, but not well
> executed in my opinion as it lacks context.
>
> Isn't the primary concern of an audio codec, to play audio?
>
> Therefore, shouldn't the audio codec point back to it's control
> interface? Also, why give the name as 'i2s-handle'? Surely it
> could be any interface. In reverse, it would be, perhaps, as
> above, i2c-handle, but then what if you change the interface
> type (for instance a bunch of Wolfson codecs can do i2c and
> spi for control). Your property name is obselete, then and
> drivers will need to switch on property names to find out
> which control interface is present.
Others have pointed out that device trees are organized by control
interface. So the codec node should be under i2c and back point to
their data stream. We could use something like codec-data instead of
i2s-handle.
I don't have a strong opinion on how to organize this stuff. I just
need some way to get the ASOC fabric drivers loaded. Actually ASOC
calls them 'machine' drivers, it is Apple's audio code that call them
fabric drivers.
>
> What they should really do, is be told where their control
> interface handle is, then you can look at that handle and
> the device it contains - that device itself will tell you the
> bus type, any devices under it, and any quirky things you
> need to do besides (above, &codec-control etc. would point to
>
> i2c@3d40 {
> codec-control@15 {
> blah
> }
> }
>
> spi@beef {
> codec-control@19 {
> blah
> }
> }
>
> gpio@cafe {
> amp-control@0 {
> compatible = "gpio-bit";
> bit = "1";
> open-drain;
> }
> }
>
> If you couldn't tell it's a device on an i2c bus then you
> are coding your driver badly. And you can have lots of
> codecs, and just back reference which control interface
> they have. I dunno.
>
> Remember, it doesn't matter what NAME you give it, the name
> is for people to read, device_type is what you search for,
> and phandles let you attach specific devices to each other.
> compatible is for when you want to tell people "it acts the
> same as this" and model is to give you the enviable ability
> to define PRECISELY what you are looking at beyond a chip
> name. I'd suggest we use all of them for great justice.
>
> --
> Matt Sealey <matt@genesi-usa.com>
> Genesi, Manager, Developer Relations
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Matt Sealey @ 2007-11-18 23:31 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <4740C0E3.5080704@genesi-usa.com>
Matt Sealey wrote:
> Jon Smirl wrote:
>
> If you require the codec to be subservient to some "fabric" then I
> suggest you make a "sound" node with a compatible entry which is
> defined as something specific to your board (digispeaker,audio) and
> let your driver pick that up and then switch on the model (rather like
> Apple's layout-id) of that device to pick out the specifics of that
> fabric. If it needs an audio codec (ac97 or i2s) and a control
> interface (i2c or spi) then it knows which ones it is looking for
> based on the model.
Sigh, I suck, I forgot the example :D
And I forgot the rant you guys usually get - for god's sake, why isn't
anyone using the "model" property? Do I have to whine about this some
more to get your attention, guys? name, device_type, compatible and
model are your tools for building device trees and detecting
things. That's FOUR unique properties.
How come I only see device trees defined using "name", with the same
device_type, and "compatible"? This is braindead design.
Why is every example device tree I see defining weird little extra
nodes for anything and everything that some driver API exposes? If
you want to expose a grand new kind of driver fabric like ALSA SoC
wants, put your codec in the tree, and give it a model property
with your unique name.
I'd suggest something like this:
sound@0 {
\\ this is our magic audio fabric
device_type = "digispeaker,flinger";
\\ it's actually just an i2s pcm codec
compatible = "mpc5200-psc-i2s";
\\ and this defines the layout Jon picked for the DACs
\\ just like Apple's layout-id value
model = "flinger,2"
codec@15 {
compatible = "TXN,tas5504";
codec-control = <&codec-control>;
}
\\ and every i2s driver on the planet will just ignore these
\\ unless it's one of our boards
digispeaker,amp-control = <&-control>
}
Then you control the fabric for your boards and get to attach
whatever the hell you want to those codecs, control interfaces
and special little tweak features you always wanted.
Be careful cross-referencing devices with each other,
for instance in your example you made the i2c codec device
point back to an i2s handle - it's a good idea, but not well
executed in my opinion as it lacks context.
Isn't the primary concern of an audio codec, to play audio?
Therefore, shouldn't the audio codec point back to it's control
interface? Also, why give the name as 'i2s-handle'? Surely it
could be any interface. In reverse, it would be, perhaps, as
above, i2c-handle, but then what if you change the interface
type (for instance a bunch of Wolfson codecs can do i2c and
spi for control). Your property name is obselete, then and
drivers will need to switch on property names to find out
which control interface is present.
What they should really do, is be told where their control
interface handle is, then you can look at that handle and
the device it contains - that device itself will tell you the
bus type, any devices under it, and any quirky things you
need to do besides (above, &codec-control etc. would point to
i2c@3d40 {
codec-control@15 {
blah
}
}
spi@beef {
codec-control@19 {
blah
}
}
gpio@cafe {
amp-control@0 {
compatible = "gpio-bit";
bit = "1";
open-drain;
}
}
If you couldn't tell it's a device on an i2c bus then you
are coding your driver badly. And you can have lots of
codecs, and just back reference which control interface
they have. I dunno.
Remember, it doesn't matter what NAME you give it, the name
is for people to read, device_type is what you search for,
and phandles let you attach specific devices to each other.
compatible is for when you want to tell people "it acts the
same as this" and model is to give you the enviable ability
to define PRECISELY what you are looking at beyond a chip
name. I'd suggest we use all of them for great justice.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* 2.6.24-rc3: High CPU load -- hardware interrupts
From: Jörg Sommer @ 2007-11-18 21:53 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I've installed the new kernel version and now suspend to RAM works. But I
saw that the CPU load is everytime 50% due to hardware interrupts. Is
this a known bug?
top - 22:51:19 up 21:58, 8 users, load average: 0.36, 0.39, 0.40
Tasks: 66 total, 4 running, 62 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.7%us, 0.5%sy, 11.2%ni, 27.0%id, 0.0%wa, 60.6%hi, 0.0%si, 0.0%st
% diff <(cat /proc/interrupts) <(sleep 2; cat /proc/interrupts)
--- /proc/self/fd/11 2007-11-18 13:02:25.204839099 +0100
+++ /proc/self/fd/13 2007-11-18 13:02:25.228832847 +0100
@@ -1,16 +1,16 @@
CPU0
21: 1 MPIC 1 Edge PMac Output
24: 68 MPIC 1 Level ide1
- 25: 1337463 MPIC 1 Level VIA-PMU
+ 25: 1337690 MPIC 1 Level VIA-PMU
26: 378 MPIC 1 Level keywest i2c
29: 1 MPIC 1 Level ohci_hcd:usb2
30: 1 MPIC 1 Edge PMac Input
39: 249347 MPIC 1 Level ide0
40: 3 MPIC 1 Level ohci1394
41: 3454 MPIC 1 Level eth0
- 42: 30782 MPIC 1 Level keywest i2c
- 47: 22021 MPIC 1 Level GPIO1 ADB
- 48: 23892 MPIC 1 Level radeon@pci:0000:00:10.0
+ 42: 30800 MPIC 1 Level keywest i2c
+ 47: 22049 MPIC 1 Level GPIO1 ADB
+ 48: 24014 MPIC 1 Level radeon@pci:0000:00:10.0
61: 0 MPIC 1 Edge Sound Headphone Detection
63: 94237 MPIC 1 Level ehci_hcd:usb1, ohci_hcd:usb3, ohci_hcd:usb4
BAD: 0
% cat /proc/cpuinfo
processor : 0
cpu : 7455, altivec supported
clock : 798.720000MHz
revision : 0.3 (pvr 8001 0303)
bogomips : 48.41
timebase : 18432000
platform : PowerMac
machine : PowerBook6,3
motherboard : PowerBook6,3 MacRISC3 Power Macintosh
detected as : 287 (iBook G4)
pmac flags : 0000001b
L2 cache : 256K unified
pmac-generation : NewWorld
% uname -a
Linux ibook 2.6.24-rc3 #1 Sat Nov 17 16:06:21 CET 2007 ppc GNU/Linux
Bye, Jörg.
--
Es liegt in der Natur des Menschen, vernünftig zu denken und
unlogisch zu handeln! Das Gesagte ist nicht das Gemeinte und das Gehörte
nicht das Verstandene!
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Matt Sealey @ 2007-11-18 22:46 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910711181349q1f840bc2w8d30bb33d2a353ce@mail.gmail.com>
Jon Smirl wrote:
>
> The codec-fabric node was just being used to trigger the loading of
> the platform specific driver.
Just remember one thing.
1) the term "fabric" when coined for audio drivers is a new, ALSA SoC
specific term. It isn't relevant for anything but ALSA SoC drivers.
2) this device tree stuff will end up in more than Linux device trees
3) you're going to piss off Open Firmware developers by specifying
very Linux-specific features in a device tree the same way Apple
pissed off Linux developers by encoding MacOS X-specific features in
the device tree.
Audio driver control like this has to be very specific for a good
reason; you can do it a billion ways to Sunday. I'd suggest basically
that if you must control a device in a way that needs to be defined by
a device which can change address (either dynamically on boot or by
board design change - per revision, for example, or with a change of
controller) then simply use the device tree to report this address
so that you can have the same basic fabric driver (all in Linux) which
can handle minor modifications of your board design.
If you require the codec to be subservient to some "fabric" then I
suggest you make a "sound" node with a compatible entry which is
defined as something specific to your board (digispeaker,audio) and
let your driver pick that up and then switch on the model (rather like
Apple's layout-id) of that device to pick out the specifics of that
fabric. If it needs an audio codec (ac97 or i2s) and a control
interface (i2c or spi) then it knows which ones it is looking for
based on the model.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* [PATCH 4/21] ide/Kconfig: fix mpc8xx host driver dependencies
From: Bartlomiej Zolnierkiewicz @ 2007-11-18 22:15 UTC (permalink / raw)
To: linux-ide; +Cc: linuxppc-dev
Only LWMON, IVMS8, IVML24 and TQM8xxL platforms have the needed
defines (IDE0_BASE_OFFSET and friends) in the platform header file.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ide/Kconfig
===================================================================
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -951,7 +951,7 @@ config BLK_DEV_Q40IDE
config BLK_DEV_MPC8xx_IDE
bool "MPC8xx IDE support"
- depends on 8xx && IDE=y && BLK_DEV_IDE=y && !PPC_MERGE
+ depends on 8xx && (LWMON || IVMS8 || IVML24 || TQM8xxL) && IDE=y && BLK_DEV_IDE=y && !PPC_MERGE
select IDE_GENERIC
help
This option provides support for IDE on Motorola MPC8xx Systems.
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-18 21:49 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: PowerPC dev list
In-Reply-To: <0fd3304ee694b2dc6a8f3055c08dc015@kernel.crashing.org>
On 11/18/07, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> > David Gibson
> > made a proposal that a fabric node wrap the codec node. That doesn't
> > work very well with the i2c bus where the bus code is walking down the
> > nodes and triggering the instantiation of the i2c drivers.
>
> Yeah, doesn't work at all.
>
> > But what about putting the fabric node inside the codec node?
>
> _Which_ codec node? Having more than one isn't uncommon at all.
In all of them. Fabric can probably be split into pieces that
corresponds to the codec.
> There is no way you can describe this fabric stuff in a generic way in
> the device tree. Just hardcode it in your platform support code; if
> the platform code supports several variant boards, _it_ can probe that
> from the device tree (in whatever way works for that platform).
The codec-fabric node was just being used to trigger the loading of
the platform specific driver.
>
>
> Segher
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Segher Boessenkool @ 2007-11-18 20:16 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910711181010q50c08d2ek8413af74d58cf0ce@mail.gmail.com>
> ac97@2200 { // PSC2
> compatible = "mpc5200b-psc-ac97","mpc5200-psc-ac97";
> cell-index = <1>;
> reg = <2200 100>;
> interrupts = <2 2 0>;
> interrupt-parent = <&mpc5200_pic>;
You need #address-cells, #size-cells here.
> codec@0 {
> compatible = "idt,stac9766";
> reg = <0>;
> };
> };
>
> i2c@3d40 {
> compatible = "mpc5200b-i2c","mpc5200-i2c","fsl-i2c";
> reg = <3d40 40>;
> interrupts = <2 10 0>;
> interrupt-parent = <&mpc5200_pic>;
> fsl5200-clocking;
And here.
> codec@15 {
> compatible = "ti,tas5504";
> reg = <15>;
> i2s-handle = <i2s@2400>;
Should use an alias here (or the full path, if that works).
> };
> };
>
> i2s@2400 { // PSC4
> compatible = "mpc5200b-psc-i2s","mpc5200-psc-i2s";
> cell-index = <1>;
> reg = <2400 100>;
> interrupts = <2 3 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> A fabric driver tells specifically how a generic codec is wired into
> the board. What I haven't been able figure out is how to load the
> right fabric driver.
Whatever way works for the platform.
> It is starting to make more sense to me that fabric driver actually
> does represent a physical device - the cluster of wires.
That's only part of it, as far as I understand.
> David Gibson
> made a proposal that a fabric node wrap the codec node. That doesn't
> work very well with the i2c bus where the bus code is walking down the
> nodes and triggering the instantiation of the i2c drivers.
Yeah, doesn't work at all.
> But what about putting the fabric node inside the codec node?
_Which_ codec node? Having more than one isn't uncommon at all.
There is no way you can describe this fabric stuff in a generic way in
the device tree. Just hardcode it in your platform support code; if
the platform code supports several variant boards, _it_ can probe that
from the device tree (in whatever way works for that platform).
Segher
^ permalink raw reply
* Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
From: Trond Myklebust @ 2007-11-18 19:18 UTC (permalink / raw)
To: Torsten Kaiser
Cc: Peter Zijlstra, steved, LKML, Kamalesh Babulal, linuxppc-dev, nfs,
Andrew Morton, Jan Blunck, Ingo Molnar, Balbir Singh
In-Reply-To: <64bb37e0711181044s75fd1081sdf44dac2e060d49a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3001 bytes --]
On Sun, 2007-11-18 at 19:44 +0100, Torsten Kaiser wrote:
> On Nov 18, 2007 12:05 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > I've been staring at this NFS code for a while an can't make any sense
> > out of it. It seems to correctly initialize the waitqueue. So this would
> > indicate corruption of some sort.
>
> No, it does not "correctly" initialize the waitqueue. It doesn't even
> try to initialize it.
>
> I now found the guilty patch and what is wrong with it.
>
> nfs-stop-sillyname-renames-and-unmounts-from-racing.patch adds:
>
> @@ -110,8 +112,22 @@ struct nfs_server {
> filesystem */
> #endif
> void (*destroy)(struct nfs_server *);
> +
> + atomic_t active; /* Keep trace of any activity to this server */
> + wait_queue_head_t active_wq; /* Wait for any activity to stop */
>
> and tries to initialize it:
> @@ -593,6 +593,10 @@ static int nfs_init_server(struct nfs_server *server,
> server->namelen = data->namlen;
> /* Create a client RPC handle for the NFSv3 ACL management interface */
> nfs_init_server_aclclient(server);
> +
> + init_waitqueue_head(&server->active_wq);
> + atomic_set(&server->active, 0);
> +
>
> and then uses it via nfs_sb_active and nfs_sb_deactive:
>
> @@ -29,6 +29,7 @@ struct nfs_unlinkdata {
> static void
> nfs_free_unlinkdata(struct nfs_unlinkdata *data)
> {
> + nfs_sb_deactive(NFS_SERVER(data->dir));
> iput(data->dir);
> put_rpccred(data->cred);
> kfree(data->args.name.name);
> @@ -151,6 +152,7 @@ static int nfs_do_call_unlink(struct dentry
> *parent, struct inode *dir, struct n
> nfs_dec_sillycount(dir);
> return 0;
> }
> + nfs_sb_active(NFS_SERVER(dir));
> data->args.fh = NFS_FH(dir);
> nfs_fattr_init(&data->res.dir_attr);
>
>
> But it does not notice this:
> struct dentry_operations nfs_dentry_operations = {
> .d_revalidate = nfs_lookup_revalidate,
> .d_delete = nfs_dentry_delete,
> .d_iput = nfs_dentry_iput,
> };
> struct dentry_operations nfs4_dentry_operations = {
> .d_revalidate = nfs_open_revalidate,
> .d_delete = nfs_dentry_delete,
> .d_iput = nfs_dentry_iput,
> };
>
> NFSv2/3 and NFSv4 share the same dentry_iput and so share the same
> unlink and sillyrename logic.
> But they do not share nfs_init_server()!
>
> I wonder why this doesn't blow up more violently, but only hangs...
>
> But as I don't know if it is correct to add the workqueue
> initialization to nfs4_init_server() or remove the nfs_sb_active /
> nfs_sb_deactive for the NFSv4 case, I can't offer a patch to fix this.
>
> Torsten
I had already fixed that one in my own stack. Attached are the 3 patches
that I've got. 1 from SteveD, 2 fixes.
Andrew, could you please unapply the sillyrename patches you've got, and
apply these 3 instead?
Trond
[-- Attachment #2: linux-2.6.24-005-fix_sillyrename_bug_on_umount.dif --]
[-- Type: message/rfc822, Size: 4060 bytes --]
From: Steve Dickson <SteveD@redhat.com>
Subject: NFS: Stop sillyname renames and unmounts from racing
Date: Thu, 08 Nov 2007 04:05:04 -0500
Message-ID: <1195413486.7893.17.camel@heimdal.trondhjem.org>
Added an active/deactive mechanism to the nfs_server structure
allowing async operations to hold off umount until the
operations are done.
Signed-off-by: Steve Dickson <steved@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---
fs/nfs/client.c | 4 ++++
fs/nfs/super.c | 13 +++++++++++++
fs/nfs/unlink.c | 2 ++
include/linux/nfs_fs_sb.h | 17 +++++++++++++++++
4 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index 70587f3..2ecf726 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -593,6 +593,10 @@ static int nfs_init_server(struct nfs_server *server,
server->namelen = data->namlen;
/* Create a client RPC handle for the NFSv3 ACL management interface */
nfs_init_server_aclclient(server);
+
+ init_waitqueue_head(&server->active_wq);
+ atomic_set(&server->active, 0);
+
dprintk("<-- nfs_init_server() = 0 [new %p]\n", clp);
return 0;
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 71067d1..833aed8 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -202,6 +202,7 @@ static int nfs_get_sb(struct file_system_type *, int, const char *, void *, stru
static int nfs_xdev_get_sb(struct file_system_type *fs_type,
int flags, const char *dev_name, void *raw_data, struct vfsmount *mnt);
static void nfs_kill_super(struct super_block *);
+static void nfs_put_super(struct super_block *);
static struct file_system_type nfs_fs_type = {
.owner = THIS_MODULE,
@@ -223,6 +224,7 @@ static const struct super_operations nfs_sops = {
.alloc_inode = nfs_alloc_inode,
.destroy_inode = nfs_destroy_inode,
.write_inode = nfs_write_inode,
+ .put_super = nfs_put_super,
.statfs = nfs_statfs,
.clear_inode = nfs_clear_inode,
.umount_begin = nfs_umount_begin,
@@ -1772,6 +1774,17 @@ static void nfs4_kill_super(struct super_block *sb)
nfs_free_server(server);
}
+static void nfs_put_super(struct super_block *sb)
+{
+ struct nfs_server *server = NFS_SB(sb);
+ /*
+ * Make sure there are no outstanding ops to this server.
+ * If so, wait for them to finish before allowing the
+ * unmount to continue.
+ */
+ wait_event(server->active_wq, atomic_read(&server->active) == 0);
+}
+
/*
* Clone an NFS4 server record on xdev traversal (FSID-change)
*/
diff --git a/fs/nfs/unlink.c b/fs/nfs/unlink.c
index 233ad38..cf12a24 100644
--- a/fs/nfs/unlink.c
+++ b/fs/nfs/unlink.c
@@ -29,6 +29,7 @@ struct nfs_unlinkdata {
static void
nfs_free_unlinkdata(struct nfs_unlinkdata *data)
{
+ nfs_sb_deactive(NFS_SERVER(data->dir));
iput(data->dir);
put_rpccred(data->cred);
kfree(data->args.name.name);
@@ -151,6 +152,7 @@ static int nfs_do_call_unlink(struct dentry *parent, struct inode *dir, struct n
nfs_dec_sillycount(dir);
return 0;
}
+ nfs_sb_active(NFS_SERVER(dir));
data->args.fh = NFS_FH(dir);
nfs_fattr_init(&data->res.dir_attr);
diff --git a/include/linux/nfs_fs_sb.h b/include/linux/nfs_fs_sb.h
index 0cac49b..6ef3af8 100644
--- a/include/linux/nfs_fs_sb.h
+++ b/include/linux/nfs_fs_sb.h
@@ -4,6 +4,8 @@
#include <linux/list.h>
#include <linux/backing-dev.h>
+#include <asm/atomic.h>
+
struct nfs_iostats;
/*
@@ -110,8 +112,23 @@ struct nfs_server {
filesystem */
#endif
void (*destroy)(struct nfs_server *);
+
+ atomic_t active; /* Keep trace of any activity to this server */
+ wait_queue_head_t active_wq; /* Wait for any activity to stop */
};
+static inline void
+nfs_sb_active(struct nfs_server *server)
+{
+ atomic_inc(&server->active);
+}
+static inline void
+nfs_sb_deactive(struct nfs_server *server)
+{
+ if (atomic_dec_and_test(&server->active))
+ wake_up(&server->active_wq);
+}
+
/* Server capabilities */
#define NFS_CAP_READDIRPLUS (1U << 0)
#define NFS_CAP_HARDLINKS (1U << 1)
[-- Attachment #3: linux-2.6.24-006-fix_to_fix_sillyrename_bug_on_umount.dif --]
[-- Type: message/rfc822, Size: 4205 bytes --]
From: Trond Myklebust <Trond.Myklebust@netapp.com>
Subject: NFS: Fix up problems with Steve's sillyrename fix
Date: Sat, 17 Nov 2007 13:08:49 -0500
Message-ID: <1195413486.7893.18.camel@heimdal.trondhjem.org>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---
fs/nfs/client.c | 6 +++---
fs/nfs/internal.h | 2 ++
fs/nfs/super.c | 33 ++++++++++++++++++++++-----------
fs/nfs/unlink.c | 2 ++
include/linux/nfs_fs_sb.h | 13 +------------
5 files changed, 30 insertions(+), 26 deletions(-)
diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index 2ecf726..be9fecb 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -594,9 +594,6 @@ static int nfs_init_server(struct nfs_server *server,
/* Create a client RPC handle for the NFSv3 ACL management interface */
nfs_init_server_aclclient(server);
- init_waitqueue_head(&server->active_wq);
- atomic_set(&server->active, 0);
-
dprintk("<-- nfs_init_server() = 0 [new %p]\n", clp);
return 0;
@@ -736,6 +733,9 @@ static struct nfs_server *nfs_alloc_server(void)
INIT_LIST_HEAD(&server->client_link);
INIT_LIST_HEAD(&server->master_link);
+ init_waitqueue_head(&server->active_wq);
+ atomic_set(&server->active, 0);
+
server->io_stats = nfs_alloc_iostats();
if (!server->io_stats) {
kfree(server);
diff --git a/fs/nfs/internal.h b/fs/nfs/internal.h
index f3acf48..7579379 100644
--- a/fs/nfs/internal.h
+++ b/fs/nfs/internal.h
@@ -160,6 +160,8 @@ extern struct rpc_stat nfs_rpcstat;
extern int __init register_nfs_fs(void);
extern void __exit unregister_nfs_fs(void);
+extern void nfs_sb_active(struct nfs_server *server);
+extern void nfs_sb_deactive(struct nfs_server *server);
/* namespace.c */
extern char *nfs_path(const char *base,
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 833aed8..046d1ac 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -327,6 +327,28 @@ void __exit unregister_nfs_fs(void)
unregister_filesystem(&nfs_fs_type);
}
+void nfs_sb_active(struct nfs_server *server)
+{
+ atomic_inc(&server->active);
+}
+
+void nfs_sb_deactive(struct nfs_server *server)
+{
+ if (atomic_dec_and_test(&server->active))
+ wake_up(&server->active_wq);
+}
+
+static void nfs_put_super(struct super_block *sb)
+{
+ struct nfs_server *server = NFS_SB(sb);
+ /*
+ * Make sure there are no outstanding ops to this server.
+ * If so, wait for them to finish before allowing the
+ * unmount to continue.
+ */
+ wait_event(server->active_wq, atomic_read(&server->active) == 0);
+}
+
/*
* Deliver file system statistics to userspace
*/
@@ -1774,17 +1796,6 @@ static void nfs4_kill_super(struct super_block *sb)
nfs_free_server(server);
}
-static void nfs_put_super(struct super_block *sb)
-{
- struct nfs_server *server = NFS_SB(sb);
- /*
- * Make sure there are no outstanding ops to this server.
- * If so, wait for them to finish before allowing the
- * unmount to continue.
- */
- wait_event(server->active_wq, atomic_read(&server->active) == 0);
-}
-
/*
* Clone an NFS4 server record on xdev traversal (FSID-change)
*/
diff --git a/fs/nfs/unlink.c b/fs/nfs/unlink.c
index cf12a24..b97d3bb 100644
--- a/fs/nfs/unlink.c
+++ b/fs/nfs/unlink.c
@@ -14,6 +14,8 @@
#include <linux/sched.h>
#include <linux/wait.h>
+#include "internal.h"
+
struct nfs_unlinkdata {
struct hlist_node list;
struct nfs_removeargs args;
diff --git a/include/linux/nfs_fs_sb.h b/include/linux/nfs_fs_sb.h
index 6ef3af8..9f949b5 100644
--- a/include/linux/nfs_fs_sb.h
+++ b/include/linux/nfs_fs_sb.h
@@ -3,6 +3,7 @@
#include <linux/list.h>
#include <linux/backing-dev.h>
+#include <linux/wait.h>
#include <asm/atomic.h>
@@ -117,18 +118,6 @@ struct nfs_server {
wait_queue_head_t active_wq; /* Wait for any activity to stop */
};
-static inline void
-nfs_sb_active(struct nfs_server *server)
-{
- atomic_inc(&server->active);
-}
-static inline void
-nfs_sb_deactive(struct nfs_server *server)
-{
- if (atomic_dec_and_test(&server->active))
- wake_up(&server->active_wq);
-}
-
/* Server capabilities */
#define NFS_CAP_READDIRPLUS (1U << 0)
#define NFS_CAP_HARDLINKS (1U << 1)
[-- Attachment #4: linux-2.6.24-007-fix_nfs_free_unlinkdata.dif --]
[-- Type: message/rfc822, Size: 1255 bytes --]
From: Trond Myklebust <Trond.Myklebust@netapp.com>
Subject: NFS: Fix nfs_free_unlinkdata()
Date: Sat, 17 Nov 2007 13:52:36 -0500
Message-ID: <1195413486.7893.19.camel@heimdal.trondhjem.org>
We should really only be calling nfs_sb_deactive() at the end of an RPC
call, to balance the nfs_sb_active() call in nfs_do_call_unlink(). OTOH,
nfs_free_unlinkdata() can be called from a variety of other situations.
Fix is to move the call to nfs_sb_deactive() into
nfs_async_unlink_release().
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---
fs/nfs/unlink.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/nfs/unlink.c b/fs/nfs/unlink.c
index b97d3bb..c90862a 100644
--- a/fs/nfs/unlink.c
+++ b/fs/nfs/unlink.c
@@ -31,7 +31,6 @@ struct nfs_unlinkdata {
static void
nfs_free_unlinkdata(struct nfs_unlinkdata *data)
{
- nfs_sb_deactive(NFS_SERVER(data->dir));
iput(data->dir);
put_rpccred(data->cred);
kfree(data->args.name.name);
@@ -116,6 +115,7 @@ static void nfs_async_unlink_release(void *calldata)
struct nfs_unlinkdata *data = calldata;
nfs_dec_sillycount(data->dir);
+ nfs_sb_deactive(NFS_SERVER(data->dir));
nfs_free_unlinkdata(data);
}
[-- Attachment #5: series --]
[-- Type: text/plain, Size: 231 bytes --]
# This series applies on GIT commit 4c1fe2f78a08e2c514a39c91a0eb7b55bbd3c0d2
linux-2.6.24-005-fix_sillyrename_bug_on_umount.dif
linux-2.6.24-006-fix_to_fix_sillyrename_bug_on_umount.dif
linux-2.6.24-007-fix_nfs_free_unlinkdata.dif
^ permalink raw reply related
* Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
From: Torsten Kaiser @ 2007-11-18 18:44 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Trond Myklebust, steved, LKML, Kamalesh Babulal, linuxppc-dev,
nfs, Andrew Morton, Jan Blunck, Ingo Molnar, Balbir Singh
In-Reply-To: <20071117230508.GB25905@dyad>
On Nov 18, 2007 12:05 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> I've been staring at this NFS code for a while an can't make any sense
> out of it. It seems to correctly initialize the waitqueue. So this would
> indicate corruption of some sort.
No, it does not "correctly" initialize the waitqueue. It doesn't even
try to initialize it.
I now found the guilty patch and what is wrong with it.
nfs-stop-sillyname-renames-and-unmounts-from-racing.patch adds:
@@ -110,8 +112,22 @@ struct nfs_server {
filesystem */
#endif
void (*destroy)(struct nfs_server *);
+
+ atomic_t active; /* Keep trace of any activity to this server */
+ wait_queue_head_t active_wq; /* Wait for any activity to stop */
and tries to initialize it:
@@ -593,6 +593,10 @@ static int nfs_init_server(struct nfs_server *server,
server->namelen = data->namlen;
/* Create a client RPC handle for the NFSv3 ACL management interface */
nfs_init_server_aclclient(server);
+
+ init_waitqueue_head(&server->active_wq);
+ atomic_set(&server->active, 0);
+
and then uses it via nfs_sb_active and nfs_sb_deactive:
@@ -29,6 +29,7 @@ struct nfs_unlinkdata {
static void
nfs_free_unlinkdata(struct nfs_unlinkdata *data)
{
+ nfs_sb_deactive(NFS_SERVER(data->dir));
iput(data->dir);
put_rpccred(data->cred);
kfree(data->args.name.name);
@@ -151,6 +152,7 @@ static int nfs_do_call_unlink(struct dentry
*parent, struct inode *dir, struct n
nfs_dec_sillycount(dir);
return 0;
}
+ nfs_sb_active(NFS_SERVER(dir));
data->args.fh = NFS_FH(dir);
nfs_fattr_init(&data->res.dir_attr);
But it does not notice this:
struct dentry_operations nfs_dentry_operations = {
.d_revalidate = nfs_lookup_revalidate,
.d_delete = nfs_dentry_delete,
.d_iput = nfs_dentry_iput,
};
struct dentry_operations nfs4_dentry_operations = {
.d_revalidate = nfs_open_revalidate,
.d_delete = nfs_dentry_delete,
.d_iput = nfs_dentry_iput,
};
NFSv2/3 and NFSv4 share the same dentry_iput and so share the same
unlink and sillyrename logic.
But they do not share nfs_init_server()!
I wonder why this doesn't blow up more violently, but only hangs...
But as I don't know if it is correct to add the workqueue
initialization to nfs4_init_server() or remove the nfs_sb_active /
nfs_sb_deactive for the NFSv4 case, I can't offer a patch to fix this.
Torsten
^ permalink raw reply
* Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-18 18:10 UTC (permalink / raw)
To: PowerPC dev list
I've been trying to write ALSA SOC code supporting audio codecs and
device trees.
This looks ok for the main device tree entires. Codecs are hung off
from their controlling bus. It may still need a little tweaking.
ac97@2200 { // PSC2
compatible = "mpc5200b-psc-ac97","mpc5200-psc-ac97";
cell-index = <1>;
reg = <2200 100>;
interrupts = <2 2 0>;
interrupt-parent = <&mpc5200_pic>;
codec@0 {
compatible = "idt,stac9766";
reg = <0>;
};
};
i2c@3d40 {
compatible = "mpc5200b-i2c","mpc5200-i2c","fsl-i2c";
reg = <3d40 40>;
interrupts = <2 10 0>;
interrupt-parent = <&mpc5200_pic>;
fsl5200-clocking;
codec@15 {
compatible = "ti,tas5504";
reg = <15>;
i2s-handle = <i2s@2400>;
};
};
i2s@2400 { // PSC4
compatible = "mpc5200b-psc-i2s","mpc5200-psc-i2s";
cell-index = <1>;
reg = <2400 100>;
interrupts = <2 3 0>;
interrupt-parent = <&mpc5200_pic>;
};
In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
A fabric driver tells specifically how a generic codec is wired into
the board. What I haven't been able figure out is how to load the
right fabric driver.
It is starting to make more sense to me that fabric driver actually
does represent a physical device - the cluster of wires. David Gibson
made a proposal that a fabric node wrap the codec node. That doesn't
work very well with the i2c bus where the bus code is walking down the
nodes and triggering the instantiation of the i2c drivers.
But what about putting the fabric node inside the codec node?
codec@15 {
compatible = "ti,tas5504";
reg = <15>;
i2s-handle = <i2s@2400>;
codec-fabric {
compatible = "digispeaker,fabric"
};
};
codec@0 {
compatible = "idt,stac9766";
reg = <0>;
codec-fabric {
compatible = "efika,fabric"
};
};
This sort of makes sense, the ac97/i2c bus is connected to the codec,
which is then connected to the fabric.
The example used in the ALSA doc of an ac97 chip needing a fabric
driver was a case where the ac97 chip has an external amp. The fabric
driver uses a GPIO to turn the amp on/off with suspend/resume.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: how to improve linux tcp/ip(UDP) efficiency on mpc8541 833Mhz.
From: Theo Gjaltema @ 2007-11-18 17:56 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <47398B44.2070902@anagramm.de>
Hi,
We use a 8250 and 8270 of which the performance is highly limited by the
bandwidth of the memory to the very small internal cache.
I once modified a driver into a "polling" method polling the device
every millisecond. The amount of messages processed trippled this way!
On full speed the console could even be used for "normal" operation (in
contrairy to the interrupt driver driver).
The penalties are obvious: When the bandwith used is low the delay for
polled messages is higher and the CPU overhead is higher.
Succes,
Theo.
Clemens Koller schreef:
> huangyun@coship.com schrieb:
> > hi,everbody:
> > I have run linux-2.6.15 on my mpc8541 custom board. but when i test
> > TSEC use UDP, i found it's efficinecy is lower.
> > my test enviroment: i only run a UDP recieve program and not to handle data
> > recieved. when i recevie 400Mbps data, 79% of MPC8541 have be consumed.
> > so i think tcp/ip protocal have consume my mpc8541 resource. i dont know
> > how to improve tcp/ip code or TSEC driver(gianfar.c).
> > can somebody help me ?
>
> Hmm... you should first try one of the current kernels and check the
> performance there.
> For further details about linux networking, I recommend you to contact
> the guys at the netdev list, giving lots of details how you do your
> benchmarking and how your workload looks like.
>
> Regards,
>
> Clemens Koller
> __________________________________
> R&D Imaging Devices
> Anagramm GmbH
> Rupert-Mayer-Straße 45/1
> Linhof Werksgelände
> D-81379 München
> Tel.089-741518-50
> Fax 089-741518-19
> http://www.anagramm-technology.com
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* Re: [POWERPC] [RFC] Fix 8xx tlbie definition
From: Kumar Gala @ 2007-11-18 16:51 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071117110658.7375dc1a@vader.jdub.homelinux.org>
>>> Where can I grab it to give a try? My linuxppc archive is silent
>>> for some reason..
>>
>> Looks like I may have failed to post it ... weird, I was sure I
>> posted
>> that days ago, when Olof first mentioned the breakage. I'll check &
>> resend.
>
> I never saw it. If I had, I wouldn't have bothered to post my own
> version :)
we still haven't seen ben's version :)
- k
^ permalink raw reply
* Re: Problem with uboot on lite5200
From: Clemens Koller @ 2007-11-18 13:21 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20071118004919.19256247F1@gemini.denx.de>
Hello, Wolfgang!
Wolfgang Denk schrieb:
> In message <6b461e5b0711150114h26624cacq3cad2629912c60ea@mail.gmail.com> you wrote:
>> how can i re-flash the uboot inside the MPC5200? i use bdi2000, compiled the
>
> You are off topic here. Please post U-Boto related questions on the
> U-Boot maioling list.
>
>> new uboot version 1.1.6 but didnt find out anyway to flash it inside the
>
> New? 1.1.6? That's stone-age.
How should people get a glue what's current, when in the section
"Latest News" at http://sourceforge.net/projects/u-boot/ the people
still find a more or less official looking "u-boot-1.1.5" release.
(And they don't want to use scm repositories because they are afraid
of using anything unstable.)
> Current U-Boot is 1.3.0-rc4. Please wake up.
Well... maybe it's better to remove all references to the old
releases at sourceforge and point them to ftp://ftp.denx.de/pub/u-boot/
instead. Btw. 1.3.0-rc4 isn't there as well. :-P
Regards,
--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm-technology.com
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: about uImage-DENX-v2.6.14 config
From: Robert Schwebel @ 2007-11-18 11:17 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, zhangwei zhang, linuxppc-embedded
In-Reply-To: <20071118004301.475BC247F1@gemini.denx.de>
On Sun, Nov 18, 2007 at 01:43:01AM +0100, Wolfgang Denk wrote:
> In message <200711150713.28211.sr@denx.de> Stefan Roese wrote:
> > On Wednesday 14 November 2007, zhangwei zhang wrote:
> > > Hello, I have a problem when using linux-2.6.14(download from
> > > ftp.denx.de) for RTAI on ppc440EP.
> >
> > RTAI on PPC? I thought RTAI was dead for anything other than X86.
>
> Stefan is right.
>
> RTAI is dead.
>
> You should use Xenomai instead.
Or rt-preempt of course, which is the mainline way of doing realtime.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ 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