[PATCH v2 5/5] usb: musb: omap2430: use the new generic PHY framework

[Kishon Vijay Abraham I]

Use the generic PHY framework API to get the PHY. The usb_phy_set_suspend
and usb_phy_set_resume is replaced with phy_suspend and phy_resume to
align with the new PHY framework.

musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/musb/musb_core.h |2 ++
 drivers/usb/musb/omap2430.c  |   22 --
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7fb4819..78251fd 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct musb;
 struct musb_hw_ep;
@@ -357,6 +358,7 @@ struct musb {
u16 int_tx;
 
struct usb_phy  *xceiv;
+   struct phy  *phy;
 
int nIrq;
unsignedirq_wake:1;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 1762354..99378af 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -345,14 +345,24 @@ static int omap2430_musb_init(struct musb *musb)
 * up through ULPI.  TWL4030-family PMICs include one,
 * which needs a driver, drivers aren't always needed.
 */
-   if (dev->parent->of_node)
+   if (dev->parent->of_node) {
+   musb->phy = devm_of_phy_get(dev->parent, "usb-phy", 0);
+
+   /* We can't totally remove musb->xceiv as of now because
+* musb core uses xceiv.state and xceiv.otg. Once we have
+* a separate state machine to handle otg, these can be moved
+* out of xceiv and then we can start using the generic PHY
+* framework
+*/
musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
"usb-phy", 0);
-   else
+   } else {
musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+   musb->phy = devm_phy_get(dev, 0);
+   }
 
-   if (IS_ERR_OR_NULL(musb->xceiv)) {
-   pr_err("HS USB OTG: no transceiver configured\n");
+   if (IS_ERR_OR_NULL(musb->xceiv) || IS_ERR_OR_NULL(musb->phy)) {
+   dev_err(dev, "no transceiver configured\n");
return -EPROBE_DEFER;
}
 
@@ -608,7 +618,7 @@ static int omap2430_runtime_suspend(struct device *dev)
OTG_INTERFSEL);
 
omap2430_low_level_exit(musb);
-   usb_phy_set_suspend(musb->xceiv, 1);
+   phy_suspend(musb->phy);
}
 
return 0;
@@ -624,7 +634,7 @@ static int omap2430_runtime_resume(struct device *dev)
musb_writel(musb->mregs, OTG_INTERFSEL,
musb->context.otg_interfsel);
 
-   usb_phy_set_suspend(musb->xceiv, 0);
+   phy_resume(musb->phy);
}
 
return 0;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/5] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY without
using phandle, the platform specfic intialization code (say from board file)
should have already called phy_bind with the binding information. The binding
information consists of phy's device name, phy user device name and an index.
The index is used when the same phy user binds to mulitple phys.

PHY drivers should create the PHY by passing phy_descriptor that has
describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
poweron, shutdown.

The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for the sysfs entry is added
in Documentation/ABI/testing/sysfs-class-phy.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/ABI/testing/sysfs-class-phy |   15 +
 Documentation/phy.txt |  113 +++
 MAINTAINERS   |7 +
 drivers/Kconfig   |2 +
 drivers/Makefile  |2 +
 drivers/phy/Kconfig   |   13 +
 drivers/phy/Makefile  |5 +
 drivers/phy/phy-core.c|  519 +
 include/linux/phy/phy.h   |  198 +++
 9 files changed, 874 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-phy
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 include/linux/phy/phy.h

diff --git a/Documentation/ABI/testing/sysfs-class-phy 
b/Documentation/ABI/testing/sysfs-class-phy
new file mode 100644
index 000..ffd9930
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-phy
@@ -0,0 +1,15 @@
+What:  /sys/class/phy//label
+Date:  Feb 2013
+KernelVersion: 3.10
+Contact:   Kishon Vijay Abraham I 
+Description:
+   This is a read-only file for getting the label of the phy.
+
+What:  /sys/class/phy//bind
+Date:  Feb 2013
+KernelVersion: 3.10
+Contact:   Kishon Vijay Abraham I 
+Description:
+   This is a read-only file for reading the phy binding
+   information. It contains the device name of the controller,
+   the index and the device name of the PHY in that order.
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
new file mode 100644
index 000..a850aa0
--- /dev/null
+++ b/Documentation/phy.txt
@@ -0,0 +1,113 @@
+   The Generic PHY Framework
+ Kishon Vijay Abraham I 
+
+This document explains the Generic PHY Framework along with the APIs provided,
+how-to-use, current status and the future work list.
+
+1. Introduction
+
+*PHY* is the abbreviation for physical layer. It is used to connect a device
+to the physical medium e.g., the USB controller has a PHY to provide functions
+such as serialization, de-serialization, encoding, decoding and is responsible
+for obtaining the required data transmission rate. Note that some USB
+controller has PHY functionality embedded into it and others use an external
+PHY. Other peripherals that uses a PHY include Wireless LAN, Ethernet,
+SATA etc.
+
+The intention of creating this framework is to bring the phy drivers spread
+all over the Linux kernel to drivers/phy to increase code re-use and to
+increase code maintainability.
+
+This framework will be of use only to devices that uses external PHY (PHY
+functionality is not embedded within the controller).
+
+2. Creating the PHY
+
+The PHY driver should create the PHY in order for other peripheral controllers
+to make use of it. The PHY framework provides 2 APIs to create the PHY.
+
+struct phy *phy_create(struct device *dev, struct phy_descriptor *desc);
+struct phy *devm_phy_create(struct device *dev, struct phy_descriptor *desc);
+
+The PHY drivers can use one of the above 2 APIs to create the PHY by passing
+the device pointer and the phy_descriptor. phy_descriptor is a structure that
+contains information about the PHY such as label, type, bus_type and phy_ops.
+phy_ops is a set of function pointers for performing PHY operations such as
+init, exit, suspend, resume, poweron and shutdown.
+
+3. Binding the PHY to the controller
+
+The framework provides an API for binding the controller to the PHY in the
+case of non dt boot.
+
+struct phy_bind *phy_bind(const char *dev_name, u8 index,
+   const char *phy_dev_name);
+
+The API fills the phy_bind structure with the dev_name (device name of the
+controller), index and phy_dev_name (device name of the PHY). This will
+be used when the controller requests this phy. This API should be used by
+platform specific initialization code (board file).
+
+In the case of dt boot, the binding in

[PATCH v2 4/5] ARM: OMAP: USB: Add phy binding information

[Kishon Vijay Abraham I]

In order for controllers to get PHY in case of non dt boot, the phy
binding information should be added in the platform specific
initialization code using phy_bind. The previously added usb_bind_phy
can't be removed yet because the musb controller continues to use the
old PHY library which has OTG in it (struct usb_phy has struct usb_otg
as member). Until we have a separate OTG state machine to handle all of
that, the new generic PHY framework and the old phy library will co-exist.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/mach-omap2/board-2430sdp.c  |2 ++
 arch/arm/mach-omap2/board-3430sdp.c  |2 ++
 arch/arm/mach-omap2/board-4430sdp.c  |2 ++
 arch/arm/mach-omap2/board-cm-t35.c   |2 ++
 arch/arm/mach-omap2/board-devkit8000.c   |2 ++
 arch/arm/mach-omap2/board-igep0020.c |2 ++
 arch/arm/mach-omap2/board-ldp.c  |2 ++
 arch/arm/mach-omap2/board-omap3beagle.c  |2 ++
 arch/arm/mach-omap2/board-omap3evm.c |2 ++
 arch/arm/mach-omap2/board-omap3logic.c   |2 ++
 arch/arm/mach-omap2/board-omap3pandora.c |2 ++
 arch/arm/mach-omap2/board-omap3stalker.c |2 ++
 arch/arm/mach-omap2/board-omap3touchbook.c   |2 ++
 arch/arm/mach-omap2/board-omap4panda.c   |2 ++
 arch/arm/mach-omap2/board-overo.c|2 ++
 arch/arm/mach-omap2/board-rm680.c|2 ++
 arch/arm/mach-omap2/board-zoom-peripherals.c |2 ++
 17 files changed, 34 insertions(+)

diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
b/arch/arm/mach-omap2/board-2430sdp.c
index 1337f2c..a28cc5b 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -265,6 +266,7 @@ static void __init omap_2430sdp_init(void)
 
