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 zumeng.c...@windriver.com
Cc: Arnd Bergmann a...@arndb.de
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
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
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 j...@terrafix.co.uk 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: 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 arc...@ti.com 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: [PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
* Hiremath, Vaibhav hvaib...@ti.com [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: [GIT PULL] ARM: OMAP5: Add minimal OMAP5 SOC support for 3.6
* Shilimkar, Santosh santosh.shilim...@ti.com [120726 00:27]: On Tue, Jul 10, 2012 at 10:33 AM, Tony Lindgren t...@atomide.com wrote: * Santosh Shilimkar santosh.shilim...@ti.com [120709 08:07]: Tony, Please pull below OMAP5 SOC minimal support. It is generated against the cleanup-part2 branch of yours. As you suggested, I have dropped CK_54XX flag changes to avoid conflicts. OK seems to merge fine now, pulled into devel-omap5. Now OMAP5 support appearing in mainline. In case you would like to boot mainline on your OMAP5 board, you need to merge a OMAP5 SOC hwmod/clock data which is out of tree. I have put that on a branch and same is available [1]. Please note that the only DT boot supported. Nice to see it being a small set :) Have these changes been posted to the mailing lists for review? Regards, Tony [1] git://github.com/SantoshShilimkar/linux.git out-of-tree/omap5-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 1/1] ARM: OMAP3: igep0020: set GPIO mode for mux mcspi1_cs2 pin
* Javier Martinez Canillas jav...@dowhile0.org [120803 01:06]: I saw that Linus 3.6-rc1 has already been released and I didn't see this patch on it. Yes I wanted to wait for -rc1 to avoid complicating things during the merge window. So, this is a kindly reminder so you don't miss this patch :-) Applying into fixes, thanks for the patience. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 1/5] omap device tree changes for v3.6 merge window
* Tony Lindgren t...@atomide.com [120713 01:01]:
* Tony Lindgren t...@atomide.com [120712 23:46]:
* Mohammed, Afzal af...@ti.com [120712 23:19]:
Afzal Mohammed (1):
arm/dts: am33xx wdt node
The above patch seems to be an empty one, actual changes in it as in
original patch [1] is missing, same changes are shown below for your
reference [2].
Can you please do the needful so that the intended change of this
patch makes to mainline this merge window.
Argh. Thanks for letting me know. I must have something wrong with
my scripts when applying patches. We'll have to apply this as a fix.
Arnd and Olof, let me know if you want me to resubmit a new branch instead
of the already pulled devel-dt branch. That branch should not have other
dependencies as it's based on -rc5. Of course is it's buried into other
DT patches it's too late.
Now with -rc1 out, I'll queue the following fix.
Regards,
Tony
From: Afzal Mohammed af...@ti.com
Date: Wed, 4 Jul 2012 18:00:37 +0530
Subject: [PATCH] arm/dts: Fix am33xx wdt node
Add am33xx wdt node.
Signed-off-by: Afzal Mohammed af...@ti.com
[t...@atomide.com: I messed up and produced an empty commit db27ac80 with stg
apply]
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 59509c4..bd0cff3 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -154,5 +154,10 @@
#size-cells = 0;
ti,hwmods = i2c3;
};
+
+ wdt2: wdt@44e35000 {
+ compatible = ti,omap3-wdt;
+ ti,hwmods = wd_timer2;
+ };
};
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP5: Add minimal OMAP5 SOC support for 3.6
On Tue, Aug 7, 2012 at 12:30 PM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120726 00:27]: On Tue, Jul 10, 2012 at 10:33 AM, Tony Lindgren t...@atomide.com wrote: * Santosh Shilimkar santosh.shilim...@ti.com [120709 08:07]: Tony, Please pull below OMAP5 SOC minimal support. It is generated against the cleanup-part2 branch of yours. As you suggested, I have dropped CK_54XX flag changes to avoid conflicts. OK seems to merge fine now, pulled into devel-omap5. Now OMAP5 support appearing in mainline. In case you would like to boot mainline on your OMAP5 board, you need to merge a OMAP5 SOC hwmod/clock data which is out of tree. I have put that on a branch and same is available [1]. Please note that the only DT boot supported. Nice to see it being a small set :) Have these changes been posted to the mailing lists for review? Not yet. Benoit was looking into the database difference between the current and next version of the silicon. Since there is a difference between the data, the idea was to submit the final version of data to avoid potential huge patching. Regards santosh [1] git://github.com/SantoshShilimkar/linux.git out-of-tree/omap5-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
[PATCH] arm/dts: omap5: Add mmc controller nodes and board data
Add OMAP MMC related device tree data for OMAP5.
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts | 31 +++
arch/arm/boot/dts/omap5.dtsi| 31 +++
2 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 200c39a..7bb0c9d 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -17,4 +17,35 @@
device_type = memory;
reg = 0x8000 0x4000; /* 1 GB */
};
+
+ vmmcsd_fixed: fixedregulator-mmcsd {
+ compatible = regulator-fixed;
+ regulator-name = vmmcsd_fixed;
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
+ };
+};
+
+mmc1 {
+ vmmc-supply = vmmcsd_fixed;
+ bus-width = 4;
+};
+
+mmc2 {
+ vmmc-supply = vmmcsd_fixed;
+ bus-width = 8;
+ ti,non-removable;
+};
+
+mmc3 {
+ bus-width = 4;
+ ti,non-removable;
+};
+
+mmc4 {
+ status = disabled;
+};
+
+mmc5 {
+ status = disabled;
};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 57e5270..881d60c 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -180,5 +180,36 @@
ti,hwmods = uart6;
clock-frequency = 4800;
};
+
+ mmc1: mmc@4809c000 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ ti,needs-special-reset;
+ };
+
+ mmc2: mmc@480b4000 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc2;
+ ti,needs-special-reset;
+ };
+
+ mmc3: mmc@480ad000 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc3;
+ ti,needs-special-reset;
+ };
+
+ mmc4: mmc@480d1000 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc4;
+ ti,needs-special-reset;
+ };
+
+ mmc5: mmc@480d5000 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc5;
+ ti,needs-special-reset;
+ };
};
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP4: twl-common: Support for additional devices on i2c1 bus
* Peter Ujfalusi peter.ujfal...@ti.com [120723 01:52]: Hi Tony, On 07/13/2012 10:38 AM, Peter Ujfalusi wrote: On OMAP4 the i2c1 bus is dedicated for the PMIC and audio related devices. Manufacturers can opt to use different codec than twl6040 and also can add audio related IC to the bus (external amplifier for example on SDP4430). Make it possible to add differnet set of additional devices to i2c1 bus on OMAP4 boards. Would it be possible to queue this patch for 3.6? Sorry things were getting already too complex for v3.6 merge window.. So v3.7 it will be. Looks like this need to be updated against v3.6-rc1 to apply. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP2+: Fix random config build break with !ARM_CPU_SUSPEND
* Santosh Shilimkar santosh.shilim...@ti.com [120713 03:50]: The random config builds with PM and !ARM_CPU_SUSPEND breaks with below error on omap2plus_defconfig. arch/arm/mach-omap2/sleep44xx.S:323: undefined reference to `cpu_resume' arch/arm/mach-omap2/omap-mpuss-lowpower.c:278: undefined reference to `cpu_suspend' This is because recently merged OMAP5 platform shares the common files with OMAP4 but doesn't select ARM_CPU_SUSPEND. Without the ARM_CPU_SUSPEND the sleep code is meaningless. Fix the same by adding ARM_CPU_SUSPEND for OMAP5. The suggestion came from Russell King in an off-list discussion. Thanks applying into fixes. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/6] ARM: OMAP3: PRM: move prcm interrupt handlers to PRM driver code
* Kevin Hilman khil...@ti.com [120730 17:36]: At first, I wasn't sure why this was happening on Overo boards and not on the other boards, but then I notcied there was a *lot* more pm_wkup interrupts during boot on Overo compared to the other boards. This is because of the GPIO IRQ for the network interface as well as the network stack itself setting timers, resulting in a lot more pm_wkup events during boot and making the race more likely. Also happens if you may have somehow both edges selected for GPIO interrupts. Might be worth checking at least just in case of bugs somewhere.. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL 1/5] omap device tree changes for v3.6 merge window
On Tue, Aug 07, 2012 at 12:43:51, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [120713 01:01]: * Tony Lindgren t...@atomide.com [120712 23:46]: my scripts when applying patches. We'll have to apply this as a fix. Arnd and Olof, let me know if you want me to resubmit a new branch instead of the already pulled devel-dt branch. That branch should not have other dependencies as it's based on -rc5. Of course is it's buried into other DT patches it's too late. Now with -rc1 out, I'll queue the following fix. Thanks Tony Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Fix dmtimer set source clock failure
Hi,
* Jon Hunter jon-hun...@ti.com [120713 13:17]:
Calling the dmtimer function omap_dm_timer_set_source() fails if following a
call to pm_runtime_put() to disable the timer. For example the following
sequence would fail to set the parent clock ...
omap_dm_timer_stop(gptimer);
omap_dm_timer_set_source(gptimer, OMAP_TIMER_SRC_32_KHZ);
The following error message would be seen ...
omap_dm_timer_set_source: failed to set timer_32k_ck as parent
The problem is that, by design, pm_runtime_put() simply decrements the usage
count and returns before the timer has actually been disabled. Therefore,
setting the parent clock failed because the timer was still active when the
trying to set the parent clock. Setting a parent clock will fail if the clock
you are setting the parent of has a non-zero usage count. To ensure that this
does not fail use pm_runtime_put_sync() when disabling the timer.
Note that this will not be seen on OMAP1 devices, because these devices do
not use the clock framework for dmtimers.
Kevin care to ack this one? This should also be Cc: stable it seems?
Regards,
Tony
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/plat-omap/dmtimer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 626ad8c..7b6689a 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -258,7 +258,7 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_enable);
void omap_dm_timer_disable(struct omap_dm_timer *timer)
{
- pm_runtime_put(timer-pdev-dev);
+ pm_runtime_put_sync(timer-pdev-dev);
}
EXPORT_SYMBOL_GPL(omap_dm_timer_disable);
--
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] OMAP: remove unused parameter arch_id from uncompress.h
* Domenico Andreoli cav...@gmail.com [120714 13:54]: From: Domenico Andreoli domenico.andre...@linux.com There is not point in having arch_id as parameter of __arch_decomp_setup(), nothing in it uses arch_id. The machine id is already exported (and used) with symbol __machine_arch_type as per mach-types.h. Removing the pointless macro as well. Thanks applying into fixes. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND v2 1/2] arm/dts: Add AM33XX basic pinctrl support
* AnilKumar, Chimata anilku...@ti.com [120731 06:37]:
Hi Peter,
On Fri, Jul 27, 2012 at 14:40:52, Ujfalusi, Peter wrote:
Hi,
On 07/24/2012 06:45 PM, AnilKumar Ch wrote:
Adds basic pinctrl support for AM33XX family of devices. This patch
is based on the pinctrl-simple driver submitted by Tony Lindgren's
here: http://lwn.net/Articles/496075/
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 59509c4..9b974dc 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -40,6 +40,15 @@
};
};
+ am3358_pinmux: pinmux@44E10800 {
+ compatible = pinctrl-single;
+ reg = 0x44E10800 0x0338;
I'm just curious about the size here: how it ended up as 0x0338?
While looking at the TRM of AM335x I can come up with 0x0238 (0x44e10800 -
0x44e10a38), but I don't see any sings of the remaining 0x0100 to be
documented at least.
No, pinmux registers are available till 0x44E10B38, look at AM335x latest TRM
or pinmux utility (we cannot find the exact offsets but pins we can find after
0x0A38, conf_ddr_resetn) at http://www.ti.com/tool/pinmuxtool
If you have a hole inbetween the registers it sounds like you also have core and
wkup domains? In that case those should be set up as separate controllers as
other
SCM registers may be inbetween those domains.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP4: twl-common: Support for additional devices on i2c1 bus
Hi Tony, On 08/07/2012 10:20 AM, Tony Lindgren wrote: Sorry things were getting already too complex for v3.6 merge window.. OK. So v3.7 it will be. Looks like this need to be updated against v3.6-rc1 to apply. I'll resend the updated patch on top of 3.6-rc1 Regards, Péter -- 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] spi: omap2-mcspi: In case of dma errors fall back to pio
* Shubhrajyoti D shubhrajy...@ti.com [120724 23:26]:
In case there are dma errors currently the driver exits.
Make the spi driver fall back to pio mode in case of dma errors.
If the DMA engine is not selected the driver
exits.This patch makes the spi fall back to pio in that case.
Also adds a field dma_unusable to struct omap2_mcspi.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index bc47781..f243a39 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -129,6 +129,7 @@ struct omap2_mcspi {
struct omap2_mcspi_dma *dma_channels;
struct device *dev;
struct omap2_mcspi_regs ctx;
+ int dma_unusable;
};
Don't you need to check separately for rx and tx dma? There's a slight
chance that you get a channel for one but not for the other..
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap2: mux: remove comment for nonexistent member
* Michael Jones michael.jo...@matrix-vision.de [120726 08:54]:
Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
---
arch/arm/mach-omap2/mux.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 471e62a..76f9b3c 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -127,7 +127,6 @@ struct omap_mux_partition {
* @gpio:GPIO number
* @muxnames:available signal modes for a ball
* @balls: available balls on the package
- * @partition: mux partition
*/
struct omap_mux {
u16 reg_offset;
Thanks applying into fixes.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] OMAPDSS: Remove cpu_is checks
Hi everyone, the patch series aims at cleaning up of DSS of cpu_is checks thereby making it more generic. The 1st patch cleans up cpu_is checks from DISPC code. The 2nd patch removes unused functions from DSS code. The 3rd patch cleans up cpu_is checks from DSS code. The 4th patch removes cpu_is checks from VENC code. The 5th patch disables VENC support on OMAP4. The 6th patch removes cpu_is checks from DPI code and replaces it with a dss feature. All your comments and suggestions are welcome. Regards, Chandrabhanu Chandrabhanu Mahapatra (6): OMAPDSS: DISPC: Remove cpu_is_ checks OMAPDSS: DSS: Remove redundant functions OMAPDSS: DSS: Remove cpu_is_ checks OMAPDSS: VENC: Remove cpu_is_ checks ARM: OMAP: Disable venc for OMAP4 OMAPDSS: DPI: Remove cpu_is_ checks arch/arm/mach-omap2/display.c |1 - drivers/video/omap2/dss/dispc.c| 386 +++- drivers/video/omap2/dss/dpi.c | 12 +- drivers/video/omap2/dss/dss.c | 155 +++-- drivers/video/omap2/dss/dss.h | 73 +- drivers/video/omap2/dss/dss_features.c | 83 +++ drivers/video/omap2/dss/dss_features.h |4 + drivers/video/omap2/dss/venc.c | 11 - 8 files changed, 465 insertions(+), 260 deletions(-) -- 1.7.10 -- 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/6] OMAPDSS: DISPC: Remove cpu_is_xxxx checks
The cpu_is checks have been removed from DISPC providing it a much generic and
cleaner interface. The OMAP version and revision specific functions are
initialized by dispc_ops structure in dss features.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dispc.c| 386 +++-
drivers/video/omap2/dss/dss.h | 48
drivers/video/omap2/dss/dss_features.c | 42
drivers/video/omap2/dss/dss_features.h |2 +
4 files changed, 317 insertions(+), 161 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 5b289c5..ad63302 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -101,6 +101,8 @@ static struct {
boolctx_valid;
u32 ctx[DISPC_SZ_REGS / sizeof(u32)];
+ const struct dispc_ops *ops;
+
#ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
spinlock_t irq_stats_lock;
struct dispc_irq_stats irq_stats;
@@ -1939,7 +1941,18 @@ static unsigned long calc_core_clk_five_taps(enum
omap_channel channel,
return core_clk;
}
-static unsigned long calc_core_clk(enum omap_channel channel, u16 width,
+unsigned long calc_core_clk_24xx(enum omap_channel channel, u16 width,
+ u16 height, u16 out_width, u16 out_height)
+{
+ unsigned long pclk = dispc_mgr_pclk_rate(channel);
+
+ if (height out_height width out_width)
+ return pclk * 4;
+ else
+ return pclk * 2;
+}
+
+unsigned long calc_core_clk_34xx(enum omap_channel channel, u16 width,
u16 height, u16 out_width, u16 out_height)
{
unsigned int hf, vf;
@@ -1958,25 +1971,163 @@ static unsigned long calc_core_clk(enum omap_channel
channel, u16 width,
hf = 2;
else
hf = 1;
-
if (height out_height)
vf = 2;
else
vf = 1;
- if (cpu_is_omap24xx()) {
- if (vf 1 hf 1)
- return pclk * 4;
- else
- return pclk * 2;
- } else if (cpu_is_omap34xx()) {
- return pclk * vf * hf;
- } else {
- if (hf 1)
- return DIV_ROUND_UP(pclk, out_width) * width;
- else
- return pclk;
+ return pclk * vf * hf;
+}
+
+unsigned long calc_core_clk_44xx(enum omap_channel channel, u16 width,
+ u16 height, u16 out_width, u16 out_height)
+{
+ unsigned long pclk = dispc_mgr_pclk_rate(channel);
+
+ if (width out_width)
+ return DIV_ROUND_UP(pclk, out_width) * width;
+ else
+ return pclk;
+}
+
+int dispc_ovl_calc_scaling_24xx(enum omap_channel channel,
+ const struct omap_video_timings *mgr_timings,
+ u16 width, u16 height, u16 out_width, u16 out_height,
+ enum omap_color_mode color_mode, bool *five_taps,
+ int *x_predecim, int *y_predecim, int *decim_x, int *decim_y,
+ u16 pos_x, unsigned long *core_clk)
+{
+ int error;
+ u16 in_width, in_height;
+ int min_factor = min(*decim_x, *decim_y);
+ const int maxsinglelinewidth =
+ dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
+ *five_taps = false;
+
+ do {
+ in_height = DIV_ROUND_UP(height, *decim_y);
+ in_width = DIV_ROUND_UP(width, *decim_x);
+ *core_clk = dispc.ops-calc_core_clk(channel, in_width,
+ in_height, out_width, out_height);
+ error = (in_width maxsinglelinewidth || !*core_clk ||
+ *core_clk dispc_core_clk_rate());
+ if (error) {
+ if (*decim_x == *decim_y) {
+ *decim_x = min_factor;
+ ++*decim_y;
+ } else {
+ swap(*decim_x, *decim_y);
+ if (*decim_x *decim_y)
+ ++*decim_x;
+ }
+ }
+ } while (*decim_x = *x_predecim *decim_y = *y_predecim error);
+
+ if (in_width maxsinglelinewidth) {
+ DSSERR(Cannot scale max input width exceeded);
+ return -EINVAL;
+ }
+ return 0;
+}
+
+int dispc_ovl_calc_scaling_34xx(enum omap_channel channel,
+ const struct omap_video_timings *mgr_timings,
+ u16 width, u16 height, u16 out_width, u16 out_height,
+ enum omap_color_mode color_mode, bool *five_taps,
+ int *x_predecim, int *y_predecim, int *decim_x, int *decim_y,
+ u16 pos_x, unsigned long *core_clk)
+{
+ int error;
+ u16 in_width, in_height;
+ int min_factor = min(*decim_x, *decim_y);
+ const int maxsinglelinewidth
[PATCH 2/6] OMAPDSS: DSS: Remove redundant functions
Functions dss_calc_clock_rates() and dss_get_clock_div() are removed as these
functions have become redundant and no longer used.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dss.c | 45 -
drivers/video/omap2/dss/dss.h |2 --
2 files changed, 47 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 04b4586..7b1c6ac 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -431,31 +431,6 @@ enum omap_dss_clk_source dss_get_lcd_clk_source(enum
omap_channel channel)
}
}
-/* calculate clock rates using dividers in cinfo */
-int dss_calc_clock_rates(struct dss_clock_info *cinfo)
-{
- if (dss.dpll4_m4_ck) {
- unsigned long prate;
- u16 fck_div_max = 16;
-
- if (cpu_is_omap3630() || cpu_is_omap44xx())
- fck_div_max = 32;
-
- if (cinfo-fck_div fck_div_max || cinfo-fck_div == 0)
- return -EINVAL;
-
- prate = clk_get_rate(clk_get_parent(dss.dpll4_m4_ck));
-
- cinfo-fck = prate / cinfo-fck_div;
- } else {
- if (cinfo-fck_div != 0)
- return -EINVAL;
- cinfo-fck = clk_get_rate(dss.dss_clk);
- }
-
- return 0;
-}
-
int dss_set_clock_div(struct dss_clock_info *cinfo)
{
if (dss.dpll4_m4_ck) {
@@ -478,26 +453,6 @@ int dss_set_clock_div(struct dss_clock_info *cinfo)
return 0;
}
-int dss_get_clock_div(struct dss_clock_info *cinfo)
-{
- cinfo-fck = clk_get_rate(dss.dss_clk);
-
- if (dss.dpll4_m4_ck) {
- unsigned long prate;
-
- prate = clk_get_rate(clk_get_parent(dss.dpll4_m4_ck));
-
- if (cpu_is_omap3630() || cpu_is_omap44xx())
- cinfo-fck_div = prate / (cinfo-fck);
- else
- cinfo-fck_div = prate / (cinfo-fck / 2);
- } else {
- cinfo-fck_div = 0;
- }
-
- return 0;
-}
-
unsigned long dss_get_dpll4_rate(void)
{
if (dss.dpll4_m4_ck)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index d87b885..5773c86 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -311,9 +311,7 @@ void dss_set_venc_output(enum omap_dss_venc_type type);
void dss_set_dac_pwrdn_bgz(bool enable);
unsigned long dss_get_dpll4_rate(void);
-int dss_calc_clock_rates(struct dss_clock_info *cinfo);
int dss_set_clock_div(struct dss_clock_info *cinfo);
-int dss_get_clock_div(struct dss_clock_info *cinfo);
int dss_calc_clock_div(unsigned long req_pck, struct dss_clock_info *dss_cinfo,
struct dispc_clock_info *dispc_cinfo);
--
1.7.10
--
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/6] OMAPDSS: DSS: Remove cpu_is_xxxx checks
The cpu_is checks have been removed from dss.c providing it a much generic and
cleaner interface. The OMAP version and revision specific functions are
initialized by dss_ops structure in dss features.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dss.c | 114 ++--
drivers/video/omap2/dss/dss.h | 23 ++-
drivers/video/omap2/dss/dss_features.c | 40 +++
drivers/video/omap2/dss/dss_features.h |1 +
4 files changed, 141 insertions(+), 37 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 7b1c6ac..c263da7 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -83,6 +83,8 @@ static struct {
boolctx_valid;
u32 ctx[DSS_SZ_REGS / sizeof(u32)];
+
+ const struct dss_ops *ops;
} dss;
static const char * const dss_generic_clk_source_names[] = {
@@ -236,6 +238,15 @@ const char *dss_get_generic_clk_source_name(enum
omap_dss_clk_source clk_src)
return dss_generic_clk_source_names[clk_src];
}
+char *set_dump_clk_str_24_34(void)
+{
+ return %s (%s) = %lu / %lu * 2 = %lu\n;
+}
+
+char *set_dump_clk_str(void)
+{
+ return %s (%s) = %lu / %lu = %lu\n;
+}
void dss_dump_clocks(struct seq_file *s)
{
@@ -254,23 +265,15 @@ void dss_dump_clocks(struct seq_file *s)
fclk_rate = clk_get_rate(dss.dss_clk);
if (dss.dpll4_m4_ck) {
+ char *str = dss.ops-set_str();
+
dpll4_ck_rate = clk_get_rate(clk_get_parent(dss.dpll4_m4_ck));
dpll4_m4_ck_rate = clk_get_rate(dss.dpll4_m4_ck);
seq_printf(s, dpll4_ck %lu\n, dpll4_ck_rate);
- if (cpu_is_omap3630() || cpu_is_omap44xx())
- seq_printf(s, %s (%s) = %lu / %lu = %lu\n,
- fclk_name, fclk_real_name,
- dpll4_ck_rate,
- dpll4_ck_rate / dpll4_m4_ck_rate,
- fclk_rate);
- else
- seq_printf(s, %s (%s) = %lu / %lu * 2 = %lu\n,
- fclk_name, fclk_real_name,
- dpll4_ck_rate,
- dpll4_ck_rate / dpll4_m4_ck_rate,
- fclk_rate);
+ seq_printf(s, str, fclk_name, fclk_real_name, dpll4_ck_rate,
+ dpll4_ck_rate / dpll4_m4_ck_rate, fclk_rate);
} else {
seq_printf(s, %s (%s) = %lu\n,
fclk_name, fclk_real_name,
@@ -461,6 +464,35 @@ unsigned long dss_get_dpll4_rate(void)
return 0;
}
+u16 get_dss_fck_div_max_24_34(void)
+{
+ return 16;
+}
+
+u16 get_dss_fck_div_max(void)
+{
+ return 32;
+}
+
+bool set_dss_clock_info_34xx(void)
+{
+ unsigned long prate = dss_get_dpll4_rate();
+ unsigned long fck = clk_get_rate(dss.dss_clk);
+
+ if (prate == dss.cache_prate || dss.cache_dss_cinfo.fck == fck)
+ return true;
+ return false;
+}
+
+bool set_dss_clock_info(void)
+{
+ unsigned long fck = clk_get_rate(dss.dss_clk);
+
+ if (dss.cache_dss_cinfo.fck == fck)
+ return true;
+ return false;
+}
+
int dss_calc_clock_div(unsigned long req_pck, struct dss_clock_info *dss_cinfo,
struct dispc_clock_info *dispc_cinfo)
{
@@ -470,7 +502,7 @@ int dss_calc_clock_div(unsigned long req_pck, struct
dss_clock_info *dss_cinfo,
unsigned long fck, max_dss_fck;
- u16 fck_div, fck_div_max = 16;
+ u16 fck_div, fck_div_max;
int match = 0;
int min_fck_per_pck;
@@ -479,10 +511,7 @@ int dss_calc_clock_div(unsigned long req_pck, struct
dss_clock_info *dss_cinfo,
max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
- fck = clk_get_rate(dss.dss_clk);
- if (req_pck == dss.cache_req_pck
- ((cpu_is_omap34xx() prate == dss.cache_prate) ||
-dss.cache_dss_cinfo.fck == fck)) {
+ if (req_pck == dss.cache_req_pck dss.ops-set_dss_cinfo()) {
DSSDBG(dispc clock info found from cache.\n);
*dss_cinfo = dss.cache_dss_cinfo;
*dispc_cinfo = dss.cache_dispc_cinfo;
@@ -519,8 +548,7 @@ retry:
goto found;
} else {
- if (cpu_is_omap3630() || cpu_is_omap44xx())
- fck_div_max = 32;
+ fck_div_max = dss.ops-get_fck_div_max();
for (fck_div = fck_div_max; fck_div 0; --fck_div) {
struct dispc_clock_info cur_dispc;
@@ -619,6 +647,32 @@ enum dss_hdmi_venc_clk_source_select
dss_get_hdmi_venc_clk_source(void)
return REG_GET(DSS_CONTROL, 15, 15);
}
+int dss_get_clk_24xx(struct
[PATCH 4/6] OMAPDSS: VENC: Remove cpu_is_xxxx checks
OMAP4 checks are removed from VENC to provide it a cleaner interface. These
checks were introduced by patches HACK: OMAP: DSS2: VENC: disable VENC on OMAP4
to prevent crash (ba02fa37de) by Tomi Valkeinen tomi.valkei...@ti.com and
OMAPDSS: VENC: fix NULL pointer dereference in DSS2 VENC sysfs debug attr on
OMAP4 (cc1d3e032d) by Danny Kukawka danny.kuka...@bisect.de to prevent VENC
from crashing OMAP4 kernel. An alternative approach is used to do the same in
later patches.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/venc.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 3a22087..8fc165a 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -752,11 +752,6 @@ static void venc_dump_regs(struct seq_file *s)
{
#define DUMPREG(r) seq_printf(s, %-35s %08x\n, #r, venc_read_reg(r))
- if (cpu_is_omap44xx()) {
- seq_printf(s, VENC currently disabled on OMAP44xx\n);
- return;
- }
-
if (venc_runtime_get())
return;
@@ -971,16 +966,10 @@ static struct platform_driver omap_venchw_driver = {
int __init venc_init_platform_driver(void)
{
- if (cpu_is_omap44xx())
- return 0;
-
return platform_driver_probe(omap_venchw_driver, omap_venchw_probe);
}
void __exit venc_uninit_platform_driver(void)
{
- if (cpu_is_omap44xx())
- return;
-
platform_driver_unregister(omap_venchw_driver);
}
--
1.7.10
--
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 5/6] ARM: OMAP: Disable venc for OMAP4
This is a alternative to HACK: OMAP: DSS2: VENC: disable VENC on OMAP4 to
prevent crash (ba02fa37de) by Tomi Valkeinen tomi.valkei...@ti.com to prevent
VENC from crashing OMAP4 kernel. This prevents OMAPDSS from initial registration
of a device for VENC on OMAP4.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
arch/arm/mach-omap2/display.c |1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index af1ed7d..ee40739 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -95,7 +95,6 @@ static const struct omap_dss_hwmod_data
omap4_dss_hwmod_data[] __initdata = {
{ dss_core, omapdss_dss, -1 },
{ dss_dispc, omapdss_dispc, -1 },
{ dss_rfbi, omapdss_rfbi, -1 },
- { dss_venc, omapdss_venc, -1 },
{ dss_dsi1, omapdss_dsi, 0 },
{ dss_dsi2, omapdss_dsi, 1 },
{ dss_hdmi, omapdss_hdmi, -1 },
--
1.7.10
--
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 6/6] OMAPDSS: DPI: Remove cpu_is_xxxx checks
The OMAP3 checks have been removed and replaced by a dss feature
FEAT_DPI_USES_VDDS_DSI for cleaner implementation. The patches
OMAP: DSS2: enable VDDS_DSI when using DPI (8a2cfea8cc) by Tomi Valkeinen
tomi.valkei...@nokia.com and ARM: omap: fix oops in
drivers/video/omap2/dss/dpi.c (4041071571) by Russell King
rmk+ker...@arm.linux.org.uk had introduced these checks. As it is evident
from these patches a dependency exists for some DSS pins on VDDS_DSI which is
better shown by dss feature FEAT_DPI_USES_VDDS_DSI.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dpi.c | 12 +++-
drivers/video/omap2/dss/dss_features.c |1 +
drivers/video/omap2/dss/dss_features.h |1 +
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 3266be2..b97f7b8 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -34,6 +34,7 @@
#include plat/cpu.h
#include dss.h
+#include dss_features.h
static struct {
struct regulator *vdds_dsi_reg;
@@ -169,7 +170,7 @@ int omapdss_dpi_display_enable(struct omap_dss_device
*dssdev)
{
int r;
- if (cpu_is_omap34xx() !dpi.vdds_dsi_reg) {
+ if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI) !dpi.vdds_dsi_reg) {
DSSERR(no VDSS_DSI regulator\n);
return -ENODEV;
}
@@ -185,7 +186,7 @@ int omapdss_dpi_display_enable(struct omap_dss_device
*dssdev)
goto err_start_dev;
}
- if (cpu_is_omap34xx()) {
+ if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI)) {
r = regulator_enable(dpi.vdds_dsi_reg);
if (r)
goto err_reg_enable;
@@ -229,7 +230,7 @@ err_dsi_pll_init:
err_get_dsi:
dispc_runtime_put();
err_get_dispc:
- if (cpu_is_omap34xx())
+ if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI))
regulator_disable(dpi.vdds_dsi_reg);
err_reg_enable:
omap_dss_stop_device(dssdev);
@@ -250,7 +251,7 @@ void omapdss_dpi_display_disable(struct omap_dss_device
*dssdev)
dispc_runtime_put();
- if (cpu_is_omap34xx())
+ if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI))
regulator_disable(dpi.vdds_dsi_reg);
omap_dss_stop_device(dssdev);
@@ -329,7 +330,8 @@ static int __init dpi_init_display(struct omap_dss_device
*dssdev)
{
DSSDBG(init_display\n);
- if (cpu_is_omap34xx() dpi.vdds_dsi_reg == NULL) {
+ if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI)
+ dpi.vdds_dsi_reg == NULL) {
struct regulator *vdds_dsi;
vdds_dsi = dss_get_vdds_dsi();
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index 6b35200..ba70de5 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -373,6 +373,7 @@ static const enum dss_feat_id omap3430_dss_feat_list[] = {
FEAT_ALPHA_FIXED_ZORDER,
FEAT_FIFO_MERGE,
FEAT_OMAP3_DSI_FIFO_BUG,
+ FEAT_DPI_USES_VDDS_DSI,
};
static const enum dss_feat_id omap3630_dss_feat_list[] = {
diff --git a/drivers/video/omap2/dss/dss_features.h
b/drivers/video/omap2/dss/dss_features.h
index aa1e4b6..9c18fe3 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -50,6 +50,7 @@ enum dss_feat_id {
FEAT_DSI_VC_OCP_WIDTH,
FEAT_DSI_REVERSE_TXCLKESC,
FEAT_DSI_GNQ,
+ FEAT_DPI_USES_VDDS_DSI,
FEAT_HDMI_CTS_SWMODE,
FEAT_HDMI_AUDIO_USE_MCLK,
FEAT_HANDLE_UV_SEPARATE,
--
1.7.10
--
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 RESEND v2 1/2] arm/dts: Add AM33XX basic pinctrl support
Hi Tony,
On Tue, Aug 07, 2012 at 13:13:48, Tony Lindgren wrote:
* AnilKumar, Chimata anilku...@ti.com [120731 06:37]:
Hi Peter,
On Fri, Jul 27, 2012 at 14:40:52, Ujfalusi, Peter wrote:
Hi,
On 07/24/2012 06:45 PM, AnilKumar Ch wrote:
Adds basic pinctrl support for AM33XX family of devices. This patch
is based on the pinctrl-simple driver submitted by Tony Lindgren's
here: http://lwn.net/Articles/496075/
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi
b/arch/arm/boot/dts/am33xx.dtsi
index 59509c4..9b974dc 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -40,6 +40,15 @@
};
};
+ am3358_pinmux: pinmux@44E10800 {
+ compatible = pinctrl-single;
+ reg = 0x44E10800 0x0338;
I'm just curious about the size here: how it ended up as 0x0338?
While looking at the TRM of AM335x I can come up with 0x0238 (0x44e10800 -
0x44e10a38), but I don't see any sings of the remaining 0x0100 to be
documented at least.
No, pinmux registers are available till 0x44E10B38, look at AM335x latest
TRM
or pinmux utility (we cannot find the exact offsets but pins we can find
after
0x0A38, conf_ddr_resetn) at http://www.ti.com/tool/pinmuxtool
If you have a hole inbetween the registers it sounds like you also have core
and
wkup domains? In that case those should be set up as separate controllers as
other
SCM registers may be inbetween those domains.
In case of AM33XX we have only one padconf domain and it do not have any holes
in between.
Regards
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
Re: [PATCH 1/6] OMAPDSS: DISPC: Remove cpu_is_xxxx checks
Hi,
On Tue, Aug 07, 2012 at 01:57:42PM +0530, Chandrabhanu Mahapatra wrote:
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index 9387097..b8d5095 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -567,6 +567,48 @@ static const struct omap_dss_features omap4_dss_features
= {
.burst_size_unit = 16,
};
+static const struct dispc_ops omap2_dispc_ops = {
+ .calc_scaling = dispc_ovl_calc_scaling_24xx,
+ .calc_core_clk = calc_core_clk_24xx,
+ .lcd_timings_ok = _dispc_lcd_timings_ok_24xx,
+ .set_lcd_timings_hv = _dispc_mgr_set_lcd_timings_hv_24xx,
+};
+
+static const struct dispc_ops omap3_2_1_dispc_ops = {
+ .calc_scaling = dispc_ovl_calc_scaling_34xx,
+ .calc_core_clk = calc_core_clk_34xx,
+ .lcd_timings_ok = _dispc_lcd_timings_ok_24xx,
+ .set_lcd_timings_hv = _dispc_mgr_set_lcd_timings_hv_24xx,
+};
+
+static const struct dispc_ops omap3_3_0_dispc_ops = {
+ .calc_scaling = dispc_ovl_calc_scaling_34xx,
+ .calc_core_clk = calc_core_clk_34xx,
+ .lcd_timings_ok = _dispc_lcd_timings_ok_44xx,
+ .set_lcd_timings_hv = _dispc_mgr_set_lcd_timings_hv_44xx,
+};
+
+static const struct dispc_ops omap4_dispc_ops = {
+ .calc_scaling = dispc_ovl_calc_scaling_44xx,
+ .calc_core_clk = calc_core_clk_44xx,
+ .lcd_timings_ok = _dispc_lcd_timings_ok_44xx,
+ .set_lcd_timings_hv = _dispc_mgr_set_lcd_timings_hv_44xx,
+};
+
+void dispc_init_ops(const struct dispc_ops *ops)
+{
+ if (cpu_is_omap24xx()) {
+ ops = omap2_dispc_ops;
+ } else if (cpu_is_omap34xx()) {
+ if (omap_rev() OMAP3430_REV_ES3_0)
+ ops = omap3_2_1_dispc_ops;
+ else
+ ops = omap3_3_0_dispc_ops;
+ } else {
+ ops = omap4_dispc_ops;
+ }
+}
you're not really removing. You're moving cpu_is_* somewhere else. A
better approach, IMHO, would be to use the DSS_REVISION register to
differentiate the DSS IP itself, not the OMAP.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 3/6] OMAPDSS: DSS: Remove cpu_is_xxxx checks
On Tue, Aug 07, 2012 at 01:58:04PM +0530, Chandrabhanu Mahapatra wrote:
The cpu_is checks have been removed from dss.c providing it a much generic and
cleaner interface. The OMAP version and revision specific functions are
initialized by dss_ops structure in dss features.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dss.c | 114
++--
drivers/video/omap2/dss/dss.h | 23 ++-
drivers/video/omap2/dss/dss_features.c | 40 +++
drivers/video/omap2/dss/dss_features.h |1 +
4 files changed, 141 insertions(+), 37 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 7b1c6ac..c263da7 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -83,6 +83,8 @@ static struct {
boolctx_valid;
u32 ctx[DSS_SZ_REGS / sizeof(u32)];
+
+ const struct dss_ops *ops;
} dss;
static const char * const dss_generic_clk_source_names[] = {
@@ -236,6 +238,15 @@ const char *dss_get_generic_clk_source_name(enum
omap_dss_clk_source clk_src)
return dss_generic_clk_source_names[clk_src];
}
+char *set_dump_clk_str_24_34(void)
+{
+ return %s (%s) = %lu / %lu * 2 = %lu\n;
+}
+
+char *set_dump_clk_str(void)
+{
+ return %s (%s) = %lu / %lu = %lu\n;
+}
void dss_dump_clocks(struct seq_file *s)
{
@@ -254,23 +265,15 @@ void dss_dump_clocks(struct seq_file *s)
fclk_rate = clk_get_rate(dss.dss_clk);
if (dss.dpll4_m4_ck) {
+ char *str = dss.ops-set_str();
+
dpll4_ck_rate = clk_get_rate(clk_get_parent(dss.dpll4_m4_ck));
dpll4_m4_ck_rate = clk_get_rate(dss.dpll4_m4_ck);
seq_printf(s, dpll4_ck %lu\n, dpll4_ck_rate);
- if (cpu_is_omap3630() || cpu_is_omap44xx())
- seq_printf(s, %s (%s) = %lu / %lu = %lu\n,
- fclk_name, fclk_real_name,
- dpll4_ck_rate,
- dpll4_ck_rate / dpll4_m4_ck_rate,
- fclk_rate);
- else
- seq_printf(s, %s (%s) = %lu / %lu * 2 = %lu\n,
- fclk_name, fclk_real_name,
- dpll4_ck_rate,
- dpll4_ck_rate / dpll4_m4_ck_rate,
- fclk_rate);
+ seq_printf(s, str, fclk_name, fclk_real_name, dpll4_ck_rate,
+ dpll4_ck_rate / dpll4_m4_ck_rate, fclk_rate);
} else {
seq_printf(s, %s (%s) = %lu\n,
fclk_name, fclk_real_name,
@@ -461,6 +464,35 @@ unsigned long dss_get_dpll4_rate(void)
return 0;
}
+u16 get_dss_fck_div_max_24_34(void)
+{
+ return 16;
+}
+
+u16 get_dss_fck_div_max(void)
+{
+ return 32;
+}
+
+bool set_dss_clock_info_34xx(void)
+{
+ unsigned long prate = dss_get_dpll4_rate();
+ unsigned long fck = clk_get_rate(dss.dss_clk);
+
+ if (prate == dss.cache_prate || dss.cache_dss_cinfo.fck == fck)
+ return true;
+ return false;
+}
+
+bool set_dss_clock_info(void)
+{
+ unsigned long fck = clk_get_rate(dss.dss_clk);
+
+ if (dss.cache_dss_cinfo.fck == fck)
+ return true;
+ return false;
+}
+
int dss_calc_clock_div(unsigned long req_pck, struct dss_clock_info
*dss_cinfo,
struct dispc_clock_info *dispc_cinfo)
{
@@ -470,7 +502,7 @@ int dss_calc_clock_div(unsigned long req_pck, struct
dss_clock_info *dss_cinfo,
unsigned long fck, max_dss_fck;
- u16 fck_div, fck_div_max = 16;
+ u16 fck_div, fck_div_max;
int match = 0;
int min_fck_per_pck;
@@ -479,10 +511,7 @@ int dss_calc_clock_div(unsigned long req_pck, struct
dss_clock_info *dss_cinfo,
max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
- fck = clk_get_rate(dss.dss_clk);
- if (req_pck == dss.cache_req_pck
- ((cpu_is_omap34xx() prate == dss.cache_prate) ||
- dss.cache_dss_cinfo.fck == fck)) {
+ if (req_pck == dss.cache_req_pck dss.ops-set_dss_cinfo()) {
DSSDBG(dispc clock info found from cache.\n);
*dss_cinfo = dss.cache_dss_cinfo;
*dispc_cinfo = dss.cache_dispc_cinfo;
@@ -519,8 +548,7 @@ retry:
goto found;
} else {
- if (cpu_is_omap3630() || cpu_is_omap44xx())
- fck_div_max = 32;
+ fck_div_max = dss.ops-get_fck_div_max();
for (fck_div = fck_div_max; fck_div 0; --fck_div) {
struct dispc_clock_info cur_dispc;
@@ -619,6 +647,32 @@ enum dss_hdmi_venc_clk_source_select
Re: [PATCH 4/6] OMAPDSS: VENC: Remove cpu_is_xxxx checks
On Tue, Aug 07, 2012 at 01:58:17PM +0530, Chandrabhanu Mahapatra wrote: OMAP4 checks are removed from VENC to provide it a cleaner interface. These checks were introduced by patches HACK: OMAP: DSS2: VENC: disable VENC on OMAP4 to prevent crash (ba02fa37de) by Tomi Valkeinen tomi.valkei...@ti.com and OMAPDSS: VENC: fix NULL pointer dereference in DSS2 VENC sysfs debug attr on OMAP4 (cc1d3e032d) by Danny Kukawka danny.kuka...@bisect.de to prevent VENC from crashing OMAP4 kernel. An alternative approach is used to do the same in later patches. in later patches ? This means you're causing a regression here. Just swap the patches around to avoid it. -- balbi signature.asc Description: Digital signature
RE: [PATCH] backlight: Add TPS65217 WLED driver
Hi Kaehlcke,
Can you re-submit the patch based on linux-next tree?
Comments inline
On Wed, Aug 01, 2012 at 01:18:38, Matthias Kaehlcke wrote:
The TPS65217 chip contains a boost converter and current sinks which can be
used to drive LEDs for use as backlights. Expose this functionality via the
backlight API.
Can you provide more details here, like patch is based on which tree?
Testing details of the driver?
Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net
---
drivers/mfd/tps65217.c| 71 +
drivers/video/backlight/Kconfig |7 +
drivers/video/backlight/Makefile |1 +
drivers/video/backlight/tps65217_bl.c | 272
+
include/linux/mfd/tps65217.h | 19 +++
5 files changed, 370 insertions(+)
create mode 100644 drivers/video/backlight/tps65217_bl.c
diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
index 61c097a..c248bb3 100644
--- a/drivers/mfd/tps65217.c
+++ b/drivers/mfd/tps65217.c
@@ -29,6 +29,12 @@
#include linux/mfd/core.h
#include linux/mfd/tps65217.h
+#if defined(CONFIG_BACKLIGHT_TPS65217) ||
defined(CONFIG_BACKLIGHT_TPS65217_MODULE)
+#define tps_has_bl() true
+#else
+#define tps_has_bl() false
+#endif
+
Is this really required?
/**
* tps65217_reg_read: Read a single tps65217 register.
*
@@ -174,6 +180,47 @@ static struct tps65217_board *tps65217_parse_dt(struct
i2c_client *client)
pdata-of_node[i] = reg_matches[i].of_node;
}
+ if (tps_has_bl()) {
+ struct device_node *np = of_find_node_by_name(node,
backlight);
+ if (np) {
This can be changed to
np = of_find_node_by_name(node, backlight);
if (np) {
}
else fall into non-backlight case.
+ u32 val;
+
+ pdata-bl_pdata = devm_kzalloc(client-dev,
sizeof(*pdata-bl_pdata), GFP_KERNEL);
+ if (!pdata-bl_pdata)
+ return NULL;
+
+ if (!of_property_read_u32(np, isel, val)) {
+ if (val == 1) {
+ pdata-bl_pdata-isel =
TPS65217_BL_ISET1;
+ } else if (val == 2) {
+ pdata-bl_pdata-isel =
TPS65217_BL_ISET2;
+ } else {
+ dev_err(client-dev, invalid value
for backlight current limit selection in the device tree\n);
fix checkpatch.pl errors before submitting the patches. More than
80 ch.
+ return NULL;
Should not return here, need to handle rest of dt portion.
+ }
+ } else {
+ pdata-bl_pdata-isel = TPS65217_BL_ISET1;
+ }
This can be changed to
pdata-bl_pdata-isel = TPS65217_BL_ISET1;
of_property_read_u32(np, isel, val)
if (val TPS65217_BL_ISET2 || val TPS65217_BL_ISET1) {
dev_err(...);
goto rest_dt_portion;
} else {
pdata-bl_pdata-isel = val;
}
+
+ if (!of_property_read_u32(np, fdim, val)) {
+ if (val == 100) {
+ pdata-bl_pdata-fdim =
TPS65217_BL_FDIM_100HZ;
+ } else if (val == 200) {
+ pdata-bl_pdata-fdim =
TPS65217_BL_FDIM_200HZ;
+ } else if (val == 500) {
+ pdata-bl_pdata-fdim =
TPS65217_BL_FDIM_500HZ;
+ } else if (val == 1000) {
+ pdata-bl_pdata-fdim =
TPS65217_BL_FDIM_1000HZ;
+ } else {
+ dev_err(client-dev, invalid value
for backlight dimming frequency in the device tree\n);
+ return NULL;
+ }
+ } else {
+ pdata-bl_pdata-fdim = TPS65217_BL_FDIM_200HZ;
+ }
+ }
+ }
Same here.
+
return pdata;
}
@@ -250,7 +297,28 @@ static int __devinit tps65217_probe(struct i2c_client
*client,
platform_device_add(pdev);
}
+ if (tps_has_bl()
+ pdata-bl_pdata) {
+ tps-bl_pdev = platform_device_alloc(tps65217-bl, 0);
+ if (!tps-bl_pdev) {
+ dev_err(tps-dev, Cannot create backlight platform
device\n);
+ ret = -ENOMEM;
+ goto err_alloc_bl_pdev;
+ }
+
+ tps-bl_pdev-dev.parent = tps-dev;
+ tps-bl_pdev-dev.platform_data = pdata-bl_pdata;
+
+ platform_device_add(tps-bl_pdev);
+ }
+
return 0;
+
+err_alloc_bl_pdev:
+ for (i = 0; i TPS65217_NUM_REGULATOR; i++)
+
Re: [PATCH 1/6] OMAPDSS: DISPC: Remove cpu_is_xxxx checks
On Tue, 2012-08-07 at 11:48 +0300, Felipe Balbi wrote: you're not really removing. You're moving cpu_is_* somewhere else. A better approach, IMHO, would be to use the DSS_REVISION register to differentiate the DSS IP itself, not the OMAP. Unfortunately we can't, DSS_REVISION contains bogus information. I didn't look at these patches yet, but the idea has been to move the cpu_is_* checks to only a few central places, not scattered all over. At some point we could perhaps either move the cpu_is_ check code to somewhere under arch/arm, or, more probably, create our own DSS version IDs which are found out via cpu_is or soc_is or such. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/6] OMAPDSS: DISPC: Remove cpu_is_xxxx checks
On Tue, Aug 07, 2012 at 12:05:29PM +0300, Tomi Valkeinen wrote:
On Tue, 2012-08-07 at 11:48 +0300, Felipe Balbi wrote:
you're not really removing. You're moving cpu_is_* somewhere else. A
better approach, IMHO, would be to use the DSS_REVISION register to
differentiate the DSS IP itself, not the OMAP.
Unfortunately we can't, DSS_REVISION contains bogus information.
I didn't look at these patches yet, but the idea has been to move the
cpu_is_* checks to only a few central places, not scattered all over.
At some point we could perhaps either move the cpu_is_ check code to
somewhere under arch/arm, or, more probably, create our own DSS version
IDs which are found out via cpu_is or soc_is or such.
Or you could use the driver_data field on the platform_device_id and
of_device_id structures for that. Something like:
static const struct platform_device_id dss_id_table[] __initconst = {
{
{ omap2-dss, omap2_dss_features },
{ omap3-dss, omap3_dss_features },
{ omap4-dss, omap4_dss_features },
{ omap5-dss, omap5_dss_features },
{} /* Terminating entry */
};
then, on your probe, you just need to copy id-driver_data to your own
structures so you can reference them later. No need for cpu_is_* or
soc_is_* or machine_is_* anywhere.
On your platform_code, wherever you create the dss device, you need to
fix up the name though. The platform_device name should match
platform_device_id name, not platform_driver name.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] arm/dts: omap5: Add mmc controller nodes and board data
On Tuesday 07 August 2012, Balaji T K wrote: Add OMAP MMC related device tree data for OMAP5. Signed-off-by: Balaji T K balaj...@ti.com --- Acked-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] OMAPDSS: DISPC: Remove cpu_is_xxxx checks
On Tue, 2012-08-07 at 12:14 +0300, Felipe Balbi wrote:
Or you could use the driver_data field on the platform_device_id and
of_device_id structures for that. Something like:
static const struct platform_device_id dss_id_table[] __initconst = {
{
{ omap2-dss, omap2_dss_features },
{ omap3-dss, omap3_dss_features },
{ omap4-dss, omap4_dss_features },
{ omap5-dss, omap5_dss_features },
{} /* Terminating entry */
};
then, on your probe, you just need to copy id-driver_data to your own
structures so you can reference them later. No need for cpu_is_* or
soc_is_* or machine_is_* anywhere.
On your platform_code, wherever you create the dss device, you need to
fix up the name though. The platform_device name should match
platform_device_id name, not platform_driver name.
I've thought about that, but we need versions even for different OMAP ES
versions.
So in the device tree data we couldn't have the DSS nodes in a, say,
common omap4 file. We'd need separate DT files for each OMAP ES version.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 1/6] OMAPDSS: DISPC: Remove cpu_is_xxxx checks
Hi,
On Tue, Aug 07, 2012 at 12:27:52PM +0300, Tomi Valkeinen wrote:
On Tue, 2012-08-07 at 12:14 +0300, Felipe Balbi wrote:
Or you could use the driver_data field on the platform_device_id and
of_device_id structures for that. Something like:
static const struct platform_device_id dss_id_table[] __initconst = {
{
{ omap2-dss, omap2_dss_features },
{ omap3-dss, omap3_dss_features },
{ omap4-dss, omap4_dss_features },
{ omap5-dss, omap5_dss_features },
{} /* Terminating entry */
};
then, on your probe, you just need to copy id-driver_data to your own
structures so you can reference them later. No need for cpu_is_* or
soc_is_* or machine_is_* anywhere.
On your platform_code, wherever you create the dss device, you need to
fix up the name though. The platform_device name should match
platform_device_id name, not platform_driver name.
I've thought about that, but we need versions even for different OMAP ES
versions.
So in the device tree data we couldn't have the DSS nodes in a, say,
common omap4 file. We'd need separate DT files for each OMAP ES version.
you can overwrite attributes on your board dts file, right ? Meaning
that e.g. omap4.dtsi would have:
dss1: dss@ {
compatible = ti, omap4-dss;
};
then on omap4-based-board.dts:
dss1 {
compatible = ti,omap4-based-board-dss;
};
or something similar. Isn't that doable ? Benoit, would this work on
DTS ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/6] OMAPDSS: DISPC: Remove cpu_is_xxxx checks
On Tue, 2012-08-07 at 12:32 +0300, Felipe Balbi wrote:
Hi,
On Tue, Aug 07, 2012 at 12:27:52PM +0300, Tomi Valkeinen wrote:
On Tue, 2012-08-07 at 12:14 +0300, Felipe Balbi wrote:
Or you could use the driver_data field on the platform_device_id and
of_device_id structures for that. Something like:
static const struct platform_device_id dss_id_table[] __initconst = {
{
{ omap2-dss, omap2_dss_features },
{ omap3-dss, omap3_dss_features },
{ omap4-dss, omap4_dss_features },
{ omap5-dss, omap5_dss_features },
{} /* Terminating entry */
};
then, on your probe, you just need to copy id-driver_data to your own
structures so you can reference them later. No need for cpu_is_* or
soc_is_* or machine_is_* anywhere.
On your platform_code, wherever you create the dss device, you need to
fix up the name though. The platform_device name should match
platform_device_id name, not platform_driver name.
I've thought about that, but we need versions even for different OMAP ES
versions.
So in the device tree data we couldn't have the DSS nodes in a, say,
common omap4 file. We'd need separate DT files for each OMAP ES version.
you can overwrite attributes on your board dts file, right ? Meaning
that e.g. omap4.dtsi would have:
dss1: dss@ {
compatible = ti, omap4-dss;
};
then on omap4-based-board.dts:
dss1 {
compatible = ti,omap4-based-board-dss;
};
or something similar. Isn't that doable ? Benoit, would this work on
DTS ?
Yes, they can be overridden, but I think it's still quite difficult to
manage. DSS is modeled with multiple blocks, also in DT data. So you'd
need to override multiple entries.
And it'd also require a new dts file for each version of your board with
different ES version.
Also, I don't really see why this information would need to be present
in the DT data (especially as it's not simple). It's all trivially found
out in the code, by using cpu_is soc_is.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: DSS and USBHOST powerdomains not entering low-power states on 37xx EVM
Hi Kevin, On Mon, 6 Aug 2012, Kevin Hilman wrote: Is this only happening on this 37xx platform?Just curious, because it seems to be a problem on any OMAP3xxx SoC. So far I've only run the baseline tests on 37xx, so wanted to state only what was observed here. ...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. Thanks for the diagnosis. Care to put together a patch to fix this for v3.6-rc? The earliest point that the usecounting improvements could get in would be v3.7. This problem is breaking the PM regression tests here that parse the powerdomain state count fields. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] OMAPDSS: DISPC: Remove cpu_is_xxxx checks
Hi,
On Tue, Aug 07, 2012 at 12:57:16PM +0300, Tomi Valkeinen wrote:
On Tue, 2012-08-07 at 12:32 +0300, Felipe Balbi wrote:
Hi,
On Tue, Aug 07, 2012 at 12:27:52PM +0300, Tomi Valkeinen wrote:
On Tue, 2012-08-07 at 12:14 +0300, Felipe Balbi wrote:
Or you could use the driver_data field on the platform_device_id and
of_device_id structures for that. Something like:
static const struct platform_device_id dss_id_table[] __initconst = {
{
{ omap2-dss, omap2_dss_features },
{ omap3-dss, omap3_dss_features },
{ omap4-dss, omap4_dss_features },
{ omap5-dss, omap5_dss_features },
{} /* Terminating entry */
};
then, on your probe, you just need to copy id-driver_data to your own
structures so you can reference them later. No need for cpu_is_* or
soc_is_* or machine_is_* anywhere.
On your platform_code, wherever you create the dss device, you need to
fix up the name though. The platform_device name should match
platform_device_id name, not platform_driver name.
I've thought about that, but we need versions even for different OMAP ES
versions.
So in the device tree data we couldn't have the DSS nodes in a, say,
common omap4 file. We'd need separate DT files for each OMAP ES version.
you can overwrite attributes on your board dts file, right ? Meaning
that e.g. omap4.dtsi would have:
dss1: dss@ {
compatible = ti, omap4-dss;
};
then on omap4-based-board.dts:
dss1 {
compatible = ti,omap4-based-board-dss;
};
or something similar. Isn't that doable ? Benoit, would this work on
DTS ?
Yes, they can be overridden, but I think it's still quite difficult to
manage. DSS is modeled with multiple blocks, also in DT data. So you'd
need to override multiple entries.
And it'd also require a new dts file for each version of your board with
different ES version.
Also, I don't really see why this information would need to be present
in the DT data (especially as it's not simple). It's all trivially found
out in the code, by using cpu_is soc_is.
Fair enough. I just think we should remove all cpu_is_* and soc_is_*
from drivers.
--
balbi
signature.asc
Description: Digital signature
[PATCH 0/2] ARM: OMAP: smatch warning cleanup and string unwrapping
This series fixes several bugs uncovered by smatch. It also unwraps all of the wrapped strings across the arch/arm/*omap* codebase. Some warning messages have been reformatted for concision and consistency. And some printk(KERN_* ... have been converted to pr_*( ... This series is intended for v3.7 cleanup. It has been only lightly tested; a pull request will be sent after testing is completed. - Paul --- warnings_cleanup_3.7 textdata bss dec hex filename 7318144 764324 5613004 13695472 d0f9f0 vmlinux.omap2plus_defconfig.orig 7318188 764348 5613004 13695540 d0fa34 vmlinux.omap2plus_defconfig Paul Walmsley (2): ARM: OMAP: clean up some smatch warnings, fix some printk(KERN_ERR ... ARM: OMAP: unwrap strings arch/arm/mach-omap1/board-htcherald.c |3 - arch/arm/mach-omap1/clock.c |4 + arch/arm/mach-omap1/clock_data.c| 13 ++--- arch/arm/mach-omap1/dma.c |5 +- arch/arm/mach-omap1/lcd_dma.c | 15 + arch/arm/mach-omap1/leds-h2p2-debug.c | 12 +++- arch/arm/mach-omap2/board-n8x0.c|7 +-- arch/arm/mach-omap2/board-overo.c |6 +- arch/arm/mach-omap2/board-zoom-debugboard.c |7 +-- arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 10 +--- arch/arm/mach-omap2/clkt_clksel.c | 28 +- arch/arm/mach-omap2/clkt_dpll.c |8 +-- arch/arm/mach-omap2/clock.c | 20 +++ arch/arm/mach-omap2/clock3xxx.c |3 - arch/arm/mach-omap2/clockdomain.c | 74 --- arch/arm/mach-omap2/common-board-devices.c |3 - arch/arm/mach-omap2/dpll3xxx.c |7 ++- arch/arm/mach-omap2/gpio.c |1 arch/arm/mach-omap2/gpmc.c |5 +- arch/arm/mach-omap2/id.c|5 +- arch/arm/mach-omap2/irq.c |5 +- arch/arm/mach-omap2/omap_hwmod.c| 16 +++--- arch/arm/mach-omap2/opp.c | 15 ++--- arch/arm/mach-omap2/pm.c|4 + arch/arm/mach-omap2/pm34xx.c|8 +-- arch/arm/mach-omap2/pm44xx.c|8 +-- arch/arm/mach-omap2/powerdomain.c | 36 ++--- arch/arm/mach-omap2/powerdomain2xxx_3xxx.c |4 + arch/arm/mach-omap2/powerdomain44xx.c |4 + arch/arm/mach-omap2/prcm.c |8 +-- arch/arm/mach-omap2/serial.c| 12 +++- arch/arm/mach-omap2/sr_device.c | 13 ++--- arch/arm/mach-omap2/timer.c |2 - arch/arm/mach-omap2/vc.c|5 +- arch/arm/mach-omap2/voltage.c | 12 ++-- arch/arm/mach-omap2/vp.c| 16 +++--- arch/arm/plat-omap/dma.c| 61 +- arch/arm/plat-omap/mux.c|2 - arch/arm/plat-omap/omap-pm-noop.c | 39 +++--- arch/arm/plat-omap/omap_device.c| 25 - 40 files changed, 239 insertions(+), 292 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP: clean up some smatch warnings, fix some printk(KERN_ERR ...
Resolve the following warnings from smatch:
arch/arm/mach-omap2/gpmc.c:282 gpmc_cs_set_timings() info: why not propagate
'div' from gpmc_cs_calc_divider() instead of -1?
arch/arm/mach-omap2/gpmc.c:456 gpmc_cs_free() info: ignoring unreachable code.
arch/arm/mach-omap2/gpmc.c:456 gpmc_cs_free() info: ignoring unreachable code.
arch/arm/mach-omap2/serial.c:328 omap_serial_init_port() error: 'pdev'
dereferencing possible ERR_PTR()
arch/arm/mach-omap2/timer.c:213 omap2_gp_clockevent_init() Error invalid range
4096 to -1
arch/arm/mach-omap2/gpio.c:63 omap2_gpio_dev_init() warn: possible memory leak
of 'pdata'
arch/arm/mach-omap2/omap_hwmod.c:1478 _assert_hardreset() warn: assigning -22
to unsigned variable 'ret'
arch/arm/mach-omap2/omap_hwmod.c:1487 _assert_hardreset() warn: 4294963201 is
more than 255 (max '(ret)' can be) so this is always the same.
arch/arm/mach-omap2/omap_hwmod.c:1545 _read_hardreset() warn: assigning -22 to
unsigned variable 'ret'
arch/arm/mach-omap2/omap_hwmod.c:1554 _read_hardreset() warn: 4294963201 is
more than 255 (max '(ret)' can be) so this is always the same.
arch/arm/mach-omap2/dpll3xxx.c:629 omap3_clkoutx2_recalc() error: we previously
assumed 'pclk' could be null (see line 627)
arch/arm/mach-omap2/board-n8x0.c:422 n8x0_mmc_late_init() Error invalid range
14 to 13
arch/arm/mach-omap1/leds-h2p2-debug.c:71 h2p2_dbg_leds_event() error:
potentially derefencing uninitialized 'fpga'.
arch/arm/mach-omap1/lcd_dma.c:97 omap_set_lcd_dma_b1_rotation() info: ignoring
unreachable code.
arch/arm/mach-omap1/lcd_dma.c:157 set_b1_regs() info: ignoring unreachable code.
arch/arm/mach-omap1/lcd_dma.c:237 set_b1_regs() info: ignoring unreachable code.
arch/arm/mach-omap1/lcd_dma.c:313 omap_request_lcd_dma() info: ignoring
unreachable code.
arch/arm/mach-omap1/lcd_dma.c:340 omap_free_lcd_dma() info: ignoring
unreachable code.
arch/arm/plat-omap/dma.c:200 omap_set_dma_priority() info: ignoring unreachable
code.
arch/arm/plat-omap/dma.c:567 omap_set_dma_dest_burst_mode() info: ignoring
unreachable code.
arch/arm/plat-omap/dma.c:1152 omap_dma_link_lch() info: ignoring unreachable
code.
arch/arm/plat-omap/dma.c:1179 omap_dma_unlink_lch() info: ignoring unreachable
code.
arch/arm/plat-omap/mux.c:79 omap_cfg_reg() Error invalid range 4096 to -1
arch/arm/plat-omap/dma.c:200 omap_set_dma_priority() info: ignoring unreachable
code.
arch/arm/plat-omap/dma.c:567 omap_set_dma_dest_burst_mode() info: ignoring
unreachable code.
Also, convert some nearby printk(KERN_ERR ... into pr_err( ...,
and unwrap some strings.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap1/lcd_dma.c |9 ++---
arch/arm/mach-omap1/leds-h2p2-debug.c | 12 +++-
arch/arm/mach-omap2/dpll3xxx.c|7 +--
arch/arm/mach-omap2/gpio.c|1 +
arch/arm/mach-omap2/gpmc.c|5 ++---
arch/arm/mach-omap2/omap_hwmod.c | 12 ++--
arch/arm/mach-omap2/serial.c |7 +--
arch/arm/mach-omap2/timer.c |2 +-
arch/arm/plat-omap/dma.c | 19 ++-
arch/arm/plat-omap/mux.c |2 +-
10 files changed, 36 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-omap1/lcd_dma.c b/arch/arm/mach-omap1/lcd_dma.c
index 5769c71..6ec931c 100644
--- a/arch/arm/mach-omap1/lcd_dma.c
+++ b/arch/arm/mach-omap1/lcd_dma.c
@@ -94,7 +94,6 @@ void omap_set_lcd_dma_b1_rotation(int rotate)
if (cpu_is_omap15xx()) {
printk(KERN_ERR DMA rotation is not supported in 1510 mode\n);
BUG();
- return;
}
lcd_dma.rotate = rotate;
}
@@ -154,7 +153,6 @@ static void set_b1_regs(void)
break;
default:
BUG();
- return;
}
vxres = lcd_dma.vxres ? lcd_dma.vxres : lcd_dma.xres;
@@ -234,7 +232,6 @@ static void set_b1_regs(void)
break;
default:
BUG();
- return; /* Suppress warning about uninitialized vars */
}
if (cpu_is_omap15xx()) {
@@ -308,9 +305,8 @@ int omap_request_lcd_dma(void (*callback)(u16 status, void
*data),
spin_lock_irq(lcd_dma.lock);
if (lcd_dma.reserved) {
spin_unlock_irq(lcd_dma.lock);
- printk(KERN_ERR LCD DMA channel already reserved\n);
+ pr_err(LCD DMA channel already reserved\n);
BUG();
- return -EBUSY;
}
lcd_dma.reserved = 1;
spin_unlock_irq(lcd_dma.lock);
@@ -335,9 +331,8 @@ void omap_free_lcd_dma(void)
spin_lock(lcd_dma.lock);
if (!lcd_dma.reserved) {
spin_unlock(lcd_dma.lock);
- printk(KERN_ERR LCD DMA is not reserved\n);
+ pr_err(LCD DMA is not reserved\n);
BUG();
- return;
}
if (!cpu_is_omap15xx())
omap_writew(omap_readw(OMAP1610_DMA_LCD_CCR)
[PATCH 2/2] ARM: OMAP: unwrap strings
Find and unwrap wrapped strings in the style:
pr_debug(clockdomain: hardware cannot set/clear wake up of
%s when %s wakes up\n, clkdm1-name, clkdm2-name);
Keeping these strings contiguous seems to be the current Linux kernel
policy.
The offending lines were found with the following command:
pcregrep -rnM '\s*$\s*' arch/arm/*omap*
While here, some messages have been clarified, some pr_warning(
... calls have been converted to pr_warn( ..., and some printk(KERN_*
... have been converted to pr_*.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap1/board-htcherald.c |3 -
arch/arm/mach-omap1/clock.c |4 +
arch/arm/mach-omap1/clock_data.c| 13 ++---
arch/arm/mach-omap1/dma.c |5 +-
arch/arm/mach-omap1/lcd_dma.c |6 +-
arch/arm/mach-omap2/board-n8x0.c|7 +--
arch/arm/mach-omap2/board-overo.c |6 +-
arch/arm/mach-omap2/board-zoom-debugboard.c |7 +--
arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 10 +---
arch/arm/mach-omap2/clkt_clksel.c | 28 +-
arch/arm/mach-omap2/clkt_dpll.c |8 +--
arch/arm/mach-omap2/clock.c | 20 +++
arch/arm/mach-omap2/clock3xxx.c |3 -
arch/arm/mach-omap2/clockdomain.c | 74 ---
arch/arm/mach-omap2/common-board-devices.c |3 -
arch/arm/mach-omap2/id.c|5 +-
arch/arm/mach-omap2/irq.c |5 +-
arch/arm/mach-omap2/omap_hwmod.c|4 +
arch/arm/mach-omap2/opp.c | 15 ++---
arch/arm/mach-omap2/pm.c|4 +
arch/arm/mach-omap2/pm34xx.c|8 +--
arch/arm/mach-omap2/pm44xx.c|8 +--
arch/arm/mach-omap2/powerdomain.c | 36 ++---
arch/arm/mach-omap2/powerdomain2xxx_3xxx.c |4 +
arch/arm/mach-omap2/powerdomain44xx.c |4 +
arch/arm/mach-omap2/prcm.c |8 +--
arch/arm/mach-omap2/serial.c|5 +-
arch/arm/mach-omap2/sr_device.c | 13 ++---
arch/arm/mach-omap2/vc.c|5 +-
arch/arm/mach-omap2/voltage.c | 12 ++--
arch/arm/mach-omap2/vp.c| 16 +++---
arch/arm/plat-omap/dma.c| 42 +++
arch/arm/plat-omap/omap-pm-noop.c | 39 +++---
arch/arm/plat-omap/omap_device.c| 25 -
34 files changed, 203 insertions(+), 252 deletions(-)
diff --git a/arch/arm/mach-omap1/board-htcherald.c
b/arch/arm/mach-omap1/board-htcherald.c
index b3f6e94..f0ef008 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -476,8 +476,7 @@ static void __init htcherald_lcd_init(void)
break;
}
if (!tries)
- printk(KERN_WARNING Timeout waiting for end of frame
- -- LCD may not be available\n);
+ pr_err(Timeout waiting for end of frame -- LCD may not
be available\n);
/* turn off DMA */
reg = omap_readw(OMAP_DMA_LCD_CCR);
diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
index a9ee06b..638f407 100644
--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -587,8 +587,8 @@ void omap1_clk_disable_unused(struct clk *clk)
/* Clocks in the DSP domain need api_ck. Just assume bootloader
* has not enabled any DSP clocks */
if (clk-enable_reg == DSP_IDLECT2) {
- printk(KERN_INFO Skipping reset check for DSP domain
- clock \%s\\n, clk-name);
+ pr_info(Skipping reset check for DSP domain clock \%s\\n,
+ clk-name);
return;
}
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index c007d80..243e8b2 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -776,11 +776,10 @@ static struct clk_functions omap1_clk_functions = {
static void __init omap1_show_rates(void)
{
- pr_notice(Clocking rate (xtal/DPLL1/MPU):
- %ld.%01ld/%ld.%01ld/%ld.%01ld MHz\n,
- ck_ref.rate / 100, (ck_ref.rate / 10) % 10,
- ck_dpll1.rate / 100, (ck_dpll1.rate / 10) % 10,
- arm_ck.rate / 100, (arm_ck.rate / 10) % 10);
+ pr_notice(Clocking rate (xtal/DPLL1/MPU):
%ld.%01ld/%ld.%01ld/%ld.%01ld MHz\n,
+ ck_ref.rate / 100, (ck_ref.rate / 10) % 10,
+ ck_dpll1.rate / 100, (ck_dpll1.rate / 10) % 10,
+ arm_ck.rate / 100, (arm_ck.rate / 10) % 10);
}
u32 cpu_mask;
@@ -848,8 +847,8 @@ int __init omap1_clk_init(void)
if (cpu_is_omap16xx()
Re: [PATCH 1/2] ARM: OMAP: clean up some smatch warnings, fix some printk(KERN_ERR ...
* Paul Walmsley p...@pwsan.com [120807 03:35]:
--- a/arch/arm/mach-omap1/lcd_dma.c
+++ b/arch/arm/mach-omap1/lcd_dma.c
@@ -94,7 +94,6 @@ void omap_set_lcd_dma_b1_rotation(int rotate)
if (cpu_is_omap15xx()) {
printk(KERN_ERR DMA rotation is not supported in 1510 mode\n);
BUG();
- return;
}
lcd_dma.rotate = rotate;
}
@@ -154,7 +153,6 @@ static void set_b1_regs(void)
break;
default:
BUG();
- return;
}
vxres = lcd_dma.vxres ? lcd_dma.vxres : lcd_dma.xres;
@@ -234,7 +232,6 @@ static void set_b1_regs(void)
break;
default:
BUG();
- return; /* Suppress warning about uninitialized vars */
}
if (cpu_is_omap15xx()) {
I think these will cause new randconfig warnings without CONFIG_BUG set.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] arm/dts: Mark vcxio, v2v1 and v1v8 regulators as always on
* Rajendra Nayak rna...@ti.com [120730 06:17]: vcxio, v2v1 and v1v8 are expected to be always on, update the dtsi for twl6030 to reflect this. commit '86f5fc' regulator: core: Mark all DT based boards as having full constraints) caused these to be disabled at late boot causing OMAP4 boards (using twl6030) to lockup. Thanks I'll apply this one into fixes. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] OMAPDSS: DISPC: Remove cpu_is_xxxx checks
Hi,
On Tue, 2012-08-07 at 13:57 +0530, Chandrabhanu Mahapatra wrote:
The cpu_is checks have been removed from DISPC providing it a much generic and
cleaner interface. The OMAP version and revision specific functions are
initialized by dispc_ops structure in dss features.
I think this needs some changes. I think our general approach to these
version differences should be such that the component in question (dispc
in this case) should ask from somewhere what the DSS version is, and
then using that version, handle the different versions internally.
What that means related to this patch is that we should keep all those
functions static, and initialize the dispc_ops structure inside dispc.c.
However, we don't have any such DSS version yet. I have previously
wanted to move the cpu_is checks to one place (dss_features), but I
think it's probably cleaner if we allow cpu_is checks in the other files
also. However, there should be only one place in the file where those
should be.
So I think we should have something like this, called from
omap_dispchw_probe():
static void dispc_init_features(void)
{
if (cpu_is_foo())
setup features for this omap;
else if (...)
...
}
This would setup the ops, or whatever is needed. This function would be
the only place in dispc.c that contains cpu_is checks.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] driver: misc: bmp085: remove of_match_table property.
On Tue, Aug 07, 2012 at 08:43:44AM +0300, Felipe Balbi wrote: On Mon, Aug 06, 2012 at 04:42:14PM +0100, Mark Brown wrote: 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 If that's all that's done it seems like a bug frankly, certainly based on previous discussions it ought to be. There are collisions out there, they've just happened to not bite us yet string is just churn and has no use at all. This is device tree we're talking about, there's a lot churn anyway. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] OMAPDSS: DISPC: Remove cpu_is_xxxx checks
On Tue, 2012-08-07 at 13:27 +0300, Felipe Balbi wrote: Hi, Yes, they can be overridden, but I think it's still quite difficult to manage. DSS is modeled with multiple blocks, also in DT data. So you'd need to override multiple entries. And it'd also require a new dts file for each version of your board with different ES version. Also, I don't really see why this information would need to be present in the DT data (especially as it's not simple). It's all trivially found out in the code, by using cpu_is soc_is. Fair enough. I just think we should remove all cpu_is_* and soc_is_* from drivers. I agree, that's part of the idea here. Instead of having cpu_is checks all around, we'll have them in only certain centralized places. Then it's easier to implement a way to move them totally out of the driver, when we come up with a good idea how to accomplish that. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] Revert ARM: OMAP3530evm: set pendown_state and debounce time for ads7846
* Kevin Hilman khil...@ti.com [120806 13:52]: 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. Yes thanks pulling into fixes. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap_vout: Set DSS overlay_info only if paddr is non zero
On Thursday 28 June 2012 11:36:48 Semwal, Sumit wrote:
On Mon, Mar 19, 2012 at 5:16 PM, Archit Taneja a0393...@ti.com wrote:
On Monday 19 March 2012 02:15 PM, Hiremath, Vaibhav wrote:
On Fri, Mar 16, 2012 at 16:41:27, Taneja, Archit wrote:
On Friday 16 March 2012 03:46 PM, Archit Taneja wrote:
On Monday 12 March 2012 03:34 PM, Hiremath, Vaibhav wrote:
On Wed, Mar 07, 2012 at 14:31:16, Taneja, Archit wrote:
The omap_vout driver tries to set the DSS overlay_info using
set_overlay_info() when the physical address for the overlay is still
not configured. This happens in omap_vout_probe() and
vidioc_s_fmt_vid_out().
The calls to omapvid_init(which internally calls set_overlay_info())
are removed from these functions. They don't need to be called as the
omap_vout_device struct anyway maintains the overlay related changes
made. Also, remove the explicit call to set_overlay_info() in
vidioc_streamon(), this was used to set the paddr, this isn't needed
as omapvid_init() does the same thing later.
These changes are required as the DSS2 driver since 3.3 kernel
doesn't let you set the overlay info with paddr as 0.
Signed-off-by: Archit Tanejaarc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 36 ---
1 files changed, 5 insertions(+), 31 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 1fb7d5b..dffcf66 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1157,13 +1157,6 @@ static int vidioc_s_fmt_vid_out(struct file
*file, void *fh,
/* set default crop and win */
omap_vout_new_format(vout-pix,vout-fbuf,vout-crop,vout-win);
- /* Save the changes in the overlay strcuture */
- ret = omapvid_init(vout, 0);
- if (ret) {
- v4l2_err(vout-vid_dev-v4l2_dev, failed to change mode\n);
- goto s_fmt_vid_out_exit;
- }
-
ret = 0;
s_fmt_vid_out_exit:
@@ -1664,20 +1657,6 @@ static int vidioc_streamon(struct file *file,
void *fh, enum v4l2_buf_type i)
omap_dispc_register_isr(omap_vout_isr, vout, mask);
- for (j = 0; j ovid-num_overlays; j++) {
- struct omap_overlay *ovl = ovid-overlays[j];
-
- if (ovl-manager ovl-manager-device) {
- struct omap_overlay_info info;
- ovl-get_overlay_info(ovl,info);
- info.paddr = addr;
- if (ovl-set_overlay_info(ovl,info)) {
- ret = -EINVAL;
- goto streamon_err1;
- }
- }
- }
-
Have you checked for build warnings? I am getting build warnings
CC drivers/media/video/omap/omap_vout.o
CC drivers/media/video/omap/omap_voutlib.o
CC drivers/media/video/omap/omap_vout_vrfb.o
drivers/media/video/omap/omap_vout.c: In function 'vidioc_streamon':
drivers/media/video/omap/omap_vout.c:1619:25: warning: unused variable
'ovid'
drivers/media/video/omap/omap_vout.c:1615:15: warning: unused variable
'j'
LD drivers/media/video/omap/omap-vout.o
LD drivers/media/video/omap/built-in.o
Can you fix this and submit the next version?
I applied the patch on the current mainline kernel, it doesn't give any
build warnings. Even after applying the patch, 'j and ovid' are still
used in vidioc_streamon().
Can you check if it was applied correctly?
Archit,
I could able to trace what's going on here,
I am using v4l_for_linus branch, which has one missing patch,
commit aaa874a985158383c4b394c687c716ef26288741
Author: Tomi Valkeinentomi.valkei...@ti.com
Date: Tue Nov 15 16:37:53 2011 +0200
OMAPDSS: APPLY: rewrite overlay enable/disable
So, I do not have below changes,
@@ -1686,6 +1681,16 @@ static int vidioc_streamon(struct file *file, void
*fh, enum v4l2_buf_type i)
if (ret)
v4l2_err(vout-vid_dev-v4l2_dev, failed to change
mode\n);
+ for (j = 0; j ovid-num_overlays; j++) {
+ struct omap_overlay *ovl = ovid-overlays[j];
+
+ if (ovl-manager ovl-manager-device) {
+ ret = ovl-enable(ovl);
+ if (ret)
+ goto streamon_err1;
+ }
+ }
+
This explains why I am seeing these warnings. Let me give pull request
based on master branch.
Okay. Thanks for looking into this.
Archit
Hi Vaibhav,
This patch has been outstanding since March, and we have received
reports from various users. Could you please push it ASAP to Mauro for
the upcoming -rc?
I second this request. Vaibhav, could you please take care of this ?
Or Did I miss a pull request from you containing this?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP: Configuring CONTROL_DEVCONF0 register via DT with pinctrl
* Peter Ujfalusi peter.ujfal...@ti.com [120727 02:47]:
Hello,
I need to find a solution to control 2 bits in CONTROL_DEVCONF0 on OMAP2/3 for
McBSP1 CLKR/FSR signal routing.
In boards using McBSP1 we might need to change bit 3 and 4 based on the audio
setup (how the board has been wired).
So far I have come up with the following idea to handle to but not really sure
if it is the correct way (I have taken the idea from the arm/dts: Add AM33XX
basic pinctrl support series).
You need to also consider that CONTROL_DEVCONF0 has the MMC/SDIO module input
clock selection. So pinctrl-single binding would have to be expanded to also
support one-bit-per-mux type registers in addition to one-register-per-mux
registers. And then this could also be used for the MMC/SDIO module input clock.
In .dtsi file of the SoC:
control_devconf0: pinmux@48002274 {
compatible = pinctrl-single;
reg = 0x48002274 4; /* Single register */
#address-cells = 1;
#size-cells = 0;
pinctrl-single,register-width = 32;
pinctrl-single,function-mask = 0x5F;
};
The pinctrl-single,function-mask is for all the registers in the range,
we also need something to specify the device specific mux bits.
In the .dts file of the board which needs to change the CLKR/FSR
configuration:
control_devconf0 {
pinctrl-names = default;
pinctrl-0 = mcbsp1_pins;
mcbsp1_pins: pinmux_mcbsp1_pins {
pinctrl-single,pins = 0x00 0x18; /* CLKR/FSR from CLKX/FSX
* pin */
};
};
I think adding support for one-bit-per-mux would require adding something
like this for the binding:
mcbsp1_pins: pinmux_mcbsp1_pins {
/* offset bits mask */
pinctrl-single,bits = 0x00 0x18 0x18;
};
As otherwise you would not know which bits to clear for alternative
named modes. Or got any better ideas?
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] OMAPDSS: DISPC: Remove cpu_is_xxxx checks
* Tomi Valkeinen tomi.valkei...@ti.com [120807 03:57]: On Tue, 2012-08-07 at 13:27 +0300, Felipe Balbi wrote: Hi, Yes, they can be overridden, but I think it's still quite difficult to manage. DSS is modeled with multiple blocks, also in DT data. So you'd need to override multiple entries. And it'd also require a new dts file for each version of your board with different ES version. Also, I don't really see why this information would need to be present in the DT data (especially as it's not simple). It's all trivially found out in the code, by using cpu_is soc_is. Fair enough. I just think we should remove all cpu_is_* and soc_is_* from drivers. I agree, that's part of the idea here. Instead of having cpu_is checks all around, we'll have them in only certain centralized places. Then it's easier to implement a way to move them totally out of the driver, when we come up with a good idea how to accomplish that. Yes limiting them to driver init and setting some driver specific flags based on that is a good start. But eventually no drivers should have those checks. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller
Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM
APIs control clocks for C_CAN/D_CAN IP and prevent access to the
register of C_CAN/D_CAN IP when clock is turned off.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
This patch has been tested on AM335X EVM. Due to lack of hardware
I am not able to test c_can functionality. I appreciate if anyone
can test c_can functionality with this patch.
This patch is based on can-next/master
Changes from v4:
- Incorporated Vaibhav H review comments on v4.
* Moved pm_runtime put/get_sync calls to appropriate positions.
- This patch is from Add DT support to C_CAN/D_CAN controller
patch series. Rest of the patches in this series were applied
so this v5 contains only this patch.
drivers/net/can/c_can/c_can.c |8
drivers/net/can/c_can/c_can.h |1 +
drivers/net/can/c_can/c_can_platform.c | 11 +++
3 files changed, 20 insertions(+)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index eea6608..ca1151d 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -34,6 +34,8 @@
#include linux/if_ether.h
#include linux/list.h
#include linux/io.h
+#include linux/pm_runtime.h
+#include linux/platform_device.h
#include linux/can.h
#include linux/can/dev.h
@@ -673,6 +675,8 @@ static int c_can_get_berr_counter(const struct net_device
*dev,
unsigned int reg_err_counter;
struct c_can_priv *priv = netdev_priv(dev);
+ pm_runtime_get_sync(priv-pdev-dev);
+
reg_err_counter = priv-read_reg(priv, C_CAN_ERR_CNT_REG);
bec-rxerr = (reg_err_counter ERR_CNT_REC_MASK)
ERR_CNT_REC_SHIFT;
@@ -1053,6 +1057,8 @@ static int c_can_open(struct net_device *dev)
int err;
struct c_can_priv *priv = netdev_priv(dev);
+ pm_runtime_get_sync(priv-pdev-dev);
+
/* open the can device */
err = open_candev(dev);
if (err) {
@@ -1079,6 +1085,7 @@ static int c_can_open(struct net_device *dev)
exit_irq_fail:
close_candev(dev);
+ pm_runtime_put_sync(priv-pdev-dev);
return err;
}
@@ -1091,6 +1098,7 @@ static int c_can_close(struct net_device *dev)
c_can_stop(dev);
free_irq(dev-irq, dev);
close_candev(dev);
+ pm_runtime_put_sync(priv-pdev-dev);
return 0;
}
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 4e56baa..ef84439 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -153,6 +153,7 @@ struct c_can_priv {
struct can_priv can;/* must be the first member */
struct napi_struct napi;
struct net_device *dev;
+ struct platform_device *pdev;
int tx_object;
int current_status;
int last_status;
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index d0a66cf..cbb1184 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -32,6 +32,7 @@
#include linux/clk.h
#include linux/of.h
#include linux/of_device.h
+#include linux/pm_runtime.h
#include linux/can/dev.h
@@ -177,7 +178,11 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
goto exit_free_device;
}
+ pm_runtime_enable(pdev-dev);
+ pm_runtime_get_sync(pdev-dev);
+
dev-irq = irq;
+ priv-pdev = pdev;
priv-base = addr;
priv-can.clock.freq = clk_get_rate(clk);
priv-priv = clk;
@@ -192,12 +197,16 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
goto exit_free_device;
}
+ pm_runtime_put_sync(pdev-dev);
+
dev_info(pdev-dev, %s device registered (regs=%p, irq=%d)\n,
KBUILD_MODNAME, priv-base, dev-irq);
return 0;
exit_free_device:
platform_set_drvdata(pdev, NULL);
+ pm_runtime_put_sync(pdev-dev);
+ pm_runtime_disable(pdev-dev);
free_c_can_dev(dev);
exit_iounmap:
iounmap(addr);
@@ -226,6 +235,8 @@ static int __devexit c_can_plat_remove(struct
platform_device *pdev)
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
release_mem_region(mem-start, resource_size(mem));
+ pm_runtime_put_sync(pdev-dev);
+ pm_runtime_disable(pdev-dev);
clk_put(priv-priv);
return 0;
--
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] spi: omap2-mcspi: In case of dma errors fall back to pio
On Tuesday 07 August 2012 01:17 PM, Tony Lindgren wrote: }; Don't you need to check separately for rx and tx dma? There's a slight chance that you get a channel for one but not for the other.. In that case I treat it as non usable and fall back to pio. Are you suggesting that let one channel be dma and only the failed one pio? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] i2c: omap: few more patches
On Monday 06 August 2012 07:48 PM, Felipe Balbi wrote: 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. Thanks for the patches. All patches boot tested with pandaboard. Tested-by: Shubhrajyoti shubhrajy...@ti.com On omap4sdp and omap3sdp also on omap3 did some basic power testing. 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(-) -- 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 4/4] i2c: omap: switch over to autosuspend API
Hi Felipe, On Monday 06 August 2012 07:48 PM, Felipe Balbi wrote: this helps us reduce unnecessary pm transitions in case we have another i2c message been started soon. Signed-off-by: Felipe Balbi ba...@ti.com --- 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); Should we mark it last busy stamp here here? Or it may not take effect till the first transaction. + pm_runtime_put_autosuspend(dev-dev); return 0; -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/2] arm/dts: AM33XX: Add D_CAN device tree data
Vaibhav,
Thanks for the review.
On Fri, Aug 03, 2012 at 11:58:41, Hiremath, Vaibhav wrote:
On 7/25/2012 5:53 PM, AnilKumar Ch wrote:
Add Bosch D_CAN controller device tree data to AM33XX dtsi file
by adding d_can device node with all the necessary parameters.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 9b974dc..2db2ffb 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -163,5 +163,10 @@
#size-cells = 0;
ti,hwmods = i2c3;
};
+
+ dcan1: d_can@481D {
+ compatible = bosch,d_can;
+ ti,hwmods = d_can1;
+ };
Anil,
Any reason why we are only specifying dcan1 instance? Shouldn't we
specify dcan0 as well here?
Yes, I agree dcan0 needs to add because SoC support two instances. I
have added d_can1 only because on AM335x-EVM d_can1 is available and
in other case AM335x-bone have two instances available. I will send next
version of these patches.
Regards
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
Re: [PATCH v5] can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller
On 08/07/2012 01:20 PM, AnilKumar Ch wrote:
Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM
APIs control clocks for C_CAN/D_CAN IP and prevent access to the
register of C_CAN/D_CAN IP when clock is turned off.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
This patch has been tested on AM335X EVM. Due to lack of hardware
I am not able to test c_can functionality. I appreciate if anyone
can test c_can functionality with this patch.
The priv-pdev-dev will not work for c_can/d_can which are not using
the platform driver. Options:
a) priv-dev
add a struct device pointer to the priv, and
1) guard pm_runtime_get_sync() for priv-dev == NULL
(or check if pm_runtime_get_sync copes with NULL pointer)
- or -
2) fill in the priv-dev in all other drivers (i.e. PCI)
and check if it makes sense/works to call it on PCI hardware
b) convert all other drivers, i.e. the PCI driver to create a
platform device
Without thinking long, I suggest to a) with flavour 1)
Maybe there are better solutions.
Marc
More comments inline:
This patch is based on can-next/master
Changes from v4:
- Incorporated Vaibhav H review comments on v4.
* Moved pm_runtime put/get_sync calls to appropriate positions.
- This patch is from Add DT support to C_CAN/D_CAN controller
patch series. Rest of the patches in this series were applied
so this v5 contains only this patch.
drivers/net/can/c_can/c_can.c |8
drivers/net/can/c_can/c_can.h |1 +
drivers/net/can/c_can/c_can_platform.c | 11 +++
3 files changed, 20 insertions(+)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index eea6608..ca1151d 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -34,6 +34,8 @@
#include linux/if_ether.h
#include linux/list.h
#include linux/io.h
+#include linux/pm_runtime.h
+#include linux/platform_device.h
#include linux/can.h
#include linux/can/dev.h
@@ -673,6 +675,8 @@ static int c_can_get_berr_counter(const struct net_device
*dev,
unsigned int reg_err_counter;
struct c_can_priv *priv = netdev_priv(dev);
+ pm_runtime_get_sync(priv-pdev-dev);
+
Why do you make a get_sync() here, where's the correspondning put_sync()?
reg_err_counter = priv-read_reg(priv, C_CAN_ERR_CNT_REG);
bec-rxerr = (reg_err_counter ERR_CNT_REC_MASK)
ERR_CNT_REC_SHIFT;
@@ -1053,6 +1057,8 @@ static int c_can_open(struct net_device *dev)
int err;
struct c_can_priv *priv = netdev_priv(dev);
+ pm_runtime_get_sync(priv-pdev-dev);
+
/* open the can device */
err = open_candev(dev);
if (err) {
What if open_candev() fails? Please add a jump label
exit_open_candev_fail and add thje put_sync() there.
goto exit_open_candev_fail;
@@ -1079,6 +1085,7 @@ static int c_can_open(struct net_device *dev)
exit_irq_fail:
close_candev(dev);
exit_open_candev_fail:
+ pm_runtime_put_sync(priv-pdev-dev);
return err;
}
@@ -1091,6 +1098,7 @@ static int c_can_close(struct net_device *dev)
c_can_stop(dev);
free_irq(dev-irq, dev);
close_candev(dev);
+ pm_runtime_put_sync(priv-pdev-dev);
return 0;
}
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 4e56baa..ef84439 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -153,6 +153,7 @@ struct c_can_priv {
struct can_priv can;/* must be the first member */
struct napi_struct napi;
struct net_device *dev;
+ struct platform_device *pdev;
int tx_object;
int current_status;
int last_status;
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index d0a66cf..cbb1184 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -32,6 +32,7 @@
#include linux/clk.h
#include linux/of.h
#include linux/of_device.h
+#include linux/pm_runtime.h
#include linux/can/dev.h
@@ -177,7 +178,11 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
goto exit_free_device;
}
+ pm_runtime_enable(pdev-dev);
+ pm_runtime_get_sync(pdev-dev);
+
dev-irq = irq;
+ priv-pdev = pdev;
priv-base = addr;
priv-can.clock.freq = clk_get_rate(clk);
priv-priv = clk;
@@ -192,12 +197,16 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
goto exit_free_device;
}
+ pm_runtime_put_sync(pdev-dev);
+
dev_info(pdev-dev, %s device registered (regs=%p, irq=%d)\n,
KBUILD_MODNAME, priv-base, dev-irq);
return 0;
exit_free_device:
platform_set_drvdata(pdev, NULL);
+ pm_runtime_put_sync(pdev-dev);
+
Re: [PATCH] spi: omap2-mcspi: In case of dma errors fall back to pio
* Shubhrajyoti shubhrajy...@ti.com [120807 04:21]: On Tuesday 07 August 2012 01:17 PM, Tony Lindgren wrote: }; Don't you need to check separately for rx and tx dma? There's a slight chance that you get a channel for one but not for the other.. In that case I treat it as non usable and fall back to pio. OK that should work too. Are you suggesting that let one channel be dma and only the failed one pio? I guess both are doable. For reduced CPU load using DMA where possible of course is the best way to go. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] i2c: omap: switch over to autosuspend API
Hi, On Mon, Aug 06, 2012 at 05:18:57PM +0300, Felipe Balbi wrote: this helps us reduce unnecessary pm transitions in case we have another i2c message been started soon. Signed-off-by: Felipe Balbi ba...@ti.com --- 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); Probably... nice catch. Will send v2 -- balbi signature.asc Description: Digital signature
[PATCH] 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 ba...@ti.com --- drivers/i2c/busses/i2c-omap.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 60928f2..c210b45 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,8 @@ omap_i2c_probe(struct platform_device *pdev) of_i2c_register_devices(adap); - pm_runtime_put(dev-dev); + pm_runtime_mark_last_busy(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
Re: [PATCH] spi: omap2-mcspi: In case of dma errors fall back to pio
Hi, On Tue, Aug 07, 2012 at 05:02:27AM -0700, Tony Lindgren wrote: * Shubhrajyoti shubhrajy...@ti.com [120807 04:21]: On Tuesday 07 August 2012 01:17 PM, Tony Lindgren wrote: }; Don't you need to check separately for rx and tx dma? There's a slight chance that you get a channel for one but not for the other.. In that case I treat it as non usable and fall back to pio. OK that should work too. Are you suggesting that let one channel be dma and only the failed one pio? I guess both are doable. For reduced CPU load using DMA where possible of course is the best way to go. indeed. if you can get DMA for TX but not for RX, then at least TX can go via DMA ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/6] OMAPDSS: DISPC: Remove cpu_is_xxxx checks
On Tuesday 07 August 2012 04:22 PM, Tomi Valkeinen wrote:
Hi,
On Tue, 2012-08-07 at 13:57 +0530, Chandrabhanu Mahapatra wrote:
The cpu_is checks have been removed from DISPC providing it a much generic
and
cleaner interface. The OMAP version and revision specific functions are
initialized by dispc_ops structure in dss features.
I think this needs some changes. I think our general approach to these
version differences should be such that the component in question (dispc
in this case) should ask from somewhere what the DSS version is, and
then using that version, handle the different versions internally.
What that means related to this patch is that we should keep all those
functions static, and initialize the dispc_ops structure inside dispc.c.
However, we don't have any such DSS version yet. I have previously
wanted to move the cpu_is checks to one place (dss_features), but I
think it's probably cleaner if we allow cpu_is checks in the other files
also. However, there should be only one place in the file where those
should be.
So I think we should have something like this, called from
omap_dispchw_probe():
static void dispc_init_features(void)
{
if (cpu_is_foo())
setup features for this omap;
else if (...)
...
}
This would setup the ops, or whatever is needed. This function would be
the only place in dispc.c that contains cpu_is checks.
Tomi
Yes, this seems good to me. Its better to have all cpu_is checks of
dispc.c and dss.c in their probe functions and by the time
implementation of DSS version come to picture these can be move to dss
features or any other place appropriate. But how to handle OMAP revision
specific functions. Will Dss version handle that too, as like DSS1,
DSS1.1, DSS1.1.1, DSS2 say?
--
Chandrabhanu Mahapatra
Texas Instruments India Pvt. Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] i2c: omap: switch over to autosuspend API
On Tue, Aug 07, 2012 at 17:41:08, Balbi, Felipe wrote: this helps us reduce unnecessary pm transitions in case we have another i2c message been started soon. s/been started/starting ? Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/i2c/busses/i2c-omap.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 60928f2..c210b45 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); I guess there will always be a debate around what's the right delay for autosuspend ;) You can at least replace the magic number with a macro. + 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,8 @@ omap_i2c_probe(struct platform_device *pdev) of_i2c_register_devices(adap); - pm_runtime_put(dev-dev); + pm_runtime_mark_last_busy(dev-dev); + pm_runtime_put_autosuspend(dev-dev); return 0; -- 1.7.12.rc0 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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 4/6] OMAPDSS: VENC: Remove cpu_is_xxxx checks
On Tuesday 07 August 2012 02:21 PM, Felipe Balbi wrote: On Tue, Aug 07, 2012 at 01:58:17PM +0530, Chandrabhanu Mahapatra wrote: OMAP4 checks are removed from VENC to provide it a cleaner interface. These checks were introduced by patches HACK: OMAP: DSS2: VENC: disable VENC on OMAP4 to prevent crash (ba02fa37de) by Tomi Valkeinen tomi.valkei...@ti.com and OMAPDSS: VENC: fix NULL pointer dereference in DSS2 VENC sysfs debug attr on OMAP4 (cc1d3e032d) by Danny Kukawka danny.kuka...@bisect.de to prevent VENC from crashing OMAP4 kernel. An alternative approach is used to do the same in later patches. in later patches ? This means you're causing a regression here. Just swap the patches around to avoid it. Hi! Yes I do agree with you. But as VENC is disabled on omap4, the basic idea here was to remove unnecessary cpu_is checks and achieve the same through a better approach. -- Chandrabhanu Mahapatra Texas Instruments India Pvt. Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] i2c: omap: switch over to autosuspend API
this helps us reduce unnecessary pm transitions
in case we have another i2c message starting soon.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 60928f2..35e8207 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -55,6 +55,9 @@
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
+/* timeout for pm runtime autosuspend */
+#define OMAP_I2C_PM_TIMEOUT1000/* ms */
+
/* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
enum {
OMAP_I2C_REV_REG = 0,
@@ -645,7 +648,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 +1117,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, OMAP_I2C_PM_TIMEOUT);
+ pm_runtime_use_autosuspend(dev-dev);
+
r = pm_runtime_get_sync(dev-dev);
if (IS_ERR_VALUE(r))
goto err_free_mem;
@@ -1189,7 +1196,8 @@ omap_i2c_probe(struct platform_device *pdev)
of_i2c_register_devices(adap);
- pm_runtime_put(dev-dev);
+ pm_runtime_mark_last_busy(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
Re: [PATCH v3] i2c: omap: switch over to autosuspend API
On Tue, Aug 07, 2012 at 03:37:16PM +0300, Felipe Balbi wrote: this helps us reduce unnecessary pm transitions in case we have another i2c message starting soon. Signed-off-by: Felipe Balbi ba...@ti.com ignore this one. sorry -- balbi signature.asc Description: Digital signature
[PATCH v3] i2c: omap: switch over to autosuspend API
this helps us reduce unnecessary pm transitions
in case we have another i2c message starting soon.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 60928f2..35e8207 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -55,6 +55,9 @@
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
+/* timeout for pm runtime autosuspend */
+#define OMAP_I2C_PM_TIMEOUT1000/* ms */
+
/* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
enum {
OMAP_I2C_REV_REG = 0,
@@ -645,7 +648,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 +1117,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, OMAP_I2C_PM_TIMEOUT);
+ pm_runtime_use_autosuspend(dev-dev);
+
r = pm_runtime_get_sync(dev-dev);
if (IS_ERR_VALUE(r))
goto err_free_mem;
@@ -1189,7 +1196,8 @@ omap_i2c_probe(struct platform_device *pdev)
of_i2c_register_devices(adap);
- pm_runtime_put(dev-dev);
+ pm_runtime_mark_last_busy(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
Re: [PATCH 3/4] arm/dts: omap5-evm: Add keypad data
Op 3 aug. 2012, om 14:38 heeft Sourav Poddar sourav.pod...@ti.com het
volgende geschreven:
Add keypad data node in omap5 device tree file.
Also fill the device tree binding parameters
with the required value in omap5-evm dts file.
Tested on omap5430 evm with 3.5 custom kernel.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts | 12
arch/arm/boot/dts/omap5.dtsi|5 +
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 45a8aeb..09fe941 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -17,6 +17,18 @@
device_type = memory;
reg = 0x8000 0x4000; /* 1 GB */
};
+
+ keypad {
+ keypad,num-rows = 8;
+ keypad,num-columns = 8;
+ linux,keymap = 0x02020073
+ 0x02030072
+ 0x020400e7
+ 0x02050066
+ 0x0206006b
+ 0x020700d9 ;
+ linux,input-no-autorepeat;
+ };
Again not a coment on your patch, but on DT:
If DT bindings must be OS independent, what then, is that linux keycode doing
there?
regards,
Koen
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] OMAPDSS: DISPC: Remove cpu_is_xxxx checks
On Tue, 2012-08-07 at 17:52 +0530, Chandrabhanu Mahapatra wrote: Yes, this seems good to me. Its better to have all cpu_is checks of dispc.c and dss.c in their probe functions and by the time implementation of DSS version come to picture these can be move to dss features or any other place appropriate. But how to handle OMAP revision specific functions. Will Dss version handle that too, as like DSS1, DSS1.1, DSS1.1.1, DSS2 say? Yes, something like that. I'm not sure how the version numbers should be created, though. If we had only OMAP, we could use the OMAP version as the DSS major version, and increasing minor version whenever the DSS is changed. So DSS3.2 could be the DSS used on OMAP3 SoCs, and it's the second revision, meaning that early OMAP3 versions would have had an different DSS version. However, the same DSS is used for other SoCs also, so the versioning is not that simple. I guess the other SoCs still always use a DSS that is designed for OMAP, so the major version would be solved by that. For example, AM3xxx DSS version would be DSS3.x. Minor version is more tricky, because OMAP and AM3 DSS can evolve separately, which means that a higher minor version may not contain the fix that exists in a lower minor version. Well, at least currently the AM3xxx's DSS is almost the same as OMAP3's, so perhaps I'm worrying too much. Tomi signature.asc Description: This is a digitally signed message part
[PATCH v2 resend] ARM: OMAP4: twl-common: Support for additional devices on i2c1 bus
On OMAP4 the i2c1 bus is dedicated for the PMIC and audio related devices.
Manufacturers can opt to use different codec than twl6040 and also can add
audio related IC to the bus (external amplifier for example on SDP4430).
Make it possible to add different set of additional devices to i2c1 bus on
OMAP4 boards.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi Tony,
The v2 patch applied cleanly on top of today's mainline (with 2 offset).
It would be really great if this could make it to 3.6, but it is not a big issue
if this can only scheduled for 3.7.
Regards,
Peter
arch/arm/mach-omap2/board-4430sdp.c| 12 -
arch/arm/mach-omap2/board-omap4panda.c | 12 -
arch/arm/mach-omap2/twl-common.c | 37 +--
arch/arm/mach-omap2/twl-common.h |3 +-
4 files changed, 33 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index d4831b6..bcbcad1 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -550,6 +550,14 @@ static struct twl6040_platform_data twl6040_data = {
.irq_base = TWL6040_CODEC_IRQ_BASE,
};
+static struct i2c_board_info __initdata sdp4430_i2c_1_boardinfo[] = {
+ {
+ I2C_BOARD_INFO(twl6040, 0x4b),
+ .irq = OMAP44XX_IRQ_SYS_2N,
+ .platform_data = twl6040_data,
+ },
+};
+
static struct twl4030_platform_data sdp4430_twldata = {
/* Regulators */
.vusim = sdp4430_vusim,
@@ -583,8 +591,8 @@ static int __init omap4_i2c_init(void)
TWL_COMMON_REGULATOR_CLK32KG |
TWL_COMMON_REGULATOR_V1V8 |
TWL_COMMON_REGULATOR_V2V1);
- omap4_pmic_init(twl6030, sdp4430_twldata,
- twl6040_data, OMAP44XX_IRQ_SYS_2N);
+ omap4_pmic_init(twl6030, sdp4430_twldata, sdp4430_i2c_1_boardinfo,
+ ARRAY_SIZE(sdp4430_i2c_1_boardinfo));
omap_register_i2c_bus(2, 400, NULL, 0);
omap_register_i2c_bus(3, 400, sdp4430_i2c_3_boardinfo,
ARRAY_SIZE(sdp4430_i2c_3_boardinfo));
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 70f6d1d..5e18927 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -266,6 +266,14 @@ static struct twl6040_platform_data twl6040_data = {
.irq_base = TWL6040_CODEC_IRQ_BASE,
};
+static struct i2c_board_info __initdata panda_i2c_1_boardinfo[] = {
+ {
+ I2C_BOARD_INFO(twl6040, 0x4b),
+ .irq = OMAP44XX_IRQ_SYS_2N,
+ .platform_data = twl6040_data,
+ },
+};
+
/* Panda board uses the common PMIC configuration */
static struct twl4030_platform_data omap4_panda_twldata;
@@ -293,8 +301,8 @@ static int __init omap4_panda_i2c_init(void)
TWL_COMMON_REGULATOR_CLK32KG |
TWL_COMMON_REGULATOR_V1V8 |
TWL_COMMON_REGULATOR_V2V1);
- omap4_pmic_init(twl6030, omap4_panda_twldata,
- twl6040_data, OMAP44XX_IRQ_SYS_2N);
+ omap4_pmic_init(twl6030, omap4_panda_twldata, panda_i2c_1_boardinfo,
+ ARRAY_SIZE(panda_i2c_1_boardinfo));
omap_register_i2c_bus(2, 400, NULL, 0);
/*
* Bus 3 is attached to the DVI port where devices like the pico DLP
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index de47f17..d52be85 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -39,16 +39,6 @@ static struct i2c_board_info __initdata pmic_i2c_board_info
= {
.flags = I2C_CLIENT_WAKE,
};
-static struct i2c_board_info __initdata omap4_i2c1_board_info[] = {
- {
- .addr = 0x48,
- .flags = I2C_CLIENT_WAKE,
- },
- {
- I2C_BOARD_INFO(twl6040, 0x4b),
- },
-};
-
#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static int twl_set_voltage(void *data, int target_uV)
{
@@ -77,30 +67,25 @@ void __init omap_pmic_init(int bus, u32 clkrate,
void __init omap4_pmic_init(const char *pmic_type,
struct twl4030_platform_data *pmic_data,
- struct twl6040_platform_data *twl6040_data, int twl6040_irq)
+ struct i2c_board_info *devices, int nr_devices)
{
/* PMIC part*/
omap_mux_init_signal(sys_nirq1, OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_WAKEUPENABLE);
- strncpy(omap4_i2c1_board_info[0].type, pmic_type,
- sizeof(omap4_i2c1_board_info[0].type));
- omap4_i2c1_board_info[0].irq = OMAP44XX_IRQ_SYS_1N;
- omap4_i2c1_board_info[0].platform_data = pmic_data;
-
- /* TWL6040 audio IC part */
- omap4_i2c1_board_info[1].irq = twl6040_irq;
Re: [PATCH 3/6] OMAPDSS: DSS: Remove cpu_is_xxxx checks
On Tue, 2012-08-07 at 13:58 +0530, Chandrabhanu Mahapatra wrote:
The cpu_is checks have been removed from dss.c providing it a much generic and
cleaner interface. The OMAP version and revision specific functions are
initialized by dss_ops structure in dss features.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dss.c | 114
++--
drivers/video/omap2/dss/dss.h | 23 ++-
drivers/video/omap2/dss/dss_features.c | 40 +++
drivers/video/omap2/dss/dss_features.h |1 +
4 files changed, 141 insertions(+), 37 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 7b1c6ac..c263da7 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -83,6 +83,8 @@ static struct {
boolctx_valid;
u32 ctx[DSS_SZ_REGS / sizeof(u32)];
+
+ const struct dss_ops *ops;
} dss;
static const char * const dss_generic_clk_source_names[] = {
@@ -236,6 +238,15 @@ const char *dss_get_generic_clk_source_name(enum
omap_dss_clk_source clk_src)
return dss_generic_clk_source_names[clk_src];
}
+char *set_dump_clk_str_24_34(void)
+{
+ return %s (%s) = %lu / %lu * 2 = %lu\n;
+}
+
+char *set_dump_clk_str(void)
+{
+ return %s (%s) = %lu / %lu = %lu\n;
+}
You don't need functions for these, or for the max fck div. Just add the
string or the number to the struct.
And I don't really like the format string being separately. It would
probably be better if you instead had just a flag for the x2 multiplier,
and the dump function would check the flag to see which format string it
uses.
@@ -479,10 +511,7 @@ int dss_calc_clock_div(unsigned long req_pck, struct
dss_clock_info *dss_cinfo,
max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
- fck = clk_get_rate(dss.dss_clk);
- if (req_pck == dss.cache_req_pck
- ((cpu_is_omap34xx() prate == dss.cache_prate) ||
- dss.cache_dss_cinfo.fck == fck)) {
+ if (req_pck == dss.cache_req_pck dss.ops-set_dss_cinfo()) {
DSSDBG(dispc clock info found from cache.\n);
*dss_cinfo = dss.cache_dss_cinfo;
*dispc_cinfo = dss.cache_dispc_cinfo;
This is quite confusing. set function should set something, normally
something that is given as a parameter. Your function seems to be
checking some values.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: v3.6-rc1 DSS issues/regression
On Tue, 2012-08-07 at 12:05 +0530, Archit Taneja wrote: 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 arc...@ti.com 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? No real ideas. I think adding the line above, and a big HACK comment above it, is ok for the time being. It's quite simple hack and shouldn't cause any problems anywhere. Aaro, if you have spare time, you could test and move the call to dispc_mgr_set_clock_div later, and see where calling it stops fixing the issue. My guess is that calling it after dss_sdi_init() will still work, but calling it after dss_sdi_enable() does not work. And most likely inside dss_sdi_enable() it won't work if placed after dispc_pck_free_enable(). Tomi signature.asc Description: This is a digitally signed message part
[PATCH] arm: OMAP3+: am33xx: Add new clk node entry for d_can modules
The d_can0/1 module integrated with AM335x device, requires
only one clock (fck) and driver expects clock to be available
without specifying any connection id (con_id) -
clk_get(pdev-dev, NULL);
This is acceptable as module has only one clock and platform
code should respect this request, so create new clock nodes
inside am33xx clock-tree table based on dev_id and con_id = NULL
for both d_can0 and d_can1 instances.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
This patch is boot tested on BeagleBone platform, and checked for
clk_get() api return value.
arch/arm/mach-omap2/clock33xx_data.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index ae27de8..23251fa 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -1027,7 +1027,9 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL, cefuse_fck, cefuse_fck,CK_AM33XX),
CLK(NULL, clkdiv32k_ick,clkdiv32k_ick, CK_AM33XX),
CLK(NULL, dcan0_fck,dcan0_fck, CK_AM33XX),
+ CLK(d_can.0, NULL, dcan0_fck, CK_AM33XX),
CLK(NULL, dcan1_fck,dcan1_fck, CK_AM33XX),
+ CLK(d_can.1, NULL, dcan1_fck, CK_AM33XX),
CLK(NULL, debugss_ick, debugss_ick, CK_AM33XX),
CLK(NULL, pruss_ocp_gclk, pruss_ocp_gclk,
CK_AM33XX),
CLK(davinci-mcasp.0, NULL, mcasp0_fck,CK_AM33XX),
--
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
Re: [RFC 08/17] OMAPDSS: DSI: Maintain own copy of timings in driver data
On Wed, 2012-08-01 at 16:01 +0530, Archit Taneja wrote:
The DSI driver currently relies on the timings in omap_dss_device struct to
configure the DISPC and DSI blocks accordingly. This makes the DSI interface
driver dependent on the omap_dss_device struct.
Make the DPI driver data maintain it's own timings field. The panel driver is
^^^
DSI
expected to call omapdss_dsi_set_timings() to set these timings before the
panel
is enabled.
Signed-off-by: Archit Taneja arc...@ti.comd
---
drivers/video/omap2/displays/panel-taal.c |2 ++
drivers/video/omap2/dss/dsi.c | 27 ++-
include/video/omapdss.h |2 ++
3 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index 3f5acc7..4775580 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -1060,6 +1060,8 @@ static int taal_power_on(struct omap_dss_device *dssdev)
goto err0;
};
+ omapdss_dsi_set_timings(dssdev, td-panel_config-timings);
+
r = omapdss_dsi_display_enable(dssdev);
if (r) {
dev_err(dssdev-dev, failed to enable DSI\n);
Video timings for command mode panel are meaningless. If we need to pass
the resolution of the panel, perhaps we should have a separate function
for that.
However, with a quick glance at dsi.c, we don't even use the
dssdev-panel.timings for cmd mode panel. But we do use
dssdev-get_resolution() in a few places. Those calls could be replaced
by storing the panel size in dsi.c, given with omapdss_dsi_set_size() or
such. We could use the timings field in dsi.c to store them, though.
Tomi
signature.asc
Description: This is a digitally signed message part
[PATCH-V3] ARM: OMAP2+: cpu: Add am33xx device under cpu_class_is_omap2
AM33XX device falls under omap2 class, so make cpu_class_is_omap2() macro true by adding soc_is_am33xx() to existing list of cpu/soc check. This is required to unblock the basic boot support on AM335x platform. Having done that, we still need to sort out properly from common zImage point of view without having to maintain this cpu/soc_is_xxx list. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com --- This patch is boot tested on BeagleBone (using already accepted hwmod patches) Changes from V2: - This change is dropped now, since it breaks common zImage support. Changes from V1: - No code change, added detailed description for common zImage support. arch/arm/plat-omap/include/plat/cpu.h |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index 68b180e..bb5d08a 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -372,7 +372,8 @@ IS_OMAP_TYPE(3430, 0x3430) #define cpu_class_is_omap1() (cpu_is_omap7xx() || cpu_is_omap15xx() || \ cpu_is_omap16xx()) #define cpu_class_is_omap2() (cpu_is_omap24xx() || cpu_is_omap34xx() || \ - cpu_is_omap44xx() || soc_is_omap54xx()) + cpu_is_omap44xx() || soc_is_omap54xx() || \ + soc_is_am33xx()) /* Various silicon revisions for omap2 */ #define OMAP242X_CLASS 0x24200024 -- 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] ARM: AM33XX: board-generic: Add of_dev_auxdata to fix dev_id for CAN module
If the module requires only one clocksource to function, then
driver can very well call clk_get() api with con_id = NULL,
clk = clk_get(dev, NULL);
And platform code should respect this and return valid clk handle.
That means, now the clk_get() api would rely on dev_id, and platform
code should either have clk node with matching dev_id (with con_id=NULL)
or return dummy clk node.
With DT support, we can fix the dev_id for particular module
using struct of_dev_auxdata to satisfy above clk framework requirement.
In case of AM33XX, we required this for the DCAN module, so this
patch adds of_dev_auxdata for both DCAN_0/1 instances.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
---
This patch is boot tested on BeagleBone platform, and checked for
clk_get() return value in d_can module driver.
arch/arm/mach-omap2/board-generic.c | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 6f93a20..c9b7903 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -37,11 +37,27 @@ static struct of_device_id omap_dt_match_table[] __initdata
= {
{ }
};
+/*
+ * Lookup table for attaching a specific name and platform_data pointer to
+ * devices as they get created by of_platform_populate(). Ideally this table
+ * would not exist, but the current clock implementation depends on some
devices
+ * having a specific name OR to satisfy NULL con_id requirement from driver.
+ */
+static const struct of_dev_auxdata am33xx_auxdata_lookup[] __initconst = {
+ OF_DEV_AUXDATA(bosch,d_can, 0x481cc000, d_can.0, NULL),
+ OF_DEV_AUXDATA(bosch,d_can, 0x481d, d_can.1, NULL),
+ { },
+};
+
static void __init omap_generic_init(void)
{
omap_sdrc_init(NULL, NULL);
- of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+ if (of_machine_is_compatible(ti,am33xx))
+ of_platform_populate(NULL, omap_dt_match_table,
+ am33xx_auxdata_lookup, NULL);
+ else
+ of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
}
#ifdef CONFIG_SOC_OMAP2420
--
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
Re: [RFC 13/17] OMAPDSS: SDI: Create a function to set timings
On Wed, 2012-08-01 at 16:01 +0530, Archit Taneja wrote: Create function omapdss_sdi_set_timings(), this can be used by a SDI panel driver without disabling/enabling the SDI interface. This is similar to the set_timings op of the DPI interface driver. It calls sdi_set_mode() which only configures the DISPC timings and DSS/DISPC clock dividers. I don't think this works, as the SDI PLL uses pclk-free, and if pclk changes, PLL lock probably breaks. OMAP3430 TRM explains the sequence how to configure settings on the fly, but that's not very simple. Just turning the output off and on is much easier. Tomi signature.asc Description: This is a digitally signed message part
Re: [RFC 00/17] OMAPDSS: Change way of passing timings from panel driver to interface
On Wed, 2012-08-01 at 16:01 +0530, Archit Taneja wrote: This series tries to make interface drivers less dependent on omap_dss_device which represents a panel/device connected to that interface. The current way of configuring an interface is to populate the panel's omap_dss_device instance with parameters common to the panel and the interface, they are either populated in the board file, or in the panel driver. Panel timings, number of lanes connected to interface, and pixel format are examples of such parameters, these are then extracted by the interface driver to configure itself. The series looks good. I had only a few comments to make, but obviously this needs quite a bit of testing. I'll try it out. Tomi signature.asc Description: This is a digitally signed message part
RE: [PATCH v3] i2c: omap: switch over to autosuspend API
On Tue, Aug 07, 2012 at 18:08:07, Balbi, Felipe wrote: this helps us reduce unnecessary pm transitions in case we have another i2c message starting soon. Signed-off-by: Felipe Balbi ba...@ti.com FWIW, Acked-by: Vaibhav Bedia vaibhav.be...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: clean up some smatch warnings, fix some printk(KERN_ERR ...
On Tue, 7 Aug 2012, Tony Lindgren wrote: I think these will cause new randconfig warnings without CONFIG_BUG set. Thanks for the comment. Did not know BUG() could be disabled. Will drop those changes. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: AM33XX: board-generic: Add of_dev_auxdata to fix dev_id for CAN module
On 08/07/2012 08:37 AM, Vaibhav Hiremath wrote:
If the module requires only one clocksource to function, then
driver can very well call clk_get() api with con_id = NULL,
clk = clk_get(dev, NULL);
And platform code should respect this and return valid clk handle.
That means, now the clk_get() api would rely on dev_id, and platform
code should either have clk node with matching dev_id (with con_id=NULL)
or return dummy clk node.
With DT support, we can fix the dev_id for particular module
using struct of_dev_auxdata to satisfy above clk framework requirement.
In case of AM33XX, we required this for the DCAN module, so this
patch adds of_dev_auxdata for both DCAN_0/1 instances.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
---
This patch is boot tested on BeagleBone platform, and checked for
clk_get() return value in d_can module driver.
arch/arm/mach-omap2/board-generic.c | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 6f93a20..c9b7903 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -37,11 +37,27 @@ static struct of_device_id omap_dt_match_table[]
__initdata = {
{ }
};
+/*
+ * Lookup table for attaching a specific name and platform_data pointer to
+ * devices as they get created by of_platform_populate(). Ideally this table
+ * would not exist, but the current clock implementation depends on some
devices
+ * having a specific name OR to satisfy NULL con_id requirement from driver.
+ */
+static const struct of_dev_auxdata am33xx_auxdata_lookup[] __initconst = {
+ OF_DEV_AUXDATA(bosch,d_can, 0x481cc000, d_can.0, NULL),
+ OF_DEV_AUXDATA(bosch,d_can, 0x481d, d_can.1, NULL),
+ { },
+};
Adding an additional clkdev lookup accomplishes the same thing and is a
cleaner solution.
Rob
+
static void __init omap_generic_init(void)
{
omap_sdrc_init(NULL, NULL);
- of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+ if (of_machine_is_compatible(ti,am33xx))
+ of_platform_populate(NULL, omap_dt_match_table,
+ am33xx_auxdata_lookup, NULL);
+ else
+ of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
}
#ifdef CONFIG_SOC_OMAP2420
--
1.7.0.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 3/4] arm/dts: omap5-evm: Add keypad data
Hi Koen,
On Tue, Aug 7, 2012 at 6:24 PM, Koen Kooi k...@dominion.thruhere.net wrote:
Op 3 aug. 2012, om 14:38 heeft Sourav Poddar sourav.pod...@ti.com het
volgende geschreven:
Add keypad data node in omap5 device tree file.
Also fill the device tree binding parameters
with the required value in omap5-evm dts file.
Tested on omap5430 evm with 3.5 custom kernel.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts | 12
arch/arm/boot/dts/omap5.dtsi|5 +
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts
b/arch/arm/boot/dts/omap5-evm.dts
index 45a8aeb..09fe941 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -17,6 +17,18 @@
device_type = memory;
reg = 0x8000 0x4000; /* 1 GB */
};
+
+ keypad {
+ keypad,num-rows = 8;
+ keypad,num-columns = 8;
+ linux,keymap = 0x02020073
+ 0x02030072
+ 0x020400e7
+ 0x02050066
+ 0x0206006b
+ 0x020700d9 ;
+ linux,input-no-autorepeat;
+ };
Again not a coment on your patch, but on DT:
If DT bindings must be OS independent, what then, is that linux keycode doing
there?
Currently, for all matrix connected keyboards the keymap are defined
in the scope of the
linux key code since that is a stable and standardized interface at this time.
For the above reason , computation of the keymap uses linux keycode
row 24 | column 16 | linux-key-code
I think this is the primary reason for keeping linux prefix with this
property.
regards,
Koen
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: AM33XX: board-generic: Add of_dev_auxdata to fix dev_id for CAN module
On Tue, Aug 07, 2012 at 20:49:48, Rob Herring wrote:
On 08/07/2012 08:37 AM, Vaibhav Hiremath wrote:
If the module requires only one clocksource to function, then
driver can very well call clk_get() api with con_id = NULL,
clk = clk_get(dev, NULL);
And platform code should respect this and return valid clk handle.
That means, now the clk_get() api would rely on dev_id, and platform
code should either have clk node with matching dev_id (with con_id=NULL)
or return dummy clk node.
With DT support, we can fix the dev_id for particular module
using struct of_dev_auxdata to satisfy above clk framework requirement.
In case of AM33XX, we required this for the DCAN module, so this
patch adds of_dev_auxdata for both DCAN_0/1 instances.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
---
This patch is boot tested on BeagleBone platform, and checked for
clk_get() return value in d_can module driver.
arch/arm/mach-omap2/board-generic.c | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 6f93a20..c9b7903 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -37,11 +37,27 @@ static struct of_device_id omap_dt_match_table[]
__initdata = {
{ }
};
+/*
+ * Lookup table for attaching a specific name and platform_data pointer to
+ * devices as they get created by of_platform_populate(). Ideally this
table
+ * would not exist, but the current clock implementation depends on some
devices
+ * having a specific name OR to satisfy NULL con_id requirement from
driver.
+ */
+static const struct of_dev_auxdata am33xx_auxdata_lookup[] __initconst = {
+ OF_DEV_AUXDATA(bosch,d_can, 0x481cc000, d_can.0, NULL),
+ OF_DEV_AUXDATA(bosch,d_can, 0x481d, d_can.1, NULL),
+ { },
+};
Adding an additional clkdev lookup accomplishes the same thing and is a
cleaner solution.
That is also required and I have submitted patch for the same -
http://www.spinics.net/lists/arm-kernel/msg187998.html
With DT support, I am getting dev_id as -
- Without reg property: d_can.16 and d_can.17,
(I believe it changes dynamically here)
- With reg property: 481cc000.d_can and 481d.d_can
Which is not so intuitive, I would like to see them as per Spec/TRM, so
doesn't this patch make sense?
Similar thing has already been done for other platforms too.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: Fix multi.h when only ARCH_OMAP3 and SOC_AM33XX are selected
When only ARCH_OMAP3 (or -2,-4,...) and SOC_AM33XX are selected, multi.h doesn't set MULTI_OMAP2. In this case, cpu.h will simply define cpu_is_omap24xx() as 1. This causes problems for example for omap_hwmod.c:omap_hwmod_init which checks for cpu_is_omap24xx() first, using the wrong soc_ops for AM33xx. Fix this by defining MULTI_OMAP2 when using SOC_AM33XX together with something else. Signed-off-by: Jan Luebbe j...@pengutronix.de --- arch/arm/plat-omap/include/plat/multi.h |9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/plat-omap/include/plat/multi.h b/arch/arm/plat-omap/include/plat/multi.h index 045e320..324d31b 100644 --- a/arch/arm/plat-omap/include/plat/multi.h +++ b/arch/arm/plat-omap/include/plat/multi.h @@ -108,4 +108,13 @@ # endif #endif +#ifdef CONFIG_SOC_AM33XX +# ifdef OMAP_NAME +# undef MULTI_OMAP2 +# define MULTI_OMAP2 +# else +# define OMAP_NAME am33xx +# endif +#endif + #endif /* __PLAT_OMAP_MULTI_H */ -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] driver: misc: bmp085: remove of_match_table property.
On Aug 7, 2012, at 4:52 AM, Mark Brown wrote: On Tue, Aug 07, 2012 at 08:43:44AM +0300, Felipe Balbi wrote: On Mon, Aug 06, 2012 at 04:42:14PM +0100, Mark Brown wrote: 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 If that's all that's done it seems like a bug frankly, certainly based on previous discussions it ought to be. There are collisions out there, they've just happened to not bite us yet Also keep in mind that the device tree is supposed to be a description of the hardware, and different implementations of the device tree may use the compatible string. Warner -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: AM33XX: board-generic: Add of_dev_auxdata to fix dev_id for CAN module
Op 7 aug. 2012, om 17:53 heeft Hiremath, Vaibhav hvaib...@ti.com het
volgende geschreven:
On Tue, Aug 07, 2012 at 20:49:48, Rob Herring wrote:
On 08/07/2012 08:37 AM, Vaibhav Hiremath wrote:
If the module requires only one clocksource to function, then
driver can very well call clk_get() api with con_id = NULL,
clk = clk_get(dev, NULL);
And platform code should respect this and return valid clk handle.
That means, now the clk_get() api would rely on dev_id, and platform
code should either have clk node with matching dev_id (with con_id=NULL)
or return dummy clk node.
With DT support, we can fix the dev_id for particular module
using struct of_dev_auxdata to satisfy above clk framework requirement.
In case of AM33XX, we required this for the DCAN module, so this
patch adds of_dev_auxdata for both DCAN_0/1 instances.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
---
This patch is boot tested on BeagleBone platform, and checked for
clk_get() return value in d_can module driver.
arch/arm/mach-omap2/board-generic.c | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 6f93a20..c9b7903 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -37,11 +37,27 @@ static struct of_device_id omap_dt_match_table[]
__initdata = {
{ }
};
+/*
+ * Lookup table for attaching a specific name and platform_data pointer to
+ * devices as they get created by of_platform_populate(). Ideally this
table
+ * would not exist, but the current clock implementation depends on some
devices
+ * having a specific name OR to satisfy NULL con_id requirement from
driver.
+ */
+static const struct of_dev_auxdata am33xx_auxdata_lookup[] __initconst = {
+ OF_DEV_AUXDATA(bosch,d_can, 0x481cc000, d_can.0, NULL),
+ OF_DEV_AUXDATA(bosch,d_can, 0x481d, d_can.1, NULL),
+ { },
+};
Adding an additional clkdev lookup accomplishes the same thing and is a
cleaner solution.
That is also required and I have submitted patch for the same -
http://www.spinics.net/lists/arm-kernel/msg187998.html
With DT support, I am getting dev_id as -
- Without reg property: d_can.16 and d_can.17,
(I believe it changes dynamically here)
- With reg property: 481cc000.d_can and 481d.d_can
Which is not so intuitive, I would like to see them as per Spec/TRM, so
doesn't this patch make sense?
Similar thing has already been done for other platforms too.
Davinci-mdio has a similar problem
regards,
Koen--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Fix dmtimer set source clock failure
Jon Hunter jon-hun...@ti.com writes:
Calling the dmtimer function omap_dm_timer_set_source() fails if following a
call to pm_runtime_put() to disable the timer. For example the following
sequence would fail to set the parent clock ...
omap_dm_timer_stop(gptimer);
omap_dm_timer_set_source(gptimer, OMAP_TIMER_SRC_32_KHZ);
The following error message would be seen ...
omap_dm_timer_set_source: failed to set timer_32k_ck as parent
The problem is that, by design, pm_runtime_put() simply decrements the usage
count and returns before the timer has actually been disabled. Therefore,
setting the parent clock failed because the timer was still active when the
trying to set the parent clock. Setting a parent clock will fail if the clock
you are setting the parent of has a non-zero usage count. To ensure that this
does not fail use pm_runtime_put_sync() when disabling the timer.
Note that this will not be seen on OMAP1 devices, because these devices do
not use the clock framework for dmtimers.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/dmtimer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 626ad8c..7b6689a 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -258,7 +258,7 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_enable);
void omap_dm_timer_disable(struct omap_dm_timer *timer)
{
- pm_runtime_put(timer-pdev-dev);
+ pm_runtime_put_sync(timer-pdev-dev);
}
EXPORT_SYMBOL_GPL(omap_dm_timer_disable);
--
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] Revert ARM: OMAP3: PM: call pre/post transition per powerdomain
This reverts commit 58f0829b7186150318c79515f0e0850c5e7a9c89.
Converstion to per-pwrdm per/post transition calls was a bit
premature. Only tracking MPU, PER CORE in the idle path means we
lose the accounting for all the other powerdomains which may also
transition in idle. On OMAP3, due to autodeps, several powerdomains
transition along with MPU (e.g. DSS, USBHOST), and the accounting for
these was lost with this patch.
This patch should be revisited when the upcoming clkdm/pwrmdm/voltdm
use-counting seires is merged since then we can properly do accounting
without relying on a call in the idle path.
Cc: Jean Pihet jean.pi...@newoldbits.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Reported-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e4fc88c..05bd8f0 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -272,21 +272,16 @@ void omap_sram_idle(void)
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
- if (mpu_next_state PWRDM_POWER_ON) {
- pwrdm_pre_transition(mpu_pwrdm);
- pwrdm_pre_transition(neon_pwrdm);
- }
+ pwrdm_pre_transition(NULL);
/* PER */
if (per_next_state PWRDM_POWER_ON) {
- pwrdm_pre_transition(per_pwrdm);
per_going_off = (per_next_state == PWRDM_POWER_OFF) ? 1 : 0;
omap2_gpio_prepare_for_idle(per_going_off);
}
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
- pwrdm_pre_transition(core_pwrdm);
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_cm_save_context();
@@ -339,20 +334,14 @@ void omap_sram_idle(void)
omap2_prm_clear_mod_reg_bits(OMAP3430_AUTO_OFF_MASK,
OMAP3430_GR_MOD,
OMAP3_PRM_VOLTCTRL_OFFSET);
- pwrdm_post_transition(core_pwrdm);
}
omap3_intc_resume_idle();
+ pwrdm_post_transition(NULL);
+
/* PER */
- if (per_next_state PWRDM_POWER_ON) {
+ if (per_next_state PWRDM_POWER_ON)
omap2_gpio_resume_after_idle();
- pwrdm_post_transition(per_pwrdm);
- }
-
- if (mpu_next_state PWRDM_POWER_ON) {
- pwrdm_post_transition(mpu_pwrdm);
- pwrdm_post_transition(neon_pwrdm);
- }
}
static void omap3_pm_idle(void)
--
1.7.9.2
--
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] backlight: Add TPS65217 WLED driver
Hi AnilKumar,
thanks for your comments
El Tue, Aug 07, 2012 at 08:59:17AM + AnilKumar, Chimata ha dit:
Can you re-submit the patch based on linux-next tree?
will do
Comments inline
On Wed, Aug 01, 2012 at 01:18:38, Matthias Kaehlcke wrote:
The TPS65217 chip contains a boost converter and current sinks which can be
used to drive LEDs for use as backlights. Expose this functionality via the
backlight API.
Can you provide more details here, like patch is based on which
tree?
this patch was based on current mainline at the time of submission
Testing details of the driver?
the driver has been tested (without device tree) on a custom AM335x
board, running an Androidized 3.2 kernel with AM335x support (rowboat
project)
+#if defined(CONFIG_BACKLIGHT_TPS65217) ||
defined(CONFIG_BACKLIGHT_TPS65217_MODULE)
+#define tps_has_bl() true
+#else
+#define tps_has_bl() false
+#endif
+
Is this really required?
was inspired by the twl-core driver, but can do without it
/**
* tps65217_reg_read: Read a single tps65217 register.
*
@@ -174,6 +180,47 @@ static struct tps65217_board *tps65217_parse_dt(struct
i2c_client *client)
pdata-of_node[i] = reg_matches[i].of_node;
}
+ if (tps_has_bl()) {
+ struct device_node *np = of_find_node_by_name(node,
backlight);
+ if (np) {
This can be changed to
np = of_find_node_by_name(node, backlight);
if (np) {
}
else fall into non-backlight case.
ok
+ u32 val;
+
+ pdata-bl_pdata = devm_kzalloc(client-dev,
sizeof(*pdata-bl_pdata), GFP_KERNEL);
+ if (!pdata-bl_pdata)
+ return NULL;
+
+ if (!of_property_read_u32(np, isel, val)) {
+ if (val == 1) {
+ pdata-bl_pdata-isel =
TPS65217_BL_ISET1;
+ } else if (val == 2) {
+ pdata-bl_pdata-isel =
TPS65217_BL_ISET2;
+ } else {
+ dev_err(client-dev, invalid value
for backlight current limit selection in the device tree\n);
fix checkpatch.pl errors before submitting the patches. More than
80 ch.
in this case it will be hard to read the 80 character limit without
modifying the log string or breaking it artifically into several
lines. i understand the 80 character limit is a soft limit, which can
be violated if readability is actually improve by the violation. i'd
suggest to make the line slightly shorter by putting the log string in
it's own line, but not break the string in between just to reach the
80 char limit
+ return NULL;
Should not return here, need to handle rest of dt portion.
ok
+ }
+ } else {
+ pdata-bl_pdata-isel = TPS65217_BL_ISET1;
+ }
This can be changed to
pdata-bl_pdata-isel = TPS65217_BL_ISET1;
of_property_read_u32(np, isel, val)
if (val TPS65217_BL_ISET2 || val TPS65217_BL_ISET1) {
dev_err(...);
goto rest_dt_portion;
} else {
pdata-bl_pdata-isel = val;
}
ok, this also requires the TPS65217_BL_ISETx enum to start at 1
+
+ if (!of_property_read_u32(np, fdim, val)) {
+ if (val == 100) {
+ pdata-bl_pdata-fdim =
TPS65217_BL_FDIM_100HZ;
+ } else if (val == 200) {
+ pdata-bl_pdata-fdim =
TPS65217_BL_FDIM_200HZ;
+ } else if (val == 500) {
+ pdata-bl_pdata-fdim =
TPS65217_BL_FDIM_500HZ;
+ } else if (val == 1000) {
+ pdata-bl_pdata-fdim =
TPS65217_BL_FDIM_1000HZ;
+ } else {
+ dev_err(client-dev, invalid value
for backlight dimming frequency in the device tree\n);
+ return NULL;
+ }
+ } else {
+ pdata-bl_pdata-fdim = TPS65217_BL_FDIM_200HZ;
+ }
+ }
+ }
Same here.
not exactly, the value specified in the device tree for the dimming
frequency will be a frequency, not a value corresponding to the enum,
so a range check + assignment isn't enough. if you'd like to see a
similar handling an option would be to set TPS65217_BL_FDIM_100HZ to
100, TPS..._200HZ to 200, ..., and do:
switch (val) {
case TPS65217_BL_FDIM_100HZ:
case TPS65217_BL_FDIM_200HZ:
...
pdata-bl_pdata-fdim = val;
break;
default:
/* error handling */
}
+struct tps65217_bl_pdata tps65217_bl_default_pdata = {
+ .isel = TPS65217_BL_ISET1,
+ .fdim
Re: DSS and USBHOST powerdomains not entering low-power states on 37xx EVM
Paul Walmsley p...@pwsan.com writes: Hi Kevin, On Mon, 6 Aug 2012, Kevin Hilman wrote: Is this only happening on this 37xx platform?Just curious, because it seems to be a problem on any OMAP3xxx SoC. So far I've only run the baseline tests on 37xx, so wanted to state only what was observed here. ...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. Thanks for the diagnosis. Care to put together a patch to fix this for v3.6-rc? Done. http://marc.info/?l=linux-omapm=134437239010649w=2 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: [PATCH 1/3] ARM: OMAP: omap_device: keep track of driver bound status
Hi Kevin
a couple of minor comments
On Tue, 10 Jul 2012, Kevin Hilman wrote:
Use the bus notifier to keep track of driver bound status by adding a
new internal field to struct omap_device: _driver_staus.
_driver_status
This will be useful for follow-up patches which need to know whether
or not a driver is bound in order to make intelligent omap_device
enable/idle decisions.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |2 ++
arch/arm/plat-omap/omap_device.c | 14 +-
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 4327b2c..e0486cb 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -60,6 +60,7 @@ extern struct dev_pm_domain omap_device_pm_domain;
* @_dev_wakeup_lat_limit: dev wakeup latency limit in nsec - set by OMAP PM
* @_state: one of OMAP_DEVICE_STATE_* (see above)
* @flags: device flags
+ * @_driver_status: one of BUS_NOTIFY_*_DRIVER from linux/device.h
*
* Integrates omap_hwmod data into Linux platform_device.
*
@@ -78,6 +79,7 @@ struct omap_device {
u8 hwmods_cnt;
u8 _state;
u8 flags;
+ u8 _driver_status;
};
/* Device driver interface (call via platform_data fn ptrs) */
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index c490240..1d1b5ff 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -385,17 +385,21 @@ static int _omap_device_notifier_call(struct
notifier_block *nb,
unsigned long event, void *dev)
{
struct platform_device *pdev = to_platform_device(dev);
+ struct omap_device *od;
switch (event) {
- case BUS_NOTIFY_ADD_DEVICE:
- if (pdev-dev.of_node)
- omap_device_build_from_dt(pdev);
- break;
-
case BUS_NOTIFY_DEL_DEVICE:
if (pdev-archdata.od)
omap_device_delete(pdev-archdata.od);
break;
+ case BUS_NOTIFY_ADD_DEVICE:
+ if (pdev-dev.of_node)
+ omap_device_build_from_dt(pdev);
+ /* fall through */
+ default:
+ od = to_omap_device(pdev);
+ if (od)
+ od-_driver_status = event;
_driver_status is a u8, but event is an unsigned long. Might be worth
adding a WARN() to complain if event is greater than (2^8)-1.
}
return NOTIFY_DONE;
--
1.7.9.2
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: nfsroot problems with v3.6-rc1 on 37xx EVM and dynamic off-mode
Hi Paul, Paul Walmsley p...@pwsan.com writes: NFS is broken on 37xx EVM with v3.6-rc1 after return from off-mode with dynamic idle. System suspend (echo mem /sys/power/state) with off-mode enabled seems to work fine. No obvious ideas here as to what could have broken this. It worked in v3.5-rc2 + my omap_fixes_a_3.5rc at least: http://www.pwsan.com/omap/bootlogs/20120617/omap_fixes_a_3.5rc__52a5ae406dadef781bfcf3a641dae2064e9697ff/37xxevm_bootlog.txt After that, it's hard to tell when this problem started occurring, since CORE stopped entering low-power states on OMAP3 on = v3.5-rc3. I see the same thing with vanilla v3.6-rc1, but it worked in my pm-cur branch which has a few fixes that I'm queuing for v3.6-rc. Tracking it down, it seems the revert patch I just sent out[1] fixes this problem, but I'm still a bit puzzled as to why. Can you try v3.6-rc1 + that revert[1] to see if that fixes the problem for you as well? Thanks, Kevin [1] http://marc.info/?l=linux-omapm=134437239010649w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP: omap_device: keep track of driver bound status
Paul Walmsley p...@pwsan.com writes:
Hi Kevin
a couple of minor comments
On Tue, 10 Jul 2012, Kevin Hilman wrote:
Use the bus notifier to keep track of driver bound status by adding a
new internal field to struct omap_device: _driver_staus.
_driver_status
This will be useful for follow-up patches which need to know whether
or not a driver is bound in order to make intelligent omap_device
enable/idle decisions.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |2 ++
arch/arm/plat-omap/omap_device.c | 14 +-
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 4327b2c..e0486cb 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -60,6 +60,7 @@ extern struct dev_pm_domain omap_device_pm_domain;
* @_dev_wakeup_lat_limit: dev wakeup latency limit in nsec - set by OMAP PM
* @_state: one of OMAP_DEVICE_STATE_* (see above)
* @flags: device flags
+ * @_driver_status: one of BUS_NOTIFY_*_DRIVER from linux/device.h
*
* Integrates omap_hwmod data into Linux platform_device.
*
@@ -78,6 +79,7 @@ struct omap_device {
u8 hwmods_cnt;
u8 _state;
u8 flags;
+u8 _driver_status;
};
/* Device driver interface (call via platform_data fn ptrs) */
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index c490240..1d1b5ff 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -385,17 +385,21 @@ static int _omap_device_notifier_call(struct
notifier_block *nb,
unsigned long event, void *dev)
{
struct platform_device *pdev = to_platform_device(dev);
+struct omap_device *od;
switch (event) {
-case BUS_NOTIFY_ADD_DEVICE:
-if (pdev-dev.of_node)
-omap_device_build_from_dt(pdev);
-break;
-
case BUS_NOTIFY_DEL_DEVICE:
if (pdev-archdata.od)
omap_device_delete(pdev-archdata.od);
break;
+case BUS_NOTIFY_ADD_DEVICE:
+if (pdev-dev.of_node)
+omap_device_build_from_dt(pdev);
+/* fall through */
+default:
+od = to_omap_device(pdev);
+if (od)
+od-_driver_status = event;
_driver_status is a u8, but event is an unsigned long. Might be worth
adding a WARN() to complain if event is greater than (2^8)-1.
It's probably more future proof if I just make _driver_status an
unsigned long, in case the values of those events ever change in the
driver core.
Thanks for the review,
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: [PATCH] Revert ARM: OMAP3: PM: call pre/post transition per powerdomain
Kevin Hilman khil...@ti.com writes: This reverts commit 58f0829b7186150318c79515f0e0850c5e7a9c89. Converstion to per-pwrdm per/post transition calls was a bit premature. Only tracking MPU, PER CORE in the idle path means we lose the accounting for all the other powerdomains which may also transition in idle. On OMAP3, due to autodeps, several powerdomains transition along with MPU (e.g. DSS, USBHOST), and the accounting for these was lost with this patch. This patch should be revisited when the upcoming clkdm/pwrmdm/voltdm use-counting seires is merged since then we can properly do accounting without relying on a call in the idle path. Cc: Jean Pihet jean.pi...@newoldbits.com Cc: Tero Kristo t-kri...@ti.com Cc: Rajendra Nayak rna...@ti.com Reported-by: Paul Walmsley p...@pwsan.com Signed-off-by: Kevin Hilman khil...@ti.com After some debugging with Paul, I found that the patch being reverted here was the cause of another regression: GPIO context not being properly restored after off mode. This caused the nfsroot problems in off-mode on boards with ethernet devices with GPIO IRQ lines (Overo, 37xx EVM, ...) Updating changelog, and will post v2 shortly. 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
[PATCH v2] Revert ARM: OMAP3: PM: call pre/post transition per powerdomain
This reverts commit 58f0829b7186150318c79515f0e0850c5e7a9c89.
Converstion to per-pwrdm per/post transition calls was a bit
premature. Only tracking MPU, PER CORE in the idle path means we
lose the accounting for all the other powerdomains which may also
transition in idle. On OMAP3, due to autodeps, several powerdomains
transition along with MPU (e.g. DSS, USBHOST), and the accounting for
these was lost with this patch. Since the accounting includes the
context loss counters, drivers for devices in those power domains
would never notice context lost, so would likely hang after any
off-mode transitions.
This patch should be revisited when the upcoming clkdm/pwrmdm/voltdm
use-counting seires is merged since then we can properly do accounting
without relying on a call in the idle path.
In addition, the original patch had another bug because the PER
powerdomain accounting was not updated until after the GPIO resume
hook is called. Since gpio_resume_after_idle() checks the context
loss count (which is not yet updated) it would not properly restore
context, leaving the GPIO banks in an undefined state.
Cc: Jean Pihet jean.pi...@newoldbits.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Reported-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e4fc88c..05bd8f0 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -272,21 +272,16 @@ void omap_sram_idle(void)
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
- if (mpu_next_state PWRDM_POWER_ON) {
- pwrdm_pre_transition(mpu_pwrdm);
- pwrdm_pre_transition(neon_pwrdm);
- }
+ pwrdm_pre_transition(NULL);
/* PER */
if (per_next_state PWRDM_POWER_ON) {
- pwrdm_pre_transition(per_pwrdm);
per_going_off = (per_next_state == PWRDM_POWER_OFF) ? 1 : 0;
omap2_gpio_prepare_for_idle(per_going_off);
}
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
- pwrdm_pre_transition(core_pwrdm);
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_cm_save_context();
@@ -339,20 +334,14 @@ void omap_sram_idle(void)
omap2_prm_clear_mod_reg_bits(OMAP3430_AUTO_OFF_MASK,
OMAP3430_GR_MOD,
OMAP3_PRM_VOLTCTRL_OFFSET);
- pwrdm_post_transition(core_pwrdm);
}
omap3_intc_resume_idle();
+ pwrdm_post_transition(NULL);
+
/* PER */
- if (per_next_state PWRDM_POWER_ON) {
+ if (per_next_state PWRDM_POWER_ON)
omap2_gpio_resume_after_idle();
- pwrdm_post_transition(per_pwrdm);
- }
-
- if (mpu_next_state PWRDM_POWER_ON) {
- pwrdm_post_transition(mpu_pwrdm);
- pwrdm_post_transition(neon_pwrdm);
- }
}
static void omap3_pm_idle(void)
--
1.7.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Add device tree support for davinci_mdio driver and fix cpsw DT binding documentation
From: Mugunthan V N mugunthan...@ti.com Date: Mon, 6 Aug 2012 20:35:56 +0530 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 Applied to net-next, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: AM33XX: board-generic: Add of_dev_auxdata to fix dev_id for CAN module
On 08/07/2012 10:53 AM, Hiremath, Vaibhav wrote:
On Tue, Aug 07, 2012 at 20:49:48, Rob Herring wrote:
On 08/07/2012 08:37 AM, Vaibhav Hiremath wrote:
If the module requires only one clocksource to function, then
driver can very well call clk_get() api with con_id = NULL,
clk = clk_get(dev, NULL);
And platform code should respect this and return valid clk handle.
That means, now the clk_get() api would rely on dev_id, and platform
code should either have clk node with matching dev_id (with con_id=NULL)
or return dummy clk node.
With DT support, we can fix the dev_id for particular module
using struct of_dev_auxdata to satisfy above clk framework requirement.
In case of AM33XX, we required this for the DCAN module, so this
patch adds of_dev_auxdata for both DCAN_0/1 instances.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
---
This patch is boot tested on BeagleBone platform, and checked for
clk_get() return value in d_can module driver.
arch/arm/mach-omap2/board-generic.c | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 6f93a20..c9b7903 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -37,11 +37,27 @@ static struct of_device_id omap_dt_match_table[]
__initdata = {
{ }
};
+/*
+ * Lookup table for attaching a specific name and platform_data pointer to
+ * devices as they get created by of_platform_populate(). Ideally this
table
+ * would not exist, but the current clock implementation depends on some
devices
+ * having a specific name OR to satisfy NULL con_id requirement from
driver.
+ */
+static const struct of_dev_auxdata am33xx_auxdata_lookup[] __initconst = {
+ OF_DEV_AUXDATA(bosch,d_can, 0x481cc000, d_can.0, NULL),
+ OF_DEV_AUXDATA(bosch,d_can, 0x481d, d_can.1, NULL),
+ { },
+};
Adding an additional clkdev lookup accomplishes the same thing and is a
cleaner solution.
That is also required and I have submitted patch for the same -
http://www.spinics.net/lists/arm-kernel/msg187998.html
That only adds the non-DT name. What I'm saying is you can have 2 lookup
names for the same clock.
With DT support, I am getting dev_id as -
- Without reg property: d_can.16 and d_can.17,
(I believe it changes dynamically here)
- With reg property: 481cc000.d_can and 481d.d_can
Which is not so intuitive, I would like to see them as per Spec/TRM, so
doesn't this patch make sense?
The spec doesn't have a base address for the module? This name is going
to get used in sysfs anyway, and the old name should be going away.
Similar thing has already been done for other platforms too.
Only ones I haven't reviewed.
Rob
--
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 RFC] mmc: omap_hsmmc: Fix the warning
Hi,
On Tue, Jul 24 2012, Shubhrajyoti D wrote:
The commit 9c17d08 [mmc: omap_hsmmc: ensure probe returns error upon
resource failure] introduced the below warning.
CC drivers/of/of_net.o
drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_probe':
drivers/mmc/host/omap_hsmmc.c:1936: warning: statement with no effect
Fix the same by assigning the error value to ret.
Cc: Kevin Hilman khil...@ti.com
Reported-by: Archit Taneja arc...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index be8631d..3a09f93 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1933,7 +1933,7 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
host-tx_chan = dma_request_channel(mask, omap_dma_filter_fn, tx_req);
if (!host-tx_chan) {
dev_err(mmc_dev(host-mmc), unable to obtain TX DMA engine
channel %u\n, tx_req);
- ret -ENXIO;
+ ret = -ENXIO;
goto err_irq;
}
I think you must be confused -- this warning isn't present in mainline, and
the line in commit 9c17d08 is already correct:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=9c17d08ca183b92c9cfab6537069914a5e0e7e81
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index a9227a7..bc28627 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1931,6 +1931,7 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
res = platform_get_resource_byname(pdev, IORESOURCE_DMA, tx);
if (!res) {
dev_err(mmc_dev(host-mmc), cannot get DMA TX channel\n);
+ ret = -ENXIO;
goto err_irq;
}
host-dma_line_tx = res-start;
@@ -1938,6 +1939,7 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
res = platform_get_resource_byname(pdev, IORESOURCE_DMA, rx);
if (!res) {
dev_err(mmc_dev(host-mmc), cannot get DMA RX channel\n);
+ ret = -ENXIO;
goto err_irq;
}
host-dma_line_rx = res-start;
--
Chris Ball c...@laptop.org http://printf.net/
One Laptop Per Child
--
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] MMC/omap_hsmmc: handle failure of regulator_get better.
Hi,
On Sun, Jul 29 2012, NeilBrown wrote:
1/ if regulator_get fails, return an error. This is important
if it failed with EPROBE_DEFER, as the probe needs to be
deferred.
2/ Don't set .set_power until the regulator has been found, or
the deferred probe will not bother calling omap_hsmmc_reg_get().
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 389a3ee..f052c29 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -299,12 +299,12 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
*host)
struct regulator *reg;
int ocr_value = 0;
- mmc_slot(host).set_power = omap_hsmmc_set_power;
-
reg = regulator_get(host-dev, vmmc);
if (IS_ERR(reg)) {
dev_dbg(host-dev, vmmc regulator missing\n);
+ return PTR_ERR(reg);
} else {
+ mmc_slot(host).set_power = omap_hsmmc_set_power;
host-vcc = reg;
ocr_value = mmc_regulator_get_ocrmask(reg);
if (!mmc_slot(host).ocr_mask) {
Thanks, pushed to mmc-next for 3.7.
- Chris.
--
Chris Ball c...@laptop.org http://printf.net/
One Laptop Per Child
--
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 RFC] mmc: omap_hsmmc: Fix the warning
On Wednesday 08 August 2012 08:22 AM, Chris Ball wrote: I think you must be confused Yes http://permalink.gmane.org/gmane.linux.ports.arm.omap/80525 confused me looks like got fixed I missed the same. Thanks -- 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
