* Re: EDAC stats & PCI error recovery (was Re: [PATCH 2/2] powerpc: MPC85xx EDAC device driver)
From: Doug Thompson @ 2007-08-01 20:34 UTC (permalink / raw)
To: Linas Vepstas
Cc: amitkale, linux-scsi, Arnd Bergmann, halr, openib-general,
munsone, linuxppc-dev, mpt_linux_developer, norsk5, Eric.Moore,
bluesmoke-devel
In-Reply-To: <20070801194857.GL4884@austin.ibm.com>
--- Linas Vepstas <linas@austin.ibm.com> wrote:
> On Mon, Jul 30, 2007 at 03:47:05PM -0700, Doug Thompson wrote:
> >
> > --- Linas Vepstas <linas@austin.ibm.com> wrote:
> > > Also: please note that the linux kernel has a pci error recovery
> > > mechanism built in; its used by pseries and PCI-E. I'm not clear
> > > on what any of this has to do with EDAC, which I thought was supposed
> > > to be for RAM only. (The EDAC project once talked about doing pci error
> > > recovery, but that was years ago, and there is a separate system for
> > > that, now.)
> >
> > no, edac can/does harvest PCI bus errors, via polling and other hardware error detectors.
>
> Ehh! I had no idea. A few years ago, when I was working on the PCI error
> recovery, I sent a number of emails to the various EDAC people and mailing
> lists that I could find, and never got a response. I assumed the
> project was dead. I guess its not ...
No its not, just some company lay offs stirred the pot, at least for me, for awhile.
I did see the ibm patches go by, but didn't have the time to check up at that time. I actually,
didn't know the recovery interface had gotten into the kernel (My failure to watch for them), so I
was pleasantly surprised at this last OLS to attend the presentation.
>
> > But at the current time, few PCI device drivers initialize those callback functions and
> > thus errors are lost and some IO transactions fail.
>
> There are patches for 6 drivers in mainline (e100, e1000, ixgb, s2io,
> ipr, lpfc), and two more pending (sym53cxxx, tg3). So far, I've written
> all of them.
Great.
EDAC does nothing for recovery, just logging and stats gathering and presentation.
>
> > Over time, as drivers get updated (might take some time) then drivers
> > can take some sort of action FOR THEMSELVES
>
> I think I need to do more to raise awareness and interest.
good point
>
> > Yet, there is no tracking of errors - except for a log message in the log file.
> >
> > There is NO meter on frequency of errors, etc. One must grep the log file and that is not a
> very
> > cycle friendly mechanism.
>
> Yeah, there was low interest in stats. There's a core set of stats in
> /proc/pp64/eeh, but these are clearly arch-specific. I'd ike to move
> away from those. Some recent patches added stats to the /sys tree,
> under the individual pci bridge and device nodes. Again, these are
> arch-specific; I'd like to move to some geeral/standardized presentation.
the memory error consumers really like the stats of EDAC. Allows them to track trends.
Cluster types, with thousands of nodes, like the monitoring for both memory and PCI, as well as
some newer hardware detector harvesting.
>
> > The reason I added PCI parity/error device scanning, was that when I was at Linux Networx, we
> had
> > parity errors on the PCI-X bus, but didn't know the cause. After we discovered that a simple
> > PCI-X riser card had manufacturing problems (quality) and didn't drive lines properly, it
> caused
> > parity errors.
>
> Heh. Not unusual. I've seen/heard of cases with voltages being low,
> and/or ground-bounce in slots near the end. There's a whole zoo of
> hardware/firmware bugs that we've had to painfully crawl through and
> fix. That's why the IBM boxes cost big $$$; here's to hoping that
> customers understand why.
I understand
>
> > This feature allowed us to track nodes that were having parity problems, but we had
> > no METER to know it.
> >
> > Recovery is a good thing, BUT how do you know you having LOTS of errors/recovery events? You
> need
> > a meter. EDAC provides that METER
>
> I'm lazy. What source code should I be looking at? I'm concerned about
> duplication of function and proliferation of interfaces. I've got my
> metering data under (for example)
> /sys/bus/pci/devices/0001:c0:01.0/eeh_*, mostly very arch specific.
> The code for this is in arch/powerpc/platforms/pseries/eeh_sysfs.c
http://bluesmoke.sourceforge.net/
is the SF project zone (bluesmoke was the out-of-tree name, changed to EDAC when it came into
tree, and source forge doesn't allow renaming)
EDAC info is under:
/sys/devices/system/edac/....
mc for memory controllers
pci for pci info.
very basic, just counters and some controls
>
> > I met with Yanmin Zhang of Intel at OLS after his paper presentation on PCI Express Advanced
> Error
> > Reporting in the Kernel, and we talked about this same thing. I am talking with him on having
> the
> > recovery code present information into EDAC sysfs area. (hopefully, anyway)
>
> Hmm. OK, where's that? Back when, I'd talked to Yamin about coming up
> with a generic, arch-indep way of driving the recovery routines. But
> this wasn't exactly easy, and we were still grappling with just getting
> things working. Now that things are working, its time to broaden
> horizons.
Not very far, but I see the potential.
When EDAC was received, it was placed where it was in the sysfs from various kernel developers as
a good spot on its own.
>
> Can you point me to the current edac code?
> find . -print |grep edac is not particuarly revealing at the moment.
drivers/edac
latest is in 2.6.23-rc1.
-rc2 will have a few vital bug fixes. This release is fairly large since 2.6.26 when it first was
in the tree.
>
> > The recovery generates log messages BUT having to periodically 'grep' the log file looking for
> > errors is not a good use of CPU cycles. grep once for a count and then grep later for a count
> and
> > then compare the counts for a delta count per unit time. ugly.
>
> Yep. Maybe send events up to udev?
That is a possibility, yet EDAC consumers like the stats being available as well.
>
> > The EDAC solution is to be able to have a Listener thread in user space that can be notified
> (via
> > poll()) that an event has occurred.
>
> Hmm. OK, I'm alarmingly nave about udev, but my initial gut instinct is
> to pipe all such events to udev. Most of user-space has already been
> given the marching orders to use udev and/or hal for this kind of stuff.
> So this makes sense to me.
I need a learning process as well on udev.
It being the unified highway of event notification from kernel to user space. Although, when
memory errors fires, sometimes they can generate MASSIVE Number of events on every memory access.
PCI being different might have different constraints. Each needs investigation and classification
of timing, etc.
>
> > There are more than one consumer (error recover) of error events:
> > 1) driver recovery after a transaction (which is the recovery consumer above)
>
> I had to argue loudly for recovery in the kernel. The problem was that
> it was impossible to recover erros on scsi devics from userspace (since
> the block device and filesystems would go bonkers).
I hear you. It took the cluster consumers to demand ROBUST "meters" to for their machines to give
'validation' (so to speak) of their calculations. Bluesmoke/EDAC became that in our sandbox.
>
> > 2) Management agents for health of a node
> > 3) Maintainance agents for predictive component replacement
>
> Yes, agreed. Care to ask your management agent friends for where they'd
> like to get these events from (i.e. udev, or somewhere else?)
They are in a learning curve as well.
Error event processing is still so "young" under linux. Getting people aware of it is the current
push.
>
> > We have MEMORY (edac_mc) devices for chipsets now, but via the new edac_device class, such
> things
> > as ECC error tracking on DMA error checkers, FABRIC switchs, L1 and L2 cache ECC events, core
> CPU
> > data ECC checkers, etc can be done. I have an out of kernel tree MIPS driver do just this.
> Other
> > types of harvesters can be generated as well for other and/or new hardware error detectors.
>
> Ohh. I've got hardware tha does this, but its not currently usng EDAC.
> There must be some edac mailing list I'm not subscribed to??
the new edac_device class rolled out in 2.6.23-rc1
No in tree drivers, but I have a test_device_edac module that uses it and it is in the svn repos.
I need to update the edac tarball to contain this stuff.
for mailing list, goto
http://bluesmoke.sourceforge.net/
find the subscribe to mailing list action item. Fairly low bandwidth, but has notices, and some
discussion on things now and then.
bluesmoke-devel@lists.sourceforge.net is the development email
doug t
>
> --linas
>
>
^ permalink raw reply
* MPC83xx - previous patch to set MBAR
From: Keith Mund @ 2007-08-01 20:20 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <fa686aa40708010653v7e1fb909gb03eb1d4754359bf@mail.gmail.com>
There was a u-boot 1.1.3 patch for start.S posted on the Freescale LTIB
site:
http://www.bitshrine.org/gpp/u-boot-1.1.3-mpc83xx-cpu-4.patch
The end result simply adds a line to set MBAR to match IMMRBAR.
lis r3, CFG_IMMRBAR@h
ori r3, r3, CFG_IMMRBAR@l
stw r3, IMMRBAR(r4)
+ mtspr MBAR, r3
Are these patches routinely added to the mainstream u-boot code?=20
Is there any reason why this fix is not a good idea?
^ permalink raw reply
* [PATCH 1/1] ibmveth: Fix rx pool deactivate oops
From: Brian King @ 2007-08-01 20:26 UTC (permalink / raw)
To: santil; +Cc: linuxppc-dev, rcjenn, brking, netdev
This fixes the following oops which can occur when trying to deallocate
receive buffer pools using sysfs with the ibmveth driver.
NIP: d00000000024f954 LR: d00000000024fa58 CTR: c0000000000d7478
REGS: c00000000ffef9f0 TRAP: 0300 Not tainted (2.6.22-ppc64)
MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24242442 XER: 00000010
DAR: 00000000000007f0, DSISR: 0000000042000000
TASK = c000000002f91360[2967] 'bash' THREAD: c00000001398c000 CPU: 2
GPR00: 0000000000000000 c00000000ffefc70 d000000000262d30 c00000001c4087a0
GPR04: 00000003000000fe 0000000000000000 000000000000000f c000000000579d80
GPR08: 0000000000365688 c00000001c408998 00000000000007f0 0000000000000000
GPR12: d000000000251e88 c000000000579d80 00000000200957ec 0000000000000000
GPR16: 00000000100b8808 00000000100feb30 0000000000000000 0000000010084828
GPR20: 0000000000000000 000000001014d4d0 0000000000000010 c00000000ffefeb0
GPR24: c00000001c408000 0000000000000000 c00000001c408000 00000000ffffb054
GPR28: 00000000000000fe 0000000000000003 d000000000262700 c00000001c4087a0
NIP [d00000000024f954] .ibmveth_remove_buffer_from_pool+0x38/0x108 [ibmveth]
LR [d00000000024fa58] .ibmveth_rxq_harvest_buffer+0x34/0x78 [ibmveth]
Call Trace:
[c00000000ffefc70] [c0000000000280a8] .dma_iommu_unmap_single+0x14/0x28 (unreliable)
[c00000000ffefd00] [d00000000024fa58] .ibmveth_rxq_harvest_buffer+0x34/0x78 [ibmveth]
[c00000000ffefd80] [d000000000250e40] .ibmveth_poll+0xd8/0x434 [ibmveth]
[c00000000ffefe40] [c00000000032da8c] .net_rx_action+0xdc/0x248
[c00000000ffefef0] [c000000000068b4c] .__do_softirq+0xa8/0x164
[c00000000ffeff90] [c00000000002789c] .call_do_softirq+0x14/0x24
[c00000001398f6f0] [c00000000000c04c] .do_softirq+0x68/0xac
[c00000001398f780] [c000000000068ca0] .irq_exit+0x54/0x6c
[c00000001398f800] [c00000000000c8e4] .do_IRQ+0x170/0x1ac
[c00000001398f890] [c000000000004790] hardware_interrupt_entry+0x18/0x1c
Exception: 501 at .plpar_hcall_norets+0x24/0x94
LR = .veth_pool_store+0x15c/0x298 [ibmveth]
[c00000001398fb80] [d000000000250b2c] .veth_pool_store+0x5c/0x298 [ibmveth] (unreliable)
[c00000001398fc30] [c000000000145530] .sysfs_write_file+0x140/0x1d8
[c00000001398fcf0] [c0000000000de89c] .vfs_write+0x120/0x208
[c00000001398fd90] [c0000000000df2c8] .sys_write+0x4c/0x8c
[c00000001398fe30] [c0000000000086ac] syscall_exit+0x0/0x40
Instruction dump:
fba1ffe8 fbe1fff8 789d0022 f8010010 f821ff71 789c0020 1d3d00a8 7b8a1f24
38000000 7c7f1b78 7d291a14 e9690128 <7c0a592a> e8030000 e9690120 80a90100
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 24 ++++++++++++++----------
linux-2.6-bjking1/drivers/net/ibmveth.h | 3 ---
2 files changed, 14 insertions(+), 13 deletions(-)
diff -puN drivers/net/ibmveth.c~ibmveth_fixup_pool_deactivate drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_fixup_pool_deactivate 2007-08-01 10:22:37.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-08-01 10:23:20.000000000 -0500
@@ -1280,24 +1280,28 @@ const char * buf, size_t count)
int i;
/* Make sure there is a buffer pool with buffers that
can hold a packet of the size of the MTU */
- for(i = 0; i<IbmVethNumBufferPools; i++) {
+ for (i = 0; i < IbmVethNumBufferPools; i++) {
if (pool == &adapter->rx_buff_pool[i])
continue;
if (!adapter->rx_buff_pool[i].active)
continue;
- if (mtu < adapter->rx_buff_pool[i].buff_size) {
- pool->active = 0;
- h_free_logical_lan_buffer(adapter->
- vdev->
- unit_address,
- pool->
- buff_size);
- }
+ if (mtu <= adapter->rx_buff_pool[i].buff_size)
+ break;
}
- if (pool->active) {
+
+ if (i == IbmVethNumBufferPools) {
ibmveth_error_printk("no active pool >= MTU\n");
return -EPERM;
}
+
+ pool->active = 0;
+ if (netif_running(netdev)) {
+ adapter->pool_config = 1;
+ ibmveth_close(netdev);
+ adapter->pool_config = 0;
+ if ((rc = ibmveth_open(netdev)))
+ return rc;
+ }
}
} else if (attr == &veth_num_attr) {
if (value <= 0 || value > IBMVETH_MAX_POOL_COUNT)
diff -puN drivers/net/ibmveth.h~ibmveth_fixup_pool_deactivate drivers/net/ibmveth.h
--- linux-2.6/drivers/net/ibmveth.h~ibmveth_fixup_pool_deactivate 2007-08-01 14:45:09.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.h 2007-08-01 14:45:21.000000000 -0500
@@ -73,9 +73,6 @@ static inline long h_send_logical_lan(un
#define h_change_logical_lan_mac(ua, mac) \
plpar_hcall_norets(H_CHANGE_LOGICAL_LAN_MAC, ua, mac)
-#define h_free_logical_lan_buffer(ua, bufsize) \
- plpar_hcall_norets(H_FREE_LOGICAL_LAN_BUFFER, ua, bufsize)
-
#define IbmVethNumBufferPools 5
#define IBMVETH_BUFF_OH 22 /* Overhead: 14 ethernet header + 8 opaque handle */
#define IBMVETH_MAX_MTU 68
_
^ permalink raw reply
* FEC driver not working after upgrade
From: Mit Matelske @ 2007-08-01 19:47 UTC (permalink / raw)
To: linuxppc-dev
I upgraded from an old 2.4.25 kernel to the latest Denx snapshot and cannot
get the ethernet to work. I was previously running the FEC driver that used
the sdma interface. I get a couple of interrupts and that is it.
Output when initializing:
mpc5xxx_fec_init
fec_priv c3f83160
MPC5200 I2S driver (16 BDs x 16 bytes).
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
mpc5xxx_fec_open
mpc5xxx_fec_restart
eth0: duplex set to 1
mii_queue: 600a0000 c0130bb0 00000000
mpc5xxx_fec_interrupt:
mpc5xxx_fec_mii 60080141 c0130bb0 00000000
mii_discover_phy
mii_queue: 600e0000 c0130abc 00000000
mpc5xxx_fec_interrupt:
mpc5xxx_fec_mii 600e0c87 c0130abc 00000000
eth0: Phy @ 0x0, type 88E6060 (0x01410c87)
Whenever I try to transmit anything I get:
mpc5xxx_fec_hard_start_xmit:
dev c3f83000, priv c3f83160, skb c3bcc860
The phy code works in the old fec driver fine, but I have tried the generic
phy driver also and it acts exactly the same.
The major change was done by this patch back on Sept 4, 2005:
Modifications to the MPC5200 ATA and FEC drivers based on the
linuxppc_2_4_devel-fec+ata.patch and linux.habanero.fifo_cntrl.patch
patches from Freescale.
I am running a 5200B. Thanks for any help.
Mit
--
View this message in context: http://www.nabble.com/FEC-driver-not-working-after-upgrade-tf4202285.html#a11952546
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* EDAC & PCI error recovery (was Re: [PATCH 2/2] powerpc: MPC85xx EDAC device driver)
From: Linas Vepstas @ 2007-08-01 19:48 UTC (permalink / raw)
To: dougthompson
Cc: amitkale, linux-scsi, Arnd Bergmann, halr, openib-general,
munsone, linuxppc-dev, mpt_linux_developer, norsk5, Eric.Moore,
bluesmoke-devel
In-Reply-To: <845900.3390.qm@web50107.mail.re2.yahoo.com>
On Mon, Jul 30, 2007 at 03:47:05PM -0700, Doug Thompson wrote:
>
> --- Linas Vepstas <linas@austin.ibm.com> wrote:
> > Also: please note that the linux kernel has a pci error recovery
> > mechanism built in; its used by pseries and PCI-E. I'm not clear
> > on what any of this has to do with EDAC, which I thought was supposed
> > to be for RAM only. (The EDAC project once talked about doing pci error
> > recovery, but that was years ago, and there is a separate system for
> > that, now.)
>
> no, edac can/does harvest PCI bus errors, via polling and other hardware error detectors.
Ehh! I had no idea. A few years ago, when I was working on the PCI error
recovery, I sent a number of emails to the various EDAC people and mailing
lists that I could find, and never got a response. I assumed the
project was dead. I guess its not ...
> But at the current time, few PCI device drivers initialize those callback functions and
> thus errors are lost and some IO transactions fail.
There are patches for 6 drivers in mainline (e100, e1000, ixgb, s2io,
ipr, lpfc), and two more pending (sym53cxxx, tg3). So far, I've written
all of them.
> Over time, as drivers get updated (might take some time) then drivers
> can take some sort of action FOR THEMSELVES
I think I need to do more to raise awareness and interest.
> Yet, there is no tracking of errors - except for a log message in the log file.
>
> There is NO meter on frequency of errors, etc. One must grep the log file and that is not a very
> cycle friendly mechanism.
Yeah, there was low interest in stats. There's a core set of stats in
/proc/pp64/eeh, but these are clearly arch-specific. I'd ike to move
away from those. Some recent patches added stats to the /sys tree,
under the individual pci bridge and device nodes. Again, these are
arch-specific; I'd like to move to some geeral/standardized presentation.
> The reason I added PCI parity/error device scanning, was that when I was at Linux Networx, we had
> parity errors on the PCI-X bus, but didn't know the cause. After we discovered that a simple
> PCI-X riser card had manufacturing problems (quality) and didn't drive lines properly, it caused
> parity errors.
Heh. Not unusual. I've seen/heard of cases with voltages being low,
and/or ground-bounce in slots near the end. There's a whole zoo of
hardware/firmware bugs that we've had to painfully crawl through and
fix. That's why the IBM boxes cost big $$$; here's to hoping that
customers understand why.
> This feature allowed us to track nodes that were having parity problems, but we had
> no METER to know it.
>
> Recovery is a good thing, BUT how do you know you having LOTS of errors/recovery events? You need
> a meter. EDAC provides that METER
I'm lazy. What source code should I be looking at? I'm concerned about
duplication of function and proliferation of interfaces. I've got my
metering data under (for example)
/sys/bus/pci/devices/0001:c0:01.0/eeh_*, mostly very arch specific.
The code for this is in arch/powerpc/platforms/pseries/eeh_sysfs.c
> I met with Yanmin Zhang of Intel at OLS after his paper presentation on PCI Express Advanced Error
> Reporting in the Kernel, and we talked about this same thing. I am talking with him on having the
> recovery code present information into EDAC sysfs area. (hopefully, anyway)
Hmm. OK, where's that? Back when, I'd talked to Yamin about coming up
with a generic, arch-indep way of driving the recovery routines. But
this wasn't exactly easy, and we were still grappling with just getting
things working. Now that things are working, its time to broaden
horizons.
Can you point me to the current edac code?
find . -print |grep edac is not particuarly revealing at the moment.
> The recovery generates log messages BUT having to periodically 'grep' the log file looking for
> errors is not a good use of CPU cycles. grep once for a count and then grep later for a count and
> then compare the counts for a delta count per unit time. ugly.
Yep. Maybe send events up to udev?
> The EDAC solution is to be able to have a Listener thread in user space that can be notified (via
> poll()) that an event has occurred.
Hmm. OK, I'm alarmingly nave about udev, but my initial gut instinct is
to pipe all such events to udev. Most of user-space has already been
given the marching orders to use udev and/or hal for this kind of stuff.
So this makes sense to me.
> There are more than one consumer (error recover) of error events:
> 1) driver recovery after a transaction (which is the recovery consumer above)
I had to argue loudly for recovery in the kernel. The problem was that
it was impossible to recover erros on scsi devics from userspace (since
the block device and filesystems would go bonkers).
> 2) Management agents for health of a node
> 3) Maintainance agents for predictive component replacement
Yes, agreed. Care to ask your management agent friends for where they'd
like to get these events from (i.e. udev, or somewhere else?)
> We have MEMORY (edac_mc) devices for chipsets now, but via the new edac_device class, such things
> as ECC error tracking on DMA error checkers, FABRIC switchs, L1 and L2 cache ECC events, core CPU
> data ECC checkers, etc can be done. I have an out of kernel tree MIPS driver do just this. Other
> types of harvesters can be generated as well for other and/or new hardware error detectors.
Ohh. I've got hardware tha does this, but its not currently usng EDAC.
There must be some edac mailing list I'm not subscribed to??
--linas
^ permalink raw reply
* Re: [RFC][PATCH] MPC832x_RDB: update dts to use spi, register mmc_spi stub
From: Kim Phillips @ 2007-08-01 19:16 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <b3d36996792216ddd9dbae12212a4168@kernel.crashing.org>
On Wed, 1 Aug 2007 00:06:46 +0200
Segher Boessenkool <segher@kernel.crashing.org> wrote:
> >>> + max-speed-hz = <bebc20>; /* 12500000 Hz */
>
> Just max-speed.
Segher, how is this different from:
http://ozlabs.org/pipermail/linuxppc-dev/2007-April/034557.html
?
Kim
^ permalink raw reply
* Re: [PATCH] POWERPC 8xx: bump up initial memory limit for 8xx
From: Scott Wood @ 2007-08-01 19:13 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070717011723.23549.44672.stgit@localhost.localdomain>
Vitaly Bordug wrote:
> From: John Traill <john.traill@freescale.com>
>
> The 8xx can only support a max of 8M during early boot ( it seems a lot of
> 8xx boards only have 8M so the bug was never triggered ). The following
> change makes it able to run with 128M.
>
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
>
> ---
>
> arch/powerpc/mm/init_32.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
> index e1f5ded..7cee86d 100644
> --- a/arch/powerpc/mm/init_32.c
> +++ b/arch/powerpc/mm/init_32.c
> @@ -133,6 +133,9 @@ void __init MMU_init(void)
> /* 601 can only access 16MB at the moment */
> if (PVR_VER(mfspr(SPRN_PVR)) == 1)
> __initial_memory_limit = 0x01000000;
> + /* 852 can only access 8MB at the moment */
> + if (PVR_VER(mfspr(SPRN_PVR)) == 0x50)
> + __initial_memory_limit = 0x00800000;
The comment should refer to 8xx, not 852, as this is a property of code
in head_8xx.S and not the chip itself.
Otherwise,
Acked-by: Scott Wood <scottwood@freescale.com>
-Scott
^ permalink raw reply
* Re: [2.6 patch] ppc .gitignore update
From: Adrian Bunk @ 2007-08-01 19:06 UTC (permalink / raw)
To: Grant Likely
Cc: Rutger Nijlunsing, Paul Mackerras, linux-kernel, linuxppc-dev
In-Reply-To: <fa686aa40708010653v7e1fb909gb03eb1d4754359bf@mail.gmail.com>
On Wed, Aug 01, 2007 at 07:53:28AM -0600, Grant Likely wrote:
> 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
Thanks, that's obviously better than my patch.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* 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
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