omap_mux_init_signal("usb0hs_stp", OMAP_PULL_ENA | OMAP_PULL_UP);
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+   phy_bind("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
 
board_smc91x_init();
diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 8a2e242..a4f4b8e 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -581,6 +582,7 @@ static void __init omap_3430sdp_init(void)
omap_serial_init();
omap_sdrc_init(hyb18m512160af6_sdrc_params, NULL);
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+   phy_bind("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 8e8efcc..d5bc353 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -698,6 +699,7 @@ static void __init omap_4430sdp_init(void)
omap4_twl6030_hsmmc_init(mmc);
 
usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
+   phy_bind("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
usb_musb_init(&musb_board_data);
 
status = omap_ethernet_init();
diff --git a/arch/arm/mach-omap2/board-cm-t35.c 
b/arch/arm/mach-omap2/board-cm-t35.c
index f1172f2..6860dc9 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -726,6 +727,7 @@ static void __init cm_t3x_common_init(void)
omap_twl4030_audio_init("cm-t3x");
 
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+   phy_bind("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
cm_t35_init_usbh();
cm_t35_init_camera();
diff --git a/arch/arm/mach-omap2/board-devkit8000.c 
b/arch/arm/mach-omap2/board-devkit8000.c
index 77cade52..89c3e64 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -624,6 +625,7 @@ static void __init devkit8000_init(void)
omap_ads7846_init(2, OMAP3_DEVKIT_TS_GPIO, 0, NULL);
 
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+   phy_bind("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
usbhs_init(&usbhs_bdata);
board_nand_init(devkit8000_nand_partitions,
diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index 15e5881..2ef8b31 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -627,6 +628,7 @@ static void __init igep_init(void)

[PATCH v2 0/5] Generic PHY Framework

[Kishon Vijay Abraham I]

Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or without using phandle. To obtain a reference to the PHY
without using phandle, the platform specfic intialization code (say from board
file) should have already called phy_bind with the binding information. The
binding information consists of phy's device name, phy user device name and an
index. The index is used when the same phy user binds to mulitple phys.

This framework will be of use only to devices that uses external PHY (PHY
functionality is not embedded within the controller).

The intention of creating this framework is to bring the phy drivers spread
all over the Linux kernel to drivers/phy to increase code re-use and to
increase code maintainability.

Comments to make PHY as bus wasn't done because PHY devices can be part of
other bus and making a same device attached to multiple bus leads to bad
design.

Changes from v1:
* Added Documentation for the PHY framework
* Added few more APIs mostly w.r.t devres
* Modified omap-usb2 and twl4030 to make use of the new framework

Did USB enumeration testing in panda and beagle.

Kishon Vijay Abraham I (5):
  drivers: phy: add generic PHY framework
  usb: phy: omap-usb2: use the new generic PHY framework
  usb: otg: twl4030: use the new generic PHY framework
  ARM: OMAP: USB: Add phy binding information
  usb: musb: omap2430: use the new generic PHY framework

 Documentation/ABI/testing/sysfs-class-phy|   15 +
 Documentation/phy.txt|  113 ++
 MAINTAINERS  |7 +
 arch/arm/mach-omap2/board-2430sdp.c  |2 +
 arch/arm/mach-omap2/board-3430sdp.c  |2 +
 arch/arm/mach-omap2/board-4430sdp.c  |2 +
 arch/arm/mach-omap2/board-cm-t35.c   |2 +
 arch/arm/mach-omap2/board-devkit8000.c   |2 +
 arch/arm/mach-omap2/board-igep0020.c |2 +
 arch/arm/mach-omap2/board-ldp.c  |2 +
 arch/arm/mach-omap2/board-omap3beagle.c  |2 +
 arch/arm/mach-omap2/board-omap3evm.c |2 +
 arch/arm/mach-omap2/board-omap3logic.c   |2 +
 arch/arm/mach-omap2/board-omap3pandora.c |2 +
 arch/arm/mach-omap2/board-omap3stalker.c |2 +
 arch/arm/mach-omap2/board-omap3touchbook.c   |2 +
 arch/arm/mach-omap2/board-omap4panda.c   |2 +
 arch/arm/mach-omap2/board-overo.c|2 +
 arch/arm/mach-omap2/board-rm680.c|2 +
 arch/arm/mach-omap2/board-zoom-peripherals.c |2 +
 drivers/Kconfig  |2 +
 drivers/Makefile |2 +
 drivers/phy/Kconfig  |   13 +
 drivers/phy/Makefile |5 +
 drivers/phy/phy-core.c   |  519 ++
 drivers/usb/musb/musb_core.h |2 +
 drivers/usb/musb/omap2430.c  |   22 +-
 drivers/usb/otg/twl4030-usb.c|   41 ++
 drivers/usb/phy/omap-usb2.c  |   49 +++
 include/linux/phy/phy.h  |  198 ++
 include/linux/usb/omap_usb.h |3 +
 31 files changed, 1019 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-class-phy
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 include/linux/phy/phy.h

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/5] usb: otg: twl4030: use the new generic PHY framework

[Kishon Vijay Abraham I]

Used the generic PHY framework API to create the PHY. twl4030_usb_suspend
and twl4030_usb_resume is added to phy_ops in order to align
with the new framework.

However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new
framework completely will break OTG. Once we have a separate OTG state machine,
we can get rid of the USB PHY library.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/otg/twl4030-usb.c |   41 +
 1 file changed, 41 insertions(+)

diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index a994715..b79c319 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -145,6 +146,7 @@
 
 struct twl4030_usb {
struct usb_phy  phy;
+   struct phy_descriptor   desc;
struct device   *dev;
 
/* TWL4030 internal USB regulator supplies */
@@ -167,6 +169,7 @@ struct twl4030_usb {
 
 /* internal define on top of container_of */
 #define phy_to_twl(x)  container_of((x), struct twl4030_usb, phy)
+#define desc_to_twl(x) container_of((x), struct twl4030_usb, desc)
 
 /*-*/
 
@@ -575,10 +578,38 @@ static int twl4030_set_host(struct usb_otg *otg, struct 
usb_bus *host)
return 0;
 }
 
+static int twl4030_usb_suspend(struct phy_descriptor *desc)
+{
+   struct twl4030_usb *twl = desc_to_twl(desc);
+
+   twl4030_phy_suspend(twl, 1);
+
+   return 0;
+}
+
+static int twl4030_usb_resume(struct phy_descriptor *desc)
+{
+   struct twl4030_usb *twl = desc_to_twl(desc);
+
+   if (!twl->asleep)
+   return -EBUSY;
+   __twl4030_phy_resume(twl);
+   twl->asleep = 0;
+
+   return 0;
+}
+
+static struct phy_ops ops = {
+   .suspend= twl4030_usb_suspend,
+   .resume = twl4030_usb_resume,
+   .owner  = THIS_MODULE,
+};
+
 static int twl4030_usb_probe(struct platform_device *pdev)
 {
struct twl4030_usb_data *pdata = pdev->dev.platform_data;
struct twl4030_usb  *twl;
+   struct phy  *phy;
int status, err;
struct usb_otg  *otg;
struct device_node  *np = pdev->dev.of_node;
@@ -617,6 +648,16 @@ static int twl4030_usb_probe(struct platform_device *pdev)
otg->set_host   = twl4030_set_host;
otg->set_peripheral = twl4030_set_peripheral;
 
+   twl->desc.ops   = &ops;
+   twl->desc.label = "twl4030";
+   twl->desc.of_node   = pdev->dev.of_node;
+
+   phy = devm_phy_create(twl->dev, &twl->desc);
+   if (IS_ERR(phy)) {
+   dev_dbg(&pdev->dev, "Failed to create PHY\n");
+   return PTR_ERR(phy);
+   }
+
/* init spinlock for workqueue */
spin_lock_init(&twl->lock);
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/5] usb: phy: omap-usb2: use the new generic PHY framework

[Kishon Vijay Abraham I]

Used the generic PHY framework API to create the PHY. omap_usb2_suspend
is split into omap_usb_suspend and omap_usb_resume in order to align
with the new framework.

However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/phy/omap-usb2.c  |   49 ++
 include/linux/usb/omap_usb.h |3 +++
 2 files changed, 52 insertions(+)

diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index 844ab68..924ae59 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -119,9 +119,48 @@ static int omap_usb2_suspend(struct usb_phy *x, int 
suspend)
return 0;
 }
 
+static int omap_usb_suspend(struct phy_descriptor *desc)
+{
+   struct omap_usb *phy = desc_to_omapusb(desc);
+
+   if (!phy->is_suspended) {
+   omap_control_usb_phy_power(phy->control_dev, 0);
+   pm_runtime_put_sync(phy->dev);
+   phy->is_suspended = 1;
+   }
+
+   return 0;
+}
+
+static int omap_usb_resume(struct phy_descriptor *desc)
+{
+   u32 ret;
+   struct omap_usb *phy = desc_to_omapusb(desc);
+
+   if (phy->is_suspended) {
+   ret = pm_runtime_get_sync(phy->dev);
+   if (ret < 0) {
+   dev_err(phy->dev, "get_sync failed with err %d\n",
+   ret);
+   return ret;
+   }
+   omap_control_usb_phy_power(phy->control_dev, 1);
+   phy->is_suspended = 0;
+   }
+
+   return 0;
+}
+
+static struct phy_ops ops = {
+   .suspend= omap_usb_suspend,
+   .resume = omap_usb_resume,
+   .owner  = THIS_MODULE,
+};
+
 static int omap_usb2_probe(struct platform_device *pdev)
 {
struct omap_usb *phy;
+   struct phy  *generic_phy;
struct usb_otg  *otg;
 
phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
@@ -144,6 +183,16 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy->phy.otg= otg;
phy->phy.type   = USB_PHY_TYPE_USB2;
 
+   phy->desc.ops   = &ops;
+   phy->desc.label = "omap-usb2";
+   phy->desc.of_node   = pdev->dev.of_node;
+
+   generic_phy = devm_phy_create(phy->dev, &phy->desc);
+   if (IS_ERR(generic_phy)) {
+   dev_dbg(&pdev->dev, "Failed to create PHY\n");
+   return PTR_ERR(generic_phy);
+   }
+
phy->control_dev = omap_get_control_dev();
if (IS_ERR(phy->control_dev)) {
dev_dbg(&pdev->dev, "Failed to get control device\n");
diff --git a/include/linux/usb/omap_usb.h b/include/linux/usb/omap_usb.h
index 6ae2936..4c6878e 100644
--- a/include/linux/usb/omap_usb.h
+++ b/include/linux/usb/omap_usb.h
@@ -20,6 +20,7 @@
 #define __DRIVERS_OMAP_USB2_H
 
 #include 
+#include 
 #include 
 
 struct usb_dpll_params {
@@ -32,6 +33,7 @@ struct usb_dpll_params {
 
 struct omap_usb {
struct usb_phy  phy;
+   struct phy_descriptor   desc;
struct phy_companion*comparator;
void __iomem*pll_ctrl_base;
struct device   *dev;
@@ -43,6 +45,7 @@ struct omap_usb {
 };
 
 #definephy_to_omapusb(x)   container_of((x), struct omap_usb, phy)
+#definedesc_to_omapusb(x)  container_of((x), struct omap_usb, desc)
 
 #if defined(CONFIG_OMAP_USB2) || defined(CONFIG_OMAP_USB2_MODULE)
 extern int omap_usb2_set_comparator(struct phy_companion *comparator);
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: dts: OMAP3: Add GPMC controller

[Jon Hunter]

On 01/28/2013 11:54 AM, Florian Vaussard wrote:
> Add device-tree support for the GPMC controller on the OMAP3.
> 
> Signed-off-by: Florian Vaussard 
> ---
>  arch/arm/boot/dts/omap3.dtsi |   11 +++
>  1 files changed, 11 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 6c63118..2ddae38 100644
> --- a/arch/arm/boot/dts/omap3.dtsi 
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -403,5 +403,16 @@
>   ti,timer-alwon;
>   ti,timer-secure;
>   };
> +
> + gpmc: gpmc@6e00 {
> + compatible = "ti,omap3430-gpmc";
> + ti,hwmods = "gpmc";
> + reg = <0x6e00 0x100>;

Can you make this size smaller? Although the reference manual states
16MB, the registers use less than 1KB of address space. Hence, it is
pointless mapping all this address space for the gpmc registers.

> + interrupts = <20>;
> + gpmc,num-cs = <8>;
> + gpmc,num-waitpins = <4>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + };
>   };
>  };

Otherwise ...

Reviewed-by: Jon Hunter 

Cheers
Jon

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 net-next 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

[David Miller]

From: Mugunthan V N 
Date: Mon, 18 Feb 2013 13:49:20 +0530

> CPDMA interrupts are not properly acknowledged which leads to interrupt
> storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
> Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
> used for rx and tx respectively.
> 
> Reported-by: Pantelis Antoniou 
> Signed-off-by: Mugunthan V N 

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH, RFC 7/8] ARM: dts: am4372: initial support

[Felipe Balbi]

Hi,

On Mon, Feb 18, 2013 at 05:08:16PM +0530, Afzal Mohammed wrote:
> + uart1: serial@44e09000 {
> + compatible = "ti,am4372-uart","ti,omap2-uart";
> + clock-frequency = <4800>;
> + reg = <0x44e09000 0x2000>;
> + interrupts = <0 72 0x4>;

missing ti,hwmods ??

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC v2 16/18] ARM: OMAP2+: AM33XX: Basic suspend resume support

[Kevin Hilman]

"Bedia, Vaibhav"  writes:

> Hi Kevin,
>
> On Tue, Feb 12, 2013 at 06:57:50, Kevin Hilman wrote:
> [...]
>> > +
>> > +void (*am33xx_do_wfi_sram)(void);
>> 
>> static?
>
> Will fix.
>
> [...]
>
>> > +
>> > +  /*
>> > +   * By default the following IPs do not have MSTANDBY asserted
>> > +   * which is necessary for PER domain transition. If the drivers
>> > +   * are not compiled into the kernel HWMOD code will not change the
>> > +   * state of the IPs if the IP was not never enabled. To ensure
>> > +   * that there no issues with or without the drivers being compiled
>> > +   * in the kernel, we forcefully put these IPs to idle.
>> > +   */
>> > +  omap_hwmod_enable(usb_oh);
>> > +  omap_hwmod_enable(tptc0_oh);
>> > +  omap_hwmod_enable(tptc1_oh);
>> > +  omap_hwmod_enable(tptc2_oh);
>> > +  omap_hwmod_enable(cpsw_oh);
>> > +
>> > +  omap_hwmod_idle(usb_oh);
>> > +  omap_hwmod_idle(tptc0_oh);
>> > +  omap_hwmod_idle(tptc1_oh);
>> > +  omap_hwmod_idle(tptc2_oh);
>> > +  omap_hwmod_idle(cpsw_oh);
>> 
>> I think I asked this in my review of v1, but why does this need to
>> happen on every suspend attempt?
>> 
>> This should happen once on init, which will handle the case where there
>> are no drivers, and if there are drivers, then the drivers need to
>> handle this properly.  
>> 
>> I don't like this happening here on every suspend attempt, because it
>> will surely hide bugs where drivers are not properly managing their own PM.
>> 
>
> By default these IPs don't have MSTANDBY asserted.

When you say "by default", I guess you mean after reset (and/or context
loss), right?

> When a low power transition happens, the peripheral power domain loses
> context and hence the forced MSTANDBY configuration in the IP is
> lost. To work around this problem we need to assert MSTANDBY in every
> suspend-resume iteration.

Yuck.  More clever hardware.  ;)

> I agree that this might hide PM bugs in the driver but to solve this problem 
> we
> need some mechanism for the PM code to know whether or not a driver is bound
> to the corresponding platform devices. Any suggestions on this?

Driver bound status can be tracked easily using bus notifiers.  You can
see an example in the omap_device core.

>> > +  /* Try to put GFX to sleep */
>> > +  pwrdm_set_next_fpwrst(gfx_pwrdm, PWRDM_FUNC_PWRST_OFF);
>> > +
>> > +  ret = cpu_suspend(0, am33xx_do_sram_idle);
>> > +  status = pwrdm_read_fpwrst(gfx_pwrdm);
>> > +  if (status != PWRDM_FUNC_PWRST_OFF)
>> > +  pr_err("GFX domain did not transition\n");
>> > +  else
>> > +  pr_info("GFX domain entered low power state\n");
>> 
>> Do you really want this printed every time?
>> 
>
> Hmm... it could perhaps be clubbed with the overall status that's
> printed. I kept it here since the GFX power domain is completely
> under MPU control and hence this information would be useful in
> finding out if there's a problem with the GFX suspend-resume.

OK.

>> > +  /*
>> > +   * GFX_L4LS clock domain needs to be woken up to
>> > +   * ensure thet L4LS clock domain does not get stuck in transition
>> > +   * If that happens L3 module does not get disabled, thereby leading
>> > +   * to PER power domain transition failing
>> > +   *
>> > +   * The clock framework should take care of ensuring
>> > +   * that the clock domain is in the right state when
>> > +   * GFX driver is active.
>> 
>> Are you suggesting that the clock framework is not doing this already?
>> 
>
> No. This clkdm_*() calls are here to work-around an issue that I observed
> when implementing suspend-resume. The force wakeup and sleep of the gfx_l4ls
> clock domain across every suspend-resume is something I don't think can
> be pushed to the clock framework.

I still don't follow what you're suggesting the clock framework "should"
do.  Are you describing the case when there is a GFX driver vs. when
there isn't a driver?  If so, it needs to be more clear.

Also, some more description about why the device gets 'stuck in
transition' would be helpful.  Is this an erratum workaround?

>> > +   */
>> > +  clkdm_wakeup(gfx_l4ls_clkdm);
>> > +  clkdm_sleep(gfx_l4ls_clkdm);
>> > +
>> > +  if (ret) {
>> > +  pr_err("Kernel suspend failure\n");
>> > +  } else {
>> > +  status = omap_ctrl_readl(AM33XX_CONTROL_IPC_MSG_REG1);
>> 
>> We're trying to git rid of direct control module register access, and
>> consolidate them into control.c (for an eventual move to a driver.)  I
>> see you've mostly done that in other parts of the series, but here's one
>> that needs to move.
>
> Yes, I somehow missed this one. Will take care of it in the next version.
>
>> 
>> > +  status &= IPC_RESP_MASK;
>> > +  status >>= __ffs(IPC_RESP_MASK);
>> > +
>> > +  switch (status) {
>> > +  case 0:
>> > +  pr_info("Successfully put all powerdomains to target 
>> > state\n");
>> > +  /*
>> > +   * XXX: Leads to loss of logic state in PER power domain
>> > +  

Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency

[Kevin Hilman]

Felipe Balbi  writes:

> Hi,
>
> On Sat, Feb 16, 2013 at 11:31:21AM +0530, Santosh Shilimkar wrote:
>> >>The main goal is to avoid duplicating data both in hwmod and DT.
>> >>That's pretty much solved as we can have the driver probe populate
>> >>the common data for hwmod from DT as Santosh has already demonstrated.
>> >>
>> >>Then we also want the driver specific idle and reset code to be done
>> >>in the drivers rather than in hwmod and glue it together with hwmod
>> >>using runtime PM. The biggest issue there is how do we reset and idle
>> >>some piece of hardware for PM purposes when there's no driver loaded.
>> >
>> >right, this will be a tough nut to crack.
>> >
>> >I guess the only way would be reset all IPs early in the boot process,
>> >before even creating the platform-devices. Can we do that ? I mean, from
>> >omap_device_build_from_dt() we have access to address space of all
>> >devices, through ti,hwmods we can figure out which hwmods are linked to
>> >that particular device, so whenever you build a device, you could just
>> >call _reset().
>> >
>> Thats what we do today and it works perfectly. As per Tony's suggestion,
>> we need to move the non-probed devices reset and idle setup to late_init
>> which is also doable.
>> 
>> In that case when probed driver calls runtime_get(), we reset that
>> device and setup the idle settings. And remainder of the devices
>> are managed in late_init().
>
> what's the point in moving it to late_initcall() ? It makes no
> difference, if no driver binds to that device it will stay in reset
> anyway. Maybe what we're missing is properly idling (not exactly) all
> devices before driver probe kicks in.
>
>> >The only problem is that now omap_device_build_from_dt() is called after
>> >we notify that a new device/driver pair has been registered with the
>> >platform_bus, right ? So we would still need a way to call _reset() for
>> >those which are on DTS but don't have a driver bound to them...
>> >
>> The only special requirement for reset remains(which today handled by
>> hwmod function calls) is for devices which needs specific reset
>> sequence. And this one can be handled through a runtime_reset()
>> kind of hook.
>> 
>> Does that sound reasonable ?
>
> Depends on Rafael. If he says no to the ->runtime_reset() I suggested
> earlier, another aproach needs to be found. In any case,
> ->runtime_reset() is only for devices which actually have a driver, so
> it matters little.

Has somone tried this to see if it works on devices with the custom
reset hooks?

It should be relatively easy to add a ->runtime_reset hook, and hook it
up to omap_device_shutdown() at the PM domain level.

If we have a patch, showing how we use it in some drivers and making the
case for why it is needed in some drivers, it will be easier to take
this to Rafael and make a case for it.

> The difficult part is handling special reset requirements for devices
> without drivers as there'd be no ->runtime_reset() to call.

IMO, this should not be difficult, as omap_device_shutdown() ->
omap_hwmod_shutdown() does the heavy lifting here.  Also, We already
track whether omap_devices have drivers bound, so adding support to
reset/shutdown unbound drivers in late init will be straight forward.

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 3/3] driver: net: ethernet: cpsw: dual emac interface implementation

[Mugunthan V N]

On 2/18/2013 7:06 PM, Peter Korsgaard wrote:

"M" == Mugunthan V N  writes:

  M> The CPSW switch can act as Dual EMAC by segregating the switch ports
  M> using VLAN and port VLAN as per the TRM description in
  M> 14.3.2.10.2 Dual Mac Mode

  M> Following CPSW components will be common for both the interfaces.
  M> * Interrupt source is common for both eth interfaces
  M> * Interrupt pacing is common for both interfaces
  M> * Hardware statistics is common for all the ports
  M> * CPDMA is common for both eth interface
  M> * CPTS is common for both the interface and it should not be enabled on
  M>   both the interface as timestamping information doesn't contain port
  M>   information.

  M> Constrains
  M> * Reserved VID of One port should not be used in other interface which will
  M>   enable switching functionality
  M> * Same VID must not be used in both the interface which will enable 
switching
  M>   functionality

  M> Signed-off-by: Mugunthan V N 
  M> ---
  M>  Documentation/devicetree/bindings/net/cpsw.txt |2 +
  M>  drivers/net/ethernet/ti/cpsw.c |  335 

  M>  include/linux/platform_data/cpsw.h |3 +
  M>  3 files changed, 288 insertions(+), 52 deletions(-)

  M> diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
  M> index 6ddd028..ecfdf75 100644
  M> --- a/Documentation/devicetree/bindings/net/cpsw.txt
  M> +++ b/Documentation/devicetree/bindings/net/cpsw.txt
  M> @@ -24,6 +24,8 @@ Required properties:
  M>  Optional properties:
  M>  - ti,hwmods: Must be "cpgmac0"
  M>  - no_bd_ram: Must be 0 or 1
  M> +- dual_emac: Specifies Switch to act as Dual EMAC
  M> +- dual_emac_res_vlan   : Specifies VID to be used to segregate the ports

You forgot to CC devicetree-discuss. Properties normally use dashes (-)
instead of underscores (_). These properties are more about
configuration and not hardware.

It is not clear to me from the description that dual_emac is a boolean
(0/1). Shouldn't dual_emacs_res_vlan be a property of the slave?

It would also be good to update the example below with this.
Since the series is already applied in net-next tree, i will submit a 
patch with incorporating

the above comments. Will add devicetree-discuss in my future patches.

Regards
Mugunthan V N
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency

[Kevin Hilman]

Santosh Shilimkar  writes:

> On Friday 15 February 2013 09:10 PM, Kevin Hilman wrote:
>> Felipe Balbi  writes:
>>
>>> Currently the omap-serial driver will not
>>> work properly if booted via DT with CPUIDLE
>>> enabled because it depends on function pointers
>>> provided by hwmod to change its own SYSCONFIG
>>> register.
>>>
>>> Remove that relyance on hwmod by moving SYSCONFIG
>>> handling to driver itself. Note that this also
>>> fixes a possible corner case bug where we could
>>> be putting UART in Force Idle mode if we called
>>> omap_serial_enable_wakeup(up, false) after setting
>>> NOIDLE to the idle mode. This is because hwmod
>>> has no protection against that situation.
>>>
>>> NYET-Signed-off-by: Felipe Balbi 
>>
>> Here's another approach to getting rid of the sysconfig twiddling in the
>> driver.  I wrote this some time ago at my former company ;) but don't
>> think I ever got around to posting it.
>>
>> It doesn't solve the whole problem (e.g. doesn't address the
>> context_loss or enable_wakeup func pointers), but at least gets rid of
>> the need for any SYSCONFIG access in the driver for the idle modes.
>>
>> Needs more thorough testing.
>>
> I posted similar patch series[1] yesterday after testing it on OMAP4/5
> devices. OMAP3 testing seems to be ok as well. AM3XXX and OMAP2 test
> results is what am waiting for.

Yeah, I saw yours after I posted mine.  Just continue with yours, I'll
be glad to have someone else take this on.

> Good to know that you had similar idea in mind to get rid of
> UART sysc hackery.

Likewise.

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: OMAP EHCI having clock problems?

[Roger Quadros]

On 02/18/2013 04:47 PM, Kevin Hilman wrote:
> Roger Quadros  writes:
> 
>> On 02/15/2013 05:54 PM, Kevin Hilman wrote:
>>> Roger Quadros  writes:
>>>
 Hi Kevin,

 On 02/15/2013 12:50 AM, Kevin Hilman wrote:
> Felipe, Roger,
>
> Using Tony's current master branch, and enabling EHCI support, I see 
> the clock framework spitting loudly about the EHCI driver (full boot log
> below.)   The same thing happens on v3.8-rc7.
>
> Any idea what's going on?  Am I missing a set of fixes that's already
> been posted?

 Thanks for pointing out. This series should fix the issues
 https://lkml.org/lkml/2013/1/23/155

 They should be on their way to linux-next.
>>>
>>> Great.  But what about v3.8?  I see the same problems in v3.8-rc7.
>>>
>>
>> Kevin, the fix is below for older kernels.
> 
> Tested-by: Kevin Hilman 
> 
> Thanks, tested on v3.8-rc and works great.  Are you planning on
> submitting this for v3.8 via stable? 
> 

OK I'll do that.

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP EHCI having clock problems?

[Kevin Hilman]

Roger Quadros  writes:

> On 02/15/2013 05:54 PM, Kevin Hilman wrote:
>> Roger Quadros  writes:
>> 
>>> Hi Kevin,
>>>
>>> On 02/15/2013 12:50 AM, Kevin Hilman wrote:
 Felipe, Roger,

 Using Tony's current master branch, and enabling EHCI support, I see 
 the clock framework spitting loudly about the EHCI driver (full boot log
 below.)   The same thing happens on v3.8-rc7.

 Any idea what's going on?  Am I missing a set of fixes that's already
 been posted?
>>>
>>> Thanks for pointing out. This series should fix the issues
>>> https://lkml.org/lkml/2013/1/23/155
>>>
>>> They should be on their way to linux-next.
>> 
>> Great.  But what about v3.8?  I see the same problems in v3.8-rc7.
>> 
>
> Kevin, the fix is below for older kernels.

Tested-by: Kevin Hilman 

Thanks, tested on v3.8-rc and works great.  Are you planning on
submitting this for v3.8 via stable? 

Thanks,

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: [RFC/RFT PATCH 0/2] SERIAL: OMAP: Remove idle handling from driver

[Santosh Shilimkar]

On Monday 18 February 2013 04:43 PM, Felipe Balbi wrote:

Hi,

On Mon, Feb 18, 2013 at 04:25:58PM +0530, Santosh Shilimkar wrote:

If I read the code correctly there's nothing setting oh->mux during DT
boot. The only caller to omap_hwmod_mux_init() (which allocates and
returns omap_hwmod_mux_info pointer) is
arch/arm/mach-omap2/devices.c::omap4_keyboard_init(). This has nothing


actually arch/arm/mach-omap2/serial.c::omap_serial_init_port() also
calls that, but it's also not used during DT boots.


DT boot, all the function pointers are broken so wakeup as well as slave
idle-mode is broken. Nothing new here. Serial file does set the pads
as you noticed and this is what can be offloaded to generic pint control
which can triggered from driver.


fair enough, understood now.


Just keep the thread posted, the slave idle handling with *wakeup*
bit is sorted out now. We are looking at the io_ring() and
pad wakeup stuff now. Once we have that working, we will repost
the series.

Regards,
Santosh

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/1] OMAP4: DSS: Add panel for Blaze Tablet boards

[Ruslan Bilovol]

Hi Andy,

On Sun, Feb 17, 2013 at 4:17 PM, Andi Shyti  wrote:
>> >> + char name[30];
>> >> + char buf[50];
>> >> +
>> >> + if (size >= sizeof(buf))
>> >> + size = sizeof(buf);
>> >
>> > what's the point of this?
>>
>> This is a way to limit copied from userspace data by available buffer size,
>> widely used in current kernel sources. Are you implying there is some
>> better (more graceful) way?
>
> No indeed :)
> There is no other way, sorry for polluting the review :)
>
>> >> + if ((pins[2] & 1) || (pins[3] & 1)) {
>> >> + lanes |= (1 << 1);
>> >> + ret |= tc358765_write_register(dssdev, PPI_D0S_CLRSIPOCOUNT,
>> >> + 
>> >> board_data->clrsipo);
>> >> + }
>> >> + if ((pins[4] & 1) || (pins[5] & 1)) {
>> >> + lanes |= (1 << 2);
>> >> + ret |= tc358765_write_register(dssdev, PPI_D1S_CLRSIPOCOUNT,
>> >> + 
>> >> board_data->clrsipo);
>> >> + }
>> >> + if ((pins[6] & 1) || (pins[7] & 1)) {
>> >> + lanes |= (1 << 3);
>> >> + ret |= tc358765_write_register(dssdev, PPI_D2S_CLRSIPOCOUNT,
>> >> + 
>> >> board_data->clrsipo);
>> >> + }
>> >> + if ((pins[8] & 1) || (pins[9] & 1)) {
>> >> + lanes |= (1 << 4);
>> >> + ret |= tc358765_write_register(dssdev, PPI_D3S_CLRSIPOCOUNT,
>> >> + 
>> >> board_data->clrsipo);
>> >> + }
>> >
>> > Can't this be done in one single multiwrighting command since
>> > this registers are consecutive?
>> >
>> > You build once the array to write and you send it at once.
>>
>> In this particular case I disagree. Yes, it will be a little bit
>> faster, however:
>> 1) we write this for panel initialization only (so no impact in other cases)
>> 2) multiwriting of array will make code reading more difficult
>>
>> So I would like to leave it as-is
>> Same is for next your similar comment.
>
> If the hw is providing us some ways for simplifying the code I
> would use it. In this case we are talking about the i2c feature
> of multiwriting and multireading.
>
> Let's assume that we want to write on 8 different consecutive
> registers. In my opinion this aproach is quite "heavy":
>
>   uX register;
>
>   register = value1;
>   i2c_write(REG1, register);
>
>   register = value2;
>   i2c_write(REG2, register);
>
>   ...
>
> Usually what I do is this:
>
>   uX register[8];
>
>   for (i = 0; i < 8; i++)
> register |= valuei << i; (or register[i] = valuei or whatever)
>
>   i2c_multi_write(REG, register, 8);
>
> of course this is a simplified example in pseudocode. I think
> it's more readable and we are making a better use of the i2c
> protocol.
>
> In your case you have some if statement that are making the multi
> writing more difficult, but still is not impossible.
>
> At the end it's still a matter of taste, so that you are free to
> choose whatever you prefer :)

Thank you for reviewing this.
Unfortunately, this driver is not accepted due to future OMAP DSS rework.

I will take into account your comments when will reimplement it for new
DSS architecture.

Thanks and best regards,
Ruslan

>
> Andi
> --
> 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/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/1] OMAP4: DSS: Add panel for Blaze Tablet boards

[Ruslan Bilovol]

Hi Tomi,

On Thu, Feb 14, 2013 at 11:24 AM, Tomi Valkeinen  wrote:
> On 2013-02-14 02:07, Ruslan Bilovol wrote:
>
>> This patch is exactly a part of mainlining of the BlazeTablet board support 
>> :)
>> The goal is to have as much as possible support of this board in the
>> 'vanilla' kernel.
>> The BlazeTablet mainlining is already ongoing (
>> https://patchwork.kernel.org/patch/2118281/ )
>> and I hope we will have some support of this board in near future.
>> The BlazeTablet's LCD panel support is very important thing for us to
>> have it in mainline because
>> without it the BlazeTablet becomes a 'black brick' and it is painful
>> for us to port this
>> driver against each new version of kernel.
>
> Ok, good to hear you're pushing it to mainline. However, you should
> mentally prepare for it being a black brick =(.
>
> Tony said he's not adding new board files, only DT from now on. The
> display subsystem driver and the panel drivers do not work with DT yet,
> and it will still take some time for that to realize.
>
> Thus adding this driver would help nothing, as it couldn't be used. And
> after the DSS and the panel drivers are made to work with DT (which is a
> big job, needing large rewrites of the drivers), there's a rework that
> has to be done with this driver to make it compatible with the new DSS
> model.
>
> So, I'm still inclined to say that we shouldn't merge this.

Thanks for explanation.

Do you have some plan when DSS will be ready to port this driver?
(3.10, 3.11 or later)?

Best regards,
Ruslan

>
>  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

[PATCH] ARM: OMAP2+: Fix broken gpmc support

[Jon Hunter]

Commit "ARM: OMAP2+: Prevent potential crash if GPMC probe fails" added
code to ensure that GPMC chip-selects could not be requested until the
device probe was successful. The chip-selects should have been
unreserved at the end of the probe function, but the code to unreserve
them appears to have ended up in the gpmc_calc_timings() function and
hence, this is causing problems requesting chip-selects. Fix this merge
error by unreserving the chip-selects at the end of the probe, but
before we call the gpmc child probe functions (for device-tree) which
request a chip-select.

Signed-off-by: Jon Hunter 
Tested-by: Ezequiel Garcia 
Tested-by: Philip Avinash 
Tested-by: Grazvydas Ignotas 
---

Tony, GPMC support is completely broken in linux-next without this fix
and a few people now are reporting this problem. Can we get this fix
merged?

Thanks
Jon

 arch/arm/mach-omap2/gpmc.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1adb2d4..1e8bcb4 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1125,9 +1125,6 @@ int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
/* TODO: remove, see function definition */
gpmc_convert_ps_to_ns(gpmc_t);
 
-   /* Now the GPMC is initialised, unreserve the chip-selects */
-   gpmc_cs_map = 0;
-
return 0;
 }
 
@@ -1388,6 +1385,9 @@ static int gpmc_probe(struct platform_device *pdev)
if (IS_ERR_VALUE(gpmc_setup_irq()))
dev_warn(gpmc_dev, "gpmc_setup_irq failed\n");
 
+   /* Now the GPMC is initialised, unreserve the chip-selects */
+   gpmc_cs_map = 0;
+
rc = gpmc_probe_dt(pdev);
if (rc < 0) {
clk_disable_unprepare(gpmc_l3_clk);
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 1/7] platform: add a device node

[Javier Martinez Canillas]

On 02/18/2013 02:51 PM, Grant Likely wrote:
> On Sun, Feb 10, 2013 at 11:35 AM, Javier Martinez Canillas
>  wrote:
>> On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
>>  wrote:
>>> On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
 I knew this would be controversial and that's why I didn't mean it to be a 
 patch
 but a RFC :)

 The problem basically is that you have to associate the platform device 
 with its
 corresponding DT device node because it can be used in the driver probe 
 function.
>>>
>>> When DT is being used, doesn't DT create the platform devices for you,
>>> with the device node already set correctly?
>>>
>>
>> Well they usually do but not always just like usually you have a
>> platform_device in your board code and call platform_device_register().
>>
>> But in some configurations you can't just define the platform_device
>> required resources (I/O memory, IRQ, etc) as static platform data.
>> In some cases you need a level of indirection.
>>
>> In this particular case a SMSC ethernet chip is connected to an
>> OMAP3 processor through its General-Purpose Memory Controller.
>>
>> You can't just define the I/O memory used by the device since you first
>> need to request that address to the GPMC. The same happens with the
>> IRQ line since a OMAP GPIO pin is used so you have to first configure
>> the GPIO line as input.
>>
>> So in platform code you call to gpmc_smsc911x_init() passing all the
>> GPMC specific configurations (GPIO used for IRQ, GPMC chip select, etc)
>>
>> Then gpmc_smsc911x_init() does all the needed setup, fills a platform_data
>> for the real platform_device and calls  platform_device_register_resndata().
>>
>> From the smsc911x platform_driver probe function point of view it just have
>> resources and doesn't know if it's I/O memory is directly mapped or is
>> through a memory controller as the GPMC. It also doesn't know if the IRQ is
>> a GPIO or not.
> 
> It's still the same difference as far as the device is concerned.
> External bus chip-select lines are well understood. The key here is to
> encode the CS line number into the reg property of the child node so
> that the GPMC driver has the information it needs to configure the
> chip selects. You do this by setting #address-cells to '2' in the GPMC
> node, and  use the ranges property to map from the gpmc address space
> to the cpu address space. Like so (if you had 2 Ethernet controllers)
> 
> gpmc {
> #address-cells = <2>;  // First cell is CS#, second
> cell is offset from CS base
> #size-cells = <1>;
> compatible = "ti,gpmc";
> ranges = <0 0 0xf100 0x1000>, //CS0 mapped to
> 0xf100..0xf1000fff
> <1 0 0xf1001000 0x1000>; //CS1 mapped
> to 0xf1001000..0xf1001fff
> 
> ethernet@0,0 {
> compatible = "smsc,91c111";
> reg = <0 0 0x1000>;
> }
> ethernet@1,0 {
> compatible = "smsc,91c111";
> reg = <1 0 0x1000>;
>}
>   }
> 
> The GPMC driver can use the information in the ranges property for
> setting up the chip select mappings. For the smsc,91c111 driver the
> mapping becomes transparent.
> 
> You can see another example of this in
> arch/powerpc/boot/dts/media5200.dts in the localbus node.
> 
> g.
> 

Hello Grant,

Thanks a lot for your explanation. Now is very clear to me how this has to be
done. I'll work on an v2 of this patch-set that do it correctly and will resend.

Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 1/7] platform: add a device node

[Grant Likely]

On Sun, Feb 10, 2013 at 11:35 AM, Javier Martinez Canillas
 wrote:
> On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
>  wrote:
>> On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
>>> I knew this would be controversial and that's why I didn't mean it to be a 
>>> patch
>>> but a RFC :)
>>>
>>> The problem basically is that you have to associate the platform device 
>>> with its
>>> corresponding DT device node because it can be used in the driver probe 
>>> function.
>>
>> When DT is being used, doesn't DT create the platform devices for you,
>> with the device node already set correctly?
>>
>
> Well they usually do but not always just like usually you have a
> platform_device in your board code and call platform_device_register().
>
> But in some configurations you can't just define the platform_device
> required resources (I/O memory, IRQ, etc) as static platform data.
> In some cases you need a level of indirection.
>
> In this particular case a SMSC ethernet chip is connected to an
> OMAP3 processor through its General-Purpose Memory Controller.
>
> You can't just define the I/O memory used by the device since you first
> need to request that address to the GPMC. The same happens with the
> IRQ line since a OMAP GPIO pin is used so you have to first configure
> the GPIO line as input.
>
> So in platform code you call to gpmc_smsc911x_init() passing all the
> GPMC specific configurations (GPIO used for IRQ, GPMC chip select, etc)
>
> Then gpmc_smsc911x_init() does all the needed setup, fills a platform_data
> for the real platform_device and calls  platform_device_register_resndata().
>
> From the smsc911x platform_driver probe function point of view it just have
> resources and doesn't know if it's I/O memory is directly mapped or is
> through a memory controller as the GPMC. It also doesn't know if the IRQ is
> a GPIO or not.

It's still the same difference as far as the device is concerned.
External bus chip-select lines are well understood. The key here is to
encode the CS line number into the reg property of the child node so
that the GPMC driver has the information it needs to configure the
chip selects. You do this by setting #address-cells to '2' in the GPMC
node, and  use the ranges property to map from the gpmc address space
to the cpu address space. Like so (if you had 2 Ethernet controllers)

gpmc {
#address-cells = <2>;  // First cell is CS#, second
cell is offset from CS base
#size-cells = <1>;
compatible = "ti,gpmc";
ranges = <0 0 0xf100 0x1000>, //CS0 mapped to
0xf100..0xf1000fff
<1 0 0xf1001000 0x1000>; //CS1 mapped
to 0xf1001000..0xf1001fff

ethernet@0,0 {
compatible = "smsc,91c111";
reg = <0 0 0x1000>;
}
ethernet@1,0 {
compatible = "smsc,91c111";
reg = <1 0 0x1000>;
   }
  }

The GPMC driver can use the information in the ranges property for
setting up the chip select mappings. For the smsc,91c111 driver the
mapping becomes transparent.

You can see another example of this in
arch/powerpc/boot/dts/media5200.dts in the localbus node.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 2/8] ARM: twd: register clock event for 1 core SMP

[Rob Herring]

On 02/18/2013 12:30 AM, Afzal Mohammed wrote:
> Register percpu local timer for scheduler tick in the case of one core
> SMP configuration. In other cases - secondary cpu's as well as boot
> cpu's having more than one core, this is being registered as per
> existing boot flow, with a difference that they happens after delay
> calibration. Registering the clock for tick in case of one core should
> be done before Kernel calibrates delay (this is required to boot,
> unless local timer is the only one registered for tick). Registering
> twd local timer at init_time (which platforms are doing now) helps
> achieve that with the proposed change.
> 
> This helps in an almost booting Kernel (minimal) by only relying on
> ARM parts for an A9 one core SMP.
> 
> Signed-off-by: Afzal Mohammed 
> ---
>  arch/arm/kernel/smp_twd.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
> index 616268c..118f4f2 100644
> --- a/arch/arm/kernel/smp_twd.c
> +++ b/arch/arm/kernel/smp_twd.c
> @@ -335,6 +335,9 @@ static int __init twd_local_timer_common_register(struct 
> device_node *np)
>  
>   twd_get_clock(np);
>  
> + if (num_possible_cpus() == 1)
> + twd_timer_setup(evt);
> +

Shouldn't this be fixed in the core code, so the same issue is fixed for
all timers?

Rob

>   return 0;
>  
>  out_irq:
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] driver: net: ethernet: cpsw: dual emac interface implementation

[Peter Korsgaard]

> "M" == Mugunthan V N  writes:

 M> The CPSW switch can act as Dual EMAC by segregating the switch ports
 M> using VLAN and port VLAN as per the TRM description in
 M> 14.3.2.10.2 Dual Mac Mode

 M> Following CPSW components will be common for both the interfaces.
 M> * Interrupt source is common for both eth interfaces
 M> * Interrupt pacing is common for both interfaces
 M> * Hardware statistics is common for all the ports
 M> * CPDMA is common for both eth interface
 M> * CPTS is common for both the interface and it should not be enabled on
 M>   both the interface as timestamping information doesn't contain port
 M>   information.

 M> Constrains
 M> * Reserved VID of One port should not be used in other interface which will
 M>   enable switching functionality
 M> * Same VID must not be used in both the interface which will enable 
switching
 M>   functionality

 M> Signed-off-by: Mugunthan V N 
 M> ---
 M>  Documentation/devicetree/bindings/net/cpsw.txt |2 +
 M>  drivers/net/ethernet/ti/cpsw.c |  335 

 M>  include/linux/platform_data/cpsw.h |3 +
 M>  3 files changed, 288 insertions(+), 52 deletions(-)

 M> diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
 M> index 6ddd028..ecfdf75 100644
 M> --- a/Documentation/devicetree/bindings/net/cpsw.txt
 M> +++ b/Documentation/devicetree/bindings/net/cpsw.txt
 M> @@ -24,6 +24,8 @@ Required properties:
 M>  Optional properties:
 M>  - ti,hwmods: Must be "cpgmac0"
 M>  - no_bd_ram: Must be 0 or 1
 M> +- dual_emac: Specifies Switch to act as Dual EMAC
 M> +- dual_emac_res_vlan   : Specifies VID to be used to segregate the 
ports

You forgot to CC devicetree-discuss. Properties normally use dashes (-)
instead of underscores (_). These properties are more about
configuration and not hardware.

It is not clear to me from the description that dual_emac is a boolean
(0/1). Shouldn't dual_emacs_res_vlan be a property of the slave?

It would also be good to update the example below with this.




 M>  Note: "ti,hwmods" field is used to fetch base address and irq
 M>  resources from TI, omap hwmod data base during device registration.
 M> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
 M> index 4b964bb..4ceed6e 100644
 M> --- a/drivers/net/ethernet/ti/cpsw.c
 M> +++ b/drivers/net/ethernet/ti/cpsw.c
 M> @@ -122,6 +122,10 @@ do {   
\
 M>  #define CPSW_VLAN_AWAREBIT(1)
 M>  #define CPSW_ALE_VLAN_AWARE1
 
 M> +#define CPSW_FIFO_NORMAL_MODE  (0 << 15)
 M> +#define CPSW_FIFO_DUAL_MAC_MODE(1 << 15)
 M> +#define CPSW_FIFO_RATE_LIMIT_MODE  (2 << 15)
 M> +
 M>  #define cpsw_enable_irq(priv)  \
 M> do {\
 M> u32 i;  \
 M> @@ -254,7 +258,7 @@ struct cpsw_ss_regs {
 M>  struct cpsw_host_regs {
 M> u32 max_blks;
 M> u32 blk_cnt;
 M> -   u32 flow_thresh;
 M> +   u32 tx_in_ctl;
 M> u32 port_vlan;
 M> u32 tx_pri_map;
 M> u32 cpdma_tx_pri_map;
 M> @@ -281,6 +285,9 @@ struct cpsw_slave {
 M> u32 mac_control;
 M> struct cpsw_slave_data  *data;
 M> struct phy_device   *phy;
 M> +   struct net_device   *ndev;
 M> +   u32 port_vlan;
 M> +   u32 open_stat;
 M>  };
 
 M>  static inline u32 slave_read(struct cpsw_slave *slave, u32 offset)
 M> @@ -320,15 +327,63 @@ struct cpsw_priv {
 M> u32 irqs_table[4];
 M> u32 num_irqs;
 M> struct cpts *cpts;
 M> +   u32 emac_port;
 M>  };
 
 M>  #define napi_to_priv(napi) container_of(napi, struct cpsw_priv, napi)
 M> -#define for_each_slave(priv, func, arg...) \
 M> -   do {\
 M> -   int idx;\
 M> -   for (idx = 0; idx < (priv)->data.slaves; idx++) \
 M> -   (func)((priv)->slaves + idx, ##arg);\
 M> +#define for_each_slave(priv, func, arg...) \
 M> +   do {\
 M> +   int idx;\
 M> +   if (priv->data.dual_emac)   \
 M> +   (func)((priv)->slaves + priv->emac_port, ##arg);\
 M> +   else\
 M> +   for (idx = 0; idx < (priv)->data.slaves; idx++) \
 M> +   (func)((priv)->slaves + idx, ##arg);\
 M> +   } while (0)
 M> +#define cpsw_get_slave_ndev(priv, __slave_no__)
\
 M> +   (priv->slaves[__slave_no__].ndev)
 M> +#define cpsw_get_slave_priv(priv, __slave_no__)

Re: [PATCH RFC 1/7] platform: add a device node

[Grant Likely]

On Sun, Feb 10, 2013 at 9:37 AM, Russell King - ARM Linux
 wrote:
> On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
>> I knew this would be controversial and that's why I didn't mean it to be a 
>> patch
>> but a RFC :)
>>
>> The problem basically is that you have to associate the platform device with 
>> its
>> corresponding DT device node because it can be used in the driver probe 
>> function.
>
> When DT is being used, doesn't DT create the platform devices for you,
> with the device node already set correctly?
>
> Manually creating platform devices and adding DT nodes to it sounds like
> the wrong thing to be doing.

Right; I'd expect your platform device creation to go through the
of_platform_populate() route. What is your use-case?

g.



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: OMAP2+: omap2plus_defconfig: Add support for BMP085 pressure sensor

[Ruslan Bilovol]

This patch enables BMP085 pressure sensor that can be
found on OMAP4 Blaze Tablet development platform

Signed-off-by: Ruslan Bilovol 
---
 arch/arm/configs/omap2plus_defconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index b16bae2..6a4e9a2 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -93,6 +93,7 @@ CONFIG_BLK_DEV_RAM_SIZE=16384
 CONFIG_SENSORS_LIS3LV02D=m
 CONFIG_SENSORS_TSL2550=m
 CONFIG_SENSORS_LIS3_I2C=m
+CONFIG_BMP085_I2C=m
 CONFIG_SCSI=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_SCSI_MULTI_LUN=y
-- 
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/1] ARM: DTS: OMAP4: Add OMAP4 Blaze Tablet support

[Ruslan Bilovol]

Hi,

This patch is a second attempt to add basic support of OMAP4 Blaze Tablet
software development platform - in this case using only Device Tree.

Additional information about this platform can be found here:
http://www.svtronics.com/omap?product_id=15

Ruslan Bilovol (1):
  ARM: DTS: OMAP4: Add OMAP4 Blaze Tablet support

 arch/arm/boot/dts/Makefile  |1 +
 arch/arm/boot/dts/omap4-blazetablet.dts |  390 +++
 2 files changed, 391 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap4-blazetablet.dts

-- 
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 1/1] ARM: DTS: OMAP4: Add OMAP4 Blaze Tablet support

[Ruslan Bilovol]

The OMAP4 Blaze Tablet is TI OMAP4 processor-based
development platform in a tablet formfactor.
The platform contains many of the features found in
present-day handsets (such as audio, video, wireless
functions and user interfaces) and in addition
contains features for software development and test.

This patch adds initial support for the OMAP4 Blaze
Tablet development platform. Additional functionality
depends on different drivers and code modifications that
are not upstreamed yet or do not support DT yet, so will
be added later.

Signed-off-by: Ruslan Bilovol 
---
 arch/arm/boot/dts/Makefile  |1 +
 arch/arm/boot/dts/omap4-blazetablet.dts |  390 +++
 2 files changed, 391 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap4-blazetablet.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5ebb44f..4f94a95 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -110,6 +110,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap4-panda-es.dtb \
omap4-var-som.dtb \
omap4-sdp.dtb \
+   omap4-blazetablet.dtb \
omap5-evm.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
diff --git a/arch/arm/boot/dts/omap4-blazetablet.dts 
b/arch/arm/boot/dts/omap4-blazetablet.dts
new file mode 100644
index 000..d6be4dc
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-blazetablet.dts
@@ -0,0 +1,390 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Ruslan Bilovol 
+ *
+ * based on omap4-sdp.dts
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ "omap4.dtsi"
+/include/ "elpida_ecb240abacn.dtsi"
+
+/ {
+   model = "TI OMAP4 Blaze Tablet";
+   compatible = "ti,omap4-blazetablet", "ti,omap4430", "ti,omap4";
+
+   chosen {
+   bootargs = "root=/dev/mmcblk0p2 rootwait console=ttyO2,115200";
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x4000>; /* 1 GB */
+   };
+
+   vdd_eth: fixedregulator-vdd-eth {
+   compatible = "regulator-fixed";
+   regulator-name = "VDD_ETH";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&gpio2 16 0>;  /* gpio line 48 */
+   enable-active-high;
+   regulator-boot-on;
+   };
+
+   vbat: fixedregulator-vbat {
+   compatible = "regulator-fixed";
+   regulator-name = "VBAT";
+   regulator-min-microvolt = <375>;
+   regulator-max-microvolt = <375>;
+   regulator-boot-on;
+   };
+
+   gpio_keys {
+   compatible = "gpio-keys";
+
+   volume_up {
+   label = "volume-up";
+   linux,code = <115>; /* KEY_VOLUMEUP */
+   gpios = <&gpio2 11 0>;  /* 43 */
+   gpio-key,wakeup;
+   };
+
+   home {
+   label = "home";
+   linux,code = <102>; /* KEY_HOME */
+   gpios = <&gpio2 14 0>;  /* 46 */
+   gpio-key,wakeup;
+   };
+
+   volume_down {
+   label = "volume-down";
+   linux,code = <114>; /* KEY_VOLUMEDOWN */
+   gpios = <&gpio2 15 0>;  /* 47 */
+   gpio-key,wakeup;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   debug2 {
+   label = "omap4:green:debug2";
+   gpios = <&gpio6 13 0>; /* 173 */
+   };
+
+   debug4 {
+   label = "omap4:green:debug4";
+   gpios = <&gpio2 18 0>; /* 50 */
+   };
+
+   user1 {
+   label = "omap4:blue:user";
+   gpios = <&gpio6 9 0>; /* 169 */
+   };
+
+   user2 {
+   label = "omap4:red:user";
+   gpios = <&gpio6 10 0>; /* 170 */
+   };
+
+   user3 {
+   label = "omap4:green:user";
+   gpios = <&gpio6 14 0>; /* 174 */
+   };
+   };
+
+   sound {
+   compatible = "ti,abe-twl6040";
+   ti,model = "BlazeTablet";
+
+   ti,jack-detection = <1>;
+   ti,mclk-freq = <3840>;
+
+   ti,mcpdm = <&mcpdm>;
+   ti,dmic = <&dmic>;
+
+   ti,twl6040 = <&twl6040>;
+
+   /* Audio routing */
+   ti,audio-routing =
+   "Headset Stereophone", "HSOL",

Re: [PATCH] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode.

[Andreas Fenkart]

Hi,

On Mon, Feb 18, 2013 at 11:26:38AM +0100, Daniel Mack wrote:
> On 10.01.2013 21:22, Tony Lindgren wrote:
> > * Andreas Fenkart  [121220 14:15]:
> >> Without functional clock the omap_hsmmc module can't forward
> >> SDIO IRQs to the system. This patch reconfigures dat1 line
> >> as a gpio while the fclk is off. And uses SDIO IRQ detection of
> >> the module, while fclk is present.
> > 
> > Looks pretty good to me, however I could not figure out what
> > to apply this on for testing. It fails to apply at least against
> > current linux next, can you please update against that?
> >  
> >> +static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
> >> +{
> >> +  struct omap_hsmmc_host *host = mmc_priv(mmc);
> >> +  u32 irq_mask;
> >> +  unsigned long flags;
> >> +
> >> +  spin_lock_irqsave(&host->irq_lock, flags);
> >> +
> >> +  host->sdio_irq_en = (enable != 0) ? true : false;
> >> +
> >> +  if (host->active_pinmux) {
> >> +  irq_mask = OMAP_HSMMC_READ(host->base, ISE);
> >> +  if (enable)
> >> +  irq_mask |= CIRQ_ENABLE;
> >> +  else
> >> +  irq_mask &= ~CIRQ_ENABLE;
> >> +  OMAP_HSMMC_WRITE(host->base, IE, irq_mask);
> >> +
> >> +  if (!host->req_in_progress)
> >> +  OMAP_HSMMC_WRITE(host->base, ISE, irq_mask);
> >> +
> >> +#if 0
> >> +  OMAP_HSMMC_READ(host->base, IE); /* flush posted write */
> >> +#endif
> > 
> > Maybe just replace #if 0 with just a comment in case it turns out to be
> > needed for some cases?
> 
> Is there any update on this series? Andreas, did you do more tests?

Thanks for all the feedback so far. Yes I did more testing. After
reducing the autosuspend delay, I found two more bugs.

--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -138,7 +138,7 @@ static void apply_clk_hack(void)
 #define SOFTRESET  (1 << 1)
 #define RESETDONE  (1 << 0)

-#define MMC_AUTOSUSPEND_DELAY  100
+#define MMC_AUTOSUSPEND_DELAY  1
 #define MMC_TIMEOUT_MS 20

One is already fixed[1], the other I'm still working on.
Hope to progress this week, then need to redo the testing.
Plan is to resubmit latest next week.

Andi

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: dts: OMAP3: Add GPMC controller

[Cousson, Benoit]

Hi Javier,

On 2/16/2013 5:44 PM, Javier Martinez Canillas wrote:

On Sat, Feb 16, 2013 at 2:09 PM, Anil Kumar  wrote:

Hi Florian,

On Mon, Jan 28, 2013 at 11:24 PM, Florian Vaussard
 wrote:

Add device-tree support for the GPMC controller on the OMAP3.

Signed-off-by: Florian Vaussard 
---
  arch/arm/boot/dts/omap3.dtsi |   11 +++
  1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 6c63118..2ddae38 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -403,5 +403,16 @@
 ti,timer-alwon;
 ti,timer-secure;
 };
+
+   gpmc: gpmc@6e00 {
+   compatible = "ti,omap3430-gpmc";
+   ti,hwmods = "gpmc";
+   reg = <0x6e00 0x100>;
+   interrupts = <20>;
+   gpmc,num-cs = <8>;
+   gpmc,num-waitpins = <4>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   };
 };
  };


Tested on devkit8000 (omap3 based board)

Please take my Tested-by: Anil Kumar 

Thanks,
Anil



Hello Tony and Benoit,

Could this patch be merged to one of your branches?


I'll take it.


It has already my Reviewed-by and now Anil's Tested-by.

Now that Daniel's OMAP GPMC binding were merged, there seems to be
many people working on adding support on their boards DT for
peripherals connected through the GPMC (NAND, OneNAND, SMSC LAN, etc).

I think it will be easier if people can base their work on top of this
patch instead of duplicating the work and sending the same patch to
add a GPMC device node to omap3.dtsi on each patch-set.


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

[PATCH, RFC 3/8] ARM: twd: clock rate from DT (if no DT clk tree)

[Afzal Mohammed]

Add an optional property to find clock-frequency from DT. This helps
as a fallback mechanism in case there is no representation of clock
tree in DT.

Signed-off-by: Afzal Mohammed 
---
 Documentation/devicetree/bindings/arm/twd.txt | 7 ++-
 arch/arm/kernel/smp_twd.c | 8 
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/twd.txt 
b/Documentation/devicetree/bindings/arm/twd.txt
index 75b8610..fdafa4f 100644
--- a/Documentation/devicetree/bindings/arm/twd.txt
+++ b/Documentation/devicetree/bindings/arm/twd.txt
@@ -7,8 +7,9 @@ and watchdog.
 The TWD is usually attached to a GIC to deliver its two per-processor
 interrupts.
 
-** Timer node required properties:
+** Timer node properties:
 
+Required properties:
 - compatible : Should be one of:
"arm,cortex-a9-twd-timer"
"arm,cortex-a5-twd-timer"
@@ -19,12 +20,16 @@ interrupts.
 - reg : Specify the base address and the size of the TWD timer
register window.
 
+Optional property:
+- clock-frequency : frequency(Hz) of peripheral clock fed to timer
+
 Example:
 
twd-timer@2c000600 {
compatible = "arm,arm11mp-twd-timer"";
reg = <0x2c000600 0x20>;
interrupts = <1 13 0xf01>;
+   clock-frequency = <3>;
};
 
 ** Watchdog node properties:
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 118f4f2..aac0f9f 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -247,7 +247,15 @@ static void twd_get_clock(struct device_node *np)
twd_clk = clk_get_sys("smp_twd", NULL);
 
if (IS_ERR(twd_clk)) {
+   u32 freq;
+
pr_err("smp_twd: clock not found %d\n", (int) PTR_ERR(twd_clk));
+
+   /* If there is no representation of clock tree in DT,
+  provide a fallback option to obtain frequency
+*/
+   if (np && !of_property_read_u32(np, "clock-frequency", &freq))
+   twd_timer_rate = freq;
return;
}
 
-- 
1.7.12

--
To unsubscribe from this list: send the line "unsubscribe 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, RFC 8/8] ARM: dts: am43-pre-silicon support

[Afzal Mohammed]

AM43 SoC is in pre-silicon stage, meanwhile it has been modelled in
a pre-silicon platform. To validate and boot Linux in pre-silicon
platform that emulates an AM43 SoC, add DT build support.

As bootloader is not used, bootargs is passed through DT.

Note: This would be replaced by an original board support.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/boot/dts/Makefile |  3 ++-
 arch/arm/boot/dts/am43-pre-silicon.dts | 31 +++
 2 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/am43-pre-silicon.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 94d88b9..b434344 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -124,7 +124,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap5-evm.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
-   am335x-bone.dtb
+   am335x-bone.dtb \
+   am43-pre-silicon.dtb
 dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
 dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
 dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
diff --git a/arch/arm/boot/dts/am43-pre-silicon.dts 
b/arch/arm/boot/dts/am43-pre-silicon.dts
new file mode 100644
index 000..b9c6297
--- /dev/null
+++ b/arch/arm/boot/dts/am43-pre-silicon.dts
@@ -0,0 +1,31 @@
+/*
+ * Copyright (C) 2013 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 version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* AM43 Pre Silicon */
+
+/dts-v1/;
+
+/include/ "am4372.dtsi"
+
+/ {
+   model = "TI AM43 Pre Silicon";
+   compatible = "ti,am43-pre-silicon","ti,am4372","ti,am43";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x1000>; /* 256 MB */
+   };
+
+   chosen {
+   bootargs = "console=ttyO0,115200n8 root=/dev/ram rw 
initrd=0x8200,32MB earlyprintk";
+   };
+};
+
+&twd1 {
+   clock-frequency = <3>;
+};
-- 
1.7.12

--
To unsubscribe from this list: send the line "unsubscribe 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, RFC 7/8] ARM: dts: am4372: initial support

[Afzal Mohammed]

DT source (minimal) for AM4372 SoC. Those represented here are the
minimal DT nodes necessary to get kernel booting.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/boot/dts/am4372.dtsi | 55 +++
 1 file changed, 55 insertions(+)
 create mode 100644 arch/arm/boot/dts/am4372.dtsi

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
new file mode 100644
index 000..178c41f
--- /dev/null
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -0,0 +1,55 @@
+/*
+ * Device Tree Source for AM4372 SoC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+   compatible = "ti,am4372", "ti,am43";
+   interrupt-parent = <&gic>;
+
+
+   aliases {
+   serial0 = &uart1;
+   };
+
+   cpus {
+   cpu@0 {
+   compatible = "arm,cortex-a9";
+   };
+   };
+
+   gic: interrupt-controller@48241000 {
+   compatible = "arm,cortex-a9-gic";
+   interrupt-controller;
+   #interrupt-cells = <3>;
+   reg = <0x48241000 0x1000>,
+ <0x48240100 0x0100>;
+   };
+
+   twd1: local-timer@0x48240600 {
+   compatible = "arm,cortex-a9-twd-timer";
+   reg = <0x48240600 0x20>;
+   interrupts = <1 13 0x304>;
+   };
+
+   ocp {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   uart1: serial@44e09000 {
+   compatible = "ti,am4372-uart","ti,omap2-uart";
+   clock-frequency = <4800>;
+   reg = <0x44e09000 0x2000>;
+   interrupts = <0 72 0x4>;
+   };
+   };
+};
-- 
1.7.12

--
To unsubscribe from this list: send the line "unsubscribe 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, RFC 5/8] ARM: OMAP2+: am43: Kconfig

[Afzal Mohammed]

Add Kconfig option for AM43 family of SoC's, these are ARM Cortex A9
based (SMP configuration with 1 core).

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/Kconfig | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 49ac3df..683fbaa 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -141,6 +141,17 @@ config SOC_AM33XX
select MULTI_IRQ_HANDLER
select COMMON_CLK
 
+config SOC_AM43
+   bool "TI AM43"
+   depends on ARCH_OMAP2PLUS
+   default y
+   select CPU_V7
+   select HAVE_SMP
+   select LOCAL_TIMERS if SMP
+   select MULTI_IRQ_HANDLER
+   select ARM_GIC
+   select COMMON_CLK
+
 config OMAP_PACKAGE_ZAF
bool
 
-- 
1.7.12

--
To unsubscribe from this list: send the line "unsubscribe 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, RFC 6/8] ARM: OMAP2+: am43: basic dt support

[Afzal Mohammed]

Describe minimal DT boot machine details for AM43 based SoC's. AM43
family of SoC's are ARM Cortex-A9 based with one core in SMP
configuration. Low level debug could be achieved by selecting
DEBUG_AM33XXUART1. To boot AM43 SoC, this change is sufficient w.r.t
Kernel (considering the fact that strictly speaking DT sources does
not classify as a part of Kernel). Here private timer of the one and
only core is being used as clock event (as well as, as time source).

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/board-generic.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 0274ff7..e083f08 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,7 +15,10 @@
 #include 
 #include 
 #include 
+#include 
 
+#include 
+#include 
 #include 
 
 #include "common.h"
@@ -182,3 +185,18 @@ DT_MACHINE_START(OMAP5_DT, "Generic OMAP5 (Flattened 
Device Tree)")
.restart= omap44xx_restart,
 MACHINE_END
 #endif
+
+#ifdef CONFIG_SOC_AM43
+static const char *am43_boards_compat[] __initdata = {
+   "ti,am43",
+   NULL,
+};
+
+DT_MACHINE_START(AM43_DT, "Generic AM43 (Flattened Device Tree)")
+   .map_io = debug_ll_io_init,
+   .init_irq   = irqchip_init,
+   .init_machine   = omap_generic_init,
+   .init_time  = twd_local_timer_of_register,
+   .dt_compat  = am43_boards_compat,
+MACHINE_END
+#endif
-- 
1.7.12

--
To unsubscribe from this list: send the line "unsubscribe 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, RFC 4/8] ARM: am33xx: ll debug config help

[Afzal Mohammed]

Selecting DEBUG_AM33XXUART1 routes low level debug messages to first
UART instance of AM335x based SoC's. This selection is valid for
upcoming AM43 based SoC's too. Make this information available upon
configuring.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/Kconfig.debug | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index aca..b717b78 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -542,6 +542,9 @@ choice
 
config DEBUG_AM33XXUART1
bool "AM33XX UART1"
+   help
+ Route low level debug messages to first uart instance
+ for boards based on am335 and am43 family of SoC's
 
config DEBUG_ZOOM_UART
bool "Zoom2/3 UART"
-- 
1.7.12

--
To unsubscribe from this list: send the line "unsubscribe 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, RFC 2/8] ARM: twd: register clock event for 1 core SMP

[Afzal Mohammed]

Register percpu local timer for scheduler tick in the case of one core
SMP configuration. In other cases - secondary cpu's as well as boot
cpu's having more than one core, this is being registered as per
existing boot flow, with a difference that they happens after delay
calibration. Registering the clock for tick in case of one core should
be done before Kernel calibrates delay (this is required to boot,
unless local timer is the only one registered for tick). Registering
twd local timer at init_time (which platforms are doing now) helps
achieve that with the proposed change.

This helps in an almost booting Kernel (minimal) by only relying on
ARM parts for an A9 one core SMP.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/kernel/smp_twd.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 616268c..118f4f2 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -335,6 +335,9 @@ static int __init twd_local_timer_common_register(struct 
device_node *np)
 
twd_get_clock(np);
 
+   if (num_possible_cpus() == 1)
+   twd_timer_setup(evt);
+
return 0;
 
 out_irq:
-- 
1.7.12

--
To unsubscribe from this list: send the line "unsubscribe 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, RFC 1/8] ARM: localtimer: return percpu clkevt on register

[Afzal Mohammed]

Return percpu clock event on local timer register. It is the boot cpu
that calls this and it can use the returned percpu clock event to
register a clock event in the case of SMP configuration with one core.
This helps to have a booting Kernel even if no other timer is
registered for clock tick.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/include/asm/localtimer.h | 7 ---
 arch/arm/kernel/smp.c | 8 
 arch/arm/kernel/smp_twd.c | 5 +++--
 3 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/arch/arm/include/asm/localtimer.h 
b/arch/arm/include/asm/localtimer.h
index f77ffc1..c3f89c0 100644
--- a/arch/arm/include/asm/localtimer.h
+++ b/arch/arm/include/asm/localtimer.h
@@ -23,11 +23,12 @@ struct local_timer_ops {
 /*
  * Register a local timer driver
  */
-int local_timer_register(struct local_timer_ops *);
+struct clock_event_device *local_timer_register(struct local_timer_ops *);
 #else
-static inline int local_timer_register(struct local_timer_ops *ops)
+static inline
+struct clock_event_device *local_timer_register(struct local_timer_ops *ops)
 {
-   return -ENXIO;
+   return ERR_PTR(-ENXIO);
 }
 #endif
 
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 5f73f70..42d95d6 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -491,16 +491,16 @@ static void __cpuinit broadcast_timer_setup(struct 
clock_event_device *evt)
 static struct local_timer_ops *lt_ops;
 
 #ifdef CONFIG_LOCAL_TIMERS
-int local_timer_register(struct local_timer_ops *ops)
+struct clock_event_device *local_timer_register(struct local_timer_ops *ops)
 {
if (!is_smp() || !setup_max_cpus)
-   return -ENXIO;
+   return ERR_PTR(-ENXIO);
 
if (lt_ops)
-   return -EBUSY;
+   return ERR_PTR(-EBUSY);
 
lt_ops = ops;
-   return 0;
+   return &per_cpu(percpu_clockevent, smp_processor_id());
 }
 #endif
 
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index c092115..616268c 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -315,6 +315,7 @@ static struct local_timer_ops twd_lt_ops __cpuinitdata = {
 static int __init twd_local_timer_common_register(struct device_node *np)
 {
int err;
+   struct clock_event_device *evt;
 
twd_evt = alloc_percpu(struct clock_event_device *);
if (!twd_evt) {
@@ -328,8 +329,8 @@ static int __init twd_local_timer_common_register(struct 
device_node *np)
goto out_free;
}
 
-   err = local_timer_register(&twd_lt_ops);
-   if (err)
+   evt = local_timer_register(&twd_lt_ops);
+   if (IS_ERR(evt))
goto out_irq;
 
twd_get_clock(np);
-- 
1.7.12

--
To unsubscribe from this list: send the line "unsubscribe 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, RFC 0/8] ARM: AM43 (OMAP2+) boot support

[Afzal Mohammed]

(Resending, since it seems, LAKML doesn't accept patches with subject
prefix only as "RFC", but requires "PATCH" prefix also)

Hi,

This series adds minimal support to boot Linux on platforms having
AM43 based SoC's.

This is being sent as an RFC to seek opinion about modification in
twd to register percpu local timer clock event for scheduler tick in
the case of one core SMP.

AM43 SoC's are based on ARM Cortex-A9. It is an ARM Cortex-A9 SMP
configuration with one core (not uniprocessor configuration). AM43 is
similar to AM335x in it's peripheral capabilities, with many of the
peripheral register mapping's similar like that of uart.

AM43 is in pre-silicon stage and currently there are no public
documents.

This series has been tested on a pre-silicon platform that emulates
AM43 SoC, changes proposed here are minimal - to get it booting.
Kernel was directly run without the help of bootloader - Images were
directly loaded onto a pre-initialized RAM and ARM registers updated
as required for booting.

Changes have been made over linux-next (next-20130213) with three "OF"
related reverts (which otherwise causes problem in other platforms
also) and compiled with omap2plus_defconfig. Multiplatform option was
enabled, while most of CONFIG options were deselected for a faster
boot. Beagle bone boots as earlier with these changes.

An interesting observation is that it may be possible to boot this
platform to console without any platform specific modification to
proper Kernel (by that I mean excluding DT sources) using Arnd's,

"[PATCH,RFC] default machine descriptor for multiplatform",

along with a "CLOCKSOURCE_OF_DECLARE" for smp twd.

But later on to make SoC do any really useful work or to get done
things that the SoC is meant to do, platform changes like omap-hwmod,
handling power management, clock tree, detecting SoC capabilities etc
would have to be made, necessitating DT_MACHINE_START at least in
the foreseeable future.

Patch - 8 that makes AM43 boot on pre-silicon platform would be
replaced later by a one for original board.

Last but not least, thanks to Ankur Kishore 
(who first made Linux to boot on AM43) for all the help that made
Linux bringup easier.

Regards
Afzal


Afzal Mohammed (8):
  ARM: localtimer: return percpu clkevt on register
  ARM: twd: register clock event for 1 core SMP
  ARM: twd: clock rate from DT (if no DT clk tree)
  ARM: am33xx: ll debug config help
  ARM: OMAP2+: am43: Kconfig
  ARM: OMAP2+: am43: basic dt support
  ARM: dts: am4372: initial support
  ARM: dts: am43-pre-silicon support

 Documentation/devicetree/bindings/arm/twd.txt |  7 +++-
 arch/arm/Kconfig.debug|  3 ++
 arch/arm/boot/dts/Makefile|  3 +-
 arch/arm/boot/dts/am43-pre-silicon.dts| 31 +++
 arch/arm/boot/dts/am4372.dtsi | 55 +++
 arch/arm/include/asm/localtimer.h |  7 ++--
 arch/arm/kernel/smp.c |  8 ++--
 arch/arm/kernel/smp_twd.c | 16 +++-
 arch/arm/mach-omap2/Kconfig   | 11 ++
 arch/arm/mach-omap2/board-generic.c   | 18 +
 10 files changed, 148 insertions(+), 11 deletions(-)
 create mode 100644 arch/arm/boot/dts/am43-pre-silicon.dts
 create mode 100644 arch/arm/boot/dts/am4372.dtsi

-- 
1.7.12

--
To unsubscribe from this list: send the line "unsubscribe 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] omapdrm: Make fixed resolution panels work

[Archit Taneja]

On Monday 18 February 2013 02:01 PM, Tomi Valkeinen wrote:

On 2013-02-18 09:23, Archit Taneja wrote:


diff --git a/drivers/staging/omapdrm/omap_connector.c
b/drivers/staging/omapdrm/omap_connector.c
index 4cc9ee7..839c6e4 100644
--- a/drivers/staging/omapdrm/omap_connector.c
+++ b/drivers/staging/omapdrm/omap_connector.c
@@ -110,6 +110,11 @@ static enum drm_connector_status
omap_connector_detect(
  ret = connector_status_connected;
  else
  ret = connector_status_disconnected;
+   } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
+   dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
+   dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
+   dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
+   ret = connector_status_connected;


hmm, why not just have a default detect fxn for panel drivers which
always returns true?  Seems a bit cleaner.. otherwise, I guess we
could just change omap_connector so that if dssdev->detect is null,
assume always connected.  Seems maybe a slightly better way since
currently omap_connector doesn't really know too much about different
sorts of panels.  But I'm not too picky if that is a big pain because
we probably end up changing all this as CFP starts coming into
existence.

Same goes for check_timings/set_timings..  it seems a bit cleaner just
to have default fxns in the panel drivers that do-the-right-thing,
although I suppose it might be a bit more convenient for out-of-tree
panel drivers to just assume fixed panel if these fxns are null.


Yeah, I can't make my mind about null pointer. It's nice to inform with
a null pointer that the panel doesn't support the given operation, or
that it doesn't make sense, but handling the null value makes the code a
bit complex.

For example, our VENC driver doesn't know if there's a TV connected or
not, so neither true or false as connect return value makes sense there.
Or, for a DSI command mode panel, set_timings doesn't really make much
sense.


Maybe having default functions in omapdss might be a better idea. There
is an option of adding default functions in omap_dss_register_driver()
(drivers/video/omap2/dss/core.c).

Tomi, do you think it's fine to add some more default panel driver funcs?


We can add default funcs. However, adding them in
omap_dss_register_driver is not so nice, as it makes the omap_dss_driver
(which is essentially an "ops" struct) non-constable. Instead, we should
move the setting of the default funcs to the drivers.

If I'm not mistaken, we could manage that with a helper macro. Assigning
a value to the same field of a struct should be ok by the compiler, and
should cause only the last assignment to be taken into use. So:

static struct foo zab = {
.bar = 123, /* ignored */
.bar = 234, /* used */
};

And so we could have:

static struct omap_dss_driver my_panel_driver = {
OMAPDSS_DEFAULT_PANEL_OPS, /* macro for default ops */

.enable = my_panel_enable,
/* ... */
};


This sounds nice, but if the panel driver ops are going to be changed 
again in CPF, then it might make sense to do this later, depending on 
how it CPF handles default ops in panel drivers.


Maybe we should leave this patch as-is, since we know it will be 
modified later.


Archit

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2] ARM: dts: omap3-devkit8000: Enable audio support

[Peter Ujfalusi]

On 02/16/2013 08:33 AM, Anil Kumar wrote:
> Add the needed sections to enable audio support on
> Devkit8000 when booted with DT blob.
> 
> Signed-off-by: Anil Kumar 

Looks good:
Acked-by: Peter Ujfalusi 

> ---
> This patch is based on top of kernel 3.8-rc5 and
> the following patches.
> 
> Peter Ujfalusi:-
> ASoC: twl4030: Correct the support for Voice port
> ASoC: twl4030: Convert MICBIAS to SUPPLY widget
> ASoC: omap-twl4030: Add support for routing, voice port and jack detect
> 
> Anil Kumar:-
> ARM: dts: add minimal DT support for DevKit8000
> https://patchwork.kernel.org/patch/2122461/
> 
> -Tested for playback and capture on Devkit8000.
> 
>  Test process:-
> 
>  #amixer set 'PredriveR Mixer AudioR2' on
>  #amixer set 'PredriveL Mixer AudioL2' on
>  #amixer set PreDriv 100 unmute
>  #amixer set 'DAC2 Digital Fine' 100
>  #amixer cset numid=27 1
>  #arecord | aplay
> 
> For V2:
>  - Remove pin mux as done at device boot time by default.
> 
> :100644 100644 6338993... c70116f... M
> arch/arm/boot/dts/omap3-devkit8000.dts
>  arch/arm/boot/dts/omap3-devkit8000.dts |   23 +++
>  1 files changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts 
> b/arch/arm/boot/dts/omap3-devkit8000.dts
> index 6338993..c70116f 100644
> --- a/arch/arm/boot/dts/omap3-devkit8000.dts
> +++ b/arch/arm/boot/dts/omap3-devkit8000.dts
> @@ -42,6 +42,19 @@
>  };
>  
>   };
> +
> + sound {
> + compatible = "ti,omap-twl4030";
> + ti,model = "devkit8000";
> +
> + ti,mcbsp = <&mcbsp2>;
> + ti,codec = <&twl_audio>;
> + ti,audio-routing =
> + "Ext Spk", "PREDRIVEL",
> + "Ext Spk", "PREDRIVER",
> + "MAINMIC", "Main Mic",
> + "Main Mic", "Mic Bias 1";
> + };
>  };
>  
>  &i2c1 {
> @@ -51,6 +64,12 @@
>   reg = <0x48>;
>   interrupts = <7>;   /* SYS_NIRQ cascaded to intc */
>   interrupt-parent = <&intc>;
> +
> + twl_audio: audio {
> + compatible = "ti,twl4030-audio";
> + codec {
> + };
> + };
>   };
>  };
>  
> @@ -86,10 +105,6 @@
>   status = "disabled";
>  };
>  
> -&mcbsp2 {
> - status = "disabled";
> -};
> -
>  &mcbsp3 {
>   status = "disabled";
>  };
> 


-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/RFT PATCH 0/2] SERIAL: OMAP: Remove idle handling from driver

[Felipe Balbi]

Hi,

On Mon, Feb 18, 2013 at 04:25:58PM +0530, Santosh Shilimkar wrote:
> >>If I read the code correctly there's nothing setting oh->mux during DT
> >>boot. The only caller to omap_hwmod_mux_init() (which allocates and
> >>returns omap_hwmod_mux_info pointer) is
> >>arch/arm/mach-omap2/devices.c::omap4_keyboard_init(). This has nothing
> >
> >actually arch/arm/mach-omap2/serial.c::omap_serial_init_port() also
> >calls that, but it's also not used during DT boots.
> >
> DT boot, all the function pointers are broken so wakeup as well as slave
> idle-mode is broken. Nothing new here. Serial file does set the pads
> as you noticed and this is what can be offloaded to generic pint control
> which can triggered from driver.

fair enough, understood now.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC/RFT PATCH 0/2] SERIAL: OMAP: Remove idle handling from driver

[Santosh Shilimkar]

On Monday 18 February 2013 04:15 PM, Felipe Balbi wrote:

On Mon, Feb 18, 2013 at 12:42:16PM +0200, Felipe Balbi wrote:

Hi,

On Mon, Feb 18, 2013 at 03:55:33PM +0530, Santosh Shilimkar wrote:

I wonder what are your ideas to sort that part out, I mean, how do you
plan to implement ->set_wake() for the tty port ?"


[1] http://marc.info/?l=linux-omap&m=136093334914275&w=2


The main need for uart wakeup is the io_ring() trigger and that needs
to happen via generic pin control API. SYSC wakeup bit isn't something
needs to be toggled so that can be decoupled. So again the idea is
to make SYSC handling transparent to UART drivers and let driver toggle
the io_ring() based on ->set_wake() as it is done today.


We're either reading different code bases or not understanding each
other. Currently this is how ->set_wake() is implemented:

serial_omap_set_wake()
  serial_omap_enable_wakeup()
   omap_uart_enable_wakeup()
omap_hwmod_enable_wakeup()
 if (SYSC_HAS_ENAWAKEUP) {  /* true for UART */
  _enable_wakeup()

There is no need to toggle this one. It can be set once and left as is.

  _write_sysconfig()
 }
 set_idle_ioring_wakeup()

So this is the part, we need to hookup with pads.


  if (!oh->mux || !oh->mux->enabled)
   return;

If I read the code correctly there's nothing setting oh->mux during DT
boot. The only caller to omap_hwmod_mux_init() (which allocates and
returns omap_hwmod_mux_info pointer) is
arch/arm/mach-omap2/devices.c::omap4_keyboard_init(). This has nothing


actually arch/arm/mach-omap2/serial.c::omap_serial_init_port() also
calls that, but it's also not used during DT boots.


DT boot, all the function pointers are broken so wakeup as well as slave
idle-mode is broken. Nothing new here. Serial file does set the pads
as you noticed and this is what can be offloaded to generic pint control
which can triggered from driver.

Regards,
Santosh




--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/RFT PATCH 0/2] SERIAL: OMAP: Remove idle handling from driver

[Felipe Balbi]

On Mon, Feb 18, 2013 at 12:42:16PM +0200, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Feb 18, 2013 at 03:55:33PM +0530, Santosh Shilimkar wrote:
> > >>I wonder what are your ideas to sort that part out, I mean, how do you
> > >>plan to implement ->set_wake() for the tty port ?"
> > >
> > >[1] http://marc.info/?l=linux-omap&m=136093334914275&w=2
> > >
> > The main need for uart wakeup is the io_ring() trigger and that needs
> > to happen via generic pin control API. SYSC wakeup bit isn't something
> > needs to be toggled so that can be decoupled. So again the idea is
> > to make SYSC handling transparent to UART drivers and let driver toggle
> > the io_ring() based on ->set_wake() as it is done today.
> 
> We're either reading different code bases or not understanding each
> other. Currently this is how ->set_wake() is implemented:
> 
> serial_omap_set_wake()
>  serial_omap_enable_wakeup()
>   omap_uart_enable_wakeup()
>omap_hwmod_enable_wakeup()
> if (SYSC_HAS_ENAWAKEUP) { /* true for UART */
>  _enable_wakeup()
>  _write_sysconfig()
> }
> set_idle_ioring_wakeup()
>  if (!oh->mux || !oh->mux->enabled)
>   return;
> 
> If I read the code correctly there's nothing setting oh->mux during DT
> boot. The only caller to omap_hwmod_mux_init() (which allocates and
> returns omap_hwmod_mux_info pointer) is
> arch/arm/mach-omap2/devices.c::omap4_keyboard_init(). This has nothing

actually arch/arm/mach-omap2/serial.c::omap_serial_init_port() also
calls that, but it's also not used during DT boots.

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC/RFT PATCH 0/2] SERIAL: OMAP: Remove idle handling from driver

