* Re: Patches added to powerpc.git powerpc-next and master branches
From: Paul Mackerras @ 2008-04-15 11:08 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev
In-Reply-To: <20080410.200730.-1300529759.kouish@swc.toshiba.co.jp>
Ishizaki Kou writes:
> Paul-san,
> Could you apply my "take 2" patchset?
There was some discussion about some of them -- did that end up with
Ben accepting that your patches didn't need any changes?
Ben - if so could you ack them for me please?
Paul.
^ permalink raw reply
* Re: Flash on LocalBus @ MPC8343
From: Andre Schwarz @ 2008-04-15 11:53 UTC (permalink / raw)
To: Scott Wood; +Cc: linux-ppc list
In-Reply-To: <20080414164518.GB7061@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]
Scott,
there has been a "compatible=soc" in my of_bus_id[] ...
It was taken from mpc834x_mds some weeks ago.
I changed to :
static struct of_device_id __initdata of_bus_ids[] = {
{ .compatible = "fsl,pq2pro-localbus", },
{},
};
now it works fine.
Thanks !
Andre
Scott Wood schrieb:
> On Sat, Apr 12, 2008 at 10:58:50AM +0200, André Schwarz wrote:
>
>> thanks , but ... can't find "of_bus_ids[]" entry.
>>
>
> That means your platform likely isn't calling of_platform_bus_probe() at
> all. Look at other platforms, such as mpc831x_rdb, for an example.
>
>
>> I'm obviously out of sync. My last git-pull from denx is 3 days old, now
>> - need to update on monday.
>>
>
> For Denx-specific support, please contact Denx.
>
> This certainly isn't something that was added in the past 3 days.
>
> -Scott
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
[-- Attachment #2: Type: text/html, Size: 2001 bytes --]
^ permalink raw reply
* Patches pushed to powerpc.git master and powerpc-next branches
From: Paul Mackerras @ 2008-04-15 12:32 UTC (permalink / raw)
To: linuxppc-dev
I have just pushed the following patches to the master and
powerpc-next branches of the powerpc.git repository, and pulled in
Linus' tree as of 2.6.25-rc9.
Paul.
Dale Farnsworth (5):
[POWERPC] prpmc2800: Fix frequencies in prpmc2800.dts
[POWERPC] mv64x60: Remove device tree absolute path references
[POWERPC] mv643xx_eth: Prepare to support multiple silicon blocks
[POWERPC] Document the mv64x60 device tree bindings
[POWERPC] prpmc2800 needs a dtbImage
David S. Miller (1):
[LMB] Add lmb_alloc_nid()
Mark A. Greer (3):
[POWERPC] prpmc2800: Convert DTS to v1 and add labels
[POWERPC] mv64x60: Fix FDT compatible names: mv64x60 => mv64360
[POWERPC] prpmc2800: Clean up dts properties
Paul Mackerras (3):
[POWERPC] Fix handling of unrecoverable SLB miss interrupts
[LMB] Fix some whitespace and other formatting issues, use pr_debug
[LMB] Restructure allocation loops to avoid unsigned underflow
Stephen Rothwell (6):
[POWERPC] Fix MAX_ORDER config problem
[POWERPC] iSeries: Use alternate paca structure for booting
[POWERPC] iSeries: Make iseries_reg_save private to iSeries
[POWERPC] iSeries: Localise and constify some iSeries data
[POWERPC] remove include of asm/of_device.h from pmi.h
[POWERPC] replace asm/of_device.h with linux/of_device.h in macio.h
^ permalink raw reply
* [RFC] GPIO-based flow control in the cpm_uart driver
From: Laurent Pinchart @ 2008-04-15 13:22 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Brownell
[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]
Hi everybody,
I'm implementing flow control and modem control lines support in the cpm_uart
driver.
The implementation is based on the GPIO lib. Modem control lines are described
in the device tree as GPIO resources and accessed through the OF GPIO
bindings. The I/O ports have to be initialized as GPIOs in the
platform-specific code.
Reading and writing the modem control lines isn't an issue, but activating
hardware flow control is more complex. The driver needs to turn dedicated
functions on and off for the RTS and CTS signals, and the GPIO API doesn't
provide a way to access the PPAR* registers (which does make sense - although
arguably - as PPAR* control specific functions, not GPIOs).
Hardcoding RTS and CTS lines control in the driver is not an option I want to
consider. Extending the GPIO API to handled special functions has been nacked
in the past (see
http://ozlabs.org/pipermail/linuxppc-dev/2008-February/051241.html). An
option would be to export gpio_to_chip from drivers/gpio/gpiolib.c and use
cpm1/2_set_pin in the cpm_uart driver.
Can anyone think of a better solution ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [RFC] Using two baud rate generators with the cpm_uart driver
From: Laurent Pinchart @ 2008-04-15 13:32 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]
Hi everybody,
thanks to a bad hardware design decision, I'm faced with a software issue with
the cpm_uart driver.
My hardware uses either SCC4 or SMC2 (production-time option) as an RS485 port
with an external transceiver. The transceiver's data direction is controlled
by external logic that monitors the SCC4/SMC2 TxD signal.
The external logic needs an input clock at the baud rate frequency on the
MPC8248 BRG5 output pin (although I could modify it to accept an input clock
at 16x the baud rate frequency). This means the cpm_uart driver has to setup
two baud rate generators instead of one.
The ppc architecture was easy to hack as it used a fs_uart_platform_info
structure in which I added a set_brg function pointer provided by platform
code. This isn't possible with the powerpc architecture anymore.
Is there a clean way to fix this issue ? Kicking the hardware designer won't
help :-)
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] GPIO-based flow control in the cpm_uart driver
From: Anton Vorontsov @ 2008-04-15 13:40 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: David Brownell, linuxppc-dev
In-Reply-To: <200804151522.36884.laurentp@cse-semaphore.com>
On Tue, Apr 15, 2008 at 03:22:33PM +0200, Laurent Pinchart wrote:
> Hi everybody,
>
> I'm implementing flow control and modem control lines support in the cpm_uart
> driver.
>
> The implementation is based on the GPIO lib. Modem control lines are described
> in the device tree as GPIO resources and accessed through the OF GPIO
> bindings. The I/O ports have to be initialized as GPIOs in the
> platform-specific code.
>
> Reading and writing the modem control lines isn't an issue, but activating
> hardware flow control is more complex. The driver needs to turn dedicated
> functions on and off for the RTS and CTS signals, and the GPIO API doesn't
> provide a way to access the PPAR* registers (which does make sense - although
> arguably - as PPAR* control specific functions, not GPIOs).
>
> Hardcoding RTS and CTS lines control in the driver is not an option I want to
> consider. Extending the GPIO API to handled special functions has been nacked
> in the past (see
> http://ozlabs.org/pipermail/linuxppc-dev/2008-February/051241.html). An
> option would be to export gpio_to_chip from drivers/gpio/gpiolib.c and use
> cpm1/2_set_pin in the cpm_uart driver.
Since you have successfuly ported QE USB controller onto CPM USB
hardware, now it's obvious that we will need generic gpio_set_dedicated()
function. So I would rather beg David to accept gpio_set_dedicated()
approach instead of exporting gpio_to_chip(). That way we'll kill two
birds with one stone.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [RFC] GPIO-based flow control in the cpm_uart driver
From: Laurent Pinchart @ 2008-04-15 13:47 UTC (permalink / raw)
To: avorontsov; +Cc: David Brownell, linuxppc-dev
In-Reply-To: <20080415134007.GA17096@polina.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 1941 bytes --]
On Tuesday 15 April 2008 15:40, Anton Vorontsov wrote:
> On Tue, Apr 15, 2008 at 03:22:33PM +0200, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > I'm implementing flow control and modem control lines support in the
> > cpm_uart driver.
> >
> > The implementation is based on the GPIO lib. Modem control lines are
> > described in the device tree as GPIO resources and accessed through the OF
> > GPIO bindings. The I/O ports have to be initialized as GPIOs in the
> > platform-specific code.
> >
> > Reading and writing the modem control lines isn't an issue, but activating
> > hardware flow control is more complex. The driver needs to turn dedicated
> > functions on and off for the RTS and CTS signals, and the GPIO API doesn't
> > provide a way to access the PPAR* registers (which does make sense -
> > although arguably - as PPAR* control specific functions, not GPIOs).
> >
> > Hardcoding RTS and CTS lines control in the driver is not an option I want
> > to consider. Extending the GPIO API to handled special functions has been
> > nacked in the past (see
> > http://ozlabs.org/pipermail/linuxppc-dev/2008-February/051241.html). An
> > option would be to export gpio_to_chip from drivers/gpio/gpiolib.c and use
> > cpm1/2_set_pin in the cpm_uart driver.
>
> Since you have successfuly ported QE USB controller onto CPM USB
> hardware, now it's obvious that we will need generic gpio_set_dedicated()
> function. So I would rather beg David to accept gpio_set_dedicated()
> approach instead of exporting gpio_to_chip(). That way we'll kill two
> birds with one stone.
Or maybe some kind of gpio_set_option() with flags specific to the
controller ? This could be used to enable open-drain outputs or internal
pull-ups for instance.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Flash on LocalBus @ MPC8343
From: Scott Wood @ 2008-04-15 14:21 UTC (permalink / raw)
To: Andre Schwarz; +Cc: linux-ppc list
In-Reply-To: <48049754.8010008@matrix-vision.de>
On Tue, Apr 15, 2008 at 01:53:56PM +0200, Andre Schwarz wrote:
> Scott,
>
> there has been a "compatible=soc" in my of_bus_id[] ...
> It was taken from mpc834x_mds some weeks ago.
>
> I changed to :
>
> static struct of_device_id __initdata of_bus_ids[] = {
> { .compatible = "fsl,pq2pro-localbus", },
> {},
> };
Don't get rid of the soc line, though -- both should be present.
-Scott
^ permalink raw reply
* Re: [RFC] GPIO-based flow control in the cpm_uart driver
From: Anton Vorontsov @ 2008-04-15 14:30 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: David Brownell, linuxppc-dev
In-Reply-To: <200804151547.44052.laurentp@cse-semaphore.com>
On Tue, Apr 15, 2008 at 03:47:41PM +0200, Laurent Pinchart wrote:
> On Tuesday 15 April 2008 15:40, Anton Vorontsov wrote:
> > On Tue, Apr 15, 2008 at 03:22:33PM +0200, Laurent Pinchart wrote:
> > > Hi everybody,
> > >
> > > I'm implementing flow control and modem control lines support in the
> > > cpm_uart driver.
> > >
> > > The implementation is based on the GPIO lib. Modem control lines are
> > > described in the device tree as GPIO resources and accessed through the OF
> > > GPIO bindings. The I/O ports have to be initialized as GPIOs in the
> > > platform-specific code.
> > >
> > > Reading and writing the modem control lines isn't an issue, but activating
> > > hardware flow control is more complex. The driver needs to turn dedicated
> > > functions on and off for the RTS and CTS signals, and the GPIO API doesn't
> > > provide a way to access the PPAR* registers (which does make sense -
> > > although arguably - as PPAR* control specific functions, not GPIOs).
> > >
> > > Hardcoding RTS and CTS lines control in the driver is not an option I want
> > > to consider. Extending the GPIO API to handled special functions has been
> > > nacked in the past (see
> > > http://ozlabs.org/pipermail/linuxppc-dev/2008-February/051241.html). An
> > > option would be to export gpio_to_chip from drivers/gpio/gpiolib.c and use
> > > cpm1/2_set_pin in the cpm_uart driver.
> >
> > Since you have successfuly ported QE USB controller onto CPM USB
> > hardware, now it's obvious that we will need generic gpio_set_dedicated()
> > function. So I would rather beg David to accept gpio_set_dedicated()
> > approach instead of exporting gpio_to_chip(). That way we'll kill two
> > birds with one stone.
>
> Or maybe some kind of gpio_set_option() with flags specific to the
> controller ? This could be used to enable open-drain outputs or internal
> pull-ups for instance.
Yes, probably this name. The purpose will be the same anyway. ;-)
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 03/12] [POWERPC] Remove and replace uses of PPC_MEMSTART with memstart_addr
From: Kumar Gala @ 2008-04-15 14:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18436.23196.673130.542635@cargo.ozlabs.ibm.com>
On Apr 15, 2008, at 2:34 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> +phys_addr_t memstart_addr;
>> +EXPORT_SYMBOL(memstart_addr);
>
> Do you have a modular user of memstart_addr in mind?
I believe its needed for the CONFIG_RELOCATE build, but I can double
check that.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] Make Book-E debug handling SMP safe
From: Kumar Gala @ 2008-04-15 14:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18436.12968.728788.841679@cargo.ozlabs.ibm.com>
On Apr 14, 2008, at 11:44 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> global_dbcr0 needs to be a per cpu set of save areas instead of a
>> single
>> global on all processors.
>
> Looks reasonable. At some point you might want to use a per-cpu
> variable instead of an array in order to reduce cacheline bouncing.
Can you point me at an example of this. Do we do any asm access with
per-cpu variables anywhere today?
>> Also, we switch to using DBCR0_IDM to determine if the user space
>> app is
>> being debugged as its a more consistent way. In the future we should
>> support features like hardware breakpoint and watchpoints which will
>> have DBCR0_IDM set but not necessarily DBCR0_IC (single step).
>
> That should be OK.
Ok. I'll put it my powerpc-next tree.
- k
^ permalink raw reply
* [PATCH] LLTEMAC resource end address
From: Hugo Villeneuve @ 2008-04-15 13:57 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
We have a design with LLTEMAC0 using channels 0 & 1, and LLTEMAC1 using =
channel 0. When the Linux kernel boots, we had the following error =
message:
---
Registering device xilinx_lltemac:0
Registering device xilinx_lltemac:1
xilinx_lltemac.1: failed to claim resource 0
cannot register dev xilinx_lltemac:1
Registering device xilinx_lltemac:2
---
We found out that the two channels of a LLTEMAC interface are each using =
0x40 bytes in length, and are contiguous. The following patch took care =
of the problem for us (against the linux-2.6-xlnx-git tree):
---
diff --git a/arch/ppc/syslib/virtex_devices.c =
b/arch/ppc/syslib/virtex_devices.c
index 457e1bd..7f731e4 100644
--- a/arch/ppc/syslib/virtex_devices.c
+++ b/arch/ppc/syslib/virtex_devices.c
@@ -202,7 +202,7 @@
.resource =3D (struct resource[]) { \
{ \
.start =3D XPAR_LLTEMAC_##num##_BASEADDR, \
- .end =3D XPAR_LLTEMAC_##num##_BASEADDR + 0x1000, =
\
+ .end =3D XPAR_LLTEMAC_##num##_BASEADDR + 0x003F, =
\
.flags =3D IORESOURCE_MEM \
}, \
{ \
---
Hugo V.
Hugo Villeneuve
Hardware developer | Concepteur mat=E9riel
Lyrtech
Phone/T=E9l. : (1) (418) 877-4644 #2395
Toll-free/Sans frais - Canada & USA : (1) (888) 922-4644 #2395
Fax/T=E9l=E9c. : (1) (418) 877-7710
www.lyrtech.com
Infinite possibilities...TM
THIS MESSAGE AND ALL ATTACHED DOCUMENTS ARE EXCLUSIVELY INTENDED
TO THE INDICATED RECIPIENTS AND ITS CONTENTS MAY BE CONFIDENTIAL.
IT IS STRICTLY FORBIDDEN TO ANYONE TO TAKE COGNIZANCE, USE, OR
DIVULGE THE INFORMATION CONTAINED HEREIN. IF YOU MISTAKENLY
RECEIVE THIS MESSAGE, IMMEDIATELY INFORM LYRTECH AND DESTROY THE
MESSAGE AND ATTACHMENTS FORTHWITH.THANK YOU.
LE PRESENT MESSAGE ET LES DOCUMENTS QUI Y SONT JOINTS S'ADRESSENT
EXCLUSIVEMENT AU(X)DESTINATAIRE(S) INDIQUE(S) ET LEUR TENEUR PEUT
ETRE CONFIDENTIELLE. IL EST STRICTEMENT INTERDIT A QUICONQUE D'EN
PRENDRE CONNAISSANCE, DE LES UTILISER OU DE LES DIVULGUER. SI
VOUS RECEVEZ LE PRESENT MESSAGE PAR ERREUR, VEUILLEZ EN AVISER
LYRTECH IMMEDIATEMENT ET DETRUIRE LE MESSAGE SEANCE TENANTE,
AINSI QUE LES DOCUMENTS QUI Y SONT JOINTS.
^ permalink raw reply related
* Re: [PATCH 03/12] [POWERPC] Remove and replace uses of PPC_MEMSTART with memstart_addr
From: Kumar Gala @ 2008-04-15 14:51 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <EE972833-6928-4ECC-B257-432DFD947627@kernel.crashing.org>
On Apr 15, 2008, at 9:35 AM, Kumar Gala wrote:
>
> On Apr 15, 2008, at 2:34 AM, Paul Mackerras wrote:
>> Kumar Gala writes:
>>
>>> +phys_addr_t memstart_addr;
>>> +EXPORT_SYMBOL(memstart_addr);
>>
>> Do you have a modular user of memstart_addr in mind?
>
> I believe its needed for the CONFIG_RELOCATE build, but I can double
> check that.
I've removed it from this patch and will add it back to the 85xx: add
reloc patch if needed.
- k
^ permalink raw reply
* Re: [PATCH 09/12] [POWERPC] Move phys_addr_t definition into asm/types.h
From: Kumar Gala @ 2008-04-15 14:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18436.32670.670138.323139@cargo.ozlabs.ibm.com>
On Apr 15, 2008, at 5:12 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Moved phys_addr_t out of mmu-*.h and into asm/types.h so we can use
>> it in
>> places that before would have caused recursive includes.
>
> ...
>
>> diff --git a/include/asm-powerpc/types.h b/include/asm-powerpc/
>> types.h
>> index 903fd19..d853cf0 100644
>> --- a/include/asm-powerpc/types.h
>> +++ b/include/asm-powerpc/types.h
>> @@ -50,6 +50,13 @@ typedef struct {
>> __u32 u[4];
>> } __attribute__((aligned(16))) __vector128;
>>
>> +/* Physical address used by some IO functions */
>> +#if defined(CONFIG_PPC64) || defined(CONFIG_PHYS_64BIT)
>> +typedef __u64 phys_addr_t;
>> +#else
>> +typedef __u32 phys_addr_t;
>> +#endif
>
> That appears to be being added in the part of that file that is
> visible to userspace, which isn't a good idea, since phys_addr_t is
> not something we want to export to userspace.
>
> I can fix up the patch when I apply it if you like.
I'll fixup and repost the series.
- k
^ permalink raw reply
* Re: [PATCH 12/12] [POWERPC] 85xx: Add support for relocatble kernel (and booting at non-zero)
From: Kumar Gala @ 2008-04-15 15:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18436.35348.316368.332336@cargo.ozlabs.ibm.com>
On Apr 15, 2008, at 5:57 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Added support to allow an 85xx kernel to be run from a non-zero
>> physical
>> address (useful for cooperative asymmetric multiprocessing
>> situations) and
>> kdump. The support can either be at compile time or runtime
>> (CONFIG_RELOCATABLE).
>>
>> Currently we are limited to running at a physical address that is
>> module
>> 256M. This is due to how we map TLBs to cover lowmem and should be
>> fixed
>> up to allow 64M or maybe even 16M alignment in the future.
>
> The first 11 patches look pretty reasonable, but I think I want a bit
> more time to digest this one. At the least it needs a bit more
> description, saying for instance why you remove USER_PGD_PTRS and
> KERNEL_PGD_PTRS (yes they are unused now but why does this patch need
> to remove them?).
No reason. I'll separate their removal into their own patch.
> Also, given that we changed from using a
> PPC_MEMSTART #define to a memstart_addr variable earlier in the patch
> series, why do we need to change back to a #define (MEMORY_START) now?
I re-introduced it because I wanted ARCH_PFN_OFFSET to be a compile
time define if !CONFIG_RELOCATABLE
I can easily move the ARCH_PFN_OFFSET define inside the
CONFIG_RELOCATABLE ifdef.
> I take it that with CONFIG_RELOCATABLE set, the kernel won't touch any
> RAM below the point where it's loaded?
that's correct.
> Is CONFIG_PHYSICAL_START used
> at all if CONFIG_RELOCATABLE is set, and if so what does it mean?
its not used for anything but as a 'hint' for setting the physical
address of the PHDR.
> What happens if CONFIG_KERNEL_START != CONFIG_PAGE_OFFSET and the
> kernel is loaded at some address != CONFIG_PHYSICAL_START?
> Are we sure that ARCH_PFN_OFFSET only gets applied to normal memory
> pages, not any I/O? What happens to /dev/mem when ARCH_PFN_OFFSET !=
> 0?
I need to think on these two.
> Also, since you're changing pmd_page(), it would be better to make it
> use pfn_to_page or something similar rather than using mem_map + xxx.
I'll change it to:
pfn_to_page(__pa(pmd_val(pmd)) >> PAGE_SHIFT)
(I'll move this into a cleanup patch with the removal of USER_PGD_PTRS
and KERNEL_PGD_PTRS)
- k
^ permalink raw reply
* fec_mpc5200: reset FEC on error
From: Robert Schwebel @ 2008-04-15 15:26 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Domen Puncer
From: Sascha Hauer <s.hauer@pengutronix.de>
The error handling for the mpc5200 fec interrupt is broken. The intended
behaviour is like this:
* If one of FEC_IEVENT_RFIFO_ERROR and FEC_IEVENT_XFIFO_ERROR happens,
the datasheet says (MPC5200B User's Guide R1.2, p. 14-13): "When this
occurs, software must ensure both the FIFO Controller and BestComm are
soft-reset".
* On any other error (non-TFINT) interrupt, just issue a debug message.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/net/fec_mpc52xx.c | 23 +++++++++++++----------
1 file changed, 13 insertions(+), 10 deletions(-)
Index: drivers/net/fec_mpc52xx.c
===================================================================
--- drivers/net/fec_mpc52xx.c.orig
+++ drivers/net/fec_mpc52xx.c
@@ -491,20 +491,23 @@
out_be32(&fec->ievent, ievent); /* clear pending events */
- if (ievent & ~(FEC_IEVENT_RFIFO_ERROR | FEC_IEVENT_XFIFO_ERROR)) {
- if (ievent & ~FEC_IEVENT_TFINT)
- dev_dbg(&dev->dev, "ievent: %08x\n", ievent);
+ /* on fifo error, soft-reset fec */
+ if (ievent & (FEC_IEVENT_RFIFO_ERROR | FEC_IEVENT_XFIFO_ERROR)) {
+
+ if (net_ratelimit() && (ievent & FEC_IEVENT_RFIFO_ERROR))
+ dev_warn(&dev->dev, "FEC_IEVENT_RFIFO_ERROR\n");
+ if (net_ratelimit() && (ievent & FEC_IEVENT_XFIFO_ERROR))
+ dev_warn(&dev->dev, "FEC_IEVENT_XFIFO_ERROR\n");
+
+ mpc52xx_fec_reset(dev);
+
+ netif_wake_queue(dev);
return IRQ_HANDLED;
}
- if (net_ratelimit() && (ievent & FEC_IEVENT_RFIFO_ERROR))
- dev_warn(&dev->dev, "FEC_IEVENT_RFIFO_ERROR\n");
- if (net_ratelimit() && (ievent & FEC_IEVENT_XFIFO_ERROR))
- dev_warn(&dev->dev, "FEC_IEVENT_XFIFO_ERROR\n");
-
- mpc52xx_fec_reset(dev);
+ if (ievent & ~FEC_IEVENT_TFINT)
+ dev_dbg(&dev->dev, "ievent: %08x\n", ievent);
- netif_wake_queue(dev);
return IRQ_HANDLED;
}
^ permalink raw reply
* Re: fec_mpc5200: reset FEC on error
From: Kumar Gala @ 2008-04-15 15:29 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linuxppc-dev, Domen Puncer
In-Reply-To: <20080415152638.GW13814@pengutronix.de>
On Apr 15, 2008, at 10:26 AM, Robert Schwebel wrote:
> From: Sascha Hauer <s.hauer@pengutronix.de>
>
> The error handling for the mpc5200 fec interrupt is broken. The
> intended
> behaviour is like this:
>
> * If one of FEC_IEVENT_RFIFO_ERROR and FEC_IEVENT_XFIFO_ERROR happens,
> the datasheet says (MPC5200B User's Guide R1.2, p. 14-13): "When this
> occurs, software must ensure both the FIFO Controller and BestComm
> are
> soft-reset".
>
> * On any other error (non-TFINT) interrupt, just issue a debug
> message.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>
> ---
> drivers/net/fec_mpc52xx.c | 23 +++++++++++++----------
> 1 file changed, 13 insertions(+), 10 deletions(-)
>
You really need to also copy netdev and patches to drivers/net.
- k
^ permalink raw reply
* mpc5200: add interrupt type function
From: Robert Schwebel @ 2008-04-15 15:29 UTC (permalink / raw)
To: linuxppc-dev
From: Sascha Hauer <s.hauer@pengutronix.de>
Add a set_type function for external (GPIO) interrupts.
Signed-off-by: Juergen Beisert <j.beisert@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 38 ++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
Index: arch/powerpc/platforms/52xx/mpc52xx_pic.c
===================================================================
--- a/arch/powerpc/platforms/52xx/mpc52xx_pic.c.orig 2008-04-15 11:25:29.000000000 +0200
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pic.c 2008-04-15 11:25:39.000000000 +0200
@@ -18,6 +18,7 @@
#undef DEBUG
+#include <linux/interrupt.h>
#include <linux/irq.h>
#include <linux/of.h>
#include <asm/io.h>
@@ -109,11 +110,48 @@
io_be_setbit(&intr->ctrl, 27-l2irq);
}
+static int mpc52xx_extirq_set_type(unsigned int virq, unsigned int flow_type)
+{
+ u32 ctrl_reg, type;
+ int irq;
+ int l2irq;
+
+ irq = irq_map[virq].hwirq;
+ l2irq = (irq & MPC52xx_IRQ_L2_MASK) >> MPC52xx_IRQ_L2_OFFSET;
+
+ pr_debug("%s: irq=%x. l2=%d flow_type=%d\n", __func__, irq, l2irq, flow_type);
+
+ switch (flow_type) {
+ case IRQF_TRIGGER_HIGH:
+ type = 0;
+ break;
+ case IRQF_TRIGGER_RISING:
+ type = 1;
+ break;
+ case IRQF_TRIGGER_FALLING:
+ type = 2;
+ break;
+ case IRQF_TRIGGER_LOW:
+ type = 3;
+ break;
+ default:
+ type = 0;
+ }
+
+ ctrl_reg = in_be32(&intr->ctrl);
+ ctrl_reg &= ~(0x3 << (22 - (l2irq * 2)));
+ ctrl_reg |= (type << (22 - (l2irq * 2)));
+ out_be32(&intr->ctrl, ctrl_reg);
+
+ return 0;
+}
+
static struct irq_chip mpc52xx_extirq_irqchip = {
.typename = " MPC52xx IRQ[0-3] ",
.mask = mpc52xx_extirq_mask,
.unmask = mpc52xx_extirq_unmask,
.ack = mpc52xx_extirq_ack,
+ .set_type = mpc52xx_extirq_set_type,
};
/*
^ permalink raw reply
* Please pull 'for-2.6.26' branch of 4xx tree
From: Josh Boyer @ 2008-04-15 15:27 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.26
to pick up some additional patches for 4xx. This contains the
defconfig reorg, some EMAC patches from Valentine that have been
outstanding for a while, and a new idle loop patch.
josh
Jerone Young (1):
[POWERPC] 4xx: Add idle wait support for 44x platforms
Josh Boyer (2):
[POWERPC] 4xx: Reorganize 4xx defconfigs
[POWERPC] 4xx: Add ppc40x_defconfig
Valentine Barshak (2):
[POWERPC] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround
[POWERPC] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround
arch/powerpc/configs/{ => 40x}/ep405_defconfig | 0
arch/powerpc/configs/{ => 40x}/kilauea_defconfig | 0
arch/powerpc/configs/{ => 40x}/makalu_defconfig | 0
arch/powerpc/configs/{ => 40x}/walnut_defconfig | 0
arch/powerpc/configs/{ => 44x}/bamboo_defconfig | 0
.../configs/{ => 44x}/canyonlands_defconfig | 0
arch/powerpc/configs/{ => 44x}/ebony_defconfig | 0
arch/powerpc/configs/{ => 44x}/katmai_defconfig | 0
arch/powerpc/configs/{ => 44x}/rainier_defconfig | 0
arch/powerpc/configs/{ => 44x}/sequoia_defconfig | 0
arch/powerpc/configs/{ => 44x}/taishan_defconfig | 0
arch/powerpc/configs/{ => 44x}/warp_defconfig | 0
.../configs/{walnut_defconfig => ppc40x_defconfig} | 31 ++++++---
arch/powerpc/platforms/44x/Makefile | 2 +-
arch/powerpc/platforms/44x/idle.c | 67 ++++++++++++++++++++
drivers/net/ibm_newemac/core.c | 48 +++++++++++++-
drivers/net/ibm_newemac/core.h | 14 +++-
17 files changed, 145 insertions(+), 17 deletions(-)
rename arch/powerpc/configs/{ => 40x}/ep405_defconfig (100%)
rename arch/powerpc/configs/{ => 40x}/kilauea_defconfig (100%)
rename arch/powerpc/configs/{ => 40x}/makalu_defconfig (100%)
copy arch/powerpc/configs/{ => 40x}/walnut_defconfig (100%)
rename arch/powerpc/configs/{ => 44x}/bamboo_defconfig (100%)
rename arch/powerpc/configs/{ => 44x}/canyonlands_defconfig (100%)
rename arch/powerpc/configs/{ => 44x}/ebony_defconfig (100%)
rename arch/powerpc/configs/{ => 44x}/katmai_defconfig (100%)
rename arch/powerpc/configs/{ => 44x}/rainier_defconfig (100%)
rename arch/powerpc/configs/{ => 44x}/sequoia_defconfig (100%)
rename arch/powerpc/configs/{ => 44x}/taishan_defconfig (100%)
rename arch/powerpc/configs/{ => 44x}/warp_defconfig (100%)
rename arch/powerpc/configs/{walnut_defconfig => ppc40x_defconfig} (97%)
create mode 100644 arch/powerpc/platforms/44x/idle.c
^ permalink raw reply
* Re: fec_mpc5200: reset FEC on error
From: Robert Schwebel @ 2008-04-15 15:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Domen Puncer
In-Reply-To: <F7AFD26F-39FE-4C1F-8918-F799F65F9559@kernel.crashing.org>
On Tue, Apr 15, 2008 at 10:29:26AM -0500, Kumar Gala wrote:
> You really need to also copy netdev and patches to drivers/net.
Hm? Sorry, don't understand what you mean.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [RFC] Using two baud rate generators with the cpm_uart driver
From: Scott Wood @ 2008-04-15 15:34 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200804151532.27057.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
> thanks to a bad hardware design decision, I'm faced with a software issue with
> the cpm_uart driver.
>
> My hardware uses either SCC4 or SMC2 (production-time option) as an RS485 port
> with an external transceiver. The transceiver's data direction is controlled
> by external logic that monitors the SCC4/SMC2 TxD signal.
>
> The external logic needs an input clock at the baud rate frequency on the
> MPC8248 BRG5 output pin (although I could modify it to accept an input clock
> at 16x the baud rate frequency). This means the cpm_uart driver has to setup
> two baud rate generators instead of one.
>
> The ppc architecture was easy to hack as it used a fs_uart_platform_info
> structure in which I added a set_brg function pointer provided by platform
> code. This isn't possible with the powerpc architecture anymore.
>
> Is there a clean way to fix this issue ? Kicking the hardware designer won't
> help :-)
Maybe not, but it'd be satisfying. :-)
The clean solution would be to have an abstracted clock API, similar to
phylib, where the caller doesn't know details about BRGs and such.
Maybe the linux/clk.h API would be suitable; I haven't looked at it in
detail.
-Scott
^ permalink raw reply
* fec_mpc5200: reset FEC on error
From: Robert Schwebel @ 2008-04-15 15:44 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, Domen Puncer
In-Reply-To: <20080415152638.GW13814@pengutronix.de>
From: Sascha Hauer <s.hauer@pengutronix.de>
The error handling for the mpc5200 fec interrupt is broken. The intended
behaviour is like this:
* If one of FEC_IEVENT_RFIFO_ERROR and FEC_IEVENT_XFIFO_ERROR happens,
the datasheet says (MPC5200B User's Guide R1.2, p. 14-13): "When this
occurs, software must ensure both the FIFO Controller and BestComm are
soft-reset".
* On any other error (non-TFINT) interrupt, just issue a debug message.
v2 changed to -p1 and posted on linuxppc list (2008-04-15).
v1 posted on linuxppc list (2008-04-15).
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/net/fec_mpc52xx.c | 23 +++++++++++++----------
1 file changed, 13 insertions(+), 10 deletions(-)
Index: drivers/net/fec_mpc52xx.c
===================================================================
--- a/drivers/net/fec_mpc52xx.c.orig
+++ b/drivers/net/fec_mpc52xx.c
@@ -491,20 +491,23 @@
out_be32(&fec->ievent, ievent); /* clear pending events */
- if (ievent & ~(FEC_IEVENT_RFIFO_ERROR | FEC_IEVENT_XFIFO_ERROR)) {
- if (ievent & ~FEC_IEVENT_TFINT)
- dev_dbg(&dev->dev, "ievent: %08x\n", ievent);
+ /* on fifo error, soft-reset fec */
+ if (ievent & (FEC_IEVENT_RFIFO_ERROR | FEC_IEVENT_XFIFO_ERROR)) {
+
+ if (net_ratelimit() && (ievent & FEC_IEVENT_RFIFO_ERROR))
+ dev_warn(&dev->dev, "FEC_IEVENT_RFIFO_ERROR\n");
+ if (net_ratelimit() && (ievent & FEC_IEVENT_XFIFO_ERROR))
+ dev_warn(&dev->dev, "FEC_IEVENT_XFIFO_ERROR\n");
+
+ mpc52xx_fec_reset(dev);
+
+ netif_wake_queue(dev);
return IRQ_HANDLED;
}
- if (net_ratelimit() && (ievent & FEC_IEVENT_RFIFO_ERROR))
- dev_warn(&dev->dev, "FEC_IEVENT_RFIFO_ERROR\n");
- if (net_ratelimit() && (ievent & FEC_IEVENT_XFIFO_ERROR))
- dev_warn(&dev->dev, "FEC_IEVENT_XFIFO_ERROR\n");
-
- mpc52xx_fec_reset(dev);
+ if (ievent & ~FEC_IEVENT_TFINT)
+ dev_dbg(&dev->dev, "ievent: %08x\n", ievent);
- netif_wake_queue(dev);
return IRQ_HANDLED;
}
^ permalink raw reply
* Re: Signal backtrace function
From: Detlev Zundel @ 2008-04-15 15:50 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-dev
In-Reply-To: <1208190010.5911.15.camel@gentoo-jocke.transmode.se>
Hi Jocke,
> On Mon, 2008-04-14 at 18:09 +0200, Detlev Zundel wrote:
>> Hi Jocke,
>>
>> > I made my own backtrace function for printing
>> > a trace from within a signal handler. Maybe it
>> > can be useful for the kernel too? General
>> > comments welcome.
>>
>> Probably a dumb question, but doesn't backtrace(3) from glibc work
>> architecture independent already? Why do you need to reimplement it?
>
> Nope, it doesn't give you a good backtrace from within a signal handler.
> On x86 you can use the normal backtrace function with a minor
> workaround, but as ppc doesn't save a FP in leaf functions, that
> workaround does not work well. You can read more about it
> at http://www.linuxjournal.com/article/6391
Thanks for clearing that up. I wasn't aware of that limitation.
Cheers
Detlev
--
In short: much of our country's [USA] counterterrorism security spending is
not designed to protect us from the terrorists, but instead to protect our
public officials from criticism when another attack occurs.
-- Bruce Schneier
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: [RFC] Using two baud rate generators with the cpm_uart driver
From: Laurent Pinchart @ 2008-04-15 15:54 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <4804CB12.1000308@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]
Hi Scott,
On Tuesday 15 April 2008 17:34, Scott Wood wrote:
> Laurent Pinchart wrote:
> > thanks to a bad hardware design decision, I'm faced with a software issue
> > with the cpm_uart driver.
> >
> > My hardware uses either SCC4 or SMC2 (production-time option) as an RS485
> > port with an external transceiver. The transceiver's data direction is
> > controlled by external logic that monitors the SCC4/SMC2 TxD signal.
> >
> > The external logic needs an input clock at the baud rate frequency on the
> > MPC8248 BRG5 output pin (although I could modify it to accept an input
> > clock at 16x the baud rate frequency). This means the cpm_uart driver has
> > to setup two baud rate generators instead of one.
> >
> > The ppc architecture was easy to hack as it used a fs_uart_platform_info
> > structure in which I added a set_brg function pointer provided by platform
> > code. This isn't possible with the powerpc architecture anymore.
> >
> > Is there a clean way to fix this issue ? Kicking the hardware designer
> > won't help :-)
>
> Maybe not, but it'd be satisfying. :-)
Don't tempt me :-)
> The clean solution would be to have an abstracted clock API, similar to
> phylib, where the caller doesn't know details about BRGs and such.
> Maybe the linux/clk.h API would be suitable; I haven't looked at it in
> detail.
The clock API would have to be quite advanced to express things like "the SCC4
clock is a combination of BRG2 and BRG5" (and I don't even consider
adding "with BRG2 set to 16x the baud rate and BRG5 to the baud rate").
I'm not even sure a generic API should be developed to solve my problem. I'm
more looking for a not too dirty hack.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Using two baud rate generators with the cpm_uart driver
From: Scott Wood @ 2008-04-15 15:59 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200804151754.21664.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
>> The clean solution would be to have an abstracted clock API, similar to
>> phylib, where the caller doesn't know details about BRGs and such.
>> Maybe the linux/clk.h API would be suitable; I haven't looked at it in
>> detail.
>
> The clock API would have to be quite advanced to express things like "the SCC4
> clock is a combination of BRG2 and BRG5" (and I don't even consider
> adding "with BRG2 set to 16x the baud rate and BRG5 to the baud rate").
What I was picturing was platform code providing a clock object that the
cpm_uart driver could be pointed at (possibly by modifying the device
tree in platform init); the knowledge of the multiple BRG weirdness
would be contained in platform code.
-Scott
^ 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