* Re: [PATCH v2 2/2] ARM: dts: Append clock bindings for sai2 on VF610 platform
From: Nicolin Chen @ 2014-04-15 2:28 UTC (permalink / raw)
To: Mark Brown
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
ijc+devicetree, linux-kernel, robh+dt, timur, Li.Xiubo, rob,
galak, shawn.guo, linuxppc-dev
In-Reply-To: <20140414203851.GD25182@sirena.org.uk>
On Mon, Apr 14, 2014 at 09:38:51PM +0100, Mark Brown wrote:
> On Wed, Apr 02, 2014 at 06:10:20PM +0800, Nicolin Chen wrote:
> > Since we added fours clock to the DT binding, we should update the current
> > SAI dts/dtsi so as not to break their functions.
>
> This doesn't apply against v3.15-rc1, can you please check and resend?
Please disregard this patch, since my v6 patch was compatible with the old
binding, the patch here is provisionally useless and I can later send it
via Shawn's tree.
Thank you,
Nicolin
^ permalink raw reply
* Re: [PATCH v2 1/2] ASoC: fsl_sai: Add clock controls for SAI
From: Nicolin Chen @ 2014-04-15 2:26 UTC (permalink / raw)
To: Mark Brown
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
ijc+devicetree, linux-kernel, robh+dt, timur, Li.Xiubo, rob,
galak, shawn.guo, linuxppc-dev
In-Reply-To: <20140414204331.GE25182@sirena.org.uk>
On Mon, Apr 14, 2014 at 09:43:31PM +0100, Mark Brown wrote:
> On Wed, Apr 02, 2014 at 06:10:19PM +0800, Nicolin Chen wrote:
>
> > -- clock-names : Must include the "sai" entry.
> > +- clock-names : Must include the "bus" for register access and "mclk1" "mclk2"
> > + "mclk3" for bit clock and frame clock providing.
>
> This breaks compatibilty with old DTs - it just removes the "sai" name.
> It's OK to deprecate the "sai" clock name but you need to keep support
> for DTs that only specify that, there's no code for that left in the
> driver.
Sir, you've already applied the v6 of this patch last week :)
And I can still find it in topic/fsl-sai.
ca3e35c ASoC: fsl_sai: Add clock controls for SAI
And regarding the old DTs compatibilty, Shawn has already reminded me
in his comments against one of the version. I took his advice and made
the patch compatible with the old 'sai' clock binding within that v6.
Thank you,
Nicolin
^ permalink raw reply
* RE: [PATCH 1/2] powerpc/mpc85xx: add two functions to get suspend state which is standby or mem
From: Dongsheng.Wang @ 2014-04-15 2:19 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev@lists.ozlabs.org, chenhui.zhao@freescale.com,
Jason.Jin@freescale.com
In-Reply-To: <1397518031.20280.229.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVHVlc2RheSwgQXByaWwgMTUsIDIwMTQgNzoyNyBBTQ0KPiBUbzogV2FuZyBE
b25nc2hlbmctQjQwNTM0DQo+IENjOiBKaW4gWmhlbmd4aW9uZy1SNjQxODg7IExpIFlhbmctTGVv
LVI1ODQ3MjsgWmhhbyBDaGVuaHVpLUIzNTMzNjsgbGludXhwcGMtDQo+IGRldkBsaXN0cy5vemxh
YnMub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMS8yXSBwb3dlcnBjL21wYzg1eHg6IGFkZCB0
d28gZnVuY3Rpb25zIHRvIGdldCBzdXNwZW5kIHN0YXRlDQo+IHdoaWNoIGlzIHN0YW5kYnkgb3Ig
bWVtDQo+IA0KPiBPbiBNb24sIDIwMTQtMDQtMTQgYXQgMTA6MjQgKzA4MDAsIERvbmdzaGVuZyBX
YW5nIHdyb3RlOg0KPiA+IEZyb206IFdhbmcgRG9uZ3NoZW5nIDxkb25nc2hlbmcud2FuZ0BmcmVl
c2NhbGUuY29tPg0KPiA+DQo+ID4gQWRkIHNldF9wbV9zdXNwZW5kX3N0YXRlICYgcG1fc3VzcGVu
ZF9zdGF0ZSBmdW5jdGlvbnMgdG8gc2V0L2dldCBzdXNwZW5kIHN0YXRlLg0KPiA+IFdoZW4gc3lz
dGVtIGdvaW5nIHRvIHNsZWVwLCBkZXZpY2VzIGNhbiBnZXQgdGhlIHN5c3RlbSBzdXNwZW5kDQo+
ID4gc3RhdGUoU1RBTkRCWS9NRU0pIHRocm91Z2ggcG1fc3VzcGVuZF9zdGF0ZSBmdW5jdGlvbiBh
bmQgaGFuZGxlIGRpZmZlcmVudA0KPiBzaXR1YXRpb25zLg0KPiA+DQo+ID4gU2lnbmVkLW9mZi1i
eTogV2FuZyBEb25nc2hlbmcgPGRvbmdzaGVuZy53YW5nQGZyZWVzY2FsZS5jb20+DQo+ID4NCj4g
PiBkaWZmIC0tZ2l0IGEvYXJjaC9wb3dlcnBjL3BsYXRmb3Jtcy84NXh4L2NvbW1vbi5jDQo+ID4g
Yi9hcmNoL3Bvd2VycGMvcGxhdGZvcm1zLzg1eHgvY29tbW9uLmMNCj4gPiBpbmRleCBiNTY0YjVl
Li4zODUzZDQzIDEwMDY0NA0KPiA+IC0tLSBhL2FyY2gvcG93ZXJwYy9wbGF0Zm9ybXMvODV4eC9j
b21tb24uYw0KPiA+ICsrKyBiL2FyY2gvcG93ZXJwYy9wbGF0Zm9ybXMvODV4eC9jb21tb24uYw0K
PiA+IEBAIC04LDYgKzgsNyBAQA0KPiA+DQo+ID4gICNpbmNsdWRlIDxsaW51eC9vZl9pcnEuaD4N
Cj4gPiAgI2luY2x1ZGUgPGxpbnV4L29mX3BsYXRmb3JtLmg+DQo+ID4gKyNpbmNsdWRlIDxsaW51
eC9zdXNwZW5kLmg+DQo+ID4NCj4gPiAgI2luY2x1ZGUgPGFzbS9xZS5oPg0KPiA+ICAjaW5jbHVk
ZSA8c3lzZGV2L2NwbTJfcGljLmg+DQo+ID4gQEAgLTQ3LDYgKzQ4LDE5IEBAIGludCBfX2luaXQg
bXBjODV4eF9jb21tb25fcHVibGlzaF9kZXZpY2VzKHZvaWQpDQo+ID4gIHsNCj4gPiAgCXJldHVy
biBvZl9wbGF0Zm9ybV9idXNfcHJvYmUoTlVMTCwgbXBjODV4eF9jb21tb25faWRzLCBOVUxMKTsg
IH0NCj4gPiArDQo+ID4gK3N0YXRpYyBzdXNwZW5kX3N0YXRlX3QgcG1fc3RhdGU7DQo+ID4gKw0K
PiA+ICt2b2lkIHNldF9wbV9zdXNwZW5kX3N0YXRlKHN1c3BlbmRfc3RhdGVfdCBzdGF0ZSkgew0K
PiA+ICsJcG1fc3RhdGUgPSBzdGF0ZTsNCj4gPiArfQ0KPiA+ICsNCj4gPiArc3VzcGVuZF9zdGF0
ZV90IHBtX3N1c3BlbmRfc3RhdGUodm9pZCkgew0KPiA+ICsJcmV0dXJuIHBtX3N0YXRlOw0KPiA+
ICt9DQo+IA0KPiBUaGVzZSBuZWVkIHRvIGJlIG5hbWVzcGFjZWQgdG8gaW5kaWNhdGUgdGhhdCB0
aGV5IGFwcGx5IG9ubHkgdG8gbXBjODV4eC4NCj4gV2hlcmUgZG8geW91IHBsYW4gb24gdXNpbmcg
dGhlc2UgZnJvbSwgdGhhdCBtcGM4NXh4IGNhbiBiZSBzYWZlbHkgYXNzdW1lZD8NCj4gDQoNCk1w
aWMgdGltZXIgYW5kIFBDSWUgZHJpdmVyLg0KDQo+IFRoaXMgc2VlbXMgbGlrZSBhIGZlYXR1cmUg
dGhhdCBzaG91bGQgYmUgaW1wbGVtZW50ZWQgaW4gZ2VuZXJpYyBjb2RlIGluc3RlYWQuDQo+IA0K
DQpPSywgSSB3aWxsIG1vdmUgdGhpcyB0byBhIGdlbmVyaWMgcGF0aC4NCg0KUmVnYXJkcywNCi1E
b25nc2hlbmcNCg0KPiAtU2NvdHQNCj4gDQoNCg==
^ permalink raw reply
* Re: [PATCH v3] dmaengine: driver support for FSL RaidEngine device.
From: Dan Williams @ 2014-04-15 0:30 UTC (permalink / raw)
To: Xuelin Shi
Cc: Harninder Rai, andriy.shevchenko@intel.com, Koul, Vinod,
Naveen Burmi, dmaengine@vger.kernel.org, linuxppc-dev
In-Reply-To: <0c8d1963a25648f8a8f820bbc55afe4f@BL2PR03MB147.namprd03.prod.outlook.com>
On Sun, Apr 13, 2014 at 7:48 PM, Xuelin Shi <xuelin.shi@freescale.com> wrote:
> Hi Dan,
>
> fsl dma device and fsl raid device are two differenct devices that both provide async_memcpy
> capability, so I use !FSL_DMA to disable the fsl dma device.
>
> That's to say, either select fsldma device, either fsl raid device.
>
Right, but that's not what your proposed Kconfig dependency line does.
You want something like "depends on FSL_SOC && !(FSL_DMA || FSL_DMA=m)"
However, the more problematic option is ASYNC_TX_CHANNEL_SWITCH. That
option is problematic for RAID, so I propose "depend on
!ASYNC_TX_CHANNEL_SWITCH" since that addresses both problems.
^ permalink raw reply
* Re: [PATCH 2/2] fsl/mpic_timer: make mpic_timer to support deep sleep feature
From: Scott Wood @ 2014-04-14 23:35 UTC (permalink / raw)
To: Dongsheng Wang; +Cc: linuxppc-dev, chenhui.zhao, jason.jin
In-Reply-To: <1397442250-14886-2-git-send-email-dongsheng.wang@freescale.com>
On Mon, 2014-04-14 at 10:24 +0800, Dongsheng Wang wrote:
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> At T104x platfrom the timer clock will be changed when system going to
> deep sleep.
Could you elaborate on what is changing and why?
> +#include <asm/mpc85xx.h>
> #include <asm/mpic_timer.h>
So much for, "The driver currently is only tested on fsl chip, but it
can potentially support other global timers complying to OpenPIC
standard."
> #define FSL_GLOBAL_TIMER 0x1
> @@ -71,8 +74,10 @@ struct timer_group_priv {
> struct timer_regs __iomem *regs;
> struct mpic_timer timer[TIMERS_PER_GROUP];
> struct list_head node;
> + unsigned long idle;
> unsigned int timerfreq;
> - unsigned int idle;
Why?
> + unsigned int suspended_timerfreq;
> + unsigned int resume_timerfreq;
> unsigned int flags;
> spinlock_t lock;
> void __iomem *group_tcr;
> @@ -88,6 +93,7 @@ static struct cascade_priv cascade_timer[] = {
> };
>
> static LIST_HEAD(timer_group_list);
> +static int switch_freq_flag;
Needs documentation, and based on "_flag" it should probably be a bool.
> static void convert_ticks_to_time(struct timer_group_priv *priv,
> const u64 ticks, struct timeval *time)
> @@ -423,6 +429,33 @@ struct mpic_timer *mpic_request_timer(irq_handler_t fn, void *dev,
> }
> EXPORT_SYMBOL(mpic_request_timer);
>
> +static void timer_group_get_suspended_freq(struct timer_group_priv *priv)
> +{
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,qoriq-clockgen-2.0");
> + if (!np) {
> + pr_err("mpic timer: Missing clockgen device node.\n");
Why is it an error to not have a 2.0 QorIQ clockgen?
> + return;
> + }
> +
> + of_property_read_u32(np, "clock-frequency", &priv->suspended_timerfreq);
> + of_node_put(np);
Shouldn't this go through the clock API?
> +}
> +
> +static int need_to_switch_freq(void)
> +{
> + u32 svr;
> +
> + svr = mfspr(SPRN_SVR);
> + if (SVR_SOC_VER(svr) == SVR_T1040 ||
> + SVR_SOC_VER(svr) == SVR_T1042)
> + return 1;
Explain why this is specific to T104x.
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/mpc85xx: add two functions to get suspend state which is standby or mem
From: Scott Wood @ 2014-04-14 23:27 UTC (permalink / raw)
To: Dongsheng Wang; +Cc: linuxppc-dev, chenhui.zhao, jason.jin
In-Reply-To: <1397442250-14886-1-git-send-email-dongsheng.wang@freescale.com>
On Mon, 2014-04-14 at 10:24 +0800, Dongsheng Wang wrote:
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> Add set_pm_suspend_state & pm_suspend_state functions to set/get suspend state.
> When system going to sleep, devices can get the system suspend state(STANDBY/MEM)
> through pm_suspend_state function and handle different situations.
>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> diff --git a/arch/powerpc/platforms/85xx/common.c b/arch/powerpc/platforms/85xx/common.c
> index b564b5e..3853d43 100644
> --- a/arch/powerpc/platforms/85xx/common.c
> +++ b/arch/powerpc/platforms/85xx/common.c
> @@ -8,6 +8,7 @@
>
> #include <linux/of_irq.h>
> #include <linux/of_platform.h>
> +#include <linux/suspend.h>
>
> #include <asm/qe.h>
> #include <sysdev/cpm2_pic.h>
> @@ -47,6 +48,19 @@ int __init mpc85xx_common_publish_devices(void)
> {
> return of_platform_bus_probe(NULL, mpc85xx_common_ids, NULL);
> }
> +
> +static suspend_state_t pm_state;
> +
> +void set_pm_suspend_state(suspend_state_t state)
> +{
> + pm_state = state;
> +}
> +
> +suspend_state_t pm_suspend_state(void)
> +{
> + return pm_state;
> +}
These need to be namespaced to indicate that they apply only to mpc85xx.
Where do you plan on using these from, that mpc85xx can be safely
assumed?
This seems like a feature that should be implemented in generic code
instead.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Add OCA4080 board support
From: Scott Wood @ 2014-04-14 22:28 UTC (permalink / raw)
To: Martijn de Gouw; +Cc: stef.van.os, Martijn de Gouw, linuxppc-dev
In-Reply-To: <1397478910-26361-1-git-send-email-martijn.de.gouw@prodrive-technologies.com>
On Mon, 2014-04-14 at 14:35 +0200, Martijn de Gouw wrote:
> + lbc: localbus@ffe124000 {
> + reg = <0xf 0xfe124000 0 0x1000>;
> + ranges = <0 0 0xf 0xef800000 0x800000>;
> +
> + flash@0,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "cfi-flash";
> + reg = <0 0 0x00800000>;
> + bank-width = <2>;
> + device-width = <2>;
> + partition@rcw {
> + label = "rcw";
> + reg = <0x00000000 0x00020000>;
> + };
> + partition@fman-ucode {
> + label = "fman-ucode";
> + reg = <0x00020000 0x00020000>;
> + };
> + partition@user {
> + label = "user";
> + reg = <0x00040000 0x00680000>;
> + };
> + partition@env0 {
> + label = "env0";
> + reg = <0x006c0000 0x00020000>;
> + };
> + partition@env1 {
> + label = "env1";
> + reg = <0x006e0000 0x00020000>;
> + };
> + partition@u-boot {
> + label = "u-boot";
> + reg = <0x00700000 0x00080000>;
> + };
> + partition@u-boot-backup {
> + label = "u-boot-backup";
> + reg = <0x00780000 0x00080000>;
> + };
These are not valid unit addresses. Regardless, please don't put
partition info in the dts.
-Scott
^ permalink raw reply
* [PATCH 18/20] cpufreq: pasemi: Use cpufreq_for_each_entry macro for iteration
From: Stratos Karafotis @ 2014-04-14 21:10 UTC (permalink / raw)
To: Olof Johansson, Rafael J. Wysocki, Viresh Kumar
Cc: linuxppc-dev, LKML, cpufreq@vger.kernel.org,
linux-pm@vger.kernel.org
The cpufreq core supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
---
Please note that I was no able to compile test this patch due to
lack of cross compiler.
drivers/cpufreq/pasemi-cpufreq.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/cpufreq/pasemi-cpufreq.c b/drivers/cpufreq/pasemi-cpufreq.c
index 84c84b5..9a64492 100644
--- a/drivers/cpufreq/pasemi-cpufreq.c
+++ b/drivers/cpufreq/pasemi-cpufreq.c
@@ -136,9 +136,10 @@ void restore_astate(int cpu)
static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
+ struct cpufreq_frequency_table *pos;
const u32 *max_freqp;
u32 max_freq;
- int i, cur_astate;
+ int cur_astate;
struct resource res;
struct device_node *cpu, *dn;
int err = -ENODEV;
@@ -197,10 +198,9 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
pr_debug("initializing frequency table\n");
/* initialize frequency table */
- for (i=0; pas_freqs[i].frequency!=CPUFREQ_TABLE_END; i++) {
- pas_freqs[i].frequency =
- get_astate_freq(pas_freqs[i].driver_data) * 100000;
- pr_debug("%d: %d\n", i, pas_freqs[i].frequency);
+ cpufreq_for_each_entry(pos, pas_freqs) {
+ pos->frequency = get_astate_freq(pos->driver_data) * 100000;
+ pr_debug("%lu: %d\n", pos - pas_freqs, pos->frequency);
}
cur_astate = get_cur_astate(policy->cpu);
--
1.9.0
^ permalink raw reply related
* Re: [PATCH] ASoC: fsl_sai: Use FSL_SAI_xXR() and regmap_update_bits() to simplify code
From: Mark Brown @ 2014-04-14 20:47 UTC (permalink / raw)
To: Nicolin Chen; +Cc: alsa-devel, Li.Xiubo, linuxppc-dev, linux-kernel, timur
In-Reply-To: <1397212209-7843-1-git-send-email-Guangyu.Chen@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 152 bytes --]
On Fri, Apr 11, 2014 at 06:30:09PM +0800, Nicolin Chen wrote:
> By doing this, the driver can drop around 50 lines and become neater.
Applied, thanks.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] ASoC: fsl_sai: Add clock controls for SAI
From: Mark Brown @ 2014-04-14 20:43 UTC (permalink / raw)
To: Nicolin Chen
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
ijc+devicetree, linux-kernel, robh+dt, timur, Li.Xiubo, rob,
galak, shawn.guo, linuxppc-dev
In-Reply-To: <12898efab7a5907e6ed1c438a486692f59ef9d8b.1396432924.git.Guangyu.Chen@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 469 bytes --]
On Wed, Apr 02, 2014 at 06:10:19PM +0800, Nicolin Chen wrote:
> -- clock-names : Must include the "sai" entry.
> +- clock-names : Must include the "bus" for register access and "mclk1" "mclk2"
> + "mclk3" for bit clock and frame clock providing.
This breaks compatibilty with old DTs - it just removes the "sai" name.
It's OK to deprecate the "sai" clock name but you need to keep support
for DTs that only specify that, there's no code for that left in the
driver.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] ARM: dts: Append clock bindings for sai2 on VF610 platform
From: Mark Brown @ 2014-04-14 20:38 UTC (permalink / raw)
To: Nicolin Chen
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
ijc+devicetree, linux-kernel, robh+dt, timur, Li.Xiubo, rob,
galak, shawn.guo, linuxppc-dev
In-Reply-To: <d09da3eb629143abd3f61ae037af4ddaf7286a83.1396432924.git.Guangyu.Chen@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 262 bytes --]
On Wed, Apr 02, 2014 at 06:10:20PM +0800, Nicolin Chen wrote:
> Since we added fours clock to the DT binding, we should update the current
> SAI dts/dtsi so as not to break their functions.
This doesn't apply against v3.15-rc1, can you please check and resend?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Fix incorrect condition check in trigger()
From: Mark Brown @ 2014-04-14 20:31 UTC (permalink / raw)
To: Nicolin Chen; +Cc: alsa-devel, Li.Xiubo, linuxppc-dev, linux-kernel, timur
In-Reply-To: <1397225400-2769-1-git-send-email-Guangyu.Chen@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 310 bytes --]
On Fri, Apr 11, 2014 at 10:10:00PM +0800, Nicolin Chen wrote:
> + /* Check if the opposite FRDE is also disabled */
> + if (!(tx ? rcsr & FSL_SAI_CSR_FRDE : tcsr & FSL_SAI_CSR_FRDE)) {
I've applied this since it's a fix but this is *not* a triumph of
legibility, the ternery operator is often not helpful.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] powerpc: Increase COMMAND_LINE_SIZE to 2048 from 512.
From: Joseph Salisbury @ 2014-04-14 18:58 UTC (permalink / raw)
To: linux-kernel, benh, paulus; +Cc: linuxppc-dev, anton, stable
In-Reply-To: <84356b1cb9452226d54641a71e4b1363e78d4417.1397260362.git.joseph.salisbury@canonical.com>
On 04/14/2014 11:30 AM, Joseph Salisbury wrote:
> BugLink: http://bugs.launchpad.net/bugs/1306677
>
> While booting the PPC64EL kernel, the command line gets truncated to 512 characters. This is due to a hard limit of 512 defined for COMMAND_LINE_SIZE. It would be beneficial to have a command line longer than 512 characters, as iscsi targets and cloud-init parameters are passed through the kernel command line.
>
> Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> (supporter:LINUX FOR POWERPC...)
> Cc: Paul Mackerras <paulus@samba.org> (supporter:LINUX FOR POWERPC...)
> Cc: linuxppc-dev@lists.ozlabs.org (open list:LINUX FOR POWERPC...)
> Cc: linux-kernel@vger.kernel.org (open list)
> Cc: stable@vger.kernel.org
>
> ---
> arch/powerpc/boot/ops.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
> index b3218ce..5a01fb1 100644
> --- a/arch/powerpc/boot/ops.h
> +++ b/arch/powerpc/boot/ops.h
> @@ -15,7 +15,7 @@
> #include "types.h"
> #include "string.h"
>
> -#define COMMAND_LINE_SIZE 512
> +#define COMMAND_LINE_SIZE 2048
> #define MAX_PATH_LEN 256
> #define MAX_PROP_LEN 256 /* What should this be? */
>
After further review, it appears ppc does not actually use the define in
the ppc headers but uses the common generic
default(include/uapi/asm-generic/setup.h). COMMAND_LINE_SIZE should
probably become a kernel config option. Do folks agree that is the
correct thing to do? If so, I can re-work the patch.
Thanks,
Joe
^ permalink raw reply
* [PATCH 1/1] powerpc: Increase COMMAND_LINE_SIZE to 2048 from 512.
From: Joseph Salisbury @ 2014-04-14 15:30 UTC (permalink / raw)
To: linux-kernel, benh, paulus; +Cc: linuxppc-dev, stable
In-Reply-To: <cover.1397260361.git.joseph.salisbury@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1306677
While booting the PPC64EL kernel, the command line gets truncated to 512 characters. This is due to a hard limit of 512 defined for COMMAND_LINE_SIZE. It would be beneficial to have a command line longer than 512 characters, as iscsi targets and cloud-init parameters are passed through the kernel command line.
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> (supporter:LINUX FOR POWERPC...)
Cc: Paul Mackerras <paulus@samba.org> (supporter:LINUX FOR POWERPC...)
Cc: linuxppc-dev@lists.ozlabs.org (open list:LINUX FOR POWERPC...)
Cc: linux-kernel@vger.kernel.org (open list)
Cc: stable@vger.kernel.org
---
arch/powerpc/boot/ops.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
index b3218ce..5a01fb1 100644
--- a/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -15,7 +15,7 @@
#include "types.h"
#include "string.h"
-#define COMMAND_LINE_SIZE 512
+#define COMMAND_LINE_SIZE 2048
#define MAX_PATH_LEN 256
#define MAX_PROP_LEN 256 /* What should this be? */
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v3 6/8] DMA: Freescale: change descriptor release process for supporting async_tx
From: Andy Shevchenko @ 2014-04-14 13:41 UTC (permalink / raw)
To: Hongbo Zhang
Cc: leo.li, vkoul, linux-kernel, scottwood, dmaengine, dan.j.williams,
linuxppc-dev
In-Reply-To: <5347A8F2.4050603@freescale.com>
On Fri, 2014-04-11 at 16:33 +0800, Hongbo Zhang wrote:
> >>> + * hardware channel, subsequent descriptors are either in
> >>> + * process or have not been submitted
> >> Dot at the eol. Check in all comments.
> >
> > Even though I saw there are other comments without the dots, I think
> > it is better to have it.
> > Thanks, all.
> >
> Hmm... think it again, it it really necessary to have it?
> Even I have it in my patch, there are already so many comments exists
> without it.
For my opinion is better to keep style in your patches. Better if it
commonly used style in the driver. But comment against comments is
really minor thing.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [PATCH v3 4/8] DMA: Freescale: add fsl_dma_free_descriptor() to reduce code duplication
From: Andy Shevchenko @ 2014-04-14 13:40 UTC (permalink / raw)
To: Hongbo Zhang
Cc: leo.li, vkoul, linux-kernel, scottwood, dmaengine, dan.j.williams,
linuxppc-dev
In-Reply-To: <5347A46B.30206@freescale.com>
On Fri, 2014-04-11 at 16:14 +0800, Hongbo Zhang wrote:
> On 04/10/2014 07:29 PM, Andy Shevchenko wrote:
> > On Thu, 2014-04-10 at 15:10 +0800, hongbo.zhang@freescale.com wrote:
[]
> >> @@ -819,8 +826,7 @@ static void fsldma_cleanup_descriptor(struct fsldma_chan *chan,
> >> dma_run_dependencies(txd);
> >>
> >> dma_descriptor_unmap(txd);
> >> - chan_dbg(chan, "LD %p free\n", desc);
> >> - dma_pool_free(chan->desc_pool, desc, txd->phys);
> >> + fsl_dma_free_descriptor(chan, desc);
> > Here is no list_del() call since it's been called in dma_do_tasklet().
> > What will be the result of double list_del() against the same node?
>
> Not clear with your point.
> This patch is only introducing a common fsl_dma_free_descriptor() to
> reduce code duplication. And later in the patch 6/8 the
> fsldma_cleanup_descriptor() is replaced by fsldma_cleanup_descriptorS().
In the last case you could have a broken kernel which will fails on
double list_del(). I think it's better to leave this one untouched and
you may remove it later.
Or move this patch after you have removed that lines.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH 2/2] PCI/MSI: Phase out pci_enable_msi_block()
From: Alexander Gordeev @ 2014-04-14 13:28 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-pci, linux-mips, x86, linuxppc-dev, linux-s390
In-Reply-To: <20140414120921.GA32132@dhcp-26-207.brq.redhat.com>
There are no users of pci_enable_msi_block() function have
left. Obsolete it in favor of pci_enable_msi_range() and
pci_enable_msi_exact() functions.
Up until now, when enabling MSI mode for a device a single
successful call to arch_msi_check_device() was followed by
a single call to arch_setup_msi_irqs() function.
Yet, if arch_msi_check_device() returned success we should be
able to call arch_setup_msi_irqs() multiple times - while it
returns a number of MSI vectors that could have been allocated
(a third state).
This update makes use of the assumption described above. It
could have broke things had the architectures done any pre-
allocations or switch to some state in a call to function
arch_msi_check_device(). But because arch_msi_check_device()
is expected stateless and MSI resources are allocated in a
follow-up call to arch_setup_msi_irqs() we should be fine.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Cc: linux-mips@linux-mips.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s390@vger.kernel.org
Cc: x86@kernel.org
Cc: linux-pci@vger.kernel.org
---
drivers/pci/msi.c | 79 +++++++++++++++++++++-----------------------------
include/linux/pci.h | 5 +--
2 files changed, 34 insertions(+), 50 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 955ab79..fc669ab 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -883,50 +883,6 @@ int pci_msi_vec_count(struct pci_dev *dev)
}
EXPORT_SYMBOL(pci_msi_vec_count);
-/**
- * pci_enable_msi_block - configure device's MSI capability structure
- * @dev: device to configure
- * @nvec: number of interrupts to configure
- *
- * Allocate IRQs for a device with the MSI capability.
- * This function returns a negative errno if an error occurs. If it
- * is unable to allocate the number of interrupts requested, it returns
- * the number of interrupts it might be able to allocate. If it successfully
- * allocates at least the number of interrupts requested, it returns 0 and
- * updates the @dev's irq member to the lowest new interrupt number; the
- * other interrupt numbers allocated to this device are consecutive.
- */
-int pci_enable_msi_block(struct pci_dev *dev, int nvec)
-{
- int status, maxvec;
-
- if (dev->current_state != PCI_D0)
- return -EINVAL;
-
- maxvec = pci_msi_vec_count(dev);
- if (maxvec < 0)
- return maxvec;
- if (nvec > maxvec)
- return maxvec;
-
- status = pci_msi_check_device(dev, nvec, PCI_CAP_ID_MSI);
- if (status)
- return status;
-
- WARN_ON(!!dev->msi_enabled);
-
- /* Check whether driver already requested MSI-X irqs */
- if (dev->msix_enabled) {
- dev_info(&dev->dev, "can't enable MSI "
- "(MSI-X already enabled)\n");
- return -EINVAL;
- }
-
- status = msi_capability_init(dev, nvec);
- return status;
-}
-EXPORT_SYMBOL(pci_enable_msi_block);
-
void pci_msi_shutdown(struct pci_dev *dev)
{
struct msi_desc *desc;
@@ -1132,14 +1088,45 @@ void pci_msi_init_pci_dev(struct pci_dev *dev)
**/
int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec)
{
- int nvec = maxvec;
+ int nvec;
int rc;
+ if (dev->current_state != PCI_D0)
+ return -EINVAL;
+
+ WARN_ON(!!dev->msi_enabled);
+
+ /* Check whether driver already requested MSI-X irqs */
+ if (dev->msix_enabled) {
+ dev_info(&dev->dev,
+ "can't enable MSI (MSI-X already enabled)\n");
+ return -EINVAL;
+ }
+
if (maxvec < minvec)
return -ERANGE;
+ nvec = pci_msi_vec_count(dev);
+ if (nvec < 0)
+ return nvec;
+ else if (nvec < minvec)
+ return -EINVAL;
+ else if (nvec > maxvec)
+ nvec = maxvec;
+
+ do {
+ rc = pci_msi_check_device(dev, nvec, PCI_CAP_ID_MSI);
+ if (rc < 0) {
+ return rc;
+ } else if (rc > 0) {
+ if (rc < minvec)
+ return -ENOSPC;
+ nvec = rc;
+ }
+ } while (rc);
+
do {
- rc = pci_enable_msi_block(dev, nvec);
+ rc = msi_capability_init(dev, nvec);
if (rc < 0) {
return rc;
} else if (rc > 0) {
diff --git a/include/linux/pci.h b/include/linux/pci.h
index aab57b4..499755e 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1158,7 +1158,6 @@ struct msix_entry {
#ifdef CONFIG_PCI_MSI
int pci_msi_vec_count(struct pci_dev *dev);
-int pci_enable_msi_block(struct pci_dev *dev, int nvec);
void pci_msi_shutdown(struct pci_dev *dev);
void pci_disable_msi(struct pci_dev *dev);
int pci_msix_vec_count(struct pci_dev *dev);
@@ -1188,8 +1187,6 @@ static inline int pci_enable_msix_exact(struct pci_dev *dev,
}
#else
static inline int pci_msi_vec_count(struct pci_dev *dev) { return -ENOSYS; }
-static inline int pci_enable_msi_block(struct pci_dev *dev, int nvec)
-{ return -ENOSYS; }
static inline void pci_msi_shutdown(struct pci_dev *dev) { }
static inline void pci_disable_msi(struct pci_dev *dev) { }
static inline int pci_msix_vec_count(struct pci_dev *dev) { return -ENOSYS; }
@@ -1244,7 +1241,7 @@ static inline void pcie_set_ecrc_checking(struct pci_dev *dev) { }
static inline void pcie_ecrc_get_policy(char *str) { }
#endif
-#define pci_enable_msi(pdev) pci_enable_msi_block(pdev, 1)
+#define pci_enable_msi(pdev) pci_enable_msi_exact(pdev, 1)
#ifdef CONFIG_HT_IRQ
/* The functions a driver should call */
--
1.7.7.6
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply related
* [PATCH] powerpc/85xx: Add OCA4080 board support
From: Martijn de Gouw @ 2014-04-14 12:35 UTC (permalink / raw)
To: linuxppc-dev, scottwood; +Cc: stef.van.os, Martijn de Gouw, Martijn de Gouw
From: Martijn de Gouw <martijn.de.gouw@prodrive.nl>
OCA4080 overview:
- 1.466 GHz Freescale QorIQ P4080E Processor
- 4Gbyte DDR3 on board
- 8Mbyte Nor flash
- Serial RapidIO 1.2
- 1 x 10/100/1000 BASE-T front ethernet
- 1 x 1000 BASE-BX ethernet on AMC connector
Signed-off-by: Martijn de Gouw <martijn.de.gouw@prodrive-technologies.com>
---
arch/powerpc/boot/dts/oca4080.dts | 148 +++++++++++++++++++++++++
arch/powerpc/configs/corenet32_smp_defconfig | 1 +
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 4 +-
4 files changed, 152 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/boot/dts/oca4080.dts
diff --git a/arch/powerpc/boot/dts/oca4080.dts b/arch/powerpc/boot/dts/oca4080.dts
new file mode 100644
index 0000000..8926a61
--- /dev/null
+++ b/arch/powerpc/boot/dts/oca4080.dts
@@ -0,0 +1,148 @@
+/*
+ * OCA4080 Device Tree Source
+ *
+ * Copyright 2014 Prodrive Technologies B.V.
+ *
+ * Based on:
+ * P4080DS Device Tree Source
+ * Copyright 2009-2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/p4080si-pre.dtsi"
+
+/ {
+ model = "fsl,OCA4080";
+ compatible = "fsl,OCA4080";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ memory {
+ device_type = "memory";
+ };
+
+ dcsr: dcsr@f00000000 {
+ ranges = <0x00000000 0xf 0x00000000 0x01008000>;
+ };
+
+ soc: soc@ffe000000 {
+ ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
+ reg = <0xf 0xfe000000 0 0x00001000>;
+
+ i2c@118000 {
+ status = "disabled";
+ };
+
+ i2c@118100 {
+ status = "disabled";
+ };
+
+ i2c@119000 {
+ status = "disabled";
+ };
+
+ i2c@119100 {
+ status = "disabled";
+ };
+
+ usb0: usb@210000 {
+ status = "disabled";
+ };
+
+ usb1: usb@211000 {
+ status = "disabled";
+ };
+ };
+
+ rio: rapidio@ffe0c0000 {
+ reg = <0xf 0xfe0c0000 0 0x11000>;
+
+ port1 {
+ ranges = <0 0 0xc 0x20000000 0 0x10000000>;
+ };
+ };
+
+ lbc: localbus@ffe124000 {
+ reg = <0xf 0xfe124000 0 0x1000>;
+ ranges = <0 0 0xf 0xef800000 0x800000>;
+
+ flash@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0 0 0x00800000>;
+ bank-width = <2>;
+ device-width = <2>;
+ partition@rcw {
+ label = "rcw";
+ reg = <0x00000000 0x00020000>;
+ };
+ partition@fman-ucode {
+ label = "fman-ucode";
+ reg = <0x00020000 0x00020000>;
+ };
+ partition@user {
+ label = "user";
+ reg = <0x00040000 0x00680000>;
+ };
+ partition@env0 {
+ label = "env0";
+ reg = <0x006c0000 0x00020000>;
+ };
+ partition@env1 {
+ label = "env1";
+ reg = <0x006e0000 0x00020000>;
+ };
+ partition@u-boot {
+ label = "u-boot";
+ reg = <0x00700000 0x00080000>;
+ };
+ partition@u-boot-backup {
+ label = "u-boot-backup";
+ reg = <0x00780000 0x00080000>;
+ };
+ };
+ };
+
+ pci0: pcie@ffe200000 {
+ status = "disabled";
+ };
+
+ pci1: pcie@ffe201000 {
+ status = "disabled";
+ };
+
+ pci2: pcie@ffe202000 {
+ status = "disabled";
+ };
+};
+
+/include/ "fsl/p4080si-post.dtsi"
diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig
index bbd794d..c19ff05 100644
--- a/arch/powerpc/configs/corenet32_smp_defconfig
+++ b/arch/powerpc/configs/corenet32_smp_defconfig
@@ -72,6 +72,7 @@ CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_PHYSMAP_OF=y
CONFIG_MTD_M25P80=y
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index c17aae8..2e2d8ab 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -263,7 +263,7 @@ config CORENET_GENERIC
help
This option enables support for the FSL CoreNet based boards.
For 32bit kernel, the following boards are supported:
- P2041 RDB, P3041 DS and P4080 DS
+ P2041 RDB, P3041 DS, OCA4080 and P4080 DS
For 64bit kernel, the following boards are supported:
T4240 QDS and B4 QDS
The following boards are supported for both 32bit and 64bit kernel:
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
index fbd871e..f3685047 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -55,8 +55,6 @@ void __init corenet_gen_setup_arch(void)
mpc85xx_smp_init();
swiotlb_detect_4g();
-
- pr_info("%s board from Freescale Semiconductor\n", ppc_md.name);
}
static const struct of_device_id of_device_ids[] = {
@@ -99,6 +97,7 @@ int __init corenet_gen_publish_devices(void)
static const char * const boards[] __initconst = {
"fsl,P2041RDB",
"fsl,P3041DS",
+ "fsl,OCA4080",
"fsl,P4080DS",
"fsl,P5020DS",
"fsl,P5040DS",
@@ -112,6 +111,7 @@ static const char * const boards[] __initconst = {
static const char * const hv_boards[] __initconst = {
"fsl,P2041RDB-hv",
"fsl,P3041DS-hv",
+ "fsl,OCA4080-hv",
"fsl,P4080DS-hv",
"fsl,P5020DS-hv",
"fsl,P5040DS-hv",
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 2/2] PCI/MSI: Phase out pci_enable_msi_block()
From: Alexander Gordeev @ 2014-04-14 12:09 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-pci, linux-mips, x86, linuxppc-dev, linux-s390
In-Reply-To: <0b08613dc17cd608c1babc1f42b8919f60e1093f.1397458024.git.agordeev@redhat.com>
On Mon, Apr 14, 2014 at 09:14:07AM +0200, Alexander Gordeev wrote:
> @@ -1244,7 +1241,7 @@ static inline void pcie_set_ecrc_checking(struct pci_dev *dev) { }
> static inline void pcie_ecrc_get_policy(char *str) { }
> #endif
>
> -#define pci_enable_msi(pdev) pci_enable_msi_block(pdev, 1)
> +#define pci_enable_msi(pdev) pci_enable_msi_range(pdev, 1, 1)
Self-Nack, it should have been pci_enable_msi_exact(pdev, 1) ^^^
> #ifdef CONFIG_HT_IRQ
> /* The functions a driver should call */
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* [PATCH 3/3] powerpc: Bump BOOT_COMMAND_LINE_SIZE to 2048
From: Anton Blanchard @ 2014-04-14 11:55 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20140414215405.319725d5@kryten>
Bump the boot wrapper BOOT_COMMAND_LINE_SIZE to match the
kernel.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
We export this in an ELF section so userspace tools can edit it.
We should be safe so long as we are only increasing it shouldn't we?
Index: b/arch/powerpc/boot/ops.h
===================================================================
--- a/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -15,7 +15,7 @@
#include "types.h"
#include "string.h"
-#define BOOT_COMMAND_LINE_SIZE 512
+#define BOOT_COMMAND_LINE_SIZE 2048
#define MAX_PATH_LEN 256
#define MAX_PROP_LEN 256 /* What should this be? */
^ permalink raw reply
* [PATCH 2/3] powerpc: Bump COMMAND_LINE_SIZE to 2048
From: Anton Blanchard @ 2014-04-14 11:54 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20140414215405.319725d5@kryten>
I've had a report that the current limit is too small for
an automated network based installer. Bump it.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/arch/powerpc/include/uapi/asm/setup.h b/arch/powerpc/include/uapi/asm/setup.h
index 552df83..0516e97 100644
--- a/arch/powerpc/include/uapi/asm/setup.h
+++ b/arch/powerpc/include/uapi/asm/setup.h
@@ -1 +1,6 @@
-#include <asm-generic/setup.h>
+#ifndef _UAPI_ASM_POWERPC_SETUP_H
+#define _UAPI_ASM_POWERPC_SETUP_H
+
+#define COMMAND_LINE_SIZE 2048
+
+#endif /* _UAPI_ASM_POWERPC_SETUP_H */
^ permalink raw reply related
* [PATCH 1/3] powerpc: Rename duplicate COMMAND_LINE_SIZE define
From: Anton Blanchard @ 2014-04-14 11:54 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
We have two definitions of COMMAND_LINE_SIZE, one for the kernel
and one for the boot wrapper. I assume this is so the boot
wrapper can be self sufficient and not rely on kernel headers.
Having two defines with the same name is confusing, I just
updated the wrong one when trying to bump it.
Make the boot wrapper define unique by calling it
BOOT_COMMAND_LINE_SIZE.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/arch/powerpc/boot/main.c b/arch/powerpc/boot/main.c
index a28f021..d367a0a 100644
--- a/arch/powerpc/boot/main.c
+++ b/arch/powerpc/boot/main.c
@@ -139,18 +139,18 @@ static struct addr_range prep_initrd(struct addr_range vmlinux, void *chosen,
* edit the command line passed to vmlinux (by setting /chosen/bootargs).
* The buffer is put in it's own section so that tools may locate it easier.
*/
-static char cmdline[COMMAND_LINE_SIZE]
+static char cmdline[BOOT_COMMAND_LINE_SIZE]
__attribute__((__section__("__builtin_cmdline")));
static void prep_cmdline(void *chosen)
{
if (cmdline[0] == '\0')
- getprop(chosen, "bootargs", cmdline, COMMAND_LINE_SIZE-1);
+ getprop(chosen, "bootargs", cmdline, BOOT_COMMAND_LINE_SIZE-1);
printf("\n\rLinux/PowerPC load: %s", cmdline);
/* If possible, edit the command line */
if (console_ops.edit_cmdline)
- console_ops.edit_cmdline(cmdline, COMMAND_LINE_SIZE);
+ console_ops.edit_cmdline(cmdline, BOOT_COMMAND_LINE_SIZE);
printf("\n\r");
/* Put the command line back into the devtree for the kernel */
@@ -174,7 +174,7 @@ void start(void)
* built-in command line wasn't set by an external tool */
if ((loader_info.cmdline_len > 0) && (cmdline[0] == '\0'))
memmove(cmdline, loader_info.cmdline,
- min(loader_info.cmdline_len, COMMAND_LINE_SIZE-1));
+ min(loader_info.cmdline_len, BOOT_COMMAND_LINE_SIZE-1));
if (console_ops.open && (console_ops.open() < 0))
exit();
diff --git a/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
index b3218ce..339e041 100644
--- a/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -15,7 +15,7 @@
#include "types.h"
#include "string.h"
-#define COMMAND_LINE_SIZE 512
+#define BOOT_COMMAND_LINE_SIZE 512
#define MAX_PATH_LEN 256
#define MAX_PROP_LEN 256 /* What should this be? */
diff --git a/arch/powerpc/boot/ps3.c b/arch/powerpc/boot/ps3.c
index 9954d98..4ec2d86 100644
--- a/arch/powerpc/boot/ps3.c
+++ b/arch/powerpc/boot/ps3.c
@@ -47,13 +47,13 @@ BSS_STACK(4096);
* The buffer is put in it's own section so that tools may locate it easier.
*/
-static char cmdline[COMMAND_LINE_SIZE]
+static char cmdline[BOOT_COMMAND_LINE_SIZE]
__attribute__((__section__("__builtin_cmdline")));
static void prep_cmdline(void *chosen)
{
if (cmdline[0] == '\0')
- getprop(chosen, "bootargs", cmdline, COMMAND_LINE_SIZE-1);
+ getprop(chosen, "bootargs", cmdline, BOOT_COMMAND_LINE_SIZE-1);
else
setprop_str(chosen, "bootargs", cmdline);
^ permalink raw reply related
* [PATCH] powerpc: Fix error return in rtas_flash module init
From: Anton Blanchard @ 2014-04-14 11:23 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
module_init should return 0 or a negative errno.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
index 2f3cdb0..658e89d 100644
--- a/arch/powerpc/kernel/rtas_flash.c
+++ b/arch/powerpc/kernel/rtas_flash.c
@@ -705,7 +705,7 @@ static int __init rtas_flash_init(void)
if (rtas_token("ibm,update-flash-64-and-reboot") ==
RTAS_UNKNOWN_SERVICE) {
pr_info("rtas_flash: no firmware flash support\n");
- return 1;
+ return -EINVAL;
}
rtas_validate_flash_data.buf = kzalloc(VALIDATE_BUF_SIZE, GFP_KERNEL);
^ permalink raw reply related
* Re: [PATCH v3] powerpc: kvm: make _PAGE_NUMA take effect
From: Alexander Graf @ 2014-04-14 9:01 UTC (permalink / raw)
To: liu ping fan
Cc: Liu Ping Fan, kvm@vger.kernel.org mailing list, kvm-ppc,
Paul Mackerras, Liu ping fan, linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <CAJnKYQ=0dpuO3XBQDpxBi=M_diwVRwA8wa-+JMXnFXYyAPVw-Q@mail.gmail.com>
On 14.04.14 10:08, liu ping fan wrote:
> On Mon, Apr 14, 2014 at 2:43 PM, Alexander Graf <agraf@suse.de> wrote:
>> On 13.04.14 04:27, Liu ping fan wrote:
>>> On Fri, Apr 11, 2014 at 10:03 PM, Alexander Graf <agraf@suse.de> wrote:
>>>> On 11.04.2014, at 13:45, Liu Ping Fan <pingfank@linux.vnet.ibm.com>
>>>> wrote:
>>>>
>>>>> When we mark pte with _PAGE_NUMA we already call
>>>>> mmu_notifier_invalidate_range_start
>>>>> and mmu_notifier_invalidate_range_end, which will mark existing guest
>>>>> hpte
>>>>> entry as HPTE_V_ABSENT. Now we need to do that when we are inserting new
>>>>> guest hpte entries.
>>>> What happens when we don't? Why do we need the check? Why isn't it done
>>>> implicitly? What happens when we treat a NUMA marked page as non-present?
>>>> Why does it work out for us?
>>>>
>>>> Assume you have no idea what PAGE_NUMA is, but try to figure out what
>>>> this patch does and whether you need to cherry-pick it into your downstream
>>>> kernel. The description as is still is not very helpful for that. It doesn't
>>>> even explain what really changes with this patch applied.
>>>>
>>> Yeah. what about appending the following description? Can it make
>>> the context clear?
>>> "Guest should not setup a hpte for the page whose pte is marked with
>>> _PAGE_NUMA, so on the host, the numa-fault mechanism can take effect
>>> to check whether the page is placed correctly or not."
>>
>> Try to come up with a text that answers the following questions in order:
>>
> I divide them into 3 groups, and answer them by 3 sections. Seems that
> it has the total story :)
> Please take a look.
>
>> - What does _PAGE_NUMA mean?
> Group 1 -> section 2
>
>> - How does page migration with _PAGE_NUMA work?
>> -> Why should we not map pages when _PAGE_NUMA is set?
> Group 2 -> section 1
> (Note: for the 1st question in this group, I am not sure about the
> details, except that we can fix numa balancing by moving task or
> moving page. So I comment as " migration should be involved to cut
> down the distance between the cpu and pages")
>
>> - Which part of what needs to be done did the previous _PAGE_NUMA patch
>> address?
>> - What's the situation without this patch?
>> - Which scenario does this patch fix?
>>
> Group 3 -> section 3
>
>
> Numa fault is a method which help to achieve auto numa balancing.
> When such a page fault takes place, the page fault handler will check
> whether the page is placed correctly. If not, migration should be
> involved to cut down the distance between the cpu and pages.
>
> A pte with _PAGE_NUMA help to implement numa fault. It means not to
> allow the MMU to access the page directly. So a page fault is triggered
> and numa fault handler gets the opportunity to run checker.
>
> As for the access of MMU, we need special handling for the powernv's guest.
> When we mark a pte with _PAGE_NUMA, we already call mmu_notifier to
> invalidate it in guest's htab, but when we tried to re-insert them,
> we firstly try to fix it in real-mode. Only after this fails, we fallback
> to virt mode, and most of important, we run numa fault handler in virt
> mode. This patch guards the way of real-mode to ensure that if a pte is
> marked with _PAGE_NUMA, it will NOT be fixed in real mode, instead, it will
> be fixed in virt mode and have the opportunity to be checked with placement.
s/fixed/mapped/g
Otherwise works as patch description for me :).
Alex
^ permalink raw reply
* Re: [PATCH v3] powerpc: kvm: make _PAGE_NUMA take effect
From: liu ping fan @ 2014-04-14 8:08 UTC (permalink / raw)
To: Alexander Graf
Cc: Liu Ping Fan, kvm@vger.kernel.org mailing list, kvm-ppc,
Paul Mackerras, Liu ping fan, linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <534B8384.7050500@suse.de>
On Mon, Apr 14, 2014 at 2:43 PM, Alexander Graf <agraf@suse.de> wrote:
>
> On 13.04.14 04:27, Liu ping fan wrote:
>>
>> On Fri, Apr 11, 2014 at 10:03 PM, Alexander Graf <agraf@suse.de> wrote:
>>>
>>> On 11.04.2014, at 13:45, Liu Ping Fan <pingfank@linux.vnet.ibm.com>
>>> wrote:
>>>
>>>> When we mark pte with _PAGE_NUMA we already call
>>>> mmu_notifier_invalidate_range_start
>>>> and mmu_notifier_invalidate_range_end, which will mark existing guest
>>>> hpte
>>>> entry as HPTE_V_ABSENT. Now we need to do that when we are inserting new
>>>> guest hpte entries.
>>>
>>> What happens when we don't? Why do we need the check? Why isn't it done
>>> implicitly? What happens when we treat a NUMA marked page as non-present?
>>> Why does it work out for us?
>>>
>>> Assume you have no idea what PAGE_NUMA is, but try to figure out what
>>> this patch does and whether you need to cherry-pick it into your downstream
>>> kernel. The description as is still is not very helpful for that. It doesn't
>>> even explain what really changes with this patch applied.
>>>
>> Yeah. what about appending the following description? Can it make
>> the context clear?
>> "Guest should not setup a hpte for the page whose pte is marked with
>> _PAGE_NUMA, so on the host, the numa-fault mechanism can take effect
>> to check whether the page is placed correctly or not."
>
>
> Try to come up with a text that answers the following questions in order:
>
I divide them into 3 groups, and answer them by 3 sections. Seems that
it has the total story :)
Please take a look.
> - What does _PAGE_NUMA mean?
Group 1 -> section 2
> - How does page migration with _PAGE_NUMA work?
> -> Why should we not map pages when _PAGE_NUMA is set?
Group 2 -> section 1
(Note: for the 1st question in this group, I am not sure about the
details, except that we can fix numa balancing by moving task or
moving page. So I comment as " migration should be involved to cut
down the distance between the cpu and pages")
> - Which part of what needs to be done did the previous _PAGE_NUMA patch
> address?
> - What's the situation without this patch?
> - Which scenario does this patch fix?
>
Group 3 -> section 3
Numa fault is a method which help to achieve auto numa balancing.
When such a page fault takes place, the page fault handler will check
whether the page is placed correctly. If not, migration should be
involved to cut down the distance between the cpu and pages.
A pte with _PAGE_NUMA help to implement numa fault. It means not to
allow the MMU to access the page directly. So a page fault is triggered
and numa fault handler gets the opportunity to run checker.
As for the access of MMU, we need special handling for the powernv's guest.
When we mark a pte with _PAGE_NUMA, we already call mmu_notifier to
invalidate it in guest's htab, but when we tried to re-insert them,
we firstly try to fix it in real-mode. Only after this fails, we fallback
to virt mode, and most of important, we run numa fault handler in virt
mode. This patch guards the way of real-mode to ensure that if a pte is
marked with _PAGE_NUMA, it will NOT be fixed in real mode, instead, it will
be fixed in virt mode and have the opportunity to be checked with placement.
Thx,
Fan
> Once you have a text that answers those, you should have a good patch
> description :).
>
> Alex
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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