* what is difference between interrupt context and process context?
From: Barisa Kisku @ 2007-11-02 6:11 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 332 bytes --]
Hi,
What is difference between interrupt context and process
context.Fromhardware(register context) view
how they are different.In linux-2.6 interrupt stack is separate from kernel
stack.How interrupt stack pointer
is retrieved?How is the implementation in freescale ppc/powerpc.
please comment.
thanks in advance.
Barisa Kisku
[-- Attachment #2: Type: text/html, Size: 379 bytes --]
^ permalink raw reply
* Re: [PATCH] ehea: add kexec support
From: Michael Ellerman @ 2007-11-02 6:30 UTC (permalink / raw)
To: Christoph Raisch
Cc: Thomas Q Klein, ossthema, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Marcus Eder, Stefan Roscher
In-Reply-To: <OF59B5FFD2.0294206F-ONC1257385.006A802D-C1257385.006CB6BB@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]
On Wed, 2007-10-31 at 20:48 +0100, Christoph Raisch wrote:
> Michael Ellerman <michael@ellerman.id.au> wrote on 30.10.2007 23:50:36:
> >
> > On Tue, 2007-10-30 at 09:39 +0100, Christoph Raisch wrote:
> > >
> > > Michael Ellerman <michael@ellerman.id.au> wrote on 28.10.2007 23:32:17:
> > > Hope I didn't miss anything here...
> >
> > Perhaps. When we kdump the kernel does not call the reboot notifiers, so
> > the code Jan-Bernd just added won't get called. So the eHEA resources
> > won't be freed. When the kdump kernel tries to load the eHEA driver what
> > will happen?
> >
> Good point.
>
> If the device driver tries to allocate resources again (in the kdump
> kernel),
> which have been allocated before (in the crashed kernel) the hcalls will
> fail because from the hypervisor view the resources are still in use.
> Currently there's no method to find out the resource handles for these
> HEA resources allocated by the crashed kernel within the hypervisor...
So the hypervisor can't allocate more resources, because they're already
allocated, but it can't free the ones that are allocated because it
doesn't know what they are? I don't think I understand.
If that's really the way it works then eHEA is more or less broken for
kdump I'm afraid.
cheers
--
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: 189 bytes --]
^ permalink raw reply
* [PATCH] net: Add 405EX support to new EMAC driver
From: Stefan Roese @ 2007-11-02 7:14 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev
This patch adds support for the 405EX to the new EMAC driver. Some as on
AXON, the 405EX handles the MDIO via the RGMII bridge.
Tested on AMCC Kilauea.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/core.c | 3 ++-
drivers/net/ibm_newemac/rgmii.c | 16 +++++++++++-----
drivers/net/ibm_newemac/rgmii.h | 2 +-
3 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 0de3aa2..fd0a585 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -2466,7 +2466,8 @@ static int __devinit emac_init_config(struct emac_instance *dev)
if (of_device_is_compatible(np, "ibm,emac4"))
dev->features |= EMAC_FTR_EMAC4;
if (of_device_is_compatible(np, "ibm,emac-axon")
- || of_device_is_compatible(np, "ibm,emac-440epx"))
+ || of_device_is_compatible(np, "ibm,emac-440epx")
+ || of_device_is_compatible(np, "ibm,emac-405ex"))
dev->features |= EMAC_FTR_HAS_AXON_STACR
| EMAC_FTR_STACR_OC_INVERT;
if (of_device_is_compatible(np, "ibm,emac-440spe"))
diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
index de41695..b9a4ce7 100644
--- a/drivers/net/ibm_newemac/rgmii.c
+++ b/drivers/net/ibm_newemac/rgmii.c
@@ -140,7 +140,12 @@ void rgmii_get_mdio(struct of_device *ofdev, int input)
RGMII_DBG2(dev, "get_mdio(%d)" NL, input);
- if (dev->type != RGMII_AXON)
+ /*
+ * Some platforms (e.g. 440GX) have RGMII support but don't use it for
+ * MDIO access. Only continue if platforms is using MDIO over the RGMII
+ * interface (e.g. AXON, 405EX).
+ */
+ if (dev->type != RGMII_HAS_MDIO)
return;
mutex_lock(&dev->lock);
@@ -161,7 +166,7 @@ void rgmii_put_mdio(struct of_device *ofdev, int input)
RGMII_DBG2(dev, "put_mdio(%d)" NL, input);
- if (dev->type != RGMII_AXON)
+ if (dev->type != RGMII_HAS_MDIO)
return;
fer = in_be32(&p->fer);
@@ -251,8 +256,9 @@ static int __devinit rgmii_probe(struct of_device *ofdev,
}
/* Check for RGMII type */
- if (of_device_is_compatible(ofdev->node, "ibm,rgmii-axon"))
- dev->type = RGMII_AXON;
+ if (of_device_is_compatible(ofdev->node, "ibm,rgmii-axon") ||
+ of_device_is_compatible(ofdev->node, "ibm,rgmii-405ex"))
+ dev->type = RGMII_HAS_MDIO;
else
dev->type = RGMII_STANDARD;
@@ -264,7 +270,7 @@ static int __devinit rgmii_probe(struct of_device *ofdev,
printk(KERN_INFO
"RGMII %s %s initialized\n",
- dev->type == RGMII_STANDARD ? "standard" : "axon",
+ dev->type == RGMII_STANDARD ? "standard" : "has-mdio",
ofdev->node->full_name);
wmb();
diff --git a/drivers/net/ibm_newemac/rgmii.h b/drivers/net/ibm_newemac/rgmii.h
index 5780683..f1b0ef5 100644
--- a/drivers/net/ibm_newemac/rgmii.h
+++ b/drivers/net/ibm_newemac/rgmii.h
@@ -23,7 +23,7 @@
/* RGMII bridge type */
#define RGMII_STANDARD 0
-#define RGMII_AXON 1
+#define RGMII_HAS_MDIO 1
/* RGMII bridge */
struct rgmii_regs {
--
1.5.3.4.498.g9c514
^ permalink raw reply related
* Re: [PATCH] Restore deterministic CPU accounting on powerpc
From: Martin Schwidefsky @ 2007-11-02 7:49 UTC (permalink / raw)
To: Paul Mackerras
Cc: Peter Zijlstra, Christian Borntraeger, linux-kernel, linuxppc-dev,
Ingo Molnar, Thomas Gleixner
In-Reply-To: <18218.44089.274628.680088@cargo.ozlabs.ibm.com>
On Fri, 2007-11-02 at 15:48 +1100, Paul Mackerras wrote:
> This also lets us simplify the s390 code a bit; it means that the s390
> timer interrupt can now call update_process_times even when
> CONFIG_VIRT_CPU_ACCOUNTING is turned on, and can just implement a
> suitable account_process_tick().
Just tested on s390 with CONFIG_VIRT_CPU_ACCOUNTING=y. Works fine and it
is a nice cleanup of the s390 timer code. Thanks Paul.
Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* RE:
From: MingLiu @ 2007-11-02 9:35 UTC (permalink / raw)
To: Mead, Joseph, linuxppc-embedded
In-Reply-To: <D1AFFAE2CC4BD54CA4C1543CFF4A4FCC59788F@exchangemb3.bnl.gov>
[-- Attachment #1: Type: text/plain, Size: 743 bytes --]
Hi Joe,
I don't think you can do 64 bit transfer at once because ppc405 is a 32-bit CPU. So we have to the transfer in twice.
BR
Ming
Date: Thu, 1 Nov 2007 14:18:07 -0400From: mead@bnl.govTo: linuxppc-embedded@ozlabs.orgSubject:
I am using a Xilinx ML403 board and created a custom IP that connects to the PLB bus. The PLB bus is 64 bits wide. To communicate with the custom IP I have been using iowrite32() and ioread32() function calls to grab 32 bits at a time. Is it possible to grab the full 64 bits in one transfer? I don’t see an iowrite64() or ioread64() function…
Thanks,Joe
_________________________________________________________________
用 Live Search 搜尽天下资讯！
http://www.live.com/?searchOnly=true
[-- Attachment #2: Type: text/html, Size: 2235 bytes --]
^ permalink raw reply
* Re: [PATCH] ehea: add kexec support
From: Christoph Raisch @ 2007-11-02 10:19 UTC (permalink / raw)
To: michael
Cc: Thomas Q Klein, ossthema, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Marcus Eder, Stefan Roscher
In-Reply-To: <1193985008.1782.7.camel@concordia>
Michael Ellerman <michael@ellerman.id.au> wrote on 02.11.2007 07:30:08:
> On Wed, 2007-10-31 at 20:48 +0100, Christoph Raisch wrote:
> > Michael Ellerman <michael@ellerman.id.au> wrote on 30.10.2007 23:50:36:
> If that's really the way it works then eHEA is more or less broken for
> kdump I'm afraid.
We think we have a way to workaround this, but let me first try to
explain the base problem.
DD allocates HEA resources and gets firmware_handles for these resources.
To free the resources DD needs to use exactly these handles.
There's no generic firmware call "clean out all resources".
Allocating the same resources twice does not work.
So a new kernel can't free the resources allocated by an old kernel,
because the numeric values of the handles aren't known anymore.
Potential Solution:
Hea driver cleanup function hooks into ppc_md.machine_crash_shutdown
and frees all firmware resources at shutdown time of the crashed kernel.
crash_kexec continues and loads new kernel.
The new kernel restarts the HEA driver within kdump kernel, which will work
because resources have been freed before.
Michael, would this work?
Gruss / Regards
Christoph R.
^ permalink raw reply
* Re: [PATCH 3/3] Add arch-specific walk_memory_remove() for ppc64
From: Johannes Berg @ 2007-11-02 10:32 UTC (permalink / raw)
To: Badari Pulavarty
Cc: linux-mm, anton, linuxppc-dev, Paul Mackerras, Andrew Morton,
KAMEZAWA Hiroyuki
In-Reply-To: <1193849335.17412.33.camel@dyn9047017100.beaverton.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 180 bytes --]
> This patch provides a way for an architecture to provide its
> own walk_memory_resource()
It seems that the patch description "walk_memory_remove()" is wrong?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* RE: The question about the fail at the begin of linux on MPC8360E.
From: Medve Emilian-EMMEDVE1 @ 2007-11-02 12:55 UTC (permalink / raw)
To: 郭劲, linuxppc-embedded
In-Reply-To: <393972917.10298@tsinghua.org.cn>
Hi there,
You need a device tree. The defaut one is =
arch/powerpc/boot/dts/mpc836x_mds.dts. You need the DTC (Device Tree =
Compiler) from here http://jdl.com/git_repos/?p=3Ddtc.git;a=3Dsummary. =
This should be enough to give you some reading pointers.
Cheers,
Emil.
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+emilian.medve=3Dfreescale.com@ozlabs.o
> rg=20
> [mailto:linuxppc-embedded-bounces+emilian.medve=3Dfreescale.com@
> ozlabs.org] On Behalf Of ??
> Sent: Thursday, November 01, 2007 10:09 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: The question about the fail at the begin of linux on=20
> MPC8360E.
>=20
> Hi,friends,
> Thanks.
>=20
> We boot the linux-2.6.22 on MPC8360 board, it failed, follow=20
> is the output
> information. we just only success on linux-2.6.11, but fail=20
> on linux-2.6.19 and
> linux-2.6.22. Both 2.6.19 and 2.6.22 are failed on same=20
> position,please see follow
> information. linux-2.6.19 and linux-2.6.22 are come from BSP=20
> of freescale. I used
> the u-boot-1.2.0 that compiled by myself. We guess that maybe=20
> we did not setup the
> bootargs parameter on u-boot rightly or maybe the DDR-I=20
> hardware circuit design is
> not good enough.
>=20
> If the reason is the bootargs parameter, could you tell me=20
> what is the right
> bootargs for linux-2.6.19 and linux-2.6.22?
>=20
> If the reason is the DDR, I want to boot the linux on my=20
> SDRAM chip,kick off the
> DDR, my SDRAM located on the address of F0000000~F3FFFFFF,=20
> total 64MB. How can I
> modify the source code of linux to re-map it and ramdisk and=20
> others to my SDRAM
> chip space?
>=20
>=20
> Follow is the fail information:
> =3D> bootm 0c000000 0e000000
> ## Booting image at 0c000000 ...
> Image Name: Linux-2.6.22
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1333681 Bytes =3D 1.3 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> ## Loading RAMDisk Image at 0e000000 ...
> Image Name: uboot ext2 ramdisk rootfs
> Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
> Data Size: 3589813 Bytes =3D 3.4 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Loading Ramdisk to 0fc3e000, end 0ffaa6b5 ... OK =20
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ permalink raw reply
* [PATCH 0/2] IB/ehca: Return physical link information, fix static rate calculation
From: Joachim Fenkes @ 2007-11-02 13:32 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier, OF-EWG
Cc: Stefan Roscher, Christoph Raisch
This patchset will fix static rate calculation for the new link speeds
supported by eHCA2. Also, it enables query_port() to return physical link
information instead of constant values, which is needed for the static rate
fix.
[1/2] makes query_port() return actual physical link info where supported
[2/2] fixes static rate calculation based on that info
The patches will apply, in order, on top of Roland's for-2.6.24 branch.
Please review them and apply for 2.6.24-rc2 if you think they're okay.
Thanks and regards,
Joachim
--
Joachim Fenkes -- eHCA Linux Driver Developer and Hardware Tamer
IBM Deutschland Entwicklung GmbH -- Dept. 3627 (I/O Firmware Dev. 2)
Schoenaicher Strasse 220 -- 71032 Boeblingen -- Germany
eMail: fenkes@de.ibm.com
^ permalink raw reply
* [PATCH 1/2] IB/ehca: Return physical link information in query_port()
From: Joachim Fenkes @ 2007-11-02 13:33 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier, OF-EWG
Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200711021432.50203.fenkes@de.ibm.com>
Newer firmware versions return physical port information to the partition,
so hand that information to the consumer if it's present.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_hca.c | 20 ++++++++++++++------
drivers/infiniband/hw/ehca/hipz_hw.h | 6 +++++-
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_hca.c b/drivers/infiniband/hw/ehca/ehca_hca.c
index 15806d1..5bd7b59 100644
--- a/drivers/infiniband/hw/ehca/ehca_hca.c
+++ b/drivers/infiniband/hw/ehca/ehca_hca.c
@@ -151,7 +151,6 @@ int ehca_query_port(struct ib_device *ibdev,
}
memset(props, 0, sizeof(struct ib_port_attr));
- props->state = rblock->state;
switch (rblock->max_mtu) {
case 0x1:
@@ -188,11 +187,20 @@ int ehca_query_port(struct ib_device *ibdev,
props->subnet_timeout = rblock->subnet_timeout;
props->init_type_reply = rblock->init_type_reply;
- props->active_width = IB_WIDTH_12X;
- props->active_speed = 0x1;
-
- /* at the moment (logical) link state is always LINK_UP */
- props->phys_state = 0x5;
+ if (rblock->state && rblock->phys_width) {
+ props->phys_state = rblock->phys_pstate;
+ props->state = rblock->phys_state;
+ props->active_width = rblock->phys_width;
+ props->active_speed = rblock->phys_speed;
+ } else {
+ /* old firmware releases don't report physical
+ * port info, so use default values
+ */
+ props->phys_state = 5;
+ props->state = rblock->state;
+ props->active_width = IB_WIDTH_12X;
+ props->active_speed = 0x1;
+ }
query_port1:
ehca_free_fw_ctrlblock(rblock);
diff --git a/drivers/infiniband/hw/ehca/hipz_hw.h b/drivers/infiniband/hw/ehca/hipz_hw.h
index d9739e5..485b840 100644
--- a/drivers/infiniband/hw/ehca/hipz_hw.h
+++ b/drivers/infiniband/hw/ehca/hipz_hw.h
@@ -402,7 +402,11 @@ struct hipz_query_port {
u64 max_msg_sz;
u32 max_mtu;
u32 vl_cap;
- u8 reserved2[1900];
+ u32 phys_pstate;
+ u32 phys_state;
+ u32 phys_speed;
+ u32 phys_width;
+ u8 reserved2[1884];
u64 guid_entries[255];
} __attribute__ ((packed));
--
1.5.2
^ permalink raw reply related
* [PATCH 2/2] IB/ehca: Fix static rate calculation
From: Joachim Fenkes @ 2007-11-02 13:41 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier, OF-EWG
Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200711021432.50203.fenkes@de.ibm.com>
The IPD formula was a little off and assumed a fixed physical link rate; fix
the formula and query the actual physical link rate, now that we can get it.
Also, refactor the calculation into a common function ehca_calc_ipd() and
use that instead of duplicating code.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_av.c | 48 +++++++++++++++++++++++-----
drivers/infiniband/hw/ehca/ehca_classes.h | 1 -
drivers/infiniband/hw/ehca/ehca_iverbs.h | 3 ++
drivers/infiniband/hw/ehca/ehca_main.c | 3 --
drivers/infiniband/hw/ehca/ehca_qp.c | 29 +++++++----------
5 files changed, 54 insertions(+), 30 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_av.c b/drivers/infiniband/hw/ehca/ehca_av.c
index 97d1086..453eb99 100644
--- a/drivers/infiniband/hw/ehca/ehca_av.c
+++ b/drivers/infiniband/hw/ehca/ehca_av.c
@@ -50,6 +50,38 @@
static struct kmem_cache *av_cache;
+int ehca_calc_ipd(struct ehca_shca *shca, int port,
+ enum ib_rate path_rate, u32 *ipd)
+{
+ int path = ib_rate_to_mult(path_rate);
+ int link, ret;
+ struct ib_port_attr pa;
+
+ if (path_rate == IB_RATE_PORT_CURRENT) {
+ *ipd = 0;
+ return 0;
+ }
+
+ if (unlikely(path < 0)) {
+ ehca_err(&shca->ib_device, "Invalid static rate! path_rate=%x",
+ path_rate);
+ return -EINVAL;
+ }
+
+ ret = ehca_query_port(&shca->ib_device, port, &pa);
+ if (unlikely(ret < 0)) {
+ ehca_err(&shca->ib_device, "Failed to query port ret=%i", ret);
+ return ret;
+ }
+
+ link = ib_width_enum_to_int(pa.active_width) * pa.active_speed;
+
+ /* IPD = round((link / path) - 1) */
+ *ipd = ((link + (path >> 1)) / path) - 1;
+
+ return 0;
+}
+
struct ib_ah *ehca_create_ah(struct ib_pd *pd, struct ib_ah_attr *ah_attr)
{
int ret;
@@ -69,15 +101,13 @@ struct ib_ah *ehca_create_ah(struct ib_pd *pd, struct ib_ah_attr *ah_attr)
av->av.slid_path_bits = ah_attr->src_path_bits;
if (ehca_static_rate < 0) {
- int ah_mult = ib_rate_to_mult(ah_attr->static_rate);
- int ehca_mult =
- ib_rate_to_mult(shca->sport[ah_attr->port_num].rate );
-
- if (ah_mult >= ehca_mult)
- av->av.ipd = 0;
- else
- av->av.ipd = (ah_mult > 0) ?
- ((ehca_mult - 1) / ah_mult) : 0;
+ u32 ipd;
+ if (ehca_calc_ipd(shca, ah_attr->port_num,
+ ah_attr->static_rate, &ipd)) {
+ ret = -EINVAL;
+ goto create_ah_exit1;
+ }
+ av->av.ipd = ipd;
} else
av->av.ipd = ehca_static_rate;
diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h b/drivers/infiniband/hw/ehca/ehca_classes.h
index 2d660ae..87f12d4 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -95,7 +95,6 @@ struct ehca_sma_attr {
struct ehca_sport {
struct ib_cq *ibcq_aqp1;
struct ib_qp *ibqp_aqp1;
- enum ib_rate rate;
enum ib_port_state port_state;
struct ehca_sma_attr saved_attr;
};
diff --git a/drivers/infiniband/hw/ehca/ehca_iverbs.h b/drivers/infiniband/hw/ehca/ehca_iverbs.h
index dce503b..5485799 100644
--- a/drivers/infiniband/hw/ehca/ehca_iverbs.h
+++ b/drivers/infiniband/hw/ehca/ehca_iverbs.h
@@ -189,6 +189,9 @@ int ehca_mmap(struct ib_ucontext *context, struct vm_area_struct *vma);
void ehca_poll_eqs(unsigned long data);
+int ehca_calc_ipd(struct ehca_shca *shca, int port,
+ enum ib_rate path_rate, u32 *ipd);
+
#ifdef CONFIG_PPC_64K_PAGES
void *ehca_alloc_fw_ctrlblock(gfp_t flags);
void ehca_free_fw_ctrlblock(void *ptr);
diff --git a/drivers/infiniband/hw/ehca/ehca_main.c b/drivers/infiniband/hw/ehca/ehca_main.c
index c6cd38c..90d4334 100644
--- a/drivers/infiniband/hw/ehca/ehca_main.c
+++ b/drivers/infiniband/hw/ehca/ehca_main.c
@@ -327,9 +327,6 @@ static int ehca_sense_attributes(struct ehca_shca *shca)
shca->hw_level = ehca_hw_level;
ehca_gen_dbg(" ... hardware level=%x", shca->hw_level);
- shca->sport[0].rate = IB_RATE_30_GBPS;
- shca->sport[1].rate = IB_RATE_30_GBPS;
-
shca->hca_cap = rblock->hca_cap_indicators;
ehca_gen_dbg(" ... HCA capabilities:");
for (i = 0; i < ARRAY_SIZE(hca_cap_descr); i++)
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c b/drivers/infiniband/hw/ehca/ehca_qp.c
index de18264..2e3e654 100644
--- a/drivers/infiniband/hw/ehca/ehca_qp.c
+++ b/drivers/infiniband/hw/ehca/ehca_qp.c
@@ -1196,10 +1196,6 @@ static int internal_modify_qp(struct ib_qp *ibqp,
update_mask |= EHCA_BMASK_SET(MQPCB_MASK_QKEY, 1);
}
if (attr_mask & IB_QP_AV) {
- int ah_mult = ib_rate_to_mult(attr->ah_attr.static_rate);
- int ehca_mult = ib_rate_to_mult(shca->sport[my_qp->
- init_attr.port_num].rate);
-
mqpcb->dlid = attr->ah_attr.dlid;
update_mask |= EHCA_BMASK_SET(MQPCB_MASK_DLID, 1);
mqpcb->source_path_bits = attr->ah_attr.src_path_bits;
@@ -1207,11 +1203,12 @@ static int internal_modify_qp(struct ib_qp *ibqp,
mqpcb->service_level = attr->ah_attr.sl;
update_mask |= EHCA_BMASK_SET(MQPCB_MASK_SERVICE_LEVEL, 1);
- if (ah_mult < ehca_mult)
- mqpcb->max_static_rate = (ah_mult > 0) ?
- ((ehca_mult - 1) / ah_mult) : 0;
- else
- mqpcb->max_static_rate = 0;
+ if (ehca_calc_ipd(shca, my_qp->init_attr.port_num,
+ attr->ah_attr.static_rate,
+ &mqpcb->max_static_rate)) {
+ ret = -EINVAL;
+ goto modify_qp_exit2;
+ }
update_mask |= EHCA_BMASK_SET(MQPCB_MASK_MAX_STATIC_RATE, 1);
/*
@@ -1280,10 +1277,6 @@ static int internal_modify_qp(struct ib_qp *ibqp,
(MQPCB_MASK_RDMA_ATOMIC_OUTST_DEST_QP, 1);
}
if (attr_mask & IB_QP_ALT_PATH) {
- int ah_mult = ib_rate_to_mult(attr->alt_ah_attr.static_rate);
- int ehca_mult = ib_rate_to_mult(
- shca->sport[my_qp->init_attr.port_num].rate);
-
if (attr->alt_port_num < 1
|| attr->alt_port_num > shca->num_ports) {
ret = -EINVAL;
@@ -1309,10 +1302,12 @@ static int internal_modify_qp(struct ib_qp *ibqp,
mqpcb->source_path_bits_al = attr->alt_ah_attr.src_path_bits;
mqpcb->service_level_al = attr->alt_ah_attr.sl;
- if (ah_mult > 0 && ah_mult < ehca_mult)
- mqpcb->max_static_rate_al = (ehca_mult - 1) / ah_mult;
- else
- mqpcb->max_static_rate_al = 0;
+ if (ehca_calc_ipd(shca, my_qp->init_attr.port_num,
+ attr->alt_ah_attr.static_rate,
+ &mqpcb->max_static_rate_al)) {
+ ret = -EINVAL;
+ goto modify_qp_exit2;
+ }
/* OpenIB doesn't support alternate retry counts - copy them */
mqpcb->retry_count_al = mqpcb->retry_count;
--
1.5.2
^ permalink raw reply related
* Re: The question about the fail at the begin of linux on MPC8360E.
From: Timur Tabi @ 2007-11-02 13:54 UTC (permalink / raw)
To: ??; +Cc: linuxppc-embedded
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E270174CCE3@az33exm24.fsl.freescale.net>
Medve Emilian-EMMEDVE1 wrote:
> Hi there,
>
>
> You need a device tree. The defaut one is arch/powerpc/boot/dts/mpc836x_mds.dts. You need the DTC (Device Tree Compiler) from here http://jdl.com/git_repos/?p=dtc.git;a=summary. This should be enough to give you some reading pointers.
And if your U-Boot doesn't support device trees, you'll need to enable cuImage
support in the kernel as well.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: serial GDBServer PPC405 problems
From: khollan @ 2007-11-02 14:37 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200711020944.53077.wangbj@lzu.edu.cn>
Wang, Baojun wrote:
>
>
>
> Your kernel don't have kgdb support? then you need a debugger like bdi2000
> to
> debug the kernel.
>
> Wang
>
>
Do I need to add kgdb even if I just want to debug a user application over
serial?
--
View this message in context: http://www.nabble.com/serial-GDBServer-PPC405--problems-tf4732593.html#a13548781
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: serial GDBServer PPC405 problems
From: Grant Likely @ 2007-11-02 14:57 UTC (permalink / raw)
To: khollan; +Cc: linuxppc-embedded
In-Reply-To: <13548781.post@talk.nabble.com>
On 11/2/07, khollan <khollan@daktronics.com> wrote:
>
>
> Wang, Baojun wrote:
> >
> >
> >
> > Your kernel don't have kgdb support? then you need a debugger like bdi2000
> > to
> > debug the kernel.
> >
> > Wang
> >
> >
> Do I need to add kgdb even if I just want to debug a user application over
> serial?
No you don't. gdbserver is the right tool.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 3/3] Add arch-specific walk_memory_remove() for ppc64
From: Badari Pulavarty @ 2007-11-02 15:57 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-mm, anton, linuxppc-dev, Paul Mackerras, Andrew Morton,
KAMEZAWA Hiroyuki
In-Reply-To: <1193999530.25744.3.camel@johannes.berg>
On Fri, 2007-11-02 at 10:32 +0000, Johannes Berg wrote:
> > This patch provides a way for an architecture to provide its
> > own walk_memory_resource()
>
> It seems that the patch description "walk_memory_remove()" is wrong?
>
Yep. Patch title is wrong.
Thanks,
Badari
^ permalink raw reply
* [PATCH] dtc: Fix the install target
From: Emil Medve @ 2007-11-02 15:26 UTC (permalink / raw)
To: jdl, linuxppc-dev; +Cc: Emil Medve
/usr/bin/install: cannot stat `fdt.h': No such file or directory
/usr/bin/install: cannot stat `libfdt.h': No such file or directory
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
---
Makefile | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index 84f0efe..d59554a 100644
--- a/Makefile
+++ b/Makefile
@@ -56,7 +56,7 @@ install: all
$(INSTALL) -d $(DESTDIR)$(LIBDIR)
$(INSTALL) -m 644 $(LIBFDT_LIB) $(DESTDIR)$(LIBDIR)
$(INSTALL) -d $(DESTDIR)$(INCLUDEDIR)
- $(INSTALL) -m 644 $(LIBFDT_INCLUDES) $(DESTDIR)$(INCLUDEDIR)
+ $(INSTALL) -m 644 $(addprefix $(LIBFDT_srcdir)/,$(LIBFDT_INCLUDES)) $(DESTDIR)$(INCLUDEDIR)
#
# Rules for versioning
@@ -136,17 +136,17 @@ endif
#
LIBFDT_objdir = libfdt
LIBFDT_srcdir = libfdt
-include libfdt/Makefile.libfdt
+include $(LIBFDT_srcdir)/Makefile.libfdt
.PHONY: libfdt
libfdt: $(LIBFDT_LIB)
-$(LIBFDT_LIB): $(addprefix libfdt/,$(LIBFDT_OBJS))
+$(LIBFDT_LIB): $(addprefix $(LIBFDT_objdir)/,$(LIBFDT_OBJS))
libfdt_clean:
@$(VECHO) CLEAN "(libfdt)"
- rm -f $(addprefix libfdt/,$(STD_CLEANFILES))
- rm -f $(addprefix libfdt/,$(LIBFDT_CLEANFILES))
+ rm -f $(addprefix $(LIBFDT_objdir)/,$(STD_CLEANFILES))
+ rm -f $(addprefix $(LIBFDT_objdir)/,$(LIBFDT_CLEANFILES))
ifneq ($(DEPTARGETS),)
-include $(LIBFDT_OBJS:%.o=$(LIBFDT_objdir)/%.d)
--
1.5.3.GIT
^ permalink raw reply related
* Re: [PATCH] net: Add 405EX support to new EMAC driver
From: Olof Johansson @ 2007-11-02 16:03 UTC (permalink / raw)
To: Stefan Roese; +Cc: netdev, linuxppc-dev
In-Reply-To: <200711020814.43524.sr@denx.de>
On Fri, Nov 02, 2007 at 08:14:43AM +0100, Stefan Roese wrote:
> This patch adds support for the 405EX to the new EMAC driver. Some as on
> AXON, the 405EX handles the MDIO via the RGMII bridge.
Hi,
This isn't feedback on your patch as much as on "new-emac" in general:
Isn't this the case where there should really be device tree properties
instead? If you had an "ibm,emac-has-axon-stacr" property in the device
node, then you don't have to modify the driver for every new board out
there. Same for the other device properties, of course.
I thought this was what having the device tree was all about. :(
-Olof
^ permalink raw reply
* Regarding Linux 2.4/2.6 for Virtex
From: ramkumarj Ramkumar @ 2007-11-02 16:45 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 579 bytes --]
Hi All,
I m new to Linux development on Xilinx Platform and have a basic query. From
where can I download Linux 2.4 Kernel source for Virtex ML-403/300. I tried
using linuxppc_2_4_devel and linuxppc-2.4 since they have the drivers
support already included. But it looks like a build breakage and the last
update shows 2005. It would be really helpful if some one could elaborate on
the source trees available as of today for Xilinx Dev or point some
references to same. I would appreciate if information regarding Linux Kernel
2.6 for Xilinx is also included.
Best Regards,
Ram
[-- Attachment #2: Type: text/html, Size: 648 bytes --]
^ permalink raw reply
* [PATCH] [ML403-AC97CR] Fix capture/periodic overrun bug.
From: Joachim Foerster @ 2007-11-02 17:52 UTC (permalink / raw)
To: linuxppc-embedded, alsa-devel
Cc: Takashi Iwai, Stephen Neuendorffer, Lorenz Kolb
Hi all,
this is a bug fix for my ALSA driver I posted in August. Since then I
hadn't the time to look at it, but some days ago I took some time and
found the reason why there are so many overruns while capturing.
Furthermore, this patch removes the one "heavy" printk for capture
debugging.
From: Joachim Foerster <JOFT@gmx.de>
We have to do fairly accurate counting of the minimal periods, instead
of being lazy and just setting the number to zero as soon as one period
elapses.
Signed-off-by: Joachim Foerster <JOFT@gmx.de>
---
sound/drivers/ml403-ac97cr.c | 6 ++----
sound/drivers/pcm-indirect2.c | 20 ++------------------
2 files changed, 4 insertions(+), 22 deletions(-)
diff --git a/sound/drivers/ml403-ac97cr.c b/sound/drivers/ml403-ac97cr.c
index 2636249..1b16a21 100644
--- a/sound/drivers/ml403-ac97cr.c
+++ b/sound/drivers/ml403-ac97cr.c
@@ -28,11 +28,9 @@
* accesses to a minimum, because after a variable amount of accesses, the AC97
* controller doesn't raise the register access finished bit anymore ...
*
- * - Capture support works - basically, but after ~30s (with rates > ~20kHz)
- * ALSA stops reading captured samples from the intermediate buffer and
- * therefore a overrun happens - ATM I don't know what's wrong.
- *
* - Playback support seems to be pretty stable - no issues here.
+ * - Capture support "works" now, too. Overruns don't happen any longer so often.
+ * But there might still be some ...
*/
#include <sound/driver.h>
diff --git a/sound/drivers/pcm-indirect2.c b/sound/drivers/pcm-indirect2.c
index a36215a..ef74a38 100644
--- a/sound/drivers/pcm-indirect2.c
+++ b/sound/drivers/pcm-indirect2.c
@@ -403,7 +403,7 @@ snd_pcm_indirect2_playback_interrupt(struct snd_pcm_substream *substream,
rec->min_multiple);
rec->mul_elapsed++;
#endif
- rec->min_periods = 0;
+ rec->min_periods = (rec->min_periods % rec->min_multiple);
snd_pcm_period_elapsed(substream);
}
}
@@ -568,24 +568,8 @@ snd_pcm_indirect2_capture_interrupt(struct snd_pcm_substream *substream,
rec->mul_elapsed_real += (rec->min_periods /
rec->min_multiple);
rec->mul_elapsed++;
-
- if (!(rec->mul_elapsed % 4)) {
- struct snd_pcm_runtime *runtime = substream->runtime;
- unsigned int appl_ptr =
- frames_to_bytes(runtime,
- (unsigned int)runtime->control->
- appl_ptr) % rec->sw_buffer_size;
- int diff = rec->sw_data - appl_ptr;
- if (diff < 0)
- diff += rec->sw_buffer_size;
- snd_printk(KERN_DEBUG
- "STAT: mul_elapsed: %d, sw_data: %u, "
- "appl_ptr (bytes): %u, diff: %d\n",
- rec->mul_elapsed, rec->sw_data, appl_ptr,
- diff);
- }
#endif
- rec->min_periods = 0;
+ rec->min_periods = (rec->min_periods % rec->min_multiple);
snd_pcm_period_elapsed(substream);
}
}
--
1.5.2.5
^ permalink raw reply related
* GDB bdi2000 and mpc85xx
From: Stuart Hodgson @ 2007-11-02 17:17 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am attempting to get Kernel debugging working on our mpc8541 based
board via a BDI2000. The various components in use are
kernel - 2.6.19.2
BDI firmware - 1.08
U-Boot - 1.2.0
ppc_85xx-gdb - from eldk4.1 (6.3.0.0-1.21_3rh)
Kernel is configured with `-g` in CFLAGS and not with CONFIG_BDI_SWITCH,
from the information I have read around the subject this seem to be
correct. I also have `MMU XLAT`, and `PTBASE 0xF0` set in by BDI
configuration file. The default value for XLAT of `0xc0000000` matches
the kernel our kernel config.
Steps that I done so far
1. Power on BDI
2. Power on the board
3. BDI> reset run
4. Enter u-boot environment to stop linux booting immediately.
5. BDI> HALT
6. BDI> BREAK HARD
7. BDI> BI 0xc025a51c (this is the address of start_kernel for my build)
8. BDI> GO
9. From U-boot prompt `bootm`, kernel is copied from flash and loading
begins
10. Kernel does not halt at start_kernel and continues to the login
If I attempt to break at an address later in the boot sequence, such as
qmx19_ata_input_data (this is the area that I am trying to investigate)
I get
- TARGET: core #0 has entered debug mode
So from here I attempt to connect to the BDI from gdb
linux> cd ~/linux-2.6.19.2
linux> ppc_85xx-gdb vmlimux
"
GNU gdb Red Hat Linux (6.3.0.0-1.21_3rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux".
The target architecture is set automatically (currently powerpc:603)
"
I noticed here that the last line does not match the e500 core I am
using, but there does not seem to a change if I change this using `set
architecture powerpc:e500`
(gdb) tar rem <bdi_ip>:2001
Remote debugging using <bdi_ip>:2001
0x00000000 in ?? ()
What I don't understand here is why 0x00000000 is shown as the address,
further on the BDI the following error is shown then the connection is made
"
*** MMU: address translation for 0x00000000 failed
*** MMU: address translation for 0xFFFFFFFC failed
*** MMU: address translation for 0x00000000 failed
*** MMU: address translation for 0xFFFFFFFC failed
"
If I then clear the breakpoint from the BDI
BDI> CI
I can then from gdb set breakpoints
(gdb) b qmx19_ata_input_data
Breakpoint 1 at 0xc014ecb4: file drivers/ide/ppc/qmx19-ide.c, line 139.
(gdb) c
Continuing.
And all seems well with resolving the symbol names and and source files.
When the breakpoint is hit next
"
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000 in ?? ()
(gdb) where
#0 0x00000000 in ?? ()
#1 0x00000000 in ?? ()
"
But as expected I can not do any debugging since the address's are not
being resolved by GDB/BDI. Trying to single step now results in gdb showing
(gdb) s
Cannot find bounds of current function
and BDI showing
*** MMU: address translation for 0x00000000 failed
*** MMU: address translation for 0xFFFFFFFC failed
So my problem would seem to be with address translation. If I ask the
BDI to translate the address for me it seems fine though
BDI> PHYS 0xc014ecb4
PHYS = 0x0_0014ecb4
So in summary is seem to me that there is a problem with the address
translation to from BDI GDB, most likely the result of a missing
configuration parameter or setting. I should also add that there there
is not an inherent problem with the build of Linux as it boots fine and
is operational but I would like to step though our CF card driver when
the kernel is loading.
I have seen a couple of similar questions asked regarding the mpc85xx
series but not any answers that have shed any light, by all accounts the
steps I have done would seem to just work for other people, such as the
BDI manual.
Does anyone have some insights into this.
thanks
Stuart Hodgson
^ permalink raw reply
* radeon boot "hot-crash"
From: Michael Buesch @ 2007-11-02 18:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Hi,
I'm wondering how we are finally going to fix my radeon
"hot-crash" issue.
Fact is, applying the patch below fixes the issue.
Though, I see that this is not the correct patch to fix it.
Other devices might need the register write which is removed here.
So what about the following:
We add a specialcase for the exact type (and revision and so on)
for my chip here.
How do find out what's my chiprevision?
What exactly should be checked for here, so that only this chip
is affected by the workaround?
Index: wireless-2.6/drivers/video/aty/radeon_i2c.c
===================================================================
--- wireless-2.6.orig/drivers/video/aty/radeon_i2c.c 2007-10-17 18:03:10.000000000 +0200
+++ wireless-2.6/drivers/video/aty/radeon_i2c.c 2007-10-17 18:18:52.000000000 +0200
@@ -137,13 +137,7 @@ void radeon_delete_i2c_busses(struct rad
int radeon_probe_i2c_connector(struct radeonfb_info *rinfo, int conn,
u8 **out_edid)
{
- u32 reg = rinfo->i2c[conn-1].ddc_reg;
- u8 *edid;
-
- OUTREG(reg, INREG(reg) &
- ~(VGA_DDC_DATA_OUTPUT | VGA_DDC_CLK_OUTPUT));
-
- edid = fb_ddc_read(&rinfo->i2c[conn-1].adapter);
+ u8 *edid = fb_ddc_read(&rinfo->i2c[conn-1].adapter);
if (out_edid)
*out_edid = edid;
--
Greetings Michael.
^ permalink raw reply
* Re: [PATCH] using mii-bitbang on different processor ports
From: Scott Wood @ 2007-10-30 16:32 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-dev
In-Reply-To: <1193760559.6244.25.camel@p60635-ste.ids.de>
On Tue, Oct 30, 2007 at 05:09:19PM +0100, Sergej Stepanov wrote:
> The patch makes possible to have mdio and mdc pins on different physical ports
> also for CONFIG_PPC_CPM_NEW_BINDING.
> To setup it in the device tree:
> reg = <10d40 14 10d60 14>; // mdc-offset: 0x10d40, mdio-offset: 0x10d60
> or
> reg = <10d40 14>; // mdc and mdio have the same offset 0x10d40
> The approach was taken from older version.
There are some formatting issues in fs_mii_bitbang_init(), but otherwise it
looks good. It'll need to be sent to Jeff Garzik and the netdev list, not
just linuxppc-dev, though.
Also, please update Documentation/powerpc/booting-without-of.txt (probably
in a separate patch, since that one would go through Paul).
> @@ -142,13 +146,27 @@ static int __devinit fs_mii_bitbang_init(struct mii_bus *bus,
> return -ENODEV;
> mdc_pin = *data;
>
> - bitbang->dir = ioremap(res.start, res.end - res.start + 1);
> - if (!bitbang->dir)
> + bitbang->mdc.dir = ioremap(res[0].start, res[0].end - res[0].start + 1);
> + if (!bitbang->mdc.dir)
> return -ENOMEM;
>
> - bitbang->dat = bitbang->dir + 4;
> - bitbang->mdio_msk = 1 << (31 - mdio_pin);
> - bitbang->mdc_msk = 1 << (31 - mdc_pin);
> + bitbang->mdc.dat = bitbang->mdc.dir + 4;
> + if( !of_address_to_resource(np, 1, &res[1]))
Space before the '(', not after. A newline after the previous line would be
nice, too.
> + {
Brace at the end of the previous line.
> + bitbang->mdio.dir = ioremap(res[1].start, res[1].end - res[1].start + 1);
> + if (!bitbang->mdio.dir)
> + {
Likewise.
You could just use of_iomap() for the second one, since we don't need
the physical address for bus->id.
> + iounmap(bitbang->mdc.dir);
> + return -ENOMEM;
Please use the goto-style error handling that's used elsewhere in the
function.
> + }
> + bitbang->mdio.dat = bitbang->mdio.dir + 4;
> + }
> + else{
} else {
> out_unmap_regs:
> - iounmap(bitbang->dir);
> + if ( bitbang->mdio.dir != bitbang->mdc.dir)
> + iounmap(bitbang->mdio.dir);
> + iounmap(bitbang->mdc.dir);
> out_free_bus:
> kfree(new_bus);
> out_free_priv:
> @@ -238,7 +258,9 @@ static int fs_enet_mdio_remove(struct of_device *ofdev)
> free_mdio_bitbang(bus);
> dev_set_drvdata(&ofdev->dev, NULL);
> kfree(bus->irq);
> - iounmap(bitbang->dir);
> + if ( bitbang->mdio.dir != bitbang->mdc.dir)
> + iounmap(bitbang->mdio.dir);
> + iounmap(bitbang->mdc.dir);
> kfree(bitbang);
> kfree(bus);
"if (bitbang", not "if ( bitbang".
-Scott
^ permalink raw reply
* Re: Regarding Linux 2.4/2.6 for Virtex
From: Grant Likely @ 2007-11-02 19:08 UTC (permalink / raw)
To: ramkumarj Ramkumar; +Cc: linuxppc-embedded
In-Reply-To: <4f8c3030711020945p7ca1280nb9bc9db10d8df081@mail.gmail.com>
On 11/2/07, ramkumarj Ramkumar <ramkumarj2000@gmail.com> wrote:
>
>
> Hi All,
>
> I m new to Linux development on Xilinx Platform and have a basic query. From
> where can I download Linux 2.4 Kernel source for Virtex ML-403/300. I tried
> using linuxppc_2_4_devel and linuxppc-2.4 since they have the drivers
> support already included. But it looks like a build breakage and the last
> update shows 2005. It would be really helpful if some one could elaborate on
> the source trees available as of today for Xilinx Dev or point some
> references to same. I would appreciate if information regarding Linux Kernel
> 2.6 for Xilinx is also included.
I recommend going for a 2.6 kernel. The following link provides a bit
of information about it.
http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH 0/3] powerpc eeh: bug fixes for crashes, bad handling
From: Linas Vepstas @ 2007-11-02 20:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev
Hi Paul,
Please forward upstream the following three tiny patches
for EEH bugs, including on crash, and one failure to
reset correctly.
(I was planning on blasting you many many more patches,
involving MSI, but have had nothing but broken hardware
for the last few weeks, and so have nothing to show.
Dang, cause I needed the msi fixes for 2.6.24. Oh well.)
--linas
^ permalink raw reply
* [PATCH 1/3] powerpc eeh: cleanup comments
From: Linas Vepstas @ 2007-11-02 20:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev
In-Reply-To: <20071102201957.GU2183@austin.ibm.com>
Clean up commentary, remove dead code.
Signed-off-by Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh_driver.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
Index: linux-2.6.23-rc8-mm1/arch/powerpc/platforms/pseries/eeh_driver.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/arch/powerpc/platforms/pseries/eeh_driver.c 2007-10-16 11:39:18.000000000 -0500
+++ linux-2.6.23-rc8-mm1/arch/powerpc/platforms/pseries/eeh_driver.c 2007-10-16 11:46:30.000000000 -0500
@@ -113,9 +113,9 @@ static void eeh_report_error(struct pci_
/**
* eeh_report_mmio_enabled - tell drivers that MMIO has been enabled
*
- * Report an EEH error to each device driver, collect up and
- * merge the device driver responses. Cumulative response
- * passed back in "userdata".
+ * Tells each device driver that IO ports, MMIO and config space I/O
+ * are now enabled. Collects up and merges the device driver responses.
+ * Cumulative response passed back in "userdata".
*/
static void eeh_report_mmio_enabled(struct pci_dev *dev, void *userdata)
@@ -123,8 +123,6 @@ static void eeh_report_mmio_enabled(stru
enum pci_ers_result rc, *res = userdata;
struct pci_driver *driver = dev->driver;
- // dev->error_state = pci_channel_mmio_enabled;
-
if (!driver ||
!driver->err_handler ||
!driver->err_handler->mmio_enabled)
^ 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