* Re: [PATCH 08/12] IB/ehca: Replace get_paca()->paca_index by the more portable smp_processor_id()
From: Nathan Lynch @ 2007-09-11 14:51 UTC (permalink / raw)
To: Joachim Fenkes
Cc: LKML, OF-EWG, LinuxPPC-Dev, Christoph Raisch, OF-General,
Stefan Roscher
In-Reply-To: <200709111533.14333.fenkes@de.ibm.com>
Hi,
Joachim Fenkes wrote:
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
> ---
> drivers/infiniband/hw/ehca/ehca_tools.h | 14 +++++++-------
> 1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/infiniband/hw/ehca/ehca_tools.h b/drivers/infiniband/hw/ehca/ehca_tools.h
> index f9b264b..863f972 100644
> --- a/drivers/infiniband/hw/ehca/ehca_tools.h
> +++ b/drivers/infiniband/hw/ehca/ehca_tools.h
> @@ -73,37 +73,37 @@ extern int ehca_debug_level;
> if (unlikely(ehca_debug_level)) \
> dev_printk(KERN_DEBUG, (ib_dev)->dma_device, \
> "PU%04x EHCA_DBG:%s " format "\n", \
> - get_paca()->paca_index, __FUNCTION__, \
> + smp_processor_id(), __FUNCTION__, \
> ## arg); \
> } while (0)
>
> #define ehca_info(ib_dev, format, arg...) \
> dev_info((ib_dev)->dma_device, "PU%04x EHCA_INFO:%s " format "\n", \
> - get_paca()->paca_index, __FUNCTION__, ## arg)
> + smp_processor_id(), __FUNCTION__, ## arg)
>
> #define ehca_warn(ib_dev, format, arg...) \
> dev_warn((ib_dev)->dma_device, "PU%04x EHCA_WARN:%s " format "\n", \
> - get_paca()->paca_index, __FUNCTION__, ## arg)
> + smp_processor_id(), __FUNCTION__, ## arg)
>
> #define ehca_err(ib_dev, format, arg...) \
> dev_err((ib_dev)->dma_device, "PU%04x EHCA_ERR:%s " format "\n", \
> - get_paca()->paca_index, __FUNCTION__, ## arg)
> + smp_processor_id(), __FUNCTION__, ## arg)
I think I see these macros used in preemptible code (e.g. ehca_probe),
where smp_processor_id() will print a warning when
CONFIG_DEBUG_PREEMPT=y. Probably better to use raw_smp_processor_id.
^ permalink raw reply
* writing to flash from linux
From: Yoni Levin @ 2007-09-11 15:13 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 209 bytes --]
Hi , I have EN29LV640H flash (http://www.eonsdi.com/pdf/EN29LV640.pdf)
On my mpc83xx board.
How can I write data to flash from linux.?
I guess it done with mtd , there is an example somewhere?
Thanks.
[-- Attachment #2: Type: text/html, Size: 2445 bytes --]
^ permalink raw reply
* RE: [PATCH 5/5] Add DMA engine driver for Freescale MPC85xx processors.
From: Nelson, Shannon @ 2007-09-11 15:15 UTC (permalink / raw)
To: Scott Wood, Zhang Wei-r63237
Cc: linuxppc-dev, Williams, Dan J, paulus, linux-kernel
In-Reply-To: <20070911142014.GG1932@ld0162-tx32.am.freescale.net>
>From: Scott Wood [mailto:scottwood@freescale.com]=20
>Sent: Tuesday, September 11, 2007 7:20 AM
>To: Zhang Wei-r63237
>Cc: Nelson, Shannon; paulus@samba.org;=20
>linuxppc-dev@ozlabs.org; Williams, Dan J; linux-kernel@vger.kernel.org
>Subject: Re: [PATCH 5/5] Add DMA engine driver for Freescale=20
>MPC85xx processors.
>
>On Tue, Sep 11, 2007 at 06:10:53PM +0800, Zhang Wei-r63237 wrote:
>> > >+
>> > >+ fsl_dma_memcpy_issue_pending(chan);
>> > >+ while (fsl_dma_is_complete(chan, cookie, NULL, NULL)
>> > >+ !=3D DMA_SUCCESS);
>> >=20
>> > Again, is it possible to hang your thread here?
>> >=20
>> > [...]
>>=20
>> I'll add msleep here.
>
>I think what was being sought was a timout, causing the test to return
>failure.
>
>-Scott
>
Either a timeout to stop the polling, or msleep() followed by a single
call to fsl_dma_is_complete(). However, using the msleep() method is
likely to be kinder to the rest of the kernel than polling for very
long.
sln
^ permalink raw reply
* Re: [PATCH 1/3] fsl_soc.c cleanup
From: Kumar Gala @ 2007-09-11 15:48 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <20070911135717.GD1932@ld0162-tx32.am.freescale.net>
On Sep 11, 2007, at 8:57 AM, Scott Wood wrote:
> On Tue, Sep 11, 2007 at 12:35:56AM -0500, Kumar Gala wrote:
>>
>> On Aug 28, 2007, at 3:16 PM, Scott Wood wrote:
>>
>>> 1. Fix get_immrbase() to use ranges, rather than reg.
>>>
>>> It is not always the case that the SoC's first reg property points
>>> to the beginning of the entire SoC block.
>>
>> when is this true?
>
> The intent was to eliminate the need for the reg property in /soc.
>
>> Upon further testing this breaks some platforms. I don't think
>> assuming the first range entry is mapping to the SOC register space
>> is a good idea.
>
> Let me guess, 8544ds and 8548cds? Because of the same recent ranges
> changes that we were arguing about in another thread? :-P
Yep. However, after some discussion with Segher on this for 83xx/
85xx/86xx I think we want to keep the reg prop and have it cover the
initial soc registers [size on 83xx is 0x100, size on 85xx/86xx would
be 0x1000].
What we need is a saner way to determine immr on 82xx & 8xx.
Segher's rule is that a given "reg" prop shouldn't overlap w/any
other reg. We currently violate that on 8xx. Not as clear on 82xx
if we do that.
I'm thinking on 8xx we should move to grabbing a top level compat
value (mpc8xx) and use the SPRN_IMMR to set immrbase. On mpc82xx-pq2
we could add a immr "device" to search for.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Kumar Gala @ 2007-09-11 15:50 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20070911141821.GA32545@lixom.net>
On Sep 11, 2007, at 9:18 AM, Olof Johansson wrote:
> Hi,
>
> On Tue, Sep 11, 2007 at 01:29:18AM -0500, Kumar Gala wrote:
>> Added basic board port for MPC8572 DS reference platform that is
>> similiar to the MPC8544/33 DS reference platform in uniprocessor
>> mode.
>>
>> ---
>> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/
>> powerpc/platforms/85xx/mpc85xx_ds.c
>> index 3a5c3c4..1e2eba8 100644
>> --- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
>> +++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
>> @@ -181,6 +181,23 @@ static int __init mpc8544_ds_probe(void)
>> }
>> }
>>
>> +/*
>> + * Called very early, device-tree isn't unflattened
>> + */
>> +static int __init mpc8572_ds_probe(void)
>> +{
>> + unsigned long root = of_get_flat_dt_root();
>> +
>> + if (of_flat_dt_is_compatible(root, "MPC8572DS")) {
>> +#ifdef CONFIG_PCI
>> + primary_phb_addr = 0x8000;
>> +#endif
>> + return 1;
>> + } else {
>> + return 0;
>> + }
>> +}
>> +
>> define_machine(mpc8544_ds) {
>> .name = "MPC8544 DS",
>> .probe = mpc8544_ds_probe,
>> @@ -194,3 +211,17 @@ define_machine(mpc8544_ds) {
>> .calibrate_decr = generic_calibrate_decr,
>> .progress = udbg_progress,
>> };
>> +
>> +define_machine(mpc8572_ds) {
>> + .name = "MPC8572 DS",
>> + .probe = mpc8572_ds_probe,
>> + .setup_arch = mpc85xx_ds_setup_arch,
>> + .init_IRQ = mpc85xx_ds_pic_init,
>> +#ifdef CONFIG_PCI
>> + .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
>> +#endif
>> + .get_irq = mpic_get_irq,
>> + .restart = mpc85xx_restart,
>> + .calibrate_decr = generic_calibrate_decr,
>> + .progress = udbg_progress,
>> +};
>
> How different are these boards really? Could you just detect MPC85xxDS
> and have a generic platform for them, or are they different enough
> that
> you need individual ones for it?
I wanted a different probe. I figured having a different struct was
a simple solution.
>
>
>> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
>> index 06d23e1..c98b867 100644
>> --- a/include/linux/pci_ids.h
>> +++ b/include/linux/pci_ids.h
>> @@ -374,10 +374,9 @@
>> #define PCI_DEVICE_ID_ATI_IXP400_SATA 0x4379
>> #define PCI_DEVICE_ID_ATI_IXP400_SATA2 0x437a
>> #define PCI_DEVICE_ID_ATI_IXP600_SATA 0x4380
>> -#define PCI_DEVICE_ID_ATI_IXP600_SMBUS 0x4385
>> +#define PCI_DEVICE_ID_ATI_SBX00_SMBUS 0x4385
>> #define PCI_DEVICE_ID_ATI_IXP600_IDE 0x438c
>> #define PCI_DEVICE_ID_ATI_IXP700_SATA 0x4390
>> -#define PCI_DEVICE_ID_ATI_IXP700_SMBUS 0x4395
>> #define PCI_DEVICE_ID_ATI_IXP700_IDE 0x439c
>
> This looks like it doesn't belong in this patch.
oops :) {copying from an different tree}
- k
^ permalink raw reply
* [PATCH] [POWERPC] QE: simplify GUEMR register initialization
From: Timur Tabi @ 2007-09-11 15:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Timur Tabi
The initialization of the QE's GUEMR register is overly complicated, involving
multiple functions and a redundant ucc_common structure. This patch removes
struct ucc_common, merges ucc_init_guemr() into ucc_set_type() (every caller
of ucc_init_guemr() also calls ucc_set_type() immediately afterward), and
removes the unused enum ucc_pram_initial_offset.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/sysdev/qe_lib/ucc.c | 62 ++++++++++++++++++++-------------
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 12 +-----
arch/powerpc/sysdev/qe_lib/ucc_slow.c | 12 +-----
include/asm-powerpc/immap_qe.h | 11 +-----
include/asm-powerpc/qe.h | 7 ++--
include/asm-powerpc/ucc.h | 24 +------------
6 files changed, 48 insertions(+), 80 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/ucc.c b/arch/powerpc/sysdev/qe_lib/ucc.c
index f970e54..597204f 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc.c
@@ -43,43 +43,57 @@ int ucc_set_qe_mux_mii_mng(int ucc_num)
}
EXPORT_SYMBOL(ucc_set_qe_mux_mii_mng);
-int ucc_set_type(int ucc_num, struct ucc_common *regs,
- enum ucc_speed_type speed)
+/* Configure the UCC to either Slow or Fast.
+ *
+ * A given UCC can be figured to support either "slow" devices (e.g. UART)
+ * or "fast" devices (e.g. Ethernet).
+ *
+ * 'ucc_num' is the UCC number, from 0 - 7.
+ *
+ * This function also sets the UCC_GUEMR_SET_RESERVED3 bit because that bit
+ * must always be set to 1.
+ */
+int ucc_set_type(unsigned int ucc_num, enum ucc_speed_type speed)
{
- u8 guemr = 0;
+ u8 __iomem *p_guemr;
+ u8 mode; /* The GUEMR register mode bits */
- /* check if the UCC number is in range. */
- if ((ucc_num > UCC_MAX_NUM - 1) || (ucc_num < 0))
+ /* The GUEMR register is at the same location for both slow and fast
+ devices, so we just use uccX.slow.guemr. */
+ switch (ucc_num) {
+ case 0: p_guemr = &qe_immr->ucc1.slow.guemr;
+ break;
+ case 1: p_guemr = &qe_immr->ucc2.slow.guemr;
+ break;
+ case 2: p_guemr = &qe_immr->ucc3.slow.guemr;
+ break;
+ case 3: p_guemr = &qe_immr->ucc4.slow.guemr;
+ break;
+ case 4: p_guemr = &qe_immr->ucc5.slow.guemr;
+ break;
+ case 5: p_guemr = &qe_immr->ucc6.slow.guemr;
+ break;
+ case 6: p_guemr = &qe_immr->ucc7.slow.guemr;
+ break;
+ case 7: p_guemr = &qe_immr->ucc8.slow.guemr;
+ break;
+ default:
return -EINVAL;
+ }
- guemr = regs->guemr;
- guemr &= ~(UCC_GUEMR_MODE_MASK_RX | UCC_GUEMR_MODE_MASK_TX);
switch (speed) {
case UCC_SPEED_TYPE_SLOW:
- guemr |= (UCC_GUEMR_MODE_SLOW_RX | UCC_GUEMR_MODE_SLOW_TX);
+ mode = UCC_GUEMR_MODE_SLOW_RX | UCC_GUEMR_MODE_SLOW_TX;
break;
case UCC_SPEED_TYPE_FAST:
- guemr |= (UCC_GUEMR_MODE_FAST_RX | UCC_GUEMR_MODE_FAST_TX);
+ mode = UCC_GUEMR_MODE_FAST_RX | UCC_GUEMR_MODE_FAST_TX;
break;
default:
return -EINVAL;
}
- regs->guemr = guemr;
-
- return 0;
-}
-
-int ucc_init_guemr(struct ucc_common *regs)
-{
- u8 guemr = 0;
-
- if (!regs)
- return -EINVAL;
-
- /* Set bit 3 (which is reserved in the GUEMR register) to 1 */
- guemr = UCC_GUEMR_SET_RESERVED3;
- regs->guemr = guemr;
+ out_8(p_guemr, (in_8(p_guemr) & ~UCC_GUEMR_MODE_MASK) |
+ UCC_GUEMR_SET_RESERVED3 | mode);
return 0;
}
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_fast.c b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
index 3df202e..aa0fdd4 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
@@ -226,17 +226,9 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct ucc_fast_private ** ucc
uccf->rx_discarded = 0;
#endif /* STATISTICS */
- /* Init Guemr register */
- if ((ret = ucc_init_guemr((struct ucc_common *) (uf_regs)))) {
- printk(KERN_ERR "%s: cannot init GUEMR", __FUNCTION__);
- ucc_fast_free(uccf);
- return ret;
- }
-
/* Set UCC to fast type */
- if ((ret = ucc_set_type(uf_info->ucc_num,
- (struct ucc_common *) (uf_regs),
- UCC_SPEED_TYPE_FAST))) {
+ ret = ucc_set_type(uf_info->ucc_num, UCC_SPEED_TYPE_FAST);
+ if (ret) {
printk(KERN_ERR "%s: cannot set UCC type", __FUNCTION__);
ucc_fast_free(uccf);
return ret;
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_slow.c b/arch/powerpc/sysdev/qe_lib/ucc_slow.c
index 1f65c26..bc30e1c 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_slow.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_slow.c
@@ -187,17 +187,9 @@ int ucc_slow_init(struct ucc_slow_info * us_info, struct ucc_slow_private ** ucc
uccs->us_pram = qe_muram_addr(uccs->us_pram_offset);
- /* Init Guemr register */
- if ((ret = ucc_init_guemr((struct ucc_common *) us_regs))) {
- printk(KERN_ERR "%s: cannot init GUEMR", __FUNCTION__);
- ucc_slow_free(uccs);
- return ret;
- }
-
/* Set UCC to slow type */
- if ((ret = ucc_set_type(us_info->ucc_num,
- (struct ucc_common *) us_regs,
- UCC_SPEED_TYPE_SLOW))) {
+ ret = ucc_set_type(us_info->ucc_num, UCC_SPEED_TYPE_SLOW);
+ if (ret) {
printk(KERN_ERR "%s: cannot set UCC type", __FUNCTION__);
ucc_slow_free(uccs);
return ret;
diff --git a/include/asm-powerpc/immap_qe.h b/include/asm-powerpc/immap_qe.h
index 1020b7f..16ed82f 100644
--- a/include/asm-powerpc/immap_qe.h
+++ b/include/asm-powerpc/immap_qe.h
@@ -260,7 +260,6 @@ struct ucc_slow {
__be16 utpt;
u8 res4[0x52];
u8 guemr; /* UCC general extended mode register */
- u8 res5[0x200 - 0x091];
} __attribute__ ((packed));
/* QE UCC Fast */
@@ -293,21 +292,13 @@ struct ucc_fast {
__be32 urtry; /* UCC retry counter register */
u8 res8[0x4C];
u8 guemr; /* UCC general extended mode register */
- u8 res9[0x100 - 0x091];
-} __attribute__ ((packed));
-
-/* QE UCC */
-struct ucc_common {
- u8 res1[0x90];
- u8 guemr;
- u8 res2[0x200 - 0x091];
} __attribute__ ((packed));
struct ucc {
union {
struct ucc_slow slow;
struct ucc_fast fast;
- struct ucc_common common;
+ u8 res[0x200]; /* UCC blocks are 512 bytes each */
};
} __attribute__ ((packed));
diff --git a/include/asm-powerpc/qe.h b/include/asm-powerpc/qe.h
index 9d304b1..2256188 100644
--- a/include/asm-powerpc/qe.h
+++ b/include/asm-powerpc/qe.h
@@ -321,13 +321,14 @@ enum qe_clock {
#define UPGCR_ADDR 0x10000000 /* Master MPHY Addr multiplexing */
#define UPGCR_DIAG 0x01000000 /* Diagnostic mode */
-/* UCC */
+/* UCC GUEMR register */
#define UCC_GUEMR_MODE_MASK_RX 0x02
-#define UCC_GUEMR_MODE_MASK_TX 0x01
#define UCC_GUEMR_MODE_FAST_RX 0x02
-#define UCC_GUEMR_MODE_FAST_TX 0x01
#define UCC_GUEMR_MODE_SLOW_RX 0x00
+#define UCC_GUEMR_MODE_MASK_TX 0x01
+#define UCC_GUEMR_MODE_FAST_TX 0x01
#define UCC_GUEMR_MODE_SLOW_TX 0x00
+#define UCC_GUEMR_MODE_MASK (UCC_GUEMR_MODE_MASK_RX | UCC_GUEMR_MODE_MASK_TX)
#define UCC_GUEMR_SET_RESERVED3 0x10 /* Bit 3 in the guemr is reserved but
must be set 1 */
diff --git a/include/asm-powerpc/ucc.h b/include/asm-powerpc/ucc.h
index afe3076..f96ea54 100644
--- a/include/asm-powerpc/ucc.h
+++ b/include/asm-powerpc/ucc.h
@@ -28,35 +28,13 @@ enum ucc_speed_type {
UCC_SPEED_TYPE_FAST, UCC_SPEED_TYPE_SLOW
};
-/* Initial UCCs Parameter RAM address relative to: MEM_MAP_BASE (IMMR).
-*/
-enum ucc_pram_initial_offset {
- UCC_PRAM_OFFSET_UCC1 = 0x8400,
- UCC_PRAM_OFFSET_UCC2 = 0x8500,
- UCC_PRAM_OFFSET_UCC3 = 0x8600,
- UCC_PRAM_OFFSET_UCC4 = 0x9000,
- UCC_PRAM_OFFSET_UCC5 = 0x8000,
- UCC_PRAM_OFFSET_UCC6 = 0x8100,
- UCC_PRAM_OFFSET_UCC7 = 0x8200,
- UCC_PRAM_OFFSET_UCC8 = 0x8300
-};
-
/* ucc_set_type
* Sets UCC to slow or fast mode.
*
* ucc_num - (In) number of UCC (0-7).
- * regs - (In) pointer to registers base for the UCC.
* speed - (In) slow or fast mode for UCC.
*/
-int ucc_set_type(int ucc_num, struct ucc_common *regs,
- enum ucc_speed_type speed);
-
-/* ucc_init_guemr
- * Init the Guemr register.
- *
- * regs - (In) pointer to registers base for the UCC.
- */
-int ucc_init_guemr(struct ucc_common *regs);
+int ucc_set_type(unsigned int ucc_num, enum ucc_speed_type speed);
int ucc_set_qe_mux_mii_mng(int ucc_num);
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH 1/3] fsl_soc.c cleanup
From: Scott Wood @ 2007-09-11 15:51 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <3583FF3E-35E3-4B0A-A170-D69135E902F2@kernel.crashing.org>
Kumar Gala wrote:
> Yep. However, after some discussion with Segher on this for
> 83xx/85xx/86xx I think we want to keep the reg prop and have it cover
> the initial soc registers [size on 83xx is 0x100, size on 85xx/86xx
> would be 0x1000].
>
> What we need is a saner way to determine immr on 82xx & 8xx. Segher's
> rule is that a given "reg" prop shouldn't overlap w/any other reg. We
> currently violate that on 8xx. Not as clear on 82xx if we do that.
>
> I'm thinking on 8xx we should move to grabbing a top level compat value
> (mpc8xx) and use the SPRN_IMMR to set immrbase.
Any particular reason to special-case it, when we already need code to
do it the other way for every other fsl soc?
> On mpc82xx-pq2 we could
> add a immr "device" to search for.
Enh. The soc node *is* the immr "device". I'd rather add a node for
the "initial" registers (they generally don't involve configuring the
immr "bus" itself, but rather the chipselect bus and other miscellaneous
things) if needed, get rid of /soc/reg, and have ranges cover the whole
immr.
And why is 82xx-pq2 special? Wouldn't you need this on 83xx, 85xx, and
86xx as well?
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Olof Johansson @ 2007-09-11 15:55 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <230A7A2A-3184-4BC2-B8AC-C94090B532B0@kernel.crashing.org>
On Tue, Sep 11, 2007 at 10:50:18AM -0500, Kumar Gala wrote:
>>> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
>>> b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
>>> index 3a5c3c4..1e2eba8 100644
>>> --- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
>>> +++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
>>> @@ -181,6 +181,23 @@ static int __init mpc8544_ds_probe(void)
>>> }
>>> }
>>>
>>> +/*
>>> + * Called very early, device-tree isn't unflattened
>>> + */
>>> +static int __init mpc8572_ds_probe(void)
>>> +{
>>> + unsigned long root = of_get_flat_dt_root();
>>> +
>>> + if (of_flat_dt_is_compatible(root, "MPC8572DS")) {
>>> +#ifdef CONFIG_PCI
>>> + primary_phb_addr = 0x8000;
>>> +#endif
>>> + return 1;
>>> + } else {
>>> + return 0;
>>> + }
>>> +}
>>> +
>>> define_machine(mpc8544_ds) {
>>> .name = "MPC8544 DS",
>>> .probe = mpc8544_ds_probe,
>>> @@ -194,3 +211,17 @@ define_machine(mpc8544_ds) {
>>> .calibrate_decr = generic_calibrate_decr,
>>> .progress = udbg_progress,
>>> };
>>> +
>>> +define_machine(mpc8572_ds) {
>>> + .name = "MPC8572 DS",
>>> + .probe = mpc8572_ds_probe,
>>> + .setup_arch = mpc85xx_ds_setup_arch,
>>> + .init_IRQ = mpc85xx_ds_pic_init,
>>> +#ifdef CONFIG_PCI
>>> + .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
>>> +#endif
>>> + .get_irq = mpic_get_irq,
>>> + .restart = mpc85xx_restart,
>>> + .calibrate_decr = generic_calibrate_decr,
>>> + .progress = udbg_progress,
>>> +};
>>
>> How different are these boards really? Could you just detect MPC85xxDS
>> and have a generic platform for them, or are they different enough that
>> you need individual ones for it?
>
> I wanted a different probe. I figured having a different struct was a
> simple solution.
Seems like the only reason to need that is the setting of
primary_phb_addr. Can't that information be derived out of the device
tree instead? That'd avoid alot of code duplication (code that includes
ifdefs, FWIW :-)
It just seems like a slippery slope. I'm not objecting directly to this
patch, but I think it should be fixed for the longer term.
-Olof
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Kumar Gala @ 2007-09-11 15:58 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070911141711.GE1932@ld0162-tx32.am.freescale.net>
On Sep 11, 2007, at 9:17 AM, Scott Wood wrote:
> On Tue, Sep 11, 2007 at 01:29:18AM -0500, Kumar Gala wrote:
>> diff --git a/arch/powerpc/boot/dts/mpc8572ds.dts b/arch/powerpc/
>> boot/dts/mpc8572ds.dts
>> new file mode 100644
>> index 0000000..9d23561
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/mpc8572ds.dts
>> @@ -0,0 +1,378 @@
>> +/*
>> + * MPC8572 DS Device Tree Source
>> + *
>> + * Copyright 2007 Freescale Semiconductor Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> modify it
>> + * under the terms of the GNU General Public License as
>> published by the
>> + * Free Software Foundation; either version 2 of the License,
>> or (at your
>> + * option) any later version.
>> + */
>> +
>> +/ {
>> + model = "MPC8572DS";
>> + compatible = "MPC8572DS", "MPC85xxDS";
>
> "fsl," prefix on compatible.
>
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + cpus {
>> + #cpus = <1>;
>
> Where is #cpus defined or used? I don't see it used in any other
> trees, either.
will kill.
>
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + PowerPC,8572@0 {
>> + device_type = "cpu";
>> + reg = <0>;
>> + d-cache-line-size = <20>; // 32 bytes
>> + i-cache-line-size = <20>; // 32 bytes
>> + d-cache-size = <8000>; // L1, 32K
>> + i-cache-size = <8000>; // L1, 32K
>> + timebase-frequency = <0>;
>> + bus-frequency = <0>;
>> + clock-frequency = <0>;
>> + 32-bit;
>
> Where is 32-bit; defined or used?
its a copy paste error. Will kill 32-bit on other platforms.
>
>> + soc8572@ffe00000 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + #interrupt-cells = <2>;
>> + device_type = "soc";
>> + ranges = <00000000 ffe00000 00100000
>> + 80000000 80000000 20000000
>> + a0000000 a0000000 20000000
>> + c0000000 c0000000 20000000
>> + ffc00000 ffc00000 00010000
>> + ffc10000 ffc10000 00010000
>> + ffc20000 ffc20000 00010000>;
>> +
>> + reg = <ffe00000 00001000>; // CCSRBAR 1M
>
> Comment doesn't match what's actually in reg.
will fix.
>
>> + bus-frequency = <0>; // Filled out by uboot.
>> +
>> + memory-controller@2000 {
>> + compatible = "fsl,8572-memory-controller";
>
> Is it compatible with any other 85xx memory controller?
maybe, but I don't want to get into that just yet.
>
>> + reg = <2000 1000>;
>> + interrupt-parent = <&mpic>;
>> + interrupts = <12 2>;
>> + };
>> +
>> + l2-cache-controller@20000 {
>> + compatible = "fsl,8572-l2-cache-controller";
>> + reg = <20000 1000>;
>> + cache-line-size = <20>; // 32 bytes
>> + cache-size = <80000>; // L2, 512K
>> + interrupt-parent = <&mpic>;
>> + interrupts = <10 2>;
>> + };
>
> Should this node be referenced by an l2-cache property in the cpu
> node?
No, its a front side cache.
>
>> + pcie@8000 {
>> + compatible = "fsl,mpc8641-pcie";
>
> Should probably be "fsl,mpc8572-pcie", "fsl,mpc8641-pcie".
this should "fsl,mpc8548-pcie" to match other 85xx pcie.
>
>> + device_type = "pci";
>> + #interrupt-cells = <1>;
>> + #size-cells = <2>;
>> + #address-cells = <3>;
>> + reg = <8000 1000>;
>> + bus-range = <0 ff>;
>> + ranges = <02000000 0 80000000 80000000 0 20000000
>> + 01000000 0 00000000 ffc00000 0 00010000>;
>
> No prefetchable mem space?
we haven't normally provided prefetch on 85xx/86xx.. will deal with
this later.
>
>> + clock-frequency = <1fca055>;
>
> Decimal would be nicer.
>
>> + pcie@9000 {
>> + compatible = "fsl,mpc8548-pcie";
>
> Why is this one 8548-compatible and the previous one 8641-compatible?
copy paste, will fix.
>
>> + mpic: pic@40000 {
>> + clock-frequency = <0>;
>> + interrupt-controller;
>> + #address-cells = <0>;
>> + #interrupt-cells = <2>;
>> + reg = <40000 40000>;
>> + built-in;
>> + compatible = "chrp,open-pic";
>> + device_type = "open-pic";
>> + big-endian;
>> + };
>
> Where is the built-in; property defined or used?
defined in chrp OF spec, not sure why we bother with it.
>
>> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
>> index 06d23e1..c98b867 100644
>> --- a/include/linux/pci_ids.h
>> +++ b/include/linux/pci_ids.h
>> @@ -374,10 +374,9 @@
>> #define PCI_DEVICE_ID_ATI_IXP400_SATA 0x4379
>> #define PCI_DEVICE_ID_ATI_IXP400_SATA2 0x437a
>> #define PCI_DEVICE_ID_ATI_IXP600_SATA 0x4380
>> -#define PCI_DEVICE_ID_ATI_IXP600_SMBUS 0x4385
>> +#define PCI_DEVICE_ID_ATI_SBX00_SMBUS 0x4385
>> #define PCI_DEVICE_ID_ATI_IXP600_IDE 0x438c
>> #define PCI_DEVICE_ID_ATI_IXP700_SATA 0x4390
>> -#define PCI_DEVICE_ID_ATI_IXP700_SMBUS 0x4395
>> #define PCI_DEVICE_ID_ATI_IXP700_IDE 0x439c
>
> What's going on here?
copied file over from an older tree.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Kumar Gala @ 2007-09-11 16:00 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20070911155558.GA10743@lixom.net>
On Sep 11, 2007, at 10:55 AM, Olof Johansson wrote:
> On Tue, Sep 11, 2007 at 10:50:18AM -0500, Kumar Gala wrote:
>>>> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
>>>> b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
>>>> index 3a5c3c4..1e2eba8 100644
>>>> --- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
>>>> +++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
>>>> @@ -181,6 +181,23 @@ static int __init mpc8544_ds_probe(void)
>>>> }
>>>> }
>>>>
>>>> +/*
>>>> + * Called very early, device-tree isn't unflattened
>>>> + */
>>>> +static int __init mpc8572_ds_probe(void)
>>>> +{
>>>> + unsigned long root = of_get_flat_dt_root();
>>>> +
>>>> + if (of_flat_dt_is_compatible(root, "MPC8572DS")) {
>>>> +#ifdef CONFIG_PCI
>>>> + primary_phb_addr = 0x8000;
>>>> +#endif
>>>> + return 1;
>>>> + } else {
>>>> + return 0;
>>>> + }
>>>> +}
>>>> +
>>>> define_machine(mpc8544_ds) {
>>>> .name = "MPC8544 DS",
>>>> .probe = mpc8544_ds_probe,
>>>> @@ -194,3 +211,17 @@ define_machine(mpc8544_ds) {
>>>> .calibrate_decr = generic_calibrate_decr,
>>>> .progress = udbg_progress,
>>>> };
>>>> +
>>>> +define_machine(mpc8572_ds) {
>>>> + .name = "MPC8572 DS",
>>>> + .probe = mpc8572_ds_probe,
>>>> + .setup_arch = mpc85xx_ds_setup_arch,
>>>> + .init_IRQ = mpc85xx_ds_pic_init,
>>>> +#ifdef CONFIG_PCI
>>>> + .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
>>>> +#endif
>>>> + .get_irq = mpic_get_irq,
>>>> + .restart = mpc85xx_restart,
>>>> + .calibrate_decr = generic_calibrate_decr,
>>>> + .progress = udbg_progress,
>>>> +};
>>>
>>> How different are these boards really? Could you just detect
>>> MPC85xxDS
>>> and have a generic platform for them, or are they different
>>> enough that
>>> you need individual ones for it?
>>
>> I wanted a different probe. I figured having a different struct
>> was a
>> simple solution.
>
> Seems like the only reason to need that is the setting of
> primary_phb_addr. Can't that information be derived out of the device
> tree instead? That'd avoid alot of code duplication (code that
> includes
> ifdefs, FWIW :-)
well the ifdefs are orthogonal. We don't have a way of knowing
primary from the device tree today.
> It just seems like a slippery slope. I'm not objecting directly to
> this
> patch, but I think it should be fixed for the longer term.
Once we have a clean way of knowing primary PHB than I'm happy to fixup.
- k
^ permalink raw reply
* RE: SPI driver?
From: Nicholas Hickman @ 2007-09-11 15:50 UTC (permalink / raw)
To: Hesam.Kohanteb, linuxppc-embedded
In-Reply-To: <46E56DEA.3060205@Sun.COM>
I am also in search of this, or some information about one. Please let
me know if you find anything.
I ran across an existing platform that used an mpc8270. During boot up
it displayed:
[ 17.828513] SPIDriver: module license 'Proprietary' taints kernel.
[ 17.865052] CPM SPI Driver: $Revision: 1.0 $ wd@denx.de
I have been all over denx and have not been able to find it. This
particular system used the SPI for a DSP chip.=20
-Nick
-----Original Message-----
From: linuxppc-embedded-bounces+nhickman=3Ddtechlabs.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+nhickman=3Ddtechlabs.com@ozlabs.org] =
On
Behalf Of Hesam Kohanteb
Sent: Monday, September 10, 2007 12:17 PM
To: linuxppc-embedded@ozlabs.org
Subject: SPI driver?
We need a Linux based SPI driver for MPC885. Do you know where can I
possibly find the code.
Regards. --Hesam
--
Hesam Yehuda Kohanteb
(Netra Systems & Networking),
M/S USCA12-216 4120 Network Circle
Santa Clara, CA 95054
(W) 408-276-7329 X17329, Fax 408-276-4552
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH v2] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Kumar Gala @ 2007-09-11 16:09 UTC (permalink / raw)
To: linuxppc-dev
Added basic board port for MPC8572 DS reference platform that is
similiar to the MPC8544/33 DS reference platform in uniprocessor mode.
---
Take two, with my clean ups to the device tree as commented by Scott and
fixing my copy/paste foobar with pci_ids.h.
arch/powerpc/boot/dts/mpc8572ds.dts | 375 ++++++++
arch/powerpc/configs/mpc8572_ds_defconfig | 1496 +++++++++++++++++++++++++++++
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 31 +
arch/powerpc/sysdev/fsl_pci.c | 2 +
include/linux/pci_ids.h | 2 +
5 files changed, 1906 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc8572ds.dts
create mode 100644 arch/powerpc/configs/mpc8572_ds_defconfig
diff --git a/arch/powerpc/boot/dts/mpc8572ds.dts b/arch/powerpc/boot/dts/mpc8572ds.dts
new file mode 100644
index 0000000..c76e8d8
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8572ds.dts
@@ -0,0 +1,375 @@
+/*
+ * MPC8572 DS Device Tree Source
+ *
+ * Copyright 2007 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/ {
+ model = "fsl,MPC8572DS";
+ compatible = "fsl,MPC8572DS", "fsl,MPC85xxDS";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,8572@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <20>; // 32 bytes
+ i-cache-line-size = <20>; // 32 bytes
+ d-cache-size = <8000>; // L1, 32K
+ i-cache-size = <8000>; // L1, 32K
+ timebase-frequency = <0>;
+ bus-frequency = <0>;
+ clock-frequency = <0>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <00000000 00000000>; // Filled by U-Boot
+ };
+
+ soc8572@ffe00000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ device_type = "soc";
+ ranges = <00000000 ffe00000 00100000
+ 80000000 80000000 20000000
+ a0000000 a0000000 20000000
+ c0000000 c0000000 20000000
+ ffc00000 ffc00000 00010000
+ ffc10000 ffc10000 00010000
+ ffc20000 ffc20000 00010000>;
+
+ reg = <ffe00000 00001000>; // CCSRBAR & soc regs
+ bus-frequency = <0>; // Filled out by uboot.
+
+ memory-controller@2000 {
+ compatible = "fsl,8572-memory-controller";
+ reg = <2000 1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <12 2>;
+ };
+
+ l2-cache-controller@20000 {
+ compatible = "fsl,8572-l2-cache-controller";
+ reg = <20000 1000>;
+ cache-line-size = <20>; // 32 bytes
+ cache-size = <80000>; // L2, 512K
+ interrupt-parent = <&mpic>;
+ interrupts = <10 2>;
+ };
+
+ i2c@3000 {
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <3000 100>;
+ interrupts = <2b 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ };
+
+ mdio@24520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "mdio";
+ compatible = "gianfar";
+ reg = <24520 20>;
+ phy0: ethernet-phy@0 {
+ interrupt-parent = <&mpic>;
+ interrupts = <a 1>;
+ reg = <0>;
+ device_type = "ethernet-phy";
+ };
+ phy1: ethernet-phy@1 {
+ interrupt-parent = <&mpic>;
+ interrupts = <a 1>;
+ reg = <1>;
+ device_type = "ethernet-phy";
+ };
+ phy2: ethernet-phy@2 {
+ interrupt-parent = <&mpic>;
+ interrupts = <a 1>;
+ reg = <2>;
+ device_type = "ethernet-phy";
+ };
+ phy3: ethernet-phy@3 {
+ interrupt-parent = <&mpic>;
+ interrupts = <a 1>;
+ reg = <3>;
+ device_type = "ethernet-phy";
+ };
+ };
+
+ ethernet@24000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <24000 1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <1d 2 1e 2 22 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy0>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ ethernet@25000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <25000 1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <23 2 24 2 28 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy1>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ ethernet@26000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <26000 1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <1f 2 20 2 21 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy2>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ ethernet@27000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <27000 1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <25 2 26 2 27 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy3>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ serial@4500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <4500 100>;
+ clock-frequency = <0>;
+ interrupts = <2a 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ serial@4600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <4600 100>;
+ clock-frequency = <0>;
+ interrupts = <2a 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ pcie@8000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <8000 1000>;
+ bus-range = <0 ff>;
+ ranges = <02000000 0 80000000 80000000 0 20000000
+ 01000000 0 00000000 ffc00000 0 00010000>;
+ clock-frequency = <1fca055>;
+ interrupt-parent = <&mpic>;
+ interrupts = <18 2>;
+ interrupt-map-mask = <fb00 0 0 0>;
+ interrupt-map = <
+ /* IDSEL 0x11 - PCI slot 1 */
+ 8800 0 0 1 &mpic 2 1
+ 8800 0 0 2 &mpic 3 1
+ 8800 0 0 3 &mpic 4 1
+ 8800 0 0 4 &mpic 1 1
+
+ /* IDSEL 0x12 - PCI slot 2 */
+ 9000 0 0 1 &mpic 3 1
+ 9000 0 0 2 &mpic 4 1
+ 9000 0 0 3 &mpic 1 1
+ 9000 0 0 4 &mpic 2 1
+
+ // IDSEL 0x1c USB
+ e000 0 0 0 &i8259 c 2
+ e100 0 0 0 &i8259 9 2
+ e200 0 0 0 &i8259 a 2
+ e300 0 0 0 &i8259 b 2
+
+ // IDSEL 0x1d Audio
+ e800 0 0 0 &i8259 6 2
+
+ // IDSEL 0x1e Legacy
+ f000 0 0 0 &i8259 7 2
+ f100 0 0 0 &i8259 7 2
+
+ // IDSEL 0x1f IDE/SATA
+ f800 0 0 0 &i8259 e 2
+ f900 0 0 0 &i8259 5 2
+
+ >;
+ uli1575@0 {
+ reg = <0 0 0 0 0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ ranges = <02000000 0 80000000
+ 02000000 0 80000000
+ 0 20000000
+ 01000000 0 00000000
+ 01000000 0 00000000
+ 0 00100000>;
+
+ pci_bridge@0 {
+ reg = <0 0 0 0 0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ ranges = <02000000 0 80000000
+ 02000000 0 80000000
+ 0 20000000
+ 01000000 0 00000000
+ 01000000 0 00000000
+ 0 00100000>;
+
+ isa@1e {
+ device_type = "isa";
+ #interrupt-cells = <2>;
+ #size-cells = <1>;
+ #address-cells = <2>;
+ reg = <f000 0 0 0 0>;
+ ranges = <1 0 01000000 0 0
+ 00001000>;
+ interrupt-parent = <&i8259>;
+
+ i8259: interrupt-controller@20 {
+ reg = <1 20 2
+ 1 a0 2
+ 1 4d0 2>;
+ clock-frequency = <0>;
+ interrupt-controller;
+ device_type = "interrupt-controller";
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ built-in;
+ compatible = "chrp,iic";
+ interrupts = <9 2>;
+ interrupt-parent =
+ <&mpic>;
+ };
+
+ i8042@60 {
+ #size-cells = <0>;
+ #address-cells = <1>;
+ reg = <1 60 1 1 64 1>;
+ interrupts = <1 3 c 3>;
+ interrupt-parent =
+ <&i8259>;
+
+ keyboard@0 {
+ reg = <0>;
+ compatible = "pnpPNP,303";
+ };
+
+ mouse@1 {
+ reg = <1>;
+ compatible = "pnpPNP,f03";
+ };
+ };
+
+ rtc@70 {
+ compatible = "pnpPNP,b00";
+ reg = <1 70 2>;
+ };
+
+ gpio@400 {
+ reg = <1 400 80>;
+ };
+ };
+ };
+ };
+
+ };
+
+ pcie@9000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <9000 1000>;
+ bus-range = <0 ff>;
+ ranges = <02000000 0 a0000000 a0000000 0 20000000
+ 01000000 0 00000000 ffc10000 0 00010000>;
+ clock-frequency = <1fca055>;
+ interrupt-parent = <&mpic>;
+ interrupts = <1a 2>;
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 4 1
+ 0000 0 0 2 &mpic 5 1
+ 0000 0 0 3 &mpic 6 1
+ 0000 0 0 4 &mpic 7 1
+ >;
+ };
+
+ pcie@a000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <a000 1000>;
+ bus-range = <0 ff>;
+ ranges = <02000000 0 c0000000 c0000000 0 20000000
+ 01000000 0 00000000 ffc20000 0 00010000>;
+ clock-frequency = <1fca055>;
+ interrupt-parent = <&mpic>;
+ interrupts = <1b 2>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 0 1
+ 0000 0 0 2 &mpic 1 1
+ 0000 0 0 3 &mpic 2 1
+ 0000 0 0 4 &mpic 3 1
+ >;
+ };
+
+ global-utilities@e0000 { //global utilities block
+ compatible = "fsl,mpc8548-guts";
+ reg = <e0000 1000>;
+ fsl,has-rstcr;
+ };
+
+ mpic: pic@40000 {
+ clock-frequency = <0>;
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <40000 40000>;
+ compatible = "chrp,open-pic";
+ device_type = "open-pic";
+ big-endian;
+ };
+ };
+};
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 3a5c3c4..4d44902 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -181,6 +181,23 @@ static int __init mpc8544_ds_probe(void)
}
}
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init mpc8572_ds_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (of_flat_dt_is_compatible(root, "fsl,MPC8572DS")) {
+#ifdef CONFIG_PCI
+ primary_phb_addr = 0x8000;
+#endif
+ return 1;
+ } else {
+ return 0;
+ }
+}
+
define_machine(mpc8544_ds) {
.name = "MPC8544 DS",
.probe = mpc8544_ds_probe,
@@ -194,3 +211,17 @@ define_machine(mpc8544_ds) {
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
};
+
+define_machine(mpc8572_ds) {
+ .name = "MPC8572 DS",
+ .probe = mpc8572_ds_probe,
+ .setup_arch = mpc85xx_ds_setup_arch,
+ .init_IRQ = mpc85xx_ds_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+ .get_irq = mpic_get_irq,
+ .restart = mpc85xx_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 114c90f..34cad96 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -255,5 +255,7 @@ DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8533E, quirk_fsl_pcie_transpare
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8533, quirk_fsl_pcie_transparent);
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8544E, quirk_fsl_pcie_transparent);
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8544, quirk_fsl_pcie_transparent);
+DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8572E, quirk_fsl_pcie_transparent)
+DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8572, quirk_fsl_pcie_transparent);
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8641, quirk_fsl_pcie_transparent);
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8641D, quirk_fsl_pcie_transparent);
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 06d23e1..daedb60 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2100,6 +2100,8 @@
#define PCI_DEVICE_ID_MPC8533 0x0031
#define PCI_DEVICE_ID_MPC8544E 0x0032
#define PCI_DEVICE_ID_MPC8544 0x0033
+#define PCI_DEVICE_ID_MPC8572E 0x0040
+#define PCI_DEVICE_ID_MPC8572 0x0041
#define PCI_DEVICE_ID_MPC8641 0x7010
#define PCI_DEVICE_ID_MPC8641D 0x7011
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH 1/3] fsl_soc.c cleanup
From: Kumar Gala @ 2007-09-11 16:22 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <46E6B98C.1070207@freescale.com>
On Sep 11, 2007, at 10:51 AM, Scott Wood wrote:
> Kumar Gala wrote:
>> Yep. However, after some discussion with Segher on this for 83xx/
>> 85xx/86xx I think we want to keep the reg prop and have it cover
>> the initial soc registers [size on 83xx is 0x100, size on 85xx/
>> 86xx would be 0x1000].
>> What we need is a saner way to determine immr on 82xx & 8xx.
>> Segher's rule is that a given "reg" prop shouldn't overlap w/any
>> other reg. We currently violate that on 8xx. Not as clear on
>> 82xx if we do that.
>> I'm thinking on 8xx we should move to grabbing a top level compat
>> value (mpc8xx) and use the SPRN_IMMR to set immrbase.
>
> Any particular reason to special-case it, when we already need code
> to do it the other way for every other fsl soc?
If you suggest a sane way of getting the value let me know. The
mpc8xx doesn't appear to have what I would call 'soc' level registers
like 83xx/85xx/86xx does. How do you propose we determine the immrbase?
>> On mpc82xx-pq2 we could add a immr "device" to search for.
>
> Enh. The soc node *is* the immr "device". I'd rather add a node
> for the "initial" registers (they generally don't involve
> configuring the immr "bus" itself, but rather the chipselect bus
> and other miscellaneous things) if needed, get rid of /soc/reg, and
> have ranges cover the whole immr.
> And why is 82xx-pq2 special? Wouldn't you need this on 83xx, 85xx,
> and 86xx as well?
The range will cover the whole immr space on 83xx/85xx/86xx.
82xx-pq2 is special in that its soc regs are in the middle of the
immr address map.
- k
^ permalink raw reply
* Re: [PATCH 1/3] fsl_soc.c cleanup
From: Scott Wood @ 2007-09-11 16:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <B247D7AF-6AB9-4009-BFB8-0A365D3F0DF2@kernel.crashing.org>
Kumar Gala wrote:
> On Sep 11, 2007, at 10:51 AM, Scott Wood wrote:
>> Any particular reason to special-case it, when we already need code to
>> do it the other way for every other fsl soc?
>
> If you suggest a sane way of getting the value let me know. The mpc8xx
> doesn't appear to have what I would call 'soc' level registers like
> 83xx/85xx/86xx does. How do you propose we determine the immrbase?
What exactly do you mean by "soc"-level registers?
I propose we do it by defining the first (and ideally only, but that's
another argument) entry in ranges as the immr, and getting rid of /soc/reg.
>> And why is 82xx-pq2 special? Wouldn't you need this on 83xx, 85xx,
>> and 86xx as well?
>
> The range will cover the whole immr space on 83xx/85xx/86xx.
And why can't it do that on 82xx?
> 82xx-pq2 is special in that its soc regs are in the middle of the immr
> address map.
The /soc node is misnamed; it should really be /immr. Why do we need
these particular registers to be in /soc/reg rather than a subnode?
-Scott
^ permalink raw reply
* SOC registers/immr determination from device tree (was Re: [PATCH 1/3] fsl_soc.c cleanup)
From: Kumar Gala @ 2007-09-11 16:45 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <46E6C145.2050006@freescale.com>
On Sep 11, 2007, at 11:24 AM, Scott Wood wrote:
> Kumar Gala wrote:
>> On Sep 11, 2007, at 10:51 AM, Scott Wood wrote:
>>> Any particular reason to special-case it, when we already need
>>> code to do it the other way for every other fsl soc?
>> If you suggest a sane way of getting the value let me know. The
>> mpc8xx doesn't appear to have what I would call 'soc' level
>> registers like 83xx/85xx/86xx does. How do you propose we
>> determine the immrbase?
>
> What exactly do you mean by "soc"-level registers?
registers that effect the soc-processor core interaction/bus (things
like LAWs, CCSRBAR, etc).
> I propose we do it by defining the first (and ideally only, but
> that's another argument) entry in ranges as the immr, and getting
> rid of /soc/reg.
I disagree. I don't think we want to start overloading the meaning
of something like 'ranges' in that way.
>>> And why is 82xx-pq2 special? Wouldn't you need this on 83xx,
>>> 85xx, and 86xx as well?
>> The range will cover the whole immr space on 83xx/85xx/86xx.
>
> And why can't it do that on 82xx?
we can cover the whole range, thats fine. We just need a different
mechanism to determine immr base.
>> 82xx-pq2 is special in that its soc regs are in the middle of the
>> immr address map.
>
> The /soc node is misnamed; it should really be /immr. Why do we
> need these particular registers to be in /soc/reg rather than a
> subnode?
They could be in a sub node if there is a clear subnode for them to
be in.
- k
^ permalink raw reply
* Re: SOC registers/immr determination from device tree (was Re: [PATCH 1/3] fsl_soc.c cleanup)
From: Scott Wood @ 2007-09-11 17:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <D3BBD38C-B050-4694-8B38-EF9C75DD2D8F@kernel.crashing.org>
Kumar Gala wrote:
> On Sep 11, 2007, at 11:24 AM, Scott Wood wrote:
>> I propose we do it by defining the first (and ideally only, but
>> that's another argument) entry in ranges as the immr, and getting
>> rid of /soc/reg.
>
> I disagree.
I'm shocked. :-)
> I don't think we want to start overloading the meaning of something
> like 'ranges' in that way.
As opposed to overloading the meaning of 'reg'?
It's no different than how PCI ranges are treated -- we interpret, in a
bus-specific way, that certain ranges mean certain things. In the case
of fsl immr/cssr buses, the first range would mean the immr/cssr space.
>>>> And why is 82xx-pq2 special? Wouldn't you need this on 83xx,
>>>> 85xx, and 86xx as well?
>>> The range will cover the whole immr space on 83xx/85xx/86xx.
>>
>> And why can't it do that on 82xx?
>
> we can cover the whole range, thats fine. We just need a different
> mechanism to determine immr base.
I'm unconvinced.
>>> 82xx-pq2 is special in that its soc regs are in the middle of the
>>> immr address map.
>>
>> The /soc node is misnamed; it should really be /immr. Why do we
>> need these particular registers to be in /soc/reg rather than a
>> subnode?
>
> They could be in a sub node if there is a clear subnode for them to
> be in.
Does anything actually use /soc/reg as anything other than an input to
get_immrbase()? If not, we can defer defining such nodes until there's
actually a need.
It'd probably be more efficient to discuss this in person; can you stop
by my cube sometime when you're around and not in a meeting?
-Scott
^ permalink raw reply
* Re: SOC registers/immr determination from device tree (was Re: [PATCH 1/3] fsl_soc.c cleanup)
From: Josh Boyer @ 2007-09-11 17:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <46E6CA63.1040703@freescale.com>
On Tue, 11 Sep 2007 12:03:31 -0500
Scott Wood <scottwood@freescale.com> wrote:
>
> It'd probably be more efficient to discuss this in person; can you stop
> by my cube sometime when you're around and not in a meeting?
Please be sure to post a summary of the discussion if you do that so the
other people that care can at least see an end result.
josh
^ permalink raw reply
* Re: FDT for Microblaze and PPC405
From: Grant Likely @ 2007-09-11 17:09 UTC (permalink / raw)
To: Michal Simek, linuxppc-dev
In-Reply-To: <2057.3992-23959-31980099-1189527824@seznam.cz>
On 9/11/07, Michal Simek <Monstr@seznam.cz> wrote:
> Hi Grant,
(Adding linuxppc-dev mailing list to CC list because we're discussing
FDT issues)
> I made EDK repository file for generation dts file from Xilinx design. I sent it to Wolfgang and Steve this week.
> It is in the same config file as I use for configuration Microblaze for U-BOOT. If you want I can send you this repository files.
Yes, please do.
> And I start with redesigning Linux kernel for Microblaze. I ported some peripherals as timer and intc etc.
> But for some peripherals I need better configuration.
>
> I have no time to read information about fdt. Can you tell me what labels I can use?
Steve has already done a bunch of work in this direction on
microblaze, I would converse with him.
>
> For example emaclite driver needs information about turning on/off ping pong buffer...
>
> I would like to make this properly.
FDT design is just as much art as it is science. It takes taste and
judgement to desgin a nice set of bindings. Your best option is to
draft something and post it to the linuxppc-embedded mailing list for
review.
>
> And second question is on early console logs and timers setting. I read about aliases in FDT. I think that aliases can cover this setting.
> For example my design contain 4 serial line and I would like to know which serial line is set on early console.
You use the chosen node for this. In the chosen node, you add a
property called "linux,stdout-path" which holds the path to your
console. You can look at examples under arch/powerpc/boot/dts/*
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] [POWERPC] QE: simplify GUEMR register initialization
From: Timur Tabi @ 2007-09-11 17:09 UTC (permalink / raw)
To: linuxppc-dev, Paul Mackerras, Gala Kumar-B11780
In-Reply-To: <11895258991411-git-send-email-timur@freescale.com>
Paul and Kumar,
It turns out that I have a bunch more QE library code clean-up, so please
ignore this patch. I'll submit a more comprehensive one later this week.
Timur Tabi wrote:
> The initialization of the QE's GUEMR register is overly complicated, involving
> multiple functions and a redundant ucc_common structure. This patch removes
> struct ucc_common, merges ucc_init_guemr() into ucc_set_type() (every caller
> of ucc_init_guemr() also calls ucc_set_type() immediately afterward), and
> removes the unused enum ucc_pram_initial_offset.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Olof Johansson @ 2007-09-11 17:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <11B85E70-D643-4013-A9B3-59CD76F9D7AB@kernel.crashing.org>
On Tue, Sep 11, 2007 at 11:00:28AM -0500, Kumar Gala wrote:
>
> On Sep 11, 2007, at 10:55 AM, Olof Johansson wrote:
>
> > On Tue, Sep 11, 2007 at 10:50:18AM -0500, Kumar Gala wrote:
> >>> How different are these boards really? Could you just detect
> >>> MPC85xxDS
> >>> and have a generic platform for them, or are they different
> >>> enough that
> >>> you need individual ones for it?
> >>
> >> I wanted a different probe. I figured having a different struct
> >> was a
> >> simple solution.
> >
> > Seems like the only reason to need that is the setting of
> > primary_phb_addr. Can't that information be derived out of the device
> > tree instead? That'd avoid alot of code duplication (code that
> > includes
> > ifdefs, FWIW :-)
>
> well the ifdefs are orthogonal. We don't have a way of knowing
> primary from the device tree today.
How about something like "fsl,primary-phb" in the bus device node? I don't
know, maybe it's already been discussed and turned down for some reason.
Or would it be sufficient to check children of that device node to see
if the ULi is on that bus?
> > It just seems like a slippery slope. I'm not objecting directly to
> > this
> > patch, but I think it should be fixed for the longer term.
>
> Once we have a clean way of knowing primary PHB than I'm happy to fixup.
-Olof
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix interrupt routing and setup of ULI M1575 on FSL boards
From: Olof Johansson @ 2007-09-11 17:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <Pine.LNX.4.64.0708170003210.21006@blarg.am.freescale.net>
On Fri, Aug 17, 2007 at 12:03:48AM -0500, Kumar Gala wrote:
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/boot/dts/mpc8544ds.dts | 88 ++++------
> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 114 +++----------
> arch/powerpc/platforms/85xx/Kconfig | 1 +
> arch/powerpc/platforms/85xx/mpc8544_ds.c | 214 ++----------------------
> arch/powerpc/platforms/86xx/Kconfig | 1 +
> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 224 ++-----------------------
> arch/powerpc/platforms/Kconfig | 8 +
> arch/powerpc/platforms/Makefile | 3 +
> arch/powerpc/platforms/fsl_uli1575.c | 255 ++++++++++++++++++++++++++++
> 9 files changed, 363 insertions(+), 545 deletions(-)
> create mode 100644 arch/powerpc/platforms/fsl_uli1575.c
>
Since when do we add code directly under powerpc/platforms? Isn't that
what we have sysdev for?
I know this is already picked up, but I just noticed it when looking at
Kumar's 8572 patch. :-(
-Olof
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Scott Wood @ 2007-09-11 17:21 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20070911171521.GB10743@lixom.net>
Olof Johansson wrote:
> On Tue, Sep 11, 2007 at 11:00:28AM -0500, Kumar Gala wrote:
>> well the ifdefs are orthogonal. We don't have a way of knowing
>> primary from the device tree today.
>
> How about something like "fsl,primary-phb" in the bus device node? I don't
> know, maybe it's already been discussed and turned down for some reason.
It's more of a Linux issue than anything to do with the hardware.
> Or would it be sufficient to check children of that device node to see
> if the ULi is on that bus?
Or more generally, see if an isa node is somewhere in that subtree.
-Scott
^ permalink raw reply
* Re: PCI target implementation on AMCC PPC CPUs
From: David Hawkins @ 2007-09-11 17:32 UTC (permalink / raw)
To: Matthias Fuchs; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <200709111113.46508.matthias.fuchs@esd-electronics.com>
Hi Matthias,
> we build a couple of PCI target designs using AMCC PowerPCs.
> You are right that some things could be better. But ..
>
> On Thursday 06 September 2007 22:26, David Hawkins wrote:
>> There are several fundamental problems with the AMCC 440EP
>> acting as a PCI target/slave;
>>
>> 2. Look in the data sheet and see if you can figure out
>> how the host processor can generate an interrupt to
>> the PowerPC core ... oops, you can't. That kind of
>> makes it difficult to work with doesn't it.
>
> You CAN! You can generate an interrupt to the PowerPC from the host
> CPU bei writing to the PCI command register. You have to read the user manual
> carefully. Perhaps it not that obvious.
Really!? Someone should tell AMCC tech support then.
When I failed to find a method (other than hooking up
an external GPIO), I contacted them and they came to
the same conclusion (on the 440EP anyway).
I'll look in the latest user manual to be sure ...
PPC440EP_UM2000_v1_23.pdf
p394 has their 'cheesy' implementation of PCI INTA# control;
toggle a single bit.
Then backing up a little, p388 has the PCI command register ...
Nope, no comment there that a write causes an interrupt to
the PowerPC core.
Ok, so going back to the UIC in Chapter 10, p224.
Ah-ha, PCI CMD write generates an interrupt 5!
So, I stand corrected; the host can generate an interrupt to
the PowerPC core, and the method is 'cheesier' than the PCI
INTA# control.
And my experience with AMCC's tech support is now a notch
lower, as even they did not offer this as a solution :)
I sure am glad I changed to a Freescale processor ;)
Cheers,
Dave
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Olof Johansson @ 2007-09-11 17:33 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <46E6CE9A.8080402@freescale.com>
On Tue, Sep 11, 2007 at 12:21:30PM -0500, Scott Wood wrote:
> Olof Johansson wrote:
> > On Tue, Sep 11, 2007 at 11:00:28AM -0500, Kumar Gala wrote:
> >> well the ifdefs are orthogonal. We don't have a way of knowing
> >> primary from the device tree today.
> >
> > How about something like "fsl,primary-phb" in the bus device node? I don't
> > know, maybe it's already been discussed and turned down for some reason.
>
> It's more of a Linux issue than anything to do with the hardware.
That doesn't stop firmware from telling linux which bus is the primary
one on the system to help out.
> > Or would it be sufficient to check children of that device node to see
> > if the ULi is on that bus?
>
> Or more generally, see if an isa node is somewhere in that subtree.
-Olof
^ permalink raw reply
* Re: [PATCH] [POWERPC] QE: simplify GUEMR register initialization
From: Kumar Gala @ 2007-09-11 17:47 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <46E6CBB9.90008@freescale.com>
On Sep 11, 2007, at 12:09 PM, Timur Tabi wrote:
> Paul and Kumar,
>
> It turns out that I have a bunch more QE library code clean-up, so
> please ignore this patch. I'll submit a more comprehensive one
> later this week.
>
> Timur Tabi wrote:
>> The initialization of the QE's GUEMR register is overly
>> complicated, involving
>> multiple functions and a redundant ucc_common structure. This
>> patch removes
>> struct ucc_common, merges ucc_init_guemr() into ucc_set_type()
>> (every caller
>> of ucc_init_guemr() also calls ucc_set_type() immediately
>> afterward), and
>> removes the unused enum ucc_pram_initial_offset.
ok
- k
^ 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