[Felipe Balbi]

Hi,

On Mon, Feb 18, 2013 at 03:55:33PM +0530, Santosh Shilimkar wrote:
> >>I wonder what are your ideas to sort that part out, I mean, how do you
> >>plan to implement ->set_wake() for the tty port ?"
> >
> >[1] http://marc.info/?l=linux-omap&m=136093334914275&w=2
> >
> The main need for uart wakeup is the io_ring() trigger and that needs
> to happen via generic pin control API. SYSC wakeup bit isn't something
> needs to be toggled so that can be decoupled. So again the idea is
> to make SYSC handling transparent to UART drivers and let driver toggle
> the io_ring() based on ->set_wake() as it is done today.

We're either reading different code bases or not understanding each
other. Currently this is how ->set_wake() is implemented:

serial_omap_set_wake()
 serial_omap_enable_wakeup()
  omap_uart_enable_wakeup()
   omap_hwmod_enable_wakeup()
if (SYSC_HAS_ENAWAKEUP) {   /* true for UART */
 _enable_wakeup()
 _write_sysconfig()
}
set_idle_ioring_wakeup()
 if (!oh->mux || !oh->mux->enabled)
  return;

If I read the code correctly there's nothing setting oh->mux during DT
boot. The only caller to omap_hwmod_mux_init() (which allocates and
returns omap_hwmod_mux_info pointer) is
arch/arm/mach-omap2/devices.c::omap4_keyboard_init(). This has nothing
to do with UART and, even more importantly, isn't even called during a
DT boot.

