Re: [PATCH 2/4] ARM: dts: omap5-uevm: Add USB Host support
On Friday 07 June 2013 12:16 AM, Nishanth Menon wrote:
On 23:21-20130606, Sricharan R wrote:
Hi,
On Wednesday 05 June 2013 07:27 PM, Nishanth Menon wrote:
On 12:16-20130605, Sricharan R wrote:
From: Roger Quadros rog...@ti.com
[...]
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 843a001..cf862df 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
snip
+ /* hsusb2_phy is clocked by FREF_CLK1 i.e. auxclk1 */
+ clock_alias {
+ clock-name = auxclk1_ck;
+ clock-alias = main_clk;
is'nt this better to use with clock node?
Roger was suggesting to remove this for now. Postedhen
V2 following that.
Are you suggesting to go with your clock-binding patch ?
you cannot. Mike has already rejected that approach and I have dropped
that series and wont be following up.
See discussion https://patchwork.kernel.org/patch/2541331/
instead the new approach being discussed
https://patchwork.kernel.org/patch/2657351/ and related discussions is
the way to go.
That said, it practically blocks introduction of all code that depend on
dts nodes :(, no matter how I dont like being blocked and my many series
delayed, I believe Mike, Tero, Rajendra are doing the right architecture
and we should wait for it's upstream introduction.
That is just my 2 cents.
Thanks for the details. So dropping the alias for now, should be fine.
Regards,
Sricharan
--
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 v9 1/9] ARM: davinci: move private EDMA API to arm/common
+ Chris since the patch has some davinci_mmc.c changes.
Chris, Mark,
On 3/6/2013 9:45 PM, Matt Porter wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
Can you please ack changes in mmc and sound respectively? I would like
to take the patch for v3.11.
Thanks,
Sekhar
---
arch/arm/Kconfig |1 +
arch/arm/common/Kconfig|3 +
arch/arm/common/Makefile |1 +
arch/arm/{mach-davinci/dma.c = common/edma.c} |2 +-
arch/arm/mach-davinci/Makefile |2 +-
arch/arm/mach-davinci/board-tnetv107x-evm.c|2 +-
arch/arm/mach-davinci/davinci.h|2 +-
arch/arm/mach-davinci/devices-tnetv107x.c |2 +-
arch/arm/mach-davinci/devices.c|6 +-
arch/arm/mach-davinci/dm355.c |2 +-
arch/arm/mach-davinci/dm365.c |2 +-
arch/arm/mach-davinci/dm644x.c |2 +-
arch/arm/mach-davinci/dm646x.c |2 +-
arch/arm/mach-davinci/include/mach/da8xx.h |2 +-
drivers/dma/edma.c |2 +-
drivers/mmc/host/davinci_mmc.c |1 +
include/linux/mfd/davinci_voicecodec.h |3 +-
.../mach = include/linux/platform_data}/edma.h| 89
+---
include/linux/platform_data/spi-davinci.h |2 +-
sound/soc/davinci/davinci-evm.c|1 +
sound/soc/davinci/davinci-pcm.c|1 +
sound/soc/davinci/davinci-pcm.h|2 +-
sound/soc/davinci/davinci-sffsdr.c |5 +-
23 files changed, 33 insertions(+), 104 deletions(-)
rename arch/arm/{mach-davinci/dma.c = common/edma.c} (99%)
rename {arch/arm/mach-davinci/include/mach =
include/linux/platform_data}/edma.h (59%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5b71469..cb80a4d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -956,6 +956,7 @@ config ARCH_DAVINCI
select GENERIC_IRQ_CHIP
select HAVE_IDE
select NEED_MACH_GPIO_H
+ select TI_PRIV_EDMA
select USE_OF
select ZONE_DMA
help
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index 9353184..c3a4e9c 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -17,3 +17,6 @@ config SHARP_PARAM
config SHARP_SCOOP
bool
+
+config TI_PRIV_EDMA
+ bool
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index dc8dd0d..9643c50 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o
obj-$(CONFIG_SHARP_SCOOP)+= scoop.o
obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o
obj-$(CONFIG_ARM_TIMER_SP804)+= timer-sp.o
+obj-$(CONFIG_TI_PRIV_EDMA) += edma.o
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/common/edma.c
similarity index 99%
rename from arch/arm/mach-davinci/dma.c
rename to arch/arm/common/edma.c
index 45b7c71..dcaeb8e 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/common/edma.c
@@ -25,7 +25,7 @@
#include linux/io.h
#include linux/slab.h
-#include mach/edma.h
+#include linux/platform_data/edma.h
/* Offsets matching struct edmacc_param */
#define PARM_OPT 0x00
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index fb5c1aa..493a36b 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -5,7 +5,7 @@
# Common objects
obj-y:= time.o clock.o serial.o psc.o \
-dma.o usb.o common.o sram.o aemif.o
+usb.o common.o sram.o aemif.o
obj-$(CONFIG_DAVINCI_MUX)+= mux.o
diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c
b/arch/arm/mach-davinci/board-tnetv107x-evm.c
index 4f41602..10c9efd 100644
--- a/arch/arm/mach-davinci/board-tnetv107x-evm.c
+++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
@@ -26,12 +26,12 @@
#include linux/input.h
#include linux/input/matrix_keypad.h
#include linux/spi/spi.h
+#include linux/platform_data/edma.h
#include asm/mach/arch.h
#include asm/mach-types.h
#include mach/irqs.h
-#include mach/edma.h
#include mach/mux.h
#include mach/cp_intc.h
#include mach/tnetv107x.h
diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index 12d544b..d26a6bc 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -23,9 +23,9 @@
#include linux/platform_device.h
#include linux/spi/spi.h
#include linux/platform_data/davinci_asp.h
+#include linux/platform_data/edma.h
#include
Re: [PATCH 10/32] OMAPDSS: split overlay manager creation
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
Split the function that creates overlay manager structs into two: one
that creates just the structs, and one that creates the sysfs files for
the manager.
This will help us use the overlay manager structs with omapdrm in the
following patches, while still leaving the sysfs files out.
Maybe the omapdss Makefile should also reflect this change, we could
move manager.o so that it doesn't look like a compat file any more.
Archit
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/apply.c | 9 ++---
drivers/video/omap2/dss/dss.h | 6 --
drivers/video/omap2/dss/manager-sysfs.c | 2 ++
drivers/video/omap2/dss/manager.c | 29 ++---
4 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index b84bd99..74d1d00 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -1577,7 +1577,8 @@ int omapdss_compat_init(void)
apply_init_priv();
- dss_init_overlay_managers(pdev);
+ dss_init_overlay_managers();
+ dss_init_overlay_managers_sysfs(pdev);
dss_init_overlays(pdev);
for (i = 0; i omap_dss_get_num_overlay_managers(); i++) {
@@ -1640,7 +1641,8 @@ err_disp_sysfs:
dss_uninstall_mgr_ops();
err_mgr_ops:
- dss_uninit_overlay_managers(pdev);
+ dss_uninit_overlay_managers_sysfs(pdev);
+ dss_uninit_overlay_managers();
dss_uninit_overlays(pdev);
compat_refcnt--;
@@ -1668,7 +1670,8 @@ void omapdss_compat_uninit(void)
dss_uninstall_mgr_ops();
- dss_uninit_overlay_managers(pdev);
+ dss_uninit_overlay_managers_sysfs(pdev);
+ dss_uninit_overlay_managers();
dss_uninit_overlays(pdev);
out:
mutex_unlock(compat_init_lock);
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 8475893..7964d3b 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -194,8 +194,10 @@ void display_uninit_sysfs(struct platform_device *pdev,
struct omap_dss_device *dssdev);
/* manager */
-int dss_init_overlay_managers(struct platform_device *pdev);
-void dss_uninit_overlay_managers(struct platform_device *pdev);
+int dss_init_overlay_managers(void);
+void dss_uninit_overlay_managers(void);
+int dss_init_overlay_managers_sysfs(struct platform_device *pdev);
+void dss_uninit_overlay_managers_sysfs(struct platform_device *pdev);
int dss_mgr_simple_check(struct omap_overlay_manager *mgr,
const struct omap_overlay_manager_info *info);
int dss_mgr_check_timings(struct omap_overlay_manager *mgr,
diff --git a/drivers/video/omap2/dss/manager-sysfs.c
b/drivers/video/omap2/dss/manager-sysfs.c
index 5104681..72784b3 100644
--- a/drivers/video/omap2/dss/manager-sysfs.c
+++ b/drivers/video/omap2/dss/manager-sysfs.c
@@ -511,4 +511,6 @@ void dss_manager_kobj_uninit(struct omap_overlay_manager
*mgr)
{
kobject_del(mgr-kobj);
kobject_put(mgr-kobj);
+
+ memset(mgr-kobj, 0, sizeof(mgr-kobj));
}
diff --git a/drivers/video/omap2/dss/manager.c
b/drivers/video/omap2/dss/manager.c
index 2551eaa..1aac9b4 100644
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -36,9 +36,9 @@
static int num_managers;
static struct omap_overlay_manager *managers;
-int dss_init_overlay_managers(struct platform_device *pdev)
+int dss_init_overlay_managers(void)
{
- int i, r;
+ int i;
num_managers = dss_feat_get_num_mgrs();
@@ -76,6 +76,17 @@ int dss_init_overlay_managers(struct platform_device *pdev)
dss_feat_get_supported_outputs(mgr-id);
INIT_LIST_HEAD(mgr-overlays);
+ }
+
+ return 0;
+}
+
+int dss_init_overlay_managers_sysfs(struct platform_device *pdev)
+{
+ int i, r;
+
+ for (i = 0; i num_managers; ++i) {
+ struct omap_overlay_manager *mgr = managers[i];
r = dss_manager_kobj_init(mgr, pdev);
if (r)
@@ -85,18 +96,22 @@ int dss_init_overlay_managers(struct platform_device *pdev)
return 0;
}
-void dss_uninit_overlay_managers(struct platform_device *pdev)
+void dss_uninit_overlay_managers(void)
+{
+ kfree(managers);
+ managers = NULL;
+ num_managers = 0;
+}
+
+void dss_uninit_overlay_managers_sysfs(struct platform_device *pdev)
{
int i;
for (i = 0; i num_managers; ++i) {
struct omap_overlay_manager *mgr = managers[i];
+
dss_manager_kobj_uninit(mgr);
}
-
- kfree(managers);
- managers = NULL;
- num_managers = 0;
}
int omap_dss_get_num_overlay_managers(void)
--
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
Re: [PATCH 11/32] OMAPDRM: fix overlay manager handling
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
Currently omapdrm creates crtcs, which map directly to DSS overlay
managers, only on demand at init time. This would make it difficult to
manage connecting the display entities in the future, as the code cannot
just search for a suitable overlay manager.
We cannot fix this the sane way, which would be to create crtcs for each
overlay manager, because we need an overlay for each crtc. With limited
number of overlays, that's not possible.
So the solution for now is to detach the overlay manager from the crtc.
crtcs are still created on demand at init time, but all overlay managers
are always initialized by the omapdss.
This way we can create and connect whole display pipelines from the
overlay manager to the display, regardless of which crtcs omapdrm would
create.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 22 +++---
drivers/gpu/drm/omapdrm/omap_drv.c | 2 ++
drivers/gpu/drm/omapdrm/omap_drv.h | 1 +
drivers/video/omap2/dss/apply.c | 3 ---
drivers/video/omap2/dss/dispc.c | 4
5 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 79b200a..02075bf 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -40,7 +40,7 @@ struct omap_crtc {
* mgr-id.) Eventually this will be replaced w/ something
* more common-panel-framework-y
*/
- struct omap_overlay_manager mgr;
+ struct omap_overlay_manager *mgr;
struct omap_video_timings timings;
bool enabled;
@@ -90,6 +90,9 @@ uint32_t pipe2vbl(struct drm_crtc *crtc)
* job of sequencing the setup of the video pipe in the proper order
*/
+/* ovl-mgr-id - crtc */
+static struct omap_crtc *omap_crtcs[8];
+
/* we can probably ignore these until we support command-mode panels: */
static void omap_crtc_start_update(struct omap_overlay_manager *mgr)
{
@@ -107,7 +110,7 @@ static void omap_crtc_disable(struct omap_overlay_manager
*mgr)
static void omap_crtc_set_timings(struct omap_overlay_manager *mgr,
const struct omap_video_timings *timings)
{
- struct omap_crtc *omap_crtc = container_of(mgr, struct omap_crtc, mgr);
+ struct omap_crtc *omap_crtc = omap_crtcs[mgr-id];
DBG(%s, omap_crtc-name);
omap_crtc-timings = *timings;
omap_crtc-full_update = true;
@@ -116,7 +119,7 @@ static void omap_crtc_set_timings(struct
omap_overlay_manager *mgr,
static void omap_crtc_set_lcd_config(struct omap_overlay_manager *mgr,
const struct dss_lcd_mgr_config *config)
{
- struct omap_crtc *omap_crtc = container_of(mgr, struct omap_crtc, mgr);
+ struct omap_crtc *omap_crtc = omap_crtcs[mgr-id];
DBG(%s, omap_crtc-name);
dispc_mgr_set_lcd_config(omap_crtc-channel, config);
}
@@ -569,7 +572,7 @@ static void omap_crtc_pre_apply(struct omap_drm_apply
*apply)
} else {
if (encoder) {
omap_encoder_set_enabled(encoder, false);
- omap_encoder_update(encoder, omap_crtc-mgr,
+ omap_encoder_update(encoder, omap_crtc-mgr,
omap_crtc-timings);
omap_encoder_set_enabled(encoder, true);
omap_crtc-full_update = false;
@@ -595,6 +598,11 @@ static const char *channel_names[] = {
[OMAP_DSS_CHANNEL_LCD2] = lcd2,
};
Since we are creating overlay managers structs now, we could get rid of
the channel_names strings above and use mgr-name instead. Not
necessary, of course.
Archit
+void omap_crtc_pre_init(void)
+{
+ dss_install_mgr_ops(mgr_ops);
+}
+
/* initialize crtc */
struct drm_crtc *omap_crtc_init(struct drm_device *dev,
struct drm_plane *plane, enum omap_channel channel, int id)
@@ -635,9 +643,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
omap_irq_register(dev, omap_crtc-error_irq);
/* temporary: */
- omap_crtc-mgr.id = channel;
-
- dss_install_mgr_ops(mgr_ops);
+ omap_crtc-mgr = omap_dss_get_overlay_manager(channel);
/* TODO: fix hard-coded setup.. add properties! */
info = omap_crtc-info;
@@ -651,6 +657,8 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
omap_plane_install_properties(omap_crtc-plane, crtc-base);
+ omap_crtcs[channel] = omap_crtc;
+
return crtc;
fail:
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 691e760..f8947f9 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -98,6 +98,8 @@ static int omap_modeset_init(struct drm_device *dev)
int num_crtcs;
int i, id = 0;
+ omap_crtc_pre_init();
+
Re: [PATCH 12/32] OMAPDSS: Implement display (dis)connect support
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
We currently have two steps in panel initialization and startup: probing
and enabling. After the panel has been probed, it's ready and can be
configured and later enabled.
This model is not enough with more complex display pipelines, where we
may have, for example, two panels, of which only one can be used at a
time, connected to the same video output.
To support that kind of scenarios, we need to add new step to the
initialization: connect.
This patch adds support for connecting and disconnecting panels. After
probe, but before connect, no panel ops should be called. When the
connect is called, a proper video pipeline is established, and the panel
is ready for use. If some part in the video pipeline is already
connected (by some other panel), the connect call fails.
One key difference with the old style setup is that connect() handles
also connecting to the overlay manager. This means that the omapfb (or
omapdrm) no longer needs to figure out which overlay manager to use, but
it can just call connect() on the panel, and the proper overlay manager
is connected by omapdss.
This also allows us to add back the support for dynamic switching
between two exclusive panels. However, the current panel device model is
not changed to support this, as the new device model is implemented in
the following patches and the old model will be removed. The new device
model supports dynamic switching.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 24 +
drivers/gpu/drm/omapdrm/omap_drv.c | 12 -
drivers/video/omap2/dss/apply.c | 14 ++
drivers/video/omap2/dss/core.c | 44 +++
drivers/video/omap2/dss/display-sysfs.c | 28 +++-
drivers/video/omap2/dss/manager-sysfs.c | 45
drivers/video/omap2/dss/output.c | 14 ++
drivers/video/omap2/omapfb/omapfb-main.c | 25 ++
include/video/omapdss.h | 23
9 files changed, 188 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 02075bf..b2ab2f5 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -94,6 +94,28 @@ uint32_t pipe2vbl(struct drm_crtc *crtc)
static struct omap_crtc *omap_crtcs[8];
/* we can probably ignore these until we support command-mode panels: */
+static int omap_crtc_connect(struct omap_overlay_manager *mgr,
+ struct omap_dss_output *dst)
+{
+ if (mgr-output)
+ return -EINVAL;
+
+ if ((mgr-supported_outputs dst-id) == 0)
+ return -EINVAL;
+
+ dst-manager = mgr;
+ mgr-output = dst;
+
+ return 0;
+}
+
+static void omap_crtc_disconnect(struct omap_overlay_manager *mgr,
+ struct omap_dss_output *dst)
+{
+ mgr-output-manager = NULL;
+ mgr-output = NULL;
+}
+
static void omap_crtc_start_update(struct omap_overlay_manager *mgr)
{
}
@@ -138,6 +160,8 @@ static void omap_crtc_unregister_framedone_handler(
}
static const struct dss_mgr_ops mgr_ops = {
+ .connect = omap_crtc_connect,
+ .disconnect = omap_crtc_disconnect,
.start_update = omap_crtc_start_update,
.enable = omap_crtc_enable,
.disable = omap_crtc_disable,
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index f8947f9..58bd259 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -97,6 +97,7 @@ static int omap_modeset_init(struct drm_device *dev)
int num_mgrs = dss_feat_get_num_mgrs();
int num_crtcs;
int i, id = 0;
+ int r;
omap_crtc_pre_init();
@@ -118,6 +119,7 @@ static int omap_modeset_init(struct drm_device *dev)
struct drm_connector *connector;
struct drm_encoder *encoder;
enum omap_channel channel;
+ struct omap_overlay_manager *mgr;
if (!dssdev-driver) {
dev_warn(dev-dev, %s has no driver.. skipping it\n,
@@ -133,6 +135,13 @@ static int omap_modeset_init(struct drm_device *dev)
continue;
}
+ r = dssdev-driver-connect(dssdev);
+ if (r) {
+ dev_err(dev-dev, could not connect display: %s\n,
+ dssdev-name);
+ continue;
+ }
+
encoder = omap_encoder_init(dev, dssdev);
if (!encoder) {
@@ -174,8 +183,9 @@ static int omap_modeset_init(struct drm_device *dev)
* other possible channels to which the encoder can connect are
* not considered.
*/
-
Re: [PATCH 14/32] OMAPDSS: DSI: cleanup regulator init
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
Separate the regulator initialization code to its own function, removing
duplicate code.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c | 82 ---
1 file changed, 31 insertions(+), 51 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index b0d..37ca980 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1114,6 +1114,30 @@ void dsi_runtime_put(struct platform_device *dsidev)
WARN_ON(r 0 r != -ENOSYS);
}
+static int dsi_regulator_init(struct platform_device *dsidev)
+{
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ struct regulator *vdds_dsi;
+
+ if (dsi-vdds_dsi_reg != NULL)
+ return 0;
+
+ vdds_dsi = regulator_get(dsi-pdev-dev, vdds_dsi);
+
+ /* DT HACK: try VCXIO to make omapdss work for o4 sdp/panda */
+ if (IS_ERR(vdds_dsi))
+ vdds_dsi = regulator_get(dsi-pdev-dev, VCXIO);
+
We could use devm_ versions here too right?
Archit
+ if (IS_ERR(vdds_dsi)) {
+ DSSERR(can't get VDDS_DSI regulator\n);
+ return PTR_ERR(vdds_dsi);
+ }
+
+ dsi-vdds_dsi_reg = vdds_dsi;
+
+ return 0;
+}
+
/* source clock for DSI PLL. this could also be PCLKFREE */
static inline void dsi_enable_pll_clock(struct platform_device *dsidev,
bool enable)
@@ -1592,22 +1616,9 @@ int dsi_pll_init(struct platform_device *dsidev, bool
enable_hsclk,
*/
enable_hsclk = enable_hsdiv = true;
- if (dsi-vdds_dsi_reg == NULL) {
- struct regulator *vdds_dsi;
-
- vdds_dsi = regulator_get(dsi-pdev-dev, vdds_dsi);
-
- /* DT HACK: try VCXIO to make omapdss work for o4 sdp/panda */
- if (IS_ERR(vdds_dsi))
- vdds_dsi = regulator_get(dsi-pdev-dev, VCXIO);
-
- if (IS_ERR(vdds_dsi)) {
- DSSERR(can't get VDDS_DSI regulator\n);
- return PTR_ERR(vdds_dsi);
- }
-
- dsi-vdds_dsi_reg = vdds_dsi;
- }
+ r = dsi_regulator_init(dsidev);
+ if (r)
+ return r;
dsi_enable_pll_clock(dsidev, 1);
/*
@@ -5225,34 +5236,6 @@ static enum omap_channel dsi_get_channel(int module_id)
}
}
-static int dsi_init_display(struct omap_dss_device *dssdev)
-{
- struct platform_device *dsidev =
- dsi_get_dsidev_from_id(dssdev-phy.dsi.module);
- struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
-
- DSSDBG(DSI init\n);
-
- if (dsi-vdds_dsi_reg == NULL) {
- struct regulator *vdds_dsi;
-
- vdds_dsi = regulator_get(dsi-pdev-dev, vdds_dsi);
-
- /* DT HACK: try VCXIO to make omapdss work for o4 sdp/panda */
- if (IS_ERR(vdds_dsi))
- vdds_dsi = regulator_get(dsi-pdev-dev, VCXIO);
-
- if (IS_ERR(vdds_dsi)) {
- DSSERR(can't get VDDS_DSI regulator\n);
- return PTR_ERR(vdds_dsi);
- }
-
- dsi-vdds_dsi_reg = vdds_dsi;
- }
-
- return 0;
-}
-
int omap_dsi_request_vc(struct omap_dss_device *dssdev, int *channel)
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
@@ -5410,19 +5393,16 @@ static int dsi_probe_pdata(struct platform_device
*dsidev)
if (!plat_dssdev)
return 0;
+ r = dsi_regulator_init(dsidev);
+ if (r)
+ return r;
+
dssdev = dss_alloc_and_init_device(dsidev-dev);
if (!dssdev)
return -ENOMEM;
dss_copy_device_pdata(dssdev, plat_dssdev);
- r = dsi_init_display(dssdev);
- if (r) {
- DSSERR(device %s init failed: %d\n, dssdev-name, r);
- dss_put_device(dssdev);
- return r;
- }
-
r = omapdss_output_set_device(dsi-output, dssdev);
if (r) {
DSSERR(failed to connect output to new device: %s\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: [PATCH 15/32] OMAPDSS: DPI: cleanup pll regulator init
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
Split regulator and DSI PLL init code to their own functions for
clarity.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c | 100 ++
1 file changed, 53 insertions(+), 47 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 43f6b26..66ba9a6 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -545,6 +545,53 @@ static int dpi_verify_dsi_pll(struct platform_device
*dsidev)
return 0;
}
+static int dpi_init_regulator(void)
+{
+ struct regulator *vdds_dsi;
+
+ if (!dss_has_feature(FEAT_DPI_USES_VDDS_DSI))
+ return 0;
+
+ if (dpi.vdds_dsi_reg)
+ return 0;
+
+ vdds_dsi = dss_get_vdds_dsi();
+
+ if (!IS_ERR(vdds_dsi)) {
+ dpi.vdds_dsi_from_core = true;
+ dpi.vdds_dsi_reg = vdds_dsi;
+ return 0;
+ }
+
+ vdds_dsi = regulator_get(dpi.pdev-dev, vdds_dsi);
+ if (!IS_ERR(vdds_dsi)) {
+ dpi.vdds_dsi_from_core = false;
+ dpi.vdds_dsi_reg = vdds_dsi;
+ return 0;
+ }
+
+ return PTR_ERR(vdds_dsi);
+}
+
+static void dpi_init_pll(void)
+{
+ struct platform_device *dsidev;
+
+ if (dpi.dsidev)
+ return;
+
+ dsidev = dpi_get_dsidev(dpi.output.dispc_channel);
+ if (!dsidev)
+ return;
+
+ if (dpi_verify_dsi_pll(dsidev)) {
+ DSSWARN(DSI PLL not operational\n);
+ return;
+ }
+
+ dpi.dsidev = dsidev;
+}
+
/*
* Return a hardcoded channel for the DPI output. This should work for
* current use cases, but this can be later expanded to either resolve
@@ -575,46 +622,6 @@ static enum omap_channel dpi_get_channel(void)
}
}
-static int dpi_init_display(struct omap_dss_device *dssdev)
-{
- struct platform_device *dsidev;
-
- DSSDBG(init_display\n);
-
- if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI)
- dpi.vdds_dsi_reg == NULL) {
- struct regulator *vdds_dsi;
-
- vdds_dsi = dss_get_vdds_dsi();
- if (IS_ERR(vdds_dsi)) {
- vdds_dsi = regulator_get(dpi.pdev-dev, vdds_dsi);
same comment about devm_ usage here, and the next few patches.
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 19/32] OMAPDSS: add videomode conversion support
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote: Add helper functions to convert between omapdss specific video timings and the common videomode. Eventually omapdss will be changed to use only the common video timings, and these helper functions will make the transition easier. So we now use omap_video_timings, videomode, drm_display_mode, and fb_var_screeninfo, fun! :) Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [net-next PATCH v4 1/5] net: cpsw: enhance pinctrl support
On Thu, Jun 6, 2013 at 10:50 AM, Mark Brown broo...@kernel.org wrote: On Thu, Jun 06, 2013 at 11:29:39AM +0530, Mugunthan V N wrote: On 6/6/2013 12:53 AM, Mark Brown wrote: Linus Walleij posted some patches which factor the state setting code out into generic functions earlier on today - it probably makes sense to pick those up rather than open coding But this can go in as Linus Walleij's patch is not accepted yet. Once that is accepted and present in net git repo I will submit a separate patch to use those APIs from pin ctrl core. Linus' change has pretty much gone in already but in any case what would be sensible here would be to write this in turns of Linus' changes and then send the patch to him to add to his series so it can go in via the same route. One of the major reasons for the patch was that lots of people were querying the amount of noise caused by this sort of change. I agree. We should be able to settle on the new core API quite soon, then I can carry the patch to this driver if you obtain David's ACK. Yours, Linus Walleij -- 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: [net-next PATCH v4 1/5] net: cpsw: enhance pinctrl support
From: Linus Walleij linus.wall...@linaro.org Date: Fri, 7 Jun 2013 09:31:58 +0200 On Thu, Jun 6, 2013 at 10:50 AM, Mark Brown broo...@kernel.org wrote: On Thu, Jun 06, 2013 at 11:29:39AM +0530, Mugunthan V N wrote: On 6/6/2013 12:53 AM, Mark Brown wrote: Linus Walleij posted some patches which factor the state setting code out into generic functions earlier on today - it probably makes sense to pick those up rather than open coding But this can go in as Linus Walleij's patch is not accepted yet. Once that is accepted and present in net git repo I will submit a separate patch to use those APIs from pin ctrl core. Linus' change has pretty much gone in already but in any case what would be sensible here would be to write this in turns of Linus' changes and then send the patch to him to add to his series so it can go in via the same route. One of the major reasons for the patch was that lots of people were querying the amount of noise caused by this sort of change. I agree. We should be able to settle on the new core API quite soon, then I can carry the patch to this driver if you obtain David's ACK. If you want to merge the direct networking parts of this series into another tree, I'm fine with that: Acked-by: David S. Miller da...@davemloft.net -- 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 14/14] ARM: OMAP4: hwmod data: Clean up the data file
cc Benoît On Fri, 7 Jun 2013, Sricharan R wrote: I used autogen to remove the data, but some of the data were not in sync with the mainline .(like abe, dss, aess, context register offsets etc..). So i have to sync them manually. OK. Are you going to fix the differences up soon? - Paul
Re: [PATCH 12/32] OMAPDSS: Implement display (dis)connect support
On 07/06/13 09:46, Archit Taneja wrote: @@ -384,6 +424,10 @@ int omap_dss_register_driver(struct omap_dss_driver *dssdriver) omapdss_default_get_recommended_bpp; if (dssdriver-get_timings == NULL) dssdriver-get_timings = omapdss_default_get_timings; +if (dssdriver-connect == NULL) +dssdriver-connect = omapdss_default_connect; +if (dssdriver-disconnect == NULL) +dssdriver-disconnect = omapdss_default_disconnect; I was wondering if these should be apis rather than driver ops. One advantage of having them as functions used by omapfb/omapdrm would be that a panel driver wouldn't override the default_connect/disconnect ops. Even though they are named omapdss_default_connect/disconnect, I don't think there is another option by which a panel driver may chose to connect to omapdss outputs, right? Those default functions are used only for the old panel drivers, and are removed when the old drivers are not needed anymore. They allow us to add the connect support without modifying the old drivers. The new drivers may do other stuff in connect/disconnect. For example, see panel-dsicm.c. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 19/32] OMAPDSS: add videomode conversion support
On 07/06/13 10:06, Archit Taneja wrote: On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote: Add helper functions to convert between omapdss specific video timings and the common videomode. Eventually omapdss will be changed to use only the common video timings, and these helper functions will make the transition easier. So we now use omap_video_timings, videomode, drm_display_mode, and fb_var_screeninfo, fun! :) Yes, although videomode is only used when passing videomode from the board file. I wanted to make that right from the start. omap_video_timings is still used everywhere else in omapdss. Tomi signature.asc Description: OpenPGP digital signature
Re: Request for OMAPDSS testing
On 06/06/13 23:43, Aaro Koskinen wrote: Hi, On Tue, Jun 04, 2013 at 10:40:37AM +0300, Tomi Valkeinen wrote: I've made some big changes on the omapdss device model, which involves converting all the panel drivers. I've got only a bunch of boards, so I hope some of you can perhaps do some minimal tests on some other boards. I've got: Beagle (old one), Panda, 4430SDP, Overo with LCD43. The code can be found from the below git branch. It's based on 3.10-rc1. git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model All you need to do to get things working is to enable the new panel drivers from kernel config, under Device drivers/Graphics support/OMAP2+ Display Subsystem support/OMAP Display Device Drivers/ I tested Nokia N900 by pulling your tree and doing the following .config changes: # CONFIG_PANEL_ACX565AKM is not set CONFIG_PANEL_SONY_ACX565AKM=y The frame buffer console seems to work OK. Excellent, thanks! Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 15/32] OMAPDSS: DPI: cleanup pll regulator init
On 07/06/13 09:51, Archit Taneja wrote:
-static int dpi_init_display(struct omap_dss_device *dssdev)
-{
-struct platform_device *dsidev;
-
-DSSDBG(init_display\n);
-
-if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI)
-dpi.vdds_dsi_reg == NULL) {
-struct regulator *vdds_dsi;
-
-vdds_dsi = dss_get_vdds_dsi();
-if (IS_ERR(vdds_dsi)) {
-vdds_dsi = regulator_get(dpi.pdev-dev, vdds_dsi);
same comment about devm_ usage here, and the next few patches.
Yes, good point. And that allows us to get rid of the 'vdds_dsi_from_core'.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On Friday 07 June 2013 01:22 PM, Paul Walmsley wrote: cc Benoît On Fri, 7 Jun 2013, Sricharan R wrote: I used autogen to remove the data, but some of the data were not in sync with the mainline .(like abe, dss, aess, context register offsets etc..). So i have to sync them manually. OK. Are you going to fix the differences up soon? - Paul + Ambresh and Tero for autogen. Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: Let users disable Probe an I2C bus for certain devices
3) Thinking about Mainline: To reach the same target - no I2C detection - and taking into account above assumption No changes in default behavior the following will need to be done: - change i2c-omap/i2c-gpio DT bindings and add parameter which will allow to change .class value for adapter. Not sure, it's possible because this parameter will be Linux and not HW specific (smth. like i2c_disable_detection) - update drivers i2c-omap/i2c-gpio to use i2c_disable_detection - update OMAP4/5 DTS files So, It seemed a good solution for me to add 6 lines of code in i2c-core.c instead of doing all that stuff. Well... I understand the default behaviour issue, yet I still think that setting class to 0 is the right thing to do. OMAP is an embedded SoC which always had i2c_board_info or devictree which are the preferred ways of instantiating. Given that, I would accept a patch setting it to 0. The more user friendly way might be to introduce a new class which makes users aware of the issue. Proof of concept follows, only compile tested. signature.asc Description: Digital signature
[RFC] i2c: add deprecation warning for class based instantiation
Class based instantiation can cause huge delays when booting. This mechanism was used when it was not possible to describe slaves on I2C busses. We now have other mechanisms, so most embedded I2C will not need classes and it was explicitly not recommended to use them. Add a deprecation warning for drivers who want to disable class based in the near future to gain boot-up time, so users relying on this technique can switch to something better. They really should. Signed-off-by: Wolfram Sang w...@the-dreams.de --- drivers/i2c/busses/i2c-omap.c |2 +- drivers/i2c/i2c-core.c|6 ++ include/linux/i2c.h |1 + 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index e02f9e3..f06109f 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1231,7 +1231,7 @@ omap_i2c_probe(struct platform_device *pdev) adap = dev-adapter; i2c_set_adapdata(adap, dev); adap-owner = THIS_MODULE; - adap-class = I2C_CLASS_HWMON; + adap-class = I2C_CLASS_HWMON | I2C_CLASS_DEPRECATED; strlcpy(adap-name, OMAP I2C adapter, sizeof(adap-name)); adap-algo = omap_i2c_algo; adap-dev.parent = pdev-dev; diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 48e31ed..47ea1f0 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -999,6 +999,12 @@ static int i2c_register_adapter(struct i2c_adapter *adap) return -EINVAL; } + if (adap-class I2C_CLASS_DEPRECATED) + dev_warn(adap-dev, This adapter will soon drop class based + instantiation of slaves\nPlease make sure all its I2C + devices are instantiated by other means.\nCheck + 'Documentation/i2c/instantiating-devices' for details\n); + rt_mutex_init(adap-bus_lock); mutex_init(adap-userspace_clients_lock); INIT_LIST_HEAD(adap-userspace_clients); diff --git a/include/linux/i2c.h b/include/linux/i2c.h index e988fa9..ffab838 100644 --- a/include/linux/i2c.h +++ b/include/linux/i2c.h @@ -473,6 +473,7 @@ void i2c_unlock_adapter(struct i2c_adapter *); #define I2C_CLASS_HWMON(10) /* lm_sensors, ... */ #define I2C_CLASS_DDC (13) /* DDC bus on graphics adapters */ #define I2C_CLASS_SPD (17) /* Memory modules */ +#define I2C_CLASS_DEPRECATED (18) /* Warn users that adapter will stop using classes */ /* Internal numbers to terminate lists */ #define I2C_CLIENT_END 0xfffeU -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On Fri, 2013-06-07 at 14:31 +0530, Sricharan R wrote: On Friday 07 June 2013 01:22 PM, Paul Walmsley wrote: cc Benoît On Fri, 7 Jun 2013, Sricharan R wrote: I used autogen to remove the data, but some of the data were not in sync with the mainline .(like abe, dss, aess, context register offsets etc..). So i have to sync them manually. OK. Are you going to fix the differences up soon? - Paul + Ambresh and Tero for autogen. This is not going to happen soon, if ever. We might consider doing this if a complete overhaul for the hwmod data is going to be done at some point so that re-generating the new format is easier. -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 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On Fri, 7 Jun 2013, Tero Kristo wrote: On Fri, 2013-06-07 at 14:31 +0530, Sricharan R wrote: On Friday 07 June 2013 01:22 PM, Paul Walmsley wrote: cc Benoît On Fri, 7 Jun 2013, Sricharan R wrote: I used autogen to remove the data, but some of the data were not in sync with the mainline .(like abe, dss, aess, context register offsets etc..). So i have to sync them manually. OK. Are you going to fix the differences up soon? - Paul + Ambresh and Tero for autogen. This is not going to happen soon, if ever. We might consider doing this if a complete overhaul for the hwmod data is going to be done at some point so that re-generating the new format is easier. OK. Sricharan, how about reposting the OMAP4 hwmod data patch and drop the comment regarding autogeneration? That will be more accurate and will save some more lines. - Paul
Re: [PATCH 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On Friday 07 June 2013 03:20 PM, Paul Walmsley wrote: On Fri, 7 Jun 2013, Tero Kristo wrote: On Fri, 2013-06-07 at 14:31 +0530, Sricharan R wrote: On Friday 07 June 2013 01:22 PM, Paul Walmsley wrote: cc Benoît On Fri, 7 Jun 2013, Sricharan R wrote: I used autogen to remove the data, but some of the data were not in sync with the mainline .(like abe, dss, aess, context register offsets etc..). So i have to sync them manually. OK. Are you going to fix the differences up soon? - Paul + Ambresh and Tero for autogen. This is not going to happen soon, if ever. We might consider doing this if a complete overhaul for the hwmod data is going to be done at some point so that re-generating the new format is easier. OK. Sricharan, how about reposting the OMAP4 hwmod data patch and drop the comment regarding autogeneration? That will be more accurate and will save some more lines. - Paul ok, sure, i will repost by dropping that comment. Regards, Sricharan -- 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 10/32] OMAPDSS: split overlay manager creation
On 07/06/13 09:19, Archit Taneja wrote: On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote: Split the function that creates overlay manager structs into two: one that creates just the structs, and one that creates the sysfs files for the manager. This will help us use the overlay manager structs with omapdrm in the following patches, while still leaving the sysfs files out. Maybe the omapdss Makefile should also reflect this change, we could move manager.o so that it doesn't look like a compat file any more. It's not quite non-compat file either, as it has compat code also. So more refactoring is needed if to make a proper compat/non-compat division. I'll keep it unchanged for the moment, but at some point it'd be nice to compile the compat stuff only if omapfb is enabled. Or, maybe move the compat stuff into omapfb (but that gives a problem with omap_vout). Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/6] Drop legacy booting for omap4 for v3.11, boot with device tree only
Hi,
On 17/05/13 22:17, Tony Lindgren wrote:
Hi all,
Here are patches against v3.10-rc1 to drop omap4 legacy booting as
things are now working well enough for booting omap4 with device
tree.
We already have am33xx and omap5 booting with device tree only,
and converting omap4 is relatively easy with just two board-*.c
files merged as we have not accepted any new board-*.c files for
quite some time now.
By working well enough I mean that I can use my omap4 panda-es
with device tree with a Motorola LapDock with HDMI, DVI, HID, USB
and WLAN using v3.10-rc1 and the patches in this series plus some
extra patches that are driver related.
Of course some things will need more work, like PM. But that
has not yet been fully working for omap4 anyways, and that
work can now be combined with omap5 PM work to some extent.
You can also add the one below to this series.
Tomi
From d22837262b59ad381feb215496fafe3fe399972f Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Fri, 7 Jun 2013 13:01:05 +0300
Subject: [PATCH] ARM: OMAP2+: Remove legacy DSS initialization for omap4
This is no longer needed as omap4 is now booted using device tree.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/dss-common.c | 47
arch/arm/mach-omap2/dss-common.h | 2 --
2 files changed, 49 deletions(-)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 393aeef..43ec787 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -80,24 +80,6 @@ static struct omap_dss_board_info omap4_panda_dss_data = {
.default_device = omap4_panda_dvi_device,
};
-void __init omap4_panda_display_init(void)
-{
- omap_display_init(omap4_panda_dss_data);
-
- /*
-* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
-* later have external pull up on the HDMI I2C lines
-*/
- if (cpu_is_omap446x() || omap_rev() OMAP4430_REV_ES2_2)
- omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
- else
- omap_hdmi_init(0);
-
- 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);
-}
-
void __init omap4_panda_display_init_of(void)
{
omap_display_init(omap4_panda_dss_data);
@@ -204,35 +186,6 @@ static struct omap_dss_board_info sdp4430_dss_data = {
* used by picodlp on the 4430sdp platform. Keep this gpio disabled as LCD2 is
* selected by default
*/
-void __init omap_4430sdp_display_init(void)
-{
- int r;
-
- r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
- display_sel);
- if (r)
- pr_err(%s: Could not get display_sel GPIO\n, __func__);
-
- r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
- DLP POWER ON);
- if (r)
- pr_err(%s: Could not get DLP POWER ON GPIO\n, __func__);
-
- omap_display_init(sdp4430_dss_data);
- /*
-* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
-* later have external pull up on the HDMI I2C lines
-*/
- if (cpu_is_omap446x() || omap_rev() OMAP4430_REV_ES2_2)
- omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
- else
- omap_hdmi_init(0);
-
- 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);
-}
-
void __init omap_4430sdp_display_init_of(void)
{
int r;
diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h
index 915f6ff..c28fe3c 100644
--- a/arch/arm/mach-omap2/dss-common.h
+++ b/arch/arm/mach-omap2/dss-common.h
@@ -6,9 +6,7 @@
* This file will be removed when DSS supports DT.
*/
-void __init omap4_panda_display_init(void);
void __init omap4_panda_display_init_of(void);
-void __init omap_4430sdp_display_init(void);
void __init omap_4430sdp_display_init_of(void);
#endif
--
1.8.1.2
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] i2c: Let users disable Probe an I2C bus for certain devices
Hi Wolfram, On 06/07/2013 12:06 PM, Wolfram Sang wrote: 3) Thinking about Mainline: To reach the same target - no I2C detection - and taking into account above assumption No changes in default behavior the following will need to be done: - change i2c-omap/i2c-gpio DT bindings and add parameter which will allow to change .class value for adapter. Not sure, it's possible because this parameter will be Linux and not HW specific (smth. like i2c_disable_detection) - update drivers i2c-omap/i2c-gpio to use i2c_disable_detection - update OMAP4/5 DTS files So, It seemed a good solution for me to add 6 lines of code in i2c-core.c instead of doing all that stuff. Well... I understand the default behaviour issue, yet I still think that setting class to 0 is the right thing to do. OMAP is an embedded SoC which always had i2c_board_info or devictree which are the preferred ways of instantiating. Given that, I would accept a patch setting it to 0. The more user friendly way might be to introduce a new class which makes users aware of the issue. Proof of concept follows, only compile tested. That sounds good to me - I can prepare patch for i2c-omap.c. But, there is still an open question regarding *i2c-gpio.c* which, actually, a source of biggest part of delay. Potentially, it can be tunned using timeout value. But, again, this is additional work/patches to workaround unneeded system feature: - timeout should not break interaction with I2C devices on i2c-gpio bus and, at same time, speed up boot; - DTS/board files need to be updated. May be, just may be), we can continue with CONFIG_I2C_DISABLE_DEVICE_DETECTION, and print deprecation warning for each registered adapter if this config option is defined. - grygorii -- 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
[RFC v1] MFD: Change TWL6025 references to TWL6032
From: Graeme Gregory g...@slimlogic.co.uk
The TWL6025 was never released beyond sample form and was replaced by
the PhoenixLite range of chips - TWL6032. Change the references to
reference the TWL6032 class and name the registers to twl6032 in line with
an actual released chip name to avoid confusion.
Currently there is no users of TWL6025 in the code.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: Oleksandr Kozaruk oleksandr.koza...@ti.com
---
There are non-mainline branches that use twl6032 by its name (for example
git://git.omapzoom.org/kernel/omap.git). There is intention to add support
of twl6032 device in mainline, but we'd like to know if we can use twl6032
instead of twl6025 in our new patches, that we are going to provide.
drivers/mfd/twl-core.c| 46 +++---
drivers/regulator/twl-regulator.c | 76 ++---
drivers/usb/phy/phy-twl6030-usb.c |2 +-
include/linux/i2c/twl.h | 30 +++
4 files changed, 77 insertions(+), 77 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 89ab4d9..f39bceb 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -118,7 +118,7 @@
#define TWL6030_BASEADD_GASGAUGE 0x00C0
#define TWL6030_BASEADD_PIH0x00D0
#define TWL6030_BASEADD_CHARGER0x00E0
-#define TWL6025_BASEADD_CHARGER0x00DA
+#define TWL6032_BASEADD_CHARGER0x00DA
#define TWL6030_BASEADD_LED0x00F4
/* subchip/slave 2 0x4A - DFT */
@@ -718,9 +718,9 @@ add_children(struct twl4030_platform_data *pdata, unsigned
irq_base,
| REGULATOR_CHANGE_STATUS,
};
- if (features TWL6025_SUBCLASS) {
+ if (features TWL6032_SUBCLASS) {
usb3v3.supply = ldousb;
- regulator = TWL6025_REG_LDOUSB;
+ regulator = TWL6032_REG_LDOUSB;
} else {
usb3v3.supply = vusb;
regulator = TWL6030_REG_VUSB;
@@ -747,8 +747,8 @@ add_children(struct twl4030_platform_data *pdata, unsigned
irq_base,
usb3v3.dev_name = dev_name(child);
} else if (IS_ENABLED(CONFIG_REGULATOR_TWL4030)
twl_class_is_6030()) {
- if (features TWL6025_SUBCLASS)
- child = add_regulator(TWL6025_REG_LDOUSB,
+ if (features TWL6032_SUBCLASS)
+ child = add_regulator(TWL6032_REG_LDOUSB,
pdata-ldousb, features);
else
child = add_regulator(TWL6030_REG_VUSB,
@@ -872,7 +872,7 @@ add_children(struct twl4030_platform_data *pdata, unsigned
irq_base,
/* twl6030 regulators */
if (IS_ENABLED(CONFIG_REGULATOR_TWL4030) twl_class_is_6030()
- !(features TWL6025_SUBCLASS)) {
+ !(features TWL6032_SUBCLASS)) {
child = add_regulator(TWL6030_REG_VDD1, pdata-vdd1,
features);
if (IS_ERR(child))
@@ -952,60 +952,60 @@ add_children(struct twl4030_platform_data *pdata,
unsigned irq_base,
return PTR_ERR(child);
}
- /* twl6025 regulators */
+ /* twl6032 regulators */
if (IS_ENABLED(CONFIG_REGULATOR_TWL4030) twl_class_is_6030()
- (features TWL6025_SUBCLASS)) {
- child = add_regulator(TWL6025_REG_LDO5, pdata-ldo5,
+ (features TWL6032_SUBCLASS)) {
+ child = add_regulator(TWL6032_REG_LDO5, pdata-ldo5,
features);
if (IS_ERR(child))
return PTR_ERR(child);
- child = add_regulator(TWL6025_REG_LDO1, pdata-ldo1,
+ child = add_regulator(TWL6032_REG_LDO1, pdata-ldo1,
features);
if (IS_ERR(child))
return PTR_ERR(child);
- child = add_regulator(TWL6025_REG_LDO7, pdata-ldo7,
+ child = add_regulator(TWL6032_REG_LDO7, pdata-ldo7,
features);
if (IS_ERR(child))
return PTR_ERR(child);
- child = add_regulator(TWL6025_REG_LDO6, pdata-ldo6,
+ child = add_regulator(TWL6032_REG_LDO6, pdata-ldo6,
features);
if (IS_ERR(child))
return PTR_ERR(child);
- child = add_regulator(TWL6025_REG_LDOLN, pdata-ldoln,
+ child = add_regulator(TWL6032_REG_LDOLN, pdata-ldoln,
features);
Re: [PATCH 14/14] ARM: OMAP4: hwmod data: Clean up the data file
Hi Benoit, On Friday 07 June 2013 04:13 PM, Benoit Cousson wrote: Hi Sricharan, On 06/07/2013 12:27 PM, Sricharan R wrote: - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data is stripped from OMAP4 SOC hwmod data file. - The devices which are still missing the device tree bindings, address space entries are not removed yet. When such devices add the dt bindings, respective address space data can be deleted. - Also other unnessecary hwmods like firewalls are removed as a part of this. typo. Ok, will correct. That part is fine, but you should add that by doing that you have to create new direct link from MPU to EMIFs that did no exist before. Yes, the mpu-emif link is already added in the patch The above update, results in reduction of about ~1650 lines of code. The comment about autogeneration is removed temporarily. Should be brought back after syncing the scripts. You'd better keep it and append a note stating that. If you remove it, I fairly know nobody will ever add it again :-) Ok, will change this then :-) Otherwise the patch looks fine. Thanks, Benoit Regards, Sricharan -- 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 v9 1/9] ARM: davinci: move private EDMA API to arm/common
Hi, On Fri, Jun 07 2013, Sekhar Nori wrote: + Chris since the patch has some davinci_mmc.c changes. Chris, Mark, On 3/6/2013 9:45 PM, Matt Porter wrote: Move mach-davinci/dma.c to common/edma.c so it can be used by OMAP (specifically AM33xx) as well. Signed-off-by: Matt Porter mpor...@ti.com Acked-by: Sekhar Nori nsek...@ti.com Can you please ack changes in mmc and sound respectively? I would like to take the patch for v3.11. For davinci_mmc.c: Acked-by: Chris Ball c...@laptop.org Thanks, - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: dts: AM33XX: Add pinmux configuration for CPSW to beaglebone
Add pinmux configurations for MII based CPSW ethernet to am335x-bone.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Sleep mode is nothing but the values required for the module during
inactive state. The pins are configured to its reset state to optimize
energy usage for the pins for the suspend/resume cycle
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 67 +
1 file changed, 67 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index fd48173..04feaf8 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -56,6 +56,60 @@
0x1b4 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /*
xdma_event_intr1.clkout2 */
;
};
+
+ cpsw_default: cpsw_default {
+ pinctrl-single,pins =
+ /* Slave 1 */
+ 0x110 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxerr.mii1_rxerr */
+ 0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txen.mii1_txen */
+ 0x118 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxdv.mii1_rxdv */
+ 0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd3.mii1_txd3 */
+ 0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd2.mii1_txd2 */
+ 0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd1.mii1_txd1 */
+ 0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd0.mii1_txd0 */
+ 0x12c (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_txclk.mii1_txclk */
+ 0x130 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxclk.mii1_rxclk */
+ 0x134 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxd3.mii1_rxd3 */
+ 0x138 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxd2.mii1_rxd2 */
+ 0x13c (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxd1.mii1_rxd1 */
+ 0x140 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxd0.mii1_rxd0 */
+ ;
+ };
+
+ cpsw_sleep: cpsw_sleep {
+ pinctrl-single,pins =
+ /* Slave 1 reset value */
+ 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x114 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x118 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x11c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x120 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x124 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x128 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x12c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x130 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x134 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x138 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ ;
+ };
+
+ davinci_mdio_default: davinci_mdio_default {
+ pinctrl-single,pins =
+ /* MDIO */
+ 0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST |
MUX_MODE0)/* mdio_data.mdio_data */
+ 0x14c (PIN_OUTPUT_PULLUP | MUX_MODE0)
/* mdio_clk.mdio_clk */
+ ;
+ };
+
+ davinci_mdio_sleep: davinci_mdio_sleep {
+ pinctrl-single,pins =
+ /* MDIO reset value */
+ 0x148 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ ;
+ };
};
ocp {
@@ -165,3 +219,16 @@
cpsw_emac1 {
phy_id = davinci_mdio, 1;
};
+
+mac {
+ pinctrl-names = default, sleep;
+ pinctrl-0 = cpsw_default;
+ pinctrl-1 = cpsw_sleep;
+
+};
+
+davinci_mdio {
+ pinctrl-names = default, sleep;
+ pinctrl-0 = davinci_mdio_default;
+ pinctrl-1 = davinci_mdio_sleep;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: dts: AM33XX: Add pinmux configuration for CPSW to am335x EVM
Add pinmux configurations for RGMII based CPSW ethernet to am335x-evm.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Sleep mode is nothing but the values required for the module during
inactive state. The pins are configured to its reset state to optimize
energy usage for the pins for the suspend/resume cycle
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 64 ++
1 file changed, 64 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 2c53247..a1a0880 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -91,6 +91,58 @@
0x9c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_be0n_cle.gpmc_be0n_cle */
;
};
+
+ cpsw_default: cpsw_default {
+ pinctrl-single,pins =
+ /* Slave 1 */
+ 0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txen.rgmii1_tctl */
+ 0x118 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxdv.rgmii1_rctl */
+ 0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd3.rgmii1_td3 */
+ 0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd2.rgmii1_td2 */
+ 0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd1.rgmii1_td1 */
+ 0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd0.rgmii1_td0 */
+ 0x12c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txclk.rgmii1_tclk */
+ 0x130 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxclk.rgmii1_rclk */
+ 0x134 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd3.rgmii1_rd3 */
+ 0x138 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd2.rgmii1_rd2 */
+ 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd1.rgmii1_rd1 */
+ 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd0.rgmii1_rd0 */
+ ;
+ };
+
+ cpsw_sleep: cpsw_sleep {
+ pinctrl-single,pins =
+ /* Slave 1 reset value */
+ 0x114 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x118 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x11c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x120 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x124 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x128 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x12c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x130 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x134 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x138 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ ;
+ };
+
+ davinci_mdio_default: davinci_mdio_default {
+ pinctrl-single,pins =
+ /* MDIO */
+ 0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST |
MUX_MODE0)/* mdio_data.mdio_data */
+ 0x14c (PIN_OUTPUT_PULLUP | MUX_MODE0)
/* mdio_clk.mdio_clk */
+ ;
+ };
+
+ davinci_mdio_sleep: davinci_mdio_sleep {
+ pinctrl-single,pins =
+ /* MDIO reset value */
+ 0x148 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ ;
+ };
};
ocp {
@@ -378,6 +430,18 @@
};
};
+mac {
+ pinctrl-names = default, sleep;
+ pinctrl-0 = cpsw_default;
+ pinctrl-1 = cpsw_sleep;
+};
+
+davinci_mdio {
+ pinctrl-names = default, sleep;
+ pinctrl-0 = davinci_mdio_default;
+ pinctrl-1 = davinci_mdio_sleep;
+};
+
cpsw_emac0 {
phy_id = davinci_mdio, 0;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Add pinmux DT nodes to CPSW for AM335x
Add pinmux DT nodes to CPSW for the following AM335x boards * AM335x Beaglebone * AM335x EVM * AM335x EVMsk default state contains the pinmux required for active mode and sleep mode contains pinmux reset values for energy saving. Mugunthan V N (3): ARM: dts: AM33XX: Add pinmux configuration for CPSW to beaglebone ARM: dts: AM33XX: Add pinmux configuration for CPSW to EVMsk ARM: dts: AM33XX: Add pinmux configuration for CPSW to am335x EVM arch/arm/boot/dts/am335x-bone.dts | 67 ++ arch/arm/boot/dts/am335x-evm.dts | 64 + arch/arm/boot/dts/am335x-evmsk.dts | 92 3 files changed, 223 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: dts: AM33XX: Add pinmux configuration for CPSW to EVMsk
Add pinmux configurations for RGMII based CPSW ethernet to AM335x EVMsk.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Sleep mode is nothing but the values required for the module during
inactive state. The pins are configured to its reset state to optimize
energy usage for the pins for the suspend/resume cycle
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 92
1 file changed, 92 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 338b681..a0c201d 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -71,6 +71,86 @@
0x1b4 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)
/* xdma_event_intr1.clkout2 */
;
};
+
+ cpsw_default: cpsw_default {
+ pinctrl-single,pins =
+ /* Slave 1 */
+ 0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txen.rgmii1_tctl */
+ 0x118 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxdv.rgmii1_rctl */
+ 0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd3.rgmii1_td3 */
+ 0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd2.rgmii1_td2 */
+ 0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd1.rgmii1_td1 */
+ 0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd0.rgmii1_td0 */
+ 0x12c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txclk.rgmii1_tclk */
+ 0x130 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxclk.rgmii1_rclk */
+ 0x134 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd3.rgmii1_rd3 */
+ 0x138 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd2.rgmii1_rd2 */
+ 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd1.rgmii1_rd1 */
+ 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd0.rgmii1_rd0 */
+
+ /* Slave 2 */
+ 0x40 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a0.rgmii2_tctl */
+ 0x44 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a1.rgmii2_rctl */
+ 0x48 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a2.rgmii2_td3 */
+ 0x4c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a3.rgmii2_td2 */
+ 0x50 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a4.rgmii2_td1 */
+ 0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a5.rgmii2_td0 */
+ 0x58 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a6.rgmii2_tclk */
+ 0x5c (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a7.rgmii2_rclk */
+ 0x60 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a8.rgmii2_rd3 */
+ 0x64 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a9.rgmii2_rd2 */
+ 0x68 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a10.rgmii2_rd1 */
+ 0x6c (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a11.rgmii2_rd0 */
+ ;
+ };
+
+ cpsw_sleep: cpsw_sleep {
+ pinctrl-single,pins =
+ /* Slave 1 reset value */
+ 0x114 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x118 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x11c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x120 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x124 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x128 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x12c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x130 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x134 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x138 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+
+ /* Slave 2 reset value*/
+ 0x40 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x44 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x48 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x4c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x50 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+
[PATCH] ARM: dts: add dtsi for palmas
Adds palmas mfd and palmas regulator nodes. This is
based on the patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
https://lkml.org/lkml/2013/6/6/25
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
arch/arm/boot/dts/palmas.dtsi | 171 +
1 files changed, 171 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/palmas.dtsi
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
new file mode 100644
index 000..be631b5
--- /dev/null
+++ b/arch/arm/boot/dts/palmas.dtsi
@@ -0,0 +1,171 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include dt-bindings/interrupt-controller/irq.h
+
+palmas {
+ compatible = ti,palmas;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ palmas_pmic {
+ compatible = ti,palmas-pmic;
+ interrupt-parent = palmas;
+ interrupts = 14 IRQ_TYPE_NONE;
+ interrupt-name = short-irq;
+
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-name = smps45;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-name = smps6;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-name = smps7;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-name = smps8;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-name = smps9;
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-name = smps10;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-name = ldo1;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-name = ldo2;
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-name = ldo3;
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
+
i2c issue on Panda with DT boot, v3.10-rc4
Hi, I was testing DT boot with 3.10-rc1 and Pandaboard, and couldn't get the DVI output's EDID reading to work. Testing with i2cget and i2cdump, I see that I can read individual bytes with i2cget, but using i2cdump doesn't work, it just shows 'XX'es. The same issue is there with 3.10-rc4, although with that one I get timeouts with i2cdump, whereas there were no timeouts with -rc1. # i2cget -y 2 0x50 0x10 0x0a # i2cget -y 2 0x50 0x20 0x0f # i2cget -y 2 0x50 0x30 0x01 # i2cget -y 2 0x50 0x40 0x36 # i2cget -y 2 0x50 0x50 0x4c # i2cdump -y 2 0x50 No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef 00: 00 [ 72.814086] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 73.825134] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 74.835327] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 76.097167] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 77.160736] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 78.174682] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 79.194824] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 80.242980] omap_i2c 4806.i2c: timeout waiting for bus ready i2cdump works fine with non-DT boot (but the i2c bus number is 3). Any ideas? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH V2 1/4] ARM: dts: omap5: Rename omap5-evm to omap5-uevm
Hi Sricharan,
On 06/06/2013 07:48 PM, Sricharan R wrote:
The uevm is the official board supported for the OMAP5 soc
in mainline. The uevm has an OMAP5432 with a DDR3 memory.
Renaming the board dts file and adding the following cleanups.
OK, so in fact you are not just renaming the board file, you are using
the previous board EVM DTS to describe a completely different board.
You are recycling the old non supported EVM.
You should update the subject and changelog to reflect that, because
that's rather confusing.
* There are no devices connected on I2C 2,3,4 buses. So remove
the pinmux data for the same.
* DDR3 memory is used in the uevm. Neither DVFS or temperature
polling is supported with DDR3. So remove the DDR3 device and
emif nodes.
You should explain why. I don't think this is obvious for people outside TI.
Regards,
Benoit
* Keypad is not supported on uevm. So remove the device node.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/Makefile |2 +-
.../arm/boot/dts/{omap5-evm.dts = omap5-uevm.dts} | 83
+---
2 files changed, 4 insertions(+), 81 deletions(-)
rename arch/arm/boot/dts/{omap5-evm.dts = omap5-uevm.dts} (73%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f0895c5..13b86bf 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -149,7 +149,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap4-panda-es.dtb \
omap4-var-som.dtb \
omap4-sdp.dtb \
- omap5-evm.dtb \
+ omap5-uevm.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb
diff --git a/arch/arm/boot/dts/omap5-evm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
similarity index 73%
rename from arch/arm/boot/dts/omap5-evm.dts
rename to arch/arm/boot/dts/omap5-uevm.dts
index 22e9ee8..843a001 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -8,11 +8,10 @@
/dts-v1/;
#include omap5.dtsi
-#include samsung_k3pe0e000b.dtsi
/ {
- model = TI OMAP5 EVM board;
- compatible = ti,omap5-evm, ti,omap5;
+ model = TI OMAP5 uEVM board;
+ compatible = ti,omap5-uevm, ti,omap5;
memory {
device_type = memory;
@@ -88,27 +87,6 @@
;
};
- i2c2_pins: pinmux_i2c2_pins {
- pinctrl-single,pins =
- 0x178 (PIN_INPUT | MUX_MODE0) /* i2c2_scl */
- 0x17a (PIN_INPUT | MUX_MODE0) /* i2c2_sda */
- ;
- };
-
- i2c3_pins: pinmux_i2c3_pins {
- pinctrl-single,pins =
- 0x13a (PIN_INPUT | MUX_MODE0) /* i2c3_scl */
- 0x13c (PIN_INPUT | MUX_MODE0) /* i2c3_sda */
- ;
- };
-
- i2c4_pins: pinmux_i2c4_pins {
- pinctrl-single,pins =
- 0xb8 (PIN_INPUT | MUX_MODE0)/* i2c4_scl */
- 0xba (PIN_INPUT | MUX_MODE0)/* i2c4_sda */
- ;
- };
-
i2c5_pins: pinmux_i2c5_pins {
pinctrl-single,pins =
0x184 (PIN_INPUT | MUX_MODE0) /* i2c5_scl */
@@ -175,39 +153,6 @@
clock-frequency = 40;
};
-i2c2 {
- pinctrl-names = default;
- pinctrl-0 = i2c2_pins;
-
- clock-frequency = 40;
-
- /* Pressure Sensor */
- bmp085@77 {
- compatible = bosch,bmp085;
- reg = 0x77;
- };
-};
-
-i2c3 {
- pinctrl-names = default;
- pinctrl-0 = i2c3_pins;
-
- clock-frequency = 40;
-};
-
-i2c4 {
- pinctrl-names = default;
- pinctrl-0 = i2c4_pins;
-
- clock-frequency = 40;
-
- /* Temperature Sensor */
- tmp102@48{
- compatible = ti,tmp102;
- reg = 0x48;
- };
-};
-
i2c5 {
pinctrl-names = default;
pinctrl-0 = i2c5_pins;
@@ -215,32 +160,10 @@
clock-frequency = 40;
};
-keypad {
- keypad,num-rows = 8;
- keypad,num-columns = 8;
- linux,keymap = 0x02020073 /* VOLUP */
- 0x02030072 /* VOLDOWM */
- 0x020400e7 /* SEND */
- 0x02050066 /* HOME */
- 0x0206006b /* END */
- 0x020700d9;/* SEARCH */
- linux,input-no-autorepeat;
-};
-
mcbsp3 {
status = disabled;
};
-emif1 {
- cs1-used;
- device-handle = samsung_K3PE0E000B;
-};
-
-emif2 {
- cs1-used;
-
Re: [PATCH V2 0/4] ARM: dts: omap5: Cleanup and updates for DT files
On 06/06/2013 07:48 PM, Sricharan R wrote: uevm is the official board supported for OMAP5 soc in the mainline. This series renames the board dts file for OMAP5 accordingly and cleans up the same. Also a few additional device DT entry updates are done. This is on top of the below branch git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Could you update your branch before reposting, I pulled a Makefile fix for AM5xx that prevents your patches to be applied properly. Thanks, Benoit Boot tested on omap5-uevm after pulling in the data from below place git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git HWMOD DATA: for_3.11/omap5_data_files CLOCK DATA: out_of_tree/omap5_clk_data Dan Murphy (1): ARM: dts: omap5-uevm: Add LED support for uEVM blue LED Roger Quadros (1): ARM: dts: omap5-uevm: Add USB Host support Sourav Poddar (1): ARM: dts: omap5-uevm: Add uart pinctrl data Sricharan R (1): ARM: dts: omap5: Rename omap5-evm to omap5-uevm arch/arm/boot/dts/Makefile |2 +- arch/arm/boot/dts/omap5-evm.dts | 261 arch/arm/boot/dts/omap5-uevm.dts | 311 ++ arch/arm/boot/dts/omap5.dtsi | 30 4 files changed, 342 insertions(+), 262 deletions(-) delete mode 100644 arch/arm/boot/dts/omap5-evm.dts create mode 100644 arch/arm/boot/dts/omap5-uevm.dts -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: add dtsi for palmas
Hi Keerthy,
On 06/07/2013 01:28 PM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes. This is
based on the patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
https://lkml.org/lkml/2013/6/6/25
It looks like the board node to use palmas is missing? I cannot find it
in the previous series as well?
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
arch/arm/boot/dts/palmas.dtsi | 171
+
1 files changed, 171 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/palmas.dtsi
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
new file mode 100644
index 000..be631b5
--- /dev/null
+++ b/arch/arm/boot/dts/palmas.dtsi
@@ -0,0 +1,171 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include dt-bindings/interrupt-controller/irq.h
+
+palmas {
+ compatible = ti,palmas;
+ interrupt-controller;
+ #interrupt-cells = 2;
The I2C address should be there as well. We used to put it in the board
file, but this is really an I2C device specific information and not
board specific in that case.
Regards,
Benoit
+
+ palmas_pmic {
+ compatible = ti,palmas-pmic;
+ interrupt-parent = palmas;
+ interrupts = 14 IRQ_TYPE_NONE;
+ interrupt-name = short-irq;
+
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-name = smps45;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-name = smps6;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-name = smps7;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-name = smps8;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-name = smps9;
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-name = smps10;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-name = ldo1;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-name = ldo2;
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ regulator-always-on;
+
RE: [PATCH] ARM: dts: add dtsi for palmas
Hi Benoit,
Thanks for the quick response.
From: Cousson, Benoit
Sent: Friday, June 07, 2013 5:57 PM
To: J, KEERTHY
Cc: devicetree-disc...@lists.ozlabs.org; linux-omap@vger.kernel.org;
linux-ker...@vger.kernel.org; ldewan...@nvidia.com; grant.lik...@secretlab.ca;
swar...@wwwdotorg.org; swar...@nvidia.com; sa...@linux.intel.com;
g...@slimlogic.co.uk; lee.jo...@linaro.org
Subject: Re: [PATCH] ARM: dts: add dtsi for palmas
Hi Keerthy,
On 06/07/2013 01:28 PM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes. This is
based on the patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
https://lkml.org/lkml/2013/6/6/25
It looks like the board node to use palmas is missing? I cannot find it
in the previous series as well?
Yes. This is just the palmas.dtsi which will be included in the board file.
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
arch/arm/boot/dts/palmas.dtsi | 171
+
1 files changed, 171 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/palmas.dtsi
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
new file mode 100644
index 000..be631b5
--- /dev/null
+++ b/arch/arm/boot/dts/palmas.dtsi
@@ -0,0 +1,171 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include dt-bindings/interrupt-controller/irq.h
+
+palmas {
+ compatible = ti,palmas;
+ interrupt-controller;
+ #interrupt-cells = 2;
The I2C address should be there as well. We used to put it in the board
file, but this is really an I2C device specific information and not
board specific in that case.
This again i will send another patch on top of the existing board
file. That will have the I2C address. This patch only adds the
standalone palmas.dtsi.
Regards,
Keerthy
Regards,
Benoit
+
+ palmas_pmic {
+ compatible = ti,palmas-pmic;
+ interrupt-parent = palmas;
+ interrupts = 14 IRQ_TYPE_NONE;
+ interrupt-name = short-irq;
+
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-name = smps45;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-name = smps6;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-name = smps7;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-name = smps8;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-name = smps9;
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-name = smps10;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+
Re: [PATCH V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On Fri, 7 Jun 2013, Sricharan R wrote: - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data is stripped from OMAP4 SOC hwmod data file. - The devices which are still missing the device tree bindings, address space entries are not removed yet. When such devices add the dt bindings, respective address space data can be deleted. - Also other unnecessary hwmods like firewalls are removed as a part of this. Since emif was getting registered only because of this firewalls links, the mpu-emif direct link is added now. The above update, results in reduction of about ~1650 lines of code. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Can't test this one since I don't have an OMAP4 DT config set up in the testbed yet. Maybe will add that to the testbed after the v3.10 release. - 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: i2c issue on Panda with DT boot, v3.10-rc4
hi Tomi,
On 06/07/2013 02:53 PM, Tomi Valkeinen wrote:
Hi,
I was testing DT boot with 3.10-rc1 and Pandaboard, and couldn't get the
DVI output's EDID reading to work. Testing with i2cget and i2cdump, I
see that I can read individual bytes with i2cget, but using i2cdump
doesn't work, it just shows 'XX'es.
The same issue is there with 3.10-rc4, although with that one I get
timeouts with i2cdump, whereas there were no timeouts with -rc1.
# i2cget -y 2 0x50 0x10
0x0a
# i2cget -y 2 0x50 0x20
0x0f
# i2cget -y 2 0x50 0x30
0x01
# i2cget -y 2 0x50 0x40
0x36
# i2cget -y 2 0x50 0x50
0x4c
# i2cdump -y 2 0x50
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef
00: 00 [ 72.814086] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 73.825134] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 74.835327] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 76.097167] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 77.160736] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 78.174682] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 79.194824] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 80.242980] omap_i2c 4806.i2c: timeout waiting for bus ready
i2cdump works fine with non-DT boot (but the i2c bus number is 3).
Any ideas?
Tomi
Could you check if below change will help you, pls?
iff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 13d1eca..66a62e7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -615,11 +615,11 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (dev-cmd_err OMAP_I2C_STAT_NACK) {
if (msg-flags I2C_M_IGNORE_NAK)
return 0;
- if (stop) {
- w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
- w |= OMAP_I2C_CON_STP;
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
- }
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
+ w |= OMAP_I2C_CON_STP;
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
+
return -EREMOTEIO;
}
return -EIO;
-grygorii
--
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: i2c issue on Panda with DT boot, v3.10-rc4
On 07/06/13 15:36, Grygorii Strashko wrote:
Could you check if below change will help you, pls?
iff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 13d1eca..66a62e7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -615,11 +615,11 @@ static int omap_i2c_xfer_msg(struct i2c_adapter
*adap,
if (dev-cmd_err OMAP_I2C_STAT_NACK) {
if (msg-flags I2C_M_IGNORE_NAK)
return 0;
- if (stop) {
- w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
- w |= OMAP_I2C_CON_STP;
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
- }
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
+ w |= OMAP_I2C_CON_STP;
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
+
return -EREMOTEIO;
}
return -EIO;
With that one, I don't get timeouts, but it still doesn't work (i.e.
behavior is the same as on -rc1).
When I run i2cdump the first time, I see that it (probably) manages to
read the first byte, as that's 00. Everything after that are 'XX'es.
Tomi
signature.asc
Description: OpenPGP digital signature
[PATCH V3 1/4] ARM: dts: omap5: Make uevm as the official board and deprecate sevm support
The uevm is the only official board supported for the OMAP5 soc
in mainline. The existent sevm platform will no more be supported.
Hence cleaning up the board dts file to have only the data
required for uevm.
Renaming the board dts file and adding the following cleanups.
* There are no devices connected on I2C 2,3,4 buses. So remove
the pinmux data for the same.
* OMAP5432 and DDR3 memory is used in the uevm. Temperature polling
is not supported with DDR3 memories. Because of DDR3 phy limitation
the voltage change across DVFS and all shadow registers for DVFS on
DDR3 is not supported. Hence the emif kernel driver is not required,
so removing the DDR3 device file and emif nodes for uevm.
* Keypad is not supported on uevm. So remove the device node.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V3] Rebased on top of Benoit's latest tip and improved the subject, changelog
arch/arm/boot/dts/Makefile |2 +-
.../arm/boot/dts/{omap5-evm.dts = omap5-uevm.dts} | 83 +---
2 files changed, 4 insertions(+), 81 deletions(-)
rename arch/arm/boot/dts/{omap5-evm.dts = omap5-uevm.dts} (73%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bd388b1..8e50761 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -150,7 +150,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap4-var-som.dtb \
omap4-sdp.dtb \
omap4-sdp-es23plus.dtb \
- omap5-evm.dtb \
+ omap5-uevm.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-uevm.dts
similarity index 73%
rename from arch/arm/boot/dts/omap5-evm.dts
rename to arch/arm/boot/dts/omap5-uevm.dts
index 22e9ee8..843a001 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -8,11 +8,10 @@
/dts-v1/;
#include omap5.dtsi
-#include samsung_k3pe0e000b.dtsi
/ {
- model = TI OMAP5 EVM board;
- compatible = ti,omap5-evm, ti,omap5;
+ model = TI OMAP5 uEVM board;
+ compatible = ti,omap5-uevm, ti,omap5;
memory {
device_type = memory;
@@ -88,27 +87,6 @@
;
};
- i2c2_pins: pinmux_i2c2_pins {
- pinctrl-single,pins =
- 0x178 (PIN_INPUT | MUX_MODE0) /* i2c2_scl */
- 0x17a (PIN_INPUT | MUX_MODE0) /* i2c2_sda */
- ;
- };
-
- i2c3_pins: pinmux_i2c3_pins {
- pinctrl-single,pins =
- 0x13a (PIN_INPUT | MUX_MODE0) /* i2c3_scl */
- 0x13c (PIN_INPUT | MUX_MODE0) /* i2c3_sda */
- ;
- };
-
- i2c4_pins: pinmux_i2c4_pins {
- pinctrl-single,pins =
- 0xb8 (PIN_INPUT | MUX_MODE0)/* i2c4_scl */
- 0xba (PIN_INPUT | MUX_MODE0)/* i2c4_sda */
- ;
- };
-
i2c5_pins: pinmux_i2c5_pins {
pinctrl-single,pins =
0x184 (PIN_INPUT | MUX_MODE0) /* i2c5_scl */
@@ -175,39 +153,6 @@
clock-frequency = 40;
};
-i2c2 {
- pinctrl-names = default;
- pinctrl-0 = i2c2_pins;
-
- clock-frequency = 40;
-
- /* Pressure Sensor */
- bmp085@77 {
- compatible = bosch,bmp085;
- reg = 0x77;
- };
-};
-
-i2c3 {
- pinctrl-names = default;
- pinctrl-0 = i2c3_pins;
-
- clock-frequency = 40;
-};
-
-i2c4 {
- pinctrl-names = default;
- pinctrl-0 = i2c4_pins;
-
- clock-frequency = 40;
-
- /* Temperature Sensor */
- tmp102@48{
- compatible = ti,tmp102;
- reg = 0x48;
- };
-};
-
i2c5 {
pinctrl-names = default;
pinctrl-0 = i2c5_pins;
@@ -215,32 +160,10 @@
clock-frequency = 40;
};
-keypad {
- keypad,num-rows = 8;
- keypad,num-columns = 8;
- linux,keymap = 0x02020073 /* VOLUP */
- 0x02030072 /* VOLDOWM */
- 0x020400e7 /* SEND */
- 0x02050066 /* HOME */
- 0x0206006b /* END */
- 0x020700d9;/* SEARCH */
- linux,input-no-autorepeat;
-};
-
mcbsp3 {
status = disabled;
};
-emif1 {
- cs1-used;
- device-handle = samsung_K3PE0E000B;
-};
-
-emif2 {
- cs1-used;
- device-handle = samsung_K3PE0E000B;
-};
-
mcspi1 {
};
--
1.7.9.5
[PATCH V3 4/4] ARM: dts: omap5-uevm: Add uart pinctrl data
From: Sourav Poddar sourav.pod...@ti.com
Booting omap5 uevm results in the following error
did not get pins for uart error: -19
This happens because omap5 uevm dts file is not adapted to use uart through
pinctrl
framework. Populating uart pinctrl data to get rid of the error.
Cc: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
[Sricharan R r.sricha...@ti.com: Replaced constants with preprocessor macros]
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 41 ++
1 file changed, 41 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 6e8bb86..927db1e 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -184,6 +184,32 @@
0x196 (PIN_OUTPUT | MUX_MODE6) /*
uart3_cts_rctx.gpio5_153 */
;
};
+
+ uart1_pins: pinmux_uart1_pins {
+ pinctrl-single,pins =
+ 0x60 (PIN_OUTPUT | MUX_MODE0) /* uart1_tx.uart1_cts */
+ 0x62 (PIN_INPUT_PULLUP | MUX_MODE0) /*
uart1_tx.uart1_cts */
+ 0x64 (PIN_INPUT_PULLUP | MUX_MODE0) /*
uart1_rx.uart1_rts */
+ 0x66 (PIN_OUTPUT | MUX_MODE0) /* uart1_rx.uart1_rts */
+ ;
+ };
+
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins =
+ 0x19a (PIN_OUTPUT | MUX_MODE0) /*
uart3_rts_irsd.uart3_tx_irtx */
+ 0x19c (PIN_INPUT_PULLUP | MUX_MODE0) /*
uart3_rx_irrx.uart3_usbb3_hsic */
+ ;
+ };
+
+ uart5_pins: pinmux_uart5_pins {
+ pinctrl-single,pins =
+ 0x170 (PIN_INPUT_PULLUP | MUX_MODE0) /*
uart5_rx.uart5_rx */
+ 0x172 (PIN_OUTPUT | MUX_MODE0) /* uart5_tx.uart5_tx */
+ 0x174 (PIN_INPUT_PULLUP | MUX_MODE0) /*
uart5_cts.uart5_rts */
+ 0x176 (PIN_OUTPUT | MUX_MODE0) /* uart5_cts.uart5_rts */
+ ;
+ };
+
};
omap5_pmx_wkup {
@@ -268,3 +294,18 @@
pinctrl-names = default;
pinctrl-0 = mcspi4_pins;
};
+
+uart1 {
+pinctrl-names = default;
+pinctrl-0 = uart1_pins;
+};
+
+uart3 {
+pinctrl-names = default;
+pinctrl-0 = uart3_pins;
+};
+
+uart5 {
+pinctrl-names = default;
+pinctrl-0 = uart5_pins;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 0/4] ARM: dts: omap5: Cleanup and updates for DT files
uevm is the only official board supported for OMAP5 soc in the mainline. This series deprecates the support for existent sevm which will no more be supported in mainline and renames the board dts file accordingly. Also a few additional device DT entry updates are done. This is on top of the below branch git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Boot tested on omap5-uevm after pulling in the data from below place git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git HWMOD DATA: for_3.11/omap5_data_files CLOCK DATA: out_of_tree/omap5_clk_data Dan Murphy (1): ARM: dts: omap5-uevm: Add LED support for uEVM blue LED Roger Quadros (1): ARM: dts: omap5-uevm: Add USB Host support Sourav Poddar (1): ARM: dts: omap5-uevm: Add uart pinctrl data Sricharan R (1): ARM: dts: omap5: Make uevm as the official board and deprecate sevm support arch/arm/boot/dts/Makefile |2 +- arch/arm/boot/dts/omap5-evm.dts | 261 arch/arm/boot/dts/omap5-uevm.dts | 311 ++ arch/arm/boot/dts/omap5.dtsi | 30 4 files changed, 342 insertions(+), 262 deletions(-) delete mode 100644 arch/arm/boot/dts/omap5-evm.dts create mode 100644 arch/arm/boot/dts/omap5-uevm.dts -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 2/4] ARM: dts: omap5-uevm: Add USB Host support
From: Roger Quadros rog...@ti.com
Provide the RESET regulators for the USB PHYs, the USB Host
port modes and the PHY devices.
Also provide pin multiplexer information for the USB host
pins.
Cc: Roger Quadros rog...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
[Sricharan R r.sricha...@ti.com: Replaced constants with preprocessor macros]
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 70 ++
arch/arm/boot/dts/omap5.dtsi | 30
2 files changed, 100 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 843a001..a31e42f 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -25,6 +25,40 @@
regulator-max-microvolt = 300;
};
+ /* HS USB Port 2 RESET */
+ hsusb2_reset: hsusb2_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio3 16 GPIO_ACTIVE_HIGH; /* gpio3_80 HUB_NRESET */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Host PHY on PORT 2 */
+ hsusb2_phy: hsusb2_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb2_reset;
+ };
+
+ /* HS USB Port 3 RESET */
+ hsusb3_reset: hsusb3_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb3_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio3 15 GPIO_ACTIVE_HIGH; /* gpio3_79 ETH_NRESET */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Host PHY on PORT 3 */
+ hsusb3_phy: hsusb3_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb3_reset;
+ };
+
};
omap5_pmx_core {
@@ -35,6 +69,7 @@
dmic_pins
mcbsp1_pins
mcbsp2_pins
+ usbhost_pins
;
twl6040_pins: pinmux_twl6040_pins {
@@ -120,6 +155,32 @@
0x16c (PIN_INPUT | MUX_MODE1) /* mcspi2_cs */
;
};
+
+ usbhost_pins: pinmux_usbhost_pins {
+ pinctrl-single,pins =
+ 0x84 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_strobe */
+ 0x86 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_data */
+
+ 0x19e (PIN_INPUT | MUX_MODE0) /* usbb3_hsic_strobe */
+ 0x1a0 (PIN_INPUT | MUX_MODE0) /* usbb3_hsic_data */
+
+ 0x70 (PIN_OUTPUT | MUX_MODE6) /* gpio3_80 HUB_NRESET */
+ 0x6e (PIN_OUTPUT | MUX_MODE6) /* gpio3_79 ETH_NRESET */
+ ;
+ };
+};
+
+omap5_pmx_wkup {
+ pinctrl-names = default;
+ pinctrl-0 =
+ usbhost_wkup_pins
+ ;
+
+ usbhost_wkup_pins: pinmux_usbhost_wkup_pins {
+ pinctrl-single,pins =
+ 0x1A (PIN_OUTPUT | MUX_MODE0) /* fref_clk1_out, USB hub
clk */
+ ;
+ };
};
mmc1 {
@@ -164,6 +225,15 @@
status = disabled;
};
+usbhshost {
+ port2-mode = ehci-hsic;
+ port3-mode = ehci-hsic;
+};
+
+usbhsehci {
+ phys = 0 hsusb2_phy hsusb3_phy;
+};
+
mcspi1 {
};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 1e84db8..accab62 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -666,5 +666,35 @@
ctrl-module = omap_control_usb;
};
};
+
+ usbhstll: usbhstll@4a062000 {
+ compatible = ti,usbhs-tll;
+ reg = 0x4a062000 0x1000;
+ interrupts = GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = usb_tll_hs;
+ };
+
+ usbhshost: usbhshost@4a064000 {
+ compatible = ti,usbhs-host;
+ reg = 0x4a064000 0x800;
+ ti,hwmods = usb_host_hs;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ usbhsohci: ohci@4a064800 {
+ compatible = ti,ohci-omap3, usb-ohci;
+ reg = 0x4a064800 0x400;
+ interrupt-parent = gic;
+ interrupts = GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH;
+ };
+
+ usbhsehci: ehci@4a064c00 {
+ compatible = ti,ehci-omap, usb-ehci;
+ reg =
[PATCH V3 3/4] ARM: dts: omap5-uevm: Add LED support for uEVM blue LED
From: Dan Murphy dmur...@ti.com
Add support for blue LED 1 off of GPIO 153.
Make the LED a heartbeat LED
Configure the MUX for GPIO output.
Cc: Dan Murphy dmur...@ti.com
Signed-off-by: Dan Murphy dmur...@ti.com
[Sricharan R r.sricha...@ti.com: Replaced constants with preprocessor macros]
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index a31e42f..6e8bb86 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -59,6 +59,15 @@
reset-supply = hsusb3_reset;
};
+ leds {
+ compatible = gpio-leds;
+ led@1 {
+ label = omap5:blue:usr1;
+ gpios = gpio5 25 GPIO_ACTIVE_HIGH; /* gpio5_153 D1
LED */
+ linux,default-trigger = heartbeat;
+ default-state = off;
+ };
+ };
};
omap5_pmx_core {
@@ -70,6 +79,7 @@
mcbsp1_pins
mcbsp2_pins
usbhost_pins
+ led_gpio_pins
;
twl6040_pins: pinmux_twl6040_pins {
@@ -168,6 +178,12 @@
0x6e (PIN_OUTPUT | MUX_MODE6) /* gpio3_79 ETH_NRESET */
;
};
+
+ led_gpio_pins: pinmux_led_gpio_pins {
+ pinctrl-single,pins =
+ 0x196 (PIN_OUTPUT | MUX_MODE6) /*
uart3_cts_rctx.gpio5_153 */
+ ;
+ };
};
omap5_pmx_wkup {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 0/4] ARM: dts: omap5: Cleanup and updates for DT files
On Friday 07 June 2013 05:36 PM, Benoit Cousson wrote: On 06/06/2013 07:48 PM, Sricharan R wrote: uevm is the official board supported for OMAP5 soc in the mainline. This series renames the board dts file for OMAP5 accordingly and cleans up the same. Also a few additional device DT entry updates are done. This is on top of the below branch git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Could you update your branch before reposting, I pulled a Makefile fix for AM5xx that prevents your patches to be applied properly. Ok, rebased and posted V3. Regards, Sricharan -- 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/4] ARM: dts: omap5: Rename omap5-evm to omap5-uevm
On Friday 07 June 2013 05:33 PM, Benoit Cousson wrote: Hi Sricharan, On 06/06/2013 07:48 PM, Sricharan R wrote: The uevm is the official board supported for the OMAP5 soc in mainline. The uevm has an OMAP5432 with a DDR3 memory. Renaming the board dts file and adding the following cleanups. OK, so in fact you are not just renaming the board file, you are using the previous board EVM DTS to describe a completely different board. You are recycling the old non supported EVM. You should update the subject and changelog to reflect that, because that's rather confusing. Ok, reposted V3. * There are no devices connected on I2C 2,3,4 buses. So remove the pinmux data for the same. * DDR3 memory is used in the uevm. Neither DVFS or temperature polling is supported with DDR3. So remove the DDR3 device and emif nodes. You should explain why. I don't think this is obvious for people outside TI. Ok, updated this in V3. Regards, Sricharan -- 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 09/11] mmc: omap_hsmmc: enhance pinctrl support
On Tuesday 04 June 2013 08:16 PM, Tony Lindgren wrote: * Hebbar Gururaja gururaja.heb...@ti.com [130531 03:19]: Amend the hsmmc controller to optionally take a pin control handle and set the state of the pins to: - default on boot, resume and before performing a mmc transfer - idle after initial default, after resume default, and after each mmc/sd card access - sleep on suspend() By optionally putting the pins into sleep state in the suspend callback we can accomplish two things. - One is to minimize current leakage from pins and thus save power, - second, we can prevent the IP from driving pins output in an uncontrolled manner, which may happen if the power domain drops the domain regulator. If any of the above pin states are missing in dt, a warning message about the missing state is displayed. If certain pin-states are not available, to remove this warning message pass respective state name with null phandler. There's a similar patch in the [RESEND PATCH v2 1/3] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode thread. It also makes the SDIO interrupts to work, so we need to consider that too. Hi Tony, I will try to combine both of these and make use of pinctrl_pm_select_[*]_state helper functions. We can merge the dynamic pinmuxing parts separately, but they should be in a separate function like I posted later on in the thread above. 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: [RFC v1] MFD: Change TWL6025 references to TWL6032
On Fri, Jun 07, 2013 at 01:53:10PM +0300, Oleksandr Kozaruk wrote: From: Graeme Gregory g...@slimlogic.co.uk The TWL6025 was never released beyond sample form and was replaced by the PhoenixLite range of chips - TWL6032. Change the references to reference the TWL6032 class and name the registers to twl6032 in line with an actual released chip name to avoid confusion. Currently there is no users of TWL6025 in the code. Given that the chip exists even if not widely distributed it seems as well to keep the twl6025 references in there at least in the device ID table - it won't do any harm to people using the twl6032 name and might help someone who happens to pick up an old board for whatever reason. signature.asc Description: Digital signature
Re: [net-next PATCH v4 1/5] net: cpsw: enhance pinctrl support
On 6/7/2013 1:12 PM, David Miller wrote: From: Linus Walleij linus.wall...@linaro.org Date: Fri, 7 Jun 2013 09:31:58 +0200 On Thu, Jun 6, 2013 at 10:50 AM, Mark Brown broo...@kernel.org wrote: On Thu, Jun 06, 2013 at 11:29:39AM +0530, Mugunthan V N wrote: On 6/6/2013 12:53 AM, Mark Brown wrote: Linus Walleij posted some patches which factor the state setting code out into generic functions earlier on today - it probably makes sense to pick those up rather than open coding But this can go in as Linus Walleij's patch is not accepted yet. Once that is accepted and present in net git repo I will submit a separate patch to use those APIs from pin ctrl core. Linus' change has pretty much gone in already but in any case what would be sensible here would be to write this in turns of Linus' changes and then send the patch to him to add to his series so it can go in via the same route. One of the major reasons for the patch was that lots of people were querying the amount of noise caused by this sort of change. I agree. We should be able to settle on the new core API quite soon, then I can carry the patch to this driver if you obtain David's ACK. If you want to merge the direct networking parts of this series into another tree, I'm fine with that: Acked-by: David S. Miller da...@davemloft.net David Can you the below patch series as i have adopted pinctrl PM api in another series, this patch has direct usage of pinctrl_select_state apis http://marc.info/?l=linux-netdevm=137054250018667w=2 Linus Walleij Please drop this patch series and take my other [atch set mentioned above with David's Ack. Regards Mugunthan V N -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v1] MFD: Change TWL6025 references to TWL6032
On 2013-06-07 15:36, Mark Brown wrote: On Fri, Jun 07, 2013 at 01:53:10PM +0300, Oleksandr Kozaruk wrote: From: Graeme Gregory g...@slimlogic.co.uk The TWL6025 was never released beyond sample form and was replaced by the PhoenixLite range of chips - TWL6032. Change the references to reference the TWL6032 class and name the registers to twl6032 in line with an actual released chip name to avoid confusion. Currently there is no users of TWL6025 in the code. Given that the chip exists even if not widely distributed it seems as well to keep the twl6025 references in there at least in the device ID table - it won't do any harm to people using the twl6032 name and might help someone who happens to pick up an old board for whatever reason. I do not think any old boards exist, it really was a limited run! Graeme -- 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 0/4] ARM: dts: omap5: Cleanup and updates for DT files
Thanks for the quick update. I've just applied the series in my for_3.11/dts branch. Regards, Benoit On 06/07/2013 03:22 PM, Sricharan R wrote: uevm is the only official board supported for OMAP5 soc in the mainline. This series deprecates the support for existent sevm which will no more be supported in mainline and renames the board dts file accordingly. Also a few additional device DT entry updates are done. This is on top of the below branch git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Boot tested on omap5-uevm after pulling in the data from below place git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git HWMOD DATA: for_3.11/omap5_data_files CLOCK DATA: out_of_tree/omap5_clk_data Dan Murphy (1): ARM: dts: omap5-uevm: Add LED support for uEVM blue LED Roger Quadros (1): ARM: dts: omap5-uevm: Add USB Host support Sourav Poddar (1): ARM: dts: omap5-uevm: Add uart pinctrl data Sricharan R (1): ARM: dts: omap5: Make uevm as the official board and deprecate sevm support arch/arm/boot/dts/Makefile |2 +- arch/arm/boot/dts/omap5-evm.dts | 261 arch/arm/boot/dts/omap5-uevm.dts | 311 ++ arch/arm/boot/dts/omap5.dtsi | 30 4 files changed, 342 insertions(+), 262 deletions(-) delete mode 100644 arch/arm/boot/dts/omap5-evm.dts create mode 100644 arch/arm/boot/dts/omap5-uevm.dts -- 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 0/4] ARM: dts: omap5: Cleanup and updates for DT files
On Friday 07 June 2013 08:21 PM, Benoit Cousson wrote: Thanks for the quick update. I've just applied the series in my for_3.11/dts branch. Thanks.. Regards, Sricharan Regards, Benoit On 06/07/2013 03:22 PM, Sricharan R wrote: uevm is the only official board supported for OMAP5 soc in the mainline. This series deprecates the support for existent sevm which will no more be supported in mainline and renames the board dts file accordingly. Also a few additional device DT entry updates are done. This is on top of the below branch git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Boot tested on omap5-uevm after pulling in the data from below place git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git HWMOD DATA: for_3.11/omap5_data_files CLOCK DATA: out_of_tree/omap5_clk_data Dan Murphy (1): ARM: dts: omap5-uevm: Add LED support for uEVM blue LED Roger Quadros (1): ARM: dts: omap5-uevm: Add USB Host support Sourav Poddar (1): ARM: dts: omap5-uevm: Add uart pinctrl data Sricharan R (1): ARM: dts: omap5: Make uevm as the official board and deprecate sevm support arch/arm/boot/dts/Makefile |2 +- arch/arm/boot/dts/omap5-evm.dts | 261 arch/arm/boot/dts/omap5-uevm.dts | 311 ++ arch/arm/boot/dts/omap5.dtsi | 30 4 files changed, 342 insertions(+), 262 deletions(-) delete mode 100644 arch/arm/boot/dts/omap5-evm.dts create mode 100644 arch/arm/boot/dts/omap5-uevm.dts -- 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 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up
* Paul Walmsley p...@pwsan.com [130605 21:06]: On Wed, 29 May 2013, Santosh Shilimkar wrote: From: Vaibhav Hiremath hvaib...@ti.com AM33XX only supports DT boot mode and with addition of extracting module resources like, irq, dma and address space from DT block, so now we can remove duplicate information from hwmod data file. OK, guess I'll take your word for it that it all works. The BeagleBone-white with appended DTB hasn't booted here since v3.7. And the BeagleBone-black with discrete DTB doesn't boot at all with current mainline, only with the TI vendor kernel DTB... Acked-by: Paul Walmsley p...@pwsan.com Thanks applying into omap-for-v3.11/cleanup. 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 V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file
* Paul Walmsley p...@pwsan.com [130607 05:38]: On Fri, 7 Jun 2013, Sricharan R wrote: - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data is stripped from OMAP4 SOC hwmod data file. - The devices which are still missing the device tree bindings, address space entries are not removed yet. When such devices add the dt bindings, respective address space data can be deleted. - Also other unnecessary hwmods like firewalls are removed as a part of this. Since emif was getting registered only because of this firewalls links, the mpu-emif direct link is added now. The above update, results in reduction of about ~1650 lines of code. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Can't test this one since I don't have an OMAP4 DT config set up in the testbed yet. Maybe will add that to the testbed after the v3.10 release. OK thanks, applying into omap-for-v3.11/cleanup. 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 v2 3/3] ARM: DTS: TWL4030: fix mux and wakeup for SYS_NIRQ line
Nishanth Menon n...@ti.com writes:
On 16:27-20130606, Kevin Hilman wrote:
On most OMAP3 platforms, the twl4030 IRQ line is connected to the
SYS_NIRQ line on OMAP. Add another DTS include file
(twl4030_omap3_mux.dtsi) for boards that hook up the twl4030 this way
to include.
This allows RTC wake from off-mode to work again on OMAP3-based
platforms with twl4030. Tested on 3530/Beagle, 3730/Beagle-xM,
3530/Overo, 3730/Overo-STORM.
Special thanks to Florian Vaussard for suggesting use of preprocessor
feature.
Cc: Florian Vaussard florian.vauss...@epfl.ch
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kevin Hilman khil...@linaro.org
---
v2: Updated to change board files instead of twl4030 file.
arch/arm/boot/dts/omap3-beagle-xm.dts| 1 +
arch/arm/boot/dts/omap3-beagle.dts | 1 +
arch/arm/boot/dts/omap3-devkit8000.dts | 1 +
arch/arm/boot/dts/omap3-evm.dts | 1 +
arch/arm/boot/dts/omap3-igep.dtsi| 1 +
arch/arm/boot/dts/omap3-overo.dtsi | 1 +
arch/arm/boot/dts/omap3430-sdp.dts | 1 +
arch/arm/boot/dts/twl4030_omap3_mux.dtsi | 17 +
minor comment:
can we do twl4030_omap3 instead? That way, I can add in twl4030 VP
specific parameters which are OMAP3 specific?
Good idea, I'll rename it to twl4030_omap3.dtsi
[...]
diff --git a/arch/arm/boot/dts/twl4030_omap3_mux.dtsi
b/arch/arm/boot/dts/twl4030_omap3_mux.dtsi
new file mode 100644
index 000..1bd0f9f
--- /dev/null
+++ b/arch/arm/boot/dts/twl4030_omap3_mux.dtsi
@@ -0,0 +1,17 @@
some license text?
oops
+twl {
+pinctrl-names = default;
+pinctrl-0 = twl4030_pins;
+};
+
+omap3_pmx_core {
+/*
+ * On most OMAP3 platforms, the twl4030 IRQ line is connected
+ * to the SYS_NIRQ line on OMAP. Therefore, configure the
+ * defaults for the SYS_NIRQ pin here.
^^^ tab?
good catch.
Thanks for the review, will make the changes and resubmit.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up
On Thursday 06 June 2013 06:27 PM, Kevin Hilman wrote: Paul Walmsley p...@pwsan.com writes: On Wed, 29 May 2013, Santosh Shilimkar wrote: From: Vaibhav Hiremath hvaib...@ti.com AM33XX only supports DT boot mode and with addition of extracting module resources like, irq, dma and address space from DT block, so now we can remove duplicate information from hwmod data file. OK, guess I'll take your word for it that it all works. The BeagleBone-white with appended DTB hasn't booted here since v3.7. And the BeagleBone-black with discrete DTB doesn't boot at all with current mainline, only with the TI vendor kernel DTB... Anyone care to shed light on what's missing for BeagleBone boot with mainline currently? I've also not been able to boot a mainline kernel on the BeagleBone for some time. Looping Rajendra. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file
* Tony Lindgren t...@atomide.com [130607 09:35]:
* Paul Walmsley p...@pwsan.com [130607 05:38]:
On Fri, 7 Jun 2013, Sricharan R wrote:
- The IO resource information like dma request lines, irq number and
ocp address space can be populated via dt blob. So such data is stripped
from OMAP4 SOC hwmod data file.
- The devices which are still missing the device tree bindings,
address space entries are not removed yet. When such devices add
the dt bindings, respective address space data can be deleted.
- Also other unnecessary hwmods like firewalls are removed as a part of
this.
Since emif was getting registered only because of this firewalls links,
the mpu-emif direct link is added now.
The above update, results in reduction of about ~1650 lines of code.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
Can't test this one since I don't have an OMAP4 DT config set up in the
testbed
yet. Maybe will add that to the testbed after the v3.10 release.
OK thanks, applying into omap-for-v3.11/cleanup.
I had to undo the following parts to avoid regressions on omap4sdp.
Can you please follow up on fixing the related issues so the fixup
won't be needed?
Seems to work now the same way as earlier for both omap4sdp and blaze
es, except for DSS, which seems to be a separate issue as posted by
Tomi. Pushed out now to omap-for-v3.11/cleanup.
Regards,
Tony
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -465,6 +465,7 @@ static struct omap_dma_dev_attr dma_dev_attr = {
.lch_count = 32,
};
+/* dma_system */
static struct omap_hwmod_irq_info omap44xx_dma_system_irqs[] = {
{ .name = 0, .irq = 12 + OMAP44XX_IRQ_GIC_START },
{ .name = 1, .irq = 13 + OMAP44XX_IRQ_GIC_START },
@@ -473,7 +474,6 @@ static struct omap_hwmod_irq_info
omap44xx_dma_system_irqs[] = {
{ .irq = -1 }
};
-/* dma_system */
static struct omap_hwmod omap44xx_dma_system_hwmod = {
.name = dma_system,
.class = omap44xx_dma_hwmod_class,
@@ -1747,6 +1747,23 @@ static struct omap_hwmod_class
omap44xx_mcspi_hwmod_class = {
};
/* mcspi1 */
+static struct omap_hwmod_irq_info omap44xx_mcspi1_irqs[] = {
+ { .irq = 65 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap44xx_mcspi1_sdma_reqs[] = {
+ { .name = tx0, .dma_req = 34 + OMAP44XX_DMA_REQ_START },
+ { .name = rx0, .dma_req = 35 + OMAP44XX_DMA_REQ_START },
+ { .name = tx1, .dma_req = 36 + OMAP44XX_DMA_REQ_START },
+ { .name = rx1, .dma_req = 37 + OMAP44XX_DMA_REQ_START },
+ { .name = tx2, .dma_req = 38 + OMAP44XX_DMA_REQ_START },
+ { .name = rx2, .dma_req = 39 + OMAP44XX_DMA_REQ_START },
+ { .name = tx3, .dma_req = 40 + OMAP44XX_DMA_REQ_START },
+ { .name = rx3, .dma_req = 41 + OMAP44XX_DMA_REQ_START },
+ { .dma_req = -1 }
+};
+
/* mcspi1 dev_attr */
static struct omap2_mcspi_dev_attr mcspi1_dev_attr = {
.num_chipselect = 4,
@@ -1756,6 +1773,8 @@ static struct omap_hwmod omap44xx_mcspi1_hwmod = {
.name = mcspi1,
.class = omap44xx_mcspi_hwmod_class,
.clkdm_name = l4_per_clkdm,
+ .mpu_irqs = omap44xx_mcspi1_irqs,
+ .sdma_reqs = omap44xx_mcspi1_sdma_reqs,
.main_clk = func_48m_fclk,
.prcm = {
.omap4 = {
@@ -1768,6 +1787,19 @@ static struct omap_hwmod omap44xx_mcspi1_hwmod = {
};
/* mcspi2 */
+static struct omap_hwmod_irq_info omap44xx_mcspi2_irqs[] = {
+ { .irq = 66 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap44xx_mcspi2_sdma_reqs[] = {
+ { .name = tx0, .dma_req = 42 + OMAP44XX_DMA_REQ_START },
+ { .name = rx0, .dma_req = 43 + OMAP44XX_DMA_REQ_START },
+ { .name = tx1, .dma_req = 44 + OMAP44XX_DMA_REQ_START },
+ { .name = rx1, .dma_req = 45 + OMAP44XX_DMA_REQ_START },
+ { .dma_req = -1 }
+};
+
/* mcspi2 dev_attr */
static struct omap2_mcspi_dev_attr mcspi2_dev_attr = {
.num_chipselect = 2,
@@ -1777,6 +1809,8 @@ static struct omap_hwmod omap44xx_mcspi2_hwmod = {
.name = mcspi2,
.class = omap44xx_mcspi_hwmod_class,
.clkdm_name = l4_per_clkdm,
+ .mpu_irqs = omap44xx_mcspi2_irqs,
+ .sdma_reqs = omap44xx_mcspi2_sdma_reqs,
.main_clk = func_48m_fclk,
.prcm = {
.omap4 = {
@@ -1789,6 +1823,19 @@ static struct omap_hwmod omap44xx_mcspi2_hwmod = {
};
/* mcspi3 */
+static struct omap_hwmod_irq_info omap44xx_mcspi3_irqs[] = {
+ { .irq = 91 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap44xx_mcspi3_sdma_reqs[] = {
+ { .name = tx0,
Re: i2c issue on Panda with DT boot, v3.10-rc4
* Tomi Valkeinen tomi.valkei...@ti.com [130607 05:53]:
On 07/06/13 15:36, Grygorii Strashko wrote:
Could you check if below change will help you, pls?
iff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 13d1eca..66a62e7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -615,11 +615,11 @@ static int omap_i2c_xfer_msg(struct i2c_adapter
*adap,
if (dev-cmd_err OMAP_I2C_STAT_NACK) {
if (msg-flags I2C_M_IGNORE_NAK)
return 0;
- if (stop) {
- w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
- w |= OMAP_I2C_CON_STP;
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
- }
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
+ w |= OMAP_I2C_CON_STP;
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
+
return -EREMOTEIO;
}
return -EIO;
With that one, I don't get timeouts, but it still doesn't work (i.e.
behavior is the same as on -rc1).
When I run i2cdump the first time, I see that it (probably) manages to
read the first byte, as that's 00. Everything after that are 'XX'es.
Hmm I suggest git bisect, I'm pretty sure I was using my panda es
with my omap4 DT conversion patches against v3.10-rc1.
In any case, please also test your changes against the current
omap-for-v3.11/cleanup branch that drops omap4 legacy hwmod data for
the parts that should come from DT. If you see some additional issues
with that, we can revert the related parts of the last patch in
omap-for-v3.11/cleanup.
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 V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On Friday 07 June 2013 01:50 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130607 09:35]: * Paul Walmsley p...@pwsan.com [130607 05:38]: On Fri, 7 Jun 2013, Sricharan R wrote: - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data is stripped from OMAP4 SOC hwmod data file. - The devices which are still missing the device tree bindings, address space entries are not removed yet. When such devices add the dt bindings, respective address space data can be deleted. - Also other unnecessary hwmods like firewalls are removed as a part of this. Since emif was getting registered only because of this firewalls links, the mpu-emif direct link is added now. The above update, results in reduction of about ~1650 lines of code. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Can't test this one since I don't have an OMAP4 DT config set up in the testbed yet. Maybe will add that to the testbed after the v3.10 release. OK thanks, applying into omap-for-v3.11/cleanup. I had to undo the following parts to avoid regressions on omap4sdp. Can you please follow up on fixing the related issues so the fixup won't be needed? Seems to work now the same way as earlier for both omap4sdp and blaze es, except for DSS, which seems to be a separate issue as posted by Tomi. Pushed out now to omap-for-v3.11/cleanup. Thats strange. You shouldn't need those fixes since that data is expected to be coming from DT. Sricharan, Can you please try out the patch against Tony's V3.11/clean-up branch and see whats missing there. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On Friday 07 June 2013 02:10 PM, Paul Walmsley wrote: On Fri, 7 Jun 2013, Tony Lindgren wrote: I had to undo the following parts to avoid regressions on omap4sdp. Can you please follow up on fixing the related issues so the fixup won't be needed? Well, I can't even test it at the moment. So it's probably best for Santosh and Sricharan to fix those issues - they're the ones who are responsible for testing the patch before it's sent. Unless there's some specific reason why I'd be the best person to do it? Will take care of that Paul. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On Fri, 7 Jun 2013, Tony Lindgren wrote: I had to undo the following parts to avoid regressions on omap4sdp. Can you please follow up on fixing the related issues so the fixup won't be needed? Well, I can't even test it at the moment. So it's probably best for Santosh and Sricharan to fix those issues - they're the ones who are responsible for testing the patch before it's sent. Unless there's some specific reason why I'd be the best person to do it? - 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: i2c issue on Panda with DT boot, v3.10-rc4
HI,
On Fri, Jun 07, 2013 at 03:36:38PM +0300, Grygorii Strashko wrote:
hi Tomi,
On 06/07/2013 02:53 PM, Tomi Valkeinen wrote:
Hi,
I was testing DT boot with 3.10-rc1 and Pandaboard, and couldn't get the
DVI output's EDID reading to work. Testing with i2cget and i2cdump, I
see that I can read individual bytes with i2cget, but using i2cdump
doesn't work, it just shows 'XX'es.
The same issue is there with 3.10-rc4, although with that one I get
timeouts with i2cdump, whereas there were no timeouts with -rc1.
# i2cget -y 2 0x50 0x10
0x0a
# i2cget -y 2 0x50 0x20
0x0f
# i2cget -y 2 0x50 0x30
0x01
# i2cget -y 2 0x50 0x40
0x36
# i2cget -y 2 0x50 0x50
0x4c
# i2cdump -y 2 0x50
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef
00: 00 [ 72.814086] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 73.825134] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 74.835327] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 76.097167] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 77.160736] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 78.174682] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 79.194824] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 80.242980] omap_i2c 4806.i2c: timeout waiting for bus ready
i2cdump works fine with non-DT boot (but the i2c bus number is 3).
Any ideas?
Tomi
Could you check if below change will help you, pls?
iff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 13d1eca..66a62e7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -615,11 +615,11 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (dev-cmd_err OMAP_I2C_STAT_NACK) {
if (msg-flags I2C_M_IGNORE_NAK)
return 0;
- if (stop) {
- w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
- w |= OMAP_I2C_CON_STP;
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
- }
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
+ w |= OMAP_I2C_CON_STP;
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
+
don't do this, it will break repeated start.
--
balbi
signature.asc
Description: Digital signature
[PATCH v3] ARM: DTS: TWL4030: fix mux and wakeup for SYS_NIRQ line
On most OMAP3 platforms, the twl4030 IRQ line is connected to the
SYS_NIRQ line on OMAP. Add another DTS include file
(twl4030_omap3.dtsi) for boards that hook up the twl4030 this way
to include.
This allows RTC wake from off-mode to work again on OMAP3-based
platforms with twl4030. Tested on 3530/Beagle, 3730/Beagle-xM,
3530/Overo, 3730/Overo-STORM.
Special thanks to Florian Vaussard for suggesting use of preprocessor
feature.
Cc: Florian Vaussard florian.vauss...@epfl.ch
Cc: Benoit Cousson b-cous...@ti.com
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@linaro.org
---
v3: renamed to twl4030_omap3 (suggested by Nishanth), add GPL, fix whitespace
v2: Updated to change board files instead of twl4030 file.
arch/arm/boot/dts/omap3-beagle-xm.dts | 1 +
arch/arm/boot/dts/omap3-beagle.dts | 1 +
arch/arm/boot/dts/omap3-devkit8000.dts | 1 +
arch/arm/boot/dts/omap3-evm.dts| 1 +
arch/arm/boot/dts/omap3-igep.dtsi | 1 +
arch/arm/boot/dts/omap3-overo.dtsi | 1 +
arch/arm/boot/dts/omap3430-sdp.dts | 1 +
arch/arm/boot/dts/twl4030_omap3.dtsi | 25 +
8 files changed, 32 insertions(+)
create mode 100644 arch/arm/boot/dts/twl4030_omap3.dtsi
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index ad17b6b..afdb164 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -96,6 +96,7 @@
};
#include twl4030.dtsi
+#include twl4030_omap3.dtsi
i2c2 {
clock-frequency = 40;
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index eb7e02a..dfd8310 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -135,6 +135,7 @@
};
#include twl4030.dtsi
+#include twl4030_omap3.dtsi
mmc1 {
vmmc-supply = vmmc1;
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts
b/arch/arm/boot/dts/omap3-devkit8000.dts
index 5be71b1..af32eff 100644
--- a/arch/arm/boot/dts/omap3-devkit8000.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -81,6 +81,7 @@
};
#include twl4030.dtsi
+#include twl4030_omap3.dtsi
mmc1 {
vmmc-supply = vmmc1;
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index baa24bb..7d4329d 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -45,6 +45,7 @@
};
#include twl4030.dtsi
+#include twl4030_omap3.dtsi
i2c2 {
clock-frequency = 40;
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index 5224c29..bc48b11 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -87,6 +87,7 @@
};
#include twl4030.dtsi
+#include twl4030_omap3.dtsi
i2c2 {
clock-frequency = 40;
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index 144a5a2..4bc78896 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -50,6 +50,7 @@
};
#include twl4030.dtsi
+#include twl4030_omap3.dtsi
/* i2c2 pins are used for gpio */
i2c2 {
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
b/arch/arm/boot/dts/omap3430-sdp.dts
index 2a725a0..c4a1c0a 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -29,6 +29,7 @@
};
#include twl4030.dtsi
+#include twl4030_omap3.dtsi
mmc1 {
vmmc-supply = vmmc1;
diff --git a/arch/arm/boot/dts/twl4030_omap3.dtsi
b/arch/arm/boot/dts/twl4030_omap3.dtsi
new file mode 100644
index 000..c353ef0
--- /dev/null
+++ b/arch/arm/boot/dts/twl4030_omap3.dtsi
@@ -0,0 +1,25 @@
+/*
+ * Copyright (C) 2013 Linaro, Ltd.
+ *
+ * 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.
+ */
+
+twl {
+ pinctrl-names = default;
+ pinctrl-0 = twl4030_pins;
+};
+
+omap3_pmx_core {
+ /*
+* On most OMAP3 platforms, the twl4030 IRQ line is connected
+* to the SYS_NIRQ line on OMAP. Therefore, configure the
+* defaults for the SYS_NIRQ pin here.
+*/
+ twl4030_pins: pinmux_twl4030_pins {
+ pinctrl-single,pins =
+ 0x1b0 (PIN_INPUT_PULLUP | PIN_OFF_WAKEUPENABLE |
MUX_MODE0) /* sys_nirq.sys_nirq */
+ ;
+ };
+};
--
1.8.3
--
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: i2c issue on Panda with DT boot, v3.10-rc4
Tony Lindgren [t...@atomide.com]: * Tomi Valkeinen tomi.valkei...@ti.com [130607 05:53]: With that one, I don't get timeouts, but it still doesn't work (i.e. behavior is the same as on -rc1). When I run i2cdump the first time, I see that it (probably) manages to read the first byte, as that's 00. Everything after that are 'XX'es. Hmm I suggest git bisect, I'm pretty sure I was using my panda es with my omap4 DT conversion patches against v3.10-rc1. As I mentioned, it doesn't work on v3.10-rc1 either. Note that DVI output itself works fine, it's the EDID read that fails. So if you force the videomode, you won't notice anything. I didn't try with v3.9 (does DT boot work on that one?), though. So I don't know if reading EDID has ever worked with DT boot. Tomi Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki -- 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: i2c issue on Panda with DT boot, v3.10-rc4
* Valkeinen, Tomi tomi.valkei...@ti.com [130607 11:37]: Tony Lindgren [t...@atomide.com]: * Tomi Valkeinen tomi.valkei...@ti.com [130607 05:53]: With that one, I don't get timeouts, but it still doesn't work (i.e. behavior is the same as on -rc1). When I run i2cdump the first time, I see that it (probably) manages to read the first byte, as that's 00. Everything after that are 'XX'es. Hmm I suggest git bisect, I'm pretty sure I was using my panda es with my omap4 DT conversion patches against v3.10-rc1. As I mentioned, it doesn't work on v3.10-rc1 either. Note that DVI output itself works fine, it's the EDID read that fails. So if you force the videomode, you won't notice anything. OK, that's probably I had it working. I didn't try with v3.9 (does DT boot work on that one?), though. So I don't know if reading EDID has ever worked with DT boot. Yes but requires several fixes. Without fixes, v3.10-rc4 is your best bet. Of course that won't help much with git bisect. Maybe check that the i2c related pins are muxed properly for your board with pinctrl-single? 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 V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file
* Santosh Shilimkar santosh.shilim...@ti.com [130607 11:20]: On Friday 07 June 2013 02:10 PM, Paul Walmsley wrote: On Fri, 7 Jun 2013, Tony Lindgren wrote: I had to undo the following parts to avoid regressions on omap4sdp. Can you please follow up on fixing the related issues so the fixup won't be needed? Well, I can't even test it at the moment. So it's probably best for Santosh and Sricharan to fix those issues - they're the ones who are responsible for testing the patch before it's sent. Unless there's some specific reason why I'd be the best person to do it? Will take care of that Paul. Thanks, sorry I did not mean Paul, I meant the authors of the patches :) 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 V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file
* Santosh Shilimkar santosh.shilim...@ti.com [130607 11:20]: On Friday 07 June 2013 01:50 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130607 09:35]: * Paul Walmsley p...@pwsan.com [130607 05:38]: On Fri, 7 Jun 2013, Sricharan R wrote: - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data is stripped from OMAP4 SOC hwmod data file. - The devices which are still missing the device tree bindings, address space entries are not removed yet. When such devices add the dt bindings, respective address space data can be deleted. - Also other unnecessary hwmods like firewalls are removed as a part of this. Since emif was getting registered only because of this firewalls links, the mpu-emif direct link is added now. The above update, results in reduction of about ~1650 lines of code. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Can't test this one since I don't have an OMAP4 DT config set up in the testbed yet. Maybe will add that to the testbed after the v3.10 release. OK thanks, applying into omap-for-v3.11/cleanup. I had to undo the following parts to avoid regressions on omap4sdp. Can you please follow up on fixing the related issues so the fixup won't be needed? Seems to work now the same way as earlier for both omap4sdp and blaze es, except for DSS, which seems to be a separate issue as posted by Tomi. Pushed out now to omap-for-v3.11/cleanup. Thats strange. You shouldn't need those fixes since that data is expected to be coming from DT. Sricharan, Can you please try out the patch against Tony's V3.11/clean-up branch and see whats missing there. Looking at the diff output with and without, it seems to be that the DMA channels won't get configured. 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: i2c issue on Panda with DT boot, v3.10-rc4
Hi, On Fri, Jun 07, 2013 at 02:53:54PM +0300, Tomi Valkeinen wrote: Hi, I was testing DT boot with 3.10-rc1 and Pandaboard, and couldn't get the DVI output's EDID reading to work. Testing with i2cget and i2cdump, I see that I can read individual bytes with i2cget, but using i2cdump doesn't work, it just shows 'XX'es. does it work with v3.9 ? The funny thing is that nothing has changed on i2c-omap.c for quite some time... The same issue is there with 3.10-rc4, although with that one I get timeouts with i2cdump, whereas there were no timeouts with -rc1. # i2cget -y 2 0x50 0x10 0x0a # i2cget -y 2 0x50 0x20 0x0f # i2cget -y 2 0x50 0x30 0x01 # i2cget -y 2 0x50 0x40 0x36 # i2cget -y 2 0x50 0x50 0x4c # i2cdump -y 2 0x50 No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef 00: 00 [ 72.814086] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 73.825134] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 74.835327] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 76.097167] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 77.160736] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 78.174682] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 79.194824] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 80.242980] omap_i2c 4806.i2c: timeout waiting for bus ready i2cdump works fine with non-DT boot (but the i2c bus number is 3). Any ideas? sounds like there's something left in FIFO which is not getting read out, then we end up timing out. Can you try the patch below ? It's patch of a bigger patchset which I still need to clean a few things up, but they should be very close to being ready. IIRC, one of the patches creates a problem for N900 (only) which gets fixed later, I just need to combine those two patches into one to avoid the regression. diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index aa3b91e..471b434 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1022,9 +1022,8 @@ omap_i2c_isr_thread(int this_irq, void *dev_id) } } while (stat); - omap_i2c_complete_cmd(dev, err); - out: + omap_i2c_complete_cmd(dev, err); spin_unlock_irqrestore(dev-lock, flags); return IRQ_HANDLED; -- balbi signature.asc Description: Digital signature
Re: [PATCH V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On Friday 07 June 2013 02:37 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130607 11:20]: On Friday 07 June 2013 01:50 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130607 09:35]: * Paul Walmsley p...@pwsan.com [130607 05:38]: On Fri, 7 Jun 2013, Sricharan R wrote: - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data is stripped from OMAP4 SOC hwmod data file. - The devices which are still missing the device tree bindings, address space entries are not removed yet. When such devices add the dt bindings, respective address space data can be deleted. - Also other unnecessary hwmods like firewalls are removed as a part of this. Since emif was getting registered only because of this firewalls links, the mpu-emif direct link is added now. The above update, results in reduction of about ~1650 lines of code. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Can't test this one since I don't have an OMAP4 DT config set up in the testbed yet. Maybe will add that to the testbed after the v3.10 release. OK thanks, applying into omap-for-v3.11/cleanup. I had to undo the following parts to avoid regressions on omap4sdp. Can you please follow up on fixing the related issues so the fixup won't be needed? Seems to work now the same way as earlier for both omap4sdp and blaze es, except for DSS, which seems to be a separate issue as posted by Tomi. Pushed out now to omap-for-v3.11/cleanup. Thats strange. You shouldn't need those fixes since that data is expected to be coming from DT. Sricharan, Can you please try out the patch against Tony's V3.11/clean-up branch and see whats missing there. Looking at the diff output with and without, it seems to be that the DMA channels won't get configured. That should work since DMA engine changes are in mainline and the DMA channel information is already in DT. 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 0/5] v3.10-rc4: fix OMAP4 boot failure if CONFIG_SENSORS_LM75=y
Hi All, I observe, that OMAP4 SDP board boot is failed if CONFIG_SENSORS_LM75=y. See log below. This issue reproduced with kernel v3.9-rc6, but without hang - just I2C is stuck in Bus Busy condition. My investigation results are below. [2.048858] TCP: cubic registered [2.052398] Initializing XFRM netlink socket [2.057037] NET: Registered protocol family 17 [2.061859] NET: Registered protocol family 15 [2.066955] Key type dns_resolver registered [2.071716] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4 [2.081085] Power Management for TI OMAP4. [2.085418] OMAP4 PM: u-boot = v2012.07 is required for full PM support [2.092773] ThumbEE CPU extension supported. [2.107788] omap_i2c 4807.i2c: bus 0 rev0.11 at 400 kHz [2.117858] Skipping twl internal clock init and using bootloader value (unknown osc rate) [2.128570] twl 0-0048: PIH (irq 39) chaining IRQs 416..436 [2.137237] twl_rtc rtc.11: Enabling TWL-RTC [2.146301] twl_rtc rtc.11: rtc core: registered rtc.11 as rtc0 [2.155181] VAUX1_6030: 1000 -- 3000 mV at 2800 mV [2.162750] VAUX2_6030: 1200 -- 2800 mV at 1800 mV [2.170318] VAUX3_6030: 1000 -- 3000 mV at 1200 mV [2.177856] VMMC: 1200 -- 3000 mV at 1800 mV [2.184692] VPP: 1800 -- 2500 mV at 1900 mV [2.191589] VUSIM: 1200 -- 2900 mV at 1800 mV [2.198394] VDAC: 1800 mV [2.202850] VANA: 2100 mV [2.207763] VCXIO: 1800 mV [2.212310] VUSB: 3300 mV [2.217346] V1V8: 1800 mV [2.90] V2V1: 2100 mV [2.239837] omap_i2c 48072000.i2c: bus 1 rev0.11 at 400 kHz [2.246307] [ cut here ] [2.251220] WARNING: at drivers/bus/omap_l3_noc.c:113 l3_interrupt_handler+0x140/0x184() [2.257781] L3 custom error: MASTER:MPU TARGET:L4 PER2 [2.264373] Modules linked in: [2.268463] CPU: 0 PID: 2 Comm: kthreadd Not tainted 3.10.0-rc4-00034-g042dd60-dirty #64 [2.270385] [c001a80c] (unwind_backtrace+0x0/0xf0) from [c0017238] (show_stack+0x10/0x14) [2.286102] [c0017238] (show_stack+0x10/0x14) from [c0040fd0] (warn_slowpath_common+0x4c/0x68) [2.295593] [c0040fd0] (warn_slowpath_common+0x4c/0x68) from [c0041080] (warn_slowpath_fmt+0x30/0x40) [2.299987] [c0041080] (warn_slowpath_fmt+0x30/0x40) from [c02c5ed0] (l3_interrupt_handler+0x140/0x184) [2.315582] [c02c5ed0] (l3_interrupt_handler+0x140/0x184) from [c009ffb8] (handle_irq_event_percpu+0x58/0x258) [2.323364] [c009ffb8] (handle_irq_event_percpu+0x58/0x258) from [c00a01f4] (handle_irq_event+0x3c/0x5c) [2.327819] [c00a01f4] (handle_irq_event+0x3c/0x5c) from [c00a2f7c] (handle_fasteoi_irq+0xbc/0x164) [2.337829] [c00a2f7c] (handle_fasteoi_irq+0xbc/0x164) from [c009f978] (generic_handle_irq+0x20/0x30) [2.357513] [c009f978] (generic_handle_irq+0x20/0x30) from [c0014168] (handle_IRQ+0x4c/0xac) [2.366821] [c0014168] (handle_IRQ+0x4c/0xac) from [c00085b4] (gic_handle_irq+0x28/0x5c) [2.375762] [c00085b4] (gic_handle_irq+0x28/0x5c) from [c04f08a4] (__irq_svc+0x44/0x5c) [2.379821] Exception stack(0xdb085ec0 to 0xdb085f08) [2.389953] 5ec0: 0001 0001 db07ea00 4113 db2317a8 db084000 02f1 [2.389953] 5ee0: db07ea00 c04fd990 db085f08 c009170c c04f03e8 [2.405609] 5f00: 2113 [2.408355] [c04f08a4] (__irq_svc+0x44/0x5c) from [c04f03e8] (_raw_spin_unlock_irqrestore+0x34/0x44) [2.418304] [c04f03e8] (_raw_spin_unlock_irqrestore+0x34/0x44) from [c00403c0] (do_fork+0xa4/0x2d4) [2.427795] [c00403c0] (do_fork+0xa4/0x2d4) from [c0040620] (kernel_thread+0x30/0x38) [2.437805] [c0040620] (kernel_thread+0x30/0x38) from [c0063888] (kthreadd+0xd4/0x13c) [2.448364] [c0063888] (kthreadd+0xd4/0x13c) from [c0013308] (ret_from_fork+0x14/0x2c) [2.448364] ---[ end trace da8cf92c433d1616 ]--- [4.028594] omap_i2c 4806.i2c: timeout waiting for bus ready [5.047637] omap_i2c 4806.i2c: timeout waiting for bus ready [6.662322] omap_i2c 4806.i2c: timeout waiting for bus ready [7.687499] omap_i2c 4806.i2c: timeout waiting for bus ready [8.717315] omap_i2c 4806.i2c: timeout waiting for bus ready [9.737365] omap_i2c 4806.i2c: timeout waiting for bus ready [ 10.747863] omap_i2c 4806.i2c: timeout waiting for bus ready [ 11.767608] omap_i2c 4806.i2c: timeout waiting for bus ready [ 12.768035] omap_i2c 4806.i2c: timeout waiting for bus ready [ 13.777893] omap_i2c 4806.i2c: timeout waiting for bus ready [ 14.787872] omap_i2c 4806.i2c: timeout waiting for bus ready [ 15.807128] omap_i2c 4806.i2c: timeout waiting for bus ready [ 17.318084] omap_i2c 4806.i2c: timeout waiting for bus ready [ 18.338226] omap_i2c 4806.i2c: timeout waiting for bus ready [ 19.367645] omap_i2c 4806.i2c: timeout waiting for bus ready [ 20.388031] omap_i2c 4806.i2c: timeout waiting for bus ready [ 21.407928]
[PATCH 0/5] v3.10-rc4: fix OMAP4 boot failure if CONFIG_SENSORS_LM75=y
Hi All, I observe, that OMAP4 SDP board boot is failed if CONFIG_SENSORS_LM75=y. See log below. This issue reproduced with kernel v3.9-rc6, but without hang - just I2C is stuck in Bus Busy condition. My investigation results are below. [2.048858] TCP: cubic registered [2.052398] Initializing XFRM netlink socket [2.057037] NET: Registered protocol family 17 [2.061859] NET: Registered protocol family 15 [2.066955] Key type dns_resolver registered [2.071716] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4 [2.081085] Power Management for TI OMAP4. [2.085418] OMAP4 PM: u-boot = v2012.07 is required for full PM support [2.092773] ThumbEE CPU extension supported. [2.107788] omap_i2c 4807.i2c: bus 0 rev0.11 at 400 kHz [2.117858] Skipping twl internal clock init and using bootloader value (unknown osc rate) [2.128570] twl 0-0048: PIH (irq 39) chaining IRQs 416..436 [2.137237] twl_rtc rtc.11: Enabling TWL-RTC [2.146301] twl_rtc rtc.11: rtc core: registered rtc.11 as rtc0 [2.155181] VAUX1_6030: 1000 -- 3000 mV at 2800 mV [2.162750] VAUX2_6030: 1200 -- 2800 mV at 1800 mV [2.170318] VAUX3_6030: 1000 -- 3000 mV at 1200 mV [2.177856] VMMC: 1200 -- 3000 mV at 1800 mV [2.184692] VPP: 1800 -- 2500 mV at 1900 mV [2.191589] VUSIM: 1200 -- 2900 mV at 1800 mV [2.198394] VDAC: 1800 mV [2.202850] VANA: 2100 mV [2.207763] VCXIO: 1800 mV [2.212310] VUSB: 3300 mV [2.217346] V1V8: 1800 mV [2.90] V2V1: 2100 mV [2.239837] omap_i2c 48072000.i2c: bus 1 rev0.11 at 400 kHz [2.246307] [ cut here ] [2.251220] WARNING: at drivers/bus/omap_l3_noc.c:113 l3_interrupt_handler+0x140/0x184() [2.257781] L3 custom error: MASTER:MPU TARGET:L4 PER2 [2.264373] Modules linked in: [2.268463] CPU: 0 PID: 2 Comm: kthreadd Not tainted 3.10.0-rc4-00034-g042dd60-dirty #64 [2.270385] [c001a80c] (unwind_backtrace+0x0/0xf0) from [c0017238] (show_stack+0x10/0x14) [2.286102] [c0017238] (show_stack+0x10/0x14) from [c0040fd0] (warn_slowpath_common+0x4c/0x68) [2.295593] [c0040fd0] (warn_slowpath_common+0x4c/0x68) from [c0041080] (warn_slowpath_fmt+0x30/0x40) [2.299987] [c0041080] (warn_slowpath_fmt+0x30/0x40) from [c02c5ed0] (l3_interrupt_handler+0x140/0x184) [2.315582] [c02c5ed0] (l3_interrupt_handler+0x140/0x184) from [c009ffb8] (handle_irq_event_percpu+0x58/0x258) [2.323364] [c009ffb8] (handle_irq_event_percpu+0x58/0x258) from [c00a01f4] (handle_irq_event+0x3c/0x5c) [2.327819] [c00a01f4] (handle_irq_event+0x3c/0x5c) from [c00a2f7c] (handle_fasteoi_irq+0xbc/0x164) [2.337829] [c00a2f7c] (handle_fasteoi_irq+0xbc/0x164) from [c009f978] (generic_handle_irq+0x20/0x30) [2.357513] [c009f978] (generic_handle_irq+0x20/0x30) from [c0014168] (handle_IRQ+0x4c/0xac) [2.366821] [c0014168] (handle_IRQ+0x4c/0xac) from [c00085b4] (gic_handle_irq+0x28/0x5c) [2.375762] [c00085b4] (gic_handle_irq+0x28/0x5c) from [c04f08a4] (__irq_svc+0x44/0x5c) [2.379821] Exception stack(0xdb085ec0 to 0xdb085f08) [2.389953] 5ec0: 0001 0001 db07ea00 4113 db2317a8 db084000 02f1 [2.389953] 5ee0: db07ea00 c04fd990 db085f08 c009170c c04f03e8 [2.405609] 5f00: 2113 [2.408355] [c04f08a4] (__irq_svc+0x44/0x5c) from [c04f03e8] (_raw_spin_unlock_irqrestore+0x34/0x44) [2.418304] [c04f03e8] (_raw_spin_unlock_irqrestore+0x34/0x44) from [c00403c0] (do_fork+0xa4/0x2d4) [2.427795] [c00403c0] (do_fork+0xa4/0x2d4) from [c0040620] (kernel_thread+0x30/0x38) [2.437805] [c0040620] (kernel_thread+0x30/0x38) from [c0063888] (kthreadd+0xd4/0x13c) [2.448364] [c0063888] (kthreadd+0xd4/0x13c) from [c0013308] (ret_from_fork+0x14/0x2c) [2.448364] ---[ end trace da8cf92c433d1616 ]--- [4.028594] omap_i2c 4806.i2c: timeout waiting for bus ready [5.047637] omap_i2c 4806.i2c: timeout waiting for bus ready [6.662322] omap_i2c 4806.i2c: timeout waiting for bus ready [7.687499] omap_i2c 4806.i2c: timeout waiting for bus ready [8.717315] omap_i2c 4806.i2c: timeout waiting for bus ready [9.737365] omap_i2c 4806.i2c: timeout waiting for bus ready [ 10.747863] omap_i2c 4806.i2c: timeout waiting for bus ready [ 11.767608] omap_i2c 4806.i2c: timeout waiting for bus ready [ 12.768035] omap_i2c 4806.i2c: timeout waiting for bus ready [ 13.777893] omap_i2c 4806.i2c: timeout waiting for bus ready [ 14.787872] omap_i2c 4806.i2c: timeout waiting for bus ready [ 15.807128] omap_i2c 4806.i2c: timeout waiting for bus ready [ 17.318084] omap_i2c 4806.i2c: timeout waiting for bus ready [ 18.338226] omap_i2c 4806.i2c: timeout waiting for bus ready [ 19.367645] omap_i2c 4806.i2c: timeout waiting for bus ready [ 20.388031] omap_i2c 4806.i2c: timeout waiting for bus ready [ 21.407928]
[PATCH 5/5] i2c: omap: remove omap_i2c_isr() hw irq handler
The omap_i2c_isr() does the irq check and schedules threaded handler if any of
enabled IRQs is active, but currently the I2C IRQs are enabled just once,
when I2C IP is enabling (transfer started) and they aren't changed after that.
More over, now the I2C INTC IRQ is disabled when I2C IP is idled.
Thus, I2C IRQs will start coming only when we want that, and there is
no sense to have omap_i2c_isr() anymore:
- omap_i2c_isr_thread() does all needed checks
- synchronization is provided IRQ Core.
So, get rid of omap_i2c_isr(), custom locking and
struct omap_i2c_dev-lock variable.
CC: Kevin Hilman khil...@linaro.org
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
This is clean-up patch.
drivers/i2c/busses/i2c-omap.c | 33 +
1 file changed, 1 insertion(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index b3daf3f..749f390 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -183,7 +183,6 @@ enum {
#define OMAP_I2C_IP_V2_INTERRUPTS_MASK 0x6FFF
struct omap_i2c_dev {
- spinlock_t lock; /* IRQ synchronization */
struct device *dev;
void __iomem*base; /* virtual */
int irq;
@@ -876,35 +875,10 @@ static int omap_i2c_transmit_data(struct omap_i2c_dev
*dev, u8 num_bytes,
}
static irqreturn_t
-omap_i2c_isr(int irq, void *dev_id)
-{
- struct omap_i2c_dev *dev = dev_id;
- irqreturn_t ret = IRQ_HANDLED;
- u16 mask;
- u16 stat;
-
- spin_lock(dev-lock);
- if (pm_runtime_suspended(dev-dev)) {
- WARN_ONCE(true, We should never be here!\n);
- return IRQ_NONE;
- }
- mask = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
-
- if (stat mask)
- ret = IRQ_WAKE_THREAD;
-
- spin_unlock(dev-lock);
-
- return ret;
-}
-
-static irqreturn_t
omap_i2c_isr_thread(int this_irq, void *dev_id)
{
struct omap_i2c_dev *dev = dev_id;
- unsigned long flags;
u16 bits;
u16 stat;
int err = 0, count = 0;
@@ -914,7 +888,6 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
return IRQ_NONE;
}
- spin_lock_irqsave(dev-lock, flags);
do {
bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
@@ -1035,8 +1008,6 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
omap_i2c_complete_cmd(dev, err);
out:
- spin_unlock_irqrestore(dev-lock, flags);
-
return IRQ_HANDLED;
}
@@ -1146,8 +1117,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev-dev = pdev-dev;
dev-irq = irq;
- spin_lock_init(dev-lock);
-
platform_set_drvdata(pdev, dev);
init_completion(dev-cmd_complete);
@@ -1229,7 +1198,7 @@ omap_i2c_probe(struct platform_device *pdev)
IRQF_NO_SUSPEND, pdev-name, dev);
else
r = devm_request_threaded_irq(pdev-dev, dev-irq,
- omap_i2c_isr, omap_i2c_isr_thread,
+ NULL, omap_i2c_isr_thread,
IRQF_NO_SUSPEND | IRQF_ONESHOT,
pdev-name, dev);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] i2c: omap: handle all irqs befor unblocking omap_i2c_xfer_msg()
ARDY|NACK and ARDY|AL are set together in OMAP_I2C_STAT_REG, which will be
processed incorrectly now:
iterration 1:
- I2C irq triggered (ARDY|NACK)
- omap_i2c_isr_thread() will ask NACK, fill dev-cmd_err = OMAP_I2C_STAT_NACK
and trigger cmd_complete completion.
- omap_i2c_xfer_msg() will be unblocked, hande NACK and finish its execution.
- omap_i2c_xfer() will finish
iteration 2:
- I2C irq triggered (ARDY)
- omap_i2c_isr_thread() will ask ARDY, trigger completion
At this point dev-cmd_err == OMAP_I2C_STAT_NACK, cmd_complete is not
initialized and omap_i2c_xfer() may be completed at all.
So, I2C driver is not ready for iteration 2.
Hence, fix it by asking NACK, AL and ARDY all togather in omap_i2c_isr_thread()
before unblocking omap_i2c_xfer_msg() execution.
This is the old I2C interrupt handler behavior which was changed by commit:
1d7afc95946487945cc7f5019b41255b72224b70 i2c: omap: ack IRQ in parts.
CC: Kevin Hilman khil...@linaro.org
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/i2c/busses/i2c-omap.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 2dac598..46fb8a5 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -938,17 +938,15 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
break;
}
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL);
+
if (stat OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
- omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
- break;
}
if (stat OMAP_I2C_STAT_AL) {
dev_err(dev-dev, Arbitration lost\n);
err |= OMAP_I2C_STAT_AL;
- omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
- break;
}
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] i2c: omap: query STP always when NACK is received
According to I2C specification the NACK should be handled as folowing:
When SDA remains HIGH during this ninth clock pulse, this is defined as the Not
Acknowledge signal. The master can then gene rate either a STOP condition to
abort the transfer, or a repeated START condition to start a new transfer.
[http://www.nxp.com/documents/user_manual/UM10204.pdf]
The same is recomened by TI I2C wiki:
http://processors.wiki.ti.com/index.php/I2C_Tips
Currently, the OMAP I2C driver interrupts I2C trunsfer in case of NACK, but
It queries Stop condition OMAP_I2C_CON_REG.STP=1 only if NACK has been received
during the last message transmitting/recieving.
This may lead to stuck Bus in Bus Busy until I2C IP reset (idle/enable).
Hence, fix it by querying Stop condition (STP) always when NACK is received.
CC: Kevin Hilman khil...@linaro.org
CC: Felipe Balbi ba...@ti.com
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/i2c/busses/i2c-omap.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 46fb8a5..b3daf3f 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -618,11 +618,10 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (dev-cmd_err OMAP_I2C_STAT_NACK) {
if (msg-flags I2C_M_IGNORE_NAK)
return 0;
- if (stop) {
- w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
- w |= OMAP_I2C_CON_STP;
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
- }
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
+ w |= OMAP_I2C_CON_STP;
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
return -EREMOTEIO;
}
return -EIO;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] i2c: omap: add runtime check in isr to be sure that i2c is enabled
Add runtime check at the beginning of omap_i2c_isr/omap_i2c_isr_thread
to be sure that i2c is enabled, before performing IRQ handling and accessing
I2C IP registers:
if (pm_runtime_suspended(dev-dev)) {
WARN_ONCE(true, We should never be here!\n);
return IRQ_NONE;
}
Produce warning in case if ISR called when i2c is disabled
CC: Kevin Hilman khil...@linaro.org
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 97844ff..2dac598 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -885,6 +885,11 @@ omap_i2c_isr(int irq, void *dev_id)
u16 stat;
spin_lock(dev-lock);
+ if (pm_runtime_suspended(dev-dev)) {
+ WARN_ONCE(true, We should never be here!\n);
+ return IRQ_NONE;
+ }
+
mask = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
@@ -905,6 +910,11 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
u16 stat;
int err = 0, count = 0;
+ if (pm_runtime_suspended(dev-dev)) {
+ WARN_ONCE(true, We should never be here!\n);
+ return IRQ_NONE;
+ }
+
spin_lock_irqsave(dev-lock, flags);
do {
bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle
From: Kevin Hilman khil...@deeprootsystems.com Currently, runtime PM is used to keep the device enabled only during active transfers and for a configurable runtime PM autosuspend timout after an xfer. In addition to idling the device, driver's -runtime_suspend() method currently disables device interrupts when idle. However, on some SoCs (notably OMAP4+), the I2C hardware may shared with other coprocessors. This means that the MPU will still recieve interrupts if a coprocessor is using the I2C device. To avoid this, also disable interrupts at the MPU INTC when idling the device in -runtime_suspend() (and re-enable them in -runtime_resume().) This part based on an original patch from Shubhrajyoti Datta. NOTE: for proper sharing the I2C with a coprocessor, this driver still needs hwspinlock support added. More over, this patch fixes the kernel boot failure which happens when CONFIG_SENSORS_LM75=y: [2.251220] WARNING: at drivers/bus/omap_l3_noc.c:113 l3_interrupt_handler+0x140/0x184() [2.257781] L3 custom error: MASTER:MPU TARGET:L4 PER2 [2.264373] Modules linked in: [2.268463] CPU: 0 PID: 2 Comm: kthreadd Not tainted 3.10.0-rc4-00034-g042dd60-dirty #64 [2.270385] [c001a80c] (unwind_backtrace+0x0/0xf0) from [c0017238] (show_stack+0x10/0x14) [2.286102] [c0017238] (show_stack+0x10/0x14) from [c0040fd0] (warn_slowpath_common+0x4c/0x68) [2.295593] [c0040fd0] (warn_slowpath_common+0x4c/0x68) from [c0041080] (warn_slowpath_fmt+0x30/0x40) [2.299987] [c0041080] (warn_slowpath_fmt+0x30/0x40) from [c02c5ed0] (l3_interrupt_handler+0x140/0x184) [2.315582] [c02c5ed0] (l3_interrupt_handler+0x140/0x184) from [c009ffb8] (handle_irq_event_percpu+0x58/0x258) [2.323364] [c009ffb8] (handle_irq_event_percpu+0x58/0x258) from [c00a01f4] (handle_irq_event+0x3c/0x5c) [2.327819] [c00a01f4] (handle_irq_event+0x3c/0x5c) from [c00a2f7c] (handle_fasteoi_irq+0xbc/0x164) [2.337829] [c00a2f7c] (handle_fasteoi_irq+0xbc/0x164) from [c009f978] (generic_handle_irq+0x20/0x30) [2.357513] [c009f978] (generic_handle_irq+0x20/0x30) from [c0014168] (handle_IRQ+0x4c/0xac) [2.366821] [c0014168] (handle_IRQ+0x4c/0xac) from [c00085b4] (gic_handle_irq+0x28/0x5c) [2.375762] [c00085b4] (gic_handle_irq+0x28/0x5c) from [c04f08a4] (__irq_svc+0x44/0x5c) [2.379821] Exception stack(0xdb085ec0 to 0xdb085f08) [2.389953] 5ec0: 0001 0001 db07ea00 4113 db2317a8 db084000 02f1 [2.389953] 5ee0: db07ea00 c04fd990 db085f08 c009170c c04f03e8 [2.405609] 5f00: 2113 [2.408355] [c04f08a4] (__irq_svc+0x44/0x5c) from [c04f03e8] (_raw_spin_unlock_irqrestore+0x34/0x44) [2.418304] [c04f03e8] (_raw_spin_unlock_irqrestore+0x34/0x44) from [c00403c0] (do_fork+0xa4/0x2d4) [2.427795] [c00403c0] (do_fork+0xa4/0x2d4) from [c0040620] (kernel_thread+0x30/0x38) [2.437805] [c0040620] (kernel_thread+0x30/0x38) from [c0063888] (kthreadd+0xd4/0x13c) [2.448364] [c0063888] (kthreadd+0xd4/0x13c) from [c0013308] (ret_from_fork+0x14/0x2c) [2.448364] ---[ end trace da8cf92c433d1616 ]--- The root casue of crash is race between omap_i2c_runtime_suspend() and omap_i2c_isr_thread() CPU1: CPU2: |-omap_i2c_xfer | |- pm_runtime_put_autosuspend() | |-timeout |-omap_i2c_isr() |-return IRQ_WAKE_THREAD; |-omap_i2c_runtime_suspend() | |-omap_i2c_isr_thread() |- oops is here - I2C module is in idle state Cc: Nishanth Menon n...@ti.com Signed-off-by: Kevin Hilman khil...@linaro.org Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com --- drivers/i2c/busses/i2c-omap.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 64c26f9..97844ff 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1290,6 +1290,8 @@ static int omap_i2c_runtime_suspend(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct omap_i2c_dev *_dev = platform_get_drvdata(pdev); + disable_irq(_dev-irq); + _dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG); if (_dev-scheme == OMAP_I2C_SCHEME_0) @@ -1320,6 +1322,8 @@ static int omap_i2c_runtime_resume(struct device *dev) __omap_i2c_init(_dev); + enable_irq(_dev-irq); + return 0; } #endif /* CONFIG_PM_RUNTIME */ -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] i2c: omap: add runtime check in isr to be sure that i2c is enabled
Hi,
On Fri, Jun 07, 2013 at 09:46:05PM +0300, Grygorii Strashko wrote:
Add runtime check at the beginning of omap_i2c_isr/omap_i2c_isr_thread
to be sure that i2c is enabled, before performing IRQ handling and accessing
I2C IP registers:
if (pm_runtime_suspended(dev-dev)) {
WARN_ONCE(true, We should never be here!\n);
return IRQ_NONE;
}
Produce warning in case if ISR called when i2c is disabled
CC: Kevin Hilman khil...@linaro.org
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 97844ff..2dac598 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -885,6 +885,11 @@ omap_i2c_isr(int irq, void *dev_id)
u16 stat;
spin_lock(dev-lock);
+ if (pm_runtime_suspended(dev-dev)) {
+ WARN_ONCE(true, We should never be here!\n);
+ return IRQ_NONE;
+ }
returning IRQ_NONE is not what you want to do in this case. You want to
setup a flag so that your runtime_resume() knows that there are pending
events to be handled and you handle those in runtime_resume time.
But to be frank, I don't see how this can trigger since we're calling
pm_runtime_get_sync() from omap_i2c_xfer() which means by the time
pm_runtime_get_sync() returns, assuming no errors, i2c module should be
fully resumed and ready to go. Perhaps you have found a bug somewhere
else ?
Also, your 'We should never be here' message isn't helpfull at all.
@@ -905,6 +910,11 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
u16 stat;
int err = 0, count = 0;
+ if (pm_runtime_suspended(dev-dev)) {
+ WARN_ONCE(true, We should never be here!\n);
+ return IRQ_NONE;
+ }
because of IRQF_ONESHOT I can't see how this would *ever* be a valid
check.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 3/5] i2c: omap: handle all irqs befor unblocking omap_i2c_xfer_msg()
Hi, On Fri, Jun 07, 2013 at 09:46:06PM +0300, Grygorii Strashko wrote: ARDY|NACK and ARDY|AL are set together in OMAP_I2C_STAT_REG, which will be Have you seen that happen ever ? AL is Arbitration Lost, we never put OMAP in a multi-master environment before. ARDY | NACK I also find it a bit hard for those two to happen together since ARDY will be set when you can change controller's register *again*, mening that a transfer has completed. Also, we need to follow what the programming model says. And, I don't have docs with me right now, but IIRC it tells us to bail out if any of the error conditions are met. -- balbi signature.asc Description: Digital signature
Re: [PATCH 4/5] i2c: omap: query STP always when NACK is received
Hi,
On Fri, Jun 07, 2013 at 09:46:07PM +0300, Grygorii Strashko wrote:
According to I2C specification the NACK should be handled as folowing:
When SDA remains HIGH during this ninth clock pulse, this is defined as the
Not
Acknowledge signal. The master can then gene rate either a STOP condition to
abort the transfer, or a repeated START condition to start a new transfer.
right ...
[http://www.nxp.com/documents/user_manual/UM10204.pdf]
The same is recomened by TI I2C wiki:
http://processors.wiki.ti.com/index.php/I2C_Tips
Currently, the OMAP I2C driver interrupts I2C trunsfer in case of NACK, but
It queries Stop condition OMAP_I2C_CON_REG.STP=1 only if NACK has been
received
during the last message transmitting/recieving.
This may lead to stuck Bus in Bus Busy until I2C IP reset (idle/enable).
Hence, fix it by querying Stop condition (STP) always when NACK is received.
CC: Kevin Hilman khil...@linaro.org
CC: Felipe Balbi ba...@ti.com
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/i2c/busses/i2c-omap.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 46fb8a5..b3daf3f 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -618,11 +618,10 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (dev-cmd_err OMAP_I2C_STAT_NACK) {
if (msg-flags I2C_M_IGNORE_NAK)
return 0;
- if (stop) {
- w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
- w |= OMAP_I2C_CON_STP;
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
- }
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
+ w |= OMAP_I2C_CON_STP;
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
... and this is breaking repeated start.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 5/5] i2c: omap: remove omap_i2c_isr() hw irq handler
Hi, On Fri, Jun 07, 2013 at 09:46:08PM +0300, Grygorii Strashko wrote: The omap_i2c_isr() does the irq check and schedules threaded handler if any of enabled IRQs is active, but currently the I2C IRQs are enabled just once, when I2C IP is enabling (transfer started) and they aren't changed after that. More over, now the I2C INTC IRQ is disabled when I2C IP is idled. Thus, I2C IRQs will start coming only when we want that, and there is no sense to have omap_i2c_isr() anymore: so ? we still want to check if this device generated IRQs in hardirq context. What if the IRQ line is shared ? -- balbi signature.asc Description: Digital signature
Re: [PATCH] ARM: dts: add dtsi for palmas
On 06/07/2013 06:27 AM, Benoit Cousson wrote:
Hi Keerthy,
On 06/07/2013 01:28 PM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes. This is
based on the patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
https://lkml.org/lkml/2013/6/6/25
...
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
...
+palmas {
+compatible = ti,palmas;
+interrupt-controller;
+#interrupt-cells = 2;
The I2C address should be there as well. We used to put it in the board
file, but this is really an I2C device specific information and not
board specific in that case.
I thought the I2C address was variable depending on OTP settings, and
hence the I2C address is board-specific; depending on which variant of
the PMIC was stuffed onto the board?
--
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: DTS: TWL4030: fix mux and wakeup for SYS_NIRQ line
On 11:31-20130607, Kevin Hilman wrote:
On most OMAP3 platforms, the twl4030 IRQ line is connected to the
SYS_NIRQ line on OMAP. Add another DTS include file
(twl4030_omap3.dtsi) for boards that hook up the twl4030 this way
to include.
This allows RTC wake from off-mode to work again on OMAP3-based
platforms with twl4030. Tested on 3530/Beagle, 3730/Beagle-xM,
3530/Overo, 3730/Overo-STORM.
Special thanks to Florian Vaussard for suggesting use of preprocessor
feature.
Cc: Florian Vaussard florian.vauss...@epfl.ch
Cc: Benoit Cousson b-cous...@ti.com
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@linaro.org
Thanks,
Reviewed-by: Nishanth Menon n...@ti.com
---
v3: renamed to twl4030_omap3 (suggested by Nishanth), add GPL, fix whitespace
v2: Updated to change board files instead of twl4030 file.
arch/arm/boot/dts/omap3-beagle-xm.dts | 1 +
arch/arm/boot/dts/omap3-beagle.dts | 1 +
arch/arm/boot/dts/omap3-devkit8000.dts | 1 +
arch/arm/boot/dts/omap3-evm.dts| 1 +
arch/arm/boot/dts/omap3-igep.dtsi | 1 +
arch/arm/boot/dts/omap3-overo.dtsi | 1 +
arch/arm/boot/dts/omap3430-sdp.dts | 1 +
arch/arm/boot/dts/twl4030_omap3.dtsi | 25 +
8 files changed, 32 insertions(+)
create mode 100644 arch/arm/boot/dts/twl4030_omap3.dtsi
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index ad17b6b..afdb164 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -96,6 +96,7 @@
};
#include twl4030.dtsi
+#include twl4030_omap3.dtsi
i2c2 {
clock-frequency = 40;
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index eb7e02a..dfd8310 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -135,6 +135,7 @@
};
#include twl4030.dtsi
+#include twl4030_omap3.dtsi
mmc1 {
vmmc-supply = vmmc1;
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts
b/arch/arm/boot/dts/omap3-devkit8000.dts
index 5be71b1..af32eff 100644
--- a/arch/arm/boot/dts/omap3-devkit8000.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -81,6 +81,7 @@
};
#include twl4030.dtsi
+#include twl4030_omap3.dtsi
mmc1 {
vmmc-supply = vmmc1;
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index baa24bb..7d4329d 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -45,6 +45,7 @@
};
#include twl4030.dtsi
+#include twl4030_omap3.dtsi
i2c2 {
clock-frequency = 40;
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index 5224c29..bc48b11 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -87,6 +87,7 @@
};
#include twl4030.dtsi
+#include twl4030_omap3.dtsi
i2c2 {
clock-frequency = 40;
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index 144a5a2..4bc78896 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -50,6 +50,7 @@
};
#include twl4030.dtsi
+#include twl4030_omap3.dtsi
/* i2c2 pins are used for gpio */
i2c2 {
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
b/arch/arm/boot/dts/omap3430-sdp.dts
index 2a725a0..c4a1c0a 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -29,6 +29,7 @@
};
#include twl4030.dtsi
+#include twl4030_omap3.dtsi
mmc1 {
vmmc-supply = vmmc1;
diff --git a/arch/arm/boot/dts/twl4030_omap3.dtsi
b/arch/arm/boot/dts/twl4030_omap3.dtsi
new file mode 100644
index 000..c353ef0
--- /dev/null
+++ b/arch/arm/boot/dts/twl4030_omap3.dtsi
@@ -0,0 +1,25 @@
+/*
+ * Copyright (C) 2013 Linaro, Ltd.
+ *
+ * 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.
+ */
+
+twl {
+ pinctrl-names = default;
+ pinctrl-0 = twl4030_pins;
+};
+
+omap3_pmx_core {
+ /*
+ * On most OMAP3 platforms, the twl4030 IRQ line is connected
+ * to the SYS_NIRQ line on OMAP. Therefore, configure the
+ * defaults for the SYS_NIRQ pin here.
+ */
+ twl4030_pins: pinmux_twl4030_pins {
+ pinctrl-single,pins =
+ 0x1b0 (PIN_INPUT_PULLUP | PIN_OFF_WAKEUPENABLE |
MUX_MODE0) /* sys_nirq.sys_nirq */
+ ;
+ };
+};
--
1.8.3
--
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: dts: add dtsi for palmas
On 06/07/2013 05:28 AM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes. This is
based on the patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
https://lkml.org/lkml/2013/6/6/25
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
+palmas {
Hmmm. That (i.e. requiring the board file to declare the node, then
setting up all the content by later including this file) is an
interesting approach. I guess it's reasonable. The one issue is that it
makes it a little harder for the board file to override any of the
properties in this file., although it certainly is possible by including
those overrides after the include.
Irrespective of that, some comments on this:
+ palmas_pmic {
+ ti,ldo6-vibrator;
For example, what if the board doesn't want to have the property set?
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
Or what if the board wants to limit the voltage range of this regulator
due to what it's used for on the board.
+ regulator-always-on;
+ regulator-boot-on;
And those two properties are almost certainly board-specific policy.
--
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
[PATCHv3 0/6] arm: enable TI SoC thermal driver
Hello, Idea is to add the missing bits under arch/arm/*omap* required to enable by default the ti-soc-thermal driver. I am planing to move it out of staging tree. This has been scheduled to 3.11. It would be interesting to get feedback from other ppl. By enabling it by default we could reach more ppl for testing it across the supported chips. The difference from v2 is that now the driver is changed to use GPIO bindings for Tshut as suggested by Benoit and I added a simple description what is bandgap. The difference from v1 is just that patch 01 doe snot include the dts prefix, as it is not supposed to be DTS related. Eduardo Valentin (6): thermal: ti-soc-thermal: use standard GPIO DT bindings arm: introduce config HAS_BANDGAP arm: dts: add bandgap entry for OMAP443x devices arm: dts: add bandgap entry for OMAP4460 devices arm: omap2plus_defconfig: enable TI bandgap driver arm: omap2plus_defconfig: enable DRA752 thermal support by default arch/arm/Kconfig | 3 +++ arch/arm/boot/dts/omap443x.dtsi | 4 arch/arm/boot/dts/omap4460.dtsi | 9 + arch/arm/configs/omap2plus_defconfig | 12 arch/arm/mach-omap2/Kconfig | 1 + drivers/staging/ti-soc-thermal/ti-bandgap.c | 8 ++-- drivers/staging/ti-soc-thermal/ti_soc_thermal.txt | 9 + 7 files changed, 36 insertions(+), 10 deletions(-) -- 1.8.2.1.342.gfa7285d -- 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
[PATCHv3 1/6] thermal: ti-soc-thermal: use standard GPIO DT bindings
This change updates the ti-soc-thermal driver to use
standard GPIO DT bindings to read the GPIO number associated
to thermal shutdown IRQ, in case the device features it.
Previously, the code was using a specific DT bindings.
As now OMAP supports the standard way to model GPIOs,
there is no point in having a ti specific binding.
Cc: Zhang Rui rui.zh...@intel.com
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: linux...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/ti-soc-thermal/ti-bandgap.c | 8 ++--
drivers/staging/ti-soc-thermal/ti_soc_thermal.txt | 9 +
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/ti-soc-thermal/ti-bandgap.c
b/drivers/staging/ti-soc-thermal/ti-bandgap.c
index f20c1cf..c7fc0d0 100644
--- a/drivers/staging/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/staging/ti-soc-thermal/ti-bandgap.c
@@ -38,6 +38,7 @@
#include linux/of_device.h
#include linux/of_platform.h
#include linux/of_irq.h
+#include linux/of_gpio.h
#include linux/io.h
#include ti-bandgap.h
@@ -1123,7 +1124,6 @@ static struct ti_bandgap *ti_bandgap_build(struct
platform_device *pdev)
const struct of_device_id *of_id;
struct ti_bandgap *bgp;
struct resource *res;
- u32 prop;
int i;
/* just for the sake */
@@ -1167,11 +1167,7 @@ static struct ti_bandgap *ti_bandgap_build(struct
platform_device *pdev)
} while (res);
if (TI_BANDGAP_HAS(bgp, TSHUT)) {
- if (of_property_read_u32(node, ti,tshut-gpio, prop) 0) {
- dev_err(pdev-dev, missing tshut gpio in device
tree\n);
- return ERR_PTR(-EINVAL);
- }
- bgp-tshut_gpio = prop;
+ bgp-tshut_gpio = of_get_gpio(node, 0);
if (!gpio_is_valid(bgp-tshut_gpio)) {
dev_err(pdev-dev, invalid gpio for tshut (%d)\n,
bgp-tshut_gpio);
diff --git a/drivers/staging/ti-soc-thermal/ti_soc_thermal.txt
b/drivers/staging/ti-soc-thermal/ti_soc_thermal.txt
index a4a33d1..382bd98 100644
--- a/drivers/staging/ti-soc-thermal/ti_soc_thermal.txt
+++ b/drivers/staging/ti-soc-thermal/ti_soc_thermal.txt
@@ -17,8 +17,9 @@ Required properties:
- interrupts : this entry should indicate which interrupt line
the talert signal is routed to;
Specific:
-- ti,tshut-gpio : this entry should be used to inform which GPIO
-line the tshut signal is routed to;
+- gpios : this entry should be used to inform which GPIO
+line the tshut signal is routed to. The informed GPIO will
+be treated as an IRQ;
- regs : this entry must also be specified and it is specific
to each bandgap version, because the mapping may change from
soc to soc, apart of depending on available features.
@@ -37,7 +38,7 @@ bandgap {
0x4a002378 0x18;
compatible = ti,omap4460-bandgap;
interrupts = 0 126 4; /* talert */
- ti,tshut-gpio = 86;
+ gpios = gpio3 22 0; /* tshut */
};
OMAP4470:
@@ -47,7 +48,7 @@ bandgap {
0x4a002378 0x18;
compatible = ti,omap4470-bandgap;
interrupts = 0 126 4; /* talert */
- ti,tshut-gpio = 86;
+ gpios = gpio3 22 0; /* tshut */
};
OMAP5430:
--
1.8.2.1.342.gfa7285d
--
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
[PATCHv3 2/6] arm: introduce config HAS_BANDGAP
Bandgap is a device used to measure temperature on electronic equipments. It is widely used in digital integrated circuits. It is based on the dependency between silicon voltage and temperature. This patch introduce HAS_BANDGAP config entry. This config is a boolean value so that arch code can flag if they feature a bandgap device. This config entry follows the same idea behind ARCH_HAS_CPUFREQ. Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: Fabio Stevam feste...@gmail.com Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- arch/arm/Kconfig| 3 +++ arch/arm/mach-omap2/Kconfig | 1 + 2 files changed, 4 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index d423d58..bcbdec9 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -174,6 +174,9 @@ config ARCH_HAS_CPUFREQ and that the relevant menu configurations are displayed for it. +config ARCH_HAS_BANDGAP + bool + config GENERIC_HWEIGHT bool default y diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f49cd51..8620ab5 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -4,6 +4,7 @@ config ARCH_OMAP config ARCH_OMAP2PLUS bool TI OMAP2/3/4/5 SoCs with device tree support if (ARCH_MULTI_V6 || ARCH_MULTI_V7) select ARCH_HAS_CPUFREQ + select ARCH_HAS_BANDGAP select ARCH_HAS_HOLES_MEMORYMODEL select ARCH_OMAP select ARCH_REQUIRE_GPIOLIB -- 1.8.2.1.342.gfa7285d -- 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
[PATCHv3 6/6] arm: omap2plus_defconfig: enable DRA752 thermal support by default
Make DRA752 thermal support enabled on omap2plus_defconfig Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk Cc: AnilKumar Ch anilku...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- arch/arm/configs/omap2plus_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 6e6c494..07aab0b 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -248,6 +248,7 @@ CONFIG_TI_SOC_THERMAL=y CONFIG_TI_THERMAL=y CONFIG_OMAP4_THERMAL=y CONFIG_OMAP5_THERMAL=y +CONFIG_DRA752_THERMAL=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set -- 1.8.2.1.342.gfa7285d -- 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
[PATCHv3 5/6] arm: omap2plus_defconfig: enable TI bandgap driver
Enable the bandgap driver for TI SoCs thermal support. Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk Cc: AnilKumar Ch anilku...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- arch/arm/configs/omap2plus_defconfig | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index c1ef64b..6e6c494 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -151,6 +151,13 @@ CONFIG_W1=y CONFIG_POWER_SUPPLY=y CONFIG_SENSORS_LM75=m CONFIG_WATCHDOG=y +CONFIG_THERMAL=y +CONFIG_THERMAL_HWMON=y +CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y +CONFIG_THERMAL_GOV_FAIR_SHARE=y +CONFIG_THERMAL_GOV_STEP_WISE=y +CONFIG_THERMAL_GOV_USER_SPACE=y +CONFIG_CPU_THERMAL=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y CONFIG_MFD_TPS65217=y @@ -237,6 +244,10 @@ CONFIG_RTC_DRV_TWL4030=y CONFIG_RTC_DRV_OMAP=y CONFIG_DMADEVICES=y CONFIG_DMA_OMAP=y +CONFIG_TI_SOC_THERMAL=y +CONFIG_TI_THERMAL=y +CONFIG_OMAP4_THERMAL=y +CONFIG_OMAP5_THERMAL=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set -- 1.8.2.1.342.gfa7285d -- 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
[PATCHv3 4/6] arm: dts: add bandgap entry for OMAP4460 devices
Include bandgap devices for OMAP4460 devices.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap4460.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 2cf227c..ea97201 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -29,4 +29,13 @@
0 55 0x4;
ti,hwmods = debugss;
};
+
+ bandgap {
+ reg = 0x4a002260 0x4
+ 0x4a00232C 0x4
+ 0x4a002378 0x18;
+ compatible = ti,omap4460-bandgap;
+ interrupts = 0 126 4; /* talert */
+ gpios = gpio3 22 0; /* tshut */
+ };
};
--
1.8.2.1.342.gfa7285d
--
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
[PATCHv3 3/6] arm: dts: add bandgap entry for OMAP443x devices
This patch add the bandgap entry for OMAP4430 devices.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap443x.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index cccf39a..8d6c968 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -24,4 +24,8 @@
clock-latency = 30; /* From legacy driver */
};
};
+ bandgap {
+ reg = 0x4a002260 0x4 0x4a00232C 0x4;
+ compatible = ti,omap4430-bandgap;
+ };
};
--
1.8.2.1.342.gfa7285d
--
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] pinctrl: single: Prepare for supporting SoC specific features
Let's replace is_pinconf with flags and add struct pcs_soc so we
can support also other features like pin wake-up events. Let's
export the probe so the SoC specific modules can pass their
SoC specific data to pinctrl-single if needed.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/pinctrl/pinctrl-single.c | 53 +++---
drivers/pinctrl/pinctrl-single.h | 15 +++
2 files changed, 52 insertions(+), 16 deletions(-)
create mode 100644 drivers/pinctrl/pinctrl-single.h
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index b9fa046..0f178d1 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -26,6 +26,7 @@
#include core.h
#include pinconf.h
+#include pinctrl-single.h
#define DRIVER_NAMEpinctrl-single
#define PCS_MUX_PINS_NAME pinctrl-single,pins
@@ -162,7 +163,7 @@ struct pcs_name {
* @fshift:function register shift
* @foff: value to turn mux off
* @fmax: max number of functions in fmask
- * @is_pinconf:whether supports pinconf
+ * @flags: supported features
* @names: array of register names for pins
* @pins: physical pins on the SoC
* @pgtree:pingroup index radix tree
@@ -175,6 +176,7 @@ struct pcs_name {
* @desc: pin controller descriptor
* @read: register read function to use
* @write: register write function to use
+ * @soc: SoC glue
*/
struct pcs_device {
struct resource *res;
@@ -189,7 +191,7 @@ struct pcs_device {
unsigned foff;
unsigned fmax;
bool bits_per_mux;
- bool is_pinconf;
+ unsigned flags;
struct pcs_name *names;
struct pcs_data pins;
struct radix_tree_root pgtree;
@@ -202,6 +204,7 @@ struct pcs_device {
struct pinctrl_desc desc;
unsigned (*read)(void __iomem *reg);
void (*write)(unsigned val, void __iomem *reg);
+ const struct pcs_soc *soc;
};
static int pcs_pinconf_get(struct pinctrl_dev *pctldev, unsigned pin,
@@ -1026,7 +1029,7 @@ static int pcs_parse_pinconf(struct pcs_device *pcs,
struct device_node *np,
};
/* If pinconf isn't supported, don't parse properties in below. */
- if (!pcs-is_pinconf)
+ if (!(pcs-flags PCS_HAS_PINCONF))
return 0;
/* cacluate how much properties are supported in current node */
@@ -1165,7 +1168,7 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device
*pcs,
(*map)-data.mux.group = np-name;
(*map)-data.mux.function = np-name;
- if (pcs-is_pinconf) {
+ if (pcs-flags PCS_HAS_PINCONF) {
res = pcs_parse_pinconf(pcs, np, function, map);
if (res)
goto free_pingroups;
@@ -1346,18 +1349,14 @@ static int pcs_add_gpio_func(struct device_node *node,
struct pcs_device *pcs)
return ret;
}
-static int pcs_probe(struct platform_device *pdev)
+int pinctrl_single_probe(struct platform_device *pdev,
+const struct pcs_soc *soc)
{
struct device_node *np = pdev-dev.of_node;
- const struct of_device_id *match;
struct resource *res;
struct pcs_device *pcs;
int ret;
- match = of_match_device(pcs_of_match, pdev-dev);
- if (!match)
- return -EINVAL;
-
pcs = devm_kzalloc(pdev-dev, sizeof(*pcs), GFP_KERNEL);
if (!pcs) {
dev_err(pdev-dev, could not allocate\n);
@@ -1368,7 +1367,8 @@ static int pcs_probe(struct platform_device *pdev)
INIT_LIST_HEAD(pcs-pingroups);
INIT_LIST_HEAD(pcs-functions);
INIT_LIST_HEAD(pcs-gpiofuncs);
- pcs-is_pinconf = match-data;
+ pcs-flags = soc-flags;
+ pcs-soc = soc;
PCS_GET_PROP_U32(pinctrl-single,register-width, pcs-width,
register width not specified\n);
@@ -1437,7 +1437,7 @@ static int pcs_probe(struct platform_device *pdev)
pcs-desc.name = DRIVER_NAME;
pcs-desc.pctlops = pcs_pinctrl_ops;
pcs-desc.pmxops = pcs_pinmux_ops;
- if (pcs-is_pinconf)
+ if (pcs-flags PCS_HAS_PINCONF)
pcs-desc.confops = pcs_pinconf_ops;
pcs-desc.owner = THIS_MODULE;
@@ -1466,8 +1466,20 @@ free:
return ret;
}
+EXPORT_SYMBOL_GPL(pinctrl_single_probe);
+
+static int pcs_probe(struct platform_device *pdev)
+{
+ const struct of_device_id *match;
+
+ match = of_match_device(pcs_of_match, pdev-dev);
+ if (!match)
+ return -EINVAL;
+
+ return pinctrl_single_probe(pdev, (struct pcs_soc *)match-data);
+}
-static int pcs_remove(struct platform_device *pdev)
+int
[PATCH 4/4] ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap
Now pinctrl-single-omap can handle the wake-up events for us now
as long as the events are configured in the .dts files.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap3.dtsi |4 ++--
arch/arm/boot/dts/omap4.dtsi |4 ++--
arch/arm/boot/dts/omap5.dtsi |4 ++--
arch/arm/mach-omap2/mux.c|8 ++--
arch/arm/mach-omap2/pm34xx.c |2 ++
arch/arm/mach-omap2/prm_common.c | 26 ++
6 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99ba6e1..847af56 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -94,7 +94,7 @@
};
omap3_pmx_core: pinmux@48002030 {
- compatible = ti,omap3-padconf, pinctrl-single;
+ compatible = ti,omap3-padconf;
reg = 0x48002030 0x05cc;
#address-cells = 1;
#size-cells = 0;
@@ -103,7 +103,7 @@
};
omap3_pmx_wkup: pinmux@0x48002a00 {
- compatible = ti,omap3-padconf, pinctrl-single;
+ compatible = ti,omap3-padconf;
reg = 0x48002a00 0x5c;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..2a4f099 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -107,7 +107,7 @@
};
omap4_pmx_core: pinmux@4a100040 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a100040 0x0196;
#address-cells = 1;
#size-cells = 0;
@@ -115,7 +115,7 @@
pinctrl-single,function-mask = 0x7fff;
};
omap4_pmx_wkup: pinmux@4a31e040 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a31e040 0x0038;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 3dd7ff8..5515d58 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -100,7 +100,7 @@
};
omap5_pmx_core: pinmux@4a002840 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a002840 0x01b6;
#address-cells = 1;
#size-cells = 0;
@@ -108,7 +108,7 @@
pinctrl-single,function-mask = 0x7fff;
};
omap5_pmx_wkup: pinmux@4ae0c840 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4ae0c840 0x0038;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index f82cf87..48094b58 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -811,6 +811,12 @@ int __init omap_mux_late_init(void)
}
}
+ omap_mux_dbg_init();
+
+ /* see pinctrl-single-omap for the wake-up interrupt handling */
+ if (of_have_populated_dt())
+ return 0;
+
ret = request_irq(omap_prcm_event_to_irq(io),
omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND,
hwmod_io, omap_mux_late_init);
@@ -818,8 +824,6 @@ int __init omap_mux_late_init(void)
if (ret)
pr_warning(mux: Failed to setup hwmod io irq %d\n, ret);
- omap_mux_dbg_init();
-
return 0;
}
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c018593..9b19b14 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -172,6 +172,8 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs, u32
ignore_bits)
wkst = omap2_prm_read_mod_reg(module, wkst_off);
wkst = ~ignore_bits;
c++;
+ if (c 10)
+ break;
}
omap2_cm_write_mod_reg(iclk, module, iclk_off);
omap2_cm_write_mod_reg(fclk, module, fclk_off);
diff --git a/arch/arm/mach-omap2/prm_common.c
[PATCH 2/4] pinctrl: single: Add hardware specific hooks for IRQ and GPIO wake-up events
At least on omaps, each board typically has at least one device
configured as wake-up capable from deeper idle modes. In the
deeper idle modes the normal interrupt wake-up path won't work
as the logic is powered off and separate wake-up hardware is
available either via IO ring or GPIO hardware. The wake-up
event can be device specific, or may need to be dynamically
remuxed to GPIO input for wake-up events. When the wake-up
event happens, it's IRQ need to be called so the device won't
lose interrupts.
Allow supporting IRQ and GPIO wake-up events if a hardware
spefific module is registered for the enable and disable
calls.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
.../devicetree/bindings/pinctrl/pinctrl-single.txt |5 +
drivers/pinctrl/pinctrl-single.c | 104 +---
drivers/pinctrl/pinctrl-single.h | 28 +
3 files changed, 123 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 08f0c3d..5dfd74b 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -68,6 +68,10 @@ Optional properties:
The number of parameters is depend on #pinctrl-single,gpio-range-cells
property.
+- interrrupts : the interrupt that a function may have for a wake-up event
+
+- gpios: the gpio that a function may have for a wake-up event
+
/* pin base, nr pins gpio function */
pinctrl-single,gpio-range = range 0 3 0 range 3 9 1;
@@ -204,6 +208,7 @@ pmx_gpio: pinmux@d401e000 {
0xdc 0x118
0xde 0
;
+ interrupts = 74;
};
};
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 0f178d1..7cb7940 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -19,6 +19,8 @@
#include linux/of.h
#include linux/of_device.h
#include linux/of_address.h
+#include linux/of_gpio.h
+#include linux/of_irq.h
#include linux/pinctrl/pinctrl.h
#include linux/pinctrl/pinmux.h
@@ -95,6 +97,8 @@ struct pcs_conf_type {
* @nvals: number of entries in vals array
* @pgnames: array of pingroup names the function uses
* @npgnames: number of pingroup names the function uses
+ * @irq: optional irq associated with the function
+ * @gpio: optional gpio associated with the function
* @node: list node
*/
struct pcs_function {
@@ -105,6 +109,8 @@ struct pcs_function {
int npgnames;
struct pcs_conf_vals *conf;
int nconfs;
+ int irq;
+ int gpio;
struct list_head node;
};
@@ -410,6 +416,18 @@ static int pcs_get_function(struct pinctrl_dev *pctldev,
unsigned pin,
return 0;
}
+static void pcs_reg_init(struct pcs_reg *p, struct pcs_device *pcs,
+struct pcs_function *func,
+void __iomem *reg, unsigned val)
+{
+ p-read = pcs-read;
+ p-write = pcs-write;
+ p-irq = func-irq;
+ p-gpio = func-gpio;
+ p-reg = reg;
+ p-val = val;
+}
+
static int pcs_enable(struct pinctrl_dev *pctldev, unsigned fselector,
unsigned group)
{
@@ -442,6 +460,12 @@ static int pcs_enable(struct pinctrl_dev *pctldev,
unsigned fselector,
val = ~mask;
val |= (vals-val mask);
pcs-write(val, vals-reg);
+ if ((func-irq || func-gpio) pcs-soc pcs-soc-enable) {
+ struct pcs_reg pcsr;
+
+ pcs_reg_init(pcsr, pcs, func, vals-reg, val);
+ pcs-soc-enable(pcs-soc, pcsr);
+ }
}
return 0;
@@ -466,18 +490,6 @@ static void pcs_disable(struct pinctrl_dev *pctldev,
unsigned fselector,
return;
}
- /*
-* Ignore disable if function-off is not specified. Some hardware
-* does not have clearly defined disable function. For pin specific
-* off modes, you can use alternate named states as described in
-* pinctrl-bindings.txt.
-*/
- if (pcs-foff == PCS_OFF_DISABLED) {
- dev_dbg(pcs-dev, ignoring disable for %s function%i\n,
- func-name, fselector);
- return;
- }
-
dev_dbg(pcs-dev, disabling function%i %s\n,
fselector, func-name);
@@ -488,8 +500,28 @@ static void pcs_disable(struct pinctrl_dev *pctldev,
unsigned fselector,
vals = func-vals[i];
val = pcs-read(vals-reg);
val = ~pcs-fmask;
-
[PATCH 0/4] pinctrl single support for SoC specific features
Hi all, Here are few patches to add support for SoC specific features to pinctrl-single. This is needed at least for omaps to support IO chain wake-up events from deeper idle states. With this patch series, device drivers can request named pinctrl states like active and idle from the PM runtime suspend and resume calls to set the wake enable bits for selected pins. Further the device driver can toggle the wake-up feature as needed based on the device_may_wakeup() state set by the standard sysfs power/wakeup entry. This is implemented in a separate pinctrl-single-omap driver that works together with pinctrl-single. This way the SoC specific are separated from the common pinctrl-single, and allows a relatively easy way to implement SoC specific things like wake-up events, pin interrupts, and GPIO. Regards, Tony --- Tony Lindgren (4): pinctrl: single: Prepare for supporting SoC specific features pinctrl: single: Add hardware specific hooks for IRQ and GPIO wake-up events pinctrl: single: omap: Add SoC specific module for wake-up events ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap .../devicetree/bindings/pinctrl/pinctrl-single.txt |5 arch/arm/boot/dts/omap3.dtsi |4 arch/arm/boot/dts/omap4.dtsi |4 arch/arm/boot/dts/omap5.dtsi |4 arch/arm/mach-omap2/mux.c |8 - arch/arm/mach-omap2/pm34xx.c |2 arch/arm/mach-omap2/prm_common.c | 26 ++ drivers/pinctrl/Makefile |3 drivers/pinctrl/pinctrl-single-omap.c | 287 drivers/pinctrl/pinctrl-single.c | 157 +-- drivers/pinctrl/pinctrl-single.h | 43 +++ include/linux/platform_data/pinctrl-single-omap.h |4 12 files changed, 508 insertions(+), 39 deletions(-) create mode 100644 drivers/pinctrl/pinctrl-single-omap.c create mode 100644 drivers/pinctrl/pinctrl-single.h create mode 100644 include/linux/platform_data/pinctrl-single-omap.h -- 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 3/4] pinctrl: single: omap: Add SoC specific module for wake-up events
For wake-up events from deeper idle modes we need to check the
configured padconf registers for the wake-up bit and then call
the related interrupt handler.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/pinctrl/Makefile |3
drivers/pinctrl/pinctrl-single-omap.c | 287 +
include/linux/platform_data/pinctrl-single-omap.h |4
3 files changed, 293 insertions(+), 1 deletion(-)
create mode 100644 drivers/pinctrl/pinctrl-single-omap.c
create mode 100644 include/linux/platform_data/pinctrl-single-omap.h
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 9bdaeb8..abf7f01 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -30,7 +30,8 @@ obj-$(CONFIG_PINCTRL_NOMADIK) += pinctrl-nomadik.o
obj-$(CONFIG_PINCTRL_STN8815) += pinctrl-nomadik-stn8815.o
obj-$(CONFIG_PINCTRL_DB8500) += pinctrl-nomadik-db8500.o
obj-$(CONFIG_PINCTRL_DB8540) += pinctrl-nomadik-db8540.o
-obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o
+pcs-$(CONFIG_ARCH_OMAP2PLUS) += pinctrl-single-omap.o
+obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o $(pcs-y)
obj-$(CONFIG_PINCTRL_SIRF) += pinctrl-sirf.o
obj-$(CONFIG_PINCTRL_SUNXI)+= pinctrl-sunxi.o
obj-$(CONFIG_PINCTRL_TEGRA)+= pinctrl-tegra.o
diff --git a/drivers/pinctrl/pinctrl-single-omap.c
b/drivers/pinctrl/pinctrl-single-omap.c
new file mode 100644
index 000..680cf81
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-single-omap.c
@@ -0,0 +1,287 @@
+/*
+ * pinctrl-single-omap - omap specific wake-up irq handler
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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/interrupt.h
+#include linux/io.h
+#include linux/irq.h
+#include linux/list.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/platform_data/pinctrl-single-omap.h
+#include linux/pm_runtime.h
+
+#include pinctrl-single.h
+
+#define OMAP_WAKEUP_EN (1 14)
+#define OMAP_WAKEUP_EVENT (1 15)
+#define OMAP_WAKEUP_EVENT_MASK (OMAP_WAKEUP_EN | OMAP_WAKEUP_EVENT)
+
+struct pcs_omap {
+ unsigned int irq;
+ struct device *dev;
+ struct list_head wakeirqs;
+ struct pcs_soc soc;
+ void (*reconfigure_io_chain)(void);
+ struct mutex mutex;
+};
+
+static int pcs_omap_reg_init(const struct pcs_soc *soc, struct pcs_reg *r)
+{
+ struct pcs_omap *pcso = container_of(soc, struct pcs_omap, soc);
+ struct list_head *pos;
+ struct pcs_reg *pcsoi;
+ int res = 0;
+
+ if (!(r-val OMAP_WAKEUP_EN))
+ return 0;
+
+ if (r-irq = 0)
+ return 0;
+
+ mutex_lock(pcso-mutex);
+ list_for_each(pos, pcso-wakeirqs) {
+ pcsoi = list_entry(pos, struct pcs_reg, node);
+ if (r-reg == pcsoi-reg) {
+ pcsoi-read = r-read;
+ pcsoi-write = r-write;
+ pcsoi-reg = r-reg;
+ pcsoi-val = r-val;
+ pcsoi-irq = r-irq;
+ pcsoi-gpio = r-gpio;
+ res++;
+ goto out;
+ }
+ }
+ pcsoi = devm_kzalloc(pcso-dev, sizeof(*r), GFP_KERNEL);
+ if (!pcsoi) {
+ mutex_unlock(pcso-mutex);
+ res = -ENOMEM;
+ goto out;
+ }
+ *pcsoi = *r;
+ list_add_tail(pcsoi-node, pcso-wakeirqs);
+
+out:
+ mutex_unlock(pcso-mutex);
+
+ if (res pcso-reconfigure_io_chain)
+ pcso-reconfigure_io_chain();
+
+ return res 0 ? 0 : res;
+}
+
+static int pcs_update_list(const struct pcs_soc *soc, struct pcs_reg *r)
+{
+ struct pcs_omap *pcso = container_of(soc, struct pcs_omap, soc);
+ struct list_head *pos;
+ int changed = 0;
+
+ if (!r-irq)
+ return 0;
+
+ mutex_lock(pcso-mutex);
+ list_for_each(pos, pcso-wakeirqs) {
+ struct pcs_reg *pcsoi;
+
+ pcsoi = list_entry(pos, struct pcs_reg, node);
+ if ((r-reg == pcsoi-reg)
+ (r-val != pcsoi-val)) {
+
Re: [PATCH 1/5] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle
Grygorii Strashko grygorii.stras...@ti.com writes: From: Kevin Hilman khil...@deeprootsystems.com Currently, runtime PM is used to keep the device enabled only during active transfers and for a configurable runtime PM autosuspend timout after an xfer. In addition to idling the device, driver's -runtime_suspend() method currently disables device interrupts when idle. However, on some SoCs (notably OMAP4+), the I2C hardware may shared with other coprocessors. This means that the MPU will still recieve interrupts if a coprocessor is using the I2C device. To avoid this, also disable interrupts at the MPU INTC when idling the device in -runtime_suspend() (and re-enable them in -runtime_resume().) This part based on an original patch from Shubhrajyoti Datta. NOTE: for proper sharing the I2C with a coprocessor, this driver still needs hwspinlock support added. More over, this patch fixes the kernel boot failure which happens when CONFIG_SENSORS_LM75=y: [2.251220] WARNING: at drivers/bus/omap_l3_noc.c:113 l3_interrupt_handler+0x140/0x184() [2.257781] L3 custom error: MASTER:MPU TARGET:L4 PER2 [2.264373] Modules linked in: [2.268463] CPU: 0 PID: 2 Comm: kthreadd Not tainted 3.10.0-rc4-00034-g042dd60-dirty #64 [2.270385] [c001a80c] (unwind_backtrace+0x0/0xf0) from [c0017238] (show_stack+0x10/0x14) [2.286102] [c0017238] (show_stack+0x10/0x14) from [c0040fd0] (warn_slowpath_common+0x4c/0x68) [2.295593] [c0040fd0] (warn_slowpath_common+0x4c/0x68) from [c0041080] (warn_slowpath_fmt+0x30/0x40) [2.299987] [c0041080] (warn_slowpath_fmt+0x30/0x40) from [c02c5ed0] (l3_interrupt_handler+0x140/0x184) [2.315582] [c02c5ed0] (l3_interrupt_handler+0x140/0x184) from [c009ffb8] (handle_irq_event_percpu+0x58/0x258) [2.323364] [c009ffb8] (handle_irq_event_percpu+0x58/0x258) from [c00a01f4] (handle_irq_event+0x3c/0x5c) [2.327819] [c00a01f4] (handle_irq_event+0x3c/0x5c) from [c00a2f7c] (handle_fasteoi_irq+0xbc/0x164) [2.337829] [c00a2f7c] (handle_fasteoi_irq+0xbc/0x164) from [c009f978] (generic_handle_irq+0x20/0x30) [2.357513] [c009f978] (generic_handle_irq+0x20/0x30) from [c0014168] (handle_IRQ+0x4c/0xac) [2.366821] [c0014168] (handle_IRQ+0x4c/0xac) from [c00085b4] (gic_handle_irq+0x28/0x5c) [2.375762] [c00085b4] (gic_handle_irq+0x28/0x5c) from [c04f08a4] (__irq_svc+0x44/0x5c) [2.379821] Exception stack(0xdb085ec0 to 0xdb085f08) [2.389953] 5ec0: 0001 0001 db07ea00 4113 db2317a8 db084000 02f1 [2.389953] 5ee0: db07ea00 c04fd990 db085f08 c009170c c04f03e8 [2.405609] 5f00: 2113 [2.408355] [c04f08a4] (__irq_svc+0x44/0x5c) from [c04f03e8] (_raw_spin_unlock_irqrestore+0x34/0x44) [2.418304] [c04f03e8] (_raw_spin_unlock_irqrestore+0x34/0x44) from [c00403c0] (do_fork+0xa4/0x2d4) [2.427795] [c00403c0] (do_fork+0xa4/0x2d4) from [c0040620] (kernel_thread+0x30/0x38) [2.437805] [c0040620] (kernel_thread+0x30/0x38) from [c0063888] (kthreadd+0xd4/0x13c) [2.448364] [c0063888] (kthreadd+0xd4/0x13c) from [c0013308] (ret_from_fork+0x14/0x2c) [2.448364] ---[ end trace da8cf92c433d1616 ]--- The root casue of crash is race between omap_i2c_runtime_suspend() and omap_i2c_isr_thread() If there's a race here, then it's not the same problem which is described above, unless the CPU2 IRQ is happening because of a shared user of I2C, in which case it doesn't need any additional explanation. CPU1: CPU2: |-omap_i2c_xfer | |- pm_runtime_put_autosuspend() | |-timeout |-omap_i2c_isr() |-return IRQ_WAKE_THREAD; |-omap_i2c_runtime_suspend() | |-omap_i2c_isr_thread() |- oops is here - I2C module is in idle state If this is happening, I don't think it's related to $SUBJECT patch (but is probably hidden by it.) Instead, what probably needs to happen in this is case is that omap_i2c_isr() should be doing a mark last busy to reset the autosuspend timeout. And, that should be done in a separate patch. Cc: Nishanth Menon n...@ti.com Signed-off-by: Kevin Hilman khil...@linaro.org Both the From: and Signed-off should be from my TI address since the work was done while I was working for TI. Also, if you change the original patch/changelog, you should add a line here like: [grygorii.stras...@ti.com]: updated changlog Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap
* Tony Lindgren t...@atomide.com [130607 13:56]: Now pinctrl-single-omap can handle the wake-up events for us now as long as the events are configured in the .dts files. This patch I should queue separately, the rest should go via the pinctrl tree. 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 09/11] mmc: omap_hsmmc: enhance pinctrl support
* Balaji T K balaj...@ti.com [130607 06:42]: On Tuesday 04 June 2013 08:16 PM, Tony Lindgren wrote: * Hebbar Gururaja gururaja.heb...@ti.com [130531 03:19]: Amend the hsmmc controller to optionally take a pin control handle and set the state of the pins to: - default on boot, resume and before performing a mmc transfer - idle after initial default, after resume default, and after each mmc/sd card access - sleep on suspend() By optionally putting the pins into sleep state in the suspend callback we can accomplish two things. - One is to minimize current leakage from pins and thus save power, - second, we can prevent the IP from driving pins output in an uncontrolled manner, which may happen if the power domain drops the domain regulator. If any of the above pin states are missing in dt, a warning message about the missing state is displayed. If certain pin-states are not available, to remove this warning message pass respective state name with null phandler. There's a similar patch in the [RESEND PATCH v2 1/3] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode thread. It also makes the SDIO interrupts to work, so we need to consider that too. Hi Tony, I will try to combine both of these and make use of pinctrl_pm_select_[*]_state helper functions. OK thanks, I'll separate out the pinctrl parts from Andreas' patch and repost. 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] i2c: Let users disable Probe an I2C bus for certain devices
That sounds good to me - I can prepare patch for i2c-omap.c. But, there is still an open question regarding *i2c-gpio.c* which, actually, a source of biggest part of delay. Why should the DEPRECATED flag not work with i2c-gpio? signature.asc Description: Digital signature
