* Re: [spi-devel-general] [PATCH 2/3] [SPI] Add new mode: SPI_LOOP
From: David Brownell @ 2007-08-01 18:25 UTC (permalink / raw)
To: spi-devel-general; +Cc: Ned Forrester, linuxppc-dev, Stephen Street
In-Reply-To: <46A967D5.30606@whoi.edu>
On Thursday 26 July 2007, Ned Forrester wrote:
> David Brownell wrote:
> > On Thursday 26 July 2007, Anton Vorontsov wrote:
> >> Loopback mode is supported by various controllers, this mode
> >> is useful for testing, especially in conjunction with spidev
> >> driver.
> >
> > ISTR that Stephen Street provided a loopback mode for debug
> > in his pxa2xx_spi code. And I know you're fight that this
> > mode shows up in a lot of hardware.
> >
> > Comments, anyone? This seems like a fair way to expose this
> > mechanism. And I tend to agree that it'd mostly be useful in
> > conjunction with "spidev".
>
> Yes, it is in pxa2xx_spi. It is passed in a structure that is attached
> to spi_board_info.controller_data. I have used it to great effect to
> test data modes in the driver for which I have no external hardware
> support: various bits/word, clock frequencies, fifo thresholds, dma
> burst sizes, etc.
Well, the SPI_LOOP stuff is now in kernel.org GIT and 2.6.23-rc2,
so if someone wants to update pxa2xx_spi to support this through
spi->mode instead of controller data, now is a good time to start
working on that.
- Dave
^ permalink raw reply
* Re: GPIO interrupts on mpc8313e
From: Scott Wood @ 2007-08-01 18:36 UTC (permalink / raw)
To: Yoni Levin; +Cc: linuxppc-embedded
In-Reply-To: <2C4FDB8D627248AE9B24BC21747E0F5D.MAI@mail.livedns.co.il>
On Wed, Aug 01, 2007 at 02:45:05PM +0300, Yoni Levin wrote:
> request_irq(74,handler,IRQF_DISABLED,"GPIO",NULL);
^^^^^^^^^^^^^
Did you try removing that flag (or calling enable_irq())?
-Scott
^ permalink raw reply
* Re: [RFC][PATCH] MPC832x_RDB: update dts to use spi, register mmc_spi stub
From: Scott Wood @ 2007-08-01 17:43 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <dfa3ff8d8c6af28003c7f9f831371358@kernel.crashing.org>
Segher Boessenkool wrote:
> For some buses, there is a "slot-names" property; some (non-core)
> bindings seem to define a "location" property.
>
> For "random" human-readable labelling, i.e. not corresponding to
> physical markings on the hardware, I recommend you look for a
> matching entry in /aliases.
Aliases could work, but are awkward to use for the purposes I'm thinking
of (giving the OS a name to present to the user in association with a
device). They're more suited to interactive OF use where the device
tree is being directly referenced by the user.
Plus, you're then restricted to valid property names for the alias,
whereas with a label property you could use any string, including spaces
and such.
> It won't ever be _exactly_ what you
> want though, the Linux device namespace is separate from the
> device tree.
That's Linux's choice. Nothing stops it from showing device tree labels
to the user in various situations -- what got me thinking about this
was that apparently ALSA lets the driver pass an arbitrary string to
identify the device, and it seemed that such a device-tree-derived label
would be the most useful to the user. To use aliases for that, it'd
have to get the full path to the audio node, compare it to each alias,
and hope it finds one and only one, and that that alias was intended to
be a user label and not something else.
-Scott
^ permalink raw reply
* Re: [PATCH] Add support for Wind River SBC8641D board
From: Kumar Gala @ 2007-08-01 17:39 UTC (permalink / raw)
To: joe.hamman; +Cc: linuxppc-embedded
In-Reply-To: <002901c7d44b$bc5b6350$6e00a8c0@ESIDT>
On Aug 1, 2007, at 9:53 AM, Joe Hamman wrote:
> Sorry, I replied to only the first question.
>
>
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Wednesday, August 01, 2007 9:18 AM
>> To: joe.hamman@embeddedspecialties.com
>> Cc: linuxppc-embedded@ozlabs.org
>> Subject: Re: [PATCH] Add support for Wind River SBC8641D board
>>
>>
>> On Jul 31, 2007, at 7:36 PM, Joe Hamman wrote:
>>
>>> Add support for Wind River's SBC8641D reference board.
>>
>> Is this a single core or dual core chip?
>>
>
> The board I have is single core. I would have to see if I could
> get access
> to a dual core board.
You may want to think about having both core's in the .dts and build
with !CONFIG_SMP for single and CONFIG_SMP for dual.
>>> +void
>>> +sbc8641d_show_cpuinfo(struct seq_file *m)
>>> +{
>>> + struct device_node *root;
>>> + uint memsize = total_memory;
>>> + const char *model = "";
>>> + uint svid = mfspr(SPRN_SVR);
>>> +
>>> + seq_printf(m, "Vendor\t\t: Wind River Systems\n");
>>> +
>>> + root = of_find_node_by_path("/");
>>> + if (root)
>>> + model = get_property(root, "model", NULL);
>>> + seq_printf(m, "Machine\t\t: %s\n", model);
>>> + of_node_put(root);
>>> +
>>> + seq_printf(m, "SVR\t\t: 0x%x\n", svid);
>>> + seq_printf(m, "Memory\t\t: %d MB\n", memsize / (1024 * 1024));
>>> +}
>>> +
>>
>> This is mostly redundant with the basic show cpu info, do you need
>> your own?
>
> The plan is to add code to read the EEPROM device and show more info.
Ok thats fine than.
>>> +
>>> +/*
>>> + * Called very early, device-tree isn't unflattened
>>> + */
>>> +static int __init sbc8641d_probe(void)
>>> +{
>>> + unsigned long root = of_get_flat_dt_root();
>>> +
>>> + if (of_flat_dt_is_compatible(root, "mpc86xx"))
>>> + return 1; /* Looks good */
>>
>> the check you have is too generic, you probably need something more
>> specific in the top level compatible property.
>
> Will do.
>
>>
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +
>>> +void
>>> +sbc8641d_restart(char *cmd)
>>> +{
>>> + void __iomem *rstcr;
>>> +
>>> + rstcr = ioremap(get_immrbase() + MPC86XX_RSTCR_OFFSET, 0x100);
>>> +
>>> + local_irq_disable();
>>> +
>>> + /* Assert reset request to Reset Control Register */
>>> + out_be32(rstcr, 0x2);
>>> +
>>> + /* not reached */
>>> +}
>>> +
>>> +
>>> +long __init
>>> +sbc8641d_time_init(void)
>>> +{
>>> + unsigned int temp;
>>> +
>>> + /* Set the time base to zero */
>>> + mtspr(SPRN_TBWL, 0);
>>> + mtspr(SPRN_TBWU, 0);
>>> +
>>> + temp = mfspr(SPRN_HID0);
>>> + temp |= HID0_TBEN;
>>> + mtspr(SPRN_HID0, temp);
>>> + asm volatile("isync");
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +
>>> +define_machine(sbc8641d) {
>>> + .name = "SBC8641D",
>>> + .probe = sbc8641d_probe,
>>> + .setup_arch = sbc8641d_setup_arch,
>>> + .init_IRQ = sbc8641d_init_irq,
>>> + .show_cpuinfo = sbc8641d_show_cpuinfo,
>>> + .get_irq = mpic_get_irq,
>>> + .restart = sbc8641d_restart,
>>> + .time_init = sbc8641d_time_init,
>>> + .calibrate_decr = generic_calibrate_decr,
>>> + .progress = udbg_progress,
>>> +
>>> +#ifdef CONFIG_GEN_RTC
>>> + /* RTC interface, using functions in include/asm-generic/rtc.h */
>>> + .get_rtc_time = get_rtc_time,
>>> + .set_rtc_time = set_rtc_time,
>>> +#endif
>>> +};
Noticed you didn't have an PCIe support. Is that something that
exists on the board? is wired to anything?
>>> diff -purN -X dontdiff linux-2.6/drivers/net/gianfar.h linux-2.6-
>>> esi/drivers/net/gianfar.h
>>> --- linux-2.6/drivers/net/gianfar.h 2007-07-31 10:15:39.000000000
>>> -0500
>>> +++ linux-2.6-esi/drivers/net/gianfar.h 2007-07-31
>>> 10:39:10.000000000 -0500
>>> @@ -131,7 +131,7 @@ extern const char gfar_driver_version[];
>>> #define DEFAULT_RXCOUNT 16
>>> #define DEFAULT_RXTIME 4
>>>
>>> -#define TBIPA_VALUE 0x1f
>>> +#define TBIPA_VALUE 0x1e
>>
>> we need to turn this into a config option or something.
>
> I was a little concerned when I saw a hard-coded address. I never
> would
> have found the conflict with the QUAD PHY (it starts at 0x1f and
> increments
> for each device) without your help.
>
> Let me know what you think and I'll put something together.
I'll talk to someone here and see. I think a simple thing would be
to make it a Kconfig'ble option to what the value is for TBIPA_VALUE
and default to 0x1f but changeable in your defconfig.
>>> #define MIIMCFG_INIT_VALUE 0x00000007
>>> #define MIIMCFG_RESET 0x80000000
>>> #define MIIMIND_BUSY 0x00000001
>>>
^ permalink raw reply
* Re: build error on powerpc for 2.6.23-rc1-mm2
From: Andrew Morton @ 2007-08-01 16:44 UTC (permalink / raw)
To: Rishikesh K Rajak; +Cc: Olof Johansson, linuxppc-dev, linux-kernel
In-Reply-To: <OFFC0F3DEC.2DEDE1A8-ON6525732A.002DB5E7-6525732A.002DEF2C@in.ibm.com>
On Wed, 1 Aug 2007 13:52:05 +0530 Rishikesh K Rajak <risrajak@in.ibm.com> wrote:
>
> Hi Andrew,
>
> I am getting following error on powerpc almost for allyesconfig,
> allmodconfig.
>
> Error produced:
>
> PowerPC: allmodconfig,allyesconfig
>
> CC arch/powerpc/mm/tlb_64.o
> /home/risrajak/TEST2/TEST/linux/CurrentTest/23-rc1-mm2-testing/linux-2.6.23-rc1/arch/powerpc/lib/copyuser_64.S:
> Assembler messages:
> /home/risrajak/TEST2/TEST/linux/CurrentTest/23-rc1-mm2-testing/linux-2.6.23-rc1/arch/powerpc/lib/copyuser_64.S:27:
> Error: Unrecognized opcode: `mtocrf'
> /home/risrajak/TEST2/TEST/linux/CurrentTest/23-rc1-mm2-testing/linux-2.6.23-rc1/arch/powerpc/lib/copyuser_64.S:138:
> Error: Unrecognized opcode: `mtocrf'
> /home/risrajak/TEST2/TEST/linux/CurrentTest/23-rc1-mm2-testing/linux-2.6.23-rc1/arch/powerpc/lib/copyuser_64.S:153:
> Error: Unrecognized opcode: `mtocrf'
> /home/risrajak/TEST2/TEST/linux/CurrentTest/23-rc1-mm2-testing/linux-2.6.23-rc1/arch/powerpc/lib/memcpy_64.S:
> Assembler messages:
> /home/risrajak/TEST2/TEST/linux/CurrentTest/23-rc1-mm2-testing/linux-2.6.23-rc1/arch/powerpc/lib/memcpy_64.S:15:
> Error: Unrecognized opcode: `mtocrf'
> /home/risrajak/TEST2/TEST/linux/CurrentTest/23-rc1-mm2-testing/linux-2.6.23-rc1/arch/powerpc/lib/memcpy_64.S:131:
> Error: Unrecognized opcode: `mtocrf'
> /home/risrajak/TEST2/TEST/linux/CurrentTest/23-rc1-mm2-testing/linux-2.6.23-rc1/arch/powerpc/lib/memcpy_64.S:146:
> Error: Unrecognized opcode: `mtocrf'
> make[2]: *** [arch/powerpc/lib/memcpy_64.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> CC arch/powerpc/sysdev/mpic_u3msi.o
> make[2]: *** [arch/powerpc/lib/copyuser_64.o] Error 1
> make[1]: *** [arch/powerpc/lib] Error 2
>
Presumably, disabling CONFIG_POWER4_ONLY would fix that.
It could be that your toolchain is insufficiently recent. Which
version of binutils are you using?
^ permalink raw reply
* Re: 2.6.23-rc1-mm2
From: Greg KH @ 2007-08-01 16:36 UTC (permalink / raw)
To: Mariusz Kozlowski
Cc: linuxppc-dev, Andrew Morton, paulus, linux-kernel,
linux-usb-devel
In-Reply-To: <200708011002.30962.m.kozlowski@tuxland.pl>
On Wed, Aug 01, 2007 at 10:02:30AM +0200, Mariusz Kozlowski wrote:
> Then reattaching a usb mouse caused this (only once)
>
> usb 2-1: USB disconnect, address 2
> BUG: atomic counter underflow at:
> [<c010456a>] show_trace_log_lvl+0x1a/0x30
> [<c010508d>] show_trace+0x12/0x14
> [<c01051e0>] dump_stack+0x15/0x17
> [<c01418cf>] __free_pages+0x50/0x52
> [<c01418f0>] free_pages+0x1f/0x21
> [<c010783d>] dma_free_coherent+0x43/0x9c
> [<c0315067>] hcd_buffer_free+0x43/0x6a
> [<c030b2b4>] usb_buffer_free+0x23/0x29
> [<c0346db4>] hid_free_buffers+0x23/0x71
> [<c0346eb2>] hid_disconnect+0xb0/0xc8
> [<c0313676>] usb_unbind_interface+0x30/0x72
> [<c02c6df0>] __device_release_driver+0x6a/0x92
> [<c02c71c3>] device_release_driver+0x20/0x36
> [<c02c6736>] bus_remove_device+0x62/0x85
> [<c02c49f8>] device_del+0x16d/0x27c
> [<c0310f25>] usb_disable_device+0x7a/0xe2
> [<c030d0bc>] usb_disconnect+0x94/0xde
> [<c030e030>] hub_thread+0x2fe/0xc1b
> [<c0128aee>] kthread+0x36/0x58
> [<c0104233>] kernel_thread_helper+0x7/0x14
> =======================
> uhci_hcd 0000:00:0c.0: dma_pool_free buffer-32, 6b6b6b6b/6b6b6b6b (bad dma)
>
> Every new try shows:
>
> usb 2-1: new low speed USB device using uhci_hcd and address 3
> usb 2-1: new device found, idVendor=046d, idProduct=c00e
> usb 2-1: new device strings: Mfr=1, Product=2, SerialNumber=0
> usb 2-1: Product: USB-PS/2 Optical Mouse
> usb 2-1: Manufacturer: Logitech
> usb 2-1: configuration #1 chosen from 1 choice
> input: Logitech USB-PS/2 Optical Mouse as /class/input/input9
> input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:0c.0-1
> usb 2-1: USB disconnect, address 3
> uhci_hcd 0000:00:0c.0: dma_pool_free buffer-32, 6b6b6b6b/6b6b6b6b (bad dma)
>
> But mouse works ok.
Can you see if the patch posted by Jiri fixes this or not?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] mark PCI resource with start 0 as unassigned
From: Alan Cox @ 2007-08-01 15:51 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-ide, Olaf Hering, linuxppc-dev
In-Reply-To: <46B0972C.3020000@ru.mvista.com>
On Wed, 01 Aug 2007 18:22:36 +0400
Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:
> Segher Boessenkool wrote:
>
> >> setup-pci is for SFF8038i devices. It therefore knows that for assigned
> >> resources they must be I/O. It also assumes that zero is not a valid I/O
> >> port just like zero is not a valid IRQ. Stick a real IDE resource at
> >> zero and drivers/ide can't cope.
>
> > 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.
Alan
^ permalink raw reply
* [PATCH] Replace a few #defines with empty inline functions
From: Segher Boessenkool @ 2007-08-01 15:41 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <11859828781513-git-send-email-segher@kernel.crashing.org>
...so that GCC doesn't complain about unused variables in the
callers of these.
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
---
include/asm-powerpc/dma-mapping.h | 24 ++++++++++++++++++------
1 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/include/asm-powerpc/dma-mapping.h b/include/asm-powerpc/dma-mapping.h
index f6bd804..22b3c40 100644
--- a/include/asm-powerpc/dma-mapping.h
+++ b/include/asm-powerpc/dma-mapping.h
@@ -249,8 +249,12 @@ dma_map_single(struct device *dev, void *ptr, size_t size,
return virt_to_bus(ptr);
}
-/* We do nothing. */
-#define dma_unmap_single(dev, addr, size, dir) ((void)0)
+static inline void dma_unmap_single(struct device *dev, dma_addr_t dma_addr,
+ size_t size,
+ enum dma_data_direction direction)
+{
+ /* We do nothing. */
+}
static inline dma_addr_t
dma_map_page(struct device *dev, struct page *page,
@@ -264,8 +268,12 @@ dma_map_page(struct device *dev, struct page *page,
return page_to_bus(page) + offset;
}
-/* We do nothing. */
-#define dma_unmap_page(dev, handle, size, dir) ((void)0)
+static inline void dma_unmap_page(struct device *dev, dma_addr_t dma_address,
+ size_t size,
+ enum dma_data_direction direction)
+{
+ /* We do nothing. */
+}
static inline int
dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
@@ -284,8 +292,12 @@ dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
return nents;
}
-/* We don't do anything here. */
-#define dma_unmap_sg(dev, sg, nents, dir) ((void)0)
+static inline void dma_unmap_sg(struct device *dev, struct scatterlist *sg,
+ int nhwentries,
+ enum dma_data_direction direction)
+{
+ /* We don't do anything here. */
+}
#endif /* CONFIG_PPC64 */
--
1.5.2.1.144.gabc40-dirty
^ permalink raw reply related
* [PATCH] ide/ppc/pmac: Remove a few unused variables
From: Segher Boessenkool @ 2007-08-01 15:41 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <11859828792347-git-send-email-segher@kernel.crashing.org>
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
---
drivers/ide/ppc/pmac.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/ide/ppc/pmac.c b/drivers/ide/ppc/pmac.c
index 33630ad..0f5a6b4 100644
--- a/drivers/ide/ppc/pmac.c
+++ b/drivers/ide/ppc/pmac.c
@@ -1810,9 +1810,7 @@ pmac_ide_dma_check(ide_drive_t *drive)
{
struct hd_driveid *id = drive->id;
ide_hwif_t *hwif = HWIF(drive);
- pmac_ide_hwif_t* pmif = (pmac_ide_hwif_t *)hwif->hwif_data;
int enable = 1;
- int map;
drive->using_dma = 0;
if (drive->media == ide_floppy)
--
1.5.2.1.144.gabc40-dirty
^ permalink raw reply related
* [PATCH] Fix a compile warning in powermac/feature.c
From: Segher Boessenkool @ 2007-08-01 15:41 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <11859828761541-git-send-email-segher@kernel.crashing.org>
...by using the pci_get API instead of the deprecated old stuff.
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
---
arch/powerpc/platforms/powermac/feature.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/feature.c b/arch/powerpc/platforms/powermac/feature.c
index f29705f..ba931be 100644
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -826,13 +826,15 @@ core99_ata100_enable(struct device_node *node, long value)
if (value) {
if (pci_device_from_OF_node(node, &pbus, &pid) == 0)
- pdev = pci_find_slot(pbus, pid);
+ pdev = pci_get_bus_and_slot(pbus, pid);
if (pdev == NULL)
return 0;
rc = pci_enable_device(pdev);
+ if (rc == 0)
+ pci_set_master(pdev);
+ pci_dev_put(pdev);
if (rc)
return rc;
- pci_set_master(pdev);
}
return 0;
}
--
1.5.2.1.144.gabc40-dirty
^ permalink raw reply related
* [PATCH] Fix a compile warning in pci_32.c
From: Segher Boessenkool @ 2007-08-01 15:41 UTC (permalink / raw)
To: linuxppc-dev
__must_check, so do so.
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
---
arch/powerpc/kernel/pci_32.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index cd35c96..04a3109 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -581,8 +581,11 @@ pcibios_assign_resources(void)
if ((r->flags & IORESOURCE_UNSET) && r->end &&
(!ppc_md.pcibios_enable_device_hook ||
!ppc_md.pcibios_enable_device_hook(dev, 1))) {
+ int rc;
+
r->flags &= ~IORESOURCE_UNSET;
- pci_assign_resource(dev, idx);
+ rc = pci_assign_resource(dev, idx);
+ BUG_ON(rc);
}
}
--
1.5.2.1.144.gabc40-dirty
^ permalink raw reply related
* Re: GPIO interrupts on mpc8313e
From: Florian A. Voegel @ 2007-08-01 16:26 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <2C4FDB8D627248AE9B24BC21747E0F5D.MAI@mail.livedns.co.il>
Is the interrupt configured properly for whatever it is you connect to it? (level vs edge triggered, rising vs falling)
Best regards,
Florian
On Wed, 1 Aug 2007 14:45:05 +0300
"Yoni Levin" <yoni.l@slyde-tech.com> wrote:
>
>
> I want to receive interrupt from 1 GPIO port (for example 14)
>
> I changed the GPIMR to 0xffffffff (so I need to get interrupts from all GPIO
> ports)
>
> And then request the irq by :
>
> irq_create_mapping(NULL,74);
>
> request_irq(74,handler,IRQF_DISABLED,"GPIO",NULL);
>
> the return value is 0 (OK)
>
> but I cant receive any interrupt.
>
> do I need to do something else?
>
>
>
>
>
>
^ permalink raw reply
* RE: [PATCH] Add support for Wind River SBC8641D board
From: Joe Hamman @ 2007-08-01 14:53 UTC (permalink / raw)
To: 'Kumar Gala'; +Cc: linuxppc-embedded
In-Reply-To: <EFF6CD19-4700-41CD-843F-9AF818F7DB82@kernel.crashing.org>
Sorry, I replied to only the first question.
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Wednesday, August 01, 2007 9:18 AM
> To: joe.hamman@embeddedspecialties.com
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: [PATCH] Add support for Wind River SBC8641D board
>
>
> On Jul 31, 2007, at 7:36 PM, Joe Hamman wrote:
>
> > Add support for Wind River's SBC8641D reference board.
>
> Is this a single core or dual core chip?
>
The board I have is single core. I would have to see if I could get access
to a dual core board.
> >
> > Signed-off by: Joe Hamman <joe.hamman@embeddedspecialties.com>
> >
> > diff -purN -X dontdiff linux-2.6/arch/powerpc/boot/dts/sbc8641d.dts
> > linux-2.6-esi/arch/powerpc/boot/dts/sbc8641d.dts
> > --- linux-2.6/arch/powerpc/boot/dts/sbc8641d.dts 1969-12-31
> > 18:00:00.000000000 -0600
> > +++ linux-2.6-esi/arch/powerpc/boot/dts/sbc8641d.dts 2007-07-31
> > 13:15:15.000000000 -0500
> > @@ -0,0 +1,160 @@
> > +/*
> > + * SBC8641D Device Tree Source
> > + *
> > + * Copyright 2007 Embedded Specialties, Inc.
> > + * Joe Hamman joe.hamman@embeddedspecialties.com
> > + *
> > + * Copyright 2006 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 = "SBC8641D";
> > + compatible = "mpc86xx";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + PowerPC,8641@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>; // 33 MHz, from
uboot
> > + bus-frequency = <0>; // From uboot
> > + clock-frequency = <0>; // From uboot
> > + 32-bit;
> > + };
>
> if this is really an 8641D I'd expect a 2nd cpu node.
>
> > + };
> > +
> > + memory {
> > + device_type = "memory";
> > + reg = <00000000 20000000>; // 512M at 0x0
> > + };
> > +
> > + soc8641@f8000000 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + #interrupt-cells = <2>;
> > + device_type = "soc";
> > + ranges = <0 f8000000 00100000>;
> > + reg = <f8000000 00100000>; // CCSRBAR 1M
> > + bus-frequency = <0>;
> > +
> > + mdio@24520 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "mdio";
> > + compatible = "gianfar";
> > + reg = <24520 20>;
> > + phy1f: ethernet-phy@1f {
> > + reg = <1f>;
> > + device_type = "ethernet-phy";
> > + };
> > + phy0: ethernet-phy@0 {
> > + reg = <0>;
> > + device_type = "ethernet-phy";
> > + };
> > + phy1: ethernet-phy@1 {
> > + reg = <1>;
> > + device_type = "ethernet-phy";
> > + };
> > + phy2: ethernet-phy@2 {
> > + reg = <2>;
> > + device_type = "ethernet-phy";
> > + };
> > + };
> > +
> > + ethernet@24000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "network";
> > + model = "eTSEC";
> > + compatible = "gianfar";
> > + reg = <24000 1000>;
> > + mac-address = [ 00 E0 0C 00 73 00 ];
>
>
> > + interrupts = <1d 2 1e 2 22 2>;
> > + interrupt-parent = <&mpic>;
> > + phy-handle = <&phy1f>;
> > + };
> > +
> > + ethernet@25000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "network";
> > + model = "eTSEC";
> > + compatible = "gianfar";
> > + reg = <25000 1000>;
> > + mac-address = [ 00 E0 0C 00 73 01 ];
> > + interrupts = <23 2 24 2 28 2>;
> > + interrupt-parent = <&mpic>;
> > + phy-handle = <&phy0>;
> > + };
> > +
> > + ethernet@26000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "network";
> > + model = "eTSEC";
> > + compatible = "gianfar";
> > + reg = <26000 1000>;
> > + mac-address = [ 00 E0 0C 00 02 FD ];
> > + interrupts = <1F 2 20 2 21 2>;
> > + interrupt-parent = <&mpic>;
> > + phy-handle = <&phy1>;
> > + };
> > +
> > + ethernet@27000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "network";
> > + model = "eTSEC";
> > + compatible = "gianfar";
> > + reg = <27000 1000>;
> > + mac-address = [ 00 E0 0C 00 03 FD ];
> > + interrupts = <25 2 26 2 27 2>;
> > + interrupt-parent = <&mpic>;
> > + phy-handle = <&phy2>;
> > + };
> > +
> > + 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 = <1c 2>;
> > + interrupt-parent = <&mpic>;
> > + };
> > +
> > + 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;
> > + };
> > + };
> > +};
>
> [snip]
>
> > diff -purN -X dontdiff linux-2.6/arch/powerpc/platforms/86xx/
> > Kconfig linux-2.6-esi/arch/powerpc/platforms/86xx/Kconfig
> > --- linux-2.6/arch/powerpc/platforms/86xx/Kconfig 2007-07-31
> > 10:15:36.000000000 -0500
> > +++ linux-2.6-esi/arch/powerpc/platforms/86xx/Kconfig 2007-07-31
> > 10:36:45.000000000 -0500
> > @@ -10,6 +10,12 @@ config MPC8641_HPCN
> > help
> > This option enables support for the MPC8641 HPCN board.
> >
> > +config SBC8641D
> > + bool "Wind River SBC8641D"
> > + select DEFAULT_UIMAGE
> > + help
> > + This option enables support for the SBC8641D board.
> > +
> > endchoice
> >
> > config MPC8641
> > @@ -18,3 +24,4 @@ config MPC8641
> > select PPC_UDBG_16550
> > select MPIC
> > default y if MPC8641_HPCN
> > + default y if SBC8641D
> > diff -purN -X dontdiff linux-2.6/arch/powerpc/platforms/86xx/
> > Makefile linux-2.6-esi/arch/powerpc/platforms/86xx/Makefile
> > --- linux-2.6/arch/powerpc/platforms/86xx/Makefile 2007-07-31
> > 10:15:36.000000000 -0500
> > +++ linux-2.6-esi/arch/powerpc/platforms/86xx/Makefile 2007-07-31
> > 10:37:30.000000000 -0500
> > @@ -4,3 +4,4 @@
> >
> > obj-$(CONFIG_SMP) += mpc86xx_smp.o
> > obj-$(CONFIG_MPC8641_HPCN) += mpc86xx_hpcn.o
> > +obj-$(CONFIG_SBC8641D) += sbc8641d.o
> > diff -purN -X dontdiff linux-2.6/arch/powerpc/platforms/86xx/
> > sbc8641d.c linux-2.6-esi/arch/powerpc/platforms/86xx/sbc8641d.c
> > --- linux-2.6/arch/powerpc/platforms/86xx/sbc8641d.c 1969-12-31
> > 18:00:00.000000000 -0600
> > +++ linux-2.6-esi/arch/powerpc/platforms/86xx/sbc8641d.c 2007-07-31
> > 15:55:59.000000000 -0500
> > @@ -0,0 +1,206 @@
> > +/*
> > + * SBC8641D board specific routines
> > + *
> > + * Copyright 2007 Embedded Specialties, Inc.
> > + * Joe Hamman <joe.hamman@embeddedspecialties.com>
> > + *
> > + * Recode: ZHANG WEI <wei.zhang@freescale.com>
> > + * Initial author: Xianghua Xiao <x.xiao@freescale.com>
> > + *
> > + * Copyright 2006 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.
> > + */
> > +
> > +#include <linux/stddef.h>
> > +#include <linux/kernel.h>
> > +#include <linux/pci.h>
> > +#include <linux/kdev_t.h>
> > +#include <linux/delay.h>
> > +#include <linux/seq_file.h>
> > +
> > +#include <asm/system.h>
> > +#include <asm/time.h>
> > +#include <asm/machdep.h>
> > +#include <asm/pci-bridge.h>
> > +#include <asm/mpc86xx.h>
> > +#include <asm/prom.h>
> > +#include <mm/mmu_decl.h>
> > +#include <asm/udbg.h>
> > +#include <asm/i8259.h>
> > +#include <asm-generic/rtc.h>
> > +#include <asm/mpic.h>
> > +
> > +#include <sysdev/fsl_soc.h>
> > +
> > +#include "mpc86xx.h"
> > +#include "sbc8641d.h"
> > +
> > +#define DEBUG
> > +
> > +#ifdef DEBUG
> > +#define DBG(fmt...) do { printk(KERN_ERR fmt); } while(0)
> > +#else
> > +#define DBG(fmt...) do { } while(0)
> > +#endif
> > +
> > +/* unsigned long isa_io_base = 0;
> > +unsigned long isa_mem_base = 0;
> > +unsigned long pci_dram_offset = 0; */
> > +
> > +
> > +void __init
> > +sbc8641d_init_irq(void)
> > +{
> > + struct mpic *mpic1;
> > + struct device_node *np;
> > + struct resource res;
> > +
> > + /* Determine PIC address. */
> > + np = of_find_node_by_type(NULL, "open-pic");
> > + if (np == NULL)
> > + return;
> > + of_address_to_resource(np, 0, &res);
> > +
> > + /* Alloc mpic structure and per isu has 16 INT entries. */
> > + mpic1 = mpic_alloc(np, res.start,
> > + MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
> > + 16, NR_IRQS - 4,
> > + " MPIC ");
> > + BUG_ON(mpic1 == NULL);
> > +
> > + mpic_assign_isu(mpic1, 0, res.start + 0x10000);
> > +
> > + /* 48 Internal Interrupts */
> > + mpic_assign_isu(mpic1, 1, res.start + 0x10200);
> > + mpic_assign_isu(mpic1, 2, res.start + 0x10400);
> > + mpic_assign_isu(mpic1, 3, res.start + 0x10600);
> > +
> > + /* 16 External interrupts
> > + * Moving them from [0 - 15] to [64 - 79]
> > + */
> > + mpic_assign_isu(mpic1, 4, res.start + 0x10000);
> > +
>
> look at a 2.6.22-rc1 kernel to see how this has changed. It also
> effects the .dts interrupt numbers. Please match how the mpc8641hpcn
> does things.
Will do.
>
> > + mpic_init(mpic1);
> > +
> > +}
> > +
> > +
> > +static void __init
> > +sbc8641d_setup_arch(void)
> > +{
> > + struct device_node *np;
> > +
> > + if (ppc_md.progress)
> > + ppc_md.progress("sbc8641d_setup_arch()", 0);
> > +
> > + np = of_find_node_by_type(NULL, "cpu");
> > + if (np != 0) {
> > + const unsigned int *fp;
> > +
> > + fp = get_property(np, "clock-frequency", NULL);
> > + if (fp != 0)
> > + loops_per_jiffy = *fp / HZ;
> > + else
> > + loops_per_jiffy = 50000000 / HZ;
> > + of_node_put(np);
> > + }
>
> git ride of this code to find loops_per_jiffy.
Will do.
>
> > +
> > + printk("SBC8641D board from Wind River Systems\n");
> > +
> > +#ifdef CONFIG_SMP
> > + mpc86xx_smp_init();
> > +#endif
> > +}
> > +
> > +
> > +void
> > +sbc8641d_show_cpuinfo(struct seq_file *m)
> > +{
> > + struct device_node *root;
> > + uint memsize = total_memory;
> > + const char *model = "";
> > + uint svid = mfspr(SPRN_SVR);
> > +
> > + seq_printf(m, "Vendor\t\t: Wind River Systems\n");
> > +
> > + root = of_find_node_by_path("/");
> > + if (root)
> > + model = get_property(root, "model", NULL);
> > + seq_printf(m, "Machine\t\t: %s\n", model);
> > + of_node_put(root);
> > +
> > + seq_printf(m, "SVR\t\t: 0x%x\n", svid);
> > + seq_printf(m, "Memory\t\t: %d MB\n", memsize / (1024 * 1024));
> > +}
> > +
>
> This is mostly redundant with the basic show cpu info, do you need
> your own?
The plan is to add code to read the EEPROM device and show more info.
>
> > +
> > +/*
> > + * Called very early, device-tree isn't unflattened
> > + */
> > +static int __init sbc8641d_probe(void)
> > +{
> > + unsigned long root = of_get_flat_dt_root();
> > +
> > + if (of_flat_dt_is_compatible(root, "mpc86xx"))
> > + return 1; /* Looks good */
>
> the check you have is too generic, you probably need something more
> specific in the top level compatible property.
Will do.
>
> > +
> > + return 0;
> > +}
> > +
> > +
> > +void
> > +sbc8641d_restart(char *cmd)
> > +{
> > + void __iomem *rstcr;
> > +
> > + rstcr = ioremap(get_immrbase() + MPC86XX_RSTCR_OFFSET, 0x100);
> > +
> > + local_irq_disable();
> > +
> > + /* Assert reset request to Reset Control Register */
> > + out_be32(rstcr, 0x2);
> > +
> > + /* not reached */
> > +}
> > +
> > +
> > +long __init
> > +sbc8641d_time_init(void)
> > +{
> > + unsigned int temp;
> > +
> > + /* Set the time base to zero */
> > + mtspr(SPRN_TBWL, 0);
> > + mtspr(SPRN_TBWU, 0);
> > +
> > + temp = mfspr(SPRN_HID0);
> > + temp |= HID0_TBEN;
> > + mtspr(SPRN_HID0, temp);
> > + asm volatile("isync");
> > +
> > + return 0;
> > +}
> > +
> > +
> > +define_machine(sbc8641d) {
> > + .name = "SBC8641D",
> > + .probe = sbc8641d_probe,
> > + .setup_arch = sbc8641d_setup_arch,
> > + .init_IRQ = sbc8641d_init_irq,
> > + .show_cpuinfo = sbc8641d_show_cpuinfo,
> > + .get_irq = mpic_get_irq,
> > + .restart = sbc8641d_restart,
> > + .time_init = sbc8641d_time_init,
> > + .calibrate_decr = generic_calibrate_decr,
> > + .progress = udbg_progress,
> > +
> > +#ifdef CONFIG_GEN_RTC
> > + /* RTC interface, using functions in include/asm-generic/rtc.h */
> > + .get_rtc_time = get_rtc_time,
> > + .set_rtc_time = set_rtc_time,
> > +#endif
> > +};
> > diff -purN -X dontdiff linux-2.6/arch/powerpc/platforms/86xx/
> > sbc8641d.h linux-2.6-esi/arch/powerpc/platforms/86xx/sbc8641d.h
> > --- linux-2.6/arch/powerpc/platforms/86xx/sbc8641d.h 1969-12-31
> > 18:00:00.000000000 -0600
> > +++ linux-2.6-esi/arch/powerpc/platforms/86xx/sbc8641d.h 2007-07-31
> > 15:57:01.000000000 -0500
> > @@ -0,0 +1,24 @@
> > +/*
> > + * SBC8641D board definitions
> > + *
> > + * Copyright 2007 Embedded Specialties, Inc.
> > + * Joe Hamman <joe.hamman@embeddedspecialties.com>
> > + *
> > + * Copyright 2006 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.
> > + *
> > + * Author: Xianghua Xiao <x.xiao@freescale.com>
> > + */
> > +
> > +#ifndef __SBC8641D_H__
> > +#define __SBC8641D_H__
> > +
> > +#include <linux/init.h>
> > +
> > +#define MPC86XX_RSTCR_OFFSET (0xe00b0) /* Reset Control
Register
> */
> > +
> > +#endif /* __SBC8641D_H__ */
> > diff -purN -X dontdiff linux-2.6/drivers/net/gianfar.h linux-2.6-
> > esi/drivers/net/gianfar.h
> > --- linux-2.6/drivers/net/gianfar.h 2007-07-31 10:15:39.000000000
> > -0500
> > +++ linux-2.6-esi/drivers/net/gianfar.h 2007-07-31
> > 10:39:10.000000000 -0500
> > @@ -131,7 +131,7 @@ extern const char gfar_driver_version[];
> > #define DEFAULT_RXCOUNT 16
> > #define DEFAULT_RXTIME 4
> >
> > -#define TBIPA_VALUE 0x1f
> > +#define TBIPA_VALUE 0x1e
>
> we need to turn this into a config option or something.
I was a little concerned when I saw a hard-coded address. I never would
have found the conflict with the QUAD PHY (it starts at 0x1f and increments
for each device) without your help.
Let me know what you think and I'll put something together.
>
> > #define MIIMCFG_INIT_VALUE 0x00000007
> > #define MIIMCFG_RESET 0x80000000
> > #define MIIMIND_BUSY 0x00000001
> >
^ permalink raw reply
* Re: a question about mpc8xx linux
From: Barisa kisku @ 2007-08-01 14:48 UTC (permalink / raw)
To: Linux-ppc mail list
In-Reply-To: <200707272111187341027@163.com>
[-- Attachment #1: Type: text/plain, Size: 354 bytes --]
how do you know execution stop at "rfi" instruction.i think it seems it stop at "rfi" instruction when debugging through debugger, but it does n't . you check it by putting break point in the later functions e.g start_here, machine_init etc.
---------------------------------
5, 50, 500, 5000. Store N number of mails in your inbox. Click here.
[-- Attachment #2: Type: text/html, Size: 479 bytes --]
^ permalink raw reply
* RE: [PATCH] Add support for Wind River SBC8641D board
From: Joe Hamman @ 2007-08-01 14:33 UTC (permalink / raw)
To: 'Kumar Gala'; +Cc: linuxppc-embedded
In-Reply-To: <EFF6CD19-4700-41CD-843F-9AF818F7DB82@kernel.crashing.org>
The board supports both single and dual core parts. The board I have is
single core.
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Wednesday, August 01, 2007 9:18 AM
> To: joe.hamman@embeddedspecialties.com
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: [PATCH] Add support for Wind River SBC8641D board
>
>
> On Jul 31, 2007, at 7:36 PM, Joe Hamman wrote:
>
> > Add support for Wind River's SBC8641D reference board.
>
> Is this a single core or dual core chip?
>
> >
> > Signed-off by: Joe Hamman <joe.hamman@embeddedspecialties.com>
> >
> > diff -purN -X dontdiff linux-2.6/arch/powerpc/boot/dts/sbc8641d.dts
> > linux-2.6-esi/arch/powerpc/boot/dts/sbc8641d.dts
> > --- linux-2.6/arch/powerpc/boot/dts/sbc8641d.dts 1969-12-31
> > 18:00:00.000000000 -0600
> > +++ linux-2.6-esi/arch/powerpc/boot/dts/sbc8641d.dts 2007-07-31
> > 13:15:15.000000000 -0500
> > @@ -0,0 +1,160 @@
> > +/*
> > + * SBC8641D Device Tree Source
> > + *
> > + * Copyright 2007 Embedded Specialties, Inc.
> > + * Joe Hamman joe.hamman@embeddedspecialties.com
> > + *
> > + * Copyright 2006 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 = "SBC8641D";
> > + compatible = "mpc86xx";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + PowerPC,8641@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>; // 33 MHz, from
uboot
> > + bus-frequency = <0>; // From uboot
> > + clock-frequency = <0>; // From uboot
> > + 32-bit;
> > + };
>
> if this is really an 8641D I'd expect a 2nd cpu node.
>
> > + };
> > +
> > + memory {
> > + device_type = "memory";
> > + reg = <00000000 20000000>; // 512M at 0x0
> > + };
> > +
> > + soc8641@f8000000 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + #interrupt-cells = <2>;
> > + device_type = "soc";
> > + ranges = <0 f8000000 00100000>;
> > + reg = <f8000000 00100000>; // CCSRBAR 1M
> > + bus-frequency = <0>;
> > +
> > + mdio@24520 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "mdio";
> > + compatible = "gianfar";
> > + reg = <24520 20>;
> > + phy1f: ethernet-phy@1f {
> > + reg = <1f>;
> > + device_type = "ethernet-phy";
> > + };
> > + phy0: ethernet-phy@0 {
> > + reg = <0>;
> > + device_type = "ethernet-phy";
> > + };
> > + phy1: ethernet-phy@1 {
> > + reg = <1>;
> > + device_type = "ethernet-phy";
> > + };
> > + phy2: ethernet-phy@2 {
> > + reg = <2>;
> > + device_type = "ethernet-phy";
> > + };
> > + };
> > +
> > + ethernet@24000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "network";
> > + model = "eTSEC";
> > + compatible = "gianfar";
> > + reg = <24000 1000>;
> > + mac-address = [ 00 E0 0C 00 73 00 ];
>
>
> > + interrupts = <1d 2 1e 2 22 2>;
> > + interrupt-parent = <&mpic>;
> > + phy-handle = <&phy1f>;
> > + };
> > +
> > + ethernet@25000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "network";
> > + model = "eTSEC";
> > + compatible = "gianfar";
> > + reg = <25000 1000>;
> > + mac-address = [ 00 E0 0C 00 73 01 ];
> > + interrupts = <23 2 24 2 28 2>;
> > + interrupt-parent = <&mpic>;
> > + phy-handle = <&phy0>;
> > + };
> > +
> > + ethernet@26000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "network";
> > + model = "eTSEC";
> > + compatible = "gianfar";
> > + reg = <26000 1000>;
> > + mac-address = [ 00 E0 0C 00 02 FD ];
> > + interrupts = <1F 2 20 2 21 2>;
> > + interrupt-parent = <&mpic>;
> > + phy-handle = <&phy1>;
> > + };
> > +
> > + ethernet@27000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "network";
> > + model = "eTSEC";
> > + compatible = "gianfar";
> > + reg = <27000 1000>;
> > + mac-address = [ 00 E0 0C 00 03 FD ];
> > + interrupts = <25 2 26 2 27 2>;
> > + interrupt-parent = <&mpic>;
> > + phy-handle = <&phy2>;
> > + };
> > +
> > + 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 = <1c 2>;
> > + interrupt-parent = <&mpic>;
> > + };
> > +
> > + 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;
> > + };
> > + };
> > +};
>
> [snip]
>
> > diff -purN -X dontdiff linux-2.6/arch/powerpc/platforms/86xx/
> > Kconfig linux-2.6-esi/arch/powerpc/platforms/86xx/Kconfig
> > --- linux-2.6/arch/powerpc/platforms/86xx/Kconfig 2007-07-31
> > 10:15:36.000000000 -0500
> > +++ linux-2.6-esi/arch/powerpc/platforms/86xx/Kconfig 2007-07-31
> > 10:36:45.000000000 -0500
> > @@ -10,6 +10,12 @@ config MPC8641_HPCN
> > help
> > This option enables support for the MPC8641 HPCN board.
> >
> > +config SBC8641D
> > + bool "Wind River SBC8641D"
> > + select DEFAULT_UIMAGE
> > + help
> > + This option enables support for the SBC8641D board.
> > +
> > endchoice
> >
> > config MPC8641
> > @@ -18,3 +24,4 @@ config MPC8641
> > select PPC_UDBG_16550
> > select MPIC
> > default y if MPC8641_HPCN
> > + default y if SBC8641D
> > diff -purN -X dontdiff linux-2.6/arch/powerpc/platforms/86xx/
> > Makefile linux-2.6-esi/arch/powerpc/platforms/86xx/Makefile
> > --- linux-2.6/arch/powerpc/platforms/86xx/Makefile 2007-07-31
> > 10:15:36.000000000 -0500
> > +++ linux-2.6-esi/arch/powerpc/platforms/86xx/Makefile 2007-07-31
> > 10:37:30.000000000 -0500
> > @@ -4,3 +4,4 @@
> >
> > obj-$(CONFIG_SMP) += mpc86xx_smp.o
> > obj-$(CONFIG_MPC8641_HPCN) += mpc86xx_hpcn.o
> > +obj-$(CONFIG_SBC8641D) += sbc8641d.o
> > diff -purN -X dontdiff linux-2.6/arch/powerpc/platforms/86xx/
> > sbc8641d.c linux-2.6-esi/arch/powerpc/platforms/86xx/sbc8641d.c
> > --- linux-2.6/arch/powerpc/platforms/86xx/sbc8641d.c 1969-12-31
> > 18:00:00.000000000 -0600
> > +++ linux-2.6-esi/arch/powerpc/platforms/86xx/sbc8641d.c 2007-07-31
> > 15:55:59.000000000 -0500
> > @@ -0,0 +1,206 @@
> > +/*
> > + * SBC8641D board specific routines
> > + *
> > + * Copyright 2007 Embedded Specialties, Inc.
> > + * Joe Hamman <joe.hamman@embeddedspecialties.com>
> > + *
> > + * Recode: ZHANG WEI <wei.zhang@freescale.com>
> > + * Initial author: Xianghua Xiao <x.xiao@freescale.com>
> > + *
> > + * Copyright 2006 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.
> > + */
> > +
> > +#include <linux/stddef.h>
> > +#include <linux/kernel.h>
> > +#include <linux/pci.h>
> > +#include <linux/kdev_t.h>
> > +#include <linux/delay.h>
> > +#include <linux/seq_file.h>
> > +
> > +#include <asm/system.h>
> > +#include <asm/time.h>
> > +#include <asm/machdep.h>
> > +#include <asm/pci-bridge.h>
> > +#include <asm/mpc86xx.h>
> > +#include <asm/prom.h>
> > +#include <mm/mmu_decl.h>
> > +#include <asm/udbg.h>
> > +#include <asm/i8259.h>
> > +#include <asm-generic/rtc.h>
> > +#include <asm/mpic.h>
> > +
> > +#include <sysdev/fsl_soc.h>
> > +
> > +#include "mpc86xx.h"
> > +#include "sbc8641d.h"
> > +
> > +#define DEBUG
> > +
> > +#ifdef DEBUG
> > +#define DBG(fmt...) do { printk(KERN_ERR fmt); } while(0)
> > +#else
> > +#define DBG(fmt...) do { } while(0)
> > +#endif
> > +
> > +/* unsigned long isa_io_base = 0;
> > +unsigned long isa_mem_base = 0;
> > +unsigned long pci_dram_offset = 0; */
> > +
> > +
> > +void __init
> > +sbc8641d_init_irq(void)
> > +{
> > + struct mpic *mpic1;
> > + struct device_node *np;
> > + struct resource res;
> > +
> > + /* Determine PIC address. */
> > + np = of_find_node_by_type(NULL, "open-pic");
> > + if (np == NULL)
> > + return;
> > + of_address_to_resource(np, 0, &res);
> > +
> > + /* Alloc mpic structure and per isu has 16 INT entries. */
> > + mpic1 = mpic_alloc(np, res.start,
> > + MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
> > + 16, NR_IRQS - 4,
> > + " MPIC ");
> > + BUG_ON(mpic1 == NULL);
> > +
> > + mpic_assign_isu(mpic1, 0, res.start + 0x10000);
> > +
> > + /* 48 Internal Interrupts */
> > + mpic_assign_isu(mpic1, 1, res.start + 0x10200);
> > + mpic_assign_isu(mpic1, 2, res.start + 0x10400);
> > + mpic_assign_isu(mpic1, 3, res.start + 0x10600);
> > +
> > + /* 16 External interrupts
> > + * Moving them from [0 - 15] to [64 - 79]
> > + */
> > + mpic_assign_isu(mpic1, 4, res.start + 0x10000);
> > +
>
> look at a 2.6.22-rc1 kernel to see how this has changed. It also
> effects the .dts interrupt numbers. Please match how the mpc8641hpcn
> does things.
>
> > + mpic_init(mpic1);
> > +
> > +}
> > +
> > +
> > +static void __init
> > +sbc8641d_setup_arch(void)
> > +{
> > + struct device_node *np;
> > +
> > + if (ppc_md.progress)
> > + ppc_md.progress("sbc8641d_setup_arch()", 0);
> > +
> > + np = of_find_node_by_type(NULL, "cpu");
> > + if (np != 0) {
> > + const unsigned int *fp;
> > +
> > + fp = get_property(np, "clock-frequency", NULL);
> > + if (fp != 0)
> > + loops_per_jiffy = *fp / HZ;
> > + else
> > + loops_per_jiffy = 50000000 / HZ;
> > + of_node_put(np);
> > + }
>
> git ride of this code to find loops_per_jiffy.
>
> > +
> > + printk("SBC8641D board from Wind River Systems\n");
> > +
> > +#ifdef CONFIG_SMP
> > + mpc86xx_smp_init();
> > +#endif
> > +}
> > +
> > +
> > +void
> > +sbc8641d_show_cpuinfo(struct seq_file *m)
> > +{
> > + struct device_node *root;
> > + uint memsize = total_memory;
> > + const char *model = "";
> > + uint svid = mfspr(SPRN_SVR);
> > +
> > + seq_printf(m, "Vendor\t\t: Wind River Systems\n");
> > +
> > + root = of_find_node_by_path("/");
> > + if (root)
> > + model = get_property(root, "model", NULL);
> > + seq_printf(m, "Machine\t\t: %s\n", model);
> > + of_node_put(root);
> > +
> > + seq_printf(m, "SVR\t\t: 0x%x\n", svid);
> > + seq_printf(m, "Memory\t\t: %d MB\n", memsize / (1024 * 1024));
> > +}
> > +
>
> This is mostly redundant with the basic show cpu info, do you need
> your own?
>
> > +
> > +/*
> > + * Called very early, device-tree isn't unflattened
> > + */
> > +static int __init sbc8641d_probe(void)
> > +{
> > + unsigned long root = of_get_flat_dt_root();
> > +
> > + if (of_flat_dt_is_compatible(root, "mpc86xx"))
> > + return 1; /* Looks good */
>
> the check you have is too generic, you probably need something more
> specific in the top level compatible property.
>
> > +
> > + return 0;
> > +}
> > +
> > +
> > +void
> > +sbc8641d_restart(char *cmd)
> > +{
> > + void __iomem *rstcr;
> > +
> > + rstcr = ioremap(get_immrbase() + MPC86XX_RSTCR_OFFSET, 0x100);
> > +
> > + local_irq_disable();
> > +
> > + /* Assert reset request to Reset Control Register */
> > + out_be32(rstcr, 0x2);
> > +
> > + /* not reached */
> > +}
> > +
> > +
> > +long __init
> > +sbc8641d_time_init(void)
> > +{
> > + unsigned int temp;
> > +
> > + /* Set the time base to zero */
> > + mtspr(SPRN_TBWL, 0);
> > + mtspr(SPRN_TBWU, 0);
> > +
> > + temp = mfspr(SPRN_HID0);
> > + temp |= HID0_TBEN;
> > + mtspr(SPRN_HID0, temp);
> > + asm volatile("isync");
> > +
> > + return 0;
> > +}
> > +
> > +
> > +define_machine(sbc8641d) {
> > + .name = "SBC8641D",
> > + .probe = sbc8641d_probe,
> > + .setup_arch = sbc8641d_setup_arch,
> > + .init_IRQ = sbc8641d_init_irq,
> > + .show_cpuinfo = sbc8641d_show_cpuinfo,
> > + .get_irq = mpic_get_irq,
> > + .restart = sbc8641d_restart,
> > + .time_init = sbc8641d_time_init,
> > + .calibrate_decr = generic_calibrate_decr,
> > + .progress = udbg_progress,
> > +
> > +#ifdef CONFIG_GEN_RTC
> > + /* RTC interface, using functions in include/asm-generic/rtc.h */
> > + .get_rtc_time = get_rtc_time,
> > + .set_rtc_time = set_rtc_time,
> > +#endif
> > +};
> > diff -purN -X dontdiff linux-2.6/arch/powerpc/platforms/86xx/
> > sbc8641d.h linux-2.6-esi/arch/powerpc/platforms/86xx/sbc8641d.h
> > --- linux-2.6/arch/powerpc/platforms/86xx/sbc8641d.h 1969-12-31
> > 18:00:00.000000000 -0600
> > +++ linux-2.6-esi/arch/powerpc/platforms/86xx/sbc8641d.h 2007-07-31
> > 15:57:01.000000000 -0500
> > @@ -0,0 +1,24 @@
> > +/*
> > + * SBC8641D board definitions
> > + *
> > + * Copyright 2007 Embedded Specialties, Inc.
> > + * Joe Hamman <joe.hamman@embeddedspecialties.com>
> > + *
> > + * Copyright 2006 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.
> > + *
> > + * Author: Xianghua Xiao <x.xiao@freescale.com>
> > + */
> > +
> > +#ifndef __SBC8641D_H__
> > +#define __SBC8641D_H__
> > +
> > +#include <linux/init.h>
> > +
> > +#define MPC86XX_RSTCR_OFFSET (0xe00b0) /* Reset Control
Register
> */
> > +
> > +#endif /* __SBC8641D_H__ */
> > diff -purN -X dontdiff linux-2.6/drivers/net/gianfar.h linux-2.6-
> > esi/drivers/net/gianfar.h
> > --- linux-2.6/drivers/net/gianfar.h 2007-07-31 10:15:39.000000000
> > -0500
> > +++ linux-2.6-esi/drivers/net/gianfar.h 2007-07-31
> > 10:39:10.000000000 -0500
> > @@ -131,7 +131,7 @@ extern const char gfar_driver_version[];
> > #define DEFAULT_RXCOUNT 16
> > #define DEFAULT_RXTIME 4
> >
> > -#define TBIPA_VALUE 0x1f
> > +#define TBIPA_VALUE 0x1e
>
> we need to turn this into a config option or something.
>
> > #define MIIMCFG_INIT_VALUE 0x00000007
> > #define MIIMCFG_RESET 0x80000000
> > #define MIIMIND_BUSY 0x00000001
> >
^ permalink raw reply
* Re: [PATCH] mark PCI resource with start 0 as unassigned
From: Sergei Shtylyov @ 2007-08-01 14:22 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linux-ide, Olaf Hering, Alan, linuxppc-dev
In-Reply-To: <52F5B831-5B40-4D40-A77F-4D7484692CAE@kernel.crashing.org>
Segher Boessenkool wrote:
>> setup-pci is for SFF8038i devices. It therefore knows that for assigned
>> resources they must be I/O. It also assumes that zero is not a valid I/O
>> port just like zero is not a valid IRQ. Stick a real IDE resource at
>> zero and drivers/ide can't cope.
> 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).
> using "virtual I/O addresses", analogue to the IRQ situation,
> or can these bad assumptions be fixed instead?
> Segher
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] Add support for Wind River SBC8641D board
From: Kumar Gala @ 2007-08-01 14:17 UTC (permalink / raw)
To: joe.hamman; +Cc: linuxppc-embedded
In-Reply-To: <1185928568.21198.10.camel@server>
On Jul 31, 2007, at 7:36 PM, Joe Hamman wrote:
> Add support for Wind River's SBC8641D reference board.
Is this a single core or dual core chip?
>
> Signed-off by: Joe Hamman <joe.hamman@embeddedspecialties.com>
>
> diff -purN -X dontdiff linux-2.6/arch/powerpc/boot/dts/sbc8641d.dts
> linux-2.6-esi/arch/powerpc/boot/dts/sbc8641d.dts
> --- linux-2.6/arch/powerpc/boot/dts/sbc8641d.dts 1969-12-31
> 18:00:00.000000000 -0600
> +++ linux-2.6-esi/arch/powerpc/boot/dts/sbc8641d.dts 2007-07-31
> 13:15:15.000000000 -0500
> @@ -0,0 +1,160 @@
> +/*
> + * SBC8641D Device Tree Source
> + *
> + * Copyright 2007 Embedded Specialties, Inc.
> + * Joe Hamman joe.hamman@embeddedspecialties.com
> + *
> + * Copyright 2006 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 = "SBC8641D";
> + compatible = "mpc86xx";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,8641@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>; // 33 MHz, from uboot
> + bus-frequency = <0>; // From uboot
> + clock-frequency = <0>; // From uboot
> + 32-bit;
> + };
if this is really an 8641D I'd expect a 2nd cpu node.
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <00000000 20000000>; // 512M at 0x0
> + };
> +
> + soc8641@f8000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #interrupt-cells = <2>;
> + device_type = "soc";
> + ranges = <0 f8000000 00100000>;
> + reg = <f8000000 00100000>; // CCSRBAR 1M
> + bus-frequency = <0>;
> +
> + mdio@24520 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "mdio";
> + compatible = "gianfar";
> + reg = <24520 20>;
> + phy1f: ethernet-phy@1f {
> + reg = <1f>;
> + device_type = "ethernet-phy";
> + };
> + phy0: ethernet-phy@0 {
> + reg = <0>;
> + device_type = "ethernet-phy";
> + };
> + phy1: ethernet-phy@1 {
> + reg = <1>;
> + device_type = "ethernet-phy";
> + };
> + phy2: ethernet-phy@2 {
> + reg = <2>;
> + device_type = "ethernet-phy";
> + };
> + };
> +
> + ethernet@24000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <24000 1000>;
> + mac-address = [ 00 E0 0C 00 73 00 ];
> + interrupts = <1d 2 1e 2 22 2>;
> + interrupt-parent = <&mpic>;
> + phy-handle = <&phy1f>;
> + };
> +
> + ethernet@25000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <25000 1000>;
> + mac-address = [ 00 E0 0C 00 73 01 ];
> + interrupts = <23 2 24 2 28 2>;
> + interrupt-parent = <&mpic>;
> + phy-handle = <&phy0>;
> + };
> +
> + ethernet@26000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <26000 1000>;
> + mac-address = [ 00 E0 0C 00 02 FD ];
> + interrupts = <1F 2 20 2 21 2>;
> + interrupt-parent = <&mpic>;
> + phy-handle = <&phy1>;
> + };
> +
> + ethernet@27000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <27000 1000>;
> + mac-address = [ 00 E0 0C 00 03 FD ];
> + interrupts = <25 2 26 2 27 2>;
> + interrupt-parent = <&mpic>;
> + phy-handle = <&phy2>;
> + };
> +
> + 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 = <1c 2>;
> + interrupt-parent = <&mpic>;
> + };
> +
> + 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;
> + };
> + };
> +};
[snip]
> diff -purN -X dontdiff linux-2.6/arch/powerpc/platforms/86xx/
> Kconfig linux-2.6-esi/arch/powerpc/platforms/86xx/Kconfig
> --- linux-2.6/arch/powerpc/platforms/86xx/Kconfig 2007-07-31
> 10:15:36.000000000 -0500
> +++ linux-2.6-esi/arch/powerpc/platforms/86xx/Kconfig 2007-07-31
> 10:36:45.000000000 -0500
> @@ -10,6 +10,12 @@ config MPC8641_HPCN
> help
> This option enables support for the MPC8641 HPCN board.
>
> +config SBC8641D
> + bool "Wind River SBC8641D"
> + select DEFAULT_UIMAGE
> + help
> + This option enables support for the SBC8641D board.
> +
> endchoice
>
> config MPC8641
> @@ -18,3 +24,4 @@ config MPC8641
> select PPC_UDBG_16550
> select MPIC
> default y if MPC8641_HPCN
> + default y if SBC8641D
> diff -purN -X dontdiff linux-2.6/arch/powerpc/platforms/86xx/
> Makefile linux-2.6-esi/arch/powerpc/platforms/86xx/Makefile
> --- linux-2.6/arch/powerpc/platforms/86xx/Makefile 2007-07-31
> 10:15:36.000000000 -0500
> +++ linux-2.6-esi/arch/powerpc/platforms/86xx/Makefile 2007-07-31
> 10:37:30.000000000 -0500
> @@ -4,3 +4,4 @@
>
> obj-$(CONFIG_SMP) += mpc86xx_smp.o
> obj-$(CONFIG_MPC8641_HPCN) += mpc86xx_hpcn.o
> +obj-$(CONFIG_SBC8641D) += sbc8641d.o
> diff -purN -X dontdiff linux-2.6/arch/powerpc/platforms/86xx/
> sbc8641d.c linux-2.6-esi/arch/powerpc/platforms/86xx/sbc8641d.c
> --- linux-2.6/arch/powerpc/platforms/86xx/sbc8641d.c 1969-12-31
> 18:00:00.000000000 -0600
> +++ linux-2.6-esi/arch/powerpc/platforms/86xx/sbc8641d.c 2007-07-31
> 15:55:59.000000000 -0500
> @@ -0,0 +1,206 @@
> +/*
> + * SBC8641D board specific routines
> + *
> + * Copyright 2007 Embedded Specialties, Inc.
> + * Joe Hamman <joe.hamman@embeddedspecialties.com>
> + *
> + * Recode: ZHANG WEI <wei.zhang@freescale.com>
> + * Initial author: Xianghua Xiao <x.xiao@freescale.com>
> + *
> + * Copyright 2006 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.
> + */
> +
> +#include <linux/stddef.h>
> +#include <linux/kernel.h>
> +#include <linux/pci.h>
> +#include <linux/kdev_t.h>
> +#include <linux/delay.h>
> +#include <linux/seq_file.h>
> +
> +#include <asm/system.h>
> +#include <asm/time.h>
> +#include <asm/machdep.h>
> +#include <asm/pci-bridge.h>
> +#include <asm/mpc86xx.h>
> +#include <asm/prom.h>
> +#include <mm/mmu_decl.h>
> +#include <asm/udbg.h>
> +#include <asm/i8259.h>
> +#include <asm-generic/rtc.h>
> +#include <asm/mpic.h>
> +
> +#include <sysdev/fsl_soc.h>
> +
> +#include "mpc86xx.h"
> +#include "sbc8641d.h"
> +
> +#define DEBUG
> +
> +#ifdef DEBUG
> +#define DBG(fmt...) do { printk(KERN_ERR fmt); } while(0)
> +#else
> +#define DBG(fmt...) do { } while(0)
> +#endif
> +
> +/* unsigned long isa_io_base = 0;
> +unsigned long isa_mem_base = 0;
> +unsigned long pci_dram_offset = 0; */
> +
> +
> +void __init
> +sbc8641d_init_irq(void)
> +{
> + struct mpic *mpic1;
> + struct device_node *np;
> + struct resource res;
> +
> + /* Determine PIC address. */
> + np = of_find_node_by_type(NULL, "open-pic");
> + if (np == NULL)
> + return;
> + of_address_to_resource(np, 0, &res);
> +
> + /* Alloc mpic structure and per isu has 16 INT entries. */
> + mpic1 = mpic_alloc(np, res.start,
> + MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
> + 16, NR_IRQS - 4,
> + " MPIC ");
> + BUG_ON(mpic1 == NULL);
> +
> + mpic_assign_isu(mpic1, 0, res.start + 0x10000);
> +
> + /* 48 Internal Interrupts */
> + mpic_assign_isu(mpic1, 1, res.start + 0x10200);
> + mpic_assign_isu(mpic1, 2, res.start + 0x10400);
> + mpic_assign_isu(mpic1, 3, res.start + 0x10600);
> +
> + /* 16 External interrupts
> + * Moving them from [0 - 15] to [64 - 79]
> + */
> + mpic_assign_isu(mpic1, 4, res.start + 0x10000);
> +
look at a 2.6.22-rc1 kernel to see how this has changed. It also
effects the .dts interrupt numbers. Please match how the mpc8641hpcn
does things.
> + mpic_init(mpic1);
> +
> +}
> +
> +
> +static void __init
> +sbc8641d_setup_arch(void)
> +{
> + struct device_node *np;
> +
> + if (ppc_md.progress)
> + ppc_md.progress("sbc8641d_setup_arch()", 0);
> +
> + np = of_find_node_by_type(NULL, "cpu");
> + if (np != 0) {
> + const unsigned int *fp;
> +
> + fp = get_property(np, "clock-frequency", NULL);
> + if (fp != 0)
> + loops_per_jiffy = *fp / HZ;
> + else
> + loops_per_jiffy = 50000000 / HZ;
> + of_node_put(np);
> + }
git ride of this code to find loops_per_jiffy.
> +
> + printk("SBC8641D board from Wind River Systems\n");
> +
> +#ifdef CONFIG_SMP
> + mpc86xx_smp_init();
> +#endif
> +}
> +
> +
> +void
> +sbc8641d_show_cpuinfo(struct seq_file *m)
> +{
> + struct device_node *root;
> + uint memsize = total_memory;
> + const char *model = "";
> + uint svid = mfspr(SPRN_SVR);
> +
> + seq_printf(m, "Vendor\t\t: Wind River Systems\n");
> +
> + root = of_find_node_by_path("/");
> + if (root)
> + model = get_property(root, "model", NULL);
> + seq_printf(m, "Machine\t\t: %s\n", model);
> + of_node_put(root);
> +
> + seq_printf(m, "SVR\t\t: 0x%x\n", svid);
> + seq_printf(m, "Memory\t\t: %d MB\n", memsize / (1024 * 1024));
> +}
> +
This is mostly redundant with the basic show cpu info, do you need
your own?
> +
> +/*
> + * Called very early, device-tree isn't unflattened
> + */
> +static int __init sbc8641d_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> +
> + if (of_flat_dt_is_compatible(root, "mpc86xx"))
> + return 1; /* Looks good */
the check you have is too generic, you probably need something more
specific in the top level compatible property.
> +
> + return 0;
> +}
> +
> +
> +void
> +sbc8641d_restart(char *cmd)
> +{
> + void __iomem *rstcr;
> +
> + rstcr = ioremap(get_immrbase() + MPC86XX_RSTCR_OFFSET, 0x100);
> +
> + local_irq_disable();
> +
> + /* Assert reset request to Reset Control Register */
> + out_be32(rstcr, 0x2);
> +
> + /* not reached */
> +}
> +
> +
> +long __init
> +sbc8641d_time_init(void)
> +{
> + unsigned int temp;
> +
> + /* Set the time base to zero */
> + mtspr(SPRN_TBWL, 0);
> + mtspr(SPRN_TBWU, 0);
> +
> + temp = mfspr(SPRN_HID0);
> + temp |= HID0_TBEN;
> + mtspr(SPRN_HID0, temp);
> + asm volatile("isync");
> +
> + return 0;
> +}
> +
> +
> +define_machine(sbc8641d) {
> + .name = "SBC8641D",
> + .probe = sbc8641d_probe,
> + .setup_arch = sbc8641d_setup_arch,
> + .init_IRQ = sbc8641d_init_irq,
> + .show_cpuinfo = sbc8641d_show_cpuinfo,
> + .get_irq = mpic_get_irq,
> + .restart = sbc8641d_restart,
> + .time_init = sbc8641d_time_init,
> + .calibrate_decr = generic_calibrate_decr,
> + .progress = udbg_progress,
> +
> +#ifdef CONFIG_GEN_RTC
> + /* RTC interface, using functions in include/asm-generic/rtc.h */
> + .get_rtc_time = get_rtc_time,
> + .set_rtc_time = set_rtc_time,
> +#endif
> +};
> diff -purN -X dontdiff linux-2.6/arch/powerpc/platforms/86xx/
> sbc8641d.h linux-2.6-esi/arch/powerpc/platforms/86xx/sbc8641d.h
> --- linux-2.6/arch/powerpc/platforms/86xx/sbc8641d.h 1969-12-31
> 18:00:00.000000000 -0600
> +++ linux-2.6-esi/arch/powerpc/platforms/86xx/sbc8641d.h 2007-07-31
> 15:57:01.000000000 -0500
> @@ -0,0 +1,24 @@
> +/*
> + * SBC8641D board definitions
> + *
> + * Copyright 2007 Embedded Specialties, Inc.
> + * Joe Hamman <joe.hamman@embeddedspecialties.com>
> + *
> + * Copyright 2006 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.
> + *
> + * Author: Xianghua Xiao <x.xiao@freescale.com>
> + */
> +
> +#ifndef __SBC8641D_H__
> +#define __SBC8641D_H__
> +
> +#include <linux/init.h>
> +
> +#define MPC86XX_RSTCR_OFFSET (0xe00b0) /* Reset Control Register */
> +
> +#endif /* __SBC8641D_H__ */
> diff -purN -X dontdiff linux-2.6/drivers/net/gianfar.h linux-2.6-
> esi/drivers/net/gianfar.h
> --- linux-2.6/drivers/net/gianfar.h 2007-07-31 10:15:39.000000000
> -0500
> +++ linux-2.6-esi/drivers/net/gianfar.h 2007-07-31
> 10:39:10.000000000 -0500
> @@ -131,7 +131,7 @@ extern const char gfar_driver_version[];
> #define DEFAULT_RXCOUNT 16
> #define DEFAULT_RXTIME 4
>
> -#define TBIPA_VALUE 0x1f
> +#define TBIPA_VALUE 0x1e
we need to turn this into a config option or something.
> #define MIIMCFG_INIT_VALUE 0x00000007
> #define MIIMCFG_RESET 0x80000000
> #define MIIMIND_BUSY 0x00000001
>
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: Valentine Barshak @ 2007-08-01 14:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: david
In-Reply-To: <20070801020836.GB31391@localhost.localdomain>
David Gibson wrote:
> On Mon, Jul 30, 2007 at 07:06:48PM +0400, Valentine Barshak wrote:
>> AMCC Sequoia board DTS
>>
>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>> ---
>> arch/powerpc/boot/dts/sequoia.dts | 292 ++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 292 insertions(+)
>>
>> diff -ruN linux.orig/arch/powerpc/boot/dts/sequoia.dts linux/arch/powerpc/boot/dts/sequoia.dts
>> --- linux.orig/arch/powerpc/boot/dts/sequoia.dts 1970-01-01 03:00:00.000000000 +0300
>> +++ linux/arch/powerpc/boot/dts/sequoia.dts 2007-07-27 20:44:26.000000000 +0400
>> @@ -0,0 +1,292 @@
>> +/*
>> + * Device Tree Source for AMCC Sequoia
>> + *
>> + * Based on Bamboo code by Josh Boyer <jwboyer@linux.vnet.ibm.com>
>> + * Copyright (c) 2006, 2007 IBM Corp.
>> + *
>> + * FIXME: Draft only!
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without
>> + * any warranty of any kind, whether express or implied.
>> + *
>> + * To build:
>> + * dtc -I dts -O asm -o bamboo.S -b 0 sequoia.dts
>> + * dtc -I dts -O dtb -o bamboo.dtb -b 0 sequoia.dts
>
> Needs updating to remove the bamboo references. In fact we can
> probably get rid of this "To build" comment that's been copied to just
> about every dts ever.
>
Old copy/paste stuff :)
>> + */
>> +
>> +/ {
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + model = "amcc,sequoia";
>> + compatible = "amcc,sequoia";
>> + dcr-parent = <&/cpus/PowerPC,440EPx@0>;
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + PowerPC,440EPx@0 {
>> + device_type = "cpu";
>> + reg = <0>;
>> + clock-frequency = <0>; /* Filled in by zImage */
>> + timebase-frequency = <0>; /* Filled in by zImage */
>> + i-cache-line-size = <20>;
>> + d-cache-line-size = <20>;
>> + i-cache-size = <8000>;
>> + d-cache-size = <8000>;
>> + dcr-controller;
>> + dcr-access-method = "native";
>> + };
>> + };
>> +
>> + memory {
>> + device_type = "memory";
>> + reg = <0 0 0>; /* Filled in by zImage */
>> + };
>> +
>> + UIC0: interrupt-controller0 {
>> + compatible = "ibm,uic-440gp","ibm,uic";
>
> The first compatible entry should always be the precise model, so in
> this case "ibm,uic-440epx". If it is (supposed to be) identical to
> the UIC in the 440GP, it can also have an "ibm,uic-440gp" entry, but
> since I believe all the UICs are supposed to operate the same, I think
> that's implicit in the "ibm,uic" entry.
>
> This goes for all the entries below where you list "ibm,....-440gp" or
> or "ibm,....-440ep" or "ibm,.....-440spe" first instead of
> "ibm,....-440epx".
>
OK, I'll correct it.
>> + interrupt-controller;
>> + cell-index = <0>;
>> + dcr-reg = <0c0 009>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + #interrupt-cells = <2>;
>> + };
>> +
>> + UIC1: interrupt-controller1 {
>> + compatible = "ibm,uic-440gp","ibm,uic";
>> + interrupt-controller;
>> + cell-index = <1>;
>> + dcr-reg = <0d0 009>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + #interrupt-cells = <2>;
>> + interrupts = <1e 4 1f 4>; /* cascade */
>> + interrupt-parent = <&UIC0>;
>> + };
>> +
>> + UIC2: interrupt-controller2 {
>> + compatible = "ibm,uic-440gp","ibm,uic";
>> + interrupt-controller;
>> + cell-index = <2>;
>> + dcr-reg = <0e0 009>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + #interrupt-cells = <2>;
>> + interrupts = <1c 4 1d 4>; /* cascade */
>> + interrupt-parent = <&UIC0>;
>> + };
>> +
>> + SDR0: sdr {
>
> What is the SDR?
SDR are System Device Control Registers (chip ID, pin function and stuff).
They are accessed by using the configuration address and data (CFGADDR
and CFGDATA) registers.
>
>> + compatible = "ibm,sdr-440ep";
>> + dcr-reg = <00e 002>;
>> + };
>> +
>> + CPR0: cpr {
>
> And the CPR?
CPR are Clock/Power-On Reset configuration registers.
They are also accessed by using the configuration address and data
(CFGADDR and CFGDATA) registers.
>
>> + compatible = "ibm,cpr-440ep";
>> + dcr-reg = <00c 002>;
>> + };
>> +
>> + plb {
>> + compatible = "ibm,plb-440gp", "ibm,plb4";
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + ranges;
>> + clock-frequency = <0>; /* Filled in by zImage */
>> +
>> + SDRAM0: sdram {
>> + device_type = "memory-controller";
>> + compatible = "ibm,sdram-44x-ddr2denali";
>
> Should have a precise -440epx compatible, as well as the more general one.
OK, got it.
>
>> + dcr-reg = <010 2>;
>> + };
>> +
>> + DMA0: dma {
>> + compatible = "ibm,dma-440gp", "ibm,dma-4xx";
>> + dcr-reg = <100 027>;
>> + };
>> +
>> + MAL0: mcmal {
>> + compatible = "ibm,mcmal-440spe", "ibm,mcmal2";
>> + dcr-reg = <180 62>;
>> + num-tx-chans = <4>;
>> + num-rx-chans = <4>;
>> + interrupt-parent = <&MAL0>;
>> + interrupts = <0 1 2 3 4>;
>> + #interrupt-cells = <1>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + interrupt-map = </*TXEOB*/ 0 &UIC0 a 4
>> + /*RXEOB*/ 1 &UIC0 b 4
>> + /*SERR*/ 2 &UIC1 0 4
>> + /*TXDE*/ 3 &UIC1 1 4
>> + /*RXDE*/ 4 &UIC1 2 4>;
>> + interrupt-map-mask = <ffffffff>;
>> + };
>> +
>> + POB0: opb {
>> + compatible = "ibm,opb-440gp", "ibm,opb";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + /* Bamboo is oddball in the 44x world and doesn't use the ERPN
>> + * bits.
>> + */
>
> Comment is for Bamboo and does not match the ranges property below.
Oops :)
>
>> + ranges = <00000000 1 00000000 80000000
>> + 80000000 1 80000000 80000000>;
>> + interrupt-parent = <&UIC1>;
>> + interrupts = <7 4>;
>> + clock-frequency = <0>; /* Filled in by zImage */
>> +
>> + EBC0: ebc {
>> + compatible = "ibm,ebc-440gp";
>> + dcr-reg = <012 2>;
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + clock-frequency = <0>; /* Filled in by zImage */
>> + interrupts = <5 1>;
>> + interrupt-parent = <&UIC1>;
>> +
>> + nor_flash@0,0 {
>> + device_type = "rom";
>> + compatible = "direct-mapped";
>> + probe-type = "CFI";
>
> This flash binding needs to be replaced, but I guess that's not really
> your problem.
>
>> + bank-width = <2>;
>> + partitions = < 0 180000
>> + 180000 200000
>> + 380000 3aa0000
>> + 3e20000 140000
>> + 3f60000 40000
>> + 3fa0000 60000>;
>> + partition-names = "Kernel", "ramdisk", "file system",
>> + "kozio", "env", "u-boot";
>> + reg = <0 000000 4000000>;
>> + };
>> +
>> + };
>> +
>> + UART0: serial@ef600300 {
>> + device_type = "serial";
>> + compatible = "ns16550";
>> + reg = <ef600300 8>;
>> + virtual-reg = <ef600300>;
>> + clock-frequency = <0>; /* Filled in by zImage */
>> + current-speed = <1c200>;
>> + interrupt-parent = <&UIC0>;
>> + interrupts = <0 4>;
>> + };
>> +
>> + UART1: serial@ef600400 {
>> + device_type = "serial";
>> + compatible = "ns16550";
>> + reg = <ef600400 8>;
>> + virtual-reg = <ef600400>;
>> + clock-frequency = <0>;
>> + current-speed = <0>;
>> + interrupt-parent = <&UIC0>;
>> + interrupts = <1 4>;
>> + };
>> +
>> + UART2: serial@ef600500 {
>> + device_type = "serial";
>> + compatible = "ns16550";
>> + reg = <ef600500 8>;
>> + virtual-reg = <ef600500>;
>> + clock-frequency = <0>;
>> + current-speed = <0>;
>> + interrupt-parent = <&UIC1>;
>> + interrupts = <3 4>;
>> + };
>> +
>> + UART3: serial@ef600600 {
>> + device_type = "serial";
>> + compatible = "ns16550";
>> + reg = <ef600600 8>;
>> + virtual-reg = <ef600600>;
>> + clock-frequency = <0>;
>> + current-speed = <0>;
>> + interrupt-parent = <&UIC1>;
>> + interrupts = <4 4>;
>> + };
>> +
>> + IIC0: i2c@ef600700 {
>> + device_type = "i2c";
>> + compatible = "ibm,iic-440gp", "ibm,iic";
>> + reg = <ef600700 14>;
>> + interrupt-parent = <&UIC0>;
>> + interrupts = <2 4>;
>> + };
>> +
>> + IIC1: i2c@ef600800 {
>> + device_type = "i2c";
>> + compatible = "ibm,iic-44gp", "ibm,iic";
>> + reg = <ef600800 14>;
>> + interrupt-parent = <&UIC0>;
>> + interrupts = <7 4>;
>> + };
>> +
>> + ZMII0: emac-zmii@ef600d00 {
>> + device_type = "zmii-interface";
>> + compatible = "ibm,zmii-440gp", "ibm,zmii";
>> + reg = <ef600d00 c>;
>> + };
>> +
>> + EMAC0: ethernet@ef600e00 {
>> + linux,network-index = <0>;
>> + device_type = "network";
>> + compatible = "ibm,emac-440spe", "ibm,emac4", "ibm,emac-axon";
>
> "ibm,emac-axon" is definitely wrong, since this isn't an Axon chip.
The chip uses EMACX_STACR_STAC_READ and EMACX_STACR_STAC_WRITE bits with
mdio_read/mdio_write commands. These are only enabled if the chip is
axon-compatible.
---
if (device_is_compatible(np, "ibm,emac-axon"))
dev->features |= EMAC_FTR_HAS_AXON_STACR
---
>
>> + interrupt-parent = <&EMAC0>;
>> + interrupts = <0 1>;
>> + #interrupt-cells = <1>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + interrupt-map = </*Status*/ 0 &UIC0 18 4
>> + /*Wake*/ 1 &UIC1 1d 4>;
>> + reg = <ef600e00 70>;
>> + local-mac-address = [000000000000];
>> + mal-device = <&MAL0>;
>> + mal-tx-channel = <0 1>;
>> + mal-rx-channel = <0>;
>> + cell-index = <0>;
>> + max-frame-size = <5dc>;
>> + rx-fifo-size = <1000>;
>> + tx-fifo-size = <800>;
>> + phy-mode = "rmii";
>> + phy-map = <00000000>;
>> + zmii-device = <&ZMII0>;
>> + zmii-channel = <0>;
>> + };
>> +
>> + EMAC1: ethernet@ef600f00 {
>> + linux,network-index = <1>;
>> + device_type = "network";
>> + compatible = "ibm,emac-440spe", "ibm,emac4", "ibm,emac-axon";
>> + interrupt-parent = <&EMAC1>;
>> + interrupts = <0 1>;
>> + #interrupt-cells = <1>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + interrupt-map = </*Status*/ 0 &UIC0 19 4
>> + /*Wake*/ 1 &UIC1 1f 4>;
>> + reg = <ef600f00 70>;
>> + local-mac-address = [000000000000];
>> + mal-device = <&MAL0>;
>> + mal-tx-channel = <2 3>;
>> + mal-rx-channel = <1>;
>> + cell-index = <1>;
>> + max-frame-size = <5dc>;
>> + rx-fifo-size = <1000>;
>> + tx-fifo-size = <800>;
>> + phy-mode = "rmii";
>> + phy-map = <00000000>;
>> + zmii-device = <&ZMII0>;
>> + zmii-channel = <1>;
>> + };
>> + };
>> + };
>> +
>> + chosen {
>> + linux,stdout-path = "/plb/opb/serial@ef600300";
>> + bootargs = "console=ttyS0,115200";
>> + };
>> +};
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>
Thanks for review,
Valentine.
^ permalink raw reply
* Re: [2.6 patch] ppc .gitignore update
From: Grant Likely @ 2007-08-01 13:53 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Rutger Nijlunsing, Paul Mackerras, linux-kernel, linuxppc-dev
In-Reply-To: <20070801133056.GP3972@stusta.de>
On 8/1/07, Adrian Bunk <bunk@stusta.de> wrote:
> arch/ppc/.gitignore shouldn't exclude arch/ppc/boot/include
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> ---
> --- /dev/null 2006-09-19 00:45:31.000000000 +0200
> +++ linux-2.6.23-rc1-mm2/arch/ppc/boot/.gitignore 2007-08-01 15:18:33.000000000 +0200
> @@ -0,0 +1 @@
> +!include
I don't think this is the best way to go about it; rather,
arch/ppc/.gitignore should be made more specific like so:
diff --git a/arch/ppc/.gitignore b/arch/ppc/.gitignore
index a1a869c..1e79a0a 100644
--- a/arch/ppc/.gitignore
+++ b/arch/ppc/.gitignore
@@ -1 +1 @@
-include
+/include
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply related
* [2.6 patch] ppc .gitignore update
From: Adrian Bunk @ 2007-08-01 13:30 UTC (permalink / raw)
To: Rutger Nijlunsing, Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
arch/ppc/.gitignore shouldn't exclude arch/ppc/boot/include
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
--- /dev/null 2006-09-19 00:45:31.000000000 +0200
+++ linux-2.6.23-rc1-mm2/arch/ppc/boot/.gitignore 2007-08-01 15:18:33.000000000 +0200
@@ -0,0 +1 @@
+!include
^ permalink raw reply
* Re: [RFC][PATCH] MPC832x_RDB: update dts to use spi, register mmc_spi stub
From: Anton Vorontsov @ 2007-08-01 13:29 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <b3d36996792216ddd9dbae12212a4168@kernel.crashing.org>
On Wed, Aug 01, 2007 at 12:06:46AM +0200, Segher Boessenkool wrote:
>>>> 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?
>> 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.
>>>> + max-chipselect = <1>;
>>>
>>> I'm not sure how I feel about this in here, I'm thinking it should go.
>>
>> It's board-specific, i.e. how much chips connected to this SPI bus.
>
> It is misnamed then. It should be automatically derived from
> the child nodes, though.
>
>>>> + mmc@01 {
>
> @01 should be @1. Except that it is wrong, since there is
> no "reg" property.
>
>>>> + device_type = "mmc";
>
> No device_type please.
>
>>>> + compatible = "mmc-spi";
>
> Needs to be more specific.
Um.. for example? I can't imagine anything specific for this. ;-)
>>>> + device-id = <1>;
>
> Get rid of this.
>
>>>> + max-speed-hz = <bebc20>; /* 12500000 Hz */
>
> Just max-speed.
>
>>>> + chip-select = <0>;
>
> This should be named "reg". And the parent needs #address-cells
> and #size-cells properties.
>
>>>> + 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?
> Segher
Thanks!
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] MPC8349E-mITX: use platform IDE driver for CF interface
From: Sergei Shtylyov @ 2007-08-01 13:11 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linux-ide, linuxppc-dev, linux-kernel
In-Reply-To: <a414f3b506b7802a717e6e2c08befd1e@kernel.crashing.org>
Hello.
Segher Boessenkool wrote:
>>>> + ide@f0000000 {
>>>> + compatible = "mmio-ide";
>>>> + device_type = "ide";
>>> Why not "ata"?
> The hardware is called (E)IDE, the protocol is called ATA.
Sorry for not denouncing this earlier. :-)
ATA is the name of ANSI standard describing IDE.
> Or that's what I was told --
Re-check your sources. ;-)
> I think there's some historic revisionism involved, too.
IDE was probably an initial name of the infamous disk hardware/protocol
later standardized as ATA, EIDE (being more of a trademark) more or less
equals to ATA-2.
>> Also, what mmio-ide in the compat properly means in the context of
>> ide_platform which is able to handle both port and memory mapped IDE.
>> I think
>> we must get rid with this crap, and since this IDE register mapping is
>> pretty
>> much board specific, call it something like "mpc8349emitx-ide" instead.
> "mmio-ide" simply is not specific enough. The device_type
Yes.
> should go, too.
> If this IDE interface is board-specific, thee "compatible"
It's "thy", not "thee". ;-)
> property should include the board vendor name and board
> name. Oh, that's what "emitx" tries to do -- it could be
> a bit clearer perhaps ;-)
Yeah, I forgot about the vondor's "fsl," prefix.
> Segher
MBR, Sergei
^ permalink raw reply
* Re: Generic clk.h wrappers? [Was: Re: [PATCH 1/3] powerpc clk.h interface for platforms]
From: Christoph Hellwig @ 2007-08-01 12:57 UTC (permalink / raw)
To: Domen Puncer
Cc: David Brownell, linuxppc-dev, Christoph Hellwig, Russell King,
linux-mips
In-Reply-To: <20070801072807.GL4529@moe.telargo.com>
On Wed, Aug 01, 2007 at 09:28:07AM +0200, Domen Puncer wrote:
> > It doesn't make any assumption on struct clk, it's just a
> > wrapper around functions from clk.h.
> > Point of this patch was to abstract exported functions, since
> > arch/powerpc/ can support multiple platfroms in one binary.
>
> So... the thread just ended without any consensus, ACK or whatever.
>
> Choices I see:
> - have EXPORT_SYMBOL for clk.h functions in ie. lib/clock.c and have
> every implemenation fill some global struct.
> - leave this patch as it is, abstraction only for arch/powerpc/.
> - or I can just forget about this, and leave it for the next sucker
> who will want nicer clock handling in some driver
It seems like arm really wants this optimized to the last cycle
and no abstraction inbetween so we're probably stuck with the status
quo. I'm pretty sure this will get too messy sooner and later and
people will clean the mess up, but due to the political issues I
don't think it's fair to put that burden on you just for submitting
the powerpc implementation.
So, please leave the patch as-is.
^ permalink raw reply
* Re: [PATCH] lite5200b: flash definition in dts
From: Grant Likely @ 2007-08-01 12:41 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-embedded
In-Reply-To: <20070801065203.GK4529@moe.telargo.com>
On 8/1/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> Add flash definition for to lite5200b dts, and while at it
> fix "ranges" for soc node.
>
>
> Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
>
> ---
> Hi!
>
> Sylvain, it would be nice to have this merged.
>
> # cat /proc/mtd
> dev: size erasesize name
> mtd0: 01000000 00020000 "data0"
> mtd1: 00f00000 00020000 "data1"
> mtd2: 00100000 00020000 "u-boot"
>
> Some benchmarks:
> read: 2.3 MB/s
> erase: 168 kB/s
> write: 7.3 kB/s
>
>
> arch/powerpc/boot/dts/lite5200b.dts | 24 +++++++++++++++++++++++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> Index: work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
> ===================================================================
> --- work-powerpc.git.orig/arch/powerpc/boot/dts/lite5200b.dts
> +++ work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
> @@ -52,7 +52,8 @@
> revision = ""; // from bootloader
> #interrupt-cells = <3>;
> device_type = "soc";
> - ranges = <0 f0000000 f0010000>;
> + ranges = <00000000 f0000000 00010000
> + fe000000 fe000000 02000000>;
I don't think this is the right approach. I think the SoC node is
intended for describing the on-chip devices, and the ranges property
reflects that. Shouldn't flash nodes be up 1 level?
Cheers,
g.
> reg = <f0000000 00010000>;
> bus-frequency = <0>; // from bootloader
> system-frequency = <0>; // from bootloader
> @@ -403,5 +404,26 @@
> compatible = "mpc5200b-sram\0mpc5200-sram\0sram";
> reg = <8000 4000>;
> };
> +
> + flash@fe000000 {
> + device_type = "rom";
> + compatible = "direct-mapped";
> + probe-type = "CFI";
> + reg = <fe000000 01000000>;
> + bank-width = <1>;
> + partitions = <00000000 01000000>;
> + partition-names = "data0";
> + };
> +
> + flash@ff000000 {
> + device_type = "rom";
> + compatible = "direct-mapped";
> + probe-type = "CFI";
> + reg = <ff000000 01000000>;
> + bank-width = <1>;
> + partitions = <00000000 00f00000
> + 00f00000 00100000>;
> + partition-names = "data1", "u-boot";
> + };
> };
> };
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 1/2] [IDE] Platform IDE driver
From: Sergei Shtylyov @ 2007-08-01 12:39 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-kernel, linux-ide
In-Reply-To: <d04530fcd6e879e0bc059049b7951aef@kernel.crashing.org>
Hello.
Segher Boessenkool wrote:
>> This doesn't mean that shift is better anyway. If everyone
>> considers it
>> better, I give up. But be warned that shift (stride) is not the only
>> property
>> characterizing register accesses -- the regs might be only accessible as
>> 16/32-bit quantities, for example (16-bit is a real world example -- from
>> Amiga or smth of that sort, IIRC).
> 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...
> The only realistic way to handle all this is to put some
> knowledge into the device driver. This does of course
> also mean that no "reg-shift" property is needed; the
> device driver can look at your "compatible" property,
> instead.
>>>> Why the heck should we care about the UART code taling about IDE?!
>>> Consistency?
>> We're not obliged to be consistent with every piece of the kernel
>> code.
> 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.
> Segher
WBR, Sergei
^ 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