* Re: [PATCH 2/3] [POWERPC] Add docs for Freescale RapidIO device tree node
From: Scott Wood @ 2007-11-21 17:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711202313350.24220@blarg.am.freescale.net>
On Tue, Nov 20, 2007 at 11:13:58PM -0600, Kumar Gala wrote:
> Required properties:
> - compatible : compatible list, contains 2 entries, first is
> - "fsl,sata-CHIP", where CHIP is the processor
> + "fsl,CHIP-sata", where CHIP is the processor
> (mpc8315, mpc8379, etc.) and the second is
> - "fsl,sata-pq2pro"
> + "fsl,pq2pro-sata"
> - interrupts : <interrupt mapping for SATA IRQ>
> - interrupt-parent : optional, if needed for interrupt mapping
> - reg : <registers mapping>
> @@ -2531,12 +2531,53 @@ platforms are moved over to use the flattened-device-tree model.
> Example:
>
> sata@19000 {
> - compatible = "fsl,mpc8315-sata", "fsl,sata-pq2pro;
> + compatible = "fsl,mpc8315-sata", "fsl,pq2pro-sata;
I think you meant to merge these changes with the previous patch...
-Scott
^ permalink raw reply
* Re: Firmware Support for USB Hub
From: Scott Wood @ 2007-11-21 17:20 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <13877282.post@talk.nabble.com>
Misbah khan wrote:
> Hi all,
>
> I am using a 8248 processor which has a USB controller and i need to connect
> a USB Hub to it, iam using Montavista Linux .I need to know that what are
> the support i need form Montavista or Open source to have an interface with
> Usb hub. ???
>
> Is there any driver that we need to make if so what type ???
I don't believe a driver currently exists for CPM USB.
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Geert Uytterhoeven @ 2007-11-21 16:50 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <7D40FA9E-A972-4995-85AE-3CE2551BB195@kernel.crashing.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1328 bytes --]
On Wed, 21 Nov 2007, Kumar Gala wrote:
> On Nov 21, 2007, at 7:09 AM, Geert Uytterhoeven wrote:
> > On Tue, 20 Nov 2007, Kumar Gala wrote:
> > > On Nov 20, 2007, at 11:54 AM, Scott Wood wrote:
> > > > Given that the instruction is meant to be a performance enhancement,
> > > > we should probably warn the first few times it's emulated, so the user
> > > > knows they should change their toolchain setup if possible.
> > >
> > > The same is true of mcrxr, popcntb, and possibly string ld/st.
> > >
> > > Feel free to submit a patch that warns about their usage.
>
> How about some per processor counters in sysfs under the processor.
Per processor? That means it has to be per_cpu, which sounds a bit like
overkill to me.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* [PATCH 2/2][2.6.24] ehea: Reworked rcv queue handling to log only fatal errors
From: Thomas Klein @ 2007-11-21 16:42 UTC (permalink / raw)
To: Jeff Garzik
Cc: Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
Prevent driver from brawly logging packet checksum errors.
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
drivers/net/ehea/ehea.h | 2 +-
drivers/net/ehea/ehea_main.c | 11 +++++------
drivers/net/ehea/ehea_qmr.h | 4 ++--
3 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 5935899..ea67615 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0082"
+#define DRV_VERSION "EHEA_0083"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index d2f715d..869e160 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -410,11 +410,6 @@ static int ehea_treat_poll_error(struct ehea_port_res *pr, int rq,
if (cqe->status & EHEA_CQE_STAT_ERR_CRC)
pr->p_stats.err_frame_crc++;
- if (netif_msg_rx_err(pr->port)) {
- ehea_error("CQE Error for QP %d", pr->qp->init_attr.qp_nr);
- ehea_dump(cqe, sizeof(*cqe), "CQE");
- }
-
if (rq == 2) {
*processed_rq2 += 1;
skb = get_skb_by_index(pr->rq2_skba.arr, pr->rq2_skba.len, cqe);
@@ -426,7 +421,11 @@ static int ehea_treat_poll_error(struct ehea_port_res *pr, int rq,
}
if (cqe->status & EHEA_CQE_STAT_FAT_ERR_MASK) {
- ehea_error("Critical receive error. Resetting port.");
+ if (netif_msg_rx_err(pr->port)) {
+ ehea_error("Critical receive error for QP %d. "
+ "Resetting port.", pr->qp->init_attr.qp_nr);
+ ehea_dump(cqe, sizeof(*cqe), "CQE");
+ }
schedule_work(&pr->port->reset_task);
return 1;
}
diff --git a/drivers/net/ehea/ehea_qmr.h b/drivers/net/ehea/ehea_qmr.h
index 562de0e..bc62d38 100644
--- a/drivers/net/ehea/ehea_qmr.h
+++ b/drivers/net/ehea/ehea_qmr.h
@@ -145,8 +145,8 @@ struct ehea_rwqe {
#define EHEA_CQE_VLAN_TAG_XTRACT 0x0400
#define EHEA_CQE_TYPE_RQ 0x60
-#define EHEA_CQE_STAT_ERR_MASK 0x720F
-#define EHEA_CQE_STAT_FAT_ERR_MASK 0x1F
+#define EHEA_CQE_STAT_ERR_MASK 0x700F
+#define EHEA_CQE_STAT_FAT_ERR_MASK 0xF
#define EHEA_CQE_STAT_ERR_TCP 0x4000
#define EHEA_CQE_STAT_ERR_IP 0x2000
#define EHEA_CQE_STAT_ERR_CRC 0x1000
--
1.5.2
^ permalink raw reply related
* [PATCH 1/2][2.6.24] ehea: Improve tx packets counting
From: Thomas Klein @ 2007-11-21 16:37 UTC (permalink / raw)
To: Jeff Garzik
Cc: Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
Using own tx_packets counter instead of firmware counters.
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
drivers/net/ehea/ehea.h | 2 +-
drivers/net/ehea/ehea_main.c | 9 +++++++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index f78e5bf..5935899 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0080"
+#define DRV_VERSION "EHEA_0082"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index f0319f1..d2f715d 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -136,7 +136,7 @@ static struct net_device_stats *ehea_get_stats(struct net_device *dev)
struct ehea_port *port = netdev_priv(dev);
struct net_device_stats *stats = &port->stats;
struct hcp_ehea_port_cb2 *cb2;
- u64 hret, rx_packets;
+ u64 hret, rx_packets, tx_packets;
int i;
memset(stats, 0, sizeof(*stats));
@@ -162,7 +162,11 @@ static struct net_device_stats *ehea_get_stats(struct net_device *dev)
for (i = 0; i < port->num_def_qps; i++)
rx_packets += port->port_res[i].rx_packets;
- stats->tx_packets = cb2->txucp + cb2->txmcp + cb2->txbcp;
+ tx_packets = 0;
+ for (i = 0; i < port->num_def_qps + port->num_add_tx_qps; i++)
+ tx_packets += port->port_res[i].tx_packets;
+
+ stats->tx_packets = tx_packets;
stats->multicast = cb2->rxmcp;
stats->rx_errors = cb2->rxuerr;
stats->rx_bytes = cb2->rxo;
@@ -2000,6 +2004,7 @@ static int ehea_start_xmit(struct sk_buff *skb, struct net_device *dev)
}
ehea_post_swqe(pr->qp, swqe);
+ pr->tx_packets++;
if (unlikely(atomic_read(&pr->swqe_avail) <= 1)) {
spin_lock_irqsave(&pr->netif_queue, flags);
--
1.5.2
^ permalink raw reply related
* Re: [PATCH 1/8] ibm_newemac: Fix possible lockup on close
From: Josh Boyer @ 2007-11-21 15:43 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <20071121154123.GB23589@lst.de>
On Wed, 21 Nov 2007 16:41:23 +0100
Christoph Hellwig <hch@lst.de> wrote:
> On Wed, Nov 21, 2007 at 05:06:39PM +1100, Benjamin Herrenschmidt wrote:
> > It's a bad idea to call flush_scheduled_work from within a
> > netdev->stop because the linkwatch will occasionally take the
> > rtnl lock from a workqueue context, and thus that can deadlock.
> >
> > This reworks things a bit in that area to avoid the problem.
>
> So from the name of the driver you want to keep the previous emac
> driver around. Is there a good reason for that?
It's being kept around until arch/ppc dies. Then things should get
renamed.
josh
^ permalink raw reply
* Re: [PATCH 1/8] ibm_newemac: Fix possible lockup on close
From: Christoph Hellwig @ 2007-11-21 15:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20071121060729.71A1FDDE01@ozlabs.org>
On Wed, Nov 21, 2007 at 05:06:39PM +1100, Benjamin Herrenschmidt wrote:
> It's a bad idea to call flush_scheduled_work from within a
> netdev->stop because the linkwatch will occasionally take the
> rtnl lock from a workqueue context, and thus that can deadlock.
>
> This reworks things a bit in that area to avoid the problem.
So from the name of the driver you want to keep the previous emac
driver around. Is there a good reason for that?
^ permalink raw reply
* annoying prinkts during vmemmap initialization
From: Christoph Hellwig @ 2007-11-21 15:35 UTC (permalink / raw)
To: apw; +Cc: linuxppc-dev
Hi Andi,
your patch 'ppc64: SPARSEMEM_VMEMMAP support' adds the following two lines:
+ printk(KERN_WARNING "vmemmap %08lx allocated at %p, "
+ "physical %p.\n", start, p, __pa(p));
in a loop around basically every page. That's a lot of flooding (with
the wrong printk level, btw) and really slows down booting my cell blade
a lot (these only have a very slow serial over lan console).
Any reason to keep this? And if yes can we please make it conditional
on some kind of vmemmap_debug boot option?
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Kumar Gala @ 2007-11-21 15:34 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.62.0711211524370.12720@pademelon.sonytel.be>
On Nov 21, 2007, at 8:33 AM, Geert Uytterhoeven wrote:
> On Wed, 21 Nov 2007, Kumar Gala wrote:
>> On Nov 21, 2007, at 7:09 AM, Geert Uytterhoeven wrote:
>>> On Tue, 20 Nov 2007, Kumar Gala wrote:
>>>> On Nov 20, 2007, at 11:54 AM, Scott Wood wrote:
>>>>> On Mon, Nov 19, 2007 at 09:36:57PM -0600, Kumar Gala wrote:
>>>>>> isel (Integer Select) is a new user space instruction in the
>>>>>> PowerISA 2.04 spec. Not all processors implement it so lets
>>>>>> emulate
>>>>>> to ensure code built with isel will run everywhere.
>>>>>
>>>>> Given that the instruction is meant to be a performance
>>>>> enhancement,
>>>>> we should probably warn the first few times it's emulated, so
>>>>> the user
>>>>> knows they should change their toolchain setup if possible.
>>>>
>>>> The same is true of mcrxr, popcntb, and possibly string ld/st.
>>>>
>>>> Feel free to submit a patch that warns about their usage.
>>>
>>> Something like this?
>>>
>>> Probably we also want it for:
>>>
>>> - arch/powerpc/kernel/align.c
>>> o emulate_dcbz()
>>> o emulate_multiple()
>>> o emulate_fp_pair()
>>> o emulate_spe()
>>>
>>> - arch/powerpc/kernel/softemu8xx.c
>>> o Soft_emulate_8xx()
>>>
>>> - arch/powerpc/kernel/traps.c
>>> o SoftwareEmulation()
>>
>> You missed math_emu.
>>
>>> - arch/powerpc/kernel/vecemu.c
>>> o emulate_altivec()
>>
>> I'm not sure I would concern this one emulation, there isn't much
>> you can do
>> about the denorm fixup.
>>
>> How about some per processor counters in sysfs under the processor.
>
> Good idea!
>
>>> Question: do we want it for emulate_single_step(), too?
>>
>> What do you mean, we should could the emulation, the emulate single
>> step just
>> is for handling if you are doing debug while hitting an emulated
>> insn.
>
> I mean: should these be counted?
the number of emulated single steps insn? not sure I follow. I think
we should count regardless if we go through emulate_single_step().
- k
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: Kumar Gala @ 2007-11-21 15:33 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <474447EF.8080405@freescale.com>
On Nov 21, 2007, at 8:59 AM, Timur Tabi wrote:
> Kumar Gala wrote:
>
>> + * Freescale 83xx DMA Controller
>> +
>> + Freescale PowerPC 83xx have on chip general purpose DMA
>> controllers.
>> +
>> + Required properties:
>> +
>> + - compatible : compatible list, contains 2 entries,
>> first is
>> + "fsl,CHIP-dma", where CHIP is the processor
>> + (mpc8349, mpc8360, etc.) and the second is
>> + "fsl,elo-dma"
>
> Shouldn't we put some text somewhere that we're calling it the Elo
> controller even though that word isn't used in the reference manual?
we don't really have a place to put that. its effectively documented
right here.
>
>
>> + * Freescale 85xx DMA Controller
>
> And 86xx.
yes, true.
>> +
>> + Freescale PowerPC 85xx have on chip general purpose DMA
>> controllers.
>> +
>> + Required properties:
>> +
>> + - compatible : compatible list, contains 2 entries,
>> first is
>> + "fsl,CHIP-dma", where CHIP is the processor
>> + (mpc8540, mpc8540, etc.) and the second is
>> + "fsl,eloplus-dma"
>> + - reg : <registers mapping for DMA general
>> status reg>
>> + - ranges : Should be defined as specified in 1) to describe
>> the
>> + DMA controller channels.
>> +
>> + - DMA channel nodes:
>> + - compatible : compatible list, contains 2 entries,
>> first is
>> + "fsl,CHIP-dma-channel", where CHIP is the processor
>> + (mpc8540, mpc8560, etc.) and the second is
>> + "fsl,eloplus-dma-channel"
>> + - reg : <registers mapping for channel>
>> + - interrupts : <interrupt mapping for DMA channel IRQ>
>> + - interrupt-parent : optional, if needed for interrupt mapping
>> +
>> + Example:
>> + dma@21000 {
>
> Shouldn't this be dma@21300?
its an example that has not basis is reality :)
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma";
>> + reg = <21300 4>;
>> + ranges = <0 21100 200>;
>> + dma-channel@0 {
>> + compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-
>> channel";
>> + reg = <0 80>;
>> + interrupt-parent = <&mpic>;
>> + interrupts = <14 2>;
>> + };
>
> The DMA controller and the DMA channels need a "device-id", so that
> they can be identified by number. Some peripherals, like the SSI,
> can only use the controller and channel number. This is what I have
> in my 8610 DTS:
Why not use reg for this? I don't see any reason to add another
"unique id" when there is already one.
> dma@21300 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "fsl,mpc8610-dma", "fsl,mpc8540-
> dma";
> --> device-id = <0>;
> reg = <21300 4>; /* DMA general status
> register */
> ranges = <0 21100 200>;
>
> dma-channel@0 {
> compatible = "fsl,mpc8610-dma-channel",
> "fsl,mpc8540-dma-channel";
> --> device-id = <0>;
> reg = <0 80>;
> interrupt-parent = <&mpic>;
> interrupts = <14 2>;
> };
>
- k
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: Timur Tabi @ 2007-11-21 14:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711202314030.24220@blarg.am.freescale.net>
Kumar Gala wrote:
> + * Freescale 83xx DMA Controller
> +
> + Freescale PowerPC 83xx have on chip general purpose DMA controllers.
> +
> + Required properties:
> +
> + - compatible : compatible list, contains 2 entries, first is
> + "fsl,CHIP-dma", where CHIP is the processor
> + (mpc8349, mpc8360, etc.) and the second is
> + "fsl,elo-dma"
Shouldn't we put some text somewhere that we're calling it the Elo controller
even though that word isn't used in the reference manual?
> + * Freescale 85xx DMA Controller
And 86xx.
> +
> + Freescale PowerPC 85xx have on chip general purpose DMA controllers.
> +
> + Required properties:
> +
> + - compatible : compatible list, contains 2 entries, first is
> + "fsl,CHIP-dma", where CHIP is the processor
> + (mpc8540, mpc8540, etc.) and the second is
> + "fsl,eloplus-dma"
> + - reg : <registers mapping for DMA general status reg>
> + - ranges : Should be defined as specified in 1) to describe the
> + DMA controller channels.
> +
> + - DMA channel nodes:
> + - compatible : compatible list, contains 2 entries, first is
> + "fsl,CHIP-dma-channel", where CHIP is the processor
> + (mpc8540, mpc8560, etc.) and the second is
> + "fsl,eloplus-dma-channel"
> + - reg : <registers mapping for channel>
> + - interrupts : <interrupt mapping for DMA channel IRQ>
> + - interrupt-parent : optional, if needed for interrupt mapping
> +
> + Example:
> + dma@21000 {
Shouldn't this be dma@21300?
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma";
> + reg = <21300 4>;
> + ranges = <0 21100 200>;
> + dma-channel@0 {
> + compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
> + reg = <0 80>;
> + interrupt-parent = <&mpic>;
> + interrupts = <14 2>;
> + };
The DMA controller and the DMA channels need a "device-id", so that they can
be identified by number. Some peripherals, like the SSI, can only use the
controller and channel number. This is what I have in my 8610 DTS:
dma@21300 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8610-dma", "fsl,mpc8540-dma";
--> device-id = <0>;
reg = <21300 4>; /* DMA general status register */
ranges = <0 21100 200>;
dma-channel@0 {
compatible = "fsl,mpc8610-dma-channel",
"fsl,mpc8540-dma-channel";
--> device-id = <0>;
reg = <0 80>;
interrupt-parent = <&mpic>;
interrupts = <14 2>;
};
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [RFC/PATCH 0/14] powerpc: 4xx PCI and PCI-X support
From: Josh Boyer @ 2007-11-21 14:33 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200711211504.13003.sr@denx.de>
On Wed, 21 Nov 2007 15:04:12 +0100
Stefan Roese <sr@denx.de> wrote:
> On Wednesday 21 November 2007, Josh Boyer wrote:
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > > Here's a set of patches that bring PCI and PCI-X support for
> > > 4xx (PCIe still missing) in arch/powerpc.
> > >
> > > This is for review before I ask paulus to pull that into his
> > > for 2.6.25 tree. Some of the patches still need a bit more
> > > testing vs. regressions on other platforms such as the
> > > 64 bits resource fixup one.
> >
> > I'm starting my 2.6.25 branch today. I'll probably throw these in
> > there after I've tested a bit, since I need them to make further
> > progress with 4xx anyway.
>
> Yes, it would be great to have an "official" repo with all the new 4xx stuff
> (PCI, EMAC...) stuff.
Sure, I can do that. I'll probably use my master branch for this
instead, and reserve for-2.6.25 for sending stuff to Paul. Reason
being that lots of useful things for 4xx don't actually go through my
tree (like EMAC, MTD stuff, etc).
I'll send out an email when I've queued up some stuff.
josh
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Geert Uytterhoeven @ 2007-11-21 14:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <7D40FA9E-A972-4995-85AE-3CE2551BB195@kernel.crashing.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2359 bytes --]
On Wed, 21 Nov 2007, Kumar Gala wrote:
> On Nov 21, 2007, at 7:09 AM, Geert Uytterhoeven wrote:
> > On Tue, 20 Nov 2007, Kumar Gala wrote:
> > > On Nov 20, 2007, at 11:54 AM, Scott Wood wrote:
> > > > On Mon, Nov 19, 2007 at 09:36:57PM -0600, Kumar Gala wrote:
> > > > > isel (Integer Select) is a new user space instruction in the
> > > > > PowerISA 2.04 spec. Not all processors implement it so lets emulate
> > > > > to ensure code built with isel will run everywhere.
> > > >
> > > > Given that the instruction is meant to be a performance enhancement,
> > > > we should probably warn the first few times it's emulated, so the user
> > > > knows they should change their toolchain setup if possible.
> > >
> > > The same is true of mcrxr, popcntb, and possibly string ld/st.
> > >
> > > Feel free to submit a patch that warns about their usage.
> >
> > Something like this?
> >
> > Probably we also want it for:
> >
> > - arch/powerpc/kernel/align.c
> > o emulate_dcbz()
> > o emulate_multiple()
> > o emulate_fp_pair()
> > o emulate_spe()
> >
> > - arch/powerpc/kernel/softemu8xx.c
> > o Soft_emulate_8xx()
> >
> > - arch/powerpc/kernel/traps.c
> > o SoftwareEmulation()
>
> You missed math_emu.
>
> > - arch/powerpc/kernel/vecemu.c
> > o emulate_altivec()
>
> I'm not sure I would concern this one emulation, there isn't much you can do
> about the denorm fixup.
>
> How about some per processor counters in sysfs under the processor.
Good idea!
> > Question: do we want it for emulate_single_step(), too?
>
> What do you mean, we should could the emulation, the emulate single step just
> is for handling if you are doing debug while hitting an emulated insn.
I mean: should these be counted?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Kumar Gala @ 2007-11-21 14:22 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.62.0711211407260.12720@pademelon.sonytel.be>
On Nov 21, 2007, at 7:09 AM, Geert Uytterhoeven wrote:
> On Tue, 20 Nov 2007, Kumar Gala wrote:
>> On Nov 20, 2007, at 11:54 AM, Scott Wood wrote:
>>> On Mon, Nov 19, 2007 at 09:36:57PM -0600, Kumar Gala wrote:
>>>> isel (Integer Select) is a new user space instruction in the
>>>> PowerISA 2.04 spec. Not all processors implement it so lets
>>>> emulate
>>>> to ensure code built with isel will run everywhere.
>>>
>>> Given that the instruction is meant to be a performance enhancement,
>>> we should probably warn the first few times it's emulated, so the
>>> user
>>> knows they should change their toolchain setup if possible.
>>
>> The same is true of mcrxr, popcntb, and possibly string ld/st.
>>
>> Feel free to submit a patch that warns about their usage.
>
> Something like this?
>
> Probably we also want it for:
>
> - arch/powerpc/kernel/align.c
> o emulate_dcbz()
> o emulate_multiple()
> o emulate_fp_pair()
> o emulate_spe()
>
> - arch/powerpc/kernel/softemu8xx.c
> o Soft_emulate_8xx()
>
> - arch/powerpc/kernel/traps.c
> o SoftwareEmulation()
You missed math_emu.
> - arch/powerpc/kernel/vecemu.c
> o emulate_altivec()
I'm not sure I would concern this one emulation, there isn't much you
can do about the denorm fixup.
How about some per processor counters in sysfs under the processor.
> Question: do we want it for emulate_single_step(), too?
What do you mean, we should could the emulation, the emulate single
step just is for handling if you are doing debug while hitting an
emulated insn.
> So far my Debian userland didn't trigger any of them on the PS3, I
> had to
> write an explicit test ;-)
> ---
> arch/powerpc/kernel/traps.c | 19 +++++++++++++++++--
> 1 files changed, 17 insertions(+), 2 deletions(-)
>
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -707,6 +707,14 @@ static int emulate_popcntb_inst(struct p
> return 0;
> }
>
> +#define WARN_EMULATE(type) \
> + do { \
> + static unsigned int count; \
> + if (count++ < 10) \
> + pr_warning("%s used emulated %s instruction\n", \
> + current->comm, type); \
> + } while (0)
> +
> static int emulate_instruction(struct pt_regs *regs)
> {
> u32 instword;
> @@ -721,31 +729,38 @@ static int emulate_instruction(struct pt
>
> /* Emulate the mfspr rD, PVR. */
> if ((instword & INST_MFSPR_PVR_MASK) == INST_MFSPR_PVR) {
> + WARN_EMULATE("mfpvr");
> rd = (instword >> 21) & 0x1f;
> regs->gpr[rd] = mfspr(SPRN_PVR);
> return 0;
> }
>
> /* Emulating the dcba insn is just a no-op. */
> - if ((instword & INST_DCBA_MASK) == INST_DCBA)
> + if ((instword & INST_DCBA_MASK) == INST_DCBA) {
> + WARN_EMULATE("dcba");
> return 0;
> + }
>
> /* Emulate the mcrxr insn. */
> if ((instword & INST_MCRXR_MASK) == INST_MCRXR) {
> int shift = (instword >> 21) & 0x1c;
> unsigned long msk = 0xf0000000UL >> shift;
>
> + WARN_EMULATE("mcrxr");
> regs->ccr = (regs->ccr & ~msk) | ((regs->xer >> shift) & msk);
> regs->xer &= ~0xf0000000UL;
> return 0;
> }
>
> /* Emulate load/store string insn. */
> - if ((instword & INST_STRING_GEN_MASK) == INST_STRING)
> + if ((instword & INST_STRING_GEN_MASK) == INST_STRING) {
> + WARN_EMULATE("string");
> return emulate_string_inst(regs, instword);
> + }
>
> /* Emulate the popcntb (Population Count Bytes) instruction. */
> if ((instword & INST_POPCNTB_MASK) == INST_POPCNTB) {
> + WARN_EMULATE("popcntb");
> return emulate_popcntb_inst(regs, instword);
> }
>
This looks good as a start.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Kumar Gala @ 2007-11-21 14:19 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1195636347.6970.80.camel@pasglop>
On Nov 21, 2007, at 3:12 AM, Benjamin Herrenschmidt wrote:
>
> On Tue, 2007-11-20 at 15:01 -0600, Kumar Gala wrote:
>>> Given that the instruction is meant to be a performance enhancement,
>>> we should probably warn the first few times it's emulated, so the
>> user
>>> knows they should change their toolchain setup if possible.
>>
>> The same is true of mcrxr, popcntb, and possibly string ld/st.
>>
>> Feel free to submit a patch that warns about their usage.
>
> At least we should keep counters... best would be per-task counters
> in /proc but that sounds harder :-)
>
> I remember in the early days of powerpc, it wasn't uncommon to have
> apps
> with issues because they used 601 only bits on 603/4 that had to be
> emulated (such as old POWER opcodes). On MacOS, we used to have a
> system-wide counter of the number of emulated instructions we could
> use
> to detect these things.
I think having some form of per insn group counters would be useful as
well. I know it would be helpful to debug user problems if they are
doing a lot of FP emu or the like and don't know it.
- k
^ permalink raw reply
* Re: [RFC/PATCH 0/14] powerpc: 4xx PCI and PCI-X support
From: Stefan Roese @ 2007-11-21 14:04 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071121072348.7fff79a9@weaponx>
On Wednesday 21 November 2007, Josh Boyer wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > Here's a set of patches that bring PCI and PCI-X support for
> > 4xx (PCIe still missing) in arch/powerpc.
> >
> > This is for review before I ask paulus to pull that into his
> > for 2.6.25 tree. Some of the patches still need a bit more
> > testing vs. regressions on other platforms such as the
> > 64 bits resource fixup one.
>
> I'm starting my 2.6.25 branch today. I'll probably throw these in
> there after I've tested a bit, since I need them to make further
> progress with 4xx anyway.
Yes, it would be great to have an "official" repo with all the new 4xx stuff
(PCI, EMAC...) stuff.
Thanks.
Best regards,
Stefan
^ permalink raw reply
* Firmware Support for USB Hub
From: Misbah khan @ 2007-11-21 13:45 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I am using a 8248 processor which has a USB controller and i need to connect
a USB Hub to it, iam using Montavista Linux .I need to know that what are
the support i need form Montavista or Open source to have an interface with
Usb hub. ???
Is there any driver that we need to make if so what type ???
--misbah <><
--
View this message in context: http://www.nabble.com/Firmware-Support-for-USB-Hub-tf4850180.html#a13877282
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC/PATCH 14/14] powerpc: Add PCI to Walnut platform
From: Josh Boyer @ 2007-11-21 13:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071121061722.2FCB7DDE45@ozlabs.org>
On Wed, 21 Nov 2007 17:16:32 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> This wires up the 4xx PCI support & device-tree bits for the
> 405GP based Walnut platform.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> This one is untested, haven't had time to dig my walnut and put it
> back into working condition. Josh, can you verify that IRQs are
> working (routing is correct ?) Thanks !
Yep, I'll try it out early next week.
josh
^ permalink raw reply
* Re: [RFC/PATCH 0/14] powerpc: 4xx PCI and PCI-X support
From: Josh Boyer @ 2007-11-21 13:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1195625777.579001.269266058699.qpush@grosgo>
On Wed, 21 Nov 2007 17:16:17 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Here's a set of patches that bring PCI and PCI-X support for
> 4xx (PCIe still missing) in arch/powerpc.
>
> This is for review before I ask paulus to pull that into his
> for 2.6.25 tree. Some of the patches still need a bit more
> testing vs. regressions on other platforms such as the
> 64 bits resource fixup one.
I'm starting my 2.6.25 branch today. I'll probably throw these in
there after I've tested a bit, since I need them to make further
progress with 4xx anyway.
josh
^ permalink raw reply
* Re: [RFC/PATCH 13/14] powerpc: EP405 boards support for arch/powerpc
From: Josh Boyer @ 2007-11-21 13:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071121061721.8497FDEBFC@ozlabs.org>
On Wed, 21 Nov 2007 17:16:31 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Brings EP405 support to arch/powerpc. The IRQ routing for the CPLD
> comes from a device-tree property, PCI is working to the point where
> I can see the video card, USB device, and south bridge.
>
> This should work with both EP405 and EP405PC.
>
> I've not totally figured out how IRQs are wired on this hardware
> though, thus at this stage, expect only USB interrupts working,
> pretty much the same as what arch/ppc did.
>
> Also, the flash, nvram, rtc and temp control still have to be wired.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
<snip>
> Index: linux-work/arch/powerpc/boot/dts/ep405.dts
> ===================================================================
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ linux-work/arch/powerpc/boot/dts/ep405.dts 2007-11-21 16:23:03.000000000 +1100
> @@ -0,0 +1,221 @@
> +/*
> + * Device Tree Source for EP405
> + *
> + * Copyright 2007 IBM Corp.
> + * Josh Boyer <jwboyer@linux.vnet.ibm.com>
Hm... odd. I don't remember writing this device tree ;)
josh
^ permalink raw reply
* Re: [RFC/PATCH 5/14] powerpc: Fix 440/440A machine check handling
From: Josh Boyer @ 2007-11-21 13:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071121061714.0AB82DEAF1@ozlabs.org>
On Wed, 21 Nov 2007 17:16:24 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> This removes CONFIG_440A which was a problem for multiplatform
> kernels and instead fixes up the IVOR at runtime from a setup_cpu
> function. The "A" version of the machine check also tweaks the
> regs->trap value to differenciate the 2 versions at the C level.
>
<snip>
> void machine_check_exception(struct pt_regs *regs)
> {
> @@ -463,8 +489,20 @@ void machine_check_exception(struct pt_r
> /* See if any machine dependent calls */
> if (ppc_md.machine_check_exception)
> recover = ppc_md.machine_check_exception(regs);
> - else
> - recover = generic_machine_check_exception(regs);
> + else {
> +#ifdef CONFIG_4xx
> + if (IS_MCHECK_EXC(regs))
> + recover = decode_machine_check_4xxA(regs);
> + else
> + recover = decode_machine_check_4xx(regs);
> +#elif defined (CONFIG_E500)
> + recover = decode_machine_check_e500(regs);
> +#elif defined (CONFIG_E200)
> + recover = decode_machine_check_e200(regs);
> +#else
> + recover = decode_machine_check_generic(regs);
> +#endif
Why didn't you just add a ppc_md.machine_check_exception to the
effected boards? Then you could have gotten rid of the ifdefs all
together.
josh
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Geert Uytterhoeven @ 2007-11-21 13:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <B82E6C31-8BB7-4348-9426-B18A971172A9@kernel.crashing.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3610 bytes --]
On Tue, 20 Nov 2007, Kumar Gala wrote:
> On Nov 20, 2007, at 11:54 AM, Scott Wood wrote:
> > On Mon, Nov 19, 2007 at 09:36:57PM -0600, Kumar Gala wrote:
> >> isel (Integer Select) is a new user space instruction in the
> >> PowerISA 2.04 spec. Not all processors implement it so lets emulate
> >> to ensure code built with isel will run everywhere.
> >
> > Given that the instruction is meant to be a performance enhancement,
> > we should probably warn the first few times it's emulated, so the user
> > knows they should change their toolchain setup if possible.
>
> The same is true of mcrxr, popcntb, and possibly string ld/st.
>
> Feel free to submit a patch that warns about their usage.
Something like this?
Probably we also want it for:
- arch/powerpc/kernel/align.c
o emulate_dcbz()
o emulate_multiple()
o emulate_fp_pair()
o emulate_spe()
- arch/powerpc/kernel/softemu8xx.c
o Soft_emulate_8xx()
- arch/powerpc/kernel/traps.c
o SoftwareEmulation()
- arch/powerpc/kernel/vecemu.c
o emulate_altivec()
Question: do we want it for emulate_single_step(), too?
So far my Debian userland didn't trigger any of them on the PS3, I had to
write an explicit test ;-)
---
arch/powerpc/kernel/traps.c | 19 +++++++++++++++++--
1 files changed, 17 insertions(+), 2 deletions(-)
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -707,6 +707,14 @@ static int emulate_popcntb_inst(struct p
return 0;
}
+#define WARN_EMULATE(type) \
+ do { \
+ static unsigned int count; \
+ if (count++ < 10) \
+ pr_warning("%s used emulated %s instruction\n", \
+ current->comm, type); \
+ } while (0)
+
static int emulate_instruction(struct pt_regs *regs)
{
u32 instword;
@@ -721,31 +729,38 @@ static int emulate_instruction(struct pt
/* Emulate the mfspr rD, PVR. */
if ((instword & INST_MFSPR_PVR_MASK) == INST_MFSPR_PVR) {
+ WARN_EMULATE("mfpvr");
rd = (instword >> 21) & 0x1f;
regs->gpr[rd] = mfspr(SPRN_PVR);
return 0;
}
/* Emulating the dcba insn is just a no-op. */
- if ((instword & INST_DCBA_MASK) == INST_DCBA)
+ if ((instword & INST_DCBA_MASK) == INST_DCBA) {
+ WARN_EMULATE("dcba");
return 0;
+ }
/* Emulate the mcrxr insn. */
if ((instword & INST_MCRXR_MASK) == INST_MCRXR) {
int shift = (instword >> 21) & 0x1c;
unsigned long msk = 0xf0000000UL >> shift;
+ WARN_EMULATE("mcrxr");
regs->ccr = (regs->ccr & ~msk) | ((regs->xer >> shift) & msk);
regs->xer &= ~0xf0000000UL;
return 0;
}
/* Emulate load/store string insn. */
- if ((instword & INST_STRING_GEN_MASK) == INST_STRING)
+ if ((instword & INST_STRING_GEN_MASK) == INST_STRING) {
+ WARN_EMULATE("string");
return emulate_string_inst(regs, instword);
+ }
/* Emulate the popcntb (Population Count Bytes) instruction. */
if ((instword & INST_POPCNTB_MASK) == INST_POPCNTB) {
+ WARN_EMULATE("popcntb");
return emulate_popcntb_inst(regs, instword);
}
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: linux2.6.19.2-> mpc8xx_wdt.c: timeout extended to reach several seconds... but I have a problem
From: Jochen Friedrich @ 2007-11-21 12:51 UTC (permalink / raw)
To: DI BACCO ANTONIO - technolabs; +Cc: linuxppc-embedded
In-Reply-To: <F1F6EC0C8B75034F9E3A79FC85122E8E2649FB@aquib01a>
Hi Antonio,
> I added a kernel timer (triggering every 500 ms) to reset the watchdog
> of mpc8xx. This timer starts when the driver is opened. The timer is
> rearmed till a counter reaches a zero value. A process can use the write
> method of the driver to set the counter to a preferred value. If the
> application misses to set the counter, it will decrease to zero and then
> the board will restart.
You might want to have a look at this patch:
http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=14682
Please make sure to call pq_wdt_init() as early as possible to avoid a
reset during the initial log buffer flush to the serial console.
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Benjamin Herrenschmidt @ 2007-11-21 9:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <B82E6C31-8BB7-4348-9426-B18A971172A9@kernel.crashing.org>
On Tue, 2007-11-20 at 15:01 -0600, Kumar Gala wrote:
> > Given that the instruction is meant to be a performance enhancement,
> > we should probably warn the first few times it's emulated, so the
> user
> > knows they should change their toolchain setup if possible.
>
> The same is true of mcrxr, popcntb, and possibly string ld/st.
>
> Feel free to submit a patch that warns about their usage.
At least we should keep counters... best would be per-task counters
in /proc but that sounds harder :-)
I remember in the early days of powerpc, it wasn't uncommon to have apps
with issues because they used 601 only bits on 603/4 that had to be
emulated (such as old POWER opcodes). On MacOS, we used to have a
system-wide counter of the number of emulated instructions we could use
to detect these things.
Ben.
^ permalink raw reply
* RE: [PATCH v7 3/9] add Freescale SerDes PHY support
From: Benjamin Herrenschmidt @ 2007-11-21 8:42 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <989B956029373F45A0B8AF029708189001A1C7DF@zch01exm26.fsl.freescale.net>
> I'm ok for it to be taken care of in u-boot for now. However, if we
> later plan to add power management support to this block. We probably
> have to do it in kernel.
In that case, can't it be just saving/restoring ? That's easier than
supporting full configuration of random user setups
Ben.
^ 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