* Re: Initialize DBCR0 for PPC440 targets
From: srikanth krishnakar @ 2009-05-20 6:14 UTC (permalink / raw)
To: srikanth krishnakar, Linuxppc-dev
In-Reply-To: <20090520060014.GL6333@yookeroo.seuss>
Hi David,
Just to correct the statements : How the DBCR0 is initialized on
targets that don't use boot loaders ?
-Srikant
On Wed, May 20, 2009 at 11:30 AM, David Gibson
<david@gibson.dropbear.id.au> wrote:
> On Wed, May 20, 2009 at 11:20:46AM +0530, srikanth krishnakar wrote:
>> Hi David,
>>
>> I am not sure how the IDM behaves on few of PPC440 targets which don't
>> have boot loaders. I have a reference for your question:
>>
>> http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td2304=
9044.html
>>
>> Without this fix (given patch) I am facing problems with GDB, and
>> further target hangs while running gdbserver !
>
> That doesn't answer my question. =A0It's not enough to say "this fixes a
> problem" you need to explain *how* it fixes the problem.
>
> And I don't see why IDM would have any effect on *software*
> breakpoints.
>
>> On Wed, May 20, 2009 at 5:23 AM, David Gibson
>> <david@gibson.dropbear.id.au> wrote:
>> > On Tue, May 19, 2009 at 06:38:53PM +0530, srikanth krishnakar wrote:
>> >> Hi,
>> >>
>> >> kernel- 2.6.29
>> >> Debug technique: KGDB
>> >>
>> >> The PowerPC kernel does not initialize the PPC440 DBCR0 register. Thi=
s
>> >> prevents the use of software breakpoints in case of internal debug
>> >> mode. Looking into head_fsl_booke.S for initialization of DBCR0 is
>> >> used by boot-loaders.
>> >> It seems head_44x.S lacks this step of DBCR0 register initialization.
>> >> So fixing this with initializing the DBCR0 register as shown below :
>> >>
>> >> Subject: [PATCH] powerpc: 44x: Initialize DBCR0 for targets not havin=
g
>> >> bootloader
>> >>
>> >> The kernel does not initialize the PPC440 DBCR0 register.
>> >> This prevents (among other things) the use of software
>> >> breakpoints with GDB. The boot loaders probably do initialize
>> >> this but few targets run without a boot loader
>> >
>> > Um.. how does this prevent the use of software breakpoints with gdb?
>> > The trap instructions still work with IDM=3D=3D0.
>
> --
> David Gibson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| I'll have my music =
baroque, and my code
> david AT gibson.dropbear.id.au =A0| minimalist, thank you. =A0NOT _the_ _=
other_
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| _way_ _a=
round_!
> http://www.ozlabs.org/~dgibson
>
--=20
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
^ permalink raw reply
* Re: Initialize DBCR0 for PPC440 targets
From: David Gibson @ 2009-05-20 6:00 UTC (permalink / raw)
To: srikanth krishnakar; +Cc: Linuxppc-dev
In-Reply-To: <6213bc560905192250w4caa84aem9c0dedb2eed72fea@mail.gmail.com>
On Wed, May 20, 2009 at 11:20:46AM +0530, srikanth krishnakar wrote:
> Hi David,
>
> I am not sure how the IDM behaves on few of PPC440 targets which don't
> have boot loaders. I have a reference for your question:
>
> http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html
>
> Without this fix (given patch) I am facing problems with GDB, and
> further target hangs while running gdbserver !
That doesn't answer my question. It's not enough to say "this fixes a
problem" you need to explain *how* it fixes the problem.
And I don't see why IDM would have any effect on *software*
breakpoints.
> On Wed, May 20, 2009 at 5:23 AM, David Gibson
> <david@gibson.dropbear.id.au> wrote:
> > On Tue, May 19, 2009 at 06:38:53PM +0530, srikanth krishnakar wrote:
> >> Hi,
> >>
> >> kernel- 2.6.29
> >> Debug technique: KGDB
> >>
> >> The PowerPC kernel does not initialize the PPC440 DBCR0 register. This
> >> prevents the use of software breakpoints in case of internal debug
> >> mode. Looking into head_fsl_booke.S for initialization of DBCR0 is
> >> used by boot-loaders.
> >> It seems head_44x.S lacks this step of DBCR0 register initialization.
> >> So fixing this with initializing the DBCR0 register as shown below :
> >>
> >> Subject: [PATCH] powerpc: 44x: Initialize DBCR0 for targets not having
> >> bootloader
> >>
> >> The kernel does not initialize the PPC440 DBCR0 register.
> >> This prevents (among other things) the use of software
> >> breakpoints with GDB. The boot loaders probably do initialize
> >> this but few targets run without a boot loader
> >
> > Um.. how does this prevent the use of software breakpoints with gdb?
> > The trap instructions still work with IDM==0.
--
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: [RFC][PATCH] powerpc/pci: Pull ppc32 code we need in ppc64
From: Kumar Gala @ 2009-05-20 5:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <Pine.LNX.4.64.0904291546130.19681@localhost.localdomain>
Ben,
Comments on the pmac case?
- k
On Apr 29, 2009, at 3:49 PM, Kumar Gala wrote:
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
>
> Ben,
>
> My question is if we think fake_pci_bus will always get a valid
> hose().
> The users of EARLY_PCI_OP are fsl/8xxx, 4xx, and pmac. I verified
> that
> fsl/8xxx & 4xx pass a valid hose. Do we think pmac does?
>
> - k
>
> arch/powerpc/include/asm/machdep.h | 6 +-
> arch/powerpc/include/asm/pci-bridge.h | 35 +++++++---------
> arch/powerpc/kernel/pci-common.c | 70 ++++++++++++++++++++++++
> ++++++++
> arch/powerpc/kernel/pci_32.c | 71
> ---------------------------------
> 4 files changed, 89 insertions(+), 93 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/
> include/asm/machdep.h
> index 0efdb1d..1b389ff 100644
> --- a/arch/powerpc/include/asm/machdep.h
> +++ b/arch/powerpc/include/asm/machdep.h
> @@ -205,14 +205,14 @@ struct machdep_calls {
> /*
> * optional PCI "hooks"
> */
> - /* Called in indirect_* to avoid touching devices */
> - int (*pci_exclude_device)(struct pci_controller *, unsigned char,
> unsigned char);
> -
> /* Called at then very end of pcibios_init() */
> void (*pcibios_after_init)(void);
>
> #endif /* CONFIG_PPC32 */
>
> + /* Called in indirect_* to avoid touching devices */
> + int (*pci_exclude_device)(struct pci_controller *, unsigned char,
> unsigned char);
> +
> /* Called after PPC generic resource fixup to perform
> machine specific fixups */
> void (*pcibios_fixup_resources)(struct pci_dev *);
> diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/
> include/asm/pci-bridge.h
> index 48f58aa..8b371df 100644
> --- a/arch/powerpc/include/asm/pci-bridge.h
> +++ b/arch/powerpc/include/asm/pci-bridge.h
> @@ -77,9 +77,7 @@ struct pci_controller {
>
> int first_busno;
> int last_busno;
> -#ifndef CONFIG_PPC64
> int self_busno;
> -#endif
>
> void __iomem *io_base_virt;
> #ifdef CONFIG_PPC64
> @@ -104,7 +102,6 @@ struct pci_controller {
> unsigned int __iomem *cfg_addr;
> void __iomem *cfg_data;
>
> -#ifndef CONFIG_PPC64
> /*
> * Used for variants of PCI indirect handling and possible quirks:
> * SET_CFG_TYPE - used on 4xx or any PHB that does explicit type0/1
> @@ -128,7 +125,6 @@ struct pci_controller {
> #define PPC_INDIRECT_TYPE_BIG_ENDIAN 0x00000010
> #define PPC_INDIRECT_TYPE_BROKEN_MRM 0x00000020
> u32 indirect_type;
> -#endif /* !CONFIG_PPC64 */
> /* Currently, we limit ourselves to 1 IO range and 3 mem
> * ranges since the common pci_bus structure can't handle more
> */
> @@ -146,21 +142,6 @@ struct pci_controller {
> #endif /* CONFIG_PPC64 */
> };
>
> -#ifndef CONFIG_PPC64
> -
> -static inline struct pci_controller *pci_bus_to_host(const struct
> pci_bus *bus)
> -{
> - return bus->sysdata;
> -}
> -
> -static inline int isa_vaddr_is_ioport(void __iomem *address)
> -{
> - /* No specific ISA handling on ppc32 at this stage, it
> - * all goes through PCI
> - */
> - return 0;
> -}
> -
> /* These are used for config access before all the PCI probing
> has been done. */
> extern int early_read_config_byte(struct pci_controller *hose, int
> bus,
> @@ -182,6 +163,22 @@ extern int early_find_capability(struct
> pci_controller *hose, int bus,
> extern void setup_indirect_pci(struct pci_controller* hose,
> resource_size_t cfg_addr,
> resource_size_t cfg_data, u32 flags);
> +
> +#ifndef CONFIG_PPC64
> +
> +static inline struct pci_controller *pci_bus_to_host(const struct
> pci_bus *bus)
> +{
> + return bus->sysdata;
> +}
> +
> +static inline int isa_vaddr_is_ioport(void __iomem *address)
> +{
> + /* No specific ISA handling on ppc32 at this stage, it
> + * all goes through PCI
> + */
> + return 0;
> +}
> +
> #else /* CONFIG_PPC64 */
>
> /*
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/
> pci-common.c
> index 9c69e7e..cae4ee1 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -1620,3 +1620,73 @@ void __devinit
> pcibios_setup_phb_resources(struct pci_controller *hose)
>
> }
>
> +/*
> + * Null PCI config access functions, for the case when we can't
> + * find a hose.
> + */
> +#define NULL_PCI_OP(rw, size, type) \
> +static int \
> +null_##rw##_config_##size(struct pci_dev *dev, int offset, type
> val) \
> +{ \
> + return PCIBIOS_DEVICE_NOT_FOUND; \
> +}
> +
> +static int
> +null_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
> + int len, u32 *val)
> +{
> + return PCIBIOS_DEVICE_NOT_FOUND;
> +}
> +
> +static int
> +null_write_config(struct pci_bus *bus, unsigned int devfn, int
> offset,
> + int len, u32 val)
> +{
> + return PCIBIOS_DEVICE_NOT_FOUND;
> +}
> +
> +static struct pci_ops null_pci_ops =
> +{
> + .read = null_read_config,
> + .write = null_write_config,
> +};
> +
> +/*
> + * These functions are used early on before PCI scanning is done
> + * and all of the pci_dev and pci_bus structures have been created.
> + */
> +static struct pci_bus *
> +fake_pci_bus(struct pci_controller *hose, int busnr)
> +{
> + static struct pci_bus bus;
> +
> + if (hose == 0) {
> + printk(KERN_ERR "Can't find hose for PCI bus %d!\n", busnr);
> + }
> + bus.number = busnr;
> + bus.sysdata = hose;
> + bus.ops = hose? hose->ops: &null_pci_ops;
> + return &bus;
> +}
> +
> +#define EARLY_PCI_OP(rw, size, type) \
> +int early_##rw##_config_##size(struct pci_controller *hose, int
> bus, \
> + int devfn, int offset, type value) \
> +{ \
> + return pci_bus_##rw##_config_##size(fake_pci_bus(hose, bus), \
> + devfn, offset, value); \
> +}
> +
> +EARLY_PCI_OP(read, byte, u8 *)
> +EARLY_PCI_OP(read, word, u16 *)
> +EARLY_PCI_OP(read, dword, u32 *)
> +EARLY_PCI_OP(write, byte, u8)
> +EARLY_PCI_OP(write, word, u16)
> +EARLY_PCI_OP(write, dword, u32)
> +
> +extern int pci_bus_find_capability (struct pci_bus *bus, unsigned
> int devfn, int cap);
> +int early_find_capability(struct pci_controller *hose, int bus, int
> devfn,
> + int cap)
> +{
> + return pci_bus_find_capability(fake_pci_bus(hose, bus), devfn, cap);
> +}
> diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/
> pci_32.c
> index d473634..32fbadb 100644
> --- a/arch/powerpc/kernel/pci_32.c
> +++ b/arch/powerpc/kernel/pci_32.c
> @@ -497,75 +497,4 @@ long sys_pciconfig_iobase(long which, unsigned
> long bus, unsigned long devfn)
> return result;
> }
>
> -/*
> - * Null PCI config access functions, for the case when we can't
> - * find a hose.
> - */
> -#define NULL_PCI_OP(rw, size, type) \
> -static int \
> -null_##rw##_config_##size(struct pci_dev *dev, int offset, type
> val) \
> -{ \
> - return PCIBIOS_DEVICE_NOT_FOUND; \
> -}
> -
> -static int
> -null_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
> - int len, u32 *val)
> -{
> - return PCIBIOS_DEVICE_NOT_FOUND;
> -}
> -
> -static int
> -null_write_config(struct pci_bus *bus, unsigned int devfn, int
> offset,
> - int len, u32 val)
> -{
> - return PCIBIOS_DEVICE_NOT_FOUND;
> -}
> -
> -static struct pci_ops null_pci_ops =
> -{
> - .read = null_read_config,
> - .write = null_write_config,
> -};
>
> -/*
> - * These functions are used early on before PCI scanning is done
> - * and all of the pci_dev and pci_bus structures have been created.
> - */
> -static struct pci_bus *
> -fake_pci_bus(struct pci_controller *hose, int busnr)
> -{
> - static struct pci_bus bus;
> -
> - if (hose == 0) {
> - hose = pci_bus_to_hose(busnr);
> - if (hose == 0)
> - printk(KERN_ERR "Can't find hose for PCI bus %d!\n", busnr);
> - }
> - bus.number = busnr;
> - bus.sysdata = hose;
> - bus.ops = hose? hose->ops: &null_pci_ops;
> - return &bus;
> -}
> -
> -#define EARLY_PCI_OP(rw, size, type) \
> -int early_##rw##_config_##size(struct pci_controller *hose, int
> bus, \
> - int devfn, int offset, type value) \
> -{ \
> - return pci_bus_##rw##_config_##size(fake_pci_bus(hose, bus), \
> - devfn, offset, value); \
> -}
> -
> -EARLY_PCI_OP(read, byte, u8 *)
> -EARLY_PCI_OP(read, word, u16 *)
> -EARLY_PCI_OP(read, dword, u32 *)
> -EARLY_PCI_OP(write, byte, u8)
> -EARLY_PCI_OP(write, word, u16)
> -EARLY_PCI_OP(write, dword, u32)
> -
> -extern int pci_bus_find_capability (struct pci_bus *bus, unsigned
> int devfn, int cap);
> -int early_find_capability(struct pci_controller *hose, int bus, int
> devfn,
> - int cap)
> -{
> - return pci_bus_find_capability(fake_pci_bus(hose, bus), devfn, cap);
> -}
> --
> 1.6.0.6
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Musings on PCI busses
From: David Miller @ 2009-05-20 5:51 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, thunderbird2k, John.Linn
In-Reply-To: <1242788490.16901.133.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed, 20 May 2009 13:01:30 +1000
> For example, some of the OF parsing bits may fail to convert memory
> addresses to IO addresses if the PCI host bridges have not been
> discovered yet, potentially causing issues with matching of resources
> between the early serial stuff and the generic serial driver (if you
> use an IO driven UART, the PCI 8250 driver may not properly figure out
> that what it's finding in its IO BARs is actually the same port as
> what it gets from the platform code as the later will end up with
> memory addresses rather than IO ones). That's one example.
FWIW, I never run into this issue on sparc64 exactly because I
fully resolve all resources when I populate the OF device tree
in the kernel.
^ permalink raw reply
* Re: Initialize DBCR0 for PPC440 targets
From: srikanth krishnakar @ 2009-05-20 5:50 UTC (permalink / raw)
To: srikanth krishnakar, Linuxppc-dev, Linuxppc-embedded
In-Reply-To: <20090519235302.GA6333@yookeroo.seuss>
Hi David,
I am not sure how the IDM behaves on few of PPC440 targets which don't
have boot loaders. I have a reference for your question:
http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td2304904=
4.html
Without this fix (given patch) I am facing problems with GDB, and
further target hangs while running gdbserver !
Thanks,
Srikanth
On Wed, May 20, 2009 at 5:23 AM, David Gibson
<david@gibson.dropbear.id.au> wrote:
> On Tue, May 19, 2009 at 06:38:53PM +0530, srikanth krishnakar wrote:
>> Hi,
>>
>> kernel- 2.6.29
>> Debug technique: KGDB
>>
>> The PowerPC kernel does not initialize the PPC440 DBCR0 register. This
>> prevents the use of software breakpoints in case of internal debug
>> mode. Looking into head_fsl_booke.S for initialization of DBCR0 is
>> used by boot-loaders.
>> It seems head_44x.S lacks this step of DBCR0 register initialization.
>> So fixing this with initializing the DBCR0 register as shown below :
>>
>> Subject: [PATCH] powerpc: 44x: Initialize DBCR0 for targets not having
>> bootloader
>>
>> The kernel does not initialize the PPC440 DBCR0 register.
>> This prevents (among other things) the use of software
>> breakpoints with GDB. The boot loaders probably do initialize
>> this but few targets run without a boot loader
>
> Um.. how does this prevent the use of software breakpoints with gdb?
> The trap instructions still work with IDM=3D=3D0.
>
> --
> David Gibson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| I'll have my music =
baroque, and my code
> david AT gibson.dropbear.id.au =A0| minimalist, thank you. =A0NOT _the_ _=
other_
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| _way_ _a=
round_!
> http://www.ozlabs.org/~dgibson
>
--=20
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
^ permalink raw reply
* Re: Musings on PCI busses
From: Benjamin Herrenschmidt @ 2009-05-20 5:33 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, thunderbird2k, John.Linn, arnd
In-Reply-To: <20090519.120514.26253637.davem@davemloft.net>
On Tue, 2009-05-19 at 12:05 -0700, David Miller wrote:
>
> This is also what sparc64 does :-)
>
> All of the individual sparc64 PCI controller types have a OF driver
> and then there is a common layer of OF PCI helper code to do most
> of the work.
I agree it's a good idea in the long run, but on ppc32, I would be a bit
careful due to the amount of historical crap & early board fixup we have
that may need working PCI config space accesses and make assumption
about when PCI is probed.
We could add the necessary bits for ppc32 to be able to "opt-in" the new
scheme on a per board basis I suppose.
Cheers,
Ben.
^ permalink raw reply
* Re: Musings on PCI busses
From: Benjamin Herrenschmidt @ 2009-05-20 5:31 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Roderick Colenbrander, John Linn
In-Reply-To: <fa686aa40905192017r7978fdddq70872dcf86127008@mail.gmail.com>
On Tue, 2009-05-19 at 21:17 -0600, Grant Likely wrote:
> On Tue, May 19, 2009 at 9:02 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Tue, 2009-05-19 at 09:25 -0700, Stephen Neuendorffer wrote:
> >
> >> I agree that something is called for... The first might be slightly
> >> simpler, since it would probably transparently deal with the presence
> >> of more than one PLB->PCI bridge?
> >
> > The current code doesn't already ?
>
> Current code doesn't exist in mainline. :-)
Well, I was thinking about ppc4xx_pci :-)
> And, no, the patch Roderick wrote doesn't handle more than one PHB.
> No reason it couldn't though.
Right, it shouldn't be hard.
Cheers,
Ben.
^ permalink raw reply
* Re: question : DMA of PCI bridge
From: David Hawkins @ 2009-05-20 3:51 UTC (permalink / raw)
To: Sauce.Cheng; +Cc: linuxppc-dev
In-Reply-To: <23628338.post@talk.nabble.com>
Hi,
> Now I attempt to fetch data from peripheral device to SDRAM, and it has been
> successed
>
> but how the DMA controller know the data bandwidth of src and dest.
>
> for example, if i get a 16bits data with a 32bits bus, and other 16bits will
> be set high
> and data will fetched into cache line of dma, then it will be wrote to
> 32bits SDRAM.
You'll need to give us a little more detail. For example,
what processor are you using to perform the transaction?
Your email title says DMA of PCI bridge, however, you
mention peripheral to SDRAM. Are you using a DMA controller
on the peripheral, eg. a PCI bus master, to DMA into the
host SDRAM, or are you using a host DMA controller to
DMA over PCI into memory on the host?
Whether or not you get packing bytes when you access a
16-bit device and transfer the data to a 32-bit destination
depends on how the device is mapped. For example, a 16-bit
device can be implemented such that it responds to 8-bit,
16-bit, and 32-bit requests, but the 32-bit requests will
require more wait-states, since the device has to be
read from twice before constructing a 32-bit word to
place on the PCI bus.
Its also possible that the DMA controller can be configured
to deal with different source and destination widths. However
without knowing what processor or DMA controller you are
asking about, theres not much to say.
Cheers,
Dave
^ permalink raw reply
* question : DMA of PCI bridge
From: Sauce.Cheng @ 2009-05-20 3:19 UTC (permalink / raw)
To: linuxppc-dev
excuse me
I hate to bother everyone but I have a question about DMA of PCI bridge
Now I attempt to fetch data from peripheral device to SDRAM, and it has been
successed
but how the DMA controller know the data bandwidth of src and dest.
for example, if i get a 16bits data with a 32bits bus, and other 16bits will
be set high
and data will fetched into cache line of dma, then it will be wrote to
32bits SDRAM.
i guess the data will be wrong, isn't ?
please give me some advices. thank you
--
View this message in context: http://www.nabble.com/question-%3A-DMA-of-PCI-bridge-tp23628338p23628338.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Musings on PCI busses
From: Grant Likely @ 2009-05-20 3:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Roderick Colenbrander, John Linn
In-Reply-To: <1242788522.16901.134.camel@pasglop>
On Tue, May 19, 2009 at 9:02 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Tue, 2009-05-19 at 09:25 -0700, Stephen Neuendorffer wrote:
>
>> I agree that something is called for... =A0The first might be slightly
>> simpler, since it would probably transparently deal with the presence
>> of more than one PLB->PCI bridge?
>
> The current code doesn't already ?
Current code doesn't exist in mainline. :-)
And, no, the patch Roderick wrote doesn't handle more than one PHB.
No reason it couldn't though.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: Musings on PCI busses
From: Benjamin Herrenschmidt @ 2009-05-20 3:02 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, Roderick Colenbrander, John Linn
In-Reply-To: <20090519162511.7454D17E8058@mail19-dub.bigfish.com>
On Tue, 2009-05-19 at 09:25 -0700, Stephen Neuendorffer wrote:
> I agree that something is called for... The first might be slightly
> simpler, since it would probably transparently deal with the presence
> of more than one PLB->PCI bridge?
The current code doesn't already ?
Cheers,
Ben.
^ permalink raw reply
* Re: Musings on PCI busses
From: Benjamin Herrenschmidt @ 2009-05-20 3:01 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Roderick Colenbrander, John Linn
In-Reply-To: <fa686aa40905190828x251765dek586f5bf8e73e4cf7@mail.gmail.com>
On Tue, 2009-05-19 at 09:28 -0600, Grant Likely wrote:
> 1) Probe the host controller in an of_platform driver. This has the
> advantage of simplicity. The probe routine will get automatically
> called when the PCI host controller device tree node is registered
> with the of_platform bus. The bus parenthood also gets reflected in
> the device model and sysfs. The disadvantage is that it defers PCI
> bus probing until after the of_platform bus is probed (maybe this is
> okay; maybe this already happens anyway).
We are doing that on Cell as mentioned by Arnd. However, there are a
few issues with that approach. One is that it relies on PCI-hotplug
related bits that currently only exist in 64-bit land. Another is
that doing so tends to expose various hidden issues or subtle
dependencies to the PCI stuff being setup early and probed early.
For example, some of the OF parsing bits may fail to convert memory
addresses to IO addresses if the PCI host bridges have not been
discovered yet, potentially causing issues with matching of resources
between the early serial stuff and the generic serial driver (if you
use an IO driven UART, the PCI 8250 driver may not properly figure out
that what it's finding in its IO BARs is actually the same port as
what it gets from the platform code as the later will end up with
memory addresses rather than IO ones). That's one example.
At this stage, I much prefer if we stick to doing the PHB discovery
at setup_arch() time, especially since there's other WIP in the area
of PCI coming from Kumar and I don't want to mixup multiple source of
problems in that area at the same time.
We can revisit that later but we'll have to be very careful.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc/mm: Fix some SMP issues with MMU context handling
From: Benjamin Herrenschmidt @ 2009-05-20 2:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Kumar Gala
This patch fixes a couple of issues that can happen as a result
of steal_context() dropping the context_lock when all possible
PIDs are ineligible for stealing (hopefully an extremely hard to
hit occurence).
This case exposes the possibility of a stale context_mm[] entry
to be seen since destroy_context() doesn't clear it and the free
map isn't re-tested. It also means steal_context() will not notice
a context freed while the lock was help, thus possibly trying to
steal a context when a free one was available.
This fixes it by always returning to the caller from steal_context
when it dropped the lock with a return value that causes the
caller to re-samble the number of free contexts, along with
properly clearing the context_mm[] array for destroyed contexts.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/mm/mmu_context_nohash.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- linux-work.orig/arch/powerpc/mm/mmu_context_nohash.c 2009-05-20 12:39:21.000000000 +1000
+++ linux-work/arch/powerpc/mm/mmu_context_nohash.c 2009-05-20 12:49:45.000000000 +1000
@@ -73,7 +73,6 @@ static unsigned int steal_context_smp(un
struct mm_struct *mm;
unsigned int cpu, max;
- again:
max = last_context - first_context;
/* Attempt to free next_context first and then loop until we manage */
@@ -108,7 +107,9 @@ static unsigned int steal_context_smp(un
spin_unlock(&context_lock);
cpu_relax();
spin_lock(&context_lock);
- goto again;
+
+ /* This will cause the caller to try again */
+ return MMU_NO_CONTEXT;
}
#endif /* CONFIG_SMP */
@@ -194,6 +195,8 @@ void switch_mmu_context(struct mm_struct
WARN_ON(prev->context.active < 1);
prev->context.active--;
}
+
+ again:
#endif /* CONFIG_SMP */
/* If we already have a valid assigned context, skip all that */
@@ -212,7 +215,8 @@ void switch_mmu_context(struct mm_struct
#ifdef CONFIG_SMP
if (num_online_cpus() > 1) {
id = steal_context_smp(id);
- goto stolen;
+ if (id == MMU_NO_CONTEXT)
+ goto again;
}
#endif /* CONFIG_SMP */
id = steal_context_up(id);
@@ -286,8 +290,8 @@ void destroy_context(struct mm_struct *m
mm->context.id = MMU_NO_CONTEXT;
#ifdef DEBUG_MAP_CONSISTENCY
mm->context.active = 0;
- context_mm[id] = NULL;
#endif
+ context_mm[id] = NULL;
nr_free_contexts++;
}
spin_unlock(&context_lock);
^ permalink raw reply
* [PATCH] tape: beyond ARRAY_SIZE of viocd_diskinfo
From: Roel Kluin @ 2009-05-20 0:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sfr, Andrew Morton, lkml
Do not go beyond ARRAY_SIZE of tape_device and viotape_unitinfo
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
diff --git a/drivers/char/viotape.c b/drivers/char/viotape.c
index ffc9254..042c814 100644
--- a/drivers/char/viotape.c
+++ b/drivers/char/viotape.c
@@ -867,7 +867,7 @@ static int viotape_probe(struct vio_dev *vdev, const struct vio_device_id *id)
int j;
struct device_node *node = vdev->dev.archdata.of_node;
- if (i > VIOTAPE_MAX_TAPE)
+ if (i >= VIOTAPE_MAX_TAPE)
return -ENODEV;
if (!node)
return -ENODEV;
^ permalink raw reply related
* Re: Re: [PATCH 11/12] mpc5121: Added MPC512x DMA driver.
From: Hongjun Chen @ 2009-05-20 0:39 UTC (permalink / raw)
To: Piotr Zięcik, John Rigby; +Cc: linuxppc-dev@ozlabs.org, Wolfgang Denk
In-Reply-To: <200905191003.42964.kosmo@semihalf.com>
[-- Attachment #1: Type: text/plain, Size: 836 bytes --]
Hi John,
Did you use DMA driver in our FEC driver before?
Best Regards,
Hongjun Chen
2009-05-20
发件人： Piotr Zięcik
发送时间： 2009-05-19 16:05:05
收件人： Hongjun Chen
抄送： Wolfgang Denk; linuxppc-dev@ozlabs.org
主题： Re: [PATCH 11/12] mpc5121: Added MPC512x DMA driver.
Tuesday 19 May 2009 03:37:47 Hongjun Chen wrote:
> Since you have reuse most part of our BSP, why should you reinvent wheel
> for MPC512x DMA? We have one ready DMA driver, which has been used by AC97,
> ATA, VIU etc.
>
Answer is simple. The old one does not fit Linux DMA API. New one uses
existing infrastructure which makes DMA engine aviable for existing consumers
in Linux kernel. For example network stack. Support for I/O <- > memory
transfers will be added when more consumers arrive.
--
Best Regards.
Piotr Zięcik
[-- Attachment #2: Type: text/html, Size: 3654 bytes --]
^ permalink raw reply
* [PATCH] powerpc/5200: beyond ARRAY_SIZE of mpc52xx_uart_{ports, nodes}
From: Roel Kluin @ 2009-05-20 0:28 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-dev, Andrew Morton
Do not go beyond ARRAY_SIZE of mpc52xx_uart_{ports,nodes}
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index 7f72f8c..b3feb61 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -988,7 +988,7 @@ mpc52xx_console_setup(struct console *co, char *options)
pr_debug("mpc52xx_console_setup co=%p, co->index=%i, options=%s\n",
co, co->index, options);
- if ((co->index < 0) || (co->index > MPC52xx_PSC_MAXNUM)) {
+ if ((co->index < 0) || (co->index >= MPC52xx_PSC_MAXNUM)) {
pr_debug("PSC%x out of range\n", co->index);
return -EINVAL;
}
^ permalink raw reply related
* Re: Initialize DBCR0 for PPC440 targets
From: David Gibson @ 2009-05-19 23:53 UTC (permalink / raw)
To: srikanth krishnakar; +Cc: Linuxppc-dev, Linuxppc-embedded
In-Reply-To: <6213bc560905190608j73f4191fxbd94158a2b1740c0@mail.gmail.com>
On Tue, May 19, 2009 at 06:38:53PM +0530, srikanth krishnakar wrote:
> Hi,
>
> kernel- 2.6.29
> Debug technique: KGDB
>
> The PowerPC kernel does not initialize the PPC440 DBCR0 register. This
> prevents the use of software breakpoints in case of internal debug
> mode. Looking into head_fsl_booke.S for initialization of DBCR0 is
> used by boot-loaders.
> It seems head_44x.S lacks this step of DBCR0 register initialization.
> So fixing this with initializing the DBCR0 register as shown below :
>
> Subject: [PATCH] powerpc: 44x: Initialize DBCR0 for targets not having
> bootloader
>
> The kernel does not initialize the PPC440 DBCR0 register.
> This prevents (among other things) the use of software
> breakpoints with GDB. The boot loaders probably do initialize
> this but few targets run without a boot loader
Um.. how does this prevent the use of software breakpoints with gdb?
The trap instructions still work with IDM==0.
--
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: mpc5200 fec error
From: Grant Likely @ 2009-05-19 23:36 UTC (permalink / raw)
To: Eric Millbrandt; +Cc: linuxppc-dev
In-Reply-To: <A88094362DE0AE49A118AB9B4EB3612403F9DEBC@dekaexchange.deka.local>
On Tue, May 19, 2009 at 4:21 PM, Eric Millbrandt
<emillbrandt@dekaresearch.com> wrote:
> -----Original Message-----
> From: Wolfram Sang [mailto:w.sang@pengutronix.de]
> Sent: Tuesday, May 19, 2009 16:57
> To: Robert Schwebel
> Cc: Eric Millbrandt; linuxppc-dev@ozlabs.org
> Subject: Re: mpc5200 fec error
>
> On Tue, May 19, 2009 at 10:36:45PM +0200, Robert Schwebel wrote:
>> Wolfram, have you seen this mail? You recently tested -rt on 2.6.29,
>> right? Did you only test that on the customer hardware or also on the
>> phyCORE-MPC5200B?
>
> So far, I tried only on customer hardware, and that was 2.6.29.2-rt11.
> With
> that setup, I could work with NFS flawlessly, no real stress-testing
> though.
> Testing latest .3-rt is on my todo, will check the phyCOREs, too.
>
> Regards,
>
> =A0 Wolfram
>
> --
> Pengutronix e.K. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Wo=
lfram Sang
> |
> Industrial Linux Solutions =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | http://www.p=
engutronix.de/
> |
>
> I am able to reproduce the error using 2.6.29.2-rt11. =A0I was able to
> mitigate the problem by raising the priority of the transmit irq.
> However when running an NFS server on the pcm030 under high cpu load I
> now get
>
> [ =A0132.477503] net eth0: FEC_IEVENT_RFIFO_ERROR
> [ =A0132.892329] net eth0: FEC_IEVENT_RFIFO_ERROR
> [ =A0133.884109] net eth0: FEC_IEVENT_RFIFO_ERROR
> [ =A0134.876059] net eth0: FEC_IEVENT_RFIFO_ERROR
>
> Raising the priority of the rx irq does not seem to fix this problem
> though.
Hi Eric,
This error has been seen before in non-rt kernels. I haven't had the
chance to track it down and kill it yet. I believe there are locking
issues associated with it.
g.
>
>
> _________________________________________________________________________=
________________
>
> This e-mail and the information, including any attachments, it contains a=
re intended to be a confidential communication only to the person or entity=
to whom it is addressed and may contain information that is privileged. If=
the reader of this message is not the intended recipient, you are hereby n=
otified that any dissemination, distribution or copying of this communicati=
on is strictly prohibited. If you have received this communication in error=
, please immediately notify the sender and destroy the original message.
>
> Thank you.
>
> Please consider the environment before printing this email.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] fsldma: fix "DMA halt timeout!" errors
From: Ira Snyder @ 2009-05-19 22:42 UTC (permalink / raw)
To: linuxppc-dev, Li Yang, Dan Williams
When using the DMA controller from multiple threads at the same time, it is
possible to get lots of "DMA halt timeout!" errors printed to the kernel
log.
This occurs due to a race between fsl_dma_memcpy_issue_pending() and the
interrupt handler, fsl_dma_chan_do_interrupt(). Both call the
fsl_chan_xfer_ld_queue() function, which does not protect against
concurrent accesses to dma_halt() and dma_start().
The existing spinlock is moved to cover the dma_halt() and dma_start()
functions. Testing shows that the "DMA halt timeout!" errors disappear.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
---
drivers/dma/fsldma.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 465846c..8db3ffd 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -841,15 +841,16 @@ static void fsl_chan_xfer_ld_queue(struct fsl_dma_chan *fsl_chan)
dma_addr_t next_dest_addr;
unsigned long flags;
+ spin_lock_irqsave(&fsl_chan->desc_lock, flags);
+
if (!dma_is_idle(fsl_chan))
- return;
+ goto out_unlock;
dma_halt(fsl_chan);
/* If there are some link descriptors
* not transfered in queue. We need to start it.
*/
- spin_lock_irqsave(&fsl_chan->desc_lock, flags);
/* Find the first un-transfer desciptor */
for (ld_node = fsl_chan->ld_queue.next;
@@ -860,8 +861,6 @@ static void fsl_chan_xfer_ld_queue(struct fsl_dma_chan *fsl_chan)
fsl_chan->common.cookie) == DMA_SUCCESS);
ld_node = ld_node->next);
- spin_unlock_irqrestore(&fsl_chan->desc_lock, flags);
-
if (ld_node != &fsl_chan->ld_queue) {
/* Get the ld start address from ld_queue */
next_dest_addr = to_fsl_desc(ld_node)->async_tx.phys;
@@ -873,6 +872,9 @@ static void fsl_chan_xfer_ld_queue(struct fsl_dma_chan *fsl_chan)
set_cdar(fsl_chan, 0);
set_ndar(fsl_chan, 0);
}
+
+out_unlock:
+ spin_unlock_irqrestore(&fsl_chan->desc_lock, flags);
}
/**
--
1.5.4.3
^ permalink raw reply related
* RE: mpc5200 fec error
From: Eric Millbrandt @ 2009-05-19 22:21 UTC (permalink / raw)
To: Wolfram Sang, Robert Schwebel; +Cc: linuxppc-dev
In-Reply-To: <20090519205706.GD27476@pengutronix.de>
-----Original Message-----
From: Wolfram Sang [mailto:w.sang@pengutronix.de]=20
Sent: Tuesday, May 19, 2009 16:57
To: Robert Schwebel
Cc: Eric Millbrandt; linuxppc-dev@ozlabs.org
Subject: Re: mpc5200 fec error
On Tue, May 19, 2009 at 10:36:45PM +0200, Robert Schwebel wrote:
> Wolfram, have you seen this mail? You recently tested -rt on 2.6.29,
> right? Did you only test that on the customer hardware or also on the
> phyCORE-MPC5200B?
So far, I tried only on customer hardware, and that was 2.6.29.2-rt11.
With
that setup, I could work with NFS flawlessly, no real stress-testing
though.
Testing latest .3-rt is on my todo, will check the phyCOREs, too.
Regards,
Wolfram
--=20
Pengutronix e.K. | Wolfram Sang
|
Industrial Linux Solutions | http://www.pengutronix.de/
|
I am able to reproduce the error using 2.6.29.2-rt11. I was able to
mitigate the problem by raising the priority of the transmit irq.
However when running an NFS server on the pcm030 under high cpu load I
now get
[ 132.477503] net eth0: FEC_IEVENT_RFIFO_ERROR
[ 132.892329] net eth0: FEC_IEVENT_RFIFO_ERROR
[ 133.884109] net eth0: FEC_IEVENT_RFIFO_ERROR
[ 134.876059] net eth0: FEC_IEVENT_RFIFO_ERROR
Raising the priority of the rx irq does not seem to fix this problem
though.
_________________________________________________________________________=
________________
This e-mail and the information, including any attachments, it contains =
are intended to be a confidential communication only to the person or =
entity to whom it is addressed and may contain information that is =
privileged. If the reader of this message is not the intended recipient, =
you are hereby notified that any dissemination, distribution or copying =
of this communication is strictly prohibited. If you have received this =
communication in error, please immediately notify the sender and destroy =
the original message.
Thank you.
Please consider the environment before printing this email.
^ permalink raw reply
* Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
From: Benjamin Herrenschmidt @ 2009-05-19 21:56 UTC (permalink / raw)
To: Piotr Zięcik
Cc: Becky Bruce, Wolfgang Denk, Detlev Zundel, John Rigby, netdev,
linuxppc-dev, Scott Wood
In-Reply-To: <200905191326.29122.kosmo@semihalf.com>
On Tue, 2009-05-19 at 13:26 +0200, Piotr Zięcik wrote:
> Tuesday 19 May 2009 00:17:31 Benjamin Herrenschmidt wrote:
> >
> > We are close to the point where we can make this a runtime option
> > though, by just having a different set of dma_ops hooked in.
> >
>
> Is somebody currently working on it? If yes, where we can see
> code ?
Well, the current upstream code has the dma ops support. Becky is
massaging that more for swiotlb support which has been submitted to the
linuxppc-dev list. We haven't yet added runtime support rather than
compile time for non-cache coherent platforms, but it's becoming
reasonably easy to add now (though still needs to be done).
Cheers,
Ben
^ permalink raw reply
* Re: [PATCH 2/2] qe: add polling timeout to qe_issue_cmd()
From: Timur Tabi @ 2009-05-19 21:09 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, smaclennan
In-Reply-To: <fa686aa40905191310h3ed0efdfn4bd4b4f4b9ca0b7d@mail.gmail.com>
Grant Likely wrote:
> Hmmm, the ret value is backwards from what most coders would expect
> (zero on success, non-zero on failure). I'd personally recommend
> reversing the polarity in the macro.
The ret value is documented as being the value of the expression when the loop terminates. The reason it appears backwards is because the expression is
(in_be32(&qe_immr->cp.cecr) & QE_CR_FLG) == 0
That is, the loop should spin until the QE_CR_FLG is zero. So when the loop terminates normally, the expression (x) == 0 is true, which is equal to one.
I would expect that in most cases, the loop spins until some bit is *set*. Let's pretend that QE_CR_FLG operates this way. In that case, the call would look like this:
spin_event_timeout(in_be32(&qe_immr->cp.cecr) & QE_CR_FLG, 100, 0, ret);
At loop termination, the result of the expression will be either QE_CR_FLG or zero.
> Otherwise, feel free to add my acked-by line to both patches.
Thanks.
Ben, would you please apply this to your 'next' branch?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Becky Bruce @ 2009-05-19 20:57 UTC (permalink / raw)
To: FUJITA Tomonori; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20090519142656T.fujita.tomonori@lab.ntt.co.jp>
On May 19, 2009, at 12:27 AM, FUJITA Tomonori wrote:
> CC'ed linux-kernel
>
> On Thu, 14 May 2009 17:42:28 -0500
> Becky Bruce <beckyb@kernel.crashing.org> wrote:
>
>
>> This patch includes the basic infrastructure to use swiotlb
>> bounce buffering on 32-bit powerpc. It is not yet enabled on
>> any platforms. Probably the most interesting bit is the
>> addition of addr_needs_map to dma_ops - we need this as
>> a dma_op because the decision of whether or not an addr
>> can be mapped by a device is device-specific.
>>
>> Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
<snip>
>> +/*
>> + * Determine if an address needs bounce buffering via swiotlb.
>> + * Going forward I expect the swiotlb code to generalize on using
>> + * a dma_ops->addr_needs_map, and this function will move from
>> here to the
>> + * generic swiotlb code.
>> + */
>> +int
>> +swiotlb_arch_address_needs_mapping(struct device *hwdev,
>> dma_addr_t addr,
>> + size_t size)
>> +{
>> + struct dma_mapping_ops *dma_ops = get_dma_ops(hwdev);
>> +
>> + BUG_ON(!dma_ops);
>> + return dma_ops->addr_needs_map(hwdev, addr, size);
>> +}
>> +
>> +/*
>> + * Determine if an address is reachable by a pci device, or if we
>> must bounce.
>> + */
>> +static int
>> +swiotlb_pci_addr_needs_map(struct device *hwdev, dma_addr_t addr,
>> size_t size)
>> +{
>> + u64 mask = dma_get_mask(hwdev);
>> + dma_addr_t max;
>> + struct pci_controller *hose;
>> + struct pci_dev *pdev = to_pci_dev(hwdev);
>> +
>> + hose = pci_bus_to_host(pdev->bus);
>> + max = hose->dma_window_base_cur + hose->dma_window_size;
>> +
>> + /* check that we're within mapped pci window space */
>> + if ((addr + size > max) | (addr < hose->dma_window_base_cur))
>> + return 1;
>> +
>> + return !is_buffer_dma_capable(mask, addr, size);
>> +}
>> +
>> +static int
>> +swiotlb_addr_needs_map(struct device *hwdev, dma_addr_t addr,
>> size_t size)
>> +{
>> + return !is_buffer_dma_capable(dma_get_mask(hwdev), addr, size);
>> +}
>
> I think that swiotlb_pci_addr_needs_map and swiotlb_addr_needs_map
> don't need swiotlb_arch_range_needs_mapping() since
>
> - swiotlb_arch_range_needs_mapping() is always used with
> swiotlb_arch_address_needs_mapping().
Yes. I don't need range_needs_mapping() on ppc, so I let it default
to the lib/swiotlb.c implementation, which just returns 0. All the
determination of whether an address needs mapping comes from
swiotlb_arch_address_needs_mapping().
>
>
> - swiotlb_arch_address_needs_mapping() uses is_buffer_dma_capable()
> and powerpc doesn't overwrite swiotlb_arch_address_needs_mapping()
I *do* overwrite it. But I still use is_buffer_dma_capable(). I just
add some other checks to it in the pci case, because I need to know
what the controller has mapped as it changes the point at which I must
begin to bounce buffer.
>
>
>
> Do I miss something?
I don't think so. But let me know if I've misunderstood you.
>
>
> Anyway, we need to fix swiotlb checking code to if an area is
> DMA-capable or not.
>
> swiotlb_arch_address_needs_mapping() calls is_buffer_dma_capable() in
> dma-mapping.h but it should not. It should live in an arch-specific
> place such as arch's dma-mapping.h or something since
> is_buffer_dma_capable() is arch-specific. I didn't know that
> is_buffer_dma_capable() is arch-specific when I added it to the
> generic place.
Errrr, is_buffer_dma_capable is generic right now, unless I'm missing
something. It's in include/linux/dma-mapping.h, unless I'm getting
bitten by a slightly stale tree.
>
>
> If we have something like in arch/{x86|ia64|powerpc}/dma-mapping.h:
>
> static inline int is_buffer_dma_capable(struct device *dev,
> dma_addr_t addr, size_t size)
>
> then we don't need two checking functions, address_needs_mapping and
> range_needs_mapping.
It's never been clear to me *why* we had both in the first place - if
you can explain this, I'd be grateful :)
It actually looks like we want to remove the dma_op that I created for
addr_needs_map because of the perf hit.... it gets called a ton of
times, many times on addresses that don't actually require bounce
buffering (and thus, are more sensitive to the minor performance
hit). We are looking instead at adding a per-device variable that is
used to determine if we need to bounce (in addition to
is_buffer_dma_capable) that would live inside archdata - see the other
posts on this thread for details (we're still hashing out exactly how
we want to do this).
Cheers,
Becky
^ permalink raw reply
* Re: mpc5200 fec error
From: Wolfram Sang @ 2009-05-19 20:57 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linuxppc-dev, Eric Millbrandt
In-Reply-To: <20090519203645.GW19843@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 641 bytes --]
On Tue, May 19, 2009 at 10:36:45PM +0200, Robert Schwebel wrote:
> Wolfram, have you seen this mail? You recently tested -rt on 2.6.29,
> right? Did you only test that on the customer hardware or also on the
> phyCORE-MPC5200B?
So far, I tried only on customer hardware, and that was 2.6.29.2-rt11. With
that setup, I could work with NFS flawlessly, no real stress-testing though.
Testing latest .3-rt is on my todo, will check the phyCOREs, too.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] maps/mtd-ram: add an of-platform driver
From: Grant Likely @ 2009-05-19 20:36 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, linux-mtd, ben-linux
In-Reply-To: <20090519203014.GC27476@pengutronix.de>
On Tue, May 19, 2009 at 2:30 PM, Wolfram Sang <w.sang@pengutronix.de> wrote=
:
>> This name is too generic for an of_platform device. =A0'mtd' needs to be
>> in there somewhere.
>
> Will "of-mtd-ram" do? (I'd think so)
fine by me.
g
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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