* Re: [v4,4/4] powernv: powerpc: Add winkle support for offline cpus
From: Michael Ellerman @ 2014-12-15 0:01 UTC (permalink / raw)
To: Shreyas B Prabhu; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <548D7A0E.2060107@linux.vnet.ibm.com>
On Sun, 2014-12-14 at 17:22 +0530, Shreyas B Prabhu wrote:
> On Sunday 14 December 2014 03:35 PM, Michael Ellerman wrote:
> >> diff --git a/arch/powerpc/platforms/powernv/subcore.h b/arch/powerpc/platforms/powernv/subcore.h
> >> index 148abc9..604eb40 100644
> >> --- a/arch/powerpc/platforms/powernv/subcore.h
> >> +++ b/arch/powerpc/platforms/powernv/subcore.h
> >> @@ -15,4 +15,5 @@
> >>
> >> #ifndef __ASSEMBLY__
> >> void split_core_secondary_loop(u8 *state);
> >> +extern void update_subcore_sibling_mask(void);
> >> #endif
> >
> > subcore.c isn't built for CONFIG_SMP=n, resulting in:
> >
> > setup.c:(.init.text+0x34b0): undefined reference to `.update_subcore_sibling_mask'
> >
> > I needed to add:
> >
> > +#else
> > +static inline void update_subcore_sibling_mask(void) { };
> > +#endif /* CONFIG_SMP */
> Sorry I missed that.
No worries.
Can you please do a quick test with a SMP=n kernel.
It looks like it should work, but it would be good to test.
cheers
^ permalink raw reply
* Re: [v3, 2/4] powerpc/powernv: Enable Offline CPUs to enter deep idle states
From: Michael Ellerman @ 2014-12-14 23:44 UTC (permalink / raw)
To: Shreyas B Prabhu
Cc: linux-pm, Rafael J. Wysocki, linux-kernel, Paul Mackerras,
Preeti U. Murthy, linuxppc-dev
In-Reply-To: <548D7967.2060403@linux.vnet.ibm.com>
On Sun, 2014-12-14 at 17:19 +0530, Shreyas B Prabhu wrote:
>
> On Sunday 14 December 2014 03:35 PM, Michael Ellerman wrote:
> > On Thu, 2014-04-12 at 07:28:21 UTC, "Shreyas B. Prabhu" wrote:
> >> From: "Preeti U. Murthy" <preeti@linux.vnet.ibm.com>
> >>
> >> The secondary threads should enter deep idle states so as to gain maximum
> >> powersavings when the entire core is offline. To do so the offline path
> >> must be made aware of the available deepest idle state. Hence probe the
> >> device tree for the possible idle states in powernv core code and
> >> expose the deepest idle state through flags.
> >>
> >> Since the device tree is probed by the cpuidle driver as well, move
> >> the parameters required to discover the idle states into an appropriate
> >> common place to both the driver and the powernv core code.
> >>
> >> Another point is that fastsleep idle state may require workarounds in
> >> the kernel to function properly. This workaround is introduced in the
> >> subsequent patches. However neither the cpuidle driver or the hotplug
> >> path need be bothered about this workaround.
> >>
> >> They will be taken care of by the core powernv code.
> >
> > ...
> >
> >> diff --git a/arch/powerpc/platforms/powernv/smp.c b/arch/powerpc/platforms/powernv/smp.c
> >> index 4753958..3dc4cec 100644
> >> --- a/arch/powerpc/platforms/powernv/smp.c
> >> +++ b/arch/powerpc/platforms/powernv/smp.c
> >> @@ -159,13 +160,17 @@ static void pnv_smp_cpu_kill_self(void)
> >> generic_set_cpu_dead(cpu);
> >> smp_wmb();
> >>
> >> + idle_states = pnv_get_supported_cpuidle_states();
> >> /* We don't want to take decrementer interrupts while we are offline,
> >> * so clear LPCR:PECE1. We keep PECE2 enabled.
> >> */
> >> mtspr(SPRN_LPCR, mfspr(SPRN_LPCR) & ~(u64)LPCR_PECE1);
> >> while (!generic_check_cpu_restart(cpu)) {
> >> ppc64_runlatch_off();
> >> - power7_nap(1);
> >> + if (idle_states & OPAL_PM_SLEEP_ENABLED)
> >> + power7_sleep();
> >> + else
> >> + power7_nap(1);
> >
> > So I might be missing something subtle here, but aren't we potentially enabling
> > sleep here, prior to your next patch which makes it safe to actually use sleep?
> >
> > Shouldn't we only allow sleep after patch 3? Or in other words shouldn't this
> > be patch 3 (or 4)?
>
> A point to note here, when sleep is exposed in device tree under ibm,cpu-idle-state-flags,
> we use 2 bits, OPAL_PM_SLEEP_ENABLED and OPAL_PM_SLEEP_ENABLED_ER1. This patch only enables
> sleep in OPAL_PM_SLEEP_ENABLED case. In current POWER8 chips, sleep is exposed as
> OPAL_PM_SLEEP_ENABLED_ER1, indicating the hardware bug and the need for fastsleep
> workaround. And bulk of the redesign introduced in next patch helps fastsleep workaround
> and winkle.
>
> That said, using sleep without "powernv: cpuidle: Redesign idle states management"
> does expose us to a bug with performing VM migration onto subcores. But not enabling
> here (i.e offline case) until next patch doesn't make much difference as the cpuidle
> framework has already enabled sleep.
>
> In other words, OPAL_PM_SLEEP_ENABLED case will come into picture when the hardware
> bug around fastsleep is fixed. And in this case running any kernel without "powernv:
> cpuidle: Redesign idle states management" does expose us to a bug with sleep + VM
> migration onto subcores, because cpuidle enables sleep based on OPAL_PM_SLEEP_ENABLED
> bit. IMO delaying enabling of sleep in OPAL_PM_SLEEP_ENABLED case until next patch,
> only for offline cpus should not gain us much. But I'll be happy to resend the patches
> with the change if you think it is required.
OK, thanks for the explanation. I'll put it in as-is.
In future if you can add that sort of explanation to the changelog that would
be great.
cheers
^ permalink raw reply
* [PATCH 13/18] powerpc/uaccess: fix sparse errors
From: Michael S. Tsirkin @ 2014-12-14 16:52 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-arch, Arnd Bergmann, Paul Mackerras, linuxppc-dev
In-Reply-To: <1418575877-21488-1-git-send-email-mst@redhat.com>
virtio wants to read bitwise types from userspace using get_user. At the
moment this triggers sparse errors, since the value is passed through an
integer.
Fix that up using __force.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/powerpc/include/asm/uaccess.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
index 9485b43..a0c071d 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -284,7 +284,7 @@ do { \
if (!is_kernel_addr((unsigned long)__gu_addr)) \
might_fault(); \
__get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
- (x) = (__typeof__(*(ptr)))__gu_val; \
+ (x) = (__force __typeof__(*(ptr)))__gu_val; \
__gu_err; \
})
#endif /* __powerpc64__ */
@@ -297,7 +297,7 @@ do { \
might_fault(); \
if (access_ok(VERIFY_READ, __gu_addr, (size))) \
__get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
- (x) = (__typeof__(*(ptr)))__gu_val; \
+ (x) = (__force __typeof__(*(ptr)))__gu_val; \
__gu_err; \
})
@@ -308,7 +308,7 @@ do { \
const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
__chk_user_ptr(ptr); \
__get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
- (x) = (__typeof__(*(ptr)))__gu_val; \
+ (x) = (__force __typeof__(*(ptr)))__gu_val; \
__gu_err; \
})
--
MST
^ permalink raw reply related
* Re: [v4,4/4] powernv: powerpc: Add winkle support for offline cpus
From: Shreyas B Prabhu @ 2014-12-14 11:52 UTC (permalink / raw)
To: Michael Ellerman, linux-kernel; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <20141214100600.3446B140119@ozlabs.org>
On Sunday 14 December 2014 03:35 PM, Michael Ellerman wrote:
> On Tue, 2014-09-12 at 18:56:53 UTC, "Shreyas B. Prabhu" wrote:
>> Winkle is a deep idle state supported in power8 chips. A core enters
>> winkle when all the threads of the core enter winkle. In this state
>> power supply to the entire chiplet i.e core, private L2 and private L3
>> is turned off. As a result it gives higher powersavings compared to
>> sleep.
> ...
>
>> diff --git a/arch/powerpc/platforms/powernv/subcore.h b/arch/powerpc/platforms/powernv/subcore.h
>> index 148abc9..604eb40 100644
>> --- a/arch/powerpc/platforms/powernv/subcore.h
>> +++ b/arch/powerpc/platforms/powernv/subcore.h
>> @@ -15,4 +15,5 @@
>>
>> #ifndef __ASSEMBLY__
>> void split_core_secondary_loop(u8 *state);
>> +extern void update_subcore_sibling_mask(void);
>> #endif
>
> subcore.c isn't built for CONFIG_SMP=n, resulting in:
>
> setup.c:(.init.text+0x34b0): undefined reference to `.update_subcore_sibling_mask'
>
> I needed to add:
>
> +#else
> +static inline void update_subcore_sibling_mask(void) { };
> +#endif /* CONFIG_SMP */
>
>
Sorry I missed that.
> I also got quite a few conflicts, with this and the previous patch, mainly in
> the paca and asm-offsets. Please check I resolved them correctly:
>
> https://github.com/mpe/powerpc-merge/commits/test
>
This looks fine to me.
Thanks,
Shreyas
> cheers
>
^ permalink raw reply
* Re: [v3, 2/4] powerpc/powernv: Enable Offline CPUs to enter deep idle states
From: Shreyas B Prabhu @ 2014-12-14 11:49 UTC (permalink / raw)
To: Michael Ellerman, linux-kernel
Cc: Preeti U. Murthy, Paul Mackerras, Rafael J. Wysocki, linuxppc-dev,
linux-pm
In-Reply-To: <20141214100558.B40551400B7@ozlabs.org>
On Sunday 14 December 2014 03:35 PM, Michael Ellerman wrote:
> On Thu, 2014-04-12 at 07:28:21 UTC, "Shreyas B. Prabhu" wrote:
>> From: "Preeti U. Murthy" <preeti@linux.vnet.ibm.com>
>>
>> The secondary threads should enter deep idle states so as to gain maximum
>> powersavings when the entire core is offline. To do so the offline path
>> must be made aware of the available deepest idle state. Hence probe the
>> device tree for the possible idle states in powernv core code and
>> expose the deepest idle state through flags.
>>
>> Since the device tree is probed by the cpuidle driver as well, move
>> the parameters required to discover the idle states into an appropriate
>> common place to both the driver and the powernv core code.
>>
>> Another point is that fastsleep idle state may require workarounds in
>> the kernel to function properly. This workaround is introduced in the
>> subsequent patches. However neither the cpuidle driver or the hotplug
>> path need be bothered about this workaround.
>>
>> They will be taken care of by the core powernv code.
>
> ...
>
>> diff --git a/arch/powerpc/platforms/powernv/smp.c b/arch/powerpc/platforms/powernv/smp.c
>> index 4753958..3dc4cec 100644
>> --- a/arch/powerpc/platforms/powernv/smp.c
>> +++ b/arch/powerpc/platforms/powernv/smp.c
>> @@ -159,13 +160,17 @@ static void pnv_smp_cpu_kill_self(void)
>> generic_set_cpu_dead(cpu);
>> smp_wmb();
>>
>> + idle_states = pnv_get_supported_cpuidle_states();
>> /* We don't want to take decrementer interrupts while we are offline,
>> * so clear LPCR:PECE1. We keep PECE2 enabled.
>> */
>> mtspr(SPRN_LPCR, mfspr(SPRN_LPCR) & ~(u64)LPCR_PECE1);
>> while (!generic_check_cpu_restart(cpu)) {
>> ppc64_runlatch_off();
>> - power7_nap(1);
>> + if (idle_states & OPAL_PM_SLEEP_ENABLED)
>> + power7_sleep();
>> + else
>> + power7_nap(1);
>
> So I might be missing something subtle here, but aren't we potentially enabling
> sleep here, prior to your next patch which makes it safe to actually use sleep?
>
> Shouldn't we only allow sleep after patch 3? Or in other words shouldn't this
> be patch 3 (or 4)?
>
A point to note here, when sleep is exposed in device tree under ibm,cpu-idle-state-flags,
we use 2 bits, OPAL_PM_SLEEP_ENABLED and OPAL_PM_SLEEP_ENABLED_ER1. This patch only enables
sleep in OPAL_PM_SLEEP_ENABLED case. In current POWER8 chips, sleep is exposed as
OPAL_PM_SLEEP_ENABLED_ER1, indicating the hardware bug and the need for fastsleep
workaround. And bulk of the redesign introduced in next patch helps fastsleep workaround
and winkle.
That said, using sleep without "powernv: cpuidle: Redesign idle states management"
does expose us to a bug with performing VM migration onto subcores. But not enabling
here (i.e offline case) until next patch doesn't make much difference as the cpuidle
framework has already enabled sleep.
In other words, OPAL_PM_SLEEP_ENABLED case will come into picture when the hardware
bug around fastsleep is fixed. And in this case running any kernel without "powernv:
cpuidle: Redesign idle states management" does expose us to a bug with sleep + VM
migration onto subcores, because cpuidle enables sleep based on OPAL_PM_SLEEP_ENABLED
bit. IMO delaying enabling of sleep in OPAL_PM_SLEEP_ENABLED case until next patch,
only for offline cpus should not gain us much. But I'll be happy to resend the patches
with the change if you think it is required.
Thanks,
Shreyas
^ permalink raw reply
* Re: [PATCH] powerpc/pci: remove the multi-init for pci_dn->phb
From: Gavin Shan @ 2014-12-14 10:57 UTC (permalink / raw)
To: Wei Yang; +Cc: linuxppc-dev
In-Reply-To: <1418440144-12122-1-git-send-email-weiyang@linux.vnet.ibm.com>
On Sat, Dec 13, 2014 at 11:09:04AM +0800, Wei Yang wrote:
>pci_dn->phb is set to phb in update_dn_pci_info(), if succeed.
>
>This patch removes the duplication of pci_dn->phb initialization.
>
>Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
>---
> arch/powerpc/kernel/pci_dn.c | 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/arch/powerpc/kernel/pci_dn.c b/arch/powerpc/kernel/pci_dn.c
>index ddae246..d40b579 100644
>--- a/arch/powerpc/kernel/pci_dn.c
>+++ b/arch/powerpc/kernel/pci_dn.c
>@@ -382,7 +382,6 @@ void pci_devs_phb_init_dynamic(struct pci_controller *phb)
> pdn = dn->data;
> if (pdn) {
> pdn->devfn = pdn->busno = -1;
>- pdn->phb = phb;
> phb->firmware_data = pdn;
It seems the patch bases on unmerged code because "phb->firmware_data"
isn't existing yet in upstream or ppc.next.
Thanks,
Gavin
> }
>
>--
>1.7.9.5
>
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@lists.ozlabs.org
>https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [v4,4/4] powernv: powerpc: Add winkle support for offline cpus
From: Michael Ellerman @ 2014-12-14 10:05 UTC (permalink / raw)
To: Shreyas B. Prabhu, linux-kernel
Cc: Shreyas B. Prabhu, linuxppc-dev, Paul Mackerras
In-Reply-To: <1418151413-6141-5-git-send-email-shreyas@linux.vnet.ibm.com>
On Tue, 2014-09-12 at 18:56:53 UTC, "Shreyas B. Prabhu" wrote:
> Winkle is a deep idle state supported in power8 chips. A core enters
> winkle when all the threads of the core enter winkle. In this state
> power supply to the entire chiplet i.e core, private L2 and private L3
> is turned off. As a result it gives higher powersavings compared to
> sleep.
...
> diff --git a/arch/powerpc/platforms/powernv/subcore.h b/arch/powerpc/platforms/powernv/subcore.h
> index 148abc9..604eb40 100644
> --- a/arch/powerpc/platforms/powernv/subcore.h
> +++ b/arch/powerpc/platforms/powernv/subcore.h
> @@ -15,4 +15,5 @@
>
> #ifndef __ASSEMBLY__
> void split_core_secondary_loop(u8 *state);
> +extern void update_subcore_sibling_mask(void);
> #endif
subcore.c isn't built for CONFIG_SMP=n, resulting in:
setup.c:(.init.text+0x34b0): undefined reference to `.update_subcore_sibling_mask'
I needed to add:
+#else
+static inline void update_subcore_sibling_mask(void) { };
+#endif /* CONFIG_SMP */
I also got quite a few conflicts, with this and the previous patch, mainly in
the paca and asm-offsets. Please check I resolved them correctly:
https://github.com/mpe/powerpc-merge/commits/test
cheers
^ permalink raw reply
* Re: [v4, 1/4] powerpc: powernv: Switch off MMU before entering nap/sleep/rvwinkle mode
From: Michael Ellerman @ 2014-12-14 10:05 UTC (permalink / raw)
To: Shreyas B. Prabhu, linux-kernel
Cc: Shreyas B. Prabhu, linuxppc-dev, Paul Mackerras
In-Reply-To: <1418151413-6141-2-git-send-email-shreyas@linux.vnet.ibm.com>
On Tue, 2014-09-12 at 18:56:50 UTC, "Shreyas B. Prabhu" wrote:
> From: Paul Mackerras <paulus@samba.org>
>
> Currently, when going idle, we set the flag indicating that we are in
> nap mode (paca->kvm_hstate.hwthread_state) and then execute the nap
> (or sleep or rvwinkle) instruction, all with the MMU on. This is bad
> for two reasons: (a) the architecture specifies that those instructions
> must be executed with the MMU off, and in fact with only the SF, HV, ME
> and possibly RI bits set, and (b) this introduces a race, because as
> soon as we set the flag, another thread can switch the MMU to a guest
> context. If the race is lost, this thread will typically start looping
> on relocation-on ISIs at 0xc...4400.
>
> This fixes it by setting the MSR as required by the architecture before
> setting the flag or executing the nap/sleep/rvwinkle instruction.
>
> [ shreyas@linux.vnet.ibm.com: Edited to handle LE ]
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> Signed-off-by: Shreyas B. Prabhu <shreyas@linux.vnet.ibm.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linuxppc-dev@lists.ozlabs.org
I'm going to CC this to stable unless anyone objects. It's not something people
are likely to hit, but the result is fairly catastrophic.
cheers
^ permalink raw reply
* Re: [v3, 2/4] powerpc/powernv: Enable Offline CPUs to enter deep idle states
From: Michael Ellerman @ 2014-12-14 10:05 UTC (permalink / raw)
To: Shreyas B. Prabhu, linux-kernel
Cc: linux-pm, Shreyas B. Prabhu, Rafael J. Wysocki, Paul Mackerras,
Preeti U. Murthy, linuxppc-dev
In-Reply-To: <1417678103-32571-3-git-send-email-shreyas@linux.vnet.ibm.com>
On Thu, 2014-04-12 at 07:28:21 UTC, "Shreyas B. Prabhu" wrote:
> From: "Preeti U. Murthy" <preeti@linux.vnet.ibm.com>
>
> The secondary threads should enter deep idle states so as to gain maximum
> powersavings when the entire core is offline. To do so the offline path
> must be made aware of the available deepest idle state. Hence probe the
> device tree for the possible idle states in powernv core code and
> expose the deepest idle state through flags.
>
> Since the device tree is probed by the cpuidle driver as well, move
> the parameters required to discover the idle states into an appropriate
> common place to both the driver and the powernv core code.
>
> Another point is that fastsleep idle state may require workarounds in
> the kernel to function properly. This workaround is introduced in the
> subsequent patches. However neither the cpuidle driver or the hotplug
> path need be bothered about this workaround.
>
> They will be taken care of by the core powernv code.
...
> diff --git a/arch/powerpc/platforms/powernv/smp.c b/arch/powerpc/platforms/powernv/smp.c
> index 4753958..3dc4cec 100644
> --- a/arch/powerpc/platforms/powernv/smp.c
> +++ b/arch/powerpc/platforms/powernv/smp.c
> @@ -159,13 +160,17 @@ static void pnv_smp_cpu_kill_self(void)
> generic_set_cpu_dead(cpu);
> smp_wmb();
>
> + idle_states = pnv_get_supported_cpuidle_states();
> /* We don't want to take decrementer interrupts while we are offline,
> * so clear LPCR:PECE1. We keep PECE2 enabled.
> */
> mtspr(SPRN_LPCR, mfspr(SPRN_LPCR) & ~(u64)LPCR_PECE1);
> while (!generic_check_cpu_restart(cpu)) {
> ppc64_runlatch_off();
> - power7_nap(1);
> + if (idle_states & OPAL_PM_SLEEP_ENABLED)
> + power7_sleep();
> + else
> + power7_nap(1);
So I might be missing something subtle here, but aren't we potentially enabling
sleep here, prior to your next patch which makes it safe to actually use sleep?
Shouldn't we only allow sleep after patch 3? Or in other words shouldn't this
be patch 3 (or 4)?
cheers
^ permalink raw reply
* [PATCH v4] i2c: Driver to expose PowerNV platform i2c busses
From: Neelesh Gupta @ 2014-12-13 18:01 UTC (permalink / raw)
To: linuxppc-dev, linux-i2c, devicetree; +Cc: wsa
The patch exposes the available i2c busses on the PowerNV platform
to the kernel and implements the bus driver to support i2c and
smbus commands.
The driver uses the platform device infrastructure to probe the busses
on the platform and registers them with the i2c driver framework.
Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Wolfram Sang <wsa@the-dreams.de> (I2C part, excluding the bindings)
---
v3 -> v4:
- Rebased to the latest tree.
- Exported the opal function 'opal_i2c_request' in opal.c to make the
driver build as module.
v2 -> v3:
- Added the device tree binding documentation for the driver.
- Sorted the ordering of this new driver added in Makefile.
- Removed populating the superfluous .owner field in 'struct driver'.
Documentation/devicetree/bindings/i2c/i2c-opal.txt | 37 +++
arch/powerpc/include/asm/opal.h | 29 ++
arch/powerpc/platforms/powernv/opal-wrappers.S | 1
arch/powerpc/platforms/powernv/opal.c | 12 +
drivers/i2c/busses/Kconfig | 11 +
drivers/i2c/busses/Makefile | 1
drivers/i2c/busses/i2c-opal.c | 294 ++++++++++++++++++++
7 files changed, 385 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-opal.txt
create mode 100644 drivers/i2c/busses/i2c-opal.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-opal.txt b/Documentation/devicetree/bindings/i2c/i2c-opal.txt
new file mode 100644
index 0000000..12bc614
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-opal.txt
@@ -0,0 +1,37 @@
+Device-tree bindings for I2C OPAL driver
+----------------------------------------
+
+Most of the device node and properties layout is specific to the firmware and
+used by the firmware itself for configuring the port. From the linux
+perspective, the properties of use are "ibm,port-name" and "ibm,opal-id".
+
+Required properties:
+
+- reg: Port-id within a given master
+- compatible: must be "ibm,opal-i2c"
+- ibm,opal-id: Refers to a specific bus and used to identify it when calling
+ the relevant OPAL functions.
+- bus-frequency: Operating frequency of the i2c bus (in HZ). Informational for
+ linux, used by the FW though.
+
+Optional properties:
+- ibm,port-name: Firmware provides this name that uniquely identifies the i2c
+ port.
+
+The node contains a number of other properties that are used by the FW itself
+and depend on the specific hardware implementation. The example below depicts
+a P8 on-chip bus.
+
+Example:
+
+i2c-bus@0 {
+ reg = <0x0>;
+ bus-frequency = <0x61a80>;
+ compatible = "ibm,power8-i2c-port", "ibm,opal-i2c";
+ ibm,opal-id = <0x1>;
+ ibm,port-name = "p8_00000000_e1p0";
+ #address-cells = <0x1>;
+ phandle = <0x10000006>;
+ #size-cells = <0x0>;
+ linux,phandle = <0x10000006>;
+};
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 5cd8d2f..4095749 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -56,6 +56,14 @@ struct opal_sg_list {
#define OPAL_HARDWARE_FROZEN -13
#define OPAL_WRONG_STATE -14
#define OPAL_ASYNC_COMPLETION -15
+#define OPAL_I2C_TIMEOUT -17
+#define OPAL_I2C_INVALID_CMD -18
+#define OPAL_I2C_LBUS_PARITY -19
+#define OPAL_I2C_BKEND_OVERRUN -20
+#define OPAL_I2C_BKEND_ACCESS -21
+#define OPAL_I2C_ARBT_LOST -22
+#define OPAL_I2C_NACK_RCVD -23
+#define OPAL_I2C_STOP_ERR -24
/* API Tokens (in r0) */
#define OPAL_INVALID_CALL -1
@@ -158,6 +166,7 @@ struct opal_sg_list {
#define OPAL_READ_TPO 104
#define OPAL_IPMI_SEND 107
#define OPAL_IPMI_RECV 108
+#define OPAL_I2C_REQUEST 109
#ifndef __ASSEMBLY__
@@ -712,6 +721,24 @@ typedef struct oppanel_line {
uint64_t line_len;
} oppanel_line_t;
+/* OPAL I2C request */
+struct opal_i2c_request {
+ uint8_t type;
+#define OPAL_I2C_RAW_READ 0
+#define OPAL_I2C_RAW_WRITE 1
+#define OPAL_I2C_SM_READ 2
+#define OPAL_I2C_SM_WRITE 3
+ uint8_t flags;
+#define OPAL_I2C_ADDR_10 0x01 /* Not supported yet */
+ uint8_t subaddr_sz; /* Max 4 */
+ uint8_t reserved;
+ __be16 addr; /* 7 or 10 bit address */
+ __be16 reserved2;
+ __be32 subaddr; /* Sub-address if any */
+ __be32 size; /* Data size */
+ __be64 buffer_ra; /* Buffer real address */
+};
+
/* /sys/firmware/opal */
extern struct kobject *opal_kobj;
@@ -881,6 +908,8 @@ int64_t opal_ipmi_send(uint64_t interface, struct opal_ipmi_msg *msg,
uint64_t msg_len);
int64_t opal_ipmi_recv(uint64_t interface, struct opal_ipmi_msg *msg,
uint64_t *msg_len);
+int64_t opal_i2c_request(uint64_t async_token, uint32_t bus_id,
+ struct opal_i2c_request *oreq);
/* Internal functions */
extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S b/arch/powerpc/platforms/powernv/opal-wrappers.S
index 0a299be..2111e08 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -254,3 +254,4 @@ OPAL_CALL(opal_tpo_write, OPAL_WRITE_TPO);
OPAL_CALL(opal_tpo_read, OPAL_READ_TPO);
OPAL_CALL(opal_ipmi_send, OPAL_IPMI_SEND);
OPAL_CALL(opal_ipmi_recv, OPAL_IPMI_RECV);
+OPAL_CALL(opal_i2c_request, OPAL_I2C_REQUEST);
diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
index cb0b6de..aa316d8 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -653,6 +653,14 @@ static void opal_ipmi_init(struct device_node *opal_node)
of_platform_device_create(np, NULL, NULL);
}
+static void opal_i2c_create_devs(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, "ibm,opal-i2c")
+ of_platform_device_create(np, NULL, NULL);
+}
+
static int __init opal_init(void)
{
struct device_node *np, *consoles;
@@ -679,6 +687,9 @@ static int __init opal_init(void)
of_node_put(consoles);
}
+ /* Create i2c platform devices */
+ opal_i2c_create_devs();
+
/* Find all OPAL interrupts and request them */
irqs = of_get_property(opal_node, "opal-interrupts", &irqlen);
pr_debug("opal: Found %d interrupts reserved for OPAL\n",
@@ -824,3 +835,4 @@ EXPORT_SYMBOL_GPL(opal_rtc_read);
EXPORT_SYMBOL_GPL(opal_rtc_write);
EXPORT_SYMBOL_GPL(opal_tpo_read);
EXPORT_SYMBOL_GPL(opal_tpo_write);
+EXPORT_SYMBOL_GPL(opal_i2c_request);
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index b4d135c..aee80e8 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1054,4 +1054,15 @@ config SCx200_ACB
This support is also available as a module. If so, the module
will be called scx200_acb.
+config I2C_OPAL
+ tristate "IBM OPAL I2C driver"
+ depends on PPC_POWERNV
+ default y
+ help
+ This exposes the PowerNV platform i2c busses to the linux i2c layer,
+ the driver is based on the OPAL interfaces.
+
+ This driver can also be built as a module. If so, the module will be
+ called as i2c-opal.
+
endmenu
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index cdac7f1..741ff95 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -100,6 +100,7 @@ obj-$(CONFIG_I2C_ACORN) += i2c-acorn.o
obj-$(CONFIG_I2C_BCM_KONA) += i2c-bcm-kona.o
obj-$(CONFIG_I2C_CROS_EC_TUNNEL) += i2c-cros-ec-tunnel.o
obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o
+obj-$(CONFIG_I2C_OPAL) += i2c-opal.o
obj-$(CONFIG_I2C_PCA_ISA) += i2c-pca-isa.o
obj-$(CONFIG_I2C_SIBYTE) += i2c-sibyte.o
obj-$(CONFIG_SCx200_ACB) += scx200_acb.o
diff --git a/drivers/i2c/busses/i2c-opal.c b/drivers/i2c/busses/i2c-opal.c
new file mode 100644
index 0000000..16f90b1
--- /dev/null
+++ b/drivers/i2c/busses/i2c-opal.c
@@ -0,0 +1,294 @@
+/*
+ * IBM OPAL I2C driver
+ * Copyright (C) 2014 IBM
+ *
+ * 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.
+ */
+
+#include <linux/device.h>
+#include <linux/i2c.h>
+#include <linux/kernel.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include <asm/firmware.h>
+#include <asm/opal.h>
+
+static int i2c_opal_translate_error(int rc)
+{
+ switch (rc) {
+ case OPAL_NO_MEM:
+ return -ENOMEM;
+ case OPAL_PARAMETER:
+ return -EINVAL;
+ case OPAL_I2C_ARBT_LOST:
+ return -EAGAIN;
+ case OPAL_I2C_TIMEOUT:
+ return -ETIMEDOUT;
+ case OPAL_I2C_NACK_RCVD:
+ return -ENXIO;
+ case OPAL_I2C_STOP_ERR:
+ return -EBUSY;
+ default:
+ return -EIO;
+ }
+}
+
+static int i2c_opal_send_request(u32 bus_id, struct opal_i2c_request *req)
+{
+ struct opal_msg msg;
+ int token, rc;
+
+ token = opal_async_get_token_interruptible();
+ if (token < 0) {
+ if (token != -ERESTARTSYS)
+ pr_err("Failed to get the async token\n");
+
+ return token;
+ }
+
+ rc = opal_i2c_request(token, bus_id, req);
+ if (rc != OPAL_ASYNC_COMPLETION) {
+ rc = i2c_opal_translate_error(rc);
+ goto exit;
+ }
+
+ rc = opal_async_wait_response(token, &msg);
+ if (rc)
+ goto exit;
+
+ rc = be64_to_cpu(msg.params[1]);
+ if (rc != OPAL_SUCCESS) {
+ rc = i2c_opal_translate_error(rc);
+ goto exit;
+ }
+
+exit:
+ opal_async_release_token(token);
+ return rc;
+}
+
+static int i2c_opal_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
+ int num)
+{
+ unsigned long opal_id = (unsigned long)adap->algo_data;
+ struct opal_i2c_request req;
+ int rc, i;
+
+ /* We only support fairly simple combinations here of one
+ * or two messages
+ */
+ memset(&req, 0, sizeof(req));
+ switch(num) {
+ case 0:
+ return 0;
+ case 1:
+ req.type = (msgs[0].flags & I2C_M_RD) ?
+ OPAL_I2C_RAW_READ : OPAL_I2C_RAW_WRITE;
+ req.addr = cpu_to_be16(msgs[0].addr);
+ req.size = cpu_to_be32(msgs[0].len);
+ req.buffer_ra = cpu_to_be64(__pa(msgs[0].buf));
+ break;
+ case 2:
+ /* For two messages, we basically support only simple
+ * smbus transactions of a write plus a read. We might
+ * want to allow also two writes but we'd have to bounce
+ * the data into a single buffer.
+ */
+ if ((msgs[0].flags & I2C_M_RD) || !(msgs[1].flags & I2C_M_RD))
+ return -EOPNOTSUPP;
+ if (msgs[0].len > 4)
+ return -EOPNOTSUPP;
+ if (msgs[0].addr != msgs[1].addr)
+ return -EOPNOTSUPP;
+ req.type = OPAL_I2C_SM_READ;
+ req.addr = cpu_to_be16(msgs[0].addr);
+ req.subaddr_sz = msgs[0].len;
+ for (i = 0; i < msgs[0].len; i++)
+ req.subaddr = (req.subaddr << 8) | msgs[0].buf[i];
+ req.subaddr = cpu_to_be32(req.subaddr);
+ req.size = cpu_to_be32(msgs[1].len);
+ req.buffer_ra = cpu_to_be64(__pa(msgs[1].buf));
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ rc = i2c_opal_send_request(opal_id, &req);
+ if (rc)
+ return rc;
+
+ return num;
+}
+
+static int i2c_opal_smbus_xfer(struct i2c_adapter *adap, u16 addr,
+ unsigned short flags, char read_write,
+ u8 command, int size, union i2c_smbus_data *data)
+{
+ unsigned long opal_id = (unsigned long)adap->algo_data;
+ struct opal_i2c_request req;
+ u8 local[2];
+ int rc;
+
+ memset(&req, 0, sizeof(req));
+
+ req.addr = cpu_to_be16(addr);
+ switch (size) {
+ case I2C_SMBUS_BYTE:
+ req.buffer_ra = cpu_to_be64(__pa(&data->byte));
+ req.size = cpu_to_be32(1);
+ /* Fall through */
+ case I2C_SMBUS_QUICK:
+ req.type = (read_write == I2C_SMBUS_READ) ?
+ OPAL_I2C_RAW_READ : OPAL_I2C_RAW_WRITE;
+ break;
+ case I2C_SMBUS_BYTE_DATA:
+ req.buffer_ra = cpu_to_be64(__pa(&data->byte));
+ req.size = cpu_to_be32(1);
+ req.subaddr = cpu_to_be32(command);
+ req.subaddr_sz = 1;
+ req.type = (read_write == I2C_SMBUS_READ) ?
+ OPAL_I2C_SM_READ : OPAL_I2C_SM_WRITE;
+ break;
+ case I2C_SMBUS_WORD_DATA:
+ if (!read_write) {
+ local[0] = data->word & 0xff;
+ local[1] = (data->word >> 8) & 0xff;
+ }
+ req.buffer_ra = cpu_to_be64(__pa(local));
+ req.size = cpu_to_be32(2);
+ req.subaddr = cpu_to_be32(command);
+ req.subaddr_sz = 1;
+ req.type = (read_write == I2C_SMBUS_READ) ?
+ OPAL_I2C_SM_READ : OPAL_I2C_SM_WRITE;
+ break;
+ case I2C_SMBUS_I2C_BLOCK_DATA:
+ req.buffer_ra = cpu_to_be64(__pa(&data->block[1]));
+ req.size = cpu_to_be32(data->block[0]);
+ req.subaddr = cpu_to_be32(command);
+ req.subaddr_sz = 1;
+ req.type = (read_write == I2C_SMBUS_READ) ?
+ OPAL_I2C_SM_READ : OPAL_I2C_SM_WRITE;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ rc = i2c_opal_send_request(opal_id, &req);
+ if (!rc && read_write && size == I2C_SMBUS_WORD_DATA) {
+ data->word = ((u16)local[1]) << 8;
+ data->word |= local[0];
+ }
+
+ return rc;
+}
+
+static u32 i2c_opal_func(struct i2c_adapter *adapter)
+{
+ return I2C_FUNC_I2C | I2C_FUNC_SMBUS_QUICK | I2C_FUNC_SMBUS_BYTE |
+ I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA |
+ I2C_FUNC_SMBUS_I2C_BLOCK;
+}
+
+static const struct i2c_algorithm i2c_opal_algo = {
+ .master_xfer = i2c_opal_master_xfer,
+ .smbus_xfer = i2c_opal_smbus_xfer,
+ .functionality = i2c_opal_func,
+};
+
+static int i2c_opal_probe(struct platform_device *pdev)
+{
+ struct i2c_adapter *adapter;
+ const char *pname;
+ u32 opal_id;
+ int rc;
+
+ if (!pdev->dev.of_node)
+ return -ENODEV;
+
+ rc = of_property_read_u32(pdev->dev.of_node, "ibm,opal-id", &opal_id);
+ if (rc) {
+ dev_err(&pdev->dev, "Missing ibm,opal-id property !\n");
+ return -EIO;
+ }
+
+ adapter = devm_kzalloc(&pdev->dev, sizeof(*adapter), GFP_KERNEL);
+ if (!adapter)
+ return -ENOMEM;
+
+ adapter->algo = &i2c_opal_algo;
+ adapter->algo_data = (void *)(unsigned long)opal_id;
+ adapter->dev.parent = &pdev->dev;
+ adapter->dev.of_node = of_node_get(pdev->dev.of_node);
+ pname = of_get_property(pdev->dev.of_node, "ibm,port-name", NULL);
+ if (pname)
+ strlcpy(adapter->name, pname, sizeof(adapter->name));
+ else
+ strlcpy(adapter->name, "opal", sizeof(adapter->name));
+
+ platform_set_drvdata(pdev, adapter);
+ rc = i2c_add_adapter(adapter);
+ if (rc)
+ dev_err(&pdev->dev, "Failed to register the i2c adapter\n");
+
+ return rc;
+}
+
+static int i2c_opal_remove(struct platform_device *pdev)
+{
+ struct i2c_adapter *adapter = platform_get_drvdata(pdev);
+
+ i2c_del_adapter(adapter);
+
+ return 0;
+}
+
+static const struct of_device_id i2c_opal_of_match[] = {
+ {
+ .compatible = "ibm,opal-i2c",
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, i2c_opal_of_match);
+
+static struct platform_driver i2c_opal_driver = {
+ .probe = i2c_opal_probe,
+ .remove = i2c_opal_remove,
+ .driver = {
+ .name = "i2c-opal",
+ .of_match_table = i2c_opal_of_match,
+ },
+};
+
+static int __init i2c_opal_init(void)
+{
+ if (!firmware_has_feature(FW_FEATURE_OPAL))
+ return -ENODEV;
+
+ return platform_driver_register(&i2c_opal_driver);
+}
+module_init(i2c_opal_init);
+
+static void __exit i2c_opal_exit(void)
+{
+ return platform_driver_unregister(&i2c_opal_driver);
+}
+module_exit(i2c_opal_exit);
+
+MODULE_AUTHOR("Neelesh Gupta <neelegup@linux.vnet.ibm.com>");
+MODULE_DESCRIPTION("IBM OPAL I2C driver");
+MODULE_LICENSE("GPL");
^ permalink raw reply related
* Re: [Patch] :Fix ISR return value in i2c-mpc.c
From: Amit Tomar @ 2014-12-13 5:02 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org, agraf@suse.de
In-Reply-To: <1418418631.5581.68.camel@freescale.com>
Sorry for sending it to wrong mailing-list :(=0A=
=0A=
Thanks,=0A=
Amit.=0A=
________________________________________=0A=
From: Wood Scott-B07421=0A=
Sent: Saturday, December 13, 2014 2:40 AM=0A=
To: Tomar Amit-B51888=0A=
Cc: linuxppc-dev@lists.ozlabs.org; agraf@suse.de=0A=
Subject: Re: [Patch] :Fix ISR return value in i2c-mpc.c=0A=
=0A=
On Fri, 2014-12-12 at 11:17 +0000, Amit Tomar wrote:=0A=
> In current scenario, ISR of i2c-mpc.c is returning IRQ_HANDLED for doing =
nothing which is not right .=0A=
>=0A=
> With below patch ISR now return IRQ_NONE for doing nothing and IRQ_HANDLE=
D for doing handler work.=0A=
=0A=
Wrap the commit message at around 65-70 characters, change the subject=0A=
to "[PATCH] i2c/mpc: Fix ISR return value", and send to the proper=0A=
mailing list/maintainers for i2c (see the MAINTAINERS file).=0A=
=0A=
-Scott=0A=
=0A=
=0A=
^ permalink raw reply
* [PATCH] powerpc/pci: remove the multi-init for pci_dn->phb
From: Wei Yang @ 2014-12-13 3:09 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Wei Yang
pci_dn->phb is set to phb in update_dn_pci_info(), if succeed.
This patch removes the duplication of pci_dn->phb initialization.
Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
---
arch/powerpc/kernel/pci_dn.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/kernel/pci_dn.c b/arch/powerpc/kernel/pci_dn.c
index ddae246..d40b579 100644
--- a/arch/powerpc/kernel/pci_dn.c
+++ b/arch/powerpc/kernel/pci_dn.c
@@ -382,7 +382,6 @@ void pci_devs_phb_init_dynamic(struct pci_controller *phb)
pdn = dn->data;
if (pdn) {
pdn->devfn = pdn->busno = -1;
- pdn->phb = phb;
phb->firmware_data = pdn;
}
--
1.7.9.5
^ permalink raw reply related
* Re: [Patch] :Fix ISR return value in i2c-mpc.c
From: Scott Wood @ 2014-12-12 21:10 UTC (permalink / raw)
To: Amit Tomar; +Cc: linuxppc-dev@lists.ozlabs.org, agraf@suse.de
In-Reply-To: <BL2PR03MB4496E03E1930685FD2A4FD483600@BL2PR03MB449.namprd03.prod.outlook.com>
On Fri, 2014-12-12 at 11:17 +0000, Amit Tomar wrote:
> In current scenario, ISR of i2c-mpc.c is returning IRQ_HANDLED for doing nothing which is not right .
>
> With below patch ISR now return IRQ_NONE for doing nothing and IRQ_HANDLED for doing handler work.
Wrap the commit message at around 65-70 characters, change the subject
to "[PATCH] i2c/mpc: Fix ISR return value", and send to the proper
mailing list/maintainers for i2c (see the MAINTAINERS file).
-Scott
^ permalink raw reply
* RE: [Patch] :Fix ISR return value in i2c-mpc.c
From: Amit Tomar @ 2014-12-12 11:17 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org; +Cc: agraf@suse.de
In-Reply-To: <BL2PR03MB4495ADAE7D752F82B58B1D783600@BL2PR03MB449.namprd03.prod.outlook.com>
In current scenario, ISR of i2c-mpc.c is returning IRQ_HANDLED for doing no=
thing which is not right .
With below patch ISR now return IRQ_NONE for doing nothing and IRQ_HANDLED =
for doing handler work.
Signed-off-by: Amit Singh Tomar <amit.tomar@freescale.com>
---
drivers/i2c/busses/i2c-mpc.c |=A0=A0=A0 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 0edf630..7a3136f 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -95,8 +95,9 @@ static irqreturn_t mpc_i2c_isr(int irq, void *dev_id)
=A0=A0=A0=A0=A0=A0=A0 i2c->interrupt =3D readb(i2c->base + MPC_I2C_SR);
=A0=A0=A0=A0=A0=A0=A0 writeb(0, i2c->base + MPC_I2C_SR);
=A0=A0=A0=A0=A0=A0=A0 wake_up(&i2c->queue);
+=A0=A0 =A0=A0 return IRQ_HANDLED;
=A0=A0=A0 }
-=A0 return IRQ_HANDLED;
+ =A0return IRQ_NONE;
}
/* Sometimes 9th clock pulse isn't generated, and slave doesn't release
--=20
1.7.9.5
^ permalink raw reply related
* [PATCH] powerpc/powernv: force all CPUs to be bootable
From: Greg Kurz @ 2014-12-12 11:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood
The subcore logic needs all the CPUs declared in the DT to be bootable,
otherwise the kernel hangs at boot time. Since subcore support starts
with POWER8, we can keep the current behaviour for older CPUs.
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
---
Since smt-enabled is still needed by Freescale, the choice was made to fix
powernv only. I could test that smt-enabled is still honored on POWER7 and
ignored on POWER8, as expected.
arch/powerpc/platforms/powernv/smp.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/smp.c b/arch/powerpc/platforms/powernv/smp.c
index b716f66..5b6e002 100644
--- a/arch/powerpc/platforms/powernv/smp.c
+++ b/arch/powerpc/platforms/powernv/smp.c
@@ -198,13 +198,24 @@ static void pnv_smp_cpu_kill_self(void)
#endif /* CONFIG_HOTPLUG_CPU */
+static int pnv_cpu_bootable(unsigned int nr)
+{
+ /* Starting with POWER8, all CPUs need to be booted to avoid hangs
+ * during subcore init.
+ */
+ if (cpu_has_feature(CPU_FTR_ARCH_207S))
+ return 1;
+
+ return smp_generic_cpu_bootable(nr);
+}
+
static struct smp_ops_t pnv_smp_ops = {
.message_pass = smp_muxed_ipi_message_pass,
.cause_ipi = NULL, /* Filled at runtime by xics_smp_probe() */
.probe = xics_smp_probe,
.kick_cpu = pnv_smp_kick_cpu,
.setup_cpu = pnv_smp_setup_cpu,
- .cpu_bootable = smp_generic_cpu_bootable,
+ .cpu_bootable = pnv_cpu_bootable,
#ifdef CONFIG_HOTPLUG_CPU
.cpu_disable = pnv_smp_cpu_disable,
.cpu_die = generic_cpu_die,
^ permalink raw reply related
* Re: [Patch] :Fix ISR return value in i2c-mpc.c
From: Alexander Graf @ 2014-12-12 10:52 UTC (permalink / raw)
To: Amit Tomar; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <BL2PR03MB4495ADAE7D752F82B58B1D783600@BL2PR03MB449.namprd03.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 413 bytes --]
> Am 12.12.2014 um 09:08 schrieb Amit Tomar <Amit.Tomar@freescale.com>:
>
> ISR should return IRQ_HANDLED only in case of handling something.
>
>
> Signed-off-by: Amit Singh Tomar <amit.tomar@freescale.com>
Oh, this is on the Linux side. Sorry, please ignore my previous email.
Please provide some information on what breakage you're fixing with the patch in the patch description.
Alex
[-- Attachment #2: Type: text/html, Size: 2233 bytes --]
^ permalink raw reply
* Re: [Patch] :Fix ISR return value in i2c-mpc.c
From: Alexander Graf @ 2014-12-12 10:50 UTC (permalink / raw)
To: Amit Tomar; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <BL2PR03MB4495ADAE7D752F82B58B1D783600@BL2PR03MB449.namprd03.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 291 bytes --]
> Am 12.12.2014 um 09:08 schrieb Amit Tomar <Amit.Tomar@freescale.com>:
>
> ISR should return IRQ_HANDLED only in case of handling something.
>
>
> Signed-off-by: Amit Singh Tomar <amit.tomar@freescale.com>
Please just send a v2 of your patch with the below fix included :).
Alex
[-- Attachment #2: Type: text/html, Size: 2094 bytes --]
^ permalink raw reply
* [PATCH] Update CXL ABI documentation
From: Philippe Bergheaud @ 2014-12-12 10:28 UTC (permalink / raw)
To: Michael Ellerman; +Cc: mikey, linuxppc-dev, imunsie
From: Philippe Bergheaud <felix@linux.vnet.ibm.com>
This fixes two typos and explains where shared attributes are stored.
Signed-off-by: Philippe Bergheaud <felix@linux.vnet.ibm.com>
Acked-by: Michael Neuling <mikey@neuling.org>
---
Documentation/ABI/testing/sysfs-class-cxl | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-cxl b/Documentation/ABI/testing/sysfs-class-cxl
index faf9479..3393ee6 100644
--- a/Documentation/ABI/testing/sysfs-class-cxl
+++ b/Documentation/ABI/testing/sysfs-class-cxl
@@ -1,3 +1,9 @@
+Note: Attributes that are shared between devices are stored in the directory
+pointed to by the symlink device/.
+Example: The real path of the attribute /sys/class/cxl/afu0.0s/irqs_max is
+/sys/class/cxl/afu0.0s/device/irqs_max, i.e. /sys/class/cxl/afu0.0/irqs_max.
+
+
Slave contexts (eg. /sys/class/cxl/afu0.0s):
What: /sys/class/cxl/<afu>/irqs_max
@@ -67,7 +73,7 @@ Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the current version of the kernel/user API.
-What: /sys/class/cxl/<afu>/api_version_com
+What: /sys/class/cxl/<afu>/api_version_compatible
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
@@ -75,7 +81,6 @@ Description: read only
this this kernel supports.
-
Master contexts (eg. /sys/class/cxl/afu0.0m)
What: /sys/class/cxl/<afu>m/mmio_size
@@ -106,7 +111,7 @@ Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Identifies the CAIA Version the card implements.
-What: /sys/class/cxl/<card>/psl_version
+What: /sys/class/cxl/<card>/psl_revision
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
--
1.7.2.5
^ permalink raw reply related
* [Patch] :Fix ISR return value in i2c-mpc.c
From: Amit Tomar @ 2014-12-12 8:08 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org; +Cc: agraf@suse.de
[-- Attachment #1: Type: text/plain, Size: 782 bytes --]
ISR should return IRQ_HANDLED only in case of handling something.
Signed-off-by: Amit Singh Tomar <amit.tomar@freescale.com>
---
drivers/i2c/busses/i2c-mpc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 0edf630..7a3136f 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -95,8 +95,9 @@ static irqreturn_t mpc_i2c_isr(int irq, void *dev_id)
i2c->interrupt = readb(i2c->base + MPC_I2C_SR);
writeb(0, i2c->base + MPC_I2C_SR);
wake_up(&i2c->queue);
+ return IRQ_HANDLED;
}
- return IRQ_HANDLED;
+ return IRQ_NONE;
}
/* Sometimes 9th clock pulse isn't generated, and slave doesn't release
--
1.7.9.5
[-- Attachment #2: Type: text/html, Size: 3559 bytes --]
^ permalink raw reply related
* Re: [v3] i2c: Driver to expose PowerNV platform i2c busses
From: Michael Ellerman @ 2014-12-12 5:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: devicetree, wsa, linuxppc-dev, linux-i2c, Neelesh Gupta,
Jeremy Kerr
In-Reply-To: <1418120492.13358.45.camel@kernel.crashing.org>
On Tue, 2014-12-09 at 21:21 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2014-12-09 at 20:45 +1100, Michael Ellerman wrote:
> > On Mon, 2014-08-12 at 06:36:16 UTC, Neelesh Gupta wrote:
> > > The patch exposes the available i2c busses on the PowerNV platform
> > > to the kernel and implements the bus driver to support i2c and
> > > smbus commands.
> > > The driver uses the platform device infrastructure to probe the busses
> > > on the platform and registers them with the i2c driver framework.
> >
> > > arch/powerpc/include/asm/opal.h | 29 ++
> > > arch/powerpc/platforms/powernv/opal-wrappers.S | 1
> > > arch/powerpc/platforms/powernv/opal.c | 11 +
> >
> > This had major conflicts in the above files.
> >
> > I've fixed it up but please check I did it correctly:
> >
> > https://github.com/mpe/powerpc-merge/commits/pw/neelesh-i2c
> >
> > It also doesn't build as a module:
> >
> > $ grep CONFIG_I2C_OPAL .config
> > CONFIG_I2C_OPAL=m
> > $ make ...
> > ...
> > ERROR: "opal_i2c_request" [drivers/i2c/busses/i2c-opal.ko] undefined!
>
> Right that needs to be exported, however for those OPAL wrappers to work
> when exported as modules on an LE kernel with ABI v2 (pfiew !) we need
> another patch from jk to sort out the external entry to the asm...
>
> Jeremy, is that already in or not yet ?
Yeah it's been in since October.
Please send a v4 with a fix for this Neelesh.
cheers
^ permalink raw reply
* Re: [PATCH 2 0/4] powerpc: don't mess with SMT at boot time
From: Michael Ellerman @ 2014-12-12 5:22 UTC (permalink / raw)
To: Greg Kurz; +Cc: linuxppc-dev
In-Reply-To: <20141205150405.11028.27445.stgit@bahia.lab.toulouse-stg.fr.ibm.com>
On Fri, 2014-12-05 at 16:13 +0100, Greg Kurz wrote:
> As requested by mpe, this series now covers both the smt-enabled
> kernel parameter and the ibm,smt-enabled property. The cleanup was
> split into 3 separate patches to ease review, but I guess they
> could be folded into a single patch as well.
Sorry to send you down the garden path Greg. It would have been a nice
cleanup, but seems the FSL folks still see value in smt-enabled.
So can you rework it to just ignore smt-enabled on powernv.
That should be as simple as implementing a powernv_cpu_bootable() that always
returns true.
cheers
^ permalink raw reply
* Re: [PATCH 2 1/4] powerpc: drop the ability to tweak SMT mode at boot time
From: Michael Ellerman @ 2014-12-12 5:19 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Greg Kurz
In-Reply-To: <1418255437.5581.45.camel@freescale.com>
On Wed, 2014-12-10 at 17:50 -0600, Scott Wood wrote:
> On Wed, 2014-12-10 at 13:14 +1100, Michael Ellerman wrote:
> > On Tue, 2014-12-09 at 18:14 -0600, Scott Wood wrote:
> > > What benefit is there to ignoring "scripture" here? Going from an easy
> > > to use command line option to needing to mess around with the dts file
> > > is not a usability improvement. If you want to make it Freescale-only,
> > > fine. If you want to push me to fix the problems with the
> > > implementation, fine.
> >
> > It's easy to use but it doesn't necessarily work.
> >
> > You said in your other mail to Greg "Sometimes it's useful to ensure that the
> > second thread has never run when debugging a problem.".
> >
> > But you don't know that, for all you know your firmware has started the thread
> > and it's busy looping somewhere. Perhaps you guys know that your firmware
> > doesn't do that, but it's still a hack.
>
> I know that our firmware doesn't do that, and I can verify by reading
> the relevant register.
Lucky you :)
> > We end up with cpus in the present map, but we have no idea where they are or
> > what they are doing.
>
> Can we check smt-enabled a little earlier and refrain from marking the
> secondary threads as present if smt is disabled?
We could, and that would make the semantics much saner. But it would actually
be exactly the opposite of what the folks who originally hit this bug want to
happen.
They are using it as a shortcut for cpu hotunplug, ie. they want the threads
asleep in Linux ready to be hotplugged back in.
This is why I wanted to remove it, because those are both valid expectations of
what smt-enabled=off should do, but they are mutually exclusive. Not to mention
that the current code doesn't implement either of those properly.
Anyway for now we should just ignore it on powernv. We can look at doing
something saner in general in future.
cheers
^ permalink raw reply
* [PATCH] powerpc/powernv: Print the M64 range information in bootup log
From: Wei Yang @ 2014-12-12 4:39 UTC (permalink / raw)
To: gwshan, linuxppc-dev; +Cc: Wei Yang
In-Reply-To: <20141211215818.GA6584@shangw>
The M64 range information is missed in dmesg, which would be helpful in debug.
This patch prints the M64 range information in the same format as M32.
Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
V1:
* use pr_info() instead of printk(KERN_INFO)
---
arch/powerpc/platforms/powernv/pci-ioda.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 21c8b4d..4fbdc7d 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -369,6 +369,9 @@ static void __init pnv_ioda_parse_m64_window(struct pnv_phb *phb)
phb->ioda.m64_segsize = phb->ioda.m64_size / phb->ioda.total_pe;
phb->ioda.m64_base = pci_addr;
+ pr_info(" MEM64 0x%016llx..0x%016llx -> 0x%016llx\n",
+ res->start, res->end, pci_addr);
+
/* Use last M64 BAR to cover M64 window */
phb->ioda.m64_bar_idx = 15;
phb->init_m64 = pnv_ioda2_init_m64;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] powerpc/powernv: Print the M64 range information
From: Wei Yang @ 2014-12-12 4:28 UTC (permalink / raw)
To: Gavin Shan; +Cc: Wei Yang, linuxppc-dev
In-Reply-To: <20141211215818.GA6584@shangw>
On Fri, Dec 12, 2014 at 08:58:19AM +1100, Gavin Shan wrote:
>On Thu, Dec 11, 2014 at 03:29:01PM +0800, Wei Yang wrote:
>>On Thu, Dec 11, 2014 at 09:40:30AM +1100, Gavin Shan wrote:
>>>On Wed, Dec 10, 2014 at 10:29:37PM +0800, Wei Yang wrote:
>>>>The M64 range information is missed, which would be helpful in debug.
>>>>
>>>>This patch print the M64 range information in the same format as M32.
>
>s/print/prints
>
>>>>
>>>>Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
>>>>---
>>>> arch/powerpc/platforms/powernv/pci-ioda.c | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>>>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
>>>>index 21c8b4d..34f1a27 100644
>>>>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
>>>>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>>>>@@ -369,6 +369,9 @@ static void __init pnv_ioda_parse_m64_window(struct pnv_phb *phb)
>>>> phb->ioda.m64_segsize = phb->ioda.m64_size / phb->ioda.total_pe;
>>>> phb->ioda.m64_base = pci_addr;
>>>>
>>>>+ printk(KERN_INFO " MEM64 0x%016llx..0x%016llx -> 0x%016llx\n",
>>>>+ res->start, res->end, pci_addr);
>>>>+
>>>
>>>Please output segment size if you think it's helpful as well.
>>
>>The M64 segment size is printed in pnv_pci_init_ioda_phb() line 2620.
>>
>
>Yes, it has been printed separately. So the change looks good to me
>after you replace "printk(KERN_INFO ...)" with pr_info. Could you please
>send updated version and include following line if you want:
Sure, glad to.
>
>Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>
>Thanks,
>Gavin
--
Richard Yang
Help you, Help me
^ permalink raw reply
* Re: powerpc/kdump: skip enabling big endian exception during crash
From: Mahesh Jagannath Salgaonkar @ 2014-12-12 4:06 UTC (permalink / raw)
To: Michael Ellerman, Hari Bathini, linuxppc-dev; +Cc: Anton Blanchard
In-Reply-To: <20141211224016.86E111400F1@ozlabs.org>
On 12/12/2014 04:10 AM, Michael Ellerman wrote:
> On Thu, 2014-11-12 at 16:44:54 UTC, Hari Bathini wrote:
>> In LE kernel, we currently have a hack for kexec that resets the exception endian
>> before starting a new kernel as the kernel that is loaded could be a big endian
>> or a little endian kernel. In kdump case, resetting exception endian fails when
>> one or more cpus is disabled. But in case of kdump, we can conveniently ignore
>> resetting endianess as crashkernel is always of same endianess as primary kernel.
>
> No, it's not guaranteed to be the same endianess.
>
> That tends to be what people do in practice, but it's not an assumption you can
> hard code.
Agree. The other solution could be to wakeup offline CPUs in crash path
as we do it in normal kexec path. PHYP expects all partitions processors
MSR[EE] = 0 while we call pseries_big_endian_exceptions(). Waking up
offline CPUs will help to achieve that. But since we are already in
crashed kernel context I am not sure how safe is to call
wake_offline_cpus().
Thanks,
-Mahesh.
^ 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