* Re: [PATCH] ASoC: fsl_sai: Add imx6sx platform support
From: Nicolin Chen @ 2014-04-03 3:11 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, linuxppc-dev
In-Reply-To: <20140402195208.GM14763@sirena.org.uk>
On Wed, Apr 02, 2014 at 08:52:08PM +0100, Mark Brown wrote:
> On Tue, Apr 01, 2014 at 07:34:09PM +0800, Nicolin Chen wrote:
> > The next coming i.MX6 Solo X SoC also contains SAI module while we use
> > imp_pcm_init() for i.MX platform.
>
> I've applied this, though obviously it'd be better if we had dmaengine
> support for this SoC so that it was just a compatible string update and
> didn't require any code.
Hmm...actually imx_pcm_init() is just a shell calling dmaengine while it
has its own config and flags. So we still need to extinguish these two
elements for them even if using devm_snd_dmaengine_pcm_register() eventually.
But the idea to merge them into one entry should be great for 3rd platform
or even further one. And a patch for imx-pcm-dma and all callers of it
would be needed then.
Thank you,
Nicolin
^ permalink raw reply
* Re: [PATCH] cpuidle: add freescale e500 family porcessors idle support
From: Daniel Lezcano @ 2014-04-03 6:28 UTC (permalink / raw)
To: Dongsheng.Wang@freescale.com, Scott Wood
Cc: chenhui.zhao@freescale.com, linux-pm@vger.kernel.org,
rjw@rjwysocki.net, Jason.Jin@freescale.com,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <e32c248e30c54f458f65501227b1ce54@BN1PR03MB188.namprd03.prod.outlook.com>
On 04/03/2014 05:20 AM, Dongsheng.Wang@freescale.com wrote:
> Hi Daniel,
>
> Thanks for your review. I will fix your comments.
>
> BTW, fix Rafael's email. :)
>
>>> +#include <linux/cpu.h>
>>> +#include <linux/cpuidle.h>
>>> +#include <linux/init.h>
>>> +#include <linux/kernel.h>
>>> +#include <linux/notifier.h>
>>> +
>>> +#include <asm/cputable.h>
>>> +#include <asm/machdep.h>
>>> +#include <asm/mpc85xx.h>
>>> +
>>> +static unsigned int max_idle_state;
>>> +static struct cpuidle_state *cpuidle_state_table;
>>> +
>>> +struct cpuidle_driver e500_idle_driver = {
>>> + .name = "e500_idle",
>>> + .owner = THIS_MODULE,
>>> +};
>>> +
>>> +static void e500_cpuidle(void)
>>> +{
>>> + if (cpuidle_idle_call())
>>> + cpuidle_wait();
>>> +}
>>
>> Nope, that has been changed. No more call to cpuidle_idle_call in a driver.
>>
>
> Thanks.
>
>>> +
>>> +static int pw10_enter(struct cpuidle_device *dev,
>>> + struct cpuidle_driver *drv, int index)
>>> +{
>>> + cpuidle_wait();
>>> + return index;
>>> +}
>>> +
>>> +#define MAX_BIT 63
>>> +#define MIN_BIT 1
>>> +extern u32 cpuidle_entry_bit;
>>> +static int pw20_enter(struct cpuidle_device *dev,
>>> + struct cpuidle_driver *drv, int index)
>>> +{
>>> + u32 pw20_idle;
>>> + u32 entry_bit;
>>> + pw20_idle = mfspr(SPRN_PWRMGTCR0);
>>> + if ((pw20_idle & PWRMGTCR0_PW20_ENT) != PWRMGTCR0_PW20_ENT) {
>>> + pw20_idle &= ~PWRMGTCR0_PW20_ENT;
>>> + entry_bit = MAX_BIT - cpuidle_entry_bit;
>>> + pw20_idle |= (entry_bit << PWRMGTCR0_PW20_ENT_SHIFT);
>>> + mtspr(SPRN_PWRMGTCR0, pw20_idle);
>>> + }
>>> +
>>> + cpuidle_wait();
>>> +
>>> + pw20_idle &= ~PWRMGTCR0_PW20_ENT;
>>> + pw20_idle |= (MIN_BIT << PWRMGTCR0_PW20_ENT_SHIFT);
>>> + mtspr(SPRN_PWRMGTCR0, pw20_idle);
>>> +
>>> + return index;
>>> +}
>>
>> Is it possible to give some comments and encapsulate the code with
>> explicit function names to be implemented in an arch specific directory
>> file (eg. pm.c) and export these functions in a linux/ header ? We try
>> to prevent to include asm if possible.
>>
>
> Yep, Looks better. Thanks.
>
>>> +
>>> +static struct cpuidle_state pw_idle_states[] = {
>>> + {
>>> + .name = "pw10",
>>> + .desc = "pw10",
>>> + .flags = CPUIDLE_FLAG_TIME_VALID,
>>> + .exit_latency = 0,
>>> + .target_residency = 0,
>>> + .enter = &pw10_enter
>>> + },
>>> +
>>> + {
>>> + .name = "pw20",
>>> + .desc = "pw20-core-idle",
>>> + .flags = CPUIDLE_FLAG_TIME_VALID,
>>> + .exit_latency = 1,
>>> + .target_residency = 50,
>>> + .enter = &pw20_enter
>>> + },
>>> +};
>>
>> No need to define this intermediate structure here, you can directly
>> initialize the cpuidle_driver:
>>
>
> Thanks. :)
>
>>> +static int cpu_hotplug_notify(struct notifier_block *n,
>>> + unsigned long action, void *hcpu)
>>> +{
>>> + unsigned long hotcpu = (unsigned long)hcpu;
>>> + struct cpuidle_device *dev =
>>> + per_cpu_ptr(cpuidle_devices, hotcpu);
>>> +
>>> + if (dev && cpuidle_get_driver()) {
>>> + switch (action) {
>>> + case CPU_ONLINE:
>>> + case CPU_ONLINE_FROZEN:
>>> + cpuidle_pause_and_lock();
>>> + cpuidle_enable_device(dev);
>>> + cpuidle_resume_and_unlock();
>>> + break;
>>> +
>>> + case CPU_DEAD:
>>> + case CPU_DEAD_FROZEN:
>>> + cpuidle_pause_and_lock();
>>> + cpuidle_disable_device(dev);
>>> + cpuidle_resume_and_unlock();
>>> + break;
>>> +
>>> + default:
>>> + return NOTIFY_DONE;
>>> + }
>>> + }
>>> +
>>> + return NOTIFY_OK;
>>> +}
>>> +
>>> +static struct notifier_block cpu_hotplug_notifier = {
>>> + .notifier_call = cpu_hotplug_notify,
>>> +};
>>
>> Can you explain why this is needed ?
>>
>
> If a cpu will be plugged out/in, We should be let Cpuidle know to remove
> corresponding sys interface and disable/enable cpudile-governor for current cpu.
Ok, this code is a copy-paste of the powers' cpuidle driver.
IIRC, I posted a patchset to move this portion of code in the cpuidle
common framework some time ago.
Could you please get rid of this part of code ?
>>> + err = register_cpu_notifier(&cpu_hotplug_notifier);
>>> + if (err)
>>> + pr_warn("Cpuidle driver: register cpu notifier failed.\n");
>>> +
>>> + /* Replace the original way of idle after cpuidle registered. */
>>> + ppc_md.power_save = e500_cpuidle;
>>> + on_each_cpu(replace_orig_idle, NULL, 1);
>>
>> Why ?
>>
>
> I checked again, if we put cpuidle_idle_call in asm, this is not need.
>
> Regards,
> -Dongsheng
>
>>> + pr_info("e500_idle_driver registered.\n");
>>> +
>>> + return 0;
>>> +}
>>> +late_initcall(e500_idle_init);
>>>
>>
>> Thanks
>>
>> -- Daniel
>>
>>
>> --
>> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>
>> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
>> <http://twitter.com/#!/linaroorg> Twitter |
>> <http://www.linaro.org/linaro-blog/> Blog
>>
>>
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH] powerpc: use of_node_init() for the fakenode in msi_bitmap.c
From: Li Zhong @ 2014-04-03 6:58 UTC (permalink / raw)
To: PowerPC email list; +Cc: grant.likely, Paul Mackerras
This patch uses of_node_init() to initialize the kobject in the fake
node used in test_of_node(), to avoid following kobject warning.
[ 0.897654] kobject: '(null)' (c0000007ca183a08): is not initialized, yet kobject_put() is being called.
[ 0.897682] ------------[ cut here ]------------
[ 0.897688] WARNING: at lib/kobject.c:670
[ 0.897692] Modules linked in:
[ 0.897701] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 3.14.0+ #1
[ 0.897708] task: c0000007ca100000 ti: c0000007ca180000 task.ti: c0000007ca180000
[ 0.897715] NIP: c00000000046a1f0 LR: c00000000046a1ec CTR: 0000000001704660
[ 0.897721] REGS: c0000007ca1835c0 TRAP: 0700 Not tainted (3.14.0+)
[ 0.897727] MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 28000024 XER: 0000000d
[ 0.897749] CFAR: c0000000008ef4ec SOFTE: 1
GPR00: c00000000046a1ec c0000007ca183840 c0000000014c59b8 000000000000005c
GPR04: 0000000000000001 c000000000129770 0000000000000000 0000000000000001
GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000003fef
GPR12: 0000000000000000 c00000000f221200 c00000000000c350 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24: 0000000000000000 c00000000144e808 c000000000c56f20 00000000000000d8
GPR28: c000000000cd5058 0000000000000000 c000000001454ca8 c0000007ca183a08
[ 0.897856] NIP [c00000000046a1f0] .kobject_put+0xa0/0xb0
[ 0.897863] LR [c00000000046a1ec] .kobject_put+0x9c/0xb0
[ 0.897868] Call Trace:
[ 0.897874] [c0000007ca183840] [c00000000046a1ec] .kobject_put+0x9c/0xb0 (unreliable)
[ 0.897885] [c0000007ca1838c0] [c000000000743f9c] .of_node_put+0x2c/0x50
[ 0.897894] [c0000007ca183940] [c000000000c83954] .test_of_node+0x1dc/0x208
[ 0.897902] [c0000007ca183b80] [c000000000c839a4] .msi_bitmap_selftest+0x24/0x38
[ 0.897913] [c0000007ca183bf0] [c00000000000bb34] .do_one_initcall+0x144/0x200
[ 0.897922] [c0000007ca183ce0] [c000000000c748e4] .kernel_init_freeable+0x2b4/0x394
[ 0.897931] [c0000007ca183db0] [c00000000000c374] .kernel_init+0x24/0x130
[ 0.897940] [c0000007ca183e30] [c00000000000a2f4] .ret_from_kernel_thread+0x5c/0x68
[ 0.897947] Instruction dump:
[ 0.897952] 7fe3fb78 38210080 e8010010 ebe1fff8 7c0803a6 4800014c e89f0000 3c62ff6e
[ 0.897971] 7fe5fb78 3863a950 48485279 60000000 <0fe00000> 39000000 393f0038 4bffff80
[ 0.897992] ---[ end trace 1eeffdb9f825a556 ]---
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
---
arch/powerpc/sysdev/msi_bitmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/msi_bitmap.c b/arch/powerpc/sysdev/msi_bitmap.c
index 8ba6042..2ff6302 100644
--- a/arch/powerpc/sysdev/msi_bitmap.c
+++ b/arch/powerpc/sysdev/msi_bitmap.c
@@ -202,7 +202,7 @@ void __init test_of_node(void)
/* There should really be a struct device_node allocator */
memset(&of_node, 0, sizeof(of_node));
- kref_init(&of_node.kobj.kref);
+ of_node_init(&of_node);
of_node.full_name = node_name;
check(0 == msi_bitmap_alloc(&bmp, size, &of_node));
^ permalink raw reply related
* Re: [PATCH 6/7] DMA: Freescale: use spin_lock_bh instead of spin_lock_irqsave
From: Hongbo Zhang @ 2014-04-03 7:00 UTC (permalink / raw)
To: Vinod Koul
Cc: Vinod Koul, linux-kernel, scottwood, dmaengine, dan.j.williams,
linuxppc-dev
In-Reply-To: <20140402163519.GU1976@intel.com>
On 04/03/2014 12:35 AM, Vinod Koul wrote:
> On Mon, Mar 31, 2014 at 12:08:55PM +0800, Hongbo Zhang wrote:
>> On 03/29/2014 09:45 PM, Vinod Koul wrote:
>>> On Fri, Mar 28, 2014 at 02:33:37PM +0800, Hongbo Zhang wrote:
>>>> On 03/26/2014 03:01 PM, Vinod Koul wrote:
>>>>> On Thu, 2014-01-16 at 13:47 +0800, hongbo.zhang@freescale.com wrote:
>>>>>> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>>>>>>
>>>>>> The usage of spin_lock_irqsave() is a stronger locking mechanism than is
>>>>>> required throughout the driver. The minimum locking required should be used
>>>>>> instead. Interrupts will be turned off and context will be saved, it is
>>>>>> unnecessary to use irqsave.
>>>>>>
>>>>>> This patch changes all instances of spin_lock_irqsave() to spin_lock_bh(). All
>>>>>> manipulation of protected fields is done using tasklet context or weaker, which
>>>>>> makes spin_lock_bh() the correct choice.
>>>>>>
>>>>>> /**
>>>>>> @@ -1124,11 +1120,10 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)
>>>>>> static void dma_do_tasklet(unsigned long data)
>>>>>> {
>>>>>> struct fsldma_chan *chan = (struct fsldma_chan *)data;
>>>>>> - unsigned long flags;
>>>>>> chan_dbg(chan, "tasklet entry\n");
>>>>>> - spin_lock_irqsave(&chan->desc_lock, flags);
>>>>>> + spin_lock_bh(&chan->desc_lock);
>>>>> okay here is the problem :(
>>>>>
>>>>> You moved to _bh variant. So if you grab the lock in rest of the code
>>>>> and irq gets triggered then here we will be spinning to grab the lock.
>>>>> So effectively you made right locking solution into deadlock situation!
>>>> If the rest code grabs lock by spin_lock_bh(), and if irq raised,
>>>> the tasklet could not be executed because it has been disabled by
>>>> the _bh variant function.
>>> yes if you are accessing resources only in tasklet and rest of the code, then
>>> _bh variant works well. The problem here is usage in irq handler
>>>
>> The name dma_do_tasklet may mislead, it is tasklet handler, not irq
>> handler, not a trigger to load tasklet.
>> the irq handler is fsldma_chan_irq, and I don't use lock in it.
> sorry my bad, i misread this as code in fsldma_chan_irq() insteadof
> dma_do_tasklet(). In that case patch is doing the right thing.
>
OK, so I will send a v2 series with only updating 3/7 soon.
^ permalink raw reply
* RE: [PATCH] cpuidle: add freescale e500 family porcessors idle support
From: Dongsheng.Wang @ 2014-04-03 8:03 UTC (permalink / raw)
To: Daniel Lezcano, Scott Wood
Cc: chenhui.zhao@freescale.com, linux-pm@vger.kernel.org,
rjw@rjwysocki.net, Jason.Jin@freescale.com,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <533CFFA7.6000907@linaro.org>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRGFuaWVsIExlemNhbm8g
W21haWx0bzpkYW5pZWwubGV6Y2Fub0BsaW5hcm8ub3JnXQ0KPiBTZW50OiBUaHVyc2RheSwgQXBy
aWwgMDMsIDIwMTQgMjoyOSBQTQ0KPiBUbzogV2FuZyBEb25nc2hlbmctQjQwNTM0OyBXb29kIFNj
b3R0LUIwNzQyMQ0KPiBDYzogcmp3QHJqd3lzb2NraS5uZXQ7IExpIFlhbmctTGVvLVI1ODQ3Mjsg
SmluIFpoZW5neGlvbmctUjY0MTg4OyBaaGFvIENoZW5odWktDQo+IEIzNTMzNjsgbGludXgtcG1A
dmdlci5rZXJuZWwub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZw0KPiBTdWJqZWN0
OiBSZTogW1BBVENIXSBjcHVpZGxlOiBhZGQgZnJlZXNjYWxlIGU1MDAgZmFtaWx5IHBvcmNlc3Nv
cnMgaWRsZSBzdXBwb3J0DQo+IA0KPiBPbiAwNC8wMy8yMDE0IDA1OjIwIEFNLCBEb25nc2hlbmcu
V2FuZ0BmcmVlc2NhbGUuY29tIHdyb3RlOg0KPiA+IEhpIERhbmllbCwNCj4gPg0KPiA+IFRoYW5r
cyBmb3IgeW91ciByZXZpZXcuIEkgd2lsbCBmaXggeW91ciBjb21tZW50cy4NCj4gPg0KPiA+IEJU
VywgZml4IFJhZmFlbCdzIGVtYWlsLiA6KQ0KPiA+DQo+ID4+PiArI2luY2x1ZGUgPGxpbnV4L2Nw
dS5oPg0KPiA+Pj4gKyNpbmNsdWRlIDxsaW51eC9jcHVpZGxlLmg+DQo+ID4+PiArI2luY2x1ZGUg
PGxpbnV4L2luaXQuaD4NCj4gPj4+ICsjaW5jbHVkZSA8bGludXgva2VybmVsLmg+DQo+ID4+PiAr
I2luY2x1ZGUgPGxpbnV4L25vdGlmaWVyLmg+DQo+ID4+PiArDQo+ID4+PiArI2luY2x1ZGUgPGFz
bS9jcHV0YWJsZS5oPg0KPiA+Pj4gKyNpbmNsdWRlIDxhc20vbWFjaGRlcC5oPg0KPiA+Pj4gKyNp
bmNsdWRlIDxhc20vbXBjODV4eC5oPg0KPiA+Pj4gKw0KPiA+Pj4gK3N0YXRpYyB1bnNpZ25lZCBp
bnQgbWF4X2lkbGVfc3RhdGU7IHN0YXRpYyBzdHJ1Y3QgY3B1aWRsZV9zdGF0ZQ0KPiA+Pj4gKypj
cHVpZGxlX3N0YXRlX3RhYmxlOw0KPiA+Pj4gKw0KPiA+Pj4gK3N0cnVjdCBjcHVpZGxlX2RyaXZl
ciBlNTAwX2lkbGVfZHJpdmVyID0gew0KPiA+Pj4gKwkubmFtZSA9ICJlNTAwX2lkbGUiLA0KPiA+
Pj4gKwkub3duZXIgPSBUSElTX01PRFVMRSwNCj4gPj4+ICt9Ow0KPiA+Pj4gKw0KPiA+Pj4gK3N0
YXRpYyB2b2lkIGU1MDBfY3B1aWRsZSh2b2lkKQ0KPiA+Pj4gK3sNCj4gPj4+ICsJaWYgKGNwdWlk
bGVfaWRsZV9jYWxsKCkpDQo+ID4+PiArCQljcHVpZGxlX3dhaXQoKTsNCj4gPj4+ICt9DQo+ID4+
DQo+ID4+IE5vcGUsIHRoYXQgaGFzIGJlZW4gY2hhbmdlZC4gTm8gbW9yZSBjYWxsIHRvIGNwdWlk
bGVfaWRsZV9jYWxsIGluIGEgZHJpdmVyLg0KPiA+Pg0KPiA+DQo+ID4gVGhhbmtzLg0KPiA+DQo+
ID4+PiArDQo+ID4+PiArc3RhdGljIGludCBwdzEwX2VudGVyKHN0cnVjdCBjcHVpZGxlX2Rldmlj
ZSAqZGV2LA0KPiA+Pj4gKwkJCXN0cnVjdCBjcHVpZGxlX2RyaXZlciAqZHJ2LCBpbnQgaW5kZXgp
IHsNCj4gPj4+ICsJY3B1aWRsZV93YWl0KCk7DQo+ID4+PiArCXJldHVybiBpbmRleDsNCj4gPj4+
ICt9DQo+ID4+PiArDQo+ID4+PiArI2RlZmluZSBNQVhfQklUCTYzDQo+ID4+PiArI2RlZmluZSBN
SU5fQklUCTENCj4gPj4+ICtleHRlcm4gdTMyIGNwdWlkbGVfZW50cnlfYml0Ow0KPiA+Pj4gK3N0
YXRpYyBpbnQgcHcyMF9lbnRlcihzdHJ1Y3QgY3B1aWRsZV9kZXZpY2UgKmRldiwNCj4gPj4+ICsJ
CXN0cnVjdCBjcHVpZGxlX2RyaXZlciAqZHJ2LCBpbnQgaW5kZXgpIHsNCj4gPj4+ICsJdTMyIHB3
MjBfaWRsZTsNCj4gPj4+ICsJdTMyIGVudHJ5X2JpdDsNCj4gPj4+ICsJcHcyMF9pZGxlID0gbWZz
cHIoU1BSTl9QV1JNR1RDUjApOw0KPiA+Pj4gKwlpZiAoKHB3MjBfaWRsZSAmIFBXUk1HVENSMF9Q
VzIwX0VOVCkgIT0gUFdSTUdUQ1IwX1BXMjBfRU5UKSB7DQo+ID4+PiArCQlwdzIwX2lkbGUgJj0g
flBXUk1HVENSMF9QVzIwX0VOVDsNCj4gPj4+ICsJCWVudHJ5X2JpdCA9IE1BWF9CSVQgLSBjcHVp
ZGxlX2VudHJ5X2JpdDsNCj4gPj4+ICsJCXB3MjBfaWRsZSB8PSAoZW50cnlfYml0IDw8IFBXUk1H
VENSMF9QVzIwX0VOVF9TSElGVCk7DQo+ID4+PiArCQltdHNwcihTUFJOX1BXUk1HVENSMCwgcHcy
MF9pZGxlKTsNCj4gPj4+ICsJfQ0KPiA+Pj4gKw0KPiA+Pj4gKwljcHVpZGxlX3dhaXQoKTsNCj4g
Pj4+ICsNCj4gPj4+ICsJcHcyMF9pZGxlICY9IH5QV1JNR1RDUjBfUFcyMF9FTlQ7DQo+ID4+PiAr
CXB3MjBfaWRsZSB8PSAoTUlOX0JJVCA8PCBQV1JNR1RDUjBfUFcyMF9FTlRfU0hJRlQpOw0KPiA+
Pj4gKwltdHNwcihTUFJOX1BXUk1HVENSMCwgcHcyMF9pZGxlKTsNCj4gPj4+ICsNCj4gPj4+ICsJ
cmV0dXJuIGluZGV4Ow0KPiA+Pj4gK30NCj4gPj4NCj4gPj4gSXMgaXQgcG9zc2libGUgdG8gZ2l2
ZSBzb21lIGNvbW1lbnRzIGFuZCBlbmNhcHN1bGF0ZSB0aGUgY29kZSB3aXRoDQo+ID4+IGV4cGxp
Y2l0IGZ1bmN0aW9uIG5hbWVzIHRvIGJlIGltcGxlbWVudGVkIGluIGFuIGFyY2ggc3BlY2lmaWMN
Cj4gPj4gZGlyZWN0b3J5IGZpbGUgKGVnLiBwbS5jKSBhbmQgZXhwb3J0IHRoZXNlIGZ1bmN0aW9u
cyBpbiBhIGxpbnV4Lw0KPiA+PiBoZWFkZXIgPyBXZSB0cnkgdG8gcHJldmVudCB0byBpbmNsdWRl
IGFzbSBpZiBwb3NzaWJsZS4NCj4gPj4NCj4gPg0KPiA+IFllcCwgTG9va3MgYmV0dGVyLiBUaGFu
a3MuDQo+ID4NCj4gPj4+ICsNCj4gPj4+ICtzdGF0aWMgc3RydWN0IGNwdWlkbGVfc3RhdGUgcHdf
aWRsZV9zdGF0ZXNbXSA9IHsNCj4gPj4+ICsJew0KPiA+Pj4gKwkJLm5hbWUgPSAicHcxMCIsDQo+
ID4+PiArCQkuZGVzYyA9ICJwdzEwIiwNCj4gPj4+ICsJCS5mbGFncyA9IENQVUlETEVfRkxBR19U
SU1FX1ZBTElELA0KPiA+Pj4gKwkJLmV4aXRfbGF0ZW5jeSA9IDAsDQo+ID4+PiArCQkudGFyZ2V0
X3Jlc2lkZW5jeSA9IDAsDQo+ID4+PiArCQkuZW50ZXIgPSAmcHcxMF9lbnRlcg0KPiA+Pj4gKwl9
LA0KPiA+Pj4gKw0KPiA+Pj4gKwl7DQo+ID4+PiArCQkubmFtZSA9ICJwdzIwIiwNCj4gPj4+ICsJ
CS5kZXNjID0gInB3MjAtY29yZS1pZGxlIiwNCj4gPj4+ICsJCS5mbGFncyA9IENQVUlETEVfRkxB
R19USU1FX1ZBTElELA0KPiA+Pj4gKwkJLmV4aXRfbGF0ZW5jeSA9IDEsDQo+ID4+PiArCQkudGFy
Z2V0X3Jlc2lkZW5jeSA9IDUwLA0KPiA+Pj4gKwkJLmVudGVyID0gJnB3MjBfZW50ZXINCj4gPj4+
ICsJfSwNCj4gPj4+ICt9Ow0KPiA+Pg0KPiA+PiBObyBuZWVkIHRvIGRlZmluZSB0aGlzIGludGVy
bWVkaWF0ZSBzdHJ1Y3R1cmUgaGVyZSwgeW91IGNhbiBkaXJlY3RseQ0KPiA+PiBpbml0aWFsaXpl
IHRoZSBjcHVpZGxlX2RyaXZlcjoNCj4gPj4NCj4gPg0KPiA+IFRoYW5rcy4gOikNCj4gPg0KPiA+
Pj4gK3N0YXRpYyBpbnQgY3B1X2hvdHBsdWdfbm90aWZ5KHN0cnVjdCBub3RpZmllcl9ibG9jayAq
biwNCj4gPj4+ICsJCQl1bnNpZ25lZCBsb25nIGFjdGlvbiwgdm9pZCAqaGNwdSkgew0KPiA+Pj4g
Kwl1bnNpZ25lZCBsb25nIGhvdGNwdSA9ICh1bnNpZ25lZCBsb25nKWhjcHU7DQo+ID4+PiArCXN0
cnVjdCBjcHVpZGxlX2RldmljZSAqZGV2ID0NCj4gPj4+ICsJCQlwZXJfY3B1X3B0cihjcHVpZGxl
X2RldmljZXMsIGhvdGNwdSk7DQo+ID4+PiArDQo+ID4+PiArCWlmIChkZXYgJiYgY3B1aWRsZV9n
ZXRfZHJpdmVyKCkpIHsNCj4gPj4+ICsJCXN3aXRjaCAoYWN0aW9uKSB7DQo+ID4+PiArCQljYXNl
IENQVV9PTkxJTkU6DQo+ID4+PiArCQljYXNlIENQVV9PTkxJTkVfRlJPWkVOOg0KPiA+Pj4gKwkJ
CWNwdWlkbGVfcGF1c2VfYW5kX2xvY2soKTsNCj4gPj4+ICsJCQljcHVpZGxlX2VuYWJsZV9kZXZp
Y2UoZGV2KTsNCj4gPj4+ICsJCQljcHVpZGxlX3Jlc3VtZV9hbmRfdW5sb2NrKCk7DQo+ID4+PiAr
CQkJYnJlYWs7DQo+ID4+PiArDQo+ID4+PiArCQljYXNlIENQVV9ERUFEOg0KPiA+Pj4gKwkJY2Fz
ZSBDUFVfREVBRF9GUk9aRU46DQo+ID4+PiArCQkJY3B1aWRsZV9wYXVzZV9hbmRfbG9jaygpOw0K
PiA+Pj4gKwkJCWNwdWlkbGVfZGlzYWJsZV9kZXZpY2UoZGV2KTsNCj4gPj4+ICsJCQljcHVpZGxl
X3Jlc3VtZV9hbmRfdW5sb2NrKCk7DQo+ID4+PiArCQkJYnJlYWs7DQo+ID4+PiArDQo+ID4+PiAr
CQlkZWZhdWx0Og0KPiA+Pj4gKwkJCXJldHVybiBOT1RJRllfRE9ORTsNCj4gPj4+ICsJCX0NCj4g
Pj4+ICsJfQ0KPiA+Pj4gKw0KPiA+Pj4gKwlyZXR1cm4gTk9USUZZX09LOw0KPiA+Pj4gK30NCj4g
Pj4+ICsNCj4gPj4+ICtzdGF0aWMgc3RydWN0IG5vdGlmaWVyX2Jsb2NrIGNwdV9ob3RwbHVnX25v
dGlmaWVyID0gew0KPiA+Pj4gKwkubm90aWZpZXJfY2FsbCA9IGNwdV9ob3RwbHVnX25vdGlmeSwg
fTsNCj4gPj4NCj4gPj4gQ2FuIHlvdSBleHBsYWluIHdoeSB0aGlzIGlzIG5lZWRlZCA/DQo+ID4+
DQo+ID4NCj4gPiBJZiBhIGNwdSB3aWxsIGJlIHBsdWdnZWQgb3V0L2luLCBXZSBzaG91bGQgYmUg
bGV0IENwdWlkbGUga25vdyB0bw0KPiA+IHJlbW92ZSBjb3JyZXNwb25kaW5nIHN5cyBpbnRlcmZh
Y2UgYW5kIGRpc2FibGUvZW5hYmxlIGNwdWRpbGUtZ292ZXJub3IgZm9yDQo+IGN1cnJlbnQgY3B1
Lg0KPiANCj4gT2ssIHRoaXMgY29kZSBpcyBhIGNvcHktcGFzdGUgb2YgdGhlIHBvd2VycycgY3B1
aWRsZSBkcml2ZXIuDQo+IA0KPiBJSVJDLCBJIHBvc3RlZCBhIHBhdGNoc2V0IHRvIG1vdmUgdGhp
cyBwb3J0aW9uIG9mIGNvZGUgaW4gdGhlIGNwdWlkbGUgY29tbW9uDQo+IGZyYW1ld29yayBzb21l
IHRpbWUgYWdvLg0KPiANCj4gQ291bGQgeW91IHBsZWFzZSBnZXQgcmlkIG9mIHRoaXMgcGFydCBv
ZiBjb2RlID8NCj4gDQoNClllcywgSSBjYW4uIDopIENvdWxkIHlvdSBzaGFyZSBtZSB5b3VyIHBh
dGNoc2V0IGxpbms/IEkgY2FuJ3QgZm91bmQgdGhlbSBvbiB5b3VyIHRyZWUuDQoNClJlZ2FyZHMs
DQotRG9uZ3NoZW5nDQoNCj4gDQo+ID4+PiArCWVyciA9IHJlZ2lzdGVyX2NwdV9ub3RpZmllcigm
Y3B1X2hvdHBsdWdfbm90aWZpZXIpOw0KPiA+Pj4gKwlpZiAoZXJyKQ0KPiA+Pj4gKwkJcHJfd2Fy
bigiQ3B1aWRsZSBkcml2ZXI6IHJlZ2lzdGVyIGNwdSBub3RpZmllciBmYWlsZWQuXG4iKTsNCj4g
Pj4+ICsNCj4gPj4+ICsJLyogUmVwbGFjZSB0aGUgb3JpZ2luYWwgd2F5IG9mIGlkbGUgYWZ0ZXIg
Y3B1aWRsZSByZWdpc3RlcmVkLiAqLw0KPiA+Pj4gKwlwcGNfbWQucG93ZXJfc2F2ZSA9IGU1MDBf
Y3B1aWRsZTsNCj4gPj4+ICsJb25fZWFjaF9jcHUocmVwbGFjZV9vcmlnX2lkbGUsIE5VTEwsIDEp
Ow0KPiA+Pg0KPiA+PiBXaHkgPw0KPiA+Pg0KPiA+DQo+ID4gSSBjaGVja2VkIGFnYWluLCBpZiB3
ZSBwdXQgY3B1aWRsZV9pZGxlX2NhbGwgaW4gYXNtLCB0aGlzIGlzIG5vdCBuZWVkLg0KPiA+DQo+
ID4gUmVnYXJkcywNCj4gPiAtRG9uZ3NoZW5nDQo+ID4NCj4gPj4+ICsJcHJfaW5mbygiZTUwMF9p
ZGxlX2RyaXZlciByZWdpc3RlcmVkLlxuIik7DQo+ID4+PiArDQo+ID4+PiArCXJldHVybiAwOw0K
PiA+Pj4gK30NCj4gPj4+ICtsYXRlX2luaXRjYWxsKGU1MDBfaWRsZV9pbml0KTsNCj4gPj4+DQo+
ID4+DQo+ID4+IFRoYW5rcw0KPiA+Pg0KPiA+PiAgICAgLS0gRGFuaWVsDQo+ID4+DQo+ID4+DQo+
ID4+IC0tDQo+ID4+ICAgIDxodHRwOi8vd3d3LmxpbmFyby5vcmcvPiBMaW5hcm8ub3JnIOKUgiBP
cGVuIHNvdXJjZSBzb2Z0d2FyZSBmb3IgQVJNDQo+ID4+IFNvQ3MNCj4gPj4NCj4gPj4gRm9sbG93
IExpbmFybzogIDxodHRwOi8vd3d3LmZhY2Vib29rLmNvbS9wYWdlcy9MaW5hcm8+IEZhY2Vib29r
IHwNCj4gPj4gPGh0dHA6Ly90d2l0dGVyLmNvbS8jIS9saW5hcm9vcmc+IFR3aXR0ZXIgfA0KPiA+
PiA8aHR0cDovL3d3dy5saW5hcm8ub3JnL2xpbmFyby1ibG9nLz4gQmxvZw0KPiA+Pg0KPiA+Pg0K
PiA+DQo+IA0KPiANCj4gLS0NCj4gICA8aHR0cDovL3d3dy5saW5hcm8ub3JnLz4gTGluYXJvLm9y
ZyDilIIgT3BlbiBzb3VyY2Ugc29mdHdhcmUgZm9yIEFSTSBTb0NzDQo+IA0KPiBGb2xsb3cgTGlu
YXJvOiAgPGh0dHA6Ly93d3cuZmFjZWJvb2suY29tL3BhZ2VzL0xpbmFybz4gRmFjZWJvb2sgfA0K
PiA8aHR0cDovL3R3aXR0ZXIuY29tLyMhL2xpbmFyb29yZz4gVHdpdHRlciB8IDxodHRwOi8vd3d3
LmxpbmFyby5vcmcvbGluYXJvLWJsb2cvPg0KPiBCbG9nDQo+IA0KPiANCg0K
^ permalink raw reply
* Re: [PATCH 3/7] DMA: Freescale: add fsl_dma_free_descriptor() to reduce code duplication
From: Hongbo Zhang @ 2014-04-03 8:09 UTC (permalink / raw)
To: Vinod Koul
Cc: scottwood, dmaengine, dan.j.williams, linuxppc-dev, linux-kernel
In-Reply-To: <5334F022.3050402@freescale.com>
On 03/28/2014 11:44 AM, Hongbo Zhang wrote:
>
> On 03/11/2014 07:06 PM, Vinod Koul wrote:
>> On Thu, Jan 16, 2014 at 01:47:22PM +0800, hongbo.zhang@freescale.com
>> wrote:
>>> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>>>
>>> There are several places where descriptors are freed using identical
>>> code.
>>> This patch puts this code into a function to reduce code duplication.
>>>
>>> Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
>>> Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
>>> ---
>>> drivers/dma/fsldma.c | 38 ++++++++++++++++++++------------------
>>> 1 file changed, 20 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
>>> index 95236e6..ad73538 100644
>>> --- a/drivers/dma/fsldma.c
>>> +++ b/drivers/dma/fsldma.c
>>> @@ -418,6 +418,21 @@ static dma_cookie_t fsl_dma_tx_submit(struct
>>> dma_async_tx_descriptor *tx)
>>> }
>>> /**
>>> + * fsl_dma_free_descriptor - Free descriptor from channel's DMA pool.
>>> + * @chan : Freescale DMA channel
>>> + * @desc: descriptor to be freed
>>> + */
>>> +static void fsl_dma_free_descriptor(struct fsldma_chan *chan,
>>> + struct fsl_desc_sw *desc)
>>> +{
>>> + list_del(&desc->node);
>>> +#ifdef FSL_DMA_LD_DEBUG
>>> + chan_dbg(chan, "LD %p free\n", desc);
>>> +#endif
>> why not wrap the define stuff in the defination of chan_dbg rather
>> than its
>> usage :(
>>
>
> OK, I will fix it by another separate patch.
> Thanks.
>
Think it again, I'd like to remove the FSL_DMA_LD_DEBUG usage, because
the chan_dbg is a wrapper of dev_dbg, we do have macro to switch on/off
dev_dbg, and most of other codes are calling chan_dbg directly without
FSL_DMA_LD_DEBUG, the FSL_DMA_LD_DEBUG only shows up 3 times unnecessarily.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] cpuidle: add freescale e500 family porcessors idle support
From: Daniel Lezcano @ 2014-04-03 8:12 UTC (permalink / raw)
To: Dongsheng.Wang@freescale.com, Scott Wood
Cc: chenhui.zhao@freescale.com, linux-pm@vger.kernel.org,
rjw@rjwysocki.net, Jason.Jin@freescale.com,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <69cec4d810a448069df4d30bfc861ea5@BN1PR03MB188.namprd03.prod.outlook.com>
On 04/03/2014 10:03 AM, Dongsheng.Wang@freescale.com wrote:
>
>
>> -----Original Message-----
>> From: Daniel Lezcano [mailto:daniel.lezcano@linaro.org]
>> Sent: Thursday, April 03, 2014 2:29 PM
>> To: Wang Dongsheng-B40534; Wood Scott-B07421
>> Cc: rjw@rjwysocki.net; Li Yang-Leo-R58472; Jin Zhengxiong-R64188; Zhao Chenhui-
>> B35336; linux-pm@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
>> Subject: Re: [PATCH] cpuidle: add freescale e500 family porcessors idle support
>>
>> On 04/03/2014 05:20 AM, Dongsheng.Wang@freescale.com wrote:
>>> Hi Daniel,
>>>
>>> Thanks for your review. I will fix your comments.
>>>
>>> BTW, fix Rafael's email. :)
>>>
>>>>> +#include <linux/cpu.h>
>>>>> +#include <linux/cpuidle.h>
>>>>> +#include <linux/init.h>
>>>>> +#include <linux/kernel.h>
>>>>> +#include <linux/notifier.h>
>>>>> +
>>>>> +#include <asm/cputable.h>
>>>>> +#include <asm/machdep.h>
>>>>> +#include <asm/mpc85xx.h>
>>>>> +
>>>>> +static unsigned int max_idle_state; static struct cpuidle_state
>>>>> +*cpuidle_state_table;
>>>>> +
>>>>> +struct cpuidle_driver e500_idle_driver = {
>>>>> + .name = "e500_idle",
>>>>> + .owner = THIS_MODULE,
>>>>> +};
>>>>> +
>>>>> +static void e500_cpuidle(void)
>>>>> +{
>>>>> + if (cpuidle_idle_call())
>>>>> + cpuidle_wait();
>>>>> +}
>>>>
>>>> Nope, that has been changed. No more call to cpuidle_idle_call in a driver.
>>>>
>>>
>>> Thanks.
>>>
>>>>> +
>>>>> +static int pw10_enter(struct cpuidle_device *dev,
>>>>> + struct cpuidle_driver *drv, int index) {
>>>>> + cpuidle_wait();
>>>>> + return index;
>>>>> +}
>>>>> +
>>>>> +#define MAX_BIT 63
>>>>> +#define MIN_BIT 1
>>>>> +extern u32 cpuidle_entry_bit;
>>>>> +static int pw20_enter(struct cpuidle_device *dev,
>>>>> + struct cpuidle_driver *drv, int index) {
>>>>> + u32 pw20_idle;
>>>>> + u32 entry_bit;
>>>>> + pw20_idle = mfspr(SPRN_PWRMGTCR0);
>>>>> + if ((pw20_idle & PWRMGTCR0_PW20_ENT) != PWRMGTCR0_PW20_ENT) {
>>>>> + pw20_idle &= ~PWRMGTCR0_PW20_ENT;
>>>>> + entry_bit = MAX_BIT - cpuidle_entry_bit;
>>>>> + pw20_idle |= (entry_bit << PWRMGTCR0_PW20_ENT_SHIFT);
>>>>> + mtspr(SPRN_PWRMGTCR0, pw20_idle);
>>>>> + }
>>>>> +
>>>>> + cpuidle_wait();
>>>>> +
>>>>> + pw20_idle &= ~PWRMGTCR0_PW20_ENT;
>>>>> + pw20_idle |= (MIN_BIT << PWRMGTCR0_PW20_ENT_SHIFT);
>>>>> + mtspr(SPRN_PWRMGTCR0, pw20_idle);
>>>>> +
>>>>> + return index;
>>>>> +}
>>>>
>>>> Is it possible to give some comments and encapsulate the code with
>>>> explicit function names to be implemented in an arch specific
>>>> directory file (eg. pm.c) and export these functions in a linux/
>>>> header ? We try to prevent to include asm if possible.
>>>>
>>>
>>> Yep, Looks better. Thanks.
>>>
>>>>> +
>>>>> +static struct cpuidle_state pw_idle_states[] = {
>>>>> + {
>>>>> + .name = "pw10",
>>>>> + .desc = "pw10",
>>>>> + .flags = CPUIDLE_FLAG_TIME_VALID,
>>>>> + .exit_latency = 0,
>>>>> + .target_residency = 0,
>>>>> + .enter = &pw10_enter
>>>>> + },
>>>>> +
>>>>> + {
>>>>> + .name = "pw20",
>>>>> + .desc = "pw20-core-idle",
>>>>> + .flags = CPUIDLE_FLAG_TIME_VALID,
>>>>> + .exit_latency = 1,
>>>>> + .target_residency = 50,
>>>>> + .enter = &pw20_enter
>>>>> + },
>>>>> +};
>>>>
>>>> No need to define this intermediate structure here, you can directly
>>>> initialize the cpuidle_driver:
>>>>
>>>
>>> Thanks. :)
>>>
>>>>> +static int cpu_hotplug_notify(struct notifier_block *n,
>>>>> + unsigned long action, void *hcpu) {
>>>>> + unsigned long hotcpu = (unsigned long)hcpu;
>>>>> + struct cpuidle_device *dev =
>>>>> + per_cpu_ptr(cpuidle_devices, hotcpu);
>>>>> +
>>>>> + if (dev && cpuidle_get_driver()) {
>>>>> + switch (action) {
>>>>> + case CPU_ONLINE:
>>>>> + case CPU_ONLINE_FROZEN:
>>>>> + cpuidle_pause_and_lock();
>>>>> + cpuidle_enable_device(dev);
>>>>> + cpuidle_resume_and_unlock();
>>>>> + break;
>>>>> +
>>>>> + case CPU_DEAD:
>>>>> + case CPU_DEAD_FROZEN:
>>>>> + cpuidle_pause_and_lock();
>>>>> + cpuidle_disable_device(dev);
>>>>> + cpuidle_resume_and_unlock();
>>>>> + break;
>>>>> +
>>>>> + default:
>>>>> + return NOTIFY_DONE;
>>>>> + }
>>>>> + }
>>>>> +
>>>>> + return NOTIFY_OK;
>>>>> +}
>>>>> +
>>>>> +static struct notifier_block cpu_hotplug_notifier = {
>>>>> + .notifier_call = cpu_hotplug_notify, };
>>>>
>>>> Can you explain why this is needed ?
>>>>
>>>
>>> If a cpu will be plugged out/in, We should be let Cpuidle know to
>>> remove corresponding sys interface and disable/enable cpudile-governor for
>> current cpu.
>>
>> Ok, this code is a copy-paste of the powers' cpuidle driver.
>>
>> IIRC, I posted a patchset to move this portion of code in the cpuidle common
>> framework some time ago.
>>
>> Could you please get rid of this part of code ?
>>
>
> Yes, I can. :) Could you share me your patchset link? I can't found them on your tree.
>
It was a while ago. I should have it somewhere locally. I will find it
out and resend the patch next week when finishing my current task.
-- Daniel
>> --
>> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>
>> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
>> <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/>
>> Blog
>>
>>
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH] power, sched: stop updating inside arch_update_cpu_topology() when nothing to be update
From: Srivatsa S. Bhat @ 2014-04-03 8:50 UTC (permalink / raw)
To: Michael wang
Cc: sfr, Srikar Dronamraju, LKML, jlarrew, paulus, alistair, nfont,
Andrew Morton, rcj, linuxppc-dev
In-Reply-To: <533B8431.8090507@linux.vnet.ibm.com>
On 04/02/2014 08:59 AM, Michael wang wrote:
> During the testing, we encounter below WARN followed by Oops:
>
> WARNING: at kernel/sched/core.c:6218
> ...
> NIP [c000000000101660] .build_sched_domains+0x11d0/0x1200
> LR [c000000000101358] .build_sched_domains+0xec8/0x1200
> PACATMSCRATCH [800000000000f032]
> Call Trace:
> [c00000001b103850] [c000000000101358] .build_sched_domains+0xec8/0x1200
> [c00000001b1039a0] [c00000000010aad4] .partition_sched_domains+0x484/0x510
> [c00000001b103aa0] [c00000000016d0a8] .rebuild_sched_domains+0x68/0xa0
> [c00000001b103b30] [c00000000005cbf0] .topology_work_fn+0x10/0x30
> ...
> Oops: Kernel access of bad area, sig: 11 [#1]
> ...
> NIP [c00000000045c000] .__bitmap_weight+0x60/0xf0
> LR [c00000000010132c] .build_sched_domains+0xe9c/0x1200
> PACATMSCRATCH [8000000000029032]
> Call Trace:
> [c00000001b1037a0] [c000000000288ff4] .kmem_cache_alloc_node_trace+0x184/0x3a0
> [c00000001b103850] [c00000000010132c] .build_sched_domains+0xe9c/0x1200
> [c00000001b1039a0] [c00000000010aad4] .partition_sched_domains+0x484/0x510
> [c00000001b103aa0] [c00000000016d0a8] .rebuild_sched_domains+0x68/0xa0
> [c00000001b103b30] [c00000000005cbf0] .topology_work_fn+0x10/0x30
> ...
>
> This was caused by that 'sd->groups == NULL' after building groups, which
> was caused by the empty 'sd->span'.
>
> The cpu's domain contain nothing because the cpu was assigned to wrong
> node inside arch_update_cpu_topology() by calling update_lookup_table()
> with the uninitialized param, in the case when there is nothing to be
> update.
>
I think we need to verify this theory. Here are my thoughts:
If we get a topology update notification from the hypervisor, and then the
update happens to be nothing new (as in, new_node == old_node for the given
cpu), then updated_cpus mask will not have any cpus set in it (like you noted
below). In that scenario, the following sequence will take place:
Inside arch_cpu_update_topology(), the 'updates' has been kzalloc()'ed.
So updates[0] will have all its fields set to 0, such as ->cpu, ->new_nid etc.
When we invoke stop_machine() the first time like this:
stop_machine(update_cpu_topology, &updates[0], &updated_cpus);
stop-machine will notice that updated_cpus mask does not have any cpus set
in it, so it will nominate cpumask_first(cpu_online_mask) to run the
update_cpu_topology() function, which means that CPU0 will run it.
So, when CPU0 runs update_cpu_topology(), it will find that cpu == update->cpu
since both are 0, and will invoke unmap_cpu_from_node() and then calls
map_cpu_to_node(), with update->new_nid == 0.
Now, the interesting thing to note here is that, if CPU0's node was already
set as node0, *nothing* should go wrong, since its just a redundant update.
However, if CPU0's original node mapping was something different, or if
node0 doesn't even exist in the machine, then the system can crash.
Have you verified that CPU0's node mapping is different from node 0?
That is, boot the kernel with "numa=debug" in the kernel command line and
it will print out the cpu-to-node associativity during boot. That way you
can figure out what was the original associativity that was set. This will
confirm the theory that the hypervisor sent a redundant update, but because
of the weird pre-allocation using kzalloc that we do inside
arch_update_cpu_topology(), we wrongly updated CPU0's mapping as CPU0 <-> Node0.
Regards,
Srivatsa S. Bhat
> Thus we should stop the updating in such cases, this patch will achieve
> this and fix the issue.
>
> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Paul Mackerras <paulus@samba.org>
> CC: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> CC: Stephen Rothwell <sfr@canb.auug.org.au>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: Robert Jennings <rcj@linux.vnet.ibm.com>
> CC: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
> CC: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
> CC: Alistair Popple <alistair@popple.id.au>
> Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
> ---
> arch/powerpc/mm/numa.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 30a42e2..6757690 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -1591,6 +1591,14 @@ int arch_update_cpu_topology(void)
> cpu = cpu_last_thread_sibling(cpu);
> }
>
> + /*
> + * The 'cpu_associativity_changes_mask' could be cleared if
> + * all the cpus it indicates won't change their node, in
> + * which case the 'updated_cpus' will be empty.
> + */
> + if (!cpumask_weight(&updated_cpus))
> + goto out;
> +
> stop_machine(update_cpu_topology, &updates[0], &updated_cpus);
>
> /*
> @@ -1612,6 +1620,7 @@ int arch_update_cpu_topology(void)
> changed = 1;
> }
>
> +out:
> kfree(updates);
> return changed;
> }
>
^ permalink raw reply
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: zhuyj @ 2014-04-03 9:11 UTC (permalink / raw)
To: sandeep.kumar, netdev, linux-kernel, Tao, Yue,
Yang, Zhangle (Eric), guang.yang, joe, festevam, linuxppc-dev,
richardcochran, clarocq, yongjun_wei, Claudiu Manoil, w, zhuyj
In-Reply-To: <53310F4E.4080104@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4932 bytes --]
Hi, Claudiu
Please help to review this patch. This patch is for kernel 2.6.x. Thanks
a lot.
Hi, Willy
Please help to merge this patch to longterm: 2.6.32.61 since this
problem also occurs on this kernel. Thanks a lot.
Based on kernel 2.6.x, gianfar nic driver can not work well. The root
cause is that tx vlan of gianfar can not handle VLAN tag 0. So on kernel
3.0+, this tx vlan feature is disabled. But on kernel 2.6.x, this
feature is still enabled. This patch will disable this feature of
gianfar nic driver. If this feature is enabled, gianfar nic can not
support vlan packets and non-vlan packets at the same time. The
following steps will reproduce this problem.
The steps are as below.
1. boot two freescale-p2020 boards with linux kernel 2.6.x, then
connected 2 gfar-enet nic cards with a direct network line;
2. On board 1, checked the driver of eth0
ethtool -i eth0
driver: gfar-enet
version: 1.3
firmware-version: N/A
bus-info: N/A
On board 2, I checked the driver of eth1
ethtool -i eth1
driver: gfar-enet
version: 1.3
firmware-version: N/A
bus-info: N/A
3. Then configure the ip address on the above 2 nic cards.
On board 1,
ifconfig eth0 192.168.1.13/24 up
On board 2,
ifconfig eth1 192.168.1.196/24 up
4. We can access the other board on one board.
For example, on board 1, we can ping board 2.
root@p2020rdb:/root> ping 192.168.1.196
PING 192.168.1.196 (192.168.1.196) 56(84) bytes of data.
64 bytes from 192.168.1.196: icmp_req=1 ttl=64 time=2.92 ms
64 bytes from 192.168.1.196: icmp_req=2 ttl=64 time=0.096 ms
5. We configure vlan on these 2 boards. VLAN tag 0
On board 1,
modprobe 8021q
vconfig add eth0 4091
ifconfig eth0.4091 10.1.1.13/24 up
On board 2,
modprobe 8021q
vconfig add eth1 4091
ifconfig eth1.4091 10.1.1.196/24 up
6. We can access the other board on one board through vlan.
For example, on board 1, we can ping board 2 through vlan nic.
root@p2020rdb:/root> ping 10.1.1.196
PING 10.1.1.196 (10.1.1.196) 56(84) bytes of data.
64 bytes from 10.1.1.196: icmp_req=1 ttl=64 time=2.92 ms
64 bytes from 10.1.1.196: icmp_req=2 ttl=64 time=0.096 ms
But we can not access the other board on one board through raw nic.
For example, on board, we can not ping board 2.
root@p2020rdb:/root> ping 192.168.1.196
From 192.168.1.196 icmp_seq=1 Destination Host Unreachable
From 192.168.1.196 icmp_seq=2 Destination Host Unreachable
From 192.168.1.196 icmp_seq=3 Destination Host Unreachable
Best Regards!
Zhu Yanjun
On 03/25/2014 01:08 PM, zhuyj wrote:
> Hi, Sandeep Gopalpet
>
> I am a developer. Now I confronted an interesting phenomena. When I
> used linux kernel 2.6.34.15 on freescale-p2020, I can not receive raw
> and vlan packets on gfar-enet nic. But with e1000e nic, we can make
> vlan and raw packets work well. I looked into the source code and find
> that maybe it is related with hardware insert and remove vlan head.
> But I have no the specifications of gfar-enet nic. Would you like to
> give some document or some guides?
>
> Thanks a lot.
> Zhu Yanjun
>
> The steps are as below.
>
> 1. I boot two freescale-p2020 boards with linux kernel 2.6.34.15, then
> I connected 2 gfar-enet nic cards with a direct network line;
>
> 2. On board 1, I checked the driver of eth0
>
> ethtool -i eth0
>
> driver: gfar-enet
> version: 1.3
> firmware-version: N/A
> bus-info: N/A
>
> On board 2, I checked the driver of eth1
>
> ethtool -i eth1
>
> driver: gfar-enet
> version: 1.3
> firmware-version: N/A
> bus-info: N/A
>
> 3. Then I configure the ip address on the above 2 nic cards.
>
> On board 1,
>
> ifconfig eth0 192.168.1.13/24 up
>
> On board 2,
>
> ifconfig eth1 192.168.1.196/24 up
>
> 4. We can access the other board on one board.
> For example, on board 1, we can ping board 2.
>
> root@p2020rdb:/root> ping 192.168.1.196
> PING 192.168.1.196 (192.168.1.196) 56(84) bytes of data.
> 64 bytes from 192.168.1.196: icmp_req=1 ttl=64 time=2.92 ms
> 64 bytes from 192.168.1.196: icmp_req=2 ttl=64 time=0.096 ms
>
> 5. We configure vlan on these 2 boards. VLAN tag 0
> On board 1,
>
> modprobe 8021q
> vconfig add eth0 4091
> ifconfig eth0.4091 10.1.1.13/24 up
>
> On board 2,
>
> modprobe 8021q
> vconfig add eth1 4091
> ifconfig eth1.4091 10.1.1.196/24 up
>
> 6. We can access the other board on one board through vlan.
> For example, on board 1, we can ping board 2 through vlan nic.
>
> root@p2020rdb:/root> ping 10.1.1.196
> PING 10.1.1.196 (10.1.1.196) 56(84) bytes of data.
> 64 bytes from 10.1.1.196: icmp_req=1 ttl=64 time=2.92 ms
> 64 bytes from 10.1.1.196: icmp_req=2 ttl=64 time=0.096 ms
>
> But we can not access the other board on one board through raw nic.
> For example, on board, we can not ping board 2.
>
> root@p2020rdb:/root> ping 192.168.1.196
> From 192.168.1.196 icmp_seq=1 Destination Host Unreachable
> From 192.168.1.196 icmp_seq=2 Destination Host Unreachable
> From 192.168.1.196 icmp_seq=3 Destination Host Unreachable
>
>
[-- Attachment #2: 0001-gianfar-disable-TX-vlan-based-on-kernel-2.6.x.patch --]
[-- Type: text/x-patch, Size: 1491 bytes --]
>From afd48fa3ad5b15d519adeb19b2a9c00051327c68 Mon Sep 17 00:00:00 2001
From: Zhu Yanjun <Yanjun.Zhu@windriver.com>
Date: Thu, 3 Apr 2014 16:41:13 +0800
Subject: [PATCH 1/1] gianfar: disable TX vlan based on kernel 2.6.x
Since there is something wrong with tx vlan of gianfar nic driver,
on kernel(3.0+), tx vlan is disabled. But on kernel 2.6.x, tx vlan
is still enabled. Thus,gianfar nic driver can not support vlan
packets and non-vlan packets.
Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
---
drivers/net/gianfar.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 934a28f..8aa2cf6 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -365,7 +365,7 @@ static int gfar_probe(struct of_device *ofdev,
priv->vlgrp = NULL;
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_VLAN)
- dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
+ dev->features |= NETIF_F_HW_VLAN_RX;
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_EXTENDED_HASH) {
priv->extended_hash = 1;
@@ -1451,12 +1451,6 @@ static void gfar_vlan_rx_register(struct net_device *dev,
priv->vlgrp = grp;
if (grp) {
- /* Enable VLAN tag insertion */
- tempval = gfar_read(&priv->regs->tctrl);
- tempval |= TCTRL_VLINS;
-
- gfar_write(&priv->regs->tctrl, tempval);
-
/* Enable VLAN tag extraction */
tempval = gfar_read(&priv->regs->rctrl);
tempval |= (RCTRL_VLEX | RCTRL_PRSDEP_INIT);
--
1.7.9.5
^ permalink raw reply related
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: Willy Tarreau @ 2014-04-03 9:27 UTC (permalink / raw)
To: zhuyj
Cc: Yang, Zhangle (Eric), netdev, richardcochran, linuxppc-dev,
guang.yang, linux-kernel, yongjun_wei, sandeep.kumar,
Claudiu Manoil, Tao, Yue, joe, festevam, clarocq
In-Reply-To: <533D25D4.4000607@gmail.com>
Hi Zhu,
On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote:
> Hi, Claudiu
>
> Please help to review this patch. This patch is for kernel 2.6.x. Thanks
> a lot.
>
> Hi, Willy
>
> Please help to merge this patch to longterm: 2.6.32.61 since this
> problem also occurs on this kernel. Thanks a lot.
Could you please send the reference to the equivalent mainline commit (the one
which disables the tx vlan feature I'm assuming) ? I'll happily queue it for
2.6.32.62.
Thanks,
Willy
^ permalink raw reply
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: zhuyj @ 2014-04-03 9:57 UTC (permalink / raw)
To: Willy Tarreau
Cc: Yang, Zhangle (Eric), netdev, richardcochran, linuxppc-dev,
guang.yang, linux-kernel, yongjun_wei, sandeep.kumar,
Claudiu Manoil, Tao, Yue, joe, festevam, clarocq
In-Reply-To: <20140403092727.GD16158@1wt.eu>
On 04/03/2014 05:27 PM, Willy Tarreau wrote:
> Hi Zhu,
>
> On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote:
>> Hi, Claudiu
>>
>> Please help to review this patch. This patch is for kernel 2.6.x. Thanks
>> a lot.
>>
>> Hi, Willy
>>
>> Please help to merge this patch to longterm: 2.6.32.61 since this
>> problem also occurs on this kernel. Thanks a lot.
> Could you please send the reference to the equivalent mainline commit (the one
> which disables the tx vlan feature I'm assuming) ? I'll happily queue it for
> 2.6.32.62.
>
> Thanks,
> Willy
>
>
Hi, Willy
I reference the following 2 mainline commits. These 2 commits are based
on the current kernel 3.x and ethtool.
If we only backport these 2 commits on kernel 2.6.x, this problem will
not be fixed yet.
Best Regards!
Zhu Yanjun
1. commit 87c288c6e9aa31720b72e2bc2d665e24e1653c3e
Author: Jiri Pirko <jpirko@redhat.com>
Date: Wed Jul 20 04:54:19 2011 +0000
gianfar: do vlan cleanup
- unify vlan and nonvlan rx path
- kill priv->vlgrp and gfar_vlan_rx_register
- allow to turn on/off rx/tx vlan accel via ethtool
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net/gianfar.c | 55
++++++++++++++++++++++++++-----------------------
1 file changed, 29 insertions(+), 26 deletions(-)
2.commit b852b720877e6b8e12b95a7cb4e00ea351b8cbfc
Author: Sebastian Pöhn <sebastian.belden@googlemail.com>
Date: Tue Jul 26 00:03:13 2011 +0000
gianfar: fix bug caused by 87c288c6e9aa31720b72e2bc2d665e24e1653c3e
commit 87c288c6e9aa31720b72e2bc2d665e24e1653c3e "gianfar: do vlan
cleanup" has two issues:
# permutation of rx and tx flags
# enabling vlan tag insertion by default (this leads to unusable
connections on some configurations)
If VLAN insertion is requested (via ethtool) it will be set at an
other point ...
Signed-off-by: Sebastian Poehn <sebastian.poehn@belden.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net/gianfar.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
^ permalink raw reply
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: Willy Tarreau @ 2014-04-03 10:01 UTC (permalink / raw)
To: zhuyj
Cc: Yang, Zhangle (Eric), netdev, richardcochran, linuxppc-dev,
guang.yang, linux-kernel, yongjun_wei, sandeep.kumar,
Claudiu Manoil, Tao, Yue, joe, festevam, clarocq
In-Reply-To: <533D30A1.1060509@gmail.com>
Hi Zhu,
On Thu, Apr 03, 2014 at 05:57:53PM +0800, zhuyj wrote:
> I reference the following 2 mainline commits. These 2 commits are based
> on the current kernel 3.x and ethtool.
> If we only backport these 2 commits on kernel 2.6.x, this problem will
> not be fixed yet.
OK fine, I just wanted that we keep the reference of these equivalent
patches in the commit message so that if later a newer patch changes
anything they did, at least we have some indications that the commit
might also have to be revisited.
I'll merge your patch and put these references there.
Thanks,
Willy
^ permalink raw reply
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: zhuyj @ 2014-04-03 10:15 UTC (permalink / raw)
To: Willy Tarreau
Cc: Yang, Zhangle (Eric), netdev, richardcochran, linuxppc-dev,
guang.yang, linux-kernel, yongjun_wei, zhuyj, sandeep.kumar,
Claudiu Manoil, Tao, Yue, joe, festevam, clarocq
In-Reply-To: <20140403092727.GD16158@1wt.eu>
[-- Attachment #1: Type: text/plain, Size: 808 bytes --]
On 04/03/2014 05:27 PM, Willy Tarreau wrote:
> Hi Zhu,
>
> On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote:
>> Hi, Claudiu
>>
>> Please help to review this patch. This patch is for kernel 2.6.x. Thanks
>> a lot.
>>
>> Hi, Willy
>>
>> Please help to merge this patch to longterm: 2.6.32.61 since this
>> problem also occurs on this kernel. Thanks a lot.
> Could you please send the reference to the equivalent mainline commit (the one
> which disables the tx vlan feature I'm assuming) ? I'll happily queue it for
> 2.6.32.62.
>
> Thanks,
> Willy
>
>
Hi, Willy
I made a new patch. In long commit message, I inserted the equivalent
mainline commit
about this feature. Maybe it is better. Now this patch is in the
attachment. Please check
and merge it into kernel 2.6.32.62.
Thanks a lot.
Zhu Yanjun
[-- Attachment #2: 0001-gianfar-disable-TX-vlan-based-on-kernel-2.6.x.patch --]
[-- Type: text/x-patch, Size: 1688 bytes --]
>From 3b74ad6134f8eccce9ee391fb02ff15863630c1b Mon Sep 17 00:00:00 2001
From: Zhu Yanjun <Yanjun.Zhu@windriver.com>
Date: Thu, 3 Apr 2014 16:41:13 +0800
Subject: [PATCH 1/1] gianfar: disable TX vlan based on kernel 2.6.x
2.6.x kernels require a similar logic change as commit e1653c3e
[gianfar: do vlan cleanup] and commit 51b8cbfc
[gianfar: fix bug caused by e1653c3e] introduces for newer kernels.
Since there is something wrong with tx vlan of gianfar nic driver,
in kernel(3.1+), tx vlan is disabled. But in kernel 2.6.x, tx vlan
is still enabled. Thus,gianfar nic driver can not support vlan
packets and non-vlan packets at the same time.
Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
---
drivers/net/gianfar.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 934a28f..8aa2cf6 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -365,7 +365,7 @@ static int gfar_probe(struct of_device *ofdev,
priv->vlgrp = NULL;
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_VLAN)
- dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
+ dev->features |= NETIF_F_HW_VLAN_RX;
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_EXTENDED_HASH) {
priv->extended_hash = 1;
@@ -1451,12 +1451,6 @@ static void gfar_vlan_rx_register(struct net_device *dev,
priv->vlgrp = grp;
if (grp) {
- /* Enable VLAN tag insertion */
- tempval = gfar_read(&priv->regs->tctrl);
- tempval |= TCTRL_VLINS;
-
- gfar_write(&priv->regs->tctrl, tempval);
-
/* Enable VLAN tag extraction */
tempval = gfar_read(&priv->regs->rctrl);
tempval |= (RCTRL_VLEX | RCTRL_PRSDEP_INIT);
--
1.7.9.5
^ permalink raw reply related
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: zhuyj @ 2014-04-03 10:18 UTC (permalink / raw)
To: Willy Tarreau
Cc: Yang, Zhangle (Eric), netdev, richardcochran, linuxppc-dev,
guang.yang, linux-kernel, yongjun_wei, zhuyj, sandeep.kumar,
Claudiu Manoil, Tao, Yue, joe, festevam, clarocq
In-Reply-To: <20140403100128.GE16158@1wt.eu>
On 04/03/2014 06:01 PM, Willy Tarreau wrote:
> Hi Zhu,
>
> On Thu, Apr 03, 2014 at 05:57:53PM +0800, zhuyj wrote:
>> I reference the following 2 mainline commits. These 2 commits are based
>> on the current kernel 3.x and ethtool.
>> If we only backport these 2 commits on kernel 2.6.x, this problem will
>> not be fixed yet.
> OK fine, I just wanted that we keep the reference of these equivalent
> patches in the commit message so that if later a newer patch changes
> anything they did, at least we have some indications that the commit
> might also have to be revisited.
>
> I'll merge your patch and put these references there.
>
> Thanks,
> Willy
OK. Thanks a lot.
Zhu Yanjun
> .
>
^ permalink raw reply
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: Willy Tarreau @ 2014-04-03 10:21 UTC (permalink / raw)
To: zhuyj
Cc: Yang, Zhangle (Eric), netdev, richardcochran, linuxppc-dev,
guang.yang, linux-kernel, yongjun_wei, sandeep.kumar,
Claudiu Manoil, Tao, Yue, joe, festevam, clarocq
In-Reply-To: <533D34BD.900@gmail.com>
On Thu, Apr 03, 2014 at 06:15:25PM +0800, zhuyj wrote:
> Hi, Willy
>
> I made a new patch. In long commit message, I inserted the equivalent
> mainline commit
> about this feature. Maybe it is better. Now this patch is in the
> attachment. Please check
> and merge it into kernel 2.6.32.62.
Sure, it's much better this way.
Thanks!
Willy
^ permalink raw reply
* Re: [PATCH RFC v10 0/6] MPC512x DMA slave s/g support, OF DMA lookup
From: Alexander Popov @ 2014-04-03 10:59 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine
Cc: devicetree
In-Reply-To: <1395326878-25243-1-git-send-email-a13xp0p0v88@gmail.com>
Hello,
2014-03-20 18:47 GMT+04:00 Alexander Popov <a13xp0p0v88@gmail.com>:
> Changes in v10:
> Part 2/6:
> - don't use direction field of dma_slave_config in mpc_dma_device_control()
> but store settings in mpc_dma_chan for both DMA_DEV_TO_MEM and
> DMA_MEM_TO_DEV cases; then retrieve the needed values in
> mpc_dma_prep_slave_sg();
> - fix style issue and put 2014 instead of 2013;
> Part 3/6:
> - fix mpc_dma_probe() error path and mpc_dma_remove(): manually free IRQs and
> dispose IRQ mappings before devm_* takes care of other resources;
> Part 6/6:
> - change according the new part 3/6;
> - fix style issue;
Excuse me, could I have a feedback?
Thanks!
> Alexander Popov (5):
> dma: mpc512x: reorder mpc8308 specific instructions
> dma: mpc512x: add support for peripheral transfers
> dma: mpc512x: fix freeing resources in mpc_dma_probe() and
> mpc_dma_remove()
> dma: of: Add common xlate function for matching by channel id
> dma: mpc512x: register for device tree channel lookup
>
> Gerhard Sittig (1):
> dma: mpc512x: add device tree binding document
>
> .../devicetree/bindings/dma/mpc512x-dma.txt | 55 ++++
> arch/powerpc/boot/dts/mpc5121.dtsi | 1 +
> drivers/dma/mpc512x_dma.c | 345 ++++++++++++++++++---
> drivers/dma/of-dma.c | 35 +++
> include/linux/of_dma.h | 4 +
> 5 files changed, 402 insertions(+), 38 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/dma/mpc512x-dma.txt
>
> --
> 1.8.4.2
Best regards,
Alexander
^ permalink raw reply
* Re: [PATCH v2] powernv: kvm: make _PAGE_NUMA take effect
From: Alexander Graf @ 2014-04-03 11:36 UTC (permalink / raw)
To: Liu ping fan, Alexander Graf
Cc: kvm-devel, kvm-ppc, Paul Mackerras, Aneesh Kumar K.V,
linuxppc-dev
In-Reply-To: <CAFgQCTs8LSXUi+AwxR9j+2-QRGw4EFZWx-JxktAnJ3VvwLJb9A@mail.gmail.com>
On 03.04.14 04:36, Liu ping fan wrote:
> Hi Alex, could you help to pick up this patch? since v3.14 kernel can
> enable numa fault for powerpc.
What bad happens without this patch? We map a page even though it was
declared to get NUMA migrated? What happens next?
I'm trying to figure out whether I need to mark this with a stable tag
for 3.14.
Alex
^ permalink raw reply
* Re: [PATCH v2] powernv: kvm: make _PAGE_NUMA take effect
From: Alexander Graf @ 2014-04-03 11:38 UTC (permalink / raw)
To: Liu ping fan, Alexander Graf
Cc: kvm-devel, kvm-ppc, Paul Mackerras, Aneesh Kumar K.V,
linuxppc-dev
In-Reply-To: <533D47CD.906@suse.com>
On 03.04.14 13:36, Alexander Graf wrote:
>
> On 03.04.14 04:36, Liu ping fan wrote:
>> Hi Alex, could you help to pick up this patch? since v3.14 kernel can
>> enable numa fault for powerpc.
>
> What bad happens without this patch? We map a page even though it was
> declared to get NUMA migrated? What happens next?
>
> I'm trying to figure out whether I need to mark this with a stable tag
> for 3.14.
Also, what about the other uses of pre_present()?
Alex
^ permalink raw reply
* Re: [PATCH v2] powernv: kvm: make _PAGE_NUMA take effect
From: Alexander Graf @ 2014-04-03 11:43 UTC (permalink / raw)
To: Liu ping fan, Alexander Graf
Cc: kvm-devel, kvm-ppc, Paul Mackerras, Aneesh Kumar K.V,
linuxppc-dev
In-Reply-To: <533D4834.7050306@suse.com>
On 03.04.14 13:38, Alexander Graf wrote:
>
> On 03.04.14 13:36, Alexander Graf wrote:
>>
>> On 03.04.14 04:36, Liu ping fan wrote:
>>> Hi Alex, could you help to pick up this patch? since v3.14 kernel can
>>> enable numa fault for powerpc.
>>
>> What bad happens without this patch? We map a page even though it was
>> declared to get NUMA migrated? What happens next?
>>
>> I'm trying to figure out whether I need to mark this with a stable
>> tag for 3.14.
>
> Also, what about the other uses of pre_present()?
Oh how I love to reply to myself. The patch doesn't apply to the latest
code anymore either. Also please rework the wording of your patch
subject and patch description to explain the actual problem at hand.
Alex
^ permalink raw reply
* cscope: issue with symlinks in tools/testing/selftests/powerpc/copyloops/
From: Yann Droneaud @ 2014-04-03 13:16 UTC (permalink / raw)
To: Michael Ellerman, Anton Blanchard, Benjamin Herrenschmidt,
Hans-Bernhard Bröker, Hans-Bernhard Broeker, Neil Horman,
Neil Horman
Cc: cscope-devel, linuxppc-dev, linux-kernel
Hi,
I'm using cscope to browse kernel sources, but I'm facing warnings from
the tool since following commit:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=22d651dcef536c75f75537290bf3da5038e68b6b
commit 22d651dcef536c75f75537290bf3da5038e68b6b
Author: Michael Ellerman <mpe@ellerman.id.au>
Date: Tue Jan 21 15:22:17 2014 +1100
selftests/powerpc: Import Anton's memcpy / copy_tofrom_user tests
Turn Anton's memcpy / copy_tofrom_user test into something that can
live in tools/testing/selftests.
It requires one turd in arch/powerpc/lib/memcpy_64.S, but it's
pretty harmless IMHO.
We are sailing very close to the wind with the feature macros. We
define them to nothing, which currently means we get a few extra
nops and include the unaligned calls.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
cscope reports error when generating the cross-reference database:
$ make ALLSOURCE_ARCHS=all O=./obj-cscope/ cscope
GEN cscope
cscope: cannot find
file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_power7.S
cscope: cannot find
file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_64.S
cscope: cannot find
file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_power7.S
cscope: cannot find
file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_64.S
And when calling cscope from ./obj-cscope/ directory, it reports errors
too.
Hopefully it doesn't stop it from working, so I'm still able to use
cscope to browse kernel sources.
It's a rather uncommon side effect of having (for the first time ?)
sources files as symlinks: looking for symlinks in the kernel sources
returns only:
$ find . -type l
./arch/mips/boot/dts/include/dt-bindings
./arch/microblaze/boot/dts/system.dts
./arch/powerpc/boot/dts/include/dt-bindings
./arch/metag/boot/dts/include/dt-bindings
./arch/arm/boot/dts/include/dt-bindings
./tools/testing/selftests/powerpc/copyloops/copyuser_power7.S
./tools/testing/selftests/powerpc/copyloops/memcpy_64.S
./tools/testing/selftests/powerpc/copyloops/memcpy_power7.S
./tools/testing/selftests/powerpc/copyloops/copyuser_64.S
./obj-cscope/source
./Documentation/DocBook/vidioc-g-sliced-vbi-cap.xml
./Documentation/DocBook/vidioc-decoder-cmd.xml
...
./Documentation/DocBook/media-func-ioctl.xml
./Documentation/DocBook/vidioc-enumoutput.xml
So one can wonder if having symlinked sources files is an expected
supported feature for kbuild and all the various kernel
tools/infrastructure ?
Regarding cscope specifically, it does not support symlink, and it's the
expected behavior according to the bug reports I was able to find:
#214 cscope ignores symlinks to files
http://sourceforge.net/p/cscope/bugs/214/
#229 -I options doesn't handle symbolic link
http://sourceforge.net/p/cscope/bugs/229/
#247 cscope: cannot find file
http://sourceforge.net/p/cscope/bugs/247/
#252 cscope: cannot find file ***
http://sourceforge.net/p/cscope/bugs/252/
#261 Regression - version 15.7a does not follow symbolic links
http://sourceforge.net/p/cscope/bugs/261/
Regards.
--
Yann Droneaud
OPTEYA
^ permalink raw reply
* Re: [RFC PATCH] hugetlb: ensure hugepage access is denied if hugepages are not supported
From: Aneesh Kumar K.V @ 2014-04-03 16:19 UTC (permalink / raw)
To: Nishanth Aravamudan, linux-mm; +Cc: linuxppc-dev, paulus, anton, nyc
In-Reply-To: <20140326155815.GB15234@linux.vnet.ibm.com>
Nishanth Aravamudan <nacc@linux.vnet.ibm.com> writes:
> On 24.03.2014 [16:02:56 -0700], Nishanth Aravamudan wrote:
>> In KVM guests on Power, if the guest is not backed by hugepages, we see
>> the following in the guest:
>>
>> AnonHugePages: 0 kB
>> HugePages_Total: 0
>> HugePages_Free: 0
>> HugePages_Rsvd: 0
>> HugePages_Surp: 0
>> Hugepagesize: 64 kB
>>
>> This seems like a configuration issue -- why is a hstate of 64k being
>> registered?
>>
>> I did some debugging and found that the following does trigger,
>> mm/hugetlb.c::hugetlb_init():
>>
>> /* Some platform decide whether they support huge pages at boot
>> * time. On these, such as powerpc, HPAGE_SHIFT is set to 0 when
>> * there is no such support
>> */
>> if (HPAGE_SHIFT == 0)
>> return 0;
>>
>> That check is only during init-time. So we don't support hugepages, but
>> none of the hugetlb APIs actually check this condition (HPAGE_SHIFT ==
>> 0), so /proc/meminfo above falsely indicates there is a valid hstate (at
>> least one). But note that there is no /sys/kernel/mm/hugepages meaning
>> no hstate was actually registered.
>>
>> Further, it turns out that huge_page_order(default_hstate) is 0, so
>> hugetlb_report_meminfo is doing:
>>
>> 1UL << (huge_page_order(h) + PAGE_SHIFT - 10)
>>
>> which ends up just doing 1 << (PAGE_SHIFT - 10) and since the base page
>> size is 64k, we report a hugepage size of 64k... And allow the user to
>> allocate hugepages via the sysctl, etc.
>>
>> What's the right thing to do here?
>>
>> 1) Should we add checks for HPAGE_SHIFT == 0 to all the hugetlb APIs? It
>> seems like HPAGE_SHIFT == 0 should be the equivalent, functionally, of
>> the config options being off. This seems like a lot of overhead, though,
>> to put everywhere, so maybe I can do it in an arch-specific macro, that
>> in asm-generic defaults to 0 (and so will hopefully be compiled out?).
>>
>> 2) What should hugetlbfs do when HPAGE_SHIFT == 0? Should it be
>> mountable? Obviously if it's mountable, we can't great files there
>> (since the fs will report insufficient space). [1]
>
> Here is my solution to this. Comments appreciated!
>
> In KVM guests on Power, in a guest not backed by hugepages, we see the
> following:
>
> AnonHugePages: 0 kB
> HugePages_Total: 0
> HugePages_Free: 0
> HugePages_Rsvd: 0
> HugePages_Surp: 0
> Hugepagesize: 64 kB
>
> HPAGE_SHIFT == 0 in this configuration, which indicates that hugepages
> are not supported at boot-time, but this is only checked in
> hugetlb_init(). Extract the check to a helper function, and use it in a
> few relevant places.
>
> This does make hugetlbfs not supported in this environment. I believe
> this is fine, as there are no valid hugepages and that won't change at
> runtime.
>
> Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Looks good. Can you resubmit it as a proper patch ? You may also want to
capture in commit message saying hugetlbfs file system also will not be
registered.
>
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index d19b30a..c7aa477 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -1017,6 +1017,11 @@ static int __init init_hugetlbfs_fs(void)
> int error;
> int i;
>
> + if (!hugepages_supported()) {
> + printk(KERN_ERR "hugetlbfs: Disabling because there are no supported page sizes\n");
> + return -ENOTSUPP;
> + }
> +
> error = bdi_init(&hugetlbfs_backing_dev_info);
> if (error)
> return error;
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 8c43cc4..0aea8de 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -450,4 +450,14 @@ static inline spinlock_t *huge_pte_lock(struct hstate *h,
> return ptl;
> }
>
> +static inline bool hugepages_supported(void)
> +{
> + /*
> + * Some platform decide whether they support huge pages at boot
> + * time. On these, such as powerpc, HPAGE_SHIFT is set to 0 when
> + * there is no such support
> + */
> + return HPAGE_SHIFT != 0;
> +}
> +
> #endif /* _LINUX_HUGETLB_H */
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index c01cb9f..1c99585 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1949,11 +1949,7 @@ module_exit(hugetlb_exit);
>
> static int __init hugetlb_init(void)
> {
> - /* Some platform decide whether they support huge pages at boot
> - * time. On these, such as powerpc, HPAGE_SHIFT is set to 0 when
> - * there is no such support
> - */
> - if (HPAGE_SHIFT == 0)
> + if (!hugepages_supported())
> return 0;
>
> if (!size_to_hstate(default_hstate_size)) {
> @@ -2069,6 +2065,9 @@ static int hugetlb_sysctl_handler_common(bool obey_mempolicy,
> unsigned long tmp;
> int ret;
>
> + if (!hugepages_supported())
> + return -ENOTSUPP;
> +
> tmp = h->max_huge_pages;
>
> if (write && h->order >= MAX_ORDER)
> @@ -2122,6 +2121,9 @@ int hugetlb_overcommit_handler(struct ctl_table *table, int write,
> unsigned long tmp;
> int ret;
>
> + if (!hugepages_supported())
> + return -ENOTSUPP;
> +
> tmp = h->nr_overcommit_huge_pages;
>
> if (write && h->order >= MAX_ORDER)
> @@ -2147,6 +2149,8 @@ out:
> void hugetlb_report_meminfo(struct seq_file *m)
> {
> struct hstate *h = &default_hstate;
> + if (!hugepages_supported())
> + return;
> seq_printf(m,
> "HugePages_Total: %5lu\n"
> "HugePages_Free: %5lu\n"
> @@ -2163,6 +2167,8 @@ void hugetlb_report_meminfo(struct seq_file *m)
> int hugetlb_report_node_meminfo(int nid, char *buf)
> {
> struct hstate *h = &default_hstate;
> + if (!hugepages_supported())
> + return 0;
> return sprintf(buf,
> "Node %d HugePages_Total: %5u\n"
> "Node %d HugePages_Free: %5u\n"
> @@ -2177,6 +2183,9 @@ void hugetlb_show_meminfo(void)
> struct hstate *h;
> int nid;
>
> + if (!hugepages_supported())
> + return;
> +
> for_each_node_state(nid, N_MEMORY)
> for_each_hstate(h)
> pr_info("Node %d hugepages_total=%u hugepages_free=%u hugepages_surp=%u hugepages_size=%lukB\n",
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Bug in reclaim logic with exhausted nodes?
From: Christoph Lameter @ 2014-04-03 16:41 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: linux-mm, mgorman, linuxppc-dev, anton, rientjes
In-Reply-To: <20140401013346.GD5144@linux.vnet.ibm.com>
On Mon, 31 Mar 2014, Nishanth Aravamudan wrote:
> Yep. The node exists, it's just fully exhausted at boot (due to the
> presence of 16GB pages reserved at boot-time).
Well if you want us to support that then I guess you need to propose
patches to address this issue.
> I'd appreciate a bit more guidance? I'm suggesting that in this case the
> node functionally has no memory. So the page allocator should not allow
> allocations from it -- except (I need to investigate this still)
> userspace accessing the 16GB pages on that node, but that, I believe,
> doesn't go through the page allocator at all, it's all from hugetlb
> interfaces. It seems to me there is a bug in SLUB that we are noting
> that we have a useless per-node structure for a given nid, but not
> actually preventing requests to that node or reclaim because of those
> allocations.
Well if you can address that without impacting the fastpath then we could
do this. Otherwise we would need a fake structure here to avoid adding
checks to the fastpath
> I think there is a logical bug (even if it only occurs in this
> particular corner case) where if reclaim progresses for a THISNODE
> allocation, we don't check *where* the reclaim is progressing, and thus
> may falsely be indicating that we have done some progress when in fact
> the allocation that is causing reclaim will not possibly make any more
> progress.
Ok maybe we could address this corner case. How would you do this?
^ permalink raw reply
* [PATCH 00/20] FDT clean-ups and libfdt support
From: Rob Herring @ 2014-04-03 22:16 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, Aurelien Jacquiot, H. Peter Anvin, Max Filippov,
Paul Mackerras, linux, Jonas Bonn, Rob Herring, Russell King,
linux-c6x-dev, x86, Ingo Molnar, Mark Salter, Grant Likely,
linux-xtensa, James Hogan, Thomas Gleixner, linux-metag,
linux-arm-kernel, Chris Zankel, Michal Simek, Vineet Gupta,
Ralf Baechle, linuxppc-dev
From: Rob Herring <robh@kernel.org>
This is a series of clean-ups of architecture FDT code and converts the
core FDT code over to using libfdt functions. This is in preparation
to add FDT based address translation parsing functions for early
console support.
The current MIPS lantiq and xlp DT code is buggy as built-in DTBs need
to be copied out of init section. Patches 2 and 3 should be applied to
3.15.
A branch is available here[1]. Please test! I've compiled on arm,
arm64, mips, microblaze, and powerpc and booted on arm and arm64.
Rob
[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git libfdt
Rob Herring (20):
mips: octeon: convert to use unflatten_and_copy_device_tree
mips: lantiq: copy built-in DTB out of init section
mips: xlp: copy built-in DTB out of init section
mips: ralink: convert to use unflatten_and_copy_device_tree
ARM: dt: use default early_init_dt_alloc_memory_arch
c6x: convert fdt pointers to opaque pointers
mips: convert fdt pointers to opaque pointers
of/fdt: consolidate built-in dtb section variables
of/fdt: create common debugfs
of/fdt: remove some unneeded includes
of/fdt: remove unused of_scan_flat_dt_by_path
of/fdt: update of_get_flat_dt_prop in prep for libfdt
of/fdt: Convert FDT functions to use libfdt
of/fdt: use libfdt accessors for header data
of/fdt: move memreserve and dtb memory reservations into core
build: add libfdt include path globally
powerpc: use libfdt accessors for header data
x86: use libfdt accessors for header data
of/fdt: convert initial_boot_params to opaque pointer
of: push struct boot_param_header and defines into powerpc
Makefile | 5 +
arch/arc/include/asm/sections.h | 1 -
arch/arc/kernel/devtree.c | 2 +-
arch/arm/include/asm/prom.h | 2 -
arch/arm/kernel/devtree.c | 34 +--
arch/arm/mach-exynos/exynos.c | 2 +-
arch/arm/mach-vexpress/platsmp.c | 2 +-
arch/arm/mm/init.c | 1 -
arch/arm/plat-samsung/s5p-dev-mfc.c | 4 +-
arch/arm64/mm/init.c | 21 --
arch/c6x/kernel/setup.c | 4 +-
arch/metag/kernel/setup.c | 4 -
arch/microblaze/kernel/prom.c | 37 +--
arch/mips/cavium-octeon/Makefile | 3 -
arch/mips/cavium-octeon/setup.c | 18 +-
arch/mips/include/asm/mips-boards/generic.h | 4 -
arch/mips/include/asm/prom.h | 6 +-
arch/mips/kernel/prom.c | 2 +-
arch/mips/lantiq/prom.c | 15 +-
arch/mips/lantiq/prom.h | 2 -
arch/mips/mti-sead3/Makefile | 2 -
arch/mips/mti-sead3/sead3-setup.c | 8 +-
arch/mips/netlogic/xlp/dt.c | 17 +-
arch/mips/ralink/of.c | 29 +--
arch/openrisc/kernel/vmlinux.h | 2 -
arch/powerpc/include/asm/prom.h | 39 +++
arch/powerpc/kernel/epapr_paravirt.c | 2 +-
arch/powerpc/kernel/fadump.c | 4 +-
arch/powerpc/kernel/prom.c | 77 ++----
arch/powerpc/kernel/rtas.c | 2 +-
arch/powerpc/mm/hash_utils_64.c | 22 +-
arch/powerpc/platforms/52xx/efika.c | 4 +-
arch/powerpc/platforms/chrp/setup.c | 4 +-
arch/powerpc/platforms/powernv/opal.c | 12 +-
arch/powerpc/platforms/pseries/setup.c | 4 +-
arch/x86/kernel/devicetree.c | 7 +-
arch/xtensa/kernel/setup.c | 3 +-
drivers/of/Kconfig | 1 +
drivers/of/fdt.c | 379 +++++++++-------------------
drivers/of/of_reserved_mem.c | 4 +-
include/linux/of_fdt.h | 64 +----
lib/Makefile | 2 -
42 files changed, 261 insertions(+), 596 deletions(-)
--
1.8.3.2
^ permalink raw reply
* [PATCH 09/20] of/fdt: create common debugfs
From: Rob Herring @ 2014-04-03 22:16 UTC (permalink / raw)
To: linux-kernel
Cc: Rob Herring, Michal Simek, Paul Mackerras, Grant Likely,
linuxppc-dev
In-Reply-To: <1396563423-30893-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <robh@kernel.org>
Both powerpc and microblaze have the same FDT blob in debugfs feature.
Move this to common location and remove the powerpc and microblaze
implementations. This feature could become more useful when FDT
overlay support is added.
This changes the path of the blob from "$arch/flat-device-tree" to
"device-tree/flat-device-tree".
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/microblaze/kernel/prom.c | 31 -------------------------------
arch/powerpc/kernel/prom.c | 21 ---------------------
drivers/of/fdt.c | 24 ++++++++++++++++++++++++
3 files changed, 24 insertions(+), 52 deletions(-)
diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
index abdfb10..1312cd2 100644
--- a/arch/microblaze/kernel/prom.c
+++ b/arch/microblaze/kernel/prom.c
@@ -114,34 +114,3 @@ void __init early_init_devtree(void *params)
pr_debug(" <- early_init_devtree()\n");
}
-
-/*******
- *
- * New implementation of the OF "find" APIs, return a refcounted
- * object, call of_node_put() when done. The device tree and list
- * are protected by a rw_lock.
- *
- * Note that property management will need some locking as well,
- * this isn't dealt with yet.
- *
- *******/
-
-#if defined(CONFIG_DEBUG_FS) && defined(DEBUG)
-static struct debugfs_blob_wrapper flat_dt_blob;
-
-static int __init export_flat_device_tree(void)
-{
- struct dentry *d;
-
- flat_dt_blob.data = initial_boot_params;
- flat_dt_blob.size = initial_boot_params->totalsize;
-
- d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
- of_debugfs_root, &flat_dt_blob);
- if (!d)
- return 1;
-
- return 0;
-}
-device_initcall(export_flat_device_tree);
-#endif
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index dd72beb..7c2f90c 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -29,7 +29,6 @@
#include <linux/bitops.h>
#include <linux/export.h>
#include <linux/kexec.h>
-#include <linux/debugfs.h>
#include <linux/irq.h>
#include <linux/memblock.h>
#include <linux/of.h>
@@ -918,23 +917,3 @@ bool arch_match_cpu_phys_id(int cpu, u64 phys_id)
{
return (int)phys_id == get_hard_smp_processor_id(cpu);
}
-
-#if defined(CONFIG_DEBUG_FS) && defined(DEBUG)
-static struct debugfs_blob_wrapper flat_dt_blob;
-
-static int __init export_flat_device_tree(void)
-{
- struct dentry *d;
-
- flat_dt_blob.data = initial_boot_params;
- flat_dt_blob.size = be32_to_cpu(initial_boot_params->totalsize);
-
- d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
- powerpc_debugfs_root, &flat_dt_blob);
- if (!d)
- return 1;
-
- return 0;
-}
-__initcall(export_flat_device_tree);
-#endif
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index fa16a91..2085d47 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -20,6 +20,7 @@
#include <linux/string.h>
#include <linux/errno.h>
#include <linux/slab.h>
+#include <linux/debugfs.h>
#include <asm/setup.h> /* for COMMAND_LINE_SIZE */
#ifdef CONFIG_PPC
@@ -1084,4 +1085,27 @@ void __init unflatten_and_copy_device_tree(void)
unflatten_device_tree();
}
+#if defined(CONFIG_DEBUG_FS) && defined(DEBUG)
+static struct debugfs_blob_wrapper flat_dt_blob;
+
+static int __init of_flat_dt_debugfs_export_fdt(void)
+{
+ struct dentry *d = debugfs_create_dir("device-tree", NULL);
+
+ if (!d)
+ return -ENOENT;
+
+ flat_dt_blob.data = initial_boot_params;
+ flat_dt_blob.size = fdt_totalsize(initial_boot_params);
+
+ d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
+ d, &flat_dt_blob);
+ if (!d)
+ return -ENOENT;
+
+ return 0;
+}
+module_init(of_flat_dt_debugfs_export_fdt);
+#endif
+
#endif /* CONFIG_OF_EARLY_FLATTREE */
--
1.8.3.2
^ permalink raw reply related
* [PATCH 20/20] of: push struct boot_param_header and defines into powerpc
From: Rob Herring @ 2014-04-03 22:17 UTC (permalink / raw)
To: linux-kernel; +Cc: Grant Likely, Rob Herring, Paul Mackerras, linuxppc-dev
In-Reply-To: <1396563423-30893-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <robh@kernel.org>
Now powerpc is the only user of struct boot_param_header and FDT defines,
so they can be moved into the powerpc architecture code.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/prom.h | 39 +++++++++++++++++++++++++++++++++++++++
include/linux/of_fdt.h | 37 -------------------------------------
2 files changed, 39 insertions(+), 37 deletions(-)
diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
index d977b9b..74b79f0 100644
--- a/arch/powerpc/include/asm/prom.h
+++ b/arch/powerpc/include/asm/prom.h
@@ -26,6 +26,45 @@
#include <linux/of_irq.h>
#include <linux/platform_device.h>
+#define OF_DT_BEGIN_NODE 0x1 /* Start of node, full name */
+#define OF_DT_END_NODE 0x2 /* End node */
+#define OF_DT_PROP 0x3 /* Property: name off, size,
+ * content */
+#define OF_DT_NOP 0x4 /* nop */
+#define OF_DT_END 0x9
+
+#define OF_DT_VERSION 0x10
+
+/*
+ * This is what gets passed to the kernel by prom_init or kexec
+ *
+ * The dt struct contains the device tree structure, full pathes and
+ * property contents. The dt strings contain a separate block with just
+ * the strings for the property names, and is fully page aligned and
+ * self contained in a page, so that it can be kept around by the kernel,
+ * each property name appears only once in this page (cheap compression)
+ *
+ * the mem_rsvmap contains a map of reserved ranges of physical memory,
+ * passing it here instead of in the device-tree itself greatly simplifies
+ * the job of everybody. It's just a list of u64 pairs (base/size) that
+ * ends when size is 0
+ */
+struct boot_param_header {
+ __be32 magic; /* magic word OF_DT_HEADER */
+ __be32 totalsize; /* total size of DT block */
+ __be32 off_dt_struct; /* offset to structure */
+ __be32 off_dt_strings; /* offset to strings */
+ __be32 off_mem_rsvmap; /* offset to memory reserve map */
+ __be32 version; /* format version */
+ __be32 last_comp_version; /* last compatible version */
+ /* version 2 fields below */
+ __be32 boot_cpuid_phys; /* Physical CPU id we're booting on */
+ /* version 3 fields below */
+ __be32 dt_strings_size; /* size of the DT strings block */
+ /* version 17 fields below */
+ __be32 dt_struct_size; /* size of the DT structure block */
+};
+
/*
* OF address retreival & translation
*/
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index aa7fb87..7f67790 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -17,47 +17,10 @@
/* Definitions used by the flattened device tree */
#define OF_DT_HEADER 0xd00dfeed /* marker */
-#define OF_DT_BEGIN_NODE 0x1 /* Start of node, full name */
-#define OF_DT_END_NODE 0x2 /* End node */
-#define OF_DT_PROP 0x3 /* Property: name off, size,
- * content */
-#define OF_DT_NOP 0x4 /* nop */
-#define OF_DT_END 0x9
-
-#define OF_DT_VERSION 0x10
#ifndef __ASSEMBLY__
#include <linux/libfdt.h>
-/*
- * This is what gets passed to the kernel by prom_init or kexec
- *
- * The dt struct contains the device tree structure, full pathes and
- * property contents. The dt strings contain a separate block with just
- * the strings for the property names, and is fully page aligned and
- * self contained in a page, so that it can be kept around by the kernel,
- * each property name appears only once in this page (cheap compression)
- *
- * the mem_rsvmap contains a map of reserved ranges of physical memory,
- * passing it here instead of in the device-tree itself greatly simplifies
- * the job of everybody. It's just a list of u64 pairs (base/size) that
- * ends when size is 0
- */
-struct boot_param_header {
- __be32 magic; /* magic word OF_DT_HEADER */
- __be32 totalsize; /* total size of DT block */
- __be32 off_dt_struct; /* offset to structure */
- __be32 off_dt_strings; /* offset to strings */
- __be32 off_mem_rsvmap; /* offset to memory reserve map */
- __be32 version; /* format version */
- __be32 last_comp_version; /* last compatible version */
- /* version 2 fields below */
- __be32 boot_cpuid_phys; /* Physical CPU id we're booting on */
- /* version 3 fields below */
- __be32 dt_strings_size; /* size of the DT strings block */
- /* version 17 fields below */
- __be32 dt_struct_size; /* size of the DT structure block */
-};
#if defined(CONFIG_OF_FLATTREE)
--
1.8.3.2
^ permalink raw reply related
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