* Re: [PATCH -V3 05/11] arch/powerpc: remove masking top 16 bit of va in tlb invalidate
From: Paul Mackerras @ 2012-07-23 3:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <1343006528.29855.25.camel@pasglop>
On Mon, Jul 23, 2012 at 11:22:08AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2012-07-23 at 09:56 +1000, Paul Mackerras wrote:
> > > That indicate we should not mask the top 16 bits. So remove the
> > same.
> >
> > Older versions of the architecture (2.02 and earler) require the
> > masking, so we can't just unconditionally remove it, since that would
> > potentially break POWER5 and PPC970. People are definitely still
> > running Linux bare-metal on PPC970s (though arguably not on POWER5).
>
> Are you sure ? I couldn't convince myself ... the old architectures say
> that it only uses some of the bits but it doesn't mark the other ones as
> "reserved" (as in must be 0).
>
> (At least 1.x, I haven't looked at 2.x with x < 03)
2.01 and 2.02 say bits 0..15 must be zero.
Paul.
^ permalink raw reply
* [PATCH] powerpc: Update g5_defconfig
From: Benjamin Herrenschmidt @ 2012-07-23 2:48 UTC (permalink / raw)
To: linuxppc-dev
This updates the g5 defconfig to include nouveau instead of nvidiafb
(which works much better nowadays, in fact the latter crashes on modern
distros), and to set CONFIG_VT_HW_CONSOLE_BINDING without which takeover
from the firmware offb by nouveau doesn't work properly (and leads to
unexplained black screens for some users).
The rest is churn of going through defconfig / savedefconfig
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig
index 07b7f2a..1513006 100644
--- a/arch/powerpc/configs/g5_defconfig
+++ b/arch/powerpc/configs/g5_defconfig
@@ -1,10 +1,8 @@
-CONFIG_PPC64=y
-CONFIG_ALTIVEC=y
-CONFIG_SMP=y
-CONFIG_NR_CPUS=4
CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_BLK_DEV_INITRD=y
@@ -15,16 +13,15 @@ CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
-# CONFIG_PPC_PSERIES is not set
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_MAC_PARTITION=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=4
+CONFIG_KEXEC=y
+# CONFIG_RELOCATABLE is not set
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
-CONFIG_CPU_FREQ_PMAC64=y
-CONFIG_NO_HZ=y
-CONFIG_HIGH_RES_TIMERS=y
-CONFIG_KEXEC=y
-CONFIG_IRQ_ALL_CPUS=y
-# CONFIG_MIGRATION is not set
CONFIG_PCI_MSI=y
CONFIG_NET=y
CONFIG_PACKET=y
@@ -52,7 +49,6 @@ CONFIG_NF_CT_NETLINK=m
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_IP_NF_QUEUE=m
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
-CONFIG_PROC_DEVICETREE=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=y
@@ -60,8 +56,6 @@ CONFIG_BLK_DEV_RAM_SIZE=65536
CONFIG_CDROM_PKTCDVD=m
CONFIG_IDE=y
CONFIG_BLK_DEV_IDECD=y
-CONFIG_BLK_DEV_IDE_PMAC=y
-CONFIG_BLK_DEV_IDE_PMAC_ATA100FIRST=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
CONFIG_BLK_DEV_SR=y
@@ -85,33 +79,24 @@ CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
-CONFIG_IEEE1394=y
-CONFIG_IEEE1394_OHCI1394=y
-CONFIG_IEEE1394_SBP2=m
-CONFIG_IEEE1394_ETH1394=m
-CONFIG_IEEE1394_RAWIO=y
-CONFIG_IEEE1394_VIDEO1394=m
-CONFIG_IEEE1394_DV1394=m
-CONFIG_ADB_PMU=y
-CONFIG_PMAC_SMU=y
+CONFIG_MACINTOSH_DRIVERS=y
CONFIG_MAC_EMUMOUSEBTN=y
-CONFIG_THERM_PM72=y
-CONFIG_WINDFARM=y
-CONFIG_WINDFARM_PM81=y
-CONFIG_WINDFARM_PM91=y
-CONFIG_WINDFARM_PM112=y
-CONFIG_WINDFARM_PM121=y
CONFIG_NETDEVICES=y
-CONFIG_DUMMY=m
CONFIG_BONDING=m
-CONFIG_TUN=m
-CONFIG_NET_ETHERNET=y
+CONFIG_DUMMY=m
CONFIG_MII=y
-CONFIG_SUNGEM=y
+CONFIG_TUN=m
CONFIG_ACENIC=m
CONFIG_ACENIC_OMIT_TIGON_I=y
-CONFIG_E1000=y
CONFIG_TIGON3=y
+CONFIG_E1000=y
+CONFIG_SUNGEM=y
+CONFIG_PPP=m
+CONFIG_PPP_BSDCOMP=m
+CONFIG_PPP_DEFLATE=m
+CONFIG_PPPOE=m
+CONFIG_PPP_ASYNC=m
+CONFIG_PPP_SYNC_TTY=m
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
@@ -121,36 +106,24 @@ CONFIG_USB_USBNET=m
# CONFIG_USB_NET_NET1080 is not set
# CONFIG_USB_NET_CDC_SUBSET is not set
# CONFIG_USB_NET_ZAURUS is not set
-CONFIG_PPP=m
-CONFIG_PPP_ASYNC=m
-CONFIG_PPP_SYNC_TTY=m
-CONFIG_PPP_DEFLATE=m
-CONFIG_PPP_BSDCOMP=m
-CONFIG_PPPOE=m
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_JOYDEV=m
CONFIG_INPUT_EVDEV=y
-# CONFIG_KEYBOARD_ATKBD is not set
# CONFIG_MOUSE_PS2 is not set
-# CONFIG_SERIO_I8042 is not set
# CONFIG_SERIO_SERPORT is not set
+CONFIG_VT_HW_CONSOLE_BINDING=y
# CONFIG_HW_RANDOM is not set
CONFIG_GEN_RTC=y
CONFIG_RAW_DRIVER=y
CONFIG_I2C_CHARDEV=y
# CONFIG_HWMON is not set
-CONFIG_AGP=m
-CONFIG_AGP_UNINORTH=m
+CONFIG_AGP=y
+CONFIG_DRM=y
+CONFIG_DRM_NOUVEAU=y
CONFIG_VIDEO_OUTPUT_CONTROL=m
-CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_TILEBLITTING=y
-CONFIG_FB_OF=y
-CONFIG_FB_NVIDIA=y
-CONFIG_FB_NVIDIA_I2C=y
CONFIG_FB_RADEON=y
-# CONFIG_VGA_CONSOLE is not set
-CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_LOGO=y
CONFIG_SOUND=m
CONFIG_SND=m
@@ -158,15 +131,7 @@ CONFIG_SND_SEQUENCER=m
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
-CONFIG_SND_POWERMAC=m
-CONFIG_SND_AOA=m
-CONFIG_SND_AOA_FABRIC_LAYOUT=m
-CONFIG_SND_AOA_ONYX=m
-CONFIG_SND_AOA_TAS=m
-CONFIG_SND_AOA_TOONIE=m
CONFIG_SND_USB_AUDIO=m
-CONFIG_HID_PID=y
-CONFIG_USB_HIDDEV=y
CONFIG_HID_GYRATION=y
CONFIG_LOGITECH_FF=y
CONFIG_HID_PANTHERLORD=y
@@ -174,13 +139,12 @@ CONFIG_HID_PETALYNX=y
CONFIG_HID_SAMSUNG=y
CONFIG_HID_SONY=y
CONFIG_HID_SUNPLUS=y
+CONFIG_HID_PID=y
+CONFIG_USB_HIDDEV=y
CONFIG_USB=y
-CONFIG_USB_DEVICEFS=y
CONFIG_USB_MON=y
CONFIG_USB_EHCI_HCD=y
-# CONFIG_USB_EHCI_HCD_PPC_OF is not set
CONFIG_USB_OHCI_HCD=y
-CONFIG_USB_OHCI_HCD_PPC_OF_BE=y
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=y
CONFIG_USB_STORAGE=y
@@ -244,8 +208,6 @@ CONFIG_REISERFS_FS_POSIX_ACL=y
CONFIG_REISERFS_FS_SECURITY=y
CONFIG_XFS_FS=m
CONFIG_XFS_POSIX_ACL=y
-CONFIG_INOTIFY=y
-CONFIG_AUTOFS_FS=m
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
@@ -259,14 +221,12 @@ CONFIG_HFS_FS=m
CONFIG_HFSPLUS_FS=m
CONFIG_CRAMFS=y
CONFIG_NFS_FS=y
-CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFSD=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
CONFIG_CIFS=m
-CONFIG_PARTITION_ADVANCED=y
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_1250=y
CONFIG_NLS_CODEPAGE_1251=y
@@ -274,29 +234,23 @@ CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_15=y
CONFIG_NLS_UTF8=y
-CONFIG_CRC_T10DIF=y
-CONFIG_LIBCRC32C=m
CONFIG_MAGIC_SYSRQ=y
+# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_MUTEXES=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
CONFIG_LATENCYTOP=y
-CONFIG_SYSCTL_SYSCALL_CHECK=y
-CONFIG_BOOTX_TEXT=y
+CONFIG_STRICT_DEVMEM=y
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_TEST=m
-CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_HMAC=y
-CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_ANUBIS=m
-CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
@@ -306,3 +260,6 @@ CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_TWOFISH=m
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_HW is not set
+# CONFIG_VIRTUALIZATION is not set
+CONFIG_CRC_T10DIF=y
+CONFIG_LIBCRC32C=m
^ permalink raw reply related
* Re: next/mmotm unbootable on G5: irqdomain
From: Benjamin Herrenschmidt @ 2012-07-23 2:45 UTC (permalink / raw)
To: Hugh Dickins
Cc: Stephen Rothwell, linux-kernel, Milton Miller, Paul Mundt,
Rob Herring, Andrew Morton, linuxppc-dev, Thomas Gleixner
In-Reply-To: <alpine.LSU.2.00.1207211911160.1585@eggly.anvils>
On Sat, 2012-07-21 at 19:47 -0700, Hugh Dickins wrote:
> I have to revert the patch below from mmotm 2012-07-20-16-30 or
> next-20120720 in order to boot on the PowerPC G5: otherwise it
> freezes before switching to the framebuffer console - but I'm
> not certain where because that initial console doesn't scroll
> (there are mpic messages at bottom and at top of screen, probably
> later messages at the top but I don't know the sequence).
This fixes it (Grant, how do we avoid bisection breakage here ? I can
put that in -powerpc and we can make sure that gets merged before your
tree ?)
powerpc/mpic: Create a revmap with enough entries for IPIs and timers
The current mpic code creates a linear revmap just big enough for all
the sources, which happens to miss the IPIs and timers on some machines.
This will in turn break when the irqdomain code loses the fallback of
doing a linear search when the revmap fails (and really slows down IPIs
otherwise).
This happens for example on the U4 based Apple machines such as the
dual core PowerMac G5s.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 906f29c..bfc6211 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1376,7 +1376,7 @@ struct mpic * __init mpic_alloc(struct device_node *node,
mpic->isu_mask = (1 << mpic->isu_shift) - 1;
mpic->irqhost = irq_domain_add_linear(mpic->node,
- last_irq + 1,
+ intvec_top,
&mpic_host_ops, mpic);
/*
^ permalink raw reply related
* Re: [PATCH] of: require a match on all fields of of_device_id
From: Rob Herring @ 2012-07-23 1:56 UTC (permalink / raw)
To: Scott Wood; +Cc: devicetree-discuss, Thierry Reding, linuxppc-dev
In-Reply-To: <5006DE87.7020503@freescale.com>
On 07/18/2012 11:04 AM, Scott Wood wrote:
> On 07/17/2012 09:38 PM, Rob Herring wrote:
>> On 07/17/2012 08:11 PM, Scott Wood wrote:
>>> Commit 107a84e61cdd3406c842a0e4be7efffd3a05dba6 ("of: match by compatible
>>> property first") breaks the gianfar ethernet driver found on various
>>> Freescale PPC chips.
>>
>> You do know this is reverted, right?
>
> No, I didn't. I got it via Kumar's next branch, and saw that it was
> still in your fixes-for-grant branch, and didn't see any revert-related
> e-mail activity on the devicetree-discuss list about it. I now see that
> it was reverted directly in Linus's tree (I didn't see either the
> original or the revert in Linus's tree when I checked, but apparently I
> hadn't fetched that as recently as I thought).
>
>> Here's my fix (untested) which is a bit simpler. I'm assuming if we care
>> about which compatible string we are matching to, then we require name
>> and type are blank and we only care about compatible strings.
>
> Any particular reason for making that assumption? We should be avoiding
> the need for .name or .type matching in new bindings, but this seems
> like unnecessarily inconsistent behavior.
Only to ensure we don't change existing behavior and I think trying to
cover all possibilities will be nearly impossible. For example, what if
we match on both a specific compatible prop alone and a less specific
compatible prop plus name and/or type. Which one do we pick as the
better match?
Rob
^ permalink raw reply
* Re: [PATCH -V3 05/11] arch/powerpc: remove masking top 16 bit of va in tlb invalidate
From: Benjamin Herrenschmidt @ 2012-07-23 1:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20120722235610.GE17790@bloggs.ozlabs.ibm.com>
On Mon, 2012-07-23 at 09:56 +1000, Paul Mackerras wrote:
> > That indicate we should not mask the top 16 bits. So remove the
> same.
>
> Older versions of the architecture (2.02 and earler) require the
> masking, so we can't just unconditionally remove it, since that would
> potentially break POWER5 and PPC970. People are definitely still
> running Linux bare-metal on PPC970s (though arguably not on POWER5).
Are you sure ? I couldn't convince myself ... the old architectures say
that it only uses some of the bits but it doesn't mark the other ones as
"reserved" (as in must be 0).
(At least 1.x, I haven't looked at 2.x with x < 03)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH -V3 10/11] arch/powerpc: Use 32bit array for slb cache
From: Paul Mackerras @ 2012-07-23 0:27 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <1341839621-28332-11-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Mon, Jul 09, 2012 at 06:43:40PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> With larger vsid we need to track more bits of ESID in slb cache
> for slb invalidate.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Minor comment below, but apart from that...
Reviewed-by: Paul Mackerras <paulus@samba.org>
> - sldi r11,r3,1 /* r11 = offset * sizeof(u16) */
> - rldicl r10,r10,36,28 /* get low 16 bits of the ESID */
> - add r11,r11,r13 /* r11 = (u16 *)paca + offset */
> - sth r10,PACASLBCACHE(r11) /* paca->slb_cache[offset] = esid */
> + sldi r11,r3,2 /* r11 = offset * sizeof(u32) */
> + rldicl r10,r10,36,28 /* get the 36 bits of the ESID */
You're correct that the rldicl instruction produces 36 bits of result,
and in fact it is equivalent to srdi r10,r10,28. If you're changing
the line you might as well change the instruction to the simpler form
too.
Paul.
^ permalink raw reply
* Re: [PATCH -V3 08/11] arch/powerpc: Make some of the PGTABLE_RANGE dependency explicit
From: Paul Mackerras @ 2012-07-23 0:20 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <1341839621-28332-9-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Mon, Jul 09, 2012 at 06:43:38PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> slice array size and slice mask size depend on PGTABLE_RANGE. We
> can't directly include pgtable.h in these header because there is
> a circular dependency. So add compile time check for these values.
Some comments below...
> struct slice_mask {
> u16 low_slices;
> /*
> - * This should be derived out of PGTABLE_RANGE. For the current
> - * max 64TB, u64 should be ok.
> + * We do this as a union so that we can verify
> + * SLICE_MASK_SIZE against PGTABLE_RANGE
> */
> - u64 high_slices;
> + union {
> + u64 high_slices;
> + unsigned char not_used[SLICE_MASK_SIZE];
> + };
Seems ugly to have to have a union just for that. Can't we do
something like BUILD_BUG_ON(sizeof(u64) < SLICE_MASK_SIZE) instead?
> @@ -73,7 +73,7 @@ static struct slice_mask slice_range_to_mask(unsigned long start,
> unsigned long len)
> {
> unsigned long end = start + len - 1;
> - struct slice_mask ret = { 0, 0 };
> + struct slice_mask ret = { 0, {0} };
Wouldn't { 0 } suffice? Similarly in several places below.
Paul.
^ permalink raw reply
* Re: [PATCH -V3 11/11] arch/powerpc: Add 64TB support
From: Paul Mackerras @ 2012-07-23 0:15 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <1341839621-28332-12-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Mon, Jul 09, 2012 at 06:43:41PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> Increase max addressable range to 64TB. This is not tested on
> real hardware yet.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/mmu-hash64.h | 8 ++++----
> arch/powerpc/include/asm/pgtable-ppc64-4k.h | 2 +-
> arch/powerpc/include/asm/pgtable-ppc64-64k.h | 2 +-
> arch/powerpc/include/asm/processor.h | 4 ++--
> arch/powerpc/include/asm/sparsemem.h | 4 ++--
> 5 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mmu-hash64.h b/arch/powerpc/include/asm/mmu-hash64.h
> index aa0d560..a227ba7 100644
> --- a/arch/powerpc/include/asm/mmu-hash64.h
> +++ b/arch/powerpc/include/asm/mmu-hash64.h
> @@ -374,16 +374,16 @@ extern void slb_set_size(u16 size);
> */
>
> #define VSID_MULTIPLIER_256M ASM_CONST(200730139) /* 28-bit prime */
> -#define VSID_BITS_256M 36
> +#define VSID_BITS_256M 38
> #define VSID_MODULUS_256M ((1UL<<VSID_BITS_256M)-1)
With these settings, the multiplication in ASM_VSID_SCRAMBLE could
overflow, leading to incorrect results (which would cause occasional
corruption of user processes under heavy load). You will need to
reduce the multiplier to be less than 2^26, and it will need to be
co-prime with 2^38 - 1. (Probably, the same value as we use in the 1T
case would be OK.)
Paul.
^ permalink raw reply
* Re: [PATCH -V3 09/11] arch/powerpc: Use 50 bits of VSID in slbmte
From: Paul Mackerras @ 2012-07-23 0:06 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <1341839621-28332-10-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Mon, Jul 09, 2012 at 06:43:39PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> Increase the number of valid VSID bits in slbmte instruction.
> We will use the new bits when we increase valid VSID bits.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
> arch/powerpc/mm/slb_low.S | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/mm/slb_low.S b/arch/powerpc/mm/slb_low.S
> index c355af6..c1fc81c 100644
> --- a/arch/powerpc/mm/slb_low.S
> +++ b/arch/powerpc/mm/slb_low.S
> @@ -226,7 +226,7 @@ _GLOBAL(slb_allocate_user)
> */
> slb_finish_load:
> ASM_VSID_SCRAMBLE(r10,r9,256M)
> - rldimi r11,r10,SLB_VSID_SHIFT,16 /* combine VSID and flags */
> + rldimi r11,r10,SLB_VSID_SHIFT,2 /* combine VSID and flags */
You can't do that without either changing ASM_VSID_SCRAMBLE or masking
the VSID it generates to 36 bits, since the logic in ASM_VSID_SCRAMBLE
can leave non-zero bits in the high 28 bits of the result. Similarly
for the 1T case.
Paul.
^ permalink raw reply
* Re: [PATCH -V3 07/11] arch/powerpc: Increase the slice range to 64TB
From: Paul Mackerras @ 2012-07-23 0:00 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <1341839621-28332-8-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Mon, Jul 09, 2012 at 06:43:37PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> This patch makes the high psizes mask as an unsigned char array
> so that we can have more than 16TB. Currently we support upto
> 64TB
Some comments inline...
> @@ -804,16 +804,19 @@ unsigned int hash_page_do_lazy_icache(unsigned int pp, pte_t pte, int trap)
> #ifdef CONFIG_PPC_MM_SLICES
> unsigned int get_paca_psize(unsigned long addr)
> {
> - unsigned long index, slices;
> + u64 lpsizes;
> + unsigned char *hpsizes;
> + unsigned long index, mask_index;
>
> if (addr < SLICE_LOW_TOP) {
> - slices = get_paca()->context.low_slices_psize;
> + lpsizes = get_paca()->context.low_slices_psize;
> index = GET_LOW_SLICE_INDEX(addr);
> - } else {
> - slices = get_paca()->context.high_slices_psize;
> - index = GET_HIGH_SLICE_INDEX(addr);
> + return (lpsizes >> (index * 4)) & 0xF;
> }
> - return (slices >> (index * 4)) & 0xF;
> + hpsizes = get_paca()->context.high_slices_psize;
> + index = GET_HIGH_SLICE_INDEX(addr) >> 1;
> + mask_index = GET_HIGH_SLICE_INDEX(addr) - (index << 1);
> + return (hpsizes[index] >> (mask_index * 4)) & 0xF;
The last 3 lines here feel awkward. How about:
> + index = GET_HIGH_SLICE_INDEX(addr);
> + mask_index = index & 1;
> + return (hpsizes[index >> 1] >> (mask_index * 4)) & 0xF;
> static struct slice_mask slice_mask_for_size(struct mm_struct *mm, int psize)
> {
> + unsigned char *hpsizes;
> + int index, mask_index;
> struct slice_mask ret = { 0, 0 };
> unsigned long i;
> - u64 psizes;
> + u64 lpsizes;
>
> - psizes = mm->context.low_slices_psize;
> + lpsizes = mm->context.low_slices_psize;
> for (i = 0; i < SLICE_NUM_LOW; i++)
> - if (((psizes >> (i * 4)) & 0xf) == psize)
> + if (((lpsizes >> (i * 4)) & 0xf) == psize)
> ret.low_slices |= 1u << i;
>
> - psizes = mm->context.high_slices_psize;
> - for (i = 0; i < SLICE_NUM_HIGH; i++)
> - if (((psizes >> (i * 4)) & 0xf) == psize)
> + hpsizes = mm->context.high_slices_psize;
> + for (i = 0; i < SLICE_NUM_HIGH; i++) {
> + index = i >> 1;
> + mask_index = i - (index << 1);
Again, seems like a complicated way to do mask_index = i & 1 (or
even i % 2, if you prefer, but then make i an unsigned type).
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc: SMT priority (PPR) save and restore
From: Michael Neuling @ 2012-07-22 23:57 UTC (permalink / raw)
To: Haren Myneni; +Cc: paulus, linuxppc-dev, anton
In-Reply-To: <14399.1342994689@neuling.org>
> > > Can you break this patch into a few parts that are easier to review than
> > > one giant patch. Start by adding the PPR ftr bits, then the extra space
> > > in the paca, then the new macros, then use the new infrastructure. I'm
> > > sure you can get 5 or so patches which will be much easier to review.
> > >
> > > Also this has been white space munged. See here:
> > > http://patchwork.ozlabs.org/patch/170993/
> > > All the #defines are broken.
> > >
> > > Also, do you know what the impacts of this are on null syscall/page
> > > faults etc on machines which need the PPR switched? If it's big, we
> > > might want to have this as a CONFIG option for those who don't care and
> > > want the speed bump.
> >
> > Thanks for your comments. Sure will split this patch in to 5/6 patches.
> > With Anton's num_syscall test -
> > http://ozlabs.org/~anton/junkcode/null_syscall.c, noticed 6% overhead.
> > As you suggested, will add CONFIG option for this feature.
>
> Eek.. 6%.. yes, definitely a CONFIG option then.
... maybe even a boot time option so we can turn it on and off easily
for distros.
Mikey
^ permalink raw reply
* Re: [PATCH -V3 06/11] arch/powerpc: Make KERN_VIRT_SIZE not dependend on PGTABLE_RANGE
From: Paul Mackerras @ 2012-07-22 23:57 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <1341839621-28332-7-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Mon, Jul 09, 2012 at 06:43:36PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> As we keep increasing PGTABLE_RANGE we need not increase the virual
> map area for kernel.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Reviewed-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH -V3 05/11] arch/powerpc: remove masking top 16 bit of va in tlb invalidate
From: Paul Mackerras @ 2012-07-22 23:56 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <1341839621-28332-6-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Mon, Jul 09, 2012 at 06:43:35PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> ISA doc doesn't talk about this. As per ISA doc for a 4K page
>
> tlbie RB RS
>
> " The Abbreviated Virtual Address (AVA) field in register RB must
> contain bits 14:65 of the virtual address translated by the TLB
> entry to be invalidated."
>
> That indicate we should not mask the top 16 bits. So remove the same.
Older versions of the architecture (2.02 and earler) require the
masking, so we can't just unconditionally remove it, since that would
potentially break POWER5 and PPC970. People are definitely still
running Linux bare-metal on PPC970s (though arguably not on POWER5).
Paul.
^ permalink raw reply
* Re: [PATCH -V3 04/11] arch/powerpc: Rename va to vpn
From: Paul Mackerras @ 2012-07-22 23:46 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <1341839621-28332-5-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Mon, Jul 09, 2012 at 06:43:34PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> Rename the variable to better reflect the values. No functional change
> in this patch.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
I think you missed a couple: kernel_map_linear_page and
kernel_unmap_linear_page are now broken since you change va to vpn in
the declaration but not in the uses, and you change host_va to
host_vpn in struct hpte_cache but don't fix up the use in
kvmppc_mmu_invalidate_pte. How many configs did you compile-test this
with?
Paul.
^ permalink raw reply
* Re: [PATCH -V3 03/11] arch/powerpc: Convert virtual address to vpn
From: Paul Mackerras @ 2012-07-22 23:42 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <1341839621-28332-4-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Mon, Jul 09, 2012 at 06:43:33PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> This patch convert different functions to take virtual page number
> instead of virtual address. Virtual page number is virtual address
> shifted right by VPN_SHIFT (12) bits. This enable us to have an
> address range of upto 76 bits.
Some comments inline below...
> +/*
> + * encode page number shift.
> + * Inorder to fit the 78 bit va in a 64 bit variable we shift the va by
^ "in order"
> + * 12 bits. This enable us to address upto 76 bit va.
^ "up to"
> + * For hpt hash from a va we can ignore the page size bits of va and for
> + * hpte encoding we ignore upto 23 bits of va. So ignoring lower 12 bits ensure
> + * we work in all cases including 4k page size.
> + */
> +#define VPN_SHIFT 12
This can't be more than 12 bits because we sometimes use 4k pages even
in a kernel configured for 64k pages (e.g. with the subpage_protection
system call).
> +static inline unsigned long hpte_encode_avpn(unsigned long vpn, int psize,
> + int ssize)
> +{
> + unsigned long v;
> + /*
> + * The AVA field omits the low-order 23 bits of the 78 bits VA.
> + * These bits are not needed in the PTE, because the
> + * low-order b of these bits are part of the byte offset
> + * into the virtual page and, if b < 23, the high-order
> + * 23-b of these bits are always used in selecting the
> + * PTEGs to be searched
> + */
> + BUG_ON(VPN_SHIFT > 23);
I don't think we need this. If VPN_SHIFT was computed by some complex
expression whose value is not obvious, then BUG_ON (or BUILD_BUG_ON)
would be appropriate, but since it's just a #define, a comment at the
site of the definition will suffice.
> static inline unsigned long hpt_hash(unsigned long va, unsigned int shift,
> int ssize)
> {
> + int mask;
> unsigned long hash, vsid;
>
> + BUG_ON(shift < VPN_SHIFT);
So VPN_SHIFT can be at most 12, since 12 is the smallest shift value
possible here.
> -static inline void __tlbiel(unsigned long va, int psize, int ssize)
> +static inline void __tlbiel(unsigned long vpn, int psize, int ssize)
> {
> + unsigned long va;
> unsigned int penc;
>
> + BUG_ON((77 - 65) > VPN_SHIFT);
> + va = vpn << VPN_SHIFT;
So VPN_SHIFT has to be at least 12. What is the significance of 77
and 65 here?
Paul.
^ permalink raw reply
* Re: [PATCH -V3 02/11] arch/powerpc: Simplify hpte_decode
From: Paul Mackerras @ 2012-07-22 23:26 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <1341839621-28332-3-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Mon, Jul 09, 2012 at 06:43:32PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> This patch simplify hpte_decode for easy switching of virtual address to
> virtual page number in the later patch
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
I'm not convinced your version is simpler than what was there before.
It's certainly longer now. But it does seem to do the same calculation
as before, so:
Reviewed-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH -V3 01/11] arch/powerpc: Use hpt_va to compute virtual address
From: Paul Mackerras @ 2012-07-22 23:17 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <1341839621-28332-2-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Mon, Jul 09, 2012 at 06:43:31PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> Don't open code the same
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Reviewed-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH] powerpc: SMT priority (PPR) save and restore
From: Michael Neuling @ 2012-07-22 22:04 UTC (permalink / raw)
To: Haren Myneni; +Cc: paulus, linuxppc-dev, anton
In-Reply-To: <1342863499.28370.41.camel@hbabu-laptop>
Haren Myneni <haren@linux.vnet.ibm.com> wrote:
> On Mon, 2012-07-16 at 13:41 +1000, Michael Neuling wrote:
> > Heaven Myneni <haren@linux.vnet.ibm.com> wrote:
> >
> > > powerpc: SMT priority (PPR) save and restore
<snip>
> > Can you break this patch into a few parts that are easier to review than
> > one giant patch. Start by adding the PPR ftr bits, then the extra space
> > in the paca, then the new macros, then use the new infrastructure. I'm
> > sure you can get 5 or so patches which will be much easier to review.
> >
> > Also this has been white space munged. See here:
> > http://patchwork.ozlabs.org/patch/170993/
> > All the #defines are broken.
> >
> > Also, do you know what the impacts of this are on null syscall/page
> > faults etc on machines which need the PPR switched? If it's big, we
> > might want to have this as a CONFIG option for those who don't care and
> > want the speed bump.
>
> Thanks for your comments. Sure will split this patch in to 5/6 patches.
> With Anton's num_syscall test -
> http://ozlabs.org/~anton/junkcode/null_syscall.c, noticed 6% overhead.
> As you suggested, will add CONFIG option for this feature.
Eek.. 6%.. yes, definitely a CONFIG option then.
> Sorry, my e-mail client messed-up some tabs. will post next time
> properly.
>
> Please see my responses below.
ok
> > > +
> > > #define __EXCEPTION_PROLOG_1(area, extra, vec) \
> > > GET_PACA(r13); \
> > > - std r9,area+EX_R9(r13); /* save r9 - r12 */ \
> > > - std r10,area+EX_R10(r13); \
> > > + std r9,area+EX_R9(r13); /* save r9 */ \
> > > + HMT_FTR_HAS_PPR(area,r9); \
> > > + std r10,area+EX_R10(r13); /* save r10 - r12 */ \
> > > BEGIN_FTR_SECTION_NESTED(66); \
> > > mfspr r10,SPRN_CFAR; \
> > > std r10,area+EX_CFAR(r13); \
> > > @@ -176,8 +213,10 @@ do_kvm_##n: \
> > > std r10,0(r1); /* make stack chain pointer */ \
> > > std r0,GPR0(r1); /* save r0 in stackframe */ \
> > > std r10,GPR1(r1); /* save r1 in stackframe */ \
> > > + beq 4f; \
> > > ACCOUNT_CPU_USER_ENTRY(r9, r10); \
> > > - std r2,GPR2(r1); /* save r2 in stackframe */ \
> > > + SAVE_PPR(area, r9, r10); \
> > > +4: std r2,GPR2(r1); /* save r2 in stackframe */ \
> >
> > why are we no longer doing ACCOUNT_CPU_USER_ENTRY here?
>
> No, we still doing ACCOUNT_CPU_USER_ENTRY for the user level exceptions.
> The existing code (ACCOUNT_CPU_USER_ENTRY macro) has the same branch
> instruction and skipping for exceptions coming from kernel. I just
> removed 'beq' in ACCOUNT_CPU_USER_ENTRY macro and added here since PPR
> saving will be done only for user level exceptions.
>
> Adding comment for this branch instruction and create a separate patch
> just for the related changes should make it more clear.
OK.
This is why it's good to split the patch into multiple parts so that you
can explain these in the associated checking comments.
> > > - HMT_MEDIUM;
> > > + HMT_FTR_NO_PPR
> >
> > Can we call this something else like HMT_MEDIUM_NO_PPR?
>
> I will make the change. Similarly HMT_FTR_HAS_PPR should be changed to
> HMT_MEDIUM_HAS_PPR.
Cool, bike shedding complete :-)
Mikey
>
>
> >
> >
> >
> > > SET_SCRATCH0(r13)
> > > #ifdef CONFIG_PPC_P7_NAP
> > > BEGIN_FTR_SECTION
> > > @@ -94,7 +94,7 @@ machine_check_pSeries_1:
> > > . = 0x300
> > > .globl data_access_pSeries
> > > data_access_pSeries:
> > > - HMT_MEDIUM
> > > + HMT_FTR_NO_PPR
> > > SET_SCRATCH0(r13)
> > > BEGIN_FTR_SECTION
> > > b data_access_check_stab
> > > @@ -106,7 +106,7 @@ END_MMU_FTR_SECTION_IFCLR(MMU_FTR_SLB)
> > > . = 0x380
> > > .globl data_access_slb_pSeries
> > > data_access_slb_pSeries:
> > > - HMT_MEDIUM
> > > + HMT_FTR_NO_PPR
> > > SET_SCRATCH0(r13)
> > > EXCEPTION_PROLOG_1(PACA_EXSLB, KVMTEST, 0x380)
> > > std r3,PACA_EXSLB+EX_R3(r13)
> > > @@ -137,7 +137,7 @@ data_access_slb_pSeries:
> > > . = 0x480
> > > .globl instruction_access_slb_pSeries
> > > instruction_access_slb_pSeries:
> > > - HMT_MEDIUM
> > > + HMT_FTR_NO_PPR
> > > SET_SCRATCH0(r13)
> > > EXCEPTION_PROLOG_1(PACA_EXSLB, KVMTEST_PR, 0x480)
> > > std r3,PACA_EXSLB+EX_R3(r13)
> > > @@ -197,7 +197,7 @@ hardware_interrupt_hv:
> > > . = 0xc00
> > > .globl system_call_pSeries
> > > system_call_pSeries:
> > > - HMT_MEDIUM
> > > + HMT_FTR_NO_PPR
> > > #ifdef CONFIG_KVM_BOOK3S_64_HANDLER
> > > SET_SCRATCH0(r13)
> > > GET_PACA(r13)
> > > @@ -213,6 +213,7 @@ BEGIN_FTR_SECTION
> > > END_FTR_SECTION_IFSET(CPU_FTR_REAL_LE)
> > > mr r9,r13
> > > GET_PACA(r13)
> > > + HMT_FTR_HAS_PPR(PACA_EXGEN,r10)
> > > mfspr r11,SPRN_SRR0
> > > mfspr r12,SPRN_SRR1
> > > ld r10,PACAKBASE(r13)
> > > @@ -295,7 +296,7 @@ vsx_unavailable_pSeries_1:
> > > machine_check_pSeries:
> > > .globl machine_check_fwnmi
> > > machine_check_fwnmi:
> > > - HMT_MEDIUM
> > > + HMT_FTR_NO_PPR
> > > SET_SCRATCH0(r13) /* save r13 */
> > > EXCEPTION_PROLOG_PSERIES(PACA_EXMC, machine_check_common,
> > > EXC_STD, KVMTEST, 0x200)
> > > @@ -417,7 +418,7 @@ _GLOBAL(__replay_interrupt)
> > > .globl system_reset_fwnmi
> > > .align 7
> > > system_reset_fwnmi:
> > > - HMT_MEDIUM
> > > + HMT_FTR_NO_PPR
> > > SET_SCRATCH0(r13) /* save r13 */
> > > EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, system_reset_common, EXC_STD,
> > > NOTEST, 0x100)
> > > @@ -717,7 +718,8 @@ _GLOBAL(slb_miss_realmode)
> > > mtcrf 0x80,r9
> > > mtcrf 0x01,r9 /* slb_allocate uses cr0 and cr7 */
> > > .machine pop
> > > -
> > > +
> >
> > Random whitespace change.
> >
> > > + RESTORE_PPR_PACA(PACA_EXSLB,r9)
> > > ld r9,PACA_EXSLB+EX_R9(r13)
> > > ld r10,PACA_EXSLB+EX_R10(r13)
> > > ld r11,PACA_EXSLB+EX_R11(r13)
> > > @@ -1048,7 +1050,7 @@ initial_stab:
> > >
> > > #ifdef CONFIG_PPC_POWERNV
> > > _GLOBAL(opal_mc_secondary_handler)
> > > - HMT_MEDIUM
> > > + HMT_FTR_NO_PPR
> > > SET_SCRATCH0(r13)
> > > GET_PACA(r13)
> > > clrldi r3,r3,2
> > >
> > >
> > > _______________________________________________
> > > Linuxppc-dev mailing list
> > > Linuxppc-dev@lists.ozlabs.org
> > > https://lists.ozlabs.org/listinfo/linuxppc-dev
> > >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
>
>
^ permalink raw reply
* Re: next/mmotm unbootable on G5: irqdomain
From: Hugh Dickins @ 2012-07-22 14:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, linux-kernel, Milton Miller, Paul Mundt,
Rob Herring, Andrew Morton, linuxppc-dev, Thomas Gleixner
In-Reply-To: <1342962554.29855.23.camel@pasglop>
On Sun, 22 Jul 2012, Benjamin Herrenschmidt wrote:
> On Sat, 2012-07-21 at 19:47 -0700, Hugh Dickins wrote:
> > I have to revert the patch below from mmotm 2012-07-20-16-30 or
> > next-20120720 in order to boot on the PowerPC G5: otherwise it
> > freezes before switching to the framebuffer console - but I'm
> > not certain where because that initial console doesn't scroll
> > (there are mpic messages at bottom and at top of screen, probably
> > later messages at the top but I don't know the sequence).
>
> Remind me your G5 variant ? (/proc/cpuinfo will do). I'll have a look
> tomorrow (and thanks for testing !).
>
> > commit 94f036a1f242f98cc30700b7676c07270a9c5c27
> > Author: Grant Likely <grant.likely@secretlab.ca>
> > Date: Sun Jun 3 22:04:39 2012 -0700
> >
> > irqdomain: eliminate slow-path revmap lookups
Thanks, Ben - here's my /proc/cpuinfo:
processor : 0
cpu : PPC970MP, altivec supported
clock : 2500.000000MHz
revision : 1.1 (pvr 0044 0101)
processor : 1
cpu : PPC970MP, altivec supported
clock : 2500.000000MHz
revision : 1.1 (pvr 0044 0101)
processor : 2
cpu : PPC970MP, altivec supported
clock : 2500.000000MHz
revision : 1.1 (pvr 0044 0101)
processor : 3
cpu : PPC970MP, altivec supported
clock : 2500.000000MHz
revision : 1.1 (pvr 0044 0101)
timebase : 33333333
platform : PowerMac
model : PowerMac11,2
machine : PowerMac11,2
motherboard : PowerMac11,2 MacRISC4 Power Macintosh
detected as : 337 (PowerMac G5 Dual Core)
pmac flags : 00000000
L2 cache : 1024K unified
pmac-generation : NewWorld
Hugh
^ permalink raw reply
* Re: next/mmotm unbootable on G5: irqdomain
From: Benjamin Herrenschmidt @ 2012-07-22 13:09 UTC (permalink / raw)
To: Hugh Dickins
Cc: Stephen Rothwell, linux-kernel, Milton Miller, Paul Mundt,
Rob Herring, Andrew Morton, linuxppc-dev, Thomas Gleixner
In-Reply-To: <alpine.LSU.2.00.1207211911160.1585@eggly.anvils>
On Sat, 2012-07-21 at 19:47 -0700, Hugh Dickins wrote:
> I have to revert the patch below from mmotm 2012-07-20-16-30 or
> next-20120720 in order to boot on the PowerPC G5: otherwise it
> freezes before switching to the framebuffer console - but I'm
> not certain where because that initial console doesn't scroll
> (there are mpic messages at bottom and at top of screen, probably
> later messages at the top but I don't know the sequence).
Remind me your G5 variant ? (/proc/cpuinfo will do). I'll have a look
tomorrow (and thanks for testing !).
Cheers,
Ben.
> Hugh
>
> commit 94f036a1f242f98cc30700b7676c07270a9c5c27
> Author: Grant Likely <grant.likely@secretlab.ca>
> Date: Sun Jun 3 22:04:39 2012 -0700
>
> irqdomain: eliminate slow-path revmap lookups
>
> With the current state of irq_domain, the reverse map is always updated
> when new IRQs get mapped. This means that the irq_find_mapping() function
> can be simplified to execute the revmap lookup functions unconditionally
>
> This patch adds lookup functions for the revmaps that don't yet have one
> and removes the slow path lookup code path.
>
> v8: Broke out unrelated changes into separate patches. Rebased on Paul's irq
> association patches.
> v7: Rebased to irqdomain/next for v3.4 and applied before the removal of 'hint'
> v6: Remove the slow path entirely. The only place where the slow path
> could get called is for a linear mapping if the hwirq number is larger
> than the linear revmap size. There shouldn't be any interrupt
> controllers that do that.
> v5: rewrite to not use a ->revmap() callback. It is simpler, smaller,
> safer and faster to open code each of the revmap lookups directly into
> irq_find_mapping() via a switch statement.
> v4: Fix build failure on incorrect variable reference.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Milton Miller <miltonm@bga.com>
> Cc: Paul Mundt <lethal@linux-sh.org>
> Cc: Rob Herring <rob.herring@calxeda.com>
>
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index c0e638b..a9b810e 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -686,16 +686,11 @@ EXPORT_SYMBOL_GPL(irq_dispose_mapping);
> * irq_find_mapping() - Find a linux irq from an hw irq number.
> * @domain: domain owning this hardware interrupt
> * @hwirq: hardware irq number in that domain space
> - *
> - * This is a slow path, for use by generic code. It's expected that an
> - * irq controller implementation directly calls the appropriate low level
> - * mapping function.
> */
> unsigned int irq_find_mapping(struct irq_domain *domain,
> irq_hw_number_t hwirq)
> {
> - unsigned int i;
> - unsigned int hint = hwirq % nr_irqs;
> + struct irq_data *data;
>
> /* Look for default domain if nececssary */
> if (domain == NULL)
> @@ -703,22 +698,27 @@ unsigned int irq_find_mapping(struct irq_domain *domain,
> if (domain == NULL)
> return 0;
>
> - /* legacy -> bail early */
> - if (domain->revmap_type == IRQ_DOMAIN_MAP_LEGACY)
> + switch (domain->revmap_type) {
> + case IRQ_DOMAIN_MAP_LEGACY:
> return irq_domain_legacy_revmap(domain, hwirq);
> -
> - /* Slow path does a linear search of the map */
> - if (hint == 0)
> - hint = 1;
> - i = hint;
> - do {
> - struct irq_data *data = irq_get_irq_data(i);
> + case IRQ_DOMAIN_MAP_LINEAR:
> + return irq_linear_revmap(domain, hwirq);
> + case IRQ_DOMAIN_MAP_TREE:
> + rcu_read_lock();
> + data = radix_tree_lookup(&domain->revmap_data.tree, hwirq);
> + rcu_read_unlock();
> + if (data)
> + return data->irq;
> + break;
> + case IRQ_DOMAIN_MAP_NOMAP:
> + data = irq_get_irq_data(hwirq);
> if (data && (data->domain == domain) && (data->hwirq == hwirq))
> - return i;
> - i++;
> - if (i >= nr_irqs)
> - i = 1;
> - } while(i != hint);
> + return hwirq;
> + break;
> + }
> +
> + WARN(1, "ERROR: irq revmap went horribly wrong. revmap_type=%i\n",
> + domain->revmap_type);
> return 0;
> }
> EXPORT_SYMBOL_GPL(irq_find_mapping);
> @@ -728,32 +728,19 @@ EXPORT_SYMBOL_GPL(irq_find_mapping);
> * @domain: domain owning this hardware interrupt
> * @hwirq: hardware irq number in that domain space
> *
> - * This is a fast path, for use by irq controller code that uses linear
> - * revmaps. It does fallback to the slow path if the revmap doesn't exist
> - * yet and will create the revmap entry with appropriate locking
> + * This is a fast path that can be called directly by irq controller code to
> + * save a handful of instructions.
> */
> unsigned int irq_linear_revmap(struct irq_domain *domain,
> irq_hw_number_t hwirq)
> {
> - unsigned int *revmap;
> + BUG_ON(domain->revmap_type != IRQ_DOMAIN_MAP_LINEAR);
>
> - if (WARN_ON_ONCE(domain->revmap_type != IRQ_DOMAIN_MAP_LINEAR))
> - return irq_find_mapping(domain, hwirq);
> -
> - /* Check revmap bounds */
> - if (unlikely(hwirq >= domain->revmap_data.linear.size))
> - return irq_find_mapping(domain, hwirq);
> -
> - /* Check if revmap was allocated */
> - revmap = domain->revmap_data.linear.revmap;
> - if (unlikely(revmap == NULL))
> - return irq_find_mapping(domain, hwirq);
> -
> - /* Fill up revmap with slow path if no mapping found */
> - if (unlikely(!revmap[hwirq]))
> - revmap[hwirq] = irq_find_mapping(domain, hwirq);
> + /* Check revmap bounds; complain if exceeded */
> + if (WARN_ON(hwirq >= domain->revmap_data.linear.size))
> + return 0;
>
> - return revmap[hwirq];
> + return domain->revmap_data.linear.revmap[hwirq];
> }
> EXPORT_SYMBOL_GPL(irq_linear_revmap);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* next/mmotm unbootable on G5: irqdomain
From: Hugh Dickins @ 2012-07-22 2:47 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Rothwell, linux-kernel, Milton Miller, Paul Mundt,
Rob Herring, Andrew Morton, linuxppc-dev, Thomas Gleixner
I have to revert the patch below from mmotm 2012-07-20-16-30 or
next-20120720 in order to boot on the PowerPC G5: otherwise it
freezes before switching to the framebuffer console - but I'm
not certain where because that initial console doesn't scroll
(there are mpic messages at bottom and at top of screen, probably
later messages at the top but I don't know the sequence).
Hugh
commit 94f036a1f242f98cc30700b7676c07270a9c5c27
Author: Grant Likely <grant.likely@secretlab.ca>
Date: Sun Jun 3 22:04:39 2012 -0700
irqdomain: eliminate slow-path revmap lookups
With the current state of irq_domain, the reverse map is always updated
when new IRQs get mapped. This means that the irq_find_mapping() function
can be simplified to execute the revmap lookup functions unconditionally
This patch adds lookup functions for the revmaps that don't yet have one
and removes the slow path lookup code path.
v8: Broke out unrelated changes into separate patches. Rebased on Paul's irq
association patches.
v7: Rebased to irqdomain/next for v3.4 and applied before the removal of 'hint'
v6: Remove the slow path entirely. The only place where the slow path
could get called is for a linear mapping if the hwirq number is larger
than the linear revmap size. There shouldn't be any interrupt
controllers that do that.
v5: rewrite to not use a ->revmap() callback. It is simpler, smaller,
safer and faster to open code each of the revmap lookups directly into
irq_find_mapping() via a switch statement.
v4: Fix build failure on incorrect variable reference.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Milton Miller <miltonm@bga.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Rob Herring <rob.herring@calxeda.com>
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index c0e638b..a9b810e 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -686,16 +686,11 @@ EXPORT_SYMBOL_GPL(irq_dispose_mapping);
* irq_find_mapping() - Find a linux irq from an hw irq number.
* @domain: domain owning this hardware interrupt
* @hwirq: hardware irq number in that domain space
- *
- * This is a slow path, for use by generic code. It's expected that an
- * irq controller implementation directly calls the appropriate low level
- * mapping function.
*/
unsigned int irq_find_mapping(struct irq_domain *domain,
irq_hw_number_t hwirq)
{
- unsigned int i;
- unsigned int hint = hwirq % nr_irqs;
+ struct irq_data *data;
/* Look for default domain if nececssary */
if (domain == NULL)
@@ -703,22 +698,27 @@ unsigned int irq_find_mapping(struct irq_domain *domain,
if (domain == NULL)
return 0;
- /* legacy -> bail early */
- if (domain->revmap_type == IRQ_DOMAIN_MAP_LEGACY)
+ switch (domain->revmap_type) {
+ case IRQ_DOMAIN_MAP_LEGACY:
return irq_domain_legacy_revmap(domain, hwirq);
-
- /* Slow path does a linear search of the map */
- if (hint == 0)
- hint = 1;
- i = hint;
- do {
- struct irq_data *data = irq_get_irq_data(i);
+ case IRQ_DOMAIN_MAP_LINEAR:
+ return irq_linear_revmap(domain, hwirq);
+ case IRQ_DOMAIN_MAP_TREE:
+ rcu_read_lock();
+ data = radix_tree_lookup(&domain->revmap_data.tree, hwirq);
+ rcu_read_unlock();
+ if (data)
+ return data->irq;
+ break;
+ case IRQ_DOMAIN_MAP_NOMAP:
+ data = irq_get_irq_data(hwirq);
if (data && (data->domain == domain) && (data->hwirq == hwirq))
- return i;
- i++;
- if (i >= nr_irqs)
- i = 1;
- } while(i != hint);
+ return hwirq;
+ break;
+ }
+
+ WARN(1, "ERROR: irq revmap went horribly wrong. revmap_type=%i\n",
+ domain->revmap_type);
return 0;
}
EXPORT_SYMBOL_GPL(irq_find_mapping);
@@ -728,32 +728,19 @@ EXPORT_SYMBOL_GPL(irq_find_mapping);
* @domain: domain owning this hardware interrupt
* @hwirq: hardware irq number in that domain space
*
- * This is a fast path, for use by irq controller code that uses linear
- * revmaps. It does fallback to the slow path if the revmap doesn't exist
- * yet and will create the revmap entry with appropriate locking
+ * This is a fast path that can be called directly by irq controller code to
+ * save a handful of instructions.
*/
unsigned int irq_linear_revmap(struct irq_domain *domain,
irq_hw_number_t hwirq)
{
- unsigned int *revmap;
+ BUG_ON(domain->revmap_type != IRQ_DOMAIN_MAP_LINEAR);
- if (WARN_ON_ONCE(domain->revmap_type != IRQ_DOMAIN_MAP_LINEAR))
- return irq_find_mapping(domain, hwirq);
-
- /* Check revmap bounds */
- if (unlikely(hwirq >= domain->revmap_data.linear.size))
- return irq_find_mapping(domain, hwirq);
-
- /* Check if revmap was allocated */
- revmap = domain->revmap_data.linear.revmap;
- if (unlikely(revmap == NULL))
- return irq_find_mapping(domain, hwirq);
-
- /* Fill up revmap with slow path if no mapping found */
- if (unlikely(!revmap[hwirq]))
- revmap[hwirq] = irq_find_mapping(domain, hwirq);
+ /* Check revmap bounds; complain if exceeded */
+ if (WARN_ON(hwirq >= domain->revmap_data.linear.size))
+ return 0;
- return revmap[hwirq];
+ return domain->revmap_data.linear.revmap[hwirq];
}
EXPORT_SYMBOL_GPL(irq_linear_revmap);
^ permalink raw reply related
* Re: mpc8xxx PCIe hotplug needs fixing, some clues ..
From: Joakim Tjernlund @ 2012-07-21 17:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: scottwood, linuxppc-dev
In-Reply-To: <EC6BFBB7-DF3B-402A-ACB6-51546C1B6CC9@kernel.crashing.org>
Kumar Gala <galak@kernel.crashing.org> wrote on 2012/07/20 20:53:10:
> From: Kumar Gala <galak@kernel.crashing.org>
> To: Joakim Tjernlund <joakim.tjernlund@transmode.se>,
> Cc: scottwood@freescale.com, linuxppc-dev@ozlabs.org
> Date: 2012/07/20 20:53
> Subject: Re: mpc8xxx PCIe hotplug needs fixing, some clues ..
>
>
> On Jul 20, 2012, at 2:17 AM, Joakim Tjernlund wrote:
>
> >
> > Hi Guys
> >
> > I see that you have been hacking Freescale PCI before so I send this to you(and the list)
> >
> > We are using PCIe(as RC) on P2010(basically a mpc85xx) and have PCI device that
> > started from user space (needs advance clock conf) so when linux boots there is
> > no device at all.
> > Trying to "hotplug" the device after it is enabled fails, no amount of recan/remove using
> > either fake or real hotplug makes a difference.
> >
> > I found the cause eventually but I can't fix it properly as I known almost nothing about PCI.
> > Cause:
> > indirect_pci.c:indirect_read_config() tests for if (hose->indirect_type & PPC_INDIRECT_TYPE_NO_PCIE_LINK)
> > and returns PCIBIOS_DEVICE_NOT_FOUND
> >
> > PPC_INDIRECT_TYPE_NO_PCIE_LINK get set by fsl_pci.c (look for fsl_pcie_check_link) but is never cleared.
> > Clearing it as appropriate makes a small difference. If you
> > remove the RC and do a few of rescan's then the device appears.
> >
> > Hacking some more, like so:
> >
> > int fsl_pcie_check_link(struct pci_controller *hose)
> > {
> > u32 val;
> >
> > early_read_config_dword(hose, 0, 0, PCIE_LTSSM, &val);
> > hose->indirect_type |= PPC_INDIRECT_TYPE_NO_PCIE_LINK;
> > if (val < PCIE_LTSSM_L0)
> > return 1;
> > hose->indirect_type &= ~PPC_INDIRECT_TYPE_NO_PCIE_LINK;
> > return 0;
> > }
> > and then using it carefully(it is easy to make linux hang) in indirect_read_config():
> > indirect_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
> > int len, u32 *val)
> > {
> > struct pci_controller *hose = pci_bus_to_host(bus);
> > volatile void __iomem *cfg_data;
> > u8 cfg_type = 0;
> > u32 bus_no, reg;
> >
> > if (hose->indirect_type & PPC_INDIRECT_TYPE_NO_PCIE_LINK) {
> > if (bus->number != hose->first_busno ||
> > devfn != 0) {
> > fsl_pcie_check_link(hose);
> > return PCIBIOS_DEVICE_NOT_FOUND;
> > }
> > }
> >
> > Now it works, just one rescan and the device appears!
> > This is a hack, I don't known what other trouble it can cause, I hope you can
> > sort this out.
>
Related, should not all those fsl quirks be __devinit instead of __init?
See this for motivation
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=85a053fa5f2d67ae5b2968305b16e8d2fe4cdf4d
Could quirk_fsl_pcie_header be moved to early fixup time? I recall some code, maybe is was hotplug,
complaining about not recognising the header because it executed before the header fixup.
Jocke
^ permalink raw reply
* Re: mpc8xxx PCIe hotplug needs fixing, some clues ..
From: Joakim Tjernlund @ 2012-07-21 16:11 UTC (permalink / raw)
To: Kumar Gala; +Cc: scottwood, linuxppc-dev
In-Reply-To: <EC6BFBB7-DF3B-402A-ACB6-51546C1B6CC9@kernel.crashing.org>
Kumar Gala <galak@kernel.crashing.org> wrote on 2012/07/20 20:53:10:
>
>
> On Jul 20, 2012, at 2:17 AM, Joakim Tjernlund wrote:
>
> >
> > Hi Guys
> >
> > I see that you have been hacking Freescale PCI before so I send this to you(and the list)
> >
> > We are using PCIe(as RC) on P2010(basically a mpc85xx) and have PCI device that
> > started from user space (needs advance clock conf) so when linux boots there is
> > no device at all.
> > Trying to "hotplug" the device after it is enabled fails, no amount of recan/remove using
> > either fake or real hotplug makes a difference.
> >
> > I found the cause eventually but I can't fix it properly as I known almost nothing about PCI.
> > Cause:
> > indirect_pci.c:indirect_read_config() tests for if (hose->indirect_type & PPC_INDIRECT_TYPE_NO_PCIE_LINK)
> > and returns PCIBIOS_DEVICE_NOT_FOUND
> >
> > PPC_INDIRECT_TYPE_NO_PCIE_LINK get set by fsl_pci.c (look for fsl_pcie_check_link) but is never cleared.
> > Clearing it as appropriate makes a small difference. If you
> > remove the RC and do a few of rescan's then the device appears.
> >
> > Hacking some more, like so:
> >
> > int fsl_pcie_check_link(struct pci_controller *hose)
> > {
> > u32 val;
> >
> > early_read_config_dword(hose, 0, 0, PCIE_LTSSM, &val);
> > hose->indirect_type |= PPC_INDIRECT_TYPE_NO_PCIE_LINK;
> > if (val < PCIE_LTSSM_L0)
> > return 1;
> > hose->indirect_type &= ~PPC_INDIRECT_TYPE_NO_PCIE_LINK;
> > return 0;
> > }
> > and then using it carefully(it is easy to make linux hang) in indirect_read_config():
> > indirect_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
> > int len, u32 *val)
> > {
> > struct pci_controller *hose = pci_bus_to_host(bus);
> > volatile void __iomem *cfg_data;
> > u8 cfg_type = 0;
> > u32 bus_no, reg;
> >
> > if (hose->indirect_type & PPC_INDIRECT_TYPE_NO_PCIE_LINK) {
> > if (bus->number != hose->first_busno ||
> > devfn != 0) {
> > fsl_pcie_check_link(hose);
> > return PCIBIOS_DEVICE_NOT_FOUND;
> > }
> > }
> >
> > Now it works, just one rescan and the device appears!
> > This is a hack, I don't known what other trouble it can cause, I hope you can
> > sort this out.
>
> How are you forcing the re-scan? We can see if we can add a re-check of the link state in that flow somewhere.
echo 1 > /sys/bus/pci/rescan
Why is that check important? Seems like some very ppc specific workaround for something.
>
> Can you do a dump_stack() or something to get a call chain?
here?
indirect_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
int len, u32 *val)
{
struct pci_controller *hose = pci_bus_to_host(bus);
volatile void __iomem *cfg_data;
u8 cfg_type = 0;
u32 bus_no, reg;
static int first_dump;
if (!first_dump) {
dump_stack();
first_dump = 1;
}
...
I am not at work and and my board needs a reset button press to recover :(
Furthermore, my vacation starts next week, not sure I can get it fixed soon enough
Jocke
^ permalink raw reply
* Re: [PATCH] powerpc: SMT priority (PPR) save and restore
From: Haren Myneni @ 2012-07-21 9:38 UTC (permalink / raw)
To: Michael Neuling; +Cc: paulus, linuxppc-dev, anton
In-Reply-To: <31198.1342410079@neuling.org>
On Mon, 2012-07-16 at 13:41 +1000, Michael Neuling wrote:
> Heaven Myneni <haren@linux.vnet.ibm.com> wrote:
>
> > powerpc: SMT priority (PPR) save and restore
> >
> > On P7 systems, users can define SMT priority levels 2,3 and 4 for
> > processes so that some can run higher priority than the other ones.
> > In the current kernel, the default priority is set to 4 which prohibits
> > processes to use higher priority. Also the kernel boosts the priority to
> > 4 during exception without saving the user defined priority values when
> > the task enters the kernel. So we will be loosing the process PPR value
> > and can not be restored it back when the task exits the kernel.
> >
> > This patch sets the default priority to 3 when tasks are created such
> > that users can use 4 for higher priority tasks. It also provides to save
> > and restore the user defined priorities for all tasks.
> >
> > When the task enters in to kernel space, the user defined priority (PPR)
> > will be saved in to PACA at the beginning of first level exception
> > vector and then copy from PACA to thread_info in second level vector.
> > PPR will be restored from thread_info before exits the kernel space.
> >
> > P7 temporarily raises the thread priority to higher level during
> > exception until the program executes HMT_* calls. But it will not modify
> > PPR register. So we saves PPR value whenever some register is available
> > to use and then calls HMT_MEDIUM to increase the priority. This feature
> > supports on P7 or later processors.
> >
> > Signed-off-by: Haren Myneni <hbabu@us.ibm.com>
>
> Can you break this patch into a few parts that are easier to review than
> one giant patch. Start by adding the PPR ftr bits, then the extra space
> in the paca, then the new macros, then use the new infrastructure. I'm
> sure you can get 5 or so patches which will be much easier to review.
>
> Also this has been white space munged. See here:
> http://patchwork.ozlabs.org/patch/170993/
> All the #defines are broken.
>
> Also, do you know what the impacts of this are on null syscall/page
> faults etc on machines which need the PPR switched? If it's big, we
> might want to have this as a CONFIG option for those who don't care and
> want the speed bump.
Thanks for your comments. Sure will split this patch in to 5/6 patches.
With Anton's num_syscall test -
http://ozlabs.org/~anton/junkcode/null_syscall.c, noticed 6% overhead.
As you suggested, will add CONFIG option for this feature.
Sorry, my e-mail client messed-up some tabs. will post next time
properly.
Please see my responses below.
> More comments below.
>
> >
> > diff --git a/arch/powerpc/include/asm/cputable.h
> > b/arch/powerpc/include/asm/cputable.h
> > index 50d82c8..e7b80d6 100644
> > --- a/arch/powerpc/include/asm/cputable.h
> > +++ b/arch/powerpc/include/asm/cputable.h
> > @@ -203,6 +203,7 @@ extern const char *powerpc_base_platform;
> > #define CPU_FTR_POPCNTD LONG_ASM_CONST(0x0800000000000000)
> > #define CPU_FTR_ICSWX LONG_ASM_CONST(0x1000000000000000)
> > #define CPU_FTR_VMX_COPY LONG_ASM_CONST(0x2000000000000000)
> > +#define CPU_FTR_HAS_PPR LONG_ASM_CONST(0x4000000000000000)
> >
> > #ifndef __ASSEMBLY__
> >
> > @@ -432,7 +433,8 @@ extern const char *powerpc_base_platform;
> > CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
> > CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_ASYM_SMT | \
> > CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD |
> > \
> > - CPU_FTR_ICSWX | CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY)
> > + CPU_FTR_ICSWX | CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY |
> > \
> > + CPU_FTR_HAS_PPR)
>
> Add CPU_FTR_HAS_PPR to CPU_FTRS_POSSIBLE as well.
CPU_FTRS_POWER7 is already defined to CPU_FTRS_POSSIBLE. So do we still
need CPU_FTR_HAS_PPR to CPU_FTRS_POSSIBLE?
#define CPU_FTRS_POSSIBLE \
(CPU_FTRS_POWER3 | CPU_FTRS_RS64 | CPU_FTRS_POWER4 |
\
CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | CPU_FTRS_POWER6 |
\
CPU_FTRS_POWER7 | CPU_FTRS_CELL | CPU_FTRS_PA6T |
\
CPU_FTR_VSX)
>
>
> > #define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
> > CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
> > CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
> > diff --git a/arch/powerpc/include/asm/exception-64s.h
> > b/arch/powerpc/include/asm/exception-64s.h
> > index d58fc4e..1fae8aa 100644
> > --- a/arch/powerpc/include/asm/exception-64s.h
> > +++ b/arch/powerpc/include/asm/exception-64s.h
> > @@ -47,6 +47,7 @@
> > #define EX_R3 64
> > #define EX_LR 72
> > #define EX_CFAR 80
> > +#define EX_PPR 88 /* SMT thread status register (priority) */
> >
> > /*
> > * We're short on space and time in the exception prolog, so we can't
> > @@ -61,10 +62,46 @@
> > #define EXC_HV H
> > #define EXC_STD
> >
> > +/*
> > + * PPR save/restore macros - Used only on P7 or later processors
> > + */
> > +#define SAVE_PPR(area, ra, rb)
> > \
> > +BEGIN_FTR_SECTION_NESTED(940)
> > \
> > + ld ra,area+EX_PPR(r13); /* Read PPR from paca */
> > \
> > + clrrdi rb,r1,THREAD_SHIFT; /* thread_info struct */
> > \
> > + std ra,TI_PPR(rb); /* Save PPR in thread_info */
> > \
> > +END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,CPU_FTR_HAS_PPR,940)
> > +
> > +#define RESTORE_PPR(ra,rb)
> > \
> > +BEGIN_FTR_SECTION_NESTED(941)
> > \
> > + clrrdi ra,r1,THREAD_SHIFT;
> > \
> > + ld rb,TI_PPR(ra); /* Read PPR from thread_info */
> > \
> > + mtspr SPRN_PPR,rb; /* Restore PPR */
> > \
> > +END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,CPU_FTR_HAS_PPR,941)
> > +
> > +#define RESTORE_PPR_PACA(area,ra)
> > \
> > +BEGIN_FTR_SECTION_NESTED(942)
> > \
> > + ld ra,area+EX_PPR(r13);
> > \
> > + mtspr SPRN_PPR,ra;
> > \
> > +END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,CPU_FTR_HAS_PPR,942)
> > +
> > +#define HMT_FTR_NO_PPR
> > \
> > +BEGIN_FTR_SECTION_NESTED(944) \
> > + HMT_MEDIUM;
> > \
> > +END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,0,944) /*non P7*/
> > +
> > +#define HMT_FTR_HAS_PPR(area, ra)
> > \
> > +BEGIN_FTR_SECTION_NESTED(943)
> > \
> > + mfspr ra,SPRN_PPR; /* Read PPR */
> > \
> > + std ra,area+EX_PPR(r13); /* Save PPR in paca */
> > \
> > + HMT_MEDIUM;
> > \
> > +END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,CPU_FTR_HAS_PPR,943) /* P7 */
>
> all munged.
>
>
>
> > +
> > #define __EXCEPTION_PROLOG_1(area, extra, vec) \
> > GET_PACA(r13); \
> > - std r9,area+EX_R9(r13); /* save r9 - r12 */ \
> > - std r10,area+EX_R10(r13); \
> > + std r9,area+EX_R9(r13); /* save r9 */ \
> > + HMT_FTR_HAS_PPR(area,r9); \
> > + std r10,area+EX_R10(r13); /* save r10 - r12 */ \
> > BEGIN_FTR_SECTION_NESTED(66); \
> > mfspr r10,SPRN_CFAR; \
> > std r10,area+EX_CFAR(r13); \
> > @@ -176,8 +213,10 @@ do_kvm_##n: \
> > std r10,0(r1); /* make stack chain pointer */ \
> > std r0,GPR0(r1); /* save r0 in stackframe */ \
> > std r10,GPR1(r1); /* save r1 in stackframe */ \
> > + beq 4f; \
> > ACCOUNT_CPU_USER_ENTRY(r9, r10); \
> > - std r2,GPR2(r1); /* save r2 in stackframe */ \
> > + SAVE_PPR(area, r9, r10); \
> > +4: std r2,GPR2(r1); /* save r2 in stackframe */ \
>
> why are we no longer doing ACCOUNT_CPU_USER_ENTRY here?
No, we still doing ACCOUNT_CPU_USER_ENTRY for the user level exceptions.
The existing code (ACCOUNT_CPU_USER_ENTRY macro) has the same branch
instruction and skipping for exceptions coming from kernel. I just
removed 'beq' in ACCOUNT_CPU_USER_ENTRY macro and added here since PPR
saving will be done only for user level exceptions.
Adding comment for this branch instruction and create a separate patch
just for the related changes should make it more clear.
>
>
>
> > SAVE_4GPRS(3, r1); /* save r3 - r6 in stackframe */ \
> > SAVE_2GPRS(7, r1); /* save r7, r8 in stackframe */ \
> > ld r9,area+EX_R9(r13); /* move r9, r10 to stackframe */ \
> > @@ -218,7 +257,7 @@ do_kvm_##n: \
> > . = loc; \
> > .globl label##_pSeries; \
> > label##_pSeries: \
> > - HMT_MEDIUM; \
> > + HMT_FTR_NO_PPR; \
> > SET_SCRATCH0(r13); /* save r13 */ \
> > EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, label##_common, \
> > EXC_STD, KVMTEST_PR, vec)
> > @@ -227,7 +266,7 @@ label##_pSeries: \
> > . = loc; \
> > .globl label##_hv; \
> > label##_hv: \
> > - HMT_MEDIUM; \
> > + HMT_FTR_NO_PPR; \
> > SET_SCRATCH0(r13); /* save r13 */ \
> > EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, label##_common, \
> > EXC_HV, KVMTEST, vec)
> > @@ -258,7 +297,7 @@ label##_hv: \
> > _SOFTEN_TEST(EXC_STD, vec)
> >
> > #define __MASKABLE_EXCEPTION_PSERIES(vec, label, h, extra) \
> > - HMT_MEDIUM; \
> > + HMT_FTR_NO_PPR; \
> > SET_SCRATCH0(r13); /* save r13 */ \
> > __EXCEPTION_PROLOG_1(PACA_EXGEN, extra, vec); \
> > EXCEPTION_PROLOG_PSERIES_1(label##_common, h);
> > diff --git a/arch/powerpc/include/asm/paca.h
> > b/arch/powerpc/include/asm/paca.h
> > index daf813f..d32b1e5 100644
> > --- a/arch/powerpc/include/asm/paca.h
> > +++ b/arch/powerpc/include/asm/paca.h
> > @@ -93,9 +93,9 @@ struct paca_struct {
> > * Now, starting in cacheline 2, the exception save areas
> > */
> > /* used for most interrupts/exceptions */
> > - u64 exgen[11] __attribute__((aligned(0x80)));
> > - u64 exmc[11]; /* used for machine checks */
> > - u64 exslb[11]; /* used for SLB/segment table misses
> > + u64 exgen[12] __attribute__((aligned(0x80)));
> > + u64 exmc[12]; /* used for machine checks */
> > + u64 exslb[12]; /* used for SLB/segment table misses
> > * on the linear mapping */
> > /* SLB related definitions */
> > u16 vmalloc_sllp;
> > diff --git a/arch/powerpc/include/asm/ppc_asm.h
> > b/arch/powerpc/include/asm/ppc_asm.h
> > index 1544420..b5437a2 100644
> > --- a/arch/powerpc/include/asm/ppc_asm.h
> > +++ b/arch/powerpc/include/asm/ppc_asm.h
> > @@ -30,7 +30,6 @@
> > #define ACCOUNT_STOLEN_TIME
> > #else
> > #define ACCOUNT_CPU_USER_ENTRY(ra, rb) \
> > - beq 2f; /* if from kernel mode */ \
> > MFTB(ra); /* get timebase */ \
> > ld rb,PACA_STARTTIME_USER(r13); \
> > std ra,PACA_STARTTIME(r13); \
> > @@ -38,7 +37,6 @@
> > ld ra,PACA_USER_TIME(r13); \
> > add ra,ra,rb; /* add on to user time */ \
> > std ra,PACA_USER_TIME(r13); \
> > -2:
>
> Why are you doing this?
As mentioned above, removing the branch instruction here and adding this
check before calling ACCOUNT_CPU_USER_ENTRY.
>
> >
> > #define ACCOUNT_CPU_USER_EXIT(ra, rb) \
> > MFTB(ra); /* get timebase */ \
> > diff --git a/arch/powerpc/include/asm/reg.h
> > b/arch/powerpc/include/asm/reg.h
> > index f0cb7f4..1e61116 100644
> > --- a/arch/powerpc/include/asm/reg.h
> > +++ b/arch/powerpc/include/asm/reg.h
> > @@ -284,6 +284,7 @@
> > #define SPRN_DBAT6U 0x23C /* Data BAT 6 Upper Register */
> > #define SPRN_DBAT7L 0x23F /* Data BAT 7 Lower Register */
> > #define SPRN_DBAT7U 0x23E /* Data BAT 7 Upper Register */
> > +#define SPRN_PPR 0x380 /* Local SMT Thread status resgiter */
>
> spelling mistake here
>
> >
> > #define SPRN_DEC 0x016 /* Decrement Register */
> > #define SPRN_DER 0x095 /* Debug Enable Regsiter */
> > diff --git a/arch/powerpc/include/asm/thread_info.h
> > b/arch/powerpc/include/asm/thread_info.h
> > index 68831e9..618e35c 100644
> > --- a/arch/powerpc/include/asm/thread_info.h
> > +++ b/arch/powerpc/include/asm/thread_info.h
> > @@ -40,10 +40,22 @@ struct thread_info {
> > struct restart_block restart_block;
> > unsigned long local_flags; /* private flags for thread */
> >
> > +#ifdef CONFIG_PPC64
> > + unsigned long ppr; /* SMT Thread status register */
> > +#endif
>
>
>
> > /* low level flags - has atomic operations done on it */
> > unsigned long flags ____cacheline_aligned_in_smp;
> > };
> >
> > +#ifdef CONFIG_PPC64
> > +/* Default SMT priority to (11- 13bits). */
> > +/* .ppr is Used to save/restore only on P7 or later */
> > +#define INIT_PPR \
> > + .ppr = (3ull << 50),
> > +#else
> > +#define INIT_PPR
> > +#endif
> > +
>
>
>
>
> > /*
> > * macros/functions for gaining access to the thread information
> > structure
> > */
> > @@ -56,6 +68,7 @@ struct thread_info {
> > .restart_block = { \
> > .fn = do_no_restart_syscall, \
> > }, \
> > + INIT_PPR \
> > .flags = 0, \
> > }
> >
> > diff --git a/arch/powerpc/kernel/asm-offsets.c
> > b/arch/powerpc/kernel/asm-offsets.c
> > index 52c7ad7..0b3a5fe 100644
> > --- a/arch/powerpc/kernel/asm-offsets.c
> > +++ b/arch/powerpc/kernel/asm-offsets.c
> > @@ -127,6 +127,7 @@ int main(void)
> > DEFINE(TI_CPU, offsetof(struct thread_info, cpu));
> >
> > #ifdef CONFIG_PPC64
> > + DEFINE(TI_PPR, offsetof(struct thread_info, ppr));
> > DEFINE(DCACHEL1LINESIZE, offsetof(struct ppc64_caches, dline_size));
> > DEFINE(DCACHEL1LOGLINESIZE, offsetof(struct ppc64_caches,
> > log_dline_size));
> > DEFINE(DCACHEL1LINESPERPAGE, offsetof(struct ppc64_caches,
> > dlines_per_page));
> > diff --git a/arch/powerpc/kernel/entry_64.S
> > b/arch/powerpc/kernel/entry_64.S
> > index 5971c85..671a3db 100644
> > --- a/arch/powerpc/kernel/entry_64.S
> > +++ b/arch/powerpc/kernel/entry_64.S
> > @@ -33,6 +33,7 @@
> > #include <asm/irqflags.h>
> > #include <asm/ftrace.h>
> > #include <asm/hw_irq.h>
> > +#include <asm/exception-64s.h> /* SAVE_PPR and RESTORE_PPR */
>
> No need for the comment here
>
> >
> > /*
> > * System calls.
> > @@ -62,8 +63,10 @@ system_call_common:
> > std r12,_MSR(r1)
> > std r0,GPR0(r1)
> > std r10,GPR1(r1)
> > + beq 2f
> > ACCOUNT_CPU_USER_ENTRY(r10, r11)
> > - std r2,GPR2(r1)
> > + SAVE_PPR(PACA_EXGEN, r10, r11)
> > +2: std r2,GPR2(r1)
>
> anyway, why are we skipping this code
ACCOUNT_CPU_USER_ENTRY is needed only for user level exceptions. As said
above, we are not changing the current behavior.
>
> > std r3,GPR3(r1)
> > mfcr r2
> > std r4,GPR4(r1)
> > @@ -228,6 +231,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_STCX_CHECKS_ADDRESS)
> >
> > beq- 1f
> > ACCOUNT_CPU_USER_EXIT(r11, r12)
> > + RESTORE_PPR(r11, r12)
> > ld r13,GPR13(r1) /* only restore r13 if returning to usermode */
> > 1: ld r2,GPR2(r1)
> > ld r1,GPR1(r1)
> > @@ -698,6 +702,7 @@ fast_exception_return:
> > andi. r0,r3,MSR_PR
> > beq 1f
> > ACCOUNT_CPU_USER_EXIT(r2, r4)
> > + RESTORE_PPR(r2, r4)
> > REST_GPR(13, r1)
> > 1:
> > mtspr SPRN_SRR1,r3
> > diff --git a/arch/powerpc/kernel/exceptions-64s.S
> > b/arch/powerpc/kernel/exceptions-64s.S
> > index 1c06d29..c3bddf8 100644
> > --- a/arch/powerpc/kernel/exceptions-64s.S
> > +++ b/arch/powerpc/kernel/exceptions-64s.S
> > @@ -40,7 +40,7 @@ __start_interrupts:
> >
> > .globl system_reset_pSeries;
> > system_reset_pSeries:
> > - HMT_MEDIUM;
> > + HMT_FTR_NO_PPR
>
> Can we call this something else like HMT_MEDIUM_NO_PPR?
I will make the change. Similarly HMT_FTR_HAS_PPR should be changed to
HMT_MEDIUM_HAS_PPR.
>
>
>
> > SET_SCRATCH0(r13)
> > #ifdef CONFIG_PPC_P7_NAP
> > BEGIN_FTR_SECTION
> > @@ -94,7 +94,7 @@ machine_check_pSeries_1:
> > . = 0x300
> > .globl data_access_pSeries
> > data_access_pSeries:
> > - HMT_MEDIUM
> > + HMT_FTR_NO_PPR
> > SET_SCRATCH0(r13)
> > BEGIN_FTR_SECTION
> > b data_access_check_stab
> > @@ -106,7 +106,7 @@ END_MMU_FTR_SECTION_IFCLR(MMU_FTR_SLB)
> > . = 0x380
> > .globl data_access_slb_pSeries
> > data_access_slb_pSeries:
> > - HMT_MEDIUM
> > + HMT_FTR_NO_PPR
> > SET_SCRATCH0(r13)
> > EXCEPTION_PROLOG_1(PACA_EXSLB, KVMTEST, 0x380)
> > std r3,PACA_EXSLB+EX_R3(r13)
> > @@ -137,7 +137,7 @@ data_access_slb_pSeries:
> > . = 0x480
> > .globl instruction_access_slb_pSeries
> > instruction_access_slb_pSeries:
> > - HMT_MEDIUM
> > + HMT_FTR_NO_PPR
> > SET_SCRATCH0(r13)
> > EXCEPTION_PROLOG_1(PACA_EXSLB, KVMTEST_PR, 0x480)
> > std r3,PACA_EXSLB+EX_R3(r13)
> > @@ -197,7 +197,7 @@ hardware_interrupt_hv:
> > . = 0xc00
> > .globl system_call_pSeries
> > system_call_pSeries:
> > - HMT_MEDIUM
> > + HMT_FTR_NO_PPR
> > #ifdef CONFIG_KVM_BOOK3S_64_HANDLER
> > SET_SCRATCH0(r13)
> > GET_PACA(r13)
> > @@ -213,6 +213,7 @@ BEGIN_FTR_SECTION
> > END_FTR_SECTION_IFSET(CPU_FTR_REAL_LE)
> > mr r9,r13
> > GET_PACA(r13)
> > + HMT_FTR_HAS_PPR(PACA_EXGEN,r10)
> > mfspr r11,SPRN_SRR0
> > mfspr r12,SPRN_SRR1
> > ld r10,PACAKBASE(r13)
> > @@ -295,7 +296,7 @@ vsx_unavailable_pSeries_1:
> > machine_check_pSeries:
> > .globl machine_check_fwnmi
> > machine_check_fwnmi:
> > - HMT_MEDIUM
> > + HMT_FTR_NO_PPR
> > SET_SCRATCH0(r13) /* save r13 */
> > EXCEPTION_PROLOG_PSERIES(PACA_EXMC, machine_check_common,
> > EXC_STD, KVMTEST, 0x200)
> > @@ -417,7 +418,7 @@ _GLOBAL(__replay_interrupt)
> > .globl system_reset_fwnmi
> > .align 7
> > system_reset_fwnmi:
> > - HMT_MEDIUM
> > + HMT_FTR_NO_PPR
> > SET_SCRATCH0(r13) /* save r13 */
> > EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, system_reset_common, EXC_STD,
> > NOTEST, 0x100)
> > @@ -717,7 +718,8 @@ _GLOBAL(slb_miss_realmode)
> > mtcrf 0x80,r9
> > mtcrf 0x01,r9 /* slb_allocate uses cr0 and cr7 */
> > .machine pop
> > -
> > +
>
> Random whitespace change.
>
> > + RESTORE_PPR_PACA(PACA_EXSLB,r9)
> > ld r9,PACA_EXSLB+EX_R9(r13)
> > ld r10,PACA_EXSLB+EX_R10(r13)
> > ld r11,PACA_EXSLB+EX_R11(r13)
> > @@ -1048,7 +1050,7 @@ initial_stab:
> >
> > #ifdef CONFIG_PPC_POWERNV
> > _GLOBAL(opal_mc_secondary_handler)
> > - HMT_MEDIUM
> > + HMT_FTR_NO_PPR
> > SET_SCRATCH0(r13)
> > GET_PACA(r13)
> > clrldi r3,r3,2
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* RE: [PATCH][upstream] TDM Framework
From: Aggrwal Poonam-B10812 @ 2012-07-21 9:20 UTC (permalink / raw)
To: Aggrwal Poonam-B10812, Josh Boyer, Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org, Singh Sandeep-B37400
In-Reply-To: <ACB6D0C0104CFF42A45A5D82A0DD4F3D079B37CA@039-SN2MPN1-013.039d.mgd.msft.net>
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+poonam.aggrwal=3Dfreescale.com@lists.ozlabs.org] On Behalf Of
> Aggrwal Poonam-B10812
> Sent: Saturday, July 21, 2012 1:07 PM
> To: Josh Boyer; Michael Ellerman
> Cc: linuxppc-dev@lists.ozlabs.org; Singh Sandeep-B37400
> Subject: RE: [PATCH][upstream] TDM Framework
>=20
>=20
>=20
> > -----Original Message-----
> > From: Josh Boyer [mailto:jwboyer@gmail.com]
> > Sent: Friday, July 20, 2012 6:57 PM
> > To: Michael Ellerman
> > Cc: Singh Sandeep-B37400; Aggrwal Poonam-B10812; linuxppc-
> > dev@lists.ozlabs.org
> > Subject: Re: [PATCH][upstream] TDM Framework
> >
> > On Fri, Jul 20, 2012 at 8:54 AM, Michael Ellerman
> > <michael@ellerman.id.au> wrote:
> > > On Fri, 2012-07-20 at 18:05 +0530, sandeep@freescale.com wrote:
> > >> From: Sandeep Singh <Sandeep@freescale.com>
> > >>
> > >> TDM Framework is an attempt to provide a platform independent layer
> > >> which can offer a standard interface for TDM access to different
> > client modules.
> > >> Beneath, the framework layer can house different types of TDM
> > >> drivers to handle various TDM devices, the hardware intricacies of
> > >> the devices being completely taken care by TDM drivers.
> > >
> > > TDM ?
> >
> > And here I was thinking I was the only one scratching his head. All I
> > could come up with was Time Division Multiplexing.
> >
> Sorry for that. TDM refers to Time Division Multiplexing. Actually the
> first version of this patch set also had a patch which documented TDM
> basics.
> We missed it this time.
>=20
> Will just send the TDM documentation patch also.
The documentation patch is at:
http://patchwork.ozlabs.org/patch/145857/
>=20
> Regards
> Poonam
>=20
> For your reference:
>=20
> > Protip: If you use an acronym a billion times in a patch, expand it at
> > least in one place.
> >
> > josh
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ 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