* [patch 5/5] [v2] powerpc: PA Semi PWRficient MAINTAINER entry
From: Olof Johansson @ 2006-09-05 23:47 UTC (permalink / raw)
To: paulus, anton; +Cc: linuxppc-dev
In-Reply-To: <20060905184316.4c1a460b@localhost.localdomain>
Maintainer entry for PWRficient
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: merge/MAINTAINERS
===================================================================
--- merge.orig/MAINTAINERS
+++ merge/MAINTAINERS
@@ -1783,6 +1783,13 @@ W: http://www.penguinppc.org/
L: linuxppc-embedded@ozlabs.org
S: Maintained
+LINUX FOR POWERPC PA SEMI PWRFICIENT
+P: Olof Johansson
+M: olof@lixom.net
+W: http://www.pasemi.com/
+L: linuxppc-dev@ozlabs.org
+S: Supported
+
LLC (802.2)
P: Arnaldo Carvalho de Melo
M: acme@conectiva.com.br
^ permalink raw reply
* [patch 0/5] [v2] powerpc: PA Semi PWRficient patches
From: Olof Johansson @ 2006-09-05 23:43 UTC (permalink / raw)
To: paulus, anton; +Cc: linuxppc-dev
Hi,
The following series of patches introduces basic support for PA Semi's
PA6T core, and the base platform support for PWRficient PA6T-1682M.
It is split up in 5 separate patches:
1. Reduce default cacheline size to 64 bytes
2. Divorce CPU_FTR_CTRL from CPU_FTR_PPCAS_ARCH_V2_BASE
3. Cpu table entry, PVR value
4. Basic arch/powerpc/platforms/pasemi contents
5. MAINTAINER entry
Changes since last submission:
* Include file cleanup (Roland)
* Whitespace/line length fixes (Mikey, Joel)
* Kill linux,pci-domain stuff (Ben)
* Remove loops_per_jiffy default (Ben)
* Enforce PCI-e config space addressing (Ben)
* Whitespace, init, cast fixes (Arnd)
* Prototypes -> pasemi.h (Arnd)
* Kill some of the RTC stubs (Arnd)
-Olof
^ permalink raw reply
* [patch 1/5] [v2] powerpc: Reduce default cacheline size to 64 bytes
From: Olof Johansson @ 2006-09-05 23:47 UTC (permalink / raw)
To: paulus, anton; +Cc: linuxppc-dev
In-Reply-To: <20060905184316.4c1a460b@localhost.localdomain>
Reduce default cacheline size on 64-bit powerpc from 128 bytes to 64.
This is the architected minimum. In most cases we'll still end up using
cache line information from the device tree, but defaults are used during
early boot and doing a few dcbst/icbi's too many there won't do any harm.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: merge/arch/powerpc/kernel/setup_64.c
===================================================================
--- merge.orig/arch/powerpc/kernel/setup_64.c
+++ merge/arch/powerpc/kernel/setup_64.c
@@ -78,10 +78,10 @@ u64 ppc64_pft_size;
* before we've read this from the device tree.
*/
struct ppc64_caches ppc64_caches = {
- .dline_size = 0x80,
- .log_dline_size = 7,
- .iline_size = 0x80,
- .log_iline_size = 7
+ .dline_size = 0x40,
+ .log_dline_size = 6,
+ .iline_size = 0x40,
+ .log_iline_size = 6
};
EXPORT_SYMBOL_GPL(ppc64_caches);
Index: merge/arch/powerpc/kernel/head_64.S
===================================================================
--- merge.orig/arch/powerpc/kernel/head_64.S
+++ merge/arch/powerpc/kernel/head_64.S
@@ -1748,7 +1748,7 @@ _STATIC(__after_prom_start)
_GLOBAL(copy_and_flush)
addi r5,r5,-8
addi r6,r6,-8
-4: li r0,16 /* Use the least common */
+4: li r0,8 /* Use the smallest common */
/* denominator cache line */
/* size. This results in */
/* extra cache line flushes */
^ permalink raw reply
* [patch 2/5] [v2] powerpc: Divorce CPU_FTR_CTRL from CPU_FTR_PPCAS_ARCH_V2_BASE
From: Olof Johansson @ 2006-09-05 23:47 UTC (permalink / raw)
To: paulus, anton; +Cc: linuxppc-dev
In-Reply-To: <20060905184316.4c1a460b@localhost.localdomain>
The performance monitor implementation (including CTRL register behaviour)
is just included in PPC v2 as an example, it's not truly part of the base.
It's actually a somewhat misleading feature, but I'll leave that be for
now: The precense of the register is not what the feature bit is used
for, but instead it's used to determine if it contains the runlatch
bit for idle reporting of the performance monitor. For alternative
implementations, the register might still exist but the bit might have
different meaning (or no meaning at all).
For now, split it off and don't include it in CPU_FTR_PPCAS_ARCH_V2_BASE.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: merge/include/asm-powerpc/cputable.h
===================================================================
--- merge.orig/include/asm-powerpc/cputable.h
+++ merge/include/asm-powerpc/cputable.h
@@ -148,7 +148,7 @@ extern void do_cpu_ftr_fixups(unsigned l
#define CPU_FTR_PPCAS_ARCH_V2_BASE (CPU_FTR_SLB | \
CPU_FTR_TLBIEL | CPU_FTR_NOEXECUTE | \
- CPU_FTR_NODSISRALIGN | CPU_FTR_CTRL)
+ CPU_FTR_NODSISRALIGN)
/* iSeries doesn't support large pages */
#ifdef CONFIG_PPC_ISERIES
@@ -313,24 +313,25 @@ extern void do_cpu_ftr_fixups(unsigned l
CPU_FTR_HPTE_TABLE | CPU_FTR_IABR | \
CPU_FTR_MMCRA | CPU_FTR_CTRL)
#define CPU_FTRS_POWER4 (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
- CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_MMCRA)
+ CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
+ CPU_FTR_MMCRA)
#define CPU_FTRS_PPC970 (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
- CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | \
+ CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_CAN_NAP | CPU_FTR_MMCRA)
#define CPU_FTRS_POWER5 (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
- CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | \
+ CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
CPU_FTR_PURR)
#define CPU_FTRS_POWER6 (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
- CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | \
+ CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
CPU_FTR_PURR | CPU_FTR_CI_LARGE_PAGE | CPU_FTR_REAL_LE)
#define CPU_FTRS_CELL (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
- CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | \
+ CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
- CPU_FTR_CTRL | CPU_FTR_PAUSE_ZERO | CPU_FTR_CI_LARGE_PAGE)
+ CPU_FTR_PAUSE_ZERO | CPU_FTR_CI_LARGE_PAGE)
#define CPU_FTRS_COMPATIBLE (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2)
#endif
^ permalink raw reply
* Re: MPC8245 reset register
From: Jon Scully @ 2006-09-06 0:06 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <198592450609051149h47423ebev9c94eb8aefc2a3fb@mail.gmail.com>
On 9/5/06, Reeve Yang <yang.reeve@gmail.com> wrote:
> I'm kind of curious what's the proper way to reset the
> 8245 CPU? For anyone who doesn't know MPC8245, which is 603e core.
You could starve the watchdog (assuming SWE=1 in SYPCR). If you own
the hardware design, you could add an addressable WO latch (FPGA) that
asserts reset for the right number of clock cycles (what I would
normally provide or ask for in a design -- but *only* during
development). Otherwise... If this is for development purposes,
consider using JTAG (Boundary Scan) to control /SRESET.
(My reference to RST was supposed to be humorous -- as in, remember
the good old days when you could do that in S/W?! ('RST 7' in Z80 &
8085) Sorry for my bad humor.)
^ permalink raw reply
* Re: [patch 0/5] [v2] powerpc: PA Semi PWRficient patches
From: Michael Ellerman @ 2006-09-06 0:17 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <20060905184316.4c1a460b@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
On Tue, 2006-09-05 at 18:43 -0500, Olof Johansson wrote:
> Hi,
>
> The following series of patches introduces basic support for PA Semi's
> PA6T core, and the base platform support for PWRficient PA6T-1682M.
I have a spare 'o' and 'e' over here if you want 'em?
;)
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* [PATCH] kdump : Support kernels having 64k page size.
From: Sachin P. Sant @ 2006-09-06 0:26 UTC (permalink / raw)
To: linuxppc-dev; +Cc: fastboot-bounces
[-- Attachment #1: Type: text/plain, Size: 167 bytes --]
The following kernel patch [ along with a patch to kexec tools posted
seperately ]
is required to generate proper core files using kdump on ppc64.
Thanks
-Sachin
[-- Attachment #2: ppc64-kexec-tools-64k-page-support --]
[-- Type: text/plain, Size: 663 bytes --]
* Generate proper core files using kdump on ppc64 with 64k page support.
Signed-off-by: Sachin Sant <sachinp@in.ibm.com>
---
diff -Naurp a/include/asm-powerpc/kdump.h b/include/asm-powerpc/kdump.h
--- a/include/asm-powerpc/kdump.h 2006-08-31 03:01:13.000000000 +0530
+++ b/include/asm-powerpc/kdump.h 2006-08-31 05:49:13.000000000 +0530
@@ -7,7 +7,7 @@
/* How many bytes to reserve at zero for kdump. The reserve limit should
* be greater or equal to the trampoline's end address.
* Reserve to the end of the FWNMI area, see head_64.S */
-#define KDUMP_RESERVE_LIMIT 0x8000
+#define KDUMP_RESERVE_LIMIT max(0x8000, PAGE_SIZE)
#ifdef CONFIG_CRASH_DUMP
^ permalink raw reply
* Re: On the transfer of data from the uart.c driver to the tty layer...
From: Benjamin Herrenschmidt @ 2006-09-06 0:45 UTC (permalink / raw)
To: Alejandro C; +Cc: linuxppc-dev
In-Reply-To: <BAY121-F225DA006048FC317F8E97BDB300@phx.gbl>
On Tue, 2006-09-05 at 14:56 +0000, Alejandro C wrote:
> Hi all,
>
> I'm working on a the uart.c driver to add support for SCCs in HDLC mode. The
> application I'm going to run on top will be sending Ethernet packets
> encapsulated in the data field of an HDLC frame. The idea was to make the
> buffer big enough so that a whole Eth. packet (max 1518 octects) could fit
> in just one buffer. I let the CPM interrupt on a frame basis and the problem
> I've come across is that the receive buffer in the struct tty_struct, where
> the tty layer collects the data from the driver
> (tty_struct.tty_flip_buffer.char_buf), is only 1024 bytes
> (2*TTY_FLIPBUF_SIZE). The easiest at this stage would be to make those
> buffers larger, but I don't know what sort of impact this might have... Any
> tips?
> Any ideas on how to solve it in another fashion?
>
> Help will be highly appreciated.
You should ask on the linux-kernel mailing list, possibly CC'ing Alan
Cox who seem to have put his hands a lot in the TTY code lately.
Ben.
^ permalink raw reply
* Re: MPC8245 reset register
From: Reeve Yang @ 2006-09-06 0:50 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <53107f6e0609051706i67eac762y114ad03bf2065548@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]
LoL, my bad not understanding the humor.
This becomes an interesting topic. I looked at different CPUs, it seems
everyone uses different method to reset itself, and there is no uniformed or
easy for 603e. I searched on google but didn't see anyone have similiar
concern. Actually lots of boxes/systems using MPC8245, why nobody cares
about it? :)
To use watchdog timeout, or gpio port to assert reset line on CPU are not
flexible enough. If using watchdog, I have to enable watchdog and reduce the
timeout length (if it's too long). If using some GPIO device, I'll have to
rely on i2c bus or whatever io interface to write data. Acutally our system
has RESET by a GPIO(PCA9556) port.
Interesting enough, I resolved the problem by writing a data to an invalid
address with hoping for a machine check exception (in fact this is what
u-boot does). Would it be good to make it as a stardard "restart" function
in mpc10x_common.c? If it's acceptable I could send out my patch.
- Reeve
On 9/6/06, Jon Scully <jonscully@gmail.com> wrote:
>
> On 9/5/06, Reeve Yang <yang.reeve@gmail.com> wrote:
> > I'm kind of curious what's the proper way to reset the
> > 8245 CPU? For anyone who doesn't know MPC8245, which is 603e core.
>
> You could starve the watchdog (assuming SWE=1 in SYPCR). If you own
> the hardware design, you could add an addressable WO latch (FPGA) that
> asserts reset for the right number of clock cycles (what I would
> normally provide or ask for in a design -- but *only* during
> development). Otherwise... If this is for development purposes,
> consider using JTAG (Boundary Scan) to control /SRESET.
>
> (My reference to RST was supposed to be humorous -- as in, remember
> the good old days when you could do that in S/W?! ('RST 7' in Z80 &
> 8085) Sorry for my bad humor.)
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 2526 bytes --]
^ permalink raw reply
* RE: Wireless Linux(802.11) for Embedded PowerPC
From: Chun Chung Lo @ 2006-09-06 1:30 UTC (permalink / raw)
To: wei.li4, linuxppc-embedded
Hi,
I have also done a such project last year. I used a MPC860SR processor
card, plus an extra tailor-made carrier board (just extend the PCMCIA
interface from the processor card). The design is simple, I just
followed the reference design suggested by Freescale MPC860 user manual.
You can get this manual on Freescale's website.
Then I used a Intersil Prism2 compatible PCMCIA WLAN card (may be a
Compact Flash WLAN card is also OK, but I have never tried this) and
plug into the PCMCIA socket of the carrier board.=0D
In the whole project, I used ELDK 3.0 as my software development
platform (U-Boot, Linux, binutils... etc). And I used linux-wlan as the
WLAN card driver.=0D
But one more thing is I have built 2 of such systems and only tried the
normal WLAN functions (infrastructure, ad-hoc mode) but never AP mode
since the driver and my WLAN card does not support.
Here are some references:
1. WLAN card driver: linux-wlan -- http://www.linux-wlan.org/
2. Freescale MPC860 User Manual: --
http://www.freescale.com/files/netcomm/doc/ref_manual/MPC860UM.pdf
Thanks for your attention.
Best regards,
Lo Chun Chung
-----Original Message-----
From: linuxppc-embedded-bounces+cclo=3Dastri.org@ozlabs.org
[mailto:linuxppc-embedded-bounces+cclo=3Dastri.org@ozlabs.org] On Behalf
Of wei.li4@elf.mcgill.ca
Sent: Wednesday, 06 September, 2006 4:04 AM
To: linuxppc-embedded@ozlabs.org
Subject: Wireless Linux(802.11) for Embedded PowerPC
Hi All,
Where is the best access point for this topic? Did anyone work on this=0D
with MPC8xx? Thanks.
Wei
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
This message (including any attachments) is for the named addressee(s)'s=
use only. It may contain
sensitive, confidential, private proprietary or legally privileged=
information intended for a
specific individual and purpose, and is protected by law. If you are not=
the intended recipient,
please immediately delete it and all copies of it from your system, destroy=
any hard copies of it
and notify the sender. Any use, disclosure, copying, or distribution of=
this message and/or any
attachments is strictly prohibited.
^ permalink raw reply
* Re: pci error recovery procedure
From: Zhang, Yanmin @ 2006-09-06 1:26 UTC (permalink / raw)
To: Linas Vepstas
Cc: Yanmin Zhang, LKML, Rajesh Shah, linuxppc-dev, linux-pci maillist
In-Reply-To: <20060905190115.GE7139@austin.ibm.com>
On Wed, 2006-09-06 at 03:01, Linas Vepstas wrote:
> On Tue, Sep 05, 2006 at 10:32:08AM +0800, Zhang, Yanmin wrote:
> > Is it the exclusive reason to have multi-steps?
>
> I don't understand the question. A previous email explained the reason
> to have mutiple steps.
The question is against Ben's comments. Pls. don't delete his comments
in your reply.
>
> > 1) Here link reset and hard reset are hardware operations, not the
> > link_reset and slot_reset callback in pci_error_handlers.
>
> I don't understand the comment.
I wanted to clarify that we need differentiate link/hard reset from
callback link_reset and slot_reset when discussing the API.
>
> > 2) Callback error_detected will notify drivers there is PCI errors. Drivers
> > shouldn't do any I/O in error_detected.
>
> It shouldn't matter. If it is truly important for a particular platform
> to make sure that there is no i/o, then the low-level i/o routines
> could be modified to drop any accidentally issued i/o on the floor.
> This doesn't require a change to either the API or the policy.
> > 3) If both the link and slot are reset after all error_detected are called,
> > the device should go back to initial status and all DMA should be stopped
> > automatically. Why does the driver still need a chance to stop DMA?
>
> As explained previously, not all drivers may want to have a full
> electrical device reset.
I need repeat my idea.
1) My new pci_error_handlers doesn't always choose to reset slot. It
still depends on the return value of error_detected.
2) As a matter of fact, most cases of specific device's error_detected callback
will choose to return PCI_ERS_RESULT_NEED_RESET. Like what you did for
e100/e1000/ipr.
>
> > The
> > error_detected of the drivers in the latest kernel who support err handlers
> > always returns PCI_ERS_RESULT_NEED_RESET. They are typical examples.
>
> Just because the current drivers do it this way does not mean that this is
> the best way to do things.
If it's not the best way, why did you choose to reset slot for e1000/e100/ipr
error handlers? They are typical widely-used devices. To make it easier to
add error handlers?
> A full reset is time-consuming. Some drivers
> may want to implement a faster and quicker reset.
>
> --linas
^ permalink raw reply
* Re: [patch 0/5] [v2] powerpc: PA Semi PWRficient patches
From: Olof Johansson @ 2006-09-06 1:41 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <1157501868.3661.1.camel@localhost.localdomain>
On Wed, Sep 06, 2006 at 10:17:48AM +1000, Michael Ellerman wrote:
> On Tue, 2006-09-05 at 18:43 -0500, Olof Johansson wrote:
> > Hi,
> >
> > The following series of patches introduces basic support for PA Semi's
> > PA6T core, and the base platform support for PWRficient PA6T-1682M.
>
> I have a spare 'o' and 'e' over here if you want 'em?
>
> ;)
Keep them, I'm sure IBM is working on some new opcodes. They're
so rare, it's better to spend them there! :-)
-Olof
^ permalink raw reply
* Re: pci error recovery procedure
From: Zhang, Yanmin @ 2006-09-06 1:35 UTC (permalink / raw)
To: Linas Vepstas
Cc: Yanmin Zhang, LKML, Rajesh Shah, linuxppc-dev, linux-pci maillist
In-Reply-To: <20060905185020.GD7139@austin.ibm.com>
On Wed, 2006-09-06 at 02:50, Linas Vepstas wrote:
> On Mon, Sep 04, 2006 at 07:03:12PM +1000, Benjamin Herrenschmidt wrote:
> >
> > > As you know, all functions of a device share the same bus number and 5 bit dev number.
> > > They just have different 3 bit function number. We could deduce if functions are in the same
> > > device (slot).
> >
> > Until you have a P2P bridge ...
>
> And this is not theoretical: for example, the matrox graphics cards:
>
> 0000:c8:01.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge (non-transparent mode) (rev 13)
> 0000:c9:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 85)
>
> Now, I could have sworn there was another device behind this bridge,
> some serial or joystick controller or something, although this
> particular card doesn't seem to have it.
Thanks. My comments above in this email is just to try to find a method
to judge if 2 or more functions belongs to the same device. If it's
not right, it still doesn't hurt the new API pci_error_handlers.
>
> ------
> It's not clear to me what hardware may show up in the future.
> For example, someone may build a 32x PCI-E card that will act
> as a bridge to a drawer with half-a-dozen ordinary PCI-X slots
> in it. This is perhaps a bit hypothetical, but changing the API
> will make it harder to implement eror recovery for such a system.
I agree that it's difficult to predict the future. At least the new API
could process the example.
> FWIW, there is at least one pSeries system in the lab which has
> several hundred PCI slots attached to it, although I've never
> done testing on it. Hmm. Maybe its time I did ...
>
> --linas
^ permalink raw reply
* Re: pci error recovery procedure
From: Zhang, Yanmin @ 2006-09-06 2:04 UTC (permalink / raw)
To: Linas Vepstas
Cc: linuxppc-dev, linux-pci maillist, Yanmin Zhang, LKML, Rajesh Shah
In-Reply-To: <20060905191739.GF7139@austin.ibm.com>
On Wed, 2006-09-06 at 03:17, Linas Vepstas wrote:
> On Mon, Sep 04, 2006 at 01:47:30PM +0800, Zhang, Yanmin wrote:
> > >
> > > Again, consider the multi-function cards. On pSeries, I can only enable
> > > DMA on a per-slot basis, not a per-function basis. So if one driver
> > > enables DMA before some other driver has reset appropriately, everything
> > > breaks.
> > Does here 'reset' mean hardware slot reset?
>
> I should have said: If one driver of a multi-function card enables DMA before
> another driver has stabilized its harware, then everything breaks.
What's another driver's hardware? A function of the previous multi-function
card? Or a function of another device?
Ok. now, I copy what you said before below for more discussion.
> If we enabled both DMA and MMIO at the same time, there are mnay cases
> where the card will immediately trap again -- for example, if its
> DMA'ing to some crazy address. Thus, typically, one wants DMA disabled
> until after the card reset. Withouth the mmio_enabled() reset, there
> is no way of doing this.
Did you asume the card reset is executed by callback mmio_enabled?
> Again, consider the multi-function cards. On pSeries, I can only enable
> DMA on a er-slot basis, not a per-function basis. So if one driver
> enables DMA before some other driver has reset appropriately, everything
> breaks.
What does 'I' above stand for? The platform error recovery procedure
or the error callbacks of drivers? I guess it means platform, that is,
only platform enables DMA for the whole slot. But why does the last sentence
become driver enables DMA? As you know, driver binds device function instead of
slot. Could driver enable DMA for a function?
>
> > Then, if the slot is always reset, there will be no the problem.
>
> But that assumes that a hardware #RST will always be done. The API
> was designed to get away from this requirement.
>
> > If mmio_enabled is not used currently, I think we could delete it firstly. Later on,
> > if a platform really need it, we could add it, so we could keep the simplied codes.
>
> It would be very difficult to add it later. And it would be especially
> silly, given that someone would find this discussion in the mailing list
> archives.
You stick to keep mmio_enabled which is not used currently, but if there will be
a new platform who uses a more fine-grained steps to recover pci/pci-e, would
you say 'it would be very difficut' and refuse add new callbacks?
>
> > Thanks. Now I understand why you specified mmio_enabled and slot_reset. They are just
> > to map to pSeries platform hardware operation steps. I know little about pSeries hardware,
>
> The hardware was designed that way because the hardware engineers
> thought that this is what the device driver writers would need.
> Thay are there to map to actual recovery steps that actual device
> drivers might want to do.
It doesn't prevent software from merging some steps. And, we want
to implement pci/pci-e error recovery for more platforms instead of just
pSeries.
>
> > but is it possible to merge such hardware steps from software point of view?
>
> The previous email explained why this would be a bad idea.
Obviously, such conclusion is too early.
>
> > > The platform. By "electrical reset", I mean "dropping the #RST pin low
> > > for 200mS". Only the platform can do this.
> > Thanks for your explanation. I assume after the electrical reset, all device
> > functions of the device slot will go back to the initial status before
> > attaching their drivers.
>
> Maybe. Depends on what yur BIOS does. On pSeries, I also need to
> set up the adress BARs
>
> > I found a problem of e1000 driver when testing its error handlers. After the NIC is resumed,
> > its RX/TX packets numbers are crazy.
>
> Hmm. There is a patch to prevent this from happening. I thought
> it was applied a long time ago. e1000_update_stats() should include the
> lines:
>
> if (pdev->error_state && pdev->error_state != pci_channel_io_normal)
> return;
>
> which is enough to prevent crazy stats on my machine.
Thanks a lot!
Yanmin
^ permalink raw reply
* Re: On the transfer of data from the uart.c driver to the tty layer...
From: Dan Malek @ 2006-09-06 2:28 UTC (permalink / raw)
To: Alejandro C; +Cc: linuxppc-dev
In-Reply-To: <BAY121-F225DA006048FC317F8E97BDB300@phx.gbl>
On Sep 5, 2006, at 10:56 AM, Alejandro C wrote:
> I'm working on a the uart.c driver to add support for SCCs in HDLC
> mode.
Write a driver that does HDLC, please don't "update"
(complicate) the existing uart.c driver by adding
these features. The uart.c is a UART driver, not
an SCC driver to be modified to your wishes.
Add another, configurable driver to do this.
> I've come across is that the receive buffer in the struct
> tty_struct, where
> the tty layer collects the data from the driver
> (tty_struct.tty_flip_buffer.char_buf), is only 1024 bytes
Write a driver specific to your requirements that
has the proper sized buffers and management.
> (2*TTY_FLIPBUF_SIZE). The easiest at this stage would be to make those
> buffers larger, but I don't know what sort of impact this might
> have... Any
> tips?
Yes, don't do this. Those buffers are allocated from
a fairly small pool specific to the needs of the uart
driver. Making these larger may quickly cause the
CPM drivers to run out of space.
> Any ideas on how to solve it in another fashion?
Write a driver specific to your requirements with the
proper buffer management for these sizes.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] kdump : Support kernels having 64k page size.
From: Michael Ellerman @ 2006-09-06 2:59 UTC (permalink / raw)
To: Sachin P. Sant; +Cc: linuxppc-dev
In-Reply-To: <44FE15B0.3030909@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 578 bytes --]
On Wed, 2006-09-06 at 05:56 +0530, Sachin P. Sant wrote:
> The following kernel patch [ along with a patch to kexec tools posted
> seperately ]
> is required to generate proper core files using kdump on ppc64.
Hi Sachin,
Can you provide some more explanation? It's not clear to me why this is
necessary.
thanks
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: common flatdevtree code
From: Paul Mackerras @ 2006-09-06 3:52 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, hollisb
In-Reply-To: <20060831184020.GA13494@mag.az.mvista.com>
Mark A. Greer writes:
> I'm doing some fairly massive rework to my patches so it'll take
> another day or two (plus 4 day weekend for me). In the meantime,
> this is what I've done to your code. :)
Any further progress on this? I need an ft library for the prep
bootwrapper changes I'm planning.
I don't like the approach of doing a malloc for the whole blob every
time you make a property larger though. I'm going to be adding quite
a few nodes and properties, potentially, and with a simple-minded
malloc (such as you get in a bootwrapper) it's likely to chew through
a lot of memory unnecessarily. I would rather be able to start with
an existing blob and pull it apart once, add stuff to it, then put it
back together, doing a small number of mallocs in the process.
> I still plan on changing it a bit to use ft_next in a few more routines
> (e.g., ft_dump_blob). ft_next has a clumsy interface but I like the fact
The interface might look nicer if we had a structure for the tag,
name, value and length. Then there would only be one parameter
instead of the four you have at the moment.
Paul.
^ permalink raw reply
* Re: [PATCH] kdump : Support kernels having 64k page size.
From: Haren Myneni @ 2006-09-06 6:13 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, Sachin P. Sant
In-Reply-To: <1157511577.3661.7.camel@localhost.localdomain>
Michael Ellerman wrote:
>On Wed, 2006-09-06 at 05:56 +0530, Sachin P. Sant wrote:
>
>
>>The following kernel patch [ along with a patch to kexec tools posted
>>seperately ]
>>is required to generate proper core files using kdump on ppc64.
>>
>>
>
>Hi Sachin,
>
>Can you provide some more explanation? It's not clear to me why this is
>necessary.
>
>thanks
>
>
>
At present we are doing the backup of 32K. Thus created one ELF PT_LOAD
segment for this region.
But, in the case of 64K page size, second segments starts at 32K and the
first one is not page aligned. __ioremap() (crash_dump.c) getting
failed if pfn = 0 which is the case for the second PT_LOAD segment. We
did not hit this issue for 4K page size because the the first page (32K
backup) is copied to second kernel memory and thus referencing with the
second kernel pfn.
Here the fix is, backup regions size is max(PAGE_SIZE, 32K) so that
at least one page will be part of backup ELF segment. Drawback here is,
we will end up 32K more for backup for 64K page size.
It can also be fixed in copy_oldmem_page() (crash_dump.c), but first
PT_LOAD segment is not page aligned:
if (pfn > 0)
vaddr = __ioremap(pfn << PAGE_SHIFT, PAGE_SIZE, 0);
else
vaddr = __va(pfn << PAGE_SHIFT);
Thanks
Haren
>------------------------------------------------------------------------
>
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: MAC driver issue
From: David H. Lynch Jr. @ 2006-09-06 6:25 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <44FD3640.30208@cambridgebroadband.com>
Alex Zeffertt wrote:
> Hi David,
>
> I think in order to get any help from this list you need to be more
> specific
> about how this problem relates to PowerPCs.
The relationship is weak - the driver is for a NIC in an embedded
PPC 405.
I was just hoping that someone here might have experienced a similar
problem and have an idea what the answer might be -
rather than join another list - I am sure there must be something
like a network drivers list
>
> You also need to say exactly what "never gets handed off to the ARP
> protocol"
> means.
I mean I put a printk into the ARP protocol handler and in the
working case I get to the prink, and in the failing case I don't.
I have tried inspecting netif_rx - but it just queues up received
packets - and in both my cases returns success.
I am basically tryng to figure out what is it that the inbound
network stack is upset about - somewhere it must have decided to reject
my data, if I knew what it did not like, I would have a clue what to
fix.
> FWIW, in my experience the hardware independent parts of the
> networking stack are
> very stable and the problem is almost always with the drivers, or with
> the IP
> configuration (e.g. two interfaces on the same subnet).
I have no doubt it is with the driver. I am somewhat fortunate in
this instance that I have a nearly identical setup - this is an FPGA
based system
I can swap the FPGA firmware, get an almost identical kernel with a
slightly different NIC, and everything works - same cables, same IP's,
Same switch, The only things different are the NIC and its driver.
Even the Linux kernels are identical - except the NIC driver.
BUT so is the data received and passed on to the kernel (outside
random differences in the padding of the ARP packet)
One works the other doesn't.
But since everything looks perfect, I have no clue where to start looking.
>
> Alex
>
> David H. Lynch Jr. wrote:
>> I am trying to get a network driver working.
>>
>> It sends - I can capture the output with Etherreal and it looks good.
>> It receives - I can dump the received packets when the come in and
>> they look ok to me.
>>
>>
>> BUT,
>> If I try to ping another host, first Linux sends and ARP
>> broadcast, the appropriate client sends an ARP response.
>> Etherreal is happy with both.
>> My driver gets the response - The driver says the packet lenght
>> is 64 bytes, which includes something like 14 bytes of padding at the
>> end.
>> But the actual packet looks perfect exactly like what etherreal
>> says it should (and what I get when I capture a received ARP packet
>> in another driver).
>> At the end of the recive interrupt the skb is passed to Linux
>> with the netif_rc(ndev) function. This returns SUCCESS.
>>
>> However, the paket never gets handed of to the ARP protocol - I
>> put some debugging in there and I never see it, while if I switch to
>> a different NIC
>> driver nearly the identical ARP packet gets processed by arp
>> inside Linux.
>>
>> I have tried to chase this down, but I can't follow what is
>> going on inside of all the /net/core/dev.c etc.
>>
>> Has anyone seen something similar to this ?
>>
>> Does anyone have a clue where I can find some info on trying to
>> follow something through netif_rx to see where things are going off
>> the rails ?
>>
>>
>>
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* RE: [PATCH 4/4] Add MPC8349E MDS device tree source file toarch/powerpc/boot/dts
From: Jiang Bo-r61859 @ 2006-09-06 7:36 UTC (permalink / raw)
To: Phillips Kim-R1AAHA, linuxppc-dev
In-Reply-To: <20060825115947.0d9ad52f.kim.phillips@freescale.com>
=20
>-----Original Message-----
>Add MPC8349E MDS device tree source file to=20
>arch/powerpc/boot/dts, aptly indicating new school sense=20
>values definition.
>
> arch/powerpc/boot/dts/mpc8349emds.dts | 328=20
>+++++++++++++++++++++++++++++++++
> 1 files changed, 328 insertions(+), 0 deletions(-)
>+ device_type =3D "serial";
>+ pci@8500 {
>+ interrupt-map-mask =3D <f800 0 0 7>;
>+ interrupt-map =3D <
>+
>+ /* IDSEL 0x11 */
>+ 8800 0 0 1 700 14 0
>+ 8800 0 0 2 700 15 0
>+ 8800 0 0 3 700 16 0
>+ 8800 0 0 4 700 17 0
snip
>+
>+ /* IDSEL 0x18 */
>+ b000 0 0 1 700 15 0
>+ b000 0 0 2 700 16 0
>+ b000 0 0 3 700 17 0
>+ b000 0 0 4 700 14 0>;
snip
If it is about IDSEL 0x18, b000 should be c000
>+
>+ pci@8600 {
>+ interrupt-map-mask =3D <f800 0 0 7>;
>+ interrupt-map =3D <
>+
snip
>+ /* IDSEL 0x18 */
>+ b000 0 0 1 700 15 0
>+ b000 0 0 2 700 16 0
>+ b000 0 0 3 700 17 0
>+ b000 0 0 4 700 14 0>;
Same problem.
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* MPC5200 SPI interface.
From: Txema Lopez @ 2006-09-06 7:30 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 503 bytes --]
Hi all,
We are developping a Lite5200B based custom board and we are planning to
connect some SPI peripherals. But we are not sure about what MPC5200 SPI
interface choose. Does anyone know what are the
advantages/disadvantages of use the MPC5200 SPI dedicated interface or
an PSC (PSC3) as the SPI interface?. The linux kernel includes both
interfaces but we can not see in the documentation anything about this
aspect. Any kind of information will be welcomed.
Best Regards,
José María López.
[-- Attachment #2: tlopez.vcf --]
[-- Type: text/x-vcard, Size: 324 bytes --]
begin:vcard
fn:Jose Maria Lopez
n:Lopez;Jose Maria
org:Fagor Automation S. Coop.
adr:;;San Andres 19. Apdo. 144;Arrasate-Mondragon;;20500;Spain
email;internet:tlopez@aotek.es
title:Sotware engineer
tel;work:(34) 943719200
tel;fax:(34) 943791712
x-mozilla-html:FALSE
url:http://www.fagorautomation.es
version:2.1
end:vcard
^ permalink raw reply
* [POWERPC] merge iSeries i/o operations with the rest
From: Stephen Rothwell @ 2006-09-06 8:24 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
In-Reply-To: <20060905120817.e52857ee.sfr@canb.auug.org.au>
The low level i/o operations are now handled in iSeries by taking a
trap when we access the (inaccessible) io memory region and calling the
Hypervisor from the trap code.
The memset_io/memcpy_(to,from)io routines just do a firmware feature
check as it will compile out in the non combined build case and in the
combined build, the extra check is a relatively small overhead.
The remainder of the routines are not used in the drivers for any
currently supported hardware on legacy iSeries (they used to BUG or were
not even implemented), so just use the eeh versions.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/mm/fault.c | 8 +
arch/powerpc/platforms/iseries/pci.c | 170 +++++++++++++++++++++---------
include/asm-powerpc/io.h | 78 +++++---------
include/asm-powerpc/iseries/iseries_io.h | 27 -----
include/asm-powerpc/ppc-pci.h | 11 ++
5 files changed, 169 insertions(+), 125 deletions(-)
This version does not change the low level inline assembler operations at
all (and so emulates more instructions in th trap handler).
Thus there are no changes to the generated code unles you compile for
legacy iSeries where I have booted this.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 78a0d59..e8add2b 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -38,6 +38,8 @@ #include <asm/uaccess.h>
#include <asm/tlbflush.h>
#include <asm/kdebug.h>
#include <asm/siginfo.h>
+#include <asm/firmware.h>
+#include <asm/ppc-pci.h>
#ifdef CONFIG_KPROBES
ATOMIC_NOTIFIER_HEAD(notify_page_fault_chain);
@@ -185,8 +187,12 @@ #endif /* CONFIG_4xx || CONFIG_BOOKE */
}
/* On a kernel SLB miss we can only check for a valid exception entry */
- if (!user_mode(regs) && (address >= TASK_SIZE))
+ if (!user_mode(regs) && (address >= TASK_SIZE)) {
+ if (firmware_has_feature(FW_FEATURE_ISERIES) &&
+ iseries_handle_io_fault(regs, address))
+ return 0;
return SIGSEGV;
+ }
#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
if (error_code & DSISR_DABRMATCH) {
diff --git a/arch/powerpc/platforms/iseries/pci.c b/arch/powerpc/platforms/iseries/pci.c
index f4d427a..0c94046 100644
--- a/arch/powerpc/platforms/iseries/pci.c
+++ b/arch/powerpc/platforms/iseries/pci.c
@@ -26,6 +26,7 @@ #include <linux/init.h>
#include <linux/module.h>
#include <linux/ide.h>
#include <linux/pci.h>
+#include <linux/ptrace.h>
#include <asm/io.h>
#include <asm/irq.h>
@@ -38,6 +39,7 @@ #include <asm/abs_addr.h>
#include <asm/iseries/hv_call_xm.h>
#include <asm/iseries/mf.h>
#include <asm/iseries/iommu.h>
+#include <asm/iseries/iseries_io.h>
#include <asm/ppc-pci.h>
@@ -270,46 +272,6 @@ void pcibios_fixup_resources(struct pci_
}
/*
- * I/0 Memory copy MUST use mmio commands on iSeries
- * To do; For performance, include the hv call directly
- */
-void iSeries_memset_io(volatile void __iomem *dest, char c, size_t Count)
-{
- u8 ByteValue = c;
- long NumberOfBytes = Count;
-
- while (NumberOfBytes > 0) {
- iSeries_Write_Byte(ByteValue, dest++);
- -- NumberOfBytes;
- }
-}
-EXPORT_SYMBOL(iSeries_memset_io);
-
-void iSeries_memcpy_toio(volatile void __iomem *dest, void *source, size_t count)
-{
- char *src = source;
- long NumberOfBytes = count;
-
- while (NumberOfBytes > 0) {
- iSeries_Write_Byte(*src++, dest++);
- -- NumberOfBytes;
- }
-}
-EXPORT_SYMBOL(iSeries_memcpy_toio);
-
-void iSeries_memcpy_fromio(void *dest, const volatile void __iomem *src, size_t count)
-{
- char *dst = dest;
- long NumberOfBytes = count;
-
- while (NumberOfBytes > 0) {
- *dst++ = iSeries_Read_Byte(src++);
- -- NumberOfBytes;
- }
-}
-EXPORT_SYMBOL(iSeries_memcpy_fromio);
-
-/*
* Look down the chain to find the matching Device Device
*/
static struct device_node *find_Device_Node(int bus, int devfn)
@@ -491,7 +453,7 @@ static inline struct device_node *xlate_
* iSeries_Read_Word = Read Word (16 bit)
* iSeries_Read_Long = Read Long (32 bit)
*/
-u8 iSeries_Read_Byte(const volatile void __iomem *IoAddress)
+static u8 iSeries_Read_Byte(const volatile void __iomem *IoAddress)
{
u64 BarOffset;
u64 dsa;
@@ -518,9 +480,8 @@ u8 iSeries_Read_Byte(const volatile void
return (u8)ret.value;
}
-EXPORT_SYMBOL(iSeries_Read_Byte);
-u16 iSeries_Read_Word(const volatile void __iomem *IoAddress)
+static u16 iSeries_Read_Word(const volatile void __iomem *IoAddress)
{
u64 BarOffset;
u64 dsa;
@@ -548,9 +509,8 @@ u16 iSeries_Read_Word(const volatile voi
return swab16((u16)ret.value);
}
-EXPORT_SYMBOL(iSeries_Read_Word);
-u32 iSeries_Read_Long(const volatile void __iomem *IoAddress)
+static u32 iSeries_Read_Long(const volatile void __iomem *IoAddress)
{
u64 BarOffset;
u64 dsa;
@@ -578,7 +538,6 @@ u32 iSeries_Read_Long(const volatile voi
return swab32((u32)ret.value);
}
-EXPORT_SYMBOL(iSeries_Read_Long);
/*
* Write MM I/O Instructions for the iSeries
@@ -587,7 +546,7 @@ EXPORT_SYMBOL(iSeries_Read_Long);
* iSeries_Write_Word = Write Word(16 bit)
* iSeries_Write_Long = Write Long(32 bit)
*/
-void iSeries_Write_Byte(u8 data, volatile void __iomem *IoAddress)
+static void iSeries_Write_Byte(u8 data, volatile void __iomem *IoAddress)
{
u64 BarOffset;
u64 dsa;
@@ -612,9 +571,8 @@ void iSeries_Write_Byte(u8 data, volatil
rc = HvCall4(HvCallPciBarStore8, dsa, BarOffset, data, 0);
} while (CheckReturnCode("WWB", DevNode, &retry, rc) != 0);
}
-EXPORT_SYMBOL(iSeries_Write_Byte);
-void iSeries_Write_Word(u16 data, volatile void __iomem *IoAddress)
+static void iSeries_Write_Word(u16 data, volatile void __iomem *IoAddress)
{
u64 BarOffset;
u64 dsa;
@@ -639,9 +597,8 @@ void iSeries_Write_Word(u16 data, volati
rc = HvCall4(HvCallPciBarStore16, dsa, BarOffset, swab16(data), 0);
} while (CheckReturnCode("WWW", DevNode, &retry, rc) != 0);
}
-EXPORT_SYMBOL(iSeries_Write_Word);
-void iSeries_Write_Long(u32 data, volatile void __iomem *IoAddress)
+static void iSeries_Write_Long(u32 data, volatile void __iomem *IoAddress)
{
u64 BarOffset;
u64 dsa;
@@ -666,4 +623,113 @@ void iSeries_Write_Long(u32 data, volati
rc = HvCall4(HvCallPciBarStore32, dsa, BarOffset, swab32(data), 0);
} while (CheckReturnCode("WWL", DevNode, &retry, rc) != 0);
}
-EXPORT_SYMBOL(iSeries_Write_Long);
+
+/*
+ * I/0 Memory copy MUST use mmio commands on iSeries
+ * To do; For performance, include the hv call directly
+ */
+void iSeries_memset_io(volatile void __iomem *dest, char c, size_t Count)
+{
+ u8 ByteValue = c;
+ long NumberOfBytes = Count;
+
+ while (NumberOfBytes > 0) {
+ iSeries_Write_Byte(ByteValue, dest++);
+ -- NumberOfBytes;
+ }
+}
+EXPORT_SYMBOL(iSeries_memset_io);
+
+void iSeries_memcpy_toio(volatile void __iomem *dest, const void *source,
+ size_t count)
+{
+ const char *src = source;
+ long NumberOfBytes = count;
+
+ while (NumberOfBytes > 0) {
+ iSeries_Write_Byte(*src++, dest++);
+ -- NumberOfBytes;
+ }
+}
+EXPORT_SYMBOL(iSeries_memcpy_toio);
+
+void iSeries_memcpy_fromio(void *dest, const volatile void __iomem *src, size_t count)
+{
+ char *dst = dest;
+ long NumberOfBytes = count;
+
+ while (NumberOfBytes > 0) {
+ *dst++ = iSeries_Read_Byte(src++);
+ -- NumberOfBytes;
+ }
+}
+EXPORT_SYMBOL(iSeries_memcpy_fromio);
+
+int iseries_handle_io_fault(struct pt_regs *regs, unsigned long address)
+{
+ u32 instr;
+ int reg;
+ int ra;
+ int op;
+ int eop;
+ void __iomem *addr = (void __iomem *)address;
+
+ /* is the address in out i/o range? */
+ if ((address < BASE_IO_MEMORY) || (address >= max_io_memory))
+ return 0;
+ /* we are only called for kernel mode faults */
+ instr = *(u32 *)regs->nip;
+ op = (instr >> 26) & 0x3f;
+ reg = (instr >> 21) & 0x1f;
+ ra = (instr >> 16) & 0x1f;
+ switch (op) {
+ case 31:
+ eop = (instr >> 1) & 0x3ff;
+
+ switch (eop) {
+ case 87: /* lbzx */
+ case 119: /* lbzux */
+ regs->gpr[reg] = iSeries_Read_Byte(addr);
+ if (eop & 0x20)
+ regs->gpr[ra] = address;
+ break;
+ case 215: /* stbx */
+ case 247: /* stbux */
+ iSeries_Write_Byte(regs->gpr[reg], addr);
+ if (eop & 0x20)
+ regs->gpr[ra] = address;
+ break;
+ case 790: /* lhbrx */
+ regs->gpr[reg] = iSeries_Read_Word(addr);
+ break;
+ case 918: /* sthbrx */
+ iSeries_Write_Word(regs->gpr[reg], addr);
+ break;
+ case 534: /* lwbrx */
+ regs->gpr[reg] = iSeries_Read_Long(addr);
+ break;
+ case 662: /* stwbrx */
+ iSeries_Write_Long(regs->gpr[reg], addr);
+ break;
+ default:
+ return 0;
+ }
+ break;
+ case 34: /* lbz */
+ case 35: /* lbzu */
+ regs->gpr[reg] = iSeries_Read_Byte(addr);
+ if (op & 1)
+ regs->gpr[ra] = address;
+ break;
+ case 38: /* stb */
+ case 39: /* stbu */
+ iSeries_Write_Byte(regs->gpr[reg], addr);
+ if (op & 1)
+ regs->gpr[ra] = address;
+ break;
+ default:
+ return 0;
+ }
+ regs->nip += 4;
+ return 1;
+}
diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h
index 36c4c34..7762898 100644
--- a/include/asm-powerpc/io.h
+++ b/include/asm-powerpc/io.h
@@ -19,11 +19,10 @@ #else
#include <linux/compiler.h>
#include <asm/page.h>
#include <asm/byteorder.h>
-#ifdef CONFIG_PPC_ISERIES
#include <asm/iseries/iseries_io.h>
-#endif
#include <asm/synch.h>
#include <asm/delay.h>
+#include <asm/firmware.h>
#include <asm-generic/iomap.h>
@@ -41,44 +40,10 @@ #define SLOW_DOWN_IO
extern unsigned long isa_io_base;
extern unsigned long pci_io_base;
-#ifdef CONFIG_PPC_ISERIES
-/* __raw_* accessors aren't supported on iSeries */
-#define __raw_readb(addr) { BUG(); 0; }
-#define __raw_readw(addr) { BUG(); 0; }
-#define __raw_readl(addr) { BUG(); 0; }
-#define __raw_readq(addr) { BUG(); 0; }
-#define __raw_writeb(v, addr) { BUG(); 0; }
-#define __raw_writew(v, addr) { BUG(); 0; }
-#define __raw_writel(v, addr) { BUG(); 0; }
-#define __raw_writeq(v, addr) { BUG(); 0; }
-#define readb(addr) iSeries_Read_Byte(addr)
-#define readw(addr) iSeries_Read_Word(addr)
-#define readl(addr) iSeries_Read_Long(addr)
-#define writeb(data, addr) iSeries_Write_Byte((data),(addr))
-#define writew(data, addr) iSeries_Write_Word((data),(addr))
-#define writel(data, addr) iSeries_Write_Long((data),(addr))
-#define memset_io(a,b,c) iSeries_memset_io((a),(b),(c))
-#define memcpy_fromio(a,b,c) iSeries_memcpy_fromio((a), (b), (c))
-#define memcpy_toio(a,b,c) iSeries_memcpy_toio((a), (b), (c))
-
-#define inb(addr) readb(((void __iomem *)(long)(addr)))
-#define inw(addr) readw(((void __iomem *)(long)(addr)))
-#define inl(addr) readl(((void __iomem *)(long)(addr)))
-#define outb(data,addr) writeb(data,((void __iomem *)(long)(addr)))
-#define outw(data,addr) writew(data,((void __iomem *)(long)(addr)))
-#define outl(data,addr) writel(data,((void __iomem *)(long)(addr)))
/*
- * The *_ns versions below don't do byte-swapping.
- * Neither do the standard versions now, these are just here
- * for older code.
+ * __raw_* accessors aren't supported on iSeries so
+ * these used to BUG() on iSeries, but that is not really necessary.
*/
-#define insb(port, buf, ns) _insb((u8 __iomem *)((port)+pci_io_base), (buf), (ns))
-#define insw(port, buf, ns) _insw_ns((u8 __iomem *)((port)+pci_io_base), (buf), (ns))
-#define insl(port, buf, nl) _insl_ns((u8 __iomem *)((port)+pci_io_base), (buf), (nl))
-#define insw_ns(port, buf, ns) _insw_ns((u16 __iomem *)((port)+pci_io_base), (buf), (ns))
-#define insl_ns(port, buf, nl) _insl_ns((u32 __iomem *)((port)+pci_io_base), (buf), (nl))
-#else
-
static inline unsigned char __raw_readb(const volatile void __iomem *addr)
{
return *(volatile unsigned char __force *)addr;
@@ -111,6 +76,7 @@ static inline void __raw_writeq(unsigned
{
*(volatile unsigned long __force *)addr = v;
}
+
#define readb(addr) eeh_readb(addr)
#define readw(addr) eeh_readw(addr)
#define readl(addr) eeh_readl(addr)
@@ -119,9 +85,6 @@ #define writeb(data, addr) eeh_writeb((d
#define writew(data, addr) eeh_writew((data), (addr))
#define writel(data, addr) eeh_writel((data), (addr))
#define writeq(data, addr) eeh_writeq((data), (addr))
-#define memset_io(a,b,c) eeh_memset_io((a),(b),(c))
-#define memcpy_fromio(a,b,c) eeh_memcpy_fromio((a),(b),(c))
-#define memcpy_toio(a,b,c) eeh_memcpy_toio((a),(b),(c))
#define inb(port) eeh_inb((unsigned long)port)
#define outb(val, port) eeh_outb(val, (unsigned long)port)
#define inw(port) eeh_inw((unsigned long)port)
@@ -140,8 +103,6 @@ #define insl(port, buf, nl) eeh_insl_ns(
#define insw_ns(port, buf, ns) eeh_insw_ns((port), (buf), (ns))
#define insl_ns(port, buf, nl) eeh_insl_ns((port), (buf), (nl))
-#endif
-
#define outsb(port, buf, ns) _outsb((u8 __iomem *)((port)+pci_io_base), (buf), (ns))
#define outsw(port, buf, ns) _outsw_ns((u16 __iomem *)((port)+pci_io_base), (buf), (ns))
#define outsl(port, buf, nl) _outsl_ns((u32 __iomem *)((port)+pci_io_base), (buf), (nl))
@@ -399,9 +360,34 @@ static inline void out_be64(volatile uns
__asm__ __volatile__("std%U0%X0 %1,%0; sync" : "=m" (*addr) : "r" (val));
}
-#ifndef CONFIG_PPC_ISERIES
#include <asm/eeh.h>
-#endif
+
+static inline void memset_io(volatile void __iomem *addr, int c,
+ unsigned long n)
+{
+ if (firmware_has_feature(FW_FEATURE_ISERIES))
+ iSeries_memset_io(addr, c, n);
+ else
+ eeh_memset_io(addr, c, n);
+}
+
+static inline void memcpy_fromio(void *dest, const volatile void __iomem *src,
+ unsigned long n)
+{
+ if (firmware_has_feature(FW_FEATURE_ISERIES))
+ iSeries_memcpy_fromio(dest, src, n);
+ else
+ eeh_memcpy_fromio(dest, src, n);
+}
+
+static inline void memcpy_toio(volatile void __iomem *dest, const void *src,
+ unsigned long n)
+{
+ if (firmware_has_feature(FW_FEATURE_ISERIES))
+ iSeries_memcpy_toio(dest, src, n);
+ else
+ eeh_memcpy_toio(dest, src, n);
+}
/**
* check_signature - find BIOS signatures
@@ -417,7 +403,6 @@ static inline int check_signature(const
const unsigned char *signature, int length)
{
int retval = 0;
-#ifndef CONFIG_PPC_ISERIES
do {
if (readb(io_addr) != *signature)
goto out;
@@ -427,7 +412,6 @@ #ifndef CONFIG_PPC_ISERIES
} while (length);
retval = 1;
out:
-#endif
return retval;
}
diff --git a/include/asm-powerpc/iseries/iseries_io.h b/include/asm-powerpc/iseries/iseries_io.h
index f29009b..1b61c51 100644
--- a/include/asm-powerpc/iseries/iseries_io.h
+++ b/include/asm-powerpc/iseries/iseries_io.h
@@ -1,9 +1,5 @@
#ifndef _ASM_POWERPC_ISERIES_ISERIES_IO_H
#define _ASM_POWERPC_ISERIES_ISERIES_IO_H
-
-
-#ifdef CONFIG_PPC_ISERIES
-#include <linux/types.h>
/*
* Created by Allan Trautman on Thu Dec 28 2000.
*
@@ -30,31 +26,12 @@ #include <linux/types.h>
* Created December 28, 2000
* End Change Activity
*/
-
-#ifdef CONFIG_PCI
-extern u8 iSeries_Read_Byte(const volatile void __iomem * IoAddress);
-extern u16 iSeries_Read_Word(const volatile void __iomem * IoAddress);
-extern u32 iSeries_Read_Long(const volatile void __iomem * IoAddress);
-extern void iSeries_Write_Byte(u8 IoData, volatile void __iomem * IoAddress);
-extern void iSeries_Write_Word(u16 IoData, volatile void __iomem * IoAddress);
-extern void iSeries_Write_Long(u32 IoData, volatile void __iomem * IoAddress);
+#include <linux/types.h>
extern void iSeries_memset_io(volatile void __iomem *dest, char x, size_t n);
-extern void iSeries_memcpy_toio(volatile void __iomem *dest, void *source,
+extern void iSeries_memcpy_toio(volatile void __iomem *dest, const void *source,
size_t n);
extern void iSeries_memcpy_fromio(void *dest,
const volatile void __iomem *source, size_t n);
-#else
-static inline u8 iSeries_Read_Byte(const volatile void __iomem *IoAddress)
-{
- return 0xff;
-}
-
-static inline void iSeries_Write_Byte(u8 IoData,
- volatile void __iomem *IoAddress)
-{
-}
-#endif /* CONFIG_PCI */
-#endif /* CONFIG_PPC_ISERIES */
#endif /* _ASM_POWERPC_ISERIES_ISERIES_IO_H */
diff --git a/include/asm-powerpc/ppc-pci.h b/include/asm-powerpc/ppc-pci.h
index cf79bc7..db153ab 100644
--- a/include/asm-powerpc/ppc-pci.h
+++ b/include/asm-powerpc/ppc-pci.h
@@ -51,6 +51,17 @@ extern void pSeries_irq_bus_setup(struct
extern unsigned long pci_probe_only;
+/* From platforms/iseries/pci.c */
+#if defined(CONFIG_PPC_ISERIES) && defined(CONFIG_PCI)
+extern int iseries_handle_io_fault(struct pt_regs *regs, unsigned long address);
+#else
+static inline int iseries_handle_io_fault(struct pt_regs *regs,
+ unsigned long address)
+{
+ return 0;
+}
+#endif
+
/* ---- EEH internal-use-only related routines ---- */
#ifdef CONFIG_EEH
--
1.4.1.1
^ permalink raw reply related
* Re: MAC driver issue
From: Alex Zeffertt @ 2006-09-06 8:25 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <44FE69F2.40409@dlasys.net>
>> FWIW, in my experience the hardware independent parts of the
>> networking stack are
>> very stable and the problem is almost always with the drivers, or with
>> the IP
>> configuration (e.g. two interfaces on the same subnet).
> I have no doubt it is with the driver. I am somewhat fortunate in
> this instance that I have a nearly identical setup - this is an FPGA
> based system
> I can swap the FPGA firmware, get an almost identical kernel with a
> slightly different NIC, and everything works - same cables, same IP's,
> Same switch, The only things different are the NIC and its driver.
> Even the Linux kernels are identical - except the NIC driver.
>
> BUT so is the data received and passed on to the kernel (outside
> random differences in the padding of the ARP packet)
> One works the other doesn't.
>
Well ethernet device drivers contain multiple arp supporting methods,
e.g. header_cache, header_cache_update, hard_header_parse, etc etc.
Generally driver writers don't need to concern themselves about these
as they are assigned to generic handlers by ether_setup(). However,
your problematic driver may do something different.
Given this problem appears to be driver specific rather than PPC
specific your best bet is to try and contact the author. BTW, I don't
think you've said which driver you are using, a key piece of info....
Alex
^ permalink raw reply
* __init() and module_init() serialization of modules?
From: Parav Pandit @ 2006-09-06 8:43 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]
Hi,
My doubt is more related to Linux kernel rather than PPC, but I feel that many will be interested to know this. Please help me to understand a silly doubt.
When we have drivers as kernel modules, it can be loaded using insmod or modprobe.
We use the depmod utility to generate the module dependancy and so concerned module gets loaded first.
This is fine.
Now when in comes to in-build module (part of kernel image), we obviously don't run the modprobe and/or depmod because they are no more modules.
So how does - during compilation time, tool chain can identify which module to load first so that do_initcalls() function can take care if it.
e.g. Module A and Module B.
Both are inbuild, and A uses the functionality of B. So module_init() of B should get called first.
How this is achieved for in-build modules?
__init macro takes care of it for freeing that memory after those calls, but how the sequencing is done?
Regards,
Parav Pandit
---------------------------------
Stay in the know. Pulse on the new Yahoo.com. Check it out.
[-- Attachment #2: Type: text/html, Size: 1400 bytes --]
^ permalink raw reply
* RE: PPC405 system slow boot
From: Clint Thomas @ 2006-09-06 13:28 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2941 bytes --]
Actually, we figured out what was going on. Apparently we left one of
the interrupt lines disconnected from the CPU in the FPGA design. Thanks
for all the help guys, I really do appreciate it.
Clint Thomas
________________________________
From: Clint Thomas
Sent: Friday, September 01, 2006 6:58 PM
To: linuxppc-embedded@ozlabs.org
Cc: 'Peter Ryser '; Jason Lamb
Subject: RE: PPC405 system slow boot
The xparameters.h file is generated by the Xilinx EDK for our FPGA, so I
don't see how there could be a mismatch. Using Chipscope, we were able
to find that the interrupt controller is triggered on kernel
initialization, but after the kernel has finished loading, the system
moves to a snail's pace at login.
Does Linux use a different set of code to handle the UART, INTC, etc.
after the kernel is loaded? The system appears to work perfectly up
until after the kernel is done loading.
________________________________
From: Peter Ryser [mailto:peter.ryser@xilinx.com]
Sent: Monday, August 28, 2006 8:45 PM
To: Clint Thomas
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: PPC405 system slow boot
Clint,
check the interrupt sub-system of your design. What you describe
typically happens when the PPC does not get any interrupts from the
UART. It's most likely a mismatch between your hardware and the
xparameters.h.
- Peter
Clint Thomas wrote:
Hey guys,
I've run through the loops to try and figure what could be wrong
with this system. The board in question is modeled after the Xilinx
ML300 board. It uses a Xilinx System ACE chip to load a FPGA / Kernel
image from compact flash. Originally, I was trying to use the
CompactFlash as the root file system, but because of issues in either
the design or software, this would only work if SysAce was in polled I/O
mode. To circumvent this, I built my root filesystem into an initrd
image and built a single ELF file with the Kernel and RFS, then strapped
that to the FPGA bit file to make a single FPGA/Kernel/RFS SysAce file.
Upon decompression, the Linux kernel boots quickly and loads all
of the device drivers. However when it gets to the prompt, it starts
slowing down. Output and input to and from the board becomes very very
slow (it displays 2 characters roughly every 20 seconds). Originally I
believed this to be the CPU still polling SystemAce, so I disabled the
Linux System ACE drivers to remove that as a possibility, however after
doing this, the problem still persists, even with the RFS in ram! Has
anybody encountered a similar situation to this before, with possible
insight towards a solution? Thank you for your time.
Clinton Thomas
cthomas@soneticom.com
________________________________
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 4666 bytes --]
^ 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