Re: [PATCH 08/21] OMAPDSS: clean up the omapdss platform data mess
On Wed, 2012-03-07 at 23:41 +0530, Archit Taneja wrote:
On Wednesday 07 March 2012 06:14 PM, Tomi Valkeinen wrote:
The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:
- Remove struct omap_display_platform_data. It was used just as a
wrapper for struct omap_dss_board_info.
- Pass the platform data only to omapdss device. The drivers for omap
dss hwmods do not need the platform data. This should also work better
for DT, as we can create omapdss device programmatically in generic omap
boot code, and thus we can pass the pdata to it.
- Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
that the dss hwmod drivers can call.
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 37
++---
drivers/video/omap2/dss/core.c | 35 +++
drivers/video/omap2/dss/dispc.c | 21 ++---
drivers/video/omap2/dss/dsi.c | 17 +++--
drivers/video/omap2/dss/dss.h |3 +++
drivers/video/omap2/dss/hdmi.c |2 --
include/video/omapdss.h |5 -
7 files changed, 61 insertions(+), 59 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 3677b1f..279c124 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -185,10 +185,23 @@ int __init omap_display_init(struct
omap_dss_board_info *board_data)
struct omap_hwmod *oh;
struct platform_device *pdev;
int i, oh_count;
- struct omap_display_platform_data pdata;
const struct omap_dss_hwmod_data *curr_dss_hwmod;
- memset(pdata, 0, sizeof(pdata));
+ /* create omapdss device */
+
+ board_data-dsi_enable_pads = omap_dsi_enable_pads;
+ board_data-dsi_disable_pads = omap_dsi_disable_pads;
+ board_data-get_context_loss_count = omap_pm_get_dev_context_loss_count;
Why are the checks for board data being NULL removed here?
We didn't check if board_data is NULL in the earlier version either. And
I don't think there's need to check that, because if the board file
calls this function, it should also give the board data.
However, the earlier version didn't set the func pointers if the func
pointer in the board_data was != NULL. Did you mean that? I removed that
check, as I don't see a need for it. The func pointers should be set by
this function, and I don't see why the board file would need to use its
own versions.
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 8613f86..3efd473 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -87,6 +87,41 @@ struct regulator *dss_get_vdds_sdi(void)
return reg;
}
+int dss_get_ctx_loss_count(struct device *dev)
+{
+ struct omap_dss_board_info *board_data = core.pdev-dev.platform_data;
+ int cnt;
+
+ if (!board_data || !board_data-get_context_loss_count)
+ return -ENOENT;
why do we check board_data being NULL here and not in omap_display_init()?
I added it for DT case, because then we don't have board_data for the
devices defined in the DT data. However, for now we always have the
board_data, and in this patch I should just move the code. So I'll
remove the check, and add it later with DT code if needed.
(and actually, I don' think the check is needed in DT case either...)
Tomi
signature.asc
Description: This is a digitally signed message part
Re: Incorrect Register Offsets in OMAP Mailbox
Sorry about that. Kind of new at this. -H Signed-off-by: Henry Chan enli.c...@gmail.com On 03/05/12 11:34, Tony Lindgren wrote: Hi Henry, * Henry Chan enli.c...@gmail.com [120207 09:25]: Hi, Looks like the register offsets are incorrect in the OMAP mailbox code (arch/arm/mach-omap2/mailbox.c) for the OMAP4_MAILBOX_IRQ* macros. The discrepancy is with p.224 of TI document SPRUGX9 and p3891 of SWPU231K. Patch attached. My hardware hasn't come in yet, so I would appreciate it if anyone can share their experience using this code. Can you please reply with your Signed-off-by, it's missing from the patch. Thanks, Tony --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -26,9 +26,9 @@ #define MAILBOX_IRQSTATUS(u)(0x100 + 8 * (u)) #define MAILBOX_IRQENABLE(u)(0x104 + 8 * (u)) -#define OMAP4_MAILBOX_IRQSTATUS(u) (0x104 + 10 * (u)) -#define OMAP4_MAILBOX_IRQENABLE(u) (0x108 + 10 * (u)) -#define OMAP4_MAILBOX_IRQENABLE_CLR(u) (0x10c + 10 * (u)) +#define OMAP4_MAILBOX_IRQSTATUS(u) (0x104 + 0x10 * (u)) +#define OMAP4_MAILBOX_IRQENABLE(u) (0x108 + 0x10 * (u)) +#define OMAP4_MAILBOX_IRQENABLE_CLR(u) (0x10c + 0x10 * (u)) #define MAILBOX_IRQ_NEWMSG(m) (1 (2 * (m))) #define MAILBOX_IRQ_NOTFULL(m) (1 (2 * (m) + 1)) -- Henry Chan -- 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 08/21] OMAPDSS: clean up the omapdss platform data mess
On Thursday 08 March 2012 01:32 PM, Tomi Valkeinen wrote:
On Wed, 2012-03-07 at 23:41 +0530, Archit Taneja wrote:
On Wednesday 07 March 2012 06:14 PM, Tomi Valkeinen wrote:
The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:
- Remove struct omap_display_platform_data. It was used just as a
wrapper for struct omap_dss_board_info.
- Pass the platform data only to omapdss device. The drivers for omap
dss hwmods do not need the platform data. This should also work better
for DT, as we can create omapdss device programmatically in generic omap
boot code, and thus we can pass the pdata to it.
- Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
that the dss hwmod drivers can call.
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 37 ++---
drivers/video/omap2/dss/core.c | 35 +++
drivers/video/omap2/dss/dispc.c | 21 ++---
drivers/video/omap2/dss/dsi.c | 17 +++--
drivers/video/omap2/dss/dss.h |3 +++
drivers/video/omap2/dss/hdmi.c |2 --
include/video/omapdss.h |5 -
7 files changed, 61 insertions(+), 59 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 3677b1f..279c124 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -185,10 +185,23 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
struct omap_hwmod *oh;
struct platform_device *pdev;
int i, oh_count;
- struct omap_display_platform_data pdata;
const struct omap_dss_hwmod_data *curr_dss_hwmod;
- memset(pdata, 0, sizeof(pdata));
+ /* create omapdss device */
+
+ board_data-dsi_enable_pads = omap_dsi_enable_pads;
+ board_data-dsi_disable_pads = omap_dsi_disable_pads;
+ board_data-get_context_loss_count = omap_pm_get_dev_context_loss_count;
Why are the checks for board data being NULL removed here?
We didn't check if board_data is NULL in the earlier version either. And
I don't think there's need to check that, because if the board file
calls this function, it should also give the board data.
However, the earlier version didn't set the func pointers if the func
pointer in the board_data was != NULL. Did you mean that? I removed that
check, as I don't see a need for it. The func pointers should be set by
this function, and I don't see why the board file would need to use its
own versions.
Yes, I had meant the function pointers being != NULL, yes it doesn't
make sense for the board file to populate these.
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 8613f86..3efd473 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -87,6 +87,41 @@ struct regulator *dss_get_vdds_sdi(void)
return reg;
}
+int dss_get_ctx_loss_count(struct device *dev)
+{
+ struct omap_dss_board_info *board_data = core.pdev-dev.platform_data;
+ int cnt;
+
+ if (!board_data || !board_data-get_context_loss_count)
+ return -ENOENT;
why do we check board_data being NULL here and not in omap_display_init()?
I added it for DT case, because then we don't have board_data for the
devices defined in the DT data. However, for now we always have the
board_data, and in this patch I should just move the code. So I'll
remove the check, and add it later with DT code if needed.
Ok. When DT will be in use, would omap_display_init() be called or not?
(and actually, I don' think the check is needed in DT case either...)
I don't know how things would work in DT case. So I'm not sure what's
happening here.
Archit
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/21] OMAPDSS: clean up the omapdss platform data mess
On Thu, 2012-03-08 at 13:47 +0530, Archit Taneja wrote:
On Thursday 08 March 2012 01:32 PM, Tomi Valkeinen wrote:
why do we check board_data being NULL here and not in omap_display_init()?
I added it for DT case, because then we don't have board_data for the
devices defined in the DT data. However, for now we always have the
board_data, and in this patch I should just move the code. So I'll
remove the check, and add it later with DT code if needed.
Ok. When DT will be in use, would omap_display_init() be called or not?
No. Currently the board files create and fill the board_data, and then
call omap_display_init.
With DT, the DT data will contain all the dynamic, per-board
information. Something like:
dss {
dpi {
dvi {
pd-gpio = 10;
...
};
};
dsi@1 {
taal {
reset-gpio = 20;
...
};
}
...
};
The DT data will be passed individually to each dss driver (i.e. dsi
driver will get its DT node, etc.). The drivers will read the data, and
initialize themselves with that, more or less the same manner they'd do
with the board_data from board files.
However, we currently have this omapdss device, which is not a hwmod
device at all. In the long run I think the omapdss device should be
removed, but for now we need it. And device has to be created in the
arch code, the same way it's now created in omap_display_init().
So with DT we need a new func, omap_display_init_dt() or such, which
creates the omapdss device, and also creates a board_data which contains
the ctx_loss etc function pointers. But the board data won't have any
display data, those come directly from DT data.
It's a bit messy solution, but it should allow us to have both DT and
non-DT working at the same time, with quite minimal changes to the board
files.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 16/21] OMAPDSS: handle output-driver reg/unreg more dynamically
On Wednesday 07 March 2012 06:14 PM, Tomi Valkeinen wrote:
Initialize and uninitialize the output drivers by using arrays of
pointers to the init/uninit functions. This simplifies the code
slightly.
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c | 111 +---
drivers/video/omap2/dss/dss.h | 41 ---
2 files changed, 59 insertions(+), 93 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 654962a..ac4f2cb 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -503,10 +503,54 @@ static int omap_dss_bus_register(void)
}
/* INIT */
+static int (*dss_output_drv_reg_funcs[])(void) __initdata = {
+#ifdef CONFIG_OMAP2_DSS_DPI
+ dpi_init_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_SDI
+ sdi_init_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_RFBI
+ rfbi_init_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_VENC
+ venc_init_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_DSI
+ dsi_init_platform_driver,
+#endif
+#ifdef CONFIG_OMAP4_DSS_HDMI
+ hdmi_init_platform_driver,
+#endif
+};
+
+static void (*dss_output_drv_unreg_funcs[])(void) __exitdata = {
+#ifdef CONFIG_OMAP2_DSS_DPI
+ dpi_uninit_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_SDI
+ sdi_uninit_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_RFBI
+ rfbi_uninit_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_VENC
+ venc_uninit_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_DSI
+ dsi_uninit_platform_driver,
+#endif
+#ifdef CONFIG_OMAP4_DSS_HDMI
+ hdmi_uninit_platform_driver,
+#endif
+};
+
+static bool dss_output_drv_loaded[ARRAY_SIZE(dss_output_drv_reg_funcs)];
static int __init omap_dss_register_drivers(void)
{
int r;
+ int i;
r = platform_driver_probe(omap_dss_driver, omap_dss_probe);
if (r)
@@ -524,56 +568,18 @@ static int __init omap_dss_register_drivers(void)
goto err_dispc;
}
- r = dpi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize dpi platform driver\n);
- goto err_dpi;
- }
-
- r = sdi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize sdi platform driver\n);
- goto err_sdi;
- }
-
- r = rfbi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize rfbi platform driver\n);
- goto err_rfbi;
- }
-
- r = venc_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize venc platform driver\n);
- goto err_venc;
- }
-
- r = dsi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize DSI platform driver\n);
- goto err_dsi;
- }
-
- r = hdmi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize hdmi\n);
- goto err_hdmi;
+ /*
+* It's ok if the output-driver register fails. It happens, for example,
+* when there is no output-device (e.g. SDI for OMAP4).
+*/
Suppose we do a omap2plus_defconfig, CONFIG_OMAP2_DSS_SDI would be
selected, and sdi.c would be built, if we boot on OMAP4, why would a sdi
driver register cause a failure? Wouldn't the sdi driver just get
registered, and wait till eternity for the corresponding sdi platform
device to get registered?
Archit
+ for (i = 0; i ARRAY_SIZE(dss_output_drv_reg_funcs); ++i) {
+ r = dss_output_drv_reg_funcs[i]();
+ if (r == 0)
+ dss_output_drv_loaded[i] = true;
}
return 0;
-err_hdmi:
- dsi_uninit_platform_driver();
-err_dsi:
- venc_uninit_platform_driver();
-err_venc:
- rfbi_uninit_platform_driver();
-err_rfbi:
- sdi_uninit_platform_driver();
-err_sdi:
- dpi_uninit_platform_driver();
-err_dpi:
- dispc_uninit_platform_driver();
err_dispc:
dss_uninit_platform_driver();
err_dss:
@@ -584,12 +590,13 @@ err_dss:
static void __exit omap_dss_unregister_drivers(void)
{
- hdmi_uninit_platform_driver();
- dsi_uninit_platform_driver();
- venc_uninit_platform_driver();
- rfbi_uninit_platform_driver();
- sdi_uninit_platform_driver();
- dpi_uninit_platform_driver();
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(dss_output_drv_unreg_funcs); ++i) {
+ if (dss_output_drv_loaded[i])
+ dss_output_drv_unreg_funcs[i]();
+ }
+
dispc_uninit_platform_driver();
dss_uninit_platform_driver();
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 24aadde..af7bed1 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -265,14 +265,9 @@ int dss_calc_clock_div(bool is_tft, unsigned long
Re: [PATCH 16/21] OMAPDSS: handle output-driver reg/unreg more dynamically
On Thu, 2012-03-08 at 14:04 +0530, Archit Taneja wrote:
On Wednesday 07 March 2012 06:14 PM, Tomi Valkeinen wrote:
- r = hdmi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize hdmi\n);
- goto err_hdmi;
+ /*
+* It's ok if the output-driver register fails. It happens, for example,
+* when there is no output-device (e.g. SDI for OMAP4).
+*/
Suppose we do a omap2plus_defconfig, CONFIG_OMAP2_DSS_SDI would be
selected, and sdi.c would be built, if we boot on OMAP4, why would a sdi
driver register cause a failure? Wouldn't the sdi driver just get
registered, and wait till eternity for the corresponding sdi platform
device to get registered?
No. Well, yes.
Currently we use platform_driver_register() to register the drivers, and
it does just what you described. But a few patches later I change
platform_driver_register() to platform_driver_probe(), which will return
ENODEV if there are no matching devices for the driver.
I originally had the platform_driver_probe() patch before this patch,
and thus the comment above made sense. Now the patch is after this
patch, so the comment is not exactly right until the probe patch is also
applied.
The point with platform_driver_probe() is that it can be used with
non-removable devices which are created at boot time, like the DSS
components. With platform_driver_probe() the probe function is called
only at that one time, and never afterwards. So probe can be in __init
section, and thrown away after init.
One side effect of using platform_driver_probe() is that it returns
ENODEV is there are no devices. In a simple module, the error can be
then returned from module_init, thus causing the whole module to be
unloaded. Our case is a bit more complex as we have multiple drivers in
the same module.
A downside with that is that we don't really know if the ENODEV error
happened because there were no devices (which is ok), or if it came from
probe function (which is not so ok). However, I thought that it doesn't
matter if an output driver has failed. We can still continue with the
other output drivers just fine.
Actually, there is a small problem. If, for example, DSI driver fails to
load, and DPI driver tries to use DSI PLL...
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 08/21] OMAPDSS: clean up the omapdss platform data mess
On Thursday 08 March 2012 02:03 PM, Tomi Valkeinen wrote:
On Thu, 2012-03-08 at 13:47 +0530, Archit Taneja wrote:
On Thursday 08 March 2012 01:32 PM, Tomi Valkeinen wrote:
why do we check board_data being NULL here and not in omap_display_init()?
I added it for DT case, because then we don't have board_data for the
devices defined in the DT data. However, for now we always have the
board_data, and in this patch I should just move the code. So I'll
remove the check, and add it later with DT code if needed.
Ok. When DT will be in use, would omap_display_init() be called or not?
No. Currently the board files create and fill the board_data, and then
call omap_display_init.
With DT, the DT data will contain all the dynamic, per-board
information. Something like:
dss {
dpi {
dvi {
pd-gpio =10;
...
};
};
dsi@1 {
taal {
reset-gpio =20;
...
};
}
...
};
The DT data will be passed individually to each dss driver (i.e. dsi
driver will get its DT node, etc.). The drivers will read the data, and
initialize themselves with that, more or less the same manner they'd do
with the board_data from board files.
However, we currently have this omapdss device, which is not a hwmod
device at all. In the long run I think the omapdss device should be
removed, but for now we need it. And device has to be created in the
arch code, the same way it's now created in omap_display_init().
So with DT we need a new func, omap_display_init_dt() or such, which
creates the omapdss device, and also creates a board_data which contains
the ctx_loss etc function pointers. But the board data won't have any
display data, those come directly from DT data.
It's a bit messy solution, but it should allow us to have both DT and
non-DT working at the same time, with quite minimal changes to the board
files.
Okay, thanks for the clarification.
Archit
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] ARM/ASoC: OMAP McBSP: Correct CLKR/FSR source selection
Hello, Changes since v1: - Adapted to the moved mcbsp code which helped to reduce the number of patches from 5 to 3. - Clock selection related defines moved from arch to ASoC header. No change in functionality otherwise. This series fixes the CLKR/FSR mux selection (on McBSP ports with 6 pin setup). OMAP2/3 has 6 pin setup on McBSP1 port while OMAP4 has the 6 pin setup on McBSP4 port. Add support for OMAP4 CLKR/FSR source selection, and simplify the ASoC part of CLK mux configuration. This series should go via ASoC with the rest of McBSP changes. Regards, Peter --- Peter Ujfalusi (3): ARM: OMAP2+: McBSP: Correct CLKR/FSR clock source mux configuration ARM/ASoC: OMAP McBSP: Move remainig defines from arch to ASoC header ASoC: omap-mcbsp: Single function CLKR/FSR source mux configuration arch/arm/mach-omap2/mcbsp.c | 46 - arch/arm/plat-omap/include/plat/mcbsp.h | 12 sound/soc/omap/mcbsp.c | 48 ++ sound/soc/omap/mcbsp.h | 13 +++- sound/soc/omap/omap-mcbsp.c |8 ++-- 5 files changed, 81 insertions(+), 46 deletions(-) -- 1.7.8.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 v2 1/3] ARM: OMAP2+: McBSP: Correct CLKR/FSR clock source mux configuration
On OMAP2/3 McBSP1 port has 6 pin setup, while on OMAP4 the port is McBSP4.
Implement the CLKR/FSR clock mux selection for OMAP4, and make sure that
we add the correct callback for the correct port across supported OMAP
versions.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
arch/arm/mach-omap2/mcbsp.c | 46 +-
1 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 49ff5b8..ecc039e 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -34,7 +34,7 @@
#include cm2xxx_3xxx.h
#include cm-regbits-34xx.h
-/* McBSP internal signal muxing function */
+/* McBSP1 internal signal muxing function for OMAP2/3 */
static int omap2_mcbsp1_mux_rx_clk(struct device *dev, const char *signal,
const char *src)
{
@@ -65,6 +65,42 @@ static int omap2_mcbsp1_mux_rx_clk(struct device *dev, const
char *signal,
return 0;
}
+/* McBSP4 internal signal muxing function for OMAP4 */
+#define OMAP4_CONTROL_MCBSPLP_ALBCTRLRX_FSX(1 31)
+#define OMAP4_CONTROL_MCBSPLP_ALBCTRLRX_CLKX (1 30)
+static int omap4_mcbsp4_mux_rx_clk(struct device *dev, const char *signal,
+ const char *src)
+{
+ u32 v;
+
+ /*
+* In CONTROL_MCBSPLP register only bit 30 (CLKR mux), and bit 31 (FSR
+* mux) is used */
+ v = omap4_ctrl_pad_readl(OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_MCBSPLP);
+
+ if (!strcmp(signal, clkr)) {
+ if (!strcmp(src, clkr))
+ v = ~OMAP4_CONTROL_MCBSPLP_ALBCTRLRX_CLKX;
+ else if (!strcmp(src, clkx))
+ v |= OMAP4_CONTROL_MCBSPLP_ALBCTRLRX_CLKX;
+ else
+ return -EINVAL;
+ } else if (!strcmp(signal, fsr)) {
+ if (!strcmp(src, fsr))
+ v = ~OMAP4_CONTROL_MCBSPLP_ALBCTRLRX_FSX;
+ else if (!strcmp(src, fsx))
+ v |= OMAP4_CONTROL_MCBSPLP_ALBCTRLRX_FSX;
+ else
+ return -EINVAL;
+ } else {
+ return -EINVAL;
+ }
+
+ omap4_ctrl_pad_writel(v, OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_MCBSPLP);
+
+ return 0;
+}
+
/* McBSP CLKS source switching function */
static int omap2_mcbsp_set_clk_src(struct device *dev, struct clk *clk,
const char *src)
@@ -146,9 +182,15 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void
*unused)
pdata-has_ccr = true;
}
pdata-set_clk_src = omap2_mcbsp_set_clk_src;
- if (id == 1)
+
+ /* On OMAP2/3 the McBSP1 port has 6 pin configuration */
+ if (id == 1 oh-class-rev MCBSP_CONFIG_TYPE4)
pdata-mux_signal = omap2_mcbsp1_mux_rx_clk;
+ /* On OMAP4 the McBSP4 port has 6 pin configuration */
+ if (id == 4 oh-class-rev == MCBSP_CONFIG_TYPE4)
+ pdata-mux_signal = omap4_mcbsp4_mux_rx_clk;
+
if (oh-class-rev == MCBSP_CONFIG_TYPE3) {
if (id == 2)
/* The FIFO has 1024 + 256 locations */
--
1.7.8.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 v2 2/3] ARM/ASoC: OMAP McBSP: Move remainig defines from arch to ASoC header
Clock signal muxing, and functional clock related defines are only needed
in ASoC drivers.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
arch/arm/plat-omap/include/plat/mcbsp.h | 12
sound/soc/omap/mcbsp.h | 12
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index 8eb9b0e..1881412 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -31,18 +31,6 @@
#define MCBSP_CONFIG_TYPE3 0x3
#define MCBSP_CONFIG_TYPE4 0x4
-/* CLKR signal muxing options */
-#define CLKR_SRC_CLKR 0
-#define CLKR_SRC_CLKX 1
-
-/* FSR signal muxing options */
-#define FSR_SRC_FSR0
-#define FSR_SRC_FSX1
-
-/* McBSP functional clock sources */
-#define MCBSP_CLKS_PRCM_SRC0
-#define MCBSP_CLKS_PAD_SRC 1
-
/* Platform specific configuration */
struct omap_mcbsp_ops {
void (*request)(unsigned int);
diff --git a/sound/soc/omap/mcbsp.h b/sound/soc/omap/mcbsp.h
index a5518d7..acc9470 100644
--- a/sound/soc/omap/mcbsp.h
+++ b/sound/soc/omap/mcbsp.h
@@ -230,6 +230,18 @@ enum {
#define XRDYEN BIT(10)
#define XEMPTYEOFENBIT(14)
+/* CLKR signal muxing options */
+#define CLKR_SRC_CLKR 0
+#define CLKR_SRC_CLKX 1
+
+/* FSR signal muxing options */
+#define FSR_SRC_FSR0
+#define FSR_SRC_FSX1
+
+/* McBSP functional clock sources */
+#define MCBSP_CLKS_PRCM_SRC0
+#define MCBSP_CLKS_PAD_SRC 1
+
/* we don't do multichannel for now */
struct omap_mcbsp_reg_cfg {
u16 spcr2;
--
1.7.8.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 v2 3/3] ASoC: omap-mcbsp: Single function CLKR/FSR source mux configuration
Use single function for the CLKR/FSR mux configuration.
OMAP2/3 has 6 pin configuration on McBSP1 instance, while on OMAP4
McBSP4 instance have the 6 pin configuration so the omap2_mcbsp1_mux_* is
not correct name for all support OMAP versions
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
sound/soc/omap/mcbsp.c | 48 +++---
sound/soc/omap/mcbsp.h | 15 +
sound/soc/omap/omap-mcbsp.c |8 +++---
3 files changed, 32 insertions(+), 39 deletions(-)
diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c
index c3e31de..95413a1 100644
--- a/sound/soc/omap/mcbsp.c
+++ b/sound/soc/omap/mcbsp.c
@@ -687,40 +687,36 @@ int omap2_mcbsp_set_clks_src(struct omap_mcbsp *mcbsp, u8
fck_src_id)
return -EINVAL;
}
-void omap2_mcbsp1_mux_clkr_src(struct omap_mcbsp *mcbsp, u8 mux)
+int omap_mcbsp_6pin_src_mux(struct omap_mcbsp *mcbsp, u8 mux)
{
- const char *src;
-
- if (mcbsp-id != 1)
- return;
+ const char *signal, *src;
+ int ret = 0;
- if (mux == CLKR_SRC_CLKR)
+ switch (mux) {
+ case CLKR_SRC_CLKR:
+ signal = clkr;
src = clkr;
- else if (mux == CLKR_SRC_CLKX)
+ break;
+ case CLKR_SRC_CLKX:
+ signal = clkr;
src = clkx;
- else
- return;
-
- if (mcbsp-pdata-mux_signal)
- mcbsp-pdata-mux_signal(mcbsp-dev, clkr, src);
-}
-
-void omap2_mcbsp1_mux_fsr_src(struct omap_mcbsp *mcbsp, u8 mux)
-{
- const char *src;
-
- if (mcbsp-id != 1)
- return;
-
- if (mux == FSR_SRC_FSR)
+ break;
+ case FSR_SRC_FSR:
+ signal = fsr;
src = fsr;
- else if (mux == FSR_SRC_FSX)
+ break;
+ case FSR_SRC_FSX:
+ signal = fsr;
src = fsx;
- else
- return;
+ break;
+ default:
+ return -EINVAL;
+ }
if (mcbsp-pdata-mux_signal)
- mcbsp-pdata-mux_signal(mcbsp-dev, fsr, src);
+ ret = mcbsp-pdata-mux_signal(mcbsp-dev, signal, src);
+
+ return ret;
}
#define max_thres(m) (mcbsp-pdata-buffer_size)
diff --git a/sound/soc/omap/mcbsp.h b/sound/soc/omap/mcbsp.h
index acc9470..a944fcc 100644
--- a/sound/soc/omap/mcbsp.h
+++ b/sound/soc/omap/mcbsp.h
@@ -230,13 +230,11 @@ enum {
#define XRDYEN BIT(10)
#define XEMPTYEOFENBIT(14)
-/* CLKR signal muxing options */
-#define CLKR_SRC_CLKR 0
-#define CLKR_SRC_CLKX 1
-
-/* FSR signal muxing options */
-#define FSR_SRC_FSR0
-#define FSR_SRC_FSX1
+/* Clock signal muxing options */
+#define CLKR_SRC_CLKR 0 /* CLKR signal is from the CLKR pin */
+#define CLKR_SRC_CLKX 1 /* CLKR signal is from the CLKX pin */
+#define FSR_SRC_FSR2 /* FSR signal is from the FSR pin */
+#define FSR_SRC_FSX3 /* FSR signal is from the FSX pin */
/* McBSP functional clock sources */
#define MCBSP_CLKS_PRCM_SRC0
@@ -333,8 +331,7 @@ void omap_mcbsp_stop(struct omap_mcbsp *mcbsp, int tx, int
rx);
int omap2_mcbsp_set_clks_src(struct omap_mcbsp *mcbsp, u8 fck_src_id);
/* McBSP signal muxing API */
-void omap2_mcbsp1_mux_clkr_src(struct omap_mcbsp *mcbsp, u8 mux);
-void omap2_mcbsp1_mux_fsr_src(struct omap_mcbsp *mcbsp, u8 mux);
+int omap_mcbsp_6pin_src_mux(struct omap_mcbsp *mcbsp, u8 mux);
/* Sidetone specific API */
int omap_st_set_chgain(struct omap_mcbsp *mcbsp, int channel, s16 chgain);
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 10eb645..d8409b0 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -554,22 +554,22 @@ static int omap_mcbsp_dai_set_dai_sysclk(struct
snd_soc_dai *cpu_dai,
case OMAP_MCBSP_CLKR_SRC_CLKR:
if (cpu_class_is_omap1())
break;
- omap2_mcbsp1_mux_clkr_src(mcbsp, CLKR_SRC_CLKR);
+ err = omap_mcbsp_6pin_src_mux(mcbsp, CLKR_SRC_CLKR);
break;
case OMAP_MCBSP_CLKR_SRC_CLKX:
if (cpu_class_is_omap1())
break;
- omap2_mcbsp1_mux_clkr_src(mcbsp, CLKR_SRC_CLKX);
+ err = omap_mcbsp_6pin_src_mux(mcbsp, CLKR_SRC_CLKX);
break;
case OMAP_MCBSP_FSR_SRC_FSR:
if (cpu_class_is_omap1())
break;
- omap2_mcbsp1_mux_fsr_src(mcbsp, FSR_SRC_FSR);
+ err = omap_mcbsp_6pin_src_mux(mcbsp, FSR_SRC_FSR);
break;
case OMAP_MCBSP_FSR_SRC_FSX:
if (cpu_class_is_omap1())
break;
- omap2_mcbsp1_mux_fsr_src(mcbsp, FSR_SRC_FSX);
+ err =
Re: [PATCH 16/21] OMAPDSS: handle output-driver reg/unreg more dynamically
On Thursday 08 March 2012 02:16 PM, Tomi Valkeinen wrote:
On Thu, 2012-03-08 at 14:04 +0530, Archit Taneja wrote:
On Wednesday 07 March 2012 06:14 PM, Tomi Valkeinen wrote:
- r = hdmi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize hdmi\n);
- goto err_hdmi;
+ /*
+* It's ok if the output-driver register fails. It happens, for example,
+* when there is no output-device (e.g. SDI for OMAP4).
+*/
Suppose we do a omap2plus_defconfig, CONFIG_OMAP2_DSS_SDI would be
selected, and sdi.c would be built, if we boot on OMAP4, why would a sdi
driver register cause a failure? Wouldn't the sdi driver just get
registered, and wait till eternity for the corresponding sdi platform
device to get registered?
No. Well, yes.
Currently we use platform_driver_register() to register the drivers, and
it does just what you described. But a few patches later I change
platform_driver_register() to platform_driver_probe(), which will return
ENODEV if there are no matching devices for the driver.
I originally had the platform_driver_probe() patch before this patch,
and thus the comment above made sense. Now the patch is after this
patch, so the comment is not exactly right until the probe patch is also
applied.
Oh okay. But the comment after the patch set still says It's ok if the
output-driver register fails., we could change it to It's ok if the
output-driver probe fails.
The point with platform_driver_probe() is that it can be used with
non-removable devices which are created at boot time, like the DSS
components. With platform_driver_probe() the probe function is called
only at that one time, and never afterwards. So probe can be in __init
section, and thrown away after init.
So platform_driver_probe() is like a driver_register() + probe().
Okay, in our case, all the devices are created at boot time, and if
omapdss were a module, the probes would have been thrown away after
module_init(), right?
One side effect of using platform_driver_probe() is that it returns
ENODEV is there are no devices. In a simple module, the error can be
then returned from module_init, thus causing the whole module to be
unloaded. Our case is a bit more complex as we have multiple drivers in
the same module.
A downside with that is that we don't really know if the ENODEV error
happened because there were no devices (which is ok), or if it came from
probe function (which is not so ok). However, I thought that it doesn't
matter if an output driver has failed. We can still continue with the
other output drivers just fine.
If we ensure that none of our probes return ENODEV(even though it may
make sense to return it if a func within probe fails), we could
differentiate between the 2 cases, right?
Actually, there is a small problem. If, for example, DSI driver fails to
load, and DPI driver tries to use DSI PLL...
If we could differentiate between an error occuring because the device
doesn't exist and an error occuring because the probe failed, we could
bail out if any of the probes fail, right?
Archit
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] ARM/ASoC: OMAP McBSP: Move remainig defines from arch to ASoC header
Hi Jarkko,
On 03/08/2012 11:22 AM, Peter Ujfalusi wrote:
Clock signal muxing, and functional clock related defines are only needed
in ASoC drivers.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com
I have added your ack to this patch by accident when I updated the
series. Sorry about that.
Please confirm if you are OK with this change.
Sorry again,
Péter
---
arch/arm/plat-omap/include/plat/mcbsp.h | 12
sound/soc/omap/mcbsp.h | 12
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index 8eb9b0e..1881412 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -31,18 +31,6 @@
#define MCBSP_CONFIG_TYPE3 0x3
#define MCBSP_CONFIG_TYPE4 0x4
-/* CLKR signal muxing options */
-#define CLKR_SRC_CLKR0
-#define CLKR_SRC_CLKX1
-
-/* FSR signal muxing options */
-#define FSR_SRC_FSR 0
-#define FSR_SRC_FSX 1
-
-/* McBSP functional clock sources */
-#define MCBSP_CLKS_PRCM_SRC 0
-#define MCBSP_CLKS_PAD_SRC 1
-
/* Platform specific configuration */
struct omap_mcbsp_ops {
void (*request)(unsigned int);
diff --git a/sound/soc/omap/mcbsp.h b/sound/soc/omap/mcbsp.h
index a5518d7..acc9470 100644
--- a/sound/soc/omap/mcbsp.h
+++ b/sound/soc/omap/mcbsp.h
@@ -230,6 +230,18 @@ enum {
#define XRDYEN BIT(10)
#define XEMPTYEOFEN BIT(14)
+/* CLKR signal muxing options */
+#define CLKR_SRC_CLKR0
+#define CLKR_SRC_CLKX1
+
+/* FSR signal muxing options */
+#define FSR_SRC_FSR 0
+#define FSR_SRC_FSX 1
+
+/* McBSP functional clock sources */
+#define MCBSP_CLKS_PRCM_SRC 0
+#define MCBSP_CLKS_PAD_SRC 1
+
/* we don't do multichannel for now */
struct omap_mcbsp_reg_cfg {
u16 spcr2;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/21] OMAPDSS: handle output-driver reg/unreg more dynamically
On Thu, 2012-03-08 at 14:52 +0530, Archit Taneja wrote:
On Thursday 08 March 2012 02:16 PM, Tomi Valkeinen wrote:
On Thu, 2012-03-08 at 14:04 +0530, Archit Taneja wrote:
On Wednesday 07 March 2012 06:14 PM, Tomi Valkeinen wrote:
- r = hdmi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize hdmi\n);
- goto err_hdmi;
+ /*
+ * It's ok if the output-driver register fails. It happens, for example,
+ * when there is no output-device (e.g. SDI for OMAP4).
+ */
Suppose we do a omap2plus_defconfig, CONFIG_OMAP2_DSS_SDI would be
selected, and sdi.c would be built, if we boot on OMAP4, why would a sdi
driver register cause a failure? Wouldn't the sdi driver just get
registered, and wait till eternity for the corresponding sdi platform
device to get registered?
No. Well, yes.
Currently we use platform_driver_register() to register the drivers, and
it does just what you described. But a few patches later I change
platform_driver_register() to platform_driver_probe(), which will return
ENODEV if there are no matching devices for the driver.
I originally had the platform_driver_probe() patch before this patch,
and thus the comment above made sense. Now the patch is after this
patch, so the comment is not exactly right until the probe patch is also
applied.
Oh okay. But the comment after the patch set still says It's ok if the
output-driver register fails., we could change it to It's ok if the
output-driver probe fails.
Well, I guess this goes into nitpicking area, but if there are no
devices, probe is not called at all. So I think it's the driver register
that fails in that case. If there is a device, and it is probed, and
that fails, then it's probe which fails.
The point with platform_driver_probe() is that it can be used with
non-removable devices which are created at boot time, like the DSS
components. With platform_driver_probe() the probe function is called
only at that one time, and never afterwards. So probe can be in __init
section, and thrown away after init.
So platform_driver_probe() is like a driver_register() + probe().
Yes. Well, when platform_driver_register() is called, and the devices
are already present, it will call the probe also. So in that sense they
are similar. The difference is that for platform_driver_register() the
probe pointer must be in the driver struct, and it stays there even
after init. For platform_driver_probe(), the probe pointer is given as
an argument to the function, and thus it's not stored anywhere and can
be thrown away afterwards.
Okay, in our case, all the devices are created at boot time, and if
omapdss were a module, the probes would have been thrown away after
module_init(), right?
Yes. If omapdss is a module, the functions marked with __init are
discarded after the module_init is done. If omapdss is built-in, the
__init funcs are thrown away after the kernel's init done.
One side effect of using platform_driver_probe() is that it returns
ENODEV is there are no devices. In a simple module, the error can be
then returned from module_init, thus causing the whole module to be
unloaded. Our case is a bit more complex as we have multiple drivers in
the same module.
A downside with that is that we don't really know if the ENODEV error
happened because there were no devices (which is ok), or if it came from
probe function (which is not so ok). However, I thought that it doesn't
matter if an output driver has failed. We can still continue with the
other output drivers just fine.
If we ensure that none of our probes return ENODEV(even though it may
make sense to return it if a func within probe fails), we could
differentiate between the 2 cases, right?
True, I thought about that. But we can never be sure that the functions
called by the probe (clk_get, or whatever) won't return ENODEV. Of
course, we could check what they return, and change the error to
something else, but I'm not sure if that's good either.
Actually, there is a small problem. If, for example, DSI driver fails to
load, and DPI driver tries to use DSI PLL...
If we could differentiate between an error occuring because the device
doesn't exist and an error occuring because the probe failed, we could
bail out if any of the probes fail, right?
Yes, but it feels a bit hackish to try to use the error as I pointed out
above. So I'd rather go the other way: the drivers should somehow
register the stuff they offer, so for example when the DSI1 is probed,
it should register the DSI1 PLL to dss core. And DPI would have to ask
for the DSI1 PLL from dss core.
That, of course, is not a trivial change, so for the moment this stuff
is slightly broken in error cases. Perhaps we could figure out some kind
of clean hack for that...
Alternatively, if the platform driver code was changed to tell us
clearly if it was the probe that failed or if there just weren't any
Re: [PATCH v2 2/3] ARM/ASoC: OMAP McBSP: Move remainig defines from arch to ASoC header
On 03/08/2012 11:29 AM, Peter Ujfalusi wrote: Hi Jarkko, On 03/08/2012 11:22 AM, Peter Ujfalusi wrote: Clock signal muxing, and functional clock related defines are only needed in ASoC drivers. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com I have added your ack to this patch by accident when I updated the series. Sorry about that. Please confirm if you are OK with this change. Go ahead :-) -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/21] OMAPDSS: handle output-driver reg/unreg more dynamically
On Thursday 08 March 2012 03:04 PM, Tomi Valkeinen wrote: On Thu, 2012-03-08 at 14:52 +0530, Archit Taneja wrote: On Thursday 08 March 2012 02:16 PM, Tomi Valkeinen wrote: On Thu, 2012-03-08 at 14:04 +0530, Archit Taneja wrote: snip Oh okay. But the comment after the patch set still says It's ok if the output-driver register fails., we could change it to It's ok if the output-driver probe fails. Well, I guess this goes into nitpicking area, but if there are no devices, probe is not called at all. So I think it's the driver register that fails in that case. If there is a device, and it is probed, and that fails, then it's probe which fails. Yes, that's fair enough I guess. snip If we ensure that none of our probes return ENODEV(even though it may make sense to return it if a func within probe fails), we could differentiate between the 2 cases, right? True, I thought about that. But we can never be sure that the functions called by the probe (clk_get, or whatever) won't return ENODEV. Of course, we could check what they return, and change the error to something else, but I'm not sure if that's good either. That's true. snip Alternatively, if the platform driver code was changed to tell us clearly if it was the probe that failed or if there just weren't any devices, we could also use that. Yes, I wonder how that could be done. Archit Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/15] ARM: OMAP4: hwmod data: add almost all remaining IP blocks
Hi
This series adds basic hwmods for all but one of the remaining
OMAP4 IP blocks that can be meaningfully controlled by the
kernel. (The remaining IP block is the USIM - there's a clocking
problem that requires further investigation to resolve.)
There are a few new boot-time warnings added by this series:
[0.280548] omap_hwmod: trace_clk_div_ck: missing clockdomain for
trace_clk_div_ck.
[0.302429] omap_hwmod: ddrphy_ck: missing clockdomain for ddrphy_ck.
[0.319519] omap_hwmod: sl2if: cannot be enabled for reset (3)
These messages will be resolved by subsequent patches, and, while annoying,
should not affect the operation of the system.
These patches have been boot-tested and suspend-tested on a
OMAP44xx PandaBoard.
The series is intended to apply on the
'hwmod_remove_link_arrays_cleanup_3.4' branch, posted previously.
These patches are also available via git from git://git.pwsan.com/linux-2.6
in the branch hwmod_enable_remaining_hwmods_devel_3.4.
- Paul
---
hwmod_enable_remaining_hwmods_devel_3.4
textdata bss dec hex filename
6590067 677452 5593500 12861019 c43e5b vmlinux.omap2plus_defconfig.orig
6594227 684620 5593500 12872347 c46a9b vmlinux.omap2plus_defconfig
Benoît Cousson (6):
ARM: OMAP4: hwmod data: add GPMC
ARM: OMAP4: hwmod data: add the Slimbus IP blocks
ARM: OMAP4: hwmod data: add McASP
ARM: OMAP4: hwmod data: add remaining USB-related IP blocks
ARM: OMAP4: hwmod data: add the OCP-WP IP block
ARM: OMAP4: hwmod data: add DEBUGSS skeleton
Ming Lei (1):
ARM: OMAP4: hwmod data: introduce fdif(face detect module) hwmod
Paul Walmsley (8):
ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common
ARM: OMAP4: hwmod data: add HDQ/1-wire
ARM: OMAP4: hwmod data: add EMIF1 and 2
ARM: OMAP4: hwmod data: add GPU
ARM: OMAP4: hwmod data: add some interconnect-related IP blocks
ARM: OMAP4: hwmod data: add OCM RAM IP block
ARM: OMAP4: hwmod data: add System Control Module
ARM: OMAP4: hwmod data: add PRCM and related IP blocks
arch/arm/mach-omap2/Makefile |8
arch/arm/mach-omap2/clockdomain44xx.c|6
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c | 10
arch/arm/mach-omap2/clockdomains44xx_data.c |2
arch/arm/mach-omap2/clockdomains_common_data.c | 24
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 1473 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h |1
7 files changed, 1443 insertions(+), 81 deletions(-)
create mode 100644 arch/arm/mach-omap2/clockdomains_common_data.c
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/15] ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common
The PRM and CM implicit clockdomains will soon be used by OMAP44xx.
So, make them common to OMAP2+ and modify the OMAP4 clockdomains code
so use of these clockdomains doesn't crash the system.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/Makefile |8 +--
arch/arm/mach-omap2/clockdomain44xx.c|6 ++
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c | 10 -
arch/arm/mach-omap2/clockdomains44xx_data.c |2 ++
arch/arm/mach-omap2/clockdomains_common_data.c | 24 ++
5 files changed, 37 insertions(+), 13 deletions(-)
create mode 100644 arch/arm/mach-omap2/clockdomains_common_data.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index bd76394..9b2f406 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -117,16 +117,18 @@ obj-$(CONFIG_ARCH_OMAP4) +=
$(powerdomain-common) \
powerdomains44xx_data.o
# PRCM clockdomain control
-obj-$(CONFIG_ARCH_OMAP2) += clockdomain.o \
+clockdomain-common += clockdomain.o \
+ clockdomains_common_data.o
+obj-$(CONFIG_ARCH_OMAP2) += $(clockdomain-common) \
clockdomain2xxx_3xxx.o \
clockdomains2xxx_3xxx_data.o
obj-$(CONFIG_SOC_OMAP2420) += clockdomains2420_data.o
obj-$(CONFIG_SOC_OMAP2430) += clockdomains2430_data.o
-obj-$(CONFIG_ARCH_OMAP3) += clockdomain.o \
+obj-$(CONFIG_ARCH_OMAP3) += $(clockdomain-common) \
clockdomain2xxx_3xxx.o \
clockdomains2xxx_3xxx_data.o \
clockdomains3xxx_data.o
-obj-$(CONFIG_ARCH_OMAP4) += clockdomain.o \
+obj-$(CONFIG_ARCH_OMAP4) += $(clockdomain-common) \
clockdomain44xx.o \
clockdomains44xx_data.o
diff --git a/arch/arm/mach-omap2/clockdomain44xx.c
b/arch/arm/mach-omap2/clockdomain44xx.c
index 935c7f0..4f04dd1 100644
--- a/arch/arm/mach-omap2/clockdomain44xx.c
+++ b/arch/arm/mach-omap2/clockdomain44xx.c
@@ -51,6 +51,9 @@ static int omap4_clkdm_clear_all_wkup_sleep_deps(struct
clockdomain *clkdm)
struct clkdm_dep *cd;
u32 mask = 0;
+ if (!clkdm-prcm_partition)
+ return 0;
+
for (cd = clkdm-wkdep_srcs; cd cd-clkdm_name; cd++) {
if (!cd-clkdm)
continue; /* only happens if data is erroneous */
@@ -103,6 +106,9 @@ static int omap4_clkdm_clk_disable(struct clockdomain
*clkdm)
{
bool hwsup = false;
+ if (!clkdm-prcm_partition)
+ return 0;
+
hwsup = omap4_cminst_is_clkdm_in_hwsup(clkdm-prcm_partition,
clkdm-cm_inst, clkdm-clkdm_offs);
diff --git a/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
b/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
index 0a6a048..839145e 100644
--- a/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
@@ -89,13 +89,3 @@ struct clockdomain wkup_common_clkdm = {
.pwrdm = { .name = wkup_pwrdm },
.dep_bit= OMAP_EN_WKUP_SHIFT,
};
-
-struct clockdomain prm_common_clkdm = {
- .name = prm_clkdm,
- .pwrdm = { .name = wkup_pwrdm },
-};
-
-struct clockdomain cm_common_clkdm = {
- .name = cm_clkdm,
- .pwrdm = { .name = core_pwrdm },
-};
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..dc42cd6 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -430,6 +430,8 @@ static struct clockdomain *clockdomains_omap44xx[]
__initdata = {
l4_wkup_44xx_clkdm,
emu_sys_44xx_clkdm,
l3_dma_44xx_clkdm,
+ prm_common_clkdm,
+ cm_common_clkdm,
NULL
};
diff --git a/arch/arm/mach-omap2/clockdomains_common_data.c
b/arch/arm/mach-omap2/clockdomains_common_data.c
new file mode 100644
index 000..615b1f0
--- /dev/null
+++ b/arch/arm/mach-omap2/clockdomains_common_data.c
@@ -0,0 +1,24 @@
+/*
+ * OMAP2+-common clockdomain data
+ *
+ * Copyright (C) 2008-2012 Texas Instruments, Inc.
+ * Copyright (C) 2008-2010 Nokia Corporation
+ *
+ * Paul Walmsley, Jouni Högander
+ */
+
+#include linux/kernel.h
+#include linux/io.h
+
+#include clockdomain.h
+
+/* These are implicit clockdomains - they are never defined as such in TRM */
+struct clockdomain prm_common_clkdm = {
+ .name = prm_clkdm,
+ .pwrdm = { .name = wkup_pwrdm },
+};
+
+struct
[PATCH 03/15] ARM: OMAP4: hwmod data: add HDQ/1-wire
Add the HDQ/1-wire hwmod and associated interconnect data. The
HDQ/1-wire IP block is a low-speed serial interconnect.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 61
1 files changed, 60 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7f42431..ae87401 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -264,7 +264,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* emif2
* gpmc
* gpu
- * hdq1w
* mcasp
* mpu_c0
* mpu_c1
@@ -1057,6 +1056,47 @@ static struct omap_hwmod omap44xx_gpio6_hwmod = {
};
/*
+ * 'hdq1w' class
+ * hdq / 1-wire serial interface controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_hdq1w_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0014,
+ .syss_offs = 0x0018,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SOFTRESET |
+ SYSS_HAS_RESET_STATUS),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_hdq1w_hwmod_class = {
+ .name = hdq1w,
+ .sysc = omap44xx_hdq1w_sysc,
+};
+
+/* hdq1w */
+static struct omap_hwmod_irq_info omap44xx_hdq1w_irqs[] = {
+ { .irq = 58 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod omap44xx_hdq1w_hwmod = {
+ .name = hdq1w,
+ .class = omap44xx_hdq1w_hwmod_class,
+ .clkdm_name = l4_per_clkdm,
+ .flags = HWMOD_INIT_NO_RESET, /* XXX temporary */
+ .mpu_irqs = omap44xx_hdq1w_irqs,
+ .main_clk = hdq1w_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_L4PER_HDQ1W_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_L4PER_HDQ1W_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'hsi' class
* mipi high-speed synchronous serial interface (multichannel and full-duplex
* serial if)
@@ -3672,6 +3712,24 @@ static struct omap_hwmod_ocp_if omap44xx_l4_per__gpio6 =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_addr_space omap44xx_hdq1w_addrs[] = {
+ {
+ .pa_start = 0x480b2000,
+ .pa_end = 0x480b201f,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l4_per - hdq1w */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__hdq1w = {
+ .master = omap44xx_l4_per_hwmod,
+ .slave = omap44xx_hdq1w_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_hdq1w_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space omap44xx_hsi_addrs[] = {
{
.pa_start = 0x4a058000,
@@ -4770,6 +4828,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_l4_per__gpio4,
omap44xx_l4_per__gpio5,
omap44xx_l4_per__gpio6,
+ omap44xx_l4_per__hdq1w,
omap44xx_l4_cfg__hsi,
omap44xx_l4_per__i2c1,
omap44xx_l4_per__i2c2,
--
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 02/15] ARM: OMAP4: hwmod data: introduce fdif(face detect module) hwmod
From: Ming Lei ming@canonical.com
Add hwmod data for the OMAP4 FDIF IP block.
Signed-off-by: Ming Lei ming@canonical.com
Acked-by: Benoît Cousson b-cous...@ti.com
[p...@pwsan.com: rearranged to match script output; fixed FDIF end address to
match script data; wrote trivial changelog]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 70
1 files changed, 69 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 9180714..7f42431 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -262,7 +262,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* elm
* emif1
* emif2
- * fdif
* gpmc
* gpu
* hdq1w
@@ -815,6 +814,47 @@ static struct omap_hwmod omap44xx_dss_venc_hwmod = {
};
/*
+ * 'fdif' class
+ * face detection hw accelerator module
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_fdif_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_RESET_STATUS |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_fdif_hwmod_class = {
+ .name = fdif,
+ .sysc = omap44xx_fdif_sysc,
+};
+
+/* fdif */
+static struct omap_hwmod_irq_info omap44xx_fdif_irqs[] = {
+ { .irq = 69 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod omap44xx_fdif_hwmod = {
+ .name = fdif,
+ .class = omap44xx_fdif_hwmod_class,
+ .clkdm_name = iss_clkdm,
+ .mpu_irqs = omap44xx_fdif_irqs,
+ .main_clk = fdif_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_CAM_FDIF_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_CAM_FDIF_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'gpio' class
* general purpose io module
*/
@@ -2948,6 +2988,14 @@ static struct omap_hwmod_ocp_if
omap44xx_dma_system__l3_main_2 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* fdif - l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_fdif__l3_main_2 = {
+ .master = omap44xx_fdif_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* hsi - l3_main_2 */
static struct omap_hwmod_ocp_if omap44xx_hsi__l3_main_2 = {
.master = omap44xx_hsi_hwmod,
@@ -3498,6 +3546,24 @@ static struct omap_hwmod_ocp_if
omap44xx_l4_per__dss_venc = {
.user = OCP_USER_MPU,
};
+static struct omap_hwmod_addr_space omap44xx_fdif_addrs[] = {
+ {
+ .pa_start = 0x4a10a000,
+ .pa_end = 0x4a10a1ff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l4_cfg - fdif */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__fdif = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_fdif_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_fdif_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space omap44xx_gpio1_addrs[] = {
{
.pa_start = 0x4a31,
@@ -4655,6 +4721,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_mmc2__l3_main_1,
omap44xx_mpu__l3_main_1,
omap44xx_dma_system__l3_main_2,
+ omap44xx_fdif__l3_main_2,
omap44xx_hsi__l3_main_2,
omap44xx_ipu__l3_main_2,
omap44xx_iss__l3_main_2,
@@ -4696,6 +4763,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_l4_per__dss_rfbi,
omap44xx_l3_main_2__dss_venc,
omap44xx_l4_per__dss_venc,
+ omap44xx_l4_cfg__fdif,
omap44xx_l4_wkup__gpio1,
omap44xx_l4_per__gpio2,
omap44xx_l4_per__gpio3,
--
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 04/15] ARM: OMAP4: hwmod data: add GPMC
From: Benoît Cousson b-cous...@ti.com
Add the GPMC hwmod and associated interconnect data. The GPMC is a
programmable parallel-bus memory controller.
Signed-off-by: Benoît Cousson b-cous...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 67
1 files changed, 66 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ae87401..6a7e26e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -262,7 +262,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* elm
* emif1
* emif2
- * gpmc
* gpu
* mcasp
* mpu_c0
@@ -1056,6 +1055,53 @@ static struct omap_hwmod omap44xx_gpio6_hwmod = {
};
/*
+ * 'gpmc' class
+ * general purpose memory controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_gpmc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_gpmc_hwmod_class = {
+ .name = gpmc,
+ .sysc = omap44xx_gpmc_sysc,
+};
+
+/* gpmc */
+static struct omap_hwmod_irq_info omap44xx_gpmc_irqs[] = {
+ { .irq = 20 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap44xx_gpmc_sdma_reqs[] = {
+ { .dma_req = 3 + OMAP44XX_DMA_REQ_START },
+ { .dma_req = -1 }
+};
+
+static struct omap_hwmod omap44xx_gpmc_hwmod = {
+ .name = gpmc,
+ .class = omap44xx_gpmc_hwmod_class,
+ .clkdm_name = l3_2_clkdm,
+ .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+ .mpu_irqs = omap44xx_gpmc_irqs,
+ .sdma_reqs = omap44xx_gpmc_sdma_reqs,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_L3_2_GPMC_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_L3_2_GPMC_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
+/*
* 'hdq1w' class
* hdq / 1-wire serial interface controller
*/
@@ -3712,6 +3758,24 @@ static struct omap_hwmod_ocp_if omap44xx_l4_per__gpio6 =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_addr_space omap44xx_gpmc_addrs[] = {
+ {
+ .pa_start = 0x5000,
+ .pa_end = 0x53ff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l3_main_2 - gpmc */
+static struct omap_hwmod_ocp_if omap44xx_l3_main_2__gpmc = {
+ .master = omap44xx_l3_main_2_hwmod,
+ .slave = omap44xx_gpmc_hwmod,
+ .clk= l3_div_ck,
+ .addr = omap44xx_gpmc_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space omap44xx_hdq1w_addrs[] = {
{
.pa_start = 0x480b2000,
@@ -4828,6 +4892,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_l4_per__gpio4,
omap44xx_l4_per__gpio5,
omap44xx_l4_per__gpio6,
+ omap44xx_l3_main_2__gpmc,
omap44xx_l4_per__hdq1w,
omap44xx_l4_cfg__hsi,
omap44xx_l4_per__i2c1,
--
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 05/15] ARM: OMAP4: hwmod data: add EMIF1 and 2
Add the EMIF1 and 2 hwmods and associated interconnect data. The EMIFs
are SDRAM interface IP blocks.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 98 +++-
1 files changed, 96 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6a7e26e..812c990 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -260,8 +260,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* efuse_ctrl_cust
* efuse_ctrl_std
* elm
- * emif1
- * emif2
* gpu
* mcasp
* mpu_c0
@@ -812,6 +810,64 @@ static struct omap_hwmod omap44xx_dss_venc_hwmod = {
};
/*
+ * 'emif' class
+ * external memory interface no1
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_emif_sysc = {
+ .rev_offs = 0x,
+};
+
+static struct omap_hwmod_class omap44xx_emif_hwmod_class = {
+ .name = emif,
+ .sysc = omap44xx_emif_sysc,
+};
+
+/* emif1 */
+static struct omap_hwmod_irq_info omap44xx_emif1_irqs[] = {
+ { .irq = 110 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod omap44xx_emif1_hwmod = {
+ .name = emif1,
+ .class = omap44xx_emif_hwmod_class,
+ .clkdm_name = l3_emif_clkdm,
+ .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+ .mpu_irqs = omap44xx_emif1_irqs,
+ .main_clk = ddrphy_ck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_MEMIF_EMIF_1_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_MEMIF_EMIF_1_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
+/* emif2 */
+static struct omap_hwmod_irq_info omap44xx_emif2_irqs[] = {
+ { .irq = 111 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod omap44xx_emif2_hwmod = {
+ .name = emif2,
+ .class = omap44xx_emif_hwmod_class,
+ .clkdm_name = l3_emif_clkdm,
+ .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+ .mpu_irqs = omap44xx_emif2_irqs,
+ .main_clk = ddrphy_ck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_MEMIF_EMIF_2_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_MEMIF_EMIF_2_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
+/*
* 'fdif' class
* face detection hw accelerator module
*/
@@ -3632,6 +3688,42 @@ static struct omap_hwmod_ocp_if
omap44xx_l4_per__dss_venc = {
.user = OCP_USER_MPU,
};
+static struct omap_hwmod_addr_space omap44xx_emif1_addrs[] = {
+ {
+ .pa_start = 0x4c00,
+ .pa_end = 0x4cff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* emif_fw - emif1 */
+static struct omap_hwmod_ocp_if omap44xx_emif_fw__emif1 = {
+ .master = omap44xx_emif_fw_hwmod,
+ .slave = omap44xx_emif1_hwmod,
+ .clk= l3_div_ck,
+ .addr = omap44xx_emif1_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space omap44xx_emif2_addrs[] = {
+ {
+ .pa_start = 0x4d00,
+ .pa_end = 0x4dff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* emif_fw - emif2 */
+static struct omap_hwmod_ocp_if omap44xx_emif_fw__emif2 = {
+ .master = omap44xx_emif_fw_hwmod,
+ .slave = omap44xx_emif2_hwmod,
+ .clk= l3_div_ck,
+ .addr = omap44xx_emif2_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space omap44xx_fdif_addrs[] = {
{
.pa_start = 0x4a10a000,
@@ -4885,6 +4977,8 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_l4_per__dss_rfbi,
omap44xx_l3_main_2__dss_venc,
omap44xx_l4_per__dss_venc,
+ omap44xx_emif_fw__emif1,
+ omap44xx_emif_fw__emif2,
omap44xx_l4_cfg__fdif,
omap44xx_l4_wkup__gpio1,
omap44xx_l4_per__gpio2,
--
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 15/15] ARM: OMAP4: hwmod data: add DEBUGSS skeleton
From: Benoît Cousson b-cous...@ti.com
Add a skeleton hwmod for the DEBUGSS and associated interconnect data.
This is a basic set of data that will need further additions as
further DEBUGSS information becomes available.
Signed-off-by: Benoît Cousson b-cous...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 59 +---
1 files changed, 52 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index a01d91f..2044c80 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -291,13 +291,7 @@ static struct omap_hwmod omap44xx_ocp_wp_noc_hwmod = {
* - They still need to be validated with the driver
* properly adapted to omap_hwmod / omap_device
*
- * debugss
- * efuse_ctrl_cust
- * efuse_ctrl_std
- * mpu_c0
- * mpu_c1
- * usb_phy_cm
- * usim
+ * usim
*/
/*
@@ -478,6 +472,29 @@ static struct omap_hwmod
omap44xx_ctrl_module_pad_wkup_hwmod = {
};
/*
+ * 'debugss' class
+ * debug and emulation sub system
+ */
+
+static struct omap_hwmod_class omap44xx_debugss_hwmod_class = {
+ .name = debugss,
+};
+
+/* debugss */
+static struct omap_hwmod omap44xx_debugss_hwmod = {
+ .name = debugss,
+ .class = omap44xx_debugss_hwmod_class,
+ .clkdm_name = emu_sys_clkdm,
+ .main_clk = trace_clk_div_ck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_EMU_DEBUGSS_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_EMU_DEBUGSS_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/*
* 'dma' class
* dma controller for data exchange between memory to memory (i.e. internal or
* external memory) and gp peripherals to memory or memory to gp peripherals
@@ -3709,6 +3726,14 @@ static struct omap_hwmod_ocp_if
omap44xx_c2c_target_fw__l3_main_2 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* debugss - l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_debugss__l3_main_2 = {
+ .master = omap44xx_debugss_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk= dbgclk_mux_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* dma_system - l3_main_2 */
static struct omap_hwmod_ocp_if omap44xx_dma_system__l3_main_2 = {
.master = omap44xx_dma_system_hwmod,
@@ -4065,6 +4090,24 @@ static struct omap_hwmod_ocp_if
omap44xx_l4_wkup__ctrl_module_pad_wkup = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_addr_space omap44xx_debugss_addrs[] = {
+ {
+ .pa_start = 0x5416,
+ .pa_end = 0x54167fff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l3_instr - debugss */
+static struct omap_hwmod_ocp_if omap44xx_l3_instr__debugss = {
+ .master = omap44xx_l3_instr_hwmod,
+ .slave = omap44xx_debugss_hwmod,
+ .clk= l3_div_ck,
+ .addr = omap44xx_debugss_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space omap44xx_dma_system_addrs[] = {
{
.pa_start = 0x4a056000,
@@ -5914,6 +5957,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_mmc2__l3_main_1,
omap44xx_mpu__l3_main_1,
omap44xx_c2c_target_fw__l3_main_2,
+ omap44xx_debugss__l3_main_2,
omap44xx_dma_system__l3_main_2,
omap44xx_fdif__l3_main_2,
omap44xx_gpu__l3_main_2,
@@ -5946,6 +5990,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_l4_cfg__ctrl_module_pad_core,
omap44xx_l4_wkup__ctrl_module_wkup,
omap44xx_l4_wkup__ctrl_module_pad_wkup,
+ omap44xx_l3_instr__debugss,
omap44xx_l4_cfg__dma_system,
omap44xx_l4_abe__dmic,
omap44xx_l4_abe__dmic_dma,
--
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 14/15] ARM: OMAP4: hwmod data: add PRCM and related IP blocks
Add the PRCM, CM, PRM, and related hwmod and associated interconnect
data. These IP blocks handle most of the on-chip power, reset, and clock
control.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 167 +++-
1 files changed, 162 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ccc1249..a01d91f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -291,16 +291,11 @@ static struct omap_hwmod omap44xx_ocp_wp_noc_hwmod = {
* - They still need to be validated with the driver
* properly adapted to omap_hwmod / omap_device
*
- * cm_core
- * cm_core_aon
* debugss
* efuse_ctrl_cust
* efuse_ctrl_std
* mpu_c0
* mpu_c1
- * prcm_mpu
- * prm
- * scrm
* usb_phy_cm
* usim
*/
@@ -2478,6 +2473,73 @@ static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod
= {
};
/*
+ * 'prcm' class
+ * power and reset manager (part of the prcm infrastructure) + clock manager 2
+ * + clock manager 1 (in always on power domain) + local prm in mpu
+ */
+
+static struct omap_hwmod_class omap44xx_prcm_hwmod_class = {
+ .name = prcm,
+};
+
+/* prcm_mpu */
+static struct omap_hwmod omap44xx_prcm_mpu_hwmod = {
+ .name = prcm_mpu,
+ .class = omap44xx_prcm_hwmod_class,
+ .clkdm_name = l4_wkup_clkdm,
+};
+
+/* cm_core_aon */
+static struct omap_hwmod omap44xx_cm_core_aon_hwmod = {
+ .name = cm_core_aon,
+ .class = omap44xx_prcm_hwmod_class,
+ .clkdm_name = cm_clkdm,
+};
+
+/* cm_core */
+static struct omap_hwmod omap44xx_cm_core_hwmod = {
+ .name = cm_core,
+ .class = omap44xx_prcm_hwmod_class,
+ .clkdm_name = cm_clkdm,
+};
+
+/* prm */
+static struct omap_hwmod_irq_info omap44xx_prm_irqs[] = {
+ { .irq = 11 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap44xx_prm_resets[] = {
+ { .name = rst_global_warm_sw, .rst_shift = 0 },
+ { .name = rst_global_cold_sw, .rst_shift = 1 },
+};
+
+static struct omap_hwmod omap44xx_prm_hwmod = {
+ .name = prm,
+ .class = omap44xx_prcm_hwmod_class,
+ .clkdm_name = prm_clkdm,
+ .mpu_irqs = omap44xx_prm_irqs,
+ .rst_lines = omap44xx_prm_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap44xx_prm_resets),
+};
+
+/*
+ * 'scrm' class
+ * system clock and reset manager
+ */
+
+static struct omap_hwmod_class omap44xx_scrm_hwmod_class = {
+ .name = scrm,
+};
+
+/* scrm */
+static struct omap_hwmod omap44xx_scrm_hwmod = {
+ .name = scrm,
+ .class = omap44xx_scrm_hwmod_class,
+ .clkdm_name = l4_wkup_clkdm,
+};
+
+/*
* 'sl2if' class
* shared level 2 memory interface
*/
@@ -5129,6 +5191,96 @@ static struct omap_hwmod_ocp_if
omap44xx_l4_cfg__ocp2scp_usb_phy = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_addr_space omap44xx_prcm_mpu_addrs[] = {
+ {
+ .pa_start = 0x48243000,
+ .pa_end = 0x48243fff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* mpu_private - prcm_mpu */
+static struct omap_hwmod_ocp_if omap44xx_mpu_private__prcm_mpu = {
+ .master = omap44xx_mpu_private_hwmod,
+ .slave = omap44xx_prcm_mpu_hwmod,
+ .clk= l3_div_ck,
+ .addr = omap44xx_prcm_mpu_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space omap44xx_cm_core_aon_addrs[] = {
+ {
+ .pa_start = 0x4a004000,
+ .pa_end = 0x4a004fff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l4_wkup - cm_core_aon */
+static struct omap_hwmod_ocp_if omap44xx_l4_wkup__cm_core_aon = {
+ .master = omap44xx_l4_wkup_hwmod,
+ .slave = omap44xx_cm_core_aon_hwmod,
+ .clk= l4_wkup_clk_mux_ck,
+ .addr = omap44xx_cm_core_aon_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space omap44xx_cm_core_addrs[] = {
+ {
+ .pa_start = 0x4a008000,
+ .pa_end = 0x4a009fff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l4_cfg - cm_core */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__cm_core = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_cm_core_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_cm_core_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space
[PATCH 12/15] ARM: OMAP4: hwmod data: add the OCP-WP IP block
From: Benoît Cousson b-cous...@ti.com
Add the OCP-WP hwmod and associated interconnect data. The OCP-WP,
or OCP watchpoint, can be used to collect interconnect data and
transmit it via the STM port.
Signed-off-by: Benoît Cousson b-cous...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 51 +++-
1 files changed, 50 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index f48fe77..5c89307 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -262,6 +262,28 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
};
/*
+ * 'ocp_wp_noc' class
+ * instance(s): ocp_wp_noc
+ */
+static struct omap_hwmod_class omap44xx_ocp_wp_noc_hwmod_class = {
+ .name = ocp_wp_noc,
+};
+
+/* ocp_wp_noc */
+static struct omap_hwmod omap44xx_ocp_wp_noc_hwmod = {
+ .name = ocp_wp_noc,
+ .class = omap44xx_ocp_wp_noc_hwmod_class,
+ .clkdm_name = l3_instr_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_L3INSTR_OCP_WP1_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_L3INSTR_OCP_WP1_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
+/*
* Modules omap_hwmod structures
*
* The following IPs are excluded for the moment because:
@@ -280,7 +302,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* efuse_ctrl_std
* mpu_c0
* mpu_c1
- * ocp_wp_noc
* prcm_mpu
* prm
* scrm
@@ -3494,6 +3515,14 @@ static struct omap_hwmod_ocp_if
omap44xx_l3_main_3__l3_instr = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* ocp_wp_noc - l3_instr */
+static struct omap_hwmod_ocp_if omap44xx_ocp_wp_noc__l3_instr = {
+ .master = omap44xx_ocp_wp_noc_hwmod,
+ .slave = omap44xx_l3_instr_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* dsp - l3_main_1 */
static struct omap_hwmod_ocp_if omap44xx_dsp__l3_main_1 = {
.master = omap44xx_dsp_hwmod,
@@ -3772,6 +3801,24 @@ static struct omap_hwmod_ocp_if
omap44xx_mpu__mpu_private = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_addr_space omap44xx_ocp_wp_noc_addrs[] = {
+ {
+ .pa_start = 0x4a102000,
+ .pa_end = 0x4a10207f,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l4_cfg - ocp_wp_noc */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__ocp_wp_noc = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_ocp_wp_noc_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_ocp_wp_noc_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space omap44xx_aess_addrs[] = {
{
.pa_start = 0x401f1000,
@@ -5584,6 +5631,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_l4_cfg__emif_fw,
omap44xx_iva__l3_instr,
omap44xx_l3_main_3__l3_instr,
+ omap44xx_ocp_wp_noc__l3_instr,
omap44xx_dsp__l3_main_1,
omap44xx_dss__l3_main_1,
omap44xx_l3_main_2__l3_main_1,
@@ -5615,6 +5663,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_l3_main_2__l4_per,
omap44xx_l4_cfg__l4_wkup,
omap44xx_mpu__mpu_private,
+ omap44xx_l4_cfg__ocp_wp_noc,
omap44xx_l4_abe__aess,
omap44xx_l4_abe__aess_dma,
omap44xx_l3_main_2__c2c,
--
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 13/15] ARM: OMAP4: hwmod data: add System Control Module
Add the System Control Module hwmod and associated interconnect data.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 134 +++-
1 files changed, 130 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 5c89307..ccc1249 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -293,10 +293,6 @@ static struct omap_hwmod omap44xx_ocp_wp_noc_hwmod = {
*
* cm_core
* cm_core_aon
- * ctrl_module_core
- * ctrl_module_pad_core
- * ctrl_module_pad_wkup
- * ctrl_module_wkup
* debugss
* efuse_ctrl_cust
* efuse_ctrl_std
@@ -433,6 +429,60 @@ static struct omap_hwmod omap44xx_counter_32k_hwmod = {
};
/*
+ * 'ctrl_module' class
+ * attila core control module + core pad control module + wkup pad control
+ * module + attila wkup control module
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_ctrl_module_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = SYSC_HAS_SIDLEMODE,
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_ctrl_module_hwmod_class = {
+ .name = ctrl_module,
+ .sysc = omap44xx_ctrl_module_sysc,
+};
+
+/* ctrl_module_core */
+static struct omap_hwmod_irq_info omap44xx_ctrl_module_core_irqs[] = {
+ { .irq = 8 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod omap44xx_ctrl_module_core_hwmod = {
+ .name = ctrl_module_core,
+ .class = omap44xx_ctrl_module_hwmod_class,
+ .clkdm_name = l4_cfg_clkdm,
+ .mpu_irqs = omap44xx_ctrl_module_core_irqs,
+};
+
+/* ctrl_module_pad_core */
+static struct omap_hwmod omap44xx_ctrl_module_pad_core_hwmod = {
+ .name = ctrl_module_pad_core,
+ .class = omap44xx_ctrl_module_hwmod_class,
+ .clkdm_name = l4_cfg_clkdm,
+};
+
+/* ctrl_module_wkup */
+static struct omap_hwmod omap44xx_ctrl_module_wkup_hwmod = {
+ .name = ctrl_module_wkup,
+ .class = omap44xx_ctrl_module_hwmod_class,
+ .clkdm_name = l4_wkup_clkdm,
+};
+
+/* ctrl_module_pad_wkup */
+static struct omap_hwmod omap44xx_ctrl_module_pad_wkup_hwmod = {
+ .name = ctrl_module_pad_wkup,
+ .class = omap44xx_ctrl_module_hwmod_class,
+ .clkdm_name = l4_wkup_clkdm,
+};
+
+/*
* 'dma' class
* dma controller for data exchange between memory to memory (i.e. internal or
* external memory) and gp peripherals to memory or memory to gp peripherals
@@ -3881,6 +3931,78 @@ static struct omap_hwmod_ocp_if
omap44xx_l4_wkup__counter_32k = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_addr_space omap44xx_ctrl_module_core_addrs[] = {
+ {
+ .pa_start = 0x4a002000,
+ .pa_end = 0x4a0027ff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l4_cfg - ctrl_module_core */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__ctrl_module_core = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_ctrl_module_core_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_ctrl_module_core_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space omap44xx_ctrl_module_pad_core_addrs[] = {
+ {
+ .pa_start = 0x4a10,
+ .pa_end = 0x4a1007ff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l4_cfg - ctrl_module_pad_core */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__ctrl_module_pad_core = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_ctrl_module_pad_core_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_ctrl_module_pad_core_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space omap44xx_ctrl_module_wkup_addrs[] = {
+ {
+ .pa_start = 0x4a30c000,
+ .pa_end = 0x4a30c7ff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l4_wkup - ctrl_module_wkup */
+static struct omap_hwmod_ocp_if omap44xx_l4_wkup__ctrl_module_wkup = {
+ .master = omap44xx_l4_wkup_hwmod,
+ .slave = omap44xx_ctrl_module_wkup_hwmod,
+ .clk= l4_wkup_clk_mux_ck,
+ .addr = omap44xx_ctrl_module_wkup_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space
[PATCH 10/15] ARM: OMAP4: hwmod data: add remaining USB-related IP blocks
From: Benoît Cousson b-cous...@ti.com
Add the OCP2SCP IP block and interconnect data. The OCP2SCP can be
used in conjunction with the on-chip embedded USB PHY, associated with
the OTG controller.
Add the on-chip full-speed USB host controller IP block and
interconnect data.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Benoît Cousson b-cous...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 120 +++-
1 files changed, 116 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 8d3a7c1..968feb0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -281,15 +281,11 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* mpu_c0
* mpu_c1
* ocmc_ram
- * ocp2scp_usb_phy
* ocp_wp_noc
* prcm_mpu
* prm
* scrm
- * usb_host_fs
- * usb_host_hs
* usb_phy_cm
- * usb_tll_hs
* usim
*/
@@ -2360,6 +2356,36 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
};
/*
+ * 'ocp2scp' class
+ * bridge to transform ocp interface protocol to scp (serial control port)
+ * protocol
+ */
+
+static struct omap_hwmod_class omap44xx_ocp2scp_hwmod_class = {
+ .name = ocp2scp,
+};
+
+/* ocp2scp_usb_phy */
+static struct omap_hwmod_opt_clk ocp2scp_usb_phy_opt_clks[] = {
+ { .role = phy_48m, .clk = ocp2scp_usb_phy_phy_48m },
+};
+
+static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
+ .name = ocp2scp_usb_phy,
+ .class = omap44xx_ocp2scp_hwmod_class,
+ .clkdm_name = l3_init_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
OMAP4_CM_L3INIT_USBPHYOCP2SCP_CLKCTRL_OFFSET,
+ .context_offs =
OMAP4_RM_L3INIT_USBPHYOCP2SCP_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .opt_clks = ocp2scp_usb_phy_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(ocp2scp_usb_phy_opt_clks),
+};
+
+/*
* 'sl2if' class
* shared level 2 memory interface
*/
@@ -3042,6 +3068,55 @@ static struct omap_hwmod omap44xx_uart4_hwmod = {
};
/*
+ * 'usb_host_fs' class
+ * full-speed usb host controller
+ */
+
+/* The IP is not compliant to type1 / type2 scheme */
+static struct omap_hwmod_sysc_fields omap_hwmod_sysc_type_usb_host_fs = {
+ .midle_shift= 4,
+ .sidle_shift= 2,
+ .srst_shift = 1,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_host_fs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0210,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type_usb_host_fs,
+};
+
+static struct omap_hwmod_class omap44xx_usb_host_fs_hwmod_class = {
+ .name = usb_host_fs,
+ .sysc = omap44xx_usb_host_fs_sysc,
+};
+
+/* usb_host_fs */
+static struct omap_hwmod_irq_info omap44xx_usb_host_fs_irqs[] = {
+ { .name = std, .irq = 89 + OMAP44XX_IRQ_GIC_START },
+ { .name = smi, .irq = 90 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod omap44xx_usb_host_fs_hwmod = {
+ .name = usb_host_fs,
+ .class = omap44xx_usb_host_fs_hwmod_class,
+ .clkdm_name = l3_init_clkdm,
+ .mpu_irqs = omap44xx_usb_host_fs_irqs,
+ .main_clk = usb_host_fs_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
OMAP4_CM_L3INIT_USB_HOST_FS_CLKCTRL_OFFSET,
+ .context_offs =
OMAP4_RM_L3INIT_USB_HOST_FS_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'usb_host_hs' class
* high-speed multi-port usb host controller
*/
@@ -3554,6 +3629,14 @@ static struct omap_hwmod_ocp_if
omap44xx_l4_cfg__l3_main_2 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* usb_host_fs - l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_usb_host_fs__l3_main_2 = {
+ .master = omap44xx_usb_host_fs_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* usb_host_hs - l3_main_2 */
static struct omap_hwmod_ocp_if omap44xx_usb_host_hs__l3_main_2 = {
.master = omap44xx_usb_host_hs_hwmod,
@@ -4840,6 +4923,14 @@ static struct omap_hwmod_ocp_if omap44xx_l4_per__mmc5 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_cfg - ocp2scp_usb_phy */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__ocp2scp_usb_phy = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave =
[PATCH 11/15] ARM: OMAP4: hwmod data: add OCM RAM IP block
Add the OCM RAM IP block and interconnect data. This is an oh-chip
block of SRAM connected directly to the L3 bus.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 32 +++-
1 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 968feb0..f48fe77 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -280,7 +280,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* efuse_ctrl_std
* mpu_c0
* mpu_c1
- * ocmc_ram
* ocp_wp_noc
* prcm_mpu
* prm
@@ -2356,6 +2355,28 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
};
/*
+ * 'ocmc_ram' class
+ * top-level core on-chip ram
+ */
+
+static struct omap_hwmod_class omap44xx_ocmc_ram_hwmod_class = {
+ .name = ocmc_ram,
+};
+
+/* ocmc_ram */
+static struct omap_hwmod omap44xx_ocmc_ram_hwmod = {
+ .name = ocmc_ram,
+ .class = omap44xx_ocmc_ram_hwmod_class,
+ .clkdm_name = l3_2_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_L3_2_OCMC_RAM_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_L3_2_OCMC_RAM_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/*
* 'ocp2scp' class
* bridge to transform ocp interface protocol to scp (serial control port)
* protocol
@@ -4923,6 +4944,14 @@ static struct omap_hwmod_ocp_if omap44xx_l4_per__mmc5 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l3_main_2 - ocmc_ram */
+static struct omap_hwmod_ocp_if omap44xx_l3_main_2__ocmc_ram = {
+ .master = omap44xx_l3_main_2_hwmod,
+ .slave = omap44xx_ocmc_ram_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l4_cfg - ocp2scp_usb_phy */
static struct omap_hwmod_ocp_if omap44xx_l4_cfg__ocp2scp_usb_phy = {
.master = omap44xx_l4_cfg_hwmod,
@@ -5654,6 +5683,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_l4_per__mmc3,
omap44xx_l4_per__mmc4,
omap44xx_l4_per__mmc5,
+ omap44xx_l3_main_2__ocmc_ram,
omap44xx_l4_cfg__ocp2scp_usb_phy,
omap44xx_l3_main_2__sl2if,
omap44xx_l4_abe__slimbus1,
--
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 09/15] ARM: OMAP4: hwmod data: add some interconnect-related IP blocks
Add the SL2 interface IP block and interconnect data. The SL2 is related
to the IVA-HD subsystem.
Add IP block and interconnect data for the C2C (Chip-to-chip)
interconnect. This can provide a direct system interconnect link to
other devices stacked on the OMAP package.
Add the ELM IP block and interconnect data. The ELM can be used
to locate errors in NAND flash connected to the GPMC.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 224 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1
2 files changed, 221 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 3be64f5..8d3a7c1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -50,6 +50,27 @@
*/
/*
+ * 'c2c_target_fw' class
+ * instance(s): c2c_target_fw
+ */
+static struct omap_hwmod_class omap44xx_c2c_target_fw_hwmod_class = {
+ .name = c2c_target_fw,
+};
+
+/* c2c_target_fw */
+static struct omap_hwmod omap44xx_c2c_target_fw_hwmod = {
+ .name = c2c_target_fw,
+ .class = omap44xx_c2c_target_fw_hwmod_class,
+ .clkdm_name = d2d_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_D2D_SAD2D_FW_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_D2D_SAD2D_FW_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/*
* 'dmm' class
* instance(s): dmm
*/
@@ -248,8 +269,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* - They still need to be validated with the driver
* properly adapted to omap_hwmod / omap_device
*
- * c2c
- * c2c_target_fw
* cm_core
* cm_core_aon
* ctrl_module_core
@@ -259,7 +278,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* debugss
* efuse_ctrl_cust
* efuse_ctrl_std
- * elm
* mpu_c0
* mpu_c1
* ocmc_ram
@@ -268,7 +286,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* prcm_mpu
* prm
* scrm
- * sl2if
* usb_host_fs
* usb_host_hs
* usb_phy_cm
@@ -331,6 +348,41 @@ static struct omap_hwmod omap44xx_aess_hwmod = {
};
/*
+ * 'c2c' class
+ * chip 2 chip interface used to plug the ape soc (omap) with an external modem
+ * soc
+ */
+
+static struct omap_hwmod_class omap44xx_c2c_hwmod_class = {
+ .name = c2c,
+};
+
+/* c2c */
+static struct omap_hwmod_irq_info omap44xx_c2c_irqs[] = {
+ { .irq = 88 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap44xx_c2c_sdma_reqs[] = {
+ { .dma_req = 68 + OMAP44XX_DMA_REQ_START },
+ { .dma_req = -1 }
+};
+
+static struct omap_hwmod omap44xx_c2c_hwmod = {
+ .name = c2c,
+ .class = omap44xx_c2c_hwmod_class,
+ .clkdm_name = d2d_clkdm,
+ .mpu_irqs = omap44xx_c2c_irqs,
+ .sdma_reqs = omap44xx_c2c_sdma_reqs,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_D2D_SAD2D_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_D2D_SAD2D_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/*
* 'counter' class
* 32-bit ordinary counter, clocked by the falling edge of the 32 khz clock
*/
@@ -806,6 +858,46 @@ static struct omap_hwmod omap44xx_dss_venc_hwmod = {
};
/*
+ * 'elm' class
+ * bch error location module
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_elm_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_elm_hwmod_class = {
+ .name = elm,
+ .sysc = omap44xx_elm_sysc,
+};
+
+/* elm */
+static struct omap_hwmod_irq_info omap44xx_elm_irqs[] = {
+ { .irq = 4 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod omap44xx_elm_hwmod = {
+ .name = elm,
+ .class = omap44xx_elm_hwmod_class,
+ .clkdm_name = l4_per_clkdm,
+ .mpu_irqs = omap44xx_elm_irqs,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_L4PER_ELM_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_L4PER_ELM_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/*
* 'emif' class
* external memory interface no1
*/
@@ -2268,6 +2360,29 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
};
/*
+ * 'sl2if' class
+ * shared level 2 memory interface
+ */
+
+static struct omap_hwmod_class omap44xx_sl2if_hwmod_class
[PATCH 08/15] ARM: OMAP4: hwmod data: add McASP
From: Benoît Cousson b-cous...@ti.com
Add the McASP hwmod and associated interconnect data. The McASP is a
general-purpose audio serial port.
Signed-off-by: Benoît Cousson b-cous...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 91
1 files changed, 90 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 283c5b2..3be64f5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -260,7 +260,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* efuse_ctrl_cust
* efuse_ctrl_std
* elm
- * mcasp
* mpu_c0
* mpu_c1
* ocmc_ram
@@ -1669,6 +1668,58 @@ static struct omap_hwmod omap44xx_mailbox_hwmod = {
};
/*
+ * 'mcasp' class
+ * multi-channel audio serial port controller
+ */
+
+/* The IP is not compliant to type1 / type2 scheme */
+static struct omap_hwmod_sysc_fields omap_hwmod_sysc_type_mcasp = {
+ .sidle_shift= 0,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_mcasp_sysc = {
+ .sysc_offs = 0x0004,
+ .sysc_flags = SYSC_HAS_SIDLEMODE,
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type_mcasp,
+};
+
+static struct omap_hwmod_class omap44xx_mcasp_hwmod_class = {
+ .name = mcasp,
+ .sysc = omap44xx_mcasp_sysc,
+};
+
+/* mcasp */
+static struct omap_hwmod_irq_info omap44xx_mcasp_irqs[] = {
+ { .name = arevt, .irq = 108 + OMAP44XX_IRQ_GIC_START },
+ { .name = axevt, .irq = 109 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap44xx_mcasp_sdma_reqs[] = {
+ { .name = axevt, .dma_req = 7 + OMAP44XX_DMA_REQ_START },
+ { .name = arevt, .dma_req = 10 + OMAP44XX_DMA_REQ_START },
+ { .dma_req = -1 }
+};
+
+static struct omap_hwmod omap44xx_mcasp_hwmod = {
+ .name = mcasp,
+ .class = omap44xx_mcasp_hwmod_class,
+ .clkdm_name = abe_clkdm,
+ .mpu_irqs = omap44xx_mcasp_irqs,
+ .sdma_reqs = omap44xx_mcasp_sdma_reqs,
+ .main_clk = mcasp_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM1_ABE_MCASP_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_ABE_MCASP_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'mcbsp' class
* multi channel buffered serial port controller
*/
@@ -4224,6 +4275,42 @@ static struct omap_hwmod_ocp_if omap44xx_l4_cfg__mailbox
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_addr_space omap44xx_mcasp_addrs[] = {
+ {
+ .pa_start = 0x40128000,
+ .pa_end = 0x401283ff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l4_abe - mcasp */
+static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcasp = {
+ .master = omap44xx_l4_abe_hwmod,
+ .slave = omap44xx_mcasp_hwmod,
+ .clk= ocp_abe_iclk,
+ .addr = omap44xx_mcasp_addrs,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_addr_space omap44xx_mcasp_dma_addrs[] = {
+ {
+ .pa_start = 0x49028000,
+ .pa_end = 0x490283ff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l4_abe - mcasp (dma) */
+static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcasp_dma = {
+ .master = omap44xx_l4_abe_hwmod,
+ .slave = omap44xx_mcasp_hwmod,
+ .clk= ocp_abe_iclk,
+ .addr = omap44xx_mcasp_dma_addrs,
+ .user = OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space omap44xx_mcbsp1_addrs[] = {
{
.name = mpu,
@@ -5222,6 +5309,8 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_l3_main_2__iva,
omap44xx_l4_wkup__kbd,
omap44xx_l4_cfg__mailbox,
+ omap44xx_l4_abe__mcasp,
+ omap44xx_l4_abe__mcasp_dma,
omap44xx_l4_abe__mcbsp1,
omap44xx_l4_abe__mcbsp1_dma,
omap44xx_l4_abe__mcbsp2,
--
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 07/15] ARM: OMAP4: hwmod data: add the Slimbus IP blocks
From: Benoît Cousson b-cous...@ti.com
Add the Slimbus hwmods and associated interconnect data. The Slimbus
IP blocks implement a two-wire serial interface.
Signed-off-by: Benoît Cousson b-cous...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 163
1 files changed, 161 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index adacc09..283c5b2 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -270,8 +270,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* prm
* scrm
* sl2if
- * slimbus1
- * slimbus2
* usb_host_fs
* usb_host_hs
* usb_phy_cm
@@ -2219,6 +2217,110 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
};
/*
+ * 'slimbus' class
+ * bidirectional, multi-drop, multi-channel two-line serial interface between
+ * the device and external components
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_slimbus_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_slimbus_hwmod_class = {
+ .name = slimbus,
+ .sysc = omap44xx_slimbus_sysc,
+};
+
+/* slimbus1 */
+static struct omap_hwmod_irq_info omap44xx_slimbus1_irqs[] = {
+ { .irq = 97 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap44xx_slimbus1_sdma_reqs[] = {
+ { .name = tx0, .dma_req = 84 + OMAP44XX_DMA_REQ_START },
+ { .name = tx1, .dma_req = 85 + OMAP44XX_DMA_REQ_START },
+ { .name = tx2, .dma_req = 86 + OMAP44XX_DMA_REQ_START },
+ { .name = tx3, .dma_req = 87 + OMAP44XX_DMA_REQ_START },
+ { .name = rx0, .dma_req = 88 + OMAP44XX_DMA_REQ_START },
+ { .name = rx1, .dma_req = 89 + OMAP44XX_DMA_REQ_START },
+ { .name = rx2, .dma_req = 90 + OMAP44XX_DMA_REQ_START },
+ { .name = rx3, .dma_req = 91 + OMAP44XX_DMA_REQ_START },
+ { .dma_req = -1 }
+};
+
+static struct omap_hwmod_opt_clk slimbus1_opt_clks[] = {
+ { .role = fclk_1, .clk = slimbus1_fclk_1 },
+ { .role = fclk_0, .clk = slimbus1_fclk_0 },
+ { .role = fclk_2, .clk = slimbus1_fclk_2 },
+ { .role = slimbus_clk, .clk = slimbus1_slimbus_clk },
+};
+
+static struct omap_hwmod omap44xx_slimbus1_hwmod = {
+ .name = slimbus1,
+ .class = omap44xx_slimbus_hwmod_class,
+ .clkdm_name = abe_clkdm,
+ .mpu_irqs = omap44xx_slimbus1_irqs,
+ .sdma_reqs = omap44xx_slimbus1_sdma_reqs,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM1_ABE_SLIMBUS_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_ABE_SLIMBUS_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+ .opt_clks = slimbus1_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(slimbus1_opt_clks),
+};
+
+/* slimbus2 */
+static struct omap_hwmod_irq_info omap44xx_slimbus2_irqs[] = {
+ { .irq = 98 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap44xx_slimbus2_sdma_reqs[] = {
+ { .name = tx0, .dma_req = 92 + OMAP44XX_DMA_REQ_START },
+ { .name = tx1, .dma_req = 93 + OMAP44XX_DMA_REQ_START },
+ { .name = tx2, .dma_req = 94 + OMAP44XX_DMA_REQ_START },
+ { .name = tx3, .dma_req = 95 + OMAP44XX_DMA_REQ_START },
+ { .name = rx0, .dma_req = 96 + OMAP44XX_DMA_REQ_START },
+ { .name = rx1, .dma_req = 97 + OMAP44XX_DMA_REQ_START },
+ { .name = rx2, .dma_req = 98 + OMAP44XX_DMA_REQ_START },
+ { .name = rx3, .dma_req = 99 + OMAP44XX_DMA_REQ_START },
+ { .dma_req = -1 }
+};
+
+static struct omap_hwmod_opt_clk slimbus2_opt_clks[] = {
+ { .role = fclk_1, .clk = slimbus2_fclk_1 },
+ { .role = fclk_0, .clk = slimbus2_fclk_0 },
+ { .role = slimbus_clk, .clk = slimbus2_slimbus_clk },
+};
+
+static struct omap_hwmod omap44xx_slimbus2_hwmod = {
+ .name = slimbus2,
+ .class = omap44xx_slimbus_hwmod_class,
+ .clkdm_name = l4_per_clkdm,
+ .mpu_irqs = omap44xx_slimbus2_irqs,
+ .sdma_reqs = omap44xx_slimbus2_sdma_reqs,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_L4PER_SLIMBUS2_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_L4PER_SLIMBUS2_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+ .opt_clks = slimbus2_opt_clks,
+ .opt_clks_cnt =
[PATCH 06/15] ARM: OMAP4: hwmod data: add GPU
Add the GPU hwmod and associated interconnect data. The GPU is a
graphics accelerator.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 70
1 files changed, 69 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 812c990..adacc09 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -260,7 +260,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* efuse_ctrl_cust
* efuse_ctrl_std
* elm
- * gpu
* mcasp
* mpu_c0
* mpu_c1
@@ -1158,6 +1157,47 @@ static struct omap_hwmod omap44xx_gpmc_hwmod = {
};
/*
+ * 'gpu' class
+ * 2d/3d graphics accelerator
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_gpu_sysc = {
+ .rev_offs = 0x1fc00,
+ .sysc_offs = 0x1fc10,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_gpu_hwmod_class = {
+ .name = gpu,
+ .sysc = omap44xx_gpu_sysc,
+};
+
+/* gpu */
+static struct omap_hwmod_irq_info omap44xx_gpu_irqs[] = {
+ { .irq = 21 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod omap44xx_gpu_hwmod = {
+ .name = gpu,
+ .class = omap44xx_gpu_hwmod_class,
+ .clkdm_name = l3_gfx_clkdm,
+ .mpu_irqs = omap44xx_gpu_irqs,
+ .main_clk = gpu_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_GFX_GFX_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_GFX_GFX_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'hdq1w' class
* hdq / 1-wire serial interface controller
*/
@@ -3138,6 +3178,14 @@ static struct omap_hwmod_ocp_if omap44xx_fdif__l3_main_2
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* gpu - l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_gpu__l3_main_2 = {
+ .master = omap44xx_gpu_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* hsi - l3_main_2 */
static struct omap_hwmod_ocp_if omap44xx_hsi__l3_main_2 = {
.master = omap44xx_hsi_hwmod,
@@ -3868,6 +3916,24 @@ static struct omap_hwmod_ocp_if omap44xx_l3_main_2__gpmc
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_addr_space omap44xx_gpu_addrs[] = {
+ {
+ .pa_start = 0x5600,
+ .pa_end = 0x5600,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l3_main_2 - gpu */
+static struct omap_hwmod_ocp_if omap44xx_l3_main_2__gpu = {
+ .master = omap44xx_l3_main_2_hwmod,
+ .slave = omap44xx_gpu_hwmod,
+ .clk= l3_div_ck,
+ .addr = omap44xx_gpu_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space omap44xx_hdq1w_addrs[] = {
{
.pa_start = 0x480b2000,
@@ -4936,6 +5002,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_mpu__l3_main_1,
omap44xx_dma_system__l3_main_2,
omap44xx_fdif__l3_main_2,
+ omap44xx_gpu__l3_main_2,
omap44xx_hsi__l3_main_2,
omap44xx_ipu__l3_main_2,
omap44xx_iss__l3_main_2,
@@ -4987,6 +5054,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_l4_per__gpio5,
omap44xx_l4_per__gpio6,
omap44xx_l3_main_2__gpmc,
+ omap44xx_l3_main_2__gpu,
omap44xx_l4_per__hdq1w,
omap44xx_l4_cfg__hsi,
omap44xx_l4_per__i2c1,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] ARM/ASoC: OMAP McBSP: Move remainig defines from arch to ASoC header
On Thu, Mar 08, 2012 at 11:22:16AM +0200, Peter Ujfalusi wrote: Clock signal muxing, and functional clock related defines are only needed in ASoC drivers. Acked-by: Mark Brown broon...@opensource.wolfsonmicro.com signature.asc Description: Digital signature
Re: [PATCH v2 3/3] ASoC: omap-mcbsp: Single function CLKR/FSR source mux configuration
On Thu, Mar 08, 2012 at 11:22:17AM +0200, Peter Ujfalusi wrote: Use single function for the CLKR/FSR mux configuration. OMAP2/3 has 6 pin configuration on McBSP1 instance, while on OMAP4 McBSP4 instance have the 6 pin configuration so the omap2_mcbsp1_mux_* is not correct name for all support OMAP versions Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com signature.asc Description: Digital signature
[PATCH v2] GPMC: add ECC control definitions
From: Yegor Yefremov yegorsli...@googlemail.com
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
---
v2: READ and WRITE will be configured in the same way, so change the cases
accordingly
arch/arm/mach-omap2/gpmc.c | 30 +++---
1 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 00d5108..212018d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -50,6 +50,19 @@
#define GPMC_ECC_SIZE_CONFIG 0x1fc
#define GPMC_ECC1_RESULT0x200
+/* GPMC ECC control settings */
+#define GPMC_ECC_CTRL_ECCCLEAR 0x100
+#define GPMC_ECC_CTRL_ECCDISABLE 0x000
+#define GPMC_ECC_CTRL_ECCREG1 0x001
+#define GPMC_ECC_CTRL_ECCREG2 0x002
+#define GPMC_ECC_CTRL_ECCREG3 0x003
+#define GPMC_ECC_CTRL_ECCREG4 0x004
+#define GPMC_ECC_CTRL_ECCREG5 0x005
+#define GPMC_ECC_CTRL_ECCREG6 0x006
+#define GPMC_ECC_CTRL_ECCREG7 0x007
+#define GPMC_ECC_CTRL_ECCREG8 0x008
+#define GPMC_ECC_CTRL_ECCREG9 0x009
+
#define GPMC_CS0_OFFSET0x60
#define GPMC_CS_SIZE 0x30
@@ -861,8 +874,9 @@ int gpmc_enable_hwecc(int cs, int mode, int dev_width, int
ecc_size)
gpmc_ecc_used = cs;
/* clear ecc and enable bits */
- val = ((0x00018) | 0x0001);
- gpmc_write_reg(GPMC_ECC_CONTROL, val);
+ gpmc_write_reg(GPMC_ECC_CONTROL,
+ GPMC_ECC_CTRL_ECCCLEAR |
+ GPMC_ECC_CTRL_ECCREG1);
/* program ecc and result sizes */
val = ecc_size 1) - 1) 22) | (0x000F));
@@ -870,13 +884,15 @@ int gpmc_enable_hwecc(int cs, int mode, int dev_width,
int ecc_size)
switch (mode) {
case GPMC_ECC_READ:
- gpmc_write_reg(GPMC_ECC_CONTROL, 0x101);
+ case GPMC_ECC_WRITE:
+ gpmc_write_reg(GPMC_ECC_CONTROL,
+ GPMC_ECC_CTRL_ECCCLEAR |
+ GPMC_ECC_CTRL_ECCREG1);
break;
case GPMC_ECC_READSYN:
-gpmc_write_reg(GPMC_ECC_CONTROL, 0x100);
- break;
- case GPMC_ECC_WRITE:
- gpmc_write_reg(GPMC_ECC_CONTROL, 0x101);
+ gpmc_write_reg(GPMC_ECC_CONTROL,
+ GPMC_ECC_CTRL_ECCCLEAR |
+ GPMC_ECC_CTRL_ECCDISABLE);
break;
default:
printk(KERN_INFO Error: Unrecognized Mode[%d]!\n, mode);
--
1.7.7
--
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] GPMC: add ECC control definitions
Am 06.03.2012 00:03, schrieb Tony Lindgren:
* Yegor Yefremov yegor_s...@visionsystems.de [120123 03:33]:
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
---
arch/arm/mach-omap2/gpmc.c | 30 +-
1 file changed, 25 insertions(+), 5 deletions(-)
Index: b/arch/arm/mach-omap2/gpmc.c
===
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -50,6 +50,19 @@
#define GPMC_ECC_SIZE_CONFIG0x1fc
#define GPMC_ECC1_RESULT0x200
+/* GPMC ECC control settings */
+#define GPMC_ECC_CTRL_ECCCLEAR 0x100
+#define GPMC_ECC_CTRL_ECCDISABLE0x000
+#define GPMC_ECC_CTRL_ECCREG1 0x001
+#define GPMC_ECC_CTRL_ECCREG2 0x002
+#define GPMC_ECC_CTRL_ECCREG3 0x003
+#define GPMC_ECC_CTRL_ECCREG4 0x004
+#define GPMC_ECC_CTRL_ECCREG5 0x005
+#define GPMC_ECC_CTRL_ECCREG6 0x006
+#define GPMC_ECC_CTRL_ECCREG7 0x007
+#define GPMC_ECC_CTRL_ECCREG8 0x008
+#define GPMC_ECC_CTRL_ECCREG9 0x009
+
#define GPMC_CS0_OFFSET 0x60
#define GPMC_CS_SIZE0x30
@@ -855,8 +868,9 @@
gpmc_ecc_used = cs;
/* clear ecc and enable bits */
-val = ((0x00018) | 0x0001);
-gpmc_write_reg(GPMC_ECC_CONTROL, val);
+gpmc_write_reg(GPMC_ECC_CONTROL,
+GPMC_ECC_CTRL_ECCCLEAR |
+GPMC_ECC_CTRL_ECCREG1);
/* program ecc and result sizes */
val = ecc_size 1) - 1) 22) | (0x000F));
@@ -864,13 +878,19 @@
switch (mode) {
case GPMC_ECC_READ:
-gpmc_write_reg(GPMC_ECC_CONTROL, 0x101);
+gpmc_write_reg(GPMC_ECC_CONTROL,
+GPMC_ECC_CTRL_ECCCLEAR |
+GPMC_ECC_CTRL_ECCREG1);
break;
case GPMC_ECC_READSYN:
- gpmc_write_reg(GPMC_ECC_CONTROL, 0x100);
+gpmc_write_reg(GPMC_ECC_CONTROL,
+GPMC_ECC_CTRL_ECCCLEAR |
+GPMC_ECC_CTRL_ECCDISABLE);
break;
case GPMC_ECC_WRITE:
-gpmc_write_reg(GPMC_ECC_CONTROL, 0x101);
+gpmc_write_reg(GPMC_ECC_CONTROL,
+GPMC_ECC_CTRL_ECCCLEAR |
+GPMC_ECC_CTRL_ECCREG1);
break;
default:
printk(KERN_INFO Error: Unrecognized Mode[%d]!\n, mode);
No functional changes here, right?
Can GPMC_ECC_READ and GPMC_ECC_WRITE case be combined:
switch (mode) {
case GPMC_ECC_READ:
case GPMC_ECC_WRITE:
gpmc_write_reg(GPMC_ECC_CONTROL,
GPMC_ECC_CTRL_ECCCLEAR |
GPMC_ECC_CTRL_ECCREG1);
break;
...
You are right. path v2 already sent.
Thanks for review.
Best regards,
Yegor
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAPDSS: add set_min_bus_tput pointer to omapdss's platform data
omapdss driver needs to use the omap_pm_set_min_bus_tput(), so add a new
entry for that in omapdss's platform data, and set it.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/display.c |6 ++
include/video/omapdss.h |1 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 3677b1f..a675cab 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -179,6 +179,11 @@ static void omap_dsi_disable_pads(int dsi_id, unsigned
lane_mask)
omap4_dsi_mux_pads(dsi_id, 0);
}
+static int omap_dss_set_min_bus_tput(struct device *dev, unsigned long tput)
+{
+ return omap_pm_set_min_bus_tput(dev, OCP_INITIATOR_AGENT, tput);
+}
+
int __init omap_display_init(struct omap_dss_board_info *board_data)
{
int r = 0;
@@ -209,6 +214,7 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
pdata.board_data = board_data;
pdata.board_data-get_context_loss_count =
omap_pm_get_dev_context_loss_count;
+ pdata.board_data-set_min_bus_tput = omap_dss_set_min_bus_tput;
for (i = 0; i oh_count; i++) {
oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 483f67c..7aecadb 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -309,6 +309,7 @@ struct omap_dss_board_info {
struct omap_dss_device *default_device;
int (*dsi_enable_pads)(int dsi_id, unsigned lane_mask);
void (*dsi_disable_pads)(int dsi_id, unsigned lane_mask);
+ int (*set_min_bus_tput)(struct device *dev, unsigned long r);
};
/* Init with the board info */
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAPDSS: Ensure OPP100 when DSS is operational
Most of the DSS clocks have restrictions on their frequency based on the
OPP in use. For example, maximum frequency for a clock may be 180MHz in
OPP100, but 90MHz in OPP50. This means that when a high enough pixel
clock or function clock is required, we need to use OPP100.
However, there's currently no way in the PM framework to make that kind
of request. The closest we get is to ask for very high bus throughput
from the PM framework, which should effectively force OPP100.
This patch is a simple version for handling the problem. Instead of
asking for OPP100 only when needed, this patch asks for OPP100 whenever
DSS is active. This obviously is not an optimal solution for cases with
small displays where OPP50 would work just fine. However, a proper
solution is a complex one, and this patch is a short term solution for
the problem.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
drivers/video/omap2/dss/core.c | 10 ++
drivers/video/omap2/dss/dss.c | 13 +
drivers/video/omap2/dss/dss.h |1 +
3 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 8613f86..999bcbc 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -87,6 +87,16 @@ struct regulator *dss_get_vdds_sdi(void)
return reg;
}
+int dss_set_min_bus_tput(struct device *dev, unsigned long tput)
+{
+ struct omap_dss_board_info *pdata = core.pdev-dev.platform_data;
+
+ if (pdata-set_min_bus_tput)
+ return pdata-set_min_bus_tput(dev, tput);
+ else
+ return 0;
+}
+
#if defined(CONFIG_DEBUG_FS) defined(CONFIG_OMAP2_DSS_DEBUG_SUPPORT)
static int dss_debug_show(struct seq_file *s, void *unused)
{
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 4a6b5ee..4a3eb22 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -826,11 +826,24 @@ static int omap_dsshw_remove(struct platform_device *pdev)
static int dss_runtime_suspend(struct device *dev)
{
dss_save_context();
+ dss_set_min_bus_tput(dev, 0);
return 0;
}
static int dss_runtime_resume(struct device *dev)
{
+ int r;
+ /*
+* Set an arbitrarily high tput request to ensure OPP100.
+* What we should really do is to make a request to stay in OPP100,
+* without any tput requirements, but that is not currently possible
+* via the PM layer.
+*/
+
+ r = dss_set_min_bus_tput(dev, 10);
+ if (r)
+ return r;
+
dss_restore_context();
return 0;
}
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index d4b3dff..42f8f62 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -162,6 +162,7 @@ struct platform_device;
struct bus_type *dss_get_bus(void);
struct regulator *dss_get_vdds_dsi(void);
struct regulator *dss_get_vdds_sdi(void);
+int dss_set_min_bus_tput(struct device *dev, unsigned long tput);
/* apply */
void dss_apply_init(void);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/15] ARM: OMAP4: hwmod data: add almost all remaining IP blocks
Hi Paul,
On Thursday 08 March 2012 04:21 PM, Paul Walmsley wrote:
Hi
This series adds basic hwmods for all but one of the remaining
OMAP4 IP blocks that can be meaningfully controlled by the
kernel. (The remaining IP block is the USIM - there's a clocking
problem that requires further investigation to resolve.)
There are a few new boot-time warnings added by this series:
[0.280548] omap_hwmod: trace_clk_div_ck: missing clockdomain for
trace_clk_div_ck.
[0.302429] omap_hwmod: ddrphy_ck: missing clockdomain for ddrphy_ck.
[0.319519] omap_hwmod: sl2if: cannot be enabled for reset (3)
These messages will be resolved by subsequent patches, and, while annoying,
should not affect the operation of the system.
These patches have been boot-tested and suspend-tested on a
OMAP44xx PandaBoard.
The series is intended to apply on the
'hwmod_remove_link_arrays_cleanup_3.4' branch, posted previously.
These patches are also available via git from git://git.pwsan.com/linux-2.6
in the branch hwmod_enable_remaining_hwmods_devel_3.4.
Could not find this branch on your tree. Found a
'enable_remaining_omap4_hwmods' instead, but that seems to
be an old branch.
regards,
Rajendra
- Paul
---
hwmod_enable_remaining_hwmods_devel_3.4
text data bss dec hex filename
6590067 677452 5593500 12861019 c43e5b vmlinux.omap2plus_defconfig.orig
6594227 684620 5593500 12872347 c46a9b vmlinux.omap2plus_defconfig
Benoît Cousson (6):
ARM: OMAP4: hwmod data: add GPMC
ARM: OMAP4: hwmod data: add the Slimbus IP blocks
ARM: OMAP4: hwmod data: add McASP
ARM: OMAP4: hwmod data: add remaining USB-related IP blocks
ARM: OMAP4: hwmod data: add the OCP-WP IP block
ARM: OMAP4: hwmod data: add DEBUGSS skeleton
Ming Lei (1):
ARM: OMAP4: hwmod data: introduce fdif(face detect module) hwmod
Paul Walmsley (8):
ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common
ARM: OMAP4: hwmod data: add HDQ/1-wire
ARM: OMAP4: hwmod data: add EMIF1 and 2
ARM: OMAP4: hwmod data: add GPU
ARM: OMAP4: hwmod data: add some interconnect-related IP blocks
ARM: OMAP4: hwmod data: add OCM RAM IP block
ARM: OMAP4: hwmod data: add System Control Module
ARM: OMAP4: hwmod data: add PRCM and related IP blocks
arch/arm/mach-omap2/Makefile |8
arch/arm/mach-omap2/clockdomain44xx.c|6
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c | 10
arch/arm/mach-omap2/clockdomains44xx_data.c |2
arch/arm/mach-omap2/clockdomains_common_data.c | 24
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 1473 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h |1
7 files changed, 1443 insertions(+), 81 deletions(-)
create mode 100644 arch/arm/mach-omap2/clockdomains_common_data.c
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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/6] mmc: omap_hsmmc: Clean up use/abuse of pdev-id
Hi Chris, On Wednesday 07 March 2012 08:29 PM, Chris Ball wrote: Hi Rajendra, On Wed, Mar 07 2012, Rajendra Nayak wrote: Chris, Ping. I am basing my DT support patches on top of these cleanups. Would be great if you can have a look and pull them in. Chris, just realized the last two requests from me to get this merged weren't addressed to you directly, but instead you were copied. Resending with you in 'To', hope this lands in your inbox :) Sorry for the delay, thanks for the ping; I've pushed these to mmc-next for 3.4 now. There's just one other cleanup patch here [1] to convert all pr_* prints in the driver to dev_*. Would be great if you can pick that as well. Thanks, Rajendra [1] http://marc.info/?l=linux-mmcm=132999677405098w=3 Thanks, - Chris. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: OMAP2+: PM: code consolidation for 3.4
Hi, On Thu, Feb 2, 2012 at 10:29 PM, Paul Walmsley p...@pwsan.com wrote: On Thu, 2 Feb 2012, Paul Walmsley wrote: Great. Do you know what the deal is with suspend on 34xx? I enabled ttyO2 wakeup and entered suspend, but serial traffic doesn't bring it out? Just a quick followup; Kevin tracked this down. v3.3-rc needs the MTD suspend patch that Artem posted recently to suspend correctly on OMAP35xx BeagleBoard with omap2plus_defconfig. Thanks Kevin. I can't get ttyO2 wakeup to work on my Blaze with 3.3-rc5. It works fine with 3.2. I've been trying to bisect and everything, but it's difficult. To start with, during my bisect, many patches seem to be in a state where the compilation fails (one example is 'OMAP44XX_IRQ_PRCM' undeclared). Anyway, what I found out is that after fcf6efa3 (ARM: OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn) wakeup from the console doesn't work anymore for me. Then I tried to comment out the omap_wakeupgen_init() call in gic_init_irq() and that seems to work... for a while. At least until ff819da4 (ARM: OMAP3: CPUidle: Make use of CPU PM notifiers) commenting out that line seems to work. But it doesn't work if I comment out the line with v3.3-rc5. And that's when I reckoned I've been using too much time trying to figure this one out. :) Does anyone know how to solve this? -- Cheers, Luca. -- 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
[PATCHv2 01/13] I2C : OMAP : make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME
The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume
and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME.
This patch removes the omap_i2c_unidle/idle functions and folds them
into the runtime callbacks.
This fixes the below warn when CONFIG_PM_RUNTIME is not defined
CC arch/arm/mach-omap2/board-ti8168evm.o
drivers/i2c/busses/i2c-omap.c:272: warning: 'omap_i2c_unidle' defined but not
used
drivers/i2c/busses/i2c-omap.c:293: warning: 'omap_i2c_idle' defined but not used
CC net/ipv4/ip_forward.o
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 75 +---
1 files changed, 32 insertions(+), 43 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 801df60..4f4188d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -269,47 +269,6 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
(i2c_dev-regs[reg] i2c_dev-reg_shift));
}
-static void omap_i2c_unidle(struct omap_i2c_dev *dev)
-{
- if (dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
- omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, dev-syscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
- }
-
- /*
-* Don't write to this register if the IE state is 0 as it can
-* cause deadlock.
-*/
- if (dev-iestate)
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
-}
-
-static void omap_i2c_idle(struct omap_i2c_dev *dev)
-{
- u16 iv;
-
- dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- if (dev-dtrev == OMAP_I2C_IP_VERSION_2)
- omap_i2c_write_reg(dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
- else
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
-
- if (dev-rev OMAP_I2C_OMAP1_REV_2) {
- iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
- } else {
- omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev-iestate);
-
- /* Flush posted write */
- omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
- }
-}
-
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
u16 psc = 0, scll = 0, sclh = 0, buf = 0;
@@ -1163,8 +1122,22 @@ 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);
+ u16 iv;
+
+ _dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
+ if (_dev-dtrev == OMAP_I2C_IP_VERSION_2)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
+ else
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+
+ if (_dev-rev OMAP_I2C_OMAP1_REV_2) {
+ iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
+ } else {
+ omap_i2c_write_reg(_dev, OMAP_I2C_STAT_REG, _dev-iestate);
- omap_i2c_idle(_dev);
+ /* Flush posted write */
+ omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG);
+ }
return 0;
}
@@ -1174,7 +1147,23 @@ static int omap_i2c_runtime_resume(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
- omap_i2c_unidle(_dev);
+ if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
+ omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev-scllstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev-sclhstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev-bufstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev-syscstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev-westate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ }
+
+ /*
+* Don't write to this register if the IE state is 0 as it can
+* cause deadlock.
+*/
+ if (_dev-iestate)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev-iestate);
return 0;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCHv2 03/13] I2C: OMAP: Recover from Bus Busy condition
From: Vikram Pandita vikram.pand...@ti.com
In case a peripheral is driving SDA bus low (ie. a start condition), provide
a constant clock output using the test mode of the OMAP I2C controller to
try and clear the bus. Soft reset I2C controller after attempting the bus clear
to ensure that controller is in a good state.
Based upon Vikram Pandita's patch from TI Android 3.0.
I acknowledge the contributions and suggestions of Jon and Hemant.
A couple differences from the original patch ...
1. Add a new function for bus clear
2. Ensure that the CON.I2C_EN bit is set when using the SYSTEST feature to
output a permanent clock. This bit needs to be set and typically it would
be set by the unidle function but this is not the case for all OMAP
generations.
3. Program the SYSTEST setting only the bits we care about. However, restore
SYSTEST registers to there original state as some OMAP generations do not
implement perform a soft-reset.
4. Clear the CON register after performing the bus clear, so when we call the
init function the controller is disabled and the init function will
re-enable later.
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Original patch can be found here:
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=a2ab04192ba25e60f95ba1ff3af5601a2d7b5bd1
drivers/i2c/busses/i2c-omap.c | 33 ++---
1 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a115d2c..f19bb7e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -147,16 +147,15 @@ enum {
#define OMAP_I2C_SCLH_HSSCLH 8
/* I2C System Test Register (OMAP_I2C_SYSTEST): */
-#ifdef DEBUG
#define OMAP_I2C_SYSTEST_ST_EN (1 15) /* System test enable */
#define OMAP_I2C_SYSTEST_FREE (1 14) /* Free running mode */
#define OMAP_I2C_SYSTEST_TMODE_MASK(3 12) /* Test mode select */
-#define OMAP_I2C_SYSTEST_TMODE_SHIFT (12)/* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_TEST(2 12) /* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_LOOP(3 12) /* Test mode select */
#define OMAP_I2C_SYSTEST_SCL_I (1 3)/* SCL line sense in */
#define OMAP_I2C_SYSTEST_SCL_O (1 2)/* SCL line drive out */
#define OMAP_I2C_SYSTEST_SDA_I (1 1)/* SDA line sense in */
#define OMAP_I2C_SYSTEST_SDA_O (1 0)/* SDA line drive out */
-#endif
/* OCP_SYSSTATUS bit definitions */
#define SYSS_RESETDONE_MASK(1 0)
@@ -319,6 +318,7 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
dev-westate);
}
}
+ return 0;
}
static int omap_i2c_init(struct omap_i2c_dev *dev)
@@ -471,6 +471,31 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
}
/*
+ * Bus Clear
+ */
+static int omap_i2c_bus_clear(struct omap_i2c_dev *dev)
+{
+ u16 w;
+
+ /*
+* Per the I2C specification, if we are stuck in a bus busy state
+* we can attempt a bus clear to try and recover the bus by sending
+* at least 9 clock pulses on SCL. Put the I2C in a test mode so it
+* will output a continuous clock on SCL.
+*/
+ w = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG,
+ (OMAP_I2C_SYSTEST_ST_EN | OMAP_I2C_SYSTEST_TMODE_TEST));
+ msleep(1);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, w);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_reset(dev);
+ omap_i2c_init(dev);
+ return omap_i2c_wait_for_bb(dev);
+}
+
+/*
* Low level master read/write transaction.
*/
static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
@@ -597,6 +622,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
r = omap_i2c_wait_for_bb(dev);
if (r 0)
+ r = omap_i2c_bus_clear(dev);
+ if (r 0)
goto out;
if (dev-set_mpu_wkup_lat != NULL)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 02/13] OMAP : I2C : Remove reset at init
The reset in the driver at init is not needed anymore as the
following patch has removed the HWMOD_INIT_NO_RESET flag.
6d3c55f [OMAP: hwmod: fix the i2c-reset timeout during bootup]
This patch does the following
-removes the reset from the probe and implements a omap_i2c_reset
function to reset.
- Reset is removed from omap_i2c_init, which was called
not only during probe, but also after time out and error handling.
omap_i2c_reset is added in those places to effect the reset.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 4f4188d..a115d2c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -269,15 +269,9 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
(i2c_dev-regs[reg] i2c_dev-reg_shift));
}
-static int omap_i2c_init(struct omap_i2c_dev *dev)
+static int omap_i2c_reset(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0, buf = 0;
- u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
- unsigned long fclk_rate = 1200;
unsigned long timeout;
- unsigned long internal_clk = 0;
- struct clk *fclk;
-
if (dev-rev = OMAP_I2C_OMAP1_REV_2) {
/* Disable I2C controller before soft reset */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
@@ -325,6 +319,16 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
dev-westate);
}
}
+}
+
+static int omap_i2c_init(struct omap_i2c_dev *dev)
+{
+ u16 psc = 0, scll = 0, sclh = 0, buf = 0;
+ u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
+ unsigned long fclk_rate = 1200;
+ unsigned long internal_clk = 0;
+ struct clk *fclk;
+
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
if (dev-flags OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
@@ -549,6 +553,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (r == 0) {
dev_err(dev-dev, controller timed out\n);
omap_i2c_init(dev);
+ omap_i2c_reset(dev);
return -ETIMEDOUT;
}
@@ -559,6 +564,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (dev-cmd_err (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
OMAP_I2C_STAT_XUDF)) {
omap_i2c_init(dev);
+ omap_i2c_reset(dev);
return -EIO;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 04/13] OMAP: I2C: I2C register restore only if context is lost
Currently i2c register restore is done always.
Adding conditional restore.
The i2c register restore is done only if the context is lost.
Also remove the definition of SYSS_RESETDONE_MASK and use the
one in omap_hwmod.h.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/plat-omap/i2c.c |3 +++
drivers/i2c/busses/i2c-omap.c | 40
include/linux/i2c-omap.h |1 +
3 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index db071bc..4ccab07 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -179,6 +179,9 @@ static inline int omap2_i2c_add_bus(int bus_id)
*/
if (cpu_is_omap34xx())
pdata-set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat;
+
+ pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count;
+
pdev = omap_device_build(name, bus_id, oh, pdata,
sizeof(struct omap_i2c_bus_platform_data),
NULL, 0, 0);
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f19bb7e..ceb09c7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -43,6 +43,7 @@
#include linux/slab.h
#include linux/i2c-omap.h
#include linux/pm_runtime.h
+#include plat/omap_device.h
/* I2C controller revisions */
#define OMAP_I2C_OMAP1_REV_2 0x20
@@ -157,9 +158,6 @@ enum {
#define OMAP_I2C_SYSTEST_SDA_I (1 1)/* SDA line sense in */
#define OMAP_I2C_SYSTEST_SDA_O (1 0)/* SDA line drive out */
-/* OCP_SYSSTATUS bit definitions */
-#define SYSS_RESETDONE_MASK(1 0)
-
/* OCP_SYSCONFIG bit definitions */
#define SYSC_CLOCKACTIVITY_MASK(0x3 8)
#define SYSC_SIDLEMODE_MASK(0x3 3)
@@ -184,6 +182,7 @@ struct omap_i2c_dev {
u32 latency;/* maximum mpu wkup latency */
void(*set_mpu_wkup_lat)(struct device *dev,
long latency);
+ int (*get_context_loss_count)(struct device *dev);
u32 speed; /* Speed of bus in kHz */
u32 dtrev; /* extra revision from DT */
u32 flags;
@@ -206,6 +205,7 @@ struct omap_i2c_dev {
u16 syscstate;
u16 westate;
u16 errata;
+ int dev_lost_count;
};
static const u8 reg_map_ip_v1[] = {
@@ -1025,6 +1025,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-speed = pdata-clkrate;
dev-flags = pdata-flags;
dev-set_mpu_wkup_lat = pdata-set_mpu_wkup_lat;
+ dev-get_context_loss_count = pdata-get_context_loss_count;
dev-dtrev = pdata-rev;
}
@@ -1151,12 +1152,25 @@ omap_i2c_remove(struct platform_device *pdev)
}
#ifdef CONFIG_PM_RUNTIME
+static void omap_i2c_restore(struct omap_i2c_dev *dev)
+{
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+}
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);
u16 iv;
+ if (_dev-get_context_loss_count)
+ _dev-dev_lost_count = _dev-get_context_loss_count(dev);
+
_dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
if (_dev-dtrev == OMAP_I2C_IP_VERSION_2)
omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
@@ -1179,18 +1193,20 @@ static int omap_i2c_runtime_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+ int loss_cnt;
+
+ if (_dev-get_context_loss_count) {
+ loss_cnt = _dev-get_context_loss_count(dev);
+ if (loss_cnt 0)
+ return loss_cnt;
- if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev-scllstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev-sclhstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev-bufstate);
-
[PATCHv2 08/13] OMAP: I2C: Fix the error handling
Currently in probe
pm_runtime_put(dev-dev);
...
/* i2c device drivers may be active on return from add_adapter() */
adap-nr = pdev-id;
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev-dev, failure adding adapter\n);
goto err_free_irq;
}
...
return 0;
err_free_irq:
free_irq(dev-irq, dev);
err_unuse_clocks:
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(dev-dev);
This may access the i2c registers without the clocks.
Attempting to fix the same by moving the pm_rintime_put after the error check.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index dd4e296..e12144e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1095,8 +1095,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev_info(dev-dev, bus %d rev%d.%d.%d at %d kHz\n, pdev-id,
dev-dtrev, dev-rev 4, dev-rev 0xf, dev-speed);
- pm_runtime_put(dev-dev);
-
adap = dev-adapter;
i2c_set_adapdata(adap, dev);
adap-owner = THIS_MODULE;
@@ -1116,6 +1114,8 @@ omap_i2c_probe(struct platform_device *pdev)
of_i2c_register_devices(adap);
+ pm_runtime_put(dev-dev);
+
return 0;
err_free_irq:
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 12/13] I2C : OMAP : Fix the crash in i2c remove
In omap_i2c_remove we are accessing the I2C_CON register without enabling the clocks. Fix the same by enabling the clocks and disabling it. This fixes the following crash. [ 154.723022] [ cut here ] [ 154.725677] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:112 l3_interrupt_handler+0x1b4/0x1c4() [ 154.725677] L3 custom error: MASTER:MPU TARGET:L4 PER2 [ 154.742614] Modules linked in: i2c_omap(-) [ 154.746948] Backtrace: [ 154.746948] [c0013078] (dump_backtrace+0x0/0x110) from [c026c158] (dump_stack+0x18/0x1c) [ 154.752716] r6:0070 r5:c002c43c r4:df9b9e98 r3:df9b8000 [ 154.764465] [c026c140] (dump_stack+0x0/0x1c) from [c0041a2c] (warn_slowpath_common+0x5c/0x6c) [ 154.768341] [c00419d0] (warn_slowpath_common+0x0/0x6c) from [c0041ae0] (warn_slowpath_fmt+0x38/0x40) [ 154.776153] r8:0180 r7:c0361594 r6:c0379b48 r5:00080003 r4:e0838b00 [ 154.790771] r3:0009 [ 154.791778] [c0041aa8] (warn_slowpath_fmt+0x0/0x40) from [c002c43c] (l3_interrupt_handler+0x1b4/0x1c4) [ 154.803710] r3:c0361598 r2:c02ef74c [ 154.807403] [c002c288] (l3_interrupt_handler+0x0/0x1c4) from [c0085f44] (handle_irq_event_percpu+0x58/0 [ 154.818237] r8:002a r7: r6: r5:df808054 r4:df8893c0 [ 154.825378] [c0085eec] (handle_irq_event_percpu+0x0/0x188) from [c00860b8] (handle_irq_event+0x44/0x64) [ 154.835662] [c0086074] (handle_irq_event+0x0/0x64) from [c0088ec0] (handle_fasteoi_irq+0xa4/0x10c) [ 154.845458] r6:002a r5:df808054 r4:df808000 r3:c034a150 [ 154.846466] [c0088e1c] (handle_fasteoi_irq+0x0/0x10c) from [c0085ed0] (generic_handle_irq+0x30/0x38) [ 154.854278] r5:c034aa48 r4:002a [ 154.862091] [c0085ea0] (generic_handle_irq+0x0/0x38) from [c000fd38] (handle_IRQ+0x60/0xc0) [ 154.874450] r4:c034ea70 r3:01f8 [ 154.878234] [c000fcd8] (handle_IRQ+0x0/0xc0) from [c0008478] (gic_handle_irq+0x20/0x5c) [ 154.887023] r7:ff40 r6:df9b9fb0 r5:c034e2b4 r4:001a [ 154.887054] [c0008458] (gic_handle_irq+0x0/0x5c) from [c000ea80] (__irq_usr+0x40/0x60) [ 154.901153] Exception stack(0xdf9b9fb0 to 0xdf9b9ff8) [ 154.907104] 9fa0: beaf1f04 4006be00 000f 000c [ 154.915710] 9fc0: 4006c000 8034 ff40 0007 0007b8d7 [ 154.916778] 9fe0: beaf1b68 d23c 4005baf0 8010 [ 154.931335] r6: r5:8010 r4:4005baf0 r3:beaf1f04 [ 154.937316] ---[ end trace 1b75b31a2719ed21 ]-- Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index f454041..47a94cf 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1134,7 +1134,9 @@ static int __devexit omap_i2c_remove(struct platform_device *pdev) free_irq(dev-irq, dev); i2c_del_adapter(dev-adapter); + pm_runtime_get_sync(pdev-dev); omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); + pm_runtime_put(pdev-dev); pm_runtime_disable(pdev-dev); return 0; } -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 07/13] OMAP: I2C: Optimise the remove code
The omap_i2c_remove function may not be needed after
device exit so the memory could be freed.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 99b14d3..dd4e296 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1134,8 +1134,7 @@ err_release_region:
return r;
}
-static int
-omap_i2c_remove(struct platform_device *pdev)
+static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
struct resource *mem;
@@ -1228,7 +1227,7 @@ static struct dev_pm_ops omap_i2c_pm_ops = {
static struct platform_driver omap_i2c_driver = {
.probe = omap_i2c_probe,
- .remove = omap_i2c_remove,
+ .remove = __devexit_p(omap_i2c_remove),
.driver = {
.name = omap_i2c,
.owner = THIS_MODULE,
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 06/13] OMAP: I2C: Fix the mismatch of pm_runtime enable and disable
Currently the i2c driver calls the pm_runtime_enable and never the disable. This may cause a warning when pm_runtime_enable checks for the count match.Attempting to fix the same by calling pm_runtime_disable in the error and the remove path. Cc: Kevin Hilman khil...@ti.com Cc: Rajendra Nayak rna...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 98720c9..99b14d3 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1124,6 +1124,7 @@ err_unuse_clocks: omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); pm_runtime_put(dev-dev); iounmap(dev-base); + pm_runtime_disable(pdev-dev); err_free_mem: platform_set_drvdata(pdev, NULL); kfree(dev); @@ -1144,6 +1145,7 @@ omap_i2c_remove(struct platform_device *pdev) free_irq(dev-irq, dev); i2c_del_adapter(dev-adapter); omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); + pm_runtime_disable(pdev-dev); iounmap(dev-base); kfree(dev); mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 11/13] OMAP : I2C : use devm_* functions
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses devm_kzalloc, devm_request_mem_region and
devm_ioremap for data that is allocated in the probe function of a platform
device and is only freed in the remove function.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 29 +
1 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 43c22a7..f454041 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -995,17 +995,17 @@ omap_i2c_probe(struct platform_device *pdev)
return -ENODEV;
}
- ioarea = request_mem_region(mem-start, resource_size(mem),
- pdev-name);
+ ioarea = devm_request_mem_region(pdev-dev, mem-start,
+ resource_size(mem), pdev-name);
if (!ioarea) {
dev_err(pdev-dev, I2C region already claimed\n);
return -EBUSY;
}
- dev = kzalloc(sizeof(struct omap_i2c_dev), GFP_KERNEL);
+ dev = devm_kzalloc(pdev-dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
if (!dev) {
- r = -ENOMEM;
- goto err_release_region;
+ dev_err(pdev-dev, Menory allocation failed\n);
+ return -ENOMEM;
}
match = of_match_device(of_match_ptr(omap_i2c_of_match), pdev-dev);
@@ -1029,11 +1029,10 @@ omap_i2c_probe(struct platform_device *pdev)
dev-dev = pdev-dev;
dev-irq = irq-start;
- dev-base = ioremap(mem-start, resource_size(mem));
- if (!dev-base) {
- r = -ENOMEM;
- goto err_free_mem;
- }
+ dev-base = devm_ioremap(pdev-dev, mem-start, resource_size(mem));
+ if (!dev-base)
+ return -ENOMEM;
+
platform_set_drvdata(pdev, dev);
@@ -1121,13 +1120,8 @@ err_free_irq:
err_unuse_clocks:
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(dev-dev);
- iounmap(dev-base);
pm_runtime_disable(pdev-dev);
-err_free_mem:
platform_set_drvdata(pdev, NULL);
- kfree(dev);
-err_release_region:
- release_mem_region(mem-start, resource_size(mem));
return r;
}
@@ -1135,7 +1129,6 @@ err_release_region:
static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
- struct resource *mem;
platform_set_drvdata(pdev, NULL);
@@ -1143,10 +1136,6 @@ static int __devexit omap_i2c_remove(struct
platform_device *pdev)
i2c_del_adapter(dev-adapter);
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_disable(pdev-dev);
- iounmap(dev-base);
- kfree(dev);
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(mem-start, resource_size(mem));
return 0;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 13/13] OMAP: I2C: Handle error check for pm runtime
If PM runtime get_sync fails return with the error
so that no further reads/writes goes through the interface.
This will avoid possible abort.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 47a94cf..293e056 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -616,7 +616,9 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
int i;
int r;
- pm_runtime_get_sync(dev-dev);
+ r = pm_runtime_get_sync(dev-dev);
+ if (r 0)
+ return r;
r = omap_i2c_wait_for_bb(dev);
if (r 0)
@@ -1044,7 +1046,9 @@ omap_i2c_probe(struct platform_device *pdev)
dev-regs = (u8 *)reg_map_ip_v1;
pm_runtime_enable(dev-dev);
- pm_runtime_get_sync(dev-dev);
+ r = pm_runtime_get_sync(dev-dev);
+ if (r 0)
+ return r;
dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff;
@@ -1129,12 +1133,15 @@ err_unuse_clocks:
static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
+ int ret;
platform_set_drvdata(pdev, NULL);
free_irq(dev-irq, dev);
i2c_del_adapter(dev-adapter);
- pm_runtime_get_sync(pdev-dev);
+ ret = pm_runtime_get_sync(pdev-dev);
+ if (ret 0)
+ return ret;
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 09/13] I2C: OMAP: Correct I2C revision for OMAP3
From: Jon Hunter jon-hun...@ti.com
The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
revision is the same for 3430 and 3530. However, the OMAP3630 device has the
same I2C revision as OMAP4. Correct the revision definition to reflect this.
This patch is based on work done by Jon Hunter jon-hun...@ti.com
Changes from his patch
- Update OMAP_I2C_REV_ON_3430 also to reflect that it is same as 3530
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e12144e..ed22e67 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -50,8 +50,8 @@
/* I2C controller revisions present on specific hardware */
#define OMAP_I2C_REV_ON_2430 0x36
-#define OMAP_I2C_REV_ON_3430 0x3C
-#define OMAP_I2C_REV_ON_3530_4430 0x40
+#define OMAP_I2C_REV_ON_3430_3530 0x3C
+#define OMAP_I2C_REV_ON_3630_4430 0x40
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -298,7 +298,7 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
SYSC_AUTOIDLE_MASK);
- } else if (dev-rev = OMAP_I2C_REV_ON_3430) {
+ } else if (dev-rev = OMAP_I2C_REV_ON_3430_3530) {
dev-syscstate = SYSC_AUTOIDLE_MASK;
dev-syscstate |= SYSC_ENAWAKEUP_MASK;
dev-syscstate |= (SYSC_IDLEMODE_SMART
@@ -1051,7 +1051,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff;
- if (dev-rev = OMAP_I2C_REV_ON_3430)
+ if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
dev-errata |= I2C_OMAP3_1P153;
if (!(dev-flags OMAP_I2C_FLAG_NO_FIFO)) {
@@ -1069,7 +1069,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-fifo_size = (dev-fifo_size / 2);
- if (dev-rev = OMAP_I2C_REV_ON_3530_4430)
+ if (dev-rev = OMAP_I2C_REV_ON_3630_4430)
dev-b_hw = 0; /* Disable hardware fixes */
else
dev-b_hw = 1; /* Enable hardware fixes */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 10/13] I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero
By definition, wait_for_completion_timeout() returns an unsigned value and
therefore, it is not necessary to check if the return value is less than zero
as this is not possible.
This is based on a patch from Jon Hunter jon-hun...@ti.com
Changes from his patch
- Declare a long as the wait_for_completion_timeout returns long.
Cc : Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Original patch is
http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=ea02cece7bbc736e60c4188a11aaa74bc6e6
drivers/i2c/busses/i2c-omap.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index ed22e67..43c22a7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -502,7 +502,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
struct i2c_msg *msg, int stop)
{
struct omap_i2c_dev *dev = i2c_get_adapdata(adap);
- int r;
+ unsigned long timeout;
u16 w;
dev_dbg(dev-dev, addr: 0x%04x, len: %d, flags: 0x%x, stop: %d\n,
@@ -570,12 +570,10 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
* REVISIT: We should abort the transfer on signals, but the bus goes
* into arbitration and we're currently unable to recover from it.
*/
- r = wait_for_completion_timeout(dev-cmd_complete,
- OMAP_I2C_TIMEOUT);
+ timeout = wait_for_completion_timeout(dev-cmd_complete,
+ OMAP_I2C_TIMEOUT);
dev-buf_len = 0;
- if (r 0)
- return r;
- if (r == 0) {
+ if (timeout == 0) {
dev_err(dev-dev, controller timed out\n);
omap_i2c_init(dev);
omap_i2c_reset(dev);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 00/13] I2C updates
The patch series does the following - Warn fixes if CONFIG_PM_RUNTIME is not selected. - I2C register restore only if context if the context is lost - Bus busy recovery mechanism. - the reset is not done in init. v2 changes -Adds a patch to use devm_* functions -Also checks the return type of the get_sync and in case of errors prevents register access. - In case of i2c remove register access was done without any get_sync fix the same. - Adds a pdata function pointer to do context save restore Tested on omap4sdp and omap3sdp. Also available through git://gitorious.org/linus-tree/linus-tree.git for_3.4_i2c_fixes Jon Hunter (1): I2C: OMAP: Correct I2C revision for OMAP3 Shubhrajyoti D (11): I2C : OMAP : make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME OMAP : I2C : Remove reset at init OMAP: I2C: I2C register restore only if context is lost OMAP: I2C: Fix the interrupt clearing in OMAP4 OMAP: I2C: Fix the mismatch of pm_runtime enable and disable OMAP: I2C: Optimise the remove code OMAP: I2C: Fix the error handling I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero OMAP : I2C : use devm_* functions I2C : OMAP : Fix the crash in i2c remove OMAP: I2C: Handle error check for pm runtime Vikram Pandita (1): I2C: OMAP: Recover from Bus Busy condition -- 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
[PATCHv2 05/13] OMAP: I2C: Fix the interrupt clearing in OMAP4
On OMAP4 we were writing 1 to IRQENABLE_CLR which cleared only
the arbitration lost interrupt. The patch intends to fix the same by writing 0
to the IE register clearing all interrupts.
This is based on the work done by Vikram Pandita vikram.pand...@ti.com.
The changes from the original patch ...
- Does not use the IRQENABLE_CLR register to clear as it is not mentioned
to be legacy register IRQENABLE_CLR helps in atomically
setting/clearing specific interrupts, instead use the OMAP_I2C_IE_REG as we
are
clearing all interrupts.
Cc: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Original patch can be found here:
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=41049d62e146e0fafe2fac0a31be566b3bbc9149
drivers/i2c/busses/i2c-omap.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index ceb09c7..98720c9 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1172,10 +1172,8 @@ static int omap_i2c_runtime_suspend(struct device *dev)
_dev-dev_lost_count = _dev-get_context_loss_count(dev);
_dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
- if (_dev-dtrev == OMAP_I2C_IP_VERSION_2)
- omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
- else
- omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
if (_dev-rev OMAP_I2C_OMAP1_REV_2) {
iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] Compile error with CONFIG_SND_OMAP_SOC_OMAP4_HDMI
Hi list, Trying to compile 3.3-rc6 with the following option combination fails: CONFIG_SND_OMAP_SOC_OMAP4_HDMI=m CONFIG_SND_OMAP_SOC_HDMI=m CONFIG_OMAP2_DSS=y drivers/built-in.o: In function `omapdss_hdmihw_remove': /home/abuild/rpmbuild/BUILD/kernel-omap2plus-3.3.rc6/linux-3.3-rc6/drivers/video/omap2/dss/hdmi.c:879: undefined reference to `snd_soc_unregister_codec' drivers/built-in.o: In function `omapdss_hdmihw_probe': /home/abuild/rpmbuild/BUILD/kernel-omap2plus-3.3.rc6/linux-3.3-rc6/drivers/video/omap2/dss/hdmi.c:863: undefined reference to `snd_soc_register_codec' However, we do want to have DSS compiled into the kernel to ensure that graphics are available, but since audio is not quite as crucial for debugging, that one should live as a module. According to Takashi, it shouldn't be all that hard to split the HDMI audio code from dss/hdmi.c, but I'm currently lacking the time to do so. If anyone's interested in picking it up, I'd very much appreciate it! Thanks a lot, Alex -- 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: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Fri, Mar 2, 2012 at 7:36 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Fri, Feb 24, 2012 at 5:14 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Fri, Feb 24, 2012 at 3:46 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Fri, Feb 24, 2012 at 03:36:15PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com won't this cause issues with EHCI/OHCI interactions ? I mean, what if you connect a FS/LS device and port is handed over to OHCI, does OHCI have any needs to reset the PHY or something similar ? No, it will not cause any issues with EHCI-OHCI issues. But its difficult to comment on this because we don't have port handoff supported in hardware. regards keshava Hi Samuel please let me know if you have any comments on this patch. This is required patch for omap3 ehci enumeration instabilities. Regards Keshava Hi Samuel do you have any comments on this patch? Felipe has reviewed this patch and he is agreed for this patch. there are no comments from your side, requesting to push this change to mainline. regards keshava -- 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 7/7] OMAPDSS: HDMI: hot plug detect fix
On Thu, Mar 08, 2012 at 09:35:13AM +0200, Tomi Valkeinen wrote: On Wed, 2012-03-07 at 12:01 -0800, Greg KH wrote: On Thu, Mar 01, 2012 at 02:26:35PM +0200, Tomi Valkeinen wrote: From: Rob Clark r...@ti.com The OMAPDSS: HDMI: PHY burnout fix commit switched the HDMI driver over to using a GPIO for plug detect. Unfortunately the -detect() method was not also updated, causing HDMI to no longer work for the omapdrm driver (because it would actually check if a connection was detected before attempting to enable display). Signed-off-by: Rob Clark r...@ti.com Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com You forgot to tell me what the git commit id is for this patch (it's ca888a7958b3d808e4efd08ceff88913f4212c69, right?) Yes, that's the one. It wasn't in Linus's tree yet, only in fbdev tree, so I wasn't sure what the commit id is. Then you should not have sent it to me, as if I were to take it then, I could not have :( And why isn't this needed for the 3.0 kernel as well? The detect() function is not present in 3.0, so there was nothing to break. Ok, so everything I've queued up is all that is needed, right? greg k-h -- 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] mmc: omap_hsmmc: Simplify init for twl6030 MMC card detect
On Wed, Mar 7, 2012 at 9:12 PM, Chris Ball c...@laptop.org wrote: Hi Balaji, On Wed, Mar 07 2012, T Krishnamoorthy, Balaji wrote: OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset. Addng the offset to platform_device resource structure increments the start address for every insmod operation. MMC command fails on re-insertion as module due incorrect register base. Fix this by updating the ioremap base address only. Signed-off-by: Balaji T K balaj...@ti.com Is this a regression, or has it never worked in mainline? Not a regression introduced in current merge window. It happens on re-insertion of module. will post a patch with $SUBJECT Note: eMMC detection is still failing on resertion due to card vcc power off on rmmod And this? This issue was hidden and uncovered after this fix. This problem is Vcc being powered off without sleep command. 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/8] OMAP4: hwmod: add EMIF hw mod data
From: Benoit Cousson b-cous...@ti.com
Add hwmod data for EMIF IP instances in OMAP4.
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
Changes since RFC:
- Improved commit log
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 110
1 files changed, 110 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index f9f1510..2b107c7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5480,6 +5480,111 @@ static struct omap_hwmod omap44xx_usb_tll_hs_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_usb_tll_hs_slaves),
};
+/*
+ * 'emif' class
+ * external memory interface no1
+ */
+
+static struct omap_hwmod_class omap44xx_emif_hwmod_class = {
+ .name = emif,
+};
+
+/* emif1 */
+static struct omap_hwmod omap44xx_emif1_hwmod;
+static struct omap_hwmod_irq_info omap44xx_emif1_irqs[] = {
+ { .irq = 110 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_addr_space omap44xx_emif1_addrs[] = {
+ {
+ .pa_start = 0x4c00,
+ .pa_end = 0x4cff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* emif_fw - emif1 */
+static struct omap_hwmod_ocp_if omap44xx_emif_fw__emif1 = {
+ .master = omap44xx_emif_fw_hwmod,
+ .slave = omap44xx_emif1_hwmod,
+ .clk= l3_div_ck,
+ .addr = omap44xx_emif1_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* emif1 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_emif1_slaves[] = {
+ omap44xx_emif_fw__emif1,
+};
+
+static struct omap_hwmod omap44xx_emif1_hwmod = {
+ .name = emif1,
+ .class = omap44xx_emif_hwmod_class,
+ .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+ .mpu_irqs = omap44xx_emif1_irqs,
+ .main_clk = emif1_fck,
+ .clkdm_name = l3_emif_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_MEMIF_EMIF_1_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_MEMIF_EMIF_1_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .slaves = omap44xx_emif1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_emif1_slaves),
+};
+
+/* emif2 */
+static struct omap_hwmod omap44xx_emif2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_emif2_irqs[] = {
+ { .irq = 111 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_addr_space omap44xx_emif2_addrs[] = {
+ {
+ .pa_start = 0x4d00,
+ .pa_end = 0x4dff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* emif_fw - emif2 */
+static struct omap_hwmod_ocp_if omap44xx_emif_fw__emif2 = {
+ .master = omap44xx_emif_fw_hwmod,
+ .slave = omap44xx_emif2_hwmod,
+ .clk= l3_div_ck,
+ .addr = omap44xx_emif2_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* emif2 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_emif2_slaves[] = {
+ omap44xx_emif_fw__emif2,
+};
+
+static struct omap_hwmod omap44xx_emif2_hwmod = {
+ .name = emif2,
+ .class = omap44xx_emif_hwmod_class,
+ .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+ .mpu_irqs = omap44xx_emif2_irqs,
+ .main_clk = emif2_fck,
+ .clkdm_name = l3_emif_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_MEMIF_EMIF_1_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_MEMIF_EMIF_1_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ }
+ },
+ .slaves = omap44xx_emif2_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_emif2_slaves),
+};
+
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
@@ -5629,6 +5734,11 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] =
{
/* wd_timer class */
omap44xx_wd_timer2_hwmod,
omap44xx_wd_timer3_hwmod,
+
+ /* emif class */
+ omap44xx_emif1_hwmod,
+ omap44xx_emif2_hwmod,
+
NULL,
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] misc: ddr: add LPDDR2 data from JESD209-2
add LPDDR2 data from the JEDEC spec JESD209-2. The data
includes:
1. Addressing information for LPDDR2 memories of different
densities and types(S2/S4)
2. AC timing data.
This data will useful for memory controller device drivers
Cc: Greg KH g...@kroah.com
Signed-off-by: Aneesh V ane...@ti.com
---
Changes since RFC:
- Moved to /lib from /drivers/misc
- Corrected Copyright year
---
include/misc/jedec_ddr.h | 177 ++
lib/Kconfig |8 ++
lib/Makefile |3 +
lib/jedec_ddr_data.c | 135 +++
4 files changed, 323 insertions(+), 0 deletions(-)
create mode 100644 include/misc/jedec_ddr.h
create mode 100644 lib/jedec_ddr_data.c
diff --git a/include/misc/jedec_ddr.h b/include/misc/jedec_ddr.h
new file mode 100644
index 000..93ffd4a
--- /dev/null
+++ b/include/misc/jedec_ddr.h
@@ -0,0 +1,177 @@
+/*
+ * Definitions for DDR memories based on JEDEC specs
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ *
+ * Aneesh V ane...@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.
+ */
+#ifndef __LINUX_JEDEC_DDR_H
+#define __LINUX_JEDEC_DDR_H
+
+#ifndef __ASSEMBLY__
+#include linux/types.h
+
+/* DDR Densities */
+#define DDR_DENSITY_64Mb 1
+#define DDR_DENSITY_128Mb 2
+#define DDR_DENSITY_256Mb 3
+#define DDR_DENSITY_512Mb 4
+#define DDR_DENSITY_1Gb5
+#define DDR_DENSITY_2Gb6
+#define DDR_DENSITY_4Gb7
+#define DDR_DENSITY_8Gb8
+#define DDR_DENSITY_16Gb 9
+#define DDR_DENSITY_32Gb 10
+
+/* DDR type */
+#define DDR_TYPE_DDR2 1
+#define DDR_TYPE_DDR3 2
+#define DDR_TYPE_LPDDR2_S4 3
+#define DDR_TYPE_LPDDR2_S2 4
+#define DDR_TYPE_LPDDR2_NVM5
+
+/* DDR IO width */
+#define DDR_IO_WIDTH_4 1
+#define DDR_IO_WIDTH_8 2
+#define DDR_IO_WIDTH_163
+#define DDR_IO_WIDTH_324
+
+/* Number of Row bits */
+#define R9 9
+#define R1010
+#define R1111
+#define R1212
+#define R1313
+#define R1414
+#define R1515
+#define R1616
+
+/* Number of Column bits */
+#define C7 7
+#define C8 8
+#define C9 9
+#define C1010
+#define C1111
+#define C1212
+
+/* Number of Banks */
+#define B1 0
+#define B2 1
+#define B4 2
+#define B8 3
+
+/* Refresh rate in nano-seconds */
+#define T_REFI_15_615600
+#define T_REFI_7_8 7800
+#define T_REFI_3_9 3900
+
+/* tRFC values */
+#define T_RFC_90 9
+#define T_RFC_110 11
+#define T_RFC_130 13
+#define T_RFC_160 16
+#define T_RFC_210 21
+#define T_RFC_300 30
+#define T_RFC_350 35
+
+/* Mode register numbers */
+#define DDR_MR00
+#define DDR_MR11
+#define DDR_MR22
+#define DDR_MR33
+#define DDR_MR44
+#define DDR_MR55
+#define DDR_MR66
+#define DDR_MR77
+#define DDR_MR88
+#define DDR_MR99
+#define DDR_MR10 10
+#define DDR_MR11 11
+#define DDR_MR16 16
+#define DDR_MR17 17
+#define DDR_MR18 18
+
+/*
+ * LPDDR2 related defines
+ */
+
+/* MR4 register fields */
+#define MR4_SDRAM_REF_RATE_SHIFT 0
+#define MR4_SDRAM_REF_RATE_MASK7
+#define MR4_TUF_SHIFT 7
+#define MR4_TUF_MASK (1 7)
+
+/* MR4 SDRAM Refresh Rate field values */
+#define SDRAM_TEMP_NOMINAL 0x3
+#define SDRAM_TEMP_RESERVED_4 0x4
+#define SDRAM_TEMP_HIGH_DERATE_REFRESH 0x5
+#define SDRAM_TEMP_HIGH_DERATE_REFRESH_AND_TIMINGS 0x6
+#define SDRAM_TEMP_VERY_HIGH_SHUTDOWN 0x7
+
+#define NUM_DDR_ADDR_TABLE_ENTRIES 11
+#define NUM_DDR_TIMING_TABLE_ENTRIES 4
+
+/* Structure for DDR addressing info from the JEDEC spec */
+struct lpddr2_addressing {
+ u32 num_banks;
+ u32 tREFI_ns;
+ u32 tRFCab_ps;
+};
+
+/*
+ * Structure for timings from the LPDDR2 datasheet
+ * All parameters are in pico seconds(ps) unless explicitly indicated
+ * with a suffix like
[PATCH 3/8] misc: emif: add register definitions for EMIF
Add register offsets and bit field definitions for EMIF module in TI SoCs Cc: Greg KH g...@kroah.com Signed-off-by: Aneesh V ane...@ti.com --- Changes since RFC: - Improved commit log - Corrected copyright year - Changed file name in order to add other defines needed by the driver in the same file in subsequent patches --- drivers/misc/emif.h | 454 +++ 1 files changed, 454 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/emif.h diff --git a/drivers/misc/emif.h b/drivers/misc/emif.h new file mode 100644 index 000..44b97df --- /dev/null +++ b/drivers/misc/emif.h @@ -0,0 +1,454 @@ +/* + * Defines for the EMIF driver + * + * Copyright (C) 2012 Texas Instruments, Inc. + * + * Benoit Cousson (b-cous...@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. + */ +#ifndef __EMIF_H +#define __EMIF_H + +/* Registers offset */ +#define EMIF_MODULE_ID_AND_REVISION0x +#define EMIF_STATUS0x0004 +#define EMIF_SDRAM_CONFIG 0x0008 +#define EMIF_SDRAM_CONFIG_20x000c +#define EMIF_SDRAM_REFRESH_CONTROL 0x0010 +#define EMIF_SDRAM_REFRESH_CTRL_SHDW 0x0014 +#define EMIF_SDRAM_TIMING_10x0018 +#define EMIF_SDRAM_TIMING_1_SHDW 0x001c +#define EMIF_SDRAM_TIMING_20x0020 +#define EMIF_SDRAM_TIMING_2_SHDW 0x0024 +#define EMIF_SDRAM_TIMING_30x0028 +#define EMIF_SDRAM_TIMING_3_SHDW 0x002c +#define EMIF_LPDDR2_NVM_TIMING 0x0030 +#define EMIF_LPDDR2_NVM_TIMING_SHDW0x0034 +#define EMIF_POWER_MANAGEMENT_CONTROL 0x0038 +#define EMIF_POWER_MANAGEMENT_CTRL_SHDW0x003c +#define EMIF_LPDDR2_MODE_REG_DATA 0x0040 +#define EMIF_LPDDR2_MODE_REG_CONFIG0x0050 +#define EMIF_OCP_CONFIG0x0054 +#define EMIF_OCP_CONFIG_VALUE_10x0058 +#define EMIF_OCP_CONFIG_VALUE_20x005c +#define EMIF_IODFT_TEST_LOGIC_GLOBAL_CONTROL 0x0060 +#define EMIF_IODFT_TEST_LOGIC_CTRL_MISR_RESULT 0x0064 +#define EMIF_IODFT_TEST_LOGIC_ADDRESS_MISR_RESULT 0x0068 +#define EMIF_IODFT_TEST_LOGIC_DATA_MISR_RESULT_1 0x006c +#define EMIF_IODFT_TEST_LOGIC_DATA_MISR_RESULT_2 0x0070 +#define EMIF_IODFT_TEST_LOGIC_DATA_MISR_RESULT_3 0x0074 +#define EMIF_PERFORMANCE_COUNTER_1 0x0080 +#define EMIF_PERFORMANCE_COUNTER_2 0x0084 +#define EMIF_PERFORMANCE_COUNTER_CONFIG0x0088 +#define EMIF_PERFORMANCE_COUNTER_MASTER_REGION_SELECT 0x008c +#define EMIF_PERFORMANCE_COUNTER_TIME 0x0090 +#define EMIF_MISC_REG 0x0094 +#define EMIF_DLL_CALIB_CTRL0x0098 +#define EMIF_DLL_CALIB_CTRL_SHDW 0x009c +#define EMIF_END_OF_INTERRUPT 0x00a0 +#define EMIF_SYSTEM_OCP_INTERRUPT_RAW_STATUS 0x00a4 +#define EMIF_LL_OCP_INTERRUPT_RAW_STATUS 0x00a8 +#define EMIF_SYSTEM_OCP_INTERRUPT_STATUS 0x00ac +#define EMIF_LL_OCP_INTERRUPT_STATUS 0x00b0 +#define EMIF_SYSTEM_OCP_INTERRUPT_ENABLE_SET 0x00b4 +#define EMIF_LL_OCP_INTERRUPT_ENABLE_SET 0x00b8 +#define EMIF_SYSTEM_OCP_INTERRUPT_ENABLE_CLEAR 0x00bc +#define EMIF_LL_OCP_INTERRUPT_ENABLE_CLEAR 0x00c0 +#define EMIF_SDRAM_OUTPUT_IMPEDANCE_CALIBRATION_CONFIG 0x00c8 +#define EMIF_TEMPERATURE_ALERT_CONFIG 0x00cc +#define EMIF_OCP_ERROR_LOG 0x00d0 +#define EMIF_READ_WRITE_LEVELING_RAMP_WINDOW 0x00d4 +#define EMIF_READ_WRITE_LEVELING_RAMP_CONTROL 0x00d8 +#define EMIF_READ_WRITE_LEVELING_CONTROL 0x00dc +#define EMIF_DDR_PHY_CTRL_10x00e4 +#define EMIF_DDR_PHY_CTRL_1_SHDW 0x00e8 +#define EMIF_DDR_PHY_CTRL_20x00ec +#define EMIF_PRIORITY_TO_CLASS_OF_SERVICE_MAPPING 0x0100 +#define EMIF_CONNECTION_ID_TO_CLASS_OF_SERVICE_1_MAPPING 0x0104 +#define EMIF_CONNECTION_ID_TO_CLASS_OF_SERVICE_2_MAPPING 0x0108 +#define EMIF_READ_WRITE_EXECUTION_THRESHOLD0x0120 +#define EMIF_COS_CONFIG0x0124 +#define EMIF_PHY_STATUS_1 0x0140 +#define EMIF_PHY_STATUS_2 0x0144 +#define EMIF_PHY_STATUS_3 0x0148 +#define EMIF_PHY_STATUS_4
[PATCH 4/8] misc: emif: add basic infrastructure for EMIF driver
EMIF is an SDRAM controller used in various Texas Instruments SoCs. EMIF supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols. Add the basic infrastructure for EMIF driver that includes driver registration, probe, parsing of platform data etc. Cc: Greg KH g...@kroah.com Signed-off-by: Aneesh V ane...@ti.com --- Changes since RFC: - Removed emif_cleanup() function and instead used devm_* variant of APIs for resource allocations - Split include/linux/emif.h into two parts. The first part now becomes include/linux/platform_data/emif_plat.h and the other part is now merged in drivers/misc/emif.h - Made error messages more verbose - Corrected copyright year - Fixed other coding style comments - Minor adjustments to patch organization. Moved some definitions to a subsequent patch that uses them - Added a list a of devices. This is needed for errata i728 workaround and for the new locking scheme - Added documentation for driver --- Documentation/misc-devices/ti-emif.txt | 58 ++ drivers/misc/Kconfig| 12 ++ drivers/misc/Makefile |1 + drivers/misc/emif.c | 289 +++ drivers/misc/emif.h |7 + include/linux/platform_data/emif_plat.h | 128 ++ 6 files changed, 495 insertions(+), 0 deletions(-) create mode 100644 Documentation/misc-devices/ti-emif.txt create mode 100644 drivers/misc/emif.c create mode 100644 include/linux/platform_data/emif_plat.h diff --git a/Documentation/misc-devices/ti-emif.txt b/Documentation/misc-devices/ti-emif.txt new file mode 100644 index 000..a9238c1 --- /dev/null +++ b/Documentation/misc-devices/ti-emif.txt @@ -0,0 +1,58 @@ +TI EMIF SDRAM Controller Driver: + +Author + +Aneesh V ane...@ti.com + +Location + +driver/misc/emif.c + +Supported SoCs: +=== +TI OMAP44xx +TI OMAP54xx + +Menuconfig option: +== +Device Drivers + Misc devices + Texas Instruments EMIF driver + +Description +=== +This driver is for the EMIF module available in Texas Instruments +SoCs. EMIF is an SDRAM controller that, based on its revision, +supports one or more of DDR2, DDR3, and LPDDR2 SDRAM protocols. +This driver takes care of only LPDDR2 memories presently. The +functions of the driver includes re-configuring AC timing +parameters and other settings during frequency, voltage and +temperature changes + +Platform Data (see include/linux/platform_data/emif_plat.h): += +DDR device details and other board dependent and SoC dependent +information can be passed through platform data (struct emif_platform_data) +- DDR device details: 'struct ddr_device_info' +- Device AC timings: 'struct lpddr2_timings' and 'struct lpddr2_min_tck' +- Custom configurations: customizable policy options through + 'struct emif_custom_configs' +- IP revision +- PHY type + +Interface to the external world: + +EMIF driver registers notifiers for voltage and frequency changes +affecting EMIF and takes appropriate actions when these are invoked. +- freq_pre_notify_handling() +- freq_post_notify_handling() +- volt_notify_handling() + +Debugfs + +The driver creates two debugfs entries per device. +- regcache_dump : dump of register values calculated and saved for all + frequencies used so far. +- mr4 : last polled value of MR4 register in the LPDDR2 device. MR4 + indicates the current temperature level of the device. + diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 6a1a092..732b38a 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -451,6 +451,18 @@ config VMWARE_BALLOON To compile this driver as a module, choose M here: the module will be called vmw_balloon. +config TI_EMIF + tristate Texas Instruments EMIF driver + select DDR + help + This driver is for the EMIF module available in Texas Instruments + SoCs. EMIF is an SDRAM controller that, based on its revision, + supports one or more of DDR2, DDR3, and LPDDR2 SDRAM protocols. + This driver takes care of only LPDDR2 memories presently. The + functions of the driver includes re-configuring AC timing + parameters and other settings during frequency, voltage and + temperature changes + config ARM_CHARLCD bool ARM Ltd. Character LCD Driver depends on PLAT_VERSATILE diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 3e1d801..75ab920 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -36,6 +36,7 @@ obj-$(CONFIG_TI_DAC7512) += ti_dac7512.o obj-$(CONFIG_C2PORT) += c2port/ obj-$(CONFIG_IWMC3200TOP) += iwmc3200top/ obj-$(CONFIG_HMC6352) += hmc6352.o +obj-$(CONFIG_TI_EMIF) += emif.o obj-y += eeprom/
[PATCH 5/8] misc: emif: handle frequency and voltage change events
Change SDRAM timings and other settings as necessary
on voltage and frequency changes. We calculate these
register settings based on data from the device data
sheet and inputs such a frequency, voltage state(stable
or ramping), temperature level etc.
TODO: frequency and voltage change handling needs to
be integrated with clock framework and regulator
framework respectively. This is not done today
due to missing pieces in the kernel.
Cc: Greg KH g...@kroah.com
Signed-off-by: Aneesh V ane...@ti.com
---
Changes since RFC:
- Added comment in commit log as well as code about
missing integration part that needs to be done in
future
- Removed some settings that were relevant only for
DDR3
- Correction in temperature derated value of tim3
- Added errata i735 and i728 workarounds. As part of
this we need to now maintain a list of all devices
in the driver and iterate through them in some cases
- Improved synchronization. Added protection for newly
identified cases of potential race conditions.
- Minor changes in patch organization. struct members
needed by this patch now defined here.
---
drivers/misc/emif.c | 894 ++-
drivers/misc/emif.h | 130 -
2 files changed, 1020 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/emif.c b/drivers/misc/emif.c
index 4a7048a..5ab130b 100644
--- a/drivers/misc/emif.c
+++ b/drivers/misc/emif.c
@@ -21,6 +21,7 @@
#include linux/seq_file.h
#include linux/module.h
#include linux/list.h
+#include linux/spinlock.h
#include misc/jedec_ddr.h
#include emif.h
@@ -37,20 +38,595 @@
* @node: node in the device list
* @base: base address of memory-mapped IO registers.
* @dev: device pointer.
+ * @addressing table with addressing information from the spec
+ * @regs_cache:An array of 'struct emif_regs' that
stores
+ * calculated register values for different
+ * frequencies, to avoid re-calculating them on
+ * each DVFS transition.
+ * @curr_regs: The set of register values used in the last
+ * frequency change (i.e. corresponding to the
+ * frequency in effect at the moment)
* @plat_data: Pointer to saved platform data.
*/
struct emif_data {
u8 duplicate;
u8 temperature_level;
+ u8 lpmode;
struct list_headnode;
+ unsigned long irq_state;
void __iomem*base;
struct device *dev;
+ const struct lpddr2_addressing *addressing;
+ struct emif_regs*regs_cache[EMIF_MAX_NUM_FREQUENCIES];
+ struct emif_regs*curr_regs;
struct emif_platform_data *plat_data;
};
static struct emif_data *emif1;
+static spinlock_t emif_lock;
+static unsigned long irq_state;
+static u32 t_ck; /* DDR clock period in ps */
static LIST_HEAD(device_list);
+/*
+ * Calculate the period of DDR clock from frequency value
+ */
+static void set_ddr_clk_period(u32 freq)
+{
+ /* Divide 10^12 by frequency to get period in ps */
+ t_ck = (u32)DIV_ROUND_UP_ULL(1ull, freq);
+}
+
+/*
+ * Get the CL from SDRAM_CONFIG register
+ */
+static u32 get_cl(struct emif_data *emif)
+{
+ u32 cl;
+ void __iomem*base = emif-base;
+
+ cl = (readl(base + EMIF_SDRAM_CONFIG) CL_MASK) CL_SHIFT;
+
+ return cl;
+}
+
+static void set_lpmode(struct emif_data *emif, u8 lpmode)
+{
+ u32 temp;
+ void __iomem *base = emif-base;
+
+ temp = readl(base + EMIF_POWER_MANAGEMENT_CONTROL);
+ temp = ~LP_MODE_MASK;
+ temp |= (lpmode LP_MODE_SHIFT);
+ writel(temp, base + EMIF_POWER_MANAGEMENT_CONTROL);
+}
+
+static void do_freq_update(void)
+{
+ struct emif_data *emif;
+
+ /*
+* Workaround for errata i728: Disable LPMODE during FREQ_UPDATE
+*
+* i728 DESCRIPTION:
+* The EMIF automatically puts the SDRAM into self-refresh mode
+* after the EMIF has not performed accesses during
+* EMIF_PWR_MGMT_CTRL[7:4] REG_SR_TIM number of DDR clock cycles
+* and the EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field is set
+* to 0x2. If during a small window the following three events
+* occur:
+* - The SR_TIMING counter expires
+* - And frequency change is requested
+* - And OCP access is requested
+* Then it causes instable clock on the DDR interface.
+*
+* WORKAROUND
+* To avoid the occurrence of the three events, the workaround
+* is to disable the self-refresh when requesting a
[PATCH 6/8] misc: emif: add interrupt and temperature handling
Add an ISR for EMIF that:
1. reports details of access errors
2. takes action on thermal events
Also clear all interrupts on shut-down. Pending IRQs
may casue problems during warm-reset.
Temperature handling:
EMIF can be configured to poll the temperature level
of an LPDDR2 device from the MR4 mode register in the
device. EMIF generates an interrupt whenever it identifies
a temperature level change between two consecutive pollings.
Some of the timing parameters need to be de-rated at high
temperatures. The interrupt handler takes care of doing
this and also takes care of going back to nominal settings
when temperature falls back to nominal levels.
Cc: Greg KH g...@kroah.com
Signed-off-by: Aneesh V ane...@ti.com
---
Changes since RFC:
- Improved commit log
- Improved synchronization with thread context
---
drivers/misc/emif.c | 211 ++-
1 files changed, 209 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/emif.c b/drivers/misc/emif.c
index 5ab130b..09d0e68 100644
--- a/drivers/misc/emif.c
+++ b/drivers/misc/emif.c
@@ -545,6 +545,42 @@ static u32 get_pwr_mgmt_ctrl(u32 freq, struct emif_data
*emif, u32 ip_rev)
}
/*
+ * Get the temperature level of the EMIF instance:
+ * Reads the MR4 register of attached SDRAM parts to find out the temperature
+ * level. If there are two parts attached(one on each CS), then the temperature
+ * level for the EMIF instance is the higher of the two temperatures.
+ */
+static void get_temperature_level(struct emif_data *emif)
+{
+ u32 temp, temperature_level;
+ void __iomem*base;
+
+ base = emif-base;
+
+ /* Read mode register 4 */
+ writel(DDR_MR4, base + EMIF_LPDDR2_MODE_REG_CONFIG);
+ temperature_level = readl(base + EMIF_LPDDR2_MODE_REG_DATA);
+ temperature_level = (temperature_level MR4_SDRAM_REF_RATE_MASK)
+ MR4_SDRAM_REF_RATE_SHIFT;
+
+ if (emif-plat_data-device_info-cs1_used) {
+ writel(DDR_MR4 | CS_MASK, base + EMIF_LPDDR2_MODE_REG_CONFIG);
+ temp = readl(base + EMIF_LPDDR2_MODE_REG_DATA);
+ temp = (temp MR4_SDRAM_REF_RATE_MASK)
+MR4_SDRAM_REF_RATE_SHIFT;
+ temperature_level = max(temp, temperature_level);
+ }
+
+ /* treat everything less than nominal(3) in MR4 as nominal */
+ if (unlikely(temperature_level SDRAM_TEMP_NOMINAL))
+ temperature_level = SDRAM_TEMP_NOMINAL;
+
+ /* if we get reserved value in MR4 persist with the existing value */
+ if (likely(temperature_level != SDRAM_TEMP_RESERVED_4))
+ emif-temperature_level = temperature_level;
+}
+
+/*
* Program EMIF shadow registers that are not dependent on temperature
* or voltage
*/
@@ -627,6 +663,158 @@ out:
writel(ref_ctrl, base + EMIF_SDRAM_REFRESH_CTRL_SHDW);
}
+static irqreturn_t handle_temp_alert(void __iomem *base, struct emif_data
*emif)
+{
+ u32 old_temp_level;
+ irqreturn_t ret = IRQ_HANDLED;
+
+ spin_lock_irqsave(emif_lock, irq_state);
+ old_temp_level = emif-temperature_level;
+ get_temperature_level(emif);
+
+ if (unlikely(emif-temperature_level == old_temp_level)) {
+ goto out;
+ } else if (!emif-curr_regs) {
+ dev_err(emif-dev, temperature alert before registers are
calculated, not de-rating timings\n);
+ goto out;
+ }
+
+ if (emif-temperature_level old_temp_level ||
+ emif-temperature_level == SDRAM_TEMP_VERY_HIGH_SHUTDOWN) {
+ /*
+* Temperature coming down - defer handling to thread OR
+* Temperature far too high - do kernel_power_off() from
+* thread context
+*/
+ ret = IRQ_WAKE_THREAD;
+ } else {
+ /* Temperature is going up - handle immediately */
+ setup_temperature_sensitive_regs(emif, emif-curr_regs);
+ do_freq_update();
+ }
+
+out:
+ spin_unlock_irqrestore(emif_lock, irq_state);
+ return ret;
+}
+
+static irqreturn_t emif_interrupt_handler(int irq, void *dev_id)
+{
+ u32 interrupts;
+ struct emif_data*emif = dev_id;
+ void __iomem*base = emif-base;
+ struct device *dev = emif-dev;
+ irqreturn_t ret = IRQ_HANDLED;
+
+ /* Save the status and clear it */
+ interrupts = readl(base + EMIF_SYSTEM_OCP_INTERRUPT_STATUS);
+ writel(interrupts, base + EMIF_SYSTEM_OCP_INTERRUPT_STATUS);
+
+ /*
+* Handle temperature alert
+* Temperature alert should be same for all ports
+* So, it's enough to process it only for one of the ports
+*/
+ if (interrupts TA_SYS_MASK)
+ ret = handle_temp_alert(base, emif);
+
+ if
[PATCH] mmc: omap4: hsmmc: fix module re-insertion
OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset. Addng the offset to platform_device resource structure increments the start address for every insmod operation. MMC command fails on re-insertion as module due to incorrect register base. Fix this by updating the ioremap base address only. Signed-off-by: Balaji T K balaj...@ti.com --- drivers/mmc/host/omap_hsmmc.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index e550170..102425c 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1741,8 +1741,6 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) if (res == NULL || irq 0) return -ENXIO; - res-start += pdata-reg_offset; - res-end += pdata-reg_offset; res = request_mem_region(res-start, resource_size(res), pdev-name); if (res == NULL) return -EBUSY; @@ -1766,7 +1764,7 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) host-dma_ch= -1; host-irq = irq; host-slot_id = 0; - host-mapbase = res-start; + host-mapbase = res-start + pdata-reg_offset; host-base = ioremap(host-mapbase, SZ_4K); host-power_mode = MMC_POWER_OFF; host-next_data.cookie = 1; -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] misc: emif: add one-time settings
Add settings that are not dependent on frequency
or any other transient parameters. This includes
- power managment control init
- impedence calibration control
- frequency independent phy configuration registers
- initialization of temperature polling
Cc: Greg KH g...@kroah.com
Signed-off-by: Aneesh V ane...@ti.com
---
Changes since RFC:
- Improved commit log
- Changes for errata i728 workaround
---
drivers/misc/emif.c | 147 +++
1 files changed, 147 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/emif.c b/drivers/misc/emif.c
index 09d0e68..da79dd6 100644
--- a/drivers/misc/emif.c
+++ b/drivers/misc/emif.c
@@ -78,6 +78,24 @@ static void set_ddr_clk_period(u32 freq)
}
/*
+ * Get bus width used by EMIF. Note that this may be different from the
+ * bus width of the DDR devices used. For instance two 16-bit DDR devices
+ * may be connected to a given CS of EMIF. In this case bus width as far
+ * as EMIF is concerned is 32, where as the DDR bus width is 16 bits.
+ */
+static u32 get_emif_bus_width(struct emif_data *emif)
+{
+ u32 width;
+ void __iomem*base = emif-base;
+
+ width = (readl(base + EMIF_SDRAM_CONFIG) NARROW_MODE_MASK)
+NARROW_MODE_SHIFT;
+ width = width == 0 ? 32 : 16;
+
+ return width;
+}
+
+/*
* Get the CL from SDRAM_CONFIG register
*/
static u32 get_cl(struct emif_data *emif)
@@ -372,6 +390,70 @@ static u32 get_sdram_tim_3_shdw(const struct
lpddr2_timings *timings,
return tim3;
}
+static u32 get_zq_config_reg(const struct lpddr2_addressing *addressing,
+ bool cs1_used, bool cal_resistors_per_cs)
+{
+ u32 zq = 0, val = 0;
+
+ val = EMIF_ZQCS_INTERVAL_US * 1000 / addressing-tREFI_ns;
+ zq |= val ZQ_REFINTERVAL_SHIFT;
+
+ val = DIV_ROUND_UP(T_ZQCL_DEFAULT_NS, T_ZQCS_DEFAULT_NS) - 1;
+ zq |= val ZQ_ZQCL_MULT_SHIFT;
+
+ val = DIV_ROUND_UP(T_ZQINIT_DEFAULT_NS, T_ZQCL_DEFAULT_NS) - 1;
+ zq |= val ZQ_ZQINIT_MULT_SHIFT;
+
+ zq |= ZQ_SFEXITEN_ENABLE ZQ_SFEXITEN_SHIFT;
+
+ if (cal_resistors_per_cs)
+ zq |= ZQ_DUALCALEN_ENABLE ZQ_DUALCALEN_SHIFT;
+ else
+ zq |= ZQ_DUALCALEN_DISABLE ZQ_DUALCALEN_SHIFT;
+
+ zq |= ZQ_CS0EN_MASK; /* CS0 is used for sure */
+
+ val = cs1_used ? 1 : 0;
+ zq |= val ZQ_CS1EN_SHIFT;
+
+ return zq;
+}
+
+static u32 get_temp_alert_config(const struct lpddr2_addressing *addressing,
+ const struct emif_custom_configs *custom_configs, bool cs1_used,
+ u32 sdram_io_width, u32 emif_bus_width)
+{
+ u32 alert = 0, interval, devcnt;
+
+ if (custom_configs (custom_configs-mask
+ EMIF_CUSTOM_CONFIG_TEMP_ALERT_POLL_INTERVAL))
+ interval = custom_configs-temp_alert_poll_interval_ms;
+ else
+ interval = TEMP_ALERT_POLL_INTERVAL_DEFAULT_MS;
+
+ interval *= 100;/* Convert to ns */
+ interval /= addressing-tREFI_ns; /* Convert to refresh cycles */
+ alert |= (interval TA_REFINTERVAL_SHIFT);
+
+ /*
+* sdram_io_width is in 'log2(x) - 1' form. Convert emif_bus_width
+* also to this form and subtract to get TA_DEVCNT, which is
+* in log2(x) form.
+*/
+ emif_bus_width = __fls(emif_bus_width) - 1;
+ devcnt = emif_bus_width - sdram_io_width;
+ alert |= devcnt TA_DEVCNT_SHIFT;
+
+ /* DEVWDT is in 'log2(x) - 3' form */
+ alert |= (sdram_io_width - 2) TA_DEVWDT_SHIFT;
+
+ alert |= 1 TA_SFEXITEN_SHIFT;
+ alert |= 1 TA_CS0EN_SHIFT;
+ alert |= (cs1_used ? 1 : 0) TA_CS1EN_SHIFT;
+
+ return alert;
+}
+
static u32 get_read_idle_ctrl_shdw(u8 volt_ramp)
{
u32 idle = 0, val = 0;
@@ -815,6 +897,70 @@ static int __init setup_interrupts(struct emif_data *emif,
u32 irq)
}
+static void __init emif_onetime_settings(struct emif_data *emif)
+{
+ u32 pwr_mgmt_ctrl, zq, temp_alert_cfg;
+ void __iomem*base = emif-base;
+ const struct lpddr2_addressing *addressing;
+ const struct ddr_device_info*device_info;
+
+ device_info = emif-plat_data-device_info;
+ addressing = get_addressing_table(device_info);
+
+ /*
+* Init power management settings
+* We don't know the frequency yet. Use a high frequency
+* value for a conservative timeout setting
+*/
+ pwr_mgmt_ctrl = get_pwr_mgmt_ctrl(10, emif,
+ emif-plat_data-ip_rev);
+ writel(pwr_mgmt_ctrl, base + EMIF_POWER_MANAGEMENT_CONTROL);
+
+ /* Init ZQ calibration settings */
+ zq = get_zq_config_reg(addressing, device_info-cs1_used,
+ device_info-cal_resistors_per_cs);
+ writel(zq, base + EMIF_SDRAM_OUTPUT_IMPEDANCE_CALIBRATION_CONFIG);
+
+
Re: [PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree
On 03/07/2012 09:46 PM, Rajendra Nayak wrote:
Hi Rob/Grant,
On Thursday 23 February 2012 05:31 PM, Rajendra Nayak wrote:
Define dt bindings for the ti-omap-hsmmc, and adapt
the driver to extract data (which was earlier passed as
platform_data) from device tree.
Any comments on these bindings for omap hsmmc? All the dependent
patches/series on which this series was based have now made it to
the respective -next of Mark and Chris.
Acked-by: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Rajendra Nayakrna...@ti.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 31 +
drivers/mmc/host/omap_hsmmc.c | 68
2 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
new file mode 100644
index 000..e4fa8f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -0,0 +1,31 @@
+* TI Highspeed MMC host controller for OMAP
+
+The Highspeed MMC Host Controller on TI OMAP family
+provides an interface for MMC, SD, and SDIO types of memory cards.
+
+Required properties:
+- compatible:
+ Should be ti,omap2-hsmmc, for OMAP2/3 controllers
+ Should be ti,omap4-hsmmc, for OMAP4 controllers
+- ti,hwmods: Must be mmcn, n is controller instance starting 1
+- reg : should contain hsmmc registers location and length
+
+Optional properties:
+ti,dual-volt: boolean, supports dual voltage cards
+supply-name-supply: phandle to the regulator device tree node
+supply-name examples are vmmc, vmmc_aux etc
+ti,bus-width: Number of data lines, default assumed is 1 if the
property is missing.
+cd-gpios: GPIOs for card detection
+wp-gpios: GPIOs for write protection
+ti,non-removable: non-removable slot (like eMMC)
+
+Example:
+mmc1: mmc@0x4809c000 {
+compatible = ti,omap4-hsmmc;
+reg =0x4809c000 0x400;
+ti,hwmods = mmc1;
+ti,dual-volt;
+ti,bus-width =4;
+vmmc-supply =vmmc; /* phandle to regulator node */
+ti,non-removable;
+};
diff --git a/drivers/mmc/host/omap_hsmmc.c
b/drivers/mmc/host/omap_hsmmc.c
index 35f6dc1..0c93d58 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -26,6 +26,9 @@
#includelinux/platform_device.h
#includelinux/timer.h
#includelinux/clk.h
+#includelinux/of.h
+#includelinux/of_gpio.h
+#includelinux/of_device.h
#includelinux/mmc/host.h
#includelinux/mmc/core.h
#includelinux/mmc/mmc.h
@@ -1718,6 +1721,46 @@ static void omap_hsmmc_debugfs(struct mmc_host
*mmc)
#endif
+#ifdef CONFIG_OF
+static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct
device *dev)
+{
+struct omap_mmc_platform_data *pdata;
+struct device_node *np = dev-of_node;
+u32 bus_width;
+
+pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+if (!pdata)
+return NULL; /* out of memory */
+
+if (of_find_property(np, ti,dual-volt, NULL))
+pdata-controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT;
+
+/* This driver only supports 1 slot */
+pdata-nr_slots = 1;
+pdata-slots[0].switch_pin = of_get_named_gpio(np, cd-gpios, 0);
+pdata-slots[0].gpio_wp = of_get_named_gpio(np, wp-gpios, 0);
+
+if (of_find_property(np, ti,non-removable, NULL)) {
+pdata-slots[0].nonremovable = true;
+pdata-slots[0].no_regulator_off_init = true;
+}
+of_property_read_u32(np, ti,bus-width,bus_width);
+if (bus_width == 4)
+pdata-slots[0].caps |= MMC_CAP_4_BIT_DATA;
+else if (bus_width == 8)
+pdata-slots[0].caps |= MMC_CAP_8_BIT_DATA;
+return pdata;
+}
+#else
+static inline struct omap_mmc_platform_data
+*of_get_hsmmc_pdata(struct device *dev)
+{
+return NULL;
+}
+#endif
+
+static const struct of_device_id omap_mmc_of_match[];
+
static int __init omap_hsmmc_probe(struct platform_device *pdev)
{
struct omap_mmc_platform_data *pdata = pdev-dev.platform_data;
@@ -1725,6 +1768,14 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
struct omap_hsmmc_host *host = NULL;
struct resource *res;
int ret, irq;
+const struct of_device_id *match;
+
+match = of_match_device(omap_mmc_of_match,pdev-dev);
+if (match) {
+pdata = of_get_hsmmc_pdata(pdev-dev);
+if (match-data)
+pdata-reg_offset = *(u16 *)match-data;
+}
if (pdata == NULL) {
dev_err(pdev-dev, Platform Data is missing\n);
@@ -2120,12 +2171,29 @@ static struct dev_pm_ops omap_hsmmc_dev_pm_ops
= {
.runtime_resume = omap_hsmmc_runtime_resume,
};
+#if defined(CONFIG_OF)
+static u16 omap4_reg_offset = 0x100;
+
+static const struct of_device_id omap_mmc_of_match[] = {
[PATCH 0/8] Add TI EMIF SDRAM controller driver
Add a driver for the EMIF SDRAM controller used in TI SoCs EMIF is an SDRAM controller that supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support for LPDDR2. The driver supports the following features: - Calculates the DDR AC timing parameters to be set in EMIF registers using data from the device data-sheets and based on the DDR frequency. If data from data-sheets is not available default timing values from the JEDEC spec are used. These will be safe, but not necessarily optimal - API for changing timings during DVFS or at boot-up - Temperature alert configuration and handling of temperature alerts, if any for LPDDR2 devices * temperature alert is based on periodic polling of MR4 mode register in DDR devices automatically performed by hardware * timings are de-rated and brought back to nominal when temperature raises and falls respectively - Cache of calculated register values to avoid re-calculating them The driver will need some minor updates when it is eventually integrated with Dynamic Voltage and Frequency Scaling (DVFS). This can not be done now as DVFS support is not available in the mainline yet. Discussions with Santosh Shilimkar santosh.shilim...@ti.com were immensely helpful in shaping up the interfaces. Vibhore Vardhan vvard...@gmail.com did the initial code snippet for thermal handling. Testing: - The driver is tested on OMAP4430 SDP. - The driver in a slightly adapted form is also tested on OMAP5. - Since mainline kernel doesn't have DVFS support yet, testing was done using a test module. - Temperature alert handling was tested with simulated interrupts and faked temperature values as testing all cases in real-life scenarios is difficult. - Tested the driver as a module Cc: Greg KH g...@kroah.com Aneesh V (7): misc: ddr: add LPDDR2 data from JESD209-2 misc: emif: add register definitions for EMIF misc: emif: add basic infrastructure for EMIF driver misc: emif: handle frequency and voltage change events misc: emif: add interrupt and temperature handling misc: emif: add one-time settings misc: emif: add debugfs entries for emif Benoit Cousson (1): OMAP4: hwmod: add EMIF hw mod data Documentation/misc-devices/ti-emif.txt | 58 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 110 ++ drivers/misc/Kconfig | 12 + drivers/misc/Makefile |1 + drivers/misc/emif.c| 1669 drivers/misc/emif.h| 589 ++ include/linux/platform_data/emif_plat.h| 128 +++ include/misc/jedec_ddr.h | 177 +++ lib/Kconfig|8 + lib/Makefile |3 + lib/jedec_ddr_data.c | 135 +++ 11 files changed, 2890 insertions(+), 0 deletions(-) create mode 100644 Documentation/misc-devices/ti-emif.txt create mode 100644 drivers/misc/emif.c create mode 100644 drivers/misc/emif.h create mode 100644 include/linux/platform_data/emif_plat.h create mode 100644 include/misc/jedec_ddr.h create mode 100644 lib/jedec_ddr_data.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] misc: emif: add debugfs entries for emif
Add debug entries for:
1. calculated registers per frequency
2. last polled value of MR4(temperature level
of LPDDR2 memory)
Cc: Greg KH g...@kroah.com
Signed-off-by: Aneesh V ane...@ti.com
---
Changes since RFC:
- None
---
drivers/misc/emif.c | 138 +++
1 files changed, 138 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/emif.c b/drivers/misc/emif.c
index da79dd6..79fb161 100644
--- a/drivers/misc/emif.c
+++ b/drivers/misc/emif.c
@@ -18,6 +18,7 @@
#include linux/platform_device.h
#include linux/interrupt.h
#include linux/slab.h
+#include linux/debugfs.h
#include linux/seq_file.h
#include linux/module.h
#include linux/list.h
@@ -47,6 +48,7 @@
* frequency change (i.e. corresponding to the
* frequency in effect at the moment)
* @plat_data: Pointer to saved platform data.
+ * @debugfs_root: dentry to the root folder for EMIF in debugfs
*/
struct emif_data {
u8 duplicate;
@@ -60,6 +62,7 @@ struct emif_data {
struct emif_regs*regs_cache[EMIF_MAX_NUM_FREQUENCIES];
struct emif_regs*curr_regs;
struct emif_platform_data *plat_data;
+ struct dentry *debugfs_root;
};
static struct emif_data *emif1;
@@ -68,6 +71,130 @@ static unsigned longirq_state;
static u32 t_ck; /* DDR clock period in ps */
static LIST_HEAD(device_list);
+static void do_emif_regdump_show(struct seq_file *s, struct emif_data *emif,
+ struct emif_regs *regs)
+{
+ u32 type = emif-plat_data-device_info-type;
+ u32 ip_rev = emif-plat_data-ip_rev;
+
+ seq_printf(s, EMIF register cache dump for %dMHz\n,
+ regs-freq/10);
+
+ seq_printf(s, ref_ctrl_shdw\t: 0x%08x\n, regs-ref_ctrl_shdw);
+ seq_printf(s, sdram_tim1_shdw\t: 0x%08x\n, regs-sdram_tim1_shdw);
+ seq_printf(s, sdram_tim2_shdw\t: 0x%08x\n, regs-sdram_tim2_shdw);
+ seq_printf(s, sdram_tim3_shdw\t: 0x%08x\n, regs-sdram_tim3_shdw);
+
+ if (ip_rev == EMIF_4D) {
+ seq_printf(s, read_idle_ctrl_shdw_normal\t: 0x%08x\n,
+ regs-read_idle_ctrl_shdw_normal);
+ seq_printf(s, read_idle_ctrl_shdw_volt_ramp\t: 0x%08x\n,
+ regs-read_idle_ctrl_shdw_volt_ramp);
+ } else if (ip_rev == EMIF_4D5) {
+ seq_printf(s, dll_calib_ctrl_shdw_normal\t: 0x%08x\n,
+ regs-dll_calib_ctrl_shdw_normal);
+ seq_printf(s, dll_calib_ctrl_shdw_volt_ramp\t: 0x%08x\n,
+ regs-dll_calib_ctrl_shdw_volt_ramp);
+ }
+
+ if (type == DDR_TYPE_LPDDR2_S2 || type == DDR_TYPE_LPDDR2_S4) {
+ seq_printf(s, ref_ctrl_shdw_derated\t: 0x%08x\n,
+ regs-ref_ctrl_shdw_derated);
+ seq_printf(s, sdram_tim1_shdw_derated\t: 0x%08x\n,
+ regs-sdram_tim1_shdw_derated);
+ seq_printf(s, sdram_tim3_shdw_derated\t: 0x%08x\n,
+ regs-sdram_tim3_shdw_derated);
+ }
+}
+
+static int emif_regdump_show(struct seq_file *s, void *unused)
+{
+ struct emif_data*emif = s-private;
+ struct emif_regs**regs_cache;
+ int i;
+
+ if (emif-duplicate)
+ regs_cache = emif1-regs_cache;
+ else
+ regs_cache = emif-regs_cache;
+
+ for (i = 0; i EMIF_MAX_NUM_FREQUENCIES regs_cache[i]; i++) {
+ do_emif_regdump_show(s, emif, regs_cache[i]);
+ seq_printf(s, \n);
+ }
+
+ return 0;
+}
+
+static int emif_regdump_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, emif_regdump_show, inode-i_private);
+}
+
+static const struct file_operations emif_regdump_fops = {
+ .open = emif_regdump_open,
+ .read = seq_read,
+ .release= single_release,
+};
+
+static int emif_mr4_show(struct seq_file *s, void *unused)
+{
+ struct emif_data *emif = s-private;
+
+ seq_printf(s, MR4=%d\n, emif-temperature_level);
+ return 0;
+}
+
+static int emif_mr4_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, emif_mr4_show, inode-i_private);
+}
+
+static const struct file_operations emif_mr4_fops = {
+ .open = emif_mr4_open,
+ .read = seq_read,
+ .release= single_release,
+};
+
+static int __init emif_debugfs_init(struct emif_data *emif)
+{
+ struct dentry *dentry;
+ int ret;
+
+ dentry = debugfs_create_dir(dev_name(emif-dev), NULL);
+ if (IS_ERR(dentry)) {
+ ret = PTR_ERR(dentry);
+ goto err0;
+ }
+ emif-debugfs_root =
[PATCH 0/4] dt: device tree support for TI EMIF driver
This series adds device tree support for TI EMIF SDRAM controller driver. For this, a binding has been added for representing AC timing parameters and other details of LPDDR2 memories. This series depends my series for adding EMIF driver [1] [1] http://marc.info/?l=linux-omapm=133122243430942w=2 Aneesh V (4): dt: device tree bindings for LPDDR2 memories dt: emif: device tree bindings for TI's EMIF sdram controller arm: dts: EMIF and LPDDR2 device tree data for OMAP4 boards misc: emif: add device tree support to emif driver .../devicetree/bindings/lpddr2/lpddr2-timings.txt | 52 .../devicetree/bindings/lpddr2/lpddr2.txt | 102 +++ .../bindings/memory-controllers/ti/emif.txt| 55 arch/arm/boot/dts/elpida_ecb240abacn.dtsi | 67 + arch/arm/boot/dts/omap4-panda.dts | 13 + arch/arm/boot/dts/omap4-sdp.dts| 13 + arch/arm/boot/dts/omap4.dtsi | 18 ++ drivers/misc/emif.c| 289 +++- 8 files changed, 608 insertions(+), 1 deletions(-) create mode 100644 Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt create mode 100644 Documentation/devicetree/bindings/lpddr2/lpddr2.txt create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti/emif.txt create mode 100644 arch/arm/boot/dts/elpida_ecb240abacn.dtsi -- 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] dt: device tree bindings for LPDDR2 memories
device tree bindings for LPDDR2 SDRAM memories compliant
to JESD209-2 standard.
The 'lpddr2' binding in-turn uses another binding 'lpddr2-timings'
for specifying the AC timing parameters of the memory device at
different speed-bins.
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
---
Changes since RFC v4:
- Removed two DDR3 only timing parameters that were
inadvertently added in the binding
---
.../devicetree/bindings/lpddr2/lpddr2-timings.txt | 52 ++
.../devicetree/bindings/lpddr2/lpddr2.txt | 102
2 files changed, 154 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt
create mode 100644 Documentation/devicetree/bindings/lpddr2/lpddr2.txt
diff --git a/Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt
b/Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt
new file mode 100644
index 000..a48f698
--- /dev/null
+++ b/Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt
@@ -0,0 +1,52 @@
+* AC timing parameters of LPDDR2(JESD209-2) memories for a given speed-bin
+
+Required properties:
+- compatible : Should be jedec,lpddr2-timings
+- min-freq : minimum DDR clock frequency for the speed-bin. Type is u32
+- max-freq : maximum DDR clock frequency for the speed-bin. Type is u32
+
+Optional properties:
+
+The following properties represent AC timing parameters from the memory
+data-sheet of the device for a given speed-bin. All these properties are
+of type u32 and the default unit is ps (pico seconds). Parameters with
+a different unit have a suffix indicating the unit such as 'tRAS-max-ns'
+- tRCD
+- tWR
+- tRAS-min
+- tRRD
+- tWTR
+- tXP
+- tRTP
+- tDQSCK-max
+- tFAW
+- tZQCS
+- tZQinit
+- tRPab
+- tZQCL
+- tCKESR
+- tRAS-max-ns
+- tDQSCK-max-derated
+
+Example:
+
+timings_elpida_ECB240ABACN_400mhz: lpddr2-timings@0 {
+ compatible = jedec,lpddr2-timings;
+ min-freq= 1000;
+ max-freq= 4;
+ tRPab = 21000;
+ tRCD= 18000;
+ tWR = 15000;
+ tRAS-min= 42000;
+ tRRD= 1;
+ tWTR= 7500;
+ tXP = 7500;
+ tRTP= 7500;
+ tCKESR = 15000;
+ tDQSCK-max = 5500;
+ tFAW= 5;
+ tZQCS = 9;
+ tZQCL = 36;
+ tZQinit = 100;
+ tRAS-max-ns = 7;
+};
diff --git a/Documentation/devicetree/bindings/lpddr2/lpddr2.txt
b/Documentation/devicetree/bindings/lpddr2/lpddr2.txt
new file mode 100644
index 000..a2ab203
--- /dev/null
+++ b/Documentation/devicetree/bindings/lpddr2/lpddr2.txt
@@ -0,0 +1,102 @@
+* LPDDR2 SDRAM memories compliant to JEDEC JESD209-2
+
+Required properties:
+- compatible : Should be one of - jedec,lpddr2-nvm, jedec,lpddr2-s2,
+ jedec,lpddr2-s4
+
+ ti,jedec-lpddr2-s2 should be listed if the memory part is LPDDR2-S2 type
+
+ ti,jedec-lpddr2-s4 should be listed if the memory part is LPDDR2-S4 type
+
+ ti,jedec-lpddr2-nvm should be listed if the memory part is LPDDR2-NVM type
+
+- density : u32 representing density in Mb (Mega bits)
+
+- io-width : u32 representing bus width. Possible values are 8, 16, and 32
+
+Optional properties:
+
+The following optional properties represent the minimum value of some AC
+timing parameters of the DDR device in terms of number of clock cycles.
+These values shall be obtained from the device data-sheet.
+- tRRD-min-tck
+- tWTR-min-tck
+- tXP-min-tck
+- tRTP-min-tck
+- tCKE-min-tck
+- tRPab-min-tck
+- tRCD-min-tck
+- tWR-min-tck
+- tRASmin-min-tck
+- tCKESR-min-tck
+- tFAW-min-tck
+
+Child nodes:
+- The lpddr2 node may have one or more child nodes of type lpddr2-timings.
+ lpddr2-timings provides AC timing parameters of the device for
+ a given speed-bin. The user may provide the timings for as many
+ speed-bins as is required. Please see Documentation/devicetree/
+ bindings/lpddr2/lpddr2-timings.txt for more information on lpddr2-timings
+
+Example:
+
+elpida_ECB240ABACN : lpddr2 {
+ compatible = Elpida,ECB240ABACN,jedec,lpddr2-s4;
+ density = 2048;
+ io-width= 32;
+
+ tRPab-min-tck = 3;
+ tRCD-min-tck= 3;
+ tWR-min-tck = 3;
+ tRASmin-min-tck = 3;
+ tRRD-min-tck= 2;
+ tWTR-min-tck= 2;
+ tXP-min-tck = 2;
+ tRTP-min-tck= 2;
+ tCKE-min-tck= 3;
+ tCKESR-min-tck = 3;
+ tFAW-min-tck= 8;
+
+ timings_elpida_ECB240ABACN_400mhz: lpddr2-timings@0 {
+ compatible = jedec,lpddr2-timings;
+ min-freq= 1000;
+ max-freq= 4;
+ tRPab = 21000;
+ tRCD= 18000;
+ tWR = 15000;
+ tRAS-min= 42000;
+
[PATCH 2/4] dt: emif: device tree bindings for TI's EMIF sdram controller
EMIF - External Memory Interface - is an SDRAM controller used in
TI SoCs. EMIF supports, based on the IP revision, one or more of
DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance
of the EMIF IP and memory parts attached to it.
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
---
Changes sice RFC v4:
- None
---
.../bindings/memory-controllers/ti/emif.txt| 55
1 files changed, 55 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
diff --git a/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
new file mode 100644
index 000..938f8e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
@@ -0,0 +1,55 @@
+* EMIF family of TI SDRAM controllers
+
+EMIF - External Memory Interface - is an SDRAM controller used in
+TI SoCs. EMIF supports, based on the IP revision, one or more of
+DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance
+of the EMIF IP and memory parts attached to it.
+
+Required properties:
+- compatible : Should be of the form ti,emif-ip-rev where ip-rev
+ is the IP revision of the specific EMIF instance.
+
+- phy-type : u32 indicating the DDR phy type. Following are the
+ allowed values
+ 1 : Attila PHY
+ 2 : Intelli PHY
+
+- device-handle: phandle to a lpddr2 node representing the memory
part
+
+- ti,hwmods: For TI hwmods processing and omap device creation
+ the value shall be emifn where n is the number of the EMIF
+ instance with base 1.
+
+Optional properties:
+- cs1-used : Have this property if CS1 of this EMIF
+ instance has a memory part attached to it. If there is a memory
+ part attached to CS1, it should be the same type as the one on CS0,
+ so there is no need to give the details of this memory part.
+
+- cal-resistor-per-cs : Have this property if the board has one
+ calibration resistor per chip-select.
+
+- hw-caps-read-idle-ctrl: Have this property if the controller
+ supports read idle window programming
+
+- hw-caps-dll-calib-ctrl: Have this property if the controller
+ supports dll calibration control
+
+- hw-caps-ll-interface : Have this property if the controller
+ has a low latency interface and corresponding interrupt events
+
+- hw-caps-temp-alert : Have this property if the controller
+ has capability for generating SDRAM temperature alerts
+
+Example:
+
+emif1: emif@0x4c00 {
+ compatible = ti,emif-4d;
+ ti,hwmods = emif2;
+ phy-type= 1;
+ device-handle = elpida_ECB240ABACN;
+ cs1-used;
+ hw-caps-read-idle-ctrl;
+ hw-caps-ll-interface;
+ hw-caps-temp-alert;
+};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] arm: dts: EMIF and LPDDR2 device tree data for OMAP4 boards
Device tree data for the EMIF sdram controllers in OMAP4
and LPDDR2 memory devices attached to OMAP4 boards.
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
---
Changes since RFC v4:
- Removed DDR3 only parameters from
elpida_ecb240abacn.dtsi
---
arch/arm/boot/dts/elpida_ecb240abacn.dtsi | 67 +
arch/arm/boot/dts/omap4-panda.dts | 13 ++
arch/arm/boot/dts/omap4-sdp.dts | 13 ++
arch/arm/boot/dts/omap4.dtsi | 18
4 files changed, 111 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/elpida_ecb240abacn.dtsi
diff --git a/arch/arm/boot/dts/elpida_ecb240abacn.dtsi
b/arch/arm/boot/dts/elpida_ecb240abacn.dtsi
new file mode 100644
index 000..34b9f72
--- /dev/null
+++ b/arch/arm/boot/dts/elpida_ecb240abacn.dtsi
@@ -0,0 +1,67 @@
+/*
+ * Common devices used in different OMAP boards
+ */
+
+/ {
+ elpida_ECB240ABACN: lpddr2 {
+ compatible = Elpida,ECB240ABACN,jedec,lpddr2-s4;
+ density = 2048;
+ io-width= 32;
+
+ tRPab-min-tck = 3;
+ tRCD-min-tck= 3;
+ tWR-min-tck = 3;
+ tRASmin-min-tck = 3;
+ tRRD-min-tck= 2;
+ tWTR-min-tck= 2;
+ tXP-min-tck = 2;
+ tRTP-min-tck= 2;
+ tCKE-min-tck= 3;
+ tCKESR-min-tck = 3;
+ tFAW-min-tck= 8;
+
+ timings_elpida_ECB240ABACN_400mhz: lpddr2-timings@0 {
+ compatible = jedec,lpddr2-timings;
+ min-freq= 1000;
+ max-freq= 4;
+ tRPab = 21000;
+ tRCD= 18000;
+ tWR = 15000;
+ tRAS-min= 42000;
+ tRRD= 1;
+ tWTR= 7500;
+ tXP = 7500;
+ tRTP= 7500;
+ tCKESR = 15000;
+ tDQSCK-max = 5500;
+ tFAW= 5;
+ tZQCS = 9;
+ tZQCL = 36;
+ tZQinit = 100;
+ tRAS-max-ns = 7;
+ tDQSCK-max-derated = 6000;
+ };
+
+ timings_elpida_ECB240ABACN_200mhz: lpddr2-timings@1 {
+ compatible = jedec,lpddr2-timings;
+ min-freq= 1000;
+ max-freq= 2;
+ tRPab = 21000;
+ tRCD= 18000;
+ tWR = 15000;
+ tRAS-min= 42000;
+ tRRD= 1;
+ tWTR= 1;
+ tXP = 7500;
+ tRTP= 7500;
+ tCKESR = 15000;
+ tDQSCK-max = 5500;
+ tFAW= 5;
+ tZQCS = 9;
+ tZQCL = 36;
+ tZQinit = 100;
+ tRAS-max-ns = 7;
+ tDQSCK-max-derated = 6000;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 9755ad5..f548523 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -8,6 +8,7 @@
/dts-v1/;
/include/ omap4.dtsi
+/include/ elpida_ecb240abacn.dtsi
/ {
model = TI OMAP4 PandaBoard;
@@ -17,4 +18,16 @@
device_type = memory;
reg = 0x8000 0x4000; /* 1 GB */
};
+
+ ocp {
+ emif1: emif@0x4c00 {
+ cs1-used;
+ device-handle = elpida_ECB240ABACN;
+ };
+
+ emif2: emif@0x4d00 {
+ cs1-used;
+ device-handle = elpida_ECB240ABACN;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 63c6b2b..6dc08bc 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -8,6 +8,7 @@
/dts-v1/;
/include/ omap4.dtsi
+/include/ elpida_ecb240abacn.dtsi
/ {
model = TI OMAP4 SDP board;
@@ -17,4 +18,16 @@
device_type = memory;
reg = 0x8000 0x4000; /* 1 GB */
};
+
+ ocp {
+ emif1: emif@0x4c00 {
+ cs1-used;
+
[PATCH 4/4] misc: emif: add device tree support to emif driver
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
---
Changes since RFC v4:
- Rebased to the latest version of EMIF series
- Replace kzalloc()/kfree() with devm_* variants
---
drivers/misc/emif.c | 289 ++-
1 files changed, 288 insertions(+), 1 deletions(-)
diff --git a/drivers/misc/emif.c b/drivers/misc/emif.c
index 79fb161..0aaa61e 100644
--- a/drivers/misc/emif.c
+++ b/drivers/misc/emif.c
@@ -18,6 +18,7 @@
#include linux/platform_device.h
#include linux/interrupt.h
#include linux/slab.h
+#include linux/of.h
#include linux/debugfs.h
#include linux/seq_file.h
#include linux/module.h
@@ -49,6 +50,7 @@
* frequency in effect at the moment)
* @plat_data: Pointer to saved platform data.
* @debugfs_root: dentry to the root folder for EMIF in debugfs
+ * @np_ddr:Pointer to ddr device tree node
*/
struct emif_data {
u8 duplicate;
@@ -63,6 +65,9 @@ struct emif_data {
struct emif_regs*curr_regs;
struct emif_platform_data *plat_data;
struct dentry *debugfs_root;
+#if defined(CONFIG_OF)
+ struct device_node *np_ddr;
+#endif
};
static struct emif_data *emif1;
@@ -1147,6 +1152,270 @@ static int is_custom_config_valid(struct
emif_custom_configs *cust_cfgs,
return valid;
}
+#if defined(CONFIG_OF)
+static void __init of_get_custom_configs(struct device_node *np_emif,
+ struct emif_data *emif)
+{
+ struct emif_custom_configs *cust_cfgs = NULL;
+ int len;
+ const int *lpmode, *poll_intvl;
+
+ lpmode = of_get_property(np_emif, low-power-mode, len);
+ poll_intvl = of_get_property(np_emif, temp-alert-poll-interval, len);
+
+ if (lpmode || poll_intvl)
+ cust_cfgs = devm_kzalloc(emif-dev, sizeof(*cust_cfgs),
+ GFP_KERNEL);
+
+ if (!cust_cfgs)
+ return;
+
+ if (lpmode) {
+ cust_cfgs-mask |= EMIF_CUSTOM_CONFIG_LPMODE;
+ cust_cfgs-lpmode = *lpmode;
+ of_property_read_u32(np_emif,
+ low-power-mode-timeout-performance,
+ cust_cfgs-lpmode_timeout_performance);
+ of_property_read_u32(np_emif,
+ low-power-mode-timeout-power,
+ cust_cfgs-lpmode_timeout_power);
+ of_property_read_u32(np_emif,
+ low-power-mode-freq-threshold,
+ cust_cfgs-lpmode_freq_threshold);
+ }
+
+ if (poll_intvl) {
+ cust_cfgs-mask |=
+ EMIF_CUSTOM_CONFIG_TEMP_ALERT_POLL_INTERVAL;
+ cust_cfgs-temp_alert_poll_interval_ms = *poll_intvl;
+ }
+
+ if (!is_custom_config_valid(cust_cfgs, emif-dev)) {
+ devm_kfree(emif-dev, cust_cfgs);
+ return;
+ }
+
+ emif-plat_data-custom_configs = cust_cfgs;
+}
+
+static void __init of_get_min_tck(struct device_node *np,
+ struct emif_data *emif)
+{
+ int ret = 0;
+ struct lpddr2_min_tck *min;
+
+ min = devm_kzalloc(emif-dev, sizeof(*min), GFP_KERNEL);
+ if (!min)
+ goto default_min_tck;
+
+ ret |= of_property_read_u32(np, tRPab-min-tck, min-tRPab);
+ ret |= of_property_read_u32(np, tRCD-min-tck, min-tRCD);
+ ret |= of_property_read_u32(np, tWR-min-tck, min-tWR);
+ ret |= of_property_read_u32(np, tRASmin-min-tck, min-tRASmin);
+ ret |= of_property_read_u32(np, tRRD-min-tck, min-tRRD);
+ ret |= of_property_read_u32(np, tWTR-min-tck, min-tWTR);
+ ret |= of_property_read_u32(np, tXP-min-tck, min-tXP);
+ ret |= of_property_read_u32(np, tRTP-min-tck, min-tRTP);
+ ret |= of_property_read_u32(np, tCKE-min-tck, min-tCKE);
+ ret |= of_property_read_u32(np, tCKESR-min-tck, min-tCKESR);
+ ret |= of_property_read_u32(np, tFAW-min-tck, min-tFAW);
+
+ if (ret) {
+ devm_kfree(emif-dev, min);
+ goto default_min_tck;
+ }
+
+ emif-plat_data-min_tck = min;
+ return;
+
+default_min_tck:
+ dev_warn(emif-dev, %s: using default min-tck values\n, __func__);
+ emif-plat_data-min_tck = lpddr2_min_tck;
+}
+
+static int __init of_do_get_timings(struct device_node *np,
+ struct lpddr2_timings *tim)
+{
+ int ret;
+
+ ret = of_property_read_u32(np, max-freq, tim-max_freq);
+ ret |= of_property_read_u32(np, min-freq, tim-min_freq);
+ ret |= of_property_read_u32(np, tRPab, tim-tRPab);
+ ret |= of_property_read_u32(np, tRCD, tim-tRCD);
+ ret |=
RE: [PATCH-V2 2/2] arm:omap:am33xx: Add power domain data
On Fri, Mar 02, 2012 at 16:16:47, Paul Walmsley wrote: Hi On Fri, 2 Mar 2012, Hiremath, Vaibhav wrote: Paul, Thanks for your review comments, can we also align on the approach, Whether to merge am33xx powerdomain with omap4 (same direction we are now) OR Have separate implementation (my original approach). Could you please take a look at the am335x_prcm_devel_3.4 branch on git://git.pwsan.com/linux-2.6 and let me know what you think? It is still rough, incomplete, and compile-tested only; and the patch commit messages have to be updated and revised; but I think it is a slightly better approach. Paul, Sorry for delayed response, was bit stuck with some baseport thing. I have reviewed the changes from your above branch. And as I mentioned before, it looks closer to my earlier approach + some good and important changes/cleanups. A significant change is that the prminst code changes have been removed. That is only needed when PRM registers are spread across multiple PRCM IP blocks. Make sense actually...I don't know, why didn't thought about this before... This does not appear to be the case with AM33xx? So the implementation has been modified to create a prm33xx.c file instead. This avoids an extra, unnecessary layer of indirection for PRM accesses. This, along with the other differences between OMAP4 and this chip, means that a separate powerdomain33xx.c file had to be created. The powerdomains33xx_data.c file is still missing the bitmask position data, but the structure members are there. Yeah, I understand, I think without this it won't be usefule. I will also get this done in next (aligned) changes. Feel free to combine, rework, or merge this series with what you are working on if you feel that it is a good approach. Otherwise, let's discuss. Thanks, Thanks a lot for your time/support/review, as always its helpful. Thanks, Vaibhav - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] OMAP4: hwmod: add EMIF hw mod data
Hi Aneesh
On 3/8/2012 4:54 PM, Aneesh V wrote:
From: Benoit Coussonb-cous...@ti.com
Add hwmod data for EMIF IP instances in OMAP4.
Paul has just posted an OMAP4 hwmod series (ARM: OMAP4: hwmod data: add
almost all remaining IP blocks) that does contain the EMIF hwmods, so
assuming that you are not adding some custom dev_attr here, it should
work for you.
Regards,
Benoit
Signed-off-by: Benoit Coussonb-cous...@ti.com
---
Changes since RFC:
- Improved commit log
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 110
1 files changed, 110 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index f9f1510..2b107c7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5480,6 +5480,111 @@ static struct omap_hwmod omap44xx_usb_tll_hs_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_usb_tll_hs_slaves),
};
+/*
+ * 'emif' class
+ * external memory interface no1
+ */
+
+static struct omap_hwmod_class omap44xx_emif_hwmod_class = {
+ .name = emif,
+};
+
+/* emif1 */
+static struct omap_hwmod omap44xx_emif1_hwmod;
+static struct omap_hwmod_irq_info omap44xx_emif1_irqs[] = {
+ { .irq = 110 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_addr_space omap44xx_emif1_addrs[] = {
+ {
+ .pa_start = 0x4c00,
+ .pa_end = 0x4cff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* emif_fw - emif1 */
+static struct omap_hwmod_ocp_if omap44xx_emif_fw__emif1 = {
+ .master =omap44xx_emif_fw_hwmod,
+ .slave =omap44xx_emif1_hwmod,
+ .clk= l3_div_ck,
+ .addr = omap44xx_emif1_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* emif1 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_emif1_slaves[] = {
+ omap44xx_emif_fw__emif1,
+};
+
+static struct omap_hwmod omap44xx_emif1_hwmod = {
+ .name = emif1,
+ .class =omap44xx_emif_hwmod_class,
+ .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+ .mpu_irqs = omap44xx_emif1_irqs,
+ .main_clk = emif1_fck,
+ .clkdm_name = l3_emif_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_MEMIF_EMIF_1_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_MEMIF_EMIF_1_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .slaves = omap44xx_emif1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_emif1_slaves),
+};
+
+/* emif2 */
+static struct omap_hwmod omap44xx_emif2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_emif2_irqs[] = {
+ { .irq = 111 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_addr_space omap44xx_emif2_addrs[] = {
+ {
+ .pa_start = 0x4d00,
+ .pa_end = 0x4dff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* emif_fw - emif2 */
+static struct omap_hwmod_ocp_if omap44xx_emif_fw__emif2 = {
+ .master =omap44xx_emif_fw_hwmod,
+ .slave =omap44xx_emif2_hwmod,
+ .clk= l3_div_ck,
+ .addr = omap44xx_emif2_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* emif2 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_emif2_slaves[] = {
+ omap44xx_emif_fw__emif2,
+};
+
+static struct omap_hwmod omap44xx_emif2_hwmod = {
+ .name = emif2,
+ .class =omap44xx_emif_hwmod_class,
+ .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+ .mpu_irqs = omap44xx_emif2_irqs,
+ .main_clk = emif2_fck,
+ .clkdm_name = l3_emif_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_MEMIF_EMIF_1_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_MEMIF_EMIF_1_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ }
+ },
+ .slaves = omap44xx_emif2_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_emif2_slaves),
+};
+
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
@@ -5629,6 +5734,11 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] =
{
/* wd_timer class */
omap44xx_wd_timer2_hwmod,
omap44xx_wd_timer3_hwmod,
+
+ /* emif class */
+ omap44xx_emif1_hwmod,
+ omap44xx_emif2_hwmod,
+
NULL,
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH 1/8] OMAP4: hwmod: add EMIF hw mod data
On Thursday 08 March 2012 10:11 PM, Cousson, Benoit wrote: Hi Aneesh On 3/8/2012 4:54 PM, Aneesh V wrote: From: Benoit Coussonb-cous...@ti.com Add hwmod data for EMIF IP instances in OMAP4. Paul has just posted an OMAP4 hwmod series (ARM: OMAP4: hwmod data: add almost all remaining IP blocks) that does contain the EMIF hwmods, so assuming that you are not adding some custom dev_attr here, it should work for you. Ok. I will test with that tomorrow and drop this patch. Thanks, Aneesh -- 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 00/15] ARM: OMAP4: hwmod data: add almost all remaining IP blocks
Hi Rajendra, On Thu, 8 Mar 2012, Rajendra Nayak wrote: On Thursday 08 March 2012 04:21 PM, Paul Walmsley wrote: These patches are also available via git from git://git.pwsan.com/linux-2.6 in the branch hwmod_enable_remaining_hwmods_devel_3.4. Could not find this branch on your tree. Found a 'enable_remaining_omap4_hwmods' instead, but that seems to be an old branch. Sorry about that. It should be pushed now. - 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
[GIT PULL] few more fixes for v3.3-rc6
Hi Arnd Olof, Here are few more fixes for the current -rc cycle if there's still enough time to get them in. Regards, Tony The following changes since commit 192cfd58774b4d17b2fe8bdc77d89c2ef4e0591d: Linus Torvalds (1): Linux 3.3-rc6 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes Cousson, Benoit (1): ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts R Sricharan (1): ARM: OMAP2+: Fix module build errors with CONFIG_OMAP4_ERRATA_I688 Rajendra Nayak (1): ARM: OMAP2+: Remove apply_uV constraints for fixed regulator Vaibhav Hiremath (1): ARM: OMAP: id: Add missing break statement in omap3xxx_check_revision arch/arm/mach-omap2/id.c |1 + arch/arm/mach-omap2/omap4-common.c |2 ++ arch/arm/mach-omap2/twl-common.c |1 - arch/arm/plat-omap/include/plat/irqs.h | 10 +- 4 files changed, 12 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: PM: core support for SMPS regulators for v3.4
Tony Lindgren t...@atomide.com writes: * Kevin Hilman khil...@ti.com [120307 11:42]: Tony, Please pull the following support for using regulators to control the on-chip VC/VP managed voltage domains. The regulator driver support for this is already queued in the regulator tree, and this is the supporting core work. This combined with the CPUfreq changes to use the regulator framework will finally result in MPU DVFS working in mainline. Nice.. However this one might be missing some header changes? Oh, that's because it depends on the regulator core changes that are in Mark's regulator tree. You need the for-next branch of : git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git For this to compile correctly. Sorry, I should've been more clear above about the build dependency. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] few more fixes for v3.3-rc6
Olof,
* Tony Lindgren t...@atomide.com [120308 09:34]:
Vaibhav Hiremath (1):
ARM: OMAP: id: Add missing break statement in omap3xxx_check_revision
FYI, this one will cause a minor merge conflict with what's in
arm-soc/for-next, here's how to resolve for reference:
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@@ -397,7 -342,8 +397,8 @@@ void __init omap3xxx_check_revision(voi
break;
case 0xb944:
omap_revision = AM335X_REV_ES1_0;
- *cpu_rev = 1.0;
+ cpu_rev = 1.0;
+ break;
case 0xb8f2:
switch (rev) {
case 0:
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 0/2] ARM: OMAP2+: PM: code consolidation for 3.4
Hi Luciano, On Thu, 8 Mar 2012, Coelho, Luciano wrote: I can't get ttyO2 wakeup to work on my Blaze with 3.3-rc5. It works fine with 3.2. I've been trying to bisect and everything, but it's difficult. To start with, during my bisect, many patches seem to be in a state where the compilation fails (one example is 'OMAP44XX_IRQ_PRCM' undeclared). Anyway, what I found out is that after fcf6efa3 (ARM: OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn) wakeup from the console doesn't work anymore for me. Then I tried to comment out the omap_wakeupgen_init() call in gic_init_irq() and that seems to work... for a while. At least until ff819da4 (ARM: OMAP3: CPUidle: Make use of CPU PM notifiers) commenting out that line seems to work. But it doesn't work if I comment out the line with v3.3-rc5. Maybe try this patch: http://www.spinics.net/lists/linux-omap/msg65786.html If that doesn't work, could you try to reproduce with omap2plus_defconfig and a boring kernel command line? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: OMAP2+: PM: code consolidation for 3.4
Hi Luca, Coelho, Luciano coe...@ti.com writes: [...] I can't get ttyO2 wakeup to work on my Blaze with 3.3-rc5. It works fine with 3.2. I assume you mean wakeup from system-wide suspend (echo mem /sys/power/state)? Are you enabling UART wakeups? They are disabled by default, so you need to: echo enabled /sys/devices/platform/omap/omap_uart.2/tty/ttyO2/power/wakeup It may work in v3.2 due to the fact that the UART runtime PM had the unintended side-effect of essentially disabling MPU and CORE PM. With that bug fixed and MPU CORE actually hitting low power states, you'll need to ensure UART wakeups are enabled. If you're already enabling wakeups and this still isn't working, try adding 'no_console_suspend' to the kernel cmdline, try a suspend/resume and post the console output. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap_hsmmc: Fix Unbalanced pm_runtime_enable warning
Chris, On 03/05/2012 04:09 PM, Kevin Hilman wrote: Tony Lindgrent...@atomide.com writes: mmc: omap_hsmmc: Fix Unbalanced pm_runtime_enable warning Otherwise we can get following warning when re-loading the omap_hsmmc driver module when gpio_twl4030 module is not loaded: omap_hsmmc omap_hsmmc.0: Unbalanced pm_runtime_enable! omap_hsmmc omap_hsmmc.0: Unable to grab MMC CD IRQ omap_hsmmc: probe of omap_hsmmc.0 failed with error -22 Signed-off-by: Tony Lindgrent...@atomide.com --- Kevin, maybe take a look and see if this is correct and fits into your PM branches? Looks right to me: Acked-by: Kevin Hilmankhil...@ti.com But this is a fix to the driver itself, so Chris should queue this in mmc-next. Chris, can you take this one? just checking on this to be sure it can make it for v3.4. 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 0/2] ARM: OMAP2+: PM: code consolidation for 3.4
On Thu, 2012-03-08 at 10:27 -0800, Kevin Hilman wrote: Hi Luca, Hey Kevin, Thanks for your reply! :) Coelho, Luciano coe...@ti.com writes: [...] I can't get ttyO2 wakeup to work on my Blaze with 3.3-rc5. It works fine with 3.2. I assume you mean wakeup from system-wide suspend (echo mem /sys/power/state)? Yes, that's what I meant. Are you enabling UART wakeups? They are disabled by default, so you need to: echo enabled /sys/devices/platform/omap/omap_uart.2/tty/ttyO2/power/wakeup No, I was actually not enabling the UART wakeups. But I tried it now but it still doesn't work. :( It may work in v3.2 due to the fact that the UART runtime PM had the unintended side-effect of essentially disabling MPU and CORE PM. With that bug fixed and MPU CORE actually hitting low power states, you'll need to ensure UART wakeups are enabled. If you're already enabling wakeups and this still isn't working, try adding 'no_console_suspend' to the kernel cmdline, try a suspend/resume and post the console output. I have no_console_suspend in bootargs. Without it, it didn't work with 3.2 either. This is what I get when I suspend with echo mem /sys/power/state: [ 128.534271] PM: Syncing filesystems ... done. [ 129.948364] PM: Preparing system for mem sleep [ 129.957061] Freezing user space processes ... [ 129.961761] BUG: sleeping function called from invalid context at include/linux/freezer.h:46 [ 129.969177] in_atomic(): 0, irqs_disabled(): 128, pid: 770, name: udevd [ 129.977813] INFO: lockdep is turned off. [ 129.977813] irq event stamp: 0 [ 129.985168] hardirqs last enabled at (0): [ (null)] (null) [ 129.991485] hardirqs last disabled at (0): [c004233c] copy_process+0x3ec/0x1050 [ 129.996520] softirqs last enabled at (0): [c004233c] copy_process+0x3ec/0x1050 [ 130.005218] softirqs last disabled at (0): [ (null)] (null) [ 130.011291] [c001e204] (unwind_backtrace+0x0/0x148) from [c0502fdc] (dump_stack+0x20/0x24) [ 130.018829] [c0502fdc] (dump_stack+0x20/0x24) from [c00779d0] (__might_sleep+0x130/0x134) [ 130.030670] [c00779d0] (__might_sleep+0x130/0x134) from [c0018998] (do_signal+0x54/0x600) [ 130.031738] [c0018998] (do_signal+0x54/0x600) from [c0018fa4] (do_notify_resume+0x60/0x6c) [ 130.049804] [c0018fa4] (do_notify_resume+0x60/0x6c) from [c00154e4] (work_pending+0x24/0x28) [ 130.067138] (elapsed 0.10 seconds) done. [ 130.070648] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 130.101165] PM: Entering mem sleep [ 130.120056] PM: suspend of devices complete after 9.646 msecs [ 130.127716] PM: late suspend of devices complete after 7.662 msecs [ 130.134246] Disabling non-boot CPUs ... [ 130.139953] CPU1: shutdown The sleeping function BUG is that known bug I already complained about some time ago. I get it all the time and, in general, it doesn't really hurt (I guess I'm lucky most of the times not to hit a race-condition). -- Cheers, Luca. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: Fix build for omap4 only builds with missing include of linux/bug.h
Found few more with randconfig generated .configs: In file included from arch/arm/mach-omap2/prm-regbits-34xx.h:17, from arch/arm/mach-omap2/vc.c:18: arch/arm/mach-omap2/prm2xxx_3xxx.h: In function ‘omap2_prm_read_mod_reg’: arch/arm/mach-omap2/prm2xxx_3xxx.h:239: error: implicit declaration of function ‘WARN’ In file included from arch/arm/mach-omap2/powerdomain44xx.c:22: arch/arm/mach-omap2/prm2xxx_3xxx.h: In function ‘omap2_prm_read_mod_reg’: arch/arm/mach-omap2/prm2xxx_3xxx.h:239: error: implicit declaration of function ‘WARN’ This is because omap2_prm functions are currently just stubs for omap4 only builds. Signed-off-by: Tony Lindgren t...@atomide.com --- a/arch/arm/mach-omap2/powerdomain44xx.c +++ b/arch/arm/mach-omap2/powerdomain44xx.c @@ -15,6 +15,7 @@ #include linux/io.h #include linux/errno.h #include linux/delay.h +#include linux/bug.h #include powerdomain.h #include plat/prcm.h --- a/arch/arm/mach-omap2/vc.c +++ b/arch/arm/mach-omap2/vc.c @@ -10,6 +10,7 @@ #include linux/kernel.h #include linux/delay.h #include linux/init.h +#include linux/bug.h #include plat/cpu.h -- 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: [BUG] Compile error with CONFIG_SND_OMAP_SOC_OMAP4_HDMI
Hi Alex, On Thu, 2012-03-08 at 15:08 +0100, Alexander Graf wrote: Hi list, Trying to compile 3.3-rc6 with the following option combination fails: CONFIG_SND_OMAP_SOC_OMAP4_HDMI=m CONFIG_SND_OMAP_SOC_HDMI=m CONFIG_OMAP2_DSS=y drivers/built-in.o: In function `omapdss_hdmihw_remove': /home/abuild/rpmbuild/BUILD/kernel-omap2plus-3.3.rc6/linux-3.3-rc6/drivers/video/omap2/dss/hdmi.c:879: undefined reference to `snd_soc_unregister_codec' drivers/built-in.o: In function `omapdss_hdmihw_probe': /home/abuild/rpmbuild/BUILD/kernel-omap2plus-3.3.rc6/linux-3.3-rc6/drivers/video/omap2/dss/hdmi.c:863: undefined reference to `snd_soc_register_codec' However, we do want to have DSS compiled into the kernel to ensure that graphics are available, but since audio is not quite as crucial for debugging, that one should live as a module. According to Takashi, it shouldn't be all that hard to split the HDMI audio code from dss/hdmi.c, but I'm currently lacking the time to do so. If anyone's interested in picking it up, I'd very much appreciate it! I have started working on moving the HDMI audio part to /sound (http://www.spinics.net/lists/linux-omap/msg64477.html) and the relocation discussion has lead to proposing an interface to provide funtionality in DSS for displays that support audio (DisplayPort and HDMI, atm, http://www.spinics.net/lists/linux-omap/msg64744.html). I am about to send a set of patches to DSS for this and then have the audio driver use the proposed DSS functionality. Thanks a lot, Alex -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: OMAP2+: PM: code consolidation for 3.4
On Thu, 8 Mar 2012, Luciano Coelho wrote: On Thu, 2012-03-08 at 10:27 -0800, Kevin Hilman wrote: Are you enabling UART wakeups? They are disabled by default, so you need to: echo enabled /sys/devices/platform/omap/omap_uart.2/tty/ttyO2/power/wakeup No, I was actually not enabling the UART wakeups. But I tried it now but it still doesn't work. :( You definitely need that. I have no_console_suspend in bootargs. Without it, it didn't work with 3.2 either. If you want to use no_console_suspend -- which is not recommended -- then you'll need http://www.spinics.net/lists/linux-omap/msg65786.html but best simply not to use no_console_suspend. - 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: [GIT PULL] few more fixes for v3.3-rc6
On Thu, Mar 8, 2012 at 10:04 AM, Tony Lindgren t...@atomide.com wrote: Hi Arnd Olof, Here are few more fixes for the current -rc cycle if there's still enough time to get them in. Regards, Tony The following changes since commit 192cfd58774b4d17b2fe8bdc77d89c2ef4e0591d: Linus Torvalds (1): Linux 3.3-rc6 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes Pulled, thanks. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: Fix compile error when FB_OMAP2 is not set
Otherwise we will get:
arch/arm/plat-omap/fb.c:101: error: expected ‘)’ before ‘*’ token
Signed-off-by: Tony Lindgren t...@atomide.com
---
Tomi, you need something like this for what you have in for-next.
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -98,6 +98,8 @@ arch_initcall(omap_init_fb);
#else
-void __init omapfb_set_lcd_config(omap_lcd_config *config) { }
+void __init omapfb_set_lcd_config(const struct omap_lcd_config *config)
+{
+}
#endif
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Fix compile error when FB_OMAP2 is not set
* Tony Lindgren t...@atomide.com [120308 12:11]:
Otherwise we will get:
arch/arm/plat-omap/fb.c:101: error: expected ‘)’ before ‘*’ token
Signed-off-by: Tony Lindgren t...@atomide.com
---
Tomi, you need something like this for what you have in for-next.
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -98,6 +98,8 @@ arch_initcall(omap_init_fb);
#else
-void __init omapfb_set_lcd_config(omap_lcd_config *config) { }
+void __init omapfb_set_lcd_config(const struct omap_lcd_config *config)
+{
+}
#endif
Also now seeing the following with what you have in for-next:
drivers/video/omap2/displays/panel-taal.c: In function ‘taal_num_errors_show’:
drivers/video/omap2/displays/panel-taal.c:605: warning: ‘errors’ may be used
uninitialized in this function
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
[GIT PULL 1/7] non-critical fixes part3 for upcoming merge window
Hi Olof, Here are two more pre-emptive fixes for upcoming merge window to pull into arm-soc/next/fixes-non-critical. Now with the fixes finallny out of the way after all the cleanup related changes, as a reply to this pull request I'm posting some more pull requests for cleanup and some minor board changes. Regards, Tony The following changes since commit 9cf793f9b8b1ba9414e2a7591b2e911885f85a27: Kevin Hilman (1): ARM: OMAP: convert omap_device_build() and callers to __init are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes-non-critical-part3 Tony Lindgren (2): ARM: OMAP2+: Fix section warnings for hsmmc_init_one ARM: OMAP2+: Fix build for omap4 only builds with missing include of linux/bug.h arch/arm/mach-omap2/hsmmc.c |2 +- arch/arm/mach-omap2/powerdomain44xx.c |1 + arch/arm/mach-omap2/vc.c |1 + 3 files changed, 3 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] Add TI EMIF SDRAM controller driver
On Thu, Mar 08, 2012 at 09:24:17PM +0530, Aneesh V wrote: Add a driver for the EMIF SDRAM controller used in TI SoCs EMIF is an SDRAM controller that supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support for LPDDR2. The driver supports the following features: - Calculates the DDR AC timing parameters to be set in EMIF registers using data from the device data-sheets and based on the DDR frequency. If data from data-sheets is not available default timing values from the JEDEC spec are used. These will be safe, but not necessarily optimal - API for changing timings during DVFS or at boot-up - Temperature alert configuration and handling of temperature alerts, if any for LPDDR2 devices * temperature alert is based on periodic polling of MR4 mode register in DDR devices automatically performed by hardware * timings are de-rated and brought back to nominal when temperature raises and falls respectively - Cache of calculated register values to avoid re-calculating them The driver will need some minor updates when it is eventually integrated with Dynamic Voltage and Frequency Scaling (DVFS). This can not be done now as DVFS support is not available in the mainline yet. What will need to be updated in it? The userspace interface or something else? Why not wait until that code is accepted, it should be going into 3.4, right? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
* Kevin Hilman khil...@ti.com [120307 11:05]: I don't think the second smsc911x on the Overo, smsc911x.1, would find it due to the dev_id. It's not about finding the second regulator. As stated in the changelog, it's about the duplicate attempt to register the exact same platform_device. Duplicate attempts to register the exact same platform_device cause kobject to panic and give up[1]. So, any platform that calls gpmc_smsc911x_init() twice (Overo and T35 in mainline) will panic on boot. This patch fixes those platforms so they can boot. Yeah but I guess the second smsc911x instance still would not work, or am I missing something? 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 1/3] ARM: OMAP2+: McBSP: Correct CLKR/FSR clock source mux configuration
* Peter Ujfalusi peter.ujfal...@ti.com [120308 00:50]: On OMAP2/3 McBSP1 port has 6 pin setup, while on OMAP4 the port is McBSP4. Implement the CLKR/FSR clock mux selection for OMAP4, and make sure that we add the correct callback for the correct port across supported OMAP versions. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: OMAP2+: PM: code consolidation for 3.4
Luciano Coelho coe...@ti.com writes: [...] Thanks, Paul! I was just chatting with Kevin about this on IRC. With your patch and no_console_suspend, it works. :) Just FYI... I've queued this patch from Paul and it's now queued by Tony for v3.4 in his cleanup-pm branch. 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 v3] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
Tony Lindgren t...@atomide.com writes: * Kevin Hilman khil...@ti.com [120307 11:05]: I don't think the second smsc911x on the Overo, smsc911x.1, would find it due to the dev_id. It's not about finding the second regulator. As stated in the changelog, it's about the duplicate attempt to register the exact same platform_device. Duplicate attempts to register the exact same platform_device cause kobject to panic and give up[1]. So, any platform that calls gpmc_smsc911x_init() twice (Overo and T35 in mainline) will panic on boot. This patch fixes those platforms so they can boot. Yeah but I guess the second smsc911x instance still would not work, or am I missing something? I don't know since my Overo expansion boards don't have a 2nd NIC, but I suspect you're right. However, my fix isn't addressing that. I am fixing a problem where mainline today will panic on some boards due to duplicate registration. If the 2nd interface doesn't work, then the original patch that added the regulators needs a rethink. My patch to prevent the panic() is needed for mainline. 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 0/8] Add TI EMIF SDRAM controller driver
On Thu, 8 Mar 2012, Greg KH wrote: On Thu, Mar 08, 2012 at 09:24:17PM +0530, Aneesh V wrote: The driver will need some minor updates when it is eventually integrated with Dynamic Voltage and Frequency Scaling (DVFS). This can not be done now as DVFS support is not available in the mainline yet. What will need to be updated in it? The userspace interface or something else? Why not wait until that code is accepted, it should be going into 3.4, right? DVFS for the ARM cores is going in for 3.4 - that's not what Aneesh is referring to. The changes here pertain to DVFS for core devices. Core devices include the EMIF as well as several other devices. Core DVFS is much more challenging to implement cleanly. It has clock framework and driver dependencies. So it probably won't be ready for several months at the very least. - 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: [BUG] Compile error with CONFIG_SND_OMAP_SOC_OMAP4_HDMI
On 08.03.2012, at 19:49, Ricardo Neri ricardo.n...@ti.com wrote: Hi Alex, On Thu, 2012-03-08 at 15:08 +0100, Alexander Graf wrote: Hi list, Trying to compile 3.3-rc6 with the following option combination fails: CONFIG_SND_OMAP_SOC_OMAP4_HDMI=m CONFIG_SND_OMAP_SOC_HDMI=m CONFIG_OMAP2_DSS=y drivers/built-in.o: In function `omapdss_hdmihw_remove': /home/abuild/rpmbuild/BUILD/kernel-omap2plus-3.3.rc6/linux-3.3-rc6/drivers/video/omap2/dss/hdmi.c:879: undefined reference to `snd_soc_unregister_codec' drivers/built-in.o: In function `omapdss_hdmihw_probe': /home/abuild/rpmbuild/BUILD/kernel-omap2plus-3.3.rc6/linux-3.3-rc6/drivers/video/omap2/dss/hdmi.c:863: undefined reference to `snd_soc_register_codec' However, we do want to have DSS compiled into the kernel to ensure that graphics are available, but since audio is not quite as crucial for debugging, that one should live as a module. According to Takashi, it shouldn't be all that hard to split the HDMI audio code from dss/hdmi.c, but I'm currently lacking the time to do so. If anyone's interested in picking it up, I'd very much appreciate it! I have started working on moving the HDMI audio part to /sound (http://www.spinics.net/lists/linux-omap/msg64477.html) and the relocation discussion has lead to proposing an interface to provide funtionality in DSS for displays that support audio (DisplayPort and HDMI, atm, http://www.spinics.net/lists/linux-omap/msg64744.html). I am about to send a set of patches to DSS for this and then have the audio driver use the proposed DSS functionality. Ah, very cool! Thanks a lot for working on that :). Please let me know when that hits mainline, so I can enable HDMI audio output in openSUSE again :) Alex -- 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
