* Re: [PATCH v6 1/5] powerpc/85xx: implement hardware timebase sync
From: Kumar Gala @ 2012-06-28 18:30 UTC (permalink / raw)
To: Zhao Chenhui
Cc: Scott Wood, linuxppc-dev@lists.ozlabs.org list,
linux-kernel@vger.kernel.org list
In-Reply-To: <1340880651.20977.83.camel@pasglop>
On Jun 28, 2012, at 5:50 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2012-06-28 at 11:38 +0800, Zhao Chenhui wrote:
>>=20
>>=20
>> The bootloader have done a timebase sync. If we do not need KEXEC or
>> HOTPLUG_CPU feature, it is unnecessary to do it again at boot time of
>> kernel. I only compile the timebase sync routines
>> when users enable KEXEC or HOTPLUG_CPU.=20
>=20
> Still, how much are you really saving ? Is it worth the added mess and
> loss of test coverage ?
>=20
> We have too many conditional stuff like that already.
>=20
> Cheers,
> Ben.
>=20
I'd also be interested to know how long it actually takes to do time =
base sync this way. Since you are freezing the timers for some period =
how long does it really take between the freeze/unfreeze in =
mpc85xx_give_timebase()
+ mpc85xx_timebase_freeze(1);
...
+ mpc85xx_timebase_freeze(0);
You can use ATBL/U as a way to see # of cycles taken.
- k=
^ permalink raw reply
* Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform
From: Scott Wood @ 2012-06-28 16:31 UTC (permalink / raw)
To: Jia Hongtao-B38951
Cc: Wood Scott-B07421, agraf@suse.de, linuxppc-dev@lists.ozlabs.org,
Li Yang-R58472
In-Reply-To: <412C8208B4A0464FA894C5F0C278CD5D01A10EAB@039-SN1MPN1-002.039d.mgd.msft.net>
On 06/27/2012 11:06 PM, Jia Hongtao-B38951 wrote:
>
>
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Thursday, June 28, 2012 7:49 AM
>> To: galak@kernel.crashing.org
>> Cc: agraf@suse.de; linuxppc-dev@lists.ozlabs.org; Jia Hongtao-B38951
>> Subject: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
>> platform
>>
>> The QEMU stuff is related to the PCI refactoring because currently
>> we have a hard time selecting a primary bus under QEMU, and also because
>> the generic qemu e500 platform wants a full list of FSL PCI compatibles
>> to check.
>>
>
> It seems that not all primary bus has "isa" node like 8541 and 8555.
Do those boards (it's the boards that matter, not chips...) have legacy
ISA? If they do, and it's not in the device tree, then we should fix
the device tree for consistency, but also retain some sort of hack to
remain compatible with old device trees.
A board can refrain from using the new common infrastructure if it has a
good reason to.
> Without PM support for pci controllers I totally agree with this refactoring
> for pci init. But in linux mechanism PM ops should be registered to a driver.
> Do you have any ideas to add PM support for pci controllers under this patchset?
This isn't meant to be instead of making it a platform device. It's
just meant to get us away from board-specific code and primary-bus
hardcoding now, rather than once we sort out all the issues with
platform devices.
-Scott
^ permalink raw reply
* Re: [PATCH v6 1/5] powerpc/85xx: implement hardware timebase sync
From: Benjamin Herrenschmidt @ 2012-06-28 10:50 UTC (permalink / raw)
To: Zhao Chenhui; +Cc: scottwood, linuxppc-dev, linux-kernel
In-Reply-To: <20120628033815.GA11387@localhost.localdomain>
On Thu, 2012-06-28 at 11:38 +0800, Zhao Chenhui wrote:
>
>
> The bootloader have done a timebase sync. If we do not need KEXEC or
> HOTPLUG_CPU feature, it is unnecessary to do it again at boot time of
> kernel. I only compile the timebase sync routines
> when users enable KEXEC or HOTPLUG_CPU.
Still, how much are you really saving ? Is it worth the added mess and
loss of test coverage ?
We have too many conditional stuff like that already.
Cheers,
Ben.
^ permalink raw reply
* Re: Build regressions/improvements in v3.5-rc4
From: Paul Mundt @ 2012-06-28 8:20 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: the arch/x86 maintainers, linuxppc-dev, linux-kernel,
Linux-sh list
In-Reply-To: <CAMuHMdXY1DFNV+jTiJkT99TbX7ZL5eEiKcG0iqZkUa8T7YZG4g@mail.gmail.com>
On Tue, Jun 26, 2012 at 10:06:27PM +0200, Geert Uytterhoeven wrote:
> On Tue, Jun 26, 2012 at 9:59 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > JFYI, when comparing v3.5-rc4 to v3.5-rc3[3], the summaries are:
> > ??- build errors: +11/-219
>
> 11 regressions:
> + arch/sh/include/asm/fixmap.h: error: implicit declaration of
> function 'BUG_ON' [-Werror=implicit-function-declaration]: => 133:2
> + arch/sh/include/asm/thread_info.h: error: implicit declaration of
> function 'WARN_ON' [-Werror=implicit-function-declaration]: => 172:2
> + include/linux/huge_mm.h: error: implicit declaration of function
> 'BUG' [-Werror=implicit-function-declaration]: => 185:2
>
> shmin_defconfig, se7712_defconfig, se7721_defconfig, sh-allnoconfig
>
I'm unable to reproduce any of these, is there some specific compiler
version or warning flag configuration I'm supposed to be using? I'm
building with 4.5.1 at the moment.
^ permalink raw reply
* Re: [RFC PATCH 4/12] memory-hotplug : remove /sys/firmware/memmap/X sysfs
From: Wen Congyang @ 2012-06-28 8:38 UTC (permalink / raw)
To: Yasuaki Ishimatsu
Cc: len.brown, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, kosaki.motohiro, cl, linuxppc-dev, akpm
In-Reply-To: <4FEC10CB.3060403@jp.fujitsu.com>
At 06/28/2012 04:07 PM, Yasuaki Ishimatsu Wrote:
> Hi Wen,
>
> 2012/06/28 15:32, Wen Congyang wrote:
>> At 06/27/2012 01:47 PM, Yasuaki Ishimatsu Wrote:
>>> When (hot)adding memory into system, /sys/firmware/memmap/X/{end,
>>> start, type}
>>> sysfs files are created. But there is no code to remove these files.
>>> The patch
>>> implements the function to remove them.
>>>
>>> Note : The code does not free firmware_map_entry since there is no
>>> way to free
>>> memory which is allocated by bootmem.
>>>
>>> CC: Len Brown <len.brown@intel.com>
>>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>> CC: Paul Mackerras <paulus@samba.org>
>>> CC: Christoph Lameter <cl@linux.com>
>>> Cc: Minchan Kim <minchan.kim@gmail.com>
>>> CC: Andrew Morton <akpm@linux-foundation.org>
>>> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>>> CC: Wen Congyang <wency@cn.fujitsu.com>
>>> Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>>>
>>> ---
>>> drivers/firmware/memmap.c | 71
>>> +++++++++++++++++++++++++++++++++++++++++++
>>> include/linux/firmware-map.h | 6 +++
>>> mm/memory_hotplug.c | 6 +++
>>> 3 files changed, 82 insertions(+), 1 deletion(-)
>>>
>>> Index: linux-3.5-rc4/mm/memory_hotplug.c
>>> ===================================================================
>>> --- linux-3.5-rc4.orig/mm/memory_hotplug.c 2012-06-26
>>> 13:37:30.546288901 +0900
>>> +++ linux-3.5-rc4/mm/memory_hotplug.c 2012-06-26
>>> 13:44:37.069955820 +0900
>>> @@ -661,7 +661,11 @@ EXPORT_SYMBOL_GPL(add_memory);
>>>
>>> int remove_memory(int nid, u64 start, u64 size)
>>> {
>>> - return -EBUSY;
>>> + lock_memory_hotplug();
>>> + /* remove memmap entry */
>>> + firmware_map_remove(start, start + size, "System RAM");
>>> + unlock_memory_hotplug();
>>> + return 0;
>>>
>>> }
>>> EXPORT_SYMBOL_GPL(remove_memory);
>>> Index: linux-3.5-rc4/include/linux/firmware-map.h
>>> ===================================================================
>>> --- linux-3.5-rc4.orig/include/linux/firmware-map.h 2012-06-25
>>> 04:53:04.000000000 +0900
>>> +++ linux-3.5-rc4/include/linux/firmware-map.h 2012-06-26
>>> 13:44:37.070955807 +0900
>>> @@ -25,6 +25,7 @@
>>>
>>> int firmware_map_add_early(u64 start, u64 end, const char *type);
>>> int firmware_map_add_hotplug(u64 start, u64 end, const char *type);
>>> +int firmware_map_remove(u64 start, u64 end, const char *type);
>>>
>>> #else /* CONFIG_FIRMWARE_MEMMAP */
>>>
>>> @@ -38,6 +39,11 @@ static inline int firmware_map_add_hotpl
>>> return 0;
>>> }
>>>
>>> +static inline int firmware_map_remove(u64 start, u64 end, const char
>>> *type)
>>> +{
>>> + return 0;
>>> +}
>>> +
>>> #endif /* CONFIG_FIRMWARE_MEMMAP */
>>>
>>> #endif /* _LINUX_FIRMWARE_MAP_H */
>>> Index: linux-3.5-rc4/drivers/firmware/memmap.c
>>> ===================================================================
>>> --- linux-3.5-rc4.orig/drivers/firmware/memmap.c 2012-06-25
>>> 04:53:04.000000000 +0900
>>> +++ linux-3.5-rc4/drivers/firmware/memmap.c 2012-06-26
>>> 13:47:17.606948898 +0900
>>> @@ -123,6 +123,16 @@ static int firmware_map_add_entry(u64 st
>>> return 0;
>>> }
>>>
>>> +/**
>>> + * firmware_map_remove_entry() - Does the real work to remove a
>>> firmware
>>> + * memmap entry.
>>> + * @entry: removed entry.
>>> + **/
>>> +static inline void firmware_map_remove_entry(struct
>>> firmware_map_entry *entry)
>>> +{
>>> + list_del(&entry->list);
>>> +}
>>> +
>>> /*
>>> * Add memmap entry on sysfs
>>> */
>>> @@ -144,6 +154,31 @@ static int add_sysfs_fw_map_entry(struct
>>> return 0;
>>> }
>>>
>>> +/*
>>> + * Remove memmap entry on sysfs
>>> + */
>>> +static inline void remove_sysfs_fw_map_entry(struct
>>> firmware_map_entry *entry)
>>> +{
>>> + kobject_del(&entry->kobj);
>>> +}
>>> +
>>> +/*
>>> + * Search memmap entry
>>> + */
>>> +
>>> +struct firmware_map_entry * __meminit
>>> +find_firmware_map_entry(u64 start, u64 end, const char *type)
>>> +{
>>> + struct firmware_map_entry *entry;
>>> +
>>> + list_for_each_entry(entry, &map_entries, list)
>>> + if ((entry->start == start) && (entry->end == end) &&
>>> + (!strcmp(entry->type, type)))
>>> + return entry;
>>> +
>>> + return NULL;
>>> +}
>>> +
>>> /**
>>> * firmware_map_add_hotplug() - Adds a firmware mapping entry when
>>> we do
>>> * memory hotplug.
>>> @@ -196,6 +231,42 @@ int __init firmware_map_add_early(u64 st
>>> return firmware_map_add_entry(start, end, type, entry);
>>> }
>>>
>>> +void release_firmware_map_entry(struct firmware_map_entry *entry)
>>> +{
>>> + /*
>>> + * FIXME : There is no idea.
>>> + * How to free the entry which allocated bootmem?
>>> + */
>>> +}
>>> +
>>> +/**
>>> + * firmware_map_remove() - remove a firmware mapping entry
>>> + * @start: Start of the memory range.
>>> + * @end: End of the memory range (inclusive).
>>> + * @type: Type of the memory range.
>>> + *
>>> + * removes a firmware mapping entry.
>>> + *
>>> + * Returns 0 on success, or -EINVAL if no entry.
>>> + **/
>>> +int __meminit firmware_map_remove(u64 start, u64 end, const char *type)
>>> +{
>>> + struct firmware_map_entry *entry;
>>> +
>>> + entry = find_firmware_map_entry(start, end, type);
>>
>> Hmm, we cannot find the entry easily, because the end can be:
>> 1. start + size
>> 2. start + size - 1
>>
>> So, We should fix this bug first.
>
> This is not a bug.
>
> start and size arguments of firmware_map_remove() include
> acpi_memory_info->{start_addr, length}. And when creating a
> firmware_map_entry,
> the entry is created by acpi_memory_info->{start_addr, length}. So I don't
> think that we need care your comment.
If the memory device is hotpluged before the os starts, and the memory
map is included in e820 map, the entry will be created by firmware_map_add_early().
The function firmware_map_add_early() is called by e820_reserve_resources():
=====================
for (i = 0; i < e820_saved.nr_map; i++) {
struct e820entry *entry = &e820_saved.map[i];
firmware_map_add_early(entry->addr,
entry->addr + entry->size - 1,
e820_type_to_string(entry->type));
}
=====================
Note: the end is addr + size - 1, not addr + size.
In such case, you cannot find the entry.
Thanks
Wen Congyang
>
>>
>>> + if (!entry)
>>> + return -EINVAL;
>>> +
>>> + /* remove the memmap entry */
>>> + remove_sysfs_fw_map_entry(entry);
>>> +
>>> + firmware_map_remove_entry(entry);
>>> +
>>> + release_firmware_map_entry(entry);
>>
>> I guess you want to free the memory in the above function. But I think
>> it is
>> not a good idea to free it here. We should free it when the
>> entry->kobj's kref
>> is decreased to 0.
>
> Thanks.
> I'll update your comment at next version.
>
> Thanks,
> Yasuaki Ishimatsu
>
>>
>> Thanks
>> Wen Congyang
>>
>>> +
>>> + return 0;
>>> +}
>>> +
>>> /*
>>> * Sysfs functions
>>> -------------------------------------------------------------
>>> */
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-kernel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>>>
>>
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majordomo@kvack.org. For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>>
>
>
>
>
^ permalink raw reply
* Re: [RFC PATCH 4/12] memory-hotplug : remove /sys/firmware/memmap/X sysfs
From: Yasuaki Ishimatsu @ 2012-06-28 8:07 UTC (permalink / raw)
To: Wen Congyang
Cc: len.brown, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, kosaki.motohiro, cl, linuxppc-dev, akpm
In-Reply-To: <4FEBFA8D.5040607@cn.fujitsu.com>
Hi Wen,
2012/06/28 15:32, Wen Congyang wrote:
> At 06/27/2012 01:47 PM, Yasuaki Ishimatsu Wrote:
>> When (hot)adding memory into system, /sys/firmware/memmap/X/{end, start, type}
>> sysfs files are created. But there is no code to remove these files. The patch
>> implements the function to remove them.
>>
>> Note : The code does not free firmware_map_entry since there is no way to free
>> memory which is allocated by bootmem.
>>
>> CC: Len Brown <len.brown@intel.com>
>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> CC: Paul Mackerras <paulus@samba.org>
>> CC: Christoph Lameter <cl@linux.com>
>> Cc: Minchan Kim <minchan.kim@gmail.com>
>> CC: Andrew Morton <akpm@linux-foundation.org>
>> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>> CC: Wen Congyang <wency@cn.fujitsu.com>
>> Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>>
>> ---
>> drivers/firmware/memmap.c | 71 +++++++++++++++++++++++++++++++++++++++++++
>> include/linux/firmware-map.h | 6 +++
>> mm/memory_hotplug.c | 6 +++
>> 3 files changed, 82 insertions(+), 1 deletion(-)
>>
>> Index: linux-3.5-rc4/mm/memory_hotplug.c
>> ===================================================================
>> --- linux-3.5-rc4.orig/mm/memory_hotplug.c 2012-06-26 13:37:30.546288901 +0900
>> +++ linux-3.5-rc4/mm/memory_hotplug.c 2012-06-26 13:44:37.069955820 +0900
>> @@ -661,7 +661,11 @@ EXPORT_SYMBOL_GPL(add_memory);
>>
>> int remove_memory(int nid, u64 start, u64 size)
>> {
>> - return -EBUSY;
>> + lock_memory_hotplug();
>> + /* remove memmap entry */
>> + firmware_map_remove(start, start + size, "System RAM");
>> + unlock_memory_hotplug();
>> + return 0;
>>
>> }
>> EXPORT_SYMBOL_GPL(remove_memory);
>> Index: linux-3.5-rc4/include/linux/firmware-map.h
>> ===================================================================
>> --- linux-3.5-rc4.orig/include/linux/firmware-map.h 2012-06-25 04:53:04.000000000 +0900
>> +++ linux-3.5-rc4/include/linux/firmware-map.h 2012-06-26 13:44:37.070955807 +0900
>> @@ -25,6 +25,7 @@
>>
>> int firmware_map_add_early(u64 start, u64 end, const char *type);
>> int firmware_map_add_hotplug(u64 start, u64 end, const char *type);
>> +int firmware_map_remove(u64 start, u64 end, const char *type);
>>
>> #else /* CONFIG_FIRMWARE_MEMMAP */
>>
>> @@ -38,6 +39,11 @@ static inline int firmware_map_add_hotpl
>> return 0;
>> }
>>
>> +static inline int firmware_map_remove(u64 start, u64 end, const char *type)
>> +{
>> + return 0;
>> +}
>> +
>> #endif /* CONFIG_FIRMWARE_MEMMAP */
>>
>> #endif /* _LINUX_FIRMWARE_MAP_H */
>> Index: linux-3.5-rc4/drivers/firmware/memmap.c
>> ===================================================================
>> --- linux-3.5-rc4.orig/drivers/firmware/memmap.c 2012-06-25 04:53:04.000000000 +0900
>> +++ linux-3.5-rc4/drivers/firmware/memmap.c 2012-06-26 13:47:17.606948898 +0900
>> @@ -123,6 +123,16 @@ static int firmware_map_add_entry(u64 st
>> return 0;
>> }
>>
>> +/**
>> + * firmware_map_remove_entry() - Does the real work to remove a firmware
>> + * memmap entry.
>> + * @entry: removed entry.
>> + **/
>> +static inline void firmware_map_remove_entry(struct firmware_map_entry *entry)
>> +{
>> + list_del(&entry->list);
>> +}
>> +
>> /*
>> * Add memmap entry on sysfs
>> */
>> @@ -144,6 +154,31 @@ static int add_sysfs_fw_map_entry(struct
>> return 0;
>> }
>>
>> +/*
>> + * Remove memmap entry on sysfs
>> + */
>> +static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry)
>> +{
>> + kobject_del(&entry->kobj);
>> +}
>> +
>> +/*
>> + * Search memmap entry
>> + */
>> +
>> +struct firmware_map_entry * __meminit
>> +find_firmware_map_entry(u64 start, u64 end, const char *type)
>> +{
>> + struct firmware_map_entry *entry;
>> +
>> + list_for_each_entry(entry, &map_entries, list)
>> + if ((entry->start == start) && (entry->end == end) &&
>> + (!strcmp(entry->type, type)))
>> + return entry;
>> +
>> + return NULL;
>> +}
>> +
>> /**
>> * firmware_map_add_hotplug() - Adds a firmware mapping entry when we do
>> * memory hotplug.
>> @@ -196,6 +231,42 @@ int __init firmware_map_add_early(u64 st
>> return firmware_map_add_entry(start, end, type, entry);
>> }
>>
>> +void release_firmware_map_entry(struct firmware_map_entry *entry)
>> +{
>> + /*
>> + * FIXME : There is no idea.
>> + * How to free the entry which allocated bootmem?
>> + */
>> +}
>> +
>> +/**
>> + * firmware_map_remove() - remove a firmware mapping entry
>> + * @start: Start of the memory range.
>> + * @end: End of the memory range (inclusive).
>> + * @type: Type of the memory range.
>> + *
>> + * removes a firmware mapping entry.
>> + *
>> + * Returns 0 on success, or -EINVAL if no entry.
>> + **/
>> +int __meminit firmware_map_remove(u64 start, u64 end, const char *type)
>> +{
>> + struct firmware_map_entry *entry;
>> +
>> + entry = find_firmware_map_entry(start, end, type);
>
> Hmm, we cannot find the entry easily, because the end can be:
> 1. start + size
> 2. start + size - 1
>
> So, We should fix this bug first.
This is not a bug.
start and size arguments of firmware_map_remove() include
acpi_memory_info->{start_addr, length}. And when creating a firmware_map_entry,
the entry is created by acpi_memory_info->{start_addr, length}. So I don't
think that we need care your comment.
>
>> + if (!entry)
>> + return -EINVAL;
>> +
>> + /* remove the memmap entry */
>> + remove_sysfs_fw_map_entry(entry);
>> +
>> + firmware_map_remove_entry(entry);
>> +
>> + release_firmware_map_entry(entry);
>
> I guess you want to free the memory in the above function. But I think it is
> not a good idea to free it here. We should free it when the entry->kobj's kref
> is decreased to 0.
Thanks.
I'll update your comment at next version.
Thanks,
Yasuaki Ishimatsu
>
> Thanks
> Wen Congyang
>
>> +
>> + return 0;
>> +}
>> +
>> /*
>> * Sysfs functions -------------------------------------------------------------
>> */
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
^ permalink raw reply
* Re: [PATCH] powerpc: check_and_cede_processor never cedes
From: Benjamin Herrenschmidt @ 2012-06-28 7:10 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev, paulus
In-Reply-To: <20120628091352.48d3859d@kryten>
On Thu, 2012-06-28 at 09:13 +1000, Anton Blanchard wrote:
> Hi,
>
> > I'd rather add a helper, something like lazy_irq_pending()
> > and hide the actual check for the bits in irq_happened, in
> > case we change the scheme again.
>
> Good idea. Look ok?
>
> --
>
> Commit f948501b36c6 ("Make hard_irq_disable() actually hard-disable
> interrupts") caused check_and_cede_processor to stop working.
> ->irq_happened will never be zero right after a hard_irq_disable
> so the compiler removes the call to cede_processor completely.
>
> The bug was introduced back in the lazy interrupt handling rework
> of 3.4 but was hidden until recently because hard_irq_disable did
> nothing.
>
> This issue will eventually appear in 3.4 stable since the
> hard_irq_disable fix is marked stable, so mark this one for stable
> too.
Yup, looks good, I'll send to Linus tomorrow.
Cheers,
Ben.
> Signed-off-by: Anton Blanchard <anton@samba.org>
> Cc: stable@vger.kernel.org
> ---
>
> v2: create a helper, suggested by Ben.
>
> Index: linux-build/arch/powerpc/platforms/pseries/processor_idle.c
> ===================================================================
> --- linux-build.orig/arch/powerpc/platforms/pseries/processor_idle.c 2012-06-28 08:55:09.422198154 +1000
> +++ linux-build/arch/powerpc/platforms/pseries/processor_idle.c 2012-06-28 08:57:36.112591023 +1000
> @@ -106,7 +106,7 @@ static void check_and_cede_processor(voi
> * we first hard disable then check.
> */
> hard_irq_disable();
> - if (get_paca()->irq_happened == 0)
> + if (!lazy_irq_pending())
> cede_processor();
> }
>
> Index: linux-build/arch/powerpc/include/asm/hw_irq.h
> ===================================================================
> --- linux-build.orig/arch/powerpc/include/asm/hw_irq.h 2012-06-21 09:16:26.265354429 +1000
> +++ linux-build/arch/powerpc/include/asm/hw_irq.h 2012-06-28 08:59:22.082320381 +1000
> @@ -103,6 +103,11 @@ static inline void hard_irq_disable(void
> /* include/linux/interrupt.h needs hard_irq_disable to be a macro */
> #define hard_irq_disable hard_irq_disable
>
> +static inline bool lazy_irq_pending(void)
> +{
> + return !!(get_paca()->irq_happened & ~PACA_IRQ_HARD_DIS);
> +}
> +
> /*
> * This is called by asynchronous interrupts to conditionally
> * re-enable hard interrupts when soft-disabled after having
^ permalink raw reply
* Re: [PATCH V4 1/2] PCI: pcibus address to resource converting take bus directly
From: Benjamin Herrenschmidt @ 2012-06-28 7:03 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci, yinghai, Gavin Shan, linuxppc-dev
In-Reply-To: <CAErSpo4u6HKdVqaaiL5=GSWRXiVfyfJ7EsnkAwGz6KvKrqaM=w@mail.gmail.com>
On Wed, 2012-06-27 at 12:15 -0600, Bjorn Helgaas wrote:
>
> This patch appears to have multiple unrelated changes:
>
> - change "struct pci_bus *bus" to "struct pci_bus *root_bus"
> - change find_pci_host_bridge() argument from dev to bus
> - fiddle with pcibios_bus_to_resource() and
> pcibios_resource_to_bus()
>
> These should be split out to make your patches easier to review.
>
> What's the rationale for preferring the pci_bus over the pci_dev?
We really want to stop doing that crap and put a pointer to the host
bridge directly in each pci_dev (and maybe pci_bus).
We already do that on powerpc via sysdata (pointing to our private
structure but the plan is to move that toward struct pci_host_bridge
eventually).
We'll need host bridge access to deal with resource "offsets" in a few
more places and having to do a lookup is just a pain.
For example, see my earlier email about the issues with the way we
calculate the minimum address to assign devices. This is currently
broken when we have an offset and to fix it we'll probably want to deal
with offsets all the way down in the resource allocation code.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH 2/12] memory-hogplug : check memory offline in offline_pages
From: Yasuaki Ishimatsu @ 2012-06-28 7:01 UTC (permalink / raw)
To: David Rientjes
Cc: len.brown, wency, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, kosaki.motohiro, cl, linuxppc-dev, akpm
In-Reply-To: <alpine.DEB.2.00.1206262313440.32567@chino.kir.corp.google.com>
Hi David,
2012/06/27 15:16, David Rientjes wrote:
> On Wed, 27 Jun 2012, Yasuaki Ishimatsu wrote:
>
>> Index: linux-3.5-rc4/mm/memory_hotplug.c
>> ===================================================================
>> --- linux-3.5-rc4.orig/mm/memory_hotplug.c 2012-06-26 13:28:16.743211538 +0900
>> +++ linux-3.5-rc4/mm/memory_hotplug.c 2012-06-26 13:48:38.264940468 +0900
>> @@ -887,6 +887,11 @@ static int __ref offline_pages(unsigned
>>
>> lock_memory_hotplug();
>>
>> + if (memory_is_offline(start_pfn, end_pfn)) {
>> + ret = 0;
>> + goto out;
>> + }
>> +
>> zone = page_zone(pfn_to_page(start_pfn));
>> node = zone_to_nid(zone);
>> nr_pages = end_pfn - start_pfn;
>
> Are there additional prerequisites for this patch? Otherwise it changes
> the return value of offline_memory() which will now call
> acpi_memory_powerdown_device() in the acpi memhotplug case when disabling.
> Is that a problem?
I have understood there is a person who expects "offline_pages()" to fail
in this case by kosaki's comment. So I'll move memory_is_offline to caller
side.
Thanks,
Yasuaki Ishimatsu
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
^ permalink raw reply
* Re: [RFC PATCH 2/12] memory-hogplug : check memory offline in offline_pages
From: Yasuaki Ishimatsu @ 2012-06-28 6:51 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: len.brown, wency, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, cl, linuxppc-dev, akpm
In-Reply-To: <CAHGf_=qtt6_EWucC4B8R_jr71UTc9=QTJcDXz8Oo13C_nyu-mQ@mail.gmail.com>
Hi Kosaki-san,
2012/06/28 14:26, KOSAKI Motohiro wrote:
> On Wed, Jun 27, 2012 at 1:44 AM, Yasuaki Ishimatsu
> <isimatu.yasuaki@jp.fujitsu.com> wrote:
>> When offline_pages() is called to offlined memory, the function fails since
>> all memory has been offlined. In this case, the function should succeed.
>> The patch adds the check function into offline_pages().
>
> I don't understand your point. I think following misoperation should
> fail. Otherwise
> administrator have no way to know their fault.
>
> $ echo offline > memoryN/state
> $ echo offline > memoryN/state
>
> In general, we don't like to ignore an error except the standard require it.
I understood the intention of previous mail (why the caller can't check it? ).
I'll move memory_is_offline() to caller side.
>>
>> CC: Len Brown <len.brown@intel.com>
>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> CC: Paul Mackerras <paulus@samba.org>
>> CC: Christoph Lameter <cl@linux.com>
>> Cc: Minchan Kim <minchan.kim@gmail.com>
>> CC: Andrew Morton <akpm@linux-foundation.org>
>> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>> CC: Wen Congyang <wency@cn.fujitsu.com>
>> Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>>
>> ---
>> drivers/base/memory.c | 20 ++++++++++++++++++++
>> include/linux/memory.h | 1 +
>> mm/memory_hotplug.c | 5 +++++
>> 3 files changed, 26 insertions(+)
>>
>> Index: linux-3.5-rc4/drivers/base/memory.c
>> ===================================================================
>> --- linux-3.5-rc4.orig/drivers/base/memory.c 2012-06-26 13:28:16.726211752 +0900
>> +++ linux-3.5-rc4/drivers/base/memory.c 2012-06-26 13:34:22.423639904 +0900
>> @@ -70,6 +70,26 @@ void unregister_memory_isolate_notifier(
>> }
>> EXPORT_SYMBOL(unregister_memory_isolate_notifier);
>>
>> +bool memory_is_offline(unsigned long start_pfn, unsigned long end_pfn)
>
> I dislike this function name. 'memory' is too vague to me.
O.K.
I retry to change the name of the function.
>
>
>> +{
>> + struct memory_block *mem;
>> + struct mem_section *section;
>> + unsigned long pfn, section_nr;
>> +
>> + for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
>> + section_nr = pfn_to_section_nr(pfn);
>> + section = __nr_to_section(section_nr);
>> + mem = find_memory_block(section);
>
> This seems to have strong sparse dependency.
Thanks.
I will consider other CONFIG_.
Thanks.
Yasuaki Ishimatsu
> Hm, I wonder why memory-hotplug.c can enable when X86_64_ACPI_NUMA.
>
> # eventually, we can have this option just 'select SPARSEMEM'
> config MEMORY_HOTPLUG
> bool "Allow for memory hot-add"
> depends on SPARSEMEM || X86_64_ACPI_NUMA
>
>
>> + if (!mem)
>> + continue;
>> + if (mem->state == MEM_OFFLINE)
>> + continue;
>> + return false;
>> + }
>> +
>> + return true;
>> +}
>> +
>> /*
>> * register_memory - Setup a sysfs device for a memory block
>> */
>> Index: linux-3.5-rc4/include/linux/memory.h
>> ===================================================================
>> --- linux-3.5-rc4.orig/include/linux/memory.h 2012-06-25 04:53:04.000000000 +0900
>> +++ linux-3.5-rc4/include/linux/memory.h 2012-06-26 13:34:22.424639891 +0900
>> @@ -120,6 +120,7 @@ extern int memory_isolate_notify(unsigne
>> extern struct memory_block *find_memory_block_hinted(struct mem_section *,
>> struct memory_block *);
>> extern struct memory_block *find_memory_block(struct mem_section *);
>> +extern bool memory_is_offline(unsigned long start_pfn, unsigned long end_pfn);
>> #define CONFIG_MEM_BLOCK_SIZE (PAGES_PER_SECTION<<PAGE_SHIFT)
>> enum mem_add_context { BOOT, HOTPLUG };
>> #endif /* CONFIG_MEMORY_HOTPLUG_SPARSE */
>> Index: linux-3.5-rc4/mm/memory_hotplug.c
>> ===================================================================
>> --- linux-3.5-rc4.orig/mm/memory_hotplug.c 2012-06-26 13:28:16.743211538 +0900
>> +++ linux-3.5-rc4/mm/memory_hotplug.c 2012-06-26 13:48:38.264940468 +0900
>> @@ -887,6 +887,11 @@ static int __ref offline_pages(unsigned
>>
>> lock_memory_hotplug();
>>
>> + if (memory_is_offline(start_pfn, end_pfn)) {
>> + ret = 0;
>> + goto out;
>> + }
>> +
>> zone = page_zone(pfn_to_page(start_pfn));
>> node = zone_to_nid(zone);
>> nr_pages = end_pfn - start_pfn;
>>
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majordomo@kvack.org. For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC PATCH 4/12] memory-hotplug : remove /sys/firmware/memmap/X sysfs
From: Wen Congyang @ 2012-06-28 6:32 UTC (permalink / raw)
To: Yasuaki Ishimatsu
Cc: len.brown, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, kosaki.motohiro, cl, linuxppc-dev, akpm
In-Reply-To: <4FEA9E5F.4070205@jp.fujitsu.com>
At 06/27/2012 01:47 PM, Yasuaki Ishimatsu Wrote:
> When (hot)adding memory into system, /sys/firmware/memmap/X/{end, start, type}
> sysfs files are created. But there is no code to remove these files. The patch
> implements the function to remove them.
>
> Note : The code does not free firmware_map_entry since there is no way to free
> memory which is allocated by bootmem.
>
> CC: Len Brown <len.brown@intel.com>
> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Paul Mackerras <paulus@samba.org>
> CC: Christoph Lameter <cl@linux.com>
> Cc: Minchan Kim <minchan.kim@gmail.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> CC: Wen Congyang <wency@cn.fujitsu.com>
> Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>
> ---
> drivers/firmware/memmap.c | 71 +++++++++++++++++++++++++++++++++++++++++++
> include/linux/firmware-map.h | 6 +++
> mm/memory_hotplug.c | 6 +++
> 3 files changed, 82 insertions(+), 1 deletion(-)
>
> Index: linux-3.5-rc4/mm/memory_hotplug.c
> ===================================================================
> --- linux-3.5-rc4.orig/mm/memory_hotplug.c 2012-06-26 13:37:30.546288901 +0900
> +++ linux-3.5-rc4/mm/memory_hotplug.c 2012-06-26 13:44:37.069955820 +0900
> @@ -661,7 +661,11 @@ EXPORT_SYMBOL_GPL(add_memory);
>
> int remove_memory(int nid, u64 start, u64 size)
> {
> - return -EBUSY;
> + lock_memory_hotplug();
> + /* remove memmap entry */
> + firmware_map_remove(start, start + size, "System RAM");
> + unlock_memory_hotplug();
> + return 0;
>
> }
> EXPORT_SYMBOL_GPL(remove_memory);
> Index: linux-3.5-rc4/include/linux/firmware-map.h
> ===================================================================
> --- linux-3.5-rc4.orig/include/linux/firmware-map.h 2012-06-25 04:53:04.000000000 +0900
> +++ linux-3.5-rc4/include/linux/firmware-map.h 2012-06-26 13:44:37.070955807 +0900
> @@ -25,6 +25,7 @@
>
> int firmware_map_add_early(u64 start, u64 end, const char *type);
> int firmware_map_add_hotplug(u64 start, u64 end, const char *type);
> +int firmware_map_remove(u64 start, u64 end, const char *type);
>
> #else /* CONFIG_FIRMWARE_MEMMAP */
>
> @@ -38,6 +39,11 @@ static inline int firmware_map_add_hotpl
> return 0;
> }
>
> +static inline int firmware_map_remove(u64 start, u64 end, const char *type)
> +{
> + return 0;
> +}
> +
> #endif /* CONFIG_FIRMWARE_MEMMAP */
>
> #endif /* _LINUX_FIRMWARE_MAP_H */
> Index: linux-3.5-rc4/drivers/firmware/memmap.c
> ===================================================================
> --- linux-3.5-rc4.orig/drivers/firmware/memmap.c 2012-06-25 04:53:04.000000000 +0900
> +++ linux-3.5-rc4/drivers/firmware/memmap.c 2012-06-26 13:47:17.606948898 +0900
> @@ -123,6 +123,16 @@ static int firmware_map_add_entry(u64 st
> return 0;
> }
>
> +/**
> + * firmware_map_remove_entry() - Does the real work to remove a firmware
> + * memmap entry.
> + * @entry: removed entry.
> + **/
> +static inline void firmware_map_remove_entry(struct firmware_map_entry *entry)
> +{
> + list_del(&entry->list);
> +}
> +
> /*
> * Add memmap entry on sysfs
> */
> @@ -144,6 +154,31 @@ static int add_sysfs_fw_map_entry(struct
> return 0;
> }
>
> +/*
> + * Remove memmap entry on sysfs
> + */
> +static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry)
> +{
> + kobject_del(&entry->kobj);
> +}
> +
> +/*
> + * Search memmap entry
> + */
> +
> +struct firmware_map_entry * __meminit
> +find_firmware_map_entry(u64 start, u64 end, const char *type)
> +{
> + struct firmware_map_entry *entry;
> +
> + list_for_each_entry(entry, &map_entries, list)
> + if ((entry->start == start) && (entry->end == end) &&
> + (!strcmp(entry->type, type)))
> + return entry;
> +
> + return NULL;
> +}
> +
> /**
> * firmware_map_add_hotplug() - Adds a firmware mapping entry when we do
> * memory hotplug.
> @@ -196,6 +231,42 @@ int __init firmware_map_add_early(u64 st
> return firmware_map_add_entry(start, end, type, entry);
> }
>
> +void release_firmware_map_entry(struct firmware_map_entry *entry)
> +{
> + /*
> + * FIXME : There is no idea.
> + * How to free the entry which allocated bootmem?
> + */
> +}
> +
> +/**
> + * firmware_map_remove() - remove a firmware mapping entry
> + * @start: Start of the memory range.
> + * @end: End of the memory range (inclusive).
> + * @type: Type of the memory range.
> + *
> + * removes a firmware mapping entry.
> + *
> + * Returns 0 on success, or -EINVAL if no entry.
> + **/
> +int __meminit firmware_map_remove(u64 start, u64 end, const char *type)
> +{
> + struct firmware_map_entry *entry;
> +
> + entry = find_firmware_map_entry(start, end, type);
Hmm, we cannot find the entry easily, because the end can be:
1. start + size
2. start + size - 1
So, We should fix this bug first.
> + if (!entry)
> + return -EINVAL;
> +
> + /* remove the memmap entry */
> + remove_sysfs_fw_map_entry(entry);
> +
> + firmware_map_remove_entry(entry);
> +
> + release_firmware_map_entry(entry);
I guess you want to free the memory in the above function. But I think it is
not a good idea to free it here. We should free it when the entry->kobj's kref
is decreased to 0.
Thanks
Wen Congyang
> +
> + return 0;
> +}
> +
> /*
> * Sysfs functions -------------------------------------------------------------
> */
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [RFC PATCH 2/12] memory-hogplug : check memory offline in offline_pages
From: Yasuaki Ishimatsu @ 2012-06-28 6:01 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: len.brown, Wen Congyang, linux-acpi, linux-kernel, linux-mm,
paulus, minchan.kim, cl, linuxppc-dev, akpm
In-Reply-To: <CAHGf_=rzRthh+hpKWAVF9OyL+P_NhFw4y+W-tF3j0zB8pr0QjA@mail.gmail.com>
Hi Kosaki-san,
2012/06/28 14:27, KOSAKI Motohiro wrote:
> On Thu, Jun 28, 2012 at 1:06 AM, Yasuaki Ishimatsu
> <isimatu.yasuaki@jp.fujitsu.com> wrote:
>> Hi Wen,
>>
>> 2012/06/27 17:49, Wen Congyang wrote:
>>> At 06/27/2012 01:44 PM, Yasuaki Ishimatsu Wrote:
>>>> When offline_pages() is called to offlined memory, the function fails since
>>>> all memory has been offlined. In this case, the function should succeed.
>>>> The patch adds the check function into offline_pages().
>>>
>>> You miss such case: some pages are online, while some pages are offline.
>>> offline_pages() will fail too in such case.
>>
>> You are right. But current code fails, when the function is called to offline
>> memory. In this case, the function should succeed. So the patch confirms
>> whether the memory was offlined or not. And if memory has already been
>> offlined, offline_pages return 0.
>
> Can you please explain why the caller can't check it? I hope to avoid
> an ignorance
> as far as we can.
Of course, caller side can check it. But there is a possibility that
offline_pages() is called by many functions. So I do not think that it
is good that all functions which call offline_pages() check it.
Thanks,
Yasuaki Ishimatsu
^ permalink raw reply
* Re: [RFC PATCH 2/12] memory-hogplug : check memory offline in offline_pages
From: KOSAKI Motohiro @ 2012-06-28 5:27 UTC (permalink / raw)
To: Yasuaki Ishimatsu
Cc: len.brown, Wen Congyang, linux-acpi, linux-kernel, linux-mm,
paulus, minchan.kim, cl, linuxppc-dev, akpm
In-Reply-To: <4FEBE646.5090801@jp.fujitsu.com>
On Thu, Jun 28, 2012 at 1:06 AM, Yasuaki Ishimatsu
<isimatu.yasuaki@jp.fujitsu.com> wrote:
> Hi Wen,
>
> 2012/06/27 17:49, Wen Congyang wrote:
>> At 06/27/2012 01:44 PM, Yasuaki Ishimatsu Wrote:
>>> When offline_pages() is called to offlined memory, the function fails since
>>> all memory has been offlined. In this case, the function should succeed.
>>> The patch adds the check function into offline_pages().
>>
>> You miss such case: some pages are online, while some pages are offline.
>> offline_pages() will fail too in such case.
>
> You are right. But current code fails, when the function is called to offline
> memory. In this case, the function should succeed. So the patch confirms
> whether the memory was offlined or not. And if memory has already been
> offlined, offline_pages return 0.
Can you please explain why the caller can't check it? I hope to avoid
an ignorance
as far as we can.
^ permalink raw reply
* Re: [RFC PATCH 2/12] memory-hogplug : check memory offline in offline_pages
From: KOSAKI Motohiro @ 2012-06-28 5:26 UTC (permalink / raw)
To: Yasuaki Ishimatsu
Cc: len.brown, wency, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, cl, linuxppc-dev, akpm
In-Reply-To: <4FEA9DB1.7010303@jp.fujitsu.com>
On Wed, Jun 27, 2012 at 1:44 AM, Yasuaki Ishimatsu
<isimatu.yasuaki@jp.fujitsu.com> wrote:
> When offline_pages() is called to offlined memory, the function fails sin=
ce
> all memory has been offlined. In this case, the function should succeed.
> The patch adds the check function into offline_pages().
I don't understand your point. I think following misoperation should
fail. Otherwise
administrator have no way to know their fault.
$ echo offline > memoryN/state
$ echo offline > memoryN/state
In general, we don't like to ignore an error except the standard require it=
.
>
> CC: Len Brown <len.brown@intel.com>
> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Paul Mackerras <paulus@samba.org>
> CC: Christoph Lameter <cl@linux.com>
> Cc: Minchan Kim <minchan.kim@gmail.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> CC: Wen Congyang <wency@cn.fujitsu.com>
> Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>
> ---
> =A0drivers/base/memory.c =A0| =A0 20 ++++++++++++++++++++
> =A0include/linux/memory.h | =A0 =A01 +
> =A0mm/memory_hotplug.c =A0 =A0| =A0 =A05 +++++
> =A03 files changed, 26 insertions(+)
>
> Index: linux-3.5-rc4/drivers/base/memory.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- linux-3.5-rc4.orig/drivers/base/memory.c =A0 =A02012-06-26 13:28:16.7=
26211752 +0900
> +++ linux-3.5-rc4/drivers/base/memory.c 2012-06-26 13:34:22.423639904 +09=
00
> @@ -70,6 +70,26 @@ void unregister_memory_isolate_notifier(
> =A0}
> =A0EXPORT_SYMBOL(unregister_memory_isolate_notifier);
>
> +bool memory_is_offline(unsigned long start_pfn, unsigned long end_pfn)
I dislike this function name. 'memory' is too vague to me.
> +{
> + =A0 =A0 =A0 struct memory_block *mem;
> + =A0 =A0 =A0 struct mem_section *section;
> + =A0 =A0 =A0 unsigned long pfn, section_nr;
> +
> + =A0 =A0 =A0 for (pfn =3D start_pfn; pfn < end_pfn; pfn +=3D PAGES_PER_S=
ECTION) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 section_nr =3D pfn_to_section_nr(pfn);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 section =3D __nr_to_section(section_nr);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mem =3D find_memory_block(section);
This seems to have strong sparse dependency.
Hm, I wonder why memory-hotplug.c can enable when X86_64_ACPI_NUMA.
# eventually, we can have this option just 'select SPARSEMEM'
config MEMORY_HOTPLUG
bool "Allow for memory hot-add"
depends on SPARSEMEM || X86_64_ACPI_NUMA
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!mem)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (mem->state =3D=3D MEM_OFFLINE)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return false;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 return true;
> +}
> +
> =A0/*
> =A0* register_memory - Setup a sysfs device for a memory block
> =A0*/
> Index: linux-3.5-rc4/include/linux/memory.h
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- linux-3.5-rc4.orig/include/linux/memory.h =A0 2012-06-25 04:53:04.000=
000000 +0900
> +++ linux-3.5-rc4/include/linux/memory.h =A0 =A0 =A0 =A02012-06-26 13:34:=
22.424639891 +0900
> @@ -120,6 +120,7 @@ extern int memory_isolate_notify(unsigne
> =A0extern struct memory_block *find_memory_block_hinted(struct mem_sectio=
n *,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct memory_block *);
> =A0extern struct memory_block *find_memory_block(struct mem_section *);
> +extern bool memory_is_offline(unsigned long start_pfn, unsigned long end=
_pfn);
> =A0#define CONFIG_MEM_BLOCK_SIZE =A0(PAGES_PER_SECTION<<PAGE_SHIFT)
> =A0enum mem_add_context { BOOT, HOTPLUG };
> =A0#endif /* CONFIG_MEMORY_HOTPLUG_SPARSE */
> Index: linux-3.5-rc4/mm/memory_hotplug.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- linux-3.5-rc4.orig/mm/memory_hotplug.c =A0 =A0 =A02012-06-26 13:28:16=
.743211538 +0900
> +++ linux-3.5-rc4/mm/memory_hotplug.c =A0 2012-06-26 13:48:38.264940468 +=
0900
> @@ -887,6 +887,11 @@ static int __ref offline_pages(unsigned
>
> =A0 =A0 =A0 =A0lock_memory_hotplug();
>
> + =A0 =A0 =A0 if (memory_is_offline(start_pfn, end_pfn)) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret =3D 0;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> + =A0 =A0 =A0 }
> +
> =A0 =A0 =A0 =A0zone =3D page_zone(pfn_to_page(start_pfn));
> =A0 =A0 =A0 =A0node =3D zone_to_nid(zone);
> =A0 =A0 =A0 =A0nr_pages =3D end_pfn - start_pfn;
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. =A0For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=3Dmailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC PATCH 2/12] memory-hogplug : check memory offline in offline_pages
From: Yasuaki Ishimatsu @ 2012-06-28 5:06 UTC (permalink / raw)
To: Wen Congyang
Cc: len.brown, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, kosaki.motohiro, cl, linuxppc-dev, akpm
In-Reply-To: <4FEAC916.7030506@cn.fujitsu.com>
Hi Wen,
2012/06/27 17:49, Wen Congyang wrote:
> At 06/27/2012 01:44 PM, Yasuaki Ishimatsu Wrote:
>> When offline_pages() is called to offlined memory, the function fails since
>> all memory has been offlined. In this case, the function should succeed.
>> The patch adds the check function into offline_pages().
>
> You miss such case: some pages are online, while some pages are offline.
> offline_pages() will fail too in such case.
You are right. But current code fails, when the function is called to offline
memory. In this case, the function should succeed. So the patch confirms
whether the memory was offlined or not. And if memory has already been
offlined, offline_pages return 0.
Thanks,
Yasuaki Ishimatsu
>
> Thanks
> Wen Congyang
>
>>
>> CC: Len Brown <len.brown@intel.com>
>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> CC: Paul Mackerras <paulus@samba.org>
>> CC: Christoph Lameter <cl@linux.com>
>> Cc: Minchan Kim <minchan.kim@gmail.com>
>> CC: Andrew Morton <akpm@linux-foundation.org>
>> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>> CC: Wen Congyang <wency@cn.fujitsu.com>
>> Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>>
>> ---
>> drivers/base/memory.c | 20 ++++++++++++++++++++
>> include/linux/memory.h | 1 +
>> mm/memory_hotplug.c | 5 +++++
>> 3 files changed, 26 insertions(+)
>>
>> Index: linux-3.5-rc4/drivers/base/memory.c
>> ===================================================================
>> --- linux-3.5-rc4.orig/drivers/base/memory.c 2012-06-26 13:28:16.726211752 +0900
>> +++ linux-3.5-rc4/drivers/base/memory.c 2012-06-26 13:34:22.423639904 +0900
>> @@ -70,6 +70,26 @@ void unregister_memory_isolate_notifier(
>> }
>> EXPORT_SYMBOL(unregister_memory_isolate_notifier);
>>
>> +bool memory_is_offline(unsigned long start_pfn, unsigned long end_pfn)
>> +{
>> + struct memory_block *mem;
>> + struct mem_section *section;
>> + unsigned long pfn, section_nr;
>> +
>> + for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
>> + section_nr = pfn_to_section_nr(pfn);
>> + section = __nr_to_section(section_nr);
>> + mem = find_memory_block(section);
>> + if (!mem)
>> + continue;
>> + if (mem->state == MEM_OFFLINE)
>> + continue;
>> + return false;
>> + }
>> +
>> + return true;
>> +}
>> +
>> /*
>> * register_memory - Setup a sysfs device for a memory block
>> */
>> Index: linux-3.5-rc4/include/linux/memory.h
>> ===================================================================
>> --- linux-3.5-rc4.orig/include/linux/memory.h 2012-06-25 04:53:04.000000000 +0900
>> +++ linux-3.5-rc4/include/linux/memory.h 2012-06-26 13:34:22.424639891 +0900
>> @@ -120,6 +120,7 @@ extern int memory_isolate_notify(unsigne
>> extern struct memory_block *find_memory_block_hinted(struct mem_section *,
>> struct memory_block *);
>> extern struct memory_block *find_memory_block(struct mem_section *);
>> +extern bool memory_is_offline(unsigned long start_pfn, unsigned long end_pfn);
>> #define CONFIG_MEM_BLOCK_SIZE (PAGES_PER_SECTION<<PAGE_SHIFT)
>> enum mem_add_context { BOOT, HOTPLUG };
>> #endif /* CONFIG_MEMORY_HOTPLUG_SPARSE */
>> Index: linux-3.5-rc4/mm/memory_hotplug.c
>> ===================================================================
>> --- linux-3.5-rc4.orig/mm/memory_hotplug.c 2012-06-26 13:28:16.743211538 +0900
>> +++ linux-3.5-rc4/mm/memory_hotplug.c 2012-06-26 13:48:38.264940468 +0900
>> @@ -887,6 +887,11 @@ static int __ref offline_pages(unsigned
>>
>> lock_memory_hotplug();
>>
>> + if (memory_is_offline(start_pfn, end_pfn)) {
>> + ret = 0;
>> + goto out;
>> + }
>> +
>> zone = page_zone(pfn_to_page(start_pfn));
>> node = zone_to_nid(zone);
>> nr_pages = end_pfn - start_pfn;
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [RFC PATCH 1/12] memory-hotplug : rename remove_memory to offline_memory
From: Yasuaki Ishimatsu @ 2012-06-28 4:50 UTC (permalink / raw)
To: Wen Congyang
Cc: len.brown, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, kosaki.motohiro, rientjes, cl, linuxppc-dev, akpm
In-Reply-To: <4FEBCE9C.7030904@cn.fujitsu.com>
Hi Wen,
2012/06/28 12:25, Wen Congyang wrote:
> At 06/28/2012 11:01 AM, Yasuaki Ishimatsu Wrote:
>> Hi David and Wen,
>>
>> Thank you for reviewing my patch.
>>
>> 2012/06/27 17:47, Wen Congyang wrote:
>>> At 06/27/2012 03:14 PM, Wen Congyang Wrote:
>>>> At 06/27/2012 01:42 PM, Yasuaki Ishimatsu Wrote:
>>>>> remove_memory() does not remove memory but just offlines memory. The patch
>>>>> changes name of it to offline_memory().
>>>>
>>>> There are 3 functions in the kernel:
>>>> 1. add_memory()
>>>> 2. online_pages()
>>>> 3. remove_memory()
>>>>
>>>> So I think offline_pages() is better than offline_memory().
>>>
>>> There is already a function named offline_pages(). So we
>>> should call offline_pages() instead of remove_memory() in
>>> memory_block_action(), and there is no need to rename
>>> remove_memory().
>>
>> As Wen says, Linux has 4 functions for memory hotplug already.
>> In my recognition, these functions are prepared for following purpose.
>>
>> 1. add_memory : add physical memory
>> 2. online_pages : online logical memory
>> 3. remove_memory : offline logical memory
>> 4. offline_pages : offline logical memory
>>
>> add_memory() is used for adding physical memory. I think remove_memory()
>> would rather be used for removing physical memory than be used for removing
>> logical memory. So I renamed remove_memory() to offline_memory().
>> How do you think?
>
> Hmm, remove_memory() will revert all things we do in add_memory(), so I think
I think so too.
add_memory() prepares to use physical memory. It prepares some structures
(pgdat, page table, node, etc) for using the physical memory at the system.
But it does not online the meomory. For onlining the memory, we use
online_pages().
So I think that remove_memory() should remove these structures which are
prepared by add_memory() not offline memory. But current remove_memory() code
only calls offline_pages() and offlines memory.
The patch series recreates remove_memory() for removing these structures
after [RFC PATCH 3/12]. The reason to change the name of remove_memory() is a
preparation to recreate it.
Thanks,
Yasuaki Ishimatsu
> there is no need to rename it. If we rename it to offline_memory(), we should
> also rename add_memory() to online_memory().
>
> Thanks
> Wen Congyang
>
>>
>> Regards,
>> Yasuaki Ishimatsu
>>
>>>
>>> Thanks
>>> Wen Congyang
>>>
>>>>
>>>> Thanks
>>>> Wen Congyang
>>>>>
^ permalink raw reply
* RE: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform
From: Jia Hongtao-B38951 @ 2012-06-28 4:06 UTC (permalink / raw)
To: Wood Scott-B07421, galak@kernel.crashing.org, Li Yang-R58472
Cc: linuxppc-dev@lists.ozlabs.org, agraf@suse.de
In-Reply-To: <20120627234851.GA9071@tyr.buserror.net>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Thursday, June 28, 2012 7:49 AM
> To: galak@kernel.crashing.org
> Cc: agraf@suse.de; linuxppc-dev@lists.ozlabs.org; Jia Hongtao-B38951
> Subject: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
> platform
>=20
> The QEMU stuff is related to the PCI refactoring because currently
> we have a hard time selecting a primary bus under QEMU, and also because
> the generic qemu e500 platform wants a full list of FSL PCI compatibles
> to check.
>=20
It seems that not all primary bus has "isa" node like 8541 and 8555.
Without PM support for pci controllers I totally agree with this refactorin=
g
for pci init. But in linux mechanism PM ops should be registered to a drive=
r.
Do you have any ideas to add PM support for pci controllers under this patc=
hset?
Thanks.
-Jia Hongtao.
^ permalink raw reply
* Re: [PATCH V4 1/2] PCI: pcibus address to resource converting take bus directly
From: Gavin Shan @ 2012-06-28 3:59 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci, yinghai, Gavin Shan, linuxppc-dev
In-Reply-To: <CAErSpo4u6HKdVqaaiL5=GSWRXiVfyfJ7EsnkAwGz6KvKrqaM=w@mail.gmail.com>
>> For allocating resource under bus path, we do have dev pass along,
>> and we could just use bus instead. Also, we'd like to make function
>> find_pci_host_bridge() global so that some platforms (e.g. PPC) can
>> access the pci host bridge directly.
>
>This patch appears to have multiple unrelated changes:
>
> - change "struct pci_bus *bus" to "struct pci_bus *root_bus"
> - change find_pci_host_bridge() argument from dev to bus
> - fiddle with pcibios_bus_to_resource() and pcibios_resource_to_bus()
>
Leave those questions to Yinghai.
>These should be split out to make your patches easier to review.
>
I will split it for easy review :-)
>What's the rationale for preferring the pci_bus over the pci_dev?
>
We probablly need retrieve the pci_host_bridge through pci_bus
and pci_dev. When converting pci_dev to pci_host_bridge, we can
simply pass "pci_dev->bus".
Thanks,
Gavin
>> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>> ---
>> drivers/pci/host-bridge.c | 34 +++++++++++++++++++++-------------
>> include/linux/pci.h | 4 ++++
>> 2 files changed, 25 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
>> index a68dc61..4ccf477 100644
>> --- a/drivers/pci/host-bridge.c
>> +++ b/drivers/pci/host-bridge.c
>> @@ -9,22 +9,19 @@
>>
>> #include "pci.h"
>>
>> -static struct pci_bus *find_pci_root_bus(struct pci_dev *dev)
>> +static struct pci_bus *find_pci_root_bus(struct pci_bus *bus)
>> {
>> - struct pci_bus *bus;
>> -
>> - bus = dev->bus;
>> while (bus->parent)
>> bus = bus->parent;
>>
>> return bus;
>> }
>>
>> -static struct pci_host_bridge *find_pci_host_bridge(struct pci_dev *dev)
>> +struct pci_host_bridge *find_pci_host_bridge(struct pci_bus *bus)
>> {
>> - struct pci_bus *bus = find_pci_root_bus(dev);
>> + struct pci_bus *root_bus = find_pci_root_bus(bus);
>>
>> - return to_pci_host_bridge(bus->bridge);
>> + return to_pci_host_bridge(root_bus->bridge);
>> }
>>
>> void pci_set_host_bridge_release(struct pci_host_bridge *bridge,
>> @@ -40,10 +37,11 @@ static bool resource_contains(struct resource *res1, struct resource *res2)
>> return res1->start <= res2->start && res1->end >= res2->end;
>> }
>>
>> -void pcibios_resource_to_bus(struct pci_dev *dev, struct pci_bus_region *region,
>> - struct resource *res)
>> +void __pcibios_resource_to_bus(struct pci_bus *bus,
>> + struct pci_bus_region *region,
>> + struct resource *res)
>> {
>> - struct pci_host_bridge *bridge = find_pci_host_bridge(dev);
>> + struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
>> struct pci_host_bridge_window *window;
>> resource_size_t offset = 0;
>>
>> @@ -60,6 +58,11 @@ void pcibios_resource_to_bus(struct pci_dev *dev, struct pci_bus_region *region,
>> region->start = res->start - offset;
>> region->end = res->end - offset;
>> }
>> +void pcibios_resource_to_bus(struct pci_dev *dev, struct pci_bus_region *region,
>> + struct resource *res)
>> +{
>> + __pcibios_resource_to_bus(dev->bus, region, res);
>> +}
>> EXPORT_SYMBOL(pcibios_resource_to_bus);
>>
>> static bool region_contains(struct pci_bus_region *region1,
>> @@ -68,10 +71,10 @@ static bool region_contains(struct pci_bus_region *region1,
>> return region1->start <= region2->start && region1->end >= region2->end;
>> }
>>
>> -void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
>> - struct pci_bus_region *region)
>> +static void __pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
>> + struct pci_bus_region *region)
>> {
>> - struct pci_host_bridge *bridge = find_pci_host_bridge(dev);
>> + struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
>> struct pci_host_bridge_window *window;
>> resource_size_t offset = 0;
>>
>> @@ -93,4 +96,9 @@ void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
>> res->start = region->start + offset;
>> res->end = region->end + offset;
>> }
>> +void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
>> + struct pci_bus_region *region)
>> +{
>> + __pcibios_bus_to_resource(dev->bus, res, region);
>> +}
>> EXPORT_SYMBOL(pcibios_bus_to_resource);
>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>> index fefb4e1..2b559f1 100644
>> --- a/include/linux/pci.h
>> +++ b/include/linux/pci.h
>> @@ -385,6 +385,7 @@ struct pci_host_bridge {
>> };
>>
>> #define to_pci_host_bridge(n) container_of(n, struct pci_host_bridge, dev)
>> +struct pci_host_bridge *find_pci_host_bridge(struct pci_bus *bus);
>> void pci_set_host_bridge_release(struct pci_host_bridge *bridge,
>> void (*release_fn)(struct pci_host_bridge *),
>> void *release_data);
>> @@ -657,6 +658,9 @@ void pci_fixup_cardbus(struct pci_bus *);
>>
>> /* Generic PCI functions used internally */
>>
>> +void __pcibios_resource_to_bus(struct pci_bus *bus,
>> + struct pci_bus_region *region,
>> + struct resource *res);
>> void pcibios_resource_to_bus(struct pci_dev *dev, struct pci_bus_region *region,
>> struct resource *res);
>> void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
>> --
>> 1.7.9.5
>>
>
^ permalink raw reply
* Re: [PATCH V4 2/2] PCI: minimal alignment for bars of P2P bridges
From: Ram Pai @ 2012-06-28 3:53 UTC (permalink / raw)
To: Gavin Shan; +Cc: bhelgaas, linux-pci, yinghai, linuxppc-dev
In-Reply-To: <1340808525-24996-2-git-send-email-shangw@linux.vnet.ibm.com>
On Wed, Jun 27, 2012 at 10:48:45PM +0800, Gavin Shan wrote:
> On some powerpc platforms, device BARs need to be assigned to separate
> "segments" of the address space in order for the error isolation and HW
> virtualization mechanisms (EEH) to work properly. Those "segments" have
> a minimum size that can be fairly large (16M). In order to be able to
> use the generic resource assignment code rather than re-inventing our
> own, we chose to group devices by bus. That way, a simple change of the
> minimum alignment requirements of resources assigned to PCI to PCI (P2P)
> bridges is enough to ensure that all BARs for devices below those bridges
> will fit into contiguous sets of segments and there will be no overlap.
>
> This patch provides a way for the host bridge to override the default
> alignment values used by the resource allocation code for that purpose.
>
> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
> Reviewed-by: Ram Pai <linuxram@us.ibm.com>
> Reviewed-by: Richard Yang <weiyang@linux.vnet.ibm.com>
> ---
> drivers/pci/probe.c | 5 +++++
> drivers/pci/setup-bus.c | 28 +++++++++++++++++++++-------
> include/linux/pci.h | 8 ++++++++
> 3 files changed, 34 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 658ac97..a196529 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -431,6 +431,11 @@ static struct pci_host_bridge *pci_alloc_host_bridge(struct pci_bus *b)
> if (bridge) {
> INIT_LIST_HEAD(&bridge->windows);
> bridge->bus = b;
> +
> + /* Set minimal alignment shift of P2P bridges */
> + bridge->io_align_shift = PCI_DEFAULT_IO_ALIGN_SHIFT;
> + bridge->mem_align_shift = PCI_DEFAULT_MEM_ALIGN_SHIFT;
> + bridge->pmem_align_shift = PCI_DEFAULT_PMEM_ALIGN_SHIFT;
> }
>
> return bridge;
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 8fa2d4b..caebe98 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -706,10 +706,12 @@ static resource_size_t calculate_memsize(resource_size_t size,
> static void pbus_size_io(struct pci_bus *bus, resource_size_t min_size,
> resource_size_t add_size, struct list_head *realloc_head)
> {
> + struct pci_host_bridge *phb;
> struct pci_dev *dev;
> struct resource *b_res = find_free_bus_resource(bus, IORESOURCE_IO);
> unsigned long size = 0, size0 = 0, size1 = 0;
> resource_size_t children_add_size = 0;
> + resource_size_t io_align;
>
> if (!b_res)
> return;
> @@ -735,13 +737,17 @@ static void pbus_size_io(struct pci_bus *bus, resource_size_t min_size,
> children_add_size += get_res_add_size(realloc_head, r);
> }
> }
> +
> + phb = find_pci_host_bridge(bus);
> + io_align = (1 << phb->io_align_shift);
I prefer to see something like
io_align = pci_align_boundary(bus, IORESOURCE_IO);
pbus_size_io() and pbus_size_mem() are already quite complicated.
They need not have to know the host_bridge the bus belongs to, in order
to determine the alignment boundary. I would rather prefer to hide those details
in some function.
> +
> size0 = calculate_iosize(size, min_size, size1,
> - resource_size(b_res), 4096);
> + resource_size(b_res), io_align);
> if (children_add_size > add_size)
> add_size = children_add_size;
> size1 = (!realloc_head || (realloc_head && !add_size)) ? size0 :
> calculate_iosize(size, min_size, add_size + size1,
> - resource_size(b_res), 4096);
> + resource_size(b_res), io_align);
> if (!size0 && !size1) {
> if (b_res->start || b_res->end)
> dev_info(&bus->self->dev, "disabling bridge window "
> @@ -751,11 +757,11 @@ static void pbus_size_io(struct pci_bus *bus, resource_size_t min_size,
> return;
> }
> /* Alignment of the IO window is always 4K */
> - b_res->start = 4096;
> + b_res->start = io_align;
> b_res->end = b_res->start + size0 - 1;
> b_res->flags |= IORESOURCE_STARTALIGN;
> if (size1 > size0 && realloc_head) {
> - add_to_list(realloc_head, bus->self, b_res, size1-size0, 4096);
> + add_to_list(realloc_head, bus->self, b_res, size1-size0, io_align);
> dev_printk(KERN_DEBUG, &bus->self->dev, "bridge window "
> "%pR to [bus %02x-%02x] add_size %lx\n", b_res,
> bus->secondary, bus->subordinate, size1-size0);
> @@ -778,6 +784,7 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask,
> resource_size_t add_size,
> struct list_head *realloc_head)
> {
> + struct pci_host_bridge *phb;
> struct pci_dev *dev;
> resource_size_t min_align, align, size, size0, size1;
> resource_size_t aligns[12]; /* Alignments from 1Mb to 2Gb */
> @@ -785,10 +792,17 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask,
> struct resource *b_res = find_free_bus_resource(bus, type);
> unsigned int mem64_mask = 0;
> resource_size_t children_add_size = 0;
> + int mem_align_shift;
>
> if (!b_res)
> return 0;
>
> + phb = find_pci_host_bridge(bus);
> + if (type & IORESOURCE_PREFETCH)
> + mem_align_shift = phb->pmem_align_shift;
mem_align = pci_align_boundary(bus, IORESOURCE_PREFETCH);
> + else
> + mem_align_shift = phb->mem_align_shift;
mem_align = pci_align_boundary(bus, IORESOURCE_MEM);
mem_align_shift = __ffs(mem_align);
> +
> memset(aligns, 0, sizeof(aligns));
> max_order = 0;
> size = 0;
> @@ -818,8 +832,8 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask,
> #endif
> /* For bridges size != alignment */
> align = pci_resource_alignment(dev, r);
> - order = __ffs(align) - 20;
> - if (order > 11) {
> + order = __ffs(align) - mem_align_shift;
> + if (order > (11 - (mem_align_shift - 20))) {
> dev_warn(&dev->dev, "disabling BAR %d: %pR "
> "(bad alignment %#llx)\n", i, r,
> (unsigned long long) align);
> @@ -846,7 +860,7 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask,
> for (order = 0; order <= max_order; order++) {
> resource_size_t align1 = 1;
>
> - align1 <<= (order + 20);
> + align1 <<= (order + mem_align_shift);
>
> if (!align)
> min_align = align1;
btw, there is good potential for cleanup here. This entire order/alignment
calculation has to go in some other function; in a different patch.
RP
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 2b559f1..879de4e 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -376,9 +376,17 @@ struct pci_host_bridge_window {
> resource_size_t offset; /* bus address + offset = CPU address */
> };
>
> +/* Default shits for P2P I/O and MMIO bar minimal alignment shifts */
> +#define PCI_DEFAULT_IO_ALIGN_SHIFT 12 /* 4KB */
> +#define PCI_DEFAULT_MEM_ALIGN_SHIFT 20 /* 1MB */
> +#define PCI_DEFAULT_PMEM_ALIGN_SHIFT 20 /* 1MB */
> +
> struct pci_host_bridge {
> struct device dev;
> struct pci_bus *bus; /* root bus */
> + int io_align_shift; /* P2P I/O bar minimal alignment shift */
> + int mem_align_shift; /* P2P MMIO bar minimal alignment shift */
> + int pmem_align_shift; /* P2P prefetchable MMIO bar minimal alignment shift */
> struct list_head windows; /* pci_host_bridge_windows */
> void (*release_fn)(struct pci_host_bridge *);
> void *release_data;
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ram Pai
^ permalink raw reply
* Re: [PATCH v6 1/5] powerpc/85xx: implement hardware timebase sync
From: Zhao Chenhui @ 2012-06-28 3:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: scottwood, linuxppc-dev, linux-kernel
In-Reply-To: <1340797732.3732.46.camel@pasglop>
On Wed, Jun 27, 2012 at 09:48:52PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2012-06-27 at 18:21 +0800, Zhao Chenhui wrote:
> > > What's that CONFIG option for ?
> > >
> > > Cheers,
> > > Ben.
> >
> > This option is to guard the timebase sync routines. It is selected
> > when KEXEC or HOTPLUG_CPU is enabled on Freescale Book-E platforms.
>
> Any reason not to just make it unconditional ? That sort of config
> option tend to just confuse things and make bug reports harder to sort
> out.... Also you decrease your test coverage.
>
> Cheers,
> Ben.
The bootloader have done a timebase sync. If we do not need KEXEC or HOTPLUG_CPU feature,
it is unnecessary to do it again at boot time of kernel. I only compile the timebase sync routines
when users enable KEXEC or HOTPLUG_CPU.
-Chenhui
^ permalink raw reply
* Re: [RFC PATCH 1/12] memory-hotplug : rename remove_memory to offline_memory
From: Wen Congyang @ 2012-06-28 3:25 UTC (permalink / raw)
To: Yasuaki Ishimatsu
Cc: len.brown, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, kosaki.motohiro, rientjes, cl, linuxppc-dev, akpm
In-Reply-To: <4FEBC8EE.7040207@jp.fujitsu.com>
At 06/28/2012 11:01 AM, Yasuaki Ishimatsu Wrote:
> Hi David and Wen,
>
> Thank you for reviewing my patch.
>
> 2012/06/27 17:47, Wen Congyang wrote:
>> At 06/27/2012 03:14 PM, Wen Congyang Wrote:
>>> At 06/27/2012 01:42 PM, Yasuaki Ishimatsu Wrote:
>>>> remove_memory() does not remove memory but just offlines memory. The patch
>>>> changes name of it to offline_memory().
>>>
>>> There are 3 functions in the kernel:
>>> 1. add_memory()
>>> 2. online_pages()
>>> 3. remove_memory()
>>>
>>> So I think offline_pages() is better than offline_memory().
>>
>> There is already a function named offline_pages(). So we
>> should call offline_pages() instead of remove_memory() in
>> memory_block_action(), and there is no need to rename
>> remove_memory().
>
> As Wen says, Linux has 4 functions for memory hotplug already.
> In my recognition, these functions are prepared for following purpose.
>
> 1. add_memory : add physical memory
> 2. online_pages : online logical memory
> 3. remove_memory : offline logical memory
> 4. offline_pages : offline logical memory
>
> add_memory() is used for adding physical memory. I think remove_memory()
> would rather be used for removing physical memory than be used for removing
> logical memory. So I renamed remove_memory() to offline_memory().
> How do you think?
Hmm, remove_memory() will revert all things we do in add_memory(), so I think
there is no need to rename it. If we rename it to offline_memory(), we should
also rename add_memory() to online_memory().
Thanks
Wen Congyang
>
> Regards,
> Yasuaki Ishimatsu
>
>>
>> Thanks
>> Wen Congyang
>>
>>>
>>> Thanks
>>> Wen Congyang
>>>>
^ permalink raw reply
* Re: [RFC PATCH 1/12] memory-hotplug : rename remove_memory to offline_memory
From: Yasuaki Ishimatsu @ 2012-06-28 3:01 UTC (permalink / raw)
To: Wen Congyang, rientjes
Cc: len.brown, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, kosaki.motohiro, cl, linuxppc-dev, akpm
In-Reply-To: <4FEAC891.7030808@cn.fujitsu.com>
Hi David and Wen,
Thank you for reviewing my patch.
2012/06/27 17:47, Wen Congyang wrote:
> At 06/27/2012 03:14 PM, Wen Congyang Wrote:
>> At 06/27/2012 01:42 PM, Yasuaki Ishimatsu Wrote:
>>> remove_memory() does not remove memory but just offlines memory. The patch
>>> changes name of it to offline_memory().
>>
>> There are 3 functions in the kernel:
>> 1. add_memory()
>> 2. online_pages()
>> 3. remove_memory()
>>
>> So I think offline_pages() is better than offline_memory().
>
> There is already a function named offline_pages(). So we
> should call offline_pages() instead of remove_memory() in
> memory_block_action(), and there is no need to rename
> remove_memory().
As Wen says, Linux has 4 functions for memory hotplug already.
In my recognition, these functions are prepared for following purpose.
1. add_memory : add physical memory
2. online_pages : online logical memory
3. remove_memory : offline logical memory
4. offline_pages : offline logical memory
add_memory() is used for adding physical memory. I think remove_memory()
would rather be used for removing physical memory than be used for removing
logical memory. So I renamed remove_memory() to offline_memory().
How do you think?
Regards,
Yasuaki Ishimatsu
>
> Thanks
> Wen Congyang
>
>>
>> Thanks
>> Wen Congyang
>>>
>>> CC: Len Brown <len.brown@intel.com>
>>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>> CC: Paul Mackerras <paulus@samba.org>
>>> CC: Christoph Lameter <cl@linux.com>
>>> Cc: Minchan Kim <minchan.kim@gmail.com>
>>> CC: Andrew Morton <akpm@linux-foundation.org>
>>> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>>> CC: Wen Congyang <wency@cn.fujitsu.com>
>>> Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>>>
>>> ---
>>> drivers/acpi/acpi_memhotplug.c | 2 +-
>>> drivers/base/memory.c | 4 ++--
>>> include/linux/memory_hotplug.h | 2 +-
>>> mm/memory_hotplug.c | 6 +++---
>>> 4 files changed, 7 insertions(+), 7 deletions(-)
>>>
>>> Index: linux-3.5-rc4/drivers/acpi/acpi_memhotplug.c
>>> ===================================================================
>>> --- linux-3.5-rc4.orig/drivers/acpi/acpi_memhotplug.c 2012-06-25 04:53:04.000000000 +0900
>>> +++ linux-3.5-rc4/drivers/acpi/acpi_memhotplug.c 2012-06-26 13:48:38.263940481 +0900
>>> @@ -318,7 +318,7 @@ static int acpi_memory_disable_device(st
>>> */
>>> list_for_each_entry_safe(info, n, &mem_device->res_list, list) {
>>> if (info->enabled) {
>>> - result = remove_memory(info->start_addr, info->length);
>>> + result = offline_memory(info->start_addr, info->length);
>>> if (result)
>>> return result;
>>> }
>>> Index: linux-3.5-rc4/drivers/base/memory.c
>>> ===================================================================
>>> --- linux-3.5-rc4.orig/drivers/base/memory.c 2012-06-25 04:53:04.000000000 +0900
>>> +++ linux-3.5-rc4/drivers/base/memory.c 2012-06-26 13:48:46.072842803 +0900
>>> @@ -266,8 +266,8 @@ memory_block_action(unsigned long phys_i
>>> break;
>>> case MEM_OFFLINE:
>>> start_paddr = page_to_pfn(first_page) << PAGE_SHIFT;
>>> - ret = remove_memory(start_paddr,
>>> - nr_pages << PAGE_SHIFT);
>>> + ret = offline_memory(start_paddr,
>>> + nr_pages << PAGE_SHIFT);
>>> break;
>>> default:
>>> WARN(1, KERN_WARNING "%s(%ld, %ld) unknown action: "
>>> Index: linux-3.5-rc4/mm/memory_hotplug.c
>>> ===================================================================
>>> --- linux-3.5-rc4.orig/mm/memory_hotplug.c 2012-06-25 04:53:04.000000000 +0900
>>> +++ linux-3.5-rc4/mm/memory_hotplug.c 2012-06-26 13:48:46.072842803 +0900
>>> @@ -990,7 +990,7 @@ out:
>>> return ret;
>>> }
>>>
>>> -int remove_memory(u64 start, u64 size)
>>> +int offline_memory(u64 start, u64 size)
>>> {
>>> unsigned long start_pfn, end_pfn;
>>>
>>> @@ -999,9 +999,9 @@ int remove_memory(u64 start, u64 size)
>>> return offline_pages(start_pfn, end_pfn, 120 * HZ);
>>> }
>>> #else
>>> -int remove_memory(u64 start, u64 size)
>>> +int offline_memory(u64 start, u64 size)
>>> {
>>> return -EINVAL;
>>> }
>>> #endif /* CONFIG_MEMORY_HOTREMOVE */
>>> -EXPORT_SYMBOL_GPL(remove_memory);
>>> +EXPORT_SYMBOL_GPL(offline_memory);
>>> Index: linux-3.5-rc4/include/linux/memory_hotplug.h
>>> ===================================================================
>>> --- linux-3.5-rc4.orig/include/linux/memory_hotplug.h 2012-06-25 04:53:04.000000000 +0900
>>> +++ linux-3.5-rc4/include/linux/memory_hotplug.h 2012-06-26 13:48:38.264940468 +0900
>>> @@ -233,7 +233,7 @@ static inline int is_mem_section_removab
>>> extern int mem_online_node(int nid);
>>> extern int add_memory(int nid, u64 start, u64 size);
>>> extern int arch_add_memory(int nid, u64 start, u64 size);
>>> -extern int remove_memory(u64 start, u64 size);
>>> +extern int offline_memory(u64 start, u64 size);
>>> extern int sparse_add_one_section(struct zone *zone, unsigned long start_pfn,
>>> int nr_pages);
>>> extern void sparse_remove_one_section(struct zone *zone, struct mem_section *ms);
>>>
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
^ permalink raw reply
* Re: [PATCH 03/21] ppc/eeh: more logs for EEH initialization
From: Gavin Shan @ 2012-06-28 2:40 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <1340840734.23635.8.camel@concordia>
>On Thu, 2012-06-28 at 00:01 +0800, Gavin Shan wrote:
>> The patch adds more logs to EEH initialization functions for
>> debugging purpose. Also, the machine type ("pSeries") is checked
>> in the platform initialization to assure it's the correct platform
>> to invoke it.
>
>Hi Gavin,
>
>Our boot logs are full enough. pr_info() is not right for this sort of
>stuff.
>
>For debug use:
> * pr_debug() - which can be enabled dynamically.
> * pr_devel() - which needs to be built with #define DEBUG
> * printk(KERN_DEBUG) - for things you always want printed, but
> needn't go to the console by default.
>
Yes, Michael. I'll replace "pr_info" with "pr_debug" in next revision :-)
>> diff --git a/arch/powerpc/platforms/pseries/eeh_dev.c b/arch/powerpc/platforms/pseries/eeh_dev.c
>> index 8e3443b..a0cee3a 100644
>> --- a/arch/powerpc/platforms/pseries/eeh_dev.c
>> +++ b/arch/powerpc/platforms/pseries/eeh_dev.c
>> @@ -100,6 +100,8 @@ static int __init eeh_dev_phb_init(void)
>> list_for_each_entry_safe(phb, tmp, &hose_list, list_node)
>> eeh_dev_phb_init_dynamic(phb);
>>
>> + pr_info("EEH: devices created\n");
>
>That's not actually very informative.
>
Yep. Let me make it more informative in next revision.
>> diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c b/arch/powerpc/platforms/pseries/eeh_pseries.c
>> index bcf0bb8..bb2bd90 100644
>> --- a/arch/powerpc/platforms/pseries/eeh_pseries.c
>> +++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
>> @@ -561,7 +561,18 @@ static struct eeh_ops pseries_eeh_ops = {
>> */
>> static int __init eeh_pseries_init(void)
>> {
>> - return eeh_ops_register(&pseries_eeh_ops);
>> + int ret = -EINVAL;
>> +
>> + if (!machine_is(pseries))
>> + return ret;
>> +
>> + ret = eeh_ops_register(&pseries_eeh_ops);
>> + if (!ret)
>> + pr_info("EEH: pSeries platform initialized\n");
>> + else
>> + pr_info("EEH: pSeries platform initialization failure\n");
>> +
>> + return ret;
>> }
>>
>> early_initcall(eeh_pseries_init);
>
>You can achieve the same with initcall_debug.
>
>But if you want to keep it at least print the return code, that's the
>first thing you will want to know if it fails.
>
Thanks, Michael. Let me print "ret" for the failure case in next revision.
Also, I will replace "pr_info" with "pr_debug" as you suggested :-)
Thanks,
Gavin
>cheers
>
>
>
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@lists.ozlabs.org
>https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* [PATCH 3/3] powerpc/mpc85xx_ds: convert to unified PCI init
From: Scott Wood @ 2012-06-27 23:50 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, agraf, Jia Hongtao
In-Reply-To: <20120627234851.GA9071@tyr.buserror.net>
Similar to how the primary PCI bridge is identified by looking
for an isa subnode, we determine whether to apply uli exclusions
by looking for a uli subnode.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
Besides being an example of a real-hardware board to use the new PCI init
(probably one of the more complicated examples due to the uli device
exclusion), this fixes PCI under QEMU's mpc8544ds machine. QEMU was
only creating one PCI bus, and it wasn't the one Linux had arbitrarily
deemed primary for mpc8544ds (AFAIK, there's no legacy ISA on this
board).
Tested with QEMU mpc8544ds, and real-hardware mpc8572ds (with uli).
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 97 +++++++++---------------------
1 files changed, 29 insertions(+), 68 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 1fd91e9..6d3265f 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -114,71 +114,53 @@ void __init mpc85xx_ds_pic_init(void)
}
#ifdef CONFIG_PCI
-static int primary_phb_addr;
extern int uli_exclude_device(struct pci_controller *hose,
u_char bus, u_char devfn);
+static struct device_node *pci_with_uli;
+
static int mpc85xx_exclude_device(struct pci_controller *hose,
u_char bus, u_char devfn)
{
- struct device_node* node;
- struct resource rsrc;
-
- node = hose->dn;
- of_address_to_resource(node, 0, &rsrc);
-
- if ((rsrc.start & 0xfffff) == primary_phb_addr) {
+ if (hose->dn == pci_with_uli)
return uli_exclude_device(hose, bus, devfn);
- }
return PCIBIOS_SUCCESSFUL;
}
#endif /* CONFIG_PCI */
-/*
- * Setup the architecture
- */
-static void __init mpc85xx_ds_setup_arch(void)
+static void __init mpc85xx_ds_pci_init(void)
{
#ifdef CONFIG_PCI
- struct device_node *np;
- struct pci_controller *hose;
-#endif
- dma_addr_t max = 0xffffffff;
+ struct device_node *node;
- if (ppc_md.progress)
- ppc_md.progress("mpc85xx_ds_setup_arch()", 0);
+ fsl_pci_init();
-#ifdef CONFIG_PCI
- for_each_node_by_type(np, "pci") {
- if (of_device_is_compatible(np, "fsl,mpc8540-pci") ||
- of_device_is_compatible(np, "fsl,mpc8548-pcie") ||
- of_device_is_compatible(np, "fsl,p2020-pcie")) {
- struct resource rsrc;
- of_address_to_resource(np, 0, &rsrc);
- if ((rsrc.start & 0xfffff) == primary_phb_addr)
- fsl_add_bridge(np, 1);
- else
- fsl_add_bridge(np, 0);
-
- hose = pci_find_hose_for_OF_device(np);
- max = min(max, hose->dma_window_base_cur +
- hose->dma_window_size);
+ /* See if we have a ULI under the primary */
+
+ node = of_find_node_by_name(NULL, "uli1575");
+ while ((pci_with_uli = of_get_parent(node))) {
+ of_node_put(node);
+ node = pci_with_uli;
+
+ if (pci_with_uli == fsl_pci_primary) {
+ ppc_md.pci_exclude_device = mpc85xx_exclude_device;
+ break;
}
}
-
- ppc_md.pci_exclude_device = mpc85xx_exclude_device;
#endif
+}
- mpc85xx_smp_init();
+/*
+ * Setup the architecture
+ */
+static void __init mpc85xx_ds_setup_arch(void)
+{
+ if (ppc_md.progress)
+ ppc_md.progress("mpc85xx_ds_setup_arch()", 0);
-#ifdef CONFIG_SWIOTLB
- if (memblock_end_of_DRAM() > max) {
- ppc_swiotlb_enable = 1;
- set_pci_dma_ops(&swiotlb_dma_ops);
- ppc_md.pci_dma_dev_setup = pci_dma_dev_setup_swiotlb;
- }
-#endif
+ mpc85xx_ds_pci_init();
+ mpc85xx_smp_init();
printk("MPC85xx DS board from Freescale Semiconductor\n");
}
@@ -190,14 +172,7 @@ static int __init mpc8544_ds_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if (of_flat_dt_is_compatible(root, "MPC8544DS")) {
-#ifdef CONFIG_PCI
- primary_phb_addr = 0xb000;
-#endif
- return 1;
- }
-
- return 0;
+ return !!of_flat_dt_is_compatible(root, "MPC8544DS");
}
machine_device_initcall(mpc8544_ds, mpc85xx_common_publish_devices);
@@ -215,14 +190,7 @@ static int __init mpc8572_ds_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if (of_flat_dt_is_compatible(root, "fsl,MPC8572DS")) {
-#ifdef CONFIG_PCI
- primary_phb_addr = 0x8000;
-#endif
- return 1;
- }
-
- return 0;
+ return !!of_flat_dt_is_compatible(root, "fsl,MPC8572DS");
}
/*
@@ -232,14 +200,7 @@ static int __init p2020_ds_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if (of_flat_dt_is_compatible(root, "fsl,P2020DS")) {
-#ifdef CONFIG_PCI
- primary_phb_addr = 0x9000;
-#endif
- return 1;
- }
-
- return 0;
+ return !!of_flat_dt_is_compatible(root, "fsl,P2020DS");
}
define_machine(mpc8544_ds) {
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/3] powerpc/e500: add paravirt QEMU platform
From: Scott Wood @ 2012-06-27 23:50 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, agraf, Jia Hongtao
In-Reply-To: <20120627234851.GA9071@tyr.buserror.net>
This gives the kernel a paravirtualized machine to target, without
requiring both sides to pretend to be targeting a specific board
that likely has little to do with the host in KVM scenarios. This
avoids the need to add new boards to QEMU just to be able to
run KVM on new CPUs.
As this is the first platform that can run with either e500v2 or
e500mc, CONFIG_PPC_E500MC is now a legitimately user configurable
option, so add a help text.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/platforms/85xx/Kconfig | 16 +++++++
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/qemu_e500.c | 66 +++++++++++++++++++++++++++++++
arch/powerpc/platforms/Kconfig.cputype | 4 ++
4 files changed, 87 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/85xx/qemu_e500.c
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index f000d81..7bbebe5 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -263,6 +263,22 @@ config P5020_DS
help
This option enables support for the P5020 DS board
+config PPC_QEMU_E500
+ bool "QEMU generic e500 platform"
+ depends on EXPERIMENTAL
+ select DEFAULT_UIMAGE
+ help
+ This option enables support for running as a QEMU guest using
+ QEMU's generic e500 machine. This is not required if you're
+ using a QEMU machine that targets a specific board, such as
+ mpc8544ds.
+
+ Unlike most e500 boards that target a specific CPU, this
+ platform works with any e500-family CPU that QEMU supports.
+ Thus, you'll need to make sure CONFIG_PPC_E500MC is set or
+ unset based on the emulated CPU (or actual host CPU in the case
+ of KVM).
+
endif # FSL_SOC_BOOKE
config TQM85xx
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index 2125d4c..f841ac8 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_SOCRATES) += socrates.o socrates_fpga_pic.o
obj-$(CONFIG_KSI8560) += ksi8560.o
obj-$(CONFIG_XES_MPC85xx) += xes_mpc85xx.o
obj-$(CONFIG_GE_IMP3A) += ge_imp3a.o
+obj-$(CONFIG_PPC_QEMU_E500) += qemu_e500.o
diff --git a/arch/powerpc/platforms/85xx/qemu_e500.c b/arch/powerpc/platforms/85xx/qemu_e500.c
new file mode 100644
index 0000000..77c8d5d
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/qemu_e500.c
@@ -0,0 +1,66 @@
+/*
+ * Paravirt target for a generic QEMU e500 machine
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/of_fdt.h>
+#include <asm/machdep.h>
+#include <asm/time.h>
+#include <asm/udbg.h>
+#include <asm/mpic.h>
+#include <sysdev/fsl_soc.h>
+#include <sysdev/fsl_pci.h>
+#include "smp.h"
+#include "mpc85xx.h"
+
+void __init qemu_e500_pic_init(void)
+{
+ struct mpic *mpic;
+
+ mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU,
+ 0, 256, " OpenPIC ");
+
+ BUG_ON(mpic == NULL);
+ mpic_init(mpic);
+}
+
+static void __init qemu_e500_setup_arch(void)
+{
+ ppc_md.progress("qemu_e500_setup_arch()", 0);
+
+ fsl_pci_init();
+ mpc85xx_smp_init();
+}
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init qemu_e500_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return !!of_flat_dt_is_compatible(root, "fsl,qemu-e500");
+}
+
+machine_device_initcall(qemu_e500, mpc85xx_common_publish_devices);
+
+define_machine(qemu_e500) {
+ .name = "QEMU e500",
+ .probe = qemu_e500_probe,
+ .setup_arch = qemu_e500_setup_arch,
+ .init_IRQ = qemu_e500_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+ .get_irq = mpic_get_irq,
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 61c9550..30fd01d 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -159,6 +159,10 @@ config PPC_E500MC
bool "e500mc Support"
select PPC_FPU
depends on E500
+ help
+ This must be enabled for running on e500mc (and derivatives
+ such as e5500/e6500), and must be disabled for running on
+ e500v1 or e500v2.
config PPC_FPU
bool
--
1.7.5.4
^ 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