* [PATCH] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Esben Haabendal @ 2009-05-14 8:10 UTC (permalink / raw)
To: linux-i2c; +Cc: linuxppc-dev
This fixes MAL (arbitration lost) bug caused by illegal use of
RSTA (repeated START) after STOP condition generated after last byte
of reads.
Signed-off-by: Esben Haabendal <eha@doredevelopment.dk>
---
drivers/i2c/busses/i2c-mpc.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 4af5c09..9fe05d9 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -456,17 +456,22 @@ static int mpc_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs, int num)
}
for (i = 0; ret >= 0 && i < num; i++) {
+ int restart = i;
pmsg = &msgs[i];
dev_dbg(i2c->dev,
"Doing %s %d bytes to 0x%02x - %d of %d messages\n",
pmsg->flags & I2C_M_RD ? "read" : "write",
pmsg->len, pmsg->addr, i + 1, num);
+ if (i > 0 && ((pmsg-1)->flags & I2C_M_RD))
+ restart = 0;
if (pmsg->flags & I2C_M_RD)
ret =
- mpc_read(i2c, pmsg->addr, pmsg->buf, pmsg->len, i);
+ mpc_read(i2c, pmsg->addr, pmsg->buf, pmsg->len,
+ restart);
else
ret =
- mpc_write(i2c, pmsg->addr, pmsg->buf, pmsg->len, i);
+ mpc_write(i2c, pmsg->addr, pmsg->buf, pmsg->len,
+ restart);
}
mpc_i2c_stop(i2c);
return (ret < 0) ? ret : num;
--
1.6.0.4
^ permalink raw reply related
* Re: drivers/video/logo/logo_linux_mono.c build error
From: Geert Uytterhoeven @ 2009-05-14 7:24 UTC (permalink / raw)
To: Andrew Morton; +Cc: sfr, linuxppc-dev
In-Reply-To: <20090513154415.fd10762c.akpm@linux-foundation.org>
On Wed, 13 May 2009, Andrew Morton wrote:
> On Tue, 28 Apr 2009 09:24:53 +0200 (CEST)
> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > On Tue, 28 Apr 2009, Stephen Rothwell wrote:
> > > On Mon, 27 Apr 2009 14:50:31 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> > > > powerpc allmodconfig, current mainline:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > >
> > > > drivers/video/logo/logo_linux_mono.c:11: error: logo_linux_mono_data causes a section type conflict
> > > >
> > > > switching it from __initconst to __initdata "fixes" it.
> > >
> > > Interesting. The program that generates the .c file above produces
> > > __initdata for me ...
> >
> > I assume Andrew once built in that tree using the recent logo patches that
> > 1. Makes the logos const and switch them from __initdata to __initconst,
> > 2. Fix the missing dependency of the generated files on the generator program.
> > Hence if you revert the logo patches, you have to manually remove the generated
> > files.
> >
> > Is my assumption correct?
>
> Nope - mrproper removes every .c file from drivers/video/logo/ apart
> from logo.c
>
>
>
> The failure is caused by your fbdev-move-logo-externs-to-header-file.patch.
Which is not in current mainline, so the above reference was incorrectly
fueling my assumption?
> Without that patch, drivers/video/logo/logo_linux_mono.c is generated as
>
> static unsigned char logo_linux_mono_data[] __initdata = {
>
> and with that patch, drivers/video/logo/logo_linux_mono.c is generated as
>
> static const unsigned char logo_linux_mono_data[] __initconst = {
>
> and it's the switch from __initdata to __initconst which causes this
> section conflict in my setup.
But logo_linux_mono_data is referenced by
const struct linux_logo logo_linux_mono __initconst = {
.type = LINUX_LOGO_MONO,
.width = 80,
.height = 80,
.data = logo_linux_mono_data
};
only, which is also __initconst? Where does the section type conflict come
from?
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Does U-BOOT (MPC8560) support Micron MT18VDD12872DG
From: Deepak Gaur @ 2009-05-14 7:23 UTC (permalink / raw)
To: linuxppc-dev, u-boot
Hi All,
I have a custom board similar to MPC8560ADS board with 1GB DDR SDRAM. The DDR SDRAM Make
is MT18VDDF12872DG-335D3. In U-BOOT (2009.01) config file I have enabled CONFIG_SPD_EEPROM
so U-boot configures MPC8560ADS DDR controller with the values read from SPD_EEPROM (i2c
address 0x51)
After card reset U-BOOT runs from BOOT Flash and debug prints start coming on SCC1 port
But after configuring the MPC8560 DDR controller the U-BOOT HANGS when it tries to run
from RAM locations after relocation from BOOT Flash.
Somewhere I read that it is due to failure of Burst Mode access of RAM. But DDR SDRAM
inherently work in Burst Mode only. Moreover U-BBOT initialized the DDR SDRAM Mode
config register using SPD EEPROM values . The value indicate that SDRAM is in Burst Mode
MPC8560 CPU Version is 2.0.2
Please help in understanding the issue here
The U-BOOT Details are
-----------------------------------------------------------------------------------------
U-Boot 2009.01 (Apr 27 2009 - 14:17:09)
CPU: 8560, Version: 2.0, (0x80700020)
Core: E500, Version: 2.0, (0x80200020)
Clock Configuration:
CPU:660 MHz, CCB:264 MHz,
DDR:132 MHz (264 MT/s data rate), LBC:66 MHz
CPM: 264 MHz
L1: D-cache 32 kB enabled
I-cache 32 kB enabled
Board: ADS
PCI1: 32 bit, 33 MHz (compiled)
I2C: ready
DRAM: Initializing
SDRAM SPD EEPROM
starting at step 1 (STEP_GET_SPD)
MEM TYPE 0x7DDR: DDR I rank density = 0x20000000
mclk_ps = 7580
i=0, x = 0, lowest_tCKmin_found = 0
i=1, x = 7500, lowest_tCKmin_found = 0
i=2, x = 6000, lowest_tCKmin_found = 7500
i=3, x = 5000, lowest_tCKmin_found = 7500
lowest_tCKmin_CL = 2
Computing lowest common DIMM parameters for memctl=0
using mclk_ps = 7580
checking common caslat = 3
CL = 3 ok on DIMM 0 at tCK=7580 ps with its tCKmin_X_ps of 6000
checking common caslat = 2
CL = 2 ok on DIMM 0 at tCK=7580 ps with its tCKmin_X_minus_1_ps of 7500
lowest common SPD-defined CAS latency = 2
highest common dereated CAS latency = 2
all DIMMs ECC capable
Reloading memory controller configuration options for memctl=0
mclk_ps = 7580 ps
FSL Memory ctrl cg register computation
FSLDDR: cs[0]_bnds = 0x0000001f
FSLDDR: cs[0]_config = 0x80010103
FSLDDR: cs[0]_config_2 = 0x00000000
FSLDDR: cs[1]_bnds = 0x0020003f
FSLDDR: cs[1]_config = 0x80010103
FSLDDR: cs[1]_config_2 = 0x00000000
FSLDDR: timing_cfg_3 = 0x00000000
FSLDDR: timing_cfg_1 = 0x36332422
FSLDDR: timing_cfg_2 = 0x00006482
FSLDDR: ddr_sdram_cfg = 0xe2000000
FSLDDR: ddr_sdram_cfg_2 = 0x20401000
FSLDDR: ddr_sdram_mode = 0x00000022
FSLDDR: ddr_sdram_mode_2 = 0x00000000
FSLDDR: ddr_sdram_interval = 0x04060100
FSLDDR: timing_cfg_4 = 0x00000000
FSLDDR: timing_cfg_5 = 0x00000000
...
...
Some stack location related prints
...
<hangs> here <---- checked with emulator its somewhere in RAM but no prints coming
---------------------------------------------------------------------------------------
The SPD EEROM Data for this Module is given on Micron's website
http://www.micron.com/products/spddetail?part=MT18VDDF12872DG-335D3
---------------------------------------------------------------------------------------
with warm regards,
Deepak Gaur
^ permalink raw reply
* [RFC] How to allow selecting mv643xx_eth on Pegasos again
From: Gabriel Paubert @ 2009-05-14 6:48 UTC (permalink / raw)
To: Matt Sealey; +Cc: LinuxPPC
On Thu, Jan 08, 2009 at 11:53:10PM -0600, Matt Sealey wrote:
> Lennert Buytenhek wrote:
>> On Thu, Jan 08, 2009 at 11:38:33PM -0600, Matt Sealey wrote:
>>
>> On this topic, I sent a patch to linuxppc-dev@ some time ago that moves
>> the mv643xx_eth SRAM window programming code from the Pegasos platform
>> code to the mv643xx_eth driver, and adds a couple of fields to the
>> mv643xx_eth platform data that lets you pass the sram addresses/sizes
>> in. Since I don't have the hardware I haven't been able to test it,
>> but it would be nice if someone could.
>
> It seems to work. However it's still static stuff in some platform
> driver, which I don't really like. pegasos_eth.c is really a holdover
> from the very early days of ppc->powerpc architecture port, where they
> insisted that we do detection that way (and fudge it based on host
> controller PCI ID)
>
> The Pegasos device tree is so screwed up, you could never gain the
> information you need from it. And times have changed..
I just tried to compile a very recent kernel for my Pegasoi, and
I can no more select the MV643XX_ETH driver. The root cause is that
PPC_MULTIPLATFORM has been removed. There are several possibilities:
1) remove simply the PPC_MULTIPLATFORM and let it depends on PPC32
2) replace PPC_MULTIPLATFORM && PPC32 by 6xx which is apparently the
blessed way of doing this. But I dislike a 6xx condition in anything
outside arch/powerpc.
3) add a select statement for MV64X60 in CHRP. It will bring in more
code and would probably need an OF node for the system controller.
I suspect that the mv64x60 pic and i2c are not wired on Pegasos.
Pick your poison...
While at it, I'm also going to remove the last remnants of MV64360
since it is never selected anywhere (replaced by MV64X60).
Regards,
Gabriel
P.S.: this is not sufficient, after this the driver crashes at initialization
but that's a separate patch, that has to do with the dma mapping interface.
^ permalink raw reply
* [PATCH] powerpc/ftrace: Use pr_devel() in ftrace.c
From: Michael Ellerman @ 2009-05-14 6:30 UTC (permalink / raw)
To: linuxppc-dev; +Cc: rostedt
pr_debug() can now result in code being generated even when #DEBUG
is not defined. That's not really desirable in the ftrace code
which we want to be snappy.
With CONFIG_DYNAMIC_DEBUG=y:
size before:
text data bss dec hex filename
3334 672 4 4010 faa arch/powerpc/kernel/ftrace.o
size after:
text data bss dec hex filename
2616 360 4 2980 ba4 arch/powerpc/kernel/ftrace.o
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/ftrace.c | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 70e2a73..5b078ee 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -157,7 +157,7 @@ __ftrace_make_nop(struct module *mod,
* 0xe8, 0x4c, 0x00, 0x28, ld r2,40(r12)
*/
- pr_debug("ip:%lx jumps to %lx r2: %lx", ip, tramp, mod->arch.toc);
+ pr_devel("ip:%lx jumps to %lx r2: %lx", ip, tramp, mod->arch.toc);
/* Find where the trampoline jumps to */
if (probe_kernel_read(jmp, (void *)tramp, sizeof(jmp))) {
@@ -165,7 +165,7 @@ __ftrace_make_nop(struct module *mod,
return -EFAULT;
}
- pr_debug(" %08x %08x", jmp[0], jmp[1]);
+ pr_devel(" %08x %08x", jmp[0], jmp[1]);
/* verify that this is what we expect it to be */
if (((jmp[0] & 0xffff0000) != 0x3d820000) ||
@@ -181,18 +181,18 @@ __ftrace_make_nop(struct module *mod,
offset = ((unsigned)((unsigned short)jmp[0]) << 16) +
(int)((short)jmp[1]);
- pr_debug(" %x ", offset);
+ pr_devel(" %x ", offset);
/* get the address this jumps too */
tramp = mod->arch.toc + offset + 32;
- pr_debug("toc: %lx", tramp);
+ pr_devel("toc: %lx", tramp);
if (probe_kernel_read(jmp, (void *)tramp, 8)) {
printk(KERN_ERR "Failed to read %lx\n", tramp);
return -EFAULT;
}
- pr_debug(" %08x %08x\n", jmp[0], jmp[1]);
+ pr_devel(" %08x %08x\n", jmp[0], jmp[1]);
ptr = ((unsigned long)jmp[0] << 32) + jmp[1];
@@ -269,7 +269,7 @@ __ftrace_make_nop(struct module *mod,
* 0x4e, 0x80, 0x04, 0x20 bctr
*/
- pr_debug("ip:%lx jumps to %lx", ip, tramp);
+ pr_devel("ip:%lx jumps to %lx", ip, tramp);
/* Find where the trampoline jumps to */
if (probe_kernel_read(jmp, (void *)tramp, sizeof(jmp))) {
@@ -277,7 +277,7 @@ __ftrace_make_nop(struct module *mod,
return -EFAULT;
}
- pr_debug(" %08x %08x ", jmp[0], jmp[1]);
+ pr_devel(" %08x %08x ", jmp[0], jmp[1]);
/* verify that this is what we expect it to be */
if (((jmp[0] & 0xffff0000) != 0x3d600000) ||
@@ -293,7 +293,7 @@ __ftrace_make_nop(struct module *mod,
if (tramp & 0x8000)
tramp -= 0x10000;
- pr_debug(" %lx ", tramp);
+ pr_devel(" %lx ", tramp);
if (tramp != addr) {
printk(KERN_ERR
@@ -402,7 +402,7 @@ __ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
/* ld r2,40(r1) */
op[1] = 0xe8410028;
- pr_debug("write to %lx\n", rec->ip);
+ pr_devel("write to %lx\n", rec->ip);
if (probe_kernel_write((void *)ip, op, MCOUNT_INSN_SIZE * 2))
return -EPERM;
@@ -442,7 +442,7 @@ __ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
return -EINVAL;
}
- pr_debug("write to %lx\n", rec->ip);
+ pr_devel("write to %lx\n", rec->ip);
if (probe_kernel_write((void *)ip, &op, MCOUNT_INSN_SIZE))
return -EPERM;
--
1.6.2.1
^ permalink raw reply related
* [PATCH v3] sata_fsl: Fix compile warnings
From: Kumar Gala @ 2009-05-14 3:10 UTC (permalink / raw)
To: jeff; +Cc: linux-ide, linux-kernel, linuxppc-dev
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 <galak@kernel.crashing.org>
---
* v2: fixed extra 'x'
* v3: fixed whitespace issue
drivers/ata/sata_fsl.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index c2e90e1..5edd654 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -332,13 +332,14 @@ static unsigned int sata_fsl_fill_sg(struct ata_queued_cmd *qc, void *cmd_desc,
dma_addr_t sg_addr = sg_dma_address(sg);
u32 sg_len = sg_dma_len(sg);
- VPRINTK("SATA FSL : fill_sg, sg_addr = 0x%x, sg_len = %d\n",
- sg_addr, sg_len);
+ VPRINTK("SATA FSL : fill_sg, sg_addr = 0x%llx, sg_len = %d\n",
+ (unsigned long long)sg_addr, sg_len);
/* warn if each s/g element is not dword aligned */
if (sg_addr & 0x03)
ata_port_printk(qc->ap, KERN_ERR,
- "s/g addr unaligned : 0x%x\n", sg_addr);
+ "s/g addr unaligned : 0x%llx\n",
+ (unsigned long long)sg_addr);
if (sg_len & 0x03)
ata_port_printk(qc->ap, KERN_ERR,
"s/g len unaligned : 0x%x\n", sg_len);
--
1.6.0.6
^ permalink raw reply related
* Re: device trees.
From: David Gibson @ 2009-05-14 3:08 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-dev
In-Reply-To: <4A0B0D4A.6000405@dlasys.net>
On Wed, May 13, 2009 at 02:11:22PM -0400, David H. Lynch Jr. wrote:
> David Gibson wrote:
> >
> >
> > Ok. If you have NOR flash, why couldn't you just put the dtb in a
> > separate partition of the NOR?
> >
> >
> It is not THE dtb, it is A dtb. Our systems support and typically use
> multiple FPGA bit streams.
Ah, ok. And those multiple bitstreams all inhabit the same NOR flash?
>From what I read below I'm guessing not..
> Clients are
> That means each bitstream must have its own dtb, clients are
> allowed/expected to create their own firmware,
> but the norm is to leave the "PrimaryBoot.bit" startup bit file intact.
> Clients may swap between several bit files for development purposes in
> the course of a day.
> It is even possible that a clients application may require swapping bit
> files as part of normal operations.
> I want one linux binary - because I know damn well that given two my
> clients will use the wrong one alteast 30% of the time.
> Somewhere arround 4 binaries that becomes almost 100% of the time.
> Using dtb's to make the linux binary does NOT solve the problem it just
> changes the file they have to get right.
Ok. But they must be using some tool to push the bitstream into the
board yes? Could that same tool be made to take a bitstream+dtb
bundle and push each piece into the right section of flash?
> Worse still the wrong dtb will probably mostly work. If it just failed
> they would be more likely to grasp what they got wrong.
>
> I need/want the device tree welded to the bitstream. That means creating
> it dynamically or welding it to the bitstream.
> Anything else wil be a support nightmare.
Right. I guess it's all a question of what constitutes "welded" given
the tool setup that's typically used by your clients. I'm trying to
understand enough about your system to make practical suggestions of
how to achieve weldedness.
--
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: [PATCH] mmc: Add fsl,esdhc as a valid compatible to bind against
From: Kumar Gala @ 2009-05-14 2:45 UTC (permalink / raw)
To: Pierre Ossman; +Cc: linuxppc-dev, pierre, linux-kernel
In-Reply-To: <1241790769-3843-1-git-send-email-galak@kernel.crashing.org>
On May 8, 2009, at 8:52 AM, Kumar Gala wrote:
> We plan to use fsl,esdhc going forward as the base compatible so
> update
> the driver to bind against it.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> drivers/mmc/host/sdhci-of.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Any feedback or possibility of picking this up.
- k
>
>
> diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
> index 3ff4ac3..09cc597 100644
> --- a/drivers/mmc/host/sdhci-of.c
> +++ b/drivers/mmc/host/sdhci-of.c
> @@ -277,6 +277,7 @@ static int __devexit sdhci_of_remove(struct
> of_device *ofdev)
> static const struct of_device_id sdhci_of_match[] = {
> { .compatible = "fsl,mpc8379-esdhc", .data = &sdhci_esdhc, },
> { .compatible = "fsl,mpc8536-esdhc", .data = &sdhci_esdhc, },
> + { .compatible = "fsl,esdhc", .data = &sdhci_esdhc, },
> { .compatible = "generic-sdhci", },
> {},
> };
> --
> 1.6.0.6
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: drivers/video/logo/logo_linux_mono.c build error
From: Andrew Morton @ 2009-05-13 22:44 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: sfr, linuxppc-dev
In-Reply-To: <alpine.LRH.2.00.0904280922410.31001@vixen.sonytel.be>
On Tue, 28 Apr 2009 09:24:53 +0200 (CEST)
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> On Tue, 28 Apr 2009, Stephen Rothwell wrote:
> > On Mon, 27 Apr 2009 14:50:31 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> > > powerpc allmodconfig, current mainline:
> > >
> > > drivers/video/logo/logo_linux_mono.c:11: error: logo_linux_mono_data causes a section type conflict
> > >
> > > switching it from __initconst to __initdata "fixes" it.
> >
> > Interesting. The program that generates the .c file above produces
> > __initdata for me ...
>
> I assume Andrew once built in that tree using the recent logo patches that
> 1. Makes the logos const and switch them from __initdata to __initconst,
> 2. Fix the missing dependency of the generated files on the generator program.
> Hence if you revert the logo patches, you have to manually remove the generated
> files.
>
> Is my assumption correct?
Nope - mrproper removes every .c file from drivers/video/logo/ apart
from logo.c
The failure is caused by your fbdev-move-logo-externs-to-header-file.patch.
Without that patch, drivers/video/logo/logo_linux_mono.c is generated as
static unsigned char logo_linux_mono_data[] __initdata = {
and with that patch, drivers/video/logo/logo_linux_mono.c is generated as
static const unsigned char logo_linux_mono_data[] __initconst = {
and it's the switch from __initdata to __initconst which causes this
section conflict in my setup.
^ permalink raw reply
* Please pull from 'next' branch
From: Kumar Gala @ 2009-05-13 22:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
This is based on v2.6.30-rc5.
- k
Please pull from 'next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next
to receive the following updates:
Documentation/powerpc/dts-bindings/ecm.txt | 64 +
Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt | 3
Documentation/powerpc/dts-bindings/fsl/mcm.txt | 64 +
arch/powerpc/boot/dts/gef_ppc9a.dts | 14
arch/powerpc/boot/dts/gef_sbc310.dts | 14
arch/powerpc/boot/dts/gef_sbc610.dts | 14
arch/powerpc/boot/dts/ksi8560.dts | 13
arch/powerpc/boot/dts/mpc832x_mds.dts | 3
arch/powerpc/boot/dts/mpc832x_rdb.dts | 3
arch/powerpc/boot/dts/mpc8349emitx.dts | 2
arch/powerpc/boot/dts/mpc8349emitxgp.dts | 1
arch/powerpc/boot/dts/mpc834x_mds.dts | 2
arch/powerpc/boot/dts/mpc836x_mds.dts | 3
arch/powerpc/boot/dts/mpc836x_rdk.dts | 2
arch/powerpc/boot/dts/mpc8377_mds.dts | 1
arch/powerpc/boot/dts/mpc8378_mds.dts | 1
arch/powerpc/boot/dts/mpc8379_mds.dts | 1
arch/powerpc/boot/dts/mpc8536ds.dts | 18
arch/powerpc/boot/dts/mpc8540ads.dts | 15
arch/powerpc/boot/dts/mpc8541cds.dts | 16
arch/powerpc/boot/dts/mpc8544ds.dts | 18
arch/powerpc/boot/dts/mpc8548cds.dts | 17
arch/powerpc/boot/dts/mpc8555cds.dts | 16
arch/powerpc/boot/dts/mpc8560ads.dts | 15
arch/powerpc/boot/dts/mpc8568mds.dts | 51 +
arch/powerpc/boot/dts/mpc8569mds.dts | 583 ++++++++++++++++++
arch/powerpc/boot/dts/mpc8572ds.dts | 17
arch/powerpc/boot/dts/mpc8572ds_36b.dts | 39 -
arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts | 16
arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts | 2
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 16
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 16
arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts | 609 +++++++++++++++++++
arch/powerpc/boot/dts/sbc8349.dts | 1
arch/powerpc/boot/dts/sbc8548.dts | 16
arch/powerpc/boot/dts/sbc8560.dts | 15
arch/powerpc/boot/dts/sbc8641d.dts | 16
arch/powerpc/boot/dts/socrates.dts | 15
arch/powerpc/boot/dts/stx_gp3_8560.dts | 15
arch/powerpc/boot/dts/tqm8540.dts | 15
arch/powerpc/boot/dts/tqm8541.dts | 15
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 16
arch/powerpc/boot/dts/tqm8548.dts | 16
arch/powerpc/boot/dts/tqm8555.dts | 15
arch/powerpc/boot/dts/tqm8560.dts | 15
arch/powerpc/include/asm/cpm1.h | 2
arch/powerpc/include/asm/cpm2.h | 4
arch/powerpc/include/asm/mpc86xx.h | 33 -
arch/powerpc/include/asm/pci-bridge.h | 6
arch/powerpc/include/asm/qe.h | 21
arch/powerpc/oprofile/op_model_fsl_emb.c | 14
arch/powerpc/platforms/82xx/pq2ads.h | 13
arch/powerpc/platforms/85xx/Kconfig | 1
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 52 +
arch/powerpc/platforms/86xx/gef_ppc9a.c | 1
arch/powerpc/platforms/86xx/gef_sbc310.c | 1
arch/powerpc/platforms/86xx/gef_sbc610.c | 1
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 1
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 1
arch/powerpc/platforms/86xx/mpc86xx_smp.c | 8
arch/powerpc/platforms/86xx/sbc8641d.c | 1
arch/powerpc/platforms/8xx/mpc885ads.h | 4
arch/powerpc/platforms/fsl_uli1575.c | 23
arch/powerpc/sysdev/cpm2.c | 2
arch/powerpc/sysdev/fsl_msi.c | 9
arch/powerpc/sysdev/fsl_pci.c | 6
arch/powerpc/sysdev/fsl_rio.c | 15
arch/powerpc/sysdev/fsl_soc.c | 14
arch/powerpc/sysdev/qe_lib/qe.c | 75 ++
drivers/dma/fsldma.c | 13
drivers/net/ucc_geth.c | 24
drivers/net/ucc_geth.h | 4
drivers/of/base.c | 1
drivers/rapidio/rio-scan.c | 6
include/linux/pci_ids.h | 2
75 files changed, 1949 insertions(+), 248 deletions(-)
Anton Vorontsov (6):
powerpc/85xx: Add PCI IDs for MPC8569 family processors
powerpc/85xx: Fix mpc8569emds crypto node to include SNOW unit
powerpc/85xx: Fix reg & interrupts for mpc8569emds localbus added NAND
powerpc/85xx: Add eSDHC support for MPC8569E-MDS boards
powerpc/85xx: Enable Serial RapidIO for MPC85xx MDS boards
powerpc/85xx: Add STMicro M25P40 serial flash support for MPC8569E-MDS
Becky Bruce (2):
powerpc/86xx: Add 36-bit device tree for mpc8641hpcn
powerpc: make dma_window_* in pci_controller struct avail on 32b
Haiying Wang (7):
powerpc/85xx: clean up for mpc8568_mds name
powerpc/qe: update risc allocation for QE
net/ucc_geth: update riscTx and riscRx in ucc_geth
powerpc/qe: update QE Serial Number
net/ucc_geth: Assign six threads to Rx for UEC
powerpc/85xx: Add MPC8569MDS board support
powerpc/qe: add new qe properties for QE based chips
Kumar Gala (15):
powerpc/fsl: Remove cell-index from PCI nodes
powerpc: Refactor board check for PCI quirks on FSL boards with uli1575
powerpc/fsl: use of_iomap() for rstcr mapping
powerpc/85xx: Add binding for LAWs and ECM
powerpc/85xx: Add new LAW & ECM device tree nodes for all 85xx systems
powerpc/86xx: Add binding for LAWs and MCM
powerpc/86xx: Add new LAW & MCM device tree nodes for all 86xx systems
powerpc/cpm: Remove some cruft code and defines
powerpc/86xx: clean up smp init code
powerpc/fsl: Removed reg property from 85xx/86xx soc node
fsldma: Fix compile warnings
powerpc/85xx: Add MSI nodes for MPC8568/9 MDS systems
powerpc/fsl: Support unique MSI addresses per PCIe Root Complex
powerpc/8xxx: Update PCI outbound window addresses for 36-bit configs
powerpc/fsl_rio: Fix compile warnings
Li Yang (2):
powerpc/fsl_rio: use LAW address from device tree
rapidio: fix section mismatch warnings
Michael Ellerman (1):
powerpc/oprofile: Remove unused dump_pmcs() in FSL oprofile
^ permalink raw reply
* Please pull from 'merge' branch for 2.6.30
From: Kumar Gala @ 2009-05-13 22:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Just added defconfig updates for the normal FSL set of HW.
- k
Please pull from 'merge' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge
to receive the following updates:
arch/powerpc/configs/83xx/asp8347_defconfig | 104 ++++-
arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 114 ++++--
arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 114 ++++--
arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 107 ++++--
arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 113 ++++--
arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 108 ++++--
arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 108 ++++--
arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 103 ++++-
arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 108 ++++--
arch/powerpc/configs/83xx/mpc836x_rdk_defconfig | 96 ++++-
arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 104 ++++-
arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 111 ++++--
arch/powerpc/configs/83xx/sbc834x_defconfig | 96 ++++-
arch/powerpc/configs/85xx/ksi8560_defconfig | 86 +++-
arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 82 +++-
arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 89 +++--
arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 88 +++--
arch/powerpc/configs/85xx/sbc8548_defconfig | 84 +++-
arch/powerpc/configs/85xx/sbc8560_defconfig | 83 +++-
arch/powerpc/configs/85xx/socrates_defconfig | 385 ++++++++++++++++------
arch/powerpc/configs/85xx/stx_gp3_defconfig | 105 ++++--
arch/powerpc/configs/85xx/tqm8540_defconfig | 100 ++++-
arch/powerpc/configs/85xx/tqm8541_defconfig | 101 ++++-
arch/powerpc/configs/85xx/tqm8548_defconfig | 64 ++-
arch/powerpc/configs/85xx/tqm8555_defconfig | 101 ++++-
arch/powerpc/configs/85xx/tqm8560_defconfig | 101 ++++-
arch/powerpc/configs/86xx/gef_ppc9a_defconfig | 92 ++++-
arch/powerpc/configs/86xx/gef_sbc310_defconfig | 92 ++++-
arch/powerpc/configs/86xx/gef_sbc610_defconfig | 122 +++++-
arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig | 100 ++++-
arch/powerpc/configs/86xx/mpc8641_hpcn_defconfig | 211 ++++--------
arch/powerpc/configs/86xx/sbc8641d_defconfig | 114 ++++--
arch/powerpc/configs/adder875_defconfig | 65 ++-
arch/powerpc/configs/c2k_defconfig | 128 +++++--
arch/powerpc/configs/ep8248e_defconfig | 74 +++-
arch/powerpc/configs/ep88xc_defconfig | 63 ++-
arch/powerpc/configs/linkstation_defconfig | 96 ++++-
arch/powerpc/configs/mgcoge_defconfig | 74 +++-
arch/powerpc/configs/mgsuvd_defconfig | 72 +++-
arch/powerpc/configs/mpc7448_hpc2_defconfig | 91 +++--
arch/powerpc/configs/mpc8272_ads_defconfig | 77 +++-
arch/powerpc/configs/mpc83xx_defconfig | 115 ++++--
arch/powerpc/configs/mpc866_ads_defconfig | 77 +++-
arch/powerpc/configs/mpc86xx_defconfig | 211 ++++--------
arch/powerpc/configs/mpc885_ads_defconfig | 63 ++-
arch/powerpc/configs/pq2fads_defconfig | 90 +++--
arch/powerpc/configs/prpmc2800_defconfig | 120 +++++-
arch/powerpc/configs/storcenter_defconfig | 71 ++--
arch/powerpc/sysdev/fsl_soc.c | 46 --
49 files changed, 3630 insertions(+), 1489 deletions(-)
Anton Vorontsov (1):
powerpc/fsl_soc: Remove mpc83xx_wdt_init, again
Kumar Gala (5):
powerpc/83xx: Update defconfigs
powerpc/85xx: Update defconfigs
powerpc/86xx: Update defconfigs
powerpc/embedded6xx: Update defconfigs
powerpc/8xx: Update defconfigs
^ permalink raw reply
* Re: [PATCH 6/6] rio: fix section mismatch
From: Kumar Gala @ 2009-05-13 22:08 UTC (permalink / raw)
To: Li Yang; +Cc: netdev, linux-kernel, davem, linuxppc-dev, akpm
In-Reply-To: <1242117363-14949-6-git-send-email-leoli@freescale.com>
On May 12, 2009, at 3:36 AM, Li Yang wrote:
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> drivers/rapidio/rio-scan.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 2/6] powerpc/fsl_rio: use LAW address from device tree
From: Kumar Gala @ 2009-05-13 22:08 UTC (permalink / raw)
To: Li Yang; +Cc: netdev, linux-kernel, davem, linuxppc-dev, akpm
In-Reply-To: <1242117363-14949-2-git-send-email-leoli@freescale.com>
On May 12, 2009, at 3:35 AM, Li Yang wrote:
> Instead of fixed address in old code.
>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_rio.c | 12 +++++++-----
> 1 files changed, 7 insertions(+), 5 deletions(-)
applied to next
- k
^ permalink raw reply
* [PATCH] powerpc/fsl_rio: Fix compile warnings
From: Kumar Gala @ 2009-05-13 22:04 UTC (permalink / raw)
To: linuxppc-dev
We we build with resource_size_t as a 64-bit quantity we get:
arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_setup':
arch/powerpc/sysdev/fsl_rio.c:1029: warning: format '%08x' expects type 'unsigned int', but argument 4 has type 'resource_size_t'
arch/powerpc/sysdev/fsl_rio.c:1029: warning: format '%08x' expects type 'unsigned int', but argument 5 has type 'resource_size_t'
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/sysdev/fsl_rio.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index abdb124..c5aa179 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -1026,8 +1026,7 @@ int fsl_rio_setup(struct of_device *dev)
return -EFAULT;
}
dev_info(&dev->dev, "Of-device full name %s\n", dev->node->full_name);
- dev_info(&dev->dev, "Regs start 0x%08x size 0x%08x\n", regs.start,
- regs.end - regs.start + 1);
+ dev_info(&dev->dev, "Regs: %pR\n", ®s);
dt_range = of_get_property(dev->node, "ranges", &rlen);
if (!dt_range) {
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH] fsldma: Fix compile warnings
From: Dan Williams @ 2009-05-13 21:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1242249957-10352-1-git-send-email-galak@kernel.crashing.org>
On Wed, May 13, 2009 at 2:25 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
> We we build with dma_addr_t as a 64-bit quantity we get:
>
> drivers/dma/fsldma.c: In function 'fsl_chan_xfer_ld_queue':
> drivers/dma/fsldma.c:625: warning: cast to pointer from integer of different size
> drivers/dma/fsldma.c: In function 'fsl_dma_chan_do_interrupt':
> drivers/dma/fsldma.c:737: warning: cast to pointer from integer of different size
> drivers/dma/fsldma.c:737: warning: cast to pointer from integer of different size
> drivers/dma/fsldma.c: In function 'of_fsl_dma_probe':
> drivers/dma/fsldma.c:927: warning: cast to pointer from integer of different
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Dan Williams <dan.j.williams@intel.com>
I'm fine with this going through your tree.
Thanks,
Dan
^ permalink raw reply
* [PATCH] fsldma: Fix compile warnings
From: Kumar Gala @ 2009-05-13 21:25 UTC (permalink / raw)
To: dan.j.williams; +Cc: linuxppc-dev, linux-kernel
We we build with dma_addr_t as a 64-bit quantity we get:
drivers/dma/fsldma.c: In function 'fsl_chan_xfer_ld_queue':
drivers/dma/fsldma.c:625: warning: cast to pointer from integer of different size
drivers/dma/fsldma.c: In function 'fsl_dma_chan_do_interrupt':
drivers/dma/fsldma.c:737: warning: cast to pointer from integer of different size
drivers/dma/fsldma.c:737: warning: cast to pointer from integer of different size
drivers/dma/fsldma.c: In function 'of_fsl_dma_probe':
drivers/dma/fsldma.c:927: warning: cast to pointer from integer of different
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
drivers/dma/fsldma.c | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index da8a8ed..66a7687 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -622,8 +622,8 @@ static void fsl_chan_xfer_ld_queue(struct fsl_dma_chan *fsl_chan)
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;
- dev_dbg(fsl_chan->dev, "xfer LDs staring from %p\n",
- (void *)next_dest_addr);
+ dev_dbg(fsl_chan->dev, "xfer LDs staring from 0x%llx\n",
+ (unsigned long long)next_dest_addr);
set_cdar(fsl_chan, next_dest_addr);
dma_start(fsl_chan);
} else {
@@ -734,8 +734,9 @@ static irqreturn_t fsl_dma_chan_do_interrupt(int irq, void *data)
*/
if (stat & FSL_DMA_SR_EOSI) {
dev_dbg(fsl_chan->dev, "event: End-of-segments INT\n");
- dev_dbg(fsl_chan->dev, "event: clndar %p, nlndar %p\n",
- (void *)get_cdar(fsl_chan), (void *)get_ndar(fsl_chan));
+ dev_dbg(fsl_chan->dev, "event: clndar 0x%llx, nlndar 0x%llx\n",
+ (unsigned long long)get_cdar(fsl_chan),
+ (unsigned long long)get_ndar(fsl_chan));
stat &= ~FSL_DMA_SR_EOSI;
update_cookie = 1;
}
@@ -925,8 +926,8 @@ static int __devinit of_fsl_dma_probe(struct of_device *dev,
}
dev_info(&dev->dev, "Probe the Freescale DMA driver for %s "
- "controller at %p...\n",
- match->compatible, (void *)fdev->reg.start);
+ "controller at 0x%llx...\n",
+ match->compatible, (unsigned long long)fdev->reg.start);
fdev->reg_base = ioremap(fdev->reg.start, fdev->reg.end
- fdev->reg.start + 1);
--
1.6.0.6
^ permalink raw reply related
* [PATCH v2] sata_fsl: Fix compile warnings
From: Kumar Gala @ 2009-05-13 21:23 UTC (permalink / raw)
To: jeff; +Cc: linux-ide, linux-kernel, linuxppc-dev
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 <galak@kernel.crashing.org>
---
* had one too many 'x'
- k
drivers/ata/sata_fsl.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index c2e90e1..a9c4e0e 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -332,13 +332,14 @@ static unsigned int sata_fsl_fill_sg(struct ata_queued_cmd *qc, void *cmd_desc,
dma_addr_t sg_addr = sg_dma_address(sg);
u32 sg_len = sg_dma_len(sg);
- VPRINTK("SATA FSL : fill_sg, sg_addr = 0x%x, sg_len = %d\n",
- sg_addr, sg_len);
+ VPRINTK("SATA FSL : fill_sg, sg_addr = 0x%llx, sg_len = %d\n",
+ (unsigned long long)sg_addr, sg_len);
/* warn if each s/g element is not dword aligned */
if (sg_addr & 0x03)
ata_port_printk(qc->ap, KERN_ERR,
- "s/g addr unaligned : 0x%x\n", sg_addr);
+ "s/g addr unaligned : 0x%llx\n",
+ (unsigned long long)sg_addr);
if (sg_len & 0x03)
ata_port_printk(qc->ap, KERN_ERR,
"s/g len unaligned : 0x%x\n", sg_len);
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH] sata_fsl: Fix compile warnings
From: Becky Bruce @ 2009-05-13 21:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-ide, linux-kernel, jeff, linuxppc-dev
In-Reply-To: <1242249131-25014-1-git-send-email-galak@kernel.crashing.org>
On May 13, 2009, at 4:12 PM, 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 <galak@kernel.crashing.org>
> ---
> drivers/ata/sata_fsl.c | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
> index c2e90e1..c7ee52d 100644
> --- a/drivers/ata/sata_fsl.c
> +++ b/drivers/ata/sata_fsl.c
> @@ -332,13 +332,14 @@ static unsigned int sata_fsl_fill_sg(struct
> ata_queued_cmd *qc, void *cmd_desc,
> dma_addr_t sg_addr = sg_dma_address(sg);
> u32 sg_len = sg_dma_len(sg);
>
> - VPRINTK("SATA FSL : fill_sg, sg_addr = 0x%x, sg_len = %d\n",
> - sg_addr, sg_len);
> + VPRINTK("SATA FSL : fill_sg, sg_addr = 0x%llx, sg_len = %d\n",
> + (unsigned long long)sg_addr, sg_len);
>
> /* warn if each s/g element is not dword aligned */
> if (sg_addr & 0x03)
> ata_port_printk(qc->ap, KERN_ERR,
> - "s/g addr unaligned : 0x%x\n", sg_addr);
> + "s/g addr unaligned : 0x%llxx\n",
You have an extra "x" in there....
Cheers,
B
^ permalink raw reply
* [PATCH] sata_fsl: Fix compile warnings
From: Kumar Gala @ 2009-05-13 21:12 UTC (permalink / raw)
To: jeff; +Cc: linux-ide, linux-kernel, linuxppc-dev
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 <galak@kernel.crashing.org>
---
drivers/ata/sata_fsl.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index c2e90e1..c7ee52d 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -332,13 +332,14 @@ static unsigned int sata_fsl_fill_sg(struct ata_queued_cmd *qc, void *cmd_desc,
dma_addr_t sg_addr = sg_dma_address(sg);
u32 sg_len = sg_dma_len(sg);
- VPRINTK("SATA FSL : fill_sg, sg_addr = 0x%x, sg_len = %d\n",
- sg_addr, sg_len);
+ VPRINTK("SATA FSL : fill_sg, sg_addr = 0x%llx, sg_len = %d\n",
+ (unsigned long long)sg_addr, sg_len);
/* warn if each s/g element is not dword aligned */
if (sg_addr & 0x03)
ata_port_printk(qc->ap, KERN_ERR,
- "s/g addr unaligned : 0x%x\n", sg_addr);
+ "s/g addr unaligned : 0x%llxx\n",
+ (unsigned long long)sg_addr);
if (sg_len & 0x03)
ata_port_printk(qc->ap, KERN_ERR,
"s/g len unaligned : 0x%x\n", sg_len);
--
1.6.0.6
^ permalink raw reply related
* Re: question about softirqs
From: Thomas Gleixner @ 2009-05-13 20:55 UTC (permalink / raw)
To: Andi Kleen
Cc: Peter Zijlstra, netdev, Steven Rostedt, linuxppc-dev, paulus,
Ingo Molnar, David Miller
In-Reply-To: <20090513195340.GC19296@one.firstfloor.org>
On Wed, 13 May 2009, Andi Kleen wrote:
> On Wed, May 13, 2009 at 01:44:59PM -0600, Chris Friesen wrote:
> > Andi Kleen wrote:
> > > On Wed, May 13, 2009 at 01:04:09PM -0600, Chris Friesen wrote:
> > >> Andi Kleen wrote:
> > >>
> > >>> network packets are normally processed by the network packet interrupt's
> > >>> softirq or alternatively in the NAPI poll loop.
> > >> If we have a high priority task, ksoftirqd may not get a chance to run.
> > >
> > > In this case the next interrupt will also process them. It will just
> > > go more slowly because interrupts limit the work compared to ksoftirqd.
> >
> > I realize that they will eventually get processed. My point is that the
> > documentation (in-kernel, online, and in various books) says that
> > softirqs will be processed _on the return from a syscall_.
>
> They are. The documentation is correct.
No, the documentation is wrong for the case that the task, which
raised the softirq and therefor woke up ksoftirqd, has a higher
priority than ksoftirqd. In that case the kernel does _NOT_ schedule
ksoftirqd in the return from syscall path.
And that's all what Chris is pointing out.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH] mmc: Fix the wrong accessor to HOSTVER register
From: Pierre Ossman @ 2009-05-13 19:47 UTC (permalink / raw)
To: Dave Liu, avorontsov; +Cc: linuxppc-dev, sdhci-devel, ben-linux
In-Reply-To: <1241606407-18685-1-git-send-email-daveliu@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 639 bytes --]
On Wed, 6 May 2009 18:40:07 +0800
Dave Liu <daveliu@freescale.com> wrote:
> Freescale eSDHC controller has the special order for
> the HOST version register. that is not same as the other's
> registers. The address of HOSTVER in spec is 0xFE, and
> we need use the in_be16(0xFE) to access it, not in_be16(0xFC).
>
> Signed-off-by: Dave Liu <daveliu@freescale.com>
> ---
Any objections, Anton?
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: question about softirqs
From: Andi Kleen @ 2009-05-13 19:53 UTC (permalink / raw)
To: Chris Friesen
Cc: Peter Zijlstra, netdev, Ingo Molnar, Steven Rostedt, linuxppc-dev,
Andi Kleen, paulus, Thomas Gleixner, David Miller
In-Reply-To: <4A0B233B.8010105@nortel.com>
On Wed, May 13, 2009 at 01:44:59PM -0600, Chris Friesen wrote:
> Andi Kleen wrote:
> > On Wed, May 13, 2009 at 01:04:09PM -0600, Chris Friesen wrote:
> >> Andi Kleen wrote:
> >>
> >>> network packets are normally processed by the network packet interrupt's
> >>> softirq or alternatively in the NAPI poll loop.
> >> If we have a high priority task, ksoftirqd may not get a chance to run.
> >
> > In this case the next interrupt will also process them. It will just
> > go more slowly because interrupts limit the work compared to ksoftirqd.
>
> I realize that they will eventually get processed. My point is that the
> documentation (in-kernel, online, and in various books) says that
> softirqs will be processed _on the return from a syscall_.
They are. The documentation is correct.
What might not be all processed is all packets that are in the per CPU
backlog queue when the network softirq runs (for non NAPI, for NAPI that's
obsolete anyways). That's because there are limits.
Or when new work comes in in parallel it doesn't process it all.
But that's always the case -- no queue is infinite, so you have
always situations where it can drop or delay items.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: question about softirqs
From: Chris Friesen @ 2009-05-13 19:44 UTC (permalink / raw)
To: Andi Kleen
Cc: Peter Zijlstra, netdev, Ingo Molnar, Steven Rostedt, linuxppc-dev,
paulus, Thomas Gleixner, David Miller
In-Reply-To: <20090513191354.GB19296@one.firstfloor.org>
Andi Kleen wrote:
> On Wed, May 13, 2009 at 01:04:09PM -0600, Chris Friesen wrote:
>> Andi Kleen wrote:
>>
>>> network packets are normally processed by the network packet interrupt's
>>> softirq or alternatively in the NAPI poll loop.
>> If we have a high priority task, ksoftirqd may not get a chance to run.
>
> In this case the next interrupt will also process them. It will just
> go more slowly because interrupts limit the work compared to ksoftirqd.
I realize that they will eventually get processed. My point is that the
documentation (in-kernel, online, and in various books) says that
softirqs will be processed _on the return from a syscall_. As we all
agree, this is not necessarily the case.
Chris
^ permalink raw reply
* Re: [PATCH] [PowerPC] MPC8272ADS: fix device tree for 8 MB flash size
From: Wolfgang Denk @ 2009-05-13 19:42 UTC (permalink / raw)
To: Li Yang; +Cc: Scott Wood, linuxppc-dev, linux-kernel
In-Reply-To: <2a27d3730905130328m27743852w2d68a62ebc32ce31@mail.gmail.com>
Dear Li Yang,
In message <2a27d3730905130328m27743852w2d68a62ebc32ce31@mail.gmail.com> you wrote:
>
> Although 8MB seems to be the common size used. It can be very easy
> changed as a pluggable module. It might be better to make the code
> working for any reasonable flash sizes.
You either have to provide a correct device tree for your board, or
use a boot loader / boot wrapper that fixes the flash base address and
size.
At the moment, U-Boot does not contain any code yet to do that
(patches welcome :-), and as far as I understand the cuImage wrapper
works just the other way round: it adjusts the mappings to the
settings in the device tree, which may or may not match the actual
hardware. This may work, but at least gives you a different flash
memory map in Linux than what you had before in U-Boot, so it's not
really nice either.
Hm... it seems the majority of MPC8272ADS boards seems to come indeed
with 8 MB NOR flash, so I wonder if the patch should actually go in?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
In accord with UNIX philosophy, Perl gives you enough rope to hang
yourself. - L. Wall & R. L. Schwartz, _Programming Perl_
^ permalink raw reply
* Re: question about softirqs
From: Andi Kleen @ 2009-05-13 19:13 UTC (permalink / raw)
To: Chris Friesen
Cc: Peter Zijlstra, netdev, Ingo Molnar, Steven Rostedt, linuxppc-dev,
Andi Kleen, paulus, Thomas Gleixner, David Miller
In-Reply-To: <4A0B19A9.1090206@nortel.com>
On Wed, May 13, 2009 at 01:04:09PM -0600, Chris Friesen wrote:
> Andi Kleen wrote:
>
> > network packets are normally processed by the network packet interrupt's
> > softirq or alternatively in the NAPI poll loop.
>
> If we have a high priority task, ksoftirqd may not get a chance to run.
In this case the next interrupt will also process them. It will just
go more slowly because interrupts limit the work compared to ksoftirqd.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ 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