Re: [PATCH] ASoC: omap-pcm: Allow only formats with 1, 2, and 4 byte physical size
On Tue, Mar 03, 2015 at 01:28:53PM +0200, Jyri Sarha wrote: sDMA support only transfer elements with 1, 2, and 4 byte physical size. Initialize the pcm driver accordingly. Applied, thanks. signature.asc Description: Digital signature
reboot command - fail with power save support
Hello, I added power support to kernel menuconfig, such as cpuidle, and it seems to work fine. I also validated in counter that cpu gets into retention. The strange thing is that reboot now doesn't work and more: it starts printing garbage, but does not continue with reboot. Is there any idea ? Thank you, Ran -- To unsubscribe from this list: send the line unsubscribe 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: [PATCHv2 0/2] N900 Modem Speech Support
Hi!
This patchset contains the missing speech data support for the
Nokia N900 modem.
Userland access goes via /dev/cmt_speech. The API is implemented in
libcmtspeechdata, which is used by ofono and the freesmartphone.org project.
Apart from that the device is also used by the phone binaries distributed
with Maemo. So while this is a new userland ABI for the mainline kernel it
has been tested in the wild for some years.
Simple Testing of the API can be done by checking out libcmtspeechdata [0],
building the test tool and executing it. The tool will loop back audio data
received from the caller.
I have prepared a kernel branch for this patchset, which can be found at [1].
Changes since PATCHv1 [2]:
* Squash cmt-speech patches together
* cs_alloc_cmds(): GFP_ATOMIC - GFP_KERNEL
* CS_SET_WAKELINE ioctl: Add sanity check
commit fd3492869b9387f7bd97821badb491e9c0be463f
Author: Pavel pa...@ucw.cz
Date: Wed Mar 4 20:22:32 2015 +0100
Simple cleanups, improve consistency.
Signed-off-by: Pavel Machek pa...@ucw.cz
diff --git a/drivers/hsi/clients/cmt_speech.c b/drivers/hsi/clients/cmt_speech.c
index a017292..9609766 100644
--- a/drivers/hsi/clients/cmt_speech.c
+++ b/drivers/hsi/clients/cmt_speech.c
@@ -115,6 +115,7 @@ struct cs_hsi_iface {
unsigned intrx_ptr_boundary;
unsigned intrx_offsets[CS_MAX_BUFFERS];
unsigned inttx_offsets[CS_MAX_BUFFERS];
+
/* size of aligned memory blocks */
unsigned intslot_size;
unsigned intflags;
@@ -194,32 +195,27 @@ static void cs_notify_data(u32 message, int maxlength)
cs_notify(message, cs_char_data.dataind_queue);
spin_lock(cs_char_data.lock);
- ++cs_char_data.dataind_pending;
+ cs_char_data.dataind_pending++;
while (cs_char_data.dataind_pending maxlength
!list_empty(cs_char_data.dataind_queue)) {
dev_dbg(cs_char_data.cl-device, data notification
queue overrun (%u entries)\n, cs_char_data.dataind_pending);
cs_pop_entry(cs_char_data.dataind_queue);
- --cs_char_data.dataind_pending;
+ cs_char_data.dataind_pending--;
}
spin_unlock(cs_char_data.lock);
}
static inline void cs_set_cmd(struct hsi_msg *msg, u32 cmd)
{
- u32 *data;
-
- data = sg_virt(msg-sgt.sgl);
+ u32 *data = sg_virt(msg-sgt.sgl);
*data = cmd;
}
static inline u32 cs_get_cmd(struct hsi_msg *msg)
{
- u32 *data;
-
- data = sg_virt(msg-sgt.sgl);
-
+ u32 *data = sg_virt(msg-sgt.sgl);
return *data;
}
@@ -641,7 +637,7 @@ static void cs_hsi_peek_on_data_complete(struct hsi_msg
*msg)
cs_hsi_data_read_error(hi, msg);
}
-/**
+/*
* Read/write transaction is ongoing. Returns false if in
* SSI_CHANNEL_STATE_POLL state.
*/
@@ -651,7 +647,7 @@ static inline int cs_state_xfer_active(unsigned int state)
(state SSI_CHANNEL_STATE_READING);
}
-/**
+/*
* No pending read/writes
*/
static inline int cs_state_idle(unsigned int state)
@@ -1117,10 +1113,9 @@ static int cs_char_fasync(int fd, struct file *file, int
on)
{
struct cs_char *csdata = file-private_data;
- if (fasync_helper(fd, file, on, csdata-async_queue) = 0)
- return 0;
- else
+ if (fasync_helper(fd, file, on, csdata-async_queue) 0)
return -EIO;
+ return 0;
}
static unsigned int cs_char_poll(struct file *file, poll_table *wait)
@@ -1149,7 +1144,7 @@ static ssize_t cs_char_read(struct file *file, char
__user *buf, size_t count,
if (count sizeof(data))
return -EINVAL;
- for ( ; ; ) {
+ for (;;) {
DEFINE_WAIT(wait);
spin_lock_bh(csdata-lock);
@@ -1157,7 +1152,7 @@ static ssize_t cs_char_read(struct file *file, char
__user *buf, size_t count,
data = cs_pop_entry(csdata-chardev_queue);
} else if (!list_empty(csdata-dataind_queue)) {
data = cs_pop_entry(csdata-dataind_queue);
- --csdata-dataind_pending;
+ csdata-dataind_pending--;
} else {
data = 0;
@@ -1239,8 +1234,8 @@ static long cs_char_ioctl(struct file *file, unsigned int
cmd,
if (copy_to_user((void __user *)arg, ifver, sizeof(ifver)))
r = -EFAULT;
- break;
}
+ break;
case CS_CONFIG_BUFS: {
struct cs_buffer_config buf_cfg;
@@ -1249,8 +1244,8 @@ static long cs_char_ioctl(struct file *file, unsigned int
cmd,
r = -EFAULT;
else
r = cs_hsi_buf_config(csdata-hi, buf_cfg);
- break;
}
+ break;
Re: [PATCHv2 0/2] N900 Modem Speech Support
On Wed, Mar 04, 2015 at 08:24:19PM +0100, Pavel Machek wrote:
@@ -1239,8 +1234,8 @@ static long cs_char_ioctl(struct file *file, unsigned
int cmd,
if (copy_to_user((void __user *)arg, ifver, sizeof(ifver)))
r = -EFAULT;
- break;
}
+ break;
case CS_CONFIG_BUFS: {
struct cs_buffer_config buf_cfg;
@@ -1249,8 +1244,8 @@ static long cs_char_ioctl(struct file *file, unsigned
int cmd,
r = -EFAULT;
else
r = cs_hsi_buf_config(csdata-hi, buf_cfg);
- break;
}
+ break;
I think having the break inside the block is more readable.
Now the indendation is mess.
A.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 0/2] N900 Modem Speech Support
On Wed 2015-03-04 21:36:50, Aaro Koskinen wrote:
On Wed, Mar 04, 2015 at 08:24:19PM +0100, Pavel Machek wrote:
@@ -1239,8 +1234,8 @@ static long cs_char_ioctl(struct file *file, unsigned
int cmd,
if (copy_to_user((void __user *)arg, ifver, sizeof(ifver)))
r = -EFAULT;
- break;
}
+ break;
case CS_CONFIG_BUFS: {
struct cs_buffer_config buf_cfg;
@@ -1249,8 +1244,8 @@ static long cs_char_ioctl(struct file *file, unsigned
int cmd,
r = -EFAULT;
else
r = cs_hsi_buf_config(csdata-hi, buf_cfg);
- break;
}
+ break;
I think having the break inside the block is more readable.
Now the indendation is mess.
Half the function does it one way, one the other way. I don't care
which way, but it should be consistent.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [PATCHv2 0/2] N900 Modem Speech Support
Hi! CMT speech (CMT_SPEECH) [N/m/y/?] (NEW) ? CONFIG_CMT_SPEECH: If you say Y here, you will enable the CMT speech protocol used by Nokia modems. If unsure, say N. Normally, we also specify name of the module in config text. .. which is strange, because I selected m and can't find cmt_speech.ko anywhere. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/2] pinctrl: Introduce TI IOdelay configuration driver
Nishanth Menon schreef op di 03-03-2015 om 18:00 [-0600]:
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index ee9f44ad7f02..8e463d75fbb2 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -160,6 +160,17 @@ config PINCTRL_TEGRA_XUSB
select PINCONF
select PINMUX
+config PINCTRL_TI_IODELAY
+ bool TI IODelay Module pinconf driver
This adds a boolean Kconfig symbol.
+ depends on OF
+ select PINCONF
+ select GENERIC_PINCONF
+ select REGMAP_MMIO
+ help
+ Say Y here to support Texas Instruments' IODelay pinconf driver.
+ IODelay module is used for the DRA7 SoC family. This driver is in
+ addition to PINCTRL_SINGLE which controls the mux.
+
config PINCTRL_TZ1090
bool Toumaz Xenif TZ1090 pin control driver
depends on SOC_TZ1090
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 0475206dd600..e441cd71aedf 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_PINCTRL_TEGRA30) += pinctrl-tegra30.o
obj-$(CONFIG_PINCTRL_TEGRA114) += pinctrl-tegra114.o
obj-$(CONFIG_PINCTRL_TEGRA124) += pinctrl-tegra124.o
obj-$(CONFIG_PINCTRL_TEGRA_XUSB) += pinctrl-tegra-xusb.o
+obj-$(CONFIG_PINCTRL_TI_IODELAY) += pinctrl-ti-iodelay.o
So this objectfile will either be built-in or not be built at all.
obj-$(CONFIG_PINCTRL_TZ1090) += pinctrl-tz1090.o
obj-$(CONFIG_PINCTRL_TZ1090_PDC) += pinctrl-tz1090-pdc.o
obj-$(CONFIG_PINCTRL_U300) += pinctrl-u300.o
diff --git a/drivers/pinctrl/pinctrl-ti-iodelay.c
b/drivers/pinctrl/pinctrl-ti-iodelay.c
new file mode 100644
index ..e4c6e25a781c
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-ti-iodelay.c
@@ -0,0 +1,963 @@
[...]
+#include linux/err.h
+#include linux/init.h
+#include linux/io.h
+#include linux/list.h
+#include linux/module.h
This is, I think, a bit of a red flag.
+#include linux/of_device.h
+#include linux/of.h
+#include linux/pinctrl/pinconf-generic.h
+#include linux/pinctrl/pinconf.h
+#include linux/pinctrl/pinctrl.h
+#include linux/regmap.h
+#include linux/slab.h
[...]
+static const struct of_device_id ti_iodelay_of_match[] = {
+ {.compatible = ti,dra7-iodelay, .data = dra7_iodelay_data},
+ { /* Hopefully no more.. */ },
+};
+MODULE_DEVICE_TABLE(of, ti_iodelay_of_match);
+
+static struct platform_driver ti_iodelay_driver = {
+ .probe = ti_iodelay_probe,
+ .remove = ti_iodelay_remove,
+ .driver = {
+.owner = THIS_MODULE,
So THIS_MODULE will, basically, be NULL.
+.name = DRIVER_NAME,
+.of_match_table = ti_iodelay_of_match,
+},
+};
+module_platform_driver(ti_iodelay_driver);
+
+MODULE_AUTHOR(Texas Instruments, Inc.);
+MODULE_DESCRIPTION(Pinconf driver for TI's IO Delay module);
+MODULE_LICENSE(GPL v2);
And these three macros will be preprocessed away.
(Perhaps there are non-modular alternatives to MODULE_DEVICE_TABLE and
module_platform_driver, but I'm not sure how those two macros actually
work.)
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe 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 4/6] ARM: dts: omap3-gta04: Add battery support
Hi, On Wed, Feb 04, 2015 at 11:14:33PM +0100, Marek Belisko wrote: Signed-off-by: Marek Belisko ma...@goldelico.com --- arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++ 1 file changed, 30 insertions(+) DTS changes must go via omap-dt tree once the driver changes have been merged. -- Sebastian signature.asc Description: Digital signature
[PATCH v8 1/4] Documentation: dt: add common bindings for hwspinlock
This patch adds the generic common bindings used to represent
a hwlock device and use/request locks in a device-tree build.
Each hwspinlock provider should have the '#hwlock-cells' property,
which represents the number of cells to be used for representing
a specific hwspinlock. Client users shall use the property
'hwlocks' for requesting specific lock(s).
Note that the document is named hwlock.txt deliberately to keep
it a bit more generic.
Cc: Rob Herring robh...@kernel.org
Cc: Mark Rutland mark.rutl...@arm.com
Reviewed-by: Bjorn Andersson bjorn.anders...@sonymobile.com
Signed-off-by: Suman Anna s-a...@ti.com
---
v8: Revised the binding completely, removed hwlock-num-locks and
hwlock-base-id properties. Added hwlock-names as optional
property. Revised patch description as well.
.../devicetree/bindings/hwlock/hwlock.txt | 59 ++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt
b/Documentation/devicetree/bindings/hwlock/hwlock.txt
new file mode 100644
index ..085d1f5c916a
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -0,0 +1,59 @@
+Generic hwlock bindings
+===
+
+Generic bindings that are common to all the hwlock platform specific driver
+implementations.
+
+Please also look through the individual platform specific hwlock binding
+documentations for identifying any additional properties specific to that
+platform.
+
+hwlock providers:
+=
+
+Required properties:
+- #hwlock-cells:Specifies the number of cells needed to represent a
+specific lock.
+
+hwlock users:
+=
+
+Consumers that require specific hwlock(s) should specify them using the
+property hwlocks, and an optional hwlock-names property.
+
+Required properties:
+- hwlocks: List of phandle to a hwlock provider node and an
+associated hwlock args specifier as indicated by
+#hwlock-cells. The list can have just a single hwlock
+or multiple hwlocks, with each hwlock represented by
+a phandle and a corresponding args specifier.
+
+Optional properties:
+- hwlock-names: List of hwlock name strings defined in the same order
+as the hwlocks, with one name per hwlock. Consumers can
+use the hwlock-names to match and get a specific
hwlock.
+
+
+1. Example of a node using a single specific hwlock:
+
+The following example has a node requesting a hwlock in the bank defined by
+the node hwlock1. hwlock1 is a hwlock provider with an argument specifier
+of length 1.
+
+ node {
+ ...
+ hwlocks = hwlock1 2;
+ ...
+ };
+
+2. Example of a node using multiple specific hwlocks:
+
+The following example has a node requesting two hwlocks, a hwlock within
+the hwlock device node 'hwlock1' with #hwlock-cells value of 1, and another
+hwlock within the hwlock device node 'hwlock2' with #hwlock-cells value of 2.
+
+ node {
+ ...
+ hwlocks = hwlock1 2, hwlock2 0 3;
+ ...
+ };
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi, On Wed, Feb 04, 2015 at 11:14:32PM +0100, Marek Belisko wrote: + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values + for charging calibration (see example) + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values + for discharging calibration (see example) Please prefix these properties with ti, -- Sebastian signature.asc Description: Digital signature
OMAP baseline test results for v4.0-rc2
Here are some basic OMAP test results for Linux v4.0-rc2. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.0-rc2/20150303123351/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: FAIL ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (15/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_oldconfig, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 Kernel warnings during boot to userspace: FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 2/17): 4430es2panda, 4460varsomom Obsolete Kconfig symbols: FAIL ( 2/20): omap1_defconfig, multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.0-rc1 (c517d838eb7d07bbe9507871fab3931deccff539)): text data bsstotal kernel +4 -80 -4 omap1_defconfig +6800 +68 omap1_defconfig_1510innovator_only +3600 +36 omap1_defconfig_5912osk_only +490589 +100104+7232 +597925 multi_v7_defconfig +15824 +5280 +16352 omap2plus_defconfig +6800 +68 omap2plus_defconfig_2430sdp_only +11728 +5600 +12288 omap2plus_defconfig_am33xx_only +15824 +5040 +16328 omap2plus_defconfig_am43xx_only +15824 +5360 +16360
Re: [PATCH 06/21] drm/omap: check CRTC color format earlier
Hi Tomi,
On Monday 02 March 2015 11:55:48 Tomi Valkeinen wrote:
On 27/02/15 14:07, Daniel Vetter wrote:
On Thu, Feb 26, 2015 at 03:20:14PM +0200, Tomi Valkeinen wrote:
When setting a color format to a DRM plane, the DRM core checks whether
the format is supported by the HW. However, it seems that when setting
the color format of a CRTC (i.e. a root plane), there's no checking
done. This causes omapdrm to configure omapdss with the bad color
format, which omapdss then rejects.
While the above is ok, the error message is a bit confusing, and the
configuring of omapdss happens asynchronously from the ioctl that does
the color format change.
This patch adds a color format check to omap_plane_mode_set() which
causes the ioctl to return an error for invalid color format. This means
that the userspace will get to know of the wrong setting, instead of the
current behavior where the error is not seen by the userspace.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_plane.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/omapdrm/omap_plane.c index 1f4f2b866379..bedd6f7af0f1
100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -207,6 +207,24 @@ int omap_plane_mode_set(struct drm_plane *plane,
{
struct omap_plane *omap_plane = to_omap_plane(plane);
struct omap_drm_window *win = omap_plane-win;
+ int i;
+
+ /*
+ * Check whether this plane supports the fb pixel format.
+ * I don't think this should really be needed, but it looks like the
+ * drm core only checks the format for planes, not for the crtc. So
+ * when setting the format for crtc, without this check we would
+ * get an error later when trying to program the color format into
the
+ * HW.
+ */
I think we should add a format check to the setcrtc ioctl if crtc-primary
is set. Atm the code is in __setplane_internal but could easily be shared
- there's already a copy in drm_atomi.c.
Omapdrm wouldn't benefit from this yet since it doesn't support universal
planes. But adding universal planes should be on your todo anyway ;-)
Laurent is working on universal planes and atomic modesetting for
omapdrm. In fact, I think universal planes is already done in his WIP
branch.
So, if this check is already done with universal planes (if I understood
correctly), I'm fine with dropping this patch.
Yes, I've implemented universal plane support. I'm currently rebasing your
patches on top of my bug fixes (excluding the more intrusive atomic update
rework). I'll push the resulting branch shortly and will send the patches for
review.
--
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 2/2] pinctrl: Introduce TI IOdelay configuration driver
* Paul Bolle pebo...@tiscali.nl [150304 14:58]:
Nishanth Menon schreef op di 03-03-2015 om 18:00 [-0600]:
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index ee9f44ad7f02..8e463d75fbb2 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -160,6 +160,17 @@ config PINCTRL_TEGRA_XUSB
select PINCONF
select PINMUX
+config PINCTRL_TI_IODELAY
+ bool TI IODelay Module pinconf driver
This adds a boolean Kconfig symbol.
+ depends on OF
+ select PINCONF
+ select GENERIC_PINCONF
+ select REGMAP_MMIO
+ help
+ Say Y here to support Texas Instruments' IODelay pinconf driver.
+ IODelay module is used for the DRA7 SoC family. This driver is in
+ addition to PINCTRL_SINGLE which controls the mux.
+
config PINCTRL_TZ1090
bool Toumaz Xenif TZ1090 pin control driver
depends on SOC_TZ1090
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 0475206dd600..e441cd71aedf 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_PINCTRL_TEGRA30) += pinctrl-tegra30.o
obj-$(CONFIG_PINCTRL_TEGRA114) += pinctrl-tegra114.o
obj-$(CONFIG_PINCTRL_TEGRA124) += pinctrl-tegra124.o
obj-$(CONFIG_PINCTRL_TEGRA_XUSB) += pinctrl-tegra-xusb.o
+obj-$(CONFIG_PINCTRL_TI_IODELAY) += pinctrl-ti-iodelay.o
So this objectfile will either be built-in or not be built at all.
obj-$(CONFIG_PINCTRL_TZ1090) += pinctrl-tz1090.o
obj-$(CONFIG_PINCTRL_TZ1090_PDC) += pinctrl-tz1090-pdc.o
obj-$(CONFIG_PINCTRL_U300) += pinctrl-u300.o
diff --git a/drivers/pinctrl/pinctrl-ti-iodelay.c
b/drivers/pinctrl/pinctrl-ti-iodelay.c
new file mode 100644
index ..e4c6e25a781c
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-ti-iodelay.c
@@ -0,0 +1,963 @@
[...]
+#include linux/err.h
+#include linux/init.h
+#include linux/io.h
+#include linux/list.h
+#include linux/module.h
This is, I think, a bit of a red flag.
+#include linux/of_device.h
+#include linux/of.h
+#include linux/pinctrl/pinconf-generic.h
+#include linux/pinctrl/pinconf.h
+#include linux/pinctrl/pinctrl.h
+#include linux/regmap.h
+#include linux/slab.h
[...]
+static const struct of_device_id ti_iodelay_of_match[] = {
+ {.compatible = ti,dra7-iodelay, .data = dra7_iodelay_data},
+ { /* Hopefully no more.. */ },
+};
+MODULE_DEVICE_TABLE(of, ti_iodelay_of_match);
+
+static struct platform_driver ti_iodelay_driver = {
+ .probe = ti_iodelay_probe,
+ .remove = ti_iodelay_remove,
+ .driver = {
+ .owner = THIS_MODULE,
So THIS_MODULE will, basically, be NULL.
+ .name = DRIVER_NAME,
+ .of_match_table = ti_iodelay_of_match,
+ },
+};
+module_platform_driver(ti_iodelay_driver);
+
+MODULE_AUTHOR(Texas Instruments, Inc.);
+MODULE_DESCRIPTION(Pinconf driver for TI's IO Delay module);
+MODULE_LICENSE(GPL v2);
And these three macros will be preprocessed away.
(Perhaps there are non-modular alternatives to MODULE_DEVICE_TABLE and
module_platform_driver, but I'm not sure how those two macros actually
work.)
This should be just made to work as a regular loadable module.
We already have pinctrl-single for the same platforms working
as a loadable module.
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 06/21] drm/omap: check CRTC color format earlier
Hi Daniel,
On Friday 27 February 2015 13:07:57 Daniel Vetter wrote:
On Thu, Feb 26, 2015 at 03:20:14PM +0200, Tomi Valkeinen wrote:
When setting a color format to a DRM plane, the DRM core checks whether
the format is supported by the HW. However, it seems that when setting
the color format of a CRTC (i.e. a root plane), there's no checking
done. This causes omapdrm to configure omapdss with the bad color
format, which omapdss then rejects.
While the above is ok, the error message is a bit confusing, and the
configuring of omapdss happens asynchronously from the ioctl that does
the color format change.
This patch adds a color format check to omap_plane_mode_set() which
causes the ioctl to return an error for invalid color format. This means
that the userspace will get to know of the wrong setting, instead of the
current behavior where the error is not seen by the userspace.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_plane.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/omapdrm/omap_plane.c index 1f4f2b866379..bedd6f7af0f1
100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -207,6 +207,24 @@ int omap_plane_mode_set(struct drm_plane *plane,
{
struct omap_plane *omap_plane = to_omap_plane(plane);
struct omap_drm_window *win = omap_plane-win;
+ int i;
+
+ /*
+* Check whether this plane supports the fb pixel format.
+* I don't think this should really be needed, but it looks like the
+* drm core only checks the format for planes, not for the crtc. So
+* when setting the format for crtc, without this check we would
+* get an error later when trying to program the color format into
the
+* HW.
+*/
I think we should add a format check to the setcrtc ioctl if crtc-primary
is set. Atm the code is in __setplane_internal but could easily be shared
- there's already a copy in drm_atomi.c.
I'll submit a patch.
Omapdrm wouldn't benefit from this yet since it doesn't support universal
planes. But adding universal planes should be on your todo anyway ;-)
Soon, soon :-)
+ for (i = 0; i plane-format_count; i++)
+ if (fb-pixel_format == plane-format_types[i])
+ break;
+ if (i == plane-format_count) {
+ DBG(Invalid pixel format %s,
+ drm_get_format_name(fb-pixel_format));
+ return -EINVAL;
+ }
win-crtc_x = crtc_x;
win-crtc_y = crtc_y;
--
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
[PATCH v8 0/4] hwspinlock core omap dt support
Hi Ohad, This is the latest version of the hwspinlock dt support series, rebased onto v4.0-rc1 and addressing the long discussion on the bindings in v7 [1]. I really hope that this series can make it into 4.1. Mark, Can you please provide your Acked-by for the binding documents so that Ohad can pick up the patches for the next merge window? Following are the main changes in v8 w.r.t v7: - Revised the generic hwspinlock bindings to remove hwlock-base-id and hwlock-num-locks properties, and added the optional hwlock-names property. - Updated the core device tree patch to remove of_hwspin_lock_get_base_id() and of_hwspin_lock_get_num_locks() functions. Reworked the of_hwspin_lock_get_id() API to not use the list of registered hwspinlock banks, but rely on the hwspinlock radix tree itself to perform deferred probing and pargs lock specifier validation. The last of the two were added in v6, but dropped in v7, and are now restored. - Updated the OMAP hwspinlock binding and DT support patches for the absence of the v7's mandatory hwlock-base-id property. - Changed the order of patches slightly to lump the core changes together and the OMAP hwspinlock changes together. The validation logs on all the applicable OMAP SoCs are at: OMAP4 : http://pastebin.ubuntu.com/10533448/ OMAP5 : http://pastebin.ubuntu.com/10533710/ DRA7 (X15) : http://pastebin.ubuntu.com/10533486/ AM33xx : http://pastebin.ubuntu.com/10533623/ AM43xx : http://pastebin.ubuntu.com/10533538/ The above logs are generated with some additional test patches staged here for reference, https://github.com/sumananna/omap-kernel/commits/hwspinlock/test/4.0-rc1-dt-v8 regards Suman [1] https://patchwork.kernel.org/patch/5635201/ --- v7: http://marc.info/?l=linux-omapm=142126914027417w=2 - Dropped the patch hwspinlock/core: maintain a list of registered hwspinlock banks - Updated generic hwspinlock bindings to make hwlock-base-id property mandatory. - Updated the OMAP hwspinlock binding and DT support patches to correct for the mandatory hwlock-base-id property. - Updated the common OF helpers patch to move the of_hwspin_lock_get_base_id() and of_hwspin_lock_get_num_locks() functions into the internal header, these are no longer exported, but available for platform implementations. of_hwspin_lock_get_id() is also simplified now. v6: http://marc.info/?l=linux-omapm=141055365213895w=2 - of_hwspin_lock_request_specific() is replaced with of_hwspin_lock_get_id(). of_hwspin_lock_simple_xlate() is made internal, and of_hwspin_lock_get_base_id() is added. - Updated the OMAP hwspinlock DT support patch to assign base-id from DT if present - RFC patches adding the concept of reserved locks and return code change convention dropped. v5: http://marc.info/?l=linux-omapm=139890478402807w=2 - Rebased v4 patches plus additional RFC patches. - Added back the patch to support DT-based hwlock-base-id property, for registration purposes. - RFC patches introducing the concept of reserved locks. - Staged patches for converting return convention to better support deferred probing of client drivers. v4: - The DT bindings are split into separate patches, and updated to add comments about #hwlock-cells - Fixed a registration issue with repeated module installation and removal. - Added a new OF helper to support #hwlock-cells in addition to the previous OF functions. The OMAP adaptation patch is updated to use the default translate function - Updated hwspinlock documentation to adjust for the structure changes and the new api additions. - Added build support for AM335x, AM43xx and DRA7xx http://marc.info/?l=linux-omapm=138965904015225w=2 v3: - Removed the DT property hwlock-base-id and associated OF helper - Added changes in core to support requesting a specific hwlock using phandle + args approach - Revised both the common and OMAP DT bindings document http://marc.info/?l=linux-omapm=138143992932197w=2 v2: - Added a new common DT binding documentation and OF helpers. - Revised OMAP DT parse support to use the new OF helper (Patch2) - OMAP5 hwspinlock support including the hwmod entry and DT node - Add AM335x support to OMAP hwspinlock driver, including a fix needed in driver given that AM335 spinlock module requires s/w wakeup - AM335 DT node for spinlock, and a hwmod change to enable smart-idle for AM335. - OMAP4 DT node patch is unchanged http://marc.info/?l=linux-omapm=137944644112727w=2 v1: - Add DT parse support to OMAP hwspinlock driver - Add OMAP4 DT node and bindings information http://marc.info/?l=linux-omapm=137823082308009w=2 --- Suman Anna (4): Documentation: dt: add common bindings for hwspinlock hwspinlock/core: add device tree support Documentation: dt: add the omap hwspinlock bindings document hwspinlock/omap: add support for dt nodes .../devicetree/bindings/hwlock/hwlock.txt | 59 .../devicetree/bindings/hwlock/omap-hwspinlock.txt
[PATCH v8 3/4] Documentation: dt: add the omap hwspinlock bindings document
HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
DT bindings information for OMAP hwspinlock module.
Cc: Rob Herring robh...@kernel.org
Cc: Mark Rutland mark.rutl...@arm.com
Signed-off-by: Suman Anna s-a...@ti.com
---
v8: Removed the previous information about hwlock-base-id, and added
a reference to the base binding document.
.../devicetree/bindings/hwlock/omap-hwspinlock.txt | 26 ++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
new file mode 100644
index ..2c9804f4f4ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
@@ -0,0 +1,26 @@
+OMAP4+ HwSpinlock Driver
+
+
+Required properties:
+- compatible: Should be ti,omap4-hwspinlock for
+ OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
+- reg: Contains the hwspinlock module register address space
+ (base address and length)
+- ti,hwmods: Name of the hwmod associated with the hwspinlock device
+- #hwlock-cells: Should be 1. The OMAP hwspinlock users will use a
+ 0-indexed relative hwlock number as the argument
+ specifier value for requesting a specific hwspinlock
+ within a hwspinlock bank.
+
+Please look at the generic hwlock binding for usage information for consumers,
+Documentation/devicetree/bindings/hwlock/hwlock.txt
+
+Example:
+
+/* OMAP4 */
+hwspinlock: spinlock@4a0f6000 {
+ compatible = ti,omap4-hwspinlock;
+ reg = 0x4a0f6000 0x1000;
+ ti,hwmods = spinlock;
+ #hwlock-cells = 1;
+};
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 4/4] hwspinlock/omap: add support for dt nodes
HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
base support for parsing the DT nodes, and removes the code
dealing with the traditional platform device instantiation.
Signed-off-by: Suman Anna s-a...@ti.com
[t...@atomide.com: ack for legacy file removal]
Acked-by: Tony Lindgren t...@atomide.com
---
v8: Updated to not rely on the retrieving base-id from DT node.
Did not use match data for base_id as OMAP will be using 0
as base id value anyways. This looks almost like the v5 version
without the added xlate ops.
MAINTAINERS | 1 -
arch/arm/mach-omap2/Makefile | 3 --
arch/arm/mach-omap2/hwspinlock.c | 60
drivers/hwspinlock/omap_hwspinlock.c | 17 +++---
4 files changed, 13 insertions(+), 68 deletions(-)
delete mode 100644 arch/arm/mach-omap2/hwspinlock.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8cf9a8a..f735fb3dfdd7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7035,7 +7035,6 @@ M:Ohad Ben-Cohen o...@wizery.com
L: linux-omap@vger.kernel.org
S: Maintained
F: drivers/hwspinlock/omap_hwspinlock.c
-F: arch/arm/mach-omap2/hwspinlock.c
OMAP MMC SUPPORT
M: Jarkko Lavinen jarkko.lavi...@nokia.com
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b83f18fcec9b..209a54007657 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -281,8 +281,5 @@ obj-y += $(nand-m)
$(nand-y)
smsc911x-$(CONFIG_SMSC911X):= gpmc-smsc911x.o
obj-y += $(smsc911x-m) $(smsc911x-y)
-ifneq ($(CONFIG_HWSPINLOCK_OMAP),)
-obj-y += hwspinlock.o
-endif
obj-y += common-board-devices.o twl-common.o
dss-common.o
diff --git a/arch/arm/mach-omap2/hwspinlock.c b/arch/arm/mach-omap2/hwspinlock.c
deleted file mode 100644
index ef175acaeaa2..
--- a/arch/arm/mach-omap2/hwspinlock.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * OMAP hardware spinlock device initialization
- *
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
- *
- * Contact: Simon Que s...@ti.com
- * Hari Kanigeri h-kanige...@ti.com
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- */
-
-#include linux/kernel.h
-#include linux/init.h
-#include linux/err.h
-#include linux/hwspinlock.h
-
-#include soc.h
-#include omap_hwmod.h
-#include omap_device.h
-
-static struct hwspinlock_pdata omap_hwspinlock_pdata __initdata = {
- .base_id = 0,
-};
-
-static int __init hwspinlocks_init(void)
-{
- int retval = 0;
- struct omap_hwmod *oh;
- struct platform_device *pdev;
- const char *oh_name = spinlock;
- const char *dev_name = omap_hwspinlock;
-
- /*
-* Hwmod lookup will fail in case our platform doesn't support the
-* hardware spinlock module, so it is safe to run this initcall
-* on all omaps
-*/
- oh = omap_hwmod_lookup(oh_name);
- if (oh == NULL)
- return -EINVAL;
-
- pdev = omap_device_build(dev_name, 0, oh, omap_hwspinlock_pdata,
- sizeof(struct hwspinlock_pdata));
- if (IS_ERR(pdev)) {
- pr_err(Can't build omap_device for %s:%s\n, dev_name,
- oh_name);
- retval = PTR_ERR(pdev);
- }
-
- return retval;
-}
-/* early board code might need to reserve specific hwspinlock instances */
-omap_postcore_initcall(hwspinlocks_init);
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
index 47a275c6ece1..e49e5eb784a6 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -1,7 +1,7 @@
/*
* OMAP hardware spinlock driver
*
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2010-2015 Texas Instruments Incorporated - http://www.ti.com
*
* Contact: Simon Que s...@ti.com
* Hari Kanigeri h-kanige...@ti.com
@@ -27,6 +27,7 @@
#include linux/slab.h
#include linux/spinlock.h
#include linux/hwspinlock.h
+#include linux/of.h
#include linux/platform_device.h
#include hwspinlock_internal.h
@@ -80,14 +81,15 @@ static const struct hwspinlock_ops omap_hwspinlock_ops = {
static int omap_hwspinlock_probe(struct platform_device *pdev)
{
- struct hwspinlock_pdata *pdata = pdev-dev.platform_data;
[PATCH v8 2/4] hwspinlock/core: add device tree support
This patch adds a new OF-friendly API of_hwspin_lock_get_id()
for hwspinlock clients to use/request locks from a hwspinlock
device instantiated through a device-tree blob. This new API
can be used by hwspinlock clients to get the id for a specific
lock using the phandle + args specifier, so that it can be
requested using the available hwspin_lock_request_specific()
API.
Signed-off-by: Suman Anna s-a...@ti.com
---
v8: Removed the previous OF helpers of_hwspin_lock_get_num_locks()
of_hwspin_lock_get_base_id() due to the revised generic
bindings. Added back the support for deferred probing and
pargs specifier validation like in v6, but without using an
added list for storing registered hwspinlock devices.
Documentation/hwspinlock.txt | 10 +
drivers/hwspinlock/hwspinlock_core.c | 79
include/linux/hwspinlock.h | 7
3 files changed, 96 insertions(+)
diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 62f7d4ea6e26..61c1ee98e59f 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -48,6 +48,16 @@ independent, drivers.
ids for predefined purposes.
Should be called from a process context (might sleep).
+ int of_hwspin_lock_get_id(struct device_node *np, int index);
+ - retrieve the global lock id for an OF phandle-based specific lock.
+ This function provides a means for DT users of a hwspinlock module
+ to get the global lock id of a specific hwspinlock, so that it can
+ be requested using the normal hwspin_lock_request_specific() API.
+ The function returns a lock id number on success, -EPROBE_DEFER if
+ the hwspinlock device is not yet registered with the core, or other
+ error values.
+ Should be called from a process context (might sleep).
+
int hwspin_lock_free(struct hwspinlock *hwlock);
- free a previously-assigned hwspinlock; returns 0 on success, or an
appropriate error code on failure (e.g. -EINVAL if the hwspinlock
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 461a0d739d75..f8539f624e3d 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -27,6 +27,7 @@
#include linux/hwspinlock.h
#include linux/pm_runtime.h
#include linux/mutex.h
+#include linux/of.h
#include hwspinlock_internal.h
@@ -257,6 +258,84 @@ void __hwspin_unlock(struct hwspinlock *hwlock, int mode,
unsigned long *flags)
}
EXPORT_SYMBOL_GPL(__hwspin_unlock);
+/**
+ * of_hwspin_lock_simple_xlate - translate hwlock_spec to return a lock id
+ * @bank: the hwspinlock device bank
+ * @hwlock_spec: hwlock specifier as found in the device tree
+ *
+ * This is a simple translation function, suitable for hwspinlock platform
+ * drivers that only has a lock specifier length of 1.
+ *
+ * Returns a relative index of the lock within a specified bank on success,
+ * or -EINVAL on invalid specifier cell count.
+ */
+static inline int
+of_hwspin_lock_simple_xlate(const struct of_phandle_args *hwlock_spec)
+{
+ if (WARN_ON(hwlock_spec-args_count != 1))
+ return -EINVAL;
+
+ return hwlock_spec-args[0];
+}
+
+/**
+ * of_hwspin_lock_get_id() - get lock id for an OF phandle-based specific lock
+ * @np: device node from which to request the specific hwlock
+ * @index: index of the hwlock in the list of values
+ *
+ * This function provides a means for DT users of the hwspinlock module to
+ * get the global lock id of a specific hwspinlock using the phandle of the
+ * hwspinlock device, so that it can be requested using the normal
+ * hwspin_lock_request_specific() API.
+ *
+ * Returns the global lock id number on success, -EPROBE_DEFER if the
hwspinlock
+ * device is not yet registered, -EINVAL on invalid args specifier value or an
+ * appropriate error as returned from the OF parsing of the DT client node.
+ */
+int of_hwspin_lock_get_id(struct device_node *np, int index)
+{
+ struct of_phandle_args args;
+ struct hwspinlock *hwlock;
+ struct radix_tree_iter iter;
+ void **slot;
+ int id;
+ int ret;
+
+ ret = of_parse_phandle_with_args(np, hwlocks, #hwlock-cells, index,
+args);
+ if (ret)
+ return ret;
+
+ /* perform a sanity check of the hwspinlock device */
+ ret = -EPROBE_DEFER;
+ rcu_read_lock();
+ radix_tree_for_each_slot(slot, hwspinlock_tree, iter, 0) {
+ hwlock = radix_tree_deref_slot(slot);
+ if (unlikely(!hwlock))
+ continue;
+
+ if (hwlock-bank-dev-of_node == args.np) {
+ ret = 0;
+ break;
+ }
+ }
+ rcu_read_unlock();
+ if (ret 0)
+ goto out;
+
+ id = of_hwspin_lock_simple_xlate(args);
+ if (id 0 || id = hwlock-bank-num_locks) {
+
Re: [PATCH 15/15] twl4030_charger: assume a 'charger' can supply maximum current.
On Mon, 2 Mar 2015 22:29:39 +0100 Pavel Machek pa...@ucw.cz wrote: On Tue 2015-02-24 15:33:53, NeilBrown wrote: If it cannot, we will stop pulling more current when voltage drops. Can you justify it a bit more? I mean... maybe there's a fuse in the charger? Or maybe it will supply the current but overheat in the process? (USB_MAX_CURRENT is 500mA or 1.7A?) USB_MAX_CURRENT is 1.7A - the most the twl4030 will manage. The relevant specs say that a charger can deliver from 0.5A to 5.0A at between 4.75 and 5.25 volts. They don't, as far as I can tell, describe how a gadget can determine where in those ranges the charger is actually happy. My understanding of electronics suggests that if you start to pull too much current, the voltage will start to drop. It is that voltage drop across internal resistance which causes over-heating. So if voltage is above 4.75 volts, it seems reasonable to assume that the charger is happy. The code currently (see previous patch) ramps up the current until the voltage drops below 4.75, or until the maximum is reached. If the voltage drops, it backs off. The current should only be too high for 100ms. Hopefully not too long. I'm very open if anyone can suggest a more safe way to make full use of a charger without risking excess current draw, but I cannot find one. Maybe I should measure the unloaded voltage, and not let it drop more than 0.25V below that? I'm also very open to someone finding out how to get the twl4030 to detect a D+ and D- shorted charger. I think it is supposed to be able to do this, but I haven't managed to make it work yet. Thanks, NeilBrown pgpVJ8GmrAVeE.pgp Description: OpenPGP digital signature
[PATCH v2 3/3] remoteproc: wkup_m3: Add wkup_m3 remoteproc driver
Add a remoteproc driver to load the firmware for and boot the wkup_m3
present on am33xx and am43xx. The wkup_m3 is an integrated Cortex M3
that allows the SoC to enter the lowest possible power state by taking
control from the MPU after it has gone into its own low power state and
shutting off any additional peripherals.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
drivers/remoteproc/Kconfig| 13 ++
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/wkup_m3_rproc.c| 229 ++
include/linux/platform_data/wkup_m3.h | 25
4 files changed, 268 insertions(+)
create mode 100644 drivers/remoteproc/wkup_m3_rproc.c
create mode 100644 include/linux/platform_data/wkup_m3.h
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 5e343ba..f73ba65 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -41,6 +41,19 @@ config STE_MODEM_RPROC
This can be either built-in or a loadable module.
If unsure say N.
+config WKUP_M3_RPROC
+ tristate AMx3xx wkup-m3 remoteproc support
+ depends on SOC_AM33XX || SOC_AM43XX
+ select REMOTEPROC
+ help
+ Say y here to support AMx3xx wkup-m3.
+
+ Required for Suspend-to-ram on AM33xx and AM43XX. Also needed
+ for deep CPUIdle states on AM33xx. Allows for loading of
+ firmware of CM3 PM coprocessor that is present on AMx3xx
+ family of SoCs.
+ If unsure say N.
+
config DA8XX_REMOTEPROC
tristate DA8xx/OMAP-L13x remoteproc support
depends on ARCH_DAVINCI_DA8XX
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index ac2ff75..81b04d1 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -9,4 +9,5 @@ remoteproc-y+= remoteproc_virtio.o
remoteproc-y += remoteproc_elf_loader.o
obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
obj-$(CONFIG_STE_MODEM_RPROC) += ste_modem_rproc.o
+obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
diff --git a/drivers/remoteproc/wkup_m3_rproc.c
b/drivers/remoteproc/wkup_m3_rproc.c
new file mode 100644
index 000..252f6f7
--- /dev/null
+++ b/drivers/remoteproc/wkup_m3_rproc.c
@@ -0,0 +1,229 @@
+/*
+ * TI AMx3 Wkup M3 Remote Processor driver
+ *
+ * Copyright (C) 2014-2015 Texas Instruments, Inc.
+ *
+ * Dave Gerlach d-gerl...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/err.h
+#include linux/kernel.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/of_address.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/remoteproc.h
+
+#include linux/platform_data/wkup_m3.h
+
+#include remoteproc_internal.h
+
+#define WKUPM3_MEM_MAX 2
+
+struct wkup_m3_mem {
+ void __iomem *cpu_addr;
+ phys_addr_t bus_addr;
+ u32 dev_addr;
+ size_t size;
+};
+
+struct wkup_m3_rproc {
+ struct rproc *rproc;
+ struct platform_device *pdev;
+ struct wkup_m3_mem mem[WKUPM3_MEM_MAX];
+};
+
+static int wkup_m3_rproc_start(struct rproc *rproc)
+{
+ struct wkup_m3_rproc *wkupm3 = rproc-priv;
+ struct platform_device *pdev = wkupm3-pdev;
+ struct device *dev = pdev-dev;
+ struct wkup_m3_platform_data *pdata = dev-platform_data;
+
+ if (pdata-deassert_reset(pdev, pdata-reset_name)) {
+ dev_err(dev, Unable to reset wkup_m3!\n);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int wkup_m3_rproc_stop(struct rproc *rproc)
+{
+ struct wkup_m3_rproc *wkupm3 = rproc-priv;
+ struct platform_device *pdev = wkupm3-pdev;
+ struct device *dev = pdev-dev;
+ struct wkup_m3_platform_data *pdata = dev-platform_data;
+
+ if (pdata-assert_reset(pdev, pdata-reset_name)) {
+ dev_err(dev, Unable to assert reset of wkup_m3!\n);
+ return -ENODEV;
+ }
+ return 0;
+}
+
+static void *wkup_m3_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
+{
+ struct wkup_m3_rproc *wkupm3 = rproc-priv;
+ void *va = NULL;
+ int i;
+ u32 offset;
+
+ if (len = 0)
+ return NULL;
+
+ for (i = 0; i WKUPM3_MEM_MAX; i++) {
+ if (da = wkupm3-mem[i].dev_addr
+ da + len = wkupm3-mem[i].dev_addr +
+ wkupm3-mem[i].size) {
+ offset = da -
[PATCH v2 0/3] remoteproc: Introduce wkup_m3_rproc driver
Hi, This patch series is version two of the series to add a wkup_m3_rproc driver for TI AM335x SoCs. This family of SoCs contains an ARM Cortex M3 coprocessor that is responsible for low-level power tasks that cannot be handled by the main ARM Cortex A8 so firmware running from the CM3 can be used instead. This driver handles loading of the firmware and reset of the CM3 once it is booted. The previous version of this series can be found here [1]. I have pushed a branch based on v4.0-rc1 containing the entire am335x suspend series here for a higher level view of the entire series of patch sets here [2]. This patch set contains a new patch from Suman Anna that replaces the RSC_INTMEM patch that this series used to depend on based on comments on that series. More info is included in the patch. Additional changes are: v1 - v2: -firmware loaded has changed, new code added by Suman Anna -wkup_m3_rproc can now be built and loaded as a module -added binding info and docs for am437x support -dts and pdata-quirks patch split to separate mach-omap2 series -remove ti,no-reset-on-init from required dt binding as it asserts hardreset which is default state of wkup_m3 anyway The driver expects to load firmware am335x-pm-firmware.elf from /lib/firmware which is found here [3]. Regards, Dave [1] http://www.spinics.net/lists/arm-kernel/msg387984.html [2] https://github.com/dgerlach/linux-pm/tree/pm-v4.0-rc1-am335x-suspend [3] https://git.ti.com/ti-cm3-pm-firmware/amx3-cm3/commits/next-upstream Dave Gerlach (2): Documentation: dt: add ti,am3353-wkup-m3 bindings remoteproc: wkup_m3: Add wkup_m3 remoteproc driver Suman Anna (1): remoteproc: add a rproc ops for performing address translation .../bindings/remoteproc/wkup_m3_rproc.txt | 46 + drivers/remoteproc/Kconfig | 13 ++ drivers/remoteproc/Makefile| 1 + drivers/remoteproc/remoteproc_core.c | 31 ++- drivers/remoteproc/wkup_m3_rproc.c | 229 + include/linux/platform_data/wkup_m3.h | 25 +++ include/linux/remoteproc.h | 2 + 7 files changed, 341 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt create mode 100644 drivers/remoteproc/wkup_m3_rproc.c create mode 100644 include/linux/platform_data/wkup_m3.h -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges
Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index acd3705..086415c 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -77,10 +77,23 @@
*/
soc {
compatible = ti,omap-infra;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0x0 0x44d0 0x4000,
+0x8 0x44d8 0x2000;
+
mpu {
compatible = ti,omap3-mpu;
ti,hwmods = mpu;
};
+
+ wkup_m3: wkup_m3@44d0 {
+ compatible = ti,am3353-wkup-m3;
+ reg = 0x0 0x4000, /* M3 UMEM */
+ 0x8 0x2000; /* M3 DMEM */
+ ti,hwmods = wkup_m3;
+ ti,pm-firmware = am335x-pm-firmware.elf;
+ };
};
am33xx_control_module: control_module@4a002000 {
@@ -755,14 +768,6 @@
reg = 0x4030 0x1; /* 64k */
};
- wkup_m3: wkup_m3@44d0 {
- compatible = ti,am3353-wkup-m3;
- reg = 0x44d0 0x4000/* M3 UMEM */
- 0x44d8 0x2000; /* M3 DMEM */
- ti,hwmods = wkup_m3;
- ti,no-reset-on-init;
- };
-
elm: elm@4808 {
compatible = ti,am3352-elm;
reg = 0x4808 0x2000;
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] pinctrl: Introduce TI IOdelay configuration driver
On 03/04/2015 04:58 PM, Tony Lindgren wrote:
* Paul Bolle pebo...@tiscali.nl [150304 14:58]:
Nishanth Menon schreef op di 03-03-2015 om 18:00 [-0600]:
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index ee9f44ad7f02..8e463d75fbb2 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -160,6 +160,17 @@ config PINCTRL_TEGRA_XUSB
select PINCONF
select PINMUX
+config PINCTRL_TI_IODELAY
+ bool TI IODelay Module pinconf driver
This adds a boolean Kconfig symbol.
Uggh.. thanks for the review and catching this..
+ depends on OF
+ select PINCONF
+ select GENERIC_PINCONF
+ select REGMAP_MMIO
+ help
+ Say Y here to support Texas Instruments' IODelay pinconf driver.
+ IODelay module is used for the DRA7 SoC family. This driver is in
+ addition to PINCTRL_SINGLE which controls the mux.
+
config PINCTRL_TZ1090
bool Toumaz Xenif TZ1090 pin control driver
depends on SOC_TZ1090
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 0475206dd600..e441cd71aedf 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_PINCTRL_TEGRA30) += pinctrl-tegra30.o
obj-$(CONFIG_PINCTRL_TEGRA114) += pinctrl-tegra114.o
obj-$(CONFIG_PINCTRL_TEGRA124) += pinctrl-tegra124.o
obj-$(CONFIG_PINCTRL_TEGRA_XUSB) += pinctrl-tegra-xusb.o
+obj-$(CONFIG_PINCTRL_TI_IODELAY) += pinctrl-ti-iodelay.o
So this objectfile will either be built-in or not be built at all.
obj-$(CONFIG_PINCTRL_TZ1090) += pinctrl-tz1090.o
obj-$(CONFIG_PINCTRL_TZ1090_PDC) += pinctrl-tz1090-pdc.o
obj-$(CONFIG_PINCTRL_U300) += pinctrl-u300.o
diff --git a/drivers/pinctrl/pinctrl-ti-iodelay.c
b/drivers/pinctrl/pinctrl-ti-iodelay.c
new file mode 100644
index ..e4c6e25a781c
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-ti-iodelay.c
@@ -0,0 +1,963 @@
[...]
+#include linux/err.h
+#include linux/init.h
+#include linux/io.h
+#include linux/list.h
+#include linux/module.h
This is, I think, a bit of a red flag.
+#include linux/of_device.h
+#include linux/of.h
+#include linux/pinctrl/pinconf-generic.h
+#include linux/pinctrl/pinconf.h
+#include linux/pinctrl/pinctrl.h
+#include linux/regmap.h
+#include linux/slab.h
[...]
+static const struct of_device_id ti_iodelay_of_match[] = {
+ {.compatible = ti,dra7-iodelay, .data = dra7_iodelay_data},
+ { /* Hopefully no more.. */ },
+};
+MODULE_DEVICE_TABLE(of, ti_iodelay_of_match);
+
+static struct platform_driver ti_iodelay_driver = {
+ .probe = ti_iodelay_probe,
+ .remove = ti_iodelay_remove,
+ .driver = {
+ .owner = THIS_MODULE,
So THIS_MODULE will, basically, be NULL.
+ .name = DRIVER_NAME,
+ .of_match_table = ti_iodelay_of_match,
+ },
+};
+module_platform_driver(ti_iodelay_driver);
+
+MODULE_AUTHOR(Texas Instruments, Inc.);
+MODULE_DESCRIPTION(Pinconf driver for TI's IO Delay module);
+MODULE_LICENSE(GPL v2);
And these three macros will be preprocessed away.
(Perhaps there are non-modular alternatives to MODULE_DEVICE_TABLE and
module_platform_driver, but I'm not sure how those two macros actually
work.)
This should be just made to work as a regular loadable module.
We already have pinctrl-single for the same platforms working
as a loadable module.
Yes, indeed. this can easily be fixed. my bad. will convert this to a
module in the next rev.
I will wait a week before reposting next rev to see if there are
improvements necessary in other areas - specifically in the way
pinconf is being used and if there are any binding related comments.
Will be great to hear any feedback on the same as well.
--
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
[PATCH v2 0/2] ARM: OMAP2+: wkup_m3_rproc support patches
Hi, This series adds the mach-omap2 code for the wkup_m3_rproc driver submitted here [1]. pdata-quirks patch requires the pdata added with patch 3 of the aforementioned series. The dt patch was previously included as part of the rproc series here [2]. Changes are: v1-v2: -Because the firmware loading has changed, the wkup_m3 node has moved into the soc node and ranges have been added so the device address to virtual address translation can work. -Removed the ti,no-reset-on-init flag as asserting the hard-reset line on init is what the wkup_m3 has by default already. Regards, Dave [1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg114621.html [2] http://www.spinics.net/lists/arm-kernel/msg387984.html Dave Gerlach (2): ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges arch/arm/boot/dts/am33xx.dtsi | 21 + arch/arm/mach-omap2/pdata-quirks.c | 13 + 2 files changed, 26 insertions(+), 8 deletions(-) -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset
Use pdata-quirks to provide platform data required for reset
of the wkup_m3 during boot.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
This patch requires the pdata introduced in this patch:
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg114622.html
arch/arm/mach-omap2/pdata-quirks.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 190fa43..7a09513 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -18,6 +18,7 @@
#include linux/platform_data/pinctrl-single.h
#include linux/platform_data/iommu-omap.h
+#include linux/platform_data/wkup_m3.h
#include common.h
#include common-board-devices.h
@@ -287,6 +288,14 @@ static void __init omap3_tao3530_legacy_init(void)
}
#endif /* CONFIG_ARCH_OMAP3 */
+#ifdef CONFIG_SOC_AM33XX
+static struct wkup_m3_platform_data wkup_m3_data = {
+ .reset_name = wkup_m3,
+ .assert_reset = omap_device_assert_hardreset,
+ .deassert_reset = omap_device_deassert_hardreset,
+};
+#endif
+
#ifdef CONFIG_ARCH_OMAP4
static void __init omap4_sdp_legacy_init(void)
{
@@ -382,6 +391,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA(ti,am3517-emac, 0x5c00, davinci_emac.0,
am35xx_emac_pdata),
#endif
+#ifdef CONFIG_SOC_AM33XX
+ OF_DEV_AUXDATA(ti,am3353-wkup-m3, 0x44d0, 44d0.wkup_m3,
+ wkup_m3_data),
+#endif
#ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a100040, 4a100040.pinmux,
pcs_pdata),
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a31e040, 4a31e040.pinmux,
pcs_pdata),
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/15] twl4030_charger: add software controlled linear charging mode.
On Mon, 2 Mar 2015 22:09:26 +0100 Pavel Machek pa...@ucw.cz wrote: On Tue 2015-02-24 15:33:52, NeilBrown wrote: Add a 'continuous' option for usb charging which enabled the linear charging mode of the twl4030. Documentation/ :-). ! Linear charging does a good job with not so reliable power sources, since several voltage controlling is then often too intelligent. Parse error. Linear charging does a good job with not-so-reliable power sources. Auto mode does not work well as it switches off when voltage drops momentarily. Care must be taken not to over-charge. It was used with a bike hub dynamo since a year or so. In that case there are automatically charging stops when the cyclist needs a break. = It was used with a bike hub dynamo since a year or so. In that case there are automatically charging stops when the cyclist needs a break. Orignal-by: Andreas Kemnade andr...@kemnade.info Signed-off-by: NeilBrown ne...@suse.de + ret = twl_i2c_write_u8(TWL_MODULE_MAIN_CHARGE, 0x33, + TWL4030_BCIWDKEY); + /* 0x24 + EKEY6: off mode */ - + ret = twl_i2c_write_u8(TWL_MODULE_MAIN_CHARGE, 0x2a, + TWL4030_BCIMDKEY); + /* EKEY2: Linear charge: usb path */ USB + ret = twl_i2c_write_u8(TWL_MODULE_MAIN_CHARGE, 0x26, + TWL4030_BCIMDKEY); + /* WDKEY5: stop watchdog count */ + ret = twl_i2c_write_u8(TWL_MODULE_MAIN_CHARGE, 0xf3, + TWL4030_BCIWDKEY); + /* enable MFEN3 access */ + ret = twl_i2c_write_u8(TWL_MODULE_MAIN_CHARGE, 0x9c, + TWL4030_BCIMFKEY); +/* ICHGEOCEN - end-of-charge monitor (current 80mA) + * (charging continues) + * ICHGLOWEN - current level monitor (charge continues) + * don't monitor over-current or heat save Heat save? Is ignoring over-current good idea? The data sheet refers to a flag HSEN which is Heat Save function enable. your guess is as good as mine. We don't currently have any code for responding to warnings. Maybe we should. For now this feature is use at your own risk - and one person has found it very useful. @@ -650,6 +684,8 @@ twl4030_bci_mode_store(struct device *dev, struct device_attribute *attr, mode = 0; else if (sysfs_streq(buf, modes[1])) mode = 1; + else if (sysfs_streq(buf, modes[2])) + mode = 2; Time for loop? When we get one more mode it will be :-) Thanks, NeilBrown pgpSRiRJsR3zi.pgp Description: OpenPGP digital signature
[PATCH v2 1/3] remoteproc: add a rproc ops for performing address translation
From: Suman Anna s-a...@ti.com
The rproc_da_to_va API is currently used to perform any device to
kernel address translations to meet the different needs of the remoteproc
core/drivers (eg: loading). The functionality is achieved within the
remoteproc core, and is limited only for carveouts allocated within the
core.
A new rproc ops, da_to_va, is added to provide flexibility to platform
implementations to perform the address translation themselves when the
above conditions cannot be met by the implementations. The rproc_da_to_va()
API is extended to invoke this ops if present, and fallback to regular
processing if the platform implementation cannot provide the translation.
This will allow any remoteproc implementations to translate addresses for
dedicated memories like internal memories, and facilitate the remoteproc
core to also load certain firmware sections into internal memories (eg:
RAM at L1 or L2 levels) for performance or other reasons.
While at this, also update the rproc_da_to_va() documentation since it
is an exported function.
Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
This patch is a replacement for the patch (remoteproc: add support to
handle internal memories) @ https://patchwork.kernel.org/patch/5602981/
The representation of internal memory regions is left to the individual
platform implementations, as this might vary from one to another.
drivers/remoteproc/remoteproc_core.c | 31 +--
include/linux/remoteproc.h | 2 ++
2 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 3cd85a63..e9825bd 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -147,28 +147,46 @@ static void rproc_disable_iommu(struct rproc *rproc)
return;
}
-/*
+/**
+ * rproc_da_to_va() - lookup the kernel virtual address for a remoteproc
address
+ * @rproc: handle of a remote processor
+ * @da: remoteproc device address to translate
+ * @len: length of the memory region @da is pointing to
+ *
* Some remote processors will ask us to allocate them physically contiguous
* memory regions (which we call carveouts), and map them to specific
- * device addresses (which are hardcoded in the firmware).
+ * device addresses (which are hardcoded in the firmware). They may also have
+ * dedicated memory regions internal to the processors, and use them either
+ * exclusively or alongside carveouts.
*
* They may then ask us to copy objects into specific device addresses (e.g.
* code/data sections) or expose us certain symbols in other device address
* (e.g. their trace buffer).
*
- * This function is an internal helper with which we can go over the allocated
- * carveouts and translate specific device address to kernel virtual addresses
- * so we can access the referenced memory.
+ * This function is a helper function with which we can go over the allocated
+ * carveouts and translate specific device addresses to kernel virtual
addresses
+ * so we can access the referenced memory. This function also allows to perform
+ * translations on the internal remoteproc memory regions through a platform
+ * implementation specific da_to_va ops, if present.
+ *
+ * The function returns a valid kernel address on success or NULL on failure.
*
* Note: phys_to_virt(iommu_iova_to_phys(rproc-domain, da)) will work too,
* but only on kernel direct mapped RAM memory. Instead, we're just using
- * here the output of the DMA API, which should be more correct.
+ * here the output of the DMA API for the carveouts, which should be more
+ * correct.
*/
void *rproc_da_to_va(struct rproc *rproc, u64 da, int len)
{
struct rproc_mem_entry *carveout;
void *ptr = NULL;
+ if (rproc-ops-da_to_va) {
+ ptr = rproc-ops-da_to_va(rproc, da, len);
+ if (ptr)
+ goto out;
+ }
+
list_for_each_entry(carveout, rproc-carveouts, node) {
int offset = da - carveout-da;
@@ -185,6 +203,7 @@ void *rproc_da_to_va(struct rproc *rproc, u64 da, int len)
break;
}
+out:
return ptr;
}
EXPORT_SYMBOL(rproc_da_to_va);
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 9e7e745..e0c0715 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -330,11 +330,13 @@ struct rproc;
* @start: power on the device and boot it
* @stop: power off the device
* @kick: kick a virtqueue (virtqueue id given as a parameter)
+ * @da_to_va: optional platform hook to perform address translations
*/
struct rproc_ops {
int (*start)(struct rproc *rproc);
int (*stop)(struct rproc *rproc);
void (*kick)(struct rproc *rproc, int vqid);
+ void * (*da_to_va)(struct rproc *rproc, u64 da, int len);
};
/**
--
2.3.0
--
To unsubscribe
[PATCH v2 2/3] Documentation: dt: add ti,am3353-wkup-m3 bindings
Add the device tree bindings document for ti,am3353-wkup-m3 which is
used by the wkup_m3_rproc driver.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
.../bindings/remoteproc/wkup_m3_rproc.txt | 46 ++
1 file changed, 46 insertions(+)
create mode 100644
Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
diff --git a/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
new file mode 100644
index 000..995af3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
@@ -0,0 +1,46 @@
+Wakeup M3 Remoteproc Driver
+===
+
+TI AMx3 family of devices use a Cortex M3 co-processor to help with various
+low power tasks that cannot be controlled from the MPU. The CM3 requires
+a firmware binary to accomplish this. The wkup_m3 remoteproc driver handles
+the loading of the firmware and booting of the CM3.
+
+Wkup M3 Device Node:
+
+A wkup_m3 device node is used to represent a wakeup M3 IP instance within
+a SoC.
+
+Required properties:
+
+- compatible: Should be:
+ ti,am3353-wkup-m3 for AM33xx SoCs
+ ti,am4372-wkup-m3 for AM43xx SoCs
+- reg: Contains the wkup_m3 register address ranges for
+ umem and dmem, from the devices address space.
+ NOTE: Parent node must contains ranges specifying
+ mapping from bus address space to device
+ address space.
+- ti,hwmods: Name of the hwmod associated with the mailbox
+- ti,pm-firmware: Name of firmware file to load for remoteproc.
+
+Example:
+
+/* AM33xx */
+soc {
+compatible = ti,omap-infra;
+#address-cells = 1;
+#size-cells = 1;
+ranges = 0x0 0x44d0 0x4000,
+ 0x8 0x44d8 0x2000;
+
+ ...
+
+ wkup_m3: wkup_m3@44d0 {
+ compatible = ti,am3353-wkup-m3;
+ reg = 0x0 0x4000 /* M3 UMEM */
+ 0x8 0x2000; /* M3 DMEM */
+ ti,hwmods = wkup_m3;
+ ti,pm-firmware = am335x-pm-firmware.elf;
+ };
+};
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/15] twl4030_charger: use runtime_pm to keep usb phy active while charging.
On Wed, 25 Feb 2015 07:24:43 + Lee Jones lee.jo...@linaro.org wrote: On Tue, 24 Feb 2015, NeilBrown wrote: The twl4030 usb phy needs to be active while we are using the USB VBUS as a current source for charging. In particular, the usb3v1 regulator must be enabled and the PHY_PWR_PHYPWD bit must be set to keep the phy powered. commit ab37813f4093a5f59cb8e083cde277289dc72ed3 twl4030_charger: Allow charger to control the regulator that feeds it Gave the charger control over the regulator, but didn't resolve the PHY_PWR_PHYPWD issue. Now that both of these are controlled by runtime_pm in phy-twl4030-usb, we can simply take a runtime_pm reference to the USB phy whenever the charger wants to use it as a current source. So this patch reverts the above commit, and adds the necessary runtime_pm calls. Signed-off-by: NeilBrown ne...@suse.de --- drivers/mfd/twl-core.c |9 - Acked-by: Lee Jones lee.jo...@linaro.org Thanks. I guess that clear it to go in though the 'power supply' tree. NeilBrown pgpPxECaAk_kV.pgp Description: OpenPGP digital signature
Re: [PATCH 09/15] twl4030_charger: allow max_current to be managed via sysfs.
On Mon, 2 Mar 2015 22:05:26 +0100 Pavel Machek pa...@ucw.cz wrote:
On Tue 2015-02-24 15:33:52, NeilBrown wrote:
'max_current' sysfs attributes are created which allow the
max to be set.
Whenever a current source changes, the default is restored.
This will be followed by a uevent, so user-space can decide to
update again.
Does this need Documentation update?
Oh all right... I've created the relevant documentation in Documentation/ABI.
It seems persistence pays off :-)
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/power/twl4030_charger.c | 76
+++
1 file changed, 76 insertions(+)
diff --git a/drivers/power/twl4030_charger.c
b/drivers/power/twl4030_charger.c
index bfc9b808301e..b0242786d047 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -527,6 +529,67 @@ static irqreturn_t twl4030_bci_interrupt(int irq, void
*arg)
return IRQ_HANDLED;
}
+/*
+ * sysfs max_current store
+ */
That's not exactly useful comment.
Now:
* Provide max_current attribute in sysfs.
+static ssize_t
+twl4030_bci_max_current_store(struct device *dev, struct device_attribute
*attr,
+ const char *buf, size_t n)
+{
+ struct twl4030_bci *bci = dev_get_drvdata(dev-parent);
+ int cur = 0;
+ int status = 0;
+ status = kstrtoint(buf, 10, cur);
+ if (status)
+ return status;
+ if (cur 0)
+ return -EINVAL;
+ if (dev == bci-ac.dev) {
+ if (bci-ac_cur == cur)
+ return n;
+ bci-ac_cur = cur;
+ } else {
+ if (bci-usb_cur == cur)
+ return n;
+ bci-usb_cur = cur;
+ }
+ twl4030_charger_update_current(bci);
+ return (status == 0) ? n : status;
+}
Uff. but we know that status == 0 at this point, no?
Yes. Fixed.
Also... is
optimalization of not calling update_current() when nothing changed
worth it?
Probably not... and code looks a lot nicer if I remove that.
So I have.
+/*
+ * sysfs max_current show
+ */
+static ssize_t twl4030_bci_max_current_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int status = 0;
+ int cur = -1;
+ u8 bcictl1;
+ struct twl4030_bci *bci = dev_get_drvdata(dev-parent);
+
+ if (dev == bci-ac.dev) {
+ if (!bci-ac_is_active)
+ cur = bci-ac_cur;
+ } else {
+ if (bci-ac_is_active)
+ cur = bci-usb_cur;
+ }
+ if (cur 0) {
+ cur = twl4030bci_read_adc_val(TWL4030_BCIIREF1);
+ if (cur 0)
+ return cur;
+ status = twl4030_bci_read(TWL4030_BCICTL1, bcictl1);
+ if (status 0)
+ return status;
+ cur = regval2ua(cur, bcictl1 TWL4030_CGAIN);
+ }
+ return scnprintf(buf, PAGE_SIZE, %u\n, cur);
+}
Is this in uA or mA? uA. Ok.
uA, now described in Documentation/ABI/testing/sysfs-class-power-twl4030
+What: /sys/class/power_supply/twl4030_ac/max_current
+ /sys/class/power_supply/twl4030_usb/max_current
+Description:
+ Read/Write limit on current which which may
+ be drawn from the ac (Accessory Charger) or
+ USB port.
+
+ Value is in micro-Amps.
+
+ Value is set automatically to an appropriate
+ value when a cable is plugged on unplugged.
+
+ Value can the set by writing to the attribute.
+ The change will only persist until the next
+ plug event. These event are reported via udev.
Acked-by: Pavel Machek pa...@ucw.cz
Pavel
Thanks,
NeilBrown
pgpUEAx3Scuug.pgp
Description: OpenPGP digital signature
Re: [PATCH 14/15] twl4030_charger: Increase current carefully while watching voltage.
On Mon, 2 Mar 2015 22:29:45 +0100 Pavel Machek pa...@ucw.cz wrote:
On Tue 2015-02-24 15:33:53, NeilBrown wrote:
The USB Battery Charging spec (BC1.2) suggests a dedicated
charging port can deliver from 0.5 to 5.0A at between 4.75 and 5.25
volts.
To choose the correct current voltage setting requires a trial
and error approach: try to draw current and see if the voltage drops
too low.
Even with a configure Standard Downstream Port, it may not be possible
to reliably pull 500mA - depending on cable quality and source
configured?
quality I have reports of charging failure due to the voltage dropping
too low.
To address both these concern, this patch introduce incremental
concerns.
current setting.
The current pull from VBUS is increased in steps of 20mA every 100ms
until the target is reached or until the measure voltage drops below
4.75V. If the voltage does go too long, the target current is reduced
too low?
by 20mA and kept there.
This applies to currents selected automatically, or to values
set via sysfs. So setting a large value will cause the maximum
available to be used - up to the limit of 1.7mA imposed by the
hardware.
1.7A?
@@ -249,8 +261,14 @@ static int twl4030_charger_update_current(struct
twl4030_bci *bci)
cur = bci-ac_cur;
bci-ac_is_active = 1;
} else {
- cur = bci-usb_cur;
+ cur = bci-usb_cur_actual;
usb_cur_actual is not a really great variable name...
I changed usb_cur to usb_cur_target and
usb_cur_actual to usb_cur.
bci-ac_is_active = 0;
+ if (cur bci-usb_cur) {
+ cur = bci-usb_cur;
+ bci-usb_cur_actual = cur;
+ }
+ if (cur bci-usb_cur)
+ schedule_delayed_work(bci-current_worker,
USB_CUR_DELAY);
}
/* First, check thresholds and see if cgain is needed */
@@ -379,6 +397,38 @@ static int twl4030_charger_update_current(struct
twl4030_bci *bci)
return 0;
}
+static void twl4030_current_worker(struct work_struct *data)
+{
+ int v;
+ int res;
+ struct twl4030_bci *bci = container_of(data, struct twl4030_bci,
+ current_worker.work);
+
+ res = twl4030bci_read_adc_val(TWL4030_BCIVBUS);
+ if (res 0)
+ v = 0;
+ else
+ /* BCIVBUS uses ADCIN8, 7/1023 V/step */
+ v = res * 6843;
+
+ printk(v=%d cur=%d target=%d\n, v, bci-usb_cur_actual,
+ bci-usb_cur);
+
+ if (v USB_MIN_VOLT) {
+ /* Back up and stop adjusting. */
+ bci-usb_cur_actual -= USB_CUR_STEP;
+ bci-usb_cur = bci-usb_cur_actual;
+ } else if (bci-usb_cur_actual = bci-usb_cur ||
+ bci-usb_cur_actual + USB_CUR_STEP USB_MAX_CURRENT) {
+ /* Reach target and volts are OK - stop */
Reached ... and the voltage is OK - stop.
Thanks for all your proof-reading :-)
NeilBrown
pgpJjaK_GqbTb.pgp
Description: OpenPGP digital signature
Re: [PATCH 0/6] mmc: omap_hsmmc: simplify cover/card detect logic
2015-03-04 6:31 GMT+01:00 NeilBrown ne...@suse.de: On Tue, 3 Mar 2015 13:28:12 +0100 Andreas Fenkart afenk...@gmail.com wrote: While cover detect is only used by one platform (rx51), it complicates the card detect logic. By separating the code paths they both become easier to understand and maintain Patches have been tested by reverting: 95bebb5696ab 'mmc: omap_hsmmc: use mmc_of_parse to parse common mmc configuration' otherwise gpio detection is handled by mmc_of_parse Wouldn't it make more sense to put this core in mmc/core rather than in just one host controller? Yes, I would very welcome that, since it would free the omap_hsmmc of the 'protection' mechanism that makes the driver clumsy. But as an initial step separating cover from card detect already seems enough for this series. Another thought was, that since only one platform is using it, the prospect of getting it merged into the core was minimal. That way it would be available to all hosts, and you wouldn't need to revert that patch. Oh sorry, seems I was unclear. I definitely do not want to revert that patch permanently, the opposite is true, I very much welcome it. Thanks for your work by the way. I only reverted it temporarily so I could test that the card detect logic still works with legacy board files, non-device-tree platforms. But since mmc_of_parse is setting the card detect pin, my changes could not be tested with my device-tree platform (bbone). So I reverted the above patch only for testing, afterwards I rebased the patches on top of it, before submitting Andreas -- To unsubscribe from this list: send the line unsubscribe 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 06/15] twl4030_charger: split uA calculation into a function.
On Mon, 2 Mar 2015 22:05:18 +0100 Pavel Machek pa...@ucw.cz wrote:
On Tue 2015-02-24 15:33:51, NeilBrown wrote:
We will need this calculation in other places, so
create functions to map between register value and uA value.
Signed-off-by: NeilBrown ne...@suse.de
Acked-by: Pavel Machek pa...@ucw.cz
Thanks.
+static int regval2ua(int regval, bool cgain)
+{
+ if (cgain)
+ return (regval * 16618 - 8500 * 1000) / 5;
+ else
+ return (regval * 16618 - 8500 * 1000) / 10;
+}
int res = (regval * 16618 - 8500 * 1000);
if (cgain)
return res / 5;
return res / 10;
?
Pavel
Maybe ... not sure it is really more readable. I think I'll leave it as is.
Thanks,
NeilBrown
pgpGQcRlihT4k.pgp
Description: OpenPGP digital signature
Re: [PATCH 3/4] usb: phy: twl4030: add support for reading restore on ID pin.
Hi! New /sys files should be documented somewhere...? Preferably with the code... Does it make sense to change 440k - 440KOhm? Interesting question. I prefer to avoid including units in files - bare numbers is better. But there is no number to match floating unless I spell it out as infinity, and wouldn't be helpful. Certainly K would be preferred over k, and given that I have ground and floating, it is more consistent to include the Ohm These are really names, not measures of resistance. The data sheet calls them: ID_RES_FLOAT (or sometimes ID_FLOAT) ID_RES_440K ID_RES_200K ID_RES_102K ID_GND(or sometimes ID_RES_GND) So using those names is defensible. I think I'll change them all to upper case, but leave out the Ohm. My justification is consistency with the data sheet. Does it make sense to use _ohm in the attribute name, then? (And yes, I was wrong with the K, k is actually right.) Plus I guess you need to update Documentation/ I guess I'll need to give in to this eventually :-) Yes please. It was useful in past. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 11/15] twl4030_charger: enable manual enable/disable of usb charging.
On Wed 2015-03-04 17:15:09, NeilBrown wrote: On Mon, 2 Mar 2015 22:03:42 +0100 Pavel Machek pa...@ucw.cz wrote: On Tue 2015-02-24 15:33:52, NeilBrown wrote: 'off' or 'auto' to /sys/class/power/twl4030_usb/mode will now enable or disable charging from USB port. Normally this is enabled on 'plug' and disabled on 'unplug'. Unplug will still disable charging. 'plug' will only enable it if 'auto' if selected. This should go to Documentation/ You mean in Documentation/ABI/stable I guess?? Yes. That strikes me as a failed experiment - there is hardly anything there. I'd be very happy to put the documentation with the code if there was some mechanism to automatically extract it. But I really see little value in Documentation/ABI. It was useful in past, and rules say it is required. Feel free to talk to greg about better place, but this is the place we have now and documentation is useful. And since you already document it in the changelogs... it should not be that much work. Acked-by: Pavel Machek pa...@ucw.cz Thanks a lot! You are welcome :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 07/15] twl4030_charger: allow fine control of charger current.
Hi! does this help? /* * For ichg_eoc, the hardware only supports reg values matching * 100000, and requires the be stored in the high nibble * of TWL4030_BCIMFTH8 */ A bit, yes. Add . at the end of sentence ;-). (Now I'd need to study the datasheets... and figure out how to enable this on N900). Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [PATCHv2 1/2] HSI: cmt_speech: Add cmt-speech driver
A license nit only. Sebastian Reichel schreef op di 03-03-2015 om 01:44 [+0100]: --- /dev/null +++ b/drivers/hsi/clients/cmt_speech.c @@ -0,0 +1,1457 @@ +/* + * cmt_speech.c - HSI CMT speech driver + * + * Copyright (C) 2008,2009,2010 Nokia Corporation. All rights reserved. + * + * Contact: Kai Vehmanen kai.vehma...@nokia.com + * Original author: Peter Ujfalusi peter.ujfal...@nokia.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + */ This states the license is GPL v2. +MODULE_LICENSE(GPL); So you probably want MODULE_LICENSE(GPL v2); here. Paul Bolle -- To unsubscribe from this list: send the line unsubscribe 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] dma: cppi41: add missing directions bitfield
On Wed, Feb 25, 2015 at 04:54:02PM -0600, Felipe Balbi wrote: Without those we will see a kernel WARN() when loading musb on am335x devices. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/dma/cppi41.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c index 512cb8e2805e..4e9cc8e8100c 100644 --- a/drivers/dma/cppi41.c +++ b/drivers/dma/cppi41.c @@ -926,6 +926,7 @@ static int cppi41_dma_probe(struct platform_device *pdev) cdd-ddev.device_issue_pending = cppi41_dma_issue_pending; cdd-ddev.device_prep_slave_sg = cppi41_dma_prep_slave_sg; cdd-ddev.device_terminate_all = cppi41_stop_chan; + cdd-ddev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV); cdd-ddev.dev = dev; INIT_LIST_HEAD(cdd-ddev.channels); cpp41_dma_info.dma_cap = cdd-ddev.cap_mask; Along with this please set src/dstn_addr_widths and residue_granularity please -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe 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: sdio: support switching to 1-bit before turning off clocks
* NeilBrown ne...@suse.de [150303 21:29]:
On Tue, 3 Mar 2015 14:53:55 -0800 Tony Lindgren t...@atomide.com wrote:
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -367,6 +367,7 @@
};
mmc2 {
+ interrupts-extended = intc 86 omap3_pmx_core 0x12e;
vmmc-supply = vaux4;
bus-width = 4;
ti,non-removable;
I had
+ interrupts-extended = intc 86 gpio5 5 0; /* GPIO_133 */
+ pinctrl-names = default, idle;
+ pinctrl-0 = mmc2_pins;
+ pinctrl-1 = mmc2_cirq_pin;
together with
+ mmc2_cirq_pin: pinmux_cirq_pin {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT_PULLUP |
MUX_MODE4)
+ ;
+ };
+
and a longer definition for mmc2_pins.
Is that one line reconfigure the pin on demand? How does that work?
Well the remuxing of the mmc2 dat1 pin is not needed on omap3/4/5.
These SoCs have the iochain wake-up events.
Remuxing is needed on SoCs with no iochain wake-up events, such as
am355x, am437x and dra7 variants.
Not sure if we actually have the gpio5 bank wake-up the system
properly currently from off-idle. It could be that only gpio1 bank
is currently capable of wake-up from off-idle without needing
to use the iochain wake-up also for GPIO lines.
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