So, is there something else setting oh->mux to a valid pointer and
actually making set_idle_ioring_wakeup() do something useful ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode.

[Daniel Mack]

On 10.01.2013 21:22, Tony Lindgren wrote:
> * Andreas Fenkart  [121220 14:15]:
>> Without functional clock the omap_hsmmc module can't forward
>> SDIO IRQs to the system. This patch reconfigures dat1 line
>> as a gpio while the fclk is off. And uses SDIO IRQ detection of
>> the module, while fclk is present.
> 
> Looks pretty good to me, however I could not figure out what
> to apply this on for testing. It fails to apply at least against
> current linux next, can you please update against that?
>  
>> +static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
>> +{
>> +struct omap_hsmmc_host *host = mmc_priv(mmc);
>> +u32 irq_mask;
>> +unsigned long flags;
>> +
>> +spin_lock_irqsave(&host->irq_lock, flags);
>> +
>> +host->sdio_irq_en = (enable != 0) ? true : false;
>> +
>> +if (host->active_pinmux) {
>> +irq_mask = OMAP_HSMMC_READ(host->base, ISE);
>> +if (enable)
>> +irq_mask |= CIRQ_ENABLE;
>> +else
>> +irq_mask &= ~CIRQ_ENABLE;
>> +OMAP_HSMMC_WRITE(host->base, IE, irq_mask);
>> +
>> +if (!host->req_in_progress)
>> +OMAP_HSMMC_WRITE(host->base, ISE, irq_mask);
>> +
>> +#if 0
>> +OMAP_HSMMC_READ(host->base, IE); /* flush posted write */
>> +#endif
> 
> Maybe just replace #if 0 with just a comment in case it turns out to be
> needed for some cases?

Is there any update on this series? Andreas, did you do more tests?


Thanks and best regards,
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: [RFC/RFT PATCH 0/2] SERIAL: OMAP: Remove idle handling from driver

[Santosh Shilimkar]

On Monday 18 February 2013 03:41 PM, Felipe Balbi wrote:

On Mon, Feb 18, 2013 at 12:10:32PM +0200, Felipe Balbi wrote:

HWMOD_SWSUP_SIDLE flag will is not what will help UART completely.
Also considering UART also needs async wakeup enabled as it implements
another such hook and attaches that through function pointer.


this is exactly what I said at [1], which I quote:

"Also, $SUBJECT isn't improving the situation regarding UART Wakeup,
there is still the regression of UART never being wakeup capable.


I also mentioned that am not touching the wakeup function pointer. The
reason an alternate is needed because wakeup function pointer back-end
comes in between. And the existing SW control flag isn't intended
completely for the purpose what we wanted to use for uart. And I didn't
expected the wakeup crap will come in between an implementation of just
slave idle bits.


I wonder what are your ideas to sort that part out, I mean, how do you
plan to implement ->set_wake() for the tty port ?"


[1] http://marc.info/?l=linux-omap&m=136093334914275&w=2


The main need for uart wakeup is the io_ring() trigger and that needs
to happen via generic pin control API. SYSC wakeup bit isn't something
needs to be toggled so that can be decoupled. So again the idea is
to make SYSC handling transparent to UART drivers and let driver toggle
the io_ring() based on ->set_wake() as it is done today.

Regards,
Santosh





--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/RFT PATCH 0/2] SERIAL: OMAP: Remove idle handling from driver

[Felipe Balbi]

On Mon, Feb 18, 2013 at 12:10:32PM +0200, Felipe Balbi wrote:
> > HWMOD_SWSUP_SIDLE flag will is not what will help UART completely.
> > Also considering UART also needs async wakeup enabled as it implements
> > another such hook and attaches that through function pointer.
> 
> this is exactly what I said at [1], which I quote:
> 
> "Also, $SUBJECT isn't improving the situation regarding UART Wakeup,
> there is still the regression of UART never being wakeup capable.
> 
> I wonder what are your ideas to sort that part out, I mean, how do you
> plan to implement ->set_wake() for the tty port ?"

[1] http://marc.info/?l=linux-omap&m=136093334914275&w=2

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC/RFT PATCH 0/2] SERIAL: OMAP: Remove idle handling from driver

