Re: [PATCH] Input: ads7846: add regulator support
Mark Brown wrote: On Fri, Feb 05, 2010 at 10:45:09PM +0200, Mike Rapoport wrote: On Thu, Feb 4, 2010 at 6:21 PM, Mark Brown The bodge I'm thinking of would do something like log an error and substitute in a dummy regulator when regulator_get() would have failed so that the driver sees behaviour equivalent to the stubbed regulator API if the bodge is active. A central thing seems much more sensible here - there's nothing specific to this driver going on here and having the API behave in a consistent manner seems good. I agree that such approach have more sense than checking for -ENODEV in each and every driver that uses the regulator framework. I just wonder, if there should be some mechanism that can switch the substitution of the dummy regulators on and off. And if yes, how should the platform code communicate with the regulator core the need for such dummy regulators... So, having thought about this a bit more we actually have two different use cases here. One is where you've got a system which has software controllable regulators for everything but may not have plumbed in all the supplies, the other is for systems where only a very few supplies are on software controlled regulators which are just trying to save the hassle of hooking up the bulk of the supplies to fixed voltage regulators. These two use cases should probably be handled differently - the first one is really expected to have all the supplies hooked up and so should warn when using the bodge regulator but the warning isn't helpful in the second case. Sounds right to me. We already have some support for boards to set up the API in the form of regulator_set_full_constraints() so we could do something similar for dummy regulators, or create a new single API to set a bunch of options via a struct which is probably less hassle going forward. Struct sounds more reasonable that just a call to e.g. regulator_warn_dummy_fixed_regulator :) -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sincerely yours, Mike. -- 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
OMAP3 Slave McSPI driver
Hi, My customer is using Android 2.6.29 kernel from OMAPZOOM and is looking for support for slave mode on the SPI driver. I saw there were patches for this feature sent to this list, but I was wondering if those patches were tested on 2.6.29. I am also looking for some kind of API usage guidelines. How to setup the slave mode and how is OMAP notified that data have been received from external master device? My customer plans to use this driver in interrupt mode (no DMA needed). Thanks Gilels. Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -- 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
Ubuntu installation on omap
Hi, I am trying to install ubuntu on my beagleboard. i installed successfully and it is booting fine. But after booting the graphics which i get is not good. It has some graphics problem. And how can work on ubuntu in board with my mouse and keyboard? If i insert mouse and keyboard to board it is not working. only my serial port is working. just i am getting login screen in my monitor.Please help me. -- 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 14/17] OMAP: DSS2: move enable/disable/suspend/resume
On Mon, Feb 8, 2010 at 5:57 PM, Tomi Valkeinen tomi.valkei...@nokia.com wrote:
Move enable/disable/suspend/resume from omap_dss_device to
omap_dss_driver.
This is part of a larger patch-set, which moves the control from omapdss
driver to the display driver.
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
snip
diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index f297a46..c6e4a7e 100644
--- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
@@ -262,18 +262,20 @@ static const struct omap_video_timings
tpo_td043_timings = {
.vbp = 34,
};
-static int tpo_td043_enable(struct omap_dss_device *dssdev)
+static int generic_panel_power_on(struct omap_dss_device *dssdev)
I guess you meant tpo_td043_power_on/tpo_td043_power_off?
I'll try to test your both series later this week.
--
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: Ubuntu installation on omap
I followed thid only. In that i have this doubts On Tue, Feb 9, 2010 at 3:24 PM, Jochen Terbeck jterb...@ela-soft.com wrote: See http://www.elinux.org/BeagleBoardUbuntu Niamathullah sharief schrieb: Hi, I am trying to install ubuntu on my beagleboard. i installed successfully and it is booting fine. But after booting the graphics which i get is not good. It has some graphics problem. And how can work on ubuntu in board with my mouse and keyboard? If i insert mouse and keyboard to board it is not working. only my serial port is working. just i am getting login screen in my monitor.Please help me. -- 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 -- 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
[PATCHV3] OMAP3630: Clock: Workaround for DPLL HS divider limitation
From: Mike Turquette mturque...@ti.com
Date: Fri, 5 Feb 2010 19:09:52 +0530
Subject: [PATCH] OMAP3630: Clock: Workaround for DPLL HS divider limitation
This patch implements a workaround for the DPLL HS divider limitation
in OMAP3630 as given by Errata ID: i556.
Errata:
When PWRDN bit is set, it resets the internal HSDIVIDER divide-by value (Mx).
The reset value gets loaded instead of the previous value.
The following HSDIVIDERs exhibit above behavior:
. DPLL4 : M6 / M5 / M4 / M3 / M2 (CM_CLKEN_PLL[31:26] register bits)
. DPLL3 : M3 (CM_CLKEN_PLL[12] register bit).
Work Around:
It is mandatory to apply the following sequence to ensure the write
value will
be loaded in DPLL HSDIVIDER FSM:
The global sequence when using PWRDN bit is the following:
. Disable Mx HSDIVIDER clock output related functional clock enable bits
(in CM_FCLKEN_xxx / CM_ICLKEN_xxx)
. Enable PWRDN bit of HSDIVIDER
. Disable PWRDN bit of HSDIVIDER
. Read current HSDIVIDER register value
. Write different value in HSDIVIDER register
. Write expected value in HSDIVIDER register
. Enable Mx HSDIVIDER clock output related functional clocks
(CM_FCLKEN_xxx / CM_ICLKEN_xxx)
Signed-off-by: Mike Turquette mturque...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Vijaykumar GN vijaykumar...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 41 ++
arch/arm/mach-omap2/clock34xx.h |1 +
arch/arm/mach-omap2/clock34xx_data.c | 20
3 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index c1c1b93..1e6297f 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -133,6 +133,47 @@ const struct clkops clkops_omap3430es2_hsotgusb_wait = {
.find_companion = omap2_clk_dflt_find_companion,
};
+/**
+ * omap3_pwrdn_clk_enable_with_hsdiv_restore - enable clocks suffering
+ * from HSDivider PWRDN problem Implements Errata ID: i556.
+ * @clk: DPLL output struct clk
+ *
+ * 3630 only: dpll3_m3_ck, dpll4_m2_ck, dpll4_m3_ck, dpll4_m4_ck, dpll4_m5_ck
+ * dpll4_m6_ck dividers gets loaded with reset valueafter their respective
+ * PWRDN bits are set.
+ * Any dummy write (Any other value different from the Read value) to the
+ * corresponding CM_CLKSEL register will refresh the dividers.
+ */
+int omap3_pwrdn_clk_enable_with_hsdiv_restore(struct clk *clk)
+{
+ u32 dummy_v, orig_v, clksel_shift;
+ int ret;
+
+ /* Enable PWRDN bit of HSDIVIDER */
+ ret = omap2_dflt_clk_enable(clk);
+
+ /* Restore the dividers */
+ if (!ret) {
+ clksel_shift = __ffs(clk-parent-clksel_mask);
+ orig_v = dummy_v = __raw_readl(clk-parent-clksel_reg);
+
+ /* Write any other value different from the Read value */
+ dummy_v ^= (1 clksel_shift);
+ __raw_writel(dummy_v, clk-parent-clksel_reg);
+
+ /* Write the original divider */
+ __raw_writel(orig_v, clk-parent-clksel_reg);
+ }
+ return ret;
+}
+
+const struct clkops clkops_omap3_pwrdn_with_hsdiv_wait_restore = {
+ .enable = omap3_pwrdn_clk_enable_with_hsdiv_restore,
+ .disable= omap2_dflt_clk_disable,
+ .find_companion = omap2_clk_dflt_find_companion,
+ .find_idlest= omap2_clk_dflt_find_idlest,
+};
+
const struct clkops omap3_clkops_noncore_dpll_ops = {
.enable = omap3_noncore_dpll_enable,
.disable= omap3_noncore_dpll_disable,
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 313efc0..29ef390 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -21,5 +21,6 @@ extern const struct clkops clkops_omap3430es2_ssi_wait;
extern const struct clkops clkops_omap3430es2_hsotgusb_wait;
extern const struct clkops clkops_omap3430es2_dss_usbhost_wait;
extern const struct clkops omap3_clkops_noncore_dpll_ops;
+extern const struct clkops clkops_omap3_pwrdn_with_hsdiv_wait_restore;
#endif
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index 8728f1f..9d11d53 100644
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -3240,6 +3240,26 @@ int __init omap3xxx_clk_init(void)
}
}
+ if (cpu_is_omap3630()) {
+
+ /*
+* For 3630: override clkops_omap2_dflt_wait for the
+* clocks affected from PWRDN reset Limitation
+*/
+ dpll3_m3x2_ck.ops =
+ clkops_omap3_pwrdn_with_hsdiv_wait_restore;
+ dpll4_m2x2_ck.ops =
+ clkops_omap3_pwrdn_with_hsdiv_wait_restore;
+ dpll4_m3x2_ck.ops =
+ clkops_omap3_pwrdn_with_hsdiv_wait_restore;
+ dpll4_m4x2_ck.ops
Re: [PATCH 14/17] OMAP: DSS2: move enable/disable/suspend/resume
On Tue, 2010-02-09 at 11:15 +0100, ext Grazvydas Ignotas wrote:
On Mon, Feb 8, 2010 at 5:57 PM, Tomi Valkeinen tomi.valkei...@nokia.com
wrote:
Move enable/disable/suspend/resume from omap_dss_device to
omap_dss_driver.
This is part of a larger patch-set, which moves the control from omapdss
driver to the display driver.
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
snip
diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index f297a46..c6e4a7e 100644
--- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
@@ -262,18 +262,20 @@ static const struct omap_video_timings
tpo_td043_timings = {
.vbp= 34,
};
-static int tpo_td043_enable(struct omap_dss_device *dssdev)
+static int generic_panel_power_on(struct omap_dss_device *dssdev)
I guess you meant tpo_td043_power_on/tpo_td043_power_off?
Yes, copy paste error =)
I'll try to test your both series later this week.
Thanks.
Tomi
--
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] DSPBRIDGE: Prevent memory corruption in DRV_ProcFreeDMMRes
On Mon, Feb 8, 2010 at 10:25 PM, Ameya Palande ameya.pala...@nokia.com wrote: Background: bridge_close() has the responsibility to cleanup all the resources allocated by user space process. One of those resources is DMMRes which is used for tracking DMM resource allocation done in PROC_Map() and PROC_UnMap(). DRV_ProcFreeDMMRes() function was used for cleaning up DMMRes has following problems which are fixed by this patch: 1. It access and modifies pDMMRes pointer when it is already freed by PROC_UnMap() 2. Instead of passing ulDSPAddr it passes ulDSPResAddr to PROC_UnMap() which will not retrive correct DMMRes element. This patch is doing the right thing to me, however, it's a bit difficult to review because it's doing many changes at once. Personally I would 1) Fix the wrong dereferences in DRV_ProcFreeDMMRes [at this point the bug should be fixed] [the leaks would be freed by the outer loop] 2) Fix the wrong PROC_UnMap address passed in DRV_ProcFreeDMMRes 3) Remove the unnecessary outer loop in DRV_RemoveAllDMMResElements [at this point the code would actually make sense] 4) Merge DRV_ProcFreeDMMRes into DRV_RemoveAllDMMResElements 5) Improve coding style The end result would be the same, but easier to see what's going on :) Cheers. -- Felipe Contreras -- 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: OMAP3 Slave McSPI driver
- Original Message - From: Talis, Gilles g-ta...@ti.com To: linux-omap@vger.kernel.org Sent: Tuesday, February 09, 2010 3:06 PM Subject: OMAP3 Slave McSPI driver Hi, My customer is using Android 2.6.29 kernel from OMAPZOOM and is looking for support for slave mode on the SPI driver. I saw there were patches for this feature sent to this list, but I was wondering if those patches were tested on 2.6.29. These patches have not been specifically tested on 29 kernel, but you could give it a shot. Pl also look at the latest patches (V2) posted. I am also looking for some kind of API usage guidelines. How to setup the slave mode and how is OMAP notified that data have been received from external master device? My customer plans to use this driver in interrupt mode (no DMA needed). To set any mcspi controller to slave mode, you need to modify arch/arm/mach-omap2/devices.c file and set mode to OMAP2_MCSPI_SLAVE. Typically gpio is used by master to notify the slave that it is ready to transfer data. On gpio interrupt slave client could issue spi_read/spi_write commands. Two modes are supported i.e PIO and DMA. Any specific reason not to use DMA mode. Thanks Hemanth Thanks Gilels. Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -- 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 -- 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: OMAP3 Slave McSPI driver
Thanks Hemanth, I'll give it a try with 2.6.29 kernel. Do the patches support McSPI RX interrupt? Or McSPI FIFO full interrupt? Upon receipt of such interrupts, slave client could issue a spi_read. Thanks gilles Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -Original Message- From: V, Hemanth Sent: Tuesday, February 09, 2010 1:59 PM To: Talis, Gilles; linux-omap@vger.kernel.org Cc: spi-devel-gene...@lists.sourceforge.net Subject: Re: OMAP3 Slave McSPI driver - Original Message - From: Talis, Gilles g-ta...@ti.com To: linux-omap@vger.kernel.org Sent: Tuesday, February 09, 2010 3:06 PM Subject: OMAP3 Slave McSPI driver Hi, My customer is using Android 2.6.29 kernel from OMAPZOOM and is looking for support for slave mode on the SPI driver. I saw there were patches for this feature sent to this list, but I was wondering if those patches were tested on 2.6.29. These patches have not been specifically tested on 29 kernel, but you could give it a shot. Pl also look at the latest patches (V2) posted. I am also looking for some kind of API usage guidelines. How to setup the slave mode and how is OMAP notified that data have been received from external master device? My customer plans to use this driver in interrupt mode (no DMA needed). To set any mcspi controller to slave mode, you need to modify arch/arm/mach-omap2/devices.c file and set mode to OMAP2_MCSPI_SLAVE. Typically gpio is used by master to notify the slave that it is ready to transfer data. On gpio interrupt slave client could issue spi_read/spi_write commands. Two modes are supported i.e PIO and DMA. Any specific reason not to use DMA mode. Thanks Hemanth Thanks Gilels. Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -- 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 -- 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: Ubuntu installation on omap
On Tue, Feb 9, 2010 at 3:41 AM, Niamathullah sharief omap...@gmail.com wrote: Hi, I am trying to install ubuntu on my beagleboard. i installed successfully and it is booting fine. But after booting the graphics which i get is not good. It has some graphics problem. Ahh, what kind of graphic problems? And how can work on ubuntu in board with my mouse and keyboard? If i insert mouse and keyboard to board it is not working. only my serial port is working. just i am getting login screen in my monitor.Please help me. Are you using a certified USB 2.0 Hub? Kernel version? As a quick verification test, use one of my demo images listed here: http://elinux.org/BeagleBoardUbuntu#Demo_Image Which have been tested on multiple Beagles (Bx's,Cx's..) Regards, -- Robert Nelson http://www.rcn-ee.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
omap3evm: Doesn't boot at 4fa42e46
Hi all, Just updated my repo to the commit: commit 4fa42e4679324b0e3c54fb509535eea3923ccb63 Merge: e599f12 c446167 Author: Tony Lindgren t...@atomide.com Date: Thu Feb 4 20:07:44 2010 -0800 The kernel builds fine; but doesn't boot on the OMAP3EVM. I have been able to trace the code until rest_init(); but will need to restart debugging. There seems to be an exception during execution. Will continue to dig further. This is just an FYI. Best regards, Sanjeev -- 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: Serial: Improved sleep logic
-Original Message-
From: ext Tony Lindgren [mailto:t...@atomide.com]
Sent: 04 February, 2010 18:11
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP3: Serial: Improved sleep logic
* tero.kri...@nokia.com tero.kri...@nokia.com [100203 23:59]:
-Original Message-
From: ext Tony Lindgren [mailto:t...@atomide.com]
Sent: 03 February, 2010 19:50
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP3: Serial: Improved sleep logic
* Tero Kristo tero.kri...@nokia.com [100202 01:38]:
From: Tero Kristo tero.kri...@nokia.com
Only RX interrupt will now kick the sleep prevent timer. In
addition, TX
fifo status is checked before disabling clocks, this will
prevent occasional
garbage being printed on serial line. Smartidle is also
disabled while
entering idle if we have data in the transmit buffer,
because having this
enabled will prevent wakeups from the TX interrupt, and
this causes
pauses while sending large blocks of data.
Sounds this is for 2.6.34 merge window and does not contain anything
that needs to be fixed for 2.6.33.
Yeah, this only fixes a couple of annoying issues, but
nothing fatal. Also improves power efficiency in some cases
which is a nice to have feature, and basically eases the
development of PM code as the UART does not block the system
from sleeping always.
Yeah cool. Separate issue, but I wonder if we should also clear
the the first rx character from the fifo to avoid corrupting
the console. Only when the uart clocks are off and and
we get a key press. Would be easy to do just do with one
serial_read_reg(uart-p, UART_RX)..
Yeah, I can try to add this change to the code and see what happens.
Tony
-Tero
Regards,
Tony
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/serial.c | 19 +++
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c
b/arch/arm/mach-omap2/serial.c
index 777e802..e11dfe9 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -317,7 +317,8 @@ static void omap_uart_allow_sleep(struct
omap_uart_state *uart)
if (!uart-clocked)
return;
- omap_uart_smart_idle_enable(uart, 1);
+ if (serial_read_reg(uart-p, UART_LSR) UART_LSR_TEMT)
+ omap_uart_smart_idle_enable(uart, 1);
uart-can_sleep = 1;
del_timer(uart-timer);
}
@@ -335,7 +336,11 @@ void omap_uart_prepare_idle(int num)
list_for_each_entry(uart, uart_list, node) {
if (num == uart-num uart-can_sleep) {
- omap_uart_disable_clocks(uart);
+ if (serial_read_reg(uart-p, UART_LSR)
+ UART_LSR_TEMT)
+ omap_uart_disable_clocks(uart);
+ else
+ omap_uart_smart_idle_enable(uart, 0);
return;
}
}
@@ -407,8 +412,14 @@ int omap_uart_can_sleep(void)
static irqreturn_t omap_uart_interrupt(int irq, void *dev_id)
{
struct omap_uart_state *uart = dev_id;
+ u8 lsr;
- omap_uart_block_sleep(uart);
+ lsr = serial_read_reg(uart-p, UART_LSR);
+ /* Check for receive interrupt */
+ if (lsr UART_LSR_DR)
+ omap_uart_block_sleep(uart);
+ if (lsr UART_LSR_TEMT uart-can_sleep)
+ omap_uart_smart_idle_enable(uart, 1);
return IRQ_NONE;
}
--
1.5.4.3
--
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
--
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: omap3evm: Doesn't boot at 4fa42e46
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Tuesday, February 09, 2010 9:02 PM To: linux-omap@vger.kernel.org Subject: omap3evm: Doesn't boot at 4fa42e46 Hi all, Just updated my repo to the commit: commit 4fa42e4679324b0e3c54fb509535eea3923ccb63 Merge: e599f12 c446167 Author: Tony Lindgren t...@atomide.com Date: Thu Feb 4 20:07:44 2010 -0800 The kernel builds fine; but doesn't boot on the OMAP3EVM. I have been able to trace the code until rest_init(); but will need to restart debugging. There seems to be an exception during execution. Will continue to dig further. This is just an FYI. The kernel panics during I2C init in function omap3_evm_i2c_init() during this call: omap_register_i2c_bus(2, 400, NULL, 0); I see that there isn't any difference between omap3_evm_i2c_init() and omap3430_i2c_init(). Has anyone tried the booting 3430SDP at this commit? ...just trying to understand if this is a board specific issue OR is it a generic OMAP3 issue before I try bisect. ~sanjeev Best regards, Sanjeev -- 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 -- 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: linux-next: manual merge of the omap_dss2 tree with the omap tree
* Tomi Valkeinen tomi.valkei...@nokia.com [100208 01:23]: On Mon, 2010-02-08 at 07:25 +0100, ext Stephen Rothwell wrote: Hi Tomi, Today's linux-next merge of the omap_dss2 tree got a conflict in arch/arm/mach-omap2/board-am3517evm.c between commit 13560d875d67c06239c82a6148c1b87075701fe9 (AM3517: Enable basic I2C Support) from the omap tree and commit 56a3d0235cd50d14d7bd4d45e55d192aa0e78cac (OMAP: AM3517: Enable DSS2 for AM3517EVM board) from the omap_dss2 tree. Juts overlapping additions. I fixed it up (see below) and can carry the fix as necessary. Thanks. I guess we can't properly fix this until the patch from omap tree goes into mainline. Let's move the AM3517 DSS2 board patch from Tomi's tree to omap for-next tree. Tony, do you think this current way, in which we have board file changes in both linux-omap and the dss tree, is best we can do? Or should all the board file changes go through linux-omap? I fear that we will have conflicts with every new board. Yeah we should just move the conflicting files into omap for-next. The board file changes conflict easily when new platform device init code is being added. Tomi, how about you ack and let me know about the patches (or git branch) you want me to add into omap for-next? Otherwise I'll assume anything DSS2 related is yours. 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
DSPBRIDGE: Add BRD_SLEEP_TRANSITION in PROC_GetState
From 40d5863c3d3f4091761fef8bff581d2a7b1f32fa Mon Sep 17 00:00:00 2001 From: Ernesto Ramos erne...@ti.com Date: Tue, 2 Feb 2010 20:30:19 -0600 Subject: [PATCH] DSPBRIDGE: Add BRD_SLEEP_TRANSITION in PROC_GetState. When PROC_GetState checks for BRD status it is not taking into account the state BRD_SLEEP_TRANSITION and it is returning DSP_EFAIL when this happens, which is wrong. This fix adds this check to return ProcStatus as PROC_RUNNING and status DSP_SOK when this happens. Signed-off-by: Ernesto Ramos erne...@ti.com --- drivers/dsp/bridge/rmgr/proc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c index a1d06dc..553c9a7 100644 --- a/drivers/dsp/bridge/rmgr/proc.c +++ b/drivers/dsp/bridge/rmgr/proc.c @@ -802,6 +802,7 @@ DSP_STATUS PROC_GetState(DSP_HPROCESSOR hProcessor, case BRD_STOPPED: pProcStatus-iState = PROC_STOPPED; break; + case BRD_SLEEP_TRANSITION: case BRD_DSP_HIBERNATION: /* Fall through */ case BRD_RUNNING: -- 1.5.4.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] DSPBRIDGE: Validate Processor Handle from user
From 07b9f6d30c9d363ba0c4cefded8068662e1048c4 Mon Sep 17 00:00:00 2001
From: Ernesto Ramos erne...@ti.com
Date: Wed, 3 Feb 2010 19:43:31 -0600
Subject: [PATCH] DSPBRIDGE: Validate Processor Handle from user.
Add check to validate the Processor handle received
from user.
Signed-off-by: Ernesto Ramos erne...@ti.com
---
drivers/dsp/bridge/pmgr/wcd.c | 86 -
drivers/dsp/bridge/rmgr/proc.c | 280 ++--
2 files changed, 179 insertions(+), 187 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 78c7acd..020abbc 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -608,6 +608,7 @@ u32 PROCWRAP_Ctrl(union Trapped_Args *args, void *pr_ctxt)
args-ARGS_PROC_CTRL.pArgs;
u8 *pArgs = NULL;
DSP_STATUS status = DSP_SOK;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
GT_3trace(WCD_debugMask, GT_ENTER,
PROCWRAP_Ctrl: entered args:\n 0x%x
@@ -615,6 +616,10 @@ u32 PROCWRAP_Ctrl(union Trapped_Args *args, void *pr_ctxt)
args-ARGS_PROC_CTRL.hProcessor,
args-ARGS_PROC_CTRL.dwCmd,
args-ARGS_PROC_CTRL.pArgs);
+ if (args-ARGS_PROC_CTRL.hProcessor != pCtxt-hProcessor) {
+ status = DSP_EHANDLE;
+ goto func_end;
+ }
if (pSize) {
if (get_user(cbDataSize, pSize)) {
status = DSP_EFAIL;
@@ -669,6 +674,7 @@ u32 PROCWRAP_EnumNode_Info(union Trapped_Args *args, void
*pr_ctxt)
DSP_HNODE aNodeTab[MAX_NODES];
u32 uNumNodes;
u32 uAllocated;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
GT_5trace(WCD_debugMask, GT_ENTER,
PROCWRAP_EnumNode_Info:entered args:\n0x
@@ -680,6 +686,9 @@ u32 PROCWRAP_EnumNode_Info(union Trapped_Args *args, void
*pr_ctxt)
args-ARGS_PROC_ENUMNODE_INFO.puNumNodes,
args-ARGS_PROC_ENUMNODE_INFO.puAllocated);
+ if (args-ARGS_PROC_ENUMNODE_INFO.hProcessor != pCtxt-hProcessor)
+ return DSP_EHANDLE;
+
if (!args-ARGS_PROC_ENUMNODE_INFO.uNodeTabSize)
return DSP_ESIZE;
@@ -702,9 +711,13 @@ u32 PROCWRAP_EnumNode_Info(union Trapped_Args *args, void
*pr_ctxt)
u32 PROCWRAP_FlushMemory(union Trapped_Args *args, void *pr_ctxt)
{
DSP_STATUS status;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
GT_0trace(WCD_debugMask, GT_ENTER, PROCWRAP_FlushMemory: entered\n);
+ if (args-ARGS_PROC_FLUSHMEMORY.hProcessor != pCtxt-hProcessor)
+ return DSP_EHANDLE;
+
if (args-ARGS_PROC_FLUSHMEMORY.ulFlags PROC_WRBK_INV_ALL)
return DSP_EINVALIDARG;
@@ -722,10 +735,14 @@ u32 PROCWRAP_FlushMemory(union Trapped_Args *args, void
*pr_ctxt)
u32 PROCWRAP_InvalidateMemory(union Trapped_Args *args, void *pr_ctxt)
{
DSP_STATUS status;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
GT_0trace(WCD_debugMask, GT_ENTER,
PROCWRAP_InvalidateMemory:entered\n);
+ if (args-ARGS_PROC_INVALIDATEMEMORY.hProcessor != pCtxt-hProcessor)
+ return DSP_EHANDLE;
+
status = PROC_InvalidateMemory(
args-ARGS_PROC_INVALIDATEMEMORY.hProcessor,
args-ARGS_PROC_INVALIDATEMEMORY.pMpuAddr,
@@ -741,6 +758,7 @@ u32 PROCWRAP_EnumResources(union Trapped_Args *args, void
*pr_ctxt)
{
DSP_STATUS status = DSP_SOK;
struct DSP_RESOURCEINFO pResourceInfo;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
GT_4trace(WCD_debugMask, GT_ENTER,
PROCWRAP_EnumResources: entered args:\n
@@ -751,6 +769,9 @@ u32 PROCWRAP_EnumResources(union Trapped_Args *args, void
*pr_ctxt)
args-ARGS_PROC_ENUMRESOURCES.pResourceInfo,
args-ARGS_PROC_ENUMRESOURCES.uResourceInfoSize);
+ if (args-ARGS_PROC_ENUMRESOURCES.hProcessor != pCtxt-hProcessor)
+ return DSP_EHANDLE;
+
if (args-ARGS_PROC_ENUMRESOURCES.uResourceInfoSize
sizeof(struct DSP_RESOURCEINFO))
return DSP_ESIZE;
@@ -774,8 +795,13 @@ u32 PROCWRAP_GetState(union Trapped_Args *args, void
*pr_ctxt)
{
DSP_STATUS status;
struct DSP_PROCESSORSTATE procStatus;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
+
GT_0trace(WCD_debugMask, GT_ENTER, PROCWRAP_GetState: entered\n);
+ if (args-ARGS_PROC_GETSTATE.hProcessor != pCtxt-hProcessor)
+ return DSP_EHANDLE;
+
if (args-ARGS_PROC_GETSTATE.uStateInfoSize
sizeof(struct DSP_PROCESSORSTATE))
return DSP_ESIZE;
@@ -794,9 +820,13 @@ u32 PROCWRAP_GetTrace(union Trapped_Args *args, void
*pr_ctxt)
{
DSP_STATUS status;
u8 *pBuf;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
GT_0trace(WCD_debugMask, GT_ENTER, PROCWRAP_GetTrace:
[PATCH] DSPBRIDGE: Validate node handle from user
From 8310b586b025b0703c3951560849c4ea0250b6e1 Mon Sep 17 00:00:00 2001
From: Ernesto Ramos erne...@ti.com
Date: Fri, 29 Jan 2010 16:21:59 -0600
Subject: [PATCH] DSPBRIDGE: Validate node handle from user.
Add checks to validate the node handles received from user.
Signed-off-by: Ernesto Ramos erne...@ti.com
---
drivers/dsp/bridge/pmgr/wcd.c | 91 -
drivers/dsp/bridge/rmgr/node.c | 174 +--
2 files changed, 146 insertions(+), 119 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 74654dc..2e6eeb0 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1066,6 +1066,24 @@ u32 PROCWRAP_Stop(union Trapped_Args *args, void
*pr_ctxt)
return retVal;
}
+bool validate_node_handle(struct NODE_OBJECT *hNode, void *pr_ctxt)
+{
+ bool retVal = false;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
+ struct NODE_RES_OBJECT *pNode = pCtxt-pNodeList;
+
+ if (hNode == (struct NODE_OBJECT *) DSP_HGPPNODE)
+ retVal = true;
+
+ while (pNode !retVal) {
+ if (hNode == pNode-hNode)
+ retVal = true;
+ pNode = pNode-next;
+ }
+
+ return retVal;
+}
+
/*
* NODEWRAP_Allocate
*/
@@ -1140,6 +1158,10 @@ u32 NODEWRAP_AllocMsgBuf(union Trapped_Args *args, void
*pr_ctxt)
if (!args-ARGS_NODE_ALLOCMSGBUF.uSize)
return DSP_ESIZE;
+ if (!validate_node_handle(args-ARGS_NODE_ALLOCMSGBUF.hNode,
+ pr_ctxt))
+ return DSP_EHANDLE;
+
if (args-ARGS_NODE_ALLOCMSGBUF.pAttr) {/* Optional argument */
cp_fm_usr(attr, args-ARGS_NODE_ALLOCMSGBUF.pAttr, status, 1);
if (DSP_SUCCEEDED(status))
@@ -1148,6 +1170,7 @@ u32 NODEWRAP_AllocMsgBuf(union Trapped_Args *args, void
*pr_ctxt)
}
/* IN OUT argument */
cp_fm_usr(pBuffer, args-ARGS_NODE_ALLOCMSGBUF.pBuffer, status, 1);
+
if (DSP_SUCCEEDED(status)) {
status = NODE_AllocMsgBuf(args-ARGS_NODE_ALLOCMSGBUF.hNode,
args-ARGS_NODE_ALLOCMSGBUF.uSize,
@@ -1166,6 +1189,11 @@ u32 NODEWRAP_ChangePriority(union Trapped_Args *args,
void *pr_ctxt)
GT_0trace(WCD_debugMask, GT_ENTER,
NODEWRAP_ChangePriority: entered\n);
+
+ if (!validate_node_handle(args-ARGS_NODE_CHANGEPRIORITY.hNode,
+ pr_ctxt))
+ return DSP_EHANDLE;
+
retVal = NODE_ChangePriority(args-ARGS_NODE_CHANGEPRIORITY.hNode,
args-ARGS_NODE_CHANGEPRIORITY.iPriority);
@@ -1186,6 +1214,13 @@ u32 NODEWRAP_Connect(union Trapped_Args *args, void
*pr_ctxt)
GT_0trace(WCD_debugMask, GT_ENTER, NODEWRAP_Connect: entered\n);
+ if (!validate_node_handle(args-ARGS_NODE_CONNECT.hNode,
+ pr_ctxt) ||
+ !validate_node_handle(args-ARGS_NODE_CONNECT.hOtherNode,
+ pr_ctxt)) {
+ status = DSP_EHANDLE;
+ goto func_cont;
+ }
/* Optional argument */
if (pSize) {
if (get_user(cbDataSize, pSize))
@@ -1211,6 +1246,7 @@ u32 NODEWRAP_Connect(union Trapped_Args *args, void
*pr_ctxt)
pAttrs = attrs;
}
+
if (DSP_SUCCEEDED(status)) {
status = NODE_Connect(args-ARGS_NODE_CONNECT.hNode,
args-ARGS_NODE_CONNECT.uStream,
@@ -1233,6 +1269,11 @@ u32 NODEWRAP_Create(union Trapped_Args *args, void
*pr_ctxt)
u32 retVal;
GT_0trace(WCD_debugMask, GT_ENTER, NODEWRAP_Create: entered\n);
+
+ if (!validate_node_handle(args-ARGS_NODE_CREATE.hNode,
+ pr_ctxt))
+ return DSP_EHANDLE;
+
retVal = NODE_Create(args-ARGS_NODE_CREATE.hNode);
return retVal;
@@ -1246,6 +1287,11 @@ u32 NODEWRAP_Delete(union Trapped_Args *args, void
*pr_ctxt)
u32 retVal;
GT_0trace(WCD_debugMask, GT_ENTER, NODEWRAP_Delete: entered\n);
+
+ if (!validate_node_handle(args-ARGS_NODE_DELETE.hNode,
+ pr_ctxt))
+ return DSP_EHANDLE;
+
retVal = NODE_Delete(args-ARGS_NODE_DELETE.hNode, pr_ctxt);
return retVal;
@@ -1259,6 +1305,14 @@ u32 NODEWRAP_FreeMsgBuf(union Trapped_Args *args, void
*pr_ctxt)
DSP_STATUS status = DSP_SOK;
struct DSP_BUFFERATTR *pAttr = NULL;
struct DSP_BUFFERATTR attr;
+
+ if (!args-ARGS_NODE_FREEMSGBUF.pBuffer)
+ return DSP_EPOINTER;
+
+ if (!validate_node_handle(args-ARGS_NODE_FREEMSGBUF.hNode,
+ pr_ctxt))
+ return DSP_EHANDLE;
+
if (args-ARGS_NODE_FREEMSGBUF.pAttr) { /* Optional argument */
cp_fm_usr(attr, args-ARGS_NODE_FREEMSGBUF.pAttr, status, 1);
if (DSP_SUCCEEDED(status))
@@ -1266,9 +1320,6 @@ u32
[PATCH] DSPBRIDGE: Validate stream handle from user
From 991bd676e160a5500cb511a78afcac838ff003e4 Mon Sep 17 00:00:00 2001
From: Ernesto Ramos erne...@ti.com
Date: Fri, 29 Jan 2010 20:00:26 -0600
Subject: [PATCH] DSPBRIDGE: Validate stream handle from user.
Add checks to verify strm handle from user.
Signed-off-by: Ernesto Ramos erne...@ti.com
---
drivers/dsp/bridge/pmgr/wcd.c | 42 +
drivers/dsp/bridge/rmgr/strm.c | 134 ---
2 files changed, 97 insertions(+), 79 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 2e6eeb0..78c7acd 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1517,6 +1517,22 @@ func_cont:
return status;
}
+
+bool validate_strm_handle(struct STRM_OBJECT *hStrm, void *pr_ctxt)
+{
+ bool retVal = false;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
+ struct STRM_RES_OBJECT *pStrm = pCtxt-pSTRMList;
+
+ while (pStrm !retVal) {
+ if (hStrm == pStrm-hStream)
+ retVal = true;
+ pStrm = pStrm-next;
+ }
+
+ return retVal;
+}
+
/*
* STRMWRAP_AllocateBuffer
*/
@@ -1526,6 +1542,10 @@ u32 STRMWRAP_AllocateBuffer(union Trapped_Args *args,
void *pr_ctxt)
u8 **apBuffer = NULL;
u32 uNumBufs = args-ARGS_STRM_ALLOCATEBUFFER.uNumBufs;
+ if (!validate_strm_handle(args-ARGS_STRM_ALLOCATEBUFFER.hStream,
+ pr_ctxt))
+ return DSP_EHANDLE;
+
if (uNumBufs MAX_BUFS)
return DSP_EINVALIDARG;
@@ -1555,6 +1575,9 @@ u32 STRMWRAP_AllocateBuffer(union Trapped_Args *args,
void *pr_ctxt)
*/
u32 STRMWRAP_Close(union Trapped_Args *args, void *pr_ctxt)
{
+ if (!validate_strm_handle(args-ARGS_STRM_CLOSE.hStream, pr_ctxt))
+ return DSP_EHANDLE;
+
return STRM_Close(args-ARGS_STRM_CLOSE.hStream, pr_ctxt);
}
@@ -1567,6 +1590,9 @@ u32 STRMWRAP_FreeBuffer(union Trapped_Args *args, void
*pr_ctxt)
u8 **apBuffer = NULL;
u32 uNumBufs = args-ARGS_STRM_FREEBUFFER.uNumBufs;
+ if (!validate_strm_handle(args-ARGS_STRM_FREEBUFFER.hStream, pr_ctxt))
+ return DSP_EHANDLE;
+
if (uNumBufs MAX_BUFS)
return DSP_EINVALIDARG;
@@ -1605,6 +1631,9 @@ u32 STRMWRAP_GetInfo(union Trapped_Args *args, void
*pr_ctxt)
struct DSP_STREAMINFO user;
struct DSP_STREAMINFO *temp;
+ if (!validate_strm_handle(args-ARGS_STRM_GETINFO.hStream, pr_ctxt))
+ return DSP_EHANDLE;
+
cp_fm_usr(strmInfo, args-ARGS_STRM_GETINFO.pStreamInfo, status, 1);
temp = strmInfo.pUser;
@@ -1627,6 +1656,9 @@ u32 STRMWRAP_Idle(union Trapped_Args *args, void *pr_ctxt)
{
u32 retVal;
+ if (!validate_strm_handle(args-ARGS_STRM_IDLE.hStream, pr_ctxt))
+ return DSP_EHANDLE;
+
retVal = STRM_Idle(args-ARGS_STRM_IDLE.hStream,
args-ARGS_STRM_IDLE.bFlush);
@@ -1640,6 +1672,9 @@ u32 STRMWRAP_Issue(union Trapped_Args *args, void
*pr_ctxt)
{
DSP_STATUS status = DSP_SOK;
+ if (!validate_strm_handle(args-ARGS_STRM_ISSUE.hStream, pr_ctxt))
+ return DSP_EHANDLE;
+
if (!args-ARGS_STRM_ISSUE.pBuffer)
return DSP_EPOINTER;
@@ -1699,6 +1734,9 @@ u32 STRMWRAP_Reclaim(union Trapped_Args *args, void
*pr_ctxt)
u32 dwArg;
u32 ulBufSize;
+ if (!validate_strm_handle(args-ARGS_STRM_RECLAIM.hStream, pr_ctxt))
+ return DSP_EHANDLE;
+
status = STRM_Reclaim(args-ARGS_STRM_RECLAIM.hStream, pBufPtr,
ulBytes, ulBufSize, dwArg);
cp_to_usr(args-ARGS_STRM_RECLAIM.pBufPtr, pBufPtr, status, 1);
@@ -1724,6 +1762,10 @@ u32 STRMWRAP_RegisterNotify(union Trapped_Args *args,
void *pr_ctxt)
GT_0trace(WCD_debugMask, GT_ENTER,
NODEWRAP_RegisterNotify: entered\n);
+ if (!validate_strm_handle(args-ARGS_STRM_REGISTERNOTIFY.hStream,
+ pr_ctxt))
+ return DSP_EHANDLE;
+
/* Initialize the notification data structure */
notification.psName = NULL;
notification.handle = NULL;
diff --git a/drivers/dsp/bridge/rmgr/strm.c b/drivers/dsp/bridge/rmgr/strm.c
index 6be8083..2da6bf0 100644
--- a/drivers/dsp/bridge/rmgr/strm.c
+++ b/drivers/dsp/bridge/rmgr/strm.c
@@ -121,16 +121,11 @@ DSP_STATUS STRM_AllocateBuffer(struct STRM_OBJECT *hStrm,
u32 uSize,
GT_4trace(STRM_debugMask, GT_ENTER, STRM_AllocateBuffer: hStrm: 0x%x\t
uSize: 0x%x\tapBuffer: 0x%x\tuNumBufs: 0x%x\n,
hStrm, uSize, apBuffer, uNumBufs);
- if (MEM_IsValidHandle(hStrm, STRM_SIGNATURE)) {
- /*
-* Allocate from segment specified at time of stream open.
-*/
- if (uSize == 0)
- status = DSP_ESIZE;
-
- } else {
- status = DSP_EHANDLE;
-
Re: [PATCH] DSPBRIDGE: Validate Processor Handle from user
Hi Ernesto, On Tue, 2010-02-09 at 18:07 +0100, ext Ramos Falcon, Ernesto wrote: From 07b9f6d30c9d363ba0c4cefded8068662e1048c4 Mon Sep 17 00:00:00 2001 From: Ernesto Ramos erne...@ti.com Date: Wed, 3 Feb 2010 19:43:31 -0600 Subject: [PATCH] DSPBRIDGE: Validate Processor Handle from user. Add check to validate the Processor handle received from user. Signed-off-by: Ernesto Ramos erne...@ti.com --- drivers/dsp/bridge/pmgr/wcd.c | 86 - drivers/dsp/bridge/rmgr/proc.c | 280 ++-- 2 files changed, 179 insertions(+), 187 deletions(-) My understanding: In bridge_open() we allocate a new process_context and store it in filp-private_data which can't be modified / tampered by user space. If this understanding is correct, then why we need to perform any validation on data hold be process_context pointer stored in flip-private_data? If you don't trust hProcessor handle received from user space arguments then instead of using that we can just use pCtxt-hProcessor! I don't understand why we need validation so NACK from my side. Cheers, Ameya. -- 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] DSPBRIDGE: Validate node handle from user
Hi Ernesto,
On Tue, 2010-02-09 at 18:08 +0100, ext Ramos Falcon, Ernesto wrote:
From 8310b586b025b0703c3951560849c4ea0250b6e1 Mon Sep 17 00:00:00 2001
From: Ernesto Ramos erne...@ti.com
Date: Fri, 29 Jan 2010 16:21:59 -0600
Subject: [PATCH] DSPBRIDGE: Validate node handle from user.
Add checks to validate the node handles received from user.
Signed-off-by: Ernesto Ramos erne...@ti.com
---
drivers/dsp/bridge/pmgr/wcd.c | 91 -
drivers/dsp/bridge/rmgr/node.c | 174 +--
2 files changed, 146 insertions(+), 119 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 74654dc..2e6eeb0 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1066,6 +1066,24 @@ u32 PROCWRAP_Stop(union Trapped_Args *args, void
*pr_ctxt)
return retVal;
}
+bool validate_node_handle(struct NODE_OBJECT *hNode, void *pr_ctxt)
+{
+ bool retVal = false;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
+ struct NODE_RES_OBJECT *pNode = pCtxt-pNodeList;
+
+ if (hNode == (struct NODE_OBJECT *) DSP_HGPPNODE)
+ retVal = true;
+
+ while (pNode !retVal) {
+ if (hNode == pNode-hNode)
If you have several nodes allocated by user space, then what you are
validating here is for any node! Is that ok?
This validation and design itself doesn't look good to me. If we don't
want to trust user space, then instead of checking the node handle in
every function it is better to store all user space specific date inside
pr_context and use it from there.
Cheers,
Ameya.
--
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] DSPBRIDGE: Validate stream handle from user
Hi Ernesto,
On Tue, 2010-02-09 at 18:09 +0100, ext Ramos Falcon, Ernesto wrote:
From 991bd676e160a5500cb511a78afcac838ff003e4 Mon Sep 17 00:00:00 2001
From: Ernesto Ramos erne...@ti.com
Date: Fri, 29 Jan 2010 20:00:26 -0600
Subject: [PATCH] DSPBRIDGE: Validate stream handle from user.
Add checks to verify strm handle from user.
Signed-off-by: Ernesto Ramos erne...@ti.com
---
drivers/dsp/bridge/pmgr/wcd.c | 42 +
drivers/dsp/bridge/rmgr/strm.c | 134 ---
2 files changed, 97 insertions(+), 79 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 2e6eeb0..78c7acd 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1517,6 +1517,22 @@ func_cont:
return status;
}
+
+bool validate_strm_handle(struct STRM_OBJECT *hStrm, void *pr_ctxt)
+{
+ bool retVal = false;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
+ struct STRM_RES_OBJECT *pStrm = pCtxt-pSTRMList;
+
+ while (pStrm !retVal) {
+ if (hStrm == pStrm-hStream)
If you have several streams allocated by user space, then what you are
validating here is for any node! Is that ok?
This validation and design itself doesn't look good to me. If we don't
want to trust user space, then instead of checking the stream handle in
every function it is better to store all user space specific date inside
pr_context and use it from there.
Cheers,
Ameya.
--
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] DSPBRIDGE: Validate Processor Handle from user
-Original Message- From: Ameya Palande [mailto:ameya.pala...@nokia.com] Sent: Tuesday, February 09, 2010 11:27 AM To: Ramos Falcon, Ernesto Cc: linux-omap@vger.kernel.org; Contreras Felipe (Nokia-D/Helsinki); Doyu Hiroshi (Nokia-D/Helsinki) Subject: Re: [PATCH] DSPBRIDGE: Validate Processor Handle from user Hi Ernesto, On Tue, 2010-02-09 at 18:07 +0100, ext Ramos Falcon, Ernesto wrote: From 07b9f6d30c9d363ba0c4cefded8068662e1048c4 Mon Sep 17 00:00:00 2001 From: Ernesto Ramos erne...@ti.com Date: Wed, 3 Feb 2010 19:43:31 -0600 Subject: [PATCH] DSPBRIDGE: Validate Processor Handle from user. Add check to validate the Processor handle received from user. Signed-off-by: Ernesto Ramos erne...@ti.com --- drivers/dsp/bridge/pmgr/wcd.c | 86 - drivers/dsp/bridge/rmgr/proc.c | 280 ++ -- 2 files changed, 179 insertions(+), 187 deletions(-) My understanding: In bridge_open() we allocate a new process_context and store it in filp-private_data which can't be modified / tampered by user space. If this understanding is correct, then why we need to perform any validation on data hold be process_context pointer stored in flip-private_data? If you don't trust hProcessor handle received from user space arguments then instead of using that we can just use pCtxt-hProcessor! Agree. We plan to remove the Proc Attach and remove the parameter hProcessor handle passed to the user but we have not done it yet because it may impact the API. I don't understand why we need validation so NACK from my side. We have had some cases where we receive an invalid proc handle from user which resulted in kernel panic. Cheers, Ameya. -- 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] DSPBRIDGE: Validate node handle from user
-Original Message-
From: Ameya Palande [mailto:ameya.pala...@nokia.com]
Sent: Tuesday, February 09, 2010 11:32 AM
To: Ramos Falcon, Ernesto
Cc: linux-omap@vger.kernel.org; Contreras Felipe (Nokia-D/Helsinki); Doyu
Hiroshi (Nokia-D/Helsinki)
Subject: Re: [PATCH] DSPBRIDGE: Validate node handle from user
Hi Ernesto,
On Tue, 2010-02-09 at 18:08 +0100, ext Ramos Falcon, Ernesto wrote:
From 8310b586b025b0703c3951560849c4ea0250b6e1 Mon Sep 17 00:00:00 2001
From: Ernesto Ramos erne...@ti.com
Date: Fri, 29 Jan 2010 16:21:59 -0600
Subject: [PATCH] DSPBRIDGE: Validate node handle from user.
Add checks to validate the node handles received from user.
Signed-off-by: Ernesto Ramos erne...@ti.com
---
drivers/dsp/bridge/pmgr/wcd.c | 91 -
drivers/dsp/bridge/rmgr/node.c | 174 +-
-
2 files changed, 146 insertions(+), 119 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/wcd.c
b/drivers/dsp/bridge/pmgr/wcd.c
index 74654dc..2e6eeb0 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1066,6 +1066,24 @@ u32 PROCWRAP_Stop(union Trapped_Args *args, void
*pr_ctxt)
return retVal;
}
+bool validate_node_handle(struct NODE_OBJECT *hNode, void *pr_ctxt)
+{
+ bool retVal = false;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
+ struct NODE_RES_OBJECT *pNode = pCtxt-pNodeList;
+
+ if (hNode == (struct NODE_OBJECT *) DSP_HGPPNODE)
+ retVal = true;
+
+ while (pNode !retVal) {
+ if (hNode == pNode-hNode)
If you have several nodes allocated by user space, then what you are
validating here is for any node! Is that ok?
This validation and design itself doesn't look good to me. If we don't
want to trust user space, then instead of checking the node handle in
every function it is better to store all user space specific date inside
pr_context and use it from there.
The user can launch several nodes, how are we going to know which node handle
to use?
I think we may need to receive at least one index or id to the node handle.
Cheers,
Ameya.
--
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] DSPBRIDGE: Add BRD_SLEEP_TRANSITION in PROC_GetState
From 40d5863c3d3f4091761fef8bff581d2a7b1f32fa Mon Sep 17 00:00:00 2001 From: Ernesto Ramos erne...@ti.com Date: Tue, 2 Feb 2010 20:30:19 -0600 Subject: [PATCH] DSPBRIDGE: Add BRD_SLEEP_TRANSITION in PROC_GetState. When PROC_GetState checks for BRD status it is not taking into account the state BRD_SLEEP_TRANSITION and it is returning DSP_EFAIL when this happens, which is wrong. This fix adds this check to return ProcStatus as PROC_RUNNING and status DSP_SOK when this happens. Signed-off-by: Ernesto Ramos erne...@ti.com --- drivers/dsp/bridge/rmgr/proc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c index a1d06dc..553c9a7 100644 --- a/drivers/dsp/bridge/rmgr/proc.c +++ b/drivers/dsp/bridge/rmgr/proc.c @@ -802,6 +802,7 @@ DSP_STATUS PROC_GetState(DSP_HPROCESSOR hProcessor, case BRD_STOPPED: pProcStatus-iState = PROC_STOPPED; break; + case BRD_SLEEP_TRANSITION: case BRD_DSP_HIBERNATION: /* Fall through */ case BRD_RUNNING: -- 1.5.4.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] DSPBRIDGE: Prevent memory corruption in DRV_ProcFreeDMMRes
Hi, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Felipe Contreras Sent: Tuesday, February 09, 2010 6:30 AM To: Ameya Palande Cc: linux-omap@vger.kernel.org; Ramirez Luna, Omar; Menon, Nishanth; Chitriki Rudramuni, Deepak; felipe.contre...@nokia.com; ext- phil.2.carm...@nokia.com Subject: Re: [PATCH] DSPBRIDGE: Prevent memory corruption in DRV_ProcFreeDMMRes On Mon, Feb 8, 2010 at 10:25 PM, Ameya Palande ameya.pala...@nokia.com wrote: Background: bridge_close() has the responsibility to cleanup all the resources allocated by user space process. One of those resources is DMMRes which is used for tracking DMM resource allocation done in PROC_Map() and PROC_UnMap(). DRV_ProcFreeDMMRes() function was used for cleaning up DMMRes has following problems which are fixed by this patch: 1. It access and modifies pDMMRes pointer when it is already freed by PROC_UnMap() 2. Instead of passing ulDSPAddr it passes ulDSPResAddr to PROC_UnMap() which will not retrive correct DMMRes element. This patch is doing the right thing to me, however, it's a bit difficult to review because it's doing many changes at once. Personally I would 1) Fix the wrong dereferences in DRV_ProcFreeDMMRes [at this point the bug should be fixed] [the leaks would be freed by the outer loop] 2) Fix the wrong PROC_UnMap address passed in DRV_ProcFreeDMMRes 3) Remove the unnecessary outer loop in DRV_RemoveAllDMMResElements [at this point the code would actually make sense] 4) Merge DRV_ProcFreeDMMRes into DRV_RemoveAllDMMResElements 5) Improve coding style The end result would be the same, but easier to see what's going on :) Cheers. -- Felipe Contreras The root problem here is that remove the DMM element should be in PROC_UnMap but in PROC_UnReserveMemory, because apart of the problem your are seeing about memory corruption if the application does a PROC_ReserveMemory and then it finished unexpectedly the resource cleanup wont be able to unreserved the memory because there is no a DMMres element in process context struct, the same applies in the case of application calls PROC_ReserveMemory, PROC_Map, PROC_UnMap but fails to do the PROC_UnReserveMemory. So the right solution should be: 1 .- Remove DRV_InsertDMMResElement function from PROC_Map and put it on PROC_ReserveMemory. 2.- Keep DRV_UpdateDMMResElement function in PROC_Map. 3.- Remove DRV_RemoveDMMResElement function from PROC_UnMap and put it on ROC_UnReserveMemory function. 4.- Clear dmmAllocated flag in PROC_UnMap: pDMMRes-dmmAllocated = 0; 5 .- in the function DRV_ProcFreeDMMRes, call PROC_UnMap if (pDMMRes-dmmAllocated) and always call PROC_UnReserveMemory not in this point is not needed the save hProcessor nor ulDSPResAddr addresses. 6 .- cleanup DRV_RemoveAllDMMResElements function (while loop is not needed). Regards, Fernando. -- 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 -- 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 1/3]: Update Platform files for SPI
* Hemanth V heman...@ti.com [100203 02:19]:
From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001
From: Hemanth V heman...@ti.com
Date: Fri, 27 Nov 2009 14:22:30 +0530
Subject: [PATCH] Update platform files
This patch updates platform files for
fifo, slave support
Signed-off-by: Hemanth V heman...@ti.com
This should get merged via the spi-devel list with the other patches.
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/devices.c |5 +
arch/arm/plat-omap/include/plat/mcspi.h | 29 -
2
files changed, 33 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 733d3dc..79b5396 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -282,6 +282,7 @@ static inline void omap_init_sti(void) {}
static struct omap2_mcspi_platform_config omap2_mcspi1_config = {
.num_cs = 4,
+ .force_cs_mode = 1,
};
static struct resource omap2_mcspi1_resources[] = {
@@ -304,6 +305,10 @@ static struct platform_device omap2_mcspi1 = {
static struct omap2_mcspi_platform_config omap2_mcspi2_config = {
.num_cs = 2,
+ .mode = OMAP2_MCSPI_MASTER,
+ .dma_mode = 0,
+ .force_cs_mode = 0,
+ .fifo_depth = 0,
};
static struct resource omap2_mcspi2_resources[] = {
diff --git a/arch/arm/plat-omap/include/plat/mcspi.h
b/arch/arm/plat-omap/include/plat/mcspi.h
index 1254e49..ffda0a1 100644
--- a/arch/arm/plat-omap/include/plat/mcspi.h
+++ b/arch/arm/plat-omap/include/plat/mcspi.h
@@ -1,8 +1,35 @@
#ifndef _OMAP2_MCSPI_H
#define _OMAP2_MCSPI_H
+#define OMAP2_MCSPI_MASTER 0
+#define OMAP2_MCSPI_SLAVE1
+
+/**
+ * struct omap2_mcspi_platform_config - McSPI controller configuration + *
@num_cs: Number of chip selects or channels supported
+ * @mode: SPI is master or slave
+ * @dma_mode: Use only DMA for data transfers
+ * @force_cs_mode: Use force chip select mode or auto chip select mode + *
@fifo_depth: FIFO depth in bytes, max value 64
+ *
+ * @dma_mode when set to 1 uses only dma for data transfers
+ * else the default behaviour is to use PIO mode for transfer
+ * size of 8 bytes or less. This mode is useful when mcspi
+ * is configured as slave
+ *
+ * @force_cs_mode when set to 1 allows continuous transfer of multiple + *
spi
words without toggling the chip select line.
+ *
+ * @fifo_depth when set to non zero values enables FIFO. fifo_depth + *
should
be set as a multiple of buffer size used for read/write. + */
+
struct omap2_mcspi_platform_config {
- unsigned short num_cs;
+ u8 num_cs;
+ u8 mode;
+ u8 dma_mode;
+ u8 force_cs_mode;
+ unsigned short fifo_depth;
};
struct omap2_mcspi_device_config {
--
1.5.6.3
--
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
--
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 2/2] OMAP3: PM: remove TWL4030 A2S script before reboot
Hi,
* Mike Turquette mturque...@gmail.com [100203 11:42]:
Removes TWL4030 sleep script prior to rebooting, only on OMAP3. This is
necessary since DPLL3 reset causes SYS_OFFMODE pin to go low, resulting
in the sleep script being executed on TWL4030. This usually results in
VDD1 VDD2 voltage collapse while ROM code is executing, followed by an
MPU Watch Dog reset or worse, an irrecoverable hang.
The first patch is OK is for Samuel, but this needs to be updated
against Paul's clock changes. One comment below too.
Signed-off-by: Mike Turquette mturque...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 0d30e53..0d6d1d6 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -28,6 +28,7 @@
#include linux/bitops.h
#include linux/err.h
#include linux/cpufreq.h
+#include linux/i2c/twl.h
#include plat/cpu.h
#include plat/clock.h
@@ -311,6 +312,8 @@ struct clk_functions omap2_clk_functions = {
*/
void omap2_clk_prepare_for_reboot(void)
{
+ int err = 0;
+
/* REVISIT: Not ready for 343x */
#if 0
u32 rate;
@@ -321,6 +324,18 @@ void omap2_clk_prepare_for_reboot(void)
rate = clk_get_rate(sclk);
clk_set_rate(vclk, rate);
#endif
+
+ /*
+ * PRCM on OMAP3 will drive SYS_OFFMODE low during DPLL3 warm reset.
+ * This causes Gaia sleep script to execute, usually killing VDD1 and
+ * VDD2 while code is running. WA is to disable the sleep script
+ * before warm reset.
+ */
+#ifdef CONFIG_TWL4030_POWER
+ err = twl4030_remove_script(TWL4030_SLEEP_SCRIPT);
+ if (err)
+ pr_err(twl4030: error trying to disable sleep script!\n);
+#endif
This needs to work in cases where we have multiple companion chips
compiled in. You may have twl4030 support compiled in, but no twl4030
hardware on the board. It needs to be based on I2C detected chips during
init somehow.
In the omap for-next branch we already support booting 2420, 34xx, 36xx
and 4430 with the same kernel binary. So please update accordingly.
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[V2 1/3]: Update Platform files for SPI
On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren t...@atomide.com wrote: * Hemanth V heman...@ti.com [100203 02:19]: From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001 From: Hemanth V heman...@ti.com Date: Fri, 27 Nov 2009 14:22:30 +0530 Subject: [PATCH] Update platform files This patch updates platform files for fifo, slave support Signed-off-by: Hemanth V heman...@ti.com This should get merged via the spi-devel list with the other patches. Acked-by: Tony Lindgren t...@atomide.com Personally, I prefer not to carry arch/* changes in my next-spi branch, since it means that my pull requests are less obvious for Linus and there is greater chance of conflict. But if you still really want me to merge it through my tree, (or if getting the patches out of order will break things) then I'll pick it up. Just let me know. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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 1/3]: Update Platform files for SPI
* Grant Likely grant.lik...@secretlab.ca [100209 14:38]: On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren t...@atomide.com wrote: * Hemanth V heman...@ti.com [100203 02:19]: From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001 From: Hemanth V heman...@ti.com Date: Fri, 27 Nov 2009 14:22:30 +0530 Subject: [PATCH] Update platform files This patch updates platform files for fifo, slave support Signed-off-by: Hemanth V heman...@ti.com This should get merged via the spi-devel list with the other patches. Acked-by: Tony Lindgren t...@atomide.com Personally, I prefer not to carry arch/* changes in my next-spi branch, since it means that my pull requests are less obvious for Linus and there is greater chance of conflict. But if you still really want me to merge it through my tree, (or if getting the patches out of order will break things) then I'll pick it up. Just let me know. OK, if you ack it, I'll add the header into omap for-next. That might break git bisect for some configurations depending in which order the patches get pulled by Linus.. I guess eventually this header should not live under plat. 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] OMAP: hsmmc: fix memory leak
* Aaro Koskinen aaro.koski...@nokia.com [100208 04:29]:
The platform data allocated with kmalloc() will become unreachable once
the init is complete, so it should be freed. The problem was discovered
by kmemleak.
Looks like this is safe to do as platform_device_add_data does kmemdup
on the data.
BTW, if you want to create a version for 2.6.33, we should still have
enough time to queue it as a fix. It's a very limited size leak though,
but still a leak.
Regards,
Tony
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap2/hsmmc.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 1156b28..9ad2295 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -145,6 +145,7 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
{
struct omap2_hsmmc_info *c;
int nr_hsmmc = ARRAY_SIZE(hsmmc_data);
+ int i;
if (cpu_is_omap2430()) {
control_pbias_offset = OMAP243X_CONTROL_PBIAS_LITE;
@@ -171,7 +172,7 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
GFP_KERNEL);
if (!mmc) {
pr_err(Cannot allocate memory for mmc device!\n);
- return;
+ goto done;
}
if (c-name)
@@ -256,6 +257,10 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
continue;
c-dev = mmc-dev;
}
+
+done:
+ for (i = 0; i nr_hsmmc; i++)
+ kfree(hsmmc_data[i]);
}
#endif
--
1.5.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] DSPBRIDGE: Prevent memory corruption in DRV_ProcFreeDMMRes
On Tue, Feb 9, 2010 at 10:22 PM, Guzman Lugo, Fernando x0095...@ti.com wrote: The root problem here is that remove the DMM element should be in PROC_UnMap but in PROC_UnReserveMemory, because apart of the problem your are seeing about memory corruption if the application does a PROC_ReserveMemory and then it finished unexpectedly the resource cleanup wont be able to unreserved the memory because there is no a DMMres element in process context struct, the same applies in the case of application calls PROC_ReserveMemory, PROC_Map, PROC_UnMap but fails to do the PROC_UnReserveMemory. No, that's a completely different issue, but also valid. So the right solution should be: 1 .- Remove DRV_InsertDMMResElement function from PROC_Map and put it on PROC_ReserveMemory. 2.- Keep DRV_UpdateDMMResElement function in PROC_Map. 3.- Remove DRV_RemoveDMMResElement function from PROC_UnMap and put it on ROC_UnReserveMemory function. 4.- Clear dmmAllocated flag in PROC_UnMap: pDMMRes-dmmAllocated = 0; At this point there's an obvious question; what's the point of reserving a memory region and not mapping it? I remember the answer from Hari was: some clients prefer to reserve a big region once, and map parts of it continuously. I have my doubts that the use-case even works with the current code-base. But assuming it does work, your proposed changes would break it. It would be much easier to merge the two functions into one. Anyway, please re-read Ameya's description carefully. -- Felipe Contreras -- 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 1/3]: Update Platform files for SPI
On Tue, Feb 9, 2010 at 4:07 PM, Tony Lindgren t...@atomide.com wrote: * Grant Likely grant.lik...@secretlab.ca [100209 14:38]: On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren t...@atomide.com wrote: * Hemanth V heman...@ti.com [100203 02:19]: From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001 From: Hemanth V heman...@ti.com Date: Fri, 27 Nov 2009 14:22:30 +0530 Subject: [PATCH] Update platform files This patch updates platform files for fifo, slave support Signed-off-by: Hemanth V heman...@ti.com This should get merged via the spi-devel list with the other patches. Acked-by: Tony Lindgren t...@atomide.com Personally, I prefer not to carry arch/* changes in my next-spi branch, since it means that my pull requests are less obvious for Linus and there is greater chance of conflict. But if you still really want me to merge it through my tree, (or if getting the patches out of order will break things) then I'll pick it up. Just let me know. OK, if you ack it, I'll add the header into omap for-next. That might break git bisect for some configurations depending in which order the patches get pulled by Linus.. git bisect breakage is breakage enough. :-) You're right. I should pick this one up. I can see that now that I've had my tea and I'm no longer grumpy. I guess eventually this header should not live under plat. Any reason the header cannot be moved to include/linux/spi/ now? g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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] DSPBRIDGE: Fix to avoid possible recursive locking
This patch fixes possible recursive locking detection.The implementation
in which the spinlock is acquired and released is rectified in WMD_MSG_Get()
to avoid locking contention.
Added SYNC_EnterCS() and SYNC_LeaveCS()in WMD_MSG_Get()function.
Cc: Ameya Palande ameya.pala...@nokia.com
Cc: Omar Ramirez Luna omar.rami...@ti.com
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Deepak Chitriki deepak.chitr...@ti.com
---
drivers/dsp/bridge/wmd/msg_sm.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/msg_sm.c b/drivers/dsp/bridge/wmd/msg_sm.c
index 50201e5..8faf5ad 100644
--- a/drivers/dsp/bridge/wmd/msg_sm.c
+++ b/drivers/dsp/bridge/wmd/msg_sm.c
@@ -300,8 +300,10 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
if (LST_IsEmpty(hMsgQueue-msgUsedList))
SYNC_ResetEvent(hMsgQueue-hSyncEvent);
else {
+ (void)SYNC_LeaveCS(hMsgMgr-hSyncCS);
NTFY_Notify(hMsgQueue-hNtfy,
DSP_NODEMESSAGEREADY);
+ (void)SYNC_EnterCS(hMsgMgr-hSyncCS);
SYNC_SetEvent(hMsgQueue-hSyncEvent);
}
@@ -352,8 +354,10 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
hMsgQueue-refCount--;
/* Reset the event if there are still queued messages */
if (!LST_IsEmpty(hMsgQueue-msgUsedList)) {
+ (void)SYNC_LeaveCS(hMsgMgr-hSyncCS);
NTFY_Notify(hMsgQueue-hNtfy,
DSP_NODEMESSAGEREADY);
+ (void)SYNC_EnterCS(hMsgMgr-hSyncCS);
SYNC_SetEvent(hMsgQueue-hSyncEvent);
}
/* Exit critical section */
--
1.6.3.3
--
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] dspbridge: Simplify Atoi() method
Hi,
On 2/3/2010 4:14 AM, Andy Shevchenko wrote:
From: Andy Shevchenkoext-andriy.shevche...@nokia.com
Try to use simple_strtol() kernel native method instead.
strtol or strtoul?
However, there are opened questions:
- why type of Atoi() is s32 if the sign is used only to detect base?
- should we really to check hex integers like DEAD0123h?
- how many spaces could lead token?
Signed-off-by: Andy Shevchenkoext-andriy.shevche...@nokia.com
---
drivers/dsp/bridge/rmgr/dbdcd.c | 42 +-
1 files changed, 6 insertions(+), 36 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/dbdcd.c b/drivers/dsp/bridge/rmgr/dbdcd.c
index caa57f1..fe2ed57 100644
--- a/drivers/dsp/bridge/rmgr/dbdcd.c
+++ b/drivers/dsp/bridge/rmgr/dbdcd.c
@@ -1002,50 +1002,20 @@ DSP_STATUS DCD_UnregisterObject(IN struct DSP_UUID
*pUuid,
*/
static s32 Atoi(char *pszBuf)
{
- s32 result = 0;
char *pch = pszBuf;
- char c;
- char first;
- s32 base = 10;
- s32 len;
+ s32 base = 0;
while (isspace(*pch))
pch++;
- first = *pch;
- if (first == '-' || first == '+') {
+ if (*pch == '-' || *pch == '+') {
+ base = 10;
pch++;
- } else {
- /* Determine if base 10 or base 16 */
- len = strlen(pch);
- if (len 1) {
- c = pch[1];
- if ((*pch == '0' (c == 'x' || c == 'X'))) {
- base = 16;
- pch += 2;
- }
- c = pch[len - 1];
- if (c == 'h' || c == 'H')
- base = 16;
-
- }
- }
-
- while (isdigit(c = *pch) || ((base == 16) isxdigit(c))) {
- result *= base;
- if ('A'= c c= 'F') {
- c = c - 'A' + 10;
- } else {
- if ('a'= c c= 'f')
- c = c - 'a' + 10;
- else
- c -= '0';
- }
- result += c;
- ++pch;
+ } else if (*pch (pch[strlen(pch) - 1] | 0x20 == 'h')) {
perhaps tolower(x)
otherwise: (pch[strlen(pch) - 1] | 0x20 == 'h')
should be ((pch[strlen(pch) - 1] | 0x20) == 'h')
+ base = 16;
}
- return result;
+ return simple_strtoul(pch, NULL, base);
}
/*
- omar
--
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] DSPBRIDGE: Prevent memory corruption in DRV_ProcFreeDMMRes
Hi, -Original Message- From: Felipe Contreras [mailto:felipe.contre...@gmail.com] Sent: Tuesday, February 09, 2010 5:48 PM To: Guzman Lugo, Fernando Cc: Ameya Palande; linux-omap@vger.kernel.org; Ramirez Luna, Omar; Menon, Nishanth; Chitriki Rudramuni, Deepak; felipe.contre...@nokia.com; ext- phil.2.carm...@nokia.com Subject: Re: [PATCH] DSPBRIDGE: Prevent memory corruption in DRV_ProcFreeDMMRes On Tue, Feb 9, 2010 at 10:22 PM, Guzman Lugo, Fernando x0095...@ti.com wrote: The root problem here is that remove the DMM element should be in PROC_UnMap but in PROC_UnReserveMemory, because apart of the problem your are seeing about memory corruption if the application does a PROC_ReserveMemory and then it finished unexpectedly the resource cleanup wont be able to unreserved the memory because there is no a DMMres element in process context struct, the same applies in the case of application calls PROC_ReserveMemory, PROC_Map, PROC_UnMap but fails to do the PROC_UnReserveMemory. No, that's a completely different issue, but also valid. So the right solution should be: 1 .- Remove DRV_InsertDMMResElement function from PROC_Map and put it on PROC_ReserveMemory. 2.- Keep DRV_UpdateDMMResElement function in PROC_Map. 3.- Remove DRV_RemoveDMMResElement function from PROC_UnMap and put it on ROC_UnReserveMemory function. 4.- Clear dmmAllocated flag in PROC_UnMap: pDMMRes-dmmAllocated = 0; At this point there's an obvious question; what's the point of reserving a memory region and not mapping it? I remember the answer from Hari was: some clients prefer to reserve a big region once, and map parts of it continuously. I have my doubts that the use-case even works with the current code-base. But assuming it does work, your proposed changes would break it. Resource cleanup does not support that even without my proposed changes. I just proposed a solution which fixes two issues in one patch. Moreover if this change is merged when the second issue be fixed this patch will not needed anymore, so why don't merge the patch which fixes both errors at this moment? Anyway, if you want to include this patch, the only comments we have is: + * PROC_UnMap will free memory allocated to p_cur_res + * pointer. So we need to save following data for the + * execution of PROC_UnReserveMemory() + */ + void *h_processor = p_cur_res-hProcessor; You could use hProcessor store in p_ctxt instead of p_cur_res, so that you don't need to save hProcessor. + u32 dsp_res_addr = p_cur_res-ulDSPResAddr; + + status = PROC_UnMap(p_cur_res-hProcessor, + (void *)p_cur_res-ulDSPAddr, p_ctxt); It would be much easier to merge the two functions into one. Yes, I am agreed. Anyway, please re-read Ameya's description carefully. -- Felipe Contreras -- 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: Ubuntu installation on omap
On Tue, Feb 9, 2010 at 8:37 PM, Robert Nelson robertcnel...@gmail.com wrote: On Tue, Feb 9, 2010 at 3:41 AM, Niamathullah sharief omap...@gmail.com wrote: Hi, I am trying to install ubuntu on my beagleboard. i installed successfully and it is booting fine. But after booting the graphics which i get is not good. It has some graphics problem. Ahh, what kind of graphic problems? it is like working without graphics driver And how can work on ubuntu in board with my mouse and keyboard? If i insert mouse and keyboard to board it is not working. only my serial port is working. just i am getting login screen in my monitor.Please help me. Are you using a certified USB 2.0 Hub? Kernel version? Yes i am using perfect. If i give lsmod in serial, i am not not getting anything. no modules running As a quick verification test, use one of my demo images listed here: http://elinux.org/BeagleBoardUbuntu#Demo_Image Which have been tested on multiple Beagles (Bx's,Cx's..) Regards, -- Robert Nelson http://www.rcn-ee.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: Ubuntu installation on omap
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Niamathullah sharief Sent: Wednesday, February 10, 2010 7:30 AM On Tue, Feb 9, 2010 at 8:37 PM, Robert Nelson robertcnel...@gmail.com wrote: On Tue, Feb 9, 2010 at 3:41 AM, Niamathullah sharief omap...@gmail.com wrote: Hi, I am trying to install ubuntu on my beagleboard. i installed successfully and it is booting fine. But after booting the graphics which i get is not good. It has some graphics problem. Ahh, what kind of graphic problems? it is like working without graphics driver Is'nt http://groups.google.com/group/beagleboard/ having more folks Who can specifically help on beagleboard? Could we take the discussion there? 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: [PATCHV3] OMAP3630: Clock: Workaround for DPLL HS divider limitation
Hello Mike, Vijayakumar,
one comment below.
On Tue, 9 Feb 2010, G.N, Vijayakumar wrote:
From: Mike Turquette mturque...@ti.com
Date: Fri, 5 Feb 2010 19:09:52 +0530
Subject: [PATCH] OMAP3630: Clock: Workaround for DPLL HS divider limitation
This patch implements a workaround for the DPLL HS divider limitation
in OMAP3630 as given by Errata ID: i556.
Errata:
When PWRDN bit is set, it resets the internal HSDIVIDER divide-by value (Mx).
The reset value gets loaded instead of the previous value.
The following HSDIVIDERs exhibit above behavior:
. DPLL4 : M6 / M5 / M4 / M3 / M2 (CM_CLKEN_PLL[31:26] register bits)
. DPLL3 : M3 (CM_CLKEN_PLL[12] register bit).
Work Around:
It is mandatory to apply the following sequence to ensure the write
value will
be loaded in DPLL HSDIVIDER FSM:
The global sequence when using PWRDN bit is the following:
. Disable Mx HSDIVIDER clock output related functional clock enable bits
(in CM_FCLKEN_xxx / CM_ICLKEN_xxx)
. Enable PWRDN bit of HSDIVIDER
. Disable PWRDN bit of HSDIVIDER
. Read current HSDIVIDER register value
. Write different value in HSDIVIDER register
. Write expected value in HSDIVIDER register
. Enable Mx HSDIVIDER clock output related functional clocks
(CM_FCLKEN_xxx / CM_ICLKEN_xxx)
Signed-off-by: Mike Turquette mturque...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Vijaykumar GN vijaykumar...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 41
++
arch/arm/mach-omap2/clock34xx.h |1 +
arch/arm/mach-omap2/clock34xx_data.c | 20
3 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index c1c1b93..1e6297f 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -133,6 +133,47 @@ const struct clkops clkops_omap3430es2_hsotgusb_wait = {
.find_companion = omap2_clk_dflt_find_companion,
};
+/**
+ * omap3_pwrdn_clk_enable_with_hsdiv_restore - enable clocks suffering
+ * from HSDivider PWRDN problem Implements Errata ID: i556.
+ * @clk: DPLL output struct clk
+ *
+ * 3630 only: dpll3_m3_ck, dpll4_m2_ck, dpll4_m3_ck, dpll4_m4_ck, dpll4_m5_ck
+ * dpll4_m6_ck dividers gets loaded with reset valueafter their respective
+ * PWRDN bits are set.
+ * Any dummy write (Any other value different from the Read value) to the
+ * corresponding CM_CLKSEL register will refresh the dividers.
+ */
+int omap3_pwrdn_clk_enable_with_hsdiv_restore(struct clk *clk)
+{
+ u32 dummy_v, orig_v, clksel_shift;
+ int ret;
+
+ /* Enable PWRDN bit of HSDIVIDER */
+ ret = omap2_dflt_clk_enable(clk);
+
+ /* Restore the dividers */
+ if (!ret) {
+ clksel_shift = __ffs(clk-parent-clksel_mask);
+ orig_v = dummy_v = __raw_readl(clk-parent-clksel_reg);
+
+ /* Write any other value different from the Read value */
+ dummy_v ^= (1 clksel_shift);
Shouldn't there also be a:
dummy_v = clk-parent-clksel_mask;
here to avoid writing to reserved bits?
+ __raw_writel(dummy_v, clk-parent-clksel_reg);
+
+ /* Write the original divider */
+ __raw_writel(orig_v, clk-parent-clksel_reg);
+ }
+ return ret;
+}
+
+const struct clkops clkops_omap3_pwrdn_with_hsdiv_wait_restore = {
+ .enable = omap3_pwrdn_clk_enable_with_hsdiv_restore,
+ .disable= omap2_dflt_clk_disable,
+ .find_companion = omap2_clk_dflt_find_companion,
+ .find_idlest= omap2_clk_dflt_find_idlest,
+};
+
const struct clkops omap3_clkops_noncore_dpll_ops = {
.enable = omap3_noncore_dpll_enable,
.disable= omap3_noncore_dpll_disable,
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 313efc0..29ef390 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -21,5 +21,6 @@ extern const struct clkops clkops_omap3430es2_ssi_wait;
extern const struct clkops clkops_omap3430es2_hsotgusb_wait;
extern const struct clkops clkops_omap3430es2_dss_usbhost_wait;
extern const struct clkops omap3_clkops_noncore_dpll_ops;
+extern const struct clkops clkops_omap3_pwrdn_with_hsdiv_wait_restore;
#endif
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index 8728f1f..9d11d53 100644
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -3240,6 +3240,26 @@ int __init omap3xxx_clk_init(void)
}
}
+ if (cpu_is_omap3630()) {
+
+ /*
+ * For 3630: override clkops_omap2_dflt_wait for the
+ * clocks affected from PWRDN reset Limitation
+ */
+ dpll3_m3x2_ck.ops =
+ clkops_omap3_pwrdn_with_hsdiv_wait_restore;
+
RE: [PATCHV3] OMAP3630: Clock: Workaround for DPLL HS divider limitation
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Wednesday, February 10, 2010 11:33 AM
To: G.N, Vijayakumar
Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath; Turquette, Mike;
khil...@deeprootsystems.com
Subject: Re: [PATCHV3] OMAP3630: Clock: Workaround for DPLL HS divider
limitation
Hello Mike, Vijayakumar,
one comment below.
On Tue, 9 Feb 2010, G.N, Vijayakumar wrote:
From: Mike Turquette mturque...@ti.com
Date: Fri, 5 Feb 2010 19:09:52 +0530
Subject: [PATCH] OMAP3630: Clock: Workaround for DPLL HS divider limitation
This patch implements a workaround for the DPLL HS divider limitation
in OMAP3630 as given by Errata ID: i556.
Errata:
When PWRDN bit is set, it resets the internal HSDIVIDER divide-by value
(Mx).
The reset value gets loaded instead of the previous value.
The following HSDIVIDERs exhibit above behavior:
. DPLL4 : M6 / M5 / M4 / M3 / M2 (CM_CLKEN_PLL[31:26] register bits)
. DPLL3 : M3 (CM_CLKEN_PLL[12] register bit).
Work Around:
It is mandatory to apply the following sequence to ensure the write
value will
be loaded in DPLL HSDIVIDER FSM:
The global sequence when using PWRDN bit is the following:
. Disable Mx HSDIVIDER clock output related functional clock enable bits
(in CM_FCLKEN_xxx / CM_ICLKEN_xxx)
. Enable PWRDN bit of HSDIVIDER
. Disable PWRDN bit of HSDIVIDER
. Read current HSDIVIDER register value
. Write different value in HSDIVIDER register
. Write expected value in HSDIVIDER register
. Enable Mx HSDIVIDER clock output related functional clocks
(CM_FCLKEN_xxx / CM_ICLKEN_xxx)
Signed-off-by: Mike Turquette mturque...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Vijaykumar GN vijaykumar...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 41
++
arch/arm/mach-omap2/clock34xx.h |1 +
arch/arm/mach-omap2/clock34xx_data.c | 20
3 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-
omap2/clock34xx.c
index c1c1b93..1e6297f 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -133,6 +133,47 @@ const struct clkops
clkops_omap3430es2_hsotgusb_wait = {
.find_companion = omap2_clk_dflt_find_companion,
};
+/**
+ * omap3_pwrdn_clk_enable_with_hsdiv_restore - enable clocks suffering
+ * from HSDivider PWRDN problem Implements Errata ID: i556.
+ * @clk: DPLL output struct clk
+ *
+ * 3630 only: dpll3_m3_ck, dpll4_m2_ck, dpll4_m3_ck, dpll4_m4_ck,
dpll4_m5_ck
+ * dpll4_m6_ck dividers gets loaded with reset valueafter their
respective
+ * PWRDN bits are set.
+ * Any dummy write (Any other value different from the Read value) to the
+ * corresponding CM_CLKSEL register will refresh the dividers.
+ */
+int omap3_pwrdn_clk_enable_with_hsdiv_restore(struct clk *clk)
+{
+ u32 dummy_v, orig_v, clksel_shift;
+ int ret;
+
+ /* Enable PWRDN bit of HSDIVIDER */
+ ret = omap2_dflt_clk_enable(clk);
+
+ /* Restore the dividers */
+ if (!ret) {
+ clksel_shift = __ffs(clk-parent-clksel_mask);
+ orig_v = dummy_v = __raw_readl(clk-parent-clksel_reg);
+
+ /* Write any other value different from the Read value */
+ dummy_v ^= (1 clksel_shift);
Shouldn't there also be a:
dummy_v = clk-parent-clksel_mask;
here to avoid writing to reserved bits?
XOR with 0x00 will always retains the original values, hence I don't see any
requirement of mask.
Example:
For CM_CLKSEL1_PLL
clksel_mask:
#define OMAP3430_DIV_DPLL3_MASK (0x1f 16)
clksel_shift = __ffs(clk-parent-clksel_mask); becomes 16
(1 clksel_shift) will become (1 16)
XOR operator will only change the Divisor's LSB 1st bit to it's negated value.
Hence we will be always changing the Divisor's LSB 1's bit and hence
the value written will be different one from the existing value and won't be
touching any reserved fileds.
+ __raw_writel(dummy_v, clk-parent-clksel_reg);
+
+ /* Write the original divider */
+ __raw_writel(orig_v, clk-parent-clksel_reg);
+ }
+ return ret;
+}
+
+const struct clkops clkops_omap3_pwrdn_with_hsdiv_wait_restore = {
+ .enable = omap3_pwrdn_clk_enable_with_hsdiv_restore,
+ .disable= omap2_dflt_clk_disable,
+ .find_companion = omap2_clk_dflt_find_companion,
+ .find_idlest= omap2_clk_dflt_find_idlest,
+};
+
const struct clkops omap3_clkops_noncore_dpll_ops = {
.enable = omap3_noncore_dpll_enable,
.disable= omap3_noncore_dpll_disable,
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-
omap2/clock34xx.h
index 313efc0..29ef390 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@
RE: [PATCHV3] OMAP3630: Clock: Workaround for DPLL HS divider limitation
Hello Vijayakumar, On Wed, 10 Feb 2010, G.N, Vijayakumar wrote: From: Paul Walmsley [mailto:p...@pwsan.com] Shouldn't there also be a: dummy_v = clk-parent-clksel_mask; here to avoid writing to reserved bits? XOR with 0x00 will always retains the original values, hence I don't see any requirement of mask. Example: For CM_CLKSEL1_PLL clksel_mask: #define OMAP3430_DIV_DPLL3_MASK (0x1f 16) clksel_shift = __ffs(clk-parent-clksel_mask); becomes 16 (1 clksel_shift) will become (1 16) XOR operator will only change the Divisor's LSB 1st bit to it's negated value. Hence we will be always changing the Divisor's LSB 1's bit and hence the value written will be different one from the existing value and won't be touching any reserved fileds. OK, thanks, looks like I misread the code. Queued for 2.6.34. - 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: [PATCHV3] OMAP3630: Clock: Workaround for DPLL HS divider limitation
Thanks :) -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, February 10, 2010 11:55 AM To: G.N, Vijayakumar Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath; Turquette, Mike; khil...@deeprootsystems.com Subject: RE: [PATCHV3] OMAP3630: Clock: Workaround for DPLL HS divider limitation Hello Vijayakumar, On Wed, 10 Feb 2010, G.N, Vijayakumar wrote: From: Paul Walmsley [mailto:p...@pwsan.com] Shouldn't there also be a: dummy_v = clk-parent-clksel_mask; here to avoid writing to reserved bits? XOR with 0x00 will always retains the original values, hence I don't see any requirement of mask. Example: For CM_CLKSEL1_PLL clksel_mask: #define OMAP3430_DIV_DPLL3_MASK (0x1f 16) clksel_shift = __ffs(clk-parent-clksel_mask); becomes 16 (1 clksel_shift) will become (1 16) XOR operator will only change the Divisor's LSB 1st bit to it's negated value. Hence we will be always changing the Divisor's LSB 1's bit and hence the value written will be different one from the existing value and won't be touching any reserved fileds. OK, thanks, looks like I misread the code. Queued for 2.6.34. - 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: [PATCHV3] OMAP3630: Clock: Workaround for DPLL HS divider limitation
On Wed, 10 Feb 2010, G.N, Vijayakumar wrote:
Thanks :)
I had to fix a few minor issues with the patch. Here's the patch as
applied. Please advise if there are any further comments.
- Paul
From d88ef2155dce7a7d995e6dea37433d1643827553 Mon Sep 17 00:00:00 2001
From: Mike Turquette mturque...@ti.com
Date: Tue, 9 Feb 2010 23:26:45 -0700
Subject: [PATCH] OMAP3630: Clock: Workaround for DPLL HS divider limitation
This patch implements a workaround for the DPLL HS divider limitation
in OMAP3630 as given by Errata ID: i556.
Errata:
When PWRDN bit is set, it resets the internal HSDIVIDER divide-by value (Mx).
The reset value gets loaded instead of the previous value.
The following HSDIVIDERs exhibit above behavior:
. DPLL4 : M6 / M5 / M4 / M3 / M2 (CM_CLKEN_PLL[31:26] register bits)
. DPLL3 : M3 (CM_CLKEN_PLL[12] register bit).
Work Around:
It is mandatory to apply the following sequence to ensure the write
value will
be loaded in DPLL HSDIVIDER FSM:
The global sequence when using PWRDN bit is the following:
. Disable Mx HSDIVIDER clock output related functional clock enable bits
(in CM_FCLKEN_xxx / CM_ICLKEN_xxx)
. Enable PWRDN bit of HSDIVIDER
. Disable PWRDN bit of HSDIVIDER
. Read current HSDIVIDER register value
. Write different value in HSDIVIDER register
. Write expected value in HSDIVIDER register
. Enable Mx HSDIVIDER clock output related functional clocks
(CM_FCLKEN_xxx / CM_ICLKEN_xxx)
Signed-off-by: Mike Turquette mturque...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Vijaykumar GN vijaykumar...@ti.com
[p...@pwsan.com: updated patch to apply; made workaround function static;
marked as being 36xx-specific]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock34xx.c | 42 ++
arch/arm/mach-omap2/clock34xx.h |3 ++
arch/arm/mach-omap2/clock34xx_data.c | 19 +++
3 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 37da629..ea6c2d6 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -150,6 +150,48 @@ const struct clkops clkops_omap3430es2_hsotgusb_wait = {
.find_companion = omap2_clk_dflt_find_companion,
};
+/**
+ * omap36xx_pwrdn_clk_enable_with_hsdiv_restore - enable clocks suffering
+ * from HSDivider PWRDN problem Implements Errata ID: i556.
+ * @clk: DPLL output struct clk
+ *
+ * 3630 only: dpll3_m3_ck, dpll4_m2_ck, dpll4_m3_ck, dpll4_m4_ck,
+ * dpll4_m5_ck dpll4_m6_ck dividers gets loaded with reset
+ * valueafter their respective PWRDN bits are set. Any dummy write
+ * (Any other value different from the Read value) to the
+ * corresponding CM_CLKSEL register will refresh the dividers.
+ */
+static int omap36xx_pwrdn_clk_enable_with_hsdiv_restore(struct clk *clk)
+{
+ u32 dummy_v, orig_v, clksel_shift;
+ int ret;
+
+ /* Clear PWRDN bit of HSDIVIDER */
+ ret = omap2_dflt_clk_enable(clk);
+
+ /* Restore the dividers */
+ if (!ret) {
+ clksel_shift = __ffs(clk-parent-clksel_mask);
+ orig_v = dummy_v = __raw_readl(clk-parent-clksel_reg);
+
+ /* Write any other value different from the Read value */
+ dummy_v ^= (1 clksel_shift);
+ __raw_writel(dummy_v, clk-parent-clksel_reg);
+
+ /* Write the original divider */
+ __raw_writel(orig_v, clk-parent-clksel_reg);
+ }
+
+ return ret;
+}
+
+const struct clkops clkops_omap36xx_pwrdn_with_hsdiv_wait_restore = {
+ .enable = omap36xx_pwrdn_clk_enable_with_hsdiv_restore,
+ .disable= omap2_dflt_clk_disable,
+ .find_companion = omap2_clk_dflt_find_companion,
+ .find_idlest= omap2_clk_dflt_find_idlest,
+};
+
const struct clkops clkops_noncore_dpll_ops = {
.enable = omap3_noncore_dpll_enable,
.disable= omap3_noncore_dpll_disable,
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index e61e653..b9c65f5 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -26,4 +26,7 @@ extern const struct clkops clkops_noncore_dpll_ops;
extern const struct clkops clkops_am35xx_ipss_module_wait;
extern const struct clkops clkops_am35xx_ipss_wait;
+/* OMAP36xx-specific clkops */
+extern const struct clkops clkops_omap36xx_pwrdn_with_hsdiv_wait_restore;
+
#endif
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index d9d5b2e..caa6a41 100644
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -3358,6 +3358,25 @@ int __init omap3xxx_clk_init(void)
}
}
+ if (cpu_is_omap3630()) {
+ /*
+* For 3630: override clkops_omap2_dflt_wait for the
+* clocks affected from PWRDN reset Limitation
RE: [PATCHV3] OMAP3630: Clock: Workaround for DPLL HS divider limitation
No Comments.
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Wednesday, February 10, 2010 12:09 PM
To: G.N, Vijayakumar
Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath; Turquette, Mike;
khil...@deeprootsystems.com
Subject: RE: [PATCHV3] OMAP3630: Clock: Workaround for DPLL HS divider
limitation
On Wed, 10 Feb 2010, G.N, Vijayakumar wrote:
Thanks :)
I had to fix a few minor issues with the patch. Here's the patch as
applied. Please advise if there are any further comments.
- Paul
From d88ef2155dce7a7d995e6dea37433d1643827553 Mon Sep 17 00:00:00 2001
From: Mike Turquette mturque...@ti.com
Date: Tue, 9 Feb 2010 23:26:45 -0700
Subject: [PATCH] OMAP3630: Clock: Workaround for DPLL HS divider limitation
This patch implements a workaround for the DPLL HS divider limitation
in OMAP3630 as given by Errata ID: i556.
Errata:
When PWRDN bit is set, it resets the internal HSDIVIDER divide-by value (Mx).
The reset value gets loaded instead of the previous value.
The following HSDIVIDERs exhibit above behavior:
. DPLL4 : M6 / M5 / M4 / M3 / M2 (CM_CLKEN_PLL[31:26] register bits)
. DPLL3 : M3 (CM_CLKEN_PLL[12] register bit).
Work Around:
It is mandatory to apply the following sequence to ensure the write
value will
be loaded in DPLL HSDIVIDER FSM:
The global sequence when using PWRDN bit is the following:
. Disable Mx HSDIVIDER clock output related functional clock enable bits
(in CM_FCLKEN_xxx / CM_ICLKEN_xxx)
. Enable PWRDN bit of HSDIVIDER
. Disable PWRDN bit of HSDIVIDER
. Read current HSDIVIDER register value
. Write different value in HSDIVIDER register
. Write expected value in HSDIVIDER register
. Enable Mx HSDIVIDER clock output related functional clocks
(CM_FCLKEN_xxx / CM_ICLKEN_xxx)
Signed-off-by: Mike Turquette mturque...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Vijaykumar GN vijaykumar...@ti.com
[p...@pwsan.com: updated patch to apply; made workaround function static;
marked as being 36xx-specific]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock34xx.c | 42
++
arch/arm/mach-omap2/clock34xx.h |3 ++
arch/arm/mach-omap2/clock34xx_data.c | 19 +++
3 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 37da629..ea6c2d6 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -150,6 +150,48 @@ const struct clkops clkops_omap3430es2_hsotgusb_wait
= {
.find_companion = omap2_clk_dflt_find_companion,
};
+/**
+ * omap36xx_pwrdn_clk_enable_with_hsdiv_restore - enable clocks suffering
+ * from HSDivider PWRDN problem Implements Errata ID: i556.
+ * @clk: DPLL output struct clk
+ *
+ * 3630 only: dpll3_m3_ck, dpll4_m2_ck, dpll4_m3_ck, dpll4_m4_ck,
+ * dpll4_m5_ck dpll4_m6_ck dividers gets loaded with reset
+ * valueafter their respective PWRDN bits are set. Any dummy write
+ * (Any other value different from the Read value) to the
+ * corresponding CM_CLKSEL register will refresh the dividers.
+ */
+static int omap36xx_pwrdn_clk_enable_with_hsdiv_restore(struct clk *clk)
+{
+ u32 dummy_v, orig_v, clksel_shift;
+ int ret;
+
+ /* Clear PWRDN bit of HSDIVIDER */
+ ret = omap2_dflt_clk_enable(clk);
+
+ /* Restore the dividers */
+ if (!ret) {
+ clksel_shift = __ffs(clk-parent-clksel_mask);
+ orig_v = dummy_v = __raw_readl(clk-parent-clksel_reg);
+
+ /* Write any other value different from the Read value */
+ dummy_v ^= (1 clksel_shift);
+ __raw_writel(dummy_v, clk-parent-clksel_reg);
+
+ /* Write the original divider */
+ __raw_writel(orig_v, clk-parent-clksel_reg);
+ }
+
+ return ret;
+}
+
+const struct clkops clkops_omap36xx_pwrdn_with_hsdiv_wait_restore = {
+ .enable = omap36xx_pwrdn_clk_enable_with_hsdiv_restore,
+ .disable= omap2_dflt_clk_disable,
+ .find_companion = omap2_clk_dflt_find_companion,
+ .find_idlest= omap2_clk_dflt_find_idlest,
+};
+
const struct clkops clkops_noncore_dpll_ops = {
.enable = omap3_noncore_dpll_enable,
.disable= omap3_noncore_dpll_disable,
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index e61e653..b9c65f5 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -26,4 +26,7 @@ extern const struct clkops clkops_noncore_dpll_ops;
extern const struct clkops clkops_am35xx_ipss_module_wait;
extern const struct clkops clkops_am35xx_ipss_wait;
+/* OMAP36xx-specific clkops */
+extern const struct clkops clkops_omap36xx_pwrdn_with_hsdiv_wait_restore;
+
#endif
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
Re: [PATCH] dspbridge: Simplify Atoi() method
On Wed, Feb 10, 2010 at 4:02 AM, Omar Ramirez Luna omar.rami...@ti.com wrote:
Try to use simple_strtol() kernel native method instead.
strtol or strtoul?
I don't know for sure, see below.
However, there are opened questions:
- why type of Atoi() is s32 if the sign is used only to detect base?
This is the question about l vs ul.
+ } else if (*pch (pch[strlen(pch) - 1] | 0x20 == 'h')) {
perhaps tolower(x)
Yep, I saw only internal macro in lib/vsprintf.c, but totally forgot
about ctype.h.
--
With Best Regards,
Andy Shevchenko
--
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
