* Re: [linuxppc-release] [PATCH 1/2] powerpc: document the FSL MPIC message register binding
From: Scott Wood @ 2012-02-18 0:47 UTC (permalink / raw)
To: Yoder Stuart-B08248
Cc: meador_inge@mentor.com, linuxppc-dev@lists.ozlabs.org,
Li Yang-R58472, Jia Hongtao-B38951
In-Reply-To: <9F6FE96B71CF29479FF1CDC8046E15032F516B@039-SN1MPN1-002.039d.mgd.msft.net>
On 02/17/2012 09:50 AM, Yoder Stuart-B08248 wrote:
>
>
>> -----Original Message-----
>> From: linuxppc-release-bounces@linux.freescale.net [mailto:linuxppc-release-
>> bounces@linux.freescale.net] On Behalf Of Jia Hongtao-B38951
>> Sent: Thursday, February 16, 2012 8:49 PM
>> To: linuxppc-dev@lists.ozlabs.org
>> Cc: meador_inge@mentor.com; Li Yang-R58472; Jia Hongtao-B38951
>> Subject: [linuxppc-release] [PATCH 1/2] powerpc: document the FSL MPIC message register
>> binding
>>
>> This binding documents how the message register blocks found in some FSL MPIC implementations
>> shall be represented in a device tree.
>>
>> Signed-off-by: Meador Inge <meador_inge@mentor.com>
>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
>> Signed-off-by: Li Yang <leoli@freescale.com>
>> ---
>> .../devicetree/bindings/powerpc/fsl/mpic-msgr.txt | 62 ++++++++++++++++++++
>> 1 files changed, 62 insertions(+), 0 deletions(-) create mode 100644
>> Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
>>
>> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
>> b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
>> new file mode 100644
>> index 0000000..b4ae70e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
>> @@ -0,0 +1,62 @@
>> +* FSL MPIC Message Registers
>> +
>> +This binding specifies what properties must be available in the device
>> +tree representation of the message register blocks found in some FSL
>> +MPIC implementations.
>> +
>> +Required properties:
>> +
>> + - compatible: Specifies the compatibility list for the message register
>> + block. The type shall be <string> and the value shall be of the form
>> + "fsl,mpic-v<version>-msgr", where <version> is the version number of
>> + the MPIC containing the message registers.
>
> The type for compatibles is a <string-list>.
>
>> + - reg: Specifies the base physical address(s) and size(s) of the
>> + message register block's addressable register space. The type shall be
>> + <prop-encoded-array>.
>> +
>> + - interrupts: Specifies a list of interrupt source and level-sense pairs.
>> + The type shall be <prop-encoded-array>. The length shall be equal to
>> + the number of registers that are available for receiving interrupts.
>
> How many interrupts are there? If more than 1, this is where
> you need to specify what each interrupt is for.
They aren't "for" anything in particular -- each interrupt is associated
with a message register. The binding does say that the number of
interrupts corresponds to the bits set in the receive mask.
>> +Optional properties:
>> +
>> + - mpic-msgr-receive-mask: Specifies what registers in the containing block
>> + are allowed to receive interrupts. The value is a bit mask where a set
>> + bit at bit 'n' indicates that message register 'n' can receive interrupts.
>> + The type shall be <prop-encoded-array>. If not present, then all of
>> + the message registers in the block are available.
>
> Your example implies that this is 1 32-bit cell. If that is the case then
> this really should be of type '<u32>'.
And should clarify that "bit 'n'" means numbered from LSB, given how PPC
hardware docs tend to use the opposite convention.
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable
From: Scott Wood @ 2012-02-18 0:56 UTC (permalink / raw)
To: Timur Tabi; +Cc: Li Yang-R58472, linuxppc-dev@ozlabs.org
In-Reply-To: <4F3EDC35.5070904@freescale.com>
On 02/17/2012 05:01 PM, Timur Tabi wrote:
> So I noticed something else. PHYS_64BIT is not defined in
> mpc85xx_smp_defconfig.
It couldn't have been, since it was selected by another kconfig option.
defconfigs only hold non-default options.
> However, that select statement also means that we can't build a 32-bit
> kernel. This is a problem for mpc85xx_defconfig, because that defconfig
> includes support for the MPC8540ADS. The 8540 has an e500v1 core which
> doesn't support MAS7 (i.e. no 36-bit physical addresses).
It's not a problem for 8540, just lost optimization potential.
> So any patch that removes "select PHYS_64BIT" from an mpc85xx_defconfig
> board must also turn on that option in the defconfig. The patches from me
> and Leo don't do that.
Yes, or maybe make it "default y", and/or require an "I know what I'm
doing" option to be set for it to be unset if a board otherwise wants it.
The ability to turn it off is potentially useful for any board, since
the address map is determined by boot software which can be changed, but
we shouldn't make it too easy to fail to select it for boards that
normally require it.
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable
From: Benjamin Herrenschmidt @ 2012-02-18 2:19 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org, Timur Tabi, Li Yang-R58472
In-Reply-To: <4F3EF72C.2090305@freescale.com>
On Fri, 2012-02-17 at 18:56 -0600, Scott Wood wrote:
> Yes, or maybe make it "default y", and/or require an "I know what I'm
> doing" option to be set for it to be unset if a board otherwise wants it.
>
> The ability to turn it off is potentially useful for any board, since
> the address map is determined by boot software which can be changed, but
> we shouldn't make it too easy to fail to select it for boards that
> normally require it.
Don't we have CONFIG_EMBEDDED to make that sort of option visible ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] usb: Fix build error due to dma_mask is not at pdev_archdata at ARM
From: Peter Chen @ 2012-02-18 10:22 UTC (permalink / raw)
To: Peter Chen, Li Yang-R58472
Cc: fabio.estevam, linux-usb, stern, ramneek.mehresh, agust,
linuxppc-dev, stable
In-Reply-To: <1329356512-31527-1-git-send-email-peter.chen@freescale.com>
On Thu, Feb 16, 2012 at 9:41 AM, Peter Chen <peter.chen@freescale.com> wrot=
e:
> When build i.mx platform with imx_v6_v7_defconfig, and after adding
> USB Gadget support, it has below build error:
>
> CC =A0 =A0 =A0drivers/usb/host/fsl-mph-dr-of.o
> drivers/usb/host/fsl-mph-dr-of.c: In function 'fsl_usb2_device_register':
> drivers/usb/host/fsl-mph-dr-of.c:97: error: 'struct pdev_archdata'
> has no member named 'dma_mask'
>
> It has discussed at: http://www.spinics.net/lists/linux-usb/msg57302.html
>
> For PowerPC, there is dma_mask at struct pdev_archdata, but there is
> no dma_mask at struct pdev_archdata for ARM. The pdev_archdata is
> related to specific platform, it should NOT be accessed by
> cross platform drivers, like USB.
>
> The code for pdev_archdata should be useless, as for PowerPC,
> it has already gotten the value for pdev->dev.dma_mask at function
> arch_setup_pdev_archdata of arch/powerpc/kernel/setup-common.c.
>
> Tested-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
> Signed-off-by: Peter Chen <peter.chen@freescale.com>
> ---
> =A0drivers/usb/host/fsl-mph-dr-of.c | =A0 =A01 -
> =A01 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-=
dr-of.c
> index 7916e56..ab333ac 100644
> --- a/drivers/usb/host/fsl-mph-dr-of.c
> +++ b/drivers/usb/host/fsl-mph-dr-of.c
> @@ -94,7 +94,6 @@ struct platform_device * __devinit fsl_usb2_device_regi=
ster(
> =A0 =A0 =A0 =A0pdev->dev.parent =3D &ofdev->dev;
>
> =A0 =A0 =A0 =A0pdev->dev.coherent_dma_mask =3D ofdev->dev.coherent_dma_ma=
sk;
> - =A0 =A0 =A0 pdev->dev.dma_mask =3D &pdev->archdata.dma_mask;
> =A0 =A0 =A0 =A0*pdev->dev.dma_mask =3D *ofdev->dev.dma_mask;
>
> =A0 =A0 =A0 =A0retval =3D platform_device_add_data(pdev, pdata, sizeof(*p=
data));
Hi Leo, can your guys give me an ACK for it? Then, Alan can apply it.
Ramneek has already tested it, and confirmed it did not break host
function at his platform.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
--=20
BR,
Peter Chen
^ permalink raw reply
* Re: [PATCH] powerpc/usb: fix bug of kernel hang when initializing usb
From: Sergei Shtylyov @ 2012-02-18 15:39 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <1329386540-12341-1-git-send-email-Shengzhou.Liu@freescale.com>
Hello.
On 16-02-2012 14:02, Shengzhou Liu wrote:
> If USB UTMI PHY is not enable, writing to portsc register will lead to
> kernel hang during boot up.
> Signed-off-by: Shengzhou Liu<Shengzhou.Liu@freescale.com>
[...]
> diff --git a/drivers/usb/host/ehci-fsl.h b/drivers/usb/host/ehci-fsl.h
> index bdf43e2..0e400c2 100644
> --- a/drivers/usb/host/ehci-fsl.h
> +++ b/drivers/usb/host/ehci-fsl.h
> @@ -45,6 +45,7 @@
> #define FSL_SOC_USB_PRICTRL 0x40c /* NOTE: big-endian */
> #define FSL_SOC_USB_SICTRL 0x410 /* NOTE: big-endian */
> #define FSL_SOC_USB_CTRL 0x500 /* NOTE: big-endian */
> +#define CTRL_UTMI_PHY_EN (1<<9)
Please put spaces around << like below.
> #define CTRL_PHY_CLK_VALID (1<< 17)
> #define SNOOP_SIZE_2GB 0x1e
> #endif /* _EHCI_FSL_H */
WBR, Sergei
^ permalink raw reply
* RE: [PATCH] powerpc/85xx:Add PSC9131 RDB Support
From: Kushwaha Prabhakar-B32579 @ 2012-02-18 16:45 UTC (permalink / raw)
To: Andy Fleming, Tabi Timur-B04825
Cc: Aggrwal Poonam-B10812, Srivastava Rajan-B34330,
Mehresh Ramneek-B31383, Goyal Akhil-B35197,
linuxppc-dev@lists.ozlabs.org,
devicetree-discuss@lists.ozlabs.org, Jain Priyanka-B32167
In-Reply-To: <CAKWjMd70yAkbY4fbMaumih86YEujjDti4YRrnH4Yycj7-NEBPw@mail.gmail.com>
Thanks Andy and Timur for correcting the statement.
I will make sure of this in future patches.
--Prabhakar
> -----Original Message-----
> From: Andy Fleming [mailto:afleming@gmail.com]
> Sent: Saturday, February 18, 2012 4:56 AM
> To: Tabi Timur-B04825
> Cc: Kushwaha Prabhakar-B32579; Goyal Akhil-B35197; Aggrwal Poonam-B10812;
> Srivastava Rajan-B34330; Mehresh Ramneek-B31383; devicetree-
> discuss@lists.ozlabs.org; linuxppc-dev@lists.ozlabs.org; Jain Priyanka-
> B32167
> Subject: Re: [PATCH] powerpc/85xx:Add PSC9131 RDB Support
>=20
> On Fri, Feb 17, 2012 at 1:20 PM, Tabi Timur-B04825 <B04825@freescale.com>
> wrote:
> > On Tue, Feb 14, 2012 at 2:37 AM, Prabhakar Kushwaha
> > <prabhakar@freescale.com> wrote:
> >>
> >> =A0Applied on
> >> git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
> >> branch next
> >
> > This is actually a false statement. =A0"Applied" is past tense, so you
> > are saying that this patch has *already* been applied to Kumar's
> > powerpc.git repository. =A0But this is not true -- Kumar's repository
> > has not been updated in the last three weeks, and this patch is
> > nowhere to be found.
>=20
> I'm pretty sure the sentence should read:
>=20
> Based on git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
> branch next
>=20
> Good idea to correct that for future submissions, as it is otherwise
> confusing. Could also say "Developed against" instead of "Based on".
>=20
> Andy
^ permalink raw reply
* Re: [PATCH] powerpc: perf: power_pmu_start restores incorrect values, breaking frequency events
From: Stephane Eranian @ 2012-02-19 11:13 UTC (permalink / raw)
To: Paul Mackerras
Cc: gleb, peterz, vince, linux-kernel, andi, Anton Blanchard, imunsie,
mingo, sukadev, linuxppc-dev, wcohen, asharma, emunson
In-Reply-To: <20120216045749.GA25364@bloggs.ozlabs.ibm.com>
Glad to see you fixed the PPC problem.
On Thu, Feb 16, 2012 at 5:57 AM, Paul Mackerras <paulus@samba.org> wrote:
> On Thu, Feb 16, 2012 at 03:48:22PM +1100, Anton Blanchard wrote:
>>
>> perf on POWER stopped working after commit e050e3f0a71b (perf: Fix
>> broken interrupt rate throttling). That patch exposed a bug in
>> the POWER perf_events code.
>>
>> Since the PMCs count upwards and take an exception when the top bit
>> is set, we want to write 0x80000000 - left in power_pmu_start. We were
>> instead programming in left which effectively disables the counter
>> until we eventually hit 0x80000000. This could take seconds or longer.
>>
>> With the patch applied I get the expected number of samples:
>>
>> # taskset -c 0 yes > /dev/null &
>> # perf record -C 0 -a sleep 10
>> # perf report -D | grep SAMPLE | tail -1
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SAMPLE events: =C2=A0 =C2=A0 =C2=A0 9=
948
>>
>> Signed-off-by: Anton Blanchard <anton@samba.org>
>
> Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* [PATCH] tty/powerpc: early udbg consoles can't be modules
From: Stephen Rothwell @ 2012-02-19 20:01 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: ppc-dev, Timur Tabi, stable
[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]
Fixes these build errors:
ERROR: ".udbg_printf" [drivers/tty/ehv_bytechan.ko] undefined!
ERROR: ".register_early_udbg_console" [drivers/tty/ehv_bytechan.ko] undefined!
ERROR: "udbg_putc" [drivers/tty/ehv_bytechan.ko] undefined!
Cc: Timur Tabi <timur@freescale.com>
Cc: stable@vger.kernel.org (v3.2)
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/tty/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index b3d1741..830cd62 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -365,7 +365,7 @@ config PPC_EPAPR_HV_BYTECHAN
config PPC_EARLY_DEBUG_EHV_BC
bool "Early console (udbg) support for ePAPR hypervisors"
- depends on PPC_EPAPR_HV_BYTECHAN
+ depends on PPC_EPAPR_HV_BYTECHAN=y
help
Select this option to enable early console (a.k.a. "udbg") support
via an ePAPR byte channel. You also need to choose the byte channel
--
1.7.9
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* warnings from drivers/tty/ehv_bytechan.c
From: Stephen Rothwell @ 2012-02-19 20:07 UTC (permalink / raw)
To: Timur Tabi; +Cc: Greg Kroah-Hartman, ppc-dev
[-- Attachment #1: Type: text/plain, Size: 600 bytes --]
Hi Timur,
If you build drivers/tty/ehv_bytechan.c as a module, it produces these warmings:
drivers/tty/ehv_bytechan.c:362:1: warning: data definition has no type or storage class
drivers/tty/ehv_bytechan.c:362:1: warning: type defaults to 'int' in declaration of 'console_initcall'
drivers/tty/ehv_bytechan.c:362:1: warning: parameter names (without types) in function declaration
drivers/tty/ehv_bytechan.c:334:19: warning: 'ehv_bc_console_init' defined but not used
console_initcall() is not defined for modules.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] tty/powerpc: early udbg consoles can't be modules
From: Stephen Rothwell @ 2012-02-19 20:22 UTC (permalink / raw)
To: gregkh; +Cc: ppc-dev, Timur Tabi, stable
[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]
Fixes these build errors:
ERROR: ".udbg_printf" [drivers/tty/ehv_bytechan.ko] undefined!
ERROR: ".register_early_udbg_console" [drivers/tty/ehv_bytechan.ko] undefined!
ERROR: "udbg_putc" [drivers/tty/ehv_bytechan.ko] undefined!
Cc: Timur Tabi <timur@freescale.com>
Cc: stable@vger.kernel.org (v3.2)
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/tty/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Resent with Greg's correct new address.
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index b3d1741..830cd62 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -365,7 +365,7 @@ config PPC_EPAPR_HV_BYTECHAN
config PPC_EARLY_DEBUG_EHV_BC
bool "Early console (udbg) support for ePAPR hypervisors"
- depends on PPC_EPAPR_HV_BYTECHAN
+ depends on PPC_EPAPR_HV_BYTECHAN=y
help
Select this option to enable early console (a.k.a. "udbg") support
via an ePAPR byte channel. You also need to choose the byte channel
--
1.7.9
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* warnings from drivers/tty/ehv_bytechan.c
From: Stephen Rothwell @ 2012-02-19 20:23 UTC (permalink / raw)
To: Timur Tabi; +Cc: gregkh, ppc-dev
[-- Attachment #1: Type: text/plain, Size: 644 bytes --]
[Resent with Greg's correct new address]
Hi Timur,
If you build drivers/tty/ehv_bytechan.c as a module, it produces these warmings:
drivers/tty/ehv_bytechan.c:362:1: warning: data definition has no type or storage class
drivers/tty/ehv_bytechan.c:362:1: warning: type defaults to 'int' in declaration of 'console_initcall'
drivers/tty/ehv_bytechan.c:362:1: warning: parameter names (without types) in function declaration
drivers/tty/ehv_bytechan.c:334:19: warning: 'ehv_bc_console_init' defined but not used
console_initcall() is not defined for modules.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 6/12] arch/powerpc: remove references to cpu_*_map.
From: Rusty Russell @ 2012-02-19 22:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Venkatesh Pallipadi, linux-kernel, Paul Mackerras,
Srivatsa S. Bhat, akpm@linux-foundation.org, linuxppc-dev
In-Reply-To: <1329362944.3772.45.camel@pasglop>
On Thu, 16 Feb 2012 14:29:04 +1100, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Wed, 2012-02-15 at 14:51 +0530, Srivatsa S. Bhat wrote:
> > On 02/15/2012 10:28 AM, Rusty Russell wrote:
> >
> > > From: Rusty Russell <rusty@rustcorp.com.au>
> > >
> > > This has been obsolescent for a while; time for the final push.
> > >
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Want me to stick that in -powerpc ? If yes, now or -next ?
Please, in -next.
Cheers,
Rusty.
^ permalink raw reply
* [PATCH] powerpc/of: add OF_DYNAMIC for chroma
From: Michael Neuling @ 2012-02-19 22:48 UTC (permalink / raw)
To: Jimi Xenidis, grant.likely; +Cc: linuxppc-dev, linux-next
linux next-20120217 compiling ppc64e_defconfig fails with:
arch/powerpc/platforms/wsp/h8.c: In function 'wsp_h8_getaddr':
arch/powerpc/platforms/wsp/h8.c:116: error: implicit declaration of function 'of_detach_node'
The below fixes this by selecting the new OF_DYNAMIC when PPC_CHROMA.
Signed-off-by: Michael Neuling <mikey@neuling.org>
diff --git a/arch/powerpc/platforms/wsp/Kconfig b/arch/powerpc/platforms/wsp/Kconfig
index 57d22a2..79d2225 100644
--- a/arch/powerpc/platforms/wsp/Kconfig
+++ b/arch/powerpc/platforms/wsp/Kconfig
@@ -25,6 +25,7 @@ config PPC_CHROMA
bool "PowerEN PCIe Chroma Card"
select EPAPR_BOOT
select PPC_WSP
+ select OF_DYNAMIC
default y
endmenu
^ permalink raw reply related
* Re: [RFC PATCH v7 00/10] fadump: Firmware-assisted dump support for Powerpc.
From: Paul Mackerras @ 2012-02-19 23:47 UTC (permalink / raw)
To: Mahesh J Salgaonkar
Cc: Anton Blanchard, Amerigo Wang, Kexec-ml, Linux Kernel,
Milton Miller, linuxppc-dev, Randy Dunlap, Eric W. Biederman,
Vivek Goyal
In-Reply-To: <20120216111050.4733.38034.stgit@mars>
On Thu, Feb 16, 2012 at 04:44:06PM +0530, Mahesh J Salgaonkar wrote:
> Please find the version 7 of the patchset that implements firmware-assisted
> dump mechanism to capture kernel crash dump for Powerpc architecture.
> Firmware-assisted dump is a robust mechanism to get reliable kernel crash
> dump with the assistance of firmware. This approach does not use kexec,
> instead firmware assists in booting the kdump kernel while preserving memory
> contents.
For the series:
Reviewed-by: Paul Mackerras <paulus@samba.org>
I think it's pretty much good enough to go in now. I have one relatively
minor comment about a printk which could be addressed if you decide to
do another version of the series.
Paul.
^ permalink raw reply
* Re: [RFC PATCH v7 03/10] fadump: Register for firmware assisted dump.
From: Paul Mackerras @ 2012-02-20 0:02 UTC (permalink / raw)
To: Mahesh J Salgaonkar
Cc: Anton Blanchard, Amerigo Wang, Kexec-ml, Linux Kernel,
Milton Miller, linuxppc-dev, Randy Dunlap, Eric W. Biederman,
Vivek Goyal
In-Reply-To: <20120216111429.4733.24480.stgit@mars>
On Thu, Feb 16, 2012 at 04:44:30PM +0530, Mahesh J Salgaonkar wrote:
> +/*
> + * Prepare for firmware-assisted dump.
> + */
> +int __init setup_fadump(void)
> +{
> + if (!fw_dump.fadump_supported) {
> + printk(KERN_ERR "Firmware-assisted dump is not supported on"
> + " this hardware\n");
> + return 0;
> + }
> +
> + fadump_show_config();
> + /* Initialize the kernel dump memory structure for FAD registration. */
> + if (fw_dump.reserve_dump_area_size)
> + init_fadump_mem_struct(&fdm, fw_dump.reserve_dump_area_start);
> + fadump_init_files();
> +
> + return 1;
> +}
> +subsys_initcall(setup_fadump);
If I have read the code correctly, we are going to get this printk on
non-pSeries machines or on older pSeries machines, even if the user
has not put the fadump=on option on the kernel command line. The
printk will be annoying since there is no actual error condition. It
seems to me that the condition for the printk should include
fw_dump.fadump_enabled. In other words you should probably add
if (!fw_dump.fadump_enabled)
return 0;
at the beginning of the function.
Paul.
^ permalink raw reply
* Re: [PATCH] params: Fix parse_args() use in PowerPC's reserve_hugetlb_gpages()
From: Rusty Russell @ 2012-02-20 1:26 UTC (permalink / raw)
To: Pawel Moll
Cc: Stephen Rothwell, Michael Neuling, Pawel Moll, linuxppc-dev,
linux-next, McClintock Matthew-B29882
In-Reply-To: <1329494916-20575-1-git-send-email-pawel.moll@arm.com>
On Fri, 17 Feb 2012 16:08:36 +0000, Pawel Moll <pawel.moll@arm.com> wrote:
> Commit b8076966e8e1 ("params: <level>_initcall-like kernel parameters")
> changed the parse_args() API without fixing all the callers. Done now.
>
> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Thanks Stephen, Pawel.
Applied,
Rusty.
^ permalink raw reply
* RE: [PATCH V2 RESEND] fsl-sata: I/O load balancing
From: Zang Roy-R61911 @ 2012-02-20 4:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Li Yang-R58472
Cc: linux-ide@vger.kernel.org, Liu Qiang-B32616, jgarzik@pobox.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <1329448724.2892.43.camel@pasglop>
> -----Original Message-----
> From: linuxppc-dev-bounces+tie-fei.zang=3Dfreescale.com@lists.ozlabs.org
> [mailto:linuxppc-dev-bounces+tie-fei.zang=3Dfreescale.com@lists.ozlabs.or=
g]
> On Behalf Of Benjamin Herrenschmidt
> Sent: Friday, February 17, 2012 11:19 AM
> To: Li Yang-R58472
> Cc: Liu Qiang-B32616; jgarzik@pobox.com; linuxppc-dev@lists.ozlabs.org;
> linux-kernel@vger.kernel.org; linux-ide@vger.kernel.org
> Subject: RE: [PATCH V2 RESEND] fsl-sata: I/O load balancing
>=20
> On Fri, 2012-02-17 at 03:09 +0000, Li Yang-R58472 wrote:
> > >I tried a debian install on the p5020ds here and I find SATA to be
> > >extremely slow, generating millions of interrupts. I think the
> > defaults
> > >should be a lot more aggressive at coalescing.
> >
> > The P5020 has a hardware problem with SATA, making it generate more
> > interrupts than it should. A new revision of the silicon will fix it.
>=20
> Ok cool. With a bit of luck you guys can send me a new silicon when it's
> available then :-) (The one in the board you got me seems to be in a
> socket).
Ben,
We still do not have the a P5020 sample to fix the problem.
One workaround is to use the patch ( I think you have noticed the patch):
http://git.freescale.com/git/cgit.cgi/ppc/sdk/linux.git/commit/?id=3D92c0ce=
1e599e788ffc0908739db9bd5e0dbdad69
and use a SSD hard drive.
It will have a usable performance.
Thanks.
Roy
^ permalink raw reply
* Re: [PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32
From: Suzuki K. Poulose @ 2012-02-20 10:31 UTC (permalink / raw)
To: Atsushi Kumagai; +Cc: kexec, linuxppc-dev
In-Reply-To: <20120220185601.d08b8864.kumagai-atsushi@mxc.nes.nec.co.jp>
On 02/20/2012 03:26 PM, Atsushi Kumagai wrote:
> Hi, Benjamin
> Hi, Suzuki
>
> On Fri, 17 Feb 2012 19:39:29 +1100
> Benjamin Herrenschmidt<benh@kernel.crashing.org> wrote:
>
>> On Fri, 2012-02-17 at 11:25 +0530, Suzuki K. Poulose wrote:
>>>> Could you tell me what kind of data is stored in vmalloc region in
>>> PPC ?
>>>> I want to estimate importance of your patches for makedumpfile.
>>> I know at least the modules are loaded in the vmalloc'd region. I have
>>> Cc'ed linux-ppc dev. We should be able to get enough info from the
>>> experts here.
>>>
>>> Josh / Kumar / Others,
>>>
>>> Could you please let us know your thoughts ?
>>
>> Modules, driver IO mappings, etc... I can see that being useful for
>> crashdumps.
>
> Thank you for your information.
>
> The above data may be required for one function of makedumpfile (filter
> out kernel data) but not so crucial for makedumpfile as page descriptors
> and related data(e.g. pglist_data).
>
> Moreover, I'm preparing the release of v1.4.3 now, so I'll merge vmalloc
> support for PPC32 into v1.4.4. Is it all right for you, Suzuki ?
Yep, fine with me.
Thanks
Suzuki
^ permalink raw reply
* Re: [PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32
From: Atsushi Kumagai @ 2012-02-20 9:56 UTC (permalink / raw)
To: benh, suzuki; +Cc: kexec, linuxppc-dev
In-Reply-To: <1329467969.2892.58.camel@pasglop>
Hi, Benjamin
Hi, Suzuki
On Fri, 17 Feb 2012 19:39:29 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Fri, 2012-02-17 at 11:25 +0530, Suzuki K. Poulose wrote:
> > > Could you tell me what kind of data is stored in vmalloc region in
> > PPC ?
> > > I want to estimate importance of your patches for makedumpfile.
> > I know at least the modules are loaded in the vmalloc'd region. I have
> > Cc'ed linux-ppc dev. We should be able to get enough info from the
> > experts here.
> >
> > Josh / Kumar / Others,
> >
> > Could you please let us know your thoughts ?
>
> Modules, driver IO mappings, etc... I can see that being useful for
> crashdumps.
Thank you for your information.
The above data may be required for one function of makedumpfile (filter
out kernel data) but not so crucial for makedumpfile as page descriptors
and related data(e.g. pglist_data).
Moreover, I'm preparing the release of v1.4.3 now, so I'll merge vmalloc
support for PPC32 into v1.4.4. Is it all right for you, Suzuki ?
Thanks
Atsushi Kumagai
^ permalink raw reply
* Re: [PATCH 13/30] KVM: PPC: booke: category E.HV (GS-mode) support
From: Alexander Graf @ 2012-02-20 11:40 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <4F3EC2A1.7080702@freescale.com>
On 17.02.2012, at 22:12, Scott Wood wrote:
> On 02/17/2012 11:13 AM, Alexander Graf wrote:
>> From: Scott Wood <scottwood@freescale.com>
>>=20
>> Chips such as e500mc that implement category E.HV in Power ISA 2.06
>> provide hardware virtualization features, including a new MSR mode =
for
>> guest state. The guest OS can perform many operations without =
trapping
>> into the hypervisor, including transitions to and from guest =
userspace.
>>=20
>> Since we can use SRR1[GS] to reliably tell whether an exception came =
from
>> guest state, instead of messing around with IVPR, we use DO_KVM =
similarly
>> to book3s.
>>=20
>> Current issues include:
>> - Machine checks from guest state are not routed to the host handler.
>> - The guest can cause a host oops by executing an emulated =
instruction
>> in a page that lacks read permission. Existing e500/4xx support =
has
>> the same problem.
>>=20
>> Includes work by Ashish Kalra <Ashish.Kalra@freescale.com>,
>> Varun Sethi <Varun.Sethi@freescale.com>, and
>> Liu Yu <yu.liu@freescale.com>.
>>=20
>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>> [agraf: remove pt_regs usage]
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> ---
>=20
> Thanks for picking this up!
>=20
>> +static unsigned long get_guest_esr(struct kvm_vcpu *vcpu)
>> +{
>> +#ifdef CONFIG_KVM_BOOKE_HV
>> + return mfspr(SPRN_ESR);
>> +#else
>> + return vcpu->arch.shared->esr;
>> +#endif
>> +}
>=20
> s/SPRN_ESR/SPRN_GESR/
Ouch :)
>=20
>> int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
>> unsigned int exit_nr)
>> {
>> - enum emulation_result er;
>> int r =3D RESUME_HOST;
>>=20
>> /* update before a new last_exit_type is rewritten */
>> kvmppc_update_timing_stats(vcpu);
>>=20
>> + switch (exit_nr) {
>> + case BOOKE_INTERRUPT_EXTERNAL:
>> + do_IRQ(current->thread.regs);
>> + break;
>=20
> What will current->thread.regs point to here? Something on the stack
> from the last normal host exception entry?
Yup. Regs only contains a few register values of volatile state that we =
shouldn't care about at this point anyways, right?
> We probably want to create a pt_regs on the stack and at least provide
> PC, LR, and r1 for perfmon interrupts and such.
We don't want guest information to leak into the host kernel, do we? =
=46rom the host's POV, any exit inside the guest happens right at the =
guest exit path of KVM.
The way we handle this on book3s is that we actually jump right into the =
real handler from asm code, right when we recovered all the MMU state. =
We could do the same here - basically move this whole thing off to asm =
code and jump right to the actual interrupt handler, not the above =
do_IRQ implementation.
Then register state in regs would also be guaranteed to be sane, since =
it's created by the interrupt handler itself.
>=20
>> @@ -384,30 +558,56 @@ int kvmppc_handle_exit(struct kvm_run *run, =
struct kvm_vcpu *vcpu,
>>=20
>> switch (exit_nr) {
>> case BOOKE_INTERRUPT_MACHINE_CHECK:
>> - printk("MACHINE CHECK: %lx\n", mfspr(SPRN_MCSR));
>> - kvmppc_dump_vcpu(vcpu);
>> - r =3D RESUME_HOST;
>> + kvm_resched(vcpu);
>> + r =3D RESUME_GUEST;
>> break;
>=20
> Leave this bit out (proper machine check handling will come later).
Ok, I'll readd it with a later patch on top that also sets =
run->hw.hardware_exit_reason to something debugg'y, so user space can =
abort.
>=20
>> case BOOKE_INTERRUPT_PROGRAM:
>> - if (vcpu->arch.shared->msr & MSR_PR) {
>> + if (vcpu->arch.shared->msr & (MSR_PR | MSR_GS)) {
>> /* Program traps generated by user-level =
software must be handled
>> * by the guest kernel. */
>> kvmppc_core_queue_program(vcpu, =
vcpu->arch.fault_esr);
>=20
> Should update the comment for why we're checking GS (i.e. we get a
> different trap for emulation with GS-mode).
k
>=20
>> +#define SET_VCPU(vcpu) \
>> + PPC_STL vcpu, (THREAD + THREAD_KVM_VCPU)(r2)
>=20
> Change spaces to tab before PPC_STL
The whole thing gets removed a few patches later.
>=20
>> +#define LONGBYTES (BITS_PER_LONG / 8)
>> +
>> +#define VCPU_GPR(n) (VCPU_GPRS + (n * LONGBYTES))
>> +#define VCPU_GUEST_SPRG(n) (VCPU_GUEST_SPRGS + (n * LONGBYTES))
>> +
>> +/* The host stack layout: */
>> +#define HOST_R1 (0 * LONGBYTES) /* Implied by stwu. */
>> +#define HOST_CALLEE_LR (1 * LONGBYTES)
>> +#define HOST_RUN (2 * LONGBYTES) /* struct kvm_run */
>> +/*
>> + * r2 is special: it holds 'current', and it made nonvolatile in the
>> + * kernel with the -ffixed-r2 gcc option.
>> + */
>> +#define HOST_R2 (3 * LONGBYTES)
>> +#define HOST_NV_GPRS (4 * LONGBYTES)
>> +#define HOST_NV_GPR(n) (HOST_NV_GPRS + ((n - 14) * LONGBYTES))
>> +#define HOST_MIN_STACK_SIZE (HOST_NV_GPR(31) + LONGBYTES)
>> +#define HOST_STACK_SIZE ((HOST_MIN_STACK_SIZE + 15) & ~15) /* Align. =
*/
>> +#define HOST_STACK_LR (HOST_STACK_SIZE + LONGBYTES) /* In caller =
stack frame. */
>> +
>> +#define NEED_EMU 0x00000001 /* emulation -- save nv regs =
*/
>> +#define NEED_DEAR 0x00000002 /* save faulting DEAR */
>> +#define NEED_ESR 0x00000004 /* save faulting ESR */
>> +
>> +/*
>> + * On entry:
>> + * r4 =3D vcpu, r5 =3D srr0, r6 =3D srr1
>> + * saved in vcpu: cr, ctr, r3-r13
>> + */
>> +.macro kvm_handler_common intno, srr0, flags
>> + mfspr r10, SPRN_PID
>> + lwz r8, VCPU_HOST_PID(r4)
>> + PPC_LL r11, VCPU_SHARED(r4)
>> + PPC_STL r14, VCPU_GPR(r14)(r4) /* We need a non-volatile GPR. */
>> + li r14, \intno
>> +
>> + stw r10, VCPU_GUEST_PID(r4)
>> + mtspr SPRN_PID, r8
>> +
>> + .if \flags & NEED_EMU
>> + lwz r9, VCPU_KVM(r4)
>> + .endif
>> +
>> +#ifdef CONFIG_KVM_EXIT_TIMING
>> + /* save exit time */
>> +1: mfspr r7, SPRN_TBRU
>> + mfspr r8, SPRN_TBRL
>> + mfspr r9, SPRN_TBRU
>> + cmpw r9, r7
>> + PPC_STL r8, VCPU_TIMING_EXIT_TBL(r4)
>> + bne- 1b
>> + PPC_STL r9, VCPU_TIMING_EXIT_TBU(r4)
>> +#endif
>=20
> As you pointed out to me last time, r9 is clobbered if exit timing is
> enabled (but see below, the load of VCPU_KVM can be removed along with
> the subsequent load of LVM_LPID(r9)).
Yes, fixed a few patches later. I went with the "put patches on top of =
your patches" style instead of rebasing and modifying your patches too =
much, so that it's easier for you guys to integrate this downstream.
>=20
>> + oris r8, r6, MSR_CE@h
>> +#ifndef CONFIG_64BIT
>> + stw r6, (VCPU_SHARED_MSR + 4)(r11)
>> +#else
>> + std r6, (VCPU_SHARED_MSR)(r11)
>> +#endif
>> + ori r8, r8, MSR_ME | MSR_RI
>> + PPC_STL r5, VCPU_PC(r4)
>> +
>> + /*
>> + * Make sure CE/ME/RI are set (if appropriate for exception =
type)
>> + * whether or not the guest had it set. Since mfmsr/mtmsr are
>> + * somewhat expensive, skip in the common case where the guest
>> + * had all these bits set (and thus they're still set if
>> + * appropriate for the exception type).
>> + */
>> + cmpw r6, r8
>> + .if \flags & NEED_EMU
>> + lwz r9, KVM_LPID(r9)
>> + .endif
>=20
> Where do we use r9? This is probably left over from something old.
Looks like it, yup.
Alex
^ permalink raw reply
* Re: [PATCH 16/30] KVM: PPC: e500mc: Add doorbell emulation support
From: Alexander Graf @ 2012-02-20 11:49 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <4F3ECCE6.2010503@freescale.com>
On 17.02.2012, at 22:55, Scott Wood wrote:
> On 02/17/2012 11:13 AM, Alexander Graf wrote:
>> When one vcpu wants to kick another, it can issue a special IPI =
instruction
>> called msgsnd. This patch emulates this instruction, its clearing =
counterpart
>> and the infrastructure required to actually trigger that interrupt =
inside
>> a guest vcpu.
>>=20
>> With this patch, SMP guests on e500mc work.
>>=20
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> ---
>> arch/powerpc/kvm/booke.c | 6 +++
>> arch/powerpc/kvm/e500_emulate.c | 68 =
+++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 74 insertions(+), 0 deletions(-)
>>=20
>> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
>> index 3dd200d..ce1599d 100644
>> --- a/arch/powerpc/kvm/booke.c
>> +++ b/arch/powerpc/kvm/booke.c
>> @@ -326,6 +326,9 @@ static int kvmppc_booke_irqprio_deliver(struct =
kvm_vcpu *vcpu,
>> int_class =3D INT_CLASS_NONCRIT;
>> break;
>> case BOOKE_IRQPRIO_CRITICAL:
>> +#ifdef CONFIG_KVM_E500MC
>> + case BOOKE_IRQPRIO_DBELL_CRIT:
>> +#endif
>> allowed =3D vcpu->arch.shared->msr & MSR_CE;
>> allowed =3D allowed && !crit;
>> msr_mask =3D MSR_GS | MSR_ME;
>> @@ -342,6 +345,9 @@ static int kvmppc_booke_irqprio_deliver(struct =
kvm_vcpu *vcpu,
>> keep_irq =3D true;
>> /* fall through */
>> case BOOKE_IRQPRIO_EXTERNAL:
>> +#ifdef CONFIG_KVM_E500MC
>> + case BOOKE_IRQPRIO_DBELL:
>> +#endif
>=20
> This isn't e500mc specific -- it's in the ISA as "Embedded.Processor
> Control".
>=20
> Any harm in just removing the ifdef (similar to tlbilx)?
Well, to me this is more of an indication "this should become a runtime =
check one day" in case we want to combine the two targets. On e500v2, we =
don't know what a doorbell interrupt is, so we really shouldn't be =
delivering one either.
>=20
>> allowed =3D vcpu->arch.shared->msr & MSR_EE;
>> allowed =3D allowed && !crit;
>> msr_mask =3D MSR_GS | MSR_CE | MSR_ME | MSR_DE;
>> diff --git a/arch/powerpc/kvm/e500_emulate.c =
b/arch/powerpc/kvm/e500_emulate.c
>> index 98b6c1c..29d5604 100644
>> --- a/arch/powerpc/kvm/e500_emulate.c
>> +++ b/arch/powerpc/kvm/e500_emulate.c
>> @@ -14,16 +14,74 @@
>>=20
>> #include <asm/kvm_ppc.h>
>> #include <asm/disassemble.h>
>> +#include <asm/dbell.h>
>>=20
>> #include "booke.h"
>> #include "e500.h"
>>=20
>> +#define XOP_MSGSND 206
>> +#define XOP_MSGCLR 238
>> #define XOP_TLBIVAX 786
>> #define XOP_TLBSX 914
>> #define XOP_TLBRE 946
>> #define XOP_TLBWE 978
>> #define XOP_TLBILX 18
>>=20
>> +#ifdef CONFIG_KVM_E500MC
>> +static int dbell2prio(ulong param)
>> +{
>> + int msg =3D param & PPC_DBELL_TYPE(-1);
>=20
> Maybe introduce PPC_DBELL_TYPE_MASK or GET_PPC_DBELL_TYPE?
TYPE_MASK I'd say.
>=20
>> + int prio =3D -1;
>> +
>> + switch (msg) {
>> + case PPC_DBELL_TYPE(PPC_DBELL):
>> + prio =3D BOOKE_IRQPRIO_DBELL;
>> + break;
>> + case PPC_DBELL_TYPE(PPC_DBELL_CRIT):
>> + prio =3D BOOKE_IRQPRIO_DBELL_CRIT;
>> + break;
>> + default:
>> + break;
>> + }
>> +
>> + return prio;
>> +}
>> +
>> +static int kvmppc_e500_emul_msgclr(struct kvm_vcpu *vcpu, int rb)
>> +{
>> + ulong param =3D vcpu->arch.gpr[rb];
>> + int prio =3D dbell2prio(param);
>> +
>> + if (prio < 0)
>> + return EMULATE_FAIL;
>> +
>> + clear_bit(prio, &vcpu->arch.pending_exceptions);
>> + return EMULATE_DONE;
>> +}
>> +
>> +static int kvmppc_e500_emul_msgsnd(struct kvm_vcpu *vcpu, int rb)
>> +{
>> + ulong param =3D vcpu->arch.gpr[rb];
>> + int prio =3D dbell2prio(rb);
>> + int pir =3D param & 0x3fff;
>=20
> Introduce PPC_DBELL_PIR_MASK or GET_PPC_DBELL_PIR?
Good point :)
>=20
>> + int i;
>> + struct kvm_vcpu *cvcpu;
>> +
>> + if (prio < 0)
>> + return EMULATE_FAIL;
>> +
>> + kvm_for_each_vcpu(i, cvcpu, vcpu->kvm) {
>> + int cpir =3D cvcpu->arch.shared->pir;
>> + if ((param & PPC_DBELL_MSG_BRDCAST) || (cpir =3D=3D =
pir)) {
>> + set_bit(prio, &cvcpu->arch.pending_exceptions);
>> + kvm_vcpu_kick(cvcpu);
>> + }
>> + }
>=20
> Should this be a kvm_make_request instead (with a separate
> pending_doorbell bool in vcpu that msgclr can act on), considering
> earlier discussion of phasing out atomics on pending_exceptions, in
> favor of requests?
Yeah, I was thinking about that too, but right now we already have some =
direct use of pending_exceptions in different places around the code. So =
today, that is our public interface.
I'd rather go in and clean up the whole thing to make pending_exceptions =
private in a separate cleanup round, rather than having it part of =
e500mc support.
Alex
^ permalink raw reply
* Re: [UPDATED] [RFC PATCH v7 03/10] fadump: Register for firmware assisted dump.
From: Mahesh J Salgaonkar @ 2012-02-20 12:15 UTC (permalink / raw)
To: Paul Mackerras
Cc: Anton Blanchard, Amerigo Wang, Kexec-ml, Linux Kernel,
Milton Miller, linuxppc-dev, Randy Dunlap, Eric W. Biederman,
Vivek Goyal
In-Reply-To: <20120220000250.GB10186@bloggs.ozlabs.ibm.com>
On 2012-02-20 11:02:51 Mon, Paul Mackerras wrote:
> On Thu, Feb 16, 2012 at 04:44:30PM +0530, Mahesh J Salgaonkar wrote:
>
> If I have read the code correctly, we are going to get this printk on
> non-pSeries machines or on older pSeries machines, even if the user
> has not put the fadump=on option on the kernel command line. The
> printk will be annoying since there is no actual error condition. It
> seems to me that the condition for the printk should include
> fw_dump.fadump_enabled. In other words you should probably add
>
> if (!fw_dump.fadump_enabled)
> return 0;
>
> at the beginning of the function.
Hi Paul,
Thanks for pointing it out. Please find the updated patch below.
The existing patches above this (4/10 through 10/10) cleanly applies
on this update.
Thanks,
-Mahesh.
---
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
This patch registers for firmware-assisted dump using rtas token
ibm,configure-kernel-dump. During registration firmware is informed about
the reserved area where it saves the CPU state data, HPTE table and contents
of RMR region at the time of kernel crash. Apart from this, firmware also
preserves the contents of entire partition memory even if it is not specified
during registration.
This patch also populates sysfs files under /sys/kernel to display
fadump status and reserved memory regions.
This patch introduces fadump_registered sysfs control file which will be
used by kdump init scripts to start/stop firmware assisted dump. echo 1 to
/sys/kernel/fadump_registered file for fadump registration and
echo 0 to /sys/kernel/fadump_registered file for fadump un-registration.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/fadump.h | 57 ++++++
arch/powerpc/kernel/fadump.c | 355 +++++++++++++++++++++++++++++++++++++
arch/powerpc/kernel/iommu.c | 8 +
arch/powerpc/mm/hash_utils_64.c | 11 +
4 files changed, 427 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/fadump.h b/arch/powerpc/include/asm/fadump.h
index 7be25d3..bbaf278 100644
--- a/arch/powerpc/include/asm/fadump.h
+++ b/arch/powerpc/include/asm/fadump.h
@@ -48,6 +48,58 @@
#define FADUMP_HPTE_REGION 0x0002
#define FADUMP_REAL_MODE_REGION 0x0011
+/* Dump request flag */
+#define FADUMP_REQUEST_FLAG 0x00000001
+
+/* FAD commands */
+#define FADUMP_REGISTER 1
+#define FADUMP_UNREGISTER 2
+#define FADUMP_INVALIDATE 3
+
+/* Kernel Dump section info */
+struct fadump_section {
+ u32 request_flag;
+ u16 source_data_type;
+ u16 error_flags;
+ u64 source_address;
+ u64 source_len;
+ u64 bytes_dumped;
+ u64 destination_address;
+};
+
+/* ibm,configure-kernel-dump header. */
+struct fadump_section_header {
+ u32 dump_format_version;
+ u16 dump_num_sections;
+ u16 dump_status_flag;
+ u32 offset_first_dump_section;
+
+ /* Fields for disk dump option. */
+ u32 dd_block_size;
+ u64 dd_block_offset;
+ u64 dd_num_blocks;
+ u32 dd_offset_disk_path;
+
+ /* Maximum time allowed to prevent an automatic dump-reboot. */
+ u32 max_time_auto;
+};
+
+/*
+ * Firmware Assisted dump memory structure. This structure is required for
+ * registering future kernel dump with power firmware through rtas call.
+ *
+ * No disk dump option. Hence disk dump path string section is not included.
+ */
+struct fadump_mem_struct {
+ struct fadump_section_header header;
+
+ /* Kernel dump sections */
+ struct fadump_section cpu_state_data;
+ struct fadump_section hpte_region;
+ struct fadump_section rmr_region;
+};
+
+/* Firmware-assisted dump configuration details. */
struct fw_dump {
unsigned long cpu_state_data_size;
unsigned long hpte_region_size;
@@ -62,10 +114,15 @@ struct fw_dump {
unsigned long fadump_enabled:1;
unsigned long fadump_supported:1;
unsigned long dump_active:1;
+ unsigned long dump_registered:1;
};
extern int early_init_dt_scan_fw_dump(unsigned long node,
const char *uname, int depth, void *data);
extern int fadump_reserve_mem(void);
+extern int setup_fadump(void);
+extern int is_fadump_active(void);
+#else /* CONFIG_FA_DUMP */
+static inline int is_fadump_active(void) { return 0; }
#endif
#endif
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index deb276a..eb8f782 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -29,6 +29,9 @@
#include <linux/string.h>
#include <linux/memblock.h>
+#include <linux/delay.h>
+#include <linux/debugfs.h>
+#include <linux/seq_file.h>
#include <asm/page.h>
#include <asm/prom.h>
@@ -36,6 +39,10 @@
#include <asm/fadump.h>
static struct fw_dump fw_dump;
+static struct fadump_mem_struct fdm;
+static const struct fadump_mem_struct *fdm_active;
+
+static DEFINE_MUTEX(fadump_mutex);
/* Scan the Firmware Assisted dump configuration details. */
int __init early_init_dt_scan_fw_dump(unsigned long node,
@@ -64,7 +71,8 @@ int __init early_init_dt_scan_fw_dump(unsigned long node,
* The 'ibm,kernel-dump' rtas node is present only if there is
* dump data waiting for us.
*/
- if (of_get_flat_dt_prop(node, "ibm,kernel-dump", NULL))
+ fdm_active = of_get_flat_dt_prop(node, "ibm,kernel-dump", NULL);
+ if (fdm_active)
fw_dump.dump_active = 1;
/* Get the sizes required to store dump data for the firmware provided
@@ -98,6 +106,85 @@ int __init early_init_dt_scan_fw_dump(unsigned long node,
return 1;
}
+int is_fadump_active(void)
+{
+ return fw_dump.dump_active;
+}
+
+/* Print firmware assisted dump configurations for debugging purpose. */
+static void fadump_show_config(void)
+{
+ pr_debug("Support for firmware-assisted dump (fadump): %s\n",
+ (fw_dump.fadump_supported ? "present" : "no support"));
+
+ if (!fw_dump.fadump_supported)
+ return;
+
+ pr_debug("Fadump enabled : %s\n",
+ (fw_dump.fadump_enabled ? "yes" : "no"));
+ pr_debug("Dump Active : %s\n",
+ (fw_dump.dump_active ? "yes" : "no"));
+ pr_debug("Dump section sizes:\n");
+ pr_debug(" CPU state data size: %lx\n", fw_dump.cpu_state_data_size);
+ pr_debug(" HPTE region size : %lx\n", fw_dump.hpte_region_size);
+ pr_debug("Boot memory size : %lx\n", fw_dump.boot_memory_size);
+}
+
+static unsigned long init_fadump_mem_struct(struct fadump_mem_struct *fdm,
+ unsigned long addr)
+{
+ if (!fdm)
+ return 0;
+
+ memset(fdm, 0, sizeof(struct fadump_mem_struct));
+ addr = addr & PAGE_MASK;
+
+ fdm->header.dump_format_version = 0x00000001;
+ fdm->header.dump_num_sections = 3;
+ fdm->header.dump_status_flag = 0;
+ fdm->header.offset_first_dump_section =
+ (u32)offsetof(struct fadump_mem_struct, cpu_state_data);
+
+ /*
+ * Fields for disk dump option.
+ * We are not using disk dump option, hence set these fields to 0.
+ */
+ fdm->header.dd_block_size = 0;
+ fdm->header.dd_block_offset = 0;
+ fdm->header.dd_num_blocks = 0;
+ fdm->header.dd_offset_disk_path = 0;
+
+ /* set 0 to disable an automatic dump-reboot. */
+ fdm->header.max_time_auto = 0;
+
+ /* Kernel dump sections */
+ /* cpu state data section. */
+ fdm->cpu_state_data.request_flag = FADUMP_REQUEST_FLAG;
+ fdm->cpu_state_data.source_data_type = FADUMP_CPU_STATE_DATA;
+ fdm->cpu_state_data.source_address = 0;
+ fdm->cpu_state_data.source_len = fw_dump.cpu_state_data_size;
+ fdm->cpu_state_data.destination_address = addr;
+ addr += fw_dump.cpu_state_data_size;
+
+ /* hpte region section */
+ fdm->hpte_region.request_flag = FADUMP_REQUEST_FLAG;
+ fdm->hpte_region.source_data_type = FADUMP_HPTE_REGION;
+ fdm->hpte_region.source_address = 0;
+ fdm->hpte_region.source_len = fw_dump.hpte_region_size;
+ fdm->hpte_region.destination_address = addr;
+ addr += fw_dump.hpte_region_size;
+
+ /* RMA region section */
+ fdm->rmr_region.request_flag = FADUMP_REQUEST_FLAG;
+ fdm->rmr_region.source_data_type = FADUMP_REAL_MODE_REGION;
+ fdm->rmr_region.source_address = RMA_START;
+ fdm->rmr_region.source_len = fw_dump.boot_memory_size;
+ fdm->rmr_region.destination_address = addr;
+ addr += fw_dump.boot_memory_size;
+
+ return addr;
+}
+
/**
* fadump_calculate_reserve_size(): reserve variable boot area 5% of System RAM
*
@@ -166,8 +253,15 @@ int __init fadump_reserve_mem(void)
fw_dump.fadump_enabled = 0;
return 0;
}
- /* Initialize boot memory size */
- fw_dump.boot_memory_size = fadump_calculate_reserve_size();
+ /*
+ * Initialize boot memory size
+ * If dump is active then we have already calculated the size during
+ * first kernel.
+ */
+ if (fdm_active)
+ fw_dump.boot_memory_size = fdm_active->rmr_region.source_len;
+ else
+ fw_dump.boot_memory_size = fadump_calculate_reserve_size();
/*
* Calculate the memory boundary.
@@ -244,3 +338,258 @@ static int __init early_fadump_reserve_mem(char *p)
return 0;
}
early_param("fadump_reserve_mem", early_fadump_reserve_mem);
+
+static void register_fw_dump(struct fadump_mem_struct *fdm)
+{
+ int rc;
+ unsigned int wait_time;
+
+ pr_debug("Registering for firmware-assisted kernel dump...\n");
+
+ /* TODO: Add upper time limit for the delay */
+ do {
+ rc = rtas_call(fw_dump.ibm_configure_kernel_dump, 3, 1, NULL,
+ FADUMP_REGISTER, fdm,
+ sizeof(struct fadump_mem_struct));
+
+ wait_time = rtas_busy_delay_time(rc);
+ if (wait_time)
+ mdelay(wait_time);
+
+ } while (wait_time);
+
+ switch (rc) {
+ case -1:
+ printk(KERN_ERR "Failed to register firmware-assisted kernel"
+ " dump. Hardware Error(%d).\n", rc);
+ break;
+ case -3:
+ printk(KERN_ERR "Failed to register firmware-assisted kernel"
+ " dump. Parameter Error(%d).\n", rc);
+ break;
+ case -9:
+ printk(KERN_ERR "firmware-assisted kernel dump is already "
+ " registered.");
+ fw_dump.dump_registered = 1;
+ break;
+ case 0:
+ printk(KERN_INFO "firmware-assisted kernel dump registration"
+ " is successful\n");
+ fw_dump.dump_registered = 1;
+ break;
+ }
+}
+
+static void register_fadump(void)
+{
+ /*
+ * If no memory is reserved then we can not register for firmware-
+ * assisted dump.
+ */
+ if (!fw_dump.reserve_dump_area_size)
+ return;
+
+ /* register the future kernel dump with firmware. */
+ register_fw_dump(&fdm);
+}
+
+static int fadump_unregister_dump(struct fadump_mem_struct *fdm)
+{
+ int rc = 0;
+ unsigned int wait_time;
+
+ pr_debug("Un-register firmware-assisted dump\n");
+
+ /* TODO: Add upper time limit for the delay */
+ do {
+ rc = rtas_call(fw_dump.ibm_configure_kernel_dump, 3, 1, NULL,
+ FADUMP_UNREGISTER, fdm,
+ sizeof(struct fadump_mem_struct));
+
+ wait_time = rtas_busy_delay_time(rc);
+ if (wait_time)
+ mdelay(wait_time);
+ } while (wait_time);
+
+ if (rc) {
+ printk(KERN_ERR "Failed to un-register firmware-assisted dump."
+ " unexpected error(%d).\n", rc);
+ return rc;
+ }
+ fw_dump.dump_registered = 0;
+ return 0;
+}
+
+static ssize_t fadump_enabled_show(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%d\n", fw_dump.fadump_enabled);
+}
+
+static ssize_t fadump_register_show(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%d\n", fw_dump.dump_registered);
+}
+
+static ssize_t fadump_register_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t count)
+{
+ int ret = 0;
+
+ if (!fw_dump.fadump_enabled || fdm_active)
+ return -EPERM;
+
+ mutex_lock(&fadump_mutex);
+
+ switch (buf[0]) {
+ case '0':
+ if (fw_dump.dump_registered == 0) {
+ ret = -EINVAL;
+ goto unlock_out;
+ }
+ /* Un-register Firmware-assisted dump */
+ fadump_unregister_dump(&fdm);
+ break;
+ case '1':
+ if (fw_dump.dump_registered == 1) {
+ ret = -EINVAL;
+ goto unlock_out;
+ }
+ /* Register Firmware-assisted dump */
+ register_fadump();
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+unlock_out:
+ mutex_unlock(&fadump_mutex);
+ return ret < 0 ? ret : count;
+}
+
+static int fadump_region_show(struct seq_file *m, void *private)
+{
+ const struct fadump_mem_struct *fdm_ptr;
+
+ if (!fw_dump.fadump_enabled)
+ return 0;
+
+ if (fdm_active)
+ fdm_ptr = fdm_active;
+ else
+ fdm_ptr = &fdm;
+
+ seq_printf(m,
+ "CPU : [%#016llx-%#016llx] %#llx bytes, "
+ "Dumped: %#llx\n",
+ fdm_ptr->cpu_state_data.destination_address,
+ fdm_ptr->cpu_state_data.destination_address +
+ fdm_ptr->cpu_state_data.source_len - 1,
+ fdm_ptr->cpu_state_data.source_len,
+ fdm_ptr->cpu_state_data.bytes_dumped);
+ seq_printf(m,
+ "HPTE: [%#016llx-%#016llx] %#llx bytes, "
+ "Dumped: %#llx\n",
+ fdm_ptr->hpte_region.destination_address,
+ fdm_ptr->hpte_region.destination_address +
+ fdm_ptr->hpte_region.source_len - 1,
+ fdm_ptr->hpte_region.source_len,
+ fdm_ptr->hpte_region.bytes_dumped);
+ seq_printf(m,
+ "DUMP: [%#016llx-%#016llx] %#llx bytes, "
+ "Dumped: %#llx\n",
+ fdm_ptr->rmr_region.destination_address,
+ fdm_ptr->rmr_region.destination_address +
+ fdm_ptr->rmr_region.source_len - 1,
+ fdm_ptr->rmr_region.source_len,
+ fdm_ptr->rmr_region.bytes_dumped);
+
+ if (!fdm_active ||
+ (fw_dump.reserve_dump_area_start ==
+ fdm_ptr->cpu_state_data.destination_address))
+ return 0;
+
+ /* Dump is active. Show reserved memory region. */
+ seq_printf(m,
+ " : [%#016llx-%#016llx] %#llx bytes, "
+ "Dumped: %#llx\n",
+ (unsigned long long)fw_dump.reserve_dump_area_start,
+ fdm_ptr->cpu_state_data.destination_address - 1,
+ fdm_ptr->cpu_state_data.destination_address -
+ fw_dump.reserve_dump_area_start,
+ fdm_ptr->cpu_state_data.destination_address -
+ fw_dump.reserve_dump_area_start);
+ return 0;
+}
+
+static struct kobj_attribute fadump_attr = __ATTR(fadump_enabled,
+ 0444, fadump_enabled_show,
+ NULL);
+static struct kobj_attribute fadump_register_attr = __ATTR(fadump_registered,
+ 0644, fadump_register_show,
+ fadump_register_store);
+
+static int fadump_region_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, fadump_region_show, inode->i_private);
+}
+
+static const struct file_operations fadump_region_fops = {
+ .open = fadump_region_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+static void fadump_init_files(void)
+{
+ struct dentry *debugfs_file;
+ int rc = 0;
+
+ rc = sysfs_create_file(kernel_kobj, &fadump_attr.attr);
+ if (rc)
+ printk(KERN_ERR "fadump: unable to create sysfs file"
+ " fadump_enabled (%d)\n", rc);
+
+ rc = sysfs_create_file(kernel_kobj, &fadump_register_attr.attr);
+ if (rc)
+ printk(KERN_ERR "fadump: unable to create sysfs file"
+ " fadump_registered (%d)\n", rc);
+
+ debugfs_file = debugfs_create_file("fadump_region", 0444,
+ powerpc_debugfs_root, NULL,
+ &fadump_region_fops);
+ if (!debugfs_file)
+ printk(KERN_ERR "fadump: unable to create debugfs file"
+ " fadump_region\n");
+ return;
+}
+
+/*
+ * Prepare for firmware-assisted dump.
+ */
+int __init setup_fadump(void)
+{
+ if (!fw_dump.fadump_enabled)
+ return 0;
+
+ if (!fw_dump.fadump_supported) {
+ printk(KERN_ERR "Firmware-assisted dump is not supported on"
+ " this hardware\n");
+ return 0;
+ }
+
+ fadump_show_config();
+ /* Initialize the kernel dump memory structure for FAD registration. */
+ if (fw_dump.reserve_dump_area_size)
+ init_fadump_mem_struct(&fdm, fw_dump.reserve_dump_area_start);
+ fadump_init_files();
+
+ return 1;
+}
+subsys_initcall(setup_fadump);
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 0cfcf98..359f078 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -39,6 +39,7 @@
#include <asm/pci-bridge.h>
#include <asm/machdep.h>
#include <asm/kdump.h>
+#include <asm/fadump.h>
#define DBG(...)
@@ -445,7 +446,12 @@ void iommu_unmap_sg(struct iommu_table *tbl, struct scatterlist *sglist,
static void iommu_table_clear(struct iommu_table *tbl)
{
- if (!is_kdump_kernel()) {
+ /*
+ * In case of firmware assisted dump system goes through clean
+ * reboot process at the time of system crash. Hence it's safe to
+ * clear the TCE entries if firmware assisted dump is active.
+ */
+ if (!is_kdump_kernel() || is_fadump_active()) {
/* Clear the table in case firmware left allocations in it */
ppc_md.tce_free(tbl, tbl->it_offset, tbl->it_size);
return;
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 2d28218..b534bba 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -55,6 +55,7 @@
#include <asm/spu.h>
#include <asm/udbg.h>
#include <asm/code-patching.h>
+#include <asm/fadump.h>
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
@@ -625,6 +626,16 @@ static void __init htab_initialize(void)
/* Using a hypervisor which owns the htab */
htab_address = NULL;
_SDR1 = 0;
+#ifdef CONFIG_FA_DUMP
+ /*
+ * If firmware assisted dump is active firmware preserves
+ * the contents of htab along with entire partition memory.
+ * Clear the htab if firmware assisted dump is active so
+ * that we dont end up using old mappings.
+ */
+ if (is_fadump_active() && ppc_md.hpte_clear_all)
+ ppc_md.hpte_clear_all();
+#endif
} else {
/* Find storage for the HPT. Must be contiguous in
* the absolute address space. On cell we want it to be
--
Mahesh J Salgaonkar
^ permalink raw reply related
* Re: [PATCH 24/30] KVM: PPC: booke: call resched after every exit
From: Alexander Graf @ 2012-02-20 13:17 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <4F3EDC01.5000400@freescale.com>
On 18.02.2012, at 00:00, Scott Wood wrote:
> On 02/17/2012 11:13 AM, Alexander Graf wrote:
>> Instead of checking whether we should reschedule only when we exited
>> due to an interrupt, let's always check before entering the guest =
back
>> again. This gets the target more in line with the other archs.
>>=20
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> ---
>> arch/powerpc/kvm/booke.c | 15 ++++++++++-----
>> 1 files changed, 10 insertions(+), 5 deletions(-)
>>=20
>> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
>> index bfb2092..de30b6d 100644
>> --- a/arch/powerpc/kvm/booke.c
>> +++ b/arch/powerpc/kvm/booke.c
>> @@ -572,6 +572,7 @@ int kvmppc_handle_exit(struct kvm_run *run, =
struct kvm_vcpu *vcpu,
>> unsigned int exit_nr)
>> {
>> int r =3D RESUME_HOST;
>> + int resched_needed =3D 1;
>>=20
>> /* update before a new last_exit_type is rewritten */
>> kvmppc_update_timing_stats(vcpu);
>> @@ -602,25 +603,21 @@ int kvmppc_handle_exit(struct kvm_run *run, =
struct kvm_vcpu *vcpu,
>>=20
>> switch (exit_nr) {
>> case BOOKE_INTERRUPT_MACHINE_CHECK:
>> - kvm_resched(vcpu);
>> r =3D RESUME_GUEST;
>> break;
>>=20
>> case BOOKE_INTERRUPT_EXTERNAL:
>> kvmppc_account_exit(vcpu, EXT_INTR_EXITS);
>> - kvm_resched(vcpu);
>> r =3D RESUME_GUEST;
>> break;
>>=20
>> case BOOKE_INTERRUPT_DECREMENTER:
>> kvmppc_account_exit(vcpu, DEC_EXITS);
>> - kvm_resched(vcpu);
>> r =3D RESUME_GUEST;
>> break;
>>=20
>> case BOOKE_INTERRUPT_DOORBELL:
>> kvmppc_account_exit(vcpu, DBELL_EXITS);
>> - kvm_resched(vcpu);
>> r =3D RESUME_GUEST;
>> break;
>>=20
>> @@ -869,8 +866,16 @@ int kvmppc_handle_exit(struct kvm_run *run, =
struct kvm_vcpu *vcpu,
>> BUG();
>> }
>>=20
>> - local_irq_disable();
>> + /* make sure we reschedule if we need to */
>> + while (resched_needed) {
>> + local_irq_disable();
>>=20
>> + resched_needed =3D need_resched();
>> + if (resched_needed) {
>> + local_irq_enable();
>> + cond_resched();
>> + }
>> + }
>> kvmppc_core_prepare_to_enter(vcpu);
>>=20
>> if (!(r & RESUME_HOST)) {
>=20
> kvmppc_core_prepare_to_enter can enable interrupts (and block) if =
guest
> MSR_WE is set. We may take an interrupt that wants a resched after
> waking but before interrupts are disabled again.
>=20
> We also want to check for a resched in kvmppc_vcpu_run. So, the =
resched
> check belongs in kvmppc_core_prepare_to_enter, something like:
>=20
> /* Check pending exceptions and deliver one, if possible. */
> void kvmppc_core_prepare_to_enter(struct kvm_vcpu *vcpu)
> {
> WARN_ON_ONCE(!irqs_disabled());
>=20
> while (true) {
> if (signal_pending(current))
> break;
>=20
> if (need_resched()) {
> local_irq_enable();
> cond_resched();
> local_irq_disable();
> continue;
> }
>=20
> kvmppc_core_check_exceptions(vcpu);
>=20
> if (vcpu->arch.shared->msr & MSR_WE) {
> local_irq_enable();
> kvm_vcpu_block(vcpu);
> local_irq_disable();
> =09
> kvmppc_set_exit_type(vcpu,
> EMULATED_MTMSRWE_EXITS);
> continue;
> }
>=20
> break;
> }
> }
>=20
> It would be simpler (both here and in the idle hcall) if we could just
> drop support for CONFIG_PREEMPT=3Dn. :-P
When running with CONFIG_PREEMPT=3Dn we don't have to worry about =
interrupts being enabled though, since we only preempt on known good =
checkpoints, right? While for CONFIG_PREEMPT=3Dy we can always get =
preempted, rendering most of these checks void.
So essentially we could just be lazy and do a "best effort" resched =
check, but not worry about races wrt guest entry/exit, right? And for =
real preemption modes we don't have to worry about any of the resched =
stuff IIUC, correct?
Alex
^ permalink raw reply
* Re: warnings from drivers/tty/ehv_bytechan.c
From: Tabi Timur-B04825 @ 2012-02-20 13:24 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: gregkh@linuxfoundation.org, ppc-dev
In-Reply-To: <20120220072352.4c8131bbcea69afc007a4297@canb.auug.org.au>
Stephen Rothwell wrote:
> console_initcall() is not defined for modules.
Hmmm... the patch you posted is a good short-term fix, but I wonder if=20
makes sense for the driver to support modules at all. I have this in the=20
driver:
#include <linux/module.h>
...
module_init(ehv_bc_init);
module_exit(ehv_bc_exit);
although to be honest, I can't remember the last time I tried to compile=20
it as a module.
The problem stems from the fact that it's a console driver *and* a tty=20
driver. It makes sense that a tty driver can be compiled as a module, but=
=20
not a console driver.
So Greg, can I do something like this:
#ifdef MODULE
module_initcall(ehv_bc_console_init)
#else
console_initcall(ehv_bc_console_init);
#endif
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* RE: [linuxppc-release] [PATCH 1/2] powerpc: document the FSL MPIC message register binding
From: Yoder Stuart-B08248 @ 2012-02-20 14:00 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: meador_inge@mentor.com, linuxppc-dev@lists.ozlabs.org,
Li Yang-R58472, Jia Hongtao-B38951
In-Reply-To: <4F3EF533.90409@freescale.com>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Friday, February 17, 2012 6:48 PM
> To: Yoder Stuart-B08248
> Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; meador_inge@mentor=
.com; Li Yang-R58472
> Subject: Re: [linuxppc-release] [PATCH 1/2] powerpc: document the FSL MPI=
C message register
> binding
>=20
> On 02/17/2012 09:50 AM, Yoder Stuart-B08248 wrote:
> >
> >
> >> -----Original Message-----
> >> From: linuxppc-release-bounces@linux.freescale.net
> >> [mailto:linuxppc-release- bounces@linux.freescale.net] On Behalf Of
> >> Jia Hongtao-B38951
> >> Sent: Thursday, February 16, 2012 8:49 PM
> >> To: linuxppc-dev@lists.ozlabs.org
> >> Cc: meador_inge@mentor.com; Li Yang-R58472; Jia Hongtao-B38951
> >> Subject: [linuxppc-release] [PATCH 1/2] powerpc: document the FSL
> >> MPIC message register binding
> >>
> >> This binding documents how the message register blocks found in some
> >> FSL MPIC implementations shall be represented in a device tree.
> >>
> >> Signed-off-by: Meador Inge <meador_inge@mentor.com>
> >> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> >> Signed-off-by: Li Yang <leoli@freescale.com>
> >> ---
> >> .../devicetree/bindings/powerpc/fsl/mpic-msgr.txt | 62 +++++++++++=
+++++++++
> >> 1 files changed, 62 insertions(+), 0 deletions(-) create mode
> >> 100644 Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
> >> b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
> >> new file mode 100644
> >> index 0000000..b4ae70e
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
> >> @@ -0,0 +1,62 @@
> >> +* FSL MPIC Message Registers
> >> +
> >> +This binding specifies what properties must be available in the
> >> +device tree representation of the message register blocks found in
> >> +some FSL MPIC implementations.
> >> +
> >> +Required properties:
> >> +
> >> + - compatible: Specifies the compatibility list for the message re=
gister
> >> + block. The type shall be <string> and the value shall be of th=
e form
> >> + "fsl,mpic-v<version>-msgr", where <version> is the version numb=
er of
> >> + the MPIC containing the message registers.
> >
> > The type for compatibles is a <string-list>.
> >
> >> + - reg: Specifies the base physical address(s) and size(s) of the
> >> + message register block's addressable register space. The type =
shall be
> >> + <prop-encoded-array>.
> >> +
> >> + - interrupts: Specifies a list of interrupt source and level-sens=
e pairs.
> >> + The type shall be <prop-encoded-array>. The length shall be eq=
ual to
> >> + the number of registers that are available for receiving interr=
upts.
> >
> > How many interrupts are there? If more than 1, this is where
> > you need to specify what each interrupt is for.
>=20
> They aren't "for" anything in particular -- each interrupt is associated =
with a message
> register. The binding does say that the number of interrupts corresponds=
to the bits set in
> the receive mask.
Then make that clear, it also should use the term 'interrupt-specifier'
not 'interrupt source and level-sense pairs', which implies a particular
parent interrupt controller configuration.
Stuart
^ 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