what is /proc/interrupts /proc/irq/*/spurious mean?
Hi All, i have a board shipped with Linux kernel 2.6.27. i have some problems in interrupts but while i was gathering some info about the interrupts on my board by cat /proc/interrupts CPU0 16: 2525 OpenPIC Level enet_tx 17: 5606 OpenPIC Level enet_rx 18: 0 OpenPIC Level enet_error 21: 3 OpenPIC Level fsldma-channel 22: 3 OpenPIC Level fsldma-channel 23: 3 OpenPIC Level fsldma-channel 25: 3 OpenPIC Level fsldma-channel 26:461 OpenPIC Level serial 27: 0 OpenPIC Level i2c-mpc 48: 4 OpenPIC Level phy_interrupt 50: 0 OpenPIC Edge DSP-A 52: 11 OpenPIC Edge DSP-B 54: 0 OpenPIC Level FPGA BAD: 0 actually i m interested in IRQ number 52. from the previous command: it seems to me OpenPIC has received 11 interrupt from the device namely DSP-B this interrupt is edge triggered. Is it correct? Also i use: cat /proc/irq/52/spurious count 11 unhandled 0 last_unhandled 0 ms but actually i dont understan its meaning? does it mean that i received 11 spurious interrupt? i expect this because the name of the file is spurious. what does the field unhandled mean? thanks for ur help. -- View this message in context: http://www.nabble.com/what-is--proc-interruptsproc-irq-*-spurious-mean--tp23918722p23918722.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
Wolfgang Denk wrote:
Dear John,
in message 4b73d43f0906061708o763409d0u10a344dfc30e3...@mail.gmail.com you
wrote:
The big question seems to be what the RefMan means when talking about
the system clock frequency. Obiously it is NOT the CPU clock as
...
But which one is it?
My best guess is still that it is ips clock. I think I stated in a previous
email ipb, but I meant ips. 5200 has ibp and 5121 has ips. Have you looked
at he MII clock on a scope to see how the calculated values compare to
actual?
Yes, it seems very much as if you were right again.
When using ips/ibp everything makes sense, and works.
Hm... so that means on MPC512x we should use mpc512x_find_ips_freq(),
while on MPC5200 we should use mpc52xx_find_ipb_freq() - but hey,
apart from the name these two functions are identical.
Grant - how would you like to see this handled? Should we merge these
two code-wise identical functions into one? What should be the name,
and in which file should we put it?
[We need this clock thing for drivers/net/fs_enet/mii-fec.c...]
I2C and MSCAN need it as well. What about implementing the more generic
clk api for the MPC5200 as done for the MPC512x?
http://lxr.linux.no/linux+v2.6.29/arch/powerpc/platforms/512x/clock.c
The MSCAN can also operate with other clock sources, e.g. the external
oscillator (ref_clk). This would avoid cumbersome frequency calculations
from the clock bit settings in the driver as shown below:
/*
* Get the frequency of the external oscillator clock connected
* to the SYS_XTAL_IN pin, or retrun 0 if it cannot be determined.
*/
static unsigned int __devinit mpc52xx_can_xtal_freq(struct device_node *np)
{
struct mpc52xx_cdm __iomem *cdm;
struct device_node *np_cdm;
unsigned int freq;
u32 val;
freq = mpc52xx_find_ipb_freq(np);
if (!freq)
return 0;
/*
* Detemine SYS_XTAL_IN frequency from the clock domain settings
*/
np_cdm = of_find_matching_node(NULL, mpc52xx_cdm_ids);
cdm = of_iomap(np_cdm, 0);
of_node_put(np_cdm);
if (!np_cdm) {
printk(KERN_ERR %s() failed abnormally\n, __func__);
return 0;
}
if (in_8(cdm-ipb_clk_sel) 0x1)
freq *= 2;
val = in_be32(cdm-rstcfg);
if (val (1 5))
freq *= 8;
else
freq *= 4;
if (val (1 6))
freq /= 12;
else
freq /= 16;
iounmap(cdm);
return freq;
}
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
Dear Wolfgang, In message 4a2cc1de.5040...@grandegger.com you wrote: Hm... so that means on MPC512x we should use mpc512x_find_ips_freq(), while on MPC5200 we should use mpc52xx_find_ipb_freq() - but hey, apart from the name these two functions are identical. Grant - how would you like to see this handled? Should we merge these two code-wise identical functions into one? What should be the name, and in which file should we put it? [We need this clock thing for drivers/net/fs_enet/mii-fec.c...] I2C and MSCAN need it as well. What about implementing the more generic clk api for the MPC5200 as done for the MPC512x? http://lxr.linux.no/linux+v2.6.29/arch/powerpc/platforms/512x/clock.c Hmmm... I have to admit that I'm biased he. My primary interest at the moment is obviously just to get the MPC512x stuff into mainline, and thus I'm not happy about extending the scope of the isse to other processors. From the technical point of view you are right, but I have to admit that I don't see which direction we should go from here. If we keep in mind that the same FEC core is also used in various i.MX platforms (= ARM processors), we probably cannot come up with a clean, unique implementation that covers all uses. That's why I asked Grant how to address this. I also added Kumar to the Cc: list - mayby he has some ideas as well? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The day-to-day travails of the IBM programmer are so amusing to most of us who are fortunate enough never to have been one - like watching Charlie Chaplin trying to cook a shoe. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mailing list moving
On Saturday 06 June 2009, Michael Ellerman wrote: On Fri, 2009-06-05 at 19:08 +1000, Stephen Rothwell wrote: I do, however, have the old archives, so maybe we can do something ... We could use the old archive to work out the mapping between old and new and write a billion rewrite rules, but it'd probably crash the rewrite code - and if not slow the server to a crawl. So into the too hard basket I think :) How about just doing a 'wget -r' on the old archive and storing it in some random directory on lists.ozlabs.org as static files? Then you only need a single rewrite rule. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4] zone_reclaim is always 0 by default
On Thu, Jun 04, 2009 at 07:23:15PM +0900, KOSAKI Motohiro wrote: Current linux policy is, zone_reclaim_mode is enabled by default if the machine has large remote node distance. it's because we could assume that large distance mean large server until recently. We don't make assumptions about the server being large, small or otherwise. The affinity tables reporting a distance of 20 or more is saying remote memory has twice the latency of local memory. This is true irrespective of workload and implies that going off-node has a real penalty regardless of workload. Unfortunately, recent modern x86 CPU (e.g. Core i7, Opeteron) have P2P transport memory controller. IOW it's seen as NUMA from software view. Some Core i7 machine has large remote node distance. If they have large remote node distance, they have large remote node distance. Now, if they are *lying* and remote memory is not really that expensive, then prehaps we should be thinking of a per-arch-per-chip modifier to the distances reported by ACPI. Yanmin reported zone_reclaim_mode=1 cause large apache regression. One Nehalem machine has 12GB memory, but there is always 2GB free although applications accesses lots of files. Eventually we located the root cause as zone_reclaim_mode=1. Actually, zone_reclaim_mode=1 mean I dislike remote node allocation rather than disk access, it makes performance improvement to HPC workload. but it makes performance degression to desktop, file server and web server. How are you determining a performance regression to desktop? On a desktop, I would expect processes to be spread on the different CPUs for each of the nodes. In that case, memory faulted on each CPU should be faulted locally. If there are local processes that access a lot of files, then it might end up reclaiming those to keep memory local and this might be undesirable but this is explicitly documented; It may be beneficial to switch off zone reclaim if the system is used for a file server and all of memory should be used for caching files from disk. In that case the caching effect is more important than data locality. Ideally we could detect if the machine was a file-server or not but no such luck. In general, workload depended configration shouldn't put into default settings. However, current code is long standing about two year. Highest POWER and IA64 HPC machine (only) use this setting. Thus, x86 and almost rest architecture change default setting, but Only power and ia64 remain current configuration for backward-compatibility. What about if it's x86-64-based NUMA but it's not i7 based. There, the NUMA distances might really mean something and that zone_reclaim behaviour is desirable. I think if we're going down the road of setting the default, it shouldn't be per-architecture defaults as such. Other choices for addressing this might be; 1. Make RECLAIM_DISTANCE a variable on x86. Set it to 20 by default, and 5 (or some other sensible figure) on i7 2. There should be a per-arch modifier callback for the affinity distances. If the x86 code detects the CPU is an i7, it can reduce the reported latencies to be more in line with expected reality. 3. Do not use zone_reclaim() for file-backed data if more than 20% of memory overall is free. The difficulty is figuring out if the allocation is for file pages. 4. Change zone_reclaim_mode default to mean do your best to figure it out. Patch 1 would default large distances to 1 to see what happens. Then apply a heuristic when in figure-it-out mode and using reclaim_mode == 1 If we have locally reclaimed 2% of the nodes memory in file pages within the last 5 seconds when = 20% of total physical memory was free, then set the reclaim_mode to 0 on the assumption the node is mostly caching pages and shouldn't be reclaimed to avoid excessive IO Option 1 would appear to be the most straight-forward but option 2 should be doable. Option 3 and 4 could turn into a rats nest and I would consider those approaches a bit more drastic. Signed-off-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com Cc: Christoph Lameter c...@linux-foundation.org Cc: Rik van Riel r...@redhat.com Cc: Robin Holt h...@sgi.com Cc: Zhang, Yanmin yanmin.zh...@intel.com Cc: Wu Fengguang fengguang...@intel.com Cc: linux-i...@vger.kernel.org Cc: linuxppc-...@ozlabs.org --- arch/powerpc/include/asm/topology.h |6 ++ include/linux/topology.h|7 +-- 2 files changed, 7 insertions(+), 6 deletions(-) Index: b/include/linux/topology.h === --- a/include/linux/topology.h +++ b/include/linux/topology.h @@ -54,12 +54,7 @@ int arch_update_cpu_topology(void); #define node_distance(from,to) ((from) == (to) ? LOCAL_DISTANCE : REMOTE_DISTANCE) #endif #ifndef RECLAIM_DISTANCE -/* - * If the distance between nodes in a
Re: [Powerpc/SLQB] Next June 06 : BUG during scsi initialization
Pekka J Enberg wrote: Hi Sachin, On Fri, 5 Jun 2009, Sachin Sant wrote: I can still recreate this bug on a Power 6 hardware with today's next tree. I can recreate this problem at will. Let me know if i can help in debugging this problem. Can you please reproduce the issue with this debugging patch applied and post the result? I had some trouble collecting debug o/p with this patch. Because of the number of printk's the machine was crawling during boot. It was difficult to read/collect the o/p. So i inserted a hack as follows such that slab_alloc_page prints only during the failure.(modprobe scsi-driver) + if (strcmp(current-comm, modprobe)) + printk(KERN_INFO %s: cpu=%d, cache_cpu=%p, cache_list=%p\n, __func__, cpu, c, l); Attached here is the boot log. Let me know if i can provide any other information. Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - 00 alloc_kmem_cache_nodes: cache=ext2_xattr, node=2 alloc_kmem_cache_nodes: cache=ext2_xattr, node=3 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 alloc_kmem_cache_nodes: cache=ext2_inode_cache, node=2 alloc_kmem_cache_nodes: cache=ext2_inode_cache, node=3 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 alloc_kmem_cache_nodes: cache=ext4_system_zone, node=2 alloc_kmem_cache_nodes: cache=ext4_system_zone, node=3 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 alloc_kmem_cache_nodes: cache=ext4_prealloc_space, node=2 alloc_kmem_cache_nodes: cache=ext4_prealloc_space, node=3 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 alloc_kmem_cache_nodes: cache=ext4_alloc_context, node=2 alloc_kmem_cache_nodes: cache=ext4_alloc_context, node=3 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 alloc_kmem_cache_nodes: cache=ext4_free_block_extents, node=2 alloc_kmem_cache_nodes: cache=ext4_free_block_extents, node=3 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 alloc_kmem_cache_nodes: cache=ext4_xattr, node=2 alloc_kmem_cache_nodes: cache=ext4_xattr, node=3 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 alloc_kmem_cache_nodes: cache=ext4_inode_cache, node=2 alloc_kmem_cache_nodes: cache=ext4_inode_cache, node=3 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 alloc_kmem_cache_nodes: cache=revoke_record, node=2 alloc_kmem_cache_nodes: cache=revoke_record, node=3 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 alloc_kmem_cache_nodes: cache=revoke_table, node=2 alloc_kmem_cache_nodes: cache=revoke_table, node=3 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 alloc_kmem_cache_nodes: cache=journal_head, node=2 alloc_kmem_cache_nodes: cache=journal_head, node=3 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 alloc_kmem_cache_nodes: cache=journal_handle, node=2 alloc_kmem_cache_nodes: cache=journal_handle, node=3 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 alloc_kmem_cache_nodes: cache=jbd2_revoke_record, node=2 alloc_kmem_cache_nodes: cache=jbd2_revoke_record, node=3 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 alloc_kmem_cache_nodes: cache=jbd2_revoke_table, node=2 alloc_kmem_cache_nodes: cache=jbd2_revoke_table, node=3 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 __slab_alloc_page: nid=2, cache_node=c08c4300, cache_list=c08c4300 alloc_kmem_cache_nodes: cache=jbd2_journal_head, node=2 alloc_kmem_cache_nodes:
[PATCH] serial: Fix bug of ucc_uart
Current ucc_uart driver doesn't work at UART mode,
The TxBD[READY] is not cleared by H/W (RISC engine)
when user send characters to Tx buffer of QE UART.
so, these characters stay on the QE forever, never
go to UART line.
The patch is fixing th bug.
Signed-off-by: Dave Liu dave...@freescale.com
---
drivers/serial/ucc_uart.c | 19 ++-
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/serial/ucc_uart.c b/drivers/serial/ucc_uart.c
index 7de66c0..e945e78 100644
--- a/drivers/serial/ucc_uart.c
+++ b/drivers/serial/ucc_uart.c
@@ -681,22 +681,27 @@ static void qe_uart_init_ucc(struct uart_qe_port *qe_port)
out_be16(uccup-rccm, 0xc0ff);
/* Configure the GUMR registers for UART */
- if (soft_uart)
+ if (soft_uart) {
/* Soft-UART requires a 1X multiplier for TX */
clrsetbits_be32(uccp-gumr_l,
UCC_SLOW_GUMR_L_MODE_MASK | UCC_SLOW_GUMR_L_TDCR_MASK |
UCC_SLOW_GUMR_L_RDCR_MASK,
UCC_SLOW_GUMR_L_MODE_UART | UCC_SLOW_GUMR_L_TDCR_1 |
UCC_SLOW_GUMR_L_RDCR_16);
- else
+
+ clrsetbits_be32(uccp-gumr_h, UCC_SLOW_GUMR_H_RFW,
+ UCC_SLOW_GUMR_H_TRX | UCC_SLOW_GUMR_H_TTX);
+ } else {
clrsetbits_be32(uccp-gumr_l,
UCC_SLOW_GUMR_L_MODE_MASK | UCC_SLOW_GUMR_L_TDCR_MASK |
UCC_SLOW_GUMR_L_RDCR_MASK,
UCC_SLOW_GUMR_L_MODE_UART | UCC_SLOW_GUMR_L_TDCR_16 |
UCC_SLOW_GUMR_L_RDCR_16);
- clrsetbits_be32(uccp-gumr_h, UCC_SLOW_GUMR_H_RFW,
- UCC_SLOW_GUMR_H_TRX | UCC_SLOW_GUMR_H_TTX);
+ clrsetbits_be32(uccp-gumr_h,
+ UCC_SLOW_GUMR_H_TRX | UCC_SLOW_GUMR_H_TTX,
+ UCC_SLOW_GUMR_H_RFW);
+ }
#ifdef LOOPBACK
clrsetbits_be32(uccp-gumr_l, UCC_SLOW_GUMR_L_DIAG_MASK,
@@ -706,7 +711,7 @@ static void qe_uart_init_ucc(struct uart_qe_port *qe_port)
UCC_SLOW_GUMR_H_CDS);
#endif
- /* Enable rx interrupts and clear all pending events. */
+ /* Disable rx interrupts and clear all pending events. */
out_be16(uccp-uccm, 0);
out_be16(uccp-ucce, 0x);
out_be16(uccp-udsr, 0x7e7e);
@@ -765,6 +770,10 @@ static void qe_uart_init_ucc(struct uart_qe_port *qe_port)
cecr_subblock = ucc_slow_get_qe_cr_subblock(qe_port-ucc_num);
qe_issue_cmd(QE_INIT_TX_RX, cecr_subblock,
QE_CR_PROTOCOL_UNSPECIFIED, 0);
+ } else {
+ cecr_subblock = ucc_slow_get_qe_cr_subblock(qe_port-ucc_num);
+ qe_issue_cmd(QE_INIT_TX_RX, cecr_subblock,
+ QE_CR_PROTOCOL_UART, 0);
}
}
--
1.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
On Sun, Jun 7, 2009 at 2:34 PM, Wolfgang Denkw...@denx.de wrote: Dear John, in message 4b73d43f0906061708o763409d0u10a344dfc30e3...@mail.gmail.com you wrote: The big question seems to be what the RefMan means when talking about the system clock frequency. Obiously it is NOT the CPU clock as ... But which one is it? My best guess is still that it is ips clock. I think I stated in a previous email ipb, but I meant ips. 5200 has ibp and 5121 has ips. Have you looked at he MII clock on a scope to see how the calculated values compare to actual? Yes, it seems very much as if you were right again. When using ips/ibp everything makes sense, and works. Hm... so that means on MPC512x we should use mpc512x_find_ips_freq(), while on MPC5200 we should use mpc52xx_find_ipb_freq() - but hey, apart from the name these two functions are identical. Grant - how would you like to see this handled? Should we merge these two code-wise identical functions into one? What should be the name, and in which file should we put it? If you want to merge them... Seeing as the function just walks up the parent nodes looking for the bus-frequency property; how about mpc5xxx_get_bus_frequency()? It should go somewhere in arch/powerpc/sysdev/ Alternately, it is a pretty trivial function; 52xx and 512x could both have their own versions of it. Whichever makes the most sense to you (I haven't personally looked at the device driver impact). g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
On Mon, Jun 8, 2009 at 2:19 AM, Wolfgang Denkw...@denx.de wrote: Dear Wolfgang, In message 4a2cc1de.5040...@grandegger.com you wrote: Hm... so that means on MPC512x we should use mpc512x_find_ips_freq(), while on MPC5200 we should use mpc52xx_find_ipb_freq() - but hey, apart from the name these two functions are identical. Grant - how would you like to see this handled? Should we merge these two code-wise identical functions into one? What should be the name, and in which file should we put it? [We need this clock thing for drivers/net/fs_enet/mii-fec.c...] I2C and MSCAN need it as well. What about implementing the more generic clk api for the MPC5200 as done for the MPC512x? http://lxr.linux.no/linux+v2.6.29/arch/powerpc/platforms/512x/clock.c Hmmm... I have to admit that I'm biased he. My primary interest at the moment is obviously just to get the MPC512x stuff into mainline, and thus I'm not happy about extending the scope of the isse to other processors. From the technical point of view you are right, but I have to admit that I don't see which direction we should go from here. If we keep in mind that the same FEC core is also used in various i.MX platforms (= ARM processors), we probably cannot come up with a clean, unique implementation that covers all uses. That's why I asked Grant how to address this. I also added Kumar to the Cc: list - mayby he has some ideas as well? I say use the simple approach to get it merged; It can always be changed later. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
2.6.30-rc6: Problem with an SSD disk on Freescale PowerPC mpc8315e-rdb, works fine on x86
Hello,
using 2.6.30-rc6, I get the following problems when I read from a SSD
disk, connected to the
3.0 Gb SATA controller of the MPC8315E SoC rev 1.0 running Linux 2.6.30-rc6.
Below see the output from two dd read runs.
The disk behaves fine on a x86 box.
What I can do to (help) pin-point the problem?
Regards,
Leon.
r...@mpc8315e-rdb:~# dd if=/dev/sda of=/dev/null bs=4k
ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:3e:1e:e0:01/00:00:00:00:00/e0 tag 0 dma 31744 in
res 50/00:3e:e0:df:01/00:00:00:00:00/e0 Emask 0x1 (device error)
ata2.00: status: { DRDY }
ata2: hard resetting link
ata2: Signature Update detected @ 3528 msecs
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: configured for UDMA/133
sd 1:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08
sd 1:0:0:0: [sda] Sense Key : 0xb [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
00 01 df e0
sd 1:0:0:0: [sda] ASC=0x0 ASCQ=0x0
end_request: I/O error, dev sda, sector 122910
__ratelimit: 52 callbacks suppressed
Buffer I/O error on device sda, logical block 122910
Buffer I/O error on device sda, logical block 122911
Buffer I/O error on device sda, logical block 122912
Buffer I/O error on device sda, logical block 122913
Buffer I/O error on device sda, logical block 122914
Buffer I/O error on device sda, logical block 122915
Buffer I/O error on device sda, logical block 122916
Buffer I/O error on device sda, logical block 122917
Buffer I/O error on device sda, logical block 122918
Buffer I/O error on device sda, logical block 122919
ata2: EH complete
dd: /dev/sda: Input/output error
r...@mpc8315e-rdb:~# dd if=/dev/sda of=/dev/null bs=4k
ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:32:9a:6e:00/00:00:00:00:00/e0 tag 0 dma 25600 in
res 50/00:3e:5c:6e:00/00:00:00:00:00/e0 Emask 0x1 (device error)
ata2.00: status: { DRDY }
ata2: hard resetting link
ata2: Signature Update detected @ 3528 msecs
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: configured for UDMA/133
sd 1:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08
sd 1:0:0:0: [sda] Sense Key : 0xb [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
00 00 6e 5c
sd 1:0:0:0: [sda] ASC=0x0 ASCQ=0x0
end_request: I/O error, dev sda, sector 28314
__ratelimit: 52 callbacks suppressed
Buffer I/O error on device sda, logical block 28314
Buffer I/O error on device sda, logical block 28315
Buffer I/O error on device sda, logical block 28316
Buffer I/O error on device sda, logical block 28317
Buffer I/O error on device sda, logical block 28318
Buffer I/O error on device sda, logical block 28319
Buffer I/O error on device sda, logical block 28320
Buffer I/O error on device sda, logical block 28321
Buffer I/O error on device sda, logical block 28322
Buffer I/O error on device sda, logical block 28323
ata2: EH complete
dd: /dev/sda: Input/output error
r...@mpc8315e-rdb:~# uname -a
Linux mpc8315e-rdb 2.6.30-rc6 #1 Mon Jun 8 15:54:00 CEST 2009 ppc unknown
r...@mpc8315e-rdb:~# hdparm -i /dev/sda
/dev/sda:
Model=Solidata X SSD , FwRev=0955, SerialNo=...
Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=128, MultSect=?1?
CurCHS=16383/16/63, CurSects=16514064, LBA=no
IORDY=no, tPIO={min:240,w/IORDY:120}
PIO modes: pio0 pio3 pio4
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
AdvancedPM=yes: disabled (255) WriteCache=disabled
Drive conforms to: Unspecified: ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6
ATA/ATAPI-7
* signifies the current active mode
--
Leon
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mkimage for ppc
Sorry, was on vacation. Copying a couple mailing lists... On Tue, 2009-06-02 at 12:34 +0300, Avi Kivity wrote: I am now doing regular build tests on various platforms (kernel only for now). That's great! Much appreciated. But ppc wants a mkimage and I don't have one to give it. Where can I find it? mkimage is a tool provided by u-boot (http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=summary). IIRC people have discussed the need to include a copy in the kernel source in the past, but apparently nothing was ever done about it. -- Hollis Blanchard IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: SD card over (xilinx_)SPI, timeout error while CID
Peter Korsgaard wrote: Joachim == Joachim Foerster j...@gmx.de writes: Hi, Joachim Any hints? Does anybody use SD card support with Joachim mmc_spi+xilinx_spi ? I don't, but have you compared the spi signals on a scope in the 2 setups? Is timing significantly different? Hi, we just tried to find differences for the timing with the oszi: Here are to screenshots taken from the initial first few data bytes that are communicated. At least at that time there does not seem to be any timing issue. 2.6.26 using arch ppc and virtex-devices: http://img145.imageshack.us/img145/9662/2626virtexdevices.jpg 2.6.29.4 using arch powerpc: http://img145.imageshack.us/img145/9847/2629devtree.jpg For explanation: yellow = chan 1 = MOSI = trigger green = chan 2 = chipselect not blue = chan 3 = clock red = chan 4 = MOSI Looks like we're gonna have to switch to a logic analyzer (with spi-mode sdcard analyzing support) as we cannot see any differences in the short timeframe our oszi does measure, though checking the timing does not look too promising. We even configured the Xilinx-SPI core to go down to ~780 kHz just to be safe, did not help either. Regards, Lorenz ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mkimage for ppc
Hollis Blanchard wrote: But ppc wants a mkimage and I don't have one to give it. Where can I find it? mkimage is a tool provided by u-boot (http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=summary). IIRC people have discussed the need to include a copy in the kernel source in the past, but apparently nothing was ever done about it. I found git://scarlet.buici.com/uboot-mkimage a few days ago and it seems to work. -- error compiling committee.c: too many arguments to function ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver
Question: why is bank-width even relevant for a RAM device? The underlying map_ram-driver uses it once while erasing. The question remains if this is really needed? And: Does this need to get solved before merging my patches because changing the binding afterwards is hard? Or can they go mainline nevertheless? Thanks, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Missing some interrupts
wael showair wrote:
You cannot really rely on getting the exact same number of edge
interrupts that were emitted. At least not unless you have a hard RT
system and can guarantee that you'll always dequeue them fast enough.
Yes, my system is a hard RT i want to receive all the interrupts that
have been generated exactly
No. Linux is not hard RT. You cannot rely on this in a reliable way,
if for any reason the kernel masks interrupt for too long, which can
happen, you'll see that sort of coalescing happening.
what about using the RT-Preempt Patch? i can see that it will convert Linux
ti an RTOS.
If you -really- can't do anything else, then use critical interrupts
but there is little if no support at all for them in linux.
It's your model that is wrong, you should be able to poll the device for
how
much work (or interrupts) have been sent and react accordingly
regardless of how many actual IRQ triggers came in via the OpenPIC.
so who is responsible for acking the interrupt?
At the PIC level, they are acked by the core just before calling into
your handler.
i have check the function of do_IRQ: there is no ack called b 4 calling the
handler but actually it does the following:
1. it gets the irq number using :
irq = ppc_md.get_irq();
2. then it calls the handler :
if (irq != NO_IRQ irq != NO_IRQ_IGNORE) {
generic_handle_irq(irq);
} else if (irq != NO_IRQ_IGNORE)
/* That's not SMP safe ... but who cares ? */
ppc_spurious_interrupts++;
i have checked the function of generic_handle_irq where it is defined
linux/irq.h it calls the handler
so from the previous code the processor or the pic does not ack but they
call my ISR handler.
i have also read the specs of my OpenPIC found that:
the interrupt handler executing on the processor should then acknowledge
the interrupt by explicitly reading the IACK register.The PIC unit
interprets this read as an interrupt acknowledge (IACK) cycle; in response,
the PIC unit returns the vector associated with the
interrupt source to the interrupt handler routine.
At the end of the interrupt the End Of Interrupt (EOI) register must be
set
So the processor neither reads this iack register nor the handler set the
EOI register.
how is the interrupts works on my board? i dont know?
my linux version is 2.6.27.
is there any API in the kernel should i call to do this ack? or
it is something Dependant on the device that generates the interrupt?
The PIC-level ack is done for you. I don't know what your DSP does.
Actaully, the device in my case which is a DSP-core is toggles the
outpin pin of its GPIO that is connected to the input pin of the
OpenPIC, so how can
i ack this device? do u have any suggestions?
The Ack isn't your problem. Your model is wrong if you design assuming
you will receive all edge interrupts. Being careful about latencies
etc... (and making sure you toggle for long enough, btw, didn't think
about that one, check your MPIC specs) may improve how many of them you
actually receive, -but- you cannot guarantee that you'll get them all,
so even if you somewhat manager into most of your tests to get 100%,
you'll still have an unreliable system.
You must design your communication between the DSP and Linux such that
the interrupt is purely a wakeup call indicating there's work to do, and
some -other- mean for Linux to actually know how much work is to be
done, the actual number of interrupts is not a proper way to do so.
So how can i achieve this step? how can i ack the interrupt b 4 i call
the handler? where can i do this in the kernel?
The kernel does it for you as I said. It's your communication model
that is flawed. Never -ever- rely on edge interrupts in ways that
require them not to be coalesced.
Cheers,
Ben.
So you don't need to worry too much about racing with new incoming
messages inside the
interrupt handler itself. But you need to be prepared to pick up more
than one item of work... whatever that is.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Quoted from:
http://www.nabble.com/Missing-some-interrupts-tp23901807p23906326.html
Quoted from:
http://www.nabble.com/Missing-some-interrupts-tp23901807p23906859.html
--
View this message in context:
http://www.nabble.com/Missing-some-interrupts-tp23901807p23927820.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mkimage for ppc
On Mon, Jun 08, 2009 at 10:48:58AM -0500, Hollis Blanchard wrote: Sorry, was on vacation. Copying a couple mailing lists... On Tue, 2009-06-02 at 12:34 +0300, Avi Kivity wrote: I am now doing regular build tests on various platforms (kernel only for now). That's great! Much appreciated. But ppc wants a mkimage and I don't have one to give it. Where can I find it? mkimage is a tool provided by u-boot (http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=summary). IIRC people have discussed the need to include a copy in the kernel source in the past, but apparently nothing was ever done about it. The first patch was pushed back on because it didn't solve it for all the architectures that use mkimage for various builds. I'd like to get back to that, but haven't had time yet. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver
Am 08.06.09 18:35 schrieb(en) Wolfram Sang: Question: why is bank-width even relevant for a RAM device? The underlying map_ram-driver uses it once while erasing. The question remains if this is really needed? Am 06.06.09 18:16 schrieb(en) Albrecht Dreß: At least if the RAM is attached to the 5200's Local Plus Bus in 16-bit mode, no byte write accesses are allowed (byte /reads/ work, though). I have a tweak (which I will post next week) to address this case, which depends upon this setting. To put this clearer: on '5200 based systems, the driver (more specific: the function inline_map_copy_to()) *must* know whether the hardware is connected in 8-bit or 16-bit mode to the Local Plus Bus, as byte writes (issued by memcpy_toio()) will fail for the latter setup (probably the same applies for byte and word writes in 32-bit mode). IMHO, this information should be passed using the device tree. The bank-width seems to be an obvious choice for that. Best, Albrecht. pgph3gL6hLYbg.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH v5] MPC5121 TLB errata workaround
On Jun 6, 2009, at 5:42 PM, Benjamin Herrenschmidt wrote: On Sun, 2009-06-07 at 00:07 +0200, Wolfgang Denk wrote: Dear David Jander, In message 200903161652.09747.david.jan...@protonic.nl you wrote: Complete workaround for DTLB errata in e300c2/c3/c4 processors. Due to the bug, the hardware-implemented LRU algorythm always goes to way 1 of the TLB. This fix implements the proposed software workaround in form of a LRW table for chosing the TLB-way. Signed-off-by: Kumar Gala ga...@kernel.crashing.org Signed-off-by: David Jander da...@protonic.nl What is the actual status of this patch? Patchwork (http://patchwork.ozlabs.org/patch/24502/) says it's superseded - but by what? I can't see such code in mainline - what happened to it? I can see the code in mainline ... but only in the -data- TLB miss handler, not the instruction one... Kumar ? Shouldn't we have the workaround in both ? The errata was only for the d-side. The patch is in the mainline kernel. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Delay on intialization ide subsystem(most likely)
On Saturday 30 May 2009 12:46:43 Andrey Gusev wrote: On Wed, 20 May 2009 17:56:14 +0200 Bartlomiej Zolnierkiewicz bzoln...@gmail.com wrote: On Friday 15 May 2009 22:40:07 Andrey Gusev wrote: On Wed, 13 May 2009 20:46:33 +0200 Bartlomiej Zolnierkiewicz bzoln...@gmail.com wrote: On Wednesday 13 May 2009 19:11:23 Andrey Gusev wrote: On Wed, 13 May 2009 15:28:26 +0200 Bartlomiej Zolnierkiewicz bzoln...@gmail.com wrote: On Tuesday 12 May 2009 21:50:24 Andrey Gusev wrote: On Mon, 27 Apr 2009 23:21:48 +0200 Bartlomiej Zolnierkiewicz bzoln...@gmail.com wrote: On Monday 27 April 2009 22:36:45 Andrey Gusev wrote: On Sat, 25 Apr 2009 16:48:38 +0200 Bartlomiej Zolnierkiewicz bzoln...@gmail.com wrote: Hi, On Saturday 25 April 2009 15:02:03 Andrey Gusev wrote: Hello! I have tested linux-2.6.30-rc3 on my system and find some problems. One of them is delaying on initialization IDE subsystem. I don't have this problem on 2.6.29.1. The difference is looked on log of dmesg. Unfortunately this doesn't give us any hint about the root cause of the bug so please try narrowing the problem down to the specific change using git-bisect (sorry, there were 212 drivers/ide/ commits during v2.6.29..v2.6.30-rc3 and much much more non-drivers/ide/ ones). Thanks, Bart Hello! The full result of bisect is: git bisect start # good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux 2.6.29 git bisect good 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84 # bad: [091069740304c979f957ceacec39c461d0192158] Linux 2.6.30-rc3 git bisect bad 091069740304c979f957ceacec39c461d0192158 # good: [40f07111be99b71c1e8d40c13cdc38445add787f] V4L/DVB (11166): pvrusb2: Implement status fetching from sub-devices git bisect good 40f07111be99b71c1e8d40c13cdc38445add787f # good: [ba0e1ebb7ea0616eebc29d2077355bacea62a9d8] Staging: sxg: slicoss: Specify the license for Sahara SXG and Slicoss drivers git bisect good ba0e1ebb7ea0616eebc29d2077355bacea62a9d8 git bisect start 'drivers/ide/' Please note that limiting search space to drivers/ide/ may not give reliable results in case problem was introduced by some other kernel area. # good: [ba0e1ebb7ea0616eebc29d2077355bacea62a9d8] Staging: sxg: slicoss: Specify the license for Sahara SXG and Slicoss drivers git bisect good ba0e1ebb7ea0616eebc29d2077355bacea62a9d8 # bad: [091069740304c979f957ceacec39c461d0192158] Linux 2.6.30-rc3 git bisect bad 091069740304c979f957ceacec39c461d0192158 # good: [e01f251fd09fa7cb3d352eac7de17bb5d5bd1f9d] ide-cd: convert cdrom_decode_status() to use switch statements git bisect good e01f251fd09fa7cb3d352eac7de17bb5d5bd1f9d # good: [3153c26b54230d025c6d536e8d3015def4524906] ide: refactor tf_read() method git bisect good 3153c26b54230d025c6d536e8d3015def4524906 # good: [c018f1ee5cf81e58b93d9e93a2ee39cad13dc1ac] hpt366: fix HPT370 DMA timeouts git bisect good c018f1ee5cf81e58b93d9e93a2ee39cad13dc1ac # bad: [d5f840bf74c09ca5a31e518c9d98426b5f44] ide: Remove void casts git bisect bad d5f840bf74c09ca5a31e518c9d98426b5f44 # bad: [59c8d04f5ee97ea46da854e9adbbaa45d988c39d] hpt366: use ATA_DMA_* constants git bisect bad 59c8d04f5ee97ea46da854e9adbbaa45d988c39d Uhh.. something went wrong during bisect. hpt366: use ATA_DMA_* constants cannot be a first bad commit because hpt366 is not even used on this system. Could it be that the delay doesn't happen on every boot for bad kernels? Also, is 2.6.30-rc1 okay? Thanks, Bart Hello all! I continue to find reason of bug. I made more testing with bisect and got result: git bisect start # bad: [c018f1ee5cf81e58b93d9e93a2ee39cad13dc1ac] hpt366: fix HPT370 DMA timeouts git bisect bad # good: [fb4252e59452c18b88af014a2c4ee697bbf8cbc6] at91_ide: turn on PIO 6 support git bisect good fb4252e59452c18b88af014a2c4ee697bbf8cbc6 # good: [2e1c63b7ed36532b68f0eddd6a184d7ba1013b89] Merge branch 'for-rc1/xen/core' of git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen git bisect good 2e1c63b7ed36532b68f0eddd6a184d7ba1013b89 # bad:
Re: Missing some interrupts
On Mon, 2009-06-08 at 09:45 -0700, wael showair wrote:
wael showair wrote:
You cannot really rely on getting the exact same number of edge
interrupts that were emitted. At least not unless you have a hard RT
system and can guarantee that you'll always dequeue them fast enough.
Yes, my system is a hard RT i want to receive all the interrupts that
have been generated exactly
No. Linux is not hard RT. You cannot rely on this in a reliable way,
if for any reason the kernel masks interrupt for too long, which can
happen, you'll see that sort of coalescing happening.
what about using the RT-Preempt Patch? i can see that it will convert Linux
ti an RTOS.
Not only I don't think it's going to guarantee RT response (just improve
it), that's a pretty big hammer to work around what is a design bug in
your system in the first place :-)
i have check the function of do_IRQ: there is no ack called b 4 calling the
handler but actually it does the following:
You haven't read properly :-)
1. it gets the irq number using :
irq = ppc_md.get_irq();
2. then it calls the handler :
if (irq != NO_IRQ irq != NO_IRQ_IGNORE) {
generic_handle_irq(irq);
} else if (irq != NO_IRQ_IGNORE)
/* That's not SMP safe ... but who cares ? */
ppc_spurious_interrupts++;
i have checked the function of generic_handle_irq where it is defined
linux/irq.h it calls the handler
No. It call the -flow- handler, which is a different thing (yes, the
terminology can be a bit confusing). The flow handler is configured
by the interrupt controller itself and will do whatever necessary
ack'ing, masking, EOI'ing etc... for a given PIC around the call to the
actual driver handler.
so from the previous code the processor or the pic does not ack but they
call my ISR handler.
They do. You missed it.
i have also read the specs of my OpenPIC found that:
the interrupt handler executing on the processor should then acknowledge
the interrupt by explicitly reading the IACK register.
Reading the IACK is what get_irq() does on OpenPIC.
The PIC unit
interprets this read as an interrupt acknowledge (IACK) cycle; in response,
the PIC unit returns the vector associated with the
interrupt source to the interrupt handler routine.
At the end of the interrupt the End Of Interrupt (EOI) register must be
set
Which is done by the flow handler.
So the processor neither reads this iack register nor the handler set the
EOI register.
You obviously missed both :-)
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -next] powerpc/85xx: Add support for X-ES MPC85xx boards
On Jun 8, 2009, at 5:13 PM, Nate Case wrote:
+static void xes_mpc85xx_configure_l1(void)
+{
+ uint spr;
+ asm volatile(msync; isync);
+ spr = mfspr(SPRN_L1CSR1);
+ asm volatile(msync; isync);
+ /* Enable instruction cache */
+ mtspr(SPRN_L1CSR1, spr | L1CSR1_ICFI | L1CSR1_ICE | L1CSR1_CPE);
+
+ /* Enable L1 data cache if it isn't already enabled */
+ if (mfspr(SPRN_L1CSR0) == 0x0) {
+ printk(KERN_INFO xes_mpc85xx: Enabling L1 caches\n);
+ asm volatile(msync; isync);
+ mtspr(SPRN_L1CSR0, 0x0);/* Disable */
+ asm volatile(msync; isync);
+ mtspr(SPRN_L1CSR0, L1CSR0_DCFI);/* Invalidate */
+ asm volatile(msync; isync);
+ spr = mfspr(SPRN_L1CSR0);
+ asm volatile(msync; isync);
+ mtspr(SPRN_L1CSR0, spr | L1CSR0_DCFI | L1CSR0_DCE |
+ L1CSR0_CPE); /* Enable */
+ }
+}
+
I'd prefer we move this into __setup_cpu_e500v1/__setup_cpu_e500v2 so
its done for all processors regardless of platform.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -next] powerpc/85xx: Add support for X-ES MPC85xx boards
diff --git a/arch/powerpc/platforms/85xx/xes_mpc85xx.c b/arch/
powerpc/platforms/85xx/xes_mpc85xx.c
new file mode 100644
index 000..c1b55b8
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/xes_mpc85xx.c
@@ -0,0 +1,332 @@
+/*
+ * Copyright (C) 2009 Extreme Engineering Solutions, Inc.
+ *
+ * X-ES board-specific functionality
+ *
+ * Based on mpc85xx_ds code from Freescale Semiconductor, Inc.
+ *
+ * Author: Nate Case nc...@xes-inc.com
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#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 linux/interrupt.h
+#include linux/of_platform.h
+
+#include asm/system.h
+#include asm/time.h
+#include asm/machdep.h
+#include asm/pci-bridge.h
+#include mm/mmu_decl.h
+#include asm/prom.h
+#include asm/udbg.h
+#include asm/mpic.h
+
+#include sysdev/fsl_soc.h
+#include sysdev/fsl_pci.h
+#include linux/of_platform.h
+
+#undef DEBUG
+
+#ifdef DEBUG
+#define DBG(fmt, args...) printk(KERN_ERR %s: fmt, __func__, ##
args)
+#else
+#define DBG(fmt, args...)
+#endif
DBG is not used.
+
+/* A few bit definitions needed for fixups on some boards */
+#define MPC85xx_L2CTL_L2E 0x8000 /* L2 enable */
+#define MPC85xx_L2CTL_L2I 0x4000 /* L2 flash invalidate */
+#define MPC85xx_L2CTL_L2SIZ_MASK 0x3000 /* L2 SRAM size (R/O) */
+
+void __init xes_mpc85xx_pic_init(void)
+{
+ struct mpic *mpic;
+ struct resource r;
+ struct device_node *np;
+
+ np = of_find_node_by_type(NULL, open-pic);
+ if (np == NULL) {
+ printk(KERN_ERR Could not find open-pic node\n);
+ return;
+ }
+
+ if (of_address_to_resource(np, 0, r)) {
+ printk(KERN_ERR Failed to map mpic register space\n);
+ of_node_put(np);
+ return;
+ }
+
+ mpic = mpic_alloc(np, r.start,
+ MPIC_PRIMARY | MPIC_WANTS_RESET |
+ MPIC_BIG_ENDIAN | MPIC_BROKEN_FRR_NIRQS,
+ 0, 256, OpenPIC );
+ BUG_ON(mpic == NULL);
+ of_node_put(np);
+
+ mpic_init(mpic);
+}
+
+static void xes_mpc85xx_configure_l1(void)
+{
+ uint spr;
+ asm volatile(msync; isync);
+ spr = mfspr(SPRN_L1CSR1);
+ asm volatile(msync; isync);
+ /* Enable instruction cache */
+ mtspr(SPRN_L1CSR1, spr | L1CSR1_ICFI | L1CSR1_ICE | L1CSR1_CPE);
+
+ /* Enable L1 data cache if it isn't already enabled */
+ if (mfspr(SPRN_L1CSR0) == 0x0) {
+ printk(KERN_INFO xes_mpc85xx: Enabling L1 caches\n);
+ asm volatile(msync; isync);
+ mtspr(SPRN_L1CSR0, 0x0);/* Disable */
+ asm volatile(msync; isync);
+ mtspr(SPRN_L1CSR0, L1CSR0_DCFI);/* Invalidate */
+ asm volatile(msync; isync);
+ spr = mfspr(SPRN_L1CSR0);
+ asm volatile(msync; isync);
+ mtspr(SPRN_L1CSR0, spr | L1CSR0_DCFI | L1CSR0_DCE |
+ L1CSR0_CPE); /* Enable */
+ }
+}
+
+static void xes_mpc85xx_configure_l2(void __iomem *l2_base)
+{
+ volatile uint32_t ctl, tmp;
+
+ asm volatile(msync; isync);
+ tmp = in_be32(l2_base);
+
+ /*
+* xMon may have enabled part of L2 as SRAM, so we need to set it
+* up for all cache mode just to be safe.
+*/
+ printk(KERN_INFO xes_mpc85xx: Enabling L2 as cache\n);
+
+ ctl = MPC85xx_L2CTL_L2E | MPC85xx_L2CTL_L2I;
+ if (machine_is_compatible(MPC8540) ||
+ machine_is_compatible(MPC8560))
+ /*
+* Assume L2 SRAM is used fully for cache, so set
+* L2BLKSZ (bits 4:5) to match L2SIZ (bits 2:3).
+*/
+ ctl |= (tmp MPC85xx_L2CTL_L2SIZ_MASK) 2;
+
+ asm volatile(msync; isync);
+ out_be32(l2_base, ctl);
+ asm volatile(msync; isync);
+}
+
+static void xes_mpc85xx_fixups(void)
+{
+ struct device_node *np;
+ int err;
+
+ /*
+* Legacy xMon firmware on some X-ES boards does not enable caches.
+* We must ensure that they get enabled here.
+*/
+ if (machine_is(xes_mpc8548) || machine_is(xes_mpc8540))
+ xes_mpc85xx_configure_l1();
+
+ for_each_node_by_name(np, l2-cache-controller) {
+ struct resource r[2];
+ void __iomem *l2_base;
+
+ /* Only MPC8548, MPC8540, and MPC8560 boards are affected */
+ if (!of_device_is_compatible(np,
+ fsl,mpc8548-l2-cache-controller)
+ !of_device_is_compatible(np,
+
[PATCH] powerpc/boot: cuboot: Fix up ethernet3 MAC address on MPC85xx
MPC85xx platforms do support 4 ethernet ports, so make sure the boot wrapper fixes up all of them in the fdt. Signed-off-by: Nate Case nc...@xes-inc.com --- arch/powerpc/boot/cuboot-85xx.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/boot/cuboot-85xx.c b/arch/powerpc/boot/cuboot-85xx.c index 6776a1a..277ba4a 100644 --- a/arch/powerpc/boot/cuboot-85xx.c +++ b/arch/powerpc/boot/cuboot-85xx.c @@ -15,6 +15,7 @@ #include cuboot.h #define TARGET_85xx +#define TARGET_HAS_ETH3 #include ppcboot.h static bd_t bd; @@ -27,6 +28,7 @@ static void platform_fixups(void) dt_fixup_mac_address_by_alias(ethernet0, bd.bi_enetaddr); dt_fixup_mac_address_by_alias(ethernet1, bd.bi_enet1addr); dt_fixup_mac_address_by_alias(ethernet2, bd.bi_enet2addr); + dt_fixup_mac_address_by_alias(ethernet3, bd.bi_enet3addr); dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 8, bd.bi_busfreq); /* Unfortunately, the specific model number is encoded in the -- 1.6.0.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Delay on intialization ide subsystem(most likely)
On Mon, 2009-06-08 at 22:20 +0200, Bartlomiej Zolnierkiewicz wrote: [ 70.584122] hdb:3ide-pmac lost interrupt, dma status: 8480 DMA status indicates that DMA transfer is still active according to the controller. This one is really a platform/hardware specific issue. I've partially missed that thread. Is the a bugzilla entry or something ? Is this a regression ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
sensors can't be detected on i2c-mpc
sensors can't be detected on i2c-mpc
Hi all,
The sensors can't be detected on the built-in I2C interface on the Freescale's
MPC processors on linux-2.6.29.
If it is not yet fixed, I think that it is forgotten to set the following
values in the class.
Signed-off-by: Hideo Saito hsaito@gmail.com
---
--- drivers/i2c/busses/i2c-mpc.c.org2009-03-24 08:12:14.0 +0900
+++ drivers/i2c/busses/i2c-mpc.c2009-06-04 08:50:34.0 +0900
@@ -304,16 +304,17 @@ static u32 mpc_functionality(struct i2c_
static const struct i2c_algorithm mpc_algo = {
.master_xfer = mpc_xfer,
.functionality = mpc_functionality,
};
static struct i2c_adapter mpc_ops = {
.owner = THIS_MODULE,
+ .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
.name = MPC adapter,
.algo = mpc_algo,
.timeout = 1,
};
static int __devinit fsl_i2c_probe(struct of_device *op, const struct
of_device_id *match)
{
int result = 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: sensors can't be detected on i2c-mpc
On Mon, Jun 8, 2009 at 7:20 PM, Hide Saitohsaito@gmail.com wrote: sensors can't be detected on i2c-mpc Hi all, The sensors can't be detected on the built-in I2C interface on the Freescale's MPC processors on linux-2.6.29. If it is not yet fixed, I think that it is forgotten to set the following values in the class. Signed-off-by: Hideo Saito hsaito@gmail.com Since i2c probing is hit and miss at best; Most MPC SPI busses get the i2c bus topology out of the device tree file (arch/powerpc/boot/dts/board-name.dts) and do not support probing. If the i2c device you need is missing, then add a node to the .dts file for the missing device (there are lots of examples of this in the dts directory). g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
On Sun, 2009-06-07 at 20:06 +0530, Subrata Modak wrote: On Sat, 2009-06-06 at 09:36 -0400, Frank Mori Hess wrote: On Saturday 06 June 2009, Greg KH wrote: Frank and Ian, any thoughts about the vmap call in the comedi_buf_alloc() call? Why is it using PAGE_KERNEL_NOCACHE, and what is the prealloc_buf buffer used for? It is a circular buffer used to hold data streaming either to or from a board (for example when producing an analog output waveform). Reads and writes to the device files read/write to the circular buffer, plus a few drivers do dma directly to/from it. I personally don't have a problem with requiring drivers to have their own dma buffers and making them copy data between their private dma buffers and the main circular buffer. I guess the original design wanted to support zero-copy dma. Great to hear that. How about a patch that solves my build problem on PPC64(the problem seems to be existing for long) ? In any case, doing PAGE_KERNEL_NOCACHE for DMA memory is incorrect on many architectures. So at this stage, there's no much option but ifdef I suspect for now until this is fixed properly. It does make sense to want to have some memory like that shared between user space and DMA, though I don't know what the right approach that works on all archs is at this stage. Worth asking the Alsa guys, I think they have similar issues :-) But doing double buffering might do the trick fine for now. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
