Re: [PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
* Hiremath, Vaibhav [120803 03:34]: > > Actually its not that. > AM335x needs to be added as part of cpu_class_is_omap2(), without this it > gets into issues. > The patch has been already submitted to the list, but still not merged by > Tony. Let's just add it to the list of cpu_class_is_omap2() with a proper patch description for the fix. Then we still need to sort it out properly from common zImage point of view without having to maintain that list. Vaibhav, can you please post your original patch with the description updated for v3.6-rc1? 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: v3.6-rc1 DSS issues/regression
On Tuesday 07 August 2012 03:44 AM, Aaro Koskinen wrote: Hi, On Mon, Aug 06, 2012 at 11:06:28PM +0530, Archit Taneja wrote: On Mon, 2012-08-06 at 19:47 +0300, Aaro Koskinen wrote: I can't get the display on N900 (SDI, acx565akm) to work with v3.6-rc1 kernel, it's just full of flicker/noise. According to git-bisect, the problem is introduced by the commit: commit f476ae9dab3234532d41d36beb4ba7be838fa786 Author: Archit Taneja Date: Fri Jun 29 14:37:03 2012 +0530 OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface [...] The diff I have shared introduces the register writes back. This should make it work like before. But we need to figure out which parameter write needs to be done immediately. If this works, could you remove each dispc register write turn by turn, and point out which is the culprit one? Thanks, the following one makes the display to work again: diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c index 5d31699..3c9f598 100644 --- a/drivers/video/omap2/dss/sdi.c +++ b/drivers/video/omap2/dss/sdi.c @@ -46,6 +46,9 @@ static void sdi_config_lcd_manager(struct omap_dss_device *dssdev) sdi.mgr_config.video_port_width = 24; sdi.mgr_config.lcden_sig_polarity = 1; + dispc_mgr_set_clock_div(dssdev->manager->id, + &sdi.mgr_config.clock_info); + Thanks for finding this. It's a bit peculiar why this is happening. The DISPC_DIVISOR is a shadow register for sure. I don't know much about SDI, but it looks like the SDI PLL needs the free running pixel clock from the LCD manager. To achieve this, we set PCKFREEENABLE. The thing I don't understand is that whether the free running pixel clock at this point would be derived out of the old LCD and PCD values, or the new ones? It should have been old since LCD and PCD are shadowed registers. In other words, I am suspecting that the field PCKFREEENABLE does a copy of the LCD and PCD dividers from the shadow registers to the working registers. The regdump shows that there were issues in SDI initialization. Tomi, Any ideas about this? Archit -- 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: USB: EHCI broken on 3.5?
On Mon, Aug 06, 2012 at 11:21:27AM -0700, Kevin Hilman wrote: > Hi Joe, > > "Joe Woodward" writes: > > > I have a GUMSTIX Overo AirSTORM (AM3703-based). > > > > When running a 3.4 kernel the USB host works just fine! > > > > However when switching to 3.5 I get a few new warning messages and USB host > > no longer works. > > As usual, thanks for the bug/problem reports. > > EHCI is broken in many ways in v3.5. Since the maintainers were not > fixing the problems (specifically the PM problems which broke PM for the > rest of the SoC too), I requested it be disabled by default in > omap2plus_defconfig. > > Kesheva sent out a large revert patch, and Russ Dill sent out an > alternative set of 2 patches that were more targetted fixes, but I lost > track of the final resolution there (if any.) Alan Stern asked to wait for his patches first... -- balbi signature.asc Description: Digital signature
Re: [PATCH] Revert "ARM: OMAP3530evm: set pendown_state and debounce time for ads7846"
On 08/07/12 04:42, Zumeng Chen wrote: > 于 2012年08月07日 04:22, Igor Grinberg 写道: >> 1) The above commit introduced a common ->get_pendown_state() function >> into the generic code, but that function was board-specific for the >> OMAP3EVM and thus broke most other boards using this code. >> >> 2) The above commit was mis-merged introducing another bug which >> prevents the ads7846 driver probe function to succeed. >> The omap_ads7846_init() function frees the pendown GPIO in case there is >> no ->get_pendown_state() function set by the caller (board specific >> code), so it can be requested later by the ads7846 driver. >> The above commit add a common ->get_pendown_state() function without >> removing the gpio_free() call and thus once the ads7846 driver tries >> to use the pendown GPIO, it crashes as the pendown GPIO has not been >> requested. >> >> 3) The above commit introduces NO new functionality as >> get_pendown_state() function is already implemented in a suitable way by >> the ads7846 driver and the debounce time handling has already been >> fixed by commit 97ee9f01 (ARM: OMAP: fix the ads7846 init code). > Igor, > > I suspect these two patches(this and 97ee9f01) works well, and there > is something new introduced in ads7846.c, I'll try to look at that new > stuff in this weekend. > > Please refer to in-line comments: > > Regards, > Zumeng >> >> This reverts commit 16aced80f6739beb2a6ff7b6f96c83ba80d331e8. >> >> Conflicts: >> arch/arm/mach-omap2/common-board-devices.c >> >> Solved by taking the working version prior to the above commit. >> >> Cc: Zumeng Chen >> Cc: Arnd Bergmann >> Signed-off-by: Igor Grinberg >> --- >> Kevin, sorry for the late reply. >> How about the above commit message and the below patch? >> >> The patch applies cleanly to Tony's master branch (6 Aug 2012) >> or Kevin's kevin-omap-pm/for_3.6/fixes/ads7846 >> after resetting two top most commits. >> >> This patch has been tested on both above branches on cm-t3730. >> Any other board tested will be greately appreciated. >> >> Also, if after all said in the commit message, you still don't >> want to revert the original patch, feel free to post your thoughts. >> >> arch/arm/mach-omap2/board-omap3evm.c |1 + >> arch/arm/mach-omap2/common-board-devices.c | 11 --- >> arch/arm/mach-omap2/common-board-devices.h |1 - >> 3 files changed, 1 insertions(+), 12 deletions(-) >> >> diff --git a/arch/arm/mach-omap2/board-omap3evm.c >> b/arch/arm/mach-omap2/board-omap3evm.c >> index ef230a0..0d362e9 100644 >> --- a/arch/arm/mach-omap2/board-omap3evm.c >> +++ b/arch/arm/mach-omap2/board-omap3evm.c >> @@ -58,6 +58,7 @@ >> #include "hsmmc.h" >> #include "common-board-devices.h" >> >> +#define OMAP3_EVM_TS_GPIO 175 >> #define OMAP3_EVM_EHCI_VBUS 22 >> #define OMAP3_EVM_EHCI_SELECT 61 >> >> diff --git a/arch/arm/mach-omap2/common-board-devices.c >> b/arch/arm/mach-omap2/common-board-devices.c >> index 1473474..c187586 100644 >> --- a/arch/arm/mach-omap2/common-board-devices.c >> +++ b/arch/arm/mach-omap2/common-board-devices.c >> @@ -35,16 +35,6 @@ static struct omap2_mcspi_device_config >> ads7846_mcspi_config = { >> .turbo_mode = 0, >> }; >> >> -/* >> - * ADS7846 driver maybe request a gpio according to the value >> - * of pdata->get_pendown_state, but we have done this. So set >> - * get_pendown_state to avoid twice gpio requesting. >> - */ >> -static int omap3_get_pendown_state(void) >> -{ >> -return !gpio_get_value(OMAP3_EVM_TS_GPIO); >> -} >> - >> static struct ads7846_platform_data ads7846_config = { >> .x_max = 0x0fff, >> .y_max = 0x0fff, >> @@ -55,7 +45,6 @@ static struct ads7846_platform_data ads7846_config = { >> .debounce_rep = 1, >> .gpio_pendown = -EINVAL, >> .keep_vref_on = 1, >> -.get_pendown_state = &omap3_get_pendown_state, > You remove this, then please look at the following codes: > > drivers/input/touchscreen/ads7846.c > > 969 if (pdata->get_pendown_state) { > 970 ts->get_pendown_state = pdata->get_pendown_state; > 971 } else if (gpio_is_valid(pdata->gpio_pendown)) { > 972 > 973 err = gpio_request_one(pdata->gpio_pendown, GPIOF_IN, > ^^^, the driver will want to request again, then it should > be error if i'm right. This patch removes the get_pendown_state function pointer from the ads7846_platform_data and gpio_free() fires as there is no get_pendown_state and therefore there will be no problem to request it again by the ads7846 driver. So, no there will be no error and if you still doubt, please test. > > 974 "ads7846_pendown"); > 975 if (err) { > 976 dev_err(&spi->dev, > 977 "failed to request/setup pendown GPIO%d: %d\n", > 978 pdata->gpio_pendown, err); > 979 return err; > 980 } > 981 > 982 ts->gpio_pendown = pdata->gpio_pendown; > 983 > 984 } else { [...] -- Regards, Igor. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in t
Re: [PATCH] Revert "ARM: OMAP3530evm: set pendown_state and debounce time for ads7846"
On 08/06/12 23:52, Kevin Hilman wrote: > Igor Grinberg writes: > >> 1) The above commit introduced a common ->get_pendown_state() function >> into the generic code, but that function was board-specific for the >> OMAP3EVM and thus broke most other boards using this code. >> >> 2) The above commit was mis-merged introducing another bug which >> prevents the ads7846 driver probe function to succeed. >> The omap_ads7846_init() function frees the pendown GPIO in case there is >> no ->get_pendown_state() function set by the caller (board specific >> code), so it can be requested later by the ads7846 driver. >> The above commit add a common ->get_pendown_state() function without >> removing the gpio_free() call and thus once the ads7846 driver tries >> to use the pendown GPIO, it crashes as the pendown GPIO has not been >> requested. >> >> 3) The above commit introduces NO new functionality as >> get_pendown_state() function is already implemented in a suitable way by >> the ads7846 driver and the debounce time handling has already been >> fixed by commit 97ee9f01 (ARM: OMAP: fix the ads7846 init code). >> >> This reverts commit 16aced80f6739beb2a6ff7b6f96c83ba80d331e8. >> >> Conflicts: >> arch/arm/mach-omap2/common-board-devices.c >> >> Solved by taking the working version prior to the above commit. >> >> Cc: Zumeng Chen >> Cc: Arnd Bergmann >> Signed-off-by: Igor Grinberg >> --- >> Kevin, sorry for the late reply. >> How about the above commit message and the below patch? >> >> The patch applies cleanly to Tony's master branch (6 Aug 2012) >> or Kevin's kevin-omap-pm/for_3.6/fixes/ads7846 >> after resetting two top most commits. > > Now that v3.6-rc1 is out, it should probalby be applied on top of -rc1. > I've taken care of that and tested as well. > >> This patch has been tested on both above branches on cm-t3730. >> Any other board tested will be greately appreciated. >> >> Also, if after all said in the commit message, you still don't >> want to revert the original patch, feel free to post your thoughts. > > After all the digging I did, I agree that the revert is the best > solution. > > While it's a slightly different problem/bug, I think the gpio_free() in > common-board-devices.c should still be unconditonal since the > gpio_request() is now unconditional. That can be a separate patch though. Well, the logic behind the conditional gpio_free() is: if a board specific code provides a board specific get_pendown_state() function (which is different from the one in the ads7846 driver), that board will not need to re-request the pendown GPIO (duplicate code). If we free the pendown GPIO unconditionally, then the board specific code will have to re-request it. So, I think, no - it should be conditional. > > Acked-by: Kevin Hilman > Tested-by: Kevin Hilman > > Tested on 3430/n900, 3530/Overo, 3730/Overo STORM, 3730/BB-xM. Thanks! [...] -- Regards, Igor. -- 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] i2c: omap: sanitize exit path
move the goto out label one line down, so that it can be used when stat is read as zero. All other exits, can be done with a break statement. While at that, also break out as soon as we complete draining IRQ, since at that time we know we transferred everything there was to be transferred. Signed-off-by: Felipe Balbi --- drivers/i2c/busses/i2c-omap.c | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 22efaba..57c2824 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -898,27 +898,26 @@ omap_i2c_isr_thread(int this_irq, void *dev_id) if (!stat) { /* my work here is done */ - spin_unlock_irqrestore(&dev->lock, flags); - return IRQ_HANDLED; + goto out; } dev_dbg(dev->dev, "IRQ (ISR = 0x%04x)\n", stat); if (count++ == 100) { dev_warn(dev->dev, "Too much work in one IRQ\n"); - goto out; + break; } if (stat & OMAP_I2C_STAT_NACK) { err |= OMAP_I2C_STAT_NACK; omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK); - goto out; + break; } if (stat & OMAP_I2C_STAT_AL) { dev_err(dev->dev, "Arbitration lost\n"); err |= OMAP_I2C_STAT_AL; omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL); - goto out; + break; } /* @@ -931,7 +930,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id) OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR | OMAP_I2C_STAT_ARDY)); - goto out; + break; } if (stat & OMAP_I2C_STAT_RDR) { @@ -946,7 +945,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id) i2c_omap_errata_i207(dev, stat); omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR); - continue; + break; } if (stat & OMAP_I2C_STAT_RRDY) { @@ -969,10 +968,10 @@ omap_i2c_isr_thread(int this_irq, void *dev_id) ret = omap_i2c_transmit_data(dev, num_bytes, true); if (ret < 0) - goto out; + break; omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XDR); - continue; + break; } if (stat & OMAP_I2C_STAT_XRDY) { @@ -984,7 +983,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id) ret = omap_i2c_transmit_data(dev, num_bytes, false); if (ret < 0) - goto out; + break; omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XRDY); continue; @@ -994,19 +993,20 @@ omap_i2c_isr_thread(int this_irq, void *dev_id) dev_err(dev->dev, "Receive overrun\n"); err |= OMAP_I2C_STAT_ROVR; omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ROVR); - goto out; + break; } if (stat & OMAP_I2C_STAT_XUDF) { dev_err(dev->dev, "Transmit underflow\n"); err |= OMAP_I2C_STAT_XUDF; omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XUDF); - goto out; + break; } } while (stat); -out: omap_i2c_complete_cmd(dev, err); + +out: spin_unlock_irqrestore(&dev->lock, flags); return IRQ_HANDLED; -- 1.7.12.rc0 -- 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] driver: misc: bmp085: remove "of_match_table" property.
Hi, On Mon, Aug 06, 2012 at 04:42:14PM +0100, Mark Brown wrote: > On Mon, Aug 06, 2012 at 12:30:34PM +0300, Felipe Balbi wrote: > > On Mon, Aug 06, 2012 at 02:58:44PM +0530, Sourav Poddar wrote: > > > There is an automatic binding done for I2C devices in the of_i2c core > > > code. So, DT will be able to bind to any I2C device using the > > > already existing table: MODULE_DEVICE_TABLE(i2c, bmp085_id). > > > Acked-by: Felipe Balbi > > It's good practice to have an explict compatible string even if the > default happens to work in order to avoid any name clashes. of_i2c.c makes no use whatsoever of the compatible string. See that it will build an i2c_boardinfo and register a new device. That compatible string is just churn and has no use at all. -- balbi signature.asc Description: Digital signature
Warning: E-mail viruses detected
Our e-mail content detector has just been triggered by a message you sent: To: m...@simplesymbol.com Subject: Error Date: Tue Aug 7 11:48:30 2012 One or more of the attachments (simplesymbol.com) are on the list of unacceptable attachments for this site and will not have been delivered. Consider renaming the files to avoid this constraint. The virus detector said this about the message: Report: Report: MailScanner: Executable DOS/Windows programs are dangerous in email (simplesymbol.com) -- MailScanner Email Virus Scanner -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "ARM: OMAP3530evm: set pendown_state and debounce time for ads7846"
于 2012年08月07日 04:52, Kevin Hilman 写道: Igor Grinberg writes: 1) The above commit introduced a common ->get_pendown_state() function into the generic code, but that function was board-specific for the OMAP3EVM and thus broke most other boards using this code. 2) The above commit was mis-merged introducing another bug which prevents the ads7846 driver probe function to succeed. The omap_ads7846_init() function frees the pendown GPIO in case there is no ->get_pendown_state() function set by the caller (board specific code), so it can be requested later by the ads7846 driver. The above commit add a common ->get_pendown_state() function without removing the gpio_free() call and thus once the ads7846 driver tries to use the pendown GPIO, it crashes as the pendown GPIO has not been requested. 3) The above commit introduces NO new functionality as get_pendown_state() function is already implemented in a suitable way by the ads7846 driver and the debounce time handling has already been fixed by commit 97ee9f01 (ARM: OMAP: fix the ads7846 init code). This reverts commit 16aced80f6739beb2a6ff7b6f96c83ba80d331e8. Conflicts: arch/arm/mach-omap2/common-board-devices.c Solved by taking the working version prior to the above commit. Cc: Zumeng Chen Cc: Arnd Bergmann Signed-off-by: Igor Grinberg --- Kevin, sorry for the late reply. How about the above commit message and the below patch? The patch applies cleanly to Tony's master branch (6 Aug 2012) or Kevin's kevin-omap-pm/for_3.6/fixes/ads7846 after resetting two top most commits. Now that v3.6-rc1 is out, it should probalby be applied on top of -rc1. I've taken care of that and tested as well. This patch has been tested on both above branches on cm-t3730. Any other board tested will be greately appreciated. Also, if after all said in the commit message, you still don't want to revert the original patch, feel free to post your thoughts. After all the digging I did, I agree that the revert is the best solution. While it's a slightly different problem/bug, I think the gpio_free() in common-board-devices.c should still be unconditonal since the gpio_request() is now unconditional. That can be a separate patch though. Absolutely right, acked this. Regards, Zumeng Acked-by: Kevin Hilman Tested-by: Kevin Hilman Tested on 3430/n900, 3530/Overo, 3730/Overo STORM, 3730/BB-xM. The Overo boards were the ones that were crashing due to this bug since the pendown GPIO was the only one used in the bank. Tony, can you queue this up for v3.6-rc? I have a version in my for_3.6/fixes/ads7846-2 branch with the tags above applied, based on v3.6-rc1. Thanks Kevin arch/arm/mach-omap2/board-omap3evm.c |1 + arch/arm/mach-omap2/common-board-devices.c | 11 --- arch/arm/mach-omap2/common-board-devices.h |1 - 3 files changed, 1 insertions(+), 12 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c index ef230a0..0d362e9 100644 --- a/arch/arm/mach-omap2/board-omap3evm.c +++ b/arch/arm/mach-omap2/board-omap3evm.c @@ -58,6 +58,7 @@ #include "hsmmc.h" #include "common-board-devices.h" +#define OMAP3_EVM_TS_GPIO 175 #define OMAP3_EVM_EHCI_VBUS 22 #define OMAP3_EVM_EHCI_SELECT 61 diff --git a/arch/arm/mach-omap2/common-board-devices.c b/arch/arm/mach-omap2/common-board-devices.c index 1473474..c187586 100644 --- a/arch/arm/mach-omap2/common-board-devices.c +++ b/arch/arm/mach-omap2/common-board-devices.c @@ -35,16 +35,6 @@ static struct omap2_mcspi_device_config ads7846_mcspi_config = { .turbo_mode = 0, }; -/* - * ADS7846 driver maybe request a gpio according to the value - * of pdata->get_pendown_state, but we have done this. So set - * get_pendown_state to avoid twice gpio requesting. - */ -static int omap3_get_pendown_state(void) -{ - return !gpio_get_value(OMAP3_EVM_TS_GPIO); -} - static struct ads7846_platform_data ads7846_config = { .x_max = 0x0fff, .y_max = 0x0fff, @@ -55,7 +45,6 @@ static struct ads7846_platform_data ads7846_config = { .debounce_rep = 1, .gpio_pendown = -EINVAL, .keep_vref_on = 1, - .get_pendown_state =&omap3_get_pendown_state, }; static struct spi_board_info ads7846_spi_board_info __initdata = { diff --git a/arch/arm/mach-omap2/common-board-devices.h b/arch/arm/mach-omap2/common-board-devices.h index 4c4ef6a..a0b4a428 100644 --- a/arch/arm/mach-omap2/common-board-devices.h +++ b/arch/arm/mach-omap2/common-board-devices.h @@ -4,7 +4,6 @@ #include "twl-common.h" #define NAND_BLOCK_SIZE SZ_128K -#define OMAP3_EVM_TS_GPIO 175 struct mtd_partition; struct ads7846_platform_data; -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "ARM: OMAP3530evm: set pendown_state and debounce time for ads7846"
于 2012年08月07日 04:22, Igor Grinberg 写道: > 1) The above commit introduced a common ->get_pendown_state() function > into the generic code, but that function was board-specific for the > OMAP3EVM and thus broke most other boards using this code. > > 2) The above commit was mis-merged introducing another bug which > prevents the ads7846 driver probe function to succeed. > The omap_ads7846_init() function frees the pendown GPIO in case there is > no ->get_pendown_state() function set by the caller (board specific > code), so it can be requested later by the ads7846 driver. > The above commit add a common ->get_pendown_state() function without > removing the gpio_free() call and thus once the ads7846 driver tries > to use the pendown GPIO, it crashes as the pendown GPIO has not been > requested. > > 3) The above commit introduces NO new functionality as > get_pendown_state() function is already implemented in a suitable way by > the ads7846 driver and the debounce time handling has already been > fixed by commit 97ee9f01 (ARM: OMAP: fix the ads7846 init code). Igor, I suspect these two patches(this and 97ee9f01) works well, and there is something new introduced in ads7846.c, I'll try to look at that new stuff in this weekend. Please refer to in-line comments: Regards, Zumeng > > This reverts commit 16aced80f6739beb2a6ff7b6f96c83ba80d331e8. > > Conflicts: > arch/arm/mach-omap2/common-board-devices.c > > Solved by taking the working version prior to the above commit. > > Cc: Zumeng Chen > Cc: Arnd Bergmann > Signed-off-by: Igor Grinberg > --- > Kevin, sorry for the late reply. > How about the above commit message and the below patch? > > The patch applies cleanly to Tony's master branch (6 Aug 2012) > or Kevin's kevin-omap-pm/for_3.6/fixes/ads7846 > after resetting two top most commits. > > This patch has been tested on both above branches on cm-t3730. > Any other board tested will be greately appreciated. > > Also, if after all said in the commit message, you still don't > want to revert the original patch, feel free to post your thoughts. > > arch/arm/mach-omap2/board-omap3evm.c |1 + > arch/arm/mach-omap2/common-board-devices.c | 11 --- > arch/arm/mach-omap2/common-board-devices.h |1 - > 3 files changed, 1 insertions(+), 12 deletions(-) > > diff --git a/arch/arm/mach-omap2/board-omap3evm.c > b/arch/arm/mach-omap2/board-omap3evm.c > index ef230a0..0d362e9 100644 > --- a/arch/arm/mach-omap2/board-omap3evm.c > +++ b/arch/arm/mach-omap2/board-omap3evm.c > @@ -58,6 +58,7 @@ > #include "hsmmc.h" > #include "common-board-devices.h" > > +#define OMAP3_EVM_TS_GPIO175 > #define OMAP3_EVM_EHCI_VBUS 22 > #define OMAP3_EVM_EHCI_SELECT61 > > diff --git a/arch/arm/mach-omap2/common-board-devices.c > b/arch/arm/mach-omap2/common-board-devices.c > index 1473474..c187586 100644 > --- a/arch/arm/mach-omap2/common-board-devices.c > +++ b/arch/arm/mach-omap2/common-board-devices.c > @@ -35,16 +35,6 @@ static struct omap2_mcspi_device_config > ads7846_mcspi_config = { > .turbo_mode = 0, > }; > > -/* > - * ADS7846 driver maybe request a gpio according to the value > - * of pdata->get_pendown_state, but we have done this. So set > - * get_pendown_state to avoid twice gpio requesting. > - */ > -static int omap3_get_pendown_state(void) > -{ > - return !gpio_get_value(OMAP3_EVM_TS_GPIO); > -} > - > static struct ads7846_platform_data ads7846_config = { > .x_max = 0x0fff, > .y_max = 0x0fff, > @@ -55,7 +45,6 @@ static struct ads7846_platform_data ads7846_config = { > .debounce_rep = 1, > .gpio_pendown = -EINVAL, > .keep_vref_on = 1, > - .get_pendown_state = &omap3_get_pendown_state, You remove this, then please look at the following codes: drivers/input/touchscreen/ads7846.c 969 if (pdata->get_pendown_state) { 970 ts->get_pendown_state = pdata->get_pendown_state; 971 } else if (gpio_is_valid(pdata->gpio_pendown)) { 972 973 err = gpio_request_one(pdata->gpio_pendown, GPIOF_IN, ^^^, the driver will want to request again, then it should be error if i'm right. 974 "ads7846_pendown"); 975 if (err) { 976 dev_err(&spi->dev, 977 "failed to request/setup pendown GPIO%d: %d\n", 978 pdata->gpio_pendown, err); 979 return err; 980 } 981 982 ts->gpio_pendown = pdata->gpio_pendown; 983 984 } else { Regards, Zumeng > }; > > static struct spi_board_info ads7846_spi_board_info __initdata = { > diff --git a/arch/arm/mach-omap2/common-board-devices.h > b/arch/arm/mach-omap2/common-board-devices.h > index 4c4ef6a..a0b4a428 100644 > --- a/arch/arm/mach-omap2/common-board-devices.h > +++ b/arch/arm/mach-omap2/common-board-devices.h > @@ -4,7 +4,6 @@ > #include "twl-common.h" > > #define NAND_BLOCK_SIZE SZ_128K > -#define OMAP3_EVM_TS_GPIO175 > > struct mtd_partition; > struct ads7846_platform_data; -- To unsubscribe from this list: send the line "unsubscr
Re: [PATCH] I2C: OMAP: xfer: fix runtime PM get/put balance on error
Hi Wolfram, Kevin Hilman writes: > In omap_i2c_xfer(), ensure pm_runtime_put() is called, even on > failure. > > Without this, after a failed xfer, the runtime PM usecount will have > been incremented, but not decremented causing the usecount to never > reach zero after a failure. This keeps the device always runtime PM > enabled which keeps the enclosing power domain active, and prevents > full-chip retention/off from happening during idle. > > Cc: Shubhrajyoti D > Signed-off-by: Kevin Hilman > --- > This patch applies to current i2c-embedded/for-next branch This one is needed for v3.6. Can you queue this up as a fix for v3.6-rc? Thanks, Kevin > drivers/i2c/busses/i2c-omap.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > index 9895fa7..b105733 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -582,7 +582,7 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg > msgs[], int num) > > r = pm_runtime_get_sync(dev->dev); > if (IS_ERR_VALUE(r)) > - return r; > + goto out; > > r = omap_i2c_wait_for_bb(dev); > if (r < 0) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 4/8] ARM: OMAP3: add manual control for mpu / core pwrdm usecounting
Kevin Hilman writes: > Tero Kristo writes: > >> mpu / core powerdomain usecounts are now statically increased >> by 1 during MPU activity. This allows the domains to reflect >> actual usage, and will allow the usecount to reach 0 just before >> all CPUs are ready to idle. Proper powerdomain usecounts are >> propageted to voltagedomain level also, and will allow vc >> callbacks to be triggered at right point of time. >> >> Signed-off-by: Tero Kristo >> Cc: Paul Walmsley >> Cc: Kevin Hilman > > IMO, the idea is fine, but I'm not crazy about the implementation in > powerdomain.c, which is meant for pwrdm generic code. In particular, > I'm not crazy about the pwrdm lookups in powerdomain.c. > > Since pm.c already has references to mpu_pwrdm and core_pwrdm, why > not just add the pwrdm_clkdm_enable/disable calls directly in pm.c > > Also, the changelog should be a bit more specific about why CORE > powerdomain is also handled here when most of the code only talks about > the CPU. After playing with this some more, and doing a test hack of my idea above, along with the per-pwrdm pre/post changes now in mainline, I thinks this series should go one step further. Basically, we should be able to get rid of the calls to prdm_pre|post_transition that are outside the powerdomain code. With the addition of pwrdm_clkdm_enable|disable, it seems that the pre|post transition calls should be called directly from pwrdm_clkdm_enable|disable when the usecount transitions to/from zero. Kevin -- 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: [PATCHv4 2/8] ARM: OMAP3+: voltage/pwrdm/clkdm/clock add recursive usecount tracking
Tero Kristo writes: > This patch fixes the usecount tracking for omap3+, previously the > usecount numbers were rather bogus and were not really useful for > any purpose. Now usecount numbers track the number of really active > clients on each domain. This patch also adds support for usecount > tracking on powerdomain level and autoidle flag for clocks that > are hardware controlled and should be skipped in usecount > calculations. > > Signed-off-by: Tero Kristo > Cc: Paul Walmsley > Cc: Kevin Hilman [...] > /* Clock control for DPLL outputs */ > diff --git a/arch/arm/mach-omap2/powerdomain.c > b/arch/arm/mach-omap2/powerdomain.c > index 9611490..68bdf36 100644 > --- a/arch/arm/mach-omap2/powerdomain.c > +++ b/arch/arm/mach-omap2/powerdomain.c > @@ -981,6 +981,41 @@ int pwrdm_state_switch(struct powerdomain *pwrdm) > return ret; > } > > +/** > + * pwrdm_clkdm_enable - increment powerdomain usecount > + * @pwrdm: struct powerdomain * > + * > + * Increases the usecount for a powerdomain. Called from clockdomain > + * code once a clockdomain's usecount reaches zero, i.e. it is ready > + * to idle. > + */ I think the comment here is wrong. > +void pwrdm_clkdm_enable(struct powerdomain *pwrdm) > +{ > + if (!pwrdm) > + return; > + > + atomic_inc(&pwrdm->usecount); > +} > + > +/** > + * pwrdm_clkdm_disable - decrease powerdomain usecount > + * @pwrdm: struct powerdomain * > + * > + * Decreases the usecount for a powerdomain. Called from clockdomain > + * code once a clockdomain becomes active. > + */ Looks like these two comments need to be swapped? > +void pwrdm_clkdm_disable(struct powerdomain *pwrdm) > +{ > + int val; > + > + if (!pwrdm) > + return; > + > + val = atomic_dec_return(&pwrdm->usecount); > + > + BUG_ON(val < 0); > +} > + Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v3.6-rc1 DSS issues/regression
Hi, On Mon, Aug 06, 2012 at 11:06:28PM +0530, Archit Taneja wrote: > >On Mon, 2012-08-06 at 19:47 +0300, Aaro Koskinen wrote: > >>I can't get the display on N900 (SDI, acx565akm) to work with v3.6-rc1 > >>kernel, it's just full of flicker/noise. > >> > >>According to git-bisect, the problem is introduced by the commit: > >> > >> commit f476ae9dab3234532d41d36beb4ba7be838fa786 > >> Author: Archit Taneja > >> Date: Fri Jun 29 14:37:03 2012 +0530 > >> > >> OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in > >> interface [...] > The diff I have shared introduces the register writes back. This > should make it work like before. But we need to figure out which > parameter write needs to be done immediately. If this works, could > you remove each dispc register write turn by turn, and point out > which is the culprit one? Thanks, the following one makes the display to work again: diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c index 5d31699..3c9f598 100644 --- a/drivers/video/omap2/dss/sdi.c +++ b/drivers/video/omap2/dss/sdi.c @@ -46,6 +46,9 @@ static void sdi_config_lcd_manager(struct omap_dss_device *dssdev) sdi.mgr_config.video_port_width = 24; sdi.mgr_config.lcden_sig_polarity = 1; + dispc_mgr_set_clock_div(dssdev->manager->id, + &sdi.mgr_config.clock_info); + dss_mgr_set_lcd_config(dssdev->manager, &sdi.mgr_config); } A. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS and USBHOST powerdomains not entering low-power states on 37xx EVM
Hi Paul, Paul Walmsley writes: > On v3.6-rc1 on 37xx EVM, DSS and USBHOST powerdomains aren't entering > low-power states. Test log is below. Is this only happening on this 37xx platform?Just curious, because it seems to be a problem on any OMAP3xxx SoC. [...] > # echo mem > /sys/power/state > [ 35.068359] PM: Syncing filesystems ... done. > [ 35.083038] Freezing user space processes ... (elapsed 0.00 seconds) > done. > [ 35.090698] Freezing remaining freezable tasks ... (elapsed 0.02 > seconds) done. > [ 35.122833] Suspending console(s) (use no_console_suspend to debug) > [ 35.144409] PM: suspend of devices complete after 11.260 msecs > [ 35.147369] PM: late suspend of devices complete after 2.929 msecs > [ 35.152465] PM: noirq suspend of devices complete after 5.096 msecs > [ 35.152526] Disabling non-boot CPUs ... > [ 36.958343] Successfully put all powerdomains to target state According to the readback of prev pwrst, it seems they are hitting the target pwrst (retention by default), so... > [ 36.960662] PM: noirq resume of devices complete after 2.166 msecs > [ 36.964050] PM: early resume of devices complete after 1.892 msecs > [ 36.973388] PM: resume of devices complete after 9.185 msecs > [ 37.025207] Restarting tasks ... done. > # cat /debug/pm_debug/count > usbhost_pwrdm > (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 > sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 > core_pwrdm > (ON),OFF:0,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 > per_pwrdm (ON),OFF:0,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 > dss_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 > cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 > neon_pwrdm (ON),OFF:0,RET:673,INA:0,ON:674,RET-LOGIC-OFF:0 > mpu_pwrdm (ON),OFF:0,RET:673,INA:0,ON:674,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 > iva2_pwrdm > (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-ME > MBANK4-OFF:0 > usbhost_clkdm->usbhost_pwrdm (1) > sgx_clkdm->sgx_pwrdm (0) > per_clkdm->per_pwrdm (22) > cam_clkdm->cam_pwrdm (0) > dss_clkdm->dss_pwrdm (1) > d2d_clkdm->core_pwrdm (0) > iva2_clkdm->iva2_pwrdm (0) > mpu_clkdm->mpu_pwrdm (0) > core_l4_clkdm->core_pwrdm (24) > core_l3_clkdm->core_pwrdm (4) > neon_clkdm->neon_pwrdm (0) ...it must be the usecounts that are not being updated. This seems to be a side effect of the pre/post transition optimization I did. A quick hack seems to indicate that that's indeed the case[1]. By default, omap_sram_idle() is now only calling the pre/post callbacks for MPU, NEON, PER, and CORE, and only if those domains are transitioning, so any other domains not explicitly managed by the idle path have lots their usecounting. Oops. I guess Tero's usecounting series should fix this up. Kevin [1] diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index e4fc88c..d87416f 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -70,6 +70,7 @@ void (*omap3_do_wfi_sram)(void); static struct powerdomain *mpu_pwrdm, *neon_pwrdm; static struct powerdomain *core_pwrdm, *per_pwrdm; +static struct powerdomain *dss_pwrdm, *usbhost_pwrdm; static void omap3_core_save_context(void) { @@ -393,7 +394,11 @@ static int omap3_pm_suspend(void) omap3_intc_suspend(); + pwrdm_pre_transition(dss_pwrdm); + pwrdm_pre_transition(usbhost_pwrdm); omap_sram_idle(); + pwrdm_post_transition(usbhost_pwrdm); + pwrdm_post_transition(dss_pwrdm); restore: /* Restore next_pwrsts */ @@ -718,6 +723,8 @@ int __init omap3_pm_init(void) neon_pwrdm = pwrdm_lookup("neon_pwrdm"); per_pwrdm = pwrdm_lookup("per_pwrdm"); core_pwrdm = pwrdm_lookup("core_pwrdm"); + dss_pwrdm = pwrdm_lookup("dss_pwrdm"); + usbhost_pwrdm = pwrdm_lookup("usbhost_pwrdm"); neon_clkdm = clkdm_lookup("neon_clkdm"); mpu_clkdm = clkdm_lookup("mpu_clkdm"); -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v3.6-rc1 DSS issues/regression
Hi, On Mon, Aug 06, 2012 at 08:24:28PM +0300, Tomi Valkeinen wrote: > On Mon, 2012-08-06 at 19:47 +0300, Aaro Koskinen wrote: > > Hi, > > > > I can't get the display on N900 (SDI, acx565akm) to work with v3.6-rc1 > > kernel, it's just full of flicker/noise. > > > > According to git-bisect, the problem is introduced by the commit: > > > > commit f476ae9dab3234532d41d36beb4ba7be838fa786 > > Author: Archit Taneja > > Date: Fri Jun 29 14:37:03 2012 +0530 > > > > OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in > > interface > > > > Any ideas? > > Looks strange, that particular commit more or less just moves the > writing of the configs to another place. And it works for DPI and DSI, > at least. > > Can you take a dump of debugfs/omapdss/dss and debugfs/omapdss/dispc, > for both working and non-working versions, to see if there's a diff? Here's a diff: --- dss-n900-ok 2012-08-06 23:54:07.0 +0300 +++ dss-n900-broken 2012-08-06 23:51:08.0 +0300 @@ -1,150 +1,150 @@ # cat clk - DSS - dpll4_ck 43200 DSS_FCK (DSS1_ALWON_FCLK) = 43200 / 12 * 2 = 7200 - DISPC - dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK) fck7200 - LCD - LCD clk source = DSS_FCK (DSS1_ALWON_FCLK) lck7200lck div 1 pck2400pck div 3 # cat dispc DISPC_REVISION 0030 DISPC_SYSCONFIG2015 DISPC_SYSSTATUS0001 DISPC_IRQSTATUS000100a2 DISPC_IRQENABLEd640 DISPC_CONTROL 38018309 DISPC_CONFIG 4204 DISPC_CAPABLE 03ff -DISPC_LINE_STATUS 0036 +DISPC_LINE_STATUS 00bf DISPC_LINE_NUMBER DISPC_GLOBAL_ALPHA 00ff DISPC_DEFAULT_COLOR(LCD) DISPC_TRANS_COLOR(LCD) DISPC_SIZE_MGR(LCD)01df031f DISPC_DEFAULT_COLOR(LCD) DISPC_TRANS_COLOR(LCD) DISPC_TIMING_H(LCD)01701b03 DISPC_TIMING_V(LCD)00400302 DISPC_POL_FREQ(LCD)00033000 DISPC_DIVISORo(LCD)00010003 DISPC_SIZE_MGR(LCD)01df031f DISPC_DATA_CYCLE1(LCD) DISPC_DATA_CYCLE2(LCD) DISPC_DATA_CYCLE3(LCD) DISPC_CPR_COEF_R(LCD) DISPC_CPR_COEF_G(LCD) DISPC_CPR_COEF_B(LCD) DISPC_DEFAULT_COLOR(TV) DISPC_TRANS_COLOR(TV) DISPC_SIZE_MGR(TV) DISPC_OVL_BA0(GFX) 8f00 DISPC_OVL_BA1(GFX) 8f00 DISPC_OVL_POSITION(GFX) DISPC_OVL_SIZE(GFX)01df031f DISPC_OVL_ATTRIBUTES(GFX) 00ad DISPC_OVL_FIFO_THRESHOLD(GFX) 0bff03c0 DISPC_OVL_FIFO_SIZE_STATUS(GFX)0400 DISPC_OVL_ROW_INC(GFX) 0001 DISPC_OVL_PIXEL_INC(GFX) 0001 DISPC_OVL_PRELOAD(GFX) 0100 DISPC_OVL_WINDOW_SKIP(GFX) DISPC_OVL_TABLE_BA(GFX) DISPC_OVL_BA0(VID1) DISPC_OVL_BA1(VID1) DISPC_OVL_POSITION(VID1) DISPC_OVL_SIZE(VID1) DISPC_OVL_ATTRIBUTES(VID1) 8000 DISPC_OVL_FIFO_THRESHOLD(VID1) DISPC_OVL_FIFO_SIZE_STATUS(VID1) 0400 DISPC_OVL_ROW_INC(VID1)0001 DISPC_OVL_PIXEL_INC(VID1) 0001 DISPC_OVL_PRELOAD(VID1)0100 DISPC_OVL_FIR(VID1) DISPC_OVL_PICTURE_SIZE(VID1) DISPC_OVL_ACCU0(VID1) DISPC_OVL_ACCU1(VID1) DISPC_OVL_PRELOAD(VID1)0100 DISPC_OVL_BA0(VID2) DISPC_OVL_BA1(VID2)
Re: [PATCH] Revert "ARM: OMAP3530evm: set pendown_state and debounce time for ads7846"
Igor Grinberg writes: > 1) The above commit introduced a common ->get_pendown_state() function > into the generic code, but that function was board-specific for the > OMAP3EVM and thus broke most other boards using this code. > > 2) The above commit was mis-merged introducing another bug which > prevents the ads7846 driver probe function to succeed. > The omap_ads7846_init() function frees the pendown GPIO in case there is > no ->get_pendown_state() function set by the caller (board specific > code), so it can be requested later by the ads7846 driver. > The above commit add a common ->get_pendown_state() function without > removing the gpio_free() call and thus once the ads7846 driver tries > to use the pendown GPIO, it crashes as the pendown GPIO has not been > requested. > > 3) The above commit introduces NO new functionality as > get_pendown_state() function is already implemented in a suitable way by > the ads7846 driver and the debounce time handling has already been > fixed by commit 97ee9f01 (ARM: OMAP: fix the ads7846 init code). > > This reverts commit 16aced80f6739beb2a6ff7b6f96c83ba80d331e8. > > Conflicts: > arch/arm/mach-omap2/common-board-devices.c > > Solved by taking the working version prior to the above commit. > > Cc: Zumeng Chen > Cc: Arnd Bergmann > Signed-off-by: Igor Grinberg > --- > Kevin, sorry for the late reply. > How about the above commit message and the below patch? > > The patch applies cleanly to Tony's master branch (6 Aug 2012) > or Kevin's kevin-omap-pm/for_3.6/fixes/ads7846 > after resetting two top most commits. Now that v3.6-rc1 is out, it should probalby be applied on top of -rc1. I've taken care of that and tested as well. > This patch has been tested on both above branches on cm-t3730. > Any other board tested will be greately appreciated. > > Also, if after all said in the commit message, you still don't > want to revert the original patch, feel free to post your thoughts. After all the digging I did, I agree that the revert is the best solution. While it's a slightly different problem/bug, I think the gpio_free() in common-board-devices.c should still be unconditonal since the gpio_request() is now unconditional. That can be a separate patch though. Acked-by: Kevin Hilman Tested-by: Kevin Hilman Tested on 3430/n900, 3530/Overo, 3730/Overo STORM, 3730/BB-xM. The Overo boards were the ones that were crashing due to this bug since the pendown GPIO was the only one used in the bank. Tony, can you queue this up for v3.6-rc? I have a version in my for_3.6/fixes/ads7846-2 branch with the tags above applied, based on v3.6-rc1. Thanks Kevin > arch/arm/mach-omap2/board-omap3evm.c |1 + > arch/arm/mach-omap2/common-board-devices.c | 11 --- > arch/arm/mach-omap2/common-board-devices.h |1 - > 3 files changed, 1 insertions(+), 12 deletions(-) > > diff --git a/arch/arm/mach-omap2/board-omap3evm.c > b/arch/arm/mach-omap2/board-omap3evm.c > index ef230a0..0d362e9 100644 > --- a/arch/arm/mach-omap2/board-omap3evm.c > +++ b/arch/arm/mach-omap2/board-omap3evm.c > @@ -58,6 +58,7 @@ > #include "hsmmc.h" > #include "common-board-devices.h" > > +#define OMAP3_EVM_TS_GPIO175 > #define OMAP3_EVM_EHCI_VBUS 22 > #define OMAP3_EVM_EHCI_SELECT61 > > diff --git a/arch/arm/mach-omap2/common-board-devices.c > b/arch/arm/mach-omap2/common-board-devices.c > index 1473474..c187586 100644 > --- a/arch/arm/mach-omap2/common-board-devices.c > +++ b/arch/arm/mach-omap2/common-board-devices.c > @@ -35,16 +35,6 @@ static struct omap2_mcspi_device_config > ads7846_mcspi_config = { > .turbo_mode = 0, > }; > > -/* > - * ADS7846 driver maybe request a gpio according to the value > - * of pdata->get_pendown_state, but we have done this. So set > - * get_pendown_state to avoid twice gpio requesting. > - */ > -static int omap3_get_pendown_state(void) > -{ > - return !gpio_get_value(OMAP3_EVM_TS_GPIO); > -} > - > static struct ads7846_platform_data ads7846_config = { > .x_max = 0x0fff, > .y_max = 0x0fff, > @@ -55,7 +45,6 @@ static struct ads7846_platform_data ads7846_config = { > .debounce_rep = 1, > .gpio_pendown = -EINVAL, > .keep_vref_on = 1, > - .get_pendown_state = &omap3_get_pendown_state, > }; > > static struct spi_board_info ads7846_spi_board_info __initdata = { > diff --git a/arch/arm/mach-omap2/common-board-devices.h > b/arch/arm/mach-omap2/common-board-devices.h > index 4c4ef6a..a0b4a428 100644 > --- a/arch/arm/mach-omap2/common-board-devices.h > +++ b/arch/arm/mach-omap2/common-board-devices.h > @@ -4,7 +4,6 @@ > #include "twl-common.h" > > #define NAND_BLOCK_SIZE SZ_128K > -#define OMAP3_EVM_TS_GPIO175 > > struct mtd_partition; > struct ads7846_platform_data; -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org
[PATCH] Revert "ARM: OMAP3530evm: set pendown_state and debounce time for ads7846"
1) The above commit introduced a common ->get_pendown_state() function into the generic code, but that function was board-specific for the OMAP3EVM and thus broke most other boards using this code. 2) The above commit was mis-merged introducing another bug which prevents the ads7846 driver probe function to succeed. The omap_ads7846_init() function frees the pendown GPIO in case there is no ->get_pendown_state() function set by the caller (board specific code), so it can be requested later by the ads7846 driver. The above commit add a common ->get_pendown_state() function without removing the gpio_free() call and thus once the ads7846 driver tries to use the pendown GPIO, it crashes as the pendown GPIO has not been requested. 3) The above commit introduces NO new functionality as get_pendown_state() function is already implemented in a suitable way by the ads7846 driver and the debounce time handling has already been fixed by commit 97ee9f01 (ARM: OMAP: fix the ads7846 init code). This reverts commit 16aced80f6739beb2a6ff7b6f96c83ba80d331e8. Conflicts: arch/arm/mach-omap2/common-board-devices.c Solved by taking the working version prior to the above commit. Cc: Zumeng Chen Cc: Arnd Bergmann Signed-off-by: Igor Grinberg --- Kevin, sorry for the late reply. How about the above commit message and the below patch? The patch applies cleanly to Tony's master branch (6 Aug 2012) or Kevin's kevin-omap-pm/for_3.6/fixes/ads7846 after resetting two top most commits. This patch has been tested on both above branches on cm-t3730. Any other board tested will be greately appreciated. Also, if after all said in the commit message, you still don't want to revert the original patch, feel free to post your thoughts. arch/arm/mach-omap2/board-omap3evm.c |1 + arch/arm/mach-omap2/common-board-devices.c | 11 --- arch/arm/mach-omap2/common-board-devices.h |1 - 3 files changed, 1 insertions(+), 12 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c index ef230a0..0d362e9 100644 --- a/arch/arm/mach-omap2/board-omap3evm.c +++ b/arch/arm/mach-omap2/board-omap3evm.c @@ -58,6 +58,7 @@ #include "hsmmc.h" #include "common-board-devices.h" +#define OMAP3_EVM_TS_GPIO 175 #define OMAP3_EVM_EHCI_VBUS22 #define OMAP3_EVM_EHCI_SELECT 61 diff --git a/arch/arm/mach-omap2/common-board-devices.c b/arch/arm/mach-omap2/common-board-devices.c index 1473474..c187586 100644 --- a/arch/arm/mach-omap2/common-board-devices.c +++ b/arch/arm/mach-omap2/common-board-devices.c @@ -35,16 +35,6 @@ static struct omap2_mcspi_device_config ads7846_mcspi_config = { .turbo_mode = 0, }; -/* - * ADS7846 driver maybe request a gpio according to the value - * of pdata->get_pendown_state, but we have done this. So set - * get_pendown_state to avoid twice gpio requesting. - */ -static int omap3_get_pendown_state(void) -{ - return !gpio_get_value(OMAP3_EVM_TS_GPIO); -} - static struct ads7846_platform_data ads7846_config = { .x_max = 0x0fff, .y_max = 0x0fff, @@ -55,7 +45,6 @@ static struct ads7846_platform_data ads7846_config = { .debounce_rep = 1, .gpio_pendown = -EINVAL, .keep_vref_on = 1, - .get_pendown_state = &omap3_get_pendown_state, }; static struct spi_board_info ads7846_spi_board_info __initdata = { diff --git a/arch/arm/mach-omap2/common-board-devices.h b/arch/arm/mach-omap2/common-board-devices.h index 4c4ef6a..a0b4a428 100644 --- a/arch/arm/mach-omap2/common-board-devices.h +++ b/arch/arm/mach-omap2/common-board-devices.h @@ -4,7 +4,6 @@ #include "twl-common.h" #define NAND_BLOCK_SIZESZ_128K -#define OMAP3_EVM_TS_GPIO 175 struct mtd_partition; struct ads7846_platform_data; -- 1.7.3.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3: USB: EHCI broken on 3.5?
Hi Joe, "Joe Woodward" writes: > I have a GUMSTIX Overo AirSTORM (AM3703-based). > > When running a 3.4 kernel the USB host works just fine! > > However when switching to 3.5 I get a few new warning messages and USB host > no longer works. As usual, thanks for the bug/problem reports. EHCI is broken in many ways in v3.5. Since the maintainers were not fixing the problems (specifically the PM problems which broke PM for the rest of the SoC too), I requested it be disabled by default in omap2plus_defconfig. Kesheva sent out a large revert patch, and Russ Dill sent out an alternative set of 2 patches that were more targetted fixes, but I lost track of the final resolution there (if any.) Kevin > dmesg log after successfully loading the module (modprobe echi-hcd) on 3.4: > [ 23.424499] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > [ 23.431427] ehci_hcd: block sizes: qh 64 qtd 96 itd 160 sitd 96 > [ 23.431732] ehci-omap ehci-omap.0: failed to get ehci port1 regulator > [ 23.431762] gpio_request: gpio-183 (USB2 PHY reset) status -16 > [ 24.433471] ehci-omap ehci-omap.0: phy reset operation timed out > [ 24.433502] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0 cc=1 > pcc=3 ordered ports=3 > [ 24.433532] ehci-omap ehci-omap.0: reset hcc_params 0016 thresh 1 uframes > 256/512/1024 park > [ 24.433532] ehci-omap ehci-omap.0: reset command 0080b02 park=3 ithresh=8 > period=1024 Reset HALT > [ 24.433563] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller > [ 24.440063] ehci-omap ehci-omap.0: new USB bus registered, assigned bus > number 1 > [ 24.448120] ehci-omap ehci-omap.0: park 0 > [ 24.448181] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800 > [ 24.454162] ehci-omap ehci-omap.0: init command 0010005 (park)=0 ithresh=1 > period=512 RUN > [ 24.474517] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 > [ 24.481597] usb usb1: default language 0x0409 > [ 24.481658] usb usb1: udev 1, busnum 1, minor = 0 > [ 24.481689] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 > [ 24.488830] usb usb1: New USB device strings: Mfr=3, Product=2, > SerialNumber=1 > [ 24.496398] usb usb1: Product: OMAP-EHCI Host Controller > [ 24.501953] usb usb1: Manufacturer: Linux 3.4.0 ehci_hcd > [ 24.507537] usb usb1: SerialNumber: ehci-omap.0 > [ 24.528747] usb usb1: usb_probe_device > [ 24.528778] usb usb1: configuration #1 chosen from 1 choice > [ 24.529479] usb usb1: adding 1-0:1.0 (config #1, interface 0) > [ 24.530212] hub 1-0:1.0: usb_probe_interface > [ 24.530242] hub 1-0:1.0: usb_probe_interface - got id > [ 24.530303] hub 1-0:1.0: USB hub found > [ 24.534362] hub 1-0:1.0: 3 ports detected > [ 24.538635] hub 1-0:1.0: standalone hub > [ 24.538635] hub 1-0:1.0: individual port power switching > [ 24.538665] hub 1-0:1.0: individual port over-current protection > [ 24.538665] hub 1-0:1.0: power on to power good time: 20ms > [ 24.539031] hub 1-0:1.0: local power source is good > [ 24.539062] hub 1-0:1.0: enabling power on all ports > [ 24.540008] ehci-omap ehci-omap.0: ...powerup ports... > [ 24.637634] hub 1-0:1.0: state 7 ports 3 chg evt > [ 27.013153] hub 1-0:1.0: hub_suspend > [ 27.015319] usb usb1: bus auto-suspend, wakeup 1 > [ 27.015411] ehci-omap ehci-omap.0: suspend root hub > > > dmesg log after failing to load the module (modprobe echi-hcd) on 3.5: > [ 83.900115] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > [ 83.907043] ehci_hcd: block sizes: qh 64 qtd 96 itd 160 sitd 96 > [ 83.907379] ehci-omap ehci-omap.0: failed to get ehci port1 regulator > [ 84.912445] ehci-omap ehci-omap.0: phy reset operation timed out > [ 84.912475] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0 cc=1 > pcc=3 ordered ports=3 > [ 84.912475] ehci-omap ehci-omap.0: reset hcc_params 0016 thresh 1 uframes > 256/512/1024 park > [ 84.912506] ehci-omap ehci-omap.0: reset command 0080b02 park=3 ithresh=8 > period=1024 Reset HALT > [ 84.912506] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller > [ 84.919097] ehci-omap ehci-omap.0: new USB bus registered, assigned bus > number 1 > [ 84.927154] ehci-omap ehci-omap.0: park 0 > [ 84.927215] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800 > [ 84.933197] ehci-omap ehci-omap.0: init command 0010005 (park)=0 ithresh=1 > period=512 RUN > [ 84.946655] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 > [ 84.953796] usb usb1: default language 0x0409 > [ 84.953887] usb usb1: udev 1, busnum 1, minor = 0 > [ 84.953887] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 > [ 84.961059] usb usb1: New USB device strings: Mfr=3, Product=2, > SerialNumber=1 > [ 84.968627] usb usb1: Product: OMAP-EHCI Host Controller > [ 84.974151] usb usb1: Manufacturer: Linux 3.5.0 ehci_hcd > [ 84.979736] usb usb1: SerialNumber: ehci-omap.0 > [ 84.987518] usb usb1: usb_probe_device > [ 84.987548] usb usb1: configuration #1 chosen from 1
Re: v3.6-rc1 DSS issues/regression
Hi, On Monday 06 August 2012 10:54 PM, Tomi Valkeinen wrote: On Mon, 2012-08-06 at 19:47 +0300, Aaro Koskinen wrote: Hi, I can't get the display on N900 (SDI, acx565akm) to work with v3.6-rc1 kernel, it's just full of flicker/noise. According to git-bisect, the problem is introduced by the commit: commit f476ae9dab3234532d41d36beb4ba7be838fa786 Author: Archit Taneja Date: Fri Jun 29 14:37:03 2012 +0530 OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface Any ideas? Thanks for pointing this out. The commit delays the register writes to a later point. But these registers are shadowed, i.e, they shouldn't take impact till the time the overlay manager is enabled. It's possible that some fields of the registers in question may have a direct impact, and hence messing up some sequence with respect to sdi registers. The diff I have shared introduces the register writes back. This should make it work like before. But we need to figure out which parameter write needs to be done immediately. If this works, could you remove each dispc register write turn by turn, and point out which is the culprit one? Sorry about the manual process, but we don't have any way to test SDI here :) Thanks Archit diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c index 5d31699..d397e96 100644 --- a/drivers/video/omap2/dss/sdi.c +++ b/drivers/video/omap2/dss/sdi.c @@ -46,6 +46,22 @@ static void sdi_config_lcd_manager(struct omap_dss_device *dssdev) sdi.mgr_config.video_port_width = 24; sdi.mgr_config.lcden_sig_polarity = 1; + + dispc_mgr_set_io_pad_mode(sdi.mgr_config.io_pad_mode); + dispc_mgr_enable_stallmode(dssdev->manager->id, + sdi.mgr_config.stallmode); + dispc_mgr_enable_fifohandcheck(dssdev->manager->id, + sdi.mgr_config.fifohandcheck); + + dispc_mgr_set_clock_div(dssdev->manager->id, + &sdi.mgr_config.clock_info); + + dispc_mgr_set_tft_data_lines(dssdev->manager->id, + sdi.mgr_config.video_port_width); + dispc_lcd_enable_signal_polarity(sdi.mgr_config.lcden_sig_polarity); + + dispc_mgr_set_lcd_type_tft(dssdev->manager->id); + Looks strange, that particular commit more or less just moves the writing of the configs to another place. And it works for DPI and DSI, at least. Can you take a dump of debugfs/omapdss/dss and debugfs/omapdss/dispc, for both working and non-working versions, to see if there's a diff? 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: v3.6-rc1 DSS issues/regression
On Mon, 2012-08-06 at 19:47 +0300, Aaro Koskinen wrote: > Hi, > > I can't get the display on N900 (SDI, acx565akm) to work with v3.6-rc1 > kernel, it's just full of flicker/noise. > > According to git-bisect, the problem is introduced by the commit: > > commit f476ae9dab3234532d41d36beb4ba7be838fa786 > Author: Archit Taneja > Date: Fri Jun 29 14:37:03 2012 +0530 > > OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in > interface > > Any ideas? Looks strange, that particular commit more or less just moves the writing of the configs to another place. And it works for DPI and DSI, at least. Can you take a dump of debugfs/omapdss/dss and debugfs/omapdss/dispc, for both working and non-working versions, to see if there's a diff? Tomi signature.asc Description: This is a digitally signed message part
v3.6-rc1 DSS issues/regression
Hi, I can't get the display on N900 (SDI, acx565akm) to work with v3.6-rc1 kernel, it's just full of flicker/noise. According to git-bisect, the problem is introduced by the commit: commit f476ae9dab3234532d41d36beb4ba7be838fa786 Author: Archit Taneja Date: Fri Jun 29 14:37:03 2012 +0530 OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface Any ideas? Thanks, A. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] driver: misc: bmp085: remove "of_match_table" property.
On Mon, Aug 06, 2012 at 12:30:34PM +0300, Felipe Balbi wrote: > On Mon, Aug 06, 2012 at 02:58:44PM +0530, Sourav Poddar wrote: > > There is an automatic binding done for I2C devices in the of_i2c core > > code. So, DT will be able to bind to any I2C device using the > > already existing table: MODULE_DEVICE_TABLE(i2c, bmp085_id). > Acked-by: Felipe Balbi It's good practice to have an explict compatible string even if the default happens to work in order to avoid any name clashes. -- 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 0/2] Add device tree support for davinci_mdio driver and fix cpsw DT binding documentation
This patch set adds support for device tree for Davinci MDIO driver and fixes CPSW DT binding documentation to make it copy pastable to dts file. This patch set is tested with the following git tree on AM335X Beagle Bone https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging-cpsw Mugunthan V N (2): drivers: net: ethernet: davince_mdio: device tree implementation documentation: dt: bindings: cpsw: fixing the examples for directly using it in dts file Documentation/devicetree/bindings/net/cpsw.txt | 101 ++- .../devicetree/bindings/net/davinci-mdio.txt | 33 +++ drivers/net/ethernet/ti/davinci_mdio.c | 41 +++- 3 files changed, 123 insertions(+), 52 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/davinci-mdio.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] documentation: dt: bindings: cpsw: fixing the examples for directly using it in dts file
Fixing the cpsw device tree example to make it simpler to copy pastable to dts file and use it directly. Signed-off-by: Mugunthan V N --- Documentation/devicetree/bindings/net/cpsw.txt | 101 --- 1 files changed, 53 insertions(+), 48 deletions(-) diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt index acca48c..dcaabe9 100644 --- a/Documentation/devicetree/bindings/net/cpsw.txt +++ b/Documentation/devicetree/bindings/net/cpsw.txt @@ -11,6 +11,7 @@ Required properties: - cpdma_channels : Specifies number of channels in CPDMA - host_port_no : Specifies host port shift - cpdma_reg_ofs: Specifies CPDMA submodule register offset +- cpdma_sram_ofs : Specifies CPDMA SRAM offset - ale_reg_ofs : Specifies ALE submodule register offset - ale_entries : Specifies No of entries ALE can hold - host_port_reg_ofs: Specifies host port register offset @@ -43,62 +44,66 @@ Examples: reg = <0x4A10 0x1000>; interrupts = <55 0x4>; interrupt-parent = <&intc>; - cpdma_channels = 8; - host_port_no = 0; - cpdma_reg_ofs = 0x800; - ale_reg_ofs = 0xd00; - ale_entries = 1024; - host_port_reg_ofs = 0x108; - hw_stats_reg_ofs = 0x900; - bd_ram_ofs = 0x2000; - bd_ram_size = 0x2000; - no_bd_ram = 0; - rx_descs = 64; - mac_control = 0x20; - slaves = 2; - slave@0 { - slave_reg_ofs = 0x208; - sliver_reg_ofs = 0xd80; - phy_id = "davinci_mdio-0:00" - mac-address = [00 04 9F 01 1B B8]; + cpdma_channels = <8>; + host_port_no = <0>; + cpdma_reg_ofs = <0x800>; + cpdma_sram_ofs = <0xa00>; + ale_reg_ofs = <0xd00>; + ale_entries = <1024>; + host_port_reg_ofs = <0x108>; + hw_stats_reg_ofs = <0x900>; + bd_ram_ofs = <0x2000>; + bd_ram_size = <0x2000>; + no_bd_ram = <0>; + rx_descs = <64>; + mac_control = <0x20>; + slaves = <2>; + cpsw_emac0: slave@0 { + slave_reg_ofs = <0x208>; + sliver_reg_ofs = <0xd80>; + phy_id = "davinci_mdio.16:00"; + /* Filled in by U-Boot */ + mac-address = [ 00 00 00 00 00 00 ]; }; - slave@1 { - slave_reg_ofs = 0x208; - sliver_reg_ofs = 0xd80; - phy_id = "davinci_mdio-0:01" - mac-address = [00 04 9F 01 1B B9]; + cpsw_emac1: slave@1 { + slave_reg_ofs = <0x308>; + sliver_reg_ofs = <0xdc0>; + phy_id = "davinci_mdio.16:01"; + /* Filled in by U-Boot */ + mac-address = [ 00 00 00 00 00 00 ]; }; }; (or) - mac: ethernet@4A10 { compatible = "ti,cpsw"; ti,hwmods = "cpgmac0"; - cpdma_channels = 8; - host_port_no = 0; - cpdma_reg_ofs = 0x800; - ale_reg_ofs = 0xd00; - ale_entries = 1024; - host_port_reg_ofs = 0x108; - hw_stats_reg_ofs = 0x900; - bd_ram_ofs = 0x2000; - bd_ram_size = 0x2000; - no_bd_ram = 0; - rx_descs = 64; - mac_control = 0x20; - slaves = 2; - slave@0 { - slave_reg_ofs = 0x208; - sliver_reg_ofs = 0xd80; - phy_id = "davinci_mdio-0:00" - mac-address = [00 04 9F 01 1B B8]; + cpdma_channels = <8>; + host_port_no = <0>; + cpdma_reg_ofs = <0x800>; + cpdma_sram_ofs = <0xa00>; + ale_reg_ofs = <0xd00>; + ale_entries = <1024>; + host_port_reg_ofs = <0x108>; + hw_stats_reg_ofs = <0x900>; + bd_ram_ofs = <0x2000>; + bd_ram_size = <0x2000>; + no_bd_ram = <0>; + rx_descs = <64>; + mac_control = <0x20>; + slaves = <2>; + cpsw_emac0: slave@0 { + slave_reg_ofs = <0x208>; + sliver_reg_ofs = <0xd80>; + phy_id = "davinci_mdio.16:00"; + /* Filled in by U-Boot */ + mac-address = [ 00 00 00 00 00 00 ]; }; - slave@1 { -
[PATCH 1/2] drivers: net: ethernet: davince_mdio: device tree implementation
device tree implementation for davinci mdio driver Signed-off-by: Mugunthan V N --- .../devicetree/bindings/net/davinci-mdio.txt | 33 drivers/net/ethernet/ti/davinci_mdio.c | 41 ++-- 2 files changed, 70 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/davinci-mdio.txt diff --git a/Documentation/devicetree/bindings/net/davinci-mdio.txt b/Documentation/devicetree/bindings/net/davinci-mdio.txt new file mode 100644 index 000..72efaaf --- /dev/null +++ b/Documentation/devicetree/bindings/net/davinci-mdio.txt @@ -0,0 +1,33 @@ +TI SoC Davinci MDIO Controller Device Tree Bindings +--- + +Required properties: +- compatible : Should be "ti,davinci_mdio" +- reg : physical base address and size of the davinci mdio + registers map +- bus_freq : Mdio Bus frequency + +Optional properties: +- ti,hwmods: Must be "davinci_mdio" + +Note: "ti,hwmods" field is used to fetch the base address and irq +resources from TI, omap hwmod data base during device registration. +Future plan is to migrate hwmod data base contents into device tree +blob so that, all the required data will be used from device tree dts +file. + +Examples: + + mdio: davinci_mdio@4A101000 { + compatible = "ti,cpsw"; + reg = <0x4A101000 0x1000>; + bus_freq = <100>; + }; + +(or) + + mdio: davinci_mdio@4A101000 { + compatible = "ti,cpsw"; + ti,hwmods = "davinci_mdio"; + bus_freq = <100>; + }; diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c index cd7ee20..573f3be 100644 --- a/drivers/net/ethernet/ti/davinci_mdio.c +++ b/drivers/net/ethernet/ti/davinci_mdio.c @@ -36,6 +36,8 @@ #include #include #include +#include +#include /* * This timeout definition is a worst-case ultra defensive measure against @@ -289,6 +291,25 @@ static int davinci_mdio_write(struct mii_bus *bus, int phy_id, return 0; } +static int davinci_mdio_probe_dt(struct mdio_platform_data *data, +struct platform_device *pdev) +{ + struct device_node *node = pdev->dev.of_node; + u32 prop; + + if (!node) + return -EINVAL; + + if (of_property_read_u32(node, "bus_freq", &prop)) { + pr_err("Missing bus_freq property in the DT.\n"); + return -EINVAL; + } + data->bus_freq = prop; + + return 0; +} + + static int __devinit davinci_mdio_probe(struct platform_device *pdev) { struct mdio_platform_data *pdata = pdev->dev.platform_data; @@ -304,8 +325,6 @@ static int __devinit davinci_mdio_probe(struct platform_device *pdev) return -ENOMEM; } - data->pdata = pdata ? (*pdata) : default_pdata; - data->bus = mdiobus_alloc(); if (!data->bus) { dev_err(dev, "failed to alloc mii bus\n"); @@ -313,14 +332,22 @@ static int __devinit davinci_mdio_probe(struct platform_device *pdev) goto bail_out; } + if (dev->of_node) { + if (davinci_mdio_probe_dt(&data->pdata, pdev)) + data->pdata = default_pdata; + snprintf(data->bus->id, MII_BUS_ID_SIZE, "%s", pdev->name); + } else { + data->pdata = pdata ? (*pdata) : default_pdata; + snprintf(data->bus->id, MII_BUS_ID_SIZE, "%s-%x", +pdev->name, pdev->id); + } + data->bus->name = dev_name(dev); data->bus->read = davinci_mdio_read, data->bus->write= davinci_mdio_write, data->bus->reset= davinci_mdio_reset, data->bus->parent = dev; data->bus->priv = data; - snprintf(data->bus->id, MII_BUS_ID_SIZE, "%s-%x", - pdev->name, pdev->id); pm_runtime_enable(&pdev->dev); pm_runtime_get_sync(&pdev->dev); @@ -454,11 +481,17 @@ static const struct dev_pm_ops davinci_mdio_pm_ops = { .resume = davinci_mdio_resume, }; +static const struct of_device_id davinci_mdio_of_mtable[] = { + { .compatible = "ti,davinci_mdio", }, + { /* sentinel */ }, +}; + static struct platform_driver davinci_mdio_driver = { .driver = { .name= "davinci_mdio", .owner = THIS_MODULE, .pm = &davinci_mdio_pm_ops, + .of_match_table = of_match_ptr(davinci_mdio_of_mtable), }, .probe = davinci_mdio_probe, .remove = __devexit_p(davinci_mdio_remove), -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.
[PATCH 4/4] i2c: omap: switch over to autosuspend API
this helps us reduce unnecessary pm transitions in case we have another i2c message been started soon. Signed-off-by: Felipe Balbi --- drivers/i2c/busses/i2c-omap.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 60928f2..22efaba 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -645,7 +645,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) omap_i2c_wait_for_bb(dev); out: - pm_runtime_put(dev->dev); + pm_runtime_mark_last_busy(dev->dev); + pm_runtime_put_autosuspend(dev->dev); return r; } @@ -1113,6 +1114,9 @@ omap_i2c_probe(struct platform_device *pdev) dev->regs = (u8 *)reg_map_ip_v1; pm_runtime_enable(dev->dev); + pm_runtime_set_autosuspend_delay(dev->dev, 1000); + pm_runtime_use_autosuspend(dev->dev); + r = pm_runtime_get_sync(dev->dev); if (IS_ERR_VALUE(r)) goto err_free_mem; @@ -1189,7 +1193,7 @@ omap_i2c_probe(struct platform_device *pdev) of_i2c_register_devices(adap); - pm_runtime_put(dev->dev); + pm_runtime_put_autosuspend(dev->dev); return 0; -- 1.7.12.rc0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] i2c: omap: switch to threaded IRQ support
for OMAP2, we can easily switch over to threaded IRQs on the I2C driver. This will allow us to spend less time in hardirq context. Signed-off-by: Felipe Balbi --- drivers/i2c/busses/i2c-omap.c | 42 -- 1 file changed, 36 insertions(+), 6 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index f5eafb7..a3db053 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -176,6 +176,7 @@ enum { #define I2C_OMAP_ERRATA_I462 (1 << 1) struct omap_i2c_dev { + spinlock_t lock; /* IRQ synchronization */ struct device *dev; void __iomem*base; /* virtual */ int irq; @@ -854,9 +855,30 @@ static int omap_i2c_transmit_data(struct omap_i2c_dev *dev, u8 num_bytes, } static irqreturn_t -omap_i2c_isr(int this_irq, void *dev_id) +omap_i2c_isr(int irq, void *dev_id) { struct omap_i2c_dev *dev = dev_id; + irqreturn_t ret = IRQ_HANDLED; + u16 mask; + u16 stat; + + spin_lock(&dev->lock); + mask = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG); + stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); + + if (stat & mask) + ret = IRQ_WAKE_THREAD; + + spin_unlock(&dev->lock); + + return ret; +} + +static irqreturn_t +omap_i2c_isr_thread(int this_irq, void *dev_id) +{ + struct omap_i2c_dev *dev = dev_id; + unsigned long flags; u16 bits; u16 stat; int err = 0, count = 0; @@ -864,6 +886,7 @@ omap_i2c_isr(int this_irq, void *dev_id) if (pm_runtime_suspended(dev->dev)) return IRQ_HANDLED; + spin_lock_irqsave(&dev->lock, flags); do { bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG); stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); @@ -877,6 +900,7 @@ omap_i2c_isr(int this_irq, void *dev_id) if (!stat) { /* my work here is done */ + spin_unlock_irqrestore(&dev->lock, flags); return IRQ_HANDLED; } @@ -985,6 +1009,8 @@ omap_i2c_isr(int this_irq, void *dev_id) out: omap_i2c_complete_cmd(dev, err); + spin_unlock_irqrestore(&dev->lock, flags); + return IRQ_HANDLED; } @@ -1028,7 +1054,6 @@ omap_i2c_probe(struct platform_device *pdev) struct omap_i2c_bus_platform_data *pdata = pdev->dev.platform_data; struct device_node *node = pdev->dev.of_node; const struct of_device_id *match; - irq_handler_t isr; int irq; int r; @@ -1078,6 +1103,8 @@ omap_i2c_probe(struct platform_device *pdev) dev->dev = &pdev->dev; dev->irq = irq; + spin_lock_init(&dev->lock); + platform_set_drvdata(pdev, dev); init_completion(&dev->cmd_complete); @@ -1130,10 +1157,13 @@ omap_i2c_probe(struct platform_device *pdev) /* reset ASAP, clearing any IRQs */ omap_i2c_init(dev); - isr = (dev->rev < OMAP_I2C_OMAP1_REV_2) ? omap_i2c_omap1_isr : - omap_i2c_isr; - r = devm_request_irq(&pdev->dev, dev->irq, isr, IRQF_NO_SUSPEND, -pdev->name, dev); + if (dev->rev < OMAP_I2C_OMAP1_REV_2) + r = devm_request_irq(&pdev->dev, dev->irq, omap_i2c_omap1_isr, + IRQF_NO_SUSPEND, pdev->name, dev); + else + r = devm_request_threaded_irq(&pdev->dev, dev->irq, omap_i2c_isr, + omap_i2c_isr_thread, IRQF_NO_SUSPEND | IRQF_ONESHOT, + pdev->name, dev); if (r) { dev_err(dev->dev, "failure requesting irq %i\n", dev->irq); -- 1.7.12.rc0 -- 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 3/4] i2c: omap: remove unnecessary pm_runtime_suspended check
before starting any messages we call pm_runtime_get_sync() which will make sure that by the time we program a transfer and our IRQ handler gets called, we're not suspended anymore. Signed-off-by: Felipe Balbi --- drivers/i2c/busses/i2c-omap.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index a3db053..60928f2 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -883,9 +883,6 @@ omap_i2c_isr_thread(int this_irq, void *dev_id) u16 stat; int err = 0, count = 0; - if (pm_runtime_suspended(dev->dev)) - return IRQ_HANDLED; - spin_lock_irqsave(&dev->lock, flags); do { bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG); -- 1.7.12.rc0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] i2c: omap: always return IRQ_HANDLED
even if our clocks are disabled, we still handled the IRQ, so we should return IRQ_HANDLED. Signed-off-by: Felipe Balbi --- drivers/i2c/busses/i2c-omap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 2dd2301..f5eafb7 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -862,7 +862,7 @@ omap_i2c_isr(int this_irq, void *dev_id) int err = 0, count = 0; if (pm_runtime_suspended(dev->dev)) - return IRQ_NONE; + return IRQ_HANDLED; do { bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG); -- 1.7.12.rc0 -- 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 0/4] i2c: omap: few more patches
Just a few extra patches on top of the earlier series I sent. With these patches, we have threaded irq support and autosuspend support for i2c-omap driver. All patches boot tested with pandaboard. Felipe Balbi (4): i2c: omap: always return IRQ_HANDLED i2c: omap: switch to threaded IRQ support i2c: omap: remove unnecessary pm_runtime_suspended check i2c: omap: switch over to autosuspend API drivers/i2c/busses/i2c-omap.c | 53 ++- 1 file changed, 42 insertions(+), 11 deletions(-) -- 1.7.12.rc0 -- 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 v4 2/2] arm/dts: omap4: Add ocp2scp data
Add ocp2scp data node in omap4 device tree file. Acked-by: Felipe Balbi Signed-off-by: Kishon Vijay Abraham I --- arch/arm/boot/dts/omap4.dtsi |8 1 file changed, 8 insertions(+) diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index 04cbbcb..8a780b2 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -295,5 +295,13 @@ interrupt-parent = <&gic>; ti,hwmods = "dmic"; }; + + ocp2scp { + compatible = "ti,omap-ocp2scp"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + ti,hwmods = "ocp2scp_usb_phy"; + }; }; }; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/2] omap: add ocp2scp as a bus driver
This patch series is done as a preparatory step for adding phy drivers for dwc3 and musb. This series adds a new driver for ocp2scp (only dt) to which phy drivers are connected. Since currently there is no generic way to create a child device along with doing a pm_runtime_enable (the exact requirement for ocp2scp), I'm creating a separate driver for ocp2scp. Changes from v3: No functional changes. Fixed few comments on filling *module* details. Changes from v2: Fixed Felipe's comments to avoid using arch_initcall and make dependent drivers return -EPROBE_DEFER case this isn't ready yet. Changes from v1: Fixed Sergei's comments to remove the address in the node name of ocp2scp since the ocp2scp node doesn't have a reg property. Changes from [RFC PATCH v2 0/2] omap: add ocp2scp as a misc driver: Created a new folder drivers/bus and moved ocp2scp driver from misc to drivers/bus. This patch was developed and tested on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git Kishon Vijay Abraham I (2): drivers: bus: add a new driver for omap-ocp2scp arm/dts: omap4: Add ocp2scp data .../devicetree/bindings/bus/omap-ocp2scp.txt | 10 +++ arch/arm/boot/dts/omap4.dtsi |8 ++ drivers/Kconfig|2 + drivers/Makefile |2 + drivers/bus/Kconfig| 15 drivers/bus/Makefile |5 ++ drivers/bus/omap-ocp2scp.c | 88 7 files changed, 130 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/omap-ocp2scp.txt create mode 100644 drivers/bus/Kconfig create mode 100644 drivers/bus/Makefile create mode 100644 drivers/bus/omap-ocp2scp.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] drivers: bus: add a new driver for omap-ocp2scp
Adds a new driver *omap-ocp2scp*. This driver takes the responsibility of creating all the devices that is connected to OCP2SCP. In the case of OMAP4, USB2PHY is connected to ocp2scp. This also includes device tree support for ocp2scp driver and the documentation with device tree binding information is updated. Acked-by: Felipe Balbi Acked-by: Arnd Bergmann Signed-off-by: Kishon Vijay Abraham I --- .../devicetree/bindings/bus/omap-ocp2scp.txt | 10 +++ drivers/Kconfig|2 + drivers/Makefile |2 + drivers/bus/Kconfig| 15 drivers/bus/Makefile |5 ++ drivers/bus/omap-ocp2scp.c | 88 6 files changed, 122 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/omap-ocp2scp.txt create mode 100644 drivers/bus/Kconfig create mode 100644 drivers/bus/Makefile create mode 100644 drivers/bus/omap-ocp2scp.c diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt new file mode 100644 index 000..d2fe064 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt @@ -0,0 +1,10 @@ +* OMAP OCP2SCP - ocp interface to scp interface + +properties: +- compatible : Should be "ti,omap-ocp2scp" +- #address-cells, #size-cells : Must be present if the device has sub-nodes +- ranges : the child address space are mapped 1:1 onto the parent address space +- ti,hwmods : must be "ocp2scp_usb_phy" + +Sub-nodes: +All the devices connected to ocp2scp are described using sub-node to ocp2scp diff --git a/drivers/Kconfig b/drivers/Kconfig index ece958d..324e958 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -2,6 +2,8 @@ menu "Device Drivers" source "drivers/base/Kconfig" +source "drivers/bus/Kconfig" + source "drivers/connector/Kconfig" source "drivers/mtd/Kconfig" diff --git a/drivers/Makefile b/drivers/Makefile index 5b42184..f8cdeeb 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -5,6 +5,8 @@ # Rewritten to use lists instead of if-statements. # +obj-y += bus/ + # GPIO must come after pinctrl as gpios may need to mux pins etc obj-y += pinctrl/ obj-y += gpio/ diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig new file mode 100644 index 000..6270415 --- /dev/null +++ b/drivers/bus/Kconfig @@ -0,0 +1,15 @@ +# +# Bus Devices +# + +menu "Bus devices" + +config OMAP_OCP2SCP + tristate "OMAP OCP2SCP DRIVER" + help + Driver to enable ocp2scp module which transforms ocp interface + protocol to scp protocol. In OMAP4, USB PHY is connected via + OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via + OCP2SCP. + +endmenu diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile new file mode 100644 index 000..0ec50bc --- /dev/null +++ b/drivers/bus/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for the bus drivers. +# + +obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c new file mode 100644 index 000..881d5bb --- /dev/null +++ b/drivers/bus/omap-ocp2scp.c @@ -0,0 +1,88 @@ +/* + * omap-ocp2scp.c - transform ocp interface protocol to scp protocol + * + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * Author: Kishon Vijay Abraham I + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#include +#include +#include +#include +#include +#include + +static int ocp2scp_remove_devices(struct device *dev, void *c) +{ + struct platform_device *pdev = to_platform_device(dev); + + platform_device_unregister(pdev); + + return 0; +} + +static int __devinit omap_ocp2scp_probe(struct platform_device *pdev) +{ + int ret; + struct device_node *np = pdev->dev.of_node; + + if (np) { + ret = of_platform_populate(np, NULL, NULL, &pdev->dev); + if (ret) { + dev_err(&pdev->dev, "failed to add resources for ocp2scp child\n"); + goto err0; + } + } + pm_runtime_enable(&pdev->dev); + + return 0; + +err0: + device_for_each_child(&pdev->dev, NULL, ocp2scp_remove_devices); + + return ret; +} + +static int __devexit omap_ocp2scp_remove(struct platform_device *pdev) +{
Re: [PATCH v3] printk: add option to print cpu id
On Fri, Aug 03, 2012 at 03:48:26PM -0700, Pandita, Vikram wrote: > On Fri, Aug 3, 2012 at 3:36 PM, Greg KH wrote: > > On Fri, Aug 03, 2012 at 03:25:17PM -0700, Pandita, Vikram wrote: > >> >> This was something that got used internally and helped at times. > >> > > >> > Could you have used the trace point instead? > >> > >> As i understood the trace_prink(), one would need to modify existing > >> printk -> trace_printk. Is my understanding correct? > > > > No, you should just be able to watch the tracepoint, right? > > yes. > Assumption being you know _EXACTLY_ what code piece to watch for. > Which may not be the case all times. But it traces all printks. # echo 1 > /sys/kernel/debug/tracing/events/printk/console/enable # mount /home/rostedt # cat /sys/kernel/debug/tracing/trace # tracer: nop # # entries-in-buffer/entries-written: 2/2 #P:4 # # _-=> irqs-off # / _=> need-resched #| / _---=> hardirq/softirq #|| / _--=> preempt-depth #||| / delay # TASK-PID CPU# TIMESTAMP FUNCTION # | | | | | modprobe-2707 [002] d..197.079458: console: [ 95.816945] NFS: Registering the id_resolver key type modprobe-2707 [002] d..197.084534: console: [ 95.822038] Key type id_resolver registered If you wanted this from boot up, you can just add to the kernel command line: trace_event=console -- Steve -- 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
gpmc generic retime function (subject was RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration)
Hi Tony, Jon, On Wed, Jul 11, 2012 at 12:17:25, Tony Lindgren wrote: > * Jon Hunter [120710 10:20]: > > The DT node should simply have the information required by the retime > > function or gpmc timings themselves if available. In the case of OneNAND > > These can be stored in the DT and then translated to gpmc timings at > > runtime. DT should only store static timing or clock information known > Yup. And the format of the timing data in DT should be standardized so > the only differences for each connected peripheral is the retime function. If we are able to achieve a generic retime function applicable to all peripherals then we don't need wrapper layer for retime handling or two linux devices and drivers (one the existing and the other to handle retime) to represent a single physical gpmc peripheral device (for DT conversion). Then handling core frequency scaling and DT conversion would be easier. We were trying to create such a retime function that would be generic so as to handle different types of gpmc peripherals. And we have been able to create such a function. Below is an implementation that has been made for handling asynchronous timings. It has been tested for OneNAND & SMSC on OMAP3EVM (rev G & C) with [1-4]. OneNAND was tested using [5] (OMAP3EVM OneNAND works in async mode) & SMSC using [6] (mainline does not have a timing calculation for smsc911x) It was difficult to squeeze tusb6010 timing calculation into generic timing calculation, hence a boolean "tusb" has been used. This is what I could achieve based on existing retime for tusb6010 and for lack of tusb6010 timing specifications. 8<--- /* Device timings in picoseconds */ struct gpmc_device_timings { u32 cs_setup; /* CS setup time */ u32 adv_setup; /* ADV setup time */ u32 adv_rd_off; /* ADV read off time */ u32 adv_add_hold; /* address hold time */ u32 oe_setup; /* OE setup time */ u32 adv_access; /* access time from ADV assertion */ u32 rd_access; /* read access time */ u32 oe_access; /* access time from OE assertion */ u32 cs_access; /* access time from CS asertion */ u32 rd_cycle; /* read cycle time */ u32 cs_highz; /* CS deassertion to high Z */ u32 oe_highz; /* OE deassertion to high Z */ u32 adv_wr_off; /* ADV write off time */ u32 we_setup; /* WE setup time */ u32 wr_pulse; /* write assertion time */ u32 wr_data_setup; /* data setup time from write assertion */ u32 wr_high;/* write deassertion time */ u32 we_highz; /* WE deassertion to high Z */ u32 wr_cycle; /* write cycle time */ boolmux;/* address & data muxed */ booltusb; /* peripheral is tusb6010 */ }; struct gpmc_timings gpmc_calc_timings(struct gpmc_device_timings *dev_t) { struct gpmc_timings gpmc_t; bool mux = dev_t->mux; bool tusb = dev_t->tusb; u32 temp; memset(&gpmc_t, 0, sizeof(gpmc_t)); /* cs_on */ gpmc_t.cs_on = gpmc_round_ns_to_ticks(dev_t->cs_setup / 1000); /* adv_on */ temp = dev_t->adv_setup; if (tusb) temp = max_t(u32, (gpmc_t.cs_on + gpmc_ticks_to_ns(1)) * 1000, temp); gpmc_t.adv_on = gpmc_round_ns_to_ticks(temp / 1000); /* adv_rd_off */ temp = dev_t->adv_rd_off; if (tusb) temp = max_t(u32, (gpmc_t.adv_on + gpmc_ticks_to_ns(1)) * 1000, temp); gpmc_t.adv_rd_off = gpmc_round_ns_to_ticks(temp / 1000); /* oe_on */ if (mux) temp = gpmc_t.adv_rd_off * 1000 + dev_t->adv_add_hold; else temp = dev_t->oe_setup; if (tusb) temp = max_t(u32, (gpmc_t.adv_rd_off + gpmc_ticks_to_ns(1)) * 1000, temp); gpmc_t.oe_on = gpmc_round_ns_to_ticks(temp / 1000); /* access */ temp = max_t(u32, dev_t->rd_access, gpmc_t.oe_on * 1000 + dev_t->oe_access); temp = max_t(u32, temp, gpmc_t.cs_on * 1000 + dev_t->cs_access); temp = max_t(u32, temp, gpmc_t.adv_on * 1000 + dev_t->adv_access); if (tusb) { temp = max_t(u32, temp, (gpmc_t.oe_on + gpmc_ticks_to_ns(1)) * 1000); temp = max_t(u32, temp, gpmc_t.oe_on * 1000 + 300); } gpmc_t.access = gpmc_round_ns_to_ticks(temp / 1000); gpmc_t.oe_off = gpmc_t.access + gpmc_ticks_to_ns(1); gpmc_t.cs_rd_off = gpmc_t.oe_off; /* rd_cycle */ temp = max_t(u32,
Re: [PATCHv7 06/12] ARM: OMAP4: suspend: Program all domains to retention
Hi! On Thu, Jul 19, 2012 at 4:16 PM, Sergei Shtylyov wrote: > Hello. > > On 07/19/2012 05:26 PM, Tero Kristo wrote: > >> From: Rajendra Nayak > >> Remove the FIXME's in the suspend sequence since >> we now intend to support system level RET support. > >> Signed-off-by: Rajendra Nayak >> Signed-off-by: Tero Kristo >> [Jean Pihet : ported on top of the functional power >> states] > > Shouldn't Jean also have signed off? Sure! I am OK with this change, feel free to add: Acked-by: Jean Pihet Regards, Jean > >> Reviewed-by: Santosh Shilimkar > > WBR, Sergei > -- > 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
[PATCH v7 3/7] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
All the PHY configuration other than VBUS, ID GND and OTG SRP are removed from twl6030. The phy configurations are taken care by the dedicated usb2 phy driver. So twl6030 is made as comparator driver for VBUS and ID detection. Writing to control module which is now handled in omap2430.c should be removed once a driver for control module is in place. Signed-off-by: Kishon Vijay Abraham I --- drivers/usb/musb/omap2430.c | 52 +++--- drivers/usb/musb/omap2430.h |9 drivers/usb/otg/twl6030-usb.c | 118 +++-- 3 files changed, 72 insertions(+), 107 deletions(-) diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 392fc7a..74dbd6f 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -44,6 +44,7 @@ struct omap2430_glue { struct platform_device *musb; enum omap_musb_vbus_id_status status; struct work_struct omap_musb_mailbox_work; + u32 __iomem *control_otghs; }; #define glue_to_musb(g)platform_get_drvdata(g->musb) @@ -51,6 +52,26 @@ struct omap2430_glue *_glue; static struct timer_list musb_idle_timer; +/** + * omap4_usb_phy_mailbox - write to usb otg mailbox + * @glue: struct omap2430_glue * + * @val: the value to be written to the mailbox + * + * On detection of a device (ID pin is grounded), this API should be called + * to set AVALID, VBUSVALID and ID pin is grounded. + * + * When OMAP is connected to a host (OMAP in device mode), this API + * is called to set AVALID, VBUSVALID and ID pin in high impedance. + * + * XXX: This function will be removed once we have a seperate driver for + * control module + */ +static void omap4_usb_phy_mailbox(struct omap2430_glue *glue, u32 val) +{ + if (glue->control_otghs) + writel(val, glue->control_otghs); +} + static void musb_do_idle(unsigned long _musb) { struct musb *musb = (void *)_musb; @@ -245,6 +266,7 @@ EXPORT_SYMBOL_GPL(omap_musb_mailbox); static void omap_musb_set_mailbox(struct omap2430_glue *glue) { + u32 val; struct musb *musb = glue_to_musb(glue); struct device *dev = musb->controller; struct musb_hdrc_platform_data *pdata = dev->platform_data; @@ -260,7 +282,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue) musb->xceiv->last_event = USB_EVENT_ID; if (!is_otg_enabled(musb) || musb->gadget_driver) { pm_runtime_get_sync(dev); - usb_phy_init(musb->xceiv); + val = AVALID | VBUSVALID; + omap4_usb_phy_mailbox(glue, val); omap2430_musb_set_vbus(musb, 1); } break; @@ -273,7 +296,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue) musb->xceiv->last_event = USB_EVENT_VBUS; if (musb->gadget_driver) pm_runtime_get_sync(dev); - usb_phy_init(musb->xceiv); + val = IDDIG | AVALID | VBUSVALID; + omap4_usb_phy_mailbox(glue, val); break; case OMAP_MUSB_ID_FLOAT: @@ -291,7 +315,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue) if (musb->xceiv->otg->set_vbus) otg_set_vbus(musb->xceiv->otg, 0); } - usb_phy_shutdown(musb->xceiv); + val = SESSEND | IDDIG; + omap4_usb_phy_mailbox(glue, val); break; default: dev_dbg(dev, "ID float\n"); @@ -366,6 +391,7 @@ err1: static void omap2430_musb_enable(struct musb *musb) { u8 devctl; + u32 val; unsigned long timeout = jiffies + msecs_to_jiffies(1000); struct device *dev = musb->controller; struct omap2430_glue *glue = dev_get_drvdata(dev->parent); @@ -375,7 +401,8 @@ static void omap2430_musb_enable(struct musb *musb) switch (glue->status) { case OMAP_MUSB_ID_GROUND: - usb_phy_init(musb->xceiv); + val = AVALID | VBUSVALID; + omap4_usb_phy_mailbox(glue, val); if (data->interface_type != MUSB_INTERFACE_UTMI) break; devctl = musb_readb(musb->mregs, MUSB_DEVCTL); @@ -394,7 +421,8 @@ static void omap2430_musb_enable(struct musb *musb) break; case OMAP_MUSB_VBUS_VALID: - usb_phy_init(musb->xceiv); + val = IDDIG | AVALID | VBUSVALID; + omap4_usb_phy_mailbox(glue, val); break; default: @@ -404,11 +432,14 @@ static void omap2430_musb_enable(struct musb *musb) static void omap2430_musb_disable(struct musb *musb) { + u32 val; struct device *dev = musb->controller; struct omap2430_glue *glue = dev_ge
[PATCH v7 5/7] drivers: usb: twl4030: Add device tree support for twl4030 usb
Add device tree support for twl4030 usb driver. Update the Documentation with device tree binding information. Signed-off-by: Kishon Vijay Abraham I --- .../devicetree/bindings/usb/twl-usb.txt| 19 ++ drivers/usb/otg/twl4030-usb.c | 26 +++- 2 files changed, 39 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt b/Documentation/devicetree/bindings/usb/twl-usb.txt index 930f9ff..36b9aed 100644 --- a/Documentation/devicetree/bindings/usb/twl-usb.txt +++ b/Documentation/devicetree/bindings/usb/twl-usb.txt @@ -19,3 +19,22 @@ Board specific device node entry &twl6030-usb { usb-supply = <&vusb>; }; + +TWL4030 USB PHY AND COMPARATOR + - compatible : Should be "ti,twl4030-usb" + - interrupts : The interrupt numbers to the cpu should be specified. First + interrupt number is the otg interrupt number that raises ID interrupts + and VBUS interrupts. The second interrupt number is optional. + - -supply : phandle to the regulator device tree node. +should be vusb1v5, vusb1v8 and vusb3v1 + - usb_mode : The mode used by the phy to connect to the controller. "1" + specifies "ULPI" mode and "2" specifies "CEA2011_3PIN" mode. + +twl4030-usb { + compatible = "ti,twl4030-usb"; + interrupts = < 10 4 >; + usb1v5-supply = <&vusb1v5>; + usb1v8-supply = <&vusb1v8>; + usb3v1-supply = <&vusb3v1>; + usb_mode = <1>; +}; diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c index 523cad5..f0d2e75 100644 --- a/drivers/usb/otg/twl4030-usb.c +++ b/drivers/usb/otg/twl4030-usb.c @@ -585,23 +585,28 @@ static int __devinit twl4030_usb_probe(struct platform_device *pdev) struct twl4030_usb *twl; int status, err; struct usb_otg *otg; - - if (!pdata) { - dev_dbg(&pdev->dev, "platform_data not available\n"); - return -EINVAL; - } + struct device_node *np = pdev->dev.of_node; twl = devm_kzalloc(&pdev->dev, sizeof *twl, GFP_KERNEL); if (!twl) return -ENOMEM; + if (np) + of_property_read_u32(np, "usb_mode", + (enum twl4030_usb_mode *)&twl->usb_mode); + else if (pdata) + twl->usb_mode = pdata->usb_mode; + else { + dev_err(&pdev->dev, "twl4030 initialized without pdata\n"); + return -EINVAL; + } + otg = devm_kzalloc(&pdev->dev, sizeof *otg, GFP_KERNEL); if (!otg) return -ENOMEM; twl->dev= &pdev->dev; twl->irq= platform_get_irq(pdev, 0); - twl->usb_mode = pdata->usb_mode; twl->vbus_supplied = false; twl->asleep = 1; twl->linkstat = OMAP_MUSB_UNKNOWN; @@ -690,12 +695,21 @@ static int __exit twl4030_usb_remove(struct platform_device *pdev) return 0; } +#ifdef CONFIG_OF +static const struct of_device_id twl4030_usb_id_table[] = { + { .compatible = "ti,twl4030-usb" }, + {} +}; +MODULE_DEVICE_TABLE(of, twl4030_usb_id_table); +#endif + static struct platform_driver twl4030_usb_driver = { .probe = twl4030_usb_probe, .remove = __exit_p(twl4030_usb_remove), .driver = { .name = "twl4030_usb", .owner = THIS_MODULE, + .of_match_table = of_match_ptr(twl4030_usb_id_table), }, }; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 1/7] drivers: usb: phy: add a new driver for omap usb2 phy
All phy related programming like enabling/disabling the clocks, powering on/off the phy is taken care of by this driver. It is also used for OTG related functionality like srp. This also includes device tree support for usb2 phy driver and the documentation with device tree binding information is updated. Currently writing to control module register is taken care in this driver which will be removed once the control module driver is in place. Cc: Felipe Balbi Signed-off-by: Kishon Vijay Abraham I --- .../devicetree/bindings/bus/omap-ocp2scp.txt |3 + Documentation/devicetree/bindings/usb/omap-usb.txt | 17 ++ drivers/usb/phy/Kconfig| 10 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c| 271 include/linux/usb/omap_usb.h | 46 include/linux/usb/phy_companion.h | 34 +++ 7 files changed, 382 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt create mode 100644 drivers/usb/phy/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt index d2fe064..bb0c7f4 100644 --- a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt +++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt @@ -8,3 +8,6 @@ properties: Sub-nodes: All the devices connected to ocp2scp are described using sub-node to ocp2scp +- usb2phy : + The binding details of usb2phy can be found in: + Documentation/devicetree/bindings/usb/omap-usb.txt diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt new file mode 100644 index 000..52f503b --- /dev/null +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt @@ -0,0 +1,17 @@ +OMAP USB PHY + +OMAP USB2 PHY + +Required properties: + - compatible: Should be "ti,omap-usb2" + - reg : Address and length of the register set for the device. Also +add the address of control module dev conf register until a driver for +control module is added + +This is usually a subnode of ocp2scp to which it is connected. + +usb2phy@4a0ad080 { + compatible = "ti,omap-usb2"; + reg = <0x4a0ad080 0x58>, + <0x4a002300 0x1>; +}; diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index e7cf84f..c2ab461 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -4,6 +4,16 @@ comment "USB Physical Layer drivers" depends on USB || USB_GADGET +config OMAP_USB2 + tristate "OMAP USB2 PHY Driver" + depends on OMAP_OCP2SCP + select USB_OTG_UTILS + help + Enable this to support the transceiver that is part of SOC. This + driver takes care of all the PHY functionality apart from comparator. + The USB OTG controller communicates with the comparator using this + driver. + config USB_ISP1301 tristate "NXP ISP1301 USB transceiver support" depends on USB || USB_GADGET diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index eca095b..d3fcec9 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -4,4 +4,5 @@ ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG +obj-$(CONFIG_OMAP_USB2)+= omap-usb2.o obj-$(CONFIG_USB_ISP1301) += isp1301.o diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c new file mode 100644 index 000..984899b --- /dev/null +++ b/drivers/usb/phy/omap-usb2.c @@ -0,0 +1,271 @@ +/* + * omap-usb2.c - USB PHY, talking to musb controller in OMAP. + * + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * Author: Kishon Vijay Abraham I + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/** + * omap_usb2_set_comparator - links the comparator present in the sytem with + * this phy + * @comparator - the companion phy(comparator) for this phy + * + * The phy companion driver should call this API passing the phy_companion + * filled with set_vbus and start_srp to be used by usb phy. + * + * For use by phy companion driver + */ +int omap_usb2_set_comparator(struct phy_companion *comparator) +{ + struct omap_usb *phy; + struct usb_
[PATCH v7 7/7] arm: omap: phy: remove unused functions from omap-phy-internal.c
All the unnessary functions in omap-phy-internal is removed. These functionality are now handled by omap-usb2 phy driver. Cc: Felipe Balbi Signed-off-by: Kishon Vijay Abraham I Acked-by: Tony Lindgren --- arch/arm/mach-omap2/omap_phy_internal.c | 138 --- arch/arm/mach-omap2/twl-common.c|5 -- arch/arm/mach-omap2/usb-musb.c |3 - 3 files changed, 146 deletions(-) diff --git a/arch/arm/mach-omap2/omap_phy_internal.c b/arch/arm/mach-omap2/omap_phy_internal.c index d52651a..874aecc 100644 --- a/arch/arm/mach-omap2/omap_phy_internal.c +++ b/arch/arm/mach-omap2/omap_phy_internal.c @@ -31,144 +31,6 @@ #include #include "control.h" -/* OMAP control module register for UTMI PHY */ -#define CONTROL_DEV_CONF 0x300 -#define PHY_PD 0x1 - -#define USBOTGHS_CONTROL 0x33c -#defineAVALID BIT(0) -#defineBVALID BIT(1) -#defineVBUSVALID BIT(2) -#defineSESSEND BIT(3) -#defineIDDIG BIT(4) - -static struct clk *phyclk, *clk48m, *clk32k; -static void __iomem *ctrl_base; -static int usbotghs_control; - -int omap4430_phy_init(struct device *dev) -{ - ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K); - if (!ctrl_base) { - pr_err("control module ioremap failed\n"); - return -ENOMEM; - } - /* Power down the phy */ - __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF); - - if (!dev) { - iounmap(ctrl_base); - return 0; - } - - phyclk = clk_get(dev, "ocp2scp_usb_phy_ick"); - if (IS_ERR(phyclk)) { - dev_err(dev, "cannot clk_get ocp2scp_usb_phy_ick\n"); - iounmap(ctrl_base); - return PTR_ERR(phyclk); - } - - clk48m = clk_get(dev, "ocp2scp_usb_phy_phy_48m"); - if (IS_ERR(clk48m)) { - dev_err(dev, "cannot clk_get ocp2scp_usb_phy_phy_48m\n"); - clk_put(phyclk); - iounmap(ctrl_base); - return PTR_ERR(clk48m); - } - - clk32k = clk_get(dev, "usb_phy_cm_clk32k"); - if (IS_ERR(clk32k)) { - dev_err(dev, "cannot clk_get usb_phy_cm_clk32k\n"); - clk_put(phyclk); - clk_put(clk48m); - iounmap(ctrl_base); - return PTR_ERR(clk32k); - } - return 0; -} - -int omap4430_phy_set_clk(struct device *dev, int on) -{ - static int state; - - if (on && !state) { - /* Enable the phy clocks */ - clk_enable(phyclk); - clk_enable(clk48m); - clk_enable(clk32k); - state = 1; - } else if (state) { - /* Disable the phy clocks */ - clk_disable(phyclk); - clk_disable(clk48m); - clk_disable(clk32k); - state = 0; - } - return 0; -} - -int omap4430_phy_power(struct device *dev, int ID, int on) -{ - if (on) { - if (ID) - /* enable VBUS valid, IDDIG groung */ - __raw_writel(AVALID | VBUSVALID, ctrl_base + - USBOTGHS_CONTROL); - else - /* -* Enable VBUS Valid, AValid and IDDIG -* high impedance -*/ - __raw_writel(IDDIG | AVALID | VBUSVALID, - ctrl_base + USBOTGHS_CONTROL); - } else { - /* Enable session END and IDIG to high impedance. */ - __raw_writel(SESSEND | IDDIG, ctrl_base + - USBOTGHS_CONTROL); - } - return 0; -} - -int omap4430_phy_suspend(struct device *dev, int suspend) -{ - if (suspend) { - /* Disable the clocks */ - omap4430_phy_set_clk(dev, 0); - /* Power down the phy */ - __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF); - - /* save the context */ - usbotghs_control = __raw_readl(ctrl_base + USBOTGHS_CONTROL); - } else { - /* Enable the internel phy clcoks */ - omap4430_phy_set_clk(dev, 1); - /* power on the phy */ - if (__raw_readl(ctrl_base + CONTROL_DEV_CONF) & PHY_PD) { - __raw_writel(~PHY_PD, ctrl_base + CONTROL_DEV_CONF); - mdelay(200); - } - - /* restore the context */ - __raw_writel(usbotghs_control, ctrl_base + USBOTGHS_CONTROL); - } - - return 0; -} - -int omap4430_phy_exit(struct device *dev) -{ - if (ctrl_base) - iounmap(ctrl_base); - if (phyclk) -
[PATCH v7 4/7] drivers: usb: twl6030: Add dt support for twl6030 usb
Add device tree support for twl6030 usb driver. Update the Documentation with device tree binding information. Signed-off-by: Kishon Vijay Abraham I --- .../devicetree/bindings/usb/twl-usb.txt| 21 +++ drivers/usb/otg/twl6030-usb.c | 39 +--- 2 files changed, 47 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt b/Documentation/devicetree/bindings/usb/twl-usb.txt new file mode 100644 index 000..930f9ff --- /dev/null +++ b/Documentation/devicetree/bindings/usb/twl-usb.txt @@ -0,0 +1,21 @@ +USB COMPARATOR OF TWL CHIPS + +TWL6030 USB COMPARATOR + - compatible : Should be "ti,twl6030-usb" + - interrupts : Two interrupt numbers to the cpu should be specified. First + interrupt number is the otg interrupt number that raises ID interrupts when + the controller has to act as host and the second interrupt number is the + usb interrupt number that raises VBUS interrupts when the controller has to + act as device + - usb-supply : phandle to the regulator device tree node. It should be vusb + if it is twl6030 or ldousb if it is twl6025 subclass. + +twl6030-usb { + compatible = "ti,twl6030-usb"; + interrupts = < 4 10 >; +}; + +Board specific device node entry +&twl6030-usb { + usb-supply = <&vusb>; +}; diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c index 32525bb..fcadef7 100644 --- a/drivers/usb/otg/twl6030-usb.c +++ b/drivers/usb/otg/twl6030-usb.c @@ -105,7 +105,7 @@ struct twl6030_usb { u8 asleep; boolirq_enabled; boolvbus_enable; - unsigned long features; + const char *regulator; }; #definecomparator_to_twl(x) container_of((x), struct twl6030_usb, comparator) @@ -153,13 +153,6 @@ static int twl6030_start_srp(struct phy_companion *comparator) static int twl6030_usb_ldo_init(struct twl6030_usb *twl) { - char *regulator_name; - - if (twl->features & TWL6025_SUBCLASS) - regulator_name = "ldousb"; - else - regulator_name = "vusb"; - /* Set to OTG_REV 1.3 and turn on the ID_WAKEUP_COMP */ twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x1, TWL6030_BACKUP_REG); @@ -169,7 +162,7 @@ static int twl6030_usb_ldo_init(struct twl6030_usb *twl) /* Program MISC2 register and set bit VUSB_IN_VBAT */ twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x10, TWL6030_MISC2); - twl->usb3v3 = regulator_get(twl->dev, regulator_name); + twl->usb3v3 = regulator_get(twl->dev, twl->regulator); if (IS_ERR(twl->usb3v3)) return -ENODEV; @@ -322,9 +315,9 @@ static int __devinit twl6030_usb_probe(struct platform_device *pdev) u32 ret; struct twl6030_usb *twl; int status, err; - struct twl4030_usb_data *pdata; - struct device *dev = &pdev->dev; - pdata = dev->platform_data; + struct device_node *np = pdev->dev.of_node; + struct device *dev = &pdev->dev; + struct twl4030_usb_data *pdata = dev->platform_data; twl = devm_kzalloc(dev, sizeof *twl, GFP_KERNEL); if (!twl) @@ -333,7 +326,6 @@ static int __devinit twl6030_usb_probe(struct platform_device *pdev) twl->dev= &pdev->dev; twl->irq1 = platform_get_irq(pdev, 0); twl->irq2 = platform_get_irq(pdev, 1); - twl->features = pdata->features; twl->linkstat = OMAP_MUSB_UNKNOWN; twl->comparator.set_vbus= twl6030_set_vbus; @@ -345,6 +337,18 @@ static int __devinit twl6030_usb_probe(struct platform_device *pdev) return -EPROBE_DEFER; } + if (np) { + twl->regulator = "usb"; + } else if (pdata) { + if (pdata->features & TWL6025_SUBCLASS) + twl->regulator = "ldousb"; + else + twl->regulator = "vusb"; + } else { + dev_err(&pdev->dev, "twl6030 initialized without pdata\n"); + return -EINVAL; + } + /* init spinlock for workqueue */ spin_lock_init(&twl->lock); @@ -406,12 +410,21 @@ static int __exit twl6030_usb_remove(struct platform_device *pdev) return 0; } +#ifdef CONFIG_OF +static const struct of_device_id twl6030_usb_id_table[] = { + { .compatible = "ti,twl6030-usb" }, + {} +}; +MODULE_DEVICE_TABLE(of, twl6030_usb_id_table); +#endif + static struct platform_driver twl6030_usb_driver = { .probe = twl6030_usb_probe, .remove = __exit_p(twl6030_usb_remove), .driver = { .name = "twl6030_usb", .owner = THIS_M
[PATCH v7 0/7] omap: musb: Add device tree support
This patch series adds device tree support for MUSB and device tree support for all the related modules to get MUSB working in OMAP platform. A new omap-usb2 phy driver has been added (with only dt suppport) to perform phy configurations. Previously this configuration was performed by twl6030, using pdata function pointers. With the addition of omap-usb2 to perform phy configurations, twl6030 is made as a comparator driver to detect VBUS and ID events and notify it to the glue layer. musb core is _NOT_ yet converted to support device tree support as it would need lot of driver re-design because of its enormous use of function pointers. That will be in _TO DO_ list. Changes from v6: * Removed the dt data part of the patch series. It'll be sent as a separate series. * Replaced arch initcall in omap-usb2 phy driver with a module platform driver. Dependent drivers should use -EPROBE_DEFER. Changes from v5: minor cleanups like checking for return value in get_sync and few changes in the documentation has been done. Changes from v4: duplicate getting of 'mode' property is removed in omap-musb glue. Changes from v3: remove the address in the node name of usb_otg_hs since the usb_otg_hs node doesn't have a reg property. Thanks Ajay Gupta for finding this. Changes from v2: Fixed Sergei's comment to remove *0x* prefix in usb2phy@0x4a0ad080 Changes from v1: * Fixed Rajendra Nayak comments (regulator naming, compatible naming of musb and other minor cleanups.) * It's agreed to have ocp2scp in drivers/bus and usb2 phy is a child of ocp2scp, the documentation is updated accordingly. Changes from RFC: Removed the dependency on [RFC PATCH 00/11] OMAP System Control Module. Writing to control module register is now handled in otg driver itself. Once the system control module driver get upstreamed, I'll send a patch to make use of API's in control module driver to write to control module register. This series was developed on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv This patch series depends on [PATCH v3 0/2] omap: add ocp2scp as a bus driver Performed MUSB device mode testing on OMAP4 panda, OMAP4 SDP and OMAP3 beagle. Kishon Vijay Abraham I (7): drivers: usb: phy: add a new driver for omap usb2 phy arm: omap: hwmod: add a new addr space in otg for writing to control module drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2 drivers: usb: twl6030: Add dt support for twl6030 usb drivers: usb: twl4030: Add device tree support for twl4030 usb drivers: usb: musb: Add device tree support for omap musb glue arm: omap: phy: remove unused functions from omap-phy-internal.c .../devicetree/bindings/bus/omap-ocp2scp.txt |3 + Documentation/devicetree/bindings/usb/omap-usb.txt | 49 .../devicetree/bindings/usb/twl-usb.txt| 40 +++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 + arch/arm/mach-omap2/omap_phy_internal.c| 138 -- arch/arm/mach-omap2/twl-common.c |5 - arch/arm/mach-omap2/usb-musb.c |3 - drivers/usb/musb/omap2430.c| 106 +++- drivers/usb/musb/omap2430.h|9 + drivers/usb/otg/twl4030-usb.c | 26 +- drivers/usb/otg/twl6030-usb.c | 157 drivers/usb/phy/Kconfig| 10 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c| 271 include/linux/usb/omap_usb.h | 46 include/linux/usb/phy_companion.h | 34 +++ 16 files changed, 631 insertions(+), 272 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt create mode 100644 drivers/usb/phy/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 2/7] arm: omap: hwmod: add a new addr space in otg for writing to control module
The mailbox register for usb otg in omap is present in control module. On detection of any events VBUS or ID, this register should be written to send the notification to musb core. Till we have a separate control module driver to write to control module, omap2430 will handle the register writes to control module by itself. So a new address space to represent this control module register is added to usb_otg_hs. Signed-off-by: Kishon Vijay Abraham I --- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index e8e5405..6334e22 100644 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -5885,6 +5885,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = { .pa_end = 0x4a0ab003, .flags = ADDR_TYPE_RT }, + { + .pa_start = 0x4a00233c, + .pa_end = 0x4a00233f, + .flags = ADDR_TYPE_RT + }, { } }; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 6/7] drivers: usb: musb: Add device tree support for omap musb glue
Added device tree support for omap musb driver and updated the Documentation with device tree binding information. Signed-off-by: Kishon Vijay Abraham I --- Documentation/devicetree/bindings/usb/omap-usb.txt | 34 +++- drivers/usb/musb/omap2430.c| 54 2 files changed, 87 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt index 52f503b..49a90fb 100644 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt @@ -1,4 +1,4 @@ -OMAP USB PHY +OMAP USB PHY AND GLUE OMAP USB2 PHY @@ -15,3 +15,35 @@ usb2phy@4a0ad080 { reg = <0x4a0ad080 0x58>, <0x4a002300 0x1>; }; + +OMAP MUSB GLUE + - compatible : Should be "ti,musb-omap2430" + - ti,hwmods : must be "usb_otg_hs" + - multipoint : Should be "1" indicating the musb controller supports + multipoint. This is a MUSB configuration-specific setting. + - num_eps : Specifies the number of endpoints. This is also a + MUSB configuration-specific setting. Should be set to "16" + - ram_bits : Specifies the ram address size. Should be set to "12" + - interface_type : This is a board specific setting to describe the type of + interface between the controller and the phy. It should be "0" or "1" + specifying ULPI and UTMI respectively. + - mode : Should be "3" to represent OTG. "1" signifies HOST and "2" + represents PERIPHERAL. + - power : Should be "50". This signifies the controller can supply upto + 100mA when operating in host mode. + +SOC specific device node entry +usb_otg_hs: usb_otg_hs@4a0ab000 { + compatible = "ti,musb-omap2430"; + ti,hwmods = "usb_otg_hs"; + multipoint = <1>; + num_eps = <16>; + ram_bits = <12>; +}; + +Board specific device node entry +&usb_otg_hs { + interface_type = <1>; + mode = <3>; + power = <50>; +}; diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 74dbd6f..8b1d7c0 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -30,6 +30,7 @@ #include #include #include +#include #include #include #include @@ -469,8 +470,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32); static int __devinit omap2430_probe(struct platform_device *pdev) { struct musb_hdrc_platform_data *pdata = pdev->dev.platform_data; + struct omap_musb_board_data *data; struct platform_device *musb; struct omap2430_glue*glue; + struct device_node *np = pdev->dev.of_node; + struct musb_hdrc_config *config; struct resource *res; int ret = -ENOMEM; @@ -500,6 +504,42 @@ static int __devinit omap2430_probe(struct platform_device *pdev) if (glue->control_otghs == NULL) dev_dbg(&pdev->dev, "Failed to obtain control memory\n"); + if (np) { + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL); + if (!pdata) { + dev_err(&pdev->dev, + "failed to allocate musb platfrom data\n"); + ret = -ENOMEM; + goto err1; + } + + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL); + if (!data) { + dev_err(&pdev->dev, + "failed to allocate musb board data\n"); + ret = -ENOMEM; + goto err1; + } + + config = devm_kzalloc(&pdev->dev, sizeof(*config), GFP_KERNEL); + if (!data) { + dev_err(&pdev->dev, + "failed to allocate musb hdrc config\n"); + goto err1; + } + + of_property_read_u32(np, "mode", (u32 *)&pdata->mode); + of_property_read_u32(np, "interface_type", + (u32 *)&data->interface_type); + of_property_read_u32(np, "num_eps", (u32 *)&config->num_eps); + of_property_read_u32(np, "ram_bits", (u32 *)&config->ram_bits); + of_property_read_u32(np, "power", (u32 *)&pdata->power); + config->multipoint = of_property_read_bool(np, "multipoint"); + + pdata->board_data = data; + pdata->config = config; + } + pdata->platform_ops = &omap2430_ops; platform_set_drvdata(pdev, glue); @@ -596,12 +636,26 @@ static struct dev_pm_ops omap2430_pm_ops = { #define DEV_PM_OPS NULL #endif +#ifdef CONFIG_OF +static const struct of_device_id omap2430_id_table[] = { + { + .compatible = "ti,omap4-musb" + }, + { + .compatible = "t
Re: [PATCH] OMAPDSS: OMAPFB: fix framebuffer console colors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/06/12 14:22, Tomi Valkeinen wrote: > On Mon, 2012-08-06 at 13:15 +0300, Igor Grinberg wrote: >> On 08/06/12 09:00, Tomi Valkeinen wrote: >>> On Sat, 2012-08-04 at 19:19 +0300, Grazvydas Ignotas wrote: omapfb does not currently set pseudo palette correctly for color depths above 16bpp, making red text invisible, command like echo -e '\e[0;31mRED' > /dev/tty1 will display nothing on framebuffer console in 24bpp mode. This is because temporary variable is declared incorrectly, fix it. >>> >>> Thanks, applied to OMAP DSS tree. >> >> Is it also applicable to stable? >> If yes, Tomi, can you please add the Cc tag? > > Yes, the bug has been there from the beginning. > > I can add the Cc tag. But I wonder is it enough just to have the tag, or > should I also send the patch forward? And does it only get applied to > the latest stable tree, not the earlier ones? Well, the Documentation/stable_kernel_rules.txt says: - To have the patch automatically included in the stable tree, add the tag Cc: sta...@vger.kernel.org in the sign-off area. Once the patch is merged it will be applied to the stable tree without anything else needing to be done by the author or subsystem maintainer. So I guess, you don't need to resend it. Also, IIUC, if you can identify all the stable kernels it applies to, you can specify them like: Cc: # 3.x, 2.6.x This can save some work for those responsible for adding the patch to stable. Now, if you say, it is applicable to all kernels since the omapfb support was merged, I think, the above example it the right choice. Anyway, Greg, please correct me if I've got anything wrong. Thanks - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQH7gRAAoJEBDE8YO64EfakCAP/izNPA/HcFhxE3cRJJhlh5xw Caf4h6gXjdTNekSfLEppyo+uf6F2ef8ojZFoim1x59phjC9N9TQWyqTgV6qTGWul o8YtCo3CMXPTVnxgoYtIFNDIngiuZFVATEWdoHlxlpWwBXWcr6K101Rg+x0hlvzl CAqquuwjO+GFmPn+6hLns3sFJcnD02e2Rb0tX29Yg/SdFCMPDIRA3NUANVqILcxN do6mWpZ3tKOmPzobUDr1tswJxK94oc0pIjKMjxy71qAxpLMtY2bVNKavKuGsgaRr Nl7Bml5e1vCvAJNtYTpiMKvjomTvS1gktBoAa43u81THDrvwzJNO/mUq88CuMOg0 D0k8ohKrv0/WyKr+LZe9W4l4I9lIvbutvF5oxcU+1gC01pMlr9qghO8J3Oz5/UTi /Swd7Q5I6X29TtudIuAsZ8g5didNBTLYgih+DODviTRzaca7msF+VfNkcg2IeOuA MvkMwiZSZX15ggriH07dEr+Z2XF7mMYVMgn492RokMzeXx31VXeHYv9pNGXcF+xn xV55Z03RT2jcnIPJVSfnzXAXIhTdkM2MVBaS/iNKckPW1Q1quiY/7IeWJaX59LBl bWUIFC02HJ+n8S2Tyqbr+7+0ue6v3xVocw/fcwx0PCLx0HltxhrAJJzTB+o4SDya DpSx1+W2seaVbd7AgkmN =qbs/ -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] drivers: bus: add a new driver for omap-ocp2scp
On Mon, Aug 06, 2012 at 04:55:30PM +0530, Kishon Vijay Abraham I wrote: > Adds a new driver *omap-ocp2scp*. This driver takes the responsibility of > creating all the devices that is connected to OCP2SCP. In the case of OMAP4, > USB2PHY is connected to ocp2scp. > > This also includes device tree support for ocp2scp driver and > the documentation with device tree binding information is updated. > > Acked-by: Felipe Balbi > Acked-by: Arnd Bergmann > Signed-off-by: Kishon Vijay Abraham I > --- > .../devicetree/bindings/bus/omap-ocp2scp.txt | 10 +++ > drivers/Kconfig|2 + > drivers/Makefile |2 + > drivers/bus/Kconfig| 15 > drivers/bus/Makefile |5 ++ > drivers/bus/omap-ocp2scp.c | 88 > > 6 files changed, 122 insertions(+) > create mode 100644 Documentation/devicetree/bindings/bus/omap-ocp2scp.txt > create mode 100644 drivers/bus/Kconfig > create mode 100644 drivers/bus/Makefile > create mode 100644 drivers/bus/omap-ocp2scp.c > > diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt > b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt > new file mode 100644 > index 000..d2fe064 > --- /dev/null > +++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt > @@ -0,0 +1,10 @@ > +* OMAP OCP2SCP - ocp interface to scp interface > + > +properties: > +- compatible : Should be "ti,omap-ocp2scp" > +- #address-cells, #size-cells : Must be present if the device has sub-nodes > +- ranges : the child address space are mapped 1:1 onto the parent address > space > +- ti,hwmods : must be "ocp2scp_usb_phy" > + > +Sub-nodes: > +All the devices connected to ocp2scp are described using sub-node to ocp2scp > diff --git a/drivers/Kconfig b/drivers/Kconfig > index ece958d..324e958 100644 > --- a/drivers/Kconfig > +++ b/drivers/Kconfig > @@ -2,6 +2,8 @@ menu "Device Drivers" > > source "drivers/base/Kconfig" > > +source "drivers/bus/Kconfig" > + > source "drivers/connector/Kconfig" > > source "drivers/mtd/Kconfig" > diff --git a/drivers/Makefile b/drivers/Makefile > index 5b42184..f8cdeeb 100644 > --- a/drivers/Makefile > +++ b/drivers/Makefile > @@ -5,6 +5,8 @@ > # Rewritten to use lists instead of if-statements. > # > > +obj-y+= bus/ > + > # GPIO must come after pinctrl as gpios may need to mux pins etc > obj-y+= pinctrl/ > obj-y+= gpio/ > diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig > new file mode 100644 > index 000..6270415 > --- /dev/null > +++ b/drivers/bus/Kconfig > @@ -0,0 +1,15 @@ > +# > +# Bus Devices > +# > + > +menu "Bus devices" > + > +config OMAP_OCP2SCP > + tristate "OMAP OCP2SCP DRIVER" > + help > + Driver to enable ocp2scp module which transforms ocp interface > + protocol to scp protocol. In OMAP4, USB PHY is connected via > + OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via > + OCP2SCP. > + > +endmenu > diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile > new file mode 100644 > index 000..0ec50bc > --- /dev/null > +++ b/drivers/bus/Makefile > @@ -0,0 +1,5 @@ > +# > +# Makefile for the bus drivers. > +# > + > +obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o > diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c > new file mode 100644 > index 000..881d5bb > --- /dev/null > +++ b/drivers/bus/omap-ocp2scp.c > @@ -0,0 +1,88 @@ > +/* > + * omap-ocp2scp.c - transform ocp interface protocol to scp protocol > + * > + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * Author: Kishon Vijay Abraham I > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +static int ocp2scp_remove_devices(struct device *dev, void *c) > +{ > + struct platform_device *pdev = to_platform_device(dev); > + > + platform_device_unregister(pdev); > + > + return 0; > +} > + > +static int __devinit omap_ocp2scp_probe(struct platform_device *pdev) > +{ > + int ret; > + struct device_node *np = pdev->dev.of_node; > + > + if (np) { > + ret = of_platform_populate(np, NULL, NULL, &pdev->dev); > + if (ret) { > + dev_err(&pdev->d
Re: [PATCH] arm/dts: AM33XX: Set the default status of module to "disabled" state
On Monday 06 August 2012, Vaibhav Hiremath wrote: > Ideally in common SoC dtsi file we should set all modules > to "disabled" state and it should get enabled in respective > EVM/Board dts file as per usage. > > This patch sets default status of all modules to "disabled" > state in am33xx.dtsi file, and as per board requirement, enabled > in board dts file (like, bone, evm, etc...). > > Signed-off-by: Vaibhav Hiremath > Cc: Benoit Cousson > Cc: Grant Likely > Cc: Arnd Bergmann > CC: Tony Lindgren Acked-by: Arnd Bergmann -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm/dts: AM33XX: Set the default status of module to "disabled" state
Ideally in common SoC dtsi file we should set all modules to "disabled" state and it should get enabled in respective EVM/Board dts file as per usage. This patch sets default status of all modules to "disabled" state in am33xx.dtsi file, and as per board requirement, enabled in board dts file (like, bone, evm, etc...). Signed-off-by: Vaibhav Hiremath Cc: Benoit Cousson Cc: Grant Likely Cc: Arnd Bergmann CC: Tony Lindgren --- This patch is tested on BeagleBone platform. arch/arm/boot/dts/am335x-bone.dts |6 ++ arch/arm/boot/dts/am335x-evm.dts |6 ++ arch/arm/boot/dts/am33xx.dtsi |9 + 3 files changed, 21 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts index a9af4db..df672b4 100644 --- a/arch/arm/boot/dts/am335x-bone.dts +++ b/arch/arm/boot/dts/am335x-bone.dts @@ -17,4 +17,10 @@ device_type = "memory"; reg = <0x8000 0x1000>; /* 256 MB */ }; + + ocp { + uart1: serial@44E09000 { + status = "okay"; + }; + }; }; diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts index d6a97d9..00bbae8 100644 --- a/arch/arm/boot/dts/am335x-evm.dts +++ b/arch/arm/boot/dts/am335x-evm.dts @@ -17,4 +17,10 @@ device_type = "memory"; reg = <0x8000 0x1000>; /* 256 MB */ }; + + ocp { + uart1: serial@44E09000 { + status = "okay"; + }; + }; }; diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 59509c4..5f6c8e3 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -102,36 +102,42 @@ compatible = "ti,omap3-uart"; ti,hwmods = "uart1"; clock-frequency = <4800>; + status = "disabled"; }; uart2: serial@48022000 { compatible = "ti,omap3-uart"; ti,hwmods = "uart2"; clock-frequency = <4800>; + status = "disabled"; }; uart3: serial@48024000 { compatible = "ti,omap3-uart"; ti,hwmods = "uart3"; clock-frequency = <4800>; + status = "disabled"; }; uart4: serial@481A6000 { compatible = "ti,omap3-uart"; ti,hwmods = "uart4"; clock-frequency = <4800>; + status = "disabled"; }; uart5: serial@481A8000 { compatible = "ti,omap3-uart"; ti,hwmods = "uart5"; clock-frequency = <4800>; + status = "disabled"; }; uart6: serial@481AA000 { compatible = "ti,omap3-uart"; ti,hwmods = "uart6"; clock-frequency = <4800>; + status = "disabled"; }; i2c1: i2c@44E0B000 { @@ -139,6 +145,7 @@ #address-cells = <1>; #size-cells = <0>; ti,hwmods = "i2c1"; + status = "disabled"; }; i2c2: i2c@4802A000 { @@ -146,6 +153,7 @@ #address-cells = <1>; #size-cells = <0>; ti,hwmods = "i2c2"; + status = "disabled"; }; i2c3: i2c@4819C000 { @@ -153,6 +161,7 @@ #address-cells = <1>; #size-cells = <0>; ti,hwmods = "i2c3"; + status = "disabled"; }; }; }; -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] drivers: bus: add a new driver for omap-ocp2scp
Adds a new driver *omap-ocp2scp*. This driver takes the responsibility of creating all the devices that is connected to OCP2SCP. In the case of OMAP4, USB2PHY is connected to ocp2scp. This also includes device tree support for ocp2scp driver and the documentation with device tree binding information is updated. Acked-by: Felipe Balbi Acked-by: Arnd Bergmann Signed-off-by: Kishon Vijay Abraham I --- .../devicetree/bindings/bus/omap-ocp2scp.txt | 10 +++ drivers/Kconfig|2 + drivers/Makefile |2 + drivers/bus/Kconfig| 15 drivers/bus/Makefile |5 ++ drivers/bus/omap-ocp2scp.c | 88 6 files changed, 122 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/omap-ocp2scp.txt create mode 100644 drivers/bus/Kconfig create mode 100644 drivers/bus/Makefile create mode 100644 drivers/bus/omap-ocp2scp.c diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt new file mode 100644 index 000..d2fe064 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt @@ -0,0 +1,10 @@ +* OMAP OCP2SCP - ocp interface to scp interface + +properties: +- compatible : Should be "ti,omap-ocp2scp" +- #address-cells, #size-cells : Must be present if the device has sub-nodes +- ranges : the child address space are mapped 1:1 onto the parent address space +- ti,hwmods : must be "ocp2scp_usb_phy" + +Sub-nodes: +All the devices connected to ocp2scp are described using sub-node to ocp2scp diff --git a/drivers/Kconfig b/drivers/Kconfig index ece958d..324e958 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -2,6 +2,8 @@ menu "Device Drivers" source "drivers/base/Kconfig" +source "drivers/bus/Kconfig" + source "drivers/connector/Kconfig" source "drivers/mtd/Kconfig" diff --git a/drivers/Makefile b/drivers/Makefile index 5b42184..f8cdeeb 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -5,6 +5,8 @@ # Rewritten to use lists instead of if-statements. # +obj-y += bus/ + # GPIO must come after pinctrl as gpios may need to mux pins etc obj-y += pinctrl/ obj-y += gpio/ diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig new file mode 100644 index 000..6270415 --- /dev/null +++ b/drivers/bus/Kconfig @@ -0,0 +1,15 @@ +# +# Bus Devices +# + +menu "Bus devices" + +config OMAP_OCP2SCP + tristate "OMAP OCP2SCP DRIVER" + help + Driver to enable ocp2scp module which transforms ocp interface + protocol to scp protocol. In OMAP4, USB PHY is connected via + OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via + OCP2SCP. + +endmenu diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile new file mode 100644 index 000..0ec50bc --- /dev/null +++ b/drivers/bus/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for the bus drivers. +# + +obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c new file mode 100644 index 000..881d5bb --- /dev/null +++ b/drivers/bus/omap-ocp2scp.c @@ -0,0 +1,88 @@ +/* + * omap-ocp2scp.c - transform ocp interface protocol to scp protocol + * + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * Author: Kishon Vijay Abraham I + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#include +#include +#include +#include +#include +#include + +static int ocp2scp_remove_devices(struct device *dev, void *c) +{ + struct platform_device *pdev = to_platform_device(dev); + + platform_device_unregister(pdev); + + return 0; +} + +static int __devinit omap_ocp2scp_probe(struct platform_device *pdev) +{ + int ret; + struct device_node *np = pdev->dev.of_node; + + if (np) { + ret = of_platform_populate(np, NULL, NULL, &pdev->dev); + if (ret) { + dev_err(&pdev->dev, "failed to add resources for ocp2scp child\n"); + goto err0; + } + } + pm_runtime_enable(&pdev->dev); + + return 0; + +err0: + device_for_each_child(&pdev->dev, NULL, ocp2scp_remove_devices); + + return ret; +} + +static int __devexit omap_ocp2scp_remove(struct platform_device *pdev) +{
[PATCH v3 0/2] omap: add ocp2scp as a bus driver
This patch series is done as a preparatory step for adding phy drivers for dwc3 and musb. This series adds a new driver for ocp2scp (only dt) to which phy drivers are connected. Since currently there is no generic way to create a child device along with doing a pm_runtime_enable (the exact requirement for ocp2scp), I'm creating a separate driver for ocp2scp. Changes from v2: Fixed Felipe's comments to avoid using arch_initcall and make dependent drivers return -EPROBE_DEFER case this isn't ready yet. Changes from v1: Fixed Sergei's comments to remove the address in the node name of ocp2scp since the ocp2scp node doesn't have a reg property. Changes from [RFC PATCH v2 0/2] omap: add ocp2scp as a misc driver: Created a new folder drivers/bus and moved ocp2scp driver from misc to drivers/bus. This patch was developed and tested on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git Kishon Vijay Abraham I (2): drivers: bus: add a new driver for omap-ocp2scp arm/dts: omap4: Add ocp2scp data .../devicetree/bindings/bus/omap-ocp2scp.txt | 10 +++ arch/arm/boot/dts/omap4.dtsi |8 ++ drivers/Kconfig|2 + drivers/Makefile |2 + drivers/bus/Kconfig| 15 drivers/bus/Makefile |5 ++ drivers/bus/omap-ocp2scp.c | 88 7 files changed, 130 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/omap-ocp2scp.txt create mode 100644 drivers/bus/Kconfig create mode 100644 drivers/bus/Makefile create mode 100644 drivers/bus/omap-ocp2scp.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] arm/dts: omap4: Add ocp2scp data
Add ocp2scp data node in omap4 device tree file. Acked-by: Felipe Balbi Signed-off-by: Kishon Vijay Abraham I --- arch/arm/boot/dts/omap4.dtsi |8 1 file changed, 8 insertions(+) diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index 04cbbcb..8a780b2 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -295,5 +295,13 @@ interrupt-parent = <&gic>; ti,hwmods = "dmic"; }; + + ocp2scp { + compatible = "ti,omap-ocp2scp"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + ti,hwmods = "ocp2scp_usb_phy"; + }; }; }; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: OMAPFB: fix framebuffer console colors
On Mon, 2012-08-06 at 13:15 +0300, Igor Grinberg wrote: > On 08/06/12 09:00, Tomi Valkeinen wrote: > > On Sat, 2012-08-04 at 19:19 +0300, Grazvydas Ignotas wrote: > >> omapfb does not currently set pseudo palette correctly for color depths > >> above 16bpp, making red text invisible, command like > >> echo -e '\e[0;31mRED' > /dev/tty1 > >> will display nothing on framebuffer console in 24bpp mode. > >> This is because temporary variable is declared incorrectly, fix it. > > > > Thanks, applied to OMAP DSS tree. > > Is it also applicable to stable? > If yes, Tomi, can you please add the Cc tag? Yes, the bug has been there from the beginning. I can add the Cc tag. But I wonder is it enough just to have the tag, or should I also send the patch forward? And does it only get applied to the latest stable tree, not the earlier ones? Tomi signature.asc Description: This is a digitally signed message part
Re: OMAP3 Overo: Crash on boot with Linus' master
Hi, This problem exists on v3.6-rc1 also. I bisected the crash below to: f1d2c07d331f717da79a42952be7dc1c0d35f846 It's a merge commit, Merge tag 'boards' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc I'm not sure why bisect did came up with a merge commit, instead of the actual code commit, though. I don't see any changes in overo's board file that could cause this, so could it be an omap3 wide problem? Although I would think somebody else had noticed it also, then. Tomi On Thu, 2012-08-02 at 13:30 +0300, Tomi Valkeinen wrote: > Hi, > > I'm unable to boot with Linus' master branch from today on OMAP3 Overo > board. Below is the full boot log. Something related to GPIOs and IRQs, > perhaps. I've also attached my kernel conf. OMAP4 Blaze works ok, and > kernel v3.5 works ok. > > The crash looks very similar to what is mentioned in a post from March > "GPIO abort on 3630/Zoom3". > > Tomi > > > �t�bPH�UI����**S��012.04.01-00958-g7d2d58b (Jun 26 2012 - 10:37:53) > OMAP SD/MMC: 0 > reading u-boot.img > reading u-boot.img > > > U-Boot 2012.04.01-00958-g7d2d58b (Jun 26 2012 - 10:37:53) > > OMAP3503-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz > Gumstix Overo board + LPDDR/NAND > I2C: ready > DRAM: 256 MiB > NAND: 256 MiB > MMC: OMAP SD/MMC: 0 > In:serial > Out: serial > Err: serial > Board revision: 0 > Direct connection on mmc2 > No EEPROM on expansion board > Die ID #4968000204013ef00a01100a > Net: No ethernet found. > Hit any key to stop autoboot: 3 2 1 0 > reading uImage > > 4107144 bytes read > ## Booting kernel from Legacy Image at 8200 ... >Image Name: Linux-3.5.0-09139-g1a9b499 >Image Type: ARM Linux Kernel Image (uncompressed) >Data Size:4107080 Bytes = 3.9 MiB >Load Address: 80008000 >Entry Point: 80008000 >Verifying Checksum ... OK >Loading Kernel Image ... OK > OK > > Starting kernel ... > > Uncompressing Linux... done, booting the kernel. > [0.00] Booting Linux on physical CPU 0 > [0.00] Linux version 3.5.0-09139-g1a9b499 (tomba@deskari) (gcc > version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #12 SMP Thu Aug 2 13:20:08 > EEST 2012 > [0.00] CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7d > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing > instruction cache > [0.00] Machine: Gumstix Overo > [0.00] Reserving 10485760 bytes SDRAM for VRAM > [0.00] Memory policy: ECC disabled, Data cache writeback > [0.00] On node 0 totalpages: 62720 > [0.00] free_area_init_node: node 0, pgdat c07dc800, node_mem_map > c0d38000 > [0.00] Normal zone: 512 pages used for memmap > [0.00] Normal zone: 0 pages reserved > [0.00] Normal zone: 62208 pages, LIFO batch:15 > [0.00] OMAP3503 ES2.1 (l2cache neon isp ) > [0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/600 MHz > [0.00] PERCPU: Embedded 9 pages/cpu @c0f3e000 s12736 r8192 d15936 > u36864 > [0.00] pcpu-alloc: s12736 r8192 d15936 u36864 alloc=9*4096 > [0.00] pcpu-alloc: [0] 0 > [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total > pages: 62208 > [0.00] Kernel command line: g_ether.host_addr=86:6a:a8:ad:e0:78 > g_ether.dev_addr=02:51:c6:e2:c3:d3 console=ttyO2,115200 root=/dev/nfs > nfsroot=/tftpboot/rootfs,tcp,nolock,rsize=1024,wsize=1024 > ip=192.168.2.15:192.168.2.14usb0: vram=10M loglevel=9 no_console_suspend > [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) > [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) > [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) > [0.00] Memory: 245MB = 245MB total > [0.00] Memory: 235032k/235032k available, 27112k reserved, 0K highmem > [0.00] Virtual kernel memory layout: > [0.00] vector : 0x - 0x1000 ( 4 kB) > [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) > [0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB) > [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) > [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) > [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) > [0.00] .text : 0xc0008000 - 0xc06f1304 (7077 kB) > [0.00] .init : 0xc06f2000 - 0xc07401c0 ( 313 kB) > [0.00] .data : 0xc0742000 - 0xc07df1c0 ( 629 kB) > [0.00].bss : 0xc07df1e4 - 0xc0d37c0c (5475 kB) > [0.00] Hierarchical RCU implementation. > [0.00]RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. > [0.00] NR_IRQS:474 > [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 > interrupts > [0.00] Total of 96 interrupts on 1 active controller > [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz > [0.00
Re: [PATCH] OMAPDSS: OMAPFB: fix framebuffer console colors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/06/12 09:00, Tomi Valkeinen wrote: > On Sat, 2012-08-04 at 19:19 +0300, Grazvydas Ignotas wrote: >> omapfb does not currently set pseudo palette correctly for color depths >> above 16bpp, making red text invisible, command like >> echo -e '\e[0;31mRED' > /dev/tty1 >> will display nothing on framebuffer console in 24bpp mode. >> This is because temporary variable is declared incorrectly, fix it. > > Thanks, applied to OMAP DSS tree. Is it also applicable to stable? If yes, Tomi, can you please add the Cc tag? Thanks - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQH5lGAAoJEBDE8YO64Efak/YP/3APyqQ3d4TLB8sG7oHSF/Vn zmwMl8kH2B70WIPWU1iIExodfrDd3Gms8UeGqjhj04kLHvqYUs3/lepTA6gkEnH0 U4vyO6WTMYtWBHUGXJhZk5GpOByn4aLdk4UGV22NNMmUI/xWqcVGSnntLjmRcUyu Y1JRQqhlrXrYXH5A866J7yrwSwhhZ/sZXs4k1N5keCNaT8ieqn0HXvu02ma7bjF7 SvhWDPNOOWUuEOGsope8F2A8Mot4ToManqRHDTUSnq/cpWziGiy6/7I7ngVIMUgD /nmiLISgU72wkoNDl0AxGQDVQ8HFUspzGe2e12VliG+ErmFkGfKr9XdI6fx7gKh2 ks7qL+uMBau9MpWYcRPhPvYrVn7tg6V9seN2/bG5gp2IgMFbu1wmibVMNyCGhQeX 1OhshGEKeR58s+R8KZ7+UzbjspDuSnlnFH2wVbbb3wr30Swc6VZA/rWlwNg3Bgz5 /h63a5SOwTF9nmV+3/O/ky4gyMORbbJyOBK/xWVmQkZ4lNNW02RnMaa6KP8fKlbb Cc7x1P07jcMH83LKGyyhsvZrK/4JCloYEDTvuYHprf9Wb+WsXNCLsRiYMngUIwPc eLrBVOlELQvS237eGAwMIfo4Lm3tI3WMyr8cjGy2aRqn8voDJW+qEN2NUNwkNDqS kGYrOE0t5VRNx5egrv+J =kydA -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 4/8] ARM: OMAP3: add manual control for mpu / core pwrdm usecounting
Hi Tero, On Mon, Jul 30, 2012 at 10:40 AM, Tero Kristo wrote: > On Fri, 2012-07-27 at 12:36 -0700, Kevin Hilman wrote: >> Tero Kristo writes: >> >> > mpu / core powerdomain usecounts are now statically increased >> > by 1 during MPU activity. This allows the domains to reflect >> > actual usage, and will allow the usecount to reach 0 just before >> > all CPUs are ready to idle. Proper powerdomain usecounts are >> > propageted to voltagedomain level also, and will allow vc >> > callbacks to be triggered at right point of time. >> > >> > Signed-off-by: Tero Kristo >> > Cc: Paul Walmsley >> > Cc: Kevin Hilman >> >> IMO, the idea is fine, but I'm not crazy about the implementation in >> powerdomain.c, which is meant for pwrdm generic code. In particular, >> I'm not crazy about the pwrdm lookups in powerdomain.c. >> >> Since pm.c already has references to mpu_pwrdm and core_pwrdm, why >> not just add the pwrdm_clkdm_enable/disable calls directly in pm.c > > I think this was how the patch was in some earlier rev but I thought I'd > try to be more clever with this. :) I can revert the implementation back > to this. Furthermore after the changes in pre/post transitions [1], some more checks will be needed to identify the transitions on the mpu and core power domains. [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=e055548953355b6e69c56f9e54388845b29b4e97 Regards, Jean > >> Also, the changelog should be a bit more specific about why CORE >> powerdomain is also handled here when most of the code only talks about >> the CPU. > > Yea, I'll add some beef to this also. > > -Tero > > -- > 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 v6 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
On Mon, Aug 06, 2012 at 03:14:42PM +0530, ABRAHAM, KISHON VIJAY wrote: > >> >> +static int omap_usb2_runtime_resume(struct device *dev) > >> >> +{ > >> >> + u32 ret = 0; > >> >> + struct platform_device *pdev = to_platform_device(dev); > >> >> + struct omap_usb *phy = platform_get_drvdata(pdev); > >> >> + > >> >> + ret = clk_enable(phy->wkupclk); > >> >> + if (ret < 0) > >> >> + dev_err(phy->dev, "Failed to enable wkupclk %d\n", ret); > >> >> + > >> >> + return ret; > >> >> +} > >> >> + > >> >> +static const struct dev_pm_ops omap_usb2_pm_ops = { > >> >> + SET_RUNTIME_PM_OPS(omap_usb2_runtime_suspend, > >> >> omap_usb2_runtime_resume, > >> >> + NULL) > >> > > >> > only runtime ? What about static suspend ? We need this to work also > >> > after a traditional echo mem > /sys/power/state ;-) > >> > >> The static suspend case is handled by users of this phy using > >> set_suspend hooks. > > > > I'm not sure if that's too wise, what if your user enabled USB, but > > for whatever reason loaded only the phy driver and not musb or dwc3. It > > will fail, right ? > > The enabling and disabling of phy is solely governed by usb controller > driver (musb/dwc3). So if you dont have musb/dwc3 loaded, the phy will > be for sure disabled. fair enough... that's ok then ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH v6 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
Hi Felipe, On Mon, Aug 6, 2012 at 2:19 PM, Felipe Balbi wrote: > Hi, > > On Fri, Aug 03, 2012 at 08:01:44PM +0530, ABRAHAM, KISHON VIJAY wrote: >> >> + return 0; >> >> +} >> >> + >> >> +#ifdef CONFIG_PM_RUNTIME >> >> + >> >> +static int omap_usb2_runtime_suspend(struct device *dev) >> >> +{ >> >> + struct platform_device *pdev = to_platform_device(dev); >> >> + struct omap_usb *phy = platform_get_drvdata(pdev); >> >> + >> >> + clk_disable(phy->wkupclk); >> > >> > weird. I would expect the wakeup clock to be enabled on suspend and >> > disabled on resume. Isn't this causing any unbalanced disable warnings ? >> >> Even I was expecting the wakeup clock to be enabled on suspend but if >> we have this enabled coreaon domain is never >> gated and core does not hit low power state. btw Why do think this is >> unbalanced? > > because you never do a clk_enable() on probe(), so on your first > suspend, you will disable the clock without having enabled it before, > no? Unless pm_runtime forces a runtime_resume() when you call > pm_runtime_enable()... > >> >> +static int omap_usb2_runtime_resume(struct device *dev) >> >> +{ >> >> + u32 ret = 0; >> >> + struct platform_device *pdev = to_platform_device(dev); >> >> + struct omap_usb *phy = platform_get_drvdata(pdev); >> >> + >> >> + ret = clk_enable(phy->wkupclk); >> >> + if (ret < 0) >> >> + dev_err(phy->dev, "Failed to enable wkupclk %d\n", ret); >> >> + >> >> + return ret; >> >> +} >> >> + >> >> +static const struct dev_pm_ops omap_usb2_pm_ops = { >> >> + SET_RUNTIME_PM_OPS(omap_usb2_runtime_suspend, >> >> omap_usb2_runtime_resume, >> >> + NULL) >> > >> > only runtime ? What about static suspend ? We need this to work also >> > after a traditional echo mem > /sys/power/state ;-) >> >> The static suspend case is handled by users of this phy using >> set_suspend hooks. > > I'm not sure if that's too wise, what if your user enabled USB, but > for whatever reason loaded only the phy driver and not musb or dwc3. It > will fail, right ? The enabling and disabling of phy is solely governed by usb controller driver (musb/dwc3). So if you dont have musb/dwc3 loaded, the phy will be for sure disabled. Thanks Kishon -- 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] driver: misc: bmp085: remove "of_match_table" property.
On Mon, Aug 06, 2012 at 02:58:44PM +0530, Sourav Poddar wrote: > There is an automatic binding done for I2C devices in the of_i2c core > code. So, DT will be able to bind to any I2C device using the > already existing table: MODULE_DEVICE_TABLE(i2c, bmp085_id). > > Tested on omap5430 evm. > > Cc: Benoit Cousson > Cc: Felipe Balbi > Cc: Santosh Shilimkar > Signed-off-by: Sourav Poddar Acked-by: Felipe Balbi > --- > drivers/misc/bmp085-i2c.c |7 --- > 1 files changed, 0 insertions(+), 7 deletions(-) > > diff --git a/drivers/misc/bmp085-i2c.c b/drivers/misc/bmp085-i2c.c > index 9943971..a4f33c9 100644 > --- a/drivers/misc/bmp085-i2c.c > +++ b/drivers/misc/bmp085-i2c.c > @@ -57,12 +57,6 @@ static int bmp085_i2c_remove(struct i2c_client *client) > return bmp085_remove(&client->dev); > } > > -static const struct of_device_id bmp085_of_match[] = { > - { .compatible = "bosch,bmp085", }, > - { }, > -}; > -MODULE_DEVICE_TABLE(of, bmp085_of_match); > - > static const struct i2c_device_id bmp085_id[] = { > { BMP085_NAME, 0 }, > { "bmp180", 0 }, > @@ -74,7 +68,6 @@ static struct i2c_driver bmp085_i2c_driver = { > .driver = { > .owner = THIS_MODULE, > .name = BMP085_NAME, > - .of_match_table = bmp085_of_match > }, > .id_table = bmp085_id, > .probe = bmp085_i2c_probe, > -- > 1.7.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- balbi signature.asc Description: Digital signature
[PATCH] driver: misc: bmp085: remove "of_match_table" property.
There is an automatic binding done for I2C devices in the of_i2c core code. So, DT will be able to bind to any I2C device using the already existing table: MODULE_DEVICE_TABLE(i2c, bmp085_id). Tested on omap5430 evm. Cc: Benoit Cousson Cc: Felipe Balbi Cc: Santosh Shilimkar Signed-off-by: Sourav Poddar --- drivers/misc/bmp085-i2c.c |7 --- 1 files changed, 0 insertions(+), 7 deletions(-) diff --git a/drivers/misc/bmp085-i2c.c b/drivers/misc/bmp085-i2c.c index 9943971..a4f33c9 100644 --- a/drivers/misc/bmp085-i2c.c +++ b/drivers/misc/bmp085-i2c.c @@ -57,12 +57,6 @@ static int bmp085_i2c_remove(struct i2c_client *client) return bmp085_remove(&client->dev); } -static const struct of_device_id bmp085_of_match[] = { - { .compatible = "bosch,bmp085", }, - { }, -}; -MODULE_DEVICE_TABLE(of, bmp085_of_match); - static const struct i2c_device_id bmp085_id[] = { { BMP085_NAME, 0 }, { "bmp180", 0 }, @@ -74,7 +68,6 @@ static struct i2c_driver bmp085_i2c_driver = { .driver = { .owner = THIS_MODULE, .name = BMP085_NAME, - .of_match_table = bmp085_of_match }, .id_table = bmp085_id, .probe = bmp085_i2c_probe, -- 1.7.1 -- 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 v6 00/11] omap: musb: Add device tree support
On Mon, Aug 6, 2012 at 2:22 PM, Felipe Balbi wrote: > Hi, > > On Mon, Jul 30, 2012 at 02:39:49PM +0530, Kishon Vijay Abraham I wrote: >> This patch series adds device tree support for MUSB and device >> tree support for all the related modules to get MUSB working in >> OMAP platform. >> >> A new omap-usb2 phy driver has been added (with only dt suppport) >> to perform phy configurations. Previously this configuration was >> performed by twl6030, using pdata function pointers. >> >> With the addition of omap-usb2 to perform phy configurations, >> twl6030 is made as a comparator driver to detect VBUS and ID events >> and notify it to the glue layer. >> >> musb core is _NOT_ yet converted to support device tree support as it >> would need lot of driver re-design because of its enormous use of >> function pointers. That will be in _TO DO_ list. >> >> Changes from v5: >> minor cleanups like checking for return value in get_sync and few changes >> in the documentation has been done. >> >> Changes from v4: >> duplicate getting of 'mode' property is removed in omap-musb glue. >> >> Changes from v3: >> remove the address in the node name of usb_otg_hs since the usb_otg_hs >> node doesn't have a reg property. Thanks Ajay Gupta for finding this. >> >> Changes from v2: >> Fixed Sergei's comment to remove *0x* prefix in usb2phy@0x4a0ad080 >> >> Changes from v1: >> * Fixed Rajendra Nayak comments (regulator naming, compatible naming of >> musb and other minor cleanups.) >> * It's agreed to have ocp2scp in drivers/bus and usb2 phy is a child of >> ocp2scp, the documentation is updated accordingly. >> >> Changes from RFC: >> Removed the dependency on [RFC PATCH 00/11] OMAP System Control Module. >> Writing to control module register is now handled in otg driver itself. >> Once the system control module driver get upstreamed, I'll send a patch >> to make use of API's in control module driver to write to control >> module register. >> >> This series was developed on >> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv >> >> This patch series depends on >> [PATCH 0/2] omap: add ocp2scp as a bus driver >> >> Performed MUSB device mode testing on OMAP4 panda, OMAP4 SDP >> and OMAP3 beagle. >> >> Kishon Vijay Abraham I (11): >> drivers: usb: otg: add a new driver for omap usb2 phy >> arm/dts: omap: Add omap-usb2 dt data >> drivers: usb: otg: make twl6030_usb as a comparator driver to >> omap_usb2 >> arm: omap: hwmod: add a new addr space in otg for writing to control >> module >> drivers: usb: twl6030: Add dt support for twl6030 usb >> arm/dts: Add twl6030-usb data >> drivers: usb: twl4030: Add device tree support for twl4030 usb >> arm/dts: Add twl4030-usb data >> drivers: usb: musb: Add device tree support for omap musb glue >> arm/dts: omap: Add usb_otg and glue data >> arm: omap: phy: remove unused functions from omap-phy-internal.c > > When you send your next series, can you please split the stuff based on > their dependencies or at least note here what depends on what ? I mean, > I cannot take the DT patches without an Acked-by Grant and Tony, but the > drivers themselves I could take queue them since they're already in good > shape ;-) > > Maybe just start the series with patches without dependencies on one > another, and the rest of the series would be ones that need to go > together, or something. That'll help me ;-) Ok Felipe. Thanks Kishon -- 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 v6 00/11] omap: musb: Add device tree support
Hi, On Mon, Jul 30, 2012 at 02:39:49PM +0530, Kishon Vijay Abraham I wrote: > This patch series adds device tree support for MUSB and device > tree support for all the related modules to get MUSB working in > OMAP platform. > > A new omap-usb2 phy driver has been added (with only dt suppport) > to perform phy configurations. Previously this configuration was > performed by twl6030, using pdata function pointers. > > With the addition of omap-usb2 to perform phy configurations, > twl6030 is made as a comparator driver to detect VBUS and ID events > and notify it to the glue layer. > > musb core is _NOT_ yet converted to support device tree support as it > would need lot of driver re-design because of its enormous use of > function pointers. That will be in _TO DO_ list. > > Changes from v5: > minor cleanups like checking for return value in get_sync and few changes > in the documentation has been done. > > Changes from v4: > duplicate getting of 'mode' property is removed in omap-musb glue. > > Changes from v3: > remove the address in the node name of usb_otg_hs since the usb_otg_hs > node doesn't have a reg property. Thanks Ajay Gupta for finding this. > > Changes from v2: > Fixed Sergei's comment to remove *0x* prefix in usb2phy@0x4a0ad080 > > Changes from v1: > * Fixed Rajendra Nayak comments (regulator naming, compatible naming of > musb and other minor cleanups.) > * It's agreed to have ocp2scp in drivers/bus and usb2 phy is a child of > ocp2scp, the documentation is updated accordingly. > > Changes from RFC: > Removed the dependency on [RFC PATCH 00/11] OMAP System Control Module. > Writing to control module register is now handled in otg driver itself. > Once the system control module driver get upstreamed, I'll send a patch > to make use of API's in control module driver to write to control > module register. > > This series was developed on > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv > > This patch series depends on > [PATCH 0/2] omap: add ocp2scp as a bus driver > > Performed MUSB device mode testing on OMAP4 panda, OMAP4 SDP > and OMAP3 beagle. > > Kishon Vijay Abraham I (11): > drivers: usb: otg: add a new driver for omap usb2 phy > arm/dts: omap: Add omap-usb2 dt data > drivers: usb: otg: make twl6030_usb as a comparator driver to > omap_usb2 > arm: omap: hwmod: add a new addr space in otg for writing to control > module > drivers: usb: twl6030: Add dt support for twl6030 usb > arm/dts: Add twl6030-usb data > drivers: usb: twl4030: Add device tree support for twl4030 usb > arm/dts: Add twl4030-usb data > drivers: usb: musb: Add device tree support for omap musb glue > arm/dts: omap: Add usb_otg and glue data > arm: omap: phy: remove unused functions from omap-phy-internal.c When you send your next series, can you please split the stuff based on their dependencies or at least note here what depends on what ? I mean, I cannot take the DT patches without an Acked-by Grant and Tony, but the drivers themselves I could take queue them since they're already in good shape ;-) Maybe just start the series with patches without dependencies on one another, and the rest of the series would be ones that need to go together, or something. That'll help me ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH v6 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
Hi, On Fri, Aug 03, 2012 at 08:01:44PM +0530, ABRAHAM, KISHON VIJAY wrote: > >> + return 0; > >> +} > >> + > >> +#ifdef CONFIG_PM_RUNTIME > >> + > >> +static int omap_usb2_runtime_suspend(struct device *dev) > >> +{ > >> + struct platform_device *pdev = to_platform_device(dev); > >> + struct omap_usb *phy = platform_get_drvdata(pdev); > >> + > >> + clk_disable(phy->wkupclk); > > > > weird. I would expect the wakeup clock to be enabled on suspend and > > disabled on resume. Isn't this causing any unbalanced disable warnings ? > > Even I was expecting the wakeup clock to be enabled on suspend but if > we have this enabled coreaon domain is never > gated and core does not hit low power state. btw Why do think this is > unbalanced? because you never do a clk_enable() on probe(), so on your first suspend, you will disable the clock without having enabled it before, no? Unless pm_runtime forces a runtime_resume() when you call pm_runtime_enable()... > >> +static int omap_usb2_runtime_resume(struct device *dev) > >> +{ > >> + u32 ret = 0; > >> + struct platform_device *pdev = to_platform_device(dev); > >> + struct omap_usb *phy = platform_get_drvdata(pdev); > >> + > >> + ret = clk_enable(phy->wkupclk); > >> + if (ret < 0) > >> + dev_err(phy->dev, "Failed to enable wkupclk %d\n", ret); > >> + > >> + return ret; > >> +} > >> + > >> +static const struct dev_pm_ops omap_usb2_pm_ops = { > >> + SET_RUNTIME_PM_OPS(omap_usb2_runtime_suspend, > >> omap_usb2_runtime_resume, > >> + NULL) > > > > only runtime ? What about static suspend ? We need this to work also > > after a traditional echo mem > /sys/power/state ;-) > > The static suspend case is handled by users of this phy using > set_suspend hooks. I'm not sure if that's too wise, what if your user enabled USB, but for whatever reason loaded only the phy driver and not musb or dwc3. It will fail, right ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/4] arm/dts: omap5-evm: Add I2C support
Hi, On Fri, Aug 03, 2012 at 09:22:19PM +0400, Sergei Shtylyov wrote: > Hello. > > On 08/03/2012 04:38 PM, Sourav Poddar wrote: > > > Add I2C data node in omap5 device tree file. > > > Tested on omap5430 sdp. > > > Cc: Benoit Cousson > > Cc: Felipe Balbi > > Cc: Santosh Shilimkar > > Acked-by: Felipe Balbi > > Signed-off-by: Sourav Poddar > > --- > > arch/arm/boot/dts/omap5.dtsi | 35 +++ > > 1 files changed, 35 insertions(+), 0 deletions(-) > > > diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi > > index 57e5270..6b68dfe 100644 > > --- a/arch/arm/boot/dts/omap5.dtsi > > +++ b/arch/arm/boot/dts/omap5.dtsi > > @@ -145,6 +145,41 @@ > > #interrupt-cells = <1>; > > }; > > > > + i2c1: i2c@4807 { > > + compatible = "ti,omap4-i2c"; > > + #address-cells = <1>; > > + #size-cells = <0>; > > + ti,hwmods = "i2c1"; > >Address postfix in the node name and no "reg" property? that's because of the ti,hwmods attribute. OMAP is still not entirely converted to DT and there's this weird ti,hwmods attribute. OMAP's hwmod framework will fill up register addresses, irqs, etc when the device is created. Oh well... -- balbi signature.asc Description: Digital signature
Re: [PATCH] hwmon: tmp102: Add device tree support
Hi Benoit, On Fri, Aug 3, 2012 at 8:26 PM, Benoit Cousson wrote: > Hi Sourav, > > On 08/03/2012 02:35 PM, Sourav Poddar wrote: >> update tmp102 temperature sensor to also use device tree. >> >> Cc: Benoit Cousson >> Cc: Felipe Balbi >> Cc: Santosh Shilimkar >> Acked-by: Felipe Balbi >> Signed-off-by: Sourav Poddar >> --- >> drivers/hwmon/tmp102.c | 14 +- >> 1 files changed, 13 insertions(+), 1 deletions(-) >> >> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c >> index 0d466b9..a8a9060 100644 >> --- a/drivers/hwmon/tmp102.c >> +++ b/drivers/hwmon/tmp102.c >> @@ -26,6 +26,7 @@ >> #include >> #include >> #include >> +#include >> >> #define DRIVER_NAME "tmp102" >> >> @@ -284,8 +285,19 @@ static const struct i2c_device_id tmp102_id[] = { >> }; >> MODULE_DEVICE_TABLE(i2c, tmp102_id); >> >> +#ifdef CONFIG_OF >> +static const struct of_device_id temperature_dt_match[] = { >> + { .compatible = "ti,tmp102" }, > > Are you sure this is needed for this device? > > There is an automatic binding done for I2C devices in the of_i2c core > code. So in theory, DT will be able to bind to any I2C device using the > already existing table: MODULE_DEVICE_TABLE(i2c, tmp102_id). > > So I think this patch should not be needed. > Indeed. Checked it just now, this patch is not required and the already existing table is enough for the device to work fine. Thanks for the information. This patch is abandoned. ~Sourav > Regards, > Benoit > -- 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] mfd/regulator: tps65217: Move regulator plat data handling to regulator
+stable Hi Samuel, On Wed, Aug 01, 2012 at 10:55:26, AnilKumar, Chimata wrote: > Hi Samuel, > > On Tue, Jul 31, 2012 at 20:00:21, AnilKumar, Chimata wrote: > > Hi Samuel, > > > > On Fri, Jul 27, 2012 at 18:18:17, Samuel Ortiz wrote: > > > Hi Anilkumar, > > > > > > On Fri, Jul 20, 2012 at 03:00:01PM +0530, AnilKumar Ch wrote: > > > > Regulator platform data handling was mistakenly added to MFD > > > > driver. So we will see build errors if we compile MFD drivers > > > > without CONFIG_REGULATOR. This patch moves regulator platform > > > > data handling from TPS65217 MFD driver to regulator driver. > > > > > > > > This makes MFD driver independent of REGULATOR framework so > > > > build error is fixed if CONFIG_REGULATOR is not set. > > > > > > > > drivers/built-in.o: In function `tps65217_probe': > > > > tps65217.c:(.devinit.text+0x13e37): undefined reference > > > > to `of_regulator_match' > > > > > > > > This patch is based on linux-next (20120720) tree > > > > > > > > Signed-off-by: AnilKumar Ch > > > > --- > > > > drivers/mfd/tps65217.c | 130 > > > > +++- > > > > drivers/regulator/tps65217-regulator.c | 124 > > > > ++ > > > > include/linux/mfd/tps65217.h | 12 ++- > > > > 3 files changed, 161 insertions(+), 105 deletions(-) > > > It doesn't apply to my for-next branch. Could you please re-send this one > > > after the merge window is closed ? I'll push that as part of the MFD > > > fixes for > > > 3.6. > > > > > > > I fetch regulator tree and applied on top of for-next branch and it is > > cleanly > > applied. > > > > My bad I picked up wrong tree, I will send the new version (if require) based > on > "MFD for-next" tree once the merge window closed. > This patch is applied on top of your "MFD master" branch. Could you please pull this patch ASAP, this patch fixs the build break. Thanks AnilKumar -- 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