RE: [PATCH] ibm_newemac: Add support for Arches CPU0 SGMII0 to CPU1SGMII0
On Fri, 2009-01-16 at 16:14 -0800, Victor Gallardo wrote: > Hi Josh, > > I see you are delegated for this patch submission any ideas when it will be > accepted. > > http://patchwork.ozlabs.org/patch/6814/ Looks like it fell through the cracks. Can you resend it to both our list and net...@vger.kernel.org ? Keep CC'me, I'll ack it and then it will be up to the networking folks to pick it up. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] ibm_newemac: Add support for Arches CPU0 SGMII0 to CPU1SGMII0
Hi Josh, I see you are delegated for this patch submission any ideas when it will be accepted. http://patchwork.ozlabs.org/patch/6814/ Thanks, -Victor Gallardo -Original Message- From: linuxppc-dev-bounces+vgallardo=amcc@ozlabs.org [mailto:linuxppc-dev-bounces+vgallardo=amcc@ozlabs.org] On Behalf Of Victor Gallardo Sent: Monday, November 10, 2008 10:07 AM To: Josh Boyer; b...@kernel.crashing.org Cc: linuxppc-dev@ozlabs.org Subject: RE: [PATCH] ibm_newemac: Add support for Arches CPU0 SGMII0 to CPU1SGMII0 Hello Josh and Ben, Who should I ask to get this patch integrated into the Linux tree? http://ozlabs.org/pipermail/linuxppc-dev/2008-November/064834.html Thanks, Victor Gallardo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] infiniband/ehca: use consistent type
Hi Roland, On Fri, 16 Jan 2009 14:51:30 -0800 Roland Dreier wrote: > > > Sorry to appear picky, but how is that different from the patch "powerpc: > > cleanup from powerpc l64 to ll64 change: drivers/infiniband" that I sent > > to you on Jan 7? > > Well, I didn't lose my version and forget all about it ;) I figured it was something simple. > Seriously, I must have lost that patch, sorry about that. I'll dig it > out and replace mine so you get credit. Thanks. /me needs all the credit he can get :-) -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpdpzhnuOeeq.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] infiniband/ehca: use consistent type
> Sorry to appear picky, but how is that different from the patch "powerpc: > cleanup from powerpc l64 to ll64 change: drivers/infiniband" that I sent > to you on Jan 7? Well, I didn't lose my version and forget all about it ;) Seriously, I must have lost that patch, sorry about that. I'll dig it out and replace mine so you get credit. - R. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] infiniband/ehca: use consistent type
Hi Roland, On Fri, 16 Jan 2009 14:36:27 -0800 Roland Dreier wrote: > > I'm going to apply this for 2.6.29, since the change to the u64 type > went upstream, so ehca spews a bunch of warnings now. Thanks. > I'll also add the following patch to fix all the printk format warnings: > > IB/ehca: Fix printk format warnings from u64 type change Sorry to appear picky, but how is that different from the patch "powerpc: cleanup from powerpc l64 to ll64 change: drivers/infiniband" that I sent to you on Jan 7? -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpYc6UOcpEmq.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] infiniband/ehca: use consistent type
I'm going to apply this for 2.6.29, since the change to the u64 type
went upstream, so ehca spews a bunch of warnings now.
I'll also add the following patch to fix all the printk format warnings:
IB/ehca: Fix printk format warnings from u64 type change
Commit fe21 ("powerpc: Change u64/s64 to a long long integer
type") changed u64 from unsigned long to unsigned long long, which
means that printk formats for printing u64 values should use "ll"
instead of "l" to avoid warnings. Fix all the places affected by this
in ehca.
Signed-off-by: Roland Dreier
---
drivers/infiniband/hw/ehca/ehca_cq.c | 16 ++--
drivers/infiniband/hw/ehca/ehca_hca.c|2 +-
drivers/infiniband/hw/ehca/ehca_irq.c| 18 ++--
drivers/infiniband/hw/ehca/ehca_main.c |6 +-
drivers/infiniband/hw/ehca/ehca_mcast.c |4 +-
drivers/infiniband/hw/ehca/ehca_mrmw.c | 144 +++---
drivers/infiniband/hw/ehca/ehca_qp.c | 32
drivers/infiniband/hw/ehca/ehca_reqs.c |2 +-
drivers/infiniband/hw/ehca/ehca_sqp.c|2 +-
drivers/infiniband/hw/ehca/ehca_tools.h |2 +-
drivers/infiniband/hw/ehca/ehca_uverbs.c |2 +-
drivers/infiniband/hw/ehca/hcp_if.c | 30 +++---
12 files changed, 130 insertions(+), 130 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_cq.c
b/drivers/infiniband/hw/ehca/ehca_cq.c
index 2f4c28a..97e4b23 100644
--- a/drivers/infiniband/hw/ehca/ehca_cq.c
+++ b/drivers/infiniband/hw/ehca/ehca_cq.c
@@ -196,7 +196,7 @@ struct ib_cq *ehca_create_cq(struct ib_device *device, int
cqe, int comp_vector,
if (h_ret != H_SUCCESS) {
ehca_err(device, "hipz_h_alloc_resource_cq() failed "
-"h_ret=%li device=%p", h_ret, device);
+"h_ret=%lli device=%p", h_ret, device);
cq = ERR_PTR(ehca2ib_return_code(h_ret));
goto create_cq_exit2;
}
@@ -232,7 +232,7 @@ struct ib_cq *ehca_create_cq(struct ib_device *device, int
cqe, int comp_vector,
if (h_ret < H_SUCCESS) {
ehca_err(device, "hipz_h_register_rpage_cq() failed "
-"ehca_cq=%p cq_num=%x h_ret=%li counter=%i "
+"ehca_cq=%p cq_num=%x h_ret=%lli counter=%i "
"act_pages=%i", my_cq, my_cq->cq_number,
h_ret, counter, param.act_pages);
cq = ERR_PTR(-EINVAL);
@@ -244,7 +244,7 @@ struct ib_cq *ehca_create_cq(struct ib_device *device, int
cqe, int comp_vector,
if ((h_ret != H_SUCCESS) || vpage) {
ehca_err(device, "Registration of pages not "
"complete ehca_cq=%p cq_num=%x "
-"h_ret=%li", my_cq, my_cq->cq_number,
+"h_ret=%lli", my_cq, my_cq->cq_number,
h_ret);
cq = ERR_PTR(-EAGAIN);
goto create_cq_exit4;
@@ -252,7 +252,7 @@ struct ib_cq *ehca_create_cq(struct ib_device *device, int
cqe, int comp_vector,
} else {
if (h_ret != H_PAGE_REGISTERED) {
ehca_err(device, "Registration of page failed "
-"ehca_cq=%p cq_num=%x h_ret=%li "
+"ehca_cq=%p cq_num=%x h_ret=%lli "
"counter=%i act_pages=%i",
my_cq, my_cq->cq_number,
h_ret, counter, param.act_pages);
@@ -266,7 +266,7 @@ struct ib_cq *ehca_create_cq(struct ib_device *device, int
cqe, int comp_vector,
gal = my_cq->galpas.kernel;
cqx_fec = hipz_galpa_load(gal, CQTEMM_OFFSET(cqx_fec));
- ehca_dbg(device, "ehca_cq=%p cq_num=%x CQX_FEC=%lx",
+ ehca_dbg(device, "ehca_cq=%p cq_num=%x CQX_FEC=%llx",
my_cq, my_cq->cq_number, cqx_fec);
my_cq->ib_cq.cqe = my_cq->nr_of_entries =
@@ -307,7 +307,7 @@ create_cq_exit3:
h_ret = hipz_h_destroy_cq(adapter_handle, my_cq, 1);
if (h_ret != H_SUCCESS)
ehca_err(device, "hipz_h_destroy_cq() failed ehca_cq=%p "
-"cq_num=%x h_ret=%li", my_cq, my_cq->cq_number, h_ret);
+"cq_num=%x h_ret=%lli", my_cq, my_cq->cq_number,
h_ret);
create_cq_exit2:
write_lock_irqsave(&ehca_cq_idr_lock, flags);
@@ -355,7 +355,7 @@ int ehca_destroy_cq(struct ib_cq *cq)
h_ret = hipz_h_destroy_cq(adapter_handle, my_cq, 0);
if (h_ret == H_R_STATE) {
/* cq in err: read err data and destroy it forcibly */
- ehca_dbg(device, "ehca_cq=%p cq_num=%x ressource=%lx in err "
+ ehca_dbg(device, "ehca_cq=%p cq_num=%x reso
Re: Re[2]: [PATCH 07/11] md: rewrite handle_stripe_dirtying6 in asynchronous way
On Fri, Jan 16, 2009 at 7:24 AM, Yuri Tikhonov wrote: >> Ok, I now see why this change was made. Please make this changelog >> more descriptive than "Rewrite handle_stripe_dirtying6 function to >> work asynchronously." > > Sure, how about the following: > > " > > md: rewrite handle_stripe_dirtying6 in asynchronous way > > Processing stripe dirtying in asynchronous way requires some changes > to the handle_stripe_dirtying6() algorithm. > > In the synchronous implementation of the stripe dirtying we processed > dirtying of a degraded stripe (with partially changed strip(s) located > on the failed drive(s)) inside one handle_stripe_dirtying6() call: > - we computed the missed strips from the old parities, and thus got > the fully up-to-date stripe, then > - we did reconstruction using the new data to write. > > In the asynchronous case of handle_stripe_dirtying6() we don't > process anything right inside this function (since we under the lock), > but only schedule the necessary operations with flags. Thus, if > handle_stripe_dirtying6() is performed on the top of a degraded array > we should schedule the reconstruction operation when the failed strips > are marked (by previously called fetch_block6()) as to be computed > (with the R5_Wantcompute flag), and all the other strips of the stripe > are UPTODATE. The schedule_reconstruction() function will set the > STRIPE_OP_POSTXOR flag [for new parity calculation], which is then > handled in raid_run_ops() after the STRIPE_OP_COMPUTE_BLK one [which > causes computing of the data missed]. > > " Excellent! Thanks, Dan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Re[2]: [PATCH 03/11][v3] async_tx: add support for asynchronous RAID6 recovery operations
On Fri, Jan 16, 2009 at 4:51 AM, Yuri Tikhonov wrote:
> The reason why I preferred to use async_pq() instead of async_xor()
> here is to maximize the chance that the whole D+D recovery operation
> will be handled in one ADMA device, i.e. without channels switch and
> the latency introduced because of that.
>
This should be a function of the async_tx_find_channel implementation.
The default version tries to keep a chain of operations on one
channel.
struct dma_chan *
__async_tx_find_channel(struct dma_async_tx_descriptor *depend_tx,
enum dma_transaction_type tx_type)
{
/* see if we can keep the chain on one channel */
if (depend_tx &&
dma_has_cap(tx_type, depend_tx->chan->device->cap_mask))
return depend_tx->chan;
return dma_find_channel(tx_type);
}
--
Dan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Re[2]: [PATCH 02/11][v3] async_tx: add support for asynchronous GF multiplication
On Fri, Jan 16, 2009 at 4:41 AM, Yuri Tikhonov wrote:
>> I don't think this will work as we will be mixing Q into the new P and
>> P into the new Q. In order to support (src_cnt > device->max_pq) we
>> need to explicitly tell the driver that the operation is being
>> continued (DMA_PREP_CONTINUE) and to apply different coeffeicients to
>> P and Q to cancel the effect of including them as sources.
>
> With DMA_PREP_ZERO_P/Q approach, the Q isn't mixed into new P, and P
> isn't mixed into new Q. For your example of max_pq=4:
>
> p, q = PQ(src0, src1, src2, src3, src4, COEF({01}, {02}, {04}, {08}, {10}))
>
> with the current implementation will be split into:
>
> p, q = PQ(src0, src1, src2, src3, COEF({01}, {02}, {04}, {08})
> p`,q` = PQ(src4, COEF({10}))
>
> which will result to the following:
>
> p = ((dma_flags & DMA_PREP_ZERO_P) ? 0 : old_p) + src0 + src1 + src2 + src3
> q = ((dma_flags & DMA_PREP_ZERO_Q) ? 0 : old_q) + {01}*src0 + {02}*src1 +
> {04}*src2 + {08}*src3
>
> p` = p + src4
> q` = q + {10}*src4
>
Huh? Does the ppc440spe engine have some notion of flagging a source
as old_p/old_q? Otherwise I do not see how the engine will not turn
this into:
p` = p + src4 + q
q` = q + {10}*src4 + {x}*p
I think you missed the fact that we have passed p and q back in as
sources. Unless we have multiple p destinations and multiple q
destinations, or hardware support for continuations I do not see how
you can guarantee this split.
> I'm afraid that the difference (13/4, 125/32) is very significant, so
> getting rid of DMA_PREP_ZERO_P/Q will eat most of the improvement
> which could be achieved with the current approach.
Data corruption is a slightly higher cost :-).
>
>> but at this point I do not see a cleaner alternatve for engines like
>> iop13xx.
>
> I can't find any description of iop13xx processors at Intel's
> web-site, only 3xx:
>
> http://www.intel.com/design/iio/index.htm?iid=ipp_embed+embed_io
>
> So, it's hard for me to do any suggestions. I just wonder - doesn't
> iop13xx allow users to program destination addresses into the sources
> fields of descriptors?
Yes it does, but the engine does not know it is a destination.
Take a look at page 496 of the following and tell me if you come to a
different conclusion.
http://download.intel.com/design/iio/docs/31503602.pdf
Thanks,
Dan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC8272ADS]Cannot start my Linux Kernel
2009/1/16 Scott Wood : > Jean-Michel Hautbois wrote: >> >> OK, I just tried a make of my kernel (already compiled yesterday), and >> it generated a cuImage.mpc8272ads kernel image (which it didn't do >> yesterday). >> I don't know why this image was generated, but I tried to reboot using >> this one. > > Use uImage if you are providing a device tree from u-boot. cuImage is for > older u-boots that don't support this, though you could still try using it > on a modern u-boot with a one- or two-argument bootm command to try to > isolate the problem. > > -Scott > Well it seems to be a (very) bad idea to use ucImage, because I cannot have my u-boot prompt after resetting my board... My LEDs are blinking (LD4 and LD 9) and my LD20 is off (when it should be on). I am blocked (without the prompt on my serial line !). JM ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device Tree setup for 8272-based board
On Fri, Jan 16, 2009 at 02:40:03PM +1100, Daniel Ng wrote:
> I've tried various values for 'console' but I'm quite certain 'ttyCPM0' is the
> one to use as this is what I was using when it was working with Linux 2.6.14
> and an old (pre-Device Tree) version of u-boot.
Yes, that is correct. You can also leave it out and rely on
/chosen/linux,stdout-path.
> I've even tried enabling the 'Early serial debugging for Freescale CPM-based
> serial ports' option in the Kernel config. Unfortunately this doesn't result
> in any noticeable difference.
>
> Can you explain why my board is freezing?
>
> Here is my Device Tree. It is a stripped-down version of mpc8272ads.dts (PCI
> has been removed among many others). I have tried to minimise the tree just to
> keep things simple.
>
> Perhaps I removed something I shouldn't have?-
You removed the brg node, but early debug output should still work
without it.
> /dts-v1/;
>
> / {
> model = "HPXRED";
> compatible = "fsl,mpc8272ads";
Is it 100% compatible? If not, change the compatible to something else
(and make sure your board code matches it).
Do you currently have mpc8272ads support enabled in the kernel? If the
kernel doesn't find a matching ppc_md, you won't get any debug output.
You can use udbg_printf() directly after the call to udbg_early_init()
though.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC8272ADS]Cannot start my Linux Kernel
Jean-Michel Hautbois wrote: OK, I just tried a make of my kernel (already compiled yesterday), and it generated a cuImage.mpc8272ads kernel image (which it didn't do yesterday). I don't know why this image was generated, but I tried to reboot using this one. Use uImage if you are providing a device tree from u-boot. cuImage is for older u-boots that don't support this, though you could still try using it on a modern u-boot with a one- or two-argument bootm command to try to isolate the problem. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC8272ADS]Cannot start my Linux Kernel
2009/1/16 Jean-Michel Hautbois : > 2009/1/16 Scott Wood : >> On Fri, Jan 16, 2009 at 01:06:06PM +0100, Jean-Michel Hautbois wrote: >>> Could it be a problem in my bootargs command line ? >>> I mean, maybe the console=ttyS0,11500 wrong ? >>> Because my "Run" LED is on... >>> >>> I tried ttyS0, ttyCPM0, tty0. >> >> It should be ttyCPM0, or just leave it out and make sure that >> /chosen/linux,stdout-path is set properly. >> >> Have you tried enabling early CPM debugging output? >> >> -Scott >> > > Well, I have to say, yes, I tried: > CONFIG_PPC_EARLY_DEBUG_CPM=y > CONFIG_PPC_EARLY_DEBUG_CPM_ADDR=0xf0001ff8 > > I have also tried without specifying the console outpût: > setenv bootargs root=/dev/ram rw > > Nothing more... > > JM > OK, I just tried a make of my kernel (already compiled yesterday), and it generated a cuImage.mpc8272ads kernel image (which it didn't do yesterday). I don't know why this image was generated, but I tried to reboot using this one. And I am going further ! Hit any key to stop autoboot: 0 ## Booting kernel from Legacy Image at 0100 ... Image Name: Linux-2.6.29-rc1-01197-g5a7b6e7- Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1529877 Bytes = 1.5 MB Load Address: 0040 Entry Point: 00400b94 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at ff98 ... Image Name: Simple Embedded Linux Framework Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:1730966 Bytes = 1.7 MB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 0200 Booting using the fdt blob at 0x200 Uncompressing Kernel Image ... OK Loading Ramdisk to 039d7000, end 03b7d996 ... OK Loading Device Tree to 007fb000, end 007ff159 ... OK Memory <- <0xd00dfeed 0x2000> (0MB) ENET0: local-mac-address <- 00:00:00:00:00:7f ENET1: local-mac-address <- 00:00:00:00:00:00 CPU clock-frequency <- 0x0 (0MHz) CPU timebase-frequency <- 0x800 (0MHz) CPU bus-frequency <- 0x2000 (0MHz) zImage starting: loaded at 0x0040 (sp: 0x03b7ebe0) Allocating 0x329908 bytes for kernel ... gunzipping (0x <- 0x0040d000:0x007591d8)...done 0x308b0c bytes Linux/PowerPC load: Finalizing device tree... flat tree at 0x767300 id mach(): done MMU:enter MMU:hw init MMU:mapin MMU:setio MMU:exit I am stuck there, with my eth LEDs blinking... JM ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.28-rc9 panics with crashkernel=256M while booting
On Fri, 2009-01-16 at 17:46 +0530, Chandru wrote: > On Thursday 15 January 2009 13:35:27 Chandru wrote: > > Hello Dave, From the debug console output, if there is anything you can add > > here, pls let me know. > > As we can see from the console output here, physbase isn't page aligned when > the panic occurs. So we could as well send (start_pfn << PAGE_SHIFT) to > reserve_bootmem_node() instead of physbase. your thoughts ?. > > Also end_pfn in mark_reserved_region_for_nid() is defined as > > unsigned long end_pfn = ((physbase + size) >> PAGE_SHIFT); > > Does this refer to the pfn after the area that we are interested in ?. We > have > atleast two fixes here, > 1. Limit start and end to bdata->node_min_pfn and bdata->node_low_pfn in > reserve_bootmem_node() and add comments out in there that the caller of the > funtion should be aware of how much are they reserving. > 2. send (start_pfn << PAGE_SHIFT) to reserve_bootmem_node() instead of > physbase. Just looking at it, that calculation is OK. But, there was one in your dmesg that looked a page too long, like page 0x1001 instead of 0x1000. I'd find out how that happened. -- Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC8272ADS]Cannot start my Linux Kernel
2009/1/16 Scott Wood : > On Fri, Jan 16, 2009 at 01:06:06PM +0100, Jean-Michel Hautbois wrote: >> Could it be a problem in my bootargs command line ? >> I mean, maybe the console=ttyS0,11500 wrong ? >> Because my "Run" LED is on... >> >> I tried ttyS0, ttyCPM0, tty0. > > It should be ttyCPM0, or just leave it out and make sure that > /chosen/linux,stdout-path is set properly. > > Have you tried enabling early CPM debugging output? > > -Scott > Well, I have to say, yes, I tried: CONFIG_PPC_EARLY_DEBUG_CPM=y CONFIG_PPC_EARLY_DEBUG_CPM_ADDR=0xf0001ff8 I have also tried without specifying the console outpût: setenv bootargs root=/dev/ram rw Nothing more... JM ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC8272ADS]Cannot start my Linux Kernel
2009/1/16 Scott Wood : > On Fri, Jan 16, 2009 at 01:06:06PM +0100, Jean-Michel Hautbois wrote: >> Could it be a problem in my bootargs command line ? >> I mean, maybe the console=ttyS0,11500 wrong ? >> Because my "Run" LED is on... >> >> I tried ttyS0, ttyCPM0, tty0. > > It should be ttyCPM0, or just leave it out and make sure that > /chosen/linux,stdout-path is set properly. > > Have you tried enabling early CPM debugging output? > > -Scott > No, I haven't tried it... How can I do it :) ? /chosen/linux,stdout-path is set to "/soc/cpm/ser...@11a00" JM ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC8272ADS]Cannot start my Linux Kernel
On Fri, Jan 16, 2009 at 01:06:06PM +0100, Jean-Michel Hautbois wrote: > Could it be a problem in my bootargs command line ? > I mean, maybe the console=ttyS0,11500 wrong ? > Because my "Run" LED is on... > > I tried ttyS0, ttyCPM0, tty0. It should be ttyCPM0, or just leave it out and make sure that /chosen/linux,stdout-path is set properly. Have you tried enabling early CPM debugging output? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re[2]: [PATCH][v4] powerpc 44x: support for 256KB PAGE_SIZE
Hello Milton, On Friday, January 16, 2009 you wrote: > On Jan 12, 2009, at 4:49 PM, Yuri Tikhonov wrote: >> This patch adds support for 256KB pages on ppc44x-based boards. > Another day, another comment. The motivation for reply was the second > comment below. >> >> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig >> index 84b8613..18f33ef 100644 >> --- a/arch/powerpc/Kconfig >> +++ b/arch/powerpc/Kconfig >> @@ -443,6 +443,19 @@ config PPC_64K_PAGES >> bool "64k page size" if 44x || PPC_STD_MMU_64 >> select PPC_HAS_HASH_64K if PPC_STD_MMU_64 >> >> +config PPC_256K_PAGES >> + bool "256k page size" if 44x >> + depends on !STDBINUTILS && !SHMEM > depends on !STDBINUTILS && (!SHMEM || BROKEN) > to identify that it is not fundamentally incompatable just not a chance > of working without other changes. This makes sense. [..] >> +config STDBINUTILS >> + bool "Using standard binutils settings" >> + depends on 44x >> + default y > I think this should be > config STDBINUTILS > bool "Using standard binutils settings" if 44x > default y > that way we imply that all powerpc users are using the standard > binutils instead of only those using a 44x platform. We still get the > intended effect of asking the user only on 44x. > I haven't looked at the resulting question or config order to see if it > makes sense to leave it here or put it closer to the page size. I'm not sure about this. For 44x platforms - the STDBINUTILS option is reasonable, because it's used in the PAGE_SIZE selection process. But as regarding the other powerpcs the STDBINUTILS option will do nothing, but taking a superfluous string in configs. Are you sure this will be better ? Regards, Yuri -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH][v4] powerpc 44x: support for 256KB PAGE_SIZE
On Jan 12, 2009, at 4:49 PM, Yuri Tikhonov wrote: This patch adds support for 256KB pages on ppc44x-based boards. Another day, another comment. The motivation for reply was the second comment below. diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 84b8613..18f33ef 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -443,6 +443,19 @@ config PPC_64K_PAGES bool "64k page size" if 44x || PPC_STD_MMU_64 select PPC_HAS_HASH_64K if PPC_STD_MMU_64 +config PPC_256K_PAGES + bool "256k page size" if 44x + depends on !STDBINUTILS && !SHMEM depends on !STDBINUTILS && (!SHMEM || BROKEN) to identify that it is not fundamentally incompatable just not a chance of working without other changes. + help + Make the page size 256k. + + As the ELF standard only requires alignment to support page + sizes up to 64k, you will need to compile all of your user + space applications with a non-standard binutils settings + (see the STDBINUTILS description for details). + + Say N unless you know what you are doing. + endchoice config FORCE_MAX_ZONEORDER diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig index 3496bc0..d02e8c8 100644 --- a/arch/powerpc/platforms/44x/Kconfig +++ b/arch/powerpc/platforms/44x/Kconfig @@ -214,6 +214,18 @@ config 440SPe bool select IBM_NEW_EMAC_EMAC4 +config STDBINUTILS + bool "Using standard binutils settings" + depends on 44x + default y I think this should be config STDBINUTILS bool "Using standard binutils settings" if 44x default y that way we imply that all powerpc users are using the standard binutils instead of only those using a 44x platform. We still get the intended effect of asking the user only on 44x. I haven't looked at the resulting question or config order to see if it makes sense to leave it here or put it closer to the page size. + help + Turning this option off allows you to select 256KB PAGE_SIZE on 44x. + Note, that kernel will be able to run only those applications, + which had been compiled using binutils later than 2.17.50.0.3 with + '-zmax-page-size' set to 256K (the default is 64K). Or, if using + the older binutils, you can patch them with a trivial patch, which + changes the ELF_MAXPAGESIZE definition from 0x1 to 0x4. + config 460EX bool select PPC_FPU -- 1.6.0.6 milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re[2]: [PATCH 07/11] md: rewrite handle_stripe_dirtying6 in asynchronous way
Hello Cheng, On Friday, January 16, 2009 you wrote: > Ack, could you please make the changelog more descriptive? > and or add some of your benchmark results? Of course. We did benchmarking using the Xdd tool like follows: # xdd -op write -kbytes $kbytes -reqsize $reqsize -dio-passes 2 –verbose -target $target_device where $kbytes = data disks * size of disk $reqsize= data disks * chunk size $target_device = /dev/md0 This way we did write of full array size, and thus achieved the maximum performance. The test cases were RAID-6 built on the top of 14 S-ATA drives connected to 2 LSI cards (7+7) inserted into the 800 MHz Katmai board (based on ppc440spe) equipped with 4GB of 800 MHz DRAM . Here are the results (Psw - write throughput with s/w RAID-6; Phw - write throughput with the h/w accelerated RAID-6): PAGE_SIZE=4KB, chunk=64/128/256 KB Psw = 71/72/74 MBps Phw = 128/136/139 MBps PAGE_SIZE=16KB, chunk=256/512/1024 KB Psw = 81/81/82 MBps Phw = 205/244/239 MBps PAGE_SIZE=64KB, chunk=1024/2048/4096 KB Psw = 84/84/85 MBps Phw = 258/253/258 MBps PAGE_SIZE=256KB, chunk=4096/8192/16384 KB Psw = 81/83/83 MBps Phw = 288/275/274 MBps Regards, Yuri -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re[2]: [PATCH 07/11] md: rewrite handle_stripe_dirtying6 in asynchronous way
On Friday, January 16, 2009 you wrote: > On Thu, Jan 15, 2009 at 2:51 PM, Dan Williams > wrote: >> On Mon, Dec 8, 2008 at 2:57 PM, Yuri Tikhonov wrote: >> What's the reasoning behind changing the logic here, i.e. removing >> must_compute and such? I'd feel more comfortable seeing copy and >> paste where possible with cleanups separated out into their own patch. >> > Ok, I now see why this change was made. Please make this changelog > more descriptive than "Rewrite handle_stripe_dirtying6 function to > work asynchronously." Sure, how about the following: " md: rewrite handle_stripe_dirtying6 in asynchronous way Processing stripe dirtying in asynchronous way requires some changes to the handle_stripe_dirtying6() algorithm. In the synchronous implementation of the stripe dirtying we processed dirtying of a degraded stripe (with partially changed strip(s) located on the failed drive(s)) inside one handle_stripe_dirtying6() call: - we computed the missed strips from the old parities, and thus got the fully up-to-date stripe, then - we did reconstruction using the new data to write. In the asynchronous case of handle_stripe_dirtying6() we don't process anything right inside this function (since we under the lock), but only schedule the necessary operations with flags. Thus, if handle_stripe_dirtying6() is performed on the top of a degraded array we should schedule the reconstruction operation when the failed strips are marked (by previously called fetch_block6()) as to be computed (with the R5_Wantcompute flag), and all the other strips of the stripe are UPTODATE. The schedule_reconstruction() function will set the STRIPE_OP_POSTXOR flag [for new parity calculation], which is then handled in raid_run_ops() after the STRIPE_OP_COMPUTE_BLK one [which causes computing of the data missed]. " Regards, Yuri -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.28-rc9 panics with crashkernel=256M while booting
On Thursday 15 January 2009 13:35:27 Chandru wrote: > Hello Dave, From the debug console output, if there is anything you can add > here, pls let me know. As we can see from the console output here, physbase isn't page aligned when the panic occurs. So we could as well send (start_pfn << PAGE_SHIFT) to reserve_bootmem_node() instead of physbase. your thoughts ?. Also end_pfn in mark_reserved_region_for_nid() is defined as unsigned long end_pfn = ((physbase + size) >> PAGE_SHIFT); Does this refer to the pfn after the area that we are interested in ?. We have atleast two fixes here, 1. Limit start and end to bdata->node_min_pfn and bdata->node_low_pfn in reserve_bootmem_node() and add comments out in there that the caller of the funtion should be aware of how much are they reserving. 2. send (start_pfn << PAGE_SHIFT) to reserve_bootmem_node() instead of physbase. Chandru ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re[2]: [PATCH 11/11][v2] ppc440spe-adma: ADMA driver for PPC440SP(e) systems
Hello Anton,
Thanks for review. Please note the general note I made in "Re[2]:
[PATCH 11/11][v2] ppc440spe-adma: ADMA driver for PPC440SP(e)
systems".
All your comments make sense, so we'll try to address these in the
next version of the driver. Some comments below.
On Thursday, January 15, 2009 you wrote:
> Hello Yuri,
> On Tue, Jan 13, 2009 at 03:43:55AM +0300, Yuri Tikhonov wrote:
>> Adds the platform device definitions and the architecture specific support
>> routines for the ppc440spe adma driver.
>>
>> Any board equipped with PPC440SP(e) controller may utilize this driver.
>>
>> Signed-off-by: Yuri Tikhonov
>> Signed-off-by: Ilya Yanok
>> ---
> Quite complex and interesting driver, I must say.
> Have you thought about splitting ppc440spe-adma.c into multiple
> files, btw?
Admittedly, no. But I guess this makes sense. The driver supports two
different types of DMA devices of ppc440spe: DMA0,1 and DMA2[XOR
engine]. So, we could split the driver at least in two, which would
definitely simplified the code.
> A few comments down below...
> [...]
>> +typedef struct ppc440spe_adma_device {
> Please avoid typedefs.
OK.
> [...]
>> +/*
>> + * Descriptor of allocated CDB
>> + */
>> +typedef struct {
>> + dma_cdb_t *vaddr; /* virtual address of CDB */
>> + dma_addr_t paddr; /* physical address of CDB */
>> + /*
>> + * Additional fields
>> + */
>> + struct list_headlink; /* link in processing list */
>> + u32 status; /* status of the CDB */
>> + /* status bits: */
>> + #define DMA_CDB_DONE(1<<0) /* CDB processing competed */
>> + #define DMA_CDB_CANCEL (1<<1) /* waiting thread was interrupted */
>> +} dma_cdbd_t;
> It seems there are no users of this struct.
Indeed. This is an useless inheritance of some old version of the
driver. Will remove this in the next patch.
[..]
>> +/**
>> + * ppc440spe_desc_init_dma01pq - initialize the descriptors for PQ operation
>> + * qith DMA0/1
>> + */
>> +static inline void ppc440spe_desc_init_dma01pq(ppc440spe_desc_t *desc,
>> + int dst_cnt, int src_cnt, unsigned long flags,
>> + unsigned long op)
>> +{
> Way to big for inline. The same for all the inlines.
> Btw, ppc_async_tx_find_best_channel() looks too big for inline
> and also too big to be in a .h file.
OK, will be moved to the appropriate .c.
[..]
> [...]
>> +static int ppc440spe_test_raid6 (ppc440spe_ch_t *chan)
>> +{
>> + ppc440spe_desc_t *sw_desc, *iter;
>> + struct page *pg;
>> + char *a;
>> + dma_addr_t dma_addr, addrs[2];
>> + unsigned long op = 0;
>> + int rval = 0;
>> +
>> + /*FIXME*/
> ?
>> +
>> + set_bit(PPC440SPE_DESC_WXOR, &op);
>> +
>> + pg = alloc_page(GFP_KERNEL);
>> + if (!pg)
>> + return -ENOMEM;
>> +
>> +
>> +/**
>> + * ppc440spe_adma_probe - probe the asynch device
>> + */
>> +static int __devinit ppc440spe_adma_probe(struct platform_device *pdev)
>> +{
>> + struct resource *res;
> Why is this a platform driver? What's the point of describing
> DMA nodes in the device tree w/o actually using them (don't count
> interrupts)? There are a lot of hard-coded addresses in the code...
> :-/
> And arch/powerpc/platforms/44x/ppc440spe_dma_engines.c file
> reminds me arch/ppc-style bindings. ;-)
Right. This driver is a not-completed port from the arch/ppc branch.
>> + int ret=0, irq1, irq2, initcode = PPC_ADMA_INIT_OK;
>> + void *regs;
>> + ppc440spe_dev_t *adev;
>> + ppc440spe_ch_t *chan;
>> + ppc440spe_aplat_t *plat_data;
>> + struct ppc_dma_chan_ref *ref;
>> + struct device_node *dp;
>> + char s[10];
>> +
> [...]
>> +static int __init ppc440spe_adma_init (void)
>> +{
>> + int rval, i;
>> + struct proc_dir_entry *p;
>> +
>> + for (i = 0; i < PPC440SPE_ADMA_ENGINES_NUM; i++)
>> + ppc_adma_devices[i] = -1;
>> +
>> + rval = platform_driver_register(&ppc440spe_adma_driver);
>> +
>> + if (rval == 0) {
>> + /* Create /proc entries */
>> + ppc440spe_proot = proc_mkdir(PPC440SPE_R6_PROC_ROOT, NULL);
>> + if (!ppc440spe_proot) {
>> + printk(KERN_ERR "%s: failed to create %s proc "
>> + "directory\n",__func__,PPC440SPE_R6_PROC_ROOT);
>> + /* User will not be able to enable h/w RAID-6 */
>> + return rval;
>> + }
> /proc? Why /proc? The driver has nothing to do with Linux VM subsystem
> or processes. I think /sys/ interface would suit better for this, no?
> Either way, userspace interfaces should be documented somehow
> (probably Documentation/ABI/, or at least some comments in the
> code).
Agree, we'll fix this.
Regards, Yuri
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
___
Linuxppc-dev mailing list
Linuxppc-dev@
Re: [MPC8272ADS]Cannot start my Linux Kernel
>> try to fix "ft_cpu_setup()" in your u-boot source for mpc8272ads >> and use "PowerPC,8...@0" as cpu_path instead of "c...@0". >> >> Best regards, >> Anatolij > I am currently going until this step: ## Booting kernel from Legacy Image at 0040 ... Image Name: Linux-2.6.29-rc1-01197-g5a7b6e7- Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1505515 Bytes = 1.4 MB Load Address: Entry Point: Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at ff98 ... Image Name: Simple Embedded Linux Framework Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:1730966 Bytes = 1.7 MB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 0200 Booting using the fdt blob at 0x200 Uncompressing Kernel Image ... OK Loading Ramdisk to 039d7000, end 03b7d996 ... OK Loading Device Tree to 007fb000, end 007ff159 ... OK Could it be a problem in my bootargs command line ? I mean, maybe the console=ttyS0,11500 wrong ? Because my "Run" LED is on... I tried ttyS0, ttyCPM0, tty0. And I don't have any "Starting kernel..." message. Thx in advance. Best Regards, JM ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re[2]: [PATCH 03/11][v3] async_tx: add support for asynchronous RAID6 recovery operations
On Thursday, January 15, 2009 Dan Williams wrote:
> On Mon, Jan 12, 2009 at 5:43 PM, Yuri Tikhonov wrote:
>> + /* (2) Calculate Q+Qxy */
>> + lptrs[0] = ptrs[failb];
>> + lptrs[1] = ptrs[disks-1];
>> + lptrs[2] = NULL;
>> + tx = async_pq(lptrs, NULL, 0, 1, bytes, ASYNC_TX_DEP_ACK,
>> + tx, NULL, NULL);
>> +
>> + /* (3) Calculate P+Pxy */
>> + lptrs[0] = ptrs[faila];
>> + lptrs[1] = ptrs[disks-2];
>> + lptrs[2] = NULL;
>> + tx = async_pq(lptrs, NULL, 0, 1, bytes, ASYNC_TX_DEP_ACK,
>> + tx, NULL, NULL);
>> +
> These two calls convinced me that ASYNC_TX_PQ_ZERO_{P,Q} need to go.
> A 1-source async_pq operation does not make sense.
Another source is hidden under not-set ASYNC_TX_PQ_ZERO_{P,Q} :)
Though, I agree, this looks rather misleading.
> These should be:
>/* (2) Calculate Q+Qxy */
>lptrs[0] = ptrs[disks-1];
>lptrs[1] = ptrs[failb];
>tx = async_xor(lptrs[0], lptrs, 0, 2, bytes,
> ASYNC_TX_XOR_DROP_DST|ASYNC_TX_DEP_ACK, tx, NULL, NULL);
> /* (3) Calculate P+Pxy */
>lptrs[0] = ptrs[disks-2];
>lptrs[1] = ptrs[faila];
>tx = async_xor(lptrs[0], lptrs, 0, 2, bytes,
> ASYNC_TX_XOR_DROP_DST|ASYNC_TX_DEP_ACK, tx, NULL, NULL);
The reason why I preferred to use async_pq() instead of async_xor()
here is to maximize the chance that the whole D+D recovery operation
will be handled in one ADMA device, i.e. without channels switch and
the latency introduced because of that.
So, if we'll decide to stay with ASYNC_TX_PQ_ZERO_{P,Q}, then this
should be probably kept unchanged, but if we'll get rid of
ASYNC_TX_PQ_ZERO_{P,Q}, then, obviously, we'll have to use
async_xor()s here as you suggest.
Regards, Yuri
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re[2]: [PATCH 02/11][v3] async_tx: add support for asynchronous GF multiplication
Hello Dan,
Thanks for review. Some comments below.
On Thursday, January 15, 2009 you wrote:
[..]
>> +/**
>> + * do_async_pq - asynchronously calculate P and/or Q
>> + */
>> +static struct dma_async_tx_descriptor *
>> +do_async_pq(struct dma_chan *chan, struct page **blocks, unsigned char
>> *scfs,
>> + unsigned int offset, int src_cnt, size_t len, enum async_tx_flags
>> flags,
>> + struct dma_async_tx_descriptor *depend_tx,
>> + dma_async_tx_callback cb_fn, void *cb_param)
>> +{
>> + struct dma_device *dma = chan->device;
>> + dma_addr_t dma_dest[2], dma_src[src_cnt];
>> + struct dma_async_tx_descriptor *tx = NULL;
>> + dma_async_tx_callback _cb_fn;
>> + void *_cb_param;
>> + unsigned char *scf = NULL;
>> + int i, src_off = 0;
>> + unsigned short pq_src_cnt;
>> + enum async_tx_flags async_flags;
>> + enum dma_ctrl_flags dma_flags = 0;
>> +
>> + /* If we won't handle src_cnt in one shot, then the following
>> +* flag(s) will be set only on the first pass of prep_dma
>> +*/
>> + if (flags & ASYNC_TX_PQ_ZERO_P)
>> + dma_flags |= DMA_PREP_ZERO_P;
>> + if (flags & ASYNC_TX_PQ_ZERO_Q)
>> + dma_flags |= DMA_PREP_ZERO_Q;
>> +
>> + /* DMAs use destinations as sources, so use BIDIRECTIONAL mapping */
>> + if (blocks[src_cnt]) {
>> + dma_dest[0] = dma_map_page(dma->dev, blocks[src_cnt],
>> + offset, len, DMA_BIDIRECTIONAL);
>> + dma_flags |= DMA_PREP_HAVE_P;
>> + }
>> + if (blocks[src_cnt+1]) {
>> + dma_dest[1] = dma_map_page(dma->dev, blocks[src_cnt+1],
>> + offset, len, DMA_BIDIRECTIONAL);
>> + dma_flags |= DMA_PREP_HAVE_Q;
>> + }
>> +
>> + for (i = 0; i < src_cnt; i++)
>> + dma_src[i] = dma_map_page(dma->dev, blocks[i],
>> + offset, len, DMA_TO_DEVICE);
>> +
>> + while (src_cnt) {
>> + async_flags = flags;
>> + pq_src_cnt = min(src_cnt, (int)dma->max_pq);
>> + /* if we are submitting additional pqs, leave the chain open,
>> +* clear the callback parameters, and leave the destination
>> +* buffers mapped
>> +*/
>> + if (src_cnt > pq_src_cnt) {
>> + async_flags &= ~ASYNC_TX_ACK;
>> + dma_flags |= DMA_COMPL_SKIP_DEST_UNMAP;
>> + _cb_fn = NULL;
>> + _cb_param = NULL;
>> + } else {
>> + _cb_fn = cb_fn;
>> + _cb_param = cb_param;
>> + }
>> + if (_cb_fn)
>> + dma_flags |= DMA_PREP_INTERRUPT;
>> + if (scfs)
>> + scf = &scfs[src_off];
>> +
>> + /* Since we have clobbered the src_list we are committed
>> +* to doing this asynchronously. Drivers force forward
>> +* progress in case they can not provide a descriptor
>> +*/
>> + tx = dma->device_prep_dma_pq(chan, dma_dest,
>> +&dma_src[src_off], pq_src_cnt,
>> +scf, len, dma_flags);
>> + if (unlikely(!tx))
>> + async_tx_quiesce(&depend_tx);
>> +
>> + /* spin wait for the preceeding transactions to complete */
>> + while (unlikely(!tx)) {
>> + dma_async_issue_pending(chan);
>> + tx = dma->device_prep_dma_pq(chan, dma_dest,
>> + &dma_src[src_off], pq_src_cnt,
>> + scf, len, dma_flags);
>> + }
>> +
>> + async_tx_submit(chan, tx, async_flags, depend_tx,
>> + _cb_fn, _cb_param);
>> +
>> + depend_tx = tx;
>> + flags |= ASYNC_TX_DEP_ACK;
>> +
>> + if (src_cnt > pq_src_cnt) {
>> + /* drop completed sources */
>> + src_cnt -= pq_src_cnt;
>> + src_off += pq_src_cnt;
>> +
>> + /* use the intermediate result as a source; we
>> +* clear DMA_PREP_ZERO, so prep_dma_pq will
>> +* include destination(s) into calculations. Thus
>> +* keep DMA_PREP_HAVE_x in dma_flags only
>> +*/
>> + dma_flags &= (DMA_PREP_HAVE_P | DMA_PREP_HAVE_Q);
> I don't think this will work as we will be mixing Q into the new P and
> P into the new Q. In order to support (src_cnt > device->max_pq) we
> need to explicitly tell the driver that the operation is being
> conti
Re: [PATCH] cpm2: Round the baud-rate clock divider to the nearest integer.
On Thursday 15 January 2009 19:57:44 Kumar Gala wrote: > On Jan 15, 2009, at 11:54 AM, Scott Wood wrote: > > On Thu, Jan 15, 2009 at 03:58:50PM +0100, Laurent Pinchart wrote: > >> On Thursday 15 January 2009 15:42:14 Kumar Gala wrote: > >>> On Jan 15, 2009, at 7:18 AM, Laurent Pinchart wrote: > 2.6.29-rc1 is out and I haven't seen the patch being applied > anywhere. Is there any blocking issue ? > >>> > >>> I wasn't sure if you and Scott had come to resolution on the > >>> rounding > >>> issue. > >> > >> I think we have. Scott, can you confirm ? > > > > I think the patch is correct, and I need to look into why it gives me > > problems on mpc8272ads (while solving similar issues on some other > > boards). > > Ok. > > Laurent, > > Is this critical for 2.6.29 or ok if I queue for .30? You can queue the patch for 2.6.30. Just don't forget this time ;-) -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH RFC v5] net: add PCINet driver
Hi! Ira Snyder wrote on 15.01.2009 22:40:56: > On Thu, Jan 15, 2009 at 10:22:53PM +0100, Arnd Bergmann wrote: > > On Thursday 15 January 2009, Ira Snyder wrote: > > > I have another question for you Arnd. > > > > > > What did you use as the host and guest drivers when you ran virtio over > > > PCI? Did you use two unmodified instances of virtio_net (one on host, > > > one on guest) for networking, or did you write new virtio drivers for > > > those? How about for virtio_console (if you ran it at all). In addition to what Arnd already told you: We used two (almost) unmodified instances of virtio_net. When we tested this driver we modified the change_mtu function slightly as this function was not implemented properly (for our purpose) at that time. > > > > Jan-Bernd may be able to tell you details about this, and send you the > > driver code that his interns implemented for it. > > This was only doing virtio_net between two machines using MMIO transfers, > > i.e. the DMA engine was unused, but there was a mailbox interrupt (if you > > have one of these, you won't need MSI, btw -- just write a DMA to it). > > > > Thanks. Jan-Bernd, I'm looking forward to any input you have. > Regards, Jan-Bernd___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re[2]: [RFC PATCH 00/11][v3] md: support for asynchronous execution of RAID6 operations
Hello Dan, On Wednesday, January 14, 2009 you wrote: [..] > Do you have a git tree where you can post this series? That would > make it easier for me to track/review. Yes. Please see the "raidstuff" branch in the linux-2.6-denx repository: http://git.denx.de/?p=linux-2.6-denx.git;a=shortlog;h=refs/heads/raidstuff Regards, Yuri -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re[2]: [PATCH 11/11][v2] ppc440spe-adma: ADMA driver for PPC440SP(e) systems
Hello David,
Thanks a lot for review.
The general note to be made here is that the changes to the DTS file
made by this patch are necessary for a ppc440spe ADMA driver, which is
a not-completed arch/powerpc port from the arch/ppc branch, and which
uses DT (well, incorrectly) just to get interrupts. Otherwise, it's
just a platform device driver.
We provided this ADMA driver just as the reference of driver, which
implements the RAID-6 related low-level stuff. ppc440spe ADMA in its
current state is far from ready for merging. We'll elaborate on its
cleaning up then (surely, taking into account all the comments made
from community). But, even now, the driver works, so we publish this
so interested people could use and test it.
Some comments mixed in below.
On Tuesday, January 13, 2009 you wrote:
> On Tue, Jan 13, 2009 at 03:43:55AM +0300, Yuri Tikhonov wrote:
>> Adds the platform device definitions and the architecture specific support
>> routines for the ppc440spe adma driver.
>>
>> Any board equipped with PPC440SP(e) controller may utilize this driver.
>>
>> diff --git a/arch/powerpc/boot/dts/katmai.dts
>> b/arch/powerpc/boot/dts/katmai.dts
>> index 077819b..f2f77c8 100644
>> --- a/arch/powerpc/boot/dts/katmai.dts
>> +++ b/arch/powerpc/boot/dts/katmai.dts
>> @@ -16,7 +16,7 @@
>>
>> / {
>> #address-cells = <2>;
>> - #size-cells = <1>;
>> + #size-cells = <2>;
> You've changed the root level size-cells, but haven't updated the
> sub-nodes (such as /memory) accordingly.
Thanks, we'll fix this in the next version of this patch.
>> model = "amcc,katmai";
>> compatible = "amcc,katmai";
>> dcr-parent = <&{/cpus/c...@0}>;
>> @@ -392,6 +392,30 @@
>> 0x0 0x0 0x0 0x3 &UIC3 0xa 0x4 /* swizzled int
>> C */
>> 0x0 0x0 0x0 0x4 &UIC3 0xb 0x4 /* swizzled int
>> D */>;
>> };
>> + DMA0: dma0 {
> No 'compatible' property, which seems dubious.
OK, we'll fix.
>> + interrupt-parent = <&DMA0>;
>> + interrupts = <0 1>;
>> + #interrupt-cells = <1>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + interrupt-map = <
>> + 0 &UIC0 0x14 4
>> + 1 &UIC1 0x16 4>;
>> + };
>> + DMA1: dma1 {
>> + interrupt-parent = <&DMA1>;
>> + interrupts = <0 1>;
>> + #interrupt-cells = <1>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + interrupt-map = <
>> + 0 &UIC0 0x16 4
>> + 1 &UIC1 0x16 4>;
> Are these interrupt-maps correct? The second interrupt from both dma
> controllers is routed to the same line on UIC1?
The map is correct:
- first interrupts are 'DMAx Command Status FIFO Needs Service';
- second interrupt is 'DMA Error', both DMA engines share common error IRQ.
>> + };
>> + xor {
>> + interrupt-parent = <&UIC1>;
>> + interrupts = <0x1f 4>;
> What the hell is this thing? No compatible property, nor even a
> meaningful name.
This is the XOR accelerator, the dedicated DMA engine of ppc440spe
equipped with the ability to do XOR operations in h/w. I guess, it
could be named like DMA2.
Regards, Yuri
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
