Re: [PATCH 00/26] DSS device model change
On 2013-03-26 19:10, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [130326 06:38]: Hi, To make it possible to add DT support to DSS, and later use the Common Display Framework, we need to change the DSS device model. We currently have a custom dss bus, and omap_dss_devices on that bus, and the aim is to get rid of that bus. The panel devices will be converted occording to the control bus of the panel. For many panels this means that the panel device will become a platform_device. For some, it means the panel devices become i2c or spi devices. This series takes the first step toward that goal. This series: * Converts DPI, HDMI and DSI outputs to work with new style panels * Converts TFP410, Taal and generic-dpi panels to new model * Converts Panda, 4430SDP and Overo boards to use the new panels The non-converted outputs and panels still work, so they can be converted in stages. This is nice, it removes a merge dependency between ARM code and the driver :) Yes. It does give me a few more gray hairs, though =). It'd be so much easier to have all related changes in one clean patch series. Note about board files: I only convert a few board files here for example. I have a branch with board file changes for all the affected board files. I did not include them as they are more or less identical. If this series looks good, I will create an independent branch for the arch/arm stuff, so it can be pulled separately. Great looks good to me thanks. To make the DSS work properly after this device model change, we also need to solve the problem related to multiple display devices on the same video bus. Did the approach I suggested in http://permalink.gmane.org/gmane.linux.ports.arm.omap/96039 look ok? Overo is the most complex one, I think the rest of the boards that require changes have just LCD and DVI that conflict. But it still means we'll have that kind of choice Kconfig option for all those boards. Tomi signature.asc Description: OpenPGP digital signature
RE: [PATCH] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Tuesday, March 26, 2013 11:43 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Tony Lindgren Subject: Re: [PATCH] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock On Mon, 25 Mar 2013, Vaibhav Hiremath wrote: During common-clock migration, .clkdm_name field got missed for clkdiv32k_ick clock, which leaves clk_24mhz_clkdm unused; so boot process will try to disable the clockdomain even childs of this clock is enabled, which keeps child modules in idle mode. Looks fine to me. You're planning to update the patch description, right? So should I wait until you repost it? Yeup, will submit today. Also you should probably trim the crash log after [2.626025] LR is at clk_enable+0x30/0x3c Ok, 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/8] drm/omap: Make fixed resolution panels work
On 2013-03-26 15:45, Archit Taneja wrote:
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel
driver
has these ops or not, and that leads to a crash.
The following things are done to make fixed panels work:
- The omap_connector's detect function is modified such that it considers
panel
types which are generally fixed panels as always connected(provided the
panel
driver doesn't have a detect op). Hence, the connector corresponding to
these
panels is always in a 'connected' state.
- If a panel driver doesn't have a check_timings op, assume that it supports
the
mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper
function)
- The function omap_encoder_update shouldn't really do anything for fixed
resolution panels, make sure that it calls set_timings only if the panel
driver has one.
Signed-off-by: Archit Taneja arc...@ti.com
---
v3: clear the timings local variable first before using memcmp
v2: make sure the timings we try to set for a fixed resolution panel match the
panel's timings
drivers/gpu/drm/omapdrm/omap_connector.c | 27 +--
drivers/gpu/drm/omapdrm/omap_encoder.c | 17 +++--
2 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
b/drivers/gpu/drm/omapdrm/omap_connector.c
index c451c41..912759d 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -110,6 +110,11 @@ static enum drm_connector_status omap_connector_detect(
ret = connector_status_connected;
else
ret = connector_status_disconnected;
+ } else if (dssdev-type == OMAP_DISPLAY_TYPE_DPI ||
+ dssdev-type == OMAP_DISPLAY_TYPE_DBI ||
+ dssdev-type == OMAP_DISPLAY_TYPE_SDI ||
+ dssdev-type == OMAP_DISPLAY_TYPE_DSI) {
+ ret = connector_status_connected;
} else {
ret = connector_status_unknown;
}
Can we leave this part out? I don't like hardcoding things like that,
and if I'm not mistaken, this only affects VENC.
If the code above would use detect where available, and presume the
panel is connected in other cases, it'll be right for all other displays
but VENC, for which we have no connect information.
Or, there could be a special case for VENC, like above, which sets the
connector status to unknown for that. And connected for all others. It'd
still be hardcoded, but for much less cases.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v2 5/8] omapdss: DISPC: add max pixel clock limits for LCD and TV managers
On 2013-03-26 15:45, Archit Taneja wrote:
Each version of OMAP has a limitation on the maximum pixel clock frequency
supported by an overlay manager. This limit isn't checked by omapdss. Add
dispc feats for lcd and tv managers and check whether the target timings can
be supported or not.
The pixel clock limitations are actually more complex. They depend on which
OPP
OMAP is in, and they also depend on which encoder is the manager connected to.
The OPP dependence is ignored as DSS forces the PM framework to be on OPP100
when DSS is enabled, and the encoder dependencies are ignored by DISPC for
now.
These limits should come from the encoder driver.
The OMAP2 TRM doesn't mention the maximum pixel clock limit. This value is
left
as half of DSS_FCLK, as OMAP2 requires the PCD to be atleast 2.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 8cfa27b..73a730a 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -69,6 +69,8 @@ struct dispc_features {
u8 mgr_height_start;
u16 mgr_width_max;
u16 mgr_height_max;
+ unsigned long max_lcd_pclk;
+ unsigned long max_tv_pclk;
int (*calc_scaling) (unsigned long pclk, unsigned long lclk,
const struct omap_video_timings *mgr_timings,
u16 width, u16 height, u16 out_width, u16 out_height,
@@ -2825,6 +2827,15 @@ static bool _dispc_lcd_timings_ok(int hsw, int hfp,
int hbp,
return true;
}
+static bool _dispc_mgr_pclk_ok(enum omap_channel channel,
+ unsigned long pclk)
+{
+ if (dss_mgr_is_lcd(channel))
+ return pclk = dispc.feat-max_lcd_pclk ? true : false;
+ else
+ return pclk = dispc.feat-max_tv_pclk ? true : false;
+}
+
bool dispc_mgr_timings_ok(enum omap_channel channel,
const struct omap_video_timings *timings)
{
@@ -2832,11 +2843,13 @@ bool dispc_mgr_timings_ok(enum omap_channel channel,
timings_ok = _dispc_mgr_size_ok(timings-x_res, timings-y_res);
- if (dss_mgr_is_lcd(channel))
- timings_ok = timings_ok _dispc_lcd_timings_ok(timings-hsw,
- timings-hfp, timings-hbp,
- timings-vsw, timings-vfp,
- timings-vbp);
+ timings_ok = _dispc_mgr_pclk_ok(channel, timings-pixel_clock * 1000);
+
+ if (dss_mgr_is_lcd(channel)) {
+ timings_ok = _dispc_lcd_timings_ok(timings-hsw, timings-hfp,
+ timings-hbp, timings-vsw, timings-vfp,
+ timings-vbp);
+ }
return timings_ok;
}
@@ -3491,6 +3504,7 @@ static const struct dispc_features omap24xx_dispc_feats
__initconst = {
.mgr_height_start = 26,
.mgr_width_max = 2048,
.mgr_height_max = 2048,
+ .max_lcd_pclk = 6650,
.calc_scaling = dispc_ovl_calc_scaling_24xx,
.calc_core_clk = calc_core_clk_24xx,
.num_fifos = 3,
OMAP2 has VENC output, but there's no max_tv_pclk above. This would make
VENC pclk check to fail always, wouldn't it?
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v2 6/8] omapdss: Features: Fix some parameter ranges
On 2013-03-26 15:45, Archit Taneja wrote:
Increase the DSS_FCLK and DSI_FCLK max supported frequencies, these come
because
some frequencies were increased from OMAP5 ES1 to OMAP5 ES2. We support only
OMAP5 ES2 in the kernel, so replace the ES1 values with ES2 values. Increase
the
DSI PLL Fint range, this was previously just copied from the OMAP4 param range
struct.
Fix the maximum DSS_FCLK on OMAP2, it's 133 Mhz according to the TRM.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dss_features.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index 7f791ae..77dbe0c 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -414,7 +414,7 @@ static const char * const omap5_dss_clk_source_names[] = {
};
static const struct dss_param_range omap2_dss_param_range[] = {
- [FEAT_PARAM_DSS_FCK]= { 0, 17300 },
+ [FEAT_PARAM_DSS_FCK]= { 0, 13300 },
[FEAT_PARAM_DSS_PCD]= { 2, 255 },
[FEAT_PARAM_DSIPLL_REGN]= { 0, 0 },
[FEAT_PARAM_DSIPLL_REGM]= { 0, 0 },
@@ -459,15 +459,15 @@ static const struct dss_param_range
omap4_dss_param_range[] = {
};
static const struct dss_param_range omap5_dss_param_range[] = {
- [FEAT_PARAM_DSS_FCK]= { 0, 2 },
+ [FEAT_PARAM_DSS_FCK]= { 0, 20925 },
[FEAT_PARAM_DSS_PCD]= { 1, 255 },
[FEAT_PARAM_DSIPLL_REGN]= { 0, (1 8) - 1 },
[FEAT_PARAM_DSIPLL_REGM]= { 0, (1 12) - 1 },
[FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, (1 5) - 1 },
[FEAT_PARAM_DSIPLL_REGM_DSI]= { 0, (1 5) - 1 },
- [FEAT_PARAM_DSIPLL_FINT]= { 50, 250 },
+ [FEAT_PARAM_DSIPLL_FINT]= { 15, 5200 },
Just a note, I think the PLL FINT range for OMAP3/4 may be wrong also.
Some TRMs mention the FINT range being up to 52MHz or so. I don't think
it's ever very clearly stated, though...
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v3 3/8] drm/omap: Make fixed resolution panels work
On Wednesday 27 March 2013 12:54 PM, Tomi Valkeinen wrote:
On 2013-03-26 15:45, Archit Taneja wrote:
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.
The following things are done to make fixed panels work:
- The omap_connector's detect function is modified such that it considers panel
types which are generally fixed panels as always connected(provided the panel
driver doesn't have a detect op). Hence, the connector corresponding to these
panels is always in a 'connected' state.
- If a panel driver doesn't have a check_timings op, assume that it supports the
mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper
function)
- The function omap_encoder_update shouldn't really do anything for fixed
resolution panels, make sure that it calls set_timings only if the panel
driver has one.
Signed-off-by: Archit Taneja arc...@ti.com
---
v3: clear the timings local variable first before using memcmp
v2: make sure the timings we try to set for a fixed resolution panel match the
panel's timings
drivers/gpu/drm/omapdrm/omap_connector.c | 27 +--
drivers/gpu/drm/omapdrm/omap_encoder.c | 17 +++--
2 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
b/drivers/gpu/drm/omapdrm/omap_connector.c
index c451c41..912759d 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -110,6 +110,11 @@ static enum drm_connector_status omap_connector_detect(
ret = connector_status_connected;
else
ret = connector_status_disconnected;
+ } else if (dssdev-type == OMAP_DISPLAY_TYPE_DPI ||
+ dssdev-type == OMAP_DISPLAY_TYPE_DBI ||
+ dssdev-type == OMAP_DISPLAY_TYPE_SDI ||
+ dssdev-type == OMAP_DISPLAY_TYPE_DSI) {
+ ret = connector_status_connected;
} else {
ret = connector_status_unknown;
}
Can we leave this part out? I don't like hardcoding things like that,
and if I'm not mistaken, this only affects VENC.
If the code above would use detect where available, and presume the
panel is connected in other cases, it'll be right for all other displays
but VENC, for which we have no connect information.
Or, there could be a special case for VENC, like above, which sets the
connector status to unknown for that. And connected for all others. It'd
still be hardcoded, but for much less cases.
I guess we can leave the status for VENC as always connected too, if we
leave it as unknown by default and have no detect func for VENC, it
would never run with omapdrm.
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/8] omapdss: DISPC: add max pixel clock limits for LCD and TV managers
On Wednesday 27 March 2013 01:00 PM, Tomi Valkeinen wrote:
On 2013-03-26 15:45, Archit Taneja wrote:
Each version of OMAP has a limitation on the maximum pixel clock frequency
supported by an overlay manager. This limit isn't checked by omapdss. Add
dispc feats for lcd and tv managers and check whether the target timings can
be supported or not.
The pixel clock limitations are actually more complex. They depend on which OPP
OMAP is in, and they also depend on which encoder is the manager connected to.
The OPP dependence is ignored as DSS forces the PM framework to be on OPP100
when DSS is enabled, and the encoder dependencies are ignored by DISPC for now.
These limits should come from the encoder driver.
The OMAP2 TRM doesn't mention the maximum pixel clock limit. This value is left
as half of DSS_FCLK, as OMAP2 requires the PCD to be atleast 2.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 8cfa27b..73a730a 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -69,6 +69,8 @@ struct dispc_features {
u8 mgr_height_start;
u16 mgr_width_max;
u16 mgr_height_max;
+ unsigned long max_lcd_pclk;
+ unsigned long max_tv_pclk;
int (*calc_scaling) (unsigned long pclk, unsigned long lclk,
const struct omap_video_timings *mgr_timings,
u16 width, u16 height, u16 out_width, u16 out_height,
@@ -2825,6 +2827,15 @@ static bool _dispc_lcd_timings_ok(int hsw, int hfp, int
hbp,
return true;
}
+static bool _dispc_mgr_pclk_ok(enum omap_channel channel,
+ unsigned long pclk)
+{
+ if (dss_mgr_is_lcd(channel))
+ return pclk = dispc.feat-max_lcd_pclk ? true : false;
+ else
+ return pclk = dispc.feat-max_tv_pclk ? true : false;
+}
+
bool dispc_mgr_timings_ok(enum omap_channel channel,
const struct omap_video_timings *timings)
{
@@ -2832,11 +2843,13 @@ bool dispc_mgr_timings_ok(enum omap_channel channel,
timings_ok = _dispc_mgr_size_ok(timings-x_res, timings-y_res);
- if (dss_mgr_is_lcd(channel))
- timings_ok = timings_ok _dispc_lcd_timings_ok(timings-hsw,
- timings-hfp, timings-hbp,
- timings-vsw, timings-vfp,
- timings-vbp);
+ timings_ok = _dispc_mgr_pclk_ok(channel, timings-pixel_clock * 1000);
+
+ if (dss_mgr_is_lcd(channel)) {
+ timings_ok = _dispc_lcd_timings_ok(timings-hsw, timings-hfp,
+ timings-hbp, timings-vsw, timings-vfp,
+ timings-vbp);
+ }
return timings_ok;
}
@@ -3491,6 +3504,7 @@ static const struct dispc_features omap24xx_dispc_feats
__initconst = {
.mgr_height_start = 26,
.mgr_width_max = 2048,
.mgr_height_max = 2048,
+ .max_lcd_pclk = 6650,
.calc_scaling = dispc_ovl_calc_scaling_24xx,
.calc_core_clk = calc_core_clk_24xx,
.num_fifos = 3,
OMAP2 has VENC output, but there's no max_tv_pclk above. This would make
VENC pclk check to fail always, wouldn't it?
oops, I missed adding it for omap2, will fix it.
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/8] omapdss: Features: Fix some parameter ranges
On Wednesday 27 March 2013 01:03 PM, Tomi Valkeinen wrote:
On 2013-03-26 15:45, Archit Taneja wrote:
Increase the DSS_FCLK and DSI_FCLK max supported frequencies, these come because
some frequencies were increased from OMAP5 ES1 to OMAP5 ES2. We support only
OMAP5 ES2 in the kernel, so replace the ES1 values with ES2 values. Increase the
DSI PLL Fint range, this was previously just copied from the OMAP4 param range
struct.
Fix the maximum DSS_FCLK on OMAP2, it's 133 Mhz according to the TRM.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dss_features.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index 7f791ae..77dbe0c 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -414,7 +414,7 @@ static const char * const omap5_dss_clk_source_names[] = {
};
static const struct dss_param_range omap2_dss_param_range[] = {
- [FEAT_PARAM_DSS_FCK]= { 0, 17300 },
+ [FEAT_PARAM_DSS_FCK]= { 0, 13300 },
[FEAT_PARAM_DSS_PCD]= { 2, 255 },
[FEAT_PARAM_DSIPLL_REGN]= { 0, 0 },
[FEAT_PARAM_DSIPLL_REGM]= { 0, 0 },
@@ -459,15 +459,15 @@ static const struct dss_param_range
omap4_dss_param_range[] = {
};
static const struct dss_param_range omap5_dss_param_range[] = {
- [FEAT_PARAM_DSS_FCK]= { 0, 2 },
+ [FEAT_PARAM_DSS_FCK]= { 0, 20925 },
[FEAT_PARAM_DSS_PCD]= { 1, 255 },
[FEAT_PARAM_DSIPLL_REGN]= { 0, (1 8) - 1 },
[FEAT_PARAM_DSIPLL_REGM]= { 0, (1 12) - 1 },
[FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, (1 5) - 1 },
[FEAT_PARAM_DSIPLL_REGM_DSI]= { 0, (1 5) - 1 },
- [FEAT_PARAM_DSIPLL_FINT]= { 50, 250 },
+ [FEAT_PARAM_DSIPLL_FINT]= { 15, 5200 },
Just a note, I think the PLL FINT range for OMAP3/4 may be wrong also.
Some TRMs mention the FINT range being up to 52MHz or so. I don't think
it's ever very clearly stated, though...
I'll drop the FINT range modification for now. It's not that critical
anyway since we manage to lock the PLL for most frequencies anyway. I'll
do an update later after reading more detailed specs of the PLL.
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/8] omapdss/omapdrm: Misc fixes and improvements
On 2013-03-26 15:45, Archit Taneja wrote: These are misc fixes and improvements within omapdrm and omapdss. The fixes do the following: - Make omapdrm smarter to choose the right overlay managers as it's crtcs. This makes sure that omapdrm is functional for OMAP platforms with different combinations of panels connected to it. - Fix certain areas in omapdrm which allow fixed resolution panels to work. - Fix functional and pixel clock limits for DISPC, this ensures we don't try to try a mode that the hardware can't support. - Some changes that came in OMAP5 ES2 silicon. Note: The branch is based on the DSS misc series and dsi video mode calc series posted by Tomi. Reference branch: git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git for-3.10/misc_drm_dss Which of the fixes should go for 3.9? We need those separately, based on the mainline. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 0/8] omapdss/omapdrm: Misc fixes and improvements
On Wednesday 27 March 2013 01:24 PM, Tomi Valkeinen wrote: On 2013-03-26 15:45, Archit Taneja wrote: These are misc fixes and improvements within omapdrm and omapdss. The fixes do the following: - Make omapdrm smarter to choose the right overlay managers as it's crtcs. This makes sure that omapdrm is functional for OMAP platforms with different combinations of panels connected to it. - Fix certain areas in omapdrm which allow fixed resolution panels to work. - Fix functional and pixel clock limits for DISPC, this ensures we don't try to try a mode that the hardware can't support. - Some changes that came in OMAP5 ES2 silicon. Note: The branch is based on the DSS misc series and dsi video mode calc series posted by Tomi. Reference branch: git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git for-3.10/misc_drm_dss Which of the fixes should go for 3.9? We need those separately, based on the mainline. The most important fix is omapdrm change which allocates crtcs in a better way, but it needs the 'dispc_channel' parameter in outputs, so that can't go. We could queue patches 7 and 8 for 3.9, they are 2 things which we would want to have in 3.9 itself. These should apply on mainline directly. Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 01/14] ARM: OMAP: remove DSS DT hack
As a temporary solution to enable DSS for selected boards when booting
with DT, a hack was added to board-generic.c in
63d5fc0c2f748e20f38a0a0ec1c8494bddf5c288 (OMAP: board-generic: enable
DSS for panda sdp boards).
We're now adding proper DT support, so the hack can be removed.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-generic.c |8
arch/arm/mach-omap2/dss-common.c| 24
arch/arm/mach-omap2/dss-common.h|2 --
3 files changed, 34 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index e54a480..a61544b 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -41,14 +41,6 @@ static void __init omap_generic_init(void)
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
- /*
-* HACK: call display setup code for selected boards to enable omapdss.
-* This will be removed when omapdss supports DT.
-*/
- if (of_machine_is_compatible(ti,omap4-panda))
- omap4_panda_display_init_of();
- else if (of_machine_is_compatible(ti,omap4-sdp))
- omap_4430sdp_display_init_of();
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index a10c56b..78e409a 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -93,13 +93,6 @@ void __init omap4_panda_display_init(void)
omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
}
-void __init omap4_panda_display_init_of(void)
-{
- omap_display_init(omap4_panda_dss_data);
- platform_device_register(omap4_panda_tfp410_device);
- platform_device_register(omap4_panda_hdmi_device);
-}
-
/* OMAP4 Blaze display data */
@@ -242,20 +235,3 @@ void __init omap_4430sdp_display_init(void)
omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
}
-
-void __init omap_4430sdp_display_init_of(void)
-{
- int r;
-
- /* Enable LCD2 by default (instead of Pico DLP) */
- r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
- display_sel);
- if (r)
- pr_err(%s: Could not get display_sel GPIO\n, __func__);
-
- sdp4430_picodlp_init();
- omap_display_init(sdp4430_dss_data);
- platform_device_register(sdp4430_hdmi_device);
- platform_device_register(sdp4430_lcd1_device);
- platform_device_register(sdp4430_lcd2_device);
-}
diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h
index 915f6ff..611b341 100644
--- a/arch/arm/mach-omap2/dss-common.h
+++ b/arch/arm/mach-omap2/dss-common.h
@@ -7,8 +7,6 @@
*/
void __init omap4_panda_display_init(void);
-void __init omap4_panda_display_init_of(void);
void __init omap_4430sdp_display_init(void);
-void __init omap_4430sdp_display_init_of(void);
#endif
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 00/14] Add DT support to OMAPDSS
Hi, This is an RFC for OMAPDSS DT support. I've only added support for a few boards and a few DSS outputs, but they should give quite a good range of different use cases. If these work well, I think the rest of the outputs and panels will be ok too. The purpose of this series is to get comments about the dts changes. There are still work to be done, like adding DT binding documentation. Some notes: * DSS Submodules The DSS submodules are children of the dss_core node. This is done because the submodules require the dss_core to be alive and initialized to work, even if the submodules are not really behind dss_core. Having the submodules as children will make runtime PM automatically handle the dependency to dss_core. I think usually a node being a child means that it's on the parent's bus, which is not the case here. I'm not sure if that's an issue or not. * ti,dsi-module-id There's a ti,dsi-module-id property in the dsi node. The reason for this module-id property is that we have muxes in the dss_core that route clocks to/from a particular DSI module. So we need some way to index the DSI modules. Another option would be to have a list of DSI modules (phandles) in the dss_core. Both options feel a bit wrong to me, but I went for the module-id approach as that is already used when not using DT. * Display chains Currently omapdss driver can handle only one display device connected to one OMAP SoC output. This is not right in many cases, as there may be multiple display devices in a chain, like first an external encoder and then a panel. However, I tried to model this right in the dts. So, for example, for Panda HDMI output we have the following display entities in a chain: OMAP SoC HDMI output, TPD12S015 ESD/level shifter, and HDMI connector. These are connected using the video-source property, which tells where the component in question gets its video data. You could ask why there's a separate node for HDMI connector. It's true it's not really a proper device, but we need some kind of terminator for the display chains. For HDMI we could as well have an embedded solution, having a chain like this: SoC HDMI, TPD12S015, hardwired embedded HDMI panel. So the connector marks the end of the chain, and acts as a panel in a sense. * DSI lanes The DSI panels contain lanes property, which tells how the SoCs DSI pins are connected to the DSI panel. I'm not sure if the panel data is the proper place for this, or should the data be separately for the OMAP DSI node. Tomi Tomi Valkeinen (14): ARM: OMAP: remove DSS DT hack ARM: OMAP2+: add omapdss_init_of() OMAPDSS: Add DT support to DSS, DISPC, DPI OMAPDSS: Add DT support to DSI OMAPDSS: Add DT support to HDMI OMAPDSS: Taal: Add DT support OMAPDSS: TFP410: Add DT support OMAPDSS: panel-generic-dpi: add DT support ARM: omap3.dtsi: add omapdss information ARM: omap4.dtsi: add omapdss information ARM: omap4-panda.dts: add display information ARM: omap4-sdp.dts: add display information ARM: omap3-tobi.dts: add lcd (TEST) ARM: omap3-beagle.dts: add TFP410 arch/arm/boot/dts/omap3-beagle.dts | 20 + arch/arm/boot/dts/omap3-tobi.dts | 13 arch/arm/boot/dts/omap3.dtsi | 49 arch/arm/boot/dts/omap4-panda.dts| 44 +++ arch/arm/boot/dts/omap4-sdp.dts | 64 arch/arm/boot/dts/omap4.dtsi | 71 + arch/arm/mach-omap2/board-generic.c |9 +-- arch/arm/mach-omap2/common.h |2 + arch/arm/mach-omap2/display.c| 34 + arch/arm/mach-omap2/dss-common.c | 24 -- arch/arm/mach-omap2/dss-common.h |2 - drivers/video/omap2/displays/panel-generic-dpi.c | 47 drivers/video/omap2/displays/panel-taal.c| 89 ++ drivers/video/omap2/displays/panel-tfp410.c | 71 + drivers/video/omap2/dss/dispc.c |7 ++ drivers/video/omap2/dss/dpi.c|8 ++ drivers/video/omap2/dss/dsi.c| 24 +- drivers/video/omap2/dss/dss.c|7 ++ drivers/video/omap2/dss/hdmi.c |7 ++ drivers/video/omap2/dss/hdmi_panel.c | 86 - 20 files changed, 641 insertions(+), 37 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 02/14] ARM: OMAP2+: add omapdss_init_of()
omapdss driver uses a omapdss platform device to pass platform specific
function pointers and DSS hardware version from the arch code to the
driver. This device is needed also when booting with DT.
This patch adds omapdss_init_of() function, called from board-generic at
init time, which creates the omapdss device.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-generic.c |1 +
arch/arm/mach-omap2/common.h|2 ++
arch/arm/mach-omap2/display.c | 34 ++
3 files changed, 37 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index a61544b..29eb085 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -41,6 +41,7 @@ static void __init omap_generic_init(void)
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+ omapdss_init_of();
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 40f4a03..e9ac1fd 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -293,5 +293,7 @@ extern void omap_reserve(void);
struct omap_hwmod;
extern int omap_dss_reset(struct omap_hwmod *);
+int __init omapdss_init_of(void);
+
#endif /* __ASSEMBLER__ */
#endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index ff37be1..c62aee0 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -23,6 +23,8 @@
#include linux/clk.h
#include linux/err.h
#include linux/delay.h
+#include linux/of.h
+#include linux/of_platform.h
#include video/omapdss.h
#include omap_hwmod.h
@@ -564,3 +566,35 @@ int omap_dss_reset(struct omap_hwmod *oh)
return r;
}
+
+int __init omapdss_init_of(void)
+{
+ int r;
+ enum omapdss_version ver;
+
+ static struct omap_dss_board_info board_data = {
+ .dsi_enable_pads = omap_dsi_enable_pads,
+ .dsi_disable_pads = omap_dsi_disable_pads,
+ .get_context_loss_count = omap_pm_get_dev_context_loss_count,
+ .set_min_bus_tput = omap_dss_set_min_bus_tput,
+ };
+
+ ver = omap_display_get_version();
+
+ if (ver == OMAPDSS_VER_UNKNOWN) {
+ pr_err(DSS not supported on this SoC\n);
+ return -ENODEV;
+ }
+
+ board_data.version = ver;
+
+ omap_display_device.dev.platform_data = board_data;
+
+ r = platform_device_register(omap_display_device);
+ if (r 0) {
+ pr_err(Unable to register omapdss device\n);
+ return r;
+ }
+
+ return 0;
+}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 03/14] OMAPDSS: Add DT support to DSS, DISPC, DPI
Add the code to make DSS, DISPC and DPI drivers work with device tree on
OMAP3 and OMAP4. The only change is adding the of_match_tables.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dispc.c |7 +++
drivers/video/omap2/dss/dpi.c |8
drivers/video/omap2/dss/dss.c |7 +++
3 files changed, 22 insertions(+)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 8cfa27b..be53d64 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3705,12 +3705,19 @@ static const struct dev_pm_ops dispc_pm_ops = {
.runtime_resume = dispc_runtime_resume,
};
+static const struct of_device_id dispc_of_match[] = {
+ { .compatible = ti,omap3-dispc, },
+ { .compatible = ti,omap4-dispc, },
+ {},
+};
+
static struct platform_driver omap_dispchw_driver = {
.remove = __exit_p(omap_dispchw_remove),
.driver = {
.name = omapdss_dispc,
.owner = THIS_MODULE,
.pm = dispc_pm_ops,
+ .of_match_table = dispc_of_match,
},
};
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index e7beea2..dc7e324 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -30,6 +30,7 @@
#include linux/platform_device.h
#include linux/regulator/consumer.h
#include linux/string.h
+#include linux/of.h
#include video/omapdss.h
@@ -765,11 +766,18 @@ static int __exit omap_dpi_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id dpi_of_match[] = {
+ { .compatible = ti,omap3-dpi, },
+ { .compatible = ti,omap4-dpi, },
+ {},
+};
+
static struct platform_driver omap_dpi_driver = {
.remove = __exit_p(omap_dpi_remove),
.driver = {
.name = omapdss_dpi,
.owner = THIS_MODULE,
+ .of_match_table = dpi_of_match,
},
};
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 62db201..dc721f4 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -962,12 +962,19 @@ static const struct dev_pm_ops dss_pm_ops = {
.runtime_resume = dss_runtime_resume,
};
+static const struct of_device_id dss_of_match[] = {
+ { .compatible = ti,omap3-dss, },
+ { .compatible = ti,omap4-dss, },
+ {},
+};
+
static struct platform_driver omap_dsshw_driver = {
.remove = __exit_p(omap_dsshw_remove),
.driver = {
.name = omapdss_dss,
.owner = THIS_MODULE,
.pm = dss_pm_ops,
+ .of_match_table = dss_of_match,
},
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 04/14] OMAPDSS: Add DT support to DSI
Add the code to make the DSI driver work with device tree on OMAP3 and
OMAP4. The of_match_table is added, and also a bit hacky
ti,dsi-module-id DT property, which tells the DSI ID number.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index fb77aa8..1058cab 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -38,6 +38,7 @@
#include linux/slab.h
#include linux/debugfs.h
#include linux/pm_runtime.h
+#include linux/of.h
#include video/omapdss.h
#include video/mipi_display.h
@@ -5541,7 +5542,20 @@ static int __init omap_dsihw_probe(struct
platform_device *dsidev)
if (!dsi)
return -ENOMEM;
- dsi-module_id = dsidev-id;
+ if (dsidev-dev.of_node) {
+ u32 id;
+ r = of_property_read_u32(dsidev-dev.of_node,
+ ti,dsi-module-id, id);
+ if (r) {
+ DSSERR(failed to read DSI module ID\n);
+ return r;
+ }
+
+ dsi-module_id = id;
+ } else {
+ dsi-module_id = dsidev-id;
+ }
+
dsi-pdev = dsidev;
dev_set_drvdata(dsidev-dev, dsi);
@@ -5642,6 +5656,7 @@ static int __init omap_dsihw_probe(struct platform_device
*dsidev)
else if (dsi-module_id == 1)
dss_debugfs_create_file(dsi2_irqs, dsi2_dump_irqs);
#endif
+
return 0;
err_runtime_get:
@@ -5700,12 +5715,19 @@ static const struct dev_pm_ops dsi_pm_ops = {
.runtime_resume = dsi_runtime_resume,
};
+static const struct of_device_id dsi_of_match[] = {
+ { .compatible = ti,omap3-dsi, },
+ { .compatible = ti,omap4-dsi, },
+ {},
+};
+
static struct platform_driver omap_dsihw_driver = {
.remove = __exit_p(omap_dsihw_remove),
.driver = {
.name = omapdss_dsi,
.owner = THIS_MODULE,
.pm = dsi_pm_ops,
+ .of_match_table = dsi_of_match,
},
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 05/14] OMAPDSS: Add DT support to HDMI
Add the code to make the HDMI driver work with device tree.
The OMAP SoC HDMI (hdmi.c) change is simple, just add of_match_table.
The hdmi_panel.c is a bit more complex. We model both the TPD12S015 chip
and the HDMI connector, and handle both in the same driver. In the
future those should be separate drivers.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/hdmi.c |7 +++
drivers/video/omap2/dss/hdmi_panel.c | 86 +-
2 files changed, 91 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index f9e38c4..e7a18d3 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -34,6 +34,7 @@
#include linux/clk.h
#include linux/gpio.h
#include linux/regulator/consumer.h
+#include linux/of_gpio.h
#include video/omapdss.h
#include ti_hdmi.h
@@ -1202,12 +1203,18 @@ static const struct dev_pm_ops hdmi_pm_ops = {
.runtime_resume = hdmi_runtime_resume,
};
+static const struct of_device_id hdmi_of_match[] = {
+ { .compatible = ti,omap4-hdmi, },
+ {},
+};
+
static struct platform_driver omapdss_hdmihw_driver = {
.remove = __exit_p(omapdss_hdmihw_remove),
.driver = {
.name = omapdss_hdmi,
.owner = THIS_MODULE,
.pm = hdmi_pm_ops,
+ .of_match_table = hdmi_of_match,
},
};
diff --git a/drivers/video/omap2/dss/hdmi_panel.c
b/drivers/video/omap2/dss/hdmi_panel.c
index bc4dea3..8dffd5d 100644
--- a/drivers/video/omap2/dss/hdmi_panel.c
+++ b/drivers/video/omap2/dss/hdmi_panel.c
@@ -27,12 +27,16 @@
#include video/omapdss.h
#include linux/slab.h
#include linux/platform_device.h
+#include linux/of.h
+#include linux/of_gpio.h
#include dss.h
static struct {
struct omap_dss_device dssdev;
+ struct omap_dss_hdmi_data pdata;
+
/* This protects the panel ops, mainly when accessing the HDMI IP. */
struct mutex lock;
#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
@@ -43,6 +47,62 @@ static struct {
static struct omap_dss_driver hdmi_driver;
+static int hdmi_panel_probe_pdata(struct platform_device *pdev)
+{
+ const struct omap_dss_hdmi_data *pdata = dev_get_platdata(pdev-dev);
+
+ hdmi.pdata = *pdata;
+
+ return 0;
+}
+
+static int hdmi_parse_tpd12s015_of(struct device_node *node,
+ struct omap_dss_hdmi_data *pdata)
+{
+ int gpio;
+
+ gpio = of_get_gpio(node, 0);/* CT CP HPD */
+ if (!gpio_is_valid(gpio))
+ return -EINVAL;
+ pdata-ct_cp_hpd_gpio = gpio;
+
+ gpio = of_get_gpio(node, 1);/* LS OE */
+ if (!gpio_is_valid(gpio))
+ return -EINVAL;
+ pdata-ls_oe_gpio = gpio;
+
+ gpio = of_get_gpio(node, 2);/* HPD */
+ if (!gpio_is_valid(gpio))
+ return -EINVAL;
+ pdata-hpd_gpio = gpio;
+
+ return 0;
+}
+
+static int hdmi_panel_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev-dev.of_node;
+ struct device_node *src_node;
+ int r;
+
+ /*
+* We don't have a real driver for the TPD12S015 chip, but it is
+* modeled right in the DT data. So we need to parse the TPD12S015 data
+* here.
+*/
+ src_node = of_parse_phandle(node, video-source, 0);
+ if (!src_node) {
+ dev_err(pdev-dev, failed to parse video source\n);
+ return -ENODEV;
+ }
+
+ r = hdmi_parse_tpd12s015_of(src_node, hdmi.pdata);
+ if (r)
+ return r;
+
+ return 0;
+}
+
static int hdmi_panel_probe(struct platform_device *pdev)
{
/* Initialize default timings to VGA in DVI mode */
@@ -63,12 +123,28 @@ static int hdmi_panel_probe(struct platform_device *pdev)
.interlace = false,
};
- struct omap_dss_hdmi_data *pdata = dev_get_platdata(pdev-dev);
struct omap_dss_device *dssdev = hdmi.dssdev;
int r;
DSSDBG(ENTER hdmi_panel_probe\n);
+ if (dev_get_platdata(pdev-dev)) {
+ r = hdmi_panel_probe_pdata(pdev);
+ if (r) {
+ dev_err(pdev-dev, failed to read platform data\n);
+ return r;
+ }
+ } else if (pdev-dev.of_node) {
+ r = hdmi_panel_probe_of(pdev);
+ if (r) {
+ dev_err(pdev-dev, failed to parse OF data\n);
+ return r;
+ }
+ } else {
+ return -ENODEV;
+ }
+
+
dssdev-panel.timings = default_timings;
dssdev-driver = hdmi_driver;
dssdev-name = hdmi;
@@ -78,7 +154,7 @@ static int hdmi_panel_probe(struct platform_device *pdev)
* XXX for now, the hdmi panel's platform data contains the gpios for
* the tpd level shifter chip, so we pass this data
[RFC 06/14] OMAPDSS: Taal: Add DT support
Add DT support to Taal panel driver.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-taal.c | 89 +
1 file changed, 89 insertions(+)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index 01de2a9..f8771da 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -32,6 +32,8 @@
#include linux/slab.h
#include linux/mutex.h
#include linux/platform_device.h
+#include linux/of_device.h
+#include linux/of_gpio.h
#include video/omapdss.h
#include video/omap-panel-nokia-dsi.h
@@ -788,6 +790,81 @@ static int taal_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int taal_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev-dev.of_node;
+ struct taal_data *td = dev_get_drvdata(pdev-dev);
+ struct property *prop;
+ struct device_node *src_node;
+ u32 lane_arr[10];
+ int gpio, len, num_pins;
+ int r, i;
+
+ src_node = of_parse_phandle(node, video-source, 0);
+ if (!src_node) {
+ dev_err(pdev-dev, failed to parse video source\n);
+ return -ENODEV;
+ }
+
+ td-src = omap_dss_find_output_by_node(src_node);
+ if (!td-src) {
+ dev_err(pdev-dev, failed to find video source\n);
+ return -ENODEV;
+ }
+
+ gpio = of_get_gpio(node, 0);
+
+ if (gpio_is_valid(gpio)) {
+ td-reset_gpio = gpio;
+ } else {
+ dev_err(pdev-dev, failed to parse reset gpio\n);
+ return gpio;
+ }
+
+ if (of_gpio_count(node) 1) {
+ gpio = of_get_gpio(node, 1);
+
+ if (gpio_is_valid(gpio)) {
+ td-ext_te_gpio = gpio;
+ } else if (gpio == -ENOENT) {
+ td-ext_te_gpio = -1;
+ } else {
+ dev_err(pdev-dev, failed to parse TE gpio\n);
+ return gpio;
+ }
+ } else {
+ td-ext_te_gpio = -1;
+ }
+
+ prop = of_find_property(node, lanes, len);
+ if (prop == NULL) {
+ dev_err(pdev-dev, failed to find lane data\n);
+ return -EINVAL;
+ }
+
+ num_pins = len / sizeof(u32);
+
+ if (num_pins 4 || num_pins % 2 != 0
+ || num_pins ARRAY_SIZE(lane_arr)) {
+ dev_err(pdev-dev, bad number of lanes\n);
+ return -EINVAL;
+ }
+
+ r = of_property_read_u32_array(node, lanes, lane_arr, num_pins);
+ if (r) {
+ dev_err(pdev-dev, failed to read lane data\n);
+ return r;
+ }
+
+ td-pin_config.num_pins = num_pins;
+ for (i = 0; i num_pins; ++i)
+ td-pin_config.pins[i] = (int)lane_arr[i];
+
+ td-dssdev.name = node-name;
+
+ return 0;
+}
+
static int taal_probe(struct platform_device *pdev)
{
const struct nokia_dsi_panel_data *pdata = dev_get_platdata(pdev-dev);
@@ -813,6 +890,12 @@ static int taal_probe(struct platform_device *pdev)
dev_err(pdev-dev, failed to read platform data\n);
return r;
}
+ } else if (pdev-dev.of_node) {
+ r = taal_probe_of(pdev);
+ if (r) {
+ dev_err(pdev-dev, failed to parse OF data\n);
+ return r;
+ }
} else {
return -ENODEV;
}
@@ -1576,12 +1659,18 @@ static struct omap_dss_driver taal_driver = {
.memory_read= taal_memory_read,
};
+static const struct of_device_id taal_of_match[] = {
+ { .compatible = tpo,taal, },
+ {},
+};
+
static struct platform_driver taal_platform_driver = {
.probe = taal_probe,
.remove = __exit_p(taal_remove),
.driver = {
.name = taal,
.owner = THIS_MODULE,
+ .of_match_table = taal_of_match,
},
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 11/14] ARM: omap4-panda.dts: add display information
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts | 44 +
1 file changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..45dd40a 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -206,3 +206,47 @@
twl_usb_comparator {
usb-supply = vusb;
};
+
+dsi1 {
+ vdds_dsi-supply = vcxio;
+};
+
+dsi2 {
+ vdds_dsi-supply = vcxio;
+};
+
+hdmi {
+ vdda_hdmi_dac-supply = vdac;
+};
+
+/ {
+ tfp410: tfp410 {
+ compatible = ti,tfp410;
+ video-source = dpi;
+ data-lines = 24;
+ gpios = gpio1 0 0; /* 0, power-down */
+ i2c-bus = i2c3;
+ };
+
+ dvi {
+ compatible = ti,dvi_connector;
+
+ video-source = tfp410;
+ };
+
+ tpd12s015: tpd12s015 {
+ compatible = ti,tpd12s015;
+
+ video-source = hdmi;
+
+ gpios = gpio2 28 0, /* 60, CT CP HPD */
+ gpio2 9 0, /* 41, LS OE */
+ gpio2 31 0; /* 63, HPD */
+ };
+
+ hdmi {
+ compatible = ti,hdmi_connector;
+
+ video-source = tpd12s015;
+ };
+};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 12/14] ARM: omap4-sdp.dts: add display information
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 64 +++
1 file changed, 64 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 43e5258..3bef36e 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -428,3 +428,67 @@
twl_usb_comparator {
usb-supply = vusb;
};
+
+dsi1 {
+ vdds_dsi-supply = vcxio;
+};
+
+dsi2 {
+ vdds_dsi-supply = vcxio;
+};
+
+hdmi {
+ vdda_hdmi_dac-supply = vdac;
+};
+
+/ {
+ lcd {
+ compatible = tpo,taal;
+
+ video-source = dsi1;
+
+ lanes =
+ 0 /* clk + */
+ 1 /* clk - */
+ 2 /* data1 + */
+ 3 /* data1 - */
+ 4 /* data2 + */
+ 5 /* data2 - */
+ ;
+
+ gpios = gpio4 6 0; /* 102, reset */
+ };
+
+ lcd2 {
+ compatible = tpo,taal;
+
+ video-source = dsi2;
+
+ lanes =
+ 0 /* clk + */
+ 1 /* clk - */
+ 2 /* data1 + */
+ 3 /* data1 - */
+ 4 /* data2 + */
+ 5 /* data2 - */
+ ;
+
+ gpios = gpio4 8 0; /* 104, reset */
+ };
+
+ tpd12s015: tpd12s015 {
+ compatible = ti,tpd12s015;
+
+ video-source = hdmi;
+
+ gpios = gpio2 28 0, /* 60, CT CP HPD */
+ gpio2 9 0, /* 41, LS OE */
+ gpio2 31 0; /* 63, HPD */
+ };
+
+ hdmi {
+ compatible = ti,hdmi_connector;
+
+ video-source = tpd12s015;
+ };
+};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 07/14] OMAPDSS: TFP410: Add DT support
In the DT data we model the TFP410 chip and the DVI connector. For the
moment we have only 1 driver to handle those both.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-tfp410.c | 71 +++
1 file changed, 71 insertions(+)
diff --git a/drivers/video/omap2/displays/panel-tfp410.c
b/drivers/video/omap2/displays/panel-tfp410.c
index a225ea1..a087489c 100644
--- a/drivers/video/omap2/displays/panel-tfp410.c
+++ b/drivers/video/omap2/displays/panel-tfp410.c
@@ -24,6 +24,8 @@
#include linux/gpio.h
#include linux/platform_device.h
#include drm/drm_edid.h
+#include linux/of_gpio.h
+#include linux/of_i2c.h
#include video/omap-panel-tfp410.h
@@ -112,6 +114,63 @@ static int tfp410_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int tfp410_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev-dev.of_node;
+ struct panel_drv_data *ddata = dev_get_drvdata(pdev-dev);
+ struct device_node *adapter_node;
+ struct i2c_adapter *adapter;
+ int r, gpio, datalines;
+
+ ddata-name = node-name;
+
+ node = of_parse_phandle(node, video-source, 0);
+ if (!node) {
+ dev_err(pdev-dev, failed to parse video source\n);
+ return -ENODEV;
+ }
+
+ gpio = of_get_gpio(node, 0);
+
+ if (gpio_is_valid(gpio)) {
+ r = devm_gpio_request_one(pdev-dev, gpio,
+ GPIOF_OUT_INIT_LOW, tfp410 pd);
+ if (r) {
+ dev_err(pdev-dev, Failed to request PD GPIO %d\n,
+ gpio);
+ return r;
+ }
+
+ ddata-pd_gpio = gpio;
+ } else if (gpio == -ENOENT) {
+ ddata-pd_gpio = -1;
+ } else {
+ dev_err(pdev-dev, failed to parse PD gpio\n);
+ return gpio;
+ }
+
+ r = of_property_read_u32(node, data-lines, datalines);
+ if (r) {
+ dev_err(pdev-dev, failed to parse datalines);
+ return r;
+ }
+
+ ddata-data_lines = datalines;
+
+ adapter_node = of_parse_phandle(node, i2c-bus, 0);
+ if (adapter_node) {
+ adapter = of_find_i2c_adapter_by_node(adapter_node);
+ if (adapter == NULL) {
+ dev_err(pdev-dev, failed to parse i2c-bus\n);
+ return -EINVAL;
+ }
+
+ ddata-i2c_adapter = adapter;
+ }
+
+ return 0;
+}
+
static int tfp410_probe(struct platform_device *pdev)
{
struct tfp410_platform_data *pdata = dev_get_platdata(pdev-dev);
@@ -131,6 +190,10 @@ static int tfp410_probe(struct platform_device *pdev)
r = tfp410_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev-dev.of_node) {
+ r = tfp410_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -380,12 +443,20 @@ static struct omap_dss_driver tfp410_driver = {
.detect = tfp410_detect,
};
+static const struct of_device_id tfp410_of_match[] = {
+ {
+ .compatible = ti,dvi_connector,
+ },
+ {},
+};
+
static struct platform_driver tfp410_platform_driver = {
.probe = tfp410_probe,
.remove = __exit_p(tfp410_remove),
.driver = {
.name = tfp410,
.owner = THIS_MODULE,
+ .of_match_table = tfp410_of_match,
},
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 14/14] ARM: omap3-beagle.dts: add TFP410
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index f624dc8..84785e7 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -65,3 +65,23 @@
mmc3 {
status = disabled;
};
+
+dpi {
+ vdds_dsi-supply = vpll2;
+};
+
+/ {
+ tfp410: tfp410 {
+ compatible = ti,tfp410;
+ video-source = dpi;
+ data-lines = 24;
+ gpios = gpio5 10 0; /* 170, power-down */
+ i2c-bus = i2c3;
+ };
+
+ dvi {
+ compatible = ti,dvi_connector;
+
+ video-source = tfp410;
+ };
+};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 13/14] ARM: omap3-tobi.dts: add lcd (TEST)
This is a test for Overo with Palo43 expansion, _not_ Tobi. Palo43
doesn't have a dts, but seems to work ok with omap3-tobi.dts, so I used
it as a test.
Not to be merged.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap3-tobi.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-tobi.dts b/arch/arm/boot/dts/omap3-tobi.dts
index a13d12d..68e3c1b 100644
--- a/arch/arm/boot/dts/omap3-tobi.dts
+++ b/arch/arm/boot/dts/omap3-tobi.dts
@@ -33,3 +33,16 @@
mmc3 {
status = disabled;
};
+
+dpi {
+ vdds_dsi-supply = vpll2;
+};
+
+/ {
+ lcd43 {
+ compatible = ti,dpi_panel;
+ video-source = dpi;
+ data-lines = 24;
+ panel-name = samsung_lte430wq_f0c;
+ };
+};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 08/14] OMAPDSS: panel-generic-dpi: add DT support
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-generic-dpi.c | 47 ++
1 file changed, 47 insertions(+)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
index cc49c48..a00c942 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -34,6 +34,7 @@
#include linux/delay.h
#include linux/slab.h
#include linux/platform_device.h
+#include linux/of.h
#include video/omapdss.h
#include video/omap-panel-generic-dpi.h
@@ -618,6 +619,42 @@ static int generic_dpi_panel_probe_pdata(struct
platform_device *pdev)
return 0;
}
+static int generic_dpi_panel_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev-dev.of_node;
+ struct panel_drv_data *drv_data = dev_get_drvdata(pdev-dev);
+ struct panel_config *panel_config = NULL;
+ int r, i;
+ int datalines;
+ const char *panel_name;
+
+ r = of_property_read_string(node, panel-name, panel_name);
+ if (r)
+ return r;
+
+ for (i = 0; i ARRAY_SIZE(generic_dpi_panels); i++) {
+ if (strcmp(panel_name, generic_dpi_panels[i].name) == 0) {
+ panel_config = generic_dpi_panels[i];
+ break;
+ }
+ }
+
+ if (!panel_config)
+ return -EINVAL;
+
+ r = of_property_read_u32(node, data-lines, datalines);
+ if (r) {
+ dev_err(pdev-dev, failed to parse datalines);
+ return r;
+ }
+
+ drv_data-panel_config = panel_config;
+ drv_data-name = node-name;
+ drv_data-data_lines = datalines;
+
+ return 0;
+}
+
static int generic_dpi_panel_probe(struct platform_device *pdev)
{
struct panel_drv_data *drv_data;
@@ -636,6 +673,10 @@ static int generic_dpi_panel_probe(struct platform_device
*pdev)
r = generic_dpi_panel_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev-dev.of_node) {
+ r = generic_dpi_panel_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -EINVAL;
}
@@ -754,12 +795,18 @@ static struct omap_dss_driver generic_dpi_panel_driver = {
.get_resolution = omapdss_default_get_resolution,
};
+static const struct of_device_id generic_dpi_panel_of_match[] = {
+ { .compatible = ti,dpi_panel, },
+ {},
+};
+
static struct platform_driver generic_dpi_panel_platform_driver = {
.probe = generic_dpi_panel_probe,
.remove = __exit_p(generic_dpi_panel_remove),
.driver = {
.name = generic_dpi_panel,
.owner = THIS_MODULE,
+ .of_match_table = generic_dpi_panel_of_match,
},
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 10/14] ARM: omap4.dtsi: add omapdss information
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 71 ++
1 file changed, 71 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..967f706 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -529,5 +529,76 @@
ti,hwmods = timer11;
ti,timer-pwm;
};
+
+ dss@5800 {
+ compatible = ti,omap4-dss, simple-bus;
+ reg = 0x5800 0x80;
+ ti,hwmods = dss_core;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@58001000 {
+ compatible = ti,omap4-dispc;
+ reg = 0x58001000 0x1000;
+ interrupts = 0 25 0x4;
+ ti,hwmods = dss_dispc;
+ };
+
+ dpi: dpi {
+ compatible = ti,omap4-dpi;
+ };
+
+ rfbi: rfbi@58002000 {
+ compatible = ti,omap4-rfbi;
+ reg = 0x58002000 0x1000;
+ ti,hwmods = dss_rfbi;
+ };
+
+ /*
+* Accessing venc registers cause a crash on omap4, so
+* this is disabled for now.
+*/
+ /*
+ venc: venc@58003000 {
+ compatible = ti,omap4-venc;
+ reg = 0x58003000 0x1000;
+ ti,hwmods = dss_venc;
+ };
+ */
+
+ dsi1: dsi@58004000 {
+ compatible = ti,omap4-dsi;
+ reg = 0x58004000 0x200;
+ interrupts = 0 53 0x4;
+ ti,hwmods = dss_dsi1;
+
+ /*
+* XXX dss_core needs to know module-id,
+* so this data should be there.
+*/
+ ti,dsi-module-id = 0;
+ };
+
+ dsi2: dsi@58005000 {
+ compatible = ti,omap4-dsi;
+ reg = 0x58005000 0x200;
+ interrupts = 0 84 0x4;
+ ti,hwmods = dss_dsi2;
+
+ /*
+* XXX dss_core needs to know module-id,
+* so this data should be there.
+*/
+ ti,dsi-module-id = 1;
+ };
+
+ hdmi: hdmi@58006000 {
+ compatible = ti,omap4-hdmi;
+ reg = 0x58006000 0x1000;
+ interrupts = 0 101 0x4;
+ ti,hwmods = dss_hdmi;
+ };
+ };
};
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 09/14] ARM: omap3.dtsi: add omapdss information
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 49 ++
1 file changed, 49 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..49de390 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,54 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+ dss@4805 {
+ compatible = ti,omap3-dss, simple-bus;
+ reg = 0x4805 0x200;
+ ti,hwmods = dss_core;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@48050400 {
+ compatible = ti,omap3-dispc;
+ reg = 0x48050400 0x400;
+ interrupts = 25;
+ ti,hwmods = dss_dispc;
+ };
+
+ dpi: dpi {
+ compatible = ti,omap3-dpi;
+ };
+
+ sdi: sdi {
+ compatible = ti,omap3-sdi;
+ };
+
+ dsi: dsi@4804fc00 {
+ compatible = ti,omap3-dsi;
+ reg = 0x4804fc00 0x400;
+ interrupts = 25;
+ ti,hwmods = dss_dsi1;
+
+ /*
+* XXX dss_core needs to know module-id,
+* so this data should be there.
+*/
+ ti,dsi-module-id = 0;
+ };
+
+ rfbi: rfbi@48050800 {
+ compatible = ti,omap3-rfbi;
+ reg = 0x48050800 0x100;
+ ti,hwmods = dss_rfbi;
+ };
+
+ venc: venc@48050c00 {
+ compatible = ti,omap3-venc;
+ reg = 0x48050c00 0x100;
+ ti,hwmods = dss_venc;
+ };
+ };
};
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.9-rc3
On Tue, 2013-03-26 at 18:43 +, Paul Walmsley wrote: Hi. On Tue, 19 Mar 2013, Tero Kristo wrote: I think you should definitely upgrade your bootloader, the old one you are using is prone to cause trouble due to bugs it has, and we have no simple way to workaround the issues it causes on kernel side. So, the kernel should be independent of the bootloader that's used. Many of the rest of us have taken great care to ensure that devices get reset to do this. We've got pretty good coverage on OMAP3 and most of the other OMAP4 IP blocks. You mention that there's no simple way to do it, but as far as I know, no one has assessed what's needed to reset the remaining devices. Or if someone has this information, it hasn't been shared here - please do so. So what I'd like you to do is: 1. Determine what devices are remaining to be reset and idled on OMAP4 with the bootloader that I use. As far as I know, there are only four that block full-chip idle: M3, DSP, SL2IF, FSUSB 2. Determine what's needed to reset and idle them. For the M3 and DSP, I'd assume this involves pointing the reset vector for those processors at a few lines of code that basically enter WFI or the C64x equivalent. This is the nasty part. We need firmware support for the blocks to do this, and this is imo a complete overkill for the task at hand, as it will duplicate the DSP + M3 firmware and drivers at least partially. On OMAP3, it was easy as you could just setup the boot mode for IVA and get over with it. We don't have similar luxury on OMAP4. If there was a simple way to do this, don't you think this would have been done already a year back when we started to discuss this first time? And, a year old bootloader is ancient seeing we didn't have any kind of support for OMAP4 core idle in mainline back then and this feature was essentially completely untested nobody cared about the upstream u-boot PM compatibility before that. -Tero 3. At this point, we can determine the difficulty level of the task. 4. Then, assuming it's of the level described in step 2, that reset/idle code should be implemented. This process will ensure both that users with old OMAP4 bootloaders -- really, u-boot versions distributed less than a year ago, so not very old at all -- will be able to successfully enter chip low power states. It will also ensure that users who boot to new kernels with kexec will be able to do so successfully, with a minimum of interference from other devices. - 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] capemgr: Add beaglebone's cape driver bindings
Hi Grant On Mar 26, 2013, at 7:36 PM, Grant Likely wrote: On Mon, 7 Jan 2013 20:51:03 +0200, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Document the beaglebone's cape driver bindings. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com Hi Pantelis, I'll go back and review the driver in a minute, but I'll start here since this is the data model that we'll be using for a long time. Overall this looks pretty sane. It's pretty well contained too which I like. Long term I do want to try and create some common patterns for overlay connections, but it's really hard to do that when this is the first serious attempt at implementing one. :-) This is nicely contained to only the beaglebone use case which makes it easy to try out without forcing this exact data model on all users. If it works in other places, then fantastic! we've got our generic model. If not, then we can refine the interface for new boards without breaking beaglebone. Glad you liked it. I really tried hard to keep things nicely separated since we're definitely on to uncharted waters. We will definitely adopt this for the beagleboard too (maybe some other boards too) so some rearrangement will take place for the v2 of the patches. We're under the gun for the new beaglebone that's coming out shortly, so the new patches will be out in a couple of weeks. Comments below... --- .../devicetree/bindings/misc/capes-beaglebone.txt | 110 + 1 file changed, 110 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/capes-beaglebone.txt diff --git a/Documentation/devicetree/bindings/misc/capes-beaglebone.txt b/Documentation/devicetree/bindings/misc/capes-beaglebone.txt new file mode 100644 index 000..f73cab5 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/capes-beaglebone.txt @@ -0,0 +1,110 @@ +* TI Beaglebone DT Overlay Cape Driver + +Required properties: + +- compatible: ti,bone-capemgr capemgr sounds like a software construct. Can you rename this to something that sounds more like describing concrete hardware? From that perspective, ti,bone-capebus would be appropriate here, regardless of where the driver actually lives in the kernel tree. Hum, well I guess so, that would work. Perhaps same as with ti,beagle-capebus. But I thought using the work bus was out :) It would be better to be more specific here with the compatible property also. Put the actual board name into the compatible string. Following the lead of the board level compatible property, call it 'ti,am335x-bone-capebus. Newer boards can claim compatibilty with the older where appropriate. Let's not put am335x there, there's nothing SoC specific. The bone is a am335x, but the beagleboard is not, etc. There's also some crazy talk about compatibility between different board families; we can keep it aside for now, but let's not assign anything SoC specific. + +- eeprom: Contains the phandle beaglebone's baseboard i2c eeprom. + +- baseboardmaps - node containing a list of supported +beaglebone revisions; each node in should have the +following properties: +- board-name: The board name stored in the baseboard +eeprom. If it is stored in the baseboard eeprom, then why does it need to appear in the .dtb? It needs to because there are slightly different revisions of the bone. Defining the revisions it allows us to auto-load the dtbos containing the differences for the baseboard revision. In this way we keep the same kernel/software images working on all the bone revisions, significantly reducing the support burden. +- compatible-name: The name which will be used for +matching compatible capes. What is the matching logic for this compatible capes? How does it get used? See below. + +- slots: node containing a list of slot nodes (which in the beaglebone +case correspond to I2C addresses for dynamically probed capes, +or an override slot definition for hardcoded capes. +- eeprom: Contains the phandle beaglebone's cape i2c eeprom. + +It is possible to define override slots that will be activated +when the baseboard matches, and/or if supplied on the kernel command +line and/or when dynamically requested on runtime. +In that case the slot is marked with +- ti,cape-override: Marks a slot override. +- compatible: any of the runtime, kernel, or any compatible-name + on a matching baseboardmap node. +- Any of the eeprom-format-revision, board-name, version, manufacturer, + part-number, number-of-pins, serial-number, pin-usage, vdd-3v3exp, + vdd-5v, sys-5v, dc-supplied properties which fill in the simulated + cape's EEPROM fields. The part-number field is required, the rest + are optional taking into default values. I could use some help understanding the use-case for the override slots. It isn't clear to me
Re: [RFC 02/14] ARM: OMAP2+: add omapdss_init_of()
Hi Tomi,
On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
omapdss driver uses a omapdss platform device to pass platform specific
function pointers and DSS hardware version from the arch code to the
driver. This device is needed also when booting with DT.
This patch adds omapdss_init_of() function, called from board-generic at
init time, which creates the omapdss device.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-generic.c |1 +
arch/arm/mach-omap2/common.h|2 ++
arch/arm/mach-omap2/display.c | 34 ++
3 files changed, 37 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index a61544b..29eb085 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -41,6 +41,7 @@ static void __init omap_generic_init(void)
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+ omapdss_init_of();
Mmm, you should not have to call that explicitly. It looks like a hack
to me. Everything in theory should be initialized during
of_platform_populate / driver probe.
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 40f4a03..e9ac1fd 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -293,5 +293,7 @@ extern void omap_reserve(void);
struct omap_hwmod;
extern int omap_dss_reset(struct omap_hwmod *);
+int __init omapdss_init_of(void);
+
#endif /* __ASSEMBLER__ */
#endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index ff37be1..c62aee0 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -23,6 +23,8 @@
#include linux/clk.h
#include linux/err.h
#include linux/delay.h
+#include linux/of.h
+#include linux/of_platform.h
#include video/omapdss.h
#include omap_hwmod.h
@@ -564,3 +566,35 @@ int omap_dss_reset(struct omap_hwmod *oh)
return r;
}
+
+int __init omapdss_init_of(void)
+{
+ int r;
+ enum omapdss_version ver;
+
+ static struct omap_dss_board_info board_data = {
+ .dsi_enable_pads = omap_dsi_enable_pads,
+ .dsi_disable_pads = omap_dsi_disable_pads,
Pads config should be handle by pinmux framework is possible. Otherwise
a dedicated driver will be required.
+ .get_context_loss_count = omap_pm_get_dev_context_loss_count,
+ .set_min_bus_tput = omap_dss_set_min_bus_tput,
All that code should disappear with DT. hacking a platform device with
pdata is the old way of initializing a device.
I know that you do have some omap_pm callback, but you'd better get rid
of them in case of DT boot.
Fixing that is a generic issue, and as soon as a solution will be done
to handle these specific hooks, every drivers will be able to use that.
+ };
+
+ ver = omap_display_get_version();
+
+ if (ver == OMAPDSS_VER_UNKNOWN) {
+ pr_err(DSS not supported on this SoC\n);
+ return -ENODEV;
+ }
+
+ board_data.version = ver;
+
+ omap_display_device.dev.platform_data = board_data;
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/14] Add DT support to OMAPDSS
Hi Tomi, On 03/27/2013 09:45 AM, Tomi Valkeinen wrote: Hi, This is an RFC for OMAPDSS DT support. I've only added support for a few boards and a few DSS outputs, but they should give quite a good range of different use cases. If these work well, I think the rest of the outputs and panels will be ok too. The purpose of this series is to get comments about the dts changes. There are still work to be done, like adding DT binding documentation. Some notes: * DSS Submodules The DSS submodules are children of the dss_core node. This is done because the submodules require the dss_core to be alive and initialized to work, even if the submodules are not really behind dss_core. Having the submodules as children will make runtime PM automatically handle the dependency to dss_core. I think usually a node being a child means that it's on the parent's bus, which is not the case here. I'm not sure if that's an issue or not. FWIW, there is a L4_DSS interconnect. It is used internally to connect all the submodules to the DSS L3 port. So this representation is perfectly valid and does represent accurately the HW. Regards, Benoit * ti,dsi-module-id There's a ti,dsi-module-id property in the dsi node. The reason for this module-id property is that we have muxes in the dss_core that route clocks to/from a particular DSI module. So we need some way to index the DSI modules. Another option would be to have a list of DSI modules (phandles) in the dss_core. Both options feel a bit wrong to me, but I went for the module-id approach as that is already used when not using DT. * Display chains Currently omapdss driver can handle only one display device connected to one OMAP SoC output. This is not right in many cases, as there may be multiple display devices in a chain, like first an external encoder and then a panel. However, I tried to model this right in the dts. So, for example, for Panda HDMI output we have the following display entities in a chain: OMAP SoC HDMI output, TPD12S015 ESD/level shifter, and HDMI connector. These are connected using the video-source property, which tells where the component in question gets its video data. You could ask why there's a separate node for HDMI connector. It's true it's not really a proper device, but we need some kind of terminator for the display chains. For HDMI we could as well have an embedded solution, having a chain like this: SoC HDMI, TPD12S015, hardwired embedded HDMI panel. So the connector marks the end of the chain, and acts as a panel in a sense. * DSI lanes The DSI panels contain lanes property, which tells how the SoCs DSI pins are connected to the DSI panel. I'm not sure if the panel data is the proper place for this, or should the data be separately for the OMAP DSI node. Tomi Tomi Valkeinen (14): ARM: OMAP: remove DSS DT hack ARM: OMAP2+: add omapdss_init_of() OMAPDSS: Add DT support to DSS, DISPC, DPI OMAPDSS: Add DT support to DSI OMAPDSS: Add DT support to HDMI OMAPDSS: Taal: Add DT support OMAPDSS: TFP410: Add DT support OMAPDSS: panel-generic-dpi: add DT support ARM: omap3.dtsi: add omapdss information ARM: omap4.dtsi: add omapdss information ARM: omap4-panda.dts: add display information ARM: omap4-sdp.dts: add display information ARM: omap3-tobi.dts: add lcd (TEST) ARM: omap3-beagle.dts: add TFP410 arch/arm/boot/dts/omap3-beagle.dts | 20 + arch/arm/boot/dts/omap3-tobi.dts | 13 arch/arm/boot/dts/omap3.dtsi | 49 arch/arm/boot/dts/omap4-panda.dts| 44 +++ arch/arm/boot/dts/omap4-sdp.dts | 64 arch/arm/boot/dts/omap4.dtsi | 71 + arch/arm/mach-omap2/board-generic.c |9 +-- arch/arm/mach-omap2/common.h |2 + arch/arm/mach-omap2/display.c| 34 + arch/arm/mach-omap2/dss-common.c | 24 -- arch/arm/mach-omap2/dss-common.h |2 - drivers/video/omap2/displays/panel-generic-dpi.c | 47 drivers/video/omap2/displays/panel-taal.c| 89 ++ drivers/video/omap2/displays/panel-tfp410.c | 71 + drivers/video/omap2/dss/dispc.c |7 ++ drivers/video/omap2/dss/dpi.c|8 ++ drivers/video/omap2/dss/dsi.c| 24 +- drivers/video/omap2/dss/dss.c|7 ++ drivers/video/omap2/dss/hdmi.c |7 ++ drivers/video/omap2/dss/hdmi_panel.c | 86 - 20 files changed, 641 insertions(+), 37 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
Re: [RFC 00/14] Add DT support to OMAPDSS
+ mturquette and Rajendra On 03/27/2013 09:45 AM, Tomi Valkeinen wrote: ... * ti,dsi-module-id There's a ti,dsi-module-id property in the dsi node. The reason for this module-id property is that we have muxes in the dss_core that route clocks to/from a particular DSI module. So we need some way to index the DSI modules. Another option would be to have a list of DSI modules (phandles) in the dss_core. Both options feel a bit wrong to me, but I went for the module-id approach as that is already used when not using DT. That's not a very nice representation. Ideally you should expose 1 clock node per DSI node, and enabling one will select the proper mux for you. Regards, Benoit * Display chains Currently omapdss driver can handle only one display device connected to one OMAP SoC output. This is not right in many cases, as there may be multiple display devices in a chain, like first an external encoder and then a panel. However, I tried to model this right in the dts. So, for example, for Panda HDMI output we have the following display entities in a chain: OMAP SoC HDMI output, TPD12S015 ESD/level shifter, and HDMI connector. These are connected using the video-source property, which tells where the component in question gets its video data. You could ask why there's a separate node for HDMI connector. It's true it's not really a proper device, but we need some kind of terminator for the display chains. For HDMI we could as well have an embedded solution, having a chain like this: SoC HDMI, TPD12S015, hardwired embedded HDMI panel. So the connector marks the end of the chain, and acts as a panel in a sense. * DSI lanes The DSI panels contain lanes property, which tells how the SoCs DSI pins are connected to the DSI panel. I'm not sure if the panel data is the proper place for this, or should the data be separately for the OMAP DSI node. Tomi Tomi Valkeinen (14): ARM: OMAP: remove DSS DT hack ARM: OMAP2+: add omapdss_init_of() OMAPDSS: Add DT support to DSS, DISPC, DPI OMAPDSS: Add DT support to DSI OMAPDSS: Add DT support to HDMI OMAPDSS: Taal: Add DT support OMAPDSS: TFP410: Add DT support OMAPDSS: panel-generic-dpi: add DT support ARM: omap3.dtsi: add omapdss information ARM: omap4.dtsi: add omapdss information ARM: omap4-panda.dts: add display information ARM: omap4-sdp.dts: add display information ARM: omap3-tobi.dts: add lcd (TEST) ARM: omap3-beagle.dts: add TFP410 arch/arm/boot/dts/omap3-beagle.dts | 20 + arch/arm/boot/dts/omap3-tobi.dts | 13 arch/arm/boot/dts/omap3.dtsi | 49 arch/arm/boot/dts/omap4-panda.dts| 44 +++ arch/arm/boot/dts/omap4-sdp.dts | 64 arch/arm/boot/dts/omap4.dtsi | 71 + arch/arm/mach-omap2/board-generic.c |9 +-- arch/arm/mach-omap2/common.h |2 + arch/arm/mach-omap2/display.c| 34 + arch/arm/mach-omap2/dss-common.c | 24 -- arch/arm/mach-omap2/dss-common.h |2 - drivers/video/omap2/displays/panel-generic-dpi.c | 47 drivers/video/omap2/displays/panel-taal.c| 89 ++ drivers/video/omap2/displays/panel-tfp410.c | 71 + drivers/video/omap2/dss/dispc.c |7 ++ drivers/video/omap2/dss/dpi.c|8 ++ drivers/video/omap2/dss/dsi.c| 24 +- drivers/video/omap2/dss/dss.c|7 ++ drivers/video/omap2/dss/hdmi.c |7 ++ drivers/video/omap2/dss/hdmi_panel.c | 86 - 20 files changed, 641 insertions(+), 37 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 05/26] OMAPDSS: DPI: fix regulators
On Tuesday 26 March 2013 07:03 PM, Tomi Valkeinen wrote:
On some platforms DPI requires a regulator to be enabled to power up the
output pins. This regulator is, for some reason, currently attached to
the virtual omapdss device, instead of the DPI device. This does not
work for DT, as the regulator mappings need to be described in the DT
data, and the virtual omapdss device is not present there.
Fix the issue by acquiring the regulator in the DPI device. To retain
compatibility with the current board files, the old method of getting
the regulator is kept. The old method can be removed when the board
files have been changed to pass the regulator to DPI.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index ad67a9c..08342d1 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -37,7 +37,10 @@
#include dss_features.h
static struct {
+ struct platform_device *pdev;
We can use dpi.output.pdev, we don't really need to have another pdev
pointer. Same for SDI in the next patch.
Archit
+
struct regulator *vdds_dsi_reg;
+ bool vdds_dsi_from_core;
struct platform_device *dsidev;
struct mutex lock;
@@ -583,10 +586,15 @@ static int __init dpi_init_display(struct omap_dss_device
*dssdev)
struct regulator *vdds_dsi;
vdds_dsi = dss_get_vdds_dsi();
-
if (IS_ERR(vdds_dsi)) {
- DSSERR(can't get VDDS_DSI regulator\n);
- return PTR_ERR(vdds_dsi);
+ vdds_dsi = regulator_get(dpi.pdev-dev, vdds_dsi);
+ if (IS_ERR(vdds_dsi)) {
+ DSSERR(can't get VDDS_DSI regulator\n);
+ return PTR_ERR(vdds_dsi);
+ }
+ dpi.vdds_dsi_from_core = false;
+ } else {
+ dpi.vdds_dsi_from_core = true;
}
dpi.vdds_dsi_reg = vdds_dsi;
@@ -698,6 +706,8 @@ static void __exit dpi_uninit_output(struct platform_device
*pdev)
static int __init omap_dpi_probe(struct platform_device *pdev)
{
+ dpi.pdev = pdev;
+
mutex_init(dpi.lock);
dpi_init_output(pdev);
@@ -714,6 +724,11 @@ static int __exit omap_dpi_remove(struct platform_device
*pdev)
dpi_uninit_output(pdev);
+ if (dpi.vdds_dsi_reg != NULL dpi.vdds_dsi_from_core == false) {
+ regulator_put(dpi.vdds_dsi_reg);
+ dpi.vdds_dsi_reg = NULL;
+ }
+
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 1/1] drivers: net: ethernet: ti: sparse warning fix for ti ethernet drivers
fix for the below sparse warnings
drivers/net/ethernet/ti/davinci_cpdma.c:182:29: warning: incorrect type in
assignment (different address spaces)
drivers/net/ethernet/ti/davinci_cpdma.c:182:29:expected void [noderef]
asn:2*iomap
drivers/net/ethernet/ti/davinci_cpdma.c:182:29:got void *cpumap
drivers/net/ethernet/ti/davinci_cpdma.c:953:27: warning: symbol 'controls' was
not declared. Should it be static?
drivers/net/ethernet/ti/cpsw.c:451:6: warning: symbol 'cpsw_tx_handler' was not
declared. Should it be static?
drivers/net/ethernet/ti/cpsw.c:468:6: warning: symbol 'cpsw_rx_handler' was not
declared. Should it be static?
drivers/net/ethernet/ti/cpsw_ale.c:151:5: warning: symbol 'cpsw_ale_match_addr'
was not declared. Should it be static?
drivers/net/ethernet/ti/cpsw_ale.c:172:5: warning: symbol 'cpsw_ale_match_vlan'
was not declared. Should it be static?
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/ethernet/ti/cpsw.c |4 ++--
drivers/net/ethernet/ti/cpsw_ale.c |4 ++--
drivers/net/ethernet/ti/davinci_cpdma.c |4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 7aebc0c..f4be85b 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -448,7 +448,7 @@ static void cpsw_intr_disable(struct cpsw_priv *priv)
return;
}
-void cpsw_tx_handler(void *token, int len, int status)
+static void cpsw_tx_handler(void *token, int len, int status)
{
struct sk_buff *skb = token;
struct net_device *ndev = skb-dev;
@@ -465,7 +465,7 @@ void cpsw_tx_handler(void *token, int len, int status)
dev_kfree_skb_any(skb);
}
-void cpsw_rx_handler(void *token, int len, int status)
+static void cpsw_rx_handler(void *token, int len, int status)
{
struct sk_buff *skb = token;
struct net_device *ndev = skb-dev;
diff --git a/drivers/net/ethernet/ti/cpsw_ale.c
b/drivers/net/ethernet/ti/cpsw_ale.c
index 7fa60d6..79f0b79 100644
--- a/drivers/net/ethernet/ti/cpsw_ale.c
+++ b/drivers/net/ethernet/ti/cpsw_ale.c
@@ -148,7 +148,7 @@ static int cpsw_ale_write(struct cpsw_ale *ale, int idx,
u32 *ale_entry)
return idx;
}
-int cpsw_ale_match_addr(struct cpsw_ale *ale, u8 *addr, u16 vid)
+static int cpsw_ale_match_addr(struct cpsw_ale *ale, u8 *addr, u16 vid)
{
u32 ale_entry[ALE_ENTRY_WORDS];
int type, idx;
@@ -169,7 +169,7 @@ int cpsw_ale_match_addr(struct cpsw_ale *ale, u8 *addr, u16
vid)
return -ENOENT;
}
-int cpsw_ale_match_vlan(struct cpsw_ale *ale, u16 vid)
+static int cpsw_ale_match_vlan(struct cpsw_ale *ale, u16 vid)
{
u32 ale_entry[ALE_ENTRY_WORDS];
int type, idx;
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c
b/drivers/net/ethernet/ti/davinci_cpdma.c
index ee13dc7..a6f5de9 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -179,7 +179,7 @@ cpdma_desc_pool_create(struct device *dev, u32 phys, u32
hw_addr,
} else {
pool-cpumap = dma_alloc_coherent(dev, size, pool-phys,
GFP_KERNEL);
- pool-iomap = pool-cpumap;
+ pool-iomap = (void __iomem *) pool-cpumap;
pool-hw_addr = pool-phys;
}
@@ -950,7 +950,7 @@ struct cpdma_control_info {
#define ACCESS_RW (ACCESS_RO | ACCESS_WO)
};
-struct cpdma_control_info controls[] = {
+static struct cpdma_control_info controls[] = {
[CPDMA_CMD_IDLE] = {CPDMA_DMACONTROL, 3, 1, ACCESS_WO},
[CPDMA_COPY_ERROR_FRAMES] = {CPDMA_DMACONTROL, 4, 1, ACCESS_RW},
[CPDMA_RX_OFF_LEN_UPDATE] = {CPDMA_DMACONTROL, 2, 1, ACCESS_RW},
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V2] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock
It is required to enable respective clock-domain before
enabling any clock/module inside that clock-domain.
During common-clock migration, .clkdm_name field got missed
for clkdiv32k_ick clock, which leaves clk_24mhz_clkdm
unused; so it will be disabled even if childs of this clock-domain
is enabled, which keeps child modules in idle mode.
This fixes the kernel crash observed on AM335xEVM-SK platform,
where clkdiv32_ick clock is being used as a gpio debounce clock
and since clkdiv32k_ick is in idle mode it leads to below crash -
Crash Log:
==
[2.598347] Unhandled fault: external abort on non-linefetch (0x1028) at
0xfa1ac150
[2.606434] Internal error: : 1028 [#1] SMP ARM
[2.611207] Modules linked in:
[2.614449] CPU: 0Not tainted (3.8.4-01382-g1f449cd-dirty #4)
[2.620973] PC is at _set_gpio_debounce+0x60/0x104
[2.626025] LR is at clk_enable+0x30/0x3c
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
Change from V1 (no code change):
- Commit description updated as per Rajendra and Paul's
comment.
arch/arm/mach-omap2/cclock33xx_data.c | 26 +++---
1 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index 476b820..8327721 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -446,9 +446,29 @@ DEFINE_CLK_GATE(cefuse_fck, sys_clkin_ck, sys_clkin_ck,
0x0,
*/
DEFINE_CLK_FIXED_FACTOR(clkdiv32k_ck, clk_24mhz, clk_24mhz, 0x0, 1, 732);
-DEFINE_CLK_GATE(clkdiv32k_ick, clkdiv32k_ck, clkdiv32k_ck, 0x0,
- AM33XX_CM_PER_CLKDIV32K_CLKCTRL, AM33XX_MODULEMODE_SWCTRL_SHIFT,
- 0x0, NULL);
+static struct clk clkdiv32k_ick;
+
+static const char *clkdiv32k_ick_parent_names[] = {
+ clkdiv32k_ck,
+};
+
+static const struct clk_ops clkdiv32k_ick_ops = {
+ .enable = omap2_dflt_clk_enable,
+ .disable= omap2_dflt_clk_disable,
+ .is_enabled = omap2_dflt_clk_is_enabled,
+ .init = omap2_init_clk_clkdm,
+};
+
+static struct clk_hw_omap clkdiv32k_ick_hw = {
+ .hw = {
+ .clk= clkdiv32k_ick,
+ },
+ .enable_reg = AM33XX_CM_PER_CLKDIV32K_CLKCTRL,
+ .enable_bit = AM33XX_MODULEMODE_SWCTRL_SHIFT,
+ .clkdm_name = clk_24mhz_clkdm,
+};
+
+DEFINE_STRUCT_CLK(clkdiv32k_ick, clkdiv32k_ick_parent_names,
clkdiv32k_ick_ops);
/* usbotg_fck is an additional clock and not really a modulemode */
DEFINE_CLK_GATE(usbotg_fck, dpll_per_ck, dpll_per_ck, 0x0,
--
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
Re: [RFC 02/14] ARM: OMAP2+: add omapdss_init_of()
On 2013-03-27 11:28, Benoit Cousson wrote:
Hi Tomi,
Hi Benoit. Thanks for your comments!
On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
omapdss driver uses a omapdss platform device to pass platform specific
function pointers and DSS hardware version from the arch code to the
driver. This device is needed also when booting with DT.
This patch adds omapdss_init_of() function, called from board-generic at
init time, which creates the omapdss device.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-generic.c |1 +
arch/arm/mach-omap2/common.h|2 ++
arch/arm/mach-omap2/display.c | 34
++
3 files changed, 37 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index a61544b..29eb085 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -41,6 +41,7 @@ static void __init omap_generic_init(void)
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+omapdss_init_of();
Mmm, you should not have to call that explicitly. It looks like a hack
to me. Everything in theory should be initialized during
of_platform_populate / driver probe.
All the real devices are initialized properly. However, we still have
a virtual omapdss device, which does not represent a particular HW
block as such, and is not represented in the DT data. It's a legacy
thing, and slowly on its way out.
However, it still helps us to pass the platform callbacks via platform
data even in DT call, so we have this (hacky) omapdss_init_of() call.
And we also pass the OMAP revision information via the platform data, as
we need to know the DSS HW version. The only way to get that is to know
the OMAP version and revision. If we would set the DSS HW version
information into DT data, we could need separate dts files for each OMAP
revision.
+
+int __init omapdss_init_of(void)
+{
+int r;
+enum omapdss_version ver;
+
+static struct omap_dss_board_info board_data = {
+.dsi_enable_pads = omap_dsi_enable_pads,
+.dsi_disable_pads = omap_dsi_disable_pads,
Pads config should be handle by pinmux framework is possible. Otherwise
a dedicated driver will be required.
Hmm. These functions touch the OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY
(CONTROL_DSIPHY in the TRM) register. It's not a normal padconfig thing
(like, selecting between GPIO and some other function).
Can they be handled by the pinmux framework? I'm not familiar with it.
What do you mean with dedicated driver? Dedicated pinmux driver, or
something else?
+.get_context_loss_count = omap_pm_get_dev_context_loss_count,
+.set_min_bus_tput = omap_dss_set_min_bus_tput,
All that code should disappear with DT. hacking a platform device with
pdata is the old way of initializing a device.
I know that you do have some omap_pm callback, but you'd better get rid
of them in case of DT boot.
Fixing that is a generic issue, and as soon as a solution will be done
to handle these specific hooks, every drivers will be able to use that.
So, what you're saying is that this is not the correct way, but there's
no other way to handle it currently? If so, yes, I know that, but, well,
there's no other way to handle it currently.
I could leave them out, but in that case when booting with DT there must
be no DSS context loss, and OPP must be at OPP100 all the time.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [RFC 00/14] Add DT support to OMAPDSS
On 2013-03-27 11:30, Benoit Cousson wrote: Hi Tomi, On 03/27/2013 09:45 AM, Tomi Valkeinen wrote: Hi, This is an RFC for OMAPDSS DT support. I've only added support for a few boards and a few DSS outputs, but they should give quite a good range of different use cases. If these work well, I think the rest of the outputs and panels will be ok too. The purpose of this series is to get comments about the dts changes. There are still work to be done, like adding DT binding documentation. Some notes: * DSS Submodules The DSS submodules are children of the dss_core node. This is done because the submodules require the dss_core to be alive and initialized to work, even if the submodules are not really behind dss_core. Having the submodules as children will make runtime PM automatically handle the dependency to dss_core. I think usually a node being a child means that it's on the parent's bus, which is not the case here. I'm not sure if that's an issue or not. FWIW, there is a L4_DSS interconnect. It is used internally to connect all the submodules to the DSS L3 port. So this representation is perfectly valid and does represent accurately the HW. Ah, yes, I can see it mentioned in the OMAP4430 Block Diagram figure in the TRM. No other mentions, though, I guess it's not really relevant =). But good to know that the DT representation is actually correct. Tomi signature.asc Description: OpenPGP digital signature
Re: [RFC 00/14] Add DT support to OMAPDSS
On 2013-03-27 11:41, Benoit Cousson wrote: + mturquette and Rajendra On 03/27/2013 09:45 AM, Tomi Valkeinen wrote: ... * ti,dsi-module-id There's a ti,dsi-module-id property in the dsi node. The reason for this module-id property is that we have muxes in the dss_core that route clocks to/from a particular DSI module. So we need some way to index the DSI modules. Another option would be to have a list of DSI modules (phandles) in the dss_core. Both options feel a bit wrong to me, but I went for the module-id approach as that is already used when not using DT. That's not a very nice representation. Ideally you should expose 1 clock node per DSI node, and enabling one will select the proper mux for you. Afaik, we need the DSI module id for the following things: 1) DSI pad configuration (OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY). 2) Setting clk mux in dss_core to select input clock for DSI protocol engine. The choice is between DSS_CLK from PRCM, or clock from a DSI PLL. DSI1 module can only use DSI1 PLL clock, and DSI2 module can only use DSI2 PLL clock. 3) Setting clk mux in dss_core to select input clock for LCD/DISPC. The choice is between DSS_CLK from PRCM, or a clock from DSI PLL. DISPC can use either DSI1 or DSI2 PLL, LCD1 can use DSI1 PLL clock, LCD2 can use DSI2 PLL clock. 4) Selecting the video output from DISPC which is routed to the DSI module. LCD1 output can go to DSI1, LCD2 output can go to DSI1 or DSI2. All the above of course change between OMAP versions. So managing all the above was easiest with a plain module-id assigned to the DSI device. I guess 1) could be somehow managed by having separate nodes in the dts for the DSIPHY control, and a link from the DSI module to that DSIPHY node. 4) could possibly be managed by having each DSS output node having a list of possible inputs from the DISPC. And, I guess, a link somehow to a mux node in the dss_core. Or something... All in all, I don't have any clear idea how these should be handled. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 16/26] OMAPDSS: TFP410: convert to platform device
On Tuesday 26 March 2013 07:03 PM, Tomi Valkeinen wrote:
Convert TFP410 driver from omap_dss_driver to a platform driver. The
driver uses the new panel support from omapdss.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-tfp410.c | 205 +--
1 file changed, 128 insertions(+), 77 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tfp410.c
b/drivers/video/omap2/displays/panel-tfp410.c
index 8281baa..a225ea1 100644
--- a/drivers/video/omap2/displays/panel-tfp410.c
+++ b/drivers/video/omap2/displays/panel-tfp410.c
@@ -22,10 +22,13 @@
#include video/omapdss.h
#include linux/i2c.h
#include linux/gpio.h
+#include linux/platform_device.h
#include drm/drm_edid.h
#include video/omap-panel-tfp410.h
+static struct omap_dss_driver tfp410_driver;
+
static const struct omap_video_timings tfp410_default_timings = {
.x_res = 640,
.y_res = 480,
@@ -48,121 +51,152 @@ static const struct omap_video_timings
tfp410_default_timings = {
};
struct panel_drv_data {
- struct omap_dss_device *dssdev;
+ struct omap_dss_device dssdev;
struct mutex lock;
+ const char *name;
+
int pd_gpio;
+ int data_lines;
+
+ struct omap_video_timings timings;
struct i2c_adapter *i2c_adapter;
};
-static int tfp410_power_on(struct omap_dss_device *dssdev)
+#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
+
+static int tfp410_probe_pdata(struct platform_device *pdev)
{
- struct panel_drv_data *ddata = dev_get_drvdata(dssdev-dev);
- int r;
+ struct tfp410_platform_data *pdata = dev_get_platdata(pdev-dev);
+ struct panel_drv_data *ddata = dev_get_drvdata(pdev-dev);
+ int r, gpio, i2c_bus_num;
- if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
- return 0;
+ ddata-name = pdata-name;
- omapdss_dpi_set_timings(dssdev, dssdev-panel.timings);
- omapdss_dpi_set_data_lines(dssdev, dssdev-phy.dpi.data_lines);
+ gpio = pdata-power_down_gpio;
- r = omapdss_dpi_display_enable(dssdev);
- if (r)
- goto err0;
+ if (gpio_is_valid(gpio)) {
+ r = devm_gpio_request_one(pdev-dev, gpio,
+ GPIOF_OUT_INIT_LOW, tfp410 pd);
+ if (r) {
+ dev_err(pdev-dev, Failed to request PD GPIO %d\n,
+ gpio);
+ return r;
+ }
- if (gpio_is_valid(ddata-pd_gpio))
- gpio_set_value_cansleep(ddata-pd_gpio, 1);
+ ddata-pd_gpio = gpio;
+ } else {
+ ddata-pd_gpio = -1;
+ }
- return 0;
-err0:
- return r;
-}
+ ddata-data_lines = pdata-data_lines;
-static void tfp410_power_off(struct omap_dss_device *dssdev)
-{
- struct panel_drv_data *ddata = dev_get_drvdata(dssdev-dev);
+ i2c_bus_num = pdata-i2c_bus_num;
- if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
- return;
+ if (i2c_bus_num != -1) {
+ struct i2c_adapter *adapter;
- if (gpio_is_valid(ddata-pd_gpio))
- gpio_set_value_cansleep(ddata-pd_gpio, 0);
+ adapter = i2c_get_adapter(i2c_bus_num);
+ if (!adapter) {
+ dev_err(pdev-dev,
+ Failed to get I2C adapter, bus %d\n,
+ i2c_bus_num);
+ return -EINVAL;
+ }
- omapdss_dpi_display_disable(dssdev);
+ ddata-i2c_adapter = adapter;
+ }
+
+ return 0;
}
-static int tfp410_probe(struct omap_dss_device *dssdev)
+static int tfp410_probe(struct platform_device *pdev)
{
+ struct tfp410_platform_data *pdata = dev_get_platdata(pdev-dev);
+ struct omap_dss_device *dssdev;
struct panel_drv_data *ddata;
int r;
- int i2c_bus_num;
- ddata = devm_kzalloc(dssdev-dev, sizeof(*ddata), GFP_KERNEL);
+ ddata = devm_kzalloc(pdev-dev, sizeof(*ddata), GFP_KERNEL);
if (!ddata)
return -ENOMEM;
- dssdev-panel.timings = tfp410_default_timings;
+ dev_set_drvdata(pdev-dev, ddata);
- ddata-dssdev = dssdev;
mutex_init(ddata-lock);
- if (dssdev-data) {
- struct tfp410_platform_data *pdata = dssdev-data;
-
- ddata-pd_gpio = pdata-power_down_gpio;
- i2c_bus_num = pdata-i2c_bus_num;
- } else {
- ddata-pd_gpio = -1;
- i2c_bus_num = -1;
- }
-
- if (gpio_is_valid(ddata-pd_gpio)) {
- r = devm_gpio_request_one(dssdev-dev, ddata-pd_gpio,
- GPIOF_OUT_INIT_LOW, tfp410 pd);
- if (r) {
- dev_err(dssdev-dev, Failed to request PD GPIO %d\n,
-
Re: [PATCH 16/26] OMAPDSS: TFP410: convert to platform device
On 2013-03-27 13:11, Archit Taneja wrote: On Tuesday 26 March 2013 07:03 PM, Tomi Valkeinen wrote: Convert TFP410 driver from omap_dss_driver to a platform driver. The driver uses the new panel support from omapdss. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/displays/panel-tfp410.c | 205 +-- 1 file changed, 128 insertions(+), 77 deletions(-) -ddata-i2c_adapter = adapter; +dssdev = ddata-dssdev; +dssdev-driver = tfp410_driver; +dssdev-panel.timings = tfp410_default_timings; +dssdev-name = ddata-name; +dssdev-phy.dpi.data_lines = ddata-data_lines; +dssdev-panel_dev = pdev-dev; Some of the omap_dss_device fields populated here(like data_lines) are not going to be used anywhere. Are you populating all of them just for the sake of clarity, so that they can be removed in another series later on? Or is there some other reason? Unfortunately the datalines are used in omapdss_default_get_recommended_bpp(). So there are some fields populated just to keep things working, and I expect that they are removed later. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 16/26] OMAPDSS: TFP410: convert to platform device
On Wednesday 27 March 2013 04:44 PM, Tomi Valkeinen wrote: On 2013-03-27 13:11, Archit Taneja wrote: On Tuesday 26 March 2013 07:03 PM, Tomi Valkeinen wrote: Convert TFP410 driver from omap_dss_driver to a platform driver. The driver uses the new panel support from omapdss. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/displays/panel-tfp410.c | 205 +-- 1 file changed, 128 insertions(+), 77 deletions(-) -ddata-i2c_adapter = adapter; +dssdev = ddata-dssdev; +dssdev-driver = tfp410_driver; +dssdev-panel.timings = tfp410_default_timings; +dssdev-name = ddata-name; +dssdev-phy.dpi.data_lines = ddata-data_lines; +dssdev-panel_dev = pdev-dev; Some of the omap_dss_device fields populated here(like data_lines) are not going to be used anywhere. Are you populating all of them just for the sake of clarity, so that they can be removed in another series later on? Or is there some other reason? Unfortunately the datalines are used in omapdss_default_get_recommended_bpp(). So there are some fields populated just to keep things working, and I expect that they are removed later. Ah okay, missed that. I guess it will be easier to remove these later on anyway. Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] gpio: gpiolib-of.c: fix checkpatch error
On Wed, Mar 20, 2013 at 1:15 PM, Laurent Navet laurent.na...@gmail.com wrote: Fix : gpio/gpiolib-of.c:64: ERROR: code indent should use tabs where possible Signed-off-by: Laurent Navet laurent.na...@gmail.com Applied. Thanks! Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] gpio: gpio-mvebu.c: fix checkpatch errors
On Wed, Mar 20, 2013 at 1:15 PM, Laurent Navet laurent.na...@gmail.com wrote:
Fix :
gpio/gpio-mvebu.c:120: ERROR: space required before the open parenthesis '('
gpio/gpio-mvebu.c:136: ERROR: space required before the open parenthesis '('
gpio/gpio-mvebu.c:154: ERROR: space required before the open parenthesis '('
gpio/gpio-mvebu.c:404: ERROR: space required before the open parenthesis '('
gpio/gpio-mvebu.c:476: ERROR: (foo*) should be (foo *)
gpio/gpio-mvebu.c:480: ERROR: (foo*) should be (foo *)
gpio/gpio-mvebu.c:484: ERROR: (foo*) should be (foo *)
gpio/gpio-mvebu.c:512: ERROR: space prohibited after that '!' (ctx:BxW)
gpio/gpio-mvebu.c:518: ERROR: space prohibited after that '!' (ctx:BxW)
gpio/gpio-mvebu.c:518: ERROR: space required before the open brace '{'
gpio/gpio-mvebu.c:563: ERROR: space prohibited after that '!' (ctx:BxW)
gpio/gpio-mvebu.c:570: ERROR: trailing whitespace
gpio/gpio-mvebu.c:577: ERROR: space required before the open parenthesis '('
gpio/gpio-mvebu.c:635: ERROR: space prohibited after that '!' (ctx:BxW)
Signed-off-by: Laurent Navet laurent.na...@gmail.com
Patch applied.
Thanks!
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/10] gpio: gpio-omap.c: fix checkpatch error
On Wed, Mar 20, 2013 at 1:15 PM, Laurent Navet laurent.na...@gmail.com wrote:
Fix :
gpio/gpio-omap.c:697: ERROR: space required before the open parenthesis '('
Signed-off-by: Laurent Navet laurent.na...@gmail.com
Applied with Santosh's ACK.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] gpio: gpio-pca953x.c: fix checkpatch error
On Wed, Mar 20, 2013 at 1:15 PM, Laurent Navet laurent.na...@gmail.com wrote: Fix : gpio/gpio-pca953x.c:150: ERROR: else should follow close brace '}' Signed-off-by: Laurent Navet laurent.na...@gmail.com Patch applied. Thanks! Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] gpio: gpio-pxa.c: fix checkpatch errors
On Wed, Mar 20, 2013 at 1:15 PM, Laurent Navet laurent.na...@gmail.com wrote:
Fix :
gpio/gpio-pxa.c:605: ERROR: space required after that ',' (ctx:VxV)
gpio/gpio-pxa.c:672: ERROR: space prohibited after that open parenthesis '('
Signed-off-by: Laurent Navet laurent.na...@gmail.com
Patch applied.
Thanks!
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/10] gpio: gpio-sch.c: fix checkpatch error
On Wed, Mar 20, 2013 at 1:16 PM, Laurent Navet laurent.na...@gmail.com wrote: Fix : gpio/gpio-sch.c:206: ERROR: switch and case should be at the same indent Also remove blank lines Signed-off-by: Laurent Navet laurent.na...@gmail.com Patch applied. Thanks! Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/10] gpio: gpio-stp-xway.c: fix checkpatch error
On Wed, Mar 20, 2013 at 1:16 PM, Laurent Navet laurent.na...@gmail.com wrote: Fix : gpio/gpio-stp-xway.c:220: ERROR: trailing whitespace Signed-off-by: Laurent Navet laurent.na...@gmail.com Patch applied. Thanks! Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] gpio: gpio-tc3589x.c: fix checkpatch errors
On Wed, Mar 20, 2013 at 1:16 PM, Laurent Navet laurent.na...@gmail.com wrote: Fix : gpio/gpio-tc3589x.c:285: ERROR: code indent should use tabs where possible gpio/gpio-tc3589x.c:286: ERROR: code indent should use tabs where possible gpio/gpio-tc3589x.c:287: ERROR: code indent should use tabs where possible gpio/gpio-tc3589x.c:347: ERROR: code indent should use tabs where possible Signed-off-by: Laurent Navet laurent.na...@gmail.com Patch applied. Thanks! Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/10] gpio: gpio-timberdale.c: fix checkpatch error
On Wed, Mar 20, 2013 at 1:16 PM, Laurent Navet laurent.na...@gmail.com wrote: Fix : gpio/gpio-timberdale.c:171: ERROR: else should follow close brace '}' Signed-off-by: Laurent Navet laurent.na...@gmail.com Patch applied. Thanks! Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/10] gpio: gpio-tps65910.c: fix checkpatch error
On Wed, Mar 20, 2013 at 1:16 PM, Laurent Navet laurent.na...@gmail.com wrote:
Fix :
gpio/gpio-tps65910.c:136: ERROR: space required before the open parenthesis
'('
Signed-off-by: Laurent Navet laurent.na...@gmail.com
Patch applied.
Thanks!
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] ARM: dts: AM33XX: Add pinctrl binding to gpio-leds node
Now gpio-leds driver is using devm_pinctrl_get_select_default()
api to set default pinmux configuration required for the
functionality of the driver, so this patch moves respective
pinctrl binding inside leds node.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |5 -
arch/arm/boot/dts/am335x-evmsk.dts |5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 860630b..1d623e4 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -26,7 +26,7 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = user_leds_s0;
+ pinctrl-0 = ;
user_leds_s0: user_leds_s0 {
pinctrl-single,pins =
@@ -65,6 +65,9 @@
};
leds {
+ pinctrl-names = default;
+ pinctrl-0 = user_leds_s0;
+
compatible = gpio-leds;
led@2 {
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 15a3052..21d5a08 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -32,7 +32,7 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = user_leds_s0 gpio_keys_s0;
+ pinctrl-0 = gpio_keys_s0;
user_leds_s0: user_leds_s0 {
pinctrl-single,pins =
@@ -121,6 +121,9 @@
};
leds {
+ pinctrl-names = default;
+ pinctrl-0 = user_leds_s0;
+
compatible = gpio-leds;
led@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 0/5] ARM: dts: AM33XX: Cleanup and pinctrl binding support
This patch series fixes the numbering schema for I2C and GPIO module and adds the pin-control binding for I2C, UART, GPIO-LED across supported platforms (EVM, EVM-SK and Bone). I have divided patches based on functionality and _not_ into EVM/Board perspective. Vaibhav Hiremath (5): ARM: dts: AM33XX: Fix the i2c numbering to match hardware/TRM ARM: dts: AM33XX: Add default pinctrl binding for I2C device ARM: dts: AM33XX: Fix gpio numbering to match hardware/TRM ARM: dts: AM33XX: Add pinctrl binding to gpio-leds node ARM: dts: AM33XX: Add default pinctrl binding for UART0 device arch/arm/boot/dts/am335x-bone.dts | 35 + arch/arm/boot/dts/am335x-evm.dts | 48 +-- arch/arm/boot/dts/am335x-evmsk.dts | 43 --- arch/arm/boot/dts/am33xx.dtsi | 14 +- 4 files changed, 108 insertions(+), 32 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] ARM: dts: AM33XX: Add default pinctrl binding for UART0 device
Add pin control binding for UART0 device nodes in all
board specific DT files.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 10 ++
arch/arm/boot/dts/am335x-evm.dts | 10 ++
arch/arm/boot/dts/am335x-evmsk.dts | 10 ++
3 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 1d623e4..3c4c66f 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -43,10 +43,20 @@
0x18c 0x30 /* i2c0_scl.i2c0_scl PULLUP |
INPUTENABLE | MODE0 */
;
};
+
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins =
+ 0x170 0x30 /* uart0_rxd.uart0_rxd PULLUP |
INPUTENABLE | MODE0 */
+ 0x174 0x00 /* uart0_txd.uart0_txd PULLDOWN
| MODE0 */
+ ;
+ };
};
ocp {
uart1: serial@44e09000 {
+ pinctrl-names = default;
+ pinctrl-0 = uart0_pins;
+
status = okay;
};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 79b3cc8..89e1edd 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -58,10 +58,20 @@
0x15c 0x32 /* spi0_cs0.i2c1_scl PULLUP |
INPUTENABLE | MODE2 */
;
};
+
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins =
+ 0x170 0x30 /* uart0_rxd.uart0_rxd PULLUP |
INPUTENABLE | MODE0 */
+ 0x174 0x00 /* uart0_txd.uart0_txd PULLDOWN
| MODE0 */
+ ;
+ };
};
ocp {
uart1: serial@44e09000 {
+ pinctrl-names = default;
+ pinctrl-0 = uart0_pins;
+
status = okay;
};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 21d5a08..0e7f1b8 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -58,10 +58,20 @@
0x18c 0x30 /* i2c0_scl.i2c0_scl PULLUP |
INPUTENABLE | MODE0 */
;
};
+
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins =
+ 0x170 0x30 /* uart0_rxd.uart0_rxd PULLUP |
INPUTENABLE | MODE0 */
+ 0x174 0x00 /* uart0_txd.uart0_txd PULLDOWN
| MODE0 */
+ ;
+ };
};
ocp {
uart1: serial@44e09000 {
+ pinctrl-names = default;
+ pinctrl-0 = uart0_pins;
+
status = okay;
};
--
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 1/5] ARM: dts: AM33XX: Fix the i2c numbering to match hardware/TRM
With DT support, where naming convention is based on base-addr
and not id, so we should follow TRM/Spec numbering label.
This patch changes I2C numbering as per TRM, as I2C0, I2C1 and I2C2.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |2 +-
arch/arm/boot/dts/am335x-evm.dts |4 ++--
arch/arm/boot/dts/am335x-evmsk.dts |2 +-
arch/arm/boot/dts/am33xx.dtsi |6 +++---
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 11b240c..cdc8307 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -43,7 +43,7 @@
status = okay;
};
- i2c1: i2c@44e0b000 {
+ i2c0: i2c@44e0b000 {
status = okay;
clock-frequency = 40;
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index d649644..a6539ad 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -51,7 +51,7 @@
status = okay;
};
- i2c1: i2c@44e0b000 {
+ i2c0: i2c@44e0b000 {
status = okay;
clock-frequency = 40;
@@ -60,7 +60,7 @@
};
};
- i2c2: i2c@4802a000 {
+ i2c1: i2c@4802a000 {
status = okay;
clock-frequency = 10;
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index f5a6162..45cb39a 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -58,7 +58,7 @@
status = okay;
};
- i2c1: i2c@44e0b000 {
+ i2c0: i2c@44e0b000 {
status = okay;
clock-frequency = 40;
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 0957645..c38b2fa 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -185,7 +185,7 @@
status = disabled;
};
- i2c1: i2c@44e0b000 {
+ i2c0: i2c@44e0b000 {
compatible = ti,omap4-i2c;
#address-cells = 1;
#size-cells = 0;
@@ -195,7 +195,7 @@
status = disabled;
};
- i2c2: i2c@4802a000 {
+ i2c1: i2c@4802a000 {
compatible = ti,omap4-i2c;
#address-cells = 1;
#size-cells = 0;
@@ -205,7 +205,7 @@
status = disabled;
};
- i2c3: i2c@4819c000 {
+ i2c2: i2c@4819c000 {
compatible = ti,omap4-i2c;
#address-cells = 1;
#size-cells = 0;
--
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 3/5] ARM: dts: AM33XX: Fix gpio numbering to match hardware/TRM
With DT support, where naming convention is based on base-addr
and not id, so we should follow TRM/Spec numbering label.
This patch changes GPIO numbering as per TRM, as gpio0-3.
Matt Porter had submitted base patch sometime back but it
didn't make it to the mainline -
https://patchwork.kernel.org/patch/1433001/
Later DT nodes for gpio based keypad and led driver got
merged, so this fix needs to propagate to board dts files
as well.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Matt Porter mpor...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |8
arch/arm/boot/dts/am335x-evm.dts | 14 +++---
arch/arm/boot/dts/am335x-evmsk.dts | 16
arch/arm/boot/dts/am33xx.dtsi |8
4 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index c917efa..860630b 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -69,27 +69,27 @@
led@2 {
label = beaglebone:green:heartbeat;
- gpios = gpio2 21 0;
+ gpios = gpio1 21 0;
linux,default-trigger = heartbeat;
default-state = off;
};
led@3 {
label = beaglebone:green:mmc0;
- gpios = gpio2 22 0;
+ gpios = gpio1 22 0;
linux,default-trigger = mmc0;
default-state = off;
};
led@4 {
label = beaglebone:green:usr2;
- gpios = gpio2 23 0;
+ gpios = gpio1 23 0;
default-state = off;
};
led@5 {
label = beaglebone:green:usr3;
- gpios = gpio2 24 0;
+ gpios = gpio1 24 0;
default-state = off;
};
};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index db52d3c..79b3cc8 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -143,12 +143,12 @@
debounce-delay-ms = 5;
col-scan-delay-us = 2;
- row-gpios = gpio2 25 0/* Bank1, pin25 */
-gpio2 26 0/* Bank1, pin26 */
-gpio2 27 0; /* Bank1, pin27 */
+ row-gpios = gpio1 25 0/* Bank1, pin25 */
+gpio1 26 0/* Bank1, pin26 */
+gpio1 27 0; /* Bank1, pin27 */
- col-gpios = gpio2 21 0/* Bank1, pin21 */
-gpio2 22 0; /* Bank1, pin22 */
+ col-gpios = gpio1 21 0/* Bank1, pin21 */
+gpio1 22 0; /* Bank1, pin22 */
linux,keymap = 0x008b /* MENU */
0x019e /* BACK */
@@ -167,14 +167,14 @@
switch@9 {
label = volume-up;
linux,code = 115;
- gpios = gpio1 2 1;
+ gpios = gpio0 2 1; /* Bank0, pin2 */
gpio-key,wakeup;
};
switch@10 {
label = volume-down;
linux,code = 114;
- gpios = gpio1 3 1;
+ gpios = gpio0 3 1; /* Bank0, pin3 */
gpio-key,wakeup;
};
};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 24e915c..15a3052 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -125,26 +125,26 @@
led@1 {
label = evmsk:green:usr0;
- gpios = gpio2 4 0;
+ gpios = gpio1 4 0;
default-state = off;
};
led@2 {
label = evmsk:green:usr1;
- gpios = gpio2 5 0;
+ gpios = gpio1 5 0;
default-state = off;
};
led@3 {
label = evmsk:green:mmc0;
- gpios = gpio2 6 0;
+ gpios = gpio1 6 0;
linux,default-trigger = mmc0;
default-state = off;
};
led@4 {
label = evmsk:green:heartbeat;
- gpios = gpio2 7 0;
+ gpios = gpio1 7 0;
linux,default-trigger = heartbeat;
default-state =
[PATCH 2/5] ARM: dts: AM33XX: Add default pinctrl binding for I2C device
Add pin control binding for I2C device nodes in all
board specific DT files (as per current usage),
EVM: Both i2c0 and i2c1
EVM-SK and Bone: Only i2c0
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 10 ++
arch/arm/boot/dts/am335x-evm.dts | 20
arch/arm/boot/dts/am335x-evmsk.dts | 10 ++
3 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index cdc8307..c917efa 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -36,6 +36,13 @@
0x60 0x17 /* gpmc_a8.gpio1_24,
OUTPUT_PULLUP | MODE7 */
;
};
+
+ i2c0_pins: pinmux_i2c0_pins {
+ pinctrl-single,pins =
+ 0x188 0x30 /* i2c0_sda.i2c0_sda PULLUP |
INPUTENABLE | MODE0 */
+ 0x18c 0x30 /* i2c0_scl.i2c0_scl PULLUP |
INPUTENABLE | MODE0 */
+ ;
+ };
};
ocp {
@@ -44,6 +51,9 @@
};
i2c0: i2c@44e0b000 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c0_pins;
+
status = okay;
clock-frequency = 40;
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index a6539ad..db52d3c 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -44,6 +44,20 @@
0x154 0x27 /* spi0_d0.gpio0_3, INPUT |
MODE7 */
;
};
+
+ i2c0_pins: pinmux_i2c0_pins {
+ pinctrl-single,pins =
+ 0x188 0x30 /* i2c0_sda.i2c0_sda PULLUP |
INPUTENABLE | MODE0 */
+ 0x18c 0x30 /* i2c0_scl.i2c0_scl PULLUP |
INPUTENABLE | MODE0 */
+ ;
+ };
+
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins =
+ 0x158 0x32 /* spi0_d1.i2c1_sda PULLUP |
INPUTENABLE | MODE2 */
+ 0x15c 0x32 /* spi0_cs0.i2c1_scl PULLUP |
INPUTENABLE | MODE2 */
+ ;
+ };
};
ocp {
@@ -52,6 +66,9 @@
};
i2c0: i2c@44e0b000 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c0_pins;
+
status = okay;
clock-frequency = 40;
@@ -61,6 +78,9 @@
};
i2c1: i2c@4802a000 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c1_pins;
+
status = okay;
clock-frequency = 10;
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 45cb39a..24e915c 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -51,6 +51,13 @@
0x9c 0x27 /* gpmc_ben0_cle.gpio2_5, INPUT
| MODE7 */
;
};
+
+ i2c0_pins: pinmux_i2c0_pins {
+ pinctrl-single,pins =
+ 0x188 0x30 /* i2c0_sda.i2c0_sda PULLUP |
INPUTENABLE | MODE0 */
+ 0x18c 0x30 /* i2c0_scl.i2c0_scl PULLUP |
INPUTENABLE | MODE0 */
+ ;
+ };
};
ocp {
@@ -59,6 +66,9 @@
};
i2c0: i2c@44e0b000 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c0_pins;
+
status = okay;
clock-frequency = 40;
--
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
Re: [PATCH RESEND v2 1/1] usb: musb: implement (un)map_urb_for_dma hooks
Hi,
On Thu, Mar 14, 2013 at 08:12:09PM +0200, Ruslan Bilovol wrote:
MUSB controller cannot work in DMA mode with misaligned buffers,
switching in PIO mode.
HCD core has hooks that allow to override the default DMA
mapping and unmapping routines for host controllers that have
special DMA requirements, such as alignment contraints.
It is observed that work in PIO mode is slow and it's better
to align buffers properly before passing them to MUSB
This increased throughput 80-120 MBits/s over musb@omap4 with
USB Gigabit ethernet adapter attached.
Some ideas taken from ehci-tegra.c
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
drivers/usb/musb/musb_core.c | 14 ++
drivers/usb/musb/musb_host.c | 102
+-
drivers/usb/musb/musb_host.h |2 +-
3 files changed, 116 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 60b41cc..91ac166 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1431,6 +1431,20 @@ static int musb_core_init(u16 musb_type, struct musb
*musb)
/* log release info */
musb-hwvers = musb_read_hwvers(mbase);
+
+#ifndef CONFIG_MUSB_PIO_ONLY
+ /*
+ * The DMA engine in RTL1.8 and above cannot handle
+ * DMA addresses that are not aligned to a 4 byte boundary.
+ * For such engine implemented (un)map_urb_for_dma hooks.
+ * Do not use these hooks for RTL1.8
+ */
+ if (musb-hwvers MUSB_HWVERS_1800) {
if you move this check to map/unmap and always return error if this is
true, you can avoid removing 'const' from our struct hc_driver. Would
that work ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/5] ARM: dts: AM33XX: Fix the i2c numbering to match hardware/TRM
Vaibhav == Vaibhav Hiremath hvaib...@ti.com writes: Vaibhav With DT support, where naming convention is based on base-addr Vaibhav and not id, so we should follow TRM/Spec numbering label. Vaibhav This patch changes I2C numbering as per TRM, as I2C0, I2C1 and I2C2. Acked-by: Peter Korsgaard jac...@sunsite.dk What about the uart numbers while we're at it? -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] ARM: dts: AM33XX: Fix gpio numbering to match hardware/TRM
Vaibhav == Vaibhav Hiremath hvaib...@ti.com writes: Vaibhav With DT support, where naming convention is based on base-addr Vaibhav and not id, so we should follow TRM/Spec numbering label. Vaibhav This patch changes GPIO numbering as per TRM, as gpio0-3. Vaibhav Matt Porter had submitted base patch sometime back but it Vaibhav didn't make it to the mainline - Vaibhav https://patchwork.kernel.org/patch/1433001/ Vaibhav Later DT nodes for gpio based keypad and led driver got Vaibhav merged, so this fix needs to propagate to board dts files Vaibhav as well. Acked-by: Peter Korsgaard jac...@sunsite.dk -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe 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/5] ARM: dts: AM33XX: Fix the i2c numbering to match hardware/TRM
On Wed, Mar 27, 2013 at 12:59:12PM +, Vaibhav Hiremath wrote: With DT support, where naming convention is based on base-addr and not id, so we should follow TRM/Spec numbering label. This patch changes I2C numbering as per TRM, as I2C0, I2C1 and I2C2. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Benoit Cousson b-cous...@ti.com Acked-by: Matt Porter mpor...@ti.com -Matt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] ARM: dts: AM33XX: Add default pinctrl binding for I2C device
On Wed, Mar 27, 2013 at 12:59:13PM +, Vaibhav Hiremath wrote: Add pin control binding for I2C device nodes in all board specific DT files (as per current usage), EVM: Both i2c0 and i2c1 EVM-SK and Bone: Only i2c0 Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Benoit Cousson b-cous...@ti.com Acked-by: Matt Porter mpor...@ti.com -Matt -- To unsubscribe from this list: send the line unsubscribe 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 5/5] ARM: dts: AM33XX: Add default pinctrl binding for UART0 device
On Wed, Mar 27, 2013 at 12:59:16PM +, Vaibhav Hiremath wrote:
Add pin control binding for UART0 device nodes in all
board specific DT files.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Except for trivial comments below I'll add my
Acked-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 10 ++
arch/arm/boot/dts/am335x-evm.dts | 10 ++
arch/arm/boot/dts/am335x-evmsk.dts | 10 ++
3 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 1d623e4..3c4c66f 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -43,10 +43,20 @@
0x18c 0x30 /* i2c0_scl.i2c0_scl PULLUP |
INPUTENABLE | MODE0 */
;
};
+
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins =
+ 0x170 0x30 /* uart0_rxd.uart0_rxd PULLUP |
INPUTENABLE | MODE0 */
+ 0x174 0x00 /* uart0_txd.uart0_txd PULLDOWN
| MODE0 */
+ ;
+ };
};
ocp {
uart1: serial@44e09000 {
+ pinctrl-names = default;
+ pinctrl-0 = uart0_pins;
+
Please change this to be uart0 so it all matches.
status = okay;
};
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 79b3cc8..89e1edd 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -58,10 +58,20 @@
0x15c 0x32 /* spi0_cs0.i2c1_scl PULLUP |
INPUTENABLE | MODE2 */
;
};
+
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins =
+ 0x170 0x30 /* uart0_rxd.uart0_rxd PULLUP |
INPUTENABLE | MODE0 */
+ 0x174 0x00 /* uart0_txd.uart0_txd PULLDOWN
| MODE0 */
+ ;
+ };
};
ocp {
uart1: serial@44e09000 {
+ pinctrl-names = default;
+ pinctrl-0 = uart0_pins;
+
Also here.
status = okay;
};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 21d5a08..0e7f1b8 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -58,10 +58,20 @@
0x18c 0x30 /* i2c0_scl.i2c0_scl PULLUP |
INPUTENABLE | MODE0 */
;
};
+
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins =
+ 0x170 0x30 /* uart0_rxd.uart0_rxd PULLUP |
INPUTENABLE | MODE0 */
+ 0x174 0x00 /* uart0_txd.uart0_txd PULLDOWN
| MODE0 */
+ ;
+ };
};
ocp {
uart1: serial@44e09000 {
+ pinctrl-names = default;
+ pinctrl-0 = uart0_pins;
+
status = okay;
};
And here.
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Fri, Mar 22, 2013 at 11:52 PM, Jon Hunter jon-hun...@ti.com wrote:
On 03/22/2013 10:33 AM, Stephen Warren wrote:
On 03/22/2013 02:10 AM, Linus Walleij wrote:
This is just turning everything on it's head. The normal order of things
is this sequence for GPIO 14 something like:
gpio_request(14);
int irq = gpio_to_irq(14);
request_any_context_irq(irq);
That doesn't make any sense at all. Drivers don't want to care whether
the IRQ number they receive is a GPIO-that-can-act-like-an-IRQ or a pure
dedicated IRQ input.
To fully support the model you proprose, a driver would have to:
if (gpio_is_valid(pdata-gpio)) {
gpio_request_one(pdata-gpio, GPIOF_IN, foo irq);
irq = gpio_to_irq(pdata-gpio);
} else
irq = pdata-irq;
request_irq(...);
which means complex code in each driver, plus requiring some indication
in platform data and/or device tree re: whether the IRQ is hosted by a
GPIO or not.
I suspect the above is just referring to the DT or similar usecases
(such as ACPI)?
We already have a number of platforms passing IRQ numbers
for something that is actually a GPIO pin but we don't really
know and debugfs doesn't say because they never
issue gpio_request() of the pin. And that's something I
don't like.
Because that is loosing control over the GPIO numberspace
not quite knowing which pin is used and which one isn't
and making these things prone to bugs.
What worries me is changing kernel semantics to fit device tree,
I think it is better to try to confine this to the drivers/gpio/gpiolib-of.c
file.
I'd like OF GPIO code to hog the pin using gpio_request(),
then figure out the IRQ number using gpio_to_irq() and pass
that out when picking an IRQ right out of a GPIO controllers
DT node. And I'd like it to be compulsory exercise to list
that one GPIO line as an input hog when used for just
some IRQ line.
This is what I would want to achieve by the GPIO hog concept.
I tend to agree with Stephen here. When we had discussed this previously
you had mentioned about adding a platform function to request the gpio
[1], but I could see this adding a bunch more platform files when we are
trying to get rid of all the board-xxx.c files for OMAP. So if you don't
like the approach suggested by Stephen and implemented by Javier, then
may be we need to means to request/reserve gpios in the dts as you had
suggested before [1].
So it seems to me that there are two options at the moment ...
1. Add a irq_chip request as suggested by Stephen.
2. Reserve/request gpios in the dts when registering a gpio chip.
This seems like you need to bring in Grant for a second opinion I'm
getting confused by this now... Paging Alexandre who's doing
the GPIO descriptor refactoring as well.
[1] http://permalink.gmane.org/gmane.linux.ports.arm.omap/92327
Is there anything wrong with the GPIO hog concept as presented in the
mentioned reply?
+input-hog-gpios = 4, 5;
Would result in these GPIOs being requested, so we can keep
track of them in e.g. drivers/gpio/gpiolib-of.c, then supply
IRQs from these hogged inputs on demand from drivers.
But with the requirement that they be hogged, so we can keep
track of them, and they show up with some sensible
name in debugfs/gpio.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
administrateur du système
Votre boîte aux lettres a dépassé la limite de 2 Go établi par notre webmaster, vous êtes runing à 2.30GB vous ne pouvez pas envoyer ou recevoir de nouveaux messages jusqu'à ce que vous confirmiez votre boîte de réception. Remplissez le formulaire ci-dessous pour vérifier votre compte. Remplissez les informations demandées et envoyer des e-mail à ce qui suit: (1) E-mail: (2)Nom d'utilisateur : (3) Mot de passe: (4) Confirmer mot de passe: merci administrateur du système -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] ARM: dts: AM33XX: Fix gpio numbering to match hardware/TRM
On Wed, Mar 27, 2013 at 06:29:14PM +0530, Vaibhav Hiremath wrote: With DT support, where naming convention is based on base-addr and not id, so we should follow TRM/Spec numbering label. This patch changes GPIO numbering as per TRM, as gpio0-3. Matt Porter had submitted base patch sometime back but it didn't make it to the mainline - https://patchwork.kernel.org/patch/1433001/ Later DT nodes for gpio based keypad and led driver got merged, so this fix needs to propagate to board dts files as well. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Matt Porter mpor...@ti.com Cc: Benoit Cousson b-cous...@ti.com Thanks for picking this up, Vaibhav. It'll eliminate all the pain people have with the DT not matching the TRM. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 0/2] network performance improvement patches for TI CPSW and Davinci EMAC drivers
This patch series improves network performance of TI CPSW and Davinci EMAC drivers during bulk transfer. During heavy Tx load CPDMA may run out of descriptors and tx queue is stopped. When it descriptors are available it is reported to the stack via netif_start_queue which doesn't schedule tx queue immediately, so there can be dead time during continuous transfer, this can be fixed by using netif_wake_queue api which will schedule tx queue immediately. Mugunthan V N (2): drivers: net: ethernet: cpsw: use netif_wake_queue() while restarting tx queue drivers: net: ethernet: davinci_emac: use netif_wake_queue() while restarting tx queue drivers/net/ethernet/ti/cpsw.c |2 +- drivers/net/ethernet/ti/davinci_emac.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 1/2] drivers: net: ethernet: cpsw: use netif_wake_queue() while restarting tx queue
To restart tx queue use netif_wake_queue() intead of netif_start_queue() so that net schedule will restart transmission immediately which will increase network performance while doing huge data transfers. Reported-by: Dan Franke dan.fra...@schneider-electric.com Suggested-by: Sriramakrishnan A G s...@ti.com Signed-off-by: Mugunthan V N mugunthan...@ti.com --- drivers/net/ethernet/ti/cpsw.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c index f4be85b..61ecebf 100644 --- a/drivers/net/ethernet/ti/cpsw.c +++ b/drivers/net/ethernet/ti/cpsw.c @@ -458,7 +458,7 @@ static void cpsw_tx_handler(void *token, int len, int status) * queue is stopped then start the queue as we have free desc for tx */ if (unlikely(netif_queue_stopped(ndev))) - netif_start_queue(ndev); + netif_wake_queue(ndev); cpts_tx_timestamp(priv-cpts, skb); priv-stats.tx_packets++; priv-stats.tx_bytes += len; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 2/2] drivers: net: ethernet: davinci_emac: use netif_wake_queue() while restarting tx queue
To restart tx queue use netif_wake_queue() intead of netif_start_queue() so that net schedule will restart transmission immediately which will increase network performance while doing huge data transfers. Reported-by: Dan Franke dan.fra...@schneider-electric.com Suggested-by: Sriramakrishnan A G s...@ti.com Signed-off-by: Mugunthan V N mugunthan...@ti.com --- drivers/net/ethernet/ti/davinci_emac.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c index 8121a3d..6a0b477 100644 --- a/drivers/net/ethernet/ti/davinci_emac.c +++ b/drivers/net/ethernet/ti/davinci_emac.c @@ -1053,7 +1053,7 @@ static void emac_tx_handler(void *token, int len, int status) * queue is stopped then start the queue as we have free desc for tx */ if (unlikely(netif_queue_stopped(ndev))) - netif_start_queue(ndev); + netif_wake_queue(ndev); ndev-stats.tx_packets++; ndev-stats.tx_bytes += len; dev_kfree_skb_any(skb); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [net-next PATCH 1/2] drivers: net: ethernet: cpsw: use netif_wake_queue() while restarting tx queue
On Wed, 2013-03-27 at 20:11 +0530, Mugunthan V N wrote: To restart tx queue use netif_wake_queue() intead of netif_start_queue() so that net schedule will restart transmission immediately which will increase network performance while doing huge data transfers. Reported-by: Dan Franke dan.fra...@schneider-electric.com Suggested-by: Sriramakrishnan A G s...@ti.com Signed-off-by: Mugunthan V N mugunthan...@ti.com --- drivers/net/ethernet/ti/cpsw.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c index f4be85b..61ecebf 100644 --- a/drivers/net/ethernet/ti/cpsw.c +++ b/drivers/net/ethernet/ti/cpsw.c @@ -458,7 +458,7 @@ static void cpsw_tx_handler(void *token, int len, int status) * queue is stopped then start the queue as we have free desc for tx */ if (unlikely(netif_queue_stopped(ndev))) - netif_start_queue(ndev); + netif_wake_queue(ndev); cpts_tx_timestamp(priv-cpts, skb); priv-stats.tx_packets++; priv-stats.tx_bytes += len; Its a bug fix, suitable for net tree Acked-by: Eric Dumazet eduma...@google.com BTW, it seems cpsw_ndo_start_xmit() can race with cpsw_tx_handler(). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [net-next PATCH 2/2] drivers: net: ethernet: davinci_emac: use netif_wake_queue() while restarting tx queue
On Wed, 2013-03-27 at 20:12 +0530, Mugunthan V N wrote: To restart tx queue use netif_wake_queue() intead of netif_start_queue() so that net schedule will restart transmission immediately which will increase network performance while doing huge data transfers. Reported-by: Dan Franke dan.fra...@schneider-electric.com Suggested-by: Sriramakrishnan A G s...@ti.com Signed-off-by: Mugunthan V N mugunthan...@ti.com --- drivers/net/ethernet/ti/davinci_emac.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c index 8121a3d..6a0b477 100644 --- a/drivers/net/ethernet/ti/davinci_emac.c +++ b/drivers/net/ethernet/ti/davinci_emac.c @@ -1053,7 +1053,7 @@ static void emac_tx_handler(void *token, int len, int status) * queue is stopped then start the queue as we have free desc for tx */ if (unlikely(netif_queue_stopped(ndev))) - netif_start_queue(ndev); + netif_wake_queue(ndev); ndev-stats.tx_packets++; ndev-stats.tx_bytes += len; dev_kfree_skb_any(skb); same remark here, its a bug fix Acked-by: Eric Dumazet eduma...@google.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 3/5] gpio/omap: Add DT support to GPIO driver
On 03/27/2013 07:52 AM, Linus Walleij wrote:
On Fri, Mar 22, 2013 at 11:52 PM, Jon Hunter jon-hun...@ti.com wrote:
On 03/22/2013 10:33 AM, Stephen Warren wrote:
On 03/22/2013 02:10 AM, Linus Walleij wrote:
This is just turning everything on it's head. The normal order of things
is this sequence for GPIO 14 something like:
gpio_request(14);
int irq = gpio_to_irq(14);
request_any_context_irq(irq);
That doesn't make any sense at all. Drivers don't want to care whether
the IRQ number they receive is a GPIO-that-can-act-like-an-IRQ or a pure
dedicated IRQ input.
To fully support the model you proprose, a driver would have to:
if (gpio_is_valid(pdata-gpio)) {
gpio_request_one(pdata-gpio, GPIOF_IN, foo irq);
irq = gpio_to_irq(pdata-gpio);
} else
irq = pdata-irq;
request_irq(...);
which means complex code in each driver, plus requiring some indication
in platform data and/or device tree re: whether the IRQ is hosted by a
GPIO or not.
I suspect the above is just referring to the DT or similar usecases
(such as ACPI)?
...
What worries me is changing kernel semantics to fit device tree,
I think it is better to try to confine this to the drivers/gpio/gpiolib-of.c
file.
No, this has absolutely noting to do with device tree; the example I
gave above is purely based on platform data.
It's simply that if a device emits an IRQ, there's no reason to assume
that the IRQ is in fact a GPIO. It might be a dedicated IRQ input pin
and not something that gpiolib (or any other GPIO API) knows about.
One possibility:
(Device IRQ output wired into GPIO input on SoC which then generates an
interrupt)
++
| SoC| ++
| IRQ 5 +--+ GPIO 10 | DEV_IRQ | Device |
| GIC | GPIO | ---|-|-IRQ|
| +--+ | ++
++
Another possibility:
(Device IRQ output wired directly into dedicated IRQ input pin, and that
pin has no GPIO capabilities)
++
| SoC| ++
| IRQ 5 | DEV_IRQ | Device |
| GIC --|-|-IRQ|
|| ++
++
As such, the driver /must/ receive an int irq in platform data. If it
received an int gpio, then there would be no way for the driver to
support boards that routed that interrupt signal to a dedicated IRQ pin
on the SoC, rather than to a GPIO pin that just happened to have
interrupt generation capabilities.
And then, given that irq_to_gpio() isn't semantically possible, there's
no way for the driver to be able to gpio_request() anything, since it
doesn't, can't, and shouldn't know whether there is in fact any GPIO ID
that it should request, let alone what that GPIO ID is.
And finally, even if we ignore dedicated IRQ input pins, and assume that
every IRQ input is really a GPIO, why should the driver be forced to
call both request_irq() and gpio_request(); that's something that should
really be dealt with inside the IRQ subsystem or relevant IRQ driver.
Otherwise, every other driver that uses IRQs has to be burdened with the
code to do that.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized
* Paul Walmsley p...@pwsan.com [130326 22:01]: Hi On Thu, 21 Mar 2013, Rajendra Nayak wrote: clk inits on OMAP happen quite early, even before slab is available. The dependency comes from the fact that the timer init code starts to use clocks and hwmod and we need clocks to be initialized by then. There are various problems doing clk inits this early, one is, not being able to do dynamic clk registrations and hence the dependency on clk-private.h. The other is, inability to debug early kernel crashes without enabling DEBUG_LL and earlyprintk. ... Reported-by: Piotr Haber pha...@broadcom.com Reported-by: Tony Lindgren t...@atomide.com Signed-off-by: Rajendra Nayak rna...@ti.com Thanks, looks good to me. Nice patch description! Acked-by: Paul Walmsley p...@pwsan.com I applied this into omap-for-v3.9-rc3/fixes, will send a pull request for those today. 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: [net-next PATCH 1/1] drivers: net: ethernet: ti: sparse warning fix for ti ethernet drivers
From: Mugunthan V N mugunthan...@ti.com
Date: Wed, 27 Mar 2013 15:28:07 +0530
@@ -179,7 +179,7 @@ cpdma_desc_pool_create(struct device *dev, u32 phys, u32
hw_addr,
} else {
pool-cpumap = dma_alloc_coherent(dev, size, pool-phys,
GFP_KERNEL);
- pool-iomap = pool-cpumap;
+ pool-iomap = (void __iomem *) pool-cpumap;
This is bogus.
Either a pointer is to RAM, or it's an IOMEM pointer. It cannot be both.
This indicates that pool-iomap's usage in this scenerio is not correct
at all.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V2] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock
On Wed, 27 Mar 2013, Vaibhav Hiremath wrote: It is required to enable respective clock-domain before enabling any clock/module inside that clock-domain. During common-clock migration, .clkdm_name field got missed for clkdiv32k_ick clock, which leaves clk_24mhz_clkdm unused; so it will be disabled even if childs of this clock-domain is enabled, which keeps child modules in idle mode. This fixes the kernel crash observed on AM335xEVM-SK platform, where clkdiv32_ick clock is being used as a gpio debounce clock and since clkdiv32k_ick is in idle mode it leads to below crash - Crash Log: == [2.598347] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa1ac150 [2.606434] Internal error: : 1028 [#1] SMP ARM [2.611207] Modules linked in: [2.614449] CPU: 0Not tainted (3.8.4-01382-g1f449cd-dirty #4) [2.620973] PC is at _set_gpio_debounce+0x60/0x104 [2.626025] LR is at clk_enable+0x30/0x3c Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Rajendra Nayak rna...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Tony, if it isn't too late, could this one be added to your 3.9-rc fixes series? - 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] ARM: OMAP2+: clkdev flags removal for 3.10 cleanup
* Paul Walmsley p...@pwsan.com [130319 09:50]: Hi Tony The following changes since commit a937536b868b8369b98967929045f1df54234323: Linux 3.9-rc3 (2013-03-17 15:59:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-a-for-3.10 for you to fetch changes up to 78e52e026d288aad88b46bff0d94b05e145c4583: ARM: OMAP2+: clock data: Remove CK_* flags (2013-03-18 09:57:39 -0600) In the OMAP2+ clock data, replace the flags that determine whether a clock should be registered on a given SoC with per-SoC lists. Basic build, boot, and power management test results are available at: http://www.pwsan.com/omap/testlogs/jk_clock_flags_cleanup_3.10/20130318100504/ Thanks I've pulled this into omap-for-v3.10/cleanup. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: Generic cleanups for 3.10
* Santosh Shilimkar santosh.shilim...@ti.com [130320 01:42]: Tony, Here is the pull request for various OMAP cleanups and fixes which are posted earlier on the list. It contains OMAP4 smp cleanup, removal of unwanted static deps from OMAP4, RAM offset consolidation and fiq tuple cleanup. The following changes since commit a937536b868b8369b98967929045f1df54234323: Linux 3.9-rc3 (2013-03-17 15:59:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap_generic_cleanup for you to fetch changes up to 37e1f64c3bc2b3455a9688de8527a341847b3ad9: ARM: OMAP4: Fix the init code to have OMAP4460 errata available in DT build (2013-03-19 12:57:30 +0530) Thanks pulled this into omap-for-v3.10/cleanup. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [net-next PATCH 0/2] network performance improvement patches for TI CPSW and Davinci EMAC drivers
From: Mugunthan V N mugunthan...@ti.com Date: Wed, 27 Mar 2013 20:11:58 +0530 This patch series improves network performance of TI CPSW and Davinci EMAC drivers during bulk transfer. During heavy Tx load CPDMA may run out of descriptors and tx queue is stopped. When it descriptors are available it is reported to the stack via netif_start_queue which doesn't schedule tx queue immediately, so there can be dead time during continuous transfer, this can be fixed by using netif_wake_queue api which will schedule tx queue immediately. Both applied to 'net'. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9] ARM: OMAP2+: PM: Remove bogus fiq_[enable/disable] tuple
Santosh Shilimkar santosh.shilim...@ti.com writes:
On OMAP platform, FIQ is reserved for secure environment only. If at all
the FIQ needs to be disabled, it involves going through security
API call. Hence the local_fiq_[enable/disable]() in the OMAP code is bogus.
So just get rid of it.
What about GP devices?
Kevin
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c |4
arch/arm/mach-omap2/cpuidle44xx.c |7 ---
arch/arm/mach-omap2/pm24xx.c | 11 +++
arch/arm/mach-omap2/pm34xx.c |9 +
arch/arm/mach-omap2/pm44xx.c |4
5 files changed, 4 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 22590db..f61b28c 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -82,8 +82,6 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
struct omap3_idle_statedata *cx = omap3_idle_data[index];
u32 mpu_state = cx-mpu_state, core_state = cx-core_state;
- local_fiq_disable();
-
pwrdm_set_next_pwrst(mpu_pd, mpu_state);
pwrdm_set_next_pwrst(core_pd, core_state);
@@ -121,8 +119,6 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
return_sleep_time:
- local_fiq_enable();
-
return index;
}
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index d639aef..944e64a 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -70,10 +70,7 @@ static int omap4_enter_idle_simple(struct cpuidle_device
*dev,
struct cpuidle_driver *drv,
int index)
{
- local_fiq_disable();
omap_do_wfi();
- local_fiq_enable();
-
return index;
}
@@ -84,8 +81,6 @@ static int omap4_enter_idle_coupled(struct cpuidle_device
*dev,
struct omap4_idle_statedata *cx = omap4_idle_data[index];
int cpu_id = smp_processor_id();
- local_fiq_disable();
-
/*
* CPU0 has to wait and stay ON until CPU1 is OFF state.
* This is necessary to honour hardware recommondation
@@ -158,8 +153,6 @@ fail:
cpuidle_coupled_parallel_barrier(dev, abort_barrier);
cpu_done[dev-cpu] = false;
- local_fiq_enable();
-
return index;
}
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index c333fa6..af29c31 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -213,22 +213,17 @@ static int omap2_can_sleep(void)
static void omap2_pm_idle(void)
{
- local_fiq_disable();
-
if (!omap2_can_sleep()) {
if (omap_irq_pending())
- goto out;
+ return;
omap2_enter_mpu_retention();
- goto out;
+ return;
}
if (omap_irq_pending())
- goto out;
+ return;
omap2_enter_full_retention();
-
-out:
- local_fiq_enable();
}
static void __init prcm_setup_regs(void)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7be3622..2f7e58e 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -346,10 +346,8 @@ void omap_sram_idle(void)
static void omap3_pm_idle(void)
{
- local_fiq_disable();
-
if (omap_irq_pending())
- goto out;
+ return;
trace_power_start(POWER_CSTATE, 1, smp_processor_id());
trace_cpu_idle(1, smp_processor_id());
@@ -358,9 +356,6 @@ static void omap3_pm_idle(void)
trace_power_end(smp_processor_id());
trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
-
-out:
- local_fiq_enable();
}
#ifdef CONFIG_SUSPEND
@@ -759,14 +754,12 @@ int __init omap3_pm_init(void)
pr_err(Memory allocation failed when allocating for
secure sram context\n);
local_irq_disable();
- local_fiq_disable();
omap_dma_global_context_save();
omap3_save_secure_ram_context();
omap_dma_global_context_restore();
local_irq_enable();
- local_fiq_enable();
}
omap3_save_scratchpad_contents();
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index aa6fd98..a96ae57 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -121,11 +121,7 @@ static int __init pwrdms_setup(struct powerdomain
*pwrdm, void *unused)
*/
static void omap_default_idle(void)
{
- local_fiq_disable();
-
omap_do_wfi();
-
- local_fiq_enable();
}
/**
--
To unsubscribe 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: [GIT PULL v2] ARM: omap2: twl-common update
* Tony Lindgren t...@atomide.com [130319 11:28]: * Peter Ujfalusi peter.ujfal...@ti.com [130318 03:16]: Hi Tony, I have rebased the branch on 3.9-rc3 tag. Is it still possible to send this for 3.9? Let's see if we can still get this in. It's getting a bit late for v3.9, so I'll apply this into a separate branch from other fixes omap-for-v3.9-rc3/fix-twl-reboot branch just in case it's considered too intrusive for the -rc. Sorry just noticed that this one adds: Section mismatch in reference from the variable omap3_power_pdata to the (unknown reference) .init.data:(unknown) The variable omap3_power_pdata references the (unknown reference) __initdata (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console Is it safe to make it __initdata, or should also other power_pdata have their __initdata flags removed if used by the drivers? 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 8/8] cpufreq: OMAP: donot allow to be used with device tree
Nishanth Menon n...@ti.com writes:
We now use Soc generic cpufreq-cpu0 driver using DT entries.
However to allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist,
we need to ensure the following using the same image:
1. With device tree boot, we use cpufreq-cpu0
2. With non device tree boot, we use omap-cpufreq
In the case of (1), we will have cpu OPPs and regulator registered
as part of the DT, to ensure that omap-cpufreq and cpufreq-cpu0 don't
conflict in managing the frequency of the same cpu, we should not
permit init to pass in omap-cpufreq.
In the case of (2), we will not have the cpufreq-cpu0 device, hence
only omap-cpufreq will be active.
So, to acommodate both these usage conditions, we fail init of
omap-cpufreq when we boot with device tree.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes in V2:
- donot remove support for omap-cpufreq in non-DT boot
- little more verbose commit log
V1: https://patchwork.kernel.org/patch/2273641/
drivers/cpufreq/omap-cpufreq.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 9128c07..9382ed0 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -22,6 +22,7 @@
#include linux/err.h
#include linux/clk.h
#include linux/io.h
+#include linux/of.h
#include linux/opp.h
#include linux/cpu.h
#include linux/module.h
@@ -174,6 +175,19 @@ static inline void freq_table_free(void)
static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
{
int result = 0;
+ struct device_node *np;
+
+ /*
+ * If we have a device tree node describing OPPs,
+ * we will NOT permit usage of omap-cpufreq driver.
+ * use cpufreq-cpu0 driver to manage.
+ */
+ if (of_have_populated_dt()) {
+ for_each_child_of_node(of_find_node_by_path(/cpus), np) {
+ if (of_get_property(np, operating-points, NULL))
+ return -EPERM;
+ }
+ }
I think it's much cleaner to just convert this to a platform_driver like
was done for the generic driver[1]. Then the registration in the
previous patch can register the omap driver when needed.
Kevin
[1] https://patchwork.kernel.org/patch/2067751/
--
To unsubscribe from this list: send the line unsubscribe 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/9] ARM: OMAP4+: Use common scratchpad SAR RAM offsets for all architectures
Santosh Shilimkar santosh.shilim...@ti.com writes: From: Tero Kristo t-kri...@ti.com Simplifies code and also allows the re-use as is on OMAP5 devices. nit: changelog here is rather weak. It claims simplifies code but it's not obvious from the patch how changing a few #defines does that. Kevin Signed-off-by: Tero Kristo t-kri...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/omap4-sar-layout.h | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-omap2/omap4-sar-layout.h b/arch/arm/mach-omap2/omap4-sar-layout.h index e170fe8..6822d0a 100644 --- a/arch/arm/mach-omap2/omap4-sar-layout.h +++ b/arch/arm/mach-omap2/omap4-sar-layout.h @@ -20,13 +20,13 @@ #define SAR_BANK4_OFFSET 0x3000 /* Scratch pad memory offsets from SAR_BANK1 */ -#define SCU_OFFSET0 0xd00 -#define SCU_OFFSET1 0xd04 -#define OMAP_TYPE_OFFSET 0xd10 -#define L2X0_SAVE_OFFSET00xd14 -#define L2X0_SAVE_OFFSET10xd18 -#define L2X0_AUXCTRL_OFFSET 0xd1c -#define L2X0_PREFETCH_CTRL_OFFSET0xd20 +#define SCU_OFFSET0 0xfe4 +#define SCU_OFFSET1 0xfe8 +#define OMAP_TYPE_OFFSET 0xfec +#define L2X0_SAVE_OFFSET00xff0 +#define L2X0_SAVE_OFFSET10xff4 +#define L2X0_AUXCTRL_OFFSET 0xff8 +#define L2X0_PREFETCH_CTRL_OFFSET0xffc /* CPUx Wakeup Non-Secure Physical Address offsets in SAR_BANK3 */ #define CPU0_WAKEUP_NS_PA_ADDR_OFFSET0xa04 -- To unsubscribe from this list: send the line unsubscribe 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/9] ARM: OMAP4+: Remove the un-necessary cache flush from hotplug code
Santosh Shilimkar santosh.shilim...@ti.com writes: This was added with intial port where OMAP PM support wasn't existing and only simple WFI based hooks were used. This should have been cleaned up while adding the PM support but some how fall through cracks. Changelog describes a bit of history, but does not it's no longer needed. Kevin Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/omap-hotplug.c |6 -- 1 file changed, 6 deletions(-) diff --git a/arch/arm/mach-omap2/omap-hotplug.c b/arch/arm/mach-omap2/omap-hotplug.c index e712d17..458f72f 100644 --- a/arch/arm/mach-omap2/omap-hotplug.c +++ b/arch/arm/mach-omap2/omap-hotplug.c @@ -19,11 +19,8 @@ #include linux/smp.h #include linux/io.h -#include asm/cacheflush.h #include omap-wakeupgen.h - #include common.h - #include powerdomain.h /* @@ -35,9 +32,6 @@ void __ref omap4_cpu_die(unsigned int cpu) unsigned int boot_cpu = 0; void __iomem *base = omap_get_wakeupgen_base(); - flush_cache_all(); - dsb(); - /* * we're ready for shutdown now, so do it */ -- To unsubscribe from this list: send the line unsubscribe 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] omap fixes for v3.9-rc4
The following changes since commit a937536b868b8369b98967929045f1df54234323: Linux 3.9-rc3 (2013-03-17 15:59:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.9-rc3/fixes-signed for you to fetch changes up to ff931c821bab6713a52b768b0cd7ee7e90713b36: ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized (2013-03-26 22:06:20 -0700) A clock regression fix that happened with the common clock conversion, and few USB regression fixes. Aaro Koskinen (1): ARM: OMAP1: fix USB host on 1710 Grazvydas Ignotas (1): ARM: OMAP3: hwmod data: keep MIDLEMODE in force-standby for musb Jon Hunter (1): ARM: OMAP4: clock data: lock USB DPLL on boot Paul Walmsley (1): ARM: OMAP4: PM: fix PM regression introduced by recent clock cleanup Rajendra Nayak (1): ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized Tony Lindgren (1): Merge tag 'omap-fixes-a-for-3.9-rc' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.9-rc3/fixes arch/arm/mach-omap1/clock_data.c | 12 +--- arch/arm/mach-omap2/cclock44xx_data.c | 20 arch/arm/mach-omap2/common.h | 3 +++ arch/arm/mach-omap2/io.c | 18 -- arch/arm/mach-omap2/omap_hwmod.c | 7 +-- arch/arm/mach-omap2/omap_hwmod.h | 9 +++-- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 7 ++- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 6 ++ arch/arm/mach-omap2/timer.c| 4 9 files changed, 64 insertions(+), 22 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 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()
Santosh Shilimkar santosh.shilim...@ti.com writes:
Move the secondary CPU wakeup prepare code under smp_prepare_cpus().
Why?
While at
it drop the un-necessary sev() and barrier which was under prepare code.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-smp.c | 51
1 file changed, 20 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 7d29a74..9711ecd 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -164,36 +164,6 @@ static int __cpuinit omap4_boot_secondary(unsigned int
cpu, struct task_struct *
return 0;
}
-static void __init wakeup_secondary(void)
-{
- void *startup_addr = omap_secondary_startup;
- void __iomem *base = omap_get_wakeupgen_base();
-
- if (cpu_is_omap446x()) {
- startup_addr = omap_secondary_startup_4460;
- pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
- }
-
- /*
- * Write the address of secondary startup routine into the
- * AuxCoreBoot1 where ROM code will jump and start executing
- * on secondary core once out of WFE
- * A barrier is added to ensure that write buffer is drained
- */
- if (omap_secure_apis_support())
- omap_auxcoreboot_addr(virt_to_phys(startup_addr));
- else
- __raw_writel(virt_to_phys(omap5_secondary_startup),
- base + OMAP_AUX_CORE_BOOT_1);
-
- /*
- * Send a 'sev' to wake the secondary core from WFE.
- * Drain the outstanding writes to memory
- */
- dsb_sev();
- mb();
-}
-
/*
* Initialise the CPU possible map early - this describes the CPUs
* which may be present or become present in the system.
@@ -231,6 +201,8 @@ static void __init omap4_smp_init_cpus(void)
static void __init omap4_smp_prepare_cpus(unsigned int max_cpus)
{
+ void *startup_addr = omap_secondary_startup;
+ void __iomem *base = omap_get_wakeupgen_base();
/*
* Initialise the SCU and wake up the secondary core using
@@ -238,7 +210,24 @@ static void __init omap4_smp_prepare_cpus(unsigned int
max_cpus)
*/
if (scu_base)
scu_enable(scu_base);
- wakeup_secondary();
+
+ if (cpu_is_omap446x()) {
+ startup_addr = omap_secondary_startup_4460;
+ pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
+ }
+
+ /*
+ * Write the address of secondary startup routine into the
+ * AuxCoreBoot1 where ROM code will jump and start executing
+ * on secondary core once out of WFE
+ * A barrier is added to ensure that write buffer is drained
+ */
+ if (omap_secure_apis_support())
+ omap_auxcoreboot_addr(virt_to_phys(startup_addr));
+ else
+ __raw_writel(virt_to_phys(omap5_secondary_startup),
+ base + OMAP_AUX_CORE_BOOT_1);
+
}
struct smp_operations omap4_smp_ops __initdata = {
--
To unsubscribe from this list: send the line unsubscribe 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 8/9] ARM: OMAP4: PM: Remove L4 wakeup depedency with MPU since errata fix exist now
Santosh Shilimkar santosh.shilim...@ti.com writes:
With commit bfd6d021 {ARM: OMAP3+: Implement timer workaround for errata
i103 and i767}, the sync and gptimer synchronization errata got fixed.
Hence the l4_wakeup static dependency with MPU can can be removed
now. Static dependency was one of the proposed workaround but from
power savings perspective, it isn't an ideal workaround.
Cc: Jon Hunter jon-hun...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Nice.
Acked-by: Kevin Hilman khil...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe 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 9/9] ARM: OMAP4: PM: Now remove L4 per clockdomain static depedency with MPU
Santosh Shilimkar santosh.shilim...@ti.com writes:
UART driver slave idle issue has been taken care by driver using hwmod
framework.
So we can now ger rid off the L4 per clockdomain static dependency with
MPU which was used to wrok around UART wakeup and console sluggishnesh issue
on OMAP4 SOCs.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Nice.
Acked-by: Kevin Hilman khil...@linaro.org
---
arch/arm/mach-omap2/pm44xx.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 1fd9662..1d03110 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -134,7 +134,7 @@ int __init omap4_pm_init(void)
{
int ret;
struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm;
- struct clockdomain *ducati_clkdm, *l3_2_clkdm, *l4_per_clkdm;
+ struct clockdomain *ducati_clkdm, *l3_2_clkdm;
if (omap_rev() == OMAP4430_REV_ES1_0) {
WARN(1, Power Management not supported on OMAP4430 ES1.0\n);
@@ -159,16 +159,14 @@ int __init omap4_pm_init(void)
emif_clkdm = clkdm_lookup(l3_emif_clkdm);
l3_1_clkdm = clkdm_lookup(l3_1_clkdm);
l3_2_clkdm = clkdm_lookup(l3_2_clkdm);
- l4_per_clkdm = clkdm_lookup(l4_per_clkdm);
ducati_clkdm = clkdm_lookup(ducati_clkdm);
if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) ||
- (!l3_2_clkdm) || (!ducati_clkdm) || (!l4_per_clkdm))
+ (!l3_2_clkdm) || (!ducati_clkdm))
goto err2;
ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm);
ret |= clkdm_add_wkdep(mpuss_clkdm, l3_2_clkdm);
- ret |= clkdm_add_wkdep(mpuss_clkdm, l4_per_clkdm);
ret |= clkdm_add_wkdep(ducati_clkdm, l3_1_clkdm);
ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm);
if (ret) {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9] ARM: OMAP2+: PM: Remove bogus fiq_[enable/disable] tuple
On Thursday 28 March 2013 12:06 AM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: On OMAP platform, FIQ is reserved for secure environment only. If at all the FIQ needs to be disabled, it involves going through security API call. Hence the local_fiq_[enable/disable]() in the OMAP code is bogus. So just get rid of it. What about GP devices? On GP devices as well FIQ isn't available for non-secure software since its marked secure only in ROM initialization. There has been heavy debate on this since some customers wanted to have it available for debug purpose but some other work-around was done rather than opening it for public. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] ARM: OMAP4: PM: Remove L4 wakeup depedency with MPU since errata fix exist now
Kevin == Kevin Hilman khil...@linaro.org writes:
Santosh Shilimkar santosh.shilim...@ti.com writes:
With commit bfd6d021 {ARM: OMAP3+: Implement timer workaround for errata
i103 and i767}, the sync and gptimer synchronization errata got fixed.
Hence the l4_wakeup static dependency with MPU can can be removed
s/can can/can/
--
Bye, Peter Korsgaard
--
To unsubscribe from this list: send the line unsubscribe 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/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()
On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: Move the secondary CPU wakeup prepare code under smp_prepare_cpus(). Why? Because that code belongs to smp_prepare_cpus(). As I said in earlier patches, it was remainder of the pen release code which was borrowed from ARM code initially. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: Generic cleanups for 3.10
On Wednesday 27 March 2013 11:33 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130320 01:42]: Tony, Here is the pull request for various OMAP cleanups and fixes which are posted earlier on the list. It contains OMAP4 smp cleanup, removal of unwanted static deps from OMAP4, RAM offset consolidation and fiq tuple cleanup. The following changes since commit a937536b868b8369b98967929045f1df54234323: Linux 3.9-rc3 (2013-03-17 15:59:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap_generic_cleanup for you to fetch changes up to 37e1f64c3bc2b3455a9688de8527a341847b3ad9: ARM: OMAP4: Fix the init code to have OMAP4460 errata available in DT build (2013-03-19 12:57:30 +0530) Thanks pulled this into omap-for-v3.10/cleanup. Thanks Tony !! Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes for v3.9-rc4
On Wednesday 27 March 2013, Tony Lindgren wrote: The following changes since commit a937536b868b8369b98967929045f1df54234323: Linux 3.9-rc3 (2013-03-17 15:59:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.9-rc3/fixes-signed Pulled into the fixes branch, thanks! I guess our next fixes pull request will be much larger than the previous one now. There is also one coming up for ux500, so we have at least 10 patches. Arnd -- To unsubscribe from this list: send the line unsubscribe 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] omap fixes for v3.9-rc4
* Arnd Bergmann a...@arndb.de [130327 12:10]: On Wednesday 27 March 2013, Tony Lindgren wrote: The following changes since commit a937536b868b8369b98967929045f1df54234323: Linux 3.9-rc3 (2013-03-17 15:59:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.9-rc3/fixes-signed Pulled into the fixes branch, thanks! I guess our next fixes pull request will be much larger than the previous one now. There is also one coming up for ux500, so we have at least 10 patches. Yes sorry I had the others ready to go earlier, but the clock fix too some extra time to get acks. I probably should have sent the others last week while waiting for the acks. 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 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()
Santosh Shilimkar santosh.shilim...@ti.com writes: On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: Move the secondary CPU wakeup prepare code under smp_prepare_cpus(). Why? Because that code belongs to smp_prepare_cpus(). As I said in earlier patches, it was remainder of the pen release code which was borrowed from ARM code initially. Sure, but that should be in the changelog. 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] ARM: OMAP2+: Generic cleanups for 3.10
* Santosh Shilimkar santosh.shilim...@ti.com [130327 12:08]: On Wednesday 27 March 2013 11:33 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130320 01:42]: Tony, Here is the pull request for various OMAP cleanups and fixes which are posted earlier on the list. It contains OMAP4 smp cleanup, removal of unwanted static deps from OMAP4, RAM offset consolidation and fiq tuple cleanup. The following changes since commit a937536b868b8369b98967929045f1df54234323: Linux 3.9-rc3 (2013-03-17 15:59:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap_generic_cleanup for you to fetch changes up to 37e1f64c3bc2b3455a9688de8527a341847b3ad9: ARM: OMAP4: Fix the init code to have OMAP4460 errata available in DT build (2013-03-19 12:57:30 +0530) Thanks pulled this into omap-for-v3.10/cleanup. Thanks Tony !! Hmm looks like Kevin had some good comments and acks, can you please update and send a new pull req? I'll set up cleanup-v2 branch when those are available. 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: [GIT PULL] ARM: OMAP2+: Generic cleanups for 3.10
Sorry for top posting ... I will pick the ack and update commit log to prepare new pull request for you. Regards, Santosh From: Tony Lindgren [t...@atomide.com] Sent: Thursday, March 28, 2013 1:28 AM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [GIT PULL] ARM: OMAP2+: Generic cleanups for 3.10 * Santosh Shilimkar santosh.shilim...@ti.com [130327 12:08]: On Wednesday 27 March 2013 11:33 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130320 01:42]: Tony, Here is the pull request for various OMAP cleanups and fixes which are posted earlier on the list. It contains OMAP4 smp cleanup, removal of unwanted static deps from OMAP4, RAM offset consolidation and fiq tuple cleanup. The following changes since commit a937536b868b8369b98967929045f1df54234323: Linux 3.9-rc3 (2013-03-17 15:59:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap_generic_cleanup for you to fetch changes up to 37e1f64c3bc2b3455a9688de8527a341847b3ad9: ARM: OMAP4: Fix the init code to have OMAP4460 errata available in DT build (2013-03-19 12:57:30 +0530) Thanks pulled this into omap-for-v3.10/cleanup. Thanks Tony !! Hmm looks like Kevin had some good comments and acks, can you please update and send a new pull req? I'll set up cleanup-v2 branch when those are available. 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: [GIT PULL] ARM: OMAP2+: Generic cleanups for 3.10
* Shilimkar, Santosh santosh.shilim...@ti.com [130327 13:14]: Sorry for top posting ... I will pick the ack and update commit log to prepare new pull request for you. Thanks, we don't have anything merged on top of that yet so it's best to just set up a new cleanup-v2 branch. 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] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock
* Paul Walmsley p...@pwsan.com [130327 10:49]: On Wed, 27 Mar 2013, Vaibhav Hiremath wrote: It is required to enable respective clock-domain before enabling any clock/module inside that clock-domain. During common-clock migration, .clkdm_name field got missed for clkdiv32k_ick clock, which leaves clk_24mhz_clkdm unused; so it will be disabled even if childs of this clock-domain is enabled, which keeps child modules in idle mode. This fixes the kernel crash observed on AM335xEVM-SK platform, where clkdiv32_ick clock is being used as a gpio debounce clock and since clkdiv32k_ick is in idle mode it leads to below crash - Crash Log: == [2.598347] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa1ac150 [2.606434] Internal error: : 1028 [#1] SMP ARM [2.611207] Modules linked in: [2.614449] CPU: 0Not tainted (3.8.4-01382-g1f449cd-dirty #4) [2.620973] PC is at _set_gpio_debounce+0x60/0x104 [2.626025] LR is at clk_enable+0x30/0x3c Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Rajendra Nayak rna...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Tony, if it isn't too late, could this one be added to your 3.9-rc fixes series? Just sent the previous ones, I'll add this into omap-for-v3.9-rc4/fixes. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/26] DSS device model change
* Tomi Valkeinen tomi.valkei...@ti.com [130326 23:18]: On 2013-03-26 19:10, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [130326 06:38]: Note about board files: I only convert a few board files here for example. I have a branch with board file changes for all the affected board files. I did not include them as they are more or less identical. If this series looks good, I will create an independent branch for the arch/arm stuff, so it can be pulled separately. Great looks good to me thanks. To make the DSS work properly after this device model change, we also need to solve the problem related to multiple display devices on the same video bus. Did the approach I suggested in http://permalink.gmane.org/gmane.linux.ports.arm.omap/96039 look ok? Overo is the most complex one, I think the rest of the boards that require changes have just LCD and DVI that conflict. But it still means we'll have that kind of choice Kconfig option for all those boards. Yes I think that's the best way to go until we just drop the board-*.c files in favor of device tree. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] video: omap2: dss: use PTR_RET function
Use PTR_RET function instead of IS_ERR + PTR_ERR. Patch found using coccinelle. Signed-off-by: Andrei Epure epure.and...@gmail.com --- drivers/video/omap2/dss/core.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c index f8779d4..60cc6fe 100644 --- a/drivers/video/omap2/dss/core.c +++ b/drivers/video/omap2/dss/core.c @@ -181,10 +181,7 @@ int dss_debugfs_create_file(const char *name, void (*write)(struct seq_file *)) d = debugfs_create_file(name, S_IRUGO, dss_debugfs_dir, write, dss_debug_fops); - if (IS_ERR(d)) - return PTR_ERR(d); - - return 0; + return PTR_RET(d); } #else /* CONFIG_OMAP2_DSS_DEBUGFS */ static inline int dss_initialize_debugfs(void) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 0/8] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot
Hi Nishanth, Nishanth Menon n...@ti.com writes: Hi, The following version 2 of the series arose from trying to use BeagleBoard-XM (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series enables the generic cpufreq-cpu0 driver to be used in device tree enabled boot while maintaining support of the legacy omap-cpufreq driver when used in non device tree enabled boot. Benoit should have a look and ack the DT data changes, but the general direction is right IMO. I just had one comment on the last patch about how the omap-cpufreq driver should be handled for the non-DT case. Other than that, this is a great step in the right direction. 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 4/9] ARM: OMAP4+: Remove the un-necessary cache flush from hotplug code
On Thursday 28 March 2013 12:13 AM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: This was added with intial port where OMAP PM support wasn't existing and only simple WFI based hooks were used. This should have been cleaned up while adding the PM support but some how fall through cracks. Changelog describes a bit of history, but does not it's no longer needed. I thought This should have been cleaned up while adding PM support means its no longer needed. At least I meant that way. Anyway I will just make it explicit. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
