Re: [PATCH V2 1/1] mmc: start removing enable / disable API
On 2/29/2012 12:47 PM, Adrian Hunter wrote:
Most parts of the enable / disable API are no longer used and
can be removed.
Cc: Rajendra Nayakrna...@ti.com
Cc: Venkatraman Ssvenk...@ti.com
Cc: Kukjin Kimkgene@samsung.com
Cc: Thomas Abrahamthomas.abra...@linaro.org
Cc: Kyungmin Parkkyungmin.p...@samsung.com
Cc: Sekhar Norinsek...@ti.com
Cc: Kevin Hilmankhil...@ti.com
Signed-off-by: Adrian Hunteradrian.hun...@intel.com
---
arch/arm/mach-exynos/mach-nuri.c |5 +-
arch/arm/mach-exynos/mach-universal_c210.c |9 +-
drivers/mmc/core/core.c| 187 +++-
drivers/mmc/core/host.c|1 -
drivers/mmc/core/host.h|1 -
drivers/mmc/host/davinci_mmc.c |4 -
drivers/mmc/host/omap_hsmmc.c | 15 +--
include/linux/mmc/core.h |1 -
include/linux/mmc/host.h | 46 +--
9 files changed, 27 insertions(+), 242 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c
index 644af11..de68248 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -109,7 +109,7 @@ static struct s3c_sdhci_platdata nuri_hsmmc0_data
__initdata = {
.max_width = 8,
.host_caps = (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA |
MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
- MMC_CAP_DISABLE | MMC_CAP_ERASE),
+ MMC_CAP_ERASE),
.cd_type= S3C_SDHCI_CD_PERMANENT,
};
@@ -147,8 +147,7 @@ static struct platform_device emmc_fixed_voltage = {
static struct s3c_sdhci_platdata nuri_hsmmc2_data __initdata = {
.max_width = 4,
.host_caps = MMC_CAP_4_BIT_DATA |
- MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
- MMC_CAP_DISABLE,
+ MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
.ext_cd_gpio= EXYNOS4_GPX3(3), /* XEINT_27 */
.ext_cd_gpio_invert = 1,
.cd_type= S3C_SDHCI_CD_GPIO,
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
b/arch/arm/mach-exynos/mach-universal_c210.c
index 9b3fbae..57cfe61 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -734,8 +734,7 @@ static struct platform_device universal_gpio_keys = {
static struct s3c_sdhci_platdata universal_hsmmc0_data __initdata = {
.max_width = 8,
.host_caps = (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA |
- MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
- MMC_CAP_DISABLE),
+ MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED),
.cd_type= S3C_SDHCI_CD_PERMANENT,
};
@@ -772,8 +771,7 @@ static struct platform_device mmc0_fixed_voltage = {
static struct s3c_sdhci_platdata universal_hsmmc2_data __initdata = {
.max_width = 4,
.host_caps = MMC_CAP_4_BIT_DATA |
- MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
- MMC_CAP_DISABLE,
+ MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
.ext_cd_gpio= EXYNOS4_GPX3(4), /* XEINT_28 */
.ext_cd_gpio_invert = 1,
.cd_type= S3C_SDHCI_CD_GPIO,
@@ -783,8 +781,7 @@ static struct s3c_sdhci_platdata universal_hsmmc2_data
__initdata = {
static struct s3c_sdhci_platdata universal_hsmmc3_data __initdata = {
.max_width = 4,
.host_caps = MMC_CAP_4_BIT_DATA |
- MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
- MMC_CAP_DISABLE,
+ MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
.cd_type= S3C_SDHCI_CD_EXTERNAL,
};
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 0b317f0..44dd013 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -605,105 +605,6 @@ unsigned int mmc_align_data_size(struct mmc_card *card,
unsigned int sz)
EXPORT_SYMBOL(mmc_align_data_size);
/**
- * mmc_host_enable - enable a host.
- * @host: mmc host to enable
- *
- * Hosts that support power saving can use the 'enable' and 'disable'
- * methods to exit and enter power saving states. For more information
- * see comments for struct mmc_host_ops.
- */
-int mmc_host_enable(struct mmc_host *host)
-{
- if (!(host-caps MMC_CAP_DISABLE))
- return 0;
-
- if (host-en_dis_recurs)
- return 0;
-
- if (host-nesting_cnt++)
- return 0;
-
-
[PATCH 0/7] remoteproc: additional virtio support
The patch set focuses on extending remoteproc's virtio support: we're
putting behind the single rpmsg virtio device limitation, and allowing
firmwares to publish any number of virtio devices and of any type.
This allows us to reuse the existing virtio drivers with remote processor
backends.
For example, by publishing a virtio console device and hooking it up to the
logging mechanism of OMAP's SYS/BIOS (the RTOS which runs on the M3
subsystem), we get a fancy console with log messages coming from the M3
without writing any additional driver:
root@omap4430-panda:~# modprobe virtio_console
root@omap4430-panda:~# cat /dev/hvc0
M3 Core0 init...
Hello from SYS/BIOS
copyTask 50: Entered...:
registering rpmsg-client-sample service on 50 with HOST
copyTask 51: Entered...:
registering rpmsg-proto service on 51 with HOST
registering rpmsg-omx service on 60 with HOST
copyTask 1: Received data: hello world!, len:12
copyTask 2: Received data: hello world!, len:12
copyTask 3: Received data: hello world!, len:12
...
Note: at this point, whether you can start using vanilla virtio drivers
with your remote processor strongly depends on your platform. E.g., there
are additional changes required for this to work on OMAP4 (mainly to
satisfy the M3's iommu requirements), and that's not upstream yet.
Other non-iommu remote processors might be able to use vanilla virtio
drivers though (probably DaVinci, for example, but this wasn't tested yet).
Cc: Brian Swetland swetl...@google.com
Cc: Iliyan Malchev malc...@google.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rusty Russell ru...@rustcorp.com.au
Cc: Mark Grosen mgro...@ti.com
Cc: John Williams john.willi...@petalogix.com
Cc: Michal Simek mon...@monstr.eu
Cc: Loic PALLARDY loic.palla...@stericsson.com
Cc: Ludovic BARRE ludovic.ba...@stericsson.com
Cc: Omar Ramirez Luna omar.l...@linaro.org
Cc: Guzman Lugo Fernando fernando.l...@ti.com
Cc: Anna Suman s-a...@ti.com
Cc: Clark Rob r...@ti.com
Cc: Stephen Boyd sb...@codeaurora.org
Cc: Saravana Kannan skan...@codeaurora.org
Cc: David Brown dav...@codeaurora.org
Cc: Kieran Bingham kieranbing...@gmail.com
Cc: Tony Lindgren t...@atomide.com
Ohad Ben-Cohen (7):
remoteproc: resource table overhaul
remoteproc: remoteproc_rpmsg - remoteproc_virtio
remoteproc: safer boot/shutdown order
remoteproc: remove the single rpmsg vdev limitation
remoteproc/omap: remove the mbox_callback limitation
remoteproc: remove the hardcoded vring alignment
remoteproc: cleanup resource table parsing paths
Documentation/remoteproc.txt | 136 +++---
drivers/remoteproc/Makefile|2 +-
drivers/remoteproc/omap_remoteproc.c | 11 +-
drivers/remoteproc/remoteproc_core.c | 524
drivers/remoteproc/remoteproc_internal.h |6 +-
.../{remoteproc_rpmsg.c = remoteproc_virtio.c}| 162 +++
include/linux/remoteproc.h | 339 ++---
7 files changed, 747 insertions(+), 433 deletions(-)
rename drivers/remoteproc/{remoteproc_rpmsg.c = remoteproc_virtio.c} (65%)
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] remoteproc: remoteproc_rpmsg - remoteproc_virtio
At this point remoteproc can only register a single VIRTIO_ID_RPMSG virtio
device.
This limitation is going away soon: remoteproc is getting support for
registering any number of virtio devices and of any type (as
published by the firmware of the remote processor).
Rename remoteproc_rpmsg.c to remoteproc_virtio.c in preparation of
this generalization work.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Brian Swetland swetl...@google.com
Cc: Iliyan Malchev malc...@google.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rusty Russell ru...@rustcorp.com.au
Cc: Mark Grosen mgro...@ti.com
Cc: John Williams john.willi...@petalogix.com
Cc: Michal Simek mon...@monstr.eu
Cc: Loic PALLARDY loic.palla...@stericsson.com
Cc: Ludovic BARRE ludovic.ba...@stericsson.com
Cc: Omar Ramirez Luna omar.l...@linaro.org
Cc: Guzman Lugo Fernando fernando.l...@ti.com
Cc: Anna Suman s-a...@ti.com
Cc: Clark Rob r...@ti.com
Cc: Stephen Boyd sb...@codeaurora.org
Cc: Saravana Kannan skan...@codeaurora.org
Cc: David Brown dav...@codeaurora.org
Cc: Kieran Bingham kieranbing...@gmail.com
Cc: Tony Lindgren t...@atomide.com
---
drivers/remoteproc/Makefile|2 +-
.../{remoteproc_rpmsg.c = remoteproc_virtio.c}|0
2 files changed, 1 insertions(+), 1 deletions(-)
rename drivers/remoteproc/{remoteproc_rpmsg.c = remoteproc_virtio.c} (100%)
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index df0897f..5445d9b 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -5,5 +5,5 @@
obj-$(CONFIG_REMOTEPROC) += remoteproc.o
remoteproc-y := remoteproc_core.o
remoteproc-y += remoteproc_debugfs.o
-remoteproc-y += remoteproc_rpmsg.o
+remoteproc-y += remoteproc_virtio.o
obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
diff --git a/drivers/remoteproc/remoteproc_rpmsg.c
b/drivers/remoteproc/remoteproc_virtio.c
similarity index 100%
rename from drivers/remoteproc/remoteproc_rpmsg.c
rename to drivers/remoteproc/remoteproc_virtio.c
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] remoteproc: resource table overhaul
The resource table is an array of 'struct fw_resource' members, where
each resource entry is expressed as a single member of that array.
This approach got us this far, but it has a few drawbacks:
1. Different resource entries end up overloading the same members of 'struct
fw_resource' with different meanings. The resulting code is error prone
and hard to read and maintain.
2. It's impossible to extend 'struct fw_resource' without breaking the
existing firmware images (and we already want to: we can't introduce the
new virito device resource entry with the current scheme).
3. It doesn't scale: 'struct fw_resource' must be as big as the largest
resource entry type. As a result, smaller resource entries end up
utilizing only small part of it.
This is fixed by defining a dedicated structure for every resource type,
and then converting the resource table to a list of type-value members.
Instead of a rigid array of homogeneous structs, the resource table
is turned into a collection of heterogeneous structures.
This way:
1. Resource entries consume exactly the amount of bytes they need.
2. It's easy to extend: just create a new resource entry structure, and assign
it a new type.
3. The code is easier to read and maintain: the structures' members names are
meaningful.
While we're at it, this patch has several other resource table changes:
1. The resource table gains a simple header which contains the
number of entries in the table and their offsets within the table. This
makes the parsing code simpler and easier to read.
2. A version member is added to the resource table. Should we change the
format again, we'll bump up this version to prevent breakage with
existing firmware images.
3. The VRING and VIRTIO_DEV resource entries are combined to a single
VDEV entry. This paves the way to supporting multiple VDEV entries.
4. Since we don't really support 64-bit rprocs yet, convert two stray u64
members to u32.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Brian Swetland swetl...@google.com
Cc: Iliyan Malchev malc...@google.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rusty Russell ru...@rustcorp.com.au
Cc: Mark Grosen mgro...@ti.com
Cc: John Williams john.willi...@petalogix.com
Cc: Michal Simek mon...@monstr.eu
Cc: Loic PALLARDY loic.palla...@stericsson.com
Cc: Ludovic BARRE ludovic.ba...@stericsson.com
Cc: Omar Ramirez Luna omar.l...@linaro.org
Cc: Guzman Lugo Fernando fernando.l...@ti.com
Cc: Anna Suman s-a...@ti.com
Cc: Clark Rob r...@ti.com
Cc: Stephen Boyd sb...@codeaurora.org
Cc: Saravana Kannan skan...@codeaurora.org
Cc: David Brown dav...@codeaurora.org
Cc: Kieran Bingham kieranbing...@gmail.com
Cc: Tony Lindgren t...@atomide.com
---
Documentation/remoteproc.txt | 127 +++
drivers/remoteproc/remoteproc_core.c | 306 +++---
include/linux/remoteproc.h | 289 ++--
3 files changed, 505 insertions(+), 217 deletions(-)
diff --git a/Documentation/remoteproc.txt b/Documentation/remoteproc.txt
index 23ff734..07057ca 100644
--- a/Documentation/remoteproc.txt
+++ b/Documentation/remoteproc.txt
@@ -221,43 +221,52 @@ resource entries that publish the existence of supported
features
or configurations by the remote processor, such as trace buffers and
supported virtio devices (and their configurations).
-Currently the resource table is just an array of:
+The resource table begins with this header:
/**
- * struct fw_resource - describes an entry from the resource section
+ * struct resource_table - firmware resource table header
+ * @ver: version number
+ * @num: number of resource entries
+ * @reserved: reserved (must be zero)
+ * @offset: array of offsets pointing at the various resource entries
+ *
+ * The header of the resource table, as expressed by this structure,
+ * contains a version number (should we need to change this format in the
+ * future), the number of available resource entries, and their offsets
+ * in the table.
+ */
+struct resource_table {
+ u32 ver;
+ u32 num;
+ u32 reserved[2];
+ u32 offset[0];
+} __packed;
+
+Immediately following this header are the resource entries themselves,
+each of which begins with the following resource entry header:
+
+/**
+ * struct fw_rsc_hdr - firmware resource entry header
* @type: resource type
- * @id: index number of the resource
- * @da: device address of the resource
- * @pa: physical address of the resource
- * @len: size, in bytes, of the resource
- * @flags: properties of the resource, e.g. iommu protection required
- * @reserved: must be 0 atm
- * @name: name of resource
+ * @data: resource data
+ *
+ * Every resource entry begins with a 'struct fw_rsc_hdr' header providing
+ * its @type. The content of the entry itself will immediately follow
+ * this header, and it should be parsed according to the resource type.
*/
-struct fw_resource {
[PATCH 3/7] remoteproc: safer boot/shutdown order
Boot the remote processor only after setting up the virtqueues,
and shut it down before deleting them.
Remote processors should obey virtio status changes, and
therefore not manipulate/trigger the virtqueues while the virtio
driver isn't ready, but it's just safer not to rely on that
(plus a vq access might already be inflight while a vdev
status is changed).
We also don't have yet status change notifications, but that's
a temporary limitation.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Brian Swetland swetl...@google.com
Cc: Iliyan Malchev malc...@google.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rusty Russell ru...@rustcorp.com.au
Cc: Mark Grosen mgro...@ti.com
Cc: John Williams john.willi...@petalogix.com
Cc: Michal Simek mon...@monstr.eu
Cc: Loic PALLARDY loic.palla...@stericsson.com
Cc: Ludovic BARRE ludovic.ba...@stericsson.com
Cc: Omar Ramirez Luna omar.l...@linaro.org
Cc: Guzman Lugo Fernando fernando.l...@ti.com
Cc: Anna Suman s-a...@ti.com
Cc: Clark Rob r...@ti.com
Cc: Stephen Boyd sb...@codeaurora.org
Cc: Saravana Kannan skan...@codeaurora.org
Cc: David Brown dav...@codeaurora.org
Cc: Kieran Bingham kieranbing...@gmail.com
Cc: Tony Lindgren t...@atomide.com
---
drivers/remoteproc/remoteproc_virtio.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_virtio.c
b/drivers/remoteproc/remoteproc_virtio.c
index 4f73e81..78d8527 100644
--- a/drivers/remoteproc/remoteproc_virtio.c
+++ b/drivers/remoteproc/remoteproc_virtio.c
@@ -123,14 +123,14 @@ static void rproc_virtio_del_vqs(struct virtio_device
*vdev)
struct virtqueue *vq, *n;
struct rproc *rproc = vdev_to_rproc(vdev);
+ /* power down the remote processor before deleting vqs */
+ rproc_shutdown(rproc);
+
list_for_each_entry_safe(vq, n, vdev-vqs, list) {
struct rproc_virtio_vq_info *rpvq = vq-priv;
vring_del_virtqueue(vq);
kfree(rpvq);
}
-
- /* power down the remote processor */
- rproc_shutdown(rproc);
}
static int rproc_virtio_find_vqs(struct virtio_device *vdev, unsigned nvqs,
@@ -145,13 +145,6 @@ static int rproc_virtio_find_vqs(struct virtio_device
*vdev, unsigned nvqs,
if (nvqs != 2)
return -EINVAL;
- /* boot the remote processor */
- ret = rproc_boot(rproc);
- if (ret) {
- dev_err(rproc-dev, rproc_boot() failed %d\n, ret);
- goto error;
- }
-
for (i = 0; i nvqs; ++i) {
vqs[i] = rp_find_vq(vdev, i, callbacks[i], names[i]);
if (IS_ERR(vqs[i])) {
@@ -160,6 +153,13 @@ static int rproc_virtio_find_vqs(struct virtio_device
*vdev, unsigned nvqs,
}
}
+ /* now that the vqs are all set, boot the remote processor */
+ ret = rproc_boot(rproc);
+ if (ret) {
+ dev_err(rproc-dev, rproc_boot() failed %d\n, ret);
+ goto error;
+ }
+
return 0;
error:
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] remoteproc/omap: remove the mbox_callback limitation
Now that remoteproc supports any number of virtio devices,
the previous sanity check in omap_rproc_mbox_callback
doesn't make sense anymore.
Remove that so we can start supporting multiple vdevs.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Brian Swetland swetl...@google.com
Cc: Iliyan Malchev malc...@google.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rusty Russell ru...@rustcorp.com.au
Cc: Mark Grosen mgro...@ti.com
Cc: John Williams john.willi...@petalogix.com
Cc: Michal Simek mon...@monstr.eu
Cc: Loic PALLARDY loic.palla...@stericsson.com
Cc: Ludovic BARRE ludovic.ba...@stericsson.com
Cc: Omar Ramirez Luna omar.l...@linaro.org
Cc: Guzman Lugo Fernando fernando.l...@ti.com
Cc: Anna Suman s-a...@ti.com
Cc: Clark Rob r...@ti.com
Cc: Stephen Boyd sb...@codeaurora.org
Cc: Saravana Kannan skan...@codeaurora.org
Cc: David Brown dav...@codeaurora.org
Cc: Kieran Bingham kieranbing...@gmail.com
Cc: Tony Lindgren t...@atomide.com
---
drivers/remoteproc/omap_remoteproc.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/drivers/remoteproc/omap_remoteproc.c
b/drivers/remoteproc/omap_remoteproc.c
index aa3ce52..69425c4 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -80,16 +80,7 @@ static int omap_rproc_mbox_callback(struct notifier_block
*this,
dev_info(dev, received echo reply from %s\n, name);
break;
default:
- /* ignore vq indices which are too large to be valid */
- if (msg = 2) {
- dev_warn(dev, invalid mbox msg: 0x%x\n, msg);
- break;
- }
-
- /*
-* At this point, 'msg' contains the index of the vring
-* which was just triggered.
-*/
+ /* msg contains the index of the triggered vring */
if (rproc_vq_interrupt(oproc-rproc, msg) == IRQ_NONE)
dev_dbg(dev, no message was found in vqid %d\n, msg);
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] remoteproc: remove the hardcoded vring alignment
Remove the hardcoded vring alignment of 4096 bytes,
and instead utilize tha vring alignment as specified in
the resource table.
This is needed for remote processors that have rigid
memory requirement, and which have found the alignment of
4096 bytes to be excessively big.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Brian Swetland swetl...@google.com
Cc: Iliyan Malchev malc...@google.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rusty Russell ru...@rustcorp.com.au
Cc: Mark Grosen mgro...@ti.com
Cc: John Williams john.willi...@petalogix.com
Cc: Michal Simek mon...@monstr.eu
Cc: Loic PALLARDY loic.palla...@stericsson.com
Cc: Ludovic BARRE ludovic.ba...@stericsson.com
Cc: Omar Ramirez Luna omar.l...@linaro.org
Cc: Guzman Lugo Fernando fernando.l...@ti.com
Cc: Anna Suman s-a...@ti.com
Cc: Clark Rob r...@ti.com
Cc: Stephen Boyd sb...@codeaurora.org
Cc: Saravana Kannan skan...@codeaurora.org
Cc: David Brown dav...@codeaurora.org
Cc: Kieran Bingham kieranbing...@gmail.com
Cc: Tony Lindgren t...@atomide.com
---
drivers/remoteproc/remoteproc_core.c | 12 +++-
drivers/remoteproc/remoteproc_virtio.c |2 +-
include/linux/remoteproc.h |9 ++---
3 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index ca02f12..9be5dad 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -298,14 +298,15 @@ __rproc_handle_vring(struct rproc_vdev *rvdev, struct
fw_rsc_vdev *rsc, int i)
return -EINVAL;
}
- /* the firmware must provide the expected queue size */
- if (!vring-num) {
- dev_err(dev, invalid qsz (%d)\n, vring-num);
+ /* verify queue size and vring alignment are sane */
+ if (!vring-num || !vring-align) {
+ dev_err(dev, invalid qsz (%d) or alignment (%d)\n,
+ vring-num, vring-align);
return -EINVAL;
}
/* actual size of vring (in bytes) */
- size = PAGE_ALIGN(vring_size(vring-num, AMP_VRING_ALIGN));
+ size = PAGE_ALIGN(vring_size(vring-num, vring-align));
if (!idr_pre_get(rproc-notifyids, GFP_KERNEL)) {
dev_err(dev, idr_pre_get failed\n);
@@ -340,6 +341,7 @@ __rproc_handle_vring(struct rproc_vdev *rvdev, struct
fw_rsc_vdev *rsc, int i)
dma, size, notifyid);
rvdev-vring[i].len = vring-num;
+ rvdev-vring[i].align = vring-align;
rvdev-vring[i].va = va;
rvdev-vring[i].dma = dma;
rvdev-vring[i].notifyid = notifyid;
@@ -354,7 +356,7 @@ static void __rproc_free_vrings(struct rproc_vdev *rvdev,
int i)
for (i--; i 0; i--) {
struct rproc_vring *rvring = rvdev-vring[i];
- int size = PAGE_ALIGN(vring_size(rvring-len, AMP_VRING_ALIGN));
+ int size = PAGE_ALIGN(vring_size(rvring-len, rvring-align));
dma_free_coherent(rproc-dev, size, rvring-va, rvring-dma);
idr_remove(rproc-notifyids, rvring-notifyid);
diff --git a/drivers/remoteproc/remoteproc_virtio.c
b/drivers/remoteproc/remoteproc_virtio.c
index 0700410..ecf6121 100644
--- a/drivers/remoteproc/remoteproc_virtio.c
+++ b/drivers/remoteproc/remoteproc_virtio.c
@@ -99,7 +99,7 @@ static struct virtqueue *rp_find_vq(struct virtio_device
*vdev,
* Create the new vq, and tell virtio we're not interested in
* the 'weak' smp barriers, since we're talking with a real device.
*/
- vq = vring_new_virtqueue(len, AMP_VRING_ALIGN, vdev, false, addr,
+ vq = vring_new_virtqueue(len, rvring-align, vdev, false, addr,
rproc_virtio_notify, callback, name);
if (!vq) {
dev_err(rproc-dev, vring_new_virtqueue %s failed\n, name);
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 7750d8a..f1ffabb 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -43,13 +43,6 @@
#include linux/completion.h
#include linux/idr.h
-/*
- * The alignment between the consumer and producer parts of the vring.
- * Note: this is part of the wire protocol. If you change this, you need
- * to update your peers too.
- */
-#define AMP_VRING_ALIGN(4096)
-
/**
* struct resource_table - firmware resource table header
* @ver: version number
@@ -423,6 +416,7 @@ struct rproc {
* @dma: dma address
* @len: length, in bytes
* @da: device address
+ * @align: vring alignment
* @notifyid: rproc-specific unique vring index
* @rvdev: remote vdev
* @vq: the virtqueue of this vring
@@ -432,6 +426,7 @@ struct rproc_vring {
dma_addr_t dma;
int len;
u32 da;
+ u32 align;
int notifyid;
struct rproc_vdev *rvdev;
struct virtqueue *vq;
--
1.7.5.4
--
To unsubscribe
[PATCH 7/7] remoteproc: cleanup resource table parsing paths
rproc_handle_resources() looks for the resource table and then
invokes a resource handler function which it took as a parameter.
This works, but it's a bit unintuitive to follow.
Instead of passing around function pointers, this patch changes
rproc_handle_resource() to just find and return the resource table,
and then the calling sites of rproc_handle_resource() invoke their
resource handlers directly.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Brian Swetland swetl...@google.com
Cc: Iliyan Malchev malc...@google.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rusty Russell ru...@rustcorp.com.au
Cc: Mark Grosen mgro...@ti.com
Cc: John Williams john.willi...@petalogix.com
Cc: Michal Simek mon...@monstr.eu
Cc: Loic PALLARDY loic.palla...@stericsson.com
Cc: Ludovic BARRE ludovic.ba...@stericsson.com
Cc: Omar Ramirez Luna omar.l...@linaro.org
Cc: Guzman Lugo Fernando fernando.l...@ti.com
Cc: Anna Suman s-a...@ti.com
Cc: Clark Rob r...@ti.com
Cc: Stephen Boyd sb...@codeaurora.org
Cc: Saravana Kannan skan...@codeaurora.org
Cc: David Brown dav...@codeaurora.org
Cc: Kieran Bingham kieranbing...@gmail.com
Cc: Tony Lindgren t...@atomide.com
---
drivers/remoteproc/remoteproc_core.c | 70 ++---
1 files changed, 38 insertions(+), 32 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 9be5dad..ee15c68 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -822,32 +822,31 @@ rproc_handle_virtio_rsc(struct rproc *rproc, struct
resource_table *table, int l
}
/**
- * rproc_handle_resources() - find and handle the resource table
+ * rproc_find_rsc_table() - find the resource table
* @rproc: the rproc handle
* @elf_data: the content of the ELF firmware image
* @len: firmware size (in bytes)
- * @handler: function that should be used to handle the resource table
+ * @tablesz: place holder for providing back the table size
*
* This function finds the resource table inside the remote processor's
- * firmware, and invoke a user-supplied handler with it (we have two
- * possible handlers: one is invoked upon registration of @rproc,
- * in order to register the supported virito devices, and the other is
- * invoked when @rproc is actually booted).
- *
- * Currently this function fails if a resource table doesn't exist.
- * This restriction will be removed when we'll start supporting remote
- * processors that don't need a resource table.
+ * firmware. It is used both upon the registration of @rproc (in order
+ * to look for and register the supported virito devices), and when the
+ * @rproc is booted.
+ *
+ * Returns the pointer to the resource table if it is found, and write its
+ * size into @tablesz. If a valid table isn't found, NULL is returned
+ * (and @tablesz isn't set).
*/
-static int rproc_handle_resources(struct rproc *rproc, const u8 *elf_data,
- size_t len, rproc_handle_resources_t handler)
-
+static struct resource_table *
+rproc_find_rsc_table(struct rproc *rproc, const u8 *elf_data, size_t len,
+ int *tablesz)
{
struct elf32_hdr *ehdr;
struct elf32_shdr *shdr;
const char *name_table;
struct device *dev = rproc-dev;
- int i, ret = -EINVAL;
- struct resource_table *table;
+ struct resource_table *table = NULL;
+ int i;
ehdr = (struct elf32_hdr *)elf_data;
shdr = (struct elf32_shdr *)(elf_data + ehdr-e_shoff);
@@ -866,39 +865,39 @@ static int rproc_handle_resources(struct rproc *rproc,
const u8 *elf_data,
/* make sure we have the entire table */
if (offset + size len) {
dev_err(dev, resource table truncated\n);
- return -EINVAL;
+ return NULL;
}
/* make sure table has at least the header */
if (sizeof(struct resource_table) size) {
dev_err(dev, header-less resource table\n);
- return -EINVAL;
+ return NULL;
}
/* we don't support any version beyond the first */
if (table-ver != 1) {
dev_err(dev, unsupported fw ver: %d\n, table-ver);
- return -EINVAL;
+ return NULL;
}
/* make sure reserved bytes are zeroes */
if (table-reserved[0] || table-reserved[1]) {
dev_err(dev, non zero reserved bytes\n);
- return -EINVAL;
+ return NULL;
}
/* make sure the offsets array isn't truncated */
if (table-num * sizeof(table-offset[0]) +
sizeof(struct resource_table)
[PATCH 4/7] remoteproc: remove the single rpmsg vdev limitation
Now that the resource table supports publishing a virtio device
in a single resource entry, firmware images can start supporting
more than a single vdev.
This patch removes the single vdev limitation of the remoteproc
framework so multi-vdev firmwares can be leveraged: VDEV resource
entries are parsed when the rproc is registered, and as a result
their vrings are set up and the virtio devices are registered
(and they go away when the rproc goes away).
Moreover, we no longer only support VIRTIO_ID_RPMSG vdevs; any
virtio device type goes now. As a result, there's no more any
rpmsg-specific APIs or code in remoteproc: it all becomes generic
virtio handling.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Brian Swetland swetl...@google.com
Cc: Iliyan Malchev malc...@google.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rusty Russell ru...@rustcorp.com.au
Cc: Mark Grosen mgro...@ti.com
Cc: John Williams john.willi...@petalogix.com
Cc: Michal Simek mon...@monstr.eu
Cc: Loic PALLARDY loic.palla...@stericsson.com
Cc: Ludovic BARRE ludovic.ba...@stericsson.com
Cc: Omar Ramirez Luna omar.l...@linaro.org
Cc: Guzman Lugo Fernando fernando.l...@ti.com
Cc: Anna Suman s-a...@ti.com
Cc: Clark Rob r...@ti.com
Cc: Stephen Boyd sb...@codeaurora.org
Cc: Saravana Kannan skan...@codeaurora.org
Cc: David Brown dav...@codeaurora.org
Cc: Kieran Bingham kieranbing...@gmail.com
Cc: Tony Lindgren t...@atomide.com
---
Documentation/remoteproc.txt |9 +-
drivers/remoteproc/remoteproc_core.c | 292 +++---
drivers/remoteproc/remoteproc_internal.h |6 +-
drivers/remoteproc/remoteproc_virtio.c | 140 +++
include/linux/remoteproc.h | 41 -
5 files changed, 260 insertions(+), 228 deletions(-)
diff --git a/Documentation/remoteproc.txt b/Documentation/remoteproc.txt
index 07057ca..70a048c 100644
--- a/Documentation/remoteproc.txt
+++ b/Documentation/remoteproc.txt
@@ -20,6 +20,11 @@ platform-specific remoteproc drivers only need to provide a
few low-level
handlers, and then all rpmsg drivers will then just work
(for more information about the virtio-based rpmsg bus and its drivers,
please read Documentation/rpmsg.txt).
+Registration of other types of virtio devices is now also possible. Firmwares
+just need to publish what kind of virtio devices do they support, and then
+remoteproc will add those devices. This makes it possible to reuse the
+existing virtio drivers with remote processor backends at a minimal development
+cost.
2. User API
@@ -136,8 +141,6 @@ int dummy_rproc_example(struct rproc *my_rproc)
If found, those virtio devices will be created and added, so as a result
of registering this remote processor, additional virtio drivers might get
probed.
- Currently, though, we only support a single RPMSG virtio vdev per remote
- processor.
int rproc_unregister(struct rproc *rproc)
- Unregister a remote processor, and decrement its refcount.
@@ -174,7 +177,7 @@ struct rproc_ops {
};
Every remoteproc implementation should at least provide the -start and -stop
-handlers. If rpmsg functionality is also desired, then the -kick handler
+handlers. If rpmsg/virtio functionality is also desired, then the -kick
handler
should be provided as well.
The -start() handler takes an rproc handle and should then power on the
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 1034845..ca02f12 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -52,8 +52,8 @@ static void klist_rproc_put(struct klist_node *n);
* We need this in order to support name-based lookups (needed by the
* rproc_get_by_name()).
*
- * That said, we don't use rproc_get_by_name() anymore within the rpmsg
- * framework. The use cases that do require its existence should be
+ * That said, we don't use rproc_get_by_name() at this point.
+ * The use cases that do require its existence should be
* scrutinized, and hopefully migrated to rproc_boot() using device-based
* binding.
*
@@ -279,80 +279,112 @@ rproc_load_segments(struct rproc *rproc, const u8
*elf_data, size_t len)
return ret;
}
-/**
- * rproc_handle_early_vdev() - early handle a virtio header resource
- * @rproc: the remote processor
- * @rsc: the resource descriptor
- * @avail: size of available data (for sanity checking the image)
- *
- * The existence of this virtio hdr resource entry means that the firmware
- * of this @rproc supports this virtio device.
- *
- * Currently we support only a single virtio device of type VIRTIO_ID_RPMSG,
- * but the plan is to remove this limitation and support any number
- * of virtio devices (and of any type). We'll also add support for dynamically
- * adding (and removing) virtio devices over the rpmsg bus, but simple
- * firmwares that doesn't want to get involved with rpmsg will be able
- * to
[PATCH] OMAPDSS: HDMI: wait for RXDET before putting phy in TX_ON
From: Mythri P K mythr...@ti.com
Currently TX_PHY is put to TX_ON(transmission state) on receiving HPD.
It just ensures that the TV is connected but does not guarantee
that TMDS data lines and clock lines are up and ready for transmission.
Which although is very rare scenario has a potential to damage the HDMI
port.(A use case where TV is connected to board but it is in different
channel would still trigger a HPD but TMDS lines will be down).
Thus this patch adds a rxdet check on getting a HPD which ensures that
TMDS lines are UP before changing the PHY state from LDO_ON to TX_ON.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 37 +++-
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |2 +
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index bb784d2..bc55528 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -224,6 +224,30 @@ void ti_hdmi_4xxx_pll_disable(struct hdmi_ip_data *ip_data)
hdmi_set_pll_pwr(ip_data, HDMI_PLLPWRCMD_ALLOFF);
}
+int hdmi_ti_4xxx_rxdet(struct hdmi_ip_data *ip_data)
+{
+ int loop = 0, tmds_data0, tmds_data1, tmds_data2, tmds_clk;
+
+ hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_WP_DEBUG_CFG, 4);
+
+ do {
+ tmds_data0 = hdmi_read_reg(hdmi_wp_base(ip_data),
+ HDMI_WP_WP_DEBUG_DATA);
+ tmds_data1 = hdmi_read_reg(hdmi_wp_base(ip_data),
+ HDMI_WP_WP_DEBUG_DATA);
+ tmds_data2 = hdmi_read_reg(hdmi_wp_base(ip_data),
+ HDMI_WP_WP_DEBUG_DATA);
+ tmds_clk = hdmi_read_reg(hdmi_wp_base(ip_data),
+ HDMI_WP_WP_DEBUG_DATA);
+ udelay(15);
+ } while ((tmds_data0 != tmds_data1 || tmds_data1 != tmds_data2
+ || tmds_data1 != tmds_clk) (loop 500));
+
+ hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_WP_DEBUG_CFG, 0);
+
+ return ((loop == 500) ? -1 : (tmds_data0 1)) ;
+}
+
static int hdmi_check_hpd_state(struct hdmi_ip_data *ip_data)
{
unsigned long flags;
@@ -241,10 +265,19 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data
*ip_data)
return 0;
}
- if (hpd)
+ if (hpd) {
+ /* before putting the phy in TX_ON,ensure that TMDS lanes
+* are pulled up .
+*/
+ r = hdmi_ti_4xxx_rxdet(ip_data);
+ if (r = 0) {
+ DSSERR(rxdet not set\n);
+ return r;
+ }
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
- else
+ } else {
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_LDOON);
+ }
if (r) {
DSSERR(Failed to %s PHY TX power\n,
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index a14d1a0..efa6f29 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -47,6 +47,8 @@
#define HDMI_WP_AUDIO_CFG2 0x84
#define HDMI_WP_AUDIO_CTRL 0x88
#define HDMI_WP_AUDIO_DATA 0x8C
+#define HDMI_WP_WP_DEBUG_CFG 0x90
+#define HDMI_WP_WP_DEBUG_DATA 0x94
/* HDMI IP Core System */
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/1] mmc: start removing enable / disable API
On 01/03/12 10:08, Subhash Jadavani wrote:
On 2/29/2012 12:47 PM, Adrian Hunter wrote:
Most parts of the enable / disable API are no longer used and
can be removed.
Cc: Rajendra Nayakrna...@ti.com
Cc: Venkatraman Ssvenk...@ti.com
Cc: Kukjin Kimkgene@samsung.com
Cc: Thomas Abrahamthomas.abra...@linaro.org
Cc: Kyungmin Parkkyungmin.p...@samsung.com
Cc: Sekhar Norinsek...@ti.com
Cc: Kevin Hilmankhil...@ti.com
Signed-off-by: Adrian Hunteradrian.hun...@intel.com
---
arch/arm/mach-exynos/mach-nuri.c |5 +-
arch/arm/mach-exynos/mach-universal_c210.c |9 +-
drivers/mmc/core/core.c| 187
+++-
drivers/mmc/core/host.c|1 -
drivers/mmc/core/host.h|1 -
drivers/mmc/host/davinci_mmc.c |4 -
drivers/mmc/host/omap_hsmmc.c | 15 +--
include/linux/mmc/core.h |1 -
include/linux/mmc/host.h | 46 +--
9 files changed, 27 insertions(+), 242 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-nuri.c
b/arch/arm/mach-exynos/mach-nuri.c
index 644af11..de68248 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -109,7 +109,7 @@ static struct s3c_sdhci_platdata nuri_hsmmc0_data
__initdata = {
.max_width= 8,
.host_caps= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA |
MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
-MMC_CAP_DISABLE | MMC_CAP_ERASE),
+MMC_CAP_ERASE),
.cd_type= S3C_SDHCI_CD_PERMANENT,
};
@@ -147,8 +147,7 @@ static struct platform_device emmc_fixed_voltage = {
static struct s3c_sdhci_platdata nuri_hsmmc2_data __initdata = {
.max_width= 4,
.host_caps= MMC_CAP_4_BIT_DATA |
-MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
-MMC_CAP_DISABLE,
+MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
.ext_cd_gpio= EXYNOS4_GPX3(3),/* XEINT_27 */
.ext_cd_gpio_invert= 1,
.cd_type= S3C_SDHCI_CD_GPIO,
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
b/arch/arm/mach-exynos/mach-universal_c210.c
index 9b3fbae..57cfe61 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -734,8 +734,7 @@ static struct platform_device universal_gpio_keys = {
static struct s3c_sdhci_platdata universal_hsmmc0_data __initdata = {
.max_width= 8,
.host_caps= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA |
-MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
-MMC_CAP_DISABLE),
+MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED),
.cd_type= S3C_SDHCI_CD_PERMANENT,
};
@@ -772,8 +771,7 @@ static struct platform_device mmc0_fixed_voltage = {
static struct s3c_sdhci_platdata universal_hsmmc2_data __initdata = {
.max_width= 4,
.host_caps= MMC_CAP_4_BIT_DATA |
-MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
-MMC_CAP_DISABLE,
+MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
.ext_cd_gpio= EXYNOS4_GPX3(4), /* XEINT_28 */
.ext_cd_gpio_invert= 1,
.cd_type= S3C_SDHCI_CD_GPIO,
@@ -783,8 +781,7 @@ static struct s3c_sdhci_platdata universal_hsmmc2_data
__initdata = {
static struct s3c_sdhci_platdata universal_hsmmc3_data __initdata = {
.max_width= 4,
.host_caps= MMC_CAP_4_BIT_DATA |
-MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
-MMC_CAP_DISABLE,
+MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
.cd_type= S3C_SDHCI_CD_EXTERNAL,
};
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 0b317f0..44dd013 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -605,105 +605,6 @@ unsigned int mmc_align_data_size(struct mmc_card
*card, unsigned int sz)
EXPORT_SYMBOL(mmc_align_data_size);
/**
- *mmc_host_enable - enable a host.
- *@host: mmc host to enable
- *
- *Hosts that support power saving can use the 'enable' and 'disable'
- *methods to exit and enter power saving states. For more information
- *see comments for struct mmc_host_ops.
- */
-int mmc_host_enable(struct mmc_host *host)
-{
-if (!(host-caps MMC_CAP_DISABLE))
-return 0;
-
-if (host-en_dis_recurs)
-return 0;
-
-if (host-nesting_cnt++)
-return 0;
-
-cancel_delayed_work_sync(host-disable);
-
-if (host-enabled)
-return 0;
-
-if (host-ops-enable) {
-int err;
-
-host-en_dis_recurs = 1;
-mmc_host_clk_hold(host);
-err = host-ops-enable(host);
-mmc_host_clk_release(host);
-
Re: [PATCHv3 4/4] ARM: OMAP3+: add prcm chain interrupts to the interrupt list
On Thu, 2012-03-01 at 12:31 +0530, Rajendra Nayak wrote:
On Wednesday 29 February 2012 08:55 PM, Tero Kristo wrote:
Currently PRCM chain handler for OMAP4 requires SPARSE_IRQ to be enabled
from kernel config, however enabling this option breaks the OMAP kernel
completely and it can't be used. Thus, OMAP_PRCM_IRQ_BASE was added
to the end of the irq list, and the prm_common code was changed to use
this instead of irq_desc allocation scheme.
Once SPARSE_IRQ is enabled for OMAP kernel, this patch can be reverted.
Do you still need this, despite this fix from Benoit?
http://marc.info/?l=linux-arm-kernelm=133043468329275w=2
Not sure, I haven't tested that yet.
-Tero
Signed-off-by: Tero Kristot-kri...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
---
arch/arm/mach-omap2/prm_common.c | 14 +-
arch/arm/plat-omap/include/plat/irqs.h |6 +-
2 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/prm_common.c
b/arch/arm/mach-omap2/prm_common.c
index 860118a..9ca829f 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -196,11 +196,6 @@ void omap_prcm_irq_cleanup(void)
prcm_irq_setup-priority_mask = NULL;
irq_set_chained_handler(prcm_irq_setup-irq, NULL);
-
- if (prcm_irq_setup-base_irq 0)
- irq_free_descs(prcm_irq_setup-base_irq,
- prcm_irq_setup-nr_regs * 32);
- prcm_irq_setup-base_irq = 0;
}
void omap_prcm_irq_prepare(void)
@@ -282,14 +277,7 @@ int omap_prcm_register_chain_handler(struct
omap_prcm_irq_setup *irq_setup)
irq_set_chained_handler(irq_setup-irq, omap_prcm_irq_handler);
- irq_setup-base_irq = irq_alloc_descs(-1, 0, irq_setup-nr_regs * 32,
- 0);
-
- if (irq_setup-base_irq 0) {
- pr_err(PRCM: failed to allocate irq descs: %d\n,
- irq_setup-base_irq);
- goto err;
- }
+ irq_setup-base_irq = OMAP_PRCM_IRQ_BASE;
for (i = 0; i= irq_setup-nr_regs; i++) {
gc = irq_alloc_generic_chip(PRCM, 1,
diff --git a/arch/arm/plat-omap/include/plat/irqs.h
b/arch/arm/plat-omap/include/plat/irqs.h
index 2efd645..fe1be1d 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -428,8 +428,12 @@
#define OMAP_GPMC_NR_IRQS 8
#define OMAP_GPMC_IRQ_END (OMAP_GPMC_IRQ_BASE + OMAP_GPMC_NR_IRQS)
+/* PRCM chain handler */
+#define OMAP_PRCM_IRQ_BASE (OMAP_GPMC_IRQ_END)
+#define OMAP_PRCM_NR_IRQS 64
+#define OMAP_PRCM_IRQ_END (OMAP_PRCM_IRQ_BASE + OMAP_PRCM_NR_IRQS)
-#define NR_IRQSOMAP_GPMC_IRQ_END
+#define NR_IRQSOMAP_PRCM_IRQ_END
#define OMAP_IRQ_BIT(irq) (1 ((irq) % 32))
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 4/6] ARM: OMAP3 PM: Enable IO Wake up
On Thu, 2012-03-01 at 12:22 +0530, Rajendra Nayak wrote:
On Wednesday 29 February 2012 07:56 PM, Tero Kristo wrote:
From: Vishwanath BSvishwanath...@ti.com
Enable IO Wake up for OMAP3 as part of PM Init. Currently this has been
managed in cpuidle path which is not the right place. Subsequent patch
will remove IO Daisy chain handling in cpuidle path once daisy chain is
handled as part of hwmod mux.
Signed-off-by: Vishwanath BSvishwanath...@ti.com
Tested-by: Govindraj.Rgovindraj.r...@ti.com
Signed-off-by: Tero Kristot-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e97ec3f..e6c2d39 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -793,6 +793,10 @@ static int __init omap3_pm_init(void)
goto err1;
}
+ if (omap3_has_io_wakeup())
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
+ PM_WKEN);
On OMAP4 this GLOBAL IO chain enable happens as part of the trigger
function itself, it might make sense to do that for OMAP3 too to avoid
similar issues as seen on OMAP4 when the GLOBAL switch is enabled too
late in boot. The best however would be to get rid of it in the trigger
function and enable this early during PM init, but I am not sure whats
a good place to do this 'early' enough.
Sounds good. This will take care of the comment from Paul also.
-Tero
regards,
Rajendra
+
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
printk(KERN_ERR Failed to setup powerdomains\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: [PATCHv3 2/6] ARM: OMAP3 PM: Move IO Daisychain function to omap3 prm file
On Thu, 2012-03-01 at 12:19 +0530, Rajendra Nayak wrote:
On Wednesday 29 February 2012 07:56 PM, Tero Kristo wrote:
From: Vishwanath BSvishwanath...@ti.com
Since IO Daisychain modifies only PRM registers, it makes sense to move
it to PRM File.
Signed-off-by: Vishwanath BSvishwanath...@ti.com
Tested-by: Govindraj.Rgovindraj.r...@ti.com
Signed-off-by: Tero Kristot-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 30 +-
arch/arm/mach-omap2/prm2xxx_3xxx.c | 32
arch/arm/mach-omap2/prm2xxx_3xxx.h | 14 ++
3 files changed, 47 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index b0821a8..e97ec3f 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -85,34 +85,6 @@ static inline void omap3_per_restore_context(void)
omap_gpio_restore_context();
}
-static void omap3_enable_io_chain(void)
-{
- int timeout = 0;
-
- omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
- /* Do a readback to assure write has been done */
- omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
-
- while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
-OMAP3430_ST_IO_CHAIN_MASK)) {
- timeout++;
- if (timeout 1000) {
- pr_err(Wake up daisy chain activation failed.\n);
- return;
- }
- }
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
-
-}
-
-static void omap3_disable_io_chain(void)
-{
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
-PM_WKEN);
-}
-
static void omap3_core_save_context(void)
{
omap3_ctrl_save_padconf();
@@ -324,7 +296,7 @@ void omap_sram_idle(void)
core_next_state PWRDM_POWER_ON)) {
omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
PM_WKEN);
if (omap3_has_io_chain_ctrl())
- omap3_enable_io_chain();
+ omap3_trigger_io_chain();
}
pwrdm_pre_transition();
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 9ce7654..fc98781 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -301,6 +301,38 @@ void omap3xxx_prm_restore_irqen(u32 *saved_mask)
OMAP3_PRM_IRQENABLE_MPU_OFFSET);
}
+/**
+ * Maximum time(us) it takes to output the signal WUCLKOUT of the last pad
of
+ * the I/O ring after asserting WUCLKIN high
+ */
+#define MAX_IOPAD_LATCH_TIME 1000
Since we are changing the implementation to use omap_test_timeout()
in this patch, it makes sense to make this 100 so we have a max 100us
delay, similar to what we did on OMAP4.
I didn't change this timeout as I wasn't quite sure what is a safe value
for it. Do you know if 100us is safe for omap3 also in all possible
scenarios?
+
+/* OMAP3 Daisychain enable sequence */
+void omap3_trigger_io_chain(void)
+{
+ int i = 0;
+
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKEN);
+ /* Do a readback to assure write has been done */
+ omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
+
+ omap_test_timeout(((omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
+ OMAP3430_ST_IO_CHAIN_MASK) == 1),
+ MAX_IOPAD_LATCH_TIME, i);
+
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+PM_WKEN);
The comment from Djamil should hold good here too. We should wait for
IO chain status to show 0 here.
Hmm okay, I'll address this also for next version.
-Tero
+}
+
regards,
Rajendra
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 2/6] ARM: OMAP3 PM: Move IO Daisychain function to omap3 prm file
On Thursday 01 March 2012 01:58 PM, Tero Kristo wrote:
On Thu, 2012-03-01 at 12:19 +0530, Rajendra Nayak wrote:
On Wednesday 29 February 2012 07:56 PM, Tero Kristo wrote:
From: Vishwanath BSvishwanath...@ti.com
Since IO Daisychain modifies only PRM registers, it makes sense to move
it to PRM File.
Signed-off-by: Vishwanath BSvishwanath...@ti.com
Tested-by: Govindraj.Rgovindraj.r...@ti.com
Signed-off-by: Tero Kristot-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 30 +-
arch/arm/mach-omap2/prm2xxx_3xxx.c | 32
arch/arm/mach-omap2/prm2xxx_3xxx.h | 14 ++
3 files changed, 47 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index b0821a8..e97ec3f 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -85,34 +85,6 @@ static inline void omap3_per_restore_context(void)
omap_gpio_restore_context();
}
-static void omap3_enable_io_chain(void)
-{
- int timeout = 0;
-
- omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
- /* Do a readback to assure write has been done */
- omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
-
- while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
-OMAP3430_ST_IO_CHAIN_MASK)) {
- timeout++;
- if (timeout 1000) {
- pr_err(Wake up daisy chain activation failed.\n);
- return;
- }
- }
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
-
-}
-
-static void omap3_disable_io_chain(void)
-{
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
-PM_WKEN);
-}
-
static void omap3_core_save_context(void)
{
omap3_ctrl_save_padconf();
@@ -324,7 +296,7 @@ void omap_sram_idle(void)
core_next_state PWRDM_POWER_ON)) {
omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
PM_WKEN);
if (omap3_has_io_chain_ctrl())
- omap3_enable_io_chain();
+ omap3_trigger_io_chain();
}
pwrdm_pre_transition();
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 9ce7654..fc98781 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -301,6 +301,38 @@ void omap3xxx_prm_restore_irqen(u32 *saved_mask)
OMAP3_PRM_IRQENABLE_MPU_OFFSET);
}
+/**
+ * Maximum time(us) it takes to output the signal WUCLKOUT of the last pad of
+ * the I/O ring after asserting WUCLKIN high
+ */
+#define MAX_IOPAD_LATCH_TIME 1000
Since we are changing the implementation to use omap_test_timeout()
in this patch, it makes sense to make this 100 so we have a max 100us
delay, similar to what we did on OMAP4.
I didn't change this timeout as I wasn't quite sure what is a safe value
for it. Do you know if 100us is safe for omap3 also in all possible
scenarios?
The IO daisy implementation is essentially the same on OMAP3 and OMAP4.
I looped in Nilesh again who can shout if it isn't.
Besides the previous implementation was just a loop of 1000 (not using
omap_test_timeout() which internally does udelay(1)) and that should be
always less than 100us even with MPU at the lowest OPP on OMAP3.
+
+/* OMAP3 Daisychain enable sequence */
+void omap3_trigger_io_chain(void)
+{
+ int i = 0;
+
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKEN);
+ /* Do a readback to assure write has been done */
+ omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
+
+ omap_test_timeout(((omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
+ OMAP3430_ST_IO_CHAIN_MASK) == 1),
+ MAX_IOPAD_LATCH_TIME, i);
+
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+PM_WKEN);
The comment from Djamil should hold good here too. We should wait for
IO chain status to show 0 here.
Hmm okay, I'll address this also for next version.
-Tero
+}
+
regards,
Rajendra
--
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: Randconfig module build error with OMAP4_ERRATA_I688
On Wed, Feb 29, 2012 at 11:07 PM, Tony Lindgren t...@atomide.com wrote: Hi Santosh, Looks like OMAP4_ERRATA_I688 still has one more issue: Modules won't build at least with the attached randconfig generated file. Can you please take a look at how to deal with it? Maybe omap_bus_sync should be an inline function with some wrapper for the sleep44xx.S to call? I already posted a fix for the GPMC related error with the same .config file. This one builds for me against 'Linux 3.3-rc5, Ofocurse I got below error with the attached .config which I bypassed to see the Errata build failure. arch/arm/mach-omap2/built-in.o: In function `n8x0_mmc_callback': linux-2.6/arch/arm/mach-omap2/board-n8x0.c:374: undefined reference to `omap_mmc_notify_cover_event' make: *** [.tmp_vmlinux1] Error 1 I build this with below toolchain... $arm-none-linux-gnueabi-gcc --version arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2011.03-41) 4.5.2 Copyright (C) 2010 Free Software Foundation, Inc. Am I missing anything ? 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
[PATCH v3 1/2] ARM: OMAP: move generic EMAC init to separate file
From: Ilya Yanok ya...@emcraft.com
AM35xx SoCs include DaVinci EMAC IP. Initialization code in
board-am3517evm.c is pretty board independent and will work for any
AM35xx based board so move this code to it's own file to be reused by
other boards.
Signed-off-by: Ilya Yanok ya...@emcraft.com
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
v3: - use DEFINE_RES_* macros
- check error of platform_device_register()
- introduce a default MDIO bus frequency define
Tony, this patch has been floating for about two months:
http://www.spinics.net/lists/linux-omap/msg62160.html
can it be applied for 3.4?
Thanks
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/am35xx-emac.c | 117 +
arch/arm/mach-omap2/am35xx-emac.h | 15
arch/arm/mach-omap2/board-am3517evm.c | 117 +
4 files changed, 137 insertions(+), 115 deletions(-)
create mode 100644 arch/arm/mach-omap2/am35xx-emac.c
create mode 100644 arch/arm/mach-omap2/am35xx-emac.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 56a6e98..64f79da 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -267,4 +267,7 @@ smsc911x-$(CONFIG_SMSC911X) := gpmc-smsc911x.o
obj-y += $(smsc911x-m) $(smsc911x-y)
obj-$(CONFIG_ARCH_OMAP4) += hwspinlock.o
+emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
+obj-y += $(emac-m) $(emac-y)
+
obj-y += common-board-devices.o twl-common.o
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
new file mode 100644
index 000..1f97e74
--- /dev/null
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -0,0 +1,117 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, Emcraft Systems
+ *
+ * Based on mach-omap2/board-am3517evm.c
+ * Copyright (C) 2009 Texas Instruments Incorporated
+ * Author: Ranjith Lohithakshan ranji...@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
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/davinci_emac.h
+#include linux/platform_device.h
+#include plat/irqs.h
+#include mach/am35xx.h
+
+#include control.h
+
+static struct mdio_platform_data am35xx_emac_mdio_pdata;
+
+static struct resource am35xx_emac_mdio_resources[] = {
+ DEFINE_RES_MEM(AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET, SZ_4K),
+};
+
+static struct platform_device am35xx_emac_mdio_device = {
+ .name = davinci_mdio,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(am35xx_emac_mdio_resources),
+ .resource = am35xx_emac_mdio_resources,
+ .dev.platform_data = am35xx_emac_mdio_pdata,
+};
+
+static void am35xx_enable_emac_int(void)
+{
+ u32 regval;
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR |
+ AM35XX_CPGMAC_C0_TX_PULSE_CLR |
+ AM35XX_CPGMAC_C0_MISC_PULSE_CLR |
+ AM35XX_CPGMAC_C0_RX_THRESH_CLR);
+ omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static void am35xx_disable_emac_int(void)
+{
+ u32 regval;
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR |
+ AM35XX_CPGMAC_C0_TX_PULSE_CLR);
+ omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static struct emac_platform_data am35xx_emac_pdata = {
+ .ctrl_reg_offset= AM35XX_EMAC_CNTRL_OFFSET,
+ .ctrl_mod_reg_offset= AM35XX_EMAC_CNTRL_MOD_OFFSET,
+ .ctrl_ram_offset= AM35XX_EMAC_CNTRL_RAM_OFFSET,
+ .ctrl_ram_size = AM35XX_EMAC_CNTRL_RAM_SIZE,
+ .hw_ram_addr= AM35XX_EMAC_HW_RAM_ADDR,
+ .version= EMAC_VERSION_2,
+ .interrupt_enable = am35xx_enable_emac_int,
+ .interrupt_disable = am35xx_disable_emac_int,
+};
+
+static struct resource am35xx_emac_resources[] = {
+ DEFINE_RES_MEM(AM35XX_IPSS_EMAC_BASE, 0x3),
+ DEFINE_RES_IRQ(INT_35XX_EMAC_C0_RXTHRESH_IRQ),
+ DEFINE_RES_IRQ(INT_35XX_EMAC_C0_RX_PULSE_IRQ),
+ DEFINE_RES_IRQ(INT_35XX_EMAC_C0_TX_PULSE_IRQ),
+ DEFINE_RES_IRQ(INT_35XX_EMAC_C0_MISC_PULSE_IRQ),
+};
+
+static struct platform_device am35xx_emac_device = {
+ .name = davinci_emac,
+
[PATCH 2/2] ARM: OMAP3: cm-t3517: add EMAC support
Add support for the EMAC Ethernet controller in the AM35xx SoC.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t3517.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index f36d694..9e66e16 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -49,6 +49,7 @@
#include mux.h
#include control.h
#include common-board-devices.h
+#include am35xx-emac.h
#if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
static struct gpio_led cm_t3517_leds[] = {
@@ -291,6 +292,7 @@ static void __init cm_t3517_init(void)
cm_t3517_init_rtc();
cm_t3517_init_usbh();
cm_t3517_init_hecc();
+ am35xx_emac_init(AM35XX_DEFAULT_MDIO_FREQUENCY, 1);
}
MACHINE_START(CM_T3517, Compulab CM-T3517)
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 4/4] ARM: OMAP3+: add prcm chain interrupts to the interrupt list
On Wed, Feb 29, 2012 at 05:25:06PM +0200, Tero Kristo wrote: Currently PRCM chain handler for OMAP4 requires SPARSE_IRQ to be enabled from kernel config, however enabling this option breaks the OMAP kernel completely and it can't be used. No it does not. Look: irq_alloc_descs(start, from, num, -1) will allocate num interrupt descriptors from within from..NR_IRQS if sparse IRQ is disabled. So, provided there is sufficient space within the available NR_IRQS, irq_alloc_descs() works for non-sparse IRQ. There is no need to get rid of it at all. If start is -1, then it will allocate from where-ever it can in the range from..NR_IRQS. Otherwise, it will fail if it can't get an allocation starting at 'start'. If sparse IRQ is enabled, then it will start allocating from whatever the last figure output from the: NR_IRQS:%d nr_irqs:%d %d line. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 4/4] ARM: OMAP3+: add prcm chain interrupts to the interrupt list
On Thu, 2012-03-01 at 09:46 +, Russell King - ARM Linux wrote: On Wed, Feb 29, 2012 at 05:25:06PM +0200, Tero Kristo wrote: Currently PRCM chain handler for OMAP4 requires SPARSE_IRQ to be enabled from kernel config, however enabling this option breaks the OMAP kernel completely and it can't be used. No it does not. Look: irq_alloc_descs(start, from, num, -1) will allocate num interrupt descriptors from within from..NR_IRQS if sparse IRQ is disabled. So, provided there is sufficient space within the available NR_IRQS, irq_alloc_descs() works for non-sparse IRQ. There is no need to get rid of it at all. If start is -1, then it will allocate from where-ever it can in the range from..NR_IRQS. Otherwise, it will fail if it can't get an allocation starting at 'start'. If sparse IRQ is enabled, then it will start allocating from whatever the last figure output from the: NR_IRQS:%d nr_irqs:%d %d line. With the patch from Benoit (http://marc.info/?l=linux-arm-kernelm=133043468329275w=2) this patch is no longer needed. Previously the NR_IRQS definition was too small for omap4 and the alloc_descs was failing because of that. It seems I overshoot with this patch of mine and dropped also the irq_alloc_desc implementation while fixing the problem. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/1] mmc: start removing enable / disable API
On 3/1/2012 1:51 PM, Adrian Hunter wrote:
On 01/03/12 10:08, Subhash Jadavani wrote:
On 2/29/2012 12:47 PM, Adrian Hunter wrote:
Most parts of the enable / disable API are no longer used and
can be removed.
Cc: Rajendra Nayakrna...@ti.com
Cc: Venkatraman Ssvenk...@ti.com
Cc: Kukjin Kimkgene@samsung.com
Cc: Thomas Abrahamthomas.abra...@linaro.org
Cc: Kyungmin Parkkyungmin.p...@samsung.com
Cc: Sekhar Norinsek...@ti.com
Cc: Kevin Hilmankhil...@ti.com
Signed-off-by: Adrian Hunteradrian.hun...@intel.com
---
arch/arm/mach-exynos/mach-nuri.c |5 +-
arch/arm/mach-exynos/mach-universal_c210.c |9 +-
drivers/mmc/core/core.c| 187
+++-
drivers/mmc/core/host.c|1 -
drivers/mmc/core/host.h|1 -
drivers/mmc/host/davinci_mmc.c |4 -
drivers/mmc/host/omap_hsmmc.c | 15 +--
include/linux/mmc/core.h |1 -
include/linux/mmc/host.h | 46 +--
9 files changed, 27 insertions(+), 242 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-nuri.c
b/arch/arm/mach-exynos/mach-nuri.c
index 644af11..de68248 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -109,7 +109,7 @@ static struct s3c_sdhci_platdata nuri_hsmmc0_data
__initdata = {
.max_width= 8,
.host_caps= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA |
MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
-MMC_CAP_DISABLE | MMC_CAP_ERASE),
+MMC_CAP_ERASE),
.cd_type= S3C_SDHCI_CD_PERMANENT,
};
@@ -147,8 +147,7 @@ static struct platform_device emmc_fixed_voltage = {
static struct s3c_sdhci_platdata nuri_hsmmc2_data __initdata = {
.max_width= 4,
.host_caps= MMC_CAP_4_BIT_DATA |
-MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
-MMC_CAP_DISABLE,
+MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
.ext_cd_gpio= EXYNOS4_GPX3(3),/* XEINT_27 */
.ext_cd_gpio_invert= 1,
.cd_type= S3C_SDHCI_CD_GPIO,
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
b/arch/arm/mach-exynos/mach-universal_c210.c
index 9b3fbae..57cfe61 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -734,8 +734,7 @@ static struct platform_device universal_gpio_keys = {
static struct s3c_sdhci_platdata universal_hsmmc0_data __initdata = {
.max_width= 8,
.host_caps= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA |
-MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
-MMC_CAP_DISABLE),
+MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED),
.cd_type= S3C_SDHCI_CD_PERMANENT,
};
@@ -772,8 +771,7 @@ static struct platform_device mmc0_fixed_voltage = {
static struct s3c_sdhci_platdata universal_hsmmc2_data __initdata = {
.max_width= 4,
.host_caps= MMC_CAP_4_BIT_DATA |
-MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
-MMC_CAP_DISABLE,
+MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
.ext_cd_gpio= EXYNOS4_GPX3(4), /* XEINT_28 */
.ext_cd_gpio_invert= 1,
.cd_type= S3C_SDHCI_CD_GPIO,
@@ -783,8 +781,7 @@ static struct s3c_sdhci_platdata universal_hsmmc2_data
__initdata = {
static struct s3c_sdhci_platdata universal_hsmmc3_data __initdata = {
.max_width= 4,
.host_caps= MMC_CAP_4_BIT_DATA |
-MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
-MMC_CAP_DISABLE,
+MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
.cd_type= S3C_SDHCI_CD_EXTERNAL,
};
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 0b317f0..44dd013 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -605,105 +605,6 @@ unsigned int mmc_align_data_size(struct mmc_card
*card, unsigned int sz)
EXPORT_SYMBOL(mmc_align_data_size);
/**
- *mmc_host_enable - enable a host.
- *@host: mmc host to enable
- *
- *Hosts that support power saving can use the 'enable' and 'disable'
- *methods to exit and enter power saving states. For more information
- *see comments for struct mmc_host_ops.
- */
-int mmc_host_enable(struct mmc_host *host)
-{
-if (!(host-caps MMC_CAP_DISABLE))
-return 0;
-
-if (host-en_dis_recurs)
-return 0;
-
-if (host-nesting_cnt++)
-return 0;
-
-cancel_delayed_work_sync(host-disable);
-
-if (host-enabled)
-return 0;
-
-if (host-ops-enable) {
-int err;
-
-host-en_dis_recurs = 1;
-mmc_host_clk_hold(host);
-err = host-ops-enable(host);
-mmc_host_clk_release(host);
-host-en_dis_recurs = 0;
-
-if
RE: [PATCH-V2 2/2] arm:omap:am33xx: Add power domain data
On Thu, Mar 01, 2012 at 07:07:01, Paul Walmsley wrote:
Hi
a question -
On Sun, 25 Dec 2011, Vaibhav Hiremath wrote:
+static struct powerdomain mpu_33xx_pwrdm = {
+ .name = mpu_pwrdm,
+ .voltdm = { .name = mpu },
+ .prcm_partition = AM33XX_PRM_PARTITION,
+ .prcm_offs = AM33XX_PRM_MPU_MOD,
+ .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts_logic_ret = PWRSTS_OFF_RET,
+ .pwrstctrl_offs = AM33XX_PM_MPU_PWRSTCTRL_OFFSET,
+ .pwrstst_offs = AM33XX_PM_MPU_PWRSTST_OFFSET,
+ .flags = PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .banks = 3,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_OFF_RET, /* mpu_l1 */
+ [1] = PWRSTS_OFF_RET, /* mpu_l2 */
+ [2] = PWRSTS_OFF_RET, /* mpu_ram */
+ },
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_ON,/* mpu_l1 */
+ [1] = PWRSTS_ON,/* mpu_l2 */
+ [2] = PWRSTS_ON,/* mpu_ram */
+ },
+};
Comparing this with Table 8-191 PM_MPU_PWRSTCTRL Register Field
Descriptions of the AM335x TRM Rev C [SPRUH73C], it seems that something
is really wrong here.
On the OMAP4430's *_PWRSTCTRL registers,
- the memory bank RETSTATE fields always start at bit 8;
- the RETSTATE fields are contiguous;
- the bank ONSTATE fields always start at bit 16; and
- the ONSTATE fields are contiguous;
- the order of the RETSTATE and ONSTATE fields always matches.
The OMAP4430 TRM Rev O [SWPU231O] Table 3-449 PM_CORE_PWRSTCTRL table
is a good illustration of this.
But, looking at SPRUH73C, none of these criteria seem to apply
consistently on AM335x :-(
Table 8-191 PM_MPU_PWRSTCTRL Register Field Descriptions starts its
RETSTATE bitfields at bit 22, not bit 8. The ONSTATE bitfields are at bit
16 (at least this part is normal). And both sets of bitfields are
internally contiguous. But then the order of the bitfields does not match
between the RETSTATE bitfields and ONSTATE bitfields - the RETSTATE order
is (L1, L2, RAM), but the ONSTATE order is (RAM, L1, L2)!
Then looking at Table 8-184 PM_PER_PWRSTCTRL Register Field Descriptions
for the same chip, the layout is completely different. The PRUSS memory
ONSTATE starts at bit 5, and its RETSTATE field is at bit 7. But then
PER_MEM's ONSTATE field starts at bit 25, and is followed immediately by
*RAM*_MEM's RETSTATE field at bit 27! And then PER_MEM's RETSTATE field
shows up at bit 29, followed by RAM_MEM's ONSTATE field at bit 30.
Is the TRM accurate in these examples? Or is this a documentation bug?
Unfortunately, the spec is correct in this context.
Anyway, if this is really accurate, this per-powerdomain bitfield
reordering is definitely not expected by the existing powerdomain code.
Looks to me that someone will have to add bitshift fields into the struct
powerdomain for every single bank RETSTATE and ONSTATE field.
That would be me... :)
I have started looking at it and will soon submit the patches for this.
Side note,
I am not sure whether we access these bits explicitly. If I understand
correctly, API's which access these bits are not being called from anywhere,
For example,
omap4_pwrdm_read_mem_retst
omap4_pwrdm_set_mem_retst
omap4_pwrdm_set_mem_onst
Currently the major issue would be, for PM_PER_PWRSTCTRL, where
LogicRETState bit has been moved to offset 3. This is being used in
omap4_pwrdm_set_logic_retst() api.
And in order to support weird/non-standard bit-offsets, we have to clean
omap2_pwrdm_get_mem_bank_onstate/retst/_mask() api and have bitshift field in
struct powerdomain, as you have rightly pointed out.
Is my all understanding correct?
If yes, do you think this patch should get blocked for above cleanup? I feel
Cleanup can still follow, since this won't impact the AM33xx boot.
What's your opinion on this??
Does this match your understanding?
Yes, certainly.
Thanks,
Vaibhav
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V2 2/2] arm:omap:am33xx: Add power domain data
On Thu, Mar 01, 2012 at 07:14:24, Paul Walmsley wrote:
Hi
some other observations:
On Sun, 25 Dec 2011, Vaibhav Hiremath wrote:
+static struct powerdomain per_33xx_pwrdm = {
+ .name = per_pwrdm,
+ .voltdm = { .name = core },
+ .prcm_partition = AM33XX_PRM_PARTITION,
+ .prcm_offs = AM33XX_PRM_PER_MOD,
+ .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts_logic_ret = PWRSTS_OFF_RET,
+ .pwrstctrl_offs = AM33XX_PM_PER_PWRSTCTRL_OFFSET,
+ .pwrstst_offs = AM33XX_PM_PER_PWRSTST_OFFSET,
+ .flags = PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .banks = 3,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_OFF_RET, /* icss_mem */
+ [1] = PWRSTS_OFF_RET, /* per_mem */
+ [2] = PWRSTS_OFF_RET, /* ram_mem */
+ },
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_ON,/* icss_mem */
+ [1] = PWRSTS_ON,/* per_mem */
+ [2] = PWRSTS_ON,/* ram_mem */
+ },
+};
According to SPRUH73C Table 8-184 PM_PER_PWRSTCTRL Register Field
Descriptions the pwrsts_mem_on field for RAM_MEM should be
PWRSTS_OFF_RET_ON.
+static struct powerdomain mpu_33xx_pwrdm = {
+ .name = mpu_pwrdm,
+ .voltdm = { .name = mpu },
+ .prcm_partition = AM33XX_PRM_PARTITION,
+ .prcm_offs = AM33XX_PRM_MPU_MOD,
+ .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts_logic_ret = PWRSTS_OFF_RET,
+ .pwrstctrl_offs = AM33XX_PM_MPU_PWRSTCTRL_OFFSET,
+ .pwrstst_offs = AM33XX_PM_MPU_PWRSTST_OFFSET,
+ .flags = PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .banks = 3,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_OFF_RET, /* mpu_l1 */
+ [1] = PWRSTS_OFF_RET, /* mpu_l2 */
+ [2] = PWRSTS_OFF_RET, /* mpu_ram */
+ },
Again SPRUH73C Table 8-191 PM_MPU_PWRSTCTRL Register Field Descriptions
claims these should simply by PWRSTS_RET.
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_ON,/* mpu_l1 */
+ [1] = PWRSTS_ON,/* mpu_l2 */
+ [2] = PWRSTS_ON,/* mpu_ram */
+ },
+};
And the same table claims the MPU_RAM pwrsts_mem_on field should be
PWRSTS_OFF_ON.
Can you please reconcile these differences and let us know which values
should be correct?
Paul,
The initialization used in the patch is correct. Unfortunately, the TRM is
incorrect here. I have already raised this issue with respective folks and soon
it will get corrected.
Thanks,
Vaibhav
thanks
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] musb runtime_pm fixes
On Sat, Feb 4, 2012 at 7:43 PM, Grazvydas Ignotas nota...@gmail.com wrote: These patches try address isp1704_charger crash in a different way than 772aed45b604, which broke runtime_pm for me. Felipe Contreras, oculd you test isp1704_charger with these? Ping. These still apply cleanly and are needed to solve musb runtime PM issues on OMAP3. I've also done a random ULPI transfer while musb was suspended and it worked. Grazvydas Ignotas (2): usb: musb: fix some runtime_pm issues usb: musb: wake the device before ulpi transfers drivers/usb/musb/musb_core.c | 40 +--- drivers/usb/musb/omap2430.c | 2 +- include/linux/usb/otg.h | 1 + 3 files changed, 35 insertions(+), 8 deletions(-) -- Gražvydas -- 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: HDMI: wait for RXDET before putting phy in TX_ON
Hi,
On Thu, 2012-03-01 at 13:44 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
Currently TX_PHY is put to TX_ON(transmission state) on receiving HPD.
It just ensures that the TV is connected but does not guarantee
that TMDS data lines and clock lines are up and ready for transmission.
Which although is very rare scenario has a potential to damage the HDMI
port.(A use case where TV is connected to board but it is in different
channel would still trigger a HPD but TMDS lines will be down).
When/how does the damaging happen? When the HDMI cable is disconnected
in the case above? Or does the damage just happen by having the cable
connected, but the TV on different channel?
Thus this patch adds a rxdet check on getting a HPD which ensures that
TMDS lines are UP before changing the PHY state from LDO_ON to TX_ON.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 37 +++-
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |2 +
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index bb784d2..bc55528 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -224,6 +224,30 @@ void ti_hdmi_4xxx_pll_disable(struct hdmi_ip_data
*ip_data)
hdmi_set_pll_pwr(ip_data, HDMI_PLLPWRCMD_ALLOFF);
}
+int hdmi_ti_4xxx_rxdet(struct hdmi_ip_data *ip_data)
+{
+ int loop = 0, tmds_data0, tmds_data1, tmds_data2, tmds_clk;
+
+ hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_WP_DEBUG_CFG, 4);
+
+ do {
+ tmds_data0 = hdmi_read_reg(hdmi_wp_base(ip_data),
+ HDMI_WP_WP_DEBUG_DATA);
+ tmds_data1 = hdmi_read_reg(hdmi_wp_base(ip_data),
+ HDMI_WP_WP_DEBUG_DATA);
+ tmds_data2 = hdmi_read_reg(hdmi_wp_base(ip_data),
+ HDMI_WP_WP_DEBUG_DATA);
+ tmds_clk = hdmi_read_reg(hdmi_wp_base(ip_data),
+ HDMI_WP_WP_DEBUG_DATA);
+ udelay(15);
This code doesn't make any sense, or the HDMI TRM is wrong. You read the
same register, HDMI_WP_WP_DEBUG_DATA, four times, assigning the value to
data0-2/clk. The TRM I have doesn't talk about anything like that. What
is the code supposed to do?
The register HDMI_TXPHY_PAD_CONFIG_CONTROL also has bits for RXDET_LINE.
Is that something different?
+ } while ((tmds_data0 != tmds_data1 || tmds_data1 != tmds_data2
+ || tmds_data1 != tmds_clk) (loop 500));
This is a rather confusing way to do the loop. Why not just use for-loop
with the timeout, and check the tmds variables inside the loop. Much
easier to read.
In the worst case the above causes a 7.5ms busy loop in an interrupt
handler. That's not very good thing. Why is there a need for the loop?
+ hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_WP_DEBUG_CFG, 0);
+
+ return ((loop == 500) ? -1 : (tmds_data0 1)) ;
This is also confusing. And you should return a proper error value, not
-1. Perhaps:
if (loop == 500)
return -ETIMEDOUT;
return tmds_data0 1;
+}
+
static int hdmi_check_hpd_state(struct hdmi_ip_data *ip_data)
{
unsigned long flags;
@@ -241,10 +265,19 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data
*ip_data)
return 0;
}
- if (hpd)
+ if (hpd) {
+ /* before putting the phy in TX_ON,ensure that TMDS lanes
+ * are pulled up .
+ */
+ r = hdmi_ti_4xxx_rxdet(ip_data);
+ if (r = 0) {
+ DSSERR(rxdet not set\n);
+ return r;
+ }
Does this mean that if the user connects a TV which is in a different
channel than HDMI, the only way for the user to get an image is to
disconnect the cable and connect it again?
Tomi
signature.asc
Description: This is a digitally signed message part
[PATCH 0/7] OMAPDSS: HDMI PHY burnout fix for 3.2 stable
The main patch in this set is the PHY burnout fix, which implements a fix for a hardware bug in the OMAP4 HDMI PHY which may cause physical damage to the board if the HDMI PHY is already enabled when the HDMI cable is plugged in. The possible damage breaks HDMI output hardware, otherwise the board is unaffected. The preceding patches are small cleanups/fixes for HDMI GPIOs so that the fix can be implemented. And the fix introduced a small bug with hot plug detect, which is fixed by the patch from Rob. Rob's patch is not yet in upstream, but has been accepted by fbdev maintainer. Tomi Rob Clark (1): OMAPDSS: HDMI: hot plug detect fix Tomi Valkeinen (6): OMAP: 4430SDP/Panda: use gpio_free_array to free HDMI gpios OMAP: 4430SDP/Panda: rename HPD GPIO to CT_CP_HPD OMAPDSS: remove wrong HDMI HPD muxing OMAP: 4430SDP/Panda: setup HDMI GPIO muxes OMAP: 4430SDP/Panda: add HDMI HPD gpio OMAPDSS: HDMI: PHY burnout fix arch/arm/mach-omap2/board-4430sdp.c | 22 +--- arch/arm/mach-omap2/board-omap4panda.c| 22 +--- drivers/video/omap2/dss/hdmi.c|3 + drivers/video/omap2/dss/ti_hdmi.h |4 ++ drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 77 - include/video/omapdss.h |5 ++ 6 files changed, 105 insertions(+), 28 deletions(-) -- 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
[PATCH 2/7] OMAP: 4430SDP/Panda: rename HPD GPIO to CT_CP_HPD
The GPIO 60 on 4430sdp and Panda is not HPD GPIO, as currently marked in
the board files, but CT_CP_HPD, which is used to enable/disable HPD
functionality.
This patch renames the GPIO.
Backported from 3932a32fcf5393f8be70ac99dc718ad7ad0a415b
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c|4 ++--
arch/arm/mach-omap2/board-omap4panda.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 8434b0c..4333115 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -52,7 +52,7 @@
#define ETH_KS8851_QUART 138
#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
#define OMAP4_SFH7741_ENABLE_GPIO 188
-#define HDMI_GPIO_HPD 60 /* Hot plug pin for HDMI */
+#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */
#define DLP_POWER_ON_GPIO 40
@@ -610,7 +610,7 @@ static void sdp4430_hdmi_mux_init(void)
}
static struct gpio sdp4430_hdmi_gpios[] = {
- { HDMI_GPIO_HPD,GPIOF_OUT_INIT_HIGH,hdmi_gpio_hpd },
+ { HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ct_cp_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH,hdmi_gpio_ls_oe },
};
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 1ac7a22..d8e20f1 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -51,7 +51,7 @@
#define GPIO_HUB_NRESET62
#define GPIO_WIFI_PMENA43
#define GPIO_WIFI_IRQ 53
-#define HDMI_GPIO_HPD 60 /* Hot plug pin for HDMI */
+#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
/* wl127x BT, FM, GPS connectivity chip */
@@ -494,7 +494,7 @@ static void omap4_panda_hdmi_mux_init(void)
}
static struct gpio panda_hdmi_gpios[] = {
- { HDMI_GPIO_HPD,GPIOF_OUT_INIT_HIGH, hdmi_gpio_hpd },
+ { HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ct_cp_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ls_oe },
};
--
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
[PATCH 1/7] OMAP: 4430SDP/Panda: use gpio_free_array to free HDMI gpios
Instead of freeing the GPIOs individually, use gpio_free_array().
Backported from 575753e3bea3b67eef8e454fb87f719e3f7da599
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c|3 +--
arch/arm/mach-omap2/board-omap4panda.c |3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 5156468..8434b0c 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -628,8 +628,7 @@ static int sdp4430_panel_enable_hdmi(struct omap_dss_device
*dssdev)
static void sdp4430_panel_disable_hdmi(struct omap_dss_device *dssdev)
{
- gpio_free(HDMI_GPIO_LS_OE);
- gpio_free(HDMI_GPIO_HPD);
+ gpio_free_array(sdp4430_hdmi_gpios, ARRAY_SIZE(sdp4430_hdmi_gpios));
}
static struct nokia_dsi_panel_data dsi1_panel = {
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index a8c2c42..1ac7a22 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -512,8 +512,7 @@ static int omap4_panda_panel_enable_hdmi(struct
omap_dss_device *dssdev)
static void omap4_panda_panel_disable_hdmi(struct omap_dss_device *dssdev)
{
- gpio_free(HDMI_GPIO_LS_OE);
- gpio_free(HDMI_GPIO_HPD);
+ gpio_free_array(panda_hdmi_gpios, ARRAY_SIZE(panda_hdmi_gpios));
}
static struct omap_dss_device omap4_panda_hdmi_device = {
--
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
[PATCH 5/7] OMAP: 4430SDP/Panda: add HDMI HPD gpio
Both Panda and 4430SDP use GPIO 63 as HDMI hot-plug-detect. Configure
this GPIO in the board files.
Backported from aa74274b464d4aa24703963ac89a0ee942d5d267
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c|3 +++
arch/arm/mach-omap2/board-omap4panda.c |3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 7bcafb9..5c2aaa0 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -54,6 +54,7 @@
#define OMAP4_SFH7741_ENABLE_GPIO 188
#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
+#define HDMI_GPIO_HPD 63 /* Hotplug detect */
#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */
#define DLP_POWER_ON_GPIO 40
@@ -608,6 +609,7 @@ static void sdp4430_hdmi_mux_init(void)
static struct gpio sdp4430_hdmi_gpios[] = {
{ HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ct_cp_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH,hdmi_gpio_ls_oe },
+ { HDMI_GPIO_HPD, GPIOF_DIR_IN, hdmi_gpio_hpd },
};
static int sdp4430_panel_enable_hdmi(struct omap_dss_device *dssdev)
@@ -827,6 +829,7 @@ static void omap_4430sdp_display_init(void)
omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
}
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 27fc162..e913c80 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -53,6 +53,7 @@
#define GPIO_WIFI_IRQ 53
#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
+#define HDMI_GPIO_HPD 63 /* Hotplug detect */
/* wl127x BT, FM, GPS connectivity chip */
static int wl1271_gpios[] = {46, -1, -1};
@@ -492,6 +493,7 @@ static void omap4_panda_hdmi_mux_init(void)
static struct gpio panda_hdmi_gpios[] = {
{ HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ct_cp_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ls_oe },
+ { HDMI_GPIO_HPD, GPIOF_DIR_IN, hdmi_gpio_hpd },
};
static int omap4_panda_panel_enable_hdmi(struct omap_dss_device *dssdev)
@@ -544,6 +546,7 @@ void omap4_panda_display_init(void)
omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
}
static void __init omap4_panda_init(void)
--
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
[PATCH 6/7] OMAPDSS: HDMI: PHY burnout fix
A hardware bug in the OMAP4 HDMI PHY may cause physical damage to the
board if the HDMI PHY is already enabled when the HDMI cable is plugged
in. The possible damage breaks HDMI output, otherwise the board is
unaffected.
This patch solves the problem by adding hot-plug-detection into the HDMI
IP driver. This is not a real HPD support in the sense that nobody else
than the IP driver gets to know about the HPD events, but is only meant
to fix the HW bug.
The strategy is simple: If the display device is turned off by the user,
the PHY power is set to OFF. When the display device is turned on by the
user, the PHY power is set either to LDOON or TXON, depending on whether
the HDMI cable is connected.
The reason to avoid PHY OFF when the display device is on, but the cable
is disconnected, is that when the PHY is turned OFF, the HDMI IP is not
ticking and thus the DISPC does not receive pixel clock from the HDMI
IP. This would, for example, prevent any VSYNCs from happening, and
would thus affect the users of omapdss. By using LDOON when the cable is
disconnected we'll avoid the HW bug, but keep the HDMI working as usual
from the user's point of view.
Backported from c49d005b6cc8491fad5b24f82805be2d6bcbd3dd
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |5 ++
arch/arm/mach-omap2/board-omap4panda.c|5 ++
drivers/video/omap2/dss/hdmi.c|3 +
drivers/video/omap2/dss/ti_hdmi.h |4 ++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 68 +++--
include/video/omapdss.h |5 ++
6 files changed, 86 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 5c2aaa0..02cd29a 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -742,6 +742,10 @@ static void sdp4430_lcd_init(void)
pr_err(%s: Could not get lcd2_reset_gpio\n, __func__);
}
+static struct omap_dss_hdmi_data sdp4430_hdmi_data = {
+ .hpd_gpio = HDMI_GPIO_HPD,
+};
+
static struct omap_dss_device sdp4430_hdmi_device = {
.name = hdmi,
.driver_name = hdmi_panel,
@@ -749,6 +753,7 @@ static struct omap_dss_device sdp4430_hdmi_device = {
.platform_enable = sdp4430_panel_enable_hdmi,
.platform_disable = sdp4430_panel_disable_hdmi,
.channel = OMAP_DSS_CHANNEL_DIGIT,
+ .data = sdp4430_hdmi_data,
};
static struct picodlp_panel_data sdp4430_picodlp_pdata = {
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index e913c80..51b1c93 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -513,6 +513,10 @@ static void omap4_panda_panel_disable_hdmi(struct
omap_dss_device *dssdev)
gpio_free_array(panda_hdmi_gpios, ARRAY_SIZE(panda_hdmi_gpios));
}
+static struct omap_dss_hdmi_data omap4_panda_hdmi_data = {
+ .hpd_gpio = HDMI_GPIO_HPD,
+};
+
static struct omap_dss_device omap4_panda_hdmi_device = {
.name = hdmi,
.driver_name = hdmi_panel,
@@ -520,6 +524,7 @@ static struct omap_dss_device omap4_panda_hdmi_device = {
.platform_enable = omap4_panda_panel_enable_hdmi,
.platform_disable = omap4_panda_panel_disable_hdmi,
.channel = OMAP_DSS_CHANNEL_DIGIT,
+ .data = omap4_panda_hdmi_data,
};
static struct omap_dss_device *omap4_panda_dss_devices[] = {
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index c56378c..7099c31 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -490,6 +490,7 @@ bool omapdss_hdmi_detect(void)
int omapdss_hdmi_display_enable(struct omap_dss_device *dssdev)
{
+ struct omap_dss_hdmi_data *priv = dssdev-data;
int r = 0;
DSSDBG(ENTER hdmi_display_enable\n);
@@ -502,6 +503,8 @@ int omapdss_hdmi_display_enable(struct omap_dss_device
*dssdev)
goto err0;
}
+ hdmi.ip_data.hpd_gpio = priv-hpd_gpio;
+
r = omap_dss_start_device(dssdev);
if (r) {
DSSERR(failed to start device\n);
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index 2c3443d..ec337b5d 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -121,6 +121,10 @@ struct hdmi_ip_data {
const struct ti_hdmi_ip_ops *ops;
struct hdmi_config cfg;
struct hdmi_pll_info pll_data;
+
+ /* ti_hdmi_4xxx_ip private data. These should be in a separate struct */
+ int hpd_gpio;
+ bool phy_tx_enabled;
};
int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index e1a6ce5..3683404 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
[PATCH 7/7] OMAPDSS: HDMI: hot plug detect fix
From: Rob Clark r...@ti.com
The OMAPDSS: HDMI: PHY burnout fix commit switched the HDMI driver
over to using a GPIO for plug detect. Unfortunately the -detect()
method was not also updated, causing HDMI to no longer work for the
omapdrm driver (because it would actually check if a connection was
detected before attempting to enable display).
Signed-off-by: Rob Clark r...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |9 +
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 3683404..aad48a1 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -479,14 +479,7 @@ int ti_hdmi_4xxx_read_edid(struct hdmi_ip_data *ip_data,
bool ti_hdmi_4xxx_detect(struct hdmi_ip_data *ip_data)
{
- int r;
-
- void __iomem *base = hdmi_core_sys_base(ip_data);
-
- /* HPD */
- r = REG_GET(base, HDMI_CORE_SYS_SYS_STAT, 1, 1);
-
- return r == 1;
+ return gpio_get_value(ip_data-hpd_gpio);
}
static void hdmi_core_init(struct hdmi_core_video_config *video_cfg,
--
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
[PATCH 3/7] OMAPDSS: remove wrong HDMI HPD muxing
hdmi_hpd pin is muxed to INPUT and PULLUP, but the pin is not
currently used, and in the future when it is used, the pin is used as a
GPIO and is board specific, not an OMAP4 wide thing.
So remove the muxing for now.
Backported from 7bb122d155f742fe2d79849090c825be7b4a247e
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c|4
arch/arm/mach-omap2/board-omap4panda.c |4
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 4333115..385c1fd 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -597,12 +597,8 @@ static void __init omap_sfh7741prox_init(void)
static void sdp4430_hdmi_mux_init(void)
{
- /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
- omap_mux_init_signal(hdmi_hpd,
- OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal(hdmi_cec,
OMAP_PIN_INPUT_PULLUP);
- /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
omap_mux_init_signal(hdmi_ddc_scl,
OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal(hdmi_ddc_sda,
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index d8e20f1..e0d0abc 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -481,12 +481,8 @@ int __init omap4_panda_dvi_init(void)
static void omap4_panda_hdmi_mux_init(void)
{
- /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
- omap_mux_init_signal(hdmi_hpd,
- OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal(hdmi_cec,
OMAP_PIN_INPUT_PULLUP);
- /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
omap_mux_init_signal(hdmi_ddc_scl,
OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal(hdmi_ddc_sda,
--
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
[PATCH 4/7] OMAP: 4430SDP/Panda: setup HDMI GPIO muxes
The HDMI GPIO pins LS_OE and CT_CP_HPD are not currently configured. This patch configures them as output pins. Backported from 78a1ad8f12db70b8b0a4548b90704de08ee216ce Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/board-4430sdp.c|3 +++ arch/arm/mach-omap2/board-omap4panda.c |3 +++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 385c1fd..7bcafb9 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -824,6 +824,9 @@ static void omap_4430sdp_display_init(void) sdp4430_hdmi_mux_init(); sdp4430_picodlp_init(); omap_display_init(sdp4430_dss_data); + + omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT); + omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT); } #ifdef CONFIG_OMAP_MUX diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index e0d0abc..27fc162 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -541,6 +541,9 @@ void omap4_panda_display_init(void) omap4_panda_hdmi_mux_init(); omap_display_init(omap4_panda_dss_data); + + omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT); + omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT); } static void __init omap4_panda_init(void) -- 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
[PATCH 0/7] OMAPDSS: HDMI PHY burnout fix for 3.0 stable
This series is for 3.0 stable. The main patch in this set is the PHY burnout fix, which implements a fix for a hardware bug in the OMAP4 HDMI PHY which may cause physical damage to the board if the HDMI PHY is already enabled when the HDMI cable is plugged in. The possible damage breaks HDMI output hardware, otherwise the board is unaffected. The use default dividers patch fixes a problem with setting up the HDMI PLL dividers on Pandaboard. Without the patch the HDMI output does not work at all on Panda. The preceding patches are small cleanups/fixes for HDMI GPIOs so that the fix can be implemented. Tomi Tomi Valkeinen (7): OMAP: DSS2: HDMI: use default dividers OMAP: 4430SDP/Panda: use gpio_free_array to free HDMI gpios OMAP: 4430SDP/Panda: rename HPD GPIO to CT_CP_HPD OMAPDSS: remove wrong HDMI HPD muxing OMAP: 4430SDP/Panda: setup HDMI GPIO muxes OMAP: 4430SDP/Panda: add HDMI HPD gpio OMAPDSS: HDMI: PHY burnout fix arch/arm/mach-omap2/board-4430sdp.c| 31 +-- arch/arm/mach-omap2/board-omap4panda.c | 22 +--- drivers/video/omap2/dss/hdmi.c | 86 +-- include/video/omapdss.h|5 ++ 4 files changed, 113 insertions(+), 31 deletions(-) -- 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
[PATCH 1/7] OMAP: DSS2: HDMI: use default dividers
Use default regn and regm2 dividers in the hdmi driver if the board file
does not define them.
Pandaboard's board file was missing the dividers, causing HDMI output
not to work, so this patch fixes the problem.
Backported from 8d88767a4377171752c22ac39bcb2b505eb751da
Cc: Mythri P K mythr...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |9 -
drivers/video/omap2/dss/hdmi.c | 15 +--
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 63de2d3..f515fa2 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -617,15 +617,6 @@ static struct omap_dss_device sdp4430_hdmi_device = {
.name = hdmi,
.driver_name = hdmi_panel,
.type = OMAP_DISPLAY_TYPE_HDMI,
- .clocks = {
- .dispc = {
- .dispc_fclk_src = OMAP_DSS_CLK_SRC_FCK,
- },
- .hdmi = {
- .regn = 15,
- .regm2 = 1,
- },
- },
.platform_enable = sdp4430_panel_enable_hdmi,
.platform_disable = sdp4430_panel_disable_hdmi,
.channel = OMAP_DSS_CHANNEL_DIGIT,
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index b0555f4..f3369cf 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -40,6 +40,9 @@
#include hdmi.h
#include dss_features.h
+#define HDMI_DEFAULT_REGN 15
+#define HDMI_DEFAULT_REGM2 1
+
static struct {
struct mutex lock;
struct omap_display_platform_data *pdata;
@@ -1069,7 +1072,11 @@ static void hdmi_compute_pll(struct omap_dss_device
*dssdev, int phy,
* Input clock is predivided by N + 1
* out put of which is reference clk
*/
- pi-regn = dssdev-clocks.hdmi.regn;
+ if (dssdev-clocks.hdmi.regn == 0)
+ pi-regn = HDMI_DEFAULT_REGN;
+ else
+ pi-regn = dssdev-clocks.hdmi.regn;
+
refclk = clkin / (pi-regn + 1);
/*
@@ -1077,7 +1084,11 @@ static void hdmi_compute_pll(struct omap_dss_device
*dssdev, int phy,
* Multiplying by 100 to avoid fractional part removal
*/
pi-regm = (phy * 100 / (refclk)) / 100;
- pi-regm2 = dssdev-clocks.hdmi.regm2;
+
+ if (dssdev-clocks.hdmi.regm2 == 0)
+ pi-regm2 = HDMI_DEFAULT_REGM2;
+ else
+ pi-regm2 = dssdev-clocks.hdmi.regm2;
/*
* fractional multiplier is remainder of the difference between
--
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
[PATCH 2/7] OMAP: 4430SDP/Panda: use gpio_free_array to free HDMI gpios
Instead of freeing the GPIOs individually, use gpio_free_array().
Backported from 575753e3bea3b67eef8e454fb87f719e3f7da599
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c|3 +--
arch/arm/mach-omap2/board-omap4panda.c |3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index f515fa2..7feefb8 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -609,8 +609,7 @@ static int sdp4430_panel_enable_hdmi(struct omap_dss_device
*dssdev)
static void sdp4430_panel_disable_hdmi(struct omap_dss_device *dssdev)
{
- gpio_free(HDMI_GPIO_LS_OE);
- gpio_free(HDMI_GPIO_HPD);
+ gpio_free_array(sdp4430_hdmi_gpios, ARRAY_SIZE(sdp4430_hdmi_gpios));
}
static struct omap_dss_device sdp4430_hdmi_device = {
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 0cfe200..2e9a6f36 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -645,8 +645,7 @@ static int omap4_panda_panel_enable_hdmi(struct
omap_dss_device *dssdev)
static void omap4_panda_panel_disable_hdmi(struct omap_dss_device *dssdev)
{
- gpio_free(HDMI_GPIO_LS_OE);
- gpio_free(HDMI_GPIO_HPD);
+ gpio_free_array(panda_hdmi_gpios, ARRAY_SIZE(panda_hdmi_gpios));
}
static struct omap_dss_device omap4_panda_hdmi_device = {
--
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
[PATCH 4/7] OMAPDSS: remove wrong HDMI HPD muxing
hdmi_hpd pin is muxed to INPUT and PULLUP, but the pin is not
currently used, and in the future when it is used, the pin is used as a
GPIO and is board specific, not an OMAP4 wide thing.
So remove the muxing for now.
Backported from 7bb122d155f742fe2d79849090c825be7b4a247e
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c|4
arch/arm/mach-omap2/board-omap4panda.c |4
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index d0a49c3..9bc418e 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -578,12 +578,8 @@ static void __init omap_sfh7741prox_init(void)
static void sdp4430_hdmi_mux_init(void)
{
- /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
- omap_mux_init_signal(hdmi_hpd,
- OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal(hdmi_cec,
OMAP_PIN_INPUT_PULLUP);
- /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
omap_mux_init_signal(hdmi_ddc_scl,
OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal(hdmi_ddc_sda,
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index bc98749..86a2d30 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -614,12 +614,8 @@ int __init omap4_panda_dvi_init(void)
static void omap4_panda_hdmi_mux_init(void)
{
- /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
- omap_mux_init_signal(hdmi_hpd,
- OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal(hdmi_cec,
OMAP_PIN_INPUT_PULLUP);
- /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
omap_mux_init_signal(hdmi_ddc_scl,
OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal(hdmi_ddc_sda,
--
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
[PATCH 3/7] OMAP: 4430SDP/Panda: rename HPD GPIO to CT_CP_HPD
The GPIO 60 on 4430sdp and Panda is not HPD GPIO, as currently marked in
the board files, but CT_CP_HPD, which is used to enable/disable HPD
functionality.
This patch renames the GPIO.
Backported from 3932a32fcf5393f8be70ac99dc718ad7ad0a415b
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c|4 ++--
arch/arm/mach-omap2/board-omap4panda.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 7feefb8..d0a49c3 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -49,7 +49,7 @@
#define ETH_KS8851_QUART 138
#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
#define OMAP4_SFH7741_ENABLE_GPIO 188
-#define HDMI_GPIO_HPD 60 /* Hot plug pin for HDMI */
+#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
static const int sdp4430_keymap[] = {
@@ -591,7 +591,7 @@ static void sdp4430_hdmi_mux_init(void)
}
static struct gpio sdp4430_hdmi_gpios[] = {
- { HDMI_GPIO_HPD,GPIOF_OUT_INIT_HIGH,hdmi_gpio_hpd },
+ { HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ct_cp_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH,hdmi_gpio_ls_oe },
};
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 2e9a6f36..bc98749 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -52,7 +52,7 @@
#define GPIO_HUB_NRESET62
#define GPIO_WIFI_PMENA43
#define GPIO_WIFI_IRQ 53
-#define HDMI_GPIO_HPD 60 /* Hot plug pin for HDMI */
+#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
/* wl127x BT, FM, GPS connectivity chip */
@@ -627,7 +627,7 @@ static void omap4_panda_hdmi_mux_init(void)
}
static struct gpio panda_hdmi_gpios[] = {
- { HDMI_GPIO_HPD,GPIOF_OUT_INIT_HIGH, hdmi_gpio_hpd },
+ { HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ct_cp_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ls_oe },
};
--
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
[PATCH 6/7] OMAP: 4430SDP/Panda: add HDMI HPD gpio
Both Panda and 4430SDP use GPIO 63 as HDMI hot-plug-detect. Configure
this GPIO in the board files.
Backported from aa74274b464d4aa24703963ac89a0ee942d5d267
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c|3 +++
arch/arm/mach-omap2/board-omap4panda.c |3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 669e329..0ee578a 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -51,6 +51,7 @@
#define OMAP4_SFH7741_ENABLE_GPIO 188
#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
+#define HDMI_GPIO_HPD 63 /* Hotplug detect */
static const int sdp4430_keymap[] = {
KEY(0, 0, KEY_E),
@@ -589,6 +590,7 @@ static void sdp4430_hdmi_mux_init(void)
static struct gpio sdp4430_hdmi_gpios[] = {
{ HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ct_cp_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH,hdmi_gpio_ls_oe },
+ { HDMI_GPIO_HPD, GPIOF_DIR_IN, hdmi_gpio_hpd },
};
static int sdp4430_panel_enable_hdmi(struct omap_dss_device *dssdev)
@@ -634,6 +636,7 @@ void omap_4430sdp_display_init(void)
omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
}
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 5d519fb..2b3f7e0 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -54,6 +54,7 @@
#define GPIO_WIFI_IRQ 53
#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
+#define HDMI_GPIO_HPD 63 /* Hotplug detect */
/* wl127x BT, FM, GPS connectivity chip */
static int wl1271_gpios[] = {46, -1, -1};
@@ -625,6 +626,7 @@ static void omap4_panda_hdmi_mux_init(void)
static struct gpio panda_hdmi_gpios[] = {
{ HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ct_cp_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ls_oe },
+ { HDMI_GPIO_HPD, GPIOF_DIR_IN, hdmi_gpio_hpd },
};
static int omap4_panda_panel_enable_hdmi(struct omap_dss_device *dssdev)
@@ -677,6 +679,7 @@ void omap4_panda_display_init(void)
omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
}
static void __init omap4_panda_init(void)
--
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
[PATCH 7/7] OMAPDSS: HDMI: PHY burnout fix
A hardware bug in the OMAP4 HDMI PHY may cause physical damage to the
board if the HDMI PHY is already enabled when the HDMI cable is plugged
in. The possible damage breaks HDMI output, otherwise the board is
unaffected.
This patch solves the problem by adding hot-plug-detection into the HDMI
IP driver. This is not a real HPD support in the sense that nobody else
than the IP driver gets to know about the HPD events, but is only meant
to fix the HW bug.
The strategy is simple: If the display device is turned off by the user,
the PHY power is set to OFF. When the display device is turned on by the
user, the PHY power is set either to LDOON or TXON, depending on whether
the HDMI cable is connected.
The reason to avoid PHY OFF when the display device is on, but the cable
is disconnected, is that when the PHY is turned OFF, the HDMI IP is not
ticking and thus the DISPC does not receive pixel clock from the HDMI
IP. This would, for example, prevent any VSYNCs from happening, and
would thus affect the users of omapdss. By using LDOON when the cable is
disconnected we'll avoid the HW bug, but keep the HDMI working as usual
from the user's point of view.
Backported from c49d005b6cc8491fad5b24f82805be2d6bcbd3dd
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c|5 ++
arch/arm/mach-omap2/board-omap4panda.c |5 ++
drivers/video/omap2/dss/hdmi.c | 71 ++--
include/video/omapdss.h|5 ++
4 files changed, 82 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 0ee578a..14a5971 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -610,6 +610,10 @@ static void sdp4430_panel_disable_hdmi(struct
omap_dss_device *dssdev)
gpio_free_array(sdp4430_hdmi_gpios, ARRAY_SIZE(sdp4430_hdmi_gpios));
}
+static struct omap_dss_hdmi_data sdp4430_hdmi_data = {
+ .hpd_gpio = HDMI_GPIO_HPD,
+};
+
static struct omap_dss_device sdp4430_hdmi_device = {
.name = hdmi,
.driver_name = hdmi_panel,
@@ -617,6 +621,7 @@ static struct omap_dss_device sdp4430_hdmi_device = {
.platform_enable = sdp4430_panel_enable_hdmi,
.platform_disable = sdp4430_panel_disable_hdmi,
.channel = OMAP_DSS_CHANNEL_DIGIT,
+ .data = sdp4430_hdmi_data,
};
static struct omap_dss_device *sdp4430_dss_devices[] = {
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 2b3f7e0..107dfc3 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -646,6 +646,10 @@ static void omap4_panda_panel_disable_hdmi(struct
omap_dss_device *dssdev)
gpio_free_array(panda_hdmi_gpios, ARRAY_SIZE(panda_hdmi_gpios));
}
+static struct omap_dss_hdmi_data omap4_panda_hdmi_data = {
+ .hpd_gpio = HDMI_GPIO_HPD,
+};
+
static struct omap_dss_device omap4_panda_hdmi_device = {
.name = hdmi,
.driver_name = hdmi_panel,
@@ -653,6 +657,7 @@ static struct omap_dss_device omap4_panda_hdmi_device = {
.platform_enable = omap4_panda_panel_enable_hdmi,
.platform_disable = omap4_panda_panel_disable_hdmi,
.channel = OMAP_DSS_CHANNEL_DIGIT,
+ .data = omap4_panda_hdmi_data,
};
static struct omap_dss_device *omap4_panda_dss_devices[] = {
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index f3369cf..fadd6a0 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -29,6 +29,7 @@
#include linux/mutex.h
#include linux/delay.h
#include linux/string.h
+#include linux/gpio.h
#include video/omapdss.h
#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
@@ -54,6 +55,9 @@ static struct {
u8 edid_set;
bool custom_set;
struct hdmi_config cfg;
+
+ int hpd_gpio;
+ bool phy_tx_enabled;
} hdmi;
/*
@@ -278,6 +282,47 @@ static int hdmi_pll_reset(void)
return 0;
}
+static int hdmi_check_hpd_state(void)
+{
+ unsigned long flags;
+ bool hpd;
+ int r;
+ /* this should be in ti_hdmi_4xxx_ip private data */
+ static DEFINE_SPINLOCK(phy_tx_lock);
+
+ spin_lock_irqsave(phy_tx_lock, flags);
+
+ hpd = gpio_get_value(hdmi.hpd_gpio);
+
+ if (hpd == hdmi.phy_tx_enabled) {
+ spin_unlock_irqrestore(phy_tx_lock, flags);
+ return 0;
+ }
+
+ if (hpd)
+ r = hdmi_set_phy_pwr(HDMI_PHYPWRCMD_TXON);
+ else
+ r = hdmi_set_phy_pwr(HDMI_PHYPWRCMD_LDOON);
+
+ if (r) {
+ DSSERR(Failed to %s PHY TX power\n,
+ hpd ? enable : disable);
+ goto err;
+ }
+
+ hdmi.phy_tx_enabled = hpd;
+err:
+ spin_unlock_irqrestore(phy_tx_lock, flags);
+ return r;
+}
+
+static
[PATCH 5/7] OMAP: 4430SDP/Panda: setup HDMI GPIO muxes
The HDMI GPIO pins LS_OE and CT_CP_HPD are not currently configured.
This patch configures them as output pins.
Backported from 78a1ad8f12db70b8b0a4548b90704de08ee216ce
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c|3 +++
arch/arm/mach-omap2/board-omap4panda.c |3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 9bc418e..669e329 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -631,6 +631,9 @@ void omap_4430sdp_display_init(void)
{
sdp4430_hdmi_mux_init();
omap_display_init(sdp4430_dss_data);
+
+ omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
}
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 86a2d30..5d519fb 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -674,6 +674,9 @@ void omap4_panda_display_init(void)
omap4_panda_hdmi_mux_init();
omap_display_init(omap4_panda_dss_data);
+
+ omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
}
static void __init omap4_panda_init(void)
--
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 V2 1/1] mmc: start removing enable / disable API
On Wed, Feb 29, 2012 at 12:47 PM, Adrian Hunter adrian.hun...@intel.com wrote:
Most parts of the enable / disable API are no longer used and
can be removed.
Cc: Rajendra Nayak rna...@ti.com
Cc: Venkatraman S svenk...@ti.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Thomas Abraham thomas.abra...@linaro.org
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
Tested on OMAP4 SDP Platform
Tested-by: Venkatraman S svenk...@ti.com
---
arch/arm/mach-exynos/mach-nuri.c | 5 +-
arch/arm/mach-exynos/mach-universal_c210.c | 9 +-
drivers/mmc/core/core.c | 187
+++-
drivers/mmc/core/host.c | 1 -
drivers/mmc/core/host.h | 1 -
drivers/mmc/host/davinci_mmc.c | 4 -
drivers/mmc/host/omap_hsmmc.c | 15 +--
include/linux/mmc/core.h | 1 -
include/linux/mmc/host.h | 46 +--
9 files changed, 27 insertions(+), 242 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-nuri.c
b/arch/arm/mach-exynos/mach-nuri.c
index 644af11..de68248 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -109,7 +109,7 @@ static struct s3c_sdhci_platdata nuri_hsmmc0_data
__initdata = {
.max_width = 8,
.host_caps = (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA |
MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
- MMC_CAP_DISABLE | MMC_CAP_ERASE),
+ MMC_CAP_ERASE),
.cd_type = S3C_SDHCI_CD_PERMANENT,
};
@@ -147,8 +147,7 @@ static struct platform_device emmc_fixed_voltage = {
static struct s3c_sdhci_platdata nuri_hsmmc2_data __initdata = {
.max_width = 4,
.host_caps = MMC_CAP_4_BIT_DATA |
- MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
- MMC_CAP_DISABLE,
+ MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
.ext_cd_gpio = EXYNOS4_GPX3(3), /* XEINT_27 */
.ext_cd_gpio_invert = 1,
.cd_type = S3C_SDHCI_CD_GPIO,
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
b/arch/arm/mach-exynos/mach-universal_c210.c
index 9b3fbae..57cfe61 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -734,8 +734,7 @@ static struct platform_device universal_gpio_keys = {
static struct s3c_sdhci_platdata universal_hsmmc0_data __initdata = {
.max_width = 8,
.host_caps = (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA |
- MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
- MMC_CAP_DISABLE),
+ MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED),
.cd_type = S3C_SDHCI_CD_PERMANENT,
};
@@ -772,8 +771,7 @@ static struct platform_device mmc0_fixed_voltage = {
static struct s3c_sdhci_platdata universal_hsmmc2_data __initdata = {
.max_width = 4,
.host_caps = MMC_CAP_4_BIT_DATA |
- MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
- MMC_CAP_DISABLE,
+ MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
.ext_cd_gpio = EXYNOS4_GPX3(4), /* XEINT_28 */
.ext_cd_gpio_invert = 1,
.cd_type = S3C_SDHCI_CD_GPIO,
@@ -783,8 +781,7 @@ static struct s3c_sdhci_platdata universal_hsmmc2_data
__initdata = {
static struct s3c_sdhci_platdata universal_hsmmc3_data __initdata = {
.max_width = 4,
.host_caps = MMC_CAP_4_BIT_DATA |
- MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
- MMC_CAP_DISABLE,
+ MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
.cd_type = S3C_SDHCI_CD_EXTERNAL,
};
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 0b317f0..44dd013 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -605,105 +605,6 @@ unsigned int mmc_align_data_size(struct mmc_card *card,
unsigned int sz)
EXPORT_SYMBOL(mmc_align_data_size);
/**
- * mmc_host_enable - enable a host.
- * @host: mmc host to enable
- *
- * Hosts that support power saving can use the 'enable' and 'disable'
- * methods to exit and enter power saving states. For more information
- * see comments for struct mmc_host_ops.
- */
-int mmc_host_enable(struct mmc_host *host)
-{
- if (!(host-caps MMC_CAP_DISABLE))
-
[PATCH] ARM: OMAP: hwmod: Use sysc_fields-srst_shift and get rid of hardcoded SYSC_TYPE2_SOFTRESET_MASK
This is useful when we have broken type2 compliant IPs' where
the softreset shift is not the same as SYSC_TYPE2_SOFTRESET_SHIFT
and hence is overridden using sysc_fields-srst_shift.
We have atleast one such instance now with onchip keypad on OMAP5
which has a different softreset shift as compared to other type2
IPs'.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Balaji TK balaj...@ti.com
Tested-by: Sourav Poddar sourav.pod...@ti.com
---
Paul,
I based the patch on top of your reset/data cleanup series
for hwmod. So its based on 'hwmod_data_cleanup_3.4' branch.
regards,
Rajendra
arch/arm/mach-omap2/omap_hwmod.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 3462dc5..6aadba2 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1524,7 +1524,7 @@ static int _read_hardreset(struct omap_hwmod *oh, const
char *name)
*/
static int _ocp_softreset(struct omap_hwmod *oh)
{
- u32 v;
+ u32 v, softrst_mask;
int c = 0;
int ret = 0;
@@ -1559,11 +1559,13 @@ static int _ocp_softreset(struct omap_hwmod *oh)
oh-class-sysc-syss_offs)
SYSS_RESETDONE_MASK),
MAX_MODULE_SOFTRESET_WAIT, c);
- else if (oh-class-sysc-sysc_flags SYSC_HAS_RESET_STATUS)
+ else if (oh-class-sysc-sysc_flags SYSC_HAS_RESET_STATUS) {
+ softrst_mask = (0x1
oh-class-sysc-sysc_fields-srst_shift);
omap_test_timeout(!(omap_hwmod_read(oh,
oh-class-sysc-sysc_offs)
- SYSC_TYPE2_SOFTRESET_MASK),
+ softrst_mask),
MAX_MODULE_SOFTRESET_WAIT, c);
+ }
if (c == MAX_MODULE_SOFTRESET_WAIT)
pr_warning(omap_hwmod: %s: softreset failed (waited %d
usec)\n,
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: hwmod: Use sysc_fields-srst_shift and get rid of hardcoded SYSC_TYPE2_SOFTRESET_MASK
On 3/1/2012 2:47 PM, Rajendra Nayak wrote:
This is useful when we have broken type2 compliant IPs' where
the softreset shift is not the same as SYSC_TYPE2_SOFTRESET_SHIFT
and hence is overridden using sysc_fields-srst_shift.
We have atleast one such instance now with onchip keypad on OMAP5
Nit: space is missing.
which has a different softreset shift as compared to other type2
IPs'.
A broken IP again :-)
That's anyway a good fix since the srst_shift was already configurable,
so having a hard-coded mask was wrong or at least error prone for non
standard IP.
Signed-off-by: Rajendra Nayakrna...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Benoit Coussonb-cous...@ti.com
Cc: Balaji TKbalaj...@ti.com
Tested-by: Sourav Poddarsourav.pod...@ti.com
---
Paul,
I based the patch on top of your reset/data cleanup series
for hwmod. So its based on 'hwmod_data_cleanup_3.4' branch.
regards,
Rajendra
arch/arm/mach-omap2/omap_hwmod.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 3462dc5..6aadba2 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1524,7 +1524,7 @@ static int _read_hardreset(struct omap_hwmod *oh, const
char *name)
*/
static int _ocp_softreset(struct omap_hwmod *oh)
{
- u32 v;
+ u32 v, softrst_mask;
int c = 0;
int ret = 0;
@@ -1559,11 +1559,13 @@ static int _ocp_softreset(struct omap_hwmod *oh)
oh-class-sysc-syss_offs)
SYSS_RESETDONE_MASK),
MAX_MODULE_SOFTRESET_WAIT, c);
- else if (oh-class-sysc-sysc_flags SYSC_HAS_RESET_STATUS)
+ else if (oh-class-sysc-sysc_flags SYSC_HAS_RESET_STATUS) {
+ softrst_mask = (0x1
oh-class-sysc-sysc_fields-srst_shift);
omap_test_timeout(!(omap_hwmod_read(oh,
oh-class-sysc-sysc_offs)
- SYSC_TYPE2_SOFTRESET_MASK),
+ softrst_mask),
MAX_MODULE_SOFTRESET_WAIT, c);
+ }
if (c == MAX_MODULE_SOFTRESET_WAIT)
pr_warning(omap_hwmod: %s: softreset failed (waited %d
usec)\n,
Acked-by: Benoit Coussonb-cous...@ti.com
Thanks,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Randconfig module build error with OMAP4_ERRATA_I688
* Shilimkar, Santosh santosh.shilim...@ti.com [120301 00:38]: On Wed, Feb 29, 2012 at 11:07 PM, Tony Lindgren t...@atomide.com wrote: Hi Santosh, Looks like OMAP4_ERRATA_I688 still has one more issue: Modules won't build at least with the attached randconfig generated file. Can you please take a look at how to deal with it? Maybe omap_bus_sync should be an inline function with some wrapper for the sleep44xx.S to call? I already posted a fix for the GPMC related error with the same .config file. This one builds for me against 'Linux 3.3-rc5, Ofocurse I got below error with the attached .config which I bypassed to see the Errata build failure. arch/arm/mach-omap2/built-in.o: In function `n8x0_mmc_callback': linux-2.6/arch/arm/mach-omap2/board-n8x0.c:374: undefined reference to `omap_mmc_notify_cover_event' make: *** [.tmp_vmlinux1] Error 1 Yes a fix for that has been queued already. I build this with below toolchain... $arm-none-linux-gnueabi-gcc --version arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2011.03-41) 4.5.2 Copyright (C) 2010 Free Software Foundation, Inc. Am I missing anything ? I think you're missing your commit 2ec1fc4e169acc0b8d6733ff028fd52e766773d9 (ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback) thats' queued up in fixes, and CONFIG_OMAP4_ERRATA_I688=y. Then with -rc5 + 2ec1fc4e when you build modules you'll get this: ERROR: omap_bus_sync [drivers/watchdog/sp805_wdt.ko] undefined! ERROR: omap_bus_sync [drivers/watchdog/dw_wdt.ko] undefined! ERROR: omap_bus_sync [drivers/virtio/virtio_ring.ko] undefined! ERROR: omap_bus_sync [drivers/video/sm501fb.ko] undefined! ERROR: omap_bus_sync [drivers/usb/mon/usbmon.ko] undefined! ERROR: omap_bus_sync [drivers/usb/host/sl811-hcd.ko] undefined! ERROR: omap_bus_sync [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: omap_bus_sync [drivers/usb/host/isp1760.ko] undefined! ERROR: omap_bus_sync [drivers/usb/host/isp1362-hcd.ko] undefined! ERROR: omap_bus_sync [drivers/usb/host/isp116x-hcd.ko] undefined! ERROR: omap_bus_sync [drivers/usb/core/usbcore.ko] undefined! ERROR: omap_bus_sync [drivers/tty/serial/altera_uart.ko] undefined! ERROR: omap_bus_sync [drivers/tty/serial/altera_jtaguart.ko] undefined! ERROR: omap_bus_sync [drivers/tty/serial/8250/8250_dw.ko] undefined! ERROR: omap_bus_sync [drivers/ssb/ssb.ko] undefined! ERROR: omap_bus_sync [drivers/rtc/rtc-cmos.ko] undefined! ERROR: omap_bus_sync [drivers/rtc/rtc-bq4802.ko] undefined! ERROR: omap_bus_sync [drivers/mtd/nand/tmio_nand.ko] undefined! ERROR: omap_bus_sync [drivers/mtd/nand/omap2.ko] undefined! ERROR: gpmc_calculate_ecc [drivers/mtd/nand/omap2.ko] undefined! ERROR: gpmc_enable_hwecc [drivers/mtd/nand/omap2.ko] undefined! For the two above I already posted a fix for. ERROR: omap_bus_sync [drivers/mtd/nand/nand.ko] undefined! ERROR: omap_bus_sync [drivers/mtd/nand/diskonchip.ko] undefined! ERROR: omap_bus_sync [drivers/mtd/maps/map_funcs.ko] undefined! ERROR: omap_bus_sync [drivers/mtd/devices/docprobe.ko] undefined! ERROR: omap_bus_sync [drivers/mtd/devices/doc2001.ko] undefined! ERROR: omap_bus_sync [drivers/mtd/devices/doc2000.ko] undefined! ERROR: omap_bus_sync [drivers/mmc/host/sdhci.ko] undefined! ERROR: omap_bus_sync [drivers/mmc/host/sdhci-pxav3.ko] undefined! ERROR: omap_bus_sync [drivers/mmc/host/sdhci-pxav2.ko] undefined! ERROR: omap_bus_sync [drivers/mmc/host/dw_mmc.ko] undefined! ERROR: omap_bus_sync [drivers/mfd/sm501.ko] undefined! ERROR: omap_bus_sync [drivers/leds/leds-ot200.ko] undefined! ERROR: omap_bus_sync [drivers/input/touchscreen/w90p910_ts.ko] undefined! ERROR: omap_bus_sync [drivers/input/touchscreen/tsc2007.ko] undefined! ERROR: omap_bus_sync [drivers/input/touchscreen/pixcir_i2c_ts.ko] undefined! ERROR: omap_bus_sync [drivers/input/touchscreen/mk712.ko] undefined! ERROR: omap_bus_sync [drivers/input/touchscreen/auo-pixcir-ts.ko] undefined! ERROR: omap_bus_sync [drivers/input/serio/ambakmi.ko] undefined! ERROR: omap_bus_sync [drivers/input/keyboard/matrix_keypad.ko] undefined! ERROR: omap_bus_sync [drivers/input/keyboard/atkbd.ko] undefined! ERROR: omap_bus_sync [drivers/i2c/busses/i2c-simtec.ko] undefined! ERROR: omap_bus_sync [drivers/i2c/busses/i2c-pca-platform.ko] undefined! ERROR: omap_bus_sync [drivers/i2c/busses/i2c-ocores.ko] undefined! ERROR: omap_bus_sync [drivers/gpu/drm/drm.ko] undefined! ERROR: omap_bus_sync [drivers/dma/dw_dmac.ko] undefined! ERROR: omap_bus_sync [drivers/char/nvram.ko] undefined! ERROR: omap_bus_sync [drivers/block/mg_disk.ko] undefined! ERROR: omap_bus_sync [drivers/base/firmware_class.ko] undefined! Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: make iommu subsys_initcall to fix builtin omap3isp
Hi Ohad, On Monday 27 February 2012 09:00:51 Ohad Ben-Cohen wrote: On Mon, Feb 27, 2012 at 12:47 AM, Laurent Pinchart wrote: I'm asking about the probe deferral mechanism. The omap3-isp driver will still call iommu_attach_device() in its probe function. What will happen then ? Will it return an error ? On what basis will it do so ? Yes, iommu_attach_device() will fail, and omap3isp's probe function will then need to return -EAGAIN to request that its probe function will be invoked again later on. That's what the comment in the Makefile is for ;-) I don't think it's a perfect solution either, but it avoids playing with the various initcalls. The OMAP3 IOMMU isn't a subsystem, subsys_initcall() looks a bit like an API abuse to me. Yes, it's dirty. But it's explicit and consistent across build system changes (without imposing anything on the build system). We do it all the time with other subsystems. We don't like it, but luckily Grant came up with the deferred probing mechanism, which will fix this all very nicely. Are drivers supposed to call iommu_attach_device() in their probe() function or later on ? If you can defer attaching to a later point, most commonly to a point where the device is opened by the user, it's better - less power will be consumed. I'll try that then. How expensive is the iommu_attach_device() (and detach) operation in terms of CPU time ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: make iommu subsys_initcall to fix builtin omap3isp
Hi Laurent, On Thu, Mar 1, 2012 at 6:37 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: I'll try that then. How expensive is the iommu_attach_device() (and detach) operation in terms of CPU time ? omap_iommu_attach() basically enables the iommu clock and configures that IP block. I suspect it's negligible but I didn't really measure it... Thanks, Ohad. -- 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: Question: Custom DAI driver for AM35xx using McBSP
We have resolved our issue with the help of PaulM at TI. The driver does work, the trouble was with the way the data was being masked in the buffer. We posted a detailed explanation on the E2E forum (link above) that you may review if interested. 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
[PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
* With certain SD cards timeouts like the following have been seen
due to an improper calculation of the dto value:
mmcblk0: error -110 transferring data, sector 4126233, nr 8,
card status 0xc00
* By removing the dto calculation and setting the timeout value
to the maximum specified by the SD card specification part A2
section 2.2.15 these timeouts can be avoided.
* This change has been used by beagleboard users as well as the
Texas Instruments SDK without a negative impact.
* There are multiple discussion threads about this but the most
relevant ones are:
* http://talk.maemo.org/showthread.php?p=1000707#post1000707
* http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42213.html
* Original proposal for this fix was done by Sukumar Ghoral of
Texas Instruments
* Tested using a Texas Instruments AM335x EVM
Signed-off-by: Chase Maupin chase.mau...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 30 +-
1 files changed, 5 insertions(+), 25 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index fd0c661..afd7292 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1481,11 +1481,8 @@ static int omap_hsmmc_start_dma_transfer(struct
omap_hsmmc_host *host,
return 0;
}
-static void set_data_timeout(struct omap_hsmmc_host *host,
-unsigned int timeout_ns,
-unsigned int timeout_clks)
+static void set_data_timeout(struct omap_hsmmc_host *host)
{
- unsigned int timeout, cycle_ns;
uint32_t reg, clkd, dto = 0;
reg = OMAP_HSMMC_READ(host-base, SYSCTL);
@@ -1493,25 +1490,8 @@ static void set_data_timeout(struct omap_hsmmc_host
*host,
if (clkd == 0)
clkd = 1;
- cycle_ns = 10 / (clk_get_rate(host-fclk) / clkd);
- timeout = timeout_ns / cycle_ns;
- timeout += timeout_clks;
- if (timeout) {
- while ((timeout 0x8000) == 0) {
- dto += 1;
- timeout = 1;
- }
- dto = 31 - dto;
- timeout = 1;
- if (timeout dto)
- dto += 1;
- if (dto = 13)
- dto -= 13;
- else
- dto = 0;
- if (dto 14)
- dto = 14;
- }
+/* Use the maximum timeout value allowed in the standard of 14 or 0xE */
+ dto = 14;
reg = ~DTO_MASK;
reg |= dto DTO_SHIFT;
@@ -1534,13 +1514,13 @@ omap_hsmmc_prepare_data(struct omap_hsmmc_host *host,
struct mmc_request *req)
* busy signal.
*/
if (req-cmd-flags MMC_RSP_BUSY)
- set_data_timeout(host, 1U, 0);
+ set_data_timeout(host);
return 0;
}
OMAP_HSMMC_WRITE(host-base, BLK, (req-data-blksz)
| (req-data-blocks 16));
- set_data_timeout(host, req-data-timeout_ns, req-data-timeout_clks);
+ set_data_timeout(host);
if (host-use_dma) {
ret = omap_hsmmc_start_dma_transfer(host, req);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Few more omap DT patches for next merge window
Hi all, Looks like we need one fix to what's currently queued up in dt-part2 branch for omaps. And we can make board-generic more readable by cutting down the ifdefs. Regards, Tony --- Tony Lindgren (2): ARM: OMAP2+: Fix build error when only ARCH_OMAP2/3 or 4 is selected ARM: OMAP2+: Remove extra ifdefs for board-generic arch/arm/mach-omap2/board-generic.c | 83 --- 1 files changed, 39 insertions(+), 44 deletions(-) -- Signature -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP2+: Fix build error when only ARCH_OMAP2/3 or 4 is selected
Otherwise we'll get undefined reference to `gic_of_init' or
undefined reference to `omap_intc_of_init'.
This was caused by commit fbf75da733e82bb17a01e1b907b0e40d9c028823
(ARM: OMAP2+: board-generic: Use of_irq_init API).
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-generic.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 12f4c5f..25d195f 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -25,6 +25,13 @@
#include common.h
#include common-board-devices.h
+#if !(defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3))
+#define omap_intc_of_init NULL
+#endif
+#ifndef CONFIG_ARCH_OMAP4
+#define gic_of_initNULL
+#endif
+
static struct of_device_id irq_match[] __initdata = {
{ .compatible = ti,omap2-intc, .data = omap_intc_of_init, },
{ .compatible = arm,cortex-a9-gic, .data = gic_of_init, },
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: OMAP2+: Remove extra ifdefs for board-generic
We need just one ifdef for each ARCH_OMAP2/3/4.
Also remove the comment about i2c twl driver as it's
pretty obvious that we still need some platform data
until drivers are converted to device tree.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-generic.c | 76 +++
1 files changed, 32 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 25d195f..74e1687 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -43,34 +43,6 @@ static void __init omap_init_irq(void)
of_irq_init(irq_match);
}
-/*
- * XXX: Still needed to boot until the i2c twl driver is adapted to
- * device-tree
- */
-#ifdef CONFIG_ARCH_OMAP4
-static struct twl4030_platform_data sdp4430_twldata = {
- .irq_base = TWL6030_IRQ_BASE,
- .irq_end= TWL6030_IRQ_END,
-};
-
-static void __init omap4_i2c_init(void)
-{
- omap4_pmic_init(twl6030, sdp4430_twldata);
-}
-#endif
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct twl4030_platform_data beagle_twldata = {
- .irq_base = TWL4030_IRQ_BASE,
- .irq_end= TWL4030_IRQ_END,
-};
-
-static void __init omap3_i2c_init(void)
-{
- omap3_pmic_init(twl4030, beagle_twldata);
-}
-#endif
-
static struct of_device_id omap_dt_match_table[] __initdata = {
{ .compatible = simple-bus, },
{ .compatible = ti,omap-infra, },
@@ -84,22 +56,6 @@ static void __init omap_generic_init(void)
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
}
-#ifdef CONFIG_ARCH_OMAP4
-static void __init omap4_init(void)
-{
- omap4_i2c_init();
- omap_generic_init();
-}
-#endif
-
-#ifdef CONFIG_ARCH_OMAP3
-static void __init omap3_init(void)
-{
- omap3_i2c_init();
- omap_generic_init();
-}
-#endif
-
#ifdef CONFIG_SOC_OMAP2420
static const char *omap242x_boards_compat[] __initdata = {
ti,omap2420,
@@ -139,6 +95,22 @@ MACHINE_END
#endif
#ifdef CONFIG_ARCH_OMAP3
+static struct twl4030_platform_data beagle_twldata = {
+ .irq_base = TWL4030_IRQ_BASE,
+ .irq_end= TWL4030_IRQ_END,
+};
+
+static void __init omap3_i2c_init(void)
+{
+ omap3_pmic_init(twl4030, beagle_twldata);
+}
+
+static void __init omap3_init(void)
+{
+ omap3_i2c_init();
+ omap_generic_init();
+}
+
static const char *omap3_boards_compat[] __initdata = {
ti,omap3,
NULL,
@@ -158,6 +130,22 @@ MACHINE_END
#endif
#ifdef CONFIG_ARCH_OMAP4
+static struct twl4030_platform_data sdp4430_twldata = {
+ .irq_base = TWL6030_IRQ_BASE,
+ .irq_end= TWL6030_IRQ_END,
+};
+
+static void __init omap4_i2c_init(void)
+{
+ omap4_pmic_init(twl6030, sdp4430_twldata);
+}
+
+static void __init omap4_init(void)
+{
+ omap4_i2c_init();
+ omap_generic_init();
+}
+
static const char *omap4_boards_compat[] __initdata = {
ti,omap4,
NULL,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Start getting rid of pdata callbacks with gpio_find_by_chip_name()
Hi all, This series adds gpio_find_by_name() that allows finding GPIOs on specific gpio_chips. As the GPIO numbers can be dynamic, it's hard to find the GPIO numbers from drivers using them directly. So far we've dealt with this using platform specific callbacks, but that is messy. This series removes the needs for these callbacks for omap hsmmc driver. Further callbacks can be removed people are OK with adding gpio_find_by_name(). This series is based on the omap fixes-non-critical that's needed for the arch/arm/mach-omap2 parts of this series. Regards, Tony --- Tony Lindgren (4): gpiolib: Add gpiochip_find_by_name() and gpio_find_by_chip_name() mmc: omap_hsmmc: Use gpio_find_by_chip_name() for omap_hsmmc_gpio_init() mmc: omap_hsmmc: Use GPIO offset for external GPIO chips mmc: omap_hsmmc: Simplify init for twl6030 MMC card detect arch/arm/mach-omap2/board-3430sdp.c | 13 +- arch/arm/mach-omap2/board-4430sdp.c | 45 arch/arm/mach-omap2/board-cm-t35.c |8 - arch/arm/mach-omap2/board-devkit8000.c |7 - arch/arm/mach-omap2/board-igep0020.c |8 - arch/arm/mach-omap2/board-omap3beagle.c |9 +- arch/arm/mach-omap2/board-omap3evm.c |8 - arch/arm/mach-omap2/board-omap3pandora.c | 13 +- arch/arm/mach-omap2/board-omap3stalker.c |8 - arch/arm/mach-omap2/board-omap3touchbook.c |7 - arch/arm/mach-omap2/board-omap4panda.c | 52 -- arch/arm/mach-omap2/board-zoom-peripherals.c |7 - arch/arm/mach-omap2/hsmmc.c |3 + arch/arm/mach-omap2/hsmmc.h |5 + arch/arm/plat-omap/include/plat/mmc.h|3 + drivers/gpio/gpio-twl4030.c |2 drivers/gpio/gpiolib.c | 47 + drivers/mfd/twl6030-irq.c| 33 +++--- drivers/mmc/host/omap_hsmmc.c| 140 +++--- include/asm-generic/gpio.h |3 - 20 files changed, 204 insertions(+), 217 deletions(-) -- Signature -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] gpiolib: Add gpiochip_find_by_name() and gpio_find_by_chip_name()
Currently there is no way for drivers to request a GPIO on a particular
gpio chip. This makes it hard to support multiple GPIO controllers
with dynamic GPIO and interrupt numbering, such as with CONFIG_SPARSE_IRQ.
Make it easier for device drivers to find GPIOs on a specific gpio_chip
by adding two functions: gpiochip_find_by_name() and gpio_find_by_chip_name().
Note that as gpiochip_find() is already exported, we may as well
export gpiochip_find_by_name() too.
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Linus Walleij linus.wall...@stericsson.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/gpio/gpiolib.c | 47
include/asm-generic/gpio.h |3 ++-
2 files changed, 49 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 17fdf4b..0e5bf55 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1173,6 +1173,53 @@ struct gpio_chip *gpiochip_find(void *data,
}
EXPORT_SYMBOL_GPL(gpiochip_find);
+static int match_name(struct gpio_chip *chip, void *data)
+{
+ const char *name = data;
+
+ return sysfs_streq(name, chip-label);
+}
+
+/**
+ * gpiochip_find_by_name() - iterator for locating a gpio_chip by name
+ * @name: name of the gpio_chip
+ *
+ * Similar to bus_find_device_by_name. It returns a reference to the
+ * first gpio_chip with matching name. It ignores NULL and empty names.
+ * If you need to do something more complex, then use gpiochip_find.
+ */
+struct gpio_chip *gpiochip_find_by_name(const char *name)
+{
+ if (!name || !strcmp(name, ))
+ return NULL;
+
+ return gpiochip_find((void *)name, match_name);
+}
+EXPORT_SYMBOL_GPL(gpiochip_find_by_name);
+
+/**
+ * gpio_find_by_chip_name() - find a gpio on a specific gpio_chip
+ * @chip_name: name of the gpio_chip
+ * @gpio_offset: offset of the gpio on the gpio_chip
+ *
+ * Note that gpiochip_find_by_name returns the first matching
+ * gpio_chip name. For more complex matching, see gpio_find.
+ */
+int gpio_find_by_chip_name(const char *chip_name, unsigned gpio_offset)
+{
+ struct gpio_chip *chip;
+ int gpio, res;
+
+ chip = gpiochip_find_by_name(chip_name);
+ if (!chip)
+ return -ENODEV;
+
+ gpio = chip-base + gpio_offset;
+
+ return gpio;
+}
+EXPORT_SYMBOL_GPL(gpio_find_by_chip_name);
+
/* These optional allocation calls help prevent drivers from stomping
* on each other, and help provide better diagnostics in debugfs.
* They're called even less than the set direction calls.
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 1ff4e22..d7a2100 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -145,7 +145,8 @@ extern int __must_check gpiochip_remove(struct gpio_chip
*chip);
extern struct gpio_chip *gpiochip_find(void *data,
int (*match)(struct gpio_chip *chip,
void *data));
-
+extern struct gpio_chip *gpiochip_find_by_name(const char *name);
+extern int gpio_find_by_chip_name(const char *chip_name, unsigned gpio_offset);
/* Always use the library code for GPIO management calls,
* or when sleeping may be involved.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] mmc: omap_hsmmc: Use GPIO offset for external GPIO chips
We can now remove the setting of GPIO pins with callbacks
as the drivers can access a GPIO offset on a named gpio_chip
directly with gpio_find_by_chip_name().
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-3430sdp.c | 13 -
arch/arm/mach-omap2/board-cm-t35.c |8 ++--
arch/arm/mach-omap2/board-devkit8000.c |7 ++-
arch/arm/mach-omap2/board-igep0020.c |8 ++--
arch/arm/mach-omap2/board-omap3beagle.c |9 +++--
arch/arm/mach-omap2/board-omap3evm.c |8 ++--
arch/arm/mach-omap2/board-omap3pandora.c | 13 -
arch/arm/mach-omap2/board-omap3stalker.c |8 ++--
arch/arm/mach-omap2/board-omap3touchbook.c |7 ++-
arch/arm/mach-omap2/board-zoom-peripherals.c |7 ++-
10 files changed, 25 insertions(+), 63 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index da75f23..238b95a 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -231,14 +231,16 @@ static struct omap2_hsmmc_info mmc[] = {
* so the SIM card isn't used; else 4 bits.
*/
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
+ .gpiochip_cd= twl4030_gpio,
+ .gpio_cd= 0,/* mmc0_cd offset in twl4030 */
.gpio_wp= 4,
- .deferred = true,
},
{
.mmc= 2,
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
+ .gpiochip_cd= twl4030_gpio,
+ .gpio_cd= 1,/* mmc1_cd offset in twl4030 */
.gpio_wp= 7,
- .deferred = true,
},
{} /* Terminator */
};
@@ -246,13 +248,6 @@ static struct omap2_hsmmc_info mmc[] = {
static int sdp3430_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
- /* gpio + 0 is mmc0_cd (input/IRQ),
-* gpio + 1 is mmc1_cd (input/IRQ)
-*/
- mmc[0].gpio_cd = gpio + 0;
- mmc[1].gpio_cd = gpio + 1;
- omap_hsmmc_late_init(mmc);
-
/* gpio + 7 is sub_lcd_en_bkl (output/PWM1) */
gpio_request_one(gpio + 7, GPIOF_OUT_INIT_LOW, sub_lcd_en_bkl);
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 49e6405..26466f3 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -411,9 +411,9 @@ static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
.caps = MMC_CAP_4_BIT_DATA,
- .gpio_cd= -EINVAL,
+ .gpiochip_cd= twl4030_gpio,
+ .gpio_cd= 0,/* mmc0_cd offset in twl4030 */
.gpio_wp= -EINVAL,
- .deferred = true,
},
{
.mmc= 2,
@@ -469,10 +469,6 @@ static int cm_t35_twl_gpio_setup(struct device *dev,
unsigned gpio,
pr_err(CM-T35: could not obtain gpio for WiFi reset\n);
}
- /* gpio + 0 is mmc0_cd (input/IRQ) */
- mmc[0].gpio_cd = gpio + 0;
- omap_hsmmc_late_init(mmc);
-
return 0;
}
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 11cd2a8..b250999 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -99,8 +99,9 @@ static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
+ .gpiochip_cd= twl4030_gpio,
+ .gpio_cd= 0,/* mmc0_cd offset in twl4030 */
.gpio_wp= 29,
- .deferred = true,
},
{} /* Terminator */
};
@@ -227,10 +228,6 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
{
int ret;
- /* gpio + 0 is mmc0_cd (input/IRQ) */
- mmc[0].gpio_cd = gpio + 0;
- omap_hsmmc_late_init(mmc);
-
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index e558800..d39f016 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -293,9 +293,9 @@ static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
.caps = MMC_CAP_4_BIT_DATA,
- .gpio_cd= -EINVAL,
+ .gpiochip_cd= twl4030_gpio,
+ .gpio_cd= 0,/* mmc0_cd offset in twl4030 */
.gpio_wp= -EINVAL,
- .deferred
[PATCH 4/4] mmc: omap_hsmmc: Simplify init for twl6030 MMC card detect
There's no need to use callbacks for this, we can
do it directly between MMC driver and twl6030.
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Chris Ball c...@laptop.org
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c| 45 +---
arch/arm/mach-omap2/board-omap4panda.c | 52 +---
drivers/mfd/twl6030-irq.c | 33 +---
drivers/mmc/host/omap_hsmmc.c | 31 +++
4 files changed, 48 insertions(+), 113 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 09ae257..c31efa4 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -455,49 +455,6 @@ static struct platform_device omap_vwlan_device = {
},
};
-static int omap4_twl6030_hsmmc_late_init(struct device *dev)
-{
- int ret = 0;
- struct platform_device *pdev = container_of(dev,
- struct platform_device, dev);
- struct omap_mmc_platform_data *pdata = dev-platform_data;
-
- /* Setting MMC1 Card detect Irq */
- if (pdev-id == 0) {
- ret = twl6030_mmc_card_detect_config();
- if (ret)
- pr_err(Failed configuring MMC1 card detect\n);
- pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
- MMCDETECT_INTR_OFFSET;
- pdata-slots[0].card_detect = twl6030_mmc_card_detect;
- }
- return ret;
-}
-
-static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
-{
- struct omap_mmc_platform_data *pdata;
-
- /* dev can be null if CONFIG_MMC_OMAP_HS is not set */
- if (!dev) {
- pr_err(Failed %s\n, __func__);
- return;
- }
- pdata = dev-platform_data;
- pdata-init = omap4_twl6030_hsmmc_late_init;
-}
-
-static int __init omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info
*controllers)
-{
- struct omap2_hsmmc_info *c;
-
- omap_hsmmc_init(controllers);
- for (c = controllers; c-mmc; c++)
- omap4_twl6030_hsmmc_set_late_init(c-pdev-dev);
-
- return 0;
-}
-
static struct regulator_init_data sdp4430_vaux1 = {
.constraints = {
.min_uV = 100,
@@ -906,7 +863,7 @@ static void __init omap_4430sdp_init(void)
omap_serial_init();
omap_sdrc_init(NULL, NULL);
omap4_sdp4430_wifi_init();
- omap4_twl6030_hsmmc_init(mmc);
+ omap_hsmmc_init(mmc);
usb_musb_init(musb_board_data);
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 7ca7a5c..8cf4e54 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -153,8 +153,8 @@ static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
- .gpio_wp= -EINVAL,
.gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
},
{
.name = wl1271,
@@ -204,54 +204,6 @@ struct wl12xx_platform_data omap_panda_wlan_data
__initdata = {
.board_ref_clock = 2,
};
-static int omap4_twl6030_hsmmc_late_init(struct device *dev)
-{
- int ret = 0;
- struct platform_device *pdev = container_of(dev,
- struct platform_device, dev);
- struct omap_mmc_platform_data *pdata = dev-platform_data;
-
- if (!pdata) {
- dev_err(dev, %s: NULL platform data\n, __func__);
- return -EINVAL;
- }
- /* Setting MMC1 Card detect Irq */
- if (pdev-id == 0) {
- ret = twl6030_mmc_card_detect_config();
-if (ret)
- dev_err(dev, %s: Error card detect config(%d)\n,
- __func__, ret);
-else
- pdata-slots[0].card_detect = twl6030_mmc_card_detect;
- }
- return ret;
-}
-
-static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
-{
- struct omap_mmc_platform_data *pdata;
-
- /* dev can be null if CONFIG_MMC_OMAP_HS is not set */
- if (!dev) {
- pr_err(Failed omap4_twl6030_hsmmc_set_late_init\n);
- return;
- }
- pdata = dev-platform_data;
-
- pdata-init = omap4_twl6030_hsmmc_late_init;
-}
-
-static int __init omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info
*controllers)
-{
- struct omap2_hsmmc_info *c;
-
- omap_hsmmc_init(controllers);
- for (c = controllers; c-mmc; c++)
- omap4_twl6030_hsmmc_set_late_init(c-pdev-dev);
-
- return 0;
-}
-
/* Panda board uses the common PMIC configuration */
static struct
[PATCH 2/4] mmc: omap_hsmmc: Use gpio_find_by_chip_name() for omap_hsmmc_gpio_init()
Use gpio_find_by_chip_name() to find the GPIO pins as they can
be dynamically allocated on various gpio_chips.
Note that we don't want to touch the platform data as it can
now specify the GPIO offset on a named gpio_chip.
This removes the need to use callbacks to set the GPIO pins
in platform data.
Cc: Chris Ball c...@laptop.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/hsmmc.c |3 +
arch/arm/mach-omap2/hsmmc.h |5 ++
arch/arm/plat-omap/include/plat/mmc.h |3 +
drivers/gpio/gpio-twl4030.c |2 +
drivers/mmc/host/omap_hsmmc.c | 109 +
5 files changed, 82 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index a97876d..dda88f7 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -323,7 +323,10 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
mmc-get_context_loss_count = hsmmc_get_context_loss;
+ mmc-slots[0].gpiochip_cd = c-gpiochip_cd;
mmc-slots[0].switch_pin = c-gpio_cd;
+
+ mmc-slots[0].gpiochip_wp = c-gpiochip_wp;
mmc-slots[0].gpio_wp = c-gpio_wp;
mmc-slots[0].remux = c-remux;
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index 07831cc..ffbb78d 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -22,8 +22,13 @@ struct omap2_hsmmc_info {
boolno_off_init;/* no power off when not in MMC sleep state */
boolvcc_aux_disable_is_sleep; /* Regulator off remapped to sleep */
booldeferred; /* mmc needs a deferred probe */
+
+ char*gpiochip_cd; /* Optional gpiochip for gpio_cd */
int gpio_cd;/* or -EINVAL */
+
+ char*gpiochip_wp; /* Optional gpiochip for gpio_wp */
int gpio_wp;/* or -EINVAL */
+
char*name; /* or NULL for default */
struct platform_device *pdev; /* mmc controller instance */
int ocr_mask; /* temporary HACK */
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index f75946c..cbfbdc3 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -130,7 +130,10 @@ struct omap_mmc_platform_data {
#define HSMMC_HAS_UPDATED_RESET(1 1)
unsigned features;
+ char *gpiochip_cd; /* optional gpiochip for card
detect */
int switch_pin; /* gpio (card detect) */
+
+ char *gpiochip_wp; /* optional gpiochip for write
protect */
int gpio_wp;/* gpio (write protect) */
int (*set_bus_mode)(struct device *dev, int slot, int bus_mode);
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index b8b4f22..d0f266c 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -391,6 +391,7 @@ static int __devinit gpio_twl4030_debounce(u32 debounce, u8
mmc_cd)
}
static int gpio_twl4030_remove(struct platform_device *pdev);
+static struct platform_driver gpio_twl4030_driver;
static int __devinit gpio_twl4030_probe(struct platform_device *pdev)
{
@@ -430,6 +431,7 @@ no_irqs:
pdata-debounce, pdata-mmc_cd,
ret);
+ twl_gpiochip.label = gpio_twl4030_driver.driver.name;
twl_gpiochip.base = pdata-gpio_base;
twl_gpiochip.ngpio = TWL4030_GPIO_MAX;
twl_gpiochip.dev = pdev-dev;
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index fd0c661..1aa2420 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -176,6 +176,8 @@ struct omap_hsmmc_host {
int use_dma, dma_ch;
int dma_line_tx, dma_line_rx;
int slot_id;
+ int gpio_cd;
+ int gpio_wp;
int got_dbclk;
int response_busy;
int context_loss;
@@ -192,26 +194,29 @@ struct omap_hsmmc_host {
static int omap_hsmmc_card_detect(struct device *dev, int slot)
{
- struct omap_mmc_platform_data *mmc = dev-platform_data;
+ struct omap_hsmmc_host *host =
+ platform_get_drvdata(to_platform_device(dev));
/* NOTE: assumes card detect signal is active-low */
- return !gpio_get_value_cansleep(mmc-slots[0].switch_pin);
+ return !gpio_get_value_cansleep(host-gpio_cd);
}
static int omap_hsmmc_get_wp(struct device *dev, int slot)
{
- struct omap_mmc_platform_data *mmc = dev-platform_data;
+ struct omap_hsmmc_host *host =
+
Re: [PATCH 5/6] ARM: OMAP3: Modify omap_hsmmc_late_init to handle deleting mmc devices
* Rajendra Nayak rna...@ti.com [120224 20:14]: On Saturday 25 February 2012 06:03 AM, Tony Lindgren wrote: Hi, * Rajendra Nayakrna...@ti.com [120224 01:27]: omap_hsmmc_late_init() adds deferred (if any) mmc devices which are dependent on twl4030-gpio device to be available. If twl4030-gpio is built as a module and inserted and deleted multiple times, the mmc devices also should be added and deleted accordingly. Split omap_hsmmc_late_init() into omap_hsmmc_deferred_add() and omap_hsmmc_deferred_del() to handle this. The .setup board hook for twl4030-gpio handles the runtime adding on deferred mmc devices. Similarly a .teardown board hook for twl4030-gpio should handle the runtime deletion by calling omap_hsmmc_deferred_del(). This is done for all existing omap3 boards in subsequent patches. This gets complex.. But I think I've found a simpler way where we can use the twl gpio offsets and let the drivers take care of the rest. I'll post some patches hopefully on Monday. I agree it gets complex. If you have a simpler way to handle this, that would be great. Posted now, sorry it too a bit longer, I got distracted with other stuff. The thread is [PATCH 0/4] Start getting rid of pdata callbacks with gpio_find_by_chip_name(). Some further testing would be appreciated. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
omap4 rotation support
Hello, I have a variscite OM44 (omap4 4460 SOM) that I need to rotate the display on but I cannot make it work. I am currently using kernel 3.1.5 and the Ubuntu 11.10 from Linaro. I have tried each of these ways to make it work: 1. From the command line as root the command 'xrandr -o left' This fails with an error 2. From uboot I tried adding: 'omapfb.tiler=y omapfb.mirror=y omapfb.rotate=1' This seems to have no effect at all. I also tried using omapdss instead of omapfb in the above three lines, but I am not certain which is correct for what. I saw a comment that omap dss rotate does not work for omap4 for Linux but does work for Android. Bummer. 3. I tried steps from this website: http://omappedia.org/wiki/Bootargs_for_enabling_display echo 1 /sys/class/graphics/fb0/mirror (this fails because mirror does not exist) cat /sys/class/graphics/fb0/rotate_type (this fails because rotate_type does not exist) echo 1 /sys/class/graphics/fb0/rotate (as root this seems to be accepted, but nothing happens. Tried stopping lightdm before and restarting after this command but no effect) Can anyone say if this should be possible (and in what kernel or uboot versions) or perhaps more important WHEN it might be usable? Thanks, Jeff -- 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] cpufreq: OMAP: specify range for voltage scaling
Afzal Mohammed af...@ti.com writes:
Specify voltage in ranges for regulator. Range
used is tolerance specified for OPP.
This helps to achieve DVFS with a wider range of
regulators.
Cc: Kevin Hilman khil...@ti.com
Cc: Sekhar Nori nsek...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
Thanks, will queue this with the CPUfreq changes for MPU DVFS.
Kevin
---
Hi,
Tolerance specified here is that of AM335X, least value
of tolerance that I could find so far for OMAP family
This applies on top of Kevin Hilman's patch (v2),
cpufreq: OMAP: scale voltage along with frequency
http://www.spinics.net/lists/linux-omap/msg65002.html
Regards
Afzal
drivers/cpufreq/omap-cpufreq.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 10b8e23..3cea51b 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -38,6 +38,9 @@
#include mach/hardware.h
+/* OPP tolerance in percentage */
+#define OPP_TOLERANCE 4
+
#ifdef CONFIG_SMP
struct lpj_info {
unsigned long ref;
@@ -81,7 +84,7 @@ static int omap_target(struct cpufreq_policy *policy,
int r, ret = 0;
struct cpufreq_freqs freqs;
struct opp *opp;
- unsigned long freq, volt = 0, volt_old = 0;
+ unsigned long freq, volt = 0, volt_old = 0, tol = 0;
if (!freq_table) {
dev_err(mpu_dev, %s: cpu%d: no freq table!\n, __func__,
@@ -125,6 +128,7 @@ static int omap_target(struct cpufreq_policy *policy,
return -EINVAL;
}
volt = opp_get_voltage(opp);
+ tol = volt * OPP_TOLERANCE / 100;
volt_old = regulator_get_voltage(mpu_reg);
}
@@ -134,7 +138,7 @@ static int omap_target(struct cpufreq_policy *policy,
/* scaling up? scale voltage before frequency */
if (mpu_reg (freqs.new freqs.old)) {
- r = regulator_set_voltage(mpu_reg, volt, volt);
+ r = regulator_set_voltage(mpu_reg, volt - tol, volt + tol);
if (r 0) {
dev_warn(mpu_dev, %s: unable to scale voltage up.\n,
__func__);
@@ -147,7 +151,7 @@ static int omap_target(struct cpufreq_policy *policy,
/* scaling down? scale voltage after frequency */
if (mpu_reg (freqs.new freqs.old)) {
- r = regulator_set_voltage(mpu_reg, volt, volt);
+ r = regulator_set_voltage(mpu_reg, volt - tol, volt + tol);
if (r 0) {
dev_warn(mpu_dev, %s: unable to scale voltage down.\n,
__func__);
--
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] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
Matt Porter mpor...@ti.com writes:
This fixes smsc911x support on platforms using gpmc_smsc911x_init().
Commit c7e963f616 (net/smsc911x: Add regulator support) added
the requirement that platforms provide vdd33a and vddvario supplies.
Signed-off-by: Matt Porter mpor...@ti.com
[...]
/*
* Initialize smsc911x device connected to the GPMC. Note that we
* assume that pin multiplexing is done in the board-*.c file,
@@ -55,6 +101,12 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_cfg = board_data;
+ ret = platform_device_register(gpmc_smsc911x_regulator);
+ if (ret 0) {
+ pr_err(Unable to register smsc911x regulators: %d\n, ret);
+ return;
+ }
+
Boards that have more than one instance of the smsc911x (OMAP3/Overo)
barf here because of trying to register the same device twice.
We need something like the patch below to make Overo boot again.
Kevin
From 4114dea2fb897ab75d05eaa943d29454034fc025 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Thu, 1 Mar 2012 12:30:42 -0800
Subject: [PATCH] ARM: OMAP2+: gpmc-smsc911x: only register regulators once
commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add required smsc911x
regulators) added regulators which are registered during
gpmc_smsc911x_init(). However, some platforms (OMAP3/Overo) have more
than one instance of the SMSC911x and result in attempting to register
the same regulator more than once which causes a panic(). Fix this by
tracking the regulator registration ensuring only a single device is
registered.
Cc: Matt Porter mpor...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/gpmc-smsc911x.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index bbb870c..95e6c7d 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -88,6 +88,8 @@ static struct platform_device gpmc_smsc911x_regulator = {
},
};
+static bool regulator_registered;
+
/*
* Initialize smsc911x device connected to the GPMC. Note that we
* assume that pin multiplexing is done in the board-*.c file,
@@ -101,10 +103,14 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_cfg = board_data;
- ret = platform_device_register(gpmc_smsc911x_regulator);
- if (ret 0) {
- pr_err(Unable to register smsc911x regulators: %d\n, ret);
- return;
+ if (!regulator_registered) {
+ ret = platform_device_register(gpmc_smsc911x_regulator);
+ if (ret 0) {
+ pr_err(Unable to register smsc911x regulators: %d\n,
+ ret);
+ return;
+ }
+ regulator_registered = true;
}
if (gpmc_cs_request(gpmc_cfg-cs, SZ_16M, cs_mem_base) 0) {
--
1.7.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/9] cpuidle: Add common time keeping and irq enabling
Hello Deepthi, On Wed, Feb 29, 2012 at 10:15 PM, Deepthi Dharwar deep...@linux.vnet.ibm.com wrote: Hi Rob, On 03/01/2012 06:12 AM, Robert Lee wrote: Make necessary changes to implement time keeping and irq enabling in the core cpuidle code. This will allow the removal of these functionalities from various platform cpuidle implementations whose timekeeping and irq enabling follows the form in this common code. The generic cpuidle changes look good, but is there a reason as to why these changes are enabled only for ARM and not other archs ? Besides ARM, this patchset also enables some of this new consolidation functionality on arch/SH and for archs that use the CONFIG_ARCH_HAS_CPU_RELAX (maybe x86 uses this?). For the powerpc P-series, it could probably could be modified to use the consolidated timekeeping but I didn't feel comfortable making that change myself for a couple of reasons. First, the common wrapper also includes the local_irq_enable() call, but the p-series cpuidle code doesn't include this call, as instead, it relies on the local_irq_enable() call in the cpu_idle() function in arch/powerpc/kernel/idle.c. Is it OK to remove this local_irq_enable() once the wrapper is used? Second, is there any special coordination needed with the timekeeping functions and the mfspr() calls? Looking at the intel and acpi cpuidle implementations, their current organization does seem to be able to use the common time keeping / irq enabling wrapper. Upon first glance, it appears that there are special timer/timekeeping requirements for x86 that aren't required by other platforms. But that may not be correct. If you look back at v4 of this patch series, you'll see an attempt at a common timekeeping that could be used by x86 and acpi , but it causes other compromises that to me aren't worth the extra gain from a 100% common timekeeping / irq enable solution. I requested feedback/opinions on this issue after v4 but didn't hear anything about changes made to the intel or acpi implementations. So I continued on with the common wrapper direction from v3 when making v5. Ultimately, even if the consolidated code only can be used by most and not all arch or platform cpuidle implementations, it still reduces some platform cpuidle fragmentation and duplicated code and hopefully improves the maintainability of the core cpuidle. -- 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] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
Hi,
On Thu, Mar 01, 2012 at 12:36:57PM -0800, Kevin Hilman wrote:
Matt Porter mpor...@ti.com writes:
This fixes smsc911x support on platforms using gpmc_smsc911x_init().
Commit c7e963f616 (net/smsc911x: Add regulator support) added
the requirement that platforms provide vdd33a and vddvario supplies.
Signed-off-by: Matt Porter mpor...@ti.com
[...]
/*
* Initialize smsc911x device connected to the GPMC. Note that we
* assume that pin multiplexing is done in the board-*.c file,
@@ -55,6 +101,12 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_cfg = board_data;
+ ret = platform_device_register(gpmc_smsc911x_regulator);
+ if (ret 0) {
+ pr_err(Unable to register smsc911x regulators: %d\n, ret);
+ return;
+ }
+
Boards that have more than one instance of the smsc911x (OMAP3/Overo)
barf here because of trying to register the same device twice.
We need something like the patch below to make Overo boot again.
Kevin
From 4114dea2fb897ab75d05eaa943d29454034fc025 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Thu, 1 Mar 2012 12:30:42 -0800
Subject: [PATCH] ARM: OMAP2+: gpmc-smsc911x: only register regulators once
commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add required smsc911x
regulators) added regulators which are registered during
gpmc_smsc911x_init(). However, some platforms (OMAP3/Overo) have more
than one instance of the SMSC911x and result in attempting to register
the same regulator more than once which causes a panic(). Fix this by
tracking the regulator registration ensuring only a single device is
registered.
Cc: Matt Porter mpor...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/gpmc-smsc911x.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index bbb870c..95e6c7d 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -88,6 +88,8 @@ static struct platform_device gpmc_smsc911x_regulator = {
},
};
+static bool regulator_registered;
+
/*
* Initialize smsc911x device connected to the GPMC. Note that we
* assume that pin multiplexing is done in the board-*.c file,
@@ -101,10 +103,14 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_cfg = board_data;
- ret = platform_device_register(gpmc_smsc911x_regulator);
- if (ret 0) {
- pr_err(Unable to register smsc911x regulators: %d\n, ret);
- return;
+ if (!regulator_registered) {
+ ret = platform_device_register(gpmc_smsc911x_regulator);
+ if (ret 0) {
+ pr_err(Unable to register smsc911x regulators: %d\n,
+ret);
+ return;
+ }
+ regulator_registered = true;
Wow, this is quite a hack. Is the regulator part of the SMSC911x device
or is it outside ? If it's outside the SMSC91xx (which I believe it is)
there should be a regulator driver instead of this hack. For boards
which don't provide such a regulator (and tie the supply pin to some
constant voltage source) there should be a constant regulator supplying
the pin. But this patch is quite hacky.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v7 0/9] Consolidate cpuidle functionality
On Wed, Feb 29, 2012 at 6:42 PM, Robert Lee rob@linaro.org wrote: This patch series moves various functionality duplicated in platform cpuidle drivers to the core cpuidle driver. Also, the platform irq disabling was removed as it appears that all calls into cpuidle_call_idle will have already called local_irq_disable(). I'm told that I forgot to add the Acks from the previous v6 to this version: Acked-by: Jean Pihet j-pi...@ti.com (v6) Tested-by: Jean Pihet j-pi...@ti.com (v6, omap3) Tested-by: Amit Daniel amit.kach...@linaro.org (v6, Exynos4) For the generic cpuidle changes: Reviewed-by: Deepthi Dharwar deep...@linux.vnet.ibm.com If anyone sees other omissions or has any suggested changes or improvements in my patch submissions semantics, please let me know. Thanks, Rob Rafael, Could you review this patchset and merge patch 1/9 once its ready? It seems pretty close to being acceptable. The get_maintainer script shows Len Brown as the cpuidle maintainer but I've been unable to get a response from him so far. If you are not the right person, could you suggest who I can make this request to? Thanks. Note to platform maintainers: Platform patches (2/9 to 9/9) in this patchset are not required to work with patch 1/9 but please review and push these platform changes as possible to allow this consolidation to occur. Based on 3.3-rc5 plus recent exynos cpuidle patch (affects exynos cpuidle only): http://www.spinics.net/lists/linux-samsung-soc/msg09467.html v6 submission tested successfully on Exynos (thanks Amit Kacchap) and OMAP3 (thanks Jean Pihet) platforms. v6 submission can be found here: http://www.spinics.net/lists/arm-kernel/msg162018.html Changes since v6: * Made some struct whitespace alignment changes. * Fixed a coding style violation (thanks Jean Pihet) * Fixed a bug in davinci cpuidle (thanks Jean Pihet) * Corrected the common ARM cpuidle WFI state description to be ARM platform agnostic (thanks Kevin Hilman) * Fixed the problem causing x86 and PPC builds to fail (thanks Deepthi) * Re-added a line of code that was mistakenly removed (thanks Deepthi) Robert Lee (9): cpuidle: Add common time keeping and irq enabling ARM: at91: Consolidate time keeping and irq enable ARM: exynos: Consolidate time keeping and irq enable ARM: kirkwood: Consolidate time keeping and irq enable ARM: davinci: Consolidate time keeping and irq enable ARM: omap: Consolidate OMAP3 time keeping and irq enable ARM: omap: Consolidate OMAP4 time keeping and irq enable ARM: shmobile: Consolidate time keeping and irq enable SH: shmobile: Consolidate time keeping and irq enable arch/arm/include/asm/cpuidle.h | 22 + arch/arm/kernel/Makefile | 2 +- arch/arm/kernel/cpuidle.c | 21 arch/arm/mach-at91/cpuidle.c | 67 ++- arch/arm/mach-davinci/cpuidle.c | 82 +--- arch/arm/mach-exynos/cpuidle.c | 53 ++--- arch/arm/mach-kirkwood/cpuidle.c | 72 arch/arm/mach-omap2/cpuidle34xx.c | 42 +++-- arch/arm/mach-omap2/cpuidle44xx.c | 21 +--- arch/arm/mach-shmobile/cpuidle.c | 31 +++-- arch/sh/kernel/cpu/shmobile/cpuidle.c | 10 +--- drivers/cpuidle/cpuidle.c | 79 +-- include/linux/cpuidle.h | 13 +- 13 files changed, 233 insertions(+), 282 deletions(-) create mode 100644 arch/arm/include/asm/cpuidle.h create mode 100644 arch/arm/kernel/cpuidle.c -- 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
MMC read errors
I'm seeing weird read errors on a DM3730. Has anyone seen anything like this before? Environment: factory images from http://cumulus.gumstix.org/images/angstrom/factory/2011-08-30-1058/ loaded onto and MMC card on a Gumstix WaterStorm on a Chestnut board Commands: dd if=/dev/urandom of=garbage bs=1024 count=1048576 while true; do md5sum garbage; done example output: 99e983a8f17f3258ddaff73bf622db47 garbage 99e983a8f17f3258ddaff73bf622db47 garbage 99e983a8f17f3258ddaff73bf622db47 garbage 99e983a8f17f3258ddaff73bf622db47 garbage 99e983a8f17f3258ddaff73bf622db47 garbage 4dee7d74d6d8013291b48d955ea7af1f garbage 99e983a8f17f3258ddaff73bf622db47 garbage 99e983a8f17f3258ddaff73bf622db47 garbage 99e983a8f17f3258ddaff73bf622db47 garbage 99e983a8f17f3258ddaff73bf622db47 garbage 99e983a8f17f3258ddaff73bf622db47 garbage dmesg has nothing interesting. Any clues? root@overo:~# cat /proc/version Linux version 2.6.39 (neil@cumulus) (gcc version 4.3.3 (GCC) ) #1 Mon Aug 15 19:04:09 PDT 2011 Although I've also seen similar behavior on a recent 3.2 kernel using oe-core. --Adam -- 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] cpufreq: OMAP: specify range for voltage scaling
+Tero Kevin Hilman khil...@ti.com writes: Afzal Mohammed af...@ti.com writes: Specify voltage in ranges for regulator. Range used is tolerance specified for OPP. This helps to achieve DVFS with a wider range of regulators. Cc: Kevin Hilman khil...@ti.com Cc: Sekhar Nori nsek...@ti.com Signed-off-by: Afzal Mohammed af...@ti.com Thanks, will queue this with the CPUfreq changes for MPU DVFS. Actually, not quite yet... After some testing with the SMPS regulators, this won't quite work with the current SMPS regulators. Does this actually work with the regulators you're using? For OMAPs using VC/VP for voltage scaling, the TWL regulator passes on the voltage requested directly to the voltage layer. When using voltage - tolerance, this results in voltages that the voltage layer doesn't know about because they do not match any of the voltages from the known OPPs. The problem that we have is that while the regulators can support a broad range of voltages (from min to max with a some step), the on-chip voltage domains cannot, which is why we have defined the OPPs which are known to work. Tero, for the SMPS regulators, would it be possible to configure the regulators so that only a discrete set voltages are availble to pick from? These should be initialied from the OPP layer. Somehow we need to support something like $SUBJECT patch in order to support a broad range of regulators. The OMAP voltagedomain limitations need to configured in platform specific way such that the CPUfreq driver can remain generic. 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: [GIT PULL 3/5] First set of omap1 related changes
On Wed, 29 Feb 2012 13:13:31 Tony Lindgren wrote: * Arnd Bergmann a...@arndb.de [120229 12:35]: On Wednesday 29 February 2012, Tony Lindgren wrote: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap omap1 Janusz Krzysztofik (7): ARM: OMAP1: ams-delta: register latch dependent devices later ARM: OMAP1: ams-delta: convert latches to basic_mmio_gpio ARM: OMAP1: ams-delta: supersede custom led device by leds- gpio LED: drop leds-ams-delta driver MTD: NAND: ams-delta: use GPIO instead of custom I/O omapfb: lcd_ams_delta: drive control lines over GPIO input: serio: ams-delta: toggle keyboard power over GPIO Since these are all for ams-delta, I pulled them into next/boards together with other board specific updates. OK makes sense. Any chance for the continuation series [1] as well as two section mismatch related fixes [2] [3] getting your attention? NB, that continuation series needs another section mismatch fix, which I was planing to submit once there was a stable base for it. Thanks, Janusz [1] http://www.spinics.net/lists/linux-omap/msg64146.html [2] http://www.spinics.net/lists/linux-omap/msg64441.html [3] http://www.spinics.net/lists/linux-omap/msg64442.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 4/6] ARM: OMAP3 PM: Enable IO Wake up
Rajendra Nayak rna...@ti.com writes: On Wednesday 29 February 2012 07:56 PM, Tero Kristo wrote: From: Vishwanath BSvishwanath...@ti.com Enable IO Wake up for OMAP3 as part of PM Init. Currently this has been managed in cpuidle path which is not the right place. Subsequent patch will remove IO Daisy chain handling in cpuidle path once daisy chain is handled as part of hwmod mux. Signed-off-by: Vishwanath BSvishwanath...@ti.com Tested-by: Govindraj.Rgovindraj.r...@ti.com Signed-off-by: Tero Kristot-kri...@ti.com --- arch/arm/mach-omap2/pm34xx.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index e97ec3f..e6c2d39 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -793,6 +793,10 @@ static int __init omap3_pm_init(void) goto err1; } +if (omap3_has_io_wakeup()) +omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD, + PM_WKEN); On OMAP4 this GLOBAL IO chain enable happens as part of the trigger function itself, it might make sense to do that for OMAP3 too to avoid similar issues as seen on OMAP4 when the GLOBAL switch is enabled too late in boot. The best however would be to get rid of it in the trigger function and enable this early during PM init, but I am not sure whats a good place to do this 'early' enough. What about the subsys_initcall() that's already in the prm*.c files? IMO, the global one-time init doesn't belong in the trigger function because there's no need to do the extra PRM read/write when it should be a one-shot init. 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
Ethernet problems on AM3517, possible regression?
We have both a CompuLab CM-T3517 and a Technexion TAM-3517 at the shop. Both boards provide dual Ethernet support in an identical fashion. One port uses the onboard EMAC tied to an SMSC LAN87xx series PHY. The other is the old trusty SMSC LAN911X hooked up to the GPMC. Both boards support both interfaces when loaded with their respective TI PSP-based images. These unfortunately date clear back to 2.6.37 or even 2.6.32 however. When upgrading to the 3.x series linux-omap kernel, we noticed we could get one or the other of these to work, _but not both simultaneously_. If both are enabled in code, neither work. Even when we can get one or the other working, we seem to be having some problems with autonegotiation and MAC addressing. MAC addresses on the SMSC are still random. On the EMAC port, as you can see from our code below, we have put a patch in that is letting us establish a fixed MAC address. However, I'm not sure this is a proper method to use at this point. We suspect issues are known to exist with the Ethernet ports as the CM-T3517 has mainlined Linux support, and its latest board file does not show any configuration for either Ethernet interface. Support from the previous kernel versions has apparently been removed, despite patches being applied to it as recently as mid-last year: http://lists.infradead.org/pipermail/linux-arm-kernel/2011-May/050430.html We also suspect this is being caused by an address conflict of some sort between the two ports. We are using a linux-omap kernel, version 3.2.0-rc6 that is a month or two old now. We've been monitoring this list, and have noted that some changes have been checked in for SMSC, but have not been able to update our kernel source as we were in the midst of a heavy debugging exercise that ended late last evening. We plan to migrate to the latest HEAD soon. Neverthelss, we've not seen any of these board files update. So, we're assuming there are still known issues here. I have attached the relevant sections of the board file we've created for the TAM-3517 (the one we've played with the most) below. It is based off the older board files from the TI PSP and various configurations we have seen in similar hardware board files (overo, am3517_evm, cm-t3517, etc.) If you note the configurable defines at the top, we've tied various combinations of code with no success to date. Would you folks please take a look? Any help would be appreciated. Thanks! - __NOTES:__ ***When we run with just the SMSC enabled, the device works: ... [ 1.119415] smsc911x: Driver version 2008-10-21 [ 1.126739] smsc911x-mdio: probed [ 1.130554] smsc911x smsc911x: eth0: attached PHY driver [SMSC LAN8700] (mii_bus:phy_addr=:01, irq=-1) [ 1.142456] smsc911x smsc911x: eth0: MAC Address: d6:b4:7d:2c:03:40 ... root@board:~# ifdown eth0 root@board:~# ifup eth0 [ 187.145019] smsc911x smsc911x: eth0: SMSC911x/921x identified at 0xd086e000, IRQ: 313 ... (*NOTE: the MAC address is random!) ***When we run with just the EMAC enabled, the device works: ... [ 1.184112] davinci_mdio davinci_mdio.0: davinci mdio revision 1.5 [ 1.190612] davinci_mdio davinci_mdio.0: detected phy mask fffe [ 1.197998] davinci_mdio.0: probed [ 1.201690] davinci_mdio davinci_mdio.0: phy[0]: device 0:00, driver SMSC LAN8710/LAN8720 ... [ 213.613555] davinci_mdio davinci_mdio.0: resetting idled controller [ 213.621704] net eth0: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=0:00, id=7c0f1) [ 215.621917] PHY: 0:00 - Link is Up - 100/Full ... *** When we run with BOTH enabled, they show in boot but neither works: [ 1.135864] smsc911x: Driver version 2008-10-21 [ 1.143249] smsc911x-mdio: probed [ 1.147064] smsc911x smsc911x: eth0: attached PHY driver [SMSC LAN8700] (mii_bus:phy_addr=:01, irq=-1) [ 1.158966] smsc911x smsc911x: eth0: MAC Address: 7e:92:21:13:be:ec [ 1.207580] davinci_mdio davinci_mdio.0: davinci mdio revision 1.5 [ 1.214080] davinci_mdio davinci_mdio.0: detected phy mask fffe [ 1.221405] davinci_mdio.0: probed [ 1.225097] davinci_mdio davinci_mdio.0: phy[0]: device 0:00, driver SMSC LAN8710/LAN8720 ... root@board:~# ifup eth0 ifconfig: SIOCSIFFLAGS: Input/output error ifconfig: SIOCSIFFLAGS: Input/output error ... root@board:~# ifup eth1 [ 1034.624603] net eth1: PHY already attached [ 1034.628936] net eth1: could not connect to phy :01 - /* * linux/arch/arm/mach-omap2/board-tam3517.c * * Copyright (C) 2011 * Author: Technexion + others * * Based on mach-omap2/board-tam3517.c from Technexion BSP release * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General
Re: [GIT PULL 3/5] First set of omap1 related changes
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [120301 13:56]: Any chance for the continuation series [1] as well as two section mismatch related fixes [2] [3] getting your attention? NB, that continuation series needs another section mismatch fix, which I was planing to submit once there was a stable base for it. [1] http://www.spinics.net/lists/linux-omap/msg64146.html [2] http://www.spinics.net/lists/linux-omap/msg64441.html [3] http://www.spinics.net/lists/linux-omap/msg64442.html Hmm sorry I guess I was waiting for the missing section mismatch patch. I've pushed ams-delta branch that's based on -rc5 merged with what Arnd pulled yesterday as -rc1 has i2c-omap.c a compile bug for omap1. I've applied these two patches there as the second one depends on what got pulled: ARM: OMAP1: ams-delta: clean up init data section assignments ARM: OMAP1: ams-delta: fix incorrect section tags Looks like your patch ARM: OMAP1: ams-delta: set up regulator over modem reset GPIO pin causes the following error with CONFIG_DEBUG_SECTION_MISMATCH=y: arch/arm/mach-omap1/board-ams-delta.c:273:36: error: modem_nreset_config causes a section type conflict So care to update and repost that (and possibly the following two patches) with your missing fixes? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cbus: Fix lines for Nokia 770
* Felipe Balbi ba...@ti.com [120223 00:15]:
Hi,
On Wed, Feb 22, 2012 at 02:09:37PM -0800, Tony Lindgren wrote:
From 54c4785b8d274f8d282b4243945ae0b17edf4686 Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Wed, 22 Feb 2012 13:03:07 -0800
Subject: [PATCH] cbus: Fix lines for Nokia 770
This makes retu and tahvo work again on Nokia 770 so it
stays running.
Signed-off-by: Tony Lindgren t...@atomide.com
---
I applied this into cbus branch as it seems to fix retu
watchdog for Nokia 770.
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -87,9 +87,9 @@ static struct platform_device nokia770_kp_device = {
#if defined(CONFIG_CBUS) || defined(CONFIG_CBUS_MODULE)
static struct cbus_host_platform_data nokia770_cbus_data = {
- .clk_gpio = OMAP_MPUIO(11),
+ .clk_gpio = OMAP_MPUIO(9),
.dat_gpio = OMAP_MPUIO(10),
- .sel_gpio = OMAP_MPUIO(9),
+ .sel_gpio = OMAP_MPUIO(11),
};
static struct platform_device nokia770_cbus_device = {
Has this been wrong since the beginning ? Looking at commit d64193bd, I
just moved whatever was on cbus.c to respective board-files.
Yes I think I dumped them from custom ATAGs quite a while ago,
but probably got them wrong way around at some point and have
been wondering ever since how come cbus does not seem to work
on 770 :)
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: hsmmc: add max_freq field
Hi, * Daniel Mack zon...@gmail.com [120217 05:13]: ping? Could anyone care for queueing this please? I suggest Rajendra queue up omap_hsmmc.c patches as he's already patching it. Regards, Tony On Thu, Dec 29, 2011 at 2:22 PM, Daniel Mack zon...@gmail.com wrote: On 12/23/2011 04:40 PM, T Krishnamoorthy, Balaji wrote: On Wed, Dec 14, 2011 at 6:52 PM, Daniel Mack zon...@gmail.com wrote: diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 101cd31..8215ef9 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1927,8 +1927,12 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) if (mmc_slot(host).vcc_aux_disable_is_sleep) mmc_slot(host).no_off = 1; - mmc-f_min = OMAP_MMC_MIN_CLOCK; - mmc-f_max = OMAP_MMC_MAX_CLOCK; + mmc-f_min = OMAP_MMC_MIN_CLOCK; Stray change for f_min ? No, this was intended. The indentation doesn't make sense anymore when not grouped with the f_max assignment. Other than that, what is necessary to get this picked? Tony? :) Thanks, Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: powerdomain: unwrap and simplify logging strings
On Wed, Feb 29, 2012 at 22:23, Paul Walmsley p...@pwsan.com wrote: b/arch/arm/mach-omap2/powerdomain.c index 8a18d1b..89000d3 100644 --- a/arch/arm/mach-omap2/powerdomain.c +++ b/arch/arm/mach-omap2/powerdomain.c @@ -339,8 +339,8 @@ int pwrdm_add_clkdm(struct powerdomain *pwrdm, struct clockdomain *clkdm) if (!pwrdm || !clkdm) return -EINVAL; - pr_debug(powerdomain: associating clockdomain %s with powerdomain - %s\n, clkdm-name, pwrdm-name); + pr_debug(powerdomain: %s: associating clockdomain %s\n, + clkdm-name, pwrdm-name); while at this, could i suggest having instead: pr_debug(%s: %s: associating clockdomain %s\n, __func__, clkdm-name, pwrdm-name); since the function name helps associate the message back in, wont it be a bit of a dual edged information as well? or even simplify it further with #define pr_fmt(fmt) %s:%s: fmt, powerdomain, __func__ ? Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: hwmod: Use sysc_fields-srst_shift and get rid of hardcoded SYSC_TYPE2_SOFTRESET_MASK
On Thu, 1 Mar 2012, Rajendra Nayak wrote: This is useful when we have broken type2 compliant IPs' where the softreset shift is not the same as SYSC_TYPE2_SOFTRESET_SHIFT and hence is overridden using sysc_fields-srst_shift. We have atleast one such instance now with onchip keypad on OMAP5 which has a different softreset shift as compared to other type2 IPs'. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com Cc: Balaji TK balaj...@ti.com Tested-by: Sourav Poddar sourav.pod...@ti.com --- Paul, I based the patch on top of your reset/data cleanup series for hwmod. So its based on 'hwmod_data_cleanup_3.4' branch. Thanks, Benoît's ack added and queued. - Paul
[PATCH 0/2] ARM: OMAP: OMAP3+ DMA and Device ID Fixes
From: Jon Hunter jon-hun...@ti.com Here are a couple minor OMAP3+ fixes I stumbled across. Jon Hunter (2): ARM: OMAP: DMA: Fix DMA channel end definition for OMAP36xx-PLUS devices ARM: OMAP: Remove definition cpu_is_omap4430() arch/arm/mach-omap2/dma.c |4 ++-- arch/arm/plat-omap/include/plat/cpu.h |2 -- 2 files changed, 2 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP: DMA: Fix DMA channel end definition for OMAP36xx-PLUS devices
From: Jon Hunter jon-hun...@ti.com
I recently noticed there are a couple bugs in the OMAP2-PLUS DMA driver code.
1. The CCDN DMA register is valid for all OMAP devices from OMAP3630 onwards.
For OMAP3630+ devices the CCDN register is the upper register in the DMA
register map and so is used to define the channel end address for a given
DMA channel. Today the driver code is written to only use the CCDN as the
upper address for OMAP3630 and OMAP4430 devices where as it should be used
for all OMAP3630+ devices. Therefore use the CCDN register as the upper
address in the DMA register map for devices OMAP3630 and beyond.
2. The OMAP2 DMA driver is using the macro cpu_is_omap4430() and from reviewing
the plat/cpu.h file I see that cpu_is_omap4430() is defined as 0 even when
CONFIG_ARCH_OMAP4 is defined. This is another bug in of itself (addressed in
the 2nd patch of this series), but the DMA driver should not be using this.
Hence, there is a dependency between this patch and the next.
3. Finally, update the comment for the registers CDP, CNDP and CCDP as registers
for OMAP3630-PLUS devices and not just OMAP4 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/dma.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index a59a45a..4fd26b4 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -81,7 +81,7 @@ static u16 reg_map[] = {
[CCFN] = 0xc0,
[COLOR] = 0xc4,
- /* OMAP4 specific registers */
+ /* OMAP36XX-PLUS specific registers */
[CDP] = 0xd0,
[CNDP] = 0xd4,
[CCDN] = 0xd8,
@@ -227,7 +227,7 @@ static int __init omap2_system_dma_init_dev(struct
omap_hwmod *oh, void *unused)
dma_stride = OMAP2_DMA_STRIDE;
dma_common_ch_start = CSDP;
- if (cpu_is_omap3630() || cpu_is_omap4430())
+ if (!cpu_is_omap24xx() !cpu_is_omap3430())
dma_common_ch_end = CCDN;
else
dma_common_ch_end = CCFN;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: OMAP: Remove definition cpu_is_omap4430()
From: Jon Hunter jon-hun...@ti.com The definition cpu_is_omap4430() always returns 0 even when CONFIG_ARCH_OMAP4 is enabled. This macro should be removed and the macro cpu_is_omap443x() should be used where needed for OMAP4430 devices. Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/plat-omap/include/plat/cpu.h |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index 6b51086..4f18eae 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -250,7 +250,6 @@ IS_AM_SUBCLASS(335x, 0x335) * cpu_is_omap2423(): True for OMAP2423 * cpu_is_omap2430(): True for OMAP2430 * cpu_is_omap3430(): True for OMAP3430 - * cpu_is_omap4430(): True for OMAP4430 * cpu_is_omap3505(): True for OMAP3505 * cpu_is_omap3517(): True for OMAP3517 */ @@ -299,7 +298,6 @@ IS_OMAP_TYPE(3517, 0x3517) #define cpu_is_omap3505() 0 #define cpu_is_omap3517() 0 #define cpu_is_omap3430() 0 -#define cpu_is_omap4430() 0 #define cpu_is_omap3630() 0 /* -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V2 2/2] arm:omap:am33xx: Add power domain data
Hi On Thu, 1 Mar 2012, Hiremath, Vaibhav wrote: I am not sure whether we access these bits explicitly. If I understand correctly, API's which access these bits are not being called from anywhere, For example, omap4_pwrdm_read_mem_retst omap4_pwrdm_set_mem_retst omap4_pwrdm_set_mem_onst They'll be needed for the functional powerstate code, device PM QoS, and OSWR. Currently the major issue would be, for PM_PER_PWRSTCTRL, where LogicRETState bit has been moved to offset 3. This is being used in omap4_pwrdm_set_logic_retst() api. And in order to support weird/non-standard bit-offsets, we have to clean omap2_pwrdm_get_mem_bank_onstate/retst/_mask() api and have bitshift field in struct powerdomain, as you have rightly pointed out. As you work on this, I have a request. Please place the AM33xx powerdomain implementation functions into a separate file, powerdomain33xx.c perhaps, rather than trying to merge them with the OMAP4 powerdomain implementation functions. Some functions can be shared -- maybe place those into a separate file, powerdomain33xx_44xx.c perhaps? Is my all understanding correct? If yes, do you think this patch should get blocked for above cleanup? I feel Cleanup can still follow, since this won't impact the AM33xx boot. What's your opinion on this?? We can't merge patches which are known to be broken. That's a rule from Linus (and a good one). Better to try to get it right the first time it hits mainline. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] mmc: omap_hsmmc: Use gpio_find_by_chip_name() for omap_hsmmc_gpio_init()
On Friday 02 March 2012 12:25 AM, Tony Lindgren wrote:
Use gpio_find_by_chip_name() to find the GPIO pins as they can
be dynamically allocated on various gpio_chips.
Note that we don't want to touch the platform data as it can
now specify the GPIO offset on a named gpio_chip.
This removes the need to use callbacks to set the GPIO pins
in platform data.
While one of the reasons for those callbacks was to set the GPIO
pins in platform data, I guess the other and more important one
was to make sure the init sequencing between twl4030-gpio and the
mmc device depending on it was done rightly. Doesn't this patch now
leave the sequencing to work by luck (in the absence of something
like deferred probe being in place) like is the case of twl6030 and
mmc init sequence on OMAP4 already?
regards,
Rajendra
Cc: Chris Ballc...@laptop.org
Cc: Grant Likelygrant.lik...@secretlab.ca
Cc: Rajendra Nayakrna...@ti.com
Signed-off-by: Tony Lindgrent...@atomide.com
---
arch/arm/mach-omap2/hsmmc.c |3 +
arch/arm/mach-omap2/hsmmc.h |5 ++
arch/arm/plat-omap/include/plat/mmc.h |3 +
drivers/gpio/gpio-twl4030.c |2 +
drivers/mmc/host/omap_hsmmc.c | 109 +
5 files changed, 82 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index a97876d..dda88f7 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -323,7 +323,10 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
mmc-get_context_loss_count = hsmmc_get_context_loss;
+ mmc-slots[0].gpiochip_cd = c-gpiochip_cd;
mmc-slots[0].switch_pin = c-gpio_cd;
+
+ mmc-slots[0].gpiochip_wp = c-gpiochip_wp;
mmc-slots[0].gpio_wp = c-gpio_wp;
mmc-slots[0].remux = c-remux;
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index 07831cc..ffbb78d 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -22,8 +22,13 @@ struct omap2_hsmmc_info {
boolno_off_init;/* no power off when not in MMC sleep state */
boolvcc_aux_disable_is_sleep; /* Regulator off remapped to sleep */
booldeferred; /* mmc needs a deferred probe */
+
+ char*gpiochip_cd; /* Optional gpiochip for gpio_cd */
int gpio_cd;/* or -EINVAL */
+
+ char*gpiochip_wp; /* Optional gpiochip for gpio_wp */
int gpio_wp;/* or -EINVAL */
+
char*name; /* or NULL for default */
struct platform_device *pdev; /* mmc controller instance */
int ocr_mask; /* temporary HACK */
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index f75946c..cbfbdc3 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -130,7 +130,10 @@ struct omap_mmc_platform_data {
#define HSMMC_HAS_UPDATED_RESET (1 1)
unsigned features;
+ char *gpiochip_cd; /* optional gpiochip for card
detect */
int switch_pin; /* gpio (card detect) */
+
+ char *gpiochip_wp; /* optional gpiochip for write
protect */
int gpio_wp;/* gpio (write protect) */
int (*set_bus_mode)(struct device *dev, int slot, int bus_mode);
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index b8b4f22..d0f266c 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -391,6 +391,7 @@ static int __devinit gpio_twl4030_debounce(u32 debounce, u8
mmc_cd)
}
static int gpio_twl4030_remove(struct platform_device *pdev);
+static struct platform_driver gpio_twl4030_driver;
static int __devinit gpio_twl4030_probe(struct platform_device *pdev)
{
@@ -430,6 +431,7 @@ no_irqs:
pdata-debounce, pdata-mmc_cd,
ret);
+ twl_gpiochip.label = gpio_twl4030_driver.driver.name;
twl_gpiochip.base = pdata-gpio_base;
twl_gpiochip.ngpio = TWL4030_GPIO_MAX;
twl_gpiochip.dev =pdev-dev;
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index fd0c661..1aa2420 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -176,6 +176,8 @@ struct omap_hsmmc_host {
int use_dma, dma_ch;
int dma_line_tx, dma_line_rx;
int slot_id;
+ int gpio_cd;
+ int gpio_wp;
int got_dbclk;
int response_busy;
int context_loss;
@@ -192,26 +194,29 @@ struct omap_hsmmc_host {
static int omap_hsmmc_card_detect(struct device *dev, int slot)
{
- struct omap_mmc_platform_data *mmc =
Re: [PATCH V2 1/1] mmc: start removing enable / disable API
Tested on Samsung-SoC
Tested-by: Jaehoon Chung jh80.ch...@samsung.com
On 02/29/2012 04:17 PM, Adrian Hunter wrote:
Most parts of the enable / disable API are no longer used and
can be removed.
Cc: Rajendra Nayak rna...@ti.com
Cc: Venkatraman S svenk...@ti.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Thomas Abraham thomas.abra...@linaro.org
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
arch/arm/mach-exynos/mach-nuri.c |5 +-
arch/arm/mach-exynos/mach-universal_c210.c |9 +-
drivers/mmc/core/core.c| 187
+++-
drivers/mmc/core/host.c|1 -
drivers/mmc/core/host.h|1 -
drivers/mmc/host/davinci_mmc.c |4 -
drivers/mmc/host/omap_hsmmc.c | 15 +--
include/linux/mmc/core.h |1 -
include/linux/mmc/host.h | 46 +--
9 files changed, 27 insertions(+), 242 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-nuri.c
b/arch/arm/mach-exynos/mach-nuri.c
index 644af11..de68248 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -109,7 +109,7 @@ static struct s3c_sdhci_platdata nuri_hsmmc0_data
__initdata = {
.max_width = 8,
.host_caps = (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA |
MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
- MMC_CAP_DISABLE | MMC_CAP_ERASE),
+ MMC_CAP_ERASE),
.cd_type= S3C_SDHCI_CD_PERMANENT,
};
@@ -147,8 +147,7 @@ static struct platform_device emmc_fixed_voltage = {
static struct s3c_sdhci_platdata nuri_hsmmc2_data __initdata = {
.max_width = 4,
.host_caps = MMC_CAP_4_BIT_DATA |
- MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
- MMC_CAP_DISABLE,
+ MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
.ext_cd_gpio= EXYNOS4_GPX3(3), /* XEINT_27 */
.ext_cd_gpio_invert = 1,
.cd_type= S3C_SDHCI_CD_GPIO,
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
b/arch/arm/mach-exynos/mach-universal_c210.c
index 9b3fbae..57cfe61 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -734,8 +734,7 @@ static struct platform_device universal_gpio_keys = {
static struct s3c_sdhci_platdata universal_hsmmc0_data __initdata = {
.max_width = 8,
.host_caps = (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA |
- MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
- MMC_CAP_DISABLE),
+ MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED),
.cd_type= S3C_SDHCI_CD_PERMANENT,
};
@@ -772,8 +771,7 @@ static struct platform_device mmc0_fixed_voltage = {
static struct s3c_sdhci_platdata universal_hsmmc2_data __initdata = {
.max_width = 4,
.host_caps = MMC_CAP_4_BIT_DATA |
- MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
- MMC_CAP_DISABLE,
+ MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
.ext_cd_gpio= EXYNOS4_GPX3(4), /* XEINT_28 */
.ext_cd_gpio_invert = 1,
.cd_type= S3C_SDHCI_CD_GPIO,
@@ -783,8 +781,7 @@ static struct s3c_sdhci_platdata universal_hsmmc2_data
__initdata = {
static struct s3c_sdhci_platdata universal_hsmmc3_data __initdata = {
.max_width = 4,
.host_caps = MMC_CAP_4_BIT_DATA |
- MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
- MMC_CAP_DISABLE,
+ MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
.cd_type= S3C_SDHCI_CD_EXTERNAL,
};
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 0b317f0..44dd013 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -605,105 +605,6 @@ unsigned int mmc_align_data_size(struct mmc_card *card,
unsigned int sz)
EXPORT_SYMBOL(mmc_align_data_size);
/**
- * mmc_host_enable - enable a host.
- * @host: mmc host to enable
- *
- * Hosts that support power saving can use the 'enable' and 'disable'
- * methods to exit and enter power saving states. For more information
- * see comments for struct mmc_host_ops.
- */
-int mmc_host_enable(struct mmc_host *host)
-{
- if (!(host-caps MMC_CAP_DISABLE))
- return 0;
-
- if (host-en_dis_recurs)
- return 0;
-
- if
RE: [PATCH-V2 2/2] arm:omap:am33xx: Add power domain data
On Fri, Mar 02, 2012 at 11:19:40, Paul Walmsley wrote: Hi On Thu, 1 Mar 2012, Hiremath, Vaibhav wrote: I am not sure whether we access these bits explicitly. If I understand correctly, API's which access these bits are not being called from anywhere, For example, omap4_pwrdm_read_mem_retst omap4_pwrdm_set_mem_retst omap4_pwrdm_set_mem_onst They'll be needed for the functional powerstate code, device PM QoS, and OSWR. Currently the major issue would be, for PM_PER_PWRSTCTRL, where LogicRETState bit has been moved to offset 3. This is being used in omap4_pwrdm_set_logic_retst() api. And in order to support weird/non-standard bit-offsets, we have to clean omap2_pwrdm_get_mem_bank_onstate/retst/_mask() api and have bitshift field in struct powerdomain, as you have rightly pointed out. As you work on this, I have a request. Please place the AM33xx powerdomain implementation functions into a separate file, powerdomain33xx.c perhaps, rather than trying to merge them with the OMAP4 powerdomain implementation functions. That was my initial code and I had submitted same to the list as an RFC, Request you to refer to the link - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg58746.html And the reason behind merging am33xx with omap4 thing was triggered from the discussion on the above patch (between me, KevinH and RajendraNaik), and we all believed that, with some cleanup in OMAP4 code we can reuse it for am33xx. Thanks, Vaibhav Some functions can be shared -- maybe place those into a separate file, powerdomain33xx_44xx.c perhaps? Is my all understanding correct? If yes, do you think this patch should get blocked for above cleanup? I feel Cleanup can still follow, since this won't impact the AM33xx boot. What's your opinion on this?? We can't merge patches which are known to be broken. That's a rule from Linus (and a good one). Better to try to get it right the first time it hits mainline. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] mmc: omap_hsmmc: Use GPIO offset for external GPIO chips
On Friday 02 March 2012 12:25 AM, Tony Lindgren wrote:
We can now remove the setting of GPIO pins with callbacks
as the drivers can access a GPIO offset on a named gpio_chip
directly with gpio_find_by_chip_name().
Cc: Rajendra Nayakrna...@ti.com
Signed-off-by: Tony Lindgrent...@atomide.com
---
arch/arm/mach-omap2/board-3430sdp.c | 13 -
arch/arm/mach-omap2/board-cm-t35.c |8 ++--
arch/arm/mach-omap2/board-devkit8000.c |7 ++-
arch/arm/mach-omap2/board-igep0020.c |8 ++--
arch/arm/mach-omap2/board-omap3beagle.c |9 +++--
arch/arm/mach-omap2/board-omap3evm.c |8 ++--
arch/arm/mach-omap2/board-omap3pandora.c | 13 -
arch/arm/mach-omap2/board-omap3stalker.c |8 ++--
arch/arm/mach-omap2/board-omap3touchbook.c |7 ++-
arch/arm/mach-omap2/board-zoom-peripherals.c |7 ++-
10 files changed, 25 insertions(+), 63 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index da75f23..238b95a 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -231,14 +231,16 @@ static struct omap2_hsmmc_info mmc[] = {
* so the SIM card isn't used; else 4 bits.
*/
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
+ .gpiochip_cd= twl4030_gpio,
+ .gpio_cd= 0,/* mmc0_cd offset in twl4030 */
.gpio_wp= 4,
- .deferred = true,
Shouldn't this patch completely get rid of all the 'deferred'
infrastructure that was put in place, including the
omap_hsmmc_late_init() function, since there is no need for it
anymore?
},
[..]
/*
* Most GPIOs are for USB OTG. Some are mostly sent to
* the P2 connector; notably LEDA for the LCD backlight.
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index ace466b..b387264 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -270,19 +270,19 @@ static struct omap2_hsmmc_info omap3pandora_mmc[] = {
{
.mmc= 1,
.caps = MMC_CAP_4_BIT_DATA,
- .gpio_cd= -EINVAL,
+ .gpiochip_cd= twl4030_gpio,
+ .gpio_cd= 0,/* mmc0_cd offset in twl4030 */
.gpio_wp= 126,
.ext_clock = 0,
- .deferred = true,
},
{
.mmc= 2,
.caps = MMC_CAP_4_BIT_DATA,
- .gpio_cd= -EINVAL,
+ .gpiochip_cd= twl4030_gpio,
+ .gpio_cd= 0,/* mmc0_cd offset in twl4030 */
This one should be gpio_cd = 1,
regards,
Rajendra
.gpio_wp= 127,
.ext_clock = 1,
.transceiver= true,
- .deferred = true,
},
{
.mmc= 3,
@@ -299,11 +299,6 @@ static int omap3pandora_twl_gpio_setup(struct device *dev,
{
int ret, gpio_32khz;
- /* gpio + {0,1} is mmc{0,1}_cd (input/IRQ) */
- omap3pandora_mmc[0].gpio_cd = gpio + 0;
- omap3pandora_mmc[1].gpio_cd = gpio + 1;
- omap_hsmmc_late_init(omap3pandora_mmc);
-
/* gpio + 13 drives 32kHz buffer for wifi module */
gpio_32khz = gpio + 13;
ret = gpio_request_one(gpio_32khz, GPIOF_OUT_INIT_HIGH, wifi 32kHz);
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c
b/arch/arm/mach-omap2/board-omap3stalker.c
index 6410043..6d0deb9 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -211,9 +211,9 @@ static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
.caps = MMC_CAP_4_BIT_DATA,
- .gpio_cd= -EINVAL,
+ .gpiochip_cd= twl4030_gpio,
+ .gpio_cd= 0,/* mmc0_cd offset in twl4030 */
.gpio_wp= 23,
- .deferred = true,
},
{} /* Terminator */
};
@@ -282,10 +282,6 @@ static int
omap3stalker_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
- /* gpio + 0 is mmc0_cd (input/IRQ) */
- mmc[0].gpio_cd = gpio + 0;
- omap_hsmmc_late_init(mmc);
-
/*
* Most GPIOs are for USB OTG. Some are mostly sent to
* the P2 connector; notably LEDA for the LCD backlight.
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c
b/arch/arm/mach-omap2/board-omap3touchbook.c
index 8842e04..cf270b8 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -99,8
Re: [PATCH 4/4] mmc: omap_hsmmc: Simplify init for twl6030 MMC card detect
On Friday 02 March 2012 12:25 AM, Tony Lindgren wrote:
There's no need to use callbacks for this, we can
do it directly between MMC driver and twl6030.
Cc: Samuel Ortizsa...@linux.intel.com
Cc: Chris Ballc...@laptop.org
Cc: Rajendra Nayakrna...@ti.com
Signed-off-by: Tony Lindgrent...@atomide.com
---
[..]
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 7ca7a5c..8cf4e54 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -153,8 +153,8 @@ static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
- .gpio_wp= -EINVAL,
.gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
stray change.
},
[..]
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index c6b456a..ce0002b 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -283,35 +283,30 @@ int twl6030_mmc_card_detect_config(void)
* Card status on TWL6030 for MMC1
*/
ret = twl_i2c_read_u8(TWL6030_MODULE_ID0,reg_val, TWL6030_MMCCTRL);
- if (ret 0) {
- pr_err(twl6030: Failed to read MMCCTRL, error %d\n, ret);
- return ret;
- }
+ if (ret 0)
+ goto err;
reg_val= ~VMMC_AUTO_OFF;
reg_val |= SW_FC;
ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val, TWL6030_MMCCTRL);
- if (ret 0) {
- pr_err(twl6030: Failed to write MMCCTRL, error %d\n, ret);
- return ret;
- }
+ if (ret 0)
+ goto err;
/* Configuring PullUp-PullDown register */
ret = twl_i2c_read_u8(TWL6030_MODULE_ID0,reg_val,
TWL6030_CFG_INPUT_PUPD3);
- if (ret 0) {
- pr_err(twl6030: Failed to read CFG_INPUT_PUPD3, error %d\n,
- ret);
- return ret;
- }
+ if (ret 0)
+ goto err;
reg_val= ~(MMC_PU | MMC_PD);
ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val,
TWL6030_CFG_INPUT_PUPD3);
- if (ret 0) {
- pr_err(twl6030: Failed to write CFG_INPUT_PUPD3, error %d\n,
- ret);
- return ret;
- }
- return 0;
+ if (ret 0)
+ goto err;
+
+ return twl6030_irq_base + MMCDETECT_INTR_OFFSET;
+
+err:
+ pr_err(twl6030: Failed to initialize MMC card detect: %d\n, ret);
+ return -ENODEV;
}
EXPORT_SYMBOL(twl6030_mmc_card_detect_config);
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 1aa2420..7f483b7 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -34,6 +34,7 @@
#includelinux/gpio.h
#includelinux/regulator/consumer.h
#includelinux/pm_runtime.h
+#includelinux/i2c/twl.h
#includeplat/dma.h
#includemach/hardware.h
#includeplat/board.h
@@ -578,6 +579,32 @@ static void omap_hsmmc_gpio_free(struct omap_hsmmc_host
*host)
gpio_free(host-gpio_cd);
}
+#ifdef CONFIG_TWL4030_CORE
+static int omap_hsmmc_init_twl6030(struct omap_hsmmc_host *host)
+{
+ struct omap_mmc_platform_data *pdata = host-pdata;
+ struct omap_mmc_slot_data *slot =pdata-slots[0];
+ int irq;
+
+ if (gpio_is_valid(host-gpio_cd) || host-id)
I have a series, which I am asking Chris to pull, which completely
gets rid of all host-id based hard-codings' in the driver.
Isn't there a better way to do this than rely on the device instance?
regards,
Rajendra
+ return 0;
+
+ irq = twl6030_mmc_card_detect_config();
+ if (irq= 0)
+ return irq;
+
+ slot-card_detect_irq = irq;
+ slot-card_detect = twl6030_mmc_card_detect;
+
+ return 0;
+}
+#else
+static inline int omap_hsmmc_init_twl6030(struct omap_hsmmc_host *host)
+{
+ return -ENODEV;
+}
+#endif
+
/*
* Start clock to the card
*/
@@ -1933,6 +1960,10 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
if (ret)
goto err1;
+ ret = omap_hsmmc_init_twl6030(host);
+ if (ret)
+ goto err1;
+
mmc-ops =omap_hsmmc_ops;
/*
--
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 2/2] arm:omap:am33xx: Add power domain data
Hi, On Thu, 1 Mar 2012, Hiremath, Vaibhav wrote: The initialization used in the patch is correct. Unfortunately, the TRM is incorrect here. I have already raised this issue with respective folks and soon it will get corrected. thanks for looking into this. Could you add a brief comment or comments in this file to indicate that the TRM Rev C is incorrect about those? That will help others who may be reviewing this code as they track down bugs. thanks - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V2 2/2] arm:omap:am33xx: Add power domain data
On Fri, Mar 02, 2012 at 12:02:31, Paul Walmsley wrote: Hi, On Thu, 1 Mar 2012, Hiremath, Vaibhav wrote: The initialization used in the patch is correct. Unfortunately, the TRM is incorrect here. I have already raised this issue with respective folks and soon it will get corrected. thanks for looking into this. Could you add a brief comment or comments in this file to indicate that the TRM Rev C is incorrect about those? That will help others who may be reviewing this code as they track down bugs. Good point. I will certainly add it in the next version of patch-sets. Paul, Thanks for your review comments, can we also align on the approach, Whether to merge am33xx powerdomain with omap4 (same direction we are now) OR Have separate implementation (my original approach). Thanks, Vaibhav thanks - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: hsmmc: add max_freq field
+Chris queues all MMC patches including omap_hsmmc. Ping ? On Fri, Mar 2, 2012 at 5:41 AM, Tony Lindgren t...@atomide.com wrote: Hi, * Daniel Mack zon...@gmail.com [120217 05:13]: ping? Could anyone care for queueing this please? I suggest Rajendra queue up omap_hsmmc.c patches as he's already patching it. Regards, Tony On Thu, Dec 29, 2011 at 2:22 PM, Daniel Mack zon...@gmail.com wrote: On 12/23/2011 04:40 PM, T Krishnamoorthy, Balaji wrote: On Wed, Dec 14, 2011 at 6:52 PM, Daniel Mack zon...@gmail.com wrote: diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 101cd31..8215ef9 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1927,8 +1927,12 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) if (mmc_slot(host).vcc_aux_disable_is_sleep) mmc_slot(host).no_off = 1; - mmc-f_min = OMAP_MMC_MIN_CLOCK; - mmc-f_max = OMAP_MMC_MAX_CLOCK; + mmc-f_min = OMAP_MMC_MIN_CLOCK; Stray change for f_min ? No, this was intended. The indentation doesn't make sense anymore when not grouped with the f_max assignment. Other than that, what is necessary to get this picked? Tony? :) Thanks, Daniel -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] mmc: omap_hsmmc: Use gpio_find_by_chip_name() for omap_hsmmc_gpio_init()
On Friday 02 March 2012 12:25 AM, Tony Lindgren wrote:
Use gpio_find_by_chip_name() to find the GPIO pins as they can
be dynamically allocated on various gpio_chips.
Note that we don't want to touch the platform data as it can
now specify the GPIO offset on a named gpio_chip.
This removes the need to use callbacks to set the GPIO pins
in platform data.
Cc: Chris Ballc...@laptop.org
Cc: Grant Likelygrant.lik...@secretlab.ca
Cc: Rajendra Nayakrna...@ti.com
Signed-off-by: Tony Lindgrent...@atomide.com
---
some more comments based on my testing with twl4030-gpio
built as a module..
arch/arm/mach-omap2/hsmmc.c |3 +
arch/arm/mach-omap2/hsmmc.h |5 ++
arch/arm/plat-omap/include/plat/mmc.h |3 +
drivers/gpio/gpio-twl4030.c |2 +
drivers/mmc/host/omap_hsmmc.c | 109 +
5 files changed, 82 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index a97876d..dda88f7 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -323,7 +323,10 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
@@ -497,55 +502,80 @@ static inline int omap_hsmmc_have_reg(void)
#endif
-static int omap_hsmmc_gpio_init(struct omap_mmc_platform_data *pdata)
+static int omap_hsmmc_gpio_init(struct omap_hsmmc_host *host)
{
- int ret;
-
- if (gpio_is_valid(pdata-slots[0].switch_pin)) {
- if (pdata-slots[0].cover)
- pdata-slots[0].get_cover_state =
+ struct omap_mmc_platform_data *pdata = host-pdata;
+ struct omap_mmc_slot_data *slot =pdata-slots[0];
+ int gpio, ret;
+
+ gpio = slot-switch_pin;
+ if (slot-gpiochip_cd)
+ gpio = gpio_find_by_chip_name(slot-gpiochip_cd, gpio);
+ if (gpio_is_valid(gpio)) {
+ if (slot-cover)
+ slot-get_cover_state =
omap_hsmmc_get_cover_state;
else
- pdata-slots[0].card_detect = omap_hsmmc_card_detect;
- pdata-slots[0].card_detect_irq =
- gpio_to_irq(pdata-slots[0].switch_pin);
- ret = gpio_request(pdata-slots[0].switch_pin, mmc_cd);
+ slot-card_detect = omap_hsmmc_card_detect;
+ slot-card_detect_irq =
+ gpio_to_irq(gpio);
+ ret = gpio_request(gpio, mmc_cd);
if (ret)
return ret;
- ret = gpio_direction_input(pdata-slots[0].switch_pin);
+ ret = gpio_direction_input(gpio);
if (ret)
goto err_free_sp;
- } else
- pdata-slots[0].switch_pin = -EINVAL;
+ host-gpio_cd = gpio;
+ } else {
+ if (slot-gpiochip_cd) {
+ pr_warning(MMC %s card detect GPIO chip %s
unavailable\n,
+ slot-name, slot-gpiochip_cd);
+ ret = -ENODEV;
+ goto err_free_sp;
This should just return -ENODEV, nothing really to free here.
+ }
+ host-gpio_cd = -EINVAL;
+ }
- if (gpio_is_valid(pdata-slots[0].gpio_wp)) {
- pdata-slots[0].get_ro = omap_hsmmc_get_wp;
- ret = gpio_request(pdata-slots[0].gpio_wp, mmc_wp);
+ gpio = slot-gpio_wp;
+ if (slot-gpiochip_wp)
+ gpio = gpio_find_by_chip_name(slot-gpiochip_wp, gpio);
+ if (gpio_is_valid(gpio)) {
+ slot-get_ro = omap_hsmmc_get_wp;
+ ret = gpio_request(gpio, mmc_wp);
if (ret)
goto err_free_cd;
- ret = gpio_direction_input(pdata-slots[0].gpio_wp);
+ ret = gpio_direction_input(gpio);
if (ret)
goto err_free_wp;
- } else
- pdata-slots[0].gpio_wp = -EINVAL;
+ host-gpio_wp = gpio;
+ } else {
+ if (slot-gpiochip_wp) {
+ pr_warning(MMC %s write protect GPIO chip %s
unavailable\n,
+ slot-name, slot-gpiochip_wp);
+ ret = -ENODEV;
+ goto err_free_wp;
+ }
+ host-gpio_wp = -EINVAL;
+ }
return 0;
err_free_wp:
- gpio_free(pdata-slots[0].gpio_wp);
+ if (gpio_is_valid(host-gpio_wp))
+ gpio_free(host-gpio_wp);
err_free_cd:
- if (gpio_is_valid(pdata-slots[0].switch_pin))
+ if (gpio_is_valid(host-gpio_cd))
err_free_sp:
- gpio_free(pdata-slots[0].switch_pin);
+ gpio_free(host-gpio_cd);
return ret;
}
-static void omap_hsmmc_gpio_free(struct omap_mmc_platform_data *pdata)
+static void omap_hsmmc_gpio_free(struct omap_hsmmc_host *host)
{
