* Re: device trees.
From: David Gibson @ 2009-05-14 3:08 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-dev
In-Reply-To: <4A0B0D4A.6000405@dlasys.net>
On Wed, May 13, 2009 at 02:11:22PM -0400, David H. Lynch Jr. wrote:
> David Gibson wrote:
> >
> >
> > Ok. If you have NOR flash, why couldn't you just put the dtb in a
> > separate partition of the NOR?
> >
> >
> It is not THE dtb, it is A dtb. Our systems support and typically use
> multiple FPGA bit streams.
Ah, ok. And those multiple bitstreams all inhabit the same NOR flash?
>From what I read below I'm guessing not..
> Clients are
> That means each bitstream must have its own dtb, clients are
> allowed/expected to create their own firmware,
> but the norm is to leave the "PrimaryBoot.bit" startup bit file intact.
> Clients may swap between several bit files for development purposes in
> the course of a day.
> It is even possible that a clients application may require swapping bit
> files as part of normal operations.
> I want one linux binary - because I know damn well that given two my
> clients will use the wrong one alteast 30% of the time.
> Somewhere arround 4 binaries that becomes almost 100% of the time.
> Using dtb's to make the linux binary does NOT solve the problem it just
> changes the file they have to get right.
Ok. But they must be using some tool to push the bitstream into the
board yes? Could that same tool be made to take a bitstream+dtb
bundle and push each piece into the right section of flash?
> Worse still the wrong dtb will probably mostly work. If it just failed
> they would be more likely to grasp what they got wrong.
>
> I need/want the device tree welded to the bitstream. That means creating
> it dynamically or welding it to the bitstream.
> Anything else wil be a support nightmare.
Right. I guess it's all a question of what constitutes "welded" given
the tool setup that's typically used by your clients. I'm trying to
understand enough about your system to make practical suggestions of
how to achieve weldedness.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] mmc: Add fsl,esdhc as a valid compatible to bind against
From: Kumar Gala @ 2009-05-14 2:45 UTC (permalink / raw)
To: Pierre Ossman; +Cc: linuxppc-dev, pierre, linux-kernel
In-Reply-To: <1241790769-3843-1-git-send-email-galak@kernel.crashing.org>
On May 8, 2009, at 8:52 AM, Kumar Gala wrote:
> We plan to use fsl,esdhc going forward as the base compatible so
> update
> the driver to bind against it.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> drivers/mmc/host/sdhci-of.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Any feedback or possibility of picking this up.
- k
>
>
> diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
> index 3ff4ac3..09cc597 100644
> --- a/drivers/mmc/host/sdhci-of.c
> +++ b/drivers/mmc/host/sdhci-of.c
> @@ -277,6 +277,7 @@ static int __devexit sdhci_of_remove(struct
> of_device *ofdev)
> static const struct of_device_id sdhci_of_match[] = {
> { .compatible = "fsl,mpc8379-esdhc", .data = &sdhci_esdhc, },
> { .compatible = "fsl,mpc8536-esdhc", .data = &sdhci_esdhc, },
> + { .compatible = "fsl,esdhc", .data = &sdhci_esdhc, },
> { .compatible = "generic-sdhci", },
> {},
> };
> --
> 1.6.0.6
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: drivers/video/logo/logo_linux_mono.c build error
From: Andrew Morton @ 2009-05-13 22:44 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: sfr, linuxppc-dev
In-Reply-To: <alpine.LRH.2.00.0904280922410.31001@vixen.sonytel.be>
On Tue, 28 Apr 2009 09:24:53 +0200 (CEST)
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> On Tue, 28 Apr 2009, Stephen Rothwell wrote:
> > On Mon, 27 Apr 2009 14:50:31 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> > > powerpc allmodconfig, current mainline:
> > >
> > > drivers/video/logo/logo_linux_mono.c:11: error: logo_linux_mono_data causes a section type conflict
> > >
> > > switching it from __initconst to __initdata "fixes" it.
> >
> > Interesting. The program that generates the .c file above produces
> > __initdata for me ...
>
> I assume Andrew once built in that tree using the recent logo patches that
> 1. Makes the logos const and switch them from __initdata to __initconst,
> 2. Fix the missing dependency of the generated files on the generator program.
> Hence if you revert the logo patches, you have to manually remove the generated
> files.
>
> Is my assumption correct?
Nope - mrproper removes every .c file from drivers/video/logo/ apart
from logo.c
The failure is caused by your fbdev-move-logo-externs-to-header-file.patch.
Without that patch, drivers/video/logo/logo_linux_mono.c is generated as
static unsigned char logo_linux_mono_data[] __initdata = {
and with that patch, drivers/video/logo/logo_linux_mono.c is generated as
static const unsigned char logo_linux_mono_data[] __initconst = {
and it's the switch from __initdata to __initconst which causes this
section conflict in my setup.
^ permalink raw reply
* Please pull from 'next' branch
From: Kumar Gala @ 2009-05-13 22:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
This is based on v2.6.30-rc5.
- k
Please pull from 'next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next
to receive the following updates:
Documentation/powerpc/dts-bindings/ecm.txt | 64 +
Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt | 3
Documentation/powerpc/dts-bindings/fsl/mcm.txt | 64 +
arch/powerpc/boot/dts/gef_ppc9a.dts | 14
arch/powerpc/boot/dts/gef_sbc310.dts | 14
arch/powerpc/boot/dts/gef_sbc610.dts | 14
arch/powerpc/boot/dts/ksi8560.dts | 13
arch/powerpc/boot/dts/mpc832x_mds.dts | 3
arch/powerpc/boot/dts/mpc832x_rdb.dts | 3
arch/powerpc/boot/dts/mpc8349emitx.dts | 2
arch/powerpc/boot/dts/mpc8349emitxgp.dts | 1
arch/powerpc/boot/dts/mpc834x_mds.dts | 2
arch/powerpc/boot/dts/mpc836x_mds.dts | 3
arch/powerpc/boot/dts/mpc836x_rdk.dts | 2
arch/powerpc/boot/dts/mpc8377_mds.dts | 1
arch/powerpc/boot/dts/mpc8378_mds.dts | 1
arch/powerpc/boot/dts/mpc8379_mds.dts | 1
arch/powerpc/boot/dts/mpc8536ds.dts | 18
arch/powerpc/boot/dts/mpc8540ads.dts | 15
arch/powerpc/boot/dts/mpc8541cds.dts | 16
arch/powerpc/boot/dts/mpc8544ds.dts | 18
arch/powerpc/boot/dts/mpc8548cds.dts | 17
arch/powerpc/boot/dts/mpc8555cds.dts | 16
arch/powerpc/boot/dts/mpc8560ads.dts | 15
arch/powerpc/boot/dts/mpc8568mds.dts | 51 +
arch/powerpc/boot/dts/mpc8569mds.dts | 583 ++++++++++++++++++
arch/powerpc/boot/dts/mpc8572ds.dts | 17
arch/powerpc/boot/dts/mpc8572ds_36b.dts | 39 -
arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts | 16
arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts | 2
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 16
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 16
arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts | 609 +++++++++++++++++++
arch/powerpc/boot/dts/sbc8349.dts | 1
arch/powerpc/boot/dts/sbc8548.dts | 16
arch/powerpc/boot/dts/sbc8560.dts | 15
arch/powerpc/boot/dts/sbc8641d.dts | 16
arch/powerpc/boot/dts/socrates.dts | 15
arch/powerpc/boot/dts/stx_gp3_8560.dts | 15
arch/powerpc/boot/dts/tqm8540.dts | 15
arch/powerpc/boot/dts/tqm8541.dts | 15
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 16
arch/powerpc/boot/dts/tqm8548.dts | 16
arch/powerpc/boot/dts/tqm8555.dts | 15
arch/powerpc/boot/dts/tqm8560.dts | 15
arch/powerpc/include/asm/cpm1.h | 2
arch/powerpc/include/asm/cpm2.h | 4
arch/powerpc/include/asm/mpc86xx.h | 33 -
arch/powerpc/include/asm/pci-bridge.h | 6
arch/powerpc/include/asm/qe.h | 21
arch/powerpc/oprofile/op_model_fsl_emb.c | 14
arch/powerpc/platforms/82xx/pq2ads.h | 13
arch/powerpc/platforms/85xx/Kconfig | 1
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 52 +
arch/powerpc/platforms/86xx/gef_ppc9a.c | 1
arch/powerpc/platforms/86xx/gef_sbc310.c | 1
arch/powerpc/platforms/86xx/gef_sbc610.c | 1
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 1
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 1
arch/powerpc/platforms/86xx/mpc86xx_smp.c | 8
arch/powerpc/platforms/86xx/sbc8641d.c | 1
arch/powerpc/platforms/8xx/mpc885ads.h | 4
arch/powerpc/platforms/fsl_uli1575.c | 23
arch/powerpc/sysdev/cpm2.c | 2
arch/powerpc/sysdev/fsl_msi.c | 9
arch/powerpc/sysdev/fsl_pci.c | 6
arch/powerpc/sysdev/fsl_rio.c | 15
arch/powerpc/sysdev/fsl_soc.c | 14
arch/powerpc/sysdev/qe_lib/qe.c | 75 ++
drivers/dma/fsldma.c | 13
drivers/net/ucc_geth.c | 24
drivers/net/ucc_geth.h | 4
drivers/of/base.c | 1
drivers/rapidio/rio-scan.c | 6
include/linux/pci_ids.h | 2
75 files changed, 1949 insertions(+), 248 deletions(-)
Anton Vorontsov (6):
powerpc/85xx: Add PCI IDs for MPC8569 family processors
powerpc/85xx: Fix mpc8569emds crypto node to include SNOW unit
powerpc/85xx: Fix reg & interrupts for mpc8569emds localbus added NAND
powerpc/85xx: Add eSDHC support for MPC8569E-MDS boards
powerpc/85xx: Enable Serial RapidIO for MPC85xx MDS boards
powerpc/85xx: Add STMicro M25P40 serial flash support for MPC8569E-MDS
Becky Bruce (2):
powerpc/86xx: Add 36-bit device tree for mpc8641hpcn
powerpc: make dma_window_* in pci_controller struct avail on 32b
Haiying Wang (7):
powerpc/85xx: clean up for mpc8568_mds name
powerpc/qe: update risc allocation for QE
net/ucc_geth: update riscTx and riscRx in ucc_geth
powerpc/qe: update QE Serial Number
net/ucc_geth: Assign six threads to Rx for UEC
powerpc/85xx: Add MPC8569MDS board support
powerpc/qe: add new qe properties for QE based chips
Kumar Gala (15):
powerpc/fsl: Remove cell-index from PCI nodes
powerpc: Refactor board check for PCI quirks on FSL boards with uli1575
powerpc/fsl: use of_iomap() for rstcr mapping
powerpc/85xx: Add binding for LAWs and ECM
powerpc/85xx: Add new LAW & ECM device tree nodes for all 85xx systems
powerpc/86xx: Add binding for LAWs and MCM
powerpc/86xx: Add new LAW & MCM device tree nodes for all 86xx systems
powerpc/cpm: Remove some cruft code and defines
powerpc/86xx: clean up smp init code
powerpc/fsl: Removed reg property from 85xx/86xx soc node
fsldma: Fix compile warnings
powerpc/85xx: Add MSI nodes for MPC8568/9 MDS systems
powerpc/fsl: Support unique MSI addresses per PCIe Root Complex
powerpc/8xxx: Update PCI outbound window addresses for 36-bit configs
powerpc/fsl_rio: Fix compile warnings
Li Yang (2):
powerpc/fsl_rio: use LAW address from device tree
rapidio: fix section mismatch warnings
Michael Ellerman (1):
powerpc/oprofile: Remove unused dump_pmcs() in FSL oprofile
^ permalink raw reply
* Please pull from 'merge' branch for 2.6.30
From: Kumar Gala @ 2009-05-13 22:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Just added defconfig updates for the normal FSL set of HW.
- k
Please pull from 'merge' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge
to receive the following updates:
arch/powerpc/configs/83xx/asp8347_defconfig | 104 ++++-
arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 114 ++++--
arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 114 ++++--
arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 107 ++++--
arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 113 ++++--
arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 108 ++++--
arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 108 ++++--
arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 103 ++++-
arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 108 ++++--
arch/powerpc/configs/83xx/mpc836x_rdk_defconfig | 96 ++++-
arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 104 ++++-
arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 111 ++++--
arch/powerpc/configs/83xx/sbc834x_defconfig | 96 ++++-
arch/powerpc/configs/85xx/ksi8560_defconfig | 86 +++-
arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 82 +++-
arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 89 +++--
arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 88 +++--
arch/powerpc/configs/85xx/sbc8548_defconfig | 84 +++-
arch/powerpc/configs/85xx/sbc8560_defconfig | 83 +++-
arch/powerpc/configs/85xx/socrates_defconfig | 385 ++++++++++++++++------
arch/powerpc/configs/85xx/stx_gp3_defconfig | 105 ++++--
arch/powerpc/configs/85xx/tqm8540_defconfig | 100 ++++-
arch/powerpc/configs/85xx/tqm8541_defconfig | 101 ++++-
arch/powerpc/configs/85xx/tqm8548_defconfig | 64 ++-
arch/powerpc/configs/85xx/tqm8555_defconfig | 101 ++++-
arch/powerpc/configs/85xx/tqm8560_defconfig | 101 ++++-
arch/powerpc/configs/86xx/gef_ppc9a_defconfig | 92 ++++-
arch/powerpc/configs/86xx/gef_sbc310_defconfig | 92 ++++-
arch/powerpc/configs/86xx/gef_sbc610_defconfig | 122 +++++-
arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig | 100 ++++-
arch/powerpc/configs/86xx/mpc8641_hpcn_defconfig | 211 ++++--------
arch/powerpc/configs/86xx/sbc8641d_defconfig | 114 ++++--
arch/powerpc/configs/adder875_defconfig | 65 ++-
arch/powerpc/configs/c2k_defconfig | 128 +++++--
arch/powerpc/configs/ep8248e_defconfig | 74 +++-
arch/powerpc/configs/ep88xc_defconfig | 63 ++-
arch/powerpc/configs/linkstation_defconfig | 96 ++++-
arch/powerpc/configs/mgcoge_defconfig | 74 +++-
arch/powerpc/configs/mgsuvd_defconfig | 72 +++-
arch/powerpc/configs/mpc7448_hpc2_defconfig | 91 +++--
arch/powerpc/configs/mpc8272_ads_defconfig | 77 +++-
arch/powerpc/configs/mpc83xx_defconfig | 115 ++++--
arch/powerpc/configs/mpc866_ads_defconfig | 77 +++-
arch/powerpc/configs/mpc86xx_defconfig | 211 ++++--------
arch/powerpc/configs/mpc885_ads_defconfig | 63 ++-
arch/powerpc/configs/pq2fads_defconfig | 90 +++--
arch/powerpc/configs/prpmc2800_defconfig | 120 +++++-
arch/powerpc/configs/storcenter_defconfig | 71 ++--
arch/powerpc/sysdev/fsl_soc.c | 46 --
49 files changed, 3630 insertions(+), 1489 deletions(-)
Anton Vorontsov (1):
powerpc/fsl_soc: Remove mpc83xx_wdt_init, again
Kumar Gala (5):
powerpc/83xx: Update defconfigs
powerpc/85xx: Update defconfigs
powerpc/86xx: Update defconfigs
powerpc/embedded6xx: Update defconfigs
powerpc/8xx: Update defconfigs
^ permalink raw reply
* Re: [PATCH 6/6] rio: fix section mismatch
From: Kumar Gala @ 2009-05-13 22:08 UTC (permalink / raw)
To: Li Yang; +Cc: netdev, linux-kernel, davem, linuxppc-dev, akpm
In-Reply-To: <1242117363-14949-6-git-send-email-leoli@freescale.com>
On May 12, 2009, at 3:36 AM, Li Yang wrote:
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> drivers/rapidio/rio-scan.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 2/6] powerpc/fsl_rio: use LAW address from device tree
From: Kumar Gala @ 2009-05-13 22:08 UTC (permalink / raw)
To: Li Yang; +Cc: netdev, linux-kernel, davem, linuxppc-dev, akpm
In-Reply-To: <1242117363-14949-2-git-send-email-leoli@freescale.com>
On May 12, 2009, at 3:35 AM, Li Yang wrote:
> Instead of fixed address in old code.
>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_rio.c | 12 +++++++-----
> 1 files changed, 7 insertions(+), 5 deletions(-)
applied to next
- k
^ permalink raw reply
* [PATCH] powerpc/fsl_rio: Fix compile warnings
From: Kumar Gala @ 2009-05-13 22:04 UTC (permalink / raw)
To: linuxppc-dev
We we build with resource_size_t as a 64-bit quantity we get:
arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_setup':
arch/powerpc/sysdev/fsl_rio.c:1029: warning: format '%08x' expects type 'unsigned int', but argument 4 has type 'resource_size_t'
arch/powerpc/sysdev/fsl_rio.c:1029: warning: format '%08x' expects type 'unsigned int', but argument 5 has type 'resource_size_t'
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/sysdev/fsl_rio.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index abdb124..c5aa179 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -1026,8 +1026,7 @@ int fsl_rio_setup(struct of_device *dev)
return -EFAULT;
}
dev_info(&dev->dev, "Of-device full name %s\n", dev->node->full_name);
- dev_info(&dev->dev, "Regs start 0x%08x size 0x%08x\n", regs.start,
- regs.end - regs.start + 1);
+ dev_info(&dev->dev, "Regs: %pR\n", ®s);
dt_range = of_get_property(dev->node, "ranges", &rlen);
if (!dt_range) {
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH] fsldma: Fix compile warnings
From: Dan Williams @ 2009-05-13 21:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1242249957-10352-1-git-send-email-galak@kernel.crashing.org>
On Wed, May 13, 2009 at 2:25 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
> We we build with dma_addr_t as a 64-bit quantity we get:
>
> drivers/dma/fsldma.c: In function 'fsl_chan_xfer_ld_queue':
> drivers/dma/fsldma.c:625: warning: cast to pointer from integer of different size
> drivers/dma/fsldma.c: In function 'fsl_dma_chan_do_interrupt':
> drivers/dma/fsldma.c:737: warning: cast to pointer from integer of different size
> drivers/dma/fsldma.c:737: warning: cast to pointer from integer of different size
> drivers/dma/fsldma.c: In function 'of_fsl_dma_probe':
> drivers/dma/fsldma.c:927: warning: cast to pointer from integer of different
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Dan Williams <dan.j.williams@intel.com>
I'm fine with this going through your tree.
Thanks,
Dan
^ permalink raw reply
* [PATCH] fsldma: Fix compile warnings
From: Kumar Gala @ 2009-05-13 21:25 UTC (permalink / raw)
To: dan.j.williams; +Cc: linuxppc-dev, linux-kernel
We we build with dma_addr_t as a 64-bit quantity we get:
drivers/dma/fsldma.c: In function 'fsl_chan_xfer_ld_queue':
drivers/dma/fsldma.c:625: warning: cast to pointer from integer of different size
drivers/dma/fsldma.c: In function 'fsl_dma_chan_do_interrupt':
drivers/dma/fsldma.c:737: warning: cast to pointer from integer of different size
drivers/dma/fsldma.c:737: warning: cast to pointer from integer of different size
drivers/dma/fsldma.c: In function 'of_fsl_dma_probe':
drivers/dma/fsldma.c:927: warning: cast to pointer from integer of different
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
drivers/dma/fsldma.c | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index da8a8ed..66a7687 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -622,8 +622,8 @@ static void fsl_chan_xfer_ld_queue(struct fsl_dma_chan *fsl_chan)
if (ld_node != &fsl_chan->ld_queue) {
/* Get the ld start address from ld_queue */
next_dest_addr = to_fsl_desc(ld_node)->async_tx.phys;
- dev_dbg(fsl_chan->dev, "xfer LDs staring from %p\n",
- (void *)next_dest_addr);
+ dev_dbg(fsl_chan->dev, "xfer LDs staring from 0x%llx\n",
+ (unsigned long long)next_dest_addr);
set_cdar(fsl_chan, next_dest_addr);
dma_start(fsl_chan);
} else {
@@ -734,8 +734,9 @@ static irqreturn_t fsl_dma_chan_do_interrupt(int irq, void *data)
*/
if (stat & FSL_DMA_SR_EOSI) {
dev_dbg(fsl_chan->dev, "event: End-of-segments INT\n");
- dev_dbg(fsl_chan->dev, "event: clndar %p, nlndar %p\n",
- (void *)get_cdar(fsl_chan), (void *)get_ndar(fsl_chan));
+ dev_dbg(fsl_chan->dev, "event: clndar 0x%llx, nlndar 0x%llx\n",
+ (unsigned long long)get_cdar(fsl_chan),
+ (unsigned long long)get_ndar(fsl_chan));
stat &= ~FSL_DMA_SR_EOSI;
update_cookie = 1;
}
@@ -925,8 +926,8 @@ static int __devinit of_fsl_dma_probe(struct of_device *dev,
}
dev_info(&dev->dev, "Probe the Freescale DMA driver for %s "
- "controller at %p...\n",
- match->compatible, (void *)fdev->reg.start);
+ "controller at 0x%llx...\n",
+ match->compatible, (unsigned long long)fdev->reg.start);
fdev->reg_base = ioremap(fdev->reg.start, fdev->reg.end
- fdev->reg.start + 1);
--
1.6.0.6
^ permalink raw reply related
* [PATCH v2] sata_fsl: Fix compile warnings
From: Kumar Gala @ 2009-05-13 21:23 UTC (permalink / raw)
To: jeff; +Cc: linux-ide, linux-kernel, linuxppc-dev
We we build with dma_addr_t as a 64-bit quantity we get:
drivers/ata/sata_fsl.c: In function 'sata_fsl_fill_sg':
drivers/ata/sata_fsl.c:340: warning: format '%x' expects type 'unsigned int', but argument 4 has type 'dma_addr_t'
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
* had one too many 'x'
- k
drivers/ata/sata_fsl.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index c2e90e1..a9c4e0e 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -332,13 +332,14 @@ static unsigned int sata_fsl_fill_sg(struct ata_queued_cmd *qc, void *cmd_desc,
dma_addr_t sg_addr = sg_dma_address(sg);
u32 sg_len = sg_dma_len(sg);
- VPRINTK("SATA FSL : fill_sg, sg_addr = 0x%x, sg_len = %d\n",
- sg_addr, sg_len);
+ VPRINTK("SATA FSL : fill_sg, sg_addr = 0x%llx, sg_len = %d\n",
+ (unsigned long long)sg_addr, sg_len);
/* warn if each s/g element is not dword aligned */
if (sg_addr & 0x03)
ata_port_printk(qc->ap, KERN_ERR,
- "s/g addr unaligned : 0x%x\n", sg_addr);
+ "s/g addr unaligned : 0x%llx\n",
+ (unsigned long long)sg_addr);
if (sg_len & 0x03)
ata_port_printk(qc->ap, KERN_ERR,
"s/g len unaligned : 0x%x\n", sg_len);
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH] sata_fsl: Fix compile warnings
From: Becky Bruce @ 2009-05-13 21:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-ide, linux-kernel, jeff, linuxppc-dev
In-Reply-To: <1242249131-25014-1-git-send-email-galak@kernel.crashing.org>
On May 13, 2009, at 4:12 PM, Kumar Gala wrote:
> We we build with dma_addr_t as a 64-bit quantity we get:
>
> drivers/ata/sata_fsl.c: In function 'sata_fsl_fill_sg':
> drivers/ata/sata_fsl.c:340: warning: format '%x' expects type
> 'unsigned int', but argument 4 has type 'dma_addr_t'
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> drivers/ata/sata_fsl.c | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
> index c2e90e1..c7ee52d 100644
> --- a/drivers/ata/sata_fsl.c
> +++ b/drivers/ata/sata_fsl.c
> @@ -332,13 +332,14 @@ static unsigned int sata_fsl_fill_sg(struct
> ata_queued_cmd *qc, void *cmd_desc,
> dma_addr_t sg_addr = sg_dma_address(sg);
> u32 sg_len = sg_dma_len(sg);
>
> - VPRINTK("SATA FSL : fill_sg, sg_addr = 0x%x, sg_len = %d\n",
> - sg_addr, sg_len);
> + VPRINTK("SATA FSL : fill_sg, sg_addr = 0x%llx, sg_len = %d\n",
> + (unsigned long long)sg_addr, sg_len);
>
> /* warn if each s/g element is not dword aligned */
> if (sg_addr & 0x03)
> ata_port_printk(qc->ap, KERN_ERR,
> - "s/g addr unaligned : 0x%x\n", sg_addr);
> + "s/g addr unaligned : 0x%llxx\n",
You have an extra "x" in there....
Cheers,
B
^ permalink raw reply
* [PATCH] sata_fsl: Fix compile warnings
From: Kumar Gala @ 2009-05-13 21:12 UTC (permalink / raw)
To: jeff; +Cc: linux-ide, linux-kernel, linuxppc-dev
We we build with dma_addr_t as a 64-bit quantity we get:
drivers/ata/sata_fsl.c: In function 'sata_fsl_fill_sg':
drivers/ata/sata_fsl.c:340: warning: format '%x' expects type 'unsigned int', but argument 4 has type 'dma_addr_t'
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
drivers/ata/sata_fsl.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index c2e90e1..c7ee52d 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -332,13 +332,14 @@ static unsigned int sata_fsl_fill_sg(struct ata_queued_cmd *qc, void *cmd_desc,
dma_addr_t sg_addr = sg_dma_address(sg);
u32 sg_len = sg_dma_len(sg);
- VPRINTK("SATA FSL : fill_sg, sg_addr = 0x%x, sg_len = %d\n",
- sg_addr, sg_len);
+ VPRINTK("SATA FSL : fill_sg, sg_addr = 0x%llx, sg_len = %d\n",
+ (unsigned long long)sg_addr, sg_len);
/* warn if each s/g element is not dword aligned */
if (sg_addr & 0x03)
ata_port_printk(qc->ap, KERN_ERR,
- "s/g addr unaligned : 0x%x\n", sg_addr);
+ "s/g addr unaligned : 0x%llxx\n",
+ (unsigned long long)sg_addr);
if (sg_len & 0x03)
ata_port_printk(qc->ap, KERN_ERR,
"s/g len unaligned : 0x%x\n", sg_len);
--
1.6.0.6
^ permalink raw reply related
* Re: question about softirqs
From: Thomas Gleixner @ 2009-05-13 20:55 UTC (permalink / raw)
To: Andi Kleen
Cc: Peter Zijlstra, netdev, Steven Rostedt, linuxppc-dev, paulus,
Ingo Molnar, David Miller
In-Reply-To: <20090513195340.GC19296@one.firstfloor.org>
On Wed, 13 May 2009, Andi Kleen wrote:
> On Wed, May 13, 2009 at 01:44:59PM -0600, Chris Friesen wrote:
> > Andi Kleen wrote:
> > > On Wed, May 13, 2009 at 01:04:09PM -0600, Chris Friesen wrote:
> > >> Andi Kleen wrote:
> > >>
> > >>> network packets are normally processed by the network packet interrupt's
> > >>> softirq or alternatively in the NAPI poll loop.
> > >> If we have a high priority task, ksoftirqd may not get a chance to run.
> > >
> > > In this case the next interrupt will also process them. It will just
> > > go more slowly because interrupts limit the work compared to ksoftirqd.
> >
> > I realize that they will eventually get processed. My point is that the
> > documentation (in-kernel, online, and in various books) says that
> > softirqs will be processed _on the return from a syscall_.
>
> They are. The documentation is correct.
No, the documentation is wrong for the case that the task, which
raised the softirq and therefor woke up ksoftirqd, has a higher
priority than ksoftirqd. In that case the kernel does _NOT_ schedule
ksoftirqd in the return from syscall path.
And that's all what Chris is pointing out.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH] mmc: Fix the wrong accessor to HOSTVER register
From: Pierre Ossman @ 2009-05-13 19:47 UTC (permalink / raw)
To: Dave Liu, avorontsov; +Cc: linuxppc-dev, sdhci-devel, ben-linux
In-Reply-To: <1241606407-18685-1-git-send-email-daveliu@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 639 bytes --]
On Wed, 6 May 2009 18:40:07 +0800
Dave Liu <daveliu@freescale.com> wrote:
> Freescale eSDHC controller has the special order for
> the HOST version register. that is not same as the other's
> registers. The address of HOSTVER in spec is 0xFE, and
> we need use the in_be16(0xFE) to access it, not in_be16(0xFC).
>
> Signed-off-by: Dave Liu <daveliu@freescale.com>
> ---
Any objections, Anton?
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: question about softirqs
From: Andi Kleen @ 2009-05-13 19:53 UTC (permalink / raw)
To: Chris Friesen
Cc: Peter Zijlstra, netdev, Ingo Molnar, Steven Rostedt, linuxppc-dev,
Andi Kleen, paulus, Thomas Gleixner, David Miller
In-Reply-To: <4A0B233B.8010105@nortel.com>
On Wed, May 13, 2009 at 01:44:59PM -0600, Chris Friesen wrote:
> Andi Kleen wrote:
> > On Wed, May 13, 2009 at 01:04:09PM -0600, Chris Friesen wrote:
> >> Andi Kleen wrote:
> >>
> >>> network packets are normally processed by the network packet interrupt's
> >>> softirq or alternatively in the NAPI poll loop.
> >> If we have a high priority task, ksoftirqd may not get a chance to run.
> >
> > In this case the next interrupt will also process them. It will just
> > go more slowly because interrupts limit the work compared to ksoftirqd.
>
> I realize that they will eventually get processed. My point is that the
> documentation (in-kernel, online, and in various books) says that
> softirqs will be processed _on the return from a syscall_.
They are. The documentation is correct.
What might not be all processed is all packets that are in the per CPU
backlog queue when the network softirq runs (for non NAPI, for NAPI that's
obsolete anyways). That's because there are limits.
Or when new work comes in in parallel it doesn't process it all.
But that's always the case -- no queue is infinite, so you have
always situations where it can drop or delay items.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: question about softirqs
From: Chris Friesen @ 2009-05-13 19:44 UTC (permalink / raw)
To: Andi Kleen
Cc: Peter Zijlstra, netdev, Ingo Molnar, Steven Rostedt, linuxppc-dev,
paulus, Thomas Gleixner, David Miller
In-Reply-To: <20090513191354.GB19296@one.firstfloor.org>
Andi Kleen wrote:
> On Wed, May 13, 2009 at 01:04:09PM -0600, Chris Friesen wrote:
>> Andi Kleen wrote:
>>
>>> network packets are normally processed by the network packet interrupt's
>>> softirq or alternatively in the NAPI poll loop.
>> If we have a high priority task, ksoftirqd may not get a chance to run.
>
> In this case the next interrupt will also process them. It will just
> go more slowly because interrupts limit the work compared to ksoftirqd.
I realize that they will eventually get processed. My point is that the
documentation (in-kernel, online, and in various books) says that
softirqs will be processed _on the return from a syscall_. As we all
agree, this is not necessarily the case.
Chris
^ permalink raw reply
* Re: [PATCH] [PowerPC] MPC8272ADS: fix device tree for 8 MB flash size
From: Wolfgang Denk @ 2009-05-13 19:42 UTC (permalink / raw)
To: Li Yang; +Cc: Scott Wood, linuxppc-dev, linux-kernel
In-Reply-To: <2a27d3730905130328m27743852w2d68a62ebc32ce31@mail.gmail.com>
Dear Li Yang,
In message <2a27d3730905130328m27743852w2d68a62ebc32ce31@mail.gmail.com> you wrote:
>
> Although 8MB seems to be the common size used. It can be very easy
> changed as a pluggable module. It might be better to make the code
> working for any reasonable flash sizes.
You either have to provide a correct device tree for your board, or
use a boot loader / boot wrapper that fixes the flash base address and
size.
At the moment, U-Boot does not contain any code yet to do that
(patches welcome :-), and as far as I understand the cuImage wrapper
works just the other way round: it adjusts the mappings to the
settings in the device tree, which may or may not match the actual
hardware. This may work, but at least gives you a different flash
memory map in Linux than what you had before in U-Boot, so it's not
really nice either.
Hm... it seems the majority of MPC8272ADS boards seems to come indeed
with 8 MB NOR flash, so I wonder if the patch should actually go in?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
In accord with UNIX philosophy, Perl gives you enough rope to hang
yourself. - L. Wall & R. L. Schwartz, _Programming Perl_
^ permalink raw reply
* Re: question about softirqs
From: Andi Kleen @ 2009-05-13 19:13 UTC (permalink / raw)
To: Chris Friesen
Cc: Peter Zijlstra, netdev, Ingo Molnar, Steven Rostedt, linuxppc-dev,
Andi Kleen, paulus, Thomas Gleixner, David Miller
In-Reply-To: <4A0B19A9.1090206@nortel.com>
On Wed, May 13, 2009 at 01:04:09PM -0600, Chris Friesen wrote:
> Andi Kleen wrote:
>
> > network packets are normally processed by the network packet interrupt's
> > softirq or alternatively in the NAPI poll loop.
>
> If we have a high priority task, ksoftirqd may not get a chance to run.
In this case the next interrupt will also process them. It will just
go more slowly because interrupts limit the work compared to ksoftirqd.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: question about softirqs
From: Chris Friesen @ 2009-05-13 19:04 UTC (permalink / raw)
To: Andi Kleen
Cc: Peter Zijlstra, netdev, Ingo Molnar, Steven Rostedt, linuxppc-dev,
paulus, Thomas Gleixner, David Miller
In-Reply-To: <20090513170122.GZ19296@one.firstfloor.org>
Andi Kleen wrote:
> network packets are normally processed by the network packet interrupt's
> softirq or alternatively in the NAPI poll loop.
If we have a high priority task, ksoftirqd may not get a chance to run.
My point is simply that the documentation says that softirqs are
processed on return from a syscall, and this is not necessarily the case.
Chris
^ permalink raw reply
* Re: [PATCH] leds: Add options to have GPIO LEDs start on or keep their state
From: Trent Piepho @ 2009-05-13 18:54 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, Richard Purdie, Sean MacLennan
In-Reply-To: <20090513091330.GA3078@pengutronix.de>
On Wed, 13 May 2009, Wolfram Sang wrote:
> > diff --git a/include/linux/leds.h b/include/linux/leds.h
> > index 376fe07..66e7d75 100644
> > --- a/include/linux/leds.h
> > +++ b/include/linux/leds.h
> > @@ -141,9 +141,14 @@ struct gpio_led {
> > const char *name;
> > const char *default_trigger;
> > unsigned gpio;
> > - u8 active_low : 1;
> > - u8 retain_state_suspended : 1;
> > + unsigned active_low : 1;
> > + unsigned retain_state_suspended : 1;
> > + unsigned default_state : 2;
> > + /* default_state should be one of LEDS_GPIO_DEFSTATE_(ON|OFF|KEEP) */
>
> Any specific reason for the change from u8 to unsigned? Could be
> mentioned in the patch description maybe. And what Sean mentioned :)
I should have mentioned that in the description. It didn't make sense to
me to declare a bit field with u8. An eight bit type that is one bit
wide? The field width overrides the type width, but I think it's better to
just use "unsigned" and only specify a width once.
>
> Other than that:
>
> Acked-by: Wolfram Sang <w.sang@pengutronix.de>
>
> --
> Pengutronix e.K. | Wolfram Sang |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
>
^ permalink raw reply
* Re: Delay on intialization ide subsystem(most likely)
From: Bartlomiej Zolnierkiewicz @ 2009-05-13 18:46 UTC (permalink / raw)
To: Andrey Gusev; +Cc: linux-ide, petkovbb, linuxppc-dev
In-Reply-To: <20090513211123.24825895@power-debian>
On Wednesday 13 May 2009 19:11:23 Andrey Gusev wrote:
> On Wed, 13 May 2009 15:28:26 +0200
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
>
> > On Tuesday 12 May 2009 21:50:24 Andrey Gusev wrote:
> > > On Mon, 27 Apr 2009 23:21:48 +0200
> > > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> > >
> > > > On Monday 27 April 2009 22:36:45 Andrey Gusev wrote:
> > > > > On Sat, 25 Apr 2009 16:48:38 +0200
> > > > > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > On Saturday 25 April 2009 15:02:03 Andrey Gusev wrote:
> > > > > > > Hello!
> > > > > > >
> > > > > > > I have tested linux-2.6.30-rc3 on my system and find some
> > > > > > > problems. One of them is delaying on initialization IDE
> > > > > > > subsystem. I don't have this problem on 2.6.29.1. The
> > > > > > > difference is looked on log of dmesg.
> > > > > >
> > > > > > Unfortunately this doesn't give us any hint about the root
> > > > > > cause of the bug so please try narrowing the problem down to
> > > > > > the specific change using git-bisect (sorry, there were 212
> > > > > > drivers/ide/ commits during v2.6.29..v2.6.30-rc3 and much much
> > > > > > more non-drivers/ide/ ones).
> > > > > >
> > > > > > Thanks,
> > > > > > Bart
> > > > > >
> > > > >
> > > > > Hello!
> > > > >
> > > > >
> > > > > The full result of bisect is:
> > > > >
> > > > >
> > > > > git bisect start
> > > > > # good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux 2.6.29
> > > > > git bisect good 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84
> > > > > # bad: [091069740304c979f957ceacec39c461d0192158] Linux
> > > > > 2.6.30-rc3 git bisect bad
> > > > > 091069740304c979f957ceacec39c461d0192158 # good:
> > > > > [40f07111be99b71c1e8d40c13cdc38445add787f] V4L/DVB (11166):
> > > > > pvrusb2: Implement status fetching from sub-devices git bisect
> > > > > good 40f07111be99b71c1e8d40c13cdc38445add787f # good:
> > > > > [ba0e1ebb7ea0616eebc29d2077355bacea62a9d8] Staging: sxg:
> > > > > slicoss: Specify the license for Sahara SXG and Slicoss drivers
> > > > > git bisect good ba0e1ebb7ea0616eebc29d2077355bacea62a9d8
> > > > >
> > > > >
> > > > > git bisect start 'drivers/ide/'
> > > >
> > > > Please note that limiting search space to drivers/ide/ may not
> > > > give reliable results in case problem was introduced by some
> > > > other kernel area.
> > > >
> > > > > # good: [ba0e1ebb7ea0616eebc29d2077355bacea62a9d8] Staging: sxg:
> > > > > slicoss: Specify the license for Sahara SXG and Slicoss drivers
> > > > > git bisect good ba0e1ebb7ea0616eebc29d2077355bacea62a9d8 # bad:
> > > > > [091069740304c979f957ceacec39c461d0192158] Linux 2.6.30-rc3 git
> > > > > bisect bad 091069740304c979f957ceacec39c461d0192158 # good:
> > > > > [e01f251fd09fa7cb3d352eac7de17bb5d5bd1f9d] ide-cd: convert
> > > > > cdrom_decode_status() to use switch statements git bisect good
> > > > > e01f251fd09fa7cb3d352eac7de17bb5d5bd1f9d # good:
> > > > > [3153c26b54230d025c6d536e8d3015def4524906] ide: refactor
> > > > > tf_read() method git bisect good
> > > > > 3153c26b54230d025c6d536e8d3015def4524906 # good:
> > > > > [c018f1ee5cf81e58b93d9e93a2ee39cad13dc1ac] hpt366: fix HPT370
> > > > > DMA timeouts git bisect good
> > > > > c018f1ee5cf81e58b93d9e93a2ee39cad13dc1ac # bad:
> > > > > [d5f840bf74c09ca5a31e518c9d984999926b5f44] ide: Remove void
> > > > > casts git bisect bad d5f840bf74c09ca5a31e518c9d984999926b5f44 #
> > > > > bad: [59c8d04f5ee97ea46da854e9adbbaa45d988c39d] hpt366: use
> > > > > ATA_DMA_* constants git bisect bad
> > > > > 59c8d04f5ee97ea46da854e9adbbaa45d988c39d
> > > >
> > > > Uhh.. something went wrong during bisect.
> > > >
> > > > "hpt366: use ATA_DMA_* constants" cannot be a first bad commit
> > > > because hpt366 is not even used on this system.
> > > >
> > > > Could it be that the delay doesn't happen on every boot for "bad"
> > > > kernels?
> > > >
> > > > Also, is 2.6.30-rc1 okay?
> > > >
> > > > Thanks,
> > > > Bart
> > > >
> > >
> > > Hello all!
> > >
> > > I continue to find reason of bug. I made more testing with bisect
> > > and got result:
> > >
> > > git bisect start
> > > # bad: [c018f1ee5cf81e58b93d9e93a2ee39cad13dc1ac] hpt366: fix
> > > HPT370 DMA timeouts git bisect bad
> > > # good:
> > > [fb4252e59452c18b88af014a2c4ee697bbf8cbc6] at91_ide: turn on PIO 6
> > > support git bisect good fb4252e59452c18b88af014a2c4ee697bbf8cbc6 #
> > > good: [2e1c63b7ed36532b68f0eddd6a184d7ba1013b89] Merge branch
> > > 'for-rc1/xen/core' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen git bisect
> > > good 2e1c63b7ed36532b68f0eddd6a184d7ba1013b89 # bad:
> > > [cd97824994042b809493807ea644ba26c0c23290] Merge
> > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 git
> > > bisect bad cd97824994042b809493807ea644ba26c0c23290 # bad:
> > > [a2c252ebdeaab28c9b400570594d576dae295958] Merge
> > > git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-fixes
> > > git bisect bad a2c252ebdeaab28c9b400570594d576dae295958 # good:
> > > [b897e6fbc49dd84b2634bca664344d503b907ce9] Merge branch
> > > 'drm-intel-next' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel git
> > > bisect good b897e6fbc49dd84b2634bca664344d503b907ce9 # good:
> > > [dfbc4752eab33e66f113f9daa2effbe241cd661d] brd: support barriers
> > > git bisect good dfbc4752eab33e66f113f9daa2effbe241cd661d # good:
> > > [a23c218bd36e11120daf18e00a91d5dc20e288e6] Merge branch 'merge' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc git
> > > bisect good a23c218bd36e11120daf18e00a91d5dc20e288e6 # good:
> > > [23da64b4714812b66ecf010e7dfb3ed1bf2eda69] Merge branch 'for-linus'
> > > of git://git.kernel.dk/linux-2.6-block git bisect good
> > > 23da64b4714812b66ecf010e7dfb3ed1bf2eda69 # good:
> > > [a228df6339e0d385b8149c860d81b6007f5e9c81] GFS2: Move umount flush
> > > rwsem git bisect good a228df6339e0d385b8149c860d81b6007f5e9c81 #
> > > skip: [1328df725239804ae30fc7257c1a3185e679b517] GFS2: Use
> > > DEFINE_SPINLOCK git bisect skip
> > > 1328df725239804ae30fc7257c1a3185e679b517 # good:
> > > [10d2198805d7faa2b193485446ff6b1de42c9b78] GFS2: cleanup
> > > file_operations mess git bisect good
> > > 10d2198805d7faa2b193485446ff6b1de42c9b78
> > >
> > > As I understand, I found bad commit, but it includes 5 commits. I
> > > checked them and they are good. So, I did git checkout
> > > a2c252ebdeaab28c9b400570594d576dae295958 and test one more time
> > > this commit. I found that bag is unstable. The boot can be bad or
> > > good on this commit. I compared dmesg of 'bad' and 'good' booting,
> > > but it is equal till delay.
> >
> > Thanks for doing it.
> >
> > > Any suggestions?
> >
> > Hard to tell...
> >
> > I went through all commits in-between
> >
> > fb4252e59452c18b88af014a2c4ee697bbf8cbc6
> >
> > and
> >
> > a2c252ebdeaab28c9b400570594d576dae295958
> >
> > and there are no obvious candidates..
> >
> > Could you please refresh my memory and tell me whether 2.6.30-rc2 was
> > OK?
> >
>
> It was ok, but I don't sure now. I tested only one boot, but this problem is not
> stable. I am rechecking it.
Ok.
Please also recheck first 'good' commit if 2.6.30-rc2 turns out to be 'bad'.
[ BTW the above bisection points that the problem was introduced outside of
drivers/ide or that it was introduced earlier that we'd initially thought ]
> I have added second hard drive and got new issue. May be this log (dmesg) can
> tell you something. It is on first known 'bad commit'. 2.6.29.2 can't properly
It tells us that there is some IRQ routing problem... seems like a platform
or ide-pmac specific problem. Does some earlier kernel work OK with this
configuration?
> initialize it too (got lost interrupt and disable dma).
>
> [ 1.113901] Uniform Multi-Platform E-IDE driver
> [ 1.120304] ide-pmac 0002:20:0d.0: enabling device (0000 -> 0002)
> [ 1.123139] adb: starting probe task...
> [ 1.125609] adb: finished probe task...
> [ 2.147653] ide-pmac: Found Apple UniNorth ATA-6 controller (PCI), bus ID 3, irq 39
> [ 2.152331] Probing IDE interface ide0...
> [ 2.457825] hda: IBM-IC35L060AVVA07-0, ATA DISK drive
> [ 2.817641] hdb: QUANTUM FIREBALLP LM20.5, ATA DISK drive
> [ 66.660447] hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> [ 66.660624] hda: UDMA/100 mode selected
> [ 66.663170] hdb: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> [ 66.663415] hdb: UDMA/66 mode selected
> [ 66.666108] ide0 at 0xf1012000-0xf1012070,0xf1012160 on irq 39
> [ 67.697640] ide-pmac: Found Apple KeyLargo ATA-4 controller (macio), bus ID 2, irq 19
> [ 67.702368] Probing IDE interface ide1...
> [ 131.867685] ide1 at 0xf100e000-0xf100e070,0xf100e160 on irq 19
> [ 132.897559] ide-pmac: Found Apple KeyLargo ATA-3 controller (macio), bus ID 0, irq 20
> [ 132.902273] Probing IDE interface ide2...
> [ 196.898053] hde: PHILIPS CDD5101, ATAPI CD/DVD-ROM drive
> [ 260.980668] hde: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> [ 260.981049] hde: MWDMA2 mode selected
> [ 260.984269] ide2 at 0xf1016000-0xf1016070,0xf1016160 on irq 20
> [ 260.989418] ide-gd driver 1.18
> [ 260.991880] hda: max request size: 128KiB
> [ 261.039649] hda: 120103200 sectors (61492 MB) w/1863KiB Cache, CHS=65535/16/63
> [ 261.044690] hda: cache flushes supported
> [ 261.047292] hda: [mac] hda1 hda2 hda3 hda4
> [ 261.060150] hdb: max request size: 128KiB
> [ 261.089788] hdb: 40132503 sectors (20547 MB) w/1900KiB Cache, CHS=39813/16/63
> [ 261.092287] hdb: cache flushes not supported
> [ 261.094754] hdb:<3>ide-pmac lost interrupt, dma status: 8480
> [ 281.089717] hdb: lost interrupt
> [ 281.092085] hdb: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
> [ 281.097038] ide: failed opcode was: unknown
> [ 281.101900] hda: DMA disabled
> [ 281.104247] hdb: DMA disabled
> [ 281.187260] ide0: reset: success
> [ 281.230368] hdb1 hdb2 < hdb5 hdb6 hdb7 hdb8 >
> [ 281.285486] ide-cd driver 5.00
> [ 281.297481] ide-cd: hde: ATAPI 32X DVD-ROM CD-R/RW drive, 8192kB Cache
> [ 281.299687] Uniform CD-ROM driver Revision: 3.20
^ permalink raw reply
* Re: device trees.
From: David H. Lynch Jr. @ 2009-05-13 18:11 UTC (permalink / raw)
To: David H. Lynch Jr., Stephen Neuendorffer, Grant Likely,
linuxppc-dev
In-Reply-To: <20090513062127.GU24338@yookeroo.seuss>
David Gibson wrote:
>
>
> Ok. If you have NOR flash, why couldn't you just put the dtb in a
> separate partition of the NOR?
>
>
It is not THE dtb, it is A dtb. Our systems support and typically use
multiple FPGA bit streams.
Clients are
That means each bitstream must have its own dtb, clients are
allowed/expected to create their own firmware,
but the norm is to leave the "PrimaryBoot.bit" startup bit file intact.
Clients may swap between several bit files for development purposes in
the course of a day.
It is even possible that a clients application may require swapping bit
files as part of normal operations.
I want one linux binary - because I know damn well that given two my
clients will use the wrong one alteast 30% of the time.
Somewhere arround 4 binaries that becomes almost 100% of the time.
Using dtb's to make the linux binary does NOT solve the problem it just
changes the file they have to get right.
Worse still the wrong dtb will probably mostly work. If it just failed
they would be more likely to grasp what they got wrong.
I need/want the device tree welded to the bitstream. That means creating
it dynamically or welding it to the bitstream.
Anything else wil be a support nightmare.
Though this does not impact Linux, we have clusters of FPGA's that are
used for High Performance computing,
One typical application is decryption where they work much like turing's
Bomb's at bletchley park only much faster.
Anyway in that application we load bitstreams into FPGA's exactly the
way someone would load programs into a processor.
The FPGA programming can be changed on a whim. In a cluster some
FPGA's/Processors might be executing one set of code while
others might be running different programming.
As the tools get better this is going to become even more common.
Right now this is not a linux application (linux manages the cluster),
but there is no reason you can not think of the cluster as a massive SMP
machine,
with massively parallel soft CPU's, and who knows the whole mess could
be running Linux itself.
The point I am trying to make is whatever I am doing now, things may be
totally different soon enough.
Every significant performance gain that occurs with Xilinx tools results
in a significant increase in our markets.
Hard and fast constraints guarantee problems down the line. Wasteful
choices that are easy now come back to haunt us down the line.
Standalone embedded systems are my bread and butter, but they are only
about 1/3 of our market.
Even within them 95% of our clients do not need Linux. Most do not
really need an OS at all.
Some of the time they do not even need a CPU.
We provide Linux because it makes them happy, because they are not up to
developing their own standalone programs to perform the tasks.
Still that means that Linux needs to make the task easier - not harder.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: question about softirqs
From: Andi Kleen @ 2009-05-13 17:01 UTC (permalink / raw)
To: Chris Friesen
Cc: Peter Zijlstra, netdev, Ingo Molnar, Steven Rostedt, linuxppc-dev,
Andi Kleen, paulus, Thomas Gleixner, David Miller
In-Reply-To: <4A0AE19D.9040509@nortel.com>
On Wed, May 13, 2009 at 09:05:01AM -0600, Chris Friesen wrote:
> Andi Kleen wrote:
> > Thomas Gleixner <tglx@linutronix.de> writes:
>
> >>Err, no. Chris is completely correct:
> >>
> >> if (!in_interrupt())
> >> wakeup_softirqd();
> >
> > Yes you have to wake it up just in case, but it doesn't normally
> > process the data because a normal softirq comes in faster. It's
> > just a safety policy.
>
> What about the scenario I raised earlier, where we have incoming network
> packets,
network packets are normally processed by the network packet interrupt's
softirq or alternatively in the NAPI poll loop.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: question about softirqs
From: Chris Friesen @ 2009-05-13 16:10 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Peter Zijlstra, netdev, Steven Rostedt, linuxppc-dev, Andi Kleen,
paulus, Ingo Molnar, David Miller
In-Reply-To: <alpine.LFD.2.00.0905131751150.3561@localhost.localdomain>
Thomas Gleixner wrote:
> On Wed, 13 May 2009, Chris Friesen wrote:
>> As far as I can tell, in this scenario softirqs may not get processed on
>> return from a syscall (contradicting the documentation). In the worst
>> case, they may not get processed until the next timer tick.
>
> Right because your high prio tasks prevents that ksoftirqd runs,
> because it can not preempt the high priority task.
Exactly.
I'm suggesting that this point (the idea that softirqs may or may not
get processed on return from syscall depending on relative task
priority) should probably be documented somewhere, because the current
documentation (in the kernel and on the web) doesn't mention it at all.
Maybe I should just submit a patch to
Documentation/DocBook/kernel-hacking.tmpl.
Chris
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox