Re: [PATCH 07/13] powerpc/ps3: printing fixups for l64 to ll64 conversion: drivers/block
On Wed, Jan 14 2009, Stephen Rothwell wrote: > > Signed-off-by: Stephen Rothwell > --- > drivers/block/ps3disk.c | 18 +- > 1 files changed, 9 insertions(+), 9 deletions(-) > > Jens, if its OK by you, this could go in via the PowerPC tree. Of course. -- Jens Axboe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Re: mpc5200b configure nand driver via dts
> > On Mon, Jan 12, 2009 at 2:07 AM,
> wrote:
> >> hello,
> >>
> >> I have some problems with an mpc5200b based board. It's nearly
> compatible to
> >> the lite5200b board.
> >> I connected an samsung k9k8g08u0a nand flash via the lpb bus. This
> works
> >> fine with an self written nand driver.
> >> Now I try to use the standard nand driver from linux and configure
> it via
> >> the dts file. But this doesn't work and I get
> >> the following output:
> >>
> >> n...@1,0 { //cs1
> >>compatible = "samsung, k9k8g08u08", "cfi-flash";
> > ^
> >
> > NAND Flash is not a CFI flash device. The cfi-flash driver won't
> work with it.
Which compatible mode whould you choose ?
> >
> >> Now my questions are:
> >> Is there any error in the dts configuration?
> >> Is it principle posible to configure a nand flash via the dts
> file (in
> >> combination with mpc5200b)?
> >
> > It is possible to *describe* the NAND flash via the dts file. The
> dts
> > file doesn't configure anything. It just describes the hardware
> > layout so that you can write or bind the appropriate driver to the
> > device. I don't know if a device tree binding has been defined for
> > NAND flash yet.
> I find 3 MTD NAND drivers with OF bindings in
> linux-2.6/drivers/mtd/nand
>
> $ grep -l of_device *.c
> fsl_elbc_nand.c
> fsl_upm.c
> pasemi_nand.c
>
> The bindings for the FSL UPM are described in
> http://lxr.linux.no/linux
v2.6.28/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt.
> Something similar is needed for his board (NAND connected to lpb) as
> well.
Am I wrong or is the MTD_NAND_FSL_UPM only useable with PPC_83xx or
PPC_85xx?
>
> >> I read in some forums that the nand flash must be activated in
> the u-boot
> >> before it can be configured via dts.
> >
> > You definitely need to set up the CS line for the NAND before using
> it
> > in Linux. Typically this is done in U-Boot, but in a pinch it can
> be
> > done in the platform support code (arch/powerpc/platforms/52xx/*)
>
> Yep, and also the R/B pin should be handled somehow, preferably using
> the OF GPIO interface.
I set the upper named points in the u-boot, now.
+++ b/board/ybox/ybox.c
@@ -282,6 +282,32 @@ void flash_preinit(void)
* executing in flash.
*/
*(vu_long *)MPC5XXX_BOOTCS_CFG &= ~0x1; /* clear RO */
+
+
+ /* Configure PSC3_6 as ChipSelect for NAND Flash chip
+set PSC3_6 pin as GPIO output */
+*(vu_long *)MPC5XXX_GPIO_ENABLE |= 0x1000; /*enable GPIO*/
+*(vu_long *)MPC5XXX_GPIO_ODE &= ~0x1000; /* no OpenDrain
*/
+*(vu_long *)MPC5XXX_GPIO_DIR |= 0x1000; /* Direction =
output */
+*(vu_long *)MPC5XXX_GPIO_DATA_O |= 0x1000; /* Set CS to 1
(low active)*/
+ /* NAND config*/
+ /* Configure IRQ_0 as input for Ready/Busy pin*/
+*(vu_long *)MPC5XXX_ICTL_EXT &= ~0x0800; /*disable IRQ_0
interrupt */
+*(vu_long *)MPC5XXX_ICTL_EXT |= 0x00C0; /*low active */
+ *(vu_long *)MPC5XXX_ADDECR &= ~0x0002; /*disable cs1 */
+
+/* Configure the ChipSelect 1 on LocalPlusBus for data
transfers
+there is a config chip select function allready, but beter do
all for nand
+at one place */
+/*CS1 start / end address*/
+*(vu_long *)MPC5XXX_CS1_START = 0x7000;
+*(vu_long *)MPC5XXX_CS1_STOP = (0x7000 + 0x100);
+/*CS1 master enable */
+*(vu_long *)MPC5XXX_CS_CTRL = 0x01;
+*(vu_long *)MPC5XXX_CS1_CFG = 0x0f0f1800;
+ *(vu_long *)MPC5XXX_ADDECR |= ~0x0002; /*enable cs1 */
+/*enable PIN as ChipSelect*/
+*(vu_long *)MPC5XXX_GPS_PORT_CONFIG |= 0x8000;
}
Thanks for your replays
Best regards
Florian Belser
Heute schon ge"freeMail"t?
Jetzt kostenlose
E-Mail-Adresse
sichern!
http://email.freenet.de/dienste/emailoffice/produktuebersicht/basic/mail/index.html?pid=6831
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 09/13] powerpc/ps3: printing fixups for l64 to ll64 conversion: sound/ppc
At Wed, 14 Jan 2009 17:07:55 +1100,
Stephen Rothwell wrote:
>
>
> Signed-off-by: Stephen Rothwell
Acked-by: Takashi Iwai
> ---
> sound/ppc/snd_ps3.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> Takashi, if it is OK with you, this could go in via the PowerPC tree.
Yes, please let it go there.
thanks,
Takashi
>
> diff --git a/sound/ppc/snd_ps3.c b/sound/ppc/snd_ps3.c
> index 8f9e385..ff32111 100644
> --- a/sound/ppc/snd_ps3.c
> +++ b/sound/ppc/snd_ps3.c
> @@ -477,7 +477,7 @@ static int snd_ps3_pcm_prepare(struct snd_pcm_substream
> *substream)
> card->dma_start_bus_addr[SND_PS3_CH_R] =
> runtime->dma_addr + (runtime->dma_bytes / 2);
>
> - pr_debug("%s: vaddr=%p bus=%#lx\n", __func__,
> + pr_debug("%s: vaddr=%p bus=%#llx\n", __func__,
>card->dma_start_vaddr[SND_PS3_CH_L],
>card->dma_start_bus_addr[SND_PS3_CH_L]);
>
> @@ -1030,7 +1030,7 @@ static int __init snd_ps3_driver_probe(struct
> ps3_system_bus_device *dev)
> pr_info("%s: nullbuffer alloc failed\n", __func__);
> goto clean_preallocate;
> }
> - pr_debug("%s: null vaddr=%p dma=%#lx\n", __func__,
> + pr_debug("%s: null vaddr=%p dma=%#llx\n", __func__,
>the_card.null_buffer_start_vaddr,
>the_card.null_buffer_start_dma_addr);
> /* set default sample rate/word width */
> --
> 1.6.0.5
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 13/13] powerpc/ps3: printing fixups for l64 to ll64 conversion: drivers/video
Signed-off-by: Stephen Rothwell --- drivers/video/ps3fb.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Antonino, if it is OK with you, this could go in via the PowerPC tree. diff --git a/drivers/video/ps3fb.c b/drivers/video/ps3fb.c index 38ac805..87f826e 100644 --- a/drivers/video/ps3fb.c +++ b/drivers/video/ps3fb.c @@ -1006,7 +1006,7 @@ static int ps3fb_xdr_settings(u64 xdr_lpar, struct device *dev) __func__, status); return -ENXIO; } - dev_dbg(dev, "video:%p ioif:%lx lpar:%lx size:%lx\n", + dev_dbg(dev, "video:%p ioif:%lx lpar:%llx size:%lx\n", ps3fb_videomemory.address, GPU_IOIF, xdr_lpar, ps3fb_videomemory.size); @@ -1133,7 +1133,7 @@ static int __devinit ps3fb_probe(struct ps3_system_bus_device *dev) __func__, status); goto err; } - dev_dbg(&dev->core, "ddr:lpar:0x%lx\n", ddr_lpar); + dev_dbg(&dev->core, "ddr:lpar:0x%llx\n", ddr_lpar); status = lv1_gpu_context_allocate(ps3fb.memory_handle, 0, &ps3fb.context_handle, -- 1.6.0.5 -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 12/13] powerpc/ps3: printing fixups for l64 to ll64 conversion: drivers/scsi
Signed-off-by: Stephen Rothwell
---
drivers/scsi/ps3rom.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
James, if it is OK with you, this could go in via the PowerPC tree.
diff --git a/drivers/scsi/ps3rom.c b/drivers/scsi/ps3rom.c
index ce48e2d..ca0dd33 100644
--- a/drivers/scsi/ps3rom.c
+++ b/drivers/scsi/ps3rom.c
@@ -290,11 +290,11 @@ static irqreturn_t ps3rom_interrupt(int irq, void *data)
if (tag != dev->tag)
dev_err(&dev->sbd.core,
- "%s:%u: tag mismatch, got %lx, expected %lx\n",
+ "%s:%u: tag mismatch, got %llx, expected %llx\n",
__func__, __LINE__, tag, dev->tag);
if (res) {
- dev_err(&dev->sbd.core, "%s:%u: res=%d status=0x%lx\n",
+ dev_err(&dev->sbd.core, "%s:%u: res=%d status=0x%llx\n",
__func__, __LINE__, res, status);
return IRQ_HANDLED;
}
@@ -364,7 +364,7 @@ static int __devinit ps3rom_probe(struct
ps3_system_bus_device *_dev)
if (dev->blk_size != CD_FRAMESIZE) {
dev_err(&dev->sbd.core,
- "%s:%u: cannot handle block size %lu\n", __func__,
+ "%s:%u: cannot handle block size %llu\n", __func__,
__LINE__, dev->blk_size);
return -EINVAL;
}
--
1.6.0.5
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 11/13] powerpc/ps3: printing fixups for l64 to ll64 conversion: drivers/ps3
Also some min -> mint_t conversion.
Signed-off-by: Stephen Rothwell
---
drivers/ps3/ps3-lpm.c | 16
drivers/ps3/ps3-vuart.c |8
drivers/ps3/ps3stor_lib.c | 14 +++---
3 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/ps3/ps3-lpm.c b/drivers/ps3/ps3-lpm.c
index 204158c..fe96793 100644
--- a/drivers/ps3/ps3-lpm.c
+++ b/drivers/ps3/ps3-lpm.c
@@ -732,7 +732,7 @@ static u64 pm_signal_group_to_ps3_lv1_signal_group(u64
group)
case 8:
return pm_translate_signal_group_number_on_island8(subgroup);
default:
- dev_dbg(sbd_core(), "%s:%u: island not found: %lu\n", __func__,
+ dev_dbg(sbd_core(), "%s:%u: island not found: %llu\n", __func__,
__LINE__, group);
BUG();
break;
@@ -765,7 +765,7 @@ static int __ps3_set_signal(u64 lv1_signal_group, u64
bus_select,
signal_select, attr1, attr2, attr3);
if (ret)
dev_err(sbd_core(),
- "%s:%u: error:%d 0x%lx 0x%lx 0x%lx 0x%lx 0x%lx 0x%lx\n",
+ "%s:%u: error:%d 0x%llx 0x%llx 0x%llx 0x%llx 0x%llx
0x%llx\n",
__func__, __LINE__, ret, lv1_signal_group, bus_select,
signal_select, attr1, attr2, attr3);
@@ -908,7 +908,7 @@ void ps3_disable_pm(u32 cpu)
lpm_priv->tb_count = tmp;
- dev_dbg(sbd_core(), "%s:%u: tb_count %lu (%lxh)\n", __func__, __LINE__,
+ dev_dbg(sbd_core(), "%s:%u: tb_count %llu (%llxh)\n", __func__,
__LINE__,
lpm_priv->tb_count, lpm_priv->tb_count);
}
EXPORT_SYMBOL_GPL(ps3_disable_pm);
@@ -938,7 +938,7 @@ int ps3_lpm_copy_tb(unsigned long offset, void *buf,
unsigned long count,
if (offset >= lpm_priv->tb_count)
return 0;
- count = min(count, lpm_priv->tb_count - offset);
+ count = min_t(u64, count, lpm_priv->tb_count - offset);
while (*bytes_copied < count) {
const unsigned long request = count - *bytes_copied;
@@ -993,7 +993,7 @@ int ps3_lpm_copy_tb_to_user(unsigned long offset, void
__user *buf,
if (offset >= lpm_priv->tb_count)
return 0;
- count = min(count, lpm_priv->tb_count - offset);
+ count = min_t(u64, count, lpm_priv->tb_count - offset);
while (*bytes_copied < count) {
const unsigned long request = count - *bytes_copied;
@@ -1013,7 +1013,7 @@ int ps3_lpm_copy_tb_to_user(unsigned long offset, void
__user *buf,
result = copy_to_user(buf, lpm_priv->tb_cache, tmp);
if (result) {
- dev_dbg(sbd_core(), "%s:%u: 0x%lx bytes at 0x%p\n",
+ dev_dbg(sbd_core(), "%s:%u: 0x%llx bytes at 0x%p\n",
__func__, __LINE__, tmp, buf);
dev_err(sbd_core(), "%s:%u: copy_to_user failed: %d\n",
__func__, __LINE__, result);
@@ -1148,8 +1148,8 @@ int ps3_lpm_open(enum ps3_lpm_tb_type tb_type, void
*tb_cache,
lpm_priv->shadow.group_control = PS3_LPM_SHADOW_REG_INIT;
lpm_priv->shadow.debug_bus_control = PS3_LPM_SHADOW_REG_INIT;
- dev_dbg(sbd_core(), "%s:%u: lpm_id 0x%lx, outlet_id 0x%lx, "
- "tb_size 0x%lx\n", __func__, __LINE__, lpm_priv->lpm_id,
+ dev_dbg(sbd_core(), "%s:%u: lpm_id 0x%llx, outlet_id 0x%llx, "
+ "tb_size 0x%llx\n", __func__, __LINE__, lpm_priv->lpm_id,
lpm_priv->outlet_id, tb_size);
return 0;
diff --git a/drivers/ps3/ps3-vuart.c b/drivers/ps3/ps3-vuart.c
index 264c447..e4ad5ba 100644
--- a/drivers/ps3/ps3-vuart.c
+++ b/drivers/ps3/ps3-vuart.c
@@ -114,7 +114,7 @@ struct ports_bmp {
static void __maybe_unused _dump_ports_bmp(
const struct ports_bmp *bmp, const char *func, int line)
{
- pr_debug("%s:%d: ports_bmp: %016lxh\n", func, line, bmp->status);
+ pr_debug("%s:%d: ports_bmp: %016llxh\n", func, line, bmp->status);
}
#define dump_port_params(_b) _dump_port_params(_b, __func__, __LINE__)
@@ -250,7 +250,7 @@ static int ps3_vuart_get_rx_bytes_waiting(struct
ps3_system_bus_device *dev,
dev_dbg(&dev->core, "%s:%d: rx_bytes failed: %s\n",
__func__, __LINE__, ps3_result(result));
- dev_dbg(&dev->core, "%s:%d: %lxh\n", __func__, __LINE__,
+ dev_dbg(&dev->core, "%s:%d: %llxh\n", __func__, __LINE__,
*bytes_waiting);
return result;
}
@@ -297,7 +297,7 @@ static int ps3_vuart_get_interrupt_status(struct
ps3_system_bus_device *dev,
*status = tmp & priv->interrupt_mask;
- dev_dbg(&dev->core, "%s:%d: m %lxh, s %lxh, m&s %lxh\n",
+ dev_dbg(&dev->core, "%s:%d: m %llxh, s %llxh, m&s %lxh\n",
__func__, __LINE__, priv->interrupt_mask, tmp, *status);
return result;
@@ -594,7 +594,7 @@ static
[PATCH 10/13] powerpc/ps3: printing fixups for l64 to ll64 convserion: drivers/net
Signed-off-by: Stephen Rothwell
---
drivers/net/ps3_gelic_wireless.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ps3_gelic_wireless.c b/drivers/net/ps3_gelic_wireless.c
index ec23142..335da48 100644
--- a/drivers/net/ps3_gelic_wireless.c
+++ b/drivers/net/ps3_gelic_wireless.c
@@ -2168,7 +2168,7 @@ static void gelic_wl_connected_event(struct gelic_wl_info
*wl,
complete(&wl->assoc_done);
netif_carrier_on(port_to_netdev(wl_port(wl)));
} else
- pr_debug("%s: event %#lx under wpa\n",
+ pr_debug("%s: event %#llx under wpa\n",
__func__, event);
}
--
1.6.0.5
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 09/13] powerpc/ps3: printing fixups for l64 to ll64 conversion: sound/ppc
Signed-off-by: Stephen Rothwell
---
sound/ppc/snd_ps3.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Takashi, if it is OK with you, this could go in via the PowerPC tree.
diff --git a/sound/ppc/snd_ps3.c b/sound/ppc/snd_ps3.c
index 8f9e385..ff32111 100644
--- a/sound/ppc/snd_ps3.c
+++ b/sound/ppc/snd_ps3.c
@@ -477,7 +477,7 @@ static int snd_ps3_pcm_prepare(struct snd_pcm_substream
*substream)
card->dma_start_bus_addr[SND_PS3_CH_R] =
runtime->dma_addr + (runtime->dma_bytes / 2);
- pr_debug("%s: vaddr=%p bus=%#lx\n", __func__,
+ pr_debug("%s: vaddr=%p bus=%#llx\n", __func__,
card->dma_start_vaddr[SND_PS3_CH_L],
card->dma_start_bus_addr[SND_PS3_CH_L]);
@@ -1030,7 +1030,7 @@ static int __init snd_ps3_driver_probe(struct
ps3_system_bus_device *dev)
pr_info("%s: nullbuffer alloc failed\n", __func__);
goto clean_preallocate;
}
- pr_debug("%s: null vaddr=%p dma=%#lx\n", __func__,
+ pr_debug("%s: null vaddr=%p dma=%#llx\n", __func__,
the_card.null_buffer_start_vaddr,
the_card.null_buffer_start_dma_addr);
/* set default sample rate/word width */
--
1.6.0.5
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 07/13] powerpc/ps3: printing fixups for l64 to ll64 conversion: drivers/block
Signed-off-by: Stephen Rothwell
---
drivers/block/ps3disk.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
Jens, if its OK by you, this could go in via the PowerPC tree.
diff --git a/drivers/block/ps3disk.c b/drivers/block/ps3disk.c
index 936466f..bccc42b 100644
--- a/drivers/block/ps3disk.c
+++ b/drivers/block/ps3disk.c
@@ -141,7 +141,7 @@ static int ps3disk_submit_request_sg(struct
ps3_storage_device *dev,
start_sector = req->sector * priv->blocking_factor;
sectors = req->nr_sectors * priv->blocking_factor;
- dev_dbg(&dev->sbd.core, "%s:%u: %s %lu sectors starting at %lu\n",
+ dev_dbg(&dev->sbd.core, "%s:%u: %s %llu sectors starting at %llu\n",
__func__, __LINE__, op, sectors, start_sector);
if (write) {
@@ -178,7 +178,7 @@ static int ps3disk_submit_flush_request(struct
ps3_storage_device *dev,
LV1_STORAGE_ATA_HDDOUT, 0, 0, 0,
0, &dev->tag);
if (res) {
- dev_err(&dev->sbd.core, "%s:%u: sync cache failed 0x%lx\n",
+ dev_err(&dev->sbd.core, "%s:%u: sync cache failed 0x%llx\n",
__func__, __LINE__, res);
end_request(req, 0);
return 0;
@@ -238,11 +238,11 @@ static irqreturn_t ps3disk_interrupt(int irq, void *data)
if (tag != dev->tag)
dev_err(&dev->sbd.core,
- "%s:%u: tag mismatch, got %lx, expected %lx\n",
+ "%s:%u: tag mismatch, got %llx, expected %llx\n",
__func__, __LINE__, tag, dev->tag);
if (res) {
- dev_err(&dev->sbd.core, "%s:%u: res=%d status=0x%lx\n",
+ dev_err(&dev->sbd.core, "%s:%u: res=%d status=0x%llx\n",
__func__, __LINE__, res, status);
return IRQ_HANDLED;
}
@@ -269,7 +269,7 @@ static irqreturn_t ps3disk_interrupt(int irq, void *data)
op = read ? "read" : "write";
}
if (status) {
- dev_dbg(&dev->sbd.core, "%s:%u: %s failed 0x%lx\n", __func__,
+ dev_dbg(&dev->sbd.core, "%s:%u: %s failed 0x%llx\n", __func__,
__LINE__, op, status);
error = -EIO;
} else {
@@ -297,7 +297,7 @@ static int ps3disk_sync_cache(struct ps3_storage_device
*dev)
res = ps3stor_send_command(dev, LV1_STORAGE_ATA_HDDOUT, 0, 0, 0, 0);
if (res) {
- dev_err(&dev->sbd.core, "%s:%u: sync cache failed 0x%lx\n",
+ dev_err(&dev->sbd.core, "%s:%u: sync cache failed 0x%llx\n",
__func__, __LINE__, res);
return -EIO;
}
@@ -388,7 +388,7 @@ static int ps3disk_identify(struct ps3_storage_device *dev)
sizeof(ata_cmnd), ata_cmnd.buffer,
ata_cmnd.arglen);
if (res) {
- dev_err(&dev->sbd.core, "%s:%u: identify disk failed 0x%lx\n",
+ dev_err(&dev->sbd.core, "%s:%u: identify disk failed 0x%llx\n",
__func__, __LINE__, res);
return -EIO;
}
@@ -426,7 +426,7 @@ static int __devinit ps3disk_probe(struct
ps3_system_bus_device *_dev)
if (dev->blk_size < 512) {
dev_err(&dev->sbd.core,
- "%s:%u: cannot handle block size %lu\n", __func__,
+ "%s:%u: cannot handle block size %llu\n", __func__,
__LINE__, dev->blk_size);
return -EINVAL;
}
@@ -512,7 +512,7 @@ static int __devinit ps3disk_probe(struct
ps3_system_bus_device *_dev)
dev->regions[dev->region_idx].size*priv->blocking_factor);
dev_info(&dev->sbd.core,
-"%s is a %s (%lu MiB total, %lu MiB for OtherOS)\n",
+"%s is a %s (%llu MiB total, %lu MiB for OtherOS)\n",
gendisk->disk_name, priv->model, priv->raw_capacity >> 11,
get_capacity(gendisk) >> 11);
--
1.6.0.5
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 08/13] powerpc/ps3: printing fixups for l64 to ll64 convserion: drivers/char
Also a couple of min -> min_t changes.
Signed-off-by: Stephen Rothwell
---
drivers/char/ps3flash.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/char/ps3flash.c b/drivers/char/ps3flash.c
index 79b6f46..afbe456 100644
--- a/drivers/char/ps3flash.c
+++ b/drivers/char/ps3flash.c
@@ -44,7 +44,7 @@ static ssize_t ps3flash_read_write_sectors(struct
ps3_storage_device *dev,
u64 res = ps3stor_read_write_sectors(dev, lpar, start_sector, sectors,
write);
if (res) {
- dev_err(&dev->sbd.core, "%s:%u: %s failed 0x%lx\n", __func__,
+ dev_err(&dev->sbd.core, "%s:%u: %s failed 0x%llx\n", __func__,
__LINE__, write ? "write" : "read", res);
return -EIO;
}
@@ -59,7 +59,7 @@ static ssize_t ps3flash_read_sectors(struct
ps3_storage_device *dev,
max_sectors = dev->bounce_size / dev->blk_size;
if (sectors > max_sectors) {
- dev_dbg(&dev->sbd.core, "%s:%u Limiting sectors to %lu\n",
+ dev_dbg(&dev->sbd.core, "%s:%u Limiting sectors to %llu\n",
__func__, __LINE__, max_sectors);
sectors = max_sectors;
}
@@ -144,7 +144,7 @@ static ssize_t ps3flash_read(struct file *file, char __user
*buf, size_t count,
goto fail;
}
- n = min(remaining, sectors_read*dev->blk_size-offset);
+ n = min_t(u64, remaining, sectors_read*dev->blk_size-offset);
dev_dbg(&dev->sbd.core,
"%s:%u: copy %lu bytes from 0x%p to user 0x%p\n",
__func__, __LINE__, n, dev->bounce_buf+offset, buf);
@@ -225,7 +225,7 @@ static ssize_t ps3flash_write(struct file *file, const char
__user *buf,
if (end_read_sector >= start_read_sector) {
/* Merge head and tail */
dev_dbg(&dev->sbd.core,
- "Merged head and tail: %lu sectors at %lu\n",
+ "Merged head and tail: %llu sectors at %llu\n",
chunk_sectors, start_write_sector);
res = ps3flash_read_sectors(dev, start_write_sector,
chunk_sectors, 0);
@@ -235,7 +235,7 @@ static ssize_t ps3flash_write(struct file *file, const char
__user *buf,
if (head) {
/* Read head */
dev_dbg(&dev->sbd.core,
- "head: %lu sectors at %lu\n", head,
+ "head: %llu sectors at %llu\n", head,
start_write_sector);
res = ps3flash_read_sectors(dev,
start_write_sector,
@@ -247,7 +247,7 @@ static ssize_t ps3flash_write(struct file *file, const char
__user *buf,
start_write_sector+chunk_sectors) {
/* Read tail */
dev_dbg(&dev->sbd.core,
- "tail: %lu sectors at %lu\n", tail,
+ "tail: %llu sectors at %llu\n", tail,
start_read_sector);
sec_off = start_read_sector-start_write_sector;
res = ps3flash_read_sectors(dev,
@@ -258,7 +258,7 @@ static ssize_t ps3flash_write(struct file *file, const char
__user *buf,
}
}
- n = min(remaining, dev->bounce_size-offset);
+ n = min_t(u64, remaining, dev->bounce_size-offset);
dev_dbg(&dev->sbd.core,
"%s:%u: copy %lu bytes from user 0x%p to 0x%p\n",
__func__, __LINE__, n, buf, dev->bounce_buf+offset);
@@ -299,11 +299,11 @@ static irqreturn_t ps3flash_interrupt(int irq, void *data)
if (tag != dev->tag)
dev_err(&dev->sbd.core,
- "%s:%u: tag mismatch, got %lx, expected %lx\n",
+ "%s:%u: tag mismatch, got %llx, expected %llx\n",
__func__, __LINE__, tag, dev->tag);
if (res) {
- dev_err(&dev->sbd.core, "%s:%u: res=%d status=0x%lx\n",
+ dev_err(&dev->sbd.core, "%s:%u: res=%d status=0x%llx\n",
__func__, __LINE__, res, status);
} else {
dev->lv1_status = status;
--
1.6.0.5
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 06/13] powerpc/ps3: printing fixups for l64 to ll64 conversion: arch/powerpc
Signed-off-by: Stephen Rothwell
---
arch/powerpc/platforms/ps3/device-init.c | 26 +-
arch/powerpc/platforms/ps3/htab.c|2 +-
arch/powerpc/platforms/ps3/interrupt.c | 16
arch/powerpc/platforms/ps3/mm.c | 10 +-
arch/powerpc/platforms/ps3/os-area.c |2 +-
arch/powerpc/platforms/ps3/repository.c | 22 +++---
arch/powerpc/platforms/ps3/system-bus.c |6 +++---
7 files changed, 42 insertions(+), 42 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/device-init.c
b/arch/powerpc/platforms/ps3/device-init.c
index ca71a12..bb028f1 100644
--- a/arch/powerpc/platforms/ps3/device-init.c
+++ b/arch/powerpc/platforms/ps3/device-init.c
@@ -82,7 +82,7 @@ static int __init ps3_register_lpm_devices(void)
goto fail_rights;
}
- pr_debug("%s:%d: pu_id %lu, rights %lu(%lxh)\n",
+ pr_debug("%s:%d: pu_id %llu, rights %llu(%llxh)\n",
__func__, __LINE__, dev->lpm.pu_id, dev->lpm.rights,
dev->lpm.rights);
@@ -348,7 +348,7 @@ static int ps3_setup_storage_dev(const struct
ps3_repository_device *repo,
return -ENODEV;
}
- pr_debug("%s:%u: (%u:%u:%u): port %lu blk_size %lu num_blocks %lu "
+ pr_debug("%s:%u: (%u:%u:%u): port %llu blk_size %llu num_blocks %llu "
"num_regions %u\n", __func__, __LINE__, repo->bus_index,
repo->dev_index, repo->dev_type, port, blk_size, num_blocks,
num_regions);
@@ -394,7 +394,7 @@ static int ps3_setup_storage_dev(const struct
ps3_repository_device *repo,
result = -ENODEV;
goto fail_read_region;
}
- pr_debug("%s:%u: region %u: id %u start %lu size %lu\n",
+ pr_debug("%s:%u: region %u: id %u start %llu size %llu\n",
__func__, __LINE__, i, id, start, size);
p->regions[i].id = id;
@@ -662,13 +662,13 @@ static void ps3_find_and_add_device(u64 bus_id, u64
dev_id)
if (rem)
break;
}
- pr_warning("%s:%u: device %lu:%lu not found\n", __func__, __LINE__,
+ pr_warning("%s:%u: device %llu:%llu not found\n", __func__, __LINE__,
bus_id, dev_id);
return;
found:
if (retries)
- pr_debug("%s:%u: device %lu:%lu found after %u retries\n",
+ pr_debug("%s:%u: device %llu:%llu found after %u retries\n",
__func__, __LINE__, bus_id, dev_id, retries);
ps3_setup_dynamic_device(&repo);
@@ -715,14 +715,14 @@ static irqreturn_t ps3_notification_interrupt(int irq,
void *data)
res = lv1_storage_get_async_status(PS3_NOTIFICATION_DEV_ID, &tag,
&status);
if (tag != dev->tag)
- pr_err("%s:%u: tag mismatch, got %lx, expected %lx\n",
+ pr_err("%s:%u: tag mismatch, got %llx, expected %llx\n",
__func__, __LINE__, tag, dev->tag);
if (res) {
- pr_err("%s:%u: res %d status 0x%lx\n", __func__, __LINE__, res,
+ pr_err("%s:%u: res %d status 0x%llx\n", __func__, __LINE__, res,
status);
} else {
- pr_debug("%s:%u: completed, status 0x%lx\n", __func__,
+ pr_debug("%s:%u: completed, status 0x%llx\n", __func__,
__LINE__, status);
dev->lv1_status = status;
complete(&dev->done);
@@ -761,7 +761,7 @@ static int ps3_notification_read_write(struct
ps3_notification_device *dev,
}
if (dev->lv1_status) {
- pr_err("%s:%u: %s not completed, status 0x%lx\n", __func__,
+ pr_err("%s:%u: %s not completed, status 0x%llx\n", __func__,
__LINE__, op, dev->lv1_status);
return -EIO;
}
@@ -850,16 +850,16 @@ static int ps3_probe_thread(void *data)
if (res)
break;
- pr_debug("%s:%u: notify event type 0x%lx bus id %lu dev id %lu"
-" type %lu port %lu\n", __func__, __LINE__,
+ pr_debug("%s:%u: notify event type 0x%llx bus id %llu dev id
%llu"
+" type %llu port %llu\n", __func__, __LINE__,
notify_event->event_type, notify_event->bus_id,
notify_event->dev_id, notify_event->dev_type,
notify_event->dev_port);
if (notify_event->event_type != notify_region_probe ||
notify_event->bus_id != dev.sbd.bus_id) {
- pr_warning("%s:%u: bad notify_event: event %lu, "
- "dev_id %lu, dev_type %lu\n",
+ pr_warning("%s:%u: bad notify_event: event %llu, "
+
[PATCH 05/13] powerpc/ps3: ps3_repository_read_mm_info takes u64 * arguments
Fixes compiler warnings:
arch/powerpc/platforms/ps3/mm.c:1205: warning: passing argument 2 of
'ps3_repository_read_mm_info' from incompatible pointer type
arch/powerpc/platforms/ps3/mm.c:1205: warning: passing argument 3 of
'ps3_repository_read_mm_info' from incompatible pointer type
Signed-off-by: Stephen Rothwell
---
arch/powerpc/platforms/ps3/mm.c | 17 -
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/mm.c b/arch/powerpc/platforms/ps3/mm.c
index 5c8d066..715508c 100644
--- a/arch/powerpc/platforms/ps3/mm.c
+++ b/arch/powerpc/platforms/ps3/mm.c
@@ -80,7 +80,7 @@ enum {
struct mem_region {
u64 base;
- unsigned long size;
+ u64 size;
unsigned long offset;
};
@@ -103,7 +103,7 @@ struct mem_region {
*/
struct map {
- unsigned long total;
+ u64 total;
u64 vas_id;
u64 htab_size;
struct mem_region rm;
@@ -114,13 +114,13 @@ struct map {
static void __maybe_unused _debug_dump_map(const struct map *m,
const char *func, int line)
{
- DBG("%s:%d: map.total = %lxh\n", func, line, m->total);
- DBG("%s:%d: map.rm.size = %lxh\n", func, line, m->rm.size);
+ DBG("%s:%d: map.total = %llxh\n", func, line, m->total);
+ DBG("%s:%d: map.rm.size = %llxh\n", func, line, m->rm.size);
DBG("%s:%d: map.vas_id= %llu\n", func, line, m->vas_id);
DBG("%s:%d: map.htab_size = %llxh\n", func, line, m->htab_size);
DBG("%s:%d: map.r1.base = %llxh\n", func, line, m->r1.base);
DBG("%s:%d: map.r1.offset = %lxh\n", func, line, m->r1.offset);
- DBG("%s:%d: map.r1.size = %lxh\n", func, line, m->r1.size);
+ DBG("%s:%d: map.r1.size = %llxh\n", func, line, m->r1.size);
}
static struct map map;
@@ -240,10 +240,9 @@ static int ps3_mm_region_create(struct mem_region *r,
unsigned long size)
r->size = _ALIGN_DOWN(size, 1 << PAGE_SHIFT_16M);
DBG("%s:%d requested %lxh\n", __func__, __LINE__, size);
- DBG("%s:%d actual %lxh\n", __func__, __LINE__, r->size);
- DBG("%s:%d difference %lxh (%luMB)\n", __func__, __LINE__,
- (unsigned long)(size - r->size),
- (size - r->size) / 1024 / 1024);
+ DBG("%s:%d actual %llxh\n", __func__, __LINE__, r->size);
+ DBG("%s:%d difference %llxh (%lluMB)\n", __func__, __LINE__,
+ size - r->size, (size - r->size) / 1024 / 1024);
if (r->size == 0) {
DBG("%s:%d: size == 0\n", __func__, __LINE__);
--
1.6.0.5
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 04/13] powerpc/ps3: clear_bit/set_bit operate on unsigned longs
This fixes these compiler warning:
arch/powerpc/platforms/ps3/interrupt.c:109: warning: passing argument 2 of
'clear_bit' from incompatible pointer type
arch/powerpc/platforms/ps3/interrupt.c:130: warning: passing argument 2 of
'set_bit' from incompatible pointer type
Signed-off-by: Stephen Rothwell
---
arch/powerpc/platforms/ps3/interrupt.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/interrupt.c
b/arch/powerpc/platforms/ps3/interrupt.c
index b746792..3ea6e51 100644
--- a/arch/powerpc/platforms/ps3/interrupt.c
+++ b/arch/powerpc/platforms/ps3/interrupt.c
@@ -60,6 +60,8 @@
* gives a usable range of plug values of {NUM_ISA_INTERRUPTS..63}. Note
* that there is no constraint on how many in this set an individual thread
* can acquire.
+ *
+ * The mask is declared as unsigned long so we can use set/clear_bit on it.
*/
#define PS3_BMP_MINALIGN 64
@@ -68,7 +70,7 @@ struct ps3_bmp {
struct {
u64 status;
u64 unused_1[3];
- u64 mask;
+ unsigned long mask;
u64 unused_2[3];
};
u64 ipi_debug_brk_mask;
--
1.6.0.5
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 03/13] powerpc/ps3: the lv1_ routines have u64 parameters
We just fix up the reference parameters as the others are dealt with by
arithmetic promotion rules and don't cause warnings.
This removes warnings like this:
arch/powerpc/platforms/ps3/interrupt.c:327: warning: passing argument 1 of
'lv1_construct_event_receive_port' from incompatible pointer type
Also, these:
drivers/ps3/ps3-vuart.c:462: warning: passing argument 4 of
'ps3_vuart_raw_read' from incompatible pointer type
drivers/ps3/ps3-vuart.c:592: warning: passing argument 4 of
'ps3_vuart_raw_read' from incompatible pointer type
Signed-off-by: Stephen Rothwell
---
arch/powerpc/platforms/ps3/interrupt.c |8 +++---
arch/powerpc/platforms/ps3/mm.c | 38 +-
arch/powerpc/platforms/ps3/spu.c| 12 ++---
arch/powerpc/platforms/ps3/system-bus.c |4 ++-
drivers/ps3/ps3-vuart.c | 24 ++-
5 files changed, 49 insertions(+), 37 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/interrupt.c
b/arch/powerpc/platforms/ps3/interrupt.c
index e59634f..b746792 100644
--- a/arch/powerpc/platforms/ps3/interrupt.c
+++ b/arch/powerpc/platforms/ps3/interrupt.c
@@ -322,7 +322,7 @@ EXPORT_SYMBOL_GPL(ps3_irq_plug_destroy);
int ps3_event_receive_port_setup(enum ps3_cpu_binding cpu, unsigned int *virq)
{
int result;
- unsigned long outlet;
+ u64 outlet;
result = lv1_construct_event_receive_port(&outlet);
@@ -468,7 +468,7 @@ int ps3_io_irq_setup(enum ps3_cpu_binding cpu, unsigned int
interrupt_id,
unsigned int *virq)
{
int result;
- unsigned long outlet;
+ u64 outlet;
result = lv1_construct_io_irq_outlet(interrupt_id, &outlet);
@@ -525,7 +525,7 @@ int ps3_vuart_irq_setup(enum ps3_cpu_binding cpu, void*
virt_addr_bmp,
unsigned int *virq)
{
int result;
- unsigned long outlet;
+ u64 outlet;
u64 lpar_addr;
BUG_ON(!is_kernel_addr((u64)virt_addr_bmp));
@@ -581,7 +581,7 @@ int ps3_spe_irq_setup(enum ps3_cpu_binding cpu, unsigned
long spe_id,
unsigned int class, unsigned int *virq)
{
int result;
- unsigned long outlet;
+ u64 outlet;
BUG_ON(class > 2);
diff --git a/arch/powerpc/platforms/ps3/mm.c b/arch/powerpc/platforms/ps3/mm.c
index 4761e2d..5c8d066 100644
--- a/arch/powerpc/platforms/ps3/mm.c
+++ b/arch/powerpc/platforms/ps3/mm.c
@@ -79,7 +79,7 @@ enum {
*/
struct mem_region {
- unsigned long base;
+ u64 base;
unsigned long size;
unsigned long offset;
};
@@ -104,8 +104,8 @@ struct mem_region {
struct map {
unsigned long total;
- unsigned long vas_id;
- unsigned long htab_size;
+ u64 vas_id;
+ u64 htab_size;
struct mem_region rm;
struct mem_region r1;
};
@@ -116,9 +116,9 @@ static void __maybe_unused _debug_dump_map(const struct map
*m,
{
DBG("%s:%d: map.total = %lxh\n", func, line, m->total);
DBG("%s:%d: map.rm.size = %lxh\n", func, line, m->rm.size);
- DBG("%s:%d: map.vas_id= %lu\n", func, line, m->vas_id);
- DBG("%s:%d: map.htab_size = %lxh\n", func, line, m->htab_size);
- DBG("%s:%d: map.r1.base = %lxh\n", func, line, m->r1.base);
+ DBG("%s:%d: map.vas_id= %llu\n", func, line, m->vas_id);
+ DBG("%s:%d: map.htab_size = %llxh\n", func, line, m->htab_size);
+ DBG("%s:%d: map.r1.base = %llxh\n", func, line, m->r1.base);
DBG("%s:%d: map.r1.offset = %lxh\n", func, line, m->r1.offset);
DBG("%s:%d: map.r1.size = %lxh\n", func, line, m->r1.size);
}
@@ -146,11 +146,11 @@ EXPORT_SYMBOL(ps3_mm_phys_to_lpar);
void __init ps3_mm_vas_create(unsigned long* htab_size)
{
int result;
- unsigned long start_address;
- unsigned long size;
- unsigned long access_right;
- unsigned long max_page_size;
- unsigned long flags;
+ u64 start_address;
+ u64 size;
+ u64 access_right;
+ u64 max_page_size;
+ u64 flags;
result = lv1_query_logical_partition_address_region_info(0,
&start_address, &size, &access_right, &max_page_size,
@@ -164,7 +164,7 @@ void __init ps3_mm_vas_create(unsigned long* htab_size)
}
if (max_page_size < PAGE_SHIFT_16M) {
- DBG("%s:%d: bad max_page_size %lxh\n", __func__, __LINE__,
+ DBG("%s:%d: bad max_page_size %llxh\n", __func__, __LINE__,
max_page_size);
goto fail;
}
@@ -208,7 +208,7 @@ void ps3_mm_vas_destroy(void)
{
int result;
- DBG("%s:%d: map.vas_id= %lu\n", __func__, __LINE__, map.vas_id);
+ DBG("%s:%d: map.vas_id= %llu\n", __func__, __LINE__, map.vas_id);
if (map.vas_id) {
result = lv1_select_virtual_address_space(0);
@@ -235,7 +235,7 @@ void ps3_mm_vas_destroy(void)
static int ps3_mm_region_create(struct mem_region *r, unsigned long size)
{
int
[PATCH 02/13] powerpc/ps3: use dma_addr_t down through the stack
Push the dma_addr_t type usage all the way down to where the actual
values are manipulated.
Now that u64 is "unsigned long long", this removes warnings like:
arch/powerpc/platforms/ps3/system-bus.c:532: warning: passing argument 4 of
'ps3_dma_map' from incompatible pointer type
arch/powerpc/platforms/ps3/system-bus.c:649: warning: passing argument 4 of
'ps3_dma_map' from incompatible pointer type
Signed-off-by: Stephen Rothwell
---
arch/powerpc/include/asm/ps3.h |8 +++---
arch/powerpc/platforms/ps3/mm.c | 32 --
arch/powerpc/platforms/ps3/system-bus.c |4 +-
3 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/include/asm/ps3.h b/arch/powerpc/include/asm/ps3.h
index eead5c6..67f1812 100644
--- a/arch/powerpc/include/asm/ps3.h
+++ b/arch/powerpc/include/asm/ps3.h
@@ -103,10 +103,10 @@ struct ps3_dma_region_ops {
int (*map)(struct ps3_dma_region *,
unsigned long virt_addr,
unsigned long len,
- unsigned long *bus_addr,
+ dma_addr_t *bus_addr,
u64 iopte_pp);
int (*unmap)(struct ps3_dma_region *,
-unsigned long bus_addr,
+dma_addr_t bus_addr,
unsigned long len);
};
/**
@@ -124,9 +124,9 @@ int ps3_dma_region_init(struct ps3_system_bus_device *dev,
int ps3_dma_region_create(struct ps3_dma_region *r);
int ps3_dma_region_free(struct ps3_dma_region *r);
int ps3_dma_map(struct ps3_dma_region *r, unsigned long virt_addr,
- unsigned long len, unsigned long *bus_addr,
+ unsigned long len, dma_addr_t *bus_addr,
u64 iopte_pp);
-int ps3_dma_unmap(struct ps3_dma_region *r, unsigned long bus_addr,
+int ps3_dma_unmap(struct ps3_dma_region *r, dma_addr_t bus_addr,
unsigned long len);
/* mmio routines */
diff --git a/arch/powerpc/platforms/ps3/mm.c b/arch/powerpc/platforms/ps3/mm.c
index a4d49dd..4761e2d 100644
--- a/arch/powerpc/platforms/ps3/mm.c
+++ b/arch/powerpc/platforms/ps3/mm.c
@@ -777,7 +777,7 @@ static int dma_ioc0_region_free(struct ps3_dma_region *r)
*/
static int dma_sb_map_area(struct ps3_dma_region *r, unsigned long virt_addr,
- unsigned long len, unsigned long *bus_addr,
+ unsigned long len, dma_addr_t *bus_addr,
u64 iopte_flag)
{
int result;
@@ -800,7 +800,7 @@ static int dma_sb_map_area(struct ps3_dma_region *r,
unsigned long virt_addr,
DBG("%s:%d lpar_addr %lxh\n", __func__, __LINE__,
lpar_addr);
DBG("%s:%d len %lxh\n", __func__, __LINE__, len);
- DBG("%s:%d bus_addr %lxh (%lxh)\n", __func__, __LINE__,
+ DBG("%s:%d bus_addr %llxh (%lxh)\n", __func__, __LINE__,
*bus_addr, len);
}
@@ -832,7 +832,7 @@ static int dma_sb_map_area(struct ps3_dma_region *r,
unsigned long virt_addr,
}
static int dma_ioc0_map_area(struct ps3_dma_region *r, unsigned long virt_addr,
-unsigned long len, unsigned long *bus_addr,
+unsigned long len, dma_addr_t *bus_addr,
u64 iopte_flag)
{
int result;
@@ -872,7 +872,7 @@ static int dma_ioc0_map_area(struct ps3_dma_region *r,
unsigned long virt_addr,
return result;
}
*bus_addr = c->bus_addr + phys_addr - aligned_phys;
- DBG("%s: va=%#lx pa=%#lx a_pa=%#lx bus=%#lx\n", __func__,
+ DBG("%s: va=%#lx pa=%#lx a_pa=%#lx bus=%#llx\n", __func__,
virt_addr, phys_addr, aligned_phys, *bus_addr);
c->usage_count = 1;
@@ -889,7 +889,7 @@ static int dma_ioc0_map_area(struct ps3_dma_region *r,
unsigned long virt_addr,
* This is the common dma unmap routine.
*/
-static int dma_sb_unmap_area(struct ps3_dma_region *r, unsigned long bus_addr,
+static int dma_sb_unmap_area(struct ps3_dma_region *r, dma_addr_t bus_addr,
unsigned long len)
{
unsigned long flags;
@@ -903,7 +903,7 @@ static int dma_sb_unmap_area(struct ps3_dma_region *r,
unsigned long bus_addr,
1 << r->page_size);
unsigned long aligned_len = _ALIGN_UP(len + bus_addr
- aligned_bus, 1 << r->page_size);
- DBG("%s:%d: not found: bus_addr %lxh\n",
+ DBG("%s:%d: not found: bus_addr %llxh\n",
__func__, __LINE__, bus_addr);
DBG("%s:%d: not found: len %lxh\n",
__func__, __LINE__, len);
@@ -926,12 +926,12 @@ static int dma_sb_unmap_area(struct ps3_dma_region *r,
unsigned long bus_addr,
}
static int dma_ioc0_unmap_area(struct ps3_dma_region *r,
- unsigned long bus_addr, unsigned long len)
+ dma_addr_t bus_addr, unsigned long len)
{
unsigned long flags;
struct dma_chunk *c;
- DBG("%s: start a=%#lx l=%#lx\n", __func__, bus_addr, len);
+ DBG("%s:
[PATCH 01/13] powerpc/ps3: set_dabr takes an unsigned long
Also silences this warning:
arch/powerpc/platforms/ps3/setup.c:275: warning: initialization from
incompatible pointer type
Signed-off-by: Stephen Rothwell
---
arch/powerpc/platforms/ps3/setup.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/setup.c
b/arch/powerpc/platforms/ps3/setup.c
index 35f3e85..3331ccb 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -186,7 +186,7 @@ early_param("ps3flash", early_parse_ps3flash);
#define prealloc_ps3flash_bounce_buffer() do { } while (0)
#endif
-static int ps3_set_dabr(u64 dabr)
+static int ps3_set_dabr(unsigned long dabr)
{
enum {DABR_USER = 1, DABR_KERNEL = 2,};
--
1.6.0.5
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Fwd: [PATCH] powerpc/mpc52xx: Properly update irq_desc when set_type() is called.
On Tue, Jan 13, 2009 at 6:00 AM, Matt Sealey wrote: > Grant Likely wrote: >> >> >> Theoretically it could call IRQ handlers to be called too often. It >> might possibly be the cause of too many 'BAD' irqs being recorded > > That might explain a few USB explosions, where high bandwidth transfers > (restoring partimage disks) would make the host controller die (a freeze, > then it comes back with 'nobody cared about irq 134' etc.) and perhaps a > lockup we saw with openSUSE 11.0 installer.. > >> Now that I think of it, I should probably also change all the internal >> IRQs to be LEVEL instead of EDGE. > > And what does that really affect? I wouldn't think the internal stuff would > make any difference what it senses on? It took me most of the morning, but I traced through all the code and figured out how it is supposed to work. In this case the type field in status is indeed cosmetic. The only time I can see that it really comes into play is when edge IRQs are enabled after being disabled for replaying IRQs. It might be the source of some of the BAD irq count on the mpc5200, but it is unlikely. The real logic behind handling an IRQ is defined by the handler registered with set_irq_chip_and_handler() which the current mpc5200 PIC driver seems to be doing correctly. However, for external IRQs, the handler is not changed when the IRQ switches from the default edge sensitivity to level sensitivity. Using the wrong handler doesn't seem to actively break things, but I'm still investigating to find out if it affects performance or results in BAD irq counts. Regardless, I'm looking at a number of cleanups to the PIC code and I'll be posting a patch soon with the intent of getting it into .30. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Add init_dummy_netdev() and fix EMAC driver using it
This adds an init_dummy_netdev() function that gets a network device
structure (allocation and lifetime entirely under caller's control) and
initialize the minimum amount of fields so it can be used to schedule
NAPI polls without registering a full blown interface. This is to be
used by drivers that need to tie several hardware interfaces to a single
NAPI poll scheduler due to HW limitations.
It also updates the ibm_newemac driver to use that, this fixing the
oops on 2.6.29 due to passing NULL as "dev" to netif_napi_add()
Symbol is exported GPL only a I don't think we want binary drivers doing
that sort of acrobatics (if we want them at all).
Signed-off-by: Benjamin Herrenschmidt
---
Index: linux-work/include/linux/netdevice.h
===
--- linux-work.orig/include/linux/netdevice.h 2009-01-13 16:13:41.0
+1100
+++ linux-work/include/linux/netdevice.h2009-01-14 14:13:24.0
+1100
@@ -795,6 +795,7 @@ struct net_device
NETREG_UNREGISTERING,/* called unregister_netdevice */
NETREG_UNREGISTERED, /* completed unregister todo */
NETREG_RELEASED, /* called free_netdev */
+ NETREG_DUMMY,/* dummy device for NAPI poll */
} reg_state;
/* Called from unregister, can be used to call free_netdev */
@@ -1077,6 +1078,8 @@ extern void free_netdev(struct net_devi
extern voidsynchronize_net(void);
extern int register_netdevice_notifier(struct notifier_block *nb);
extern int unregister_netdevice_notifier(struct notifier_block
*nb);
+extern int init_dummy_netdev(struct net_device *dev);
+
extern int call_netdevice_notifiers(unsigned long val, struct net_device *dev);
extern struct net_device *dev_get_by_index(struct net *net, int ifindex);
extern struct net_device *__dev_get_by_index(struct net *net, int
ifindex);
Index: linux-work/net/core/dev.c
===
--- linux-work.orig/net/core/dev.c 2009-01-13 16:17:52.0 +1100
+++ linux-work/net/core/dev.c 2009-01-14 14:24:03.0 +1100
@@ -4434,6 +4434,45 @@ err_uninit:
}
/**
+ * init_dummy_netdev - init a dummy network device for NAPI
+ * @dev: device to init
+ *
+ * This takes a network device structure and initialize the minimum
+ * amount of fields so it can be used to schedule NAPI polls without
+ * registering a full blown interface. This is to be used by drivers
+ * that need to tie several hardware interfaces to a single NAPI
+ * poll scheduler due to HW limitations.
+ */
+int init_dummy_netdev(struct net_device *dev)
+{
+ /* Clear everything. Note we don't initialize spinlocks
+* are they aren't supposed to be taken by any of the
+* NAPI code and this dummy netdev is supposed to be
+* only ever used for NAPI polls
+*/
+ memset(dev, 0, sizeof(struct net_device));
+
+ /* make sure we BUG if trying to hit standard
+* register/unregister code path
+*/
+ dev->reg_state = NETREG_DUMMY;
+
+ /* initialize the ref count */
+ atomic_set(&dev->refcnt, 1);
+
+ /* NAPI wants this */
+ INIT_LIST_HEAD(&dev->napi_list);
+
+ /* a dummy interface is started by default */
+ set_bit(__LINK_STATE_PRESENT, &dev->state);
+ set_bit(__LINK_STATE_START, &dev->state);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(init_dummy_netdev);
+
+
+/**
* register_netdev - register a network device
* @dev: device to register
*
Index: linux-work/drivers/net/ibm_newemac/mal.c
===
--- linux-work.orig/drivers/net/ibm_newemac/mal.c 2009-01-14
14:25:10.0 +1100
+++ linux-work/drivers/net/ibm_newemac/mal.c2009-01-14 14:25:30.0
+1100
@@ -613,7 +613,9 @@ static int __devinit mal_probe(struct of
INIT_LIST_HEAD(&mal->list);
spin_lock_init(&mal->lock);
- netif_napi_add(NULL, &mal->napi, mal_poll,
+ init_dummy_netdev(&mal->dummy_dev);
+
+ netif_napi_add(&mal->dummy_dev, &mal->napi, mal_poll,
CONFIG_IBM_NEW_EMAC_POLL_WEIGHT);
/* Load power-on reset defaults */
Index: linux-work/drivers/net/ibm_newemac/mal.h
===
--- linux-work.orig/drivers/net/ibm_newemac/mal.h 2009-01-14
14:24:40.0 +1100
+++ linux-work/drivers/net/ibm_newemac/mal.h2009-01-14 14:24:58.0
+1100
@@ -214,6 +214,8 @@ struct mal_instance {
int index;
spinlock_t lock;
+ struct net_device dummy_dev;
+
unsigned int features;
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mai
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here's another batch for before -rc2. The main highlight is the u64 conversion to unsigned long long along with a bunch of patches fixing warnings due to this conversion. There will be a few more, for example the PS3 code is still pretty bad in this area, but that's about it. The rest is mostly bug fixes, moving a driver around as requested by a maintainer, a couple of trivial things, and a few late embedded changes that were posted before the merge window, but some maintainer needed more time than others to recover from whatever he got intoxicated with over new year :-) After that, I'm opening my next branch for .30 material and merge will be regressions and severe bugs only. Cheers, Ben. The following changes since commit a6525042bfdfcab128bd91fad264de10fd24a55e: Linus Torvalds (1): Merge branch 'x86-pat-for-linus' of git://git.kernel.org/.../tip/linux-2.6-tip are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Anton Vorontsov (2): powerpc/83xx: Make serial ports work on MPC8315E-RDB w/ FSL U-Boots powerpc/83xx: Move mcu_mpc8349emitx driver out of drivers/i2c/chips/ Benjamin Herrenschmidt (3): Merge commit 'kumar/kumar-next' into next Merge commit 'gcl/gcl-next' into next powerpc/powermac: Fix occasional SMP boot failure Grant Likely (1): powerpc/mpc52xx: Properly update irq_desc when set_type() is called. Ingo Molnar (1): powerpc: Change u64/s64 to a long long integer type Jason Jin (1): powerpc: Fix the ide suspend function in uli1575 John Linn (1): Xilinx: SPI: updated driver for device tree Jon Smirl (1): drivers/of: Add the of_find_i2c_device_by_node function. Kumar Gala (2): powerpc/85xx: Fix PCIe error interrupts powerpc/e500mc: Doorbells need to be taken w/exceptions disabled Michael Ellerman (1): powerpc: Enable PS3 options and QPACE in ppc64_defconfig Milton Miller (6): powerpc: Make dummy section a valid note header powerpc/kexec: Check crash_base for relocatable kernel hvc_console: Change an mb() to smp_mb() and add some comments hvc_console: Call free_irq() only if request_irq() was successful hvc_console: Do not set low_latency when using interrupts hvc_console: Use kzalloc() instead of kmalloc() + memset() Nathan Lynch (1): powerpc/cacheinfo: Rename cache_dir per-cpu variable Stephen Rothwell (3): powerpc: Cleanup from l64 to ll64 change: arch code powerpc: Cleanup from l64 to ll64 change: drivers/char powerpc: Cleanup from l64 to ll64 change: drivers/net Timur Tabi (1): powerpc/qe: add Ethernet UPSMR definitions to QE library Trent Piepho (4): powerpc/fsl-pci: Better ATMU setup for 85xx/86xx powerpc/fsl-pci: Set relaxed ordering on prefetchable ranges powerpc/fsl-booke: Don't hard-code size of struct tlbcam powerpc/fsl-booke: Remove num_tlbcam_entries Wolfram Sang (1): powerpc/mpc52xx: remove dead code from GPIO driver Yuri Tikhonov (1): powerpc/xsysace: add compatible string for non-ipcore instance roel kluin (1): powerpc/mpc5121: fix NULL test in mpc5121_clk_get utility function. arch/powerpc/boot/dts/mpc8315erdb.dts |4 +- arch/powerpc/boot/dts/mpc8544ds.dts|4 +- arch/powerpc/boot/dts/mpc8572ds.dts|4 +- arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts |2 +- arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts |2 +- arch/powerpc/configs/ppc64_defconfig | 26 - arch/powerpc/include/asm/qe.h | 19 +++- arch/powerpc/include/asm/rtas.h|2 +- arch/powerpc/include/asm/types.h |7 +- arch/powerpc/kernel/asm-offsets.c |7 + arch/powerpc/kernel/cacheinfo.c| 10 +- arch/powerpc/kernel/dma-iommu.c|4 +- arch/powerpc/kernel/head_64.S |9 ++ arch/powerpc/kernel/head_fsl_booke.S |8 +- arch/powerpc/kernel/iommu.c| 12 +- arch/powerpc/kernel/lparcfg.c | 10 +- arch/powerpc/kernel/machine_kexec.c| 25 arch/powerpc/kernel/pci_64.c |6 +- arch/powerpc/kernel/setup_64.c |6 +- arch/powerpc/kernel/vmlinux.lds.S |4 +- arch/powerpc/mm/fsl_booke_mmu.c|9 +- arch/powerpc/mm/mmu_decl.h | 11 ++- arch/powerpc/mm/stab.c |4 +- arch/powerpc/oprofile/op_model_pa6t.c |6 +- arch/powerpc/platforms/512x/clock.c|4 +- arch/powerpc/platforms/52xx/mpc52xx_gpio.c |3 - arch/powerpc/platforms/52xx/mpc52xx_pic.c |8 +- arch/powerpc/platforms/83xx/Makefile |1 + .../powerpc
Please pull from 'next' branch (for 2.6.29)(updated)
Updated to just be the small bug fixes and the move of the driver - k Please pull from 'next' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next to receive the following updates: arch/powerpc/boot/dts/mpc8315erdb.dts |4 arch/powerpc/kernel/head_fsl_booke.S |2 arch/powerpc/platforms/83xx/Makefile |1 arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 209 + arch/powerpc/platforms/Kconfig | 11 + drivers/i2c/chips/Kconfig | 11 - drivers/i2c/chips/Makefile |1 drivers/i2c/chips/mcu_mpc8349emitx.c | 209 - 8 files changed, 224 insertions(+), 224 deletions(-) Anton Vorontsov (2): powerpc/83xx: Make serial ports work on MPC8315E-RDB w/ FSL U-Boots powerpc/83xx: Move mcu_mpc8349emitx driver out of drivers/i2c/chips/ Kumar Gala (1): powerpc/e500mc: Doorbells need to be taken w/exceptions disabled ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from 'next' branch (2.6.29)
On Tue, 2009-01-13 at 15:17 -0600, Kumar Gala wrote: > On Jan 13, 2009, at 2:59 PM, Benjamin Herrenschmidt wrote: > > > On Tue, 2009-01-13 at 09:21 -0600, Kumar Gala wrote: > >> Please pull from 'next' branch of > >> > >> (this is my last pull request of 'next' for 2.6.29. I would like > >> to see > >> the 'powerpc: Unify opcode definitions and support' patch go in but > >> leave > >> that for you to pull in directly). > > > > This is really very very very late for these changes, most of them > > aren't bug fixes at all... > > True. > > >> Anton Vorontsov (4): > >> powerpc/fsl_pci: Add MPC83xx PCI-E controller RC mode support > >> powerpc/83xx: Add PCI-E support for all MPC83xx boards with > >> PCI-E > > Would like to see this feature added into .29 Can you either rebase with just that (and bug fixes) ? Or stick that in another branch ? > >> powerpc/83xx: Make serial ports work on MPC8315E-RDB w/ FSL U- > >> Boots > > A sort of bug fix. Ok. > >> powerpc/83xx: Move mcu_mpc8349emitx driver out of drivers/i2c/ > >> chips/ > > At Jean's request to move i2c clients out of drivers/i2c. Ok. > >> Kumar Gala (2): > >> powerpc/fsl-booke: Cleanup init/exception setup to be runtime > >> powerpc/e500mc: Doorbells need to be taken w/exceptions disabled > > can wait for .30 Isn't the second one a clear bug fix ? > >> Trent Piepho (3): > >> powerpc/fsl-booke: Remove code duplication in lowmem mapping > >> powerpc/fsl-booke: Allow larger CAM sizes than 256 MB > >> powerpc/fsl-booke: Make CAM entries used for lowmem configurable > > Posted we'll before.. finally got around to reviewing them.. but can > wait for .30 > > So the real question I have is when does your next branch start > queuing up changes for .30? Soon :-) > I can completely live w/these not going into .29 if they can go into > your next branch for .30 Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3] powerpc: Unify opcode definitions and support
Create a new header that becomes a single location for defining PowerPC opcodes used by code that is either generationg instructions at runtime (fixups, debug, etc.), emulating instructions, or just compiling instructions old assemblers don't know about. We currently don't handle the floating point emulation or alignment decode as both are better handled by the specific decode support they already have. Added support for the new dcbzl, dcbal, msgsnd, tlbilx, & wait instructions since older assemblers don't know about them. Signed-off-by: Kumar Gala --- * Added PPC_ prefixes to everything to ensure namespace * removed defines from traps.c arch/powerpc/include/asm/code-patching.h |4 +- arch/powerpc/include/asm/ppc-opcode.h| 68 ++ arch/powerpc/include/asm/ppc_asm.h |6 +-- arch/powerpc/kernel/crash_dump.c |2 +- arch/powerpc/kernel/entry_32.S |8 ++-- arch/powerpc/kernel/ftrace.c |8 ++-- arch/powerpc/kernel/head_booke.h |2 +- arch/powerpc/kernel/module_64.c |2 +- arch/powerpc/kernel/traps.c | 58 - arch/powerpc/lib/feature-fixups.c|4 +- 10 files changed, 101 insertions(+), 61 deletions(-) create mode 100644 arch/powerpc/include/asm/ppc-opcode.h diff --git a/arch/powerpc/include/asm/code-patching.h b/arch/powerpc/include/asm/code-patching.h index 107d9b9..37c32ab 100644 --- a/arch/powerpc/include/asm/code-patching.h +++ b/arch/powerpc/include/asm/code-patching.h @@ -11,9 +11,7 @@ */ #include - -#define PPC_NOP_INSTR 0x6000 -#define PPC_LWSYNC_INSTR 0x7c2004ac +#include /* Flags for create_branch: * "b" == create_branch(addr, target, 0); diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h new file mode 100644 index 000..027f965 --- /dev/null +++ b/arch/powerpc/include/asm/ppc-opcode.h @@ -0,0 +1,68 @@ +/* + * Copyright (C) 2009 Freescale Semicondutor, Inc. All rights reserved. + * + * provides masks and opcode images for use by code generation, emulation + * and for instructions that older assemblers might not know about + */ +#ifndef _ASM_POWERPC_PPC_OPCODE_H +#define _ASM_POWERPC_PPC_OPCODE_H + +#include +#include + +/* sorted alphabetically */ +#define PPC_INST_DCBA 0x7c0005ec +#define PPC_INST_DCBA_MASK 0xfc0007fe +#define PPC_INST_DCBAL 0x7c2005ec +#define PPC_INST_DCBZL 0x7c2007ec +#define PPC_INST_ISEL 0x7c1e +#define PPC_INST_ISEL_MASK 0xfc3e +#define PPC_INST_LSWI 0x7c0004aa +#define PPC_INST_LSWX 0x7c00042a +#define PPC_INST_LWSYNC0x7c2004ac +#define PPC_INST_MCRXR 0x7c000400 +#define PPC_INST_MCRXR_MASK0xfc0007fe +#define PPC_INST_MFSPR_PVR 0x7c1f42a6 +#define PPC_INST_MFSPR_PVR_MASK0xfc1f +#define PPC_INST_MSGSND0x7c00019c +#define PPC_INST_NOP 0x6000 +#define PPC_INST_POPCNTB 0x7cf4 +#define PPC_INST_POPCNTB_MASK 0xfc0007fe +#define PPC_INST_RFCI 0x4c66 +#define PPC_INST_RFDI 0x4c4e +#define PPC_INST_RFMCI 0x4c4c + +#define PPC_INST_STRING0x7c00042a +#define PPC_INST_STRING_MASK 0xfc0007fe +#define PPC_INST_STRING_GEN_MASK 0xfc00067e + +#define PPC_INST_STSWI 0x7c0005aa +#define PPC_INST_STSWX 0x7c00052a +#define PPC_INST_TLBILX0x7c000626 +#define PPC_INST_WAIT 0x7c7c + +/* macros to insert fields into opcodes */ +#define __PPC_RA(a)((a & 0x1f) << 16) +#define __PPC_RB(b)((b & 0x1f) << 11) +#define __PPC_T_TLB(t) ((t & 0x3) << 21) +#define __PPC_WC(w)((w & 0x3) << 21) + +/* Deal with instructions that older assemblers aren't aware of */ +#definePPC_DCBAL(a, b) stringify_in_c(.long PPC_INST_DCBAL | \ + __PPC_RA(a) | __PPC_RB(b)) +#definePPC_DCBZL(a, b) stringify_in_c(.long PPC_INST_DCBZL | \ + __PPC_RA(a) | __PPC_RB(b)) +#define PPC_MSGSND(b) stringify_in_c(.long PPC_INST_MSGSND | \ + __PPC_RB(b)) +#define PPC_RFCI stringify_in_c(.long PPC_INST_RFCI) +#define PPC_RFDI stringify_in_c(.long PPC_INST_RFDI) +#define PPC_RFMCI stringify_in_c(.long PPC_INST_RFMCI) +#define PPC_TLBILX(t, a, b)stringify_in_c(.long PPC_INST_TLBILX | \ + __T_TLB(t) | __PPC_RA(a) | __PPC_RB(b)) +#define PPC_TLBILX_ALL(a, b) TLBILX(0, a, b) +#define PPC_TLBILX_PID(a, b) TLBILX(1, a, b) +#define PPC_TLBILX_VA(a, b)TLBILX(3, a, b) +#define PPC_WAIT(w)
Re: Please pull from 'next' branch (2.6.29)
On Jan 13, 2009, at 3:17 PM, Kumar Gala wrote: powerpc/83xx: Move mcu_mpc8349emitx driver out of drivers/i2c/ chips/ At Jean's request to move i2c clients out of drivers/i2c. Getting this into .29 might be useful since its just a driver move and saves us merge headache's later. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from 'next' branch (2.6.29)
On Jan 13, 2009, at 2:59 PM, Benjamin Herrenschmidt wrote: On Tue, 2009-01-13 at 09:21 -0600, Kumar Gala wrote: Please pull from 'next' branch of (this is my last pull request of 'next' for 2.6.29. I would like to see the 'powerpc: Unify opcode definitions and support' patch go in but leave that for you to pull in directly). This is really very very very late for these changes, most of them aren't bug fixes at all... True. Anton Vorontsov (4): powerpc/fsl_pci: Add MPC83xx PCI-E controller RC mode support powerpc/83xx: Add PCI-E support for all MPC83xx boards with PCI-E Would like to see this feature added into .29 powerpc/83xx: Make serial ports work on MPC8315E-RDB w/ FSL U- Boots A sort of bug fix. powerpc/83xx: Move mcu_mpc8349emitx driver out of drivers/i2c/ chips/ At Jean's request to move i2c clients out of drivers/i2c. Kumar Gala (2): powerpc/fsl-booke: Cleanup init/exception setup to be runtime powerpc/e500mc: Doorbells need to be taken w/exceptions disabled can wait for .30 Trent Piepho (3): powerpc/fsl-booke: Remove code duplication in lowmem mapping powerpc/fsl-booke: Allow larger CAM sizes than 256 MB powerpc/fsl-booke: Make CAM entries used for lowmem configurable Posted we'll before.. finally got around to reviewing them.. but can wait for .30 So the real question I have is when does your next branch start queuing up changes for .30? I can completely live w/these not going into .29 if they can go into your next branch for .30 - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] hvc_console: do not set low_latency
> So the simplest is to never set it.
I already applied your previous patch. Please send an incremental fix.
Cheers,
Ben.
> milton
>
> > BUG: sleeping function called from invalid context at
> > /root/cvs/linux-2.6.git/kernel/mutex.c:207
> > in_atomic(): 1, irqs_disabled(): 0, pid: 748, name: khvcd
> > 1 lock held by khvcd/748:
> > #0: (hvc_structs_lock){--..}, at: [<002ceb50>]
> > khvcd+0x58/0x12c
> > CPU: 0 Not tainted 2.6.29-rc1git #29
> > Process khvcd (pid: 748, task: 2fb9a480, ksp: 2f66bd78)
> > 070a 2f66ba00 0002 (null)
> >2f66baa0 2f66ba18 2f66ba18
> > 00104f08
> >c000 2f66bd78 (null) (null)
> >2f66ba00 000c 2f66ba00
> > 2f66ba70
> >00466af8 00104f08 2f66ba00
> > 2f66ba50
> > Call Trace:
> > ([<00104e7c>] show_trace+0x138/0x158)
> > [<00104f62>] show_stack+0xc6/0xf8
> > [<00105740>] dump_stack+0xb0/0xc0
> > [<0013144a>] __might_sleep+0x14e/0x17c
> > [<0045e226>] mutex_lock_nested+0x42/0x3b4
> > [<002c443e>] echo_char_raw+0x3a/0x9c
> > [<002c688c>] n_tty_receive_buf+0x1154/0x1208
> > [<002ca0a2>] flush_to_ldisc+0x152/0x220
> > [<002ca1da>] tty_flip_buffer_push+0x6a/0x90
> > [<002cea74>] hvc_poll+0x244/0x2c8
> > [<002ceb68>] khvcd+0x70/0x12c
> > [<0015bbd0>] kthread+0x68/0xa0
> > [<00109d5a>] kernel_thread_starter+0x6/0xc
> > [<00109d54>] kernel_thread_starter+0x0/0xc
> > 1 lock held by khvcd/748:
> > #0: (hvc_structs_lock){--..}, at: [<002ceb50>]
> > khvcd+0x58/0x12c
> >
> >> This wont work, since the call to notifier_add is done later:
> >> What about:
> >> ---
> >> drivers/char/hvc_console.c |5 +++--
> >> 1 file changed, 3 insertions(+), 2 deletions(-)
> >>
> >> Index: linux-2.6/drivers/char/hvc_console.c
> >> ===
> >> --- linux-2.6.orig/drivers/char/hvc_console.c
> >> +++ linux-2.6/drivers/char/hvc_console.c
> >> @@ -318,8 +318,6 @@ static int hvc_open(struct tty_struct *t
> >>} /* else count == 0 */
> >>
> >>tty->driver_data = hp;
> >> - tty->low_latency = 1; /* Makes flushes to ldisc synchronous. */
> >> -
> >>hp->tty = tty;
> >>
> >>spin_unlock_irqrestore(&hp->lock, flags);
> >> @@ -327,6 +325,9 @@ static int hvc_open(struct tty_struct *t
> >>if (hp->ops->notifier_add)
> >>rc = hp->ops->notifier_add(hp, hp->data);
> >>
> >> + if (!hp->irq_requested)
> >> + tty->low_latency = 1; /* Makes flushes to ldisc synchronous. */
> >> +
> >>/*
> >> * If the notifier fails we return an error. The tty layer
> >> * will call hvc_close() after a failed open but we don't want to
> >> clean
> >
> > Acked-by: Hendrik Brueckner
> >
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from 'next' branch (2.6.29)
On Tue, 2009-01-13 at 09:21 -0600, Kumar Gala wrote: > Please pull from 'next' branch of > > (this is my last pull request of 'next' for 2.6.29. I would like to see > the 'powerpc: Unify opcode definitions and support' patch go in but leave > that for you to pull in directly). This is really very very very late for these changes, most of them aren't bug fixes at all... > master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next > > to receive the following updates: > > arch/powerpc/Kconfig | 18 + > arch/powerpc/boot/dts/mpc8315erdb.dts | 68 ++ > arch/powerpc/boot/dts/mpc8377_mds.dts | 64 ++ > arch/powerpc/boot/dts/mpc8377_rdb.dts | 64 ++ > arch/powerpc/boot/dts/mpc8378_mds.dts | 64 ++ > arch/powerpc/boot/dts/mpc8378_rdb.dts | 64 ++ > arch/powerpc/include/asm/reg_booke.h |1 > arch/powerpc/kernel/Makefile |1 > arch/powerpc/kernel/cpu_setup_fsl_booke.S | 31 +++ > arch/powerpc/kernel/cputable.c |8 > arch/powerpc/kernel/head_booke.h |6 > arch/powerpc/kernel/head_fsl_booke.S | 85 +--- > arch/powerpc/mm/fsl_booke_mmu.c| 93 - > arch/powerpc/platforms/83xx/Makefile |1 > arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 209 + > arch/powerpc/platforms/83xx/mpc831x_rdb.c |2 > arch/powerpc/platforms/83xx/mpc837x_mds.c | 10 - > arch/powerpc/platforms/83xx/mpc837x_rdb.c |2 > arch/powerpc/platforms/Kconfig | 11 + > arch/powerpc/sysdev/fsl_pci.c | 244 > ++--- > drivers/i2c/chips/Kconfig | 11 - > drivers/i2c/chips/Makefile |1 > drivers/i2c/chips/mcu_mpc8349emitx.c | 209 - > include/linux/pci_ids.h|8 > 24 files changed, 941 insertions(+), 334 deletions(-) > > Anton Vorontsov (4): > powerpc/fsl_pci: Add MPC83xx PCI-E controller RC mode support > powerpc/83xx: Add PCI-E support for all MPC83xx boards with PCI-E > powerpc/83xx: Make serial ports work on MPC8315E-RDB w/ FSL U-Boots > powerpc/83xx: Move mcu_mpc8349emitx driver out of drivers/i2c/chips/ > > Kumar Gala (2): > powerpc/fsl-booke: Cleanup init/exception setup to be runtime > powerpc/e500mc: Doorbells need to be taken w/exceptions disabled > > Trent Piepho (3): > powerpc/fsl-booke: Remove code duplication in lowmem mapping > powerpc/fsl-booke: Allow larger CAM sizes than 256 MB > powerpc/fsl-booke: Make CAM entries used for lowmem configurable ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Enable PS3 options and QPACE in ppc64_defconfig
Michael Ellerman wrote: > To increase the amount of code that's built for a defconfig build. > > Signed-off-by: Michael Ellerman > --- > arch/powerpc/configs/ppc64_defconfig | 26 +- > 1 files changed, 25 insertions(+), 1 deletions(-) > -# CONFIG_PPC_PS3 is not set > +CONFIG_PPC_PS3=y I tested this ppc64_defconfig, and it could boot on PS3. Acked-by: Geoff Levand ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH RFC v5] net: add PCINet driver
On Tuesday 13 January 2009, Ira Snyder wrote: > So do you program one channel of the DMA engine from the host side and > another channel from the guest side? Yes. > I tried to avoid having the host program the DMA controller at all. > Using the DMAEngine API on the guest did better than I could achieve by > programming the registers manually. I didn't use chaining or any of the > fancier features in my tests, though. Our driver unfortunately does not use the DMA API, but it clearly should. What this means in your case is that you would need to port the freescale DMA engine driver to the host side, to operate on the PCI device. Not sure about how specifically this would work on fsl hardware, but it seems generally doable. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/6] USB: Fixes for fsl_qe_udc driver
Just resending some fixes that seem to be lost... Greg, What happened w/this patch set? As it was sent during the hollidays (on Christmas day at that), it's still in my "to-review" queue. I'll get to it in a few days after I resync the USB tree with Linus. Any update on the review of these 6 patches? It's in my queue, been busy with "real work" for a bit right now, sorry... thanks, greg k-h np. Just going through my patchworks queue and hadn't seen these show up in any tree. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/6] USB: Fixes for fsl_qe_udc driver
On Tue, Jan 13, 2009 at 09:49:39AM -0600, Kumar Gala wrote: > > On Jan 6, 2009, at 10:53 PM, Greg KH wrote: > >> On Tue, Jan 06, 2009 at 10:44:13PM -0600, Kumar Gala wrote: >>> >>> On Dec 25, 2008, at 8:14 AM, Anton Vorontsov wrote: >>> Hi all, Just resending some fixes that seem to be lost... >>> >>> Greg, >>> >>> What happened w/this patch set? >> >> As it was sent during the hollidays (on Christmas day at that), it's >> still in my "to-review" queue. I'll get to it in a few days after I >> resync the USB tree with Linus. > > Any update on the review of these 6 patches? It's in my queue, been busy with "real work" for a bit right now, sorry... thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH RFC v5] net: add PCINet driver
On Tue, Jan 13, 2009 at 05:33:03PM +0100, Arnd Bergmann wrote: > On Tuesday 13 January 2009, Ira Snyder wrote: > > On Tue, Jan 13, 2009 at 01:02:52PM +1030, Rusty Russell wrote: > > > > > >Interesting system: the guest being able to access the > > >host's memory but not (fully) vice-versa makes this a > > >little different from the current implementations where > > >that was assumed. virtio assumes that the guest will > > >publish buffers and someone else (ie. the host) will access them. > > > > The guest system /could/ publish all of its RAM, but with 256MB per > > board, 19 boards per cPCI crate, that's way too much for a 32-bit PC to > > map into it's memory space. That's the real reason I use the 1MB > > windows. I could make them bigger (16MB would be fine, I think), but I > > doubt it would make much of a difference to the implementation. > > The way we do it in the existing driver for cell, both sides export > just a little part of their memory to the other side, and they > also both get access to one channel of the DMA engine, which is > enough to transfer larger data sections, as the DMA engine has > access to all the memory on both sides. So do you program one channel of the DMA engine from the host side and another channel from the guest side? I tried to avoid having the host program the DMA controller at all. Using the DMAEngine API on the guest did better than I could achieve by programming the registers manually. I didn't use chaining or any of the fancier features in my tests, though. Ira ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH RFC v5] net: add PCINet driver
On Tuesday 13 January 2009, Ira Snyder wrote: > On Tue, Jan 13, 2009 at 01:02:52PM +1030, Rusty Russell wrote: > > > >Interesting system: the guest being able to access the > >host's memory but not (fully) vice-versa makes this a > >little different from the current implementations where > >that was assumed. virtio assumes that the guest will > >publish buffers and someone else (ie. the host) will access them. > > The guest system /could/ publish all of its RAM, but with 256MB per > board, 19 boards per cPCI crate, that's way too much for a 32-bit PC to > map into it's memory space. That's the real reason I use the 1MB > windows. I could make them bigger (16MB would be fine, I think), but I > doubt it would make much of a difference to the implementation. The way we do it in the existing driver for cell, both sides export just a little part of their memory to the other side, and they also both get access to one channel of the DMA engine, which is enough to transfer larger data sections, as the DMA engine has access to all the memory on both sides. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: origin tree build failure
Hi Ingo, On Mon, 12 Jan 2009 10:32:14 +0100 Ingo Molnar wrote: > > * Stephen Rothwell wrote: > > > > It slipped through because it didnt get caught in build tests because > > > cpufreq isnt enabled in the powerpc defconfig. > > > > Which is one of the reasons we have linux-next: "integration testing". > > Build bugs slipped through that net too in the past. Of course they have. > And we dont really want developers and maintainers to rely on an external > middle man facility to be able to submit patches. So the best method is to > make the defconfigs good enough to catch everyday build bugs. Random > testing and linux-next can then catch the weird special cases as well. linux-next is merely a tool - it can't catch anything if you don't use it. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgp96aB4G9ond.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Unsubscribe me
Please unsubscribe me from this group ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/fs_enet: Add missing irq free in error path.
On Oct 27, 2008, at 4:46 PM, Mike Ditto wrote:
If something goes wrong attaching to phy driver, we weren't freeing
the IRQ.
Signed-off-by: Mike Ditto
---
Reposting to CC netdev list. (Thanks, Kumar)
diff -r -upN 2.6.28-rc1/drivers/net/fs_enet/fs_enet-main.c NEW/
drivers/net/fs_enet/fs_enet-main.c
--- 2.6.28-rc1/drivers/net/fs_enet/fs_enet-main.c 2008-10-24
17:54:31.0 -0700
+++ NEW/drivers/net/fs_enet/fs_enet-main.c 2008-10-24
17:57:03.0 -0700
@@ -795,6 +795,7 @@ static int fs_enet_open(struct net_devic
err = fs_init_phy(dev);
if (err) {
+ free_irq(fep->interrupt, dev);
if (fep->fpi->use_napi)
napi_disable(&fep->napi);
return err;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Dave,
This seems to have gotten lost in the shuffle. Can you please apply.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re[2]: mal_probe crash
On Tue, 13 Jan 2009, Yuri Tikhonov wrote: > On Tuesday, January 13, 2009 you wrote: > > On Mon, 2009-01-12 at 14:37 +0100, Geert Uytterhoeven wrote: > >> On Fri, 9 Jan 2009, Roland Dreier wrote: > >> > > Can you double check that the e1000 isn't copying the PCI resources > >> > into > >> > > a unsigned long before ioremap'ing the result, thus cropping the top > >> > > bits ? > >> > > >> > as far as I can see, e1000 is using pci_ioremap_bar(), which should do > >> > the right thing as long as resource_size_t is the right type (which it > >> > looks like it is on PowerPC 44x). > >> > >> Indeed, the full 36-bit address is passed to __ioremap() via > >> pci_ioremap_bar(), > >> as evidenced from the additional debug output below (see [1]). > >> > >> As I don't have any other 3.3V PCI Ethernet cards, I plugged in a 3.3V PCI > >> USB > >> 2.0 card in the second PCI slot, and got a similar crash (see [2]). > >> > >> Are the PCI slots on the Sequoia known broken under recent Linux kernels? > >> I've > >> never used them before... > > > Hrm, something is indeed wrong, hard to say what tho. My canyonlands > > works fine (460EPx) and I can try a Taishan one of these days (440GX > > iirc). What is in sequoia ? I think it's a GX no ? > > Sequoia is equipped with 440EPx. > > I observe the 'mal_probe' crash on the Katmai board too (based on > 440SPe): Do PCI cards in the Katmai's PCI-X slot work? With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft 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.uytterhoe...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] phylib: Fix Freescale TBI PHY detection
Freescale on-chip TBI PHYs reports PHY ID as 0x0, but as of
commit 3ee82383f0098a2e13acc8cf1be8e47512f41e5a
Author: Giulio Benetti
Date: Thu Nov 13 21:53:13 2008 +
phy: fix phy address bug
PHYID returns 0x and not 0x when not found and in some
case(at91sam9263) 0x0. Maybe this patch could be useful.
phy_device.c treats PHY ID == 0x0 as bogus IDs, and that results in
gianfar driver failure to see the TBI PHYs. This code snippet triggers:
if (!priv->tbiphy) {
printk(KERN_WARNING "SGMII mode requires that the device "
"tree specify a tbi-handle\n");
return;
}
Although tbi-handle is specified in the device tree.
Btw, technically PHY ID == 0x0 is a valid ID (if we ever see a PHY
manufactured by Xerox :-).
Signed-off-by: Anton Vorontsov
---
There is one thing I don't actually understand though...
Andy, were you testing the TBI support on a hardware where PHY ID
!= 0x0 or maybe your TBI PHY support patch (commit b31a1d8b41513b,
dated Tue Dec 16 15:29:15 2008) was based on a bit outdated kernel
version? Because according to the git timestamps, the TBI support
was not working since the submission.
Just in case, the hardware I'm seeing the PHY ID == 0x0 is
MPC8378E-MDS.
Thanks,
drivers/net/phy/phy_device.c |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index e354601..0a06e4f 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -231,15 +231,6 @@ struct phy_device * get_phy_device(struct mii_bus *bus,
int addr)
if ((phy_id & 0x1fff) == 0x1fff)
return NULL;
- /*
-* Broken hardware is sometimes missing the pull-up resistor on the
-* MDIO line, which results in reads to non-existent devices returning
-* 0 rather than 0x. Catch this here and treat 0 as a non-existent
-* device as well.
-*/
- if (phy_id == 0)
- return NULL;
-
dev = phy_device_create(bus, addr, phy_id);
return dev;
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] hvc_console: do not set low_latency
On Jan 13, 2009, at 5:35 AM, Hendrik Brueckner wrote:
Here is yet another bug trace related to the low_latency issue, that is
experienced using the hvc_iucv backend. The hvc_iucv backend now also
uses irq
notifiers.
The bug trace below appears if hvc_kick() is called.
On Tue, Jan 13, 2009 at 10:04:22AM +0100, Christian Borntraeger wrote:
Am Donnerstag 08 Januar 2009 schrieb Milton Miller:
hvc_console is setting low_latency unconditionally, but some clients
are
interrupt driven and will call hvc_poll from irq context. This will
cause
tty_flip_buffer_push to be called from irq context, and it very
clearly
states it must not be called from IRQ when low_latency is specified.
It seems that if low_latency is set, tty_flip_buffer_push() should
also not be
called within an atomic context, because echo_char_raw() and other
echo* calls
might sleep.
Christian's patch solves this problem for irq driven backends.
However, there might be still a problem with polled backends since the
khvcd()
thread calls hvc_poll() while hvc_structs_lock is held.
I think the hvc_udbg backend is based on polling.
David, could you check if you experience any problems with your
hvc_udbg
backend on latest git.
So the simplest is to never set it.
milton
BUG: sleeping function called from invalid context at
/root/cvs/linux-2.6.git/kernel/mutex.c:207
in_atomic(): 1, irqs_disabled(): 0, pid: 748, name: khvcd
1 lock held by khvcd/748:
#0: (hvc_structs_lock){--..}, at: [<002ceb50>]
khvcd+0x58/0x12c
CPU: 0 Not tainted 2.6.29-rc1git #29
Process khvcd (pid: 748, task: 2fb9a480, ksp: 2f66bd78)
070a 2f66ba00 0002 (null)
2f66baa0 2f66ba18 2f66ba18
00104f08
c000 2f66bd78 (null) (null)
2f66ba00 000c 2f66ba00
2f66ba70
00466af8 00104f08 2f66ba00
2f66ba50
Call Trace:
([<00104e7c>] show_trace+0x138/0x158)
[<00104f62>] show_stack+0xc6/0xf8
[<00105740>] dump_stack+0xb0/0xc0
[<0013144a>] __might_sleep+0x14e/0x17c
[<0045e226>] mutex_lock_nested+0x42/0x3b4
[<002c443e>] echo_char_raw+0x3a/0x9c
[<002c688c>] n_tty_receive_buf+0x1154/0x1208
[<002ca0a2>] flush_to_ldisc+0x152/0x220
[<002ca1da>] tty_flip_buffer_push+0x6a/0x90
[<002cea74>] hvc_poll+0x244/0x2c8
[<002ceb68>] khvcd+0x70/0x12c
[<0015bbd0>] kthread+0x68/0xa0
[<00109d5a>] kernel_thread_starter+0x6/0xc
[<00109d54>] kernel_thread_starter+0x0/0xc
1 lock held by khvcd/748:
#0: (hvc_structs_lock){--..}, at: [<002ceb50>]
khvcd+0x58/0x12c
This wont work, since the call to notifier_add is done later:
What about:
---
drivers/char/hvc_console.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: linux-2.6/drivers/char/hvc_console.c
===
--- linux-2.6.orig/drivers/char/hvc_console.c
+++ linux-2.6/drivers/char/hvc_console.c
@@ -318,8 +318,6 @@ static int hvc_open(struct tty_struct *t
} /* else count == 0 */
tty->driver_data = hp;
- tty->low_latency = 1; /* Makes flushes to ldisc synchronous. */
-
hp->tty = tty;
spin_unlock_irqrestore(&hp->lock, flags);
@@ -327,6 +325,9 @@ static int hvc_open(struct tty_struct *t
if (hp->ops->notifier_add)
rc = hp->ops->notifier_add(hp, hp->data);
+ if (!hp->irq_requested)
+ tty->low_latency = 1; /* Makes flushes to ldisc synchronous. */
+
/*
* If the notifier fails we return an error. The tty layer
* will call hvc_close() after a failed open but we don't want to
clean
Acked-by: Hendrik Brueckner
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/6] USB: Fixes for fsl_qe_udc driver
On Jan 6, 2009, at 10:53 PM, Greg KH wrote: On Tue, Jan 06, 2009 at 10:44:13PM -0600, Kumar Gala wrote: On Dec 25, 2008, at 8:14 AM, Anton Vorontsov wrote: Hi all, Just resending some fixes that seem to be lost... Greg, What happened w/this patch set? As it was sent during the hollidays (on Christmas day at that), it's still in my "to-review" queue. I'll get to it in a few days after I resync the USB tree with Linus. Any update on the review of these 6 patches? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5 + 2] kexec updates
On Jan 12, 2009, at 12:24 AM, Simon Horman wrote: On Fri, Jan 02, 2009 at 02:42:38PM -0600, Milton Miller wrote: Follwing this mail are 5 patches for kexec userspace and two for the kernel. The first fixes an array overflow and the second updates userspace to the merged 2.6.28 kdump support. The remaining are cleanups and warning fixes, including one for the common code. The two patchs for the kernel are independent. Hi all, sorry to be a bit slow in responding, this email landed just as I was leaving for a weeks holiday. No problem, I figured as much. The kexec-tools patches seem reasonable to me and I'm happy to merge what I think are the latest versions - thanks Michael for your review. Milton, here are the Subjects, Dates and Message-Ids of what I have in my queue. If you could confirm this or repost that would be great. #1 Subject: [PATCH kexec-tools v2] ppc64: always check number of ranges when adding them Date: Thu, 08 Jan 2009 06:33:50 -0600 Message-ID: <1231418030_141...@mercury.realtime.net> #2 Subject: [PATCH kexec-tools 2/5] ppc64: update kdump for 2.6.28 relocatable kernel Date: Fri, 02 Jan 2009 15:04:42 -0600 Message-Id: #3 Subject: [PATCH kexec-tools 3/5] ppc64: segments may be reordered Date: Fri, 02 Jan 2009 15:04:45 -0600 Message-Id: #4 Subject: [PATCH kexec-tools 4/5] ppc64: cleanups Date: Fri, 02 Jan 2009 15:04:48 -0600 Message-Id: #5 Subject: [PATCH kexec-tools 5/5] entry wants to be void * Date: Fri, 02 Jan 2009 15:04:51 -0600 Message-Id: Based on the subjects, yes, those are the lastest versions. And I assume you saw Mohan's tested message. Thanks, milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/5] powerpc: booke: Allow larger CAM sizes than 256 MB
On Dec 8, 2008, at 9:34 PM, Trent Piepho wrote: The code that maps kernel low memory would only use page sizes up to 256 MB. On E500v2 pages up to 4 GB are supported. However, a page must be aligned to a multiple of the page's size. I.e. 256 MB pages must aligned to a 256 MB boundary. This was enforced by a requirement that the physical and virtual addresses of the start of lowmem be aligned to 256 MB. Clearly requiring 1GB or 4GB alignment to allow pages of that size isn't acceptable. To solve this, I simply have adjust_total_lowmem() take alignment into account when it decides what size pages to use. Give it PAGE_OFFSET = 0x7000_, PHYSICAL_START = 0x3000_, and 2GB of RAM, and it will map pages like this: PA 0x3000_ VA 0x7000_ Size 256 MB PA 0x4000_ VA 0x8000_ Size 1 GB PA 0x8000_ VA 0xC000_ Size 256 MB PA 0x9000_ VA 0xD000_ Size 256 MB PA 0xA000_ VA 0xE000_ Size 256 MB Because the lowmem mapping code now takes alignment into account, PHYSICAL_ALIGN can be lowered from 256 MB to 64 MB. Even lower might be possible. The lowmem code will work down to 4 kB but it's possible some of the boot code will fail before then. Poor alignment will force small pages to be used, which combined with the limited number of TLB1 pages available, will result in very little memory getting mapped. So alignments less than 64 MB probably aren't very useful anyway. Signed-off-by: Trent Piepho --- arch/powerpc/Kconfig|2 +- arch/powerpc/mm/fsl_booke_mmu.c | 14 +- 2 files changed, 14 insertions(+), 2 deletions(-) applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] powerpc: booke: Make CAM entries used for lowmem configurable
On Dec 8, 2008, at 9:34 PM, Trent Piepho wrote: On booke processors, the code that maps low memory only uses up to three CAM entries, even though there are sixteen and nothing else uses them. Make this number configurable in the advanced options menu along with max low memory size. If one wants 1 GB of lowmem, then it's typically necessary to have four CAM entries. Signed-off-by: Trent Piepho --- arch/powerpc/Kconfig| 16 arch/powerpc/mm/fsl_booke_mmu.c |6 +- 2 files changed, 21 insertions(+), 1 deletions(-) applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/5] powerpc: booke: Remove code duplication in lowmem mapping
On Dec 8, 2008, at 9:34 PM, Trent Piepho wrote: The code to map lowmem uses three CAM aka TLB[1] entries to cover it. The size of each is stored in three globals named __cam0, __cam1, and __cam2. All the code that uses them is duplicated three times for each of the three variables. We have these things called arrays and loops Once converted to use an array, it will be easier to make the number of CAMs configurable. Signed-off-by: Trent Piepho --- arch/powerpc/mm/fsl_booke_mmu.c | 79 ++ +--- 1 files changed, 31 insertions(+), 48 deletions(-) applied. Still not happy about the buf[] for output, but its minor. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'next' branch (2.6.29)
Please pull from 'next' branch of (this is my last pull request of 'next' for 2.6.29. I would like to see the 'powerpc: Unify opcode definitions and support' patch go in but leave that for you to pull in directly). master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next to receive the following updates: arch/powerpc/Kconfig | 18 + arch/powerpc/boot/dts/mpc8315erdb.dts | 68 ++ arch/powerpc/boot/dts/mpc8377_mds.dts | 64 ++ arch/powerpc/boot/dts/mpc8377_rdb.dts | 64 ++ arch/powerpc/boot/dts/mpc8378_mds.dts | 64 ++ arch/powerpc/boot/dts/mpc8378_rdb.dts | 64 ++ arch/powerpc/include/asm/reg_booke.h |1 arch/powerpc/kernel/Makefile |1 arch/powerpc/kernel/cpu_setup_fsl_booke.S | 31 +++ arch/powerpc/kernel/cputable.c |8 arch/powerpc/kernel/head_booke.h |6 arch/powerpc/kernel/head_fsl_booke.S | 85 +--- arch/powerpc/mm/fsl_booke_mmu.c| 93 - arch/powerpc/platforms/83xx/Makefile |1 arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 209 + arch/powerpc/platforms/83xx/mpc831x_rdb.c |2 arch/powerpc/platforms/83xx/mpc837x_mds.c | 10 - arch/powerpc/platforms/83xx/mpc837x_rdb.c |2 arch/powerpc/platforms/Kconfig | 11 + arch/powerpc/sysdev/fsl_pci.c | 244 ++--- drivers/i2c/chips/Kconfig | 11 - drivers/i2c/chips/Makefile |1 drivers/i2c/chips/mcu_mpc8349emitx.c | 209 - include/linux/pci_ids.h|8 24 files changed, 941 insertions(+), 334 deletions(-) Anton Vorontsov (4): powerpc/fsl_pci: Add MPC83xx PCI-E controller RC mode support powerpc/83xx: Add PCI-E support for all MPC83xx boards with PCI-E powerpc/83xx: Make serial ports work on MPC8315E-RDB w/ FSL U-Boots powerpc/83xx: Move mcu_mpc8349emitx driver out of drivers/i2c/chips/ Kumar Gala (2): powerpc/fsl-booke: Cleanup init/exception setup to be runtime powerpc/e500mc: Doorbells need to be taken w/exceptions disabled Trent Piepho (3): powerpc/fsl-booke: Remove code duplication in lowmem mapping powerpc/fsl-booke: Allow larger CAM sizes than 256 MB powerpc/fsl-booke: Make CAM entries used for lowmem configurable ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/83xx: Move mcu_mpc8349emitx driver out of drivers/i2c/chips/
On Tue, 13 Jan 2009 08:39:37 -0600, Kumar Gala wrote: > > On Jan 11, 2009, at 10:55 AM, Anton Vorontsov wrote: > > > This patch is used to help Jean Delvare to get rid of drivers/i2c/ > > chips/ > > directory. The new location suggested by Kumar Gala: as the driver is > > 83xx specific it's placed into arch/powerpc/platforms/83xx/. > > > > Signed-off-by: Anton Vorontsov > > --- > > > > The same patch but suitable for patch(1). > > > > arch/powerpc/platforms/83xx/Makefile |1 + > > arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 209 +++ > > + > > arch/powerpc/platforms/Kconfig | 11 ++ > > drivers/i2c/chips/Kconfig | 11 -- > > drivers/i2c/chips/Makefile |1 - > > drivers/i2c/chips/mcu_mpc8349emitx.c | 209 > > > > 6 files changed, 221 insertions(+), 221 deletions(-) > > create mode 100644 arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c > > delete mode 100644 drivers/i2c/chips/mcu_mpc8349emitx.c > > applied Great, thanks Anton and Kumar! -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/83xx: Move mcu_mpc8349emitx driver out of drivers/i2c/chips/
On Jan 11, 2009, at 10:55 AM, Anton Vorontsov wrote: This patch is used to help Jean Delvare to get rid of drivers/i2c/ chips/ directory. The new location suggested by Kumar Gala: as the driver is 83xx specific it's placed into arch/powerpc/platforms/83xx/. Signed-off-by: Anton Vorontsov --- The same patch but suitable for patch(1). arch/powerpc/platforms/83xx/Makefile |1 + arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 209 +++ + arch/powerpc/platforms/Kconfig | 11 ++ drivers/i2c/chips/Kconfig | 11 -- drivers/i2c/chips/Makefile |1 - drivers/i2c/chips/mcu_mpc8349emitx.c | 209 6 files changed, 221 insertions(+), 221 deletions(-) create mode 100644 arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c delete mode 100644 drivers/i2c/chips/mcu_mpc8349emitx.c applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] powerpc: Generic device tree for all AmigaOne boards
Original-Nachricht > Datum: Tue, 13 Jan 2009 16:01:42 +1100 > Von: Benjamin Herrenschmidt > An: Gerhard Pircher > CC: linuxppc-dev@ozlabs.org, grant.lik...@secretlab.ca > Betreff: Re: [PATCH 2/5] powerpc: Generic device tree for all AmigaOne boards > > I think I throw away the IDE controller node for now, as libata just > > reads the PCI register settings (progif) and I guess the IDE subsystem > > will do the same in the future. > > Well... if all AmigaOne use a 8259, they probably use the same interrupt > routing except for PCI slots. In which case, I would -still- prefer if > you had a proper interrupt tree, and at runtime or boot-wrapper time, > fixed up the PCI host "interrupt-map" property to contain the right > values for a given board. That would be the ideal solution. But there is no reliable way to identify, if the board is an AmigaOneSE, AmigaOneXE or an uA1. AFAIK the firmware checks for a specifc onboard PCI sound chip to differentiate between an A1XE and the uA1, but this sound chip is also used on various PCI sound cards. I don't really like that approach. > I'm not going to include the new platform in .29, it's way too late > anyway (it should have been published a couple of weeks before the merge > window at least I'd say) so we have some time til .30 to polish things a > bit. Okay. Some months more don't matter after all these years. :-) > Another area to look at is to cleanup the non-coherent DMA thingy. The > config option should just enable a set of non-coherent backend ops, but > we should still be able to decide which ones to use (coherent vs. > non-coherent) at runtime. What about drivers that need to handle non coherent DMA differently (e.g. because they map DMA memory to userspace)? Will the "#ifdef CONFIG_NOT_COHERENT_CACHE" be replaced with calls to dma_is_consistent()? (for example in the radeon driver, that you fixed for non coherent DMA platforms in 2.6.25). If I may express a wish: a reworked CPU feature fixup code for PPC32 will avoid bigger problems with the AmigaOne platform in the future. Thanks a lot! Gerhard -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne boards
Original-Nachricht > Datum: Tue, 13 Jan 2009 16:02:38 +1100 > Von: Benjamin Herrenschmidt > An: Gerhard Pircher > CC: Bartlomiej Zolnierkiewicz , > grant.lik...@secretlab.ca, linuxppc-dev@ozlabs.org, linux-...@vger.kernel.org > Betreff: Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne > boards > > Yes, it can wait. > > Although I would like to know from the powerpc maintainer, if my > > platform patches could still go in 2.6.29, if I resend them in the next > > days? I > > guess it's too late, right? > > Yes it is. I'll put them in -next after -rc2 or later, when we are happy > with them. That gives us a bit of time to do extra polishing. Good, then I'll send out a new patch for the IDE driver and the current one can be reverted. Gerhard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] hvc_console: do not set low_latency
Here is yet another bug trace related to the low_latency issue, that is
experienced using the hvc_iucv backend. The hvc_iucv backend now also uses irq
notifiers.
The bug trace below appears if hvc_kick() is called.
On Tue, Jan 13, 2009 at 10:04:22AM +0100, Christian Borntraeger wrote:
> Am Donnerstag 08 Januar 2009 schrieb Milton Miller:
> > hvc_console is setting low_latency unconditionally, but some clients are
> > interrupt driven and will call hvc_poll from irq context. This will cause
> > tty_flip_buffer_push to be called from irq context, and it very clearly
> > states it must not be called from IRQ when low_latency is specified.
It seems that if low_latency is set, tty_flip_buffer_push() should also not be
called within an atomic context, because echo_char_raw() and other echo* calls
might sleep.
Christian's patch solves this problem for irq driven backends.
However, there might be still a problem with polled backends since the khvcd()
thread calls hvc_poll() while hvc_structs_lock is held.
I think the hvc_udbg backend is based on polling.
David, could you check if you experience any problems with your hvc_udbg
backend on latest git.
BUG: sleeping function called from invalid context at
/root/cvs/linux-2.6.git/kernel/mutex.c:207
in_atomic(): 1, irqs_disabled(): 0, pid: 748, name: khvcd
1 lock held by khvcd/748:
#0: (hvc_structs_lock){--..}, at: [<002ceb50>] khvcd+0x58/0x12c
CPU: 0 Not tainted 2.6.29-rc1git #29
Process khvcd (pid: 748, task: 2fb9a480, ksp: 2f66bd78)
070a 2f66ba00 0002 (null)
2f66baa0 2f66ba18 2f66ba18 00104f08
c000 2f66bd78 (null) (null)
2f66ba00 000c 2f66ba00 2f66ba70
00466af8 00104f08 2f66ba00 2f66ba50
Call Trace:
([<00104e7c>] show_trace+0x138/0x158)
[<00104f62>] show_stack+0xc6/0xf8
[<00105740>] dump_stack+0xb0/0xc0
[<0013144a>] __might_sleep+0x14e/0x17c
[<0045e226>] mutex_lock_nested+0x42/0x3b4
[<002c443e>] echo_char_raw+0x3a/0x9c
[<002c688c>] n_tty_receive_buf+0x1154/0x1208
[<002ca0a2>] flush_to_ldisc+0x152/0x220
[<002ca1da>] tty_flip_buffer_push+0x6a/0x90
[<002cea74>] hvc_poll+0x244/0x2c8
[<002ceb68>] khvcd+0x70/0x12c
[<0015bbd0>] kthread+0x68/0xa0
[<00109d5a>] kernel_thread_starter+0x6/0xc
[<00109d54>] kernel_thread_starter+0x0/0xc
1 lock held by khvcd/748:
#0: (hvc_structs_lock){--..}, at: [<002ceb50>] khvcd+0x58/0x12c
> This wont work, since the call to notifier_add is done later:
> What about:
> ---
> drivers/char/hvc_console.c |5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> Index: linux-2.6/drivers/char/hvc_console.c
> ===
> --- linux-2.6.orig/drivers/char/hvc_console.c
> +++ linux-2.6/drivers/char/hvc_console.c
> @@ -318,8 +318,6 @@ static int hvc_open(struct tty_struct *t
> } /* else count == 0 */
>
> tty->driver_data = hp;
> - tty->low_latency = 1; /* Makes flushes to ldisc synchronous. */
> -
> hp->tty = tty;
>
> spin_unlock_irqrestore(&hp->lock, flags);
> @@ -327,6 +325,9 @@ static int hvc_open(struct tty_struct *t
> if (hp->ops->notifier_add)
> rc = hp->ops->notifier_add(hp, hp->data);
>
> + if (!hp->irq_requested)
> + tty->low_latency = 1; /* Makes flushes to ldisc synchronous. */
> +
> /*
>* If the notifier fails we return an error. The tty layer
>* will call hvc_close() after a failed open but we don't want to clean
Acked-by: Hendrik Brueckner
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] hvc_console: do not set low_latency
Am Dienstag 13 Januar 2009 schrieb Christian Borntraeger: > drivers/char/hvc_console.c |5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > Index: linux-2.6/drivers/char/hvc_console.c > === > --- linux-2.6.orig/drivers/char/hvc_console.c > +++ linux-2.6/drivers/char/hvc_console.c > @@ -318,8 +318,6 @@ static int hvc_open(struct tty_struct *t > } /* else count == 0 */ > > tty->driver_data = hp; > - tty->low_latency = 1; /* Makes flushes to ldisc synchronous. */ > - > hp->tty = tty; > > spin_unlock_irqrestore(&hp->lock, flags); > @@ -327,6 +325,9 @@ static int hvc_open(struct tty_struct *t > if (hp->ops->notifier_add) > rc = hp->ops->notifier_add(hp, hp->data); > > + if (!hp->irq_requested) > + tty->low_latency = 1; /* Makes flushes to ldisc synchronous. */ > + > /* >* If the notifier fails we return an error. The tty layer >* will call hvc_close() after a failed open but we don't want to clean > > Just in case: Signed-off-by: Christian Borntraeger ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] hvc_console: do not set low_latency
Am Donnerstag 08 Januar 2009 schrieb Milton Miller: > hvc_console is setting low_latency unconditionally, but some clients are > interrupt driven and will call hvc_poll from irq context. This will cause > tty_flip_buffer_push to be called from irq context, and it very clearly > states it must not be called from IRQ when low_latency is specified. > > Looking back through history: > v2.6.16-rc1 via 33f0f88f1c51ae5c2d593d26960c760ea154c2e2 > [PATCH] TTY layer buffering revamp > > added this new api. > > v2.6.16-rc3 via 8977d929e49021d9a6e031310aab01fa72f849c2 > [PATCH] tty buffering stall fix > > claims to fix a stall discovered with hvc_console > > v2.6.16-rc5 via fb5c594c2acc441f0d2d8f457484a0e0e9285db3 >[PATCH] Fix race condition in hvc console. > > said set this flag to avoid a stall problem, and was merged through > the powerpc arch tree. > > Without searching for email discussions, it would appear to be an > overlapping "fix", but one that did not consider all users. > > --- > This version continues to set low_latency if irqs are not flagged to > be in use, as requested by paulus. Do all hvc drivers identify the > interrupt this way? (A quick look at hvc_iucv says they lock to bh > and are not irq driven, the rest would have used the irq before that > patch). > > Having the flag set for purely polled drivers will save delaying > the work when receiving input for 1 jiffie. > > > Index: work.git/drivers/char/hvc_console.c > === > --- work.git.orig/drivers/char/hvc_console.c 2009-01-08 03:01:24.0 -0600 > +++ work.git/drivers/char/hvc_console.c 2009-01-08 03:01:51.0 > -0600 > @@ -318,7 +318,8 @@ static int hvc_open(struct tty_struct *t > } /* else count == 0 */ > > tty->driver_data = hp; > - tty->low_latency = 1; /* Makes flushes to ldisc synchronous. */ > + if (!hp->irq_requested) > + tty->low_latency = 1; /* Makes flushes to ldisc synchronous. */ > > hp->tty = tty; > > This wont work, since the call to notifier_add is done later: What about: --- drivers/char/hvc_console.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Index: linux-2.6/drivers/char/hvc_console.c === --- linux-2.6.orig/drivers/char/hvc_console.c +++ linux-2.6/drivers/char/hvc_console.c @@ -318,8 +318,6 @@ static int hvc_open(struct tty_struct *t } /* else count == 0 */ tty->driver_data = hp; - tty->low_latency = 1; /* Makes flushes to ldisc synchronous. */ - hp->tty = tty; spin_unlock_irqrestore(&hp->lock, flags); @@ -327,6 +325,9 @@ static int hvc_open(struct tty_struct *t if (hp->ops->notifier_add) rc = hp->ops->notifier_add(hp, hp->data); + if (!hp->irq_requested) + tty->low_latency = 1; /* Makes flushes to ldisc synchronous. */ + /* * If the notifier fails we return an error. The tty layer * will call hvc_close() after a failed open but we don't want to clean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: When do i need to allocate DMA buffer
1. so my question is: is there any difference between the DMA engine & the DMA controller? 2. i have read the following section in my reference manual: "The MPC8555E DMA engine is capable of transferring blocks of data from any legal address range to any other legal address range. Therefore, it can perform a DMA transfer between any of its I/O or memory ports or even between two devices or locations on the same port." does it mean that it can copy data from source to destination directly without using the DMA buffer? 3.can i use the DMA-PCI or the generic DMA APIs or DMA ISA APIs to drive the DMA Engine or i m obligitaed to use the driver of DMA engine? Sylvain Joyeau wrote: > > Hi Wael, > > 1. The DMA engine source and destination registers are based on > physical memory addresses, whatever is the bus connected on, thus you > need to provide it physical addresses. > It looks like you are a bit confused about the terminology "DMA > buffer": a DMA buffer is either the source and/or destination buffer, > but not a intermediate buffer that you could bypass. Perhaps anybody > speaking english more fluently can explain that better than me. > > 2. Know nothing about Linux DMA API, but more thant a bit about > MPC8555 DMA, and I can say it's quite easy to program, directly > (through DMA registers) if your application doesn't require > portability across platforms. > AFAIK, the better way to allocate source and/or destination RAM buffer > in the kernel side is dma_alloc_coherent(): that's one seems rather > portable ! > > Best regards. > -- > sj > > 2009/1/12 wael showair : >> >> Hi All, >> i have MPC8555 processor, also i have linux-kernel 2.6.19-rc5 on my >> board.i >> want to use the DMA on my board, just a simple example is enough for me >> but >> during my reading on how to use the DMA i have some questions: >> 1. The DMA buffer is always needed for all kind of buses or not? (I think >> this is valid in the ISA bus but not in the PCI bus, plz correct me if i >> m >> wrong?) >> Note that my target is to transfer data from memory location to another >> memory location & it will be an overhead if i copy the data from the src >> to >> the DMA buffer then from the DMA buffer to the Destination. >> isn't there any other way to avoid using that DMA buffer & to copy data >> from >> src to dest directly? >> i read the documentation of my board & it tells me that it contain DMA >> engine which "is capable of transferring blocks of data from any legal >> address range to any >> other legal address range." >> >> 2. i have read DMA-API.txt in the linux Documentation folder but i m >> little >> confused about the APIs that exist in this file. Actually, it is stated >> in >> this file the following: >> "This document describes the DMA API.This API is split into two pieces. >> Part I describes the API and the corresponding pci_ API". >> >> so if the DMA controller is connected to the PCI bus, am i obligated to >> use >> the pci_API & for any other case (like ISA bus or any other bus types) >> shall >> i use this generic API? >> also what r the benefits of these APIs over the normal kmalloc? specially >> that i have read the following section in the DMA-mapping.txt: >> "If you acquired your memory via the page allocator >> (i.e. __get_free_page*()) or the generic memory allocators >> (i.e. kmalloc() or kmem_cache_alloc()) then you may DMA to/from >> that memory using the addresses returned from those routines." >> >> thanks in advance for ur help >> -- >> View this message in context: >> http://www.nabble.com/When-do-i-need-to-allocate-DMA-buffer-tp21413193p21413193.html >> Sent from the linuxppc-dev mailing list archive at Nabble.com. >> >> ___ >> Linuxppc-dev mailing list >> Linuxppc-dev@ozlabs.org >> https://ozlabs.org/mailman/listinfo/linuxppc-dev >> > > > > -- > -- > Sylvain JOYEAU > Freelance Engineer > Software RT-OS R&D > sylvain.joy...@gmail.com > "A good idea is one side of the coin. The other side is the practical > usefulness". J. Liedke. > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > > -- View this message in context: http://www.nabble.com/When-do-i-need-to-allocate-DMA-buffer-tp21413193p21431621.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
