[PATCH 0/2] OMAPDSS: DISPC: Update manager size limits for OMAP5
Manager width and height can go up to 4K on OMAP5. Make manager width and height register field offsets and maximum limits as dispc_features. Create a new dispc_feature struct for OMAP5 which highlights this difference. Archit Taneja (2): OMAPDSS: Add overlay manager width and height limits as a dispc feature OMAPDSS: Add a dispc_features struct for OMAP5 drivers/video/omap2/dss/dispc.c| 47 +--- drivers/video/omap2/dss/dss_features.c |8 -- drivers/video/omap2/dss/dss_features.h |2 -- 3 files changed, 43 insertions(+), 14 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
[PATCH 1/2] OMAPDSS: Add overlay manager width and height limits as a dispc feature
The overlay manager width and height vary in OMAP5 vary from previous OMAPs in
terms of maximum limit and register field positions. Add parameters in
dispc_features for these. Remove params related to manager width and height from
dss_features. We do this because we want to maintain a feature list for
individual IPs.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c| 28 +---
drivers/video/omap2/dss/dss_features.c |8
drivers/video/omap2/dss/dss_features.h |2 --
3 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index bab9d6b..29e6aa1 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -87,6 +87,10 @@ struct dispc_features {
u16 sw_max;
u16 vp_max;
u16 hp_max;
+ u8 mgr_width_start;
+ u8 mgr_height_start;
+ u16 mgr_width_max;
+ u16 mgr_height_max;
int (*calc_scaling) (enum omap_plane plane,
const struct omap_video_timings *mgr_timings,
u16 width, u16 height, u16 out_width, u16 out_height,
@@ -1128,7 +1132,9 @@ static void dispc_mgr_set_size(enum omap_channel channel,
u16 width,
{
u32 val;
- val = FLD_VAL(height - 1, 26, 16) | FLD_VAL(width - 1, 10, 0);
+ val = FLD_VAL(height - 1, dispc.feat-mgr_height_start, 16) |
+ FLD_VAL(width - 1, dispc.feat-mgr_width_start, 0);
+
dispc_write_reg(DISPC_SIZE_MGR(channel), val);
}
@@ -2985,8 +2991,8 @@ void dispc_mgr_set_lcd_config(enum omap_channel channel,
static bool _dispc_mgr_size_ok(u16 width, u16 height)
{
- return width = dss_feat_get_param_max(FEAT_PARAM_MGR_WIDTH)
- height = dss_feat_get_param_max(FEAT_PARAM_MGR_HEIGHT);
+ return width = dispc.feat-mgr_width_max
+ height = dispc.feat-mgr_height_max;
}
static bool _dispc_lcd_timings_ok(int hsw, int hfp, int hbp,
@@ -4067,6 +4073,10 @@ static const struct dispc_features omap24xx_dispc_feats
__initconst = {
.sw_max = 64,
.vp_max = 255,
.hp_max = 256,
+ .mgr_width_start= 10,
+ .mgr_height_start = 26,
+ .mgr_width_max = 2048,
+ .mgr_height_max = 2048,
.calc_scaling = dispc_ovl_calc_scaling_24xx,
.calc_core_clk = calc_core_clk_24xx,
.num_fifos = 3,
@@ -4079,6 +4089,10 @@ static const struct dispc_features
omap34xx_rev1_0_dispc_feats __initconst = {
.sw_max = 64,
.vp_max = 255,
.hp_max = 256,
+ .mgr_width_start= 10,
+ .mgr_height_start = 26,
+ .mgr_width_max = 2048,
+ .mgr_height_max = 2048,
.calc_scaling = dispc_ovl_calc_scaling_34xx,
.calc_core_clk = calc_core_clk_34xx,
.num_fifos = 3,
@@ -4091,6 +4105,10 @@ static const struct dispc_features
omap34xx_rev3_0_dispc_feats __initconst = {
.sw_max = 256,
.vp_max = 4095,
.hp_max = 4096,
+ .mgr_width_start= 10,
+ .mgr_height_start = 26,
+ .mgr_width_max = 2048,
+ .mgr_height_max = 2048,
.calc_scaling = dispc_ovl_calc_scaling_34xx,
.calc_core_clk = calc_core_clk_34xx,
.num_fifos = 3,
@@ -4103,6 +4121,10 @@ static const struct dispc_features omap44xx_dispc_feats
__initconst = {
.sw_max = 256,
.vp_max = 4095,
.hp_max = 4096,
+ .mgr_width_start= 10,
+ .mgr_height_start = 26,
+ .mgr_width_max = 2048,
+ .mgr_height_max = 2048,
.calc_scaling = dispc_ovl_calc_scaling_44xx,
.calc_core_clk = calc_core_clk_44xx,
.num_fifos = 5,
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index 8dcecbc..1d125c6 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -429,8 +429,6 @@ static const struct dss_param_range omap2_dss_param_range[]
= {
* scaler cannot scale a image with width more than 768.
*/
[FEAT_PARAM_LINEWIDTH] = { 1, 768 },
- [FEAT_PARAM_MGR_WIDTH] = { 1, 2048 },
- [FEAT_PARAM_MGR_HEIGHT] = { 1, 2048 },
};
static const struct dss_param_range omap3_dss_param_range[] =
[PATCH 2/2] OMAPDSS: Add a dispc_features struct for OMAP5
Add a dispc_features struct for OMAP5. Previously, OMAP5 used the same struct
as OMAP4. The new struct for OMAP5 contains the updated register field offset
and maximum limit for overlay manager width and height.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 29e6aa1..c681460 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -4131,6 +4131,23 @@ static const struct dispc_features omap44xx_dispc_feats
__initconst = {
.gfx_fifo_workaround= true,
};
+static const struct dispc_features omap54xx_dispc_feats __initconst = {
+ .sw_start = 7,
+ .fp_start = 19,
+ .bp_start = 31,
+ .sw_max = 256,
+ .vp_max = 4095,
+ .hp_max = 4096,
+ .mgr_width_start= 11,
+ .mgr_height_start = 27,
+ .mgr_width_max = 4096,
+ .mgr_height_max = 4096,
+ .calc_scaling = dispc_ovl_calc_scaling_44xx,
+ .calc_core_clk = calc_core_clk_44xx,
+ .num_fifos = 5,
+ .gfx_fifo_workaround= true,
+};
+
static int __init dispc_init_features(struct platform_device *pdev)
{
const struct dispc_features *src;
@@ -4164,7 +4181,7 @@ static int __init dispc_init_features(struct
platform_device *pdev)
break;
case OMAPDSS_VER_OMAP5:
- src = omap44xx_dispc_feats;
+ src = omap54xx_dispc_feats;
break;
default:
--
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
OMAP* Latest build failures
OMAP* allnoconfig fails: arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput': twl-common.c:(.text+0x1e08): undefined reference to `omap_pm_set_min_bus_tput' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_init_postsetup': twl-common.c:(.init.text+0x8f8): undefined reference to `omap_pm_if_early_init' arch/arm/mach-omap2/built-in.o: In function `omap_serial_init_port': twl-common.c:(.init.text+0x1284): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_timer_init': twl-common.c:(.init.text+0x1544): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_init': twl-common.c:(.init.text+0x1af0): undefined reference to `omap_pm_if_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': twl-common.c:(.init.text+0x2168): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_display_init': twl-common.c:(.init.text+0x25cc): undefined reference to `omap_pm_get_dev_context_loss_count' OMAP4 randconfig fails: arch/arm/mach-omap2/cm_common.c: In function 'cm_register': arch/arm/mach-omap2/cm_common.c:42:11: error: 'EINVAL' undeclared (first use in this function) arch/arm/mach-omap2/cm_common.c:45:11: error: 'EEXIST' undeclared (first use in this function) arch/arm/mach-omap2/cm_common.c: In function 'cm_unregister': arch/arm/mach-omap2/cm_common.c:66:11: error: 'EINVAL' undeclared (first use in this function) You know where to find the build information and results... -- To unsubscribe from this list: send the line unsubscribe 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 v4 2/2] ARM: OMAP3/4: iommu: adapt to runtime pm
Hi Omar, On Wed, Nov 14, 2012 at 4:34 AM, Omar Ramirez Luna omar.l...@linaro.org wrote: Use runtime PM functionality interfaced with hwmod enable/idle functions, to replace direct clock operations and sysconfig handling. Dues to reset sequence, pm_runtime_put_sync must be used, to avoid possible operations with the module under reset. There are some changes here that might not be trivial to understand in hindsight; any chance you can add more explanations (even only in the commit log) regarding: @@ -160,11 +160,10 @@ static int iommu_enable(struct omap_iommu *obj) ... - clk_enable(obj-clk); + pm_runtime_get_sync(obj-dev); err = arch_iommu-enable(obj); - clk_disable(obj-clk); return err; } Why do we remove clk_disable here (instead of replacing it with a _put variant) ? @@ -306,7 +303,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct iotlb_entry *e) if (!obj || !obj-nr_tlb_entries || !e) return -EINVAL; - clk_enable(obj-clk); + pm_runtime_get_sync(obj-dev); If iommu_enable no longer disables obj-clk before returning, do we really need to call -get here (and in all the other similar instances) ? @@ -816,9 +813,7 @@ static irqreturn_t iommu_fault_handler(int irq, void *data) if (!obj-refcount) return IRQ_NONE; - clk_enable(obj-clk); errs = iommu_report_fault(obj, da); - clk_disable(obj-clk); Why do we remove the clk_ invocations here (instead of replacing them with get/put variants) ? Most of the above questions imply this patch not only converts the iommu to runtime PM, but may carry additional changes that may imply previous implementation is sub-optimal. I hope we can clearly document the motivation behind these changes too (maybe even consider extracting them to a different patch ?). @@ -990,6 +981,9 @@ static int __devinit omap_iommu_probe(struct platform_device *pdev) goto err_irq; platform_set_drvdata(pdev, obj); + pm_runtime_irq_safe(obj-dev); Let's also document why _irq_safe is needed here ? Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP* Latest build failures
Hi Russell, On 11/14/2012 10:26 AM, Russell King - ARM Linux wrote: OMAP* allnoconfig fails: arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput': twl-common.c:(.text+0x1e08): undefined reference to `omap_pm_set_min_bus_tput' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_init_postsetup': twl-common.c:(.init.text+0x8f8): undefined reference to `omap_pm_if_early_init' arch/arm/mach-omap2/built-in.o: In function `omap_serial_init_port': twl-common.c:(.init.text+0x1284): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_timer_init': twl-common.c:(.init.text+0x1544): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_init': twl-common.c:(.init.text+0x1af0): undefined reference to `omap_pm_if_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': twl-common.c:(.init.text+0x2168): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_display_init': twl-common.c:(.init.text+0x25cc): undefined reference to `omap_pm_get_dev_context_loss_count' Not sure what is going on here but neither of these are referenced within twl-common.c directly. OMAP4 randconfig fails: arch/arm/mach-omap2/cm_common.c: In function 'cm_register': arch/arm/mach-omap2/cm_common.c:42:11: error: 'EINVAL' undeclared (first use in this function) arch/arm/mach-omap2/cm_common.c:45:11: error: 'EEXIST' undeclared (first use in this function) arch/arm/mach-omap2/cm_common.c: In function 'cm_unregister': arch/arm/mach-omap2/cm_common.c:66:11: error: 'EINVAL' undeclared (first use in this function) I have already sent a patch to fix this: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/131341.html You know where to find the build information and results... It seams I can not find the link in my mail archives. Could you point me to the correct place? -- Péter -- To unsubscribe from this list: send the line unsubscribe 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/4] mfd: tps65217: Set PMIC to shutdowm on PWR_EN toggle
Hi Mark, On 11/14/2012 08:00 AM, Mark Brown wrote: On Wed, Nov 14, 2012 at 06:49:58AM +, AnilKumar, Chimata wrote: Earlier you have a comment on this thread, I am adding my comments on top of it. Sorry if I am in wrong direction. Ah, I see. I was just commenting because Benoit was asking if this should be supported with a standard framework feature - I'm not convinced that it should right now as there's not any clear patterns in hardware behaviour. I've no specific interest in this system. I was wondering that, because exposing a pin to control the whole PMIC low power mode seems to be something that should be generic enough to be handled by the regulator framework. In the current situation we do have a pwr_en pin that can be controlled by a GPIO or whatever signal from the SoC. That's very similar, at PMIC level, to the fixedregulator that allow a GPIO binding to enable it. Don't you think that should deserve a support in the fmwk? 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: [PATCH 1/3] ASoC: OMAP: HDMI: Update machine driver name
On 14/11/12 02:30, Ricardo Neri wrote: Being the name of a machine driver, it aims to describe the connection between the HDMI IP of the processor and the companion chip it uses to connect to the outside world. This name tries to follow the same naming convention as in the OMAP-ABE-TWL6040 machine driver. TPD12S015 is an HDMI companion chip for DC-DC step-up, I2C level shifter and low-capacitance ESD protection. This chip is used on all OMAP4 Pandaboards an SDPs as well as in OMAP5 EVMs. Is the TPD12S015 passive or actively controlled by the CPU in this case ? If it's passive then it's not really worth changing the driver name since other OMAP4/5 devices may use other HDMI companion chips (an we can reuse this driver without changes). Liam -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Concerning OMAP v4l2 driver (omap_vout)
Hi Vaibhav, I'd like to get clarity on the omap_vout maintenance. You've been the maintainer of omap_vout, but you have lately been quite inactive in this role, and getting omap_vout patches merged has not been as fluent as it could be. Do you still want to continue in this role? Will you have time for it? Any ideas or suggestions how we should manage omap_vout in the future? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/4] mfd: tps65217: Set PMIC to shutdowm on PWR_EN toggle
On Wed, Nov 14, 2012 at 11:08:49AM +0100, Benoit Cousson wrote: I was wondering that, because exposing a pin to control the whole PMIC low power mode seems to be something that should be generic enough to be handled by the regulator framework. Having something that's controlled by software is really not at all generic - suspending a PMIC from a GPIO is generally tied in very closely with the CPU power sequencing which means it's typically some combination of very hard coded things that we can't control or part of much wider control of sequencing. In the current situation we do have a pwr_en pin that can be controlled by a GPIO or whatever signal from the SoC. That's very similar, at PMIC level, to the fixedregulator that allow a GPIO binding to enable it. Don't you think that should deserve a support in the fmwk? I'm not seeing a coherent description of a feature here - what exactly are you proposing that we do? When and how would this GPIO be set for example? signature.asc Description: Digital signature
Re: OMAP* Latest build failures
On Wed, Nov 14, 2012 at 11:08:35AM +0100, Peter Ujfalusi wrote: Hi Russell, On 11/14/2012 10:26 AM, Russell King - ARM Linux wrote: OMAP* allnoconfig fails: arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput': twl-common.c:(.text+0x1e08): undefined reference to `omap_pm_set_min_bus_tput' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_init_postsetup': twl-common.c:(.init.text+0x8f8): undefined reference to `omap_pm_if_early_init' arch/arm/mach-omap2/built-in.o: In function `omap_serial_init_port': twl-common.c:(.init.text+0x1284): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_timer_init': twl-common.c:(.init.text+0x1544): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_init': twl-common.c:(.init.text+0x1af0): undefined reference to `omap_pm_if_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': twl-common.c:(.init.text+0x2168): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_display_init': twl-common.c:(.init.text+0x25cc): undefined reference to `omap_pm_get_dev_context_loss_count' Not sure what is going on here but neither of these are referenced within twl-common.c directly. You can't rely on the .c file issued by the linker. omap_display_init() is not in twl-common.c, but is in arch/arm/mach-omap2/display.c. So ignore the twl-common.c. OMAP4 randconfig fails: arch/arm/mach-omap2/cm_common.c: In function 'cm_register': arch/arm/mach-omap2/cm_common.c:42:11: error: 'EINVAL' undeclared (first use in this function) arch/arm/mach-omap2/cm_common.c:45:11: error: 'EEXIST' undeclared (first use in this function) arch/arm/mach-omap2/cm_common.c: In function 'cm_unregister': arch/arm/mach-omap2/cm_common.c:66:11: error: 'EINVAL' undeclared (first use in this function) I have already sent a patch to fix this: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/131341.html You know where to find the build information and results... It seams I can not find the link in my mail archives. Could you point me to the correct place? http://www.arm.linux.org.uk/developer/build/ -- To unsubscribe from this list: send the line unsubscribe 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] Revert ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints
On Tue, Nov 06, 2012 at 04:31:32PM +, Paul Walmsley wrote: This reverts commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc. Here giving the patch name in parens would have really made sense. Will fix that. This commit causes I2C timeouts to appear on several OMAP3430/3530-based boards: http://marc.info/?l=linux-arm-kernelm=135071372426971w=2 http://marc.info/?l=linux-arm-kernelm=135067558415214w=2 http://marc.info/?l=linux-arm-kernelm=135216013608196w=2 and appears to have been sent for merging before one of its prerequisites was merged: http://marc.info/?l=linux-arm-kernelm=135219411617621w=2 Hmm, any ideas how to avoid such things in the future? Signed-off-by: Paul Walmsley p...@pwsan.com Applied to for-current, thanks! -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH] i2c: omap: Move the remove constraint
Currently we just queue the transfer and release the qos constraints, however we donot wait for the transfer to complete to release the constraint. Move the remove constraint after the bus busy as we are sure that the transfers are completed by then. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com Good catch, the change definitely makes sense. Feel free to add: Acked-by: Jean Pihet j-pi...@ti.com Since I just reverted the QoS patch, I suppose this gets merged into the original patch when resent? -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH] Revert ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints
Hi Wolfram, On Wed, Nov 14, 2012 at 11:51 AM, Wolfram Sang w.s...@pengutronix.de wrote: On Tue, Nov 06, 2012 at 04:31:32PM +, Paul Walmsley wrote: This reverts commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc. Here giving the patch name in parens would have really made sense. Will fix that. The title is ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints. This commit causes I2C timeouts to appear on several OMAP3430/3530-based boards: http://marc.info/?l=linux-arm-kernelm=135071372426971w=2 http://marc.info/?l=linux-arm-kernelm=135067558415214w=2 http://marc.info/?l=linux-arm-kernelm=135216013608196w=2 There is no formal piecof evidence that the commit is the cause of it. and appears to have been sent for merging before one of its prerequisites was merged: However this is correct. My fault ;-| http://marc.info/?l=linux-arm-kernelm=135219411617621w=2 Hmm, any ideas how to avoid such things in the future? The only way is to figure out the dependencies with other features. In this case I overlooked them and assumed some other features were already merged in. Will take care next time. Signed-off-by: Paul Walmsley p...@pwsan.com Applied to for-current, thanks! Thanks! Jean -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: omap: Move the remove constraint
Hi Wolfram, Shubhrajyoti, On Wed, Nov 14, 2012 at 11:57 AM, Wolfram Sang w.s...@pengutronix.de wrote: Currently we just queue the transfer and release the qos constraints, however we donot wait for the transfer to complete to release the constraint. Move the remove constraint after the bus busy as we are sure that the transfers are completed by then. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com Good catch, the change definitely makes sense. Feel free to add: Acked-by: Jean Pihet j-pi...@ti.com Since I just reverted the QoS patch, I suppose this gets merged into the original patch when resent? The best for now is to re-submit a new patch that moves the constraint release in the original code. Later the PM QoS patch will be applied on the new code base. What do you think? I can provide a patch if needed. Regards, Jean -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: omap: adopt pinctrl support
On Mon, Oct 22, 2012 at 10:42:01AM +0300, Felipe Balbi wrote: Hi, On Tue, Oct 16, 2012 at 05:23:20PM +0200, Sebastien Guiriec wrote: Some GPIO expanders need some early pin control muxing. Due to legacy boards sometimes the driver uses subsys_initcall instead of module_init. This patch takes advantage of defer probe feature and pin control in order to wait until pin control probing before GPIO driver probing. It has been tested on OMAP5 board with TCA6424 driver. log: [0.482299] omap_i2c i2c.15: could not find pctldev for node /ocp/pinmux@4a00 2840/pinmux_i2c5_pins, deferring probe [0.482330] platform i2c.15: Driver omap_i2c requests probe deferral [0.484466] Advanced Linux Sound Architecture Driver Initialized. [4.746917] omap_i2c i2c.15: bus 4 rev2.4.0 at 100 kHz [4.755279] gpiochip_find_base: found new base at 477 [4.761169] gpiochip_add: registered GPIOs 477 to 500 on device: tca6424a Signed-off-by: Sebastien Guiriec s-guir...@ti.com looks good to me also, should go in v3.8 merge window: Reviewed-by: Felipe Balbi ba...@ti.com Applied to for-next, thanks! -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH v2] i2c: omap: ensure writes to dev-buf_len are ordered
On Mon, Nov 05, 2012 at 10:04:43AM +0200, Felipe Balbi wrote: if we allow compiler reorder our writes, we could fall into a situation where dev-buf_len is reset for no apparent reason. This bug was found with a simple script which would transfer data to an i2c client from 1 to 1024 bytes (a simple for loop), when we got to transfer sizes bigger than the fifo size, dev-buf_len was reset to zero before we had an oportunity to handle XDR Interrupt. Because dev-buf_len was zero, we entered omap_i2c_transmit_data() to transfer zero bytes, which would mean we would just silently exit omap_i2c_transmit_data() without actually writing anything to DATA register. That would cause XDR IRQ to trigger forever and we would never transfer the remaining bytes. After adding the memory barrier, we also drop resetting dev-buf_len to zero in omap_i2c_xfer_msg() because both omap_i2c_transmit_data() and omap_i2c_receive_data() will act until dev-buf_len reaches zero, rendering the other write in omap_i2c_xfer_msg() redundant. This patch has been tested with pandaboard for a few iterations of the script mentioned above. Signed-off-by: Felipe Balbi ba...@ti.com --- Changes since v1: - use barrier() instead of wmb() Note: this version was compile-tested only drivers/i2c/busses/i2c-omap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index db31eae..ba03bec 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -521,6 +521,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap, /* REVISIT: Could the STB bit of I2C_CON be used with probing? */ dev-buf = msg-buf; dev-buf_len = msg-len; + barrier(); I agree adding a comment here is a good idea. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH] i2c: omap: Move the remove constraint
On Wednesday 14 November 2012 04:33 PM, Jean Pihet wrote: Acked-by: Jean Pihet j-pi...@ti.com Since I just reverted the QoS patch, I suppose this gets merged into the original patch when resent? The best for now is to re-submit a new patch that moves the constraint release in the original code. Later the PM QoS patch will be applied on the new code base. What do you think? I can provide a patch if needed. Will resubmit this. Regards, Jean -- To unsubscribe from this list: send the line unsubscribe 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* Latest build failures
On 2012-11-14 11:26, Russell King - ARM Linux wrote: OMAP* allnoconfig fails: arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput': twl-common.c:(.text+0x1e08): undefined reference to `omap_pm_set_min_bus_tput' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_init_postsetup': twl-common.c:(.init.text+0x8f8): undefined reference to `omap_pm_if_early_init' arch/arm/mach-omap2/built-in.o: In function `omap_serial_init_port': twl-common.c:(.init.text+0x1284): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_timer_init': twl-common.c:(.init.text+0x1544): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_init': twl-common.c:(.init.text+0x1af0): undefined reference to `omap_pm_if_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': twl-common.c:(.init.text+0x2168): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_display_init': twl-common.c:(.init.text+0x25cc): undefined reference to `omap_pm_get_dev_context_loss_count' I'm not able to reproduce this. I took v3.7-rc5, and the omap4430-sdp noconfig (http://www.arm.linux.org.uk/developer/build/file.php?type=configidx=2711), and it builds fine for me. From the error log (http://www.arm.linux.org.uk/developer/build/result.php?type=buildidx=2711) I see that arch/arm/plat-omap/omap-pm-noop.c is not compiled, which is where the above functions are. However, the config contains CONFIG_OMAP_PM_NOOP=y, which should cause omap-pm-noop.c to be compiled. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCHv3 0/7] i2c: omap: updates
On Mon, Nov 05, 2012 at 05:53:35PM +0530, Shubhrajyoti D wrote: Shubhrajyoti D (8): i2c: omap: Fix the revision register read i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207 i2c: omap: remove the dtrev ARM: i2c: omap: Remove the i207 errata flag i2c: omap: re-factor omap_i2c_init function i2c: omap: make reset a seperate function i2c: omap: Restore i2c context always i2c: omap: cleanup the sysc write Pushed the series to for-next, after fixing a trivial merge conflict caused by reverting the QoS patch. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCHv3 0/7] i2c: omap: updates
On Wednesday 14 November 2012 05:34 PM, Wolfram Sang wrote: On Mon, Nov 05, 2012 at 05:53:35PM +0530, Shubhrajyoti D wrote: Shubhrajyoti D (8): i2c: omap: Fix the revision register read i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207 i2c: omap: remove the dtrev ARM: i2c: omap: Remove the i207 errata flag i2c: omap: re-factor omap_i2c_init function i2c: omap: make reset a seperate function i2c: omap: Restore i2c context always i2c: omap: cleanup the sysc write Pushed the series to for-next, after fixing a trivial merge conflict caused by reverting the QoS patch. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] i2c: omap: ensure writes to dev-buf_len are ordered
if we allow compiler reorder our writes, we could
fall into a situation where dev-buf_len is reset
for no apparent reason.
This bug was found with a simple script which would
transfer data to an i2c client from 1 to 1024 bytes
(a simple for loop), when we got to transfer sizes
bigger than the fifo size, dev-buf_len was reset
to zero before we had an oportunity to handle XDR
Interrupt. Because dev-buf_len was zero, we entered
omap_i2c_transmit_data() to transfer zero bytes,
which would mean we would just silently exit
omap_i2c_transmit_data() without actually writing
anything to DATA register. That would cause XDR
IRQ to trigger forever and we would never transfer
the remaining bytes.
After adding the memory barrier, we also drop resetting
dev-buf_len to zero in omap_i2c_xfer_msg() because
both omap_i2c_transmit_data() and omap_i2c_receive_data()
will act until dev-buf_len reaches zero, rendering the
other write in omap_i2c_xfer_msg() redundant.
This patch has been tested with pandaboard for a few
iterations of the script mentioned above.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Changes since v2:
- add a comment
Changes since v1:
- use barrier() instead of wmb()
drivers/i2c/busses/i2c-omap.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index db31eae..e88fc26 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -522,6 +522,9 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
dev-buf = msg-buf;
dev-buf_len = msg-len;
+ /* make sure writes to dev-buf_len are ordered */
+ barrier();
+
omap_i2c_write_reg(dev, OMAP_I2C_CNT_REG, dev-buf_len);
/* Clear the FIFO Buffers */
@@ -579,7 +582,6 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
*/
timeout = wait_for_completion_timeout(dev-cmd_complete,
OMAP_I2C_TIMEOUT);
- dev-buf_len = 0;
if (timeout == 0) {
dev_err(dev-dev, controller timed out\n);
omap_i2c_init(dev);
--
1.8.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
AM335x: Beaglebone stops to boot with current git kernel
Hello,
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfig for tests.
It looks like the boot process stops due to the last changes in the AM33xx clock
sysbsystem. A following patch resolves this issue:
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index ad8d43b..858e180 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -586,7 +586,7 @@ static struct omap_hwmod am33xx_smartreflex0_hwmod = {
.class = am33xx_smartreflex_hwmod_class,
.clkdm_name = l4_wkup_clkdm,
.mpu_irqs = am33xx_smartreflex0_irqs,
- .main_clk = smartreflex0_fck,
+ .main_clk = smartreflex_mpu_fck,
.prcm = {
.omap4 = {
.clkctrl_offs =
AM33XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET,
@@ -606,7 +606,7 @@ static struct omap_hwmod am33xx_smartreflex1_hwmod = {
.class = am33xx_smartreflex_hwmod_class,
.clkdm_name = l4_wkup_clkdm,
.mpu_irqs = am33xx_smartreflex1_irqs,
- .main_clk = smartreflex1_fck,
+ .main_clk = smartreflex_core_fck,
.prcm = {
.omap4 = {
.clkctrl_offs =
AM33XX_CM_WKUP_SMARTREFLEX1_CLKCTRL_OFFSET,
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: hwmod data: ipu and dsp to use parent clocks instead of leaf clocks
Hi On Tue, 13 Nov 2012, Omar Ramirez Luna wrote: This prevents hwmod _enable_clocks...omap2_dflt_clk_enable path from enabling modulemode inside CLKCTRL using its clk-enable_reg field. Instead is left to _omap4_enable_module though soc_ops, as the one in charge of this setting. According to comments received[1] for related patches the idea is to get rid of leaf clocks in future. So remove these two while at it. [1] http://lkml.org/lkml/2012/8/20/226 Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org Does this one belong as part of the OMAP: iommu: hwmod, reset handling and runtime PM series? Looks like applying this one separately might cause these clocks not to be disabled by either the clock code's disable-unused-clocks code, or the hwmod code? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8] ARM: OMAP: Remove unnecessary inclusion of dmtimer.h
On 11/13/2012 12:13 PM, Jon Hunter wrote: Some source files are including dmtimer.h but not actually using any dmtimer definitions or functions. Therefore, remove the inclusion dmtimer.h from these source files. Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/mach-omap1/timer32k.c |1 - arch/arm/mach-omap2/omap_hwmod_2420_data.c |1 - arch/arm/mach-omap2/omap_hwmod_2430_data.c |1 - arch/arm/mach-omap2/pm-debug.c |1 - drivers/staging/tidspbridge/core/ue_deh.c |1 - 5 files changed, 5 deletions(-) diff --git a/arch/arm/mach-omap1/timer32k.c b/arch/arm/mach-omap1/timer32k.c index 8936819..41152fa 100644 --- a/arch/arm/mach-omap1/timer32k.c +++ b/arch/arm/mach-omap1/timer32k.c @@ -51,7 +51,6 @@ #include asm/mach/time.h #include plat/counter-32k.h -#include plat/dmtimer.h #include mach/hardware.h diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c index a8b3368..e8efe3d 100644 --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c @@ -17,7 +17,6 @@ #include linux/platform_data/spi-omap2-mcspi.h #include plat-omap/dma-omap.h -#include plat/dmtimer.h #include omap_hwmod.h #include l3_2xxx.h diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c index dc768c5..32d17e3 100644 --- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c @@ -18,7 +18,6 @@ #include linux/platform_data/spi-omap2-mcspi.h #include plat-omap/dma-omap.h -#include plat/dmtimer.h #include omap_hwmod.h #include mmc.h diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c index 3cf4fdf..e2c291f 100644 --- a/arch/arm/mach-omap2/pm-debug.c +++ b/arch/arm/mach-omap2/pm-debug.c @@ -30,7 +30,6 @@ #include clock.h #include powerdomain.h #include clockdomain.h -#include plat/dmtimer.h #include omap-pm.h #include soc.h diff --git a/drivers/staging/tidspbridge/core/ue_deh.c b/drivers/staging/tidspbridge/core/ue_deh.c index 3d28b23..6aea6f1 100644 --- a/drivers/staging/tidspbridge/core/ue_deh.c +++ b/drivers/staging/tidspbridge/core/ue_deh.c @@ -19,7 +19,6 @@ #include linux/kernel.h #include linux/interrupt.h -#include plat/dmtimer.h #include dspbridge/dbdefs.h #include dspbridge/dspdeh.h Hi Omar, I should have had you in copy on this one. Are you ok with the removal of the above dmtimer.h include? It does not appear that this file needs to include dmtimer.h. Is it ok for this to go through Tony's tree? If so, care to ACK? Cheers Jon -- To unsubscribe from this list: send the line unsubscribe 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: AM335x: Beaglebone stops to boot with current git kernel
Hi,
On Wed, Nov 14, 2012 at 4:28 PM, Igor Mazanov i.maza...@gmail.com wrote:
Hello,
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfig for tests.
It looks like the boot process stops due to the last changes in the AM33xx
clock sysbsystem. A following patch resolves this issue:
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index ad8d43b..858e180 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -586,7 +586,7 @@ static struct omap_hwmod am33xx_smartreflex0_hwmod = {
.class = am33xx_smartreflex_hwmod_class,
.clkdm_name = l4_wkup_clkdm,
.mpu_irqs = am33xx_smartreflex0_irqs,
- .main_clk = smartreflex0_fck,
+ .main_clk = smartreflex_mpu_fck,
.prcm = {
.omap4 = {
.clkctrl_offs =
AM33XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET,
@@ -606,7 +606,7 @@ static struct omap_hwmod am33xx_smartreflex1_hwmod = {
.class = am33xx_smartreflex_hwmod_class,
.clkdm_name = l4_wkup_clkdm,
.mpu_irqs = am33xx_smartreflex1_irqs,
- .main_clk = smartreflex1_fck,
+ .main_clk = smartreflex_core_fck,
.prcm = {
.omap4 = {
.clkctrl_offs =
AM33XX_CM_WKUP_SMARTREFLEX1_CLKCTRL_OFFSET,
About the name field in the hwmod entry: the SR code checks on the
value of smartreflex_mpu_iva to differentiate the SR IP blocks and
to apply the correct parameters to each of them. Cf. the function
sr_set_regfields in drivers/power/avs/smartreflex.c.
The patch should change the name of the hwmod entry as well, can you
fold this change in the current patch?
Note: I know the name smartreflex_mpu_iva is not perfect since it
does not apply to all OMAP3 variants, maybe we could change the SR
code to be more generic.
Nishant, what do you think?
Regards,
Jean
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe 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] i2c: omap: ensure writes to dev-buf_len are ordered
On Wed, Nov 14, 2012 at 04:22:45PM +0200, Felipe Balbi wrote: if we allow compiler reorder our writes, we could fall into a situation where dev-buf_len is reset for no apparent reason. This bug was found with a simple script which would transfer data to an i2c client from 1 to 1024 bytes (a simple for loop), when we got to transfer sizes bigger than the fifo size, dev-buf_len was reset to zero before we had an oportunity to handle XDR Interrupt. Because dev-buf_len was zero, we entered omap_i2c_transmit_data() to transfer zero bytes, which would mean we would just silently exit omap_i2c_transmit_data() without actually writing anything to DATA register. That would cause XDR IRQ to trigger forever and we would never transfer the remaining bytes. After adding the memory barrier, we also drop resetting dev-buf_len to zero in omap_i2c_xfer_msg() because both omap_i2c_transmit_data() and omap_i2c_receive_data() will act until dev-buf_len reaches zero, rendering the other write in omap_i2c_xfer_msg() redundant. This patch has been tested with pandaboard for a few iterations of the script mentioned above. Signed-off-by: Felipe Balbi ba...@ti.com Applied to for-current, thanks! -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH v3 7/7] crypto: omap_sham: Remove usage of private DMA API
On Tue, Nov 13, 2012 at 11:47:57PM -0800, Kasatkin, Dmitry wrote: On Fri, Nov 9, 2012 at 9:17 AM, Mark A. Greer mgr...@animalcreek.com wrote: On Fri, Nov 09, 2012 at 06:28:16PM +0200, Kasatkin, Dmitry wrote: On Wed, Nov 7, 2012 at 4:57 AM, Mark A. Greer mgr...@animalcreek.com wrote: From: Mark A. Greer mgr...@animalcreek.com Remove usage of the private OMAP DMA API. The dmaengine API will be used instead. CC: Russell King rmk+ker...@arm.linux.org.uk CC: Dmitry Kasatkin dmitry.kasat...@intel.com Signed-off-by: Mark A. Greer mgr...@animalcreek.com --- drivers/crypto/omap-sham.c | 117 - 1 file changed, 117 deletions(-) diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c index b57277c..ebb5255 100644 --- a/drivers/crypto/omap-sham.c +++ b/drivers/crypto/omap-sham.c @@ -807,18 +762,6 @@ static int omap_sham_handle_queue(struct omap_sham_dev *dd, if (err) goto err1; -#ifdef OMAP_SHAM_DMA_PRIVATE - omap_set_dma_dest_params(dd-dma_lch, 0, - OMAP_DMA_AMODE_CONSTANT, - dd-phys_base + SHA_REG_DIN(0), 0, 16); - - omap_set_dma_dest_burst_mode(dd-dma_lch, - OMAP_DMA_DATA_BURST_16); - - omap_set_dma_src_burst_mode(dd-dma_lch, - OMAP_DMA_DATA_BURST_4); Burst mode significantly improves performance. How do you configure burst mode with new API? This is (or should be) taken care of by the dmaengine infrastructure. I've noted that there's an issue and there is a discussion about it here: http://www.spinics.net/lists/linux-omap/msg79855.html We probably need to extend the dmaengine API to allow API-users to request specific tweaks/optimizations/whatever but that's MHO. Hello, I am in favor of new APIs. The only my concern is that it performs worse.. Is it possible to keep burst mode setting there? I'm going to respin the patch the I posted in the email thread above to only set bursting for non-cyclic DMAs. Mark -- -- To unsubscribe from this list: send the line unsubscribe 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* Latest build failures
* Tomi Valkeinen tomi.valkei...@ti.com [121114 03:47]: On 2012-11-14 11:26, Russell King - ARM Linux wrote: OMAP* allnoconfig fails: arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput': twl-common.c:(.text+0x1e08): undefined reference to `omap_pm_set_min_bus_tput' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_init_postsetup': twl-common.c:(.init.text+0x8f8): undefined reference to `omap_pm_if_early_init' arch/arm/mach-omap2/built-in.o: In function `omap_serial_init_port': twl-common.c:(.init.text+0x1284): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_timer_init': twl-common.c:(.init.text+0x1544): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_init': twl-common.c:(.init.text+0x1af0): undefined reference to `omap_pm_if_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': twl-common.c:(.init.text+0x2168): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_display_init': twl-common.c:(.init.text+0x25cc): undefined reference to `omap_pm_get_dev_context_loss_count' I'm not able to reproduce this. I took v3.7-rc5, and the omap4430-sdp noconfig (http://www.arm.linux.org.uk/developer/build/file.php?type=configidx=2711), and it builds fine for me. It happens if in arm-soc/for-next and rmk/for-next. Looks like the CONFIG_OMAP_PM_NOOP can't be under CONFIG_PM in the makefile where I moved it in commit 6e740f9a8. Looks like in my test configs I run make oldnoconfig on Russell's seed config, and I do get CONFIG_PM=y set while Russell's generated config does not have that. No ideas yet why oldnoconfig add CONFIG_PM=y.. Anyways, patch below to make it behave like earlier. Regards, Tony From: Tony Lindgren t...@atomide.com Date: Wed, 14 Nov 2012 08:40:00 -0800 Subject: [PATCH] ARM: OMAP: Fix compile for OMAP_PM_NOOP if PM is not selected Commit 6e740f9a8 (ARM: OMAP: Move omap-pm-noop.c local to mach-omap2) moved omap-pm-noop to be local to mach-omap2. However, the makefile entry got placed within ifeq ($(CONFIG_PM),y) which was not the case earlier. Fix the issue by moving it out of the ifeq ($(CONFIG_PM),y) in the makefile as these stubs are needed also when PM is not set. Reported-by: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Tony Lindgren t...@atomide.com --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -68,6 +68,8 @@ obj-$(CONFIG_ARCH_OMAP4) += opp4xxx_data.o endif # Power Management +obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o + ifeq ($(CONFIG_PM),y) obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o @@ -75,7 +77,6 @@ obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o obj-$(CONFIG_SOC_OMAP5)+= omap-mpuss-lowpower.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o -obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o obj-$(CONFIG_POWER_AVS_OMAP_CLASS3)+= smartreflex-class3.o -- To unsubscribe from this list: send the line unsubscribe 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: AM335x: Beaglebone stops to boot with current git kernel
On 11/14/2012 10:41 AM, Jean Pihet wrote:
Hi,
On Wed, Nov 14, 2012 at 4:28 PM, Igor Mazanov i.maza...@gmail.com wrote:
Hello,
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfig for tests.
It looks like the boot process stops due to the last changes in the AM33xx
clock sysbsystem. A following patch resolves this issue:
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index ad8d43b..858e180 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -586,7 +586,7 @@ static struct omap_hwmod am33xx_smartreflex0_hwmod = {
.class = am33xx_smartreflex_hwmod_class,
.clkdm_name = l4_wkup_clkdm,
.mpu_irqs = am33xx_smartreflex0_irqs,
- .main_clk = smartreflex0_fck,
+ .main_clk = smartreflex_mpu_fck,
.prcm = {
.omap4 = {
.clkctrl_offs =
AM33XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET,
@@ -606,7 +606,7 @@ static struct omap_hwmod am33xx_smartreflex1_hwmod = {
.class = am33xx_smartreflex_hwmod_class,
.clkdm_name = l4_wkup_clkdm,
.mpu_irqs = am33xx_smartreflex1_irqs,
- .main_clk = smartreflex1_fck,
+ .main_clk = smartreflex_core_fck,
.prcm = {
.omap4 = {
.clkctrl_offs =
AM33XX_CM_WKUP_SMARTREFLEX1_CLKCTRL_OFFSET,
About the name field in the hwmod entry: the SR code checks on the
value of smartreflex_mpu_iva to differentiate the SR IP blocks and
to apply the correct parameters to each of them. Cf. the function
sr_set_regfields in drivers/power/avs/smartreflex.c.
The patch should change the name of the hwmod entry as well, can you
fold this change in the current patch?
Note: I know the name smartreflex_mpu_iva is not perfect since it
does not apply to all OMAP3 variants, maybe we could change the SR
code to be more generic.
Nishant, what do you think?
Might be an better idea to remove the entire function sr_set_regfields
instead provide the err_weight, max_limit, accum_data, avgweights to
platform_data.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] I2C patches for v3.8 merge window
here's another series for OMAP I2C driver. There are a few cleanups and one very nice new feature: we can now report how many bytes we transferred until NACK. Note that the implemementation for OMAP-I2C turned out to be a little more complex then I expected, mainly because of the way I2C_CNT register behaves and because of the very buggy register usage on that driver. I have boot tested all patches on beagle xM (3630) and pandaboard rev A3 (4430), will send boot-logs if anyone wants to see. The series is a bit confusing mixing V1, V2 and V3 patches. Also, there are a few comments unaddressed it seems to me (reading in hot path, barriers). Please make sure these are properly handled and resend as a seperate series (all patches V4). Bonus point if you rebase it to my for-next, which I will push out soon. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: OMAP* Latest build failures
* Tony Lindgren t...@atomide.com [121114 08:50]: * Tomi Valkeinen tomi.valkei...@ti.com [121114 03:47]: On 2012-11-14 11:26, Russell King - ARM Linux wrote: OMAP* allnoconfig fails: arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput': twl-common.c:(.text+0x1e08): undefined reference to `omap_pm_set_min_bus_tput' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_init_postsetup': twl-common.c:(.init.text+0x8f8): undefined reference to `omap_pm_if_early_init' arch/arm/mach-omap2/built-in.o: In function `omap_serial_init_port': twl-common.c:(.init.text+0x1284): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_timer_init': twl-common.c:(.init.text+0x1544): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_init': twl-common.c:(.init.text+0x1af0): undefined reference to `omap_pm_if_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': twl-common.c:(.init.text+0x2168): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_display_init': twl-common.c:(.init.text+0x25cc): undefined reference to `omap_pm_get_dev_context_loss_count' I'm not able to reproduce this. I took v3.7-rc5, and the omap4430-sdp noconfig (http://www.arm.linux.org.uk/developer/build/file.php?type=configidx=2711), and it builds fine for me. It happens if in arm-soc/for-next and rmk/for-next. Looks like the CONFIG_OMAP_PM_NOOP can't be under CONFIG_PM in the makefile where I moved it in commit 6e740f9a8. This should say just It happens in arm-soc/for-next. Looks like in my test configs I run make oldnoconfig on Russell's seed config, and I do get CONFIG_PM=y set while Russell's generated config does not have that. No ideas yet why oldnoconfig add CONFIG_PM=y.. Anyways, patch below to make it behave like earlier. Regards, Tony From: Tony Lindgren t...@atomide.com Date: Wed, 14 Nov 2012 08:40:00 -0800 Subject: [PATCH] ARM: OMAP: Fix compile for OMAP_PM_NOOP if PM is not selected Commit 6e740f9a8 (ARM: OMAP: Move omap-pm-noop.c local to mach-omap2) moved omap-pm-noop to be local to mach-omap2. However, the makefile entry got placed within ifeq ($(CONFIG_PM),y) which was not the case earlier. Fix the issue by moving it out of the ifeq ($(CONFIG_PM),y) in the makefile as these stubs are needed also when PM is not set. Reported-by: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Tony Lindgren t...@atomide.com --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -68,6 +68,8 @@ obj-$(CONFIG_ARCH_OMAP4)+= opp4xxx_data.o endif # Power Management +obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o + ifeq ($(CONFIG_PM),y) obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o @@ -75,7 +77,6 @@ obj-$(CONFIG_ARCH_OMAP3)+= pm34xx.o sleep34xx.o obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o obj-$(CONFIG_SOC_OMAP5) += omap-mpuss-lowpower.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o -obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o obj-$(CONFIG_POWER_AVS_OMAP_CLASS3)+= smartreflex-class3.o -- To unsubscribe from this list: send the line unsubscribe 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 1/3] ASoC: OMAP: HDMI: Update machine driver name
Hi Liam, Thanks for reviewing! On 11/14/2012 04:16 AM, Liam Girdwood wrote: On 14/11/12 02:30, Ricardo Neri wrote: Being the name of a machine driver, it aims to describe the connection between the HDMI IP of the processor and the companion chip it uses to connect to the outside world. This name tries to follow the same naming convention as in the OMAP-ABE-TWL6040 machine driver. TPD12S015 is an HDMI companion chip for DC-DC step-up, I2C level shifter and low-capacitance ESD protection. This chip is used on all OMAP4 Pandaboards an SDPs as well as in OMAP5 EVMs. Is the TPD12S015 passive or actively controlled by the CPU in this case ? Yes the CPU controls the TPD12S015 actively through two GPIOs. One GPIO is used to enable data transfer. The second GPIO is enable the TPD to detect cable connection. However, this abstracted by the OMAPDSS HDMI driver and the ASoC driver does not know about it. If it's passive then it's not really worth changing the driver name since other OMAP4/5 devices may use other HDMI companion chips (an we can reuse this driver without changes). I believe it would be good to change the name of the driver to describe better the machine. omap-hdmi-audio makes reference only to the processor and sounds good to reserve it for the CPU DAI driver. Maybe something more generic could be used if the ASoC driver will not control the companion chip. How about omap-hdmi-board-audio or omap-hdmi-machine-audio? omap-hdmi-[companion]-audio was the best-looking to me. BR, Ricardo Liam -- To unsubscribe from this list: send the line unsubscribe 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/3] ASoC: OMAP: HDMI: Obtain DMA port from resources
Hi Mark, Thanks for reviewing! On 11/13/2012 09:27 PM, Mark Brown wrote: On Tue, Nov 13, 2012 at 08:30:49PM -0600, Ricardo Neri wrote: Instead of defining the address offset of the DMA port for transfers of audio samples, obtain this information from the resources of the device. This device and its resources are created by the OMAPDSS HDMI driver. Presumably this needs some other corresponding change in the resource setup to go in simultaneously... Yes, the change in the resources setup has been submitted to the OMAPDSS HDMI driver and accepted by Tomi [1]. - hdmi_data-dma_params.port_addr = hdmi_rsrc-start - + OMAP_HDMI_AUDIO_DMA_PORT; + hdmi_data-dma_params.port_addr = hdmi_rsrc-start; ...both before and after versions use the resource. This change should be present in K3.8. BR, Ricardo [1].http://www.mail-archive.com/linux-omap@vger.kernel.org/msg79801.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: OMAP* Latest build failures
* Tony Lindgren t...@atomide.com [121114 09:02]: * Tony Lindgren t...@atomide.com [121114 08:50]: * Tomi Valkeinen tomi.valkei...@ti.com [121114 03:47]: On 2012-11-14 11:26, Russell King - ARM Linux wrote: OMAP* allnoconfig fails: arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput': twl-common.c:(.text+0x1e08): undefined reference to `omap_pm_set_min_bus_tput' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_init_postsetup': twl-common.c:(.init.text+0x8f8): undefined reference to `omap_pm_if_early_init' arch/arm/mach-omap2/built-in.o: In function `omap_serial_init_port': twl-common.c:(.init.text+0x1284): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_timer_init': twl-common.c:(.init.text+0x1544): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_init': twl-common.c:(.init.text+0x1af0): undefined reference to `omap_pm_if_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': twl-common.c:(.init.text+0x2168): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_display_init': twl-common.c:(.init.text+0x25cc): undefined reference to `omap_pm_get_dev_context_loss_count' I'm not able to reproduce this. I took v3.7-rc5, and the omap4430-sdp noconfig (http://www.arm.linux.org.uk/developer/build/file.php?type=configidx=2711), and it builds fine for me. It happens if in arm-soc/for-next and rmk/for-next. Looks like the CONFIG_OMAP_PM_NOOP can't be under CONFIG_PM in the makefile where I moved it in commit 6e740f9a8. This should say just It happens in arm-soc/for-next. Looks like in my test configs I run make oldnoconfig on Russell's seed config, and I do get CONFIG_PM=y set while Russell's generated config does not have that. No ideas yet why oldnoconfig add CONFIG_PM=y.. Looks like the way to do this not to use oldnoconfig but to do: $ make KCONFIG_ALLCONFIG=../configs/rmk-omap4430-sdp-noconfig allnoconfig It seems that oldnoconfig will pick the new options that have default y? 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] i2c: omap: don't save a value only needed for read-clearing
Signed-off-by: Wolfram Sang wolf...@the-dreams.de
---
This makes one of my code analyzers happy and makes me a part of the
i2c-omap-patch crowd \o/
drivers/i2c/busses/i2c-omap.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 482c63d..49b12fb 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1291,14 +1291,13 @@ static int omap_i2c_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
- u16 iv;
_dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
if (_dev-rev OMAP_I2C_OMAP1_REV_2) {
- iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
+ omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
} else {
omap_i2c_write_reg(_dev, OMAP_I2C_STAT_REG, _dev-iestate);
--
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* Latest build failures
On Wed, Nov 14, 2012 at 01:45:15PM +0200, Tomi Valkeinen wrote: On 2012-11-14 11:26, Russell King - ARM Linux wrote: OMAP* allnoconfig fails: arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput': twl-common.c:(.text+0x1e08): undefined reference to `omap_pm_set_min_bus_tput' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_init_postsetup': twl-common.c:(.init.text+0x8f8): undefined reference to `omap_pm_if_early_init' arch/arm/mach-omap2/built-in.o: In function `omap_serial_init_port': twl-common.c:(.init.text+0x1284): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_timer_init': twl-common.c:(.init.text+0x1544): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_init': twl-common.c:(.init.text+0x1af0): undefined reference to `omap_pm_if_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': twl-common.c:(.init.text+0x2168): undefined reference to `omap_pm_get_dev_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_display_init': twl-common.c:(.init.text+0x25cc): undefined reference to `omap_pm_get_dev_context_loss_count' I'm not able to reproduce this. I took v3.7-rc5, and the omap4430-sdp noconfig (http://www.arm.linux.org.uk/developer/build/file.php?type=configidx=2711), and it builds fine for me. That's not the kernel it builds - it builds mainline + my kernel (which is basically for-next + a few bits more) + arm-soc. This error only just poped up, so I'm guessing there is a change in arm-soc which has broken it. I see that arch/arm/plat-omap/omap-pm-noop.c is not compiled, which is where the above functions are. However, the config contains CONFIG_OMAP_PM_NOOP=y, which should cause omap-pm-noop.c to be compiled. Suggest you retry with v3.7-rc5 + arm-soc. -- To unsubscribe from this list: send the line unsubscribe 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* Latest build failures
On Wed, Nov 14, 2012 at 09:17:31AM -0800, Tony Lindgren wrote: Looks like the way to do this not to use oldnoconfig but to do: $ make KCONFIG_ALLCONFIG=../configs/rmk-omap4430-sdp-noconfig allnoconfig It seems that oldnoconfig will pick the new options that have default y? That is the correct way to tell Kconfig to use the seed configuration - that forces the options in the ALLCONFIG file to the values in there in the final configuration while setting the rest of the options as desired by the all*config target. -- To unsubscribe from this list: send the line unsubscribe 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: AM335x: Beaglebone stops to boot with current git kernel
* Jean Pihet jean.pi...@newoldbits.com [121114 08:43]: The patch should change the name of the hwmod entry as well, can you fold this change in the current patch? This was caused by the merge of omap-for-v3.8/pm into omap-for-v3.8/clock. I noticed a smilar issue for omap3, but missed at least this one. Jean, can you please check omap-for-v3.8/clock for the smartreflex clock names in case there are more issues like this remaining? 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 3/3] ARM: dts: AM33XX: Add memory resource to d_can node
Add a new address space/memory resource to d_can device tree node. D_CAN
RAM initialization is achieved through RAMINIT register which is part of
AM33XX control module address space. D_CAN RAM init or de-init should be
done by writing instance corresponding value to control module register.
Till we have a separate control module driver to write to control module,
d_can driver will handle the register writes to control module by itself.
So a new address space to represent this control module register is added
to d_can driver.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index c92c35f..ea011d6 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -227,7 +227,8 @@
dcan0: d_can@481cc000 {
compatible = bosch,d_can;
ti,hwmods = d_can0;
- reg = 0x481cc000 0x2000;
+ reg = 0x481cc000 0x2000
+ 0x44e10644 0x4;
interrupts = 52;
status = disabled;
};
@@ -235,7 +236,8 @@
dcan1: d_can@481d {
compatible = bosch,d_can;
ti,hwmods = d_can1;
- reg = 0x481d 0x2000;
+ reg = 0x481d 0x2000
+ 0x44e10644 0x4;
interrupts = 55;
status = disabled;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] can: c_can: Add d_can raminit support
Add D_CAN raminit support to C_CAN driver to enable D_CAN RAM,
which holds all the message objects during transmission or
receiving of data. This initialization/de-initialization should
be done in synchronous with D_CAN clock.
In case of AM335X-EVM (active user of D_CAN driver) message RAM is
controlled through control module register for both instances. So
control module register details is required to initialization or
de-initialization of message RAM according to instance number.
Control module memory resource is obtained from D_CAN dt node and
instance number obtained from device tree aliases node.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
drivers/net/can/c_can/c_can.c | 12 +++
drivers/net/can/c_can/c_can.h |3 +++
drivers/net/can/c_can/c_can_platform.c | 34 +++-
3 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index e5180df..c15830c 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -233,6 +233,12 @@ static inline void c_can_pm_runtime_put_sync(const struct
c_can_priv *priv)
pm_runtime_put_sync(priv-device);
}
+static inline void c_can_reset_ram(const struct c_can_priv *priv, bool enable)
+{
+ if (priv-ram_init)
+ priv-ram_init(priv, enable);
+}
+
static inline int get_tx_next_msg_obj(const struct c_can_priv *priv)
{
return (priv-tx_next C_CAN_NEXT_MSG_OBJ_MASK) +
@@ -1090,6 +1096,7 @@ static int c_can_open(struct net_device *dev)
struct c_can_priv *priv = netdev_priv(dev);
c_can_pm_runtime_get_sync(priv);
+ c_can_reset_ram(priv, true);
/* open the can device */
err = open_candev(dev);
@@ -1118,6 +1125,7 @@ static int c_can_open(struct net_device *dev)
exit_irq_fail:
close_candev(dev);
exit_open_fail:
+ c_can_reset_ram(priv, false);
c_can_pm_runtime_put_sync(priv);
return err;
}
@@ -1131,6 +1139,8 @@ static int c_can_close(struct net_device *dev)
c_can_stop(dev);
free_irq(dev-irq, dev);
close_candev(dev);
+
+ c_can_reset_ram(priv, false);
c_can_pm_runtime_put_sync(priv);
return 0;
@@ -1188,6 +1198,7 @@ int c_can_power_down(struct net_device *dev)
c_can_stop(dev);
+ c_can_reset_ram(priv, false);
c_can_pm_runtime_put_sync(priv);
return 0;
@@ -1206,6 +1217,7 @@ int c_can_power_up(struct net_device *dev)
WARN_ON(priv-type != BOSCH_D_CAN);
c_can_pm_runtime_get_sync(priv);
+ c_can_reset_ram(priv, true);
/* Clear PDR and INIT bits */
val = priv-read_reg(priv, C_CAN_CTRL_EX_REG);
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index e5ed41d..419de5c 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -169,6 +169,9 @@ struct c_can_priv {
void *priv; /* for board-specific data */
u16 irqstatus;
enum c_can_dev_id type;
+ u32 __iomem *raminit_ctrlreg;
+ unsigned int instance;
+ void (*ram_init) (const struct c_can_priv *priv, bool enable);
};
struct net_device *alloc_c_can_dev(void);
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index ee141613..2e61d69 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -38,6 +38,8 @@
#include c_can.h
+#define CAN_RAMINIT_START_MASK(i) (1 (i))
+
/*
* 16-bit c_can registers can be arranged differently in the memory
* architecture of different implementations. For example: 16-bit
@@ -68,6 +70,24 @@ static void c_can_plat_write_reg_aligned_to_32bit(struct
c_can_priv *priv,
writew(val, priv-base + 2 * priv-regs[index]);
}
+static void c_can_hw_raminit(const struct c_can_priv *priv, bool enable)
+{
+ u32 val;
+
+ if (!priv-raminit_ctrlreg || (priv-instance 0))
+ return;
+
+ val = readl(priv-raminit_ctrlreg);
+ if (enable) {
+ val = ~CAN_RAMINIT_START_MASK(priv-instance);
+ val |= CAN_RAMINIT_START_MASK(priv-instance);
+ writel(val, priv-raminit_ctrlreg);
+ } else {
+ val = ~CAN_RAMINIT_START_MASK(priv-instance);
+ writel(val, priv-raminit_ctrlreg);
+ }
+}
+
static struct platform_device_id c_can_id_table[] = {
[BOSCH_C_CAN_PLATFORM] = {
.name = KBUILD_MODNAME,
@@ -99,7 +119,7 @@ static int __devinit c_can_plat_probe(struct platform_device
*pdev)
const struct of_device_id *match;
const struct platform_device_id *id;
struct pinctrl *pinctrl;
- struct resource *mem;
+ struct resource *mem, *res;
int irq;
struct clk *clk;
@@ -178,6 +198,18 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
[PATCH 0/3] can: Add D_CAN raminit support to am335x-evm
This patch series adds d_can raminit support to c_can/d_can driver, which is required to init/de-init D_CAN message RAM (holds message objects). Added corresponding DT changes to get resource of RAMINIT register and device instance. These patches were tested on AM335x-EVM along with pinctrl data addition patch, which is not added to am335x-evm.dts (only supports CPLD profile#0) because d_can1 is supported under CPLD profile#1. AnilKumar Ch (3): can: c_can: Add d_can raminit support ARM: dts: AM33XX: Add d_can instances to aliases ARM: dts: AM33XX: Add memory resource to d_can node arch/arm/boot/dts/am33xx.dtsi |8 ++-- drivers/net/can/c_can/c_can.c | 12 +++ drivers/net/can/c_can/c_can.h |3 +++ drivers/net/can/c_can/c_can_platform.c | 34 +++- 4 files changed, 54 insertions(+), 3 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
[PATCH 2/3] ARM: dts: AM33XX: Add d_can instances to aliases
Add d_can instances to aliases node to get the D_CAN instance number
from the driver. To initialize D_CAN message RAM, corresponding instance
number is required.
To initialize instance 0 message RAM then 0x1 should be written and for
instance 1 message RAM, 0x2 should be written to control module register.
With device-tree framework ip instance number is -1 by default for all
instances. To get device id/instance number then modules should be added
to DT aliases node. of_alias_get_id() gives the device id number based
on number of alias nodes present in aliases node.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 5dfd682..c92c35f 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -21,6 +21,8 @@
serial3 = uart4;
serial4 = uart5;
serial5 = uart6;
+ d_can0 = dcan0;
+ d_can1 = dcan1;
};
cpus {
--
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] i2c: omap: don't save a value only needed for read-clearing
Hi,
On Wed, Nov 14, 2012 at 06:21:06PM +0100, Wolfram Sang wrote:
Signed-off-by: Wolfram Sang wolf...@the-dreams.de
fine by me. I'd like to see a commit log (even if obvious) there. But no
strong feelings.
Acked-by: Felipe Balbi ba...@ti.com
---
This makes one of my code analyzers happy and makes me a part of the
anything open source which we could all be using ? :-)
i2c-omap-patch crowd \o/
drivers/i2c/busses/i2c-omap.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 482c63d..49b12fb 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1291,14 +1291,13 @@ static int omap_i2c_runtime_suspend(struct device
*dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
- u16 iv;
_dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
if (_dev-rev OMAP_I2C_OMAP1_REV_2) {
- iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
+ omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
} else {
omap_i2c_write_reg(_dev, OMAP_I2C_STAT_REG, _dev-iestate);
--
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
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] i2c: omap: don't save a value only needed for read-clearing
This makes one of my code analyzers happy and makes me a part of the anything open source which we could all be using ? :-) 'my' as in 'one of those I am using'. It was cppcheck which found that flaw. Its use for kernel code is limited, but it does find one or the other thing. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
[PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze to not boot when enabled. The ARM core on it is an earlier r1p2: CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d Unfortunately I don't have the details of errata 751472, but I'm guessing we need to disable it for r1p*. Signed-off-by: Tony Lindgren t...@atomide.com --- Can somebody with access to the errata check if it has more info on which revisions this should be set on? Maybe it's just r2p* - r3p0? --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -236,6 +236,8 @@ __v7_setup: mcreq p15, 0, r10, c15, c0, 1 @ write diagnostic register #endif #if defined(CONFIG_ARM_ERRATA_751472) defined(CONFIG_SMP) + teq r5, #0x0010 @ fails at least on r1p2 + beq 1f ALT_SMP(cmp r6, #0x30) @ present prior to r3p0 ALT_UP_B(1f) mrclt p15, 0, r10, c15, c0, 1 @ read diagnostic register -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
On Wed, Nov 14, 2012 at 10:53:35AM -0800, Tony Lindgren wrote: Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze to not boot when enabled. The ARM core on it is an earlier r1p2: CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d Unfortunately I don't have the details of errata 751472, but I'm guessing we need to disable it for r1p*. Fails because it can't write the diagnostic register from non-secure mode or fails later? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
On 11/14/2012 12:53 PM, Tony Lindgren wrote: Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze to not boot when enabled. The ARM core on it is an earlier r1p2: CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d Unfortunately I don't have the details of errata 751472, but I'm guessing we need to disable it for r1p*. I checked the CA9MP errata document and this erratum impacts all r0/r1/r2 CPUs. I am wondering if the problem is because the workaround requires you to set a bit in the Diagnostic Control register and the read-modify-write sequence provided in the workaround is for secure mode. Not sure if there is a non-secure workaround available :-( Cheers Jon -- To unsubscribe from this list: send the line unsubscribe 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 V5 0/7] ARM: AM33XX: net: Add DT support to CPSW and MDIO driver
This patch-series adds support for, [1/7]: Typo mistake in CPSW driver while invoking runtime_pm api's [2/7]: Adds parent-child relation between CPSW MDIO module inside cpsw driver, as in case of AM33XX, the resources are shared and common register bit-field is provided to control module/clock enable/disable, makes it difficult to handle common resource. So the solution here is, to create parent-child relation between them. [3/7]: cpsw: simplify the setup of the register pointers [4/7]: cpsw: Kernel warn fix during suspend [5/7]: Add hwmod entry for MDIO module, required for MDIO driver. [6/7]: Enable CPSW support to omap2plus_defconfig [7/7]: Add DT device nodes for both CPSW and MDIO modules in am33xx.dtsi, am335x-evm.dts and am335x-bone.dts file This patch series has been created on top of net-next/master and tested on BeagleBone platform for NFS boot and basic ping test cases. Changes from V3: * Removed unnecessary flags in Davinci MDIO Hwmod entry. Changes from V4: * Changed CPSW phy ID in DT to make it generic. * Applied cosmetic changed in AM33XX dts file from Benoit Cousson Mugunthan V N (4): net: cpsw: halt network stack before halting the device during suspend ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module ARM: OMAP2+: omap2plus_defconfig: Enable CPSW support arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX Richard Cochran (1): cpsw: simplify the setup of the register pointers Vaibhav Hiremath (2): net: davinci_mdio: Fix typo mistake in calling runtime-pm api net: cpsw: Add parent-child relation support between cpsw and mdio Documentation/devicetree/bindings/net/cpsw.txt | 42 + arch/arm/boot/dts/am335x-bone.dts |8 + arch/arm/boot/dts/am335x-evm.dts |8 + arch/arm/boot/dts/am33xx.dtsi | 48 + arch/arm/configs/omap2plus_defconfig |3 + arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 31 +++ drivers/net/ethernet/ti/cpsw.c | 248 +++- drivers/net/ethernet/ti/davinci_mdio.c |2 +- include/linux/platform_data/cpsw.h | 21 +-- 9 files changed, 216 insertions(+), 195 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 V5 6/7] ARM: OMAP2+: omap2plus_defconfig: Enable CPSW support
Enable CPSW support in defconfig which is present in AM33xx SoC Signed-off-by: Mugunthan V N mugunthan...@ti.com Acked-by: Richard Cochran richardcoch...@gmail.com --- arch/arm/configs/omap2plus_defconfig |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index a4b330e..41b595e 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -242,3 +242,6 @@ CONFIG_CRC_ITU_T=y CONFIG_CRC7=y CONFIG_LIBCRC32C=y CONFIG_SOC_OMAP5=y +CONFIG_TI_DAVINCI_MDIO=y +CONFIG_TI_DAVINCI_CPDMA=y +CONFIG_TI_CPSW=y -- 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 V5 4/7] net: cpsw: halt network stack before halting the device during suspend
Move network stack halt APIs before halting the hardware to ensure no packets are queued to hardware during closing the device during suspend sequence. Signed-off-by: Mugunthan V N mugunthan...@ti.com Acked-by: Richard Cochran richardcoch...@gmail.com --- drivers/net/ethernet/ti/cpsw.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c index 0da9c75..02c2477 100644 --- a/drivers/net/ethernet/ti/cpsw.c +++ b/drivers/net/ethernet/ti/cpsw.c @@ -698,12 +698,12 @@ static int cpsw_ndo_stop(struct net_device *ndev) struct cpsw_priv *priv = netdev_priv(ndev); cpsw_info(priv, ifdown, shutting down cpsw device\n); - cpsw_intr_disable(priv); - cpdma_ctlr_int_ctrl(priv-dma, false); - cpdma_ctlr_stop(priv-dma); netif_stop_queue(priv-ndev); napi_disable(priv-napi); netif_carrier_off(priv-ndev); + cpsw_intr_disable(priv); + cpdma_ctlr_int_ctrl(priv-dma, false); + cpdma_ctlr_stop(priv-dma); cpsw_ale_stop(priv-ale); for_each_slave(priv, cpsw_slave_stop, priv); pm_runtime_put_sync(priv-pdev-dev); -- 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 V5 3/7] cpsw: simplify the setup of the register pointers
From: Richard Cochran richardcoch...@gmail.com
Instead of having a host of different register offsets in the device tree,
this patch simplifies the CPSW code by letting the driver set the proper
register offsets automatically, based on the CPSW version.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
Documentation/devicetree/bindings/net/cpsw.txt | 42 +
drivers/net/ethernet/ti/cpsw.c | 242 ++--
include/linux/platform_data/cpsw.h | 21 +--
3 files changed, 108 insertions(+), 197 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt
b/Documentation/devicetree/bindings/net/cpsw.txt
index 2214607..6ddd028 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -9,15 +9,7 @@ Required properties:
number
- interrupt-parent : The parent interrupt controller
- cpdma_channels : Specifies number of channels in CPDMA
-- host_port_no : Specifies host port shift
-- cpdma_reg_ofs: Specifies CPDMA submodule register offset
-- cpdma_sram_ofs : Specifies CPDMA SRAM offset
-- ale_reg_ofs : Specifies ALE submodule register offset
- ale_entries : Specifies No of entries ALE can hold
-- host_port_reg_ofs: Specifies host port register offset
-- hw_stats_reg_ofs : Specifies hardware statistics register offset
-- cpts_reg_ofs : Specifies the offset of the CPTS registers
-- bd_ram_ofs : Specifies internal desciptor RAM offset
- bd_ram_size : Specifies internal descriptor RAM size
- rx_descs : Specifies number of Rx descriptors
- mac_control : Specifies Default MAC control register content
@@ -26,8 +18,6 @@ Required properties:
- cpts_active_slave: Specifies the slave to use for time stamping
- cpts_clock_mult : Numerator to convert input clock ticks into
nanoseconds
- cpts_clock_shift : Denominator to convert input clock ticks into
nanoseconds
-- slave_reg_ofs: Specifies slave register offset
-- sliver_reg_ofs : Specifies slave sliver register offset
- phy_id : Specifies slave phy id
- mac-address : Specifies slave MAC address
@@ -49,15 +39,7 @@ Examples:
interrupts = 55 0x4;
interrupt-parent = intc;
cpdma_channels = 8;
- host_port_no = 0;
- cpdma_reg_ofs = 0x800;
- cpdma_sram_ofs = 0xa00;
- ale_reg_ofs = 0xd00;
ale_entries = 1024;
- host_port_reg_ofs = 0x108;
- hw_stats_reg_ofs = 0x900;
- cpts_reg_ofs = 0xc00;
- bd_ram_ofs = 0x2000;
bd_ram_size = 0x2000;
no_bd_ram = 0;
rx_descs = 64;
@@ -67,16 +49,12 @@ Examples:
cpts_clock_mult = 0x8000;
cpts_clock_shift = 29;
cpsw_emac0: slave@0 {
- slave_reg_ofs = 0x200;
- sliver_reg_ofs = 0xd80;
- phy_id = davinci_mdio.16:00;
+ phy_id = davinci_mdio, 0;
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave@1 {
- slave_reg_ofs = 0x300;
- sliver_reg_ofs = 0xdc0;
- phy_id = davinci_mdio.16:01;
+ phy_id = davinci_mdio, 1;
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
@@ -87,15 +65,7 @@ Examples:
compatible = ti,cpsw;
ti,hwmods = cpgmac0;
cpdma_channels = 8;
- host_port_no = 0;
- cpdma_reg_ofs = 0x800;
- cpdma_sram_ofs = 0xa00;
- ale_reg_ofs = 0xd00;
ale_entries = 1024;
- host_port_reg_ofs = 0x108;
- hw_stats_reg_ofs = 0x900;
- cpts_reg_ofs = 0xc00;
- bd_ram_ofs = 0x2000;
bd_ram_size = 0x2000;
no_bd_ram = 0;
rx_descs = 64;
@@ -105,16 +75,12 @@ Examples:
cpts_clock_mult = 0x8000;
cpts_clock_shift = 29;
cpsw_emac0: slave@0 {
- slave_reg_ofs = 0x200;
- sliver_reg_ofs = 0xd80;
- phy_id = davinci_mdio.16:00;
+ phy_id = davinci_mdio, 0;
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave@1 {
- slave_reg_ofs = 0x300;
- sliver_reg_ofs = 0xdc0;
-
[PATCH V5 2/7] net: cpsw: Add parent-child relation support between cpsw and mdio
From: Vaibhav Hiremath hvaib...@ti.com
CPGMAC SubSystem consist of various sub-modules, like, mdio, cpdma,
cpsw, etc... These sub-modules are also used in some of Davinci family
of devices. Now based on requirement, use-case and available technology
nodes the integration of these sub-modules varies across devices.
So coming back to Linux net driver, currently separate and independent
platform devices drivers for CPSW and MDIO is implemented. In case of
Davinci they both has separate control, from resources perspective,
like clock.
In case of AM33XX, the resources are shared and only one register
bit-field is provided to control module/clock enable/disable, makes it
difficult to handle common resource.
So the solution here implemented in this patch is,
Create parent-child relationship between both the drivers, making
CPSW as a parent and MDIO as its child and enumerate all the child nodes
under CPSW module.
Both the drivers will function exactly the way it was operating before,
including runtime-pm functionality. No change is required in MDIO driver
(for that matter to any child driver).
As this is only supported during DT boot, the parent-child relationship
is created and populated in DT execution flow. The only required change
is inside DTS file, making MDIO as a child to CPSW node.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Acked-by: Peter Korsgaard jac...@sunsite.dk
Acked-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/ti/cpsw.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 7654a62..7007aba 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1144,7 +1144,7 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
}
data-mac_control = prop;
- for_each_child_of_node(node, slave_node) {
+ for_each_node_by_name(slave_node, slave) {
struct cpsw_slave_data *slave_data = data-slave_data + i;
const char *phy_id = NULL;
const void *mac_addr = NULL;
@@ -1179,6 +1179,14 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
i++;
}
+ /*
+* Populate all the child nodes here...
+*/
+ ret = of_platform_populate(node, NULL, NULL, pdev-dev);
+ /* We do not want to force this, as in some cases may not have child */
+ if (ret)
+ pr_warn(Doesn't have any child node\n);
+
return 0;
error_ret:
@@ -1212,6 +1220,11 @@ static int __devinit cpsw_probe(struct platform_device
*pdev)
priv-msg_enable = netif_msg_init(debug_level, CPSW_DEBUG);
priv-rx_packet_max = max(rx_packet_max, 128);
+ /*
+* This may be required here for child devices.
+*/
+ pm_runtime_enable(pdev-dev);
+
if (cpsw_probe_dt(priv-data, pdev)) {
pr_err(cpsw: platform data missing\n);
ret = -ENODEV;
@@ -1238,7 +1251,6 @@ static int __devinit cpsw_probe(struct platform_device
*pdev)
for (i = 0; i data-slaves; i++)
priv-slaves[i].slave_num = i;
- pm_runtime_enable(pdev-dev);
priv-clk = clk_get(pdev-dev, fck);
if (IS_ERR(priv-clk)) {
dev_err(pdev-dev, fck is not found\n);
--
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 V5 1/7] net: davinci_mdio: Fix typo mistake in calling runtime-pm api
From: Vaibhav Hiremath hvaib...@ti.com By mistake (most likely a copy-paste), instead of pm_runtime_get_sync() api, driver is calling pm_runtime_put_sync() api in resume callback function. The bug was introduced by commit id (ae2c07aaf74: davinci_mdio: runtime PM support). Now, the reason why it didn't impact functionality is, the patch has been tested on AM335x-EVM and BeagleBone platform while submitting; and in case of AM335x the MDIO driver doesn't control the module enable/disable part, which is handled by CPSW driver. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Mugunthan V N mugunthan...@ti.com Acked-by: Peter Korsgaard jac...@sunsite.dk Acked-by: Richard Cochran richardcoch...@gmail.com --- drivers/net/ethernet/ti/davinci_mdio.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c index 51a96db..ae74280 100644 --- a/drivers/net/ethernet/ti/davinci_mdio.c +++ b/drivers/net/ethernet/ti/davinci_mdio.c @@ -465,7 +465,7 @@ static int davinci_mdio_resume(struct device *dev) u32 ctrl; spin_lock(data-lock); - pm_runtime_put_sync(data-dev); + pm_runtime_get_sync(data-dev); /* restart the scan state machine */ ctrl = __raw_readl(data-regs-control); -- 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] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
* Russell King - ARM Linux li...@arm.linux.org.uk [121114 11:03]: On Wed, Nov 14, 2012 at 10:53:35AM -0800, Tony Lindgren wrote: Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze to not boot when enabled. The ARM core on it is an earlier r1p2: CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d Unfortunately I don't have the details of errata 751472, but I'm guessing we need to disable it for r1p*. Fails because it can't write the diagnostic register from non-secure mode or fails later? Hmm good question, it fails a bit later on during the boot just before __enable_mmu. But I just tried commenting out the setting of bit 11: @orrlt r10, r10, #1 11 @ set bit #11 And just trying to write the unmodified diagnostic register also makes it fail. So yeah it seems to be related to the secure crap instead :( Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
* Jon Hunter jon-hun...@ti.com [121114 11:09]: On 11/14/2012 12:53 PM, Tony Lindgren wrote: Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze to not boot when enabled. The ARM core on it is an earlier r1p2: CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d Unfortunately I don't have the details of errata 751472, but I'm guessing we need to disable it for r1p*. I checked the CA9MP errata document and this erratum impacts all r0/r1/r2 CPUs. I am wondering if the problem is because the workaround requires you to set a bit in the Diagnostic Control register and the read-modify-write sequence provided in the workaround is for secure mode. Not sure if there is a non-secure workaround available :-( So it seems :( And I guess we still don't have a generic way to check if the core has secure mode or not, and what registers are accessible in secure mode. 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
[RFC PATCH v7] ARM hibernation / suspend-to-disk
This is a rebase/rework of Frank Hofmann's work, the most recent patchset
being here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-June/053229.html
The biggest gotcha right now:
If there's any cpu-specific / SoC-specific state that needs (re)init
over a suspend-to-disk/resume-from-disk cycle, this patch is incomplete
because it provides no hooks/code for that.
This is the case e.g. for secure SoCs that have different sets of
control registers and/or different CR reg access patterns.
It's also the case e.g. for SoCs with L2 caches as the activation
sequence there is SoC-dependent; a full off-on cycle for L2 is not done
by the hibernation support code.
It's also the case if the SoC requires steps on wakeup _before_ the
generic parts done by cpu_suspend / cpu_resume can work correctly.
(OMAP is an example of such a SoC; the patch works on OMAP in the
sense that it gets you a non-secure OMAP back from hibernation but as
mentioned, your mileage may vary; I for example don't know what the
consequences of not disabling / reenabling the L2 cache over cpu_reset
are)
I've only tested on Beagleboard xM, and it gets stuck trying to program
some GPIOs since the interface clock isn't enabled. However, things
generally look good.
The work is built on Linux-3.7.0-rc5-00014-g9924a19.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/include/asm/memory.h | 1 +
arch/arm/kernel/Makefile | 1 +
arch/arm/kernel/hibernate.c | 117 ++
arch/arm/mm/Kconfig | 5 ++
4 files changed, 124 insertions(+)
create mode 100644 arch/arm/kernel/hibernate.c
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 73cf03a..8376a39 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -230,6 +230,7 @@ static inline void *phys_to_virt(phys_addr_t x)
*/
#define __pa(x)__virt_to_phys((unsigned long)(x))
#define __va(x)((void *)__phys_to_virt((unsigned
long)(x)))
+#define __pa_symbol(x) __pa(RELOC_HIDE((unsigned long)(x),0))
#define pfn_to_kaddr(pfn) __va((pfn) PAGE_SHIFT)
/*
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 5bbec7b..2971988 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_ARTHUR) += arthur.o
obj-$(CONFIG_ISA_DMA) += dma-isa.o
obj-$(CONFIG_PCI) += bios32.o isa.o
obj-$(CONFIG_ARM_CPU_SUSPEND) += sleep.o suspend.o
+obj-$(CONFIG_HIBERNATION) += hibernate.o
obj-$(CONFIG_SMP) += smp.o smp_tlb.o
obj-$(CONFIG_HAVE_ARM_SCU) += smp_scu.o
obj-$(CONFIG_HAVE_ARM_TWD) += smp_twd.o
diff --git a/arch/arm/kernel/hibernate.c b/arch/arm/kernel/hibernate.c
new file mode 100644
index 000..0b72e17
--- /dev/null
+++ b/arch/arm/kernel/hibernate.c
@@ -0,0 +1,117 @@
+/*
+ * Hibernation support specific for ARM
+ *
+ * Derived from work on ARM hibernation support by:
+ *
+ * Ubuntu project, hibernation support for mach-dove
+ * Copyright (C) 2010 Nokia Corporation (Hiroshi Doyu)
+ * Copyright (C) 2010 Texas Instruments, Inc. (Teerth Reddy et al.)
+ * https://lkml.org/lkml/2010/6/18/4
+ *
https://lists.linux-foundation.org/pipermail/linux-pm/2010-June/027422.html
+ * https://patchwork.kernel.org/patch/96442/
+ *
+ * Copyright (C) 2006 Rafael J. Wysocki r...@sisk.pl
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include linux/mm.h
+#include linux/suspend.h
+#include asm/tlbflush.h
+#include asm/cacheflush.h
+#include asm/system_misc.h
+#include asm/idmap.h
+#include asm/suspend.h
+
+extern const void __nosave_begin, __nosave_end;
+extern void cpu_resume(void);
+
+int pfn_is_nosave(unsigned long pfn)
+{
+ unsigned long nosave_begin_pfn =
+ __pa_symbol(__nosave_begin) PAGE_SHIFT;
+ unsigned long nosave_end_pfn =
+ PAGE_ALIGN(__pa_symbol(__nosave_end)) PAGE_SHIFT;
+
+ return (pfn = nosave_begin_pfn) (pfn nosave_end_pfn);
+}
+
+void notrace save_processor_state(void)
+{
+ WARN_ON(num_online_cpus() != 1);
+ flush_thread();
+ local_fiq_disable();
+}
+
+void notrace restore_processor_state(void)
+{
+ local_fiq_enable();
+}
+
+/*
+ * Snapshot kernel memory and reset the system.
+ * After resume, the hibernation snapshot is written out.
+ */
+static int notrace __swsusp_arch_save_image(unsigned long unused)
+{
+ extern int swsusp_save(void);
+ int ret;
+
+ ret = swsusp_save();
+ if (ret == 0)
+ soft_restart(virt_to_phys(cpu_resume));
+ return ret;
+}
+
+/*
+ * Save the current CPU state before suspend / poweroff.
+ */
+int notrace swsusp_arch_suspend(void)
+{
+ return cpu_suspend(0, __swsusp_arch_save_image);
+}
+
+/*
+ * The framework loads the hibernation image into a linked list anchored
+ *
Re: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
On Wed, Nov 14, 2012 at 01:06:53PM -0600, Jon Hunter wrote: On 11/14/2012 12:53 PM, Tony Lindgren wrote: Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze to not boot when enabled. The ARM core on it is an earlier r1p2: CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d Unfortunately I don't have the details of errata 751472, but I'm guessing we need to disable it for r1p*. I checked the CA9MP errata document and this erratum impacts all r0/r1/r2 CPUs. I am wondering if the problem is because the workaround requires you to set a bit in the Diagnostic Control register and the read-modify-write sequence provided in the workaround is for secure mode. Not sure if there is a non-secure workaround available :-( Most likely, and there's not a lot that the kernel can sanely do about that. We have ended up deciding (through being forced to because of how the security stuff works) that the stages prior to the kernel will implement the work-around enables because those stages are already platform specific, and the kernel will implement a test for the work-around already enabled. The net result is, if you enable an Errata in the kernel which your earlier boot stages has not already configured, the kernel will hang. Not much we can do about the hanging aspect, because the kernel takes an exception which we can't trap at those early stages in the boot process. I'm not particularly happy about that design, but that's what we've ended up with through the 'design' of the security stuff forced onto us. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
* Russell King - ARM Linux li...@arm.linux.org.uk [121114 12:24]: On Wed, Nov 14, 2012 at 01:06:53PM -0600, Jon Hunter wrote: On 11/14/2012 12:53 PM, Tony Lindgren wrote: Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze to not boot when enabled. The ARM core on it is an earlier r1p2: CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d Unfortunately I don't have the details of errata 751472, but I'm guessing we need to disable it for r1p*. I checked the CA9MP errata document and this erratum impacts all r0/r1/r2 CPUs. I am wondering if the problem is because the workaround requires you to set a bit in the Diagnostic Control register and the read-modify-write sequence provided in the workaround is for secure mode. Not sure if there is a non-secure workaround available :-( Most likely, and there's not a lot that the kernel can sanely do about that. We have ended up deciding (through being forced to because of how the security stuff works) that the stages prior to the kernel will implement the work-around enables because those stages are already platform specific, and the kernel will implement a test for the work-around already enabled. The net result is, if you enable an Errata in the kernel which your earlier boot stages has not already configured, the kernel will hang. Not much we can do about the hanging aspect, because the kernel takes an exception which we can't trap at those early stages in the boot process. I'm not particularly happy about that design, but that's what we've ended up with through the 'design' of the security stuff forced onto us. Checking for the bit already set should work in this case, I'll post a patch for that shortly. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
On 11/14/2012 02:32 PM, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [121114 12:24]: On Wed, Nov 14, 2012 at 01:06:53PM -0600, Jon Hunter wrote: On 11/14/2012 12:53 PM, Tony Lindgren wrote: Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze to not boot when enabled. The ARM core on it is an earlier r1p2: CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d Unfortunately I don't have the details of errata 751472, but I'm guessing we need to disable it for r1p*. I checked the CA9MP errata document and this erratum impacts all r0/r1/r2 CPUs. I am wondering if the problem is because the workaround requires you to set a bit in the Diagnostic Control register and the read-modify-write sequence provided in the workaround is for secure mode. Not sure if there is a non-secure workaround available :-( Most likely, and there's not a lot that the kernel can sanely do about that. We have ended up deciding (through being forced to because of how the security stuff works) that the stages prior to the kernel will implement the work-around enables because those stages are already platform specific, and the kernel will implement a test for the work-around already enabled. The net result is, if you enable an Errata in the kernel which your earlier boot stages has not already configured, the kernel will hang. Not much we can do about the hanging aspect, because the kernel takes an exception which we can't trap at those early stages in the boot process. I'm not particularly happy about that design, but that's what we've ended up with through the 'design' of the security stuff forced onto us. Checking for the bit already set should work in this case, I'll post a patch for that shortly. Can you actually read the state of the diagnostic register in non-secure mode? If you can on the A9, is the same true on A8 or others? Multi-platform kernels present a new problem in that we basically need to enable all errata work-arounds. I've been meaning to look thru the errata work-arounds to figure out which ones can be selected for multi-platform kernels without side effects on unaffected parts (i.e. set a chicken bit based on core revision). For any in runtime paths, we may need to do runtime patching if they have performance impact. Rob -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
* Rob Herring robherri...@gmail.com [121114 13:59]: On 11/14/2012 02:32 PM, Tony Lindgren wrote: Checking for the bit already set should work in this case, I'll post a patch for that shortly. Can you actually read the state of the diagnostic register in non-secure mode? If you can on the A9, is the same true on A8 or others? Looks like it can be read on at least TI omap 4430 which is A9. But it reads as zero, so the below patch is what I came up with. No idea if assuming that zero value for the diagnostic register is safe.. What's the default value of the diagnostic register supposed to be? Multi-platform kernels present a new problem in that we basically need to enable all errata work-arounds. I've been meaning to look thru the errata work-arounds to figure out which ones can be selected for multi-platform kernels without side effects on unaffected parts (i.e. set a chicken bit based on core revision). For any in runtime paths, we may need to do runtime patching if they have performance impact. Yeah that's how I ran into it as multiplatform enabled omap booted on other omaps but not on omap4. Regards, Tony From: Tony Lindgren t...@atomide.com Date: Tue, 13 Nov 2012 16:57:42 -0800 Subject: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 for secure mode Looks like enabling CONFIG_ARM_ERRATA_751472 causes TI omap4 blaze to not boot when enabled. The ARM core on it is an earlier r1p2. This seems to be caused by the write to the diagnostic register that shortly after causes an exception as writing to the diagnostic register on systems with secure mode is not allowed. Also it seems that reading the diagnostic register results zero so we may not be able to check if bit #11 is already set. Let's assume that if the diagnostic register is zero, we don't want to touch it as it seems to hint secure mode at least on TI omaps. If it's non-zero, check if bit #11 is set and only attempt to set it if not set. --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -238,9 +238,13 @@ __v7_setup: #if defined(CONFIG_ARM_ERRATA_751472) defined(CONFIG_SMP) ALT_SMP(cmp r6, #0x30) @ present prior to r3p0 ALT_UP_B(1f) - mrclt p15, 0, r10, c15, c0, 1 @ read diagnostic register - orrlt r10, r10, #1 11 @ set bit #11 - mcrlt p15, 0, r10, c15, c0, 1 @ write diagnostic register + bge 1f @ not needed for r3p0 and later + mrc p15, 0, r10, c15, c0, 1 @ read diagnostic register + teq r10, #0 @ zero for secure mode? + beq 1f @ bail out for secure mode + tst r10, #1 11 @ bit #11 already set? + orreq r10, r10, #1 11 @ set bit #11 if not set + mcreq p15, 0, r10, c15, c0, 1 @ write diagnostic register 1: #endif -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ASoC: OMAP: HDMI: Obtain DMA port from resources
On Wed, Nov 14, 2012 at 11:07:09AM -0600, Ricardo Neri wrote: On 11/13/2012 09:27 PM, Mark Brown wrote: Presumably this needs some other corresponding change in the resource setup to go in simultaneously... Yes, the change in the resources setup has been submitted to the OMAPDSS HDMI driver and accepted by Tomi [1]. Don't do this. With a change like this which must be made at the same time over multiple subsystems it is very important that you send all the parts of the changes together. Otherwise there's a risk that one of them won't get merged and even if they do both get merged you'll break bisection - it's clear that nobody can be testing this on Tomi's branch. - hdmi_data-dma_params.port_addr = hdmi_rsrc-start - + OMAP_HDMI_AUDIO_DMA_PORT; + hdmi_data-dma_params.port_addr = hdmi_rsrc-start; ...both before and after versions use the resource. This change should be present in K3.8. What is K3.8? signature.asc Description: Digital signature
Re: OMAP baseline test results for v3.7-rc5
* Kevin Hilman khil...@deeprootsystems.com [121113 17:09]: Tony Lindgren t...@atomide.com writes: Here's one more booting issue I recently ran into: - If DEBUG_LL and earlyprintk are enabled, and omap-serial.c is compiled as a module, the kernel boot hangs early as the clocks for serial port are cut while earlyprintk still uses the port. This might be regression from v3.6. Can you test if the patch below[1] helps? With that, it seems to finish booting for me (based solely on a ping test.) The problem is a race between the late_initcall for omap_device (which idles devices that have no drivers) and the late_initcall in kernel/printk.c which turns off the earlyconsole. Any printks that happen between this omap_device late initcall and the earlyconsole late initcall will crash when accessing the UART. Yeh that fixes it for me: Tested-by: Tony Lindgren t...@atomide.com Kevin [1] diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index 7a7d1f2..138114a 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -1275,4 +1275,4 @@ static int __init omap_device_late_init(void) bus_for_each_dev(platform_bus_type, NULL, NULL, omap_device_late_idle); return 0; } -late_initcall(omap_device_late_init); +late_initcall_sync(omap_device_late_init); -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On 11.11.2012 02:56, Daniel Mack wrote:
On 07.11.2012 16:37, Philip, Avinash wrote:
On Wed, Nov 07, 2012 at 15:18:37, Daniel Mack wrote:
On 05.11.2012 14:29, Philip, Avinash wrote:
On Mon, Nov 05, 2012 at 18:28:22, Daniel Mack wrote:
On 05.11.2012 12:03, Philip, Avinash wrote:
On Fri, Nov 02, 2012 at 20:55:56, Daniel Mack wrote:
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instanciated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.
Code was added to parse the generic GPMC timing parameters and some
documentation with examples on how to use them.
Successfully tested on an AM33xx board.
Signed-off-by: Daniel Mack zon...@gmail.com
[...]
+
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
+ nand-bus-width = 16;
+ nand-ecc-mode = none;
+
+ gpmc,sync-clk = 0;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 36;
+ gpmc,cs-wr-off = 36;
+ gpmc,adv-on = 6;
+ gpmc,adv-rd-off = 24;
+ gpmc,adv-wr-off = 36;
+ gpmc,we-off = 30;
+ gpmc,oe-off = 48;
+ gpmc,access = 54;
+ gpmc,rd-cycle = 72;
+ gpmc,wr-cycle = 72;
+ gpmc,wr-access = 30;
+ gpmc,wr-data-mux-bus = 0;
+
+ #address-cells = 1;
+ #size-cells = 1;
+
Can you take the timings (for example) from arago tree. The timings is
tested in am335x-evm
So the timings can be directly used to populate GPMC timings. Timings
can found at
http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;
h=66bfbd2c5b35dc81edce0c24843c476161ab5978;hp=370630359cb8db711cf0941cd2a242e28ccfb61e
[...]
+static int gpmc_probe_dt(struct platform_device *pdev)
Can you take care of the following section mismatch.
WARNING: vmlinux.o(.text+0x1e2d0): Section mismatch in reference
from the function gpmc_probe_dt() to the function
.init.text:gpmc_nand_init().
Sore, both fixed for v4.
[...]
+
+ val = of_get_nand_ecc_mode(child);
+ if (val = 0)
+ gpmc_nand_data-ecc_opt = val;
This will fail for BCH. Index of soft_bch is 5 also don't have
selection
option between for BCH4 BCH8 also.
Can you use the of_property_read_u32 (as done early) to pass the ecc
selection
from dt file. This will help selection of BCH4 BCH8 ecc options.
Hmm. Shouldn't we rather teach of_get_nand_ecc_mode() that two modes and
bring the enum in sync?
ecc_opt is for selecting different ecc layout and not for selecting ecc
mode.
In omap2 driver NAND_ECC_HW ecc mode supports 3 ecc layout
OMAP_ECC_HAMMING_CODE_HW_ROMCODE
OMAP_ECC_BCH4_CODE_HW
OMAP_ECC_BCH8_CODE_HW
So selection of ecc layout data should come from DT not ecc mode.
Ok, I see. I would still like to set them by string rather than magic
numbers that map to enum entries. Valid values would be none, hw,
hw-romcode, bch4 and bch8. Are you ok with that?
Ok, that's nice. Better use ecc_opt instead of ecc_mode.
I did some more extensive tests that include reading the same nand pages
from both U-Boot and the kernel with BCH8 ECC, and it turns out that
-is_elm_used needs to be set in the pdata in order to make this work.
So the question is whether we actually want to have a DT property for
that or just always enable that bit in case a hardware supported ecc
mode is selected. Any opinion on this?
That's the last topic before I'm clear to send off v4.
Any opionion on this, anyone?
Thanks,
Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP4: PM: fix errata handling when CONFIG_PM=n
From: Kevin Hilman khil...@ti.com
commit c9621844 (ARM: OMAP4: PM: add errata support) introduced errata
handling for OMAP4, but was broken when CONFIG_PM=n.
When CONFIG_PM=n, pm44xx.c is not compiled, yet that is where pm44xx_errata
is defined. However, these errata are needed for the SMP boot/hotplug case
also, and are primarily used in omap-smp.c.
Move the definition of pm44xx_errata to omap-smp.c so that it's available
even in the CONFIG_PM=n case.
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
This patch applies on top of Tony's fixes-non-critical-part-2.
The bug was introduced in my for_3.8-fixes-pm tag (now included in Tony's
fixes-non-critical-part2.)
arch/arm/mach-omap2/omap-smp.c | 2 ++
arch/arm/mach-omap2/pm44xx.c | 1 -
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 49a08df..cd42d92 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -40,6 +40,8 @@
#define OMAP5_CORE_COUNT 0x2
+u16 pm44xx_errata;
+
/* SCU base address */
static void __iomem *scu_base;
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 0adbd7d..04922d1 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -34,7 +34,6 @@ struct power_state {
};
static LIST_HEAD(pwrst_list);
-u16 pm44xx_errata;
#ifdef CONFIG_SUSPEND
static int omap4_pm_suspend(void)
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
On 11/14/2012 04:21 PM, Tony Lindgren wrote: * Rob Herring robherri...@gmail.com [121114 13:59]: On 11/14/2012 02:32 PM, Tony Lindgren wrote: Checking for the bit already set should work in this case, I'll post a patch for that shortly. Can you actually read the state of the diagnostic register in non-secure mode? If you can on the A9, is the same true on A8 or others? Looks like it can be read on at least TI omap 4430 which is A9. But it reads as zero, so the below patch is what I came up with. No idea if assuming that zero value for the diagnostic register is safe.. What's the default value of the diagnostic register supposed to be? RTFM. Oh, wait it's a super secret, undocumented register. We shouldn't even be talking about it. It could vary by rev, but I see 0 for the reset value, so this would not work if the bootloader did not do any setup of the diagnostic register. One way to determine secure mode on the A9 would be seeing if you can change the auxcr register. Something like this (untested): mrc p15, 0, r0, c1, c0, 1; Read ACTLR eor r1, r0, #0x100 ; Modify alloc in 1 way mcr p15, 0, r1, c1, c0, 1 mrc p15, 0, r2, c1, c0, 1; Read ACTLR mcr p15, 0, r0, c1, c0, 1 ; Restore original value cmp r1, r2 bne skip_errata It would be good to do this test for all the errata rather than just this one. Rob Multi-platform kernels present a new problem in that we basically need to enable all errata work-arounds. I've been meaning to look thru the errata work-arounds to figure out which ones can be selected for multi-platform kernels without side effects on unaffected parts (i.e. set a chicken bit based on core revision). For any in runtime paths, we may need to do runtime patching if they have performance impact. Yeah that's how I ran into it as multiplatform enabled omap booted on other omaps but not on omap4. Regards, Tony From: Tony Lindgren t...@atomide.com Date: Tue, 13 Nov 2012 16:57:42 -0800 Subject: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 for secure mode Looks like enabling CONFIG_ARM_ERRATA_751472 causes TI omap4 blaze to not boot when enabled. The ARM core on it is an earlier r1p2. This seems to be caused by the write to the diagnostic register that shortly after causes an exception as writing to the diagnostic register on systems with secure mode is not allowed. Also it seems that reading the diagnostic register results zero so we may not be able to check if bit #11 is already set. Let's assume that if the diagnostic register is zero, we don't want to touch it as it seems to hint secure mode at least on TI omaps. If it's non-zero, check if bit #11 is set and only attempt to set it if not set. --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -238,9 +238,13 @@ __v7_setup: #if defined(CONFIG_ARM_ERRATA_751472) defined(CONFIG_SMP) ALT_SMP(cmp r6, #0x30) @ present prior to r3p0 ALT_UP_B(1f) - mrclt p15, 0, r10, c15, c0, 1 @ read diagnostic register - orrlt r10, r10, #1 11 @ set bit #11 - mcrlt p15, 0, r10, c15, c0, 1 @ write diagnostic register + bge 1f @ not needed for r3p0 and later + mrc p15, 0, r10, c15, c0, 1 @ read diagnostic register + teq r10, #0 @ zero for secure mode? + beq 1f @ bail out for secure mode + tst r10, #1 11 @ bit #11 already set? + orreq r10, r10, #1 11 @ set bit #11 if not set + mcreq p15, 0, r10, c15, c0, 1 @ write diagnostic register 1: #endif -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/26] Move OMAP2+ over to common clk framework
Hi Mike,
On Tuesday 13 November 2012 08:43:23 Mike Turquette wrote:
Quoting Laurent Pinchart (2012-11-13 05:42:35)
On Wednesday 07 November 2012 17:12:35 Mike Turquette wrote:
From: Mike Turquette mturque...@linaro.org
Hi all,
This series is based on top of Paul's PRM/CM clean-up work. It is a
refresh of the patches Rajendra sent out a while back[1], with the
addition of several fixes for PM regressions[2] across several
platforms.
I have tested on OMAP4430 Panda including PRCM diffing against pre-CCF
patches (delta is zero) and also suspend/resume.
I also tested on OMAP4460 Panda-ES. Boot is fine and PRCM programming
appears sane. However Panda-ES never comes back from suspend/resume.
This problem exists on the PRM/CM branch I based on and was not
introduced by this series. I am investigating that independently of
this series.
Anyone wanting to pull the work can find it at:
git://git.linaro.org/people/mturquette/linux.git clk-omap-3.8
[1] http://article.gmane.org/gmane.linux.ports.arm.omap/78771
[2] http://article.gmane.org/gmane.linux.ports.arm.omap/84015
I've tested the whole series on a Beagleboard-xM. The kernel boots fine
but
spits a couple of WARN_ON due to missing clk_prepare in USB-related
drivers. I haven't noticed any regression in the OMAP3 ISP driver.
Those drivers need to be fixed. Can you provide a log?
Complete boot log attached to this e-mail. My tree is based on your clk-
omap-3.8 branch in git://git.linaro.org/people/mturquette/linux.git. I haven't
checked yet if patches for the following warnings have been posted to linux-
omap or other mailing lists.
I've also successfully tested rate back-propagation (CLK_SET_RATE_PARENT)
on the dpll4_m5x2_ck and cam_mclk clocks with the OMAP3 ISP driver. I'll
send a patch for that on top of your v3.
It is great to see this feature in action. Do you think the OMAP3 ISP
driver can have parent clock info removed? The goal of the
CLK_SET_RATE_PARENT flag is to make life easier for drivers by not
having to know the details of the clock tree topology.
If you mean removing the explicit handling of dpll4_m5_ck and setting the
cam_mclk rate directly then yes, that's the goal, and I'll submit patches for
that when the successor to thiis patch series will reach mainline. If you mean
something different please elaborate :-)
So,
Tested-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Thanks for testing!
--
Regards,
Laurent Pinchart
[0.00] Booting Linux on physical CPU 0
[0.00] Linux version 3.7.0-rc2-00295-g2d0135b (laurent@avalon) (gcc version 4.4.1 ('cs2009q3-67-hard-sb4') ) #454 Thu Nov 15 01:52:32 CET 2012
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[0.00] Machine: OMAP3 Beagle Board
[0.00] Ignoring tag cmdline (using the default kernel command line)
[0.00] Reserving 16777216 bytes SDRAM for VRAM
[0.00] cma: CMA: reserved 16 MiB at 9dc0
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk )
[0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/600 MHz
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 125696
[0.00] Kernel command line: console=ttyO2,115200 omapfb.mode=dvi:1024x768MR-32@60 omapdss.def_disp=dvi
[0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
[0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Memory: 495MB = 495MB total
[0.00] Memory: 471724k/471724k available, 52564k reserved, 0K highmem
[0.00] Virtual kernel memory layout:
[0.00] vector : 0x - 0x1000 ( 4 kB)
[0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB)
[0.00] vmalloc : 0xe080 - 0xff00 ( 488 MB)
[0.00] lowmem : 0xc000 - 0xe000 ( 512 MB)
[0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB)
[0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB)
[0.00] .text : 0xc0008000 - 0xc0624dd0 (6260 kB)
[0.00] .init : 0xc0625000 - 0xc065a300 ( 213 kB)
[0.00] .data : 0xc065c000 - 0xc0815e50 (1768 kB)
[0.00].bss : 0xc0815e74 - 0xc0dd87c0 (5899 kB)
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts
[0.00] Total of 96 interrupts on 1 active controller
[0.00] OMAP clockevent source: GPTIMER12 at 32768 Hz
[0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
[0.00] OMAP clocksource: 32k_counter at 32768 Hz
[0.00]
[PATCH] ARM: OMAP2+: voltage: fixup oscillator handling when CONFIG_PM=n
From: Kevin Hilman khil...@ti.com
commit 908b75e8 (ARM: OMAP: add support for oscillator setup) added a new
API for oscillator setup, but is broken when CONFIG_PM=n.
The new functions have dummy definitions when CONFIG_PM=n, but also have
full implementations available, which conflict.
To fix, wrap the PM implmentations in #ifdef CONFIG_PM.
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
This applies to Tony's omap-for-v3.8/pm branch, which includes my
for_3.8-pm-voltage tag where this bug was introduced.
arch/arm/mach-omap2/pm.c | 2 ++
arch/arm/mach-omap2/pm.h | 2 +-
arch/arm/mach-omap2/vc.c | 2 ++
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 109a02e..ef668c756 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -39,6 +39,7 @@ static struct omap_device_pm_latency *pm_lats;
*/
int (*omap_pm_suspend)(void);
+#ifdef CONFIG_PM
/**
* struct omap2_oscillator - Describe the board main oscillator latencies
* @startup_time: oscillator startup latency
@@ -68,6 +69,7 @@ void omap_pm_get_oscillator(u32 *tstart, u32 *tshut)
*tstart = oscillator.startup_time;
*tshut = oscillator.shutdown_time;
}
+#endif
static int __init _init_omap_device(char *name)
{
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 4db7b23..02c291c 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -135,7 +135,7 @@ extern void omap_pm_get_oscillator(u32 *tstart, u32 *tshut);
extern void omap_pm_setup_sr_i2c_pcb_length(u32 mm);
#else
static inline void omap_pm_setup_oscillator(u32 tstart, u32 tshut) { }
-static inline void omap_pm_get_oscillator(u32 *tstart, u32 *tshut) { }
+static inline void omap_pm_get_oscillator(u32 *tstart, u32 *tshut) { *tstart =
*tshut = 0; }
static inline void omap_pm_setup_sr_i2c_pcb_length(u32 mm) { }
#endif
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 687aa86..a89ec8a 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -666,6 +666,7 @@ static u8 omap_vc_calc_vsel(struct voltagedomain *voltdm,
u32 uvolt)
return voltdm-pmic-uv_to_vsel(uvolt);
}
+#ifdef CONFIG_PM
/**
* omap_pm_setup_sr_i2c_pcb_length - set length of SR I2C traces on PCB
* @mm: length of the PCB trace in millimetres
@@ -678,6 +679,7 @@ void __init omap_pm_setup_sr_i2c_pcb_length(u32 mm)
{
sr_i2c_pcb_length = mm;
}
+#endif
void __init omap_vc_init_channel(struct voltagedomain *voltdm)
{
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: PM: fix errata handling when CONFIG_PM=n
* Kevin Hilman khil...@deeprootsystems.com [121114 16:56]: From: Kevin Hilman khil...@ti.com commit c9621844 (ARM: OMAP4: PM: add errata support) introduced errata handling for OMAP4, but was broken when CONFIG_PM=n. When CONFIG_PM=n, pm44xx.c is not compiled, yet that is where pm44xx_errata is defined. However, these errata are needed for the SMP boot/hotplug case also, and are primarily used in omap-smp.c. Move the definition of pm44xx_errata to omap-smp.c so that it's available even in the CONFIG_PM=n case. Cc: Tero Kristo t-kri...@ti.com Signed-off-by: Kevin Hilman khil...@ti.com --- This patch applies on top of Tony's fixes-non-critical-part-2. The bug was introduced in my for_3.8-fixes-pm tag (now included in Tony's fixes-non-critical-part2.) Thanks applied to omap-for-v3.8/fixes-non-critical-v2 and pushed out. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: voltage: fixup oscillator handling when CONFIG_PM=n
* Kevin Hilman khil...@deeprootsystems.com [121114 17:15]: From: Kevin Hilman khil...@ti.com commit 908b75e8 (ARM: OMAP: add support for oscillator setup) added a new API for oscillator setup, but is broken when CONFIG_PM=n. The new functions have dummy definitions when CONFIG_PM=n, but also have full implementations available, which conflict. To fix, wrap the PM implmentations in #ifdef CONFIG_PM. Cc: Tero Kristo t-kri...@ti.com Signed-off-by: Kevin Hilman khil...@ti.com --- This applies to Tony's omap-for-v3.8/pm branch, which includes my for_3.8-pm-voltage tag where this bug was introduced. Thanks for fixing this quickly. Applied to omap-for-v3.8/pm-part2 and pushed out. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
* Rob Herring robherri...@gmail.com [121114 16:56]: On 11/14/2012 04:21 PM, Tony Lindgren wrote: * Rob Herring robherri...@gmail.com [121114 13:59]: On 11/14/2012 02:32 PM, Tony Lindgren wrote: Checking for the bit already set should work in this case, I'll post a patch for that shortly. Can you actually read the state of the diagnostic register in non-secure mode? If you can on the A9, is the same true on A8 or others? Looks like it can be read on at least TI omap 4430 which is A9. But it reads as zero, so the below patch is what I came up with. No idea if assuming that zero value for the diagnostic register is safe.. What's the default value of the diagnostic register supposed to be? RTFM. Oh, wait it's a super secret, undocumented register. We shouldn't even be talking about it. WITFM? :) It could vary by rev, but I see 0 for the reset value, so this would not work if the bootloader did not do any setup of the diagnostic register. OK One way to determine secure mode on the A9 would be seeing if you can change the auxcr register. Something like this (untested): mrc p15, 0, r0, c1, c0, 1; Read ACTLR eor r1, r0, #0x100 ; Modify alloc in 1 way mcr p15, 0, r1, c1, c0, 1 mrc p15, 0, r2, c1, c0, 1; Read ACTLR mcr p15, 0, r0, c1, c0, 1 ; Restore original value cmp r1, r2 bne skip_errata It would be good to do this test for all the errata rather than just this one. I recall writes to the aux control registers producing an exception on secure A8 based omaps, but I'll give that a try when I have a chance. 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 3/3] ASoC: OMAP: HDMI: Obtain DMA port from resources
Hi Mark, On 11/14/2012 05:08 PM, Mark Brown wrote: On Wed, Nov 14, 2012 at 11:07:09AM -0600, Ricardo Neri wrote: On 11/13/2012 09:27 PM, Mark Brown wrote: Presumably this needs some other corresponding change in the resource setup to go in simultaneously... Yes, the change in the resources setup has been submitted to the OMAPDSS HDMI driver and accepted by Tomi [1]. Don't do this. With a change like this which must be made at the same time over multiple subsystems it is very important that you send all the parts of the changes together. Otherwise there's a risk that one of them won't get merged and even if they do both get merged you'll break bisection - it's clear that nobody can be testing this on Tomi's branch. but the changes will hit linux-next at some point and they could be tested there, right? Sorry, as changes for the HDMI drivers go to several maintainers, I was trying to send the relevant patches to the respective maintainers and avoid potential merge/rebase issues. Tomi has already taken the DSS changes. Perhaps, if you and Tomi agree, Tomi could also take the ASoC and the arch/arm/mach-omap2 changes. This way all changes come from the same tree. - hdmi_data-dma_params.port_addr = hdmi_rsrc-start - + OMAP_HDMI_AUDIO_DMA_PORT; + hdmi_data-dma_params.port_addr = hdmi_rsrc-start; ...both before and after versions use the resource. This change should be present in K3.8. What is K3.8? I meant that Tomi took the DSS changes in [1] on his master branch and he should push them upstream when the merge window for kernel v3.8 opens. BR, Ricardo [1].http://www.mail-archive.com/linux-omap@vger.kernel.org/msg79795.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
[GIT PULL 1/5] omap non critical fixes for v3.8 merge window
The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89: Linux 3.7-rc4 (2012-11-04 11:07:39 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.8/fixes-non-critical-v4-signed for you to fetch changes up to 936407358759adb302df93ab61fa68141897270c: ARM: OMAP4: PM: fix errata handling when CONFIG_PM=n (2012-11-14 17:06:20 -0800) Non critical omap fixes that were not considered urgent for the -rc cycle. Colin Cross (1): ARM: OMAP4: retrigger localtimers after re-enabling gic Kevin Hilman (1): ARM: OMAP4: PM: fix errata handling when CONFIG_PM=n Santosh Shilimkar (1): ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC control register change. Tero Kristo (1): ARM: OMAP4: PM: add errata support Tony Lindgren (1): Merge tag 'for_3.8-fixes-pm' of git://git.kernel.org/.../khilman/linux-omap-pm into omap-for-v3.8/fixes-non-critical-v2 arch/arm/mach-omap2/common.h | 4 +++ arch/arm/mach-omap2/omap-headsmp.S| 38 arch/arm/mach-omap2/omap-mpuss-lowpower.c | 9 ++- arch/arm/mach-omap2/omap-smp.c| 41 +- arch/arm/mach-omap2/omap4-common.c| 42 ++- arch/arm/mach-omap2/pm.h | 9 +++ 6 files changed, 140 insertions(+), 3 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 V5 0/7] ARM: AM33XX: net: Add DT support to CPSW and MDIO driver
From: Mugunthan V N mugunthan...@ti.com Date: Thu, 15 Nov 2012 00:37:53 +0530 This patch-series adds support for, [1/7]: Typo mistake in CPSW driver while invoking runtime_pm api's [2/7]: Adds parent-child relation between CPSW MDIO module inside cpsw driver, as in case of AM33XX, the resources are shared and common register bit-field is provided to control module/clock enable/disable, makes it difficult to handle common resource. So the solution here is, to create parent-child relation between them. [3/7]: cpsw: simplify the setup of the register pointers [4/7]: cpsw: Kernel warn fix during suspend [5/7]: Add hwmod entry for MDIO module, required for MDIO driver. [6/7]: Enable CPSW support to omap2plus_defconfig [7/7]: Add DT device nodes for both CPSW and MDIO modules in am33xx.dtsi, am335x-evm.dts and am335x-bone.dts file This patch series has been created on top of net-next/master and tested on BeagleBone platform for NFS boot and basic ping test cases. All applied, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ASoC: OMAP: HDMI: Obtain DMA port from resources
On Wed, Nov 14, 2012 at 08:33:11PM -0600, Ricardo Neri wrote: On 11/14/2012 05:08 PM, Mark Brown wrote: Don't do this. With a change like this which must be made at the same time over multiple subsystems it is very important that you send all the but the changes will hit linux-next at some point and they could be tested there, right? This isn't much fun for anyone doing git bisect, it means the device will be unusuable for large periods of history. Sorry, as changes for the HDMI drivers go to several maintainers, I was trying to send the relevant patches to the respective maintainers and avoid potential merge/rebase issues. You need to make sure everyone involved knows what's going on - review should really turn up the sort of issue I just highlighted. Tomi has already taken the DSS changes. Perhaps, if you and Tomi agree, Tomi could also take the ASoC and the arch/arm/mach-omap2 changes. This way all changes come from the same tree. Yes, we're going to need to do that. Ideally all the changes would be squashed into a single commit. This change should be present in K3.8. What is K3.8? I meant that Tomi took the DSS changes in [1] on his master branch and he should push them upstream when the merge window for kernel v3.8 opens. Do you mean that K3.8 is v3.8? signature.asc Description: Digital signature
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On Tue, Nov 13, 2012 at 03:38:18PM +0200, Pantelis Antoniou wrote: Hi Grant, On Nov 13, 2012, at 2:24 PM, Grant Likely wrote: On Tue, Nov 13, 2012 at 8:09 AM, Pantelis Antoniou [snip] My intention wasn't never to make overlays overly portable. My intention was to make them in a way that portability can be introduced if the boards are 'close' enough, but not for arbitrary boards. There have to be compatible interfaces both on the base, and the overlay dtbs. Right. And this is why I'm arguing that those interfaces should be described explicitly - using existing OF mechanisms like interrupt-map where possible, rather than having a very general, but very low-level interface to make arbitrary changes to the DT. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] i2c: omap: Move the remove constraint
Currently we just queue the transfer and release the qos constraints, however we donot wait for the transfer to complete to release the constraint. Move the remove constraint after the bus busy as we are sure that the transfers are completed by then. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- v2: rebase to the for-next branch drivers/i2c/busses/i2c-omap.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 482c63d..fabcbe1 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -654,13 +654,14 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) break; } - if (dev-set_mpu_wkup_lat != NULL) - dev-set_mpu_wkup_lat(dev-dev, -1); - if (r == 0) r = num; omap_i2c_wait_for_bb(dev); + + if (dev-set_mpu_wkup_lat != NULL) + dev-set_mpu_wkup_lat(dev-dev, -1); + out: pm_runtime_mark_last_busy(dev-dev); pm_runtime_put_autosuspend(dev-dev); -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