[Felipe Balbi]

Hi,

On Mon, Feb 18, 2013 at 03:34:56PM +0530, Santosh Shilimkar wrote:
> On Friday 15 February 2013 05:36 PM, Santosh Shilimkar wrote:
> >OMAP UART IP needs manual idle modes based on state of the
> >IP. Currently this is handled by the driver with function pointers
> >implemented in platform code.
> >
> >This however breaks in case of device tree because of missing
> >idle handling.
> >
> >The series tries to address the issue
> >
> >Patches has been tested on OMAP4 and OMAP5 devices where the console
> >slugishness was observed without idle mode handling. CPUIDLE and
> >suspend tested ok on these devices.
> >
> >Need help in testing on OMAP2, OMAP3 and AM3XXX devices.
> >
> >Santosh Shilimkar (2):
> >   ARM: OMAP2+: hwmod-data: UART IP needs software control of sidle
> > modes
> >   SERIAL: OMAP: Remove the idle handling from the driver
> >
> HWMOD_SWSUP_SIDLE flag will is not what will help UART completely.
> Also considering UART also needs async wakeup enabled as it implements
> another such hook and attaches that through function pointer.

this is exactly what I said at [1], which I quote:

"Also, $SUBJECT isn't improving the situation regarding UART Wakeup,
there is still the regression of UART never being wakeup capable.

