[PATCH v2] pstore: Adjust buffer size for compression for smaller registered buffers
When backends (ex: efivars) have smaller registered buffers, the big_oops_buf
is quite too big for them as number of repeated occurences in the text captured
will be less. Patch takes care of adjusting the buffer size based on the
registered buffer size. cmpr values has been arrived after doing experiments
with
plain text for buffers of size 1k - 4k (Smaller the buffer size repeated
occurence
will be less) and with sample crash log for buffers ranging from 4k - 10k.
Reported-by: Seiji Aguchi seiji.agu...@hds.com
Signed-off-by: Aruna Balakrishnaiah ar...@linux.vnet.ibm.com
---
Changes from v1:
Retain the cmpr = 45 for buffers ranging of size 4k - 10k. 45 seems to
work.
I added an additional headroom of 3%. Revert it back to 45.
fs/pstore/platform.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 4ffb7ab..57b4219 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -195,8 +195,29 @@ error:
static void allocate_buf_for_compression(void)
{
size_t size;
+ size_t cmpr;
+
+ switch (psinfo-bufsize) {
+ /* buffer range for efivars */
+ case 1000 ... 2000:
+ cmpr = 56;
+ break;
+ case 2001 ... 3000:
+ cmpr = 54;
+ break;
+ case 3001 ... 3999:
+ cmpr = 52;
+ break;
+ /* buffer range for nvram, erst */
+ case 4000 ... 1:
+ cmpr = 45;
+ break;
+ default:
+ cmpr = 60;
+ break;
+ }
- big_oops_buf_sz = (psinfo-bufsize * 100) / 45;
+ big_oops_buf_sz = (psinfo-bufsize * 100) / cmpr;
big_oops_buf = kmalloc(big_oops_buf_sz, GFP_KERNEL);
if (big_oops_buf) {
size = max(zlib_deflate_workspacesize(WINDOW_BITS, MEM_LEVEL),
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy in device tree
-Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Wednesday, September 11, 2013 11:13 PM To: Zhao Qiang-B45475 Cc: linuxppc-dev@lists.ozlabs.org; Liu Shengzhou-B36685 Subject: Re: [PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy in device tree On Sep 10, 2013, at 10:49 PM, Zhao Qiang wrote: Since P1010RDB-PA and P1010RDB-PB boards use different external PHY interrupt signals. And actually the PHY interrupt is not used effectively with corresponding interrupt handler. So we can remove the interrupts node without side-effect to comply with both P1010RDB-PA and P1010RDB-PB. Signed-off-by: Shengzhou Liu shengzhou@freescale.com Signed-off-by: Zhao Qiang b45...@freescale.com --- arch/powerpc/boot/dts/p1010rdb.dtsi | 3 --- 1 file changed, 3 deletions(-) NAK. The device tree should represent the HW not what drivers decide to do with it. If different board revs have different interrupt signals than create dts's to handle the 2 board revs. - k You mean we need to create p1010rdb-pa.dtsi and p1010rdb-pb.dtsi replacing current p1010rdb.dtsi just because of the unused phy interrupt? and phy interrupt is not present in those dts of P3/P4/P5 platforms. Actually currently many hardware are not present in dts, such as a lot of i2c devices, temperature monitor, etc. -Shengzhou ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/2] powerpc/85xx: introduce cornet_generic machine
This patch series introduces a common machine to support p2041rdb, p3041ds, p4080ds, p5020ds, p5040ds, t4240qds and b4qds to avoid the code duplication. Boot test on p5020ds and p4080ds. Kevin Hao (2): powerpc/85xx: introduce cornet_generic machine powerpc/85xx: remove the unneeded corenet_ds.h arch/powerpc/platforms/85xx/Kconfig | 10 arch/powerpc/platforms/85xx/Makefile | 8 +-- arch/powerpc/platforms/85xx/b4_qds.c | 97 arch/powerpc/platforms/85xx/corenet_ds.c | 86 arch/powerpc/platforms/85xx/corenet_ds.h | 19 --- arch/powerpc/platforms/85xx/p2041_rdb.c | 87 arch/powerpc/platforms/85xx/p3041_ds.c | 89 - arch/powerpc/platforms/85xx/p4080_ds.c | 87 arch/powerpc/platforms/85xx/p5020_ds.c | 93 -- arch/powerpc/platforms/85xx/p5040_ds.c | 84 --- arch/powerpc/platforms/85xx/t4240_qds.c | 93 -- 11 files changed, 97 insertions(+), 656 deletions(-) delete mode 100644 arch/powerpc/platforms/85xx/b4_qds.c delete mode 100644 arch/powerpc/platforms/85xx/corenet_ds.h delete mode 100644 arch/powerpc/platforms/85xx/p2041_rdb.c delete mode 100644 arch/powerpc/platforms/85xx/p3041_ds.c delete mode 100644 arch/powerpc/platforms/85xx/p4080_ds.c delete mode 100644 arch/powerpc/platforms/85xx/p5020_ds.c delete mode 100644 arch/powerpc/platforms/85xx/p5040_ds.c delete mode 100644 arch/powerpc/platforms/85xx/t4240_qds.c -- 1.8.3.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/85xx: introduce cornet_generic machine
In the current kernel, the board files for p2041rdb, p3041ds, p4080ds, p5020ds, p5040ds, t4240qds and b4qds are almost the same except the machine name. So this introduces a cornet_generic machine to support all these boards to avoid the code duplication. Signed-off-by: Kevin Hao haoke...@gmail.com --- This patch is based on http://patchwork.ozlabs.org/patch/274390/ arch/powerpc/platforms/85xx/Kconfig | 10 arch/powerpc/platforms/85xx/Makefile | 8 +-- arch/powerpc/platforms/85xx/b4_qds.c | 97 arch/powerpc/platforms/85xx/corenet_ds.c | 86 arch/powerpc/platforms/85xx/p2041_rdb.c | 87 arch/powerpc/platforms/85xx/p3041_ds.c | 89 - arch/powerpc/platforms/85xx/p4080_ds.c | 87 arch/powerpc/platforms/85xx/p5020_ds.c | 93 -- arch/powerpc/platforms/85xx/p5040_ds.c | 84 --- arch/powerpc/platforms/85xx/t4240_qds.c | 93 -- 10 files changed, 97 insertions(+), 637 deletions(-) delete mode 100644 arch/powerpc/platforms/85xx/b4_qds.c delete mode 100644 arch/powerpc/platforms/85xx/p2041_rdb.c delete mode 100644 arch/powerpc/platforms/85xx/p3041_ds.c delete mode 100644 arch/powerpc/platforms/85xx/p4080_ds.c delete mode 100644 arch/powerpc/platforms/85xx/p5020_ds.c delete mode 100644 arch/powerpc/platforms/85xx/p5040_ds.c delete mode 100644 arch/powerpc/platforms/85xx/t4240_qds.c diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig index de2eb93..3bee943 100644 --- a/arch/powerpc/platforms/85xx/Kconfig +++ b/arch/powerpc/platforms/85xx/Kconfig @@ -228,6 +228,7 @@ config P2041_RDB select GPIO_MPC8XXX select HAS_RAPIDIO select PPC_EPAPR_HV_PIC + select CORENET_GENERIC help This option enables support for the P2041 RDB board @@ -241,6 +242,7 @@ config P3041_DS select GPIO_MPC8XXX select HAS_RAPIDIO select PPC_EPAPR_HV_PIC + select CORENET_GENERIC help This option enables support for the P3041 DS board @@ -254,6 +256,7 @@ config P4080_DS select GPIO_MPC8XXX select HAS_RAPIDIO select PPC_EPAPR_HV_PIC + select CORENET_GENERIC help This option enables support for the P4080 DS board @@ -278,6 +281,7 @@ config P5020_DS select GPIO_MPC8XXX select HAS_RAPIDIO select PPC_EPAPR_HV_PIC + select CORENET_GENERIC help This option enables support for the P5020 DS board @@ -292,6 +296,7 @@ config P5040_DS select GPIO_MPC8XXX select HAS_RAPIDIO select PPC_EPAPR_HV_PIC + select CORENET_GENERIC help This option enables support for the P5040 DS board @@ -323,6 +328,7 @@ config T4240_QDS select GPIO_MPC8XXX select HAS_RAPIDIO select PPC_EPAPR_HV_PIC + select CORENET_GENERIC help This option enables support for the T4240 QDS board @@ -337,6 +343,7 @@ config B4_QDS select ARCH_REQUIRE_GPIOLIB select HAS_RAPIDIO select PPC_EPAPR_HV_PIC + select CORENET_GENERIC help This option enables support for the B4 QDS board The B4 application development system B4 QDS is a complete @@ -348,3 +355,6 @@ endif # FSL_SOC_BOOKE config TQM85xx bool + +config CORENET_GENERIC + bool diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile index 53c9f75..a6c281d 100644 --- a/arch/powerpc/platforms/85xx/Makefile +++ b/arch/powerpc/platforms/85xx/Makefile @@ -18,13 +18,7 @@ obj-$(CONFIG_P1010_RDB) += p1010rdb.o obj-$(CONFIG_P1022_DS)+= p1022_ds.o obj-$(CONFIG_P1022_RDK) += p1022_rdk.o obj-$(CONFIG_P1023_RDS) += p1023_rds.o -obj-$(CONFIG_P2041_RDB) += p2041_rdb.o corenet_ds.o -obj-$(CONFIG_P3041_DS)+= p3041_ds.o corenet_ds.o -obj-$(CONFIG_P4080_DS)+= p4080_ds.o corenet_ds.o -obj-$(CONFIG_P5020_DS)+= p5020_ds.o corenet_ds.o -obj-$(CONFIG_P5040_DS)+= p5040_ds.o corenet_ds.o -obj-$(CONFIG_T4240_QDS) += t4240_qds.o corenet_ds.o -obj-$(CONFIG_B4_QDS) += b4_qds.o corenet_ds.o +obj-$(CONFIG_CORENET_GENERIC) += corenet_ds.o obj-$(CONFIG_STX_GP3)+= stx_gp3.o obj-$(CONFIG_TQM85xx)+= tqm85xx.o obj-$(CONFIG_SBC8548) += sbc8548.o diff --git a/arch/powerpc/platforms/85xx/b4_qds.c b/arch/powerpc/platforms/85xx/b4_qds.c deleted file mode 100644 index 0f18663..000 --- a/arch/powerpc/platforms/85xx/b4_qds.c +++ /dev/null @@ -1,97 +0,0 @@ -/* - * B4 QDS Setup - * Should apply for QDS platform of B4860 and it's personalities. - * viz B4860/B4420/B4220QDS - * - * Copyright 2012 Freescale Semiconductor Inc. - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General
[PATCH 2/2] powerpc/85xx: remove the unneeded corenet_ds.h
With the patch (powerpc/85xx: introduce cornet_generic machine) this file becomes useless. Just delete it. Signed-off-by: Kevin Hao haoke...@gmail.com --- arch/powerpc/platforms/85xx/corenet_ds.h | 19 --- 1 file changed, 19 deletions(-) delete mode 100644 arch/powerpc/platforms/85xx/corenet_ds.h diff --git a/arch/powerpc/platforms/85xx/corenet_ds.h b/arch/powerpc/platforms/85xx/corenet_ds.h deleted file mode 100644 index ddd700b..000 --- a/arch/powerpc/platforms/85xx/corenet_ds.h +++ /dev/null @@ -1,19 +0,0 @@ -/* - * Corenet based SoC DS Setup - * - * Copyright 2009 Freescale Semiconductor Inc. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - */ - -#ifndef CORENET_DS_H -#define CORENET_DS_H - -extern void __init corenet_ds_pic_init(void); -extern void __init corenet_ds_setup_arch(void); -extern int __init corenet_ds_publish_devices(void); - -#endif -- 1.8.3.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc 8xx: Reverting commit e0908085fc2391c85b85fb814ae1df377c8e0dcb which has become useless
Christophe Leroy christophe.le...@c-s.fr wrote on 2013/09/11 17:50:28: From: Christophe Leroy christophe.le...@c-s.fr To: Benjamin Herrenschmidt b...@kernel.crashing.org, Paul Mackerras pau...@samba.org, Cc: linux-ker...@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Joakim Tjernlund joakim.tjernl...@transmode.se Date: 2013/09/11 18:43 Subject: [PATCH] powerpc 8xx: Reverting commit e0908085fc2391c85b85fb814ae1df377c8e0dcb which has become useless The commit e0908085fc2391c85b85fb814ae1df377c8e0dcb is not needed anymore. The issue was because dcbst wrongly sets the store bit when causing a DTLB error, but this is now fixed by commit 0a2ab51ffb8dfdf51402dcfb446629648c96bc78 which handles the buggy dcbx instructions on data page faults on the 8xx. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr Acked-by: Joakim Tjernlund joakim.tjernl...@transmode.se Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2][RFC][v3] pci: fsl: derive the common PCI driver to drivers/pci/host
The Freescale's Layerscape series processors will use ARM cores.
The LS1's PCIe controllers is the same as T4240's. So it's better
the PCIe controller driver can support PowerPC and ARM
simultaneously. This patch is for this purpose. It derives
the common functions from arch/powerpc/sysdev/fsl_pci.c to
drivers/pci/host/pci-fsl.c and leaves the architecture-specific
functions which should be implemented in arch related files.
Signed-off-by: Minghuan Lian minghuan.l...@freescale.com
---
Based on upstream master
Change log:
v3:
1. Add the new patch that only contains the code movement.
V2:
NULL
arch/powerpc/sysdev/fsl_pci.c | 521 +-
arch/powerpc/sysdev/fsl_pci.h | 89
.../sysdev/fsl_pci.c = drivers/pci/host/pci-fsl.c | 591 +
.../sysdev/fsl_pci.h = include/linux/fsl/pci.h| 40 +-
4 files changed, 7 insertions(+), 1234 deletions(-)
copy arch/powerpc/sysdev/fsl_pci.c = drivers/pci/host/pci-fsl.c (54%)
copy arch/powerpc/sysdev/fsl_pci.h = include/linux/fsl/pci.h (81%)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index ccfb50d..a189ff0 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -27,6 +27,7 @@
#include linux/log2.h
#include linux/slab.h
#include linux/uaccess.h
+#include linux/fsl/pci.h
#include asm/io.h
#include asm/prom.h
@@ -58,57 +59,8 @@ static void quirk_fsl_pcie_header(struct pci_dev *dev)
return;
}
-static int fsl_indirect_read_config(struct pci_bus *, unsigned int,
- int, int, u32 *);
-
-static int fsl_pcie_check_link(struct pci_controller *hose)
-{
- u32 val = 0;
-
- if (hose-indirect_type PPC_INDIRECT_TYPE_FSL_CFG_REG_LINK) {
- if (hose-ops-read == fsl_indirect_read_config) {
- struct pci_bus bus;
- bus.number = hose-first_busno;
- bus.sysdata = hose;
- bus.ops = hose-ops;
- indirect_read_config(bus, 0, PCIE_LTSSM, 4, val);
- } else
- early_read_config_dword(hose, 0, 0, PCIE_LTSSM, val);
- if (val PCIE_LTSSM_L0)
- return 1;
- } else {
- struct ccsr_pci __iomem *pci = hose-private_data;
- /* for PCIe IP rev 3.0 or greater use CSR0 for link state */
- val = (in_be32(pci-pex_csr0) PEX_CSR0_LTSSM_MASK)
-PEX_CSR0_LTSSM_SHIFT;
- if (val != PEX_CSR0_LTSSM_L0)
- return 1;
- }
-
- return 0;
-}
-
-static int fsl_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);
-
- if (fsl_pcie_check_link(hose))
- hose-indirect_type |= PPC_INDIRECT_TYPE_NO_PCIE_LINK;
- else
- hose-indirect_type = ~PPC_INDIRECT_TYPE_NO_PCIE_LINK;
-
- return indirect_read_config(bus, devfn, offset, len, val);
-}
-
#if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
-static struct pci_ops fsl_indirect_pcie_ops =
-{
- .read = fsl_indirect_read_config,
- .write = indirect_write_config,
-};
-
#define MAX_PHYS_ADDR_BITS 40
static u64 pci64_dma_offset = 1ull MAX_PHYS_ADDR_BITS;
@@ -132,291 +84,6 @@ static int fsl_pci_dma_set_mask(struct device *dev, u64
dma_mask)
return 0;
}
-static int setup_one_atmu(struct ccsr_pci __iomem *pci,
- unsigned int index, const struct resource *res,
- resource_size_t offset)
-{
- resource_size_t pci_addr = res-start - offset;
- resource_size_t phys_addr = res-start;
- resource_size_t size = resource_size(res);
- u32 flags = 0x80044000; /* enable mem R/W */
- unsigned int i;
-
- pr_debug(PCI MEM resource start 0x%016llx, size 0x%016llx.\n,
- (u64)res-start, (u64)size);
-
- if (res-flags IORESOURCE_PREFETCH)
- flags |= 0x1000; /* enable relaxed ordering */
-
- for (i = 0; size 0; i++) {
- unsigned int bits = min(ilog2(size),
- __ffs(pci_addr | phys_addr));
-
- if (index + i = 5)
- return -1;
-
- out_be32(pci-pow[index + i].potar, pci_addr 12);
- out_be32(pci-pow[index + i].potear, (u64)pci_addr 44);
- out_be32(pci-pow[index + i].powbar, phys_addr 12);
- out_be32(pci-pow[index + i].powar, flags | (bits - 1));
-
- pci_addr += (resource_size_t)1U bits;
- phys_addr += (resource_size_t)1U bits;
- size -= (resource_size_t)1U bits;
- }
-
- return i;
-}
-
-/* atmu setup for fsl pci/pcie controller */
-static void setup_pci_atmu(struct pci_controller *hose)
-{
-
[PATCH 2/2][RFC][v3] pci: fsl: rework PCI driver compatible with Layerscape
The Freescale's Layerscape series processors will use the same PCI
controller but change cores from PowerPC to ARM. This patch is to
rework FSL PCI driver to support PowerPC and ARM simultaneously.
PowerPC uses structure pci_controller to describe PCI controller,
but arm uses structure hw_pci and pci_sys_data. They also have
different architecture implementation and initialization flow.
The architecture-dependent driver will bridge the gap, get the
settings from the common driver and initialize the corresponding
structure and call the related interface to register PCI controller.
The common driver pci-fsl.c removes all the architecture-specific
code and provides structure fsl_pci to store all the controller
settings and the common functionalities that include reading/writing
PCI configuration space, parsing dts node and getting the MEM/IO and
bus number ranges, setting ATMU and check link status.
Signed-off-by: Minghuan Lian minghuan.l...@freescale.com
---
Based on upstream master
The function has been tested on MPC8315ERDB MPC8572DS P5020DS P3041DS
and T4240QDS boards
Change log:
v3:
1. use 'fsl_arch' as function name prefix of all the
architecture-specific hooks.
2. Move PCI compatible definitions from arch/powerpc/sysdev/fsl_pci.c
to driver/pci/host/pci-fsl.c
v2:
1. Use 'pci' instead of 'pcie' in new file name and file contents.
2. Use iowrite32be()/iowrite32() instead of out_be32/le32()
3. Fix ppc_md.dma_set_mask setting
4. Synchronizes host-first_busno and pci-first_busno.
5. Fix PCI IO space settings
6. Some small changes according to Scott's comments.
arch/powerpc/Kconfig | 1 +
arch/powerpc/sysdev/fsl_pci.c | 150 +-
drivers/edac/mpc85xx_edac.c | 9 -
drivers/pci/host/Kconfig | 4 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-fsl.c| 656 +++---
include/linux/fsl/pci.h | 69 +
7 files changed, 648 insertions(+), 242 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 6b7530f..657d90f 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -691,6 +691,7 @@ config FSL_SOC
config FSL_PCI
bool
+ select PCI_FSL if FSL_SOC_BOOKE || PPC_86xx
select PPC_INDIRECT_PCI
select PCI_QUIRKS
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index a189ff0..4cb12e8 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -62,7 +62,11 @@ static void quirk_fsl_pcie_header(struct pci_dev *dev)
#if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
#define MAX_PHYS_ADDR_BITS 40
-static u64 pci64_dma_offset = 1ull MAX_PHYS_ADDR_BITS;
+
+u64 fsl_arch_pci64_dma_offset(void)
+{
+ return 1ull MAX_PHYS_ADDR_BITS;
+}
static int fsl_pci_dma_set_mask(struct device *dev, u64 dma_mask)
{
@@ -77,17 +81,43 @@ static int fsl_pci_dma_set_mask(struct device *dev, u64
dma_mask)
if ((dev-bus == pci_bus_type)
dma_mask = DMA_BIT_MASK(MAX_PHYS_ADDR_BITS)) {
set_dma_ops(dev, dma_direct_ops);
- set_dma_offset(dev, pci64_dma_offset);
+ set_dma_offset(dev, fsl_arch_pci64_dma_offset());
}
*dev-dma_mask = dma_mask;
return 0;
}
+struct fsl_pci *fsl_arch_sys_to_pci(void *sys)
+{
+ struct pci_controller *hose = sys;
+ struct fsl_pci *pci = hose-private_data;
+
+ /* Update the first bus number */
+ if (pci-first_busno != hose-first_busno)
+ pci-first_busno = hose-first_busno;
+
+ return pci;
+}
+
+struct pci_bus *fsl_arch_fake_pci_bus(struct fsl_pci *pci, int busnr)
+{
+ static struct pci_bus bus;
+ static struct pci_controller hose;
+
+ bus.number = busnr;
+ bus.sysdata = hose;
+ hose.private_data = pci;
+ bus.ops = pci-ops;
+
+ return bus;
+}
+
void fsl_pcibios_fixup_bus(struct pci_bus *bus)
{
struct pci_controller *hose = pci_bus_to_host(bus);
- int i, is_pcie = 0, no_link;
+ int i, is_pcie, no_link;
+ struct fsl_pci *pci = fsl_arch_sys_to_pci(hose);
/* The root complex bridge comes up with bogus resources,
* we copy the PHB ones in.
@@ -97,9 +127,8 @@ void fsl_pcibios_fixup_bus(struct pci_bus *bus)
* tricky.
*/
- if (fsl_pcie_bus_fixup)
- is_pcie = early_find_capability(hose, 0, 0, PCI_CAP_ID_EXP);
- no_link = !!(hose-indirect_type PPC_INDIRECT_TYPE_NO_PCIE_LINK);
+ is_pcie = pci-is_pcie;
+ no_link = fsl_pci_check_link(pci);
if (bus-parent == hose-bus (is_pcie || no_link)) {
for (i = 0; i PCI_BRIDGE_RESOURCE_NUM; ++i) {
@@ -121,6 +150,94 @@ void fsl_pcibios_fixup_bus(struct pci_bus *bus)
}
}
+int fsl_arch_pci_exclude_device(struct fsl_pci *pci, u8 bus, u8 devfn)
+{
+ struct pci_controller *hose = pci-sys;
+
+ if (!hose)
+ return PCIBIOS_SUCCESSFUL;
[PATCH] pci: fix interrupt-map for bridges
The previous scheme always put 0 as a parent slot#. However it is not always the case and QEMU's PCI bridge does not support putting device at slot#0 as it claims SHPC support for hotplug. This modifies the interrups map to let the linux guest resolve XICS global interrupt number correctly. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru --- This is the example of working system: [root@erif_root pci@1]# lspci 0001:00:01.0 PCI bridge: Red Hat, Inc. Device 0001 0001:01:02.0 PCI bridge: Red Hat, Inc. Device 0001 0001:01:03.0 PCI bridge: Red Hat, Inc. Device 0001 0001:02:01.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06) 0001:02:02.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06) 0001:03:01.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06) 0001:03:02.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06) [root@erif_root pci@1]# pwd /proc/device-tree/pci@800200f/pci@1 [root@erif_root pci@1]# hexdump -e '9/4 %08x ' -e '\n' i*map 1000 0001 3e57f7e0 0800 0003 1000 0002 3e57f7e0 0800 1000 0003 3e57f7e0 0800 0001 1000 0004 3e57f7e0 0800 0002 1800 0001 3e57f7e0 0800 1800 0002 3e57f7e0 0800 0001 1800 0003 3e57f7e0 0800 0002 1800 0004 3e57f7e0 0800 0003 [root@erif_root pci@1]# cd pci@2/ [root@erif_root pci@2]# hexdump -e '9/4 %08x ' -e '\n' i*map 0800 0001 3e5a86f0 1000 0002 0800 0002 3e5a86f0 1000 0003 0800 0003 3e5a86f0 1000 0800 0004 3e5a86f0 1000 0001 1000 0001 3e5a86f0 1000 0003 1000 0002 3e5a86f0 1000 1000 0003 3e5a86f0 1000 0001 1000 0004 3e5a86f0 1000 0002 [root@erif_root pci@2]# cd ethernet@ ethernet@1/ ethernet@2/ [root@erif_root pci@2]# cd ethernet@1/ [root@erif_root ethernet@1]# lsprop reg reg 00020800 02020810 0002 02020814 0002 01020818 0020 02020830 0002 [root@erif_root ethernet@1]# lsprop interrupts interrupts 0002 --- board-qemu/slof/pci-interrupts.fs | 31 --- 1 file changed, 20 insertions(+), 11 deletions(-) diff --git a/board-qemu/slof/pci-interrupts.fs b/board-qemu/slof/pci-interrupts.fs index a12d7bb..62785a7 100644 --- a/board-qemu/slof/pci-interrupts.fs +++ b/board-qemu/slof/pci-interrupts.fs @@ -1,17 +1,26 @@ : pci-gen-irq-map-one ( prop-addr prop-len slot pin -- prop-addr prop-len ) -2dup + 4 mod( prop-addr prop-len slot pin parentpin ) +2dup + 4 mod( prop-addr prop-len slot pin parentpin ) +r r r( prop-addr prop-len R: swizzledpin pin slot ) + +\ Child slot# +r B lshift encode-int+ ( prop-addr prop-len R: swizzledpin pin ) +\ Child 64bit BAR (not really used) +0 encode-64+ +\ Chile pin# +r encode-int+ ( prop-addr prop-len R: swizzledpin ) + +\ Parent phandle +get-parent encode-int+ + +\ Parent slot# get-node space -pci-addr2dev + 1- 4 mod 1+ \ do swizzling ( prop-addr prop-len slot pin swizzledpin ) -r r r( prop-addr prop-len R: swizzledpin pin slot ) - -r B lshift encode-int+ -0 encode-64+\ device slot ( prop-addr prop-len R: swizzledpin pin ) -r encode-int+ \ device pin( prop-addr prop-len R: swizzledpin ) - -get-parent encode-int+ \ parent phandle -0 encode-int+ 0 encode-64+ \ parent slot -r encode-int+ \ parent swizzled pin ( prop-addr prop-len R: ) +pci-addr2dev B lshift ( prop-addr prop-len parent-slot R: swizzledpin ) +encode-int+ +\ Parent 64bit BAR (not really used) +0 encode-64+ +\ Parent pin +r encode-int+ ( prop-addr
Re: [RFC PATCH v2 15/25] smp, ppc: kill SMP single function call interrupt
On 09/12/2013 04:03 AM, Srivatsa S. Bhat wrote:
On 09/11/2013 09:37 PM, Jiang Liu wrote:
From: Jiang Liu jiang@huawei.com
Commit 9a46ad6d6df3b54 smp: make smp_call_function_many() use logic
similar to smp_call_function_single() has unified the way to handle
single and multiple cross-CPU function calls. Now only one interrupt
is needed for architecture specific code to support generic SMP function
call interfaces, so kill the redundant single function call interrupt.
Signed-off-by: Jiang Liu jiang@huawei.com
Cc: Jiang Liu liu...@gmail.com
---
It turns out that freeing up the IPI slot in powerpc is very useful, since
we actually wanted a slot for some other use-case (and there are only 4 slots
available on powerpc).
Here are the patches which achieve that:
http://marc.info/?l=linuxppc-embeddedm=137886807502898w=2
http://marc.info/?l=linuxppc-embeddedm=137886811502909w=2
Hi Srivatsa,
That's great and I will drop this patch from my series.
Could you please to kill call_function_single_action() instead of
call_function_action()? Please refer to
http://lkml.org/lkml/2013/9/11/579
Regards!
Gerry
So, can you kindly consider dropping the powerpc patch from your series,
if that is OK with you? Thanks!
BTW, after doing the powerpc cleanup, even I had thought about killing one
of the smp-function variants in various architectures, but never got around
to do it. But now that you have posted the series which does that, I'll try
to review them.
Thank you!
Regards,
Srivatsa S. Bhat
arch/powerpc/include/asm/smp.h | 3 +--
arch/powerpc/kernel/smp.c | 12 +---
2 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index 48cfc85..53faa03 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -119,8 +119,7 @@ extern int cpu_to_core_id(int cpu);
* in /proc/interrupts will be wrong!!! --Troy */
#define PPC_MSG_CALL_FUNCTION 0
#define PPC_MSG_RESCHEDULE 1
-#define PPC_MSG_CALL_FUNC_SINGLE2
-#define PPC_MSG_DEBUGGER_BREAK 3
+#define PPC_MSG_DEBUGGER_BREAK 2
/* for irq controllers that have dedicated ipis per message (4) */
extern int smp_request_message_ipi(int virq, int message);
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 38b0ba6..0c53b10 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -123,12 +123,6 @@ static irqreturn_t reschedule_action(int irq, void
*data)
return IRQ_HANDLED;
}
-static irqreturn_t call_function_single_action(int irq, void *data)
-{
-generic_smp_call_function_single_interrupt();
-return IRQ_HANDLED;
-}
-
static irqreturn_t debug_ipi_action(int irq, void *data)
{
if (crash_ipi_function_ptr) {
@@ -146,14 +140,12 @@ static irqreturn_t debug_ipi_action(int irq, void
*data)
static irq_handler_t smp_ipi_action[] = {
[PPC_MSG_CALL_FUNCTION] = call_function_action,
[PPC_MSG_RESCHEDULE] = reschedule_action,
-[PPC_MSG_CALL_FUNC_SINGLE] = call_function_single_action,
[PPC_MSG_DEBUGGER_BREAK] = debug_ipi_action,
};
const char *smp_ipi_name[] = {
[PPC_MSG_CALL_FUNCTION] = ipi call function,
[PPC_MSG_RESCHEDULE] = ipi reschedule,
-[PPC_MSG_CALL_FUNC_SINGLE] = ipi call function single,
[PPC_MSG_DEBUGGER_BREAK] = ipi debugger,
};
@@ -225,8 +217,6 @@ irqreturn_t smp_ipi_demux(void)
generic_smp_call_function_interrupt();
if (all (1 (24 - 8 * PPC_MSG_RESCHEDULE)))
scheduler_ipi();
-if (all (1 (24 - 8 * PPC_MSG_CALL_FUNC_SINGLE)))
-generic_smp_call_function_single_interrupt();
if (all (1 (24 - 8 * PPC_MSG_DEBUGGER_BREAK)))
debug_ipi_action(0, NULL);
#else
@@ -257,7 +247,7 @@ EXPORT_SYMBOL_GPL(smp_send_reschedule);
void arch_send_call_function_single_ipi(int cpu)
{
-do_message_pass(cpu, PPC_MSG_CALL_FUNC_SINGLE);
+do_message_pass(cpu, PPC_MSG_CALL_FUNCTION);
}
void arch_send_call_function_ipi_mask(const struct cpumask *mask)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] powerpc: allow kvm to use kerel debug framework
On 10.07.2013, at 02:25, Michael Neuling wrote: Alexander Graf ag...@suse.de wrote: On 09.07.2013, at 06:24, Michael Neuling wrote: Alexander Graf ag...@suse.de wrote: On 04.07.2013, at 08:15, Bharat Bhushan wrote: From: Bharat Bhushan bharat.bhus...@freescale.com This patchset moves the debug registers in a structure, which allows kvm to use same structure for debug emulation. Note: Earilier a patchset https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-June/108132.html; was sent which is a bunch of six patches. That patchset is divided into two parts: 1) powerpc specific changes (These 2 patches are actually have those changes) 2) KVM specific changes (will send separate patch on agraf repository) Mikey, if you like those could you please apply the into a topic branch and get that one merged with Ben? I'd also pull it into my tree then. benh would pull these directly. I'll have a chat with him to see if he wants my ACK before he does that. I have a bunch of patches that I need to apply on top, so I need a topic branch. I've acked the PPC specific bits of the v6 version of these patches. benh said he'll open a topic branch for you sometime next week and he'll stick them in there. Did anything happen here? Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4] powerpc/mpc85xx: Update the clock device tree nodes
On Wed, 2013-09-11 at 20:31 -0500, Tang Yuantian-B29983 wrote: -Original Message- From: Wood Scott-B07421 Sent: 2013年9月12日 星期四 9:10 To: Tang Yuantian-B29983 Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Li Yang-Leo-R58472 Subject: Re: [PATCH v4] powerpc/mpc85xx: Update the clock device tree nodes This description of reg is overly specific (assumes how the parent node's ranges are set up), incomplete (there's a size as well as the offset), and does not apply to the clockgen node itself (you probably shouldn't lump them together like this). Do you mean I should explain the REG of clockgen and its child node respectively? +- clocks : shall be the input parent clock phandle for the clock. Not required on the clockgen node Required by child node of clockgen. My point is that you're lumping several different types of nodes together with one binding, when some parts of the binding are not applicable to the clockgen node. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2] pstore: Adjust buffer size for compression for smaller registered buffers
efivars works fine with this v2 patch.
Tested-by: Seiji Aguchi seiji.agu...@hds.com
-Original Message-
From: Aruna Balakrishnaiah [mailto:ar...@linux.vnet.ibm.com]
Sent: Thursday, September 12, 2013 2:51 AM
To: linuxppc-...@ozlabs.org; tony.l...@intel.com; Seiji Aguchi;
linux-ker...@vger.kernel.org; keesc...@chromium.org
Cc: jkeni...@linux.vnet.ibm.com; mah...@linux.vnet.ibm.com;
cbouatmai...@gmail.com; ana...@in.ibm.com; ccr...@android.com
Subject: [PATCH v2] pstore: Adjust buffer size for compression for smaller
registered buffers
When backends (ex: efivars) have smaller registered buffers, the big_oops_buf
is quite too big for them as number of repeated occurences in the text
captured
will be less. Patch takes care of adjusting the buffer size based on the
registered buffer size. cmpr values has been arrived after doing experiments
with
plain text for buffers of size 1k - 4k (Smaller the buffer size repeated
occurence
will be less) and with sample crash log for buffers ranging from 4k - 10k.
Reported-by: Seiji Aguchi seiji.agu...@hds.com
Signed-off-by: Aruna Balakrishnaiah ar...@linux.vnet.ibm.com
---
Changes from v1:
Retain the cmpr = 45 for buffers ranging of size 4k - 10k. 45 seems to
work.
I added an additional headroom of 3%. Revert it back to 45.
fs/pstore/platform.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 4ffb7ab..57b4219 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -195,8 +195,29 @@ error:
static void allocate_buf_for_compression(void)
{
size_t size;
+ size_t cmpr;
+
+ switch (psinfo-bufsize) {
+ /* buffer range for efivars */
+ case 1000 ... 2000:
+ cmpr = 56;
+ break;
+ case 2001 ... 3000:
+ cmpr = 54;
+ break;
+ case 3001 ... 3999:
+ cmpr = 52;
+ break;
+ /* buffer range for nvram, erst */
+ case 4000 ... 1:
+ cmpr = 45;
+ break;
+ default:
+ cmpr = 60;
+ break;
+ }
- big_oops_buf_sz = (psinfo-bufsize * 100) / 45;
+ big_oops_buf_sz = (psinfo-bufsize * 100) / cmpr;
big_oops_buf = kmalloc(big_oops_buf_sz, GFP_KERNEL);
if (big_oops_buf) {
size = max(zlib_deflate_workspacesize(WINDOW_BITS, MEM_LEVEL),
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy in device tree
On Sep 12, 2013, at 1:54 AM, Liu Shengzhou-B36685 wrote: -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Wednesday, September 11, 2013 11:13 PM To: Zhao Qiang-B45475 Cc: linuxppc-dev@lists.ozlabs.org; Liu Shengzhou-B36685 Subject: Re: [PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy in device tree On Sep 10, 2013, at 10:49 PM, Zhao Qiang wrote: Since P1010RDB-PA and P1010RDB-PB boards use different external PHY interrupt signals. And actually the PHY interrupt is not used effectively with corresponding interrupt handler. So we can remove the interrupts node without side-effect to comply with both P1010RDB-PA and P1010RDB-PB. Signed-off-by: Shengzhou Liu shengzhou@freescale.com Signed-off-by: Zhao Qiang b45...@freescale.com --- arch/powerpc/boot/dts/p1010rdb.dtsi | 3 --- 1 file changed, 3 deletions(-) NAK. The device tree should represent the HW not what drivers decide to do with it. If different board revs have different interrupt signals than create dts's to handle the 2 board revs. - k You mean we need to create p1010rdb-pa.dtsi and p1010rdb-pb.dtsi replacing current p1010rdb.dtsi just because of the unused phy interrupt? and phy interrupt is not present in those dts of P3/P4/P5 platforms. Actually currently many hardware are not present in dts, such as a lot of i2c devices, temperature monitor, etc. -Shengzhou I'm saying of the board revs are different w/regards to how the PHY interrupt is wired, than create two .dts one for each of the board revs. If the p3/p4/p5 platforms are missing the phy interrupt in the .dts than its an error. Other devices like i2c, temp mon, etc should be added. There is a difference between something not existing because people haven't gotten around to it / there isn't a binding vs a using the lack of information as a configuration mechanism. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2] pstore: Adjust buffer size for compression for smaller registered buffers
+ default: + cmpr = 60; + break; + } Is this the right default? It may be a good choice for a backend with a really tiny buffer (1 ... 999). But less good for a (theoretical) backend with a larger buffer (10001 ... infinity and beyond). Which are you trying to catch here? -Tony ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v9 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
On Tue, Sep 03, 2013 at 10:01:50AM +0100, Hongbo Zhang wrote: On 09/02/2013 11:58 PM, Mark Rutland wrote: Hi, On Fri, Aug 30, 2013 at 12:26:19PM +0100, hongbo.zh...@freescale.com wrote: From: Hongbo Zhang hongbo.zh...@freescale.com Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds the device tree nodes for them. Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com --- .../devicetree/bindings/powerpc/fsl/dma.txt| 67 arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +- arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 82 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 82 arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +- 5 files changed, 235 insertions(+), 4 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt index ddf17af..332ac77 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt @@ -126,6 +126,73 @@ Example: }; }; +** Freescale Elo3 DMA Controller + This is EloPlus controller with 8 channels, used in Freescale Txxx and Bxxx I was under the impression EloPlus was the previous revision. Should that say Elo3, or is Elo3 considered to be an EloPlus implementation? In this patch 1/3 I revise the doc to make it clear we have Elo and EloPlus, and I'm adding another new Elo3. Yes the only difference between Elo3 and EloPlus is channel numbers(8 channels vs 4 channels), so we can call Elo3 is an 8-channel EloPlus Ok. + series chips, such as t1040, t4240, b4860. + +Required properties: + +- compatible: must include fsl,elo3-dma +- reg : registers specifier for DMA general status reg The example has two reg entries. What both are should be specified. From what you described last time, it sounds like each is a status register for four channels. Presumably the first covers the channels at 0x0,0x80,0x100,0x180, and the second covers the channels at 0x300,0x380,0x400,0x480? If the registers have specific names in a datasheet, it would be worth mentioning them. Yes, each is a status register for four channels, you got it -- this means my statement works. Is it necessary to specify all the register names? I can describe my two registers, but in other cases the reg entryies can cover tens even hundreds of registers, just a summary is OK I think. I think there should at least be a description of which channels each reg entry corresponds to. I see this hasn't been done so far for the older Elo DMAs, but they only had 4 channels max, and one status reg. If the specification of the DMA controller allows for more channels, it may be worth describing that case now. This DMA controller doesn't allows for more channels. (Even if it does, it should be another new controller) Ok. +- ranges: describes the mapping between the address space of the + DMA channels and the address space of the DMA controller This looks odd as a required property, and I'm slightly confused. Is this used to map the reg values of the DMA channels, or is it used when mapping the DMA address space (for which dma-ranges exists in ePAPR and other bindings). It is used to map the reg values of DMA channels. Ok, I guess that makes sense. + +- DMA channel nodes: +- compatible: must include fsl,eloplus-dma-channel +- reg : registers specifier for channel What does this represent? What are valid values? In the example below it looks like these are offsets of control registers within the dma controller. Yes, they are offsets of control registers within dma controller, but the contents in these registers are for dma channels. Physically we have dma controller registers and dma channel registers, they are in one continuous physical address space, we divide all these registers into two controller/channel parts, according to contents in these registers, common status registers for all channels are called dma controller registers, otherwise channel specific registers are called dma channel registers. I see, so this reg represents a channels channel specific registers (which are distinct from the shared status registers). I was confused initially as to what address space they were in, but that makes sense with your description of ranges above. If the reg property may have any value, how do they get mapped to bits in the status register(s)? In fact, each channel has its own status register(and also other registers), the dma controller status register is
[PATCH v2] powerpc 8xx: Fixing issue with CONFIG_PIN_TLB
This is a reorganisation of the setup of the TLB at kernel startup, in order to handle the CONFIG_PIN_TLB case in accordance with chapter 8.10.3 of MPC866 and MPC885 reference manuals. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr diff -ur linux-3.11.org/arch/powerpc/kernel/head_8xx.S linux-3.11/arch/powerpc/kernel/head_8xx.S --- linux-3.11.org/arch/powerpc/kernel/head_8xx.S 2013-09-02 22:46:10.0 +0200 +++ linux-3.11/arch/powerpc/kernel/head_8xx.S 2013-09-09 11:28:54.0 +0200 @@ -785,27 +785,24 @@ * these mappings is mapped by page tables. */ initial_mmu: - tlbia /* Invalidate all TLB entries */ -/* Always pin the first 8 MB ITLB to prevent ITLB - misses while mucking around with SRR0/SRR1 in asm -*/ - lis r8, MI_RSV4I@h - ori r8, r8, 0x1c00 - + lis r8, MI_RESETVAL@h mtspr SPRN_MI_CTR, r8 /* Set instruction MMU control */ -#ifdef CONFIG_PIN_TLB - lis r10, (MD_RSV4I | MD_RESETVAL)@h - ori r10, r10, 0x1c00 - mr r8, r10 -#else lis r10, MD_RESETVAL@h -#endif #ifndef CONFIG_8xx_COPYBACK orisr10, r10, MD_WTDEF@h #endif mtspr SPRN_MD_CTR, r10/* Set data TLB control */ + tlbia /* Invalidate all TLB entries */ + + ori r8, r8, 0x1c00 + mtspr SPRN_MI_CTR, r8 /* Set instruction MMU control */ +#ifdef CONFIG_PIN_TLB + ori r10, r10, 0x1c00 + mtspr SPRN_MD_CTR, r10/* Set data TLB control */ +#endif + /* Now map the lower 8 Meg into the TLBs. For this quick hack, * we can load the instruction and data TLB registers with the * same values. @@ -825,6 +822,12 @@ mtspr SPRN_MI_AP, r8 mtspr SPRN_MD_AP, r8 + /* Always pin the first 8 MB ITLB to prevent ITLB +* misses while mucking around with SRR0/SRR1 in asm +*/ + lis r8, (MI_RSV4I | MI_RESETVAL)@h + mtspr SPRN_MI_CTR, r8 /* Set instruction MMU control */ + /* Map another 8 MByte at the IMMR to get the processor * internal registers (among other things). */ @@ -870,7 +873,15 @@ mtspr SPRN_MD_TWC, r9 addis r11, r11, 0x0080/* Add 8M */ mtspr SPRN_MD_RPN, r11 + + lis r10, (MD_RSV4I | MD_RESETVAL)@h +#else + lis r10, MD_RESETVAL@h #endif +#ifndef CONFIG_8xx_COPYBACK + orisr10, r10, MD_WTDEF@h +#endif + mtspr SPRN_MD_CTR, r10/* Set data TLB control */ /* Since the cache is enabled according to the information we * just loaded into the TLB, invalidate and enable the caches here. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc 8xx: Fixing issue with CONFIG_PIN_TLB
On Thu, 2013-09-12 at 20:25 +0200, Christophe Leroy wrote: This is a reorganisation of the setup of the TLB at kernel startup, in order to handle the CONFIG_PIN_TLB case in accordance with chapter 8.10.3 of MPC866 and MPC885 reference manuals. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr diff -ur linux-3.11.org/arch/powerpc/kernel/head_8xx.S linux-3.11/arch/powerpc/kernel/head_8xx.S --- linux-3.11.org/arch/powerpc/kernel/head_8xx.S 2013-09-02 22:46:10.0 +0200 +++ linux-3.11/arch/powerpc/kernel/head_8xx.S 2013-09-09 11:28:54.0 +0200 @@ -785,27 +785,24 @@ * these mappings is mapped by page tables. */ initial_mmu: - tlbia /* Invalidate all TLB entries */ -/* Always pin the first 8 MB ITLB to prevent ITLB - misses while mucking around with SRR0/SRR1 in asm -*/ - lis r8, MI_RSV4I@h - ori r8, r8, 0x1c00 - + lis r8, MI_RESETVAL@h mtspr SPRN_MI_CTR, r8 /* Set instruction MMU control */ -#ifdef CONFIG_PIN_TLB - lis r10, (MD_RSV4I | MD_RESETVAL)@h - ori r10, r10, 0x1c00 - mr r8, r10 -#else lis r10, MD_RESETVAL@h -#endif #ifndef CONFIG_8xx_COPYBACK orisr10, r10, MD_WTDEF@h #endif mtspr SPRN_MD_CTR, r10/* Set data TLB control */ + tlbia /* Invalidate all TLB entries */ Is this change to make sure we invalidate everything even if the bootloader set RSV4I? + ori r8, r8, 0x1c00 + mtspr SPRN_MI_CTR, r8 /* Set instruction MMU control */ +#ifdef CONFIG_PIN_TLB + ori r10, r10, 0x1c00 + mtspr SPRN_MD_CTR, r10/* Set data TLB control */ +#endif Still 0x1c00? /* Now map the lower 8 Meg into the TLBs. For this quick hack, * we can load the instruction and data TLB registers with the * same values. @@ -825,6 +822,12 @@ mtspr SPRN_MI_AP, r8 mtspr SPRN_MD_AP, r8 + /* Always pin the first 8 MB ITLB to prevent ITLB + * misses while mucking around with SRR0/SRR1 in asm + */ + lis r8, (MI_RSV4I | MI_RESETVAL)@h + mtspr SPRN_MI_CTR, r8 /* Set instruction MMU control */ Entry 0 is not pinnable. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/85xx: introduce cornet_generic machine
On Thu, 2013-09-12 at 15:13 +0800, Kevin Hao wrote:
In the current kernel, the board files for p2041rdb, p3041ds, p4080ds,
p5020ds, p5040ds, t4240qds and b4qds are almost the same except the
machine name. So this introduces a cornet_generic machine to support
all these boards to avoid the code duplication.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
This patch is based on http://patchwork.ozlabs.org/patch/274390/
arch/powerpc/platforms/85xx/Kconfig | 10
arch/powerpc/platforms/85xx/Makefile | 8 +--
arch/powerpc/platforms/85xx/b4_qds.c | 97
arch/powerpc/platforms/85xx/corenet_ds.c | 86
arch/powerpc/platforms/85xx/p2041_rdb.c | 87
arch/powerpc/platforms/85xx/p3041_ds.c | 89 -
arch/powerpc/platforms/85xx/p4080_ds.c | 87
arch/powerpc/platforms/85xx/p5020_ds.c | 93 --
arch/powerpc/platforms/85xx/p5040_ds.c | 84 ---
arch/powerpc/platforms/85xx/t4240_qds.c | 93 --
10 files changed, 97 insertions(+), 637 deletions(-)
delete mode 100644 arch/powerpc/platforms/85xx/b4_qds.c
delete mode 100644 arch/powerpc/platforms/85xx/p2041_rdb.c
delete mode 100644 arch/powerpc/platforms/85xx/p3041_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/p4080_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/p5020_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/p5040_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/t4240_qds.c
Why not merge patch 2/2 with this?
Did you use -M -C with git format-patch?
diff --git a/arch/powerpc/platforms/85xx/Kconfig
b/arch/powerpc/platforms/85xx/Kconfig
index de2eb93..3bee943 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -228,6 +228,7 @@ config P2041_RDB
select GPIO_MPC8XXX
select HAS_RAPIDIO
select PPC_EPAPR_HV_PIC
+ select CORENET_GENERIC
help
This option enables support for the P2041 RDB board
@@ -241,6 +242,7 @@ config P3041_DS
select GPIO_MPC8XXX
select HAS_RAPIDIO
select PPC_EPAPR_HV_PIC
+ select CORENET_GENERIC
help
This option enables support for the P3041 DS board
@@ -254,6 +256,7 @@ config P4080_DS
select GPIO_MPC8XXX
select HAS_RAPIDIO
select PPC_EPAPR_HV_PIC
+ select CORENET_GENERIC
help
This option enables support for the P4080 DS board
@@ -278,6 +281,7 @@ config P5020_DS
select GPIO_MPC8XXX
select HAS_RAPIDIO
select PPC_EPAPR_HV_PIC
+ select CORENET_GENERIC
help
This option enables support for the P5020 DS board
@@ -292,6 +296,7 @@ config P5040_DS
select GPIO_MPC8XXX
select HAS_RAPIDIO
select PPC_EPAPR_HV_PIC
+ select CORENET_GENERIC
help
This option enables support for the P5040 DS board
@@ -323,6 +328,7 @@ config T4240_QDS
select GPIO_MPC8XXX
select HAS_RAPIDIO
select PPC_EPAPR_HV_PIC
+ select CORENET_GENERIC
help
This option enables support for the T4240 QDS board
@@ -337,6 +343,7 @@ config B4_QDS
select ARCH_REQUIRE_GPIOLIB
select HAS_RAPIDIO
select PPC_EPAPR_HV_PIC
+ select CORENET_GENERIC
help
This option enables support for the B4 QDS board
The B4 application development system B4 QDS is a complete
@@ -348,3 +355,6 @@ endif # FSL_SOC_BOOKE
config TQM85xx
bool
+
+config CORENET_GENERIC
+ bool
Why do we need separate kconfig symbols for each board, if they all
select the same code?
+define_machine(corenet_generic) {
+ .name = CORENET GENERIC,
No allcaps please.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
On Wed, 2013-09-11 at 22:48 -0500, Wang Dongsheng-B40534 wrote: -Original Message- From: Wood Scott-B07421 Sent: Thursday, September 12, 2013 7:04 AM To: Wang Dongsheng-B40534 Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle On Wed, 2013-09-11 at 13:56 +0800, Dongsheng Wang wrote: From: Wang Dongsheng dongsheng.w...@freescale.com Add a sys interface to enable/diable pw20 state or altivec idle, and control the wait entry time. Enable/Disable interface: 0, disable. 1, enable. /sys/devices/system/cpu/cpuX/pw20_state /sys/devices/system/cpu/cpuX/altivec_idle Set wait entry bit interface: bit value range 0~63, 0 bit is Mintime, 63 bit is Maxtime. /sys/devices/system/cpu/cpuX/pw20_wait_entry_bit /sys/devices/system/cpu/cpuX/altivec_idle_wait_entry_bit I'm no fan of the way powerpc does bit numbering, but don't flip it around here -- you'll just cause confusion. OK. 0 bit is maxtime, 63 bit is mintime. Better yet, this interface should take real time units rather than a timebase bit. I think the real time is not suitable, because timebase bit does not correspond with real time. It's a bit sloppy due to how the hardware works, but you could convert it like you did in earlier patches. Semantically it should probably be the minimum time to wait before entering the low power state. Also, you disable the power saving mode if the maximum interval is selected, It's not disable the pw20 state or altivec idle, just max-delay entry time. No, the code checks for zero to set or clear the enabling bit (e.g. PW20_WAIT). but the documentation doesn't say that -- and the documentation should be in the code (or other easily findable place), not just in the commit message. Also add a comment in the 85xx/common.c ? Yes. +_GLOBAL(has_pw20_altivec_idle) + /* 0 false, 1 true */ + li r3, 0 + + /* PW20 AltiVec idle feature only exists for E6500 */ + mfspr r0, SPRN_PVR + rlwinm r4, r0, 16, 16, 31 + lis r12, 0 + ori r12, r12, PVR_VER_E6500@l + cmpwr4, r12 + bne 2f + li r3, 1 +2: + blr Why is this in asm? And shouldn't this go in the cputable somehow? Not a special reason for this, just asm... Asm shouldn't be used without a good reason. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] pstore: Adjust buffer size for compression for smaller registered buffers
On Thursday 12 September 2013 11:13 PM, Luck, Tony wrote: + default: + cmpr = 60; + break; + } Is this the right default? It may be a good choice for a backend with a really tiny buffer (1 ... 999). But less good for a (theoretical) backend with a larger buffer (10001 ... infinity and beyond). Which are you trying to catch here? Trying to catch lower buffers and also tried till 23k ( 10k * 100/45) of text with a sample crash logit achieved a good compression of 25%. Since the upper limit is not known and compression behavior is not tested above 10k chose to keep a higher default of 60. -Tony ___ 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
Re: [PATCH 1/2] powerpc/85xx: introduce cornet_generic machine
On Thu, Sep 12, 2013 at 01:44:46PM -0500, Scott Wood wrote:
On Thu, 2013-09-12 at 15:13 +0800, Kevin Hao wrote:
In the current kernel, the board files for p2041rdb, p3041ds, p4080ds,
p5020ds, p5040ds, t4240qds and b4qds are almost the same except the
machine name. So this introduces a cornet_generic machine to support
all these boards to avoid the code duplication.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
This patch is based on http://patchwork.ozlabs.org/patch/274390/
arch/powerpc/platforms/85xx/Kconfig | 10
arch/powerpc/platforms/85xx/Makefile | 8 +--
arch/powerpc/platforms/85xx/b4_qds.c | 97
arch/powerpc/platforms/85xx/corenet_ds.c | 86
arch/powerpc/platforms/85xx/p2041_rdb.c | 87
arch/powerpc/platforms/85xx/p3041_ds.c | 89 -
arch/powerpc/platforms/85xx/p4080_ds.c | 87
arch/powerpc/platforms/85xx/p5020_ds.c | 93
--
arch/powerpc/platforms/85xx/p5040_ds.c | 84 ---
arch/powerpc/platforms/85xx/t4240_qds.c | 93
--
10 files changed, 97 insertions(+), 637 deletions(-)
delete mode 100644 arch/powerpc/platforms/85xx/b4_qds.c
delete mode 100644 arch/powerpc/platforms/85xx/p2041_rdb.c
delete mode 100644 arch/powerpc/platforms/85xx/p3041_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/p4080_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/p5020_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/p5040_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/t4240_qds.c
Why not merge patch 2/2 with this?
OK. I will fold the patch 2 into this one.
Did you use -M -C with git format-patch?
For this case, using '-M -C' or not would generate the same patch.
diff --git a/arch/powerpc/platforms/85xx/Kconfig
b/arch/powerpc/platforms/85xx/Kconfig
config TQM85xx
[...]
bool
+
+config CORENET_GENERIC
+ bool
Why do we need separate kconfig symbols for each board, if they all
select the same code?
I thought it would be more obvious for the board support if we have a separate
option for each board. We can also use this option for some board specific
configuration if we have. Yes, it does seem a bit redundant. If you prefer I
can drop these boards options.
+define_machine(corenet_generic) {
+ .name = CORENET GENERIC,
No allcaps please.
How about CORENET Generic?
BTW with these changes the file name corenet_ds.c seems not accurate anymore?
How about change it to corenet_generic.c?
Thanks,
Kevin
-Scott
pgp0Gia7jSiSN.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v4] powerpc/mpc85xx: Update the clock device tree nodes
-Original Message- From: Wood Scott-B07421 Sent: 2013年9月12日 星期四 22:44 To: Tang Yuantian-B29983 Cc: Wood Scott-B07421; ga...@kernel.crashing.org; linuxppc- d...@lists.ozlabs.org; devicet...@vger.kernel.org; Li Yang-Leo-R58472 Subject: Re: [PATCH v4] powerpc/mpc85xx: Update the clock device tree nodes On Wed, 2013-09-11 at 20:31 -0500, Tang Yuantian-B29983 wrote: -Original Message- From: Wood Scott-B07421 Sent: 2013年9月12日 星期四 9:10 To: Tang Yuantian-B29983 Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Li Yang-Leo-R58472 Subject: Re: [PATCH v4] powerpc/mpc85xx: Update the clock device tree nodes This description of reg is overly specific (assumes how the parent node's ranges are set up), incomplete (there's a size as well as the offset), and does not apply to the clockgen node itself (you probably shouldn't lump them together like this). Do you mean I should explain the REG of clockgen and its child node respectively? +- clocks : shall be the input parent clock phandle for the clock. Not required on the clockgen node Required by child node of clockgen. My point is that you're lumping several different types of nodes together with one binding, when some parts of the binding are not applicable to the clockgen node. Not several, just two types of nodes. One is clockgen node, the other is PLL and mux nodes. The reason they lumped together is that the clockgen node is not only IP block Node but also a clock provider node. At first, I want to add a extra fixed-clock node and move the clock-frequency of clockgen Node to it, but it is against the backward compatibility which I think it is not a big deal, Because nobody hasn't used it yet. If I add a extra node with the clock-frequency property and don't move the clock-frequency property of clockgen, that would be redundant because both clockgen node and the extra node have the same clock-frequency node. So, I choose what I did now. Could you give me some suggestions on this? Regards, Yuantian -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message- From: Wood Scott-B07421 Sent: Friday, September 13, 2013 2:07 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; ga...@kernel.crashing.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle On Wed, 2013-09-11 at 22:48 -0500, Wang Dongsheng-B40534 wrote: -Original Message- From: Wood Scott-B07421 Sent: Thursday, September 12, 2013 7:04 AM To: Wang Dongsheng-B40534 Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle On Wed, 2013-09-11 at 13:56 +0800, Dongsheng Wang wrote: From: Wang Dongsheng dongsheng.w...@freescale.com Add a sys interface to enable/diable pw20 state or altivec idle, and control the wait entry time. Enable/Disable interface: 0, disable. 1, enable. /sys/devices/system/cpu/cpuX/pw20_state /sys/devices/system/cpu/cpuX/altivec_idle Set wait entry bit interface: bit value range 0~63, 0 bit is Mintime, 63 bit is Maxtime. /sys/devices/system/cpu/cpuX/pw20_wait_entry_bit /sys/devices/system/cpu/cpuX/altivec_idle_wait_entry_bit I'm no fan of the way powerpc does bit numbering, but don't flip it around here -- you'll just cause confusion. OK. 0 bit is maxtime, 63 bit is mintime. Better yet, this interface should take real time units rather than a timebase bit. I think the real time is not suitable, because timebase bit does not correspond with real time. It's a bit sloppy due to how the hardware works, but you could convert it like you did in earlier patches. Semantically it should probably be the minimum time to wait before entering the low power state. But there has a problem, we can't convert bit to the real time when user read this sysfs. Like: echo 1000(us) /sys/*/pw20_wait_entry_bit, after convert we get bit is 49. cat /sys/*/pw20_wait_entry_bit, after convert the time is 1598(us). The read out of the time is not real time. Unless we define a variable to save the real time. Also, you disable the power saving mode if the maximum interval is selected, It's not disable the pw20 state or altivec idle, just max-delay entry time. No, the code checks for zero to set or clear the enabling bit (e.g. PW20_WAIT). There has pw20_state/altivec_idle sys interface to control enable/disable, There is only to control wait bit. Did you mean remove pw20_state/altivec_idle sys interface, and reuse pw20_wait_entry_bit/altivec_idle* sys interface? When echo zero into pw20_wait_entry_bit we just to disable pw20 state, I think that is reasonable. :) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy in device tree
Do you have any solutions? -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Friday, September 13, 2013 12:42 AM To: Liu Shengzhou-B36685 Cc: Zhao Qiang-B45475; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy in device tree On Sep 12, 2013, at 1:54 AM, Liu Shengzhou-B36685 wrote: -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Wednesday, September 11, 2013 11:13 PM To: Zhao Qiang-B45475 Cc: linuxppc-dev@lists.ozlabs.org; Liu Shengzhou-B36685 Subject: Re: [PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy in device tree On Sep 10, 2013, at 10:49 PM, Zhao Qiang wrote: Since P1010RDB-PA and P1010RDB-PB boards use different external PHY interrupt signals. And actually the PHY interrupt is not used effectively with corresponding interrupt handler. So we can remove the interrupts node without side-effect to comply with both P1010RDB-PA and P1010RDB-PB. Signed-off-by: Shengzhou Liu shengzhou@freescale.com Signed-off-by: Zhao Qiang b45...@freescale.com --- arch/powerpc/boot/dts/p1010rdb.dtsi | 3 --- 1 file changed, 3 deletions(-) NAK. The device tree should represent the HW not what drivers decide to do with it. If different board revs have different interrupt signals than create dts's to handle the 2 board revs. - k You mean we need to create p1010rdb-pa.dtsi and p1010rdb-pb.dtsi replacing current p1010rdb.dtsi just because of the unused phy interrupt? and phy interrupt is not present in those dts of P3/P4/P5 platforms. Actually currently many hardware are not present in dts, such as a lot of i2c devices, temperature monitor, etc. -Shengzhou I'm saying of the board revs are different w/regards to how the PHY interrupt is wired, than create two .dts one for each of the board revs. If the p3/p4/p5 platforms are missing the phy interrupt in the .dts than its an error. Other devices like i2c, temp mon, etc should be added. There is a difference between something not existing because people haven't gotten around to it / there isn't a binding vs a using the lack of information as a configuration mechanism. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy in device tree
On Sep 13, 2013, at 12:42 AM, Kumar Gala wrote: -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Friday, September 13, 2013 12:42 AM To: Liu Shengzhou-B36685 Cc: Zhao Qiang-B45475; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy in device tree On Sep 12, 2013, at 1:54 AM, Liu Shengzhou-B36685 wrote: -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Wednesday, September 11, 2013 11:13 PM To: Zhao Qiang-B45475 Cc: linuxppc-dev@lists.ozlabs.org; Liu Shengzhou-B36685 Subject: Re: [PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy in device tree On Sep 10, 2013, at 10:49 PM, Zhao Qiang wrote: NAK. The device tree should represent the HW not what drivers decide to do with it. If different board revs have different interrupt signals than create dts's to handle the 2 board revs. - k You mean we need to create p1010rdb-pa.dtsi and p1010rdb-pb.dtsi replacing current p1010rdb.dtsi just because of the unused phy interrupt? and phy interrupt is not present in those dts of P3/P4/P5 platforms. Actually currently many hardware are not present in dts, such as a lot of i2c devices, temperature monitor, etc. -Shengzhou I'm saying of the board revs are different w/regards to how the PHY interrupt is wired, than create two .dts one for each of the board revs. If the p3/p4/p5 platforms are missing the phy interrupt in the .dts than its an error. Other devices like i2c, temp mon, etc should be added. There is a difference between something not existing because people haven't gotten around to it / there isn't a binding vs a using the lack of information as a configuration mechanism. - k Kumar, please advice your solution, thanks. -zhaoqiang ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc 8xx: Fixing issue with CONFIG_PIN_TLB
Le 12/09/2013 20:44, Scott Wood a écrit : On Thu, 2013-09-12 at 20:25 +0200, Christophe Leroy wrote: This is a reorganisation of the setup of the TLB at kernel startup, in order to handle the CONFIG_PIN_TLB case in accordance with chapter 8.10.3 of MPC866 and MPC885 reference manuals. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr diff -ur linux-3.11.org/arch/powerpc/kernel/head_8xx.S linux-3.11/arch/powerpc/kernel/head_8xx.S --- linux-3.11.org/arch/powerpc/kernel/head_8xx.S 2013-09-02 22:46:10.0 +0200 +++ linux-3.11/arch/powerpc/kernel/head_8xx.S 2013-09-09 11:28:54.0 +0200 @@ -785,27 +785,24 @@ * these mappings is mapped by page tables. */ initial_mmu: - tlbia /* Invalidate all TLB entries */ -/* Always pin the first 8 MB ITLB to prevent ITLB - misses while mucking around with SRR0/SRR1 in asm -*/ - lis r8, MI_RSV4I@h - ori r8, r8, 0x1c00 - + lis r8, MI_RESETVAL@h mtspr SPRN_MI_CTR, r8 /* Set instruction MMU control */ -#ifdef CONFIG_PIN_TLB - lis r10, (MD_RSV4I | MD_RESETVAL)@h - ori r10, r10, 0x1c00 - mr r8, r10 -#else lis r10, MD_RESETVAL@h -#endif #ifndef CONFIG_8xx_COPYBACK orisr10, r10, MD_WTDEF@h #endif mtspr SPRN_MD_CTR, r10/* Set data TLB control */ + tlbia /* Invalidate all TLB entries */ Is this change to make sure we invalidate everything even if the bootloader set RSV4I? Most probably. It is step 2 of the process defined in MPC866 and MPC885 Reference Manuals: §8.10.3 Loading Locked TLB Entries: The process of loading a single reserved entry in the TLB is as follows: 1. Disable the TLB by clearing MSR[IR] or MSR[DR] as needed. 2. Clear MI_CTR[RSV4I] (MD_CTR[RSV4D]). 3. Invalidate the EA of the reserved page by using tlbia or tlbie. 4. Set MI_CTR[ITLB_INDX] (MD_CTR[DTLB_INDX]) to the appropriate value (between 27 and 31). 5. Load Mx_EPN with the effective page number, the ASID of the reserved page, and set EV. 6. Run software tablewalk code to load the appropriate entry into the translation lookaside buffer. See Section 8.10.1.1, “Translation Reload Examples.” 7. Repeat steps 4–6 to load other TLB entries. 8. Set MI_CTR[RSV4I] (MD_CTR[RSV4D]) + ori r8, r8, 0x1c00 + mtspr SPRN_MI_CTR, r8 /* Set instruction MMU control */ +#ifdef CONFIG_PIN_TLB + ori r10, r10, 0x1c00 + mtspr SPRN_MD_CTR, r10/* Set data TLB control */ +#endif Still 0x1c00? Yes, I kept the same entries in order to limit modifications: * 28 = First 8Mbytes page * 29 = IMMR * 30 = Second 8Mbytes page * 31 = Third 8Mbytes page /* Now map the lower 8 Meg into the TLBs. For this quick hack, * we can load the instruction and data TLB registers with the * same values. @@ -825,6 +822,12 @@ mtspr SPRN_MI_AP, r8 mtspr SPRN_MD_AP, r8 + /* Always pin the first 8 MB ITLB to prevent ITLB +* misses while mucking around with SRR0/SRR1 in asm +*/ + lis r8, (MI_RSV4I | MI_RESETVAL)@h + mtspr SPRN_MI_CTR, r8 /* Set instruction MMU control */ Entry 0 is not pinnable. Here we are not trying to pin entry 0. We are at step 8, we are setting MI_RSV4I. At the same time, we set MD_CTR to 0 which is off the pinned range, to be sure that we won't overwrite one of the pinned entries. The main difference compared to the previous implementation is that before, we were setting the RSV4I bit before loading the TLB entries. Now, as defined in the Reference Manuals, we are doing it at the end. Christophe ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/pmac: Early debug output on screen on 64-bit macs
On Thu, Jul 25, 2013 at 12:49:57PM +1000, Benjamin Herrenschmidt wrote: On Thu, 2013-07-25 at 12:12 +1000, Benjamin Herrenschmidt wrote: --- a/arch/powerpc/kernel/setup_64.c +++ b/arch/powerpc/kernel/setup_64.c @@ -10,7 +10,7 @@ * 2 of the License, or (at your option) any later version. */ -#undef DEBUG +#define DEBUG Ooops... sent the wrong version. Will send an updated one later, if there are no other comments. Looks like you merged the version with #define DEBUG. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/setup_64.c#n13 cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/pmac: Early debug output on screen on 64-bit macs
On Fri, 2013-09-13 at 15:10 +1000, Michael Ellerman wrote: Looks like you merged the version with #define DEBUG. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/setup_64.c#n13 Yes, it looks like I've been distracted, I'll remove it again (or you can send a patch :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] pci: fix interrupt-map for bridges
Alexey Kardashevskiy a...@ozlabs.ru writes: The previous scheme always put 0 as a parent slot#. However it is not always the case and QEMU's PCI bridge does not support putting device at slot#0 as it claims SHPC support for hotplug. This modifies the interrups map to let the linux guest resolve XICS global interrupt number correctly. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru --- This is the example of working system: [root@erif_root pci@1]# lspci 0001:00:01.0 PCI bridge: Red Hat, Inc. Device 0001 0001:01:02.0 PCI bridge: Red Hat, Inc. Device 0001 0001:01:03.0 PCI bridge: Red Hat, Inc. Device 0001 0001:02:01.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06) 0001:02:02.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06) 0001:03:01.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06) 0001:03:02.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06) [root@erif_root pci@1]# pwd /proc/device-tree/pci@800200f/pci@1 [root@erif_root pci@1]# hexdump -e '9/4 %08x ' -e '\n' i*map 1000 0001 3e57f7e0 0800 0003 1000 0002 3e57f7e0 0800 1000 0003 3e57f7e0 0800 0001 1000 0004 3e57f7e0 0800 0002 1800 0001 3e57f7e0 0800 1800 0002 3e57f7e0 0800 0001 1800 0003 3e57f7e0 0800 0002 1800 0004 3e57f7e0 0800 0003 [root@erif_root pci@1]# cd pci@2/ [root@erif_root pci@2]# hexdump -e '9/4 %08x ' -e '\n' i*map 0800 0001 3e5a86f0 1000 0002 0800 0002 3e5a86f0 1000 0003 0800 0003 3e5a86f0 1000 0800 0004 3e5a86f0 1000 0001 1000 0001 3e5a86f0 1000 0003 1000 0002 3e5a86f0 1000 1000 0003 3e5a86f0 1000 0001 1000 0004 3e5a86f0 1000 0002 [root@erif_root pci@2]# cd ethernet@ ethernet@1/ ethernet@2/ [root@erif_root pci@2]# cd ethernet@1/ [root@erif_root ethernet@1]# lsprop reg reg 00020800 02020810 0002 02020814 0002 01020818 0020 02020830 0002 [root@erif_root ethernet@1]# lsprop interrupts interrupts 0002 --- board-qemu/slof/pci-interrupts.fs | 31 --- 1 file changed, 20 insertions(+), 11 deletions(-) diff --git a/board-qemu/slof/pci-interrupts.fs b/board-qemu/slof/pci-interrupts.fs index a12d7bb..62785a7 100644 --- a/board-qemu/slof/pci-interrupts.fs +++ b/board-qemu/slof/pci-interrupts.fs @@ -1,17 +1,26 @@ : pci-gen-irq-map-one ( prop-addr prop-len slot pin -- prop-addr prop-len ) -2dup + 4 mod( prop-addr prop-len slot pin parentpin ) +2dup + 4 mod( prop-addr prop-len slot pin parentpin ) +r r r( prop-addr prop-len R: swizzledpin pin slot ) + +\ Child slot# +r B lshift encode-int+ ( prop-addr prop-len R: swizzledpin pin ) Redundant push to the R-Stack, can just be r r( prop-addr prop-len slot R: swizzledpin pin ) \ Child slot# B lshift encode-int+ ( prop-addr prop-len R: swizzledpin pin ) +\ Child 64bit BAR (not really used) +0 encode-64+ +\ Chile pin# +r encode-int+ ( prop-addr prop-len R: swizzledpin ) + +\ Parent phandle +get-parent encode-int+ + +\ Parent slot# get-node space -pci-addr2dev + 1- 4 mod 1+ \ do swizzling ( prop-addr prop-len slot pin swizzledpin ) -r r r( prop-addr prop-len R: swizzledpin pin slot ) - -r B lshift encode-int+ -0 encode-64+\ device slot ( prop-addr prop-len R: swizzledpin pin ) -r encode-int+ \ device pin( prop-addr prop-len R: swizzledpin ) - -get-parent encode-int+ \ parent phandle -
