Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 18 February 2015 at 22:14, Pali Rohár pali.ro...@gmail.com wrote: Can you help us with above problem? How to catch external abort on non-linefetch in kernel driver and prevent kernel panic? Actually it's a synchronous bus error that you want to catch, which however is misreported by linux as external abort on non-linefetch (... but a bus error on a linefetch would produce exactly the same error). Also, ARM apparently uses the term external abort as umbrella term for aborts triggered outside the MMU, which includes not just bus errors but also (uncorrectable) parity/ECC errors. Anyhow, the core question you mean to ask is: can the exception mechanism current already in place to trap MMU faults in e.g. put_user() easily be extended to allow drivers to trap synchronous bus errors? My impression is that this would in fact be quite easy and I even outlined a suggested patch, but I'm still a kernel newbie so I may be way off course. Although its main use would be for auto-probing, it's maybe worth mentioning I've met at least one peripheral which also reports bus errors when writing inappropriate/unsupported *values* to a register. (Of course when using posted writes you won't get an abort anyhow in that case, it's only reported via interconnect error logs.) On 19 February 2015 at 19:20, Pali Rohár pali.ro...@gmail.com wrote: Anyway, in Nokia Harmattan N9/N950 2.6.32 kernel is this patch In mainline linux the same fix-up is done at runtime rather than compile time (in exceptions_init() at the bottom of fault.c). Either way, in my post of the 11th I also mentioned that it looks wrong to me. I-cache maintenance fault is really a special case in the fault decoding logic since it means although you got here via DAbort and the relevant address is in DFAR, the exception happened on the instruction side so you need to fetch the fault status from IFSR instead. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: boot: dts: am437x-idk: fix sleep pinctrl state
we have i2c0 sleep pinctrl state but were passing
default state anyhow. Fix that.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am437x-idk-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am437x-idk-evm.dts
b/arch/arm/boot/dts/am437x-idk-evm.dts
index 22c2031dea17..378344271746 100644
--- a/arch/arm/boot/dts/am437x-idk-evm.dts
+++ b/arch/arm/boot/dts/am437x-idk-evm.dts
@@ -254,7 +254,7 @@
status = okay;
pinctrl-names = default, sleep;
pinctrl-0 = i2c0_pins_default;
- pinctrl-1 = i2c0_pins_default;
+ pinctrl-1 = i2c0_pins_sleep;
clock-frequency = 40;
at24@50 {
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: boot: dts: am437x-idk: enable i2c2
i2c2 goes to an expansion connector which we
want to use.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am437x-idk-evm.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-idk-evm.dts
b/arch/arm/boot/dts/am437x-idk-evm.dts
index 2471f1ebd4ed..22c2031dea17 100644
--- a/arch/arm/boot/dts/am437x-idk-evm.dts
+++ b/arch/arm/boot/dts/am437x-idk-evm.dts
@@ -133,6 +133,20 @@
;
};
+ i2c2_pins_default: i2c2_pins_default {
+ pinctrl-single,pins =
+ 0x1e8 (PIN_INPUT | SLEWCTRL_FAST | MUX_MODE3) /*
cam1_data1.i2c2_scl */
+ 0x1ec (PIN_INPUT | SLEWCTRL_FAST | MUX_MODE3) /*
cam1_data0.i2c2_sda */
+ ;
+ };
+
+ i2c2_pins_sleep: i2c2_pins_sleep {
+ pinctrl-single,pins =
+ 0x1e8 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x1ec (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ ;
+ };
+
mmc1_pins_default: pinmux_mmc1_pins_default {
pinctrl-single,pins =
0x100 (PIN_INPUT | MUX_MODE0) /* mmc0_clk.mmc0_clk */
@@ -263,6 +277,14 @@
};
};
+i2c2 {
+ status = okay;
+ pinctrl-names = default, sleep;
+ pinctrl-0 = i2c2_pins_default;
+ pinctrl-1 = i2c2_pins_sleep;
+ clock-frequency = 10;
+};
+
epwmss0 {
status = okay;
};
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] dtc: parser: Add label while overriding nodes
This patch changes the dtc grammar to allow following syntax
i2cexp: i2c2 {
...
};
Current device tree compiler allows to define multiple labels when defining
the device node the first time. Typically device nodes are defined in
DTSI files. Now these nodes can be overwritten for updating some of the
properties. Typically, device nodes are overridden in DTS files.
When working with adapter boards, most of the time adapter board can fit to
multiple base boards. But depending on which base board it is connected to,
the devices on the adapter board would be children of different devices.
e.g. On dra7-evm.dts, i2c2 is exported for expansion connector whereas
on dra72-evm.dts, i2c5 is exported for expansion connector.
This causes a problem when writing a generic device tree file for
the adapter board. Because, you cannot know whether all the devices on
adapter board are present on i2c or i2c5.
The problem can be solved by adding a common label (e.g. i2cexp) in both
of the DTS files when overriding the device nodes for i2c2 or i2c5.
This way, generic adapter board file would override the i2cexp. And
depending on which base board you use the adapter board, all the devices
are automatically added for correct device nodes.
Signed-off-by: Nikhil Devshatwar nikhil...@ti.com
---
dtc-parser.y | 12
tests/run_tests.sh |2 ++
tests/test_tree1_label_noderef.dts | 55
3 files changed, 69 insertions(+)
create mode 100644 tests/test_tree1_label_noderef.dts
diff --git a/dtc-parser.y b/dtc-parser.y
index ea57e0a..5a897e3 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -140,6 +140,18 @@ devicetree:
{
$$ = merge_nodes($1, $3);
}
+
+ | devicetree DT_LABEL DT_REF nodedef
+ {
+ struct node *target = get_node_by_ref($1, $3);
+
+ add_label(target-labels, $2);
+ if (target)
+ merge_nodes(target, $4);
+ else
+ ERROR(@3, Label or path %s not found, $3);
+ $$ = $1;
+ }
| devicetree DT_REF nodedef
{
struct node *target = get_node_by_ref($1, $2);
diff --git a/tests/run_tests.sh b/tests/run_tests.sh
index c5856d9..7c5f6ac 100755
--- a/tests/run_tests.sh
+++ b/tests/run_tests.sh
@@ -399,6 +399,8 @@ dtc_tests () {
tree1_tests dtc_tree1_merge.test.dtb test_tree1.dtb
run_dtc_test -I dts -O dtb -o dtc_tree1_merge_labelled.test.dtb
test_tree1_merge_labelled.dts
tree1_tests dtc_tree1_merge_labelled.test.dtb test_tree1.dtb
+run_dtc_test -I dts -O dtb -o dtc_tree1_label_noderef.test.dtb
test_tree1_label_noderef.dts
+tree1_tests dtc_tree1_label_noderef.test.dtb test_tree1.dtb
run_dtc_test -I dts -O dtb -o multilabel_merge.test.dtb
multilabel_merge.dts
run_test references multilabel.test.dtb
run_test dtbs_equal_ordered multilabel.test.dtb multilabel_merge.test.dtb
diff --git a/tests/test_tree1_label_noderef.dts
b/tests/test_tree1_label_noderef.dts
new file mode 100644
index 000..b2b194c
--- /dev/null
+++ b/tests/test_tree1_label_noderef.dts
@@ -0,0 +1,55 @@
+/dts-v1/;
+
+/memreserve/ 0xdeadbeef 0x10;
+/memreserve/ 123456789 01;
+
+/ {
+ compatible = test_tree1;
+ prop-int = 0xdeadbeef;
+ prop-int64 = /bits/ 64 0xdeadbeef01abcdef;
+ prop-str = hello world;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ subnode@1 {
+ compatible = subnode1;
+ reg = 1;
+ prop-int = [deadbeef];
+
+ subsubnode {
+ compatible = subsubnode1, subsubnode;
+ prop-int = 0xdeadbeef;
+ };
+
+ ss1 {
+ };
+ };
+
+ subnode@2 {
+ reg = 2;
+ linux,phandle = 0x2000;
+ prop-int = 123456789;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ ssn0: subsubnode@0 {
+ phandle = 0x2001;
+ prop-int = 0xbad;
+ };
+
+ ss2 {
+ };
+ };
+};
+
+/* Add label to a noderef */
+ssn1: ssn0 {
+ reg = 0;
+ prop-int = 123456789;
+};
+
+/* Use the new label for merging */
+ssn1 {
+ prop-int = 0726746425;
+ compatible = subsubnode2, subsubnode;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
advanced LED controllers
Hi, Do we have support for LED controllers which can handle patterns of different kinds ? I mean, currently, if we have an LED controller such as TPIC2810 [1] which can control 8 different leds and each LED corresponds to one bit on register 0x44, we could control leds by just playing a wave file on the controller and create easy patterns with that. AFAICT, in linux today we would have to register each of the 8 LEDs as a different LED and have driver magic to write the proper bits on register 0x44, that seems a bit overkill, specially when we want to make patterns: instead of writing 0xff we would have to write 0x80, 0x40, 0x20, 0x10, 0x08, 0x04, 0x02, 0x01 separately and have the driver cache the previous results so we don't end up switching off other LEDs. IOW, what could be handled with a single write, currently needs 8. I wonder if there's any work happening to support these slightly more inteligent LED engines. regards [1] http://www.ti.com/product/tpic2810 ps: tpic2810 is probably the simplest example, lp551, lp5523 and others have even more advanced pattern engines which can even handle RGB leds. Currently the driver loads patterns as if it was a firmware blob and registers each of R, G and B components as separate LEDs. Each component also has its own brightness controls (something tpic2810 doesn't have, it's either on or off). -- balbi signature.asc Description: Digital signature
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
Hi,
On Thu, Feb 19, 2015 at 07:20:41PM +0100, Pali Rohár wrote:
Anyway, in Nokia Harmattan N9/N950 2.6.32 kernel is this patch:
+/* Do we need runtime check ? */
+#if __LINUX_ARM_ARCH__ 6
{ do_bad, SIGBUS, 0, external abort on
linefetch },
+#else
+ { do_translation_fault, SIGSEGV, SEGV_MAPERR, I-cache maintenance
fault},
+#endif
Maybe it is related?
That was unrelated. Also, the patch is also in mainline,
see 8c0b742ca7a7d21de0ddc87eda6ef0b282e4de18 (ARM: 6134/1: Handle
instruction cache maintenance fault properly).
A.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
On Thursday 19 February 2015 05:50:48 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150218 15:58]: On Wednesday 18 February 2015 23:42:06 Tony Lindgren wrote: Of course it's always possible to do do a omap3-n900-qemu.dts if larger changes are needed :) I would like to avoid using separate DTS for qemu. When we have only one DTS file (for both qemu and real HW), we can test for regression in qemu and we are sure that we have same software configuration... Agreed, and I'd rather take the extra warning on rare to find hardware to avoid an etra .dts file. Are there any reasons whey the n900 qemu support could not be in the mainline qemu btw? Regards, Tony Missing lot of omap stuff (in mainline qemu) which linaro have not sent to mainline yet... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: Enabling DBGEN signal in GP OMAP3
On 19 February 2015 at 03:16, Grazvydas Ignotas nota...@gmail.com wrote: It turns out 050, 054 and 058 (but only them) are actually documented in dm3730 manual and are part of Emulation Pin Manager. 058 works as you (and the manual) describe, however claiming and enabling EPM registers still doesn't enable writing to 030 :( Ah, bummer. OK thanks for all the info. I've tested a spare floating pin by muxing it as a GPIO on my dm3730 and it works as you describe, nice. Hopefully this also applies to jtag pins there. At least on the am335x disabling RXEN of the TMS pin rendered JTAG inoperable, which means it looks like the technique will at least work there. I'm now working on a test to see if it really works. Once done it shouldn't be too hard to adapt to the dm37xx: the padconf registers are different obviously, but the bitbang sequence will be almost the same (just a different ICEPick register), at least if setting debug-enable on DAP's tap control register suffices. If it turns out you really need to write to the DAPCTL registers themselves via JTAG, that will be a bit more work... Ok, sounds like I need to find and get rid of that 10k resistor, or connect the pad to 1.8V. It's just a shame that there doesn't seem to be a way to do it purely in software so that other pandora users could have hardware watchpoints. You can solder-blob a path from nTRST to Vref via other input pads (which all need to be high, but they should already be pulled up anyway), as long as you avoid GND and the outputs (TDO and RTCK). Though I'm not sure that's a good idea considering it looks like there's a ground plane running between the pads... Anyhow, I'm currently testing just with nTRST connected to Vref, and TDO to some GPIO for monitoring. If you could share the programming sequence it would be great. Working on it! When you manage to get nTRST (and the other all relevant inputs: TMS, TDI, TCK) high, you can first try simple tests: (all this should be done by via INPUTENABLE of the pads): 1. nTRST low, TMS and TDI high, toggle TCK a bunch of times (at least five rising edges) and end with TCK low. 2. nTRST high, TMS low, and start toggling TCK. If all is well, sooner or later (possible right away), the processor's RTCK output should start following TCK. If this is the case, then you can pretty much start doing the victory-dance ;-) When you stop toggling, make sure you end with TCK low. 3. If you also want to see TDO in action, perform the following sequence: TMS high, one TCK pulse (high-low), TMS low again, and start toggling TCK: after two pulses the processor should start driving TDO and the 32-bit JTAG ID should emerge from it, after which TDO remains high. To exit data mode and return to idle state again, give two TCK pulses with TMS high. TDO will go high-Z again (after the first TCK pulse already in fact). 4. The final pin to test is TDI: repeat step 3, but occasionally change TDI in between clock pulses. JTAG uses shift registers for everything, so after outputting the 32-bit JTAG ID it will actually start repeating the input you provided, but with 32 cycles delay. When you exit data mode, the JTAG ID register will discard the data you provided. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: DRA7x/OMAP5: Clock: DPLL Clock fixes
On 1/31/2015 10:36 PM, Ravikumar Kattekola wrote: Fix bypass clock source for a few DPLLs. On DRA7x/OMAP5, for a few DPLLs, both CLKINP and CLKINPULOW are connected to a mux and the output from mux is routed to the bypass clkout. Add a mux-clock as bypass clock with CLKINP and CLKINPULOW as parents. Tested against: tree: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git branch: master On: CPU : OMAP5432 ES2.0 Board: OMAP5432 uEVM and CPU : DRA752 ES1.0 Board: DRA7xx Ravikumar Kattekola (2): ARM: DRA7x: dts: Fix the bypass clock source for dpll_iva and others ARM: OMAP5: dts: Fix the bypass clock source for dpll_iva and others arch/arm/boot/dts/dra7xx-clocks.dtsi | 90 arch/arm/boot/dts/omap54xx-clocks.dtsi | 41 +-- 2 files changed, 118 insertions(+), 13 deletions(-) Hi Benoit, Can these fixes be looked into for 3.20-rc? Regards, RK -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: omap: implement bus recovery
On Thu, Feb 19, 2015 at 12:06:49PM -0600, Felipe Balbi wrote:
If either SCL or SDA are stuck low, we need to
recover the bus using the procedure described
on section 3.1.16 of the I2C specification.
Note that we're trying to implement the procedure
exactly as described by that section. First we
check which line is stuck low, then implement
one or the other procedure. If SDA recovery procedure
fails, we reset our IP in an attempt to make it work.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Tested with AM437x IDK, AM437x SK, BeagleBoneBlack and Beagle X15 with
1000 iterations of i2cdetect on all available buses.
That said, I couldn't get any device to hold the bus busy so I could
see this working. If anybody has any good way of forcing a condition
so that we need bus recovery, I'd be glad to look at.
cheers
drivers/i2c/busses/i2c-omap.c | 71
+--
1 file changed, 69 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0e894193accf..c3e4da751adf 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -472,6 +472,73 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
return 0;
}
+static void omap_i2c_clock_pulse(struct omap_i2c_dev *dev)
+{
+ u32 reg;
+ int i;
+
+ /* Enable testmode */
+ reg = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
+ reg |= OMAP_I2C_SYSTEST_ST_EN;
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, reg);
+
+ for (i = 0; i 9; i++) {
+ reg |= OMAP_I2C_SYSTEST_SCL_O;
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, reg);
+ mdelay(100);
+ reg = ~OMAP_I2C_SYSTEST_SCL_O;
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, reg);
+ mdelay(100);
+ }
+
+ /* Disable testmode */
+ reg = ~OMAP_I2C_SYSTEST_ST_EN;
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, reg);
+}
+
+static void omap_i2c_bus_recover(struct omap_i2c_dev *dev)
+{
+ u32 reg1;
+ u32 reg2;
+
+ /*
+ * First differentiate SCL stuck low from SDA stuck low using our
+ * SYSTEST register. Depending on which line is stuck low, we will
+ * either Reset our I2C IP (SCL stuck low) or drive 9 clock pulses on
+ * SCL (SDA stuck low) to tell the device to release the bus.
+ *
+ * If, after 9 clock pulses on SCL device still doesn't release the
+ * bus, there's nothing more we can do; we will still try to Reset
+ * our I2C IP anyway.
+ */
+
+ reg1 = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
+ msleep(1);
Hmm... I wonder if this msleep() should be scaled based on i2c bus
frequency.
--
balbi
signature.asc
Description: Digital signature
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On Wednesday 11 February 2015 16:22:51 Matthijs van Duin wrote:
On 11 February 2015 at 13:39, Pali Rohár pali.ro...@gmail.com wrote:
Anyhow, since checking the firewalls/APs to see if you have
permission will probably only get you yet another fault if
things are walled off, the robust way of dealing with this
sort of situation is by probing the device with a read
while trapping bus faults. This also handles modules that
are unreachable for other reasons, e.g. being disabled by
eFuse.
It is possible to patch kernel code to mask or ignore that
fault? Can you help me with something like that?
As I mentioned, I'm still learning my way around the kernel,
so I don't feel very comfortable suggesting a concrete patch
just yet. I've been browsing arch/arm/mm/ however and my
impression is that all that would be required is editing
fault.c by making a copy of do_bad but containing
return user_mode(regs) || !fixup_exception(regs);
and hook it onto the appropriate fault codes. However, this
really needs the opinion of someone more familiar with this
code.
I do have an observation to make on the issue of fault
decoding: the list in fsr-2level.c may be standard ARMv3 and
ARMv4 aborts but they are quite wrong for ARMv7 which has:
[ 0] -
[ 1] alignment fault
[ 2] debug event
[ 3] section access flag fault
[ 4] instruction cache maintainance fault (reported via data
abort) [ 5] section translation fault
[ 6] page access flag fault
[ 7] page translation fault
[ 8] bus error on access
[ 9] section domain fault
[10] -
[11] page domain fault
[12] bus error on section table walk
[13] section permission fault
[14] bus error on page table walk
[15] page permission fault
[16] (TLB conflict abort)
[17] -
[18] -
[19] -
[20] (lockdown abort)
[21] -
[22] async bus error (reported via data abort)
[23] -
[24] async parity/ECC error (reported via data abort)
[25] parity/ECC error on access
[26] (coprocessor abort)
[27] -
[28] parity/ECC error on section table walk
[29] -
[30] parity/ECC error on page table walk
[31] -
Some entries are patched up near the bottom of fault.c but
many bogus messages remain, for example the on linefetch vs
on non-linefetch is misleading since no such thing can be
inferred from the fault status on v7. Also, the i-cache
maintenance fault handling looks wrong to me: it should fetch
the actual fault status from IFSR (even though the address
still comes from DFSR) and dispatch based on that.
Async external aborts (async bus error and async parity/ECC
error) give you basically no info. DFAR will contain garbage
hence displaying it will confuse rather than enlighten, a
traceback is pointless since the instruction that caused the
access is long retired, likewise user_mode() doesn't matter
since a transition to kernel space may have happened after
the access that cause the abort. Basically they should be
treated more as an IRQ than as a fault (note they can also be
masked just like irqs). In case of a bus error, it may be
appropriate to just warn about it, or perhaps send a signal
to the current process, although in the latter case it should
have some means to distinguish it from a synchronous bus
error.
At least on the cortex-a8, a parity/ECC error (whether async
or not) is to be regarded as absolutely fatal. Quoth the
TRM: No recovery is possible. The abort handler must disable
the caches, communicate the fail directly with the external
system, request a reboot.
Bit 10 no longer indicates an asynchronous (let alone
imprecise) fault. Apart from the debug events and async
aborts (and possibly some implementation-defined aborts), all
aborts listed are synchronous, and DFAR/IFAR is valid.
There's no technical obstruction to make these trappable via
the kernel exception handling mechanism. (Though at least in
case of parity/ECC errors one shouldn't.)
Anyway, in Nokia Harmattan N9/N950 2.6.32 kernel is this patch:
diff --git a/arch/arm/mm/fsr-2level.c b/arch/arm/mm/fsr-2level.c
index 18ca74c..d530d55 100644
--- a/arch/arm/mm/fsr-2level.c
+++ b/arch/arm/mm/fsr-2level.c
@@ -7,7 +7,12 @@ static struct fsr_info fsr_info[] = {
{ do_bad, SIGBUS, BUS_ADRALN,alignment exception
},
{ do_bad, SIGKILL, 0, terminal exception
},
{ do_bad, SIGBUS, BUS_ADRALN,alignment exception
},
+/* Do we need runtime check ? */
+#if __LINUX_ARM_ARCH__ 6
{ do_bad, SIGBUS, 0, external abort on
linefetch },
+#else
+ { do_translation_fault, SIGSEGV, SEGV_MAPERR, I-cache maintenance
fault},
+#endif
{ do_translation_fault, SIGSEGV, SEGV_MAPERR, section translation
fault},
{ do_bad, SIGBUS, 0, external abort on
linefetch },
{ do_page_fault,SIGSEGV, SEGV_MAPERR, page
[PATCH] i2c: omap: implement bus recovery
If either SCL or SDA are stuck low, we need to
recover the bus using the procedure described
on section 3.1.16 of the I2C specification.
Note that we're trying to implement the procedure
exactly as described by that section. First we
check which line is stuck low, then implement
one or the other procedure. If SDA recovery procedure
fails, we reset our IP in an attempt to make it work.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Tested with AM437x IDK, AM437x SK, BeagleBoneBlack and Beagle X15 with
1000 iterations of i2cdetect on all available buses.
That said, I couldn't get any device to hold the bus busy so I could
see this working. If anybody has any good way of forcing a condition
so that we need bus recovery, I'd be glad to look at.
cheers
drivers/i2c/busses/i2c-omap.c | 71 +--
1 file changed, 69 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0e894193accf..c3e4da751adf 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -472,6 +472,73 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
return 0;
}
+static void omap_i2c_clock_pulse(struct omap_i2c_dev *dev)
+{
+ u32 reg;
+ int i;
+
+ /* Enable testmode */
+ reg = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
+ reg |= OMAP_I2C_SYSTEST_ST_EN;
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, reg);
+
+ for (i = 0; i 9; i++) {
+ reg |= OMAP_I2C_SYSTEST_SCL_O;
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, reg);
+ mdelay(100);
+ reg = ~OMAP_I2C_SYSTEST_SCL_O;
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, reg);
+ mdelay(100);
+ }
+
+ /* Disable testmode */
+ reg = ~OMAP_I2C_SYSTEST_ST_EN;
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, reg);
+}
+
+static void omap_i2c_bus_recover(struct omap_i2c_dev *dev)
+{
+ u32 reg1;
+ u32 reg2;
+
+ /*
+* First differentiate SCL stuck low from SDA stuck low using our
+* SYSTEST register. Depending on which line is stuck low, we will
+* either Reset our I2C IP (SCL stuck low) or drive 9 clock pulses on
+* SCL (SDA stuck low) to tell the device to release the bus.
+*
+* If, after 9 clock pulses on SCL device still doesn't release the
+* bus, there's nothing more we can do; we will still try to Reset
+* our I2C IP anyway.
+*/
+
+ reg1 = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
+ msleep(1);
+ reg2 = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
+
+ if (!(reg1 OMAP_I2C_SYSTEST_SCL_I_FUNC)
+ !(reg2 OMAP_I2C_SYSTEST_SCL_I_FUNC)) {
+ dev_err(dev-dev, SCL is stuck low, resetting\n);
+ omap_i2c_reset(dev);
+ }
+
+ if (!(reg1 OMAP_I2C_SYSTEST_SDA_I_FUNC)
+ !(reg2 OMAP_I2C_SYSTEST_SDA_I_FUNC)) {
+ dev_err(dev-dev, SDA is stuck low, driving 9 pulses on
SCL\n);
+ omap_i2c_clock_pulse(dev);
+
+ reg1 = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
+ msleep(1);
+ reg2 = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
+
+ if ((reg1 OMAP_I2C_SYSTEST_SDA_I_FUNC)
+ (reg2 OMAP_I2C_SYSTEST_SDA_I_FUNC)) {
+ dev_err(dev-dev, SDA still stuck, resetting\n);
+ omap_i2c_reset(dev);
+ }
+ }
+}
+
/*
* Waiting on Bus Busy
*/
@@ -482,8 +549,8 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
timeout = jiffies + OMAP_I2C_TIMEOUT;
while (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG) OMAP_I2C_STAT_BB) {
if (time_after(jiffies, timeout)) {
- dev_warn(dev-dev, timeout waiting for bus ready\n);
- return -ETIMEDOUT;
+ omap_i2c_bus_recover(dev);
+ return 0;
}
msleep(1);
}
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] arm: boot: dts: am437x-idk: fix TPS62362 i2c bus
As it turns out, tps62362 is actually on I2C bus0,
not bus1. This has gone unnoticed because Linux
doesn't use (as of now) that regulator at all, it's
setup by the bootloader and left as is.
While at that, also add missing reg property for
our regulator.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am437x-idk-evm.dts | 23 +--
1 file changed, 1 insertion(+), 22 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-idk-evm.dts
b/arch/arm/boot/dts/am437x-idk-evm.dts
index f9a17e2ca8cb..2471f1ebd4ed 100644
--- a/arch/arm/boot/dts/am437x-idk-evm.dts
+++ b/arch/arm/boot/dts/am437x-idk-evm.dts
@@ -133,20 +133,6 @@
;
};
- i2c1_pins_default: i2c1_pins_default {
- pinctrl-single,pins =
- 0x15c (PIN_INPUT | SLEWCTRL_FAST | MUX_MODE2) /*
spi0_cs0.i2c1_scl */
- 0x158 (PIN_INPUT | SLEWCTRL_FAST | MUX_MODE2) /*
spi0_d1.i2c1_sda */
- ;
- };
-
- i2c1_pins_sleep: i2c1_pins_sleep {
- pinctrl-single,pins =
- 0x15c (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
spi0_cs0.i2c1_scl */
- 0x158 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
spi0_d1.i2c1_sda */
- ;
- };
-
mmc1_pins_default: pinmux_mmc1_pins_default {
pinctrl-single,pins =
0x100 (PIN_INPUT | MUX_MODE0) /* mmc0_clk.mmc0_clk */
@@ -262,17 +248,10 @@
pagesize = 64;
reg = 0x50;
};
-};
-
-i2c1 {
- status = okay;
- pinctrl-names = default, sleep;
- pinctrl-0 = i2c1_pins_default;
- pinctrl-1 = i2c1_pins_default;
- clock-frequency = 40;
tps: tps62362@60 {
compatible = ti,tps62362;
+ reg = 0x60;
regulator-name = VDD_MPU;
regulator-min-microvolt = 95;
regulator-max-microvolt = 133;
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] arm: configs: omap2plus_defconfig: enable TPS62362 regulator
This regulator is used on AM437x Industrial Development Kit. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/configs/omap2plus_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index b7386524c356..8ff1a988c0f4 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -248,6 +248,7 @@ CONFIG_TWL6040_CORE=y CONFIG_REGULATOR_PALMAS=y CONFIG_REGULATOR_PBIAS=y CONFIG_REGULATOR_TI_ABB=y +CONFIG_REGULATOR_TPS62360=m CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y CONFIG_REGULATOR_TPS65217=y -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances
Quoting Stephen Boyd (2015-02-06 11:30:18)
On 02/06/15 05:39, Russell King - ARM Linux wrote:
On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
From what I can tell this code is
now broken because we made all clk getting functions (there's quite a
few...) return unique pointers every time they're called. It seems that
the driver wants to know if extclk and clk are the same so it can do
something differently in kirkwood_set_rate(). Do we need some sort of
clk_equal(struct clk *a, struct clk *b) function for drivers like this?
Well, the clocks in question are the SoC internal clock (which is more or
less fixed, but has a programmable divider) and an externally supplied
clock, and the IP has a multiplexer on its input which allows us to select
between those two sources.
If it were possible to bind both to the same clock, it wouldn't be a
useful configuration - nothing would be gained from doing so in terms of
available rates.
What the comparison is there for is to catch the case with legacy lookups
where a clkdev lookup entry with a NULL connection ID results in matching
any connection ID passed to clk_get(). If the patch changes this, then
we will have a regression - and this is something which needs fixing
_before_ we do this return unique clocks.
Ok. It seems that we might need a clk_equal() or similar API after all.
My understanding is that this driver is calling clk_get() twice with
NULL for the con_id and then extclk in attempts to get the SoC
internal clock and the externally supplied clock. If we're using legacy
lookups then both clk_get() calls may map to the same clk_lookup entry
and before Tomeu's patch that returns unique clocks the driver could
detect this case and know that there isn't an external clock. Looking at
arch/arm/mach-dove/common.c it seems that there is only one lookup per
device and it has a wildcard NULL for con_id so both clk_get() calls
here are going to find the same lookup and get a unique struct clk pointer.
Why don't we make the legacy lookup more specific and actually indicate
internal for the con_id? Then the external clock would fail to be
found, but we can detect that case and figure out that it's not due to
probe defer, but instead due to the fact that there really isn't any
mapping. It looks like the code is already prepared for this anyway.
8
From: Stephen Boyd sb...@codeaurora.org
Subject: [PATCH] ARM: dove: Remove wildcard from mvebu-audio device clk lookup
This i2s driver is using the wildcard nature of clkdev lookups to
figure out if there's an external clock or not. It does this by
calling clk_get() twice with NULL for the con_id first and then
external for the con_id the second time around and then
compares the two pointers. With DT the wildcard feature of
clk_get() is gone and so the driver has to handle an error from
the second clk_get() call as meaning no external clock
specified. Let's use that logic even with clk lookups to
simplify the code and remove the struct clk pointer comparisons
which may not work in the future when clk_get() returns unique
pointers.
Signed-off-by: Stephen Boyd sb...@codeaurora.org
Russell et al,
I'm happy to take this patch through the clock tree (where the problem
shows up) with an ack.
Regards,
Mike
---
arch/arm/mach-dove/common.c | 4 ++--
sound/soc/kirkwood/kirkwood-i2s.c | 13 -
2 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
index 0d1a89298ece..f290fc944cc1 100644
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-dove/common.c
@@ -124,8 +124,8 @@ static void __init dove_clk_init(void)
orion_clkdev_add(NULL, sdhci-dove.1, sdio1);
orion_clkdev_add(NULL, orion_nand, nand);
orion_clkdev_add(NULL, cafe1000-ccic.0, camera);
- orion_clkdev_add(NULL, mvebu-audio.0, i2s0);
- orion_clkdev_add(NULL, mvebu-audio.1, i2s1);
+ orion_clkdev_add(internal, mvebu-audio.0, i2s0);
+ orion_clkdev_add(internal, mvebu-audio.1, i2s1);
orion_clkdev_add(NULL, mv_crypto, crypto);
orion_clkdev_add(NULL, dove-ac97, ac97);
orion_clkdev_add(NULL, dove-pdma, pdma);
diff --git a/sound/soc/kirkwood/kirkwood-i2s.c
b/sound/soc/kirkwood/kirkwood-i2s.c
index def7d8260c4e..0bfeb712a997 100644
--- a/sound/soc/kirkwood/kirkwood-i2s.c
+++ b/sound/soc/kirkwood/kirkwood-i2s.c
@@ -564,7 +564,7 @@ static int kirkwood_i2s_dev_probe(struct platform_device
*pdev)
return -EINVAL;
}
- priv-clk = devm_clk_get(pdev-dev, np ? internal : NULL);
+ priv-clk = devm_clk_get(pdev-dev, internal);
if (IS_ERR(priv-clk)) {
dev_err(pdev-dev, no clock\n);
return PTR_ERR(priv-clk);
@@ -579,14 +579,9 @@ static int kirkwood_i2s_dev_probe(struct platform_device
*pdev)
if
Re: [PATCH v2 1/3] ARM: dts: omap3-pandora: add common device tree
On Tue, Feb 17, 2015 at 9:52 PM, Marek Belisko ma...@goldelico.com wrote:
From: H. Nikolaus Schaller h...@goldelico.com
This device tree allows to boot, supports the panel,
framebuffer, touch screen, as well as some more peripherals.
Since there is a OMAP3530 based 600 MHz variant and a DM3730 based
1 GHz variant we must include this common device tree code
in one of two CPU specific device trees.
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
Signed-off-by: Marek Belisko ma...@goldelico.com
---
arch/arm/boot/dts/omap3-pandora-common.dtsi | 640
1 file changed, 640 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-pandora-common.dtsi
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
new file mode 100644
index 000..78ef1ee
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
...
+
+ penirq_pins: pinmux_penirq_pins {
+ pinctrl-single,pins =
+ /* here we could enable to wakeup the cpu from
suspend by a pen touch */
+ OMAP3_CORE1_IOPAD(0x210c, MUX_MODE4)/* GPIO_94 */
We need PIN_INPUT here, otherwise the touchscreen doesn't react to pen down.
(Sorry missed it last time).
Gražvydas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] omap-rng: Change RNG_CONFIG_REG to RNG_CONTROL_REG when, checking and disabling TRNG
In omap4_rng_init(), a check of bit 10 of the RNG_CONFIG_REG is done to determine whether the RNG is running. This is suspicious firstly due to the use of RNG_CONTROL_ENABLE_TRNG_MASK and secondly because the same mask is written to RNG_CONTROL_REG after configuration of the FROs. Similar suspicious logic is repeated in omap4_rng_cleanup() when RNG_CONTROL_REG masked with RNG_CONTROL_ENABLE_TRNG_MASK is read, the same mask bit is cleared, and then written to RNG_CONFIG_REG. Unless the TRNG is enabled with one bit in RNG_CONTROL and disabled with another in RNG_CONFIG and these bits are mirrored in some way, I believe that the TRNG is not really shutting off, leaving the FROs running indefinitely which, in an extreme case, could lead to degredation of the hardware and potentially reduce the level of entropy generated. Apart from the strange logic, I have reason to suspect that the OMAP4 related code in this driver is driving an Inside Secure IP hardware RNG and strongly suspect that bit 10 of RNG_CONFIG_REG is one of the bits configuring the sampling rate of the FROs. This option is by default set to 0 and is not being set anywhere in omap-rng.c. Reading this bit during omap4_rng_init() will always return 0. It will remain 0 because ~(value of TRNG_MASK in control) will always be 0, because the TRNG is never shut off. This is of course presuming that the OMAP4 features the Inside Secure IP, which I strongly suspect. I'm interested in knowing what the guys at TI think about this, as only they can confirm or deny the detailed structure of these registers. Signed-off-by: Andre Wolokita andre.wolok...@analog.com --- drivers/char/hw_random/omap-rng.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c index d14dcf7..67151cb 100644 --- a/drivers/char/hw_random/omap-rng.c +++ b/drivers/char/hw_random/omap-rng.c @@ -236,7 +236,7 @@ static int omap4_rng_init(struct omap_rng_dev *priv) u32 val; /* Return if RNG is already running. */ - if (omap_rng_read(priv, RNG_CONFIG_REG) RNG_CONTROL_ENABLE_TRNG_MASK) + if (omap_rng_read(priv, RNG_CONTROL_REG) RNG_CONTROL_ENABLE_TRNG_MASK) return 0; val = RNG_CONFIG_MIN_REFIL_CYCLES RNG_CONFIG_MIN_REFIL_CYCLES_SHIFT; @@ -262,7 +262,7 @@ static void omap4_rng_cleanup(struct omap_rng_dev *priv) val = omap_rng_read(priv, RNG_CONTROL_REG); val = ~RNG_CONTROL_ENABLE_TRNG_MASK; - omap_rng_write(priv, RNG_CONFIG_REG, val); + omap_rng_write(priv, RNG_CONTROL_REG, val); } static irqreturn_t omap4_rng_irq(int irq, void *dev_id) -- 1.7.9.5 -- Andre Wolokita (andre.wolok...@analog.com) Design Engineer, Analog Devices Australia Pty Ltd Unit 3, 97 Lewis Road, Wantirna, Victoria, 3152, AUSTRALIA Direct: +61 3 9881 9933 Main: +61 3 9881 Fax: +61 3 9881 9988 Web: www.analog.com/au Embedded DSP software for multimedia telecommunications. This communication is proprietary and confidential. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
On Wednesday 18 February 2015 23:42:06 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150218 11:07]: On Wednesday 18 February 2015 17:33:53 Tony Lindgren wrote: */ +// reg = 1 0x300 0xf;/* 16 byte IO range at offset 0x300 */ + reg = 1 0x0 0xf; /* 16 byte IO range at offset 0x300 */ bank-width = 2; pinctrl-names = default; pinctrl-0 = ethernet_pins; Oh cool, the 0x300 offset is there mostly to suppress warnings about non-standard location. ... OK that's good news. Care to do a patch to set the offset 0x0 with added comment that qemu needs it? I'll test to make sure it works on the real hardware as well. Yes, I can send proper git format-patch, but first let me know if that change does not break your HW... Yes using reg = 1 0 0xf works, it just adds this extra warning: smc91x 200.ethernet (unnamed net_device) (uninitialized): smc91x: IOADDR d09d6000 doesn't match configuration (300). And I'm pretty sure that can be fixed by setting the EEPROM offset to 0 instead of the default 0x300. People with smc91x most likely want to write at least the MAC address to the EEPROM, so might as well set the offset to zero then too. Of course it's always possible to do do a omap3-n900-qemu.dts if larger changes are needed :) Regards, Tony Anyway, here are original Nokia board data (2.6.28) for smc91x ethernet: https://gitorious.org/linux-n900/linux-n900/source/629fc5ab00cafb31272c478efa2c2b35fabd4c70:arch/arm/mach-omap2/board-rx51-peripherals.c#L42 https://gitorious.org/linux-n900/linux-n900/source/629fc5ab00cafb31272c478efa2c2b35fabd4c70:arch/arm/mach-omap2/board-rx51-peripherals.c#L274 Can you check if it match with our data in DT file? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
[PATCH] ARM: dts: OMAP3-N900: Fix offset for smc91x ethernet
Offset for smc91x must be zero otherwise smc91x linux kernel driver does not detect smc91x ethernet hardware in qemu N900 machine. Signed-off-by: Pali Rohár pali.ro...@gmail.com --- arch/arm/boot/dts/omap3-n900.dts |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts index ff36fbe..b9c1c62 100644 --- a/arch/arm/boot/dts/omap3-n900.dts +++ b/arch/arm/boot/dts/omap3-n900.dts @@ -770,7 +770,7 @@ compatible = smsc,lan91c94; interrupt-parent = gpio2; interrupts = 22 IRQ_TYPE_LEVEL_HIGH; /* gpio54 */ - reg = 1 0x300 0xf;/* 16 byte IO range at offset 0x300 */ + reg = 1 0x0 0xf; /* 16 byte IO range */ bank-width = 2; pinctrl-names = default; pinctrl-0 = ethernet_pins; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: Return correct error values from device and hwmod
Without this patch function pm_runtime_get_sync() returns 0 even when some
omap subfunction fails. This patch properly propagate error codes from omap
functions back to caller.
This patch fix problem, when loading omap-aes driver in qemu cause kernel oops.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/mach-omap2/omap_device.c | 30 +-
arch/arm/mach-omap2/omap_hwmod.c | 20
2 files changed, 29 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index be9541e..9fd47a9 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -224,13 +224,13 @@ static int _omap_device_notifier_call(struct
notifier_block *nb,
*/
static int _omap_device_enable_hwmods(struct omap_device *od)
{
+ int ret = 0;
int i;
for (i = 0; i od-hwmods_cnt; i++)
- omap_hwmod_enable(od-hwmods[i]);
+ ret |= omap_hwmod_enable(od-hwmods[i]);
- /* XXX pass along return value here? */
- return 0;
+ return ret;
}
/**
@@ -241,13 +241,13 @@ static int _omap_device_enable_hwmods(struct omap_device
*od)
*/
static int _omap_device_idle_hwmods(struct omap_device *od)
{
+ int ret = 0;
int i;
for (i = 0; i od-hwmods_cnt; i++)
- omap_hwmod_idle(od-hwmods[i]);
+ ret |= omap_hwmod_idle(od-hwmods[i]);
- /* XXX pass along return value here? */
- return 0;
+ return ret;
}
/* Public functions for use by core code */
@@ -595,18 +595,20 @@ static int _od_runtime_suspend(struct device *dev)
int ret;
ret = pm_generic_runtime_suspend(dev);
+ if (ret)
+ return ret;
- if (!ret)
- omap_device_idle(pdev);
-
- return ret;
+ return omap_device_idle(pdev);
}
static int _od_runtime_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
+ int ret;
- omap_device_enable(pdev);
+ ret = omap_device_enable(pdev);
+ if (ret)
+ return ret;
return pm_generic_runtime_resume(dev);
}
@@ -740,7 +742,8 @@ int omap_device_enable(struct platform_device *pdev)
ret = _omap_device_enable_hwmods(od);
- od-_state = OMAP_DEVICE_STATE_ENABLED;
+ if (ret == 0)
+ od-_state = OMAP_DEVICE_STATE_ENABLED;
return ret;
}
@@ -770,7 +773,8 @@ int omap_device_idle(struct platform_device *pdev)
ret = _omap_device_idle_hwmods(od);
- od-_state = OMAP_DEVICE_STATE_IDLE;
+ if (ret == 0)
+ od-_state = OMAP_DEVICE_STATE_IDLE;
return ret;
}
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index cbb908d..2ce4f39 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3350,16 +3350,17 @@ int omap_hwmod_enable(struct omap_hwmod *oh)
*/
int omap_hwmod_idle(struct omap_hwmod *oh)
{
+ int r;
unsigned long flags;
if (!oh)
return -EINVAL;
spin_lock_irqsave(oh-_lock, flags);
- _idle(oh);
+ r = _idle(oh);
spin_unlock_irqrestore(oh-_lock, flags);
- return 0;
+ return r;
}
/**
@@ -3372,16 +3373,17 @@ int omap_hwmod_idle(struct omap_hwmod *oh)
*/
int omap_hwmod_shutdown(struct omap_hwmod *oh)
{
+ int r;
unsigned long flags;
if (!oh)
return -EINVAL;
spin_lock_irqsave(oh-_lock, flags);
- _shutdown(oh);
+ r = _shutdown(oh);
spin_unlock_irqrestore(oh-_lock, flags);
- return 0;
+ return r;
}
/**
@@ -3392,13 +3394,14 @@ int omap_hwmod_shutdown(struct omap_hwmod *oh)
*/
int omap_hwmod_enable_clocks(struct omap_hwmod *oh)
{
+ int r;
unsigned long flags;
spin_lock_irqsave(oh-_lock, flags);
- _enable_clocks(oh);
+ r = _enable_clocks(oh);
spin_unlock_irqrestore(oh-_lock, flags);
- return 0;
+ return r;
}
/**
@@ -3409,13 +3412,14 @@ int omap_hwmod_enable_clocks(struct omap_hwmod *oh)
*/
int omap_hwmod_disable_clocks(struct omap_hwmod *oh)
{
+ int r;
unsigned long flags;
spin_lock_irqsave(oh-_lock, flags);
- _disable_clocks(oh);
+ r = _disable_clocks(oh);
spin_unlock_irqrestore(oh-_lock, flags);
- return 0;
+ return r;
}
/**
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v3.19: Nokia N900 (qemu) - omap_aes error
On Wednesday 18 February 2015 22:36:41 Pali Rohár wrote: On Monday 09 February 2015 12:25:00 Pali Rohár wrote: On Saturday 31 January 2015 16:29:36 Pali Rohár wrote: Hello, when I enable problematic omap_aes.ko driver (also in DT) for Nokia N900 machine in qemu (it emulates OMAP GP device, not HS) I get this error message in dmesg at modprobe time: [ 37.660339] [ cut here ] [ 37.663940] WARNING: CPU: 0 PID: 173 at arch/arm/mach- omap2/omap_hwmod.c:2182 _idle+0x28/0x64() [ 37.668762] omap_hwmod: aes: idle state can only be entered from enabled state [ 37.672271] Modules linked in: omap_aes(+) [ 37.675933] CPU: 0 PID: 173 Comm: modprobe Not tainted 3.19.0- rc5+ #299 [ 37.679534] Hardware name: Nokia RX-51 board [ 37.683227] [c0012678] (unwind_backtrace) from [c0010d44] (show_stack+0x10/0x14) [ 37.686920] [c0010d44] (show_stack) from [c0032194] (warn_slowpath_common+0x84/0xac) [ 37.690765] [c0032194] (warn_slowpath_common) from [c003223c] (warn_slowpath_fmt+0x2c/0x3c) [ 37.694366] [c003223c] (warn_slowpath_fmt) from [c0020cb0] (_idle+0x28/0x64) [ 37.698791] [c0020cb0] (_idle) from [c0021078] (omap_hwmod_idle+0x30/0x78) [ 37.702636] [c0021078] (omap_hwmod_idle) from [c00222c4] (omap_device_idle+0x48/0x6c) [ 37.707153] [c00222c4] (omap_device_idle) from [c0022304] (_od_runtime_suspend+0x1c/0x24) [ 37.710723] [c0022304] (_od_runtime_suspend) from [c0269680] (__rpm_callback+0x8c/0xdc) [ 37.714385] [c0269680] (__rpm_callback) from [c0269740] (rpm_callback+0x70/0x88) [ 37.717987] [c0269740] (rpm_callback) from [c0269f74] (rpm_suspend+0x2e8/0x5a4) [ 37.721710] [c0269f74] (rpm_suspend) from [c026a6ec] (__pm_runtime_idle+0x58/0x9c) [ 37.725402] [c026a6ec] (__pm_runtime_idle) from [bf00129c] (omap_aes_probe+0x15c/0x448 [omap_aes]) [ 37.733489] [bf00129c] (omap_aes_probe [omap_aes]) from [c0263d78] (platform_drv_probe+0x48/0x90) [ 37.740936] [c0263d78] (platform_drv_probe) from [c02624ec] (really_probe+0xac/0x1e0) [ 37.745025] [c02624ec] (really_probe) from [c0262718] (driver_probe_device+0x30/0x48) [ 37.749847] [c0262718] (driver_probe_device) from [c0262790] (__driver_attach+0x60/0x84) [ 37.753601] [c0262790] (__driver_attach) from [c0261070] (bus_for_each_dev+0x50/0x84) [ 37.758422] [c0261070] (bus_for_each_dev) from [c0261e20] (bus_add_driver+0xac/0x1bc) [ 37.762207] [c0261e20] (bus_add_driver) from [c02630c8] (driver_register+0x9c/0xe0) [ 37.765899] [c02630c8] (driver_register) from [c0008798] (do_one_initcall+0x100/0x1b0) [ 37.769653] [c0008798] (do_one_initcall) from [c0085ca4] (do_init_module+0x34/0x158) [ 37.773590] [c0085ca4] (do_init_module) from [c00868d8] (SyS_init_module+0x54/0x64) [ 37.777252] [c00868d8] (SyS_init_module) from [c000dbe0] (ret_fast_syscall+0x0/0x30) [ 37.780975] ---[ end trace 86c3e025b92e700d ]--- [ 37.784667] omap-aes 480c5000.aes: OMAP AES hw accel rev: 0.0 [ 37.789794] of_dma_request_slave_channel: dma-names property of node '/ocp/aes@480c5000' missing or empty [ 37.797668] omap-aes 480c5000.aes: Unable to request in DMA channel [ 37.801391]omap_aes_dma_init: error: -12 Error is not fatal, kernel does not crash and qemu emulation working fine. But error is there. I'm sure that qemu does not support omap aes hw emulation and so I except error message about missing hw part (or something else). But not above unwind_backtrace error message. Any idea why it happens? It is probably not related to AES but to DMA. It is for OMAP GP device (but emulated), so can TI comment this problem (as this is not HS under NDA)? Hello, what does that error line means? [ 37.668762] omap_hwmod: aes: idle state can only be entered from enabled state Is not it bug in omap_hwmod.c code? In qemu dmesg log I see this debug line: [0.297851] omap_hwmod: aes: cannot be enabled for reset (3) So aes is in disabled state. Should not omap-aes driver check for aes state if is enabled? Above dmesg error should be fixed by my patch sent to ML: ARM: OMAP2+: Return correct error values from device and hwmod -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH v2 0/3] ARM: dts: add openpandora device support
On Tue, Feb 17, 2015 at 9:52 PM, Marek Belisko ma...@goldelico.com wrote: changes from v1: - add new boards to makefile in patch 2,3 (don't add them in separate commit together), fix gpmc issues (reported by Tony Lindgren) - fix various issues reported by Grazvydas Ignotas (drop internal pullups from pinmux as external are in place, fix gpio buttons active state ...) This series of patches adds initial device tree support for the OpenPandora. The most important parts are working (display, keyboard, touch, charging, fuel gauge, musb port, sd/mmc ports, leds, buttons). All of these have been tested to be working, after adding missing input flag for touchscreen. Well except musb, but I often have trouble with that in mainline, probably not a problem with this dts. Tested-by: Grazvydas Ignotas nota...@gmail.com And FWIW, the patches have been Reviewed-by: Grazvydas Ignotas nota...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
