* [PATCH] Re: Hardcoded instruction causes certain features to fail on ARM platfrom due to endianness
From: Dave Martin @ 2012-10-16 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKw8HL154a=K9O7CzPFZ-EqtT+BxYU-uRHodtutdRfYmNpWVww@mail.gmail.com>
On Mon, Oct 15, 2012 at 11:33:08PM +0800, Fei Yang wrote:
> 2012/10/15 Mikael Pettersson <mikpe@it.uu.se>:
> > Yangfei (Felix) writes:
> > > Hi all,
> > >
> > > I found that hardcoded instruction in inline asm can cause certains certain features fail to work on ARM platform due to endianness.
> > > As an example, consider the following code snippet of platform_do_lowpower function from arch/arm/mach-realview/hotplug.c:
> > > / *
> > > * here's the WFI
> > > */
> > > asm(".word 0xe320f003\n"
> > > :
> > > :
> > > : "memory", "cc");
> > >
> > > The instruction generated from this inline asm will not work on big-endian ARM platform, such as ARM BE-8 format. Instead, an exception will be generated.
> > >
> > > Here the code should be:
> > > / *
> > > * here's the WFI
> > > */
> > > asm("WFI\n"
> > > :
> > > :
> > > : "memory", "cc");
> > >
> > > Seems the kernel doesn't support ARM BE-8 well. I don't know why this problem happens.
> > > Can anyone tell me who owns this part? I can prepare a patch then.
> > > Thanks.
> >
> > Questions regarding the ARM kernel should go to the linux-arm-kernel mailing list
> > (see the MAINTAINERS file), with an optional cc: to the regular LKML.
> >
> > BE-8 is, if I recall correctly, ARMv7's broken format where code and data have
> > different endianess. GAS supports an ".inst" directive which is like ".word"
> > except the data is assumed to be code. This matters for disassembly, and may
> > also be required for BE-8.
> >
> > That is, just s/.word/.inst/g above and report back if that works or not.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
> >
>
> Hi Mikael,
>
> Thanks for the reply. I modified the code as suggested and rebuilt the
> kernel, cpu-hotplug feature now works on big-endian(BE-8) ARM
> platform.
> Since the ARM core can be configured by system software to work in
> big-endian mode, it's necessary to fix this problem. And here is a
> small patch :
>
> diff -urN linux-3.6.2/arch/arm/mach-exynos/hotplug.c
> linux/arch/arm/mach-exynos/hotplug.c
> --- linux-3.6.2/arch/arm/mach-exynos/hotplug.c 2012-10-13
> 04:50:59.000000000 +0800
> +++ linux/arch/arm/mach-exynos/hotplug.c 2012-10-15 23:05:44.000000000 +0800
> @@ -72,7 +72,7 @@
> /*
> * here's the WFI
> */
> - asm(".word 0xe320f003\n"
> + asm(".inst 0xe320f003\n"
The cleanest fix would simply be to build these files with appropriate
modified CFLAGS (-march=armv6k or -march=armv7-a), and use the proper
"wfi" mnemonic.
Failing that, you could use the facilities in <asm/opcodes.h> to
declare a wrapper macro for injecting this opcode (see
<asm/opcodes-virt.h> for an example). However, putting custom
opcodes into the assembler should only be done if it's really
necessary. Nowadays, I think we can consider tools which don't
understand the WFI mnemonic to be obsolete, at least for platforms
which only build for v7 and above.
The relevant board maintainers would need to sign off on such a
change, so we don't end up breaking their builds.
If any of these boards needs to build for v6K, the custom opcode might
be worth it -- some people might just possibly be relying on older tools
for such platforms.
Cheers
---Dave
> :
> :
> : "memory", "cc");
> diff -urN linux-3.6.2/arch/arm/mach-realview/hotplug.c
> linux/arch/arm/mach-realview/hotplug.c
> --- linux-3.6.2/arch/arm/mach-realview/hotplug.c 2012-10-13
> 04:50:59.000000000 +0800
> +++ linux/arch/arm/mach-realview/hotplug.c 2012-10-15 23:05:00.000000000 +0800
> @@ -66,7 +66,7 @@
> /*
> * here's the WFI
> */
> - asm(".word 0xe320f003\n"
> + asm(".inst 0xe320f003\n"
> :
> :
> : "memory", "cc");
> diff -urN linux-3.6.2/arch/arm/mach-shmobile/hotplug.c
> linux/arch/arm/mach-shmobile/hotplug.c
> --- linux-3.6.2/arch/arm/mach-shmobile/hotplug.c 2012-10-13
> 04:50:59.000000000 +0800
> +++ linux/arch/arm/mach-shmobile/hotplug.c 2012-10-15 23:05:25.000000000 +0800
> @@ -53,7 +53,7 @@
> /*
> * here's the WFI
> */
> - asm(".word 0xe320f003\n"
> + asm(".inst 0xe320f003\n"
> :
> :
> : "memory", "cc");
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] mm: compaction: Correct the nr_strict_isolated check for CMA
From: Rik van Riel @ 2012-10-16 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016083927.GG29125@suse.de>
On 10/16/2012 04:39 AM, Mel Gorman wrote:
> Thierry reported that the "iron out" patch for isolate_freepages_block()
> had problems due to the strict check being too strict with "mm: compaction:
> Iron out isolate_freepages_block() and isolate_freepages_range() -fix1".
> It's possible that more pages than necessary are isolated but the check
> still fails and I missed that this fix was not picked up before RC1. This
> same problem has been identified in 3.7-RC1 by Tony Prisk and should be
> addressed by the following patch.
>
> Signed-off-by: Mel Gorman <mgorman@suse.de>
> Tested-by: Tony Prisk <linux@prisktech.co.nz>
Acked-by: Rik van Riel <riel@redhat.com>
--
All rights reversed
^ permalink raw reply
* [PATCH RFC 02/11 v4] gpio: Add sysfs support to block GPIO API
From: Roland Stigge @ 2012-10-16 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015235720.GA3132@kroah.com>
On 10/16/2012 01:57 AM, Greg KH wrote:
> On Tue, Oct 16, 2012 at 01:31:18AM +0200, Roland Stigge wrote:
>> +int gpio_block_export(struct gpio_block *block)
>> +{
>> + int status;
>> + struct device *dev;
>> +
>> + /* can't export until sysfs is available ... */
>> + if (!gpio_class.p) {
>> + pr_debug("%s: called too early!\n", __func__);
>> + return -ENOENT;
>> + }
>> +
>> + mutex_lock(&sysfs_lock);
>> + dev = device_create(&gpio_class, NULL, MKDEV(0, 0), block,
>> + block->name);
>> + if (!IS_ERR(dev))
>> + status = sysfs_create_group(&dev->kobj, &gpio_block_attr_group);
>> + else
>> + status = PTR_ERR(dev);
>> + mutex_unlock(&sysfs_lock);
>
> You just raced with userspace telling it that the device was present,
> yet the attributes are not there. Don't do that, use the default class
> attributes for the class and then the driver core will create them
> automagically without needing to this "by hand" at all.
I guess you mean class attributes like gpio_class_attrs[] of gpio_class?
Aren't class attributes specific to a class only (i.e. only one
attribute at the root for all devices)? What I needed above are
attributes for the block itself (of which there can be several). So we
need device attributes for each block, not class attributes here.
Maybe there's some other kind of locking/atomicity available for this task?
Further, current gpio and gpiochip devices are also doing this way:
creating the device and subsequently their attrs, even though there may
be a better way but I'm still wondering how this would be.
Any hint appreciated.
Thanks in advance,
Roland
^ permalink raw reply
* [PATCH] i2c: omap: revert "i2c: omap: switch to threaded IRQ support"
From: Shubhrajyoti Datta @ 2012-10-16 12:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210150148080.16624@utopia.booyaka.com>
On Mon, Oct 15, 2012 at 7:21 AM, Paul Walmsley <paul@pwsan.com> wrote:
>
> Commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde ("i2c: omap: switch to
> threaded IRQ support") causes communication with I2C devices to fail
> after system suspend/resume on all OMAP3 devices:
>
Could you tell me which omap3 platform
On Beagle Xm
after
mount /dev/mmcblk /mmcfs
# mount /dev/mmcblk0p2 /mmcfs/
[ 412.480041] kjournald starting. Commit interval 5 seconds
[ 412.490020] EXT3-fs (mmcblk0p2): using internal journal
[ 412.495605] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode
#
# cd /mmcfs/
#
#
# ls
bin omap3_usb_prcm.sh usb_prcm.sh
dev omap3_usbhs_off.sh usb_uhh_show.sh
etc omap3_usbhs_on.sh usb_uhh_tll.sh
init proc usbhs_clk_disable.sh
lib readmem.dat usbhs_clk_enable.sh
lost+found root usbhs_set_sm.sh
mnt sbin usbhs_show.sh
modules sys usr
msc tmp var
omap3_ehcidump.sh usb_omap3.sh
#
#
# echo mem > /sys/power/state
[ 464.785461] PM: Syncing filesystems ... done.
[ 464.791442] PM: Preparing system for mem sleep
[ 464.798034] Freezing user space processes ... (elapsed 0.02 seconds) done.
[ 464.827301] Freezing remaining freezable tasks ... (elapsed 0.02
seconds) done.
[ 464.858703] PM: Entering mem sleep
[ 464.862304] Suspending console(s) (use no_console_suspend to debug)
[ 464.994415] PM: suspend of devices complete after 121.002 msecs
[ 464.998107] PM: late suspend of devices complete after 3.662 msecs
[ 465.003173] PM: noirq suspend of devices complete after 5.004 msecs
[ 465.003173] Disabling non-boot CPUs ...
[ 466.225585] Successfully put all powerdomains to target state
[ 466.228942] PM: noirq resume of devices complete after 3.051 msecs
[ 466.232421] PM: early resume of devices complete after 2.349 msecs
[ 467.492645] PM: resume of devices complete after 1260.131 msecs
[ 467.546936] PM: Finishing wakeup.
[ 467.550415] Restarting tasks ... done.
#
#
# cat /debug/pm_debug/count | grep per_pwrdm
per_pwrdm (ON),OFF:7,RET:0,INA:0,ON:8,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
per_clkdm->per_pwrdm (17)
# echo mem > /sys/power/state
[ 1492.225311] PM: Syncing filesystems ... done.
[ 1492.232177] PM: Preparing system for mem sleep
[ 1492.238830] Freezing user space processes ... (elapsed 0.02 seconds) done.
[ 1492.268188] Freezing remaining freezable tasks ... (elapsed 0.02
seconds) done.
[ 1492.299804] PM: Entering mem sleep
[ 1492.303375] Suspending console(s) (use no_console_suspend to debug)
[ 1492.435333] PM: suspend of devices complete after 120.880 msecs
[ 1492.439025] PM: late suspend of devices complete after 3.692 msecs
[ 1492.444091] PM: noirq suspend of devices complete after 5.004 msecs
[ 1492.444091] Disabling non-boot CPUs ...
[ 1493.745544] Successfully put all powerdomains to target state
[ 1493.748901] PM: noirq resume of devices complete after 3.051 msecs
[ 1493.752319] PM: early resume of devices complete after 2.319 msecs
[ 1494.794067] PM: resume of devices complete after 1041.625 msecs
[ 1494.848388] PM: Finishing wakeup.
[ 1494.851867] Restarting tasks ... done.
#
#
# cat /debug/pm_debug/count | grep per_pwrdm
per_pwrdm (ON),OFF:8,RET:0,INA:0,ON:9,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
per_clkdm->per_pwrdm (17)
#
Anyways will retry with fs on mmc.
^ permalink raw reply
* [PATCH 1/4] leds: leds-ns2: add device tree binding
From: Arnd Bergmann @ 2012-10-16 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350315295-14567-2-git-send-email-simon.guinot@sequanux.org>
On Monday 15 October 2012, Simon Guinot wrote:
> diff --git a/Documentation/devicetree/bindings/gpio/leds-ns2.txt b/Documentation/devicetree/bindings/gpio/leds-ns2.txt
> new file mode 100644
> index 0000000..1a84969
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/leds-ns2.txt
> @@ -0,0 +1,26 @@
> +Binding for dual-GPIO LED found on Network Space v2 (and parents).
> +
> +Required properties:
> +- compatible: "ns2-leds".
> +
> +Each LED is represented as a sub-node of the ns2-leds device.
> +
> +Required sub-node properties:
> +- cmd-gpio: Command LED GPIO. See OF device-tree GPIO specification.
> +- slow-gpio: Slow LED GPIO. See OF device-tree GPIO specification.
> +
> +Optional sub-node properties:
> +- label: Name for this LED. If omitted, the label is taken from the node name.
> +- linux,default-trigger: Trigger assigned to the LED.
Hi Simon,
I'm not overly familiar with the LED subsystem, but isn't this something
that could be done with the generic gpio-led driver?
If not, is it possible to extend that driver in a way to make it possible
and remove the leds-ns2 driver?
Arnd
^ permalink raw reply
* [PATCH] ARM: VIC: use irq_domain_add_simple()
From: Linus Walleij @ 2012-10-16 13:06 UTC (permalink / raw)
To: linux-arm-kernel
From: Linus Walleij <linus.walleij@linaro.org>
Instead of allocating descriptors on-the-fly for the device tree
initialization case, use irq_domain_add_simple() which will take
care of this if you pass negative as the first_irq.
Alter the signature of __vic_init() to pass the first_irq as
signed so this works as expected.
Switching the VIC to use irq_domain_add_simple() also has the
upside of displaying the same WARNING when you boot with
pre-allocated descriptors on systems using SPARSE_IRQ but
yet not using device tree.
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/common/vic.c | 18 ++++++------------
arch/arm/include/asm/hardware/vic.h | 2 +-
2 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/arch/arm/common/vic.c b/arch/arm/common/vic.c
index e0d5388..4fd5d98 100644
--- a/arch/arm/common/vic.c
+++ b/arch/arm/common/vic.c
@@ -218,7 +218,7 @@ static void __init vic_register(void __iomem *base, unsigned int irq,
v->resume_sources = resume_sources;
v->irq = irq;
vic_id++;
- v->domain = irq_domain_add_legacy(node, fls(valid_sources), irq, 0,
+ v->domain = irq_domain_add_simple(node, fls(valid_sources), irq,
&vic_irqdomain_ops, v);
}
@@ -350,7 +350,7 @@ static void __init vic_init_st(void __iomem *base, unsigned int irq_start,
vic_register(base, irq_start, vic_sources, 0, node);
}
-void __init __vic_init(void __iomem *base, unsigned int irq_start,
+void __init __vic_init(void __iomem *base, int irq_start,
u32 vic_sources, u32 resume_sources,
struct device_node *node)
{
@@ -416,18 +416,12 @@ int __init vic_of_init(struct device_node *node, struct device_node *parent)
if (WARN_ON(!regs))
return -EIO;
- irq_base = irq_alloc_descs(-1, 0, 32, numa_node_id());
- if (WARN_ON(irq_base < 0))
- goto out_unmap;
-
- __vic_init(regs, irq_base, ~0, ~0, node);
+ /*
+ * Passing -1 as first IRQ makes the simple domain allocate descriptors
+ */
+ __vic_init(regs, -1, ~0, ~0, node);
return 0;
-
- out_unmap:
- iounmap(regs);
-
- return -EIO;
}
#endif /* CONFIG OF */
diff --git a/arch/arm/include/asm/hardware/vic.h b/arch/arm/include/asm/hardware/vic.h
index e14af1a..2bebad3 100644
--- a/arch/arm/include/asm/hardware/vic.h
+++ b/arch/arm/include/asm/hardware/vic.h
@@ -47,7 +47,7 @@
struct device_node;
struct pt_regs;
-void __vic_init(void __iomem *base, unsigned int irq_start, u32 vic_sources,
+void __vic_init(void __iomem *base, int irq_start, u32 vic_sources,
u32 resume_sources, struct device_node *node);
void vic_init(void __iomem *base, unsigned int irq_start, u32 vic_sources, u32 resume_sources);
int vic_of_init(struct device_node *node, struct device_node *parent);
--
1.7.11.3
^ permalink raw reply related
* [PATCH] mm: compaction: Correct the nr_strict_isolated check for CMA
From: Minchan Kim @ 2012-10-16 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016083927.GG29125@suse.de>
On Tue, Oct 16, 2012 at 09:39:27AM +0100, Mel Gorman wrote:
> Thierry reported that the "iron out" patch for isolate_freepages_block()
> had problems due to the strict check being too strict with "mm: compaction:
> Iron out isolate_freepages_block() and isolate_freepages_range() -fix1".
> It's possible that more pages than necessary are isolated but the check
> still fails and I missed that this fix was not picked up before RC1. This
> same problem has been identified in 3.7-RC1 by Tony Prisk and should be
> addressed by the following patch.
>
> Signed-off-by: Mel Gorman <mgorman@suse.de>
> Tested-by: Tony Prisk <linux@prisktech.co.nz>
Acked-by: Minchan Kim <minchan@kernel.org>
--
Kind Regards,
Minchan Kim
^ permalink raw reply
* [RFC PATCH 0/4] ARM: multi-cluster aware boot protocol
From: Lorenzo Pieralisi @ 2012-10-16 13:21 UTC (permalink / raw)
To: linux-arm-kernel
This series is an updated version of a previous posting available here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080868.html
The introduction of multi-cluster ARM systems in SoC designs requires the
kernel to become cluster aware, so that it can be booted on every CPU in the
system and it can build an appropriate HW-to-logical cpu map.
Current code in the kernel, in particular the boot sequence, hinges upon a
sequential mapping of MPIDR values for cpus and related interrupt controller
CPU interfaces to logical cpu indexing.
This hypothesis is not valid when the concept of cluster is introduced since
the MPIDR cannot be represented as a single index and interrupt controller
CPU interfaces can be wired with a numbering scheme following per-SoC
design parameters which can be only detected through probing or device
tree representation.
Through the device tree and "cpu" nodes bindings, the kernel is provided
with HW values for MPIDR registers that allow the kernel to identify the
HW CPU ids that are present in the platform.
The GIC code has been extended to allow automatic detection of GIC CPU IF ids
at boot. IPIs are broadcast to all possible CPUs, and every time a secondary
CPU is booted, it initializes its own mask and clears itself from the mask of
all other logical CPUs.
The device tree bindings and GIC probing allow to boot the Linux kernel on any
CPU of a multi-cluster system without relying on a platform specific hook to
identify the number of CPUs and hypothesis on the sequential pattern of MPIDRs
and relative GIC CPU IF ids.
Pen release code for all converted platforms will need patching to extend the
current MPIDR range check; this will be done as soon as the bindings and
code for the multi-cluster boot protocol will be reviewed and accepted.
The patchset has been tested on:
- TC2 testchip
to boot a 5-core dual-cluster system on every possible CPU.
Lorenzo Pieralisi (3):
ARM: kernel: add device tree init map function
ARM: kernel: add cpu logical map DT init in setup_arch
ARM: kernel: add logical mappings look-up
Nicolas Pitre (1):
ARM: gic: use a private mapping for CPU target interfaces
Documentation/devicetree/bindings/arm/cpus.txt | 42 +++++++++++++++++++++++
arch/arm/common/gic.c | 42 ++++++++++++++++++-----
arch/arm/include/asm/prom.h | 2 ++
arch/arm/include/asm/smp_plat.h | 17 ++++++++++
arch/arm/kernel/devtree.c | 47 ++++++++++++++++++++++++++
arch/arm/kernel/setup.c | 1 +
6 files changed, 143 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/cpus.txt
--
1.7.12
^ permalink raw reply
* [RFC PATCH 1/4] ARM: kernel: add device tree init map function
From: Lorenzo Pieralisi @ 2012-10-16 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350393709-23546-1-git-send-email-lorenzo.pieralisi@arm.com>
When booting through a device tree, the kernel cpu logical id map can be
initialized using device tree data passed by FW or through an embedded blob.
This patch adds a function that parses device tree "cpu" nodes and
retrieves the corresponding CPUs hardware identifiers (MPIDR).
It sets the possible cpus and the cpu logical map values according to
the number of CPUs defined in the device tree and respective properties.
The primary CPU is assigned cpu logical number 0 to keep the current
convention valid.
Current bindings documentation is included in the patch:
Documentation/devicetree/bindings/arm/cpus.txt
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
Documentation/devicetree/bindings/arm/cpus.txt | 42 +++++++++++++++++++++++
arch/arm/include/asm/prom.h | 2 ++
arch/arm/kernel/devtree.c | 47 ++++++++++++++++++++++++++
3 files changed, 91 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/cpus.txt
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
new file mode 100644
index 0000000..897f3b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -0,0 +1,42 @@
+* ARM CPUs binding description
+
+The device tree allows to describe the layout of CPUs in a system through
+the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
+defining properties for every cpu.
+
+Bindings for CPU nodes follow the ePAPR standard, available from:
+
+http://devicetree.org
+
+For the ARM architecture every CPU node must contain the following property:
+
+- reg : property defining the CPU MPIDR[23:0] register bits
+
+Every cpu node is required to set its device_type to "cpu".
+
+Example:
+
+ cpus {
+ #size-cells = <0>;
+ #address-cells = <1>;
+
+ CPU0: cpu at 0 {
+ device_type = "cpu";
+ reg = <0x0>;
+ };
+
+ CPU1: cpu at 1 {
+ device_type = "cpu";
+ reg = <0x1>;
+ };
+
+ CPU2: cpu at 100 {
+ device_type = "cpu";
+ reg = <0x100>;
+ };
+
+ CPU3: cpu at 101 {
+ device_type = "cpu";
+ reg = <0x101>;
+ };
+ };
diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
index aeae9c6..8dd51dc 100644
--- a/arch/arm/include/asm/prom.h
+++ b/arch/arm/include/asm/prom.h
@@ -15,6 +15,7 @@
extern struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
extern void arm_dt_memblock_reserve(void);
+extern void __init arm_dt_init_cpu_maps(void);
#else /* CONFIG_OF */
@@ -24,6 +25,7 @@ static inline struct machine_desc *setup_machine_fdt(unsigned int dt_phys)
}
static inline void arm_dt_memblock_reserve(void) { }
+static inline void arm_dt_init_cpu_maps(void) { }
#endif /* CONFIG_OF */
#endif /* ASMARM_PROM_H */
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index bee7f9d..c86e414 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -19,8 +19,10 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
+#include <asm/cputype.h>
#include <asm/setup.h>
#include <asm/page.h>
+#include <asm/smp_plat.h>
#include <asm/mach/arch.h>
#include <asm/mach-types.h>
@@ -61,6 +63,51 @@ void __init arm_dt_memblock_reserve(void)
}
}
+/*
+ * arm_dt_init_cpu_maps - Function retrieves cpu nodes from the device tree
+ * and builds the cpu logical map array containing MPIDR values related to
+ * logical cpus
+ *
+ * Updates the cpu possible mask with the number of parsed cpu nodes
+ */
+void __init arm_dt_init_cpu_maps(void)
+{
+ struct device_node *dn = NULL;
+ int i, cpu = 1;
+
+ while ((dn = of_find_node_by_type(dn, "cpu")) && cpu <= nr_cpu_ids) {
+ const u32 *hwid;
+ int len;
+
+ pr_debug(" * %s...\n", dn->full_name);
+
+ hwid = of_get_property(dn, "reg", &len);
+
+ if (!hwid || len != 4) {
+ pr_err(" * %s missing reg property\n", dn->full_name);
+ continue;
+ }
+ /*
+ * We want to assign the boot CPU logical id 0.
+ * Boot CPU checks its own MPIDR and if matches the current
+ * cpu node "reg" value it sets the logical cpu index to 0
+ * and stores the physical id accordingly.
+ * If MPIDR does not match, assign sequential cpu logical
+ * id (starting from 1) and increments it.
+ */
+ i = (be32_to_cpup(hwid) == (read_cpuid_mpidr() & 0xffffff))
+ ? 0 : cpu++;
+
+ if (!i)
+ printk(KERN_INFO "Booting Linux on CPU HWID 0x%x\n",
+ be32_to_cpup(hwid));
+
+ cpu_logical_map(i) = be32_to_cpup(hwid);
+
+ set_cpu_possible(i, true);
+ }
+}
+
/**
* setup_machine_fdt - Machine setup when an dtb was passed to the kernel
* @dt_phys: physical address of dt blob
--
1.7.12
^ permalink raw reply related
* [RFC PATCH 2/4] ARM: kernel: add cpu logical map DT init in setup_arch
From: Lorenzo Pieralisi @ 2012-10-16 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350393709-23546-1-git-send-email-lorenzo.pieralisi@arm.com>
As soon as the device tree is unflattened the cpu logical to physical
mapping is carried out in setup_arch to build a proper array of MPIDR and
corresponding logical indexes.
The mapping could have been carried out using the flattened DT blob and
related primitives, but since the mapping is not needed by early boot
code it can safely be executed when the device tree has been uncompressed to
its tree data structure.
This patch adds the arm_dt_init_cpu maps() function call in setup_arch().
If the kernel is not compiled with DT support the function is empty and
no logical mapping takes place through it; the mapping carried out in
smp_setup_processor_id() is left unchanged.
If DT is supported the mapping created in smp_setup_processor_id() is overriden.
The DT mapping also sets the possible cpus mask, hence platform
code need not set it again in the respective smp_init_cpus() functions.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
arch/arm/kernel/setup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index da1d1aa..20c530b 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -758,6 +758,7 @@ void __init setup_arch(char **cmdline_p)
unflatten_device_tree();
+ arm_dt_init_cpu_maps();
#ifdef CONFIG_SMP
if (is_smp()) {
smp_set_ops(mdesc->smp);
--
1.7.12
^ permalink raw reply related
* [RFC PATCH 3/4] ARM: kernel: add logical mappings look-up
From: Lorenzo Pieralisi @ 2012-10-16 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350393709-23546-1-git-send-email-lorenzo.pieralisi@arm.com>
In ARM SMP systems the MPIDR register ([23:0] bits) is used to uniquely
identify CPUs.
In order to retrieve the logical CPU index corresponding to a given
MPIDR value and guarantee a consistent translation throughout the kernel,
this patch adds a look-up based on the MPIDR[23:0] so that kernel subsystems
can use it whenever the logical cpu index corresponding to a given MPIDR
value is needed.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
arch/arm/include/asm/smp_plat.h | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index 558d6c8..aaa61b6 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -5,6 +5,9 @@
#ifndef __ASMARM_SMP_PLAT_H
#define __ASMARM_SMP_PLAT_H
+#include <linux/cpumask.h>
+#include <linux/err.h>
+
#include <asm/cputype.h>
/*
@@ -48,5 +51,19 @@ static inline int cache_ops_need_broadcast(void)
*/
extern int __cpu_logical_map[];
#define cpu_logical_map(cpu) __cpu_logical_map[cpu]
+/*
+ * Retrieve logical cpu index corresponding to a given MPIDR[23:0]
+ * - mpidr: MPIDR[23:0] to be used for the look-up
+ *
+ * Returns the cpu logical index or -EINVAL on look-up error
+ */
+static inline int get_logical_index(u32 mpidr)
+{
+ int cpu;
+ for (cpu = 0; cpu < nr_cpu_ids; cpu++)
+ if (cpu_logical_map(cpu) == mpidr)
+ return cpu;
+ return -EINVAL;
+}
#endif
--
1.7.12
^ permalink raw reply related
* [RFC PATCH 4/4] ARM: gic: use a private mapping for CPU target interfaces
From: Lorenzo Pieralisi @ 2012-10-16 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350393709-23546-1-git-send-email-lorenzo.pieralisi@arm.com>
From: Nicolas Pitre <nicolas.pitre@linaro.org>
The GIC interface numbering does not necessarily follow the logical
CPU numbering, especially for complex topologies such as multi-cluster
systems.
Fortunately we can easily probe the GIC to create a mapping as the
Interrupt Processor Targets Registers for the first 32 interrupts are
read-only, and each field returns a value that always corresponds to
the processor reading the register.
Initially all mappings target all CPUs in case an IPI is required to
boot secondary CPUs. It is refined as those CPUs discover what their
actual mapping is.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
---
arch/arm/common/gic.c | 42 ++++++++++++++++++++++++++++++++++--------
1 file changed, 34 insertions(+), 8 deletions(-)
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index aa52699..1338a55 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -70,6 +70,13 @@ struct gic_chip_data {
static DEFINE_RAW_SPINLOCK(irq_controller_lock);
/*
+ * The GIC mapping of CPU interfaces does not necessarily match
+ * the logical CPU numbering. Let's use a mapping as returned
+ * by the GIC itself.
+ */
+static u8 gic_cpu_map[8] __read_mostly;
+
+/*
* Supported arch specific GIC irq extension.
* Default make them NULL.
*/
@@ -242,7 +249,7 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
return -EINVAL;
mask = 0xff << shift;
- bit = 1 << (cpu_logical_map(cpu) + shift);
+ bit = gic_cpu_map[cpu] << shift;
raw_spin_lock(&irq_controller_lock);
val = readl_relaxed(reg) & ~mask;
@@ -349,11 +356,6 @@ static void __init gic_dist_init(struct gic_chip_data *gic)
u32 cpumask;
unsigned int gic_irqs = gic->gic_irqs;
void __iomem *base = gic_data_dist_base(gic);
- u32 cpu = cpu_logical_map(smp_processor_id());
-
- cpumask = 1 << cpu;
- cpumask |= cpumask << 8;
- cpumask |= cpumask << 16;
writel_relaxed(0, base + GIC_DIST_CTRL);
@@ -366,6 +368,7 @@ static void __init gic_dist_init(struct gic_chip_data *gic)
/*
* Set all global interrupts to this CPU only.
*/
+ cpumask = readl_relaxed(base + GIC_DIST_TARGET + 0);
for (i = 32; i < gic_irqs; i += 4)
writel_relaxed(cpumask, base + GIC_DIST_TARGET + i * 4 / 4);
@@ -389,9 +392,25 @@ static void __cpuinit gic_cpu_init(struct gic_chip_data *gic)
{
void __iomem *dist_base = gic_data_dist_base(gic);
void __iomem *base = gic_data_cpu_base(gic);
+ unsigned int cpu_mask, cpu = smp_processor_id();
int i;
/*
+ * Get what the GIC says our CPU mask is.
+ */
+ BUG_ON(cpu >= 8);
+ cpu_mask = readl_relaxed(dist_base + GIC_DIST_TARGET + 0);
+ gic_cpu_map[cpu] = cpu_mask;
+
+ /*
+ * Clear our mask from the other map entries in case they're
+ * still undefined.
+ */
+ for (i = 0; i < 8; i++)
+ if (i != cpu)
+ gic_cpu_map[i] &= ~cpu_mask;
+
+ /*
* Deal with the banked PPI and SGI interrupts - disable all
* PPI interrupts, ensure all SGI interrupts are enabled.
*/
@@ -646,7 +665,7 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start,
{
irq_hw_number_t hwirq_base;
struct gic_chip_data *gic;
- int gic_irqs, irq_base;
+ int gic_irqs, irq_base, i;
BUG_ON(gic_nr >= MAX_GIC_NR);
@@ -683,6 +702,13 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start,
}
/*
+ * Initialize the CPU interface map to all CPUs.
+ * It will be refined as each CPU probes its ID.
+ */
+ for (i = 0; i < 8; i++)
+ gic_cpu_map[i] = 0xff;
+
+ /*
* For primary GICs, skip over SGIs.
* For secondary GICs, skip over PPIs, too.
*/
@@ -737,7 +763,7 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
/* Convert our logical CPU mask into a physical one. */
for_each_cpu(cpu, mask)
- map |= 1 << cpu_logical_map(cpu);
+ map |= gic_cpu_map[cpu];
/*
* Ensure that stores to Normal memory are visible to the
--
1.7.12
^ permalink raw reply related
* PDF documentation
From: Constantine Shulyupin @ 2012-10-16 13:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I have some questions and ideas about documentation in PDF format.
During embedded SW development I often work with documentation,
especially datasheets in PDF format. I have some issues with such
documentation. It is not so easy to manage a lot of PDF documents
sometimes with strange code in file names. It is not easy to store
and share links to documentation.
It is possible to reference to a PDF page in this way
http://www.ti.com/lit/ds/symlink/omap4430.pdf#page=100 , but it slow
and doesn?t work in all cases.
Sometimes it is more easy just to copy paste and send by email part of
documentation instead of using hyperlinks.
I found, that it is more easy work (and work collaboratively) with
documentation in HTML format. Sometimes it is possible just to convert
PDF to HTML.
Questions:
- have same issues with PDF documentation and datasheets?
- do you think documentation and datasheets in HTML format on a site
can be more useful than PDF?
- what PDF documentation do you use? (You can just drop a link to PDF,
for example http://www.ti.com/lit/ds/symlink/omap4430.pdf)
--
Constantine Shulyupin
http://www.MakeLinux.com/
Embedded Linux Systems,
Device Drivers, TI DaVinci
^ permalink raw reply
* [PATCH 1/1] ARM64: Remove duplicate inclusion of mmu_context.h in smp.c
From: Catalin Marinas @ 2012-10-16 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350116758-624-1-git-send-email-sachin.kamat@linaro.org>
On Sat, Oct 13, 2012 at 09:25:58AM +0100, Sachin Kamat wrote:
> asm/mmu_context.h was included twice.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Applied. Thanks.
--
Catalin
^ permalink raw reply
* [PATCH] ARM: VIC: use irq_domain_add_simple()
From: Rob Herring @ 2012-10-16 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350392786-29191-1-git-send-email-linus.walleij@stericsson.com>
On 10/16/2012 08:06 AM, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> Instead of allocating descriptors on-the-fly for the device tree
> initialization case, use irq_domain_add_simple() which will take
> care of this if you pass negative as the first_irq.
>
> Alter the signature of __vic_init() to pass the first_irq as
> signed so this works as expected.
>
> Switching the VIC to use irq_domain_add_simple() also has the
> upside of displaying the same WARNING when you boot with
> pre-allocated descriptors on systems using SPARSE_IRQ but
> yet not using device tree.
>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Rob
> ---
> arch/arm/common/vic.c | 18 ++++++------------
> arch/arm/include/asm/hardware/vic.h | 2 +-
> 2 files changed, 7 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/common/vic.c b/arch/arm/common/vic.c
> index e0d5388..4fd5d98 100644
> --- a/arch/arm/common/vic.c
> +++ b/arch/arm/common/vic.c
> @@ -218,7 +218,7 @@ static void __init vic_register(void __iomem *base, unsigned int irq,
> v->resume_sources = resume_sources;
> v->irq = irq;
> vic_id++;
> - v->domain = irq_domain_add_legacy(node, fls(valid_sources), irq, 0,
> + v->domain = irq_domain_add_simple(node, fls(valid_sources), irq,
> &vic_irqdomain_ops, v);
> }
>
> @@ -350,7 +350,7 @@ static void __init vic_init_st(void __iomem *base, unsigned int irq_start,
> vic_register(base, irq_start, vic_sources, 0, node);
> }
>
> -void __init __vic_init(void __iomem *base, unsigned int irq_start,
> +void __init __vic_init(void __iomem *base, int irq_start,
> u32 vic_sources, u32 resume_sources,
> struct device_node *node)
> {
> @@ -416,18 +416,12 @@ int __init vic_of_init(struct device_node *node, struct device_node *parent)
> if (WARN_ON(!regs))
> return -EIO;
>
> - irq_base = irq_alloc_descs(-1, 0, 32, numa_node_id());
> - if (WARN_ON(irq_base < 0))
> - goto out_unmap;
> -
> - __vic_init(regs, irq_base, ~0, ~0, node);
> + /*
> + * Passing -1 as first IRQ makes the simple domain allocate descriptors
> + */
> + __vic_init(regs, -1, ~0, ~0, node);
>
> return 0;
> -
> - out_unmap:
> - iounmap(regs);
> -
> - return -EIO;
> }
> #endif /* CONFIG OF */
>
> diff --git a/arch/arm/include/asm/hardware/vic.h b/arch/arm/include/asm/hardware/vic.h
> index e14af1a..2bebad3 100644
> --- a/arch/arm/include/asm/hardware/vic.h
> +++ b/arch/arm/include/asm/hardware/vic.h
> @@ -47,7 +47,7 @@
> struct device_node;
> struct pt_regs;
>
> -void __vic_init(void __iomem *base, unsigned int irq_start, u32 vic_sources,
> +void __vic_init(void __iomem *base, int irq_start, u32 vic_sources,
> u32 resume_sources, struct device_node *node);
> void vic_init(void __iomem *base, unsigned int irq_start, u32 vic_sources, u32 resume_sources);
> int vic_of_init(struct device_node *node, struct device_node *parent);
>
^ permalink raw reply
* [PATCH] i2c: omap: revert "i2c: omap: switch to threaded IRQ support"
From: Felipe Balbi @ 2012-10-16 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAM=Q2csHTbR4rBe1HNr5-M3sG5wgdCv6dCnGLmNQEwo1gjCSGg@mail.gmail.com>
Hi,
+ Thomas Gleixner
On Tue, Oct 16, 2012 at 06:28:13PM +0530, Shubhrajyoti Datta wrote:
> On Mon, Oct 15, 2012 at 7:21 AM, Paul Walmsley <paul@pwsan.com> wrote:
> >
> > Commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde ("i2c: omap: switch to
> > threaded IRQ support") causes communication with I2C devices to fail
> > after system suspend/resume on all OMAP3 devices:
> >
> Could you tell me which omap3 platform
>
> On Beagle Xm
> after
> mount /dev/mmcblk /mmcfs
>
>
> # mount /dev/mmcblk0p2 /mmcfs/
> [ 412.480041] kjournald starting. Commit interval 5 seconds
> [ 412.490020] EXT3-fs (mmcblk0p2): using internal journal
> [ 412.495605] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode
> #
>
>
> # cd /mmcfs/
> #
> #
> # ls
> bin omap3_usb_prcm.sh usb_prcm.sh
> dev omap3_usbhs_off.sh usb_uhh_show.sh
> etc omap3_usbhs_on.sh usb_uhh_tll.sh
> init proc usbhs_clk_disable.sh
> lib readmem.dat usbhs_clk_enable.sh
> lost+found root usbhs_set_sm.sh
> mnt sbin usbhs_show.sh
> modules sys usr
> msc tmp var
> omap3_ehcidump.sh usb_omap3.sh
> #
> #
> # echo mem > /sys/power/state
> [ 464.785461] PM: Syncing filesystems ... done.
> [ 464.791442] PM: Preparing system for mem sleep
> [ 464.798034] Freezing user space processes ... (elapsed 0.02 seconds) done.
> [ 464.827301] Freezing remaining freezable tasks ... (elapsed 0.02
> seconds) done.
> [ 464.858703] PM: Entering mem sleep
> [ 464.862304] Suspending console(s) (use no_console_suspend to debug)
> [ 464.994415] PM: suspend of devices complete after 121.002 msecs
> [ 464.998107] PM: late suspend of devices complete after 3.662 msecs
> [ 465.003173] PM: noirq suspend of devices complete after 5.004 msecs
> [ 465.003173] Disabling non-boot CPUs ...
> [ 466.225585] Successfully put all powerdomains to target state
> [ 466.228942] PM: noirq resume of devices complete after 3.051 msecs
> [ 466.232421] PM: early resume of devices complete after 2.349 msecs
> [ 467.492645] PM: resume of devices complete after 1260.131 msecs
> [ 467.546936] PM: Finishing wakeup.
> [ 467.550415] Restarting tasks ... done.
> #
> #
> # cat /debug/pm_debug/count | grep per_pwrdm
> per_pwrdm (ON),OFF:7,RET:0,INA:0,ON:8,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> per_clkdm->per_pwrdm (17)
> # echo mem > /sys/power/state
> [ 1492.225311] PM: Syncing filesystems ... done.
> [ 1492.232177] PM: Preparing system for mem sleep
> [ 1492.238830] Freezing user space processes ... (elapsed 0.02 seconds) done.
> [ 1492.268188] Freezing remaining freezable tasks ... (elapsed 0.02
> seconds) done.
> [ 1492.299804] PM: Entering mem sleep
> [ 1492.303375] Suspending console(s) (use no_console_suspend to debug)
> [ 1492.435333] PM: suspend of devices complete after 120.880 msecs
> [ 1492.439025] PM: late suspend of devices complete after 3.692 msecs
> [ 1492.444091] PM: noirq suspend of devices complete after 5.004 msecs
> [ 1492.444091] Disabling non-boot CPUs ...
> [ 1493.745544] Successfully put all powerdomains to target state
> [ 1493.748901] PM: noirq resume of devices complete after 3.051 msecs
> [ 1493.752319] PM: early resume of devices complete after 2.319 msecs
> [ 1494.794067] PM: resume of devices complete after 1041.625 msecs
> [ 1494.848388] PM: Finishing wakeup.
> [ 1494.851867] Restarting tasks ... done.
> #
> #
> # cat /debug/pm_debug/count | grep per_pwrdm
> per_pwrdm (ON),OFF:8,RET:0,INA:0,ON:9,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> per_clkdm->per_pwrdm (17)
> #
>
> Anyways will retry with fs on mmc.
rootfs has to be on MMC to trigger this. The problem happens because
omap_hsmmc calls enable_irq() on its resume method. That IRQ line is
actually a GPIO from TWL4030, so
twl4030-irq.c::twl4030_sih_bus_sync_unlock() will be called, which will
trigger an I2C transfer.
The problem I see is that even though we properly return IRQ_WAKE_THREAD
and wake_up_process() manages to wakeup the IRQ thread (it returns 1),
the thread is never scheduled. To make things even worse, ouw irq thread
runs once, but doesn't run on a consecutive call. Here's some (rather
nasty) debug prints showing the problem:
> [ 78.709381] omap_i2c omap_i2c.1: omap_i2c_isr_thread 913
> [ 78.715026] omap_i2c omap_i2c.1: omap_i2c_isr_thread 1038
> [ 78.720733] omap_i2c omap_i2c.1: omap_i2c_xfer 655
> [ 78.725769] omap_i2c omap_i2c.1: omap_i2c_xfer 659
> [ 78.730804] omap_i2c omap_i2c.1: omap_i2c_xfer 663
> [ 78.735870] omap_i2c omap_i2c.1: omap_i2c_xfer 668
> [ 78.850708] PM: suspend of devices complete after 1287.841 msecs
> [ 78.860870] PM: late suspend of devices complete after 3.753 msecs
> [ 78.872283] try_to_wake_up 1411
> [ 78.875701] try_to_wake_up 1411
> [ 78.879028] try_to_wake_up 1411
> [ 78.882537] omap_i2c omap_i2c.1: omap_i2c_runtime_suspend 1359
> [ 78.888763] omap_i2c omap_i2c.1: omap_i2c_low_level_suspend 1261
> [ 78.895416] PM: noirq suspend of devices complete after 28.015 msecs
> [ 78.902160] Disabling non-boot CPUs ...
> [ 88.568664] Powerdomain (per_pwrdm) didn't enter target state 1
> [ 88.574859] Powerdomain (core_pwrdm) didn't enter target state 1
> [ 88.581115] Could not enter target state in pm_suspend
> [ 88.586975] omap_i2c omap_i2c.1: omap_i2c_runtime_resume 1373
> [ 88.592987] omap_i2c omap_i2c.1: omap_i2c_low_level_resume 1287
> [ 88.599243] try_to_wake_up 1411
> [ 88.602569] try_to_wake_up 1411
> [ 88.608459] PM: noirq resume of devices complete after 21.759 msecs
> [ 88.615814] try_to_wake_up 1411
> [ 88.622497] PM: early resume of devices complete after 2.380 msecs
> [ 88.632965] omap_i2c omap_i2c.1: omap_i2c_xfer 626
> [ 88.638092] omap_i2c omap_i2c.1: omap_i2c_xfer 632
> [ 88.643188] omap_i2c omap_i2c.1: omap_i2c_xfer 648
> [ 88.648193] omap_i2c omap_i2c.1: addr: 0x0049, len: 4, flags: 0x0, stop: 1
> [ 88.655456] omap_i2c omap_i2c.1: omap_i2c_xfer_msg 537
> [ 88.660858] omap_i2c omap_i2c.1: omap_i2c_isr 885
> [ 88.665802] omap_i2c omap_i2c.1: omap_i2c_isr 891: mask 601f stat 1510
> [ 88.672637] omap_i2c omap_i2c.1: omap_i2c_isr 894
> [ 88.677551] omap_i2c omap_i2c.1: omap_i2c_isr 899
> [ 88.682495] ===> irq_wake_thread 139: IRQ 72 wake_up_process 1
> [ 88.688751] omap_i2c omap_i2c.1: omap_i2c_isr_thread 913
> [ 88.694335] omap_i2c omap_i2c.1: omap_i2c_isr_thread 1038
> [ 88.700347] omap_i2c omap_i2c.1: omap_i2c_isr 885
> [ 88.705291] omap_i2c omap_i2c.1: omap_i2c_isr 891: mask 601f stat 0104
> [ 88.712097] omap_i2c omap_i2c.1: omap_i2c_isr 894
> [ 88.717010] omap_i2c omap_i2c.1: omap_i2c_isr 899
> [ 88.721923] try_to_wake_up 1411
> [ 88.725189] ===> irq_wake_thread 139: IRQ 72 wake_up_process 0
> [ 88.731292] [sched_delayed] sched: RT throttling activated
> [ 88.737091] omap_i2c omap_i2c.1: omap_i2c_isr_thread 913
> [ 88.742706] omap_i2c omap_i2c.1: omap_i2c_isr_thread 1038
this is the last time our omap_i2c_isr_thread() runs. Note that the
thread was already running when wake_up_process() was called.
> [ 88.749206] omap_i2c omap_i2c.1: omap_i2c_xfer 655
> [ 88.754302] omap_i2c omap_i2c.1: omap_i2c_xfer 659
> [ 88.759368] omap_i2c omap_i2c.1: omap_i2c_xfer 663
> [ 88.764373] omap_i2c omap_i2c.1: omap_i2c_xfer 668
> [ 88.769531] omap_i2c omap_i2c.1: omap_i2c_xfer 626
> [ 88.774597] omap_i2c omap_i2c.1: omap_i2c_xfer 632
> [ 88.779602] omap_i2c omap_i2c.1: omap_i2c_xfer 648
> [ 88.784667] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0
> [ 88.791900] omap_i2c omap_i2c.1: omap_i2c_xfer_msg 537
> [ 88.797271] omap_i2c omap_i2c.1: omap_i2c_isr 885
> [ 88.802185] omap_i2c omap_i2c.1: omap_i2c_isr 891: mask 601f stat 1510
> [ 88.809020] omap_i2c omap_i2c.1: omap_i2c_isr 894
> [ 88.813934] omap_i2c omap_i2c.1: omap_i2c_isr 899
> [ 88.818847] ===> irq_wake_thread 139: IRQ 72 wake_up_process 1
notice here that our omap_i2c_isr_thread() never runs. I'm still
debugging, trying to pin point what the real issue is, but it's
definitely not the fact that we have a threaded ISR, since it runs at
least once.
> [ 90.610107] try_to_wake_up 1411
> [ 93.821044] try_to_wake_up 1411
> [ 93.824768] omap_i2c omap_i2c.1: controller timed out
> [ 93.830169] [<c001c118>] (unwind_backtrace+0x0/0xf0) from [<c040c738>] (omap_i2c_xfer_msg+0x314/0x360)
> [ 93.839935] [<c040c738>] (omap_i2c_xfer_msg+0x314/0x360) from [<c040d26c>] (omap_i2c_xfer+0xac/0x220)
> [ 93.849639] [<c040d26c>] (omap_i2c_xfer+0xac/0x220) from [<c040884c>] (__i2c_transfer+0x40/0x80)
> [ 93.858886] [<c040884c>] (__i2c_transfer+0x40/0x80) from [<c0409da8>] (i2c_transfer+0x1f8/0x26c)
> [ 93.868103] [<c0409da8>] (i2c_transfer+0x1f8/0x26c) from [<c035dab8>] (twl_i2c_read+0xc4/0x15c)
> [ 93.877288] [<c035dab8>] (twl_i2c_read+0xc4/0x15c) from [<c03189f4>] (twl4030ldo_get_voltage+0x28/0x60)
> [ 93.887145] [<c03189f4>] (twl4030ldo_get_voltage+0x28/0x60) from [<c03120b0>] (_regulator_get_voltage+0x68/0x84)
> [ 93.897827] [<c03120b0>] (_regulator_get_voltage+0x68/0x84) from [<c03125a0>] (regulator_get_voltage+0x20/0x38)
> [ 93.908447] [<c03125a0>] (regulator_get_voltage+0x20/0x38) from [<c0411bcc>] (mmc_regulator_set_ocr+0x40/0x12c)
> [ 93.919036] [<c0411bcc>] (mmc_regulator_set_ocr+0x40/0x12c) from [<c0426418>] (omap_hsmmc_set_power+0xe4/0x11c)
> [ 93.929626] [<c0426418>] (omap_hsmmc_set_power+0xe4/0x11c) from [<c042582c>] (omap_hsmmc_set_ios+0x140/0x150)
> [ 93.940032] [<c042582c>] (omap_hsmmc_set_ios+0x140/0x150) from [<c04135c4>] (mmc_power_up+0x80/0xc4)
> [ 93.949615] [<c04135c4>] (mmc_power_up+0x80/0xc4) from [<c04136d8>] (mmc_resume_host+0xd0/0x150)
> [ 93.958862] [<c04136d8>] (mmc_resume_host+0xd0/0x150) from [<c0426b5c>] (omap_hsmmc_resume+0x7c/0xc8)
> [ 93.968536] [<c0426b5c>] (omap_hsmmc_resume+0x7c/0xc8) from [<c0347a78>] (platform_pm_resume+0x2c/0x50)
> [ 93.978424] [<c0347a78>] (platform_pm_resume+0x2c/0x50) from [<c034bca4>] (dpm_run_callback.isra.4+0x2c/0x64)
> [ 93.988830] [<c034bca4>] (dpm_run_callback.isra.4+0x2c/0x64) from [<c034ca48>] (device_resume+0xdc/0x18c)
> [ 93.998870] [<c034ca48>] (device_resume+0xdc/0x18c) from [<c034ce8c>] (dpm_resume+0xfc/0x21c)
> [ 94.007812] [<c034ce8c>] (dpm_resume+0xfc/0x21c) from [<c034d094>] (dpm_resume_end+0xc/0x18)
> [ 94.016723] [<c034d094>] (dpm_resume_end+0xc/0x18) from [<c0087b14>] (suspend_devices_and_enter+0xe8/0x1b0)
> [ 94.026947] [<c0087b14>] (suspend_devices_and_enter+0xe8/0x1b0) from [<c0087c78>] (enter_state+0x9c/0xdc)
> [ 94.036987] [<c0087c78>] (enter_state+0x9c/0xdc) from [<c0087ccc>] (pm_suspend+0x14/0x70)
> [ 94.045593] [<c0087ccc>] (pm_suspend+0x14/0x70) from [<c0086d34>] (state_store+0x30/0x3c)
> [ 94.054199] [<c0086d34>] (state_store+0x30/0x3c) from [<c02d39b8>] (kobj_attr_store+0x14/0x20)
> [ 94.063262] [<c02d39b8>] (kobj_attr_store+0x14/0x20) from [<c017bcd0>] (sysfs_write_file+0x80/0xb4)
> [ 94.072784] [<c017bcd0>] (sysfs_write_file+0x80/0xb4) from [<c01174c4>] (vfs_write+0xa8/0x138)
> [ 94.081817] [<c01174c4>] (vfs_write+0xa8/0x138) from [<c0117730>] (sys_write+0x40/0x68)
> [ 94.090240] [<c0117730>] (sys_write+0x40/0x68) from [<c0013f40>] (ret_fast_syscall+0x0/0x3c)
> [ 94.099334] omap_i2c omap_i2c.1: omap_i2c_xfer 655
> [ 94.104431] omap_i2c omap_i2c.1: omap_i2c_xfer 659
> [ 94.109466] omap_i2c omap_i2c.1: omap_i2c_xfer 663
> [ 94.114532] omap_i2c omap_i2c.1: omap_i2c_xfer 668
> [ 94.119567] twl: i2c_read failed to transfer all messages
> [ 94.125244] omap_hsmmc omap_hsmmc.0: could not set regulator OCR (-110)
> [ 94.286773] mmc0: error -110 during resume (card was removed?)
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121016/07571ff5/attachment.sig>
^ permalink raw reply
* [PATCH] i2c: omap: revert "i2c: omap: switch to threaded IRQ support"
From: Felipe Balbi @ 2012-10-16 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016133356.GG21801@arwen.pp.htv.fi>
Hi again,
On Tue, Oct 16, 2012 at 04:33:56PM +0300, Felipe Balbi wrote:
> Hi,
>
> + Thomas Gleixner
>
> On Tue, Oct 16, 2012 at 06:28:13PM +0530, Shubhrajyoti Datta wrote:
> > On Mon, Oct 15, 2012 at 7:21 AM, Paul Walmsley <paul@pwsan.com> wrote:
> > >
> > > Commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde ("i2c: omap: switch to
> > > threaded IRQ support") causes communication with I2C devices to fail
> > > after system suspend/resume on all OMAP3 devices:
> > >
> > Could you tell me which omap3 platform
> >
> > On Beagle Xm
> > after
> > mount /dev/mmcblk /mmcfs
> >
> >
> > # mount /dev/mmcblk0p2 /mmcfs/
> > [ 412.480041] kjournald starting. Commit interval 5 seconds
> > [ 412.490020] EXT3-fs (mmcblk0p2): using internal journal
> > [ 412.495605] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode
> > #
> >
> >
> > # cd /mmcfs/
> > #
> > #
> > # ls
> > bin omap3_usb_prcm.sh usb_prcm.sh
> > dev omap3_usbhs_off.sh usb_uhh_show.sh
> > etc omap3_usbhs_on.sh usb_uhh_tll.sh
> > init proc usbhs_clk_disable.sh
> > lib readmem.dat usbhs_clk_enable.sh
> > lost+found root usbhs_set_sm.sh
> > mnt sbin usbhs_show.sh
> > modules sys usr
> > msc tmp var
> > omap3_ehcidump.sh usb_omap3.sh
> > #
> > #
> > # echo mem > /sys/power/state
> > [ 464.785461] PM: Syncing filesystems ... done.
> > [ 464.791442] PM: Preparing system for mem sleep
> > [ 464.798034] Freezing user space processes ... (elapsed 0.02 seconds) done.
> > [ 464.827301] Freezing remaining freezable tasks ... (elapsed 0.02
> > seconds) done.
> > [ 464.858703] PM: Entering mem sleep
> > [ 464.862304] Suspending console(s) (use no_console_suspend to debug)
> > [ 464.994415] PM: suspend of devices complete after 121.002 msecs
> > [ 464.998107] PM: late suspend of devices complete after 3.662 msecs
> > [ 465.003173] PM: noirq suspend of devices complete after 5.004 msecs
> > [ 465.003173] Disabling non-boot CPUs ...
> > [ 466.225585] Successfully put all powerdomains to target state
> > [ 466.228942] PM: noirq resume of devices complete after 3.051 msecs
> > [ 466.232421] PM: early resume of devices complete after 2.349 msecs
> > [ 467.492645] PM: resume of devices complete after 1260.131 msecs
> > [ 467.546936] PM: Finishing wakeup.
> > [ 467.550415] Restarting tasks ... done.
> > #
> > #
> > # cat /debug/pm_debug/count | grep per_pwrdm
> > per_pwrdm (ON),OFF:7,RET:0,INA:0,ON:8,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> > per_clkdm->per_pwrdm (17)
> > # echo mem > /sys/power/state
> > [ 1492.225311] PM: Syncing filesystems ... done.
> > [ 1492.232177] PM: Preparing system for mem sleep
> > [ 1492.238830] Freezing user space processes ... (elapsed 0.02 seconds) done.
> > [ 1492.268188] Freezing remaining freezable tasks ... (elapsed 0.02
> > seconds) done.
> > [ 1492.299804] PM: Entering mem sleep
> > [ 1492.303375] Suspending console(s) (use no_console_suspend to debug)
> > [ 1492.435333] PM: suspend of devices complete after 120.880 msecs
> > [ 1492.439025] PM: late suspend of devices complete after 3.692 msecs
> > [ 1492.444091] PM: noirq suspend of devices complete after 5.004 msecs
> > [ 1492.444091] Disabling non-boot CPUs ...
> > [ 1493.745544] Successfully put all powerdomains to target state
> > [ 1493.748901] PM: noirq resume of devices complete after 3.051 msecs
> > [ 1493.752319] PM: early resume of devices complete after 2.319 msecs
> > [ 1494.794067] PM: resume of devices complete after 1041.625 msecs
> > [ 1494.848388] PM: Finishing wakeup.
> > [ 1494.851867] Restarting tasks ... done.
> > #
> > #
> > # cat /debug/pm_debug/count | grep per_pwrdm
> > per_pwrdm (ON),OFF:8,RET:0,INA:0,ON:9,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> > per_clkdm->per_pwrdm (17)
> > #
> >
> > Anyways will retry with fs on mmc.
>
> rootfs has to be on MMC to trigger this. The problem happens because
> omap_hsmmc calls enable_irq() on its resume method. That IRQ line is
> actually a GPIO from TWL4030, so
> twl4030-irq.c::twl4030_sih_bus_sync_unlock() will be called, which will
> trigger an I2C transfer.
>
> The problem I see is that even though we properly return IRQ_WAKE_THREAD
> and wake_up_process() manages to wakeup the IRQ thread (it returns 1),
> the thread is never scheduled. To make things even worse, ouw irq thread
> runs once, but doesn't run on a consecutive call. Here's some (rather
another detail here:
if I drop the disable_irq()/enable_irq() from omap_hsmmc driver,
everything ends up being fine, so I'm wondering if we have a race
between omap_hsmmc, twl4030 card detect GPIO and I2C, but I'm not sure
yet.
> nasty) debug prints showing the problem:
>
> > [ 78.709381] omap_i2c omap_i2c.1: omap_i2c_isr_thread 913
> > [ 78.715026] omap_i2c omap_i2c.1: omap_i2c_isr_thread 1038
> > [ 78.720733] omap_i2c omap_i2c.1: omap_i2c_xfer 655
> > [ 78.725769] omap_i2c omap_i2c.1: omap_i2c_xfer 659
> > [ 78.730804] omap_i2c omap_i2c.1: omap_i2c_xfer 663
> > [ 78.735870] omap_i2c omap_i2c.1: omap_i2c_xfer 668
> > [ 78.850708] PM: suspend of devices complete after 1287.841 msecs
> > [ 78.860870] PM: late suspend of devices complete after 3.753 msecs
> > [ 78.872283] try_to_wake_up 1411
> > [ 78.875701] try_to_wake_up 1411
> > [ 78.879028] try_to_wake_up 1411
> > [ 78.882537] omap_i2c omap_i2c.1: omap_i2c_runtime_suspend 1359
> > [ 78.888763] omap_i2c omap_i2c.1: omap_i2c_low_level_suspend 1261
> > [ 78.895416] PM: noirq suspend of devices complete after 28.015 msecs
> > [ 78.902160] Disabling non-boot CPUs ...
> > [ 88.568664] Powerdomain (per_pwrdm) didn't enter target state 1
> > [ 88.574859] Powerdomain (core_pwrdm) didn't enter target state 1
> > [ 88.581115] Could not enter target state in pm_suspend
> > [ 88.586975] omap_i2c omap_i2c.1: omap_i2c_runtime_resume 1373
> > [ 88.592987] omap_i2c omap_i2c.1: omap_i2c_low_level_resume 1287
> > [ 88.599243] try_to_wake_up 1411
> > [ 88.602569] try_to_wake_up 1411
> > [ 88.608459] PM: noirq resume of devices complete after 21.759 msecs
> > [ 88.615814] try_to_wake_up 1411
> > [ 88.622497] PM: early resume of devices complete after 2.380 msecs
> > [ 88.632965] omap_i2c omap_i2c.1: omap_i2c_xfer 626
> > [ 88.638092] omap_i2c omap_i2c.1: omap_i2c_xfer 632
> > [ 88.643188] omap_i2c omap_i2c.1: omap_i2c_xfer 648
> > [ 88.648193] omap_i2c omap_i2c.1: addr: 0x0049, len: 4, flags: 0x0, stop: 1
> > [ 88.655456] omap_i2c omap_i2c.1: omap_i2c_xfer_msg 537
> > [ 88.660858] omap_i2c omap_i2c.1: omap_i2c_isr 885
> > [ 88.665802] omap_i2c omap_i2c.1: omap_i2c_isr 891: mask 601f stat 1510
> > [ 88.672637] omap_i2c omap_i2c.1: omap_i2c_isr 894
> > [ 88.677551] omap_i2c omap_i2c.1: omap_i2c_isr 899
> > [ 88.682495] ===> irq_wake_thread 139: IRQ 72 wake_up_process 1
> > [ 88.688751] omap_i2c omap_i2c.1: omap_i2c_isr_thread 913
> > [ 88.694335] omap_i2c omap_i2c.1: omap_i2c_isr_thread 1038
> > [ 88.700347] omap_i2c omap_i2c.1: omap_i2c_isr 885
> > [ 88.705291] omap_i2c omap_i2c.1: omap_i2c_isr 891: mask 601f stat 0104
> > [ 88.712097] omap_i2c omap_i2c.1: omap_i2c_isr 894
> > [ 88.717010] omap_i2c omap_i2c.1: omap_i2c_isr 899
> > [ 88.721923] try_to_wake_up 1411
> > [ 88.725189] ===> irq_wake_thread 139: IRQ 72 wake_up_process 0
> > [ 88.731292] [sched_delayed] sched: RT throttling activated
> > [ 88.737091] omap_i2c omap_i2c.1: omap_i2c_isr_thread 913
> > [ 88.742706] omap_i2c omap_i2c.1: omap_i2c_isr_thread 1038
>
> this is the last time our omap_i2c_isr_thread() runs. Note that the
> thread was already running when wake_up_process() was called.
>
> > [ 88.749206] omap_i2c omap_i2c.1: omap_i2c_xfer 655
> > [ 88.754302] omap_i2c omap_i2c.1: omap_i2c_xfer 659
> > [ 88.759368] omap_i2c omap_i2c.1: omap_i2c_xfer 663
> > [ 88.764373] omap_i2c omap_i2c.1: omap_i2c_xfer 668
> > [ 88.769531] omap_i2c omap_i2c.1: omap_i2c_xfer 626
> > [ 88.774597] omap_i2c omap_i2c.1: omap_i2c_xfer 632
> > [ 88.779602] omap_i2c omap_i2c.1: omap_i2c_xfer 648
> > [ 88.784667] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0
> > [ 88.791900] omap_i2c omap_i2c.1: omap_i2c_xfer_msg 537
> > [ 88.797271] omap_i2c omap_i2c.1: omap_i2c_isr 885
> > [ 88.802185] omap_i2c omap_i2c.1: omap_i2c_isr 891: mask 601f stat 1510
> > [ 88.809020] omap_i2c omap_i2c.1: omap_i2c_isr 894
> > [ 88.813934] omap_i2c omap_i2c.1: omap_i2c_isr 899
> > [ 88.818847] ===> irq_wake_thread 139: IRQ 72 wake_up_process 1
>
> notice here that our omap_i2c_isr_thread() never runs. I'm still
> debugging, trying to pin point what the real issue is, but it's
> definitely not the fact that we have a threaded ISR, since it runs at
> least once.
>
> > [ 90.610107] try_to_wake_up 1411
> > [ 93.821044] try_to_wake_up 1411
> > [ 93.824768] omap_i2c omap_i2c.1: controller timed out
> > [ 93.830169] [<c001c118>] (unwind_backtrace+0x0/0xf0) from [<c040c738>] (omap_i2c_xfer_msg+0x314/0x360)
> > [ 93.839935] [<c040c738>] (omap_i2c_xfer_msg+0x314/0x360) from [<c040d26c>] (omap_i2c_xfer+0xac/0x220)
> > [ 93.849639] [<c040d26c>] (omap_i2c_xfer+0xac/0x220) from [<c040884c>] (__i2c_transfer+0x40/0x80)
> > [ 93.858886] [<c040884c>] (__i2c_transfer+0x40/0x80) from [<c0409da8>] (i2c_transfer+0x1f8/0x26c)
> > [ 93.868103] [<c0409da8>] (i2c_transfer+0x1f8/0x26c) from [<c035dab8>] (twl_i2c_read+0xc4/0x15c)
> > [ 93.877288] [<c035dab8>] (twl_i2c_read+0xc4/0x15c) from [<c03189f4>] (twl4030ldo_get_voltage+0x28/0x60)
> > [ 93.887145] [<c03189f4>] (twl4030ldo_get_voltage+0x28/0x60) from [<c03120b0>] (_regulator_get_voltage+0x68/0x84)
> > [ 93.897827] [<c03120b0>] (_regulator_get_voltage+0x68/0x84) from [<c03125a0>] (regulator_get_voltage+0x20/0x38)
> > [ 93.908447] [<c03125a0>] (regulator_get_voltage+0x20/0x38) from [<c0411bcc>] (mmc_regulator_set_ocr+0x40/0x12c)
> > [ 93.919036] [<c0411bcc>] (mmc_regulator_set_ocr+0x40/0x12c) from [<c0426418>] (omap_hsmmc_set_power+0xe4/0x11c)
> > [ 93.929626] [<c0426418>] (omap_hsmmc_set_power+0xe4/0x11c) from [<c042582c>] (omap_hsmmc_set_ios+0x140/0x150)
> > [ 93.940032] [<c042582c>] (omap_hsmmc_set_ios+0x140/0x150) from [<c04135c4>] (mmc_power_up+0x80/0xc4)
> > [ 93.949615] [<c04135c4>] (mmc_power_up+0x80/0xc4) from [<c04136d8>] (mmc_resume_host+0xd0/0x150)
> > [ 93.958862] [<c04136d8>] (mmc_resume_host+0xd0/0x150) from [<c0426b5c>] (omap_hsmmc_resume+0x7c/0xc8)
> > [ 93.968536] [<c0426b5c>] (omap_hsmmc_resume+0x7c/0xc8) from [<c0347a78>] (platform_pm_resume+0x2c/0x50)
> > [ 93.978424] [<c0347a78>] (platform_pm_resume+0x2c/0x50) from [<c034bca4>] (dpm_run_callback.isra.4+0x2c/0x64)
> > [ 93.988830] [<c034bca4>] (dpm_run_callback.isra.4+0x2c/0x64) from [<c034ca48>] (device_resume+0xdc/0x18c)
> > [ 93.998870] [<c034ca48>] (device_resume+0xdc/0x18c) from [<c034ce8c>] (dpm_resume+0xfc/0x21c)
> > [ 94.007812] [<c034ce8c>] (dpm_resume+0xfc/0x21c) from [<c034d094>] (dpm_resume_end+0xc/0x18)
> > [ 94.016723] [<c034d094>] (dpm_resume_end+0xc/0x18) from [<c0087b14>] (suspend_devices_and_enter+0xe8/0x1b0)
> > [ 94.026947] [<c0087b14>] (suspend_devices_and_enter+0xe8/0x1b0) from [<c0087c78>] (enter_state+0x9c/0xdc)
> > [ 94.036987] [<c0087c78>] (enter_state+0x9c/0xdc) from [<c0087ccc>] (pm_suspend+0x14/0x70)
> > [ 94.045593] [<c0087ccc>] (pm_suspend+0x14/0x70) from [<c0086d34>] (state_store+0x30/0x3c)
> > [ 94.054199] [<c0086d34>] (state_store+0x30/0x3c) from [<c02d39b8>] (kobj_attr_store+0x14/0x20)
> > [ 94.063262] [<c02d39b8>] (kobj_attr_store+0x14/0x20) from [<c017bcd0>] (sysfs_write_file+0x80/0xb4)
> > [ 94.072784] [<c017bcd0>] (sysfs_write_file+0x80/0xb4) from [<c01174c4>] (vfs_write+0xa8/0x138)
> > [ 94.081817] [<c01174c4>] (vfs_write+0xa8/0x138) from [<c0117730>] (sys_write+0x40/0x68)
> > [ 94.090240] [<c0117730>] (sys_write+0x40/0x68) from [<c0013f40>] (ret_fast_syscall+0x0/0x3c)
> > [ 94.099334] omap_i2c omap_i2c.1: omap_i2c_xfer 655
> > [ 94.104431] omap_i2c omap_i2c.1: omap_i2c_xfer 659
> > [ 94.109466] omap_i2c omap_i2c.1: omap_i2c_xfer 663
> > [ 94.114532] omap_i2c omap_i2c.1: omap_i2c_xfer 668
> > [ 94.119567] twl: i2c_read failed to transfer all messages
> > [ 94.125244] omap_hsmmc omap_hsmmc.0: could not set regulator OCR (-110)
> > [ 94.286773] mmc0: error -110 during resume (card was removed?)
>
> --
> balbi
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121016/662a3e0b/attachment-0001.sig>
^ permalink raw reply
* [PATCH 1/4] leds: leds-ns2: add device tree binding
From: Simon Guinot @ 2012-10-16 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210161302.39302.arnd@arndb.de>
On Tue, Oct 16, 2012 at 01:02:39PM +0000, Arnd Bergmann wrote:
> On Monday 15 October 2012, Simon Guinot wrote:
> > diff --git a/Documentation/devicetree/bindings/gpio/leds-ns2.txt b/Documentation/devicetree/bindings/gpio/leds-ns2.txt
> > new file mode 100644
> > index 0000000..1a84969
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/gpio/leds-ns2.txt
> > @@ -0,0 +1,26 @@
> > +Binding for dual-GPIO LED found on Network Space v2 (and parents).
> > +
> > +Required properties:
> > +- compatible: "ns2-leds".
> > +
> > +Each LED is represented as a sub-node of the ns2-leds device.
> > +
> > +Required sub-node properties:
> > +- cmd-gpio: Command LED GPIO. See OF device-tree GPIO specification.
> > +- slow-gpio: Slow LED GPIO. See OF device-tree GPIO specification.
> > +
> > +Optional sub-node properties:
> > +- label: Name for this LED. If omitted, the label is taken from the node name.
> > +- linux,default-trigger: Trigger assigned to the LED.
>
> Hi Simon,
Hi Arnd,
>
> I'm not overly familiar with the LED subsystem, but isn't this something
> that could be done with the generic gpio-led driver?
Basically, the leds-gpio driver allows to associate one pin to one LED.
It is simple and efficient. The LED can be turned on or off. And using a
platform callback (gpio_blink_set), some hardware timer blink can be
enabled. A very few platforms are using this last callback.
On the ns2 (and other lacie machines), there is three different modes
for the front blue LED: on, off and SATA activity blink. Three different
pins are used to configure the LED. Definitively it is not compatible
with the leds-gpio driver.
>
> If not, is it possible to extend that driver in a way to make it possible
> and remove the leds-ns2 driver?
At the time I have written the leds-ns2 driver, I have failed to figure
out how to merge it with the leds-gpio driver. I remember I thought that
the best alternative was to add a new platform callback (maybe
sata_blink_set). It _should_ be possible to control "on" and "off" with
a single pin. The other pins could be contained inside the callback.
But there is a problem with this method. It is probably not DT
compliant. Add a new platform or machine hook doesn't fit very well with
the DT target on ARM. I mean remove the board setup files.
Please, let me know your advice.
Simon
>
> Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121016/e63b6c2c/attachment.sig>
^ permalink raw reply
* [Celinux-dev] PDF documentation
From: Bill Traynor @ 2012-10-16 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAE7jHC83biZy7TNYSr+-X85tpenqtAHuwSO47Q-6+XRF0fUxLA@mail.gmail.com>
On Tue, Oct 16, 2012 at 9:22 AM, Constantine Shulyupin
<const@makelinux.com> wrote:
> Hi,
>
> I have some questions and ideas about documentation in PDF format.
> During embedded SW development I often work with documentation,
> especially datasheets in PDF format. I have some issues with such
> documentation. It is not so easy to manage a lot of PDF documents
> sometimes with strange code in file names. It is not easy to store
> and share links to documentation.
> It is possible to reference to a PDF page in this way
> http://www.ti.com/lit/ds/symlink/omap4430.pdf#page=100 , but it slow
> and doesn?t work in all cases.
> Sometimes it is more easy just to copy paste and send by email part of
> documentation instead of using hyperlinks.
> I found, that it is more easy work (and work collaboratively) with
> documentation in HTML format. Sometimes it is possible just to convert
> PDF to HTML.
>
> Questions:
> - have same issues with PDF documentation and datasheets?
Yes, PDFs can be unwieldy. However, for a vendor, they provide an
immutable format that allows vendors to disseminate technical
information in one format, thereby decreasing their documentation
requirements.
> - do you think documentation and datasheets in HTML format on a site
> can be more useful than PDF?
Useful for some perhaps, but not universally useful. There just isn't
one perfect solution for datasheet documentation.
> - what PDF documentation do you use? (You can just drop a link to PDF,
> for example http://www.ti.com/lit/ds/symlink/omap4430.pdf)
http://beagleboard.org/static/beaglebone/latest/Docs/Hardware/BONE_SCH.pdf
etc. etc.
>
> --
> Constantine Shulyupin
> http://www.MakeLinux.com/
> Embedded Linux Systems,
> Device Drivers, TI DaVinci
> _______________________________________________
> Celinux-dev mailing list
> Celinux-dev at lists.celinuxforum.org
> https://lists.celinuxforum.org/mailman/listinfo/celinux-dev
^ permalink raw reply
* [git pull] signals pile 3
From: Uwe Kleine-König @ 2012-10-16 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121014231649.GO21164@n2100.arm.linux.org.uk>
Hello,
On Mon, Oct 15, 2012 at 12:16:49AM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 15, 2012 at 12:39:40AM +0200, Daniel Mack wrote:
> > Tested-by: Daniel Mack <zonque@gmail.com>
> >
> > Many thanks for the very prompt response!
>
> Thanks Daniel.
>
> I've also tested this on my OMAP4430 board running in ARM mode, so that
> still works - we've covered the possibilities between us here between
> ARM mode and Thumb mode, so...
>
> Linus, could you merge this patch please, thanks.
>
> 8<===
> From: Russell King <rmk+kernel@arm.linux.org.uk>
> Subject: [PATCH] ARM: fix oops on initial entry to userspace with Thumb2 kernels
>
> Daniel Mack reports an oops at boot with the latest kernels:
>
> [ 4.896717] Internal error: Oops - undefined instruction: 0 [#1] SMP THUMB2
> [ 4.904034] Modules linked in:
> [ 4.907253] CPU: 0 Not tainted (3.6.0-11057-g584df1d #145)
> [ 4.913372] PC is at cpsw_probe+0x45a/0x9ac
> [ 4.917760] LR is at trace_hardirqs_on_caller+0x8f/0xfc
> [ 4.923235] pc : [<c03493de>] lr : [<c005e81f>] psr: 60000113
> [ 4.923235] sp : cf055fb0 ip : 00000000 fp : 00000000
> [ 4.935246] r10: 00000000 r9 : 00000000 r8 : 00000000
> [ 4.940715] r7 : 00000000 r6 : 00000000 r5 : c0344555 r4 : 00000000
> [ 4.947548] r3 : cf057a40 r2 : 00000000 r1 : 00000001 r0 : 00000000
> [ 4.954383] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> [ 4.961853] Control: 50c5387d Table: 8f3f4019 DAC: 00000015
> [ 4.967868] Process init (pid: 1, stack limit = 0xcf054240)
> [ 4.973702] Stack: (0xcf055fb0 to 0xcf056000)
> [ 4.978269] 5fa0: 00000001 00000000 00000000 00000000
> [ 4.986836] 5fc0: cf055fb0 c000d1a8 00000000 00000000 00000000 00000000 00000000 00000000
> [ 4.995403] 5fe0: 00000000 be9b3f10 00000000 b6f6add0 00000010 00000000 aaaabfaf a8babbaa
>
> The analysis of this is as follows. In init/main.c, we issue:
>
> kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
>
> This creates a new thread, which falls through to the ret_from_fork
> assembly, with r4 set NULL and r5 set to kernel_init. You can see
> this in your oops dump register set - r5 is 0xc0344555, which is the
> address of kernel_init plus 1 which marks the function as Thumb code.
>
> Now, let's look at this code a little closer - this is what the
> disassembly looks like:
>
> c000d180 <ret_from_fork>:
> c000d180: f03a fe08 bl c0047d94 <schedule_tail>
> c000d184: 2d00 cmp r5, #0
> c000d186: bf1e ittt ne
> c000d188: 4620 movne r0, r4
> c000d18a: 46fe movne lr, pc <-- XXXXXXX
> c000d18c: 46af movne pc, r5
> c000d18e: 46e9 mov r9, sp
> c000d190: ea4f 3959 mov.w r9, r9, lsr #13
> c000d194: ea4f 3949 mov.w r9, r9, lsl #13
> c000d198: e7c8 b.n c000d12c <ret_to_user>
> c000d19a: bf00 nop
> c000d19c: f3af 8000 nop.w
>
> This code was introduced in 9fff2fa0db911 (arm: switch to saner
> kernel_execve() semantics). I have marked one instruction, and it's
> the significant one - I'll come back to that later.
>
> Eventually, having had a successful call to kernel_execve(), kernel_init()
> returns zero.
>
> In returning, it uses the value in 'lr' which was set by the instruction
> I marked above. Unfortunately, this causes lr to contain 0xc000d18e -
> an even address. This switches the ISA to ARM on return but with a non
> word aligned PC value.
>
> So, what do we end up executing? Well, not the instructions above - yes
> the opcodes, but they don't mean the same thing in ARM mode. In ARM mode,
> it looks like this instead:
>
> c000d18c: 46e946af strbtmi r4, [r9], pc, lsr #13
> c000d190: 3959ea4f ldmdbcc r9, {r0, r1, r2, r3, r6, r9, fp, sp, lr, pc}^
> c000d194: 3949ea4f stmdbcc r9, {r0, r1, r2, r3, r6, r9, fp, sp, lr, pc}^
> c000d198: bf00e7c8 svclt 0x0000e7c8
> c000d19c: 8000f3af andhi pc, r0, pc, lsr #7
> c000d1a0: e88db092 stm sp, {r1, r4, r7, ip, sp, pc}
> c000d1a4: 46e81fff ; <UNDEFINED> instruction: 0x46e81fff
> c000d1a8: 8a00f3ef bhi 0xc004a16c
> c000d1ac: 0a0cf08a beq 0xc03493dc
>
> I have included more above, because it's relevant. The PSR flags which we
> can see in the oops dump are nZCv, so Z and C are set.
>
> All the above ARM instructions are not executed, except for two. c000d1a0,
> which has no writeback, and writes below the current stack pointer (and
> that data is lost when we take the next exception.) The other instruction
> which is executed is c000d1ac, which takes us to... 0xc03493dc. However,
> remember that bit 1 of the PC got set. So that makes the PC value
> 0xc03493de.
>
> And that value is the value we find in the oops dump for PC. What is the
> instruction here when interpreted in ARM mode?
>
> 0: f71e150c ; <UNDEFINED> instruction: 0xf71e150c
>
> and there we have our undefined instruction (remember that the 'never'
> condition code, 0xf, has been deprecated and is now always executed as it
> is now being used for additional instructions.)
>
> This path also nicely explains the state of the stack we see in the oops
> dump too.
>
> The above is a consistent and sane story for how we got to the oops dump,
> which all stems from the instruction at 0xc000d18a being wrong.
>
> Reported-by: Daniel Mack <zonque@gmail.com>
> Tested-by: Daniel Mack <zonque@gmail.com>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch makes my Cortex-M3 boot again on v3.7-rc1. I did it slightly
different:
> ---
> arch/arm/kernel/entry-common.S | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
> index 417bac1..3471175 100644
> --- a/arch/arm/kernel/entry-common.S
> +++ b/arch/arm/kernel/entry-common.S
> @@ -88,9 +88,9 @@ ENTRY(ret_from_fork)
> bl schedule_tail
> cmp r5, #0
> movne r0, r4
> - movne lr, pc
> + adrne lr, BSYM(1f)
> movne pc, r5
> - get_thread_info tsk
> +1: get_thread_info tsk
> b ret_slow_syscall
I used:
movne r0, r4
- movne lr, pc
- movne pc, r5
+ blxne r5
get_thread_info tsk
but I assume Russell's patch is better. (Probably because blx doesn't
exist everywhere?!)
So if it's not too late yet:
Tested-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [git pull] signals pile 3
From: Russell King - ARM Linux @ 2012-10-16 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016140414.GS639@pengutronix.de>
On Tue, Oct 16, 2012 at 04:04:14PM +0200, Uwe Kleine-K?nig wrote:
> I used:
> movne r0, r4
> - movne lr, pc
> - movne pc, r5
> + blxne r5
> get_thread_info tsk
>
> but I assume Russell's patch is better. (Probably because blx doesn't
> exist everywhere?!)
Correct.
> So if it's not too late yet:
>
> Tested-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
It is, because it's already in Linus' tree.
^ permalink raw reply
* PDF documentation
From: Peter Stuge @ 2012-10-16 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAE7jHC83biZy7TNYSr+-X85tpenqtAHuwSO47Q-6+XRF0fUxLA@mail.gmail.com>
Constantine Shulyupin wrote:
> It is not so easy to manage a lot of PDF documents
> sometimes with strange code in file names.
I tend to rename them in some way that allows me to find them quickly
when I need them.
> It is not easy to store and share links to documentation.
Storing is easy, I just have a pdf folder. Sharing, well, they can be
committed to version control systems and they can be sent via email
or URLs can be shared when it is known that someone will in fact
receive the correct document version by using the URL. URLs are
temporal however, they frequently stop working as vendors re-organize
their web sites.
> Sometimes it is more easy just to copy paste and send by email part
> of documentation instead of using hyperlinks.
A group collaborating around a given hardware certainly needs a
common repository of documentation. A file server is often used
internally. I like to use wikis for public projects. They make it
easy to upload PDF files, references can be made to page
number+section.
> I found, that it is more easy work (and work collaboratively) with
> documentation in HTML format. Sometimes it is possible just to
> convert PDF to HTML.
I strongly prefer working with PDF because it is the canonical
documentation made available by the manufacturer and because my
PDF readers are much much better than my HTML readers.
> - have same issues with PDF documentation and datasheets?
Personally no.
> - do you think documentation and datasheets in HTML format on a
> site can be more useful than PDF?
Yes and no. I do like detailed information on a web site in the phase
of discovering a new product. Not many vendors provide detailed
technical information on web sites, because the web is so horribly
broken technology, and there are already well-established processes
for producing printed or PDF documentation. Those processes do not
translate 1:1 to web with useful results.
More useful for initial impression, yes, but under no circumstance do
I think HTML would be a good replacement for PDF. Already the fact
that PDF is self-contained but HTML is not should suggest that HTML
is a poor representation outside the web browser, for anything
really.
> - what PDF documentation do you use? (You can just drop a link to PDF,
> for example http://www.ti.com/lit/ds/symlink/omap4430.pdf)
I don't understand what you want to know. I have thousands of data
sheets for parts that I have used, use, or plan to use.
//Peter
^ permalink raw reply
* [PATCH] Revert "serial: omap: fix software flow control"
From: Felipe Balbi @ 2012-10-16 14:09 UTC (permalink / raw)
To: linux-arm-kernel
This reverts commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6
(serial: omap: fix software flow control).
As Russell has pointed out, that commit isn't fixing
Software Flow Control at all, and it actually makes
it even more broken.
It was agreed to revert this commit and use Russell's
latest UART patches instead.
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
Hi Greg,
you might prefer to do the revert yourself, in that case just
revert commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6.
thanks
arch/arm/plat-omap/include/plat/omap-serial.h | 4 ++--
drivers/tty/serial/omap-serial.c | 12 ++++++------
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
index f4a4cd0..1957a85 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -40,10 +40,10 @@
#define OMAP_UART_WER_MOD_WKUP 0X7F
/* Enable XON/XOFF flow control on output */
-#define OMAP_UART_SW_TX 0x8
+#define OMAP_UART_SW_TX 0x04
/* Enable XON/XOFF flow control on input */
-#define OMAP_UART_SW_RX 0x2
+#define OMAP_UART_SW_RX 0x04
#define OMAP_UART_SYSC_RESET 0X07
#define OMAP_UART_TCR_TRIG 0X0F
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 6ede6fd..6d3d26a 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -671,19 +671,19 @@ serial_omap_configure_xonxoff
/*
* IXON Flag:
- * Flow control for OMAP.TX
- * OMAP.RX should listen for XON/XOFF
+ * Enable XON/XOFF flow control on output.
+ * Transmit XON1, XOFF1
*/
if (termios->c_iflag & IXON)
- up->efr |= OMAP_UART_SW_RX;
+ up->efr |= OMAP_UART_SW_TX;
/*
* IXOFF Flag:
- * Flow control for OMAP.RX
- * OMAP.TX should send XON/XOFF
+ * Enable XON/XOFF flow control on input.
+ * Receiver compares XON1, XOFF1.
*/
if (termios->c_iflag & IXOFF)
- up->efr |= OMAP_UART_SW_TX;
+ up->efr |= OMAP_UART_SW_RX;
serial_out(up, UART_EFR, up->efr | UART_EFR_ECB);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
--
1.8.0.rc0
^ permalink raw reply related
* [Linaro-mm-sig] [RFC 0/2] DMA-mapping & IOMMU - physically contiguous allocations
From: Hiroshi Doyu @ 2012-10-16 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAQKjZNQFfxpr-7dFb4cgNB2Gkrxxrswds_fSrYgssxXaqRF7g@mail.gmail.com>
Hi Inki,
Inki Dae <inki.dae@samsung.com> wrote @ Tue, 16 Oct 2012 12:12:49 +0200:
> Hi Hiroshi,
>
> 2012/10/16 Hiroshi Doyu <hdoyu@nvidia.com>:
> > Hi Inki/Marek,
> >
> > On Tue, 16 Oct 2012 02:50:16 +0200
> > Inki Dae <inki.dae@samsung.com> wrote:
> >
> >> 2012/10/15 Marek Szyprowski <m.szyprowski@samsung.com>:
> >> > Hello,
> >> >
> >> > Some devices, which have IOMMU, for some use cases might require to
> >> > allocate a buffers for DMA which is contiguous in physical memory. Such
> >> > use cases appears for example in DRM subsystem when one wants to improve
> >> > performance or use secure buffer protection.
> >> >
> >> > I would like to ask if adding a new attribute, as proposed in this RFC
> >> > is a good idea? I feel that it might be an attribute just for a single
> >> > driver, but I would like to know your opinion. Should we look for other
> >> > solution?
> >> >
> >>
> >> In addition, currently we have worked dma-mapping-based iommu support
> >> for exynos drm driver with this patch set so this patch set has been
> >> tested with iommu enabled exynos drm driver and worked fine. actually,
> >> this feature is needed for secure mode such as TrustZone. in case of
> >> Exynos SoC, memory region for secure mode should be physically
> >> contiguous and also maybe OMAP but now dma-mapping framework doesn't
> >> guarantee physically continuous memory allocation so this patch set
> >> would make it possible.
> >
> > Agree that the contigous memory allocation is necessary for us too.
> >
> > In addition to those contiguous/discontiguous page allocation, is
> > there any way to _import_ anonymous pages allocated by a process to be
> > used in dma-mapping API later?
> >
> > I'm considering the following scenario, an user process allocates a
> > buffer by malloc() in advance, and then it asks some driver to convert
> > that buffer into IOMMU'able/DMA'able ones later. In this case, pages
> > are discouguous and even they may not be yet allocated at
> > malloc()/mmap().
> >
>
> I'm not sure I understand what you mean but we had already tried this
> way and for this, you can refer to below link,
> http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg22555.html
The above patch doesn't seem to have so much platform/SoC specific
code but rather it could common over other SoC as well. Is there any
plan to make it more generic, which can be used by other DRM drivers?
^ permalink raw reply
* [Celinux-dev] PDF documentation
From: Wolfgang Denk @ 2012-10-16 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAE7jHC83biZy7TNYSr+-X85tpenqtAHuwSO47Q-6+XRF0fUxLA@mail.gmail.com>
Dear Constantine Shulyupin,
In message <CAE7jHC83biZy7TNYSr+-X85tpenqtAHuwSO47Q-6+XRF0fUxLA@mail.gmail.com> you wrote:
>
> I have some questions and ideas about documentation in PDF format.
> During embedded SW development I often work with documentation,
> especially datasheets in PDF format. I have some issues with such
> documentation. It is not so easy to manage a lot of PDF documents
> sometimes with strange code in file names. It is not easy to store
> and share links to documentation.
PDF has a lot of advantages in many situations, but I agree that it is
also non-perfect for many other use cases.
> Questions:
> - have same issues with PDF documentation and datasheets?
> - do you think documentation and datasheets in HTML format on a site
> can be more useful than PDF?
HTML is really useful in a web browser only.
For documentation of the U-Boot boot loader we use a very different
approach: documentation is created, stored and edited in a wiki
(using FosWiki, see http://foswiki.org/). This has the advantage that
you can make it either easily editable to the community, or put
arbitrary access restrictions to it by using wiki user / group access
permissions. In combination with some plugins (like TocPlugin,
BookmakerPlugin and PublishPlugin) we can then "linearize" the entries
in the wiki to generate a "book" which can be read both online (as
HTML) or offline (by publishing the content as a linerarized, single
HTLP, plain text, PDF and/or PostScript document).
To give you a feeling how this works, please see for example
http://www.denx.de/wiki/view/DULG/Manual?stickboard=m28
http://www.denx.de/wiki/publish/DULG/DULG-m28.html
http://www.denx.de/wiki/publish/DULG/DULG-m28.ps
and http://www.denx.de/wiki/publish/DULG/DULG-m28.pdf
[Actually this documentation does much more behind the scenes; all
examples in this documentation come from include files which are
automatically generated from our regression test suite (DUTS); so the
procedure is to come up with a new software version, run the test
suite over it, upload the generated log files to the web server, and
voila, there is a new version of the documentation matching exactly
the new software version.]
And the nice thing is: all this is based on free software only...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
One difference between a man and a machine is that a machine is quiet
when well oiled.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox