[PATCH v4 1/5] PCI: pcibus address to resource converting take bus instead of dev
For allocating resource under bus path, we do not have dev to pass along,
and we only have bus to use instead.
-v2: drop pcibios_bus_addr_to_resource().
-v3: drop __* change requested by Bjorn.
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: linux-al...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: sparcli...@vger.kernel.org
Cc: linux-pcm...@lists.infradead.org
Cc: linux-s...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
---
arch/alpha/kernel/pci-sysfs.c | 4 ++--
arch/powerpc/kernel/pci-common.c| 4 ++--
arch/powerpc/kernel/pci_of_scan.c | 4 ++--
arch/sparc/kernel/pci.c | 6 +++---
drivers/pci/host-bridge.c | 24 +++-
drivers/pci/probe.c | 18 +-
drivers/pci/quirks.c| 2 +-
drivers/pci/rom.c | 2 +-
drivers/pci/setup-bus.c | 16
drivers/pci/setup-res.c | 2 +-
drivers/pcmcia/i82092.c | 2 +-
drivers/pcmcia/yenta_socket.c | 6 +++---
drivers/scsi/sym53c8xx_2/sym_glue.c | 5 +++--
drivers/video/arkfb.c | 2 +-
drivers/video/s3fb.c| 2 +-
drivers/video/vt8623fb.c| 2 +-
include/linux/pci.h | 4 ++--
17 files changed, 52 insertions(+), 53 deletions(-)
diff --git a/arch/alpha/kernel/pci-sysfs.c b/arch/alpha/kernel/pci-sysfs.c
index 2b183b0..99e8d47 100644
--- a/arch/alpha/kernel/pci-sysfs.c
+++ b/arch/alpha/kernel/pci-sysfs.c
@@ -83,7 +83,7 @@ static int pci_mmap_resource(struct kobject *kobj,
if (iomem_is_exclusive(res-start))
return -EINVAL;
- pcibios_resource_to_bus(pdev, bar, res);
+ pcibios_resource_to_bus(pdev-bus, bar, res);
vma-vm_pgoff += bar.start (PAGE_SHIFT - (sparse ? 5 : 0));
mmap_type = res-flags IORESOURCE_MEM ? pci_mmap_mem : pci_mmap_io;
@@ -139,7 +139,7 @@ static int sparse_mem_mmap_fits(struct pci_dev *pdev, int
num)
long dense_offset;
unsigned long sparse_size;
- pcibios_resource_to_bus(pdev, bar, pdev-resource[num]);
+ pcibios_resource_to_bus(pdev-bus, bar, pdev-resource[num]);
/* All core logic chips have 4G sparse address space, except
CIA which has 16G (see xxx_SPARSE_MEM and xxx_DENSE_MEM
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index a1e3e40..d9476c1 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -835,7 +835,7 @@ static void pcibios_fixup_resources(struct pci_dev *dev)
* at 0 as unset as well, except if PCI_PROBE_ONLY is also set
* since in that case, we don't want to re-assign anything
*/
- pcibios_resource_to_bus(dev, reg, res);
+ pcibios_resource_to_bus(dev-bus, reg, res);
if (pci_has_flag(PCI_REASSIGN_ALL_RSRC) ||
(reg.start == 0 !pci_has_flag(PCI_PROBE_ONLY))) {
/* Only print message if not re-assigning */
@@ -886,7 +886,7 @@ static int pcibios_uninitialized_bridge_resource(struct
pci_bus *bus,
/* Job is a bit different between memory and IO */
if (res-flags IORESOURCE_MEM) {
- pcibios_resource_to_bus(dev, region, res);
+ pcibios_resource_to_bus(dev-bus, region, res);
/* If the BAR is non-0 then it's probably been initialized */
if (region.start != 0)
diff --git a/arch/powerpc/kernel/pci_of_scan.c
b/arch/powerpc/kernel/pci_of_scan.c
index ac0b034..83c26d8 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -111,7 +111,7 @@ static void of_pci_parse_addrs(struct device_node *node,
struct pci_dev *dev)
res-name = pci_name(dev);
region.start = base;
region.end = base + size - 1;
- pcibios_bus_to_resource(dev, res, region);
+ pcibios_bus_to_resource(dev-bus, res, region);
}
}
@@ -280,7 +280,7 @@ void of_scan_pci_bridge(struct pci_dev *dev)
res-flags = flags;
region.start = of_read_number(ranges[1], 2);
region.end = region.start + size - 1;
- pcibios_bus_to_resource(dev, res, region);
+ pcibios_bus_to_resource(dev-bus, res, region);
}
sprintf(bus-name, PCI Bus %04x:%02x, pci_domain_nr(bus),
bus-number);
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index cb02145..7de8d1f 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -392,7 +392,7 @@ static void apb_fake_ranges(struct pci_dev *dev,
res-flags = IORESOURCE_IO;
region.start = (first 21);
region.end = (last 21) + ((1 21) - 1);
- pcibios_bus_to_resource(dev, res, region);
+ pcibios_bus_to_resource(dev-bus, res, region);
pci_read_config_byte(dev,
RE: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
-Original Message- From: Alex Williamson [mailto:alex.william...@redhat.com] Sent: Tuesday, December 10, 2013 11:23 AM To: Bhushan Bharat-R65777 Cc: Wood Scott-B07421; linux-...@vger.kernel.org; ag...@suse.de; Yoder Stuart- B08248; io...@lists.linux-foundation.org; bhelg...@google.com; linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU) On Tue, 2013-12-10 at 05:37 +, bharat.bhus...@freescale.com wrote: -Original Message- From: Alex Williamson [mailto:alex.william...@redhat.com] Sent: Saturday, December 07, 2013 1:00 AM To: Wood Scott-B07421 Cc: Bhushan Bharat-R65777; linux-...@vger.kernel.org; ag...@suse.de; Yoder Stuart-B08248; io...@lists.linux-foundation.org; bhelg...@google.com; linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU) On Fri, 2013-12-06 at 12:59 -0600, Scott Wood wrote: On Thu, 2013-12-05 at 22:11 -0600, Bharat Bhushan wrote: -Original Message- From: Wood Scott-B07421 Sent: Friday, December 06, 2013 5:52 AM To: Bhushan Bharat-R65777 Cc: Alex Williamson; linux-...@vger.kernel.org; ag...@suse.de; Yoder Stuart- B08248; io...@lists.linux-foundation.org; bhelg...@google.com; linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU) On Thu, 2013-11-28 at 03:19 -0600, Bharat Bhushan wrote: -Original Message- From: Bhushan Bharat-R65777 Sent: Wednesday, November 27, 2013 9:39 PM To: 'Alex Williamson' Cc: Wood Scott-B07421; linux-...@vger.kernel.org; ag...@suse.de; Yoder Stuart- B08248; io...@lists.linux-foundation.org; bhelg...@google.com; linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org Subject: RE: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU) If we just provide the size of MSI bank to userspace then userspace cannot do anything wrong. So userspace does not know address, so it cannot mmap and cause any interference by directly reading/writing. That's security through obscurity... Couldn't the malicious user find out the address via other means, such as experimentation on another system over which they have full control? What would happen if the user reads from their device's PCI config space? Or gets the information via some back door in the PCI device they own? Or pokes throughout the address space looking for something that generates an interrupt to its own device? So how to solve this problem, Any suggestion ? We have to map one window in PAMU for MSIs and a malicious user can ask its device to do DMA to MSI window region with any pair of address and data, which can lead to unexpected MSIs in system? I don't think there are any solutions other than to limit each bank to one user, unless the admin turns some knob that says they're OK with the partial loss of isolation. Even if the admin does opt-in to an allow_unsafe_interrupts options, it should still be reasonably difficult for one guest to interfere with the other. I don't think we want to rely on the blind luck of making the full MSI bank accessible to multiple guests and hoping they don't step on each other. Not sure how to solve in this case (sharing MSI page) That probably means that vfio needs to manage the space rather than the guest. What you mean by vfio needs to manage the space rather than the guest? I mean there needs to be some kernel component managing the contents of the MSI page rather than just handing it out to the user and hoping for the best. The user API also needs to remain the same whether the user has the MSI page exclusively or it's shared with others (kernel or users). Thanks, We have limited number of MSI banks, so we cannot provide explicit MSI bank to each VMs. Below is the summary of msi allocation/ownership model I am thinking of: Option-1: User-space aware of MSI banks = 1 ) Userspace will make GET_MSI_REGION(request number of MSI banks) - VFIO will allocate requested number of MSI bank; - If allocation succeed then return number of banks - If allocation fails then check opt-in flag set by administrator (allow_unsafe_interrupts); allow_unsafe_interrupts == 0; Not allowed to share; return FAIL (-ENODEV) else share MSI bank of another VM. 2) Userspace will adjust geometry size as per number of banks and calls SET_GEOMETRY 3) Userspace will do DMA_MAP for its memory 4) Userspace will do MSI_MAP for number of banks it
[PATCH v1 1/1] powerpc/512x: dts: remove misplaced IRQ spec from 'soc' node (5125)
the 'soc' node in the MPC5125 tower board .dts has an '#interrupt-cells' property although this node is not an interrupt controller remove this erroneously placed property because starting with v3.13-rc1 lookup and resolution of 'interrupts' specs for peripherals gets misled (tries to use the 'soc' as the interrupt parent which fails), emits 'no irq domain found' WARN() messages and breaks the boot process [ best viewed with 'git diff -U5' to have DT node names in the context ] Cc: Anatolij Gustschin ag...@denx.de Cc: linuxppc-dev@lists.ozlabs.org Cc: devicet...@vger.kernel.org Signed-off-by: Gerhard Sittig g...@denx.de --- note that this is not a resend of the previous MPC5121 fix, but instead is a fix for MPC5125 along the same lines of the MPC5121 fix --- arch/powerpc/boot/dts/mpc5125twr.dts |1 - 1 file changed, 1 deletion(-) diff --git a/arch/powerpc/boot/dts/mpc5125twr.dts b/arch/powerpc/boot/dts/mpc5125twr.dts index 4177b62240c2..0a0fe92216ae 100644 --- a/arch/powerpc/boot/dts/mpc5125twr.dts +++ b/arch/powerpc/boot/dts/mpc5125twr.dts @@ -58,7 +58,6 @@ compatible = fsl,mpc5121-immr; #address-cells = 1; #size-cells = 1; - #interrupt-cells = 2; ranges = 0x0 0x8000 0x40; reg = 0x8000 0x40; bus-frequency = 6600; // 66 MHz ips bus -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v1 1/1] powerpc/512x: dts: remove misplaced IRQ spec from 'soc' node
[ Cc: to Matteo as well ] On Tue, Dec 03, 2013 at 15:04 +0100, Anatolij Gustschin wrote: On Tue, 3 Dec 2013 11:56:52 +0100 Gerhard Sittig g...@denx.de wrote: the 'soc' node in the common .dtsi for MPC5121 has an '#interrupt-cells' property although this node is not an interrupt controller remove this erroneously placed property because starting with v3.13-rc1 lookup and resolution of 'interrupts' specs for peripherals gets misled, emits 'no irq domain found' WARN() messages and breaks the boot process irq: no irq domain found for /soc@8000 ! [ cut here ] WARNING: at /home/gsi/SRC/linux-torvalds/drivers/of/platform.c:171 [ ... ] ... irq: no irq domain found for /soc@8000 ! fsl-diu-fb 80002100.display: could not get DIU IRQ fsl-diu-fb: probe of 80002100.display failed with error -22 irq: no irq domain found for /soc@8000 ! mpc512x_dma 80014000.dma: Error mapping IRQ! mpc512x_dma: probe of 80014000.dma failed with error -22 ... irq: no irq domain found for /soc@8000 ! fs_enet: probe of 80002800.ethernet failed with error -22 ... irq: no irq domain found for /soc@8000 ! mpc5121-rtc 8a00.rtc: mpc5121_rtc_probe: could not request irq: 0 mpc5121-rtc: probe of 8a00.rtc failed with error -22 ... [ best viewed with 'git diff -U5' to have DT node names in the context ] Cc: Anatolij Gustschin ag...@denx.de Cc: linuxppc-dev@lists.ozlabs.org Cc: devicet...@vger.kernel.org Signed-off-by: Gerhard Sittig g...@denx.de --- arch/powerpc/boot/dts/mpc5121.dtsi |1 - 1 file changed, 1 deletion(-) applied, thanks! FYI: I only noticed yesterday that MPC5125 suffers from the same issue, have sent 1386669068-2477-1-git-send-email-...@denx.de to fix that as well. Both patches may get squashed when going upstream. Don't have a dump at hand for MPC5125 as I don't have access to hardware. Matteo, can you verify that an unpatched v3.13-rc1 (up to and including -rc3) won't boot, and that the patch fixes the issue for you? Forgot to Cc: you on the MPC5125 patch, will bounce it to you. Thanks! virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] DTS: DMA: Fix DMA3 interrupts
Scott,
This issue is due to the non-continuous MPIC register, I think there is
two ways to fix it.
The first one is as what we are discussing, in fact the Bman/Qman DT
author had introduced this way, and I had to follow it, it is a trick,
adding 208 is a bit ugly I think, and even difficult to explain it to
customers etc, but this way changes less codes.
The second one is editing MPIC related codes without adding 208 to high
interrupts. The point of translate interrupt number to MPIC register
address is a so called 'isu' mechanism, we can do like the following
example codes, then the tricky adding 208 isn't needed any more.
Which one do you prefer?
In fact I myself prefer the second, if the idea is acceptable, I will
send a patch instead of this one. (and also alone with the internal
patch decreasing 208 for the Bman/Qman)
void __init corenet_ds_pic_init(void)
{
..
mpic = mpic_alloc(NULL, 0, flags, 0, 512, OpenPIC);
BUG_ON(mpic == NULL);
// Add this start
for (i = 0; i 17; i++) {
if (i 11)
addr_off = 0x1 + 0x20 * 16 * i;
else
addr_off = 0x13000 + 0x20 * 16 * (i - 11); /* scape the
address not for interrupts */
mpic_assign_isu(mpic, i, mpic-paddr + addr_off);
}
// Add this end
mpic_init(mpic);
}
On 12/07/2013 03:21 AM, Scott Wood wrote:
On Fri, 2013-11-29 at 16:07 +0800, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang hongbo.zh...@freescale.com
MPIC registers for internal interrupts is non-continous in address, any
internal interrupt number greater than 159 should be added (16+208) to work.
16 is due to external interrupts as usual, 208 is due to the non-continous MPIC
register space.
Tested on T4240 rev2 with SRIO2 disabled.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
---
arch/powerpc/boot/dts/fsl/elo3-dma-2.dtsi | 16
1 file changed, 8 insertions(+), 8 deletions(-)
The FSL MPIC binding should be updated to point out how this works.
Technically it's not a change to the binding itself, since it's defined
in terms of register offset, but the explanatory text says So interrupt
0 is at offset 0x0, interrupt 1 is at offset 0x20, and so on. which is
not accurate for these new high interrupt numbers.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v1 1/1] powerpc/512x: dts: remove misplaced IRQ spec from 'soc' node
On Tue, Dec 10, 2013 at 11:05 +0100, Gerhard Sittig wrote: FYI: I only noticed yesterday that MPC5125 suffers from the same issue, have sent 1386669068-2477-1-git-send-email-...@denx.de to fix that as well. Both patches may get squashed when going upstream. Don't have a dump at hand for MPC5125 as I don't have access to hardware. Had a thinko there, the MPC5121 fix already went upstream, while the MPC5125 fix is pending. So there is no squashing. Nevermind. virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] DTS: DMA: Fix DMA3 interrupts
On Tue, 2013-12-10 at 18:33 +0800, Hongbo Zhang wrote:
Scott,
This issue is due to the non-continuous MPIC register, I think there is
two ways to fix it.
The first one is as what we are discussing, in fact the Bman/Qman DT
author had introduced this way, and I had to follow it, it is a trick,
adding 208 is a bit ugly I think, and even difficult to explain it to
customers etc, but this way changes less codes.
The second one is editing MPIC related codes without adding 208 to high
interrupts. The point of translate interrupt number to MPIC register
address is a so called 'isu' mechanism, we can do like the following
example codes, then the tricky adding 208 isn't needed any more.
Which one do you prefer?
In fact I myself prefer the second, if the idea is acceptable, I will
send a patch instead of this one. (and also alone with the internal
patch decreasing 208 for the Bman/Qman)
void __init corenet_ds_pic_init(void)
{
..
mpic = mpic_alloc(NULL, 0, flags, 0, 512, OpenPIC);
BUG_ON(mpic == NULL);
// Add this start
for (i = 0; i 17; i++) {
if (i 11)
addr_off = 0x1 + 0x20 * 16 * i;
else
addr_off = 0x13000 + 0x20 * 16 * (i - 11); /* scape the
address not for interrupts */
mpic_assign_isu(mpic, i, mpic-paddr + addr_off);
}
// Add this end
mpic_init(mpic);
}
NACK
We already have a binding that states that the interrupt number is based
on the register offset, rather than whatever arbitrary numbers hardware
documenters decide to use next week.
While I'm not terribly happy with the usability of this, especially now
that it's not a simple add 16, redefining the existing binding is not
OK (and in any case the code above seems obfuscatory). If we decide to
do something other than continue with register offset divided by 32,
then we need to define a new interrupt type (similar to current defined
types of error interrupt, timer, and IPI) for the new numberspace -- and
it should be handled when decoding that type of interrupt specifier,
rather than with the isu mechanism.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc 8xx: Loading kernels over 8Mbytes without CONFIG_PIN_TLB
On Tue, 2013-12-10 at 12:29 +0100, Christophe Leroy wrote: Today, the only way to load kernels whose size is greater than 8Mbytes is to activate CONFIG_PIN_TLB. Otherwise, the physical memory initially mapped is limited to 8Mbytes. This patch adds the capability to select the size of initial memory between 8/16/24 Mbytes and this is regardless of whether CONFIG_PIN_TLB is active or not. It allows to load big kernels (for instance when activating CONFIG_LOCKDEP_SUPPORT) without having to activate CONFIG_PIN_TLB. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr diff -ur a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -980,6 +980,29 @@ config PIN_TLB bool Pinned Kernel TLBs (860 ONLY) depends on ADVANCED_OPTIONS 8xx + +choice + prompt Initial Data Memory Mapped on 8xx + default 8xx_MAP_8M + depends on ADVANCED_OPTIONS 8xx + +config 8xx_INIT_MAP_8M + bool 8 Mbytes + +config 8xx_INIT_MAP_16M + bool 16 Mbytes + +config 8xx_INIT_MAP_24M + bool 24 Mbytes Are you working with a loader that passes initial-mapped-area size in r7 as per ePAPR? If so, we could rely on that at runtime. If you're using a non-ancient U-Boot, it should qualify here even if it's not fully ePAPR compliant (it passes the value of the bootm_mapsize variable in r7). -#ifdef CONFIG_PIN_TLB +#if defined (CONFIG_8xx_INIT_MAP_16M) || defined (CONFIG_8xx_INIT_MAP_24M) /* Map two more 8M kernel data pages. */ +#ifdef CONFIG_PIN_TLB addir10, r10, 0x0100 mtspr SPRN_MD_CTR, r10 +#endif lis r8, KERNELBASE@h/* Create vaddr for TLB */ addis r8, r8, 0x0080 /* Add 8M */ @@ -858,15 +860,19 @@ addis r11, r11, 0x0080/* Add 8M */ mtspr SPRN_MD_RPN, r11 +#ifdef CONFIG_8xx_INIT_MAP_24M +#ifdef CONFIG_PIN_TLB addir10, r10, 0x0100 mtspr SPRN_MD_CTR, r10 +#endif Are these ifdefs for CONFIG_PIN_TLB really needed? It shouldn't harm anything to use those entries even if they're not being pinned. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 00/17] add COMMON_CLK support for PowerPC MPC512x
[ trimmed Cc: list to PowerPC and CCF ] On Sat, Nov 30, 2013 at 23:51 +0100, Gerhard Sittig wrote: this series introduces support for the common clock framework (CCF, COMMON_CLK Kconfig option) in the PowerPC based MPC512x platform, which brings device tree based clock lookup as well For the record: MPC5125 turned out to be quite different compared to MPC5121/5123 with regard to the set of peripherals and clock features, so I sent an update of this COMMON_CLK support motivated by MPC5125: From: Gerhard Sittig g...@denx.de To: linuxppc-dev@lists.ozlabs.org, linux-arm-ker...@lists.infradead.org, Anatolij Gustschin ag...@denx.de, Mike Turquette mturque...@linaro.org, Matteo Facchinetti matteo.facchine...@sirius-es.it Cc: Scott Wood scottw...@freescale.com, Detlev Zundel d...@denx.de, Gerhard Sittig g...@denx.de Subject: [PATCH v1 0/4] powerpc/512x: update COMMON_CLK support for MPC5125 Date: Tue, 10 Dec 2013 14:11:33 +0100 Message-Id: 1386681097-14126-1-git-send-email-...@denx.de virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/9] PCI: Use dev_is_pci() to check whether it is pci device
On Mon, Dec 9, 2013 at 8:59 PM, Benjamin Herrenschmidt b...@au1.ibm.com wrote: On Mon, 2013-12-09 at 17:01 -0700, Bjorn Helgaas wrote: [+cc arch lists] On Thu, Dec 05, 2013 at 07:52:53PM +0800, Yijing Wang wrote: Use dev_is_pci() instead of directly compare pci_bus_type to check whether it is pci device. Signed-off-by: Yijing Wang wangyij...@huawei.com I applied all these to my pci/yijing-dev_is_pci branch for v3.14, thanks! Browse them here: http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/yijing-dev_is_pci Ah ok. I also have the powerpc one in powerpc -next, no biggie though I'll drop the powerpc one. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
My e-mail address is scottw...@freescale.com, not IMCEAEX-_O=MMS_OU=EXTERNAL+20+28FYDIBOHF25SPDLT +29_CN=RECIPIENTS_CN=f0faac8d7e74473a9ee1c45b068d8...@namprd03.prod.outlook.com On Tue, 2013-12-10 at 05:37 +, bharat.bhus...@freescale.com wrote: -Original Message- From: Wood Scott-B07421 Sent: Saturday, December 07, 2013 12:55 AM To: Bhushan Bharat-R65777 Cc: Alex Williamson; linux-...@vger.kernel.org; ag...@suse.de; Yoder Stuart- B08248; io...@lists.linux-foundation.org; bhelg...@google.com; linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU) If the administrator does not opt into this partial loss of isolation, then once you run out of MSI groups, new users should not be able to set up MSIs. So mean vfio should use Legacy when out of MSI banks? Yes, if the administrator hasn't granted permission to share. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] KVM: PPC: Use schedule instead of cond_resched
On Wed, Dec 11, 2013 at 07:52:51AM +1100, Benjamin Herrenschmidt wrote: On Tue, 2013-12-10 at 15:40 +0100, Alexander Graf wrote: On 10.12.2013, at 15:21, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com We already checked need_resched. So we can call schedule directly Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com The real fix for the issue you're seeing is https://lkml.org/lkml/2013/11/28/241 And is still not upstream Peter ? Yeah, I went on holidays and the patch just sat there. I'll prod Ingo into merging it. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v1 2/4] powerpc/512x: clk: enforce even SDHC divider values
the SDHC clock is derived from CSB with a fractional divider which can address quarters; the implementation multiplies CSB by 4 and divides it by the (integer) divider value a bug in the clock domain synchronisation requires that only even divider values get setup; we achieve this by - multiplying CSB by 2 only instead of 4 - registering with CCF the divider's bit field without bit0 - the divider's lowest bit remains clear as this is the reset value and later operations won't touch it this change keeps fully utilizing common clock primitives (needs no additional support logic, and avoids an excessive divider table) and satisfies the hardware's constraint of only supporting even divider values Signed-off-by: Gerhard Sittig g...@denx.de --- arch/powerpc/platforms/512x/clock-commonclk.c | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c index 079eb1137260..b5190fcb81bb 100644 --- a/arch/powerpc/platforms/512x/clock-commonclk.c +++ b/arch/powerpc/platforms/512x/clock-commonclk.c @@ -560,9 +560,21 @@ static void mpc512x_clk_setup_clock_tree(struct device_node *np, int busfreq) /* now setup anything below SYS and CSB and IPS */ clks[MPC512x_CLK_DDR_UG] = mpc512x_clk_factor(ddr-ug, sys, 1, 2); - clks[MPC512x_CLK_SDHC_x4] = mpc512x_clk_factor(sdhc-x4, csb, 4, 1); + + /* +* the Reference Manual discusses that for SDHC only even divide +* ratios are supported because clock domain synchronization +* between 'per' and 'ipg' is broken; +* keep the divider's bit 0 cleared (per reset value), and only +* allow to setup the divider's bits 7:1, which results in that +* only even divide ratios can get configured upon rate changes; +* keep the x4 name because this bit shift hack is an internal +* implementation detail, the fractional divider with quarters +* semantics remains +*/ + clks[MPC512x_CLK_SDHC_x4] = mpc512x_clk_factor(sdhc-x4, csb, 2, 1); clks[MPC512x_CLK_SDHC_UG] = mpc512x_clk_divider(sdhc-ug, sdhc-x4, 0, - clkregs-scfr2, 0, 8, + clkregs-scfr2, 1, 7, CLK_DIVIDER_ONE_BASED); clks[MPC512x_CLK_DIU_x4] = mpc512x_clk_factor(diu-x4, csb, 4, 1); clks[MPC512x_CLK_DIU_UG] = mpc512x_clk_divider(diu-ug, diu-x4, 0, -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] KVM: PPC: Use schedule instead of cond_resched
On 10.12.2013, at 17:08, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com wrote: Alexander Graf ag...@suse.de writes: On 10.12.2013, at 15:21, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com We already checked need_resched. So we can call schedule directly Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com The real fix for the issue you're seeing is https://lkml.org/lkml/2013/11/28/241 True, I mentioned that in the thread https://lkml.org/lkml/2013/12/9/64 But do we need to do cond_resched after we checked for need_resched() ? This is really just copying the logic from kvm_resched() from virt/kvm/kvm_main.c. And I'd prefer not to diverge from that. I do agree that there's a good chance we don't need it, as it seems to predate preempt notifiers: https://git.kernel.org/cgit/virt/kvm/kvm.git/commit/?id=3fca03653010b8c5fa63b99fc94c78cbfb433d00 But this is a discussion that should occur on the non-ppc specific code first :). Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] KVM: PPC: Use schedule instead of cond_resched
On 10.12.2013, at 15:21, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com We already checked need_resched. So we can call schedule directly Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com The real fix for the issue you're seeing is https://lkml.org/lkml/2013/11/28/241 Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] KVM: PPC: Use schedule instead of cond_resched
On Tue, 2013-12-10 at 23:48 +0100, Peter Zijlstra wrote: Yeah, I went on holidays and the patch just sat there. I'll prod Ingo into merging it. Thanks ! Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc 8xx: Loading kernels over 8Mbytes without CONFIG_PIN_TLB
Le 10/12/2013 23:24, Scott Wood a écrit : On Tue, 2013-12-10 at 12:29 +0100, Christophe Leroy wrote: Today, the only way to load kernels whose size is greater than 8Mbytes is to activate CONFIG_PIN_TLB. Otherwise, the physical memory initially mapped is limited to 8Mbytes. This patch adds the capability to select the size of initial memory between 8/16/24 Mbytes and this is regardless of whether CONFIG_PIN_TLB is active or not. It allows to load big kernels (for instance when activating CONFIG_LOCKDEP_SUPPORT) without having to activate CONFIG_PIN_TLB. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr diff -ur a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -980,6 +980,29 @@ config PIN_TLB bool Pinned Kernel TLBs (860 ONLY) depends on ADVANCED_OPTIONS 8xx + +choice + prompt Initial Data Memory Mapped on 8xx + default 8xx_MAP_8M + depends on ADVANCED_OPTIONS 8xx + +config 8xx_INIT_MAP_8M + bool 8 Mbytes + +config 8xx_INIT_MAP_16M + bool 16 Mbytes + +config 8xx_INIT_MAP_24M + bool 24 Mbytes Are you working with a loader that passes initial-mapped-area size in r7 as per ePAPR? If so, we could rely on that at runtime. If you're using a non-ancient U-Boot, it should qualify here even if it's not fully ePAPR compliant (it passes the value of the bootm_mapsize variable in r7). Ok, let me check that. But it means that the size of the kernel I can boot will depend on the initial memory mapped by uboot ? Isn't it limitating ? Even if uboot only maps 8Mbytes, why couldn't I be allowed to boot a kernel having 10 Mbytes data if I have 32 Mbytes mem on the board ? I don't like the idea of having to change the bootloader just because I want to activate CONFIG_LOCKDEP to debug my kernel. -#ifdef CONFIG_PIN_TLB +#if defined (CONFIG_8xx_INIT_MAP_16M) || defined (CONFIG_8xx_INIT_MAP_24M) /* Map two more 8M kernel data pages. */ +#ifdef CONFIG_PIN_TLB addir10, r10, 0x0100 mtspr SPRN_MD_CTR, r10 +#endif lis r8, KERNELBASE@h /* Create vaddr for TLB */ addis r8, r8, 0x0080 /* Add 8M */ @@ -858,15 +860,19 @@ addis r11, r11, 0x0080/* Add 8M */ mtspr SPRN_MD_RPN, r11 +#ifdef CONFIG_8xx_INIT_MAP_24M +#ifdef CONFIG_PIN_TLB addir10, r10, 0x0100 mtspr SPRN_MD_CTR, r10 +#endif Are these ifdefs for CONFIG_PIN_TLB really needed? It shouldn't harm anything to use those entries even if they're not being pinned. I'm not sure I understand your comment. ifdef for CONFIG_PIN_TLB was already there before, but was enclosing the whole block, so 24 Mbytes were automatically mapped when you selected CONFIG_PIN_TLB and only 8 Mbytes were mapped when you didn't select CONFIG_PIN_TLB. I reduced the scope of those ifdefs so that they now apply on the pinning only. Christophe ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCHv2 1/6] powerpc: fix exception clearing in e500 SPE float emulation
From: Joseph Myers jos...@codesourcery.com
The e500 SPE floating-point emulation code clears existing exceptions
(__FPU_FPSCR = ~FP_EX_MASK;) before ORing in the exceptions from the
emulated operation. However, these exception bits are the sticky,
cumulative exception bits, and should only be cleared by the user
program setting SPEFSCR, not implicitly by any floating-point
instruction (whether executed purely by the hardware or emulated).
The spurious clearing of these bits shows up as missing exceptions in
glibc testing.
Fixing this, however, is not as simple as just not clearing the bits,
because while the bits may be from previous floating-point operations
(in which case they should not be cleared), the processor can also set
the sticky bits itself before the interrupt for an exception occurs,
and this can happen in cases when IEEE 754 semantics are that the
sticky bit should not be set. Specifically, the invalid sticky bit
is set in various cases with non-finite operands, where IEEE 754
semantics do not involve raising such an exception, and the
underflow sticky bit is set in cases of exact underflow, whereas
IEEE 754 semantics are that this flag is set only for inexact
underflow. Thus, for correct emulation the kernel needs to know the
setting of these two sticky bits before the instruction being
emulated.
When a floating-point operation raises an exception, the kernel can
note the state of the sticky bits immediately afterwards. Some
fenv.h functions that affect the state of these bits, such as
fesetenv and feholdexcept, need to use prctl with PR_GET_FPEXC and
PR_SET_FPEXC anyway, and so it is natural to record the state of those
bits during that call into the kernel and so avoid any need for a
separate call into the kernel to inform it of a change to those bits.
Thus, the interface I chose to use (in this patch and the glibc port)
is that one of those prctl calls must be made after any userspace
change to those sticky bits, other than through a floating-point
operation that traps into the kernel anyway. feclearexcept and
fesetexceptflag duly make those calls, which would not be required
were it not for this issue.
The previous EGLIBC port, and the uClibc code copied from it, is
fundamentally broken as regards any use of prctl for floating-point
exceptions because it didn't use the PR_FP_EXC_SW_ENABLE bit in its
prctl calls (and did various worse things, such as passing a pointer
when prctl expected an integer). If you avoid anything where prctl is
used, the clearing of sticky bits still means it will never give
anything approximating correct exception semantics with existing
kernels. I don't believe the patch makes things any worse for
existing code that doesn't try to inform the kernel of changes to
sticky bits - such code may get incorrect exceptions in some cases,
but it would have done so anyway in other cases.
Signed-off-by: Joseph Myers jos...@codesourcery.com
---
OK -- please mention this in the changelog.
The description of brokenness of existing code attempting to use
floating-point exceptions on e500 is now included above.
I don't know of a formal place for it, but there should at least be a
code comment somewhere.
This version now adds a comment alongside the relevant settings of
spefscr_last.
The other patches in this series (2-6) remain independent of this one
(and as previously noted, with no dependencies except that patch 5
depends on patch 2) and so are not resent.
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index fc14a38..91441d9 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -256,6 +256,8 @@ struct thread_struct {
unsigned long evr[32];/* upper 32-bits of SPE regs */
u64 acc;/* Accumulator */
unsigned long spefscr;/* SPE eFP status */
+ unsigned long spefscr_last; /* SPEFSCR value on last prctl
+ call or trap return */
int used_spe; /* set if process has used spe */
#endif /* CONFIG_SPE */
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
@@ -317,7 +319,9 @@ struct thread_struct {
(_ALIGN_UP(sizeof(init_thread_info), 16) + (unsigned long) init_stack)
#ifdef CONFIG_SPE
-#define SPEFSCR_INIT .spefscr = SPEFSCR_FINVE | SPEFSCR_FDBZE | SPEFSCR_FUNFE
| SPEFSCR_FOVFE,
+#define SPEFSCR_INIT \
+ .spefscr = SPEFSCR_FINVE | SPEFSCR_FDBZE | SPEFSCR_FUNFE |
SPEFSCR_FOVFE, \
+ .spefscr_last = SPEFSCR_FINVE | SPEFSCR_FDBZE | SPEFSCR_FUNFE |
SPEFSCR_FOVFE,
#else
#define SPEFSCR_INIT
#endif
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 3386d8a..b08c0d0 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1175,6 +1175,19 @@ int set_fpexc_mode(struct task_struct *tsk, unsigned int
val)
if (val PR_FP_EXC_SW_ENABLE) {
#ifdef CONFIG_SPE
Re: [PATCH] KVM: PPC: Use schedule instead of cond_resched
On Tue, 2013-12-10 at 15:40 +0100, Alexander Graf wrote: On 10.12.2013, at 15:21, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com We already checked need_resched. So we can call schedule directly Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com The real fix for the issue you're seeing is https://lkml.org/lkml/2013/11/28/241 And is still not upstream Peter ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v1 4/4] powerpc/512x: dts: add MPC5125 clock specs
add clock related specs to the MPC5125 tower board DTS
- add clock providers (crystal/oscillator, clock control module)
- add consumers (the CAN, SDHC, I2C, DIU, FEC, USB, PSC peripherals)
Signed-off-by: Gerhard Sittig g...@denx.de
---
arch/powerpc/boot/dts/mpc5125twr.dts | 53 +-
1 file changed, 52 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/dts/mpc5125twr.dts
b/arch/powerpc/boot/dts/mpc5125twr.dts
index 0a0fe92216ae..806479ffc607 100644
--- a/arch/powerpc/boot/dts/mpc5125twr.dts
+++ b/arch/powerpc/boot/dts/mpc5125twr.dts
@@ -12,6 +12,8 @@
* option) any later version.
*/
+#include dt-bindings/clock/mpc512x-clock.h
+
/dts-v1/;
/ {
@@ -54,6 +56,17 @@
reg = 0x3000 0x08000; // 32K at 0x3000
};
+ clocks {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ osc: osc {
+ compatible = fixed-clock;
+ #clock-cells = 0;
+ clock-frequency = 3300;
+ };
+ };
+
soc@8000 {
compatible = fsl,mpc5121-immr;
#address-cells = 1;
@@ -87,9 +100,12 @@
reg = 0xe00 0x100;
};
- clock@f00 { // Clock control
+ clks: clock@f00 { // Clock control
compatible = fsl,mpc5121-clock;
reg = 0xf00 0x100;
+ #clock-cells = 1;
+ clocks = osc;
+ clock-names = osc;
};
pmc@1000{ // Power Management Controller
@@ -114,18 +130,33 @@
compatible = fsl,mpc5121-mscan;
interrupts = 12 0x8;
reg = 0x1300 0x80;
+ clocks = clks MPC512x_CLK_BDLC,
+clks MPC512x_CLK_IPS,
+clks MPC512x_CLK_SYS,
+clks MPC512x_CLK_REF,
+clks MPC512x_CLK_MSCAN0_MCLK;
+ clock-names = ipg, ips, sys, ref, mclk;
};
can@1380 {
compatible = fsl,mpc5121-mscan;
interrupts = 13 0x8;
reg = 0x1380 0x80;
+ clocks = clks MPC512x_CLK_BDLC,
+clks MPC512x_CLK_IPS,
+clks MPC512x_CLK_SYS,
+clks MPC512x_CLK_REF,
+clks MPC512x_CLK_MSCAN1_MCLK;
+ clock-names = ipg, ips, sys, ref, mclk;
};
sdhc@1500 {
compatible = fsl,mpc5121-sdhc;
interrupts = 8 0x8;
reg = 0x1500 0x100;
+ clocks = clks MPC512x_CLK_IPS,
+clks MPC512x_CLK_SDHC;
+ clock-names = ipg, per;
};
i2c@1700 {
@@ -134,6 +165,8 @@
compatible = fsl,mpc5121-i2c, fsl-i2c;
reg = 0x1700 0x20;
interrupts = 0x9 0x8;
+ clocks = clks MPC512x_CLK_I2C;
+ clock-names = ipg;
};
i2c@1720 {
@@ -142,6 +175,8 @@
compatible = fsl,mpc5121-i2c, fsl-i2c;
reg = 0x1720 0x20;
interrupts = 0xa 0x8;
+ clocks = clks MPC512x_CLK_I2C;
+ clock-names = ipg;
};
i2c@1740 {
@@ -150,6 +185,8 @@
compatible = fsl,mpc5121-i2c, fsl-i2c;
reg = 0x1740 0x20;
interrupts = 0xb 0x8;
+ clocks = clks MPC512x_CLK_I2C;
+ clock-names = ipg;
};
i2ccontrol@1760 {
@@ -161,6 +198,8 @@
compatible = fsl,mpc5121-diu;
reg = 0x2100 0x100;
interrupts = 64 0x8;
+ clocks = clks MPC512x_CLK_DIU;
+ clock-names = ipg;
};
mdio@2800 {
@@ -180,6 +219,8 @@
interrupts = 4 0x8;
phy-handle = phy0 ;
phy-connection-type = rmii;
+ clocks = clks MPC512x_CLK_FEC;
+ clock-names = per;
};
// IO control
@@ -196,6 +237,8 @@
interrupts = 43 0x8;
dr_mode = host;
phy_type = ulpi;
+ clocks = clks MPC512x_CLK_USB1;
+ clock-names = ipg;
};
Re: [PATCH v2 00/11] Consolidate asm/fixmap.h files
Hi Mark, Is there some reason you've excluded OpenRISC here? Did you just miss it, or does the implementation diverage too much to be usable with your generic version? Regards, Jonas On 25 November 2013 17:13, Mark Salter msal...@redhat.com wrote: Many architectures provide an asm/fixmap.h which defines support for compile-time 'special' virtual mappings which need to be made before paging_init() has run. This suport is also used for early ioremap on x86. Much of this support is identical across the architectures. This patch consolidates all of the common bits into asm-generic/fixmap.h which is intended to be included from arch/*/include/asm/fixmap.h. This has been compiled on x86, arm, powerpc, and sh, but tested on x86 only. This is version two of the patch series: git://github.com/mosalter/linux.git#fixmap-v2 Version 1 is here: git://github.com/mosalter/linux.git#fixmap Changes from v1: * Added acks from feedback. * Use BUILD_BUG_ON in fix_to_virt() * Fixed ARM patch to make FIXMAP_TOP inclusive of fixmap range as is the case in the other architectures. Mark Salter (11): Add generic fixmap.h x86: use generic fixmap.h arm: use generic fixmap.h hexagon: use generic fixmap.h metag: use generic fixmap.h microblaze: use generic fixmap.h mips: use generic fixmap.h powerpc: use generic fixmap.h sh: use generic fixmap.h tile: use generic fixmap.h um: use generic fixmap.h arch/arm/include/asm/fixmap.h| 29 +++ arch/arm/mm/init.c | 2 +- arch/hexagon/include/asm/fixmap.h| 40 +-- arch/metag/include/asm/fixmap.h | 32 +--- arch/microblaze/include/asm/fixmap.h | 44 +--- arch/mips/include/asm/fixmap.h | 33 +--- arch/powerpc/include/asm/fixmap.h| 44 +--- arch/sh/include/asm/fixmap.h | 39 +-- arch/tile/include/asm/fixmap.h | 33 +--- arch/um/include/asm/fixmap.h | 40 +-- arch/x86/include/asm/fixmap.h| 59 +- include/asm-generic/fixmap.h | 97 12 files changed, 118 insertions(+), 374 deletions(-) create mode 100644 include/asm-generic/fixmap.h -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-arch in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jonas Bonn Stockholm, Sweden ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc 8xx: Loading kernels over 8Mbytes without CONFIG_PIN_TLB
On Wed, 2013-12-11 at 00:05 +0100, leroy christophe wrote: Le 10/12/2013 23:24, Scott Wood a écrit : On Tue, 2013-12-10 at 12:29 +0100, Christophe Leroy wrote: Today, the only way to load kernels whose size is greater than 8Mbytes is to activate CONFIG_PIN_TLB. Otherwise, the physical memory initially mapped is limited to 8Mbytes. This patch adds the capability to select the size of initial memory between 8/16/24 Mbytes and this is regardless of whether CONFIG_PIN_TLB is active or not. It allows to load big kernels (for instance when activating CONFIG_LOCKDEP_SUPPORT) without having to activate CONFIG_PIN_TLB. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr diff -ur a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -980,6 +980,29 @@ config PIN_TLB bool Pinned Kernel TLBs (860 ONLY) depends on ADVANCED_OPTIONS 8xx + +choice + prompt Initial Data Memory Mapped on 8xx + default 8xx_MAP_8M + depends on ADVANCED_OPTIONS 8xx + +config8xx_INIT_MAP_8M + bool 8 Mbytes + +config8xx_INIT_MAP_16M + bool 16 Mbytes + +config8xx_INIT_MAP_24M + bool 24 Mbytes Are you working with a loader that passes initial-mapped-area size in r7 as per ePAPR? If so, we could rely on that at runtime. If you're using a non-ancient U-Boot, it should qualify here even if it's not fully ePAPR compliant (it passes the value of the bootm_mapsize variable in r7). Ok, let me check that. But it means that the size of the kernel I can boot will depend on the initial memory mapped by uboot ? Isn't it limitating ? The ePAPR IMA is supposed to be large enough to include the OS image, device tree, etc. Even if uboot only maps 8Mbytes, why couldn't I be allowed to boot a kernel having 10 Mbytes data if I have 32 Mbytes mem on the board ? I don't like the idea of having to change the bootloader just because I want to activate CONFIG_LOCKDEP to debug my kernel. Well, as noted, if you're using a non-ancient U-Boot you shouldn't have to change anything because it already implements r7. Now, the value of r7 it passes might be a lie as far as ePAPR is concerned, since it's supposed to represent what's actually mapped, but that's another matter. Even fixing that wouldn't mean you have to change U-Boot every time the kernel size changes; you'd just set it to something reasonable and be done with it. I'm not fond of adding kconfigs to hack around a problem that has already been addressed in the standard that governs the PPC boot process that U-Boot claims to implement. -#ifdef CONFIG_PIN_TLB +#if defined (CONFIG_8xx_INIT_MAP_16M) || defined (CONFIG_8xx_INIT_MAP_24M) /* Map two more 8M kernel data pages. */ +#ifdef CONFIG_PIN_TLB addir10, r10, 0x0100 mtspr SPRN_MD_CTR, r10 +#endif lis r8, KERNELBASE@h/* Create vaddr for TLB */ addis r8, r8, 0x0080 /* Add 8M */ @@ -858,15 +860,19 @@ addis r11, r11, 0x0080/* Add 8M */ mtspr SPRN_MD_RPN, r11 +#ifdef CONFIG_8xx_INIT_MAP_24M +#ifdef CONFIG_PIN_TLB addir10, r10, 0x0100 mtspr SPRN_MD_CTR, r10 +#endif Are these ifdefs for CONFIG_PIN_TLB really needed? It shouldn't harm anything to use those entries even if they're not being pinned. I'm not sure I understand your comment. ifdef for CONFIG_PIN_TLB was already there before, but was enclosing the whole block, so 24 Mbytes were automatically mapped when you selected CONFIG_PIN_TLB and only 8 Mbytes were mapped when you didn't select CONFIG_PIN_TLB. I reduced the scope of those ifdefs so that they now apply on the pinning only. There wasn't previously an ifdef specifically around the setting of SPRN_MD_CTR. That's new. There was an ifdef around the entire block, which has gone away because you are now trying to map more than 8M regardless of CONFIG_PIN_TLB, but that has nothing to do with whether there should be an ifdef around SPRN_MD_CTR. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc 8xx: Loading kernels over 8Mbytes without CONFIG_PIN_TLB
Le 11/12/2013 00:18, Scott Wood a écrit : On Wed, 2013-12-11 at 00:05 +0100, leroy christophe wrote: Le 10/12/2013 23:24, Scott Wood a écrit : On Tue, 2013-12-10 at 12:29 +0100, Christophe Leroy wrote: Today, the only way to load kernels whose size is greater than 8Mbytes is to activate CONFIG_PIN_TLB. Otherwise, the physical memory initially mapped is limited to 8Mbytes. This patch adds the capability to select the size of initial memory between 8/16/24 Mbytes and this is regardless of whether CONFIG_PIN_TLB is active or not. It allows to load big kernels (for instance when activating CONFIG_LOCKDEP_SUPPORT) without having to activate CONFIG_PIN_TLB. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr diff -ur a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -980,6 +980,29 @@ config PIN_TLB bool Pinned Kernel TLBs (860 ONLY) depends on ADVANCED_OPTIONS 8xx + +choice + prompt Initial Data Memory Mapped on 8xx + default 8xx_MAP_8M + depends on ADVANCED_OPTIONS 8xx + +config 8xx_INIT_MAP_8M + bool 8 Mbytes + +config 8xx_INIT_MAP_16M + bool 16 Mbytes + +config 8xx_INIT_MAP_24M + bool 24 Mbytes Are you working with a loader that passes initial-mapped-area size in r7 as per ePAPR? If so, we could rely on that at runtime. If you're using a non-ancient U-Boot, it should qualify here even if it's not fully ePAPR compliant (it passes the value of the bootm_mapsize variable in r7). Ok, let me check that. But it means that the size of the kernel I can boot will depend on the initial memory mapped by uboot ? Isn't it limitating ? The ePAPR IMA is supposed to be large enough to include the OS image, device tree, etc. Even if uboot only maps 8Mbytes, why couldn't I be allowed to boot a kernel having 10 Mbytes data if I have 32 Mbytes mem on the board ? I don't like the idea of having to change the bootloader just because I want to activate CONFIG_LOCKDEP to debug my kernel. Well, as noted, if you're using a non-ancient U-Boot you shouldn't have to change anything because it already implements r7. Now, the value of r7 it passes might be a lie as far as ePAPR is concerned, since it's supposed to represent what's actually mapped, but that's another matter. Even fixing that wouldn't mean you have to change U-Boot every time the kernel size changes; you'd just set it to something reasonable and be done with it. I'm not fond of adding kconfigs to hack around a problem that has already been addressed in the standard that governs the PPC boot process that U-Boot claims to implement. Well, ok, that makes sense. I'll investigate around that solution. -#ifdef CONFIG_PIN_TLB +#if defined (CONFIG_8xx_INIT_MAP_16M) || defined (CONFIG_8xx_INIT_MAP_24M) /* Map two more 8M kernel data pages. */ +#ifdef CONFIG_PIN_TLB addir10, r10, 0x0100 mtspr SPRN_MD_CTR, r10 +#endif lis r8, KERNELBASE@h /* Create vaddr for TLB */ addis r8, r8, 0x0080 /* Add 8M */ @@ -858,15 +860,19 @@ addis r11, r11, 0x0080/* Add 8M */ mtspr SPRN_MD_RPN, r11 +#ifdef CONFIG_8xx_INIT_MAP_24M +#ifdef CONFIG_PIN_TLB addir10, r10, 0x0100 mtspr SPRN_MD_CTR, r10 +#endif Are these ifdefs for CONFIG_PIN_TLB really needed? It shouldn't harm anything to use those entries even if they're not being pinned. I'm not sure I understand your comment. ifdef for CONFIG_PIN_TLB was already there before, but was enclosing the whole block, so 24 Mbytes were automatically mapped when you selected CONFIG_PIN_TLB and only 8 Mbytes were mapped when you didn't select CONFIG_PIN_TLB. I reduced the scope of those ifdefs so that they now apply on the pinning only. There wasn't previously an ifdef specifically around the setting of SPRN_MD_CTR. That's new. There was an ifdef around the entire block, which has gone away because you are now trying to map more than 8M regardless of CONFIG_PIN_TLB, but that has nothing to do with whether there should be an ifdef around SPRN_MD_CTR. Euh, ok, but then we have to fix it in the whole function, not only in this block. Do you think it is worth doing it ? Then we are back to the problem we discussed some months ago which is that the 8xx is decrementing the MD_CTR after writting a TLB entry, and if pinning is activated it decrements it out of the pinnable area. So it would still be needed to: * Reposition it for each entry for when the pinning is activated * Make sure we set it out of the area at the end when the pinning is not active hence the area not protected. * Then we should probably reverse the entries, start at 31 and go down to 28 instead of going from 28 to 31 as do today. But is it worth doing such a big change which will not add anything functionnaly speaking ? Christophe ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org
[PATCH v1 3/4] powerpc/512x: clk: support MPC5121/5123/5125 SoC variants
improve the common clock support code for MPC512x
- expand the CCM register set declaration with MPC5125 related registers
(which reside in the previously reserved area)
- tell the MPC5121, MPC5123, and MPC5125 SoC variants apart, and derive
the availability of components and their clocks from the detected SoC
(MBX, AXE, VIU, SPDIF, PATA, SATA, PCI, second FEC, second SDHC,
number of PSC components, type of NAND flash controller,
interpretation of the CPMF bitfield, PSC/CAN mux0 stage input clocks,
output clocks on SoC pins)
- add backwards compatibility (allow operation against a device tree
which lacks clock related specs) for MPC5125 FECs, too
telling SoC variants apart and adjusting the clock tree's generation
occurs at runtime, a common generic binary supports all of the chips
the MPC5125 approach to the NFC clock (one register with two counters
for the high and low periods of the clock) is not implemented, as there
are no users and there is no common implementation which supports this
kind of clock -- the new implementation would be unused and could not
get verified, so it shall wait until there is demand
Signed-off-by: Gerhard Sittig g...@denx.de
---
arch/powerpc/include/asm/mpc5121.h|7 +-
arch/powerpc/platforms/512x/clock-commonclk.c | 339 +
include/dt-bindings/clock/mpc512x-clock.h |9 +-
3 files changed, 309 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/include/asm/mpc5121.h
b/arch/powerpc/include/asm/mpc5121.h
index 887d3d6133e3..4a69cd1d5041 100644
--- a/arch/powerpc/include/asm/mpc5121.h
+++ b/arch/powerpc/include/asm/mpc5121.h
@@ -37,7 +37,12 @@ struct mpc512x_ccm {
u32 cccr; /* CFM Clock Control Register */
u32 dccr; /* DIU Clock Control Register */
u32 mscan_ccr[4]; /* MSCAN Clock Control Registers */
- u8 res[0x98]; /* Reserved */
+ u32 out_ccr[4]; /* OUT CLK Configure Registers */
+ u32 rsv0[2];/* Reserved */
+ u32 scfr3; /* System Clock Frequency Register 3 */
+ u32 rsv1[3];/* Reserved */
+ u32 spll_lock_cnt; /* System PLL Lock Counter */
+ u8 res[0x6c]; /* Reserved */
};
/*
diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c
b/arch/powerpc/platforms/512x/clock-commonclk.c
index b5190fcb81bb..af8d50d58af5 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -36,7 +36,8 @@ enum {
#define NR_PSCS12
#define NR_MSCANS 4
#define NR_SPDIFS 1
-#define NR_MCLKS (NR_PSCS + NR_MSCANS + NR_SPDIFS)
+#define NR_OUTCLK 4
+#define NR_MCLKS (NR_PSCS + NR_MSCANS + NR_SPDIFS + NR_OUTCLK)
/* extend the public set of clocks by adding internal slots for management */
enum {
@@ -46,11 +47,11 @@ enum {
MPC512x_CLK_DDR,
MPC512x_CLK_MEM,
MPC512x_CLK_IIM,
- MPC512x_CLK_SDHC_2,
/* intermediates in div+gate combos or fractional dividers */
MPC512x_CLK_DDR_UG,
MPC512x_CLK_SDHC_x4,
MPC512x_CLK_SDHC_UG,
+ MPC512x_CLK_SDHC2_UG,
MPC512x_CLK_DIU_x4,
MPC512x_CLK_DIU_UG,
MPC512x_CLK_MBX_BUS_UG,
@@ -76,6 +77,144 @@ static struct clk_onecell_data clk_data;
static struct mpc512x_ccm __iomem *clkregs;
static DEFINE_SPINLOCK(clklock);
+/* SoC variants {{{ */
+
+/*
+ * tell SoC variants apart as they are rather similar yet not identical,
+ * cache the result in an enum to not repeatedly run the expensive OF test
+ *
+ * MPC5123 is an MPC5121 without the MBX graphics accelerator
+ *
+ * MPC5125 has many more differences: no MBX, no AXE, no VIU, no SPDIF,
+ * no PATA, no SATA, no PCI, two FECs (of different compatibility name),
+ * only 10 PSCs (of different compatibility name), two SDHCs, different
+ * NFC IP block, output clocks, system PLL status query, different CPMF
+ * interpretation, no CFM, different fourth PSC/CAN mux0 input -- yet
+ * those differences can get folded into this clock provider support
+ * code and don't warrant a separate highly redundant implementation
+ */
+
+static enum soc_type {
+ MPC512x_SOC_MPC5121,
+ MPC512x_SOC_MPC5123,
+ MPC512x_SOC_MPC5125,
+} soc;
+
+static void mpc512x_clk_determine_soc(void)
+{
+ if (of_machine_is_compatible(fsl,mpc5121)) {
+ soc = MPC512x_SOC_MPC5121;
+ return;
+ }
+ if (of_machine_is_compatible(fsl,mpc5123)) {
+ soc = MPC512x_SOC_MPC5123;
+ return;
+ }
+ if (of_machine_is_compatible(fsl,mpc5125)) {
+ soc = MPC512x_SOC_MPC5125;
+ return;
+ }
+}
+
+static bool soc_has_mbx(void)
+{
+ if (soc == MPC512x_SOC_MPC5121)
+ return true;
+ return false;
+}
+
+static bool soc_has_axe(void)
+{
+ if (soc == MPC512x_SOC_MPC5125)
+
[PATCH v1 0/4] powerpc/512x: update COMMON_CLK support for MPC5125
this series improves the previously introduced common clock support for
MPC512x such that SoC variants 5123 and 5125 get addressed appropriately
(MPC5125 turned out to be rather different from MPC5121 than I perceived
before -- there is much more than just two FECs and no MBX)
thus this series depends on add COMMON_CLK support for PowerPC MPC512x
(v6 sent in 1385851897-23475-1-git-send-email-...@denx.de, applicable
on top of v3.13-rc1 or later, currently applied to mpc5xxx -next,
available at git://git.denx.de/linux-2.6-agust.git next)
this series does not address the issue of outdated or missing device
tree binding documentation for MPC512x peripherals -- that's the scope
of a pending separate series
v1 initial submission (2013-12-10)
- enforce an even divider value for SDHC (on all MPC512x variants)
- tell 5121/5123/5125 SoC variants apart and only register the
appropriate set of clock items (i.e. refuse to access unused and
reserved bits, and support those components which are only found on
MPC5125)
- update the MPC5125 tower board DTS (although the code still works in
the absence of device tree clock specs)
the series passes 'checkpatch.pl --strict' except for two warnings which
cannot get fixed because linux/clk-provider.h dictates the data type
and fixing the warning would break the build
WARNING: static const char * array should probably be static const char *
const
#256: FILE: arch/powerpc/platforms/512x/clock-commonclk.c:500:
+static const char *parent_names_mux0_spdif[] = {
WARNING: static const char * array should probably be static const char *
const
#260: FILE: arch/powerpc/platforms/512x/clock-commonclk.c:504:
+static const char *parent_names_mux0_canin[] = {
total: 0 errors, 2 warnings, 0 checks, 495 lines checked
the series was build-tested, and was run-tested on the MPC5121 ADS board
Matteo, can you verify the crystal frequency in the DTS update, please?
And that v3.13-rc kernels with v6 of the COMMON_CLK introduction for
MPC512x plus this series for MPC5125 operate your peripherals, both with
an updated device tree as well as with a former device tree that lacks
clock specs? Thank you! Setting CONFIG_COMMON_CLK_DEBUG=y in your
.config and eyeballing /sys/kernel/debug/clk/clk_summary will help you.
Gerhard Sittig (4):
powerpc/512x: clk: minor comment updates
powerpc/512x: clk: enforce even SDHC divider values
powerpc/512x: clk: support MPC5121/5123/5125 SoC variants
powerpc/512x: dts: add MPC5125 clock specs
arch/powerpc/boot/dts/mpc5125twr.dts | 53 +++-
arch/powerpc/include/asm/mpc5121.h|7 +-
arch/powerpc/platforms/512x/clock-commonclk.c | 369 +
include/dt-bindings/clock/mpc512x-clock.h |9 +-
4 files changed, 386 insertions(+), 52 deletions(-)
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v1 1/4] powerpc/512x: clk: minor comment updates
adjust (expand on or move) a few comments,
add markers for easier navigation around helpers
Signed-off-by: Gerhard Sittig g...@denx.de
---
arch/powerpc/platforms/512x/clock-commonclk.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c
b/arch/powerpc/platforms/512x/clock-commonclk.c
index 189be4a4cb42..079eb1137260 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -76,6 +76,8 @@ static struct clk_onecell_data clk_data;
static struct mpc512x_ccm __iomem *clkregs;
static DEFINE_SPINLOCK(clklock);
+/* common clk API wrappers {{{ */
+
/* convenience wrappers around the common clk API */
static inline struct clk *mpc512x_clk_fixed(const char *name, int rate)
{
@@ -139,6 +141,8 @@ static inline struct clk *mpc512x_clk_muxed(const char
*name,
reg, pos, len, muxflags, clklock);
}
+/* }}} common clk API wrappers */
+
/* helper to isolate a bit field from a register */
static inline int get_bit_field(uint32_t __iomem *reg, uint8_t pos, uint8_t
len)
{
@@ -308,6 +312,8 @@ static void mpc512x_clk_setup_ref_clock(struct device_node
*np, int bus_freq,
}
}
+/* MCLK helpers {{{ */
+
/*
* helper code for the MCLK subtree setup
*
@@ -338,8 +344,8 @@ static void mpc512x_clk_setup_ref_clock(struct device_node
*np, int bus_freq,
/*
* note that this declaration raises a checkpatch warning, but
- * it's the very data type which linux/clk-provider.h expects,
- * making this declaration pass checkpatch will break compilation
+ * it's the very data type dictated by linux/clk-provider.h,
+ * fixing this warning will break compilation
*/
static const char *parent_names_mux0[] = {
sys, ref, psc-mclk-in, spdif-tx,
@@ -512,6 +518,8 @@ static void mpc512x_clk_setup_mclk(struct mclk_setup_data
*entry, size_t idx)
}
}
+/* }}} MCLK helpers */
+
static void mpc512x_clk_setup_clock_tree(struct device_node *np, int busfreq)
{
int sys_mul, sys_div, ips_div;
@@ -549,8 +557,8 @@ static void mpc512x_clk_setup_clock_tree(struct device_node
*np, int busfreq)
clks[MPC512x_CLK_IPS] = mpc512x_clk_divtable(ips, csb,
clkregs-scfr1, 23, 3,
divtab_2346);
-
/* now setup anything below SYS and CSB and IPS */
+
clks[MPC512x_CLK_DDR_UG] = mpc512x_clk_factor(ddr-ug, sys, 1, 2);
clks[MPC512x_CLK_SDHC_x4] = mpc512x_clk_factor(sdhc-x4, csb, 4, 1);
clks[MPC512x_CLK_SDHC_UG] = mpc512x_clk_divider(sdhc-ug, sdhc-x4, 0,
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] KVM: PPC: Use schedule instead of cond_resched
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
We already checked need_resched. So we can call schedule directly
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
NOTE: This patch also work around a regression upstream w.r.t PR KVM
BUG: soft lockup - CPU#0 stuck for 23s! [qemu-system-ppc:4394]
Modules linked in:
CPU: 0 PID: 4394 Comm: qemu-system-ppc Not tainted 3.13.0-rc3+ #98
task: c001d0788400 ti: c001dca0 task.ti: c001dca0
NIP: c082dd80 LR: c0081ae0 CTR: c0062ba0
REGS: c001dca02f70 TRAP: 0901 Not tainted (3.13.0-rc3+)
MSR: 80009032 SF,EE,ME,IR,DR,RI CR: 24822024 XER:
CFAR: c0081adc SOFTE: 1
GPR00: c0081ae0 c001dca031f0 c0d67ab0 0001
GPR04: 7102 0001 0189a0d786b7 018c
GPR08: 0001 c0da
GPR12: 0c00 cfef
NIP [c082dd80] ._cond_resched+0x0/0x40
LR [c0081ae0] .kvmppc_prepare_to_enter+0x2a0/0x2e0
Call Trace:
[c001dca031f0] [c0081ae0] .kvmppc_prepare_to_enter+0x2a0/0x2e0
(unreliable)
[c001dca03290] [c008f2cc] .kvmppc_handle_exit_pr+0xec/0xa40
[c001dca03340] [c00918c4] kvm_start_lightweight+0xac/0xbc
[c001dca03510] [c008efe0] .kvmppc_vcpu_run_pr+0x130/0x2a0
[c001dca039e0] [c00855bc] .kvmppc_vcpu_run+0x2c/0x40
[c001dca03a50] [c0082c94] .kvm_arch_vcpu_ioctl_run+0x54/0x1b0
[c001dca03ae0] [c007d5f8] .kvm_vcpu_ioctl+0x478/0x740
[c001dca03ca0] [c0218864] .do_vfs_ioctl+0x4a4/0x760
[c001dca03d80] [c0218b78] .SyS_ioctl+0x58/0xb0
[c001dca03e30] [c0009e58] syscall_exit+0x0/0x98
Instruction dump:
e92d0260 e94911c0 812a0004 5529f07e 5529103e 912a0004 38210080 e8010010
ebc1fff0 ebe1fff8 7c0803a6 4e800020 7c0802a6 3860 f8010010 f821ff91
arch/powerpc/kvm/powerpc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index e4d511c8b38b..6a49b23a3276 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -74,7 +74,7 @@ int kvmppc_prepare_to_enter(struct kvm_vcpu *vcpu)
while (true) {
if (need_resched()) {
local_irq_enable();
- cond_resched();
+ schedule();
local_irq_disable();
continue;
}
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc 8xx: Loading kernels over 8Mbytes without CONFIG_PIN_TLB
Today, the only way to load kernels whose size is greater than 8Mbytes is to activate CONFIG_PIN_TLB. Otherwise, the physical memory initially mapped is limited to 8Mbytes. This patch adds the capability to select the size of initial memory between 8/16/24 Mbytes and this is regardless of whether CONFIG_PIN_TLB is active or not. It allows to load big kernels (for instance when activating CONFIG_LOCKDEP_SUPPORT) without having to activate CONFIG_PIN_TLB. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr diff -ur a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -980,6 +980,29 @@ config PIN_TLB bool Pinned Kernel TLBs (860 ONLY) depends on ADVANCED_OPTIONS 8xx + +choice + prompt Initial Data Memory Mapped on 8xx + default 8xx_MAP_8M + depends on ADVANCED_OPTIONS 8xx + +config 8xx_INIT_MAP_8M + bool 8 Mbytes + +config 8xx_INIT_MAP_16M + bool 16 Mbytes + +config 8xx_INIT_MAP_24M + bool 24 Mbytes + +endchoice + +config 8xx_INIT_MAP + hex + default 0x0180 if 8xx_INIT_MAP_24M + default 0x0100 if 8xx_INIT_MAP_16M + default 0x0080 + endmenu if PPC64 diff -ur a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S --- a/arch/powerpc/kernel/head_8xx.S +++ b/arch/powerpc/kernel/head_8xx.S @@ -841,11 +841,13 @@ ori r8, r8, MI_BOOTINIT|0x2 /* Inhibit cache -- Cort */ mtspr SPRN_MD_RPN, r8 -#ifdef CONFIG_PIN_TLB +#if defined (CONFIG_8xx_INIT_MAP_16M) || defined (CONFIG_8xx_INIT_MAP_24M) /* Map two more 8M kernel data pages. */ +#ifdef CONFIG_PIN_TLB addir10, r10, 0x0100 mtspr SPRN_MD_CTR, r10 +#endif lis r8, KERNELBASE@h/* Create vaddr for TLB */ addis r8, r8, 0x0080 /* Add 8M */ @@ -858,15 +860,19 @@ addis r11, r11, 0x0080/* Add 8M */ mtspr SPRN_MD_RPN, r11 +#ifdef CONFIG_8xx_INIT_MAP_24M +#ifdef CONFIG_PIN_TLB addir10, r10, 0x0100 mtspr SPRN_MD_CTR, r10 +#endif addis r8, r8, 0x0080 /* Add 8M */ mtspr SPRN_MD_EPN, r8 mtspr SPRN_MD_TWC, r9 addis r11, r11, 0x0080/* Add 8M */ mtspr SPRN_MD_RPN, r11 -#endif +#endif /* CONFIG_8xx_INIT_MAP_24M */ +#endif /* CONFIG_8xx_INIT_MAP_16M || CONFIG_8xx_INIT_MAP_24M */ /* Since the cache is enabled according to the information we * just loaded into the TLB, invalidate and enable the caches here. diff -ur a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c --- a/arch/powerpc/mm/init_32.c +++ b/arch/powerpc/mm/init_32.c @@ -213,12 +213,8 @@ */ BUG_ON(first_memblock_base != 0); -#ifdef CONFIG_PIN_TLB /* 8xx can only access 24MB at the moment */ - memblock_set_current_limit(min_t(u64, first_memblock_size, 0x0180)); -#else - /* 8xx can only access 8MB at the moment */ - memblock_set_current_limit(min_t(u64, first_memblock_size, 0x0080)); -#endif + memblock_set_current_limit(min_t(u64, first_memblock_size, + CONFIG_8xx_INIT_MAP)); } #endif /* CONFIG_8xx */ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] KVM: PPC: Use schedule instead of cond_resched
Alexander Graf ag...@suse.de writes: On 10.12.2013, at 15:21, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com We already checked need_resched. So we can call schedule directly Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com The real fix for the issue you're seeing is https://lkml.org/lkml/2013/11/28/241 True, I mentioned that in the thread https://lkml.org/lkml/2013/12/9/64 But do we need to do cond_resched after we checked for need_resched() ? -aneesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [V2 PATCH 3/3] powerpc: Fix Unaligned LE Floating Point Loads and Stores
On Thu, Oct 31, 2013 at 01:38:58PM -0500, Tom wrote:
From: Tom Musta tommu...@gmail.com
This patch addresses unaligned single precision floating point loads
and stores in the single-step code. The old implementation
improperly treated an 8 byte structure as an array of two 4 byte
words, which is a classic little endian bug.
Signed-off-by: Tom Musta tommu...@gmail.com
---
arch/powerpc/lib/sstep.c | 52 +++--
1 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index c8743e1..1cfd150 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -355,22 +355,36 @@ static int __kprobes do_fp_load(int rn, int
(*func)(int, unsigned long),
struct pt_regs *regs)
{
int err;
- unsigned long val[sizeof(double) / sizeof(long)];
+ union {
+ double dbl;
+ unsigned long ul[2];
+ struct {
+#ifdef __BIG_ENDIAN__
+ unsigned _pad_;
+ unsigned word;
+#endif
+#ifdef __LITTLE_ENDIAN__
+ unsigned word;
+ unsigned _pad_;
+#endif
+ } single;
+ } data;
unsigned long ptr;
if (!address_ok(regs, ea, nb))
return -EFAULT;
if ((ea 3) == 0)
return (*func)(rn, ea);
- ptr = (unsigned long) val[0];
+ ptr = (unsigned long) data.ul;
if (sizeof(unsigned long) == 8 || nb == 4) {
- err = read_mem_unaligned(val[0], ea, nb, regs);
- ptr += sizeof(unsigned long) - nb;
+ err = read_mem_unaligned(data.ul[0], ea, nb, regs);
+ if (nb == 4)
+ ptr = (unsigned long)(data.single.word);
} else {
/* reading a double on 32-bit */
- err = read_mem_unaligned(val[0], ea, 4, regs);
+ err = read_mem_unaligned(data.ul[0], ea, 4, regs);
if (!err)
- err = read_mem_unaligned(val[1], ea + 4, 4, regs);
+ err = read_mem_unaligned(data.ul[1], ea + 4, 4, regs);
This breaks 32-bit big-endian (as well as making the code longer and
more complex).
In fact, to make this work for 64-bit little-endian, all you really
needed to do was ifdef out the statement:
ptr += sizeof(unsigned long) - nb;
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [V2 PATCH 3/3] powerpc: Fix Unaligned LE Floating Point Loads and Stores
On Wed, Dec 11, 2013 at 02:54:40PM +1100, Paul Mackerras wrote:
On Thu, Oct 31, 2013 at 01:38:58PM -0500, Tom wrote:
From: Tom Musta tommu...@gmail.com
This patch addresses unaligned single precision floating point loads
and stores in the single-step code. The old implementation
improperly treated an 8 byte structure as an array of two 4 byte
words, which is a classic little endian bug.
Signed-off-by: Tom Musta tommu...@gmail.com
---
arch/powerpc/lib/sstep.c | 52
+++--
1 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index c8743e1..1cfd150 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -355,22 +355,36 @@ static int __kprobes do_fp_load(int rn, int
(*func)(int, unsigned long),
struct pt_regs *regs)
{
int err;
- unsigned long val[sizeof(double) / sizeof(long)];
+ union {
+ double dbl;
+ unsigned long ul[2];
+ struct {
+#ifdef __BIG_ENDIAN__
+ unsigned _pad_;
+ unsigned word;
+#endif
+#ifdef __LITTLE_ENDIAN__
+ unsigned word;
+ unsigned _pad_;
+#endif
+ } single;
+ } data;
unsigned long ptr;
if (!address_ok(regs, ea, nb))
return -EFAULT;
if ((ea 3) == 0)
return (*func)(rn, ea);
- ptr = (unsigned long) val[0];
+ ptr = (unsigned long) data.ul;
if (sizeof(unsigned long) == 8 || nb == 4) {
- err = read_mem_unaligned(val[0], ea, nb, regs);
- ptr += sizeof(unsigned long) - nb;
+ err = read_mem_unaligned(data.ul[0], ea, nb, regs);
+ if (nb == 4)
+ ptr = (unsigned long)(data.single.word);
} else {
/* reading a double on 32-bit */
- err = read_mem_unaligned(val[0], ea, 4, regs);
+ err = read_mem_unaligned(data.ul[0], ea, 4, regs);
if (!err)
- err = read_mem_unaligned(val[1], ea + 4, 4, regs);
+ err = read_mem_unaligned(data.ul[1], ea + 4, 4, regs);
This breaks 32-bit big-endian (as well as making the code longer and
more complex).
And in fact none of this code will get executed in little-endian mode
anyway, since we still have this in the middle of emulate_step():
/*
* Following cases are for loads and stores, so bail out
* if we're in little-endian mode.
*/
if (regs-msr MSR_LE)
return 0;
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: set default kernel thread priority to medium-low
On Tue, 2013-12-10 at 08:39 +0100, Philippe Bergheaud wrote: All the important PThread locking occurs in GLIBC libpthread.so For scaling to large core counts we need to stay out of the kernel and scheduler as much as possible which implies increasing the spin time in user mode. For POWER implementations with SMT this implies that user mode needs to manage SMT priority for spinning and active (in the critical region) threads. Libpthread must be able to raise and lower the the SMT priority versus the default to be effective. This lowers the default kernel thread priority from medium to medium-low. Hi Philippe, It would be nice if you could make an assertion about what the state of HMT handling should be once your patch is applied. I think it's: * The kernel should use HMT_MEDIUM_LOW as it's default priority * The kernel should use HMT_LOW as it's low priority Which would imply: * The kernel should not use HMT_MEDIUM anywhere .. * Nor should it use any of the other higher HMT modes. Do you agree? The reason I ask is I still see HMT_MEDIUM used in a few places, and it's not clear to me if that is correct. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