I wonder what are your ideas to sort that part out, I mean, how do you
plan to implement ->set_wake() for the tty port ?"

> So some more work is needed to get that sorted out at least from
> sysc point of view. That way we can deal with io_ring stuff using
> pin control APIs.
> 
> Some patches will follow in attempt to address it. Stay tuned !!

good

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC/RFT PATCH 0/2] SERIAL: OMAP: Remove idle handling from driver

[Santosh Shilimkar]

On Friday 15 February 2013 05:36 PM, Santosh Shilimkar wrote:

OMAP UART IP needs manual idle modes based on state of the
IP. Currently this is handled by the driver with function pointers
implemented in platform code.

This however breaks in case of device tree because of missing
idle handling.

The series tries to address the issue

Patches has been tested on OMAP4 and OMAP5 devices where the console
slugishness was observed without idle mode handling. CPUIDLE and
suspend tested ok on these devices.

Need help in testing on OMAP2, OMAP3 and AM3XXX devices.

Santosh Shilimkar (2):
   ARM: OMAP2+: hwmod-data: UART IP needs software control of sidle
 modes
   SERIAL: OMAP: Remove the idle handling from the driver


HWMOD_SWSUP_SIDLE flag will is not what will help UART completely.
Also considering UART also needs async wakeup enabled as it implements
another such hook and attaches that through function pointer.

