* SD Card over SPI, not working for MPC8313
From: R.Patil @ 2013-01-16 13:30 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]
Hello,
We are working on board based on Freescale MPC8313ERDB. We have ported linux 3.0.46 kernel on it. We have to use SD card over SPI. We are trying to use 'mmc_spi' driver for the same. We are able to detect SD card insertion by the interrupt (gpio interrupt is used to detect card insertion). But we are not able to initialise the card. Is the 'mmc_spi' support for MPC8313ERDB broken?
If no, what could be the reason we are getting timeout error by function 'mmc_spi_response_get()'?
If anybody could just give a hint to solve or debug the problem.
Thanks and Regards,
Rahul Patil
Email Disclaimer:
---------------------------
This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. Computer viruses can be transmitted via email.The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
[-- Attachment #2: Type: text/html, Size: 1246 bytes --]
^ permalink raw reply
* Re: [PATCH 6/6][v3] perf: Document the ABI of perf sysfs entries
From: Jiri Olsa @ 2013-01-16 11:30 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Andi Kleen, Peter Zijlstra, robert.richter, Greg KH,
Anton Blanchard, linux-kernel, Stephane Eranian, linuxppc-dev,
Ingo Molnar, Paul Mackerras, Sukadev Bhattiprolu
In-Reply-To: <20130115185759.GG5826@ghostprotocols.net>
On Tue, Jan 15, 2013 at 03:57:59PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Jan 09, 2013 at 05:07:03PM -0800, Sukadev Bhattiprolu escreveu:
> > [PATCH 6/6][v3] perf: Document the ABI of perf sysfs entries
> >
> > This patchset addes two new sets of files to sysfs:
> >
> > - generic and POWER-specific perf events in /sys/devices/cpu/events/
> > - perf event config format in /sys/devices/cpu/format/event
> >
> > Document the format of these files which would become part of the ABI.
> >
> > Changelog[v3]:
> > [Greg KH] Include ABI documentation.
>
> Jiri, can I have your ack on this one too?
hm, we already already 'format' definition but in testing section
(and we are missing 'events' definition there.. my bad)
anyway, after reading Documentation/ABI/README looks like we
should go for 'testing' section with this as well.. stable
seems scary at this point ;-)
jirka
>
> Greg, all ok now?
>
> - Arnaldo
>
> > Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> > ---
> > Documentation/ABI/stable/sysfs-devices-cpu-events | 54 +++++++++++++++++++++
> > Documentation/ABI/stable/sysfs-devices-cpu-format | 27 ++++++++++
> > 2 files changed, 81 insertions(+), 0 deletions(-)
> > create mode 100644 Documentation/ABI/stable/sysfs-devices-cpu-format
> >
> > diff --git a/Documentation/ABI/stable/sysfs-devices-cpu-events b/Documentation/ABI/stable/sysfs-devices-cpu-events
> > index e69de29..f37d542 100644
> > --- a/Documentation/ABI/stable/sysfs-devices-cpu-events
> > +++ b/Documentation/ABI/stable/sysfs-devices-cpu-events
> > @@ -0,0 +1,54 @@
> > +What: /sys/devices/cpu/events/
> > + /sys/devices/cpu/events/branch-misses
> > + /sys/devices/cpu/events/cache-references
> > + /sys/devices/cpu/events/cache-misses
> > + /sys/devices/cpu/events/stalled-cycles-frontend
> > + /sys/devices/cpu/events/branch-instructions
> > + /sys/devices/cpu/events/stalled-cycles-backend
> > + /sys/devices/cpu/events/instructions
> > + /sys/devices/cpu/events/cpu-cycles
> > +
> > +Date: 2013/01/08
> > +
> > +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
> > +
> > +Description: Generic performance monitoring events
> > +
> > + A collection of performance monitoring events that may be
> > + supported by many/most CPUs. These events can be monitored
> > + using the 'perf(1)' tool.
> > +
> > + The contents of each file would look like:
> > +
> > + event=0xNNNN
> > +
> > + where 'N' is a hex digit.
> > +
> > +
> > +What: /sys/devices/cpu/events/PM_LD_MISS_L1
> > + /sys/devices/cpu/events/PM_LD_REF_L1
> > + /sys/devices/cpu/events/PM_CYC
> > + /sys/devices/cpu/events/PM_BRU_FIN
> > + /sys/devices/cpu/events/PM_GCT_NOSLOT_CYC
> > + /sys/devices/cpu/events/PM_BRU_MPRED
> > + /sys/devices/cpu/events/PM_INST_CMPL
> > + /sys/devices/cpu/events/PM_CMPLU_STALL
> > +
> > +Date: 2013/01/08
> > +
> > +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
> > + Linux Powerpc mailing list <linuxppc-dev@ozlabs.org>
> > +
> > +Description: POWER specific performance monitoring events
> > +
> > + A collection of performance monitoring events that may be
> > + supported by the POWER CPU. These events can be monitored
> > + using the 'perf(1)' tool.
> > +
> > + These events may not be supported by other CPUs.
> > +
> > + The contents of each file would look like:
> > +
> > + event=0xNNNN
> > +
> > + where 'N' is a hex digit.
> > diff --git a/Documentation/ABI/stable/sysfs-devices-cpu-format b/Documentation/ABI/stable/sysfs-devices-cpu-format
> > new file mode 100644
> > index 0000000..b15cfb2
> > --- /dev/null
> > +++ b/Documentation/ABI/stable/sysfs-devices-cpu-format
> > @@ -0,0 +1,27 @@
> > +What: /sys/devices/cpu/format/
> > + /sys/devices/cpu/format/event
> > +
> > +Date: 2013/01/08
> > +
> > +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
> > +
> > +Description: Format of performance monitoring events
> > +
> > + Each CPU/architecture may use different format to represent
> > + the perf event. The 'event' file describes the configuration
> > + format of the performance monitoring event on the CPU/system.
> > +
> > + The contents of each file would look like:
> > +
> > + config:m-n
> > +
> > + where m and n are the starting and ending bits that are
> > + used to represent the event.
> > +
> > + For example, on POWER,
> > +
> > + $ cat /sys/devices/cpu/format/event
> > + config:0-20
> > +
> > + meaning that POWER uses the first 20-bits to represent a perf
> > + event.
> > --
> > 1.7.1
^ permalink raw reply
* [PATCH 2/2] memory-hotplug: cleanup: removing the arch specific functions without any implementation
From: Lin Feng @ 2013-01-16 8:14 UTC (permalink / raw)
To: akpm, mhocko, linux-mm, tglx, mingo, hpa, jbeulich, dhowells,
wency, isimatu.yasuaki, paul.gortmaker, laijs, kamezawa.hiroyu,
mel, minchan, aquini, jiang.liu, tony.luck, fenghua.yu, benh,
paulus, schwidefsky, heiko.carstens, davem, michael,
gerald.schaefer, gregkh
Cc: linux-s390, linux-ia64, x86, linux-kernel, tangchen, linfeng,
sparclinux, linux390, linuxppc-dev
In-Reply-To: <1358324059-9608-1-git-send-email-linfeng@cn.fujitsu.com>
From: Michal Hocko <mhocko@suse.cz>
After introducing CONFIG_HAVE_BOOTMEM_INFO_NODE Kconfig option, the related arch
specific functions become confusing, remove them.
Guys who want to implement memory-hotplug feature on such archs for this part
should look into register_page_bootmem_info_node() and flesh out from top to
end.
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Lin Feng <linfeng@cn.fujitsu.com>
---
arch/ia64/mm/discontig.c | 5 -----
arch/powerpc/mm/init_64.c | 5 -----
arch/s390/mm/vmem.c | 6 ------
arch/sparc/mm/init_64.c | 5 -----
4 files changed, 0 insertions(+), 21 deletions(-)
diff --git a/arch/ia64/mm/discontig.c b/arch/ia64/mm/discontig.c
index 882a0fd..cb5e1ff 100644
--- a/arch/ia64/mm/discontig.c
+++ b/arch/ia64/mm/discontig.c
@@ -827,9 +827,4 @@ void vmemmap_free(struct page *memmap, unsigned long nr_pages)
{
}
-void register_page_bootmem_memmap(unsigned long section_nr,
- struct page *start_page, unsigned long size)
-{
- /* TODO */
-}
#endif
diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
index 2969591..7e2246f 100644
--- a/arch/powerpc/mm/init_64.c
+++ b/arch/powerpc/mm/init_64.c
@@ -302,10 +302,5 @@ void vmemmap_free(struct page *memmap, unsigned long nr_pages)
{
}
-void register_page_bootmem_memmap(unsigned long section_nr,
- struct page *start_page, unsigned long size)
-{
- /* TODO */
-}
#endif /* CONFIG_SPARSEMEM_VMEMMAP */
diff --git a/arch/s390/mm/vmem.c b/arch/s390/mm/vmem.c
index 81e6ba3..fa09c2f 100644
--- a/arch/s390/mm/vmem.c
+++ b/arch/s390/mm/vmem.c
@@ -276,12 +276,6 @@ void vmemmap_free(struct page *memmap, unsigned long nr_pages)
{
}
-void register_page_bootmem_memmap(unsigned long section_nr,
- struct page *start_page, unsigned long size)
-{
- /* TODO */
-}
-
/*
* Add memory segment to the segment list if it doesn't overlap with
* an already present segment.
diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
index 5afe21a..76ac544 100644
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -2236,11 +2236,6 @@ void vmemmap_free(struct page *memmap, unsigned long nr_pages)
{
}
-void register_page_bootmem_memmap(unsigned long section_nr,
- struct page *start_page, unsigned long size)
-{
- /* TODO */
-}
#endif /* CONFIG_SPARSEMEM_VMEMMAP */
static void prot_init_common(unsigned long page_none,
--
1.7.1
^ permalink raw reply related
* [PATCH v3 1/2] memory-hotplug: introduce CONFIG_HAVE_BOOTMEM_INFO_NODE and revert register_page_bootmem_info_node() when platform not support
From: Lin Feng @ 2013-01-16 8:14 UTC (permalink / raw)
To: akpm, mhocko, linux-mm, tglx, mingo, hpa, jbeulich, dhowells,
wency, isimatu.yasuaki, paul.gortmaker, laijs, kamezawa.hiroyu,
mel, minchan, aquini, jiang.liu, tony.luck, fenghua.yu, benh,
paulus, schwidefsky, heiko.carstens, davem, michael,
gerald.schaefer, gregkh
Cc: linux-s390, linux-ia64, x86, linux-kernel, tangchen, linfeng,
sparclinux, linux390, linuxppc-dev
In-Reply-To: <1358324059-9608-1-git-send-email-linfeng@cn.fujitsu.com>
It's implemented by adding a new Kconfig option named
CONFIG_HAVE_BOOTMEM_INFO_NODE, which will be automatically selected by
memory-hotplug feature fully supported archs(currently only on x86_64).
Reported-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Lin Feng <linfeng@cn.fujitsu.com>
---
ChangeLog v2->v3:
- Rename the patch title to conform it's content.
- Update memory_hotplug.h and remove the misleading TODO pointed out by Michal.
ChangeLog v1->v2:
- Add a Kconfig option named HAVE_BOOTMEM_INFO_NODE suggested by Michal, which
will be automatically selected by supported archs(currently only on x86_64).
---
arch/x86/mm/init_64.c | 2 +-
include/linux/memory_hotplug.h | 6 ++++++
mm/Kconfig | 8 ++++++++
mm/memory_hotplug.c | 2 ++
4 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 07d6966..b539015 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1317,7 +1317,7 @@ vmemmap_populate(struct page *start_page, unsigned long size, int node)
return 0;
}
-#ifdef CONFIG_MEMORY_HOTPLUG_SPARSE
+#if defined(CONFIG_MEMORY_HOTPLUG_SPARSE) && defined(CONFIG_HAVE_BOOTMEM_INFO_NODE)
void register_page_bootmem_memmap(unsigned long section_nr,
struct page *start_page, unsigned long size)
{
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index f60e728..69903cc 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -174,7 +174,13 @@ static inline void arch_refresh_nodedata(int nid, pg_data_t *pgdat)
#endif /* CONFIG_NUMA */
#endif /* CONFIG_HAVE_ARCH_NODEDATA_EXTENSION */
+#ifdef CONFIG_HAVE_BOOTMEM_INFO_NODE
extern void register_page_bootmem_info_node(struct pglist_data *pgdat);
+#else
+static inline void register_page_bootmem_info_node(struct pglist_data *pgdat)
+{
+}
+#endif
extern void put_page_bootmem(struct page *page);
extern void get_page_bootmem(unsigned long ingo, struct page *page,
unsigned long type);
diff --git a/mm/Kconfig b/mm/Kconfig
index 278e3ab..f8c5799 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -162,10 +162,18 @@ config MOVABLE_NODE
Say Y here if you want to hotplug a whole node.
Say N here if you want kernel to use memory on all nodes evenly.
+#
+# Only be set on architectures that have completely implemented memory hotplug
+# feature. If you are not sure, don't touch it.
+#
+config HAVE_BOOTMEM_INFO_NODE
+ def_bool n
+
# eventually, we can have this option just 'select SPARSEMEM'
config MEMORY_HOTPLUG
bool "Allow for memory hot-add"
select MEMORY_ISOLATION
+ select HAVE_BOOTMEM_INFO_NODE if X86_64
depends on SPARSEMEM || X86_64_ACPI_NUMA
depends on HOTPLUG && ARCH_ENABLE_MEMORY_HOTPLUG
depends on (IA64 || X86 || PPC_BOOK3S_64 || SUPERH || S390)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 8aa2b56..daf111f 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -189,6 +189,7 @@ static void register_page_bootmem_info_section(unsigned long start_pfn)
}
#endif
+#ifdef CONFIG_HAVE_BOOTMEM_INFO_NODE
void register_page_bootmem_info_node(struct pglist_data *pgdat)
{
unsigned long i, pfn, end_pfn, nr_pages;
@@ -230,6 +231,7 @@ void register_page_bootmem_info_node(struct pglist_data *pgdat)
register_page_bootmem_info_section(pfn);
}
}
+#endif
static void grow_zone_span(struct zone *zone, unsigned long start_pfn,
unsigned long end_pfn)
--
1.7.1
^ permalink raw reply related
* [PATCH v3 0/2] memory-hotplug: introduce CONFIG_HAVE_BOOTMEM_INFO_NODE and revert register_page_bootmem_info_node() when platform not support
From: Lin Feng @ 2013-01-16 8:14 UTC (permalink / raw)
To: akpm, mhocko, linux-mm, tglx, mingo, hpa, jbeulich, dhowells,
wency, isimatu.yasuaki, paul.gortmaker, laijs, kamezawa.hiroyu,
mel, minchan, aquini, jiang.liu, tony.luck, fenghua.yu, benh,
paulus, schwidefsky, heiko.carstens, davem, michael,
gerald.schaefer, gregkh
Cc: linux-s390, linux-ia64, x86, linux-kernel, tangchen, linfeng,
sparclinux, linux390, linuxppc-dev
Memory-hotplug codes for x86_64 have been implemented by patchset:
https://lkml.org/lkml/2013/1/9/124
While other platforms haven't been completely implemented yet.
If we enable both CONFIG_MEMORY_HOTPLUG_SPARSE and CONFIG_SPARSEMEM_VMEMMAP,
register_page_bootmem_info_node() may be buggy, which is a hotplug generic
function but falling back to call platform related function
register_page_bootmem_memmap().
Other platforms such as powerpc it's not implemented, so on such platforms,
revert them to empty as they were before.
It's implemented by adding a new Kconfig option named
CONFIG_HAVE_BOOTMEM_INFO_NODE, which will be automatically selected by
memory-hotplug supported archs(currently only on x86_64).
changeLog v2->v3:
1) patch 1/2:
- Rename the patch title to conform it's content.
- Update memory_hotplug.h and remove the misleading TODO pointed out by Michal.
2) patch 2/2:
- New added, remove unimplemented functions suggested by Michal.
ChangeLog v1->v2:
1) patch 1/2:
- Add a Kconfig option named HAVE_BOOTMEM_INFO_NODE suggested by Michal, which
will be automatically selected by supported archs(currently only on x86_64).
Lin Feng (1):
memory-hotplug: revert register_page_bootmem_info_node() to empty
when platform related code is not implemented
Michal Hocko (1):
memory-hotplug: cleanup: removing the arch specific functions without
any implementation
arch/ia64/mm/discontig.c | 5 -----
arch/powerpc/mm/init_64.c | 5 -----
arch/s390/mm/vmem.c | 6 ------
arch/sparc/mm/init_64.c | 5 -----
arch/x86/mm/init_64.c | 2 +-
include/linux/memory_hotplug.h | 6 ++++++
mm/Kconfig | 8 ++++++++
mm/memory_hotplug.c | 2 ++
8 files changed, 17 insertions(+), 22 deletions(-)
^ permalink raw reply
* [v1][PATCH 1/1] ppc64: max next_tb to prevent from replaying timer interrupt
From: Tiejun Chen @ 2013-01-16 3:01 UTC (permalink / raw)
To: benh, galak; +Cc: linuxppc-dev, linux-kernel
With lazy interrupt, we always call __check_irq_replaysome with
decrementers_next_tb to check if we need to replay timer interrupt.
So in hotplug case we also need to set decrementers_next_tb as MAX
to make sure __check_irq_replay don't replay timer interrupt
when return as we expect, otherwise we'll trap here infinitely.
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
v1:
* In hotplug case we max decrementers_next_tb to prevent from
replaying timer interrupt for any offline CPU.
arch/powerpc/kernel/time.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 6f6b1cc..127361e 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -494,10 +494,15 @@ void timer_interrupt(struct pt_regs * regs)
set_dec(DECREMENTER_MAX);
/* Some implementations of hotplug will get timer interrupts while
- * offline, just ignore these
+ * offline, just ignore these and we also need to set
+ * decrementers_next_tb as MAX to make sure __check_irq_replay
+ * don't replay timer interrupt when return, otherwise we'll trap
+ * here infinitely :(
*/
- if (!cpu_online(smp_processor_id()))
+ if (!cpu_online(smp_processor_id())) {
+ *next_tb = ~(u64)0;
return;
+ }
/* Conditionally hard-enable interrupts now that the DEC has been
* bumped to its maximum value
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC][v0][PATCH 1/1] ppc64: ignore interrupts while offline
From: tiejun.chen @ 2013-01-16 3:00 UTC (permalink / raw)
To: benh, galak; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1358245860-6546-1-git-send-email-tiejun.chen@windriver.com>
Please ignore this to check next version.
Tiejun
On 01/15/2013 06:31 PM, Tiejun Chen wrote:
> With lazy interrupt, some implementations of hotplug will
> get some interrupts even while offline, just ignore these.
>
> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
> ---
> arch/powerpc/kernel/irq.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index 4f97fe3..dbca574 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -144,6 +144,12 @@ notrace unsigned int __check_irq_replay(void)
> */
> unsigned char happened = local_paca->irq_happened;
>
> + /* Some implementations of hotplug will get some interrupts while
> + * offline, just ignore these.
> + */
> + if (cpu_is_offline(smp_processor_id()))
> + return 0;
> +
> /* Clear bit 0 which we wouldn't clear otherwise */
> local_paca->irq_happened &= ~PACA_IRQ_HARD_DIS;
>
>
^ permalink raw reply
* Re: [BUG Fix Patch 1/6] Bug fix: Hold spinlock across find|remove /sys/firmware/memmap/X operation.
From: Tang Chen @ 2013-01-16 2:12 UTC (permalink / raw)
To: Julian Calaby
Cc: linux-ia64, linux-sh, linux-mm, paulus, hpa, sparclinux, cl,
linux-s390, x86, linux-acpi, isimatu.yasuaki, linfeng, mgorman,
kosaki.motohiro, rientjes, len.brown, jiang.liu, wency, cmetcalf,
glommer, wujianguo, yinghai, laijs, linux-kernel, minchan.kim,
akpm, linuxppc-dev
In-Reply-To: <CAGRGNgWCdvWhp=9+PDRbC9bK100BdBv9kpcsqoM-J6ipq22Szw@mail.gmail.com>
On 01/16/2013 06:26 AM, Julian Calaby wrote:
> Hi Tang,
>
> One minor point.
>
>>
>> /*
>> - * Search memmap entry
>> + * firmware_map_find_entry: Search memmap entry.
>> + * @start: Start of the memory range.
>> + * @end: End of the memory range (exclusive).
>> + * @type: Type of the memory range.
>> + *
>> + * This function is to find the memmap entey of a given memory range.
>> + * The caller must hold map_entries_lock, and must not release the lock
>> + * until the processing of the returned entry has completed.
>> + *
>> + * Return pointer to the entry to be found on success, or NULL on failure.
>
> Why not make this completely kernel-doc compliant as you're already
> re-writing the comment?
Hi Julian,
Thank you for reminding me this. I think I may have some more problems
like this. I'll post a patch to fix as many of them as I can. :)
Thanks.
^ permalink raw reply
* Re: [PATCH v5 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
From: Peter Chen @ 2013-01-16 1:48 UTC (permalink / raw)
To: Shawn Guo
Cc: r58472, gregkh, linux-usb, balbi, kernel, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20130115140344.GB6574@S2101-09.ap.freescale.net>
On Tue, Jan 15, 2013 at 10:03:46PM +0800, Shawn Guo wrote:
> On Tue, Jan 15, 2013 at 10:29:33AM +0800, Peter Chen wrote:
> > As mach/hardware.h is deleted, we need to use platform_device_id to
> > differentiate SoCs. Besides, one cpu_is_mx35 is useless as it has
> > already used pdata to differentiate runtime
> >
> > Meanwhile we update the platform code accordingly.
> >
> > Signed-off-by: Peter Chen <peter.chen@freescale.com>
> > ---
> > arch/arm/mach-imx/devices/devices-common.h | 1 +
> > arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c | 15 ++++---
> > drivers/usb/gadget/fsl_mxc_udc.c | 24 +++++-------
> > drivers/usb/gadget/fsl_udc_core.c | 42 +++++++++++++--------
> > 4 files changed, 45 insertions(+), 37 deletions(-)
>
> Since we are splitting the original patch anyway, it's a bit strange
> to me that you are mixing arch/arm/mach-imx and drivers/usb/gadget
> in this patch. I'm fine with it, since I assume all the patches to
> go via USB tree anyway.
>
> >
> > diff --git a/arch/arm/mach-imx/devices/devices-common.h b/arch/arm/mach-imx/devices/devices-common.h
> > index 6277baf..9bd5777 100644
> > --- a/arch/arm/mach-imx/devices/devices-common.h
> > +++ b/arch/arm/mach-imx/devices/devices-common.h
> > @@ -63,6 +63,7 @@ struct platform_device *__init imx_add_flexcan(
> >
> > #include <linux/fsl_devices.h>
> > struct imx_fsl_usb2_udc_data {
> > + const char *devid;
> > resource_size_t iobase;
> > resource_size_t irq;
> > };
> > diff --git a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
> > index 37e4439..fb527c7 100644
> > --- a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
> > +++ b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
> > @@ -11,35 +11,36 @@
> > #include "../hardware.h"
> > #include "devices-common.h"
> >
> > -#define imx_fsl_usb2_udc_data_entry_single(soc) \
> > +#define imx_fsl_usb2_udc_data_entry_single(soc, _devid) \
> > { \
> > + .devid = _devid, \
> > .iobase = soc ## _USB_OTG_BASE_ADDR, \
> > .irq = soc ## _INT_USB_OTG, \
> > }
> >
> > #ifdef CONFIG_SOC_IMX25
> > const struct imx_fsl_usb2_udc_data imx25_fsl_usb2_udc_data __initconst =
> > - imx_fsl_usb2_udc_data_entry_single(MX25);
> > + imx_fsl_usb2_udc_data_entry_single(MX25, "imx-udc-mx25");
> > #endif /* ifdef CONFIG_SOC_IMX25 */
> >
> > #ifdef CONFIG_SOC_IMX27
> > const struct imx_fsl_usb2_udc_data imx27_fsl_usb2_udc_data __initconst =
> > - imx_fsl_usb2_udc_data_entry_single(MX27);
> > + imx_fsl_usb2_udc_data_entry_single(MX27, "imx-udc-mx27");
> > #endif /* ifdef CONFIG_SOC_IMX27 */
> >
> > #ifdef CONFIG_SOC_IMX31
> > const struct imx_fsl_usb2_udc_data imx31_fsl_usb2_udc_data __initconst =
> > - imx_fsl_usb2_udc_data_entry_single(MX31);
> > + imx_fsl_usb2_udc_data_entry_single(MX31, "imx-udc-mx31");
> > #endif /* ifdef CONFIG_SOC_IMX31 */
> >
> > #ifdef CONFIG_SOC_IMX35
> > const struct imx_fsl_usb2_udc_data imx35_fsl_usb2_udc_data __initconst =
> > - imx_fsl_usb2_udc_data_entry_single(MX35);
> > + imx_fsl_usb2_udc_data_entry_single(MX35, "imx-udc-mx35");
> > #endif /* ifdef CONFIG_SOC_IMX35 */
> >
> > #ifdef CONFIG_SOC_IMX51
> > const struct imx_fsl_usb2_udc_data imx51_fsl_usb2_udc_data __initconst =
> > - imx_fsl_usb2_udc_data_entry_single(MX51);
> > + imx_fsl_usb2_udc_data_entry_single(MX51, "imx-udc-mx51");
> > #endif
> >
> > struct platform_device *__init imx_add_fsl_usb2_udc(
> > @@ -57,7 +58,7 @@ struct platform_device *__init imx_add_fsl_usb2_udc(
> > .flags = IORESOURCE_IRQ,
> > },
> > };
> > - return imx_add_platform_device_dmamask("fsl-usb2-udc", -1,
> > + return imx_add_platform_device_dmamask(data->devid, -1,
> > res, ARRAY_SIZE(res),
> > pdata, sizeof(*pdata), DMA_BIT_MASK(32));
> > }
>
> <snip>
>
> > +static const struct platform_device_id fsl_udc_devtype[] = {
> > + {
> > + .name = "imx-udc-mx25",
> > + }, {
> > + .name = "imx-udc-mx27",
> > + }, {
> > + .name = "imx-udc-mx31",
> > + }, {
> > + .name = "imx-udc-mx35",
> > + }, {
> > + .name = "imx-udc-mx51",
> > + }
> > +};
>
> From what I understand balbi's comment, he dislikes this full list of
> device id. Instead, he prefers to something like below.
>
> static const struct platform_device_id fsl_udc_devtype[] = {
> {
> .name = "imx-udc-mx27",
> }, {
> .name = "imx-udc-mx51",
> }
> };
>
> It basically tells that we are handling two type of devices here, one
> is imx-udc-mx27 type and the other is imx-udc-mx51 type, with mx25/31/35
> completely compatible with mx27 type. We choose mx27 instead of mx25
> to define the type because mx27 Si came out earlier than mx25. That
> said, we generally choose the earlies SoC name to define a particular
> version of IP block, since hardware version is mostly unavailable or
> unreliable.
>
> But that also means in platform code which create the platform_device,
> you will need to use name "imx-udc-mx27" for even mx25/31/35.
>
> imx_fsl_usb2_udc_data_entry_single(MX25, "imx-udc-mx27");
> imx_fsl_usb2_udc_data_entry_single(MX31, "imx-udc-mx27");
> imx_fsl_usb2_udc_data_entry_single(MX35, "imx-udc-mx27");
>
> Considering this is a piece of code we will not use for any new
> hardware, I'm fine with either way.
>
> So, balbi, it's all your call to accept the series as it is or ask for
> another iteration.
Thanks Shawn. Let's see Felipe's comment, nevertheless, I will send v6 patch
due to a compile error at mx25
>
> Shawn
--
Best Regards,
Peter Chen
^ permalink raw reply
* Re: [PATCH 6/6][v3] perf: Document the ABI of perf sysfs entries
From: Greg KH @ 2013-01-15 22:47 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Andi Kleen, Peter Zijlstra, robert.richter, Anton Blanchard,
linux-kernel, Stephane Eranian, linuxppc-dev, Ingo Molnar,
Paul Mackerras, Sukadev Bhattiprolu, Jiri Olsa
In-Reply-To: <20130115185759.GG5826@ghostprotocols.net>
On Tue, Jan 15, 2013 at 03:57:59PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Jan 09, 2013 at 05:07:03PM -0800, Sukadev Bhattiprolu escreveu:
> > [PATCH 6/6][v3] perf: Document the ABI of perf sysfs entries
> >
> > This patchset addes two new sets of files to sysfs:
> >
> > - generic and POWER-specific perf events in /sys/devices/cpu/events/
> > - perf event config format in /sys/devices/cpu/format/event
> >
> > Document the format of these files which would become part of the ABI.
> >
> > Changelog[v3]:
> > [Greg KH] Include ABI documentation.
>
> Jiri, can I have your ack on this one too?
>
> Greg, all ok now?
No objection from me, thanks.
greg k-h
^ permalink raw reply
* Re: [BUG Fix Patch 1/6] Bug fix: Hold spinlock across find|remove /sys/firmware/memmap/X operation.
From: Julian Calaby @ 2013-01-15 22:26 UTC (permalink / raw)
To: Tang Chen
Cc: linux-ia64, linux-sh, linux-mm, paulus, hpa, sparclinux, cl,
linux-s390, x86, linux-acpi, isimatu.yasuaki, linfeng, mgorman,
kosaki.motohiro, rientjes, len.brown, jiang.liu, wency, cmetcalf,
glommer, wujianguo, yinghai, laijs, linux-kernel, minchan.kim,
akpm, linuxppc-dev
In-Reply-To: <1358247267-18089-2-git-send-email-tangchen@cn.fujitsu.com>
Hi Tang,
One minor point.
On Tue, Jan 15, 2013 at 9:54 PM, Tang Chen <tangchen@cn.fujitsu.com> wrote:
> It is unsafe to return an entry pointer and release the map_entries_lock. So we should
> not hold the map_entries_lock separately in firmware_map_find_entry() and
> firmware_map_remove_entry(). Hold the map_entries_lock across find and remove
> /sys/firmware/memmap/X operation.
>
> And also, users of these two functions need to be careful to hold the lock when using
> these two functions.
>
> The suggestion is from Andrew Morton <akpm@linux-foundation.org>
>
> Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
> ---
> drivers/firmware/memmap.c | 25 +++++++++++++++++--------
> 1 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/firmware/memmap.c b/drivers/firmware/memmap.c
> index 4211da5..940c4e9 100644
> --- a/drivers/firmware/memmap.c
> +++ b/drivers/firmware/memmap.c
> @@ -188,23 +188,28 @@ static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry)
> }
>
> /*
> - * Search memmap entry
> + * firmware_map_find_entry: Search memmap entry.
> + * @start: Start of the memory range.
> + * @end: End of the memory range (exclusive).
> + * @type: Type of the memory range.
> + *
> + * This function is to find the memmap entey of a given memory range.
> + * The caller must hold map_entries_lock, and must not release the lock
> + * until the processing of the returned entry has completed.
> + *
> + * Return pointer to the entry to be found on success, or NULL on failure.
Why not make this completely kernel-doc compliant as you're already
re-writing the comment?
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* [PATCH] powerpc/fsl: remove extraneous DIU platform functions
From: Timur Tabi @ 2013-01-15 20:04 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev
From: Timur Tabi <timur@freescale.com>
The Freescale DIU driver was recently updated to not require a
set_monitor_port platform function if there is only one monitor port. This
is the case on the P1022 RDK and the MPC5121 ADS boards. So now we can
remove those functions.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/platforms/512x/mpc512x_shared.c | 5 -----
arch/powerpc/platforms/85xx/p1022_rdk.c | 12 ------------
2 files changed, 0 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/platforms/512x/mpc512x_shared.c
index 35f14fd..c7f47cf 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -68,10 +68,6 @@ struct fsl_diu_shared_fb {
bool in_use;
};
-void mpc512x_set_monitor_port(enum fsl_diu_monitor_port port)
-{
-}
-
#define DIU_DIV_MASK 0x000000ff
void mpc512x_set_pixel_clock(unsigned int pixclock)
{
@@ -303,7 +299,6 @@ void __init mpc512x_setup_diu(void)
}
}
- diu_ops.set_monitor_port = mpc512x_set_monitor_port;
diu_ops.set_pixel_clock = mpc512x_set_pixel_clock;
diu_ops.valid_monitor_port = mpc512x_valid_monitor_port;
diu_ops.release_bootmem = mpc512x_release_bootmem;
diff --git a/arch/powerpc/platforms/85xx/p1022_rdk.c b/arch/powerpc/platforms/85xx/p1022_rdk.c
index 55ffa1c..8c92971 100644
--- a/arch/powerpc/platforms/85xx/p1022_rdk.c
+++ b/arch/powerpc/platforms/85xx/p1022_rdk.c
@@ -35,17 +35,6 @@
#define CLKDVDR_PXCLK_MASK 0x00FF0000
/**
- * p1022rdk_set_monitor_port: switch the output to a different monitor port
- */
-static void p1022rdk_set_monitor_port(enum fsl_diu_monitor_port port)
-{
- if (port != FSL_DIU_PORT_DVI) {
- pr_err("p1022rdk: unsupported monitor port %i\n", port);
- return;
- }
-}
-
-/**
* p1022rdk_set_pixel_clock: program the DIU's clock
*
* @pixclock: the wavelength, in picoseconds, of the clock
@@ -124,7 +113,6 @@ static void __init p1022_rdk_setup_arch(void)
ppc_md.progress("p1022_rdk_setup_arch()", 0);
#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
- diu_ops.set_monitor_port = p1022rdk_set_monitor_port;
diu_ops.set_pixel_clock = p1022rdk_set_pixel_clock;
diu_ops.valid_monitor_port = p1022rdk_valid_monitor_port;
#endif
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH 6/6][v3] perf: Document the ABI of perf sysfs entries
From: Arnaldo Carvalho de Melo @ 2013-01-15 18:57 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: Andi Kleen, Peter Zijlstra, robert.richter, Greg KH,
Anton Blanchard, linux-kernel, Stephane Eranian, linuxppc-dev,
Ingo Molnar, Paul Mackerras, Jiri Olsa
In-Reply-To: <20130110010703.GF32590@us.ibm.com>
Em Wed, Jan 09, 2013 at 05:07:03PM -0800, Sukadev Bhattiprolu escreveu:
> [PATCH 6/6][v3] perf: Document the ABI of perf sysfs entries
>
> This patchset addes two new sets of files to sysfs:
>
> - generic and POWER-specific perf events in /sys/devices/cpu/events/
> - perf event config format in /sys/devices/cpu/format/event
>
> Document the format of these files which would become part of the ABI.
>
> Changelog[v3]:
> [Greg KH] Include ABI documentation.
Jiri, can I have your ack on this one too?
Greg, all ok now?
- Arnaldo
> Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> ---
> Documentation/ABI/stable/sysfs-devices-cpu-events | 54 +++++++++++++++++++++
> Documentation/ABI/stable/sysfs-devices-cpu-format | 27 ++++++++++
> 2 files changed, 81 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/ABI/stable/sysfs-devices-cpu-format
>
> diff --git a/Documentation/ABI/stable/sysfs-devices-cpu-events b/Documentation/ABI/stable/sysfs-devices-cpu-events
> index e69de29..f37d542 100644
> --- a/Documentation/ABI/stable/sysfs-devices-cpu-events
> +++ b/Documentation/ABI/stable/sysfs-devices-cpu-events
> @@ -0,0 +1,54 @@
> +What: /sys/devices/cpu/events/
> + /sys/devices/cpu/events/branch-misses
> + /sys/devices/cpu/events/cache-references
> + /sys/devices/cpu/events/cache-misses
> + /sys/devices/cpu/events/stalled-cycles-frontend
> + /sys/devices/cpu/events/branch-instructions
> + /sys/devices/cpu/events/stalled-cycles-backend
> + /sys/devices/cpu/events/instructions
> + /sys/devices/cpu/events/cpu-cycles
> +
> +Date: 2013/01/08
> +
> +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
> +
> +Description: Generic performance monitoring events
> +
> + A collection of performance monitoring events that may be
> + supported by many/most CPUs. These events can be monitored
> + using the 'perf(1)' tool.
> +
> + The contents of each file would look like:
> +
> + event=0xNNNN
> +
> + where 'N' is a hex digit.
> +
> +
> +What: /sys/devices/cpu/events/PM_LD_MISS_L1
> + /sys/devices/cpu/events/PM_LD_REF_L1
> + /sys/devices/cpu/events/PM_CYC
> + /sys/devices/cpu/events/PM_BRU_FIN
> + /sys/devices/cpu/events/PM_GCT_NOSLOT_CYC
> + /sys/devices/cpu/events/PM_BRU_MPRED
> + /sys/devices/cpu/events/PM_INST_CMPL
> + /sys/devices/cpu/events/PM_CMPLU_STALL
> +
> +Date: 2013/01/08
> +
> +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
> + Linux Powerpc mailing list <linuxppc-dev@ozlabs.org>
> +
> +Description: POWER specific performance monitoring events
> +
> + A collection of performance monitoring events that may be
> + supported by the POWER CPU. These events can be monitored
> + using the 'perf(1)' tool.
> +
> + These events may not be supported by other CPUs.
> +
> + The contents of each file would look like:
> +
> + event=0xNNNN
> +
> + where 'N' is a hex digit.
> diff --git a/Documentation/ABI/stable/sysfs-devices-cpu-format b/Documentation/ABI/stable/sysfs-devices-cpu-format
> new file mode 100644
> index 0000000..b15cfb2
> --- /dev/null
> +++ b/Documentation/ABI/stable/sysfs-devices-cpu-format
> @@ -0,0 +1,27 @@
> +What: /sys/devices/cpu/format/
> + /sys/devices/cpu/format/event
> +
> +Date: 2013/01/08
> +
> +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
> +
> +Description: Format of performance monitoring events
> +
> + Each CPU/architecture may use different format to represent
> + the perf event. The 'event' file describes the configuration
> + format of the performance monitoring event on the CPU/system.
> +
> + The contents of each file would look like:
> +
> + config:m-n
> +
> + where m and n are the starting and ending bits that are
> + used to represent the event.
> +
> + For example, on POWER,
> +
> + $ cat /sys/devices/cpu/format/event
> + config:0-20
> +
> + meaning that POWER uses the first 20-bits to represent a perf
> + event.
> --
> 1.7.1
^ permalink raw reply
* Re: [PATCH] powerpc: added DSCR support to ptrace
From: Benjamin Herrenschmidt @ 2013-01-15 18:17 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: Michael Neuling, linuxppc-dev, linux-kernel
In-Reply-To: <1357885749-14042-1-git-send-email-aik@ozlabs.ru>
On Fri, 2013-01-11 at 17:29 +1100, Alexey Kardashevskiy wrote:
> +static unsigned long get_user_dscr(struct task_struct *task)
> +{
> + return -EIO;
> +}
> +
Does it make sense to return an error here ? ptrace_get_reg() doesn't
seem to have provisions for returning errors, it just return register
values, there's no way to differenciate an error code from a register
value as far as I can tell...
I'll apply your patch anyway because this is an existing problem with
that function (it already returns -EIO in other circumstances), but I
would like if you could submit a followup patch that changes it to
return the register by value and return a real error code, which can be
then handled properly in the two call sites (ptrace.c and ptrace32.c).
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
From: Shawn Guo @ 2013-01-15 14:03 UTC (permalink / raw)
To: Peter Chen
Cc: r58472, gregkh, linux-usb, balbi, kernel, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <1358216975-1404-2-git-send-email-peter.chen@freescale.com>
On Tue, Jan 15, 2013 at 10:29:33AM +0800, Peter Chen wrote:
> As mach/hardware.h is deleted, we need to use platform_device_id to
> differentiate SoCs. Besides, one cpu_is_mx35 is useless as it has
> already used pdata to differentiate runtime
>
> Meanwhile we update the platform code accordingly.
>
> Signed-off-by: Peter Chen <peter.chen@freescale.com>
> ---
> arch/arm/mach-imx/devices/devices-common.h | 1 +
> arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c | 15 ++++---
> drivers/usb/gadget/fsl_mxc_udc.c | 24 +++++-------
> drivers/usb/gadget/fsl_udc_core.c | 42 +++++++++++++--------
> 4 files changed, 45 insertions(+), 37 deletions(-)
Since we are splitting the original patch anyway, it's a bit strange
to me that you are mixing arch/arm/mach-imx and drivers/usb/gadget
in this patch. I'm fine with it, since I assume all the patches to
go via USB tree anyway.
>
> diff --git a/arch/arm/mach-imx/devices/devices-common.h b/arch/arm/mach-imx/devices/devices-common.h
> index 6277baf..9bd5777 100644
> --- a/arch/arm/mach-imx/devices/devices-common.h
> +++ b/arch/arm/mach-imx/devices/devices-common.h
> @@ -63,6 +63,7 @@ struct platform_device *__init imx_add_flexcan(
>
> #include <linux/fsl_devices.h>
> struct imx_fsl_usb2_udc_data {
> + const char *devid;
> resource_size_t iobase;
> resource_size_t irq;
> };
> diff --git a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
> index 37e4439..fb527c7 100644
> --- a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
> +++ b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
> @@ -11,35 +11,36 @@
> #include "../hardware.h"
> #include "devices-common.h"
>
> -#define imx_fsl_usb2_udc_data_entry_single(soc) \
> +#define imx_fsl_usb2_udc_data_entry_single(soc, _devid) \
> { \
> + .devid = _devid, \
> .iobase = soc ## _USB_OTG_BASE_ADDR, \
> .irq = soc ## _INT_USB_OTG, \
> }
>
> #ifdef CONFIG_SOC_IMX25
> const struct imx_fsl_usb2_udc_data imx25_fsl_usb2_udc_data __initconst =
> - imx_fsl_usb2_udc_data_entry_single(MX25);
> + imx_fsl_usb2_udc_data_entry_single(MX25, "imx-udc-mx25");
> #endif /* ifdef CONFIG_SOC_IMX25 */
>
> #ifdef CONFIG_SOC_IMX27
> const struct imx_fsl_usb2_udc_data imx27_fsl_usb2_udc_data __initconst =
> - imx_fsl_usb2_udc_data_entry_single(MX27);
> + imx_fsl_usb2_udc_data_entry_single(MX27, "imx-udc-mx27");
> #endif /* ifdef CONFIG_SOC_IMX27 */
>
> #ifdef CONFIG_SOC_IMX31
> const struct imx_fsl_usb2_udc_data imx31_fsl_usb2_udc_data __initconst =
> - imx_fsl_usb2_udc_data_entry_single(MX31);
> + imx_fsl_usb2_udc_data_entry_single(MX31, "imx-udc-mx31");
> #endif /* ifdef CONFIG_SOC_IMX31 */
>
> #ifdef CONFIG_SOC_IMX35
> const struct imx_fsl_usb2_udc_data imx35_fsl_usb2_udc_data __initconst =
> - imx_fsl_usb2_udc_data_entry_single(MX35);
> + imx_fsl_usb2_udc_data_entry_single(MX35, "imx-udc-mx35");
> #endif /* ifdef CONFIG_SOC_IMX35 */
>
> #ifdef CONFIG_SOC_IMX51
> const struct imx_fsl_usb2_udc_data imx51_fsl_usb2_udc_data __initconst =
> - imx_fsl_usb2_udc_data_entry_single(MX51);
> + imx_fsl_usb2_udc_data_entry_single(MX51, "imx-udc-mx51");
> #endif
>
> struct platform_device *__init imx_add_fsl_usb2_udc(
> @@ -57,7 +58,7 @@ struct platform_device *__init imx_add_fsl_usb2_udc(
> .flags = IORESOURCE_IRQ,
> },
> };
> - return imx_add_platform_device_dmamask("fsl-usb2-udc", -1,
> + return imx_add_platform_device_dmamask(data->devid, -1,
> res, ARRAY_SIZE(res),
> pdata, sizeof(*pdata), DMA_BIT_MASK(32));
> }
<snip>
> +static const struct platform_device_id fsl_udc_devtype[] = {
> + {
> + .name = "imx-udc-mx25",
> + }, {
> + .name = "imx-udc-mx27",
> + }, {
> + .name = "imx-udc-mx31",
> + }, {
> + .name = "imx-udc-mx35",
> + }, {
> + .name = "imx-udc-mx51",
> + }
> +};
>From what I understand balbi's comment, he dislikes this full list of
device id. Instead, he prefers to something like below.
static const struct platform_device_id fsl_udc_devtype[] = {
{
.name = "imx-udc-mx27",
}, {
.name = "imx-udc-mx51",
}
};
It basically tells that we are handling two type of devices here, one
is imx-udc-mx27 type and the other is imx-udc-mx51 type, with mx25/31/35
completely compatible with mx27 type. We choose mx27 instead of mx25
to define the type because mx27 Si came out earlier than mx25. That
said, we generally choose the earlies SoC name to define a particular
version of IP block, since hardware version is mostly unavailable or
unreliable.
But that also means in platform code which create the platform_device,
you will need to use name "imx-udc-mx27" for even mx25/31/35.
imx_fsl_usb2_udc_data_entry_single(MX25, "imx-udc-mx27");
imx_fsl_usb2_udc_data_entry_single(MX31, "imx-udc-mx27");
imx_fsl_usb2_udc_data_entry_single(MX35, "imx-udc-mx27");
Considering this is a piece of code we will not use for any new
hardware, I'm fine with either way.
So, balbi, it's all your call to accept the series as it is or ask for
another iteration.
Shawn
^ permalink raw reply
* Issue with USB Mass storage on P5020
From: Vineeth @ 2013-01-15 13:04 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]
When i connect my 500GB seagate HD on a P5020DS, its not getting mounted.
This is the dmesg log;
am i supposed to change some configuration ?
/ # dmesg
usb 1-1: new high speed USB device using fsl-ehci and address 5
usb 1-1: configuration #1 chosen from 1 choice
scsi2 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 5
usb-storage: waiting for device to settle before scanning
do_scsi_scan_host
scsi 2:0:0:0: Direct-Access Seagate Expansion 0219 PQ: 0 ANSI: 6
sd 2:0:0:0: Attached scsi generic sg0 type 0
usb 1-1: USB disconnect, address 5
sd 2:0:0:0: [sda] the result = 65536
usb-storage: device scan complete
sd 2:0:0:0: [sda] sense_valid = 0
sd 2:0:0:0: [sda] the result = 65536
sd 2:0:0:0: [sda] sense_valid = 0
sd 2:0:0:0: [sda] the result = 65536
sd 2:0:0:0: [sda] sense_valid = 0
*sd 2:0:0:0: [sda] READ CAPACITY failed*
sd 2:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00
sd 2:0:0:0: [sda] Sense not available.
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: ea 0d 20 84
sd 2:0:0:0: [sda] Assuming drive cache: write through
sd 2:0:0:0: [sda] the result = 65536
sd 2:0:0:0: [sda] sense_valid = 0
sd 2:0:0:0: [sda] the result = 65536
sd 2:0:0:0: [sda] sense_valid = 0
sd 2:0:0:0: [sda] the result = 65536
sd 2:0:0:0: [sda] sense_valid = 0
*sd 2:0:0:0: [sda] READ CAPACITY failed *
sd 2:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00
sd 2:0:0:0: [sda] Sense not available.
sd 2:0:0:0: [sda] Assuming drive cache: write through
sd 2:0:0:0: [sda] Attached SCSI disk
/ #
/ #
/ #
-- VISUAL --
[-- Attachment #2: Type: text/html, Size: 1874 bytes --]
^ permalink raw reply
* [BUG Fix Patch 6/6] Bug fix: Reuse the storage of /sys/firmware/memmap/X/ allocated by bootmem.
From: Tang Chen @ 2013-01-15 10:54 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, tangchen, hpa,
linfeng, laijs, mgorman, yinghai, glommer, jiang.liu
Cc: linux-s390, linux-ia64, linux-acpi, linux-sh, x86, linux-kernel,
cmetcalf, linux-mm, sparclinux, linuxppc-dev
In-Reply-To: <1358247267-18089-1-git-send-email-tangchen@cn.fujitsu.com>
Now we don't free firmware_map_entry which is allocated by bootmem because
there is no way to do so when the system is up. But we can at least remember
the address of that memory and reuse the storage when the memory is added
next time.
This patch introduces a new list map_entries_bootmem to link the map entries
allocated by bootmem when they are removed, and a lock to protect it.
And these entries will be reused when the memory is hot-added again.
The idea is suggestted by Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
drivers/firmware/memmap.c | 103 ++++++++++++++++++++++++++++++++++++++-------
1 files changed, 88 insertions(+), 15 deletions(-)
diff --git a/drivers/firmware/memmap.c b/drivers/firmware/memmap.c
index ae823b4..0710179 100644
--- a/drivers/firmware/memmap.c
+++ b/drivers/firmware/memmap.c
@@ -53,6 +53,9 @@ static ssize_t start_show(struct firmware_map_entry *entry, char *buf);
static ssize_t end_show(struct firmware_map_entry *entry, char *buf);
static ssize_t type_show(struct firmware_map_entry *entry, char *buf);
+static struct firmware_map_entry * __meminit
+firmware_map_find_entry(u64 start, u64 end, const char *type);
+
/*
* Static data -----------------------------------------------------------------
*/
@@ -80,6 +83,19 @@ static const struct sysfs_ops memmap_attr_ops = {
.show = memmap_attr_show,
};
+/* Firmware memory map entries. */
+static LIST_HEAD(map_entries);
+static DEFINE_SPINLOCK(map_entries_lock);
+
+/*
+ * For memory hotplug, there is no way to free memory map entries allocated
+ * by boot mem after the system is up. So when we hot-remove memory whose
+ * map entry is allocated by bootmem, we need to remember the storage and
+ * reuse it when the memory is hot-added again.
+ */
+static LIST_HEAD(map_entries_bootmem);
+static DEFINE_SPINLOCK(map_entries_bootmem_lock);
+
static inline struct firmware_map_entry *
to_memmap_entry(struct kobject *kobj)
@@ -91,9 +107,22 @@ static void release_firmware_map_entry(struct kobject *kobj)
{
struct firmware_map_entry *entry = to_memmap_entry(kobj);
- if (PageReserved(virt_to_page(entry)))
- /* There is no way to free memory allocated from bootmem */
+ if (PageReserved(virt_to_page(entry))) {
+ /*
+ * Remember the storage allocated by bootmem, and reuse it when
+ * the memory is hot-added again. The entry will be added to
+ * map_entries_bootmem here, and deleted from &map_entries in
+ * firmware_map_remove_entry().
+ */
+ if (firmware_map_find_entry(entry->start, entry->end,
+ entry->type)) {
+ spin_lock(&map_entries_bootmem_lock);
+ list_add(&entry->list, &map_entries_bootmem);
+ spin_unlock(&map_entries_bootmem_lock);
+ }
+
return;
+ }
kfree(entry);
}
@@ -108,10 +137,6 @@ static struct kobj_type memmap_ktype = {
* Registration functions ------------------------------------------------------
*/
-/* Firmware memory map entries. */
-static LIST_HEAD(map_entries);
-static DEFINE_SPINLOCK(map_entries_lock);
-
/**
* firmware_map_add_entry() - Does the real work to add a firmware memmap entry.
* @start: Start of the memory range.
@@ -184,23 +209,25 @@ static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry)
}
/*
- * firmware_map_find_entry: Search memmap entry.
+ * firmware_map_find_entry_in_list: Search memmap entry in a given list.
* @start: Start of the memory range.
* @end: End of the memory range (exclusive).
* @type: Type of the memory range.
+ * @list: In which to find the entry.
*
- * This function is to find the memmap entey of a given memory range.
- * The caller must hold map_entries_lock, and must not release the lock
- * until the processing of the returned entry has completed.
+ * This function is to find the memmap entey of a given memory range in a
+ * given list. The caller must hold map_entries_lock, and must not release
+ * the lock until the processing of the returned entry has completed.
*
* Return pointer to the entry to be found on success, or NULL on failure.
*/
static struct firmware_map_entry * __meminit
-firmware_map_find_entry(u64 start, u64 end, const char *type)
+firmware_map_find_entry_in_list(u64 start, u64 end, const char *type,
+ struct list_head *list)
{
struct firmware_map_entry *entry;
- list_for_each_entry(entry, &map_entries, list)
+ list_for_each_entry(entry, list, list)
if ((entry->start == start) && (entry->end == end) &&
(!strcmp(entry->type, type))) {
return entry;
@@ -209,6 +236,42 @@ firmware_map_find_entry(u64 start, u64 end, const char *type)
return NULL;
}
+/*
+ * firmware_map_find_entry: Search memmap entry in map_entries.
+ * @start: Start of the memory range.
+ * @end: End of the memory range (exclusive).
+ * @type: Type of the memory range.
+ *
+ * This function is to find the memmap entey of a given memory range.
+ * The caller must hold map_entries_lock, and must not release the lock
+ * until the processing of the returned entry has completed.
+ *
+ * Return pointer to the entry to be found on success, or NULL on failure.
+ */
+static struct firmware_map_entry * __meminit
+firmware_map_find_entry(u64 start, u64 end, const char *type)
+{
+ return firmware_map_find_entry_in_list(start, end, type, &map_entries);
+}
+
+/*
+ * firmware_map_find_entry_bootmem: Search memmap entry in map_entries_bootmem.
+ * @start: Start of the memory range.
+ * @end: End of the memory range (exclusive).
+ * @type: Type of the memory range.
+ *
+ * This function is similar to firmware_map_find_entry except that it find the
+ * given entry in map_entries_bootmem.
+ *
+ * Return pointer to the entry to be found on success, or NULL on failure.
+ */
+static struct firmware_map_entry * __meminit
+firmware_map_find_entry_bootmem(u64 start, u64 end, const char *type)
+{
+ return firmware_map_find_entry_in_list(start, end, type,
+ &map_entries_bootmem);
+}
+
/**
* firmware_map_add_hotplug() - Adds a firmware mapping entry when we do
* memory hotplug.
@@ -226,9 +289,19 @@ int __meminit firmware_map_add_hotplug(u64 start, u64 end, const char *type)
{
struct firmware_map_entry *entry;
- entry = kzalloc(sizeof(struct firmware_map_entry), GFP_ATOMIC);
- if (!entry)
- return -ENOMEM;
+ entry = firmware_map_find_entry_bootmem(start, end, type);
+ if (!entry) {
+ entry = kzalloc(sizeof(struct firmware_map_entry), GFP_ATOMIC);
+ if (!entry)
+ return -ENOMEM;
+ } else {
+ /* Reuse storage allocated by bootmem. */
+ spin_lock(&map_entries_bootmem_lock);
+ list_del(&entry->list);
+ spin_unlock(&map_entries_bootmem_lock);
+
+ memset(entry, 0, sizeof(*entry));
+ }
firmware_map_add_entry(start, end, type, entry);
/* create the memmap entry */
--
1.7.1
^ permalink raw reply related
* [BUG Fix Patch 4/6] Bug fix: Do not free page split from hugepage one by one.
From: Tang Chen @ 2013-01-15 10:54 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, tangchen, hpa,
linfeng, laijs, mgorman, yinghai, glommer, jiang.liu
Cc: linux-s390, linux-ia64, linux-acpi, linux-sh, x86, linux-kernel,
cmetcalf, linux-mm, sparclinux, linuxppc-dev
In-Reply-To: <1358247267-18089-1-git-send-email-tangchen@cn.fujitsu.com>
When we split a larger page into smaller ones, we should not free them
one by one because only the _count of the first page struct makes sense.
Otherwise, the kernel will panic.
So fulfill the unused small pages with 0xFD, and when the whole larger
page is fulfilled with 0xFD, free the whole larger page.
The call trace is like the following:
[ 1052.819430] ------------[ cut here ]------------
[ 1052.874575] kernel BUG at include/linux/mm.h:278!
[ 1052.930754] invalid opcode: 0000 [#1] SMP
[ 1052.979888] Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables bridge stp llc sunrpc binfmt_misc dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun uinput iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crc32c_intel microcode pcspkr sg i2c_i801 i2c_core lpc_ich mfd_core ioatdma e1000e i7core_edac edac_core igb dca ptp pps_core sd_mod crc_t10dif megaraid_sas mptsas mptscsih mptbase scsi_transport_sas scsi_mod
[ 1053.580111] CPU 0
[ 1053.602026] Pid: 4, comm: kworker/0:0 Tainted: G W 3.8.0-rc2-memory-hotremove+ #3 FUJITSU-SV PRIMEQUEST 1800E/SB
[ 1053.736188] RIP: 0010:[<ffffffff81175bd7>] [<ffffffff81175bd7>] __free_pages+0x37/0x50
[ 1053.831952] RSP: 0018:ffff8807bdcb37f8 EFLAGS: 00010246
[ 1053.895403] RAX: 0000000000000000 RBX: ffff88077c401000 RCX: 000000000000002c
[ 1053.980660] RDX: ffff8807fffd7000 RSI: 0000000000000000 RDI: ffffea001df10040
[ 1054.065917] RBP: ffff8807bdcb37f8 R08: 0000000000000000 R09: 0000000000000000
[ 1054.151178] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
[ 1054.236433] R13: ffffea0040008000 R14: ffffea0040002000 R15: 00003ffffffff000
[ 1054.321691] FS: 0000000000000000(0000) GS:ffff8807c1a00000(0000) knlGS:0000000000000000
[ 1054.418372] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1054.487015] CR2: 00007fbc137ad000 CR3: 0000000001c0c000 CR4: 00000000000007f0
[ 1054.572272] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1054.657533] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1054.742797] Process kworker/0:0 (pid: 4, threadinfo ffff8807bdcb2000, task ffff8807bde18000)
[ 1054.843628] Stack:
[ 1054.867622] ffff8807bdcb3818 ffffffff81175ccf 000000077c401000 ffff880796349008
[ 1054.956421] ffff8807bdcb3848 ffffffff816a16e2 ffffea0040001000 ffff880796349008
[ 1055.045227] ffffea0040008000 ffffea0040002000 ffff8807bdcb38b8 ffffffff816a181c
[ 1055.134033] Call Trace:
[ 1055.163230] [<ffffffff81175ccf>] free_pages+0x5f/0x70
[ 1055.224611] [<ffffffff816a16e2>] free_pagetable+0x7f/0xee
[ 1055.290147] [<ffffffff816a181c>] remove_pte_table+0xcb/0x1cd
[ 1055.358806] [<ffffffff81055bd0>] ? leave_mm+0x50/0x50
[ 1055.420187] [<ffffffff810df55d>] ? trace_hardirqs_on+0xd/0x10
[ 1055.489882] [<ffffffff816a1f8b>] remove_pmd_table+0x191/0x253
[ 1055.559576] [<ffffffff816a261e>] remove_pud_table+0x194/0x24d
[ 1055.629270] [<ffffffff811bbc3f>] ? sparse_remove_one_section+0x2f/0x150
[ 1055.709348] [<ffffffff816a278c>] remove_pagetable+0xb5/0x17c
[ 1055.778002] [<ffffffff81692f28>] vmemmap_free+0x18/0x20
[ 1055.841465] [<ffffffff811bbd15>] sparse_remove_one_section+0x105/0x150
[ 1055.920508] [<ffffffff811c953c>] __remove_pages+0xec/0x110
[ 1055.987087] [<ffffffff81692fa7>] arch_remove_memory+0x77/0xc0
[ 1056.056781] [<ffffffff81694138>] remove_memory+0xb8/0xf0
[ 1056.121284] [<ffffffff814040aa>] acpi_memory_device_remove+0x76/0xbc
[ 1056.198244] [<ffffffff813c1e50>] acpi_device_remove+0x90/0xb2
[ 1056.267941] [<ffffffff8146bf3c>] __device_release_driver+0x7c/0xf0
[ 1056.342824] [<ffffffff8146c0bf>] device_release_driver+0x2f/0x50
[ 1056.415635] [<ffffffff813c3142>] acpi_bus_remove+0x32/0x6d
[ 1056.482215] [<ffffffff813c320e>] acpi_bus_trim+0x91/0x102
[ 1056.547755] [<ffffffff813c3307>] acpi_bus_hot_remove_device+0x88/0x180
[ 1056.626794] [<ffffffff813be152>] acpi_os_execute_deferred+0x27/0x34
[ 1056.702717] [<ffffffff81091c5e>] process_one_work+0x20e/0x5c0
[ 1056.772411] [<ffffffff81091bef>] ? process_one_work+0x19f/0x5c0
[ 1056.844184] [<ffffffff813be12b>] ? acpi_os_wait_events_complete+0x23/0x23
[ 1056.926337] [<ffffffff81093cfe>] worker_thread+0x12e/0x370
[ 1056.992908] [<ffffffff81093bd0>] ? manage_workers+0x180/0x180
[ 1057.062602] [<ffffffff81099e3e>] kthread+0xee/0x100
[ 1057.121913] [<ffffffff810e10b9>] ? __lock_release+0x129/0x190
[ 1057.191609] [<ffffffff81099d50>] ? __init_kthread_worker+0x70/0x70
[ 1057.266494] [<ffffffff816b33ac>] ret_from_fork+0x7c/0xb0
[ 1057.330992] [<ffffffff81099d50>] ? __init_kthread_worker+0x70/0x70
[ 1057.405863] Code: 85 c0 74 27 f0 ff 4f 1c 0f 94 c0 84 c0 74 0a 85 f6 74 11 90 e8 bb e3 ff ff c9 c3 66 0f 1f 84 00 00 00 00 00 e8 1b fe ff ff c9 c3 <0f> 0b 0f 1f 80 00 00 00 00 eb f7 66 66 66 66 66 2e 0f 1f 84 00
[ 1057.638271] RIP [<ffffffff81175bd7>] __free_pages+0x37/0x50
[ 1057.705994] RSP <ffff8807bdcb37f8>
[ 1057.747882] ---[ end trace 0f90e1e054d174f9 ]---
[ 1057.803158] Kernel panic - not syncing: Fatal exception
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
---
arch/x86/mm/init_64.c | 80 +++++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 71 insertions(+), 9 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index e77d312..ff0206b 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -777,7 +777,7 @@ static bool __meminit free_pud_table(pud_t *pud_start, pgd_t *pgd)
static void __meminit
remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
- bool direct)
+ bool direct, bool split)
{
unsigned long next, pages = 0;
pte_t *pte;
@@ -806,14 +806,30 @@ remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
IS_ALIGNED(next, PAGE_SIZE)) {
/*
* Do not free direct mapping pages since they were
- * freed when offlining.
+ * freed when offlining, or simplely not in use.
+ *
+ * Do not free pages split from larger page since only
+ * the _count of the 1st page struct is available.
+ * Free the larger page when it is fulfilled with 0xFD.
*/
- if (!direct)
- free_pagetable(pte_page(*pte), 0);
+ if (!direct) {
+ if (split) {
+ /*
+ * Fill the split 4KB page with 0xFD.
+ * When the whole 2MB page is fulfilled
+ * with 0xFD, it could be freed.
+ */
+ memset((void *)addr, PAGE_INUSE,
+ PAGE_SIZE);
+ } else
+ free_pagetable(pte_page(*pte), 0);
+ }
spin_lock(&init_mm.page_table_lock);
pte_clear(&init_mm, addr, pte);
spin_unlock(&init_mm.page_table_lock);
+
+ /* For non-direct mapping, pages means nothing. */
pages++;
} else {
/*
@@ -824,6 +840,10 @@ remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
*/
memset((void *)addr, PAGE_INUSE, next - addr);
+ /*
+ * If the range is not aligned to PAGE_SIZE, then the
+ * page is definitely not split from larger page.
+ */
page_addr = page_address(pte_page(*pte));
if (!memchr_inv(page_addr, PAGE_INUSE, PAGE_SIZE)) {
if (!direct)
@@ -845,11 +865,13 @@ remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
static void __meminit
remove_pmd_table(pmd_t *pmd_start, unsigned long addr, unsigned long end,
- bool direct)
+ bool direct, bool split)
{
unsigned long pte_phys, next, pages = 0;
pte_t *pte_base;
pmd_t *pmd;
+ void *page_addr;
+ bool split_pmd = split, split_pte = false;
pmd = pmd_start + pmd_index(addr);
for (; addr < end; addr = next, pmd++) {
@@ -861,14 +883,32 @@ remove_pmd_table(pmd_t *pmd_start, unsigned long addr, unsigned long end,
if (pmd_large(*pmd)) {
if (IS_ALIGNED(addr, PMD_SIZE) &&
IS_ALIGNED(next, PMD_SIZE)) {
- if (!direct)
- free_pagetable(pmd_page(*pmd),
+ if (!direct) {
+ if (split_pmd) {
+ /*
+ * Fill the split 2MB page with
+ * 0xFD. When the whole 1GB page
+ * is fulfilled with 0xFD, it
+ * could be freed.
+ */
+ memset((void *)addr, PAGE_INUSE,
+ PMD_SIZE);
+ } else {
+ free_pagetable(pmd_page(*pmd),
get_order(PMD_SIZE));
+ }
+ }
spin_lock(&init_mm.page_table_lock);
pmd_clear(pmd);
spin_unlock(&init_mm.page_table_lock);
+
+ /*
+ * For non-direct mapping, pages means
+ * nothing.
+ */
pages++;
+
continue;
}
@@ -880,6 +920,7 @@ remove_pmd_table(pmd_t *pmd_start, unsigned long addr, unsigned long end,
BUG_ON(!pte_base);
__split_large_page((pte_t *)pmd, addr,
(pte_t *)pte_base);
+ split_pte = true;
spin_lock(&init_mm.page_table_lock);
pmd_populate_kernel(&init_mm, pmd, __va(pte_phys));
@@ -889,7 +930,16 @@ remove_pmd_table(pmd_t *pmd_start, unsigned long addr, unsigned long end,
}
pte_base = (pte_t *)map_low_page((pte_t *)pmd_page_vaddr(*pmd));
- remove_pte_table(pte_base, addr, next, direct);
+ remove_pte_table(pte_base, addr, next, direct, split_pte);
+
+ if (!direct && split_pte) {
+ page_addr = page_address(pmd_page(*pmd));
+ if (!memchr_inv(page_addr, PAGE_INUSE, PMD_SIZE)) {
+ free_pagetable(pmd_page(*pmd),
+ get_order(PMD_SIZE));
+ }
+ }
+
free_pte_table(pte_base, pmd);
unmap_low_page(pte_base);
}
@@ -906,6 +956,8 @@ remove_pud_table(pud_t *pud_start, unsigned long addr, unsigned long end,
unsigned long pmd_phys, next, pages = 0;
pmd_t *pmd_base;
pud_t *pud;
+ void *page_addr;
+ bool split_pmd = false;
pud = pud_start + pud_index(addr);
for (; addr < end; addr = next, pud++) {
@@ -936,6 +988,7 @@ remove_pud_table(pud_t *pud_start, unsigned long addr, unsigned long end,
BUG_ON(!pmd_base);
__split_large_page((pte_t *)pud, addr,
(pte_t *)pmd_base);
+ split_pmd = true;
spin_lock(&init_mm.page_table_lock);
pud_populate(&init_mm, pud, __va(pmd_phys));
@@ -945,7 +998,16 @@ remove_pud_table(pud_t *pud_start, unsigned long addr, unsigned long end,
}
pmd_base = (pmd_t *)map_low_page((pmd_t *)pud_page_vaddr(*pud));
- remove_pmd_table(pmd_base, addr, next, direct);
+ remove_pmd_table(pmd_base, addr, next, direct, split_pmd);
+
+ if (!direct && split_pmd) {
+ page_addr = page_address(pud_page(*pud));
+ if (!memchr_inv(page_addr, PAGE_INUSE, PUD_SIZE)) {
+ free_pagetable(pud_page(*pud),
+ get_order(PUD_SIZE));
+ }
+ }
+
free_pmd_table(pmd_base, pud);
unmap_low_page(pmd_base);
}
--
1.7.1
^ permalink raw reply related
* [BUG Fix Patch 3/6] Bug fix: Do not free direct mapping pages twice.
From: Tang Chen @ 2013-01-15 10:54 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, tangchen, hpa,
linfeng, laijs, mgorman, yinghai, glommer, jiang.liu
Cc: linux-s390, linux-ia64, linux-acpi, linux-sh, x86, linux-kernel,
cmetcalf, linux-mm, sparclinux, linuxppc-dev
In-Reply-To: <1358247267-18089-1-git-send-email-tangchen@cn.fujitsu.com>
Direct mapped pages were freed when they were offlined, or they were
not allocated. So we only need to free vmemmap pages, no need to free
direct mapped pages.
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
arch/x86/mm/init_64.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 368cc3f..e77d312 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -804,6 +804,10 @@ remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
if (IS_ALIGNED(addr, PAGE_SIZE) &&
IS_ALIGNED(next, PAGE_SIZE)) {
+ /*
+ * Do not free direct mapping pages since they were
+ * freed when offlining.
+ */
if (!direct)
free_pagetable(pte_page(*pte), 0);
@@ -819,10 +823,11 @@ remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
* remove the page when it is wholly filled with 0xFD.
*/
memset((void *)addr, PAGE_INUSE, next - addr);
- page_addr = page_address(pte_page(*pte));
+ page_addr = page_address(pte_page(*pte));
if (!memchr_inv(page_addr, PAGE_INUSE, PAGE_SIZE)) {
- free_pagetable(pte_page(*pte), 0);
+ if (!direct)
+ free_pagetable(pte_page(*pte), 0);
spin_lock(&init_mm.page_table_lock);
pte_clear(&init_mm, addr, pte);
--
1.7.1
^ permalink raw reply related
* [BUG Fix Patch 5/6] Bug fix: Fix the wrong comments of map_entries.
From: Tang Chen @ 2013-01-15 10:54 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, tangchen, hpa,
linfeng, laijs, mgorman, yinghai, glommer, jiang.liu
Cc: linux-s390, linux-ia64, linux-acpi, linux-sh, x86, linux-kernel,
cmetcalf, linux-mm, sparclinux, linuxppc-dev
In-Reply-To: <1358247267-18089-1-git-send-email-tangchen@cn.fujitsu.com>
Now we have a map_entries_lock to protect map_entries list.
So we need to update the comments.
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
drivers/firmware/memmap.c | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/drivers/firmware/memmap.c b/drivers/firmware/memmap.c
index 940c4e9..ae823b4 100644
--- a/drivers/firmware/memmap.c
+++ b/drivers/firmware/memmap.c
@@ -108,11 +108,7 @@ static struct kobj_type memmap_ktype = {
* Registration functions ------------------------------------------------------
*/
-/*
- * Firmware memory map entries. No locking is needed because the
- * firmware_map_add() and firmware_map_add_early() functions are called
- * in firmware initialisation code in one single thread of execution.
- */
+/* Firmware memory map entries. */
static LIST_HEAD(map_entries);
static DEFINE_SPINLOCK(map_entries_lock);
--
1.7.1
^ permalink raw reply related
* [BUG Fix Patch 1/6] Bug fix: Hold spinlock across find|remove /sys/firmware/memmap/X operation.
From: Tang Chen @ 2013-01-15 10:54 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, tangchen, hpa,
linfeng, laijs, mgorman, yinghai, glommer, jiang.liu
Cc: linux-s390, linux-ia64, linux-acpi, linux-sh, x86, linux-kernel,
cmetcalf, linux-mm, sparclinux, linuxppc-dev
In-Reply-To: <1358247267-18089-1-git-send-email-tangchen@cn.fujitsu.com>
It is unsafe to return an entry pointer and release the map_entries_lock. So we should
not hold the map_entries_lock separately in firmware_map_find_entry() and
firmware_map_remove_entry(). Hold the map_entries_lock across find and remove
/sys/firmware/memmap/X operation.
And also, users of these two functions need to be careful to hold the lock when using
these two functions.
The suggestion is from Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
drivers/firmware/memmap.c | 25 +++++++++++++++++--------
1 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/firmware/memmap.c b/drivers/firmware/memmap.c
index 4211da5..940c4e9 100644
--- a/drivers/firmware/memmap.c
+++ b/drivers/firmware/memmap.c
@@ -150,12 +150,12 @@ static int firmware_map_add_entry(u64 start, u64 end,
* firmware_map_remove_entry() - Does the real work to remove a firmware
* memmap entry.
* @entry: removed entry.
+ *
+ * The caller must hold map_entries_lock, and release it properly.
**/
static inline void firmware_map_remove_entry(struct firmware_map_entry *entry)
{
- spin_lock(&map_entries_lock);
list_del(&entry->list);
- spin_unlock(&map_entries_lock);
}
/*
@@ -188,23 +188,28 @@ static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry)
}
/*
- * Search memmap entry
+ * firmware_map_find_entry: Search memmap entry.
+ * @start: Start of the memory range.
+ * @end: End of the memory range (exclusive).
+ * @type: Type of the memory range.
+ *
+ * This function is to find the memmap entey of a given memory range.
+ * The caller must hold map_entries_lock, and must not release the lock
+ * until the processing of the returned entry has completed.
+ *
+ * Return pointer to the entry to be found on success, or NULL on failure.
*/
-
static struct firmware_map_entry * __meminit
firmware_map_find_entry(u64 start, u64 end, const char *type)
{
struct firmware_map_entry *entry;
- spin_lock(&map_entries_lock);
list_for_each_entry(entry, &map_entries, list)
if ((entry->start == start) && (entry->end == end) &&
(!strcmp(entry->type, type))) {
- spin_unlock(&map_entries_lock);
return entry;
}
- spin_unlock(&map_entries_lock);
return NULL;
}
@@ -274,11 +279,15 @@ int __meminit firmware_map_remove(u64 start, u64 end, const char *type)
{
struct firmware_map_entry *entry;
+ spin_lock(&map_entries_lock);
entry = firmware_map_find_entry(start, end - 1, type);
- if (!entry)
+ if (!entry) {
+ spin_unlock(&map_entries_lock);
return -EINVAL;
+ }
firmware_map_remove_entry(entry);
+ spin_unlock(&map_entries_lock);
/* remove the memmap entry */
remove_sysfs_fw_map_entry(entry);
--
1.7.1
^ permalink raw reply related
* [BUG Fix Patch 2/6] Bug fix: Do not calculate direct mapping pages when freeing vmemmap pagetables.
From: Tang Chen @ 2013-01-15 10:54 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, tangchen, hpa,
linfeng, laijs, mgorman, yinghai, glommer, jiang.liu
Cc: linux-s390, linux-ia64, linux-acpi, linux-sh, x86, linux-kernel,
cmetcalf, linux-mm, sparclinux, linuxppc-dev
In-Reply-To: <1358247267-18089-1-git-send-email-tangchen@cn.fujitsu.com>
We only need to update direct_pages_count[level] when we freeing direct mapped
pagetables.
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
arch/x86/mm/init_64.c | 17 +++++++----------
1 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index e829113..368cc3f 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -804,14 +804,13 @@ remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
if (IS_ALIGNED(addr, PAGE_SIZE) &&
IS_ALIGNED(next, PAGE_SIZE)) {
- if (!direct) {
+ if (!direct)
free_pagetable(pte_page(*pte), 0);
- pages++;
- }
spin_lock(&init_mm.page_table_lock);
pte_clear(&init_mm, addr, pte);
spin_unlock(&init_mm.page_table_lock);
+ pages++;
} else {
/*
* If we are not removing the whole page, it means
@@ -824,11 +823,11 @@ remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
if (!memchr_inv(page_addr, PAGE_INUSE, PAGE_SIZE)) {
free_pagetable(pte_page(*pte), 0);
- pages++;
spin_lock(&init_mm.page_table_lock);
pte_clear(&init_mm, addr, pte);
spin_unlock(&init_mm.page_table_lock);
+ pages++;
}
}
}
@@ -857,15 +856,14 @@ remove_pmd_table(pmd_t *pmd_start, unsigned long addr, unsigned long end,
if (pmd_large(*pmd)) {
if (IS_ALIGNED(addr, PMD_SIZE) &&
IS_ALIGNED(next, PMD_SIZE)) {
- if (!direct) {
+ if (!direct)
free_pagetable(pmd_page(*pmd),
get_order(PMD_SIZE));
- pages++;
- }
spin_lock(&init_mm.page_table_lock);
pmd_clear(pmd);
spin_unlock(&init_mm.page_table_lock);
+ pages++;
continue;
}
@@ -914,15 +912,14 @@ remove_pud_table(pud_t *pud_start, unsigned long addr, unsigned long end,
if (pud_large(*pud)) {
if (IS_ALIGNED(addr, PUD_SIZE) &&
IS_ALIGNED(next, PUD_SIZE)) {
- if (!direct) {
+ if (!direct)
free_pagetable(pud_page(*pud),
get_order(PUD_SIZE));
- pages++;
- }
spin_lock(&init_mm.page_table_lock);
pud_clear(pud);
spin_unlock(&init_mm.page_table_lock);
+ pages++;
continue;
}
--
1.7.1
^ permalink raw reply related
* [BUG Fix Patch 0/6] Bug fix for physical memory hot-remove.
From: Tang Chen @ 2013-01-15 10:54 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, tangchen, hpa,
linfeng, laijs, mgorman, yinghai, glommer, jiang.liu
Cc: linux-s390, linux-ia64, linux-acpi, linux-sh, x86, linux-kernel,
cmetcalf, linux-mm, sparclinux, linuxppc-dev
Hi Andrew,
Here are some bug fix patches for physical hot-remove patches.
And there are some new ones reported by others, I'll fix them soon.
Thanks. :)
Tang Chen (6):
Bug fix: Hold spinlock across find|remove /sys/firmware/memmap/X
operation.
Bug fix: Do not calculate direct mapping pages when freeing vmemmap
pagetables.
Bug fix: Do not free direct mapping pages twice.
Bug fix: Do not free page split from hugepage one by one.
Bug fix: Fix the wrong comments of map_entries.
Bug fix: Reuse the storage of /sys/firmware/memmap/X/ allocated by
bootmem.
arch/x86/mm/init_64.c | 92 ++++++++++++++++++++++++++++-----
drivers/firmware/memmap.c | 124 ++++++++++++++++++++++++++++++++++++--------
2 files changed, 179 insertions(+), 37 deletions(-)
^ permalink raw reply
* [RFC][v0][PATCH 1/1] ppc64: ignore interrupts while offline
From: Tiejun Chen @ 2013-01-15 10:31 UTC (permalink / raw)
To: benh, galak; +Cc: linuxppc-dev, linux-kernel
With lazy interrupt, some implementations of hotplug will
get some interrupts even while offline, just ignore these.
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
arch/powerpc/kernel/irq.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 4f97fe3..dbca574 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -144,6 +144,12 @@ notrace unsigned int __check_irq_replay(void)
*/
unsigned char happened = local_paca->irq_happened;
+ /* Some implementations of hotplug will get some interrupts while
+ * offline, just ignore these.
+ */
+ if (cpu_is_offline(smp_processor_id()))
+ return 0;
+
/* Clear bit 0 which we wouldn't clear otherwise */
local_paca->irq_happened &= ~PACA_IRQ_HARD_DIS;
--
1.7.9.5
^ permalink raw reply related
* Re: device tree entry for tsi148
From: Martyn Welch @ 2013-01-15 9:32 UTC (permalink / raw)
To: ternaryd; +Cc: linuxppc-dev
In-Reply-To: <20130115091119.41e2a0f9@vesta>
On 15/01/13 08:11, ternaryd wrote:
> Hi,
>
> I'm trying to install linux on an e500v2 board with the tsi148
> VME-Bridge, but got stuck. Now it seems that I need to include
> information regarding this bridge into the .dts-file, but can't figure
> out how. Maybe somebody on this list could post the tsi148-specific
> part of a device tree, which I could use as a guide line?
>
You don't need to include anything about the device it's self, but there will
need to be an entry in the DTS for PCI. Which SOC are you using?
Can you provide your boot log?
Martyn
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.welch@ge.com | VAT:GB 927559189
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox