Re: [PATCH v3 3/4] sta2x11_vip: convert to videobuf2 and control framework
Thank you Mauro for the good explanation Yeah, there are many changes there that justifies adding you at its authorship, and that's ok. Also, anyone saying the size of your patch will recognize your and ST efforts to improve the driver. However, as some parts of the code were preserved, dropping the old authors doesn't sound right (and can even be illegal, in the light of the GPL license). It would be ok, though, if you would be changing it to something like: Copyright (c) 2010 by ... or Original driver from ... Ok, I understand. I will write something like this. * Copyright (C) 2012 ST Microelectronics * author: Federico Vaga federico.v...@gmail.com * Copyright (C) 2010 WindRiver Systems, Inc. * authors: Andreas Kies andreas.k...@windriver.com * Vlad Lungu vlad.lu...@windriver.com The only way of not preserving the original authors here were if you start from scratch, without looking at the original code (and you can somehow, be able to proof it), otherwise, the code will be fit as a derivative work, in the light of GPL, and should be preserving the original authorship. Something started from scratch like that will hardly be accepted upstream, as regressions will likely be introduced, and previously supported hardware/features may be lost in the process. I understand Of course the original author can abdicate to his rights of keeping his name on it. Yet, even if he opt/accept to not keep his name explicitly there, his copyrights are preserved, with the help of the git history. That's said, no single kernel developer/company has full copyrights on any part of the Kernel, as their code are based on someone else's work. For example, all Kernel drivers depend on drivers/base, with in turn, depends on memory management, generic helper functions, arch code, etc. yeah I know :) So, IMHO, there's not much point on dropping authorship messages. So the MODULE_AUTHOR will be Windriver forever until they drop authorship? Also if in the next future 0 windriver lines will be in the code? (general talking, not about this driver) If I do git blame on a driver with MODULE_AUTHOR(Mr. X); but only the MODULE_AUTHOR line is from Mr X; there is not an automatically system which remove the MODULE_AUTHOR? Ok, probably it was the original author of the code and the comment header with the copyright history gives to Mr X all the honours, but there is nothing from him in the code. It is not better to remove MODULE_AUTHOR or replace it with who wrotes most of the code? I know that this is not the best place to talk about this, just a little curiosity -- Federico Vaga -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf test: Add a test case for hists__{match,link}
As they are used from diff and event group report, add a test case to
verify their behaviors.
In this test I made a fake machine and two evsel. Each evsel got 10
samples (so hist entries) - 5 are common and the rests are not. So
after hists__match() both of them will have 5 entries with pair set.
And the second evsel has a collapsed entry so that the total number is
9 - I made it in order to simulate more realistic case. Thus after
hists__link the first entry will have 14 entries - 5 are common (w/
pair), 5 are unmatch (w/o pair) and 4 are dummy (w/ pair). And the
second entry will have 9 entries all have its pair.
Cc: Jiri Olsa jo...@redhat.com
Cc: Stephane Eranian eran...@google.com
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/Makefile | 1 +
tools/perf/tests/builtin-test.c | 4 +
tools/perf/tests/hists_link.c | 502
tools/perf/tests/tests.h| 1 +
tools/perf/util/machine.h | 1 +
tools/perf/util/session.c | 2 +-
6 files changed, 510 insertions(+), 1 deletion(-)
create mode 100644 tools/perf/tests/hists_link.c
diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 75785bb98c30..3628065cda20 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -460,6 +460,7 @@ LIB_OBJS += $(OUTPUT)tests/evsel-roundtrip-name.o
LIB_OBJS += $(OUTPUT)tests/evsel-tp-sched.o
LIB_OBJS += $(OUTPUT)tests/pmu.o
LIB_OBJS += $(OUTPUT)tests/util.o
+LIB_OBJS += $(OUTPUT)tests/hists_link.o
BUILTIN_OBJS += $(OUTPUT)builtin-annotate.o
BUILTIN_OBJS += $(OUTPUT)builtin-bench.o
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index 186f67535494..479d10484a74 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -69,6 +69,10 @@ static struct test {
.func = test__attr,
},
{
+ .desc = Test matching and linking mutliple hists,
+ .func = test__hists_link,
+ },
+ {
.func = NULL,
},
};
diff --git a/tools/perf/tests/hists_link.c b/tools/perf/tests/hists_link.c
new file mode 100644
index ..0f1aae3b8a99
--- /dev/null
+++ b/tools/perf/tests/hists_link.c
@@ -0,0 +1,502 @@
+#include perf.h
+#include tests.h
+#include debug.h
+#include symbol.h
+#include sort.h
+#include evsel.h
+#include evlist.h
+#include machine.h
+#include thread.h
+#include parse-events.h
+
+static struct {
+ u32 pid;
+ const char *comm;
+} fake_threads[] = {
+ { 100, perf },
+ { 200, perf },
+ { 300, bash },
+};
+
+static struct {
+ u32 pid;
+ u64 start;
+ const char *filename;
+} fake_mmap_info[] = {
+ { 100, 0x4, perf },
+ { 100, 0x5, libc },
+ { 100, 0xf, [kernel] },
+ { 200, 0x4, perf },
+ { 200, 0x5, libc },
+ { 200, 0xf, [kernel] },
+ { 300, 0x4, bash },
+ { 300, 0x5, libc },
+ { 300, 0xf, [kernel] },
+};
+
+struct fake_sym {
+ u64 start;
+ u64 length;
+ const char *name;
+};
+
+static struct fake_sym perf_syms[] = {
+ { 700, 100, main },
+ { 800, 100, run_command },
+ { 900, 100, cmd_record },
+};
+
+static struct fake_sym bash_syms[] = {
+ { 700, 100, main },
+ { 800, 100, xmalloc },
+ { 900, 100, xfree },
+};
+
+static struct fake_sym libc_syms[] = {
+ { 700, 100, malloc },
+ { 800, 100, free },
+ { 900, 100, realloc },
+};
+
+static struct fake_sym kernel_syms[] = {
+ { 700, 100, schedule },
+ { 800, 100, page_fault },
+ { 900, 100, sys_perf_event_open },
+};
+
+static struct {
+ const char *dso_name;
+ struct fake_sym *syms;
+ size_t nr_syms;
+} fake_symbols[] = {
+ { perf, perf_syms, ARRAY_SIZE(perf_syms) },
+ { bash, bash_syms, ARRAY_SIZE(bash_syms) },
+ { libc, libc_syms, ARRAY_SIZE(libc_syms) },
+ { [kernel], kernel_syms, ARRAY_SIZE(kernel_syms) },
+};
+
+static struct machine *setup_fake_machine(void)
+{
+ struct rb_root machine_root = RB_ROOT;
+ struct machine *machine;
+ size_t i;
+
+ machine = machines__findnew(machine_root, HOST_KERNEL_ID);
+ if (machine == NULL) {
+ pr_debug(Not enough memory for machine setup\n);
+ return NULL;
+ }
+
+ for (i = 0; i ARRAY_SIZE(fake_threads); i++) {
+ struct thread *thread;
+
+ thread = machine__findnew_thread(machine, fake_threads[i].pid);
+ if (thread == NULL)
+ goto out;
+
+ thread__set_comm(thread, fake_threads[i].comm);
+ }
+
+ for (i = 0; i ARRAY_SIZE(fake_mmap_info); i++) {
+ union perf_event fake_mmap_event = {
+ .mmap = {
+ .header = { .misc = PERF_RECORD_MISC_USER, },
+ .pid = fake_mmap_info[i].pid,
Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x
On Wed, Dec 05, 2012 at 01:03:14PM +0100, Daniel Vetter wrote: On Wed, Dec 5, 2012 at 12:47 PM, Terje Bergström tbergst...@nvidia.com wrote: You're right in that binding to a sub-device is not a nice way. DRM framework just needs a struct device to bind to. exynos seems to solve this by introducing a virtual device and bind to that. I'm not sure if this is the best way, but worth considering? Note that I'm not too happy about the fact that drm wants a struct device to register a drm device. This all made a lot of sense back in the days when drm drivers this this fancy shadow attaching to allow drm to use a driver for rendering cooperatively with a fbdev driver. Today there's not much reason for that anymore imo, and I'd welcome patches to allow drivers to simply register a drm device (and remove all the newer registration functions for usb/platform/whatever drivers, moving the device handling into drivers). Note that it's a bit work, since not-really-required abstraction (which was useful back when the drm drivers have been shared with *BSD, but pointless now) like the drm irq support needs to be moved away to a pci-dev legacy thing only - it doesn't really buy a kms driver anything abovebeyond calling request_irq() itself. So feel free to burn this down, I'll be happy to carry wood to the pyre in the from of reviews (not much time for more right now ...). This wouldn't solve the problem at hand, though, since we'd still need to instantiate the DRM driver somehow. Currently this is triggered ultimately by the host1x's .probe(). Maybe something more elaborate could help, though. Suppose we add functionality to DRM to instantiate a DRM device. We could call such a function from the host1x driver to add a device which the tegra-drm driver could bind to. This would entail something like a small bus implementation for DRM that would allow matching DRM devices to DRM drivers much like the platform or PCI busses. This could automatically take care of registering the DRM device with the proper parent so that host1x clients can lookup the host1x via dev-parent. Perhaps something as simple as int drm_device_register(struct device *parent, const char *name, int id); could work. Or something more elaborate such as allocating a device with struct drm_device *drm_device_alloc(const char *name, int id); paired with int drm_device_register(struct drm_device *dev); would be more flexible in that drivers could modify the DRM device in between the two calls. Thierry pgpilsepJtics.pgp Description: PGP signature
Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x
On Wed, Dec 5, 2012 at 1:22 PM, Thierry Reding thierry.red...@avionic-design.de wrote: Maybe something more elaborate could help, though. Suppose we add functionality to DRM to instantiate a DRM device. We could call such a function from the host1x driver to add a device which the tegra-drm driver could bind to. This would entail something like a small bus implementation for DRM that would allow matching DRM devices to DRM drivers much like the platform or PCI busses. This could automatically take care of registering the DRM device with the proper parent so that host1x clients can lookup the host1x via dev-parent. Perhaps something as simple as int drm_device_register(struct device *parent, const char *name, int id); could work. Or something more elaborate such as allocating a device with struct drm_device *drm_device_alloc(const char *name, int id); paired with int drm_device_register(struct drm_device *dev); would be more flexible in that drivers could modify the DRM device in between the two calls. Imo that's worse, since now drm manages even more of the driver-hw binding process. In my dream world the drm driver just registers a normal driver at module load time directly with whatever bus it's interested in, and then, from it the bus' -probe callback setups up the entire driver, calling down into drm to setup up interfaces to userspace (dev node, sysfs, and whatever is required to implement the ioctls) and uses the various helper libraries provided. So host1x providing a virtual device that tegradrm can match sounds much better (if that helps in decoupling from host1x). Or simply call the tegradrm setup from host1x directly, creating a depency on the tegradrm module. When trying to unload host1x it can then also call down into tegradrm to tear down the drm device. Afterwards you should be able to unload tegradrm without fuzz. And if the hard dependcy is an issue for other host1x clients this setup/teardown could be wrapped into an #ifdef CONFIG_TEGRADRM. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)
Hi! Agreed. If I understand you correctly though, your approach is specific to a particular hardware implementation (Zynq) on the user interface layer, which I think is exactly what we should avoid. Obviously, there is always a driver involved that is specific to the IP block you load into an FPGA at runtime, and that is ok. The two parts that I think we should agree on are: The approach I am taking is not Zynq specific. The only Zynq specific bits will be range checking data from the device tree to make sure the user is mapping address space that is used by the FPGA and a similar validation of the IRQ numbers. I have not looked at the Altera part closely, but I suspect their fpga/processor interface may use similar concepts. So... the arch may be called socfpga, but I don't think we managed to merge actual fpga parts, yet ;-). In fact, I'm not sure if I actually seen those... Dinh should know more about status there. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] MODSIGN: Avoid using .incbin in C source
Takashi Iwai ti...@suse.de wrote: From: Takashi Iwai ti...@suse.de Subject: [PATCH v2] MODSIGN: Avoid using .incbin in C source Using the asm .incbin statement in C sources breaks any gcc wrapper which assumes that preprocessed C source is self-contained. Use a separate .S file to include the siging key and certificate. Tested-by: Michal Marek mma...@suse.cz Signed-off-by: Takashi Iwai ti...@suse.de Acked-by: David Howells dhowe...@redhat.com +#define GLOBAL(name) \ + .globl ASM_SYMBOL(name);\ + ASM_SYMBOL(name): This should perhaps be moved into a global header. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 01/10] CPU hotplug: Introduce stable cpu online mask, for atomic hotplug readers
On 12/05/2012 03:40 AM, Andrew Morton wrote:
On Tue, 04 Dec 2012 14:23:41 +0530
Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote:
From: Michael Wang wang...@linux.vnet.ibm.com
There are places where preempt_disable() is used to prevent any CPU from
going offline during the critical section. Let us call them as atomic
hotplug readers (atomic because they run in atomic contexts).
Often, these atomic hotplug readers have a simple need : they want the cpu
online mask that they work with (inside their critical section), to be
stable, i.e., it should be guaranteed that CPUs in that mask won't go
offline during the critical section. An important point here is that they
don't really care if such a stable mask is a subset of the actual
cpu_online_mask.
The intent of this patch is to provide such a stable cpu online mask
for that class of atomic hotplug readers.
[...]
...
@@ -705,12 +707,15 @@ extern const DECLARE_BITMAP(cpu_all_bits, NR_CPUS);
#define for_each_possible_cpu(cpu) for_each_cpu((cpu), cpu_possible_mask)
#define for_each_online_cpu(cpu) for_each_cpu((cpu), cpu_online_mask)
+#define for_each_online_cpu_stable(cpu)
\
+for_each_cpu((cpu), cpu_online_stable_mask)
#define for_each_present_cpu(cpu) for_each_cpu((cpu), cpu_present_mask)
/* Wrappers for arch boot code to manipulate normally-constant masks */
void set_cpu_possible(unsigned int cpu, bool possible);
void set_cpu_present(unsigned int cpu, bool present);
void set_cpu_online(unsigned int cpu, bool online);
+void set_cpu_online_stable(unsigned int cpu, bool online);
The naming is inconsistent. This is cpu_online_stable, but
for_each_online_cpu_stable() is online_cpu_stable. Can we make
everything the same?
I've actually gotten rid of the cpu_online_stable_mask in my new version
(which I'll post shortly), based on Tejun's suggestion.
void set_cpu_active(unsigned int cpu, bool active);
void init_cpu_present(const struct cpumask *src);
void init_cpu_possible(const struct cpumask *src);
...
+void get_online_cpus_stable_atomic(void)
+{
+preempt_disable();
+this_cpu_inc(hotplug_reader_refcount);
+
+/*
+ * Prevent reordering of writes to hotplug_reader_refcount and
+ * reads from cpu_online_stable_mask.
+ */
+smp_mb();
+}
+EXPORT_SYMBOL_GPL(get_online_cpus_stable_atomic);
+
+void put_online_cpus_stable_atomic(void)
+{
+/*
+ * Prevent reordering of reads from cpu_online_stable_mask and
+ * writes to hotplug_reader_refcount.
+ */
+smp_mb();
+this_cpu_dec(hotplug_reader_refcount);
+preempt_enable();
+}
+EXPORT_SYMBOL_GPL(put_online_cpus_stable_atomic);
+
static struct {
struct task_struct *active_writer;
struct mutex lock; /* Synchronizes accesses to refcount, */
@@ -237,6 +304,44 @@ static inline void check_for_tasks(int cpu)
write_unlock_irq(tasklist_lock);
}
+/*
+ * We want all atomic hotplug readers to refer to the new value of
+ * cpu_online_stable_mask. So wait for the existing atomic hotplug readers
+ * to complete. Any new atomic hotplug readers will see the updated mask
+ * and hence pose no problems.
+ */
+static void sync_hotplug_readers(void)
+{
+unsigned int cpu;
+
+for_each_online_cpu(cpu) {
+while (per_cpu(hotplug_reader_refcount, cpu))
+cpu_relax();
+}
+}
That all looks solid to me.
Actually it isn't fully correct. For example, consider a reader such as this:
get_online_cpus_atomic_stable();
for_each_online_cpu_stable(cpu)
do_operation_X();
for_each_online_cpu_stable(cpu)
undo_operation_X();
put_online_cpus_atomic_stable();
Here, the stable mask is supposed to remain *unchanged* throughout the
entire duration of get/put_online_cpus_stable_atomic(). However, since the
hotplug writer updates the stable online mask without waiting for anything,
the reader can see updates to the stable mask *in-between* his critical section!
So he can end up doing operation_X() on CPUs 1, 2 and 3 and undoing the
operation
on only CPUs 1 and 2, for example, because CPU 3 was removed from the stable
mask in the meantime, by the hotplug writer!
IOW, it actually breaks the fundamental guarantee that we set out to provide
in the first place! Of course, the usecase I gave above is hypothetical, but
it _is_ valid and important nevertheless, IMHO.
Anyway, the new version (which gets rid of the extra cpumask) won't get
into such issues. I actually have a version of the extra cpumask patchset
that fixes this particular issue using rwlocks (like Michael mentioned), but
I won't post it because IMHO it is much superior to provide the necessary
synchronization without using such extra cpumasks at all.
+/*
+ * We are serious about taking this CPU down. So clear the CPU from the
+ * stable online mask.
+ */
+static void
Re: [RFC PATCH 02/10] smp, cpu hotplug: Fix smp_call_function_*() to prevent CPU offline properly
On 12/05/2012 03:47 AM, Andrew Morton wrote:
On Tue, 04 Dec 2012 14:24:28 +0530
Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote:
From: Michael Wang wang...@linux.vnet.ibm.com
With stop_machine() gone from the CPU offline path, we can't depend on
preempt_disable() to prevent CPUs from going offline from under us.
Use the get/put_online_cpus_stable_atomic() APIs to prevent CPUs from going
offline, while invoking from atomic context.
...
*/
-this_cpu = get_cpu();
+get_online_cpus_stable_atomic();
+this_cpu = smp_processor_id();
I wonder if get_online_cpus_stable_atomic() should return the local CPU
ID. Just as a little convenience thing. Time will tell.
With the new version which doesn't use extra cpumasks, we won't have to
bother about this..
/*
* Can deadlock when called with interrupts disabled.
...
@@ -380,15 +383,15 @@ int smp_call_function_any(const struct cpumask *mask,
nodemask = cpumask_of_node(cpu_to_node(cpu));
for (cpu = cpumask_first_and(nodemask, mask); cpu nr_cpu_ids;
cpu = cpumask_next_and(cpu, nodemask, mask)) {
-if (cpu_online(cpu))
+if (cpu_online_stable(cpu))
goto call;
}
/* Any online will do: smp_call_function_single handles nr_cpu_ids. */
-cpu = cpumask_any_and(mask, cpu_online_mask);
+cpu = cpumask_any_and(mask, cpu_online_stable_mask);
call:
ret = smp_call_function_single(cpu, func, info, wait);
-put_cpu();
+put_online_cpus_stable_atomic();
return ret;
}
EXPORT_SYMBOL_GPL(smp_call_function_any);
So smp_call_function_any() has no synchronization against CPUs coming
online. Hence callers of smp_call_function_any() are responsible for
ensuring that CPUs which are concurrently coming online will adopt the
required state?
Yes.
I guess that has always been the case...
Right.
Regards,
Srivatsa S. Bhat
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI / PM: Fix header of acpi_dev_pm_detach() in acpi.h
On Wed, Dec 05, 2012 at 12:08:12PM +0100, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
The header of acpi_dev_pm_detach() in include/linux/acpi.h has an
incorrect return type, which should be void. Fix that.
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
Reviewed-by: Mika Westerberg mika.westerb...@linux.intel.com
---
include/linux/acpi.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/include/linux/acpi.h
===
--- linux.orig/include/linux/acpi.h
+++ linux/include/linux/acpi.h
@@ -506,7 +506,7 @@ static inline int acpi_subsys_resume_ear
#if defined(CONFIG_ACPI) defined(CONFIG_PM)
int acpi_dev_pm_attach(struct device *dev, bool power_on);
-int acpi_dev_pm_detach(struct device *dev, bool power_off);
+void acpi_dev_pm_detach(struct device *dev, bool power_off);
#else
static inline int acpi_dev_pm_attach(struct device *dev, bool power_on)
{
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v3 1/3] mtd: nand: omap2: Update nerrors using ecc.strength
On Wed, Dec 05, 2012 at 17:33:37, Nori, Sekhar wrote:
Hi Avinash,
On 11/29/2012 5:16 PM, Philip, Avinash wrote:
Update number of errors using nand ecc strength.
Also add macro definitions BCH8_ERROR_MAX BCH4_ERROR_MAX
Can you please describe why the original method of setting nerrors was
incorrect? Was it causing any issues in any particular configuration?
It affects the reusability of the code. For example BCH8 with AM335x RBL
compatibility requires 14 bytes instead of 13 byte. So setting nerrors
with
nerrors = (info-nand.ecc.bytes == 13) ? 8 : 4;
will break am335x RBL compatibility.
Mentioning this will help maintainers assign priority to your patch. If
this is a real bug affecting existing platforms, then there is a chance
this patch can get into v3.7 (or at least into v3.8-rc1).
Like Peter who commented on this before, I am not a fan of using macros
for self-describing constants - especially when you end up using the
same numbers inside the macro name itself. No need to resend any thing
just for this, you can wait to see if the maintainers are okay with it.
Yes I agree. But the same constants are used in multiple places here.
So usage of macro helps in readability code debugging.
Thanks
Avinash
Thanks,
Sekhar
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
:100644 100644 359293e... 7e61dac... M drivers/mtd/nand/omap2.c
drivers/mtd/nand/omap2.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 359293e..7e61dac 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -118,6 +118,9 @@
#define OMAP24XX_DMA_GPMC 4
+#define BCH8_MAX_ERROR 8 /* upto 8 bit correctable */
+#define BCH4_MAX_ERROR 4 /* upto 4 bit correctable */
+
/* oob info generated runtime depending on ecc algorithm and layout
selected */
static struct nand_ecclayout omap_oobinfo;
/* Define some generic bad / good block scan pattern which are used
@@ -1042,7 +1045,7 @@ static void omap3_enable_hwecc_bch(struct mtd_info
*mtd, int mode)
struct nand_chip *chip = mtd-priv;
u32 val;
- nerrors = (info-nand.ecc.bytes == 13) ? 8 : 4;
+ nerrors = info-nand.ecc.strength;
dev_width = (chip-options NAND_BUSWIDTH_16) ? 1 : 0;
nsectors = 1;
/*
@@ -1219,13 +1222,14 @@ static int omap3_init_bch(struct mtd_info *mtd, int
ecc_opt)
struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
mtd);
#ifdef CONFIG_MTD_NAND_OMAP_BCH8
- const int hw_errors = 8;
+ const int hw_errors = BCH8_MAX_ERROR;
#else
- const int hw_errors = 4;
+ const int hw_errors = BCH4_MAX_ERROR;
#endif
info-bch = NULL;
- max_errors = (ecc_opt == OMAP_ECC_BCH8_CODE_HW) ? 8 : 4;
+ max_errors = (ecc_opt == OMAP_ECC_BCH8_CODE_HW) ?
+ BCH8_MAX_ERROR : BCH4_MAX_ERROR;
if (max_errors != hw_errors) {
pr_err(cannot configure %d-bit BCH ecc, only %d-bit supported,
max_errors, hw_errors);
Re: [RFC PATCH 02/10] smp, cpu hotplug: Fix smp_call_function_*() to prevent CPU offline properly
On 12/05/2012 05:09 AM, Rusty Russell wrote: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com writes: From: Michael Wang wang...@linux.vnet.ibm.com With stop_machine() gone from the CPU offline path, we can't depend on preempt_disable() to prevent CPUs from going offline from under us. Minor gripe: I'd prefer this paragraph to use the future rather than past tense, like: Once stop_machine() is gone ... we won't be able to depend. Fixed in the new version. Since you're not supposed to use the _stable() accessors without calling get_online_cpus_stable_atomic(), why not have get_online_cpus_stable_atomic() return a pointer to the stable cpumask? (Which is otherwise static, at least for debug). We don't have to worry about this now because the new version doesn't use stable cpumask. Might make the patches messier though... Oh, and I'd love to see actual benchmarks to make sure we've actually fixed a problem with this ;) Of course :-) They will follow, once we have a proper implementation that we are happy with :-) Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] videobuf2-dma-streaming: new videobuf2 memory allocator
On Tuesday 04 December 2012 14:04:22 Mauro Carvalho Chehab wrote: Em 24-09-2012 09:44, Marek Szyprowski escreveu: Hello, On Monday, September 24, 2012 12:59 PM Federico Vaga wrote: The DMA streaming allocator is similar to the DMA contig but it use the DMA streaming interface (dma_map_single, dma_unmap_single). The allocator allocates buffers and immediately map the memory for DMA transfer. For each buffer prepare/finish it does a DMA synchronization. Hmm.. the explanation didn't convince me, e. g.: 1) why is it needed; This allocator is needed because some device (like STA2X11 VIP) cannot work with DMA sg or DMA coherent. Some other device (like the one used by Jonathan when he proposes vb2-dma-nc allocator) can obtain much better performance with DMA streaming than coherent. 2) why vb2-dma-config can't be patched to use dma_map_single (eventually using a different vb2_io_modes bit?); I did not modify vb2-dma-contig because I was thinking that each DMA memory allocator should reflect a DMA API. 3) what are the usecases for it. Could you please detail it? Without that, one that would be needing to write a driver will have serious doubts about what would be the right driver for its usage. Also, please document it at the driver itself. I did not write all this details because the reasons to use vb2-dma-contig, vb2-dma-sg or vb2-dma-streaming are the same reasons because someone choose SG, coherent or streaming API. This is already documented in the DMA-*.txt files, so I did not rewrite it to avoid duplication. -- Federico Vaga -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Alter steal time reporting in KVM
I am deeply sorry. I was busy first time I read this, so I postponed answering and ended up forgetting. Sorry include/linux/sched.h: unsigned long long run_delay; /* time spent waiting on a runqueue */ So if you are out of the runqueue, you won't get steal time accounted, and then I truly fail to understand what you are doing. So I looked at something like this in the past. To make sure things haven't changed I set up a cgroup on my test server running a kernel built from the latest tip tree. [root]# cat cpu.cfs_quota_us 5 [root]# cat cpu.cfs_period_us 10 [root]# cat cpuset.cpus 1 [root]# cat cpuset.mems 0 Next I put the PID from the cpu thread into tasks. When I start a script that will hog the cpu I see the following in top on the guest Cpu(s): 1.9%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 48.3%hi, 0.0%si, 49.8%st So the steal time here is in line with the bandwidth control settings. Ok. So I was wrong in my hunch that it would be outside the runqueue, therefore work automatically. Still, the host kernel has all the information in cgroups. So then the steal time did not show on the guest. You have no value that needs to be passed around. What I did not like about this approach was * only works for cfs bandwidth control. If another type of hard limit was added to the kernel the code would potentially need to change. This is true for almost everything we have in the kernel! It is *very* unlikely for other bandwidth control mechanism to ever appear. If it ever does, it's *their* burden to make sure it works for steal time (provided it is merged). Code in tree gets precedence. * This approach doesn't help if the limits are set by overcommitting the cpus. It is my understanding that this is a common approach. I can't say anything about commonality, but common or not, it is a *crazy* approach. When you simply overcommit, you have no way to differentiate between intended steal time and non-intended steal time. Moreover, when you overcommit, your cpu usage will vary over time. If two guests use the cpu to their full power, you will have 50 % each. But if one of them slows down, the other gets more. What is your entitlement value? How do you define this? And then after you define it, you end up using more than this, what is your cpu usage? 130 %? The only sane way to do it, is to communicate this value to the kernel somehow. The bandwidth controller is the interface we have for that. So everybody that wants to *intentionally* overcommit needs to communicate this to the controller. IOW: Any sane configuration should be explicit about your capping. Add an ioctl to communicate the consign limit to the host. This definitely should go away. More specifically, *whatever* way we use to cap the processor, the host system will have all the information at all times. I'm not understanding that comment. If you are capping by simply controlling the amount of overcommit on the host then wouldn't you still need some value to indicate the desired amount. No, that is just crazy, and I don't like it a single bit. So in the light of it: Whatever capping mechanism we have, we need to be explicit about the expected entitlement. At this point, the kernel already knows what it is, and needs no extra ioctls or anything like that. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Partialy mapped page stays in page cache after unmap
Hi!
I've seen the LTP open posix mmap/{11-4,11-5} issues in the past myself
and was something I wanted to discuss on the lists myself. Thanks for
bringing this up.
Jut to reiterate: the expectations are
1. zero filling of unmapped (trailing) partial page
2. NO Writeout (to disk) of trailing partial page.
#1 is broken as your latter test case proves. We can have an alternate
test case which starts with non empty file (preloaded with all 'a's),
mmap partial page and then read out the trailing partial page, it will
not be zeroes (it's probably ftruncate which does the trick in first place).
Regarding #2 - I did verify that msync indeed makes it pass - but I'm
confused why. After all it is going to commit the buffer with 'b' to
on-disk - so a subsequent mmap is bound to see the update to file and
hence would make the test fail. What am I missing here ?
I've been researching that issue for quite some time and found this:
Once the partial page gets loaded into the page cache it stays there
till it's flushed back to the disk. There is no information about the
length of the data in that page in the page cache. The page is zeroed at
the time it's loaded into the cache but once you dirty the the content
it's not zeroed until it's flushed back to the disk it just stays in the
cache as it is and any subsequent mappings will just pick this page. The
page is not written back untill it's forced to leave the cache (which is
not after the the mapping has been destroyed or the process has exited)
which is the reason why msync() makes the test succeed.
In my opinion this behavior is not 100% POSIXly correct, on the other
hand I find it quite reasonable, making the mmap() see zeroed page at
any mapping would only waste memory (I can't see any other solution than
duplicating the last page for any new mmap).
Also note that the msync() doesn't work for shm as the shm filesystem
msycn is no-operation one (as the data doesn't have to be synced
anywhere).
I've send a patch to the linux man pages with similar description:
http://marc.info/?l=linux-manm=135271969606543w=2
Hope this clarifies the issue.
--
Cyril Hrubis
chru...@suse.cz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -next 2/2] tty: Correct tty buffer flush.
The root of problem is carelessly zeroing pointer(in function
__tty_buffer_flush()),
when another thread can use it. It can be cause of NULL pointer dereference.
Main idea of the patch, this is never free last (struct tty_buffer) in the
active buffer.
Only flush the data for ldisc(tty-buf.head-read = tty-buf.head-commit).
At that moment driver can collect(write) data in buffer without conflict.
It is repeat behavior of flush_to_ldisc(), only without feeding data to ldisc.
Signed-off-by: Ilya Zykov i...@ilyx.ru
---
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 7602df8..8ad 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -119,11 +119,14 @@ static void __tty_buffer_flush(struct tty_port *port)
struct tty_bufhead *buf = port-buf;
struct tty_buffer *thead;
- while ((thead = buf-head) != NULL) {
- buf-head = thead-next;
- tty_buffer_free(port, thead);
+ if (unlikely(buf-head == NULL))
+ return;
+ while ((thead = buf-head-next) != NULL) {
+ tty_buffer_free(port, buf-head);
+ buf-head = thead;
}
- buf-tail = NULL;
+ WARN_ON(buf-head != buf-tail);
+ buf-head-read = buf-head-commit;
}
/**
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mfd: tps80031: Add terminating entry for tps80031_id_table
The i2c_device_id table is supposed to be zero-terminated.
Signed-off-by: Axel Lin axel@ingics.com
---
drivers/mfd/tps80031.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/tps80031.c b/drivers/mfd/tps80031.c
index f64005e..10b51f7 100644
--- a/drivers/mfd/tps80031.c
+++ b/drivers/mfd/tps80031.c
@@ -543,6 +543,7 @@ static int __devexit tps80031_remove(struct i2c_client
*client)
static const struct i2c_device_id tps80031_id_table[] = {
{ tps80031, TPS80031 },
{ tps80032, TPS80032 },
+ { }
};
MODULE_DEVICE_TABLE(i2c, tps80031_id_table);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 2/2] mfd: stmpe: Update DT support in stmpe driver
Ping!!!
On 1 December 2012 00:33, Viresh Kumar viresh.ku...@linaro.org wrote:
On 30 November 2012 21:15, Lee Jones lee.jo...@linaro.org wrote:
But ... I don't see how the changes in the -i2c and -spi files
are of benefit either. When I boot without the ID table I still
get stmpe-i2c 0-0040: stmpe1601 detected, chip id: 0x212.
What is it that actually uses the IDs?
Perhaps Viresh can shine some light on the matter?
As you can see, i wasn't the author of this patch and when you asked
this question, i didn't had an answer to it. I went through code and
formed some theory/story :) .
@Grant: i need your help to check if my theory is correct or not. Question
is about adding below code in any i2c client driver:
+#ifdef CONFIG_OF
+static const struct of_device_id stmpe_dt_ids[] = {
+ { .compatible = st,stmpe610, .data = stmpe_i2c_id[0], },
+ { .compatible = st,stmpe801, .data = stmpe_i2c_id[1], },
+ { .compatible = st,stmpe811, .data = stmpe_i2c_id[2], },
+ { .compatible = st,stmpe1601, .data = stmpe_i2c_id[3], },
+ { .compatible = st,stmpe2401, .data = stmpe_i2c_id[4], },
+ { .compatible = st,stmpe2403, .data = stmpe_i2c_id[5], },
+ { }
+};
+MODULE_DEVICE_TABLE(of, stmpe_dt_ids);
+#endif
+
static struct i2c_driver stmpe_i2c_driver = {
.driver = {
.name = stmpe-i2c,
@@ -88,6 +102,7 @@ static struct i2c_driver stmpe_i2c_driver = {
#ifdef CONFIG_PM
.pm = stmpe_dev_pm_ops,
#endif
+ .of_match_table = of_match_ptr(stmpe_dt_ids),
So, what is the use of this table when we already have i2c_driver.id_table
populated.
This is my theory:
-
Adapter drivers supporting DT will call:
of_i2c_register_devices()
{
for_each_child_of_node(adap-dev.of_node, node) {
if (of_modalias_node(node, info.type, sizeof(info.type)) 0)
error condition
...
result = i2c_new_device(adap, info);
...
}
of_modalias_node(): expects compatible in child node, i.e. stmpe node in our
case. If it is not there, then that node is skipped. then it copies
string after ','
to info.type. So, for us only stmpe810 out of st,stmpe810 is copied.
Now this name, i.e. stmpe810 is copied as client.name in i2c_new_device()
and device_register() is called, which will eventually call:
i2c_device_match()
{
/* Attempt an OF style match */
if (of_driver_match_device(dev, drv))
return 1;
driver = to_i2c_driver(drv);
/* match on an id table if there is one */
if (driver-id_table)
return i2c_match_id(driver-id_table, client) != NULL;
}
This first tries to match the table my patch added, _BUT_ the string will
never match as we had st,stmpe810 in table and stmpe810 in dev.
So, we fall back to i2c_match_id(), which will match it against
i2c_driver.id_table present in driver, which has entry for stmpe810 and
so strings matched.
@Lee: This is what happened in your case. :)
So, whether its DT or non DT, true is returned from here if something
matched.
Later on, this will be called:
static int i2c_device_probe(struct device *dev)
{
.
status = driver-probe(client, i2c_match_id(driver-id_table,
client));
}
Which will again match the legacy table to find correct struct i2c_device_id
*id
to pass to probe().
So, the final question: WTF is of_match_table for?
Then i thought maybe it is used when we don't have child nodes inside parent,
something related to the phandle way ? I grep'd i2c in arch/arm/boot/dts and
couldn't find anything of that sort, the way i2c clients are added is:
in dtsi file:
i2c0: i2c@address {
...
}
in dts file:
i2c0 {
stmpe810 {
}
}
which i believe will be taken care by dtc and will fold client nodes
as child nodes
of i2c0.
@Grant: Please throw some light here :)
--
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/4] sta2x11_vip: convert to videobuf2 and control framework
Em 05-12-2012 10:24, Federico Vaga escreveu: Thank you Mauro for the good explanation Yeah, there are many changes there that justifies adding you at its authorship, and that's ok. Also, anyone saying the size of your patch will recognize your and ST efforts to improve the driver. However, as some parts of the code were preserved, dropping the old authors doesn't sound right (and can even be illegal, in the light of the GPL license). It would be ok, though, if you would be changing it to something like: Copyright (c) 2010 by ... or Original driver from ... Ok, I understand. I will write something like this. * Copyright (C) 2012 ST Microelectronics * author: Federico Vaga federico.v...@gmail.com * Copyright (C) 2010 WindRiver Systems, Inc. * authors: Andreas Kies andreas.k...@windriver.com * Vlad Lungu vlad.lu...@windriver.com Sounds perfect to me. So, IMHO, there's not much point on dropping authorship messages. So the MODULE_AUTHOR will be Windriver forever until they drop authorship? Also if in the next future 0 windriver lines will be in the code? (general talking, not about this driver) If I do git blame on a driver with MODULE_AUTHOR(Mr. X); but only the MODULE_AUTHOR line is from Mr X; there is not an automatically system which remove the MODULE_AUTHOR? Ok, probably it was the original author of the code and the comment header with the copyright history gives to Mr X all the honours, but there is nothing from him in the code. It is not better to remove MODULE_AUTHOR or replace it with who wrotes most of the code? I know that this is not the best place to talk about this, just a little curiosity As you said, the best place to discuss about it is likely at LKML. It could make sense to have some policy with regards to MODULE_AUTHOR(), stating when it could be modified, preferably reviewed by some experienced open source lawyers. I'm not aware of any. In any case, I don't think anyone should rely on git blame for it. The tool that helps to get code authorship is git log -M, but to get the real authorship requires a lot more of just calling it. A trivial case where git blame will likely be giving wrong credits is if a driver has all functions reordered. It may happen that git blame will give credits to the one that reordered the functions, and not to the original code's author. There are more subtle cases, though. For example, please assume that the original driver has to call a certain function to do some needed work to initialize the device: call_function_foo(); And a reviewer latter add a logic to deal with errors, like: ret = call_function_foo(); if (ret) return ret; The reviewer wrote 2 additional lines, and modified 1 original line. Yet, his contribution didn't make the code to work. The one that did it was the single-line patch that added call_function_foo(). So, in this case, a single line change was more significant for the driver than a 3 line addition[1]. Also, again, git blame will give the credits for the line that calls call_function_foo() to the wrong guy. Btw, this is why it is called git blame, and not git authorship: it is a tool to identify who was the last one that modified the code. Its main usage is to identify who might have introduced a bug on the code. Let's assume that call_function_foo() could be returning some non-error positive values, under certain circumstances. In that case, the above code would actually be introducing a bug by using: if (ret) instead of if (ret 0) So, the 3 line patch is not only be less relevant for the driver to work than the original author's code, but it is actually wrong and introduced a serious driver regression, preventing it to work. Git blame was made to address such cases: once a bug got bisected, it helps to get the changelog that made the change, pointing to who made the changes and why. So, a proper fix for the bug can be better prepared, to not only fix the bug, but to also address the issue pointed by the blamed patchset. Regards, Mauro [1] Please, don't get be wrong on that: we do want patches adding proper error handling. They are important to improve the driver's reliability. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PTRACE_SYSCALL vsyscall (Was: arch_check_bp_in_kernelspace: fix the range check)
Dear Jan, x86 debug registers are already very scarce. Besides that userland applications know they have 4 of them available so it would also break them. If a userland application wants to cheat, then it has no need to bypass the debug registers: even if there were 4096 of them, covering the whole vsyscall page, it could simply copy the whole vsyscall page somewhere else, then run (or emulate) it, or look directly at the raw data within the vsyscall page. The only way to overcome that would be to make the vsyscall page either non-existent or unreadable. Personally, allowing userland applications to read the vsyscall page can't hurt me and my applications, but if someone else is concerned with such malicious programs (does anyone?), if they need to construct the strictest-of-strict jail, where jailed applications cannot glimpse any information from the kernel they run on no matter how hard they try, then they must at least make the vsyscall page unreadable, then rely either on kernel emulation or a SIGSEGV (the later would be quite sufficient for my own needs as a substitute for debug-registers, but unfortunately not for the current version of strace). If, as I was told, it's too hard to remove the vsyscall page on a per-process basis, then it's sufficient to make it unreadable on context-switch. My concern, however, is not with the bad guys, but with good honest programs that would run incorrectly if allowed to call time() or gettimeofday() unsupervised. No good program or library jumps into the vsyscall page except into its 3 official entry points. In summary, it should be decided: If it is important enough for Linux to support paranoidically strict jails, then full kernel emulation of PTRACE_SYSCALL (and PTRACE_SYSEMU) is inescapable. If, on the other hand, there is only a need to allow applications such as mine and strace/gdb to trap system-calls that occur via the vsyscall page, then in principle a variety of options are possible: 1. Allow setting the x86 hardware-debug registers into the vsyscall page. 2. Optional (per-process) removal of execute-permission from the vsyscall page. 3. Optional (per-process) removal of both read and execute permissions from the vsyscall page. 4. Optional (per-process) elimination of the vsyscall page altogether. 5. Kernel vsyscall emulation code to send some signal or event to traced processes if the ptracer asked for it (using a new ptrace option). 6. Complete and transparent emulation of PTRACE_SYSCALL/PTRACE_SYSEMU. Option #1 requires the least effort (a 2-line fix). Option #6 requires the most effort. Best Regards, Amnon. On Sun, 02 Dec 2012 20:30:58 +0100, Oleg Nesterov wrote: Yes, that is why I said this needs the new option. I do not mind new options although personally I do not find them meaningful for an already deprecated ABI compatibility-only issue. If the tracer does PTRACE_SYSCALL the tracee reports syscall exit _after_ gettimeofday/etc. The tracer can look at regs-orig_ax == -1 and detect that this is not syscall but vsyscall, it can look at regs-ip then (not with the patch below). I believe applications just call PTRACE_SYSCALL twice, without checking orig_eax. At least strace and its TCB_INSYSCALL looks so. On Mon, 03 Dec 2012 00:54:58 +0100, u3...@miso.sublimeip.com wrote: The beauty of using the x86 debug-registers, x86 debug registers are already very scarce. Besides that userland applications know they have 4 of them available so it would also break them. Regards, Jan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 2/2] mfd: stmpe: Update DT support in stmpe driver
Ping!!!
Documentation/development-process/2.Process:
- Avoid top-posting (the practice of putting your answer above the quoted
text you are responding to). It makes your response harder to read and
makes a poor impression.
:)
On 1 December 2012 00:33, Viresh Kumar viresh.ku...@linaro.org wrote:
On 30 November 2012 21:15, Lee Jones lee.jo...@linaro.org wrote:
But ... I don't see how the changes in the -i2c and -spi files
are of benefit either. When I boot without the ID table I still
get stmpe-i2c 0-0040: stmpe1601 detected, chip id: 0x212.
What is it that actually uses the IDs?
Perhaps Viresh can shine some light on the matter?
As you can see, i wasn't the author of this patch and when you asked
this question, i didn't had an answer to it. I went through code and
formed some theory/story :) .
@Grant: i need your help to check if my theory is correct or not. Question
is about adding below code in any i2c client driver:
+#ifdef CONFIG_OF
+static const struct of_device_id stmpe_dt_ids[] = {
+ { .compatible = st,stmpe610, .data = stmpe_i2c_id[0], },
+ { .compatible = st,stmpe801, .data = stmpe_i2c_id[1], },
+ { .compatible = st,stmpe811, .data = stmpe_i2c_id[2], },
+ { .compatible = st,stmpe1601, .data = stmpe_i2c_id[3], },
+ { .compatible = st,stmpe2401, .data = stmpe_i2c_id[4], },
+ { .compatible = st,stmpe2403, .data = stmpe_i2c_id[5], },
+ { }
+};
+MODULE_DEVICE_TABLE(of, stmpe_dt_ids);
+#endif
+
static struct i2c_driver stmpe_i2c_driver = {
.driver = {
.name = stmpe-i2c,
@@ -88,6 +102,7 @@ static struct i2c_driver stmpe_i2c_driver = {
#ifdef CONFIG_PM
.pm = stmpe_dev_pm_ops,
#endif
+ .of_match_table = of_match_ptr(stmpe_dt_ids),
So, what is the use of this table when we already have i2c_driver.id_table
populated.
This is my theory:
-
Adapter drivers supporting DT will call:
of_i2c_register_devices()
{
for_each_child_of_node(adap-dev.of_node, node) {
if (of_modalias_node(node, info.type, sizeof(info.type))
0)
error condition
...
result = i2c_new_device(adap, info);
...
}
of_modalias_node(): expects compatible in child node, i.e. stmpe node in our
case. If it is not there, then that node is skipped. then it copies
string after ','
to info.type. So, for us only stmpe810 out of st,stmpe810 is copied.
Now this name, i.e. stmpe810 is copied as client.name in i2c_new_device()
and device_register() is called, which will eventually call:
i2c_device_match()
{
/* Attempt an OF style match */
if (of_driver_match_device(dev, drv))
return 1;
driver = to_i2c_driver(drv);
/* match on an id table if there is one */
if (driver-id_table)
return i2c_match_id(driver-id_table, client) != NULL;
}
This first tries to match the table my patch added, _BUT_ the string will
never match as we had st,stmpe810 in table and stmpe810 in dev.
So, we fall back to i2c_match_id(), which will match it against
i2c_driver.id_table present in driver, which has entry for stmpe810 and
so strings matched.
@Lee: This is what happened in your case. :)
So, whether its DT or non DT, true is returned from here if something
matched.
Later on, this will be called:
static int i2c_device_probe(struct device *dev)
{
.
status = driver-probe(client, i2c_match_id(driver-id_table,
client));
}
Which will again match the legacy table to find correct struct
i2c_device_id *id
to pass to probe().
So, the final question: WTF is of_match_table for?
Then i thought maybe it is used when we don't have child nodes inside
parent,
something related to the phandle way ? I grep'd i2c in arch/arm/boot/dts and
couldn't find anything of that sort, the way i2c clients are added is:
in dtsi file:
i2c0: i2c@address {
...
}
in dts file:
i2c0 {
stmpe810 {
}
}
which i believe will be taken care by dtc and will fold client nodes
as child nodes
of i2c0.
@Grant: Please throw some light here :)
--
viresh
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mfd: tps80031: MFD_TPS80031 needs to select REGMAP_IRQ
This driver uses regmap_irq APIs, thus need to select REGMAP_IRQ. IRQ_DOMAIN will be selected if select REGMAP_IRQ, thus remove it here. This fixes below build errors: drivers/built-in.o: In function `tps80031_remove': drivers/mfd/tps80031.c:534: undefined reference to `regmap_del_irq_chip' drivers/built-in.o: In function `tps80031_irq_init': drivers/mfd/tps80031.c:305: undefined reference to `regmap_add_irq_chip' drivers/built-in.o: In function `tps80031_probe': drivers/mfd/tps80031.c:496: undefined reference to `regmap_irq_get_domain' drivers/mfd/tps80031.c:512: undefined reference to `regmap_del_irq_chip' make: *** [vmlinux] Error 1 Signed-off-by: Axel Lin axel@ingics.com --- drivers/mfd/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 09d43a9..1c0abd4 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -269,7 +269,7 @@ config MFD_TPS80031 depends on I2C=y GENERIC_HARDIRQS select MFD_CORE select REGMAP_I2C - select IRQ_DOMAIN + select REGMAP_IRQ help If you say yes here you get support for the Texas Instruments TPS80031/ TPS80032 Fully Integrated Power Management with Power -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/4] sta2x11_vip: convert to videobuf2 and control framework
Ok, I understand. I will write something like this. * Copyright (C) 2012 ST Microelectronics * author: Federico Vaga federico.v...@gmail.com * Copyright (C) 2010 WindRiver Systems, Inc. * authors: Andreas Kies andreas.k...@windriver.com * Vlad Lungu vlad.lu...@windriver.com Sounds perfect to me. I will answer to this with a patch As you said, the best place to discuss about it is likely at LKML. [...] Btw, this is why it is called git blame, and not git authorship: it is a tool to identify who was the last one that modified the code. Its main usage is to identify who might have introduced a bug on the code. I know I know, it was just a stupid example to expose the problem that I have in my mind. I know that it is very difficult (impossible?) to assign the authorship of a single line, and git blame it is not the tool to do this :) I think you understand what I mean despite the stupid example -- Federico Vaga -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 2/2] mfd: stmpe: Update DT support in stmpe driver
On 5 December 2012 18:49, Lee Jones lee.jo...@linaro.org wrote: Ping!!! Documentation/development-process/2.Process: - Avoid top-posting (the practice of putting your answer above the quoted text you are responding to). It makes your response harder to read and makes a poor impression. Yes, i know that. Did that in hurry, as it was just an ping and wasn't answering any question. -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x
On Wed, Dec 05, 2012 at 01:31:54PM +0100, Daniel Vetter wrote: On Wed, Dec 5, 2012 at 1:22 PM, Thierry Reding thierry.red...@avionic-design.de wrote: Maybe something more elaborate could help, though. Suppose we add functionality to DRM to instantiate a DRM device. We could call such a function from the host1x driver to add a device which the tegra-drm driver could bind to. This would entail something like a small bus implementation for DRM that would allow matching DRM devices to DRM drivers much like the platform or PCI busses. This could automatically take care of registering the DRM device with the proper parent so that host1x clients can lookup the host1x via dev-parent. Perhaps something as simple as int drm_device_register(struct device *parent, const char *name, int id); could work. Or something more elaborate such as allocating a device with struct drm_device *drm_device_alloc(const char *name, int id); paired with int drm_device_register(struct drm_device *dev); would be more flexible in that drivers could modify the DRM device in between the two calls. Imo that's worse, since now drm manages even more of the driver-hw binding process. In my dream world the drm driver just registers a normal driver at module load time directly with whatever bus it's interested in, and then, from it the bus' -probe callback setups up the entire driver, calling down into drm to setup up interfaces to userspace (dev node, sysfs, and whatever is required to implement the ioctls) and uses the various helper libraries provided. So host1x providing a virtual device that tegradrm can match sounds much better (if that helps in decoupling from host1x). Okay, now I see where you're going. You want to replace the various drm_*_init() functions with something more fine-grained that does the initialization manually in each driver. Is that it? The obvious disadvantage is that a lot of code would have to be duplicated, though that can presumably be factored out into further helpers if necessary. On that note, I just noticed that drm_platform_init() actually binds a single platform_device to the drm_driver, which isn't going to work very well in case there are two devices that want to use the same driver. It would be nice to get rid of that limitation as well while at it. Or simply call the tegradrm setup from host1x directly, creating a depency on the tegradrm module. When trying to unload host1x it can then also call down into tegradrm to tear down the drm device. Afterwards you should be able to unload tegradrm without fuzz. And if the hard dependcy is an issue for other host1x clients this setup/teardown could be wrapped into an #ifdef CONFIG_TEGRADRM. This is what I originally proposed. However, since tegra-drm will need to call functions provided by host1x we have a cyclic dependency. Wouldn't that prevent either module from being unloaded? Thierry pgpsOpjAH4afp.pgp Description: PGP signature
Re: [PATCH v3 3/4] sta2x11_vip: convert to videobuf2 and control framework
Em 05-12-2012 11:27, Federico Vaga escreveu: Ok, I understand. I will write something like this. * Copyright (C) 2012 ST Microelectronics * author: Federico Vaga federico.v...@gmail.com * Copyright (C) 2010 WindRiver Systems, Inc. * authors: Andreas Kies andreas.k...@windriver.com * Vlad Lungu vlad.lu...@windriver.com Sounds perfect to me. I will answer to this with a patch Thanks! As you said, the best place to discuss about it is likely at LKML. [...] Btw, this is why it is called git blame, and not git authorship: it is a tool to identify who was the last one that modified the code. Its main usage is to identify who might have introduced a bug on the code. I know I know, it was just a stupid example to expose the problem that I have in my mind. I know that it is very difficult (impossible?) to assign the authorship of a single line, and git blame it is not the tool to do this :) I think you understand what I mean despite the stupid example Yeah, I hear you. Not sure if you got my point: the main point of removing MODULE_AUTHOR and other copyright stuff is that such patch may easily be doing something that could be considered a copyright violation, being bad not only to the affected driver, but to the entire Kernel. So, we need to handle it with due care. Getting other authors's acks on such patch seems to be the only safe way of doing that. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/4] sta2x11_vip: convert to videobuf2 and control framework
Not sure if you got my point: the main point of removing MODULE_AUTHOR and other copyright stuff is that such patch may easily be doing something that could be considered a copyright violation, being bad not only to the affected driver, but to the entire Kernel. So, we need to handle it with due care. Getting other authors's acks on such patch seems to be the only safe way of doing that. Yes I got the point. Thank you -- Federico Vaga -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fs: Fix imbalance in freeze protection in mark_files_ro()
File descriptors (even those for writing) do not hold freeze protection. Thus mark_files_ro() must call __mnt_drop_write() to only drop protection against remount read-only. Calling mnt_drop_write_file() as we do now results in: [ BUG: bad unlock balance detected! ] 3.7.0-rc6-00028-g88e75b6 #101 Not tainted - kworker/1:2/79 is trying to release lock (sb_writers) at: [811b33b4] mnt_drop_write+0x24/0x30 but there are no more locks to release! Reported-by: Zdenek Kabelac zkabe...@redhat.com CC: sta...@vger.kernel.org Signed-off-by: Jan Kara j...@suse.cz --- fs/file_table.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Umm, this got lost for some reason... diff --git a/fs/file_table.c b/fs/file_table.c index a72bf9d..de9e965 100644 --- a/fs/file_table.c +++ b/fs/file_table.c @@ -458,8 +458,8 @@ void mark_files_ro(struct super_block *sb) spin_unlock(f-f_lock); if (file_check_writeable(f) != 0) continue; + __mnt_drop_write(f-f_path.mnt); file_release_write(f); - mnt_drop_write_file(f); } while_file_list_for_each_entry; lg_global_unlock(files_lglock); } -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] printk: Fix print_time length computation when no buffer is given
The %5lu part of the sprintf only guarantees a minimum length,
not a maximum one. This patch should make it correct for any
possible timestamp.
Signed-off-by: Sylvain Munaut s.mun...@whatever-company.com
---
kernel/printk.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/kernel/printk.c b/kernel/printk.c
index 66a2ea3..2ceceea 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -847,8 +847,17 @@ static size_t print_time(u64 ts, char *buf)
if (!printk_time)
return 0;
- if (!buf)
- return 15;
+ if (!buf) {
+ size_t len = 15;
+ u64 ts_limit = (u64)10 * (u64)10;
+
+ while ((ts ts_limit) (len 21)) {
+ len++;
+ ts_limit = 10 * ts_limit;
+ }
+
+ return len;
+ }
rem_nsec = do_div(ts, 10);
return sprintf(buf, [%5lu.%06lu] ,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for 3.2.34] memcg: do not trigger OOM from add_to_page_cache_locked
On Wed 05-12-12 02:36:44, azurIt wrote: The following should print the traces when we hand over ENOMEM to the caller. It should catch all charge paths (migration is not covered but that one is not important here). If we don't see any traces from here and there is still global OOM striking then there must be something else to trigger this. Could you test this with the patch which aims at fixing your deadlock, please? I realise that this is a production environment but I do not see anything relevant in the code. Michal, i think/hope this is what you wanted: http://www.watchdog.sk/lkml/oom_mysqld2 Dec 5 02:20:48 server01 kernel: [ 380.995947] WARNING: at mm/memcontrol.c:2400 T.1146+0x2c1/0x5d0() Dec 5 02:20:48 server01 kernel: [ 380.995950] Hardware name: S5000VSA Dec 5 02:20:48 server01 kernel: [ 380.995952] Pid: 5351, comm: apache2 Not tainted 3.2.34-grsec #1 Dec 5 02:20:48 server01 kernel: [ 380.995954] Call Trace: Dec 5 02:20:48 server01 kernel: [ 380.995960] [81054eaa] warn_slowpath_common+0x7a/0xb0 Dec 5 02:20:48 server01 kernel: [ 380.995963] [81054efa] warn_slowpath_null+0x1a/0x20 Dec 5 02:20:48 server01 kernel: [ 380.995965] [8110b2e1] T.1146+0x2c1/0x5d0 Dec 5 02:20:48 server01 kernel: [ 380.995967] [8110ba83] mem_cgroup_charge_common+0x53/0x90 Dec 5 02:20:48 server01 kernel: [ 380.995970] [8110bb05] mem_cgroup_newpage_charge+0x45/0x50 Dec 5 02:20:48 server01 kernel: [ 380.995974] [810eddf9] handle_pte_fault+0x609/0x940 Dec 5 02:20:48 server01 kernel: [ 380.995978] [8102aa8f] ? pte_alloc_one+0x3f/0x50 Dec 5 02:20:48 server01 kernel: [ 380.995981] [810ee268] handle_mm_fault+0x138/0x260 Dec 5 02:20:48 server01 kernel: [ 380.995983] [810270ed] do_page_fault+0x13d/0x460 Dec 5 02:20:48 server01 kernel: [ 380.995986] [810f429c] ? do_mmap_pgoff+0x3dc/0x430 Dec 5 02:20:48 server01 kernel: [ 380.995988] [810f197d] ? remove_vma+0x5d/0x80 Dec 5 02:20:48 server01 kernel: [ 380.995992] [815b54ff] page_fault+0x1f/0x30 Dec 5 02:20:48 server01 kernel: [ 380.995994] ---[ end trace 25bbb3e634c25b7f ]--- Dec 5 02:20:48 server01 kernel: [ 380.996373] apache2 invoked oom-killer: gfp_mask=0x0, order=0, oom_adj=0, oom_score_adj=0 Dec 5 02:20:48 server01 kernel: [ 380.996377] apache2 cpuset=uid mems_allowed=0 Dec 5 02:20:48 server01 kernel: [ 380.996379] Pid: 5351, comm: apache2 Tainted: GW3.2.34-grsec #1 Dec 5 02:20:48 server01 kernel: [ 380.996380] Call Trace: Dec 5 02:20:48 server01 kernel: [ 380.996384] [810cc91e] dump_header+0x7e/0x1e0 Dec 5 02:20:48 server01 kernel: [ 380.996387] [810cc81f] ? find_lock_task_mm+0x2f/0x70 Dec 5 02:20:48 server01 kernel: [ 380.996389] [810ccde5] oom_kill_process+0x85/0x2a0 Dec 5 02:20:48 server01 kernel: [ 380.996392] [810cd495] out_of_memory+0xe5/0x200 Dec 5 02:20:48 server01 kernel: [ 380.996394] [8102aa8f] ? pte_alloc_one+0x3f/0x50 Dec 5 02:20:48 server01 kernel: [ 380.996397] [810cd66d] pagefault_out_of_memory+0xbd/0x110 Dec 5 02:20:48 server01 kernel: [ 380.996399] [81026ec6] mm_fault_error+0xb6/0x1a0 Dec 5 02:20:48 server01 kernel: [ 380.996401] [8102739e] do_page_fault+0x3ee/0x460 Dec 5 02:20:48 server01 kernel: [ 380.996403] [810f429c] ? do_mmap_pgoff+0x3dc/0x430 Dec 5 02:20:48 server01 kernel: [ 380.996405] [810f197d] ? remove_vma+0x5d/0x80 Dec 5 02:20:48 server01 kernel: [ 380.996408] [815b54ff] page_fault+0x1f/0x30 OK, so the ENOMEM seems to be leaking from mem_cgroup_newpage_charge. This can only happen if this was an atomic allocation request (!__GFP_WAIT) or if oom is not allowed which is the case only for transparent huge page allocation. The first case can be excluded (in the clean 3.2 stable kernel) because all callers of mem_cgroup_newpage_charge use GFP_KERNEL. The later one should be OK because the page fault should fallback to a regular page if THP allocation/charge fails. [/me goes to double check] Hmm do_huge_pmd_wp_page seems to charge a huge page and fails with VM_FAULT_OOM without any fallback. We should do_huge_pmd_wp_page_fallback instead. This has been fixed in 3.5-rc1 by 1f1d06c3 (thp, memcg: split hugepage for memcg oom on cow) but it hasn't been backported to 3.2. The patch applies to 3.2 without any further modifications. I didn't have time to test it but if it helps you we should push this to the stable tree. --- From 765f5e0121c4410faa19c088e9ada75976bde178 Mon Sep 17 00:00:00 2001 From: David Rientjes rient...@google.com Date: Tue, 29 May 2012 15:06:23 -0700 Subject: [PATCH] thp, memcg: split hugepage for memcg oom on cow On COW, a new hugepage is allocated and charged to the memcg. If the system is oom or the charge to the memcg fails, however, the fault handler will return VM_FAULT_OOM which results in an oom kill.
[PATCH] Round the calculated scale factor in set_cyc2ns_scale()
During some experiments with an external clock (in a FPGA), we saw that
the TSC clock drifted approx. 2.5ms per second.
This drift was caused by the current way of calculating the scale.
In our case cpu_khz had a value of 3292725. This resulted in a scale
value of 310. But when doing the calculation by hand it shows that the
actual value is 310.9886188491, so a value of 311 would be more precise.
With this change the value is rounded.
Signed-off-by: Bernd Faust berndfa...@gmail.com
---
arch/x86/kernel/tsc.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index cfa5d4f..8ed0857 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -617,7 +617,8 @@ static void set_cyc2ns_scale(unsigned long cpu_khz, int cpu)
ns_now = __cycles_2_ns(tsc_now);
if (cpu_khz) {
- *scale = (NSEC_PER_MSEC CYC2NS_SCALE_FACTOR)/cpu_khz;
+ *scale = ((NSEC_PER_MSEC CYC2NS_SCALE_FACTOR) +
+ cpu_khz / 2) / cpu_khz;
*offset = ns_now - mult_frac(tsc_now, *scale,
(1UL CYC2NS_SCALE_FACTOR));
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Staging: android: ashmem: Add support for 32bit ashmem calls in a 64bit kernel
On 04/12/12 11:45, Dan Carpenter wrote:
I don't understand this, and I'm going to embarrass myself by
displaying my ignorance for all to see. Why is this code so
different from all the other 32 bit compat code that we have in the
kernel?
On Tue, Dec 04, 2012 at 10:44:14AM +, Serban Constantinescu wrote:
-static int set_name(struct ashmem_area *asma, void __user *name)
+static int set_name(struct ashmem_area *asma, userptr32_t name)
The user passes in a value which is a 32 pointer. ashmem_ioctl()
accepts it as unsigned long arg. We pass it to set_name() which
truncates away the high zeros so now its a u32 (userptr32_t). We
then cast it to (unsigned long) and then we cast it to a void
pointer.
What's the point? Why not just takeunsigned long arg and cast it
to a pointer directly?
if (unlikely(copy_from_user(asma-name + ASHMEM_NAME_PREFIX_LEN,
-name, ASHMEM_NAME_LEN)))
+(void *)(unsigned long)name, ASHMEM_NAME_LEN)))
ret = -EFAULT;
This will introduce a Sparse complaint. It should be:
(void __user *)(unsigned long)name.
Thanks for taking your time and reviewing this patch set. I have put
together a new version of this patch (ashmem) and I will resend it to
LKML as soon as I finish testing on both 32 and 64 bit platforms.
But actually we shouldn't need to do this casting. Any casting
which we need to do should be done in one place instead of pushed
out to every function.
+switch (_IOC_NR(cmd)) {
+case _IOC_NR(ASHMEM_SET_NAME):
+if (_IOC_SIZE(cmd) != sizeof(char[ASHMEM_NAME_LEN]))
+pr_err(ashmem: ASHMEM_SET_NAME transaction size
differs\n);
Don't merge debug code into the kernel. It just means people can
spam /var/log/messages.
I see what you mean. I won't include those in the new patch set.
regards,
dan carpenter
Kind regards,
Serban Constantinescu
`
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: switcheroo registration vs switching race...
On 5 December 2012 00:04, Takashi Iwai ti...@suse.de wrote: At Tue, 4 Dec 2012 23:54:39 +0800, Daniel J Blueman wrote: On 4 December 2012 23:03, Takashi Iwai ti...@suse.de wrote: At Tue, 4 Dec 2012 22:46:47 +0800, Daniel J Blueman wrote: On 4 December 2012 21:55, Takashi Iwai ti...@suse.de wrote: At Tue, 04 Dec 2012 14:23:05 +0100, Takashi Iwai wrote: At Tue, 4 Dec 2012 20:58:55 +0800, Daniel J Blueman wrote: On 4 December 2012 01:10, Takashi Iwai ti...@suse.de wrote: At Tue, 4 Dec 2012 00:50:56 +0800, Daniel J Blueman wrote: On 4 December 2012 00:23, Takashi Iwai ti...@suse.de wrote: At Mon, 3 Dec 2012 23:08:28 +0800, Daniel J Blueman wrote: On 3 December 2012 22:40, Takashi Iwai ti...@suse.de wrote: At Mon, 3 Dec 2012 22:25:52 +0800, Daniel J Blueman wrote: On 3 December 2012 19:17, Takashi Iwai ti...@suse.de wrote: At Wed, 28 Nov 2012 09:45:39 +0100, Takashi Iwai wrote: At Wed, 28 Nov 2012 11:45:07 +0800, Daniel J Blueman wrote: Hi Seth, Dave, Takashi, If I power down the unused discrete GPU before lightdm starts by fiddling with the sysfs file [1] in the upstart script, I see a race manifesting as the discrete GPU's HDA controller timing out to commands [2]. Adding some debug, I see that the registered audio devices are put into D3 before the GPU is, but it turns out that the discrete (and internal) GPU's HDA controller gets registered a bit later, so the list is empty. The symptom is since the HDA driver it's talking to hardware which is now in D3. We could add a mutex to nouveau to allow us to wait for the DGPU HDA controller, but perhaps this should be solved at a higher level in the vgaswitcheroo code; what do you think? Maybe it's a side effect for the recent effort to fix another race in the probe. A part of them problem is that the registration is done at the very last of probing. Instead of delaying the registration, how about the patch below? Ping. If this really works, I'd like to queue it for 3.8 merge, at least... Ping ack; I was trying to find time to understand another race that occurs with GPU probing after switching, but is separate from the situation before switching, here. In the context of writing the switch, it looks like struct azx isn't allocated by the time azx_vs_set_state accesses it [1,2]; racing with azx_codec_create? It was allocated, but it wasn't assigned properly in pci drvdata. Below is the revised patch. Just moved pci_set_drvdata() before register_vga_switcheroo(). Could you retest with it? Superb; this addresses the oops. OK, I'll queue it to sound tree for 3.8 kernel with Cc to stable. ~1 second after the DGPU is put into D3, I still often see hda-intel: spurious response 0x0:0x0, last cmd=0x170500: http://quora.org/2012/hda-switch-spurious.txt Hm, it's not clear who triggers these messages. I'll try to check the code paths. Presumably this implies the read of the ring-buffer pointer returned 0x, so the HDA driver understands the pointer to have wrapped and processes the 191 unwritten entries? Good point. Actually there is one bug that looks obviously wrong (writing 32bit value to CORBWP). Maybe it has been working just because writing CORBRP doesn't influence except for the reset bit. Reading CORBWP as a byte is OK, but this could be better in a word so that we can check 0x as invalid. A test patch is below. Hopefully this improves the situation... I'll check this out tomorrow and also instrument the code to get a backtrace, since there may still be an underlying race with the previous patches: [...] That's odd. The Cirrus one (:00:1b.0) must be independent from the vga switcheroo things for Nvidia... The patch below is the revised patch of the first one. Now the vga switcheroo registration is done before the video controller D3 check, so the race should be smaller. This patch improves things further of course; a major improvement over without. ~15% of the time, I still get the 'spurious response' messages in this callpath: A possible scenario is that the graphics went in D3 before probing hd-audio, and the
Re: [PATCH v3 2/4] videobuf2-dma-streaming: new videobuf2 memory allocator
Em 05-12-2012 10:50, Federico Vaga escreveu: On Tuesday 04 December 2012 14:04:22 Mauro Carvalho Chehab wrote: Em 24-09-2012 09:44, Marek Szyprowski escreveu: Hello, On Monday, September 24, 2012 12:59 PM Federico Vaga wrote: The DMA streaming allocator is similar to the DMA contig but it use the DMA streaming interface (dma_map_single, dma_unmap_single). The allocator allocates buffers and immediately map the memory for DMA transfer. For each buffer prepare/finish it does a DMA synchronization. Hmm.. the explanation didn't convince me, e. g.: 1) why is it needed; This allocator is needed because some device (like STA2X11 VIP) cannot work with DMA sg or DMA coherent. Some other device (like the one used by Jonathan when he proposes vb2-dma-nc allocator) can obtain much better performance with DMA streaming than coherent. Ok, please add such explanations at the patch's descriptions, as it is important not only for me, but to others that may need to use it.. 2) why vb2-dma-config can't be patched to use dma_map_single (eventually using a different vb2_io_modes bit?); I did not modify vb2-dma-contig because I was thinking that each DMA memory allocator should reflect a DMA API. The basic reason for having more than one VB low-level handling (vb2 was inspired on this concept) is that some DMA APIs are very different than the other ones (see vmalloc x DMA S/G for example). I didn't make a diff between videobuf2-dma-streaming and videobuf2-dma-contig, so I can't tell if it makes sense to merge them or not, but the above argument seems too weak. I was expecting for a technical reason why it wouldn't make sense for merging them. 3) what are the usecases for it. Could you please detail it? Without that, one that would be needing to write a driver will have serious doubts about what would be the right driver for its usage. Also, please document it at the driver itself. I did not write all this details because the reasons to use vb2-dma-contig, vb2-dma-sg or vb2-dma-streaming are the same reasons because someone choose SG, coherent or streaming API. This is already documented in the DMA-*.txt files, so I did not rewrite it to avoid duplication. I see. It doesn't hurt to add a short explanation then at the patch description, pointing to Documentation/DMA-API-HOWTO.txt, describing when using it instead of vb2-dma-config (or vb2-dma-sg) would likely give better performance results, and when the reverse is true. Btw, from Documentation/DMA-API-HOWTO.txt: Good examples of what to use streaming mappings for are: - Networking buffers transmitted/received by a device. - Filesystem buffers written/read by a SCSI device. The interfaces for using this type of mapping were designed in such a way that an implementation can make whatever performance optimizations the hardware allows. To this end, when using such mappings you must be explicit about what you want to happen. I'm not a DMA performance expert. As such, from that comment, it sounded to me that replacing dma-config/dma-sg by dma streaming will always give performance optimizations the hardware allow. If this is always true, why to preserve the old vb2-dma-config/vb2-dma-sg? In other words, I suspect that the above is just half of the history ;) On a separate but related issue, while doing DMABUF tests with an Exynos4 hardware, using a s5p sensor, sending data to s5p-tv, I noticed a CPU consumption of about 42%, which seems too high. Could it be related to not using the DMA streaming API? (c/c Sylwester, due to this last comment) Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Look Ma, da kernel is b0rken
On Wed, Dec 05, 2012 at 08:09:01AM +0100, Andreas Mohr wrote: Hi, drivers/pnp/pnpacpi/core.c: In function 'ispnpidacpi': drivers/pnp/pnpacpi/core.c:65:2: warning: logical 'or' of collectively exhaustive tests is always true [-Wlogical-op] drivers/pnp/pnpacpi/core.c:66:2: warning: logical 'or' of collectively exhaustive tests is always true [-Wlogical-op] drivers/pnp/pnpacpi/core.c:67:2: warning: logical 'or' of collectively exhaustive tests is always true [-Wlogical-op] That's already the second less enticing -Wlogical-op issue which was discovered by accident during less than two days of my happy(?) activity of kernel suspend breakage bisection. Why oh why, as a rather *very* critical piece of software, can't the kernel use sufficiently aggressive warning levels *by default*?? IMHO it's simply NOT ACCEPTABLE to have such sloppiness creep into the daily bandwagon of kernel development life (or should I say: being mandated to creep in?). Result: whichever default warning level you set *will* end up as The New Normal, and all those warnings which then remain able to rear their ugly heads according to the chosen default level will be fixed by the community eventually, and *most others won't* (or at least not in time). The amount of warnings spewn by make W=3 (or even W=2) is simply shocking IMNSHO. And there can always be an argument that most of such warnings are fixable. If not directly (e.g. because analysis of that warning type is partially unreliable), then by actively reworking code into something slightly different. Can we all relax ourselves first? Now, I admit that ispnpidacpi() is a rather clumsy way of testing string sanity but whatever, it is there. Then, we added W= exactly for inquisitive and adventurous people like yourself to build kernel compilation units with, to *verify* the *sanity* of the compiler's error messages (yes, gcc has been wrong a lot in the past too) and fix them. So why not write a patch that fixes this, *test* it correctly and then submit it to the proper maintainer instead of ranting about it without any constructive help and thus piss off everybody on the ML? And yes, bugs happen and this is the reality of it - programmers are people and they make mistakes too. So I think helping out fix bugs is a much more constructive way of spending your time instead of pissing off the only people who can actually help you with your problem. HTH. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] drivers: cma: represent physical addresses as phys_addr_t
This commit changes the CMA early initialization code to use phys_addr_t
for representing physical addresses instead of unsigned long.
Without this change, among other things, dma_declare_contiguous() simply
discards any memory regions whose address is not representable as unsigned
long.
This is a problem on 32-bit PAE machines where unsigned long is 32-bit
but physical address space is larger.
Signed-off-by: Vitaly Andrianov vita...@ti.com
Signed-off-by: Cyril Chemparathy cy...@ti.com
---
drivers/base/dma-contiguous.c | 24 ++--
include/linux/dma-contiguous.h |4 ++--
2 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 9a14694..9b841e2 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -60,8 +60,8 @@ struct cma *dma_contiguous_default_area;
* Users, who want to set the size of global CMA area for their system
* should use cma= kernel parameter.
*/
-static const unsigned long size_bytes = CMA_SIZE_MBYTES * SZ_1M;
-static long size_cmdline = -1;
+static const phys_addr_t size_bytes = CMA_SIZE_MBYTES * SZ_1M;
+static phys_addr_t size_cmdline = -1;
static int __init early_cma(char *p)
{
@@ -73,7 +73,7 @@ early_param(cma, early_cma);
#ifdef CONFIG_CMA_SIZE_PERCENTAGE
-static unsigned long __init __maybe_unused cma_early_percent_memory(void)
+static phys_addr_t __init __maybe_unused cma_early_percent_memory(void)
{
struct memblock_region *reg;
unsigned long total_pages = 0;
@@ -91,7 +91,7 @@ static unsigned long __init __maybe_unused
cma_early_percent_memory(void)
#else
-static inline __maybe_unused unsigned long cma_early_percent_memory(void)
+static inline __maybe_unused phys_addr_t cma_early_percent_memory(void)
{
return 0;
}
@@ -109,7 +109,7 @@ static inline __maybe_unused unsigned long
cma_early_percent_memory(void)
*/
void __init dma_contiguous_reserve(phys_addr_t limit)
{
- unsigned long selected_size = 0;
+ phys_addr_t selected_size = 0;
pr_debug(%s(limit %08lx)\n, __func__, (unsigned long)limit);
@@ -129,7 +129,7 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
if (selected_size) {
pr_debug(%s: reserving %ld MiB for global area\n, __func__,
-selected_size / SZ_1M);
+(unsigned long)selected_size / SZ_1M);
dma_declare_contiguous(NULL, selected_size, 0, limit);
}
@@ -230,11 +230,11 @@ core_initcall(cma_init_reserved_areas);
* called by board specific code when early allocator (memblock or bootmem)
* is still activate.
*/
-int __init dma_declare_contiguous(struct device *dev, unsigned long size,
+int __init dma_declare_contiguous(struct device *dev, phys_addr_t size,
phys_addr_t base, phys_addr_t limit)
{
struct cma_reserved *r = cma_reserved[cma_reserved_count];
- unsigned long alignment;
+ phys_addr_t alignment;
pr_debug(%s(size %lx, base %08lx, limit %08lx)\n, __func__,
(unsigned long)size, (unsigned long)base,
@@ -271,10 +271,6 @@ int __init dma_declare_contiguous(struct device *dev,
unsigned long size,
if (!addr) {
base = -ENOMEM;
goto err;
- } else if (addr + size ~(unsigned long)0) {
- memblock_free(addr, size);
- base = -EINVAL;
- goto err;
} else {
base = addr;
}
@@ -288,14 +284,14 @@ int __init dma_declare_contiguous(struct device *dev,
unsigned long size,
r-size = size;
r-dev = dev;
cma_reserved_count++;
- pr_info(CMA: reserved %ld MiB at %08lx\n, size / SZ_1M,
+ pr_info(CMA: reserved %ld MiB at %08lx\n, (unsigned long)size / SZ_1M,
(unsigned long)base);
/* Architecture specific contiguous memory fixup. */
dma_contiguous_early_fixup(base, size);
return 0;
err:
- pr_err(CMA: failed to reserve %ld MiB\n, size / SZ_1M);
+ pr_err(CMA: failed to reserve %ld MiB\n, (unsigned long)size / SZ_1M);
return base;
}
diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
index 2f303e4..01b5c84 100644
--- a/include/linux/dma-contiguous.h
+++ b/include/linux/dma-contiguous.h
@@ -68,7 +68,7 @@ struct device;
extern struct cma *dma_contiguous_default_area;
void dma_contiguous_reserve(phys_addr_t addr_limit);
-int dma_declare_contiguous(struct device *dev, unsigned long size,
+int dma_declare_contiguous(struct device *dev, phys_addr_t size,
phys_addr_t base, phys_addr_t limit);
struct page *dma_alloc_from_contiguous(struct device *dev, int count,
@@ -83,7 +83,7 @@ bool dma_release_from_contiguous(struct device *dev, struct
page *pages,
static inline
Re: [PATCH 1/2] Staging: android: binder: Add support for 32bit binder calls in a 64bit kernel
On 04/12/12 16:17, Greg KH wrote: On Tue, Dec 04, 2012 at 10:44:13AM +, Serban Constantinescu wrote: Android's IPC, Binder, does not support calls from a 32-bit userspace in a 64 bit kernel. This patch adds support for syscalls coming from a 32-bit userspace in a 64-bit kernel. Most of the changes were applied to types that change sizes between 32 and 64 bit world. This will also fix some of the issues around checking the size of an incoming transaction package in the ioctl switch. Since the transaction's ioctl number are generated using _IOC(dir,type,nr,size), a different userspace size will generate a different ioctl number, thus switching by _IOC_NR is a better solution. The patch has been successfully tested on ARMv8 AEM and Versatile Express V2P-CA9. Has it also been properly tested on a 32bit kernel and userspace to verify that nothing broke? We have tested this patch set with a 32-bit kernel (on a Versatile Express platform with an 4xA9 (ARMv7a)) as well as a 64-bit kernel (on ARMv8 simulation platform). For both test cases we used the same 32-bit Android file system (ICS, JB). Both platforms have been running browser loads for days without any problems. We are currently extending the test cases by running Android CTS test. I was wondering when someone would notice that this code was not going to work for this type of system, nice to see that you are working to fix it up. But, I'll reask Dan's question here, why not use the compat32 ioctl interface instead? Shouldn't that be the easier way to do this? Binder uses a 2 layer ioctl structure i.e. you can't know from the top of the ioctl handler the size of the incoming package. Therefore adding a wrapper for a 64bit kernel is not an option. Should a 64bit Android ever appear we would probably want to support 32bit legacy applications. For this we will need the same binder/ashmem driver to service both a 32bit application as well as a 64bit application in a 64bit kernel. Therefore I guess the way forward will be to support 32bit file systems in a 64bit kernel without any change to the existing user space (implemented in this patch) and at some point extend the ioctl range with the needed functionality for 64bit user space. Also, one meta comment, never use the uint32_t types, use the native kernel types (u32 and the like.) If you are crossing the user/kernel boundry, use the other correct types for those data structures (__u32 and the like). What you did here is mix and match things so much that I really can't verify that it is all correct. I have tried to in-line my changes with the types already used in the driver but I will update to using the suggested types. thanks, greg k-h Thanks for the feedback, Serban Constantinescu ` -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 2/3] aerdrv: Enhanced AER logging
On Tue, Dec 04, 2012 at 02:03:12PM -0700, Lance Ortiz wrote:
This patch will provide a more reliable and easy way for user-space
applications to have access to AER logs rather than reading them from the
message buffer. It also provides a way to notify user-space when an AER
event occurs.
The aer driver is updated to generate a trace event of function 'aer_event'
when a PCIe error is reported over the AER interface. The trace event was
added to both the interrupt based aer path and the firmware first path.
v1-v2 fix compile errors in ifdefs.
v2-v3 Update to new location of trace header. Update print to remove
warning.
v3-v4 Reworked logic when getting ready to call cper_print_aer
v6-v7 Change print from pr_info to pr_err if !dev
Signed-off-by: Lance Ortiz lance.or...@hp.com
---
drivers/acpi/apei/cper.c | 19 ---
drivers/pci/pcie/aer/aerdrv_errprint.c | 10 +-
include/linux/aer.h|2 +-
3 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/apei/cper.c b/drivers/acpi/apei/cper.c
index e6defd8..b2f695b 100644
--- a/drivers/acpi/apei/cper.c
+++ b/drivers/acpi/apei/cper.c
@@ -29,6 +29,7 @@
#include linux/time.h
#include linux/cper.h
#include linux/acpi.h
+#include linux/pci.h
#include linux/aer.h
/*
@@ -249,6 +250,10 @@ static const char *cper_pcie_port_type_strs[] = {
static void cper_print_pcie(const char *pfx, const struct cper_sec_pcie
*pcie,
const struct acpi_hest_generic_data *gdata)
{
+#ifdef CONFIG_ACPI_APEI_PCIEAER
+ struct pci_dev *dev;
+#endif
+
if (pcie-validation_bits CPER_PCIE_VALID_PORT_TYPE)
printk(%sport_type: %d, %s\n, pfx, pcie-port_type,
pcie-port_type ARRAY_SIZE(cper_pcie_port_type_strs) ?
@@ -281,10 +286,18 @@ static void cper_print_pcie(const char *pfx, const
struct cper_sec_pcie *pcie,
%sbridge: secondary_status: 0x%04x, control: 0x%04x\n,
pfx, pcie-bridge.secondary_status, pcie-bridge.control);
#ifdef CONFIG_ACPI_APEI_PCIEAER
- if (pcie-validation_bits CPER_PCIE_VALID_AER_INFO) {
- struct aer_capability_regs *aer_regs = (void *)pcie-aer_info;
- cper_print_aer(pfx, gdata-error_severity, aer_regs);
+ dev = pci_get_domain_bus_and_slot(pcie-device_id.segment,
+ pcie-device_id.bus, pcie-device_id.function);
+ if (!dev) {
+ pr_err(PCI AER Cannot get PCI device %04x:%02x:%02x.%d\n,
+ pcie-device_id.segment, pcie-device_id.bus,
+ pcie-device_id.slot, pcie-device_id.function);
+ return;
}
+ if (pcie-validation_bits CPER_PCIE_VALID_AER_INFO)
+ cper_print_aer(dev, gdata-error_severity,
+ (struct aer_capability_regs *) pcie-aer_info);
+ pci_dev_put(dev);
#endif
}
diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c
b/drivers/pci/pcie/aer/aerdrv_errprint.c
index 3ea5173..34d96e4 100644
--- a/drivers/pci/pcie/aer/aerdrv_errprint.c
+++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
@@ -23,6 +23,9 @@
#include aerdrv.h
+#define CREATE_TRACE_POINTS
+#include trace/events/ras.h
+
#define AER_AGENT_RECEIVER 0
#define AER_AGENT_REQUESTER 1
#define AER_AGENT_COMPLETER 2
@@ -194,6 +197,8 @@ void aer_print_error(struct pci_dev *dev, struct
aer_err_info *info)
if (info-id info-error_dev_num 1 info-id == id)
printk(%s Error of this Agent(%04x) is reported first\n,
prefix, id);
+ trace_aer_event(dev_name(dev-dev), (info-status ~info-mask),
+ info-severity);
}
void aer_print_port_info(struct pci_dev *dev, struct aer_err_info *info)
@@ -217,12 +222,13 @@ int cper_severity_to_aer(int cper_severity)
}
EXPORT_SYMBOL_GPL(cper_severity_to_aer);
-void cper_print_aer(const char *prefix, int cper_severity,
+void cper_print_aer(struct pci_dev *dev, int cper_severity,
struct aer_capability_regs *aer)
{
int aer_severity, layer, agent, status_strs_size, tlp_header_valid = 0;
u32 status, mask;
const char **status_strs;
+ char *prefix = NULL;
What are you doing here? You dropped the 'prefix' argument being passed
down in this function and are defining a local variable of the same name
which is used in the function later:
printk(%saer_status: 0x%08x, aer_mask: 0x%08x\n,
prefix, status, mask);
WTF?
Also, this function cper_print_aer() is too crammed and could use a
little spacing out between lines belonging logically together.
Finally, please wait a couple of days before resending the patchset
so that you can collect *all* feedback and can save yourself needless
iterations.
Thanks.
--
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Re: [PATCH] fs:ext3: remove lock_buffer in bclean() and setup_new_group_blocks
On Sun 02-12-12 01:40:28, Cong Ding wrote:
it's not necessary to lock the buffers because no one touches them
beyond the file system.
Although I agree those locks are not strictly necessary, I prefer to keep
them because the general rula is buffer contents should be changed under
buffer lock unless we have a good reason to do otherwise. And here the cost
of additional lock is really marginal...
Honza
Signed-off-by: Cong Ding ding...@gmail.com
---
fs/ext3/resize.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/fs/ext3/resize.c b/fs/ext3/resize.c
index 0f814f3..f76fcd6 100644
--- a/fs/ext3/resize.c
+++ b/fs/ext3/resize.c
@@ -122,10 +122,8 @@ static struct buffer_head *bclean(handle_t *handle,
struct super_block *sb,
brelse(bh);
bh = ERR_PTR(err);
} else {
- lock_buffer(bh);
memset(bh-b_data, 0, sb-s_blocksize);
set_buffer_uptodate(bh);
- unlock_buffer(bh);
}
return bh;
@@ -242,10 +240,8 @@ static int setup_new_group_blocks(struct super_block *sb,
brelse(gdb);
goto exit_bh;
}
- lock_buffer(gdb);
memcpy(gdb-b_data, sbi-s_group_desc[i]-b_data, gdb-b_size);
set_buffer_uptodate(gdb);
- unlock_buffer(gdb);
err = ext3_journal_dirty_metadata(handle, gdb);
if (err) {
brelse(gdb);
--
1.7.4.5
--
Jan Kara j...@suse.cz
SUSE Labs, CR
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 3/3] aerdrv: Cleanup log output for CPER based AER
Em Tue, 04 Dec 2012 14:03:18 -0700
Lance Ortiz lance.or...@hp.com escreveu:
Hmm... I did a reply to v6 of this patch, but i pressed the wrong button
and it went only to Joe. Excuse-me for that. Let me resend the
comments to everybody:
On Tue, 2012-12-04 at 16:33 -0200, Mauro Carvalho Chehab wrote:
Em Tue, 04 Dec 2012 09:39:23 -0800
Joe Perches j...@perches.com escreveu:
On Tue, 2012-12-04 at 10:04 -0700, Lance Ortiz wrote:
These changes make cper_print_aer more consistent with aer_print_error
which is called in the AER interrupt case. The string in the variable
'prefix' is printed at the beginning of each print statement in
cper_print_aer(). The prefix is a string containing the driver name
and the device's slot location. From the callers the value of prefix
is never assigned and is NULL, so when cper_print_aer prints data the
initial string does not get printed. This string is important because
it identifies the device that the error is on.
Hi again Lance.
diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c
b/drivers/pci/pcie/aer/aerdrv_errprint.c
[]
@@ -228,9 +228,14 @@ void cper_print_aer(struct pci_dev *dev, int
cper_severity,
int aer_severity, layer, agent, status_strs_size, tlp_header_valid = 0;
u32 status, mask;
const char **status_strs;
- char *prefix = NULL;
+ char prefix[44];
aer_severity = cper_severity_to_aer(cper_severity);
+ snprintf(prefix, sizeof(prefix), %s%s %s: ,
+ (aer_severity == AER_CORRECTABLE) ?
+ KERN_WARNING : KERN_ERR,
+ dev_driver_string(dev-dev), dev_name(dev-dev));
+
if (aer_severity == AER_CORRECTABLE) {
status = aer-cor_status;
mask = aer-cor_mask;
Perhaps this would be better just using dev_printk
instead of snprintf into a prefix with printk to
emulate dev_printk.
Also, perhaps KERN_NOTICE is preferable to KERN_WARNING
in the CORRECTABLE case.
Hmm... IMHO, it should be KERN_ERR, even for a correctable one ;)
This is an error and probably means some hardware problem or a bad
contact. In any case, a preventive action is likely required.
Maybe something like:
const char *level = KERN_ERR;
if (aer_severity == AER_CORRECTABLE)
level = KERN_NOTICE;
...
dev_printk(level, dev-dev, etc...);
Maybe do this after this series of patches is accepted.
Enough with the revisions for awhile...
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 3/3] aerdrv: Cleanup log output for CPER based AER
On Tue, Dec 04, 2012 at 02:03:18PM -0700, Lance Ortiz wrote: These changes make cper_print_aer more consistent with aer_print_error which is called in the AER interrupt case. The string in the variable 'prefix' is printed at the beginning of each print statement in cper_print_aer(). The prefix is a string containing the driver name and the device's slot location. From the callers the value of prefix is never assigned and is NULL, so when cper_print_aer prints data the initial string does not get printed. This string is important because it identifies the device that the error is on. v1-v2 fix some compile errors withinn the #ifdef v3-v4 remove agent id stuff and kept print the same to avoid compatibility issues Signed-off-by: Lance Ortiz lance.or...@hp.com --- drivers/pci/pcie/aer/aerdrv_errprint.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c b/drivers/pci/pcie/aer/aerdrv_errprint.c index 34d96e4..58ff4c0 100644 --- a/drivers/pci/pcie/aer/aerdrv_errprint.c +++ b/drivers/pci/pcie/aer/aerdrv_errprint.c @@ -228,9 +228,14 @@ void cper_print_aer(struct pci_dev *dev, int cper_severity, int aer_severity, layer, agent, status_strs_size, tlp_header_valid = 0; u32 status, mask; const char **status_strs; - char *prefix = NULL; + char prefix[44]; aer_severity = cper_severity_to_aer(cper_severity); + snprintf(prefix, sizeof(prefix), %s%s %s: , + (aer_severity == AER_CORRECTABLE) ? + KERN_WARNING : KERN_ERR, + dev_driver_string(dev-dev), dev_name(dev-dev)); Here it is, you're initializing 'prefix' here although it is being used in the previous patch. You should concentrate the whole prefix initialization and passing in one patch so that there are no breakages. Also, why is it exactly 44 chars long, is that some magic number that always works? At least this is what aer_print_error does too. I'm guessing someone chose it because it is large enough for dev_driver_string() and dev_name() and a couple more formatting characters. Oh well. Thanks. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Staging: android: binder: Add support for 32bit binder calls in a 64bit kernel
On 05/12/12 00:26, Arve Hjønnevåg wrote:
On Tue, Dec 4, 2012 at 2:44 AM, Serban Constantinescu
serban.constantine...@arm.com wrote:
Android's IPC, Binder, does not support calls from a 32-bit userspace
in a 64 bit kernel. This patch adds support for syscalls coming from a
32-bit userspace in a 64-bit kernel.
It also seems to remove support for 64-bit user-space in a 64 bit
kernel at the same time. While we have not started fixing this problem
yet, it is not clear that we want to go in this direction. If we want
to have any 64 bit user-space processes, the 32-bit processes need to
use 64 bit pointers when talking to other processes. It may make more
sense to change the user-space binder library to probe for needed
pointer size (either by adding an ioctl to the driver to return the
pointer size in an ioctl with a fixed size pointer or by calling
BINDER_VERSION with the two pointer sizes you support (assuming long
and void * are the same size)).
Thanks for the feedback! As described in my previous e-mail, since the
binder uses 2 layer ioctl we can't know from the top of the ioctl
handler what is the size of the incoming package. Therefore we can't
have the same ioctl call servicing both 32bit requests and 64bit
requests in a 64bit kernel. I consider that the way forward would be to
support the existing 32bit user space in a 64bit kernel (allowing
backwards compatibility and what this patch implements) and to extend
the ioctl space with the needed functionality when and if we will get to
64bit Android. Please correct me if I am wrong.
Most of the changes were applied to types that change sizes between
32 and 64 bit world. This will also fix some of the issues around
checking the size of an incoming transaction package in the ioctl
switch. Since the transaction's ioctl number are generated using
_IOC(dir,type,nr,size), a different userspace size will generate
a different ioctl number, thus switching by _IOC_NR is a better
solution.
I don't understand this change. If you use _IOC_NR you lose the
protection that the _IOC macros added. If the size does not match you
still dereference the pointer using the size that the kernel has
(expect where you added a new size check to replace the one you
removed).
Take the following snippet as an example:
static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
unsigned int size = _IOC_SIZE(cmd);
switch (cmd) {
case BINDER_WRITE_READ: {
struct binder_write_read bwr;
if (size != sizeof(struct binder_write_read)) {
ret = -EINVAL;
goto err;
}
since BINDER_WRITE_READ is defined as:
#define BINDER_WRITE_READ _IOWR('b', 1, struct binder_write_read)
the size checking done here is not of any use since a different size
would fall in default. Therefore I thought a nicer version would be to
switch by the _IOC_NR() - in this case 1, but with the protection
offered by dir - 'b'. Once again correct me if I am wrong.
Kind regards,
Serban Constantinescu
`
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] HDA: Add PCI device prefix for clarity
When printing, use a prefix of the PCI domain, bus, device and function
as in other drivers, to differentiate multiple devices.
Important for reporting and debugging. A future step is to tidy this up with
dev_printk et al.
v2: Move conversion specifier into call site, preventing build issues
v3: Refactor for Takashi's for-next branch
Signed-off-by: Daniel J Blueman dan...@quora.org
---
sound/pci/hda/hda_intel.c | 125 +++--
1 file changed, 64 insertions(+), 61 deletions(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 22ecadc..eb48109 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -192,7 +192,7 @@ MODULE_DESCRIPTION(Intel HDA driver);
#ifdef CONFIG_SND_VERBOSE_PRINTK
#define SFX/* nop */
#else
-#define SFXhda-intel:
+#define SFXhda-intel
#endif
#if defined(CONFIG_PM) defined(CONFIG_VGA_SWITCHEROO)
@@ -717,7 +717,7 @@ static int azx_alloc_cmd_io(struct azx *chip)
snd_dma_pci_data(chip-pci),
PAGE_SIZE, chip-rb);
if (err 0) {
- snd_printk(KERN_ERR SFX cannot allocate CORB/RIRB\n);
+ snd_printk(KERN_ERR SFX %s: cannot allocate CORB/RIRB\n,
pci_name(chip-pci));
return err;
}
mark_pages_wc(chip, chip-rb, true);
@@ -894,9 +894,9 @@ static unsigned int azx_rirb_get_response(struct hda_bus
*bus,
}
if (!chip-polling_mode chip-poll_count 2) {
- snd_printdd(SFX azx_get_response timeout,
+ snd_printdd(SFX %s: azx_get_response timeout,
polling the codec once: last cmd=0x%08x\n,
- chip-last_cmd[addr]);
+ pci_name(chip-pci), chip-last_cmd[addr]);
do_poll = 1;
chip-poll_count++;
goto again;
@@ -904,17 +904,17 @@ static unsigned int azx_rirb_get_response(struct hda_bus
*bus,
if (!chip-polling_mode) {
- snd_printk(KERN_WARNING SFX azx_get_response timeout,
+ snd_printk(KERN_WARNING SFX %s: azx_get_response timeout,
switching to polling mode: last cmd=0x%08x\n,
- chip-last_cmd[addr]);
+ pci_name(chip-pci), chip-last_cmd[addr]);
chip-polling_mode = 1;
goto again;
}
if (chip-msi) {
- snd_printk(KERN_WARNING SFX No response from codec,
+ snd_printk(KERN_WARNING SFX %s: No response from codec,
disabling MSI: last cmd=0x%08x\n,
- chip-last_cmd[addr]);
+ pci_name(chip-pci), chip-last_cmd[addr]);
free_irq(chip-irq, chip);
chip-irq = -1;
pci_disable_msi(chip-pci);
@@ -980,8 +980,8 @@ static int azx_single_wait_for_response(struct azx *chip,
unsigned int addr)
udelay(1);
}
if (printk_ratelimit())
- snd_printd(SFX get_response timeout: IRS=0x%x\n,
- azx_readw(chip, IRS));
+ snd_printd(SFX %s: get_response timeout: IRS=0x%x\n,
+ pci_name(chip-pci), azx_readw(chip, IRS));
chip-rirb.res[addr] = -1;
return -EIO;
}
@@ -1008,8 +1008,8 @@ static int azx_single_send_cmd(struct hda_bus *bus, u32
val)
udelay(1);
}
if (printk_ratelimit())
- snd_printd(SFX send_cmd timeout: IRS=0x%x, val=0x%x\n,
- azx_readw(chip, IRS), val);
+ snd_printd(SFX %s: send_cmd timeout: IRS=0x%x, val=0x%x\n,
+ pci_name(chip-pci), azx_readw(chip, IRS), val);
return -EIO;
}
@@ -1095,7 +1095,7 @@ static int azx_reset(struct azx *chip, int full_reset)
__skip:
/* check to see if controller is ready */
if (!azx_readb(chip, GCTL)) {
- snd_printd(SFX azx_reset: controller not ready!\n);
+ snd_printd(SFX %s: azx_reset: controller not ready!\n,
pci_name(chip-pci));
return -EBUSY;
}
@@ -1107,7 +1107,7 @@ static int azx_reset(struct azx *chip, int full_reset)
/* detect codecs */
if (!chip-codec_mask) {
chip-codec_mask = azx_readw(chip, STATESTS);
- snd_printdd(SFX codec_mask = 0x%x\n, chip-codec_mask);
+ snd_printdd(SFX %s: codec_mask = 0x%x\n, pci_name(chip-pci),
chip-codec_mask);
}
return 0;
@@ -1251,7 +1251,7 @@ static void azx_init_pci(struct azx *chip)
* The PCI register TCSEL is defined in the Intel manuals.
*/
if (!(chip-driver_caps AZX_DCAPS_NO_TCSEL)) {
- snd_printdd(SFX Clearing TCSEL\n);
+ snd_printdd(SFX %s: Clearing TCSEL\n, pci_name(chip-pci));
Re: [PATCH] net/macb: increase RX buffer size for GEM
On 12/04/2012 07:22 PM, David Miller : From: Nicolas Ferre nicolas.fe...@atmel.com Date: Mon, 3 Dec 2012 13:15:43 +0100 Macb Ethernet controller requires a RX buffer of 128 bytes. It is highly sub-optimal for Gigabit-capable GEM that is able to use a bigger DMA buffer. Change this constant and associated macros with data stored in the private structure. I also kept the result of buffers per page calculation to lower the impact of this move to a variable rx buffer size on rx hot path. RX DMA buffer size has to be multiple of 64 bytes as indicated in DMA Configuration Register specification. Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com This looks like it will waste a couple hundred bytes for 1500 MTU frames, am I right? Yep! But buffers get recycled, and with the current memory management by pages, it seems that I have to rework some part of it to optimize this memory usage (8KB memory blocks split into 5 buffers each as David said...). Do you think it is worth digging this way or may I rework the rx buffer management in case of the GEM interface. If I implement a different path for GEM interface, I will have the possibility to tailor rx DMA buffers from 1500 Bytes up to 10KB jumbo frames... Best regards, -- Nicolas Ferre -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Staging: android: binder: Add support for 32bit binder calls in a 64bit kernel
On Wed, Dec 05, 2012 at 02:31:02PM +, Serban Constantinescu wrote: -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. Email footers like this, sent to public mailing lists, cause me to delete the emails without reading them, sorry. Normally the list can filter these emails away, I'll work on updating the rules. Please fix your email to not have these if you wish to contribute to Linux kernel development. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] HDA: Add PCI device prefix for clarity
At Wed, 5 Dec 2012 23:04:21 +0800,
Daniel J Blueman wrote:
When printing, use a prefix of the PCI domain, bus, device and function
as in other drivers, to differentiate multiple devices.
Important for reporting and debugging. A future step is to tidy this up with
dev_printk et al.
v2: Move conversion specifier into call site, preventing build issues
v3: Refactor for Takashi's for-next branch
Signed-off-by: Daniel J Blueman dan...@quora.org
Thanks, applied now.
Takashi
---
sound/pci/hda/hda_intel.c | 125
+++--
1 file changed, 64 insertions(+), 61 deletions(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 22ecadc..eb48109 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -192,7 +192,7 @@ MODULE_DESCRIPTION(Intel HDA driver);
#ifdef CONFIG_SND_VERBOSE_PRINTK
#define SFX /* nop */
#else
-#define SFX hda-intel:
+#define SFX hda-intel
#endif
#if defined(CONFIG_PM) defined(CONFIG_VGA_SWITCHEROO)
@@ -717,7 +717,7 @@ static int azx_alloc_cmd_io(struct azx *chip)
snd_dma_pci_data(chip-pci),
PAGE_SIZE, chip-rb);
if (err 0) {
- snd_printk(KERN_ERR SFX cannot allocate CORB/RIRB\n);
+ snd_printk(KERN_ERR SFX %s: cannot allocate CORB/RIRB\n,
pci_name(chip-pci));
return err;
}
mark_pages_wc(chip, chip-rb, true);
@@ -894,9 +894,9 @@ static unsigned int azx_rirb_get_response(struct hda_bus
*bus,
}
if (!chip-polling_mode chip-poll_count 2) {
- snd_printdd(SFX azx_get_response timeout,
+ snd_printdd(SFX %s: azx_get_response timeout,
polling the codec once: last cmd=0x%08x\n,
-chip-last_cmd[addr]);
+pci_name(chip-pci), chip-last_cmd[addr]);
do_poll = 1;
chip-poll_count++;
goto again;
@@ -904,17 +904,17 @@ static unsigned int azx_rirb_get_response(struct
hda_bus *bus,
if (!chip-polling_mode) {
- snd_printk(KERN_WARNING SFX azx_get_response timeout,
+ snd_printk(KERN_WARNING SFX %s: azx_get_response timeout,
switching to polling mode: last cmd=0x%08x\n,
-chip-last_cmd[addr]);
+pci_name(chip-pci), chip-last_cmd[addr]);
chip-polling_mode = 1;
goto again;
}
if (chip-msi) {
- snd_printk(KERN_WARNING SFX No response from codec,
+ snd_printk(KERN_WARNING SFX %s: No response from codec,
disabling MSI: last cmd=0x%08x\n,
-chip-last_cmd[addr]);
+pci_name(chip-pci), chip-last_cmd[addr]);
free_irq(chip-irq, chip);
chip-irq = -1;
pci_disable_msi(chip-pci);
@@ -980,8 +980,8 @@ static int azx_single_wait_for_response(struct azx *chip,
unsigned int addr)
udelay(1);
}
if (printk_ratelimit())
- snd_printd(SFX get_response timeout: IRS=0x%x\n,
-azx_readw(chip, IRS));
+ snd_printd(SFX %s: get_response timeout: IRS=0x%x\n,
+pci_name(chip-pci), azx_readw(chip, IRS));
chip-rirb.res[addr] = -1;
return -EIO;
}
@@ -1008,8 +1008,8 @@ static int azx_single_send_cmd(struct hda_bus *bus, u32
val)
udelay(1);
}
if (printk_ratelimit())
- snd_printd(SFX send_cmd timeout: IRS=0x%x, val=0x%x\n,
-azx_readw(chip, IRS), val);
+ snd_printd(SFX %s: send_cmd timeout: IRS=0x%x, val=0x%x\n,
+pci_name(chip-pci), azx_readw(chip, IRS), val);
return -EIO;
}
@@ -1095,7 +1095,7 @@ static int azx_reset(struct azx *chip, int full_reset)
__skip:
/* check to see if controller is ready */
if (!azx_readb(chip, GCTL)) {
- snd_printd(SFX azx_reset: controller not ready!\n);
+ snd_printd(SFX %s: azx_reset: controller not ready!\n,
pci_name(chip-pci));
return -EBUSY;
}
@@ -1107,7 +1107,7 @@ static int azx_reset(struct azx *chip, int full_reset)
/* detect codecs */
if (!chip-codec_mask) {
chip-codec_mask = azx_readw(chip, STATESTS);
- snd_printdd(SFX codec_mask = 0x%x\n, chip-codec_mask);
+ snd_printdd(SFX %s: codec_mask = 0x%x\n, pci_name(chip-pci),
chip-codec_mask);
}
return 0;
@@ -1251,7 +1251,7 @@ static void azx_init_pci(struct azx *chip)
* The PCI register TCSEL is defined in the Intel manuals.
*/
if (!(chip-driver_caps AZX_DCAPS_NO_TCSEL)) {
- snd_printdd(SFX Clearing TCSEL\n);
+
Re: [PATCH v2] net/macb: Use non-coherent memory for rx buffers
On 12/05/2012 10:35 AM, David Laight : If I understand well, you mean that the call to: dma_sync_single_range_for_device(bp-pdev-dev, phys, pg_offset, frag_len, DMA_FROM_DEVICE); in the rx path after having copied the data to skb is not needed? That is also the conclusion that I found after having thinking about this again... I will check this. You need to make sure that the memory isn't in the data cache when you give the rx buffer back to the MAC. (and ensure the cpu doesn't read it until the rx is complete.) I've NFI what that dma_sync call does - you need to invalidate the cache lines. The invalidate of cache lines is done by dma_sync_single_range_for_device(, DMA_FROM_DEVICE) so I need to keep it. For the CRC, my driver is not using the CRC offloading feature for the moment. So no CRC is written by the device. I was thinking it would matter if the MAC wrote the CRC into the buffer (even though it was excluded from the length). It doesn't - you only need to worry about data you've read. I was wondering if the code needs to do per page allocations? Perhaps that is necessary to avoid needing a large block of contiguous physical memory (and virtual addresses)? The page management seems interesting for future management of RX buffers as skb fragments: that will allow to avoid copying received data. Dunno - the complexities of such buffer loaning schemes often exceed the gain of avoiding the data copy. Using buffers allocated to the skb is a bit different - since you completely forget about the memory once you pass the skb upstream. Some quick sums indicate you might want to allocate 8k memory blocks and split into 5 buffers. Well, for the 10/100 MACB interface, I am stuck with 128 Bytes buffers! So this use of pages seems sensible. On the other hand, it is true that I may have to reconsider the GEM memory management (it one is able to cover 128-10KB rx DMA buffers)... Best regards, -- Nicolas Ferre -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Look Ma, da kernel is b0rken
On Wed, 5 Dec 2012 15:29:35 +0100 Borislav Petkov b...@alien8.de wrote: On Wed, Dec 05, 2012 at 08:09:01AM +0100, Andreas Mohr wrote: Hi, drivers/pnp/pnpacpi/core.c: In function 'ispnpidacpi': drivers/pnp/pnpacpi/core.c:65:2: warning: logical 'or' of collectively exhaustive tests is always true [-Wlogical-op] drivers/pnp/pnpacpi/core.c:66:2: warning: logical 'or' of collectively exhaustive tests is always true [-Wlogical-op] drivers/pnp/pnpacpi/core.c:67:2: warning: logical 'or' of collectively exhaustive tests is always true [-Wlogical-op] That's already the second less enticing -Wlogical-op issue which was discovered by accident during less than two days No it's not. It's been reported in bugzilla. I sent patches ages ago. They were ignored. Coverity has had it tagged for years (and a ton more of them you've not noticed yet) http://article.gmane.org/gmane.linux.acpi.devel/56753/match=test_alpha This isn't discovered, this is in the If you stick your fingers in your ears and hum you can't hear the screaming category. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2] net/macb: Use non-coherent memory for rx buffers
Well, for the 10/100 MACB interface, I am stuck with 128 Bytes buffers! So this use of pages seems sensible. If you have dma coherent memory you can make the rx buffer space be an array of short buffers referenced by adjacent ring entries (possibly with the last one slightly short to allow for the 2 byte offset). Then, when a big frame ends up in multiple buffers, you need a maximum of two copies to extract the data. David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUGFIX PATCH] rtc: eliminate extra call of ida_simple_remove()
Unbinding an RTC chip driver from its device leads to the error message: |ida_remove called for id=0 which is not allocated. This is caused by a redundant call to ida_simple_remove() in rtc_device_unregister(). Eliminate the call in rtc_device_unregister() and only call the function in rtc_device_release(). Signed-off-by: Lothar Waßmann l...@karo-electronics.de --- drivers/rtc/class.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c index f8a0aab..5143629 100644 --- a/drivers/rtc/class.c +++ b/drivers/rtc/class.c @@ -244,7 +244,6 @@ void rtc_device_unregister(struct rtc_device *rtc) rtc_proc_del_device(rtc); device_unregister(rtc-dev); rtc-ops = NULL; - ida_simple_remove(rtc_ida, rtc-id); mutex_unlock(rtc-ops_lock); put_device(rtc-dev); } -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Look Ma, da kernel is b0rken
On Wed, Dec 05, 2012 at 03:27:56PM +, Alan Cox wrote: On Wed, 5 Dec 2012 15:29:35 +0100 Borislav Petkov b...@alien8.de wrote: On Wed, Dec 05, 2012 at 08:09:01AM +0100, Andreas Mohr wrote: Hi, drivers/pnp/pnpacpi/core.c: In function 'ispnpidacpi': drivers/pnp/pnpacpi/core.c:65:2: warning: logical 'or' of collectively exhaustive tests is always true [-Wlogical-op] drivers/pnp/pnpacpi/core.c:66:2: warning: logical 'or' of collectively exhaustive tests is always true [-Wlogical-op] drivers/pnp/pnpacpi/core.c:67:2: warning: logical 'or' of collectively exhaustive tests is always true [-Wlogical-op] That's already the second less enticing -Wlogical-op issue which was discovered by accident during less than two days No it's not. It's been reported in bugzilla. I sent patches ages ago. They were ignored. Coverity has had it tagged for years (and a ton more of them you've not noticed yet) http://article.gmane.org/gmane.linux.acpi.devel/56753/match=test_alpha This isn't discovered, this is in the If you stick your fingers in your ears and hum you can't hear the screaming category. Hillarious! Andrew, would you please pick up Alan's patch? It clearly fixes an ancient bug in the pnpacpi code. Thanks. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel BUG at /build/buildd/linux-2.6.32/mm/mempolicy.c
Hello. We have several servers with mongodb running. Each server has several mongodb instances. Mongodb dataset is larger then availiable memory (mongodb uses memory-mapped files for all disk I/O). 2.6.32 and 2.6.38 kernels periodically crash and crash happens only with mongodb servers. 2.6.38's trace is in attachment. For 2.6.32 I only have kernel BUG at /build/buildd/linux-2.6.32/mm/mempolicy.c:1489! Heed help! :) [10153.490832] [ cut here ] [10153.495452] kernel BUG at /build/buildd/linux-lts-backport-natty-2.6.38/mm/mempolicy.c:1606! [10153.503879] invalid opcode: [#1] SMP [10153.508007] last sysfs file: /sys/module/megaraid_sas/version [10153.513752] CPU 2 [10153.515594] Modules linked in: ipmi_si ipmi_devintf ipmi_msghandler ghes lp psmouse i7core_edac edac_core hed serio_raw joydev ioatdma parport usbhid hid igb megaraid_sas dca [10153.531904] [10153.533412] Pid: 34275, comm: mongod Not tainted 2.6.38-15-server #66~lucid1-Ubuntu Supermicro X8DTT/X8DTT [10153.543178] RIP: 0010:[81148afe] [81148afe] slab_node+0x2e/0x90 [10153.550965] RSP: 0018:8800bf443890 EFLAGS: 00010097 [10153.556287] RAX: RBX: 88063f802800 RCX: [10153.563434] RDX: 03e8 RSI: 0020 RDI: 880553a40e70 [10153.570582] RBP: 8800bf4438a0 R08: 03e8 R09: 8153dcc1 [10153.577736] R10: e2979754 R11: 0002 R12: 0020 [10153.584876] R13: 0002 R14: 8800bf4438c8 R15: [10153.592084] FS: () GS:8800bf44() knlGS: [10153.600200] CS: 0010 DS: ES: CR0: 80050033 [10153.605952] CR2: 7f61f0221fd8 CR3: 00060bc84000 CR4: 06e0 [10153.613090] DR0: DR1: DR2: [10153.620289] DR3: DR6: 0ff0 DR7: 0400 [10153.627428] Process mongod (pid: 34275, threadinfo 880b8cac6000, task 880b3f6cc4a0) [10153.635794] Stack: [10153.637827] 8800bf453cc0 8800bf453cc0 8800bf443900 81151dd0 [10153.645330] 0086 880b3f6cc4a0 8800bf443930 8105f7f3 [10153.652831] 8800bf443940 88063f802800 [10153.660334] Call Trace: [10153.662799] IRQ [10153.664939] [81151dd0] get_any_partial+0xa0/0x190 [10153.670606] [8105f7f3] ? try_to_wake_up+0xc3/0x410 [10153.676369] [81153f2b] __slab_alloc+0x1eb/0x320 [10153.681864] [8153dcc1] ? tcp_v4_conn_request+0x101/0x6b0 [10153.688143] [811549e2] kmem_cache_alloc+0x102/0x110 [10153.693986] [81038d99] ? default_spin_lock_flags+0x9/0x10 [10153.700353] [8153dcc1] tcp_v4_conn_request+0x101/0x6b0 [10153.706455] [814d597c] ? sk_reset_timer+0x1c/0x30 [10153.712130] [815342c3] tcp_rcv_state_process+0xc3/0x4f0 [10153.718325] [8153c0b3] tcp_v4_do_rcv+0xa3/0x1c0 [10153.723818] [8153d929] tcp_v4_rcv+0x5a9/0x840 [10153.729141] [812d88c3] ? cpumask_next_and+0x23/0x40 [10153.734991] [8151a58d] ip_local_deliver_finish+0xdd/0x290 [10153.741356] [8151a7c0] ip_local_deliver+0x80/0x90 [10153.747025] [81519d91] ip_rcv_finish+0x121/0x3f0 [10153.752605] [8151a3dd] ip_rcv+0x23d/0x310 [10153.757580] [814e404a] __netif_receive_skb+0x40a/0x690 [10153.763679] [814e9700] netif_receive_skb+0x80/0x90 [10153.769434] [814e9860] napi_skb_finish+0x50/0x70 [10153.775014] [814e9d05] napi_gro_receive+0xc5/0xd0 [10153.780687] [a0038eec] igb_poll+0x71c/0x1220 [igb] [10153.786454] [81052775] ? enqueue_entity+0x145/0x290 [10153.792303] [8105290b] ? enqueue_task_fair+0x4b/0xd0 [10153.798231] [814bb7f6] ? dma_issue_pending_all+0x86/0xc0 [10153.804512] [814e9ee8] net_rx_action+0x108/0x2d0 [10153.810092] [8108b6a8] ? __hrtimer_start_range_ns+0x188/0x480 [10153.816807] [8106bf8b] __do_softirq+0xab/0x200 [10153.822246] [810d1b60] ? handle_IRQ_event+0x50/0x170 [10153.828185] [8100cf5c] call_softirq+0x1c/0x30 [10153.833506] [8100e9c5] do_softirq+0x65/0xa0 [10153.838654] [8106be55] irq_exit+0x85/0x90 [10153.843639] [815e45a6] do_IRQ+0x66/0xe0 [10153.848441] [815dc9d3] ret_from_intr+0x0/0x15 [10153.853759] EOI [10153.855900] [815dc2de] ? _raw_spin_lock+0xe/0x20 [10153.861488] [81154e41] ? kmem_cache_free+0x91/0x100 [10153.867328] [811482d7] __mpol_put+0x27/0x30 [10153.872477] [81069b6e] do_exit+0x1ee/0x400 [10153.877538] [81069e87] sys_exit+0x17/0x20 [10153.882514] [8100c042] system_call_fastpath+0x16/0x1b [10153.888525] Code: e5 48 83 ec 10 0f 1f 44 00 00 48 85 ff 74 20 f6 47 06 02 75 1a 0f b7 47 04 66 83 f8 02 74 27 66 83 f8 03 74 14 66 83 f8 01 74 15 0f 0b eb fe 65 8b 04 25
Re: Debugging system freezes on filesystem writes
On Tue 27-11-12 18:14:42, Marcus Sundman wrote: On 22.11.2012 01:30, Jan Kara wrote: On Fri 16-11-12 03:11:22, Marcus Sundman wrote: On 13.11.2012 15:51, Jan Kara wrote: On Fri 09-11-12 15:12:43, Marcus Sundman wrote: On 09.11.2012 01:41, Marcus Sundman wrote: On 07.11.2012 18:17, Jan Kara wrote: On Fri 02-11-12 04:19:24, Marcus Sundman wrote: Also, and this might be important, according to iotop there is almost no disk writing going on during the freeze. (Occasionally there are a few MB/s, but mostly it's 0-200 kB/s.) Well, at least when an iotop running on nice -20 hasn't frozen completely, which it does during the more severe freezes. OK, it seems as if your machine has some problems with memory allocations. Can you capture /proc/vmstat before the freeze and after the freeze and send them for comparison. Maybe it will show us what is the system doing. t=01:06 http://sundman.iki.fi/vmstat.pre-freeze.txt t=01:08 http://sundman.iki.fi/vmstat.during-freeze.txt t=01:12 http://sundman.iki.fi/vmstat.post-freeze.txt Here are some more vmstats: http://sundman.iki.fi/vmstats.tar.gz They are from running this: while true; do cat /proc/vmstat vmstat.$(date +%FT%X).txt; sleep 10; done There were lots and lots of freezes for almost 20 mins from 14:37:45 onwards, pretty much constantly, but at 14:56:50 the freezes suddenly stopped and everything went back to how it should be. I was looking into the data but they didn't show anything problematic. The machine seems to be writing a lot but there's always some free memory, even direct reclaim isn't ever entered. Hum, actually you wrote iotop isn't showing much IO going on but vmstats show there is about 1 GB written during the freeze. It is not a huge amount given the time span but it certainly gives a few MB/s of write load. I didn't watch iotop during this particular freeze. I'll try to keep an eye on iotop in the future. Is there some particular options I should run iotop with, or is a nice -n -20 iotop -od3 fine? I'm not really familiar with iotop :). Usually I use iostat... OK, which options for iostat should I use then? :) I'm back from vacation. Sorry for the delay. You can use iostat -x 1 There's surprisingly high number of allocations going on but that may be due to the IO activity. So let's try something else: Can you switch to console and when the hang happens press Alt-Sysrq-w (or you can just do echo w /proc/sysrq-trigger if the machine is live enough to do that). Then send me the output from dmesg. Thanks! Sure! Here are two: http://sundman.iki.fi/dmesg-1.txt http://sundman.iki.fi/dmesg-2.txt Thanks for those and sorry for the delay (I was busy with other stuff). I had a look into those traces and I have to say I'm not much wiser. In the first dump there is just kswapd waiting for IO. In the second dump there are more processes waiting for IO (mostly for reads - nautilus, thunderbird, opera, ...) but nothing really surprising. So I'm lost what could cause the hangs you observe. Yes, mostly it's difficult to trigger the sysrq thingy, because by the time I manage to switch to the console or running that echo to proc in a terminal the worst is already over. I see. Maybe you could have something like while true; do echo w /proc/sysrq-trigger; sleep 10; done running in the background? Recalling you wrote even simple programs like top hang, maybe it is some CPU scheduling issue? Can you boot with noautogroup kernel option? Sure. I've been running with noautogroup for almost a week now, but no big change one way or the other. (E.g., it's still impossible to listen to music, because the songs will start skipping/looping several times during each song even if there isn't any big hang happening. And uncompressing a 100 MB archive (with nice '19' and ionice 'idle') is still, after a while, followed by a couple of minutes of superhigh I/O wait causing everything to become really slow.) Hum, I'm starting to wander what's so special about your system that you see these hangs while noone else seems to be hitting them. Your kernel is a standard one from Ubuntu so tons of people run it. Your HW doesn't seem to be too special either. BTW the fact that you ionice 'tar' doesn't change anything because all the writes are done in the context of kernel flusher thread (tar just writes data into cache). But still it shouldn't lock the machine up. What might be interesting test though is running: dd if=/dev/zero of=file bs=1M count=200 oflags=direct Does this trigger any hangs? Honza -- Jan Kara j...@suse.cz SUSE Labs, CR -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pwm: i.MX: eliminate build warning
compiling the i.MX pwm driver produces the following warning:
|drivers/pwm/pwm-imx.c: In function 'imx_pwm_probe':
|drivers/pwm/pwm-imx.c:281:7: warning: assignment discards qualifiers from
pointer target type
Apply a 'const' attribute to the affected variable declaration.
Signed-off-by: Lothar Waßmann l...@karo-electronics.de
---
drivers/pwm/pwm-imx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index 8f26e9f..65a86bd 100644
--- a/drivers/pwm/pwm-imx.c
+++ b/drivers/pwm/pwm-imx.c
@@ -235,7 +235,7 @@ static int imx_pwm_probe(struct platform_device *pdev)
{
const struct of_device_id *of_id =
of_match_device(imx_pwm_dt_ids, pdev-dev);
- struct imx_pwm_data *data;
+ const struct imx_pwm_data *data;
struct imx_chip *imx;
struct resource *r;
int ret = 0;
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] leds: leds-pwm: Convert to use devm_get_pwm
On 12/04/2012 06:34 PM, Bryan Wu wrote: What's best thing I can do is I can merge these patchset into my -devel branch, after 3.8 merge window close I will move this -devel branch to my for-next branch for 3.9 merge window. Does this make sense to you? Not sure if I can get changes related to leds-pwm through linux-omap in this way. The practice is that l-o should be 'in a working condition' alone - without linux-next. But I'll find something else while waiting for 3.10 to clean up the omap board files related to this. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Look Ma, da kernel is b0rken
Hillarious! Andrew, would you please pick up Alan's patch? It clearly fixes an ancient bug in the pnpacpi code. And yes btw we should turn this option on in -next, and get these sort of things out of the tree for good. More importantly it'll mean anyone adding another one gets a whine on the spot. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x
On 05.12.2012 14:04, Thierry Reding wrote: On Wed, Dec 05, 2012 at 01:47:38PM +0200, Terje Bergström wrote: Yes, but there's more. For instance I went to great lengths to make sure there's no global data whatsoever. So all the data is bound to the host1x device in the current code. I know many other drivers like to take a shortcut and just put these things into global variables but I didn't want to. Sure, that feedback is in the todo list. For some parts I already have a proposed solution, but for chip ops not yet. The problem with doing drm_platform_init() with host1x device as parameter is that drm_get_platform_dev() will take control of drvdata. We'd need to put host1x specific struct host1x pointer to some other place and I'm not sure what that place could be. Not anymore. I submitted a patch so that it no longer does that. The patch was merged about a month and a half ago. Oops, I must've checked the status from a stale tree. Thanks for that. In this case there's no technical reason why host1x couldn't act as the device to register for drm, as drm wouldn't touch host1x device data in any way. How about if we treat the host1x driver as utility library, and move the code for host1x probe altogether to tegradrm/host1x.c? I haven't yet checked how bad the dependencies between host1x's driver's host1x.c and the rest of the driver are, so I'm not sure if it's feasible and if there would be a clear design. Just tossing in ideas. That would solve the circular dependency problem. I've already committed to contents of host1x.c being very different in downstream and upstream, so this change would just emphasize that. Terje -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/5] page_alloc: Make movablecore_map has higher priority
If we make movablecore_map take precedence over movablecore/kernelcore,
the logic could be simplified. I think it's not so attractive to support
both movablecore_map and movablecore/kernelcore at the same time.
On 11/23/2012 06:44 PM, Tang Chen wrote:
If kernelcore or movablecore is specified at the same time
with movablecore_map, movablecore_map will have higher
priority to be satisfied.
This patch will make find_zone_movable_pfns_for_nodes()
calculate zone_movable_pfn[] with the limit from
zone_movable_limit[].
Signed-off-by: Tang Chen tangc...@cn.fujitsu.com
Reviewed-by: Wen Congyang we...@cn.fujitsu.com
Reviewed-by: Lai Jiangshan la...@cn.fujitsu.com
Tested-by: Lin Feng linf...@cn.fujitsu.com
---
mm/page_alloc.c | 35 +++
1 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f23d76a..05bafbb 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4800,12 +4800,25 @@ static void __init
find_zone_movable_pfns_for_nodes(void)
required_kernelcore = max(required_kernelcore, corepages);
}
- /* If kernelcore was not specified, there is no ZONE_MOVABLE */
- if (!required_kernelcore)
+ /*
+ * No matter kernelcore/movablecore was limited or not, movable_zone
+ * should always be set to a usable zone index.
+ */
+ find_usable_zone_for_movable();
+
+ /*
+ * If neither kernelcore/movablecore nor movablecore_map is specified,
+ * there is no ZONE_MOVABLE. But if movablecore_map is specified, the
+ * start pfn of ZONE_MOVABLE has been stored in zone_movable_limit[].
+ */
+ if (!required_kernelcore) {
+ if (movablecore_map.nr_map)
+ memcpy(zone_movable_pfn, zone_movable_limit,
+ sizeof(zone_movable_pfn));
goto out;
+ }
/* usable_startpfn is the lowest possible pfn ZONE_MOVABLE can be at */
- find_usable_zone_for_movable();
usable_startpfn = arch_zone_lowest_possible_pfn[movable_zone];
restart:
@@ -4833,10 +4846,24 @@ restart:
for_each_mem_pfn_range(i, nid, start_pfn, end_pfn, NULL) {
unsigned long size_pages;
+ /*
+ * Find more memory for kernelcore in
+ * [zone_movable_pfn[nid], zone_movable_limit[nid]).
+ */
start_pfn = max(start_pfn, zone_movable_pfn[nid]);
if (start_pfn = end_pfn)
continue;
+ if (zone_movable_limit[nid]) {
+ end_pfn = min(end_pfn, zone_movable_limit[nid]);
+ /* No range left for kernelcore in this node */
+ if (start_pfn = end_pfn) {
+ zone_movable_pfn[nid] =
+ zone_movable_limit[nid];
+ break;
+ }
+ }
+
/* Account for what is only usable for kernelcore */
if (start_pfn usable_startpfn) {
unsigned long kernel_pages;
@@ -4896,12 +4923,12 @@ restart:
if (usable_nodes required_kernelcore usable_nodes)
goto restart;
+out:
/* Align start of ZONE_MOVABLE on all nids to MAX_ORDER_NR_PAGES */
for (nid = 0; nid MAX_NUMNODES; nid++)
zone_movable_pfn[nid] =
roundup(zone_movable_pfn[nid], MAX_ORDER_NR_PAGES);
-out:
/* restore the node_state */
node_states[N_HIGH_MEMORY] = saved_node_state;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)
On Tue, Dec 04, 2012 at 08:43:18PM +, Arnd Bergmann wrote: On Tuesday 04 December 2012, Eli Billauer wrote: I'm currently writing some documentation which will cover the API and also help reading the code, I hope. It takes some time... Until it's done, let's look at a usage example: Suppose that the FPGA's application is to receive a high-speed bitstream with time multiplexed data, demultiplex the bitstream into individual channel streams, and send each channel's data to the host. And let's say that there are 64 channels in original bitstream. So the FPGA has now 64 independent sources of data. For that purpose, the Xillybus IP core (on the FPGA) is configured to create 64 pipes for FPGA to host communication. The names of these pipes (say, chan00, chan01, ...) are also stored in the FPGA. When the driver starts, it queries the FPGA for its Xillybus configuration, and creates 64 device nodes: /dev/xillybus_chan00, /dev/xillybus_chan01, ... /dev/xillybus_chan63. If the user wants to dump the data in channel 43 into a file, it's just: $ cat /dev/xillybus_chan43 mydump.dat I hope this clarified things a bit. I can't see how the firmware interface would help here. I think a lot of us (including Greg and me) were confused about the purpose of the driver, since you did not include much documentation. The request_firmware interface would be useful for loading a model into the FPGA, but that doesn't seem to be what your driver is concerned with. It's also a bit confusing because it doesn't appear to be a bus in the Linux sense of being something that provides an abstract interface between hardware and kernel device drivers. Yes, that's what I was confused about as well. I'll wait for a new patch with new documentation, before commenting further. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI
On Wed, Dec 5, 2012 at 2:48 AM, Martin Steigerwald mar...@lichtvoll.de wrote: Linus, while I am interested in an answer I think that Dave and Christoph as Linux filesystem developers actually deserve one (instead of silently being ignored which is also a decision in this matter). I did not see an answer in linux-2.6 commit log as of today so far. Christ guys. This whole thread is retarded. The *ONLY* reason people seem to have for reverting that is a ooh, my feelings are hurt by how this was done, and now I'm a pissy bitch and I want to get this reverted. Stop the f*cking around already. If you want something reverted, you show me the *technical* reason for it. Not the ooh, I'm so annoyed by how this was done reason for it. And if your little feelings got hurt, get your mommy to tuck you in, don't email me about it. Because I'm not exactly known for my deep emotional understanding and supportive personality, am I? Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/5] page_alloc: Introduce zone_movable_limit[] to keep movable limit for nodes
On 11/23/2012 06:44 PM, Tang Chen wrote:
This patch introduces a new array zone_movable_limit[] to store the
ZONE_MOVABLE limit from movablecore_map boot option for all nodes.
The function sanitize_zone_movable_limit() will find out to which
node the ranges in movable_map.map[] belongs, and calculates the
low boundary of ZONE_MOVABLE for each node.
Signed-off-by: Tang Chen tangc...@cn.fujitsu.com
Reviewed-by: Wen Congyang we...@cn.fujitsu.com
Reviewed-by: Lai Jiangshan la...@cn.fujitsu.com
Tested-by: Lin Feng linf...@cn.fujitsu.com
---
mm/page_alloc.c | 55
+++
1 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index fb5cf12..f23d76a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -206,6 +206,7 @@ static unsigned long __meminitdata
arch_zone_highest_possible_pfn[MAX_NR_ZONES];
static unsigned long __initdata required_kernelcore;
static unsigned long __initdata required_movablecore;
static unsigned long __meminitdata zone_movable_pfn[MAX_NUMNODES];
+static unsigned long __meminitdata zone_movable_limit[MAX_NUMNODES];
/* movable_zone is the real zone pages in ZONE_MOVABLE are taken from */
int movable_zone;
@@ -4323,6 +4324,55 @@ static unsigned long __meminit
zone_absent_pages_in_node(int nid,
return __absent_pages_in_range(nid, zone_start_pfn, zone_end_pfn);
}
+/**
+ * sanitize_zone_movable_limit - Sanitize the zone_movable_limit array.
+ *
+ * zone_movable_limit is initialized as 0. This function will try to get
+ * the first ZONE_MOVABLE pfn of each node from movablecore_map, and
+ * assigne them to zone_movable_limit.
+ * zone_movable_limit[nid] == 0 means no limit for the node.
+ *
+ * Note: Each range is represented as [start_pfn, end_pfn)
+ */
+static void __meminit sanitize_zone_movable_limit(void)
+{
+ int map_pos = 0, i, nid;
+ unsigned long start_pfn, end_pfn;
+
+ if (!movablecore_map.nr_map)
+ return;
+
+ /* Iterate all ranges from minimum to maximum */
+ for_each_mem_pfn_range(i, MAX_NUMNODES, start_pfn, end_pfn, nid) {
+ /*
+ * If we have found lowest pfn of ZONE_MOVABLE of the node
+ * specified by user, just go on to check next range.
+ */
+ if (zone_movable_limit[nid])
+ continue;
Need special handling of low memory here on systems with highmem, otherwise
it will cause us to configure both lowmem and highmem as movable_zone.
+
+ while (map_pos movablecore_map.nr_map) {
+ if (end_pfn = movablecore_map.map[map_pos].start)
+ break;
+
+ if (start_pfn = movablecore_map.map[map_pos].end) {
+ map_pos++;
+ continue;
+ }
+
+ /*
+ * The start_pfn of ZONE_MOVABLE is either the minimum
+ * pfn specified by movablecore_map, or 0, which means
+ * the node has no ZONE_MOVABLE.
+ */
+ zone_movable_limit[nid] = max(start_pfn,
+ movablecore_map.map[map_pos].start);
+
+ break;
+ }
+ }
+}
+
#else /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
static inline unsigned long __meminit zone_spanned_pages_in_node(int nid,
unsigned long zone_type,
@@ -4341,6 +4391,10 @@ static inline unsigned long __meminit
zone_absent_pages_in_node(int nid,
return zholes_size[zone_type];
}
+static void __meminit sanitize_zone_movable_limit(void)
+{
+}
+
#endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
static void __meminit calculate_node_totalpages(struct pglist_data *pgdat,
@@ -4906,6 +4960,7 @@ void __init free_area_init_nodes(unsigned long
*max_zone_pfn)
/* Find the PFNs that ZONE_MOVABLE begins at in each node */
memset(zone_movable_pfn, 0, sizeof(zone_movable_pfn));
+ sanitize_zone_movable_limit();
find_zone_movable_pfns_for_nodes();
/* Print out the zone ranges */
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at /build/buildd/linux-2.6.32/mm/mempolicy.c
On Wed, Dec 05, 2012 at 10:22:08PM +0700, Bokhan Artem wrote: Hello. We have several servers with mongodb running. Each server has several mongodb instances. Mongodb dataset is larger then availiable memory (mongodb uses memory-mapped files for all disk I/O). 2.6.32 and 2.6.38 kernels periodically crash and crash happens only with mongodb servers. 2.6.38's trace is in attachment. For 2.6.32 I only have kernel BUG at /build/buildd/linux-2.6.32/mm/mempolicy.c:1489! Can you reproduce this with the current upstream kernel 3.7-rc8? If no, then you should complain to the ubuntu people or whoever provides your kernels. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at /build/buildd/linux-2.6.32/mm/mempolicy.c
On 05.12.2012 22:53, Borislav Petkov wrote: On Wed, Dec 05, 2012 at 10:22:08PM +0700, Bokhan Artem wrote: Hello. We have several servers with mongodb running. Each server has several mongodb instances. Mongodb dataset is larger then availiable memory (mongodb uses memory-mapped files for all disk I/O). 2.6.32 and 2.6.38 kernels periodically crash and crash happens only with mongodb servers. 2.6.38's trace is in attachment. For 2.6.32 I only have kernel BUG at /build/buildd/linux-2.6.32/mm/mempolicy.c:1489! Can you reproduce this with the current upstream kernel 3.7-rc8? If no, then you should complain to the ubuntu people or whoever provides your kernels. We will try. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Build regressions/improvements in v3.7-rc8
Below is the list of build error/warning regressions/improvements in v3.7-rc8[1] compared to v3.6[2]. To make this mail fit in the lkml limit, I deleted - 6016 lines about __mcount_loc on sparc64 - all error and warning improvements Summarized: - build errors: +13/-952 - build warnings: +332/-7901 JFYI, when comparing v3.7-rc8 to v3.7-rc7[3], the summaries are: - build errors: +3/-5 - build warnings: +38/-5936 As I haven't mastered kup yet, there's no verbose summary at http://www.kernel.org/pub/linux/kernel/people/geert/linux-log/v3.7-rc8.summary.gz Happy fixing! ;-) Thanks to the linux-next team for providing the build service. [1] http://kisskb.ellerman.id.au/kisskb/head/5670/ (all 117 configs) [2] http://kisskb.ellerman.id.au/kisskb/head/5469/ (all 117 configs) [3] http://kisskb.ellerman.id.au/kisskb/head/5646/ (all 117 configs) *** ERRORS *** 13 regressions: + drivers/staging/ipack/devices/ipoctal.c: error: implicit declaration of function 'ioread8' [-Werror=implicit-function-declaration]: = 141:3 + drivers/staging/ipack/devices/ipoctal.c: error: implicit declaration of function 'iowrite8' [-Werror=implicit-function-declaration]: = 64:2 + drivers/staging/ipack/ipack.c: error: implicit declaration of function 'ioread16be' [-Werror=implicit-function-declaration]: = 383:3 + drivers/staging/ipack/ipack.c: error: implicit declaration of function 'ioread8' [-Werror=implicit-function-declaration]: = 365:2 + error: phy_n.c: relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o: = (.text+0x1ffa5f4), (.text+0x1ff9fac), (.text+0x1ffbcc8) + error: phy_n.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_restgpr0_14' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: = (.text+0x1ffa5bc), (.text+0x1ff9f8c) + error: phy_n.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_savegpr0_21' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: = (.text+0x1ffa5c8) + error: relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o: = (.text+0x1ffadb0) + error: relocation truncated to fit: R_PPC64_REL24 against symbol `.memset' defined in .text section in arch/powerpc/lib/built-in.o: = (.text+0x1ffaefc) + error: relocation truncated to fit: R_PPC64_REL24 against symbol `_restgpr0_14' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: = (.text+0x1ff8b34) + error: relocation truncated to fit: R_PPC64_REL24 against symbol `_savegpr0_15' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: = (.text+0x1ffad84) + error: vsprintf.c: relocation truncated to fit: R_AVR32_9UW_PCREL against `.text'+adc: = (.text+0x8de) + kernel/task_work.c: error: implicit declaration of function 'read_barrier_depends' [-Werror=implicit-function-declaration]: = 38:3 *** WARNINGS *** 332 regressions: + .config: warning: override: SLOB changes choice state: = 173 + arch/avr32/include/asm/param.h: warning: HZ redefined: = 6:1 + arch/avr32/include/uapi/asm/param.h: warning: this is the location of the previous definition: = 6:1 + arch/cris/include/asm/atomic.h: warning: 'cli' may be used uninitialized in this function [-Wuninitialized]: = 83:4 + arch/mn10300/mm/dma-alloc.c: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat]: = 29:2 + arch/sh/include/uapi/asm/swab.h: warning: 'r.x[0]' may be used uninitialized in this function [-Wuninitialized]: = 14:2 + block/blk-sysfs.c: warning: 'val' may be used uninitialized in this function: = 246, 244, 245 + drivers/ata/libahci.c: warning: value computed is not used [-Wunused-value]: = 831:453, 576:476, 697:478, 1446:477, 1258:507, 629:476 + drivers/ata/pata_pdc2027x.c: warning: value computed is not used [-Wunused-value]: = 614:491, 631:491 + drivers/ata/sata_promise.c: warning: value computed is not used [-Wunused-value]: = 401:521, 1027:481, 743:506, 397:521, 754:486, 456:456, 780:506, 926:486, 760:486, 722:486, 1169:496, 1032:501 + drivers/ata/sata_qstor.c: warning: value computed is not used [-Wunused-value]: = 327:461 + drivers/ata/sata_sil.c: warning: value computed is not used [-Wunused-value]: = 388:396, 563:486 + drivers/ata/sata_sx4.c: warning: value computed is not used [-Wunused-value]: = 757:558, 547:421, 1336:481, 1100:492, 908:396, 578:551, 675:557, 1244:496, 1089:492, 1097:512, 884:466, 1437:491, 754:553, 1430:491, 581:506, 1252:497, 1086:512, 1121:496, 671:552, 1297:491, 1221:496, 867:466, 1073:511, 1080:491, 512:421 + drivers/block/cciss.h: warning: value computed is not used [-Wunused-value]: = 227:451 + drivers/block/mtip32xx/mtip32xx.c: warning: value computed is not used [-Wunused-value]: = 361:481, 336:481, 507:501, 1724:471, 494:501, 264:471 +
Re: [PATCH 4/8] srcu: srcu_read_lock() can be called from offline cpu
On Thu, Nov 29, 2012 at 04:46:05PM +0800, Lai Jiangshan wrote:
SRCU is based on its own statemachine and it doesn't
relies on normal RCU now, its read critical section can be used in
offline cpu, so we remove the check and the comments.
It partially reverts c0d6d01b(the part for SRCU).
It also makes the codes match the comments in whatisRCU.txt:
g.Do you need read-side critical sections that are respected
even though they are in the middle of the idle loop, during
user-mode execution, or on an offlined CPU? If so, SRCU is the
only choice that will work for you.
One thing just occurred to me... Won't lockdep refuse to operated on
offline CPUs? If so, one way to handle this would be to flag srcu_struct
structures that were to be used on idle and offline CPUs, and avoid
using lockdep on them. This would allow most uses of SRCU to continue
using lockdep, while avoiding lockdep false positives in other cases.
Or am I confused?
Thanx, Paul
Signed-off-by: Lai Jiangshan la...@cn.fujitsu.com
---
include/linux/srcu.h |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/include/linux/srcu.h b/include/linux/srcu.h
index 6eb691b..ae3ee39 100644
--- a/include/linux/srcu.h
+++ b/include/linux/srcu.h
@@ -163,9 +163,6 @@ void srcu_barrier(struct srcu_struct *sp);
* power mode. This way we can notice an extended quiescent state to
* other CPUs that started a grace period. Otherwise we would delay any
* grace period as long as we run in the idle task.
- *
- * Similarly, we avoid claiming an SRCU read lock held if the current
- * CPU is offline.
*/
static inline int srcu_read_lock_held(struct srcu_struct *sp)
{
@@ -173,8 +170,6 @@ static inline int srcu_read_lock_held(struct srcu_struct
*sp)
return 1;
if (rcu_is_cpu_idle())
return 0;
- if (!rcu_lockdep_current_cpu_online())
- return 0;
return lock_is_held(sp-dep_map);
}
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Look Ma, da kernel is b0rken
On Wed, Dec 05, 2012 at 03:47:49PM +, Alan Cox wrote: Hillarious! Andrew, would you please pick up Alan's patch? It clearly fixes an ancient bug in the pnpacpi code. And yes btw we should turn this option on in -next, and get these sort of things out of the tree for good. More importantly it'll mean anyone adding another one gets a whine on the spot. Right, when we added W=, we thought that one use case would be for devs to use it when build-testing patches and check whether they're adding new warnings. However, (1) we need additional functionality in some script to be able to test when the build log adds new warnings and (2) need someone to enforce it. I think Geert is doing something like that but I'm not sure he's even using W=. Actually, it would be cool if something checked for new warnings, mapped it back to the patch in linux-next adding that warning and then nags the patch author endlessly until it is fixed. Thanks. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] 3.6.9-rt21
Dear RT Folks,
I'm pleased to announce the 3.6.9-rt21 release. 3.6.7-rt18, 3.6.8-rt19
and 3.6.9-rt20 are not announced updates to the respective 3.6.y
stable releases without any RT changes
Changes since 3.6.9-rt20:
* Fix the PREEMPT_LAZY implementation on ARM
* Fix the RCUTINY issues
* Fix a long standing scheduler bug (See commit log of
sched-enqueue-to-head.patch)
Known issues:
* There is still a possibility to get false positives from the NOHZ
idle softirq pending detector. It's rather complex to fix and I
have postponed it for a separate release. The warnings are
harmless and can be ignored for now.
The delta patch against 3.6.9-rt20 is appended below and can be found
here:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/incr/patch-3.6.9-rt20-rt21.patch.xz
The RT patch against 3.6.9 can be found here:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patch-3.6.9-rt21.patch.xz
The split quilt queue is available at:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patches-3.6.9-rt21.tar.xz
Enjoy,
tglx
-
Index: linux-stable/arch/arm/kernel/entry-armv.S
===
--- linux-stable.orig/arch/arm/kernel/entry-armv.S
+++ linux-stable/arch/arm/kernel/entry-armv.S
@@ -216,17 +216,18 @@ __irq_svc:
#ifdef CONFIG_PREEMPT
get_thread_info tsk
ldr r8, [tsk, #TI_PREEMPT] @ get preempt count
- ldr r0, [tsk, #TI_FLAGS]@ get flags
teq r8, #0 @ if preempt count != 0
- movne r0, #0 @ force flags to 0
- tst r0, #_TIF_NEED_RESCHED
- blnesvc_preempt
- ldr r8, [tsk, #TI_PREEMPT_LAZY] @ get preempt lazy count
+ bne 1f @ return from exeption
ldr r0, [tsk, #TI_FLAGS]@ get flags
+ tst r0, #_TIF_NEED_RESCHED @ if NEED_RESCHED is set
+ blnesvc_preempt @ preempt!
+
+ ldr r8, [tsk, #TI_PREEMPT_LAZY] @ get preempt lazy count
teq r8, #0 @ if preempt lazy count != 0
movne r0, #0 @ force flags to 0
tst r0, #_TIF_NEED_RESCHED_LAZY
blnesvc_preempt
+1:
#endif
#ifdef CONFIG_TRACE_IRQFLAGS
Index: linux-stable/kernel/Makefile
===
--- linux-stable.orig/kernel/Makefile
+++ linux-stable/kernel/Makefile
@@ -10,7 +10,7 @@ obj-y = fork.o exec_domain.o panic.o
kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o \
hrtimer.o nsproxy.o srcu.o semaphore.o \
notifier.o ksysfs.o cred.o \
- async.o range.o groups.o lglock.o
+ async.o range.o groups.o lglock.o wait-simple.o
ifdef CONFIG_FUNCTION_TRACER
# Do not trace debug files and internal ftrace files
Index: linux-stable/kernel/rcutiny_plugin.h
===
--- linux-stable.orig/kernel/rcutiny_plugin.h
+++ linux-stable/kernel/rcutiny_plugin.h
@@ -26,6 +26,7 @@
#include linux/module.h
#include linux/debugfs.h
#include linux/seq_file.h
+#include linux/wait-simple.h
/* Global control variables for rcupdate callback mechanism. */
struct rcu_ctrlblk {
@@ -260,7 +261,7 @@ static void show_tiny_preempt_stats(stru
/* Controls for rcu_kthread() kthread. */
static struct task_struct *rcu_kthread_task;
-static DECLARE_WAIT_QUEUE_HEAD(rcu_kthread_wq);
+static DEFINE_SWAIT_HEAD(rcu_kthread_wq);
static unsigned long have_rcu_kthread_work;
/*
@@ -710,7 +711,7 @@ void synchronize_rcu(void)
}
EXPORT_SYMBOL_GPL(synchronize_rcu);
-static DECLARE_WAIT_QUEUE_HEAD(sync_rcu_preempt_exp_wq);
+static DEFINE_SWAIT_HEAD(sync_rcu_preempt_exp_wq);
static unsigned long sync_rcu_preempt_exp_count;
static DEFINE_MUTEX(sync_rcu_preempt_exp_mutex);
@@ -732,7 +733,7 @@ static int rcu_preempted_readers_exp(voi
*/
static void rcu_report_exp_done(void)
{
- wake_up(sync_rcu_preempt_exp_wq);
+ swait_wake(sync_rcu_preempt_exp_wq);
}
/*
@@ -784,8 +785,8 @@ void synchronize_rcu_expedited(void)
} else {
rcu_initiate_boost();
local_irq_restore(flags);
- wait_event(sync_rcu_preempt_exp_wq,
- !rcu_preempted_readers_exp());
+ swait_event(sync_rcu_preempt_exp_wq,
+ !rcu_preempted_readers_exp());
}
/* Clean up and exit. */
@@ -855,7 +856,7 @@ static void invoke_rcu_callbacks(void)
{
have_rcu_kthread_work = 1;
if (rcu_kthread_task != NULL)
- wake_up(rcu_kthread_wq);
+ swait_wake(rcu_kthread_wq);
}
#ifdef CONFIG_RCU_TRACE
@@ -885,8 +886,8 @@ static int rcu_kthread(void *arg)
unsigned long flags;
for (;;) {
-
[PATCH v2 01/44] asm-generic/io.h: remove asm/cacheflush.h include
Including asm/cacheflush.h from asm-generic/io.h prevents cacheflush.h being able to use I/O functions like readl and writel due to circular include dependencies. It doesn't appear as if anything from cacheflush.h is actually used by the generic io.h, so remove the include. I've compile tested a defconfig compilation of blackfin, openrisc (which needed asm/pgtable.h including from it's asm/io.h to get the PAGE_* definitions), and xtensa. Other architectures which use asm-generic/io.h are score and unicore32, and looking at their io.h I don't see any obvious problems. Signed-off-by: James Hogan james.ho...@imgtec.com Acked-by: Jonas Bonn jo...@southpole.se Acked-by: Max Filippov jcmvb...@gmail.com Acked-by: Guan Xuetao g...@mprc.pku.edu.cn Cc: Chris Zankel ch...@zankel.net Cc: Mike Frysinger vap...@gentoo.org Cc: Chen Liqin liqin.c...@sunplusct.com Cc: Lennox Wu lennox...@gmail.com Signed-off-by: Arnd Bergmann a...@arndb.de --- arch/openrisc/include/asm/io.h |1 + include/asm-generic/io.h |1 - 2 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/openrisc/include/asm/io.h b/arch/openrisc/include/asm/io.h index 07f5299..7c69139 100644 --- a/arch/openrisc/include/asm/io.h +++ b/arch/openrisc/include/asm/io.h @@ -30,6 +30,7 @@ #define PIO_MASK 0 #include asm-generic/io.h +#include asm/pgtable.h extern void __iomem *__ioremap(phys_addr_t offset, unsigned long size, pgprot_t prot); diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h index 448303b..616eea5 100644 --- a/include/asm-generic/io.h +++ b/include/asm-generic/io.h @@ -12,7 +12,6 @@ #define __ASM_GENERIC_IO_H #include asm/page.h /* I/O is all done through memory accesses */ -#include asm/cacheflush.h #include linux/types.h #ifdef CONFIG_GENERIC_IOMAP -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 03/44] Add CONFIG_HAVE_64BIT_ALIGNED_STRUCT for taskstats
On 64 bit architectures with no efficient unaligned access, taskstats has to add some padding to a reply to prevent unaligned access warnings. However this also needs to apply to 32 bit architectures with 64 bit struct alignment such as metag (which has 64 bit memory accesses). This is solved by adding a new Kconfig symbol CONFIG_HAVE_64BIT_ALIGNED_STRUCT which defaults to CONFIG_64BIT, and can be explicitly selected by CONFIG_METAG. Taskstats then uses this symbol instead of CONFIG_64BIT to determine whether to add the padding. Signed-off-by: James Hogan james.ho...@imgtec.com Cc: Balbir Singh bsinghar...@gmail.com Cc: Ingo Molnar mi...@kernel.org Cc: Andrew Morton a...@linux-foundation.org Cc: Eric Paris epa...@redhat.com Cc: Will Drewry w...@chromium.org Cc: James Morris james.l.mor...@oracle.com --- arch/Kconfig | 16 kernel/taskstats.c |3 ++- 2 files changed, 18 insertions(+), 1 deletions(-) diff --git a/arch/Kconfig b/arch/Kconfig index 366ec06..dc7ffb1 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -93,6 +93,22 @@ config UPROBES If in doubt, say N. +config HAVE_64BIT_ALIGNED_STRUCT + bool + default 64BIT + help + Some architectures have 64bit struct alignment (64 bit + architectures and some 32 bit architectures which can do + 64 bit accesses). + + This symbol should be selected by an architecture if it has + a 64 bit struct alignment requirement even though it isn't + a 64 bit architecture (64 bit architectures have this on by + default). + + See Documentation/unaligned-memory-access.txt for more + information on the topic of unaligned memory accesses. + config HAVE_EFFICIENT_UNALIGNED_ACCESS bool help diff --git a/kernel/taskstats.c b/kernel/taskstats.c index 145bb4d..afaa4c2 100644 --- a/kernel/taskstats.c +++ b/kernel/taskstats.c @@ -364,7 +364,8 @@ static int parse(struct nlattr *na, struct cpumask *mask) return ret; } -#if defined(CONFIG_64BIT) !defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) +#if defined(CONFIG_HAVE_64BIT_ALIGNED_STRUCT) \ + !defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) #define TASKSTATS_NEEDS_PADDING 1 #endif -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 05/44] Revert some of binfmt_elf: cleanups
The commit binfmt_elf: cleanups
(f670d0ecda73b7438eec9ed108680bc5f5362ad8) removed an ifndef elf_map but
this breaks compilation for metag which does define elf_map.
This adds the ifndef back in as it was before, but does not affect the
other cleanups made by that patch.
Signed-off-by: James Hogan james.ho...@imgtec.com
Acked-by: Mikael Pettersson mi...@it.uu.se
Cc: Alexander Viro v...@zeniv.linux.org.uk
Cc: linux-fsde...@vger.kernel.org
---
fs/binfmt_elf.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index fbd9f60..34493b5 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -321,6 +321,8 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr
*exec,
return 0;
}
+#ifndef elf_map
+
static unsigned long elf_map(struct file *filep, unsigned long addr,
struct elf_phdr *eppnt, int prot, int type,
unsigned long total_size)
@@ -355,6 +357,8 @@ static unsigned long elf_map(struct file *filep, unsigned
long addr,
return(map_addr);
}
+#endif /* !elf_map */
+
static unsigned long total_mapping_size(struct elf_phdr *cmds, int nr)
{
int i, first_idx = -1, last_idx = -1;
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 06/44] of/vendor-prefixes: add Imagination Technologies
The powervr prefix which is currently described as Imagination Technologies isn't really appropriate for non-PowerVR hardware, so deprecate it, changing the description of powervr to PowerVR (deprecated, use img), and add a separate img prefix for Imagination Technologies Ltd.. Signed-off-by: James Hogan james.ho...@imgtec.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Rob Herring rob.herr...@calxeda.com Cc: Rob Landley r...@landley.net Cc: devicetree-disc...@lists.ozlabs.org --- .../devicetree/bindings/vendor-prefixes.txt|3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 9de2b9f..aab2993 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -25,6 +25,7 @@ gef GE Fanuc Intelligent Platforms Embedded Systems, Inc. hp Hewlett Packard ibmInternational Business Machines (IBM) idtIntegrated Device Technologies, Inc. +imgImagination Technologies Ltd. intercontrol Inter Control Group linux Linux-specific binding marvellMarvell Technology Group Ltd. @@ -35,7 +36,7 @@ nintendo Nintendo nvidia NVIDIA nxpNXP Semiconductors picochip Picochip Ltd -powervrImagination Technologies +powervrPowerVR (deprecated, use img) qcom Qualcomm, Inc. ramtronRamtron International realtek Realtek Semiconductor Corp. -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 21/44] metag: ptrace
The ptrace interface for metag provides access to some core register
sets using the PTRACE_GETREGSET and PTRACE_SETREGSET operations. The
details of the internal context structures is abstracted into user API
structures to both ease use and allow flexibility to change the internal
context layouts. Copyin and copyout functions for these register sets
are exposed to allow signal handling code to use them to copy to and
from the signal context.
struct user_gp_regs (NT_PRSTATUS) provides access to the core general
purpose register context.
struct user_cb_regs (NT_METAG_CBUF) provides access to the TXCATCH*
registers which contains information abuot a memory fault, unaligned
access error or watchpoint. This can be modified to alter the way the
fault is replayed on resume (catch replay), or to prevent the replay
taking place.
struct user_rp_state (NT_METAG_RPIPE) provides access to the state of
the Meta read pipeline which can be used to hide memory latencies in
hand optimised data loops.
Extended DSP register state, DSP RAM, and hardware breakpoint registers
aren't yet exposed through ptrace.
Signed-off-by: James Hogan james.ho...@imgtec.com
---
arch/metag/include/asm/ptrace.h | 60 ++
arch/metag/include/uapi/asm/ptrace.h | 113 ++
arch/metag/kernel/ptrace.c | 380 ++
include/uapi/linux/elf.h |2 +
4 files changed, 555 insertions(+), 0 deletions(-)
create mode 100644 arch/metag/include/asm/ptrace.h
create mode 100644 arch/metag/include/uapi/asm/ptrace.h
create mode 100644 arch/metag/kernel/ptrace.c
diff --git a/arch/metag/include/asm/ptrace.h b/arch/metag/include/asm/ptrace.h
new file mode 100644
index 000..fcabc18
--- /dev/null
+++ b/arch/metag/include/asm/ptrace.h
@@ -0,0 +1,60 @@
+#ifndef _METAG_PTRACE_H
+#define _METAG_PTRACE_H
+
+#include linux/compiler.h
+#include uapi/asm/ptrace.h
+#include asm/tbx.h
+
+#ifndef __ASSEMBLY__
+
+/* this struct defines the way the registers are stored on the
+ stack during a system call. */
+
+struct pt_regs {
+ TBICTX ctx;
+ TBICTXEXTCB0 extcb0[5];
+};
+
+#define user_mode(regs) (((regs)-ctx.SaveMask TBICTX_PRIV_BIT) 0)
+
+#define instruction_pointer(regs) ((unsigned long)(regs)-ctx.CurrPC)
+#define profile_pc(regs) instruction_pointer(regs)
+
+#define task_pt_regs(task) \
+ ((struct pt_regs *)(task_stack_page(task) + \
+ sizeof(struct thread_info)))
+
+#define current_pt_regs() \
+ ((struct pt_regs *)((char *)current_thread_info() + \
+ sizeof(struct thread_info)))
+
+int syscall_trace_enter(struct pt_regs *regs);
+void syscall_trace_leave(struct pt_regs *regs);
+
+/* copy a struct user_gp_regs out to user */
+int metag_gp_regs_copyout(const struct pt_regs *regs,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf);
+/* copy a struct user_gp_regs in from user */
+int metag_gp_regs_copyin(struct pt_regs *regs,
+unsigned int pos, unsigned int count,
+const void *kbuf, const void __user *ubuf);
+/* copy a struct user_cb_regs out to user */
+int metag_cb_regs_copyout(const struct pt_regs *regs,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf);
+/* copy a struct user_cb_regs in from user */
+int metag_cb_regs_copyin(struct pt_regs *regs,
+unsigned int pos, unsigned int count,
+const void *kbuf, const void __user *ubuf);
+/* copy a struct user_rp_state out to user */
+int metag_rp_state_copyout(const struct pt_regs *regs,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf);
+/* copy a struct user_rp_state in from user */
+int metag_rp_state_copyin(struct pt_regs *regs,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf);
+
+#endif /* __ASSEMBLY__ */
+#endif /* _METAG_PTRACE_H */
diff --git a/arch/metag/include/uapi/asm/ptrace.h
b/arch/metag/include/uapi/asm/ptrace.h
new file mode 100644
index 000..45d9780
--- /dev/null
+++ b/arch/metag/include/uapi/asm/ptrace.h
@@ -0,0 +1,113 @@
+#ifndef _UAPI_METAG_PTRACE_H
+#define _UAPI_METAG_PTRACE_H
+
+#ifndef __ASSEMBLY__
+
+/*
+ * These are the layouts of the regsets returned by the GETREGSET ptrace call
+ */
+
+/* user_gp_regs::status */
+
+/* CBMarker bit (indicates catch state / catch replay) */
+#define USER_GP_REGS_STATUS_CATCH_BIT (1 22)
+#define USER_GP_REGS_STATUS_CATCH_S22
+/* LSM_STEP field (load/store multiple step) */
+#define USER_GP_REGS_STATUS_LSM_STEP_BITS (0x7 8)
+#define USER_GP_REGS_STATUS_LSM_STEP_S 8
+/* SCC bit (indicates split 16x16 condition flags) */
+#define USER_GP_REGS_STATUS_SCC_BIT(1 4)
+#define
[PATCH v2 35/44] mm: define VM_GROWSUP for CONFIG_METAG
Commit cc2383ec06be093789469852e1fe96e1148e9a2c (mm: introduce arch-specific vma flag VM_ARCH_1) merged in v3.7-rc1. The above commit combined several arch-specific vma flags into one, and in the process it changed the VM_GROWSUP definition to depend on specific architectures rather than CONFIG_STACK_GROWSUP. Therefore add an ifdef for CONFIG_METAG to also set VM_GROWSUP. Signed-off-by: James Hogan james.ho...@imgtec.com --- include/linux/mm.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index bcaab4e..85c1df8 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -114,6 +114,8 @@ extern unsigned int kobjsize(const void *objp); # define VM_SAOVM_ARCH_1 /* Strong Access Ordering (powerpc) */ #elif defined(CONFIG_PARISC) # define VM_GROWSUPVM_ARCH_1 +#elif defined(CONFIG_METAG) +# define VM_GROWSUPVM_ARCH_1 #elif defined(CONFIG_IA64) # define VM_GROWSUPVM_ARCH_1 #elif !defined(CONFIG_MMU) -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 36/44] Add metag to various Kconfig dependency lists
Add [!]METAG to various Kconfig dependencies in generic code, as described below: - Kconfig.debug: don't allow stack utilization instrumentation on metag, and allow building with frame pointers. - char: don't build rtc or genrtc on METAG The metag architecture doesn't have a PC RTC or implement the RTC interface that genrtc expects, so add METAG to the list of architectures not to build RTC or GEN_RTC on. - i8042: don't build on METAG The metag architecture port doesn't support the i8042 keyboard controller, so add METAG to the list of architectures not to build it's driver on. - parport: don't build on METAG The metag architecture port doesn't support PC parallel ports, so add METAG to the list of architectures not to build it's driver on. - vga console: don't build on METAG The metag architecture doesn't support VGA so add METAG to the list of architectures not to build support on. TODO: invert the dependency logic of most of these with the help of a new LEGACY_PC_IO Kconfig symbol Signed-off-by: James Hogan james.ho...@imgtec.com --- drivers/char/Kconfig |5 +++-- drivers/input/serio/Kconfig |2 +- drivers/parport/Kconfig |3 ++- drivers/video/console/Kconfig |2 +- lib/Kconfig.debug |4 ++-- 5 files changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index 72bedad..59f7d70 100644 --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -283,7 +283,8 @@ if RTC_LIB=n config RTC tristate Enhanced Real Time Clock Support (legacy PC RTC driver) depends on !PPC !PARISC !IA64 !M68K !SPARC !FRV \ -!ARM !SUPERH !S390 !AVR32 !BLACKFIN !UML +!ARM !SUPERH !S390 !AVR32 !BLACKFIN \ +!UML !METAG ---help--- If you say Y here and create a character special file /dev/rtc with major number 10 and minor number 135 using mknod (man mknod), you @@ -331,7 +332,7 @@ config JS_RTC config GEN_RTC tristate Generic /dev/rtc emulation - depends on RTC!=y !IA64 !ARM !M32R !MIPS !SPARC !FRV !S390 !SUPERH !AVR32 !BLACKFIN !UML + depends on RTC!=y !IA64 !ARM !M32R !MIPS !SPARC !FRV !S390 !SUPERH !AVR32 !BLACKFIN !UML !METAG ---help--- If you say Y here and create a character special file /dev/rtc with major number 10 and minor number 135 using mknod (man mknod), you diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig index 55f2c22..60b2a09 100644 --- a/drivers/input/serio/Kconfig +++ b/drivers/input/serio/Kconfig @@ -22,7 +22,7 @@ config SERIO_I8042 tristate i8042 PC Keyboard controller if EXPERT || !X86 default y depends on !PARISC (!ARM || ARCH_SHARK || FOOTBRIDGE_HOST) \ - (!SUPERH || SH_CAYMAN) !M68K !BLACKFIN + (!SUPERH || SH_CAYMAN) !M68K !BLACKFIN !METAG help i8042 is the chip over which the standard AT keyboard and PS/2 mouse are connected to the computer. If you use these devices, diff --git a/drivers/parport/Kconfig b/drivers/parport/Kconfig index 4b6e4e7..ff2cea5 100644 --- a/drivers/parport/Kconfig +++ b/drivers/parport/Kconfig @@ -36,7 +36,8 @@ if PARPORT config PARPORT_PC tristate PC-style hardware depends on (!SPARC64 || PCI) !SPARC32 !M32R !FRV \ - (!M68K || ISA) !MN10300 !AVR32 !BLACKFIN !XTENSA + (!M68K || ISA) !MN10300 !AVR32 !BLACKFIN \ + !XTENSA !METAG ---help--- You should say Y here if you have a PC-style parallel port. All IBM PC compatible computers and some Alphas have PC-style diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig index e2c96d0..3ee55e1 100644 --- a/drivers/video/console/Kconfig +++ b/drivers/video/console/Kconfig @@ -6,7 +6,7 @@ menu Console display driver support config VGA_CONSOLE bool VGA text console if EXPERT || !X86 - depends on !4xx !8xx !SPARC !M68K !PARISC !FRV !SUPERH !BLACKFIN !AVR32 !MN10300 (!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER) + depends on !4xx !8xx !SPARC !M68K !PARISC !FRV !SUPERH !BLACKFIN !AVR32 !MN10300 (!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER) !METAG default y help Saying Y here will allow you to use Linux in text mode through a diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 28e9d6c9..445fbe6 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -730,7 +730,7 @@ config STACKTRACE config DEBUG_STACK_USAGE bool Stack utilization instrumentation - depends on DEBUG_KERNEL !IA64 !PARISC + depends on DEBUG_KERNEL !IA64 !PARISC !METAG help Enables the display
[PATCH v2 44/44] fs: imgdafs: Add IMG DAFS filesystem for metag
Add the IMG Debug Adapter File System (DAFS) for metag, which uses
SWITCH operations to communicate with a file server on a host computer
via a JTAG debug adapter.
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Alexander Viro v...@zeniv.linux.org.uk
Cc: linux-fsde...@vger.kernel.org
---
MAINTAINERS |1 +
arch/metag/Kconfig |1 +
fs/Kconfig |1 +
fs/Makefile |1 +
fs/imgdafs/Kconfig |6 +
fs/imgdafs/Makefile |7 +
fs/imgdafs/imgdafs.h | 80 +
fs/imgdafs/inode.c | 840 ++
8 files changed, 937 insertions(+), 0 deletions(-)
create mode 100644 fs/imgdafs/Kconfig
create mode 100644 fs/imgdafs/Makefile
create mode 100644 fs/imgdafs/imgdafs.h
create mode 100644 fs/imgdafs/inode.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 9ed766d..07294e0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4857,6 +4857,7 @@ F:arch/metag/
F: Documentation/metag/
F: Documentation/devicetree/bindings/metag/
F: drivers/tty/metag_da.c
+F: fs/imgdafs/
MICROBLAZE ARCHITECTURE
M: Michal Simek mon...@monstr.eu
diff --git a/arch/metag/Kconfig b/arch/metag/Kconfig
index 9489431..29787c8 100644
--- a/arch/metag/Kconfig
+++ b/arch/metag/Kconfig
@@ -223,6 +223,7 @@ config METAG_DA
This enables support for services provided by DA JTAG debug adapters,
such as:
- communication over DA channels (such as the console driver).
+ - use of the DA filesystem.
menu Boot options
diff --git a/fs/Kconfig b/fs/Kconfig
index f95ae3a..b2d09b0 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -220,6 +220,7 @@ source fs/pstore/Kconfig
source fs/sysv/Kconfig
source fs/ufs/Kconfig
source fs/exofs/Kconfig
+source fs/imgdafs/Kconfig
endif # MISC_FILESYSTEMS
diff --git a/fs/Makefile b/fs/Makefile
index 1d7af79..7b478a5 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -126,3 +126,4 @@ obj-$(CONFIG_GFS2_FS) += gfs2/
obj-y += exofs/ # Multiple modules
obj-$(CONFIG_CEPH_FS) += ceph/
obj-$(CONFIG_PSTORE) += pstore/
+obj-$(CONFIG_IMGDAFS_FS) += imgdafs/
diff --git a/fs/imgdafs/Kconfig b/fs/imgdafs/Kconfig
new file mode 100644
index 000..5293adb
--- /dev/null
+++ b/fs/imgdafs/Kconfig
@@ -0,0 +1,6 @@
+config IMGDAFS_FS
+ bool Meta DA filesystem support
+ depends on METAG_DA
+ help
+ This enables the DA filesystem, which allows Linux to
+ to access files on a system attached via a debug adapter.
diff --git a/fs/imgdafs/Makefile b/fs/imgdafs/Makefile
new file mode 100644
index 000..169a3c6
--- /dev/null
+++ b/fs/imgdafs/Makefile
@@ -0,0 +1,7 @@
+#
+# Makefile for DAfs the Debug Adapter filesystem.
+#
+
+obj-$(CONFIG_IMGDAFS_FS) += imgdafs.o
+
+imgdafs-objs := inode.o
diff --git a/fs/imgdafs/imgdafs.h b/fs/imgdafs/imgdafs.h
new file mode 100644
index 000..6c1da13
--- /dev/null
+++ b/fs/imgdafs/imgdafs.h
@@ -0,0 +1,80 @@
+#ifndef _IMGDAFS_H_
+#define _IMGDAFS_H_
+
+#define DA_OP_OPEN 0
+#define DA_OP_CREAT 1
+#define DA_OP_READ 2
+#define DA_OP_WRITE 3
+#define DA_OP_CLOSE 4
+#define DA_OP_LINK 5
+#define DA_OP_LSEEK 6
+#define DA_OP_UNLINK 7
+#define DA_OP_ISATTY 8
+#define DA_OP_FCNTL 9
+#define DA_OP_STAT 10
+#define DA_OP_FSTAT 11
+#define DA_OP_GETCWD 12
+#define DA_OP_CHDIR 13
+#define DA_OP_MKDIR 14
+#define DA_OP_RMDIR 15
+#define DA_OP_FINDFIRST 16
+#define DA_OP_FINDNEXT 17
+#define DA_OP_FINDCLOSE 18
+#define DA_OP_CHMOD 19
+#define DA_OP_PREAD 20
+#define DA_OP_PWRITE 21
+
+#define OS_TYPE_FILE 1
+#define OS_TYPE_DIR 2
+#define OS_TYPE_SYMLINK 3
+#define OS_TYPE_CHARDEV 4
+#define OS_TYPE_BLOCKDEV 5
+#define OS_TYPE_FIFO 6
+#define OS_TYPE_SOCK 7
+
+#define DA_O_RDONLY 0
+#define DA_O_WRONLY 1
+#define DA_O_RDWR 2
+#define DA_O_APPEND 8
+#define DA_O_CREAT 0x0200
+#define DA_O_TRUNC 0x0400
+#define DA_O_EXCL 0x0800
+
+#define DA_O_AFFINITY_THREAD_0 0x1
+#define DA_O_AFFINITY_THREAD_1 0x2
+#define DA_O_AFFINITY_THREAD_2 0x4
+#define DA_O_AFFINITY_THREAD_3 0x8
+#define DA_O_AFFINITY_SHIFT 16
+
+#define DA_S_IWUSR 0200/* 0x80 */
+#define DA_S_IRUSR 0400/* 0x100 */
+
+struct da_stat {
+ short st_dev;
+ unsigned short st_ino;
+ unsigned st_mode;
+ unsigned short st_nlink;
+ unsigned short st_uid;
+ unsigned short st_gid;
+ short st_rdev;
+ int st_size;
+ int st_atime;
+ int st_spare1;
+ int st_mtime;
+ int st_spare2;
+ int st_ctime;
+ int st_spare3;
+ int st_blksize;
+ int st_blocks;
+ int st_spare4[2];
+};
+
+#define _A_SUBDIR 0x10
+
+struct da_finddata {
+ unsigned long size;
+ unsigned long attrib;
+ char name[260];
+};
+
+#endif
diff --git a/fs/imgdafs/inode.c b/fs/imgdafs/inode.c
new file mode 100644
index 000..b7d7199
--- /dev/null
+++ b/fs/imgdafs/inode.c
@@ -0,0 +1,840 @@
+/*
+ * Copyright (C)
[PATCH v2 43/44] tty/metag_da: Add metag DA TTY driver
Add a TTY driver for communicating over a Meta DA (Debug Adapter)
channel using the bios channel SWITCH operation.
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
MAINTAINERS|1 +
arch/metag/Kconfig |4 +-
arch/metag/configs/meta1_defconfig |2 +
arch/metag/configs/meta2_defconfig |2 +
arch/metag/configs/meta2_smp_defconfig |2 +
arch/metag/kernel/setup.c | 12 +
drivers/tty/Kconfig| 13 +
drivers/tty/Makefile |1 +
drivers/tty/metag_da.c | 523
9 files changed, 559 insertions(+), 1 deletions(-)
create mode 100644 drivers/tty/metag_da.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b2b64ea..9ed766d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4856,6 +4856,7 @@ S:Maintained
F: arch/metag/
F: Documentation/metag/
F: Documentation/devicetree/bindings/metag/
+F: drivers/tty/metag_da.c
MICROBLAZE ARCHITECTURE
M: Michal Simek mon...@monstr.eu
diff --git a/arch/metag/Kconfig b/arch/metag/Kconfig
index 5807964..9489431 100644
--- a/arch/metag/Kconfig
+++ b/arch/metag/Kconfig
@@ -220,7 +220,9 @@ config METAG_DA
of the DA will be detected automatically at boot, so it is safe to say
Y to this option even when booting without a DA.
- This enables support for services provided by DA JTAG debug adapters.
+ This enables support for services provided by DA JTAG debug adapters,
+ such as:
+ - communication over DA channels (such as the console driver).
menu Boot options
diff --git a/arch/metag/configs/meta1_defconfig
b/arch/metag/configs/meta1_defconfig
index 76a2d5f..f440e5a 100644
--- a/arch/metag/configs/meta1_defconfig
+++ b/arch/metag/configs/meta1_defconfig
@@ -28,6 +28,8 @@ CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_SERIO is not set
# CONFIG_VT is not set
# CONFIG_LEGACY_PTYS is not set
+CONFIG_DA_TTY=y
+CONFIG_DA_CONSOLE=y
# CONFIG_DEVKMEM is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_HWMON is not set
diff --git a/arch/metag/configs/meta2_defconfig
b/arch/metag/configs/meta2_defconfig
index 0b46722..b9ecdd2 100644
--- a/arch/metag/configs/meta2_defconfig
+++ b/arch/metag/configs/meta2_defconfig
@@ -29,6 +29,8 @@ CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_SERIO is not set
# CONFIG_VT is not set
# CONFIG_LEGACY_PTYS is not set
+CONFIG_DA_TTY=y
+CONFIG_DA_CONSOLE=y
# CONFIG_DEVKMEM is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_HWMON is not set
diff --git a/arch/metag/configs/meta2_smp_defconfig
b/arch/metag/configs/meta2_smp_defconfig
index b254e6c..87b60eb 100644
--- a/arch/metag/configs/meta2_smp_defconfig
+++ b/arch/metag/configs/meta2_smp_defconfig
@@ -30,6 +30,8 @@ CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_SERIO is not set
# CONFIG_VT is not set
# CONFIG_LEGACY_PTYS is not set
+CONFIG_DA_TTY=y
+CONFIG_DA_CONSOLE=y
# CONFIG_DEVKMEM is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_HWMON is not set
diff --git a/arch/metag/kernel/setup.c b/arch/metag/kernel/setup.c
index 65e8641..35d129f 100644
--- a/arch/metag/kernel/setup.c
+++ b/arch/metag/kernel/setup.c
@@ -61,6 +61,11 @@ extern char _heap_start[];
extern u32 __dtb_start[];
#endif
+#ifdef CONFIG_DA_CONSOLE
+/* Our early channel based console driver */
+extern struct console dash_console;
+#endif
+
struct machine_desc *machine_desc __initdata;
/*
@@ -184,6 +189,13 @@ void __init setup_arch(char **cmdline_p)
int heap_id, i;
metag_da_probe();
+#ifdef CONFIG_DA_CONSOLE
+ if (metag_da_enabled()) {
+ /* An early channel based console driver */
+ register_console(dash_console);
+ add_preferred_console(ttyDA, 1, NULL);
+ }
+#endif
/* try interpreting the argument as a device tree */
machine_desc = setup_machine_fdt(original_cmd_line);
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index d8e05ee..182f92b 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -387,3 +387,16 @@ config PPC_EARLY_DEBUG_EHV_BC_HANDLE
If the number you specify is not a valid byte channel handle, then
there simply will be no early console output. This is true also
if you don't boot under a hypervisor at all.
+
+config DA_TTY
+ bool DA TTY
+ depends on METAG_DA
+ select SERIAL_NONSTANDARD
+ help
+ This enables a TTY on a Dash channel.
+
+config DA_CONSOLE
+ bool DA Console
+ depends on DA_TTY
+ help
+ This enables a console on a Dash channel.
diff --git a/drivers/tty/Makefile b/drivers/tty/Makefile
index 2953059..dbd7745 100644
--- a/drivers/tty/Makefile
+++ b/drivers/tty/Makefile
@@ -27,5 +27,6 @@ obj-$(CONFIG_SYNCLINK_GT) += synclink_gt.o
obj-$(CONFIG_SYNCLINKMP) += synclinkmp.o
obj-$(CONFIG_SYNCLINK) += synclink.o
[PATCH v2 42/44] metag: Add JTAG Debug Adapter (DA) support
Add basic JTAG Debug Adapter (DA) support so that drivers which
communicate with the DA can detect whether one is actually present
(otherwise the target will halt indefinitely).
Signed-off-by: James Hogan james.ho...@imgtec.com
---
arch/metag/Kconfig |9 ++
arch/metag/configs/meta1_defconfig |1 +
arch/metag/configs/meta2_defconfig |1 +
arch/metag/configs/meta2_smp_defconfig |1 +
arch/metag/include/asm/da.h| 43
arch/metag/kernel/Makefile |1 +
arch/metag/kernel/da.c | 23 +
arch/metag/kernel/setup.c |3 ++
8 files changed, 82 insertions(+), 0 deletions(-)
create mode 100644 arch/metag/include/asm/da.h
create mode 100644 arch/metag/kernel/da.c
diff --git a/arch/metag/Kconfig b/arch/metag/Kconfig
index d198c9b..5807964 100644
--- a/arch/metag/Kconfig
+++ b/arch/metag/Kconfig
@@ -213,6 +213,15 @@ config METAG_PERFCOUNTER_IRQS
When disabled, Performance Counters information will be collected
based on Timer Interrupt.
+config METAG_DA
+ bool DA support
+ help
+ Say Y if you plan to use a DA debug adapter with Linux. The presence
+ of the DA will be detected automatically at boot, so it is safe to say
+ Y to this option even when booting without a DA.
+
+ This enables support for services provided by DA JTAG debug adapters.
+
menu Boot options
config METAG_BUILTIN_DTB
diff --git a/arch/metag/configs/meta1_defconfig
b/arch/metag/configs/meta1_defconfig
index 74cc490..76a2d5f 100644
--- a/arch/metag/configs/meta1_defconfig
+++ b/arch/metag/configs/meta1_defconfig
@@ -14,6 +14,7 @@ CONFIG_PARTITION_ADVANCED=y
# CONFIG_IOSCHED_CFQ is not set
CONFIG_FLATMEM_MANUAL=y
CONFIG_META12_FPGA=y
+CONFIG_METAG_DA=y
CONFIG_HZ_100=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
diff --git a/arch/metag/configs/meta2_defconfig
b/arch/metag/configs/meta2_defconfig
index ad4ee2b..0b46722 100644
--- a/arch/metag/configs/meta2_defconfig
+++ b/arch/metag/configs/meta2_defconfig
@@ -16,6 +16,7 @@ CONFIG_PARTITION_ADVANCED=y
CONFIG_METAG_L2C=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_METAG_HALT_ON_PANIC=y
+CONFIG_METAG_DA=y
CONFIG_HZ_100=y
CONFIG_DEVTMPFS=y
# CONFIG_STANDALONE is not set
diff --git a/arch/metag/configs/meta2_smp_defconfig
b/arch/metag/configs/meta2_smp_defconfig
index d9349df..b254e6c 100644
--- a/arch/metag/configs/meta2_smp_defconfig
+++ b/arch/metag/configs/meta2_smp_defconfig
@@ -17,6 +17,7 @@ CONFIG_METAG_L2C=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_METAG_HALT_ON_PANIC=y
CONFIG_SMP=y
+CONFIG_METAG_DA=y
CONFIG_HZ_100=y
CONFIG_DEVTMPFS=y
# CONFIG_STANDALONE is not set
diff --git a/arch/metag/include/asm/da.h b/arch/metag/include/asm/da.h
new file mode 100644
index 000..81bd521
--- /dev/null
+++ b/arch/metag/include/asm/da.h
@@ -0,0 +1,43 @@
+/*
+ * Meta DA JTAG debugger control.
+ *
+ * Copyright 2012 Imagination Technologies Ltd.
+ */
+
+#ifndef _METAG_DA_H_
+#define _METAG_DA_H_
+
+#ifdef CONFIG_METAG_DA
+
+#include linux/init.h
+#include linux/types.h
+
+extern bool _metag_da_present;
+
+/**
+ * metag_da_enabled() - Find whether a DA is currently enabled.
+ *
+ * Returns:true if a DA was detected, false if not.
+ */
+static inline bool metag_da_enabled(void)
+{
+ return _metag_da_present;
+}
+
+/**
+ * metag_da_probe() - Try and detect a connected DA.
+ *
+ * This is used at start up to detect whether a DA is active.
+ *
+ * Returns:0 on detection, -err otherwise.
+ */
+int __init metag_da_probe(void);
+
+#else /* !CONFIG_METAG_DA */
+
+#define metag_da_enabled() false
+#define metag_da_probe() do {} while (0)
+
+#endif
+
+#endif /* _METAG_DA_H_ */
diff --git a/arch/metag/kernel/Makefile b/arch/metag/kernel/Makefile
index 01536f9..228607e 100644
--- a/arch/metag/kernel/Makefile
+++ b/arch/metag/kernel/Makefile
@@ -29,6 +29,7 @@ obj-y += user_gateway.o
obj-$(CONFIG_PERF_EVENTS) += perf/
obj-$(CONFIG_METAG_COREMEM)+= coremem.o
+obj-$(CONFIG_METAG_DA) += da.o
obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o
obj-$(CONFIG_FUNCTION_TRACER) += ftrace_stub.o
obj-$(CONFIG_METAG_PERFCOUNTER_IRQS) += irq_internal.o
diff --git a/arch/metag/kernel/da.c b/arch/metag/kernel/da.c
new file mode 100644
index 000..52aabb6
--- /dev/null
+++ b/arch/metag/kernel/da.c
@@ -0,0 +1,23 @@
+/*
+ * Meta DA JTAG debugger control.
+ *
+ * Copyright 2012 Imagination Technologies Ltd.
+ */
+
+
+#include linux/io.h
+#include linux/kernel.h
+#include asm/da.h
+#include asm/metag_mem.h
+
+bool _metag_da_present;
+
+int __init metag_da_probe(void)
+{
+ _metag_da_present = (metag_in32(T0VECINT_BHALT) == 1);
+ if (_metag_da_present)
+ pr_info(DA present\n);
+ else
+ pr_info(DA not present\n);
+ return 0;
+}
diff --git a/arch/metag/kernel/setup.c b/arch/metag/kernel/setup.c
index
[PATCH v2 41/44] metag: OProfile
Add oprofile support for metag.
Signed-off-by: James Hogan james.ho...@imgtec.com
---
arch/metag/Kconfig|1 +
arch/metag/Makefile |2 +
arch/metag/oprofile/Makefile | 16 ++
arch/metag/oprofile/backtrace.c | 134 ++
arch/metag/oprofile/backtrace.h |6 +
arch/metag/oprofile/op_model_meta12.c | 242 +
6 files changed, 401 insertions(+), 0 deletions(-)
create mode 100644 arch/metag/oprofile/Makefile
create mode 100644 arch/metag/oprofile/backtrace.c
create mode 100644 arch/metag/oprofile/backtrace.h
create mode 100644 arch/metag/oprofile/op_model_meta12.c
diff --git a/arch/metag/Kconfig b/arch/metag/Kconfig
index 4c731d80..d198c9b 100644
--- a/arch/metag/Kconfig
+++ b/arch/metag/Kconfig
@@ -26,6 +26,7 @@ config METAG
select HAVE_MEMBLOCK
select HAVE_MEMBLOCK_NODE_MAP
select HAVE_MOD_ARCH_SPECIFIC
+ select HAVE_OPROFILE
select HAVE_PERF_EVENTS
select HAVE_SYSCALL_TRACEPOINTS
select IRQ_DOMAIN
diff --git a/arch/metag/Makefile b/arch/metag/Makefile
index d455140..53fc094 100644
--- a/arch/metag/Makefile
+++ b/arch/metag/Makefile
@@ -49,6 +49,8 @@ core-y+=
arch/metag/mm/
libs-y += arch/metag/lib/
libs-y += arch/metag/tbx/
+drivers-$(CONFIG_OPROFILE) += arch/metag/oprofile/
+
boot := arch/metag/boot
boot_targets += uImage
diff --git a/arch/metag/oprofile/Makefile b/arch/metag/oprofile/Makefile
new file mode 100644
index 000..4b4ceee
--- /dev/null
+++ b/arch/metag/oprofile/Makefile
@@ -0,0 +1,16 @@
+obj-y += oprofile.o
+
+oprofile-core-y+= buffer_sync.o
+oprofile-core-y+= cpu_buffer.o
+oprofile-core-y+= event_buffer.o
+oprofile-core-y+= oprof.o
+oprofile-core-y+= oprofile_files.o
+oprofile-core-y+= oprofile_stats.o
+oprofile-core-y+= oprofilefs.o
+oprofile-core-y+= timer_int.o
+
+oprofile-y += backtrace.o
+oprofile-y += op_model_meta12.o
+oprofile-y += $(addprefix ../../../drivers/oprofile/,$(oprofile-core-y))
+
+ccflags-y += -Werror
diff --git a/arch/metag/oprofile/backtrace.c b/arch/metag/oprofile/backtrace.c
new file mode 100644
index 000..0ae7489
--- /dev/null
+++ b/arch/metag/oprofile/backtrace.c
@@ -0,0 +1,134 @@
+/*
+ * Copyright (C) 2010 Imagination Technologies Ltd.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ */
+
+#include linux/oprofile.h
+#include linux/sched.h
+#include linux/mm.h
+#include linux/io.h
+#include linux/uaccess.h
+#include backtrace.h
+
+#ifdef CONFIG_FRAME_POINTER
+
+#ifdef CONFIG_KALLSYMS
+#include linux/kallsyms.h
+#include linux/module.h
+
+static unsigned long tbi_boing_addr;
+static unsigned long tbi_boing_size;
+#endif
+
+static void user_backtrace_fp(unsigned long __user *fp, unsigned int depth)
+{
+ while (depth-- access_ok(VERIFY_READ, fp, 8)) {
+ unsigned long addr;
+ unsigned long __user *fpnew;
+ if (__copy_from_user_inatomic(addr, fp + 1, sizeof(addr)))
+ break;
+ addr -= 4;
+
+ oprofile_add_trace(addr);
+
+ /* stack grows up, so frame pointers must decrease */
+ if (__copy_from_user_inatomic(fpnew, fp + 0, sizeof(fpnew)))
+ break;
+ if (fpnew fp)
+ break;
+ fp = fpnew;
+ }
+}
+
+static void kernel_backtrace_fp(unsigned long *fp, unsigned long *stack,
+ unsigned int depth)
+{
+#ifdef CONFIG_KALLSYMS
+ /* We need to know where TBIBoingVec is and it's size */
+ if (!tbi_boing_addr) {
+ unsigned long size;
+ unsigned long offset;
+ char modname[MODULE_NAME_LEN];
+ char name[KSYM_NAME_LEN];
+ tbi_boing_addr = kallsyms_lookup_name(___TBIBoingVec);
+ if (!tbi_boing_addr)
+ tbi_boing_addr = 1;
+ else if (!lookup_symbol_attrs(tbi_boing_addr, size,
+ offset, modname, name))
+ tbi_boing_size = size;
+ }
+#endif
+ /* detect when the frame pointer has been used for other purposes and
+* doesn't point to the stack (it may point completely elsewhere which
+* kstack_end may not detect).
+*/
+ while (depth-- fp = stack fp + 8 = stack + THREAD_SIZE) {
+ unsigned long addr;
+ unsigned long *fpnew;
+
+ addr = fp[1] - 4;
+ if (!__kernel_text_address(addr))
+
[PATCH v2 40/44] scripts/checkstack.pl: Add metag support
Adapt checkstack.pl so that it works for metag.
Signed-off-by: James Hogan james.ho...@imgtec.com
---
scripts/checkstack.pl |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/scripts/checkstack.pl b/scripts/checkstack.pl
index 17e3843..544aa56 100755
--- a/scripts/checkstack.pl
+++ b/scripts/checkstack.pl
@@ -34,7 +34,7 @@ use strict;
# $1 (first bracket) matches the dynamic amount of the stack growth
#
# use anything else and feel the pain ;)
-my (@stack, $re, $dre, $x, $xs);
+my (@stack, $re, $dre, $x, $xs, $funcre);
{
my $arch = shift;
if ($arch eq ) {
@@ -44,6 +44,7 @@ my (@stack, $re, $dre, $x, $xs);
$x = [0-9a-f]; # hex character
$xs = [0-9a-f ]; # hex character or space
+ $funcre = qr/^$x* (.*):$/;
if ($arch eq 'arm') {
#c0008ffc: e24dd064sub sp, sp, #100; 0x64
$re = qr/.*sub.*sp, sp, #(([0-9]{2}|[3-9])[0-9]{2})/o;
@@ -66,6 +67,10 @@ my (@stack, $re, $dre, $x, $xs);
#2b6c: 4e56 fb70 linkw %fp,#-1168
# 1df770: defc ffe4 addaw #-28,%sp
$re = qr/.*(?:linkw %fp,|addaw )#-([0-9]{1,4})(?:,%sp)?$/o;
+ } elsif ($arch eq 'metag') {
+ #400026fc: 40 00 00 82 ADD A0StP,A0StP,#0x8
+ $re = qr/.*ADD.*A0StP,A0StP,\#(0x$x{1,8})/o;
+ $funcre = qr/^$x* [^\$](.*):$/;
} elsif ($arch eq 'mips64') {
#8800402c: 67bdfff0daddiu sp,sp,-16
$re = qr/.*daddiu.*sp,sp,-(([0-9]{2}|[3-9])[0-9]{2})/o;
@@ -109,7 +114,6 @@ my (@stack, $re, $dre, $x, $xs);
#
# main()
#
-my $funcre = qr/^$x* (.*):$/;
my ($func, $file, $lastslash);
while (my $line = STDIN) {
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 38/44] metag: Perf
Add Perf support for metag.
Signed-off-by: James Hogan james.ho...@imgtec.com
---
arch/metag/Kconfig |1 +
arch/metag/include/asm/perf_event.h |4 +
arch/metag/kernel/Makefile |2 +
arch/metag/kernel/perf/Makefile |3 +
arch/metag/kernel/perf/perf_event.c | 859 +++
arch/metag/kernel/perf/perf_event.h | 106 +
arch/metag/kernel/perf_callchain.c | 96
7 files changed, 1071 insertions(+), 0 deletions(-)
create mode 100644 arch/metag/include/asm/perf_event.h
create mode 100644 arch/metag/kernel/perf/Makefile
create mode 100644 arch/metag/kernel/perf/perf_event.c
create mode 100644 arch/metag/kernel/perf/perf_event.h
create mode 100644 arch/metag/kernel/perf_callchain.c
diff --git a/arch/metag/Kconfig b/arch/metag/Kconfig
index 60575ee..073c324 100644
--- a/arch/metag/Kconfig
+++ b/arch/metag/Kconfig
@@ -21,6 +21,7 @@ config METAG
select HAVE_MEMBLOCK
select HAVE_MEMBLOCK_NODE_MAP
select HAVE_MOD_ARCH_SPECIFIC
+ select HAVE_PERF_EVENTS
select HAVE_SYSCALL_TRACEPOINTS
select IRQ_DOMAIN
select MODULES_USE_ELF_RELA
diff --git a/arch/metag/include/asm/perf_event.h
b/arch/metag/include/asm/perf_event.h
new file mode 100644
index 000..105bbff
--- /dev/null
+++ b/arch/metag/include/asm/perf_event.h
@@ -0,0 +1,4 @@
+#ifndef __ASM_METAG_PERF_EVENT_H
+#define __ASM_METAG_PERF_EVENT_H
+
+#endif /* __ASM_METAG_PERF_EVENT_H */
diff --git a/arch/metag/kernel/Makefile b/arch/metag/kernel/Makefile
index abe0e03..01536f9 100644
--- a/arch/metag/kernel/Makefile
+++ b/arch/metag/kernel/Makefile
@@ -26,6 +26,8 @@ obj-y += topology.o
obj-y += traps.o
obj-y += user_gateway.o
+obj-$(CONFIG_PERF_EVENTS) += perf/
+
obj-$(CONFIG_METAG_COREMEM)+= coremem.o
obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o
obj-$(CONFIG_FUNCTION_TRACER) += ftrace_stub.o
diff --git a/arch/metag/kernel/perf/Makefile b/arch/metag/kernel/perf/Makefile
new file mode 100644
index 000..b158cb2
--- /dev/null
+++ b/arch/metag/kernel/perf/Makefile
@@ -0,0 +1,3 @@
+# Makefile for performance event core
+
+obj-y += perf_event.o
diff --git a/arch/metag/kernel/perf/perf_event.c
b/arch/metag/kernel/perf/perf_event.c
new file mode 100644
index 000..8219802
--- /dev/null
+++ b/arch/metag/kernel/perf/perf_event.c
@@ -0,0 +1,859 @@
+/*
+ * Meta performance counter support.
+ * Copyright (C) 2012 Imagination Technologies Ltd
+ *
+ * This code is based on the sh pmu code:
+ * Copyright (C) 2009 Paul Mundt
+ *
+ * and on the arm pmu code:
+ * Copyright (C) 2009 picoChip Designs, Ltd., James Iles
+ * Copyright (C) 2010 ARM Ltd., Will Deacon will.dea...@arm.com
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ */
+
+#include linux/atomic.h
+#include linux/export.h
+#include linux/init.h
+#include linux/perf_event.h
+#include linux/slab.h
+
+#include asm/hwthread.h
+#include asm/io.h
+#include asm/irq.h
+#include asm/irq_internal.h
+
+#include perf_event.h
+
+static int _hw_perf_event_init(struct perf_event *);
+static void _hw_perf_event_destroy(struct perf_event *);
+
+/* Determines which core type we are */
+static struct metag_pmu *metag_pmu __read_mostly;
+
+/* Processor specific data */
+static DEFINE_PER_CPU(struct cpu_hw_events, cpu_hw_events);
+
+/* PMU admin */
+const char *perf_pmu_name(void)
+{
+ if (metag_pmu)
+ return metag_pmu-pmu.name;
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(perf_pmu_name);
+
+int perf_num_counters(void)
+{
+ if (metag_pmu)
+ return metag_pmu-max_events;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(perf_num_counters);
+
+static inline int metag_pmu_initialised(void)
+{
+ return !!metag_pmu;
+}
+
+static void release_pmu_hardware(void)
+{
+ unsigned int version = (metag_pmu-version
+ (METAC_ID_MINOR_BITS | METAC_ID_REV_BITS))
+ METAC_ID_REV_S;
+
+ /* Early cores don't have overflow interrupts */
+ if (version 0x0104)
+ return;
+
+ free_irq(HWSTATMETA_TO_IRQ(17), NULL);
+ free_irq(HWSTATMETA_TO_IRQ(16), NULL);
+}
+
+static int reserve_pmu_hardware(void)
+{
+ int err = 0, irq;
+ unsigned int version = (metag_pmu-version
+ (METAC_ID_MINOR_BITS | METAC_ID_REV_BITS))
+ METAC_ID_REV_S;
+
+ /* Early cores don't have overflow interrupts */
+ if (version 0x0104)
+ goto out;
+
+ /*
+* Bit 16 on HWSTATMETA is the interrupt for performance counter 0;
+* similarly, 17 is the interrupt for performance counter 1.
+* We can't (yet) interrupt on the cycle counter, because it's a
+* register, however it holds a 32-bit value as opposed to 24-bit.
+*/
+ irq
[PATCH v2] x86,AMD: Power driver support for AMD's family 16h processors
Add family 16h PCI ID to AMD's power driver to allow it report
power consumption on these processors.
Signed-off-by: Boris Ostrovsky boris.ostrov...@amd.com
---
drivers/hwmon/fam15h_power.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index 4f41104..34ab2a8 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -31,6 +31,9 @@ MODULE_DESCRIPTION(AMD Family 15h CPU processor power
monitor);
MODULE_AUTHOR(Andreas Herrmann herrmann.der.u...@googlemail.com);
MODULE_LICENSE(GPL);
+/* Family 16h Northbridge's function 4 PCI ID */
+#define PCI_DEVICE_ID_AMD_16H_NB_F40x1534
+
/* D18F3 */
#define REG_NORTHBRIDGE_CAP0xe8
@@ -248,6 +251,7 @@ static void __devexit fam15h_power_remove(struct pci_dev
*pdev)
static DEFINE_PCI_DEVICE_TABLE(fam15h_power_id_table) = {
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F4) },
+ { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F4) },
{}
};
MODULE_DEVICE_TABLE(pci, fam15h_power_id_table);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 37/44] metag: Build infrastructure
Add metag build infrastructure. TODO: use generic CMDLINE Kconfig symbols Signed-off-by: James Hogan james.ho...@imgtec.com --- arch/metag/Kconfig | 299 arch/metag/Kconfig.debug | 40 + arch/metag/Kconfig.soc | 55 ++ arch/metag/Makefile| 87 + arch/metag/boot/Makefile | 68 +++ arch/metag/configs/meta1_defconfig | 39 arch/metag/configs/meta2_defconfig | 40 + arch/metag/configs/meta2_smp_defconfig | 41 + arch/metag/include/asm/Kbuild | 54 ++ arch/metag/include/uapi/asm/Kbuild | 13 ++ arch/metag/kernel/.gitignore |1 + arch/metag/kernel/Makefile | 38 arch/metag/kernel/asm-offsets.c| 14 ++ arch/metag/kernel/metag_ksyms.c| 74 arch/metag/kernel/vmlinux.lds.S| 71 arch/metag/lib/Makefile| 22 +++ arch/metag/mm/Kconfig | 153 arch/metag/mm/Makefile | 18 ++ arch/metag/tbx/Makefile| 22 +++ 19 files changed, 1149 insertions(+), 0 deletions(-) create mode 100644 arch/metag/Kconfig create mode 100644 arch/metag/Kconfig.debug create mode 100644 arch/metag/Kconfig.soc create mode 100644 arch/metag/Makefile create mode 100644 arch/metag/boot/Makefile create mode 100644 arch/metag/configs/meta1_defconfig create mode 100644 arch/metag/configs/meta2_defconfig create mode 100644 arch/metag/configs/meta2_smp_defconfig create mode 100644 arch/metag/include/asm/Kbuild create mode 100644 arch/metag/include/uapi/asm/Kbuild create mode 100644 arch/metag/kernel/.gitignore create mode 100644 arch/metag/kernel/Makefile create mode 100644 arch/metag/kernel/asm-offsets.c create mode 100644 arch/metag/kernel/metag_ksyms.c create mode 100644 arch/metag/kernel/vmlinux.lds.S create mode 100644 arch/metag/lib/Makefile create mode 100644 arch/metag/mm/Kconfig create mode 100644 arch/metag/mm/Makefile create mode 100644 arch/metag/tbx/Makefile diff --git a/arch/metag/Kconfig b/arch/metag/Kconfig new file mode 100644 index 000..60575ee --- /dev/null +++ b/arch/metag/Kconfig @@ -0,0 +1,299 @@ +config SYMBOL_PREFIX + string + default _ + +config METAG + def_bool y + select EMBEDDED + select GENERIC_ATOMIC64 + select GENERIC_CLOCKEVENTS + select GENERIC_IRQ_SHOW + select GENERIC_SMP_IDLE_THREAD + select HAVE_64BIT_ALIGNED_STRUCT + select HAVE_ARCH_TRACEHOOK + select HAVE_DEBUG_KMEMLEAK + select HAVE_GENERIC_HARDIRQS + select HAVE_IRQ_WORK + select HAVE_KERNEL_BZIP2 + select HAVE_KERNEL_GZIP + select HAVE_KERNEL_LZO + select HAVE_KERNEL_XZ + select HAVE_MEMBLOCK + select HAVE_MEMBLOCK_NODE_MAP + select HAVE_MOD_ARCH_SPECIFIC + select HAVE_SYSCALL_TRACEPOINTS + select IRQ_DOMAIN + select MODULES_USE_ELF_RELA + select OF + select OF_EARLY_FLATTREE + +config ARCH_NO_VIRT_TO_BUS + def_bool y + +config STACKTRACE_SUPPORT + def_bool y + +config LOCKDEP_SUPPORT + def_bool y + +config HAVE_LATENCYTOP_SUPPORT + def_bool y + +config RWSEM_GENERIC_SPINLOCK + def_bool y + +config RWSEM_XCHGADD_ALGORITHM + bool + +config GENERIC_HWEIGHT + def_bool y + +config GENERIC_CALIBRATE_DELAY + def_bool y + +config GENERIC_GPIO + def_bool n + +config NO_IOPORT + def_bool y + +source init/Kconfig + +source kernel/Kconfig.freezer + +menu Processor type and features + +config MMU + def_bool y + +config STACK_GROWSUP + def_bool y + +config HOTPLUG_CPU + bool Enable CPU hotplug support + depends on SMP + help + Say Y here to allow turning CPUs off and on. CPUs can be + controlled through /sys/devices/system/cpu. + + Say N if you want to disable CPU hotplug. + +config HIGHMEM + bool High Memory Support + help + The address space of Meta processors is only 4 Gigabytes large + and it has to accommodate user address space, kernel address + space as well as some memory mapped IO. That means that, if you + have a large amount of physical memory and/or IO, not all of the + memory can be permanently mapped by the kernel. The physical + memory that is not permanently mapped is called high memory. + + Depending on the selected kernel/user memory split, minimum + vmalloc space and actual amount of RAM, you may not need this + option which should result in a slightly faster kernel. + + If unsure, say n. + +source arch/metag/mm/Kconfig + +source arch/metag/Kconfig.soc + +config METAG_META12 + bool + help + Select this from the SoC config symbol to indicate that it contains a + Meta 1.2 core. + +config METAG_META21
[PATCH v2 22/44] metag: Time keeping
Add time keeping code for metag. Meta hardware threads have 2 timers.
The background timer (TXTIMER) is used as a free-running time base, and
the interrupt timer (TXTIMERI) is used for the timer interrupt. Both
counters traditionally count at approximately 1MHz.
Signed-off-by: James Hogan james.ho...@imgtec.com
---
arch/metag/include/asm/clock.h | 51 +++
arch/metag/include/asm/delay.h | 29 +++
arch/metag/include/asm/mach/arch.h |4 +
arch/metag/kernel/clock.c | 53
arch/metag/kernel/time.c | 163
5 files changed, 300 insertions(+), 0 deletions(-)
create mode 100644 arch/metag/include/asm/clock.h
create mode 100644 arch/metag/include/asm/delay.h
create mode 100644 arch/metag/kernel/clock.c
create mode 100644 arch/metag/kernel/time.c
diff --git a/arch/metag/include/asm/clock.h b/arch/metag/include/asm/clock.h
new file mode 100644
index 000..3e2915a
--- /dev/null
+++ b/arch/metag/include/asm/clock.h
@@ -0,0 +1,51 @@
+/*
+ * arch/metag/include/asm/clock.h
+ *
+ * Copyright (C) 2012 Imagination Technologies Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _METAG_CLOCK_H_
+#define _METAG_CLOCK_H_
+
+#include asm/mach/arch.h
+
+/**
+ * struct meta_clock_desc - Meta Core clock callbacks.
+ * @get_core_freq: Get the frequency of the Meta core. If this is NULL, the
+ * core frequency will be determined like this:
+ * Meta 1: based on loops_per_jiffy.
+ * Meta 2: (EXPAND_TIMER_DIV + 1) MHz.
+ */
+struct meta_clock_desc {
+ unsigned long (*get_core_freq)(void);
+};
+
+extern struct meta_clock_desc _meta_clock;
+
+/*
+ * Set up the default clock, ensuring all callbacks are valid - only accessible
+ * during boot.
+ */
+void setup_meta_clocks(struct meta_clock_desc *desc);
+
+/**
+ * get_coreclock() - Get the frequency of the Meta core clock.
+ *
+ * Returns:The Meta core clock frequency in Hz.
+ */
+static inline unsigned long get_coreclock(void)
+{
+ /*
+* Use the current clock callback. If set correctly this will provide
+* the most accurate frequency as it can be calculated directly from the
+* PLL configuration. otherwise a default callback will have been set
+* instead.
+*/
+ return _meta_clock.get_core_freq();
+}
+
+#endif /* _METAG_CLOCK_H_ */
diff --git a/arch/metag/include/asm/delay.h b/arch/metag/include/asm/delay.h
new file mode 100644
index 000..9c92f99
--- /dev/null
+++ b/arch/metag/include/asm/delay.h
@@ -0,0 +1,29 @@
+#ifndef _METAG_DELAY_H
+#define _METAG_DELAY_H
+
+/*
+ * Copyright (C) 1993 Linus Torvalds
+ *
+ * Delay routines calling functions in arch/metag/lib/delay.c
+ */
+
+/* Undefined functions to get compile-time errors */
+extern void __bad_udelay(void);
+extern void __bad_ndelay(void);
+
+extern void __udelay(unsigned long usecs);
+extern void __ndelay(unsigned long nsecs);
+extern void __const_udelay(unsigned long xloops);
+extern void __delay(unsigned long loops);
+
+/* 0x10c7 is 2**32 / 100 (rounded up) */
+#define udelay(n) (__builtin_constant_p(n) ? \
+ ((n) 2 ? __bad_udelay() : __const_udelay((n) * 0x10c7ul)) : \
+ __udelay(n))
+
+/* 0x5 is 2**32 / 10 (rounded up) */
+#define ndelay(n) (__builtin_constant_p(n) ? \
+ ((n) 2 ? __bad_ndelay() : __const_udelay((n) * 5ul)) : \
+ __ndelay(n))
+
+#endif /* _METAG_DELAY_H */
diff --git a/arch/metag/include/asm/mach/arch.h
b/arch/metag/include/asm/mach/arch.h
index 8429c76..230d896 100644
--- a/arch/metag/include/asm/mach/arch.h
+++ b/arch/metag/include/asm/mach/arch.h
@@ -16,10 +16,13 @@
#include linux/stddef.h
+#include asm/clock.h
+
/**
* struct machine_desc - Describes a board controlled by a Meta.
* @name: Board/SoC name.
* @dt_compat: Array of device tree 'compatible' strings.
+ * @clocks:Clock callbacks.
*
* @init_early:Early init callback.
* @init_irq: IRQ init callback for setting up IRQ controllers.
@@ -34,6 +37,7 @@
struct machine_desc {
const char *name;
const char **dt_compat;
+ struct meta_clock_desc *clocks;
void(*init_early)(void);
void(*init_irq)(void);
diff --git a/arch/metag/kernel/clock.c b/arch/metag/kernel/clock.c
new file mode 100644
index 000..defc840
--- /dev/null
+++ b/arch/metag/kernel/clock.c
@@ -0,0 +1,53 @@
+/*
+ * arch/metag/kernel/clock.c
+ *
+ * Copyright (C) 2012 Imagination Technologies Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free
[PATCH v2 20/44] metag: Device tree
Add device tree files to arch/metag.
Signed-off-by: James Hogan james.ho...@imgtec.com
---
arch/metag/boot/dtb/Makefile | 17 ++
arch/metag/boot/dts/skeleton.dts | 10
arch/metag/boot/dts/skeleton.dtsi | 14 +
arch/metag/include/asm/prom.h | 23 +
arch/metag/kernel/devtree.c | 100 +
5 files changed, 164 insertions(+), 0 deletions(-)
create mode 100644 arch/metag/boot/dtb/Makefile
create mode 100644 arch/metag/boot/dts/skeleton.dts
create mode 100644 arch/metag/boot/dts/skeleton.dtsi
create mode 100644 arch/metag/include/asm/prom.h
create mode 100644 arch/metag/kernel/devtree.c
diff --git a/arch/metag/boot/dtb/Makefile b/arch/metag/boot/dtb/Makefile
new file mode 100644
index 000..c024aec
--- /dev/null
+++ b/arch/metag/boot/dtb/Makefile
@@ -0,0 +1,17 @@
+dtb-y += skeleton.dtb
+
+# Built-in dtb
+builtindtb-y := skeleton
+
+ifneq ($(CONFIG_METAG_BUILTIN_DTB_NAME),)
+ builtindtb-y:= $(CONFIG_METAG_BUILTIN_DTB_NAME)
+endif
+obj-$(CONFIG_METAG_BUILTIN_DTB)+= $(patsubst
%,%,$(builtindtb-y)).dtb.o
+
+clean-files += $(obj)/$(dtb-y) $(obj)/*.dtb.S $(obj)/*.dtb.o
+
+# Rule to build device tree blobs
+$(obj)/%.dtb: $(src)/../dts/%.dts FORCE
+ $(call if_changed_dep,dtc)
+
+$(obj)/dtbs: $(addprefix $(obj)/, $(dtb-y))
diff --git a/arch/metag/boot/dts/skeleton.dts b/arch/metag/boot/dts/skeleton.dts
new file mode 100644
index 000..7244d1f
--- /dev/null
+++ b/arch/metag/boot/dts/skeleton.dts
@@ -0,0 +1,10 @@
+/*
+ * Copyright (C) 2012 Imagination Technologies Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ skeleton.dtsi
diff --git a/arch/metag/boot/dts/skeleton.dtsi
b/arch/metag/boot/dts/skeleton.dtsi
new file mode 100644
index 000..78229ea
--- /dev/null
+++ b/arch/metag/boot/dts/skeleton.dtsi
@@ -0,0 +1,14 @@
+/*
+ * Skeleton device tree; the bare minimum needed to boot; just include and
+ * add a compatible value. The bootloader will typically populate the memory
+ * node.
+ */
+
+/ {
+ compatible = img,meta;
+ #address-cells = 1;
+ #size-cells = 1;
+ chosen { };
+ aliases { };
+ memory { device_type = memory; reg = 0 0; };
+};
diff --git a/arch/metag/include/asm/prom.h b/arch/metag/include/asm/prom.h
new file mode 100644
index 000..d881396
--- /dev/null
+++ b/arch/metag/include/asm/prom.h
@@ -0,0 +1,23 @@
+/*
+ * arch/metag/include/asm/prom.h
+ *
+ * Copyright (C) 2012 Imagination Technologies Ltd.
+ *
+ * Based on ARM version:
+ * Copyright (C) 2009 Canonical Ltd. jeremy.k...@canonical.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#ifndef __ASM_METAG_PROM_H
+#define __ASM_METAG_PROM_H
+
+#include asm/setup.h
+#define HAVE_ARCH_DEVTREE_FIXUPS
+
+extern struct machine_desc *setup_machine_fdt(void *dt);
+extern void metag_dt_memblock_reserve(void);
+
+#endif /* __ASM_METAG_PROM_H */
diff --git a/arch/metag/kernel/devtree.c b/arch/metag/kernel/devtree.c
new file mode 100644
index 000..251819c
--- /dev/null
+++ b/arch/metag/kernel/devtree.c
@@ -0,0 +1,100 @@
+/*
+ * linux/arch/metag/kernel/devtree.c
+ *
+ * Copyright (C) 2012 Imagination Technologies Ltd.
+ *
+ * Based on ARM version:
+ * Copyright (C) 2009 Canonical Ltd. jeremy.k...@canonical.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/init.h
+#include linux/export.h
+#include linux/errno.h
+#include linux/types.h
+#include linux/bootmem.h
+#include linux/memblock.h
+#include linux/of.h
+#include linux/of_fdt.h
+#include linux/of_irq.h
+#include linux/of_platform.h
+
+#include asm/setup.h
+#include asm/page.h
+#include asm/mach/arch.h
+
+void __init early_init_dt_add_memory_arch(u64 base, u64 size)
+{
+ pr_err(%s(%llx, %llx)\n,
+ __func__, base, size);
+}
+
+void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
+{
+ return alloc_bootmem_align(size, align);
+}
+
+/**
+ * setup_machine_fdt - Machine setup when an dtb was passed to the kernel
+ * @dt:virtual address pointer to dt blob
+ *
+ * If a dtb was passed to the kernel, then use it to choose the correct
+ * machine_desc and to setup the system.
+ */
+struct machine_desc * __init setup_machine_fdt(void *dt)
+{
+ struct boot_param_header *devtree = dt;
+ struct machine_desc *mdesc, *mdesc_best = NULL;
+ unsigned int score, mdesc_score = ~1;
+ unsigned long dt_root;
+ const char *model;
+
+ /* check
[PATCH v2 39/44] metag: ftrace support
Add ftrace support for metag.
Signed-off-by: James Hogan james.ho...@imgtec.com
---
arch/metag/Kconfig |5 ++
arch/metag/include/asm/Kbuild |1 -
arch/metag/include/asm/ftrace.h | 23 +++
arch/metag/kernel/ftrace.c | 127 +++
arch/metag/kernel/ftrace_stub.S | 76 +++
arch/metag/kernel/metag_ksyms.c |5 ++
scripts/recordmcount.c | 13
7 files changed, 249 insertions(+), 1 deletions(-)
create mode 100644 arch/metag/include/asm/ftrace.h
create mode 100644 arch/metag/kernel/ftrace.c
create mode 100644 arch/metag/kernel/ftrace_stub.S
diff --git a/arch/metag/Kconfig b/arch/metag/Kconfig
index 073c324..4c731d80 100644
--- a/arch/metag/Kconfig
+++ b/arch/metag/Kconfig
@@ -11,7 +11,12 @@ config METAG
select GENERIC_SMP_IDLE_THREAD
select HAVE_64BIT_ALIGNED_STRUCT
select HAVE_ARCH_TRACEHOOK
+ select HAVE_C_RECORDMCOUNT
select HAVE_DEBUG_KMEMLEAK
+ select HAVE_DYNAMIC_FTRACE
+ select HAVE_FTRACE_MCOUNT_RECORD
+ select HAVE_FUNCTION_TRACER
+ select HAVE_FUNCTION_TRACE_MCOUNT_TEST
select HAVE_GENERIC_HARDIRQS
select HAVE_IRQ_WORK
select HAVE_KERNEL_BZIP2
diff --git a/arch/metag/include/asm/Kbuild b/arch/metag/include/asm/Kbuild
index 380a9f3..6ddcd6f 100644
--- a/arch/metag/include/asm/Kbuild
+++ b/arch/metag/include/asm/Kbuild
@@ -11,7 +11,6 @@ generic-y += errno.h
generic-y += exec.h
generic-y += fb.h
generic-y += fcntl.h
-generic-y += ftrace.h
generic-y += futex.h
generic-y += hardirq.h
generic-y += hw_irq.h
diff --git a/arch/metag/include/asm/ftrace.h b/arch/metag/include/asm/ftrace.h
new file mode 100644
index 000..2901f0f
--- /dev/null
+++ b/arch/metag/include/asm/ftrace.h
@@ -0,0 +1,23 @@
+#ifndef _ASM_METAG_FTRACE
+#define _ASM_METAG_FTRACE
+
+#ifdef CONFIG_FUNCTION_TRACER
+#define MCOUNT_INSN_SIZE 8 /* sizeof mcount call */
+
+#ifndef __ASSEMBLY__
+extern void mcount_wrapper(void);
+#define MCOUNT_ADDR((long)(mcount_wrapper))
+
+static inline unsigned long ftrace_call_adjust(unsigned long addr)
+{
+ return addr;
+}
+
+struct dyn_arch_ftrace {
+ /* No extra data needed on metag */
+};
+#endif /* __ASSEMBLY__ */
+
+#endif /* CONFIG_FUNCTION_TRACER */
+
+#endif /* _ASM_METAG_FTRACE */
diff --git a/arch/metag/kernel/ftrace.c b/arch/metag/kernel/ftrace.c
new file mode 100644
index 000..8cbeb53
--- /dev/null
+++ b/arch/metag/kernel/ftrace.c
@@ -0,0 +1,127 @@
+/*
+ * Copyright (C) 2008 Imagination Technologies Ltd.
+ * Licensed under the GPL
+ *
+ * Dynamic ftrace support.
+ */
+
+#include linux/ftrace.h
+#include linux/io.h
+#include linux/uaccess.h
+#include linux/ftrace.h
+
+#include asm/cacheflush.h
+
+#define D04_MOVT_TEMPLATE 0x0225
+#define D04_CALL_TEMPLATE 0xAC25
+#define D1RTP_MOVT_TEMPLATE0x0325
+#define D1RTP_CALL_TEMPLATE0xAC26
+
+static const unsigned long NOP[2] = {0xa0fe, 0xa0fe};
+static unsigned long movt_and_call_insn[2];
+
+static unsigned char *ftrace_nop_replace(void)
+{
+ return (char *)NOP[0];
+}
+
+static unsigned char *ftrace_call_replace(unsigned long pc, unsigned long addr)
+{
+ unsigned long hi16, low16;
+
+ hi16 = (addr 0x) 13;
+ low16 = (addr 0x) 3;
+
+ /*
+* The compiler makes the call to mcount_wrapper()
+* (Meta's wrapper around mcount()) through the register
+* D0.4. So whenever we're patching one of those compiler-generated
+* calls we also need to go through D0.4. Otherwise use D1RtP.
+*/
+ if (pc == (unsigned long)ftrace_call) {
+ writel(D1RTP_MOVT_TEMPLATE | hi16, movt_and_call_insn[0]);
+ writel(D1RTP_CALL_TEMPLATE | low16, movt_and_call_insn[1]);
+ } else {
+ writel(D04_MOVT_TEMPLATE | hi16, movt_and_call_insn[0]);
+ writel(D04_CALL_TEMPLATE | low16, movt_and_call_insn[1]);
+ }
+
+ return (unsigned char *)movt_and_call_insn[0];
+}
+
+static int ftrace_modify_code(unsigned long pc, unsigned char *old_code,
+ unsigned char *new_code)
+{
+ unsigned char replaced[MCOUNT_INSN_SIZE];
+
+ /*
+* Note: Due to modules and __init, code can
+* disappear and change, we need to protect against faulting
+* as well as code changing.
+*
+* No real locking needed, this code is run through
+* kstop_machine.
+*/
+
+ /* read the text we want to modify */
+ if (probe_kernel_read(replaced, (void *)pc, MCOUNT_INSN_SIZE))
+ return -EFAULT;
+
+ /* Make sure it is what we expect it to be */
+ if (memcmp(replaced, old_code, MCOUNT_INSN_SIZE) != 0)
+ return -EINVAL;
+
+ /* replace the text with the new text */
+ if (probe_kernel_write((void *)pc, new_code, MCOUNT_INSN_SIZE))
+
RE: [tpmdd-devel] [PATCH 1/1] TPM: STMicroelectronics ST33 I2C KERNEL 3.x.x
Hi Peter, Thanks for your contribution. I have modified the driver files name and descriptions. Regarding the warnings, it's strange. @Kent, could you confirm that you have the same? Regards, Mathias Leblanc -Original Message- From: Peter Hüwe [mailto:peterhu...@gmx.de] Sent: 29 November, 2012 01:05 To: Mathias LEBLANC Cc: Kent Yoder; Kent Yoder; Jean-Luc BLANC; linux-kernel@vger.kernel.org; Rajiv Andrade; tpmdd-de...@lists.sourceforge.net; sir...@jasper.es Subject: Re: [tpmdd-devel] [PATCH 1/1] TPM: STMicroelectronics ST33 I2C KERNEL 3.x.x Hi Mathias, please note: I'm writing this email on behalf of myself only and nobody else, especially not my employer - and I'm doing this in my spare time. I'm working for a direct competitor of yours, but I'm not using any knowledge that I've picked up at work or that is considered secret in any way. I have a personal interest in the TPM subsystem and want to keep it as clean as possible. So please don't see my review as something negative, but rather something positive. Am Mittwoch, 28. November 2012, 18:48:57 schrieb Mathias LEBLANC: Ok, so i have patch the ST33 I2C driver on this branch and correct some errors. I send you the patch for the kernel 3.x I have no error on compilation, tell me if you have problems. I have implemented the tpm_do_selftest function to get the tpm ready, but it can be removed Unfortunately you attached the patch instead of sending it in plaintext which is the usual practice - care to resend in plain text? Makes the review far easier. (btw.: Please also have a look at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;hb=HEAD http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmitChecklist;hb=HEAD http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingDrivers;hb=HEAD which describes the process in detail) When you resend the patch, can you please include the metadata as well - i.e. your modifications to the Kconfig / Makefile etc. I do not see a reason why to keep it in a seperate patch. I tried the patch you've posted and it applies cleanly and now (finally) compiles as well - so now I can start with my review: = The name = There's already one i2c tpm driver in the tree, so maybe it would be a good idea to keep the naming scheme consistent? - How about tpm_i2c_stm_st33.c ? Eventually this is something Kent as a maintainer has to decice - but I would really like to see the name change. I hope we can eventually consolidate all the 'tis' based drivers. = Compiling / License = When compiling the driver I get the following warning WARNING: modpost: missing MODULE_LICENSE() in /data/data-old/linux-2.6/drivers/char/tpm/tpm_stm_st33_i2c.o Please include the appropriate MODULE_LICENSE as my kernel otherwise gets tainted by your driver. Also this: + * STMicroelectronics TPM I2C Linux driver for TPM ST33ZP24 + * Copyright (C) 2009, 2010 STMicroelectronics + * + * 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. is not possible afaik - kernel code must be under GPL v2 _only_ without the or (at your option) any later version. addition. = sparse warnings = When running sparse against your code I get the following warnings: make -C /data/data-old/linux-2.6/ M=`pwd` modules C=1 make: Entering directory `/data/data-old/linux-2.6' CHECK /data/data-old/linux-2.6/drivers/char/tpm/tpm_stm_st33_i2c.c /data/data-old/linux-2.6/drivers/char/tpm/tpm_stm_st33_i2c.c:167:19: warning: cast removes address space of expression /data/data-old/linux-2.6/drivers/char/tpm/tpm_stm_st33_i2c.c:187:19: warning: cast removes address space of expression /data/data-old/linux-2.6/drivers/char/tpm/tpm_stm_st33_i2c.c:180:5: warning: symbol 'wait_for_serirq_timeout' was not declared. Should it be static? /data/data-old/linux-2.6/drivers/char/tpm/tpm_stm_st33_i2c.c:210:19: warning: cast removes address space of expression /data/data-old/linux-2.6/drivers/char/tpm/tpm_stm_st33_i2c.c:227:19: warning: cast removes address space of expression /data/data-old/linux-2.6/drivers/char/tpm/tpm_stm_st33_i2c.c:245:19: warning: cast removes address space of expression /data/data-old/linux-2.6/drivers/char/tpm/tpm_stm_st33_i2c.c:269:19: warning: cast removes address space of expression /data/data-old/linux-2.6/drivers/char/tpm/tpm_stm_st33_i2c.c:307:19: warning: cast removes address space of expression /data/data-old/linux-2.6/drivers/char/tpm/tpm_stm_st33_i2c.c:324:38: warning: cast removes address space of expression /data/data-old/linux-2.6/drivers/char/tpm/tpm_stm_st33_i2c.c:394:19: warning: cast removes address space of expression
[PATCH v2 34/44] metag: Various other headers
Add the remaining metag header files:
- byteorder.h, swab.h (byte order and swapping)
- barrier.h, cpu.h. hwthread.h, processor.h (hardware thread related)
- bug.h, elf.h, gpio.h, linkage.h, resource.h (other)
Signed-off-by: James Hogan james.ho...@imgtec.com
---
arch/metag/include/asm/barrier.h| 85 +
arch/metag/include/asm/bug.h| 12 ++
arch/metag/include/asm/cpu.h| 14 ++
arch/metag/include/asm/elf.h| 128 +++
arch/metag/include/asm/gpio.h |4 +
arch/metag/include/asm/hwthread.h | 40 ++
arch/metag/include/asm/linkage.h|7 +
arch/metag/include/asm/processor.h | 204 +++
arch/metag/include/uapi/asm/byteorder.h |1 +
arch/metag/include/uapi/asm/resource.h |7 +
arch/metag/include/uapi/asm/swab.h | 26
11 files changed, 528 insertions(+), 0 deletions(-)
create mode 100644 arch/metag/include/asm/barrier.h
create mode 100644 arch/metag/include/asm/bug.h
create mode 100644 arch/metag/include/asm/cpu.h
create mode 100644 arch/metag/include/asm/elf.h
create mode 100644 arch/metag/include/asm/gpio.h
create mode 100644 arch/metag/include/asm/hwthread.h
create mode 100644 arch/metag/include/asm/linkage.h
create mode 100644 arch/metag/include/asm/processor.h
create mode 100644 arch/metag/include/uapi/asm/byteorder.h
create mode 100644 arch/metag/include/uapi/asm/resource.h
create mode 100644 arch/metag/include/uapi/asm/swab.h
diff --git a/arch/metag/include/asm/barrier.h b/arch/metag/include/asm/barrier.h
new file mode 100644
index 000..8794fca
--- /dev/null
+++ b/arch/metag/include/asm/barrier.h
@@ -0,0 +1,85 @@
+#ifndef _ASM_METAG_BARRIER_H
+#define _ASM_METAG_BARRIER_H
+
+#include asm/metag_mem.h
+
+#define nop() __asm__ __volatile__ (NOP)
+#define mb() wmb()
+#define rmb() barrier()
+
+#ifdef CONFIG_METAG_META21
+
+/* HTP and above have a system event to fence writes */
+static inline void wr_fence(void)
+{
+ volatile int *flushptr = (volatile int *) LINSYSEVENT_WR_FENCE;
+ barrier();
+ *flushptr = 0;
+}
+
+#else /* CONFIG_METAG_META21 */
+
+/*
+ * ATP doesn't have system event to fence writes, so it is necessary to flush
+ * the processor write queues as well as possibly the write combiner (depending
+ * on the page being written).
+ * To ensure the write queues are flushed we do 4 writes to a system event
+ * register (in this case write combiner flush) which will also flush the write
+ * combiner.
+ */
+static inline void wr_fence(void)
+{
+ volatile int *flushptr = (volatile int *) LINSYSEVENT_WR_COMBINE_FLUSH;
+ barrier();
+ *flushptr = 0;
+ *flushptr = 0;
+ *flushptr = 0;
+ *flushptr = 0;
+}
+
+#endif /* !CONFIG_METAG_META21 */
+
+static inline void wmb(void)
+{
+ /* flush writes through the write combiner */
+ wr_fence();
+}
+
+#define read_barrier_depends() do { } while (0)
+
+#ifndef CONFIG_SMP
+#define fence()do { } while (0)
+#define smp_mb()barrier()
+#define smp_rmb() barrier()
+#define smp_wmb() barrier()
+#else
+
+#ifdef CONFIG_METAG_SMP_WRITE_REORDERING
+/*
+ * Write to the atomic memory unlock system event register (command 0). This is
+ * needed before a write to shared memory in a critical section, to prevent
+ * external reordering of writes before the fence on other threads with writes
+ * after the fence on this thread (and to prevent the ensuing cache-memory
+ * incoherence). It is therefore ineffective if used after and on the same
+ * thread as a write.
+ */
+static inline void fence(void)
+{
+ volatile int *flushptr = (volatile int *) LINSYSEVENT_WR_ATOMIC_UNLOCK;
+ barrier();
+ *flushptr = 0;
+}
+#define smp_mb()fence()
+#define smp_rmb() fence()
+#define smp_wmb() barrier()
+#else
+#define fence()do { } while (0)
+#define smp_mb()barrier()
+#define smp_rmb() barrier()
+#define smp_wmb() barrier()
+#endif
+#endif
+#define smp_read_barrier_depends() do { } while (0)
+#define set_mb(var, value) do { var = value; smp_mb(); } while (0)
+
+#endif /* _ASM_METAG_BARRIER_H */
diff --git a/arch/metag/include/asm/bug.h b/arch/metag/include/asm/bug.h
new file mode 100644
index 000..d04b48c
--- /dev/null
+++ b/arch/metag/include/asm/bug.h
@@ -0,0 +1,12 @@
+#ifndef _ASM_METAG_BUG_H
+#define _ASM_METAG_BUG_H
+
+#include asm-generic/bug.h
+
+struct pt_regs;
+
+extern const char *trap_name(int trapno);
+extern void die(const char *str, struct pt_regs *regs, long err,
+ unsigned long addr) __attribute__ ((noreturn));
+
+#endif
diff --git a/arch/metag/include/asm/cpu.h b/arch/metag/include/asm/cpu.h
new file mode 100644
index 000..decf129
--- /dev/null
+++ b/arch/metag/include/asm/cpu.h
@@ -0,0 +1,14 @@
+#ifndef _ASM_METAG_CPU_H
+#define _ASM_METAG_CPU_H
+
+#include linux/percpu.h
+
[PATCH v2 33/44] metag: Stack unwinding
Add stack unwinding support for metag.
Signed-off-by: James Hogan james.ho...@imgtec.com
---
arch/metag/include/asm/stacktrace.h | 20
arch/metag/kernel/stacktrace.c | 187 +++
2 files changed, 207 insertions(+), 0 deletions(-)
create mode 100644 arch/metag/include/asm/stacktrace.h
create mode 100644 arch/metag/kernel/stacktrace.c
diff --git a/arch/metag/include/asm/stacktrace.h
b/arch/metag/include/asm/stacktrace.h
new file mode 100644
index 000..2830a0f
--- /dev/null
+++ b/arch/metag/include/asm/stacktrace.h
@@ -0,0 +1,20 @@
+#ifndef __ASM_STACKTRACE_H
+#define __ASM_STACKTRACE_H
+
+struct stackframe {
+ unsigned long fp;
+ unsigned long sp;
+ unsigned long lr;
+ unsigned long pc;
+};
+
+struct metag_frame {
+ unsigned long fp;
+ unsigned long lr;
+};
+
+extern int unwind_frame(struct stackframe *frame);
+extern void walk_stackframe(struct stackframe *frame,
+ int (*fn)(struct stackframe *, void *), void *data);
+
+#endif /* __ASM_STACKTRACE_H */
diff --git a/arch/metag/kernel/stacktrace.c b/arch/metag/kernel/stacktrace.c
new file mode 100644
index 000..5510361
--- /dev/null
+++ b/arch/metag/kernel/stacktrace.c
@@ -0,0 +1,187 @@
+#include linux/export.h
+#include linux/sched.h
+#include linux/stacktrace.h
+
+#include asm/stacktrace.h
+
+#if defined(CONFIG_FRAME_POINTER)
+
+#ifdef CONFIG_KALLSYMS
+#include linux/kallsyms.h
+#include linux/module.h
+
+static unsigned long tbi_boing_addr;
+static unsigned long tbi_boing_size;
+
+static void tbi_boing_init(void)
+{
+ /* We need to know where TBIBoingVec is and it's size */
+ unsigned long size;
+ unsigned long offset;
+ char modname[MODULE_NAME_LEN];
+ char name[KSYM_NAME_LEN];
+ tbi_boing_addr = kallsyms_lookup_name(___TBIBoingVec);
+ if (!tbi_boing_addr)
+ tbi_boing_addr = 1;
+ else if (!lookup_symbol_attrs(tbi_boing_addr, size,
+ offset, modname, name))
+ tbi_boing_size = size;
+}
+#endif
+
+#define ALIGN_DOWN(addr, size) ((addr)(~((size)-1)))
+
+/*
+ * Unwind the current stack frame and store the new register values in the
+ * structure passed as argument. Unwinding is equivalent to a function return,
+ * hence the new PC value rather than LR should be used for backtrace.
+ */
+int notrace unwind_frame(struct stackframe *frame)
+{
+ struct metag_frame *fp = (struct metag_frame *)frame-fp;
+ unsigned long lr;
+ unsigned long fpnew;
+
+ if (frame-fp 0x7)
+ return -EINVAL;
+
+ fpnew = fp-fp;
+ lr = fp-lr - 4;
+
+#ifdef CONFIG_KALLSYMS
+ /* If we've reached TBIBoingVec then we're at an interrupt
+* entry point or a syscall entry point. The frame pointer
+* points to a pt_regs which can be used to continue tracing on
+* the other side of the boing.
+*/
+ if (!tbi_boing_addr)
+ tbi_boing_init();
+ if (tbi_boing_size lr = tbi_boing_addr
+ lr tbi_boing_addr + tbi_boing_size) {
+ struct pt_regs *regs = (struct pt_regs *)fpnew;
+ if (user_mode(regs))
+ return -EINVAL;
+ fpnew = regs-ctx.AX[1].U0;
+ lr = regs-ctx.DX[4].U1;
+ }
+#endif
+
+ /* stack grows up, so frame pointers must decrease */
+ if (fpnew (ALIGN_DOWN((unsigned long)fp, THREAD_SIZE) +
+sizeof(struct thread_info)) || fpnew = (unsigned long)fp)
+ return -EINVAL;
+
+ /* restore the registers from the stack frame */
+ frame-fp = fpnew;
+ frame-pc = lr;
+
+ return 0;
+}
+#else
+int notrace unwind_frame(struct stackframe *frame)
+{
+ struct metag_frame *sp = (struct metag_frame *)frame-sp;
+
+ if (frame-sp 0x7)
+ return -EINVAL;
+
+ while (!kstack_end(sp)) {
+ unsigned long addr = sp-lr - 4;
+ sp--;
+
+ if (__kernel_text_address(addr)) {
+ frame-sp = (unsigned long)sp;
+ frame-pc = addr;
+ return 0;
+ }
+ }
+ return -EINVAL;
+}
+#endif
+
+void notrace walk_stackframe(struct stackframe *frame,
+int (*fn)(struct stackframe *, void *), void *data)
+{
+ while (1) {
+ int ret;
+
+ if (fn(frame, data))
+ break;
+ ret = unwind_frame(frame);
+ if (ret 0)
+ break;
+ }
+}
+EXPORT_SYMBOL(walk_stackframe);
+
+#ifdef CONFIG_STACKTRACE
+struct stack_trace_data {
+ struct stack_trace *trace;
+ unsigned int no_sched_functions;
+ unsigned int skip;
+};
+
+static int save_trace(struct stackframe *frame, void *d)
+{
+ struct stack_trace_data *data = d;
+ struct stack_trace *trace = data-trace;
[PATCH v2 31/44] metag: DMA
Add DMA mapping code.
Signed-off-by: James Hogan james.ho...@imgtec.com
---
arch/metag/include/asm/dma-mapping.h | 183
arch/metag/kernel/dma.c | 507 ++
2 files changed, 690 insertions(+), 0 deletions(-)
create mode 100644 arch/metag/include/asm/dma-mapping.h
create mode 100644 arch/metag/kernel/dma.c
diff --git a/arch/metag/include/asm/dma-mapping.h
b/arch/metag/include/asm/dma-mapping.h
new file mode 100644
index 000..b5f80a6
--- /dev/null
+++ b/arch/metag/include/asm/dma-mapping.h
@@ -0,0 +1,183 @@
+#ifndef _ASM_METAG_DMA_MAPPING_H
+#define _ASM_METAG_DMA_MAPPING_H
+
+#include linux/mm.h
+
+#include asm/cache.h
+#include asm/io.h
+#include linux/scatterlist.h
+#include asm/bug.h
+
+#define dma_alloc_noncoherent(d, s, h, f) dma_alloc_coherent(d, s, h, f)
+#define dma_free_noncoherent(d, s, v, h) dma_free_coherent(d, s, v, h)
+
+void *dma_alloc_coherent(struct device *dev, size_t size,
+dma_addr_t *dma_handle, gfp_t flag);
+
+void dma_free_coherent(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t dma_handle);
+
+void dma_sync_for_device(void *vaddr, size_t size, int dma_direction);
+void dma_sync_for_cpu(void *vaddr, size_t size, int dma_direction);
+
+int dma_mmap_coherent(struct device *dev, struct vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size);
+
+int dma_mmap_writecombine(struct device *dev, struct vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size);
+
+static inline dma_addr_t
+dma_map_single(struct device *dev, void *ptr, size_t size,
+ enum dma_data_direction direction)
+{
+ BUG_ON(!valid_dma_direction(direction));
+ WARN_ON(size == 0);
+ dma_sync_for_device(ptr, size, direction);
+ return virt_to_phys(ptr);
+}
+
+static inline void
+dma_unmap_single(struct device *dev, dma_addr_t dma_addr, size_t size,
+enum dma_data_direction direction)
+{
+ BUG_ON(!valid_dma_direction(direction));
+ dma_sync_for_cpu(phys_to_virt(dma_addr), size, direction);
+}
+
+static inline int
+dma_map_sg(struct device *dev, struct scatterlist *sglist, int nents,
+ enum dma_data_direction direction)
+{
+ struct scatterlist *sg;
+ int i;
+
+ BUG_ON(!valid_dma_direction(direction));
+ WARN_ON(nents == 0 || sglist[0].length == 0);
+
+ for_each_sg(sglist, sg, nents, i) {
+ BUG_ON(!sg_page(sg));
+
+ sg-dma_address = sg_phys(sg);
+ dma_sync_for_device(sg_virt(sg), sg-length, direction);
+ }
+
+ return nents;
+}
+
+static inline dma_addr_t
+dma_map_page(struct device *dev, struct page *page, unsigned long offset,
+size_t size, enum dma_data_direction direction)
+{
+ BUG_ON(!valid_dma_direction(direction));
+ dma_sync_for_device((void *)(page_to_phys(page) + offset), size,
+ direction);
+ return page_to_phys(page) + offset;
+}
+
+static inline void
+dma_unmap_page(struct device *dev, dma_addr_t dma_address, size_t size,
+ enum dma_data_direction direction)
+{
+ BUG_ON(!valid_dma_direction(direction));
+ dma_sync_for_cpu(phys_to_virt(dma_address), size, direction);
+}
+
+
+static inline void
+dma_unmap_sg(struct device *dev, struct scatterlist *sglist, int nhwentries,
+enum dma_data_direction direction)
+{
+ struct scatterlist *sg;
+ int i;
+
+ BUG_ON(!valid_dma_direction(direction));
+ WARN_ON(nhwentries == 0 || sglist[0].length == 0);
+
+ for_each_sg(sglist, sg, nhwentries, i) {
+ BUG_ON(!sg_page(sg));
+
+ sg-dma_address = sg_phys(sg);
+ dma_sync_for_cpu(sg_virt(sg), sg-length, direction);
+ }
+}
+
+static inline void
+dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle, size_t size,
+ enum dma_data_direction direction)
+{
+ dma_sync_for_cpu(phys_to_virt(dma_handle), size, direction);
+}
+
+static inline void
+dma_sync_single_for_device(struct device *dev, dma_addr_t dma_handle,
+ size_t size, enum dma_data_direction direction)
+{
+ dma_sync_for_device(phys_to_virt(dma_handle), size, direction);
+}
+
+static inline void
+dma_sync_single_range_for_cpu(struct device *dev, dma_addr_t dma_handle,
+ unsigned long offset, size_t size,
+ enum dma_data_direction direction)
+{
+ dma_sync_for_cpu(phys_to_virt(dma_handle)+offset, size,
+direction);
+}
+
+static inline void
+dma_sync_single_range_for_device(struct device *dev, dma_addr_t dma_handle,
+unsigned long offset, size_t size,
+enum dma_data_direction direction)
+{
+ dma_sync_for_device(phys_to_virt(dma_handle)+offset, size,
[PATCH v2 30/44] metag: SMP support
Add SMP support for metag. This allows Linux to take control of multiple
hardware threads on a single Meta core, treating them as separate Linux
CPUs.
Signed-off-by: James Hogan james.ho...@imgtec.com
---
arch/metag/include/asm/cachepart.h | 42 +++
arch/metag/include/asm/core_reg.h |7 +
arch/metag/include/asm/smp.h | 31 ++
arch/metag/include/asm/topology.h | 53
arch/metag/kernel/cachepart.c | 124
arch/metag/kernel/core_reg.c | 117 +++
arch/metag/kernel/head.S | 12 +
arch/metag/kernel/smp.c| 582
arch/metag/kernel/topology.c | 77 +
9 files changed, 1045 insertions(+), 0 deletions(-)
create mode 100644 arch/metag/include/asm/cachepart.h
create mode 100644 arch/metag/include/asm/core_reg.h
create mode 100644 arch/metag/include/asm/smp.h
create mode 100644 arch/metag/include/asm/topology.h
create mode 100644 arch/metag/kernel/cachepart.c
create mode 100644 arch/metag/kernel/core_reg.c
create mode 100644 arch/metag/kernel/smp.c
create mode 100644 arch/metag/kernel/topology.c
diff --git a/arch/metag/include/asm/cachepart.h
b/arch/metag/include/asm/cachepart.h
new file mode 100644
index 000..cf6b44e
--- /dev/null
+++ b/arch/metag/include/asm/cachepart.h
@@ -0,0 +1,42 @@
+/*
+ * Meta cache partition manipulation.
+ *
+ * Copyright 2010 Imagination Technologies Ltd.
+ */
+
+#ifndef _METAG_CACHEPART_H_
+#define _METAG_CACHEPART_H_
+
+/**
+ * get_dcache_size() - Get size of data cache.
+ */
+unsigned int get_dcache_size(void);
+
+/**
+ * get_icache_size() - Get size of code cache.
+ */
+unsigned int get_icache_size(void);
+
+/**
+ * get_global_dcache_size() - Get the thread's global dcache.
+ *
+ * Returns the size of the current thread's global dcache partition.
+ */
+unsigned int get_global_dcache_size(void);
+
+/**
+ * get_global_icache_size() - Get the thread's global icache.
+ *
+ * Returns the size of the current thread's global icache partition.
+ */
+unsigned int get_global_icache_size(void);
+
+/**
+ * check_for_dache_aliasing() - Ensure that the bootloader has configured the
+ * dache and icache properly to avoid aliasing
+ * @thread_id: Hardware thread ID
+ *
+ */
+void check_for_cache_aliasing(int thread_id);
+
+#endif
diff --git a/arch/metag/include/asm/core_reg.h
b/arch/metag/include/asm/core_reg.h
new file mode 100644
index 000..62a4a3a
--- /dev/null
+++ b/arch/metag/include/asm/core_reg.h
@@ -0,0 +1,7 @@
+#ifndef __ASM_METAG_CORE_REG_H_
+#define __ASM_METAG_CORE_REG_H_
+
+extern void core_reg_write(int unit, int reg, int thread, unsigned int val);
+extern unsigned int core_reg_read(int unit, int reg, int thread);
+
+#endif
diff --git a/arch/metag/include/asm/smp.h b/arch/metag/include/asm/smp.h
new file mode 100644
index 000..b35fa84
--- /dev/null
+++ b/arch/metag/include/asm/smp.h
@@ -0,0 +1,31 @@
+#ifndef __ASM_SMP_H
+#define __ASM_SMP_H
+
+#include linux/cpumask.h
+
+#define raw_smp_processor_id() (current_thread_info()-cpu)
+
+extern void local_timer_setup(unsigned int cpu);
+
+enum ipi_msg_type {
+ IPI_CALL_FUNC,
+ IPI_CALL_FUNC_SINGLE,
+ IPI_RESCHEDULE,
+};
+
+extern void arch_send_call_function_single_ipi(int cpu);
+extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);
+#define arch_send_call_function_ipi_mask arch_send_call_function_ipi_mask
+
+asmlinkage void secondary_start_kernel(void);
+
+extern void secondary_startup(void);
+
+#ifdef CONFIG_HOTPLUG_CPU
+extern void __cpu_die(unsigned int cpu);
+extern int __cpu_disable(void);
+extern void cpu_die(void);
+#endif
+
+extern void smp_init_cpus(void);
+#endif /* __ASM_SMP_H */
diff --git a/arch/metag/include/asm/topology.h
b/arch/metag/include/asm/topology.h
new file mode 100644
index 000..23f5118
--- /dev/null
+++ b/arch/metag/include/asm/topology.h
@@ -0,0 +1,53 @@
+#ifndef _ASM_METAG_TOPOLOGY_H
+#define _ASM_METAG_TOPOLOGY_H
+
+#ifdef CONFIG_NUMA
+
+/* sched_domains SD_NODE_INIT for Meta machines */
+#define SD_NODE_INIT (struct sched_domain) { \
+ .parent = NULL, \
+ .child = NULL, \
+ .groups = NULL, \
+ .min_interval = 8,\
+ .max_interval = 32, \
+ .busy_factor= 32, \
+ .imbalance_pct = 125, \
+ .cache_nice_tries = 2,\
+ .busy_idx = 3,\
+ .idle_idx = 2,\
+ .newidle_idx= 0,\
+ .wake_idx = 0,\
+ .forkexec_idx = 0,\
+ .flags = SD_LOAD_BALANCE \
+ | SD_BALANCE_FORK \
+ |
[PATCH v2 29/44] metag: Basic documentation
Add basic metag documentation. Signed-off-by: James Hogan james.ho...@imgtec.com --- Documentation/00-INDEX |2 ++ Documentation/kernel-parameters.txt |4 Documentation/metag/00-INDEX|2 ++ 3 files changed, 8 insertions(+), 0 deletions(-) create mode 100644 Documentation/metag/00-INDEX diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index ceb1ff7..d06f731 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -228,6 +228,8 @@ memory-hotplug.txt - Hotpluggable memory support, how to use and current status. memory.txt - info on typical Linux memory problems. +metag/ + - directory with info about Linux on Meta architecture. mips/ - directory with info about Linux on MIPS architecture. mmc/ diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 9776f06..20c93ba 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -958,6 +958,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. If specified, z/VM IUCV HVC accepts connections from listed z/VM user IDs only. + hwthread_map= [METAG] Comma-separated list of Linux cpu id to + hardware thread id mappings. + Format: cpu:hwthread + keep_bootcon[KNL] Do not unregister boot console at start. This is only useful for debugging when something happens in the window diff --git a/Documentation/metag/00-INDEX b/Documentation/metag/00-INDEX new file mode 100644 index 000..808f5d4 --- /dev/null +++ b/Documentation/metag/00-INDEX @@ -0,0 +1,2 @@ +00-INDEX + - this file -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v7 2/3] aerdrv: Enhanced AER logging
+ char *prefix = NULL;
What are you doing here? You dropped the 'prefix' argument being passed
down in this function and are defining a local variable of the same
name
which is used in the function later:
printk(%saer_status: 0x%08x, aer_mask: 0x%08x\n,
prefix, status, mask);
Boris,
I removed the prefix argument because it was never used by its caller and never
set. The reason I added the prefix variable and set it to NULL was to help in
breaking up the patch and adding it would help the intermittent patch build
without changing too much code. I knew I was actually going to use the
variable in patch 3.
Lance
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH v2 28/44] metag: Atomics, locks and bitops
Add header files to implement Meta hardware thread locks (used by some
other atomic operations), atomics, spinlocks, and bitops.
There are 2 main types of atomic primitives for metag (in addition to
IRQs off on UP):
- LOCK instructions provide locking between hardware threads.
- LNKGET/LNKSET instructions provide load-linked/store-conditional
operations allowing for lighter weight atomics on Meta2)
LOCK instructions allow for hardware threads to acquire voluntary or
exclusive hardware thread locks:
- LOCK0 releases exclusive and voluntary lock from the running hardware
thread.
- LOCK1 acquires the voluntary hardware lock, blocking until it becomes
available.
- LOCK2 implies LOCK1, and additionally acquires the exclusive hardware
lock, blocking all other hardware threads from executing.
Signed-off-by: James Hogan james.ho...@imgtec.com
---
arch/metag/include/asm/atomic.h | 53 ++
arch/metag/include/asm/atomic_lnkget.h | 245
arch/metag/include/asm/atomic_lock1.h| 160 ++
arch/metag/include/asm/bitops.h | 132 +++
arch/metag/include/asm/cmpxchg.h | 65
arch/metag/include/asm/cmpxchg_irq.h | 42 +
arch/metag/include/asm/cmpxchg_lnkget.h | 86 ++
arch/metag/include/asm/cmpxchg_lock1.h | 48 ++
arch/metag/include/asm/lock.h| 14 ++
arch/metag/include/asm/spinlock.h| 22 +++
arch/metag/include/asm/spinlock_lnkget.h | 261 ++
arch/metag/include/asm/spinlock_lock1.h | 184 +
arch/metag/include/asm/spinlock_types.h | 20 +++
13 files changed, 1332 insertions(+), 0 deletions(-)
create mode 100644 arch/metag/include/asm/atomic.h
create mode 100644 arch/metag/include/asm/atomic_lnkget.h
create mode 100644 arch/metag/include/asm/atomic_lock1.h
create mode 100644 arch/metag/include/asm/bitops.h
create mode 100644 arch/metag/include/asm/cmpxchg.h
create mode 100644 arch/metag/include/asm/cmpxchg_irq.h
create mode 100644 arch/metag/include/asm/cmpxchg_lnkget.h
create mode 100644 arch/metag/include/asm/cmpxchg_lock1.h
create mode 100644 arch/metag/include/asm/lock.h
create mode 100644 arch/metag/include/asm/spinlock.h
create mode 100644 arch/metag/include/asm/spinlock_lnkget.h
create mode 100644 arch/metag/include/asm/spinlock_lock1.h
create mode 100644 arch/metag/include/asm/spinlock_types.h
diff --git a/arch/metag/include/asm/atomic.h b/arch/metag/include/asm/atomic.h
new file mode 100644
index 000..307ecd2
--- /dev/null
+++ b/arch/metag/include/asm/atomic.h
@@ -0,0 +1,53 @@
+#ifndef __ASM_METAG_ATOMIC_H
+#define __ASM_METAG_ATOMIC_H
+
+#include linux/compiler.h
+#include linux/types.h
+#include asm/cmpxchg.h
+
+#if defined(CONFIG_METAG_ATOMICITY_IRQSOFF)
+/* The simple UP case. */
+#include asm-generic/atomic.h
+#else
+
+#if defined(CONFIG_METAG_ATOMICITY_LOCK1)
+#include asm/atomic_lock1.h
+#else
+#include asm/atomic_lnkget.h
+#endif
+
+#define atomic_add_negative(a, v) (atomic_add_return((a), (v)) 0)
+
+#define atomic_dec_return(v) atomic_sub_return(1, (v))
+#define atomic_inc_return(v) atomic_add_return(1, (v))
+
+/*
+ * atomic_inc_and_test - increment and test
+ * @v: pointer of type atomic_t
+ *
+ * Atomically increments @v by 1
+ * and returns true if the result is zero, or false for all
+ * other cases.
+ */
+#define atomic_inc_and_test(v) (atomic_inc_return(v) == 0)
+
+#define atomic_sub_and_test(i, v) (atomic_sub_return((i), (v)) == 0)
+#define atomic_dec_and_test(v) (atomic_sub_return(1, (v)) == 0)
+
+#define atomic_inc(v) atomic_add(1, (v))
+#define atomic_dec(v) atomic_sub(1, (v))
+
+#define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0)
+
+#define smp_mb__before_atomic_dec()barrier()
+#define smp_mb__after_atomic_dec() barrier()
+#define smp_mb__before_atomic_inc()barrier()
+#define smp_mb__after_atomic_inc() barrier()
+
+#endif
+
+#define atomic_dec_if_positive(v) atomic_sub_if_positive(1, v)
+
+#include asm-generic/atomic64.h
+
+#endif /* __ASM_METAG_ATOMIC_H */
diff --git a/arch/metag/include/asm/atomic_lnkget.h
b/arch/metag/include/asm/atomic_lnkget.h
new file mode 100644
index 000..b05be05
--- /dev/null
+++ b/arch/metag/include/asm/atomic_lnkget.h
@@ -0,0 +1,245 @@
+#ifndef __ASM_METAG_ATOMIC_LNKGET_H
+#define __ASM_METAG_ATOMIC_LNKGET_H
+
+#define ATOMIC_INIT(i) { (i) }
+
+#define atomic_set(v, i) ((v)-counter = (i))
+
+#include linux/compiler.h
+
+#include asm/barrier.h
+
+/*
+ * None of these asm statements clobber memory as LNKSET writes around
+ * the cache so the memory it modifies cannot safely be read by any means
+ * other than these accessors.
+ */
+
+static inline int atomic_read(const atomic_t *v)
+{
+ int temp;
+
+ __asm__ __volatile__(
+ LNKGETD %0, [%1]\n
+ : =da (temp)
+ : da (v-counter)
+ );
+
+ return temp;
+}
+
Re: [PATCH RESEND] tty: don't dead lock while flushing workqueue
On 12/03/2012 06:41 PM, Peter Hurley wrote: The lock logic for tty_set_ldisc() is wrong. Despite existing code in tty_set_ldisc() and tty_ldisc_hangup(), the ldisc_mutex does **not** (and should not) play a role in acquiring or releasing ldisc references. The only thing that needs to happen here is below (don't actually use below because I just hand-edited it): Hmm. What about I stay in sync with the code that is already in tree and if the wrong locking gets removed in both places later on? Alan, what do you prefer? See http://lkml.org/lkml/2012/11/21/347 drivers/tty/tty_ldisc.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c index 0f2a2c5..fb76818 100644 --- a/drivers/tty/tty_ldisc.c +++ b/drivers/tty/tty_ldisc.c @@ -930,16 +930,21 @@ void tty_ldisc_release(struct tty_struct *tty, struct tty_struct *o_tty) */ - tty_lock_pair(tty, o_tty); tty_ldisc_halt(tty); tty_ldisc_flush_works(tty); + tty_lock_pair(tty, o_tty); /* This will need doing differently if we need to lock */ tty_ldisc_kill(tty); - if (o_tty) tty_ldisc_kill(o_tty); Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 26/44] metag: Scheduling/Process management
Signed-off-by: James Hogan james.ho...@imgtec.com
---
arch/metag/include/asm/thread_info.h | 155
arch/metag/kernel/process.c | 453 ++
2 files changed, 608 insertions(+), 0 deletions(-)
create mode 100644 arch/metag/include/asm/thread_info.h
create mode 100644 arch/metag/kernel/process.c
diff --git a/arch/metag/include/asm/thread_info.h
b/arch/metag/include/asm/thread_info.h
new file mode 100644
index 000..0ecd34d
--- /dev/null
+++ b/arch/metag/include/asm/thread_info.h
@@ -0,0 +1,155 @@
+/* thread_info.h: Meta low-level thread information
+ *
+ * Copyright (C) 2002 David Howells (dhowe...@redhat.com)
+ * - Incorporating suggestions made by Linus Torvalds and Dave Miller
+ *
+ * Meta port by Imagination Technologies
+ */
+
+#ifndef _ASM_THREAD_INFO_H
+#define _ASM_THREAD_INFO_H
+
+#include linux/compiler.h
+#include asm/page.h
+
+#ifndef __ASSEMBLY__
+#include asm/processor.h
+#endif
+
+/*
+ * low level task data that entry.S needs immediate access to
+ * - this struct should fit entirely inside of one cache line
+ * - this struct shares the supervisor stack pages
+ * - if the contents of this structure are changed, the assembly constants must
+ * also be changed
+ */
+#ifndef __ASSEMBLY__
+
+/* This must be 8 byte aligned so we can ensure stack alignment. */
+struct thread_info {
+ struct task_struct *task; /* main task structure */
+ struct exec_domain *exec_domain;/* execution domain */
+ unsigned long flags;/* low level flags */
+ unsigned long status; /* thread-synchronous flags */
+ u32 cpu;/* current CPU */
+ int preempt_count; /* 0 = preemptable, 0 = BUG */
+
+ mm_segment_t addr_limit;/* thread address space */
+ struct restart_block restart_block;
+
+ u8 supervisor_stack[0];
+};
+
+#else /* !__ASSEMBLY__ */
+
+#include generated/asm-offsets.h
+
+#endif
+
+#define PREEMPT_ACTIVE 0x1000
+
+#ifdef CONFIG_4KSTACKS
+#define THREAD_SHIFT 12
+#else
+#define THREAD_SHIFT 13
+#endif
+
+#if THREAD_SHIFT = PAGE_SHIFT
+#define THREAD_SIZE_ORDER (THREAD_SHIFT - PAGE_SHIFT)
+#else
+#define THREAD_SIZE_ORDER 0
+#endif
+
+#define THREAD_SIZE(PAGE_SIZE THREAD_SIZE_ORDER)
+
+#define STACK_WARN (THREAD_SIZE/8)
+/*
+ * macros/functions for gaining access to the thread information structure
+ */
+#ifndef __ASSEMBLY__
+
+#define INIT_THREAD_INFO(tsk) \
+{ \
+ .task = tsk, \
+ .exec_domain= default_exec_domain, \
+ .flags = 0,\
+ .cpu= 0,\
+ .preempt_count = INIT_PREEMPT_COUNT, \
+ .addr_limit = KERNEL_DS,\
+ .restart_block = { \
+ .fn = do_no_restart_syscall,\
+ }, \
+}
+
+#define init_thread_info (init_thread_union.thread_info)
+#define init_stack (init_thread_union.stack)
+
+/* how to get the current stack pointer from C */
+register unsigned long current_stack_pointer asm(A0StP) __used;
+
+/* how to get the thread information struct from C */
+static inline struct thread_info *current_thread_info(void)
+{
+ return (struct thread_info *)(current_stack_pointer
+ ~(THREAD_SIZE - 1));
+}
+
+#define __HAVE_ARCH_KSTACK_END
+static inline int kstack_end(void *addr)
+{
+ return addr == (void *) (((unsigned long) addr ~(THREAD_SIZE - 1))
++ sizeof(struct thread_info));
+}
+
+#endif
+
+/*
+ * thread information flags
+ * - these are process state flags that various assembly files may need to
+ * access
+ * - pending work-to-be-done flags are in LSW
+ * - other flags in MSW
+ */
+#define TIF_SYSCALL_TRACE 0 /* syscall trace active */
+#define TIF_SIGPENDING 1 /* signal pending */
+#define TIF_NEED_RESCHED 2 /* rescheduling necessary */
+#define TIF_SINGLESTEP 3 /* restore singlestep on return to user
+ mode */
+#define TIF_SYSCALL_AUDIT 4 /* syscall auditing active */
+#define TIF_SECCOMP5 /* secure computing */
+#define TIF_RESTORE_SIGMASK6 /* restore signal mask in do_signal() */
+#define TIF_NOTIFY_RESUME 7 /* callback before returning to user */
+#define TIF_POLLING_NRFLAG 8 /* true if poll_idle() is polling
+ TIF_NEED_RESCHED */
+#define TIF_MEMDIE 9 /* is terminating due to OOM killer */
+#define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint instrumentation */
+
+
+#define _TIF_SYSCALL_TRACE (1TIF_SYSCALL_TRACE)
+#define _TIF_SIGPENDING(1TIF_SIGPENDING)
+#define
[PATCH v2 27/44] metag: Module support
Signed-off-by: James Hogan james.ho...@imgtec.com
---
arch/metag/include/asm/module.h | 37 +
arch/metag/kernel/module.c | 284 +++
2 files changed, 321 insertions(+), 0 deletions(-)
create mode 100644 arch/metag/include/asm/module.h
create mode 100644 arch/metag/kernel/module.c
diff --git a/arch/metag/include/asm/module.h b/arch/metag/include/asm/module.h
new file mode 100644
index 000..e47e609
--- /dev/null
+++ b/arch/metag/include/asm/module.h
@@ -0,0 +1,37 @@
+#ifndef _ASM_METAG_MODULE_H
+#define _ASM_METAG_MODULE_H
+
+#include asm-generic/module.h
+
+struct metag_plt_entry {
+ /* Indirect jump instruction sequence. */
+ unsigned long tramp[2];
+};
+
+struct mod_arch_specific {
+ /* Indices of PLT sections within module. */
+ unsigned int core_plt_section, init_plt_section;
+};
+
+#if defined CONFIG_METAG_META12
+#define MODULE_PROC_FAMILY META 1.2
+#elif defined CONFIG_METAG_META21
+#define MODULE_PROC_FAMILY META 2.1
+#else
+#define MODULE_PROC_FAMILY
+#endif
+
+#ifdef CONFIG_4KSTACKS
+#define MODULE_STACKSIZE 4KSTACKS
+#else
+#define MODULE_STACKSIZE
+#endif
+
+#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY MODULE_STACKSIZE
+
+#ifdef MODULE
+asm(.section .plt,\ax\,@progbits; .balign 8; .previous);
+asm(.section .init.plt,\ax\,@progbits; .balign 8; .previous);
+#endif
+
+#endif /* _ASM_METAG_MODULE_H */
diff --git a/arch/metag/kernel/module.c b/arch/metag/kernel/module.c
new file mode 100644
index 000..986331c
--- /dev/null
+++ b/arch/metag/kernel/module.c
@@ -0,0 +1,284 @@
+/* Kernel module help for Meta.
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+*/
+#include linux/moduleloader.h
+#include linux/elf.h
+#include linux/vmalloc.h
+#include linux/fs.h
+#include linux/string.h
+#include linux/kernel.h
+#include linux/sort.h
+
+#include asm/unaligned.h
+
+/* Count how many different relocations (different symbol, different
+ addend) */
+static unsigned int count_relocs(const Elf32_Rela *rela, unsigned int num)
+{
+ unsigned int i, r_info, r_addend, _count_relocs;
+
+ _count_relocs = 0;
+ r_info = 0;
+ r_addend = 0;
+ for (i = 0; i num; i++)
+ /* Only count relbranch relocs, others don't need stubs */
+ if (ELF32_R_TYPE(rela[i].r_info) == R_METAG_RELBRANCH
+ (r_info != ELF32_R_SYM(rela[i].r_info) ||
+r_addend != rela[i].r_addend)) {
+ _count_relocs++;
+ r_info = ELF32_R_SYM(rela[i].r_info);
+ r_addend = rela[i].r_addend;
+ }
+
+ return _count_relocs;
+}
+
+static int relacmp(const void *_x, const void *_y)
+{
+ const Elf32_Rela *x, *y;
+
+ y = (Elf32_Rela *)_x;
+ x = (Elf32_Rela *)_y;
+
+ /* Compare the entire r_info (as opposed to ELF32_R_SYM(r_info) only) to
+* make the comparison cheaper/faster. It won't affect the sorting or
+* the counting algorithms' performance
+*/
+ if (x-r_info y-r_info)
+ return -1;
+ else if (x-r_info y-r_info)
+ return 1;
+ else if (x-r_addend y-r_addend)
+ return -1;
+ else if (x-r_addend y-r_addend)
+ return 1;
+ else
+ return 0;
+}
+
+static void relaswap(void *_x, void *_y, int size)
+{
+ uint32_t *x, *y, tmp;
+ int i;
+
+ y = (uint32_t *)_x;
+ x = (uint32_t *)_y;
+
+ for (i = 0; i sizeof(Elf32_Rela) / sizeof(uint32_t); i++) {
+ tmp = x[i];
+ x[i] = y[i];
+ y[i] = tmp;
+ }
+}
+
+/* Get the potential trampolines size required of the init and
+ non-init sections */
+static unsigned long get_plt_size(const Elf32_Ehdr *hdr,
+ const Elf32_Shdr *sechdrs,
+ const char *secstrings,
+ int is_init)
+{
+ unsigned long ret = 0;
+ unsigned i;
+
+ /* Everything marked ALLOC (this includes the exported
+ symbols) */
+ for (i = 1; i hdr-e_shnum; i++) {
+ /* If it's called *.init*, and we're not init, we're
+ not interested */
+ if ((strstr(secstrings + sechdrs[i].sh_name, .init) != NULL)
+ != is_init)
+ continue;
+
+ /* We don't want to look at debug sections. */
+ if
[PATCH v2 25/44] metag: System Calls
Add metag system call and gateway page interfaces. The metag
architecture port uses the generic system call numbers from
asm-generic/unistd.h, as well as a user gateway page mapped at
0x6000 which contains fast atomic primitives (depending on SMP) and
a fast method of accessing TLS data.
System calls use the SWITCH instruction with the immediate 0x440001 to
signal a system call.
Signed-off-by: James Hogan james.ho...@imgtec.com
---
arch/metag/include/asm/mman.h | 11 ++
arch/metag/include/asm/syscall.h | 104 +
arch/metag/include/asm/syscalls.h | 62 ++
arch/metag/include/asm/unistd.h | 12 ++
arch/metag/include/asm/user_gateway.h | 44 +++
arch/metag/include/uapi/asm/unistd.h | 21
arch/metag/kernel/sys_metag.c | 198 +
arch/metag/kernel/user_gateway.S | 97
8 files changed, 549 insertions(+), 0 deletions(-)
create mode 100644 arch/metag/include/asm/mman.h
create mode 100644 arch/metag/include/asm/syscall.h
create mode 100644 arch/metag/include/asm/syscalls.h
create mode 100644 arch/metag/include/asm/unistd.h
create mode 100644 arch/metag/include/asm/user_gateway.h
create mode 100644 arch/metag/include/uapi/asm/unistd.h
create mode 100644 arch/metag/kernel/sys_metag.c
create mode 100644 arch/metag/kernel/user_gateway.S
diff --git a/arch/metag/include/asm/mman.h b/arch/metag/include/asm/mman.h
new file mode 100644
index 000..17999db
--- /dev/null
+++ b/arch/metag/include/asm/mman.h
@@ -0,0 +1,11 @@
+#ifndef __METAG_MMAN_H__
+#define __METAG_MMAN_H__
+
+#include uapi/asm/mman.h
+
+#ifndef __ASSEMBLY__
+#define arch_mmap_check metag_mmap_check
+int metag_mmap_check(unsigned long addr, unsigned long len,
+unsigned long flags);
+#endif
+#endif /* __METAG_MMAN_H__ */
diff --git a/arch/metag/include/asm/syscall.h b/arch/metag/include/asm/syscall.h
new file mode 100644
index 000..24fc979
--- /dev/null
+++ b/arch/metag/include/asm/syscall.h
@@ -0,0 +1,104 @@
+/*
+ * Access to user system call parameters and results
+ *
+ * Copyright (C) 2008 Imagination Technologies Ltd.
+ *
+ * This copyrighted material is made available to anyone wishing to use,
+ * modify, copy, or redistribute it subject to the terms and conditions
+ * of the GNU General Public License v.2.
+ *
+ * See asm-generic/syscall.h for descriptions of what we must do here.
+ */
+
+#ifndef _ASM_METAG_SYSCALL_H
+#define _ASM_METAG_SYSCALL_H
+
+#include linux/sched.h
+#include linux/err.h
+#include linux/uaccess.h
+
+#include asm/switch.h
+
+static inline long syscall_get_nr(struct task_struct *task,
+ struct pt_regs *regs)
+{
+ unsigned long insn;
+
+ /*
+* FIXME there's no way to find out how we got here other than to
+* examine the memory at the PC to see if it is a syscall
+* SWITCH instruction.
+*/
+ if (get_user(insn, (unsigned long *)(regs-ctx.CurrPC - 4)))
+ return -1;
+
+ if (insn == __METAG_SW_ENCODING(SYS))
+ return regs-ctx.DX[0].U1;
+ else
+ return -1L;
+}
+
+static inline void syscall_rollback(struct task_struct *task,
+ struct pt_regs *regs)
+{
+ /* do nothing */
+}
+
+static inline long syscall_get_error(struct task_struct *task,
+struct pt_regs *regs)
+{
+ unsigned long error = regs-ctx.DX[0].U0;
+ return IS_ERR_VALUE(error) ? error : 0;
+}
+
+static inline long syscall_get_return_value(struct task_struct *task,
+ struct pt_regs *regs)
+{
+ return regs-ctx.DX[0].U0;
+}
+
+static inline void syscall_set_return_value(struct task_struct *task,
+ struct pt_regs *regs,
+ int error, long val)
+{
+ regs-ctx.DX[0].U0 = (long) error ?: val;
+}
+
+static inline void syscall_get_arguments(struct task_struct *task,
+struct pt_regs *regs,
+unsigned int i, unsigned int n,
+unsigned long *args)
+{
+ unsigned int reg, j;
+ BUG_ON(i + n 6);
+
+ for (j = i, reg = 6 - i; j (i + n); j++, reg--) {
+ if (reg % 2)
+ args[j] = regs-ctx.DX[(reg + 1) / 2].U0;
+ else
+ args[j] = regs-ctx.DX[reg / 2].U1;
+ }
+}
+
+static inline void syscall_set_arguments(struct task_struct *task,
+struct pt_regs *regs,
+unsigned int i, unsigned int n,
+const unsigned long *args)
+{
+ unsigned int reg;
+ BUG_ON(i + n 6);
+
+ for (reg = 6 - i; i (i + n); i++, reg--) {
+ if (reg % 2)
+
[PATCH v2 24/44] metag: IRQ handling
Add core IRQ handling for metag. The code in irq.c exposes the TBX
signal numbers as Linux IRQs.
Meta core internal interrupts (from HWSTATMETA and friends) are vectored
onto the TR1 core trigger for the current thread. This is demultiplexed
in irq_internal.c to individual Linux IRQs for each internal interrupt.
External SoC interrupts (from HWSTATEXT and friends) are vectored onto
the TR2 core trigger for the current thread. This is demultiplexed in
irq_external.c to individual Linux IRQs for each external SoC interrupt.
TODO: make purer use of sparse IRQs
TODO: move IRQ drivers into drivers/irqchip
Signed-off-by: James Hogan james.ho...@imgtec.com
---
.../devicetree/bindings/metag/meta-intc.txt| 92 ++
arch/metag/include/asm/irq.h | 79 ++
arch/metag/include/asm/irq_external.h | 33 +
arch/metag/include/asm/irq_internal.h | 16 +
arch/metag/include/asm/irqflags.h | 97 +++
arch/metag/kernel/irq.c| 277 ++
arch/metag/kernel/irq_external.c | 886
arch/metag/kernel/irq_internal.c | 237 ++
8 files changed, 1717 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/metag/meta-intc.txt
create mode 100644 arch/metag/include/asm/irq.h
create mode 100644 arch/metag/include/asm/irq_external.h
create mode 100644 arch/metag/include/asm/irq_internal.h
create mode 100644 arch/metag/include/asm/irqflags.h
create mode 100644 arch/metag/kernel/irq.c
create mode 100644 arch/metag/kernel/irq_external.c
create mode 100644 arch/metag/kernel/irq_internal.c
diff --git a/Documentation/devicetree/bindings/metag/meta-intc.txt
b/Documentation/devicetree/bindings/metag/meta-intc.txt
new file mode 100644
index 000..b9bbe19
--- /dev/null
+++ b/Documentation/devicetree/bindings/metag/meta-intc.txt
@@ -0,0 +1,92 @@
+* Meta External Trigger Controller Binding
+
+This binding specifies what properties must be available in the device tree
+representation of a Meta external trigger controller.
+
+Required properties:
+
+- compatible: Specifies the compatibility list for the interrupt
controller.
+ The type shall be string and the value shall include img,meta-intc.
+
+- num-banks: Specifies the number of interrupt banks (each of which can
+ handle 32 interrupt sources).
+
+- interrupt-controller: The presence of this property identifies the node
+ as an interupt controller. No property value shall be defined.
+
+- #interrupt-cells: Specifies the number of cells needed to encode an
+ interrupt source. The type shall be a u32 and the value shall be 2.
+
+- #address-cells: Specifies the number of cells needed to encode an
+ address. The type shall be u32 and the value shall be 0. As such,
+ 'interrupt-map' nodes do not have to specify a parent unit address.
+
+Optional properties:
+
+- no-mask: The controller doesn't have any mask registers.
+
+- default-level: List of default level bitfields, one for each bank, where
+ each set bit indicates that the interrupt should be level sensitive by
+ default rather than edge. The purpose of this is mainly to ease the
+ transition to device tree from platform data. It should not be necessary
+ if all IRQ users are configured with devicetree as each one should set
the
+ flow type in the interrupt specifier.
+
+* Interrupt Specifier Definition
+
+ Interrupt specifiers consists of 2 cells encoded as follows:
+
+- 1st-cell: The interrupt-number that identifies the interrupt source.
+
+- 2nd-cell: The Linux interrupt flags containing level-sense information,
+ encoded as follows:
+1 = edge triggered
+4 = level-sensitive
+
+* Examples
+
+Example 1:
+
+ /*
+* Meta external trigger block
+*/
+ intc: intc {
+ // This is an interrupt controller node.
+ interrupt-controller;
+
+ // No address cells so that 'interrupt-map' nodes which
+ // reference this interrupt controller node do not need a parent
+ // address specifier.
+ #address-cells = 0;
+
+ // Two cells to encode interrupt sources.
+ #interrupt-cells = 2;
+
+ // Number of interrupt banks
+ num-banks = 2;
+
+ // IRQs 0-35 are level sensitive, except 16 and 34
+ default-level = 0xfffe 0xb;
+
+ // No HWMASKEXT is available (specify on Chorus2 and Comet ES1)
+ no-mask;
+
+ // Compatible with Meta hardware trigger block.
+ compatible = img,meta-intc;
+ };
+
+Example 2:
+
+ /*
+* An interrupt generating device that is wired to a Meta external
+* trigger block.
+*/
+ uart1: uart@0x02004c00 {
+
[PATCH v2 23/44] metag: Traps
Add trap code for metag. At the lowest level Meta traps (and return from
interrupt instruction - RTI) simply swap the PC and PCX registers and
optionally toggle the interrupt status bit (ISTAT). Low level TBX code
in tbipcx.S handles the core context save, determine the TBX signal
number based on the core trigger that fired (using the TXSTATI status
register), and call TBX signal handlers (mostly in traps.c) via a vector
table.
Signed-off-by: James Hogan james.ho...@imgtec.com
---
arch/metag/include/asm/switch.h | 22 +
arch/metag/include/asm/traps.h | 43 ++
arch/metag/kernel/kick.c| 94
arch/metag/kernel/tbiunexp.S| 22 +
arch/metag/kernel/traps.c | 964 +++
5 files changed, 1145 insertions(+), 0 deletions(-)
create mode 100644 arch/metag/include/asm/switch.h
create mode 100644 arch/metag/include/asm/traps.h
create mode 100644 arch/metag/kernel/kick.c
create mode 100644 arch/metag/kernel/tbiunexp.S
create mode 100644 arch/metag/kernel/traps.c
diff --git a/arch/metag/include/asm/switch.h b/arch/metag/include/asm/switch.h
new file mode 100644
index 000..53eed0d
--- /dev/null
+++ b/arch/metag/include/asm/switch.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2012 Imagination Technologies Ltd.
+ *
+ * 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.
+ */
+
+#ifndef _ASM_METAG_SWITCH_H
+#define _ASM_METAG_SWITCH_H
+
+/* metag SWITCH codes */
+#define __METAG_SW_IDLE0x40/* idle waiting for
trigger */
+#define __METAG_SW_PERM_BREAK 0x42/* compiled in breakpoint */
+#define __METAG_SW_SYS_LEGACY 0x44/* legacy system calls */
+#define __METAG_SW_SYS 0x440001/* system calls */
+
+/* metag SWITCH instruction encoding */
+#define __METAG_SW_ENCODING(TYPE) (0xaf00 | (__METAG_SW_##TYPE))
+
+#endif /* _ASM_METAG_SWITCH_H */
diff --git a/arch/metag/include/asm/traps.h b/arch/metag/include/asm/traps.h
new file mode 100644
index 000..24db3ac
--- /dev/null
+++ b/arch/metag/include/asm/traps.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2005,2008 Imagination Technologies
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ */
+
+#ifndef _METAG_TBIVECTORS_H
+#define _METAG_TBIVECTORS_H
+
+#ifndef __ASSEMBLY__
+
+#include asm/tbx.h
+
+typedef TBIRES (*kick_irq_func_t)(TBIRES, int, int, int, PTBI, int *);
+
+extern TBIRES kick_handler(TBIRES, int, int, int, PTBI);
+struct kick_irq_handler {
+ struct list_head list;
+ kick_irq_func_t func;
+};
+
+extern void kick_register_func(struct kick_irq_handler *);
+extern void kick_unregister_func(struct kick_irq_handler *);
+
+extern void head_end(TBIRES, unsigned long);
+extern TBIRES tail_end(TBIRES, unsigned long);
+
+DECLARE_PER_CPU(PTBI, pTBI);
+extern PTBI pTBI_get(unsigned int);
+
+extern int ret_from_fork(TBIRES arg);
+
+extern int do_page_fault(struct pt_regs *regs, unsigned long address,
+unsigned int write_access, unsigned int trapno);
+
+extern TBIRES __TBIUnExpXXX(TBIRES State, int SigNum, int Triggers, int Inst,
+ PTBI pTBI);
+
+#endif
+
+#endif /* _METAG_TBIVECTORS_H */
diff --git a/arch/metag/kernel/kick.c b/arch/metag/kernel/kick.c
new file mode 100644
index 000..c9858e2
--- /dev/null
+++ b/arch/metag/kernel/kick.c
@@ -0,0 +1,94 @@
+/*
+ * Copyright (C) 2009 Imagination Technologies
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ *
+ * The Meta KICK interrupt mechanism is generally a useful feature, so
+ * we provide an interface for registering multiple interrupt
+ * handlers. All the registered interrupt handlers are chained. When
+ * a KICK interrupt is received the first function in the list is
+ * called. If that interrupt handler cannot handle the KICK the next
+ * one is called, then the next until someone handles it (or we run
+ * out of functions). As soon as one function handles the interrupt no
+ * other handlers are called.
+ *
+ * The only downside of chaining interrupt handlers is that each
+ * handler must be able to detect whether the KICK was intended for it
+ * or not. For example, when the IPI handler runs and it sees that
+ * there are no IPI messages it must not signal that the KICK was
+ * handled, thereby giving the other handlers a chance to run.
+ *
+ * The reason that we provide our own interface for calling KICK
+ * handlers instead of using the generic kernel infrastructure is that
+ * the KICK handlers require access to a CPU's pTBI structure. So we
+ * pass it as an
RE: [PATCH v7 3/3] aerdrv: Cleanup log output for CPER based AER
Here it is, you're initializing 'prefix' here although it is being
used in the previous patch. You should concentrate the whole prefix
initialization and passing in one patch so that there are no breakages.
Yes I probably could have broken up the patches in a cleaner way. Thanks.
Also, why is it exactly 44 chars long, is that some magic number
that always works? At least this is what aer_print_error does
too. I'm guessing someone chose it because it is large enough for
dev_driver_string() and dev_name() and a couple more formatting
characters. Oh well.
Yes, I was using the same code as in aer_print_error. This was brought up in a
previous mail with Joe and we discussed cleaning all of this up in a later
patch.
Lance
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH v2 19/44] metag: Signal handling
Add signal handling code for metag.
Signed-off-by: James Hogan james.ho...@imgtec.com
---
arch/metag/include/uapi/asm/sigcontext.h | 31 +++
arch/metag/include/uapi/asm/siginfo.h|8 +
arch/metag/kernel/signal.c | 345 ++
3 files changed, 384 insertions(+), 0 deletions(-)
create mode 100644 arch/metag/include/uapi/asm/sigcontext.h
create mode 100644 arch/metag/include/uapi/asm/siginfo.h
create mode 100644 arch/metag/kernel/signal.c
diff --git a/arch/metag/include/uapi/asm/sigcontext.h
b/arch/metag/include/uapi/asm/sigcontext.h
new file mode 100644
index 000..ef79a91
--- /dev/null
+++ b/arch/metag/include/uapi/asm/sigcontext.h
@@ -0,0 +1,31 @@
+#ifndef _ASM_METAG_SIGCONTEXT_H
+#define _ASM_METAG_SIGCONTEXT_H
+
+#include asm/ptrace.h
+
+/*
+ * In a sigcontext structure we need to store the active state of the
+ * user process so that it does not get trashed when we call the signal
+ * handler. That not really the same as a user context that we are
+ * going to store on syscall etc.
+ */
+struct sigcontext {
+ struct user_gp_regs regs; /* needs to be first */
+
+ /*
+* Catch registers describing a memory fault.
+* If USER_GP_REGS_STATUS_CATCH_BIT is set in regs.status then catch
+* buffers have been saved and will be replayed on sigreturn.
+* Clear that bit to discard the catch state instead of replaying it.
+*/
+ struct user_cb_regs cb;
+
+ /*
+* Read pipeline state. This will get restored on sigreturn.
+*/
+ struct user_rp_state rp;
+
+ unsigned long oldmask;
+};
+
+#endif
diff --git a/arch/metag/include/uapi/asm/siginfo.h
b/arch/metag/include/uapi/asm/siginfo.h
new file mode 100644
index 000..b2e0c8b
--- /dev/null
+++ b/arch/metag/include/uapi/asm/siginfo.h
@@ -0,0 +1,8 @@
+#ifndef _METAG_SIGINFO_H
+#define _METAG_SIGINFO_H
+
+#define __ARCH_SI_TRAPNO
+
+#include asm-generic/siginfo.h
+
+#endif
diff --git a/arch/metag/kernel/signal.c b/arch/metag/kernel/signal.c
new file mode 100644
index 000..9d7065a
--- /dev/null
+++ b/arch/metag/kernel/signal.c
@@ -0,0 +1,345 @@
+/*
+ * Copyright (C) 1991,1992 Linus Torvalds
+ * Copyright (C) 2005,2006,2007,2008,2009 Imagination Technologies Ltd.
+ *
+ * 1997-11-28 Modified for POSIX.1b signals by Richard Henderson
+ *
+ */
+
+#include linux/sched.h
+#include linux/mm.h
+#include linux/smp.h
+#include linux/kernel.h
+#include linux/signal.h
+#include linux/errno.h
+#include linux/wait.h
+#include linux/ptrace.h
+#include linux/unistd.h
+#include linux/stddef.h
+#include linux/personality.h
+#include linux/uaccess.h
+#include linux/tracehook.h
+
+#include asm/ucontext.h
+#include asm/cacheflush.h
+#include asm/switch.h
+#include asm/syscall.h
+#include asm/syscalls.h
+
+#define REG_FLAGS ctx.SaveMask
+#define REG_RETVAL ctx.DX[0].U0
+#define REG_SYSCALLctx.DX[0].U1
+#define REG_SP ctx.AX[0].U0
+#define REG_ARG1 ctx.DX[3].U1
+#define REG_ARG2 ctx.DX[3].U0
+#define REG_ARG3 ctx.DX[2].U1
+#define REG_PC ctx.CurrPC
+#define REG_RTPctx.DX[4].U1
+
+int sys_sigaltstack(const stack_t __user *uss,
+ stack_t __user *uoss,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ struct pt_regs *regs)
+{
+ return do_sigaltstack(uss, uoss, regs-REG_SP);
+}
+
+struct rt_sigframe {
+ struct siginfo info;
+ struct ucontext uc;
+ unsigned long retcode[2];
+};
+
+static int restore_sigcontext(struct pt_regs *regs,
+ struct sigcontext __user *sc)
+{
+ int err;
+
+ /* Always make any pending restarted system calls return -EINTR */
+ current_thread_info()-restart_block.fn = do_no_restart_syscall;
+
+ err = metag_gp_regs_copyin(regs, 0, sizeof(struct user_gp_regs), NULL,
+ sc-regs);
+ if (!err)
+ err = metag_cb_regs_copyin(regs, 0,
+ sizeof(struct user_cb_regs), NULL,
+ sc-cb);
+ if (!err)
+ err = metag_rp_state_copyin(regs, 0,
+ sizeof(struct user_rp_state), NULL,
+ sc-rp);
+
+ /* This is a user-mode context. */
+ regs-REG_FLAGS |= TBICTX_PRIV_BIT;
+
+ return err;
+}
+
+int sys_rt_sigreturn(unsigned long arg1,
+unsigned long arg2,
+unsigned long arg3,
+unsigned long arg4,
+unsigned long arg5,
+unsigned long arg6,
+struct pt_regs *regs)/* regs always arg7 on Meta */
+{
+ /* NOTE - Meta stack goes UPWARDS - so we wind the stack back */
+ struct rt_sigframe