So some more work is needed to get that sorted out at least from
sysc point of view. That way we can deal with io_ring stuff using
pin control APIs.

Some patches will follow in attempt to address it. Stay tuned !!

Regards,
Santosh



--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP EHCI having clock problems?

[Roger Quadros]

On 02/15/2013 05:54 PM, Kevin Hilman wrote:
> Roger Quadros  writes:
> 
>> Hi Kevin,
>>
>> On 02/15/2013 12:50 AM, Kevin Hilman wrote:
>>> Felipe, Roger,
>>>
>>> Using Tony's current master branch, and enabling EHCI support, I see 
>>> the clock framework spitting loudly about the EHCI driver (full boot log
>>> below.)   The same thing happens on v3.8-rc7.
>>>
>>> Any idea what's going on?  Am I missing a set of fixes that's already
>>> been posted?
>>
>> Thanks for pointing out. This series should fix the issues
>> https://lkml.org/lkml/2013/1/23/155
>>
>> They should be on their way to linux-next.
> 
> Great.  But what about v3.8?  I see the same problems in v3.8-rc7.
> 

Kevin, the fix is below for older kernels.

>From 4762086167510619f2fb765871e7af144b86e937 Mon Sep 17 00:00:00 2001
From: Roger Quadros 
Date: Mon, 18 Feb 2013 11:44:59 +0200
Subject: [PATCH] mfd: omap-usb-host: Fix clk warnings at boot

utmi_p1_gfclk and utmi_p2_gfclk are just clock multiplexers and
don't have a gate. So don't call clk_enable/disable on them.

Gets rid of warnings like below

[0.716613] [ cut here ]
[0.716644] WARNING: at drivers/clk/clk.c:522 __clk_enable+0x94/0xa4()
[0.716674] Modules linked in:
[0.716735] [] (unwind_backtrace+0x0/0xf0) from [] 
(warn_slowpath_common+0x4c/0x64)
[0.716766] [] (warn_slowpath_common+0x4c/0x64) from [] 
(warn_slowpath_null+0x1c/0x24)
[0.716766] [] (warn_slowpath_null+0x1c/0x24) from [] 
(__clk_enable+0x94/0xa4)
[0.716796] [] (__clk_enable+0x94/0xa4) from [] 
(clk_enable+0x20/0x3c)
[0.716857] [] (clk_enable+0x20/0x3c) from [] 
(usbhs_runtime_resume+0x1c/0x34)
[0.716888] [] (usbhs_runtime_resume+0x1c/0x34) from [] 
(pm_generic_runtime_resume+0x2c/0x38)
[0.716918] [] (pm_generic_runtime_resume+0x2c/0x38) from 
[] (__rpm_callback+0x2c/0x60)
[0.716949] [] (__rpm_callback+0x2c/0x60) from [] 
(rpm_resume+0x39c/0x60c)
[0.716979] [] (rpm_resume+0x39c/0x60c) from [] 
(__pm_runtime_resume+0x48/0x60)
[0.717010] [] (__pm_runtime_resume+0x48/0x60) from [] 
(usbhs_omap_probe+0x1f8/0x85c)
[0.717041] [] (usbhs_omap_probe+0x1f8/0x85c) from [] 
(platform_drv_probe+0x18/0x1c)
[0.717041] [] (platform_drv_probe+0x18/0x1c) from [] 
(driver_probe_device+0x74/0x218)
[0.717071] [] (driver_probe_device+0x74/0x218) from [] 
(__driver_attach+0x94/0x98)
[0.717132] [] (__driver_attach+0x94/0x98) from [] 
(bus_for_each_dev+0x4c/0x80)
[0.717132] [] (bus_for_each_dev+0x4c/0x80) from [] 
(bus_add_driver+0x174/0x240)
[0.717163] [] (bus_add_driver+0x174/0x240) from [] 
(driver_register+0x78/0x14c)
[0.717193] [] (driver_register+0x78/0x14c) from [] 
(platform_driver_probe+0x18/0x9c)
[0.717224] [] (platform_driver_probe+0x18/0x9c) from [] 
(do_one_initcall+0xfc/0x168)
[0.717254] [] (do_one_initcall+0xfc/0x168) from [] 
(kernel_init_freeable+0xfc/0x1cc)
[0.717285] [] (kernel_init_freeable+0xfc/0x1cc) from [] 
(kernel_init+0x8/0xe4)
[0.717315] [] (kernel_init+0x8/0xe4) from [] 
(ret_from_fork+0x14/0x24)
[0.717498] ---[ end trace 3ac11fdde949a96e ]---

