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