Re: [PATCH] Revert OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation
Actually, I've tested my patch on DM3730, and, at least, can prove
that original settings of UART are incorrect according to TRM of
processor. What settings of UART you were using to reproduce issue?
I'd like to kindly ask you to describe your test environment, since
I've never experiences issues that you've described nor in debug
console, nor in regular UART usage.
On Mon, Apr 1, 2013 at 8:25 AM, Paul Walmsley p...@pwsan.com wrote:
This reverts commit 1776fd059c40907297d6c26c51876575d63fd9e2.
Commit 1776fd059c40 causes UART sluggishness on the OMAP37xx EVM.
This can be demonstrated by pasting in a ten-character string, like
ff, at the serial console. The string will be echoed back
two to three characters at a time, with about a one-second pause
between groups. This causes one of the OMAP PM validation tests to
time out:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc5/20130331205513/pm/37xxevm/37xxevm_log.txt
With commit 1776fd059c40 reverted, the test succeeds:
http://www.pwsan.com/omap/testlogs/serial_fix_37xx_v3.9-rc/20130331230517/pm/37xxevm/37xxevm_log.txt
This problem has been present since v3.9-rc1, but was incorrectly
suspected to be due to commit 6aa9707099c4b25700940eb3d016f16c4434360d
(lockdep: check that no locks held at freeze time), due to limitations
in my local testbed.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Alexey Pelykh alexey.pel...@gmail.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
Alexey, care to make another attempt for 3.11 at fixing the issue you were
originally debugging, but one that also works on OMAP37xx EVM? It would
be good to cc the linux-omap@vger.kernel.org on your OMAP work. If you
don't have a 37xx EVM, someone there might be able to help you test.
drivers/tty/serial/omap-serial.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index 4dc4140..9915e4d 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -59,7 +59,6 @@
/* SCR register bitmasks */
#define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1 7)
-#define OMAP_UART_SCR_TX_TRIG_GRANU1_MASK (1 6)
#define OMAP_UART_SCR_TX_EMPTY (1 3)
/* FCR register bitmasks */
@@ -321,6 +320,9 @@ static void transmit_chars(struct uart_omap_port *up,
unsigned int lsr)
struct circ_buf *xmit = up-port.state-xmit;
int count;
+ if (!(lsr UART_LSR_THRE))
+ return;
+
if (up-port.x_char) {
serial_out(up, UART_TX, up-port.x_char);
up-port.icount.tx++;
@@ -862,7 +864,7 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
serial_out(up, UART_IER, up-ier);
serial_out(up, UART_LCR, cval); /* reset DLAB */
up-lcr = cval;
- up-scr = 0;
+ up-scr = OMAP_UART_SCR_TX_EMPTY;
/* FIFOs and DMA Settings */
@@ -886,6 +888,8 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
serial_out(up, UART_MCR, up-mcr | UART_MCR_TCRTLR);
/* FIFO ENABLE, DMA MODE */
+ up-scr |= OMAP_UART_SCR_RX_TRIG_GRANU1_MASK;
+
/* Set receive FIFO threshold to 16 characters and
* transmit FIFO threshold to 16 spaces
*/
--
1.7.10.4
--
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] RX-51: ARM errata 430973 workaround
On Sunday 31 March 2013 07:24 PM, Pali Rohár wrote: Closed and signed Nokia X-Loader bootloader stored in RX-51 nand does not set IBE bit in ACTLR and starting kernel in non-secure mode. So direct write to ACTLR by our kernel does not working and the code for ARM errata 430973 in commit 7ce236fcd6fd45b0441a2d49acb2ceb2de2e8a47 that sets IBE bit is a noop. In order to have workaround for ARM errata 430973 from non-secure world on RX-51 we needs Secure Monitor Call to set IBE BIT in ACTLR. This patch adds RX-51 specific SMC support and sets IBE bit in ACTLR during board init code for ARM errata 430973 workaround. Because all the setup and what arguments are required for SMC are completely different from SoC to SoC it is not possible to create generic SMC handling. Code in omap-smc.S looks identical but it is not. So RX-51 needs another code. ARM errata 430973 workaround is needed for thumb-2 ISA compiled userspace binaries. Without this workaround thumb-2 binaries crashing. So with this patch it is possible to recompile and run applications/binaries with thumb-2 ISA on RX-51. Signed-off-by: Ivaylo Dimitrov freemangor...@abv.bg Signed-off-by: Pali Rohár pali.ro...@gmail.com --- arch/arm/mach-omap2/Makefile|1 + arch/arm/mach-omap2/board-rx51-secure.c | 66 +++ arch/arm/mach-omap2/board-rx51-secure.h | 36 + arch/arm/mach-omap2/board-rx51-smc.S| 34 arch/arm/mach-omap2/board-rx51.c|7 5 files changed, 144 insertions(+) create mode 100644 arch/arm/mach-omap2/board-rx51-secure.c create mode 100644 arch/arm/mach-omap2/board-rx51-secure.h create mode 100644 arch/arm/mach-omap2/board-rx51-smc.S diff --git a/arch/arm/mach-omap2/board-rx51-smc.S b/arch/arm/mach-omap2/board-rx51-smc.S new file mode 100644 index 000..70e2eb7 --- /dev/null +++ b/arch/arm/mach-omap2/board-rx51-smc.S @@ -0,0 +1,34 @@ You can avoid creating board-rx51-smc.S by having rx51_ppa_smc() part of board-rx51-secure.c using inline asm. You can avoid the board-rx51-secure.h as well considering the usage is limited to the rx51 board. Regards, Santosh -- 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] Revert OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation
Hi On Mon, 1 Apr 2013, Alexey Pelykh wrote: Actually, I've tested my patch on DM3730, What board, bootloader, and test steps did you use? Can you post a dmesg? and, at least, can prove that original settings of UART are incorrect according to TRM of processor. The TRM could be buggy or wrong; or your patch could be correct as far as the UART goes, but could be triggering a separate bug. We're reaching the end of the v3.9-rc fixes period, so we need to deal with the v3.9-rc regression quickly so folks don't wind up with a broken v3.9 kernel. Then the issue can be debugged and tested, and the revised fix targeted for the v3.11 kernel. What settings of UART you were using to reproduce issue? I'd like to kindly ask you to describe your test environment, since I've never experiences issues that you've described nor in debug console, nor in regular UART usage. Could you be more specific about what information you're looking for, beyond what's in: http://www.pwsan.com/omap/testlogs/test_v3.9-rc5/20130331205513/pm/37xxevm/37xxevm_log.txt ? As you can see from the log, it's using UART1 at 115kbps -- init=/bin/sh, so no userspace to speak of. It's also worth mentioning that the 3730 Beagle XM here doesn't fail the PM test, UART3 at 230kbps in a full userspace: http://www.pwsan.com/omap/testlogs/test_v3.9-rc5/20130331205513/pm/3730beaglexm/3730beaglexm_log.txt - Paul -- 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] Revert OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation
Hi, On Mon, Apr 1, 2013 at 12:13 PM, Paul Walmsley p...@pwsan.com wrote: Hi On Mon, 1 Apr 2013, Alexey Pelykh wrote: Actually, I've tested my patch on DM3730, What board, bootloader, and test steps did you use? Can you post a dmesg? I've used LogicPD Torpedo Wireless SoM + DevKit board. Bootloader is stock from their BSP, u-boot 2011.06 + patches from LogicPD. I can provide dmesg of 3.8(inital kernel this patch was intented for) a bit later during the day, and a bit more later same patch rebased onto latest sources. Also, I should mention that LogicPD does not support 3.8, so most LogicPD-specific devices are not working. And I'd like to point out that after patch gaps I've seen are not gone completely, ~1 packet out of 200 at 1mbaud is still corrupted, but only when PM is enabled in kernel, what gives me a clue that it must be something in PM also. Maybe my patch just reveals PM-specific issue. Have you tried without PM to reproduce issues you're experiencing? and, at least, can prove that original settings of UART are incorrect according to TRM of processor. The TRM could be buggy or wrong; or your patch could be correct as far as the UART goes, but could be triggering a separate bug. We're reaching the end of the v3.9-rc fixes period, so we need to deal with the v3.9-rc regression quickly so folks don't wind up with a broken v3.9 kernel. Then the issue can be debugged and tested, and the revised fix targeted for the v3.11 kernel. Indeed, TRMs appear to contain wrong information, but I believe that in this particular case, bug is somewhere around, but not in these lines. I believe if you take a look on related TRM pages, it seems quite logical that configuration of SCR (before my patch) is not quite proper: - trigger interrupt only when it's entirely empty, not when threshold level is reached, what is incorrect, in my opinion. - (less influencing) Granularity of counter indicates opposite to what is stated in comments These issues may have never been experienced by others, since originally I've hit them on 1mbaud speed, what is not supported by original driver at all. What settings of UART you were using to reproduce issue? I'd like to kindly ask you to describe your test environment, since I've never experiences issues that you've described nor in debug console, nor in regular UART usage. Could you be more specific about what information you're looking for, beyond what's in: http://www.pwsan.com/omap/testlogs/test_v3.9-rc5/20130331205513/pm/37xxevm/37xxevm_log.txt ? As you can see from the log, it's using UART1 at 115kbps -- init=/bin/sh, so no userspace to speak of. Sorry, I've missed that file at all. After patch I've never expericed any issues on 115200 speed of debug console, and it works flawlessly for me. It's also worth mentioning that the 3730 Beagle XM here doesn't fail the PM test, UART3 at 230kbps in a full userspace: http://www.pwsan.com/omap/testlogs/test_v3.9-rc5/20130331205513/pm/3730beaglexm/3730beaglexm_log.txt - Paul -- 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] Revert OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation
cc Kevin, Felipe Hi On Mon, 1 Apr 2013, Alexey Pelykh wrote: On Mon, Apr 1, 2013 at 12:13 PM, Paul Walmsley p...@pwsan.com wrote: On Mon, 1 Apr 2013, Alexey Pelykh wrote: Actually, I've tested my patch on DM3730, What board, bootloader, and test steps did you use? Can you post a dmesg? I've used LogicPD Torpedo Wireless SoM + DevKit board. Bootloader is stock from their BSP, u-boot 2011.06 + patches from LogicPD. I can provide dmesg of 3.8(inital kernel this patch was intented for) a bit later during the day, and a bit more later same patch rebased onto latest sources. Also, I should mention that LogicPD does not support 3.8, so most LogicPD-specific devices are not working. A dmesg from v3.9-rc5 would be ideal, but sounds like it's a non-mainline kernel? Are you using a serial console on that board, and if so, what UART is it on? And I'd like to point out that after patch gaps I've seen are not gone completely, ~1 packet out of 200 at 1mbaud is still corrupted, but only when PM is enabled in kernel, Are you seeing corruption caused by the OMAP UART's receive path, or by the transmit path? When you say only when PM is enabled do you mean by enabling CONFIG_PM, or do you mean after setting an autosuspend timeout on the serial drivers, or something else? what gives me a clue that it must be something in PM also. Maybe my patch just reveals PM-specific issue. Have you tried without PM to reproduce issues you're experiencing? So I'm using omap2plus_defconfig, which has CONFIG_PM=y, but the issues appear before serial autosuspend is enabled. Indeed, TRMs appear to contain wrong information, but I believe that in this particular case, bug is somewhere around, but not in these lines. I believe if you take a look on related TRM pages, it seems quite logical that configuration of SCR (before my patch) is not quite proper: - trigger interrupt only when it's entirely empty, not when threshold level is reached, what is incorrect, in my opinion. - (less influencing) Granularity of counter indicates opposite to what is stated in comments These issues may have never been experienced by others, since originally I've hit them on 1mbaud speed, what is not supported by original driver at all. It wouldn't surprise me at all if something is wrong with the original driver's FIFO setup. The challenge at this point is to keep the driver working while trying to fix what's wrong with it. - Paul -- 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:OMAP2: an issue about curr_pwrst, u8 is never 0
Hi,
On Thu, 14 Mar 2013, Chen Gang wrote:
if pwrdm_read_pwrst returns negative number, curr_pwrst can not notice it.
since really need check curr_pwrst whether is negative,
need let the check valid in _pwrdm_save_clkdm_state_and_activate.
and also better to check the return value of pwrdm_read_pwrst, firstly.
Signed-off-by: Chen Gang gang.c...@asianux.com
thanks for reporting this and sending a suggested fix. The following
patch is what I've queued here, which should deal with the root cause
without the casts.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Sun, 31 Mar 2013 20:22:22 -0600
Subject: [PATCH] ARM: OMAP2+: powerdomain: avoid testing whether an unsigned
char is less than 0
_pwrdm_save_clkdm_state_and_activate() tried to test one of its
unsigned arguments to determine whether it was less than zero. Fix by
moving the error test to the caller.
Reported-by: Chen Gang gang.c...@asianux.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/powerdomain.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 8e61d80..89cad4a 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -52,7 +52,6 @@ enum {
#define ALREADYACTIVE_SWITCH 0
#define FORCEWAKEUP_SWITCH 1
#define LOWPOWERSTATE_SWITCH 2
-#define ERROR_SWITCH 3
/* pwrdm_list contains all registered struct powerdomains */
static LIST_HEAD(pwrdm_list);
@@ -233,10 +232,7 @@ static u8 _pwrdm_save_clkdm_state_and_activate(struct
powerdomain *pwrdm,
{
u8 sleep_switch;
- if (curr_pwrst 0) {
- WARN_ON(1);
- sleep_switch = ERROR_SWITCH;
- } else if (curr_pwrst PWRDM_POWER_ON) {
+ if (curr_pwrst PWRDM_POWER_ON) {
if (curr_pwrst pwrst
pwrdm-flags PWRDM_HAS_LOWPOWERSTATECHANGE
arch_pwrdm-pwrdm_set_lowpwrstchange) {
@@ -1091,7 +1087,8 @@ int pwrdm_post_transition(struct powerdomain *pwrdm)
*/
int omap_set_pwrdm_state(struct powerdomain *pwrdm, u8 pwrst)
{
- u8 curr_pwrst, next_pwrst, sleep_switch;
+ u8 next_pwrst, sleep_switch;
+ int curr_pwrst;
int ret = 0;
bool hwsup = false;
@@ -1107,16 +1104,17 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u8
pwrst)
pwrdm_lock(pwrdm);
curr_pwrst = pwrdm_read_pwrst(pwrdm);
+ if (curr_pwrst 0) {
+ ret = -EINVAL;
+ goto osps_out;
+ }
+
next_pwrst = pwrdm_read_next_pwrst(pwrdm);
if (curr_pwrst == pwrst next_pwrst == pwrst)
goto osps_out;
sleep_switch = _pwrdm_save_clkdm_state_and_activate(pwrdm, curr_pwrst,
pwrst, hwsup);
- if (sleep_switch == ERROR_SWITCH) {
- ret = -EINVAL;
- goto osps_out;
- }
ret = pwrdm_set_next_pwrst(pwrdm, pwrst);
if (ret)
--
1.7.10.4
--
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: OMAP: dpll: enable bypass clock only when attempting dpll bypass
On Thu, 28 Mar 2013, Rajendra Nayak wrote: omap3_noncore_dpll_set_rate() attempts an enable of bypass clk as well as ref clk for every .set_rate attempt on a noncore DPLL, regardless of whether the .set_rate results in the DPLL being locked or put in bypass. Early at boot, while some of these DPLLs are programmed and locked (using .set_rate for the DPLL), this causes an ordering issue. For instance, on OMAP5, the USB DPLL derives its bypass clk from ABE DPLL. If a .set_rate of USB DPLL which programmes the M,N and locks it is called before the one for ABE, the enable of USB bypass clk (derived from ABE DPLL) then attempts to lock the ABE DPLL and fails as the M,N values for ABE are yet to be programmed. To get rid of this ordering needs, enable bypass clk for a DPLL as part of its .set_rate only when its being put in bypass, and only enable the ref clk when its locked. Reported-by: Roger Quadros rog...@ti.com Signed-off-by: Rajendra Nayak rna...@ti.com Thanks, queued for 3.10. - Paul -- 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
Query regarding clk framework - from .set_rate api
Hi Rajendra/Paul/Mike,
I am debugging the issue reported by Michal on AM33xx clock tree
In the context of LCDC driver functionality-
http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg36102.html
Where, the clk_set_rate() seems to be not working, and that's true
with the current implementation of OMAP/AM33xx clock tree,
as the CLK_SET_RATE_PARENT flag is not set to any of the clock nodes.
Please note that I am using DEFINE_STRUCT_CLK() macro for defining clocks
And which doesn't allow you to specify the flags.
Below is the propagation scenario under discussion:
DISP_DPLL (dpll_disp_ck) -
dpll_disp_m2_ck -
lcd_clk_mux_sel -
lcd_gclk
Just to make sure that propagation works fine, I hacked the code and
tested it on AM335x BeagleBone platform without any issues.
Can I create a patch modifying DEFINE_STRUCT_CLK() macro to take
Another argument '.flags and change all clock-trees accrordingly??
Diff Starts here:
=
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 7baede1..51fc78b 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -11,6 +11,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#include linux/clk-private.h
#include linux/io.h
#include linux/of_irq.h
#include linux/of_platform.h
@@ -100,6 +101,7 @@ exit:
static void __init omap_generic_init(void)
{
struct device_node *np;
+ struct clk *clk;
omap_sdrc_init(NULL, NULL);
@@ -115,6 +117,15 @@ static void __init omap_generic_init(void)
if (of_machine_is_compatible(ti,omap5))
omap_sata_init();
+
+ clk = clk_get(NULL, lcd_gclk);
+ if (IS_ERR(clk))
+ printk(Can not get lcd_gclk clock\n);
+
+ printk(%s:%d gclk_rate - %lu\n, __func__, __LINE__,
clk_get_rate(clk));
+ clk_set_rate(clk, 3);
+ printk(%s:%d clk_rate - %lu\n, __func__, __LINE__, clk_get_rate(clk));
+ clk_put(clk);
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index e674e01..d4552db 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -284,7 +284,7 @@ DEFINE_STRUCT_CLK(dpll_disp_ck, dpll_core_ck_parents,
dpll_ddr_ck_ops);
* TODO: Add clksel here (sys_clkin, CORE_CLKOUTM6, PER_CLKOUTM2
* and ALT_CLK1/2)
*/
-DEFINE_CLK_DIVIDER(dpll_disp_m2_ck, dpll_disp_ck, dpll_disp_ck, 0x0,
+DEFINE_CLK_DIVIDER(dpll_disp_m2_ck, dpll_disp_ck, dpll_disp_ck,
CLK_SET_RATE_PARENT,
AM33XX_CM_DIV_M2_DPLL_DISP, AM33XX_DPLL_CLKOUT_DIV_SHIFT,
AM33XX_DPLL_CLKOUT_DIV_WIDTH, CLK_DIVIDER_ONE_BASED, NULL);
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 836311f..3830e5b 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -64,6 +64,7 @@ struct clockdomain;
.parent_names = _parent_array_name, \
.num_parents = ARRAY_SIZE(_parent_array_name), \
.ops = _clkops_name, \
+ .flags = CLK_SET_RATE_PARENT, \
};
#define DEFINE_STRUCT_CLK_HW_OMAP(_name, _clkdm_name) \
Thanks,
Vaibhav
--
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:OMAP2: an issue about curr_pwrst, u8 is never 0
On 2013年04月01日 18:25, Paul Walmsley wrote:
Hi,
On Thu, 14 Mar 2013, Chen Gang wrote:
if pwrdm_read_pwrst returns negative number, curr_pwrst can not notice it.
since really need check curr_pwrst whether is negative,
need let the check valid in _pwrdm_save_clkdm_state_and_activate.
and also better to check the return value of pwrdm_read_pwrst, firstly.
Signed-off-by: Chen Gang gang.c...@asianux.com
thanks for reporting this and sending a suggested fix. The following
patch is what I've queued here, which should deal with the root cause
without the casts.
yours (patch below) is simpler and clearer than mine.
thanks.
:-)
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Sun, 31 Mar 2013 20:22:22 -0600
Subject: [PATCH] ARM: OMAP2+: powerdomain: avoid testing whether an unsigned
char is less than 0
_pwrdm_save_clkdm_state_and_activate() tried to test one of its
unsigned arguments to determine whether it was less than zero. Fix by
moving the error test to the caller.
Reported-by: Chen Gang gang.c...@asianux.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/powerdomain.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 8e61d80..89cad4a 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -52,7 +52,6 @@ enum {
#define ALREADYACTIVE_SWITCH 0
#define FORCEWAKEUP_SWITCH 1
#define LOWPOWERSTATE_SWITCH 2
-#define ERROR_SWITCH 3
/* pwrdm_list contains all registered struct powerdomains */
static LIST_HEAD(pwrdm_list);
@@ -233,10 +232,7 @@ static u8 _pwrdm_save_clkdm_state_and_activate(struct
powerdomain *pwrdm,
{
u8 sleep_switch;
- if (curr_pwrst 0) {
- WARN_ON(1);
- sleep_switch = ERROR_SWITCH;
- } else if (curr_pwrst PWRDM_POWER_ON) {
+ if (curr_pwrst PWRDM_POWER_ON) {
if (curr_pwrst pwrst
pwrdm-flags PWRDM_HAS_LOWPOWERSTATECHANGE
arch_pwrdm-pwrdm_set_lowpwrstchange) {
@@ -1091,7 +1087,8 @@ int pwrdm_post_transition(struct powerdomain *pwrdm)
*/
int omap_set_pwrdm_state(struct powerdomain *pwrdm, u8 pwrst)
{
- u8 curr_pwrst, next_pwrst, sleep_switch;
+ u8 next_pwrst, sleep_switch;
+ int curr_pwrst;
int ret = 0;
bool hwsup = false;
@@ -1107,16 +1104,17 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm,
u8 pwrst)
pwrdm_lock(pwrdm);
curr_pwrst = pwrdm_read_pwrst(pwrdm);
+ if (curr_pwrst 0) {
+ ret = -EINVAL;
+ goto osps_out;
+ }
+
next_pwrst = pwrdm_read_next_pwrst(pwrdm);
if (curr_pwrst == pwrst next_pwrst == pwrst)
goto osps_out;
sleep_switch = _pwrdm_save_clkdm_state_and_activate(pwrdm, curr_pwrst,
pwrst, hwsup);
- if (sleep_switch == ERROR_SWITCH) {
- ret = -EINVAL;
- goto osps_out;
- }
ret = pwrdm_set_next_pwrst(pwrdm, pwrst);
if (ret)
--
Chen Gang
Asianux Corporation
--
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
[GIT PULL] ARM: OMAP2+: PRCM fixes for 3.10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9: Linux 3.9-rc5 (2013-03-31 15:12:43 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-devel-b-for-3.10 for you to fetch changes up to 469d633d20c774ecd34ac615c838193e1e150c62: ARM: OMAP: dpll: enable bypass clock only when attempting dpll bypass (2013-03-31 20:43:06 -0600) - Some miscellaneous OMAP hwmod, powerdomain, and clock fixes for 3.10. Basic test logs are here: http://www.pwsan.com/omap/testlogs/prcm_fixes_a_3.10/20130331205716/ - vmlinux object size (delta in bytes from test_v3.9-rc5 (07961ac7c0ee8b546658717034fe692fd12eefa9)): text data bsstotal kernel -36 +80 -28 n800_multi_omap2xxx -4 +80 +4 n800_only_a 0000 omap1_defconfig 0000 omap1_defconfig_1510innovator_only 0000 omap1_defconfig_5912osk_only +76 +560 +132 omap2plus_defconfig +76 +160 +92 omap2plus_defconfig_cpupm +76 +800 +156 omap2plus_defconfig_no_pm +6000 +60 omap2plus_defconfig_omap2_4_only +80 +800 +160 omap2plus_defconfig_omap3_4_only +44 +560 +100 rmk_omap3430_ldp_allnoconfig +48 +160 +64 rmk_omap3430_ldp_oldconfig +44 +560 +100 rmk_omap4430_sdp_allnoconfig +16 +160 +32 rmk_omap4430_sdp_oldconfig Paul Walmsley (1): ARM: OMAP2+: powerdomain: avoid testing whether an unsigned char is less than 0 Rajendra Nayak (2): ARM: OMAP2+: hwmod: Remove unused _HWMOD_WAKEUP_ENABLED flag ARM: OMAP: dpll: enable bypass clock only when attempting dpll bypass Vaibhav Hiremath (2): ARM: OMAP2+: AM33xx: hwmod: Add missing sysc definition to wdt1 entry ARM: OMAP2+: am335x: Change the wdt1 func clk src to per_32k clk arch/arm/mach-omap2/cclock33xx_data.c |8 arch/arm/mach-omap2/dpll3xxx.c | 19 +-- arch/arm/mach-omap2/omap_hwmod.c |4 arch/arm/mach-omap2/omap_hwmod.h |6 ++ arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 15 +++ arch/arm/mach-omap2/powerdomain.c | 18 -- 6 files changed, 42 insertions(+), 28 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJRWWSNAAoJEMePsQ0LvSpLMB4P/RzdRMcPLkFBrJaG76uXXmRg yFHJnaS8nQ5obtpu0yzmgznEhuhU9I4DpmIcqaoiAIFO55jPvsWDK1RkQaJpWzou 8DERbYURBELN33iVpChakTLmCzt9spPYqs2F0Eg9h08CpJWlhsIFj1SqRk57Ze8A 3eY/ayqpDTiRbUKzy/PocpUmbT+kwoXNZFNuguM8WQnbVlFKCC8OTVvm3K9iCGCr 30gF+RKAhbNtOMPpruJodBKkld+8rnUx/lOsvDudCs5ggszw7Kb8x4KyLRwZct1j zQAp2We4OKluHYZjPUV1ewAQBuD0YbVJM0A7wpDU6avY4Glf849uOhx+3ScCfVR5 E+9HwpBPfDQlVzPIRhick0LaDAmPtj+68n6r+J9FBTUUTONfJDDu9jDAPPt2qn7P fg8YUiB6tmRInx4lkxfqNuhfHUH96zc+ffQLwNJ1YDFGV460Ltk2j57ienhO/UhX WDAB8b147rsw/dXcF2YlR6b3UjO5vILbO/eJkEPIMCsUXx7WMX729MNp9q+Hskiv DpULnXTd3P4T7dj99/rKlhcHQ2rT9fJ2kM7tPss71j87MvihrPecxCnA/4H401p3 YQf1Mt1EpBPPodhOIiOl9TgqslIZno+R0hSDtO1th/ZuZTPrTG/KKeMqau45WYkr iv4uHjsjFYjgvAhMV43J =z+VJ -END PGP SIGNATURE- -- 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: Query regarding clk framework - from .set_rate api
Where, the clk_set_rate() seems to be not working, and that's true with the current implementation of OMAP/AM33xx clock tree, as the CLK_SET_RATE_PARENT flag is not set to any of the clock nodes. Please note that I am using DEFINE_STRUCT_CLK() macro for defining clocks And which doesn't allow you to specify the flags. Use DEFINE_STRUCT_CLK_FLAGS() then. Its already used in AM33xx clock tree. -- 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 1/3] ARM: dts: AM33XX: Add pinmux configuration for CPSW to beaglebone
On Mon, Mar 25, 2013 at 12:57:56PM +0530, Mugunthan V N wrote:
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = user_leds_s0;
+ pinctrl-0 = user_leds_s0 cpsw_s0;
Why do you add cpsw_s0 to the pinmux node? This should go into the cpsw
node itself, which should work without further code changes since:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ab78029ecc347
(drivers/pinctrl: grab default handles from device core)
Same for the other patches.
Regards,
Jan
--
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] Revert OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation
On Mon, Apr 1, 2013 at 1:19 PM, Paul Walmsley p...@pwsan.com wrote: cc Kevin, Felipe Hi On Mon, 1 Apr 2013, Alexey Pelykh wrote: On Mon, Apr 1, 2013 at 12:13 PM, Paul Walmsley p...@pwsan.com wrote: On Mon, 1 Apr 2013, Alexey Pelykh wrote: Actually, I've tested my patch on DM3730, What board, bootloader, and test steps did you use? Can you post a dmesg? I've used LogicPD Torpedo Wireless SoM + DevKit board. Bootloader is stock from their BSP, u-boot 2011.06 + patches from LogicPD. I can provide dmesg of 3.8(inital kernel this patch was intented for) a bit later during the day, and a bit more later same patch rebased onto latest sources. Also, I should mention that LogicPD does not support 3.8, so most LogicPD-specific devices are not working. A dmesg from v3.9-rc5 would be ideal, but sounds like it's a non-mainline kernel? It's true, mainline kernel won't run on that board out of the box, but patches to support it go only in mach-types.h and board-omap3logic.c Are you using a serial console on that board, and if so, what UART is it on? Yes, it's serial console port on UART0 (console=ttyO0,115200n8) And I'd like to point out that after patch gaps I've seen are not gone completely, ~1 packet out of 200 at 1mbaud is still corrupted, but only when PM is enabled in kernel, Are you seeing corruption caused by the OMAP UART's receive path, or by the transmit path? Corruption is on Tx path. Without my patch (but with patch to allow 1Mbaud): Interrupt to refill Tx FIFO is raised only after entire FIFO is transmitted (that is, no data left in FIFO to be sent), and it takes kernel 25us to handle interrupt and refill FIFO. Issue is in condition when UART triggers interrupt. According to original sources, this interrupt is configured to be raised only when TX FIFO is (fully) empty, while ignoring Tx FIFO threshold level completely, although it's being (almost) properly configured and enabled. So, what my patch changes is basically when interrupt to refill Tx FIFO is raised: - from when empty to when threshold is reached, refs: OMAP_UART_SCR_TX_EMPTY flag should not be set, and UART_LSR_THRE check is also invalid, since blocks threshold level situation. - setting OMAP_UART_SCR_RX_TRIG_GRANU1_MASK will lead to incorrect interpretation of threshold level settings (inconsistent with comments in driver sources itself). When you say only when PM is enabled do you mean by enabling CONFIG_PM, or do you mean after setting an autosuspend timeout on the serial drivers, or something else? I mean that I've seen gap issues both with CONFIG_PM=y and CONFIG_PM=n After my patch I saw gap issues only several times, and _probably_ that is due to CONFIG_PM=y, since I've never seen them after that with CONFIG_PM=n I should point that tests I run are completely user-space, so I've never tested UARTs using oscilloscope during kernel boot. But, no issues in serial console seen, as I've already pointed out. what gives me a clue that it must be something in PM also. Maybe my patch just reveals PM-specific issue. Have you tried without PM to reproduce issues you're experiencing? So I'm using omap2plus_defconfig, which has CONFIG_PM=y, but the issues appear before serial autosuspend is enabled. Indeed, TRMs appear to contain wrong information, but I believe that in this particular case, bug is somewhere around, but not in these lines. I believe if you take a look on related TRM pages, it seems quite logical that configuration of SCR (before my patch) is not quite proper: - trigger interrupt only when it's entirely empty, not when threshold level is reached, what is incorrect, in my opinion. - (less influencing) Granularity of counter indicates opposite to what is stated in comments These issues may have never been experienced by others, since originally I've hit them on 1mbaud speed, what is not supported by original driver at all. It wouldn't surprise me at all if something is wrong with the original driver's FIFO setup. The challenge at this point is to keep the driver working while trying to fix what's wrong with it. - Paul -- 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 5/6] ARM: OMAP3+: ABB: introduce ABB driver
Hi,
Subject changed to Re: [*RFC* PATCH 5/6] ARM: OMAP3+: ABB: introduce
ABB driver
On 03/29/2013 12:35 AM, Nishanth Menon wrote:
- ti internal list which got into the git send-email by error.
Apologies on the bounces which might have resulted... On
14:27-20130328, Mike Turquette wrote:
Quoting Andrii Tseglytskyi (2013-03-28 10:16:07)
From: Andrii.Tseglytskyiandrii.tseglyts...@ti.com
Ownership of ABB driver patch probably still belongs to Mike as the
original
author of the code and working out all the details to entitle ABB on OMAP
platforms
Agreed with Mike to keep mine ownership of patch series, and mention
that Mike is an author of idea and architecture of ABB driver.
[..]
You should probably post this as an RFC. It remains to be seen if using
the clk rate-change notifiers will be the mechanism for scaling voltage
in The Future. This patch is helpful for the purposes of that
discussion but shouldn't be merged until there is more consensus.
I agree. + include linux-arm-kernel and lkml in CC on the next *public*
revision .
Agree.
[..]
+/*
+ * struct omap_abb_data - common data for each instance of ABB ldo
+ *
+ * @opp_sel_mask: selects Fast/Nominal/Slow OPP for ABB
+ * @opp_change_mask: selects OPP_CHANGE bit value
+ * @sr2_wtcnt_value_mask: LDO settling time for active-mode
OPP change
+ * @sr2en_mask:enables/disables ABB
+ * @fbb_sel_mask: selects FBB mode
+ * @rbb_sel_mask: selects RBB mode
+ * @settling_time: IRQ handle used to resolve IRQSTATUS offset
masks
+ * @clock_cycles: value needed for LDO setting time calculation
+ * @setup_offs:PRM_LDO_ABB_XXX_SETUP register offset
+ * @control_offs: PRM_LDO_ABB_IVA_CTRL register offset
Can you align all of these?
We should check up on AM and DM series as well - if the bit offsets are
precisely the same, we could stick with macros instead of having the
masks and register offsets in a device specific manner.
These offsets are the same for OMAP3/4/5. I see two options here.
1) Use macro to define offsets and continue storing them in struct
omap_abb_data
2) Use macro definitions directly in the driver code and remove
mentioned fields from struct omap_abb_data
[..]
+/**
+ * omap_abb_readl() - reads ABB control memory
+ * @abb: pointer to the abb instance
+ * @offs: offset to read
+ *
+ * Returns @offs value
+ */
+static u32 omap_abb_readl(struct omap_abb *abb, u32 offs)
+{
+ return __raw_readl(abb-control + offs);
+}
readl instead of __raw_readl?
Ack. readl/writel should be used..
Ack. readl/writel to be used.
+/**
+ * omap_abb_clock_rate_change() - ABB clock notifier callback
+ * @nb:notifier block
+ * @flags: notifier event type
+ * @data: notifier data, contains clock rates
+ *
+ * Returns NOTIFY_OK
+ */
+static int omap_abb_clock_rate_change(struct notifier_block *nb,
+ unsigned long flags, void *data)
+{
+ struct clk_notifier_data *cnd = data;
+ struct omap_abb *abb = container_of(nb, struct omap_abb,
abb_clk_nb);
+
+ switch (flags) {
+ case PRE_RATE_CHANGE:
+ omap_abb_pre_scale(abb, cnd-old_rate, cnd-new_rate);
+ break;
+ case POST_RATE_CHANGE:
+ omap_abb_post_scale(abb, cnd-old_rate, cnd-new_rate);
+ break;
+ }
+
+ return NOTIFY_OK;
+}
How does this synchronize with the VC/VP voltage transition? Ordering
is important here and if the clk rate-change notifiers are used for both
a VP force update and for an FBB transition there is no guarantee of the
ordering.
I need to dig into this series deeper, but the requirement is as
follows:
Actual voltage change may occur with vc/vp - OMAP3,4,5 OR with i2c1- AM
series or the upcoming DRA SoCs, intent is to model the vc-vp-pmic as
regulators (some internal patches circulate for this, but not mature
enough
to be send out in a public list yet)
Key however is:
* if we do as clock notifiers(as this series attempts I believe), we'd
get ABB
settings around clock change boundary.
Alternative might be to do it around voltage change - we could, in
theory:
a) make an omap voltage regulator and provide notifier around the same
and hook ABB to it. the omap voltage regulator will in turn call the
appropriate voltage regulator (modelled from a regulator that controls
an PMIC over i2c1 OR over vc-vp regulator)
b) make ABB as an regulator by itself?
c) how might this work if we have DVFS capability in CCF itself[1]? it
might be better to have it as notifiers to regulator (the pseudo
omap-voltage regulator perhaps?)
[1] CCF DVFS patches:
https://patchwork.kernel.org/patch/2195431/
https://patchwork.kernel.org/patch/2195421/
https://patchwork.kernel.org/patch/2195451/
https://patchwork.kernel.org/patch/2195441/
https://patchwork.kernel.org/patch/2195461/
In case if VC/VP use clock notifier to scale voltage,
RE: Query regarding clk framework - from .set_rate api
-Original Message- From: Nayak, Rajendra Sent: Monday, April 01, 2013 4:14 PM To: Hiremath, Vaibhav Cc: mturque...@linaro.org; Paul Walmsley; Tony Lindgren; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; khil...@deeprootsystems.com Subject: Re: Query regarding clk framework - from .set_rate api Where, the clk_set_rate() seems to be not working, and that's true with the current implementation of OMAP/AM33xx clock tree, as the CLK_SET_RATE_PARENT flag is not set to any of the clock nodes. Please note that I am using DEFINE_STRUCT_CLK() macro for defining clocks And which doesn't allow you to specify the flags. Use DEFINE_STRUCT_CLK_FLAGS() then. Its already used in AM33xx clock tree. Its not there in my kernel baseline v3.8.5, that’s why I missed it. It got merged into v3.9-rc. I am testing it now, and will update shortly. Thanks, Vaibhav -- 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 5/6] ARM: OMAP3+: ABB: introduce ABB driver
Hi,
Subject changed to Re: [*RFC* PATCH 5/6] ARM: OMAP3+: ABB: introduce
ABB driver
On 03/29/2013 12:35 AM, Nishanth Menon wrote:
- ti internal list which got into the git send-email by error.
Apologies on the bounces which might have resulted... On
14:27-20130328, Mike Turquette wrote:
Quoting Andrii Tseglytskyi (2013-03-28 10:16:07)
From: Andrii.Tseglytskyiandrii.tseglyts...@ti.com
Ownership of ABB driver patch probably still belongs to Mike as the
original
author of the code and working out all the details to entitle ABB on OMAP
platforms
Agreed with Mike to keep mine ownership of patch series, and mention
that Mike is an author of idea and architecture of ABB driver.
[..]
You should probably post this as an RFC. It remains to be seen if using
the clk rate-change notifiers will be the mechanism for scaling voltage
in The Future. This patch is helpful for the purposes of that
discussion but shouldn't be merged until there is more consensus.
I agree. + include linux-arm-kernel and lkml in CC on the next *public*
revision .
Agree.
[..]
+/*
+ * struct omap_abb_data - common data for each instance of ABB ldo
+ *
+ * @opp_sel_mask: selects Fast/Nominal/Slow OPP for ABB
+ * @opp_change_mask: selects OPP_CHANGE bit value
+ * @sr2_wtcnt_value_mask: LDO settling time for active-mode
OPP change
+ * @sr2en_mask:enables/disables ABB
+ * @fbb_sel_mask: selects FBB mode
+ * @rbb_sel_mask: selects RBB mode
+ * @settling_time: IRQ handle used to resolve IRQSTATUS offset
masks
+ * @clock_cycles: value needed for LDO setting time calculation
+ * @setup_offs:PRM_LDO_ABB_XXX_SETUP register offset
+ * @control_offs: PRM_LDO_ABB_IVA_CTRL register offset
Can you align all of these?
We should check up on AM and DM series as well - if the bit offsets are
precisely the same, we could stick with macros instead of having the
masks and register offsets in a device specific manner.
These offsets are the same for OMAP3/4/5. I see two options here.
1) Use macro to define offsets and continue storing them in struct
omap_abb_data
2) Use macro definitions directly in the driver code and remove
mentioned fields from struct omap_abb_data
[..]
+/**
+ * omap_abb_readl() - reads ABB control memory
+ * @abb: pointer to the abb instance
+ * @offs: offset to read
+ *
+ * Returns @offs value
+ */
+static u32 omap_abb_readl(struct omap_abb *abb, u32 offs)
+{
+ return __raw_readl(abb-control + offs);
+}
readl instead of __raw_readl?
Ack. readl/writel should be used..
Ack. readl/writel to be used.
+/**
+ * omap_abb_clock_rate_change() - ABB clock notifier callback
+ * @nb:notifier block
+ * @flags: notifier event type
+ * @data: notifier data, contains clock rates
+ *
+ * Returns NOTIFY_OK
+ */
+static int omap_abb_clock_rate_change(struct notifier_block *nb,
+ unsigned long flags, void *data)
+{
+ struct clk_notifier_data *cnd = data;
+ struct omap_abb *abb = container_of(nb, struct omap_abb,
abb_clk_nb);
+
+ switch (flags) {
+ case PRE_RATE_CHANGE:
+ omap_abb_pre_scale(abb, cnd-old_rate, cnd-new_rate);
+ break;
+ case POST_RATE_CHANGE:
+ omap_abb_post_scale(abb, cnd-old_rate, cnd-new_rate);
+ break;
+ }
+
+ return NOTIFY_OK;
+}
How does this synchronize with the VC/VP voltage transition? Ordering
is important here and if the clk rate-change notifiers are used for both
a VP force update and for an FBB transition there is no guarantee of the
ordering.
I need to dig into this series deeper, but the requirement is as
follows:
Actual voltage change may occur with vc/vp - OMAP3,4,5 OR with i2c1- AM
series or the upcoming DRA SoCs, intent is to model the vc-vp-pmic as
regulators (some internal patches circulate for this, but not mature
enough
to be send out in a public list yet)
Key however is:
* if we do as clock notifiers(as this series attempts I believe), we'd
get ABB
settings around clock change boundary.
Alternative might be to do it around voltage change - we could, in
theory:
a) make an omap voltage regulator and provide notifier around the same
and hook ABB to it. the omap voltage regulator will in turn call the
appropriate voltage regulator (modelled from a regulator that controls
an PMIC over i2c1 OR over vc-vp regulator)
b) make ABB as an regulator by itself?
c) how might this work if we have DVFS capability in CCF itself[1]? it
might be better to have it as notifiers to regulator (the pseudo
omap-voltage regulator perhaps?)
[1] CCF DVFS patches:
https://patchwork.kernel.org/patch/2195431/
https://patchwork.kernel.org/patch/2195421/
https://patchwork.kernel.org/patch/2195451/
https://patchwork.kernel.org/patch/2195441/
https://patchwork.kernel.org/patch/2195461/
In case if VC/VP use clock notifier to scale voltage,
Re: [PATCH] Revert OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation
Paul, Please, correct me if I'm wrong, you're experiencing issues on Tx, or Rx direction? You've said that characters are echoed incorrectly, but haven't mentioned in what direction issue appears? For reference, I'll quote TI DM3730 Rev.R TRM: TRM page 2953, LSR_REG Bit #5: TX_FIFO_E 0x0 Transmit hold register (TX FIFO) is not empty. 0x1 Transmit hold register (TX FIFO) is empty. The transmission is not necessarily complete. Before my patch: there was a check for TX_FIFO_E to be 0x1 before filling Tx FIFO After: If THR interrupt is raised, then there is a space in FIFO and threshold has reached it's level, no extra check is required TRM page 2972, SCR_REG Bit #4: TX_EMPTY_CTL_IT 0x1 The THR interrupt is generated when TX FIFO and TX shift register are empty. 0x0 Normal mode for THR interrupt (see Table 19-33 for details about UART mode interrupts) Before: THR interrput is raised only when TX FIFO and TX shift register are empty, for shortcut all Tx lane empty After: THR interrupt is raised both when Tx lane is empty, or when size of data in Tx lane falls below Tx threshold level Bit #7: RX_TRIG_GRANU1 0x0 Disables the granularity of 1 for TRIGGER RX level 0x1 Enables the granularity of 1 for TRIGGER RX level Before: RX FIFO Trigger Level Defined by the concatenated value of RX_FIFO_TRIG_DMA and RX_FIFO_TRIG (from 1 to 63 characters with a granularity of 1 character). Note: The combination of RX_FIFO_TRIG_DMA = 0x0 and RX_FIFO_TRIG = 0x0 (all zeros) is not supported (minimum 1 character required). All zeros result in unpredictable behavior. After: RX FIFO Trigger Level Defined by the UARTi.FCR_REG[7:6] RX_FIFO_TRIG field (8,16, 56, or 60 characters) (as it should be according to comments in source code) On Mon, Apr 1, 2013 at 1:45 PM, Alexey Pelykh alexey.pel...@gmail.com wrote: On Mon, Apr 1, 2013 at 1:19 PM, Paul Walmsley p...@pwsan.com wrote: cc Kevin, Felipe Hi On Mon, 1 Apr 2013, Alexey Pelykh wrote: On Mon, Apr 1, 2013 at 12:13 PM, Paul Walmsley p...@pwsan.com wrote: On Mon, 1 Apr 2013, Alexey Pelykh wrote: Actually, I've tested my patch on DM3730, What board, bootloader, and test steps did you use? Can you post a dmesg? I've used LogicPD Torpedo Wireless SoM + DevKit board. Bootloader is stock from their BSP, u-boot 2011.06 + patches from LogicPD. I can provide dmesg of 3.8(inital kernel this patch was intented for) a bit later during the day, and a bit more later same patch rebased onto latest sources. Also, I should mention that LogicPD does not support 3.8, so most LogicPD-specific devices are not working. A dmesg from v3.9-rc5 would be ideal, but sounds like it's a non-mainline kernel? It's true, mainline kernel won't run on that board out of the box, but patches to support it go only in mach-types.h and board-omap3logic.c Are you using a serial console on that board, and if so, what UART is it on? Yes, it's serial console port on UART0 (console=ttyO0,115200n8) And I'd like to point out that after patch gaps I've seen are not gone completely, ~1 packet out of 200 at 1mbaud is still corrupted, but only when PM is enabled in kernel, Are you seeing corruption caused by the OMAP UART's receive path, or by the transmit path? Corruption is on Tx path. Without my patch (but with patch to allow 1Mbaud): Interrupt to refill Tx FIFO is raised only after entire FIFO is transmitted (that is, no data left in FIFO to be sent), and it takes kernel 25us to handle interrupt and refill FIFO. Issue is in condition when UART triggers interrupt. According to original sources, this interrupt is configured to be raised only when TX FIFO is (fully) empty, while ignoring Tx FIFO threshold level completely, although it's being (almost) properly configured and enabled. So, what my patch changes is basically when interrupt to refill Tx FIFO is raised: - from when empty to when threshold is reached, refs: OMAP_UART_SCR_TX_EMPTY flag should not be set, and UART_LSR_THRE check is also invalid, since blocks threshold level situation. - setting OMAP_UART_SCR_RX_TRIG_GRANU1_MASK will lead to incorrect interpretation of threshold level settings (inconsistent with comments in driver sources itself). When you say only when PM is enabled do you mean by enabling CONFIG_PM, or do you mean after setting an autosuspend timeout on the serial drivers, or something else? I mean that I've seen gap issues both with CONFIG_PM=y and CONFIG_PM=n After my patch I saw gap issues only several times, and _probably_ that is due to CONFIG_PM=y, since I've never seen them after that with CONFIG_PM=n I should point that tests I run are completely user-space, so I've never tested UARTs using oscilloscope during kernel boot. But, no issues in serial console seen, as I've already pointed out. what gives me a clue that it must be something in PM also. Maybe my patch just reveals PM-specific issue. Have you tried without PM to reproduce issues
RE: Query regarding clk framework - from .set_rate api
-Original Message- From: Hiremath, Vaibhav Sent: Monday, April 01, 2013 4:37 PM To: Nayak, Rajendra Cc: mturque...@linaro.org; Paul Walmsley; Tony Lindgren; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; khil...@deeprootsystems.com Subject: RE: Query regarding clk framework - from .set_rate api -Original Message- From: Nayak, Rajendra Sent: Monday, April 01, 2013 4:14 PM To: Hiremath, Vaibhav Cc: mturque...@linaro.org; Paul Walmsley; Tony Lindgren; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; khil...@deeprootsystems.com Subject: Re: Query regarding clk framework - from .set_rate api Where, the clk_set_rate() seems to be not working, and that's true with the current implementation of OMAP/AM33xx clock tree, as the CLK_SET_RATE_PARENT flag is not set to any of the clock nodes. Please note that I am using DEFINE_STRUCT_CLK() macro for defining clocks And which doesn't allow you to specify the flags. Use DEFINE_STRUCT_CLK_FLAGS() then. Its already used in AM33xx clock tree. Its not there in my kernel baseline v3.8.5, that’s why I missed it. It got merged into v3.9-rc. I am testing it now, and will update shortly. And it works fine... Sorry for the noise, I should have checked mainline status before drafting this email. Thanks, Vaibhav -- 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 00/11] usb: dwc3/xhci/phy: Enable runtime power management
This patch-series enables runtime power management on xhci-plat, dwc3-core, dwc3-exynos as well as on Samsung's USB 2.0 type and USB 3.0 type PHYs. Based on 'next' branch of Felipe Balbi's USB tree. Changes from v2: - Using separate functions for USB PHY runtime power management, instead of using macros. - Adding 'pm_runtime_set_suspended()' api call in dwc3 core layer before enabling runtime pm. (Ideally, we should be explicitly make device 'suspended' or 'active' before enabling runtime pm on it). - Checking return code for 'put_sync' and 'get_sync' of USB-PHYs when waking up or suspending them from dwc3 core's runtime_pm callbacks. - Removed buggy pm_runtime_put() calls from driver's (xhci, dwc3 and PHY) remove functions. - Adding a patch to enable runtime power management of Samsung's USB 2.0 PHY (usb: phy: samsung: Enable runtime power management on usb2phy) Changes from v1: - Adding required PHY APIs to handle runtime power management instead of directly twiddling with phy-dev. - Handling runtime power management of usb PHYs in dwc3 core driver instead of in any glue layer. - Splitting the patch: [PATCH 4/4] usb: phy: samsung: Enable runtime power management on samsung-usb into required number to bifurcate functionality. Vivek Gautam (11): usb: phy: Add APIs for runtime power management USB: dwc3: Adjust runtime pm to allow autosuspend usb: dwc3: Enable runtime pm only after PHYs are initialized usb: dwc3: Add runtime power management callbacks usb: dwc3: exynos: Enable runtime power management usb: xhci: Enable runtime pm in xhci-plat usb: phy: samsung: Enable runtime power management on usb2phy usb: phy: samsung: Enable runtime power management on usb3phy usb: phy: samsung: Add support for external reference clock usb: phy: samsung: Add support for PHY ref_clk gpio usb: phy: samsung: Add support for PHY refclk switching drivers/usb/dwc3/core.c| 59 ++-- drivers/usb/dwc3/dwc3-exynos.c | 12 +++ drivers/usb/host/xhci-plat.c |6 ++ drivers/usb/phy/phy-samsung-usb.c | 26 +++ drivers/usb/phy/phy-samsung-usb.h |1 + drivers/usb/phy/phy-samsung-usb2.c |5 ++ drivers/usb/phy/phy-samsung-usb3.c | 119 +-- include/linux/usb/phy.h| 141 8 files changed, 358 insertions(+), 11 deletions(-) -- 1.7.6.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 v3 06/11] usb: xhci: Enable runtime pm in xhci-plat
By enabling runtime pm in this driver allows users of xhci-plat to enter into runtime pm. This is not full runtime pm support (AKA xhci-plat doesn't actually power anything off when in runtime suspend mode) but, just basic enablement. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com CC: Doug Anderson diand...@chromium.org --- drivers/usb/host/xhci-plat.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c index df90fe5..b10573e 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -12,6 +12,7 @@ */ #include linux/platform_device.h +#include linux/pm_runtime.h #include linux/module.h #include linux/slab.h @@ -149,6 +150,9 @@ static int xhci_plat_probe(struct platform_device *pdev) if (ret) goto put_usb3_hcd; + pm_runtime_set_active(pdev-dev); + pm_runtime_enable(pdev-dev); + return 0; put_usb3_hcd: @@ -174,6 +178,8 @@ static int xhci_plat_remove(struct platform_device *dev) struct usb_hcd *hcd = platform_get_drvdata(dev); struct xhci_hcd *xhci = hcd_to_xhci(hcd); + pm_runtime_disable(dev-dev); + usb_remove_hcd(xhci-shared_hcd); usb_put_hcd(xhci-shared_hcd); -- 1.7.6.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 v3 07/11] usb: phy: samsung: Enable runtime power management on usb2phy
Enable autosuspending of Samsung usb2.0 PHY Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- drivers/usb/phy/phy-samsung-usb2.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/usb/phy/phy-samsung-usb2.c b/drivers/usb/phy/phy-samsung-usb2.c index 45ffe03..d378fe9 100644 --- a/drivers/usb/phy/phy-samsung-usb2.c +++ b/drivers/usb/phy/phy-samsung-usb2.c @@ -423,6 +423,9 @@ static int samsung_usb2phy_probe(struct platform_device *pdev) platform_set_drvdata(pdev, sphy); + pm_runtime_set_active(pdev-dev); + pm_runtime_enable(pdev-dev); + return usb_add_phy(sphy-phy, USB_PHY_TYPE_USB2); } @@ -432,6 +435,8 @@ static int samsung_usb2phy_remove(struct platform_device *pdev) usb_remove_phy(sphy-phy); + pm_runtime_disable(pdev-dev); + if (sphy-pmuregs) iounmap(sphy-pmuregs); if (sphy-sysreg) -- 1.7.6.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 v3 08/11] usb: phy: samsung: Enable runtime power management on usb3phy
Enable autosuspending of Samsung usb3.0 PHY Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- drivers/usb/phy/phy-samsung-usb3.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/usb/phy/phy-samsung-usb3.c b/drivers/usb/phy/phy-samsung-usb3.c index 54f6418..a713585 100644 --- a/drivers/usb/phy/phy-samsung-usb3.c +++ b/drivers/usb/phy/phy-samsung-usb3.c @@ -24,6 +24,7 @@ #include linux/err.h #include linux/io.h #include linux/of.h +#include linux/pm_runtime.h #include linux/usb/samsung_usb_phy.h #include linux/platform_data/samsung-usbphy.h @@ -287,6 +288,9 @@ static int samsung_usb3phy_probe(struct platform_device *pdev) platform_set_drvdata(pdev, sphy); + pm_runtime_set_active(pdev-dev); + pm_runtime_enable(pdev-dev); + return usb_add_phy(sphy-phy, USB_PHY_TYPE_USB3); } @@ -296,6 +300,8 @@ static int samsung_usb3phy_remove(struct platform_device *pdev) usb_remove_phy(sphy-phy); + pm_runtime_disable(pdev-dev); + if (sphy-pmuregs) iounmap(sphy-pmuregs); if (sphy-sysreg) -- 1.7.6.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 v3 05/11] usb: dwc3: exynos: Enable runtime power management
Enabling runtime power management on dwc3-exynos
letting dwc3 controller to be autosuspended on exynos
platform when not in use.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 1ea7bd8..1ae81a0 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -19,6 +19,7 @@
#include linux/platform_data/dwc3-exynos.h
#include linux/dma-mapping.h
#include linux/clk.h
+#include linux/pm_runtime.h
#include linux/usb/otg.h
#include linux/usb/nop-usb-xceiv.h
#include linux/of.h
@@ -138,6 +139,11 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
exynos-dev = dev;
exynos-clk = clk;
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+ pm_runtime_get_sync(dev);
+ pm_runtime_forbid(dev);
+
clk_prepare_enable(exynos-clk);
if (node) {
@@ -152,10 +158,14 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
goto err2;
}
+ pm_runtime_put_sync(dev);
+ pm_runtime_allow(dev);
+
return 0;
err2:
clk_disable_unprepare(clk);
+ pm_runtime_disable(dev);
err1:
return ret;
}
@@ -164,6 +174,8 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
{
struct dwc3_exynos *exynos = platform_get_drvdata(pdev);
+ pm_runtime_disable(pdev-dev);
+
platform_device_unregister(exynos-usb2_phy);
platform_device_unregister(exynos-usb3_phy);
device_for_each_child(pdev-dev, NULL, dwc3_exynos_remove_child);
--
1.7.6.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 v3 01/11] usb: phy: Add APIs for runtime power management
Adding APIs to handle runtime power management on PHY
devices. PHY consumers may need to wake-up/suspend PHYs
when they work across autosuspend.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
include/linux/usb/phy.h | 141 +++
1 files changed, 141 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 6b5978f..01bf9c1 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -297,4 +297,145 @@ static inline const char *usb_phy_type_string(enum
usb_phy_type type)
return UNKNOWN PHY TYPE;
}
}
+
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return;
+ }
+
+ pm_runtime_enable(x-dev);
+}
+
+static inline void usb_phy_autopm_disable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return;
+ }
+
+ pm_runtime_disable(x-dev);
+}
+
+static inline int usb_phy_autopm_get(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return -ENODEV;
+ }
+
+ return pm_runtime_get(x-dev);
+}
+
+static inline int usb_phy_autopm_get_sync(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return -ENODEV;
+ }
+
+ return pm_runtime_get_sync(x-dev);
+}
+
+static inline int usb_phy_autopm_put(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return -ENODEV;
+ }
+
+ return pm_runtime_put(x-dev);
+}
+
+static inline int usb_phy_autopm_put_sync(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return -ENODEV;
+ }
+
+ return pm_runtime_put_sync(x-dev);
+}
+
+static inline void usb_phy_autopm_allow(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return;
+ }
+
+ pm_runtime_allow(x-dev);
+}
+
+static inline void usb_phy_autopm_forbid(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return;
+ }
+
+ pm_runtime_forbid(x-dev);
+}
+
+static inline int usb_phy_autopm_set_active(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return -ENODEV;
+ }
+
+ return pm_runtime_set_active(x-dev);
+}
+
+static inline void usb_phy_autopm_set_suspended(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return;
+ }
+
+ pm_runtime_set_suspended(x-dev);
+}
+
+static inline bool usb_phy_autopm_suspended(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return 0;
+ }
+
+ return pm_runtime_suspended(x-dev);
+}
+
+static inline bool usb_phy_autopm_active(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return 0;
+ }
+
+ return pm_runtime_active(x-dev);
+}
+
+static inline int usb_phy_autopm_suspend(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return -ENODEV;
+ }
+
+ return pm_runtime_suspend(x-dev);
+}
+
+static inline int usb_phy_autopm_resume(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return -ENODEV;
+ }
+
+ return pm_runtime_resume(x-dev);
+}
+
#endif /* __LINUX_USB_PHY_H */
--
1.7.6.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 v3 04/11] usb: dwc3: Add runtime power management callbacks
Right now it doesn't handle full runtime suspend/resume
functionality. However it allows to handle PHYs' sleep
and wakeup across runtime suspend/resume.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/core.c | 43 +++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index e250828..65a3adf 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -745,11 +745,54 @@ static int dwc3_resume(struct device *dev)
return 0;
}
+#ifdef CONFIG_PM_RUNTIME
+static int dwc3_runtime_suspend(struct device *dev)
+{
+ struct dwc3 *dwc = dev_get_drvdata(dev);
+ int ret = 0;
+
+ ret = usb_phy_autopm_put_sync(dwc-usb2_phy);
+ if (ret)
+ dev_warn(dev, Can't autosuspend usb2-phy\n);
+
+ ret = usb_phy_autopm_put_sync(dwc-usb3_phy);
+ if (ret)
+ dev_warn(dev, Can't autosuspend usb3-phy\n);
+
+ return ret;
+}
+
+static int dwc3_runtime_resume(struct device *dev)
+{
+ struct dwc3 *dwc = dev_get_drvdata(dev);
+ int ret = 0;
+
+ ret = usb_phy_autopm_get_sync(dwc-usb2_phy);
+ if (ret) {
+ dev_err(dev, usb2-phy: get sync failed with err %d\n, ret);
+ return ret;
+ }
+
+ ret = usb_phy_autopm_get_sync(dwc-usb3_phy);
+ if (ret) {
+ dev_err(dev, usb3-phy: get sync failed with err %d\n, ret);
+ return ret;
+ }
+
+ return ret;
+}
+#else
+#define dwc3_runtime_suspend NULL
+#define dwc3_runtime_resumeNULL
+#endif
+
static const struct dev_pm_ops dwc3_dev_pm_ops = {
.prepare= dwc3_prepare,
.complete = dwc3_complete,
SET_SYSTEM_SLEEP_PM_OPS(dwc3_suspend, dwc3_resume)
+ SET_RUNTIME_PM_OPS(dwc3_runtime_suspend,
+ dwc3_runtime_resume, NULL)
};
#define DWC3_PM_OPS(dwc3_dev_pm_ops)
--
1.7.6.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 v3 03/11] usb: dwc3: Enable runtime pm only after PHYs are initialized
Allow dwc3 to enable auto power management only after its PHYs are initialized so that any further PHY handling by dwc3's runtime power management callbacks is fine. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- drivers/usb/dwc3/core.c | 18 +- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 3a6993c..e250828 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -491,15 +491,6 @@ static int dwc3_probe(struct platform_device *pdev) dwc-needs_fifo_resize = of_property_read_bool(node, tx-fifo-resize); - /* Setting device state as 'suspended' initially, -* to make sure we know device state prior to -* pm_runtime_enable -*/ - pm_runtime_set_suspended(dev); - pm_runtime_enable(dev); - pm_runtime_get_sync(dev); - pm_runtime_forbid(dev); - dwc3_cache_hwparams(dwc); ret = dwc3_alloc_event_buffers(dwc, DWC3_EVENT_BUFFERS_SIZE); @@ -521,6 +512,15 @@ static int dwc3_probe(struct platform_device *pdev) goto err1; } + /* Setting device state as 'suspended' initially, +* to make sure we know device state prior to +* pm_runtime_enable +*/ + pm_runtime_set_suspended(dev); + pm_runtime_enable(dev); + pm_runtime_get_sync(dev); + pm_runtime_forbid(dev); + if (IS_ENABLED(CONFIG_USB_DWC3_HOST)) mode = DWC3_MODE_HOST; else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET)) -- 1.7.6.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 v3 02/11] USB: dwc3: Adjust runtime pm to allow autosuspend
The current code in the dwc3 probe effectively disables runtime pm from ever working because it calls a get() that was never put() until device removal. Change the runtime pm code to match the standard formula and allow runtime pm to function. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com CC: Doug Anderson diand...@chromium.org --- drivers/usb/dwc3/core.c |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index e2325ad..3a6993c 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -491,6 +491,11 @@ static int dwc3_probe(struct platform_device *pdev) dwc-needs_fifo_resize = of_property_read_bool(node, tx-fifo-resize); + /* Setting device state as 'suspended' initially, +* to make sure we know device state prior to +* pm_runtime_enable +*/ + pm_runtime_set_suspended(dev); pm_runtime_enable(dev); pm_runtime_get_sync(dev); pm_runtime_forbid(dev); @@ -566,6 +571,7 @@ static int dwc3_probe(struct platform_device *pdev) goto err3; } + pm_runtime_put_sync(dev); pm_runtime_allow(dev); return 0; @@ -595,6 +601,7 @@ err1: err0: dwc3_free_event_buffers(dwc); + pm_runtime_disable(pdev-dev); return ret; } @@ -606,7 +613,6 @@ static int dwc3_remove(struct platform_device *pdev) usb_phy_set_suspend(dwc-usb2_phy, 1); usb_phy_set_suspend(dwc-usb3_phy, 1); - pm_runtime_put(pdev-dev); pm_runtime_disable(pdev-dev); dwc3_debugfs_exit(dwc); -- 1.7.6.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: [PATCH] ARM: OMAP1: remove config MACH_OMAP_HTCWIZARD
* Paul Bolle pebo...@tiscali.nl [130321 14:40]: The Kconfig symbol MACH_OMAP_HTCWIZARD got added in v2.6.30. It has never been used. Its entry can safely be removed. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Untested. Thanks, applying into omap-for-v3.10/fixes-non-critical. Regards, Tony arch/arm/mach-omap1/Kconfig | 6 -- 1 file changed, 6 deletions(-) diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig index 903da8e..cdd05f2 100644 --- a/arch/arm/mach-omap1/Kconfig +++ b/arch/arm/mach-omap1/Kconfig @@ -55,12 +55,6 @@ config MACH_OMAP_H3 TI OMAP 1710 H3 board support. Say Y here if you have such a board. -config MACH_OMAP_HTCWIZARD - bool HTC Wizard - depends on ARCH_OMAP850 - help - HTC Wizard smartphone support (AKA QTEK 9100, ...) - config MACH_HERALD bool HTC Herald depends on ARCH_OMAP850 -- 1.7.11.7 -- 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] omap: fix typo CONFIG_BRIDGE_DVFS
* Paul Bolle pebo...@tiscali.nl [130325 16:34]:
Commit 90173882ed15a8034d6d162da5f343a2c7d87587 (omap: add dsp platform
device) used CONFIG_BRIDGE_DVFS were it obviously meant
CONFIG_TIDSPBRIDGE_DVFS. Fix that.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Untested. As this typo has been in the tree since v2.6.37, this really
needs some testing.
Thanks, applying into omap-for-v3.10/fixes-non-critical.
Regards,
Tony
arch/arm/mach-omap2/dsp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/dsp.c b/arch/arm/mach-omap2/dsp.c
index b155500..b8208b4 100644
--- a/arch/arm/mach-omap2/dsp.c
+++ b/arch/arm/mach-omap2/dsp.c
@@ -26,7 +26,7 @@
#include control.h
#include cm2xxx_3xxx.h
#include prm2xxx_3xxx.h
-#ifdef CONFIG_BRIDGE_DVFS
+#ifdef CONFIG_TIDSPBRIDGE_DVFS
#include omap-pm.h
#endif
@@ -35,7 +35,7 @@
static struct platform_device *omap_dsp_pdev;
static struct omap_dsp_platform_data omap_dsp_pdata __initdata = {
-#ifdef CONFIG_BRIDGE_DVFS
+#ifdef CONFIG_TIDSPBRIDGE_DVFS
.dsp_set_min_opp = omap_pm_dsp_set_min_opp,
.dsp_get_opp = omap_pm_dsp_get_opp,
.cpu_set_freq = omap_pm_cpu_set_freq,
--
1.7.11.7
--
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: [GIT PULL] ARM: OMAP2+: PRCM fixes for 3.10
* Paul Walmsley p...@pwsan.com [130401 03:48]: Hi Tony The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9: Linux 3.9-rc5 (2013-03-31 15:12:43 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-devel-b-for-3.10 for you to fetch changes up to 469d633d20c774ecd34ac615c838193e1e150c62: ARM: OMAP: dpll: enable bypass clock only when attempting dpll bypass (2013-03-31 20:43:06 -0600) Some miscellaneous OMAP hwmod, powerdomain, and clock fixes for 3.10. Basic test logs are here: http://www.pwsan.com/omap/testlogs/prcm_fixes_a_3.10/20130331205716/ Thanks applying into omap-for-v3.10/fixes-non-critical. Regards, Tony -- 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 00/14] staging: ti-soc-thermal: fixes and trending support
Hello Greg, Here is a new series of patches for ti-soc-thermal. It will contain a couple of minor fixes, but it has also support for trending, computed by HW history buffer. These patches are also available here: g...@gitorious.org:thermal-framework/thermal-framework.git thermal_work/omap/ti-soc-thermal-history-buffer https://git.gitorious.org/thermal-framework/thermal-framework.git thermal_work/omap/ti-soc-thermal-history-buffer Eduardo Valentin (4): staging: ti-soc-thermal: return error in case power switch is not supported staging: ti-soc-thermal: expose ti_thermal_report_temperature staging: ti-soc-thermal: report alert events on OMAP4 devices staging: ti-soc-thermal: report alert events on OMAP5 devices J Keerthy (9): staging: ti-soc-thermal: Add counter_delay_mask field to temp_sensor_registers struct staging: ti-soc-thermal: Initialise counter_delay field for OMAP5 sensors staging: ti-soc-thermal: Introduce HAS_COUNTER_DELAY feature for bandgap staging: ti-soc-thermal: Enable COUNTER_DELAY feature for OMAP5 staging: ti-soc-thermal: Modify update_interval r/w functions to incorporate the OMAP5 feature of COUNTER_DELAY. staging: ti-soc-thermal: Introduce HAS_HISTORY_BUFFER feature for bandgap staging: ti-soc-thermal: Enable HISTORY_BUFFER Feature for OMAP5 staging: ti-soc-thermal:Introduce ti_bandgap_get_trend function for OMAP5 staging: ti-soc-thermal: Add get_trend support Nishanth Menon (1): staging: ti-soc-thermal: remove kernel-doc warnings reported with -v .../staging/ti-soc-thermal/omap4-thermal-data.c|2 + .../staging/ti-soc-thermal/omap5-thermal-data.c|8 +- drivers/staging/ti-soc-thermal/omap5xxx-bandgap.h |1 + drivers/staging/ti-soc-thermal/ti-bandgap.c| 298 +--- drivers/staging/ti-soc-thermal/ti-bandgap.h| 11 + drivers/staging/ti-soc-thermal/ti-thermal-common.c | 27 ++- drivers/staging/ti-soc-thermal/ti-thermal.h|7 + 7 files changed, 319 insertions(+), 35 deletions(-) -- 1.7.7.1.488.ge8e1c -- 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 01/14] staging: ti-soc-thermal: return error in case power switch is not supported
Improve ti_bandgap_power by returning an error code in case
the device does not support controlling its power state.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/ti-soc-thermal/ti-bandgap.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/ti-soc-thermal/ti-bandgap.c
b/drivers/staging/ti-soc-thermal/ti-bandgap.c
index d479e50..a6aa75f 100644
--- a/drivers/staging/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/staging/ti-soc-thermal/ti-bandgap.c
@@ -100,17 +100,19 @@ do {
\
*/
static int ti_bandgap_power(struct ti_bandgap *bgp, bool on)
{
- int i;
+ int i, ret = 0;
- if (!TI_BANDGAP_HAS(bgp, POWER_SWITCH))
+ if (!TI_BANDGAP_HAS(bgp, POWER_SWITCH)) {
+ ret = -ENOTSUPP;
goto exit;
+ }
for (i = 0; i bgp-conf-sensor_count; i++)
/* active on 0 */
RMW_BITS(bgp, i, temp_sensor_ctrl, bgap_tempsoff_mask, !on);
exit:
- return 0;
+ return ret;
}
/**
--
1.7.7.1.488.ge8e1c
--
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 03/14] staging: ti-soc-thermal: expose ti_thermal_report_temperature
Whenever a sensor has an alert to be reported to the thermal framework,
it can use the report ti_thermal_report_temperature helper. This patch
expose this function so that bandgap data config declarations could use it.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/ti-soc-thermal/ti-thermal.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/ti-soc-thermal/ti-thermal.h
b/drivers/staging/ti-soc-thermal/ti-thermal.h
index ef6981c..7b2d600 100644
--- a/drivers/staging/ti-soc-thermal/ti-thermal.h
+++ b/drivers/staging/ti-soc-thermal/ti-thermal.h
@@ -76,6 +76,7 @@
#ifdef CONFIG_TI_THERMAL
int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id, char *domain);
int ti_thermal_remove_sensor(struct ti_bandgap *bgp, int id);
+int ti_thermal_report_sensor_temperature(struct ti_bandgap *bgp, int id);
int ti_thermal_register_cpu_cooling(struct ti_bandgap *bgp, int id);
int ti_thermal_unregister_cpu_cooling(struct ti_bandgap *bgp, int id);
#else
@@ -92,6 +93,12 @@ int ti_thermal_remove_sensor(struct ti_bandgap *bgp, int id)
}
static inline
+int ti_thermal_report_sensor_temperature(struct ti_bandgap *bgp, int id)
+{
+ return 0;
+}
+
+static inline
int ti_thermal_register_cpu_cooling(struct ti_bandgap *bgp, int id)
{
return 0;
--
1.7.7.1.488.ge8e1c
--
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 04/14] staging: ti-soc-thermal: report alert events on OMAP4 devices
OMAP4460 and OMAP4470 devices have the capability to generate
alert temperature. Thus, whenever a T_ALERT IRQ is served,
the ti-bandgap will call .report_temperature to notify the
thermal framework about thermal zone update request.
This patch allows OMAP4460 and OMAP4470 devices to notify
the thermal framework about T_ALERT events.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
.../staging/ti-soc-thermal/omap4-thermal-data.c|2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/ti-soc-thermal/omap4-thermal-data.c
b/drivers/staging/ti-soc-thermal/omap4-thermal-data.c
index 49d0324..ee9c902 100644
--- a/drivers/staging/ti-soc-thermal/omap4-thermal-data.c
+++ b/drivers/staging/ti-soc-thermal/omap4-thermal-data.c
@@ -216,6 +216,7 @@ const struct ti_bandgap_data omap4460_data = {
.adc_end_val = OMAP4460_ADC_END_VALUE,
.expose_sensor = ti_thermal_expose_sensor,
.remove_sensor = ti_thermal_remove_sensor,
+ .report_temperature = ti_thermal_report_sensor_temperature,
.sensors = {
{
.registers = omap4460_mpu_temp_sensor_registers,
@@ -248,6 +249,7 @@ const struct ti_bandgap_data omap4470_data = {
.adc_end_val = OMAP4460_ADC_END_VALUE,
.expose_sensor = ti_thermal_expose_sensor,
.remove_sensor = ti_thermal_remove_sensor,
+ .report_temperature = ti_thermal_report_sensor_temperature,
.sensors = {
{
.registers = omap4460_mpu_temp_sensor_registers,
--
1.7.7.1.488.ge8e1c
--
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 02/14] staging: ti-soc-thermal: remove kernel-doc warnings reported with -v
From: Nishanth Menon n...@ti.com
Fix all kernel-doc warnings by add documentation about returns.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/ti-soc-thermal/ti-bandgap.c | 58 +-
1 files changed, 47 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/ti-soc-thermal/ti-bandgap.c
b/drivers/staging/ti-soc-thermal/ti-bandgap.c
index a6aa75f..62ffea1 100644
--- a/drivers/staging/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/staging/ti-soc-thermal/ti-bandgap.c
@@ -50,7 +50,7 @@
* @reg: desired register (offset) to be read
*
* Helper function to read bandgap registers. It uses the io remapped area.
- * Returns the register value.
+ * Return: the register value.
*/
static u32 ti_bandgap_readl(struct ti_bandgap *bgp, u32 reg)
{
@@ -97,6 +97,8 @@ do {
\
*
* Used to power on/off a bandgap device instance. Only used on those
* that features tempsoff bit.
+ *
+ * Return: 0 on success, -ENOTSUPP if tempsoff is not supported.
*/
static int ti_bandgap_power(struct ti_bandgap *bgp, bool on)
{
@@ -124,6 +126,8 @@ exit:
* This function is desired because, depending on bandgap device version,
* it might be needed to freeze the bandgap state machine, before fetching
* the register value.
+ *
+ * Return: temperature in ADC values.
*/
static u32 ti_bandgap_read_temp(struct ti_bandgap *bgp, int id)
{
@@ -164,6 +168,8 @@ static u32 ti_bandgap_read_temp(struct ti_bandgap *bgp, int
id)
* conditions and acts accordingly. In case there are events pending,
* it will reset the event mask to wait for the opposite event (next event).
* Every time there is a new event, it will be reported to thermal layer.
+ *
+ * Return: IRQ_HANDLED
*/
static irqreturn_t ti_bandgap_talert_irq_handler(int irq, void *data)
{
@@ -224,6 +230,8 @@ static irqreturn_t ti_bandgap_talert_irq_handler(int irq,
void *data)
* This is the Tshut handler. Use it only if bandgap device features
* HAS(TSHUT). If any sensor fires the Tshut signal, we simply shutdown
* the system.
+ *
+ * Return: IRQ_HANDLED
*/
static irqreturn_t ti_bandgap_tshut_irq_handler(int irq, void *data)
{
@@ -246,6 +254,9 @@ static irqreturn_t ti_bandgap_tshut_irq_handler(int irq,
void *data)
* Simple conversion from ADC representation to mCelsius. In case the ADC value
* is out of the ADC conv table range, it returns -ERANGE, 0 on success.
* The conversion table is indexed by the ADC values.
+ *
+ * Return: 0 if conversion was successful, else -ERANGE in case the @adc_val
+ * argument is out of the ADC conv table range.
*/
static
int ti_bandgap_adc_to_mcelsius(struct ti_bandgap *bgp, int adc_val, int *t)
@@ -274,6 +285,9 @@ exit:
* Simple conversion from mCelsius to ADC values. In case the temp value
* is out of the ADC conv table range, it returns -ERANGE, 0 on success.
* The conversion table is indexed by the ADC values.
+ *
+ * Return: 0 if conversion was successful, else -ERANGE in case the @temp
+ * argument is out of the ADC conv table range.
*/
static
int ti_bandgap_mcelsius_to_adc(struct ti_bandgap *bgp, long temp, int *adc)
@@ -313,7 +327,8 @@ exit:
* @sum: address where to write the resulting temperature (in ADC scale)
*
* Adds an hysteresis value (in mCelsius) to a ADC temperature value.
- * Returns 0 on success, -ERANGE otherwise.
+ *
+ * Return: 0 on success, -ERANGE otherwise.
*/
static
int ti_bandgap_add_hyst(struct ti_bandgap *bgp, int adc_val, int hyst_val,
@@ -386,6 +401,8 @@ static void ti_bandgap_unmask_interrupts(struct ti_bandgap
*bgp, int id,
* It checks the resulting t_hot and t_cold values, based on the new passed
@val
* and configures the thresholds so that t_hot is always greater than t_cold.
* Call this function only if bandgap features HAS(TALERT).
+ *
+ * Return: 0 if no error, else corresponding error
*/
static int ti_bandgap_update_alert_threshold(struct ti_bandgap *bgp, int id,
int val, bool hot)
@@ -444,6 +461,9 @@ exit:
*
* Checks if the bandgap pointer is valid and if the sensor id is also
* applicable.
+ *
+ * Return: 0 if no errors, -EINVAL for invalid @bgp pointer or -ERANGE if
+ * @id cannot index @bgp sensors.
*/
static inline int ti_bandgap_validate(struct ti_bandgap *bgp, int id)
{
@@ -477,6 +497,8 @@ exit:
* This function can be used to update t_hot or t_cold, depending on @hot
value.
* Validates the mCelsius range and update the requested threshold.
* Call this function only if bandgap features HAS(TALERT).
+ *
+ * Return: 0 if no error, else corresponding error value.
*/
static int _ti_bandgap_write_threshold(struct ti_bandgap *bgp, int id, int val,
bool hot)
@@ -531,6 +553,9 @@ exit:
* It will fetch the required thresholds (hot and cold) for TALERT signal.
* This function can be used to
[PATCH 05/14] staging: ti-soc-thermal: report alert events on OMAP5 devices
OMAP5430 devices have the capability to generate
alert temperature. Thus, whenever a T_ALERT IRQ is served,
the ti-bandgap will call .report_temperature to notify the
thermal framework about thermal zone update request.
This patch allows OMAP5430 devices to notify
the thermal framework about T_ALERT events.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
.../staging/ti-soc-thermal/omap5-thermal-data.c|1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/ti-soc-thermal/omap5-thermal-data.c
b/drivers/staging/ti-soc-thermal/omap5-thermal-data.c
index 0afe9c8..aa16f92 100644
--- a/drivers/staging/ti-soc-thermal/omap5-thermal-data.c
+++ b/drivers/staging/ti-soc-thermal/omap5-thermal-data.c
@@ -323,6 +323,7 @@ const struct ti_bandgap_data omap5430_data = {
.adc_end_val = OMAP5430_ADC_END_VALUE,
.expose_sensor = ti_thermal_expose_sensor,
.remove_sensor = ti_thermal_remove_sensor,
+ .report_temperature = ti_thermal_report_sensor_temperature,
.sensors = {
{
.registers = omap5430_mpu_temp_sensor_registers,
--
1.7.7.1.488.ge8e1c
--
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 06/14] staging: ti-soc-thermal: Add counter_delay_mask field to temp_sensor_registers struct
From: J Keerthy j-keer...@ti.com
Add counter_delay_mask field to temp_sensor_registers structure.
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/ti-soc-thermal/ti-bandgap.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/ti-soc-thermal/ti-bandgap.h
b/drivers/staging/ti-soc-thermal/ti-bandgap.h
index 04c6ec2..8f9bdb9 100644
--- a/drivers/staging/ti-soc-thermal/ti-bandgap.h
+++ b/drivers/staging/ti-soc-thermal/ti-bandgap.h
@@ -79,6 +79,7 @@
* @mask_hot_mask: mask to bandgap_mask_ctrl.mask_hot
* @mask_cold_mask: mask to bandgap_mask_ctrl.mask_cold
* @mask_sidlemode_mask: mask to bandgap_mask_ctrl.mask_sidlemode
+ * @mask_counter_delay_mask: mask to bandgap_mask_ctrl.mask_counter_delay
* @mask_freeze_mask: mask to bandgap_mask_ctrl.mask_free
* @mask_clear_mask: mask to bandgap_mask_ctrl.mask_clear
* @mask_clear_accum_mask: mask to bandgap_mask_ctrl.mask_clear_accum
@@ -127,6 +128,7 @@ struct temp_sensor_registers {
u32 mask_hot_mask;
u32 mask_cold_mask;
u32 mask_sidlemode_mask; /* not used: but may be needed for pm */
+ u32 mask_counter_delay_mask;
u32 mask_freeze_mask;
u32 mask_clear_mask; /* not used: but needed for trending */
u32 mask_clear_accum_mask; /* not used: but needed for trending */
--
1.7.7.1.488.ge8e1c
--
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 07/14] staging: ti-soc-thermal: Initialise counter_delay field for OMAP5 sensors
From: J Keerthy j-keer...@ti.com
Initialize all 3 temperature sensors of OMAP5 bandgap with the counter delay
mask.
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
.../staging/ti-soc-thermal/omap5-thermal-data.c|3 +++
drivers/staging/ti-soc-thermal/omap5xxx-bandgap.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/ti-soc-thermal/omap5-thermal-data.c
b/drivers/staging/ti-soc-thermal/omap5-thermal-data.c
index aa16f92..a5fa113 100644
--- a/drivers/staging/ti-soc-thermal/omap5-thermal-data.c
+++ b/drivers/staging/ti-soc-thermal/omap5-thermal-data.c
@@ -39,6 +39,7 @@ omap5430_mpu_temp_sensor_registers = {
.mask_hot_mask = OMAP5430_MASK_HOT_MPU_MASK,
.mask_cold_mask = OMAP5430_MASK_COLD_MPU_MASK,
.mask_sidlemode_mask = OMAP5430_MASK_SIDLEMODE_MASK,
+ .mask_counter_delay_mask = OMAP5430_MASK_COUNTER_DELAY_MASK,
.mask_freeze_mask = OMAP5430_MASK_FREEZE_MPU_MASK,
.mask_clear_mask = OMAP5430_MASK_CLEAR_MPU_MASK,
.mask_clear_accum_mask = OMAP5430_MASK_CLEAR_ACCUM_MPU_MASK,
@@ -84,6 +85,7 @@ omap5430_gpu_temp_sensor_registers = {
.mask_hot_mask = OMAP5430_MASK_HOT_GPU_MASK,
.mask_cold_mask = OMAP5430_MASK_COLD_GPU_MASK,
.mask_sidlemode_mask = OMAP5430_MASK_SIDLEMODE_MASK,
+ .mask_counter_delay_mask = OMAP5430_MASK_COUNTER_DELAY_MASK,
.mask_freeze_mask = OMAP5430_MASK_FREEZE_GPU_MASK,
.mask_clear_mask = OMAP5430_MASK_CLEAR_GPU_MASK,
.mask_clear_accum_mask = OMAP5430_MASK_CLEAR_ACCUM_GPU_MASK,
@@ -129,6 +131,7 @@ omap5430_core_temp_sensor_registers = {
.mask_hot_mask = OMAP5430_MASK_HOT_CORE_MASK,
.mask_cold_mask = OMAP5430_MASK_COLD_CORE_MASK,
.mask_sidlemode_mask = OMAP5430_MASK_SIDLEMODE_MASK,
+ .mask_counter_delay_mask = OMAP5430_MASK_COUNTER_DELAY_MASK,
.mask_freeze_mask = OMAP5430_MASK_FREEZE_CORE_MASK,
.mask_clear_mask = OMAP5430_MASK_CLEAR_CORE_MASK,
.mask_clear_accum_mask = OMAP5430_MASK_CLEAR_ACCUM_CORE_MASK,
diff --git a/drivers/staging/ti-soc-thermal/omap5xxx-bandgap.h
b/drivers/staging/ti-soc-thermal/omap5xxx-bandgap.h
index 8824db4..400b55d 100644
--- a/drivers/staging/ti-soc-thermal/omap5xxx-bandgap.h
+++ b/drivers/staging/ti-soc-thermal/omap5xxx-bandgap.h
@@ -95,6 +95,7 @@
/* OMAP5430.BANDGAP_CTRL */
#define OMAP5430_MASK_SIDLEMODE_MASK (0x3 30)
+#define OMAP5430_MASK_COUNTER_DELAY_MASK (0x7 27)
#define OMAP5430_MASK_FREEZE_CORE_MASK BIT(23)
#define OMAP5430_MASK_FREEZE_GPU_MASK BIT(22)
#define OMAP5430_MASK_FREEZE_MPU_MASK BIT(21)
--
1.7.7.1.488.ge8e1c
--
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 08/14] staging: ti-soc-thermal: Introduce HAS_COUNTER_DELAY feature for bandgap
From: J Keerthy j-keer...@ti.com
Introduce HAS_COUNTER_DELAY feature for bandgap.
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/ti-soc-thermal/ti-bandgap.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/ti-soc-thermal/ti-bandgap.h
b/drivers/staging/ti-soc-thermal/ti-bandgap.h
index 8f9bdb9..8ee4857 100644
--- a/drivers/staging/ti-soc-thermal/ti-bandgap.h
+++ b/drivers/staging/ti-soc-thermal/ti-bandgap.h
@@ -312,6 +312,9 @@ struct ti_temp_sensor {
* TI_BANDGAP_FEATURE_FREEZE_BIT - used when the bandgap device features
* a history buffer that its update can be freezed/unfreezed.
*
+ * TI_BANDGAP_FEATURE_COUNTER_DELAY - used when the bandgap device features
+ * a delay programming based on distinct values.
+ *
* TI_BANDGAP_HAS(b, f) - macro to check if a bandgap device is capable of a
* specific feature (above) or not. Return non-zero, if yes.
*/
@@ -323,6 +326,7 @@ struct ti_temp_sensor {
#define TI_BANDGAP_FEATURE_POWER_SWITCHBIT(5)
#define TI_BANDGAP_FEATURE_CLK_CTRLBIT(6)
#define TI_BANDGAP_FEATURE_FREEZE_BIT BIT(7)
+#define TI_BANDGAP_FEATURE_COUNTER_DELAY BIT(8)
#define TI_BANDGAP_HAS(b, f) \
((b)-conf-features TI_BANDGAP_FEATURE_ ## f)
--
1.7.7.1.488.ge8e1c
--
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 09/14] staging: ti-soc-thermal: Enable COUNTER_DELAY feature for OMAP5
From: J Keerthy j-keer...@ti.com
Enable COUNTER_DELAY feature for OMAP5.
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
.../staging/ti-soc-thermal/omap5-thermal-data.c|3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/ti-soc-thermal/omap5-thermal-data.c
b/drivers/staging/ti-soc-thermal/omap5-thermal-data.c
index a5fa113..460a3b2 100644
--- a/drivers/staging/ti-soc-thermal/omap5-thermal-data.c
+++ b/drivers/staging/ti-soc-thermal/omap5-thermal-data.c
@@ -318,7 +318,8 @@ omap5430_adc_to_temp[
const struct ti_bandgap_data omap5430_data = {
.features = TI_BANDGAP_FEATURE_TSHUT_CONFIG |
TI_BANDGAP_FEATURE_FREEZE_BIT |
- TI_BANDGAP_FEATURE_TALERT,
+ TI_BANDGAP_FEATURE_TALERT |
+ TI_BANDGAP_FEATURE_COUNTER_DELAY,
.fclock_name = l3instr_ts_gclk_div,
.div_ck_name = l3instr_ts_gclk_div,
.conv_table = omap5430_adc_to_temp,
--
1.7.7.1.488.ge8e1c
--
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 10/14] staging: ti-soc-thermal: Modify update_interval r/w functions to incorporate the OMAP5 feature of COUNTER_DELAY.
From: J Keerthy j-keer...@ti.com
Update ti_bandgap_write_update_interval and ti_bandgap_read_update_interval
functions to incorporate the OMAP5 feature of COUNTER_DELAY. The way we
program the delay between two successive temperature conversions
is different for OMAP5 as when compared with OMAP4. Incorporating
the changes required to program the delay for OMAP5.
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/ti-soc-thermal/ti-bandgap.c | 165 +++---
1 files changed, 146 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/ti-soc-thermal/ti-bandgap.c
b/drivers/staging/ti-soc-thermal/ti-bandgap.c
index 62ffea1..cc0c4ba 100644
--- a/drivers/staging/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/staging/ti-soc-thermal/ti-bandgap.c
@@ -649,6 +649,68 @@ int ti_bandgap_write_tcold(struct ti_bandgap *bgp, int id,
int val)
}
/**
+ * ti_bandgap_read_counter() - read the sensor counter
+ * @bgp: pointer to bandgap instance
+ * @id: sensor id
+ * @interval: resulting update interval in miliseconds
+ */
+static void ti_bandgap_read_counter(struct ti_bandgap *bgp, int id,
+ int *interval)
+{
+ struct temp_sensor_registers *tsr;
+ int time;
+
+ tsr = bgp-conf-sensors[id].registers;
+ time = ti_bandgap_readl(bgp, tsr-bgap_counter);
+ time = (time tsr-counter_mask)
+ __ffs(tsr-counter_mask);
+ time = time * 1000 / bgp-clk_rate;
+ *interval = time;
+}
+
+/**
+ * ti_bandgap_read_counter_delay() - read the sensor counter delay
+ * @bgp: pointer to bandgap instance
+ * @id: sensor id
+ * @interval: resulting update interval in miliseconds
+ */
+static void ti_bandgap_read_counter_delay(struct ti_bandgap *bgp, int id,
+ int *interval)
+{
+ struct temp_sensor_registers *tsr;
+ int reg_val;
+
+ tsr = bgp-conf-sensors[id].registers;
+
+ reg_val = ti_bandgap_readl(bgp, tsr-bgap_mask_ctrl);
+ reg_val = (reg_val tsr-mask_counter_delay_mask)
+ __ffs(tsr-mask_counter_delay_mask);
+ switch (reg_val) {
+ case 0:
+ *interval = 0;
+ break;
+ case 1:
+ *interval = 1;
+ break;
+ case 2:
+ *interval = 10;
+ break;
+ case 3:
+ *interval = 100;
+ break;
+ case 4:
+ *interval = 250;
+ break;
+ case 5:
+ *interval = 500;
+ break;
+ default:
+ dev_warn(bgp-dev, Wrong counter delay value read from
register %X,
+reg_val);
+ }
+}
+
+/**
* ti_bandgap_read_update_interval() - read the sensor update interval
* @bgp: pointer to bandgap instance
* @id: sensor id
@@ -659,28 +721,88 @@ int ti_bandgap_write_tcold(struct ti_bandgap *bgp, int
id, int val)
int ti_bandgap_read_update_interval(struct ti_bandgap *bgp, int id,
int *interval)
{
- struct temp_sensor_registers *tsr;
- u32 time;
- int ret;
+ int ret = 0;
ret = ti_bandgap_validate(bgp, id);
if (ret)
- return ret;
+ goto exit;
- if (!TI_BANDGAP_HAS(bgp, COUNTER))
- return -ENOTSUPP;
+ if (!TI_BANDGAP_HAS(bgp, COUNTER)
+ !TI_BANDGAP_HAS(bgp, COUNTER_DELAY)) {
+ ret = -ENOTSUPP;
+ goto exit;
+ }
- tsr = bgp-conf-sensors[id].registers;
- time = ti_bandgap_readl(bgp, tsr-bgap_counter);
- time = (time tsr-counter_mask) __ffs(tsr-counter_mask);
- time = time * 1000 / bgp-clk_rate;
+ if (TI_BANDGAP_HAS(bgp, COUNTER)) {
+ ti_bandgap_read_counter(bgp, id, interval);
+ goto exit;
+ }
- *interval = time;
+ ti_bandgap_read_counter_delay(bgp, id, interval);
+exit:
+ return ret;
+}
+
+/**
+ * ti_bandgap_write_counter_delay() - set the counter_delay
+ * @bgp: pointer to bandgap instance
+ * @id: sensor id
+ * @interval: desired update interval in miliseconds
+ *
+ * Return: 0 on success or the proper error code
+ */
+static int ti_bandgap_write_counter_delay(struct ti_bandgap *bgp, int id,
+ u32 interval)
+{
+ int rval;
+
+ switch (interval) {
+ case 0: /* Immediate conversion */
+ rval = 0x0;
+ break;
+ case 1: /* Conversion after ever 1ms */
+ rval = 0x1;
+ break;
+ case 10: /* Conversion after ever 10ms */
+ rval = 0x2;
+ break;
+ case 100: /* Conversion after ever 100ms */
+ rval = 0x3;
+ break;
+ case 250: /* Conversion after ever 250ms */
+ rval = 0x4;
+
[PATCH 11/14] staging: ti-soc-thermal: Introduce HAS_HISTORY_BUFFER feature for bandgap
From: J Keerthy j-keer...@ti.com
The patch introduces HISTORY_BUFFER feature. This is present in OMAP5 bandgap
and it is a hardware history buffer of previously read temperatures.
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/ti-soc-thermal/ti-bandgap.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/ti-soc-thermal/ti-bandgap.h
b/drivers/staging/ti-soc-thermal/ti-bandgap.h
index 8ee4857..e29e357 100644
--- a/drivers/staging/ti-soc-thermal/ti-bandgap.h
+++ b/drivers/staging/ti-soc-thermal/ti-bandgap.h
@@ -315,6 +315,9 @@ struct ti_temp_sensor {
* TI_BANDGAP_FEATURE_COUNTER_DELAY - used when the bandgap device features
* a delay programming based on distinct values.
*
+ * TI_BANDGAP_FEATURE_HISTORY_BUFFER - used when the bandgap device features
+ * a history buffer of temperatures.
+ *
* TI_BANDGAP_HAS(b, f) - macro to check if a bandgap device is capable of a
* specific feature (above) or not. Return non-zero, if yes.
*/
@@ -327,6 +330,7 @@ struct ti_temp_sensor {
#define TI_BANDGAP_FEATURE_CLK_CTRLBIT(6)
#define TI_BANDGAP_FEATURE_FREEZE_BIT BIT(7)
#define TI_BANDGAP_FEATURE_COUNTER_DELAY BIT(8)
+#define TI_BANDGAP_FEATURE_HISTORY_BUFFER BIT(9)
#define TI_BANDGAP_HAS(b, f) \
((b)-conf-features TI_BANDGAP_FEATURE_ ## f)
--
1.7.7.1.488.ge8e1c
--
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 12/14] staging: ti-soc-thermal: Enable HISTORY_BUFFER Feature for OMAP5
From: J Keerthy j-keer...@ti.com
This patch enables the HISTORY_BUFFER eature for OMAP5.
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
.../staging/ti-soc-thermal/omap5-thermal-data.c|3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/ti-soc-thermal/omap5-thermal-data.c
b/drivers/staging/ti-soc-thermal/omap5-thermal-data.c
index 460a3b2..f170211 100644
--- a/drivers/staging/ti-soc-thermal/omap5-thermal-data.c
+++ b/drivers/staging/ti-soc-thermal/omap5-thermal-data.c
@@ -319,7 +319,8 @@ const struct ti_bandgap_data omap5430_data = {
.features = TI_BANDGAP_FEATURE_TSHUT_CONFIG |
TI_BANDGAP_FEATURE_FREEZE_BIT |
TI_BANDGAP_FEATURE_TALERT |
- TI_BANDGAP_FEATURE_COUNTER_DELAY,
+ TI_BANDGAP_FEATURE_COUNTER_DELAY |
+ TI_BANDGAP_FEATURE_HISTORY_BUFFER,
.fclock_name = l3instr_ts_gclk_div,
.div_ck_name = l3instr_ts_gclk_div,
.conv_table = omap5430_adc_to_temp,
--
1.7.7.1.488.ge8e1c
--
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 13/14] staging: ti-soc-thermal:Introduce ti_bandgap_get_trend function for OMAP5
From: J Keerthy j-keer...@ti.com
The patch adds ti_bandgap_get_trend function. This is specific
to OMAP5 for now it computes the trend from the temp values stored
in the hardware history buffer.
Formula: (T1 - T2) / P.
Where:
T1: Last read valid temperature.
T2: Last but one read valid temperature.
P: Update Interval.
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/ti-soc-thermal/ti-bandgap.c | 67 +++
drivers/staging/ti-soc-thermal/ti-bandgap.h |1 +
2 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/ti-soc-thermal/ti-bandgap.c
b/drivers/staging/ti-soc-thermal/ti-bandgap.c
index cc0c4ba..5b06b12 100644
--- a/drivers/staging/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/staging/ti-soc-thermal/ti-bandgap.c
@@ -962,6 +962,73 @@ static int ti_bandgap_set_continuous_mode(struct
ti_bandgap *bgp)
}
/**
+ * ti_bandgap_get_trend() - To fetch the temperature trend of a sensor
+ * @bgp: pointer to struct ti_bandgap
+ * @id: id of the individual sensor
+ * @trend: Pointer to trend.
+ *
+ * This function needs to be called to fetch the temperature trend of a
+ * Particular sensor. The function computes the difference in temperature
+ * w.r.t time. For the bandgaps with built in history buffer the temperatures
+ * are read from the buffer and for those without the Buffer -ENOTSUPP is
+ * returned.
+ *
+ * Return: 0 if no error, else return corresponding error. If no
+ * error then the trend value is passed on to trend parameter
+ */
+int ti_bandgap_get_trend(struct ti_bandgap *bgp, int id, int *trend)
+{
+ struct temp_sensor_registers *tsr;
+ u32 temp1, temp2, reg1, reg2;
+ int t1, t2, interval, ret = 0;
+
+ ret = ti_bandgap_validate(bgp, id);
+ if (ret)
+ goto exit;
+
+ if (!TI_BANDGAP_HAS(bgp, HISTORY_BUFFER) ||
+ !TI_BANDGAP_HAS(bgp, FREEZE_BIT)) {
+ ret = -ENOTSUPP;
+ goto exit;
+ }
+
+ tsr = bgp-conf-sensors[id].registers;
+
+ /* Freeze and read the last 2 valid readings */
+ reg1 = tsr-ctrl_dtemp_1;
+ reg2 = tsr-ctrl_dtemp_2;
+
+ /* read temperature from history buffer */
+ temp1 = ti_bandgap_readl(bgp, reg1);
+ temp1 = tsr-bgap_dtemp_mask;
+
+ temp2 = ti_bandgap_readl(bgp, reg2);
+ temp2 = tsr-bgap_dtemp_mask;
+
+ /* Convert from adc values to mCelsius temperature */
+ ret = ti_bandgap_adc_to_mcelsius(bgp, temp1, t1);
+ if (ret)
+ goto exit;
+
+ ret = ti_bandgap_adc_to_mcelsius(bgp, temp2, t2);
+ if (ret)
+ goto exit;
+
+ /* Fetch the update interval */
+ ret = ti_bandgap_read_update_interval(bgp, id, interval);
+ if (ret || !interval)
+ goto exit;
+
+ *trend = (t1 - t2) / interval;
+
+ dev_dbg(bgp-dev, The temperatures are t1 = %d and t2 = %d and trend
=%d\n,
+ t1, t2, *trend);
+
+exit:
+ return ret;
+}
+
+/**
* ti_bandgap_tshut_init() - setup and initialize tshut handling
* @bgp: pointer to struct ti_bandgap
* @pdev: pointer to device struct platform_device
diff --git a/drivers/staging/ti-soc-thermal/ti-bandgap.h
b/drivers/staging/ti-soc-thermal/ti-bandgap.h
index e29e357..5f4794a 100644
--- a/drivers/staging/ti-soc-thermal/ti-bandgap.h
+++ b/drivers/staging/ti-soc-thermal/ti-bandgap.h
@@ -382,6 +382,7 @@ int ti_bandgap_read_temperature(struct ti_bandgap *bgp, int
id,
int *temperature);
int ti_bandgap_set_sensor_data(struct ti_bandgap *bgp, int id, void *data);
void *ti_bandgap_get_sensor_data(struct ti_bandgap *bgp, int id);
+int ti_bandgap_get_trend(struct ti_bandgap *bgp, int id, int *trend);
#ifdef CONFIG_OMAP4_THERMAL
extern const struct ti_bandgap_data omap4430_data;
--
1.7.7.1.488.ge8e1c
--
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 14/14] staging: ti-soc-thermal: Add get_trend support
From: J Keerthy j-keer...@ti.com
Patch adds get_trend functionality for OMAP Bandgap thermal devices.
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/ti-soc-thermal/ti-thermal-common.c | 27 +++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/ti-soc-thermal/ti-thermal-common.c
b/drivers/staging/ti-soc-thermal/ti-thermal-common.c
index 231c549..092b39d 100644
--- a/drivers/staging/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/staging/ti-soc-thermal/ti-thermal-common.c
@@ -215,6 +215,31 @@ static int ti_thermal_get_trip_temp(struct
thermal_zone_device *thermal,
return 0;
}
+/* Get the temperature trend callback functions for thermal zone */
+static int ti_thermal_get_trend(struct thermal_zone_device *thermal,
+ int trip, enum thermal_trend *trend)
+{
+ struct ti_thermal_data *data = thermal-devdata;
+ struct ti_bandgap *bgp;
+ int id, tr, ret = 0;
+
+ bgp = data-bgp;
+ id = data-sensor_id;
+
+ ret = ti_bandgap_get_trend(bgp, id, tr);
+ if (ret)
+ return ret;
+
+ if (tr 0)
+ *trend = THERMAL_TREND_RAISING;
+ else if (tr 0)
+ *trend = THERMAL_TREND_DROPPING;
+ else
+ *trend = THERMAL_TREND_STABLE;
+
+ return 0;
+}
+
/* Get critical temperature callback functions for thermal zone */
static int ti_thermal_get_crit_temp(struct thermal_zone_device *thermal,
unsigned long *temp)
@@ -225,7 +250,7 @@ static int ti_thermal_get_crit_temp(struct
thermal_zone_device *thermal,
static struct thermal_zone_device_ops ti_thermal_ops = {
.get_temp = ti_thermal_get_temp,
- /* TODO: add .get_trend */
+ .get_trend = ti_thermal_get_trend,
.bind = ti_thermal_bind,
.unbind = ti_thermal_unbind,
.get_mode = ti_thermal_get_mode,
--
1.7.7.1.488.ge8e1c
--
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] OMAP3 ROM Random Number Generator support
* Pali Rohár pali.ro...@gmail.com [130331 02:32]: On Thursday 28 March 2013 22:44:11 Tony Lindgren wrote: You can use regular clk_get if you add the alias to struct omap_clk omap3xxx_clks table. Tony, can you show me how? Take a look at the omap3xxx_clks in cclock3xxx_data.c. Note how some entries have things like omap_hsmmc.0 and ick. By adding those your driver can request the clock with clk_get(pdev-dev, ick). Regards, Tony -- 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: [RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two
Hi Javier On Sat, 2013-03-30 at 14:18 +0100, Javier Martinez Canillas wrote: A call to gpio_request() to enable the GPIO bank is needed before using a GPIO as an IRQ source, otherwise accesses to the GPIO bank registers fails making the kernel to hang. Yes, that is exactly my problem here. I'm using the GPIO as an IRQ source. Jon's (added as cc)gpio/omap: warn if bank is not enabled on setting irq type patch [1] fixes the issue by warning and returning -EINVAL. This patch will make the kernel to boot but the call to request_irq() will fail of course. For now, the only solution is to call gpio_request() before request_irq() in your platform code or device driver. There is an on going discussion about what's the better way to address this but we still haven't found a good solution to this problem, you can see the last email for this discussion here [2] Also, even when calling gpio_request() before request_irq() this won't work. When specifying the trigger/level flags on the second cell for an GPIO-IRQ, this is not set on the IORESOURCE_IRQ struct resource. The IRQ flag is set on of_irq_to_resource() but it just does: r-flags = IORESOURCE_IRQ; and then the call stack is irq_to_parse_and_map() - irq_set_irq_type() - __irq_set_trigger() - chip-irq_set_type() - (drivers/gpio/gpio-omap.c) gpio_irq_type(). So, even when gpio_irq_type() receive the correct flags, this are not returned neither stored on the flags member of the IORESOURCE_IRQ struct resource that passed to the drivers in their struct platform_device. As a quick-fix (hack) I wrote directly to the registers in gpio_probe() to enable GPIO banks. I now geht this: [0.214630] omap_gpio_probe, 1133, CM_CLKSEL_PER 0x48005040: 0x00ff [0.214660] omap_gpio_probe, 1136, CM_ICLKEN_PER 0x48005010: 0x0007 [0.214660] omap_gpio_probe, 1139, CM_FCLKEN_PER 0x48005000: 0x0007 And it works for me. _But_ when I do enable regulator twl4030 (CONFIG_REGULATOR_TWL4030=y) in my config these registers get reset: [2.935455] smsc911x_open, 1537, CM_CLKSEL_PER 0x48005040: 0x00ff [2.942291] smsc911x_open, 1540, CM_ICLKEN_PER 0x48005010: 0x00040fff [2.949066] smsc911x_open, 1543, CM_FCLKEN_PER 0x48005000: 0x And the IRQ source for the network chip (smsc911x) is disabled :-( Do you have any idea how to (quick) fix this? Thanks -- Christoph -- 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: [GIT PULL] ARM: OMAP5: Generic updates and es2 fixes for 3.10
* Santosh Shilimkar santosh.shilim...@ti.com [130320 01:42]: Tony, Here is the pull request for various OMAP5 generic updates which are posted earlier on the list. It contains OMAP5 es2 related updates like idcode, RAM base and couple of initialisation fixes. The following changes since commit a937536b868b8369b98967929045f1df54234323: Linux 3.9-rc3 (2013-03-17 15:59:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_generic_updates for you to fetch changes up to ecf51648c192377ea2830101b12fc3017bfd2b0c: ARM: OMAP5: clock: No Freqsel on OMAP5 devices too (2013-03-19 12:57:03 +0530) Thanks pulling into omap-for-v3.10/fixes-non-critical. Regards, Tony -- 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] OMAP3 ROM Random Number Generator support
* Ивайло Димитров freemangor...@abv.bg [130331 05:10]:
Hi Pali,
Yep, the code looks almost identical, I guess with some tweaks all SMC code
from that patch could be removed and instead used the one from SMC PPA API.
What I don't get, is why one needs to disable/enable fiqs/irqs:
+static int call_sec_rom(u32 appl_id, u32 proc_id, u32 flag, ...)
+{
+ va_list ap;
+ u32 ret;
+ u32 val;
+
+ va_start(ap, flag);
+ val = *(u32 *) ap;
+ local_irq_disable();
+ local_fiq_disable();
+ ret = omap3_rom_rng_call(appl_id, proc_id, flag,
+ (u32) virt_to_phys((void *) val));
+ local_fiq_enable();
+ local_irq_enable();
+ va_end(ap);
+
+ return ret;
+}
Do you have any idea why is that needed? Any other code I've ever seen to
call SM, does not disable fiqs/irqs, is RNG SMC somehow special? I know this
is Nokia's code, but still, if we can get some understanding...
Sounds like the fiq handling can be dropped based on what
the TI guys posted recently about FIQs only be available in
the secure mode starting with omap2.
Regards,
Tony
--
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: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
* Santosh Shilimkar santosh.shilim...@ti.com [130320 01:43]: Tony, Here is the pull request for OMAP5 data file patches which are on list from last merge window. As aligned on list, I have dropped clock data from the series. That means for the boot, one clock data patch needs to be applied. It is available on my git tree in 'out_of_tree/omap5_clk_data' branch. As discussed already on list, you will notice hwmod data loc has come down from ~6000 lines to ~2000 lines becasue of removal of iospace, irq, dma data as well as unused hwmods. Few hwmods for which dt conversion is pending are not added as well but those would add max ~400 loc in future. The following changes since commit a937536b868b8369b98967929045f1df54234323: Linux 3.9-rc3 (2013-03-17 15:59:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_data_files for you to fetch changes up to 8a6a32e589a1a2a5a3fb8ebe8fc7426997bc6d89: ARM: OMAP5: Enable build and frameowrk initialisations (2013-03-19 14:09:11 +0530) Paul, do you have any comments on these? This branch should be queued separately because of the amount of LOC it adds. But as you may have other PRCM related patches then it's probably best that you queue it. Regards, Tony Benoit Cousson (7): ARM: OMAP5: PRM: Add OMAP54XX register and bitfield files ARM: OMAP5: CM: Add OMAP54XX register and bitfield files ARM: OMAP5: PRCM: Add OMAP54XX local MPU PRCM registers ARM: OMAP5: SCRM: Add OMAP54XX header file. ARM: OMAP2+: clockdomain data: Add OMAP54XX data and update the header ARM: OMAP5: powerdomain data: Add OMAP54XX data and update the header ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data Santosh Shilimkar (4): ARM: OMAP5: hwmod_data: Fix UART sysc settings ARM: OMAP5: hwmod-data: Add timer clock activity flags ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data ARM: OMAP5: Enable build and frameowrk initialisations arch/arm/mach-omap2/Makefile |4 + arch/arm/mach-omap2/clockdomain.h |1 + arch/arm/mach-omap2/clockdomains54xx_data.c | 464 + arch/arm/mach-omap2/cm-regbits-54xx.h | 1737 arch/arm/mach-omap2/cm1_54xx.h| 216 ++ arch/arm/mach-omap2/cm2_54xx.h| 392 arch/arm/mach-omap2/io.c |7 + arch/arm/mach-omap2/omap_hwmod.h |1 + arch/arm/mach-omap2/omap_hwmod_54xx_data.c| 2151 arch/arm/mach-omap2/powerdomain.h |1 + arch/arm/mach-omap2/powerdomains54xx_data.c | 331 +++ arch/arm/mach-omap2/prcm44xx.h|6 + arch/arm/mach-omap2/prcm_mpu54xx.h| 92 + arch/arm/mach-omap2/prm-regbits-54xx.h| 2701 + arch/arm/mach-omap2/prm54xx.h | 447 arch/arm/mach-omap2/scrm54xx.h| 231 +++ arch/arm/mach-omap2/voltage.h |1 + arch/arm/mach-omap2/voltagedomains54xx_data.c | 102 + 18 files changed, 8885 insertions(+) create mode 100644 arch/arm/mach-omap2/clockdomains54xx_data.c create mode 100644 arch/arm/mach-omap2/cm-regbits-54xx.h create mode 100644 arch/arm/mach-omap2/cm1_54xx.h create mode 100644 arch/arm/mach-omap2/cm2_54xx.h create mode 100644 arch/arm/mach-omap2/omap_hwmod_54xx_data.c create mode 100644 arch/arm/mach-omap2/powerdomains54xx_data.c create mode 100644 arch/arm/mach-omap2/prcm_mpu54xx.h create mode 100644 arch/arm/mach-omap2/prm-regbits-54xx.h create mode 100644 arch/arm/mach-omap2/prm54xx.h create mode 100644 arch/arm/mach-omap2/scrm54xx.h create mode 100644 arch/arm/mach-omap2/voltagedomains54xx_data.c -- 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: [GIT PULL] ARM: OMAP2+: standardize integration for AES SHA/MD5 IP blocks for 3.10
* Paul Walmsley p...@pwsan.com [130330 15:51]: Hi Tony, The following changes since commit 78e52e026d288aad88b46bff0d94b05e145c4583: ARM: OMAP2+: clock data: Remove CK_* flags (2013-03-18 09:57:39 -0600) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-devel-a-for-3.10 for you to fetch changes up to 1cb804b93f506dfba5fd684a8ea63706aaa8e709: ARM: AM33XX: hwmod: Update and uncomment AES0 module data (2013-03-30 15:52:17 -0600) For OMAP2+ SoCs, convert the SHA/MD5 and AES accelerator integration code and data to use hwmod and omap_device. This is a prerequisite for moving the hwmod code out of arch/arm. Basic test logs are available at: http://www.pwsan.com/omap/testlogs/sham_aes_integration_devel_3.10/20130330155313/ Thanks pulling into omap-for-v3.10/crypto. Regards, Tony -- 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] Revert OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation
On Mon, 1 Apr 2013, Alexey Pelykh wrote: Please, correct me if I'm wrong, you're experiencing issues on Tx, or Rx direction? You've said that characters are echoed incorrectly, but haven't mentioned in what direction issue appears? The problem seems to be on the Rx path. If I 'cat' a file, it's transmitted without hesitation. But when I paste in this Simpsons quote into the serial console via X: - Mr. Burns: A lifetime of working with nuclear power has left me with a healthy green glow... and left me as impotent as a Nevada boxing commissioner. - ... everything up to the end of boxing is echoed immediately, and then commissioner. stutters its way across the screen over the next five seconds. - Paul -- 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: OMAP baseline test results for v3.9-rc3
* Tero Kristo t-kri...@ti.com [130327 02:15]: On Tue, 2013-03-26 at 18:43 +, Paul Walmsley wrote: So what I'd like you to do is: 1. Determine what devices are remaining to be reset and idled on OMAP4 with the bootloader that I use. As far as I know, there are only four that block full-chip idle: M3, DSP, SL2IF, FSUSB 2. Determine what's needed to reset and idle them. For the M3 and DSP, I'd assume this involves pointing the reset vector for those processors at a few lines of code that basically enter WFI or the C64x equivalent. This is the nasty part. We need firmware support for the blocks to do this, and this is imo a complete overkill for the task at hand, as it will duplicate the DSP + M3 firmware and drivers at least partially. On OMAP3, it was easy as you could just setup the boot mode for IVA and get over with it. We don't have similar luxury on OMAP4. If there was a simple way to do this, don't you think this would have been done already a year back when we started to discuss this first time? And, a year old bootloader is ancient seeing we didn't have any kind of support for OMAP4 core idle in mainline back then and this feature was essentially completely untested nobody cared about the upstream u-boot PM compatibility before that. You may be able to have an inline function in the DSP and M3 headers that idles those modules that can also be called from the reset and idle function in the hwmod code. That way the driver related code stays in the driver, but can be called from hwmod reset if the driver is not compiled in. Of course if the reset and idle of DSP and M3 gets more complex than just a few lines of code, then we should just determine that the PM is broken without those drivers and print out a warning. Regards, Tony -- 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 V3 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver
Vinod,
On 03/20/2013 11:36 AM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [130319 09:08]:
Vinod, Tony, Benoit,
On 02/26/2013 12:27 PM, Jon Hunter wrote:
If the device-tree blob is present during boot, then register the SDMA
controller with the device-tree DMA driver so that we can use device-tree
to look-up DMA client information.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/dma.c |4
drivers/dma/omap-dma.c| 38 --
2 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index dab9fc0..49fd0d5 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -28,6 +28,7 @@
#include linux/init.h
#include linux/device.h
#include linux/dma-mapping.h
+#include linux/of.h
#include linux/omap-dma.h
#include soc.h
@@ -304,6 +305,9 @@ static int __init omap2_system_dma_init(void)
if (res)
return res;
+ if (of_have_populated_dt())
+ return res;
+
pdev = platform_device_register_full(omap_dma_dev_info);
if (IS_ERR(pdev))
return PTR_ERR(pdev);
AFAIK we don't currently have anything else touching this file..
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index c4b4fd2..2ea3d7e 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -16,6 +16,8 @@
#include linux/platform_device.h
#include linux/slab.h
#include linux/spinlock.h
+#include linux/of_dma.h
+#include linux/of_device.h
#include virt-dma.h
@@ -67,6 +69,10 @@ static const unsigned es_bytes[] = {
[OMAP_DMA_DATA_TYPE_S32] = 4,
};
+static struct of_dma_filter_info omap_dma_info = {
+ .filter_fn = omap_dma_filter_fn,
+};
+
static inline struct omap_dmadev *to_omap_dma_dev(struct dma_device *d)
{
return container_of(d, struct omap_dmadev, ddev);
@@ -621,8 +627,22 @@ static int omap_dma_probe(struct platform_device *pdev)
pr_warn(OMAP-DMA: failed to register slave DMA engine device:
%d\n,
rc);
omap_dma_free(od);
- } else {
- platform_set_drvdata(pdev, od);
+ return rc;
+ }
+
+ platform_set_drvdata(pdev, od);
+
+ if (pdev-dev.of_node) {
+ omap_dma_info.dma_cap = od-ddev.cap_mask;
+
+ /* Device-tree DMA controller registration */
+ rc = of_dma_controller_register(pdev-dev.of_node,
+ of_dma_simple_xlate, omap_dma_info);
+ if (rc) {
+ pr_warn(OMAP-DMA: failed to register DMA
controller\n);
+ dma_async_device_unregister(od-ddev);
+ omap_dma_free(od);
+ }
}
dev_info(pdev-dev, OMAP DMA engine driver\n);
@@ -634,18 +654,32 @@ static int omap_dma_remove(struct platform_device
*pdev)
{
struct omap_dmadev *od = platform_get_drvdata(pdev);
+ if (pdev-dev.of_node)
+ of_dma_controller_free(pdev-dev.of_node);
+
dma_async_device_unregister(od-ddev);
omap_dma_free(od);
return 0;
}
+static const struct of_device_id omap_dma_match[] = {
+ { .compatible = ti,omap2420-sdma, },
+ { .compatible = ti,omap2430-sdma, },
+ { .compatible = ti,omap3430-sdma, },
+ { .compatible = ti,omap3630-sdma, },
+ { .compatible = ti,omap4430-sdma, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_dma_match);
+
static struct platform_driver omap_dma_driver = {
.probe = omap_dma_probe,
.remove = omap_dma_remove,
.driver = {
.name = omap-dma-engine,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(omap_dma_match),
},
};
Who's tree does it make most sense for this patch to go through?
Benoit has queued up patch 1/2 and so I am not sure if this should go
via Benoit tree to Tony or directly via Vinod's tree. What are your
thoughts?
OK
It would be great if this could make v3.10.
I suggest Vinod/Grant/Linus W queue this patch:
Acked-by: Tony Lindgren t...@atomide.com
Can you take this patch with Tony's ACK? Let me know if you want me to
resend with the ACK.
Cheers
Jon
--
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] Revert OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation
Paul, can you please try to comment out change related to Rx line (granulation one). That's only Rx line related change in the patch. On Mon, Apr 1, 2013 at 8:09 PM, Paul Walmsley p...@pwsan.com wrote: On Mon, 1 Apr 2013, Alexey Pelykh wrote: Please, correct me if I'm wrong, you're experiencing issues on Tx, or Rx direction? You've said that characters are echoed incorrectly, but haven't mentioned in what direction issue appears? The problem seems to be on the Rx path. If I 'cat' a file, it's transmitted without hesitation. But when I paste in this Simpsons quote into the serial console via X: - Mr. Burns: A lifetime of working with nuclear power has left me with a healthy green glow... and left me as impotent as a Nevada boxing commissioner. - ... everything up to the end of boxing is echoed immediately, and then commissioner. stutters its way across the screen over the next five seconds. - Paul -- 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: [RFC PATCH 5/6] ARM: OMAP3+: ABB: introduce ABB driver
Andrii, Sorry to nitpick further but this your replies look very non-standard. Typically a right chevron and a space is used to indent replies instead of a tab. Something like this: https://wiki.openstack.org/wiki/MailingListEtiquette#Reply_Level_Indication Quoting Andrii Tseglytskyi (2013-04-01 03:53:25) In case if VC/VP use clock notifier to scale voltage, there is no guarantee of order. The only option which I see is to create ABB API and call it from OMAP regulator during OPP change. I doubt that is the only option. Do you mean it is the only option to quickly get it working right now? The VC VP code should be converted to the regulator framework if not already. After that is done there are some options for how ABB is handled. The VC VP regulator driver could directly call the api's you list below in their .set_voltage callback. Additionally if the regulator is reentrant then ABB could be modeled as a regulator itself and the VC or VP .set_voltage callback could perhaps call regulator_set_mode(abb_reg, FBB_MODE). Creating a regulator for each ABB instance may be overkill or may not be overkill... that IP has been around since 3630 so several chips use it. omap_abb_pre_scale(struct omap_abb *abb, u32 old_volt, u32 new_volt); omap_abb_post_scale(struct omap_abb *abb, u32 old_volt, u32 new_volt); Mike, do you agree to proceed in this way? Also I need you opinion about files placement. Now it is placed in The above code looks like a quick solution to me. The long-term upstream path for this code needs be decided first. If everything is going to get converted to the regulator framework then I do not agree to proceed that way. Let's figure out what is happening to the VC/VP code first and then figure out what to do about ABB. Regards, Mike drivers/power/avs/abb.c And header will be added to include/linux/power/abb.h Regards, Andrii -- 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 V3 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver
On Mon, Apr 01, 2013 at 12:48:26PM -0500, Jon Hunter wrote:
Vinod,
On 03/20/2013 11:36 AM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [130319 09:08]:
Vinod, Tony, Benoit,
On 02/26/2013 12:27 PM, Jon Hunter wrote:
If the device-tree blob is present during boot, then register the SDMA
controller with the device-tree DMA driver so that we can use device-tree
to look-up DMA client information.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/dma.c |4
drivers/dma/omap-dma.c| 38 --
2 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index dab9fc0..49fd0d5 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -28,6 +28,7 @@
#include linux/init.h
#include linux/device.h
#include linux/dma-mapping.h
+#include linux/of.h
#include linux/omap-dma.h
#include soc.h
@@ -304,6 +305,9 @@ static int __init omap2_system_dma_init(void)
if (res)
return res;
+ if (of_have_populated_dt())
+ return res;
+
pdev = platform_device_register_full(omap_dma_dev_info);
if (IS_ERR(pdev))
return PTR_ERR(pdev);
AFAIK we don't currently have anything else touching this file..
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index c4b4fd2..2ea3d7e 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -16,6 +16,8 @@
#include linux/platform_device.h
#include linux/slab.h
#include linux/spinlock.h
+#include linux/of_dma.h
+#include linux/of_device.h
#include virt-dma.h
@@ -67,6 +69,10 @@ static const unsigned es_bytes[] = {
[OMAP_DMA_DATA_TYPE_S32] = 4,
};
+static struct of_dma_filter_info omap_dma_info = {
+ .filter_fn = omap_dma_filter_fn,
+};
+
static inline struct omap_dmadev *to_omap_dma_dev(struct dma_device *d)
{
return container_of(d, struct omap_dmadev, ddev);
@@ -621,8 +627,22 @@ static int omap_dma_probe(struct platform_device
*pdev)
pr_warn(OMAP-DMA: failed to register slave DMA engine device:
%d\n,
rc);
omap_dma_free(od);
- } else {
- platform_set_drvdata(pdev, od);
+ return rc;
+ }
+
+ platform_set_drvdata(pdev, od);
+
+ if (pdev-dev.of_node) {
+ omap_dma_info.dma_cap = od-ddev.cap_mask;
+
+ /* Device-tree DMA controller registration */
+ rc = of_dma_controller_register(pdev-dev.of_node,
+ of_dma_simple_xlate, omap_dma_info);
+ if (rc) {
+ pr_warn(OMAP-DMA: failed to register DMA
controller\n);
+ dma_async_device_unregister(od-ddev);
+ omap_dma_free(od);
+ }
}
dev_info(pdev-dev, OMAP DMA engine driver\n);
@@ -634,18 +654,32 @@ static int omap_dma_remove(struct platform_device
*pdev)
{
struct omap_dmadev *od = platform_get_drvdata(pdev);
+ if (pdev-dev.of_node)
+ of_dma_controller_free(pdev-dev.of_node);
+
dma_async_device_unregister(od-ddev);
omap_dma_free(od);
return 0;
}
+static const struct of_device_id omap_dma_match[] = {
+ { .compatible = ti,omap2420-sdma, },
+ { .compatible = ti,omap2430-sdma, },
+ { .compatible = ti,omap3430-sdma, },
+ { .compatible = ti,omap3630-sdma, },
+ { .compatible = ti,omap4430-sdma, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_dma_match);
+
static struct platform_driver omap_dma_driver = {
.probe = omap_dma_probe,
.remove = omap_dma_remove,
.driver = {
.name = omap-dma-engine,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(omap_dma_match),
},
};
Who's tree does it make most sense for this patch to go through?
Benoit has queued up patch 1/2 and so I am not sure if this should go
via Benoit tree to Tony or directly via Vinod's tree. What are your
thoughts?
OK
It would be great if this could make v3.10.
I suggest Vinod/Grant/Linus W queue this patch:
Acked-by: Tony Lindgren t...@atomide.com
Can you take this patch with Tony's ACK? Let me know if you want me to
resend with the ACK.
ahhh due to my vcation/travel looks like this one was skipped, I have
applied it now should show up in linus's tree during next merg window
Sorry for delay
~Vinod
Cheers
Jon
--
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: [RFC PATCH 5/6] ARM: OMAP3+: ABB: introduce ABB driver
On Mon, Apr 1, 2013 at 1:10 PM, Mike Turquette mturque...@linaro.org wrote: Andrii, Sorry to nitpick further but this your replies look very non-standard. Typically a right chevron and a space is used to indent replies instead of a tab. Something like this: https://wiki.openstack.org/wiki/MailingListEtiquette#Reply_Level_Indication Quoting Andrii Tseglytskyi (2013-04-01 03:53:25) In case if VC/VP use clock notifier to scale voltage, there is no guarantee of order. The only option which I see is to create ABB API and call it from OMAP regulator during OPP change. I doubt that is the only option. Do you mean it is the only option to quickly get it working right now? The VC VP code should be converted to the regulator framework if not already. After that is done there are some options for how ABB is handled. The VC VP regulator driver could directly call the api's you list below in their .set_voltage callback. Additionally if the regulator is reentrant then ABB could be modeled as a regulator itself and the VC or VP .set_voltage callback could perhaps call regulator_set_mode(abb_reg, FBB_MODE). Creating a regulator for each ABB instance may be overkill or may not be overkill... that IP has been around since 3630 so several chips use it. omap_abb_pre_scale(struct omap_abb *abb, u32 old_volt, u32 new_volt); omap_abb_post_scale(struct omap_abb *abb, u32 old_volt, u32 new_volt); Mike, do you agree to proceed in this way? Also I need you opinion about files placement. Now it is placed in The above code looks like a quick solution to me. The long-term upstream path for this code needs be decided first. If everything is going to get converted to the regulator framework then I do not agree to proceed that way. Let's figure out what is happening to the VC/VP code first and then figure out what to do about ABB. http://picpaste.com/KmqDYTn0.jpg is an quick depiction of the thought I have in my mind. We do have, in the upcoming SoCs, where Nominal Voltages per device, will now be encoded into the efuse itself(so called class 0 voltage). Future SoCs will need to be able to use ABB along with standard regulators (without use of VC-VP) - in fact, even today, SoCs like AM and DM series of processors have the same requirement. We also will have to support class 2 variants of AVS (which will use standard regulators to set voltage). As of date, CCF does not control regulators - which means the interim solution would be for the device control to manipulate both clock and regulator voltage (similar to what cpufreq-cpu0 driver does today). these drivers should not know the existance of SoC specific intricacies - so ABB linked to voltage values make more sense if ABB sequencing is handled in TI regulator Intent of VC/VP regulator is to be replaceable, on required platforms, with appropriate regulator which do not use VC/VP paths (e.g. on SoCs that do not have it). There is also need to support multiple voltage rails supplied by a single SMPS - in which case controlling via regulator framework is more desirable. --- 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
Re: [PATCH v4 1/6] drivers: phy: add generic PHY framework
Just couple minor comments...
On 03/28/2013 06:43 AM, Kishon Vijay Abraham I wrote:
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY without
using phandle, the platform specfic intialization code (say from board file)
should have already called phy_bind with the binding information. The binding
information consists of phy's device name, phy user device name and an index.
The index is used when the same phy user binds to mulitple phys.
PHY drivers should create the PHY by passing phy_descriptor that has
describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
poweron, shutdown.
The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for the sysfs entry is added
in Documentation/ABI/testing/sysfs-class-phy and the documentation for
dt binding is can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
---
[...]
+/**
+ * phy_put - release the PHY
nit: According to kernel-doc documentation function names should have
parentheses appended to the name. So it would need to be
+ * phy_put() - release the PHY
in this case and it applies to multiple places elsewhere in this patch.
+ * @phy: the phy returned by phy_get()
+ *
+ * Releases a refcount the caller received from phy_get().
+ */
+void phy_put(struct phy *phy)
+{
+ if (phy) {
+ module_put(phy-ops-owner);
+ put_device(phy-dev);
+ }
+}
+EXPORT_SYMBOL_GPL(phy_put);
[...]
+/**
+ * devm_of_phy_get_byname - lookup and obtain a reference to a phy by name
+ * @dev: device that requests this phy
+ * @string - the phy name as given in the dt data
s/ -/:
+ *
+ * Calls devm_of_phy_get (which associates the device with the phy using devres
+ * on successful phy get) and passes on the return value of devm_of_phy_get.
+ */
+struct phy *devm_of_phy_get_byname(struct device *dev, const char *string)
+{
+ int index;
+
+ if (!dev-of_node) {
+ dev_dbg(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ index = of_property_match_string(dev-of_node, phy-names, string);
+
+ return devm_of_phy_get(dev, index);
+}
+EXPORT_SYMBOL_GPL(devm_of_phy_get_byname);
+
+/**
+ * phy_get - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @index: the index of the phy
+ *
+ * Returns the phy driver, after getting a refcount to it; or
+ * -ENODEV if there is no such phy. The caller is responsible for
+ * calling phy_put() to release that count.
+ */
+struct phy *phy_get(struct device *dev, int index)
+{
+ struct phy *phy = NULL;
Unneeded initialization.
+ phy = phy_lookup(dev, index);
+ if (IS_ERR(phy)) {
+ dev_err(dev, unable to find phy\n);
+ goto err0;
Wouldn't it be better to just do:
return phy;
+ }
+
+ if (!try_module_get(phy-ops-owner)) {
+ phy = ERR_PTR(-EPROBE_DEFER);
and
return ERR_PTR(-EPROBE_DEFER);
+ goto err0;
and to drop this goto and the label below ?
+ }
+
+ get_device(phy-dev);
+
+err0:
+ return phy;
+}
+EXPORT_SYMBOL_GPL(phy_get);
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
new file mode 100644
index 000..0cb2298
--- /dev/null
+++ b/include/linux/phy/phy.h
@@ -0,0 +1,237 @@
+/*
+ * phy.h -- generic phy header file
[...]
+#ifndef __DRIVERS_PHY_H
+#define __DRIVERS_PHY_H
+
+#includelinux/err.h
+#includelinux/of.h
+
+struct phy
I think you also need to add either
#include linux/device.h
or
struct device;
struct device * is used further in this file.
+/**
+ * struct phy_ops - set of function pointers for performing phy operations
+ * @init: operation to be performed for initializing phy
+ * @exit: operation to be performed while exiting
+ * @suspend: suspending the phy
+ * @resume: resuming the phy
+ * @poweron: powering on the phy
+ * @shutdown: shutting down the phy
Could these be named power_on/power_off ? Looks a bit more symmetric
to me that way.
+ * @owner: the module owner containing the ops
+ */
+struct phy_ops {
+ int (*init)(struct phy *phy);
+ int (*exit)(struct phy *phy);
+ int (*suspend)(struct phy *phy);
+ int (*resume)(struct phy *phy);
+ int (*poweron)(struct phy *phy);
+ int (*shutdown)(struct phy *phy);
+ struct module *owner;
+};
Thanks,
Sylwester
--
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 RESEND] ARM: OMAP1: fix omap_udc registration
omap_udc platform device is not registered properly anymore:
CONFIG_USB_GADGET_OMAP was deleted by 193ab2a6 (usb: gadget: allow
multiple gadgets to be built) already in v3.1.
Fix by using CONFIG_USB_OMAP instead. Tested on Nokia 770 by checking
that omap_udc is probed working properly when built as a module.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
Patch history:
v2: http://marc.info/?t=13626631986r=1w=2
- use IS_ENABLED()
v1: http://marc.info/?t=13626088666r=1w=2
arch/arm/mach-omap1/include/mach/usb.h |2 +-
arch/arm/mach-omap1/usb.c |6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/include/mach/usb.h
b/arch/arm/mach-omap1/include/mach/usb.h
index 753cd5c..45e5ac7 100644
--- a/arch/arm/mach-omap1/include/mach/usb.h
+++ b/arch/arm/mach-omap1/include/mach/usb.h
@@ -2,7 +2,7 @@
* FIXME correct answer depends on hmc_mode,
* as does (on omap1) any nonzero value for config-otg port number
*/
-#ifdef CONFIG_USB_GADGET_OMAP
+#if IS_ENABLED(CONFIG_USB_OMAP)
#defineis_usb0_device(config) 1
#else
#defineis_usb0_device(config) 0
diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c
index 1a1db59..4118db5 100644
--- a/arch/arm/mach-omap1/usb.c
+++ b/arch/arm/mach-omap1/usb.c
@@ -123,7 +123,7 @@ omap_otg_init(struct omap_usb_config *config)
syscon = omap_readl(OTG_SYSCON_1);
syscon |= HST_IDLE_EN|DEV_IDLE_EN|OTG_IDLE_EN;
-#ifdef CONFIG_USB_GADGET_OMAP
+#if IS_ENABLED(CONFIG_USB_OMAP)
if (config-otg || config-register_dev) {
struct platform_device *udc_device = config-udc_device;
int status;
@@ -169,7 +169,7 @@ omap_otg_init(struct omap_usb_config *config)
void omap_otg_init(struct omap_usb_config *config) {}
#endif
-#ifdef CONFIG_USB_GADGET_OMAP
+#if IS_ENABLED(CONFIG_USB_OMAP)
static struct resource udc_resources[] = {
/* order is significant! */
@@ -600,7 +600,7 @@ static void __init omap_1510_usb_init(struct
omap_usb_config *config)
while (!(omap_readw(ULPD_DPLL_CTRL) DPLL_LOCK))
cpu_relax();
-#ifdef CONFIG_USB_GADGET_OMAP
+#if IS_ENABLED(CONFIG_USB_OMAP)
if (config-register_dev) {
int status;
--
1.7.10.4
--
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: OMAP: RX-51: add missing regulator supply definitions for lis3lv02d
Add missing regulator definitions for lis3lv02d accelerometer. Fixes
the following probe issue:
[ 57.737518] lis3lv02d_i2c 3-001d: Failed to get supply 'Vdd': -517
[ 57.747100] i2c 3-001d: Driver lis3lv02d_i2c requests probe deferral
Reported-by: Pali Rohár pali.ro...@gmail.com
Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
The patch was discussed in this thread...
http://marc.info/?t=13610584241r=1w=2
...and now sending it to relevant mailing lists.
arch/arm/mach-omap2/board-rx51-peripherals.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 3a077df..1a88467 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -547,12 +547,16 @@ static struct regulator_consumer_supply
rx51_vio_supplies[] = {
REGULATOR_SUPPLY(DVDD, 2-0019),
/* Si4713 IO supply */
REGULATOR_SUPPLY(vio, 2-0063),
+ /* lis3lv02d */
+ REGULATOR_SUPPLY(Vdd_IO, 3-001d),
};
static struct regulator_consumer_supply rx51_vaux1_consumers[] = {
REGULATOR_SUPPLY(vdds_sdi, omapdss),
/* Si4713 supply */
REGULATOR_SUPPLY(vdd, 2-0063),
+ /* lis3lv02d */
+ REGULATOR_SUPPLY(Vdd, 3-001d),
};
static struct regulator_init_data rx51_vaux1 = {
--
1.7.10.4
--
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: [RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two
On Mon, Apr 1, 2013 at 6:41 PM, Christoph Fritz
chf.fr...@googlemail.com wrote:
Hi Javier
On Sat, 2013-03-30 at 14:18 +0100, Javier Martinez Canillas wrote:
A call to gpio_request() to enable the GPIO bank is needed before
using a GPIO as an IRQ source, otherwise accesses to the GPIO bank
registers fails making the kernel to hang.
Yes, that is exactly my problem here. I'm using the GPIO as an IRQ
source.
Jon's (added as cc)gpio/omap: warn if bank is not enabled on setting
irq type patch [1] fixes the issue by warning and returning -EINVAL.
This patch will make the kernel to boot but the call to request_irq()
will fail of course. For now, the only solution is to call
gpio_request() before request_irq() in your platform code or device
driver. There is an on going discussion about what's the better way to
address this but we still haven't found a good solution to this
problem, you can see the last email for this discussion here [2]
Also, even when calling gpio_request() before request_irq() this won't
work. When specifying the trigger/level flags on the second cell for
an GPIO-IRQ, this is not set on the IORESOURCE_IRQ struct resource.
The IRQ flag is set on of_irq_to_resource() but it just does:
r-flags = IORESOURCE_IRQ;
and then the call stack is irq_to_parse_and_map() -
irq_set_irq_type() - __irq_set_trigger() - chip-irq_set_type() -
(drivers/gpio/gpio-omap.c) gpio_irq_type().
So, even when gpio_irq_type() receive the correct flags, this are not
returned neither stored on the flags member of the IORESOURCE_IRQ
struct resource that passed to the drivers in their struct
platform_device.
As a quick-fix (hack) I wrote directly to the registers in gpio_probe()
to enable GPIO banks. I now geht this:
[0.214630] omap_gpio_probe, 1133, CM_CLKSEL_PER 0x48005040: 0x00ff
[0.214660] omap_gpio_probe, 1136, CM_ICLKEN_PER 0x48005010: 0x0007
[0.214660] omap_gpio_probe, 1139, CM_FCLKEN_PER 0x48005000: 0x0007
And it works for me. _But_ when I do enable regulator twl4030
(CONFIG_REGULATOR_TWL4030=y) in my config these registers get reset:
[2.935455] smsc911x_open, 1537, CM_CLKSEL_PER 0x48005040: 0x00ff
[2.942291] smsc911x_open, 1540, CM_ICLKEN_PER 0x48005010: 0x00040fff
[2.949066] smsc911x_open, 1543, CM_FCLKEN_PER 0x48005000: 0x
And the IRQ source for the network chip (smsc911x) is disabled :-(
Do you have any idea how to (quick) fix this?
A quick hack is to call gpio_request() explicitly before calling to
irq_set_type() is made.
I've this patch just to make it work until we find a clean solution:
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 90c15ee..d594e1d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -14,6 +14,7 @@
*/
#undef DEBUG
+#include linux/gpio.h
#include linux/irq.h
#include linux/kernel.h
#include linux/init.h
@@ -1528,6 +1529,11 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
+ ret = gpio_request_one(176, GPIOF_IN, smsc911x irq);
+ if (ret) {
+ pr_err(Failed to request IRQ GPIO%d\n, 176);
+ return ret;
+ }
+
for_each_node_by_name(child, nand) {
ret = gpmc_probe_nand_child(pdev, child);
if (ret 0) {
This solves the issue of the non-initialized GPIO bank before that
makes the kernel to hang. Since I've to configure the IRQ polarity as
active low level-sensitive on my board and the flags are not set by
the IRQ core, I've another ugly hack that forces this:
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc
index da5cc9a..27e46f9 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -2390,6 +2390,9 @@ static int smsc911x_drv_probe(struct
platform_device *pdev)
pdata = netdev_priv(dev);
dev-irq = irq_res-start;
-irq_flags = irq_res-flags IRQF_TRIGGER_MASK;
+ irq_flags = IRQF_TRIGGER_LOW;
pdata-ioaddr = ioremap_nocache(res-start, res_size);
pdata-dev = dev;
Thanks
-- Christoph
I hope to find some time this week to work on this and at least find a
solution for the second issue (IORESOURCE_IRQ struct resource flags
not being set).
Best regards,
Javier
--
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] OMAP3 ROM Random Number Generator support
It could be that I am misreading something, but RX51 is OMAP3.
Regards,
Ivo
Оригинално писмо
От: Tony Lindgren
Относно: Re: [PATCH] OMAP3 ROM Random Number Generator support
До: Ивайло Димитров
Изпратено на: Понеделник, 2013, Април 1 19:59:50 EEST
* Ивайло Димитров [130331 05:10]:
Hi Pali,
Yep, the code looks almost identical, I guess with some tweaks all SMC code
from that patch could be removed and instead used the one from SMC PPA API.
What I don't get, is why one needs to disable/enable fiqs/irqs:
+static int call_sec_rom(u32 appl_id, u32 proc_id, u32 flag, ...)
+{
+ va_list ap;
+ u32 ret;
+ u32 val;
+
+ va_start(ap, flag);
+ val = *(u32 *) amp;ap;
+ local_irq_disable();
+ local_fiq_disable();
+ ret = omap3_rom_rng_call(appl_id, proc_id, flag,
+(u32) virt_to_phys((void *) val));
+ local_fiq_enable();
+ local_irq_enable();
+ va_end(ap);
+
+ return ret;
+}
Do you have any idea why is that needed? Any other code I've ever seen to
call SM, does not disable fiqs/irqs, is RNG SMC somehow special? I know
this is Nokia's code, but still, if we can get some understanding...
Sounds like the fiq handling can be dropped based on what
the TI guys posted recently about FIQs only be available in
the secure mode starting with omap2.
Regards,
Tony
--
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: [RFC][PATCH 0/5] Introduce .get_voltage callback into voltdm
On Sat, Mar 30, 2013 at 7:35 PM, Paul Walmsley p...@pwsan.com wrote: Hi Mike, Kevin, On Wed, 3 Oct 2012, Mike Turquette wrote: From: Mike Turquette mturque...@linaro.org This series creates a new callback for struct voltagedomain, .get_voltage. This fetches the voltage from hardware, if possible, and returns it to the caller. We use this call to populate voltdm-nominal_volt at boot time. Just checking on the status of this series. Is this superseded by Andrii's driver? Does it need to be reposted for merging? etc. Hi Paul, Thanks for resurrecting this thread. This series is needed if the ABB transition is triggered by the OMAP VC/VP code. Andrii's approach triggers an ABB transition based on the clock rate-change notifiers but that is still in discussion. So the short answer is I don't know yet. Regards, Mike - Paul -- 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] OMAP3 ROM Random Number Generator support
Hi, On Sun, Mar 31, 2013 at 03:05:42PM +0300, Ивайло Димитров wrote: Yep, the code looks almost identical, I guess with some tweaks all SMC code from that patch could be removed and instead used the one from SMC PPA API. What I don't get, is why one needs to disable/enable fiqs/irqs: [..] Do you have any idea why is that needed? Any other code I've ever seen to call SM, does not disable fiqs/irqs, is RNG SMC somehow special? I know this is Nokia's code, but still, if we can get some understanding... I think without disabling irqs you may suffer some strange crashes when heavily stressing the RNG... that's why you also have cache flushes before and after the SMC. With proper test suite you could probably verify this. How are you testing this driver? 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
[PATCH v2 02/13] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
From: Rob Herring rob.herr...@calxeda.com
This converts arm and arm64 to use CLKSRC_OF DT based initialization for
the arch timer. A new function arch_timer_arch_init is added to allow for
arch specific setup.
This has a side effect of enabling sched_clock on omap5 and exynos5. There
should not be any reason not to use the arch timers for sched_clock.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Kukjin Kim kgene@samsung.com
Cc: Tony Lindgren t...@atomide.com
Cc: Simon Horman ho...@verge.net.au
Cc: Magnus Damm magnus.d...@gmail.com
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Cc: John Stultz john.stu...@linaro.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux...@vger.kernel.org
---
arch/arm/include/asm/arch_timer.h| 13 +
arch/arm/kernel/arch_timer.c | 17 +++--
arch/arm/mach-exynos/mach-exynos5-dt.c |1 -
arch/arm/mach-exynos/mct.c |6 --
arch/arm/mach-highbank/highbank.c|5 +
arch/arm/mach-omap2/timer.c |5 +
arch/arm/mach-shmobile/board-kzm9d.c |1 -
arch/arm/mach-shmobile/include/mach/common.h |1 -
arch/arm/mach-shmobile/setup-emev2.c |1 -
arch/arm/mach-shmobile/setup-r8a7740.c |1 -
arch/arm/mach-shmobile/setup-sh7372.c|1 -
arch/arm/mach-shmobile/setup-sh73a0.c|1 -
arch/arm/mach-shmobile/timer.c |6 --
arch/arm/mach-vexpress/v2m.c |7 ++-
arch/arm/mach-virt/virt.c|9 -
arch/arm64/include/asm/arch_timer.h |5 +
arch/arm64/kernel/time.c |6 --
drivers/clocksource/Kconfig |1 +
drivers/clocksource/arm_arch_timer.c | 23 +--
include/clocksource/arm_arch_timer.h |6 --
20 files changed, 27 insertions(+), 89 deletions(-)
diff --git a/arch/arm/include/asm/arch_timer.h
b/arch/arm/include/asm/arch_timer.h
index 7ade91d..7c1bfc0 100644
--- a/arch/arm/include/asm/arch_timer.h
+++ b/arch/arm/include/asm/arch_timer.h
@@ -10,8 +10,7 @@
#include clocksource/arm_arch_timer.h
#ifdef CONFIG_ARM_ARCH_TIMER
-int arch_timer_of_register(void);
-int arch_timer_sched_clock_init(void);
+int arch_timer_arch_init(void);
/*
* These register accessors are marked inline so the compiler can
@@ -110,16 +109,6 @@ static inline void __cpuinit
arch_counter_set_user_access(void)
asm volatile(mcr p15, 0, %0, c14, c1, 0 : : r (cntkctl));
}
-#else
-static inline int arch_timer_of_register(void)
-{
- return -ENXIO;
-}
-
-static inline int arch_timer_sched_clock_init(void)
-{
- return -ENXIO;
-}
#endif
#endif
diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
index a7536d4..dc74048 100644
--- a/arch/arm/kernel/arch_timer.c
+++ b/arch/arm/kernel/arch_timer.c
@@ -39,26 +39,15 @@ static void __init arch_timer_delay_timer_register(void)
register_current_timer_delay(arch_delay_timer);
}
-int __init arch_timer_of_register(void)
-{
- int ret;
-
- ret = arch_timer_init();
- if (ret)
- return ret;
-
- arch_timer_delay_timer_register();
-
- return 0;
-}
-
-int __init arch_timer_sched_clock_init(void)
+int __init arch_timer_arch_init(void)
{
u32 arch_timer_rate = arch_timer_get_rate();
if (arch_timer_rate == 0)
return -ENXIO;
+ arch_timer_delay_timer_register();
+
/* Cache the sched_clock multiplier to save a divide in the hot path. */
sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
sched_clock_func = arch_timer_sched_clock;
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index acaeb14..4d97b43 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -216,7 +216,6 @@ DT_MACHINE_START(EXYNOS5_DT, SAMSUNG EXYNOS5 (Flattened
Device Tree))
.map_io = exynos5_dt_map_io,
.init_machine = exynos5_dt_machine_init,
.init_late = exynos_init_late,
- .init_time = exynos4_timer_init,
.dt_compat = exynos5_dt_compat,
.restart= exynos5_restart,
.reserve= exynos5_reserve,
diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
index c9d6650..04aff6a 100644
--- a/arch/arm/mach-exynos/mct.c
+++ b/arch/arm/mach-exynos/mct.c
@@ -21,7 +21,6 @@
#include linux/percpu.h
#include linux/of.h
-#include asm/arch_timer.h
#include asm/localtimer.h
#include plat/cpu.h
@@ -469,11 +468,6 @@ static void __init exynos4_timer_resources(void)
void __init exynos4_timer_init(void)
{
- if (soc_is_exynos5440()) {
-
Re: [PATCH v4 1/6] drivers: phy: add generic PHY framework
On 03/28/2013 06:43 AM, Kishon Vijay Abraham I wrote:
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt
b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 000..35696b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,76 @@
+This document explains only the dt data binding. For general information about
+PHY subsystem refer Documentation/phy.txt
+
+PHY device node
+===
+
+Optional Properties:
+#phy-cells:Number of cells in a PHY specifier; The meaning of all those
+ cells is defined by the binding for the phy node. However
+ in-order to return the correct PHY, the PHY susbsystem
+ requires the first cell always refers to the port.
+
+This property is optional because it is needed only for the case where a
+single IP implements multiple PHYs.
+
+For example:
+
+phys: phy {
+compatible = xxx;
+reg1 =...;
+reg2 =...;
+reg3 =...;
+.
+.
+#phy-cells =1;
+.
+.
+};
+
+That node describes an IP block that implements 3 different PHYs. In order to
+differentiate between these 3 PHYs, an additonal specifier should be given
+while trying to get a reference to it. (The PHY subsystem assumes the
+specifier is port id).
+
+PHY user node
+=
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+
+Optional properties:
+phy-names : the names of the PHY corresponding to the PHYs present in the
+ *phys* phandle
+
+example1:
+phys: phy {
+compatible = xxx;
+reg =...;
+.
+.
+phys =usb2_phy,usb3_phy;
+phy-names = usb2phy, usb3phy;
+.
+.
+};
+This node represents a controller that uses two PHYs one for usb2 and one for
+usb3. The controller driver can get the appropriate PHY either by using
+devm_of_phy_get/of_phy_get by passing the correct index or by using
+of_phy_get_byname/devm_of_phy_get_byname by passing the names given in
+*phy-names*.
+
+example2:
+phys: phy {
+compatible = xxx;
+reg =...;
+.
+.
+phys =phys 1;
+.
+.
+};
+
+This node represents a controller that uses one of the PHYs which is defined
+previously. Note that the phy handle has an additional specifier 1 to
+differentiate between the three PHYs. For this case, the controller driver
+should use of_phy_get_with_args/devm_of_phy_get_with_args.
This means a PHY user needs to know indexes at the PHY driver ?
I have been thinking of using this for an IP which has 4 video PHYs: 2 MIPI
CSI-2 and 2 MIPI DSI. The IP has just 2 registers, each of which is shared
between one MIPI CSI-2 DPHY and one MIPI DSI DPHY. So I thought about
creating
a single device node for this IP and using 4 indexes for the PHYs, e.g.
0...3.
Then users of each PHY type would use only indexes 0..1 (to select their
corresponding port).
However I fail to see how this could now be represented in the bindings.
I assume struct phy::type could be used to differentiate between CSI-2
and DSI.
And struct phy::port could be used to select specific CSI-2 or DSI channel
(0, 1). Ideally the phy users should not care about index of a PHY at
the PHY
device tree node. E.g. there are 2 MIPI CSI-2 receivers and each has only
one PHY assigned to it. I'm just wondering how the binding should look like,
so a PHY could be associated with a receiver automatically by the phy-core,
e.g.
/* DPHY IP node */
video-phy {
reg = 0x1000 8;
};
/* MIPI DSI nodes */
dsi_0 {
phys = video-phy 0;
};
dsi_1 {
phys = video-phy 1;
};
/* MIPI CSI-2 nodes */
csi_0 {
phys = video-phy 2;
};
csi_1 {
phys = video-phy 3;
};
I'm not sure if it is not an overkill to use this the PHY framework with
a device which has only 2 registers. Perhaps something less heavy could
be designed for it. However, if the PHY framework is commonly used there
should be no issue wrt enabling the whole big infrastructure for a simple
device like this.
Thanks,
Sylwester
--
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 v4 1/6] drivers: phy: add generic PHY framework
On 04/01/2013 04:27 PM, Sylwester Nawrocki wrote:
On 03/28/2013 06:43 AM, Kishon Vijay Abraham I wrote:
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt
+example2:
+phys: phy {
+compatible = xxx;
+reg =...;
+.
+.
+phys =phys 1;
+.
+.
+};
+
+This node represents a controller that uses one of the PHYs which is defined
+previously. Note that the phy handle has an additional specifier 1 to
+differentiate between the three PHYs. For this case, the controller driver
+should use of_phy_get_with_args/devm_of_phy_get_with_args.
This means a PHY user needs to know indexes at the PHY driver ?
The client node's DT has to specify which of the provider's PHYs it
references, yes. Presumably the device driver for the client node knows
absolutely nothing about this.
I have been thinking of using this for an IP which has 4 video PHYs: 2 MIPI
CSI-2 and 2 MIPI DSI. The IP has just 2 registers, each of which is shared
between one MIPI CSI-2 DPHY and one MIPI DSI DPHY. So I thought about creating
a single device node for this IP and using 4 indexes for the PHYs, e.g. 0...3.
That sounds right.
Then users of each PHY type would use only indexes 0..1 (to select their
corresponding port).
I don't follow that. If the provider exports PHYs 0..3, then the client
nodes would refer to PHYS 0..3 not 0..1.
However I fail to see how this could now be represented in the bindings.
Exactly like the example you gave below, I would expect.
I assume struct phy::type could be used to differentiate between CSI-2 and
DSI.
And struct phy::port could be used to select specific CSI-2 or DSI channel
(0, 1). Ideally the phy users should not care about index of a PHY at the PHY
device tree node. E.g. there are 2 MIPI CSI-2 receivers and each has only
one PHY assigned to it. I'm just wondering how the binding should look like,
so a PHY could be associated with a receiver automatically by the phy-core,
e.g.
Details such as phy::type and phy::port sounds like internal driver
implementation details which would have no effect on the bindings.
/* DPHY IP node */
video-phy {
reg = 0x1000 8;
};
/* MIPI DSI nodes */
dsi_0 {
phys = video-phy 0;
};
dsi_1 {
phys = video-phy 1;
};
/* MIPI CSI-2 nodes */
csi_0 {
phys = video-phy 2;
};
csi_1 {
phys = video-phy 3;
};
That looks correct to me.
I'm not sure if it is not an overkill to use this the PHY framework with
a device which has only 2 registers. Perhaps something less heavy could
be designed for it. However, if the PHY framework is commonly used there
should be no issue wrt enabling the whole big infrastructure for a simple
device like this.
I don't think the number of registers should really makes any
difference; the whole point of the PHY framework is to decouple to
providers and consumers, so doing anything custom for special cases
would completely destroy the ability of the PHY framework to do that.
--
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: [RFC PATCH 5/6] ARM: OMAP3+: ABB: introduce ABB driver
On 14:34-20130401, Mike Turquette wrote: Quoting Nishanth Menon (2013-04-01 12:28:20) On Mon, Apr 1, 2013 at 1:10 PM, Mike Turquette mturque...@linaro.org wrote: Let's figure out what is happening to the VC/VP code first and then figure out what to do about ABB. http://picpaste.com/KmqDYTn0.jpg is an quick depiction of the thought I have in my mind. OK, looks like the Super Regulator Approach(tm). :D I hope it can be modelled after TI SoCs and then expanded to other SoCs as needed. We do have, in the upcoming SoCs, where Nominal Voltages per device, will now be encoded into the efuse itself(so called class 0 voltage). Future SoCs will need to be able to use ABB along with standard regulators (without use of VC-VP) - in fact, even today, SoCs like AM and DM series of processors have the same requirement. This de-linking of ABB from VC/VP probably supports modeling ABB ldo's as Linux regulators. That would provide a common interface where either the VC/VP code or another regulator could call something like regulator_set_mode. If we're going to export something which can get called by different actors it's best to use an already exported interface which the regulator framework supplies, instead of exporting something new and omap-specific. Yep - that was my original thought - though modeling it as a regulator in itself is, IMHO, I think is a good idea. We also will have to support class 2 variants of AVS (which will use standard regulators to set voltage). As of date, CCF does not control regulators - which means the interim solution would be for the device control to manipulate both clock and regulator voltage (similar to what cpufreq-cpu0 driver does today). these drivers should not know the existance of SoC specific intricacies - so ABB linked to voltage values make more sense if ABB sequencing is handled in TI regulator Intent of VC/VP regulator is to be replaceable, on required platforms, with appropriate regulator which do not use VC/VP paths (e.g. on SoCs that do not have it). Well if everything is nicely modeled then I suppose per-board and per-soc DT will give you the ability to link things up nicely. E.g. replacing VC/VP with an external physical LDO, etc. True - that is precisely what are attempting to do in (hopefully) edible stages :). -- 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
[GIT PULL] ARM: OMAP2+: System timer updates
The following changes since commit 2d61aecee8f32259920cdf90a452fa26ffc64e9f: Merge commit '6bb27d7349db51b50c40534710fe164ca0d58902' into omap-timer-for-v3.10 (2013-04-01 13:47:29 -0500) are available in the git repository at: git://github.com/jonhunter/linux.git omap-timer-for-v3.10 for you to fetch changes up to 4615943cf3a531bc76f589c22bd366da092b7c0f: ARM: OMAP4+: Fix sparse warning in system timers (2013-04-01 13:49:46 -0500) This series consists mainly of clean-ups for clockevents and clocksource timers on OMAP2+ devices. The most significant change in functionality comes from the 5th patch which is changing the selection of the clocksource timer for OMAP3 and AM335x devices when gptimers are used for clocksource. This series is dependent on commit 7185684 (ARM: OMAP: use consistent error checking) from RMK's clean-up branch and commit 6bb27d7 (ARM: delete struct sys_timer) Jon Hunter (7): ARM: OMAP2+: Display correct system timer name ARM: OMAP2+: Remove hard-coded test on timer ID ARM: OMAP2+: Simplify system timer clock definitions ARM: OMAP2+: Simplify system timers definitions ARM: OMAP3: Update clocksource timer selection ARM: OMAP2+: Store ID of system timers in timer structure ARM: OMAP4+: Fix sparse warning in system timers arch/arm/mach-omap2/board-cm-t3517.c |2 +- arch/arm/mach-omap2/board-generic.c |2 +- arch/arm/mach-omap2/common.h |3 +- arch/arm/mach-omap2/timer.c | 121 +- 4 files changed, 65 insertions(+), 63 deletions(-) -- 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 v2 02/13] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
On Tuesday 02 April 2013 03:51 AM, Rob Herring wrote: From: Rob Herring rob.herr...@calxeda.com This converts arm and arm64 to use CLKSRC_OF DT based initialization for the arch timer. A new function arch_timer_arch_init is added to allow for arch specific setup. This has a side effect of enabling sched_clock on omap5 and exynos5. There should not be any reason not to use the arch timers for sched_clock. Absolutely. Signed-off-by: Rob Herring rob.herr...@calxeda.com [..] arch/arm/mach-omap2/timer.c |5 + Acked-by: Santosh Shilimkar santosh.shilim...@ti.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
Re: [RFC PATCH 5/6] ARM: OMAP3+: ABB: introduce ABB driver
On 17:05-20130401, Mike Turquette wrote: OK, so we're in agreement on what The Future looks like. What does that mean for Andrii's patchset? Unless anyone has an fundamental issue with the approach of an Super regulator controlling sub regulators, I think, in-line with your view, we should probably make ABB as an regulator instead of inventing our own API and hooking it around clock notifiers. -- 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
