* Re: [PATCH 02/25] arch/powerpc: Use static const char arrays
From: Stephen Rothwell @ 2010-09-14 2:02 UTC (permalink / raw)
To: Joe Perches; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <a2d6296e9aabed2de77ae0b44f16b13008129e48.1284406638.git.joe@perches.com>
[-- Attachment #1: Type: text/plain, Size: 591 bytes --]
Hi Joe,
On Mon, 13 Sep 2010 12:47:40 -0700 Joe Perches <joe@perches.com> wrote:
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> arch/powerpc/boot/addnote.c | 4 ++--
> arch/powerpc/boot/cuboot-c2k.c | 4 ++--
> arch/powerpc/kernel/irq.c | 2 +-
> 3 files changed, 5 insertions(+), 5 deletions(-)
I am also unsure that the transformation to cuboot-c2k.c adds anything.
Other than that
Reviewed-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH v2] APM821xx: Add support for new SoC APM821xx
From: tmarri @ 2010-09-13 23:26 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tmarri
From: Tirumala Marri <tmarri@apm.com>
This patch adds CPU, device tree, defconfig and bluestone board
support for APM821xx SoC.
Signed-off-by: Tirumala R Marri <tmarri@apm.com>
---
V1:
* CPU name changed to 464.
* defconfig is created using "make savedefconfig".
V2:
* CPU name changed back to apm821xx for now.
* some white space problem in device tree.
---
arch/powerpc/boot/dts/bluestone.dts | 254 ++++++++++++++++++++++++++
arch/powerpc/configs/44x/bluestone_defconfig | 68 +++++++
arch/powerpc/kernel/cpu_setup_44x.S | 1 +
arch/powerpc/kernel/cputable.c | 15 ++
arch/powerpc/platforms/44x/Kconfig | 16 ++
arch/powerpc/platforms/44x/ppc44x_simple.c | 1 +
6 files changed, 355 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/bluestone.dts
create mode 100644 arch/powerpc/configs/44x/bluestone_defconfig
diff --git a/arch/powerpc/boot/dts/bluestone.dts b/arch/powerpc/boot/dts/bluestone.dts
new file mode 100644
index 0000000..9bb3d72
--- /dev/null
+++ b/arch/powerpc/boot/dts/bluestone.dts
@@ -0,0 +1,254 @@
+/*
+ * Device Tree for Bluestone (APM821xx) board.
+ *
+ * Copyright (c) 2010, Applied Micro Circuits Corporation
+ * Author: Tirumala R Marri <tmarri@apm.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "apm,bluestone";
+ compatible = "apm,bluestone";
+ dcr-parent = <&{/cpus/cpu@0}>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ model = "PowerPC,apm821xx";
+ reg = <0x00000000>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ i-cache-line-size = <32>;
+ d-cache-line-size = <32>;
+ i-cache-size = <32768>;
+ d-cache-size = <32768>;
+ dcr-controller;
+ dcr-access-method = "native";
+ next-level-cache = <&L2C0>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x00000000 0x00000000>; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0x0c0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0x0d0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0x1e 0x4 0x1f 0x4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0x0e0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0xa 0x4 0xb 0x4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC3: interrupt-controller3 {
+ compatible = "ibm,uic";
+ interrupt-controller;
+ cell-index = <3>;
+ dcr-reg = <0x0f0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0x10 0x4 0x11 0x4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ SDR0: sdr {
+ compatible = "ibm,sdr-apm821xx";
+ dcr-reg = <0x00e 0x002>;
+ };
+
+ CPR0: cpr {
+ compatible = "ibm,cpr-apm821xx";
+ dcr-reg = <0x00c 0x002>;
+ };
+
+ plb {
+ compatible = "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: sdram {
+ compatible = "ibm,sdram-apm821xx";
+ dcr-reg = <0x010 0x002>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal2";
+ descriptor-memory = "ocm";
+ dcr-reg = <0x180 0x062>;
+ num-tx-chans = <1>;
+ num-rx-chans = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-parent = <&UIC2>;
+ interrupts = < /*TXEOB*/ 0x6 0x4
+ /*RXEOB*/ 0x7 0x4
+ /*SERR*/ 0x3 0x4
+ /*TXDE*/ 0x4 0x4
+ /*RXDE*/ 0x5 0x4
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0xb0000000 0x00000004 0xb0000000 0x50000000>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc";
+ dcr-reg = <0x012 0x002>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ /* ranges property is supplied by U-Boot */
+ ranges = < 0x00000003 0x00000000 0xe0000000 0x8000000>;
+ interrupts = <0x6 0x4>;
+ interrupt-parent = <&UIC1>;
+
+ nor_flash@0,0 {
+ compatible = "amd,s29gl512n", "cfi-flash";
+ bank-width = <2>;
+ reg = <0x00000000 0x00000000 0x00400000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "kernel";
+ reg = <0x00000000 0x00180000>;
+ };
+ partition@180000 {
+ label = "env";
+ reg = <0x00180000 0x00020000>;
+ };
+ partition@1a0000 {
+ label = "u-boot";
+ reg = <0x001a0000 0x00060000>;
+ };
+ };
+ }
+
+ UART0: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0xef600300 0x00000008>;
+ virtual-reg = <0xef600300>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <0x1 0x4>;
+ };
+
+ IIC0: i2c@ef600700 {
+ compatible = "ibm,iic";
+ reg = <0xef600700 0x00000014>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0x2 0x4>;
+ };
+
+ IIC1: i2c@ef600800 {
+ compatible = "ibm,iic";
+ reg = <0xef600800 0x00000014>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0x3 0x4>;
+ };
+
+ RGMII0: emac-rgmii@ef601500 {
+ compatible = "ibm,rgmii";
+ reg = <0xef601500 0x00000008>;
+ has-mdio;
+ };
+
+ TAH0: emac-tah@ef601350 {
+ compatible = "ibm,tah";
+ reg = <0xef601350 0x00000030>;
+ };
+
+ EMAC0: ethernet@ef600c00 {
+ device_type = "network";
+ compatible = "ibm,emac4sync";
+ interrupt-parent = <&EMAC0>;
+ interrupts = <0x0 0x1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0x0 &UIC2 0x10 0x4
+ /*Wake*/ 0x1 &UIC2 0x14 0x4>;
+ reg = <0xef600c00 0x000000c4>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <9000>;
+ rx-fifo-size = <16384>;
+ tx-fifo-size = <2048>;
+ phy-mode = "rgmii";
+ phy-map = <0x00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
+ tah-device = <&TAH0>;
+ tah-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+ };
+
+ };
+};
diff --git a/arch/powerpc/configs/44x/bluestone_defconfig b/arch/powerpc/configs/44x/bluestone_defconfig
new file mode 100644
index 0000000..ac65b48
--- /dev/null
+++ b/arch/powerpc/configs/44x/bluestone_defconfig
@@ -0,0 +1,68 @@
+CONFIG_44x=y
+CONFIG_EXPERIMENTAL=y
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_EMBEDDED=y
+# CONFIG_VM_EVENT_COUNTERS is not set
+# CONFIG_PCI_QUIRKS is not set
+# CONFIG_COMPAT_BRK is not set
+CONFIG_BLUESTONE=y
+# CONFIG_EBONY is not set
+# CONFIG_KVM_GUEST is not set
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_SPARSE_IRQ=y
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE=""
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_CONNECTOR=y
+CONFIG_MTD=y
+CONFIG_MTD_PARTITIONS=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_OF_PARTS=y
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_PHYSMAP_OF=y
+CONFIG_PROC_DEVICETREE=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZE=35000
+CONFIG_NETDEVICES=y
+CONFIG_NET_ETHERNET=y
+CONFIG_IBM_NEW_EMAC=y
+CONFIG_IBM_NEW_EMAC_RXB=256
+CONFIG_IBM_NEW_EMAC_TXB=256
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=2
+CONFIG_SERIAL_8250_RUNTIME_UARTS=2
+CONFIG_SERIAL_8250_EXTENDED=y
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_IBM_IIC=y
+CONFIG_SENSORS_AD7414=y
+# CONFIG_HID_SUPPORT is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_M41T80=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT3_FS=y
+CONFIG_PROC_KCORE=y
+CONFIG_TMPFS=y
+CONFIG_CRAMFS=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS=y
diff --git a/arch/powerpc/kernel/cpu_setup_44x.S b/arch/powerpc/kernel/cpu_setup_44x.S
index 7d606f8..e32b4a9 100644
--- a/arch/powerpc/kernel/cpu_setup_44x.S
+++ b/arch/powerpc/kernel/cpu_setup_44x.S
@@ -35,6 +35,7 @@ _GLOBAL(__setup_cpu_440grx)
_GLOBAL(__setup_cpu_460ex)
_GLOBAL(__setup_cpu_460gt)
_GLOBAL(__setup_cpu_460sx)
+_GLOBAL(__setup_cpu_apm821xx)
mflr r4
bl __init_fpu_44x
bl __fixup_440A_mcheck
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 1f9123f..b7ac795 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -48,6 +48,7 @@ extern void __setup_cpu_440x5(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_460ex(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_460gt(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_460sx(unsigned long offset, struct cpu_spec *spec);
+extern void __setup_cpu_apm821xx(unsigned long offset, struct cpu_spec *spec);
extern void __setup_cpu_603(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_604(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_750(unsigned long offset, struct cpu_spec* spec);
@@ -1805,6 +1806,20 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_440A,
.platform = "ppc440",
},
+ { /* 464 in APM821xx */
+ .pvr_mask = 0xffffff00,
+ .pvr_value = 0x12C41C80,
+ .cpu_name = "APM821XX",
+ .cpu_features = CPU_FTRS_44X,
+ .cpu_user_features = COMMON_USER_BOOKE |
+ PPC_FEATURE_HAS_FPU,
+ .mmu_features = MMU_FTR_TYPE_44x,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .cpu_setup = __setup_cpu_apm821xx,
+ .machine_check = machine_check_440A,
+ .platform = "ppc440",
+ },
{ /* 476 core */
.pvr_mask = 0xffff0000,
.pvr_value = 0x11a50000,
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 69d668c..0f979c5 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -17,6 +17,16 @@ config BAMBOO
help
This option enables support for the IBM PPC440EP evaluation board.
+config BLUESTONE
+ bool "Bluestone"
+ depends on 44x
+ default n
+ select PPC44x_SIMPLE
+ select APM821xx
+ select IBM_NEW_EMAC_RGMII
+ help
+ This option enables support for the APM APM821xx Evaluation board.
+
config EBONY
bool "Ebony"
depends on 44x
@@ -293,6 +303,12 @@ config 460SX
select IBM_NEW_EMAC_ZMII
select IBM_NEW_EMAC_TAH
+config APM821xx
+ bool
+ select PPC_FPU
+ select IBM_NEW_EMAC_EMAC4
+ select IBM_NEW_EMAC_TAH
+
# 44x errata/workaround config symbols, selected by the CPU models above
config IBM440EP_ERR42
bool
diff --git a/arch/powerpc/platforms/44x/ppc44x_simple.c b/arch/powerpc/platforms/44x/ppc44x_simple.c
index 5f7a29d..7ddcba3 100644
--- a/arch/powerpc/platforms/44x/ppc44x_simple.c
+++ b/arch/powerpc/platforms/44x/ppc44x_simple.c
@@ -52,6 +52,7 @@ machine_device_initcall(ppc44x_simple, ppc44x_device_probe);
static char *board[] __initdata = {
"amcc,arches",
"amcc,bamboo",
+ "amcc,bluestone",
"amcc,canyonlands",
"amcc,glacier",
"ibm,ebony",
--
1.6.1.rc3
^ permalink raw reply related
* RE: [PATCH v1] APM821xx: Add support for new SoC APM821xx
From: Tirumala Marri @ 2010-09-13 23:01 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20100913135410.GB31548@zod.rchland.ibm.com>
> >+ clock-frequency = <0>; /* Filled in by U-Boot */
>
> Out of curiosity, which version of U-Boot has (or will have) this
> support?
[Marri] Currently I am working with u-boot list to accept my patch. It
should
be available as soon as it is accepted.
>
> >diff --git a/arch/powerpc/configs/44x/bluestone_defconfig
> b/arch/powerpc/configs/44x/bluestone_defconfig
> >new file mode 100644
> >index 0000000..ac65b48
> >--- /dev/null
> >+++ b/arch/powerpc/configs/44x/bluestone_defconfig
>
> This defconfig is much better. Thanks.
>
> >diff --git a/arch/powerpc/kernel/cpu_setup_44x.S
> b/arch/powerpc/kernel/cpu_setup_44x.S
> >index 7d606f8..549f482 100644
> >--- a/arch/powerpc/kernel/cpu_setup_44x.S
> >+++ b/arch/powerpc/kernel/cpu_setup_44x.S
> >@@ -35,6 +35,7 @@ _GLOBAL(__setup_cpu_440grx)
> > _GLOBAL(__setup_cpu_460ex)
> > _GLOBAL(__setup_cpu_460gt)
> > _GLOBAL(__setup_cpu_460sx)
> >+_GLOBAL(__setup_cpu_464)
> > mflr r4
> > bl __init_fpu_44x
> > bl __fixup_440A_mcheck
>
> This doesn't look correct. Not all 464 cores will have an FPU.
> Additionally, if this were correct then you could just replace all of
> the 460xx setup functions with a single one instead of adding one for
> 464 cores and ignoring those.
[Marri] I reverted back apm821xx in the next patch.
>
> >diff --git a/arch/powerpc/kernel/cputable.c
> b/arch/powerpc/kernel/cputable.c
> >index 1f9123f..89e55b1 100644
> >--- a/arch/powerpc/kernel/cputable.c
> >+++ b/arch/powerpc/kernel/cputable.c
> >@@ -48,6 +48,7 @@ extern void __setup_cpu_440x5(unsigned long offset,
> struct cpu_spec* spec);
> > extern void __setup_cpu_460ex(unsigned long offset, struct cpu_spec*
> spec);
> > extern void __setup_cpu_460gt(unsigned long offset, struct cpu_spec*
> spec);
> > extern void __setup_cpu_460sx(unsigned long offset, struct cpu_spec
> *spec);
> >+extern void __setup_cpu_464(unsigned long offset, struct cpu_spec
> *spec);
> > extern void __setup_cpu_603(unsigned long offset, struct cpu_spec*
> spec);
> > extern void __setup_cpu_604(unsigned long offset, struct cpu_spec*
> spec);
> > extern void __setup_cpu_750(unsigned long offset, struct cpu_spec*
> spec);
> >@@ -1805,6 +1806,20 @@ static struct cpu_spec __initdata cpu_specs[] =
> {
> > .machine_check = machine_check_440A,
> > .platform = "ppc440",
> > },
> >+ { /* 464 in APM821xx */
> >+ .pvr_mask = 0xffffff00,
> >+ .pvr_value = 0x12C41C80,
> >+ .cpu_name = "464 in APM821xx",
>
> That's a bit of an odd cpu_name. Let's just stick with the SoC name
> for
> this, as the PVR really identifies the SoC on 4xx, not the core. I'd
> suggest just creating the __setup_cpu_apm821xx function for now. We
> can
> sort out how to break out the 4xx core inside the SoC later.
[Marri]Sure will do.
^ permalink raw reply
* Re: [PATCH 11/11] sound: Remove pr_<level> uses of KERN_<level>
From: Takashi Iwai @ 2010-09-13 21:41 UTC (permalink / raw)
To: Joe Perches
Cc: cbe-oss-dev, alsa-devel, Jiri Kosina, Geoff Levand, Mark Brown,
linux-kernel, Jaroslav Kysela, linuxppc-dev, Liam Girdwood
In-Reply-To: <27a88f64b5bfec16c8abf5aca89b7a1b7533ecb9.1284267142.git.joe@perches.com>
At Sat, 11 Sep 2010 22:10:59 -0700,
Joe Perches wrote:
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied to sound git tree now. Thanks.
Takashi
> ---
> sound/ppc/snd_ps3.c | 2 +-
> sound/soc/s3c24xx/s3c-dma.c | 3 +--
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/sound/ppc/snd_ps3.c b/sound/ppc/snd_ps3.c
> index 2f12da4..581a670 100644
> --- a/sound/ppc/snd_ps3.c
> +++ b/sound/ppc/snd_ps3.c
> @@ -579,7 +579,7 @@ static int snd_ps3_delay_to_bytes(struct snd_pcm_substream *substream,
> rate * delay_ms / 1000)
> * substream->runtime->channels;
>
> - pr_debug(KERN_ERR "%s: time=%d rate=%d bytes=%ld, frames=%d, ret=%d\n",
> + pr_debug("%s: time=%d rate=%d bytes=%ld, frames=%d, ret=%d\n",
> __func__,
> delay_ms,
> rate,
> diff --git a/sound/soc/s3c24xx/s3c-dma.c b/sound/soc/s3c24xx/s3c-dma.c
> index 1b61c23..f1b1bc4 100644
> --- a/sound/soc/s3c24xx/s3c-dma.c
> +++ b/sound/soc/s3c24xx/s3c-dma.c
> @@ -94,8 +94,7 @@ static void s3c_dma_enqueue(struct snd_pcm_substream *substream)
>
> if ((pos + len) > prtd->dma_end) {
> len = prtd->dma_end - pos;
> - pr_debug(KERN_DEBUG "%s: corrected dma len %ld\n",
> - __func__, len);
> + pr_debug("%s: corrected dma len %ld\n", __func__, len);
> }
>
> ret = s3c2410_dma_enqueue(prtd->params->channel,
> --
> 1.7.3.rc1
>
^ permalink raw reply
* Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Scott Wood @ 2010-09-13 20:04 UTC (permalink / raw)
To: Timur Tabi
Cc: Wood Scott-B07421, dedekind1, Zang Roy-R61911, Lan Chunhe-B25806,
linuxppc-dev, linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <AANLkTimUR5-hWRkDAwWTXJYCOcse7LTR0r-vSsZec1g1@mail.gmail.com>
On Mon, 13 Sep 2010 13:36:45 -0500
Timur Tabi <timur.tabi@gmail.com> wrote:
> On Mon, Sep 13, 2010 at 11:45 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> > Unsigned int is reliably >= 4 in Linux.
>
> Not exactly. sizeof(unsigned int) is effectively never greater than 4
> in Linux (I think it's still 32 bits even on a 64-bit kernel), so it
> makes no sense to say >=.
I think the point is that if a machine/ABI comes along with
sizeof(int) > 4 (e.g. if there's a significant penalty for working
with anything < 64-bit), Linux might consider supporting that. Whereas
if someone points to their microcontroller or ancient 286 with
sizeof(int) == 2, the answer would be, "Here's a nickel, kid -- get a
real computer".
-Scott
^ permalink raw reply
* [PATCH 04/25] drivers/char: Use static const char arrays
From: Joe Perches @ 2010-09-13 19:47 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev
In-Reply-To: <cover.1284406638.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/char/hvc_vio.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/char/hvc_vio.c b/drivers/char/hvc_vio.c
index 27370e9..5e2f52b 100644
--- a/drivers/char/hvc_vio.c
+++ b/drivers/char/hvc_vio.c
@@ -39,7 +39,7 @@
#include "hvc_console.h"
-char hvc_driver_name[] = "hvc_console";
+static const char hvc_driver_name[] = "hvc_console";
static struct vio_device_id hvc_driver_table[] __devinitdata = {
{"serial", "hvterm1"},
--
1.7.3.rc1
^ permalink raw reply related
* [PATCH 00/25] treewide-next: Use static const char arrays
From: Joe Perches @ 2010-09-13 19:47 UTC (permalink / raw)
To: linux-kernel
Cc: Amit Kumar Salecha, linux-fbdev, Greg Kroah-Hartman, James Smart,
linux-mips, VMware, Inc., PJ Waskiewicz, Shreyas Bhatewara,
alsa-devel, Jaroslav Kysela, J. Bruce Fields,
James E.J. Bottomley, Paul Mackerras, linux-i2c, Brett Rudley,
sparclinux, Martin Schwidefsky, devel, linux-s390, linux-acpi,
linux-scsi, Florian Tobias Schandinat, e1000-devel,
Trond Myklebust, Jesse Brandeburg, Neil Brown, Jeff Kirsher,
linux-wireless, Ingo Molnar, linux-usb, Len Brown, Alex Duyck,
Peter Zijlstra, Henry Ptasinski, Heiko Carstens,
Thomas Winischhofer, Mauro Carvalho Chehab,
Arnaldo Carvalho de Melo, Jean Delvare (PC drivers, core),
mjpeg-users, Ben Dooks (embedded platforms), linux-nfs,
linux-arm-kernel, Neela Syam Kolli, Karsten Keil, Linus Walleij,
netdev, Anirban Chakraborty, Bruce Allan, Nohee Ko, Ralf Baechle,
Joseph Chan, John Ronciak, Takashi Iwai, linux-driver, linux390,
linux-media, linuxppc-dev, David S. Miller
Using static const char foo[] = "bar" can save some
code and text space, so change the places where it's possible.
Also change the places that use
char foo[] = "barX";
...
foo[3] = value + '0';
where X is typically changed
char foo[sizeof("barX")];
...
sprintf(foo, "bar%c", value + '0');
Joe Perches (25):
arch/mips: Use static const char arrays
arch/powerpc: Use static const char arrays
drivers/acpi: Use static const char arrays
drivers/char: Use static const char arrays
drivers/i2c: Use static const char arrays
drivers/isdn: Use static const char arrays
drivers/media: Use static const char arrays
drivers/net/atl1c: Use static const char arrays
drivers/net/atl1e: Use static const char arrays
drivers/net/(intel): Use static const char arrays
drivers/net/netxen: Use static const char arrays
drivers/net/qlcnic: Use static const char arrays
drivers/net/spider_net.c: Use static const char arrays
drivers/net/vnxnet3: Use static const char arrays
drivers/net/wireless/ipw2x00: Use static const char arrays
drivers/s390/char: Use static const char arrays
drivers/scsi: Use static const char arrays
drivers/serial/suncore.c: Use static const char arrays
drivers/staging: Use static const char arrays
drivers/usb: Use static const char arrays
drivers/video: Use static const char arrays
net/dsa: Use static const char arrays
net/sunrpc: Use static const char arrays
sound: Use static const char arrays
tools/perf/util: Use static const char arrays
arch/mips/pnx8550/common/reset.c | 4 ++--
arch/powerpc/boot/addnote.c | 4 ++--
arch/powerpc/boot/cuboot-c2k.c | 4 ++--
arch/powerpc/kernel/irq.c | 2 +-
drivers/acpi/sleep.c | 4 ++--
drivers/char/hvc_vio.c | 2 +-
drivers/i2c/busses/i2c-stu300.c | 4 ++--
drivers/isdn/hysdn/hycapi.c | 2 +-
drivers/isdn/mISDN/dsp_cmx.c | 2 +-
drivers/media/video/zoran/zoran_device.c | 5 ++---
drivers/net/atl1c/atl1c.h | 4 ++--
drivers/net/atl1c/atl1c_main.c | 4 ++--
drivers/net/atl1e/atl1e.h | 4 ++--
drivers/net/atl1e/atl1e_main.c | 4 ++--
drivers/net/e1000/e1000.h | 2 +-
drivers/net/e1000/e1000_main.c | 4 ++--
drivers/net/e1000e/e1000.h | 2 +-
drivers/net/e1000e/netdev.c | 2 +-
drivers/net/igb/igb.h | 4 ++--
drivers/net/igb/igb_main.c | 4 ++--
drivers/net/igbvf/igbvf.h | 2 +-
drivers/net/igbvf/netdev.c | 2 +-
drivers/net/ixgb/ixgb.h | 2 +-
drivers/net/ixgb/ixgb_main.c | 2 +-
drivers/net/ixgbe/ixgbe.h | 2 +-
drivers/net/ixgbe/ixgbe_main.c | 4 ++--
drivers/net/ixgbevf/ixgbevf.h | 2 +-
drivers/net/ixgbevf/ixgbevf_main.c | 2 +-
drivers/net/netxen/netxen_nic.h | 2 +-
drivers/net/netxen/netxen_nic_main.c | 2 +-
drivers/net/qlcnic/qlcnic.h | 2 +-
drivers/net/qlcnic/qlcnic_main.c | 2 +-
drivers/net/spider_net.c | 2 +-
drivers/net/vmxnet3/vmxnet3_drv.c | 2 +-
drivers/net/vmxnet3/vmxnet3_int.h | 2 +-
drivers/net/wireless/ipw2x00/ipw2100.c | 2 +-
drivers/net/wireless/ipw2x00/ipw2200.c | 2 +-
drivers/net/wireless/ipw2x00/libipw_module.c | 2 +-
drivers/s390/char/vmlogrdr.c | 4 ++--
drivers/scsi/bnx2i/bnx2i_hwi.c | 6 +++---
drivers/scsi/lpfc/lpfc_init.c | 2 +-
drivers/scsi/megaraid/megaraid_mbox.c | 6 +++---
drivers/serial/suncore.c | 4 ++--
drivers/staging/brcm80211/util/bcmutils.c | 2 +-
drivers/staging/comedi/drivers/comedi_bond.c | 2 +-
drivers/staging/cxt1e1/ossiRelease.c | 2 +-
drivers/staging/go7007/go7007-driver.c | 2 +-
drivers/staging/msm/mdp.c | 2 +-
.../staging/rtl8192e/ieee80211/ieee80211_module.c | 2 +-
.../staging/rtl8192u/ieee80211/ieee80211_module.c | 2 +-
drivers/staging/tidspbridge/rmgr/dbdcd.c | 6 +++---
drivers/usb/atm/ueagle-atm.c | 14 +++++---------
drivers/usb/otg/langwell_otg.c | 2 +-
drivers/video/sh_mipi_dsi.c | 4 ++--
drivers/video/sis/sis_main.c | 10 +++++-----
drivers/video/via/viafbdev.c | 2 +-
net/dsa/dsa.c | 2 +-
net/dsa/dsa_priv.h | 2 +-
net/sunrpc/auth_gss/gss_krb5_mech.c | 2 +-
sound/core/misc.c | 5 ++++-
tools/perf/util/ui/setup.c | 3 ++-
tools/perf/util/ui/util.c | 3 ++-
62 files changed, 98 insertions(+), 98 deletions(-)
--
1.7.3.rc1
^ permalink raw reply
* [PATCH 02/25] arch/powerpc: Use static const char arrays
From: Joe Perches @ 2010-09-13 19:47 UTC (permalink / raw)
To: linux-kernel; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <cover.1284406638.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
arch/powerpc/boot/addnote.c | 4 ++--
arch/powerpc/boot/cuboot-c2k.c | 4 ++--
arch/powerpc/kernel/irq.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/addnote.c b/arch/powerpc/boot/addnote.c
index b1e5611..349b553 100644
--- a/arch/powerpc/boot/addnote.c
+++ b/arch/powerpc/boot/addnote.c
@@ -20,7 +20,7 @@
#include <string.h>
/* CHRP note section */
-char arch[] = "PowerPC";
+static const char arch[] = "PowerPC";
#define N_DESCR 6
unsigned int descr[N_DESCR] = {
@@ -33,7 +33,7 @@ unsigned int descr[N_DESCR] = {
};
/* RPA note section */
-char rpaname[] = "IBM,RPA-Client-Config";
+static const char rpaname[] = "IBM,RPA-Client-Config";
/*
* Note: setting ignore_my_client_config *should* mean that OF ignores
diff --git a/arch/powerpc/boot/cuboot-c2k.c b/arch/powerpc/boot/cuboot-c2k.c
index e435949..030d7db 100644
--- a/arch/powerpc/boot/cuboot-c2k.c
+++ b/arch/powerpc/boot/cuboot-c2k.c
@@ -62,9 +62,9 @@ static void c2k_bridge_setup(u32 mem_size)
/* Get the cpu -> pci i/o & mem mappings from the device tree */
devp = NULL;
for (bus = 0; ; bus++) {
- char name[] = "pci ";
+ char name[sizeof("pciX")];
- name[strlen(name)-1] = bus+'0';
+ sprintf(name, "pci%c", bus + '0');
devp = find_node_by_alias(name);
if (devp == NULL)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 4a65386..47fbc56 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -1143,7 +1143,7 @@ static int virq_debug_show(struct seq_file *m, void *private)
unsigned long flags;
struct irq_desc *desc;
const char *p;
- char none[] = "none";
+ static const char none[] = "none";
int i;
seq_printf(m, "%-5s %-7s %-15s %s\n", "virq", "hwirq",
--
1.7.3.rc1
^ permalink raw reply related
* Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Artem Bityutskiy @ 2010-09-13 18:46 UTC (permalink / raw)
To: Timur Tabi
Cc: Wood Scott-B07421, Zang Roy-R61911, Lan Chunhe-B25806,
linuxppc-dev, linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <AANLkTimUR5-hWRkDAwWTXJYCOcse7LTR0r-vSsZec1g1@mail.gmail.com>
On Mon, 2010-09-13 at 13:36 -0500, Timur Tabi wrote:
> On Mon, Sep 13, 2010 at 11:45 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> > Unsigned int is reliably >= 4 in Linux.
>
> Not exactly. sizeof(unsigned int) is effectively never greater than 4
> in Linux
I know and said the same in the other paragraph which you cut.
> (I think it's still 32 bits even on a 64-bit kernel)
Yes.
> , so it
> makes no sense to say >=. So since you can't say that sizeof(int) ==
> 4, and you can't say that sizeof(int) > 4, then you certainly can't
> say that sizeof(int) >= 4.
It also makes no sense to send "makes no sense" answer 2 times in a row
and it makes no sense to not read and not try to understand the e-mail
you are replying (even though the english of the writer is not perfect)
So it makes no sense to continue arguing.
But it makes some sense to go sleep, good night.
--
Best Regards,
Artem Bityutskiy (Битюцкий Артём)
^ permalink raw reply
* Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Timur Tabi @ 2010-09-13 18:36 UTC (permalink / raw)
To: dedekind1
Cc: Wood Scott-B07421, Zang Roy-R61911, Lan Chunhe-B25806,
linuxppc-dev, linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <1284396320.1783.30.camel@brekeke>
On Mon, Sep 13, 2010 at 11:45 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> Unsigned int is reliably >= 4 in Linux.
Not exactly. sizeof(unsigned int) is effectively never greater than 4
in Linux (I think it's still 32 bits even on a 64-bit kernel), so it
makes no sense to say >=. So since you can't say that sizeof(int) ==
4, and you can't say that sizeof(int) > 4, then you certainly can't
say that sizeof(int) >= 4.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 11/11] sound: Remove pr_<level> uses of KERN_<level>
From: Geoff Levand @ 2010-09-13 17:55 UTC (permalink / raw)
To: Joe Perches
Cc: cbe-oss-dev, alsa-devel, Jiri Kosina, Takashi Iwai, Mark Brown,
linux-kernel, Jaroslav Kysela, linuxppc-dev, Liam Girdwood
In-Reply-To: <27a88f64b5bfec16c8abf5aca89b7a1b7533ecb9.1284267142.git.joe@perches.com>
[-- Attachment #1: Type: text/plain, Size: 662 bytes --]
Hi Joe,
On 09/11/2010 10:10 PM, Joe Perches wrote:
> sound/ppc/snd_ps3.c | 2 +-
>
> diff --git a/sound/ppc/snd_ps3.c b/sound/ppc/snd_ps3.c
> index 2f12da4..581a670 100644
> --- a/sound/ppc/snd_ps3.c
> +++ b/sound/ppc/snd_ps3.c
> @@ -579,7 +579,7 @@ static int snd_ps3_delay_to_bytes(struct snd_pcm_substream *substream,
> rate * delay_ms / 1000)
> * substream->runtime->channels;
>
> - pr_debug(KERN_ERR "%s: time=%d rate=%d bytes=%ld, frames=%d, ret=%d\n",
> + pr_debug("%s: time=%d rate=%d bytes=%ld, frames=%d, ret=%d\n",
> __func__,
> delay_ms,
> rate,
snd_ps3.c looks OK.
Acked-by: Geoff Levand <geoff@infradead.org>
[-- Attachment #2: 0x2E141B16.asc --]
[-- Type: application/pgp-keys, Size: 9418 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Artem Bityutskiy @ 2010-09-13 16:45 UTC (permalink / raw)
To: Timur Tabi
Cc: Wood Scott-B07421, Zang Roy-R61911, Lan Chunhe-B25806,
linuxppc-dev, linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <AANLkTinyELs7KNDQxWsaR8Ea13SewWYwgtnie_P7cAzC@mail.gmail.com>
On Mon, 2010-09-13 at 09:35 -0500, Timur Tabi wrote:
> On Mon, Sep 13, 2010 at 9:27 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
>
> > Yes, sizeof(int) == 4 assumption is not good.
> >
> > But sizeof(int) >= 4 is perfectly fine.
>
> I have to disagree. I don't see how you can say that == is not okay,
> but >= is okay.
If I assume that int == 4, which is true for all platform ATM, and will
most probably stay true for very long time, I still make an unnecessary
assumption which C99 does not guarantee. This is just not very clean. So
for things which require exactly 32 bits, u32 or C99 uint32_t should be
used.
On the other hand, if a have a local variable "var" which needs to store
values which I know will always fit 32 bits, and I do not use it in
operations (I/O, etc) which require exactly 32 bits, it is better to use
unsigned int for it. Unsigned int is reliably >= 4 in Linux.
This is wat I meant that sizeof(int) >= 4 is perfectly fine. One
everywhere, of course, but in many cases.
To put it differently, if there is no special reason to limit the
variable by exactly 32 bits, it is better to use int.
--
Best Regards,
Artem Bityutskiy (Битюцкий Артём)
^ permalink raw reply
* Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Scott Wood @ 2010-09-13 16:27 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, Geert Uytterhoeven, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <3850A844E6A3854C827AC5C0BEC7B60A1FC150@zch01exm23.fsl.freescale.net>
On Mon, 13 Sep 2010 00:22:10 -0700
"Zang Roy-R61911" <r61911@freescale.com> wrote:
>=20
>=20
> > -----Original Message-----
> > From: geert.uytterhoeven@gmail.com [mailto:geert.uytterhoeven@gmail.com=
] On
> > Behalf Of Geert Uytterhoeven
> > Sent: Thursday, September 09, 2010 19:06 PM
> > To: Zang Roy-R61911
> > Cc: linux-mtd@lists.infradead.org; Wood Scott-B07421; dedekind1@gmail.c=
om; Lan
> > Chunhe-B25806; linuxppc-dev@ozlabs.org; akpm@linux-foundation.org;
> > dwmw2@infradead.org; Gala Kumar-B11780
> > Subject: Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue=
with
> > 36bit mode
> >=20
> > On Thu, Sep 9, 2010 at 12:20, Roy Zang <tie-fei.zang@freescale.com> wro=
te:
> > > From: Lan Chunhe-B25806 <b25806@freescale.com>
> > >
> > > When system uses 36bit physical address, res.start is 36bit
> > > physical address. But the function of in_be32 returns 32bit
> > > physical address. Then both of them compared each other is
> > > wrong. So by converting the address of res.start into
> > > the right format fixes this issue.
> >=20
> > > =A0/**
> > > + * fsl_lbc_addr - convert the base address
> > > + * @addr_base: base address of the memory bank
> > > + *
> > > + * This function converts a base address of lbc into the right forma=
t for
> > the BR
> > > + * registers. If the SOC has eLBC then it returns 32bit physical add=
ress
> > else
> > > + * it returns 34bit physical address for local bus(Example: MPC8641).
> > > + */
> > > +unsigned int fsl_lbc_addr(phys_addr_t addr_base)
> > ^^^^^^^^^^^^
> > Shouldn't this be u32 or __be32, for consistency with the actual
> > comparisons below?
> __be32 is better.
I disagree, the return from this function is native-endian. It should
be u32.
-Scott
^ permalink raw reply
* Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Timur Tabi @ 2010-09-13 14:35 UTC (permalink / raw)
To: dedekind1
Cc: Wood Scott-B07421, Zang Roy-R61911, Lan Chunhe-B25806,
linuxppc-dev, linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <1284388075.10955.51.camel@localhost>
On Mon, Sep 13, 2010 at 9:27 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> Yes, sizeof(int) == 4 assumption is not good.
>
> But sizeof(int) >= 4 is perfectly fine.
I have to disagree. I don't see how you can say that == is not okay,
but >= is okay. That just doesn't make any sense. Obviously, you
have to make some assumptions about sizeof(int), but that assumption
should be nothing more than "it should be big enough for these small
numbers that I'm using".
> I see people use u32 and the friends too much.
I agree with that.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Artem Bityutskiy @ 2010-09-13 14:27 UTC (permalink / raw)
To: Timur Tabi
Cc: Wood Scott-B07421, Zang Roy-R61911, Lan Chunhe-B25806,
linuxppc-dev, linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <AANLkTimfKwdw+nLAjDjxf52dbZKLF-3aES+bT7CHskAS@mail.gmail.com>
On Mon, 2010-09-13 at 09:10 -0500, Timur Tabi wrote:
> On Mon, Sep 13, 2010 at 2:30 AM, Zang Roy-R61911 <r61911@freescale.com> wrote:
>
> > What is the different for unsigned int and u32? I think they are same.
>
> Roy, please don't ever write code that assumes that sizeof(int) == 4.
> There's a reason why we have unsized integer types (like int, long,
> and short) and sized integer types (like u8, u16, u32). If you want
> an integer of a specific size, you should use a sized integer type.
Yes, sizeof(int) == 4 assumption is not good.
But sizeof(int) >= 4 is perfectly fine.
It is OK to rely on the fact that unsigned int is _at least_ 32-bit, not
less. And if you know 32 bits is enough, and you are fine with more, it
is _better_ to avoid u32. Simply because with unsigned int you do not
limit the compiler and CPU and let them use native integers, rather than
strictly 32-bit. This potentially gives the compiler and CPU more room
for optimization.
I see people use u32 and the friends too much. It is safe and better to
use native types, unless you really have to make the variable to be
strictly u32.
I did not follow this particular conversation and do not judge which
type is better in this case. I am talking in general. :-)
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply
* Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Timur Tabi @ 2010-09-13 14:10 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <3850A844E6A3854C827AC5C0BEC7B60A1FC158@zch01exm23.fsl.freescale.net>
On Mon, Sep 13, 2010 at 2:30 AM, Zang Roy-R61911 <r61911@freescale.com> wrote:
> What is the different for unsigned int and u32? I think they are same.
Roy, please don't ever write code that assumes that sizeof(int) == 4.
There's a reason why we have unsized integer types (like int, long,
and short) and sized integer types (like u8, u16, u32). If you want
an integer of a specific size, you should use a sized integer type.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v1] APM821xx: Add support for new SoC APM821xx
From: Josh Boyer @ 2010-09-13 13:54 UTC (permalink / raw)
To: tmarri; +Cc: linuxppc-dev
In-Reply-To: <1284143257-15993-1-git-send-email-tmarri@apm.com>
On Fri, Sep 10, 2010 at 11:27:37AM -0700, tmarri@apm.com wrote:
>From: Tirumala Marri <tmarri@apm.com>
>
>This patch adds CPU, device tree, defconfig and bluestone board
>support for APM821xx SoC.
>
>Signed-off-by: Tirumala R Marri <tmarri@apm.com>
>+ cpus {
>+ #address-cells = <1>;
>+ #size-cells = <0>;
>+
>+ cpu@0 {
>+ device_type = "cpu";
>+ model = "PowerPC,464";
Let's just keep this as it was in your first patch for now. See why in
later comments. (Also, the whitespace is odd here anyway.)
>+ reg = <0x00000000>;
>+ clock-frequency = <0>; /* Filled in by U-Boot */
Out of curiosity, which version of U-Boot has (or will have) this support?
>diff --git a/arch/powerpc/configs/44x/bluestone_defconfig b/arch/powerpc/configs/44x/bluestone_defconfig
>new file mode 100644
>index 0000000..ac65b48
>--- /dev/null
>+++ b/arch/powerpc/configs/44x/bluestone_defconfig
This defconfig is much better. Thanks.
>diff --git a/arch/powerpc/kernel/cpu_setup_44x.S b/arch/powerpc/kernel/cpu_setup_44x.S
>index 7d606f8..549f482 100644
>--- a/arch/powerpc/kernel/cpu_setup_44x.S
>+++ b/arch/powerpc/kernel/cpu_setup_44x.S
>@@ -35,6 +35,7 @@ _GLOBAL(__setup_cpu_440grx)
> _GLOBAL(__setup_cpu_460ex)
> _GLOBAL(__setup_cpu_460gt)
> _GLOBAL(__setup_cpu_460sx)
>+_GLOBAL(__setup_cpu_464)
> mflr r4
> bl __init_fpu_44x
> bl __fixup_440A_mcheck
This doesn't look correct. Not all 464 cores will have an FPU.
Additionally, if this were correct then you could just replace all of
the 460xx setup functions with a single one instead of adding one for
464 cores and ignoring those.
>diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
>index 1f9123f..89e55b1 100644
>--- a/arch/powerpc/kernel/cputable.c
>+++ b/arch/powerpc/kernel/cputable.c
>@@ -48,6 +48,7 @@ extern void __setup_cpu_440x5(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_460ex(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_460gt(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_460sx(unsigned long offset, struct cpu_spec *spec);
>+extern void __setup_cpu_464(unsigned long offset, struct cpu_spec *spec);
> extern void __setup_cpu_603(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_604(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_750(unsigned long offset, struct cpu_spec* spec);
>@@ -1805,6 +1806,20 @@ static struct cpu_spec __initdata cpu_specs[] = {
> .machine_check = machine_check_440A,
> .platform = "ppc440",
> },
>+ { /* 464 in APM821xx */
>+ .pvr_mask = 0xffffff00,
>+ .pvr_value = 0x12C41C80,
>+ .cpu_name = "464 in APM821xx",
That's a bit of an odd cpu_name. Let's just stick with the SoC name for
this, as the PVR really identifies the SoC on 4xx, not the core. I'd
suggest just creating the __setup_cpu_apm821xx function for now. We can
sort out how to break out the 4xx core inside the SoC later.
josh
^ permalink raw reply
* Re: [PATCH] APM821xx: Add support for new SoC APM821xx
From: Josh Boyer @ 2010-09-13 13:44 UTC (permalink / raw)
To: Olof Johansson; +Cc: Tirumala Marri, linuxppc-dev
In-Reply-To: <20100906154526.GA515@lixom.net>
On Mon, Sep 06, 2010 at 10:45:26AM -0500, Olof Johansson wrote:
>On Sun, Sep 05, 2010 at 10:19:53PM -0700, Tirumala Marri wrote:
>> >
>> > Then the device tree identifier, and the cpu setup functions, etc,
>> > should indicate
>> > 464, not APM821xx.
>> This is new SoC based on 464 cpu core. All the previous SoC device tree
>> CPU portion uses SoC name.
>
>Hm, you're right. Confusing.
>
>Still, the cpu setup functions would make more sense to have the core
>name in, not the SoC name. Especially since multiple SoC families might
>use the same core, etc.
In theory. In practice, it just makes it a damn mess. I'd rather leave
it as-is until we can get a good split-out of the core variants and what
their setup functions might require. Starting with just this SoC and not
fixing everything else is going to be confusing and probably wrong.
josh
^ permalink raw reply
* Re: [PATCH] char: hvc: check for error case
From: Vasiliy Kulikov @ 2010-09-13 13:32 UTC (permalink / raw)
To: Chris Metcalf
Cc: Arnd Bergmann, kernel-janitors, linux-kernel, FUJITA Tomonori,
Paul Mundt, linuxppc-dev
In-Reply-To: <4C8E2355.60807@tilera.com>
On Mon, Sep 13, 2010 at 09:12 -0400, Chris Metcalf wrote:
> Thanks, accepted into my tree (for the next merge window). In practice all
> this means is in debug mode we'll get a warning from do_one_initcall()
> rather than silence, but you're right, it's technically better. :-)
Anyway it's better, if user sees warning in the dmesg, he/she might
response to this situation.
Best,
--
Vasiliy
^ permalink raw reply
* Re: [PATCH] char: hvc: check for error case
From: Chris Metcalf @ 2010-09-13 13:12 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: Arnd Bergmann, kernel-janitors, linux-kernel, FUJITA Tomonori,
Paul Mundt, linuxppc-dev
In-Reply-To: <1284317835-5086-1-git-send-email-segooon@gmail.com>
On 9/12/2010 2:57 PM, Vasiliy Kulikov wrote:
> hvc_alloc() may fail, if so exit from init() with error.
>
> Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
Thanks, accepted into my tree (for the next merge window). In practice all
this means is in debug mode we'll get a warning from do_one_initcall()
rather than silence, but you're right, it's technically better. :-)
> ---
> I cannot compile this driver at all, so it is not tested.
>
> drivers/char/hvc_tile.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/char/hvc_tile.c b/drivers/char/hvc_tile.c
> index c4efb55..7a84a05 100644
> --- a/drivers/char/hvc_tile.c
> +++ b/drivers/char/hvc_tile.c
> @@ -61,7 +61,8 @@ console_initcall(hvc_tile_console_init);
>
> static int __init hvc_tile_init(void)
> {
> - hvc_alloc(0, 0, &hvc_tile_get_put_ops, 128);
> - return 0;
> + struct hvc_struct *s;
> + s = hvc_alloc(0, 0, &hvc_tile_get_put_ops, 128);
> + return IS_ERR(s) ? PTR_ERR(s) : 0;
> }
> device_initcall(hvc_tile_init);
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Re: pci_request_regions() failure
From: Ravi Gupta @ 2010-09-13 9:04 UTC (permalink / raw)
To: tiejun.chen; +Cc: linuxppc-dev
In-Reply-To: <4C89C0C9.6090007@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 18210 bytes --]
Hi Tiejun,
Firstly I think we'd better print the BAR0 and BAR1 on the probe function of
> your device driver because you have to make sure if a8000000-a803ffff is
> assigned to BAR0 and 0xa8040000-0xa807ffff for BAR1 as we expect.
>
> u32 value;
> pci_read_config_word(pdev, PCI_BASE_ADDRESS_0, &value); printk...
> pci_read_config_word(pdev, PCI_BASE_ADDRESS_1, &value); printk....
>
>
Both the BAR's values are coming out to be zero.
> And you can print this pci_resource_start(pdev, bar),
> pci_resource_len(pdev,
> bar) from the function, __pci_request_region, on the file
> drivers/pci/pci.c.
> Please check this as well.
>
I have done the changes in the __pci_request_region. But as you suggested
earlier that one should call pci_request_regions() after pci_enable_device()
in the driver code. My driver is failing at the pci_enable_device() only.
Hence __pci_request_region() is not getting called. If, just for RND, I call
pci_request_regions() before pci_enable_device(), it give me the following
O/P.
__pci_request_region : Base Address = 0
__pci_request_region : Length Address = 1125903130362788
__pci_request_region : Base Address = 0
__pci_request_region : Length Address = 1125903130362788
> And currently we have to debug this so on the function,
> __pci_assign_resource,
> from the file drivers/pci/setup-res.c, we can force skipping temporarily
> pci_bus_alloc_resource for bus 0001:01 since that will call
> pci_update_resource
> for bus 0001:01.
>
> static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev,
> int resno)
> {
> struct resource *res = dev->resource + resno;
> resource_size_t size, min, align;
> int ret;
>
> size = resource_size(res);
> min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO :
> PCIBIOS_MIN_MEM;
> align = pci_resource_alignment(dev, res);
> -------
> if (bus->number == 0x01) {
> ret = -ENOMEM
> return ret;
> }
> -------
>
> I means we don't want to assign resource as the below line on the log.
> ------
> pci 0001:01:00.0: BAR 8: assigned [mem 0xa8000000-0xa80fffff]
>
> I expect the following output:
> ------
> pci 0001:01:00.0: BAR 8: can't assign mem pref (size 0x100000)
>
>
This I have done successfully.
Dmesg
================================================================
Using MPC837x RDB/WLAN machine description
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.35 (okapi@okapi) (gcc version 4.2.3 (Sourcery G++ Lite
4.2-171)) #35 Mon Sep 13 13:43:01 IST 2010
Found initrd at 0xcf46d000:0xcf7b15b7
Found legacy serial port 0 for /immr@e0000000/serial@4500
mem=e0004500, taddr=e0004500, irq=0, clk=400000002, speed=0
Found legacy serial port 1 for /immr@e0000000/serial@4600
mem=e0004600, taddr=e0004600, irq=0, clk=400000002, speed=0
bootconsole [udbg0] enabled
Found FSL PCI host bridge at 0x00000000e0008500. Firmware bus number: 0->0
PCI host bridge /pci@e0008500 (primary) ranges:
MEM 0x0000000090000000..0x000000009fffffff -> 0x0000000090000000
MEM 0x0000000080000000..0x000000008fffffff -> 0x0000000080000000 Prefetch
IO 0x00000000e0300000..0x00000000e03fffff -> 0x0000000000000000
No pci config register base in dev tree, using default
Found FSL PCI host bridge at 0x00000000e0009000. Firmware bus number: 0->255
PCI host bridge /pcie@e0009000 ranges:
MEM 0x00000000a8000000..0x00000000b7ffffff -> 0x00000000a8000000
IO 0x00000000b8000000..0x00000000b87fffff -> 0x0000000000000000
No pci config register base in dev tree, using default
Found FSL PCI host bridge at 0x00000000e000a000. Firmware bus number: 0->255
PCI host bridge /pcie@e000a000 ranges:
MEM 0x00000000c8000000..0x00000000d7ffffff -> 0x00000000c8000000
IO 0x00000000d8000000..0x00000000d87fffff -> 0x0000000000000000
Top of RAM: 0x10000000, Total RAM: 0x10000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0x00000000 -> 0x00010000
Normal empty
HighMem empty
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00010000
On node 0 totalpages: 65536
free_area_init_node: node 0, pgdat c042d978, node_mem_map c0800000
DMA zone: 512 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 65024 pages, LIFO batch:15
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: root=/dev/ram ramdisk_size=120000 rw ip=10.20.50.230:10
.20.50.70:10.20.50.50:255.255.0.0:PowerQUICC:eth0:off console=ttyS0,115200
mtdparts=nand:4m(kernel),-(jffs2)
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
High memory: 0k
Memory: 249920k/262144k available (4092k kernel code, 12224k reserved, 248k
data, 2207k bss, 192k init)
Kernel virtual memory layout:
* 0xfffcf000..0xfffff000 : fixmap
* 0xff800000..0xffc00000 : highmem PTEs
* 0xfe6f7000..0xff800000 : early ioremap
* 0xd1000000..0xfe6f7000 : vmalloc & ioremap
Hierarchical RCU implementation.
RCU-based detection of stalled CPUs is disabled.
Verbose stalled-CPUs detection is disabled.
NR_IRQS:512
IPIC (128 IRQ sources) at d1000700
time_init: decrementer frequency = 100.000000 MHz
time_init: processor frequency = 800.000004 MHz
clocksource: timebase mult[2800000] shift[22] registered
clockevent: decrementer mult[19999999] shift[32] cpu[0]
Console: colour dummy device 80x25
pid_max: default: 32768 minimum: 301
Security Framework initialized
SELinux: Disabled at boot.
Mount-cache hash table entries: 512
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys devices
NET: Registered protocol family 16
irq: irq 38 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 38
__irq_set_trigger: setting type, irq = 38, flags = 8
ipic_set_irq_type function, with virq = 38, flow = 8
irq: irq 74 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 74
__irq_set_trigger: setting type, irq = 74, flags = 8
ipic_set_irq_type function, with virq = 74, flow = 8
irq: irq 75 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 75
__irq_set_trigger: setting type, irq = 75, flags = 8
ipic_set_irq_type function, with virq = 75, flow = 8
PCI: Probing PCI hardware
PCI: Scanning PHB /pci@e0008500
PCI: PHB IO resource = 0000000000000000-00000000000fffff [100]
PCI: PHB MEM resource 0 = 0000000090000000-000000009fffffff [200]
PCI: PHB MEM resource 1 = 0000000080000000-000000008fffffff [2200]
PCI: PHB MEM offset = 0000000000000000
PCI: PHB IO offset = 00000000
probe mode: 0
pci_bus 0000:00: scanning bus
pci : vendor id = 0x1957
pci 0000:00:00.0: found [1957:00c6] class 000b20 header type 00
pci 0000:00:00.0: reg 10: [mem 0x00000000-0x000fffff]
pci 0000:00:00.0: reg 18: [mem 0x00000000-0x0fffffff 64bit pref]
pci 0000:00:00.0: calling fixup_hide_host_resource_fsl+0x0/0x58
pci 0000:00:00.0: calling pcibios_fixup_resources+0x0/0x180
pci 0000:00:00.0: calling quirk_fsl_pcie_header+0x0/0x48
pci 0000:00:00.0: calling quirk_resource_alignment+0x0/0x1c0
pci 0000:00:00.0: supports D1 D2
pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot
pci 0000:00:00.0: PME# disabled
pci_bus 0000:00: fixups for bus
PCI: Fixup bus devices 0 (PHB)
PCI: Try to map irq for 0000:00:00.0...
pci_bus 0000:00: bus scan returning with max=00
PCI: Scanning PHB /pcie@e0009000
PCI: PHB IO resource = 00000000ff7fe000-00000000ffffdfff [100]
PCI: PHB MEM resource 0 = 00000000a8000000-00000000b7ffffff [200]
PCI: PHB MEM offset = 0000000000000000
PCI: PHB IO offset = ff7fe000
probe mode: 0
pci_bus 0001:01: scanning bus
pci : vendor id = 0x1957
pci 0001:01:00.0: found [1957:00c6] class 000b20 header type 01
pci 0001:01:00.0: ignoring class b20 (doesn't match header type 01)
pci 0001:01:00.0: calling fixup_hide_host_resource_fsl+0x0/0x58
pci 0001:01:00.0: calling pcibios_fixup_resources+0x0/0x180
pci 0001:01:00.0: calling quirk_fsl_pcie_header+0x0/0x48
pci 0001:01:00.0: calling quirk_resource_alignment+0x0/0x1c0
pci 0001:01:00.0: supports D1 D2
pci 0001:01:00.0: PME# supported from D0 D1 D2 D3hot
pci 0001:01:00.0: PME# disabled
pci_bus 0001:01: fixups for bus
PCI: Fixup bus devices 1 (PHB)
PCI: Try to map irq for 0001:01:00.0...
pci 0001:01:00.0: scanning [bus 01-ff] behind bridge, pass 0
pci 0001:01:00.0: bus configuration invalid, reconfiguring
pci 0001:01:00.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0001:02: scanning bus
pci : vendor id = 0x1204
pci 0001:02:00.0: trying to set all zeros in BARs
pci 0001:02:00.0: found [1204:e250] class 000000 header type 00
pci 0001:02:00.0: reg 10: [mem 0x00000000-0x0003ffff]
pci 0001:02:00.0: reg 14: [mem 0x00000000-0x0003ffff]
pci 0001:02:00.0: calling pcibios_fixup_resources+0x0/0x180
PCI:0001:02:00.0 Resource 0 0000000000000000-000000000003ffff [40200] is
unassigned
PCI:0001:02:00.0 Resource 1 0000000000000000-000000000003ffff [40200] is
unassigned
pci 0001:02:00.0: calling quirk_resource_alignment+0x0/0x1c0
pci_bus 0001:02: fixups for bus
pci 0001:01:00.0: PCI bridge to [bus 02-ff]
pci 0001:01:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0001:01:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
pci 0001:01:00.0: bridge window [mem 0x00000000-0x000fffff pref]
(disabled)
PCI: Fixup bus devices 2 (0001:01:00.0)
PCI: Try to map irq for 0001:02:00.0...
Got one, spec 2 cells (0x00000001 0x00000008...) on /immr@e0000000
/interrupt-controller@700
irq: irq 1 on host /immr@e0000000/interrupt-controller@700 mapped to virtual
irq 16
__irq_set_trigger: setting type, irq = 16, flags = 8
ipic_set_irq_type function, with virq = 16, flow = 8
Mapped to linux irq 16
pci_bus 0001:02: bus scan returning with max=02
pci_bus 0001:01: bus scan returning with max=02
PCI: Scanning PHB /pcie@e000a000
PCI: PHB IO resource = 00000000feffc000-00000000ff7fbfff [100]
PCI: PHB MEM resource 0 = 00000000c8000000-00000000d7ffffff [200]
PCI: PHB MEM offset = 0000000000000000
PCI: PHB IO offset = feffc000
probe mode: 0
pci_bus 0002:03: scanning bus
pci_bus 0002:03: fixups for bus
PCI: Fixup bus devices 3 (PHB)
pci_bus 0002:03: bus scan returning with max=03
PCI->OF bus map:
0 -> 0
1 -> 0
3 -> 0
PCI: Allocating bus resources for 0000:00...
PCI: PHB (bus 0) bridge rsrc 0: 0000000000000000-00000000000fffff [0x100],
parent c0405660 (PCI IO)
PCI: PHB (bus 0) bridge rsrc 1: 0000000090000000-000000009fffffff [0x200],
parent c0405644 (PCI mem)
PCI: PHB (bus 0) bridge rsrc 2: 0000000080000000-000000008fffffff [0x2200],
parent c0405644 (PCI mem)
PCI: Allocating bus resources for 0001:01...
PCI: PHB (bus 1) bridge rsrc 0: 00000000ff7fe000-00000000ffffdfff [0x100],
parent c0405660 (PCI IO)
PCI: PHB (bus 1) bridge rsrc 1: 00000000a8000000-00000000b7ffffff [0x200],
parent c0405644 (PCI mem)
PCI: Allocating bus resources for 0001:02...
PCI: Allocating bus resources for 0002:03...
PCI: PHB (bus 3) bridge rsrc 0: 00000000feffc000-00000000ff7fbfff [0x100],
parent c0405660 (PCI IO)
PCI: PHB (bus 3) bridge rsrc 1: 00000000c8000000-00000000d7ffffff [0x200],
parent c0405644 (PCI mem)
Reserving legacy ranges for domain 0000
Candidate legacy IO: [io 0x0000-0x0fff]
hose mem offset: 0000000000000000
hose mem res: [mem 0x90000000-0x9fffffff]
hose mem res: [mem 0x80000000-0x8fffffff pref]
Reserving legacy ranges for domain 0001
Candidate legacy IO: [io 0xff7fe000-0xff7fefff]
hose mem offset: 0000000000000000
hose mem res: [mem 0xa8000000-0xb7ffffff]
Reserving legacy ranges for domain 0002
Candidate legacy IO: [io 0xfeffc000-0xfeffcfff]
hose mem offset: 0000000000000000
hose mem res: [mem 0xc8000000-0xd7ffffff]
PCI: Assigning unassigned resources...
pci 0001:01:00.0: BAR 8: can't assign mem (size 0x100000)
pci 0001:01:00.0: PCI bridge to [bus 02-02]
pci 0001:01:00.0: __pci_setup_bridge: Disabling prefetch window.
pci 0001:01:00.0: __pci_setup_bridge: Prefetch window disabled successfully.
pci 0001:01:00.0: bridge window [io disabled]
pci 0001:01:00.0: bridge window [mem disabled]
pci 0001:01:00.0: bridge window [mem pref disabled]
pci_bus 0000:00: resource 0 [io 0x0000-0xfffff]
pci_bus 0000:00: resource 1 [mem 0x90000000-0x9fffffff]
pci_bus 0000:00: resource 2 [mem 0x80000000-0x8fffffff pref]
pci_bus 0001:01: resource 0 [io 0xff7fe000-0xffffdfff]
pci_bus 0001:01: resource 1 [mem 0xa8000000-0xb7ffffff]
pci_bus 0002:03: resource 0 [io 0xfeffc000-0xff7fbfff]
pci_bus 0002:03: resource 1 [mem 0xc8000000-0xd7ffffff]
Registering qe_ic with sysfs...
Registering ipic with sysfs...
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
Switching to clocksource timebase
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
pci 0000:00:00.0: calling quirk_cardbus_legacy+0x0/0x44
pci 0000:00:00.0: calling quirk_usb_early_handoff+0x0/0x740
pci 0001:01:00.0: calling quirk_cardbus_legacy+0x0/0x44
pci 0001:01:00.0: calling quirk_usb_early_handoff+0x0/0x740
pci 0001:02:00.0: calling quirk_cardbus_legacy+0x0/0x44
pci 0001:02:00.0: calling quirk_usb_early_handoff+0x0/0x740
PCI: CLS 32 bytes, default 32
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 3345k freed
irq: irq 9 on host /immr@e0000000/interrupt-controller@700 mapped to virtual
irq 17
__irq_set_trigger: setting type, irq = 17, flags = 8
ipic_set_irq_type function, with virq = 17, flow = 8
irq: irq 10 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 18
__irq_set_trigger: setting type, irq = 18, flags = 8
ipic_set_irq_type function, with virq = 18, flow = 8
irq: irq 80 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 80
__irq_set_trigger: setting type, irq = 80, flags = 8
ipic_set_irq_type function, with virq = 80, flow = 8
audit: initializing netlink socket (disabled)
type=2000 audit(0.220:1): initialized
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
SGI XFS with security attributes, large block/inode numbers, no debug
enabled
msgmni has been set to 494
alg: No test for cipher_null (cipher_null-generic)
alg: No test for ecb(cipher_null) (ecb-cipher_null)
alg: No test for digest_null (digest_null-generic)
alg: No test for compress_null (compress_null-generic)
alg: No test for stdrng (krng)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 17) is a 16550A
console [ttyS0] enabled, bootconsole disabled
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 18) is a 16550A
brd: module loaded
of_mpc8xxx_spi_probe function called.
irq: irq 16 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 19
__irq_set_trigger: setting type, irq = 19, flags = 8
ipic_set_irq_type function, with virq = 19, flow = 8
mpc8xxx_spi_probe function called.
mpc8xxx_spi e0007000.spi: at 0xd1078000 (irq = 19), CPU mode
irq: irq 32 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 32
__irq_set_trigger: setting type, irq = 32, flags = 8
ipic_set_irq_type function, with virq = 32, flow = 8
irq: irq 33 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 33
__irq_set_trigger: setting type, irq = 33, flags = 8
ipic_set_irq_type function, with virq = 33, flow = 8
irq: irq 34 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 34
__irq_set_trigger: setting type, irq = 34, flags = 8
ipic_set_irq_type function, with virq = 34, flow = 8
eth0: Gianfar Ethernet Controller Version 1.2, 04:00:00:00:00:0a
eth0: Running with NAPI enabled
eth0: RX BD ring size for Q[0]: 256
eth0: TX BD ring size for Q[0]: 256
irq: irq 35 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 35
__irq_set_trigger: setting type, irq = 35, flags = 8
ipic_set_irq_type function, with virq = 35, flow = 8
irq: irq 36 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 36
__irq_set_trigger: setting type, irq = 36, flags = 8
ipic_set_irq_type function, with virq = 36, flow = 8
irq: irq 37 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 37
__irq_set_trigger: setting type, irq = 37, flags = 8
ipic_set_irq_type function, with virq = 37, flow = 8
eth1: Gianfar Ethernet Controller Version 1.2, 00:00:00:00:00:00
eth1: Running with NAPI enabled
eth1: RX BD ring size for Q[0]: 256
eth1: TX BD ring size for Q[0]: 256
ucc_geth: QE UCC Gigabit Ethernet Controller
Freescale PowerQUICC MII Bus: probed
irq: irq 17 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 20
__irq_set_trigger: setting type, irq = 20, flags = 8
ipic_set_irq_type function, with virq = 20, flow = 8
Freescale PowerQUICC MII Bus: probed
mice: PS/2 mouse device common for all mice
Skipping unavailable LED gpio -19 (pwr)
Skipping unavailable LED gpio -19 (hdd)
TCP cubic registered
NET: Registered protocol family 17
registered taskstats version 1
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing unused kernel memory: 192k init
PHY: mdio@e0024520:02 - Link is Up - 10/Half
================================================================
Regards,
Ravi
[-- Attachment #2: Type: text/html, Size: 19679 bytes --]
^ permalink raw reply
* Re: linux-next: build warnings after merge of the final tree (tip treee related)
From: Yinghai Lu @ 2010-09-13 8:24 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Peter Zijlstra, linux-kernel, linux-next, H. Peter Anvin,
Ingo Molnar, ppc-dev, Thomas Gleixner
In-Reply-To: <20100913143942.7344ada4.sfr@canb.auug.org.au>
On 09/12/2010 09:39 PM, Stephen Rothwell wrote:
>
> Your patch fixes some of the warnings, but still leaves these for a
> powerpc allnoconfig build:
>
> WARNING: mm/built-in.o(.text+0x25d80): Section mismatch in reference from the function memblock_double_array() to the function .init.text:memblock_free()
> The function memblock_double_array() references
> the function __init memblock_free().
> This is often because memblock_double_array lacks a __init
> annotation or the annotation of memblock_free is wrong.
>
> WARNING: mm/built-in.o(.text+0x26318): Section mismatch in reference from the function memblock_reserve_reserved_regions() to the function .init.text:memblock_reserve()
> The function memblock_reserve_reserved_regions() references
> the function __init memblock_reserve().
> This is often because memblock_reserve_reserved_regions lacks a __init
> annotation or the annotation of memblock_reserve is wrong.
>
> WARNING: mm/built-in.o(.text+0x26490): Section mismatch in reference from the function memblock_free_reserved_regions() to the function .init.text:memblock_free()
> The function memblock_free_reserved_regions() references
> the function __init memblock_free().
> This is often because memblock_free_reserved_regions lacks a __init
> annotation or the annotation of memblock_free is wrong.
v1 already changed them all to __init_memblock, so we should not have those warnings.
>
> And these for a i386 defconfig build:
>
> WARNING: mm/built-in.o(.text+0x1e261): Section mismatch in reference from the function memblock_is_memory() to the variable .init.data:memblock
> The function memblock_is_memory() references
> the variable __initdata memblock.
> This is often because memblock_is_memory lacks a __initdata
> annotation or the annotation of memblock is wrong.
>
> WARNING: mm/built-in.o(.text+0x1e27f): Section mismatch in reference from the function memblock_is_region_memory() to the variable .init.data:memblock
> The function memblock_is_region_memory() references
> the variable __initdata memblock.
> This is often because memblock_is_region_memory lacks a __initdata
> annotation or the annotation of memblock is wrong.
>
you must have old gcc, those functions are not used with i386.
[PATCH -v2] memblock: Fix section mismatch warning
for arches that use memblock other than x86
-v2: more with memblock_is_meory()
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Yinghai Lu <Yinghai@kernel.org>
---
mm/memblock.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
Index: linux-2.6/mm/memblock.c
===================================================================
--- linux-2.6.orig/mm/memblock.c
+++ linux-2.6/mm/memblock.c
@@ -125,8 +125,8 @@ static phys_addr_t __init memblock_find_
return MEMBLOCK_ERROR;
}
-static phys_addr_t __init memblock_find_base(phys_addr_t size, phys_addr_t align,
- phys_addr_t start, phys_addr_t end)
+static phys_addr_t __init_memblock memblock_find_base(phys_addr_t size,
+ phys_addr_t align, phys_addr_t start, phys_addr_t end)
{
long i;
@@ -439,12 +439,12 @@ long __init_memblock memblock_remove(phy
return __memblock_remove(&memblock.memory, base, size);
}
-long __init memblock_free(phys_addr_t base, phys_addr_t size)
+long __init_memblock memblock_free(phys_addr_t base, phys_addr_t size)
{
return __memblock_remove(&memblock.reserved, base, size);
}
-long __init memblock_reserve(phys_addr_t base, phys_addr_t size)
+long __init_memblock memblock_reserve(phys_addr_t base, phys_addr_t size)
{
struct memblock_type *_rgn = &memblock.reserved;
@@ -671,12 +671,12 @@ int __init memblock_is_reserved(phys_add
return memblock_search(&memblock.reserved, addr) != -1;
}
-int memblock_is_memory(phys_addr_t addr)
+int __init_memblock memblock_is_memory(phys_addr_t addr)
{
return memblock_search(&memblock.memory, addr) != -1;
}
-int memblock_is_region_memory(phys_addr_t base, phys_addr_t size)
+int __init_memblock memblock_is_region_memory(phys_addr_t base, phys_addr_t size)
{
int idx = memblock_search(&memblock.reserved, base);
@@ -693,7 +693,7 @@ int __init_memblock memblock_is_region_r
}
-void __init memblock_set_current_limit(phys_addr_t limit)
+void __init_memblock memblock_set_current_limit(phys_addr_t limit)
{
memblock.current_limit = limit;
}
^ permalink raw reply
* Re: [PATCH 11/11] sound: Remove pr_<level> uses of KERN_<level>
From: Mark Brown @ 2010-09-13 8:25 UTC (permalink / raw)
To: Joe Perches
Cc: cbe-oss-dev, alsa-devel, Jiri Kosina, Geoff Levand, linux-kernel,
Jaroslav Kysela, Takashi Iwai, linuxppc-dev, Liam Girdwood
In-Reply-To: <27a88f64b5bfec16c8abf5aca89b7a1b7533ecb9.1284267142.git.joe@perches.com>
On Sat, Sep 11, 2010 at 10:10:59PM -0700, Joe Perches wrote:
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> sound/ppc/snd_ps3.c | 2 +-
> sound/soc/s3c24xx/s3c-dma.c | 3 +--
> 2 files changed, 2 insertions(+), 3 deletions(-)
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
^ permalink raw reply
* RE: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Zang Roy-R61911 @ 2010-09-13 7:30 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <20100909114153.GB6622@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIFNlcHRl
bWJlciAwOSwgMjAxMCAxOTo0MiBQTQ0KPiBUbzogWmFuZyBSb3ktUjYxOTExDQo+IENjOiBsaW51
eC1tdGRAbGlzdHMuaW5mcmFkZWFkLm9yZzsgZHdtdzJAaW5mcmFkZWFkLm9yZzsgZGVkZWtpbmQx
QGdtYWlsLmNvbTsNCj4gYWtwbUBsaW51eC1mb3VuZGF0aW9uLm9yZzsgTGFuIENodW5oZS1CMjU4
MDY7IFdvb2QgU2NvdHQtQjA3NDIxOyBHYWxhIEt1bWFyLQ0KPiBCMTE3ODA7IGxpbnV4cHBjLWRl
dkBvemxhYnMub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjIgMy8zXVtNVERdIFA0MDgwL210
ZDogRml4IHRoZSBmcmVlc2NhbGUgbGJjIGlzc3VlIHdpdGgNCj4gMzZiaXQgbW9kZQ0KPiANCj4g
T24gVGh1LCBTZXAgMDksIDIwMTAgYXQgMDY6MjA6MzJQTSArMDgwMCwgUm95IFphbmcgd3JvdGU6
DQo+IFsuLi5dDQo+ID4gIC8qKg0KPiA+ICsgKiBmc2xfbGJjX2FkZHIgLSBjb252ZXJ0IHRoZSBi
YXNlIGFkZHJlc3MNCj4gPiArICogQGFkZHJfYmFzZToJYmFzZSBhZGRyZXNzIG9mIHRoZSBtZW1v
cnkgYmFuaw0KPiA+ICsgKg0KPiA+ICsgKiBUaGlzIGZ1bmN0aW9uIGNvbnZlcnRzIGEgYmFzZSBh
ZGRyZXNzIG9mIGxiYyBpbnRvIHRoZSByaWdodCBmb3JtYXQgZm9yDQo+IHRoZSBCUg0KPiA+ICsg
KiByZWdpc3RlcnMuIElmIHRoZSBTT0MgaGFzIGVMQkMgdGhlbiBpdCByZXR1cm5zIDMyYml0IHBo
eXNpY2FsIGFkZHJlc3MNCj4gZWxzZQ0KPiA+ICsgKiBpdCByZXR1cm5zIDM0Yml0IHBoeXNpY2Fs
IGFkZHJlc3MgZm9yIGxvY2FsIGJ1cyhFeGFtcGxlOiBNUEM4NjQxKS4NCj4gPiArICovDQo+IA0K
PiBJdCByZXR1cm5zIDM0Yml0IHBoeXNpY2FsIGFkZHJlc3MgZW5jb2RlZCBpbiBhIDMyIGJpdCB3
b3JkLA0KPiByaWdodD8gDQpZZXMuDQoNCj5CZWNhdXNlLCBJSVJDLCAndW5zaWduZWQgaW50JyBp
cyBhbHdheXMgMzIgYml0Lg0KPiANCj4gV29ydGggbWVudGlvbmluZyB0aGlzIGZhY3QuDQpBZ3Jl
ZS4NClRoZSBjb21tZW50IGlzIGEgbGl0dGxlIGJpdCBjb25mdXNpbmcuIFdpbGwgdXBkYXRlLg0K
DQoNCj4gDQo+ID4gK3Vuc2lnbmVkIGludCBmc2xfbGJjX2FkZHIocGh5c19hZGRyX3QgYWRkcl9i
YXNlKQ0KPiA+ICt7DQo+ID4gKwl2b2lkICpkZXY7DQo+IA0KPiBzdHJ1Y3QgZGV2aWNlX25vZGUg
Km5wOw0KPiANCj4gPiArCWludCBjb21wYXRpYmxlOw0KPiA+ICsNCj4gPiArCWRldiA9IGZzbF9s
YmNfY3RybF9kZXYtPmRldi0+b2Zfbm9kZTsNCj4gPiArCWNvbXBhdGlibGUgPSBvZl9kZXZpY2Vf
aXNfY29tcGF0aWJsZShkZXYsICJmc2wsZWxiYyIpOw0KPiA+ICsNCj4gPiArCWlmIChjb21wYXRp
YmxlKQ0KPiA+ICsJCXJldHVybiBhZGRyX2Jhc2UgJiAweGZmZmY4MDAwOw0KPiA+ICsJZWxzZQ0K
PiA+ICsJCXJldHVybiAoYWRkcl9iYXNlICYgMHgwZmZmZjgwMDB1bGwpDQo+ID4gKwkJCXwgKChh
ZGRyX2Jhc2UgJiAweDMwMDAwMDAwMHVsbCkgPj4gMTkpOw0KPiA+ICt9DQo+ID4gK0VYUE9SVF9T
WU1CT0woZnNsX2xiY19hZGRyKTsNCj4gDQo+IEFsbW9zdCBwZXJmZWN0LiBJJ20gbm90IHN1cmUg
aWYgJ3Vuc2lnbmVkIGludCcgaXMgdGVjaG5pY2FsbHkNCj4gY29ycmVjdCByZXR1cm4gdHlwZSBm
b3IgdGhpcyBmdW5jdGlvbiB0aG91Z2guIEkgZ3Vlc3MgaXQgc2hvdWxkDQo+IGJlIHUzMi4NCj4g
DQpXaGF0IGlzIHRoZSBkaWZmZXJlbnQgZm9yIHVuc2lnbmVkIGludCBhbmQgdTMyPyBJIHRoaW5r
IHRoZXkgYXJlIHNhbWUuDQoNCg0KPiBBbHNvLCB0aGUgZnVuY3Rpb24gbWF5IGJlIGEgYml0IG1v
cmUgdW5kZXJzdGFuZGFibGUgYW5kIHNob3J0ZXI6DQo+IA0KPiB1MzIgZnNsX2xiY19hZGRyKHBo
eXNfYWRkcl90IGFkZHIpDQo+IHsNCj4gCXN0cnVjdCBkZXZpY2Vfbm9kZSAqbnAgPSBmc2xfbGJj
X2N0cmxfZGV2LT5kZXYtPm9mX25vZGU7DQo+IAl1MzIgYWRkcmwgPSBhZGRyICYgMHhmZmZmODAw
MDsNCmlmIGFkZHIgaXMgMzQgYml0IGxvbmcsIGlzIHRoaXMgY29ycmVjdD8NClRoYW5rcy4NClJv
eQ0K
^ permalink raw reply
* RE: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Zang Roy-R61911 @ 2010-09-13 7:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <AANLkTik3ViwjmOFfm6GUwmuzMkO75+2pCUdnC0z8A7Jb@mail.gmail.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZ2VlcnQudXl0dGVyaG9l
dmVuQGdtYWlsLmNvbSBbbWFpbHRvOmdlZXJ0LnV5dHRlcmhvZXZlbkBnbWFpbC5jb21dIE9uDQo+
IEJlaGFsZiBPZiBHZWVydCBVeXR0ZXJob2V2ZW4NCj4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJl
ciAwOSwgMjAxMCAxOTowNiBQTQ0KPiBUbzogWmFuZyBSb3ktUjYxOTExDQo+IENjOiBsaW51eC1t
dGRAbGlzdHMuaW5mcmFkZWFkLm9yZzsgV29vZCBTY290dC1CMDc0MjE7IGRlZGVraW5kMUBnbWFp
bC5jb207IExhbg0KPiBDaHVuaGUtQjI1ODA2OyBsaW51eHBwYy1kZXZAb3psYWJzLm9yZzsgYWtw
bUBsaW51eC1mb3VuZGF0aW9uLm9yZzsNCj4gZHdtdzJAaW5mcmFkZWFkLm9yZzsgR2FsYSBLdW1h
ci1CMTE3ODANCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2MiAzLzNdW01URF0gUDQwODAvbXRkOiBG
aXggdGhlIGZyZWVzY2FsZSBsYmMgaXNzdWUgd2l0aA0KPiAzNmJpdCBtb2RlDQo+IA0KPiBPbiBU
aHUsIFNlcCA5LCAyMDEwIGF0IDEyOjIwLCBSb3kgWmFuZyA8dGllLWZlaS56YW5nQGZyZWVzY2Fs
ZS5jb20+IHdyb3RlOg0KPiA+IEZyb206IExhbiBDaHVuaGUtQjI1ODA2IDxiMjU4MDZAZnJlZXNj
YWxlLmNvbT4NCj4gPg0KPiA+IFdoZW4gc3lzdGVtIHVzZXMgMzZiaXQgcGh5c2ljYWwgYWRkcmVz
cywgcmVzLnN0YXJ0IGlzIDM2Yml0DQo+ID4gcGh5c2ljYWwgYWRkcmVzcy4gQnV0IHRoZSBmdW5j
dGlvbiBvZiBpbl9iZTMyIHJldHVybnMgMzJiaXQNCj4gPiBwaHlzaWNhbCBhZGRyZXNzLiBUaGVu
IGJvdGggb2YgdGhlbSBjb21wYXJlZCBlYWNoIG90aGVyIGlzDQo+ID4gd3JvbmcuIFNvIGJ5IGNv
bnZlcnRpbmcgdGhlIGFkZHJlc3Mgb2YgcmVzLnN0YXJ0IGludG8NCj4gPiB0aGUgcmlnaHQgZm9y
bWF0IGZpeGVzIHRoaXMgaXNzdWUuDQo+IA0KPiA+IMKgLyoqDQo+ID4gKyAqIGZzbF9sYmNfYWRk
ciAtIGNvbnZlcnQgdGhlIGJhc2UgYWRkcmVzcw0KPiA+ICsgKiBAYWRkcl9iYXNlOiBiYXNlIGFk
ZHJlc3Mgb2YgdGhlIG1lbW9yeSBiYW5rDQo+ID4gKyAqDQo+ID4gKyAqIFRoaXMgZnVuY3Rpb24g
Y29udmVydHMgYSBiYXNlIGFkZHJlc3Mgb2YgbGJjIGludG8gdGhlIHJpZ2h0IGZvcm1hdCBmb3IN
Cj4gdGhlIEJSDQo+ID4gKyAqIHJlZ2lzdGVycy4gSWYgdGhlIFNPQyBoYXMgZUxCQyB0aGVuIGl0
IHJldHVybnMgMzJiaXQgcGh5c2ljYWwgYWRkcmVzcw0KPiBlbHNlDQo+ID4gKyAqIGl0IHJldHVy
bnMgMzRiaXQgcGh5c2ljYWwgYWRkcmVzcyBmb3IgbG9jYWwgYnVzKEV4YW1wbGU6IE1QQzg2NDEp
Lg0KPiA+ICsgKi8NCj4gPiArdW5zaWduZWQgaW50IGZzbF9sYmNfYWRkcihwaHlzX2FkZHJfdCBh
ZGRyX2Jhc2UpDQo+ICAgICBeXl5eXl5eXl5eXl4NCj4gU2hvdWxkbid0IHRoaXMgYmUgdTMyIG9y
IF9fYmUzMiwgZm9yIGNvbnNpc3RlbmN5IHdpdGggdGhlIGFjdHVhbA0KPiBjb21wYXJpc29ucyBi
ZWxvdz8NCl9fYmUzMiBpcyBiZXR0ZXIuDQpUaGFua3MuDQpSb3kNCg==
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox