Re: omap DSS fails with tft410 driver panel?
On 2012-12-18 10:31, Javier Martinez Canillas wrote: Did you find a solution for this? Not that I know. Also I have this log about a locking dependency: [ 24.690795] [ 24.690826] == [ 24.690826] [ INFO: possible circular locking dependency detected ] [ 24.690826] 3.7.0-00017-g6c2ecfb-dirty #144 Not tainted [ 24.690826] --- I've also seen these. But they don't seem to happen with linux-next (or Linus' current tree). I haven't been able to figure out the reason for the warning, but as they seem to have disappeared, they may be related to something else than omapfb/omapdss. Tomi signature.asc Description: OpenPGP digital signature
Re: omap DSS fails with tft410 driver panel?
On 2012-12-18 15:45, Javier Martinez Canillas wrote: Hi, I've tested with the latest stable kernel (Linux 3.7.1) and the video output is working correctly with the same user-space components. The complete dmesg is here: http://fpaste.org/1Kv4/ Looking at the logs for both kernels I realized that there are two differences main between the working (3.7.1) and non-working (mainline) kernel (besides the versions of course): a) The number of framebuffers created (working 1, non working 3) b) The omapfb now uses dma_alloc_attrs to allocate memory instead of the now removed OMAP-specific omap_vram_alloc For a) I built mainline with CONFIG_FB_OMAP2_NUM_FBS=1 and that made the error about the overlay paddr being zero disappear (OVERLAY error: check_overlay: paddr cannot be 0) but still no video on the screen. Ok. I think the reason for that is that the paddr errors come from X trying to setup the video overlays with paddr 0. The video overlays are by default on fb1 and fb2, so they are not present if you set the NUM_FBS to 1. Conversely I build 3.7.1 with CONFIG_FB_OMAP2_NUM_FBS=3 and even though I had the paddr can't be zero error, video is working correctly. So it seems that error shouldn't affect the video display. Hmm, so do you get any display with 3.8, before X is started, using plain fb? For example, break the boot before X is started, and do cat /dev/urandom /dev/fb0 Do you have an userspace image I could download to reproduce this? For b) I tried to built mainline with CONFIG_CMA=y but it didn't work either. I don't think the vram change affects this, except if you see errors about mem alloc. But yes, I think you should enable CMA with 3.8, although allocation may work fine for smaller displays even without CMA. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH V2 4/6] OMAPDSS: DSI: Move DSI specific reg_fields to dsi_feats
On Monday 17 December 2012 05:53 PM, Tomi Valkeinen wrote:
Hi,
On 2012-12-05 12:16, Chandrabhanu Mahapatra wrote:
The DSI specific dss_reg_fields are moved to corresponding dsi_reg_fields
initialized in dsi_feats. The dsi_feats structure is initialized as per
corresponding DSS version in dsi_init_features().
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dsi.c | 126
+---
drivers/video/omap2/dss/dss_features.c | 16
drivers/video/omap2/dss/dss_features.h |4 -
3 files changed, 114 insertions(+), 32 deletions(-)
+static int __init dsi_init_features(struct platform_device *dsidev)
+{
+const struct feats *src;
+struct feats *dst;
+
+dst = devm_kzalloc(dsidev-dev, sizeof(*dst), GFP_KERNEL);
+if (!dst) {
+dev_err(dsidev-dev, Failed to allocate DISPC Features\n);
+return -ENOMEM;
+}
+
+switch (omapdss_get_version()) {
+case OMAPDSS_VER_OMAP24xx:
+src = omap24xx_dsi_feats;
+break;
+
+case OMAPDSS_VER_OMAP34xx_ES1:
+case OMAPDSS_VER_OMAP34xx_ES3:
+case OMAPDSS_VER_OMAP3630:
+case OMAPDSS_VER_AM35xx:
+src = omap34xx_dsi_feats;
+break;
+
+case OMAPDSS_VER_OMAP4430_ES1:
+case OMAPDSS_VER_OMAP4430_ES2:
+case OMAPDSS_VER_OMAP4:
+src = omap44xx_dsi_feats;
+break;
+
+case OMAPDSS_VER_OMAP5:
+src = omap54xx_dsi_feats;
+break;
+
+default:
+return -ENODEV;
+}
There's no DSI on OMAP2, so that case can be left out.
Tomi
Ok. Forgot to see that in dss_features.
--
Chandrabhanu Mahapatra
Texas Instruments India Pvt. Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/6] OMAPDSS: DISPC: Move DISPC specific dss_reg_fields to dispc_features
On Monday 17 December 2012 06:07 PM, Tomi Valkeinen wrote:
On 2012-12-05 12:16, Chandrabhanu Mahapatra wrote:
The register fields in dss_reg_fields specific to DISPC are moved from struct
omap_dss_features to corresponding dispc_reg_fields, initialized in struct
dispc_features, thereby enabling local access.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dispc.c| 114
drivers/video/omap2/dss/dss.h |4 ++
drivers/video/omap2/dss/dss_features.c | 28
drivers/video/omap2/dss/dss_features.h |7 --
4 files changed, 89 insertions(+), 64 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c
b/drivers/video/omap2/dss/dispc.c
index bbba83f..ee4b152 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -80,6 +80,16 @@ struct dispc_irq_stats {
unsigned irqs[32];
};
+struct dispc_reg_fields {
+struct omapdss_reg_field firhinc;
+struct omapdss_reg_field firvinc;
+struct omapdss_reg_field fifo_low_thresh;
+struct omapdss_reg_field fifo_high_thresh;
+struct omapdss_reg_field fifosize;
+struct omapdss_reg_field hori_accu;
+struct omapdss_reg_field vert_accu;
+};
+
struct dispc_features {
u8 sw_start;
u8 fp_start;
@@ -110,6 +120,8 @@ struct dispc_features {
u32 buffer_size_unit; /* in bytes */
u32 burst_size_unit; /* in bytes */
+
+struct dispc_reg_fields *reg_fields;
This can be pointer to const.
Yes, the same thing can also be done in other dispc and dsi reg_fields
and param_ranges.
};
#define DISPC_MAX_NR_FIFOS 5
@@ -1137,17 +1149,17 @@ static void dispc_mgr_set_size(enum omap_channel
channel, u16 width,
static void dispc_init_fifos(void)
{
-u32 size;
+u32 size, unit;
int fifo;
-u8 start, end;
-u32 unit;
+const struct omapdss_reg_field *fifo_field;
unit = dispc.feat-buffer_size_unit;
-dss_feat_get_reg_field(FEAT_REG_FIFOSIZE, start, end);
+fifo_field = dispc.feat-reg_fields-fifosize;
for (fifo = 0; fifo dispc.feat-num_fifos; ++fifo) {
-size = REG_GET(DISPC_OVL_FIFO_SIZE_STATUS(fifo), start, end);
+size = REG_GET(DISPC_OVL_FIFO_SIZE_STATUS(fifo),
+fifo_field-start, fifo_field-end);
size *= unit;
dispc.fifo_size[fifo] = size;
@@ -1197,8 +1209,8 @@ static u32 dispc_ovl_get_fifo_size(enum omap_plane
plane)
void dispc_ovl_set_fifo_threshold(enum omap_plane plane, u32 low, u32 high)
{
-u8 hi_start, hi_end, lo_start, lo_end;
u32 unit;
+const struct omapdss_reg_field *hi_field, *lo_field;
unit = dispc.feat-buffer_size_unit;
@@ -1208,20 +1220,20 @@ void dispc_ovl_set_fifo_threshold(enum omap_plane
plane, u32 low, u32 high)
low /= unit;
high /= unit;
-dss_feat_get_reg_field(FEAT_REG_FIFOHIGHTHRESHOLD, hi_start, hi_end);
-dss_feat_get_reg_field(FEAT_REG_FIFOLOWTHRESHOLD, lo_start, lo_end);
+hi_field = dispc.feat-reg_fields-fifo_high_thresh;
+lo_field = dispc.feat-reg_fields-fifo_low_thresh;
DSSDBG(fifo(%d) threshold (bytes), old %u/%u, new %u/%u\n,
plane,
REG_GET(DISPC_OVL_FIFO_THRESHOLD(plane),
-lo_start, lo_end) * unit,
+lo_field-start, lo_field-end) * unit,
REG_GET(DISPC_OVL_FIFO_THRESHOLD(plane),
-hi_start, hi_end) * unit,
+hi_field-start, hi_field-end) * unit,
low * unit, high * unit);
dispc_write_reg(DISPC_OVL_FIFO_THRESHOLD(plane),
-FLD_VAL(high, hi_start, hi_end) |
-FLD_VAL(low, lo_start, lo_end));
+FLD_VAL(high, hi_field-start, hi_field-end) |
+FLD_VAL(low, lo_field-start, lo_field-end));
}
void dispc_enable_fifomerge(bool enable)
@@ -1289,14 +1301,13 @@ static void dispc_ovl_set_fir(enum omap_plane plane,
u32 val;
if (color_comp == DISPC_COLOR_COMPONENT_RGB_Y) {
-u8 hinc_start, hinc_end, vinc_start, vinc_end;
+const struct omapdss_reg_field *hinc_field, *vinc_field;
-dss_feat_get_reg_field(FEAT_REG_FIRHINC,
-hinc_start, hinc_end);
-dss_feat_get_reg_field(FEAT_REG_FIRVINC,
-vinc_start, vinc_end);
-val = FLD_VAL(vinc, vinc_start, vinc_end) |
-FLD_VAL(hinc, hinc_start, hinc_end);
+hinc_field = dispc.feat-reg_fields-firhinc;
+vinc_field = dispc.feat-reg_fields-firvinc;
+
+val = FLD_VAL(vinc, vinc_field-start, vinc_field-end) |
+FLD_VAL(hinc, hinc_field-start, hinc_field-end);
Re: [PATCH 1/1] ARM: dts: omap3-igep: remove VSIM regulator
On Sat, Dec 15, 2012 at 1:52 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
commit 5a8095e9 ARM: dts: Add omap3-beagle.dts
moved the VSIM regulator definition to the twl4030.dtsi to avoid
duplication. A definition for the VSIM regulator was also present
on omap3-igep.dtsi which leads to the following build error:
DTC arch/arm/boot/dts/omap3-igep0020.dtb
DTC arch/arm/boot/dts/omap3-igep0030.dtb
ERROR (duplicate_label): Duplicate label 'vsim' on
/ocp/i2c@4807/twl@48/regulator-vsim and
/ocp/i2c@4807/twl@48/regulator@10
ERROR: Input tree has errors, aborting (use -f to force output)
ERROR (duplicate_label): Duplicate label 'vsim' on
/ocp/i2c@4807/twl@48/regulator-vsim and
/ocp/i2c@4807/twl@48/regulator@10
ERROR: Input tree has errors, aborting (use -f to force output)
make[1]: *** [arch/arm/boot/dts/omap3-igep0020.dtb] Error 2
make[1]: *** Waiting for unfinished jobs
make[1]: *** [arch/arm/boot/dts/omap3-igep0030.dtb] Error 2
make: *** [dtbs] Error 2
Since IGEP devices uses the same PMIC as Beagle boards, the VSIM
definition from twl4030.dtsi can be used.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep.dtsi |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index 125fe00..de708ca 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -43,12 +43,6 @@
interrupts = 7; /* SYS_NIRQ cascaded to intc */
interrupt-parent = intc;
- vsim: regulator@10 {
- compatible = ti,twl4030-vsim;
- regulator-min-microvolt = 180;
- regulator-max-microvolt = 300;
- };
-
twl_audio: audio {
compatible = ti,twl4030-audio;
codec {
Hi Benoit,
It is ok for you that I send delta patches for the IGEP DT initial
support [1] such as this patch and the MMC device node mux pins setup
[2] or should I merge these changes and resend a new patch-set?
Thanks a lot and best regards,
Javier
[1]: https://lkml.org/lkml/2012/12/3/142
[2]: https://patchwork.kernel.org/patch/1882991/
--
To unsubscribe from this list: send the line unsubscribe 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: 32kHz clock removal causes problems omap_hsmmc
On Tue, Dec 18, 2012 at 11:54:50AM +0200, Felipe Balbi wrote: damn, this is still part of our v3.7-rc kernel. Original commit was done with no testing whatsoever and caused a big regression to (at least) TI's WiFi driver which depend on SDIO to function. Too bad things break and even when reported nobody gives a rat's *** about them :-s I guess it's going to be even more of an issue going forward given the recent events but FWIW it was always very unusual to see any review of any TWL patches, the PMIC appeared to have been rather abandoned so the only way of getting any testing was to put stuff in -next and hope. Mind you, if there is an issue it doesn't seem that serious given that it took at least one kernel release before anyone noticed and even when they did you're the first person who bothered to respond... signature.asc Description: Digital signature
[PATCH] ARM: OMAP2+: Fix compillation error in mach-omap2/timer.c
prom_add_property() has been renamed to of_add_property() This patch fixes the following comilation error: arch/arm/mach-omap2/timer.c: In function ‘omap_get_timer_dt’: arch/arm/mach-omap2/timer.c:178:3: error: implicit declaration of function ‘prom_add_property’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[1]: *** [arch/arm/mach-omap2/timer.o] Error 1 make[1]: *** Waiting for unfinished jobs Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- Hi Tony, today's mainline does not compile due to this API rename in of core. Not sure if we alreasy have fix for this pending. Regards, Peter arch/arm/mach-omap2/timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 7016637..cece724 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -175,7 +175,7 @@ static struct device_node * __init omap_get_timer_dt(struct of_device_id *match, continue; } - prom_add_property(np, device_disabled); + of_add_property(np, device_disabled); return np; } -- 1.8.0.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
downscaling YUV fails
Hello, downscaling a YUV video from /dev/fb1 silently fails and results in incorrectly rendered data (each line is shifted a bit more to the right, turning vertical lines into diagonals) -- observed with Linux 3.6.11 on omap3/dm3730 test data (an image with vertical bars) is produced by: gst-launch-0.10 videotestsrc ! video/x-raw-yuv, width=400, height=240 ! freeze ! omapfbsink cd /sys/devices/platform/omapdss/overlay1 echo 400,240 output_size echo 100,100 position echo 220,140 output_size this downscales the YUV data from 400x240-220x140 and results in distorted output data (see http://pmeerw.net/overlay-distorted.jpg) note that upscaling works more observations: setting CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=4 results in correct downscaling with x_predecim=1/y_predecim=1 CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0 leads to distorted output with x_predecim=2/y_predecim=1 I think there is a bug downscaling YUV data when resorting to pre-decimation; setting CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK is a workaround -- any ideas how this can be fixed? thanks, regards, p. -- Peter Meerwald +43-664-218 (mobile) -- To unsubscribe from this list: send the line unsubscribe 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: 32kHz clock removal causes problems omap_hsmmc
On 12/19/2012 10:45 AM, Mark Brown wrote: On Tue, Dec 18, 2012 at 11:54:50AM +0200, Felipe Balbi wrote: damn, this is still part of our v3.7-rc kernel. Original commit was done with no testing whatsoever and caused a big regression to (at least) TI's WiFi driver which depend on SDIO to function. Too bad things break and even when reported nobody gives a rat's *** about them :-s I guess it's going to be even more of an issue going forward given the recent events but FWIW it was always very unusual to see any review of any TWL patches, the PMIC appeared to have been rather abandoned so the only way of getting any testing was to put stuff in -next and hope. As for the twl-regulator I still have plan to do a major cleanup there. It is just sad that it received the DT bindings for the current code. The DT support addition would have been the perfect place to sanitize it. Now it is just going to be a huge pain in the back. As for the 32k clock: I don't know the state of the common clock framework for OMAPs. Is it already up in 3.7? Or going for 3.8? 3.9? 3.10?... We need CCF to resolve this. I can cook up the clock driver for the 32k clock from twl, but in order to use it we need CCF on OMAP. -- 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: 32kHz clock removal causes problems omap_hsmmc
Hi Mark, On Wed, 2012-12-19 at 09:45 +, Mark Brown wrote: On Tue, Dec 18, 2012 at 11:54:50AM +0200, Felipe Balbi wrote: damn, this is still part of our v3.7-rc kernel. Original commit was done with no testing whatsoever and caused a big regression to (at least) TI's WiFi driver which depend on SDIO to function. Too bad things break and even when reported nobody gives a rat's *** about them :-s I guess it's going to be even more of an issue going forward given the recent events but FWIW it was always very unusual to see any review of any TWL patches, the PMIC appeared to have been rather abandoned so the only way of getting any testing was to put stuff in -next and hope. Unfortunately I don't know how many of us are using this specific platform with the latest kernel, so not much testing is done. Mind you, if there is an issue it doesn't seem that serious given that it took at least one kernel release before anyone noticed and even when they did you're the first person who bothered to respond... To me it has been very serious. I had to revert a bunch of patches to be able to continue working with the mainline. It took me a while to see the bug because I've been away during the 3.6 cycle. I think one of the reasons not many people use the mainline with TWL is exactly because something seems to break on every new kernel release. I'm one of those who care and report things when I see them. I think saying that it is not important because only one person reported it is not a good excuse. I would at least have liked seeing an answer saying, this can't be fixed because of this and that or can you try to fix it by doing this or that. -- Cheers, Luca. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP4: PRM: Correct reset source map
In the map for reset sources register we use defines intended for
using with PRM_RSTCTRL register. So fix it.
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
arch/arm/mach-omap2/prm44xx.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 7498bc7..e335216 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -56,9 +56,9 @@ static struct omap_prcm_irq_setup omap4_prcm_irq_setup = {
* enumeration)
*/
static struct prm_reset_src_map omap44xx_prm_reset_src_map[] = {
- { OMAP4430_RST_GLOBAL_WARM_SW_SHIFT,
+ { OMAP4430_GLOBAL_WARM_SW_RST_SHIFT,
OMAP_GLOBAL_WARM_RST_SRC_ID_SHIFT },
- { OMAP4430_RST_GLOBAL_COLD_SW_SHIFT,
+ { OMAP4430_GLOBAL_COLD_RST_SHIFT,
OMAP_GLOBAL_COLD_RST_SRC_ID_SHIFT },
{ OMAP4430_MPU_SECURITY_VIOL_RST_SHIFT,
OMAP_SECU_VIOL_RST_SRC_ID_SHIFT },
--
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] ARM: OMAP4: PRM: Correct wrong instance usage for reading reset sources
To read reset sources registers we have to use PRM_DEVICE_INST Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com --- arch/arm/mach-omap2/prm44xx.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c index 7498bc7..0b61b8d 100644 --- a/arch/arm/mach-omap2/prm44xx.c +++ b/arch/arm/mach-omap2/prm44xx.c @@ -333,7 +333,7 @@ static u32 omap44xx_prm_read_reset_sources(void) u32 r = 0; u32 v; - v = omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST, + v = omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST, OMAP4_RM_RSTST); p = omap44xx_prm_reset_src_map; -- 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] ARM: OMAP4: PRM: fix RSTTIME and RSTST offsets
From: Nishanth Menon n...@ti.com RSTTIME is offset 0x8 and RSTST is offset 0x04 for OMAP4430 and OMAP4460. Signed-off-by: Nishanth Menon n...@ti.com [ivan.khoronz...@ti.com: ported from k3.4] Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com --- arch/arm/mach-omap2/prm44xx.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h index 22b0979..8ee1fbd 100644 --- a/arch/arm/mach-omap2/prm44xx.h +++ b/arch/arm/mach-omap2/prm44xx.h @@ -62,8 +62,8 @@ /* OMAP4 specific register offsets */ #define OMAP4_RM_RSTCTRL 0x -#define OMAP4_RM_RSTTIME 0x0004 -#define OMAP4_RM_RSTST 0x0008 +#define OMAP4_RM_RSTST 0x0004 +#define OMAP4_RM_RSTTIME 0x0008 #define OMAP4_PM_PWSTCTRL 0x #define OMAP4_PM_PWSTST0x0004 -- 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: 32kHz clock removal causes problems omap_hsmmc
On Wed, Dec 19, 2012 at 11:00:32AM +0100, Peter Ujfalusi wrote: I don't know the state of the common clock framework for OMAPs. Is it already up in 3.7? Or going for 3.8? 3.9? 3.10?... We need CCF to resolve this. I can cook up the clock driver for the 32k clock from twl, but in order to use it we need CCF on OMAP. Well, we at least ought to make sure it doesn't appear in the regulator DT bindings even if it's handled via some OMAP magic - that was the key point here. signature.asc Description: Digital signature
RE: [PATCH] ARM: OMAP2+: Fix compillation error in mach-omap2/timer.c
Hi Peter, Tony On Wed, Dec 19, 2012 at 15:20:09, Ujfalusi, Peter wrote: prom_add_property() has been renamed to of_add_property() This patch fixes the following comilation error: arch/arm/mach-omap2/timer.c: In function ‘omap_get_timer_dt’: arch/arm/mach-omap2/timer.c:178:3: error: implicit declaration of function ‘prom_add_property’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[1]: *** [arch/arm/mach-omap2/timer.o] Error 1 make[1]: *** Waiting for unfinished jobs Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- Hi Tony, today's mainline does not compile due to this API rename in of core. Not sure if we alreasy have fix for this pending. There following patches for needed to get omap2plus_defconfig build working https://patchwork.kernel.org/patch/1810481/ - address the build breakage due to header file cleanup https://patchwork.kernel.org/patch/1810441/ - address the prom_add_property() issue http://marc.info/?l=linux-arm-kernelm=135589966017628w=2 - this crept in during a merge commit.
Re: downscaling YUV fails
Hi, On Wednesday 19 December 2012 03:21 PM, Peter Meerwald wrote: Hello, downscaling a YUV video from /dev/fb1 silently fails and results in incorrectly rendered data (each line is shifted a bit more to the right, turning vertical lines into diagonals) -- observed with Linux 3.6.11 on omap3/dm3730 test data (an image with vertical bars) is produced by: gst-launch-0.10 videotestsrc ! video/x-raw-yuv, width=400, height=240 ! freeze ! omapfbsink cd /sys/devices/platform/omapdss/overlay1 echo 400,240 output_size echo 100,100 position echo 220,140 output_size this downscales the YUV data from 400x240-220x140 and results in distorted output data (see http://pmeerw.net/overlay-distorted.jpg) note that upscaling works more observations: setting CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=4 results in correct downscaling with x_predecim=1/y_predecim=1 CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0 leads to distorted output with x_predecim=2/y_predecim=1 Configuring CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK to 0 will make the driver try to derive a closer accurate pixel clock, but it will sacrifice on the DISPC_FCLK used by scalar. Configuring it to 4 will ensure that DISPC_FCLK is at least 4 times the pixel clock. The DISPC HW can achieve more downscaling when the DISPC_FCLK is higher. In the case we set it to 4, the DISPC_FCLK is fast enough to do the required downscaling, but in the case when it's set to 0, it might need to pre decimate rather than try to scale. I think there is a bug downscaling YUV data when resorting to pre-decimation; setting CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK is a workaround -- any ideas how this can be fixed? Pre-decimation should work for YUV formats also. Could you share DISPC reg dumps when this happens: mount -t debugfs debugfs /sys/kernel/debug cat /sys/kernel/debug/omapdss/dispc Thanks, Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32kHz clock removal causes problems omap_hsmmc
On 12/19/2012 11:09 AM, Mark Brown wrote: On Wed, Dec 19, 2012 at 11:00:32AM +0100, Peter Ujfalusi wrote: I don't know the state of the common clock framework for OMAPs. Is it already up in 3.7? Or going for 3.8? 3.9? 3.10?... We need CCF to resolve this. I can cook up the clock driver for the 32k clock from twl, but in order to use it we need CCF on OMAP. Well, we at least ought to make sure it doesn't appear in the regulator DT bindings even if it's handled via some OMAP magic - that was the key point here. Sure. It must be a clock driver. I already have similar driver (for McPDM fclk clock) for twl6040. Let me check linux-next, if CCF is there for OMAP I can send the 32k clock driver soon (after writing it and testing it). It is going to be for 3.9 but we can roll it with us I think locally to resolv issues. -- 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: 32kHz clock removal causes problems omap_hsmmc
On Wed, Dec 19, 2012 at 12:01:57PM +0200, Luciano Coelho wrote: I think one of the reasons not many people use the mainline with TWL is exactly because something seems to break on every new kernel release. I'm one of those who care and report things when I see them. Well, it's a recursive thing - nobody works on mainline, nobody reviews mainline code and therefore you shouldn't be surprised if there's issues. I think saying that it is not important because only one person reported it is not a good excuse. I would at least have liked seeing an answer saying, this can't be fixed because of this and that or can you try to fix it by doing this or that. That's not what I'm saying. What I'm saying is that it's clearly not the case that OMAP is completely broken here or anything, it appears to be one particular system which it appears vanishingly few people cared about in mainline even before all the stuff with TI recently. Looking at your report the reason I didn't reply myself is most likely to be a combination of my expectation that someone from TI would look at OMAP problems (at the time there were hundreds of people working on OMAP) and the lack of detail in your mail - the bisection report was a bit unclear as you said that you'd reverted the patch plus a couple of associated patches without saying what exactly you'd backed out and there was no analysis of the problem to engage with. signature.asc Description: Digital signature
Re: 32kHz clock removal causes problems omap_hsmmc
On Wed, Dec 19, 2012 at 11:18:11AM +0100, Peter Ujfalusi wrote: Sure. It must be a clock driver. I already have similar driver (for McPDM fclk clock) for twl6040. Let me check linux-next, if CCF is there for OMAP I can send the 32k clock driver soon (after writing it and testing it). It is going to be for 3.9 but we can roll it with us I think locally to resolv issues. Well, we still haven't got the foggiest idea what the actual problem is beyond that it's probably related to the 32kHz clock in some way (unless it was one of the other reverts that coincidentally made a difference, but we don't know what they were) so it's unlikely that just randomly implementing clock support is going to fix anything immediately here. signature.asc Description: Digital signature
Re: 32kHz clock removal causes problems omap_hsmmc
On Wed, 2012-12-19 at 10:28 +, Mark Brown wrote: On Wed, Dec 19, 2012 at 12:01:57PM +0200, Luciano Coelho wrote: I think one of the reasons not many people use the mainline with TWL is exactly because something seems to break on every new kernel release. I'm one of those who care and report things when I see them. Well, it's a recursive thing - nobody works on mainline, nobody reviews mainline code and therefore you shouldn't be surprised if there's issues. Sure, it's a vicious circle. In any case, I still endure using it and going against the flow. ;) I think saying that it is not important because only one person reported it is not a good excuse. I would at least have liked seeing an answer saying, this can't be fixed because of this and that or can you try to fix it by doing this or that. That's not what I'm saying. What I'm saying is that it's clearly not the case that OMAP is completely broken here or anything, it appears to be one particular system which it appears vanishingly few people cared about in mainline even before all the stuff with TI recently. You're right. I also had problems with MMC in a Pandaboard too, but I didn't even bother investigating it (yet) because I can use my other setup. Looking at your report the reason I didn't reply myself is most likely to be a combination of my expectation that someone from TI would look at OMAP problems (at the time there were hundreds of people working on OMAP) and the lack of detail in your mail - the bisection report was a bit unclear as you said that you'd reverted the patch plus a couple of associated patches without saying what exactly you'd backed out and there was no analysis of the problem to engage with. Right, my report was a bit vague indeed. What I meant by plus a couple of associated patches was the things that would break compilation if I reverted only the patch in question. Most likely I ended up reverting your whole patchset. I didn't provide further analysis because I had already spent too much time trying to figure out how to get my stuff to work. Reverting the patches locally and hoping someone would respond to my report was good enough for me at the time. I also agree that someone from OMAP should have picked it up, but my report went out exactly when the bomb was exploding inside TI. So that probably explains it. -- Cheers, Luca. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32kHz clock removal causes problems omap_hsmmc
On Wed, 2012-12-19 at 10:32 +, Mark Brown wrote: On Wed, Dec 19, 2012 at 11:18:11AM +0100, Peter Ujfalusi wrote: Sure. It must be a clock driver. I already have similar driver (for McPDM fclk clock) for twl6040. Let me check linux-next, if CCF is there for OMAP I can send the 32k clock driver soon (after writing it and testing it). It is going to be for 3.9 but we can roll it with us I think locally to resolv issues. Well, we still haven't got the foggiest idea what the actual problem is beyond that it's probably related to the 32kHz clock in some way (unless it was one of the other reverts that coincidentally made a difference, but we don't know what they were) so it's unlikely that just randomly implementing clock support is going to fix anything immediately here. This is exactly what I had to revert (as I mentioned in the other email, I had to revert the other patches otherwise compilation would break): 0e8e5c34 regulator: twl: Remove references to 32kHz clock from DT bindings e76ab829 regulator: twl: Remove references to the twl4030 regulator 029dd3ce regulator: twl: Remove another unused variable warning Let me know if you need more info. -- Luca. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: downscaling YUV fails
Hello, In the case we set it to 4, the DISPC_FCLK is fast enough to do the required downscaling, but in the case when it's set to 0, it might need to pre decimate rather than try to scale. this is my understanding as well I think there is a bug downscaling YUV data when resorting to pre-decimation; setting CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK is a workaround -- any ideas how this can be fixed? Pre-decimation should work for YUV formats also. Could you share DISPC reg dumps when this happens: mount -t debugfs debugfs /sys/kernel/debug cat /sys/kernel/debug/omapdss/dispc please find the files http://pmeerw.net/ok.dispc (with FCK_PER_PCK=4) and http://pmeerw.net/fail.dispc (FCK_PER_PCK=0) thanks, p. -- Peter Meerwald +43-664-218 (mobile) -- To unsubscribe from this list: send the line unsubscribe 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: 32kHz clock removal causes problems omap_hsmmc
On 12/19/2012 11:45 AM, Luciano Coelho wrote: Well, we still haven't got the foggiest idea what the actual problem is beyond that it's probably related to the 32kHz clock in some way (unless it was one of the other reverts that coincidentally made a difference, but we don't know what they were) so it's unlikely that just randomly implementing clock support is going to fix anything immediately here. This is exactly what I had to revert (as I mentioned in the other email, I had to revert the other patches otherwise compilation would break): 0e8e5c34 regulator: twl: Remove references to 32kHz clock from DT bindings e76ab829 regulator: twl: Remove references to the twl4030 regulator 029dd3ce regulator: twl: Remove another unused variable warning Yeah. 32k clock is not provided by twl. As I said I need to take a look at CCF to see if it already there. If it is clock driver + mapping + patch for wl12xx should fix the issue you are facing. Let me know if you need more info. BTW: have you happened to ubdate u-boot recently? There is a nice easter egg added there: f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls. Which means that _essential_ clocks and pads are no longer configured. -- 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: 32kHz clock removal causes problems omap_hsmmc
On 12/19/2012 11:56 AM, Peter Ujfalusi wrote: BTW: have you happened to ubdate u-boot recently? There is a nice easter egg added there: f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls. Which means that _essential_ clocks and pads are no longer configured. Meanwhile you can try to hack the u-boot to enable the 32k from there. It is going to stay up since we do not have code to control it in the kernel anymore. Also do something like this at the same time to get things working: diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h index cbc9bdb..b0ff1ec 100644 --- a/include/configs/omap4_common.h +++ b/include/configs/omap4_common.h @@ -271,4 +271,8 @@ #define CONFIG_SYS_THUMB_BUILD +/* Configure all pins and clocks */ +#define CONFIG_SYS_ENABLE_PADS_ALL +#define CONFIG_SYS_CLOCKS_ENABLE_ALL + #endif /* __CONFIG_OMAP4_COMMON_H */ -- 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: 32kHz clock removal causes problems omap_hsmmc
On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote: On 12/19/2012 11:45 AM, Luciano Coelho wrote: 0e8e5c34 regulator: twl: Remove references to 32kHz clock from DT bindings e76ab829 regulator: twl: Remove references to the twl4030 regulator 029dd3ce regulator: twl: Remove another unused variable warning Yeah. 32k clock is not provided by twl. If these changes do anything to the platform I'd expect them to be leaving the clock enabled instead of disabling it... signature.asc Description: Digital signature
BUG: spinlock bad magic on CPU#0 on BeagleBone
Hi, Current mainline on Beaglebone using the omap2plus_defconfig + 3 build fixes is triggering a BUG() [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.7.0-01415-g55bc169 (a0393953@psplinux063) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Wed Dec 19 13:40:13 IST 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: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] On node 0 totalpages: 65280 [0.00] free_area_init_node: node 0, pgdat c07b3680, node_mem_map c0d11000 [0.00] Normal zone: 512 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 64768 pages, LIFO batch:15 [0.00] AM335X ES1.0 (neon ) [0.00] PERCPU: Embedded 9 pages/cpu @c0f1a000 s12992 r8192 d15680 u36864 [0.00] pcpu-alloc: s12992 r8192 d15680 u36864 alloc=9*4096 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [0.00] Kernel command line: console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x8200,16MB ramdisk_size=65536 earlyprintk=serial [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] __ex_table already sorted, skipping sort [0.00] Memory: 255MB = 255MB total [0.00] Memory: 229012k/229012k available, 33132k 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 : 0xd080 - 0xff00 ( 744 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc06d3f3c (6960 kB) [0.00] .init : 0xc06d4000 - 0xc07252c0 ( 325 kB) [0.00] .data : 0xc0726000 - 0xc07b6068 ( 577 kB) [0.00].bss : 0xc07b608c - 0xc0d10af0 (5483 kB) [0.00] Hierarchical RCU implementation. [0.00] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128 interrupts [0.00] Total of 128 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER1 at 2400 Hz [0.00] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms [0.00] OMAP clocksource: GPTIMER2 at 2400 Hz [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.001227] Calibrating delay loop... 364.48 BogoMIPS (lpj=1425408) [0.109084] pid_max: default: 32768 minimum: 301 [0.109688] Security Framework initialized [0.109889] Mount-cache hash table entries: 512 [0.112674] BUG: spinlock bad magic on CPU#0, swapper/0/0 [0.112724] lock: atomic64_lock+0x240/0x400, .magic: , .owner: none/-1, .owner_cpu: 0 [0.112782] [c001af64] (unwind_backtrace+0x0/0xf0) from [c02c2010] (do_raw_spin_lock+0x158/0x198) [0.112813] [c02c2010] (do_raw_spin_lock+0x158/0x198) from [c04d89ec] (_raw_spin_lock_irqsave+0x4c/0x58) [0.112844] [c04d89ec] (_raw_spin_lock_irqsave+0x4c/0x58) from [c02cabf0] (atomic64_add_return+0x30/0x5c) [0.112886] [c02cabf0] (atomic64_add_return+0x30/0x5c) from [c0124564] (alloc_mnt_ns.clone.14+0x44/0xac) [0.112914] [c0124564] (alloc_mnt_ns.clone.14+0x44/0xac) from [c0124f4c] (create_mnt_ns+0xc/0x54) [0.112951] [c0124f4c] (create_mnt_ns+0xc/0x54) from [c06f31a4] (mnt_init+0x120/0x1d4) [0.112978] [c06f31a4] (mnt_init+0x120/0x1d4) from [c06f2d50] (vfs_caches_init+0xe0/0x10c) [0.113005] [c06f2d50] (vfs_caches_init+0xe0/0x10c) from [c06d4798] (start_kernel+0x29c/0x300) [0.113029] [c06d4798] (start_kernel+0x29c/0x300) from [80008078] (0x80008078) [0.118290] CPU: Testing write buffer coherency: ok [0.118968] CPU0: thread -1, cpu 0, socket -1, mpidr 0 [0.119053]
Re: 32kHz clock removal causes problems omap_hsmmc
On Wed, 2012-12-19 at 11:56 +0100, Peter Ujfalusi wrote: On 12/19/2012 11:45 AM, Luciano Coelho wrote: Well, we still haven't got the foggiest idea what the actual problem is beyond that it's probably related to the 32kHz clock in some way (unless it was one of the other reverts that coincidentally made a difference, but we don't know what they were) so it's unlikely that just randomly implementing clock support is going to fix anything immediately here. This is exactly what I had to revert (as I mentioned in the other email, I had to revert the other patches otherwise compilation would break): 0e8e5c34 regulator: twl: Remove references to 32kHz clock from DT bindings e76ab829 regulator: twl: Remove references to the twl4030 regulator 029dd3ce regulator: twl: Remove another unused variable warning Yeah. 32k clock is not provided by twl. As I said I need to take a look at CCF to see if it already there. If it is clock driver + mapping + patch for wl12xx should fix the issue you are facing. Let me know if you need more info. BTW: have you happened to ubdate u-boot recently? There is a nice easter egg added there: f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls. Which means that _essential_ clocks and pads are no longer configured. Actually no, I haven't updated my u-boot for a while. I'll check if that improves things. -- Luca. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: downscaling YUV fails
On 2012-12-19 12:51, Peter Meerwald wrote: Hello, In the case we set it to 4, the DISPC_FCLK is fast enough to do the required downscaling, but in the case when it's set to 0, it might need to pre decimate rather than try to scale. this is my understanding as well I think there is a bug downscaling YUV data when resorting to pre-decimation; setting CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK is a workaround -- any ideas how this can be fixed? Pre-decimation should work for YUV formats also. Could you share DISPC reg dumps when this happens: mount -t debugfs debugfs /sys/kernel/debug cat /sys/kernel/debug/omapdss/dispc please find the files http://pmeerw.net/ok.dispc (with FCK_PER_PCK=4) and http://pmeerw.net/fail.dispc (FCK_PER_PCK=0) Something funny is going on here. I can reproduce on omap3 with a few hacks that reduce the clocks. The PICTURE_SIZE's width field is different for working and non-working cases, but I think it should be the same for both. Even more interesting, with my tests I first setup the ovl with a test picture, and see the issue (with RGB mode also). If I then use fbset to first set the mode to YUV and then back to RGB, predecimation is not used and the issue is not visible... Tomi signature.asc Description: OpenPGP digital signature
Re: downscaling YUV fails
On 2012-12-19 13:19, Tomi Valkeinen wrote: On 2012-12-19 12:51, Peter Meerwald wrote: Hello, In the case we set it to 4, the DISPC_FCLK is fast enough to do the required downscaling, but in the case when it's set to 0, it might need to pre decimate rather than try to scale. this is my understanding as well I think there is a bug downscaling YUV data when resorting to pre-decimation; setting CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK is a workaround -- any ideas how this can be fixed? Pre-decimation should work for YUV formats also. Could you share DISPC reg dumps when this happens: mount -t debugfs debugfs /sys/kernel/debug cat /sys/kernel/debug/omapdss/dispc please find the files http://pmeerw.net/ok.dispc (with FCK_PER_PCK=4) and http://pmeerw.net/fail.dispc (FCK_PER_PCK=0) Something funny is going on here. I can reproduce on omap3 with a few hacks that reduce the clocks. The PICTURE_SIZE's width field is different for working and non-working cases, but I think it should be the same for both. Ah, never mind. Of course the picture_size needs to be modified if predecimation is used... Tomi signature.asc Description: OpenPGP digital signature
Re: downscaling YUV fails
On Wednesday 19 December 2012 04:51 PM, Tomi Valkeinen wrote: On 2012-12-19 13:19, Tomi Valkeinen wrote: On 2012-12-19 12:51, Peter Meerwald wrote: Hello, In the case we set it to 4, the DISPC_FCLK is fast enough to do the required downscaling, but in the case when it's set to 0, it might need to pre decimate rather than try to scale. this is my understanding as well I think there is a bug downscaling YUV data when resorting to pre-decimation; setting CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK is a workaround -- any ideas how this can be fixed? Pre-decimation should work for YUV formats also. Could you share DISPC reg dumps when this happens: mount -t debugfs debugfs /sys/kernel/debug cat /sys/kernel/debug/omapdss/dispc please find the files http://pmeerw.net/ok.dispc (with FCK_PER_PCK=4) and http://pmeerw.net/fail.dispc (FCK_PER_PCK=0) Something funny is going on here. I can reproduce on omap3 with a few hacks that reduce the clocks. The PICTURE_SIZE's width field is different for working and non-working cases, but I think it should be the same for both. Ah, never mind. Of course the picture_size needs to be modified if predecimation is used... You said that you see the issue with RGB too. Did you mean the picture_size, or visually also? One thing I'm guessing is that DMA fetching with predecimation isn't really optimised for omap3, if the pixel clock in Peter's setup is high, the DISPC DMA might not be able to fetch pixels fast enough in predecimation case. That sort of supports the possibility of a skewed image seen. Peter, Do you see any SYNC_LOST or UNDERFLOW prints when this happens? Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: downscaling YUV fails
On 2012-12-19 13:52, Archit Taneja wrote: On Wednesday 19 December 2012 04:51 PM, Tomi Valkeinen wrote: On 2012-12-19 13:19, Tomi Valkeinen wrote: On 2012-12-19 12:51, Peter Meerwald wrote: Hello, In the case we set it to 4, the DISPC_FCLK is fast enough to do the required downscaling, but in the case when it's set to 0, it might need to pre decimate rather than try to scale. this is my understanding as well I think there is a bug downscaling YUV data when resorting to pre-decimation; setting CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK is a workaround -- any ideas how this can be fixed? Pre-decimation should work for YUV formats also. Could you share DISPC reg dumps when this happens: mount -t debugfs debugfs /sys/kernel/debug cat /sys/kernel/debug/omapdss/dispc please find the files http://pmeerw.net/ok.dispc (with FCK_PER_PCK=4) and http://pmeerw.net/fail.dispc (FCK_PER_PCK=0) Something funny is going on here. I can reproduce on omap3 with a few hacks that reduce the clocks. The PICTURE_SIZE's width field is different for working and non-working cases, but I think it should be the same for both. Ah, never mind. Of course the picture_size needs to be modified if predecimation is used... You said that you see the issue with RGB too. Did you mean the picture_size, or visually also? Visually. I see skewed image for both RGB and YUV modes on omap3. It was a bit difficult to reproduce, but I first forced the clocks down, and then I was able to get predecimation for RGB, but not YUV. The reason was this: if (color_mode == OMAP_DSS_COLOR_RGB24U) core_clk = 1; So for some reason, the core_clk requirement for RGB24U is x2 than for others. I have _no_ idea why that is, the line has been there from the start... After I removed the if, so that the core_clk requirement is x2 always, I also got predecimation for YUV, and I see the same skew. One thing I'm guessing is that DMA fetching with predecimation isn't really optimised for omap3, if the pixel clock in Peter's setup is high, the DISPC DMA might not be able to fetch pixels fast enough in predecimation case. That sort of supports the possibility of a skewed image seen. The image I get is stable, and clearly something that happens when, say, row_inc is one pixel too much, or similar. Tomi signature.asc Description: OpenPGP digital signature
Re: downscaling YUV fails
One thing I'm guessing is that DMA fetching with predecimation isn't really optimised for omap3, if the pixel clock in Peter's setup is high, the DISPC DMA might not be able to fetch pixels fast enough in predecimation case. That sort of supports the possibility of a skewed image seen. Do you see any SYNC_LOST or UNDERFLOW prints when this happens? not that I am aware of the issue is fully reproducible here; there seem to be two extra pixels per line p. -- Peter Meerwald +43-664-218 (mobile) -- To unsubscribe from this list: send the line unsubscribe 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: downscaling YUV fails
On Wednesday 19 December 2012 05:29 PM, Tomi Valkeinen wrote: On 2012-12-19 13:52, Archit Taneja wrote: On Wednesday 19 December 2012 04:51 PM, Tomi Valkeinen wrote: On 2012-12-19 13:19, Tomi Valkeinen wrote: On 2012-12-19 12:51, Peter Meerwald wrote: Hello, In the case we set it to 4, the DISPC_FCLK is fast enough to do the required downscaling, but in the case when it's set to 0, it might need to pre decimate rather than try to scale. this is my understanding as well I think there is a bug downscaling YUV data when resorting to pre-decimation; setting CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK is a workaround -- any ideas how this can be fixed? Pre-decimation should work for YUV formats also. Could you share DISPC reg dumps when this happens: mount -t debugfs debugfs /sys/kernel/debug cat /sys/kernel/debug/omapdss/dispc please find the files http://pmeerw.net/ok.dispc (with FCK_PER_PCK=4) and http://pmeerw.net/fail.dispc (FCK_PER_PCK=0) Something funny is going on here. I can reproduce on omap3 with a few hacks that reduce the clocks. The PICTURE_SIZE's width field is different for working and non-working cases, but I think it should be the same for both. Ah, never mind. Of course the picture_size needs to be modified if predecimation is used... You said that you see the issue with RGB too. Did you mean the picture_size, or visually also? Visually. I see skewed image for both RGB and YUV modes on omap3. It was a bit difficult to reproduce, but I first forced the clocks down, and then I was able to get predecimation for RGB, but not YUV. The reason was this: if (color_mode == OMAP_DSS_COLOR_RGB24U) core_clk = 1; So for some reason, the core_clk requirement for RGB24U is x2 than for others. I have _no_ idea why that is, the line has been there from the start... After I removed the if, so that the core_clk requirement is x2 always, I also got predecimation for YUV, and I see the same skew. One thing I'm guessing is that DMA fetching with predecimation isn't really optimised for omap3, if the pixel clock in Peter's setup is high, the DISPC DMA might not be able to fetch pixels fast enough in predecimation case. That sort of supports the possibility of a skewed image seen. The image I get is stable, and clearly something that happens when, say, row_inc is one pixel too much, or similar. Ok, about the width in this case. The original width is 400, and what we finally want is 220. After pre-decimation, the width would become 200, and we would need our scalar to actually upscale to 220. I am wondering if the driver gets confused when such a scenario occurs, or the DSS HW is weird when we upscale some predecimated content. If you look at the hinc(1024 * width/out_width) value in the FIR register, in the ok regdumps, the value is 1861, which points to downscaling. And in the fail case, it's 92, which is upscaling. Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP2+: omap2plus_defconfig: enable TFP410 chip support
Many OMAP3 based boards such as Beagle, Overo and IGEP use the TFP410 DPI-to-DVI chip. So, it's good to have it built as a module by default on OMAP2+ config. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- arch/arm/configs/omap2plus_defconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index a1dc5c0..da530a0 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -146,6 +146,7 @@ CONFIG_OMAP2_DSS_SDI=y CONFIG_OMAP2_DSS_DSI=y CONFIG_FB_OMAP2=m CONFIG_PANEL_GENERIC_DPI=m +CONFIG_PANEL_TFP410=m CONFIG_PANEL_SHARP_LS037V7DW01=m CONFIG_PANEL_NEC_NL8048HL11_01B=m CONFIG_PANEL_TAAL=m -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: OMAP2+: omap2plus_defconfig: enable CMA allocator
The OMAP framebuffer driver now uses the standard dma allocator instead of the (now removed) omap specific vram allocator. Enable the Contiguous Memory Allocator by default to allow large dma memory buffers allocation. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- arch/arm/configs/omap2plus_defconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index da530a0..dc4789e 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -64,6 +64,7 @@ CONFIG_MAC80211=m CONFIG_MAC80211_RC_PID=y CONFIG_MAC80211_RC_DEFAULT_PID=y CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug +CONFIG_CMA=y CONFIG_CONNECTOR=y CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe 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/1] ARM: dts: omap3-igep: remove VSIM regulator
Hi Javier,
On 12/19/2012 10:31 AM, Javier Martinez Canillas wrote:
On Sat, Dec 15, 2012 at 1:52 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
commit 5a8095e9 ARM: dts: Add omap3-beagle.dts
moved the VSIM regulator definition to the twl4030.dtsi to avoid
duplication. A definition for the VSIM regulator was also present
on omap3-igep.dtsi which leads to the following build error:
DTC arch/arm/boot/dts/omap3-igep0020.dtb
DTC arch/arm/boot/dts/omap3-igep0030.dtb
ERROR (duplicate_label): Duplicate label 'vsim' on
/ocp/i2c@4807/twl@48/regulator-vsim and
/ocp/i2c@4807/twl@48/regulator@10
ERROR: Input tree has errors, aborting (use -f to force output)
ERROR (duplicate_label): Duplicate label 'vsim' on
/ocp/i2c@4807/twl@48/regulator-vsim and
/ocp/i2c@4807/twl@48/regulator@10
ERROR: Input tree has errors, aborting (use -f to force output)
make[1]: *** [arch/arm/boot/dts/omap3-igep0020.dtb] Error 2
make[1]: *** Waiting for unfinished jobs
make[1]: *** [arch/arm/boot/dts/omap3-igep0030.dtb] Error 2
make: *** [dtbs] Error 2
Since IGEP devices uses the same PMIC as Beagle boards, the VSIM
definition from twl4030.dtsi can be used.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep.dtsi |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index 125fe00..de708ca 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -43,12 +43,6 @@
interrupts = 7; /* SYS_NIRQ cascaded to intc */
interrupt-parent = intc;
- vsim: regulator@10 {
- compatible = ti,twl4030-vsim;
- regulator-min-microvolt = 180;
- regulator-max-microvolt = 300;
- };
-
twl_audio: audio {
compatible = ti,twl4030-audio;
codec {
Hi Benoit,
It is ok for you that I send delta patches for the IGEP DT initial
support [1] such as this patch and the MMC device node mux pins setup
[2] or should I merge these changes and resend a new patch-set?
It is always better to re-send a clean patch set instead of fixing a
previously broken one. It will be bisect friendly.
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: downscaling YUV fails
On 2012-12-19 14:19, Archit Taneja wrote: The image I get is stable, and clearly something that happens when, say, row_inc is one pixel too much, or similar. Ok, about the width in this case. The original width is 400, and what we finally want is 220. After pre-decimation, the width would become 200, and we would need our scalar to actually upscale to 220. I am wondering if the driver gets confused when such a scenario occurs, or the DSS HW is weird when we upscale some predecimated content. If you look at the hinc(1024 * width/out_width) value in the FIR register, in the ok regdumps, the value is 1861, which points to downscaling. And in the fail case, it's 92, which is upscaling. I can reproduce this with a very simple case. 400x200 - 200x200, and forcing horizontal predecimation. So this will cause no scaling to be used, only the pixel_inc is used to downscale. The VID1 registers are as follows. They look right to me... DISPC_OVL_BA0(VID1)8d90 DISPC_OVL_BA1(VID1)8d90 DISPC_OVL_POSITION(VID1) DISPC_OVL_SIZE(VID1) 00c700c7 DISPC_OVL_ATTRIBUTES(VID1) 00608011 DISPC_OVL_FIFO_THRESHOLD(VID1) 03ff03c0 DISPC_OVL_FIFO_SIZE_STATUS(VID1) 0400 DISPC_OVL_ROW_INC(VID1)0001 DISPC_OVL_PIXEL_INC(VID1) 0005 DISPC_OVL_PRELOAD(VID1)0100 DISPC_OVL_FIR(VID1)04000400 DISPC_OVL_PICTURE_SIZE(VID1) 00c700c7 DISPC_OVL_ACCU0(VID1) DISPC_OVL_ACCU1(VID1) DISPC_OVL_PRELOAD(VID1)0100 Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/1] ARM: dts: omap3-igep: remove VSIM regulator
On Wed, Dec 19, 2012 at 1:36 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Javier,
On 12/19/2012 10:31 AM, Javier Martinez Canillas wrote:
On Sat, Dec 15, 2012 at 1:52 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
commit 5a8095e9 ARM: dts: Add omap3-beagle.dts
moved the VSIM regulator definition to the twl4030.dtsi to avoid
duplication. A definition for the VSIM regulator was also present
on omap3-igep.dtsi which leads to the following build error:
DTC arch/arm/boot/dts/omap3-igep0020.dtb
DTC arch/arm/boot/dts/omap3-igep0030.dtb
ERROR (duplicate_label): Duplicate label 'vsim' on
/ocp/i2c@4807/twl@48/regulator-vsim and
/ocp/i2c@4807/twl@48/regulator@10
ERROR: Input tree has errors, aborting (use -f to force output)
ERROR (duplicate_label): Duplicate label 'vsim' on
/ocp/i2c@4807/twl@48/regulator-vsim and
/ocp/i2c@4807/twl@48/regulator@10
ERROR: Input tree has errors, aborting (use -f to force output)
make[1]: *** [arch/arm/boot/dts/omap3-igep0020.dtb] Error 2
make[1]: *** Waiting for unfinished jobs
make[1]: *** [arch/arm/boot/dts/omap3-igep0030.dtb] Error 2
make: *** [dtbs] Error 2
Since IGEP devices uses the same PMIC as Beagle boards, the VSIM
definition from twl4030.dtsi can be used.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep.dtsi |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index 125fe00..de708ca 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -43,12 +43,6 @@
interrupts = 7; /* SYS_NIRQ cascaded to intc */
interrupt-parent = intc;
- vsim: regulator@10 {
- compatible = ti,twl4030-vsim;
- regulator-min-microvolt = 180;
- regulator-max-microvolt = 300;
- };
-
twl_audio: audio {
compatible = ti,twl4030-audio;
codec {
Hi Benoit,
It is ok for you that I send delta patches for the IGEP DT initial
support [1] such as this patch and the MMC device node mux pins setup
[2] or should I merge these changes and resend a new patch-set?
It is always better to re-send a clean patch set instead of fixing a
previously broken one. It will be bisect friendly.
Regards,
Benoit
ok, it wasn't broken when I sent it but the recent change on
twl4030.dtsi broke it...
I'll send a v4 of the patch-set with this fix + the MMC mux pins setup
Thanks a lot and best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe 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: downscaling YUV fails
On Wednesday 19 December 2012 06:07 PM, Tomi Valkeinen wrote: On 2012-12-19 14:19, Archit Taneja wrote: The image I get is stable, and clearly something that happens when, say, row_inc is one pixel too much, or similar. Ok, about the width in this case. The original width is 400, and what we finally want is 220. After pre-decimation, the width would become 200, and we would need our scalar to actually upscale to 220. I am wondering if the driver gets confused when such a scenario occurs, or the DSS HW is weird when we upscale some predecimated content. If you look at the hinc(1024 * width/out_width) value in the FIR register, in the ok regdumps, the value is 1861, which points to downscaling. And in the fail case, it's 92, which is upscaling. I can reproduce this with a very simple case. 400x200 - 200x200, and forcing horizontal predecimation. So this will cause no scaling to be used, only the pixel_inc is used to downscale. Ah okay. My guess was wrong then :) The VID1 registers are as follows. They look right to me... DISPC_OVL_BA0(VID1)8d90 DISPC_OVL_BA1(VID1)8d90 DISPC_OVL_POSITION(VID1) DISPC_OVL_SIZE(VID1) 00c700c7 DISPC_OVL_ATTRIBUTES(VID1) 00608011 DISPC_OVL_FIFO_THRESHOLD(VID1) 03ff03c0 DISPC_OVL_FIFO_SIZE_STATUS(VID1) 0400 DISPC_OVL_ROW_INC(VID1)0001 DISPC_OVL_PIXEL_INC(VID1) 0005 DISPC_OVL_PRELOAD(VID1)0100 DISPC_OVL_FIR(VID1)04000400 DISPC_OVL_PICTURE_SIZE(VID1) 00c700c7 DISPC_OVL_ACCU0(VID1) DISPC_OVL_ACCU1(VID1) DISPC_OVL_PRELOAD(VID1)0100 The only thing which seems not so nice is that vertical taps and vid line buffer split are enabled in OVL_ATTRIBUTES. These shouldn't be harmful though. Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32kHz clock removal causes problems omap_hsmmc
Hi, +Sricharan who commited that On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote: On 12/19/2012 11:45 AM, Luciano Coelho wrote: Well, we still haven't got the foggiest idea what the actual problem is beyond that it's probably related to the 32kHz clock in some way (unless it was one of the other reverts that coincidentally made a difference, but we don't know what they were) so it's unlikely that just randomly implementing clock support is going to fix anything immediately here. This is exactly what I had to revert (as I mentioned in the other email, I had to revert the other patches otherwise compilation would break): 0e8e5c34 regulator: twl: Remove references to 32kHz clock from DT bindings e76ab829 regulator: twl: Remove references to the twl4030 regulator 029dd3ce regulator: twl: Remove another unused variable warning Yeah. 32k clock is not provided by twl. As I said I need to take a look at CCF to see if it already there. If it is clock driver + mapping + patch for wl12xx should fix the issue you are facing. Let me know if you need more info. BTW: have you happened to ubdate u-boot recently? There is a nice easter egg added there: f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls. Which means that _essential_ clocks and pads are no longer configured. anything essential you can list ? -- balbi signature.asc Description: Digital signature
Re: downscaling YUV fails
On 2012-12-19 15:00, Archit Taneja wrote: On Wednesday 19 December 2012 06:07 PM, Tomi Valkeinen wrote: On 2012-12-19 14:19, Archit Taneja wrote: The image I get is stable, and clearly something that happens when, say, row_inc is one pixel too much, or similar. Ok, about the width in this case. The original width is 400, and what we finally want is 220. After pre-decimation, the width would become 200, and we would need our scalar to actually upscale to 220. I am wondering if the driver gets confused when such a scenario occurs, or the DSS HW is weird when we upscale some predecimated content. If you look at the hinc(1024 * width/out_width) value in the FIR register, in the ok regdumps, the value is 1861, which points to downscaling. And in the fail case, it's 92, which is upscaling. I can reproduce this with a very simple case. 400x200 - 200x200, and forcing horizontal predecimation. So this will cause no scaling to be used, only the pixel_inc is used to downscale. Ah okay. My guess was wrong then :) The VID1 registers are as follows. They look right to me... DISPC_OVL_BA0(VID1)8d90 DISPC_OVL_BA1(VID1)8d90 DISPC_OVL_POSITION(VID1) DISPC_OVL_SIZE(VID1) 00c700c7 DISPC_OVL_ATTRIBUTES(VID1) 00608011 DISPC_OVL_FIFO_THRESHOLD(VID1) 03ff03c0 DISPC_OVL_FIFO_SIZE_STATUS(VID1) 0400 DISPC_OVL_ROW_INC(VID1)0001 DISPC_OVL_PIXEL_INC(VID1) 0005 DISPC_OVL_PRELOAD(VID1)0100 DISPC_OVL_FIR(VID1)04000400 DISPC_OVL_PICTURE_SIZE(VID1) 00c700c7 DISPC_OVL_ACCU0(VID1) DISPC_OVL_ACCU1(VID1) DISPC_OVL_PRELOAD(VID1)0100 The only thing which seems not so nice is that vertical taps and vid line buffer split are enabled in OVL_ATTRIBUTES. These shouldn't be harmful though. Yep, I've tested disabling five_taps also, but it doesn't have any effect. I'm at loss here =). If I force pix inc to 1, I get what I expect: an image without skew, but the height is doubled as the left and right sides are shows on two lines. Then setting pix inc to 5 causes the skew. Colors are still correct, so the byte alignment is right. Tomi signature.asc Description: OpenPGP digital signature
[PATCH v4 0/3] ARM/dts: omap3: Add DT support for IGEP devices
IGEP technology devices are TI OMAP3 SoC based industrial embedded and computer-on-module boards. This patch-set adds initial device tree support for these devices. The device trees allows to boot from an MMC and are working all the components that already have device tree support on OMAP3 SoCs: - MMC/SD - UARTs - GPIO LEDs - TWL4030 codec audio - pinmux/pinconf pinctrl Some peripheral are still not working such as Flash storage and Ethernet but support for these will also be included once the OMAP GPMC device tree binding patches land on mainline. This is a v4 of the patch-set that adds MMC mux pins setup and fixes a build issue due recent changes on twl4030.dtsi. The patch-set is composed of the following patches: [PATCH v4 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices [PATCH v4 2/3] ARM/dts: omap3: Add support for IGEPv2 board [PATCH v4 3/3] ARM/dts: omap3: Add support for IGEP COM Module -- To unsubscribe from this list: send the line unsubscribe 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 v4 2/3] ARM/dts: omap3: Add support for IGEPv2 board
ISEE IGEPv2 is an TI OMAP3 SoC based embedded board.
This patch adds an initial device tree support to boot
an IGEPv2 from the MMC/SD.
Currently is working everything that is supported by DT
on OMAP3 SoCs (MMC/SD, GPIO LEDs, EEPROM, TWL4030 audio).
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
---
Changes since v1:
- Use default-state = on instead default-trigger = default-on for LED
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap3-igep0020.dts | 56 ++
2 files changed, 57 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-igep0020.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0f44174..24b28ba 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -106,6 +106,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
+ omap3-igep0020.dtb \
omap4-panda.dtb \
omap4-panda-es.dtb \
omap4-var-som.dtb \
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
new file mode 100644
index 000..e2b9849
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -0,0 +1,56 @@
+/*
+ * Device Tree Source for IGEPv2 board
+ *
+ * Copyright (C) 2012 Javier Martinez Canillas jav...@collabora.co.uk
+ * Copyright (C) 2012 Enric Balletbo i Serra eballe...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/include/ omap3-igep.dtsi
+
+/ {
+ model = IGEPv2;
+ compatible = isee,omap3-igep0020, ti,omap3;
+
+ leds {
+ compatible = gpio-leds;
+ boot {
+label = omap3:green:boot;
+gpios = gpio1 26 0;
+default-state = on;
+ };
+
+ user0 {
+label = omap3:red:user0;
+gpios = gpio1 27 0;
+default-state = off;
+ };
+
+ user1 {
+label = omap3:red:user1;
+gpios = gpio1 28 0;
+default-state = off;
+ };
+
+ user2 {
+ label = omap3:green:user1;
+ gpios = twl_gpio 19 1;
+ };
+ };
+};
+
+i2c3 {
+ clock-frequency = 10;
+
+ /*
+* Display monitor features are burnt in the EEPROM
+* as EDID data.
+*/
+ eeprom@50 {
+ compatible = ti,eeprom;
+ reg = 0x50;
+ };
+};
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe 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 v4 3/3] ARM/dts: omap3: Add support for IGEP COM Module
ISEE IGEP COM Module is an TI OMAP3 SoC computer on module.
This patch adds an initial device tree support to boot an
IGEP COM Module from the MMC/SD.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
---
Changes since v1:
- Use default-state = on instead default-trigger = default-on for LED
- Update GPIO mapping according to latest IGEP COM Module rev.E instead D
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap3-igep0030.dts | 44 ++
2 files changed, 45 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-igep0030.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 24b28ba..8880c55 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -107,6 +107,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
omap3-igep0020.dtb \
+ omap3-igep0030.dtb \
omap4-panda.dtb \
omap4-panda-es.dtb \
omap4-var-som.dtb \
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts
b/arch/arm/boot/dts/omap3-igep0030.dts
new file mode 100644
index 000..9dc48d2
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -0,0 +1,44 @@
+/*
+ * Device Tree Source for IGEP COM Module
+ *
+ * Copyright (C) 2012 Javier Martinez Canillas jav...@collabora.co.uk
+ * Copyright (C) 2012 Enric Balletbo i Serra eballe...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/include/ omap3-igep.dtsi
+
+/ {
+ model = IGEP COM Module;
+ compatible = isee,omap3-igep0030, ti,omap3;
+
+ leds {
+ compatible = gpio-leds;
+ boot {
+label = omap3:green:boot;
+gpios = twl_gpio 13 1;
+default-state = on;
+ };
+
+ user0 {
+label = omap3:red:user0;
+gpios = twl_gpio 18 1; /* LEDA */
+default-state = off;
+ };
+
+ user1 {
+label = omap3:green:user1;
+gpios = twl_gpio 19 1; /* LEDB */
+default-state = off;
+ };
+
+ user2 {
+label = omap3:red:user1;
+gpios = gpio1 16 1;
+default-state = off;
+ };
+ };
+};
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe 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: 32kHz clock removal causes problems omap_hsmmc
On 12/19/2012 02:01 PM, Felipe Balbi wrote: Hi, +Sricharan who commited that On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote: On 12/19/2012 11:45 AM, Luciano Coelho wrote: Well, we still haven't got the foggiest idea what the actual problem is beyond that it's probably related to the 32kHz clock in some way (unless it was one of the other reverts that coincidentally made a difference, but we don't know what they were) so it's unlikely that just randomly implementing clock support is going to fix anything immediately here. This is exactly what I had to revert (as I mentioned in the other email, I had to revert the other patches otherwise compilation would break): 0e8e5c34 regulator: twl: Remove references to 32kHz clock from DT bindings e76ab829 regulator: twl: Remove references to the twl4030 regulator 029dd3ce regulator: twl: Remove another unused variable warning Yeah. 32k clock is not provided by twl. As I said I need to take a look at CCF to see if it already there. If it is clock driver + mapping + patch for wl12xx should fix the issue you are facing. Let me know if you need more info. BTW: have you happened to ubdate u-boot recently? There is a nice easter egg added there: f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls. Which means that _essential_ clocks and pads are no longer configured. anything essential you can list ? Yeah, that u-boot version is just unusable at all with any mainline kernel, since we are still missing pads conf for every drivers. Regarding the 32k clock, I noticed as well that the OMAP4460 panda u-boot is the only one to enable it at boot time, and thus this is the only board that can probe the wilink chip properly as of today. 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: 32kHz clock removal causes problems omap_hsmmc
Hi, On Wed, Dec 19, 2012 at 02:51:14PM +0100, Benoit Cousson wrote: On 12/19/2012 02:01 PM, Felipe Balbi wrote: Hi, +Sricharan who commited that On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote: On 12/19/2012 11:45 AM, Luciano Coelho wrote: Well, we still haven't got the foggiest idea what the actual problem is beyond that it's probably related to the 32kHz clock in some way (unless it was one of the other reverts that coincidentally made a difference, but we don't know what they were) so it's unlikely that just randomly implementing clock support is going to fix anything immediately here. This is exactly what I had to revert (as I mentioned in the other email, I had to revert the other patches otherwise compilation would break): 0e8e5c34 regulator: twl: Remove references to 32kHz clock from DT bindings e76ab829 regulator: twl: Remove references to the twl4030 regulator 029dd3ce regulator: twl: Remove another unused variable warning Yeah. 32k clock is not provided by twl. As I said I need to take a look at CCF to see if it already there. If it is clock driver + mapping + patch for wl12xx should fix the issue you are facing. Let me know if you need more info. BTW: have you happened to ubdate u-boot recently? There is a nice easter egg added there: f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls. Which means that _essential_ clocks and pads are no longer configured. anything essential you can list ? Yeah, that u-boot version is just unusable at all with any mainline kernel, since we are still missing pads conf for every drivers. Regarding the 32k clock, I noticed as well that the OMAP4460 panda u-boot is the only one to enable it at boot time, and thus this is the only board that can probe the wilink chip properly as of today. hah, way to cause regression -- balbi signature.asc Description: Digital signature
Re: 32kHz clock removal causes problems omap_hsmmc
On Wed, Dec 19, 2012 at 02:51:14PM +0100, Benoit Cousson wrote: Regarding the 32k clock, I noticed as well that the OMAP4460 panda u-boot is the only one to enable it at boot time, and thus this is the only board that can probe the wilink chip properly as of today. Well, there was nothing in the code that was disabled which would have turned on the 32kHz clock and no references to it in the standard kernel... signature.asc Description: Digital signature
Re: 32kHz clock removal causes problems omap_hsmmc
On Wed, 2012-12-19 at 14:51 +0100, Benoit Cousson wrote: On 12/19/2012 02:01 PM, Felipe Balbi wrote: On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote: BTW: have you happened to ubdate u-boot recently? There is a nice easter egg added there: f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls. Which means that _essential_ clocks and pads are no longer configured. anything essential you can list ? Yeah, that u-boot version is just unusable at all with any mainline kernel, since we are still missing pads conf for every drivers. Regarding the 32k clock, I noticed as well that the OMAP4460 panda u-boot is the only one to enable it at boot time, and thus this is the only board that can probe the wilink chip properly as of today. Do you mean that with the latest mainline u-boot all boards will have trouble except panda? I'm still reorganizing everything and update my stuff with the latest mainline u-boot, but at least blaze and panda now boot and recognize their wilink chips (with the patches I mentioned reverted). Now I'll try to remove my reverts and see what happens. -- Luca. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32kHz clock removal causes problems omap_hsmmc
On 12/19/2012 02:58 PM, Luciano Coelho wrote: On Wed, 2012-12-19 at 14:51 +0100, Benoit Cousson wrote: On 12/19/2012 02:01 PM, Felipe Balbi wrote: On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote: BTW: have you happened to ubdate u-boot recently? There is a nice easter egg added there: f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls. Which means that _essential_ clocks and pads are no longer configured. anything essential you can list ? Yeah, that u-boot version is just unusable at all with any mainline kernel, since we are still missing pads conf for every drivers. Regarding the 32k clock, I noticed as well that the OMAP4460 panda u-boot is the only one to enable it at boot time, and thus this is the only board that can probe the wilink chip properly as of today. Do you mean that with the latest mainline u-boot all boards will have trouble except panda? I don't know since the u-boot mainline has never ever supported properly the SDP4430, I stopped wasting my time with that code a long time ago. But the braves who tried using the latest u-boot mainline code that does not configure anything anymore had some troubles... 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: 32kHz clock removal causes problems omap_hsmmc
On 12/19/2012 02:01 PM, Felipe Balbi wrote: Hi, +Sricharan who commited that On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote: On 12/19/2012 11:45 AM, Luciano Coelho wrote: Well, we still haven't got the foggiest idea what the actual problem is beyond that it's probably related to the 32kHz clock in some way (unless it was one of the other reverts that coincidentally made a difference, but we don't know what they were) so it's unlikely that just randomly implementing clock support is going to fix anything immediately here. This is exactly what I had to revert (as I mentioned in the other email, I had to revert the other patches otherwise compilation would break): 0e8e5c34 regulator: twl: Remove references to 32kHz clock from DT bindings e76ab829 regulator: twl: Remove references to the twl4030 regulator 029dd3ce regulator: twl: Remove another unused variable warning Yeah. 32k clock is not provided by twl. As I said I need to take a look at CCF to see if it already there. If it is clock driver + mapping + patch for wl12xx should fix the issue you are facing. Let me know if you need more info. BTW: have you happened to ubdate u-boot recently? There is a nice easter egg added there: f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls. Which means that _essential_ clocks and pads are no longer configured. anything essential you can list ? Depends on the definition of essential. Serial and mmc works. I said it was an easter egg since it was... well... quite a bit of surprise that the same kernel started to fail for example in all audio operation when I updated the u-boot, which I tend to do every now and then to see if there are no regression. So it was a nice surprise. Even the commit message agreed that it is going to break the drivers: Note that this is going to break the kernel drivers. But this is the only way to get things fixed in the kernel. Usually if I know I will going to break something intentionally I tend to send warnings and give some grace periods for the interested guys to adopt. And this is why people are not testing u-boot. We tend to have one working binary moving from SD card to other and update it only, __only__ when it can not be avoided. If we work together, we should work together... Do not take it personal. I just had tough days... -- 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/2] ARM: OMAP2+: omap2plus_defconfig: enable TFP410 chip support
On 2012-12-19 14:33, Javier Martinez Canillas wrote: Many OMAP3 based boards such as Beagle, Overo and IGEP use the TFP410 DPI-to-DVI chip. So, it's good to have it built as a module by default on OMAP2+ config. Also on OMAP4 boards, like Panda. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- arch/arm/configs/omap2plus_defconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index a1dc5c0..da530a0 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -146,6 +146,7 @@ CONFIG_OMAP2_DSS_SDI=y CONFIG_OMAP2_DSS_DSI=y CONFIG_FB_OMAP2=m CONFIG_PANEL_GENERIC_DPI=m +CONFIG_PANEL_TFP410=m CONFIG_PANEL_SHARP_LS037V7DW01=m CONFIG_PANEL_NEC_NL8048HL11_01B=m CONFIG_PANEL_TAAL=m For both patches: Acked-by: Tomi Valkeinen tomi.valkei...@ti.com Tomi signature.asc Description: OpenPGP digital signature
Re: 32kHz clock removal causes problems omap_hsmmc
* Peter Ujfalusi peter.ujfal...@ti.com [121219 02:20]: On 12/19/2012 11:09 AM, Mark Brown wrote: On Wed, Dec 19, 2012 at 11:00:32AM +0100, Peter Ujfalusi wrote: I don't know the state of the common clock framework for OMAPs. Is it already up in 3.7? Or going for 3.8? 3.9? 3.10?... We need CCF to resolve this. I can cook up the clock driver for the 32k clock from twl, but in order to use it we need CCF on OMAP. Well, we at least ought to make sure it doesn't appear in the regulator DT bindings even if it's handled via some OMAP magic - that was the key point here. Sure. It must be a clock driver. I already have similar driver (for McPDM fclk clock) for twl6040. Let me check linux-next, if CCF is there for OMAP I can send the 32k clock driver soon (after writing it and testing it). It is going to be for 3.9 but we can roll it with us I think locally to resolv issues. The omap common clock patches are now in mainline kernel as of v3.8 merge window. 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 1/1] ARM: OMAP: Fix build breakage due to missing include in i2c.c
* Vaibhav Bedia vaibhav.be...@ti.com [121218 22:49]: Merge commit 752451f (Merge branch 'i2c-embedded/for-next' of git://git.pengutronix.de/git/wsa/linux) resulted in a build breakage for OMAP ... arch/arm/mach-omap2/i2c.c: In function 'omap_pm_set_max_mpu_wakeup_lat_compat': arch/arm/mach-omap2/i2c.c:130:2: error: implicit declaration of function 'omap_pm_set_max_mpu_wakeup_lat' make[1]: *** [arch/arm/mach-omap2/i2c.o] Error 1 ... Fix this by including the appropriate header file with the function prototype Thanks applying. Tony Reported-by: Fengguang Wu fengguang...@intel.com Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com --- arch/arm/mach-omap2/i2c.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/i2c.c b/arch/arm/mach-omap2/i2c.c index df6d6ac..b9074dd 100644 --- a/arch/arm/mach-omap2/i2c.c +++ b/arch/arm/mach-omap2/i2c.c @@ -22,6 +22,7 @@ #include soc.h #include omap_hwmod.h #include omap_device.h +#include omap-pm.h #include prm.h #include common.h -- 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: OMAP2+: Fix compillation error in mach-omap2/timer.c
* Bedia, Vaibhav vaibhav.be...@ti.com [121219 02:18]: Hi Peter, Tony On Wed, Dec 19, 2012 at 15:20:09, Ujfalusi, Peter wrote: prom_add_property() has been renamed to of_add_property() This patch fixes the following comilation error: arch/arm/mach-omap2/timer.c: In function ‘omap_get_timer_dt’: arch/arm/mach-omap2/timer.c:178:3: error: implicit declaration of function ‘prom_add_property’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[1]: *** [arch/arm/mach-omap2/timer.o] Error 1 make[1]: *** Waiting for unfinished jobs Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- Hi Tony, today's mainline does not compile due to this API rename in of core. Not sure if we alreasy have fix for this pending. Thanks applying. There following patches for needed to get omap2plus_defconfig build working https://patchwork.kernel.org/patch/1810481/ - address the build breakage due to header file cleanup https://patchwork.kernel.org/patch/1810441/ - address the prom_add_property() issue http://marc.info/?l=linux-arm-kernelm=135589966017628w=2 - this crept in during a merge commit. Thanks all these should be queued up somewhere now. 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: BUG: spinlock bad magic on CPU#0 on BeagleBone
On Wed, 19 Dec 2012, Bedia, Vaibhav wrote: Current mainline on Beaglebone using the omap2plus_defconfig + 3 build fixes is triggering a BUG() ... [0.109688] Security Framework initialized [0.109889] Mount-cache hash table entries: 512 [0.112674] BUG: spinlock bad magic on CPU#0, swapper/0/0 [0.112724] lock: atomic64_lock+0x240/0x400, .magic: , .owner: none/-1, .owner_cpu: 0 [0.112782] [c001af64] (unwind_backtrace+0x0/0xf0) from [c02c2010] (do_raw_spin_lock+0x158/0x198) [0.112813] [c02c2010] (do_raw_spin_lock+0x158/0x198) from [c04d89ec] (_raw_spin_lock_irqsave+0x4c/0x58) [0.112844] [c04d89ec] (_raw_spin_lock_irqsave+0x4c/0x58) from [c02cabf0] (atomic64_add_return+0x30/0x5c) [0.112886] [c02cabf0] (atomic64_add_return+0x30/0x5c) from [c0124564] (alloc_mnt_ns.clone.14+0x44/0xac) [0.112914] [c0124564] (alloc_mnt_ns.clone.14+0x44/0xac) from [c0124f4c] (create_mnt_ns+0xc/0x54) [0.112951] [c0124f4c] (create_mnt_ns+0xc/0x54) from [c06f31a4] (mnt_init+0x120/0x1d4) [0.112978] [c06f31a4] (mnt_init+0x120/0x1d4) from [c06f2d50] (vfs_caches_init+0xe0/0x10c) [0.113005] [c06f2d50] (vfs_caches_init+0xe0/0x10c) from [c06d4798] (start_kernel+0x29c/0x300) [0.113029] [c06d4798] (start_kernel+0x29c/0x300) from [80008078] (0x80008078) [0.118290] CPU: Testing write buffer coherency: ok [0.118968] CPU0: thread -1, cpu 0, socket -1, mpidr 0 [0.119053] Setting up static identity map for 0x804de2c8 - 0x804de338 [0.120698] Brought up 1 CPUs This is probably a memory corruption bug, there's probably some code executing early that's writing outside its own data and trashing some previously-allocated memory. - 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] ARM: OMAP4: PRM: Correct reset source map
On Wed, 19 Dec 2012, Ivan Khoronzhuk wrote: In the map for reset sources register we use defines intended for using with PRM_RSTCTRL register. So fix it. Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com Thanks, queued for v3.8-rc fixes. - 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] ARM: OMAP4: PRM: fix RSTTIME and RSTST offsets
On Wed, 19 Dec 2012, Ivan Khoronzhuk wrote: From: Nishanth Menon n...@ti.com RSTTIME is offset 0x8 and RSTST is offset 0x04 for OMAP4430 and OMAP4460. Signed-off-by: Nishanth Menon n...@ti.com [ivan.khoronz...@ti.com: ported from k3.4] Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com Thanks guys, queued for v3.8-rc fixes. - 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] ARM: OMAP4: PRM: Correct wrong instance usage for reading reset sources
On Wed, 19 Dec 2012, Ivan Khoronzhuk wrote: To read reset sources registers we have to use PRM_DEVICE_INST Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com Thanks, queued for v3.8-rc fixes. - 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 V6 2/2] dmaengine: add helper function to request a slave DMA channel
Hi Vinod, On 11/15/2012 07:37 PM, Vinod Koul wrote: On Fri, 2012-11-09 at 14:01 -0600, Jon Hunter wrote: Hi Vinod, A few people have been asking me if getting device-tree support for DMA engine is plan for record for v3.8. I know that you were working through implementing a common interface and so I wanted to check how that is going. Do you have any insight to when device-tree support may get added? I have not been able to do much work on this for last couple of weeks. I hope to do it in by this weekend. If not I will merge yours and then uppdate. Anyway, DT would be there in 3.8 with or without my changes. I am not sure if I have missed your pull request, but wanted to see if you had or were going to send a pull request for the DT changes for v3.8? I believe that the merge window ends this week. 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
[GIT PULL] two trivial omap build error fixes for v3.8 merge window
Hi Arnd Olof, Here's few more trivial build fixes caused by the merge conflicts. Tony The following changes since commit 5031a2a7c12b837a0913c4139ebeb6bbff5e1aa5: Merge tag 'for-v3.8-part2' of git://git.infradead.org/battery-2.6 (2012-12-19 08:14:08 -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-for-merge-window-part2-signed for you to fetch changes up to a702e279da5154d09a894bf9eac594845da3f390: ARM: OMAP: Fix build breakage due to missing include in i2c.c (2012-12-19 08:37:30 -0800) Looks like few more trivial merge errors caused by the multiplatform related header clean-up popped up. Peter Ujfalusi (1): ARM: OMAP2+: Fix compillation error in mach-omap2/timer.c Vaibhav Bedia (1): ARM: OMAP: Fix build breakage due to missing include in i2c.c arch/arm/mach-omap2/i2c.c | 1 + arch/arm/mach-omap2/timer.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line unsubscribe 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: 32kHz clock removal causes problems omap_hsmmc
Hi, On Wednesday 19 December 2012 07:34 PM, Benoit Cousson wrote: On 12/19/2012 02:58 PM, Luciano Coelho wrote: On Wed, 2012-12-19 at 14:51 +0100, Benoit Cousson wrote: On 12/19/2012 02:01 PM, Felipe Balbi wrote: On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote: BTW: have you happened to ubdate u-boot recently? There is a nice easter egg added there: f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls. Which means that _essential_ clocks and pads are no longer configured. anything essential you can list ? Yeah, that u-boot version is just unusable at all with any mainline kernel, since we are still missing pads conf for every drivers. Regarding the 32k clock, I noticed as well that the OMAP4460 panda u-boot is the only one to enable it at boot time, and thus this is the only board that can probe the wilink chip properly as of today. Do you mean that with the latest mainline u-boot all boards will have trouble except panda? I don't know since the u-boot mainline has never ever supported properly the SDP4430, I stopped wasting my time with that code a long time ago. But the braves who tried using the latest u-boot mainline code that does not configure anything anymore had some troubles... Configuring every pad and clocks in the u-boot was removed to force kernel drivers to fix up things. Dependency on boot loader was always a problem. Bootloader should not configure anything apart from what is required for boot. Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] Flip on multiplatform support for omap2plus for v3.9
Hi all, These patches enable multiplatform support for omap2plus. To build and boot it against the current mainline kernel you need the following: [PATCH 1/2] ARM: l2x0: Only set .set_debug on PL310 r3p0 and earlier [PATCH 2/2] ARM: disable errata work-arounds which access secure registers [GIT PULL 1/2] omap fixes for v3.8 merge window [GIT PULL 2/2] omap cleanup for v3.8 merge window [GIT PULL] two trivial omap build error fixes for v3.8 merge window cpts: Fix build error caused by include of plat/clock.h Regards, Tony --- Tony Lindgren (8): ARM: OMAP2+: Limi omap initcalls to omap only on multiplatform kernels ARM: OMAP2+: Use omap initcalls ARM: OMAP: Fix i2c cmdline initcall for multiplatform ARM: OMAP: Fix dmaengine init for multiplatform ARM: OMAP2+: Add multiplatform debug_ll support ARM: OMAP2+: Disable code that currently does not work with multiplaform ARM: OMAP2+: Enable ARCH_MULTIPLATFORM support ARM: OMAP2+: Add minimal support for booting vexpress arch/arm/Kconfig | 13 ++ arch/arm/Kconfig.debug | 56 + arch/arm/configs/omap2plus_defconfig |6 + arch/arm/include/debug/omap2plus.S | 190 ++ arch/arm/mach-omap1/dma.c| 18 +++ arch/arm/mach-omap1/i2c.c|6 + arch/arm/mach-omap2/Kconfig | 25 arch/arm/mach-omap2/Makefile |3 arch/arm/mach-omap2/board-omap3beagle.c |2 arch/arm/mach-omap2/board-rx51-video.c |3 arch/arm/mach-omap2/clock2xxx.c |2 arch/arm/mach-omap2/clock3xxx.c |2 arch/arm/mach-omap2/devices.c|6 - arch/arm/mach-omap2/dma.c| 23 +++- arch/arm/mach-omap2/drm.c|2 arch/arm/mach-omap2/emu.c|2 arch/arm/mach-omap2/fb.c |4 - arch/arm/mach-omap2/gpio.c |5 - arch/arm/mach-omap2/gpmc.c |4 - arch/arm/mach-omap2/hdq1w.c |3 arch/arm/mach-omap2/hwspinlock.c |2 arch/arm/mach-omap2/i2c.c|5 + arch/arm/mach-omap2/mcbsp.c |3 arch/arm/mach-omap2/omap-iommu.c |2 arch/arm/mach-omap2/omap2-restart.c |3 arch/arm/mach-omap2/omap4-common.c |4 - arch/arm/mach-omap2/omap_device.c|5 - arch/arm/mach-omap2/omap_hwmod.c |2 arch/arm/mach-omap2/omap_phy_internal.c |2 arch/arm/mach-omap2/opp3xxx_data.c |2 arch/arm/mach-omap2/opp4xxx_data.c |2 arch/arm/mach-omap2/pm-debug.c |2 arch/arm/mach-omap2/pm.c |2 arch/arm/mach-omap2/pmu.c|2 arch/arm/mach-omap2/prm3xxx.c|2 arch/arm/mach-omap2/prm44xx.c|2 arch/arm/mach-omap2/serial.c |2 arch/arm/mach-omap2/smartreflex-class3.c |2 arch/arm/mach-omap2/soc.h| 29 + arch/arm/mach-omap2/timer.c |2 arch/arm/mach-omap2/wd_timer.c |2 arch/arm/plat-omap/Kconfig | 30 - arch/arm/plat-omap/Makefile |2 arch/arm/plat-omap/i2c.c |3 arch/arm/plat-omap/include/plat/i2c.h|6 + drivers/crypto/omap-sham.c |3 drivers/dma/omap-dma.c | 20 --- drivers/media/rc/Kconfig |2 drivers/staging/tidspbridge/Kconfig |2 49 files changed, 422 insertions(+), 100 deletions(-) create mode 100644 arch/arm/include/debug/omap2plus.S -- Signature -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] ARM: OMAP2+: Limi omap initcalls to omap only on multiplatform kernels
We need to make sure that multiplatform kernels don't
run omap initcalls when booted on other SoCs.
Do this by adding wrapper macros for the initcalls that
return early if soc_is_omap() test fails. This allows
us to easily change the defines later if we have SoC
specific init sections available.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/soc.h | 29 +
1 file changed, 29 insertions(+)
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index f31d907..092aedd 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -42,6 +42,9 @@
#undef MULTI_OMAP2
#undef OMAP_NAME
+#ifdef CONFIG_ARCH_MULTIPLATFORM
+#define MULTI_OMAP2
+#endif
#ifdef CONFIG_SOC_OMAP2420
# ifdef OMAP_NAME
# undef MULTI_OMAP2
@@ -112,6 +115,11 @@ int omap_type(void);
*/
unsigned int omap_rev(void);
+static inline int soc_is_omap(void)
+{
+ return omap_rev() != 0;
+}
+
/*
* Get the CPU revision for OMAP devices
*/
@@ -465,5 +473,26 @@ static inline unsigned int omap4_has_ ##feat(void) \
OMAP4_HAS_FEATURE(perf_silicon, PERF_SILICON)
+/*
+ * We need to make sure omap initcalls don't run when
+ * multiplatform kernels are booted on other SoCs.
+ */
+#define omap_initcall(level, fn) \
+static int __init __used __##fn(void) \
+{ \
+ if (!soc_is_omap()) \
+ return 0; \
+ return fn();\
+} \
+level(__##fn);
+
+#define omap_early_initcall(fn)omap_initcall(early_initcall,
fn)
+#define omap_core_initcall(fn) omap_initcall(core_initcall, fn)
+#define omap_postcore_initcall(fn) omap_initcall(postcore_initcall, fn)
+#define omap_arch_initcall(fn) omap_initcall(arch_initcall, fn)
+#define omap_subsys_initcall(fn) omap_initcall(subsys_initcall, fn)
+#define omap_device_initcall(fn) omap_initcall(device_initcall, fn)
+#define omap_late_initcall(fn) omap_initcall(late_initcall, fn)
+
#endif /* __ASSEMBLY__ */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] ARM: OMAP2+: Use omap initcalls
This way the initcalls don't run on other SoCs on multiplatform
kernels. Otherwise we'll get something like this when booting
on vexpress:
omap_hwmod: _ensure_mpu_hwmod_is_setup: MPU initiator hwmod mpu not yet
registered
...
WARNING: at arch/arm/mach-omap2/pm.c:82 _init_omap_device+0x74/0x94()
_init_omap_device: could not find omap_hwmod for mpu
...
omap-dma-engine omap-dma-engine: OMAP DMA engine driver
...
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-omap3beagle.c |2 +-
arch/arm/mach-omap2/board-rx51-video.c |3 ++-
arch/arm/mach-omap2/clock2xxx.c |2 +-
arch/arm/mach-omap2/clock3xxx.c |2 +-
arch/arm/mach-omap2/devices.c|6 +++---
arch/arm/mach-omap2/dma.c|2 +-
arch/arm/mach-omap2/drm.c|2 +-
arch/arm/mach-omap2/emu.c|2 +-
arch/arm/mach-omap2/fb.c |4 ++--
arch/arm/mach-omap2/gpio.c |5 +++--
arch/arm/mach-omap2/gpmc.c |4 ++--
arch/arm/mach-omap2/hdq1w.c |3 ++-
arch/arm/mach-omap2/hwspinlock.c |2 +-
arch/arm/mach-omap2/mcbsp.c |3 ++-
arch/arm/mach-omap2/omap-iommu.c |2 +-
arch/arm/mach-omap2/omap2-restart.c |3 ++-
arch/arm/mach-omap2/omap4-common.c |4 ++--
arch/arm/mach-omap2/omap_device.c|5 +++--
arch/arm/mach-omap2/omap_hwmod.c |2 +-
arch/arm/mach-omap2/omap_phy_internal.c |2 +-
arch/arm/mach-omap2/opp3xxx_data.c |2 +-
arch/arm/mach-omap2/opp4xxx_data.c |2 +-
arch/arm/mach-omap2/pm-debug.c |2 +-
arch/arm/mach-omap2/pm.c |2 +-
arch/arm/mach-omap2/pmu.c|2 +-
arch/arm/mach-omap2/prm3xxx.c|2 +-
arch/arm/mach-omap2/prm44xx.c|2 +-
arch/arm/mach-omap2/serial.c |2 +-
arch/arm/mach-omap2/smartreflex-class3.c |2 +-
arch/arm/mach-omap2/timer.c |2 +-
arch/arm/mach-omap2/wd_timer.c |2 +-
31 files changed, 44 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 22c483d..5c68009 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -494,7 +494,7 @@ static int __init beagle_opp_init(void)
}
return 0;
}
-device_initcall(beagle_opp_init);
+omap_device_initcall(beagle_opp_init);
static void __init omap3_beagle_init(void)
{
diff --git a/arch/arm/mach-omap2/board-rx51-video.c
b/arch/arm/mach-omap2/board-rx51-video.c
index 46f4fc9..eb66726 100644
--- a/arch/arm/mach-omap2/board-rx51-video.c
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -18,6 +18,7 @@
#include video/omapdss.h
#include linux/platform_data/spi-omap2-mcspi.h
+#include soc.h
#include board-rx51.h
#include mux.h
@@ -85,5 +86,5 @@ static int __init rx51_video_init(void)
return 0;
}
-subsys_initcall(rx51_video_init);
+omap_subsys_initcall(rx51_video_init);
#endif /* defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE) */
diff --git a/arch/arm/mach-omap2/clock2xxx.c b/arch/arm/mach-omap2/clock2xxx.c
index 1ff6469..b870f6a 100644
--- a/arch/arm/mach-omap2/clock2xxx.c
+++ b/arch/arm/mach-omap2/clock2xxx.c
@@ -52,6 +52,6 @@ static int __init omap2xxx_clk_arch_init(void)
return ret;
}
-arch_initcall(omap2xxx_clk_arch_init);
+omap_arch_initcall(omap2xxx_clk_arch_init);
diff --git a/arch/arm/mach-omap2/clock3xxx.c b/arch/arm/mach-omap2/clock3xxx.c
index 4eacab8..0b02b41 100644
--- a/arch/arm/mach-omap2/clock3xxx.c
+++ b/arch/arm/mach-omap2/clock3xxx.c
@@ -94,6 +94,6 @@ static int __init omap3xxx_clk_arch_init(void)
return ret;
}
-arch_initcall(omap3xxx_clk_arch_init);
+omap_arch_initcall(omap3xxx_clk_arch_init);
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 4abb8b5..8b142da 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -68,7 +68,7 @@ static int __init omap3_l3_init(void)
return IS_ERR(pdev) ? PTR_ERR(pdev) : 0;
}
-postcore_initcall(omap3_l3_init);
+omap_postcore_initcall(omap3_l3_init);
static int __init omap4_l3_init(void)
{
@@ -103,7 +103,7 @@ static int __init omap4_l3_init(void)
return IS_ERR(pdev) ? PTR_ERR(pdev) : 0;
}
-postcore_initcall(omap4_l3_init);
+omap_postcore_initcall(omap4_l3_init);
#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
@@ -734,4 +734,4 @@ static int __init omap2_init_devices(void)
return 0;
}
-arch_initcall(omap2_init_devices);
+omap_arch_initcall(omap2_init_devices);
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index 612b982..e034ab6 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -293,4 +293,4 @@ static int __init omap2_system_dma_init(void)
return
[PATCH 3/8] ARM: OMAP: Fix i2c cmdline initcall for multiplatform
We only want this initcall to run when the kernel is
booted on omap SoCs. Fix the issue by initializing the
the initcall from separately for omap1 and omap2+.
This fixes the issue for omap2+ multiplatform configs
as we are using omap_subsys_initcall there.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/i2c.c |6 ++
arch/arm/mach-omap2/i2c.c |5 +
arch/arm/plat-omap/i2c.c |3 +--
arch/arm/plat-omap/include/plat/i2c.h |6 ++
4 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap1/i2c.c b/arch/arm/mach-omap1/i2c.c
index faca808..7f5761c 100644
--- a/arch/arm/mach-omap1/i2c.c
+++ b/arch/arm/mach-omap1/i2c.c
@@ -91,3 +91,9 @@ int __init omap_i2c_add_bus(struct omap_i2c_bus_platform_data
*pdata,
return platform_device_register(pdev);
}
+
+static int __init omap_i2c_cmdline(void)
+{
+ return omap_register_i2c_bus_cmdline();
+}
+subsys_initcall(omap_i2c_cmdline);
diff --git a/arch/arm/mach-omap2/i2c.c b/arch/arm/mach-omap2/i2c.c
index fbb9b15..9eb146f 100644
--- a/arch/arm/mach-omap2/i2c.c
+++ b/arch/arm/mach-omap2/i2c.c
@@ -165,3 +165,8 @@ int __init omap_i2c_add_bus(struct
omap_i2c_bus_platform_data *i2c_pdata,
return PTR_RET(pdev);
}
+static int __init omap_i2c_cmdline(void)
+{
+ return omap_register_i2c_bus_cmdline();
+}
+omap_subsys_initcall(omap_i2c_cmdline);
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index f9df624..58213d9 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -68,7 +68,7 @@ __setup(i2c_bus=, omap_i2c_bus_setup);
* Register busses defined in command line but that are not registered with
* omap_register_i2c_bus from board initialization code.
*/
-static int __init omap_register_i2c_bus_cmdline(void)
+int __init omap_register_i2c_bus_cmdline(void)
{
int i, err = 0;
@@ -83,7 +83,6 @@ static int __init omap_register_i2c_bus_cmdline(void)
out:
return err;
}
-subsys_initcall(omap_register_i2c_bus_cmdline);
/**
* omap_register_i2c_bus - register I2C bus with device descriptors
diff --git a/arch/arm/plat-omap/include/plat/i2c.h
b/arch/arm/plat-omap/include/plat/i2c.h
index 7a9028c..810629d 100644
--- a/arch/arm/plat-omap/include/plat/i2c.h
+++ b/arch/arm/plat-omap/include/plat/i2c.h
@@ -32,6 +32,7 @@ int omap_i2c_add_bus(struct omap_i2c_bus_platform_data
*i2c_pdata,
extern int omap_register_i2c_bus(int bus_id, u32 clkrate,
struct i2c_board_info const *info,
unsigned len);
+extern int omap_register_i2c_bus_cmdline(void);
#else
static inline int omap_register_i2c_bus(int bus_id, u32 clkrate,
struct i2c_board_info const *info,
@@ -39,6 +40,11 @@ static inline int omap_register_i2c_bus(int bus_id, u32
clkrate,
{
return 0;
}
+
+static inline int omap_register_i2c_bus_cmdline(void)
+{
+ return 0;
+}
#endif
struct omap_hwmod;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] ARM: OMAP: Fix dmaengine init for multiplatform
Otherwise omap dmaengine will initialized when booted
on other SoCs. Fix this by initializing the platform
device in arch/arm/*omap*/dma.c instead.
Cc: Russell King li...@arm.linux.org.uk
Cc: Dan Williams d...@fb.com
Cc: Vinod Koul vinod.k...@intel.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/dma.c | 18 --
arch/arm/mach-omap2/dma.c | 21 +++--
drivers/dma/omap-dma.c| 20 +---
3 files changed, 36 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
index e190611..1a4e887 100644
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -24,7 +24,7 @@
#include linux/init.h
#include linux/device.h
#include linux/io.h
-
+#include linux/dma-mapping.h
#include linux/omap-dma.h
#include mach/tc.h
@@ -270,11 +270,17 @@ static u32 configure_dma_errata(void)
return errata;
}
+static const struct platform_device_info omap_dma_dev_info = {
+ .name = omap-dma-engine,
+ .id = -1,
+ .dma_mask = DMA_BIT_MASK(32),
+};
+
static int __init omap1_system_dma_init(void)
{
struct omap_system_dma_plat_info*p;
struct omap_dma_dev_attr*d;
- struct platform_device *pdev;
+ struct platform_device *pdev, *dma_pdev;
int ret;
pdev = platform_device_alloc(omap_dma_system, 0);
@@ -380,8 +386,16 @@ static int __init omap1_system_dma_init(void)
dma_common_ch_start = CPC;
dma_common_ch_end = COLOR;
+ dma_pdev = platform_device_register_full(omap_dma_dev_info);
+ if (IS_ERR(dma_pdev)) {
+ ret = PTR_ERR(dma_pdev);
+ goto exit_release_pdev;
+ }
+
return ret;
+exit_release_pdev:
+ platform_device_del(pdev);
exit_release_chan:
kfree(d-chan);
exit_release_d:
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index e034ab6..5cd8d76 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -27,7 +27,7 @@
#include linux/module.h
#include linux/init.h
#include linux/device.h
-
+#include linux/dma-mapping.h
#include linux/omap-dma.h
#include soc.h
@@ -288,9 +288,26 @@ static int __init omap2_system_dma_init_dev(struct
omap_hwmod *oh, void *unused)
return 0;
}
+static const struct platform_device_info omap_dma_dev_info = {
+ .name = omap-dma-engine,
+ .id = -1,
+ .dma_mask = DMA_BIT_MASK(32),
+};
+
static int __init omap2_system_dma_init(void)
{
- return omap_hwmod_for_each_by_class(dma,
+ struct platform_device *pdev;
+ int res;
+
+ res = omap_hwmod_for_each_by_class(dma,
omap2_system_dma_init_dev, NULL);
+ if (res)
+ return res;
+
+ pdev = platform_device_register_full(omap_dma_dev_info);
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ return res;
}
omap_arch_initcall(omap2_system_dma_init);
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 5a31264..c4b4fd2 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -661,32 +661,14 @@ bool omap_dma_filter_fn(struct dma_chan *chan, void
*param)
}
EXPORT_SYMBOL_GPL(omap_dma_filter_fn);
-static struct platform_device *pdev;
-
-static const struct platform_device_info omap_dma_dev_info = {
- .name = omap-dma-engine,
- .id = -1,
- .dma_mask = DMA_BIT_MASK(32),
-};
-
static int omap_dma_init(void)
{
- int rc = platform_driver_register(omap_dma_driver);
-
- if (rc == 0) {
- pdev = platform_device_register_full(omap_dma_dev_info);
- if (IS_ERR(pdev)) {
- platform_driver_unregister(omap_dma_driver);
- rc = PTR_ERR(pdev);
- }
- }
- return rc;
+ return platform_driver_register(omap_dma_driver);
}
subsys_initcall(omap_dma_init);
static void __exit omap_dma_exit(void)
{
- platform_device_unregister(pdev);
platform_driver_unregister(omap_dma_driver);
}
module_exit(omap_dma_exit);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] ARM: OMAP2+: Add multiplatform debug_ll support
Add multiplatform debug_ll support by stripping away the custom hacks to detect the port from debug-macro.S. Note that this now requires the specific debug_ll port to be selected in the .config. The old debug-macro.S will be removed a bit later once we are sure things work properly with multiplatform enabled. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/Kconfig.debug | 56 +++ arch/arm/include/debug/omap2plus.S | 190 2 files changed, 246 insertions(+) create mode 100644 arch/arm/include/debug/omap2plus.S diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 661030d..8e3 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -291,6 +291,13 @@ choice Say Y here if you want kernel low-level debugging support on MVEBU based platforms. + config DEBUG_OMAP2PLUS_UART + bool Kernel low-level debugging messages via OMAP2PLUS UART + depends on ARCH_OMAP2PLUS + help + Say Y here if you want kernel low-level debugging support + on OMAP2PLUS based platforms. + config DEBUG_PICOXCELL_UART depends on ARCH_PICOXCELL bool Use PicoXcell UART for low-level debug @@ -461,6 +468,54 @@ config DEBUG_IMX6Q_UART_PORT choice prompt Low-level debug console UART + depends on DEBUG_OMAP2PLUS_UART + + config DEBUG_OMAP2UART1 + bool OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 boards) + help + This covers at least h4, 2430sdp, 3430sdp, 3630sdp, + omap3 torpedo and 3530 lv som. + + config DEBUG_OMAP2UART2 + bool OMAP2/3/4 UART2 + + config DEBUG_OMAP2UART3 + bool OMAP2 UART3 (n8x0) + + config DEBUG_OMAP3UART3 + bool OMAP3 UART3 (most omap3 boards) + help + This covers at least cm_t3x, beagle, crane, devkit8000, + igep00x0, ldp, n900, n9(50), pandora, overo, touchbook, + and 3517evm. + + config DEBUG_OMAP4UART3 + bool OMAP4/5 UART3 (omap4 blaze, panda, omap5 sevm) + + config DEBUG_OMAP3UART4 + bool OMAP36XX UART4 + + config DEBUG_OMAP4UART4 + bool OMAP4/5 UART4 + + config DEBUG_TI81XXUART1 + bool TI81XX UART1 (ti8148evm) + + config DEBUG_TI81XXUART2 + bool TI81XX UART2 + + config DEBUG_TI81XXUART3 + bool TI81XX UART3 (ti8168evm) + + config DEBUG_AM33XXUART1 + bool AM33XX UART1 + + config DEBUG_ZOOM_UART + bool Zoom2/3 UART +endchoice + +choice + prompt Low-level debug console UART depends on DEBUG_LL DEBUG_TEGRA_UART config TEGRA_DEBUG_UART_AUTO_ODMDATA @@ -501,6 +556,7 @@ config DEBUG_LL_INCLUDE DEBUG_IMX6Q_UART default debug/highbank.S if DEBUG_HIGHBANK_UART default debug/mvebu.S if DEBUG_MVEBU_UART + default debug/omap2plus.S if DEBUG_OMAP2PLUS_UART default debug/picoxcell.S if DEBUG_PICOXCELL_UART default debug/socfpga.S if DEBUG_SOCFPGA_UART default debug/sunxi.S if DEBUG_SUNXI_UART0 || DEBUG_SUNXI_UART1 diff --git a/arch/arm/include/debug/omap2plus.S b/arch/arm/include/debug/omap2plus.S new file mode 100644 index 000..6d867ae --- /dev/null +++ b/arch/arm/include/debug/omap2plus.S @@ -0,0 +1,190 @@ +/* + * Debugging macro include header + * + * Copyright (C) 1994-1999 Russell King + * Moved from linux/arch/arm/kernel/debug.S by Ben Dooks + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * +*/ + +#include linux/serial_reg.h + +/* OMAP2 serial ports */ +#define OMAP2_UART1_BASE 0x4806a000 +#define OMAP2_UART2_BASE 0x4806c000 +#define OMAP2_UART3_BASE 0x4806e000 + +/* OMAP3 serial ports */ +#define OMAP3_UART1_BASE OMAP2_UART1_BASE +#define OMAP3_UART2_BASE OMAP2_UART2_BASE +#define OMAP3_UART3_BASE 0x4902 +#define OMAP3_UART4_BASE 0x49042000 /* Only on 36xx */ +#define OMAP3_UART4_AM35XX_BASE0x4809E000 /* Only on AM35xx */ + +/* OMAP4 serial ports */ +#define OMAP4_UART1_BASE OMAP2_UART1_BASE +#define OMAP4_UART2_BASE OMAP2_UART2_BASE +#define OMAP4_UART3_BASE 0x4802 +#define OMAP4_UART4_BASE 0x4806e000 + +/* TI81XX serial ports */ +#define TI81XX_UART1_BASE 0x4802 +#define TI81XX_UART2_BASE 0x48022000 +#define TI81XX_UART3_BASE 0x48024000 + +/* AM3505/3517 UART4 */ +#define AM35XX_UART4_BASE 0x4809E000 /* Only on AM3505/3517 */ + +/* AM33XX serial port */ +#define AM33XX_UART1_BASE 0x44E09000 + +/* OMAP5 serial ports */ +#define
[PATCH 7/8] ARM: OMAP2+: Enable ARCH_MULTIPLATFORM support
Flip on multiplatform support for omap2+. No changes to omap2plus_defconfig needed, but please note that you may need to update your custom config files to make sure you have: CONFIG_ARCH_MULTIPLATFORM=y CONFIG_ARCH_MULTI_V7=y CONFIG_ARCH_OMAP2PLUS=y And may need CONFIG_ARCH_MULTI_V6=y if booting omap2 boards. Cc: Russell King li...@arm.linux.org.uk Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/Kconfig | 13 ++--- arch/arm/configs/omap2plus_defconfig |2 +- arch/arm/mach-omap2/Kconfig | 23 +++ arch/arm/mach-omap2/Makefile |3 +++ arch/arm/plat-omap/Kconfig | 30 -- arch/arm/plat-omap/Makefile |2 ++ 6 files changed, 39 insertions(+), 34 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index ae97414..93b6acd 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -940,17 +940,24 @@ config ARCH_DAVINCI help Support for TI's DaVinci platform. -config ARCH_OMAP - bool TI OMAP +config ARCH_OMAP1 + bool TI OMAP1 depends on MMU select ARCH_HAS_CPUFREQ select ARCH_HAS_HOLES_MEMORYMODEL + select ARCH_OMAP select ARCH_REQUIRE_GPIOLIB + select CLKDEV_LOOKUP select CLKSRC_MMIO select GENERIC_CLOCKEVENTS + select GENERIC_IRQ_CHIP select HAVE_CLK + select HAVE_IDE + select IRQ_DOMAIN + select NEED_MACH_IO_H if PCCARD + select NEED_MACH_MEMORY_H help - Support for TI's OMAP platform (OMAP1/2/3/4). + Support for older TI OMAP1 (omap7xx, omap15xx or omap16xx) config ARCH_VT8500_SINGLE bool VIA/WonderMedia 85xx diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 82ce8d7..db05745 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -20,7 +20,7 @@ CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y # CONFIG_BLK_DEV_BSG is not set -CONFIG_ARCH_OMAP=y +CONFIG_ARCH_OMAP2PLUS=y CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_MUX_DEBUG=y CONFIG_ARM_THUMBEE=y diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 492d764..c3c033f 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -1,3 +1,26 @@ +config ARCH_OMAP + bool + +config ARCH_OMAP2PLUS + bool TI OMAP2/3/4/5 SoCs with device tree support if (ARCH_MULTI_V6 || ARCH_MULTI_V7) + select ARCH_HAS_CPUFREQ + select ARCH_HAS_HOLES_MEMORYMODEL + select ARCH_OMAP + select ARCH_REQUIRE_GPIOLIB + select CLKDEV_LOOKUP + select CLKSRC_MMIO + select GENERIC_CLOCKEVENTS + select GENERIC_IRQ_CHIP + select HAVE_CLK + select OMAP_DM_TIMER + select PINCTRL + select PROC_DEVICETREE if PROC_FS + select SPARSE_IRQ + select USE_OF + help + Systems based on OMAP2, OMAP3, OMAP4 or OMAP5 + + if ARCH_OMAP2PLUS menu TI OMAP2/3/4 Specific Features diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 947cafe..65fb6fb 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -2,6 +2,9 @@ # Makefile for the linux kernel. # +ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \ + -I$(srctree)/arch/arm/plat-omap/include + # Common support obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o gpmc.o timer.o pm.o \ common.o gpio.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o \ diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index 665870d..886af14 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -5,36 +5,6 @@ menu TI OMAP Common Features config ARCH_OMAP_OTG bool -choice - prompt OMAP System Type - default ARCH_OMAP2PLUS - -config ARCH_OMAP1 - bool TI OMAP1 - select CLKDEV_LOOKUP - select CLKSRC_MMIO - select GENERIC_IRQ_CHIP - select HAVE_IDE - select IRQ_DOMAIN - select NEED_MACH_IO_H if PCCARD - select NEED_MACH_MEMORY_H - help - Systems based on omap7xx, omap15xx or omap16xx - -config ARCH_OMAP2PLUS - bool TI OMAP2/3/4 - select CLKDEV_LOOKUP - select GENERIC_IRQ_CHIP - select OMAP_DM_TIMER - select PINCTRL - select PROC_DEVICETREE if PROC_FS - select SPARSE_IRQ - select USE_OF - help - Systems based on OMAP2, OMAP3, OMAP4 or OMAP5 - -endchoice - comment OMAP Feature Selections config OMAP_DEBUG_DEVICES diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index a14a78a..3119941 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -2,6 +2,8 @@ # Makefile for the linux kernel. # +ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/arch/arm/plat-omap/include + # Common support
[PATCH 6/8] ARM: OMAP2+: Disable code that currently does not work with multiplaform
We still need to fix up few places for multiplatform support, but that can proceed separately. Fix the issue by making the problem drivers depends !ARCH_MULTIPLATFORM for now. The remaining pieces that are not multiplatform compatible for omap2+ SoCs are: 1. Some drivers are using custom omap_dm_timer calls There are two drivers that are directly usign omap hardware timers for PWM and DSP clocking: drivers/media/rc/ir-rx51.c and drivers/staging/tidspbridge/core/dsp-clock.c. These can be fixed for multiplatform by allowing a minimal set of hardware timers to be accessed, and for some functionality by using the hrtimer framework. 2. Hardware OMAP4_ERRATA_I688 needs to be fixed up This can't be enabled for multiplatform configurations in it's current form. It may be possible to fix it up to do instruction replacement early on during init. Luckily it looks like this errata does not seem to get hit with mainline kernel code alone at least currently. 3. Legacy header needed for omap-sham.c Looks like it still needs mach/irqs.h for omap1 that does not exist for multiplatform systems. Just ifdef it for now. Cc: Timo Kokkonen timo.t.kokko...@iki.fi Cc: Sean Young s...@mess.org Cc: Víctor Manuel Jáquez Leal vjaq...@igalia.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: Omar Ramirez Luna omar.rami...@ti.com Cc: Herbert Xu herb...@gondor.apana.org.au Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Kconfig |2 +- drivers/crypto/omap-sham.c |3 +++ drivers/media/rc/Kconfig|2 +- drivers/staging/tidspbridge/Kconfig |2 +- 4 files changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 41b581f..492d764 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -397,7 +397,7 @@ config OMAP3_SDRC_AC_TIMING config OMAP4_ERRATA_I688 bool OMAP4 errata: Async Bridge Corruption - depends on ARCH_OMAP4 + depends on ARCH_OMAP4 !ARCH_MULTIPLATFORM select ARCH_HAS_BARRIERS help If a data is stalled inside asynchronous bridge because of back diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c index 1d75e6f..d65f22c 100644 --- a/drivers/crypto/omap-sham.c +++ b/drivers/crypto/omap-sham.c @@ -38,7 +38,10 @@ #include crypto/internal/hash.h #include linux/omap-dma.h + +#ifdef CONFIG_ARCH_OMAP1 #include mach/irqs.h +#endif #define SHA_REG_DIGEST(x) (0x00 + ((x) * 0x04)) #define SHA_REG_DIN(x) (0x1C + ((x) * 0x04)) diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig index 79ba242..19f3563 100644 --- a/drivers/media/rc/Kconfig +++ b/drivers/media/rc/Kconfig @@ -291,7 +291,7 @@ config IR_TTUSBIR config IR_RX51 tristate Nokia N900 IR transmitter diode - depends on OMAP_DM_TIMER LIRC + depends on OMAP_DM_TIMER LIRC !ARCH_MULTIPLATFORM ---help--- Say Y or M here if you want to enable support for the IR transmitter diode built in the Nokia N900 (RX51) device. diff --git a/drivers/staging/tidspbridge/Kconfig b/drivers/staging/tidspbridge/Kconfig index 0dd479f..60848f1 100644 --- a/drivers/staging/tidspbridge/Kconfig +++ b/drivers/staging/tidspbridge/Kconfig @@ -4,7 +4,7 @@ menuconfig TIDSPBRIDGE tristate DSP Bridge driver - depends on ARCH_OMAP3 + depends on ARCH_OMAP3 !ARCH_MULTIPLATFORM select OMAP_MBOX_FWK help DSP/BIOS Bridge is designed for platforms that contain a GPP and -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] ARM: OMAP2+: Add minimal support for booting vexpress
With multiplatform support enabled we are now always building in vexpress. Let's enable few drivers also as this allows us to boot omap2plus zImage in qemu for testing multiplaform related changes. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/configs/omap2plus_defconfig |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index db05745..5be2e4b 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -23,6 +23,7 @@ CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_ARCH_OMAP2PLUS=y CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_MUX_DEBUG=y +CONFIG_ARCH_VEXPRESS_CA9X4=y CONFIG_ARM_THUMBEE=y CONFIG_ARM_ERRATA_411920=y CONFIG_NO_HZ=y @@ -121,6 +122,8 @@ CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_RSA=y +CONFIG_SERIAL_AMBA_PL011=y +CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_HW_RANDOM=y CONFIG_I2C_CHARDEV=y CONFIG_SPI=y @@ -194,6 +197,7 @@ CONFIG_USB_ZERO=m CONFIG_MMC=y CONFIG_MMC_UNSAFE_RESUME=y CONFIG_SDIO_UART=y +CONFIG_MMC_ARMMMCI=y CONFIG_MMC_OMAP=y CONFIG_MMC_OMAP_HS=y CONFIG_RTC_CLASS=y -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: spinlock bad magic on CPU#0 on BeagleBone
On 12/19/12 08:53, Paul Walmsley wrote:
On Wed, 19 Dec 2012, Bedia, Vaibhav wrote:
Current mainline on Beaglebone using the omap2plus_defconfig + 3 build fixes
is triggering a BUG()
...
[0.109688] Security Framework initialized
[0.109889] Mount-cache hash table entries: 512
[0.112674] BUG: spinlock bad magic on CPU#0, swapper/0/0
[0.112724] lock: atomic64_lock+0x240/0x400, .magic: , .owner:
none/-1, .owner_cpu: 0
[0.112782] [c001af64] (unwind_backtrace+0x0/0xf0) from [c02c2010]
(do_raw_spin_lock+0x158/0x198)
[0.112813] [c02c2010] (do_raw_spin_lock+0x158/0x198) from [c04d89ec]
(_raw_spin_lock_irqsave+0x4c/0x58)
[0.112844] [c04d89ec] (_raw_spin_lock_irqsave+0x4c/0x58) from
[c02cabf0] (atomic64_add_return+0x30/0x5c)
[0.112886] [c02cabf0] (atomic64_add_return+0x30/0x5c) from
[c0124564] (alloc_mnt_ns.clone.14+0x44/0xac)
[0.112914] [c0124564] (alloc_mnt_ns.clone.14+0x44/0xac) from
[c0124f4c] (create_mnt_ns+0xc/0x54)
[0.112951] [c0124f4c] (create_mnt_ns+0xc/0x54) from [c06f31a4]
(mnt_init+0x120/0x1d4)
[0.112978] [c06f31a4] (mnt_init+0x120/0x1d4) from [c06f2d50]
(vfs_caches_init+0xe0/0x10c)
[0.113005] [c06f2d50] (vfs_caches_init+0xe0/0x10c) from [c06d4798]
(start_kernel+0x29c/0x300)
[0.113029] [c06d4798] (start_kernel+0x29c/0x300) from [80008078]
(0x80008078)
[0.118290] CPU: Testing write buffer coherency: ok
[0.118968] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[0.119053] Setting up static identity map for 0x804de2c8 - 0x804de338
[0.120698] Brought up 1 CPUs
This is probably a memory corruption bug, there's probably some code
executing early that's writing outside its own data and trashing some
previously-allocated memory.
I'm not so sure. It looks like atomic64s use spinlocks on processors
that don't have 64-bit atomic instructions (see lib/atomic64.c). And
those spinlocks are not initialized until a pure initcall runs,
init_atomic64_lock(). Pure initcalls don't run until after
vfs_caches_init() and so you get this BUG() warning that the spinlock is
not initialized.
How about we initialize the locks statically? Does that fix your problem?
8-
diff --git a/lib/atomic64.c b/lib/atomic64.c
index 9785378..08a4f06 100644
--- a/lib/atomic64.c
+++ b/lib/atomic64.c
@@ -31,7 +31,11 @@
static union {
raw_spinlock_t lock;
char pad[L1_CACHE_BYTES];
-} atomic64_lock[NR_LOCKS] __cacheline_aligned_in_smp;
+} atomic64_lock[NR_LOCKS] __cacheline_aligned_in_smp = {
+ [0 ... (NR_LOCKS - 1)] = {
+ .lock = __RAW_SPIN_LOCK_UNLOCKED(atomic64_lock.lock),
+ },
+};
static inline raw_spinlock_t *lock_addr(const atomic64_t *v)
{
@@ -173,14 +177,3 @@ int atomic64_add_unless(atomic64_t *v, long long a, long
long u)
return ret;
}
EXPORT_SYMBOL(atomic64_add_unless);
-
-static int init_atomic64_lock(void)
-{
- int i;
-
- for (i = 0; i NR_LOCKS; ++i)
- raw_spin_lock_init(atomic64_lock[i].lock);
- return 0;
-}
-
-pure_initcall(init_atomic64_lock);
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] gpio: twl4030: Cache the direction and output states in private data
On Thu, 6 Dec 2012 11:52:06 +0100, Peter Ujfalusi peter.ujfal...@ti.com wrote:
Use more coherent locking in the driver. Use bitfield to store the GPIO
direction and if the pin is configured as output store the status also in a
bitfiled.
In this way we can just look at these bitfields when we need information
about the pin status and only reach out to the chip when it is needed.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Applied, thanks
g.
---
drivers/gpio/gpio-twl4030.c | 99
++---
1 file changed, 66 insertions(+), 33 deletions(-)
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index c092739..a38e6e9c 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -64,14 +64,15 @@
/* Mask for GPIO registers when aggregated into a 32-bit integer */
#define GPIO_32_MASK 0x0003
-/* Data structures */
-static DEFINE_MUTEX(gpio_lock);
-
struct gpio_twl4030_priv {
struct gpio_chip gpio_chip;
+ struct mutex mutex;
int irq_base;
+ /* Bitfields for state caching */
unsigned int usage_count;
+ unsigned int direction;
+ unsigned int out_state;
};
/*--*/
@@ -130,7 +131,7 @@ static inline int gpio_twl4030_read(u8 address)
/*--*/
-static u8 cached_leden; /* protected by gpio_lock */
+static u8 cached_leden;
/* The LED lines are open drain outputs ... a FET pulls to GND, so an
* external pullup is needed. We could also expose the integrated PWM
@@ -144,14 +145,12 @@ static void twl4030_led_set_value(int led, int value)
if (led)
mask = 1;
- mutex_lock(gpio_lock);
if (value)
cached_leden = ~mask;
else
cached_leden |= mask;
status = twl_i2c_write_u8(TWL4030_MODULE_LED, cached_leden,
TWL4030_LED_LEDEN_REG);
- mutex_unlock(gpio_lock);
}
static int twl4030_set_gpio_direction(int gpio, int is_input)
@@ -162,7 +161,6 @@ static int twl4030_set_gpio_direction(int gpio, int
is_input)
u8 base = REG_GPIODATADIR1 + d_bnk;
int ret = 0;
- mutex_lock(gpio_lock);
ret = gpio_twl4030_read(base);
if (ret = 0) {
if (is_input)
@@ -172,7 +170,6 @@ static int twl4030_set_gpio_direction(int gpio, int
is_input)
ret = gpio_twl4030_write(base, reg);
}
- mutex_unlock(gpio_lock);
return ret;
}
@@ -212,7 +209,7 @@ static int twl_request(struct gpio_chip *chip, unsigned
offset)
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
int status = 0;
- mutex_lock(gpio_lock);
+ mutex_lock(priv-mutex);
/* Support the two LED outputs as output-only GPIOs. */
if (offset = TWL4030_GPIO_MAX) {
@@ -271,7 +268,7 @@ done:
if (!status)
priv-usage_count |= BIT(offset);
- mutex_unlock(gpio_lock);
+ mutex_unlock(priv-mutex);
return status;
}
@@ -279,64 +276,98 @@ static void twl_free(struct gpio_chip *chip, unsigned
offset)
{
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
+ mutex_lock(priv-mutex);
if (offset = TWL4030_GPIO_MAX) {
twl4030_led_set_value(offset - TWL4030_GPIO_MAX, 1);
return;
}
- mutex_lock(gpio_lock);
-
priv-usage_count = ~BIT(offset);
/* on last use, switch off GPIO module */
if (!priv-usage_count)
gpio_twl4030_write(REG_GPIO_CTRL, 0x0);
- mutex_unlock(gpio_lock);
+ mutex_unlock(priv-mutex);
}
static int twl_direction_in(struct gpio_chip *chip, unsigned offset)
{
- return (offset TWL4030_GPIO_MAX)
- ? twl4030_set_gpio_direction(offset, 1)
- : -EINVAL;
+ struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
+ int ret;
+
+ mutex_lock(priv-mutex);
+ if (offset TWL4030_GPIO_MAX)
+ ret = twl4030_set_gpio_direction(offset, 1);
+ else
+ ret = -EINVAL;
+
+ if (!ret)
+ priv-direction = ~BIT(offset);
+
+ mutex_unlock(priv-mutex);
+
+ return ret;
}
static int twl_get(struct gpio_chip *chip, unsigned offset)
{
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
+ int ret;
int status = 0;
- if (!(priv-usage_count BIT(offset)))
- return -EPERM;
+ mutex_lock(priv-mutex);
+ if (!(priv-usage_count BIT(offset))) {
+ ret = -EPERM;
+ goto out;
+ }
- if (offset TWL4030_GPIO_MAX)
- status = twl4030_get_gpio_datain(offset);
- else if (offset == TWL4030_GPIO_MAX)
- status = cached_leden LEDEN_LEDAON;
+ if
Re: [PATCH v2 3/3] gpio: twl4030: TODO comment to remove the PWMA/B (LEDA/B) handling
On Thu, 6 Dec 2012 11:52:07 +0100, Peter Ujfalusi peter.ujfal...@ti.com wrote: This GPIO driver should not configure anything else then GPIOs. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com I'm not sure if this is the right direction. I actually have no problem with a single driver that registers itself with multiple interfaces (ie. GPIO and PWM) if it makes sense for it to do so. I suspec that a lot of the multifunction device drivers break things up more than is strictly necessary. I'll still apply this if you think it is the right direction, but I wanted to throw that though out there for consideration. g. --- drivers/gpio/gpio-twl4030.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c index a38e6e9c..1e9f08c4 100644 --- a/drivers/gpio/gpio-twl4030.c +++ b/drivers/gpio/gpio-twl4030.c @@ -47,6 +47,7 @@ * intended to support multiple hosts. * * There are also two LED pins used sometimes as output-only GPIOs. + * TODO: Handling of PWMA/B (LEDA/B) should be removed from this GPIO driver! */ /* genirq interfaces are not available to modules */ @@ -131,6 +132,7 @@ static inline int gpio_twl4030_read(u8 address) /*--*/ +/* TODO: Handling of PWMA/B (LEDA/B) should be removed from this GPIO driver! */ static u8 cached_leden; /* The LED lines are open drain outputs ... a FET pulls to GND, so an -- 1.8.0 -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] gpio: twl4030: Introduce private structure to store variables needed runtime
On Thu, 6 Dec 2012 11:52:05 +0100, Peter Ujfalusi peter.ujfal...@ti.com wrote:
Move most of the global variables inside a private structure and allocate
it dynamically.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Applied, thanks
g.
---
drivers/gpio/gpio-twl4030.c | 82
+++--
1 file changed, 50 insertions(+), 32 deletions(-)
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index 55b4fe4..c092739 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -49,11 +49,6 @@
* There are also two LED pins used sometimes as output-only GPIOs.
*/
-
-static struct gpio_chip twl_gpiochip;
-static int twl4030_gpio_base;
-static int twl4030_gpio_irq_base;
-
/* genirq interfaces are not available to modules */
#ifdef MODULE
#define is_module() true
@@ -72,11 +67,20 @@ static int twl4030_gpio_irq_base;
/* Data structures */
static DEFINE_MUTEX(gpio_lock);
-/* store usage of each GPIO. - each bit represents one GPIO */
-static unsigned int gpio_usage_count;
+struct gpio_twl4030_priv {
+ struct gpio_chip gpio_chip;
+ int irq_base;
+
+ unsigned int usage_count;
+};
/*--*/
+static inline struct gpio_twl4030_priv *to_gpio_twl4030(struct gpio_chip
*chip)
+{
+ return container_of(chip, struct gpio_twl4030_priv, gpio_chip);
+}
+
/*
* To configure TWL4030 GPIO module registers
*/
@@ -193,10 +197,6 @@ static int twl4030_get_gpio_datain(int gpio)
u8 base = 0;
int ret = 0;
- if (unlikely((gpio = TWL4030_GPIO_MAX)
- || !(gpio_usage_count BIT(gpio
- return -EPERM;
-
base = REG_GPIODATAIN1 + d_bnk;
ret = gpio_twl4030_read(base);
if (ret 0)
@@ -209,6 +209,7 @@ static int twl4030_get_gpio_datain(int gpio)
static int twl_request(struct gpio_chip *chip, unsigned offset)
{
+ struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
int status = 0;
mutex_lock(gpio_lock);
@@ -252,7 +253,7 @@ static int twl_request(struct gpio_chip *chip, unsigned
offset)
}
/* on first use, turn GPIO module on */
- if (!gpio_usage_count) {
+ if (!priv-usage_count) {
struct twl4030_gpio_platform_data *pdata;
u8 value = MASK_GPIO_CTRL_GPIO_ON;
@@ -266,16 +267,18 @@ static int twl_request(struct gpio_chip *chip, unsigned
offset)
status = gpio_twl4030_write(REG_GPIO_CTRL, value);
}
+done:
if (!status)
- gpio_usage_count |= (0x1 offset);
+ priv-usage_count |= BIT(offset);
-done:
mutex_unlock(gpio_lock);
return status;
}
static void twl_free(struct gpio_chip *chip, unsigned offset)
{
+ struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
+
if (offset = TWL4030_GPIO_MAX) {
twl4030_led_set_value(offset - TWL4030_GPIO_MAX, 1);
return;
@@ -283,10 +286,10 @@ static void twl_free(struct gpio_chip *chip, unsigned
offset)
mutex_lock(gpio_lock);
- gpio_usage_count = ~BIT(offset);
+ priv-usage_count = ~BIT(offset);
/* on last use, switch off GPIO module */
- if (!gpio_usage_count)
+ if (!priv-usage_count)
gpio_twl4030_write(REG_GPIO_CTRL, 0x0);
mutex_unlock(gpio_lock);
@@ -301,14 +304,19 @@ static int twl_direction_in(struct gpio_chip *chip,
unsigned offset)
static int twl_get(struct gpio_chip *chip, unsigned offset)
{
+ struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
int status = 0;
+ if (!(priv-usage_count BIT(offset)))
+ return -EPERM;
+
if (offset TWL4030_GPIO_MAX)
status = twl4030_get_gpio_datain(offset);
else if (offset == TWL4030_GPIO_MAX)
status = cached_leden LEDEN_LEDAON;
else
status = cached_leden LEDEN_LEDBON;
+
return (status 0) ? 0 : status;
}
@@ -333,12 +341,14 @@ static void twl_set(struct gpio_chip *chip, unsigned
offset, int value)
static int twl_to_irq(struct gpio_chip *chip, unsigned offset)
{
- return (twl4030_gpio_irq_base (offset TWL4030_GPIO_MAX))
- ? (twl4030_gpio_irq_base + offset)
+ struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
+
+ return (priv-irq_base (offset TWL4030_GPIO_MAX))
+ ? (priv-irq_base + offset)
: -EINVAL;
}
-static struct gpio_chip twl_gpiochip = {
+static struct gpio_chip template_chip = {
.label = twl4030,
.owner = THIS_MODULE,
.request= twl_request,
@@ -424,8 +434,14 @@ static int __devinit gpio_twl4030_probe(struct
platform_device *pdev)
{
struct twl4030_gpio_platform_data *pdata = pdev-dev.platform_data;
Re: [PATCH v2 2/3] gpio: twl4030: Cache the direction and output states in private data
Hi
Grant Likely grant.lik...@secretlab.ca wrote:
On Thu, 6 Dec 2012 11:52:06 +0100, Peter Ujfalusi
peter.ujfal...@ti.com wrote:
Use more coherent locking in the driver. Use bitfield to store the
GPIO
direction and if the pin is configured as output store the status
also in a
bitfiled.
In this way we can just look at these bitfields when we need
information
about the pin status and only reach out to the chip when it is
needed.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Applied, thanks
g.
---
drivers/gpio/gpio-twl4030.c | 99
++---
1 file changed, 66 insertions(+), 33 deletions(-)
diff --git a/drivers/gpio/gpio-twl4030.c
b/drivers/gpio/gpio-twl4030.c
index c092739..a38e6e9c 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -64,14 +64,15 @@
/* Mask for GPIO registers when aggregated into a 32-bit integer */
#define GPIO_32_MASK0x0003
-/* Data structures */
-static DEFINE_MUTEX(gpio_lock);
-
struct gpio_twl4030_priv {
struct gpio_chip gpio_chip;
+struct mutex mutex;
int irq_base;
+/* Bitfields for state caching */
unsigned int usage_count;
+unsigned int direction;
+unsigned int out_state;
};
/*--*/
@@ -130,7 +131,7 @@ static inline int gpio_twl4030_read(u8 address)
/*--*/
-static u8 cached_leden; /* protected by gpio_lock */
+static u8 cached_leden;
/* The LED lines are open drain outputs ... a FET pulls to GND, so
an
* external pullup is needed. We could also expose the integrated
PWM
@@ -144,14 +145,12 @@ static void twl4030_led_set_value(int led, int
value)
if (led)
mask = 1;
-mutex_lock(gpio_lock);
if (value)
cached_leden = ~mask;
else
cached_leden |= mask;
status = twl_i2c_write_u8(TWL4030_MODULE_LED, cached_leden,
TWL4030_LED_LEDEN_REG);
-mutex_unlock(gpio_lock);
}
static int twl4030_set_gpio_direction(int gpio, int is_input)
@@ -162,7 +161,6 @@ static int twl4030_set_gpio_direction(int gpio,
int is_input)
u8 base = REG_GPIODATADIR1 + d_bnk;
int ret = 0;
-mutex_lock(gpio_lock);
ret = gpio_twl4030_read(base);
if (ret = 0) {
if (is_input)
@@ -172,7 +170,6 @@ static int twl4030_set_gpio_direction(int gpio,
int is_input)
ret = gpio_twl4030_write(base, reg);
}
-mutex_unlock(gpio_lock);
return ret;
}
@@ -212,7 +209,7 @@ static int twl_request(struct gpio_chip *chip,
unsigned offset)
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
int status = 0;
-mutex_lock(gpio_lock);
+mutex_lock(priv-mutex);
/* Support the two LED outputs as output-only GPIOs. */
if (offset = TWL4030_GPIO_MAX) {
@@ -271,7 +268,7 @@ done:
if (!status)
priv-usage_count |= BIT(offset);
-mutex_unlock(gpio_lock);
+mutex_unlock(priv-mutex);
return status;
}
@@ -279,64 +276,98 @@ static void twl_free(struct gpio_chip *chip,
unsigned offset)
{
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
+mutex_lock(priv-mutex);
if (offset = TWL4030_GPIO_MAX) {
twl4030_led_set_value(offset - TWL4030_GPIO_MAX, 1);
I have the mobile but where is the unlock here?
return;
}
-mutex_lock(gpio_lock);
-
priv-usage_count = ~BIT(offset);
/* on last use, switch off GPIO module */
if (!priv-usage_count)
gpio_twl4030_write(REG_GPIO_CTRL, 0x0);
-mutex_unlock(gpio_lock);
+mutex_unlock(priv-mutex);
}
static int twl_direction_in(struct gpio_chip *chip, unsigned offset)
{
-return (offset TWL4030_GPIO_MAX)
-? twl4030_set_gpio_direction(offset, 1)
-: -EINVAL;
+struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
+int ret;
+
+mutex_lock(priv-mutex);
+if (offset TWL4030_GPIO_MAX)
+ret = twl4030_set_gpio_direction(offset, 1);
+else
+ret = -EINVAL;
+
+if (!ret)
+priv-direction = ~BIT(offset);
+
+mutex_unlock(priv-mutex);
+
+return ret;
}
static int twl_get(struct gpio_chip *chip, unsigned offset)
{
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
+int ret;
int status = 0;
-if (!(priv-usage_count BIT(offset)))
-return -EPERM;
+mutex_lock(priv-mutex);
+if (!(priv-usage_count BIT(offset))) {
+ret = -EPERM;
+goto out;
+}
-if (offset TWL4030_GPIO_MAX)
-status = twl4030_get_gpio_datain(offset);
-else if (offset == TWL4030_GPIO_MAX)
-status = cached_leden
Re: [PATCH 09/12] ARM: OMAP2+: powerdomain: skip register reads for powerdomains known to be on
Hi Paul,
On 12/09/2012 02:03 PM, Paul Walmsley wrote:
There's no need to determine the current power state for powerdomains
that must be on while the kernel is running. We mark these
powerdomains with a new flag, PWRDM_ACTIVE_WITH_KERNEL. Any
powerdomain marked with that flag is reported as being in the ON power
state while the kernel is running.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/powerdomain.c |9 ++---
arch/arm/mach-omap2/powerdomain.h |4
arch/arm/mach-omap2/powerdomains2xxx_data.c |2 ++
arch/arm/mach-omap2/powerdomains33xx_data.c |3 ++-
arch/arm/mach-omap2/powerdomains3xxx_data.c |9 ++---
arch/arm/mach-omap2/powerdomains44xx_data.c |5 -
6 files changed, 24 insertions(+), 8 deletions(-)
[snip]
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm/mach-omap2/powerdomains44xx_data.c
index 704664c..b64213c 100644
--- a/arch/arm/mach-omap2/powerdomains44xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
@@ -53,7 +53,8 @@ static struct powerdomain core_44xx_pwrdm = {
[3] = PWRSTS_ON,/* ducati_l2ram */
[4] = PWRSTS_ON,/* ducati_unicache */
},
- .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .flags= (PWRDM_HAS_LOWPOWERSTATECHANGE |
+ PWRDM_ACTIVE_WITH_KERNEL),
};
My understanding is that for OMAP4 devices, the core power domain may
not be active the same time as the MPU power domain. The Cortex-A9 has
the ability to access some peripherals (such as timer, McBSP) via a
private bus that does not require the core domain to be active. This is
a difference from OMAP3 devices, where the core would always be on with
the MPU power domain.
Hopefully, Benoit will chime in if I have gotten this wrong ;-)
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] ARM: OMAP1: nokia770: enable CBUS/Retu
Add needed platform data so that it's possible to use Retu and e.g. feed
Retu watchdog.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
arch/arm/mach-omap1/board-nokia770.c | 43 ++
1 file changed, 43 insertions(+)
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index 24d2f2d..ecd3f2a 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -7,6 +7,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#include linux/irq.h
#include linux/gpio.h
#include linux/kernel.h
#include linux/init.h
@@ -23,6 +24,8 @@
#include linux/platform_data/keypad-omap.h
#include linux/platform_data/lcd-mipid.h
+#include linux/platform_data/gpio-omap.h
+#include linux/platform_data/i2c-cbus-gpio.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -212,6 +215,45 @@ static inline void nokia770_mmc_init(void)
}
#endif
+#if defined(CONFIG_I2C_CBUS_GPIO) || defined(CONFIG_I2C_CBUS_GPIO_MODULE)
+static struct i2c_cbus_platform_data nokia770_cbus_data = {
+ .clk_gpio = OMAP_MPUIO(9),
+ .dat_gpio = OMAP_MPUIO(10),
+ .sel_gpio = OMAP_MPUIO(11),
+};
+
+static struct platform_device nokia770_cbus_device = {
+ .name = i2c-cbus-gpio,
+ .id = 2,
+ .dev= {
+ .platform_data = nokia770_cbus_data,
+ },
+};
+
+static struct i2c_board_info nokia770_i2c_board_info_2[] __initdata = {
+ {
+ I2C_BOARD_INFO(retu-mfd, 0x01),
+ },
+};
+
+static void __init nokia770_cbus_init(void)
+{
+ const int retu_irq_gpio = 62;
+
+ if (gpio_request_one(retu_irq_gpio, GPIOF_IN, Retu IRQ))
+ return;
+ irq_set_irq_type(gpio_to_irq(retu_irq_gpio), IRQ_TYPE_EDGE_RISING);
+ nokia770_i2c_board_info_2[0].irq = gpio_to_irq(retu_irq_gpio);
+ i2c_register_board_info(2, nokia770_i2c_board_info_2,
+ ARRAY_SIZE(nokia770_i2c_board_info_2));
+ platform_device_register(nokia770_cbus_device);
+}
+#else /* CONFIG_I2C_CBUS_GPIO */
+static void __init nokia770_cbus_init(void)
+{
+}
+#endif /* CONFIG_I2C_CBUS_GPIO */
+
static void __init omap_nokia770_init(void)
{
/* On Nokia 770, the SleepX signal is masked with an
@@ -233,6 +275,7 @@ static void __init omap_nokia770_init(void)
mipid_dev_init();
omap1_usb_init(nokia770_usb_config);
nokia770_mmc_init();
+ nokia770_cbus_init();
}
MACHINE_START(NOKIA770, Nokia 770)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/RFT] ARM: OMAP1: fix USB host on 1710
There seems to be a longstanding bug that OHCI USB host controller
does not respond on 1710, possibly because of wrong clocks. Has it ever
worked? See e.g. http://marc.info/?l=linux-omapm=119634441229321w=2. All
register reads return just zeroes:
[1.896606] ohci ohci: OMAP OHCI
[1.912597] ohci ohci: new USB bus registered, assigned bus number 1
[1.933776] ohci ohci: irq 38, io mem 0xfffba000
[2.012573] ohci ohci: init err ( )
[2.030334] ohci ohci: can't start
[2.046661] ohci ohci: startup error -75
[2.063201] ohci ohci: USB bus 1 deregistered
After some experiments, it seems that when changing the usb_dc_ck /
SOFT_REQ enable bit from USB_REQ_EN_SHIFT to SOFT_USB_OTG_DPLL_REQ_SHIFT
(like done also on 7XX), the USB appears to work (tested on Nokia 770):
[2.183959] ohci ohci: OMAP OHCI
[2.198242] ohci ohci: new USB bus registered, assigned bus number 1
[2.215820] ohci ohci: irq 38, io mem 0xfffba000
[2.324798] hub 1-0:1.0: USB hub found
[2.361267] hub 1-0:1.0: 3 ports detected
Can someone test if this works also on 16xx and 5912? It seems the current
clock data format does not allow to make this change only for 1710...
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
arch/arm/mach-omap1/clock_data.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index cb7c6ae..6c4f766 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -543,15 +543,6 @@ static struct clk usb_dc_ck = {
/* Direct from ULPD, no parent */
.rate = 4800,
.enable_reg = OMAP1_IO_ADDRESS(SOFT_REQ_REG),
- .enable_bit = USB_REQ_EN_SHIFT,
-};
-
-static struct clk usb_dc_ck7xx = {
- .name = usb_dc_ck,
- .ops= clkops_generic,
- /* Direct from ULPD, no parent */
- .rate = 4800,
- .enable_reg = OMAP1_IO_ADDRESS(SOFT_REQ_REG),
.enable_bit = SOFT_USB_OTG_DPLL_REQ_SHIFT,
};
@@ -727,8 +718,7 @@ static struct omap_clk omap_clks[] = {
CLK(NULL, usb_clko, usb_clko, CK_16XX | CK_1510 |
CK_310),
CLK(NULL, usb_hhc_ck, usb_hhc_ck1510, CK_1510 | CK_310),
CLK(NULL, usb_hhc_ck, usb_hhc_ck16xx, CK_16XX),
- CLK(NULL, usb_dc_ck,usb_dc_ck, CK_16XX),
- CLK(NULL, usb_dc_ck,usb_dc_ck7xx, CK_7XX),
+ CLK(NULL, usb_dc_ck,usb_dc_ck, CK_16XX | CK_7XX),
CLK(NULL, mclk, mclk_1510, CK_1510 | CK_310),
CLK(NULL, mclk, mclk_16xx, CK_16XX),
CLK(NULL, bclk, bclk_1510, CK_1510 | CK_310),
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] gpio: twl4030: Cache the direction and output states in private data
On Wed, 19 Dec 2012 21:53:23 +0100, Michael Trimarchi
mich...@amarulasolutions.com wrote:
Hi
Grant Likely grant.lik...@secretlab.ca wrote:
On Thu, 6 Dec 2012 11:52:06 +0100, Peter Ujfalusi
peter.ujfal...@ti.com wrote:
Use more coherent locking in the driver. Use bitfield to store the
GPIO
direction and if the pin is configured as output store the status
also in a
bitfiled.
In this way we can just look at these bitfields when we need
information
about the pin status and only reach out to the chip when it is
needed.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Applied, thanks
g.
@@ -279,64 +276,98 @@ static void twl_free(struct gpio_chip *chip,
unsigned offset)
{
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
+ mutex_lock(priv-mutex);
if (offset = TWL4030_GPIO_MAX) {
twl4030_led_set_value(offset - TWL4030_GPIO_MAX, 1);
I have the mobile but where is the unlock here?
Good catch. I've dropped the patch. Peter, please resend a fixed-up version.
g.
--
To unsubscribe from this list: send the line unsubscribe 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] OMAP GPIO - don't wake from suspend unless requested.
On Fri, 14 Dec 2012 18:05:53 +1100, NeilBrown ne...@suse.de wrote: On Mon, 10 Sep 2012 10:57:07 -0700 Kevin Hilman khil...@deeprootsystems.com wrote: OK thanks, I'll queue this up for v3.6-rc as this should qualify as a regression. I don't think this did actually get queued. At least I'm still seeing the bug in 3.7 and I cannot see a patch in the git history that looks right. But then I don't remember what we ended up with - it was 3 months ago!!! This is the last thing I can find in my email history - it still seems to apply and still seems to work. NeilBrown Kevin, let me know if I need to do anything here. Since you might have it in one of you're trees, I'm not going to do anything unless I hear from you. g. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/RFT] ARM: OMAP1: fix USB host on 1710
Hi, * Aaro Koskinen aaro.koski...@iki.fi [121219 14:10]: There seems to be a longstanding bug that OHCI USB host controller does not respond on 1710, possibly because of wrong clocks. Has it ever worked? Don't know about 770, but I used to have an old CF card reader hooked to my osk5912 and it was working. See e.g. http://marc.info/?l=linux-omapm=119634441229321w=2. All register reads return just zeroes: [1.896606] ohci ohci: OMAP OHCI [1.912597] ohci ohci: new USB bus registered, assigned bus number 1 [1.933776] ohci ohci: irq 38, io mem 0xfffba000 [2.012573] ohci ohci: init err ( ) [2.030334] ohci ohci: can't start [2.046661] ohci ohci: startup error -75 [2.063201] ohci ohci: USB bus 1 deregistered After some experiments, it seems that when changing the usb_dc_ck / SOFT_REQ enable bit from USB_REQ_EN_SHIFT to SOFT_USB_OTG_DPLL_REQ_SHIFT (like done also on 7XX), the USB appears to work (tested on Nokia 770): [2.183959] ohci ohci: OMAP OHCI [2.198242] ohci ohci: new USB bus registered, assigned bus number 1 [2.215820] ohci ohci: irq 38, io mem 0xfffba000 [2.324798] hub 1-0:1.0: USB hub found [2.361267] hub 1-0:1.0: 3 ports detected Cool seems like you've fixed a long standing bug :) And also have tahvo-usb working? Can someone test if this works also on 16xx and 5912? It seems the current clock data format does not allow to make this change only for 1710... Does not seem to make a difference, I get the following on osk5912 with and without your patch: hci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ohci_hcd: block sizes: ed 64 td 64 ohci ohci: OMAP OHCI ohci ohci: new USB bus registered, assigned bus number 1 ohci ohci: starting USB Controller ohci ohci: created debug files ohci ohci: irq 38, io mem 0xfffba000 ohci ohci: OHCI controller state ohci ohci: OHCI 1.0, NO legacy support registers, rh state running ohci ohci: control 0x283 RWC HCFS=operational CBSR=3 ohci ohci: cmdstatus 0x0 SOC=0 ohci ohci: intrstatus 0x0004 SF ohci ohci: intrenable 0x805a MIE RHSC UE RD WDH ohci ohci: hcca frame #002f ohci ohci: roothub.a 0a03 POTPGT=10 NDP=3(3) ohci ohci: roothub.b 000e PPCM=000e DR= ohci ohci: roothub.status 8000 DRWE ohci ohci: roothub.portstatus [0] 0x0100 PPS ohci ohci: roothub.portstatus [1] 0x0100 PPS ohci ohci: roothub.portstatus [2] 0x0100 PPS usb usb1: default language 0x0409 usb usb1: udev 1, busnum 1, minor = 0 usb usb1: New USB device found, idVendor=1d6b, idProduct=0001 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: OMAP OHCI usb usb1: Manufacturer: Linux 3.7.0-00024-gf7c4407 ohci_hcd usb usb1: SerialNumber: ohci usb usb1: usb_probe_device usb usb1: configuration #1 chosen from 1 choice usb usb1: adding 1-0:1.0 (config #1, interface 0) hub 1-0:1.0: usb_probe_interface hub 1-0:1.0: usb_probe_interface - got id hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected hub 1-0:1.0: standalone hub hub 1-0:1.0: ganged power switching hub 1-0:1.0: global over-current protection hub 1-0:1.0: power on to power good time: 20ms hub 1-0:1.0: 250mA bus power budget for each child hub 1-0:1.0: local power source is good hub 1-0:1.0: no over-current condition exists hub 1-0:1.0: enabling power on all ports Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] ARM: OMAP2: hwmod: Fix register offset NULL check bug
On Wed, Dec 19, 2012 at 07:43:50, Paul Walmsley wrote:
On Tue, 18 Dec 2012, Hebbar Gururaja wrote:
From: Hebbar, Gururaja gururaja.heb...@ti.com
omap4_cminst_wait_module_ready() checks if register offset is NULL.
int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16 cdoffs,
u16 clkctrl_offs)
{
int i = 0;
if (!clkctrl_offs)
return 0;
In case of AM33xx, CLKCTRL register offset for different clock domains
are not uniformly placed. An example of this would be the RTC clock
domain with CLKCTRL offset at 0x00.
In such cases the module ready check is skipped which leads to a data
abort during boot-up when RTC registers is accessed.
We've got a few hwmods on OMAP44xx that don't have clkctrl_offs registers
listed in the hwmod data, and which are not marked with HWMOD_NO_IDLEST.
What's going to happen in those cases?
Hmm. This is a special case to me. Let me go back and do some review.
Will be back with some more details.
- Paul
Regards,
Gururaja
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: BUG: spinlock bad magic on CPU#0 on BeagleBone
On Thu, Dec 20, 2012 at 01:53:42, Stephen Boyd wrote:
On 12/19/12 08:53, Paul Walmsley wrote:
On Wed, 19 Dec 2012, Bedia, Vaibhav wrote:
Current mainline on Beaglebone using the omap2plus_defconfig + 3 build
fixes
is triggering a BUG()
...
[0.109688] Security Framework initialized
[0.109889] Mount-cache hash table entries: 512
[0.112674] BUG: spinlock bad magic on CPU#0, swapper/0/0
[0.112724] lock: atomic64_lock+0x240/0x400, .magic: , .owner:
none/-1, .owner_cpu: 0
[0.112782] [c001af64] (unwind_backtrace+0x0/0xf0) from [c02c2010]
(do_raw_spin_lock+0x158/0x198)
[0.112813] [c02c2010] (do_raw_spin_lock+0x158/0x198) from
[c04d89ec] (_raw_spin_lock_irqsave+0x4c/0x58)
[0.112844] [c04d89ec] (_raw_spin_lock_irqsave+0x4c/0x58) from
[c02cabf0] (atomic64_add_return+0x30/0x5c)
[0.112886] [c02cabf0] (atomic64_add_return+0x30/0x5c) from
[c0124564] (alloc_mnt_ns.clone.14+0x44/0xac)
[0.112914] [c0124564] (alloc_mnt_ns.clone.14+0x44/0xac) from
[c0124f4c] (create_mnt_ns+0xc/0x54)
[0.112951] [c0124f4c] (create_mnt_ns+0xc/0x54) from [c06f31a4]
(mnt_init+0x120/0x1d4)
[0.112978] [c06f31a4] (mnt_init+0x120/0x1d4) from [c06f2d50]
(vfs_caches_init+0xe0/0x10c)
[0.113005] [c06f2d50] (vfs_caches_init+0xe0/0x10c) from [c06d4798]
(start_kernel+0x29c/0x300)
[0.113029] [c06d4798] (start_kernel+0x29c/0x300) from [80008078]
(0x80008078)
[0.118290] CPU: Testing write buffer coherency: ok
[0.118968] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[0.119053] Setting up static identity map for 0x804de2c8 - 0x804de338
[0.120698] Brought up 1 CPUs
This is probably a memory corruption bug, there's probably some code
executing early that's writing outside its own data and trashing some
previously-allocated memory.
I'm not so sure. It looks like atomic64s use spinlocks on processors
that don't have 64-bit atomic instructions (see lib/atomic64.c). And
those spinlocks are not initialized until a pure initcall runs,
init_atomic64_lock(). Pure initcalls don't run until after
vfs_caches_init() and so you get this BUG() warning that the spinlock is
not initialized.
How about we initialize the locks statically? Does that fix your problem?
8-
diff --git a/lib/atomic64.c b/lib/atomic64.c
index 9785378..08a4f06 100644
--- a/lib/atomic64.c
+++ b/lib/atomic64.c
@@ -31,7 +31,11 @@
static union {
raw_spinlock_t lock;
char pad[L1_CACHE_BYTES];
-} atomic64_lock[NR_LOCKS] __cacheline_aligned_in_smp;
+} atomic64_lock[NR_LOCKS] __cacheline_aligned_in_smp = {
+ [0 ... (NR_LOCKS - 1)] = {
+ .lock = __RAW_SPIN_LOCK_UNLOCKED(atomic64_lock.lock),
+ },
+};
static inline raw_spinlock_t *lock_addr(const atomic64_t *v)
{
@@ -173,14 +177,3 @@ int atomic64_add_unless(atomic64_t *v, long long a, long
long u)
return ret;
}
EXPORT_SYMBOL(atomic64_add_unless);
-
-static int init_atomic64_lock(void)
-{
- int i;
-
- for (i = 0; i NR_LOCKS; ++i)
- raw_spin_lock_init(atomic64_lock[i].lock);
- return 0;
-}
-
-pure_initcall(init_atomic64_lock);
I tried out 3 variants of AM335x boards - 2 of these (BeagleBone and EVM) have
DDR2
and 1 has DDR3 (EVM-SK). The BUG is triggered on all of these at the same point.
With Stephen's change I don't see this on any of the board variants :)
New bootlog below.
Thanks,
Vaibhav
---
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.7.0-01415-g55bc169-dirty (a0393953@psplinux063)
(gcc version 4.5.3 20110311 (prerelease) (GCC) ) #4 SMP Thu Dec 20 09:59:12 IST
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: Generic AM33XX (Flattened Device Tree), model: TI
AM335x BeagleBone
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] AM335X ES1.0 (neon )
[0.00] PERCPU: Embedded 9 pages/cpu @c0f1a000 s12992 r8192 d15680 u36864
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 64768
[0.00] Kernel command line: console=ttyO0,115200n8 mem=256M
root=/dev/ram rw initrd=0x8200,16MB ramdisk_size=65536 earlyprintk=serial
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] __ex_table already sorted, skipping sort
[0.00] Memory: 255MB = 255MB total
[0.00] Memory: 229012k/229012k available, 33132k 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]
Re: [PATCH] gpio/omap: implement irq_enable/disable using mask/unmask.
On Monday 17 December 2012 02:57 PM, Andreas Fenkart wrote:
Please add some changelog here too.
Signed-off-by: Andreas Fenkart andreas.fenk...@streamunlimited.com
---
Patch seems straight forward thought will be interesting where you found
the need of it.
drivers/gpio/gpio-omap.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index d335af1..c1951ec 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -815,6 +815,8 @@ static struct irq_chip gpio_irq_chip = {
.irq_unmask = gpio_unmask_irq,
.irq_set_type = gpio_irq_type,
.irq_set_wake = gpio_wake_enable,
+ .irq_disable= gpio_mask_irq,
+ .irq_enable = gpio_unmask_irq,
};
/*-*/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: spinlock bad magic on CPU#0 on BeagleBone
On 12/19/2012 8:48 PM, Bedia, Vaibhav wrote: I tried out 3 variants of AM335x boards - 2 of these (BeagleBone and EVM) have DDR2 and 1 has DDR3 (EVM-SK). The BUG is triggered on all of these at the same point. With Stephen's change I don't see this on any of the board variants :) New bootlog below. Great! Can I have your Tested-by then? I'll wrap it up into a patch. Is this is a new regression? From a glance at the code it looks to have existed for quite a while now. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] drop plat/cpu.h for omap2plus
On Monday 17 December 2012 01:33 AM, Tony Lindgren wrote: Hi all, Finally it can be dropped. Thanks for help everybody. Looks fine to me with update plat/cpu.h patch. Thanks to you as well for all those patches. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: BUG: spinlock bad magic on CPU#0 on BeagleBone
On Thu, Dec 20, 2012 at 11:55:24, Stephen Boyd wrote: On 12/19/2012 8:48 PM, Bedia, Vaibhav wrote: I tried out 3 variants of AM335x boards - 2 of these (BeagleBone and EVM) have DDR2 and 1 has DDR3 (EVM-SK). The BUG is triggered on all of these at the same point. With Stephen's change I don't see this on any of the board variants :) New bootlog below. Great! Can I have your Tested-by then? I'll wrap it up into a patch. Is this is a new regression? From a glance at the code it looks to have existed for quite a while now. I went back to a branch based off 3.7-rc4 and don't see the issue there. Not sure what is triggering this now. Tested-by: Vaibhav Bedia vaibhav.be...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: spinlock bad magic on CPU#0 on BeagleBone
On 12/19/2012 10:44 PM, Bedia, Vaibhav wrote: On Thu, Dec 20, 2012 at 11:55:24, Stephen Boyd wrote: On 12/19/2012 8:48 PM, Bedia, Vaibhav wrote: I tried out 3 variants of AM335x boards - 2 of these (BeagleBone and EVM) have DDR2 and 1 has DDR3 (EVM-SK). The BUG is triggered on all of these at the same point. With Stephen's change I don't see this on any of the board variants :) New bootlog below. Great! Can I have your Tested-by then? I'll wrap it up into a patch. Is this is a new regression? From a glance at the code it looks to have existed for quite a while now. I went back to a branch based off 3.7-rc4 and don't see the issue there. Not sure what is triggering this now. Tested-by: Vaibhav Bedia vaibhav.be...@ti.com Thanks. I was thrown off by the author date of this patch which introduced your problem commit 8823c079ba7136dc1948d6f6dcb5f8022bde438e Author: Eric W. Biederman ebied...@xmission.com AuthorDate: Sun Mar 7 18:49:36 2010 -0800 Commit: Eric W. Biederman ebied...@xmission.com CommitDate: Mon Nov 19 05:59:18 2012 -0800 vfs: Add setns support for the mount namespace It seems to have a 2 year gap between commit date and author date. Either way, it looks to be isolated to the 3.8 merge window but affects quite a few architectures. Patch to follow shortly. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] ARM: OMAP2: hwmod: Fix register offset NULL check bug
On Thu, 20 Dec 2012, Hebbar, Gururaja wrote: On Wed, Dec 19, 2012 at 07:43:50, Paul Walmsley wrote: We've got a few hwmods on OMAP44xx that don't have clkctrl_offs registers listed in the hwmod data, and which are not marked with HWMOD_NO_IDLEST. What's going to happen in those cases? Hmm. This is a special case to me. Let me go back and do some review. Will be back with some more details. Probably what needs to happen is that those hwmods need to be marked with HWMOD_NO_IDLEST, in a separate patch before yours. As far as I can tell, that's how they should have been marked initially. Then your patch should be fine. - 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
[PATCH] lib: atomic64: Initialize locks statically to fix early users
The atomic64 library uses a handful of static spin locks to
implement atomic 64-bit operations on architectures without
support for atomic 64-bit instructions. Unfortunately, the
spinlocks are initialized in a pure initcall and that is too late
for the vfs namespace code which wants to use atomic64 operations
before the initcall is run (introduced by 8823c07 vfs: Add setns
support for the mount namespace).
This leads to BUG messages such as:
BUG: spinlock bad magic on CPU#0, swapper/0/0
lock: atomic64_lock+0x240/0x400, .magic: , .owner: none/-1,
.owner_cpu: 0
[c001af64] (unwind_backtrace+0x0/0xf0) from [c02c2010]
(do_raw_spin_lock+0x158/0x198)
[c02c2010] (do_raw_spin_lock+0x158/0x198) from [c04d89ec]
(_raw_spin_lock_irqsave+0x4c/0x58)
[c04d89ec] (_raw_spin_lock_irqsave+0x4c/0x58) from [c02cabf0]
(atomic64_add_return+0x30/0x5c)
[c02cabf0] (atomic64_add_return+0x30/0x5c) from [c0124564]
(alloc_mnt_ns.clone.14+0x44/0xac)
[c0124564] (alloc_mnt_ns.clone.14+0x44/0xac) from [c0124f4c]
(create_mnt_ns+0xc/0x54)
[c0124f4c] (create_mnt_ns+0xc/0x54) from [c06f31a4] (mnt_init+0x120/0x1d4)
[c06f31a4] (mnt_init+0x120/0x1d4) from [c06f2d50]
(vfs_caches_init+0xe0/0x10c)
[c06f2d50] (vfs_caches_init+0xe0/0x10c) from [c06d4798]
(start_kernel+0x29c/0x300)
[c06d4798] (start_kernel+0x29c/0x300) from [80008078] (0x80008078)
coming out early on during boot when spinlock debugging is enabled.
Fix this problem by initializing the spinlocks statically at
compile time.
Reported-by: Vaibhav Bedia vaibhav.be...@ti.com
Tested-by: Vaibhav Bedia vaibhav.be...@ti.com
Cc: Eric W. Biederman ebied...@xmission.com
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
Sorry Andrew, I couldn't find a maintainer of this file so I
am picking on you.
lib/atomic64.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/lib/atomic64.c b/lib/atomic64.c
index 9785378..08a4f06 100644
--- a/lib/atomic64.c
+++ b/lib/atomic64.c
@@ -31,7 +31,11 @@
static union {
raw_spinlock_t lock;
char pad[L1_CACHE_BYTES];
-} atomic64_lock[NR_LOCKS] __cacheline_aligned_in_smp;
+} atomic64_lock[NR_LOCKS] __cacheline_aligned_in_smp = {
+ [0 ... (NR_LOCKS - 1)] = {
+ .lock = __RAW_SPIN_LOCK_UNLOCKED(atomic64_lock.lock),
+ },
+};
static inline raw_spinlock_t *lock_addr(const atomic64_t *v)
{
@@ -173,14 +177,3 @@ int atomic64_add_unless(atomic64_t *v, long long a, long
long u)
return ret;
}
EXPORT_SYMBOL(atomic64_add_unless);
-
-static int init_atomic64_lock(void)
-{
- int i;
-
- for (i = 0; i NR_LOCKS; ++i)
- raw_spin_lock_init(atomic64_lock[i].lock);
- return 0;
-}
-
-pure_initcall(init_atomic64_lock);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
