* RE: My kernel hangs after transferring control to linux
From: Pedro Luis D. L. @ 2007-08-06 10:40 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <380-220078167042554@M2W021.mail2web.com>
Ramesh wrote on Mon, 6 Aug 2007 03:00:42 -0400
>
>Hi ,
> My kernel hangs after transferring control to linux ,can any one
>help
>me out how to trace my problem .
>
>I have attached my u-boot.bin and memory layout of our board.
>
>I guess problem will be on the u-boot configuration i am missing something
>.Can any one tell me what todo next because i am getting struck with it for
>more than 2 weeks.I have attached the snap-shot of my problem.If anyone
>has faced similar issue can help me out. I have attached my bin file also
>for your refference.
>
>Regards
>Ramesh
>
Is the console parameter given to the kernel at boot time?
I had the same problem long time ago and it was solved giving the
console=ttyPSC0,115200 parameter in bootargs. You will need to give the
appropriate parameter depending on your hardware, of course.
Regards,
Pedro.
>--------------------------------------------------------------------
>mail2web.com – What can On Demand Business Solutions do for you?
>http://link.mail2web.com/Business/SharePoint
>
><< Memory >>
><< U-2.png >>
><< U-1.png >>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
Horóscopo, tarot, numerología... Escucha lo que te dicen los astros.
http://astrocentro.msn.es/
^ permalink raw reply
* [RESEND][PATCH 1/3] ehea: Fix workqueue handling
From: Thomas Klein @ 2007-08-06 11:54 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Christoph Raisch, Stefan Roscher, linux-ppc, Jan-Bernd Themann,
Marcus Eder
Fix: Workqueue ehea_driver_wq was not destroyed
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
drivers/net/ehea/ehea.h | 2 +-
drivers/net/ehea/ehea_main.c | 1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 8ee2c2c..d67f97b 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0072"
+#define DRV_VERSION "EHEA_0073"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 58702f5..d43ab0f 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -3099,6 +3099,7 @@ out:
static void __exit ehea_module_exit(void)
{
+ destroy_workqueue(ehea_driver_wq);
driver_remove_file(&ehea_driver.driver, &driver_attr_capabilities);
ibmebus_unregister_driver(&ehea_driver);
ehea_destroy_busmap();
--
1.5.2
^ permalink raw reply related
* [RESEND][PATCH 2/3] ehea: Simplify resource usage check
From: Thomas Klein @ 2007-08-06 11:55 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Christoph Raisch, Stefan Roscher, linux-ppc, Jan-Bernd Themann,
Marcus Eder
Use shorter method to determine whether adapter has configured ports
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
drivers/net/ehea/ehea_main.c | 18 ++++++------------
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index d43ab0f..36ca322 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -2165,24 +2165,18 @@ static int ehea_clean_all_portres(struct ehea_port *port)
return ret;
}
-static void ehea_remove_adapter_mr (struct ehea_adapter *adapter)
+static void ehea_remove_adapter_mr(struct ehea_adapter *adapter)
{
- int i;
-
- for (i=0; i < EHEA_MAX_PORTS; i++)
- if (adapter->port[i])
- return;
+ if (adapter->active_ports)
+ return;
ehea_rem_mr(&adapter->mr);
}
-static int ehea_add_adapter_mr (struct ehea_adapter *adapter)
+static int ehea_add_adapter_mr(struct ehea_adapter *adapter)
{
- int i;
-
- for (i=0; i < EHEA_MAX_PORTS; i++)
- if (adapter->port[i])
- return 0;
+ if (adapter->active_ports)
+ return 0;
return ehea_reg_kernel_mr(adapter, &adapter->mr);
}
--
1.5.2
^ permalink raw reply related
* [RESEND][PATCH 3/3] ehea: Eliminated some compiler warnings
From: Thomas Klein @ 2007-08-06 11:55 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Christoph Raisch, Stefan Roscher, linux-ppc, Jan-Bernd Themann,
Marcus Eder
Fixed wrongly casted pointers
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
drivers/net/ehea/ehea_main.c | 25 ++++++++++---------------
1 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 36ca322..9756211 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -1326,7 +1326,6 @@ static void write_swqe2_TSO(struct sk_buff *skb,
u8 *imm_data = &swqe->u.immdata_desc.immediate_data[0];
int skb_data_size = skb->len - skb->data_len;
int headersize;
- u64 tmp_addr;
/* Packet is TCP with TSO enabled */
swqe->tx_control |= EHEA_SWQE_TSO;
@@ -1347,9 +1346,8 @@ static void write_swqe2_TSO(struct sk_buff *skb,
/* set sg1entry data */
sg1entry->l_key = lkey;
sg1entry->len = skb_data_size - headersize;
-
- tmp_addr = (u64)(skb->data + headersize);
- sg1entry->vaddr = ehea_map_vaddr(tmp_addr);
+ sg1entry->vaddr =
+ ehea_map_vaddr(skb->data + headersize);
swqe->descriptors++;
}
} else
@@ -1362,7 +1360,6 @@ static void write_swqe2_nonTSO(struct sk_buff *skb,
int skb_data_size = skb->len - skb->data_len;
u8 *imm_data = &swqe->u.immdata_desc.immediate_data[0];
struct ehea_vsgentry *sg1entry = &swqe->u.immdata_desc.sg_entry;
- u64 tmp_addr;
/* Packet is any nonTSO type
*
@@ -1379,8 +1376,8 @@ static void write_swqe2_nonTSO(struct sk_buff *skb,
/* copy sg1entry data */
sg1entry->l_key = lkey;
sg1entry->len = skb_data_size - SWQE2_MAX_IMM;
- tmp_addr = (u64)(skb->data + SWQE2_MAX_IMM);
- sg1entry->vaddr = ehea_map_vaddr(tmp_addr);
+ sg1entry->vaddr =
+ ehea_map_vaddr(skb->data + SWQE2_MAX_IMM);
swqe->descriptors++;
}
} else {
@@ -1395,7 +1392,6 @@ static inline void write_swqe2_data(struct sk_buff *skb, struct net_device *dev,
struct ehea_vsgentry *sg_list, *sg1entry, *sgentry;
skb_frag_t *frag;
int nfrags, sg1entry_contains_frag_data, i;
- u64 tmp_addr;
nfrags = skb_shinfo(skb)->nr_frags;
sg1entry = &swqe->u.immdata_desc.sg_entry;
@@ -1417,9 +1413,9 @@ static inline void write_swqe2_data(struct sk_buff *skb, struct net_device *dev,
/* copy sg1entry data */
sg1entry->l_key = lkey;
sg1entry->len = frag->size;
- tmp_addr = (u64)(page_address(frag->page)
- + frag->page_offset);
- sg1entry->vaddr = ehea_map_vaddr(tmp_addr);
+ sg1entry->vaddr =
+ ehea_map_vaddr(page_address(frag->page)
+ + frag->page_offset);
swqe->descriptors++;
sg1entry_contains_frag_data = 1;
}
@@ -1431,10 +1427,9 @@ static inline void write_swqe2_data(struct sk_buff *skb, struct net_device *dev,
sgentry->l_key = lkey;
sgentry->len = frag->size;
-
- tmp_addr = (u64)(page_address(frag->page)
- + frag->page_offset);
- sgentry->vaddr = ehea_map_vaddr(tmp_addr);
+ sgentry->vaddr =
+ ehea_map_vaddr(page_address(frag->page)
+ + frag->page_offset);
swqe->descriptors++;
}
}
--
1.5.2
^ permalink raw reply related
* Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping"
From: Olaf Hering @ 2007-08-06 11:58 UTC (permalink / raw)
To: Stefan Richter; +Cc: Robert Hancock, stable, linux-kernel, linuxppc-dev
In-Reply-To: <46B5824B.1000103@s5r6.in-berlin.de>
On Sun, Aug 05, Stefan Richter wrote:
> Benjamin Herrenschmidt wrote:
> >>> If setting 32-bit DMA mask fails on ppc64, that sounds like a problem
> >>> with the DMA implementation on that architecture. There are enough cards
> >>> out there that only support 32-bit DMA that this really needs to work..
> >> Yes, could the PPC folks please have a look at it? Thanks.
> >
> > Smells like we may have a bug there. No worries though, all current PPC
> > machines have an iommu that will not give out addresses above 32 bits
> > anyway, but I'll double check what's up.
> >
> > Do you see something in dmesg when that happens ?
>
> There was nothing in Olaf's report, except for trouble in sbp2 _after_
> the failure. http://lkml.org/lkml/2007/8/1/344 (I don't have a PMac.)
sbp2util_remove_command_orb_pool() does not check for lu->hi being NULL.
dev->dma_mask is NULL too, thats why dma_direct_dma_supported() returns
false, and dma_set_mask() will return -EIO.
^ permalink raw reply
* Re: [spi-devel-general] [PATCH] [SPI][POWERPC] spi_mpc83xx: in "QE mode" spiclk is sysclk/2
From: Anton Vorontsov @ 2007-08-06 12:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: David Brownell, spi-devel-general, linuxppc-dev
In-Reply-To: <595EE3AF-CDD6-4260-83D9-A3FA3EA1DF95@kernel.crashing.org>
On Fri, Aug 03, 2007 at 04:29:48AM -0500, Kumar Gala wrote:
>
> On Aug 2, 2007, at 4:47 PM, David Brownell wrote:
>
> > On Thursday 02 August 2007, Anton Vorontsov wrote:
> >> Probably someday mpc83xx_spi->sysclk should be renamed to
> >> mpc83xx_spi->spiclk to be less confusing.
> >
> > Why not "today", with this patch? That would fix some of
> > the root cause of this bug...
>
> I'm fine with this as well. I just called it sysclk to start with
> since when I wrote the driver it was just for the MPC834x.
Ok, great.
Now I think that `spiclk' is the bad name either, because it's output
clock of the spi unit. `spibrg' should be the best name for this,
as it's input clock to the SPI unit. Patch below.
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Subject: [PATCH] spi_mpc83xx: for SPI in QE spibrg's input is sysclk/2
For MPC8349E input to SPIBRG is SYSCLK, but it's SYSCLK/2 for
MPC8323E (SPI in QE).
Also mpc83xx_spi->sysclk renamed to mpc83xx_spi->spibrg.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/spi/spi_mpc83xx.c | 20 ++++++++++++--------
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
index 0c16a2b..446b624 100644
--- a/drivers/spi/spi_mpc83xx.c
+++ b/drivers/spi/spi_mpc83xx.c
@@ -86,7 +86,7 @@ struct mpc83xx_spi {
unsigned nsecs; /* (clock cycle time)/2 */
- u32 sysclk;
+ u32 spibrg; /* SPIBRG input clock */
u32 rx_shift; /* RX data reg shift when in qe mode */
u32 tx_shift; /* TX data reg shift when in qe mode */
@@ -169,17 +169,17 @@ static void mpc83xx_spi_chipselect(struct spi_device *spi, int value)
regval |= SPMODE_LEN(len);
- if ((mpc83xx_spi->sysclk / spi->max_speed_hz) >= 64) {
- u8 pm = mpc83xx_spi->sysclk / (spi->max_speed_hz * 64);
+ if ((mpc83xx_spi->spibrg / spi->max_speed_hz) >= 64) {
+ u8 pm = mpc83xx_spi->spibrg / (spi->max_speed_hz * 64);
if (pm > 0x0f) {
- printk(KERN_WARNING "MPC83xx SPI: SPICLK can't be less then a SYSCLK/1024!\n"
- "Requested SPICLK is %d Hz. Will use %d Hz instead.\n",
- spi->max_speed_hz, mpc83xx_spi->sysclk / 1024);
+ dev_warn(&spi->dev, "Requested speed is too "
+ "low: %d Hz. Will use %d Hz instead.\n",
+ spi->max_speed_hz, mpc83xx_spi->spibrg / 1024);
pm = 0x0f;
}
regval |= SPMODE_PM(pm) | SPMODE_DIV16;
} else {
- u8 pm = mpc83xx_spi->sysclk / (spi->max_speed_hz * 4);
+ u8 pm = mpc83xx_spi->spibrg / (spi->max_speed_hz * 4);
regval |= SPMODE_PM(pm);
}
@@ -429,13 +429,17 @@ static int __init mpc83xx_spi_probe(struct platform_device *dev)
mpc83xx_spi->bitbang.chipselect = mpc83xx_spi_chipselect;
mpc83xx_spi->bitbang.setup_transfer = mpc83xx_spi_setup_transfer;
mpc83xx_spi->bitbang.txrx_bufs = mpc83xx_spi_bufs;
- mpc83xx_spi->sysclk = pdata->sysclk;
mpc83xx_spi->activate_cs = pdata->activate_cs;
mpc83xx_spi->deactivate_cs = pdata->deactivate_cs;
mpc83xx_spi->qe_mode = pdata->qe_mode;
mpc83xx_spi->get_rx = mpc83xx_spi_rx_buf_u8;
mpc83xx_spi->get_tx = mpc83xx_spi_tx_buf_u8;
+ if (mpc83xx_spi->qe_mode)
+ mpc83xx_spi->spibrg = pdata->sysclk / 2;
+ else
+ mpc83xx_spi->spibrg = pdata->sysclk;
+
mpc83xx_spi->rx_shift = 0;
mpc83xx_spi->tx_shift = 0;
if (mpc83xx_spi->qe_mode) {
--
1.5.0.6
^ permalink raw reply related
* Re: [patch 02/10] 4xx Kconfig cleanup
From: Josh Boyer @ 2007-08-06 12:31 UTC (permalink / raw)
To: paulus, dwg; +Cc: linuxppc-dev
In-Reply-To: <20070804074538.GA5662@localhost.localdomain>
On Sat, Aug 04, 2007 at 05:45:38PM +1000, David Gibson wrote:
> On Fri, Aug 03, 2007 at 11:09:02AM -0500, Josh Boyer wrote:
> > Remove some leftover cruft in the 40x Kconfig file. Also make sure we
> > select WANT_DEVICE_TREE for 40x.
> >
> > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> >
> > ---
> > arch/powerpc/platforms/40x/Kconfig | 77 ---------------------------------
> > arch/powerpc/platforms/Kconfig.cputype | 1
> > 2 files changed, 1 insertion(+), 77 deletions(-)
> >
> > --- linux-2.6.orig/arch/powerpc/platforms/40x/Kconfig
> > +++ linux-2.6/arch/powerpc/platforms/40x/Kconfig
> > @@ -1,16 +1,3 @@
> > -config 4xx
> > - bool
> > - depends on 40x || 44x
> > - default y
>
> You've removed this one, but I don't see you re-add it anywhere. We
> still need to define the CONFIG_4xx symbol or things will break..
I don't need to re-add it. It's already in
arch/powerpc/platforms/Kconfig.cputype
josh
^ permalink raw reply
* Re: [patch 04/10] 4xx bootwrapper reworks
From: Josh Boyer @ 2007-08-06 12:36 UTC (permalink / raw)
To: paulus, dwg; +Cc: linuxppc-dev
In-Reply-To: <20070806043855.GF6103@localhost.localdomain>
On Mon, Aug 06, 2007 at 02:38:55PM +1000, David Gibson wrote:
> On Fri, Aug 03, 2007 at 11:09:04AM -0500, Josh Boyer wrote:
> > -#define SPRN_DBCR0 0x134
> > -#define DBCR0_RST_SYSTEM 0x30000000
> > +#define DBCR0_RST_SYSTEM 0x30000000
>
> Rather than just removing these defines and using hardcoded values,
> I'd prefer to see separate SPRN_DBCR0_40X and SPRN_DBCR0_44X defines.
Ok. And place them where? In the same file since they aren't DCR defines?
Seems fairly trivial, but ok.
> [snip]
> > +#define EMAC_RESET 0x20000000
> > +#define MAL_RESET 0x80000000
>
> I think the MAL_RESET definition should go in the same place as the
> DCR number definition.
Ok. Trivial.
> As I think I said before, I'm not really happy with this being
> hardcoded assuming exactly 2 ethernets.
Well, it's hardcoded to assume one or two. I know of only one board that has
more than two EMACs. I was hoping we could get this in for 2.6.24 as-is and
change it when needs be. But I'll look at making it var-args or similar.
josh
^ permalink raw reply
* Re: [patch 10/10] Bamboo zImage wrapper
From: Josh Boyer @ 2007-08-06 12:39 UTC (permalink / raw)
To: paulus, dwg; +Cc: linuxppc-dev
In-Reply-To: <20070806050011.GC11051@localhost.localdomain>
On Mon, Aug 06, 2007 at 03:00:12PM +1000, David Gibson wrote:
> On Fri, Aug 03, 2007 at 11:09:10AM -0500, Josh Boyer wrote:
> > Add a bootwrapper for the AMCC 440EP Bamboo Eval board. This also adds a
> > common fixup_clock function for all 440EP(x) chips.
>
> Ok, you have a separate bamboo.c and treeboot-bamboo.c, like with
> ebony. However here, therer's only one outermost wrapper -
> treeboot-bamboo.c which means there's not really any point to this
> separation.
Milton already mentioned this the first time I submitted the patch.
> Do you know if there are Bamboo boards with old u-boot versions, or
> some other bootloader which would make the separation worthwhile
> later?
Yes, there are. And yes, I plan on submitting the cuboot-bamboo.c wrapper
just as soon as I get a chance to get my board switched back to u-boot. It's
actually pretty trivial to keep both PIBS and u-boot on a bamboo board, since
you can program u-boot into the flash from PIBS and flip some switches to boot
from it.
josh
^ permalink raw reply
* [PATCH] [SPI][POWERPC] spi_mpc83xx: fix prescale modulus calculation
From: Anton Vorontsov @ 2007-08-06 13:10 UTC (permalink / raw)
To: spi-devel-general; +Cc: linuxppc-dev
Long ago I've noticed (but didn't pay much attention) that
spi_mpc83xx using PM calculations that differs from what
specs describe. I.e.
u8 pm = mpc83xx_spi->spibrg / (spi->max_speed_hz * 4);
While specs says: "The SPI baud rate generator clock source (either
system clock or system clock divided by 16, depending on DIV16 bit) is
divided by 4 * ([PM] + 1), a range from 4 to 64.".
Thus " - 1" is missing in the spi_mpc83xx's formula.
Why nobody noticed that bug? Probably because sysclk usually less then
user expects, e.g. you expect 200 MHz, but real clock is 198 MHz,
and integer rounding helps when this formula is used.
Suppose it's SPI in QE, SYSCLK at 198 MHz, thus SPIBRG at 99MHz, 25 MHz
requested.
PM = (99MHz / ( 25 MHz * 4 )), PM == 0, output SPICLK will be 24.75 MHz
At lower frequencies this bug is more noticeable, though.
And this bug shows itself in all its beauty if SYSCLK is equal or a bit
more than you expect (200 MHz SYSCLK, 100 MHz SPIBRG):
PM = (100MHz / ( 25 MHz * 4 )), PM == 1, output SPICLK will be 12.625 MHz!
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/spi/spi_mpc83xx.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
index 446b624..042704b 100644
--- a/drivers/spi/spi_mpc83xx.c
+++ b/drivers/spi/spi_mpc83xx.c
@@ -170,7 +170,8 @@ static void mpc83xx_spi_chipselect(struct spi_device *spi, int value)
regval |= SPMODE_LEN(len);
if ((mpc83xx_spi->spibrg / spi->max_speed_hz) >= 64) {
- u8 pm = mpc83xx_spi->spibrg / (spi->max_speed_hz * 64);
+ u8 pm = mpc83xx_spi->spibrg / (spi->max_speed_hz * 64) - 1;
+
if (pm > 0x0f) {
dev_warn(&spi->dev, "Requested speed is too "
"low: %d Hz. Will use %d Hz instead.\n",
@@ -180,6 +181,13 @@ static void mpc83xx_spi_chipselect(struct spi_device *spi, int value)
regval |= SPMODE_PM(pm) | SPMODE_DIV16;
} else {
u8 pm = mpc83xx_spi->spibrg / (spi->max_speed_hz * 4);
+
+ if (pm)
+ pm--;
+ else /* this floods dmesg if using mmc_spi, so dbg */
+ dev_dbg(&spi->dev, "Requested speed is too "
+ "high: %d Hz. Will use %d Hz instead.\n",
+ spi->max_speed_hz, mpc83xx_spi->spibrg / 4);
regval |= SPMODE_PM(pm);
}
--
1.5.0.6
^ permalink raw reply related
* RE: My kernel hangs after transferring control to linux
From: Stevan Ignjatovic @ 2007-08-06 13:11 UTC (permalink / raw)
To: Pedro Luis D. L.; +Cc: linuxppc-embedded
In-Reply-To: <BAY122-F17AC13F9942DC50628B067CAE50@phx.gbl>
Maybe this can help...
http://www.denx.de/wiki/view/DULG/LinuxHangsAfterUncompressingKernel
Regards,
Stevan
On Mon, 2007-08-06 at 12:40 +0200, Pedro Luis D. L. wrote:
>
> Ramesh wrote on Mon, 6 Aug 2007 03:00:42 -0400
> >
> >Hi ,
> > My kernel hangs after transferring control to linux ,can any one
> >help
> >me out how to trace my problem .
> >
> >I have attached my u-boot.bin and memory layout of our board.
> >
> >I guess problem will be on the u-boot configuration i am missing something
> >.Can any one tell me what todo next because i am getting struck with it for
> >more than 2 weeks.I have attached the snap-shot of my problem.If anyone
> >has faced similar issue can help me out. I have attached my bin file also
> >for your refference.
> >
> >Regards
> >Ramesh
> >
> Is the console parameter given to the kernel at boot time?
> I had the same problem long time ago and it was solved giving the
> console=ttyPSC0,115200 parameter in bootargs. You will need to give the
> appropriate parameter depending on your hardware, of course.
>
> Regards,
> Pedro.
> >--------------------------------------------------------------------
> >mail2web.com – What can On Demand Business Solutions do for you?
> >http://link.mail2web.com/Business/SharePoint
> >
>
>
> ><< Memory >>
>
>
> ><< U-2.png >>
>
>
> ><< U-1.png >>
>
>
> >_______________________________________________
> >Linuxppc-embedded mailing list
> >Linuxppc-embedded@ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> _________________________________________________________________
> Horóscopo, tarot, numerología... Escucha lo que te dicen los astros.
> http://astrocentro.msn.es/
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: DTC 1.0.0 Release Coming?
From: Josh Boyer @ 2007-08-06 13:48 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <20070727013331.GB1561@localhost.localdomain>
On Fri, 27 Jul 2007 11:33:31 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Thu, Jul 26, 2007 at 10:21:33AM -0500, Jon Loeliger wrote:
> > So, like, the other day David Gibson mumbled:
> >
> > > > > Only thing I'm not really happy with in the current release is the
> > > > > versioning stuff. For starters, it always reports my builds as
> > > > > -dirty, even when they're not.
> > > >
> > > > I think it won't do that once there is a tag available.
> > >
> > > Your 1.0.0-rc1 tag is there, still showing as dirty.
git vs quilt issue, as you have already discovered. I've always seen
that with kernel builds.
> > > > I would like to keep the current version mechanism as it
> > > > is really quite similar to what is in the Kernel now.
> > >
> > > First, I don't think it really is - except in superficial aspect of
> > > how the version number is partitioned
> >
> > I lifted the code from the Kernel's Makefile directly, and tweaked
> > it slightly for lack of Kconfig aspects.
>
> Ah, yes, ok, I see. Frankly I really don't think a lot of that stuff
> makes much sense outside the context of Kbuild. The whole complex
> filechk macro, for example - for which there's only one used parameter
> in dtc's case.
Except didn't you say you were going to work with Stephen to get DTC
into the kernel source itself? Keeping things similar to Kbuild might
help in that effort.
> > I don't want to tie the code and build mechanism to git too much.
> > Specifically, we need to be able to support stand-alone tarball
> > based builds. For example, I've spoken to the Debian package
> > maintainer on this issue, and he likes this approach as well as
> > he says it will make packaging it much easier.
>
> Have a look at the patch I posted. I haven't sufficiently tested it
> yet, but it should be able to generated version info for a tarball too
> (provided the .git-manifest file is included, and I'm intending that
> will be build by a make dist target). It will give both the
> git-derived based version, and a file content derived hash so we can
> robustly tell different builds apart, all with less code than the
> current system.
That may be. But I don't see the current approach being too much of a
problem either. Especially given that it's already there and it
works. Oh, and you sent out your patch saying it wasn't ready for
merge and with no sign off. Small but important issues to fix I'd
think.
This seems to be the last issue holding up a dtc 1.0 release. Perhaps
we could go with what exists and see if there really are problems. It
can always be fixed later.
josh
^ permalink raw reply
* Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping"
From: Olaf Hering @ 2007-08-06 13:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Robert Hancock, linuxppc-dev, Stefan Richter, stable,
linux-kernel
In-Reply-To: <1186351473.938.21.camel@localhost.localdomain>
On Mon, Aug 06, Benjamin Herrenschmidt wrote:
> BTW. Any reason why you don't set the DMA mask in the ohci driver rather
> than the sbp2 one ?
I used this patch, and the attached CD was found.
What dma mask should be used in ohci_probe()?
---
drivers/ieee1394/ohci1394.c | 2 ++
drivers/ieee1394/sbp2.c | 3 +++
drivers/pci/pci.c | 1 +
drivers/pci/probe.c | 1 +
include/asm-powerpc/dma-mapping.h | 1 +
5 files changed, 8 insertions(+)
--- a/drivers/ieee1394/ohci1394.c
+++ b/drivers/ieee1394/ohci1394.c
@@ -3223,6 +3223,8 @@ static int __devinit ohci1394_pci_probe(
}
#endif /* CONFIG_PPC_PMAC */
+ if (pci_set_dma_mask(dev, DMA_32BIT_MASK))
+ FAIL(-ENXIO, "Failed to set DMA mask");
if (pci_enable_device(dev))
FAIL(-ENXIO, "Failed to enable OHCI hardware");
pci_set_master(dev);
--- a/drivers/ieee1394/sbp2.c
+++ b/drivers/ieee1394/sbp2.c
@@ -775,12 +775,15 @@ static struct sbp2_lu *sbp2_alloc_device
goto failed_alloc;
}
#else
+ printk(KERN_DEBUG "%s():%u dev '%s' %p parent '%s' %p %016lx\n",__func__,__LINE__,hi->host->device.bus_id,hi->host->device.dma_mask,hi->host->device.parent->bus_id,(hi->host->device.parent->dma_mask),*(hi->host->device.parent->dma_mask));
if (dma_set_mask(hi->host->device.parent, DMA_32BIT_MASK)) {
SBP2_ERR("failed to set 4GB DMA mask");
goto failed_alloc;
}
#endif
}
+ else
+ printk(KERN_DEBUG "%s():%u dev '%s' parent '%s'\n",__func__,__LINE__,hi->host->device.bus_id,hi->host->device.parent->bus_id);
/* Prevent unloading of the 1394 host */
if (!try_module_get(hi->host->driver->owner)) {
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1358,6 +1358,7 @@ pci_set_dma_mask(struct pci_dev *dev, u6
return -EIO;
dev->dma_mask = mask;
+ printk(KERN_DEBUG "%s() '%s' %p %016lx\n",__func__,dev->dev.bus_id,dev->dev.dma_mask,*(dev->dev.dma_mask));
return 0;
}
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -937,6 +937,7 @@ void pci_device_add(struct pci_dev *dev,
set_dev_node(&dev->dev, pcibus_to_node(bus));
dev->dev.dma_mask = &dev->dma_mask;
+ printk(KERN_DEBUG "%s() '%s' %p %016lx\n",__func__,dev->dev.bus_id,dev->dev.dma_mask,*(dev->dev.dma_mask));
dev->dev.coherent_dma_mask = 0xffffffffull;
/* Fix up broken headers */
--- a/include/asm-powerpc/dma-mapping.h
+++ b/include/asm-powerpc/dma-mapping.h
@@ -92,6 +92,7 @@ static inline int dma_set_mask(struct de
{
struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
+ printk(KERN_DEBUG "%s() '%s' %016llx %p\n",__func__,dev->bus_id,(unsigned long long)dma_mask,dma_ops);
if (unlikely(dma_ops == NULL))
return -EIO;
if (dma_ops->set_dma_mask != NULL)
Using PowerMac machine description
Page orders: linear mapping = 24, virtual = 12, io = 12
Found initrd at 0xc000000001500000:0xc000000001763000
Found U3 memory controller & host bridge @ 0xf8000000 revision: 0x32
Mapped at 0xd000080080000000
Found a K2 mac-io controller, rev: 32, mapped at 0xd000080080041000
PowerMac motherboard: PowerMac G5
DART: table not allocated, using direct DMA
Starting Linux PPC64 #4 SMP Mon Aug 6 15:40:01 CEST 2007
-----------------------------------------------------
ppc64_pft_size = 0x0
physicalMemorySize = 0x10000000
ppc64_caches.dcache_line_size = 0x80
ppc64_caches.icache_line_size = 0x80
htab_address = 0xc00000000f800000
htab_hash_mask = 0x7fff
-----------------------------------------------------
Linux version 2.6.22.1-ppc64 (geeko@buildhost) (gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)) #4 SMP Mon Aug 6 15:40:01 CEST 2007
[boot]0012 Setup Arch
Top of RAM: 0x10000000, Total RAM: 0x10000000
Memory hole size: 0MB
Entering add_active_range(0, 0, 65536) 0 entries of 256 used
Found U3-AGP PCI host bridge. Firmware bus number: 240->255
Can't get bus-range for /ht@0,f2000000, assume bus 0
Found U3-HT PCI host bridge. Firmware bus number: 0->239
PCI Host 0, io start: 400000; io end: bfffff
PCI Host 1, io start: 0; io end: 3fffff
via-pmu: Server Mode is disabled
PMU driver v2 initialized for Core99, firmware: 0c
nvram: Checking bank 0...
nvram: gen0=493, gen1=492
nvram: Active bank is: 0
nvram: OF partition at 0x410
nvram: XP partition at 0x1020
nvram: NR partition at 0x1120
Zone PFN ranges:
DMA 0 -> 65536
Normal 65536 -> 65536
early_node_map[1] active PFN ranges
0: 0 -> 65536
On node 0 totalpages: 65536
DMA zone: 896 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 64640 pages, LIFO batch:15
Normal zone: 0 pages used for memmap
[boot]0015 Setup Done
Built 1 zonelists. Total pages: 64640
Kernel command line:
mpic: Setting up MPIC " MPIC 1 " version 1.2 at 80040000, max 4 CPUs
mpic: ISU size: 120, shift: 7, mask: 7f
mpic: Initializing for 120 sources
mpic: Setting up MPIC " MPIC 2 " version 1.2 at f8040000, max 4 CPUs
mpic: ISU size: 120, shift: 7, mask: 7f
mpic: Initializing for 120 sources
PID hash table entries: 1024 (order: 10, 8192 bytes)
time_init: decrementer frequency = 33.333333 MHz
time_init: processor frequency = 1600.000000 MHz
Console: colour dummy device 80x25
console handover: boot [udbg0] -> real [tty0]
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
freeing bootmem node 0
Memory: 242692k/262144k available (5920k kernel code, 19452k reserved, 1384k data, 1103k bss, 292k init)
Calibrating delay loop... 66.56 BogoMIPS (lpj=332800)
Security Framework v1.0.0 initialized
Mount-cache hash table entries: 256
PowerMac SMP probe found 1 cpus
Brought up 1 CPUs
NET: Registered protocol family 16
KeyWest i2c @0xf8001003 irq 42 /u3@0,f8000000/i2c@f8001000
channel 0 bus <multibus>
channel 1 bus <multibus>
KeyWest i2c @0x80018000 irq 26 /ht@0,f2000000/pci@3/mac-io@7/i2c@18000
channel 0 bus <multibus>
PMU i2c /ht@0,f2000000/pci@3/mac-io@7/via-pmu@16000/pmu-i2c
channel 1 bus <multibus>
channel 2 bus <multibus>
CPU Hotplug not supported by firmware - disabling.
PCI: Probing PCI hardware
pci_device_add() '0000:f0:0b.0' c000000001978860 00000000ffffffff
pci_device_add() '0000:f0:10.0' c00000000ff41860 00000000ffffffff
pci_device_add() '0001:00:01.0' c00000000ff41060 0000000000000000
pci_device_add() '0001:06:03.0' c00000000ff47860 0000000000000000
pci_device_add() '0001:00:02.0' c00000000ff47060 0000000000000000
Can't get ranges for PCI-PCI bridge /ht@0,f2000000/pci@2
pci_device_add() '0001:00:03.0' c00000000ff48860 0000000000000000
pci_device_add() '0001:01:07.0' c00000000ff48060 0000000000000000
pci_device_add() '0001:01:08.0' c00000000ff4b860 0000000000000000
pci_device_add() '0001:01:09.0' c00000000ff4b060 0000000000000000
pci_device_add() '0001:00:04.0' c00000000ff6c860 0000000000000000
pci_device_add() '0001:02:0b.0' c00000000ff6c060 0000000000000000
pci_device_add() '0001:02:0b.1' c00000000ff6d860 0000000000000000
pci_device_add() '0001:02:0b.2' c00000000ff6d060 0000000000000000
pci_device_add() '0001:00:05.0' c00000000ff6e860 0000000000000000
pci_device_add() '0001:03:0d.0' c00000000ff6e060 0000000000000000
pci_device_add() '0001:03:0e.0' c00000000ff71860 0000000000000000
pci_device_add() '0001:00:06.0' c00000000ff71060 0000000000000000
pci_device_add() '0001:04:0f.0' c00000000ff72860 0000000000000000
pci_device_add() '0001:00:07.0' c00000000ff72060 0000000000000000
pci_device_add() '0001:05:0c.0' c00000000ff73860 0000000000000000
mapping IO f0000000 -> d000080000400000, size: 800000
mapping IO f4000000 -> d000080000000000, size: 400000
PCI: Probing PCI hardware done
Registering pmac pic with sysfs...
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 2, 16384 bytes)
TCP established hash table entries: 8192 (order: 5, 196608 bytes)
TCP bind hash table entries: 8192 (order: 5, 131072 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
Unpacking initramfs... done
Freeing initrd memory: 2444k freed
nvram_init: Could not find nvram partition for nvram buffered error logging.
rtas_flash: no firmware flash support
IBM eBus Device Driver
Registering G5 CPU frequency driver
Frequency method: i2c/pfunc, Voltage method: i2c/pfunc
Low: 1301 Mhz, High: 1600 Mhz, Cur: 1600 MHz
audit: initializing netlink socket (disabled)
audit(1186407931.610:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
rpadlpar_io_init: partition not DLPAR capable
nvidiafb: Device ID: 10de0321
nvidiafb: CRTC0 analog not found
nvidiafb: CRTC1 analog found
nvidiafb: EDID found from BUS1
i2c-adapter i2c-1: unable to read EDID block.
i2c-adapter i2c-1: unable to read EDID block.
i2c-adapter i2c-1: unable to read EDID block.
nvidiafb: Found OF EDID for head 2
nvidiafb: EDID found from BUS2
nvidiafb: CRTC 1appears to have a CRT attached
nvidiafb: Using CRT on CRTC 1
Trying to im_free nonexistent area (d0000800800c1000)
Console: switching to colour frame buffer device 160x64
nvidiafb: PCI nVidia NV32 framebuffer (64MB @ 0xA8000000)
vio_register_driver: driver hvc_console registering
HVSI: registered 0 devices
Generic RTC Driver v1.07
pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>)
ttyS0 at MMIO 0x80013020 (irq = 22) is a Z85c30 ESCC - Serial port
ttyS1 at MMIO 0x80013000 (irq = 23) is a Z85c30 ESCC - Serial port
MacIO PCI driver attached to K2 chipset
input: Macintosh mouse button emulation as /class/input/input0
PowerMac G5 Thermal control driver 1.3
adb: starting probe task...
adb: finished probe task...
Detected fan controls:
0: PWM fan, id 1, location: BACKSIDE,SYS CTRLR FAN
1: RPM fan, id 2, location: DRIVE BAY
2: PWM fan, id 2, location: SLOT,PCI FAN
3: RPM fan, id 3, location: CPU A INTAKE
4: RPM fan, id 4, location: CPU A EXHAUST
5: RPM fan, id 5, location: CPU B INTAKE
6: RPM fan, id 6, location: CPU B EXHAUST
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PCI: Enabling device: (0001:03:0d.0), cmd 16
ide0: Found Apple K2 ATA-6 controller, bus ID 3, irq 39
Probing IDE interface ide0...
hda: PIONEER DVD-RW DVR-106D, ATAPI CD/DVD-ROM drive
hda: Enabling Ultra DMA 2
ide0 at 0xd00008008729a000-0xd00008008729a007,0xd00008008729a160 on irq 39
PCI: Enabling device: (0001:02:0b.2), cmd 6
ehci_hcd 0001:02:0b.2: EHCI Host Controller
ehci_hcd 0001:02:0b.2: new USB bus registered, assigned bus number 1
ehci_hcd 0001:02:0b.2: irq 63, io mem 0x80100000
ehci_hcd 0001:02:0b.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: new device found, idVendor=0000, idProduct=0000
usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.22.1-ppc64 ehci_hcd
usb usb1: SerialNumber: 0001:02:0b.2
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 5 ports detected
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
PCI: Enabling device: (0001:01:08.0), cmd 2
ohci_hcd 0001:01:08.0: OHCI Host Controller
ohci_hcd 0001:01:08.0: new USB bus registered, assigned bus number 2
ohci_hcd 0001:01:08.0: irq 27, io mem 0x80081000
usb usb2: new device found, idVendor=0000, idProduct=0000
usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: OHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.22.1-ppc64 ohci_hcd
usb usb2: SerialNumber: 0001:01:08.0
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
PCI: Enabling device: (0001:01:09.0), cmd 2
ohci_hcd 0001:01:09.0: OHCI Host Controller
ohci_hcd 0001:01:09.0: new USB bus registered, assigned bus number 3
ohci_hcd 0001:01:09.0: irq 28, io mem 0x80080000
usb usb3: new device found, idVendor=0000, idProduct=0000
usb usb3: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: OHCI Host Controller
usb usb3: Manufacturer: Linux 2.6.22.1-ppc64 ohci_hcd
usb usb3: SerialNumber: 0001:01:09.0
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
PCI: Enabling device: (0001:02:0b.0), cmd 2
ohci_hcd 0001:02:0b.0: OHCI Host Controller
ohci_hcd 0001:02:0b.0: new USB bus registered, assigned bus number 4
ohci_hcd 0001:02:0b.0: irq 63, io mem 0x80102000
usb usb4: new device found, idVendor=0000, idProduct=0000
usb usb4: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb4: Product: OHCI Host Controller
usb usb4: Manufacturer: Linux 2.6.22.1-ppc64 ohci_hcd
usb usb4: SerialNumber: 0001:02:0b.0
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 3 ports detected
PCI: Enabling device: (0001:02:0b.1), cmd 2
ohci_hcd 0001:02:0b.1: OHCI Host Controller
ohci_hcd 0001:02:0b.1: new USB bus registered, assigned bus number 5
ohci_hcd 0001:02:0b.1: irq 63, io mem 0x80101000
usb usb5: new device found, idVendor=0000, idProduct=0000
usb usb5: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb5: Product: OHCI Host Controller
usb usb5: Manufacturer: Linux 2.6.22.1-ppc64 ohci_hcd
usb usb5: SerialNumber: 0001:02:0b.1
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
mice: PS/2 mouse device common for all mice
PowerMac i2c bus pmu 2 registered
PowerMac i2c bus pmu 1 registered
PowerMac i2c bus mac-io 0 registered
PowerMac i2c bus u3 1 registered
PowerMac i2c bus u3 0 registered
FCU Initialized, RPM fan shift is 3
usb 5-2: new full speed USB device using ohci_hcd and address 2
usb 5-2: new device found, idVendor=05ac, idProduct=1003
usb 5-2: new device strings: Mfr=1, Product=2, SerialNumber=0
usb 5-2: Product: Hub in Apple Extended USB Keyboard
usb 5-2: Manufacturer: Mitsumi Electric
usb 5-2: configuration #1 chosen from 1 choice
hub 5-2:1.0: USB hub found
hub 5-2:1.0: 3 ports detected
usb 5-2.1: new low speed USB device using ohci_hcd and address 3
usb 5-2.1: new device found, idVendor=05ac, idProduct=0307
usb 5-2.1: new device strings: Mfr=1, Product=2, SerialNumber=0
usb 5-2.1: Product: Apple Optical USB Mouse
usb 5-2.1: Manufacturer: Logitech
usb 5-2.1: configuration #1 chosen from 1 choice
usb 5-2.3: new full speed USB device using ohci_hcd and address 4
usb 5-2.3: new device found, idVendor=05ac, idProduct=020c
usb 5-2.3: new device strings: Mfr=1, Product=3, SerialNumber=0
usb 5-2.3: Product: Apple Extended USB Keyboard
usb 5-2.3: Manufacturer: Mitsumi Electric
usb 5-2.3: configuration #1 chosen from 1 choice
usbcore: registered new interface driver hiddev
input: Logitech Apple Optical USB Mouse as /class/input/input1
input: USB HID v1.10 Mouse [Logitech Apple Optical USB Mouse] on usb-0001:02:0b.1-2.1
input: Mitsumi Electric Apple Extended USB Keyboard as /class/input/input2
input: USB HID v1.10 Keyboard [Mitsumi Electric Apple Extended USB Keyboard] on usb-0001:02:0b.1-2.3
input: Mitsumi Electric Apple Extended USB Keyboard as /class/input/input3
input: USB HID v1.10 Device [Mitsumi Electric Apple Extended USB Keyboard] on usb-0001:02:0b.1-2.3
usbcore: registered new interface driver usbhid
/dev/shm/R/linux-2.6.22/drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
oprofile: using ppc64/970 performance monitoring.
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
input: PMU as /class/input/input4
Registered led device: pmu-front-led
Freeing unused kernel memory: 292k freed
SCSI subsystem initialized
libata version 3.00 loaded.
sata_svw 0001:05:0c.0: version 2.2
pci_set_dma_mask() '0001:05:0c.0' c00000000ff73860 00000000ffffffff
scsi0 : sata_svw
scsi1 : sata_svw
scsi2 : sata_svw
scsi3 : sata_svw
ata1: SATA max UDMA/133 cmd 0xd0000800872a1000 ctl 0xd0000800872a1020 bmdma 0xd0000800872a1030 irq 16
ata2: SATA max UDMA/133 cmd 0xd0000800872a1100 ctl 0xd0000800872a1120 bmdma 0xd0000800872a1130 irq 16
ata3: SATA max UDMA/133 cmd 0xd0000800872a1200 ctl 0xd0000800872a1220 bmdma 0xd0000800872a1230 irq 16
ata4: SATA max UDMA/133 cmd 0xd0000800872a1300 ctl 0xd0000800872a1320 bmdma 0xd0000800872a1330 irq 16
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-6: ST380013AS, 3.05, max UDMA/133
ata1.00: 156301488 sectors, multi 0: LBA48
ata1.00: configured for UDMA/133
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: ATA-7: Maxtor 6Y080M0, YAR511W0, max UDMA/133
ata2.00: 156312576 sectors, multi 0: LBA
ata2.00: configured for UDMA/133
ata3: SATA link down (SStatus 4 SControl 300)
ata4: SATA link down (SStatus 4 SControl 300)
scsi 0:0:0:0: Direct-Access ATA ST380013AS 3.05 PQ: 0 ANSI: 5
scsi 1:0:0:0: Direct-Access ATA Maxtor 6Y080M0 YAR5 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8
sd 0:0:0:0: [sda] Attached SCSI disk
sd 1:0:0:0: [sdb] 156312576 512-byte hardware sectors (80032 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 1:0:0:0: [sdb] 156312576 512-byte hardware sectors (80032 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sdb: [mac] sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 sdb7 sdb8
sd 1:0:0:0: [sdb] Attached SCSI disk
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda8, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 1:0:0:0: Attached scsi generic sg1 type 0
Linux agpgart interface v0.102 (c) Dave Jones
agpgart: Detected Apple U3 chipset
agpgart: configuring for size idx: 8
agpgart: AGP aperture is 32M @ 0x0
tg3.c:v3.77 (May 31, 2007)
PCI: Enabling device: (0001:06:03.0), cmd 6
hda: ATAPI 32X DVD-ROM DVD-R CD-R/RW drive, 2000kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
snd-aoa-fabric-layout: found bus with layout 36
snd-aoa-fabric-layout: Using PMF GPIOs
snd-aoa-codec-tas: found 'deq' node
snd-aoa-fabric-layout: can use this codec
snd-aoa-codec-tas: tas found, addr 0x35 on /ht@0,f2000000/pci@3/mac-io@7/i2c@18000/deq@6a
pci_set_dma_mask() '0001:06:03.0' c00000000ff47860 ffffffffffffffff
eth0: Tigon3 [partno(3C996B-T) rev 0105 PHY(5701)] (PCI:33MHz:64-bit) 10/100/1000Base-T Ethernet 00:04:76:f3:c2:4f
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[0]
eth0: dma_rwctrl[76ff2d0f] dma_mask[64-bit]
sungem.c:v0.98 8/24/03 David S. Miller (davem@redhat.com)
pci_set_dma_mask() '0001:04:0f.0' c00000000ff72860 00000000ffffffff
PHY ID: 2062e0, addr: 1
eth1: Sun GEM (PCI) 10/100/1000BaseT Ethernet 00:0a:95:a6:5d:66
eth1: Found BCM5421-K2 PHY
pci_set_dma_mask() '0001:03:0e.0' c00000000ff71860 00000000ffffffff
PCI: Enabling device: (0001:03:0e.0), cmd 2
ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[40] MMIO=[80200000-802007ff] Max Packet=[4096] IR/IT contexts=[8/8]
Adding 1023992k swap on /dev/sdb3. Priority:-1 extents:1 across:1023992k
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com
ieee1394: Node added: ID:BUS[0-00:1023] GUID[0010100305179115]
ieee1394: Host added: ID:BUS[0-01:1023] GUID[000a95fffea65d66]
sbp2_alloc_device():778 dev 'fw-host0' 0000000000000000 parent '0001:03:0e.0' c00000000ff71860 00000000ffffffff
dma_set_mask() '0001:03:0e.0' 00000000ffffffff c0000000005fee68
scsi4 : SBP-2 IEEE-1394
loop: module loaded
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
REISERFS (device sdb4): found reiserfs format "3.6" with standard journal
REISERFS (device sdb4): using ordered data mode
reiserfs: using flush barriers
REISERFS (device sdb4): journal params: device sdb4, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
REISERFS (device sdb4): checking transaction log (sdb4)
REISERFS (device sdb4): Using r5 hash to sort names
eth1: Link is up at 100 Mbps, full-duplex.
AppArmor: AppArmor initialized<5>audit(1186407949.200:2): info="AppArmor initialized" pid=1871
fuse init (API version 7.8)
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: sbp2: Node 0-00:1023: Max speed [S400] - Max payload [2048]
scsi 4:0:0:0: CD-ROM MATSHITA DVD-RAM UJ-85JS F100 PQ: 0 ANSI: 0
scsi 4:0:0:0: Attached scsi generic sg2 type 5
sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda caddy
sr 4:0:0:0: Attached scsi CD-ROM sr0
audit(1186407951.229:3): operation="file_lock" requested_mask="k" denied_mask="k" name="/var/run/klogd.pid" pid=1949 profile="/sbin/klogd"
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
Mobile IPv6
ip6_tables: (C) 2000-2006 Netfilter Core Team
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
nf_conntrack version 0.5.0 (1024 buckets, 8192 max)
eth1: Link is up at 100 Mbps, full-duplex.
eth1: Pause is enabled (rxfifo: 10240 off: 7168 on: 5632)
audit(1186407961.889:4): operation="file_lock" requested_mask="k" denied_mask="k" name="/var/run/klogd.pid" pid=3061 profile="/sbin/klogd"
audit(1186407962.979:5): audit_pid=3113 old=0 by auid=4294967295
^ permalink raw reply
* Re: Please pull powerpc.git merge branch
From: Kumar Gala @ 2007-08-06 13:57 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <46B96294322F7D458F9648B60E15112C7A98ED@zch01exm26.fsl.freescale.net>
On Aug 6, 2007, at 12:57 AM, Zhang Wei-r63237 wrote:
> Hi, Paul,
>
> How about following patches?
>
> [PATCH 1/2] Add sysdev/pci_quirks.c file into PowerPC architecture
> with
> ULI chip quirk functions.
> URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-August/040363.html
> [PATCH 2/2] Remove ULI chip quirks functions from MPC8641HPCN and
> MPC8544DS boards.
> URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-August/040364.html
>
> [PATCH 1/3] Add a new member name to structure irq_host
> URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039896.html
> [PATCH 2/3] Add irq host name for all powerpc interrupt controllors.
> URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039897.html
> [PATCH 3/3] Add irq debugfs and virq_mapping for getting the virq
> URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039895.html
These patches aren't fixing any bugs and would be for 2.6.24 at this
point.
- k
^ permalink raw reply
* Re: [spi-devel-general] [PATCH] [SPI][POWERPC] spi_mpc83xx: fix prescale modulus calculation
From: David Brownell @ 2007-08-06 15:44 UTC (permalink / raw)
To: spi-devel-general; +Cc: linuxppc-dev
In-Reply-To: <20070806131014.GA6913@localhost.localdomain>
On Monday 06 August 2007, Anton Vorontsov wrote:
> +
> + if (pm)
> + pm--;
> + else /* this floods dmesg if using mmc_spi, so dbg */
> + dev_dbg(&spi->dev, "Requested speed is too "
> + "high: %d Hz. Will use %d Hz instead.\n",
> + spi->max_speed_hz, mpc83xx_spi->spibrg / 4);
Except that's not worthy of any message whatsoever, so it shouldn't
even be a debug message: user says "give me at most X", driver says
"fine", end of story.
I'm more bothered by the earlier message, which gives a rate higher
than X instead of cleanly failing.
- Dave
^ permalink raw reply
* Re: my cpu is MPC860, kernel version is 2.6.20.14, the kernel start info in the mail. why does the kernel panic?
From: Scott Wood @ 2007-08-06 15:52 UTC (permalink / raw)
To: poorbeyond; +Cc: Linux-ppc mail list
In-Reply-To: <200708051854252184131@163.com>
poorbeyond wrote:
> Linux version 2.6.20.14 (root@localhost.localdomain) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #1 PREEMPT Sun Aug 5 18:23:18 CST 2007
It wouldn't surprise me if the 8xx code has issues with PREEMPT; try
turning it off for now.
>
> ------------[ cut here ]------------
>
> Badness at 00200880 [verbose debug info unavailable]
>
> Call Trace:
>
> [00285E60] [00008E24] (unreliable)
>
> [00285E90] [000EBA14]
>
> [00285EA0] [00003D88]
Enable verbose debug messages and kallsyms for more useful output.
Are you running arch/ppc or arch/powerpc?
-Scott
^ permalink raw reply
* Re: [spi-devel-general] [PATCH] [SPI][POWERPC] spi_mpc83xx: fix prescale modulus?calculation
From: Anton Vorontsov @ 2007-08-06 16:39 UTC (permalink / raw)
To: David Brownell; +Cc: spi-devel-general, linuxppc-dev
In-Reply-To: <200708060844.40310.david-b@pacbell.net>
On Mon, Aug 06, 2007 at 08:44:40AM -0700, David Brownell wrote:
> On Monday 06 August 2007, Anton Vorontsov wrote:
> > +
> > + if (pm)
> > + pm--;
> > + else /* this floods dmesg if using mmc_spi, so dbg */
> > + dev_dbg(&spi->dev, "Requested speed is too "
> > + "high: %d Hz. Will use %d Hz instead.\n",
> > + spi->max_speed_hz, mpc83xx_spi->spibrg / 4);
>
> Except that's not worthy of any message whatsoever, so it shouldn't
> even be a debug message: user says "give me at most X", driver says
> "fine", end of story.
>
> I'm more bothered by the earlier message, which gives a rate higher
> than X instead of cleanly failing.
[...]
> So the patch should be more like the appended ...
Thanks! Reposting here.
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Subject: spi_mpc83xx: fix prescale modulus calculation
Long ago I've noticed (but didn't pay much attention) that
spi_mpc83xx using PM calculations that differs from what
specs describe. I.e.
u8 pm = mpc83xx_spi->spibrg / (spi->max_speed_hz * 4);
While specs says: "The SPI baud rate generator clock source (either
system clock or system clock divided by 16, depending on DIV16 bit) is
divided by 4 * ([PM] + 1), a range from 4 to 64.".
Thus " - 1" is missing in the spi_mpc83xx's formula.
Why nobody noticed that bug? Probably because sysclk usually less then
user expects, e.g. you expect 200 MHz, but real clock is 198 MHz,
and integer rounding helps when this formula is used.
Suppose it's SPI in QE, SYSCLK at 198 MHz, thus SPIBRG at 99MHz, 25 MHz
requested.
PM = (99MHz / ( 25 MHz * 4 )), PM == 0, output SPICLK will be 24.75 MHz
At lower frequencies this bug is more noticeable, though.
And this bug shows itself in all its beauty if SYSCLK is equal or a bit
more than you expect (200 MHz SYSCLK, 100 MHz SPIBRG):
PM = (100MHz / ( 25 MHz * 4 )), PM == 1, output SPICLK will be 12.625 MHz!
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
drivers/spi/spi_mpc83xx.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
index fe69e94..2adf856 100644
--- a/drivers/spi/spi_mpc83xx.c
+++ b/drivers/spi/spi_mpc83xx.c
@@ -148,6 +148,8 @@ static void mpc83xx_spi_chipselect(struct spi_device *spi, int value)
if (value == BITBANG_CS_ACTIVE) {
u32 regval = mpc83xx_spi_read_reg(&mpc83xx_spi->base->mode);
u32 len = spi->bits_per_word;
+ u8 pm;
+
if (len == 32)
len = 0;
else
@@ -170,7 +172,7 @@ static void mpc83xx_spi_chipselect(struct spi_device *spi, int value)
regval |= SPMODE_LEN(len);
if ((mpc83xx_spi->spibrg / spi->max_speed_hz) >= 64) {
- u8 pm = mpc83xx_spi->spibrg / (spi->max_speed_hz * 64);
+ pm = mpc83xx_spi->spibrg / (spi->max_speed_hz * 64) - 1;
if (pm > 0x0f) {
dev_err(&spi->dev, "Requested speed is too "
"low: %d Hz. Will use %d Hz instead.\n",
@@ -180,7 +182,9 @@ static void mpc83xx_spi_chipselect(struct spi_device *spi, int value)
}
regval |= SPMODE_PM(pm) | SPMODE_DIV16;
} else {
- u8 pm = mpc83xx_spi->spibrg / (spi->max_speed_hz * 4);
+ pm = mpc83xx_spi->spibrg / (spi->max_speed_hz * 4);
+ if (pm)
+ pm--;
regval |= SPMODE_PM(pm);
}
--
1.5.0.6
^ permalink raw reply related
* Re: [PATCH 1/2] [IDE] Platform IDE driver
From: Segher Boessenkool @ 2007-08-06 17:16 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-kernel, linux-ide
In-Reply-To: <46B07F04.8040806@ru.mvista.com>
>> More importantly, "reg-shift" doesn't say what part of
>> the bigger words to access. A common example is byte-wide
>> registers on a 32-bit-only bus; it's about 50%-50% between
>> connecting the registers to the low byte vs. connecting it
>> to the byte with the lowest address.
>
> We already have "big-endian" prop used in MPIC nodes, IIRC. Could
> try to "reuse" it here as well...
Sure. This would be an okay way to handle legacy devices that
are connected in inventive ways: add "reg-shift" and/or "big-endian"
properties. We should make sure this is documented in the
appropriate bindings though, don't just assume it will work.
For non-legacy devices, please just use the "compatible"
property to figure out the endianness etc.; it is a bad idea
to make a "blablabla-big-endian" compatible value, but you can
almost often just use a more specific model name instead; and
typically the device has some other quirks anyway ;-)
>> It would be nice to not name similar properties in the
>> device tree dissimilarly. Kernel code doesn't come into
>> the picture here.
>
> The "reg-shift" prop is yet unaccepted ad-hockery at this point. ;-)
> So, I don't see why we have to be consistent with it.
Don't treat your ad-hockery ad hoc, that way leads to insanity :-)
It's quite important to use good names for all new properties
you define, so you naturally end up with similar names for
similar purposes. Of course it isn't a *requirement*, you're
right about that.
Segher
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] MPC8349E-mITX: use platform IDE driver for CF interface
From: Segher Boessenkool @ 2007-08-06 17:19 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20070801005640.327226db@the-village.bc.nu>
>> The hardware is called (E)IDE, the protocol is called ATA.
>> Or that's what I was told -- I think there's some historic
>> revisionism involved, too.
>
> ATA is the interface and standards for the ANSI standards based disk
> attachment. IDE "Integrated Drive Electronics" is a marketing name used
> to cover all sorts of ST412 compatible-ish early interfaces that moved
> the brains onto the disk. IDE doesn't really mean much but "brains on
> disk", ATA is a real standard.
Thanks for refreshing my memory.
We will have to support both names in OF device tree nodes, since
both names are used in many existing device trees. For new nodes
with no precedent, like this "mmio-ide", let's require the more
correct "ata" name.
Segher
^ permalink raw reply
* Re: [patch 08/10] Bamboo DTS
From: Jon Loeliger @ 2007-08-06 18:01 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <20070806045332.GA11051@localhost.localdomain>
On Sun, 2007-08-05 at 23:53, David Gibson wrote:
> > + *
> > + * To build:
> > + * dtc -I dts -O asm -o bamboo.S -b 0 bamboo.dts
> > + * dtc -I dts -O dtb -o bamboo.dtb -b 0 bamboo.dts
>
> Can we ditch this "to build" boilerplate. It's just another thing
> people frequently forget to update as they copy it from dts to dts.
That's a good idea, I think. Especially since it is
not really accurate for u-boot with libfdt either.
I believe it that case it needs to have some extra
space reservations made for it as well.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] mark PCI resource with start 0 as unassigned
From: Segher Boessenkool @ 2007-08-06 18:04 UTC (permalink / raw)
To: Alan Cox; +Cc: linuxppc-dev, Olaf Hering, linux-ide
In-Reply-To: <20070801165140.3e176cd1@the-village.bc.nu>
>>> But 0 _is_ a valid PCI I/O address. Do we now have to start
>>
>> I wasn't in PCI 2.1 (later the corresponding passage have
>> disppeared).
>
> SFF controllers often use 0 to indicate a channel isn't configured and
> present. Libata and old IDE both assume these semantics for an SFF
> IDE device reporting address zero. It matches the hardware behaviour.
>
> I would suggest you don't map one at I/O zero on your PCI.
That's of course the smarter choice, _if_ we have a choice at
all -- on PowerPC, the PCI setup on certain platforms is done
by the firmware (and we don't want to mess with it for various
reasons), and some _do_ map PCI legacy I/O at 0.
Not in this case though, so let's just ignore that possibility
until it hits us in the face :-)
Segher
^ permalink raw reply
* Re: [patch 08/10] Bamboo DTS
From: Josh Boyer @ 2007-08-06 18:05 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras, David Gibson
In-Reply-To: <1186423283.5970.32.camel@ld0161-tx32>
On Mon, 06 Aug 2007 13:01:28 -0500
Jon Loeliger <jdl@freescale.com> wrote:
> On Sun, 2007-08-05 at 23:53, David Gibson wrote:
>
> > > + *
> > > + * To build:
> > > + * dtc -I dts -O asm -o bamboo.S -b 0 bamboo.dts
> > > + * dtc -I dts -O dtb -o bamboo.dtb -b 0 bamboo.dts
> >
> > Can we ditch this "to build" boilerplate. It's just another thing
> > people frequently forget to update as they copy it from dts to dts.
>
> That's a good idea, I think. Especially since it is
> not really accurate for u-boot with libfdt either.
> I believe it that case it needs to have some extra
> space reservations made for it as well.
Yeah, will kill it.
josh
^ permalink raw reply
* Re: Trying to use Device Tree...and getting continuous interrupts from attached 88e1145
From: Andy Fleming @ 2007-08-06 18:09 UTC (permalink / raw)
To: Morrison, Tom; +Cc: linuxppc-dev
In-Reply-To: <BD261180E6D35F4D9D32F3E44FD3D90108BE44C2@EMPBEDEX.empirix.com>
On Aug 3, 2007, at 17:54, Morrison, Tom wrote:
> All,
>
> Connected to eth1 (etsec2) of my mpc8548 cpu is a 88E1145 and I
> am trying to get the core functionality running with the device tree
> paradigm - I know the sense of the 88E1145 is active-low for my
> mpc8548 board and have it working with an older 2.6.11++ kernel.
>
> I built this new kernel with the marvell driver - it seemingly
> does all the same things we did in the 2.6.11 kernel in separate
> spots...
>
> Here is the appropriate parts of my device tree for this part of the
> core...
>
>>> mdio@24520 {
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>> device_type = "mdio";
>>> compatible = "gianfar";
>>> reg = <24520 20>;
>>> phy1: ethernet-phy@1 {
>>> interrupt-parent = <&mpic>;
>>> interrupts = <37 1>;
How recent of a kernel are you using? The current kernel assigns the
external interrupts to be the low 12 interrupts, which would make
your interrupt assignment wrong.
>
> Now, that looks OK! Those are what I would expect. And when the
> mdio/phy are probed, configured, and the 88E1145 interrupt (EXT7
> (0x37H)) is enabled, the interrupt never (seemingly) gets cleared,
> and basically hangs the entire box up and eventually it panics!
Can you determine where it's hanging. Or whether it is calling
phy_interrupt() at all? phy_interrupt should be disabling the
interrupt at the PIC, and then the interrupt should be handled in a
work queue.
Andy
^ permalink raw reply
* Re: [RFC][PATCH] MPC832x_RDB: update dts to use spi, register mmc_spi stub
From: Segher Boessenkool @ 2007-08-06 18:09 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070801123400.GA20200@localhost.localdomain>
>>> + spi1pio:spi_pin@01 {
>>
>> There should be whitespace after the label. @01 should be
>> spelled @1. Except there is no "reg" property.
>
> Hm. I've just tried to keep original style in this particular dts.
> Want to ack patch below?
Not unless you get rid of the extra zeroes, too :-)
> What is prefered style of <&label> vs. < &label > usage, btw?
>
> arch/powerpc/boot/dts$ grep "<&" -r . | wc -l
> 327
> arch/powerpc/boot/dts$ grep "< &" -r . | wc -l
> 92
>
> I can only guess - the first?
I think it looks neater, yes. I wouldn't worry about it
too much though.
>> What is this
>> stuff, anyway?
>
> Which one? pio-map for spi? This is GPIO pins configuration, to use
> dedicated functions (SPI) for these pins, otherwise SPI will not work.
The weird pseudo-nodes, yes. This really should be handled in
platform code, not in the device tree; if there is a need to
describe what GPIOs are used for what, that should be handled
differently.
> p.s. mpc8272ads.dts is broken wrt spaces/tabs, very.
Care to do a cleanup patch? Good for your karma ;-)
Segher
^ permalink raw reply
* Re: [RFC][PATCH] MPC832x_RDB: update dts to use spi, register mmc_spi stub
From: Segher Boessenkool @ 2007-08-06 18:18 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070801132948.GB20200@localhost.localdomain>
>>>>> spi@4c0 {
>>>>> device_type = "spi";
>>>>> + device-id = <1>;
>>>>
>>>> Can we just use the reg value for bus_num in the kernel.
>>>
>>> Sure, technically nothing prevents this. But, QE specs names
>>> SPIs by these ids.
>>
>> As a minimum the property name should start with "fsl," then.
>
> fsl,device-id = <1>;, correct?
Fine with me. Someone more familiar with the FSL SoCs might
have a different opinion about polluting their namespace though.
>>> Plus, from the kernel side spi name will be
>>> not pretty, it will be spi1216.1.
>>
>> What, the kernel cannot implement a counter itself?
>
> Just counter is especially meaningless and confusing. It will
> work in that particular case, though. But then SPI bus number will
> depend on definition order in the dts file. This isn't how SPI
> bus numbers should be assigned. SPI bus numbers taken from specs,
> this is how people know which SPI is which.
Right, so the kernel platform code should number the SPI busses
based on their position in the device tree, etc.; that doesn't
mean you should put a Linux-specific "device name" property in
there.
>>>>> + compatible = "mmc-spi";
>>
>> Needs to be more specific.
>
> Um.. for example? I can't imagine anything specific for this. ;-)
It should include a vendor name, a device name, and/or a board
name. Something that uniquely defines the hardware programming
model for the device.
>>>>> + pio-handle = <&mmc1pio>;
>>
>> What is this for?
>
> To set up output function of GPIO pin for MMC chip select.
>
> And well, I've just looked into par_io_of_config(), and I've found
> that pio-handle is mandatory (obviously), and thus let's back to:
>
>>>> we should do this in board code and not the device tree.
>>>
>>> Well, I've done this initially. But Vitaly hinted that this could
>>> be done in the DT instead, which made sense to me - mmc is the child
>>> device of SPI bus. Why do you think it shouldn't be in the DT? I'm
>>> not arguing, just want understand this.
>>
>> The hardware should be described in the device tree. This isn't
>> the same as simply copying all your Linux code into it ;-)
>
> Ugh. SD/MMC slot is the hardware, isn't it? It have wired SPI pins,
> and chip select pin. To set up this pin, I need mmc node, which means
> that I can't completely move mmc definitions to the board file, as
> suggested by Kumar Gala.
>
> Advices?
You need to declare in the SPI node which GPIOs it uses for
what. You shouldn't have the actual values to put into the
GPIO registers in the device tree; the kernel driver can
figure it out.
Hope this helps,
Segher
^ 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