Re: Build regressions/improvements in v3.14-rc3
On Tue, Feb 18, 2014 at 10:02 AM, Geert Uytterhoeven
wrote:
> JFYI, when comparing v3.14-rc3[1] to v3.14-rc2[3], the summaries are:
> - build errors: +17/-6
+ /scratch/kisskb/src/arch/powerpc/include/asm/floppy.h: error:
'isa_bridge_pcidev' undeclared (first use in this function): =>
142:20
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error: #error
m8xx_pcmcia: Bad configuration!: => 127:2
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error:
'PCMCIA_IO_WIN_NO' undeclared here (not in a function): => 220:30
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error:
'PCMCIA_MEM_WIN_NO' undeclared here (not in a function): => 219:32
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error:
'PCMCIA_SOCKETS_NO' undeclared here (not in a function): => 225:34
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error: 'irq_map'
undeclared (first use in this function): => 1027:10
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error: 's'
undeclared (first use in this function): => 982:2
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error: expected
')' before 'PCMCIA_BOARD_MSG': => 1036:2
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error: implicit
declaration of function 'hardware_disable'
[-Werror=implicit-function-declaration]: => 1137:3
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error: implicit
declaration of function 'hardware_enable'
[-Werror=implicit-function-declaration]: => 1080:2
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error: implicit
declaration of function 'mk_int_int_mask'
[-Werror=implicit-function-declaration]: => 748:6
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error: implicit
declaration of function 'socket_get'
[-Werror=implicit-function-declaration]: => 657:2
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error: implicit
declaration of function 'voltage_set'
[-Werror=implicit-function-declaration]: => 686:2
powerpc-randconfig
+ /scratch/kisskb/src/drivers/gpio/gpio-xtensa.c: Error: unknown
opcode or format name 'read_impwire': => 87
+ /scratch/kisskb/src/drivers/gpio/gpio-xtensa.c: Error: unknown
opcode or format name 'rur.expstate': => 110
+ /scratch/kisskb/src/drivers/gpio/gpio-xtensa.c: Error: unknown
opcode or format name 'wrmsk_expstate': => 124
xtensa-allmodconfig
+ error: kvm_main.c: undefined reference to `__stack_chk_guard': =>
.text+0x6895)
i386-randconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/7190/ (all 119 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/7167/ (all 119 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ppc: RECLAIM_DISTANCE 10?
Hi, I have just noticed that ppc has RECLAIM_DISTANCE reduced to 10 set by 56608209d34b (powerpc/numa: Set a smaller value for RECLAIM_DISTANCE to enable zone reclaim). The commit message suggests that the zone reclaim is desirable for all NUMA configurations. History has shown that the zone reclaim is more often harmful than helpful and leads to performance problems. The default RECLAIM_DISTANCE for generic case has been increased from 20 to 30 around 3.0 (32e45ff43eaf mm: increase RECLAIM_DISTANCE to 30). I strongly suspect that the patch is incorrect and it should be reverted. Before I will send a revert I would like to understand what led to the patch in the first place. I do not see why would PPC use only LOCAL_DISTANCE and REMOTE_DISTANCE distances and in fact machines I have seen use different values. Anton, could you comment please? -- Michal Hocko SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RFC 00/31] SDHCI and SDIO IRQ improvements
The following patch series is targetted at two things - fixing the SDIO interrupt handling, and fixing problems with the sdhci driver. - the first two patches from Thomas Gleixner provide genirq support to allow us to fix the SDIO interrupt handling in a graceful manner. - patch 3 adds support for avoiding the buggy sdio_irq thread - the problem is described in that commit. Other solutions were explored, but this is the one which was settled on after discussions between Thomas, scheduler people and myself. - patches 4 to 7 update sdhci to use a genirq to deal with the threaded part of the interrupts. - patch 8 allows card interrupts to be received from a SDIO card while runtime suspended. Without this patch, Wifi cards attached to a kernel with runtime PM support built in totally fail to work. This allows them to work. Tested in 4-bit mode. - patches 9 onwards are cleanups and fixes to the sdhci code. drivers/mmc/core/sdio_irq.c| 41 ++- drivers/mmc/host/sdhci-acpi.c | 8 + drivers/mmc/host/sdhci-bcm-kona.c | 4 + drivers/mmc/host/sdhci-bcm2835.c | 4 + drivers/mmc/host/sdhci-cns3xxx.c | 13 +- drivers/mmc/host/sdhci-dove.c | 4 + drivers/mmc/host/sdhci-esdhc-imx.c | 82 ++--- drivers/mmc/host/sdhci-esdhc.h | 4 +- drivers/mmc/host/sdhci-of-arasan.c | 4 + drivers/mmc/host/sdhci-of-esdhc.c | 70 +++-- drivers/mmc/host/sdhci-of-hlwd.c | 4 + drivers/mmc/host/sdhci-pci.c | 9 +- drivers/mmc/host/sdhci-pltfm.c | 4 + drivers/mmc/host/sdhci-pxav2.c | 14 +- drivers/mmc/host/sdhci-pxav3.c | 13 +- drivers/mmc/host/sdhci-s3c.c | 36 ++- drivers/mmc/host/sdhci-sirf.c | 4 + drivers/mmc/host/sdhci-spear.c | 5 +- drivers/mmc/host/sdhci-tegra.c | 27 +- drivers/mmc/host/sdhci.c | 606 ++--- drivers/mmc/host/sdhci.h | 20 +- include/linux/hardirq.h| 1 + include/linux/interrupt.h | 1 + include/linux/mmc/host.h | 3 + include/linux/mmc/sdhci.h | 14 +- kernel/irq/handle.c| 4 +- kernel/irq/internals.h | 1 + kernel/irq/manage.c| 94 -- 28 files changed, 608 insertions(+), 486 deletions(-) -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was "up to 13.2Mbit". ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RFC 11/31] mmc: sdhci: convert generic bus width setup to library function
Signed-off-by: Russell King
=-DO NOT APPLY-=
drivers/mmc/host/sdhci-acpi.c | 2 ++
drivers/mmc/host/sdhci-bcm-kona.c | 1 +
drivers/mmc/host/sdhci-bcm2835.c | 1 +
drivers/mmc/host/sdhci-cns3xxx.c | 1 +
drivers/mmc/host/sdhci-dove.c | 1 +
drivers/mmc/host/sdhci-esdhc-imx.c | 6 ++---
drivers/mmc/host/sdhci-of-arasan.c | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 6 ++---
drivers/mmc/host/sdhci-of-hlwd.c | 1 +
drivers/mmc/host/sdhci-pci.c | 6 ++---
drivers/mmc/host/sdhci-pltfm.c | 1 +
drivers/mmc/host/sdhci-pxav2.c | 6 ++---
drivers/mmc/host/sdhci-pxav3.c | 1 +
drivers/mmc/host/sdhci-s3c.c | 8 +++
drivers/mmc/host/sdhci-sirf.c | 1 +
drivers/mmc/host/sdhci-spear.c | 2 +-
drivers/mmc/host/sdhci-tegra.c | 5 ++---
drivers/mmc/host/sdhci.c | 45 +++---
drivers/mmc/host/sdhci.h | 5 +++--
19 files changed, 50 insertions(+), 50 deletions(-)
diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
index 9ce17f6e4014..b138bfdd3843 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-acpi.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-acpi.c
@@ -102,10 +102,12 @@ static void sdhci_acpi_int_hw_reset(struct sdhci_host
*host)
static const struct sdhci_ops sdhci_acpi_ops_dflt = {
.enable_dma = sdhci_acpi_enable_dma,
=+DO NOT APPLY+=.set_bus_width = sdhci_set_bus_width,
};
static const struct sdhci_ops sdhci_acpi_ops_int = {
.enable_dma = sdhci_acpi_enable_dma,
=+DO NOT APPLY+=.set_bus_width = sdhci_set_bus_width,
.hw_reset = sdhci_acpi_int_hw_reset,
};
diff --git a/drivers/mmc/host/sdhci-bcm-kona.c
b/drivers/mmc/host/sdhci-bcm-kona.c
index 7a190fe4dff1..bf851a6e4e8e 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-bcm-kona.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-bcm-kona.c
@@ -208,6 +208,7 @@ static struct sdhci_ops sdhci_bcm_kona_ops = {
.get_max_clock = sdhci_bcm_kona_get_max_clk,
.get_timeout_clock = sdhci_bcm_kona_get_timeout_clock,
.platform_send_init_74_clocks = sdhci_bcm_kona_init_74_clocks,
=+DO NOT APPLY+=.set_bus_width = sdhci_set_bus_width,
.card_event = sdhci_bcm_kona_card_event,
};
diff --git a/drivers/mmc/host/sdhci-bcm2835.c b/drivers/mmc/host/sdhci-bcm2835.c
index f6d8d67c545f..7ab69af979b4 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-bcm2835.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-bcm2835.c
@@ -133,6 +133,7 @@ static const struct sdhci_ops bcm2835_sdhci_ops = {
.read_b = bcm2835_sdhci_readb,
.get_max_clock = sdhci_pltfm_clk_get_max_clock,
.get_min_clock = bcm2835_sdhci_get_min_clock,
=+DO NOT APPLY+=.set_bus_width = sdhci_set_bus_width,
};
static const struct sdhci_pltfm_data bcm2835_sdhci_pdata = {
diff --git a/drivers/mmc/host/sdhci-cns3xxx.c b/drivers/mmc/host/sdhci-cns3xxx.c
index f2cc26633cb2..5e0cc9c47887 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-cns3xxx.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-cns3xxx.c
@@ -82,6 +82,7 @@ static void sdhci_cns3xxx_set_clock(struct sdhci_host *host,
unsigned int clock)
static const struct sdhci_ops sdhci_cns3xxx_ops = {
.get_max_clock = sdhci_cns3xxx_get_max_clk,
.set_clock = sdhci_cns3xxx_set_clock,
=+DO NOT APPLY+=.set_bus_width = sdhci_set_bus_width,
};
static const struct sdhci_pltfm_data sdhci_cns3xxx_pdata = {
diff --git a/drivers/mmc/host/sdhci-dove.c b/drivers/mmc/host/sdhci-dove.c
index 8424839660f8..7eef4890fd22 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-dove.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-dove.c
@@ -86,6 +86,7 @@ static u32 sdhci_dove_readl(struct sdhci_host *host, int reg)
static const struct sdhci_ops sdhci_dove_ops = {
.read_w = sdhci_dove_readw,
.read_l = sdhci_dove_readl,
=+DO NOT APPLY+=.set_bus_width = sdhci_set_bus_width,
};
static const struct sdhci_pltfm_data sdhci_dove_pdata = {
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c
b/drivers/mmc/host/sdhci-esdhc-imx.c
index b0b4eea8d232..568239d84cbe 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-esdhc-imx.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -668,7 +668,7 @@ static unsigned int esdhc_pltfm_get_ro(struct sdhci_host
*host)
return -ENOSYS;
}
-static int esdhc_pltfm_bus_width(struct sdhci_host *host, int width)
=+DO NOT APPLY+=static void esdhc_pltfm_set_bus_width(struct sdhci_host *host,
int width)
{
u32 ctrl;
@@ -686,8 +686,6 @@ static int esdhc_pltfm_bus_width(struct sdhci_host *host,
int width)
esdhc_clrset_le(host, ESDHC_CTRL_BUSWIDTH_MASK, ctrl,
SDHCI_HOST_CONTROL);
-
- return 0;
}
static void esdhc_prepare_tuning(struct sdhci_host *host, u32 val)
@@ -888,7 +886,7 @@ static struct sdhci_ops sdhci_esdhc_ops = {
.get_max_clock = esdhc_pltfm_get_max_clock,
.get_min_clock = esdhc_pltfm_get_min_clock,
[PATCH RFC 12/31] mmc: sdhci: convert reset into a library function
Rather than having platform_reset_enter/platform_reset_exit methods,
turn the core of the reset handling into a library function which
platforms can call at the appropriate moment in their (new) reset
method.
Signed-off-by: Russell King
=-DO NOT APPLY-=
drivers/mmc/host/sdhci-acpi.c | 2 ++
drivers/mmc/host/sdhci-bcm-kona.c | 1 +
drivers/mmc/host/sdhci-bcm2835.c | 1 +
drivers/mmc/host/sdhci-cns3xxx.c | 1 +
drivers/mmc/host/sdhci-dove.c | 1 +
drivers/mmc/host/sdhci-esdhc-imx.c | 1 +
drivers/mmc/host/sdhci-of-arasan.c | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 1 +
drivers/mmc/host/sdhci-of-hlwd.c | 1 +
drivers/mmc/host/sdhci-pci.c | 1 +
drivers/mmc/host/sdhci-pltfm.c | 1 +
drivers/mmc/host/sdhci-pxav2.c | 6 +++--
drivers/mmc/host/sdhci-pxav3.c | 6 +++--
drivers/mmc/host/sdhci-s3c.c | 1 +
drivers/mmc/host/sdhci-sirf.c | 1 +
drivers/mmc/host/sdhci-spear.c | 1 +
drivers/mmc/host/sdhci-tegra.c | 6 +++--
drivers/mmc/host/sdhci.c | 47 +++---
drivers/mmc/host/sdhci.h | 4 ++--
19 files changed, 53 insertions(+), 31 deletions(-)
diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
index b138bfdd3843..1ded6690be43 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-acpi.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-acpi.c
@@ -103,11 +103,13 @@ static void sdhci_acpi_int_hw_reset(struct sdhci_host
*host)
static const struct sdhci_ops sdhci_acpi_ops_dflt = {
.enable_dma = sdhci_acpi_enable_dma,
.set_bus_width = sdhci_set_bus_width,
=+DO NOT APPLY+=.reset = sdhci_reset,
};
static const struct sdhci_ops sdhci_acpi_ops_int = {
.enable_dma = sdhci_acpi_enable_dma,
.set_bus_width = sdhci_set_bus_width,
=+DO NOT APPLY+=.reset = sdhci_reset,
.hw_reset = sdhci_acpi_int_hw_reset,
};
diff --git a/drivers/mmc/host/sdhci-bcm-kona.c
b/drivers/mmc/host/sdhci-bcm-kona.c
index bf851a6e4e8e..4c82ecb7a71e 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-bcm-kona.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-bcm-kona.c
@@ -209,6 +209,7 @@ static struct sdhci_ops sdhci_bcm_kona_ops = {
.get_timeout_clock = sdhci_bcm_kona_get_timeout_clock,
.platform_send_init_74_clocks = sdhci_bcm_kona_init_74_clocks,
.set_bus_width = sdhci_set_bus_width,
=+DO NOT APPLY+=.reset = sdhci_reset,
.card_event = sdhci_bcm_kona_card_event,
};
diff --git a/drivers/mmc/host/sdhci-bcm2835.c b/drivers/mmc/host/sdhci-bcm2835.c
index 7ab69af979b4..289b1c80d5fc 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-bcm2835.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-bcm2835.c
@@ -134,6 +134,7 @@ static const struct sdhci_ops bcm2835_sdhci_ops = {
.get_max_clock = sdhci_pltfm_clk_get_max_clock,
.get_min_clock = bcm2835_sdhci_get_min_clock,
.set_bus_width = sdhci_set_bus_width,
=+DO NOT APPLY+=.reset = sdhci_reset,
};
static const struct sdhci_pltfm_data bcm2835_sdhci_pdata = {
diff --git a/drivers/mmc/host/sdhci-cns3xxx.c b/drivers/mmc/host/sdhci-cns3xxx.c
index 5e0cc9c47887..87af66bb1ea8 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-cns3xxx.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-cns3xxx.c
@@ -83,6 +83,7 @@ static const struct sdhci_ops sdhci_cns3xxx_ops = {
.get_max_clock = sdhci_cns3xxx_get_max_clk,
.set_clock = sdhci_cns3xxx_set_clock,
.set_bus_width = sdhci_set_bus_width,
=+DO NOT APPLY+=.reset = sdhci_reset,
};
static const struct sdhci_pltfm_data sdhci_cns3xxx_pdata = {
diff --git a/drivers/mmc/host/sdhci-dove.c b/drivers/mmc/host/sdhci-dove.c
index 7eef4890fd22..4c0191bff85d 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-dove.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-dove.c
@@ -87,6 +87,7 @@ static const struct sdhci_ops sdhci_dove_ops = {
.read_w = sdhci_dove_readw,
.read_l = sdhci_dove_readl,
.set_bus_width = sdhci_set_bus_width,
=+DO NOT APPLY+=.reset = sdhci_reset,
};
static const struct sdhci_pltfm_data sdhci_dove_pdata = {
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c
b/drivers/mmc/host/sdhci-esdhc-imx.c
index 568239d84cbe..b1d74fa33c5f 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-esdhc-imx.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -888,6 +888,7 @@ static struct sdhci_ops sdhci_esdhc_ops = {
.get_ro = esdhc_pltfm_get_ro,
.set_bus_width = esdhc_pltfm_set_bus_width,
.set_uhs_signaling = esdhc_set_uhs_signaling,
=+DO NOT APPLY+=.reset = sdhci_reset,
};
static const struct sdhci_pltfm_data sdhci_esdhc_imx_pdata = {
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index 9bb1dd263a45..faef21740584 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-of-arasan.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-of-arasan.c
@@ -55,6 +55,7 @@ static struct sdhci_ops sdhci_arasan_ops = {
[PATCH RFC 19/31] mmc: sdhci: convert sdhci_set_clock() into a library function
Signed-off-by: Russell King
=-DO NOT APPLY-=
drivers/mmc/host/sdhci-acpi.c | 2 ++
drivers/mmc/host/sdhci-bcm-kona.c | 1 +
drivers/mmc/host/sdhci-bcm2835.c | 1 +
drivers/mmc/host/sdhci-cns3xxx.c | 3 +--
drivers/mmc/host/sdhci-dove.c | 1 +
drivers/mmc/host/sdhci-esdhc.h | 1 -
drivers/mmc/host/sdhci-of-arasan.c | 1 +
drivers/mmc/host/sdhci-of-hlwd.c | 1 +
drivers/mmc/host/sdhci-pci.c | 1 +
drivers/mmc/host/sdhci-pltfm.c | 1 +
drivers/mmc/host/sdhci-pxav2.c | 1 +
drivers/mmc/host/sdhci-pxav3.c | 1 +
drivers/mmc/host/sdhci-s3c.c | 19 ++-
drivers/mmc/host/sdhci-sirf.c | 1 +
drivers/mmc/host/sdhci-spear.c | 1 +
drivers/mmc/host/sdhci-tegra.c | 1 +
drivers/mmc/host/sdhci.c | 17 ++---
drivers/mmc/host/sdhci.h | 1 +
include/linux/mmc/sdhci.h | 2 --
19 files changed, 36 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
index 1ded6690be43..c20964e577e9 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-acpi.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-acpi.c
@@ -101,12 +101,14 @@ static void sdhci_acpi_int_hw_reset(struct sdhci_host
*host)
}
static const struct sdhci_ops sdhci_acpi_ops_dflt = {
=+DO NOT APPLY+=.set_clock = sdhci_set_clock,
.enable_dma = sdhci_acpi_enable_dma,
.set_bus_width = sdhci_set_bus_width,
.reset = sdhci_reset,
};
static const struct sdhci_ops sdhci_acpi_ops_int = {
=+DO NOT APPLY+=.set_clock = sdhci_set_clock,
.enable_dma = sdhci_acpi_enable_dma,
.set_bus_width = sdhci_set_bus_width,
.reset = sdhci_reset,
diff --git a/drivers/mmc/host/sdhci-bcm-kona.c
b/drivers/mmc/host/sdhci-bcm-kona.c
index 4c82ecb7a71e..77b14b1a24bc 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-bcm-kona.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-bcm-kona.c
@@ -205,6 +205,7 @@ static void sdhci_bcm_kona_init_74_clocks(struct sdhci_host
*host,
}
static struct sdhci_ops sdhci_bcm_kona_ops = {
=+DO NOT APPLY+=.set_clock = sdhci_set_clock,
.get_max_clock = sdhci_bcm_kona_get_max_clk,
.get_timeout_clock = sdhci_bcm_kona_get_timeout_clock,
.platform_send_init_74_clocks = sdhci_bcm_kona_init_74_clocks,
diff --git a/drivers/mmc/host/sdhci-bcm2835.c b/drivers/mmc/host/sdhci-bcm2835.c
index 289b1c80d5fc..74906d6008e1 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-bcm2835.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-bcm2835.c
@@ -131,6 +131,7 @@ static const struct sdhci_ops bcm2835_sdhci_ops = {
.read_l = bcm2835_sdhci_readl,
.read_w = bcm2835_sdhci_readw,
.read_b = bcm2835_sdhci_readb,
=+DO NOT APPLY+=.set_clock = sdhci_set_clock,
.get_max_clock = sdhci_pltfm_clk_get_max_clock,
.get_min_clock = bcm2835_sdhci_get_min_clock,
.set_bus_width = sdhci_set_bus_width,
diff --git a/drivers/mmc/host/sdhci-cns3xxx.c b/drivers/mmc/host/sdhci-cns3xxx.c
index 416f4a4c2e35..587d73ef33ff 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-cns3xxx.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-cns3xxx.c
@@ -89,8 +89,7 @@ static const struct sdhci_pltfm_data sdhci_cns3xxx_pdata = {
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
SDHCI_QUIRK_INVERTED_WRITE_PROTECT |
SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN |
- SDHCI_QUIRK_BROKEN_TIMEOUT_VAL |
- SDHCI_QUIRK_NONSTANDARD_CLOCK,
=+DO NOT APPLY+= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL,
};
static int sdhci_cns3xxx_probe(struct platform_device *pdev)
diff --git a/drivers/mmc/host/sdhci-dove.c b/drivers/mmc/host/sdhci-dove.c
index 4c0191bff85d..4f4216115aed 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-dove.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-dove.c
@@ -86,6 +86,7 @@ static u32 sdhci_dove_readl(struct sdhci_host *host, int reg)
static const struct sdhci_ops sdhci_dove_ops = {
.read_w = sdhci_dove_readw,
.read_l = sdhci_dove_readl,
=+DO NOT APPLY+=.set_clock = sdhci_set_clock,
.set_bus_width = sdhci_set_bus_width,
.reset = sdhci_reset,
};
diff --git a/drivers/mmc/host/sdhci-esdhc.h b/drivers/mmc/host/sdhci-esdhc.h
index de69bddc3afc..3497cfaf683c 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-esdhc.h
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-esdhc.h
@@ -20,7 +20,6 @@
#define ESDHC_DEFAULT_QUIRKS (SDHCI_QUIRK_FORCE_BLK_SZ_2048 | \
SDHCI_QUIRK_NO_BUSY_IRQ | \
- SDHCI_QUIRK_NONSTANDARD_CLOCK | \
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK | \
SDHCI_QUIRK_PIO_NEEDS_DELAY)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index faef21740584..f0ee594f25d1 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-of-arasan.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-of
[PATCH RFC 25/31] mmc: sdhci: convert sdhci_set_uhs_signaling() into a library function
Add sdhci_set_uhs_signaling() and always call the set_uhs_signaling
method. This avoids quirks being added into sdhci_set_uhs_signaling().
Signed-off-by: Russell King
=-DO NOT APPLY-=
drivers/mmc/host/sdhci-acpi.c | 2 ++
drivers/mmc/host/sdhci-bcm-kona.c | 1 +
drivers/mmc/host/sdhci-bcm2835.c | 1 +
drivers/mmc/host/sdhci-cns3xxx.c | 1 +
drivers/mmc/host/sdhci-dove.c | 1 +
drivers/mmc/host/sdhci-of-arasan.c | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 1 +
drivers/mmc/host/sdhci-of-hlwd.c | 1 +
drivers/mmc/host/sdhci-pci.c | 1 +
drivers/mmc/host/sdhci-pltfm.c | 1 +
drivers/mmc/host/sdhci-pxav2.c | 1 +
drivers/mmc/host/sdhci-pxav3.c | 1 +
drivers/mmc/host/sdhci-s3c.c | 1 +
drivers/mmc/host/sdhci-sirf.c | 1 +
drivers/mmc/host/sdhci-spear.c | 1 +
drivers/mmc/host/sdhci-tegra.c | 1 +
drivers/mmc/host/sdhci.c | 42 +-
drivers/mmc/host/sdhci.h | 1 +
18 files changed, 41 insertions(+), 19 deletions(-)
diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
index c20964e577e9..2ece31d88196 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-acpi.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-acpi.c
@@ -105,6 +105,7 @@ static const struct sdhci_ops sdhci_acpi_ops_dflt = {
.enable_dma = sdhci_acpi_enable_dma,
.set_bus_width = sdhci_set_bus_width,
.reset = sdhci_reset,
=+DO NOT APPLY+=.set_uhs_signaling = sdhci_set_uhs_signaling,
};
static const struct sdhci_ops sdhci_acpi_ops_int = {
@@ -112,6 +113,7 @@ static const struct sdhci_ops sdhci_acpi_ops_int = {
.enable_dma = sdhci_acpi_enable_dma,
.set_bus_width = sdhci_set_bus_width,
.reset = sdhci_reset,
=+DO NOT APPLY+=.set_uhs_signaling = sdhci_set_uhs_signaling,
.hw_reset = sdhci_acpi_int_hw_reset,
};
diff --git a/drivers/mmc/host/sdhci-bcm-kona.c
b/drivers/mmc/host/sdhci-bcm-kona.c
index 77b14b1a24bc..20096aaf14b4 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-bcm-kona.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-bcm-kona.c
@@ -211,6 +211,7 @@ static struct sdhci_ops sdhci_bcm_kona_ops = {
.platform_send_init_74_clocks = sdhci_bcm_kona_init_74_clocks,
.set_bus_width = sdhci_set_bus_width,
.reset = sdhci_reset,
=+DO NOT APPLY+=.set_uhs_signaling = sdhci_set_uhs_signaling,
.card_event = sdhci_bcm_kona_card_event,
};
diff --git a/drivers/mmc/host/sdhci-bcm2835.c b/drivers/mmc/host/sdhci-bcm2835.c
index 74906d6008e1..46af9a439d7b 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-bcm2835.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-bcm2835.c
@@ -136,6 +136,7 @@ static const struct sdhci_ops bcm2835_sdhci_ops = {
.get_min_clock = bcm2835_sdhci_get_min_clock,
.set_bus_width = sdhci_set_bus_width,
.reset = sdhci_reset,
=+DO NOT APPLY+=.set_uhs_signaling = sdhci_set_uhs_signaling,
};
static const struct sdhci_pltfm_data bcm2835_sdhci_pdata = {
diff --git a/drivers/mmc/host/sdhci-cns3xxx.c b/drivers/mmc/host/sdhci-cns3xxx.c
index 587d73ef33ff..14b74075589a 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-cns3xxx.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-cns3xxx.c
@@ -81,6 +81,7 @@ static const struct sdhci_ops sdhci_cns3xxx_ops = {
.set_clock = sdhci_cns3xxx_set_clock,
.set_bus_width = sdhci_set_bus_width,
.reset = sdhci_reset,
=+DO NOT APPLY+=.set_uhs_signaling = sdhci_set_uhs_signaling,
};
static const struct sdhci_pltfm_data sdhci_cns3xxx_pdata = {
diff --git a/drivers/mmc/host/sdhci-dove.c b/drivers/mmc/host/sdhci-dove.c
index 4f4216115aed..8d6d0a293f17 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-dove.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-dove.c
@@ -89,6 +89,7 @@ static const struct sdhci_ops sdhci_dove_ops = {
.set_clock = sdhci_set_clock,
.set_bus_width = sdhci_set_bus_width,
.reset = sdhci_reset,
=+DO NOT APPLY+=.set_uhs_signaling = sdhci_set_uhs_signaling,
};
static const struct sdhci_pltfm_data sdhci_dove_pdata = {
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index f0ee594f25d1..5bd1092310f2 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-of-arasan.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-of-arasan.c
@@ -57,6 +57,7 @@ static struct sdhci_ops sdhci_arasan_ops = {
.get_timeout_clock = sdhci_arasan_get_timeout_clock,
.set_bus_width = sdhci_set_bus_width,
.reset = sdhci_reset,
=+DO NOT APPLY+=.set_uhs_signaling = sdhci_set_uhs_signaling,
};
static struct sdhci_pltfm_data sdhci_arasan_pdata = {
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
b/drivers/mmc/host/sdhci-of-esdhc.c
index c4f8cd3f83c8..fcaeae5f55b8 100644
=-DO NOT APPLY-= a/drivers/mmc/host/sdhci-of-esdhc.c
=+DO NOT APPLY+= b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -309,6 +309,7 @@ static const struct sdhci_ops sdhci_esdhc_o
Re: [RFC PATCH 2/3] topology: support node_numa_mem() for determining the fallback node
On Mon, 17 Feb 2014, Joonsoo Kim wrote:
> On Wed, Feb 12, 2014 at 04:16:11PM -0600, Christoph Lameter wrote:
> > Here is another patch with some fixes. The additional logic is only
> > compiled in if CONFIG_HAVE_MEMORYLESS_NODES is set.
> >
> > Subject: slub: Memoryless node support
> >
> > Support memoryless nodes by tracking which allocations are failing.
>
> I still don't understand why this tracking is needed.
Its an optimization to avoid calling the page allocator to figure out if
there is memory available on a particular node.
> All we need for allcation targeted to memoryless node is to fallback proper
> node, that it, numa_mem_id() node of targeted node. My previous patch
> implements it and use proper fallback node on every allocation code path.
> Why this tracking is needed? Please elaborate more on this.
Its too slow to do that on every alloc. One needs to be able to satisfy
most allocations without switching percpu slabs for optimal performance.
> > Allocations targeted to the nodes without memory fall back to the
> > current available per cpu objects and if that is not available will
> > create a new slab using the page allocator to fallback from the
> > memoryless node to some other node.
And what about the next alloc? Assuem there are N allocs from a memoryless
node this means we push back the partial slab on each alloc and then fall
back?
> > {
> > void *object;
> > - int searchnode = (node == NUMA_NO_NODE) ? numa_node_id() : node;
> > + int searchnode = (node == NUMA_NO_NODE) ? numa_mem_id() : node;
> >
> > object = get_partial_node(s, get_node(s, searchnode), c, flags);
> > if (object || node != NUMA_NO_NODE)
>
> This isn't enough.
> Consider that allcation targeted to memoryless node.
It will not common get there because of the tracking. Instead a per cpu
object will be used.
> get_partial_node() always fails even if there are some partial slab on
> memoryless node's neareast node.
Correct and that leads to a page allocator action whereupon the node will
be marked as empty.
> We should fallback to some proper node in this case, since there is no slab
> on memoryless node.
NUMA is about optimization of memory allocations. It is often *not* about
correctness but heuristics are used in many cases. F.e. see the zone
reclaim logic, zone reclaim mode, fallback scenarios in the page allocator
etc etc.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 2/3] topology: support node_numa_mem() for determining the fallback node
On Mon, 17 Feb 2014, Joonsoo Kim wrote: > On Wed, Feb 12, 2014 at 10:51:37PM -0800, Nishanth Aravamudan wrote: > > Hi Joonsoo, > > Also, given that only ia64 and (hopefuly soon) ppc64 can set > > CONFIG_HAVE_MEMORYLESS_NODES, does that mean x86_64 can't have > > memoryless nodes present? Even with fakenuma? Just curious. x86_64 currently does not support memoryless nodes otherwise it would have set CONFIG_HAVE_MEMORYLESS_NODES in the kconfig. Memoryless nodes are a bit strange given that the NUMA paradigm is to have NUMA nodes (meaning memory) with processors. MEMORYLESS nodes means that we have a fake NUMA node without memory but just processors. Not very efficient. Not sure why people use these configurations. > I don't know, because I'm not expert on NUMA system :) > At first glance, fakenuma can't be used for testing > CONFIG_HAVE_MEMORYLESS_NODES. Maybe some modification is needed. Well yeah. You'd have to do some mods to enable that testing. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 2/3] topology: support node_numa_mem() for determining the fallback node
On 12.02.2014 [16:16:11 -0600], Christoph Lameter wrote:
> Here is another patch with some fixes. The additional logic is only
> compiled in if CONFIG_HAVE_MEMORYLESS_NODES is set.
>
> Subject: slub: Memoryless node support
>
> Support memoryless nodes by tracking which allocations are failing.
> Allocations targeted to the nodes without memory fall back to the
> current available per cpu objects and if that is not available will
> create a new slab using the page allocator to fallback from the
> memoryless node to some other node.
>
> Signed-off-by: Christoph Lameter
Tested-by: Nishanth Aravamudan
Acked-by: Nishanth Aravamudan
> Index: linux/mm/slub.c
> ===
> --- linux.orig/mm/slub.c 2014-02-12 16:07:48.957869570 -0600
> +++ linux/mm/slub.c 2014-02-12 16:09:22.198928260 -0600
> @@ -134,6 +134,10 @@ static inline bool kmem_cache_has_cpu_pa
> #endif
> }
>
> +#ifdef CONFIG_HAVE_MEMORYLESS_NODES
> +static nodemask_t empty_nodes;
> +#endif
> +
> /*
> * Issues still to be resolved:
> *
> @@ -1405,16 +1409,28 @@ static struct page *new_slab(struct kmem
> void *last;
> void *p;
> int order;
> + int alloc_node;
>
> BUG_ON(flags & GFP_SLAB_BUG_MASK);
>
> page = allocate_slab(s,
> flags & (GFP_RECLAIM_MASK | GFP_CONSTRAINT_MASK), node);
> - if (!page)
> + if (!page) {
> +#ifdef CONFIG_HAVE_MEMORYLESS_NODES
> + if (node != NUMA_NO_NODE)
> + node_set(node, empty_nodes);
> +#endif
> goto out;
> + }
>
> order = compound_order(page);
> - inc_slabs_node(s, page_to_nid(page), page->objects);
> + alloc_node = page_to_nid(page);
> +#ifdef CONFIG_HAVE_MEMORYLESS_NODES
> + node_clear(alloc_node, empty_nodes);
> + if (node != NUMA_NO_NODE && alloc_node != node)
> + node_set(node, empty_nodes);
> +#endif
> + inc_slabs_node(s, alloc_node, page->objects);
> memcg_bind_pages(s, order);
> page->slab_cache = s;
> __SetPageSlab(page);
> @@ -1722,7 +1738,7 @@ static void *get_partial(struct kmem_cac
> struct kmem_cache_cpu *c)
> {
> void *object;
> - int searchnode = (node == NUMA_NO_NODE) ? numa_node_id() : node;
> + int searchnode = (node == NUMA_NO_NODE) ? numa_mem_id() : node;
>
> object = get_partial_node(s, get_node(s, searchnode), c, flags);
> if (object || node != NUMA_NO_NODE)
> @@ -2117,8 +2133,19 @@ static void flush_all(struct kmem_cache
> static inline int node_match(struct page *page, int node)
> {
> #ifdef CONFIG_NUMA
> - if (!page || (node != NUMA_NO_NODE && page_to_nid(page) != node))
> + int page_node = page_to_nid(page);
> +
> + if (!page)
> return 0;
> +
> + if (node != NUMA_NO_NODE) {
> +#ifdef CONFIG_HAVE_MEMORYLESS_NODES
> + if (node_isset(node, empty_nodes))
> + return 1;
> +#endif
> + if (page_node != node)
> + return 0;
> + }
> #endif
> return 1;
> }
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 2/3] topology: support node_numa_mem() for determining the fallback node
On 18.02.2014 [10:57:09 -0600], Christoph Lameter wrote: > On Mon, 17 Feb 2014, Joonsoo Kim wrote: > > > On Wed, Feb 12, 2014 at 10:51:37PM -0800, Nishanth Aravamudan wrote: > > > Hi Joonsoo, > > > Also, given that only ia64 and (hopefuly soon) ppc64 can set > > > CONFIG_HAVE_MEMORYLESS_NODES, does that mean x86_64 can't have > > > memoryless nodes present? Even with fakenuma? Just curious. > > x86_64 currently does not support memoryless nodes otherwise it would > have set CONFIG_HAVE_MEMORYLESS_NODES in the kconfig. Memoryless nodes are > a bit strange given that the NUMA paradigm is to have NUMA nodes (meaning > memory) with processors. MEMORYLESS nodes means that we have a fake NUMA > node without memory but just processors. Not very efficient. Not sure why > people use these configurations. Well, on powerpc, with the hypervisor providing the resources and the topology, you can have cpuless and memoryless nodes. I'm not sure how "fake" the NUMA is -- as I think since the resources are virtualized to be one system, it's logically possible that the actual topology of the resources can be CPUs from physical node 0 and memory from physical node 2. I would think with KVM on a sufficiently large (physically NUMA x86_64) and loaded system, one could cause the same sort of configuration to occur for a guest? In any case, these configurations happen fairly often on long-running (not rebooted) systems as LPARs are created/destroyed, resources are DLPAR'd in and out of LPARs, etc. > > I don't know, because I'm not expert on NUMA system :) > > At first glance, fakenuma can't be used for testing > > CONFIG_HAVE_MEMORYLESS_NODES. Maybe some modification is needed. > > Well yeah. You'd have to do some mods to enable that testing. I might look into it, as it might have sped up testing these changes. Thanks, Nish ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 2/3] topology: support node_numa_mem() for determining the fallback node
On Tue, 18 Feb 2014, Nishanth Aravamudan wrote: > > Well, on powerpc, with the hypervisor providing the resources and the > topology, you can have cpuless and memoryless nodes. I'm not sure how > "fake" the NUMA is -- as I think since the resources are virtualized to > be one system, it's logically possible that the actual topology of the > resources can be CPUs from physical node 0 and memory from physical node > 2. I would think with KVM on a sufficiently large (physically NUMA > x86_64) and loaded system, one could cause the same sort of > configuration to occur for a guest? Ok but since you have a virtualized environment: Why not provide a fake home node with fake memory that could be anywhere? This would avoid the whole problem of supporting such a config at the kernel level. Do not have a fake node that has no memory. > In any case, these configurations happen fairly often on long-running > (not rebooted) systems as LPARs are created/destroyed, resources are > DLPAR'd in and out of LPARs, etc. Ok then also move the memory of the local node somewhere? > I might look into it, as it might have sped up testing these changes. I guess that will be necessary in order to support the memoryless nodes long term. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 2/3] topology: support node_numa_mem() for determining the fallback node
On 18.02.2014 [13:58:20 -0600], Christoph Lameter wrote: > On Tue, 18 Feb 2014, Nishanth Aravamudan wrote: > > > > > Well, on powerpc, with the hypervisor providing the resources and the > > topology, you can have cpuless and memoryless nodes. I'm not sure how > > "fake" the NUMA is -- as I think since the resources are virtualized to > > be one system, it's logically possible that the actual topology of the > > resources can be CPUs from physical node 0 and memory from physical node > > 2. I would think with KVM on a sufficiently large (physically NUMA > > x86_64) and loaded system, one could cause the same sort of > > configuration to occur for a guest? > > Ok but since you have a virtualized environment: Why not provide a fake > home node with fake memory that could be anywhere? This would avoid the > whole problem of supporting such a config at the kernel level. We use the topology provided by the hypervisor, it does actually reflect where CPUs and memory are, and their corresponding performance/NUMA characteristics. > Do not have a fake node that has no memory. > > > In any case, these configurations happen fairly often on long-running > > (not rebooted) systems as LPARs are created/destroyed, resources are > > DLPAR'd in and out of LPARs, etc. > > Ok then also move the memory of the local node somewhere? This happens below the OS, we don't control the hypervisor's decisions. I'm not sure if that's what you are suggesting. Thanks, Nish ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Anyone using SysRQ key sequences on console serial port ?
I am enable to get one keyboard sequence responded to with the noted change in the dts . for instance: SysRQ ( Break) c Panics .. Which is a good response, and since it doesn't require a return to user mode ( I suspect ) it appears to work. Any other requests fail to report any information : SysRQ (break ) l - list active processes m - list memory Any additional SysRQ are ignored., and the system appears hung. On an reference Intel platform, multiple SyqRQ can be issued and the system remains healthy . On Mon, Feb 17, 2014 at 1:37 PM, Scott Wood wrote: > On Sun, 2014-02-16 at 10:56 -0500, Paul Gortmaker wrote: > > On Fri, Feb 14, 2014 at 3:42 PM, John Donnelly > wrote: > > > Hi, > > > > > > I tried using the SysRq hotkey sequence on a serial console - > > > 3.11.0-5-powerpc-e500mc system, by issuing a " break " and the system > > > immediately wedges after displaying "SysRQ : HELP : " using both > "Putty" and > > > "Teraterm" terminal emulators. I know the system is dead because my > ssh > > > sessions stopped too. > > > > Yes it does work -- or at least it _did_ work. Make sure your dts has > an entry > > > > compatible = "fsl,ns16550", "ns16550"; > > > > since that enables a workaround I'd added for a hardware errata relating > > to sending breaks over the serial console. What you describe above > > makes me think you aren't getting the workaround enabled. > > Also make sure CONFIG_SERIAL_8250_FSL is enabled. > > -Scott > > > -- *Regards,* * John.* *--* *o* Energy-efficiency is #1 reason data centers look to expand. -- Digital Realty Trust *o* Green Data Centers spending to increase 300% worldwide by 2016. -- Pike Research *o *Data Centers have become as vital to the functioni ng of society as power stations. -- The Economist ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 2/3] topology: support node_numa_mem() for determining the fallback node
On Tue, 18 Feb 2014, Nishanth Aravamudan wrote: > We use the topology provided by the hypervisor, it does actually reflect > where CPUs and memory are, and their corresponding performance/NUMA > characteristics. And so there are actually nodes without memory that have processors? Can the hypervisor or the linux arch code be convinced to ignore nodes without memory or assign a sane default node to processors? > > Ok then also move the memory of the local node somewhere? > > This happens below the OS, we don't control the hypervisor's decisions. > I'm not sure if that's what you are suggesting. You could also do this from the powerpc arch code by sanitizing the processor / node information that is then used by Linux. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 2/3] topology: support node_numa_mem() for determining the fallback node
On 18.02.2014 [15:49:22 -0600], Christoph Lameter wrote: > On Tue, 18 Feb 2014, Nishanth Aravamudan wrote: > > > We use the topology provided by the hypervisor, it does actually reflect > > where CPUs and memory are, and their corresponding performance/NUMA > > characteristics. > > And so there are actually nodes without memory that have processors? Virtually (topologically as indicated to Linux), yes. Physically, I don't think they are, but they might be exhausted, which is we get sort of odd-appearing NUMA configurations. > Can the hypervisor or the linux arch code be convinced to ignore nodes > without memory or assign a sane default node to processors? I think this happens quite often, so I don't know that we want to ignore the performance impact of the underlying NUMA configuration. I guess we could special-case memoryless/cpuless configurations somewhat, but I don't think there's any reason to do that if we can make memoryless-node support work in-kernel? > > > Ok then also move the memory of the local node somewhere? > > > > This happens below the OS, we don't control the hypervisor's decisions. > > I'm not sure if that's what you are suggesting. > > You could also do this from the powerpc arch code by sanitizing the > processor / node information that is then used by Linux. I see what you're saying now, thanks! -Nish ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] powerpc/pseries: Report in kernel device tree update to drmgr
On 02/16/2014 04:22 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2014-01-31 at 15:58 -0800, Tyrel Datwyler wrote:
>> Traditionally it has been drmgr's responsibilty to update the device tree
>> through the /proc/ppc64/ofdt interface after a suspend/resume operation.
>> This patchset however has modified suspend/resume ops to preform that update
>> entirely in the kernel during the resume. Therefore, a mechanism is required
>> for drmgr to determine who is responsible for the update. This patch adds a
>> show function to the "hibernate" attribute that returns 1 if the kernel
>> updates the device tree after the resume and 0 if drmgr is responsible.
>
> This is not right.
>
> We cannot change the kernel behaviour in a way that is incompatible with
> existing userspace, and unless you can explain me why that is not the
> case, it feels like this patch set does just that
>
> What happens if you have an older drmgr which still does the update
> itself ?
>
In this case we get a double update which I clearly neglected to mention
in the patch. The first patch in this series actually removes an
unnecessary double update from the existing kernel implementation. The
same information is returned by the update-nodes/properties call the
second time around and aside from being a waste of a few cycles is harmless.
Tyrel
> You can't just change user visible behaviours and interface without at
> least explaining why it's ok to do so at the very least (and ensuring
> that of course) without breaking existing userspace.
>
> Now it's possible that the double update caused by this series is
> harmless, in which case please explain it in the changeset, I certainly
> can't assume it and if it's not, you'll need some other way for drmgr to
> signal the kernel to indicate it supports the new behaviour before you
> enable it.
>
> Ben.
>
>> Signed-off-by: Tyrel Datwyler
>> ---
>> arch/powerpc/platforms/pseries/suspend.c | 25 -
>> 1 file changed, 24 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/platforms/pseries/suspend.c
>> b/arch/powerpc/platforms/pseries/suspend.c
>> index 1d9c580..b87b978 100644
>> --- a/arch/powerpc/platforms/pseries/suspend.c
>> +++ b/arch/powerpc/platforms/pseries/suspend.c
>> @@ -192,7 +192,30 @@ out:
>> return rc;
>> }
>>
>> -static DEVICE_ATTR(hibernate, S_IWUSR, NULL, store_hibernate);
>> +#define USER_DT_UPDATE 0
>> +#define KERN_DT_UPDATE 1
>> +
>> +/**
>> + * show_hibernate - Report device tree update responsibilty
>> + * @dev:subsys root device
>> + * @attr: device attribute struct
>> + * @buf:buffer
>> + *
>> + * Report whether a device tree update is performed by the kernel after a
>> + * resume, or if drmgr must coordinate the update from user space.
>> + *
>> + * Return value:
>> + * 0 if drmgr is to initiate update, and 1 otherwise
>> + **/
>> +static ssize_t show_hibernate(struct device *dev,
>> + struct device_attribute *attr,
>> + char *buf)
>> +{
>> +return sprintf(buf, "%d\n", KERN_DT_UPDATE);
>> +}
>> +
>> +static DEVICE_ATTR(hibernate, S_IWUSR | S_IRUGO,
>> + show_hibernate, store_hibernate);
>>
>> static struct bus_type suspend_subsys = {
>> .name = "power",
>
>
> ___
> 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: ppc: RECLAIM_DISTANCE 10?
Hi Michal,
On 18.02.2014 [10:06:58 +0100], Michal Hocko wrote:
> Hi,
> I have just noticed that ppc has RECLAIM_DISTANCE reduced to 10 set by
> 56608209d34b (powerpc/numa: Set a smaller value for RECLAIM_DISTANCE to
> enable zone reclaim). The commit message suggests that the zone reclaim
> is desirable for all NUMA configurations.
>
> History has shown that the zone reclaim is more often harmful than
> helpful and leads to performance problems. The default RECLAIM_DISTANCE
> for generic case has been increased from 20 to 30 around 3.0
> (32e45ff43eaf mm: increase RECLAIM_DISTANCE to 30).
Interesting.
> I strongly suspect that the patch is incorrect and it should be
> reverted. Before I will send a revert I would like to understand what
> led to the patch in the first place. I do not see why would PPC use only
> LOCAL_DISTANCE and REMOTE_DISTANCE distances and in fact machines I have
> seen use different values.
>
> Anton, could you comment please?
I'll let Anton comment here, but in looking into this issue in working
on CONFIG_HAVE_MEMORYLESS_NODE support, I realized that any LPAR with
memoryless nodes will set zone_reclaim_mode to 1. I think we want to
ignore memoryless nodes when we set up the reclaim mode like the
following? I'll send it as a proper patch if you agree?
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 5de4337..4f6ff6f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1853,8 +1853,9 @@ static void __paginginit init_zone_allows_reclaim(int nid)
{
int i;
- for_each_online_node(i)
- if (node_distance(nid, i) <= RECLAIM_DISTANCE)
+ for_each_online_node(i) {
+ if (node_distance(nid, i) <= RECLAIM_DISTANCE ||
+ local_memory_node(nid) != nid)
node_set(i, NODE_DATA(nid)->reclaim_nodes);
else
zone_reclaim_mode = 1;
Note, this won't actually do anything if CONFIG_HAVE_MEMORYLESS_NODES is
not set, but if it is, I think semantically it will indicate that
memoryless nodes *have* to reclaim remotely.
And actually the above won't work, because the callpath is
start_kernel -> setup_arch -> paging_init [-> free_area_init_nodes ->
free_area_init_node -> init_zone_allows_reclaim] which is called before
build_all_zonelists. This is a similar ordering problem as I'm having
with the MEMORYLESS_NODE support, will work on it.
Thanks,
Nish
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] powerpc/pseries: Report in kernel device tree update to drmgr
On Tue, 2014-02-18 at 15:28 -0800, Tyrel Datwyler wrote: > In this case we get a double update which I clearly neglected to > mention > in the patch. The first patch in this series actually removes an > unnecessary double update from the existing kernel implementation. The > same information is returned by the update-nodes/properties call the > second time around and aside from being a waste of a few cycles is > harmless. Thanks. Can you resend the patches with updated descriptions ? I will try to send them to Linus by end of week. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc: RECLAIM_DISTANCE 10?
On 18.02.2014 [15:34:05 -0800], Nishanth Aravamudan wrote:
> Hi Michal,
>
> On 18.02.2014 [10:06:58 +0100], Michal Hocko wrote:
> > Hi,
> > I have just noticed that ppc has RECLAIM_DISTANCE reduced to 10 set by
> > 56608209d34b (powerpc/numa: Set a smaller value for RECLAIM_DISTANCE to
> > enable zone reclaim). The commit message suggests that the zone reclaim
> > is desirable for all NUMA configurations.
> >
> > History has shown that the zone reclaim is more often harmful than
> > helpful and leads to performance problems. The default RECLAIM_DISTANCE
> > for generic case has been increased from 20 to 30 around 3.0
> > (32e45ff43eaf mm: increase RECLAIM_DISTANCE to 30).
>
> Interesting.
>
> > I strongly suspect that the patch is incorrect and it should be
> > reverted. Before I will send a revert I would like to understand what
> > led to the patch in the first place. I do not see why would PPC use only
> > LOCAL_DISTANCE and REMOTE_DISTANCE distances and in fact machines I have
> > seen use different values.
> >
> > Anton, could you comment please?
>
> I'll let Anton comment here, but in looking into this issue in working
> on CONFIG_HAVE_MEMORYLESS_NODE support, I realized that any LPAR with
> memoryless nodes will set zone_reclaim_mode to 1. I think we want to
> ignore memoryless nodes when we set up the reclaim mode like the
> following? I'll send it as a proper patch if you agree?
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 5de4337..4f6ff6f 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1853,8 +1853,9 @@ static void __paginginit init_zone_allows_reclaim(int
> nid)
> {
> int i;
>
> - for_each_online_node(i)
> - if (node_distance(nid, i) <= RECLAIM_DISTANCE)
> + for_each_online_node(i) {
> + if (node_distance(nid, i) <= RECLAIM_DISTANCE ||
> + local_memory_node(nid) != nid)
> node_set(i, NODE_DATA(nid)->reclaim_nodes);
> else
> zone_reclaim_mode = 1;
>
> Note, this won't actually do anything if CONFIG_HAVE_MEMORYLESS_NODES is
> not set, but if it is, I think semantically it will indicate that
> memoryless nodes *have* to reclaim remotely.
>
> And actually the above won't work, because the callpath is
>
> start_kernel -> setup_arch -> paging_init [-> free_area_init_nodes ->
> free_area_init_node -> init_zone_allows_reclaim] which is called before
> build_all_zonelists. This is a similar ordering problem as I'm having
> with the MEMORYLESS_NODE support, will work on it.
How about the following?
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 5de4337..1a0eced 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1854,7 +1854,8 @@ static void __paginginit init_zone_allows_reclaim(int nid)
int i;
for_each_online_node(i)
- if (node_distance(nid, i) <= RECLAIM_DISTANCE)
+ if (node_distance(nid, i) <= RECLAIM_DISTANCE ||
+ !NODE_DATA(nid)->node_present_pages)
node_set(i, NODE_DATA(nid)->reclaim_nodes);
else
zone_reclaim_mode = 1;
@@ -4901,13 +4902,13 @@ void __paginginit free_area_init_node(int nid, unsigned
long *zones_size,
pgdat->node_id = nid;
pgdat->node_start_pfn = node_start_pfn;
- init_zone_allows_reclaim(nid);
#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
get_pfn_range_for_nid(nid, &start_pfn, &end_pfn);
#endif
calculate_node_totalpages(pgdat, start_pfn, end_pfn,
zones_size, zholes_size);
+ init_zone_allows_reclaim(nid);
alloc_node_mem_map(pgdat);
#ifdef CONFIG_FLAT_NODE_MEM_MAP
printk(KERN_DEBUG "free_area_init_node: node %d, pgdat %08lx,
node_mem_map %08lx\n",
I think it's safe to move init_zone_allows_reclaim, because I don't
think any allocates are occurring here that could cause us to reclaim
anyways, right? Moving it allows us to safely reference
node_present_pages.
Thanks,
Nish
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][v2] powerpc/fsl: Add/update miscellaneous missing bindings
On Thu, 2014-02-13 at 12:59 +0530, Harninder Rai wrote: > Missing bindings were found on running checkpatch.pl on bsc9132 > device tree. This patch add/update the following > > - Add bindings for L2 cache controller > - Add bindings for memory controller > - Update bindings for USB controller > > Signed-off-by: Harninder Rai > --- > Changes since base version: > Incorporated Scott's comments > - Rename l2cc.txt to l2cache.txt > - Add information about ePAPR compliance > - Add missing "cache" in compatible > - Miscellaneous minors > > .../devicetree/bindings/powerpc/fsl/l2cache.txt| 26 > > .../devicetree/bindings/powerpc/fsl/mem-ctrlr.txt | 16 > Documentation/devicetree/bindings/usb/fsl-usb.txt |2 + > 3 files changed, 44 insertions(+), 0 deletions(-) > create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt > create mode 100644 > Documentation/devicetree/bindings/powerpc/fsl/mem-ctrlr.txt > > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt > b/Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt > new file mode 100644 > index 000..79ef4a1 > --- /dev/null > +++ b/Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt > @@ -0,0 +1,26 @@ > +Freescale L2 Cache Controller > + > +L2 cache is present in Freescale's QorIQ and QorIQ Qonverge platforms. > +The cache bindings explained below are ePAPR compliant > + > +Required Properties: > + > +- compatible : Should include "fsl,chip-l2-cache-controller" and "cache" > + where chip is the processor (bsc9132, npc8572 etc.) > +- reg: Address and size of L2 cache controller registers > +- cache-size : Size of the entire L2 cache > +- interrupts : Error interrupt of L2 controller > + > +Optional Properties: > + > +- cache-line-size : Size of L2 cache lines cache-line-size is required as per ePAPR. > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mem-ctrlr.txt > b/Documentation/devicetree/bindings/powerpc/fsl/mem-ctrlr.txt > new file mode 100644 > index 000..70b42bb > --- /dev/null > +++ b/Documentation/devicetree/bindings/powerpc/fsl/mem-ctrlr.txt > @@ -0,0 +1,16 @@ > +Freescale DDR memory controller > + > +Properties: > + > +- compatible : Should include "fsl,chip-memory-controller" where > + chip is the processor (bsc9132, mpc8572 etc.) Please also cover newer device trees that use "fsl,qoriq-memory-controller" and don't have "fsl,CHIP-memory-controller" (they also use a variant with the block version, but since the block version is readable in a register I don't think it's necessary to specify that here). > diff --git a/Documentation/devicetree/bindings/usb/fsl-usb.txt > b/Documentation/devicetree/bindings/usb/fsl-usb.txt > index bd5723f..afa5809 100644 > --- a/Documentation/devicetree/bindings/usb/fsl-usb.txt > +++ b/Documentation/devicetree/bindings/usb/fsl-usb.txt > @@ -9,6 +9,8 @@ Required properties : > - compatible : Should be "fsl-usb2-mph" for multi port host USB > controllers, or "fsl-usb2-dr" for dual role USB controllers > or "fsl,mpc5121-usb2-dr" for dual role USB controllers of MPC5121 > + Wherever applicable, the IP version of the USB controller should > + also be mentioned (for eg. fsl-usb2-dr-v2.2 for bsc9132). Please terminate the previous sentence with a period. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc: RECLAIM_DISTANCE 10?
On 18.02.2014 [15:58:00 -0800], Nishanth Aravamudan wrote:
> On 18.02.2014 [15:34:05 -0800], Nishanth Aravamudan wrote:
> > Hi Michal,
> >
> > On 18.02.2014 [10:06:58 +0100], Michal Hocko wrote:
> > > Hi,
> > > I have just noticed that ppc has RECLAIM_DISTANCE reduced to 10 set by
> > > 56608209d34b (powerpc/numa: Set a smaller value for RECLAIM_DISTANCE to
> > > enable zone reclaim). The commit message suggests that the zone reclaim
> > > is desirable for all NUMA configurations.
> > >
> > > History has shown that the zone reclaim is more often harmful than
> > > helpful and leads to performance problems. The default RECLAIM_DISTANCE
> > > for generic case has been increased from 20 to 30 around 3.0
> > > (32e45ff43eaf mm: increase RECLAIM_DISTANCE to 30).
> >
> > Interesting.
> >
> > > I strongly suspect that the patch is incorrect and it should be
> > > reverted. Before I will send a revert I would like to understand what
> > > led to the patch in the first place. I do not see why would PPC use only
> > > LOCAL_DISTANCE and REMOTE_DISTANCE distances and in fact machines I have
> > > seen use different values.
> > >
> > > Anton, could you comment please?
> >
> > I'll let Anton comment here, but in looking into this issue in working
> > on CONFIG_HAVE_MEMORYLESS_NODE support, I realized that any LPAR with
> > memoryless nodes will set zone_reclaim_mode to 1. I think we want to
> > ignore memoryless nodes when we set up the reclaim mode like the
> > following? I'll send it as a proper patch if you agree?
> >
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 5de4337..4f6ff6f 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1853,8 +1853,9 @@ static void __paginginit init_zone_allows_reclaim(int
> > nid)
> > {
> > int i;
> >
> > - for_each_online_node(i)
> > - if (node_distance(nid, i) <= RECLAIM_DISTANCE)
> > + for_each_online_node(i) {
> > + if (node_distance(nid, i) <= RECLAIM_DISTANCE ||
> > + local_memory_node(nid) != nid)
> > node_set(i, NODE_DATA(nid)->reclaim_nodes);
> > else
> > zone_reclaim_mode = 1;
> >
> > Note, this won't actually do anything if CONFIG_HAVE_MEMORYLESS_NODES is
> > not set, but if it is, I think semantically it will indicate that
> > memoryless nodes *have* to reclaim remotely.
> >
> > And actually the above won't work, because the callpath is
> >
> > start_kernel -> setup_arch -> paging_init [-> free_area_init_nodes ->
> > free_area_init_node -> init_zone_allows_reclaim] which is called before
> > build_all_zonelists. This is a similar ordering problem as I'm having
> > with the MEMORYLESS_NODE support, will work on it.
>
> How about the following?
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 5de4337..1a0eced 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1854,7 +1854,8 @@ static void __paginginit init_zone_allows_reclaim(int
> nid)
> int i;
>
> for_each_online_node(i)
> - if (node_distance(nid, i) <= RECLAIM_DISTANCE)
> + if (node_distance(nid, i) <= RECLAIM_DISTANCE ||
> + !NODE_DATA(nid)->node_present_pages)
err s/nid/i/ above.
-Nish
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
