On Mon, 2009-07-06 at 07:47 +0530, Subrata Modak wrote:
> Hi,
>
> Is there somebody else whom i should also address to get an attention
> for this patch ? I apolozise if i have not included someone. Kindly
> connect to the concerned.
I'm putting your patch to l2-mtd-2.6.git.
--
Best regards,
Ar
On Fri, 2009-07-10 at 08:59 +0300, Artem Bityutskiy wrote:
> On Mon, 2009-07-06 at 07:47 +0530, Subrata Modak wrote:
> > Hi,
> >
> > Is there somebody else whom i should also address to get an attention
> > for this patch ? I apolozise if i have not included someone. Kindly
> > connect to the conc
On Mon, 2009-06-01 at 16:32 +0100, Ian Campbell wrote:
> This series:
> * removes the swiotlb_(arch_)_phys_to_bus and bus_to_phys __weak
> hooks, replacing them with an architecture-specific phys_to_dma and
> dma_to_phys interface. These are used by both PowerPC and Xen to
> provide the corre
On Fri, 10 Jul 2009 07:12:36 +0200
Ingo Molnar wrote:
>
> * FUJITA Tomonori wrote:
>
> > - removes unused (and unnecessary) hooks in swiotlb.
> >
> > - adds dma_capable() and converts swiotlb to use it. It can be used to
> > know if a memory area is dma capable or not. I added
> > is_buffer_d
* FUJITA Tomonori wrote:
> - removes unused (and unnecessary) hooks in swiotlb.
>
> - adds dma_capable() and converts swiotlb to use it. It can be used to
> know if a memory area is dma capable or not. I added
> is_buffer_dma_capable() for the same purpose long ago but it turned
> out that the
On Thu, Jul 09, 2009 at 02:31:53PM -0500, Edmar Wienskoski-RA8797 wrote:
> I understand your arguments, but there is something inconsistent about this.
> If I change the script to be:
>_end3 = . ;
>. = _end3;
>. = ALIGN(PAGE_SIZE);
>_end = . ;
>PROVIDE32 (end
On Thu, Jul 09, 2009 at 02:31:53PM -0500, Edmar Wienskoski-RA8797 wrote:
> Kumar Gala wrote:
>>
>> On Jul 8, 2009, at 11:40 PM, Alan Modra wrote:
>>
>>> On Wed, Jul 08, 2009 at 10:52:59PM -0500, Kumar Gala wrote:
To further verify this if I switch the -me500 to -mspe and build things
seem
I'm trying to convert POWERPC to use asm-generic/dma-mapping-common.h.
POWERPC needs addr_needs_map() in struct dma_mapping_ops for SWIOTLB
support but I want to avoid add addr_needs_map() in struct
dma_map_ops. IIRC, you guys think it as a temporary solution and
talked about defining something li
swiotlb_bus_to_virt is unncessary; we can use swiotlb_bus_to_phys and
phys_to_virt instead.
Signed-off-by: FUJITA Tomonori
---
arch/powerpc/kernel/dma-swiotlb.c | 10 --
lib/swiotlb.c | 34 --
2 files changed, 16 insertions(+), 28 d
This converts swiotlb to use phys_to_dma and dma_to_phys instead of
swiotlb_phys_to_bus() and swiotlb_bus_to_phys().
swiotlb_phys_to_bus() and swiotlb_bus_to_phys() are not necessary so
this patch also removes them.
Signed-off-by: FUJITA Tomonori
---
include/linux/swiotlb.h |5 -
lib/sw
Nobody uses swiotlb_arch_range_needs_mapping().
Signed-off-by: FUJITA Tomonori
---
arch/x86/kernel/pci-swiotlb.c |5 -
include/linux/swiotlb.h |2 --
lib/swiotlb.c | 15 ++-
3 files changed, 2 insertions(+), 20 deletions(-)
diff --git a/arch/x86/k
This converts swiotlb to use dma_capable() instead of
swiotlb_arch_address_needs_mapping() and is_buffer_dma_capable().
Signed-off-by: FUJITA Tomonori
---
lib/swiotlb.c | 24 +---
1 files changed, 5 insertions(+), 19 deletions(-)
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
This adds two functions, phys_to_dma() and dma_to_phys() to x86, IA64
and powerpc. swiotlb uses them. phys_to_dma() converts a physical
address to a dma address. dma_to_phys() does the opposite.
Signed-off-by: FUJITA Tomonori
---
arch/ia64/include/asm/dma-mapping.h| 10 ++
arch/pow
swiotlb doesn't use swiotlb_arch_address_needs_mapping(); it uses
dma_capalbe(). We can remove unnecessary
swiotlb_arch_address_needs_mapping().
We can remove swiotlb_addr_needs_map() and is_buffer_dma_capable() in
swiotlb_pci_addr_needs_map() too; dma_capable() handles the features
that both prov
Nobody uses swiotlb_alloc_boot().
Signed-off-by: FUJITA Tomonori
---
arch/x86/kernel/pci-swiotlb.c |5 -
include/linux/swiotlb.h |2 --
lib/swiotlb.c |7 +--
3 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/pci-swiotlb.c b/
Nobody uses swiotlb_alloc().
Signed-off-by: FUJITA Tomonori
---
arch/x86/kernel/pci-swiotlb.c |5 -
include/linux/swiotlb.h |2 --
lib/swiotlb.c |8 ++--
3 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch
Signed-off-by: FUJITA Tomonori
---
arch/x86/kernel/pci-dma.c |2 +-
arch/x86/kernel/pci-gart_64.c |5 ++---
arch/x86/kernel/pci-nommu.c |2 +-
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index 1a041bc..3c94
dma_capable() eventually replaces is_buffer_dma_capable(), which tells
if a memory area is dma-capable or not. The problem of
is_buffer_dma_capable() is that it doesn't take a pointer to struct
device so it doesn't work for POWERPC.
Signed-off-by: FUJITA Tomonori
---
arch/powerpc/include/asm/dma
dma_capable() eventually replaces is_buffer_dma_capable(), which tells
if a memory area is dma-capable or not. The problem of
is_buffer_dma_capable() is that it doesn't take a pointer to struct
device so it doesn't work for POWERPC.
Signed-off-by: FUJITA Tomonori
---
arch/x86/include/asm/dma-map
- removes unused (and unnecessary) hooks in swiotlb.
- adds dma_capable() and converts swiotlb to use it. It can be used to
know if a memory area is dma capable or not. I added
is_buffer_dma_capable() for the same purpose long ago but it turned
out that the function doesn't work on POWERPC.
This
dma_capable() eventually replaces is_buffer_dma_capable(), which tells
if a memory area is dma-capable or not. The problem of
is_buffer_dma_capable() is that it doesn't take a pointer to struct
device so it doesn't work for POWERPC.
Signed-off-by: FUJITA Tomonori
---
arch/ia64/include/asm/dma-ma
phys_to_dma() and dma_to_phys() are used instead of
swiotlb_phys_to_bus() and swiotlb_bus_to_phys().
Signed-off-by: FUJITA Tomonori
---
arch/powerpc/kernel/dma-swiotlb.c | 11 ---
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/kernel/dma-swiotlb.c
b/arch/
is_buffer_dma_capable() was replaced with dma_capable().
is_buffer_dma_capable() tells if a buffer is dma-capable or
not. However, it doesn't take a pointer to struct device so it doesn't
work for POWERPC.
Signed-off-by: FUJITA Tomonori
---
include/linux/dma-mapping.h |5 -
1 files chan
phys_to_dma() and dma_to_phys() are used instead of
swiotlb_phys_to_bus() and swiotlb_bus_to_phys().
Signed-off-by: FUJITA Tomonori
---
arch/x86/kernel/pci-swiotlb.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch/x86/kernel
Ok, is this the one you want me to push upstream?
doug t
--- On Thu, 7/9/09, Ira W. Snyder wrote:
From: Ira W. Snyder
Subject: [PATCH v2] edac: mpc85xx: add support for mpc83xx memory controller
To: bluesmoke-de...@lists.sourceforge.net, "Dave Jiang" ,
"Kumar Gala" , linuxppc-...@ozlabs.org
Hi Mark,
On Thu, Jul 09, 2009 at 02:16:48PM -0400, Mark Bishop wrote:
> I haven't seen this before - the '##' in the function name. This is ANCII C?
Of course. See pp. 90-91 in "The C Programming Language" second edition.
>
> #define MPC83XX_SPI_TX_BUF(type) \
> u3
Kumar Gala wrote:
On Jul 8, 2009, at 11:40 PM, Alan Modra wrote:
On Wed, Jul 08, 2009 at 10:52:59PM -0500, Kumar Gala wrote:
To further verify this if I switch the -me500 to -mspe and build things
seem to be ok. This further points at some APU section related bug.
Like omitting .PPC.EMB.ap
Chris Friesen wrote:
> Hi all,
>
> This probably isn't the right place to ask about this, but does anyone
> know where the implied memory barrier happens for pthread mutexes in the
> uncontended case? I'm looking at the glibc code and I don't see any
> barrier instructions for mutexes, only semap
Hi all,
This probably isn't the right place to ask about this, but does anyone
know where the implied memory barrier happens for pthread mutexes in the
uncontended case? I'm looking at the glibc code and I don't see any
barrier instructions for mutexes, only semaphores and spinlocks.
Thanks,
C
On Thu, Jul 09, 2009 at 03:15:29PM -0500, Kumar Gala wrote:
>
> On Jul 9, 2009, at 2:35 PM, Ira W. Snyder wrote:
>
>> On Thu, Jul 09, 2009 at 01:25:43PM -0500, Kumar Gala wrote:
>>>
>>> On Jul 9, 2009, at 1:17 PM, Ira W. Snyder wrote:
>>>
On Thu, Jul 09, 2009 at 12:58:53PM -0500, Kumar Gala wr
On Thu, Jul 9, 2009 at 2:33 PM, Wolfgang Grandegger wrote:
> Hello,
>
> I'm currently trying to implement NAPI for the FEC on the MPC5200 to
> solve the well known problem, that network packet storms can cause
> interrupt flooding, which may totally block the system.
Good to hear it! Thanks for t
Hello,
I'm currently trying to implement NAPI for the FEC on the MPC5200 to
solve the well known problem, that network packet storms can cause
interrupt flooding, which may totally block the system. The NAPI
implementation, in principle, is straight forward and works
well under normal and moderate
On Jul 9, 2009, at 2:35 PM, Ira W. Snyder wrote:
On Thu, Jul 09, 2009 at 01:25:43PM -0500, Kumar Gala wrote:
On Jul 9, 2009, at 1:17 PM, Ira W. Snyder wrote:
On Thu, Jul 09, 2009 at 12:58:53PM -0500, Kumar Gala wrote:
Hello Kumar,
I must not understand something going on here. Your propos
Add support for the Freescale MPC83xx memory controller to the existing
driver for the Freescale MPC85xx memory controller. The only difference
between the two processors are in the CS_BNDS register parsing code, which
has been changed so it will work on both processors.
The L2 cache controller do
On Thu, Jul 09, 2009 at 01:25:43PM -0500, Kumar Gala wrote:
>
> On Jul 9, 2009, at 1:17 PM, Ira W. Snyder wrote:
>
>> On Thu, Jul 09, 2009 at 12:58:53PM -0500, Kumar Gala wrote:
Hello Kumar,
I must not understand something going on here. Your proposed code
doesn't work at all on
Quoting Baruch Siach :
Hi Mark,
On Thu, Jul 09, 2009 at 02:16:48PM -0400, Mark Bishop wrote:
I haven't seen this before - the '##' in the function name. This
is ANCII C?
Of course. See pp. 90-91 in "The C Programming Language" second edition.
Wow, thanks. I missed that little nugget
On Thu, Jul 09, 2009 at 01:14:28PM -0500, Kumar Gala wrote:
> On Jul 9, 2009, at 11:39 AM, Dale Farnsworth wrote:
>> We have found the following workaround to be useful.
>> Thanks to Andrew Jenner at Code Sourcery.
>>
>> -Dale
>>
>> Dale Farnsworth
>> MontaVista Software
>>
>> diff --git a/arch/pow
This patch simply adds four eeprom nodes to MPC8548CDS' device tree.
Signed-off-by: Anton Vorontsov
---
arch/powerpc/boot/dts/mpc8548cds.dts | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8548cds.dts
b/arch/powerpc/boot/dts/
I haven't seen this before - the '##' in the function name. This is ANCII C?
#define MPC83XX_SPI_TX_BUF(type)\
u32 mpc83xx_spi_tx_buf_##type(struct mpc83xx_spi *mpc83xx_spi) \
{ \
u32 data;
On Jul 9, 2009, at 1:17 PM, Ira W. Snyder wrote:
On Thu, Jul 09, 2009 at 12:58:53PM -0500, Kumar Gala wrote:
Hello Kumar,
I must not understand something going on here. Your proposed code
doesn't work at all on my board. The
/sys/devices/system/edac/mc/mc0/size_mb doesn't come out correctly.
On Thu, Jul 09, 2009 at 12:58:53PM -0500, Kumar Gala wrote:
>> Hello Kumar,
>>
>> I must not understand something going on here. Your proposed code
>> doesn't work at all on my board. The
>> /sys/devices/system/edac/mc/mc0/size_mb doesn't come out correctly.
>
> What does it come out as? How much
On Jul 9, 2009, at 11:39 AM, Dale Farnsworth wrote:
On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
We are seeing an issue w/ld and kernel linking of 32-bit kernels.
The ld from fedora 11 (2.19.51.0.2-17.fc11 20090204) ends not
providing
the proper address for _end.
Building s
Hello Kumar,
I must not understand something going on here. Your proposed code
doesn't work at all on my board. The
/sys/devices/system/edac/mc/mc0/size_mb doesn't come out correctly.
What does it come out as? How much memory do you have in the system?
The attached patch DOES work on my board
On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
> We are seeing an issue w/ld and kernel linking of 32-bit kernels.
>
> The ld from fedora 11 (2.19.51.0.2-17.fc11 20090204) ends not providing
> the proper address for _end.
>
> Building stock v2.6.30 w/the mpc85xx_defconfig we get:
>
>
On Wed, Jul 08, 2009 at 03:58:02PM -0500, Kumar Gala wrote:
>
> On Jul 8, 2009, at 2:33 PM, Ira W. Snyder wrote:
>
>> On Wed, Jul 08, 2009 at 01:09:39PM -0500, Kumar Gala wrote:
>>>
>>> On Jul 8, 2009, at 11:19 AM, Ira W. Snyder wrote:
>>>
Add support for the Freescale MPC83xx memory controlle
On Jul 8, 2009, at 11:40 PM, Alan Modra wrote:
On Wed, Jul 08, 2009 at 10:52:59PM -0500, Kumar Gala wrote:
To further verify this if I switch the -me500 to -mspe and build
things
seem to be ok. This further points at some APU section related bug.
Like omitting .PPC.EMB.apuinfo from your k
Hallo,
On Monday 05 January 2009 16:31:33 Grant Likely wrote:
> DMA support is now in mainline, but it is disabled by
> default ...
I had problems using ATA DMA on an own MPC5200B board, too. This board
has no problems at all using DMA33 with DENX 2.4.25, with all kinds of
automotive disks from
Original-Nachricht
> Datum: Wed, 08 Jul 2009 16:13:10 +0200
> Von: Takashi Iwai
> An: Benjamin Herrenschmidt
> CC: Gerhard Pircher , linuxppc-...@ozlabs.org
> Betreff: Re: ALSA fixes for non-coherent ppc32 again
> At Wed, 08 Jul 2009 13:01:50 +1000,
> Benjamin Herrenschmidt wr
Hi,
I'm on a mpc5121 platform, kernel 2.6.24.6, and I'm using the mpc512x_psc_spi
driver to communicate with a touch screen controller.
I'm sending commands and reading data from the controller using 24-bit packet
(3 bytes).
The speed of the SPI is set to 640 KHz.
I thought that I would need 8/6
49 matches
Mail list logo
