On Fri, May 15, 2009 at 08:39:24PM +0200, Gabriel Paubert wrote:
> After 2.6.29, PPC no more admits passing NULL to the dev parameter of
> the DMA API. The result is a BUG followed by solid lock-up when the
> mv643xx_eth driver brings an interface up. The following patch makes
> the driver work
Use the DMA_SLAVE capability of the DMAEngine API to copy/from a
scatterlist into an arbitrary list of hardware address/length pairs.
This allows a single DMA transaction to copy data from several different
devices into a scatterlist at the same time.
This also adds support to enable some control
Hi,
As requested here the same patch but now with a signed-off line which I forgot.
Regards,
Roderick Colenbrander
Signed-off-by: Roderick Colenbrander
>From f46fa90e4d066767cc4fc1c5b8dc2f9ee013ea0a Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander
Date: Tue, 14 Apr 2009 15:49:32 +0200
Su
On Fri, 2009-05-15 at 10:33 -0400, Steven Rostedt wrote:
> After upgrading my distcc boxes from gcc 4.2.2 to 4.4.0, the function
> graph tracer broke. This was discovered on my x86 boxes.
>
> The issue is that gcc used the same register for an output as it did for
> an input in an asm statement.
Hi,
As requested here the same patch but now with a signed-off line which I forgot.
Regards,
Roderick Colenbrander
Signed-off-by: Roderick Colenbrander
>From 2b34a315b18834448c0a8218d4da85ffaf76039e Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander
Date: Tue, 14 Apr 2009 15:45:07 +0200
Su
Roderick,
These two patches are missing a "signed-off-by" line from you. Can
you please reply with one confirming that the patches adhere to the
Developer's Certificate of Origin from
Documentation/SubmittingPatches?
Thanks,
g.
On Wed, Apr 15, 2009 at 2:40 AM, Roderick Colenbrander
wrote:
> Hi
When creating a DMA transaction with multiple descriptors, the async_tx
cookie is set to 0 for each descriptor in the chain, excluding the last
descriptor, whose cookie is set to -EBUSY.
When fsl_dma_tx_submit() is run, it only assigns a cookie to the first
descriptor. All of the remaining descrip
After 2.6.29, PPC no more admits passing NULL to the dev parameter of
the DMA API. The result is a BUG followed by solid lock-up when the
mv643xx_eth driver brings an interface up. The following patch makes
the driver work on my Pegasos again; it is mostly a search and replace
of NULL by mp->dev
On the 83xx controller, snooping is necessary for the DMA controller to
ensure cache coherence with the CPU when transferring to/from RAM.
The last descriptor in a chain will always have the End-of-Chain interrupt
bit set, so we can set the snoop bit while adding the End-of-Chain
interrupt bit.
S
From: John Linn
Added support for the new xps tft controller. The new core
has PLB interface support in addition to existing DCR interface.
Removed platform device support as both MicroBlaze and PowerPC
use device tree.
Previously, the dcr interface was assumed to be used in mmio mode,
and the
Since PPC_MUTIPLATFORM was removed, it was impossible to select the
driver for mv643xx_eth on the Pegasos. Fix by allowing to select
the driver on CHRP platforms; Pegasos is a CHRP platform and the driver
will not work wihtout arch/powerpc/platforms/chrp/pegasos_eth.
The patch also removes all ref
Refresh and set these options:
CONFIG_SYSFS_DEPRECATED_V2: y -> n
CONFIG_INPUT_JOYSTICK: y -> n
CONFIG_HID_SONY:n -> m
CONFIG_RTC_DRV_PS3: - -> m
Signed-off-by: Geoff Levand
---
Ben,
Please apply for 2.6.30.
-Geoff
arch/powerpc/configs/ps3_defconfig | 105 ++
Kumar Gala wrote:
From: Dave Liu
The bit 11 of command description is reserved bit in Freescale
SATA controller and needs to be set to '1'. This is needed to
make sure the last write from the controller to the buffer
descriptor is seen before an interrupt is raised.
Signed-off-by: Dave Liu
S
Kumar Gala wrote:
We we build with dma_addr_t as a 64-bit quantity we get:
drivers/ata/sata_fsl.c: In function 'sata_fsl_fill_sg':
drivers/ata/sata_fsl.c:340: warning: format '%x' expects type 'unsigned int',
but argument 4 has type 'dma_addr_t'
Signed-off-by: Kumar Gala
---
* v2: fixed extra
When preparing a memcpy operation, if the kernel fails to allocate memory
for a link descriptor after the first link descriptor has already been
allocated, then some memory will never be released. Fix the problem by
walking the list of allocated descriptors backwards, and freeing the
allocated desc
On Fri, May 15, 2009 at 07:54:51AM +0200, Heiko Schocher wrote:
> Scott Wood wrote:
> > We should proabbly leave out the ranges altogether, and have u-boot
> > populate it from the mappings it establishes.
>
> No, I vote for manipulating just the entries, which u-boot dynamically
> detect, and let
Hello All,
Quite a while back Michael Ellerman had posted a patch to add support to xmon
to print the contents of the console log pointed to by __log_buf.
Here's the link to that patch -
http://ozlabs.org/pipermail/linuxppc64-dev/2005-March/003657.html
I've ported the patch in the above link to
On Fri, May 15, 2009 at 2:36 AM, Dimiter Popoff wrote:
> Hi people,
>
> I am porting my (not linux) OS to the 5200. I went all the
> way understanding how the SDMA works and programming what
> I needed for it so things are now pretty stable in terms
> of disk I/O and system memory -> PCI (offscree
- refactor printk with pr_info/pr_cont
- use '=' in output to connect key/value pairs
Signed-off-by: Wolfram Sang
Cc: John Rigby
Cc: Grant Likely
---
arch/powerpc/platforms/512x/clock.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
Index: arch/powerpc/platforms/512x/clock
After upgrading my distcc boxes from gcc 4.2.2 to 4.4.0, the function
graph tracer broke. This was discovered on my x86 boxes.
The issue is that gcc used the same register for an output as it did for
an input in an asm statement. I first thought this was a bug in gcc and
reported it. I was not
Esben Haabendal wrote on 15/05/2009 14:52:28:
>
> Your new patch also does not work.
>
> Have you tested it?
sure, works fine. I haven't stressed it too much though.
>
> I already tried something very much what you sent here, I believe the
> only difference was that I named the "last" variable "
Your new patch also does not work.
Have you tested it?
I already tried something very much what you sent here, I believe the
only difference was that I named the "last" variable "stop". I also
tried several other aproaches, and none of them worked. I would
appreciate not to have to test all of t
On May 15, 2009, at 7:47 AM, Kumar Gala wrote:
We shouldn't directly access sysdata to get the device node. We
should
be calling pci_device_to_OF_node().
Signed-off-by: Kumar Gala
---
* Updated based on sfr's iseries pci fix patch
arch/powerpc/platforms/iseries/iommu.c |2 +-
arch/powe
For those that care and have an interest I've posted a 'swiotlb'
branch that includes all the patches needed for running with large
amounts of memory on MPC8641 or MPC85xx based systems. This branch is
based on v2.6.30-rc5 + next branch + core swiotlb patches
git://git.kernel.org/p
We shouldn't directly access sysdata to get the device node. We should
be calling pci_device_to_OF_node().
Signed-off-by: Kumar Gala
---
* Updated based on sfr's iseries pci fix patch
arch/powerpc/platforms/iseries/iommu.c |2 +-
arch/powerpc/platforms/iseries/pci.c |8
2 fi
Hello All,
I upgraded the Linux kernel version from 2.6.20 to 2.6.23 on eval
board mpc8313erdb. Then I wrote a simple hello_world kernel module for
testing but when I do make it gives following compilation error.
Whereas I did not had this problem with kernel 2.6.20 !!!
It says; 'include/asm/curr
On Thu, 2009-05-14 at 11:49 -0400, Steven Rostedt wrote:
> I'm fine with this patch, but it should go via the PPC tree.
Yep, it went To linux-ppc, CC you - so that's the plan, I'll nag Ben to
pick it up.
> Acked-by: Steven Rostedt
Thanks for the ack.
cheers
signature.asc
Description: This is
Esben Haabendal wrote on 15/05/2009 12:18:39:
>
> I have now spent a few hours trying a lot of different paths to fix
> this approach, but I simply cannot find a way to get i2c read to work
> without a trailing STOP condition with this controller.
I found a bug which lets me remove the "fix" and
Hi
Your patch (and the small addition to mpc_i2c_start) does not work for me.
[ 35.765803] mpc_xfer()
[ 35.785480] writeccr 0
[ 35.785505] writeccr 80
[ 35.785523] mpc_xfer: 1 bytes to 2c:W - 1 of 2 messages
[ 35.798817] mpc_write addr=2c len=1 restart=0
[ 35.815327] writeccr f0
[ 3
Support EDAC INT mode for AMD8131 EDAC driver, which may post upstream
NMI interrupt request messages that will latch MPIC INT0 pin.
Following aspects for this patch have been tested:
1, module initialization and deletion for NMI mode;
2, creation and deletion for the mapping between hwirq==0 to a
Support EDAC INT mode for Hypertransport devices, where southbridge
NMI Request messages posted through Hypertransport Channel will
be transferred to a MPIC interrupt instance that latches MPIC INT0
pin. Also, Hypertransport Hostbridge controller may latch MPIC INT2
pin for Hypertransport Link Erro
Support EDAC INT mode and add a new EDAC MCE mode for CPC925 EDAC driver.
CPC925 Hypertransport hostbridge controller may trigger interrupt that
latches MPIC INT2 pin on Hypertransport Link Errors, and generate MCE on
memory ECC Errors and Processor Interface Errors.
The global variable "edac_op_s
Support EDAC INT mode for AMD8111 EDAC driver, which may post upstream
NMI interrupt request messages that will latch MPIC INT0 pin.
Following aspects for this patch have been tested:
1, module initialization and deletion for NMI mode;
2, creation and deletion for the mapping between hwirq==0 to a
Comments:
-
What to be added
-
1, Support EDAC INT mode on Maple platform, where CPC925 Hypertransport
hostbridge controller will latch MPIC INT0 pin on receiving upstream
NMI request messages with vector == 0 that posted from Hypertransport
southbridges su
On Fri, May 15, 2009 at 3:33 PM, Jan Neskudla wrote:
> On Wed, 2009-05-13 at 18:57 +0800, ext Li Yang wrote:
>> cc'ed LKML
>>
>> On Tue, May 12, 2009 at 5:17 PM, Jan Neskudla
>> wrote:
>> > Hallo
>> >
>> > we'd likes to use a RapidIO as a general communication bus on our new
>> > product, and so
Hi people,
I am porting my (not linux) OS to the 5200. I went all the
way understanding how the SDMA works and programming what
I needed for it so things are now pretty stable in terms
of disk I/O and system memory -> PCI (offscreen window
buffers -> PCI display framebuffer).
And I wanted to ma
Hi Linus !
Here are some updates for .30. A bit more than I would have hoped at
this stage in the game, but I've been MIA for a while, first on vacation
and then carried off to a customer issue, and so a lot of this have
actually been around for some time. There are bug fixes and defconfig
updates
On Wed, 2009-05-13 at 18:57 +0800, ext Li Yang wrote:
> cc'ed LKML
>
> On Tue, May 12, 2009 at 5:17 PM, Jan Neskudla
> wrote:
> > Hallo
> >
> > we'd likes to use a RapidIO as a general communication bus on our new
> > product, and so I have some questions about general design of Linux RIO
> > su
38 matches
Mail list logo