Signed-off-by: Roger Quadros 
---
 drivers/mfd/omap-usb-host.c |6 --
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 05164d7..f6f5b18 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -299,9 +299,6 @@ static int usbhs_runtime_resume(struct device *dev)
if (is_ehci_tll_mode(pdata->port_mode[1]))
clk_enable(omap->usbhost_p2_fck);
 
-   clk_enable(omap->utmi_p1_fck);
-   clk_enable(omap->utmi_p2_fck);
-
spin_unlock_irqrestore(&omap->lock, flags);
 
return 0;
@@ -327,9 +324,6 @@ static int usbhs_runtime_suspend(struct device *dev)
if (is_ehci_tll_mode(pdata->port_mode[1]))
clk_disable(omap->usbhost_p2_fck);
 
-   clk_disable(omap->utmi_p2_fck);
-   clk_disable(omap->utmi_p1_fck);
-
if (omap->ehci_logic_fck && !IS_ERR(omap->ehci_logic_fck))
clk_disable(omap->ehci_logic_fck);
 
-- 
1.7.4.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] OMAPDSS: tpo-td043 panel: fix data passing between SPI/DSS parts

[Tomi Valkeinen]

On 2013-02-17 02:43, Grazvydas Ignotas wrote:
> This driver uses omap_dss_device that it gets from a board file through
> SPI platfrom_data pointer to pass data from SPI to DSS portion of the
> driver by using dev_set_drvdata(). However this trick no longer works,
> as DSS core no longer uses omap_dss_device from a board file to create
> the real device, so use a global pointer to accomplish this instead,
> like other SPI panel drivers do.

Thanks, looks fine to me.

As a side note, I'm working on removing the omap_dss_device stuff, and
after that change this driver can be a plain SPI driver. That should
make things simpler.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH] omapdrm: Make fixed resolution panels work

[Tomi Valkeinen]

On 2013-02-18 09:23, Archit Taneja wrote:

>>> diff --git a/drivers/staging/omapdrm/omap_connector.c
>>> b/drivers/staging/omapdrm/omap_connector.c
>>> index 4cc9ee7..839c6e4 100644
>>> --- a/drivers/staging/omapdrm/omap_connector.c
>>> +++ b/drivers/staging/omapdrm/omap_connector.c
>>> @@ -110,6 +110,11 @@ static enum drm_connector_status
>>> omap_connector_detect(
>>>  ret = connector_status_connected;
>>>  else
>>>  ret = connector_status_disconnected;
>>> +   } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
>>> +   dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
>>> +   dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
>>> +   dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
>>> +   ret = connector_status_connected;
>>
>> hmm, why not just have a default detect fxn for panel drivers which
>> always returns true?  Seems a bit cleaner.. otherwise, I guess we
>> could just change omap_connector so that if dssdev->detect is null,
>> assume always connected.  Seems maybe a slightly better way since
>> currently omap_connector doesn't really know too much about different
>> sorts of panels.  But I'm not too picky if that is a big pain because
>> we probably end up changing all this as CFP starts coming into
>> existence.
>>
>> Same goes for check_timings/set_timings..  it seems a bit cleaner just
>> to have default fxns in the panel drivers that do-the-right-thing,
>> although I suppose it might be a bit more convenient for out-of-tree
>> panel drivers to just assume fixed panel if these fxns are null.

Yeah, I can't make my mind about null pointer. It's nice to inform with
a null pointer that the panel doesn't support the given operation, or
that it doesn't make sense, but handling the null value makes the code a
bit complex.

For example, our VENC driver doesn't know if there's a TV connected or
not, so neither true or false as connect return value makes sense there.
Or, for a DSI command mode panel, set_timings doesn't really make much
sense.

> Maybe having default functions in omapdss might be a better idea. There
> is an option of adding default functions in omap_dss_register_driver()
> (drivers/video/omap2/dss/core.c).
> 
> Tomi, do you think it's fine to add some more default panel driver funcs?

We can add default funcs. However, adding them in
omap_dss_register_driver is not so nice, as it makes the omap_dss_driver
(which is essentially an "ops" struct) non-constable. Instead, we should
move the setting of the default funcs to the drivers.

If I'm not mistaken, we could manage that with a helper macro. Assigning
a value to the same field of a struct should be ok by the compiler, and
should cause only the last assignment to be taken into use. So:

static struct foo zab = {
.bar = 123, /* ignored */
.bar = 234, /* used */
};

And so we could have:

static struct omap_dss_driver my_panel_driver = {
OMAPDSS_DEFAULT_PANEL_OPS, /* macro for default ops */

.enable = my_panel_enable,
/* ... */
};

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency

[Santosh Shilimkar]

On Monday 18 February 2013 01:38 PM, Bedia, Vaibhav wrote:

On Sat, Feb 16, 2013 at 11:18:36, Shilimkar, Santosh wrote:
[...]


For the duplicate ioremapping, I don't think there's any need to
do it if we get things right.


Note that if the ioremap matches a static map area there is no cost to
ioremap it multiple times.



Thats true though now on OMAP we removed most of the static mappings.
The main issue is waste of IO space because, we end up mapping same
area two times for all the OMAP drivers. This can be optimized with
a arch ioremap caller hook but as discussed here, its nice to have
rather than something important.




Mostly L3 and L4 OCP slaves ones are covered because of L3/L4 map.
If you boot a full blown kernel, you will see many dynamically allocated 
as well.


Regards,
Santosh

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver

[Archit Taneja]

On Monday 18 February 2013 01:41 PM, Tomi Valkeinen wrote:

On 2013-02-18 09:33, Archit Taneja wrote:

On Thursday 14 February 2013 12:28 PM, Tomi Valkeinen wrote:

On 2013-02-14 08:51, Archit Taneja wrote:

On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:

Hi,

On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:

+static struct panel_acx565akm_data *get_panel_data(struct
omap_dss_device *dssdev)
+{
+return (struct panel_acx565akm_data *) dssdev->data;
+}
+
static int acx_panel_probe(struct omap_dss_device *dssdev)
{
int r;
struct acx565akm_device *md = &acx_dev;
+struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);


Why the get_panel_data function is needed, isn't the cast unnecessary?


the 'data' member of omap_dss_device has the type 'void *', we need to
cast it to access the panel_acx565akm_data struct pointer.


You don't need an explicit cast to assign a void pointer to a pointer to
something else (or vice versa, I think).

I remember us having similar constructs in some other panel drivers
also. I think they are unnecessary also.


I was considering keeping the get_panel_data() funcs in the panel
drivers though. This way, whenever the way of retrieving platform data
changes because of DT or CDF or something else, we would just need to
modify the get_panel_data func.


I think it's simpler if we manage the fetching of the platform data in
probe one, and just store a struct panel_acx565akm_data or such to the
panel driver's data.

For DT we don't have platform data, but we can create the same platform
data struct from the DT properties.

So the above would become something like:

struct acx565akm_device *md = &acx_dev;
struct panel_acx565akm_data *panel_data = md->pdata;


okay, that seems to be a better way.

Archit

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 net-next 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

[Mugunthan V N]

CPDMA interrupts are not properly acknowledged which leads to interrupt
storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
used for rx and tx respectively.

Reported-by: Pantelis Antoniou 
Signed-off-by: Mugunthan V N 
---
Changes from v2:
* Changed the hardware register values from enumeration to defines

 drivers/net/ethernet/ti/cpsw.c  |   25 -
 drivers/net/ethernet/ti/davinci_cpdma.c |4 ++--
 drivers/net/ethernet/ti/davinci_cpdma.h |7 ++-
 3 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 4ceed6e..7e93df6 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -510,19 +510,21 @@ static int cpsw_poll(struct napi_struct *napi, int budget)
int num_tx, num_rx;
 
num_tx = cpdma_chan_process(priv->txch, 128);
-   num_rx = cpdma_chan_process(priv->rxch, budget);
-
-   if (num_rx || num_tx)
-   cpsw_dbg(priv, intr, "poll %d rx, %d tx pkts\n",
-num_rx, num_tx);
+   if (num_tx)
+   cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_TX);
 
+   num_rx = cpdma_chan_process(priv->rxch, budget);
if (num_rx < budget) {
napi_complete(napi);
cpsw_intr_enable(priv);
-   cpdma_ctlr_eoi(priv->dma);
+   cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_RX);
cpsw_enable_irq(priv);
}
 
+   if (num_rx || num_tx)
+   cpsw_dbg(priv, intr, "poll %d rx, %d tx pkts\n",
+num_rx, num_tx);
+
return num_rx;
 }
 
@@ -835,7 +837,8 @@ static int cpsw_ndo_open(struct net_device *ndev)
cpdma_ctlr_start(priv->dma);
cpsw_intr_enable(priv);
napi_enable(&priv->napi);
-   cpdma_ctlr_eoi(priv->dma);
+   cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_RX);
+   cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_TX);
 
if (priv->data.dual_emac)
priv->slaves[priv->emac_port].open_stat = true;
@@ -1075,7 +1078,9 @@ static void cpsw_ndo_tx_timeout(struct net_device *ndev)
cpdma_chan_start(priv->txch);
cpdma_ctlr_int_ctrl(priv->dma, true);
cpsw_intr_enable(priv);
-   cpdma_ctlr_eoi(priv->dma);
+   cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_RX);
+   cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_TX);
+
 }
 
 static struct net_device_stats *cpsw_ndo_get_stats(struct net_device *ndev)
@@ -1094,7 +1099,9 @@ static void cpsw_ndo_poll_controller(struct net_device 
*ndev)
cpsw_interrupt(ndev->irq, priv);
cpdma_ctlr_int_ctrl(priv->dma, true);
cpsw_intr_enable(priv);
-   cpdma_ctlr_eoi(priv->dma);
+   cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_RX);
+   cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_TX);
+
 }
 #endif
 
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c 
b/drivers/net/ethernet/ti/davinci_cpdma.c
index 7d3bffd..68c3418 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -493,9 +493,9 @@ int cpdma_ctlr_int_ctrl(struct cpdma_ctlr *ctlr, bool 
enable)
return 0;
 }
 
-void cpdma_ctlr_eoi(struct cpdma_ctlr *ctlr)
+void cpdma_ctlr_eoi(struct cpdma_ctlr *ctlr, u32 value)
 {
-   dma_reg_write(ctlr, CPDMA_MACEOIVECTOR, 0);
+   dma_reg_write(ctlr, CPDMA_MACEOIVECTOR, value);
 }
 
 struct cpdma_chan *cpdma_chan_create(struct cpdma_ctlr *ctlr, int chan_num,
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.h 
b/drivers/net/ethernet/ti/davinci_cpdma.h
index a97d6ab..d9bcc60 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.h
+++ b/drivers/net/ethernet/ti/davinci_cpdma.h
@@ -26,6 +26,11 @@
 
 #define CPDMA_RX_SOURCE_PORT(__status__)   ((__status__ >> 16) & 0x7)
 
+#define CPDMA_EOI_RX_THRESH0x0
+#define CPDMA_EOI_RX   0x1
+#define CPDMA_EOI_TX   0x2
+#define CPDMA_EOI_MISC 0x3
+
 struct cpdma_params {
struct device   *dev;
void __iomem*dmaregs;
@@ -88,7 +93,7 @@ int cpdma_chan_submit(struct cpdma_chan *chan, void *token, 
void *data,
 int cpdma_chan_process(struct cpdma_chan *chan, int quota);
 
 int cpdma_ctlr_int_ctrl(struct cpdma_ctlr *ctlr, bool enable);
-void cpdma_ctlr_eoi(struct cpdma_ctlr *ctlr);
+void cpdma_ctlr_eoi(struct cpdma_ctlr *ctlr, u32 value);
 int cpdma_chan_int_ctrl(struct cpdma_chan *chan, bool enable);
 bool cpdma_check_free_tx_desc(struct cpdma_chan *chan);
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver

[Tomi Valkeinen]

On 2013-02-18 09:33, Archit Taneja wrote:
> On Thursday 14 February 2013 12:28 PM, Tomi Valkeinen wrote:
>> On 2013-02-14 08:51, Archit Taneja wrote:
>>> On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
 Hi,

 On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
> +static struct panel_acx565akm_data *get_panel_data(struct
> omap_dss_device *dssdev)
> +{
> +return (struct panel_acx565akm_data *) dssdev->data;
> +}
> +
>static int acx_panel_probe(struct omap_dss_device *dssdev)
>{
>int r;
>struct acx565akm_device *md = &acx_dev;
> +struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);

 Why the get_panel_data function is needed, isn't the cast unnecessary?
>>>
>>> the 'data' member of omap_dss_device has the type 'void *', we need to
>>> cast it to access the panel_acx565akm_data struct pointer.
>>
>> You don't need an explicit cast to assign a void pointer to a pointer to
>> something else (or vice versa, I think).
>>
>> I remember us having similar constructs in some other panel drivers
>> also. I think they are unnecessary also.
> 
> I was considering keeping the get_panel_data() funcs in the panel
> drivers though. This way, whenever the way of retrieving platform data
> changes because of DT or CDF or something else, we would just need to
> modify the get_panel_data func.

I think it's simpler if we manage the fetching of the platform data in
probe one, and just store a struct panel_acx565akm_data or such to the
panel driver's data.

For DT we don't have platform data, but we can create the same platform
data struct from the DT properties.

So the above would become something like:

struct acx565akm_device *md = &acx_dev;
struct panel_acx565akm_data *panel_data = md->pdata;

 Tomi




signature.asc
Description: OpenPGP digital signature

RE: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency

[Bedia, Vaibhav]

On Sat, Feb 16, 2013 at 11:18:36, Shilimkar, Santosh wrote:
[...]
> >>
> >> For the duplicate ioremapping, I don't think there's any need to
> >> do it if we get things right.
> >
> > Note that if the ioremap matches a static map area there is no cost to
> > ioremap it multiple times.
> >
> >
> Thats true though now on OMAP we removed most of the static mappings.
> The main issue is waste of IO space because, we end up mapping same
> area two times for all the OMAP drivers. This can be optimized with
> a arch ioremap caller hook but as discussed here, its nice to have
> rather than something important.
> 

Err.. I was looking at the iotable_init for OMAPx in mainline and it looks
like most (all?) of the peripherals are already covered in the static mappings?

Regards,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html