with mentioned limitation.
Signed-off-by: Nishanth Menon n...@ti.com
---
This explains the logs I see:
OMAP3430 LDP (ES2.2):
uImage only boot: http://slexy.org/raw/s2YrbMAi7c
uImage+dtb concatenated boot: http://slexy.org/raw/s20qVg17T0
With the following flag set, device is now able
MMC1 is the only MMC interface available on the platform. Further,
since the platform is based on older revision of SoC which is not
capable of doing multi-block writes, mark it so and add pinmux
to ensure that all relevant pins are configured for non-MMC boot
mode.
Signed-off-by: Nishanth Menon
: uevm: Boot PASS: http://slexy.org/raw/s2Q5IdWfMQ
TOTAL = 14 boards, Booted Boards = 10, No Boot boards = 4
--
Regards,
Nishanth Menon
--
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
--
Regards,
Nishanth Menon
--
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
On 01/17/2014 06:12 PM, Olof Johansson wrote:
On Fri, Jan 17, 2014 at 4:02 PM, Nishanth Menon n...@ti.com wrote:
clk-next-6a0cad9 + next-20140117 multi_v7_defconfig + CONFIG_LPAE=y:
1: am335x-evm: Boot PASS: http://slexy.org/raw/s21GRhEOj4
2: am335x-sk: Boot PASS: http://slexy.org/raw
On 01/17/2014 06:23 PM, Olof Johansson wrote:
On Fri, Jan 17, 2014 at 4:19 PM, Nishanth Menon n...@ti.com wrote:
On 01/17/2014 06:12 PM, Olof Johansson wrote:
On Fri, Jan 17, 2014 at 4:02 PM, Nishanth Menon n...@ti.com wrote:
clk-next-6a0cad9 + next-20140117 multi_v7_defconfig + CONFIG_LPAE=y
to enable the
support.
Use COMPILE_TEST to enable the build for other platforms.
Signed-off-by: Amarinder Bindra a-bin...@ti.com
Cc: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Cc: Nishanth Menon n...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Acked
and Benoit. So, linux-next should eventually be good.
As far as I see: the test results are equivalent to the branch that
Tero posted.
Thanks for the patience and effort :).
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message
on linux-next tag.
[1] http://marc.info/?l=devicetreem=138930255330882w=2
--
Regards,
Nishanth Menon
--
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
OMAP5, DRA7, AM43xx all have OPPs. So select the same to allow SoC
only configuration boot to work with OPP.
Reported-by: Nikhil Devshatwar nikhil...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
For DRA7, depends on: https://patchwork.kernel.org/patch/3465411/
arch/arm/mach-omap2
On 01/14/2014 05:14 AM, Taras Kondratiuk wrote:
On 13 January 2014 17:23, Nishanth Menon n...@ti.com wrote:
On 01/13/2014 09:03 AM, Taras Kondratiuk wrote:
From: Victor Kamensky victor.kamen...@linaro.org
Assembler functions defined in sleep44xx.S need to byteswap values
after read / before
do it!.. I mean, yep, it sounds great and all.. but 4 years down the
line, is this still going to work? is this going to be interesting
careabout? or we are just maintaining additional code for a passing
fancy or proof-of-concept?
Regards,
Nishanth Menon
--
To unsubscribe from this list: send
On Tue, Jan 14, 2014 at 2:20 PM, Victor Kamensky
victor.kamen...@linaro.org wrote:
On 14 January 2014 09:56, Nishanth Menon n...@ti.com wrote:
On Tue, Jan 14, 2014 at 11:35 AM, Victor Kamensky
victor.kamen...@linaro.org wrote:
When BE kernel is built Makefile does take of compiling code
arguments in this case..
Regards,
Nishanth Menon
--
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
, =OMAP4_MON_L2X0_AUXCTRL_INDEX @ Setup L2 AUXCTRL
DO_SMC
mov r0, #0x1
--
Regards,
Nishanth Menon
--
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
);
if (!ret)
oh-_state = _HWMOD_STATE_CLKS_INITED;
--
Regards,
Nishanth Menon
--
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
:
15. am43xx-epos + out-of-tree patches for engineering samples
before: http://pastebin.mozilla.org/3976306 (no boot)
after: http://pastebin.mozilla.org/3976399 (boot)
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message
On 01/06/2014 09:21 PM, Nishanth Menon wrote:
Hi Tero,
On 12/20/2013 10:34 AM, Tero Kristo wrote:
Hopefully final post of this series. At least this is going to be the last
post this year as I will be going to x-mas vacation and won't be back before
Jan 2nd. This time I just sent the patches
/processor to work.
--
Regards,
Nishanth Menon
--
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
On 01/06/2014 03:51 PM, Joachim Eastwood wrote:
On 6 January 2014 17:28, Nishanth Menon n...@ti.com wrote:
On 01/01/2014 04:37 PM, Joachim Eastwood wrote:
[...]
I assume this would work but I don't have a 4430 board to test it on.
Unsure about voltage range, but at least 1.0 to 1.4V covers
MMC 8 bit mode operation depends on dip switch setting which is not
obvious - The current board file has this description. However, with
removal of the board file in the future, this information will be lost
and has to be rediscovered.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot
On 01/06/2014 04:24 PM, Joachim Eastwood wrote:
On 6 January 2014 23:02, Nishanth Menon n...@ti.com wrote:
On 01/06/2014 03:51 PM, Joachim Eastwood wrote:
On 6 January 2014 17:28, Nishanth Menon n...@ti.com wrote:
On 01/01/2014 04:37 PM, Joachim Eastwood wrote:
[...]
I assume this would work
Hi Benoit, Tony,
On Wed, Dec 4, 2013 at 6:49 PM, Nishanth Menon n...@ti.com wrote:
Originally attempted partially in [1], the missing binding were
reported as part of Rob's report in [2].
Would you like me to send this series again since I do not see this in:
https://git.kernel.org/cgit/linux
it not appear in patch 44 itself.
Also pending is OMAP5 only build failure that Felipe reported and does
not seem fixed in V12 as well:
http://marc.info/?l=linux-arm-kernelm=138757010619274w=2
and
http://marc.info/?l=linux-arm-kernelm=138755595914796w=2
--
Regards,
Nishanth Menon
--
To unsubscribe from
.
I am unfortunately on vacation right now, and will not be able to test
until second week of jan on platforms - thanks to my completely messed
up vpn setup.
[1] https://github.com/nmenon/kernel_patch_verify
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux
On 12/18/2013 10:57 AM, Benoit Cousson wrote:
On 17/12/2013 20:45, Nishanth Menon wrote:
On 12/09/2013 03:55 PM, Nishanth Menon wrote:
Craneboard is a hardware development platform based on the Sitara
AM3517 ARM Cortex - A8 microprocessor device - see [1] for more
details. Add basic devices
On 12/09/2013 03:55 PM, Nishanth Menon wrote:
Craneboard is a hardware development platform based on the Sitara
AM3517 ARM Cortex - A8 microprocessor device - see [1] for more
details. Add basic devices for craneboard as replacement for the board
file scheduled for removal as part of device
on beagleboard-xm. This is reported in the log as:
hsusb2_vbus: Failed to request enable GPIO510: -22
To fix this, we should handle the fail case of
twl4030_set_gpio_direction independent of the offset TWL4030_GPIO_MAX
check.
Signed-off-by: Nishanth Menon n...@ti.com
---
Applies on v3.13-rc3
Tested
On 12/13/2013 11:04 AM, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [131212 15:38]:
On 12/10/2013 04:41 AM, Tomi Valkeinen wrote:
Hi,
On beagle-xm, v3.13-rc3, I see the following crash if I use the pinctrl
debugfs:
# cat /debug/pinctrl/48002030.pinmux/pins
[ 16.464233] Unhandled
On 12/13/2013 11:28 AM, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [131213 08:48]:
Commit 0b2aa8b (gpio: twl4030: Fix regression for twl gpio output)
introduces yet another regression by ignoring the fact that we use twl
gpio even for LED. For example, leda (offset 18) is used for USB
] for an example (omap2).
+};
+};
+
leds {
pinctrl-0 =
led_gpio_pins
[1]
https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/tree/arch/arm/boot/dts/omap2430-sdp.dts?id=omap-for-v3.14/omap3-board-removal-wl1251#n42
--
Regards,
Nishanth Menon
--
To unsubscribe from
different, but
logical in it's own way.
Regards,
Nishanth Menon
--
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
).
in dts, omap3_pmx_core: pinmux@48002030 describes the range as reg =
0x48002030 0x05cc (which is the max range for the module)
wish pinctrl-single driver could support handle multiple address ranges?
[...]
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux
-by: Nishanth Menon n...@ti.com
---
Applies on v3.13-rc3
Tested on the following platform:
Beagle-XM (OMAP3630): http://pastebin.mozilla.org/3764783
CraneBoard(AM3517): http://pastebin.mozilla.org/3764784
SDP3430 (OMAP3430): http://pastebin.mozilla.org/3764786
I have not been able to test function
On 19:02-20131212, Nishanth Menon wrote:
3430 TRM(SWPU222W) states that control core module padconf
missed a typo in beagle-xm.dts which i failed to
commit --amend :( grr.. Apologies on the noise..
Fixed version below:
8
From
://pastebin.mozilla.org/3753792
Nishanth Menon (2):
net: smc91x: Read hardware behavior flags from device tree
ARM: dts: omap2430-sdp: add flags for ethernet functionality
Documentation/devicetree/bindings/net/smsc91x.txt | 45 +
arch/arm/boot/dts/omap2430-sdp.dts
Ethernet transition from board file to dts missed the required pdata
conversion. So fix the same.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap2430-sdp.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap2430-sdp.dts
b/arch/arm/boot/dts
,
platform_data flags have been used to describe the hardware behavior.
So, introduce the legacy equivalent flags and bindings document to
handle the transition to device tree enabled boot.
Signed-off-by: Nishanth Menon n...@ti.com
---
I am open to the suggestion to make smsc,leda|b macro based value
/interrupts.txt
(hint: b) two cells)
On 12/11/2013 04:39 PM, menon.nisha...@gmail.com wrote:
For a future note, please avoid top-posting in mailing lists :)
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
On Wed, Dec 11, 2013 at 10:04 AM, Tony Lindgren t...@atomide.com wrote:
* Nishanth Menon n...@ti.com [131211 02:23]:
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/smsc91x.txt
@@ -0,0 +1,45 @@
+* Smart Mixed-Signal Connectivity (SMSC) LAN91c94/91c111 Controller
+
+Required
-off-by: Nishanth Menon n...@ti.com
---
Based on:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
branch: omap-for-v3.14/omap3-board-removal 736e812 ARM: OMAP2+: Remove unused
platform init code and headers
Bootlog: http://pastebin.mozilla.org/3744412
arch/arm/boot/dts/Makefile
On 12/04/2013 02:08 AM, Joel Fernandes wrote:
On 12/04/2013 07:09 AM, Nishanth Menon wrote:
Due to the cross dependencies between hwmod for automanaged device
information for OMAP and dts node definitions, we can run into scenarios
where the dts node is defined, however it's hwmod entry is yet
On 18:14-20131204, Joel Fernandes wrote:
On 12/04/2013 05:03 PM, Nishanth Menon wrote:
On 12/04/2013 02:08 AM, Joel Fernandes wrote:
On 12/04/2013 07:09 AM, Nishanth Menon wrote:
Due to the cross dependencies between hwmod for automanaged device
information for OMAP and dts node
have stayed a bit away from updating board and SoC dts files yet
to look at the direction we'd like to go here. If we feel things are
good, I would gladly try to clean our mess up.
Nishanth Menon (2):
Documentation: dt: OMAP: explicitly state SoC compatible strings
ARM: OMAP2+: board-generic
and
are maintained for backward compatibility. It is also expected that
any future SoC addition will keep this documentation updated.
Signed-off-by: Nishanth Menon n...@ti.com
---
.../devicetree/bindings/arm/omap/omap.txt | 53
1 file changed, 53 insertions(+)
diff --git
Now that we have standardized SoC definitions, update the
compatibility strings in board machine descriptors. Eventually, we
should just have SoC compatiblity here and all board specific stuff
should disappear.
Signed-off-by: Nishanth Menon n...@ti.com
---
NOTE: To prevent conflict, I have
or other
similar scenario), fail at pm_domain level due to lack of data, provide
enough information for it to be fixed, however, it allows for the driver
to take appropriate measures to prevent crash.
Reported-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
Signed-off-by: Nishanth Menon n...@ti.com
-bielefeld.de
Signed-off-by: Nishanth Menon n...@ti.com
---
Note: the bug in OMAP pm_domain layer is addressed here:
https://patchwork.kernel.org/patch/3280531/
Proper fixes required to make this work is part of the series:
http://marc.info/?l=linux-kernelm=138541594910233w=2
drivers/crypto/omap
=linux-kernelm=138541603810300w=2
[2] https://patchwork.kernel.org/patch/3280531/
[3] https://patchwork.kernel.org/patch/3280571/
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo
: e92d4038 e2504000 01a05004 0a05 (e5943034)
So, just warn and continue instead of proceeding and crashing, with
missing clock nodes/bad data, we will eventually fail, however we
should now have enough information to identify the culprit.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach
and fixing
the ones we already have, how about something like the following
patch?
For example, on 3.13-rc1, with omap2plus_defconfig, I see the following:
http://pastebin.mozilla.org/3681911
--8--
From b7946d214fab72b2e18cd67eec01c377f1cddee8 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
.
--
Regards,
Nishanth Menon
--
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
-ret_mem_off_counter[i] = 0;
- arch_pwrdm-pwrdm_wait_transition(pwrdm);
+ if (arch_pwrdm arch_pwrdm-pwrdm_wait_transition)
+ arch_pwrdm-pwrdm_wait_transition(pwrdm);
pwrdm-state = pwrdm_read_pwrst(pwrdm);
pwrdm-state_counter[pwrdm-state] = 1;
Acked-by: Nishanth Menon n
/?l=linux-omapm=138545331825036w=2
--
Regards,
Nishanth Menon
--
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
())
- devinfo.name = omap-cpufreq;
- else
- devinfo.name = cpufreq-cpu0;
+ devinfo.name = cpufreq-cpu0;
struct platform_device_info devinfo = { .name = cpufreq-cpu0 };
otherwise, ok with the change.
Thanks and Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line
On Tue, Nov 26, 2013 at 3:04 PM, Tony Lindgren t...@atomide.com wrote:
* Roger Quadros rog...@ti.com [131120 02:33]:
Nishant,
On 11/19/2013 11:05 PM, Nishanth Menon wrote:
On 09/24/2013 03:53 AM, Roger Quadros wrote:
Provide RESET GPIO and Power regulator for the USB PHY,
the USB
On 11/26/2013 05:33 PM, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [131126 14:14]:
On Mon, Nov 25, 2013 at 6:14 PM, Tony Lindgren t...@atomide.com wrote:
This is no longer needed when booted with device tree.
[...]
static inline void omap_init_cpufreq(void)
{
struct
Menon n...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
Tested-by: Nishanth Menon n...@ti.com
I might suggest though that the better alternative might be to get phy
driver to handle multiple regulators considering that DT is supposed
to represent the h/w topology.
---
arch/arm/boot/dts
access to the RTC registers?
http://www.spinics.net/lists/linux-omap/msg98207.html
might help you - we had thought it might get queued for 3.12, but it
was queued for 3.13 instead..
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
{
compatible = ti,da830-rtc;
reg = 0x44e3e000 0x1000;
interrupts = 75
--
Regards,
Nishanth Menon
--
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
On 11/20/2013 11:42 PM, Stefan Roese wrote:
Thanks Nishanth!
On 11/21/2013 06:30 AM, Nishanth Menon wrote:
This (hacky) patch works, but I'm not sure if this is acceptable upstream:
am335x-board_foo.dts:
...
rtc {
reg = 0x0 0x0;
};
You should be able to achieve the same effect
for the clock nodes to get merged.. we are at v9 of
discussion thread here[1].
for ti-maintained tree, you need to talk to TI support folks for
appropriate kernel for your product line.
[1] http://marc.info/?t=13827167252r=1w=2
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send
On 11/19/2013 11:18 AM, Ben Gamari wrote:
Nishanth Menon n...@ti.com writes:
On 11/19/2013 08:59 AM, Ben Gamari wrote:
Booting a PandaBoard with a recent kernel and devicetree appears to be a
rather messy process. There are dozens of devicetree-related warnings
spewed on boot (many
= uart3_pins;
@@ -166,3 +205,11 @@
pinctrl-names = default;
pinctrl-0 = gpio1_pins;
};
+
+usbhshost {
+ port2-mode = ehci-phy;
+};
+
+usbhsehci {
+ phys = 0 hsusb2_phy;
+};
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux
On 11/15/2013 02:07 AM, Paul Walmsley wrote:
On Thu, 14 Nov 2013, Nishanth Menon wrote:
OMAP device hooks around suspend|resume_noirq ensures that hwmod
devices are forced to idle using omap_device_idle/enable as part of
the last stage of suspend activity.
For a device such as i2c who uses
On 11/07/2013 02:42 PM, Vaibhav Bedia wrote:
Hi Nishanth :)
On Thu, Nov 7, 2013 at 10:48 AM, Nishanth Menon n...@ti.com wrote:
On 11/07/2013 09:36 AM, Daniel Mack wrote:
On 11/07/2013 04:18 PM, Nishanth Menon wrote:
Tested this on a vendor V3.12 tag based kernel:
Test patch: http
data in some
other form which duplicates existing infrastructure for the same.
Signed-off-by: Nishanth Menon n...@ti.com
---
Traditionally, we have add solutions in production kernel that
duplicated data such as:
3.0:
https://android.googlesource.com/kernel/omap.git/+/android-omap-tuna-3.0-jb-mr2
Apologies - $subject should have been an RFC PATCH.
On 11/15/2013 09:11 AM, Nishanth Menon wrote:
[...]
--
Regards,
Nishanth Menon
--
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
as we suspended with. These operations are not expected
to fail as we update the states after the core runtime framework has
suspended itself and restore before the core runtime framework has
resumed.
Reported-by: J Keerthy j-keer...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Acked
On 11/14/2013 12:55 PM, Felipe Balbi wrote:
Hi,
On Thu, Nov 14, 2013 at 11:05:16AM -0600, Nishanth Menon wrote:
OMAP device hooks around suspend|resume_noirq ensures that hwmod
devices are forced to idle using omap_device_idle/enable as part of
the last stage of suspend activity
On 11/13/2013 06:51 AM, Felipe Balbi wrote:
Hi,
On Tue, Nov 12, 2013 at 05:08:30PM -0600, Nishanth Menon wrote:
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index b69dd9a..f97b34b 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach
On 11/13/2013 09:20 AM, Felipe Balbi wrote:
On Wed, Nov 13, 2013 at 08:56:06AM -0600, Nishanth Menon wrote:
On 11/13/2013 06:51 AM, Felipe Balbi wrote:
Hi,
On Tue, Nov 12, 2013 at 05:08:30PM -0600, Nishanth Menon wrote:
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2
it from dra7 init without
SoC check dependency?
Rationale - with more TI SoCs trending towards crossbar, we dont need
to keep adding to the soc_is checks, further, we intend to remove
soc_is checks in it's entirety..
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line
On Wed, Nov 13, 2013 at 9:45 AM, Kevin Hilman khil...@linaro.org wrote:
Nishanth Menon n...@ti.com writes:
On 11/13/2013 06:51 AM, Felipe Balbi wrote:
Hi,
On Tue, Nov 12, 2013 at 05:08:30PM -0600, Nishanth Menon wrote:
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2
as we suspended with.
Reported-by: J Keerthy j-keer...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Acked-by: Rajendra Nayak rna...@ti.com
Acked-by: Kevin Hilman khil...@linaro.org
---
Changes in V2 (resend):
- dropped the unnecessary flag for runtime status restore
- picked up
://patchwork.kernel.org/patch/3176501/
--
Regards,
Nishanth Menon
--
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
Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Thu, 24 Oct 2013 09:12:42 -0500
Subject: [PATCH V2] ARM: OMAP2+: omap_device: maintain sane runtime pm status
around suspend/resume
OMAP device hooks around suspend|resume_noirq ensures that hwmod
devices are forced to idle using
implementation.
that is the entire purpose of autosuspend - the back2back calls have
almost no overhead (other than to see that device suspend was not
invoked) - this is pretty fast. you can tweak autosuspend timeout for
the right configuration to meet up with what you need.
--
Regards,
Nishanth Menon
framework deals
with - so ensure sequences consider that as well.
--
Regards,
Nishanth Menon
--
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
edma_pm_resume(struct device *dev)
+{
+ int i, j;
+
+ pm_runtime_get_sync(dev);
error checks?
[...]
--
Regards,
Nishanth Menon
--
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
On 11/07/2013 09:36 AM, Daniel Mack wrote:
On 11/07/2013 04:18 PM, Nishanth Menon wrote:
Tested this on a vendor V3.12 tag based kernel:
Test patch: http://pastebin.com/AmnktQ7B
test: echo -n 1/sys/power/pm_print_times; rtcwake -d /dev/rtc0 -m
mem -s 5
with the current patch: http
as we suspended with.
Reported-by: J Keerthy j-keer...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Acked-by: Rajendra Nayak rna...@ti.com
---
patch baseline: V3.12 tag (also applies on linux-next next-20131107 tag)
Logs from 3.12 based vendor kernel:
Before: http://pastebin.com/m5KxnB7a
On 11/07/2013 05:44 PM, Kevin Hilman wrote:
Nishanth Menon n...@ti.com writes:
OMAP device hooks around suspend|resume_noirq ensures that hwmod
devices are forced to idle using omap_device_idle/enable as part of
the last stage of suspend activity.
For a device such as i2c who uses autosuspend
On 11/04/2013 04:00 AM, Tero Kristo wrote:
On 11/01/2013 09:16 PM, Nishanth Menon wrote:
On 11/01/2013 04:18 AM, Tero Kristo wrote:
[...]
one other thing I missed, will be nice to introduce a common bindings
for autoidle which tends to be reused in other drivers..
You mean documentation
On 11/01/2013 04:12 AM, Tero Kristo wrote:
On 10/31/2013 05:42 PM, Nishanth Menon wrote:
On 10/25/2013 10:57 AM, Tero Kristo wrote:
ti_dt_clk_init_provider() can now be used to initialize the contents of
a single clock IP block. This parses all the clocks under the IP block
and calls
On 11/01/2013 04:18 AM, Tero Kristo wrote:
On 10/31/2013 06:05 PM, Nishanth Menon wrote:
On 10/25/2013 10:57 AM, Tero Kristo wrote:
[...]
diff --git a/drivers/clk/ti/autoidle.c b/drivers/clk/ti/autoidle.c
new file mode 100644
index 000..efa2a3e
--- /dev/null
+++ b/drivers/clk/ti
On 11/01/2013 04:35 AM, Tero Kristo wrote:
On 10/31/2013 06:27 PM, Nishanth Menon wrote:
On 10/25/2013 10:57 AM, Tero Kristo wrote:
[..]
diff --git a/drivers/clk/ti/composite.c b/drivers/clk/ti/composite.c
new file mode 100644
index 000..9ce7e54
--- /dev/null
+++ b/drivers/clk/ti
On 11/01/2013 04:54 AM, Tero Kristo wrote:
On 11/01/2013 11:48 AM, Tero Kristo wrote:
On 10/31/2013 08:02 PM, Nishanth Menon wrote:
On 10/25/2013 10:57 AM, Tero Kristo wrote:
[...]
diff --git a/drivers/clk/ti/divider.c b/drivers/clk/ti/divider.c
new file mode 100644
index 000..787bc8f
;
+ }
+
free(clk_hw)?
+ return PTR_ERR(clk);
+}
+
--
Regards,
Nishanth Menon
--
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
);
+ }
+}
--
Regards,
Nishanth Menon
--
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
= ti_clk_add_component(node, mux-hw, CLK_COMPONENT_TYPE_MUX);
+ if (!ret)
+ return 0;
+
+ kfree(mux);
+ return -ret;
+}
+CLK_OF_DECLARE(ti_composite_mux_clk_setup, ti,composite-mux-clock,
+of_ti_composite_mux_clk_setup);
--
Regards,
Nishanth Menon
not use regmap_mmio?
[...]
--
Regards,
Nishanth Menon
--
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
the scrm, prm, cm devices in
SoC.dtsi? and clocks.dtsi just contains the clock nodes?
[...]
--
Regards,
Nishanth Menon
--
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
*/
+ };
+ };
+};
[..]
--
Regards,
Nishanth Menon
--
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
On 10/31/2013 08:55 AM, Nishanth Menon wrote:
On 10/31/2013 04:10 AM, Tero Kristo wrote:
On 10/30/2013 10:10 PM, Nishanth Menon wrote:
On 10/30/2013 10:00 AM, Nishanth Menon wrote:
On 10/30/2013 03:23 AM, Tero Kristo wrote:
On 10/29/2013 06:19 PM, Nishanth Menon wrote:
On 10/25/2013 10:56 AM
On 10/31/2013 04:10 AM, Tero Kristo wrote:
On 10/30/2013 10:10 PM, Nishanth Menon wrote:
On 10/30/2013 10:00 AM, Nishanth Menon wrote:
On 10/30/2013 03:23 AM, Tero Kristo wrote:
On 10/29/2013 06:19 PM, Nishanth Menon wrote:
On 10/25/2013 10:56 AM, Tero Kristo wrote:
snip
Testing done
.
--
Regards,
Nishanth Menon
--
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
+ omap2_init_clk_hw_omap_clocks(clk);
+
+ return clk;
+}
+#endif
[...]
+
+#ifdef CONFIG_ARCH_OMAP3
just a mention - I understand we are still in transition and we need
these #ifdefs, but eventually, we should be able to make the dpll.c
independent of SoC variant #ifdefs.
[...]
--
Regards,
Nishanth Menon
On 10/31/2013 09:56 AM, Tero Kristo wrote:
On 10/31/2013 04:19 PM, Nishanth Menon wrote:
On 10/25/2013 10:56 AM, Tero Kristo wrote:
[...]
diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt
b/Documentation/devicetree/bindings/clock/ti/dpll.txt
new file mode 100644
index
;
--
Regards,
Nishanth Menon
--
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
801 - 900 of 2389 matches
Mail list logo
