Re: [PATCH 1/5] sched: fix capacity calculations for SMT4
On Wed, 2010-06-02 at 04:22 +0530, Vaidyanathan Srinivasan wrote:
If the group were a core group, the total would be much higher and we'd
likely end up assigning 1 to each before we'd run out of capacity.
This is a tricky case because we are depending upon the
DIV_ROUND_CLOSEST to decide whether to flag capacity to 0 or 1. We
will not have any task movement until capacity is depleted to quite
low value due to RT task. Having a threshold to flag 0/1 instead of
DIV_ROUND_CLOSEST just like you have suggested in the power savings
case may help here as well to move tasks to other idle cores.
Right, well we could put the threshold higher than the 50%, say 90% or
so.
For power savings, we can lower the threshold and maybe use the maximal
individual cpu_power in the group to base 1 capacity from.
So, suppose the second example, where sibling0 has 50 and the others
have 294, you'd end up with a capacity distribution of: {0,1,1,1}.
One challenge here is that if RT tasks run on more that one thread in
this group, we will have slightly different cpu powers. Arranging
them from max to min and having a cutoff threshold should work.
Right, like the 90% above.
Should we keep the RT scaling as a separate entity along with
cpu_power to simplify these thresholds. Whenever we need to scale
group load with cpu power can take the product of cpu_power and
scale_rt_power but in these cases where we compute capacity, we can
mark a 0 or 1 just based on whether scale_rt_power was less than
SCHED_LOAD_SCALE or not. Alternatively we can keep cpu_power as
a product of all scaling factors as it is today but save the component
scale factors also like scale_rt_power() and arch_scale_freq_power()
so that it can be used in load balance decisions.
Right, so the question is, do we only care about RT or should capacity
reflect the full asymmetric MP case.
I don't quite see why RT is special from any of the other scale factors,
if someone pegged one core at half the frequency of the others you'd
still want it to get 0 capacity so that we only try to populate it on
overload.
Basically in power save balance we would give all threads a capacity
'1' unless the cpu_power was reduced due to RT task. Similarly in
the non-power save case, we can have flag 1,0,0,0 unless first thread
had a RT scaling during the last interval.
I am suggesting to distinguish the reduction is cpu_power due to
architectural (hardware DVFS) reasons from RT tasks so that it is easy
to decide if moving tasks to sibling thread or core can help or not.
For power savings such a special heuristic _might_ make sense.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PowerPC: Remove hardcoded BAT configuration of IMMR in CPM early debug console
Scott Wood wrote: On 06/02/2010 03:06 AM, Martyn Welch wrote: I think that's a more fundamental change to CPM early debug than I can handle right now. Is IMMRBASE on your board at some address that has a low likelihood of conflicting when treated as a kernel effective address? It's at 0x0f00, is seems ok, but then I'm not sure I fully understand kernel effective addresses. That overlaps userspace -- is the BAT cleared before userspace starts? To be honest, once I'd got the device booting past the early debug stage, I rebuilt the kernel without udbg in it... If you don't want to do the fixmap stuff, might want to at least just leave it at the current arbitrary effective address, which hasn't seemed to cause much trouble so far. Given that I've now switched udbg off in the kernel config, I really can't substantiate spending much more time on this. This patch was mainly to help others that maybe struggling to bring up Linux on a device with CPM serial. I'll try and get a revised patch out soon which keeps the current arbitrary effective address. Martyn But fixmap is the right way to do it. -Scott -- Martyn Welch (Principal Software Engineer) | Registered in England and GE Intelligent Platforms | Wales (3828642) at 100 T +44(0)127322748| Barbirolli Square, Manchester, E martyn.we...@ge.com| M2 3AB VAT:GB 927559189 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Adding a section to linux kernel
Hi, I am building a kernel module on linux-2.6.31 on a PowerPC architecture. While buildng the module i am including a static library given by the client. I am getting the below warning while building the module with the library: WARNING: /home/drivers/modules/module.o (.ghsinfo): unexpected non-allocatable section. Did you forget to use ax/aw in a .S file? Note that for example linux/init.h contains section definitions for use in .S files. The .ghsinfo section i havent used in my code. It is being used in the Library given by the client. Does anyone know how do i include a section (namely .ghsinfo) into the kernel to get rid of the above warning? Regards, Azhar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Anyone using PowerPC little-endian mode?
Currently the kernel supports processes running in little-endian mode on machines that have a little-endian mode (as opposed to an endian bit in the TLB entry like most embedded PowerPC processors do, which is a much better idea). Little-endian mode comes in two flavours: so-called PowerPC little-endian mode, which works by swizzling the bottom 3 bits of the address, and true little-endian mode, which actually swaps the order of the bytes read from or written to memory. The classic 32-bit processors (603, 604, 750, 74xx, and derivatives) implemented PowerPC little-endian mode, and I think some early 64-bit processors did also. POWER6 and POWER7 implement true little-endian mode. POWER4, PPC970 and POWER5 don't implement any little-endian mode. Is anyone actually using little-endian mode processes on processors that implement PowerPC little-endian mode? One of the ways that we could make the alignment interrupt handler go faster is by removing the code for address swizzling that we have in order to handle PowerPC little-endian mode. If nobody is actually using it, we should remove it and make the code simpler and faster. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Anyone using PowerPC little-endian mode?
On 06/03/2010 06:20 AM, Paul Mackerras wrote: Currently the kernel supports processes running in little-endian mode on machines that have a little-endian mode (as opposed to an endian bit in the TLB entry like most embedded PowerPC processors do, which is a much better idea). Little-endian mode comes in two flavours: so-called PowerPC little-endian mode, which works by swizzling the bottom 3 bits of the address, and true little-endian mode, which actually swaps the order of the bytes read from or written to memory. The classic 32-bit processors (603, 604, 750, 74xx, and derivatives) implemented PowerPC little-endian mode, and I think some early 64-bit processors did also. POWER6 and POWER7 implement true little-endian mode. POWER4, PPC970 and POWER5 don't implement any little-endian mode. Is anyone actually using little-endian mode processes on processors that implement PowerPC little-endian mode? One of the ways that we could make the alignment interrupt handler go faster is by removing the code for address swizzling that we have in order to handle PowerPC little-endian mode. If nobody is actually using it, we should remove it and make the code simpler and faster. I don't know about today, but my recollection is that the only use of little-endian mode on PowerPC was during the early days attempt to run Windows-NT. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: unconditionally enabled irq stacks
On Thu, 2010-06-03 at 10:24 +0200, Christoph Hellwig wrote: Irq stacks provide an essential protection from stack overflows through external interrupts, at the cost of two additionals stacks per CPU. Enable them unconditionally to simplify the kernel build and prevent people from accidentally disabling them. Since when did we worry about simplifying the kernel build? :) I'm thinking embedded folks might prefer the reduction in stack space, though I guess we'll let them speak for themselves. Perhaps it could depend on EMBEDDED? It's not like it's a lot of extra code. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Compilation error: KVM support for PowerPC book3s_64 processors
Hello! My hardware: Apple Power Mac G5 Late 2005 I've just compiled kernel 2.6.34 for Gentoo Linux. # ACCEPT_KEYWORDS=~ppc64 emerge -1 sys-kernel/gentoo-sources-2.6.34 I tried the KVM support for PowerPC book3s_64 processors just to see if what I could do with KVM on my Apple Power Mac G5 with IBM PowerPC 970MP processor. Apperently it isn't supported by this CPU. Or am I wrong? Anyway, I get errors that indicate this option requires some VSX support, which isn't supported by IBM POWER4+/PowerPC G5. I cannot post the complete error message right now, but maybe some of you can try it. Processor support --- [*] AltiVec Support [ ] VSX Support [*] Virtualization --- * KVM support for PowerPC book3s_64 processors Some maybe relevant .config options: CONFIG_PPC_BOOK3S_64=y CONFIG_PPC_BOOK3S=y CONFIG_POWER4_ONLY=y CONFIG_POWER4=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y … CONFIG_PPC_PMAC=y CONFIG_PPC_PMAC64=y … CONFIG_KVM_MMIO=y CONFIG_VIRTUALIZATION=y CONFIG_KVM=y CONFIG_KVM_BOOK3S_64_HANDLER=y CONFIG_KVM_BOOK3S_64=y Maybe I've got something wrong though… Or there are other dependencies, like CONFIG_VSX that are not met. Let me know if I can help to test something. Cheers, Andreas. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/5200: Update defconfigs
Signed-off-by: Grant Likely grant.lik...@secretlab.ca CC: linuxppc-dev@lists.ozlabs.org CC: Benjamin Herrenschmidt b...@kernel.crashing.org --- arch/powerpc/configs/52xx/cm5200_defconfig| 45 +++-- arch/powerpc/configs/52xx/lite5200b_defconfig | 109 + arch/powerpc/configs/52xx/motionpro_defconfig | 76 ++--- arch/powerpc/configs/52xx/pcm030_defconfig| 108 arch/powerpc/configs/52xx/tqm5200_defconfig | 75 ++--- arch/powerpc/configs/mpc5200_defconfig| 217 - 6 files changed, 421 insertions(+), 209 deletions(-) diff --git a/arch/powerpc/configs/52xx/cm5200_defconfig b/arch/powerpc/configs/52xx/cm5200_defconfig index 218d49b..70fdf88 100644 --- a/arch/powerpc/configs/52xx/cm5200_defconfig +++ b/arch/powerpc/configs/52xx/cm5200_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.34-rc1 -# Wed Mar 10 14:34:22 2010 +# Linux kernel version: 2.6.35-rc1 +# Thu Jun 3 08:28:02 2010 # # CONFIG_PPC64 is not set @@ -72,6 +72,7 @@ CONFIG_CONSTRUCTORS=y CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_CROSS_COMPILE= CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y @@ -144,6 +145,7 @@ CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y +CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_CLK=y CONFIG_HAVE_DMA_API_DEBUG=y @@ -308,6 +310,8 @@ CONFIG_ISA_DMA_API=y # Bus options # CONFIG_ZONE_DMA=y +# CONFIG_NEED_DMA_MAP_STATE is not set +CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_PPC_PCI_CHOICE=y # CONFIG_PCI is not set @@ -379,6 +383,7 @@ CONFIG_DEFAULT_TCP_CONG=cubic # CONFIG_RDS is not set # CONFIG_TIPC is not set # CONFIG_ATM is not set +# CONFIG_L2TP is not set # CONFIG_BRIDGE is not set # CONFIG_NET_DSA is not set # CONFIG_VLAN_8021Q is not set @@ -411,9 +416,14 @@ CONFIG_WIRELESS=y # # CFG80211 needs to be enabled for MAC80211 # + +# +# Some wireless drivers require a rate control algorithm +# # CONFIG_WIMAX is not set # CONFIG_RFKILL is not set # CONFIG_NET_9P is not set +# CONFIG_CAIF is not set # # Device Drivers @@ -451,6 +461,7 @@ CONFIG_MTD_BLOCK=y # CONFIG_INFTL is not set # CONFIG_RFD_FTL is not set # CONFIG_SSFDC is not set +# CONFIG_SM_FTL is not set # CONFIG_MTD_OOPS is not set # @@ -543,6 +554,7 @@ CONFIG_HAVE_IDE=y # # SCSI device support # +CONFIG_SCSI_MOD=y # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_DMA=y @@ -603,6 +615,7 @@ CONFIG_LXT_PHY=y # CONFIG_NATIONAL_PHY is not set # CONFIG_STE10XP is not set # CONFIG_LSI_ET1011C_PHY is not set +# CONFIG_MICREL_PHY is not set # CONFIG_FIXED_PHY is not set # CONFIG_MDIO_BITBANG is not set CONFIG_NET_ETHERNET=y @@ -640,6 +653,7 @@ CONFIG_WLAN=y # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set +# CONFIG_USB_IPHETH is not set # CONFIG_WAN is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set @@ -666,6 +680,7 @@ CONFIG_WLAN=y # CONFIG_VT is not set CONFIG_DEVKMEM=y # CONFIG_SERIAL_NONSTANDARD is not set +# CONFIG_N_GSM is not set # # Serial drivers @@ -683,6 +698,8 @@ CONFIG_SERIAL_MPC52xx_CONSOLE=y CONFIG_SERIAL_MPC52xx_CONSOLE_BAUD=57600 # CONFIG_SERIAL_TIMBERDALE is not set # CONFIG_SERIAL_GRLIB_GAISLER_APBUART is not set +# CONFIG_SERIAL_ALTERA_JTAGUART is not set +# CONFIG_SERIAL_ALTERA_UART is not set CONFIG_UNIX98_PTYS=y # CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set CONFIG_LEGACY_PTYS=y @@ -695,6 +712,7 @@ CONFIG_LEGACY_PTY_COUNT=256 # CONFIG_R3964 is not set # CONFIG_RAW_DRIVER is not set # CONFIG_TCG_TPM is not set +# CONFIG_RAMOOPS is not set CONFIG_I2C=y CONFIG_I2C_BOARDINFO=y CONFIG_I2C_COMPAT=y @@ -725,15 +743,9 @@ CONFIG_I2C_MPC=y # Other I2C/SMBus bus drivers # # CONFIG_I2C_PCA_PLATFORM is not set - -# -# Miscellaneous I2C Chip support -# -# CONFIG_SENSORS_TSL2550 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set -# CONFIG_I2C_DEBUG_CHIP is not set # CONFIG_SPI is not set # @@ -753,7 +765,6 @@ CONFIG_WATCHDOG=y # Watchdog Device Drivers # # CONFIG_SOFT_WATCHDOG is not set -# CONFIG_MAX63XX_WATCHDOG is not set # CONFIG_MPC5200_WDT is not set # @@ -766,15 +777,14 @@ CONFIG_SSB_POSSIBLE=y # Sonics Silicon Backplane # # CONFIG_SSB is not set - -# -# Multifunction device drivers -# +CONFIG_MFD_SUPPORT=y # CONFIG_MFD_CORE is not set # CONFIG_MFD_88PM860X is not set # CONFIG_MFD_SM501 is not set # CONFIG_HTC_PASIC3 is not set +# CONFIG_TPS6507X is not set # CONFIG_TWL4030_CORE is not set +# CONFIG_MFD_TC35892 is not set # CONFIG_MFD_TMIO is not set # CONFIG_PMIC_DA903X is not set # CONFIG_PMIC_ADP5520 is not set @@ -784,7 +794,7 @@ CONFIG_SSB_POSSIBLE=y # CONFIG_MFD_WM8350_I2C is not set # CONFIG_MFD_WM8994 is not set # CONFIG_MFD_PCF50633 is not set -#
[PATCH 1/1] [SCSI] ipr: fix resource path display and formatting
It was possible to overflow the buffer used to print out the formatted
version of the resource path. The fix is to limit the number of
bytes that get formatted.
This patch also updates the ipr_show_resource_path function to display the
resource address for devices that are attached to adapters that don't
support resource paths.
Signed-off-by: Wayne Boyer way...@linux.vnet.ibm.com
---
James, this patch needs to go into rc-fixes. It fixes an oops that is
currently being seen on Power.
---
drivers/scsi/ipr.c | 51 +--
drivers/scsi/ipr.h |5 +++--
2 files changed, 36 insertions(+), 20 deletions(-)
Index: b/drivers/scsi/ipr.c
===
--- a/drivers/scsi/ipr.c2010-05-26 16:01:22.0 -0700
+++ b/drivers/scsi/ipr.c2010-06-03 15:31:59.0 -0700
@@ -1129,20 +1129,22 @@ static int ipr_is_same_device(struct ipr
}
/**
- * ipr_format_resource_path - Format the resource path for printing.
+ * ipr_format_res_path - Format the resource path for printing.
* @res_path: resource path
* @buf: buffer
*
* Return value:
* pointer to buffer
**/
-static char *ipr_format_resource_path(u8 *res_path, char *buffer)
+static char *ipr_format_res_path(u8 *res_path, char *buffer, int len)
{
int i;
+ char *p = buffer;
- sprintf(buffer, %02X, res_path[0]);
- for (i=1; res_path[i] != 0xff; i++)
- sprintf(buffer, %s-%02X, buffer, res_path[i]);
+ res_path[0] = '\0';
+ p += snprintf(p, buffer + len - p, %02X, res_path[0]);
+ for (i = 1; res_path[i] != 0xff ((i * 3) len); i++)
+ p += snprintf(p, buffer + len - p, -%02X, res_path[i]);
return buffer;
}
@@ -1187,7 +1189,8 @@ static void ipr_update_res_entry(struct
if (res-sdev new_path)
sdev_printk(KERN_INFO, res-sdev, Resource path: %s\n,
- ipr_format_resource_path(res-res_path[0],
buffer[0]));
+ ipr_format_res_path(res-res_path, buffer,
+ sizeof(buffer)));
} else {
res-flags = cfgtew-u.cfgte-flags;
if (res-flags IPR_IS_IOA_RESOURCE)
@@ -1573,7 +1576,8 @@ static void ipr_log_sis64_config_error(s
ipr_err_separator;
ipr_err(Device %d : %s, i + 1,
-ipr_format_resource_path(dev_entry-res_path[0],
buffer[0]));
+ipr_format_res_path(dev_entry-res_path, buffer,
+sizeof(buffer)));
ipr_log_ext_vpd(dev_entry-vpd);
ipr_err(-New Device Information-\n);
@@ -1919,13 +1923,14 @@ static void ipr_log64_fabric_path(struct
ipr_hcam_err(hostrcb, %s %s: Resource Path=%s\n,
path_active_desc[i].desc,
path_state_desc[j].desc,
-
ipr_format_resource_path(fabric-res_path[0], buffer[0]));
+ipr_format_res_path(fabric-res_path,
buffer,
+sizeof(buffer)));
return;
}
}
ipr_err(Path state=%02X Resource Path=%s\n, path_state,
- ipr_format_resource_path(fabric-res_path[0], buffer[0]));
+ ipr_format_res_path(fabric-res_path, buffer, sizeof(buffer)));
}
static const struct {
@@ -2066,7 +2071,8 @@ static void ipr_log64_path_elem(struct i
ipr_hcam_err(hostrcb, %s %s: Resource Path=%s, Link
rate=%s, WWN=%08X%08X\n,
path_status_desc[j].desc,
path_type_desc[i].desc,
-
ipr_format_resource_path(cfg-res_path[0], buffer[0]),
+ipr_format_res_path(cfg-res_path, buffer,
+sizeof(buffer)),
link_rate[cfg-link_rate
IPR_PHY_LINK_RATE_MASK],
be32_to_cpu(cfg-wwid[0]),
be32_to_cpu(cfg-wwid[1]));
return;
@@ -2074,7 +2080,7 @@ static void ipr_log64_path_elem(struct i
}
ipr_hcam_err(hostrcb, Path element=%02X: Resource Path=%s, Link
rate=%s
WWN=%08X%08X\n, cfg-type_status,
-ipr_format_resource_path(cfg-res_path[0], buffer[0]),
+ipr_format_res_path(cfg-res_path, buffer, sizeof(buffer)),
link_rate[cfg-link_rate IPR_PHY_LINK_RATE_MASK],
be32_to_cpu(cfg-wwid[0]), be32_to_cpu(cfg-wwid[1]));
}
@@ -2139,7 +2145,7 @@ static void ipr_log_sis64_array_error(st
ipr_err(RAID %s Array Configuration: %s\n,
error-protection_level,
-
Re: [PATCH] powerpc/5200: Update defconfigs
On Thu, Jun 3, 2010 at 3:17 PM, Grant Likely grant.lik...@secretlab.ca wrote: Signed-off-by: Grant Likely grant.lik...@secretlab.ca CC: linuxppc-dev@lists.ozlabs.org CC: Benjamin Herrenschmidt b...@kernel.crashing.org --- ... and my timing is fantastic in light of the defconfig discussion going on on the LKML. :-) http://lkml.org/lkml/2010/6/2/472 g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/5200: Update defconfigs
It seems to me like what's confused in the defconfigs is two concepts: 1) The requirements of a platform (what options must be set and must not be set) 2) The guarantee that a particular config was known to work at some point in time. The first could allow you to drop 99% of the options (I think that this mainly what Linus objects to) The second is better handled with testing anyway (assuming that all of the unmentioned options are, in fact, unset) Steve -Original Message- From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org [mailto:linuxppc-dev- bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Grant Likely Sent: Thursday, June 03, 2010 4:13 PM To: grant.lik...@secretlab.ca Cc: linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] powerpc/5200: Update defconfigs On Thu, Jun 3, 2010 at 3:17 PM, Grant Likely grant.lik...@secretlab.ca wrote: Signed-off-by: Grant Likely grant.lik...@secretlab.ca CC: linuxppc-dev@lists.ozlabs.org CC: Benjamin Herrenschmidt b...@kernel.crashing.org --- ... and my timing is fantastic in light of the defconfig discussion going on on the LKML. :-) http://lkml.org/lkml/2010/6/2/472 g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/5200: Update defconfigs
On Thu, Jun 3, 2010 at 5:22 PM, Stephen Neuendorffer stephen.neuendorf...@xilinx.com wrote: It seems to me like what's confused in the defconfigs is two concepts: 1) The requirements of a platform (what options must be set and must not be set) 2) The guarantee that a particular config was known to work at some point in time. I can't speak for other maintainers; but #2 is not something I worry about w.r.t. defconfigs. That guarantee is pretty meaningless for anything but an exact version of the kernel tree. The first could allow you to drop 99% of the options (I think that this mainly what Linus objects to) That, and the fact that the current files are machine-generated as opposed to something written/edited/maintained by a human. The second is better handled with testing anyway (assuming that all of the unmentioned options are, in fact, unset) Yup. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] - PCI EEH pci_restore_state fix allowing for repeated adapter recovery per state save
Patch Overview:
The pci_restore_state API is shared by both power management code and Extended
Error Handling (EEH) code on Power. This patch adds an additional recovery
function to pci_restore_state API. The problem being addressed is that Power
Management semantics only allow the saved state of PCI device to be restored
once per save. With this patch, EEH is able to restore the saved state
each time a PCI error is detected, enabling recovery in the face of repeated
errors.
There was some discussion of renaming the existing and new functions to more
clearly break out unconditional restore from the default conditional one, but a
name change seemed a heavy-handed change to force on the 200+ current users.
Bit more detail:
PCI device drivers which support EEH/AER save their pci state once during
driver initialization and during EEH/AER error recovery, restore the
original saved state. What we found was that our pci driver code would
recover from the first EEH error and fail to recover on subsequent
EEH errors. This issue results from pci_restore_state() function
restoring the state during initialization on the first EEH error.
What this patch does is to provide the pci_force_restore_state() for use
by PCI drivers which support EEH/AER that require the original saved
state be restored each time an EEH/AER error is detected.
Signed-off by: Brad Peters bpet...@us.ibm.com
Signed-off by: Richard A Lary rl...@linux.vnet.ibm.com
--
Brad Peters
IBM
Linux on System-P Platform Serviceability Team Lead
bpet...@linux.vnet.ibm.com
-
diff -uNrp -X linux-2.6.34/Documentation/dontdiff
linux-2.6.34.orig/drivers/pci/pci.c linux-2.6.34/drivers/pci/pci.c
--- linux-2.6.34.orig/drivers/pci/pci.c 2010-05-16 14:17:36.0 -0700
+++ linux-2.6.34/drivers/pci/pci.c 2010-05-26 17:16:20.0 -0700
@@ -920,19 +920,11 @@ pci_save_state(struct pci_dev *dev)
return 0;
}
-/**
- * pci_restore_state - Restore the saved state of a PCI device
- * @dev: - PCI device that we're dealing with
- */
-int
-pci_restore_state(struct pci_dev *dev)
+static void __pci_restore_state(struct pci_dev *dev)
{
int i;
u32 val;
- if (!dev-state_saved)
- return 0;
-
/* PCI Express register must be restored first */
pci_restore_pcie_state(dev);
@@ -953,12 +945,44 @@ pci_restore_state(struct pci_dev *dev)
pci_restore_pcix_state(dev);
pci_restore_msi_state(dev);
pci_restore_iov_state(dev);
+}
+
+
+/**
+ * pci_restore_state - Restore the saved state of a PCI device
+ * only if dev-state_saved is not 0. Used by
+ * power management suspend/restore routines.
+ * @dev: - PCI device that we're dealing with
+ */
+int
+pci_restore_state(struct pci_dev *dev)
+{
+
+ if (!dev-state_saved)
+ return 0;
+
+ __pci_restore_state(dev);
dev-state_saved = false;
return 0;
}
+/**
+ * pci_force_restore_state - Restore the saved state of a PCI device
+ * even if dev-state_saved is 0. Used by
+ * EEH and AER PCI error recovery.
+ * @dev: - PCI device that we're dealing with
+ */
+int
+pci_force_restore_state(struct pci_dev *dev)
+{
+ __pci_restore_state(dev);
+
+ return 0;
+}
+
+
static int do_pci_enable_device(struct pci_dev *dev, int bars)
{
int err;
@@ -3039,6 +3063,7 @@ EXPORT_SYMBOL(pci_select_bars);
EXPORT_SYMBOL(pci_set_power_state);
EXPORT_SYMBOL(pci_save_state);
EXPORT_SYMBOL(pci_restore_state);
+EXPORT_SYMBOL(pci_force_restore_state);
EXPORT_SYMBOL(pci_pme_capable);
EXPORT_SYMBOL(pci_pme_active);
EXPORT_SYMBOL(pci_wake_from_d3);
diff -uNrp -X linux-2.6.34/Documentation/dontdiff
linux-2.6.34.orig/include/linux/pci.h linux-2.6.34/include/linux/pci.h
--- linux-2.6.34.orig/include/linux/pci.h 2010-05-16 14:17:36.0
-0700
+++ linux-2.6.34/include/linux/pci.h2010-05-26 17:16:21.0 -0700
@@ -792,6 +792,7 @@ size_t pci_get_rom_size(struct pci_dev *
/* Power management related routines */
int pci_save_state(struct pci_dev *dev);
int pci_restore_state(struct pci_dev *dev);
+int pci_force_restore_state(struct pci_dev *dev);
int __pci_complete_power_transition(struct pci_dev *dev, pci_power_t state);
int pci_set_power_state(struct pci_dev *dev, pci_power_t state);
pci_power_t pci_choose_state(struct pci_dev *dev, pm_message_t state);
@@ -1155,6 +1156,11 @@ static inline int pci_restore_state(stru
return 0;
}
+static inline int pci_force_restore_state(struct pci_dev *dev)
+{
+ return 0;
+}
+
static inline int pci_set_power_state(struct pci_dev *dev, pci_power_t state)
{
return 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
