From laurent.pinchart at ideasonboard.com Mon Jan 2 05:21:06 2012 From: laurent.pinchart at ideasonboard.com (Laurent Pinchart) Date: Mon, 2 Jan 2012 12:21:06 +0100 Subject: [PATCH 2/2] v4l2: add new pixel formats supported on dm365 In-Reply-To: <20111228111627.GT3677@valkosipuli.localdomain> References: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> <201112212323.26971.laurent.pinchart@ideasonboard.com> <20111228111627.GT3677@valkosipuli.localdomain> Message-ID: <201201021221.06660.laurent.pinchart@ideasonboard.com> Hi Sakari, On Wednesday 28 December 2011 12:16:27 Sakari Ailus wrote: > On Wed, Dec 21, 2011 at 11:23:26PM +0100, Laurent Pinchart wrote: > > On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote: > > > On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote: > > > > On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote: > > > > > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote: > > > > > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote: > > > > > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer > > > > > > > format frames compressed by A-LAW alogorithm. > > > > > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) > > > > > > > only. > > > > > > > > > > > > > > Signed-off-by: Manjunath Hadli > > > > > > > Cc: Laurent Pinchart > > > > > > > --- > > > > > > > > > > > > > > include/linux/videodev2.h | 6 ++++++ > > > > > > > 1 files changed, 6 insertions(+), 0 deletions(-) > > > > > > > > > > > > Could you please also document these formats in > > > > > > Documentation/DocBook/media/v4l ? > > > > > > > > > > I will. Sorry to have missed that out. > > > > > > > > > > > > diff --git a/include/linux/videodev2.h > > > > > > > b/include/linux/videodev2.h index 4b752d5..969112d 100644 > > > > > > > --- a/include/linux/videodev2.h > > > > > > > +++ b/include/linux/videodev2.h > > > > > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format { > > > > > > > > > > > > > > #define V4L2_PIX_FMT_HM12 v4l2_fourcc('H', 'M', '1', '2') > > > > > > > /* 8 YUV > > > > > > > > > > > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420 > > > > > > > v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 > > > > > > > line uv interleaved */ > > > > > > > > > > > > > > +/* Chrominance formats */ > > > > > > > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') > > > > > > > /* 8 UV 4:4 */ + > > > > > > > > > > > > > > /* two planes -- one Y, one Cr + Cb interleaved */ > > > > > > > #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') > > > > > > > /* 12 Y/CbCr > > > > > > > > > > > > > > 4:2:0 */ #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', > > > > > > > '2', '1') /* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ struct > > > > > > > v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12 > > > > > > > v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /* > > > > > > > 10bit raw bayer DPCM compressed to 8 bits */ #define > > > > > > > V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0') > > > > > > > + /* 10bit raw bayer a-law compressed to 8 bits */ #define > > > > > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8') > > > > > > > + > > > > > > > > > > > > That's not very future-proof, how would you describe SGBRG10ALAW8 > > > > > > for instance ? > > > > > > > > > > > > Maybe it's time to standardize FOURCCs for Bayer new formats. We > > > > > > have 4 characters, we could start with 'B' to denote Bayer, > > > > > > followed by one character for the order, one for the > > > > > > compression, and one for the number of bits. > > > > > > > > > > I agree. > > > > > May be ('B', 'G', 'A', '8') is fine for the above? > > > > > > > > We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use > > > > 'B', 'g', 'G' and 'R' respectively for the second character. The > > > > third character would be 'A' for A-law and 'D' for DPCM, and the > > > > fourth character could describe the bus width in bits from 0 to 15 > > > > with '0' - '9', 'A' - 'F'. However, I suspect that we will need > > > > 16-bit wide busses for raw Bayer at some point, and a 0 width is > > > > definitely not useful. We could thus offset the width by some value. > > > > > > > > This is just a preliminary idea, I'm open to suggestions. > > > > > > I think it is a very good suggestion that we can go with. > > > B : BGGR > > > g : GBRG > > > G : GRBG > > > R : RGGB > > > > > > and 0-F can signify 1-16. > > > > Hans, Guennadi, Sakari, any opinion on that as well ? > > I think four letters simply aren't enough to universally describe a media > bus format in a human-readable way. We can aim to that, but we will have to > make compromises. > > For example, DPCM compressed format has two important parameters beyond > pixel order and the colour space, the uncompressed depth and the compressed > depth. Typically one doesn't compress the data too much, but things like > 10-to-6 bits are well possible. > > Could we use a single letter to tell that a format is both bayer and DPCM > compressed? I'd go for 'b'. Raw bayer alaw could be denoted by 'a'. > > Then raw bayer, GBRG pixel order 10-to-7 bits would be called "bgA7". The > same in Alaw would be "agA7". > > What do you think? We can't come up with a naming scheme that will handle all possible combinations. I'm fine as long as the names we select have some kind of structure and handle the raw patterns currently available. I'd still like to hear Hans' opinion on this. -- Regards, Laurent Pinchart From prakash.pm at ti.com Mon Jan 2 23:41:06 2012 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Tue, 3 Jan 2012 05:41:06 +0000 Subject: [PATCH v2] video: da8xx-fb: reset LCDC only if functional clock changes with DVFS In-Reply-To: <1324545554-20543-1-git-send-email-prakash.pm@ti.com> References: <1324545554-20543-1-git-send-email-prakash.pm@ti.com> Message-ID: Hi, On Thu, Dec 22, 2011 at 14:49:14, Manjunathappa, Prakash wrote: > LCDC functional clock may or may not be derived from CPU/MPU DPLL, For example, AM335x => Separate independent DPLL for LCDC Davinci => Same DPLL as MPU > > So, on platforms where LCDC functional clock is not derived from CPU/MPU PLL it is not required to reset LCDC module as its functional clock does not change with DVFS. > > This patch adds check to do reset only if functional clock changes between pre and post notifier callbacks with DVFS. > > Signed-off-by: Manjunathappa, Prakash > --- > drivers/video/da8xx-fb.c | 15 ++++++++++----- > 1 files changed, 10 insertions(+), 5 deletions(-) > > diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c index 6b27751..6146186 100644 > --- a/drivers/video/da8xx-fb.c > +++ b/drivers/video/da8xx-fb.c > @@ -163,6 +163,7 @@ struct da8xx_fb_par { > int vsync_timeout; > #ifdef CONFIG_CPU_FREQ > struct notifier_block freq_transition; > + unsigned int lcd_fck_rate; > #endif > void (*panel_power_ctrl)(int); > }; > @@ -895,11 +896,12 @@ static int lcd_da8xx_cpufreq_transition(struct notifier_block *nb, > struct da8xx_fb_par *par; > > par = container_of(nb, struct da8xx_fb_par, freq_transition); > - if (val == CPUFREQ_PRECHANGE) { > - lcd_disable_raster(); > - } else if (val == CPUFREQ_POSTCHANGE) { > - lcd_calc_clk_divider(par); > - lcd_enable_raster(); > + if (val == CPUFREQ_POSTCHANGE) { > + if (par->lcd_fck_rate != clk_get_rate(par->lcdc_clk)) { I need to update par->lcd_fck_rate here, I will send v3 of this patch. Thanks, Prakash > + lcd_disable_raster(); > + lcd_calc_clk_divider(par); > + lcd_enable_raster(); > + } > } > > return 0; > @@ -1192,6 +1194,9 @@ static int __devinit fb_probe(struct platform_device *device) > > par = da8xx_fb_info->par; > par->lcdc_clk = fb_clk; > +#ifdef CONFIG_CPU_FREQ > + par->lcd_fck_rate = clk_get_rate(fb_clk); #endif > par->pxl_clk = lcdc_info->pxl_clk; > if (fb_pdata->panel_power_ctrl) { > par->panel_power_ctrl = fb_pdata->panel_power_ctrl; > -- > 1.7.1 > > From linux at arm.linux.org.uk Tue Jan 3 03:07:11 2012 From: linux at arm.linux.org.uk (Russell King - ARM Linux) Date: Tue, 3 Jan 2012 09:07:11 +0000 Subject: [PATCH 2/2] ARM: davinci: convert sched_clock() to use common infrastructure In-Reply-To: <1324663040-2859-2-git-send-email-nsekhar@ti.com> References: <1324663040-2859-1-git-send-email-nsekhar@ti.com> <1324663040-2859-2-git-send-email-nsekhar@ti.com> Message-ID: <20120103090711.GB2914@n2100.arm.linux.org.uk> On Fri, Dec 23, 2011 at 11:27:20PM +0530, Sekhar Nori wrote: > Convert davinci to use the common sched_clock() infrastructure > for extending 32bit counters to full 64-bit nanoseconds. > > Eventually clocksource timer should be initialized from init_early > so there would be no need to use a dummy clocksource read at start. Please see patch 7205/2. From linus.walleij at linaro.org Tue Jan 3 03:26:04 2012 From: linus.walleij at linaro.org (Linus Walleij) Date: Tue, 3 Jan 2012 10:26:04 +0100 Subject: [PATCH 2/2] ARM: davinci: convert sched_clock() to use common infrastructure In-Reply-To: <1324663040-2859-2-git-send-email-nsekhar@ti.com> References: <1324663040-2859-1-git-send-email-nsekhar@ti.com> <1324663040-2859-2-git-send-email-nsekhar@ti.com> Message-ID: On Fri, Dec 23, 2011 at 6:57 PM, Sekhar Nori wrote: > Convert davinci to use the common sched_clock() infrastructure > for extending 32bit counters to full 64-bit nanoseconds. > > Eventually clocksource timer should be initialized from init_early > so there would be no need to use a dummy clocksource read at start. > > Tested-by: Murali Karicheri > Signed-off-by: Sekhar Nori This will collide with Marc Zyngiers runtime-selectable sched_clock() patches merged to linux-next recently, it probably won't even compile. Yours, Linus Walleij From prakash.pm at ti.com Tue Jan 3 06:40:51 2012 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Tue, 3 Jan 2012 18:10:51 +0530 Subject: [PATCH v3] video: da8xx-fb: reset LCDC only if functional clock changes with DVFS Message-ID: <1325594451-11963-1-git-send-email-prakash.pm@ti.com> LCDC functional clock may or may not be derived from CPU/MPU DPLL, For example, AM335x => Separate independent DPLL for LCDC Davinci => Same DPLL as MPU So, on platforms where LCDC functional clock is not derived from CPU/MPU PLL it is not required to reset LCDC module as its functional clock does not change with DVFS. This patch adds check to do reset only if functional clock changes between pre and post notifier callbacks with DVFS. Signed-off-by: Manjunathappa, Prakash --- Since v2: Fix, update lcd_fck_rate with current LCD functional clock rate. Since v1: Fixed the commit message. drivers/video/da8xx-fb.c | 16 +++++++++++----- 1 files changed, 11 insertions(+), 5 deletions(-) diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c index 6b27751..dee1918 100644 --- a/drivers/video/da8xx-fb.c +++ b/drivers/video/da8xx-fb.c @@ -163,6 +163,7 @@ struct da8xx_fb_par { int vsync_timeout; #ifdef CONFIG_CPU_FREQ struct notifier_block freq_transition; + unsigned int lcd_fck_rate; #endif void (*panel_power_ctrl)(int); }; @@ -895,11 +896,13 @@ static int lcd_da8xx_cpufreq_transition(struct notifier_block *nb, struct da8xx_fb_par *par; par = container_of(nb, struct da8xx_fb_par, freq_transition); - if (val == CPUFREQ_PRECHANGE) { - lcd_disable_raster(); - } else if (val == CPUFREQ_POSTCHANGE) { - lcd_calc_clk_divider(par); - lcd_enable_raster(); + if (val == CPUFREQ_POSTCHANGE) { + if (par->lcd_fck_rate != clk_get_rate(par->lcdc_clk)) { + par->lcd_fck_rate = clk_get_rate(par->lcdc_clk); + lcd_disable_raster(); + lcd_calc_clk_divider(par); + lcd_enable_raster(); + } } return 0; @@ -1192,6 +1195,9 @@ static int __devinit fb_probe(struct platform_device *device) par = da8xx_fb_info->par; par->lcdc_clk = fb_clk; +#ifdef CONFIG_CPU_FREQ + par->lcd_fck_rate = clk_get_rate(fb_clk); +#endif par->pxl_clk = lcdc_info->pxl_clk; if (fb_pdata->panel_power_ctrl) { par->panel_power_ctrl = fb_pdata->panel_power_ctrl; -- 1.7.1 From manjunath.hadli at ti.com Wed Jan 4 01:17:47 2012 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Wed, 4 Jan 2012 12:47:47 +0530 Subject: [PATCH v8 0/2]remove machine specific header file inclusion from driver Message-ID: <1325661469-4411-1-git-send-email-manjunath.hadli@ti.com> remove unnecessary inclusion of machine specific header file from driver which comes in the way of platform code consolidation. Manjunath Hadli (2): davinci: vpif: remove machine specific header file inclusion from the driver davinci: CQ93VC: remove machine specific header file inclusion from codec driver drivers/media/video/davinci/vpif.h | 2 -- drivers/media/video/davinci/vpif_display.c | 2 -- include/media/davinci/vpif_types.h | 2 ++ sound/soc/codecs/cq93vc.c | 2 -- 4 files changed, 2 insertions(+), 6 deletions(-) From manjunath.hadli at ti.com Wed Jan 4 01:17:48 2012 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Wed, 4 Jan 2012 12:47:48 +0530 Subject: [PATCH v8 1/2] davinci: vpif: remove machine specific header file inclusion from the driver In-Reply-To: <1325661469-4411-1-git-send-email-manjunath.hadli@ti.com> References: <1325661469-4411-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1325661469-4411-2-git-send-email-manjunath.hadli@ti.com> remove unnecessary inclusion of machine specific header files mach/dm646x.h, mach/hardware.h from vpif.h and aslo mach/dm646x.h from vpif_display.c driver which comes in the way of platform code consolidation. Add linux/i2c.h header file in vpif_types.h which is required for building. Signed-off-by: Manjunath Hadli Cc: Mauro Carvalho Chehab Cc: LMML --- drivers/media/video/davinci/vpif.h | 2 -- drivers/media/video/davinci/vpif_display.c | 2 -- include/media/davinci/vpif_types.h | 2 ++ 3 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/media/video/davinci/vpif.h b/drivers/media/video/davinci/vpif.h index 25036cb..8bcac65 100644 --- a/drivers/media/video/davinci/vpif.h +++ b/drivers/media/video/davinci/vpif.h @@ -18,8 +18,6 @@ #include #include -#include -#include #include /* Maximum channel allowed */ diff --git a/drivers/media/video/davinci/vpif_display.c b/drivers/media/video/davinci/vpif_display.c index 286f029..7fa34b4 100644 --- a/drivers/media/video/davinci/vpif_display.c +++ b/drivers/media/video/davinci/vpif_display.c @@ -39,8 +39,6 @@ #include #include -#include - #include "vpif_display.h" #include "vpif.h" diff --git a/include/media/davinci/vpif_types.h b/include/media/davinci/vpif_types.h index 9929b05..bd8217c 100644 --- a/include/media/davinci/vpif_types.h +++ b/include/media/davinci/vpif_types.h @@ -17,6 +17,8 @@ #ifndef _VPIF_TYPES_H #define _VPIF_TYPES_H +#include + #define VPIF_CAPTURE_MAX_CHANNELS 2 enum vpif_if_type { -- 1.6.2.4 From manjunath.hadli at ti.com Wed Jan 4 01:17:49 2012 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Wed, 4 Jan 2012 12:47:49 +0530 Subject: [PATCH v8 2/2] davinci: CQ93VC: remove machine specific header file inclusion from codec driver In-Reply-To: <1325661469-4411-1-git-send-email-manjunath.hadli@ti.com> References: <1325661469-4411-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1325661469-4411-3-git-send-email-manjunath.hadli@ti.com> remove unnecessary inclusion of machine specific header file mach/dm365.h from cq93vc.c voice codec driver which comes in the way of platform code consolidation. Signed-off-by: Manjunath Hadli Cc: Miguel Aguilar Cc: Jaroslav Kysela CC: Takashi Iwai Cc: Cc: --- sound/soc/codecs/cq93vc.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/cq93vc.c b/sound/soc/codecs/cq93vc.c index 46dbfd0..ff4eb7a 100644 --- a/sound/soc/codecs/cq93vc.c +++ b/sound/soc/codecs/cq93vc.c @@ -38,8 +38,6 @@ #include #include -#include - static inline unsigned int cq93vc_read(struct snd_soc_codec *codec, unsigned int reg) { -- 1.6.2.4 From manjunath.hadli at ti.com Wed Jan 4 01:37:43 2012 From: manjunath.hadli at ti.com (Hadli, Manjunath) Date: Wed, 4 Jan 2012 07:37:43 +0000 Subject: [PATCH v7 5/8] davinci: dm644x: change vpfe capture structure variables for consistency In-Reply-To: <3E54258959B69E4282D79E01AB1F32B724A949@DFLE34.ent.ti.com> References: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com> <1324475021-32509-6-git-send-email-manjunath.hadli@ti.com> <3E54258959B69E4282D79E01AB1F32B724A949@DFLE34.ent.ti.com> Message-ID: Murali, On Wed, Dec 21, 2011 at 20:25:23, Karicheri, Muralidharan wrote: > original Message----- > >> From: davinci-linux-open-source-bounces+m- > >> karicheri2=ti.com at linux.davincidsp.com > >> [mailto:davinci-linux-open-source- > >> bounces+m-karicheri2=ti.com at linux.davincidsp.com] On Behalf Of Hadli, > >> Manjunath > >> Sent: Wednesday, December 21, 2011 8:44 AM > >> To: dlos; LAK > >> Subject: [PATCH v7 5/8] davinci: dm644x: change vpfe capture > >> structure variables for consistency > >> > >> Add SoC and board prefixes to variable names so that it is consistent > >> with the rest of the file. > >> > >> Signed-off-by: Manjunath Hadli > >> Acked-by: Sekhar Nori > >> --- > >> arch/arm/mach-davinci/board-dm644x-evm.c | 24 ++++++++++++------------ > >> arch/arm/mach-davinci/dm644x.c | 12 ++++++------ > >> 2 files changed, 18 insertions(+), 18 deletions(-) > >> > >> diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c > >> b/arch/arm/mach- davinci/board-dm644x-evm.c index 6d76d7c..7d940f5 > >> 100644 > >> --- a/arch/arm/mach-davinci/board-dm644x-evm.c > >> +++ b/arch/arm/mach-davinci/board-dm644x-evm.c > >> @@ -190,7 +190,7 @@ static struct platform_device davinci_fb_device = { > >> .num_resources = 0, > >> }; > >> > >> -static struct tvp514x_platform_data tvp5146_pdata = { > >> +static struct tvp514x_platform_data dm644xevm_tvp5146_pdata = { > >> .clk_polarity = 0, > >> .hs_polarity = 1, > >> .vs_polarity = 1 > >> @@ -198,7 +198,7 @@ static struct tvp514x_platform_data tvp5146_pdata > >> = { > >> > >> #define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL) > >> /* Inputs available at the TVP5146 */ -static struct v4l2_input > >> tvp5146_inputs[] = { > >> +static struct v4l2_input dm644xevm_tvp5146_inputs[] = { > >> { > >> .index = 0, > >> .name = "Composite", > >> @@ -218,7 +218,7 @@ static struct v4l2_input tvp5146_inputs[] = { > >> * ouput that goes to vpfe. There is a one to one correspondence > >> * with tvp5146_inputs > >> */ > >> -static struct vpfe_route tvp5146_routes[] = { > >> +static struct vpfe_route dm644xevm_tvp5146_routes[] = { > >> { > >> .input = INPUT_CVBS_VI2B, > >> .output = OUTPUT_10BIT_422_EMBEDDED_SYNC, @@ -229,13 +229,13 @@ > >> static struct vpfe_route tvp5146_routes[] = { > >> }, > >> }; > >> > >> -static struct vpfe_subdev_info vpfe_sub_devs[] = { > >> +static struct vpfe_subdev_info dm644xevm_vpfe_sub_devs[] = { > >> { > >> .name = "tvp5146", > >> .grp_id = 0, > >> - .num_inputs = ARRAY_SIZE(tvp5146_inputs), > >> - .inputs = tvp5146_inputs, > >> - .routes = tvp5146_routes, > >> + .num_inputs = ARRAY_SIZE(dm644xevm_tvp5146_inputs), > >> + .inputs = dm644xevm_tvp5146_inputs, > >> + .routes = dm644xevm_tvp5146_routes, > >> .can_route = 1, > >> .ccdc_if_params = { > >> .if_type = VPFE_BT656, > >> @@ -244,15 +244,15 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = { > >> }, > >> .board_info = { > >> I2C_BOARD_INFO("tvp5146", 0x5d), > >> - .platform_data = &tvp5146_pdata, > >> + .platform_data = &dm644xevm_tvp5146_pdata, > >> }, > >> }, > >> }; > >> > >> -static struct vpfe_config vpfe_cfg = { > >> - .num_subdevs = ARRAY_SIZE(vpfe_sub_devs), > >> +static struct vpfe_config dm644xevm_capture_cfg = { > >> + .num_subdevs = ARRAY_SIZE(dm644xevm_vpfe_sub_devs), > >> .i2c_adapter_id = 1, > >> - .sub_devs = vpfe_sub_devs, > >> + .sub_devs = dm644xevm_vpfe_sub_devs, > >> .card_name = "DM6446 EVM", > >> .ccdc = "DM6446 CCDC", > >> }; > >> @@ -626,7 +626,7 @@ static void __init > >> davinci_evm_map_io(void) > >> { > >> /* setup input configuration for VPFE input devices */ > >> - dm644x_set_vpfe_config(&vpfe_cfg); > >> + dm644x_set_vpfe_config(&dm644xevm_capture_cfg); > >> dm644x_init(); > >> } > >> > >> diff --git a/arch/arm/mach-davinci/dm644x.c > >> b/arch/arm/mach-davinci/dm644x.c index 97aecf2..acd9ee2 100644 > >> --- a/arch/arm/mach-davinci/dm644x.c > >> +++ b/arch/arm/mach-davinci/dm644x.c > >> @@ -614,7 +614,7 @@ static struct platform_device dm644x_vpss_device = { > >> .resource = dm644x_vpss_resources, > >> }; > >> > >> -static struct resource vpfe_resources[] = { > >> +static struct resource dm644x_vpfe_resources[] = { > >> { > >> .start = IRQ_VDINT0, > >> .end = IRQ_VDINT0, > >> @@ -648,11 +648,11 @@ static struct platform_device dm644x_ccdc_dev = { > >> }, > >> }; > >> > >> -static struct platform_device vpfe_capture_dev = { > >> +static struct platform_device dm644x_vpfe_dev = { > >> .name = CAPTURE_DRV_NAME, > >> .id = -1, > >> - .num_resources = ARRAY_SIZE(vpfe_resources), > >> - .resource = vpfe_resources, > >> + .num_resources = ARRAY_SIZE(dm644x_vpfe_resources), > >> + .resource = dm644x_vpfe_resources, > >> .dev = { > >> .dma_mask = &vpfe_capture_dma_mask, > >> .coherent_dma_mask = DMA_BIT_MASK(32), > >> @@ -661,7 +661,7 @@ static struct platform_device vpfe_capture_dev = > >> { > >> > >> void dm644x_set_vpfe_config(struct vpfe_config *cfg) { > >> - vpfe_capture_dev.dev.platform_data = cfg; > >> + dm644x_vpfe_dev.dev.platform_data = cfg; > >> } > >> > >> > >> /*------------------------------------------------------------------- > >> ---*/ @@ -809,7 +809,7 @@ static int __init dm644x_init_devices(void) > >> > >> platform_device_register(&dm644x_vpss_device); > >> platform_device_register(&dm644x_ccdc_dev); > >> - platform_device_register(&vpfe_capture_dev); > >> + platform_device_register(&dm644x_vpfe_dev); > >> > > Just a suggestion. Why don't we change these with platform_add_devices() API call and register all of the video devices in once call instead of separate calls to platform_device_register? Thak you for the comment. In later patches we have a need to register three subsets of devices - vpfe, vpss and vpbe. So to make things simple, I have used this generic way. I suggest we keep the current format. Thx, -Manju > > >> return 0; > >> } > >> -- > >> 1.6.2.4 > >> > >> _______________________________________________ > >> Davinci-linux-open-source mailing list > >> Davinci-linux-open-source at linux.davincidsp.com > >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > From sshtylyov at mvista.com Wed Jan 4 06:59:13 2012 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Wed, 04 Jan 2012 16:59:13 +0400 Subject: [PATCH v8 1/2] davinci: vpif: remove machine specific header file inclusion from the driver In-Reply-To: <1325661469-4411-2-git-send-email-manjunath.hadli@ti.com> References: <1325661469-4411-1-git-send-email-manjunath.hadli@ti.com> <1325661469-4411-2-git-send-email-manjunath.hadli@ti.com> Message-ID: <4F044D21.1030204@mvista.com> Hello. On 04-01-2012 11:17, Manjunath Hadli wrote: > remove unnecessary inclusion of machine specific header files mach/dm646x.h, > mach/hardware.h from vpif.h and aslo mach/dm646x.h from vpif_display.c > driver which comes in the way of platform code consolidation. > Add linux/i2c.h header file in vpif_types.h which is required for > building. This last modification should be in a separate patch. Don;t mix changes having the different purpose. > Signed-off-by: Manjunath Hadli > Cc: Mauro Carvalho Chehab > Cc: LMML WBR, Sergei From manjunath.hadli at ti.com Wed Jan 4 08:27:38 2012 From: manjunath.hadli at ti.com (Hadli, Manjunath) Date: Wed, 4 Jan 2012 14:27:38 +0000 Subject: [PATCH v8 1/2] davinci: vpif: remove machine specific header file inclusion from the driver In-Reply-To: <4F044D21.1030204@mvista.com> References: <1325661469-4411-1-git-send-email-manjunath.hadli@ti.com> <1325661469-4411-2-git-send-email-manjunath.hadli@ti.com> <4F044D21.1030204@mvista.com> Message-ID: Sergei, On Wed, Jan 04, 2012 at 18:29:13, Sergei Shtylyov wrote: > Hello. > > On 04-01-2012 11:17, Manjunath Hadli wrote: > > > remove unnecessary inclusion of machine specific header files > > mach/dm646x.h, mach/hardware.h from vpif.h and aslo mach/dm646x.h > > from vpif_display.c driver which comes in the way of platform code consolidation. > > Add linux/i2c.h header file in vpif_types.h which is required for > > building. > > This last modification should be in a separate patch. Don;t mix changes having the different purpose. It is part of the same modification of removing the machine specific header. When the header file was removed, it needed the i2c to be included due to a dependency and hence the inclusion. Thx, -Manju > > > Signed-off-by: Manjunath Hadli > > Cc: Mauro Carvalho Chehab > > Cc: LMML > > WBR, Sergei > From manjunath.hadli at ti.com Thu Jan 5 05:24:53 2012 From: manjunath.hadli at ti.com (Hadli, Manjunath) Date: Thu, 5 Jan 2012 11:24:53 +0000 Subject: [GIT PULL] davinci vpbe pull request Message-ID: Hi Mauro, Can you please pull these vpbe patches which add the support for DM365 and DM355 display? The 3 vpbe patches were sent to you as a pull request earlier. Please see this mail: http://linux.omap.com/pipermail/davinci-linux-open-source/2011-November/023496.html I have now rebased these to 3.2 since my earlier pull request was not based on commits on Linus's tree. As a result they look like recent commits, but have actually been around for a long time. Thx, -Manju The following changes since commit 805a6af8dba5dfdd35ec35dc52ec0122400b2610: Linus Torvalds (1): Linux 3.2 are available in the git repository at: git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for-mauro-v3.3 Manjunath Hadli (3): davinci vpbe: add dm365 VPBE display driver changes davinci vpbe: add dm365 and dm355 specific OSD changes davinci vpbe: add VENC block changes to enable dm365 and dm355 drivers/media/video/davinci/vpbe.c | 48 +++- drivers/media/video/davinci/vpbe_osd.c | 473 ++++++++++++++++++++++++++++--- drivers/media/video/davinci/vpbe_venc.c | 205 ++++++++++++-- include/media/davinci/vpbe.h | 16 + include/media/davinci/vpbe_venc.h | 4 + 5 files changed, 678 insertions(+), 68 deletions(-) From jhautbois at gmail.com Thu Jan 5 09:05:44 2012 From: jhautbois at gmail.com (Jean-Michel Hautbois) Date: Thu, 5 Jan 2012 16:05:44 +0100 Subject: DM36x Leopard Board support Message-ID: Hi List, I have a leopard board with a DM368 cpu. I would like to use my own kernel, and not use the ridgerun sdk, for lots of reasons. Is there a support for this board planned in linux-davinci ? I tried to boot with the DM365EVM config, but it is not working in the first try : Error: unrecognized/unsupported machine ID (r1 = 0x00000a59). Available machine support: ID (hex) NAME 00000793 DaVinci DM36x EVM I can understand the reason, and I can of course override the values in order to boot anyway, but if there is a branch (which I didn't find) with support for this board, I woul appreciate it :). Thanks in advance for your answer, Regards, JM From memadrigals at yahoo.es Thu Jan 5 15:51:12 2012 From: memadrigals at yahoo.es (Marco Madrigal) Date: Thu, 5 Jan 2012 21:51:12 +0000 (UTC) Subject: Codec Engine 1.20 and LAD References: <007501c81162$a9bafbd0$3f00a8c0@tieline.com.au> Message-ID: Gary, Scott writes: > > Bernard, > > Sorry for the slow reply. > > LAD was initially created for a specific use case where multiple > independent Linux processes needed to be able to simultaneously access > the DSP, and these processes could come and go in any order at runtime. > LAD was needed because there were some limitations with the DSP/BIOS > Link APIs that required coordination between the different apps, as well > as an ownership model that required the first app to keep alive in order > for the other apps to continue to use the DSP. When LAD is used, LAD is > the "owner" of the DSP, and it handles all the DSP/BIOS Link startup and > shutdown calls that require arbitration between the different apps. > > LAD was left very lightly documented because we've been looking at a few > different options going forward. Today it can be used "under the hood" > by Codec Engine, and the details are abstracted underneath CE's OS > abstraction layer. For CE apps, all that is needed (as you can see in > the speech_copy_LAD example), is to specify in the engine configuration > file: 1) that LAD is to be used, 2) the particular Link configuration to > be used, and 3) the path to the DSP server executable. > > For non-CE apps that want to communicate with LAD, those apps will need > to call the "ladclient" APIs at the appropriate parts of their startup > and shutdown. There is also some work required to define the "common" > Link configuration that will be used for the DSP server, and all the > client Linux apps. > > I will be adding some LAD information to the DaVinci Wiki. In the mean > time, I will send you in a private email a document that describes LAD, > configuration, and usage constraints. > > Please contact me directly if you have questions. > > Regards, > Scott > Hello Scott, I am facing a problem trying to use LAD on an OMAP35x based system. I have been able to built and load the LAD with the following log: Initializing LAD... running LAD config inits... opening FIFO: /tmp/LAD/LADCMDS I want to use LAD in order to get two GStreamer pipelines running together and using the DSP. I already have added the following lines to the GStreamer's engine configuration file: osalGlobal.useLinkArbiter = true; demoEngine.linkCfg= "user0"; But it seems like GStreamer is not using the LAD to access the DSP. In your last email you mention the need of specify the path to the LAD into the configuration file, I am not completely sure about how to specify it, can you help me on this? Do you think the problem I am getting is due to the lack of this path? Regards, Marco From nsekhar at ti.com Fri Jan 6 00:53:09 2012 From: nsekhar at ti.com (Nori, Sekhar) Date: Fri, 6 Jan 2012 06:53:09 +0000 Subject: [PATCH 2/2] ARM: davinci: convert sched_clock() to use common infrastructure In-Reply-To: <20120103090711.GB2914@n2100.arm.linux.org.uk> References: <1324663040-2859-1-git-send-email-nsekhar@ti.com> <1324663040-2859-2-git-send-email-nsekhar@ti.com> <20120103090711.GB2914@n2100.arm.linux.org.uk> Message-ID: Hi Russell, Linus, On Tue, Jan 03, 2012 at 14:37:11, Russell King - ARM Linux wrote: > On Fri, Dec 23, 2011 at 11:27:20PM +0530, Sekhar Nori wrote: > > Convert davinci to use the common sched_clock() infrastructure > > for extending 32bit counters to full 64-bit nanoseconds. > > > > Eventually clocksource timer should be initialized from init_early > > so there would be no need to use a dummy clocksource read at start. > > Please see patch 7205/2. Thanks for the pointers. I rebased this series on latest linux-next and got things working again. I will post updated patches soon. Thanks, Sekhar From sshtylyov at ru.mvista.com Fri Jan 6 12:40:33 2012 From: sshtylyov at ru.mvista.com (Sergei Shtylyov) Date: Fri, 6 Jan 2012 21:40:33 +0300 Subject: [PATCH] DaVinci: can only power up domains on DM644x In-Reply-To: <201109151829.49256.sshtylyov@ru.mvista.com> References: <201109151829.49256.sshtylyov@ru.mvista.com> Message-ID: <201201062140.33712.sshtylyov@ru.mvista.com> Only DM644x has the domain power up procedure documented; for all other SoCs a bootloader probably should have powered the domain up. Print error message and give up if it hasn't done so. Signed-off-by: Sergei Shtylyov --- Sekhar, I haven't forgotten about that patch we discussed, just lacked time... arch/arm/mach-davinci/psc.c | 8 ++++++++ 1 file changed, 8 insertions(+) Index: linux-davinci/arch/arm/mach-davinci/psc.c =================================================================== --- linux-davinci.orig/arch/arm/mach-davinci/psc.c +++ linux-davinci/arch/arm/mach-davinci/psc.c @@ -81,6 +81,14 @@ void davinci_psc_config(unsigned int dom pdstat = __raw_readl(psc_base + PDSTAT + 4 * domain); if ((pdstat & PDSTAT_STATE_MASK) == 0) { + /* Only DM644x has the domain power up procedure documented. */ + if (!cpu_is_davinci_dm644x()) { + pr_err("Don't know how to power on domain %u of PSC%u, " + "probably bootloader should have done this!", + domain, ctlr); + BUG(); + } + pdctl = __raw_readl(psc_base + PDCTL + 4 * domain); pdctl |= PDCTL_NEXT; __raw_writel(pdctl, psc_base + PDCTL + 4 * domain); From sshtylyov at ru.mvista.com Fri Jan 6 12:48:31 2012 From: sshtylyov at ru.mvista.com (Sergei Shtylyov) Date: Fri, 6 Jan 2012 21:48:31 +0300 Subject: [PATCH v2] DaVinci: can only power up domains on DM644x In-Reply-To: <201201062140.33712.sshtylyov@ru.mvista.com> References: <201109151829.49256.sshtylyov@ru.mvista.com> <201201062140.33712.sshtylyov@ru.mvista.com> Message-ID: <201201062148.32025.sshtylyov@ru.mvista.com> Only DM644x has the domain power up procedure documented; for all other SoCs a bootloader probably should have powered the domain up. Print error message and give up if it hasn't done so. Signed-off-by: Sergei Shtylyov --- Duh, forgot a newline in the message! arch/arm/mach-davinci/psc.c | 8 ++++++++ 1 file changed, 8 insertions(+) Index: linux-davinci/arch/arm/mach-davinci/psc.c =================================================================== --- linux-davinci.orig/arch/arm/mach-davinci/psc.c +++ linux-davinci/arch/arm/mach-davinci/psc.c @@ -81,6 +81,14 @@ void davinci_psc_config(unsigned int dom pdstat = __raw_readl(psc_base + PDSTAT + 4 * domain); if ((pdstat & PDSTAT_STATE_MASK) == 0) { + /* Only DM644x has the domain power up procedure documented. */ + if (!cpu_is_davinci_dm644x()) { + pr_err("Don't know how to power on domain %u of PSC%u, " + "probably bootloader should have done this!\n", + domain, ctlr); + BUG(); + } + pdctl = __raw_readl(psc_base + PDCTL + 4 * domain); pdctl |= PDCTL_NEXT; __raw_writel(pdctl, psc_base + PDCTL + 4 * domain); From broonie at opensource.wolfsonmicro.com Fri Jan 6 18:53:50 2012 From: broonie at opensource.wolfsonmicro.com (Mark Brown) Date: Sat, 7 Jan 2012 00:53:50 +0000 Subject: [PATCH v8 2/2] davinci: CQ93VC: remove machine specific header file inclusion from codec driver In-Reply-To: <1325661469-4411-3-git-send-email-manjunath.hadli@ti.com> References: <1325661469-4411-1-git-send-email-manjunath.hadli@ti.com> <1325661469-4411-3-git-send-email-manjunath.hadli@ti.com> Message-ID: <20120107005350.GA26307@sirena.org.uk> On Wed, Jan 04, 2012 at 12:47:49PM +0530, Manjunath Hadli wrote: > remove unnecessary inclusion of machine specific header > file mach/dm365.h from cq93vc.c voice codec driver > which comes in the way of platform code consolidation. *Always* CC maintainers on patches. If you send me a copy directly this looks OK. From manjunath.hadli at ti.com Tue Jan 10 05:27:43 2012 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Tue, 10 Jan 2012 16:57:43 +0530 Subject: [RESEND PATCH] davinci: CQ93VC: remove machine specific header file inclusion from codec driver Message-ID: <1326194863-31194-1-git-send-email-manjunath.hadli@ti.com> remove unnecessary inclusion of machine specific header file mach/dm365.h from cq93vc.c voice codec driver which comes in the way of platform code consolidation. Signed-off-by: Manjunath Hadli Cc: Liam Girdwood Cc: Mark Brown Cc: Jaroslav Kysela CC: Takashi Iwai Cc: Cc: --- sound/soc/codecs/cq93vc.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/cq93vc.c b/sound/soc/codecs/cq93vc.c index 46dbfd0..ff4eb7a 100644 --- a/sound/soc/codecs/cq93vc.c +++ b/sound/soc/codecs/cq93vc.c @@ -38,8 +38,6 @@ #include #include -#include - static inline unsigned int cq93vc_read(struct snd_soc_codec *codec, unsigned int reg) { -- 1.6.2.4 From balbi at ti.com Tue Jan 10 09:26:54 2012 From: balbi at ti.com (Felipe Balbi) Date: Tue, 10 Jan 2012 17:26:54 +0200 Subject: [PATCH 1/1] usb: musb: davinci: fix build breakage In-Reply-To: <8a79643d234d8357b39b513bce73d7b00851f921.1325053572.git.nsekhar@ti.com> References: <8a79643d234d8357b39b513bce73d7b00851f921.1325053572.git.nsekhar@ti.com> Message-ID: <20120110152652.GG4925@legolas.emea.dhcp.ti.com> On Wed, Dec 28, 2011 at 12:02:57PM +0530, Sekhar Nori wrote: > Commit 0020afb369859472a461ef4af6410732e929d402 (ARM: mach-davinci: > remove mach/memory.h) removed mach/memory.h for DaVinci which broke > DaVinci MUSB build. > > mach/memory.h is not actually needed in davinci.c, so remove it. > While at it, also remove some more machine specific inclulde > files which are not needed for build. > > Tested on DM644x EVM using USB card reader. > > Signed-off-by: Sekhar Nori applied, thanks -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From balbi at ti.com Tue Jan 10 09:31:48 2012 From: balbi at ti.com (Felipe Balbi) Date: Tue, 10 Jan 2012 17:31:48 +0200 Subject: [PATCH 1/1] usb: musb: davinci: fix build breakage In-Reply-To: <8a79643d234d8357b39b513bce73d7b00851f921.1325053572.git.nsekhar@ti.com> References: <8a79643d234d8357b39b513bce73d7b00851f921.1325053572.git.nsekhar@ti.com> Message-ID: <20120110153147.GH4925@legolas.emea.dhcp.ti.com> On Wed, Dec 28, 2011 at 12:02:57PM +0530, Sekhar Nori wrote: > Commit 0020afb369859472a461ef4af6410732e929d402 (ARM: mach-davinci: > remove mach/memory.h) removed mach/memory.h for DaVinci which broke > DaVinci MUSB build. > > mach/memory.h is not actually needed in davinci.c, so remove it. > While at it, also remove some more machine specific inclulde > files which are not needed for build. > > Tested on DM644x EVM using USB card reader. > > Signed-off-by: Sekhar Nori applied, thanks > Hopefully this is not too late for v3.2. If it is late, > please apply stable tag for v3.2.x while comitting. > > drivers/usb/musb/davinci.c | 3 --- > 1 files changed, 0 insertions(+), 3 deletions(-) > > diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c > index f9a3f62..7c569f5 100644 > --- a/drivers/usb/musb/davinci.c > +++ b/drivers/usb/musb/davinci.c > @@ -33,9 +33,6 @@ > #include > #include > > -#include > -#include > -#include > #include > > #include > -- > 1.7.0.4 > -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From broonie at opensource.wolfsonmicro.com Tue Jan 10 12:47:41 2012 From: broonie at opensource.wolfsonmicro.com (Mark Brown) Date: Tue, 10 Jan 2012 18:47:41 +0000 Subject: [RESEND PATCH] davinci: CQ93VC: remove machine specific header file inclusion from codec driver In-Reply-To: <1326194863-31194-1-git-send-email-manjunath.hadli@ti.com> References: <1326194863-31194-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <20120110184741.GG7164@opensource.wolfsonmicro.com> On Tue, Jan 10, 2012 at 04:57:43PM +0530, Manjunath Hadli wrote: > remove unnecessary inclusion of machine specific header > file mach/dm365.h from cq93vc.c voice codec driver > which comes in the way of platform code consolidation. Applied but please do try to use a subject line appropriate for the subsystem you're contributing to. From nsekhar at ti.com Wed Jan 11 00:28:41 2012 From: nsekhar at ti.com (Nori, Sekhar) Date: Wed, 11 Jan 2012 06:28:41 +0000 Subject: [PATCH 1/1] usb: musb: davinci: fix build breakage In-Reply-To: <20120110153147.GH4925@legolas.emea.dhcp.ti.com> References: <8a79643d234d8357b39b513bce73d7b00851f921.1325053572.git.nsekhar@ti.com> <20120110153147.GH4925@legolas.emea.dhcp.ti.com> Message-ID: Hi Felipe, On Tue, Jan 10, 2012 at 21:01:48, Balbi, Felipe wrote: > On Wed, Dec 28, 2011 at 12:02:57PM +0530, Sekhar Nori wrote: > > Commit 0020afb369859472a461ef4af6410732e929d402 (ARM: mach-davinci: > > remove mach/memory.h) removed mach/memory.h for DaVinci which broke > > DaVinci MUSB build. > > > > mach/memory.h is not actually needed in davinci.c, so remove it. > > While at it, also remove some more machine specific inclulde > > files which are not needed for build. > > > > Tested on DM644x EVM using USB card reader. > > > > Signed-off-by: Sekhar Nori > > applied, thanks Thanks! I noticed that the commit[1] did not have the stable tag for v3.2. Can you please add Cc: # 3.2.x to the commit? Please ignore if you typically do this just before sending upstream. Regards, Sekhar [1] http://git.kernel.org/?p=linux/kernel/git/balbi/usb.git;a=commit;h=c5b6e4e8481fd73e237fc68023714af910bd87a9 From hs at denx.de Wed Jan 11 02:28:56 2012 From: hs at denx.de (Heiko Schocher) Date: Wed, 11 Jan 2012 09:28:56 +0100 Subject: [PATCH v2] arm, da8xx, mmc: set second MMC controllers default queue In-Reply-To: <1323327357-23886-1-git-send-email-hs@denx.de> References: <1322991210-20486-1-git-send-email-hs@denx.de> <1323327357-23886-1-git-send-email-hs@denx.de> Message-ID: <4F0D4848.4070000@denx.de> Hello, Heiko Schocher wrote: > The MMC driver allocates channels with EVENTQ_DEFAULT, they > get put into EVENTQ_1, which the second EDMA controller does > not have and hence transfers stall. This is fixed > in commit f23fe857bbea393b4b94fe2218c98d934bd3d4cf > "ARM: davinci: Explicitly set channel controllers' default queues" > from Ido Yariv. This patch sets immediately in edma_probe() > the proper default_queue, so this patch does not really fix > something, it is more a cosmetic change. > > Signed-off-by: Heiko Schocher > Signed-off-by: juha.kuikka at gmail.com > Reported-by: juha.kuikka at gmail.com > Acked-by: Rajashekhara, Sudhakar > Cc: linux-mmc at vger.kernel.org > Cc: davinci-linux-open-source at linux.davincidsp.com > Cc: Rajashekhara, Sudhakar > Cc: Ido Yariv > Cc: Sekhar Nori > Cc: Wolfgang Denk > Cc: Sergei Shtylyov > > --- > - changes for v2: > - add comment from Sergei Shtylyov > add in commit message the commit's summary in parens. > - add comment from Ido Yariv: > changed comment and commit message > - added Acked-by from Rajashekhara, Sudhakar > > arch/arm/mach-davinci/dma.c | 10 ++++++---- > 1 files changed, 6 insertions(+), 4 deletions(-) Ping. Can this patch go into mainline, or are there some more objections? Thanks bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany From manjunath.hadli at ti.com Wed Jan 11 05:39:59 2012 From: manjunath.hadli at ti.com (Hadli, Manjunath) Date: Wed, 11 Jan 2012 11:39:59 +0000 Subject: [GIT PULL] davinci vpif pull request Message-ID: Hi Mauro, Can you please pull the following patch which removes some unnecessary inclusion of machine specific header files from the main driver files? This patch has undergone sufficient review already. It is just a cleanup patch and I don't expect any functionality to break because of this. The reason I did not club this with the 3 previous patches was because one of the previous patches on which this is dependent, is now pulled in by Arnd. Thanks and Regards, -Manju The following changes since commit e343a895a9f342f239c5e3c5ffc6c0b1707e6244: Linus Torvalds (1): Merge tag 'for-linus' of git://git.kernel.org/.../mst/vhost are available in the git repository at: git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for-mauro-v3.3 Manjunath Hadli (1): davinci: vpif: remove machine specific header file inclusion from the driver drivers/media/video/davinci/vpif.h | 2 -- drivers/media/video/davinci/vpif_display.c | 2 -- include/media/davinci/vpif_types.h | 2 ++ 3 files changed, 2 insertions(+), 4 deletions(-) From Jon.Povey at racelogic.co.uk Wed Jan 11 05:47:34 2012 From: Jon.Povey at racelogic.co.uk (Jon Povey) Date: Wed, 11 Jan 2012 11:47:34 +0000 Subject: DaVinci unbanked GPIO IRQs broken Message-ID: <70E876B0EA86DD4BAF101844BC814DFE0BF3FFD2EF@Cloud.RL.local> Unbanked GPIO IRQs (I am on DM365) seem to have been broken by commit aac4dd1dab8acfc244d697473d2a5f4424a5746c, conversion to generic irq chip, leading to an oops from request_irq(). Please note I am on kernel 3.0.0-rc7 not the latest, although I tried more recent gpio.c patches to no avail, I think this is probably still broken in 3.2. The problem seems to be with chip_data and chip getting overwritten in davinci_gpio_irq_setup(), this was fixed for banked IRQs but not unbanked. I had a go at fixing the overwrite of chip_data but it still oopses in the same function, irq_gc_mask_set_bit(). Looking at the way gpio_irqchip_unbanked is copied from the irq and modified looks pretty fishy but I am out of time to work on this more (reverting the conversion to generic irq chip works for me). Requesting an IRQ for example IRQ 44 for GPIO 0, I get a backtrace, hopefuly my mail client won't mangle this too badly. Unable to handle kernel paging request at virtual address febfffff pgd = c22dc000 [febfffff] *pgd=00000000 Internal error: Oops: 801 [#1] PREEMPT Modules linked in: mcu(+) edmak irqk cmemk CPU: 0 Not tainted (3.0.0-rc7+ #93) PC is at irq_gc_mask_set_bit+0x68/0x7c LR is at vprintk+0x22c/0x484 pc : [] lr : [] psr: 60000093 sp : c33e3ba0 ip : c33e3af0 fp : c33e3bc4 r10: c04555bc r9 : c33d4340 r8 : 60000013 r7 : 0000002d r6 : c04555bc r5 : fec67010 r4 : 00000000 r3 : c04734c8 r2 : fec00000 r1 : ffffffff r0 : 00000026 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 0005317f Table: 822dc000 DAC: 00000015 Process modprobe (pid: 526, stack limit = 0xc33e2270) Stack: (0xc33e3ba0 to 0xc33e4000) 3ba0: 00000000 c007d3d4 c33e3bcc c04555bc c04555bc c33d4340 c33e3bdc c33e3bc8 3bc0: c007f5f8 c0080bb4 00000000 c04555bc c33e3bf4 c33e3be0 c007f654 c007f5c0 3be0: 00000000 c04555bc c33e3c24 c33e3bf8 c007e6e8 c007f618 c01f2284 c0350af8 3c00: c0405214 bf016c98 00000001 00000000 c33dc008 0000002d c33e3c54 c33e3c28 3c20: c007e888 c007e408 00000001 c23ef880 c33dc000 00000000 c33dc080 c25caa00 3c40: c0487498 bf017078 c33e3c94 c33e3c58 bf016b44 c007e7d4 bf017078 c33dc008 3c60: c25caa08 c33dc008 c33e3c84 bf017484 c25caa00 c25caa00 c01f5f48 c25caa08 3c80: c0496d60 bf017484 c33e3ca4 c33e3c98 c022a698 bf01692c c33e3cd4 c33e3ca8 3ca0: c01f5d88 c022a688 00000000 bf017484 c25caa00 c25caa00 c01f5f48 c25caa08 3cc0: c0496d60 00000000 c33e3cec c33e3cd8 c01f5f8c c01f5d10 00000000 c33e3cf0 3ce0: c33e3d14 c33e3cf0 c01f5210 c01f5f58 c303cb48 c25ecf94 c25caa00 c25caa00 3d00: c25caa34 c33e3dd8 c33e3d34 c33e3d18 c01f6044 c01f51b8 c0496d3c c25caa00 3d20: c044e918 c33e3dd8 c33e3d44 c33e3d38 c01f4ff4 c01f5fcc c33e3d94 c33e3d48 3d40: c01f3d10 c01f4fd8 00000000 c044e918 00000000 00000000 c01f52c0 c034d570 3d60: c33e3d84 c33e3d70 c022bf84 c25caa00 00000000 c044e918 c33e3dd8 c25c2e00 3d80: c0496d60 bf01763c c33e3db4 c33e3d98 c022b1a0 c01f384c c25caa00 c33e3dd8 3da0: 00000000 c33e3dd8 c33e3dd4 c33e3db8 c022b27c c022b0e8 00000000 bf01763c 3dc0: c0451c80 c33e3dd8 c33e3e34 c33e3dd8 bf016f60 c022b210 5f75636d 746e6f63 3de0: 006c6f72 00000000 00000000 00000000 00000000 00000000 00000000 bf0174bc 3e00: 00000000 00989680 00000000 00000020 c0451c80 c0451c80 bf0174dc c01f5eb0 3e20: c33f0f00 bf0174dc c33e3e44 c33e3e38 c01f72f4 bf016e2c c33e3e74 c33e3e48 3e40: c01f5d88 c01f72e4 00000000 c0451c80 c0451cb4 bf0174dc c01f5eb0 c33f0f00 3e60: c0473100 00000000 c33e3e94 c33e3e78 c01f5f44 c01f5d10 00000000 c33e3e98 3e80: bf0174dc c01f5eb0 c33e3ebc c33e3e98 c01f5534 c01f5ec0 c303c038 c3061c30 3ea0: 00003cd8 00098258 bf0174dc c0462ac8 c33e3ecc c33e3ec0 c01f5bec c01f54dc 3ec0: c33e3efc c33e3ed0 c01f4d30 c01f5bdc bf0173a0 c33e2000 00003cd8 00098258 3ee0: bf0174dc c33e2000 c00301a4 bf019000 c33e3f1c c33e3f00 c01f6588 c01f4c8c 3f00: 00003cd8 00098258 00000000 c33e2000 c33e3f2c c33e3f20 c01f777c c01f6524 3f20: c33e3f3c c33e3f30 bf019014 c01f7740 c33e3f7c c33e3f40 c002f3ec bf019010 3f40: 00000000 00003cd8 00098258 bf017518 00000000 00003cd8 00098258 bf017518 3f60: 00000000 c00301a4 c33e2000 00000000 c33e3fa4 c33e3f80 c007b934 c002f3c4 3f80: c00b307c c00b2f48 00003cd8 00000000 00000003 00000080 00000000 c33e3fa8 3fa0: c0030020 c007b8b8 00003cd8 00000000 00098288 00003cd8 00098258 00098240 3fc0: 00003cd8 00000000 00000003 00000080 00098008 00098028 00098288 00000001 3fe0: be892998 be892988 00013d7c 40178740 60000010 00098288 09089041 00200845 Backtrace: [] (irq_gc_mask_set_bit+0x0/0x7c) from [] (irq_enable+0x48/0x58) r6:c33d4340 r5:c04555bc r4:c04555bc [] (irq_enable+0x0/0x58) from [] (irq_startup+0x4c/0x54) r5:c04555bc r4:00000000 [] (irq_startup+0x0/0x54) from [] (__setup_irq+0x2f0/0x3cc) r5:c04555bc r4:00000000 [] (__setup_irq+0x0/0x3cc) from [] (request_threaded_irq+0xc4/0x110) r8:0000002d r7:c33dc008 r6:00000000 r5:00000001 r4:bf016c98 [] (request_threaded_irq+0x0/0x110) from [] (mcu_spi_probe+0x228/0x37c [mcu]) [] (mcu_spi_probe+0x0/0x37c [mcu]) from [] (spi_drv_probe+0x20/0x24) [] (spi_drv_probe+0x0/0x24) from [] (driver_probe_device+0x88/0x1b0) [] (driver_probe_device+0x0/0x1b0) from [] (__device_attach+0x44/0x48) [] (__device_attach+0x0/0x48) from [] (bus_for_each_drv+0x68/0x94) r5:c33e3cf0 r4:00000000 [] (bus_for_each_drv+0x0/0x94) from [] (device_attach+0x88/0xa0) r7:c33e3dd8 r6:c25caa34 r5:c25caa00 r4:c25caa00 [] (device_attach+0x0/0xa0) from [] (bus_probe_device+0x2c/0x4c) r7:c33e3dd8 r6:c044e918 r5:c25caa00 r4:c0496d3c [] (bus_probe_device+0x0/0x4c) from [] (device_add+0x4d4/0x648) [] (device_add+0x0/0x648) from [] (spi_add_device+0xc8/0x128) [] (spi_add_device+0x0/0x128) from [] (spi_new_device+0x7c/0xb4) r7:c33e3dd8 r6:00000000 r5:c33e3dd8 r4:c25caa00 [] (spi_new_device+0x0/0xb4) from [] (mcu_probe+0x144/0x224 [mcu]) r7:c33e3dd8 r6:c0451c80 r5:bf01763c r4:00000000 [] (mcu_probe+0x0/0x224 [mcu]) from [] (platform_drv_probe+0x20/0x24) [] (platform_drv_probe+0x0/0x24) from [] (driver_probe_device+0x88/0x1b0) [] (driver_probe_device+0x0/0x1b0) from [] (__driver_attach+0x94/0x98) [] (__driver_attach+0x0/0x98) from [] (bus_for_each_dev+0x68/0x94) r7:c01f5eb0 r6:bf0174dc r5:c33e3e98 r4:00000000 [] (bus_for_each_dev+0x0/0x94) from [] (driver_attach+0x20/0x28) r7:c0462ac8 r6:bf0174dc r5:00098258 r4:00003cd8 [] (driver_attach+0x0/0x28) from [] (bus_add_driver+0xb4/0x258) [] (bus_add_driver+0x0/0x258) from [] (driver_register+0x74/0x158) [] (driver_register+0x0/0x158) from [] (platform_driver_register+0x4c/0x60) r7:c33e2000 r6:00000000 r5:00098258 r4:00003cd8 [] (platform_driver_register+0x0/0x60) from [] (mcu_init+0x14/0x20 [mcu]) [] (mcu_init+0x0/0x20 [mcu]) from [] (do_one_initcall+0x38/0x170) [] (do_one_initcall+0x0/0x170) from [] (sys_init_module+0x8c/0x1a4) [] (sys_init_module+0x0/0x1a4) from [] (ret_fast_syscall+0x0/0x2c) r7:00000080 r6:00000003 r5:00000000 r4:00003cd8 Code: e1844003 e585400c e596300c e5932064 (e7814002) ---[ end trace 1820e9849d265227 ]--- note: modprobe[526] exited with preempt_count 1 BUG: scheduling while atomic: modprobe/526/0x40000002 Modules linked in: mcu(+) edmak irqk cmemk Backtrace: [] (dump_backtrace+0x0/0x10c) from [] (dump_stack+0x18/0x1c) r7:0008d000 r6:c25cf600 r5:0008d000 r4:00000000 [] (dump_stack+0x0/0x1c) from [] (__schedule_bug+0x54/0x60) [] (__schedule_bug+0x0/0x60) from [] (schedule+0x320/0x460) r5:0008d000 r4:00000000 [] (schedule+0x0/0x460) from [] (__cond_resched+0x18/0x24) [] (__cond_resched+0x0/0x24) from [] (_cond_resched+0x3c/0x44) [] (_cond_resched+0x0/0x44) from [] (unmap_vmas+0x2bc/0x64c) [] (unmap_vmas+0x0/0x64c) from [] (exit_mmap+0x134/0x2d0) [] (exit_mmap+0x0/0x2d0) from [] (mmput+0x40/0xf8) [] (mmput+0x0/0xf8) from [] (exit_mm+0x154/0x1b8) r5:c2aa9a80 r4:c25cf600 [] (exit_mm+0x0/0x1b8) from [] (do_exit+0x590/0x750) r7:c03e78f8 r6:00000801 r5:c33e2000 r4:0000000b [] (do_exit+0x0/0x750) from [] (die+0x1bc/0x1e4) [] (die+0x0/0x1e4) from [] (__do_kernel_fault+0x6c/0x8c) [] (__do_kernel_fault+0x0/0x8c) from [] (do_bad_area+0x48/0x70) r9:bf000000 r8:00000000 r7:00000000 r6:e7814002 r5:c04732f8 r4:fec00000 [] (do_bad_area+0x0/0x70) from [] (do_alignment+0xf4/0x748) [] (do_alignment+0x0/0x748) from [] (do_DataAbort+0x3c/0xa0) [] (do_DataAbort+0x0/0xa0) from [] (__dabt_svc+0x4c/0x60) Exception stack(0xc33e3b58 to 0xc33e3ba0) 3b40: 00000026 ffffffff 3b60: fec00000 c04734c8 00000000 fec67010 c04555bc 0000002d 60000013 c33d4340 3b80: c04555bc c33e3bc4 c33e3af0 c33e3ba0 c00457e0 c0080c0c 60000093 ffffffff r8:60000013 r7:0000002d r6:c04555bc r5:c33e3b8c r4:ffffffff [] (irq_gc_mask_set_bit+0x0/0x7c) from [] (irq_enable+0x48/0x58) r6:c33d4340 r5:c04555bc r4:c04555bc [] (irq_enable+0x0/0x58) from [] (irq_startup+0x4c/0x54) r5:c04555bc r4:00000000 [] (irq_startup+0x0/0x54) from [] (__setup_irq+0x2f0/0x3cc) r5:c04555bc r4:00000000 [] (__setup_irq+0x0/0x3cc) from [] (request_threaded_irq+0xc4/0x110) r8:0000002d r7:c33dc008 r6:00000000 r5:00000001 r4:bf016c98 [] (request_threaded_irq+0x0/0x110) from [] (mcu_spi_probe+0x228/0x37c [mcu]) [] (mcu_spi_probe+0x0/0x37c [mcu]) from [] (spi_drv_probe+0x20/0x24) [] (spi_drv_probe+0x0/0x24) from [] (driver_probe_device+0x88/0x1b0) [] (driver_probe_device+0x0/0x1b0) from [] (__device_attach+0x44/0x48) [] (__device_attach+0x0/0x48) from [] (bus_for_each_drv+0x68/0x94) r5:c33e3cf0 r4:00000000 [] (bus_for_each_drv+0x0/0x94) from [] (device_attach+0x88/0xa0) r7:c33e3dd8 r6:c25caa34 r5:c25caa00 r4:c25caa00 [] (device_attach+0x0/0xa0) from [] (bus_probe_device+0x2c/0x4c) r7:c33e3dd8 r6:c044e918 r5:c25caa00 r4:c0496d3c [] (bus_probe_device+0x0/0x4c) from [] (device_add+0x4d4/0x648) [] (device_add+0x0/0x648) from [] (spi_add_device+0xc8/0x128) [] (spi_add_device+0x0/0x128) from [] (spi_new_device+0x7c/0xb4) r7:c33e3dd8 r6:00000000 r5:c33e3dd8 r4:c25caa00 [] (spi_new_device+0x0/0xb4) from [] (mcu_probe+0x144/0x224 [mcu]) r7:c33e3dd8 r6:c0451c80 r5:bf01763c r4:00000000 [] (mcu_probe+0x0/0x224 [mcu]) from [] (platform_drv_probe+0x20/0x24) [] (platform_drv_probe+0x0/0x24) from [] (driver_probe_device+0x88/0x1b0) [] (driver_probe_device+0x0/0x1b0) from [] (__driver_attach+0x94/0x98) [] (__driver_attach+0x0/0x98) from [] (bus_for_each_dev+0x68/0x94) r7:c01f5eb0 r6:bf0174dc r5:c33e3e98 r4:00000000 [] (bus_for_each_dev+0x0/0x94) from [] (driver_attach+0x20/0x28) r7:c0462ac8 r6:bf0174dc r5:00098258 r4:00003cd8 [] (driver_attach+0x0/0x28) from [] (bus_add_driver+0xb4/0x258) [] (bus_add_driver+0x0/0x258) from [] (driver_register+0x74/0x158) [] (driver_register+0x0/0x158) from [] (platform_driver_register+0x4c/0x60) r7:c33e2000 r6:00000000 r5:00098258 r4:00003cd8 [] (platform_driver_register+0x0/0x60) from [] (mcu_init+0x14/0x20 [mcu]) [] (mcu_init+0x0/0x20 [mcu]) from [] (do_one_initcall+0x38/0x170) [] (do_one_initcall+0x0/0x170) from [] (sys_init_module+0x8c/0x1a4) [] (sys_init_module+0x0/0x1a4) from [] (ret_fast_syscall+0x0/0x2c) r7:00000080 r6:00000003 r5:00000000 r4:00003cd8 BUG: scheduling while atomic: modprobe/526/0x40000002 Modules linked in: mcu(+) edmak irqk cmemk Backtrace: [] (dump_backtrace+0x0/0x10c) from [] (dump_stack+0x18/0x1c) r7:00000000 r6:c25cf600 r5:00000007 r4:00000000 [] (dump_stack+0x0/0x1c) from [] (__schedule_bug+0x54/0x60) [] (__schedule_bug+0x0/0x60) from [] (schedule+0x320/0x460) r5:00000007 r4:00000000 [] (schedule+0x0/0x460) from [] (__cond_resched+0x18/0x24) [] (__cond_resched+0x0/0x24) from [] (_cond_resched+0x3c/0x44) [] (_cond_resched+0x0/0x44) from [] (put_files_struct+0xd0/0xf0) [] (put_files_struct+0x0/0xf0) from [] (exit_files+0x64/0x68) [] (exit_files+0x0/0x68) from [] (do_exit+0x5a0/0x750) r5:c33e2000 r4:0000000b [] (do_exit+0x0/0x750) from [] (die+0x1bc/0x1e4) [] (die+0x0/0x1e4) from [] (__do_kernel_fault+0x6c/0x8c) [] (__do_kernel_fault+0x0/0x8c) from [] (do_bad_area+0x48/0x70) r9:bf000000 r8:00000000 r7:00000000 r6:e7814002 r5:c04732f8 r4:fec00000 [] (do_bad_area+0x0/0x70) from [] (do_alignment+0xf4/0x748) [] (do_alignment+0x0/0x748) from [] (do_DataAbort+0x3c/0xa0) [] (do_DataAbort+0x0/0xa0) from [] (__dabt_svc+0x4c/0x60) Exception stack(0xc33e3b58 to 0xc33e3ba0) 3b40: 00000026 ffffffff 3b60: fec00000 c04734c8 00000000 fec67010 c04555bc 0000002d 60000013 c33d4340 3b80: c04555bc c33e3bc4 c33e3af0 c33e3ba0 c00457e0 c0080c0c 60000093 ffffffff r8:60000013 r7:0000002d r6:c04555bc r5:c33e3b8c r4:ffffffff [] (irq_gc_mask_set_bit+0x0/0x7c) from [] (irq_enable+0x48/0x58) r6:c33d4340 r5:c04555bc r4:c04555bc [] (irq_enable+0x0/0x58) from [] (irq_startup+0x4c/0x54) r5:c04555bc r4:00000000 [] (irq_startup+0x0/0x54) from [] (__setup_irq+0x2f0/0x3cc) r5:c04555bc r4:00000000 [] (__setup_irq+0x0/0x3cc) from [] (request_threaded_irq+0xc4/0x110) r8:0000002d r7:c33dc008 r6:00000000 r5:00000001 r4:bf016c98 [] (request_threaded_irq+0x0/0x110) from [] (mcu_spi_probe+0x228/0x37c [mcu]) [] (mcu_spi_probe+0x0/0x37c [mcu]) from [] (spi_drv_probe+0x20/0x24) [] (spi_drv_probe+0x0/0x24) from [] (driver_probe_device+0x88/0x1b0) [] (driver_probe_device+0x0/0x1b0) from [] (__device_attach+0x44/0x48) [] (__device_attach+0x0/0x48) from [] (bus_for_each_drv+0x68/0x94) r5:c33e3cf0 r4:00000000 [] (bus_for_each_drv+0x0/0x94) from [] (device_attach+0x88/0xa0) r7:c33e3dd8 r6:c25caa34 r5:c25caa00 r4:c25caa00 [] (device_attach+0x0/0xa0) from [] (bus_probe_device+0x2c/0x4c) r7:c33e3dd8 r6:c044e918 r5:c25caa00 r4:c0496d3c [] (bus_probe_device+0x0/0x4c) from [] (device_add+0x4d4/0x648) [] (device_add+0x0/0x648) from [] (spi_add_device+0xc8/0x128) [] (spi_add_device+0x0/0x128) from [] (spi_new_device+0x7c/0xb4) r7:c33e3dd8 r6:00000000 r5:c33e3dd8 r4:c25caa00 [] (spi_new_device+0x0/0xb4) from [] (mcu_probe+0x144/0x224 [mcu]) r7:c33e3dd8 r6:c0451c80 r5:bf01763c r4:00000000 [] (mcu_probe+0x0/0x224 [mcu]) from [] (platform_drv_probe+0x20/0x24) [] (platform_drv_probe+0x0/0x24) from [] (driver_probe_device+0x88/0x1b0) [] (driver_probe_device+0x0/0x1b0) from [] (__driver_attach+0x94/0x98) [] (__driver_attach+0x0/0x98) from [] (bus_for_each_dev+0x68/0x94) r7:c01f5eb0 r6:bf0174dc r5:c33e3e98 r4:00000000 [] (bus_for_each_dev+0x0/0x94) from [] (driver_attach+0x20/0x28) r7:c0462ac8 r6:bf0174dc r5:00098258 r4:00003cd8 [] (driver_attach+0x0/0x28) from [] (bus_add_driver+0xb4/0x258) [] (bus_add_driver+0x0/0x258) from [] (driver_register+0x74/0x158) [] (driver_register+0x0/0x158) from [] (platform_driver_register+0x4c/0x60) r7:c33e2000 r6:00000000 r5:00098258 r4:00003cd8 [] (platform_driver_register+0x0/0x60) from [] (mcu_init+0x14/0x20 [mcu]) [] (mcu_init+0x0/0x20 [mcu]) from [] (do_one_initcall+0x38/0x170) [] (do_one_initcall+0x0/0x170) from [] (sys_init_module+0x8c/0x1a4) [] (sys_init_module+0x0/0x1a4) from [] (ret_fast_syscall+0x0/0x2c) r7:00000080 r6:00000003 r5:00000000 r4:00003cd8 -- Jon Povey jon.povey at racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network From mosin.t at gmail.com Wed Jan 11 08:53:12 2012 From: mosin.t at gmail.com (Simon Therriault) Date: Wed, 11 Jan 2012 09:53:12 -0500 Subject: spi kernel crash Message-ID: Hi, I'm running a linux kernel 2.6.34 on a TI AM1808 and I just started to encounter several kernel crashes in spi_davinci module. During boot up, several spi transmissions are done and everything has been fine for a while. Now, the cpu load has augmented a lot and since then, I often get kernel crashes. With the stack trace, I could track down that the last function called is bitbang_work(spi_bitbang.c) and I think it crashes during list_del_init because of a bad entry in the queue. But that's only a guess... I was wondering if anyone has ever encountered this or has any idea what could cause this. I copy pasted a short portion of the kernel oops below. Thanks *********************************************************************** *spi: Unable to send spi message: Operation now in progress* *IOCTL returned -1* *Unable to handle kernel NULL pointer dereference at virtual address 00000021* *pgd = c7df8000* *[00000021] *pgd=c7de4031, *pte=00000000, *ppte=00000000* *Internal error: Oops: 801 [#1] PREEMPT* *CPU: 0 Not tainted (2.6.34-svn632 #24)* *pc : [] lr : [] psr: 20000093* *sp : c7cfbf48 ip : c7cfbf88 fp : c7cfbf84* *r10: c7cf12d0 r9 : 00000000 r8 : c7cfa000* *r7 : c7e17eb4 r6 : c7e17e94 r5 : c7cf12d4 r4 : c7cf12d8* *r3 : 0000001d r2 : c7e17f18 r1 : 60000013 r0 : c7cf12e4* *Process spi_davinci.1 (pid: 17, stack limit = 0xc7cfa270)* *********************************************************************** -- Simon Therriault -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsekhar at ti.com Thu Jan 12 03:19:44 2012 From: nsekhar at ti.com (Nori, Sekhar) Date: Thu, 12 Jan 2012 09:19:44 +0000 Subject: [PATCH v2] arm, da8xx, mmc: set second MMC controllers default queue In-Reply-To: <4F0D4848.4070000@denx.de> References: <1322991210-20486-1-git-send-email-hs@denx.de> <1323327357-23886-1-git-send-email-hs@denx.de> <4F0D4848.4070000@denx.de> Message-ID: Hi Heiko, On Wed, Jan 11, 2012 at 13:58:56, Heiko Schocher wrote: > Hello, > > Heiko Schocher wrote: > > The MMC driver allocates channels with EVENTQ_DEFAULT, they > > get put into EVENTQ_1, which the second EDMA controller does > > not have and hence transfers stall. This is fixed > > in commit f23fe857bbea393b4b94fe2218c98d934bd3d4cf > > "ARM: davinci: Explicitly set channel controllers' default queues" > > from Ido Yariv. This patch sets immediately in edma_probe() > > the proper default_queue, so this patch does not really fix > > something, it is more a cosmetic change. > > > > Signed-off-by: Heiko Schocher > > Signed-off-by: juha.kuikka at gmail.com > > Reported-by: juha.kuikka at gmail.com > > Acked-by: Rajashekhara, Sudhakar > > Cc: linux-mmc at vger.kernel.org > > Cc: davinci-linux-open-source at linux.davincidsp.com > > Cc: Rajashekhara, Sudhakar > > Cc: Ido Yariv > > Cc: Sekhar Nori > > Cc: Wolfgang Denk > > Cc: Sergei Shtylyov > > > > --- > > - changes for v2: > > - add comment from Sergei Shtylyov > > add in commit message the commit's summary in parens. > > - add comment from Ido Yariv: > > changed comment and commit message > > - added Acked-by from Rajashekhara, Sudhakar > > > > arch/arm/mach-davinci/dma.c | 10 ++++++---- > > 1 files changed, 6 insertions(+), 4 deletions(-) > > Ping. Can this patch go into mainline, or are there some more objections? Hmm, looks like you asking "no need for applying my patch" in an earlier e-mail on this topic made me discard this. I had a look and the patch is OK. Except, I think the comment can do better without reference to TC1 since its not relevant once the code has been fixed. Also, the comment is better placed in edma.h where near the default_queue member definition since that's where folks will look up when setting up the default queue. So, the comment can simply be: + /* + * Default queue is expected to be a low-priority queue. + * This way, long transfers on the default queue started + * by the codec engine will not cause audio defects. Similarly you can drop references to the MMC/SD issue and the fix in the commit text since its not directly relevant to your patch. Can you fix this up so I can apply it? Please note that patches for mach-davinci should be pre-fixed with "ARM: davinci: ". Also Cc linux-arm-kernel at lists.infradead.org on ARM patch submissions. Thanks, Sekhar From m-karicheri2 at ti.com Thu Jan 12 06:00:15 2012 From: m-karicheri2 at ti.com (Karicheri, Muralidharan) Date: Thu, 12 Jan 2012 12:00:15 +0000 Subject: [PATCH v2] DaVinci: can only power up domains on DM644x In-Reply-To: <201201062148.32025.sshtylyov@ru.mvista.com> References: <201109151829.49256.sshtylyov@ru.mvista.com> <201201062140.33712.sshtylyov@ru.mvista.com> <201201062148.32025.sshtylyov@ru.mvista.com> Message-ID: <3E54258959B69E4282D79E01AB1F32B7265471@DFLE34.ent.ti.com> Sekhar & Sergei, This will affect the new SoCs that have capabilities to power up different domains. Why do we need this enforcement? We are working on a DaVinci variant SoC that can do power up multiple domains (That is why I had a patch earlier to support Multiple PD which is already part of the tree). So I don't want this patch to go through unless I see a reason for pushing this. Murali Karicheri Software Design Engineer email: m-karicheri2 at ti.com >> -----Original Message----- >> From: davinci-linux-open-source-bounces at linux.davincidsp.com >> [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf >> Of Sergei Shtylyov >> Sent: Friday, January 06, 2012 1:49 PM >> To: davinci-linux-open-source at linux.davincidsp.com; Nori, Sekhar; linux- >> arm-kernel at lists.infradead.org >> Subject: [PATCH v2] DaVinci: can only power up domains on DM644x >> >> Only DM644x has the domain power up procedure documented; for all other >> SoCs a >> bootloader probably should have powered the domain up. Print error message >> and >> give up if it hasn't done so. >> >> Signed-off-by: Sergei Shtylyov >> >> --- >> Duh, forgot a newline in the message! >> >> arch/arm/mach-davinci/psc.c | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> Index: linux-davinci/arch/arm/mach-davinci/psc.c >> =================================================================== >> --- linux-davinci.orig/arch/arm/mach-davinci/psc.c >> +++ linux-davinci/arch/arm/mach-davinci/psc.c >> @@ -81,6 +81,14 @@ void davinci_psc_config(unsigned int dom >> >> pdstat = __raw_readl(psc_base + PDSTAT + 4 * domain); >> if ((pdstat & PDSTAT_STATE_MASK) == 0) { >> + /* Only DM644x has the domain power up procedure documented. >> */ >> + if (!cpu_is_davinci_dm644x()) { >> + pr_err("Don't know how to power on domain %u of PSC%u, " >> + "probably bootloader should have done this!\n", >> + domain, ctlr); >> + BUG(); >> + } >> + >> pdctl = __raw_readl(psc_base + PDCTL + 4 * domain); >> pdctl |= PDCTL_NEXT; >> __raw_writel(pdctl, psc_base + PDCTL + 4 * domain); >> _______________________________________________ >> Davinci-linux-open-source mailing list >> Davinci-linux-open-source at linux.davincidsp.com >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source From nsekhar at ti.com Fri Jan 13 04:56:04 2012 From: nsekhar at ti.com (Nori, Sekhar) Date: Fri, 13 Jan 2012 10:56:04 +0000 Subject: DaVinci unbanked GPIO IRQs broken In-Reply-To: <70E876B0EA86DD4BAF101844BC814DFE0BF3FFD2EF@Cloud.RL.local> References: <70E876B0EA86DD4BAF101844BC814DFE0BF3FFD2EF@Cloud.RL.local> Message-ID: Hi Jon, On Wed, Jan 11, 2012 at 17:17:34, Jon Povey wrote: > Unbanked GPIO IRQs (I am on DM365) seem to have been broken > by commit aac4dd1dab8acfc244d697473d2a5f4424a5746c, conversion > to generic irq chip, leading to an oops from request_irq(). > > Please note I am on kernel 3.0.0-rc7 not the latest, although > I tried more recent gpio.c patches to no avail, I think this is > probably still broken in 3.2. Yes, I was able to reproduce it on my 3.2-rc6 based branch. > > The problem seems to be with chip_data and chip getting overwritten > in davinci_gpio_irq_setup(), this was fixed for banked IRQs but not > unbanked. I had a go at fixing the overwrite of chip_data but it > still oopses in the same function, irq_gc_mask_set_bit(). The root cause indeed seems to be chip_data getting overwritten. I made a patch for it and was able to test that requesting IRQ number 44 doesn't oops. Yet to figure out if there is an easy way to trigger an unbanked GPIO IRQ on the EVM, so a large part of the patch is actually untested. Anyway, can you give this patch a shot (hopefully not mailer mangled)? I don't like the fact that it increases davinci_soc_info usage, but first lets see if it fixes the issue. Thanks, Sekhar ------8<------------------------ From: Sekhar Nori Date: Fri, 13 Jan 2012 15:55:35 +0530 Subject: [PATCH] gpio/davinci: fix unbanked gpio irq handling Unbanked GPIO irq setup code was overwriting chip_data leading to oops on request_irq() Fix the issue. Reported-by: Jon Povey Signed-off-by: Sekhar Nori --- drivers/gpio/gpio-davinci.c | 15 ++++++++++----- 1 files changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c index df0d595..a6777e5 100644 --- a/drivers/gpio/gpio-davinci.c +++ b/drivers/gpio/gpio-davinci.c @@ -313,10 +313,16 @@ static int gpio_to_irq_unbanked(struct gpio_chip *chip, unsigned offset) return -ENODEV; } -static int gpio_irq_type_unbanked(struct irq_data *d, unsigned trigger) +static int gpio_irq_type_unbanked(struct irq_data *data, unsigned trigger) { - struct davinci_gpio_regs __iomem *g = irq2regs(d->irq); - u32 mask = (u32) irq_data_get_irq_handler_data(d); + struct davinci_gpio_controller *d; + struct davinci_gpio_regs __iomem *g; + struct davinci_soc_info *soc_info = &davinci_soc_info; + u32 mask; + + d = (struct davinci_gpio_controller *)data->handler_data; + g = (struct davinci_gpio_regs __iomem *)d->regs; + mask = __gpio_mask(data->irq - soc_info->gpio_irq); if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING)) return -EINVAL; @@ -400,8 +406,7 @@ static int __init davinci_gpio_irq_setup(void) /* set the direct IRQs up to use that irqchip */ for (gpio = 0; gpio < soc_info->gpio_unbanked; gpio++, irq++) { irq_set_chip(irq, &gpio_irqchip_unbanked); - irq_set_handler_data(irq, (void *)__gpio_mask(gpio)); - irq_set_chip_data(irq, (__force void *)g); + irq_set_handler_data(irq, &chips[gpio / 32]); irq_set_status_flags(irq, IRQ_TYPE_EDGE_BOTH); } -- From b.van.den.berg.nl at gmail.com Fri Jan 13 06:48:13 2012 From: b.van.den.berg.nl at gmail.com (Bas van den Berg) Date: Fri, 13 Jan 2012 13:48:13 +0100 Subject: [PATCH] ARM: mach-davinci: removed un-existing pll1_sysclk4-7 clock domains Message-ID: <20120113124811.GA9223@altenpts-laptop> sysclk4-7 only exist for pll0. for pll1 sysclk1-3 exist. Signed-off-by: Bas van den Berg --- arch/arm/mach-davinci/da850.c | 32 -------------------------------- 1 files changed, 0 insertions(+), 32 deletions(-) diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c index 0ed7fdb..992c4c4 100644 --- a/arch/arm/mach-davinci/da850.c +++ b/arch/arm/mach-davinci/da850.c @@ -153,34 +153,6 @@ static struct clk pll1_sysclk3 = { .div_reg = PLLDIV3, }; -static struct clk pll1_sysclk4 = { - .name = "pll1_sysclk4", - .parent = &pll1_clk, - .flags = CLK_PLL, - .div_reg = PLLDIV4, -}; - -static struct clk pll1_sysclk5 = { - .name = "pll1_sysclk5", - .parent = &pll1_clk, - .flags = CLK_PLL, - .div_reg = PLLDIV5, -}; - -static struct clk pll1_sysclk6 = { - .name = "pll0_sysclk6", - .parent = &pll0_clk, - .flags = CLK_PLL, - .div_reg = PLLDIV6, -}; - -static struct clk pll1_sysclk7 = { - .name = "pll1_sysclk7", - .parent = &pll1_clk, - .flags = CLK_PLL, - .div_reg = PLLDIV7, -}; - static struct clk i2c0_clk = { .name = "i2c0", .parent = &pll0_aux_clk, @@ -397,10 +369,6 @@ static struct clk_lookup da850_clks[] = { CLK(NULL, "pll1_aux", &pll1_aux_clk), CLK(NULL, "pll1_sysclk2", &pll1_sysclk2), CLK(NULL, "pll1_sysclk3", &pll1_sysclk3), - CLK(NULL, "pll1_sysclk4", &pll1_sysclk4), - CLK(NULL, "pll1_sysclk5", &pll1_sysclk5), - CLK(NULL, "pll1_sysclk6", &pll1_sysclk6), - CLK(NULL, "pll1_sysclk7", &pll1_sysclk7), CLK("i2c_davinci.1", NULL, &i2c0_clk), CLK(NULL, "timer0", &timerp64_0_clk), CLK("watchdog", NULL, &timerp64_1_clk), -- 1.7.0.4 From sshtylyov at mvista.com Fri Jan 13 09:52:02 2012 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Fri, 13 Jan 2012 18:52:02 +0300 Subject: [PATCH] ARM: mach-davinci: removed un-existing pll1_sysclk4-7 clock domains In-Reply-To: <20120113124811.GA9223@altenpts-laptop> References: <20120113124811.GA9223@altenpts-laptop> Message-ID: <4F105322.3030206@mvista.com> Hello. On 01/13/2012 03:48 PM, Bas van den Berg wrote: > sysclk4-7 only exist for pll0. for pll1 sysclk1-3 exist. You should have marked (in the subject and here) that you're doing this for DA850 only. > Signed-off-by: Bas van den Berg WBR, Sergei From b.van.den.berg.nl at gmail.com Mon Jan 16 00:46:02 2012 From: b.van.den.berg.nl at gmail.com (Bas van den Berg) Date: Mon, 16 Jan 2012 07:46:02 +0100 Subject: [PATCH] ARM: mach-davinci DA850: removed un-existing pll1_sysclk4-7 clock domains Message-ID: <20120116064559.GA3025@altenpts-laptop> DA850: sysclk4-7 only exist for pll0. for pll1 sysclk1-3 exist. Signed-off-by: Bas van den Berg --- arch/arm/mach-davinci/da850.c | 32 -------------------------------- 1 files changed, 0 insertions(+), 32 deletions(-) diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c index 0ed7fdb..992c4c4 100644 --- a/arch/arm/mach-davinci/da850.c +++ b/arch/arm/mach-davinci/da850.c @@ -153,34 +153,6 @@ static struct clk pll1_sysclk3 = { .div_reg = PLLDIV3, }; -static struct clk pll1_sysclk4 = { - .name = "pll1_sysclk4", - .parent = &pll1_clk, - .flags = CLK_PLL, - .div_reg = PLLDIV4, -}; - -static struct clk pll1_sysclk5 = { - .name = "pll1_sysclk5", - .parent = &pll1_clk, - .flags = CLK_PLL, - .div_reg = PLLDIV5, -}; - -static struct clk pll1_sysclk6 = { - .name = "pll0_sysclk6", - .parent = &pll0_clk, - .flags = CLK_PLL, - .div_reg = PLLDIV6, -}; - -static struct clk pll1_sysclk7 = { - .name = "pll1_sysclk7", - .parent = &pll1_clk, - .flags = CLK_PLL, - .div_reg = PLLDIV7, -}; - static struct clk i2c0_clk = { .name = "i2c0", .parent = &pll0_aux_clk, @@ -397,10 +369,6 @@ static struct clk_lookup da850_clks[] = { CLK(NULL, "pll1_aux", &pll1_aux_clk), CLK(NULL, "pll1_sysclk2", &pll1_sysclk2), CLK(NULL, "pll1_sysclk3", &pll1_sysclk3), - CLK(NULL, "pll1_sysclk4", &pll1_sysclk4), - CLK(NULL, "pll1_sysclk5", &pll1_sysclk5), - CLK(NULL, "pll1_sysclk6", &pll1_sysclk6), - CLK(NULL, "pll1_sysclk7", &pll1_sysclk7), CLK("i2c_davinci.1", NULL, &i2c0_clk), CLK(NULL, "timer0", &timerp64_0_clk), CLK("watchdog", NULL, &timerp64_1_clk), -- 1.7.0.4 From Jon.Povey at racelogic.co.uk Mon Jan 16 03:20:03 2012 From: Jon.Povey at racelogic.co.uk (Jon Povey) Date: Mon, 16 Jan 2012 09:20:03 +0000 Subject: DaVinci unbanked GPIO IRQs broken In-Reply-To: Message-ID: <70E876B0EA86DD4BAF101844BC814DFE0BF403D9FD@Cloud.RL.local> Nori, Sekhar wrote: > On Wed, Jan 11, 2012 at 17:17:34, Jon Povey wrote: >> Unbanked GPIO IRQs (I am on DM365) seem to have been broken >> by commit aac4dd1dab8acfc244d697473d2a5f4424a5746c, conversion >> to generic irq chip, leading to an oops from request_irq(). > The root cause indeed seems to be chip_data getting > overwritten. > > I made a patch for it and was able to test that requesting IRQ > number 44 doesn't oops. Yet to figure out if there is an easy way > to trigger an unbanked GPIO IRQ on the EVM, so a large part of > the patch is actually untested. Anyway, can you give this patch > a shot (hopefully not mailer mangled)? I don't like the fact that > it increases davinci_soc_info usage, but first lets see if it fixes > the issue. gpio_export(n, 1) and using sysfs to set the gpio to output can be used to test. Tried quickly rebasing my stuff to 3.2, your patch fixes the oops, but the interrupt does not trigger. I don't have time to investigate why not right now, sorry. But I did try reverting the genirq change too, and the interrupt handler still wasn't called, so maybe something else broke somewhere, or it could be something needs updating in my board support. I tried applying this patch (modulo gpio path change) to my 3.0-rc7 base with the genirq stuff left in. I still get an oops and backtrace when requesting the irq! If this is clearer: 3.2 vanilla: oops requesting irq 3.2 + your patch: no oops, isr is not run 3.2 + reverted genirq: no oops, isr is not run 3.0-rc7: oops requesting irq 3.0-rc7 + your patch: oops requesting irq 3.0-rc7 + reverted genirq: no oops, isr works -- Jon Povey jon.povey at racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network From Jon.Povey at racelogic.co.uk Mon Jan 16 05:38:30 2012 From: Jon.Povey at racelogic.co.uk (Jon Povey) Date: Mon, 16 Jan 2012 11:38:30 +0000 Subject: DaVinci unbanked GPIO IRQs broken Message-ID: <70E876B0EA86DD4BAF101844BC814DFE0BF403DA89@Cloud.RL.local> Sorry, last email had some lies, I had testing errors: Jon Povey wrote: > But I did try reverting the genirq change too, and > the interrupt handler still wasn't called This was incorrect, interrupt DOES work with genirq reverted on 3.2. > 3.2 vanilla: oops requesting irq > 3.2 + your patch: no oops, isr is not run These are still the case > 3.2 + reverted genirq: no oops, isr is not run This was incorrect, real result is: no oops, isr WORKS. (with or without your patch). -- Jon Povey jon.povey at racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network From mchehab at redhat.com Mon Jan 16 05:57:03 2012 From: mchehab at redhat.com (Mauro Carvalho Chehab) Date: Mon, 16 Jan 2012 09:57:03 -0200 Subject: [GIT PULL] davinci vpif pull request In-Reply-To: References: Message-ID: <4F14108F.5050505@redhat.com> Em 11-01-2012 09:39, Hadli, Manjunath escreveu: > Hi Mauro, > Can you please pull the following patch which removes some unnecessary inclusion > of machine specific header files from the main driver files? > > This patch has undergone sufficient review already. It is just a cleanup patch and I don't > expect any functionality to break because of this. The reason I did not club this with the > 3 previous patches was because one of the previous patches on which this is dependent, > is now pulled in by Arnd. > > Thanks and Regards, > -Manju > > > The following changes since commit e343a895a9f342f239c5e3c5ffc6c0b1707e6244: > Linus Torvalds (1): > Merge tag 'for-linus' of git://git.kernel.org/.../mst/vhost > > are available in the git repository at: > > git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for-mauro-v3.3 > > Manjunath Hadli (1): > davinci: vpif: remove machine specific header file inclusion from the driver This patch is outdated and doesn't apply anymore. Could you please rebase it over my tree, branch "staging/for_v3.3"? Thanks! Mauro > > drivers/media/video/davinci/vpif.h | 2 -- > drivers/media/video/davinci/vpif_display.c | 2 -- > include/media/davinci/vpif_types.h | 2 ++ > 3 files changed, 2 insertions(+), 4 deletions(-) > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html From manjunath.hadli at ti.com Mon Jan 16 06:45:05 2012 From: manjunath.hadli at ti.com (Hadli, Manjunath) Date: Mon, 16 Jan 2012 12:45:05 +0000 Subject: [GIT PULL] davinci vpif pull request In-Reply-To: <4F14108F.5050505@redhat.com> References: <4F14108F.5050505@redhat.com> Message-ID: Mauro, On Mon, Jan 16, 2012 at 17:27:03, Mauro Carvalho Chehab wrote: > Em 11-01-2012 09:39, Hadli, Manjunath escreveu: > > Hi Mauro, > > Can you please pull the following patch which removes some unnecessary inclusion > > of machine specific header files from the main driver files? > > > > This patch has undergone sufficient review already. It is just a cleanup patch and I don't > > expect any functionality to break because of this. The reason I did not club this with the > > 3 previous patches was because one of the previous patches on which this is dependent, > > is now pulled in by Arnd. > > > > Thanks and Regards, > > -Manju > > > > > > The following changes since commit e343a895a9f342f239c5e3c5ffc6c0b1707e6244: > > Linus Torvalds (1): > > Merge tag 'for-linus' of git://git.kernel.org/.../mst/vhost > > > > are available in the git repository at: > > > > git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for-mauro-v3.3 > > > > Manjunath Hadli (1): > > davinci: vpif: remove machine specific header file inclusion > > from the driver > > This patch is outdated and doesn't apply anymore. Could you please rebase it over my tree, branch "staging/for_v3.3"? This patch needs a recent accepted commit by Arnd which is available on http://git.linuxtv.org/linux-2.6.git but not on staging. Are you planning to rebase you staging tree to latest? When you do that this Patch will apply. Please let me know if there is any other way you want me to do? Regards, -Manju > > Thanks! > Mauro > > > > > drivers/media/video/davinci/vpif.h | 2 -- > > drivers/media/video/davinci/vpif_display.c | 2 -- > > include/media/davinci/vpif_types.h | 2 ++ > > 3 files changed, 2 insertions(+), 4 deletions(-) > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" > > in the body of a message to majordomo at vger.kernel.org More majordomo > > info at http://vger.kernel.org/majordomo-info.html > > From mchehab at redhat.com Mon Jan 16 06:56:25 2012 From: mchehab at redhat.com (Mauro Carvalho Chehab) Date: Mon, 16 Jan 2012 10:56:25 -0200 Subject: [GIT PULL] davinci vpif pull request In-Reply-To: References: <4F14108F.5050505@redhat.com> Message-ID: <4F141E79.1040800@redhat.com> Em 16-01-2012 10:45, Hadli, Manjunath escreveu: > Mauro, > On Mon, Jan 16, 2012 at 17:27:03, Mauro Carvalho Chehab wrote: >> Em 11-01-2012 09:39, Hadli, Manjunath escreveu: >>> Hi Mauro, >>> Can you please pull the following patch which removes some unnecessary inclusion >>> of machine specific header files from the main driver files? >>> >>> This patch has undergone sufficient review already. It is just a cleanup patch and I don't >>> expect any functionality to break because of this. The reason I did not club this with the >>> 3 previous patches was because one of the previous patches on which this is dependent, >>> is now pulled in by Arnd. >>> >>> Thanks and Regards, >>> -Manju >>> >>> >>> The following changes since commit e343a895a9f342f239c5e3c5ffc6c0b1707e6244: >>> Linus Torvalds (1): >>> Merge tag 'for-linus' of git://git.kernel.org/.../mst/vhost >>> >>> are available in the git repository at: >>> >>> git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for-mauro-v3.3 >>> >>> Manjunath Hadli (1): >>> davinci: vpif: remove machine specific header file inclusion >>> from the driver >> >> This patch is outdated and doesn't apply anymore. Could you please rebase it over my tree, branch "staging/for_v3.3"? > This patch needs a recent accepted commit by Arnd which is available on > http://git.linuxtv.org/linux-2.6.git but not on staging. This tree is just a daily-updated copy of Linus one. It is mirrored there just to minimize the object copies at the other local trees. > Are you planning to rebase you staging tree to latest? When you do that this > Patch will apply. Please let me know if there is any other way you want me to do? Linus doesn't like when someone merge from a random place at his tree. I'll merge from his tree at -rc1, but I'm not intending to merge it earlier than that, except if there are some strong reasons for that. Anyway, if you prefer to send this patch through Arnd's tree, feel free to add my acked-by: on that: Acked-by: Mauro Carvalho Chehab > > Regards, > -Manju >> >> Thanks! >> Mauro >> >>> >>> drivers/media/video/davinci/vpif.h | 2 -- >>> drivers/media/video/davinci/vpif_display.c | 2 -- >>> include/media/davinci/vpif_types.h | 2 ++ >>> 3 files changed, 2 insertions(+), 4 deletions(-) >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-media" >>> in the body of a message to majordomo at vger.kernel.org More majordomo >>> info at http://vger.kernel.org/majordomo-info.html >> >> > From manjunath.hadli at ti.com Mon Jan 16 07:06:52 2012 From: manjunath.hadli at ti.com (Hadli, Manjunath) Date: Mon, 16 Jan 2012 13:06:52 +0000 Subject: [GIT PULL] davinci vpif pull request In-Reply-To: <4F141E79.1040800@redhat.com> References: <4F14108F.5050505@redhat.com> <4F141E79.1040800@redhat.com> Message-ID: Mauro, On Mon, Jan 16, 2012 at 18:26:25, Mauro Carvalho Chehab wrote: > Em 16-01-2012 10:45, Hadli, Manjunath escreveu: > > Mauro, > > On Mon, Jan 16, 2012 at 17:27:03, Mauro Carvalho Chehab wrote: > >> Em 11-01-2012 09:39, Hadli, Manjunath escreveu: > >>> Hi Mauro, > >>> Can you please pull the following patch which removes some unnecessary inclusion > >>> of machine specific header files from the main driver files? > >>> > >>> This patch has undergone sufficient review already. It is just a cleanup patch and I don't > >>> expect any functionality to break because of this. The reason I did not club this with the > >>> 3 previous patches was because one of the previous patches on which this is dependent, > >>> is now pulled in by Arnd. > >>> > >>> Thanks and Regards, > >>> -Manju > >>> > >>> > >>> The following changes since commit e343a895a9f342f239c5e3c5ffc6c0b1707e6244: > >>> Linus Torvalds (1): > >>> Merge tag 'for-linus' of git://git.kernel.org/.../mst/vhost > >>> > >>> are available in the git repository at: > >>> > >>> git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git > >>> for-mauro-v3.3 > >>> > >>> Manjunath Hadli (1): > >>> davinci: vpif: remove machine specific header file inclusion > >>> from the driver > >> > >> This patch is outdated and doesn't apply anymore. Could you please rebase it over my tree, branch "staging/for_v3.3"? > > This patch needs a recent accepted commit by Arnd which is available > > on http://git.linuxtv.org/linux-2.6.git but not on staging. > > This tree is just a daily-updated copy of Linus one. It is mirrored there just to minimize the object copies at the other local trees. > > > Are you planning to rebase you staging tree to latest? When you do > > that this Patch will apply. Please let me know if there is any other way you want me to do? > > Linus doesn't like when someone merge from a random place at his tree. > I'll merge from his tree at -rc1, but I'm not intending to merge it earlier than that, except if there are some strong reasons for that. Indeed, there are quite a few patches waiting to be pulled which are dependent on this patch. I would urge you to pull this as early as possible. Rgds, -Manju > > Anyway, if you prefer to send this patch through Arnd's tree, feel free to add my acked-by: on that: > > Acked-by: Mauro Carvalho Chehab > > > > Regards, > > -Manju > >> > >> Thanks! > >> Mauro > >> > >>> > >>> drivers/media/video/davinci/vpif.h | 2 -- > >>> drivers/media/video/davinci/vpif_display.c | 2 -- > >>> include/media/davinci/vpif_types.h | 2 ++ > >>> 3 files changed, 2 insertions(+), 4 deletions(-) > >>> -- > >>> To unsubscribe from this list: send the line "unsubscribe linux-media" > >>> in the body of a message to majordomo at vger.kernel.org More majordomo > >>> info at http://vger.kernel.org/majordomo-info.html > >> > >> > > > > From mchehab at redhat.com Mon Jan 16 07:17:00 2012 From: mchehab at redhat.com (Mauro Carvalho Chehab) Date: Mon, 16 Jan 2012 11:17:00 -0200 Subject: [GIT PULL] davinci vpif pull request In-Reply-To: References: <4F14108F.5050505@redhat.com> <4F141E79.1040800@redhat.com> Message-ID: <4F14234C.5000404@redhat.com> Em 16-01-2012 11:06, Hadli, Manjunath escreveu: > Mauro, > On Mon, Jan 16, 2012 at 18:26:25, Mauro Carvalho Chehab wrote: >> Em 16-01-2012 10:45, Hadli, Manjunath escreveu: >>> Mauro, >>> On Mon, Jan 16, 2012 at 17:27:03, Mauro Carvalho Chehab wrote: >>>> Em 11-01-2012 09:39, Hadli, Manjunath escreveu: >>>>> Hi Mauro, >>>>> Can you please pull the following patch which removes some unnecessary inclusion >>>>> of machine specific header files from the main driver files? >>>>> >>>>> This patch has undergone sufficient review already. It is just a cleanup patch and I don't >>>>> expect any functionality to break because of this. The reason I did not club this with the >>>>> 3 previous patches was because one of the previous patches on which this is dependent, >>>>> is now pulled in by Arnd. >>>>> >>>>> Thanks and Regards, >>>>> -Manju >>>>> >>>>> >>>>> The following changes since commit e343a895a9f342f239c5e3c5ffc6c0b1707e6244: >>>>> Linus Torvalds (1): >>>>> Merge tag 'for-linus' of git://git.kernel.org/.../mst/vhost >>>>> >>>>> are available in the git repository at: >>>>> >>>>> git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git >>>>> for-mauro-v3.3 >>>>> >>>>> Manjunath Hadli (1): >>>>> davinci: vpif: remove machine specific header file inclusion >>>>> from the driver >>>> >>>> This patch is outdated and doesn't apply anymore. Could you please rebase it over my tree, branch "staging/for_v3.3"? >>> This patch needs a recent accepted commit by Arnd which is available >>> on http://git.linuxtv.org/linux-2.6.git but not on staging. >> >> This tree is just a daily-updated copy of Linus one. It is mirrored there just to minimize the object copies at the other local trees. >> >>> Are you planning to rebase you staging tree to latest? When you do >>> that this Patch will apply. Please let me know if there is any other way you want me to do? >> >> Linus doesn't like when someone merge from a random place at his tree. >> I'll merge from his tree at -rc1, but I'm not intending to merge it earlier than that, except if there are some strong reasons for that. > Indeed, there are quite a few patches waiting to be pulled which are > dependent on this patch. I would urge you to pull this as early as possible. Are those features target for 3.4? It is late for adding new features for 3.3. If they aren't for 3.3, merging at 3.3-rc1 should be ok for your needs. Otherwise, you need to point me the exact patch at Linus tree you need me to pull, and properly justify the need for this patch, and submit it together with the other ones you're needing for 3.3. > > Rgds, > -Manju >> >> Anyway, if you prefer to send this patch through Arnd's tree, feel free to add my acked-by: on that: >> >> Acked-by: Mauro Carvalho Chehab >>> >>> Regards, >>> -Manju >>>> >>>> Thanks! >>>> Mauro >>>> >>>>> >>>>> drivers/media/video/davinci/vpif.h | 2 -- >>>>> drivers/media/video/davinci/vpif_display.c | 2 -- >>>>> include/media/davinci/vpif_types.h | 2 ++ >>>>> 3 files changed, 2 insertions(+), 4 deletions(-) >>>>> -- >>>>> To unsubscribe from this list: send the line "unsubscribe linux-media" >>>>> in the body of a message to majordomo at vger.kernel.org More majordomo >>>>> info at http://vger.kernel.org/majordomo-info.html >>>> >>>> >>> >> >> > From michael.williamson at criticallink.com Mon Jan 16 08:55:44 2012 From: michael.williamson at criticallink.com (Michael Williamson) Date: Mon, 16 Jan 2012 09:55:44 -0500 Subject: DA850 / OMAP-L138 / AM-1808 EMIFA Clk issues. Message-ID: <4F143A70.4040505@criticallink.com> Hi, I am working with the OMAP-L138 and I think there may be a problem with the 456 MHz OPP point and using the EMIFA. The EMIFA max clock rate is specified at 148 MHz. By default, the EMIFA is driven by PLL0_SYSCLK3 (or 1/3 the CPU rate). At 456 MHz, this is 152 MHz. In addition to being out of spec, it looks like the aemif code that sets up wait state divisor settings is getting called by the MTD/NAND probe() code at startup, but doesn't register and recompute the timings if someone starts messing with the OPP (e.g., cranks it up from 300 MHz to 456 MHz) and the affected clock. There is a 4.5 divisor option (versus using PLL0_SYSCLK3) which would bring the timing back into specification at 456 MHz, but I am not sure where to plumb this code in, and when to call it. It seems application specific for OPPs below 456 MHz, and a requirement for the 456 MHz OPP. Would a sysfs attribute be appropriate? It would also seem that the NAND driver should register for clk change notification and update the CE space timings on change. I don't know if this is an issue with the DA830 / OMAP-L137, I am not familiar with the part. -Mike From sudhakar.raj at ti.com Mon Jan 16 23:39:31 2012 From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar) Date: Tue, 17 Jan 2012 05:39:31 +0000 Subject: DA850 / OMAP-L138 / AM-1808 EMIFA Clk issues. In-Reply-To: <4F143A70.4040505@criticallink.com> References: <4F143A70.4040505@criticallink.com> Message-ID: Hi Mike, On Mon, Jan 16, 2012 at 20:25:44, Michael Williamson wrote: > Hi, > > I am working with the OMAP-L138 and I think there may be a > problem with the 456 MHz OPP point and using the EMIFA. The > EMIFA max clock rate is specified at 148 MHz. By default, > the EMIFA is driven by PLL0_SYSCLK3 (or 1/3 the CPU rate). > Though EMIFA is configured at 1/3 of CPU rate, maximum frequency supported by it 100 MHz which is mentioned in the OMAP-L138 TRM at [1] (Refer to the Note below Table 7-6). We'll be correcting this in our next release scheduled for March end. > At 456 MHz, this is 152 MHz. In addition to being out of spec, > it looks like the aemif code that sets up wait state divisor settings > is getting called by the MTD/NAND probe() code at startup, but doesn't > register and recompute the timings if someone starts messing with the > OPP (e.g., cranks it up from 300 MHz to 456 MHz) and the affected clock. > We had two options to keep the pll0_sysclk3 frequency under allowable limits: a. Whenever cpu frequency changes, check whether the current value of PLL0_SYSCLK3 is greater than the allowed value and adjust accordingly. b. Fix the PLL0_SYSCLK3 divider value at some constant such that at all operating points, the frequency is within the allowed value. We did some experiments on the NAND performance with the above two options. We found out that except for the case when CPU is operating at 100 MHz, there was a minor variation in the performance figures (of the order of 2-4%). Note that we had implemented CPU freq support for NAND during this experiment. Based on the findings we'll be implementing option 'b' in our next release. EMIFA frequency will be fixed at 1/5 of CPU rate. Regards, Sudhakar From sudhakar.raj at ti.com Mon Jan 16 23:45:57 2012 From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar) Date: Tue, 17 Jan 2012 05:45:57 +0000 Subject: DA850 / OMAP-L138 / AM-1808 EMIFA Clk issues. In-Reply-To: References: <4F143A70.4040505@criticallink.com> Message-ID: Hi, On Tue, Jan 17, 2012 at 11:09:31, Rajashekhara, Sudhakar wrote: > Hi Mike, > > On Mon, Jan 16, 2012 at 20:25:44, Michael Williamson wrote: > > Hi, > > > > I am working with the OMAP-L138 and I think there may be a > > problem with the 456 MHz OPP point and using the EMIFA. The > > EMIFA max clock rate is specified at 148 MHz. By default, > > the EMIFA is driven by PLL0_SYSCLK3 (or 1/3 the CPU rate). > > > > Though EMIFA is configured at 1/3 of CPU rate, maximum frequency > supported by it 100 MHz which is mentioned in the OMAP-L138 TRM > at [1] (Refer to the Note below Table 7-6). We'll be correcting > this in our next release scheduled for March end. Forgot to mention the link. [1] http://www.ti.com/litv/pdf/spruh77a > > > At 456 MHz, this is 152 MHz. In addition to being out of spec, > > it looks like the aemif code that sets up wait state divisor settings > > is getting called by the MTD/NAND probe() code at startup, but doesn't > > register and recompute the timings if someone starts messing with the > > OPP (e.g., cranks it up from 300 MHz to 456 MHz) and the affected clock. > > > [...] Regards, Sudhakar From manjunath.hadli at ti.com Tue Jan 17 00:36:19 2012 From: manjunath.hadli at ti.com (Hadli, Manjunath) Date: Tue, 17 Jan 2012 06:36:19 +0000 Subject: [GIT PULL] davinci vpif pull request In-Reply-To: <4F14234C.5000404@redhat.com> References: <4F14108F.5050505@redhat.com> <4F141E79.1040800@redhat.com> <4F14234C.5000404@redhat.com> Message-ID: Mauro, On Mon, Jan 16, 2012 at 18:47:00, Mauro Carvalho Chehab wrote: > Em 16-01-2012 11:06, Hadli, Manjunath escreveu: > > Mauro, > > On Mon, Jan 16, 2012 at 18:26:25, Mauro Carvalho Chehab wrote: > >> Em 16-01-2012 10:45, Hadli, Manjunath escreveu: > >>> Mauro, > >>> On Mon, Jan 16, 2012 at 17:27:03, Mauro Carvalho Chehab wrote: > >>>> Em 11-01-2012 09:39, Hadli, Manjunath escreveu: > >>>>> Hi Mauro, > >>>>> Can you please pull the following patch which removes some unnecessary inclusion > >>>>> of machine specific header files from the main driver files? > >>>>> > >>>>> This patch has undergone sufficient review already. It is just a cleanup patch and I don't > >>>>> expect any functionality to break because of this. The reason I did not club this with the > >>>>> 3 previous patches was because one of the previous patches on which this is dependent, > >>>>> is now pulled in by Arnd. > >>>>> > >>>>> Thanks and Regards, > >>>>> -Manju > >>>>> > >>>>> > >>>>> The following changes since commit e343a895a9f342f239c5e3c5ffc6c0b1707e6244: > >>>>> Linus Torvalds (1): > >>>>> Merge tag 'for-linus' of > >>>>> git://git.kernel.org/.../mst/vhost > >>>>> > >>>>> are available in the git repository at: > >>>>> > >>>>> git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git > >>>>> for-mauro-v3.3 > >>>>> > >>>>> Manjunath Hadli (1): > >>>>> davinci: vpif: remove machine specific header file inclusion > >>>>> from the driver > >>>> > >>>> This patch is outdated and doesn't apply anymore. Could you please rebase it over my tree, branch "staging/for_v3.3"? > >>> This patch needs a recent accepted commit by Arnd which is available > >>> on http://git.linuxtv.org/linux-2.6.git but not on staging. > >> > >> This tree is just a daily-updated copy of Linus one. It is mirrored there just to minimize the object copies at the other local trees. > >> > >>> Are you planning to rebase you staging tree to latest? When you do > >>> that this Patch will apply. Please let me know if there is any other way you want me to do? > >> > >> Linus doesn't like when someone merge from a random place at his tree. > >> I'll merge from his tree at -rc1, but I'm not intending to merge it earlier than that, except if there are some strong reasons for that. > > Indeed, there are quite a few patches waiting to be pulled which are > > dependent on this patch. I would urge you to pull this as early as possible. > > Are those features target for 3.4? It is late for adding new features for 3.3. > > If they aren't for 3.3, merging at 3.3-rc1 should be ok for your needs. They are intended for 3.4. Merging at v3.3-rc1 is OK. Regards, -Manju > Otherwise, you need to point me the exact patch at Linus tree you need me to pull, and properly justify the need for this patch, and submit it together with the other ones you're needing for 3.3. > > > > Rgds, > > -Manju > >> > >> Anyway, if you prefer to send this patch through Arnd's tree, feel free to add my acked-by: on that: > >> > >> Acked-by: Mauro Carvalho Chehab > >>> > >>> Regards, > >>> -Manju > >>>> > >>>> Thanks! > >>>> Mauro > >>>> > >>>>> > >>>>> drivers/media/video/davinci/vpif.h | 2 -- > >>>>> drivers/media/video/davinci/vpif_display.c | 2 -- > >>>>> include/media/davinci/vpif_types.h | 2 ++ > >>>>> 3 files changed, 2 insertions(+), 4 deletions(-) > >>>>> -- > >>>>> To unsubscribe from this list: send the line "unsubscribe linux-media" > >>>>> in the body of a message to majordomo at vger.kernel.org More > >>>>> majordomo info at http://vger.kernel.org/majordomo-info.html > >>>> > >>>> > >>> > >> > >> > > > > From manjunath.hadli at ti.com Tue Jan 17 00:59:35 2012 From: manjunath.hadli at ti.com (Hadli, Manjunath) Date: Tue, 17 Jan 2012 06:59:35 +0000 Subject: [PATCH 2/2] v4l2: add new pixel formats supported on dm365 In-Reply-To: <201201021221.06660.laurent.pinchart@ideasonboard.com> References: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> <201112212323.26971.laurent.pinchart@ideasonboard.com> <20111228111627.GT3677@valkosipuli.localdomain> <201201021221.06660.laurent.pinchart@ideasonboard.com> Message-ID: All, On Mon, Jan 02, 2012 at 16:51:06, Laurent Pinchart wrote: > Hi Sakari, > > On Wednesday 28 December 2011 12:16:27 Sakari Ailus wrote: > > On Wed, Dec 21, 2011 at 11:23:26PM +0100, Laurent Pinchart wrote: > > > On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote: > > > > On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote: > > > > > On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote: > > > > > > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote: > > > > > > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote: > > > > > > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer > > > > > > > > format frames compressed by A-LAW alogorithm. > > > > > > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV > > > > > > > > interleved) only. > > > > > > > > > > > > > > > > Signed-off-by: Manjunath Hadli > > > > > > > > Cc: Laurent Pinchart > > > > > > > > --- > > > > > > > > > > > > > > > > include/linux/videodev2.h | 6 ++++++ > > > > > > > > 1 files changed, 6 insertions(+), 0 deletions(-) > > > > > > > > > > > > > > Could you please also document these formats in > > > > > > > Documentation/DocBook/media/v4l ? > > > > > > > > > > > > I will. Sorry to have missed that out. > > > > > > > > > > > > > > diff --git a/include/linux/videodev2.h > > > > > > > > b/include/linux/videodev2.h index 4b752d5..969112d 100644 > > > > > > > > --- a/include/linux/videodev2.h > > > > > > > > +++ b/include/linux/videodev2.h > > > > > > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format { > > > > > > > > > > > > > > > > #define V4L2_PIX_FMT_HM12 v4l2_fourcc('H', 'M', '1', '2') > > > > > > > > /* 8 YUV > > > > > > > > > > > > > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420 > > > > > > > > v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines > > > > > > > > y, 1 line uv interleaved */ > > > > > > > > > > > > > > > > +/* Chrominance formats */ > > > > > > > > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') > > > > > > > > /* 8 UV 4:4 */ + > > > > > > > > > > > > > > > > /* two planes -- one Y, one Cr + Cb interleaved */ > > > > > > > > #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') > > > > > > > > /* 12 Y/CbCr > > > > > > > > > > > > > > > > 4:2:0 */ #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', > > > > > > > > '2', '1') /* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ > > > > > > > > struct v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12 > > > > > > > > v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /* > > > > > > > > 10bit raw bayer DPCM compressed to 8 bits */ #define > > > > > > > > V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0') > > > > > > > > + /* 10bit raw bayer a-law compressed to 8 bits */ #define > > > > > > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8') > > > > > > > > + > > > > > > > > > > > > > > That's not very future-proof, how would you describe > > > > > > > SGBRG10ALAW8 for instance ? > > > > > > > > > > > > > > Maybe it's time to standardize FOURCCs for Bayer new > > > > > > > formats. We have 4 characters, we could start with 'B' to > > > > > > > denote Bayer, followed by one character for the order, one > > > > > > > for the compression, and one for the number of bits. > > > > > > > > > > > > I agree. > > > > > > May be ('B', 'G', 'A', '8') is fine for the above? > > > > > > > > > > We need to describe at last BGGR, GBRG, GRBG and RGGB. We could > > > > > use 'B', 'g', 'G' and 'R' respectively for the second character. > > > > > The third character would be 'A' for A-law and 'D' for DPCM, and > > > > > the fourth character could describe the bus width in bits from 0 > > > > > to 15 with '0' - '9', 'A' - 'F'. However, I suspect that we will > > > > > need 16-bit wide busses for raw Bayer at some point, and a 0 > > > > > width is definitely not useful. We could thus offset the width by some value. > > > > > > > > > > This is just a preliminary idea, I'm open to suggestions. > > > > > > > > I think it is a very good suggestion that we can go with. > > > > B : BGGR > > > > g : GBRG > > > > G : GRBG > > > > R : RGGB > > > > > > > > and 0-F can signify 1-16. > > > > > > Hans, Guennadi, Sakari, any opinion on that as well ? > > > > I think four letters simply aren't enough to universally describe a > > media bus format in a human-readable way. We can aim to that, but we > > will have to make compromises. > > > > For example, DPCM compressed format has two important parameters > > beyond pixel order and the colour space, the uncompressed depth and > > the compressed depth. Typically one doesn't compress the data too > > much, but things like > > 10-to-6 bits are well possible. > > > > Could we use a single letter to tell that a format is both bayer and > > DPCM compressed? I'd go for 'b'. Raw bayer alaw could be denoted by 'a'. > > > > Then raw bayer, GBRG pixel order 10-to-7 bits would be called "bgA7". > > The same in Alaw would be "agA7". > > > > What do you think? > > We can't come up with a naming scheme that will handle all possible combinations. I'm fine as long as the names we select have some kind of structure and handle the raw patterns currently available. I'd still like to hear Hans' opinion on this. Since we agree that the scheme will not be able to cover the spectrum In the level of detail which we would like to, I think we should go with the Above discussed scheme which seems logical. I will send out a detailed patch With added documentation. Thx, -Manju > > -- > Regards, > > Laurent Pinchart > From laurent.pinchart at ideasonboard.com Tue Jan 17 03:17:58 2012 From: laurent.pinchart at ideasonboard.com (Laurent Pinchart) Date: Tue, 17 Jan 2012 10:17:58 +0100 Subject: [PATCH 2/2] v4l2: add new pixel formats supported on dm365 In-Reply-To: References: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> <201201021221.06660.laurent.pinchart@ideasonboard.com> Message-ID: <201201171017.59137.laurent.pinchart@ideasonboard.com> Hi Manjunath, On Tuesday 17 January 2012 07:59:35 Hadli, Manjunath wrote: > On Mon, Jan 02, 2012 at 16:51:06, Laurent Pinchart wrote: > > On Wednesday 28 December 2011 12:16:27 Sakari Ailus wrote: > > > On Wed, Dec 21, 2011 at 11:23:26PM +0100, Laurent Pinchart wrote: > > > > On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote: > > > > > On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote: > > > > > > On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote: > > > > > > > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote: > > > > > > > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote: > > > > > > > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer > > > > > > > > > format frames compressed by A-LAW alogorithm. > > > > > > > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV > > > > > > > > > interleved) only. > > > > > > > > > > > > > > > > > > Signed-off-by: Manjunath Hadli > > > > > > > > > Cc: Laurent Pinchart > > > > > > > > > --- > > > > > > > > > > > > > > > > > > include/linux/videodev2.h | 6 ++++++ > > > > > > > > > 1 files changed, 6 insertions(+), 0 deletions(-) > > > > > > > > > > > > > > > > Could you please also document these formats in > > > > > > > > Documentation/DocBook/media/v4l ? > > > > > > > > > > > > > > I will. Sorry to have missed that out. > > > > > > > > > > > > > > > > diff --git a/include/linux/videodev2.h > > > > > > > > > b/include/linux/videodev2.h index 4b752d5..969112d 100644 > > > > > > > > > --- a/include/linux/videodev2.h > > > > > > > > > +++ b/include/linux/videodev2.h > > > > > > > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format { > > > > > > > > > > > > > > > > > > #define V4L2_PIX_FMT_HM12 v4l2_fourcc('H', 'M', '1', > > > > > > > > > '2') /* 8 YUV > > > > > > > > > > > > > > > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420 > > > > > > > > > v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines > > > > > > > > > y, 1 line uv interleaved */ > > > > > > > > > > > > > > > > > > +/* Chrominance formats */ > > > > > > > > > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' > > > > > > > > > ') /* 8 UV 4:4 */ + > > > > > > > > > > > > > > > > > > /* two planes -- one Y, one Cr + Cb interleaved */ > > > > > > > > > #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', > > > > > > > > > '2') /* 12 Y/CbCr > > > > > > > > > > > > > > > > > > 4:2:0 */ #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', > > > > > > > > > 'V', '2', '1') /* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ > > > > > > > > > struct v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12 > > > > > > > > > v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /* > > > > > > > > > 10bit raw bayer DPCM compressed to 8 bits */ #define > > > > > > > > > V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0') > > > > > > > > > + /* 10bit raw bayer a-law compressed to 8 bits */ #define > > > > > > > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8') > > > > > > > > > + > > > > > > > > > > > > > > > > That's not very future-proof, how would you describe > > > > > > > > SGBRG10ALAW8 for instance ? > > > > > > > > > > > > > > > > Maybe it's time to standardize FOURCCs for Bayer new > > > > > > > > formats. We have 4 characters, we could start with 'B' to > > > > > > > > denote Bayer, followed by one character for the order, one > > > > > > > > for the compression, and one for the number of bits. > > > > > > > > > > > > > > I agree. > > > > > > > May be ('B', 'G', 'A', '8') is fine for the above? > > > > > > > > > > > > We need to describe at last BGGR, GBRG, GRBG and RGGB. We could > > > > > > use 'B', 'g', 'G' and 'R' respectively for the second character. > > > > > > The third character would be 'A' for A-law and 'D' for DPCM, and > > > > > > the fourth character could describe the bus width in bits from 0 > > > > > > to 15 with '0' - '9', 'A' - 'F'. However, I suspect that we will > > > > > > need 16-bit wide busses for raw Bayer at some point, and a 0 > > > > > > width is definitely not useful. We could thus offset the width by > > > > > > some value. > > > > > > > > > > > > This is just a preliminary idea, I'm open to suggestions. > > > > > > > > > > I think it is a very good suggestion that we can go with. > > > > > B : BGGR > > > > > g : GBRG > > > > > G : GRBG > > > > > R : RGGB > > > > > > > > > > and 0-F can signify 1-16. > > > > > > > > Hans, Guennadi, Sakari, any opinion on that as well ? > > > > > > I think four letters simply aren't enough to universally describe a > > > media bus format in a human-readable way. We can aim to that, but we > > > will have to make compromises. > > > > > > For example, DPCM compressed format has two important parameters > > > beyond pixel order and the colour space, the uncompressed depth and > > > the compressed depth. Typically one doesn't compress the data too > > > much, but things like > > > 10-to-6 bits are well possible. > > > > > > Could we use a single letter to tell that a format is both bayer and > > > DPCM compressed? I'd go for 'b'. Raw bayer alaw could be denoted by > > > 'a'. > > > > > > Then raw bayer, GBRG pixel order 10-to-7 bits would be called "bgA7". > > > The same in Alaw would be "agA7". > > > > > > What do you think? > > > > We can't come up with a naming scheme that will handle all possible > > combinations. I'm fine as long as the names we select have some kind of > > structure and handle the raw patterns currently available. I'd still > > like to hear Hans' opinion on this. > > Since we agree that the scheme will not be able to cover the spectrum > In the level of detail which we would like to, I think we should go with > the Above discussed scheme which seems logical. I will send out a detailed > patch With added documentation. Please also see http://www.spinics.net/lists/linux-media/msg43192.html. -- Regards, Laurent Pinchart From nsekhar at ti.com Tue Jan 17 04:02:23 2012 From: nsekhar at ti.com (Nori, Sekhar) Date: Tue, 17 Jan 2012 10:02:23 +0000 Subject: DaVinci unbanked GPIO IRQs broken In-Reply-To: <70E876B0EA86DD4BAF101844BC814DFE0BF403DA89@Cloud.RL.local> References: <70E876B0EA86DD4BAF101844BC814DFE0BF403DA89@Cloud.RL.local> Message-ID: Hi Jon, On Mon, Jan 16, 2012 at 17:08:30, Jon Povey wrote: > Sorry, last email had some lies, I had testing errors: > > Jon Povey wrote: > > But I did try reverting the genirq change too, and > > the interrupt handler still wasn't called > > This was incorrect, interrupt DOES work with genirq reverted on 3.2. > > > 3.2 vanilla: oops requesting irq > > 3.2 + your patch: no oops, isr is not run > > These are still the case > > > 3.2 + reverted genirq: no oops, isr is not run > > This was incorrect, real result is: no oops, isr WORKS. > (with or without your patch). I was able to reproduce this on the EVM using v2.6.38 (works) and v3.2 + my patch (doesn't work). I just started poking some registers to see what is happening. Will keep you updated on any progress. Thanks, Sekhar From michael.williamson at criticallink.com Tue Jan 17 06:43:23 2012 From: michael.williamson at criticallink.com (Michael Williamson) Date: Tue, 17 Jan 2012 07:43:23 -0500 Subject: DA850 / OMAP-L138 / AM-1808 EMIFA Clk issues. In-Reply-To: References: <4F143A70.4040505@criticallink.com> Message-ID: <4F156CEB.4050803@criticallink.com> Hello Sudhakar, On 1/17/2012 12:39 AM, Rajashekhara, Sudhakar wrote: > Hi Mike, > > On Mon, Jan 16, 2012 at 20:25:44, Michael Williamson wrote: >> Hi, >> >> I am working with the OMAP-L138 and I think there may be a >> problem with the 456 MHz OPP point and using the EMIFA. The >> EMIFA max clock rate is specified at 148 MHz. By default, >> the EMIFA is driven by PLL0_SYSCLK3 (or 1/3 the CPU rate). >> > > Though EMIFA is configured at 1/3 of CPU rate, maximum frequency > supported by it 100 MHz which is mentioned in the OMAP-L138 TRM > at [1] (Refer to the Note below Table 7-6). We'll be correcting > this in our next release scheduled for March end. > Correcting the spec? The revision D OMAP-L138 specification[1] in Table 5-5 indicates a max async rate of 148 MHz and a max SDRAM rate of 100 MHz. It also indicates a max 148 MHz rate in table 5-23 (Tc(CLK) is minimum 6.75 ns) for async operation. >> At 456 MHz, this is 152 MHz. In addition to being out of spec, >> it looks like the aemif code that sets up wait state divisor settings >> is getting called by the MTD/NAND probe() code at startup, but doesn't >> register and recompute the timings if someone starts messing with the >> OPP (e.g., cranks it up from 300 MHz to 456 MHz) and the affected clock. >> > > We had two options to keep the pll0_sysclk3 frequency under allowable > limits: > a. Whenever cpu frequency changes, check whether the current value of > PLL0_SYSCLK3 is greater than the allowed value and adjust accordingly. > b. Fix the PLL0_SYSCLK3 divider value at some constant such that at all > operating points, the frequency is within the allowed value. > > We did some experiments on the NAND performance with the above two options. > We found out that except for the case when CPU is operating at 100 MHz, > there was a minor variation in the performance figures (of the order of 2-4%). > Note that we had implemented CPU freq support for NAND during this experiment. > > Based on the findings we'll be implementing option 'b' in our next release. > EMIFA frequency will be fixed at 1/5 of CPU rate. > Well, that's all fine and swell, except we have OMAP-L138 platforms (built using the MityDSP-L138 SOM) that use the EMIFA for other devices than NAND, such as an FPGA (and no SDRAM). Dropping the default 300 MHz OPP EMIFA speed from 100 MHz down to 60 MHz will directly translate to a 40% reduction in potential bus bandwidth. If you are making this device wide, it would really be nice to have an option that is more consistent with option A and let the platform designer decide what rate the EMIFA clock should run at based on his hardware requirements. Is your release regarding this matter going to be brought into the mainline as well or just the TI Arago tree? We were actually interested in having the option to run that bus (in async mode) faster than 100 MHz for the higher speed OPP's, but it sounds like the specification is a little misleading in the capabilities of the part. I appreciate the information. [1] http://www.ti.com/lit/gpn/omap-l138 -Mike From christian.riesch at omicron.at Tue Jan 17 06:53:52 2012 From: christian.riesch at omicron.at (Christian Riesch) Date: Tue, 17 Jan 2012 13:53:52 +0100 Subject: DA850 / OMAP-L138 / AM-1808 EMIFA Clk issues. In-Reply-To: <4F156CEB.4050803@criticallink.com> References: <4F143A70.4040505@criticallink.com> <4F156CEB.4050803@criticallink.com> Message-ID: Hi Sudhakar, hi Mike, On Tue, Jan 17, 2012 at 1:43 PM, Michael Williamson wrote: > On 1/17/2012 12:39 AM, Rajashekhara, Sudhakar wrote: >> We had two options to keep the pll0_sysclk3 frequency under allowable >> limits: >> a. Whenever cpu frequency changes, check whether the current value of >> ? ?PLL0_SYSCLK3 is greater than the allowed value and adjust accordingly. >> b. Fix the PLL0_SYSCLK3 divider value at some constant such that at all >> ? ?operating points, the frequency is within the allowed value. > >> We did some experiments on the NAND performance with the above two options. >> We found out that except for the case when CPU is operating at 100 MHz, >> there was a minor variation in the performance figures (of the order of 2-4%). >> Note that we had implemented CPU freq support for NAND during this experiment. >> >> Based on the findings we'll be implementing option 'b' in our next release. >> EMIFA frequency will be fixed at 1/5 of CPU rate. > > Well, that's all fine and swell, except we have OMAP-L138 platforms > (built using the MityDSP-L138 SOM) that use the EMIFA for other > devices than NAND, such as an FPGA (and no SDRAM). ?Dropping the default > 300 MHz OPP EMIFA speed from 100 MHz down to 60 MHz will directly translate > to a 40% reduction in potential bus bandwidth. ?If you are making this device > wide, it would really be nice to have an option that is more consistent > with option A and let the platform designer decide what rate the EMIFA > clock should run at based on his hardware requirements. In my opinion hardcoding OPPs in a SoC specific file (arch/arm/mach-davinci/da850.c) was a bad idea. Setting EMIFA clock to 1/5 of CPU rate may be fine for some boards, but for others it may be a bad decision. How about boards with input clock frequencies other than 24 MHz? Currently the OPP settings are only correct if a 24 MHz quartz or oscillator is used. So I think the OPPs should move out of the SoC specific file. Regards, Christian From nsekhar at ti.com Tue Jan 17 13:56:27 2012 From: nsekhar at ti.com (Nori, Sekhar) Date: Tue, 17 Jan 2012 19:56:27 +0000 Subject: [PATCH v2] DaVinci: can only power up domains on DM644x In-Reply-To: <3E54258959B69E4282D79E01AB1F32B7265471@DFLE34.ent.ti.com> References: <201109151829.49256.sshtylyov@ru.mvista.com> <201201062140.33712.sshtylyov@ru.mvista.com> <201201062148.32025.sshtylyov@ru.mvista.com> <3E54258959B69E4282D79E01AB1F32B7265471@DFLE34.ent.ti.com> Message-ID: Hi Sergei, On Thu, Jan 12, 2012 at 17:30:15, Karicheri, Muralidharan wrote: > Sekhar & Sergei, > > This will affect the new SoCs that have capabilities to power up different domains. Why do we need this enforcement? We are working on a DaVinci variant SoC that can do power up multiple domains (That is why I had a patch earlier to support > Multiple PD which is already part of the tree). So I don't want this patch to go through unless I see a reason for pushing this. I agree with Murali here. The cpu_is_ checking in the patch is going to quickly turn ugly as new SoCs with power domain control are added. On SoCs where domain power up procedure is not documented, even bootloader cannot be responsible for powering up the domain. The domain will be powered up in hardware itself; so the power domain status cannot show the domain as powered off. A better change in this area would be to add a timeout to the infinite loop reading epcpr. This will enable proper error reporting. Thanks, Sekhar From hs at denx.de Thu Jan 19 01:05:21 2012 From: hs at denx.de (Heiko Schocher) Date: Thu, 19 Jan 2012 08:05:21 +0100 Subject: [PATCH v3] ARM: davinci: map default_queue to edma channels Message-ID: <1326956721-25158-1-git-send-email-hs@denx.de> Default queue is expected to be a low-priority queue. This way, long transfers on the default queue started by the codec engine will not cause audio defects. Signed-off-by: Heiko Schocher Signed-off-by: juha.kuikka at gmail.com Reported-by: juha.kuikka at gmail.com Acked-by: Rajashekhara, Sudhakar Cc: linux-mmc at vger.kernel.org Cc: davinci-linux-open-source at linux.davincidsp.com Cc: linux-arm-kernel at lists.infradead.org Cc: Rajashekhara, Sudhakar Cc: Ido Yariv Cc: Sekhar Nori Cc: Wolfgang Denk Cc: Sergei Shtylyov --- - changes for v2: - add comment from Sergei Shtylyov add in commit message the commit's summary in parens. - add comment from Ido Yariv: changed comment and commit message - added Acked-by from Rajashekhara, Sudhakar - changes for v3: - add comments from Sekhar Nori : - add linux-arm-kernel at lists.infradead.org to Cc - simplify and move comment to arch/arm/mach-davinci/include/mach/edma.h - rework commit message - as the subject changed v2 can be found for example here: http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2011-December/023606.html - checkpatch shows: total: 0 errors, 0 warnings, 24 lines checked temp/0001-ARM-davinci-map-default_queue-to-edma-channels.patch has no obvious style problems and is ready for submission. arch/arm/mach-davinci/dma.c | 6 +----- arch/arm/mach-davinci/include/mach/edma.h | 5 +++++ 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c index da90103..fd33919 100644 --- a/arch/arm/mach-davinci/dma.c +++ b/arch/arm/mach-davinci/dma.c @@ -1508,12 +1508,8 @@ static int __init edma_probe(struct platform_device *pdev) goto fail; } - /* Everything lives on transfer controller 1 until otherwise - * specified. This way, long transfers on the low priority queue - * started by the codec engine will not cause audio defects. - */ for (i = 0; i < edma_cc[j]->num_channels; i++) - map_dmach_queue(j, i, EVENTQ_1); + map_dmach_queue(j, i, info[j]->default_queue); queue_tc_mapping = info[j]->queue_tc_mapping; queue_priority_mapping = info[j]->queue_priority_mapping; diff --git a/arch/arm/mach-davinci/include/mach/edma.h b/arch/arm/mach-davinci/include/mach/edma.h index 20c77f2..7e84c90 100644 --- a/arch/arm/mach-davinci/include/mach/edma.h +++ b/arch/arm/mach-davinci/include/mach/edma.h @@ -250,6 +250,11 @@ struct edma_soc_info { unsigned n_slot; unsigned n_tc; unsigned n_cc; + /* + * Default queue is expected to be a low-priority queue. + * This way, long transfers on the default queue started + * by the codec engine will not cause audio defects. + */ enum dma_event_q default_queue; /* Resource reservation for other cores */ -- 1.7.7.5 From nsekhar at ti.com Thu Jan 19 14:23:03 2012 From: nsekhar at ti.com (Nori, Sekhar) Date: Thu, 19 Jan 2012 20:23:03 +0000 Subject: [PATCH] ARM: mach-davinci DA850: removed un-existing pll1_sysclk4-7 clock domains In-Reply-To: <20120116064559.GA3025@altenpts-laptop> References: <20120116064559.GA3025@altenpts-laptop> Message-ID: Hi Bas van den, On Mon, Jan 16, 2012 at 12:16:02, Bas van den Berg wrote: > DA850: sysclk4-7 only exist for pll0. for pll1 sysclk1-3 exist. > > Signed-off-by: Bas van den Berg Applied, thanks. Please note that there is no need to add "mach-" in front of davinci in subject line. It helps to keep the subject lines consistent. While committing, I changed the subject to: "ARM: davinci: DA850: remove non-existing pll1_sysclk4-7 clocks" Please take care next time on. Thanks, Sekhar From sudhakar.raj at ti.com Fri Jan 20 03:48:07 2012 From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar) Date: Fri, 20 Jan 2012 09:48:07 +0000 Subject: DA850 / OMAP-L138 / AM-1808 EMIFA Clk issues. In-Reply-To: <4F156CEB.4050803@criticallink.com> References: <4F143A70.4040505@criticallink.com> <4F156CEB.4050803@criticallink.com> Message-ID: Hi Mike, On Tue, Jan 17, 2012 at 18:13:23, Michael Williamson wrote: > Hello Sudhakar, > > On 1/17/2012 12:39 AM, Rajashekhara, Sudhakar wrote: > > > Hi Mike, > > > > On Mon, Jan 16, 2012 at 20:25:44, Michael Williamson wrote: > >> Hi, > >> > >> I am working with the OMAP-L138 and I think there may be a > >> problem with the 456 MHz OPP point and using the EMIFA. The > >> EMIFA max clock rate is specified at 148 MHz. By default, > >> the EMIFA is driven by PLL0_SYSCLK3 (or 1/3 the CPU rate). > >> > > > > Though EMIFA is configured at 1/3 of CPU rate, maximum frequency > > supported by it 100 MHz which is mentioned in the OMAP-L138 TRM > > at [1] (Refer to the Note below Table 7-6). We'll be correcting > > this in our next release scheduled for March end. > > > > > Correcting the spec? The revision D OMAP-L138 specification[1] in > Table 5-5 indicates a max async rate of 148 MHz and a max SDRAM rate > of 100 MHz. It also indicates a max 148 MHz rate in table 5-23 (Tc(CLK) is > minimum 6.75 ns) for async operation. > I was talking about correcting the software here. As of now there is some confusion on the maximum allowable EMIFA frequency. I'll get this clarified from our design team and then either correct the software or the documentation. > > >> At 456 MHz, this is 152 MHz. In addition to being out of spec, > >> it looks like the aemif code that sets up wait state divisor settings > >> is getting called by the MTD/NAND probe() code at startup, but doesn't > >> register and recompute the timings if someone starts messing with the > >> OPP (e.g., cranks it up from 300 MHz to 456 MHz) and the affected clock. > >> > > > > We had two options to keep the pll0_sysclk3 frequency under allowable > > limits: > > a. Whenever cpu frequency changes, check whether the current value of > > PLL0_SYSCLK3 is greater than the allowed value and adjust accordingly. > > b. Fix the PLL0_SYSCLK3 divider value at some constant such that at all > > operating points, the frequency is within the allowed value. > > > > > > We did some experiments on the NAND performance with the above two options. > > We found out that except for the case when CPU is operating at 100 MHz, > > there was a minor variation in the performance figures (of the order of 2-4%). > > Note that we had implemented CPU freq support for NAND during this experiment. > > > > Based on the findings we'll be implementing option 'b' in our next release. > > EMIFA frequency will be fixed at 1/5 of CPU rate. > > > > > > Well, that's all fine and swell, except we have OMAP-L138 platforms > (built using the MityDSP-L138 SOM) that use the EMIFA for other > devices than NAND, such as an FPGA (and no SDRAM). Dropping the default > 300 MHz OPP EMIFA speed from 100 MHz down to 60 MHz will directly translate > to a 40% reduction in potential bus bandwidth. If you are making this device > wide, it would really be nice to have an option that is more consistent > with option A and let the platform designer decide what rate the EMIFA > clock should run at based on his hardware requirements. > You are right. We'll implement option A in our software. Right now we are working on supporting USB on Linux 3.2 on AM18x. Once we finish that, we'll look into this. > Is your release regarding this matter going to be brought into the mainline > as well or just the TI Arago tree? > We'll be pushing this patch upstream but till the point it gets accepted, we'll be maintaining it on Arago. > We were actually interested in having the option to run that bus (in async > mode) faster than 100 MHz for the higher speed OPP's, but it sounds like > the specification is a little misleading in the capabilities of the part. > As I mentioned above, I'll get this clarified from our design team and update you. Thanks, Sudhakar From sudhakar.raj at ti.com Fri Jan 20 04:01:34 2012 From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar) Date: Fri, 20 Jan 2012 10:01:34 +0000 Subject: DA850 / OMAP-L138 / AM-1808 EMIFA Clk issues. In-Reply-To: References: <4F143A70.4040505@criticallink.com> <4F156CEB.4050803@criticallink.com> Message-ID: Hi Christian, On Tue, Jan 17, 2012 at 18:23:52, Christian Riesch wrote: > Hi Sudhakar, hi Mike, > > On Tue, Jan 17, 2012 at 1:43 PM, Michael Williamson > wrote: > > On 1/17/2012 12:39 AM, Rajashekhara, Sudhakar wrote: [...] > > > > Well, that's all fine and swell, except we have OMAP-L138 platforms > > (built using the MityDSP-L138 SOM) that use the EMIFA for other > > devices than NAND, such as an FPGA (and no SDRAM). ?Dropping the default > > 300 MHz OPP EMIFA speed from 100 MHz down to 60 MHz will directly translate > > to a 40% reduction in potential bus bandwidth. ?If you are making this device > > wide, it would really be nice to have an option that is more consistent > > with option A and let the platform designer decide what rate the EMIFA > > clock should run at based on his hardware requirements. > > In my opinion hardcoding OPPs in a SoC specific file > (arch/arm/mach-davinci/da850.c) was a bad idea. Setting EMIFA clock to > 1/5 of CPU rate may be fine for some boards, but for others it may be > a bad decision. How about boards with input clock frequencies other > than 24 MHz? Currently the OPP settings are only correct if a 24 MHz > quartz or oscillator is used. So I think the OPPs should move out of > the SoC specific file. > Using a different oscillator is a perfectly valid use case but I was wondering why anyone would do that? The OPP settings are defined and are valid when using a 24 MHz quartz. Have you come across a board where a different quartz is being used with OMAP-L138? Regards, Sudhakar From christian.riesch at omicron.at Fri Jan 20 04:10:28 2012 From: christian.riesch at omicron.at (Christian Riesch) Date: Fri, 20 Jan 2012 11:10:28 +0100 Subject: DA850 / OMAP-L138 / AM-1808 EMIFA Clk issues. In-Reply-To: References: <4F143A70.4040505@criticallink.com> <4F156CEB.4050803@criticallink.com> Message-ID: Hi Sudhakar, On Fri, Jan 20, 2012 at 11:01 AM, Rajashekhara, Sudhakar wrote: > Hi Christian, > > On Tue, Jan 17, 2012 at 18:23:52, Christian Riesch wrote: >> Hi Sudhakar, hi Mike, >> >> On Tue, Jan 17, 2012 at 1:43 PM, Michael Williamson >> wrote: >> > On 1/17/2012 12:39 AM, Rajashekhara, Sudhakar wrote: > > [...] > >> > >> > Well, that's all fine and swell, except we have OMAP-L138 platforms >> > (built using the MityDSP-L138 SOM) that use the EMIFA for other >> > devices than NAND, such as an FPGA (and no SDRAM). ?Dropping the default >> > 300 MHz OPP EMIFA speed from 100 MHz down to 60 MHz will directly translate >> > to a 40% reduction in potential bus bandwidth. ?If you are making this device >> > wide, it would really be nice to have an option that is more consistent >> > with option A and let the platform designer decide what rate the EMIFA >> > clock should run at based on his hardware requirements. >> >> In my opinion hardcoding OPPs in a SoC specific file >> (arch/arm/mach-davinci/da850.c) was a bad idea. Setting EMIFA clock to >> 1/5 of CPU rate may be fine for some boards, but for others it may be >> a bad decision. How about boards with input clock frequencies other >> than 24 MHz? Currently the OPP settings are only correct if a 24 MHz >> quartz or oscillator is used. So I think the OPPs should move out of >> the SoC specific file. >> > > Using a different oscillator is a perfectly valid use case but I was > wondering why anyone would do that? The OPP settings are defined and > are valid when using a 24 MHz quartz. Have you come across a board > where a different quartz is being used with OMAP-L138? Yes, my own board. I already had a 25MHz clock on the board so I used it to drive the SoC as well and saved a few components. However, I do not use frequency/voltage scaling, so there was no need to change the OPP configurations. I just want to point out that there are such use cases and if work on the OPP settings is done, it should be done in a way that allows other input clock frequencies than just 24 MHz. Regards, Christian From manjunath.hadli at ti.com Fri Jan 20 07:22:17 2012 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Fri, 20 Jan 2012 18:52:17 +0530 Subject: [PATCH v2 0/2] add dm365 specific media formats Message-ID: <1327065739-3362-1-git-send-email-manjunath.hadli@ti.com> add mediabus formats and pixel formats supported as part of dm365 vpfe device. The device supports media formats(transfer and storage) which include- 1: ALAW compressed bayer. 2: UV interleaved without Y (for resizer). 3: YDYC. Changes from previous version: 1: Added entries in subdev-formats.xml for V4L2_MBUS_FMT_YDYC8_1X16, V4L2_MBUS_FMT_UV8_1X8, V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8, V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8, V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8, V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8. 2: Added documentation of ALAW and UV8 pix format. Manjunath Hadli (2): media: add new mediabus format enums for dm365 v4l2: add new pixel formats supported on dm365 .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 ++++ Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62 +++++++ Documentation/DocBook/media/v4l/pixfmt.xml | 2 + Documentation/DocBook/media/v4l/subdev-formats.xml | 171 ++++++++++++++++++++ include/linux/v4l2-mediabus.h | 10 +- include/linux/videodev2.h | 9 + 6 files changed, 286 insertions(+), 2 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml From manjunath.hadli at ti.com Fri Jan 20 07:22:19 2012 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Fri, 20 Jan 2012 18:52:19 +0530 Subject: [PATCH v2 2/2] v4l2: add new pixel formats supported on dm365 In-Reply-To: <1327065739-3362-1-git-send-email-manjunath.hadli@ti.com> References: <1327065739-3362-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1327065739-3362-3-git-send-email-manjunath.hadli@ti.com> add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats to represent Bayer format frames compressed by A-LAW alogorithm, add V4L2_PIX_FMT_UV8 to represent storage of C data (UV interleved) only. Signed-off-by: Manjunath Hadli Cc: Laurent Pinchart --- .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 +++++++++++ Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62 ++++++++++++++++++++ Documentation/DocBook/media/v4l/pixfmt.xml | 2 + include/linux/videodev2.h | 9 +++ 4 files changed, 107 insertions(+), 0 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml new file mode 100644 index 0000000..8c1765c --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml @@ -0,0 +1,34 @@ + + + + V4L2_PIX_FMT_SRGGB10ALAW8 ('bBL8'), + V4L2_PIX_FMT_SGBRG10ALAW8 ('bgL8'), + V4L2_PIX_FMT_SGRBG10ALAW8 ('BGL8'), + V4L2_PIX_FMT_SBGGR10ALAW8 ('bRL8'), + + &manvol; + + + + V4L2_PIX_FMT_SRGGB10ALAW8 + + + V4L2_PIX_FMT_SGRBG10ALAW8 + + + V4L2_PIX_FMT_SGBRG10ALAW8 + + + V4L2_PIX_FMT_SBGGR10ALAW8 + + 10-bit Bayer formats compressed to 8 bits + + + Description + The following four pixel formats are raw sRGB / Bayer + formats with 10 bits per colour compressed to 8 bits each, + using the A-LAW algorithm. Each colour component consumes 8 + bits of memory. In other respects this format is similar to + . + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml new file mode 100644 index 0000000..e3e6b11 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml @@ -0,0 +1,62 @@ + + + V4L2_PIX_FMT_UV8 ('UV8') + &manvol; + + + V4L2_PIX_FMT_UV8 + UV plane interleaved + + + Description + In this format there is no Y plane, Only C plane. ie + (UV interleaved) + + + <constant>V4L2_PIX_FMT_UV8</constant> + pixel image + + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Cb00 + Cr00 + Cb01 + Cr01 + + + start + 4: + Cb10 + Cr10 + Cb11 + Cr11 + + + start + 8: + Cb20 + Cr20 + Cb21 + Cr21 + + + start + 12: + Cb30 + Cr30 + Cb31 + Cr31 + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index 9ddc57c..0b62750 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.< &sub-srggb8; &sub-sbggr16; &sub-srggb10; + &sub-srggb10alaw8; &sub-srggb12; @@ -696,6 +697,7 @@ information. &sub-packed-yuv; &sub-grey; + &sub-uv8; &sub-y10; &sub-y12; &sub-y10b; diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h index 012a296..36b6d91 100644 --- a/include/linux/videodev2.h +++ b/include/linux/videodev2.h @@ -338,6 +338,9 @@ struct v4l2_pix_format { #define V4L2_PIX_FMT_HM12 v4l2_fourcc('H', 'M', '1', '2') /* 8 YUV 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420 v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 line uv interleaved */ +/* Chrominance formats */ +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /* 8 UV 4:4 */ + /* two planes -- one Y, one Cr + Cb interleaved */ #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr 4:2:0 */ #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,12 @@ struct v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /* 10bit raw bayer DPCM compressed to 8 bits */ #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0') + /* 10bit raw bayer a-law compressed to 8 bits */ +#define V4L2_PIX_FMT_SRGGB10ALAW8 v4l2_fourcc('b', 'B', 'L', '8') +#define V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('b', 'g', 'L', '8') +#define V4L2_PIX_FMT_SGBRG10ALAW8 v4l2_fourcc('B', 'G', 'L', '8') +#define V4L2_PIX_FMT_SBGGR10ALAW8 v4l2_fourcc('b', 'R', 'L', '8') + /* * 10bit raw bayer, expanded to 16 bits * xxxxrrrrrrrrrrxxxxgggggggggg xxxxggggggggggxxxxbbbbbbbbbb... -- 1.6.2.4 From manjunath.hadli at ti.com Fri Jan 20 07:22:18 2012 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Fri, 20 Jan 2012 18:52:18 +0530 Subject: [PATCH v2 1/2] media: add new mediabus format enums for dm365 In-Reply-To: <1327065739-3362-1-git-send-email-manjunath.hadli@ti.com> References: <1327065739-3362-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1327065739-3362-2-git-send-email-manjunath.hadli@ti.com> add new enum entries for supporting the media-bus formats on dm365. These include some bayer and some non-bayer formats. V4L2_MBUS_FMT_YDYC8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used internal to the hardware by the resizer. V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format that is supported by dm365 hardware. Signed-off-by: Manjunath Hadli Cc: Laurent Pinchart --- Documentation/DocBook/media/v4l/subdev-formats.xml | 171 ++++++++++++++++++++ include/linux/v4l2-mediabus.h | 10 +- 2 files changed, 179 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532e..48d92bb 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -356,6 +356,9 @@ If the pixel components are DPCM-compressed, a mention of the DPCM compression and the number of bits per compressed pixel component. + If the pixel components are ALAW-compressed, a mention of the + ALAW compression and the number of bits per compressed pixel component. + The number of bus samples per pixel. Pixels that are wider than the bus width must be transferred in multiple samples. Common values are 1 and 2. @@ -572,6 +575,74 @@ r1 r0 + + V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 + 0x3015 + + - + - + - + - + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + + V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 + 0x3016 + + - + - + - + - + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + + V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 + 0x3017 + + - + - + - + - + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + + V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 + 0x3018 + + - + - + - + - + r7 + r6 + r5 + r4 + r3 + r2 + r1 + r0 + V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE 0x3003 @@ -965,6 +1036,56 @@ y1 y0 + + V4L2_MBUS_FMT_UV8_1X8 + 0x2015 + + - + - + - + - + - + - + - + - + - + - + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + V4L2_MBUS_FMT_UYVY8_1_5X8 0x2002 @@ -2415,6 +2536,56 @@ u1 u0 + + V4L2_MBUS_FMT_YDYC8_1X16 + 0x2014 + + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + d7 + d6 + d5 + d4 + d3 + d2 + d1 + d0 + + + + + + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + c7 + c6 + c5 + c4 + c3 + c2 + c1 + c0 + V4L2_MBUS_FMT_YUYV10_1X20 0x200d diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h index 5ea7f75..8d68fa1 100644 --- a/include/linux/v4l2-mediabus.h +++ b/include/linux/v4l2-mediabus.h @@ -47,8 +47,9 @@ enum v4l2_mbus_pixelcode { V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007, V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008, - /* YUV (including grey) - next is 0x2014 */ + /* YUV (including grey) - next is 0x2016 */ V4L2_MBUS_FMT_Y8_1X8 = 0x2001, + V4L2_MBUS_FMT_UV8_1X8 = 0x2015, V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002, V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003, V4L2_MBUS_FMT_YUYV8_1_5X8 = 0x2004, @@ -65,10 +66,11 @@ enum v4l2_mbus_pixelcode { V4L2_MBUS_FMT_VYUY8_1X16 = 0x2010, V4L2_MBUS_FMT_YUYV8_1X16 = 0x2011, V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012, + V4L2_MBUS_FMT_YDYC8_1X16 = 0x2014, V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d, V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e, - /* Bayer - next is 0x3015 */ + /* Bayer - next is 0x3019 */ V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001, V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013, V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002, @@ -77,6 +79,10 @@ enum v4l2_mbus_pixelcode { V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8 = 0x300c, V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 = 0x3009, V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8 = 0x300d, + V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015, + V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016, + V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017, + V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018, V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE = 0x3003, V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE = 0x3004, V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE = 0x3005, -- 1.6.2.4 From nsekhar at ti.com Fri Jan 20 10:46:48 2012 From: nsekhar at ti.com (Nori, Sekhar) Date: Fri, 20 Jan 2012 16:46:48 +0000 Subject: [PATCH v3] ARM: davinci: map default_queue to edma channels In-Reply-To: <1326956721-25158-1-git-send-email-hs@denx.de> References: <1326956721-25158-1-git-send-email-hs@denx.de> Message-ID: Hi Heiko, On Thu, Jan 19, 2012 at 12:35:21, Heiko Schocher wrote: > Default queue is expected to be a low-priority queue. > This way, long transfers on the default queue started > by the codec engine will not cause audio defects. > > Signed-off-by: Heiko Schocher > Signed-off-by: juha.kuikka at gmail.com > Reported-by: juha.kuikka at gmail.com Sign-off should include real name, so I changed these two lines to: Signed-off-by: Juha Kuikka Reported-by: Juha Kuikka before applying. Let me know if anyone has objections. Thanks, Sekhar From sshtylyov at mvista.com Fri Jan 20 12:45:15 2012 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Fri, 20 Jan 2012 21:45:15 +0300 Subject: [PATCH v2] DaVinci: can only power up domains on DM644x In-Reply-To: <3E54258959B69E4282D79E01AB1F32B7265471@DFLE34.ent.ti.com> References: <201109151829.49256.sshtylyov@ru.mvista.com> <201201062140.33712.sshtylyov@ru.mvista.com> <201201062148.32025.sshtylyov@ru.mvista.com> <3E54258959B69E4282D79E01AB1F32B7265471@DFLE34.ent.ti.com> Message-ID: <4F19B63B.1020306@mvista.com> Hello. On 01/12/2012 03:00 PM, Karicheri, Muralidharan wrote: > Sekhar & Sergei, > This will affect the new SoCs that have capabilities to power up different domains. Why do we need this enforcement? We are working on a DaVinci variant SoC that can do power up multiple domains Will their power-up procedure be the same as for DM644x? > (That is why I had a patch earlier to support > Multiple PD which is already part of the tree). So I don't want this patch to go through unless I see a reason for pushing this. Why you didn't voice your concern when Sekhar has suggested this approach? > Murali Karicheri > Software Design Engineer > email: m-karicheri2 at ti.com WBR, Sergei From nsekhar at ti.com Fri Jan 20 15:18:17 2012 From: nsekhar at ti.com (Sekhar Nori) Date: Sat, 21 Jan 2012 02:48:17 +0530 Subject: [PATCH] ARM: davinci: update mdio bus name Message-ID: <1327094297-1954-1-git-send-email-nsekhar@ti.com> Commit 5a05a8200a4359ef2bfe9094c137dee35cfdd516 ("davinci_emac: use an unique MDIO bus name") introduced during the v3.3 merge window updated the davinci mdio bus name to make it unique. Update the bus name in board files which use DaVinci MDIO bus to match the new name. Without this PHY is not detected with error like: PHY 0:01 not found net eth0: could not connect to phy 0:01 Tested on DM365 and DA850 EVMs. Cc: Florian Fainelli Cc: David S. Miller Signed-off-by: Sekhar Nori --- arch/arm/mach-davinci/board-da850-evm.c | 2 +- arch/arm/mach-davinci/board-dm365-evm.c | 2 +- arch/arm/mach-davinci/board-dm644x-evm.c | 2 +- arch/arm/mach-davinci/board-dm646x-evm.c | 2 +- arch/arm/mach-davinci/board-neuros-osd2.c | 2 +- arch/arm/mach-davinci/board-omapl138-hawk.c | 2 +- arch/arm/mach-davinci/board-sffsdr.c | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c index 6b22b54..d508890 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c @@ -44,7 +44,7 @@ #include #include -#define DA850_EVM_PHY_ID "0:00" +#define DA850_EVM_PHY_ID "davinci_mdio-0:00" #define DA850_LCD_PWR_PIN GPIO_TO_PIN(2, 8) #define DA850_LCD_BL_PIN GPIO_TO_PIN(2, 15) diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c index 346e1de..849311d 100644 --- a/arch/arm/mach-davinci/board-dm365-evm.c +++ b/arch/arm/mach-davinci/board-dm365-evm.c @@ -54,7 +54,7 @@ static inline int have_tvp7002(void) return 0; } -#define DM365_EVM_PHY_ID "0:01" +#define DM365_EVM_PHY_ID "davinci_mdio-0:01" /* * A MAX-II CPLD is used for various board control functions. */ diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index a64b49c..1247ecd 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -40,7 +40,7 @@ #include #include -#define DM644X_EVM_PHY_ID "0:01" +#define DM644X_EVM_PHY_ID "davinci_mdio-0:01" #define LXT971_PHY_ID (0x001378e2) #define LXT971_PHY_MASK (0xfffffff0) diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c index 6401755..872ac69 100644 --- a/arch/arm/mach-davinci/board-dm646x-evm.c +++ b/arch/arm/mach-davinci/board-dm646x-evm.c @@ -736,7 +736,7 @@ static struct davinci_uart_config uart_config __initdata = { .enabled_uarts = (1 << 0), }; -#define DM646X_EVM_PHY_ID "0:01" +#define DM646X_EVM_PHY_ID "davinci_mdio-0:01" /* * The following EDMA channels/slots are not being used by drivers (for * example: Timer, GPIO, UART events etc) on dm646x, hence they are being diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c index 6c4a164..8d34f51 100644 --- a/arch/arm/mach-davinci/board-neuros-osd2.c +++ b/arch/arm/mach-davinci/board-neuros-osd2.c @@ -39,7 +39,7 @@ #include #include -#define NEUROS_OSD2_PHY_ID "0:01" +#define NEUROS_OSD2_PHY_ID "davinci_mdio-0:01" #define LXT971_PHY_ID 0x001378e2 #define LXT971_PHY_MASK 0xfffffff0 diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c index e7c0c7c..45e8157 100644 --- a/arch/arm/mach-davinci/board-omapl138-hawk.c +++ b/arch/arm/mach-davinci/board-omapl138-hawk.c @@ -21,7 +21,7 @@ #include #include -#define HAWKBOARD_PHY_ID "0:07" +#define HAWKBOARD_PHY_ID "davinci_mdio-0:07" #define DA850_HAWK_MMCSD_CD_PIN GPIO_TO_PIN(3, 12) #define DA850_HAWK_MMCSD_WP_PIN GPIO_TO_PIN(3, 13) diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c index 0b136a8..31da3c5 100644 --- a/arch/arm/mach-davinci/board-sffsdr.c +++ b/arch/arm/mach-davinci/board-sffsdr.c @@ -42,7 +42,7 @@ #include #include -#define SFFSDR_PHY_ID "0:01" +#define SFFSDR_PHY_ID "davinci_mdio-0:01" static struct mtd_partition davinci_sffsdr_nandflash_partition[] = { /* U-Boot Environment: Block 0 * UBL: Block 1 -- 1.7.0.4 From hs at denx.de Mon Jan 23 02:56:04 2012 From: hs at denx.de (Heiko Schocher) Date: Mon, 23 Jan 2012 09:56:04 +0100 Subject: [RFC PATCH 4/7] ARM: davinci: net: davinci_emac: add OF support In-Reply-To: <1327308967-8092-1-git-send-email-hs@denx.de> References: <1327308967-8092-1-git-send-email-hs@denx.de> Message-ID: <1327308967-8092-5-git-send-email-hs@denx.de> add of support for the davinci_emac driver. Signed-off-by: Heiko Schocher Cc: davinci-linux-open-source at linux.davincidsp.com Cc: linux-arm-kernel at lists.infradead.org Cc: devicetree-discuss at lists.ozlabs.org Cc: netdev at vger.kernel.org Cc: Grant Likely Cc: Sekhar Nori Cc: Wolfgang Denk --- .../bindings/arm/davinci/davinci_emac.txt | 46 ++++++++ drivers/net/ethernet/ti/davinci_emac.c | 111 +++++++++++++++++++- 2 files changed, 156 insertions(+), 1 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt diff --git a/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt new file mode 100644 index 0000000..4e5dc8d --- /dev/null +++ b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt @@ -0,0 +1,46 @@ +* Texas Instruments Davinci EMAC + +This file provides information, what the davice node +for the davinci_emac interface contain. + +Required properties: +- compatible: "ti,davinci-emac"; +- reg: Offset and length of the register set for the device +- ctrl_reg_offset: offset to control register +- ctrl_mod_reg_offset: offset to control module register +- ctrl_ram_offset: offset to control module ram +- hw_ram_addr: hardware ram addr +- ctrl_ram_size: size of control module ram +- version: 1 (EMAC_VERSION_1 for DM644x) + 2 (EMAC_VERSION_2 for DM646x) +- phy-handle: Contains a phandle to an Ethernet PHY. + if not, davinci_emac driver defaults to 100/FULL +- interrupts: interrupt mapping for the davinci emac interrupts sources: + 4 sources: +- pinmux-handle: Contains a handle to configure the pinmux settings. + +Optional properties: +- local-mac-address : 6 bytes, mac address + +Example (enbw_cmc board): + eth0: emac at 1e20000 { + compatible = "ti,davinci-emac"; + reg = <0x220000 0x4000>; + ctrl_reg_offset = <0x3000>; + ctrl_mod_reg_offset = <0x2000>; + ctrl_ram_offset = <0>; + hw_ram_addr = <0>; + ctrl_ram_size = <0x2000>; + version = <1>; + local-mac-address = [ 00 00 00 00 00 00 ]; + interrupts = <33 + 34 + 35 + 36 + >; + interrupt-parent = <&intc>; + pinmux-handle = <&emac_pins>; + }; diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c index 794ac30..cad7a96 100644 --- a/drivers/net/ethernet/ti/davinci_emac.c +++ b/drivers/net/ethernet/ti/davinci_emac.c @@ -58,6 +58,12 @@ #include #include #include +#include +#include +#include +#include + +#include #include #include @@ -339,6 +345,9 @@ struct emac_priv { u32 rx_addr_type; atomic_t cur_tx; const char *phy_id; +#ifdef CONFIG_OF + struct device_node *phy_node; +#endif struct phy_device *phydev; spinlock_t lock; /*platform specific members*/ @@ -1582,6 +1591,7 @@ static int emac_dev_open(struct net_device *ndev) cpdma_ctlr_start(priv->dma); priv->phydev = NULL; + /* use the first phy on the bus if pdata did not give us a phy id */ if (!priv->phy_id) { struct device *phy; @@ -1759,6 +1769,104 @@ static const struct net_device_ops emac_netdev_ops = { #endif }; +#ifdef CONFIG_OF +static struct emac_platform_data + *davinci_emac_of_get_pdata(struct platform_device *pdev, + struct emac_priv *priv) +{ + struct device_node *np; + struct device_node *pinmux_np; + struct emac_platform_data *pdata = NULL; + const u8 *mac_addr; + u32 data; + int ret; + struct resource temp_res; + int irq; + int index = 0; + + np = of_find_compatible_node(NULL, NULL, "ti,davinci-emac"); + if (!np) + goto nodata; + + pdata = pdev->dev.platform_data; + if (!pdata) { + pdata = kzalloc(sizeof(struct emac_platform_data), GFP_KERNEL); + if (!pdata) + goto nodata; + } + + mac_addr = of_get_mac_address(np); + if (mac_addr) + memcpy(pdata->mac_addr, mac_addr, ETH_ALEN); + + ret = of_property_read_u32(np, "ctrl_reg_offset", &data); + if (!ret) + pdata->ctrl_reg_offset = data; + + ret = of_property_read_u32(np, "ctrl_mod_reg_offset", &data); + if (!ret) + pdata->ctrl_mod_reg_offset = data; + + ret = of_property_read_u32(np, "ctrl_ram_offset", &data); + if (!ret) + pdata->ctrl_ram_offset = data; + + ret = of_property_read_u32(np, "hw_ram_addr", &data); + if (!ret) + pdata->hw_ram_addr = data; + + ret = of_property_read_u32(np, "ctrl_ram_size", &data); + if (!ret) + pdata->ctrl_ram_size = data; + + ret = of_property_read_u32(np, "rmii_en", &data); + if (!ret) + pdata->rmii_en = data; + + ret = of_property_read_u32(np, "version", &data); + if (!ret) + pdata->version = data; + + ret = of_property_read_u32(np, "no_bd_ram", &data); + if (!ret) + pdata->ctrl_mod_reg_offset = data; + + priv->phy_node = of_parse_phandle(np, "phy-handle", 0); + if (!priv->phy_node) + pdata->phy_id = ""; + + if (!of_address_to_resource(np, 0, &temp_res)) + memcpy(&pdev->resource[0], &temp_res, sizeof(struct resource)); + + index = 0; + while (index < 4) { + irq = irq_of_parse_and_map(np, index); + if (irq > 0) { + temp_res.start = irq; + temp_res.end = irq; + temp_res.flags = IORESOURCE_IRQ; + memcpy(&pdev->resource[index + 1], &temp_res, + sizeof(struct resource)); + } + index++; + } + + pinmux_np = of_parse_phandle(np, "pinmux-handle", 0); + if (pinmux_np) + davinci_cfg_reg_of(pinmux_np); + + pdev->dev.platform_data = pdata; +nodata: + return pdata; +} +#else +static struct emac_platform_data + *davinci_emac_of_get_pdata(struct platform_device *pdev, + struct emac_priv *priv) +{ + return pdev->dev.platform_data; +} +#endif /** * davinci_emac_probe: EMAC device probe * @pdev: The DaVinci EMAC device that we are removing @@ -1802,7 +1910,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev) spin_lock_init(&priv->lock); - pdata = pdev->dev.platform_data; + pdata = davinci_emac_of_get_pdata(pdev, priv); if (!pdata) { dev_err(&pdev->dev, "no platform data\n"); rc = -ENODEV; @@ -1811,6 +1919,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev) /* MAC addr and PHY mask , RMII enable info from platform_data */ memcpy(priv->mac_addr, pdata->mac_addr, 6); + priv->phy_id = pdata->phy_id; priv->rmii_en = pdata->rmii_en; priv->version = pdata->version; -- 1.7.7.5 From hs at denx.de Mon Jan 23 02:56:06 2012 From: hs at denx.de (Heiko Schocher) Date: Mon, 23 Jan 2012 09:56:06 +0100 Subject: [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller In-Reply-To: <1327308967-8092-1-git-send-email-hs@denx.de> References: <1327308967-8092-1-git-send-email-hs@denx.de> Message-ID: <1327308967-8092-7-git-send-email-hs@denx.de> add OF support for the davinci nand controller. Signed-off-by: Heiko Schocher Cc: davinci-linux-open-source at linux.davincidsp.com Cc: linux-arm-kernel at lists.infradead.org Cc: devicetree-discuss at lists.ozlabs.org Cc: linux-mtd at lists.infradead.org Cc: David Woodhouse Cc: Grant Likely Cc: Sekhar Nori Cc: Wolfgang Denk --- .../devicetree/bindings/arm/davinci/nand.txt | 72 ++++++++++++++++++ drivers/mtd/nand/davinci_nand.c | 78 +++++++++++++++++++- 2 files changed, 148 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/davinci/nand.txt diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt b/Documentation/devicetree/bindings/arm/davinci/nand.txt new file mode 100644 index 0000000..7e8d6db --- /dev/null +++ b/Documentation/devicetree/bindings/arm/davinci/nand.txt @@ -0,0 +1,72 @@ +* Texas Instruments Davinci NAND + +This file provides information, what the device node for the +davinci nand interface contain. + +Required properties: +- compatible: "ti,davinci-nand"; +- reg : contain 2 offset/length values: + - offset and length for the access window + - offset and length for accessing the aemif control registers +- id: id of the controller + +Recommended properties : +- mask_ale: mask for ale +- mask_cle: mask for cle +- mask_chipsel: mask for chipselect +- ecc_mode: ECC mode, see NAND_ECC_* defines +- ecc_bits: used ECC bits +- options: nand options, defined in + include/linux/mtd/nand.h, grep for NAND_NO_AUTOINCR +- bbt_options: NAND_BBT_* defines + +Optional properties: +- pinmux-handle: contains a handle to configure the pinmux settings. +- timing-handle: contains a handle to setup aemif timing. + +Example (enbw_cmc board): +aemif at 60000000 { + compatible = "ti,davinci-aemif"; + #address-cells = <2>; + #size-cells = <1>; + reg = <0x68000000 0x80000>; + ranges = <2 0 0x60000000 0x02000000 + 3 0 0x62000000 0x02000000 + 4 0 0x64000000 0x02000000 + 5 0 0x66000000 0x02000000 + 6 0 0x68000000 0x02000000>; + nand_cs: cs3 at 68000000 { + compatible = "ti,davinci-cs"; + #address-cells = <1>; + #size-cells = <1>; + /* all timings in nanoseconds */ + cs = <3>; + asize = <0>; + ta = <0>; + rhold = <7>; + rstrobe = <42>; + rsetup = <7>; + whold = <7>; + wstrobe = <14>; + wsetup = <7>; + ew = <0>; + ss = <0>; + }; + nandflash at 3,0 { + compatible = "ti,davinci-nand"; + reg = <3 0x0 0x807ff + 6 0x0 0x8000>; + #address-cells = <1>; + #size-cells = <1>; + id = <1>; + mask_ale = <0>; + mask_cle = <0>; + mask_chipsel = <0>; + ecc_mode = <2>; + ecc_bits = <4>; + options = <0>; + bbt_options = <0x20000>; + pinmux-handle = <&nand_pins>; + timing-handle = <&nand_cs>; + }; +}; diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c index 6e56615..a1946c3 100644 --- a/drivers/mtd/nand/davinci_nand.c +++ b/drivers/mtd/nand/davinci_nand.c @@ -33,9 +33,12 @@ #include #include #include +#include +#include #include #include +#include /* * This is a device driver for the NAND flash controller found on the @@ -518,9 +521,76 @@ static struct nand_ecclayout hwecc4_2048 __initconst = { }, }; +#if defined(CONFIG_OF) +static const struct of_device_id davinci_nand_of_match[] = { + {.compatible = "ti,davinci-nand", }, + {}, +} +MODULE_DEVICE_TABLE(of, davinci_nand_of_match); + +static struct davinci_nand_pdata + *nand_davinci_get_pdata(struct platform_device *pdev) +{ + if ((pdev->dev.platform_data == NULL) && + (pdev->dev.of_node)) { + struct device_node *tmp_np; + struct davinci_nand_pdata *pdata; + u32 prop; + + pdata = kzalloc(sizeof(struct davinci_nand_pdata), + GFP_KERNEL); + pdev->dev.platform_data = pdata; + if (!pdata) + return NULL; + if (!of_property_read_u32(pdev->dev.of_node, "id", + &prop)) + pdev->id = prop; + if (!of_property_read_u32(pdev->dev.of_node, "mask_ale", + &prop)) + pdata->mask_ale = prop; + if (!of_property_read_u32(pdev->dev.of_node, "mask_cle", + &prop)) + pdata->mask_cle = prop; + if (!of_property_read_u32(pdev->dev.of_node, "mask_chipsel", + &prop)) + pdata->mask_chipsel = prop; + if (!of_property_read_u32(pdev->dev.of_node, "ecc_mode", + &prop)) + pdata->ecc_mode = prop; + if (!of_property_read_u32(pdev->dev.of_node, "ecc_bits", + &prop)) + pdata->ecc_bits = prop; + if (!of_property_read_u32(pdev->dev.of_node, "options", + &prop)) + pdata->options = prop; + if (!of_property_read_u32(pdev->dev.of_node, "bbt_options", + &prop)) + pdata->bbt_options = prop; + tmp_np = of_parse_phandle(pdev->dev.of_node, + "pinmux-handle", 0); + if (tmp_np) + davinci_cfg_reg_of(tmp_np); + + tmp_np = of_parse_phandle(pdev->dev.of_node, + "timing-handle", 0); + if (tmp_np) + davinci_aemif_setup_timing_of(tmp_np); + } + + return pdev->dev.platform_data; +} +#else +#define davinci_nand_of_match NULL +static struct davinci_nand_pdata + *nand_davinci_get_pdata(struct platform_device *pdev) +{ + return pdev->dev.platform_data; +} +#endif + static int __init nand_davinci_probe(struct platform_device *pdev) { - struct davinci_nand_pdata *pdata = pdev->dev.platform_data; + struct davinci_nand_pdata *pdata; struct davinci_nand_info *info; struct resource *res1; struct resource *res2; @@ -530,6 +600,7 @@ static int __init nand_davinci_probe(struct platform_device *pdev) uint32_t val; nand_ecc_modes_t ecc_mode; + pdata = nand_davinci_get_pdata(pdev); /* insist on board-specific configuration */ if (!pdata) return -ENODEV; @@ -812,16 +883,19 @@ static int __exit nand_davinci_remove(struct platform_device *pdev) } static struct platform_driver nand_davinci_driver = { + .probe = nand_davinci_probe, .remove = __exit_p(nand_davinci_remove), .driver = { .name = "davinci_nand", + .owner = THIS_MODULE, + .of_match_table = davinci_nand_of_match, }, }; MODULE_ALIAS("platform:davinci_nand"); static int __init nand_davinci_init(void) { - return platform_driver_probe(&nand_davinci_driver, nand_davinci_probe); + return platform_driver_register(&nand_davinci_driver); } module_init(nand_davinci_init); -- 1.7.7.5 From hs at denx.de Mon Jan 23 02:56:02 2012 From: hs at denx.de (Heiko Schocher) Date: Mon, 23 Jan 2012 09:56:02 +0100 Subject: [RFC PATCH 2/7 v2] ARM: davinci: configure davinci aemif chipselects through OF In-Reply-To: <1327308967-8092-1-git-send-email-hs@denx.de> References: <1327308967-8092-1-git-send-email-hs@denx.de> Message-ID: <1327308967-8092-3-git-send-email-hs@denx.de> Add support for configuring the aemif timing registers through device tree. Introduce new compatible property "ti,davinci-cs", see full description in Documentation/devicetree/bindings/arm/davinci/aemif.txt Signed-off-by: Heiko Schocher Cc: davinci-linux-open-source at linux.davincidsp.com Cc: devicetree-discuss at lists.ozlabs.org Cc: linux-arm-kernel at lists.infradead.org Cc: Grant Likely Cc: Sekhar Nori Cc: Kevin Hilman Cc: Wolfgang Denk Cc: Sergei Shtylyov --- - changes for v2 - add comment from Sergei Shtylyov: - use of_property_read_u32() - Conding Style changes - add comment from Sekhar Nori: - add patch description - use davinci_aemif_setup_timing - change compatible node to "ti,davinci-aemif" - not moved to mfd, as mentioned in this discussion: http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-arm-davinci-configure-davinci-aemif-chipselects-through-OF-td7059739.html instead use a phandle in the DTS, so drivers which uses the davinci aemif, can call davinci_aemif_setup_timing_of() This is just thought as an RFC ... The enbw_cmc board support not really need to setup this bus timings, as they are setup in U-Boot ... but I want to post this, as I think, it is a nice to have ... as an example used in the davinci nand controller OF support patch, in this patchserie. .../devicetree/bindings/arm/davinci/aemif.txt | 119 ++++++++++++++++++++ arch/arm/mach-davinci/aemif.c | 86 ++++++++++++++- arch/arm/mach-davinci/include/mach/aemif.h | 1 + 3 files changed, 205 insertions(+), 1 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/davinci/aemif.txt diff --git a/Documentation/devicetree/bindings/arm/davinci/aemif.txt b/Documentation/devicetree/bindings/arm/davinci/aemif.txt new file mode 100644 index 0000000..0dbb842 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/davinci/aemif.txt @@ -0,0 +1,119 @@ +* Texas Instruments Davinci AEMIF + +This file provides information, what the device node for the +davinci aemif interface contain. + +Required properties: +- compatible: "ti,davinci-aemif"; +- #address-cells : Should be either two or three. The first cell is the + chipselect number, and the remaining cells are the + offset into the chipselect. +- #size-cells : Either one or two, depending on how large each chipselect + can be. +- ranges : Each range corresponds to a single chipselect, and cover + the entire access window as configured. + +Optional properties: +- none + +Optional subnodes: +- Chipselect setup: + - compatible: "ti,davinci-cs"; + - #address-cells = <1>; + - #size-cells = <1>; + + Timing setup, all timings in nanoseconds + - cs: chipselect (value 2,3,4 or 5) + - asize: Asynchronous Data Bus Width. + value: + 0: 8 bit + 1: 16 bit + - ta: Minimum Turn-Around time. + - rhold: Read hold width + - rstrobe: Read strobe width + - rsetup: Read setup width + - whold: Write hold width + - wstrobe: Write strobe width + - wsetup: Write setup width + - ew: Extend Wait bit + value: + 0: Extended wait cycles disabled. + 1: Extended wait cycles enabled. + - ss: Select Strobe bit. + value: + 0: Normal Mode enabled. + 1: Select Strobe Mode enabled. +- CFI driver: + see: Documentation/devicetree/bindings/mtd/mtd-physmap.txt + +Example (enbw_cmc board): + aemif at 60000000 { + compatible = "ti,davinci-aemif"; + #address-cells = <2>; + #size-cells = <1>; + reg = <0x68000000 0x80000>; + ranges = <2 0 0x60000000 0x02000000 + 3 0 0x62000000 0x02000000 + 4 0 0x64000000 0x02000000 + 5 0 0x66000000 0x02000000 + 6 0 0x68000000 0x02000000>; + cs2 at 68000000 { + compatible = "ti,davinci-cs"; + #address-cells = <1>; + #size-cells = <1>; + /* all timings in nanoseconds */ + cs = <2>; + asize = <1>; + ta = <0>; + rhold = <7>; + rstrobe = <42>; + rsetup = <14>; + whold = <7>; + wstrobe = <42>; + wsetup = <14>; + ew = <0>; + ss = <0>; + }; + flash at 2,0 { + compatible = "cfi-flash"; + reg = <2 0x0 0x400000>; + #address-cells = <1>; + #size-cells = <1>; + bank-width = <2>; + device-width = <2>; + }; + nand_cs: cs3 at 68000000 { + compatible = "ti,davinci-cs"; + #address-cells = <1>; + #size-cells = <1>; + /* all timings in nanoseconds */ + cs = <3>; + asize = <0>; + ta = <0>; + rhold = <7>; + rstrobe = <42>; + rsetup = <7>; + whold = <7>; + wstrobe = <14>; + wsetup = <7>; + ew = <0>; + ss = <0>; + }; + nandflash at 3,0 { + compatible = "ti,davinci-nand"; + reg = <3 0x0 0x807ff + 6 0x0 0x8000>; + #address-cells = <1>; + #size-cells = <1>; + mask_ale = <0>; + mask_cle = <0>; + mask_chipsel = <0>; + ecc_mode = <2>; + ecc_bits = <4>; + options = <0>; + bbt_options = <0x20000>; + pinmux-handle = <&nand_pins>; + timing-handle = <&nand_cs>; + }; + + }; diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c index 1ce70a9..e3d94a5 100644 --- a/arch/arm/mach-davinci/aemif.c +++ b/arch/arm/mach-davinci/aemif.c @@ -13,12 +13,14 @@ #include #include #include +#include +#include #include #include /* Timing value configuration */ - +#define ASIZE(x) (x) #define TA(x) ((x) << 2) #define RHOLD(x) ((x) << 4) #define RSTROBE(x) ((x) << 7) @@ -26,7 +28,10 @@ #define WHOLD(x) ((x) << 17) #define WSTROBE(x) ((x) << 20) #define WSETUP(x) ((x) << 26) +#define EW(x) ((x) << 30) +#define SS(x) ((x) << 31) +#define ASIZE_MAX 0x1 #define TA_MAX 0x3 #define RHOLD_MAX 0x7 #define RSTROBE_MAX 0x3f @@ -34,6 +39,8 @@ #define WHOLD_MAX 0x7 #define WSTROBE_MAX 0x3f #define WSETUP_MAX 0xf +#define EW_MAX 0x1 +#define SS_MAX 0x1 #define TIMING_MASK (TA(TA_MAX) | \ RHOLD(RHOLD_MAX) | \ @@ -131,3 +138,80 @@ int davinci_aemif_setup_timing(struct davinci_aemif_timing *t, return 0; } EXPORT_SYMBOL(davinci_aemif_setup_timing); + +#if defined(CONFIG_OF) +static int dv_get_value(struct device_node *np, const char *name) +{ + u32 data; + int ret; + + ret = of_property_read_u32(np, name, &data); + if (ret != 0) + return ret; + + return data; +} + +int davinci_aemif_setup_timing_of(struct device_node *np) +{ + struct device_node *parent; + struct davinci_aemif_timing t; + void __iomem *base; + unsigned val; + int asize, ew, ss; + int cs; + unsigned offset; + int ret; + + if (!np) + return -ENODEV; + + parent = np->parent; + if (!np) + return -ENODEV; + + base = of_iomap(parent, 0); + if (!base) + return -EINVAL; + + cs = dv_get_value(np, "cs"); + if (cs < 2) + return -EINVAL; + + t.ta = dv_get_value(np, "ta"); + t.rhold = dv_get_value(np, "rhold"); + t.rstrobe = dv_get_value(np, "rstrobe"); + t.rsetup = dv_get_value(np, "rsetup"); + t.whold = dv_get_value(np, "whold"); + t.wstrobe = dv_get_value(np, "wstrobe"); + t.wsetup = dv_get_value(np, "wsetup"); + + ret = davinci_aemif_setup_timing(&t, base, cs); + if (ret != 0) + return ret; + + /* setup none timing paramters */ + offset = A1CR_OFFSET + cs * 4; + asize = dv_get_value(np, "asize"); + ew = dv_get_value(np, "ew"); + ss = dv_get_value(np, "ss"); + val = __raw_readl(base + offset); + val &= TIMING_MASK; + val |= (asize & ACR_ASIZE_MASK); + if (ew) + val |= ACR_EW_MASK; + if (ss) + val |= ACR_SS_MASK; + + __raw_writel(val, base + offset); + + iounmap(base); + return 0; +} +#else +int davinci_aemif_setup_timing_of(struct device_node *np) +{ + return 0; +} +#endif +EXPORT_SYMBOL(davinci_aemif_setup_timing_of); diff --git a/arch/arm/mach-davinci/include/mach/aemif.h b/arch/arm/mach-davinci/include/mach/aemif.h index 05b2934..f3bbec6 100644 --- a/arch/arm/mach-davinci/include/mach/aemif.h +++ b/arch/arm/mach-davinci/include/mach/aemif.h @@ -33,4 +33,5 @@ struct davinci_aemif_timing { int davinci_aemif_setup_timing(struct davinci_aemif_timing *t, void __iomem *base, unsigned cs); +int davinci_aemif_setup_timing_of(struct device_node *np); #endif -- 1.7.7.5 From hs at denx.de Mon Jan 23 02:56:01 2012 From: hs at denx.de (Heiko Schocher) Date: Mon, 23 Jan 2012 09:56:01 +0100 Subject: [RFC PATCH 1/7] ARM: davinci, intc: Add OF support for TI interrupt controller In-Reply-To: <1327308967-8092-1-git-send-email-hs@denx.de> References: <1327308967-8092-1-git-send-email-hs@denx.de> Message-ID: <1327308967-8092-2-git-send-email-hs@denx.de> Add a function to initialize the davinci interrupt controller (INTC) using a device tree node. Signed-off-by: Heiko Schocher Cc: davinci-linux-open-source at linux.davincidsp.com Cc: linux-arm-kernel at lists.infradead.org Cc: devicetree-discuss at lists.ozlabs.org Cc: Grant Likely Cc: Sekhar Nori Cc: Wolfgang Denk --- .../devicetree/bindings/arm/davinci/intc.txt | 26 ++++++++++ arch/arm/mach-davinci/cp_intc.c | 51 ++++++++++++++++++++ arch/arm/mach-davinci/include/mach/cp_intc.h | 1 + 3 files changed, 78 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/davinci/intc.txt diff --git a/Documentation/devicetree/bindings/arm/davinci/intc.txt b/Documentation/devicetree/bindings/arm/davinci/intc.txt new file mode 100644 index 0000000..dac2f69 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/davinci/intc.txt @@ -0,0 +1,26 @@ +* TI Davinci Interrupt Controller + +davinci are using a TI interrupt controller that can support several +configurable number of interrupts. + +Main node required properties: + +- compatible : should be: + "ti,davinci-intc" +- interrupt-controller : Identifies the node as an interrupt controller +- #interrupt-cells : Specifies the number of cells needed to encode an + interrupt source. The type shall be a and the value shall be 1. + + The cell contains the interrupt number in the range [0-128]. +- ti,intc-size: Number of interrupts handled by the interrupt controller. +- reg: physical base address and size of the intc registers map. + +Example: + + intc: interrupt-controller at 1 { + compatible = "ti,davinci-intc"; + interrupt-controller; + #interrupt-cells = <1>; + ti,intc-size = <101>; + reg = <0xfffee000 0x2000>; + }; diff --git a/arch/arm/mach-davinci/cp_intc.c b/arch/arm/mach-davinci/cp_intc.c index f83152d..2c6e2e4 100644 --- a/arch/arm/mach-davinci/cp_intc.c +++ b/arch/arm/mach-davinci/cp_intc.c @@ -11,7 +11,11 @@ #include #include +#include #include +#include +#include +#include #include #include @@ -175,3 +179,50 @@ void __init cp_intc_init(void) /* Enable global interrupt */ cp_intc_write(1, CP_INTC_GLOBAL_ENABLE); } + +#ifdef CONFIG_OF +int __init dv_intc_of_init(struct device_node *node, struct device_node *parent) +{ + struct resource res; + u32 nr_irqs; + + if (WARN_ON(!node)) + return -ENODEV; + + if (of_address_to_resource(node, 0, &res)) { + WARN(1, "unable to get intc registers\n"); + return -EINVAL; + } + + davinci_soc_info.intc_base = res.start; + if (WARN_ON(!davinci_soc_info.intc_base)) + return -EINVAL; + + if (of_property_read_u32(node, "ti,intc-size", &nr_irqs)) { + WARN(1, "unable to get intc-size\n"); + return -EINVAL; + } + davinci_soc_info.intc_irq_num = nr_irqs; + davinci_soc_info.intc_type = DAVINCI_INTC_TYPE_CP_INTC; + + cp_intc_init(); + irq_domain_add_simple(node, 0); + + return 0; +} + +static struct of_device_id irq_match[] __initdata = { + { .compatible = "ti,davinci-intc", .data = dv_intc_of_init, }, + { } +}; + +void __init davinci_init_irq(void) +{ + of_irq_init(irq_match); +} +#else +void __init davinci_init_irq(void) +{ + cp_intc_init(); +} +#endif diff --git a/arch/arm/mach-davinci/include/mach/cp_intc.h b/arch/arm/mach-davinci/include/mach/cp_intc.h index 4e8190e..d674b95 100644 --- a/arch/arm/mach-davinci/include/mach/cp_intc.h +++ b/arch/arm/mach-davinci/include/mach/cp_intc.h @@ -52,5 +52,6 @@ #define CP_INTC_VECTOR_ADDR(n) (0x2000 + (n << 2)) void __init cp_intc_init(void); +void __init davinci_init_irq(void); #endif /* __ASM_HARDWARE_CP_INTC_H */ -- 1.7.7.5 From hs at denx.de Mon Jan 23 02:56:03 2012 From: hs at denx.de (Heiko Schocher) Date: Mon, 23 Jan 2012 09:56:03 +0100 Subject: [RFC PATCH 3/7] ARM: davinci: mux: add OF support In-Reply-To: <1327308967-8092-1-git-send-email-hs@denx.de> References: <1327308967-8092-1-git-send-email-hs@denx.de> Message-ID: <1327308967-8092-4-git-send-email-hs@denx.de> add support for configuring the pinmux on davinci SoC through OF. Signed-off-by: Heiko Schocher Cc: davinci-linux-open-source at linux.davincidsp.com Cc: linux-arm-kernel at lists.infradead.org Cc: devicetree-discuss at lists.ozlabs.org Cc: Grant Likely Cc: Sekhar Nori Cc: Wolfgang Denk --- This patch is just a RFC, as I want to get rid of the pin setup code in board code ... This patch introduces a davinci_cfg_reg_of() function, which davinci drivers can call, if they found a pinmux-handle, so used in the following drivers in this patchserie: drivers/net/ethernet/ti/davinci_emac drivers/i2c/busses/i2c-davinci.c drivers/mtd/nand/davinci_nand.c Comments are welcome. .../devicetree/bindings/arm/davinci/mux.txt | 40 +++++++++++ arch/arm/mach-davinci/include/mach/mux.h | 2 + arch/arm/mach-davinci/mux.c | 73 +++++++++++++++++++- 3 files changed, 114 insertions(+), 1 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/davinci/mux.txt diff --git a/Documentation/devicetree/bindings/arm/davinci/mux.txt b/Documentation/devicetree/bindings/arm/davinci/mux.txt new file mode 100644 index 0000000..ecb026a --- /dev/null +++ b/Documentation/devicetree/bindings/arm/davinci/mux.txt @@ -0,0 +1,40 @@ +* Texas Instruments Davinci pinmux + +This file provides information, what the device node for the +davinci pinmux interface contain. + +Required properties: +- compatible: "ti,davinci-pinmux"; +- pins : contains a table with the following colums: + mux register: pinmux register + register offset: offset in register, which to change + mode mask: mode mask + mode value: mode value + +Optional properties: +- none + +Example (enbw_cmc board): + emac_pins: pinmux at 1c14120 { + compatible = "ti,davinci-pinmux"; + reg = <0x14120 0x1000>; + pins = < /* muxreg maskoff modemsk muxmode */ + 2 4 15 8 /* MII TXEN */ + 2 8 15 8 /* MII TXCLK */ + 2 12 15 8 /* MII COL */ + 2 16 15 8 /* MII TXD_3 */ + 2 20 15 8 /* MII TXD_2 */ + 2 24 15 8 /* MII TXD_1 */ + 2 28 15 8 /* MII TXD_0 */ + 3 8 15 8 /* MII RXER */ + 3 12 15 8 /* MII CRS */ + 3 0 15 8 /* MII RXCLK */ + 3 4 15 8 /* MII RXDV */ + 3 16 15 8 /* MII RXD_3 */ + 3 20 15 8 /* MII RXD_2 */ + 3 24 15 8 /* MII RXD_1 */ + 3 28 15 8 /* MII RXD_0 */ + 4 0 15 8 /* MDIO CLK */ + 4 4 15 8 /* MDIO D */ + >; + }; diff --git a/arch/arm/mach-davinci/include/mach/mux.h b/arch/arm/mach-davinci/include/mach/mux.h index a7e92fc..3a62857 100644 --- a/arch/arm/mach-davinci/include/mach/mux.h +++ b/arch/arm/mach-davinci/include/mach/mux.h @@ -1205,6 +1205,7 @@ enum davinci_tnetv107x_index { /* setup pin muxing */ extern int davinci_cfg_reg(unsigned long reg_cfg); extern int davinci_cfg_reg_list(const short pins[]); +extern int davinci_cfg_reg_of(struct device_node *); #else /* boot loader does it all (no warnings from CONFIG_DAVINCI_MUX_WARNINGS) */ static inline int davinci_cfg_reg(unsigned long reg_cfg) { return 0; } @@ -1212,6 +1213,7 @@ static inline int davinci_cfg_reg_list(const short pins[]) { return 0; } +static int davinci_cfg_reg_of(struct device_node *) { return 0; }; #endif #endif /* __INC_MACH_MUX_H */ diff --git a/arch/arm/mach-davinci/mux.c b/arch/arm/mach-davinci/mux.c index f34a8dc..6b38072 100644 --- a/arch/arm/mach-davinci/mux.c +++ b/arch/arm/mach-davinci/mux.c @@ -18,18 +18,21 @@ #include #include #include +#include +#include +#include #include #include static void __iomem *pinmux_base; +static DEFINE_SPINLOCK(mux_spin_lock); /* * Sets the DAVINCI MUX register based on the table */ int __init_or_module davinci_cfg_reg(const unsigned long index) { - static DEFINE_SPINLOCK(mux_spin_lock); struct davinci_soc_info *soc_info = &davinci_soc_info; unsigned long flags; const struct mux_config *cfg; @@ -98,6 +101,74 @@ int __init_or_module davinci_cfg_reg(const unsigned long index) } EXPORT_SYMBOL(davinci_cfg_reg); +#ifdef CONFIG_OF +int davinci_cfg_reg_of(struct device_node *np) +{ + unsigned long flags; + int pinmux_map_len; + const unsigned int *pinmux_map; + u32 muxreg, maskoff, modemsk, muxmode; + unsigned int reg_orig = 0, reg = 0; + unsigned int mask, warn = 0; + + pinmux_map = of_get_property(np, "pins", &pinmux_map_len); + if (pinmux_map == NULL) { + printk(KERN_ERR "pins is not set!\n"); + return -EINVAL; + } + + pinmux_map_len /= sizeof(unsigned int); + if ((pinmux_map_len % 4) != 0) { + printk(KERN_ERR "pins format wrong!\n"); + return -EINVAL; + } + + if (!pinmux_base) { + pinmux_base = of_iomap(np, 0); + if (WARN_ON(!pinmux_base)) + return -ENOMEM; + } + + while (pinmux_map_len > 0) { + muxreg = be32_to_cpu(pinmux_map[0]); + maskoff = be32_to_cpu(pinmux_map[1]); + modemsk = be32_to_cpu(pinmux_map[2]); + muxmode = be32_to_cpu(pinmux_map[3]); + + /* Update the mux register in question */ + if (modemsk) { + unsigned tmp1, tmp2; + + spin_lock_irqsave(&mux_spin_lock, flags); + reg_orig = __raw_readl(pinmux_base + muxreg); + + mask = (modemsk << maskoff); + tmp1 = reg_orig & mask; + reg = reg_orig & ~mask; + + tmp2 = (muxmode << maskoff); + reg |= tmp2; + + if (tmp1 != tmp2) + warn = 1; + + __raw_writel(reg, pinmux_base + muxreg); + spin_unlock_irqrestore(&mux_spin_lock, flags); + } + pinmux_map += 4; + pinmux_map_len -= 4; + } + + return 0; +} +#else +int davinci_cfg_reg_of(struct device_node *np) +{ + return 0; +} +#endif +EXPORT_SYMBOL(davinci_cfg_reg_of); + int __init_or_module davinci_cfg_reg_list(const short pins[]) { int i, error = -EINVAL; -- 1.7.7.5 From hs at denx.de Mon Jan 23 02:56:00 2012 From: hs at denx.de (Heiko Schocher) Date: Mon, 23 Jan 2012 09:56:00 +0100 Subject: [RFC PATCH 0/7] ARM: davinci: add support for the am1808 based enbw_cmc board Message-ID: <1327308967-8092-1-git-send-email-hs@denx.de> add support for the davinci am1808 based enbw_cmc board. This is thought as a RFC patchserie, as this patches surely have to be discussed: - ARM: davinci: configure davinci aemif chipselects through OF not moved to mfd, as mentioned in this discussion: http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-arm-davinci-configure-davinci-aemif-chipselects-through-OF-td7059739.html instead use a phandle in the DTS, so drivers which uses the davinci aemif, can call davinci_aemif_setup_timing_of() This is just thought as an RFC ... The enbw_cmc board support not really need to setup this bus timings, as they are setup in U-Boot ... but I want to post this, as I think, it is a nice to have, and I am not really sure, if this has to be a MFD device (If so, all bus interfaces for other SoCs should be converted also to MFD devices) ... as an example how this can be used I add this to the davinci nand controller OF support patch, in this patchserie. - ARM: davinci: mux: add OF support I want to get rid of the pin setup code in board code ... This patch introduces a davinci_cfg_reg_of() function, which davinci drivers can call, if they found a "pinmux-handle", so used in the following drivers in this patchserie: drivers/net/ethernet/ti/davinci_emac drivers/i2c/busses/i2c-davinci.c drivers/mtd/nand/davinci_nand.c - post this board support with USB support, even though USB is only working with the 10 ms "workaround", posted here: http://comments.gmane.org/gmane.linux.usb.general/54505 I see this issue also on the AM1808 TMDXEXP1808L evalboard. - MMC and USB are not using OF support yet, ideas how to port this are welcome. I need for USB and MMC board specific callbacks, how to solve this with OF support? Signed-off-by: Heiko Schocher Cc: linux-arm-kernel at lists.infradead.org Cc: devicetree-discuss at lists.ozlabs.org Cc: davinci-linux-open-source at linux.davincidsp.com Cc: linux-mtd at lists.infradead.org Cc: linux-i2c at vger.kernel.org Cc: netdev at vger.kernel.org Cc: David Woodhouse Cc: Ben Dooks Cc: Wolfram Sang Cc: Sekhar Nori Cc: Kevin Hilman Cc: Wolfgang Denk Heiko Schocher (7): ARM: davinci, intc: Add OF support for TI interrupt controller ARM: davinci: configure davinci aemif chipselects through OF ARM: davinci: mux: add OF support ARM: davinci: net: davinci_emac: add OF support ARM: davinci: i2c: add OF support ARM: mtd: nand: davinci: add OF support for davinci nand controller ARM: davinci: add support for the am1808 based enbw_cmc board .../devicetree/bindings/arm/davinci/aemif.txt | 119 ++++++ .../bindings/arm/davinci/davinci_emac.txt | 46 +++ .../devicetree/bindings/arm/davinci/i2c.txt | 39 ++ .../devicetree/bindings/arm/davinci/intc.txt | 26 ++ .../devicetree/bindings/arm/davinci/mux.txt | 40 ++ .../devicetree/bindings/arm/davinci/nand.txt | 72 ++++ arch/arm/boot/dts/enbw_cmc.dts | 286 +++++++++++++++ arch/arm/configs/enbw_cmc_defconfig | 125 +++++++ arch/arm/mach-davinci/Kconfig | 8 + arch/arm/mach-davinci/Makefile | 1 + arch/arm/mach-davinci/aemif.c | 86 +++++- arch/arm/mach-davinci/board-enbw-cmc.c | 384 ++++++++++++++++++++ arch/arm/mach-davinci/cp_intc.c | 51 +++ arch/arm/mach-davinci/include/mach/aemif.h | 1 + arch/arm/mach-davinci/include/mach/cp_intc.h | 1 + arch/arm/mach-davinci/include/mach/mux.h | 2 + arch/arm/mach-davinci/include/mach/uncompress.h | 1 + arch/arm/mach-davinci/mux.c | 73 ++++- drivers/i2c/busses/i2c-davinci.c | 43 +++ drivers/mtd/nand/davinci_nand.c | 78 ++++- drivers/net/ethernet/ti/davinci_emac.c | 111 ++++++- 21 files changed, 1588 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/davinci/aemif.txt create mode 100644 Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt create mode 100644 Documentation/devicetree/bindings/arm/davinci/intc.txt create mode 100644 Documentation/devicetree/bindings/arm/davinci/mux.txt create mode 100644 Documentation/devicetree/bindings/arm/davinci/nand.txt create mode 100644 arch/arm/boot/dts/enbw_cmc.dts create mode 100644 arch/arm/configs/enbw_cmc_defconfig create mode 100644 arch/arm/mach-davinci/board-enbw-cmc.c -- 1.7.7.5 From hs at denx.de Mon Jan 23 02:56:05 2012 From: hs at denx.de (Heiko Schocher) Date: Mon, 23 Jan 2012 09:56:05 +0100 Subject: [RFC PATCH 5/7] ARM: davinci: i2c: add OF support In-Reply-To: <1327308967-8092-1-git-send-email-hs@denx.de> References: <1327308967-8092-1-git-send-email-hs@denx.de> Message-ID: <1327308967-8092-6-git-send-email-hs@denx.de> add of support for the davinci i2c driver. Signed-off-by: Heiko Schocher Cc: davinci-linux-open-source at linux.davincidsp.com Cc: linux-arm-kernel at lists.infradead.org Cc: devicetree-discuss at lists.ozlabs.org Cc: linux-i2c at vger.kernel.org Cc: Ben Dooks Cc: Wolfram Sang Cc: Grant Likely Cc: Sekhar Nori Cc: Wolfgang Denk --- .../devicetree/bindings/arm/davinci/i2c.txt | 39 ++++++++++++++++++ drivers/i2c/busses/i2c-davinci.c | 43 ++++++++++++++++++++ 2 files changed, 82 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt b/Documentation/devicetree/bindings/arm/davinci/i2c.txt new file mode 100644 index 0000000..94ec670 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt @@ -0,0 +1,39 @@ +* Texas Instruments Davinci I2C + +This file provides information, what the device node for the +davinci i2c interface contain. + +Required properties: +- compatible: "ti,davinci-i2c"; +- reg : Offset and length of the register set for the device +- id: id of the controller + +Recommended properties : +- interrupts : where a is the interrupt number and b is a + field that represents an encoding of the sense and level + information for the interrupt. +- interrupt-parent : the phandle for the interrupt controller that + services interrupts for this device. +- clock-frequency : desired I2C bus clock frequency in Hz. + +Optional properties: +- bus-delay: bus delay in usec +- pinmux-handle: Contains a handle to configure the pinmux settings. + +Example (enbw_cmc board): + i2c at 1c22000 { + compatible = "ti,davinci-i2c"; + reg = <0x22000 0x1000>; + clock-frequency = <100000>; + interrupts = <15 2>; + interrupt-parent = <&intc>; + id = <1>; + pinmux-handle = <&i2c1_pins>; + #address-cells = <1>; + #size-cells = <0>; + + dtt at 48 { + compatible = "national,lm75"; + reg = <0x48>; + }; + }; diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c index a76d85f..6f59fae 100644 --- a/drivers/i2c/busses/i2c-davinci.c +++ b/drivers/i2c/busses/i2c-davinci.c @@ -38,9 +38,12 @@ #include #include #include +#include +#include #include #include +#include /* ----- global defines ----------------------------------------------- */ @@ -635,6 +638,16 @@ static struct i2c_algorithm i2c_davinci_algo = { .functionality = i2c_davinci_func, }; +#if defined(CONFIG_OF) +static const struct of_device_id davinci_i2c_of_match[] = { + {.compatible = "ti,davinci-i2c", }, + {}, +} +MODULE_DEVICE_TABLE(of, davinci_i2c_of_match); +#else +#define davinci_i2c_of_match NULL +#endif + static int davinci_i2c_probe(struct platform_device *pdev) { struct davinci_i2c_dev *dev; @@ -676,7 +689,34 @@ static int davinci_i2c_probe(struct platform_device *pdev) dev->irq = irq->start; platform_set_drvdata(pdev, dev); + if ((dev->dev->platform_data == NULL) && + (pdev->dev.of_node)) { + struct device_node *pinmux_np; + struct davinci_i2c_platform_data *pdata; + u32 prop; + + dev->dev->platform_data = &davinci_i2c_platform_data_default; + pdata = &davinci_i2c_platform_data_default; + if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency", + &prop)) + pdata->bus_freq = prop / 1000; + if (!of_property_read_u32(pdev->dev.of_node, "bus-delay", + &prop)) + pdata->bus_delay = prop; + if (!of_property_read_u32(pdev->dev.of_node, "id", + &prop)) { + pdev->id = prop; + pdev->dev.init_name = kzalloc(20, GFP_KERNEL); + sprintf((char *)pdev->dev.init_name, + "i2c_davinci.%d", pdev->id); + } + pinmux_np = of_parse_phandle(pdev->dev.of_node, + "pinmux-handle", 0); + if (pinmux_np) + davinci_cfg_reg_of(pinmux_np); + } dev->clk = clk_get(&pdev->dev, NULL); + if (IS_ERR(dev->clk)) { r = -ENODEV; goto err_free_mem; @@ -711,6 +751,7 @@ static int davinci_i2c_probe(struct platform_device *pdev) adap->algo = &i2c_davinci_algo; adap->dev.parent = &pdev->dev; adap->timeout = DAVINCI_I2C_TIMEOUT; + adap->dev.of_node = pdev->dev.of_node; adap->nr = pdev->id; r = i2c_add_numbered_adapter(adap); @@ -718,6 +759,7 @@ static int davinci_i2c_probe(struct platform_device *pdev) dev_err(&pdev->dev, "failure adding adapter\n"); goto err_free_irq; } + of_i2c_register_devices(adap); return 0; @@ -809,6 +851,7 @@ static struct platform_driver davinci_i2c_driver = { .name = "i2c_davinci", .owner = THIS_MODULE, .pm = davinci_i2c_pm_ops, + .of_match_table = davinci_i2c_of_match, }, }; -- 1.7.7.5 From hs at denx.de Mon Jan 23 02:56:07 2012 From: hs at denx.de (Heiko Schocher) Date: Mon, 23 Jan 2012 09:56:07 +0100 Subject: [RFC PATCH 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board In-Reply-To: <1327308967-8092-1-git-send-email-hs@denx.de> References: <1327308967-8092-1-git-send-email-hs@denx.de> Message-ID: <1327308967-8092-8-git-send-email-hs@denx.de> - AM1808 based board - 64 MiB DDR ram - 2 MiB Nor flash - 128 MiB NAND flash - use internal RTC - I2C support - hwmon lm75 support - UBI/UBIFS support - MMC support - USB OTG support Signed-off-by: Heiko Schocher Cc: linux-arm-kernel at lists.infradead.org Cc: devicetree-discuss at lists.ozlabs.org Cc: davinci-linux-open-source at linux.davincidsp.com Cc: linux-mtd at lists.infradead.org Cc: linux-i2c at vger.kernel.org Cc: netdev at vger.kernel.org Cc: David Woodhouse Cc: Ben Dooks Cc: Wolfram Sang Cc: Sekhar Nori Cc: Kevin Hilman Cc: Wolfgang Denk --- - post this board support with USB support, even though USB is only working with the 10 ms "workaround", posted here: http://comments.gmane.org/gmane.linux.usb.general/54505 I see this issue also on the AM1808 TMDXEXP1808L evalboard. - MMC and USB are not using OF support yet, ideas how to port this are welcome. I need for USB and MMC boards board specific callbacks, how to solve this with OF support? arch/arm/boot/dts/enbw_cmc.dts | 286 +++++++++++++++++ arch/arm/configs/enbw_cmc_defconfig | 125 ++++++++ arch/arm/mach-davinci/Kconfig | 8 + arch/arm/mach-davinci/Makefile | 1 + arch/arm/mach-davinci/board-enbw-cmc.c | 384 +++++++++++++++++++++++ arch/arm/mach-davinci/include/mach/uncompress.h | 1 + 6 files changed, 805 insertions(+), 0 deletions(-) create mode 100644 arch/arm/boot/dts/enbw_cmc.dts create mode 100644 arch/arm/configs/enbw_cmc_defconfig create mode 100644 arch/arm/mach-davinci/board-enbw-cmc.c diff --git a/arch/arm/boot/dts/enbw_cmc.dts b/arch/arm/boot/dts/enbw_cmc.dts new file mode 100644 index 0000000..e5995ce --- /dev/null +++ b/arch/arm/boot/dts/enbw_cmc.dts @@ -0,0 +1,286 @@ +/* + * Device Tree for the EnBW CMC plattform + * + * Copyright 2011 DENX Software Engineering GmbH + * Heiko Schocher + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ +/dts-v1/; +/include/ "skeleton.dtsi" + +/ { + model = "EnBW CMC"; + compatible = "enbw,cmc"; + + aliases { + ethernet0 = ð0; + }; + + arm { + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0xfffee000 0x00020000>; + intc: interrupt-controller at 1 { + compatible = "ti,davinci-intc"; + interrupt-controller; + #interrupt-cells = <1>; + ti,intc-size = <101>; + reg = <0x0 0x2000>; + }; + }; + soc at 1c00000 { + compatible = "ti,da8xx"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x01c00000 0x400000>; + + serial0: serial at 1c42000 { + cell-index = <2>; + compatible = "ns16550a"; + reg = <0x42000 0x100>; + clock-frequency = <150000000>; + reg-shift = <2>; + interrupts = <25>; + interrupt-parent = <&intc>; + }; + serial1: serial at 1d0c000 { + cell-index = <1>; + compatible = "ns16550a"; + reg = <0x10c000 0x100>; + clock-frequency = <150000000>; + reg-shift = <2>; + interrupts = <53>; + interrupt-parent = <&intc>; + }; + serial2: serial at 1d0d000 { + cell-index = <2>; + compatible = "ns16550a"; + reg = <0x10d000 0x100>; + clock-frequency = <150000000>; + reg-shift = <2>; + interrupts = <61>; + interrupt-parent = <&intc>; + }; + + nor_pins: nor_pinmux at 1c14120 { + compatible = "ti,davinci-pinmux"; + reg = <0x14120 0x1000>; + pins = < /* muxreg maskoff modemsk muxmode */ + 5 24 15 1 /* EMA_BA_1 */ + 6 0 15 1 /* EMA CLK */ + 6 24 15 1 /* EMA_WAIT_1 */ + 7 0 15 1 /* NEMA_CS_2 */ + 7 16 15 1 /* NEMA_WE */ + 7 20 15 1 /* NEMA_OE */ + 9 28 15 1 /* EMA_D_0 */ + 9 24 15 1 /* EMA_D_1 */ + 9 20 15 1 /* EMA_D_2 */ + 9 16 15 1 /* EMA_D_3 */ + 9 12 15 1 /* EMA_D_4 */ + 9 8 15 1 /* EMA_D_5 */ + 9 4 15 1 /* EMA_D_6 */ + 9 0 15 1 /* EMA_D_7 */ + 8 28 15 1 /* EMA_D_8 */ + 8 24 15 1 /* EMA_D_9 */ + 8 20 15 1 /* EMA_D_10 */ + 8 16 15 1 /* EMA_D_11 */ + 8 12 15 1 /* EMA_D_12 */ + 8 8 15 1 /* EMA_D_13 */ + 8 4 15 1 /* EMA_D_14 */ + 8 0 15 1 /* EMA_D_15 */ + 12 28 15 1 /* EMA_A_0 */ + 12 24 15 1 /* EMA_A_1 */ + 12 20 15 1 /* EMA_A_2 */ + 12 16 15 1 /* EMA_A_3 */ + 12 12 15 1 /* EMA_A_4 */ + 12 8 15 1 /* EMA_A_5 */ + 12 4 15 1 /* EMA_A_6 */ + 12 0 15 1 /* EMA_A_7 */ + 11 28 15 1 /* EMA_A_8 */ + 11 24 15 1 /* EMA_A_9 */ + 11 20 15 1 /* EMA_A_10 */ + 11 16 15 1 /* EMA_A_11 */ + 11 12 15 1 /* EMA_A_12 */ + 11 8 15 1 /* EMA_A_13 */ + 11 4 15 1 /* EMA_A_14 */ + 11 0 15 1 /* EMA_A_15 */ + 10 28 15 1 /* EMA_A_16 */ + 10 24 15 1 /* EMA_A_17 */ + 10 20 15 1 /* EMA_A_18 */ + 10 16 15 1 /* EMA_A_19 */ + 10 12 15 1 /* EMA_A_20 */ + 10 8 15 1 /* EMA_A_21 */ + 10 4 15 1 /* EMA_A_22 */ + 10 0 15 1 /* EMA_A_23 */ + >; + }; + nand_pins: nand_pinmux at 1c14120 { + compatible = "ti,davinci-pinmux"; + reg = <0x14120 0x1000>; + pins = < /* muxreg maskoff modemsk muxmode */ + 7 4 15 1 /* NEMA_CS_3 */ + >; + }; + + emac_pins: pinmux at 1c14120 { + compatible = "ti,davinci-pinmux"; + reg = <0x14120 0x1000>; + pins = < /* muxreg maskoff modemsk muxmode */ + 2 4 15 8 /* MII TXEN */ + 2 8 15 8 /* MII TXCLK */ + 2 12 15 8 /* MII COL */ + 2 16 15 8 /* MII TXD_3 */ + 2 20 15 8 /* MII TXD_2 */ + 2 24 15 8 /* MII TXD_1 */ + 2 28 15 8 /* MII TXD_0 */ + 3 8 15 8 /* MII RXER */ + 3 12 15 8 /* MII CRS */ + 3 0 15 8 /* MII RXCLK */ + 3 4 15 8 /* MII RXDV */ + 3 16 15 8 /* MII RXD_3 */ + 3 20 15 8 /* MII RXD_2 */ + 3 24 15 8 /* MII RXD_1 */ + 3 28 15 8 /* MII RXD_0 */ + 4 0 15 8 /* MDIO CLK */ + 4 4 15 8 /* MDIO D */ + >; + }; + + i2c1_pins: i2c_pinmux at 1c14120 { + compatible = "ti,davinci-pinmux"; + reg = <0x14120 0x1000>; + pins = < /* muxreg maskoff modemsk muxmode */ + 4 12 15 2 /* I2C0 SDA */ + 4 8 15 2 /* I2C0 SCL */ + >; + }; + + eth0: emac at 1e20000 { + compatible = "ti,davinci-emac"; + reg = <0x220000 0x4000>; + ctrl_reg_offset = <0x3000>; + ctrl_mod_reg_offset = <0x2000>; + ctrl_ram_offset = <0>; + hw_ram_addr = <0>; + ctrl_ram_size = <0x2000>; + version = <1>; + local-mac-address = [ 00 00 00 00 00 00 ]; + interrupts = <33 + 34 + 35 + 36 + >; + interrupt-parent = <&intc>; + pinmux-handle = <&emac_pins>; + }; + + i2c at 1c22000 { + compatible = "ti,davinci-i2c"; + reg = <0x22000 0x1000>; + clock-frequency = <100000>; + interrupts = <15>; + interrupt-parent = <&intc>; + id = <1>; + pinmux-handle = <&i2c1_pins>; + #address-cells = <1>; + #size-cells = <0>; + + dtt at 48 { + compatible = "national,lm75"; + reg = <0x48>; + }; + }; + + wdt at 1c21000 { + compatible = "ti,davinci-wdt"; + reg = <0x00021000 0x1000>; + period = <100>; + }; + bootcount at 1c23000 { + compatible = "uboot,bootcount"; + reg = <0x23060 0x20>; + }; + + }; + onchipram at 8000000 { + compatible = "ti,davinci-onchipram"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x80000000 0x20000>; + }; + aemif at 60000000 { + compatible = "ti,davinci-aemif"; + #address-cells = <2>; + #size-cells = <1>; + reg = <0x68000000 0x80000>; + ranges = <2 0 0x60000000 0x02000000 + 3 0 0x62000000 0x02000000 + 4 0 0x64000000 0x02000000 + 5 0 0x66000000 0x02000000 + 6 0 0x68000000 0x02000000>; + cs2 at 68000000 { + compatible = "ti,davinci-cs"; + #address-cells = <1>; + #size-cells = <1>; + /* all timings in nanoseconds */ + cs = <2>; + asize = <1>; + ta = <0>; + rhold = <7>; + rstrobe = <42>; + rsetup = <14>; + whold = <7>; + wstrobe = <42>; + wsetup = <14>; + ew = <0>; + ss = <0>; + }; + flash at 2,0 { + compatible = "cfi-flash"; + reg = <2 0x0 0x400000>; + #address-cells = <1>; + #size-cells = <1>; + bank-width = <2>; + device-width = <2>; + }; + nand_cs: cs3 at 68000000 { + compatible = "ti,davinci-cs"; + #address-cells = <1>; + #size-cells = <1>; + /* all timings in nanoseconds */ + cs = <3>; + asize = <0>; + ta = <0>; + rhold = <7>; + rstrobe = <42>; + rsetup = <7>; + whold = <7>; + wstrobe = <14>; + wsetup = <7>; + ew = <0>; + ss = <0>; + }; + nandflash at 3,0 { + compatible = "ti,davinci-nand"; + reg = <3 0x0 0x807ff + 6 0x0 0x8000>; + #address-cells = <1>; + #size-cells = <1>; + id = <1>; + mask_ale = <0>; + mask_cle = <0>; + mask_chipsel = <0>; + ecc_mode = <2>; + ecc_bits = <4>; + options = <0>; + bbt_options = <0x20000>; + pinmux-handle = <&nand_pins>; + timing-handle = <&nand_cs>; + }; + + }; +}; diff --git a/arch/arm/configs/enbw_cmc_defconfig b/arch/arm/configs/enbw_cmc_defconfig new file mode 100644 index 0000000..c794127 --- /dev/null +++ b/arch/arm/configs/enbw_cmc_defconfig @@ -0,0 +1,125 @@ +CONFIG_EXPERIMENTAL=y +# CONFIG_SWAP is not set +CONFIG_SYSVIPC=y +CONFIG_POSIX_MQUEUE=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_BLK_DEV_INITRD=y +CONFIG_EXPERT=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +CONFIG_MODULE_FORCE_UNLOAD=y +CONFIG_MODVERSIONS=y +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_IOSCHED_DEADLINE is not set +# CONFIG_IOSCHED_CFQ is not set +CONFIG_ARCH_DAVINCI=y +CONFIG_ARCH_DAVINCI_DA850=y +# CONFIG_MACH_DAVINCI_DA850_EVM is not set +CONFIG_GPIO_PCA953X=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_PREEMPT=y +CONFIG_AEABI=y +# CONFIG_OABI_COMPAT is not set +CONFIG_USE_OF=y +CONFIG_NET=y +CONFIG_PACKET=y +CONFIG_UNIX=y +CONFIG_INET=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +# CONFIG_INET_LRO is not set +CONFIG_IPV6=y +CONFIG_NETFILTER=y +# CONFIG_WIRELESS is not set +CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +# CONFIG_FW_LOADER is not set +CONFIG_MTD=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLKDEVS=y +CONFIG_MTD_CFI=y +CONFIG_MTD_CFI_INTELEXT=y +CONFIG_MTD_CFI_AMDSTD=y +CONFIG_MTD_PHYSMAP=y +CONFIG_MTD_PHYSMAP_OF=y +CONFIG_MTD_NAND=y +CONFIG_MTD_NAND_DAVINCI=y +CONFIG_MTD_UBI=y +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_COUNT=1 +CONFIG_BLK_DEV_RAM_SIZE=32768 +CONFIG_MISC_DEVICES=y +CONFIG_UBOOT_BOOTCOUNT=y +CONFIG_EEPROM_AT24=y +CONFIG_SCSI=y +CONFIG_BLK_DEV_SD=y +CONFIG_NETDEVICES=y +CONFIG_MII=y +CONFIG_TI_DAVINCI_EMAC=y +# CONFIG_WLAN is not set +CONFIG_INPUT_POLLDEV=y +# CONFIG_INPUT_MOUSEDEV is not set +CONFIG_INPUT_EVDEV=y +CONFIG_INPUT_EVBUG=y +# CONFIG_INPUT_KEYBOARD is not set +# CONFIG_INPUT_MOUSE is not set +# CONFIG_SERIO is not set +# CONFIG_VT is not set +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_NR_UARTS=3 +CONFIG_SERIAL_8250_RUNTIME_UARTS=3 +CONFIG_SERIAL_OF_PLATFORM=y +CONFIG_HW_RANDOM=y +CONFIG_I2C=y +CONFIG_I2C_CHARDEV=y +CONFIG_I2C_DAVINCI=y +CONFIG_GPIO_SYSFS=y +CONFIG_GPIO_PCF857X=y +CONFIG_SENSORS_LM75=y +CONFIG_WATCHDOG=y +CONFIG_WD=y +CONFIG_WD_DAVINCI=y +# CONFIG_HID_SUPPORT is not set +CONFIG_USB=y +CONFIG_USB_ANNOUNCE_NEW_DEVICES=y +CONFIG_USB_MUSB_HDRC=y +CONFIG_USB_MUSB_DA8XX=y +CONFIG_USB_STORAGE=y +CONFIG_USB_UAS=y +CONFIG_USB_LIBUSUAL=y +CONFIG_USB_GADGET=y +CONFIG_USB_FUSB300=y +CONFIG_USB_ETH=y +CONFIG_MMC=y +CONFIG_MMC_DAVINCI=y +CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_OMAP=y +CONFIG_EXT2_FS=y +CONFIG_EXT3_FS=y +CONFIG_AUTOFS4_FS=y +CONFIG_MSDOS_FS=y +CONFIG_VFAT_FS=y +CONFIG_TMPFS=y +CONFIG_UBIFS_FS=y +CONFIG_CRAMFS=y +CONFIG_NFS_FS=y +CONFIG_NFS_V3=y +CONFIG_ROOT_NFS=y +CONFIG_PARTITION_ADVANCED=y +CONFIG_NLS_CODEPAGE_437=y +CONFIG_NLS_ASCII=y +CONFIG_NLS_ISO8859_1=y +CONFIG_NLS_UTF8=y +CONFIG_DEBUG_FS=y +CONFIG_TIMER_STATS=y +CONFIG_DEBUG_RT_MUTEXES=y +CONFIG_DEBUG_MUTEXES=y +# CONFIG_CRYPTO_ANSI_CPRNG is not set +# CONFIG_CRYPTO_HW is not set +CONFIG_CRC_CCITT=m +CONFIG_CRC_T10DIF=m diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig index 32d837d..66efe86 100644 --- a/arch/arm/mach-davinci/Kconfig +++ b/arch/arm/mach-davinci/Kconfig @@ -202,6 +202,14 @@ config DA850_WL12XX Say Y if you want to use a wl1271 expansion card connected to the AM18x EVM. +config MACH_ENBW_CMC + bool "EnBW Communication Module Compact" + default ARCH_DAVINCI_DA850 + depends on ARCH_DAVINCI_DA850 + help + Say Y here to select the EnBW Communication Module Compact + board. + config GPIO_PCA953X default MACH_DAVINCI_DA850_EVM diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile index 2db78bd..12f3166 100644 --- a/arch/arm/mach-davinci/Makefile +++ b/arch/arm/mach-davinci/Makefile @@ -34,6 +34,7 @@ obj-$(CONFIG_MACH_DAVINCI_DA850_EVM) += board-da850-evm.o obj-$(CONFIG_MACH_TNETV107X) += board-tnetv107x-evm.o obj-$(CONFIG_MACH_MITYOMAPL138) += board-mityomapl138.o obj-$(CONFIG_MACH_OMAPL138_HAWKBOARD) += board-omapl138-hawk.o +obj-$(CONFIG_MACH_ENBW_CMC) += board-enbw-cmc.o # Power Management obj-$(CONFIG_CPU_FREQ) += cpufreq.o diff --git a/arch/arm/mach-davinci/board-enbw-cmc.c b/arch/arm/mach-davinci/board-enbw-cmc.c new file mode 100644 index 0000000..4473c4a --- /dev/null +++ b/arch/arm/mach-davinci/board-enbw-cmc.c @@ -0,0 +1,384 @@ +/* + * EnBW Communication Module Compact board + * Copyright 2011 DENX Software Engineering GmbH + * Author: Heiko Schocher + * + * based on: + * TI DA850/OMAP-L138 EVM board + * + * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/ + * + * Derived from: arch/arm/mach-davinci/board-da850-evm.c + * Original Copyrights follow: + * + * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under + * the terms of the GNU General Public License version 2. This program + * is licensed "as is" without any warranty of any kind, whether express + * or implied. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define ENBW_CMC_MMCSD_CD_PIN GPIO_TO_PIN(3, 13) + +/* + * USB1 VBUS is controlled by GPIO7[12], over-current is reported on GPIO7[8]. + */ +#define DA850_USB_VBUS_PIN GPIO_TO_PIN(7, 12) +#define ON_BD_USB_OVC GPIO_TO_PIN(7, 8) + +#if defined(CONFIG_USB_OHCI_HCD) +static irqreturn_t enbw_cmc_usb_ocic_irq(int irq, void *dev_id); +static da8xx_ocic_handler_t enbw_cmc_usb_ocic_handler; + +static int enbw_cmc_usb_set_power(unsigned port, int on) +{ + gpio_set_value(DA850_USB_VBUS_PIN, on); + return 0; +} + +static int enbw_cmc_usb_get_power(unsigned port) +{ + return gpio_get_value(DA850_USB_VBUS_PIN); +} + +static int enbw_cmc_usb_get_oci(unsigned port) +{ + return !gpio_get_value(ON_BD_USB_OVC); +} + +static irqreturn_t enbw_cmc_usb_ocic_irq(int, void *); + +static int enbw_cmc_usb_ocic_notify(da8xx_ocic_handler_t handler) +{ + int irq = gpio_to_irq(ON_BD_USB_OVC); + int error = 0; + + if (handler != NULL) { + enbw_cmc_usb_ocic_handler = handler; + + error = request_irq(irq, enbw_cmc_usb_ocic_irq, + IRQF_DISABLED | IRQF_TRIGGER_RISING | + IRQF_TRIGGER_FALLING, + "OHCI over-current indicator", NULL); + if (error) + pr_err("%s: could not request IRQ to watch " + "over-current indicator changes\n", __func__); + } else { + free_irq(irq, NULL); + } + return error; +} + +static struct da8xx_ohci_root_hub enbw_cmc_usb11_pdata = { + .set_power = enbw_cmc_usb_set_power, + .get_power = enbw_cmc_usb_get_power, + .get_oci = enbw_cmc_usb_get_oci, + .ocic_notify = enbw_cmc_usb_ocic_notify, + .potpgt = (10 + 1) / 2, /* 10 ms max */ +}; + +static irqreturn_t enbw_cmc_usb_ocic_irq(int irq, void *dev_id) +{ + enbw_cmc_usb_ocic_handler(&enbw_cmc_usb11_pdata, 1); + return IRQ_HANDLED; +} +#endif + +#if defined(CONFIG_OF) +static __init void enbw_cmc_usb_init(void) +{ + int ret; + u32 cfgchip2; + + /* Set up USB clock/mode in the CFGCHIP2 register. */ + cfgchip2 = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG)); + + /* USB2.0 PHY reference clock is AUXCLK with 24MHz */ + cfgchip2 &= ~CFGCHIP2_REFFREQ; + cfgchip2 |= CFGCHIP2_REFFREQ_24MHZ; + + /* + * Select internal reference clock for USB 2.0 PHY + * and use it as a clock source for USB 1.1 PHY + * (this is the default setting anyway). + */ + cfgchip2 &= ~CFGCHIP2_USB1PHYCLKMUX; + cfgchip2 |= CFGCHIP2_USB2PHYCLKMUX; + + cfgchip2 &= ~CFGCHIP2_OTGMODE; + cfgchip2 |= CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN; + + __raw_writel(cfgchip2, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG)); + + ret = davinci_cfg_reg(DA830_USB0_DRVVBUS); + if (ret) + pr_warning("%s: USB 2.0 PinMux setup failed: %d\n", + __func__, ret); + else { + /* + * SP2525A @ 5V supplies 500mA, + * with the power on to power good time of 10 ms. + */ + ret = da8xx_register_usb20(500, 10); + if (ret) + pr_warning("%s: USB 2.0 registration failed: %d\n", + __func__, ret); + } + + ret = gpio_request_one(DA850_USB_VBUS_PIN, + GPIOF_DIR_OUT, "USB 1.1 VBUS"); + if (ret < 0) { + pr_err("%s: failed to request GPIO for USB 1.1 port " + "power control: %d\n", __func__, ret); + return; + } + gpio_direction_input(DA850_USB_VBUS_PIN); + + ret = gpio_request(ON_BD_USB_OVC, "ON_BD_USB_OVC"); + if (ret) { + printk(KERN_ERR "%s: failed to request GPIO for USB 1.1 port " + "over-current indicator: %d\n", __func__, ret); + gpio_free(DA850_USB_VBUS_PIN); + return; + } + gpio_direction_input(ON_BD_USB_OVC); + +#if defined(CONFIG_USB_OHCI_HCD) + ret = da8xx_register_usb11(&enbw_cmc_usb11_pdata); + if (ret) { + pr_warning("%s: USB 1.1 registration failed: %d\n", + __func__, ret); + gpio_free(ON_BD_USB_OVC); + gpio_free(DA850_USB_VBUS_PIN); + } +#endif + + return; +} + +static int enbw_cmc_mmc_get_ro(int index) +{ + return 0; +} + +static int enbw_cmc_mmc_get_cd(int index) +{ + return gpio_get_value(ENBW_CMC_MMCSD_CD_PIN) ? 1 : 0; +} + +static struct davinci_mmc_config enbw_cmc_mmc_config = { + .get_ro = enbw_cmc_mmc_get_ro, + .get_cd = enbw_cmc_mmc_get_cd, + .wires = 4, + .max_freq = 50000000, + .caps = MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED, + .version = MMC_CTLR_VERSION_2, +}; + +static int __init enbw_cmc_config_emac(void) +{ + void __iomem *cfg_chip3_base; + int ret; + u32 val; + struct davinci_soc_info *soc_info = &davinci_soc_info; + + if (!machine_is_enbw_cmc()) + return 0; + + cfg_chip3_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG); + val = __raw_readl(cfg_chip3_base); + val &= ~BIT(8); + pr_info("EMAC: MII PHY configured, RMII PHY will not be" + " functional\n"); + + /* configure the CFGCHIP3 register for MII */ + __raw_writel(val, cfg_chip3_base); + + /* use complete info from OF */ + soc_info->emac_pdata = NULL; + ret = da8xx_register_emac(); + if (ret) + pr_warning("enbw_cmc_init: emac registration failed: %d\n", + ret); + + return 0; +} +device_initcall(enbw_cmc_config_emac); + +static const s16 da850_dma0_rsv_chans[][2] = { + /* (offset, number) */ + {-1, -1} +}; + +static const s16 da850_dma0_rsv_slots[][2] = { + /* (offset, number) */ + {-1, -1} +}; + +static const s16 da850_dma1_rsv_chans[][2] = { + /* (offset, number) */ + {-1, -1} +}; + +static const s16 da850_dma1_rsv_slots[][2] = { + /* (offset, number) */ + {-1, -1} +}; + +static struct edma_rsv_info da850_edma_cc0_rsv = { + .rsv_chans = da850_dma0_rsv_chans, + .rsv_slots = da850_dma0_rsv_slots, +}; + +static struct edma_rsv_info da850_edma_cc1_rsv = { + .rsv_chans = da850_dma1_rsv_chans, + .rsv_slots = da850_dma1_rsv_slots, +}; + +static struct edma_rsv_info *da850_edma_rsv[2] = { + &da850_edma_cc0_rsv, + &da850_edma_cc1_rsv, +}; + +#ifdef CONFIG_CPU_FREQ +static __init int da850_evm_init_cpufreq(void) +{ + switch (system_rev & 0xF) { + case 3: + da850_max_speed = 456000; + break; + case 2: + da850_max_speed = 408000; + break; + case 1: + da850_max_speed = 372000; + break; + } + + return da850_register_cpufreq("pll0_sysclk3"); +} +#else +static __init int da850_evm_init_cpufreq(void) { return 0; } +#endif + +struct of_dev_auxdata enbw_cmc_auxdata_lookup[] __initdata = { + OF_DEV_AUXDATA("ti,davinci-wdt", 0x01c21000, "ti,davinci-wdt", NULL), + {} +}; + +const struct of_device_id enbw_cmc_bus_match_table[] = { + { .compatible = "simple-bus", }, + { .compatible = "ti,da8xx", }, + { .compatible = "ti,davinci-onchipram", }, + { .compatible = "ti,davinci-aemif", }, + {} /* Empty terminated list */ +}; + +static __init void enbw_cmc_init(void) +{ + int ret; + + of_platform_populate(NULL, enbw_cmc_bus_match_table, + enbw_cmc_auxdata_lookup, NULL); + + ret = da850_register_edma(da850_edma_rsv); + if (ret) + pr_warning("enbw_cmc_init: edma registration failed: %d\n", + ret); + + /* + * shut down uart 0 this port is not used on the board + */ + __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30); + + ret = da8xx_register_rtc(); + if (ret) + pr_warning("enbw_cmc_init: rtc setup failed: %d\n", ret); + + ret = da850_evm_init_cpufreq(); + if (ret) + pr_warning("enbw_cmc_init: cpufreq registration failed: %d\n", + ret); + + ret = da8xx_register_cpuidle(); + if (ret) + pr_warning("enbw_cmc_init: cpuidle registration failed: %d\n", + ret); + + ret = gpio_request(ENBW_CMC_MMCSD_CD_PIN, "MMC CD\n"); + if (ret) + pr_warning("enbw_cmc_init: can not open GPIO %d\n", + ENBW_CMC_MMCSD_CD_PIN); + gpio_direction_input(ENBW_CMC_MMCSD_CD_PIN); + + ret = da850_register_mmcsd1(&enbw_cmc_mmc_config); + if (ret) + pr_warning("enbw_cmc_init: mmcsd1 registration failed:" + " %d\n", ret); + + enbw_cmc_usb_init(); +} +#else +static __init void enbw_cmc_init(void) +{ + pr_err("enbw_cmc: please use OF.\n"); + return; +} +#endif + +#ifdef CONFIG_SERIAL_8250_CONSOLE +static int __init enbw_cmc_console_init(void) +{ + if (!machine_is_enbw_cmc()) + return 0; + + return add_preferred_console("ttyS", 2, "115200"); +} +console_initcall(enbw_cmc_console_init); +#endif + +static void __init enbw_cmc_map_io(void) +{ + da850_init(); +} + +static const char *enbw_cmc_board_compat[] __initconst = { + "enbw,cmc", + NULL +}; + +MACHINE_START(ENBW_CMC, "EnBW CMC") + .map_io = enbw_cmc_map_io, + .init_irq = davinci_init_irq, + .timer = &davinci_timer, + .init_machine = enbw_cmc_init, + .dt_compat = enbw_cmc_board_compat, + .dma_zone_size = SZ_128M, + .restart = da8xx_restart, +MACHINE_END diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h index 9dc7cf9..2f21384 100644 --- a/arch/arm/mach-davinci/include/mach/uncompress.h +++ b/arch/arm/mach-davinci/include/mach/uncompress.h @@ -96,6 +96,7 @@ static inline void __arch_decomp_setup(unsigned long arch_id) DEBUG_LL_DA8XX(davinci_da850_evm, 2); DEBUG_LL_DA8XX(mityomapl138, 1); DEBUG_LL_DA8XX(omapl138_hawkboard, 2); + DEBUG_LL_DA8XX(enbw_cmc, 2); /* TNETV107x boards */ DEBUG_LL_TNETV107X(tnetv107x, 1); -- 1.7.7.5 From linux at arm.linux.org.uk Mon Jan 23 05:49:02 2012 From: linux at arm.linux.org.uk (Russell King - ARM Linux) Date: Mon, 23 Jan 2012 11:49:02 +0000 Subject: ARM/ARM-SoC plans for v3.4 merge window Message-ID: <20120123114902.GY1068@n2100.arm.linux.org.uk> This is an outline of the plan for this cycle, up to the next merge window, agreed between Olof and myself. As Nicolas' idle changes weren't merged before the last merge window opened, we have decided that Nicolas will resubmit his changes after -rc1 (in other words, now) and they will be merged into both the arm-soc and my trees. I have at least one other patch which has a high 'will cause horrible conficts' rating (the debug option rearrangement patch), so I'll be including that for the arm-soc tree as well. However, what this does mean is that Arnd, Olof, and myself will be in for up to three months of merge hell unless people take account of these changes. Therefore, our plan is to publish this as a baseline, and we'd really appreciate any development submitted after that baseline has been established is based upon those changes and does not conflict with them. That may mean you have to pull these changes into your tree and merge them into your development work (and fix up any conflicts there yourself.) Once you've taken these changes into your tree, you must not rebase or modify them. Changing those commits will cause all hell to break loose, and we'll have to refuse merging your tree (otherwise we'll be in Linus' sights for a roasting at gas mark 2 million.) From prakash.pm at ti.com Mon Jan 23 08:52:47 2012 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Mon, 23 Jan 2012 20:22:47 +0530 Subject: [PATCH 1/3] arm:davinci: prepare to move aemif driver to drivers/mfd Message-ID: <1327330367-4025-1-git-send-email-prakash.pm@ti.com> Patch moves emif header file appropriately as a part preparation to move emif driver from arch/arm/mach-davinci/ to drivers/mfd folder. There by it isolates modifications in emif interface depicting as platform code change. Patch series are based on the discussion and concerns expressed in davinci-linux-open-source community. Here is the link for the same: http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-arm-davinci-configure-davinci-aemif-chipselects-through-OF-tt7059739.html#none Signed-off-by: Manjunathappa, Prakash --- arch/arm/mach-davinci/aemif.c | 2 +- arch/arm/mach-davinci/board-da830-evm.c | 2 +- arch/arm/mach-davinci/board-da850-evm.c | 2 +- arch/arm/mach-davinci/include/mach/aemif.h | 36 ---------------------------- drivers/mtd/nand/davinci_nand.c | 2 +- include/linux/mfd/davinci_aemif.h | 36 ++++++++++++++++++++++++++++ 6 files changed, 40 insertions(+), 40 deletions(-) delete mode 100644 arch/arm/mach-davinci/include/mach/aemif.h create mode 100644 include/linux/mfd/davinci_aemif.h diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c index 1ce70a9..b67c115 100644 --- a/arch/arm/mach-davinci/aemif.c +++ b/arch/arm/mach-davinci/aemif.c @@ -15,7 +15,7 @@ #include #include -#include +#include /* Timing value configuration */ diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c index dc1afe5..0b43554 100644 --- a/arch/arm/mach-davinci/board-da830-evm.c +++ b/arch/arm/mach-davinci/board-da830-evm.c @@ -31,7 +31,7 @@ #include #include #include -#include +#include #include #define DA830_EVM_PHY_ID "" diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c index 6b22b54..6dda013 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c @@ -41,7 +41,7 @@ #include #include #include -#include +#include #include #define DA850_EVM_PHY_ID "0:00" diff --git a/arch/arm/mach-davinci/include/mach/aemif.h b/arch/arm/mach-davinci/include/mach/aemif.h deleted file mode 100644 index 05b2934..0000000 --- a/arch/arm/mach-davinci/include/mach/aemif.h +++ /dev/null @@ -1,36 +0,0 @@ -/* - * TI DaVinci AEMIF support - * - * Copyright 2010 (C) Texas Instruments, Inc. http://www.ti.com/ - * - * This file is licensed under the terms of the GNU General Public License - * version 2. This program is licensed "as is" without any warranty of any - * kind, whether express or implied. - */ -#ifndef _MACH_DAVINCI_AEMIF_H -#define _MACH_DAVINCI_AEMIF_H - -#define NRCSR_OFFSET 0x00 -#define AWCCR_OFFSET 0x04 -#define A1CR_OFFSET 0x10 - -#define ACR_ASIZE_MASK 0x3 -#define ACR_EW_MASK BIT(30) -#define ACR_SS_MASK BIT(31) - -/* All timings in nanoseconds */ -struct davinci_aemif_timing { - u8 wsetup; - u8 wstrobe; - u8 whold; - - u8 rsetup; - u8 rstrobe; - u8 rhold; - - u8 ta; -}; - -int davinci_aemif_setup_timing(struct davinci_aemif_timing *t, - void __iomem *base, unsigned cs); -#endif diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c index 6e56615..f19151b 100644 --- a/drivers/mtd/nand/davinci_nand.c +++ b/drivers/mtd/nand/davinci_nand.c @@ -35,7 +35,7 @@ #include #include -#include +#include /* * This is a device driver for the NAND flash controller found on the diff --git a/include/linux/mfd/davinci_aemif.h b/include/linux/mfd/davinci_aemif.h new file mode 100644 index 0000000..05b2934 --- /dev/null +++ b/include/linux/mfd/davinci_aemif.h @@ -0,0 +1,36 @@ +/* + * TI DaVinci AEMIF support + * + * Copyright 2010 (C) Texas Instruments, Inc. http://www.ti.com/ + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed "as is" without any warranty of any + * kind, whether express or implied. + */ +#ifndef _MACH_DAVINCI_AEMIF_H +#define _MACH_DAVINCI_AEMIF_H + +#define NRCSR_OFFSET 0x00 +#define AWCCR_OFFSET 0x04 +#define A1CR_OFFSET 0x10 + +#define ACR_ASIZE_MASK 0x3 +#define ACR_EW_MASK BIT(30) +#define ACR_SS_MASK BIT(31) + +/* All timings in nanoseconds */ +struct davinci_aemif_timing { + u8 wsetup; + u8 wstrobe; + u8 whold; + + u8 rsetup; + u8 rstrobe; + u8 rhold; + + u8 ta; +}; + +int davinci_aemif_setup_timing(struct davinci_aemif_timing *t, + void __iomem *base, unsigned cs); +#endif -- 1.7.1 From prakash.pm at ti.com Mon Jan 23 09:12:32 2012 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Mon, 23 Jan 2012 20:42:32 +0530 Subject: [RESEND PATCH] arm:davinci: prepare to move aemif driver to drivers/mfd Message-ID: <1327331552-9913-1-git-send-email-prakash.pm@ti.com> Patch moves emif header file appropriately as a part preparation to move emif driver from arch/arm/mach-davinci/ to drivers/mfd folder. There by it isolates modifications in emif interface depicting as platform code change. Patch series are based on the discussion and concerns expressed in davinci-linux-open-source community. Here is the link for the same: http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-arm-davinci-configure-davinci-aemif-chipselects-through-OF-tt7059739.html#none Signed-off-by: Manjunathappa, Prakash --- Adding: MFD maintainer and mailing list. arch/arm/mach-davinci/aemif.c | 2 +- arch/arm/mach-davinci/board-da830-evm.c | 2 +- arch/arm/mach-davinci/board-da850-evm.c | 2 +- arch/arm/mach-davinci/include/mach/aemif.h | 36 ---------------------------- drivers/mtd/nand/davinci_nand.c | 2 +- include/linux/mfd/davinci_aemif.h | 36 ++++++++++++++++++++++++++++ 6 files changed, 40 insertions(+), 40 deletions(-) delete mode 100644 arch/arm/mach-davinci/include/mach/aemif.h create mode 100644 include/linux/mfd/davinci_aemif.h diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c index 1ce70a9..b67c115 100644 --- a/arch/arm/mach-davinci/aemif.c +++ b/arch/arm/mach-davinci/aemif.c @@ -15,7 +15,7 @@ #include #include -#include +#include /* Timing value configuration */ diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c index dc1afe5..0b43554 100644 --- a/arch/arm/mach-davinci/board-da830-evm.c +++ b/arch/arm/mach-davinci/board-da830-evm.c @@ -31,7 +31,7 @@ #include #include #include -#include +#include #include #define DA830_EVM_PHY_ID "" diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c index 6b22b54..6dda013 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c @@ -41,7 +41,7 @@ #include #include #include -#include +#include #include #define DA850_EVM_PHY_ID "0:00" diff --git a/arch/arm/mach-davinci/include/mach/aemif.h b/arch/arm/mach-davinci/include/mach/aemif.h deleted file mode 100644 index 05b2934..0000000 --- a/arch/arm/mach-davinci/include/mach/aemif.h +++ /dev/null @@ -1,36 +0,0 @@ -/* - * TI DaVinci AEMIF support - * - * Copyright 2010 (C) Texas Instruments, Inc. http://www.ti.com/ - * - * This file is licensed under the terms of the GNU General Public License - * version 2. This program is licensed "as is" without any warranty of any - * kind, whether express or implied. - */ -#ifndef _MACH_DAVINCI_AEMIF_H -#define _MACH_DAVINCI_AEMIF_H - -#define NRCSR_OFFSET 0x00 -#define AWCCR_OFFSET 0x04 -#define A1CR_OFFSET 0x10 - -#define ACR_ASIZE_MASK 0x3 -#define ACR_EW_MASK BIT(30) -#define ACR_SS_MASK BIT(31) - -/* All timings in nanoseconds */ -struct davinci_aemif_timing { - u8 wsetup; - u8 wstrobe; - u8 whold; - - u8 rsetup; - u8 rstrobe; - u8 rhold; - - u8 ta; -}; - -int davinci_aemif_setup_timing(struct davinci_aemif_timing *t, - void __iomem *base, unsigned cs); -#endif diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c index 6e56615..f19151b 100644 --- a/drivers/mtd/nand/davinci_nand.c +++ b/drivers/mtd/nand/davinci_nand.c @@ -35,7 +35,7 @@ #include #include -#include +#include /* * This is a device driver for the NAND flash controller found on the diff --git a/include/linux/mfd/davinci_aemif.h b/include/linux/mfd/davinci_aemif.h new file mode 100644 index 0000000..05b2934 --- /dev/null +++ b/include/linux/mfd/davinci_aemif.h @@ -0,0 +1,36 @@ +/* + * TI DaVinci AEMIF support + * + * Copyright 2010 (C) Texas Instruments, Inc. http://www.ti.com/ + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed "as is" without any warranty of any + * kind, whether express or implied. + */ +#ifndef _MACH_DAVINCI_AEMIF_H +#define _MACH_DAVINCI_AEMIF_H + +#define NRCSR_OFFSET 0x00 +#define AWCCR_OFFSET 0x04 +#define A1CR_OFFSET 0x10 + +#define ACR_ASIZE_MASK 0x3 +#define ACR_EW_MASK BIT(30) +#define ACR_SS_MASK BIT(31) + +/* All timings in nanoseconds */ +struct davinci_aemif_timing { + u8 wsetup; + u8 wstrobe; + u8 whold; + + u8 rsetup; + u8 rstrobe; + u8 rhold; + + u8 ta; +}; + +int davinci_aemif_setup_timing(struct davinci_aemif_timing *t, + void __iomem *base, unsigned cs); +#endif -- 1.7.1 From prakash.pm at ti.com Mon Jan 23 09:14:53 2012 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Mon, 23 Jan 2012 20:44:53 +0530 Subject: [PATCH 2/3] arm:davinci: Move emif driver to drivers/mfd from mach-davinci folder Message-ID: <1327331693-10374-1-git-send-email-prakash.pm@ti.com> Move aemif kernel module from arch/arm/amch-davinci/ to multi functional devices frame work. Signed-off-by: Manjunathappa, Prakash --- arch/arm/Kconfig | 1 + arch/arm/mach-davinci/Makefile | 4 +- arch/arm/mach-davinci/aemif.c | 133 --------------------- drivers/mfd/Makefile | 1 + drivers/mfd/davinci_aemif.c | 238 +++++++++++++++++++++++++++++++++++++ include/linux/mfd/davinci_aemif.h | 14 ++ 6 files changed, 256 insertions(+), 135 deletions(-) delete mode 100644 arch/arm/mach-davinci/aemif.c create mode 100644 drivers/mfd/davinci_aemif.c diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 24626b0..5b717cf 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -936,6 +936,7 @@ config ARCH_DAVINCI select GENERIC_ALLOCATOR select GENERIC_IRQ_CHIP select ARCH_HAS_HOLES_MEMORYMODEL + select MFD_CORE help Support for TI's DaVinci platform. diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile index 2db78bd..e25a459 100644 --- a/arch/arm/mach-davinci/Makefile +++ b/arch/arm/mach-davinci/Makefile @@ -4,8 +4,8 @@ # # Common objects -obj-y := time.o clock.o serial.o psc.o \ - dma.o usb.o common.o sram.o aemif.o +obj-y := time.o clock.o serial.o io.o psc.o \ + dma.o usb.o common.o sram.o obj-$(CONFIG_DAVINCI_MUX) += mux.o diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c deleted file mode 100644 index b67c115..0000000 --- a/arch/arm/mach-davinci/aemif.c +++ /dev/null @@ -1,133 +0,0 @@ -/* - * AEMIF support for DaVinci SoCs - * - * Copyright (C) 2010 Texas Instruments Incorporated. http://www.ti.com/ - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ - -#include -#include -#include -#include -#include -#include - -#include - -/* Timing value configuration */ - -#define TA(x) ((x) << 2) -#define RHOLD(x) ((x) << 4) -#define RSTROBE(x) ((x) << 7) -#define RSETUP(x) ((x) << 13) -#define WHOLD(x) ((x) << 17) -#define WSTROBE(x) ((x) << 20) -#define WSETUP(x) ((x) << 26) - -#define TA_MAX 0x3 -#define RHOLD_MAX 0x7 -#define RSTROBE_MAX 0x3f -#define RSETUP_MAX 0xf -#define WHOLD_MAX 0x7 -#define WSTROBE_MAX 0x3f -#define WSETUP_MAX 0xf - -#define TIMING_MASK (TA(TA_MAX) | \ - RHOLD(RHOLD_MAX) | \ - RSTROBE(RSTROBE_MAX) | \ - RSETUP(RSETUP_MAX) | \ - WHOLD(WHOLD_MAX) | \ - WSTROBE(WSTROBE_MAX) | \ - WSETUP(WSETUP_MAX)) - -/* - * aemif_calc_rate - calculate timing data. - * @wanted: The cycle time needed in nanoseconds. - * @clk: The input clock rate in kHz. - * @max: The maximum divider value that can be programmed. - * - * On success, returns the calculated timing value minus 1 for easy - * programming into AEMIF timing registers, else negative errno. - */ -static int aemif_calc_rate(int wanted, unsigned long clk, int max) -{ - int result; - - result = DIV_ROUND_UP((wanted * clk), NSEC_PER_MSEC) - 1; - - pr_debug("%s: result %d from %ld, %d\n", __func__, result, clk, wanted); - - /* It is generally OK to have a more relaxed timing than requested... */ - if (result < 0) - result = 0; - - /* ... But configuring tighter timings is not an option. */ - else if (result > max) - result = -EINVAL; - - return result; -} - -/** - * davinci_aemif_setup_timing - setup timing values for a given AEMIF interface - * @t: timing values to be progammed - * @base: The virtual base address of the AEMIF interface - * @cs: chip-select to program the timing values for - * - * This function programs the given timing values (in real clock) into the - * AEMIF registers taking the AEMIF clock into account. - * - * This function does not use any locking while programming the AEMIF - * because it is expected that there is only one user of a given - * chip-select. - * - * Returns 0 on success, else negative errno. - */ -int davinci_aemif_setup_timing(struct davinci_aemif_timing *t, - void __iomem *base, unsigned cs) -{ - unsigned set, val; - int ta, rhold, rstrobe, rsetup, whold, wstrobe, wsetup; - unsigned offset = A1CR_OFFSET + cs * 4; - struct clk *aemif_clk; - unsigned long clkrate; - - if (!t) - return 0; /* Nothing to do */ - - aemif_clk = clk_get(NULL, "aemif"); - if (IS_ERR(aemif_clk)) - return PTR_ERR(aemif_clk); - - clkrate = clk_get_rate(aemif_clk); - - clkrate /= 1000; /* turn clock into kHz for ease of use */ - - ta = aemif_calc_rate(t->ta, clkrate, TA_MAX); - rhold = aemif_calc_rate(t->rhold, clkrate, RHOLD_MAX); - rstrobe = aemif_calc_rate(t->rstrobe, clkrate, RSTROBE_MAX); - rsetup = aemif_calc_rate(t->rsetup, clkrate, RSETUP_MAX); - whold = aemif_calc_rate(t->whold, clkrate, WHOLD_MAX); - wstrobe = aemif_calc_rate(t->wstrobe, clkrate, WSTROBE_MAX); - wsetup = aemif_calc_rate(t->wsetup, clkrate, WSETUP_MAX); - - if (ta < 0 || rhold < 0 || rstrobe < 0 || rsetup < 0 || - whold < 0 || wstrobe < 0 || wsetup < 0) { - pr_err("%s: cannot get suitable timings\n", __func__); - return -EINVAL; - } - - set = TA(ta) | RHOLD(rhold) | RSTROBE(rstrobe) | RSETUP(rsetup) | - WHOLD(whold) | WSTROBE(wstrobe) | WSETUP(wsetup); - - val = __raw_readl(base + offset); - val &= ~TIMING_MASK; - val |= set; - __raw_writel(val, base + offset); - - return 0; -} -EXPORT_SYMBOL(davinci_aemif_setup_timing); diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index b953bab..54fc267 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -11,6 +11,7 @@ obj-$(CONFIG_HTC_EGPIO) += htc-egpio.o obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o +obj-${CONFIG_ARCH_DAVINCI} += davinci_aemif.o obj-$(CONFIG_MFD_DAVINCI_VOICECODEC) += davinci_voicecodec.o obj-$(CONFIG_MFD_DM355EVM_MSP) += dm355evm_msp.o obj-$(CONFIG_MFD_TI_SSP) += ti-ssp.o diff --git a/drivers/mfd/davinci_aemif.c b/drivers/mfd/davinci_aemif.c new file mode 100644 index 0000000..ab3292c --- /dev/null +++ b/drivers/mfd/davinci_aemif.c @@ -0,0 +1,238 @@ +/* + * AEMIF support for DaVinci SoCs + * + * Copyright (C) 2010 Texas Instruments Incorporated. http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static struct mfd_cell davinci_emifs[] = { + { + .name = "davinci_nand", + }, + { + .name = "physmap-flash", + }, +}; + +/* Timing value configuration */ + +#define TA(x) ((x) << 2) +#define RHOLD(x) ((x) << 4) +#define RSTROBE(x) ((x) << 7) +#define RSETUP(x) ((x) << 13) +#define WHOLD(x) ((x) << 17) +#define WSTROBE(x) ((x) << 20) +#define WSETUP(x) ((x) << 26) + +#define TA_MAX 0x3 +#define RHOLD_MAX 0x7 +#define RSTROBE_MAX 0x3f +#define RSETUP_MAX 0xf +#define WHOLD_MAX 0x7 +#define WSTROBE_MAX 0x3f +#define WSETUP_MAX 0xf + +#define TIMING_MASK (TA(TA_MAX) | \ + RHOLD(RHOLD_MAX) | \ + RSTROBE(RSTROBE_MAX) | \ + RSETUP(RSETUP_MAX) | \ + WHOLD(WHOLD_MAX) | \ + WSTROBE(WSTROBE_MAX) | \ + WSETUP(WSETUP_MAX)) + +/* + * aemif_calc_rate - calculate timing data. + * @wanted: The cycle time needed in nanoseconds. + * @clk: The input clock rate in kHz. + * @max: The maximum divider value that can be programmed. + * + * On success, returns the calculated timing value minus 1 for easy + * programming into AEMIF timing registers, else negative errno. + */ +static int aemif_calc_rate(int wanted, unsigned long clk, int max) +{ + int result; + + result = DIV_ROUND_UP((wanted * clk), NSEC_PER_MSEC) - 1; + + pr_debug("%s: result %d from %ld, %d\n", __func__, result, clk, wanted); + + /* It is generally OK to have a more relaxed timing than requested... */ + if (result < 0) + result = 0; + + /* ... But configuring tighter timings is not an option. */ + else if (result > max) + result = -EINVAL; + + return result; +} + +/** + * davinci_aemif_setup_timing - setup timing values for a given AEMIF interface + * @t: timing values to be progammed + * @base: The virtual base address of the AEMIF interface + * @cs: chip-select to program the timing values for + * + * This function programs the given timing values (in real clock) into the + * AEMIF registers taking the AEMIF clock into account. + * + * This function does not use any locking while programming the AEMIF + * because it is expected that there is only one user of a given + * chip-select. + * + * Returns 0 on success, else negative errno. + */ +int davinci_aemif_setup_timing(struct davinci_aemif_timing *t, + void __iomem *base, unsigned cs) +{ + unsigned set, val; + int ta, rhold, rstrobe, rsetup, whold, wstrobe, wsetup; + unsigned offset = A1CR_OFFSET + cs * 4; + struct clk *aemif_clk; + unsigned long clkrate; + + if (!t) + return 0; /* Nothing to do */ + + aemif_clk = clk_get(NULL, "aemif"); + if (IS_ERR(aemif_clk)) + return PTR_ERR(aemif_clk); + + clkrate = clk_get_rate(aemif_clk); + + clkrate /= 1000; /* turn clock into kHz for ease of use */ + + ta = aemif_calc_rate(t->ta, clkrate, TA_MAX); + rhold = aemif_calc_rate(t->rhold, clkrate, RHOLD_MAX); + rstrobe = aemif_calc_rate(t->rstrobe, clkrate, RSTROBE_MAX); + rsetup = aemif_calc_rate(t->rsetup, clkrate, RSETUP_MAX); + whold = aemif_calc_rate(t->whold, clkrate, WHOLD_MAX); + wstrobe = aemif_calc_rate(t->wstrobe, clkrate, WSTROBE_MAX); + wsetup = aemif_calc_rate(t->wsetup, clkrate, WSETUP_MAX); + + if (ta < 0 || rhold < 0 || rstrobe < 0 || rsetup < 0 || + whold < 0 || wstrobe < 0 || wsetup < 0) { + pr_err("%s: cannot get suitable timings\n", __func__); + return -EINVAL; + } + + set = TA(ta) | RHOLD(rhold) | RSTROBE(rstrobe) | RSETUP(rsetup) | + WHOLD(whold) | WSTROBE(wstrobe) | WSETUP(wsetup); + + val = __raw_readl(base + offset); + val &= ~TIMING_MASK; + val |= set; + __raw_writel(val, base + offset); + + return 0; +} +EXPORT_SYMBOL(davinci_aemif_setup_timing); + +static int __init davinci_aemif_probe(struct platform_device *pdev) +{ + struct davinci_aemif_devices *davinci_aemif_devices = + pdev->dev.platform_data; + struct platform_device *devices; + struct mfd_cell *cells; + int i, ret; + + devices = davinci_aemif_devices->devices; + cells = davinci_emifs; + + /* DaVinci NAND device client */ + for (i = 0; i < davinci_aemif_devices->num_devices; i++) { + if (!strcmp(devices[i].name, + cells[DAVINCI_NAND_DEVICE_CELL].name)) + break; + + } + if (i > davinci_aemif_devices->num_devices) { + dev_err(&pdev->dev, "No NAND device found by DaVinci EMIF" + "MFD\n"); + cells[DAVINCI_NAND_DEVICE_CELL].name = NULL; + } else { + cells[DAVINCI_NAND_DEVICE_CELL].platform_data = + devices[i].dev.platform_data; + cells[DAVINCI_NAND_DEVICE_CELL].pdata_size = + sizeof(struct davinci_nand_pdata); + cells[DAVINCI_NAND_DEVICE_CELL].id = devices[i].id; + cells[DAVINCI_NAND_DEVICE_CELL].resources = + devices[i].resource; + cells[DAVINCI_NAND_DEVICE_CELL].num_resources = + devices[i].num_resources; + } + + /* DaVinci NOR device client */ + for (i = 0; i < davinci_aemif_devices->num_devices; i++) { + if (!strcmp(devices[i].name, + cells[DAVINCI_NOR_FLASH_CELL].name)) + break; + } + + if (i > davinci_aemif_devices->num_devices) { + dev_err(&pdev->dev, "No NOR device found by DaVinci EMIF" + "MFD\n"); + cells[DAVINCI_NOR_FLASH_CELL].name = NULL; + } else { + cells[DAVINCI_NOR_FLASH_CELL].platform_data = + devices[i].dev.platform_data; + cells[DAVINCI_NOR_FLASH_CELL].pdata_size = + sizeof(struct physmap_flash_data); + cells[DAVINCI_NOR_FLASH_CELL].id = devices[i].id; + cells[DAVINCI_NOR_FLASH_CELL].resources = devices[i].resource; + cells[DAVINCI_NOR_FLASH_CELL].num_resources = + devices[i].num_resources; + } + + ret = mfd_add_devices(&pdev->dev, pdev->id, cells, + davinci_aemif_devices->num_devices, NULL, 0); + if (ret != 0) + dev_err(&pdev->dev, "fail to register client devices\n"); + + return 0; +} + +static int __devexit davinci_aemif_remove(struct platform_device *pdev) +{ + mfd_remove_devices(&pdev->dev); + return 0; +} + +static struct platform_driver davinci_aemif_driver = { + .driver = { + .name = "davinci_aemif", + .owner = THIS_MODULE, + }, + .remove = __devexit_p(davinci_aemif_remove), +}; + +static int __init davinci_aemif_init(void) +{ + return platform_driver_probe(&davinci_aemif_driver, + davinci_aemif_probe); +} +module_init(davinci_aemif_init); + +static void __exit davinci_aemif_exit(void) +{ + platform_driver_unregister(&davinci_aemif_driver); +} +module_exit(davinci_aemif_exit); + +MODULE_AUTHOR("Prakash Manjunathappa"); +MODULE_DESCRIPTION("Texas Instruments AEMIF Interface"); +MODULE_LICENSE("GPL"); diff --git a/include/linux/mfd/davinci_aemif.h b/include/linux/mfd/davinci_aemif.h index 05b2934..18650c3 100644 --- a/include/linux/mfd/davinci_aemif.h +++ b/include/linux/mfd/davinci_aemif.h @@ -10,6 +10,10 @@ #ifndef _MACH_DAVINCI_AEMIF_H #define _MACH_DAVINCI_AEMIF_H +#include +#include +#include + #define NRCSR_OFFSET 0x00 #define AWCCR_OFFSET 0x04 #define A1CR_OFFSET 0x10 @@ -18,6 +22,16 @@ #define ACR_EW_MASK BIT(30) #define ACR_SS_MASK BIT(31) +enum davinci_emif_cells { + DAVINCI_NAND_DEVICE_CELL, + DAVINCI_NOR_FLASH_CELL, +}; + +struct davinci_aemif_devices { + struct platform_device *devices; + unsigned int num_devices; +}; + /* All timings in nanoseconds */ struct davinci_aemif_timing { u8 wsetup; -- 1.7.1 From prakash.pm at ti.com Mon Jan 23 09:15:25 2012 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Mon, 23 Jan 2012 20:45:25 +0530 Subject: [PATCH 3/3] arm: da830: move NAND and NOR devices as aemif MFD slaves Message-ID: <1327331725-10559-1-git-send-email-prakash.pm@ti.com> NAND and NOR device are made as aemif devices slave, hence device registration achieved via aemif MFD driver. Signed-off-by: Manjunathappa, Prakash --- arch/arm/mach-davinci/board-da830-evm.c | 31 +++++++++++++++++++++++-------- 1 files changed, 23 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c index 0b43554..0ad3662 100644 --- a/arch/arm/mach-davinci/board-da830-evm.c +++ b/arch/arm/mach-davinci/board-da830-evm.c @@ -396,14 +396,29 @@ static struct resource da830_evm_nand_resources[] = { }, }; -static struct platform_device da830_evm_nand_device = { - .name = "davinci_nand", - .id = 1, - .dev = { - .platform_data = &da830_evm_nand_pdata, +static struct platform_device da830_evm_devices[] __initdata = { + { + .name = "davinci_nand", + .id = 1, + .dev = { + .platform_data = &da830_evm_nand_pdata, + }, + .num_resources = ARRAY_SIZE(da830_evm_nand_resources), + .resource = da830_evm_nand_resources, + }, +}; + +static struct davinci_aemif_devices da830_emif_devices = { + .devices = da830_evm_devices, + .num_devices = ARRAY_SIZE(da830_evm_devices), +}; + +static struct platform_device davinci_emif_device = { + .name = "davinci_aemif", + .id = -1, + .dev = { + .platform_data = &da830_emif_devices, }, - .num_resources = ARRAY_SIZE(da830_evm_nand_resources), - .resource = da830_evm_nand_resources, }; static inline void da830_evm_init_nand(int mux_mode) @@ -422,7 +437,7 @@ static inline void da830_evm_init_nand(int mux_mode) pr_warning("da830_evm_init: emif25 mux setup failed: %d\n", ret); - ret = platform_device_register(&da830_evm_nand_device); + ret = platform_device_register(&davinci_emif_device); if (ret) pr_warning("da830_evm_init: NAND device not registered.\n"); -- 1.7.1 From linux at arm.linux.org.uk Mon Jan 23 11:04:36 2012 From: linux at arm.linux.org.uk (Russell King - ARM Linux) Date: Mon, 23 Jan 2012 17:04:36 +0000 Subject: [RESEND PATCH] arm:davinci: prepare to move aemif driver to drivers/mfd In-Reply-To: <1327331552-9913-1-git-send-email-prakash.pm@ti.com> References: <1327331552-9913-1-git-send-email-prakash.pm@ti.com> Message-ID: <20120123170436.GZ1068@n2100.arm.linux.org.uk> On Mon, Jan 23, 2012 at 08:42:32PM +0530, Manjunathappa, Prakash wrote: > Adding: MFD maintainer and mailing list. > > arch/arm/mach-davinci/aemif.c | 2 +- > arch/arm/mach-davinci/board-da830-evm.c | 2 +- > arch/arm/mach-davinci/board-da850-evm.c | 2 +- > arch/arm/mach-davinci/include/mach/aemif.h | 36 ---------------------------- > drivers/mtd/nand/davinci_nand.c | 2 +- > include/linux/mfd/davinci_aemif.h | 36 ++++++++++++++++++++++++++++ > 6 files changed, 40 insertions(+), 40 deletions(-) > delete mode 100644 arch/arm/mach-davinci/include/mach/aemif.h > create mode 100644 include/linux/mfd/davinci_aemif.h As Linus has requested on many occasions, and it's a damned good idea, use -M when generating diffstat - and its also a *really* good idea to use -M if you're submitting patches which rename files for review as well. Obviously arch/arm/mach-davinci/include/mach/aemif.h was moved to include/linux/mfd/davinci_aemif.h, but were there any changes to its contents? Without -M, there only way of knowing is to compare each file line by line. With -M, it'll tell us that it was renamed and produce a diff between the old and new location. From mm05 at mail.ru Mon Jan 23 13:20:29 2012 From: mm05 at mail.ru (Anatoly Sivov) Date: Mon, 23 Jan 2012 23:20:29 +0400 Subject: [RFC PATCH 4/7] ARM: davinci: net: davinci_emac: add OF support In-Reply-To: <1327308967-8092-5-git-send-email-hs@denx.de> References: <1327308967-8092-1-git-send-email-hs@denx.de> <1327308967-8092-5-git-send-email-hs@denx.de> Message-ID: Hello Heiko, > +* Texas Instruments Davinci EMAC > + > +This file provides information, what the davice node > +for the davinci_emac interface contain. Please, fix the typo. (davice -> device) BR, Anatoly From sylvester.nawrocki at gmail.com Mon Jan 23 14:35:12 2012 From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki) Date: Mon, 23 Jan 2012 21:35:12 +0100 Subject: [RFC PATCH 5/7] ARM: davinci: i2c: add OF support In-Reply-To: <1327308967-8092-6-git-send-email-hs@denx.de> References: <1327308967-8092-1-git-send-email-hs@denx.de> <1327308967-8092-6-git-send-email-hs@denx.de> Message-ID: <4F1DC480.4010603@gmail.com> Hello, On 01/23/2012 09:56 AM, Heiko Schocher wrote: > add of support for the davinci i2c driver. > > Signed-off-by: Heiko Schocher > Cc: davinci-linux-open-source at linux.davincidsp.com > Cc: linux-arm-kernel at lists.infradead.org > Cc: devicetree-discuss at lists.ozlabs.org > Cc: linux-i2c at vger.kernel.org > Cc: Ben Dooks > Cc: Wolfram Sang > Cc: Grant Likely > Cc: Sekhar Nori > Cc: Wolfgang Denk > --- > .../devicetree/bindings/arm/davinci/i2c.txt | 39 ++++++++++++++++++ > drivers/i2c/busses/i2c-davinci.c | 43 ++++++++++++++++++++ > 2 files changed, 82 insertions(+), 0 deletions(-) > create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt > > diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt b/Documentation/devicetree/bindings/arm/davinci/i2c.txt > new file mode 100644 > index 0000000..94ec670 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt > @@ -0,0 +1,39 @@ > +* Texas Instruments Davinci I2C > + > +This file provides information, what the device node for the > +davinci i2c interface contain. > + > +Required properties: > +- compatible: "ti,davinci-i2c"; > +- reg : Offset and length of the register set for the device > +- id: id of the controller I was wondering whether we're supposed to use "cell-index" property name for such a device instance index? or doesn't it really matter and "id" is fine? Such an IP instance index seems quite common so I thought it could be easier to follow to use standard name. -- Regards, Sylwester From prakash.pm at ti.com Mon Jan 23 23:24:00 2012 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Tue, 24 Jan 2012 05:24:00 +0000 Subject: [RESEND PATCH] arm:davinci: prepare to move aemif driver to drivers/mfd In-Reply-To: <20120123170436.GZ1068@n2100.arm.linux.org.uk> References: <1327331552-9913-1-git-send-email-prakash.pm@ti.com> <20120123170436.GZ1068@n2100.arm.linux.org.uk> Message-ID: Hi Russell King, On Mon, Jan 23, 2012 at 22:34:36, Russell King - ARM Linux wrote: > On Mon, Jan 23, 2012 at 08:42:32PM +0530, Manjunathappa, Prakash wrote: > > Adding: MFD maintainer and mailing list. > > > > arch/arm/mach-davinci/aemif.c | 2 +- > > arch/arm/mach-davinci/board-da830-evm.c | 2 +- > > arch/arm/mach-davinci/board-da850-evm.c | 2 +- > > arch/arm/mach-davinci/include/mach/aemif.h | 36 ---------------------------- > > drivers/mtd/nand/davinci_nand.c | 2 +- > > include/linux/mfd/davinci_aemif.h | 36 ++++++++++++++++++++++++++++ > > 6 files changed, 40 insertions(+), 40 deletions(-) > > delete mode 100644 arch/arm/mach-davinci/include/mach/aemif.h > > create mode 100644 include/linux/mfd/davinci_aemif.h > > As Linus has requested on many occasions, and it's a damned good > idea, use -M when generating diffstat - and its also a *really* good > idea to use -M if you're submitting patches which rename files for > review as well. > > Obviously arch/arm/mach-davinci/include/mach/aemif.h was moved to > include/linux/mfd/davinci_aemif.h, but were there any changes to its > contents? Without -M, there only way of knowing is to compare each > file line by line. With -M, it'll tell us that it was renamed and > produce a diff between the old and new location. > Yes, I will make it a point to do this in next version and in future. Thanks, Prakash From hs at denx.de Tue Jan 24 00:14:42 2012 From: hs at denx.de (Heiko Schocher) Date: Tue, 24 Jan 2012 07:14:42 +0100 Subject: [RFC PATCH 4/7] ARM: davinci: net: davinci_emac: add OF support In-Reply-To: References: <1327308967-8092-1-git-send-email-hs@denx.de> <1327308967-8092-5-git-send-email-hs@denx.de> Message-ID: <4F1E4C52.1000403@denx.de> Hello Anatoly, Anatoly Sivov wrote: > Hello Heiko, > >> +* Texas Instruments Davinci EMAC >> + >> +This file provides information, what the davice node >> +for the davinci_emac interface contain. > Please, fix the typo. (davice -> device) Ups, thanks! Fix this in the next version, just waiting for more comments... bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany From hs at denx.de Tue Jan 24 01:18:28 2012 From: hs at denx.de (Heiko Schocher) Date: Tue, 24 Jan 2012 08:18:28 +0100 Subject: [RFC PATCH 5/7] ARM: davinci: i2c: add OF support In-Reply-To: <4F1DC480.4010603@gmail.com> References: <1327308967-8092-1-git-send-email-hs@denx.de> <1327308967-8092-6-git-send-email-hs@denx.de> <4F1DC480.4010603@gmail.com> Message-ID: <4F1E5B44.4090200@denx.de> Hello Sylwester, Sylwester Nawrocki wrote: > Hello, > > On 01/23/2012 09:56 AM, Heiko Schocher wrote: >> add of support for the davinci i2c driver. >> >> Signed-off-by: Heiko Schocher >> Cc: davinci-linux-open-source at linux.davincidsp.com >> Cc: linux-arm-kernel at lists.infradead.org >> Cc: devicetree-discuss at lists.ozlabs.org >> Cc: linux-i2c at vger.kernel.org >> Cc: Ben Dooks >> Cc: Wolfram Sang >> Cc: Grant Likely >> Cc: Sekhar Nori >> Cc: Wolfgang Denk >> --- >> .../devicetree/bindings/arm/davinci/i2c.txt | 39 ++++++++++++++++++ >> drivers/i2c/busses/i2c-davinci.c | 43 ++++++++++++++++++++ >> 2 files changed, 82 insertions(+), 0 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt >> >> diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt b/Documentation/devicetree/bindings/arm/davinci/i2c.txt >> new file mode 100644 >> index 0000000..94ec670 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt >> @@ -0,0 +1,39 @@ >> +* Texas Instruments Davinci I2C >> + >> +This file provides information, what the device node for the >> +davinci i2c interface contain. >> + >> +Required properties: >> +- compatible: "ti,davinci-i2c"; >> +- reg : Offset and length of the register set for the device >> +- id: id of the controller > > I was wondering whether we're supposed to use "cell-index" property name > for such a device instance index? or doesn't it really matter and "id" is > fine? Such an IP instance index seems quite common so I thought it could > be easier to follow to use standard name. I just copied the "name" from "struct davinci_nand_pdata" ... it is used in the davinci_nand driver as chipselect ... maybe it is better I rename this to "chipselect" ? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany From hs at denx.de Tue Jan 24 01:23:46 2012 From: hs at denx.de (Heiko Schocher) Date: Tue, 24 Jan 2012 08:23:46 +0100 Subject: [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller In-Reply-To: <4F1DF465.60206@freescale.com> References: <1327308967-8092-1-git-send-email-hs@denx.de> <1327308967-8092-7-git-send-email-hs@denx.de> <4F1DF465.60206@freescale.com> Message-ID: <4F1E5C82.60108@denx.de> Hello Scott, Scott Wood wrote: > On 01/23/2012 02:56 AM, Heiko Schocher wrote: >> diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt b/Documentation/devicetree/bindings/arm/davinci/nand.txt >> new file mode 100644 >> index 0000000..7e8d6db >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/arm/davinci/nand.txt >> @@ -0,0 +1,72 @@ >> +* Texas Instruments Davinci NAND >> + >> +This file provides information, what the device node for the >> +davinci nand interface contain. >> + >> +Required properties: >> +- compatible: "ti,davinci-nand"; >> +- reg : contain 2 offset/length values: >> + - offset and length for the access window >> + - offset and length for accessing the aemif control registers >> +- id: id of the controller > > What does "id of the controller" mean, specfically? From this I can't > even tell if it's a number or a string, much less how to use it > semantically. If it's just a "match what's in the manual" thing, > perhaps an alias would be better here. Or, if it's a value with a > specific meaning (e.g. that you need to program into a register) use a > more specific name. Ok, fix this. Id means here, which chipselect the controller uses. Maybe it is better to rename it to "chipselect" ? >> +Recommended properties : >> +- mask_ale: mask for ale >> +- mask_cle: mask for cle >> +- mask_chipsel: mask for chipselect >> +- ecc_mode: ECC mode, see NAND_ECC_* defines >> +- ecc_bits: used ECC bits >> +- options: nand options, defined in >> + include/linux/mtd/nand.h, grep for NAND_NO_AUTOINCR >> +- bbt_options: NAND_BBT_* defines > > Binding-specific properties should have a vendor prefix. Dashes are > preferred to underscores. You think something like that: davinci-mask-ale davinci-mask-cle ... ? > Don't specify Linux internals by reference -- they could change and > invalidate existing device trees and non-Linux code that accepts them > (e.g. U-Boot). If you want them to line up, copy the definition here, > and if Linux changes, write glue code to convert. It would probably be > better to define specific properties for anything that must be specified > here (neither deteted dynamically nor defined by compatible = > "ti,davinci-nand"). Ok, I add the defines here, and add also a comment in the dts. > Do all of these properties really belong here? I can see providing some I think so, because this values come from existing platform code (grep for struct davinci_nand_pdata) > information about ECC or BBT mode, if there are multiple conventions > already in use (or that are reasonably justifiable for different > situations), as that must agree with how the flash has already been > programmed. How much of the rest can vary from one "ti,davinci-nand" to > another? Maybe it's obvious to someone more familiar with davinci, but > what does "mask for ale/cle/chipselect" mean? I mapped here just the existing platform code (=struct davinci_nand_pdata) to OF, so existing boards can easy switch to OF. Comment in arch/arm/mach-davinci/include/mach/nand.h says for mask_ale and mask_cle: /* NOTE: boards don't need to use these address bits * for ALE/CLE unless they support booting from NAND. * They're used unless platform data overrides them. */ It is used for addressing the ALE/CLE Signals through the address, used on the arch/arm/mach-davinci/board-dm646x-evm.c and arch/arm/mach-davinci/board-tnetv107x-evm.c board ... so I think, this should be also be setupable through OF ... >> + nandflash at 3,0 { > > PowerPC's ePAPR document -- not directly relevant to ARM, but contains a > more recently updated list of generic names than the IEEE1275 > recommended pratice -- specifies "flash@". If you don't want to do > that, "nand@" is used in many existing trees. Why introduce a new name? There is no reason for that, change this to "nand@". Thanks for the review. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany From linux at arm.linux.org.uk Tue Jan 24 03:50:09 2012 From: linux at arm.linux.org.uk (Russell King - ARM Linux) Date: Tue, 24 Jan 2012 09:50:09 +0000 Subject: ARM/ARM-SoC plans for v3.4 merge window In-Reply-To: <20120123114902.GY1068@n2100.arm.linux.org.uk> References: <20120123114902.GY1068@n2100.arm.linux.org.uk> Message-ID: <20120124095009.GS16726@n2100.arm.linux.org.uk> On Mon, Jan 23, 2012 at 11:49:02AM +0000, Russell King - ARM Linux wrote: > This is an outline of the plan for this cycle, up to the next merge > window, agreed between Olof and myself. > > As Nicolas' idle changes weren't merged before the last merge window > opened, we have decided that Nicolas will resubmit his changes after > -rc1 (in other words, now) and they will be merged into both the > arm-soc and my trees. > > I have at least one other patch which has a high 'will cause horrible > conficts' rating (the debug option rearrangement patch), so I'll be > including that for the arm-soc tree as well. > > However, what this does mean is that Arnd, Olof, and myself will be > in for up to three months of merge hell unless people take account of > these changes. > > Therefore, our plan is to publish this as a baseline, and we'd really > appreciate any development submitted after that baseline has been > established is based upon those changes and does not conflict with > them. That may mean you have to pull these changes into your tree > and merge them into your development work (and fix up any conflicts > there yourself.) > > Once you've taken these changes into your tree, you must not rebase or > modify them. Changing those commits will cause all hell to break loose, > and we'll have to refuse merging your tree (otherwise we'll be in Linus' > sights for a roasting at gas mark 2 million.) Right, although it's out there - but I'd like to get the AMBA changes into it which are already conflicting the Samsung development. So I'm going to hold off officially asking for people to include the baseline until this evening. At that point, I will shut down my 'amba' branch and transfer that over; that means I won't be accepting any further acks etc for that work. If you haven't acked changes in the amba branch (eg, to Versatile, Realview etc) then it'll soon be too late... From scottwood at freescale.com Mon Jan 23 17:59:33 2012 From: scottwood at freescale.com (Scott Wood) Date: Mon, 23 Jan 2012 17:59:33 -0600 Subject: [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller In-Reply-To: <1327308967-8092-7-git-send-email-hs@denx.de> References: <1327308967-8092-1-git-send-email-hs@denx.de> <1327308967-8092-7-git-send-email-hs@denx.de> Message-ID: <4F1DF465.60206@freescale.com> On 01/23/2012 02:56 AM, Heiko Schocher wrote: > diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt b/Documentation/devicetree/bindings/arm/davinci/nand.txt > new file mode 100644 > index 0000000..7e8d6db > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/davinci/nand.txt > @@ -0,0 +1,72 @@ > +* Texas Instruments Davinci NAND > + > +This file provides information, what the device node for the > +davinci nand interface contain. > + > +Required properties: > +- compatible: "ti,davinci-nand"; > +- reg : contain 2 offset/length values: > + - offset and length for the access window > + - offset and length for accessing the aemif control registers > +- id: id of the controller What does "id of the controller" mean, specfically? From this I can't even tell if it's a number or a string, much less how to use it semantically. If it's just a "match what's in the manual" thing, perhaps an alias would be better here. Or, if it's a value with a specific meaning (e.g. that you need to program into a register) use a more specific name. > +Recommended properties : > +- mask_ale: mask for ale > +- mask_cle: mask for cle > +- mask_chipsel: mask for chipselect > +- ecc_mode: ECC mode, see NAND_ECC_* defines > +- ecc_bits: used ECC bits > +- options: nand options, defined in > + include/linux/mtd/nand.h, grep for NAND_NO_AUTOINCR > +- bbt_options: NAND_BBT_* defines Binding-specific properties should have a vendor prefix. Dashes are preferred to underscores. Don't specify Linux internals by reference -- they could change and invalidate existing device trees and non-Linux code that accepts them (e.g. U-Boot). If you want them to line up, copy the definition here, and if Linux changes, write glue code to convert. It would probably be better to define specific properties for anything that must be specified here (neither deteted dynamically nor defined by compatible = "ti,davinci-nand"). Do all of these properties really belong here? I can see providing some information about ECC or BBT mode, if there are multiple conventions already in use (or that are reasonably justifiable for different situations), as that must agree with how the flash has already been programmed. How much of the rest can vary from one "ti,davinci-nand" to another? Maybe it's obvious to someone more familiar with davinci, but what does "mask for ale/cle/chipselect" mean? > + nandflash at 3,0 { PowerPC's ePAPR document -- not directly relevant to ARM, but contains a more recently updated list of generic names than the IEEE1275 recommended pratice -- specifies "flash@". If you don't want to do that, "nand@" is used in many existing trees. Why introduce a new name? -Scott From s.nawrocki at samsung.com Tue Jan 24 03:51:50 2012 From: s.nawrocki at samsung.com (Sylwester Nawrocki) Date: Tue, 24 Jan 2012 10:51:50 +0100 Subject: [RFC PATCH 5/7] ARM: davinci: i2c: add OF support In-Reply-To: <4F1E5B44.4090200@denx.de> References: <1327308967-8092-1-git-send-email-hs@denx.de> <1327308967-8092-6-git-send-email-hs@denx.de> <4F1DC480.4010603@gmail.com> <4F1E5B44.4090200@denx.de> Message-ID: <4F1E7F36.50505@samsung.com> Hello Heiko, On 01/24/2012 08:18 AM, Heiko Schocher wrote: >> On 01/23/2012 09:56 AM, Heiko Schocher wrote: >>> add of support for the davinci i2c driver. >>> >>> Signed-off-by: Heiko Schocher >>> Cc: davinci-linux-open-source at linux.davincidsp.com >>> Cc: linux-arm-kernel at lists.infradead.org >>> Cc: devicetree-discuss at lists.ozlabs.org >>> Cc: linux-i2c at vger.kernel.org >>> Cc: Ben Dooks >>> Cc: Wolfram Sang >>> Cc: Grant Likely >>> Cc: Sekhar Nori >>> Cc: Wolfgang Denk >>> --- >>> .../devicetree/bindings/arm/davinci/i2c.txt | 39 ++++++++++++++++++ >>> drivers/i2c/busses/i2c-davinci.c | 43 ++++++++++++++++++++ >>> 2 files changed, 82 insertions(+), 0 deletions(-) >>> create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt >>> >>> diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt b/Documentation/devicetree/bindings/arm/davinci/i2c.txt >>> new file mode 100644 >>> index 0000000..94ec670 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt >>> @@ -0,0 +1,39 @@ >>> +* Texas Instruments Davinci I2C >>> + >>> +This file provides information, what the device node for the >>> +davinci i2c interface contain. >>> + >>> +Required properties: >>> +- compatible: "ti,davinci-i2c"; >>> +- reg : Offset and length of the register set for the device >>> +- id: id of the controller >> >> I was wondering whether we're supposed to use "cell-index" property name >> for such a device instance index? or doesn't it really matter and "id" is >> fine? Such an IP instance index seems quite common so I thought it could >> be easier to follow to use standard name. > > I just copied the "name" from "struct davinci_nand_pdata" ... it is > used in the davinci_nand driver as chipselect ... maybe it is better > I rename this to "chipselect" ? >From what I can see the 'id' property is used to determine I2C adapter number. In that case 'id' seems more correct than "chipselect". Are you sure there is a chip select functionality in I2C controller ? It seems that your id is just an index of I2C controller in hardware. I would personally just use cell-index for that, but I'm not a dt expert, someone nay correct me. For instance, this is how "cell-index" semantics is described in case of MPC5200 Programmable Serial Controllers (from Documentation/devicetree/ bindings/powerpc/fsl/mpc5200.txt): "fsl,mpc5200-psc nodes --------------------- The PSCs should include a cell-index which is the index of the PSC in hardware. cell-index is used to determine which shared SoC registers to use when setting up PSC clocking. cell-index number starts at '0'. ie: PSC1 has 'cell-index = <0>' PSC4 has 'cell-index = <3>'" Moreover you seem to overwrite platform device name and id, if (!of_property_read_u32(pdev->dev.of_node, "id", + &prop)) { + pdev->id = prop; + pdev->dev.init_name = kzalloc(20, GFP_KERNEL); + sprintf((char *)pdev->dev.init_name, + "i2c_davinci.%d", pdev->id); I'm not sure if it is a good practice. If you want to pre-define platform device name (likely for the clock API to work), it might be more appropriate to use OF_DEV_AUXDATA in the machine code, until there are clock bindings available. Then you would just use your 'id'/'cell-index' property to set an I2C adapter number. -- Regards, Sylwester From will.deacon at arm.com Tue Jan 24 04:56:45 2012 From: will.deacon at arm.com (Will Deacon) Date: Tue, 24 Jan 2012 10:56:45 +0000 Subject: ARM/ARM-SoC plans for v3.4 merge window In-Reply-To: <20120124095009.GS16726@n2100.arm.linux.org.uk> References: <20120123114902.GY1068@n2100.arm.linux.org.uk> <20120124095009.GS16726@n2100.arm.linux.org.uk> Message-ID: <20120124105645.GE19798@mudshark.cambridge.arm.com> Hi Russell, On Tue, Jan 24, 2012 at 09:50:09AM +0000, Russell King - ARM Linux wrote: > Right, although it's out there - but I'd like to get the AMBA changes > into it which are already conflicting the Samsung development. So I'm > going to hold off officially asking for people to include the baseline > until this evening. At that point, I will shut down my 'amba' branch > and transfer that over; that means I won't be accepting any further > acks etc for that work. > > If you haven't acked changes in the amba branch (eg, to Versatile, > Realview etc) then it'll soon be too late... I took a look at your amba branch, but all I can see in there is: 6cfa627 ARM: 7079/1: spi: Fix builderror in spi-pl022.c 1c3be36 PM: add runtime PM support to MMCI 92b97f0 PM: add runtime PM support to core Primecell driver which don't seem to touch Versatile or Realview. Am I looking in the wrong place? Cheers, Will From ido at wizery.com Tue Jan 24 05:02:36 2012 From: ido at wizery.com (Ido Yariv) Date: Tue, 24 Jan 2012 13:02:36 +0200 Subject: [RFC] ARM: davinci: Fix boards' phy ids Message-ID: <1327402956-626-1-git-send-email-ido@wizery.com> Commit 5a05a820 "davinci_emac: use an unique MDIO bus name" modified the mdio bus id to be unique by adding a 'davinci_mdio-' prefix to it. The phy ids need to be modified accordingly in order to connect the ethernet device to the phy device. Fix this by modifying the phy ids in all davinci board files. Signed-off-by: Ido Yariv CC: Florian Fainelli --- This patch was only tested on an AM18 (DA850) board. arch/arm/mach-davinci/board-da850-evm.c | 2 +- arch/arm/mach-davinci/board-dm365-evm.c | 2 +- arch/arm/mach-davinci/board-dm644x-evm.c | 2 +- arch/arm/mach-davinci/board-dm646x-evm.c | 2 +- arch/arm/mach-davinci/board-neuros-osd2.c | 2 +- arch/arm/mach-davinci/board-omapl138-hawk.c | 2 +- arch/arm/mach-davinci/board-sffsdr.c | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c index 6b22b54..d508890 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c @@ -44,7 +44,7 @@ #include #include -#define DA850_EVM_PHY_ID "0:00" +#define DA850_EVM_PHY_ID "davinci_mdio-0:00" #define DA850_LCD_PWR_PIN GPIO_TO_PIN(2, 8) #define DA850_LCD_BL_PIN GPIO_TO_PIN(2, 15) diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c index 346e1de..849311d 100644 --- a/arch/arm/mach-davinci/board-dm365-evm.c +++ b/arch/arm/mach-davinci/board-dm365-evm.c @@ -54,7 +54,7 @@ static inline int have_tvp7002(void) return 0; } -#define DM365_EVM_PHY_ID "0:01" +#define DM365_EVM_PHY_ID "davinci_mdio-0:01" /* * A MAX-II CPLD is used for various board control functions. */ diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index a64b49c..1247ecd 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -40,7 +40,7 @@ #include #include -#define DM644X_EVM_PHY_ID "0:01" +#define DM644X_EVM_PHY_ID "davinci_mdio-0:01" #define LXT971_PHY_ID (0x001378e2) #define LXT971_PHY_MASK (0xfffffff0) diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c index 6401755..872ac69 100644 --- a/arch/arm/mach-davinci/board-dm646x-evm.c +++ b/arch/arm/mach-davinci/board-dm646x-evm.c @@ -736,7 +736,7 @@ static struct davinci_uart_config uart_config __initdata = { .enabled_uarts = (1 << 0), }; -#define DM646X_EVM_PHY_ID "0:01" +#define DM646X_EVM_PHY_ID "davinci_mdio-0:01" /* * The following EDMA channels/slots are not being used by drivers (for * example: Timer, GPIO, UART events etc) on dm646x, hence they are being diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c index 6c4a164..8d34f51 100644 --- a/arch/arm/mach-davinci/board-neuros-osd2.c +++ b/arch/arm/mach-davinci/board-neuros-osd2.c @@ -39,7 +39,7 @@ #include #include -#define NEUROS_OSD2_PHY_ID "0:01" +#define NEUROS_OSD2_PHY_ID "davinci_mdio-0:01" #define LXT971_PHY_ID 0x001378e2 #define LXT971_PHY_MASK 0xfffffff0 diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c index e7c0c7c..45e8157 100644 --- a/arch/arm/mach-davinci/board-omapl138-hawk.c +++ b/arch/arm/mach-davinci/board-omapl138-hawk.c @@ -21,7 +21,7 @@ #include #include -#define HAWKBOARD_PHY_ID "0:07" +#define HAWKBOARD_PHY_ID "davinci_mdio-0:07" #define DA850_HAWK_MMCSD_CD_PIN GPIO_TO_PIN(3, 12) #define DA850_HAWK_MMCSD_WP_PIN GPIO_TO_PIN(3, 13) diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c index 0b136a8..31da3c5 100644 --- a/arch/arm/mach-davinci/board-sffsdr.c +++ b/arch/arm/mach-davinci/board-sffsdr.c @@ -42,7 +42,7 @@ #include #include -#define SFFSDR_PHY_ID "0:01" +#define SFFSDR_PHY_ID "davinci_mdio-0:01" static struct mtd_partition davinci_sffsdr_nandflash_partition[] = { /* U-Boot Environment: Block 0 * UBL: Block 1 -- 1.7.7.5 From ido at wizery.com Tue Jan 24 05:05:02 2012 From: ido at wizery.com (Ido Yariv) Date: Tue, 24 Jan 2012 13:05:02 +0200 Subject: [RFC 1/2] mmc: davinci: Eliminate spurious interrupts Message-ID: <1327403103-690-1-git-send-email-ido@wizery.com> The davinci mmc interrupt handler fills the fifo, as long as the DXRDY or DRRDY bits are set in the status register. If interrupts fire during this loop, they will be handled by the handler, but the interrupt controller will still buffer these. As a result, the handler will be called again to serve these needlessly. In order to avoid these spurious interrupts, keep interrupts masked while filling the fifo. Signed-off-by: Ido Yariv --- drivers/mmc/host/davinci_mmc.c | 33 +++++++++++++++++++++++++++------ 1 files changed, 27 insertions(+), 6 deletions(-) diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c index 64a8325..9cea66f 100644 --- a/drivers/mmc/host/davinci_mmc.c +++ b/drivers/mmc/host/davinci_mmc.c @@ -1009,12 +1009,33 @@ static irqreturn_t mmc_davinci_irq(int irq, void *dev_id) * by read. So, it is not unbouned loop even in the case of * non-dma. */ - while (host->bytes_left && (status & (MMCST0_DXRDY | MMCST0_DRRDY))) { - davinci_fifo_data_trans(host, rw_threshold); - status = readl(host->base + DAVINCI_MMCST0); - if (!status) - break; - qstatus |= status; + if (host->bytes_left && (status & (MMCST0_DXRDY | MMCST0_DRRDY))) { + unsigned long im_val; + + /* + * If interrupts fire during the following loop, they will be + * handled by the handler, but the PIC will still buffer these. + * As a result, the handler will be called again to serve these + * needlessly. In order to avoid these spurious interrupts, + * keep interrupts masked during the loop. + */ + im_val = readl(host->base + DAVINCI_MMCIM); + writel(0, host->base + DAVINCI_MMCIM); + + do { + davinci_fifo_data_trans(host, rw_threshold); + status = readl(host->base + DAVINCI_MMCST0); + qstatus |= status; + } while (host->bytes_left && + (status & (MMCST0_DXRDY | MMCST0_DRRDY))); + + /* + * If an interrupt is pending, it is assumed it will fire when + * it is unmasked. This assumption is also taken when the MMCIM + * is first set. Otherwise, writing to MMCIM after reading the + * status is race-prone. + */ + writel(im_val, host->base + DAVINCI_MMCIM); } if (qstatus & MMCST0_DATDNE) { -- 1.7.7.5 From ido at wizery.com Tue Jan 24 05:05:03 2012 From: ido at wizery.com (Ido Yariv) Date: Tue, 24 Jan 2012 13:05:03 +0200 Subject: [RFC 2/2] mmc: davinci: Poll status for small size transfers In-Reply-To: <1327403103-690-1-git-send-email-ido@wizery.com> References: <1327403103-690-1-git-send-email-ido@wizery.com> Message-ID: <1327403103-690-2-git-send-email-ido@wizery.com> For small size non-dma sdio transactions, it is sometimes better to poll the mmc host and avoid interrupts altogether. Polling lowers the number of interrupts and context switches. Tests have shown that for small transactions, only a few polling iterations are needed, so this is worth while. Signed-off-by: Ido Yariv --- drivers/mmc/host/davinci_mmc.c | 29 ++++++++++++++++++++++++++++- 1 files changed, 28 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c index 9cea66f..fb1368a 100644 --- a/drivers/mmc/host/davinci_mmc.c +++ b/drivers/mmc/host/davinci_mmc.c @@ -160,6 +160,16 @@ module_param(rw_threshold, uint, S_IRUGO); MODULE_PARM_DESC(rw_threshold, "Read/Write threshold. Default = 32"); +static unsigned poll_threshold = 128; +module_param(poll_threshold, uint, S_IRUGO); +MODULE_PARM_DESC(poll_threshold, + "Polling transaction size threshold. Default = 128"); + +static unsigned poll_loopcount = 32; +module_param(poll_loopcount, uint, S_IRUGO); +MODULE_PARM_DESC(poll_loopcount, + "Maximum polling loop count. Default = 32"); + static unsigned __initdata use_dma = 1; module_param(use_dma, uint, 0); MODULE_PARM_DESC(use_dma, "Whether to use DMA or not. Default = 1"); @@ -193,6 +203,7 @@ struct mmc_davinci_host { bool use_dma; bool do_dma; bool sdio_int; + bool active_request; /* Scatterlist DMA uses one or more parameter RAM entries: * the main one (associated with rxdma or txdma) plus zero or @@ -219,6 +230,7 @@ struct mmc_davinci_host { #endif }; +static irqreturn_t mmc_davinci_irq(int irq, void *dev_id); /* PIO only */ static void mmc_davinci_sg_to_buf(struct mmc_davinci_host *host) @@ -376,7 +388,20 @@ static void mmc_davinci_start_command(struct mmc_davinci_host *host, writel(cmd->arg, host->base + DAVINCI_MMCARGHL); writel(cmd_reg, host->base + DAVINCI_MMCCMD); - writel(im_val, host->base + DAVINCI_MMCIM); + + host->active_request = true; + + if (!host->do_dma && host->bytes_left <= poll_threshold) { + u32 count = poll_loopcount; + + while (host->active_request && count--) { + mmc_davinci_irq(0, host); + cpu_relax(); + } + } + + if (host->active_request) + writel(im_val, host->base + DAVINCI_MMCIM); } /*----------------------------------------------------------------------*/ @@ -915,6 +940,7 @@ mmc_davinci_xfer_done(struct mmc_davinci_host *host, struct mmc_data *data) if (!data->stop || (host->cmd && host->cmd->error)) { mmc_request_done(host->mmc, data->mrq); writel(0, host->base + DAVINCI_MMCIM); + host->active_request = false; } else mmc_davinci_start_command(host, data->stop); } @@ -942,6 +968,7 @@ static void mmc_davinci_cmd_done(struct mmc_davinci_host *host, cmd->mrq->cmd->retries = 0; mmc_request_done(host->mmc, cmd->mrq); writel(0, host->base + DAVINCI_MMCIM); + host->active_request = false; } } -- 1.7.7.5 From nsekhar at ti.com Tue Jan 24 05:09:06 2012 From: nsekhar at ti.com (Nori, Sekhar) Date: Tue, 24 Jan 2012 11:09:06 +0000 Subject: [RFC] ARM: davinci: Fix boards' phy ids In-Reply-To: <1327402956-626-1-git-send-email-ido@wizery.com> References: <1327402956-626-1-git-send-email-ido@wizery.com> Message-ID: Hi Ido, On Tue, Jan 24, 2012 at 16:32:36, Ido Yariv wrote: > Commit 5a05a820 "davinci_emac: use an unique MDIO bus name" modified the > mdio bus id to be unique by adding a 'davinci_mdio-' prefix to it. > > The phy ids need to be modified accordingly in order to connect the > ethernet device to the phy device. > > Fix this by modifying the phy ids in all davinci board files. > > Signed-off-by: Ido Yariv > CC: Florian Fainelli A patch for this issue was submitted on Friday last week. http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2012-January/023797.html I will queue that for v3.3-rc soon. Was waiting to see if there are any comments/acks. Thanks, Sekhar From sshtylyov at mvista.com Tue Jan 24 05:10:12 2012 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Tue, 24 Jan 2012 15:10:12 +0400 Subject: [RFC 1/2] mmc: davinci: Eliminate spurious interrupts In-Reply-To: <1327403103-690-1-git-send-email-ido@wizery.com> References: <1327403103-690-1-git-send-email-ido@wizery.com> Message-ID: <4F1E9194.90608@mvista.com> Hello. On 24-01-2012 15:05, Ido Yariv wrote: > The davinci mmc interrupt handler fills the fifo, as long as the DXRDY > or DRRDY bits are set in the status register. > If interrupts fire during this loop, they will be handled by the > handler, but the interrupt controller will still buffer these. As a > result, the handler will be called again to serve these needlessly. In > order to avoid these spurious interrupts, keep interrupts masked while > filling the fifo. > Signed-off-by: Ido Yariv You should send these to linux-mmc at vger.kernel.org and Chris Ball, MMC maintainer. WBR, Sergei From ido at wizery.com Tue Jan 24 05:16:05 2012 From: ido at wizery.com (Ido Yariv) Date: Tue, 24 Jan 2012 13:16:05 +0200 Subject: [RFC 1/2] mmc: davinci: Eliminate spurious interrupts In-Reply-To: <4F1E9194.90608@mvista.com> References: <4F1E9194.90608@mvista.com> Message-ID: <1327403766-962-1-git-send-email-ido@wizery.com> The davinci mmc interrupt handler fills the fifo, as long as the DXRDY or DRRDY bits are set in the status register. If interrupts fire during this loop, they will be handled by the handler, but the interrupt controller will still buffer these. As a result, the handler will be called again to serve these needlessly. In order to avoid these spurious interrupts, keep interrupts masked while filling the fifo. Signed-off-by: Ido Yariv --- drivers/mmc/host/davinci_mmc.c | 33 +++++++++++++++++++++++++++------ 1 files changed, 27 insertions(+), 6 deletions(-) diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c index 64a8325..9cea66f 100644 --- a/drivers/mmc/host/davinci_mmc.c +++ b/drivers/mmc/host/davinci_mmc.c @@ -1009,12 +1009,33 @@ static irqreturn_t mmc_davinci_irq(int irq, void *dev_id) * by read. So, it is not unbouned loop even in the case of * non-dma. */ - while (host->bytes_left && (status & (MMCST0_DXRDY | MMCST0_DRRDY))) { - davinci_fifo_data_trans(host, rw_threshold); - status = readl(host->base + DAVINCI_MMCST0); - if (!status) - break; - qstatus |= status; + if (host->bytes_left && (status & (MMCST0_DXRDY | MMCST0_DRRDY))) { + unsigned long im_val; + + /* + * If interrupts fire during the following loop, they will be + * handled by the handler, but the PIC will still buffer these. + * As a result, the handler will be called again to serve these + * needlessly. In order to avoid these spurious interrupts, + * keep interrupts masked during the loop. + */ + im_val = readl(host->base + DAVINCI_MMCIM); + writel(0, host->base + DAVINCI_MMCIM); + + do { + davinci_fifo_data_trans(host, rw_threshold); + status = readl(host->base + DAVINCI_MMCST0); + qstatus |= status; + } while (host->bytes_left && + (status & (MMCST0_DXRDY | MMCST0_DRRDY))); + + /* + * If an interrupt is pending, it is assumed it will fire when + * it is unmasked. This assumption is also taken when the MMCIM + * is first set. Otherwise, writing to MMCIM after reading the + * status is race-prone. + */ + writel(im_val, host->base + DAVINCI_MMCIM); } if (qstatus & MMCST0_DATDNE) { -- 1.7.7.5 From ido at wizery.com Tue Jan 24 05:16:06 2012 From: ido at wizery.com (Ido Yariv) Date: Tue, 24 Jan 2012 13:16:06 +0200 Subject: [RFC 2/2] mmc: davinci: Poll status for small size transfers In-Reply-To: <1327403766-962-1-git-send-email-ido@wizery.com> References: <4F1E9194.90608@mvista.com> <1327403766-962-1-git-send-email-ido@wizery.com> Message-ID: <1327403766-962-2-git-send-email-ido@wizery.com> For small size non-dma sdio transactions, it is sometimes better to poll the mmc host and avoid interrupts altogether. Polling lowers the number of interrupts and context switches. Tests have shown that for small transactions, only a few polling iterations are needed, so this is worth while. Signed-off-by: Ido Yariv --- drivers/mmc/host/davinci_mmc.c | 29 ++++++++++++++++++++++++++++- 1 files changed, 28 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c index 9cea66f..fb1368a 100644 --- a/drivers/mmc/host/davinci_mmc.c +++ b/drivers/mmc/host/davinci_mmc.c @@ -160,6 +160,16 @@ module_param(rw_threshold, uint, S_IRUGO); MODULE_PARM_DESC(rw_threshold, "Read/Write threshold. Default = 32"); +static unsigned poll_threshold = 128; +module_param(poll_threshold, uint, S_IRUGO); +MODULE_PARM_DESC(poll_threshold, + "Polling transaction size threshold. Default = 128"); + +static unsigned poll_loopcount = 32; +module_param(poll_loopcount, uint, S_IRUGO); +MODULE_PARM_DESC(poll_loopcount, + "Maximum polling loop count. Default = 32"); + static unsigned __initdata use_dma = 1; module_param(use_dma, uint, 0); MODULE_PARM_DESC(use_dma, "Whether to use DMA or not. Default = 1"); @@ -193,6 +203,7 @@ struct mmc_davinci_host { bool use_dma; bool do_dma; bool sdio_int; + bool active_request; /* Scatterlist DMA uses one or more parameter RAM entries: * the main one (associated with rxdma or txdma) plus zero or @@ -219,6 +230,7 @@ struct mmc_davinci_host { #endif }; +static irqreturn_t mmc_davinci_irq(int irq, void *dev_id); /* PIO only */ static void mmc_davinci_sg_to_buf(struct mmc_davinci_host *host) @@ -376,7 +388,20 @@ static void mmc_davinci_start_command(struct mmc_davinci_host *host, writel(cmd->arg, host->base + DAVINCI_MMCARGHL); writel(cmd_reg, host->base + DAVINCI_MMCCMD); - writel(im_val, host->base + DAVINCI_MMCIM); + + host->active_request = true; + + if (!host->do_dma && host->bytes_left <= poll_threshold) { + u32 count = poll_loopcount; + + while (host->active_request && count--) { + mmc_davinci_irq(0, host); + cpu_relax(); + } + } + + if (host->active_request) + writel(im_val, host->base + DAVINCI_MMCIM); } /*----------------------------------------------------------------------*/ @@ -915,6 +940,7 @@ mmc_davinci_xfer_done(struct mmc_davinci_host *host, struct mmc_data *data) if (!data->stop || (host->cmd && host->cmd->error)) { mmc_request_done(host->mmc, data->mrq); writel(0, host->base + DAVINCI_MMCIM); + host->active_request = false; } else mmc_davinci_start_command(host, data->stop); } @@ -942,6 +968,7 @@ static void mmc_davinci_cmd_done(struct mmc_davinci_host *host, cmd->mrq->cmd->retries = 0; mmc_request_done(host->mmc, cmd->mrq); writel(0, host->base + DAVINCI_MMCIM); + host->active_request = false; } } -- 1.7.7.5 From nsekhar at ti.com Tue Jan 24 05:16:45 2012 From: nsekhar at ti.com (Nori, Sekhar) Date: Tue, 24 Jan 2012 11:16:45 +0000 Subject: [RFC] ARM: davinci: Fix boards' phy ids In-Reply-To: <4F1E903F.1090708@openwrt.org> References: <1327402956-626-1-git-send-email-ido@wizery.com> <4F1E903F.1090708@openwrt.org> Message-ID: Hi Florian, On Tue, Jan 24, 2012 at 16:34:31, Florian Fainelli wrote: > Hello Ido, > > On 01/24/12 12:02, Ido Yariv wrote: > > Commit 5a05a820 "davinci_emac: use an unique MDIO bus name" modified the > > mdio bus id to be unique by adding a 'davinci_mdio-' prefix to it. > > > > The phy ids need to be modified accordingly in order to connect the > > ethernet device to the phy device. > > > > Fix this by modifying the phy ids in all davinci board files. > > I completely overlooked that part, thanks for fixing this. > > Acked-by: Florian Fainelli Thanks for the ack, but the patch I am planning to queue is the one I submitted on Friday. Can you please take a look and ack that one? The patch is called "ARM: davinci: update mdio bus name". You are CCed on it. Thanks, Sekhar From florian at openwrt.org Tue Jan 24 05:04:31 2012 From: florian at openwrt.org (Florian Fainelli) Date: Tue, 24 Jan 2012 12:04:31 +0100 Subject: [RFC] ARM: davinci: Fix boards' phy ids In-Reply-To: <1327402956-626-1-git-send-email-ido@wizery.com> References: <1327402956-626-1-git-send-email-ido@wizery.com> Message-ID: <4F1E903F.1090708@openwrt.org> Hello Ido, On 01/24/12 12:02, Ido Yariv wrote: > Commit 5a05a820 "davinci_emac: use an unique MDIO bus name" modified the > mdio bus id to be unique by adding a 'davinci_mdio-' prefix to it. > > The phy ids need to be modified accordingly in order to connect the > ethernet device to the phy device. > > Fix this by modifying the phy ids in all davinci board files. I completely overlooked that part, thanks for fixing this. Acked-by: Florian Fainelli > > Signed-off-by: Ido Yariv > CC: Florian Fainelli > --- > This patch was only tested on an AM18 (DA850) board. > > arch/arm/mach-davinci/board-da850-evm.c | 2 +- > arch/arm/mach-davinci/board-dm365-evm.c | 2 +- > arch/arm/mach-davinci/board-dm644x-evm.c | 2 +- > arch/arm/mach-davinci/board-dm646x-evm.c | 2 +- > arch/arm/mach-davinci/board-neuros-osd2.c | 2 +- > arch/arm/mach-davinci/board-omapl138-hawk.c | 2 +- > arch/arm/mach-davinci/board-sffsdr.c | 2 +- > 7 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c > index 6b22b54..d508890 100644 > --- a/arch/arm/mach-davinci/board-da850-evm.c > +++ b/arch/arm/mach-davinci/board-da850-evm.c > @@ -44,7 +44,7 @@ > #include > #include > > -#define DA850_EVM_PHY_ID "0:00" > +#define DA850_EVM_PHY_ID "davinci_mdio-0:00" > #define DA850_LCD_PWR_PIN GPIO_TO_PIN(2, 8) > #define DA850_LCD_BL_PIN GPIO_TO_PIN(2, 15) > > diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c > index 346e1de..849311d 100644 > --- a/arch/arm/mach-davinci/board-dm365-evm.c > +++ b/arch/arm/mach-davinci/board-dm365-evm.c > @@ -54,7 +54,7 @@ static inline int have_tvp7002(void) > return 0; > } > > -#define DM365_EVM_PHY_ID "0:01" > +#define DM365_EVM_PHY_ID "davinci_mdio-0:01" > /* > * A MAX-II CPLD is used for various board control functions. > */ > diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c > index a64b49c..1247ecd 100644 > --- a/arch/arm/mach-davinci/board-dm644x-evm.c > +++ b/arch/arm/mach-davinci/board-dm644x-evm.c > @@ -40,7 +40,7 @@ > #include > #include > > -#define DM644X_EVM_PHY_ID "0:01" > +#define DM644X_EVM_PHY_ID "davinci_mdio-0:01" > #define LXT971_PHY_ID (0x001378e2) > #define LXT971_PHY_MASK (0xfffffff0) > > diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c > index 6401755..872ac69 100644 > --- a/arch/arm/mach-davinci/board-dm646x-evm.c > +++ b/arch/arm/mach-davinci/board-dm646x-evm.c > @@ -736,7 +736,7 @@ static struct davinci_uart_config uart_config __initdata = { > .enabled_uarts = (1<< 0), > }; > > -#define DM646X_EVM_PHY_ID "0:01" > +#define DM646X_EVM_PHY_ID "davinci_mdio-0:01" > /* > * The following EDMA channels/slots are not being used by drivers (for > * example: Timer, GPIO, UART events etc) on dm646x, hence they are being > diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c > index 6c4a164..8d34f51 100644 > --- a/arch/arm/mach-davinci/board-neuros-osd2.c > +++ b/arch/arm/mach-davinci/board-neuros-osd2.c > @@ -39,7 +39,7 @@ > #include > #include > > -#define NEUROS_OSD2_PHY_ID "0:01" > +#define NEUROS_OSD2_PHY_ID "davinci_mdio-0:01" > #define LXT971_PHY_ID 0x001378e2 > #define LXT971_PHY_MASK 0xfffffff0 > > diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c > index e7c0c7c..45e8157 100644 > --- a/arch/arm/mach-davinci/board-omapl138-hawk.c > +++ b/arch/arm/mach-davinci/board-omapl138-hawk.c > @@ -21,7 +21,7 @@ > #include > #include > > -#define HAWKBOARD_PHY_ID "0:07" > +#define HAWKBOARD_PHY_ID "davinci_mdio-0:07" > #define DA850_HAWK_MMCSD_CD_PIN GPIO_TO_PIN(3, 12) > #define DA850_HAWK_MMCSD_WP_PIN GPIO_TO_PIN(3, 13) > > diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c > index 0b136a8..31da3c5 100644 > --- a/arch/arm/mach-davinci/board-sffsdr.c > +++ b/arch/arm/mach-davinci/board-sffsdr.c > @@ -42,7 +42,7 @@ > #include > #include > > -#define SFFSDR_PHY_ID "0:01" > +#define SFFSDR_PHY_ID "davinci_mdio-0:01" > static struct mtd_partition davinci_sffsdr_nandflash_partition[] = { > /* U-Boot Environment: Block 0 > * UBL: Block 1 From linux at arm.linux.org.uk Tue Jan 24 05:27:45 2012 From: linux at arm.linux.org.uk (Russell King - ARM Linux) Date: Tue, 24 Jan 2012 11:27:45 +0000 Subject: ARM/ARM-SoC plans for v3.4 merge window In-Reply-To: <20120124105645.GE19798@mudshark.cambridge.arm.com> References: <20120123114902.GY1068@n2100.arm.linux.org.uk> <20120124095009.GS16726@n2100.arm.linux.org.uk> <20120124105645.GE19798@mudshark.cambridge.arm.com> Message-ID: <20120124112745.GT16726@n2100.arm.linux.org.uk> On Tue, Jan 24, 2012 at 10:56:45AM +0000, Will Deacon wrote: > Hi Russell, > > On Tue, Jan 24, 2012 at 09:50:09AM +0000, Russell King - ARM Linux wrote: > > Right, although it's out there - but I'd like to get the AMBA changes > > into it which are already conflicting the Samsung development. So I'm > > going to hold off officially asking for people to include the baseline > > until this evening. At that point, I will shut down my 'amba' branch > > and transfer that over; that means I won't be accepting any further > > acks etc for that work. > > > > If you haven't acked changes in the amba branch (eg, to Versatile, > > Realview etc) then it'll soon be too late... > > I took a look at your amba branch, but all I can see in there is: > > 6cfa627 ARM: 7079/1: spi: Fix builderror in spi-pl022.c > 1c3be36 PM: add runtime PM support to MMCI > 92b97f0 PM: add runtime PM support to core Primecell driver > > which don't seem to touch Versatile or Realview. Am I looking in the wrong > place? Erm, I don't think you're looking at the right branch - especially as all the commits start "ARM: amba:". They were sent out to the mailing list on 20th Jan as a set of 31 patches (latest first): ARM: amba: samsung: use common amba device initializers ARM: amba: spear: use common amba device initializers ARM: amba: nomadik: use common amba device initializers ARM: amba: u300: use common amba device initializers ARM: amba: lpc32xx: use common amba device initializers ARM: amba: netx: use common amba device initializers ARM: amba: bcmring: use common amba device initializers ARM: amba: ep93xx: use common amba device initializers ARM: amba: omap2: use common amba device initializers ARM: amba: integrator: use common amba device initializers ARM: amba: realview: get rid of private platform amba_device initializer ARM: amba: versatile: get rid of private platform amba_device initializer ARM: amba: vexpress: get rid of private platform amba_device initializer ARM: amba: provide common initializers for static amba devices ARM: amba: make use of -1 IRQs warn ARM: amba: u300: get rid of NO_IRQ initializers ARM: amba: spear: get rid of NO_IRQ initializers ARM: amba: netx: get rid of NO_IRQ initializers ARM: amba: nomadik: get rid of NO_IRQ initializers ARM: amba: mxs: get rid of NO_IRQ initializers ARM: amba: lpc32xx: get rid of NO_IRQ initializers ARM: amba: integrator/realview/versatile/vexpress: get rid of NO_IRQ initializers ARM: amba: samsung: get rid of NO_IRQ initializers ARM: amba: get rid of NO_IRQ initializers ARM: amba: ux500: get rid of NO_IRQ ARM: amba: make irq 0 invalid ARM: amba: mxs: convert to use amba_device_alloc ARM: amba: integrator: convert to use amba_device_alloc ARM: amba: ux500: convert to use amba_device_alloc ARM: amba: of: convert to use amba_device_alloc ARM: amba: add amba_device allocation/add/put functions From will.deacon at arm.com Tue Jan 24 05:45:43 2012 From: will.deacon at arm.com (Will Deacon) Date: Tue, 24 Jan 2012 11:45:43 +0000 Subject: ARM/ARM-SoC plans for v3.4 merge window In-Reply-To: <20120124112745.GT16726@n2100.arm.linux.org.uk> References: <20120123114902.GY1068@n2100.arm.linux.org.uk> <20120124095009.GS16726@n2100.arm.linux.org.uk> <20120124105645.GE19798@mudshark.cambridge.arm.com> <20120124112745.GT16726@n2100.arm.linux.org.uk> Message-ID: <20120124114543.GG19798@mudshark.cambridge.arm.com> On Tue, Jan 24, 2012 at 11:27:45AM +0000, Russell King - ARM Linux wrote: > On Tue, Jan 24, 2012 at 10:56:45AM +0000, Will Deacon wrote: > > I took a look at your amba branch, but all I can see in there is: > > > > 6cfa627 ARM: 7079/1: spi: Fix builderror in spi-pl022.c > > 1c3be36 PM: add runtime PM support to MMCI > > 92b97f0 PM: add runtime PM support to core Primecell driver > > > > which don't seem to touch Versatile or Realview. Am I looking in the wrong > > place? > > Erm, I don't think you're looking at the right branch - especially as > all the commits start "ARM: amba:". They were sent out to the mailing > list on 20th Jan as a set of 31 patches (latest first): [...] Indeed, the amba branch I was looking at no longer exists on your server and a git prune removed it. I'll take a look at the guys in devel-3.3 instead. Thanks, Will From scottwood at freescale.com Tue Jan 24 13:45:02 2012 From: scottwood at freescale.com (Scott Wood) Date: Tue, 24 Jan 2012 13:45:02 -0600 Subject: [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller In-Reply-To: <4F1E5C82.60108@denx.de> References: <1327308967-8092-1-git-send-email-hs@denx.de> <1327308967-8092-7-git-send-email-hs@denx.de> <4F1DF465.60206@freescale.com> <4F1E5C82.60108@denx.de> Message-ID: <4F1F0A3E.40805@freescale.com> On 01/24/2012 01:23 AM, Heiko Schocher wrote: > Hello Scott, > > Scott Wood wrote: >> On 01/23/2012 02:56 AM, Heiko Schocher wrote: >>> diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt b/Documentation/devicetree/bindings/arm/davinci/nand.txt >>> new file mode 100644 >>> index 0000000..7e8d6db >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/arm/davinci/nand.txt >>> @@ -0,0 +1,72 @@ >>> +* Texas Instruments Davinci NAND >>> + >>> +This file provides information, what the device node for the >>> +davinci nand interface contain. >>> + >>> +Required properties: >>> +- compatible: "ti,davinci-nand"; >>> +- reg : contain 2 offset/length values: >>> + - offset and length for the access window >>> + - offset and length for accessing the aemif control registers >>> +- id: id of the controller >> >> What does "id of the controller" mean, specfically? From this I can't >> even tell if it's a number or a string, much less how to use it >> semantically. If it's just a "match what's in the manual" thing, >> perhaps an alias would be better here. Or, if it's a value with a >> specific meaning (e.g. that you need to program into a register) use a >> more specific name. > > Ok, fix this. Id means here, which chipselect the controller uses. > Maybe it is better to rename it to "chipselect" ? Yes, or better "ti,chipselect" or "ti,davinci-chipselect". >>> +Recommended properties : >>> +- mask_ale: mask for ale >>> +- mask_cle: mask for cle >>> +- mask_chipsel: mask for chipselect >>> +- ecc_mode: ECC mode, see NAND_ECC_* defines >>> +- ecc_bits: used ECC bits >>> +- options: nand options, defined in >>> + include/linux/mtd/nand.h, grep for NAND_NO_AUTOINCR >>> +- bbt_options: NAND_BBT_* defines >> >> Binding-specific properties should have a vendor prefix. Dashes are >> preferred to underscores. > > You think something like that: > > davinci-mask-ale > davinci-mask-cle > ... "ti,davinci-mask-ale", etc. >> Don't specify Linux internals by reference -- they could change and >> invalidate existing device trees and non-Linux code that accepts them >> (e.g. U-Boot). If you want them to line up, copy the definition here, >> and if Linux changes, write glue code to convert. It would probably be >> better to define specific properties for anything that must be specified >> here (neither deteted dynamically nor defined by compatible = >> "ti,davinci-nand"). > > Ok, I add the defines here, and add also a comment in the dts. Which options actually need to come from the device tree? >> Do all of these properties really belong here? I can see providing some > > I think so, because this values come from existing platform code > (grep for struct davinci_nand_pdata) The standards are a bit stricter for the device tree, since it's a more stable interface across components -- at least that's how we've used it on a lot of powerpc targets. I'm not sure if that's the intent here, but I have seen U-Boot patches for ARM hardware using them as well. > Comment in arch/arm/mach-davinci/include/mach/nand.h says for > mask_ale and mask_cle: > > /* NOTE: boards don't need to use these address bits > * for ALE/CLE unless they support booting from NAND. > * They're used unless platform data overrides them. > */ > > It is used for addressing the ALE/CLE Signals through the address, > used on the arch/arm/mach-davinci/board-dm646x-evm.c and > arch/arm/mach-davinci/board-tnetv107x-evm.c board ... so I think, > this should be also be setupable through OF ... OK, if it's board logic that does the decoding, and the compatible is not board-specific, they belong here. -Scott From Wee-chang.Liew at leica-microsystems.com Tue Jan 24 14:01:55 2012 From: Wee-chang.Liew at leica-microsystems.com (Wee-chang.Liew at leica-microsystems.com) Date: Wed, 25 Jan 2012 04:01:55 +0800 Subject: AUTO: Wee-chang Liew is out of the office. Message-ID: I am out of the office until 01/30/2012. I will respond to your message when I return. Note: This is an automated response to your message "Davinci-linux-open-source Digest, Vol 73, Issue 29" sent on 1/25/2012 2:00:01 AM. This is the only notification you will receive while this person is away. _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk From maxdw.ml at gmail.com Tue Jan 24 15:02:59 2012 From: maxdw.ml at gmail.com (Nam Nequam) Date: Tue, 24 Jan 2012 23:02:59 +0200 Subject: platform driver (musb/davinci.ko) and resource.c Message-ID: Hello, In the recent kernel versions usb/musb/davinci has been promoted to a module (platform driver) instead of being part of musb_hdrc. There is a little bug if davinci.ko is compiled as loadable module. davinci.ko can be inserted (modprobe) once only. After removal, it cannot be inserted again, due to "musb_hdrc: failed to claim resource 0" error in platform.c:platform_device_add() or crash. It happens because upon davinci.ko:davinci_probe(), resource.c:__insert_resource() modifies the global mach-davinci/usb.c:usb_dev.resource variable. After davinci.ko removal, the global usb.c:usb_dev.resource.parent points to freed memory. So, at the next modprobe davinci.ko, if, luckily, davinci.ko allocates memory platfrom_device_add_resources():kmemdup at the same location, it gives the above error ("claim resource"), otherwise - crash (since resource->parent pointer is not valid) It may be a common problem for platform devices that use global resource array, and their loadable platform drivers. BTW: Why does resource.c build a tree from overlapping resources at multiple insertions, and then silently drops the whole sub-tree upon removal of the current root. Where the root is just the most recently added resource. Here is the exact sequence: 1. Upon boot /mach-davinci/usb:davinci_setup_usb registers a usb_dev 1.1 platform.c:platform_device_add inserts a usb_dev.resource[0] (defaulting its parent to iomem_resource) 1.2 resource.c:__insert_resource places usb_dev.resource[0] under iomem_resource 2. Upon modprobe davinci.ko: 2.1 davinci.c:davinci_probe kmemdup(platform_device_add_resources) the resource from usb_dev.resource[0] (where sb_dev.resource[0].parent == iomem_resource from 1.1) 2.2 davinci.c:davinci_probe calls platform.c:platform_device_add, which calls resource.c:insert_resource 2.3 resource.c:__insert_resource: 2.3.1 finds a registered (at 1.2) usb_dev.resource[0] 2.3.2 replaces it by musb->resource[0] and makes usb_dev.resource[0] child of musb->resource[0] 2.3.3 so, now, the global usb_dev.resource[0].parent == musb->resource[0] (usb_dev.resource[0].parent->musb->resource[0].parent->iomem_resource) 3. Upon rmmod davinci.ko 2.1 resource.c:release_resource drops both musb->resource[0] and usb_dev.resource[0] (usb_dev.resource[0].parent->musb->resource[0].parent) 2.2 davinci.c:davinci_removes platform device 2.3 the global usb_dev.resource[0].parent now points to kfreed parent->musb->resource[0] 4. Upon the second modprobe davinci.ko: resource.c:__insert_resource 4.1 davinci.c:davinci_probe kmemdup(platform_device_add_resources) the resource from usb_dev.resource[0] (where usb_dev.resource[0].parent == deleted musb->resource[0] from 2.3.3) 4.2 if kmemdup allocated musb->resource[0] at the same place: __insert_resource will reject it, because its parent points to itself (the same memory location from the previous reincarantion), otherwise __insert_resource will crash trying to insert musb->resource[0] under [usb_dev/musb].parent which points to invalid memory location (released at 2.2) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hs at denx.de Wed Jan 25 01:09:34 2012 From: hs at denx.de (Heiko Schocher) Date: Wed, 25 Jan 2012 08:09:34 +0100 Subject: [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller In-Reply-To: <4F1F0A3E.40805@freescale.com> References: <1327308967-8092-1-git-send-email-hs@denx.de> <1327308967-8092-7-git-send-email-hs@denx.de> <4F1DF465.60206@freescale.com> <4F1E5C82.60108@denx.de> <4F1F0A3E.40805@freescale.com> Message-ID: <4F1FAAAE.2060007@denx.de> Hello Scott, Scott Wood wrote: > On 01/24/2012 01:23 AM, Heiko Schocher wrote: >> Hello Scott, >> >> Scott Wood wrote: >>> On 01/23/2012 02:56 AM, Heiko Schocher wrote: >>>> diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt b/Documentation/devicetree/bindings/arm/davinci/nand.txt >>>> new file mode 100644 >>>> index 0000000..7e8d6db >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/arm/davinci/nand.txt >>>> @@ -0,0 +1,72 @@ >>>> +* Texas Instruments Davinci NAND >>>> + >>>> +This file provides information, what the device node for the >>>> +davinci nand interface contain. >>>> + >>>> +Required properties: >>>> +- compatible: "ti,davinci-nand"; >>>> +- reg : contain 2 offset/length values: >>>> + - offset and length for the access window >>>> + - offset and length for accessing the aemif control registers >>>> +- id: id of the controller >>> What does "id of the controller" mean, specfically? From this I can't >>> even tell if it's a number or a string, much less how to use it >>> semantically. If it's just a "match what's in the manual" thing, >>> perhaps an alias would be better here. Or, if it's a value with a >>> specific meaning (e.g. that you need to program into a register) use a >>> more specific name. >> Ok, fix this. Id means here, which chipselect the controller uses. >> Maybe it is better to rename it to "chipselect" ? > > Yes, or better "ti,chipselect" or "ti,davinci-chipselect". Ok. fixed this to "ti,davinci-chipselect" >>>> +Recommended properties : >>>> +- mask_ale: mask for ale >>>> +- mask_cle: mask for cle >>>> +- mask_chipsel: mask for chipselect >>>> +- ecc_mode: ECC mode, see NAND_ECC_* defines >>>> +- ecc_bits: used ECC bits >>>> +- options: nand options, defined in >>>> + include/linux/mtd/nand.h, grep for NAND_NO_AUTOINCR >>>> +- bbt_options: NAND_BBT_* defines >>> Binding-specific properties should have a vendor prefix. Dashes are >>> preferred to underscores. >> You think something like that: >> >> davinci-mask-ale >> davinci-mask-cle >> ... > > "ti,davinci-mask-ale", etc. Ok, fixed. >>> Don't specify Linux internals by reference -- they could change and >>> invalidate existing device trees and non-Linux code that accepts them >>> (e.g. U-Boot). If you want them to line up, copy the definition here, >>> and if Linux changes, write glue code to convert. It would probably be >>> better to define specific properties for anything that must be specified >>> here (neither deteted dynamically nor defined by compatible = >>> "ti,davinci-nand"). >> Ok, I add the defines here, and add also a comment in the dts. > > Which options actually need to come from the device tree? I found the following used options: ecc_mode: NAND_ECC_NONE NAND_ECC_SOFT NAND_ECC_HW NAND_ECC_HW_SYNDROME bbt_options: NAND_BBT_USE_FLASH ecc_bits: 1 4 options: NAND_BUSWIDTH_16 >>> Do all of these properties really belong here? I can see providing some >> I think so, because this values come from existing platform code >> (grep for struct davinci_nand_pdata) > > The standards are a bit stricter for the device tree, since it's a more > stable interface across components -- at least that's how we've used it > on a lot of powerpc targets. I'm not sure if that's the intent here, > but I have seen U-Boot patches for ARM hardware using them as well. Ok, so, should I introduce instead properties for the above needed parameters? (As this are not davinci specific parameters, are there somewhere such definitions for them?) >> Comment in arch/arm/mach-davinci/include/mach/nand.h says for >> mask_ale and mask_cle: >> >> /* NOTE: boards don't need to use these address bits >> * for ALE/CLE unless they support booting from NAND. >> * They're used unless platform data overrides them. >> */ >> >> It is used for addressing the ALE/CLE Signals through the address, >> used on the arch/arm/mach-davinci/board-dm646x-evm.c and >> arch/arm/mach-davinci/board-tnetv107x-evm.c board ... so I think, >> this should be also be setupable through OF ... > > OK, if it's board logic that does the decoding, and the compatible is > not board-specific, they belong here. Ok. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany From sshtylyov at mvista.com Wed Jan 25 04:29:40 2012 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Wed, 25 Jan 2012 14:29:40 +0400 Subject: Fwd: platform driver (musb/davinci.ko) and resource.c In-Reply-To: References: Message-ID: <4F1FD994.3080203@mvista.com> Hello. I'm forwarding this mail to linux-usb and the MUSB maintainer. WBR, Sergei -------- Original Message -------- Subject: platform driver (musb/davinci.ko) and resource.c Date: Tue, 24 Jan 2012 23:02:59 +0200 From: Nam Nequam To: davinci-linux-open-source at linux.davincidsp.com Hello, In the recent kernel versions usb/musb/davinci has been promoted to a module (platform driver) instead of being part of musb_hdrc. There is a little bug if davinci.ko is compiled as loadable module. davinci.ko can be inserted (modprobe) once only. After removal, it cannot be inserted again, due to "musb_hdrc: failed to claim resource 0" error in platform.c:platform_device_add() or crash. It happens because upon davinci.ko:davinci_probe(), resource.c:__insert_resource() modifies the global mach-davinci/usb.c:usb_dev.resource variable. After davinci.ko removal, the global usb.c:usb_dev.resource.parent points to freed memory. So, at the next modprobe davinci.ko, if, luckily, davinci.ko allocates memory platfrom_device_add_resources():kmemdup at the same location, it gives the above error ("claim resource"), otherwise - crash (since resource->parent pointer is not valid) It may be a common problem for platform devices that use global resource array, and their loadable platform drivers. BTW: Why does resource.c build a tree from overlapping resources at multiple insertions, and then silently drops the whole sub-tree upon removal of the current root. Where the root is just the most recently added resource. Here is the exact sequence: 1. Upon boot /mach-davinci/usb:davinci_setup_usb registers a usb_dev 1.1 platform.c:platform_device_add inserts a usb_dev.resource[0] (defaulting its parent to iomem_resource) 1.2 resource.c:__insert_resource places usb_dev.resource[0] under iomem_resource 2. Upon modprobe davinci.ko: 2.1 davinci.c:davinci_probe kmemdup(platform_device_add_resources) the resource from usb_dev.resource[0] (where sb_dev.resource[0].parent == iomem_resource from 1.1) 2.2 davinci.c:davinci_probe calls platform.c:platform_device_add, which calls resource.c:insert_resource 2.3 resource.c:__insert_resource: 2.3.1 finds a registered (at 1.2) usb_dev.resource[0] 2.3.2 replaces it by musb->resource[0] and makes usb_dev.resource[0] child of musb->resource[0] 2.3.3 so, now, the global usb_dev.resource[0].parent == musb->resource[0] (usb_dev.resource[0].parent->musb->resource[0].parent->iomem_resource) 3. Upon rmmod davinci.ko 2.1 resource.c:release_resource drops both musb->resource[0] and usb_dev.resource[0] (usb_dev.resource[0].parent->musb->resource[0].parent) 2.2 davinci.c:davinci_removes platform device 2.3 the global usb_dev.resource[0].parent now points to kfreed parent->musb->resource[0] 4. Upon the second modprobe davinci.ko: resource.c:__insert_resource 4.1 davinci.c:davinci_probe kmemdup(platform_device_add_resources) the resource from usb_dev.resource[0] (where usb_dev.resource[0].parent == deleted musb->resource[0] from 2.3.3) 4.2 if kmemdup allocated musb->resource[0] at the same place: __insert_resource will reject it, because its parent points to itself (the same memory location from the previous reincarantion), otherwise __insert_resource will crash trying to insert musb->resource[0] under [usb_dev/musb].parent which points to invalid memory location (released at 2.2) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Attached Message Part URL: From prakash.pm at ti.com Wed Jan 25 04:25:54 2012 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Wed, 25 Jan 2012 15:55:54 +0530 Subject: [PATCH v2 1/3] arm:davinci: prepare to move aemif driver to drivers/mfd Message-ID: <1327487156-10238-1-git-send-email-prakash.pm@ti.com> Patch moves emif header file appropriately as a part preparation to move emif driver from arch/arm/mach-davinci/ to drivers/mfd folder. There by it isolates modifications in emif interface depicting as platform code change. Patch series are based on the discussion and concerns expressed in davinci-linux-open-source community. Here is the link for the same: http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-arm-davinci-configure-davinci-aemif-chipselects-through-OF-tt7059739.html#none Signed-off-by: Manjunathappa, Prakash --- Since v1: Patch is generated using -M option. arch/arm/mach-davinci/aemif.c | 2 +- arch/arm/mach-davinci/board-da830-evm.c | 2 +- arch/arm/mach-davinci/board-da850-evm.c | 2 +- drivers/mtd/nand/davinci_nand.c | 2 +- .../aemif.h => include/linux/mfd/davinci_aemif.h | 0 5 files changed, 4 insertions(+), 4 deletions(-) rename arch/arm/mach-davinci/include/mach/aemif.h => include/linux/mfd/davinci_aemif.h (100%) diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c index 1ce70a9..b67c115 100644 --- a/arch/arm/mach-davinci/aemif.c +++ b/arch/arm/mach-davinci/aemif.c @@ -15,7 +15,7 @@ #include #include -#include +#include /* Timing value configuration */ diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c index dc1afe5..0b43554 100644 --- a/arch/arm/mach-davinci/board-da830-evm.c +++ b/arch/arm/mach-davinci/board-da830-evm.c @@ -31,7 +31,7 @@ #include #include #include -#include +#include #include #define DA830_EVM_PHY_ID "" diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c index 6b22b54..6dda013 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c @@ -41,7 +41,7 @@ #include #include #include -#include +#include #include #define DA850_EVM_PHY_ID "0:00" diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c index 6e56615..f19151b 100644 --- a/drivers/mtd/nand/davinci_nand.c +++ b/drivers/mtd/nand/davinci_nand.c @@ -35,7 +35,7 @@ #include #include -#include +#include /* * This is a device driver for the NAND flash controller found on the diff --git a/arch/arm/mach-davinci/include/mach/aemif.h b/include/linux/mfd/davinci_aemif.h similarity index 100% rename from arch/arm/mach-davinci/include/mach/aemif.h rename to include/linux/mfd/davinci_aemif.h -- 1.7.1 From prakash.pm at ti.com Wed Jan 25 04:25:55 2012 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Wed, 25 Jan 2012 15:55:55 +0530 Subject: [PATCH v2 2/3] arm:davinci: Move emif driver to drivers/mfd from mach-davinci folder In-Reply-To: <1327487156-10238-1-git-send-email-prakash.pm@ti.com> References: <1327487156-10238-1-git-send-email-prakash.pm@ti.com> Message-ID: <1327487156-10238-2-git-send-email-prakash.pm@ti.com> Move aemif kernel module from arch/arm/amch-davinci/ to multi functional devices frame work. Signed-off-by: Manjunathappa, Prakash --- Since v1: Patch is generated using -M option. arch/arm/Kconfig | 1 + arch/arm/mach-davinci/Makefile | 4 +- arch/arm/mach-davinci/aemif.c | 133 --------------------- drivers/mfd/Makefile | 1 + drivers/mfd/davinci_aemif.c | 238 +++++++++++++++++++++++++++++++++++++ include/linux/mfd/davinci_aemif.h | 14 ++ 6 files changed, 256 insertions(+), 135 deletions(-) delete mode 100644 arch/arm/mach-davinci/aemif.c create mode 100644 drivers/mfd/davinci_aemif.c diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 24626b0..5b717cf 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -936,6 +936,7 @@ config ARCH_DAVINCI select GENERIC_ALLOCATOR select GENERIC_IRQ_CHIP select ARCH_HAS_HOLES_MEMORYMODEL + select MFD_CORE help Support for TI's DaVinci platform. diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile index 2db78bd..e25a459 100644 --- a/arch/arm/mach-davinci/Makefile +++ b/arch/arm/mach-davinci/Makefile @@ -4,8 +4,8 @@ # # Common objects -obj-y := time.o clock.o serial.o psc.o \ - dma.o usb.o common.o sram.o aemif.o +obj-y := time.o clock.o serial.o io.o psc.o \ + dma.o usb.o common.o sram.o obj-$(CONFIG_DAVINCI_MUX) += mux.o diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c deleted file mode 100644 index b67c115..0000000 --- a/arch/arm/mach-davinci/aemif.c +++ /dev/null @@ -1,133 +0,0 @@ -/* - * AEMIF support for DaVinci SoCs - * - * Copyright (C) 2010 Texas Instruments Incorporated. http://www.ti.com/ - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ - -#include -#include -#include -#include -#include -#include - -#include - -/* Timing value configuration */ - -#define TA(x) ((x) << 2) -#define RHOLD(x) ((x) << 4) -#define RSTROBE(x) ((x) << 7) -#define RSETUP(x) ((x) << 13) -#define WHOLD(x) ((x) << 17) -#define WSTROBE(x) ((x) << 20) -#define WSETUP(x) ((x) << 26) - -#define TA_MAX 0x3 -#define RHOLD_MAX 0x7 -#define RSTROBE_MAX 0x3f -#define RSETUP_MAX 0xf -#define WHOLD_MAX 0x7 -#define WSTROBE_MAX 0x3f -#define WSETUP_MAX 0xf - -#define TIMING_MASK (TA(TA_MAX) | \ - RHOLD(RHOLD_MAX) | \ - RSTROBE(RSTROBE_MAX) | \ - RSETUP(RSETUP_MAX) | \ - WHOLD(WHOLD_MAX) | \ - WSTROBE(WSTROBE_MAX) | \ - WSETUP(WSETUP_MAX)) - -/* - * aemif_calc_rate - calculate timing data. - * @wanted: The cycle time needed in nanoseconds. - * @clk: The input clock rate in kHz. - * @max: The maximum divider value that can be programmed. - * - * On success, returns the calculated timing value minus 1 for easy - * programming into AEMIF timing registers, else negative errno. - */ -static int aemif_calc_rate(int wanted, unsigned long clk, int max) -{ - int result; - - result = DIV_ROUND_UP((wanted * clk), NSEC_PER_MSEC) - 1; - - pr_debug("%s: result %d from %ld, %d\n", __func__, result, clk, wanted); - - /* It is generally OK to have a more relaxed timing than requested... */ - if (result < 0) - result = 0; - - /* ... But configuring tighter timings is not an option. */ - else if (result > max) - result = -EINVAL; - - return result; -} - -/** - * davinci_aemif_setup_timing - setup timing values for a given AEMIF interface - * @t: timing values to be progammed - * @base: The virtual base address of the AEMIF interface - * @cs: chip-select to program the timing values for - * - * This function programs the given timing values (in real clock) into the - * AEMIF registers taking the AEMIF clock into account. - * - * This function does not use any locking while programming the AEMIF - * because it is expected that there is only one user of a given - * chip-select. - * - * Returns 0 on success, else negative errno. - */ -int davinci_aemif_setup_timing(struct davinci_aemif_timing *t, - void __iomem *base, unsigned cs) -{ - unsigned set, val; - int ta, rhold, rstrobe, rsetup, whold, wstrobe, wsetup; - unsigned offset = A1CR_OFFSET + cs * 4; - struct clk *aemif_clk; - unsigned long clkrate; - - if (!t) - return 0; /* Nothing to do */ - - aemif_clk = clk_get(NULL, "aemif"); - if (IS_ERR(aemif_clk)) - return PTR_ERR(aemif_clk); - - clkrate = clk_get_rate(aemif_clk); - - clkrate /= 1000; /* turn clock into kHz for ease of use */ - - ta = aemif_calc_rate(t->ta, clkrate, TA_MAX); - rhold = aemif_calc_rate(t->rhold, clkrate, RHOLD_MAX); - rstrobe = aemif_calc_rate(t->rstrobe, clkrate, RSTROBE_MAX); - rsetup = aemif_calc_rate(t->rsetup, clkrate, RSETUP_MAX); - whold = aemif_calc_rate(t->whold, clkrate, WHOLD_MAX); - wstrobe = aemif_calc_rate(t->wstrobe, clkrate, WSTROBE_MAX); - wsetup = aemif_calc_rate(t->wsetup, clkrate, WSETUP_MAX); - - if (ta < 0 || rhold < 0 || rstrobe < 0 || rsetup < 0 || - whold < 0 || wstrobe < 0 || wsetup < 0) { - pr_err("%s: cannot get suitable timings\n", __func__); - return -EINVAL; - } - - set = TA(ta) | RHOLD(rhold) | RSTROBE(rstrobe) | RSETUP(rsetup) | - WHOLD(whold) | WSTROBE(wstrobe) | WSETUP(wsetup); - - val = __raw_readl(base + offset); - val &= ~TIMING_MASK; - val |= set; - __raw_writel(val, base + offset); - - return 0; -} -EXPORT_SYMBOL(davinci_aemif_setup_timing); diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index b953bab..54fc267 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -11,6 +11,7 @@ obj-$(CONFIG_HTC_EGPIO) += htc-egpio.o obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o +obj-${CONFIG_ARCH_DAVINCI} += davinci_aemif.o obj-$(CONFIG_MFD_DAVINCI_VOICECODEC) += davinci_voicecodec.o obj-$(CONFIG_MFD_DM355EVM_MSP) += dm355evm_msp.o obj-$(CONFIG_MFD_TI_SSP) += ti-ssp.o diff --git a/drivers/mfd/davinci_aemif.c b/drivers/mfd/davinci_aemif.c new file mode 100644 index 0000000..ab3292c --- /dev/null +++ b/drivers/mfd/davinci_aemif.c @@ -0,0 +1,238 @@ +/* + * AEMIF support for DaVinci SoCs + * + * Copyright (C) 2010 Texas Instruments Incorporated. http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static struct mfd_cell davinci_emifs[] = { + { + .name = "davinci_nand", + }, + { + .name = "physmap-flash", + }, +}; + +/* Timing value configuration */ + +#define TA(x) ((x) << 2) +#define RHOLD(x) ((x) << 4) +#define RSTROBE(x) ((x) << 7) +#define RSETUP(x) ((x) << 13) +#define WHOLD(x) ((x) << 17) +#define WSTROBE(x) ((x) << 20) +#define WSETUP(x) ((x) << 26) + +#define TA_MAX 0x3 +#define RHOLD_MAX 0x7 +#define RSTROBE_MAX 0x3f +#define RSETUP_MAX 0xf +#define WHOLD_MAX 0x7 +#define WSTROBE_MAX 0x3f +#define WSETUP_MAX 0xf + +#define TIMING_MASK (TA(TA_MAX) | \ + RHOLD(RHOLD_MAX) | \ + RSTROBE(RSTROBE_MAX) | \ + RSETUP(RSETUP_MAX) | \ + WHOLD(WHOLD_MAX) | \ + WSTROBE(WSTROBE_MAX) | \ + WSETUP(WSETUP_MAX)) + +/* + * aemif_calc_rate - calculate timing data. + * @wanted: The cycle time needed in nanoseconds. + * @clk: The input clock rate in kHz. + * @max: The maximum divider value that can be programmed. + * + * On success, returns the calculated timing value minus 1 for easy + * programming into AEMIF timing registers, else negative errno. + */ +static int aemif_calc_rate(int wanted, unsigned long clk, int max) +{ + int result; + + result = DIV_ROUND_UP((wanted * clk), NSEC_PER_MSEC) - 1; + + pr_debug("%s: result %d from %ld, %d\n", __func__, result, clk, wanted); + + /* It is generally OK to have a more relaxed timing than requested... */ + if (result < 0) + result = 0; + + /* ... But configuring tighter timings is not an option. */ + else if (result > max) + result = -EINVAL; + + return result; +} + +/** + * davinci_aemif_setup_timing - setup timing values for a given AEMIF interface + * @t: timing values to be progammed + * @base: The virtual base address of the AEMIF interface + * @cs: chip-select to program the timing values for + * + * This function programs the given timing values (in real clock) into the + * AEMIF registers taking the AEMIF clock into account. + * + * This function does not use any locking while programming the AEMIF + * because it is expected that there is only one user of a given + * chip-select. + * + * Returns 0 on success, else negative errno. + */ +int davinci_aemif_setup_timing(struct davinci_aemif_timing *t, + void __iomem *base, unsigned cs) +{ + unsigned set, val; + int ta, rhold, rstrobe, rsetup, whold, wstrobe, wsetup; + unsigned offset = A1CR_OFFSET + cs * 4; + struct clk *aemif_clk; + unsigned long clkrate; + + if (!t) + return 0; /* Nothing to do */ + + aemif_clk = clk_get(NULL, "aemif"); + if (IS_ERR(aemif_clk)) + return PTR_ERR(aemif_clk); + + clkrate = clk_get_rate(aemif_clk); + + clkrate /= 1000; /* turn clock into kHz for ease of use */ + + ta = aemif_calc_rate(t->ta, clkrate, TA_MAX); + rhold = aemif_calc_rate(t->rhold, clkrate, RHOLD_MAX); + rstrobe = aemif_calc_rate(t->rstrobe, clkrate, RSTROBE_MAX); + rsetup = aemif_calc_rate(t->rsetup, clkrate, RSETUP_MAX); + whold = aemif_calc_rate(t->whold, clkrate, WHOLD_MAX); + wstrobe = aemif_calc_rate(t->wstrobe, clkrate, WSTROBE_MAX); + wsetup = aemif_calc_rate(t->wsetup, clkrate, WSETUP_MAX); + + if (ta < 0 || rhold < 0 || rstrobe < 0 || rsetup < 0 || + whold < 0 || wstrobe < 0 || wsetup < 0) { + pr_err("%s: cannot get suitable timings\n", __func__); + return -EINVAL; + } + + set = TA(ta) | RHOLD(rhold) | RSTROBE(rstrobe) | RSETUP(rsetup) | + WHOLD(whold) | WSTROBE(wstrobe) | WSETUP(wsetup); + + val = __raw_readl(base + offset); + val &= ~TIMING_MASK; + val |= set; + __raw_writel(val, base + offset); + + return 0; +} +EXPORT_SYMBOL(davinci_aemif_setup_timing); + +static int __init davinci_aemif_probe(struct platform_device *pdev) +{ + struct davinci_aemif_devices *davinci_aemif_devices = + pdev->dev.platform_data; + struct platform_device *devices; + struct mfd_cell *cells; + int i, ret; + + devices = davinci_aemif_devices->devices; + cells = davinci_emifs; + + /* DaVinci NAND device client */ + for (i = 0; i < davinci_aemif_devices->num_devices; i++) { + if (!strcmp(devices[i].name, + cells[DAVINCI_NAND_DEVICE_CELL].name)) + break; + + } + if (i > davinci_aemif_devices->num_devices) { + dev_err(&pdev->dev, "No NAND device found by DaVinci EMIF" + "MFD\n"); + cells[DAVINCI_NAND_DEVICE_CELL].name = NULL; + } else { + cells[DAVINCI_NAND_DEVICE_CELL].platform_data = + devices[i].dev.platform_data; + cells[DAVINCI_NAND_DEVICE_CELL].pdata_size = + sizeof(struct davinci_nand_pdata); + cells[DAVINCI_NAND_DEVICE_CELL].id = devices[i].id; + cells[DAVINCI_NAND_DEVICE_CELL].resources = + devices[i].resource; + cells[DAVINCI_NAND_DEVICE_CELL].num_resources = + devices[i].num_resources; + } + + /* DaVinci NOR device client */ + for (i = 0; i < davinci_aemif_devices->num_devices; i++) { + if (!strcmp(devices[i].name, + cells[DAVINCI_NOR_FLASH_CELL].name)) + break; + } + + if (i > davinci_aemif_devices->num_devices) { + dev_err(&pdev->dev, "No NOR device found by DaVinci EMIF" + "MFD\n"); + cells[DAVINCI_NOR_FLASH_CELL].name = NULL; + } else { + cells[DAVINCI_NOR_FLASH_CELL].platform_data = + devices[i].dev.platform_data; + cells[DAVINCI_NOR_FLASH_CELL].pdata_size = + sizeof(struct physmap_flash_data); + cells[DAVINCI_NOR_FLASH_CELL].id = devices[i].id; + cells[DAVINCI_NOR_FLASH_CELL].resources = devices[i].resource; + cells[DAVINCI_NOR_FLASH_CELL].num_resources = + devices[i].num_resources; + } + + ret = mfd_add_devices(&pdev->dev, pdev->id, cells, + davinci_aemif_devices->num_devices, NULL, 0); + if (ret != 0) + dev_err(&pdev->dev, "fail to register client devices\n"); + + return 0; +} + +static int __devexit davinci_aemif_remove(struct platform_device *pdev) +{ + mfd_remove_devices(&pdev->dev); + return 0; +} + +static struct platform_driver davinci_aemif_driver = { + .driver = { + .name = "davinci_aemif", + .owner = THIS_MODULE, + }, + .remove = __devexit_p(davinci_aemif_remove), +}; + +static int __init davinci_aemif_init(void) +{ + return platform_driver_probe(&davinci_aemif_driver, + davinci_aemif_probe); +} +module_init(davinci_aemif_init); + +static void __exit davinci_aemif_exit(void) +{ + platform_driver_unregister(&davinci_aemif_driver); +} +module_exit(davinci_aemif_exit); + +MODULE_AUTHOR("Prakash Manjunathappa"); +MODULE_DESCRIPTION("Texas Instruments AEMIF Interface"); +MODULE_LICENSE("GPL"); diff --git a/include/linux/mfd/davinci_aemif.h b/include/linux/mfd/davinci_aemif.h index 05b2934..18650c3 100644 --- a/include/linux/mfd/davinci_aemif.h +++ b/include/linux/mfd/davinci_aemif.h @@ -10,6 +10,10 @@ #ifndef _MACH_DAVINCI_AEMIF_H #define _MACH_DAVINCI_AEMIF_H +#include +#include +#include + #define NRCSR_OFFSET 0x00 #define AWCCR_OFFSET 0x04 #define A1CR_OFFSET 0x10 @@ -18,6 +22,16 @@ #define ACR_EW_MASK BIT(30) #define ACR_SS_MASK BIT(31) +enum davinci_emif_cells { + DAVINCI_NAND_DEVICE_CELL, + DAVINCI_NOR_FLASH_CELL, +}; + +struct davinci_aemif_devices { + struct platform_device *devices; + unsigned int num_devices; +}; + /* All timings in nanoseconds */ struct davinci_aemif_timing { u8 wsetup; -- 1.7.1 From prakash.pm at ti.com Wed Jan 25 04:25:56 2012 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Wed, 25 Jan 2012 15:55:56 +0530 Subject: [PATCH v2 3/3] arm: da830: move NAND and NOR devices as aemif MFD slaves In-Reply-To: <1327487156-10238-1-git-send-email-prakash.pm@ti.com> References: <1327487156-10238-1-git-send-email-prakash.pm@ti.com> Message-ID: <1327487156-10238-3-git-send-email-prakash.pm@ti.com> NAND and NOR device are made as aemif devices slave, hence device registration achieved via aemif MFD driver. Signed-off-by: Manjunathappa, Prakash --- Since v1: Patch is generated using -M option. arch/arm/mach-davinci/board-da830-evm.c | 31 +++++++++++++++++++++++-------- 1 files changed, 23 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c index 0b43554..0ad3662 100644 --- a/arch/arm/mach-davinci/board-da830-evm.c +++ b/arch/arm/mach-davinci/board-da830-evm.c @@ -396,14 +396,29 @@ static struct resource da830_evm_nand_resources[] = { }, }; -static struct platform_device da830_evm_nand_device = { - .name = "davinci_nand", - .id = 1, - .dev = { - .platform_data = &da830_evm_nand_pdata, +static struct platform_device da830_evm_devices[] __initdata = { + { + .name = "davinci_nand", + .id = 1, + .dev = { + .platform_data = &da830_evm_nand_pdata, + }, + .num_resources = ARRAY_SIZE(da830_evm_nand_resources), + .resource = da830_evm_nand_resources, + }, +}; + +static struct davinci_aemif_devices da830_emif_devices = { + .devices = da830_evm_devices, + .num_devices = ARRAY_SIZE(da830_evm_devices), +}; + +static struct platform_device davinci_emif_device = { + .name = "davinci_aemif", + .id = -1, + .dev = { + .platform_data = &da830_emif_devices, }, - .num_resources = ARRAY_SIZE(da830_evm_nand_resources), - .resource = da830_evm_nand_resources, }; static inline void da830_evm_init_nand(int mux_mode) @@ -422,7 +437,7 @@ static inline void da830_evm_init_nand(int mux_mode) pr_warning("da830_evm_init: emif25 mux setup failed: %d\n", ret); - ret = platform_device_register(&da830_evm_nand_device); + ret = platform_device_register(&davinci_emif_device); if (ret) pr_warning("da830_evm_init: NAND device not registered.\n"); -- 1.7.1 From balbi at ti.com Wed Jan 25 05:00:20 2012 From: balbi at ti.com (Felipe Balbi) Date: Wed, 25 Jan 2012 13:00:20 +0200 Subject: Fwd: platform driver (musb/davinci.ko) and resource.c In-Reply-To: <4F1FD994.3080203@mvista.com> References: <4F1FD994.3080203@mvista.com> Message-ID: <20120125110019.GF12577@legolas.emea.dhcp.ti.com> Hi, On Wed, Jan 25, 2012 at 02:29:40PM +0400, Sergei Shtylyov wrote: > Hello. > > I'm forwarding this mail to linux-usb and the MUSB maintainer. > > WBR, Sergei > > -------- Original Message -------- > Subject: platform driver (musb/davinci.ko) and resource.c > Date: Tue, 24 Jan 2012 23:02:59 +0200 > From: Nam Nequam > To: davinci-linux-open-source at linux.davincidsp.com > > > > Hello, > > In the recent kernel versions usb/musb/davinci has been promoted to a module > (platform driver) instead of being part of musb_hdrc. > > There is a little bug if davinci.ko is compiled as loadable module. davinci.ko > can be inserted (modprobe) once only. > After removal, it cannot be inserted again, due to "musb_hdrc: failed to claim > resource 0" error in platform.c:platform_device_add() or crash. > It happens because upon davinci.ko:davinci_probe(), > resource.c:__insert_resource() modifies the global > mach-davinci/usb.c:usb_dev.resource variable. > After davinci.ko removal, the global usb.c:usb_dev.resource.parent points to > freed memory. > So, at the next modprobe davinci.ko, if, luckily, davinci.ko allocates memory > platfrom_device_add_resources():kmemdup at the same location, > it gives the above error ("claim resource"), otherwise - crash (since > resource->parent pointer is not valid) > > It may be a common problem for platform devices that use global resource > array, and their loadable platform drivers. > > BTW: Why does resource.c build a tree from overlapping resources at multiple > insertions, and then silently drops the whole sub-tree upon removal of the > current root. > Where the root is just the most recently added resource. > > > Here is the exact sequence: > 1. Upon boot /mach-davinci/usb:davinci_setup_usb registers a usb_dev > 1.1 platform.c:platform_device_add inserts a usb_dev.resource[0] (defaulting > its parent to iomem_resource) > 1.2 resource.c:__insert_resource places usb_dev.resource[0] under iomem_resource > > 2. Upon modprobe davinci.ko: > 2.1 davinci.c:davinci_probe kmemdup(platform_device_add_resources) the > resource from usb_dev.resource[0] (where sb_dev.resource[0].parent == > iomem_resource from 1.1) > 2.2 davinci.c:davinci_probe calls platform.c:platform_device_add, which > calls resource.c:insert_resource > 2.3 resource.c:__insert_resource: > 2.3.1 finds a registered (at 1.2) usb_dev.resource[0] > 2.3.2 replaces it by musb->resource[0] and makes usb_dev.resource[0] child of > musb->resource[0] > 2.3.3 so, now, the global usb_dev.resource[0].parent == musb->resource[0] > (usb_dev.resource[0].parent->musb->resource[0].parent->iomem_resource) > > 3. Upon rmmod davinci.ko > 2.1 resource.c:release_resource drops both musb->resource[0] and > usb_dev.resource[0] (usb_dev.resource[0].parent->musb->resource[0].parent) > 2.2 davinci.c:davinci_removes platform device > 2.3 the global usb_dev.resource[0].parent now points to kfreed > parent->musb->resource[0] > > 4. Upon the second modprobe davinci.ko: resource.c:__insert_resource > 4.1 davinci.c:davinci_probe kmemdup(platform_device_add_resources) the > resource from usb_dev.resource[0] (where usb_dev.resource[0].parent == > deleted musb->resource[0] from 2.3.3) > 4.2 if kmemdup allocated musb->resource[0] at the same place: > __insert_resource will reject it, because its parent points to itself > (the same memory location from the previous reincarantion), > otherwise > __insert_resource will crash trying to insert musb->resource[0] under > [usb_dev/musb].parent which points to invalid memory location (released at 2.2) try patch below: diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c index 7c569f5..d6774fc 100644 --- a/drivers/usb/musb/davinci.c +++ b/drivers/usb/musb/davinci.c @@ -511,7 +511,7 @@ static const struct musb_platform_ops davinci_ops = { static u64 davinci_dmamask = DMA_BIT_MASK(32); -static int __init davinci_probe(struct platform_device *pdev) +static int __devinit davinci_probe(struct platform_device *pdev) { struct musb_hdrc_platform_data *pdata = pdev->dev.platform_data; struct platform_device *musb; @@ -594,7 +594,7 @@ err0: return ret; } -static int __exit davinci_remove(struct platform_device *pdev) +static int __devexit davinci_remove(struct platform_device *pdev) { struct davinci_glue *glue = platform_get_drvdata(pdev); @@ -608,7 +608,8 @@ static int __exit davinci_remove(struct platform_device *pdev) } static struct platform_driver davinci_driver = { - .remove = __exit_p(davinci_remove), + .probe = davinci_probe, + .remove = __devexit_p(davinci_remove), .driver = { .name = "musb-davinci", }, @@ -620,7 +621,7 @@ MODULE_LICENSE("GPL v2"); static int __init davinci_init(void) { - return platform_driver_probe(&davinci_driver, davinci_probe); + return platform_driver_register(&davinci_driver); } subsys_initcall(davinci_init); let me know if that doesn't solve all your problems. -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From sshtylyov at mvista.com Wed Jan 25 08:51:32 2012 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Wed, 25 Jan 2012 17:51:32 +0300 Subject: [PATCH v2 3/3] arm: da830: move NAND and NOR devices as aemif MFD slaves In-Reply-To: <1327487156-10238-3-git-send-email-prakash.pm@ti.com> References: <1327487156-10238-1-git-send-email-prakash.pm@ti.com> <1327487156-10238-3-git-send-email-prakash.pm@ti.com> Message-ID: <4F2016F4.2080302@mvista.com> Hello. On 01/25/2012 01:25 PM, Manjunathappa, Prakash wrote: > NAND and NOR device are made as aemif devices slave, hence device > registration achieved via aemif MFD driver. > Signed-off-by: Manjunathappa, Prakash > --- > Since v1: > Patch is generated using -M option. > arch/arm/mach-davinci/board-da830-evm.c | 31 +++++++++++++++++++++++-------- > 1 files changed, 23 insertions(+), 8 deletions(-) Why only this file? Don't other board files have NAND/NOR devices? WBR, Sergei From manjunath.hadli at ti.com Wed Jan 25 09:05:30 2012 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Wed, 25 Jan 2012 20:35:30 +0530 Subject: [PATCH 0/4] davinci: add vpif support for da850/omap-l138 Message-ID: <1327503934-28186-1-git-send-email-manjunath.hadli@ti.com> add vpif capture and display driver support for da850/omap-l138 by taking care of the interrupt behavior changes and removing platform specific connotations. Manjunath Hadli (4): davinci: vpif: add check for genuine interrupts in the isr davinci: vpif: make generic changes to re-use the vpif drivers on da850/omap-l138 soc davinci: vpif: make request_irq flags as shared davinci: da850: add build configuration for vpif drivers drivers/media/video/davinci/Kconfig | 26 +++++++++++++++++++++++++- drivers/media/video/davinci/Makefile | 5 +++++ drivers/media/video/davinci/vpif.c | 2 +- drivers/media/video/davinci/vpif_capture.c | 16 ++++++++++------ drivers/media/video/davinci/vpif_display.c | 21 +++++++++++++-------- drivers/media/video/davinci/vpif_display.h | 2 +- include/media/davinci/vpif_types.h | 2 ++ 7 files changed, 57 insertions(+), 17 deletions(-) From manjunath.hadli at ti.com Wed Jan 25 09:05:31 2012 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Wed, 25 Jan 2012 20:35:31 +0530 Subject: [PATCH 1/4] davinci: vpif: add check for genuine interrupts in the isr In-Reply-To: <1327503934-28186-1-git-send-email-manjunath.hadli@ti.com> References: <1327503934-28186-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1327503934-28186-2-git-send-email-manjunath.hadli@ti.com> add a condition to in the isr to check for interrupt ownership and channel number to make sure we do not service wrong interrupts. Signed-off-by: Manjunath Hadli --- drivers/media/video/davinci/vpif_capture.c | 5 +++++ drivers/media/video/davinci/vpif_display.c | 5 +++++ include/media/davinci/vpif_types.h | 2 ++ 3 files changed, 12 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/davinci/vpif_capture.c b/drivers/media/video/davinci/vpif_capture.c index 6504e40..33d865d 100644 --- a/drivers/media/video/davinci/vpif_capture.c +++ b/drivers/media/video/davinci/vpif_capture.c @@ -333,6 +333,7 @@ static void vpif_schedule_next_buffer(struct common_obj *common) */ static irqreturn_t vpif_channel_isr(int irq, void *dev_id) { + struct vpif_capture_config *config = vpif_dev->platform_data; struct vpif_device *dev = &vpif_obj; struct common_obj *common; struct channel_obj *ch; @@ -341,6 +342,10 @@ static irqreturn_t vpif_channel_isr(int irq, void *dev_id) int fid = -1, i; channel_id = *(int *)(dev_id); + if (!config->intr_status || + !config->intr_status(vpif_base, channel_id)) + return IRQ_NONE; + ch = dev->dev[channel_id]; field = ch->common[VPIF_VIDEO_INDEX].fmt.fmt.pix.field; diff --git a/drivers/media/video/davinci/vpif_display.c b/drivers/media/video/davinci/vpif_display.c index 286f029..b315ccf 100644 --- a/drivers/media/video/davinci/vpif_display.c +++ b/drivers/media/video/davinci/vpif_display.c @@ -301,6 +301,7 @@ static void process_interlaced_mode(int fid, struct common_obj *common) */ static irqreturn_t vpif_channel_isr(int irq, void *dev_id) { + struct vpif_display_config *config = vpif_dev->platform_data; struct vpif_device *dev = &vpif_obj; struct channel_obj *ch; struct common_obj *common; @@ -309,6 +310,10 @@ static irqreturn_t vpif_channel_isr(int irq, void *dev_id) int channel_id = 0; channel_id = *(int *)(dev_id); + if (!config->intr_status || + !config->intr_status(vpif_base, channel_id + 2)) + return IRQ_NONE; + ch = dev->dev[channel_id]; field = ch->common[VPIF_VIDEO_INDEX].fmt.fmt.pix.field; for (i = 0; i < VPIF_NUMOBJECTS; i++) { diff --git a/include/media/davinci/vpif_types.h b/include/media/davinci/vpif_types.h index 9929b05..4802d06 100644 --- a/include/media/davinci/vpif_types.h +++ b/include/media/davinci/vpif_types.h @@ -43,6 +43,7 @@ struct vpif_subdev_info { struct vpif_display_config { int (*set_clock)(int, int); + int (*intr_status)(void __iomem *vpif_base, int); struct vpif_subdev_info *subdevinfo; int subdev_count; const char **output; @@ -63,6 +64,7 @@ struct vpif_capture_chan_config { struct vpif_capture_config { int (*setup_input_channel_mode)(int); int (*setup_input_path)(int, const char *); + int (*intr_status)(void __iomem *vpif_base, int); struct vpif_capture_chan_config chan_config[VPIF_CAPTURE_MAX_CHANNELS]; struct vpif_subdev_info *subdev_info; int subdev_count; -- 1.6.2.4 From manjunath.hadli at ti.com Wed Jan 25 09:05:32 2012 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Wed, 25 Jan 2012 20:35:32 +0530 Subject: [PATCH 2/4] davinci: vpif: make generic changes to re-use the vpif drivers on da850/omap-l138 soc In-Reply-To: <1327503934-28186-1-git-send-email-manjunath.hadli@ti.com> References: <1327503934-28186-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1327503934-28186-3-git-send-email-manjunath.hadli@ti.com> change the dm646x specific strings in the driver to make them generic across platforms. In this case change all the strings which have a dm646x connotation to vpif which is a platform independent ip. Signed-off-by: Manjunath Hadli --- drivers/media/video/davinci/vpif.c | 2 +- drivers/media/video/davinci/vpif_capture.c | 9 ++++----- drivers/media/video/davinci/vpif_display.c | 14 +++++++------- drivers/media/video/davinci/vpif_display.h | 2 +- 4 files changed, 13 insertions(+), 14 deletions(-) diff --git a/drivers/media/video/davinci/vpif.c b/drivers/media/video/davinci/vpif.c index af96802..774bcd3 100644 --- a/drivers/media/video/davinci/vpif.c +++ b/drivers/media/video/davinci/vpif.c @@ -1,5 +1,5 @@ /* - * vpif - DM646x Video Port Interface driver + * vpif - Video Port Interface driver * VPIF is a receiver and transmitter for video data. It has two channels(0, 1) * that receiveing video byte stream and two channels(2, 3) for video output. * The hardware supports SDTV, HDTV formats, raw data capture. diff --git a/drivers/media/video/davinci/vpif_capture.c b/drivers/media/video/davinci/vpif_capture.c index 33d865d..010cce4 100644 --- a/drivers/media/video/davinci/vpif_capture.c +++ b/drivers/media/video/davinci/vpif_capture.c @@ -1684,7 +1684,7 @@ static int vpif_querycap(struct file *file, void *priv, cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING; strlcpy(cap->driver, "vpif capture", sizeof(cap->driver)); - strlcpy(cap->bus_info, "DM646x Platform", sizeof(cap->bus_info)); + strlcpy(cap->bus_info, "VPIF Platform", sizeof(cap->bus_info)); strlcpy(cap->card, config->card_name, sizeof(cap->card)); return 0; @@ -2192,7 +2192,7 @@ static __init int vpif_probe(struct platform_device *pdev) while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, k))) { for (i = res->start; i <= res->end; i++) { if (request_irq(i, vpif_channel_isr, IRQF_DISABLED, - "DM646x_Capture", + "VPIF_Capture", (void *)(&vpif_obj.dev[k]->channel_id))) { err = -EBUSY; i--; @@ -2221,7 +2221,7 @@ static __init int vpif_probe(struct platform_device *pdev) vfd->v4l2_dev = &vpif_obj.v4l2_dev; vfd->release = video_device_release; snprintf(vfd->name, sizeof(vfd->name), - "DM646x_VPIFCapture_DRIVER_V%s", + "VPIF_Capture_DRIVER_V%s", VPIF_CAPTURE_VERSION); /* Set video_dev to the video device */ ch->video_dev = vfd; @@ -2276,8 +2276,7 @@ static __init int vpif_probe(struct platform_device *pdev) vpif_obj.sd[i]->grp_id = 1 << i; } - v4l2_info(&vpif_obj.v4l2_dev, - "DM646x VPIF capture driver initialized\n"); + v4l2_info(&vpif_obj.v4l2_dev, "VPIF capture driver initialized\n"); return 0; probe_subdev_out: diff --git a/drivers/media/video/davinci/vpif_display.c b/drivers/media/video/davinci/vpif_display.c index b315ccf..6f3eabb 100644 --- a/drivers/media/video/davinci/vpif_display.c +++ b/drivers/media/video/davinci/vpif_display.c @@ -48,7 +48,7 @@ MODULE_DESCRIPTION("TI DaVinci VPIF Display driver"); MODULE_LICENSE("GPL"); MODULE_VERSION(VPIF_DISPLAY_VERSION); -#define DM646X_V4L2_STD (V4L2_STD_525_60 | V4L2_STD_625_50) +#define VPIF_V4L2_STD (V4L2_STD_525_60 | V4L2_STD_625_50) #define vpif_err(fmt, arg...) v4l2_err(&vpif_obj.v4l2_dev, fmt, ## arg) #define vpif_dbg(level, debug, fmt, arg...) \ @@ -976,7 +976,7 @@ static int vpif_s_std(struct file *file, void *priv, v4l2_std_id *std_id) struct common_obj *common = &ch->common[VPIF_VIDEO_INDEX]; int ret = 0; - if (!(*std_id & DM646X_V4L2_STD)) + if (!(*std_id & VPIF_V4L2_STD)) return -EINVAL; if (common->started) { @@ -1227,7 +1227,7 @@ static int vpif_enum_output(struct file *file, void *fh, strcpy(output->name, config->output[output->index]); output->type = V4L2_OUTPUT_TYPE_ANALOG; - output->std = DM646X_V4L2_STD; + output->std = VPIF_V4L2_STD; return 0; } @@ -1612,7 +1612,7 @@ static struct video_device vpif_video_template = { .name = "vpif", .fops = &vpif_fops, .ioctl_ops = &vpif_ioctl_ops, - .tvnorms = DM646X_V4L2_STD, + .tvnorms = VPIF_V4L2_STD, .current_norm = V4L2_STD_625_50, }; @@ -1714,7 +1714,7 @@ static __init int vpif_probe(struct platform_device *pdev) while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, k))) { for (i = res->start; i <= res->end; i++) { if (request_irq(i, vpif_channel_isr, IRQF_DISABLED, - "DM646x_Display", + "VPIF_Display", (void *)(&vpif_obj.dev[k]->channel_id))) { err = -EBUSY; goto vpif_int_err; @@ -1744,7 +1744,7 @@ static __init int vpif_probe(struct platform_device *pdev) vfd->v4l2_dev = &vpif_obj.v4l2_dev; vfd->release = video_device_release; snprintf(vfd->name, sizeof(vfd->name), - "DM646x_VPIFDisplay_DRIVER_V%s", + "VPIF_Display_DRIVER_V%s", VPIF_DISPLAY_VERSION); /* Set video_dev to the video device */ @@ -1826,7 +1826,7 @@ static __init int vpif_probe(struct platform_device *pdev) } v4l2_info(&vpif_obj.v4l2_dev, - "DM646x VPIF display driver initialized\n"); + " VPIF display driver initialized\n"); return 0; probe_subdev_out: diff --git a/drivers/media/video/davinci/vpif_display.h b/drivers/media/video/davinci/vpif_display.h index 56879d1..dd4887c 100644 --- a/drivers/media/video/davinci/vpif_display.h +++ b/drivers/media/video/davinci/vpif_display.h @@ -1,5 +1,5 @@ /* - * DM646x display header file + * VPIF display header file * * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/ * -- 1.6.2.4 From manjunath.hadli at ti.com Wed Jan 25 09:05:33 2012 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Wed, 25 Jan 2012 20:35:33 +0530 Subject: [PATCH 3/4] davinci: vpif: make request_irq flags as shared In-Reply-To: <1327503934-28186-1-git-send-email-manjunath.hadli@ti.com> References: <1327503934-28186-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1327503934-28186-4-git-send-email-manjunath.hadli@ti.com> omap-l138 shares the interrupt between capture and display. Make sure we are able to request for the same irq number by making a shared irq request. Signed-off-by: Manjunath Hadli --- drivers/media/video/davinci/vpif_capture.c | 2 +- drivers/media/video/davinci/vpif_display.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/davinci/vpif_capture.c b/drivers/media/video/davinci/vpif_capture.c index 010cce4..ad933e0 100644 --- a/drivers/media/video/davinci/vpif_capture.c +++ b/drivers/media/video/davinci/vpif_capture.c @@ -2191,7 +2191,7 @@ static __init int vpif_probe(struct platform_device *pdev) k = 0; while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, k))) { for (i = res->start; i <= res->end; i++) { - if (request_irq(i, vpif_channel_isr, IRQF_DISABLED, + if (request_irq(i, vpif_channel_isr, IRQF_SHARED, "VPIF_Capture", (void *)(&vpif_obj.dev[k]->channel_id))) { err = -EBUSY; diff --git a/drivers/media/video/davinci/vpif_display.c b/drivers/media/video/davinci/vpif_display.c index 6f3eabb..c876c10 100644 --- a/drivers/media/video/davinci/vpif_display.c +++ b/drivers/media/video/davinci/vpif_display.c @@ -1713,7 +1713,7 @@ static __init int vpif_probe(struct platform_device *pdev) k = 0; while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, k))) { for (i = res->start; i <= res->end; i++) { - if (request_irq(i, vpif_channel_isr, IRQF_DISABLED, + if (request_irq(i, vpif_channel_isr, IRQF_SHARED, "VPIF_Display", (void *)(&vpif_obj.dev[k]->channel_id))) { err = -EBUSY; -- 1.6.2.4 From manjunath.hadli at ti.com Wed Jan 25 09:05:34 2012 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Wed, 25 Jan 2012 20:35:34 +0530 Subject: [PATCH 4/4] davinci: da850: add build configuration for vpif drivers In-Reply-To: <1327503934-28186-1-git-send-email-manjunath.hadli@ti.com> References: <1327503934-28186-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1327503934-28186-5-git-send-email-manjunath.hadli@ti.com> add build configuration for da850/omapl-138 for vpif capture and display drivers. Signed-off-by: Manjunath Hadli --- drivers/media/video/davinci/Kconfig | 26 +++++++++++++++++++++++++- drivers/media/video/davinci/Makefile | 5 +++++ 2 files changed, 30 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig index 60a456e..a0b0fb3 100644 --- a/drivers/media/video/davinci/Kconfig +++ b/drivers/media/video/davinci/Kconfig @@ -22,9 +22,33 @@ config CAPTURE_DAVINCI_DM646X_EVM To compile this driver as a module, choose M here: the module will be called vpif_capture. +config DISPLAY_DAVINCI_DA850_EVM + tristate "DA850/OMAPL138 EVM Video Display" + depends on DA850_UI_SD_VIDEO_PORT && VIDEO_DEV && MACH_DAVINCI_DA850_EVM + select VIDEOBUF_DMA_CONTIG + select VIDEO_DAVINCI_VPIF + select VIDEO_ADV7343 + select VIDEO_THS7303 + help + Support for DA850/OMAP-L138/AM18xx based display device. + + To compile this driver as a module, choose M here: the + module will be called vpif_display. + +config CAPTURE_DAVINCI_DA850_EVM + tristate "DA850/OMAPL138 EVM Video Capture" + depends on DA850_UI_SD_VIDEO_PORT && VIDEO_DEV && MACH_DAVINCI_DA850_EVM + select VIDEOBUF_DMA_CONTIG + select VIDEO_DAVINCI_VPIF + help + Support for DA850/OMAP-L138/AM18xx based capture device. + + To compile this driver as a module, choose M here: the + module will be called vpif_capture. + config VIDEO_DAVINCI_VPIF tristate "DaVinci VPIF Driver" - depends on DISPLAY_DAVINCI_DM646X_EVM + depends on DISPLAY_DAVINCI_DM646X_EVM || DISPLAY_DAVINCI_DA850_EVM help Support for DaVinci VPIF Driver. diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index ae7dafb..2c7cfb0 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -10,6 +10,11 @@ obj-$(CONFIG_DISPLAY_DAVINCI_DM646X_EVM) += vpif_display.o #DM646x EVM Capture driver obj-$(CONFIG_CAPTURE_DAVINCI_DM646X_EVM) += vpif_capture.o +#DA850 EVM Display driver +obj-$(CONFIG_DISPLAY_DAVINCI_DA850_EVM) += vpif_display.o +#DA850 EVM Capture driver +obj-$(CONFIG_CAPTURE_DAVINCI_DA850_EVM) += vpif_capture.o + # Capture: DM6446 and DM355 obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o -- 1.6.2.4 From sakari.ailus at iki.fi Wed Jan 25 17:43:17 2012 From: sakari.ailus at iki.fi (Sakari Ailus) Date: Thu, 26 Jan 2012 01:43:17 +0200 Subject: [PATCH v2 2/2] v4l2: add new pixel formats supported on dm365 In-Reply-To: <1327065739-3362-3-git-send-email-manjunath.hadli@ti.com> References: <1327065739-3362-1-git-send-email-manjunath.hadli@ti.com> <1327065739-3362-3-git-send-email-manjunath.hadli@ti.com> Message-ID: <20120125234317.GB15297@valkosipuli.localdomain> Hi Manju, Thanks for the patch. On Fri, Jan 20, 2012 at 06:52:19PM +0530, Manjunath Hadli wrote: > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats > to represent Bayer format frames compressed by A-LAW alogorithm, > add V4L2_PIX_FMT_UV8 to represent storage of C data (UV interleved) > only. > > Signed-off-by: Manjunath Hadli > Cc: Laurent Pinchart > --- > .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 +++++++++++ > Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62 ++++++++++++++++++++ > Documentation/DocBook/media/v4l/pixfmt.xml | 2 + > include/linux/videodev2.h | 9 +++ > 4 files changed, 107 insertions(+), 0 deletions(-) > create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml > create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml > > diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml > new file mode 100644 > index 0000000..8c1765c > --- /dev/null > +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml > @@ -0,0 +1,34 @@ > + > + > + > + V4L2_PIX_FMT_SRGGB10ALAW8 ('bBL8'), > + V4L2_PIX_FMT_SGBRG10ALAW8 ('bgL8'), > + V4L2_PIX_FMT_SGRBG10ALAW8 ('BGL8'), > + V4L2_PIX_FMT_SBGGR10ALAW8 ('bRL8'), I have a proposal on 4CC naming which I'll try to post tomorrow. This may require extending it a little bit, but I think it's about time to set guidelines on 4CC naming. > + > + &manvol; > + > + > + > + V4L2_PIX_FMT_SRGGB10ALAW8 > + > + > + V4L2_PIX_FMT_SGRBG10ALAW8 > + > + > + V4L2_PIX_FMT_SGBRG10ALAW8 > + > + > + V4L2_PIX_FMT_SBGGR10ALAW8 > + > + 10-bit Bayer formats compressed to 8 bits > + > + > + Description > + The following four pixel formats are raw sRGB / Bayer > + formats with 10 bits per colour compressed to 8 bits each, > + using the A-LAW algorithm. Each colour component consumes 8 > + bits of memory. In other respects this format is similar to > + . > + > + > diff --git a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml > new file mode 100644 > index 0000000..e3e6b11 > --- /dev/null > +++ b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml > @@ -0,0 +1,62 @@ > + > + > + V4L2_PIX_FMT_UV8 ('UV8') > + &manvol; > + > + > + V4L2_PIX_FMT_UV8 > + UV plane interleaved > + > + > + Description > + In this format there is no Y plane, Only C plane. ie > + (UV interleaved) > + > + > + <constant>V4L2_PIX_FMT_UV8</constant> > + pixel image > + > + > + > + Byte Order. > + Each cell is one byte. > + > + > + > + > + > + start + 0: > + Cb00 > + Cr00 > + Cb01 > + Cr01 > + > + > + start + 4: > + Cb10 > + Cr10 > + Cb11 > + Cr11 > + > + > + start + 8: > + Cb20 > + Cr20 > + Cb21 > + Cr21 > + > + > + start + 12: > + Cb30 > + Cr30 > + Cb31 > + Cr31 > + > + > + > + > + > + > + > + > + > diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml > index 9ddc57c..0b62750 100644 > --- a/Documentation/DocBook/media/v4l/pixfmt.xml > +++ b/Documentation/DocBook/media/v4l/pixfmt.xml > @@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.< > &sub-srggb8; > &sub-sbggr16; > &sub-srggb10; > + &sub-srggb10alaw8; > &sub-srggb12; > > > @@ -696,6 +697,7 @@ information. > > &sub-packed-yuv; > &sub-grey; > + &sub-uv8; > &sub-y10; > &sub-y12; > &sub-y10b; > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h > index 012a296..36b6d91 100644 > --- a/include/linux/videodev2.h > +++ b/include/linux/videodev2.h > @@ -338,6 +338,9 @@ struct v4l2_pix_format { > #define V4L2_PIX_FMT_HM12 v4l2_fourcc('H', 'M', '1', '2') /* 8 YUV 4:2:0 16x16 macroblocks */ > #define V4L2_PIX_FMT_M420 v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 line uv interleaved */ > > +/* Chrominance formats */ > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /* 8 UV 4:4 */ > + > /* two planes -- one Y, one Cr + Cb interleaved */ > #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr 4:2:0 */ > #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb 4:2:0 */ > @@ -366,6 +369,12 @@ struct v4l2_pix_format { > #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */ > /* 10bit raw bayer DPCM compressed to 8 bits */ > #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0') > + /* 10bit raw bayer a-law compressed to 8 bits */ > +#define V4L2_PIX_FMT_SRGGB10ALAW8 v4l2_fourcc('b', 'B', 'L', '8') > +#define V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('b', 'g', 'L', '8') > +#define V4L2_PIX_FMT_SGBRG10ALAW8 v4l2_fourcc('B', 'G', 'L', '8') > +#define V4L2_PIX_FMT_SBGGR10ALAW8 v4l2_fourcc('b', 'R', 'L', '8') > + > /* > * 10bit raw bayer, expanded to 16 bits > * xxxxrrrrrrrrrrxxxxgggggggggg xxxxggggggggggxxxxbbbbbbbbbb... > -- > 1.6.2.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sakari Ailus e-mail: sakari.ailus at iki.fi jabber/XMPP/Gmail: sailus at retiisi.org.uk From sudhakar.raj at ti.com Thu Jan 26 02:27:10 2012 From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar) Date: Thu, 26 Jan 2012 08:27:10 +0000 Subject: DA850 / OMAP-L138 / AM-1808 EMIFA Clk issues. In-Reply-To: References: <4F143A70.4040505@criticallink.com> <4F156CEB.4050803@criticallink.com> Message-ID: Hi Mike, On Fri, Jan 20, 2012 at 15:18:07, Rajashekhara, Sudhakar wrote: > Hi Mike, > > On Tue, Jan 17, 2012 at 18:13:23, Michael Williamson wrote: > > Hello Sudhakar, > > > > On 1/17/2012 12:39 AM, Rajashekhara, Sudhakar wrote: > > > > > Hi Mike, > > > > > > On Mon, Jan 16, 2012 at 20:25:44, Michael Williamson wrote: > > >> Hi, > > >> [...] > > > We were actually interested in having the option to run that bus (in async > > mode) faster than 100 MHz for the higher speed OPP's, but it sounds like > > the specification is a little misleading in the capabilities of the part. > > > > As I mentioned above, I'll get this clarified from our design team and update you. > I got the confirmation from our design team that EMIFA can be run at a frequency more than 100 MHz at 1.3v and 1.2v. So information in Table 5.5 of OMAP-L138 data sheet (http://www.ti.com/lit/ds/symlink/omap-l138.pdf) is correct. We will correct the software to adjust the EMIFA frequency when the OPP changes instead of fixing the clock divider value. Thanks, Sudhakar From balbi at ti.com Thu Jan 26 04:45:49 2012 From: balbi at ti.com (Felipe Balbi) Date: Thu, 26 Jan 2012 12:45:49 +0200 Subject: [PATCH] usb: musb: make modules behave better Message-ID: <1327574749-18552-1-git-send-email-balbi@ti.com> There's really no point in doing all that initcall trickery when we can safely let udev handle module probing for us. Remove all of that trickery, by moving everybody to module_init() and making proper use of platform_device_register() rather than platform_device_probe(). Signed-off-by: Felipe Balbi --- Because this falls into the "has never worked before" category I will be sending this only on the next merge window. This also gives people enough time to complain about any mistakes on the patch. drivers/usb/musb/am35x.c | 11 ++++++----- drivers/usb/musb/blackfin.c | 9 +++++---- drivers/usb/musb/da8xx.c | 11 ++++++----- drivers/usb/musb/davinci.c | 11 ++++++----- drivers/usb/musb/musb_core.c | 15 ++++++--------- drivers/usb/musb/omap2430.c | 11 ++++++----- drivers/usb/musb/tusb6010.c | 11 ++++++----- drivers/usb/musb/ux500.c | 11 ++++++----- 8 files changed, 47 insertions(+), 43 deletions(-) diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c index e233d2b..5285bda 100644 --- a/drivers/usb/musb/am35x.c +++ b/drivers/usb/musb/am35x.c @@ -456,7 +456,7 @@ static const struct musb_platform_ops am35x_ops = { static u64 am35x_dmamask = DMA_BIT_MASK(32); -static int __init am35x_probe(struct platform_device *pdev) +static int __devinit am35x_probe(struct platform_device *pdev) { struct musb_hdrc_platform_data *pdata = pdev->dev.platform_data; struct platform_device *musb; @@ -561,7 +561,7 @@ err0: return ret; } -static int __exit am35x_remove(struct platform_device *pdev) +static int __devexit am35x_remove(struct platform_device *pdev) { struct am35x_glue *glue = platform_get_drvdata(pdev); @@ -630,7 +630,8 @@ static struct dev_pm_ops am35x_pm_ops = { #endif static struct platform_driver am35x_driver = { - .remove = __exit_p(am35x_remove), + .probe = am35x_probe, + .remove = __devexit_p(am35x_remove), .driver = { .name = "musb-am35x", .pm = DEV_PM_OPS, @@ -643,9 +644,9 @@ MODULE_LICENSE("GPL v2"); static int __init am35x_init(void) { - return platform_driver_probe(&am35x_driver, am35x_probe); + return platform_driver_register(&am35x_driver); } -subsys_initcall(am35x_init); +module_init(am35x_init); static void __exit am35x_exit(void) { diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c index 5e7cfba..261af34 100644 --- a/drivers/usb/musb/blackfin.c +++ b/drivers/usb/musb/blackfin.c @@ -463,7 +463,7 @@ static const struct musb_platform_ops bfin_ops = { static u64 bfin_dmamask = DMA_BIT_MASK(32); -static int __init bfin_probe(struct platform_device *pdev) +static int __devinit bfin_probe(struct platform_device *pdev) { struct musb_hdrc_platform_data *pdata = pdev->dev.platform_data; struct platform_device *musb; @@ -525,7 +525,7 @@ err0: return ret; } -static int __exit bfin_remove(struct platform_device *pdev) +static int __devexit bfin_remove(struct platform_device *pdev) { struct bfin_glue *glue = platform_get_drvdata(pdev); @@ -575,6 +575,7 @@ static struct dev_pm_ops bfin_pm_ops = { #endif static struct platform_driver bfin_driver = { + .probe = bfin_probe, .remove = __exit_p(bfin_remove), .driver = { .name = "musb-blackfin", @@ -588,9 +589,9 @@ MODULE_LICENSE("GPL v2"); static int __init bfin_init(void) { - return platform_driver_probe(&bfin_driver, bfin_probe); + return platform_driver_register(&bfin_driver); } -subsys_initcall(bfin_init); +module_init(bfin_init); static void __exit bfin_exit(void) { diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c index 2613bfd..01c8f2e 100644 --- a/drivers/usb/musb/da8xx.c +++ b/drivers/usb/musb/da8xx.c @@ -478,7 +478,7 @@ static const struct musb_platform_ops da8xx_ops = { static u64 da8xx_dmamask = DMA_BIT_MASK(32); -static int __init da8xx_probe(struct platform_device *pdev) +static int __devinit da8xx_probe(struct platform_device *pdev) { struct musb_hdrc_platform_data *pdata = pdev->dev.platform_data; struct platform_device *musb; @@ -562,7 +562,7 @@ err0: return ret; } -static int __exit da8xx_remove(struct platform_device *pdev) +static int __devexit da8xx_remove(struct platform_device *pdev) { struct da8xx_glue *glue = platform_get_drvdata(pdev); @@ -576,7 +576,8 @@ static int __exit da8xx_remove(struct platform_device *pdev) } static struct platform_driver da8xx_driver = { - .remove = __exit_p(da8xx_remove), + .probe = da8xx_probe, + .remove = __devexit_p(da8xx_remove), .driver = { .name = "musb-da8xx", }, @@ -588,9 +589,9 @@ MODULE_LICENSE("GPL v2"); static int __init da8xx_init(void) { - return platform_driver_probe(&da8xx_driver, da8xx_probe); + return platform_driver_register(&da8xx_driver); } -subsys_initcall(da8xx_init); +module_init(da8xx_init); static void __exit da8xx_exit(void) { diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c index f9a3f62..7802c7e 100644 --- a/drivers/usb/musb/davinci.c +++ b/drivers/usb/musb/davinci.c @@ -514,7 +514,7 @@ static const struct musb_platform_ops davinci_ops = { static u64 davinci_dmamask = DMA_BIT_MASK(32); -static int __init davinci_probe(struct platform_device *pdev) +static int __devinit davinci_probe(struct platform_device *pdev) { struct musb_hdrc_platform_data *pdata = pdev->dev.platform_data; struct platform_device *musb; @@ -597,7 +597,7 @@ err0: return ret; } -static int __exit davinci_remove(struct platform_device *pdev) +static int __devexit davinci_remove(struct platform_device *pdev) { struct davinci_glue *glue = platform_get_drvdata(pdev); @@ -611,7 +611,8 @@ static int __exit davinci_remove(struct platform_device *pdev) } static struct platform_driver davinci_driver = { - .remove = __exit_p(davinci_remove), + .probe = davinci_probe, + .remove = __devexit_p(davinci_remove), .driver = { .name = "musb-davinci", }, @@ -623,9 +624,9 @@ MODULE_LICENSE("GPL v2"); static int __init davinci_init(void) { - return platform_driver_probe(&davinci_driver, davinci_probe); + return platform_driver_register(&davinci_driver); } -subsys_initcall(davinci_init); +module_init(davinci_init); static void __exit davinci_exit(void) { diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index 6a92985..bd54470 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -2072,7 +2072,7 @@ fail0: static u64 *orig_dma_mask; #endif -static int __init musb_probe(struct platform_device *pdev) +static int __devinit musb_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; int irq = platform_get_irq_byname(pdev, "mc"); @@ -2101,7 +2101,7 @@ static int __init musb_probe(struct platform_device *pdev) return status; } -static int __exit musb_remove(struct platform_device *pdev) +static int __devexit musb_remove(struct platform_device *pdev) { struct musb *musb = dev_to_musb(&pdev->dev); void __iomem *ctrl_base = musb->ctrl_base; @@ -2361,7 +2361,8 @@ static struct platform_driver musb_driver = { .owner = THIS_MODULE, .pm = MUSB_DEV_PM_OPS, }, - .remove = __exit_p(musb_remove), + .probe = musb_probe, + .remove = __devexit_p(musb_remove), .shutdown = musb_shutdown, }; @@ -2377,13 +2378,9 @@ static int __init musb_init(void) ", " "otg (peripheral+host)", musb_driver_name); - return platform_driver_probe(&musb_driver, musb_probe); + return platform_driver_register(&musb_driver); } - -/* make us init after usbcore and i2c (transceivers, regulators, etc) - * and before usb gadget and host-side drivers start to register - */ -fs_initcall(musb_init); +module_init(musb_init); static void __exit musb_cleanup(void) { diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index c27bbbf..b254173 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -408,7 +408,7 @@ static const struct musb_platform_ops omap2430_ops = { static u64 omap2430_dmamask = DMA_BIT_MASK(32); -static int __init omap2430_probe(struct platform_device *pdev) +static int __devinit omap2430_probe(struct platform_device *pdev) { struct musb_hdrc_platform_data *pdata = pdev->dev.platform_data; struct platform_device *musb; @@ -471,7 +471,7 @@ err0: return ret; } -static int __exit omap2430_remove(struct platform_device *pdev) +static int __devexit omap2430_remove(struct platform_device *pdev) { struct omap2430_glue *glue = platform_get_drvdata(pdev); @@ -524,7 +524,8 @@ static struct dev_pm_ops omap2430_pm_ops = { #endif static struct platform_driver omap2430_driver = { - .remove = __exit_p(omap2430_remove), + .probe = omap2430_probe, + .remove = __devexit_p(omap2430_remove), .driver = { .name = "musb-omap2430", .pm = DEV_PM_OPS, @@ -537,9 +538,9 @@ MODULE_LICENSE("GPL v2"); static int __init omap2430_init(void) { - return platform_driver_probe(&omap2430_driver, omap2430_probe); + return platform_driver_register(&omap2430_driver); } -subsys_initcall(omap2430_init); +module_init(omap2430_init); static void __exit omap2430_exit(void) { diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c index 1f40561..b387f12 100644 --- a/drivers/usb/musb/tusb6010.c +++ b/drivers/usb/musb/tusb6010.c @@ -1165,7 +1165,7 @@ static const struct musb_platform_ops tusb_ops = { static u64 tusb_dmamask = DMA_BIT_MASK(32); -static int __init tusb_probe(struct platform_device *pdev) +static int __devinit tusb_probe(struct platform_device *pdev) { struct musb_hdrc_platform_data *pdata = pdev->dev.platform_data; struct platform_device *musb; @@ -1227,7 +1227,7 @@ err0: return ret; } -static int __exit tusb_remove(struct platform_device *pdev) +static int __devexit tusb_remove(struct platform_device *pdev) { struct tusb6010_glue *glue = platform_get_drvdata(pdev); @@ -1239,7 +1239,8 @@ static int __exit tusb_remove(struct platform_device *pdev) } static struct platform_driver tusb_driver = { - .remove = __exit_p(tusb_remove), + .probe = tusb_probe, + .remove = __devexit_p(tusb_remove), .driver = { .name = "musb-tusb", }, @@ -1251,9 +1252,9 @@ MODULE_LICENSE("GPL v2"); static int __init tusb_init(void) { - return platform_driver_probe(&tusb_driver, tusb_probe); + return platform_driver_register(&tusb_driver); } -subsys_initcall(tusb_init); +module_init(tusb_init); static void __exit tusb_exit(void) { diff --git a/drivers/usb/musb/ux500.c b/drivers/usb/musb/ux500.c index f7e04bf..bcfc48f 100644 --- a/drivers/usb/musb/ux500.c +++ b/drivers/usb/musb/ux500.c @@ -58,7 +58,7 @@ static const struct musb_platform_ops ux500_ops = { .exit = ux500_musb_exit, }; -static int __init ux500_probe(struct platform_device *pdev) +static int __devinit ux500_probe(struct platform_device *pdev) { struct musb_hdrc_platform_data *pdata = pdev->dev.platform_data; struct platform_device *musb; @@ -141,7 +141,7 @@ err0: return ret; } -static int __exit ux500_remove(struct platform_device *pdev) +static int __devexit ux500_remove(struct platform_device *pdev) { struct ux500_glue *glue = platform_get_drvdata(pdev); @@ -194,7 +194,8 @@ static const struct dev_pm_ops ux500_pm_ops = { #endif static struct platform_driver ux500_driver = { - .remove = __exit_p(ux500_remove), + .probe = ux500_probe, + .remove = __devexit_p(ux500_remove), .driver = { .name = "musb-ux500", .pm = DEV_PM_OPS, @@ -207,9 +208,9 @@ MODULE_LICENSE("GPL v2"); static int __init ux500_init(void) { - return platform_driver_probe(&ux500_driver, ux500_probe); + return platform_driver_register(&ux500_driver); } -subsys_initcall(ux500_init); +module_init(ux500_init); static void __exit ux500_exit(void) { -- 1.7.8.2 From balbi at ti.com Thu Jan 26 05:22:43 2012 From: balbi at ti.com (Felipe Balbi) Date: Thu, 26 Jan 2012 13:22:43 +0200 Subject: [PATCH] usb: musb: make modules behave better In-Reply-To: <4F21371F.7010403@gmail.com> References: <1327574749-18552-1-git-send-email-balbi@ti.com> <4F21371F.7010403@gmail.com> Message-ID: <20120126112242.GN15110@legolas.emea.dhcp.ti.com> Hi, On Thu, Jan 26, 2012 at 12:21:03PM +0100, Tasslehoff Kjappfot wrote: > On 01/26/2012 11:45 AM, Felipe Balbi wrote: > >There's really no point in doing all that > >initcall trickery when we can safely let > >udev handle module probing for us. > > > >Remove all of that trickery, by moving everybody > >to module_init() and making proper use of > >platform_device_register() rather than > >platform_device_probe(). > > > >Signed-off-by: Felipe Balbi > >--- > > > > Tested-by: Tasslehoff Kjappfot Thanks, I have added this line to the commit. -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From tasskjapp at gmail.com Thu Jan 26 05:21:03 2012 From: tasskjapp at gmail.com (Tasslehoff Kjappfot) Date: Thu, 26 Jan 2012 12:21:03 +0100 Subject: [PATCH] usb: musb: make modules behave better In-Reply-To: <1327574749-18552-1-git-send-email-balbi@ti.com> References: <1327574749-18552-1-git-send-email-balbi@ti.com> Message-ID: <4F21371F.7010403@gmail.com> On 01/26/2012 11:45 AM, Felipe Balbi wrote: > There's really no point in doing all that > initcall trickery when we can safely let > udev handle module probing for us. > > Remove all of that trickery, by moving everybody > to module_init() and making proper use of > platform_device_register() rather than > platform_device_probe(). > > Signed-off-by: Felipe Balbi > --- > Tested-by: Tasslehoff Kjappfot > Because this falls into the "has never worked before" category > I will be sending this only on the next merge window. This > also gives people enough time to complain about any mistakes > on the patch. > > drivers/usb/musb/am35x.c | 11 ++++++----- > drivers/usb/musb/blackfin.c | 9 +++++---- > drivers/usb/musb/da8xx.c | 11 ++++++----- > drivers/usb/musb/davinci.c | 11 ++++++----- > drivers/usb/musb/musb_core.c | 15 ++++++--------- > drivers/usb/musb/omap2430.c | 11 ++++++----- > drivers/usb/musb/tusb6010.c | 11 ++++++----- > drivers/usb/musb/ux500.c | 11 ++++++----- > 8 files changed, 47 insertions(+), 43 deletions(-) > > diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c > index e233d2b..5285bda 100644 > --- a/drivers/usb/musb/am35x.c > +++ b/drivers/usb/musb/am35x.c > @@ -456,7 +456,7 @@ static const struct musb_platform_ops am35x_ops = { > > static u64 am35x_dmamask = DMA_BIT_MASK(32); > > -static int __init am35x_probe(struct platform_device *pdev) > +static int __devinit am35x_probe(struct platform_device *pdev) > { > struct musb_hdrc_platform_data *pdata = pdev->dev.platform_data; > struct platform_device *musb; > @@ -561,7 +561,7 @@ err0: > return ret; > } > > -static int __exit am35x_remove(struct platform_device *pdev) > +static int __devexit am35x_remove(struct platform_device *pdev) > { > struct am35x_glue *glue = platform_get_drvdata(pdev); > > @@ -630,7 +630,8 @@ static struct dev_pm_ops am35x_pm_ops = { > #endif > > static struct platform_driver am35x_driver = { > - .remove = __exit_p(am35x_remove), > + .probe = am35x_probe, > + .remove = __devexit_p(am35x_remove), > .driver = { > .name = "musb-am35x", > .pm = DEV_PM_OPS, > @@ -643,9 +644,9 @@ MODULE_LICENSE("GPL v2"); > > static int __init am35x_init(void) > { > - return platform_driver_probe(&am35x_driver, am35x_probe); > + return platform_driver_register(&am35x_driver); > } > -subsys_initcall(am35x_init); > +module_init(am35x_init); > > static void __exit am35x_exit(void) > { > diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c > index 5e7cfba..261af34 100644 > --- a/drivers/usb/musb/blackfin.c > +++ b/drivers/usb/musb/blackfin.c > @@ -463,7 +463,7 @@ static const struct musb_platform_ops bfin_ops = { > > static u64 bfin_dmamask = DMA_BIT_MASK(32); > > -static int __init bfin_probe(struct platform_device *pdev) > +static int __devinit bfin_probe(struct platform_device *pdev) > { > struct musb_hdrc_platform_data *pdata = pdev->dev.platform_data; > struct platform_device *musb; > @@ -525,7 +525,7 @@ err0: > return ret; > } > > -static int __exit bfin_remove(struct platform_device *pdev) > +static int __devexit bfin_remove(struct platform_device *pdev) > { > struct bfin_glue *glue = platform_get_drvdata(pdev); > > @@ -575,6 +575,7 @@ static struct dev_pm_ops bfin_pm_ops = { > #endif > > static struct platform_driver bfin_driver = { > + .probe = bfin_probe, > .remove = __exit_p(bfin_remove), > .driver = { > .name = "musb-blackfin", > @@ -588,9 +589,9 @@ MODULE_LICENSE("GPL v2"); > > static int __init bfin_init(void) > { > - return platform_driver_probe(&bfin_driver, bfin_probe); > + return platform_driver_register(&bfin_driver); > } > -subsys_initcall(bfin_init); > +module_init(bfin_init); > > static void __exit bfin_exit(void) > { > diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c > index 2613bfd..01c8f2e 100644 > --- a/drivers/usb/musb/da8xx.c > +++ b/drivers/usb/musb/da8xx.c > @@ -478,7 +478,7 @@ static const struct musb_platform_ops da8xx_ops = { > > static u64 da8xx_dmamask = DMA_BIT_MASK(32); > > -static int __init da8xx_probe(struct platform_device *pdev) > +static int __devinit da8xx_probe(struct platform_device *pdev) > { > struct musb_hdrc_platform_data *pdata = pdev->dev.platform_data; > struct platform_device *musb; > @@ -562,7 +562,7 @@ err0: > return ret; > } > > -static int __exit da8xx_remove(struct platform_device *pdev) > +static int __devexit da8xx_remove(struct platform_device *pdev) > { > struct da8xx_glue *glue = platform_get_drvdata(pdev); > > @@ -576,7 +576,8 @@ static int __exit da8xx_remove(struct platform_device *pdev) > } > > static struct platform_driver da8xx_driver = { > - .remove = __exit_p(da8xx_remove), > + .probe = da8xx_probe, > + .remove = __devexit_p(da8xx_remove), > .driver = { > .name = "musb-da8xx", > }, > @@ -588,9 +589,9 @@ MODULE_LICENSE("GPL v2"); > > static int __init da8xx_init(void) > { > - return platform_driver_probe(&da8xx_driver, da8xx_probe); > + return platform_driver_register(&da8xx_driver); > } > -subsys_initcall(da8xx_init); > +module_init(da8xx_init); > > static void __exit da8xx_exit(void) > { > diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c > index f9a3f62..7802c7e 100644 > --- a/drivers/usb/musb/davinci.c > +++ b/drivers/usb/musb/davinci.c > @@ -514,7 +514,7 @@ static const struct musb_platform_ops davinci_ops = { > > static u64 davinci_dmamask = DMA_BIT_MASK(32); > > -static int __init davinci_probe(struct platform_device *pdev) > +static int __devinit davinci_probe(struct platform_device *pdev) > { > struct musb_hdrc_platform_data *pdata = pdev->dev.platform_data; > struct platform_device *musb; > @@ -597,7 +597,7 @@ err0: > return ret; > } > > -static int __exit davinci_remove(struct platform_device *pdev) > +static int __devexit davinci_remove(struct platform_device *pdev) > { > struct davinci_glue *glue = platform_get_drvdata(pdev); > > @@ -611,7 +611,8 @@ static int __exit davinci_remove(struct platform_device *pdev) > } > > static struct platform_driver davinci_driver = { > - .remove = __exit_p(davinci_remove), > + .probe = davinci_probe, > + .remove = __devexit_p(davinci_remove), > .driver = { > .name = "musb-davinci", > }, > @@ -623,9 +624,9 @@ MODULE_LICENSE("GPL v2"); > > static int __init davinci_init(void) > { > - return platform_driver_probe(&davinci_driver, davinci_probe); > + return platform_driver_register(&davinci_driver); > } > -subsys_initcall(davinci_init); > +module_init(davinci_init); > > static void __exit davinci_exit(void) > { > diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c > index 6a92985..bd54470 100644 > --- a/drivers/usb/musb/musb_core.c > +++ b/drivers/usb/musb/musb_core.c > @@ -2072,7 +2072,7 @@ fail0: > static u64 *orig_dma_mask; > #endif > > -static int __init musb_probe(struct platform_device *pdev) > +static int __devinit musb_probe(struct platform_device *pdev) > { > struct device *dev =&pdev->dev; > int irq = platform_get_irq_byname(pdev, "mc"); > @@ -2101,7 +2101,7 @@ static int __init musb_probe(struct platform_device *pdev) > return status; > } > > -static int __exit musb_remove(struct platform_device *pdev) > +static int __devexit musb_remove(struct platform_device *pdev) > { > struct musb *musb = dev_to_musb(&pdev->dev); > void __iomem *ctrl_base = musb->ctrl_base; > @@ -2361,7 +2361,8 @@ static struct platform_driver musb_driver = { > .owner = THIS_MODULE, > .pm = MUSB_DEV_PM_OPS, > }, > - .remove = __exit_p(musb_remove), > + .probe = musb_probe, > + .remove = __devexit_p(musb_remove), > .shutdown = musb_shutdown, > }; > > @@ -2377,13 +2378,9 @@ static int __init musb_init(void) > ", " > "otg (peripheral+host)", > musb_driver_name); > - return platform_driver_probe(&musb_driver, musb_probe); > + return platform_driver_register(&musb_driver); > } > - > -/* make us init after usbcore and i2c (transceivers, regulators, etc) > - * and before usb gadget and host-side drivers start to register > - */ > -fs_initcall(musb_init); > +module_init(musb_init); > > static void __exit musb_cleanup(void) > { > diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c > index c27bbbf..b254173 100644 > --- a/drivers/usb/musb/omap2430.c > +++ b/drivers/usb/musb/omap2430.c > @@ -408,7 +408,7 @@ static const struct musb_platform_ops omap2430_ops = { > > static u64 omap2430_dmamask = DMA_BIT_MASK(32); > > -static int __init omap2430_probe(struct platform_device *pdev) > +static int __devinit omap2430_probe(struct platform_device *pdev) > { > struct musb_hdrc_platform_data *pdata = pdev->dev.platform_data; > struct platform_device *musb; > @@ -471,7 +471,7 @@ err0: > return ret; > } > > -static int __exit omap2430_remove(struct platform_device *pdev) > +static int __devexit omap2430_remove(struct platform_device *pdev) > { > struct omap2430_glue *glue = platform_get_drvdata(pdev); > > @@ -524,7 +524,8 @@ static struct dev_pm_ops omap2430_pm_ops = { > #endif > > static struct platform_driver omap2430_driver = { > - .remove = __exit_p(omap2430_remove), > + .probe = omap2430_probe, > + .remove = __devexit_p(omap2430_remove), > .driver = { > .name = "musb-omap2430", > .pm = DEV_PM_OPS, > @@ -537,9 +538,9 @@ MODULE_LICENSE("GPL v2"); > > static int __init omap2430_init(void) > { > - return platform_driver_probe(&omap2430_driver, omap2430_probe); > + return platform_driver_register(&omap2430_driver); > } > -subsys_initcall(omap2430_init); > +module_init(omap2430_init); > > static void __exit omap2430_exit(void) > { > diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c > index 1f40561..b387f12 100644 > --- a/drivers/usb/musb/tusb6010.c > +++ b/drivers/usb/musb/tusb6010.c > @@ -1165,7 +1165,7 @@ static const struct musb_platform_ops tusb_ops = { > > static u64 tusb_dmamask = DMA_BIT_MASK(32); > > -static int __init tusb_probe(struct platform_device *pdev) > +static int __devinit tusb_probe(struct platform_device *pdev) > { > struct musb_hdrc_platform_data *pdata = pdev->dev.platform_data; > struct platform_device *musb; > @@ -1227,7 +1227,7 @@ err0: > return ret; > } > > -static int __exit tusb_remove(struct platform_device *pdev) > +static int __devexit tusb_remove(struct platform_device *pdev) > { > struct tusb6010_glue *glue = platform_get_drvdata(pdev); > > @@ -1239,7 +1239,8 @@ static int __exit tusb_remove(struct platform_device *pdev) > } > > static struct platform_driver tusb_driver = { > - .remove = __exit_p(tusb_remove), > + .probe = tusb_probe, > + .remove = __devexit_p(tusb_remove), > .driver = { > .name = "musb-tusb", > }, > @@ -1251,9 +1252,9 @@ MODULE_LICENSE("GPL v2"); > > static int __init tusb_init(void) > { > - return platform_driver_probe(&tusb_driver, tusb_probe); > + return platform_driver_register(&tusb_driver); > } > -subsys_initcall(tusb_init); > +module_init(tusb_init); > > static void __exit tusb_exit(void) > { > diff --git a/drivers/usb/musb/ux500.c b/drivers/usb/musb/ux500.c > index f7e04bf..bcfc48f 100644 > --- a/drivers/usb/musb/ux500.c > +++ b/drivers/usb/musb/ux500.c > @@ -58,7 +58,7 @@ static const struct musb_platform_ops ux500_ops = { > .exit = ux500_musb_exit, > }; > > -static int __init ux500_probe(struct platform_device *pdev) > +static int __devinit ux500_probe(struct platform_device *pdev) > { > struct musb_hdrc_platform_data *pdata = pdev->dev.platform_data; > struct platform_device *musb; > @@ -141,7 +141,7 @@ err0: > return ret; > } > > -static int __exit ux500_remove(struct platform_device *pdev) > +static int __devexit ux500_remove(struct platform_device *pdev) > { > struct ux500_glue *glue = platform_get_drvdata(pdev); > > @@ -194,7 +194,8 @@ static const struct dev_pm_ops ux500_pm_ops = { > #endif > > static struct platform_driver ux500_driver = { > - .remove = __exit_p(ux500_remove), > + .probe = ux500_probe, > + .remove = __devexit_p(ux500_remove), > .driver = { > .name = "musb-ux500", > .pm = DEV_PM_OPS, > @@ -207,9 +208,9 @@ MODULE_LICENSE("GPL v2"); > > static int __init ux500_init(void) > { > - return platform_driver_probe(&ux500_driver, ux500_probe); > + return platform_driver_register(&ux500_driver); > } > -subsys_initcall(ux500_init); > +module_init(ux500_init); > > static void __exit ux500_exit(void) > { From scottwood at freescale.com Thu Jan 26 14:33:48 2012 From: scottwood at freescale.com (Scott Wood) Date: Thu, 26 Jan 2012 14:33:48 -0600 Subject: [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller In-Reply-To: <4F1FAAAE.2060007@denx.de> References: <1327308967-8092-1-git-send-email-hs@denx.de> <1327308967-8092-7-git-send-email-hs@denx.de> <4F1DF465.60206@freescale.com> <4F1E5C82.60108@denx.de> <4F1F0A3E.40805@freescale.com> <4F1FAAAE.2060007@denx.de> Message-ID: <4F21B8AC.40002@freescale.com> On 01/25/2012 01:09 AM, Heiko Schocher wrote: > Scott Wood wrote: > I found the following used options: > > ecc_mode: > NAND_ECC_NONE > NAND_ECC_SOFT > NAND_ECC_HW > NAND_ECC_HW_SYNDROME > > bbt_options: > NAND_BBT_USE_FLASH > > ecc_bits: > 1 > 4 > > options: > NAND_BUSWIDTH_16 > >>>> Do all of these properties really belong here? I can see providing some >>> I think so, because this values come from existing platform code >>> (grep for struct davinci_nand_pdata) >> >> The standards are a bit stricter for the device tree, since it's a more >> stable interface across components -- at least that's how we've used it >> on a lot of powerpc targets. I'm not sure if that's the intent here, >> but I have seen U-Boot patches for ARM hardware using them as well. > > Ok, so, should I introduce instead properties for the above > needed parameters? Yes. > (As this are not davinci specific parameters, are there somewhere such definitions for them?) It's controller-specific which options are changeable, and whether there's a better source of information. Most controllers don't seem to need this. I'd keep the definitions davinci specific for now. If there's enough of a common need, a common definition could be considered. -Scott From linux at arm.linux.org.uk Thu Jan 26 15:23:19 2012 From: linux at arm.linux.org.uk (Russell King - ARM Linux) Date: Thu, 26 Jan 2012 21:23:19 +0000 Subject: ARM/ARM-SoC plans for v3.4 merge window In-Reply-To: <20120124095009.GS16726@n2100.arm.linux.org.uk> References: <20120123114902.GY1068@n2100.arm.linux.org.uk> <20120124095009.GS16726@n2100.arm.linux.org.uk> Message-ID: <20120126212319.GE11941@n2100.arm.linux.org.uk> On Tue, Jan 24, 2012 at 09:50:09AM +0000, Russell King - ARM Linux wrote: > On Mon, Jan 23, 2012 at 11:49:02AM +0000, Russell King - ARM Linux wrote: > > This is an outline of the plan for this cycle, up to the next merge > > window, agreed between Olof and myself. > > > > As Nicolas' idle changes weren't merged before the last merge window > > opened, we have decided that Nicolas will resubmit his changes after > > -rc1 (in other words, now) and they will be merged into both the > > arm-soc and my trees. > > > > I have at least one other patch which has a high 'will cause horrible > > conficts' rating (the debug option rearrangement patch), so I'll be > > including that for the arm-soc tree as well. > > > > However, what this does mean is that Arnd, Olof, and myself will be > > in for up to three months of merge hell unless people take account of > > these changes. > > > > Therefore, our plan is to publish this as a baseline, and we'd really > > appreciate any development submitted after that baseline has been > > established is based upon those changes and does not conflict with > > them. That may mean you have to pull these changes into your tree > > and merge them into your development work (and fix up any conflicts > > there yourself.) > > > > Once you've taken these changes into your tree, you must not rebase or > > modify them. Changing those commits will cause all hell to break loose, > > and we'll have to refuse merging your tree (otherwise we'll be in Linus' > > sights for a roasting at gas mark 2 million.) > > Right, although it's out there - but I'd like to get the AMBA changes > into it which are already conflicting the Samsung development. So I'm > going to hold off officially asking for people to include the baseline > until this evening. At that point, I will shut down my 'amba' branch > and transfer that over; that means I won't be accepting any further > acks etc for that work. > > If you haven't acked changes in the amba branch (eg, to Versatile, > Realview etc) then it'll soon be too late... And we're now there. So... Arnd, Olaf, Please incorporate the latest ARM (for-armsoc branch) changes, which can be found at: git://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-arm.git for-armsoc with SHA1 dcf81c1af839b77b44404453ecae6e5ac5a75f05. This will update the following files: arch/arm/Kconfig.debug | 156 ++++++++++---------- arch/arm/include/asm/system.h | 1 + arch/arm/kernel/process.c | 27 ++-- arch/arm/mach-at91/at91cap9.c | 8 + arch/arm/mach-at91/at91rm9200.c | 10 ++ arch/arm/mach-at91/at91sam9260.c | 8 + arch/arm/mach-at91/at91sam9261.c | 8 + arch/arm/mach-at91/at91sam9263.c | 8 + arch/arm/mach-at91/at91sam9g45.c | 7 + arch/arm/mach-at91/at91sam9rl.c | 8 + arch/arm/mach-at91/at91x40.c | 12 ++ arch/arm/mach-at91/include/mach/system.h | 50 ------- arch/arm/mach-bcmring/core.c | 23 +--- arch/arm/mach-bcmring/include/mach/system.h | 28 ---- arch/arm/mach-clps711x/common.c | 16 ++ arch/arm/mach-clps711x/include/mach/system.h | 35 ----- arch/arm/mach-cns3xxx/include/mach/system.h | 25 ---- arch/arm/mach-davinci/include/mach/system.h | 21 --- arch/arm/mach-dove/include/mach/system.h | 17 --- arch/arm/mach-ebsa110/core.c | 25 ++++ arch/arm/mach-ebsa110/include/mach/system.h | 37 ----- arch/arm/mach-ep93xx/core.c | 46 +------ arch/arm/mach-ep93xx/include/mach/system.h | 7 - arch/arm/mach-exynos/common.c | 12 -- arch/arm/mach-exynos/dma.c | 38 +----- arch/arm/mach-exynos/include/mach/system.h | 20 --- arch/arm/mach-footbridge/include/mach/system.h | 13 -- arch/arm/mach-gemini/Makefile | 2 +- arch/arm/mach-gemini/idle.c | 29 ++++ arch/arm/mach-gemini/include/mach/system.h | 14 -- arch/arm/mach-gemini/irq.c | 4 +- arch/arm/mach-h720x/common.c | 18 +++ arch/arm/mach-h720x/include/mach/system.h | 27 ---- arch/arm/mach-highbank/include/mach/system.h | 24 --- arch/arm/mach-imx/mm-imx3.c | 52 ++++---- arch/arm/mach-imx/pm-imx27.c | 3 +- arch/arm/mach-integrator/core.c | 70 ++-------- arch/arm/mach-integrator/impd1.c | 9 +- arch/arm/mach-integrator/include/mach/system.h | 33 ----- arch/arm/mach-integrator/integrator_cp.c | 49 ++------ arch/arm/mach-iop13xx/include/mach/system.h | 13 -- arch/arm/mach-iop32x/include/mach/system.h | 13 -- arch/arm/mach-iop33x/include/mach/system.h | 13 -- arch/arm/mach-ixp2000/include/mach/system.h | 14 -- arch/arm/mach-ixp23xx/core.c | 3 + arch/arm/mach-ixp23xx/include/mach/system.h | 16 -- arch/arm/mach-ixp4xx/common.c | 6 + arch/arm/mach-ixp4xx/include/mach/system.h | 19 --- arch/arm/mach-kirkwood/include/mach/system.h | 17 --- arch/arm/mach-ks8695/include/mach/system.h | 27 ---- arch/arm/mach-lpc32xx/include/mach/system.h | 27 ---- arch/arm/mach-lpc32xx/phy3250.c | 32 +---- arch/arm/mach-mmp/include/mach/system.h | 16 -- arch/arm/mach-msm/idle.S | 36 ----- arch/arm/mach-msm/idle.c | 49 +++++++ arch/arm/mach-msm/include/mach/system.h | 1 - arch/arm/mach-mv78xx0/include/mach/system.h | 17 --- arch/arm/mach-mx5/mm.c | 28 ++--- arch/arm/mach-mxs/devices.c | 8 +- arch/arm/mach-mxs/devices/amba-duart.c | 2 +- arch/arm/mach-mxs/include/mach/system.h | 25 ---- arch/arm/mach-mxs/pm.c | 3 +- arch/arm/mach-netx/fb.c | 13 +-- arch/arm/mach-netx/include/mach/system.h | 28 ---- arch/arm/mach-nomadik/board-nhk8815.c | 17 +-- arch/arm/mach-nomadik/cpu-8815.c | 9 +- arch/arm/mach-nomadik/include/mach/system.h | 32 ----- arch/arm/mach-omap1/include/mach/system.h | 5 - arch/arm/mach-omap1/pm.c | 19 +-- arch/arm/mach-omap2/emu.c | 26 +--- arch/arm/mach-omap2/include/mach/system.h | 5 - arch/arm/mach-omap2/pm24xx.c | 4 +- arch/arm/mach-omap2/pm34xx.c | 6 +- arch/arm/mach-omap2/pm44xx.c | 8 +- arch/arm/mach-omap2/prm_common.c | 1 - arch/arm/mach-orion5x/include/mach/system.h | 19 --- arch/arm/mach-picoxcell/include/mach/system.h | 26 ---- arch/arm/mach-pnx4008/include/mach/system.h | 29 ---- arch/arm/mach-prima2/include/mach/system.h | 17 --- arch/arm/mach-pxa/include/mach/system.h | 15 -- arch/arm/mach-realview/core.h | 20 +-- arch/arm/mach-realview/include/mach/irqs-pb1176.h | 2 +- arch/arm/mach-realview/include/mach/system.h | 33 ----- arch/arm/mach-realview/realview_eb.c | 78 +++++----- arch/arm/mach-realview/realview_pb1176.c | 78 +++++----- arch/arm/mach-realview/realview_pb11mp.c | 78 +++++----- arch/arm/mach-realview/realview_pba8.c | 78 +++++----- arch/arm/mach-realview/realview_pbx.c | 78 +++++----- arch/arm/mach-rpc/include/mach/system.h | 13 -- arch/arm/mach-s3c2410/include/mach/system.h | 54 ------- arch/arm/mach-s3c2412/s3c2412.c | 4 +- arch/arm/mach-s3c2416/s3c2416.c | 3 - arch/arm/mach-s3c64xx/include/mach/system.h | 19 --- arch/arm/mach-s5p64x0/common.c | 15 +-- arch/arm/mach-s5p64x0/dma.c | 22 +--- arch/arm/mach-s5p64x0/include/mach/system.h | 21 --- arch/arm/mach-s5pc100/common.c | 12 -- arch/arm/mach-s5pc100/dma.c | 38 +----- arch/arm/mach-s5pc100/include/mach/system.h | 19 --- arch/arm/mach-s5pv210/common.c | 12 -- arch/arm/mach-s5pv210/dma.c | 38 +----- arch/arm/mach-s5pv210/include/mach/system.h | 21 --- arch/arm/mach-sa1100/include/mach/system.h | 9 -- arch/arm/mach-shark/core.c | 6 + arch/arm/mach-shark/include/mach/system.h | 13 -- arch/arm/mach-shmobile/include/mach/system.h | 5 - arch/arm/mach-spear3xx/include/mach/system.h | 19 --- arch/arm/mach-spear3xx/spear300.c | 14 +-- arch/arm/mach-spear3xx/spear3xx.c | 27 +--- arch/arm/mach-spear6xx/include/mach/system.h | 19 --- arch/arm/mach-spear6xx/spear6xx.c | 10 +- arch/arm/mach-tegra/common.c | 3 +- arch/arm/mach-tegra/include/mach/system.h | 28 ---- arch/arm/mach-u300/core.c | 85 ++--------- arch/arm/mach-u300/include/mach/system.h | 14 -- arch/arm/mach-ux500/devices-common.c | 13 +-- arch/arm/mach-ux500/include/mach/system.h | 20 --- arch/arm/mach-versatile/core.c | 70 +++++----- arch/arm/mach-versatile/core.h | 20 +-- arch/arm/mach-versatile/include/mach/system.h | 33 ----- arch/arm/mach-versatile/versatile_pb.c | 18 ++-- arch/arm/mach-vexpress/core.h | 17 --- arch/arm/mach-vexpress/ct-ca9x4.c | 8 +- arch/arm/mach-vexpress/include/mach/ct-ca9x4.h | 2 +- arch/arm/mach-vexpress/include/mach/system.h | 33 ----- arch/arm/mach-vexpress/v2m.c | 20 ++-- arch/arm/mach-vt8500/include/mach/system.h | 5 - arch/arm/mach-w90x900/dev.c | 1 + arch/arm/mach-w90x900/include/mach/system.h | 19 --- arch/arm/mach-zynq/include/mach/system.h | 23 --- arch/arm/plat-mxc/include/mach/system.h | 25 ---- arch/arm/plat-omap/include/plat/system.h | 15 -- arch/arm/plat-s3c24xx/cpu.c | 27 ++++ arch/arm/plat-spear/include/plat/system.h | 26 ---- drivers/amba/bus.c | 105 +++++++++++---- drivers/mmc/host/mmci.c | 2 +- drivers/of/platform.c | 6 +- include/linux/amba/bus.h | 36 +++++ 138 files changed, 893 insertions(+), 2303 deletions(-) delete mode 100644 arch/arm/mach-at91/include/mach/system.h delete mode 100644 arch/arm/mach-bcmring/include/mach/system.h delete mode 100644 arch/arm/mach-clps711x/include/mach/system.h delete mode 100644 arch/arm/mach-cns3xxx/include/mach/system.h delete mode 100644 arch/arm/mach-davinci/include/mach/system.h delete mode 100644 arch/arm/mach-dove/include/mach/system.h delete mode 100644 arch/arm/mach-ebsa110/include/mach/system.h delete mode 100644 arch/arm/mach-ep93xx/include/mach/system.h delete mode 100644 arch/arm/mach-exynos/include/mach/system.h delete mode 100644 arch/arm/mach-footbridge/include/mach/system.h create mode 100644 arch/arm/mach-gemini/idle.c delete mode 100644 arch/arm/mach-h720x/include/mach/system.h delete mode 100644 arch/arm/mach-highbank/include/mach/system.h delete mode 100644 arch/arm/mach-integrator/include/mach/system.h delete mode 100644 arch/arm/mach-iop13xx/include/mach/system.h delete mode 100644 arch/arm/mach-iop32x/include/mach/system.h delete mode 100644 arch/arm/mach-iop33x/include/mach/system.h delete mode 100644 arch/arm/mach-ixp2000/include/mach/system.h delete mode 100644 arch/arm/mach-ixp23xx/include/mach/system.h delete mode 100644 arch/arm/mach-ixp4xx/include/mach/system.h delete mode 100644 arch/arm/mach-kirkwood/include/mach/system.h delete mode 100644 arch/arm/mach-ks8695/include/mach/system.h delete mode 100644 arch/arm/mach-lpc32xx/include/mach/system.h delete mode 100644 arch/arm/mach-mmp/include/mach/system.h delete mode 100644 arch/arm/mach-msm/idle.S create mode 100644 arch/arm/mach-msm/idle.c delete mode 100644 arch/arm/mach-mv78xx0/include/mach/system.h delete mode 100644 arch/arm/mach-mxs/include/mach/system.h delete mode 100644 arch/arm/mach-netx/include/mach/system.h delete mode 100644 arch/arm/mach-nomadik/include/mach/system.h delete mode 100644 arch/arm/mach-omap1/include/mach/system.h delete mode 100644 arch/arm/mach-omap2/include/mach/system.h delete mode 100644 arch/arm/mach-orion5x/include/mach/system.h delete mode 100644 arch/arm/mach-picoxcell/include/mach/system.h delete mode 100644 arch/arm/mach-pnx4008/include/mach/system.h delete mode 100644 arch/arm/mach-prima2/include/mach/system.h delete mode 100644 arch/arm/mach-pxa/include/mach/system.h delete mode 100644 arch/arm/mach-realview/include/mach/system.h delete mode 100644 arch/arm/mach-rpc/include/mach/system.h delete mode 100644 arch/arm/mach-s3c2410/include/mach/system.h delete mode 100644 arch/arm/mach-s3c64xx/include/mach/system.h delete mode 100644 arch/arm/mach-s5p64x0/include/mach/system.h delete mode 100644 arch/arm/mach-s5pc100/include/mach/system.h delete mode 100644 arch/arm/mach-s5pv210/include/mach/system.h delete mode 100644 arch/arm/mach-sa1100/include/mach/system.h delete mode 100644 arch/arm/mach-shark/include/mach/system.h delete mode 100644 arch/arm/mach-spear3xx/include/mach/system.h delete mode 100644 arch/arm/mach-spear6xx/include/mach/system.h delete mode 100644 arch/arm/mach-tegra/include/mach/system.h delete mode 100644 arch/arm/mach-u300/include/mach/system.h delete mode 100644 arch/arm/mach-ux500/include/mach/system.h delete mode 100644 arch/arm/mach-versatile/include/mach/system.h delete mode 100644 arch/arm/mach-vexpress/include/mach/system.h delete mode 100644 arch/arm/mach-w90x900/include/mach/system.h delete mode 100644 arch/arm/mach-zynq/include/mach/system.h delete mode 100644 arch/arm/plat-mxc/include/mach/system.h delete mode 100644 arch/arm/plat-omap/include/plat/system.h delete mode 100644 arch/arm/plat-spear/include/plat/system.h through these changes: Nicolas Pitre (23): ARM: OMAP1: Fix pm_idle during suspend ARM: clean up idle handlers ARM: OMAP: convert idle handlers from pm_idle to arm_pm_idle ARM: mach-s5pv210: use standard arch_idle() ARM: mach-s5pc100: use standard arch_idle() ARM: mach-s5p64x0: move idle handler from pm_idle to arm_pm_idle ARM: mach-exynos: use standard arch_idle() ARM: mach-at91: move special idle code out of line ARM: mach-clps711x: move special idle code out of line ARM: mach-ebsa110: move special idle code out of line ARM: mach-gemini: move special idle code out of line ARM: mach-h720x: move special idle code out of line ARM: s3c24xx: move special idle code to out of line ARM: plat-mxc: hook special idle handlers to arm_pm_idle ARM: mach-msm: hook special idle handlers to arm_pm_idle ARM: mach-ixp23xx: properly disable CPU idle call ARM: mach-ixp4xx: properly disable CPU idle call ARM: mach-shark: properly disable CPU idle call ARM: mach-w90x900: properly disable CPU idle call ARM: mach-s3c64xx: use standard arch_idle() implementation ARM: mach-tegra: properly disable CPU idle call ARM: substitute arch_idle() ARM: big removal of now unused arch_idle() Russell King (34): ARM: debug: arrange Kconfig options more logically Merge branches 'debug' and 'idle' into for-armsoc ARM: amba: add amba_device allocation/add/put functions ARM: amba: of: convert to use amba_device_alloc ARM: amba: ux500: convert to use amba_device_alloc ARM: amba: integrator: convert to use amba_device_alloc ARM: amba: mxs: convert to use amba_device_alloc ARM: amba: make irq 0 invalid ARM: amba: ux500: get rid of NO_IRQ ARM: amba: get rid of NO_IRQ initializers ARM: amba: samsung: get rid of NO_IRQ initializers ARM: amba: integrator/realview/versatile/vexpress: get rid of NO_IRQ initializers ARM: amba: lpc32xx: get rid of NO_IRQ initializers ARM: amba: mxs: get rid of NO_IRQ initializers ARM: amba: nomadik: get rid of NO_IRQ initializers ARM: amba: netx: get rid of NO_IRQ initializers ARM: amba: spear: get rid of NO_IRQ initializers ARM: amba: u300: get rid of NO_IRQ initializers ARM: amba: make use of -1 IRQs warn ARM: amba: provide common initializers for static amba devices ARM: amba: vexpress: get rid of private platform amba_device initializer ARM: amba: versatile: get rid of private platform amba_device initializer ARM: amba: realview: get rid of private platform amba_device initializer ARM: amba: integrator: use common amba device initializers ARM: amba: omap2: use common amba device initializers ARM: amba: ep93xx: use common amba device initializers ARM: amba: bcmring: use common amba device initializers ARM: amba: netx: use common amba device initializers ARM: amba: lpc32xx: use common amba device initializers ARM: amba: u300: use common amba device initializers ARM: amba: nomadik: use common amba device initializers ARM: amba: spear: use common amba device initializers ARM: amba: samsung: use common amba device initializers Merge branch 'amba' into for-armsoc Will Deacon (1): ARM: 7300/1: realview: fix definition of GPIO0 interrupt on PB1176 to match TRM Thanks. From hs at denx.de Fri Jan 27 00:40:00 2012 From: hs at denx.de (Heiko Schocher) Date: Fri, 27 Jan 2012 07:40:00 +0100 Subject: [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller In-Reply-To: <4F21B8AC.40002@freescale.com> References: <1327308967-8092-1-git-send-email-hs@denx.de> <1327308967-8092-7-git-send-email-hs@denx.de> <4F1DF465.60206@freescale.com> <4F1E5C82.60108@denx.de> <4F1F0A3E.40805@freescale.com> <4F1FAAAE.2060007@denx.de> <4F21B8AC.40002@freescale.com> Message-ID: <4F2246C0.6020905@denx.de> Hello Scott, Scott Wood wrote: > On 01/25/2012 01:09 AM, Heiko Schocher wrote: >> Scott Wood wrote: >> I found the following used options: >> >> ecc_mode: >> NAND_ECC_NONE >> NAND_ECC_SOFT >> NAND_ECC_HW >> NAND_ECC_HW_SYNDROME >> >> bbt_options: >> NAND_BBT_USE_FLASH >> >> ecc_bits: >> 1 >> 4 >> >> options: >> NAND_BUSWIDTH_16 >> >>>>> Do all of these properties really belong here? I can see providing some >>>> I think so, because this values come from existing platform code >>>> (grep for struct davinci_nand_pdata) >>> The standards are a bit stricter for the device tree, since it's a more >>> stable interface across components -- at least that's how we've used it >>> on a lot of powerpc targets. I'm not sure if that's the intent here, >>> but I have seen U-Boot patches for ARM hardware using them as well. >> Ok, so, should I introduce instead properties for the above >> needed parameters? > > Yes. Ok, I change this. >> (As this are not davinci specific parameters, are there somewhere such definitions for them?) > > It's controller-specific which options are changeable, and whether > there's a better source of information. Most controllers don't seem to > need this. I'd keep the definitions davinci specific for now. If > there's enough of a common need, a common definition could be considered. Ok, a proposal for the properties names and values: >> ecc_mode: >> NAND_ECC_NONE >> NAND_ECC_SOFT >> NAND_ECC_HW >> NAND_ECC_HW_SYNDROME "ti,davinci-nand-ecc-mode" = "none", "soft", "hw" or "hw_syndrome" >> bbt_options: >> NAND_BBT_USE_FLASH "ti,davinci-nand-bbt-options" = "use_flash" >> ecc_bits: >> 1 >> 4 "ti,davinci-nand-ecc-bits" = "1" or "4" >> options: >> NAND_BUSWIDTH_16 "ti,davinci-nand-options" = "buswidth-16" bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany From sudhakar.raj at ti.com Fri Jan 27 02:11:55 2012 From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar) Date: Fri, 27 Jan 2012 08:11:55 +0000 Subject: [RFC 1/2] mmc: davinci: Eliminate spurious interrupts In-Reply-To: <1327403766-962-1-git-send-email-ido@wizery.com> References: <4F1E9194.90608@mvista.com> <1327403766-962-1-git-send-email-ido@wizery.com> Message-ID: Hello Ido, On Tue, Jan 24, 2012 at 16:46:05, Ido Yariv wrote: > The davinci mmc interrupt handler fills the fifo, as long as the DXRDY > or DRRDY bits are set in the status register. > > If interrupts fire during this loop, they will be handled by the > handler, but the interrupt controller will still buffer these. As a > result, the handler will be called again to serve these needlessly. In > order to avoid these spurious interrupts, keep interrupts masked while > filling the fifo. > I tested both these patches and they work fine on the OMAP-L138 EVM. I observed that with these patches the number of interrupts during a transfer are less compared to earlier. For a 100 MB transfer, I could see around 700-800 interrupts less. Did you see any performance improvement with these patches? Thanks, Sudhakar From manjunath.hadli at ti.com Fri Jan 27 04:12:59 2012 From: manjunath.hadli at ti.com (Hadli, Manjunath) Date: Fri, 27 Jan 2012 10:12:59 +0000 Subject: [GIT PULL] davinci vpif pull request Message-ID: Hi Mauro, Can you please pull the following patch for v3.3-rc1 which removes some unnecessary inclusion of machine specific header files from the main driver files? This patch has undergone sufficient review already. It is just a cleanup patch and I don't expect any functionality to break because of this. Thanks and Regards, -Manju The following changes since commit 74ea15d909b31158f9b63190a95b52bc05586d4b: Linus Torvalds (1): Merge branch 'v4l_for_linus' of git://git.kernel.org/.../mchehab/linux-media are available in the git repository at: git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for-mauro-v3.3 Manjunath Hadli (1): davinci: vpif: remove machine specific header file inclusion from the driver drivers/media/video/davinci/vpif.h | 2 -- drivers/media/video/davinci/vpif_display.c | 2 -- include/media/davinci/vpif_types.h | 2 ++ 3 files changed, 2 insertions(+), 4 deletions(-) From nsekhar at ti.com Fri Jan 27 07:19:42 2012 From: nsekhar at ti.com (Nori, Sekhar) Date: Fri, 27 Jan 2012 13:19:42 +0000 Subject: DaVinci unbanked GPIO IRQs broken In-Reply-To: References: <70E876B0EA86DD4BAF101844BC814DFE0BF403DA89@Cloud.RL.local> Message-ID: Hi Jon, On Tue, Jan 17, 2012 at 15:32:23, Nori, Sekhar wrote: > I was able to reproduce this on the EVM using v2.6.38 (works) > and v3.2 + my patch (doesn't work). I just started poking some > registers to see what is happening. Will keep you updated > on any progress. > Following patch fixes the issue of interrupt handler not getting called. I tested it using GPIO3 on DM365. On applying this, I see a constant rate of 4-5 interrupts per second on that line. Yet to figure out what is triggering those. Anyway I will wait for you to test this after you are back before sending this to Grant. Thanks, Sekhar ------8<--------- From: Sekhar Nori Date: Fri, 27 Jan 2012 00:31:54 +0530 Subject: [PATCH] gpio/davinci: fix enabling of unbanked GPIO IRQs Unbanked GPIO IRQ handling code made a copy of just the irq_chip structure for GPIO IRQ lines which caused problems after the generic IRQ chip conversion because there was no valid irq_chip_type structure with the right "regs" populated. irq_gc_mask_set_bit() was therefore accessing random addresses. Fix it by making a copy of irq_chip_type structure instead. This will ensure sane register offsets. Reported-by: Jon Povey Signed-off-by: Sekhar Nori --- drivers/gpio/gpio-davinci.c | 11 ++++++----- 1 files changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c index a6777e5..3d00016 100644 --- a/drivers/gpio/gpio-davinci.c +++ b/drivers/gpio/gpio-davinci.c @@ -386,7 +386,7 @@ static int __init davinci_gpio_irq_setup(void) * IRQ mux conflicts; gpio_irq_type_unbanked() is only for GPIOs. */ if (soc_info->gpio_unbanked) { - static struct irq_chip gpio_irqchip_unbanked; + static struct irq_chip_type gpio_unbanked; /* pass "bank 0" GPIO IRQs to AINTC */ chips[0].chip.to_irq = gpio_to_irq_unbanked; @@ -394,9 +394,10 @@ static int __init davinci_gpio_irq_setup(void) /* AINTC handles mask/unmask; GPIO handles triggering */ irq = bank_irq; - gpio_irqchip_unbanked = *irq_get_chip(irq); - gpio_irqchip_unbanked.name = "GPIO-AINTC"; - gpio_irqchip_unbanked.irq_set_type = gpio_irq_type_unbanked; + gpio_unbanked = *container_of(irq_get_chip(irq), + struct irq_chip_type, chip); + gpio_unbanked.chip.name = "GPIO-AINTC"; + gpio_unbanked.chip.irq_set_type = gpio_irq_type_unbanked; /* default trigger: both edges */ g = gpio2regs(0); @@ -405,7 +406,7 @@ static int __init davinci_gpio_irq_setup(void) /* set the direct IRQs up to use that irqchip */ for (gpio = 0; gpio < soc_info->gpio_unbanked; gpio++, irq++) { - irq_set_chip(irq, &gpio_irqchip_unbanked); + irq_set_chip(irq, &gpio_unbanked.chip); irq_set_handler_data(irq, &chips[gpio / 32]); irq_set_status_flags(irq, IRQ_TYPE_EDGE_BOTH); } From nsekhar at ti.com Fri Jan 27 10:09:50 2012 From: nsekhar at ti.com (Sekhar Nori) Date: Fri, 27 Jan 2012 21:39:50 +0530 Subject: [PATCH 1/2] MAINTAINERS: mark DaVinci list as "moderated" Message-ID: <1327680591-15362-1-git-send-email-nsekhar@ti.com> DaVinci list is moderated for non-subscribers instead of being "subscribers-only". Fix this. Without this the DaVinci list does not show up by default with get_maintainer.pl Signed-off-by: Sekhar Nori --- MAINTAINERS | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 89b70df..ae16106 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5977,7 +5977,7 @@ F: arch/arm/mach-s3c2410/bast-irq.c TI DAVINCI MACHINE SUPPORT M: Sekhar Nori M: Kevin Hilman -L: davinci-linux-open-source at linux.davincidsp.com (subscribers-only) +L: davinci-linux-open-source at linux.davincidsp.com (moderated for non-subscribers) Q: http://patchwork.kernel.org/project/linux-davinci/list/ S: Supported F: arch/arm/mach-davinci -- 1.7.0.4 From nsekhar at ti.com Fri Jan 27 10:09:51 2012 From: nsekhar at ti.com (Sekhar Nori) Date: Fri, 27 Jan 2012 21:39:51 +0530 Subject: [PATCH 2/2] MAINTAINERS: add information on DaVinci tree In-Reply-To: <1327680591-15362-1-git-send-email-nsekhar@ti.com> References: <1327680591-15362-1-git-send-email-nsekhar@ti.com> Message-ID: <1327680591-15362-2-git-send-email-nsekhar@ti.com> Add information on DaVinci git tree to MAINTAINERS file. Signed-off-by: Sekhar Nori --- MAINTAINERS | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index ae16106..d677547 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5978,6 +5978,7 @@ TI DAVINCI MACHINE SUPPORT M: Sekhar Nori M: Kevin Hilman L: davinci-linux-open-source at linux.davincidsp.com (moderated for non-subscribers) +T: git git://gitorious.org/linux-davinci/linux-davinci.git Q: http://patchwork.kernel.org/project/linux-davinci/list/ S: Supported F: arch/arm/mach-davinci -- 1.7.0.4 From sudhakar.raj at ti.com Fri Jan 27 10:21:58 2012 From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar) Date: Fri, 27 Jan 2012 16:21:58 +0000 Subject: [PATCH] usb: musb: make modules behave better In-Reply-To: <1327574749-18552-1-git-send-email-balbi@ti.com> References: <1327574749-18552-1-git-send-email-balbi@ti.com> Message-ID: Hello, On Thu, Jan 26, 2012 at 16:15:49, Balbi, Felipe wrote: > There's really no point in doing all that > initcall trickery when we can safely let > udev handle module probing for us. > > Remove all of that trickery, by moving everybody > to module_init() and making proper use of > platform_device_register() rather than > platform_device_probe(). > > Signed-off-by: Felipe Balbi > --- > Tested on DM644x EVM. Tested-by: Rajashekhara, Sudhakar Thanks, Sudhakar From scottwood at freescale.com Fri Jan 27 11:02:51 2012 From: scottwood at freescale.com (Scott Wood) Date: Fri, 27 Jan 2012 11:02:51 -0600 Subject: [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller In-Reply-To: <4F2246C0.6020905@denx.de> References: <1327308967-8092-1-git-send-email-hs@denx.de> <1327308967-8092-7-git-send-email-hs@denx.de> <4F1DF465.60206@freescale.com> <4F1E5C82.60108@denx.de> <4F1F0A3E.40805@freescale.com> <4F1FAAAE.2060007@denx.de> <4F21B8AC.40002@freescale.com> <4F2246C0.6020905@denx.de> Message-ID: <4F22D8BB.6090801@freescale.com> On 01/27/2012 12:40 AM, Heiko Schocher wrote: > Hello Scott, > > Scott Wood wrote: >> On 01/25/2012 01:09 AM, Heiko Schocher wrote: >>> ecc_mode: >>> NAND_ECC_NONE >>> NAND_ECC_SOFT >>> NAND_ECC_HW >>> NAND_ECC_HW_SYNDROME > > "ti,davinci-nand-ecc-mode" = "none", "soft", "hw" or "hw_syndrome" OK. >>> bbt_options: >>> NAND_BBT_USE_FLASH > > "ti,davinci-nand-bbt-options" = "use_flash" Just make it a boolean ti,davinci-nand-use-bbt >>> ecc_bits: >>> 1 >>> 4 > > "ti,davinci-nand-ecc-bits" = "1" or "4" <1> or <4> >>> options: >>> NAND_BUSWIDTH_16 > > "ti,davinci-nand-options" = "buswidth-16" ti,davinci-nand-buswidth = <16>; -Scott From nsekhar at ti.com Fri Jan 27 11:26:17 2012 From: nsekhar at ti.com (Nori, Sekhar) Date: Fri, 27 Jan 2012 17:26:17 +0000 Subject: [GIT PULL] DaVinci fixes for v3.3-rc Message-ID: Hi Olof, Arnd, Can you please pull these DaVinci fixes for the next v3.3-rc? Both the patches have not been stable tagged. The fix by me is a v3.3 regression. The fix by Bas van den Berg is not critical enough to get into stable kernels. Thanks, Sekhar The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f: Linus Torvalds (1): Linux 3.3-rc1 are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git fixes Bas van den Berg (1): ARM: davinci: DA850: remove non-existing pll1_sysclk4-7 clocks Sekhar Nori (1): ARM: davinci: update mdio bus name arch/arm/mach-davinci/board-da850-evm.c | 2 +- arch/arm/mach-davinci/board-dm365-evm.c | 2 +- arch/arm/mach-davinci/board-dm644x-evm.c | 2 +- arch/arm/mach-davinci/board-dm646x-evm.c | 2 +- arch/arm/mach-davinci/board-neuros-osd2.c | 2 +- arch/arm/mach-davinci/board-omapl138-hawk.c | 2 +- arch/arm/mach-davinci/board-sffsdr.c | 2 +- arch/arm/mach-davinci/da850.c | 32 --------------------------- 8 files changed, 7 insertions(+), 39 deletions(-) From gary at mlbassoc.com Sat Jan 28 05:16:03 2012 From: gary at mlbassoc.com (Gary Thomas) Date: Sat, 28 Jan 2012 04:16:03 -0700 Subject: [PATCH] Fix 4 bit ECC on OMAP-L13x Message-ID: <4F23D8F3.3000100@mlbassoc.com> The use of pdev->id as a channel select is problematic, at least on the OMAP-L13x when using 4 bit hardware assisted ECC. On this hardware, only EMiF channels (chip select) 2 through 5 are available. Specifying platform device id 1 when using chip select 3 is obscure at best. If the core_chipsel value used by the driver is incorrect, then the ECC hardware is not set up properly and ends up always reading ECC values of zero. This is totally broken as no ECC errors will be detected on reads and incorrect ECC values will be stored on writes. The best way to fix this is to pass the actual chip select in the platform data, rather than have it be inferred from the platform device id. The attached patch provides for this. Also, this patch is a no-op for target platforms that do not specify the core_chipsel value in the platform data. This patch was generated against the mainline 3.0 kernel, but applies to 3.2 as well. Note: there does not seem to be an identified maintainer of this code, so this list was my first guess at where to post. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-4-bit-ECC-on-OMAP-L138.patch Type: text/x-patch Size: 1892 bytes Desc: not available URL: From sshtylyov at mvista.com Sat Jan 28 08:53:58 2012 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Sat, 28 Jan 2012 18:53:58 +0400 Subject: [PATCH] Fix 4 bit ECC on OMAP-L13x In-Reply-To: <4F23D8F3.3000100@mlbassoc.com> References: <4F23D8F3.3000100@mlbassoc.com> Message-ID: <4F240C06.8070300@mvista.com> On 28.01.2012 15:16, Gary Thomas wrote: > The use of pdev->id as a channel select is problematic, at least > on the OMAP-L13x when using 4 bit hardware assisted ECC. On this > hardware, only EMiF channels (chip select) 2 through 5 are available. > Specifying platform device id 1 when using chip select 3 is obscure > at best. > If the core_chipsel value used by the driver is incorrect, then > the ECC hardware is not set up properly and ends up always reading > ECC values of zero. This is totally broken as no ECC errors will > be detected on reads and incorrect ECC values will be stored on writes. > The best way to fix this is to pass the actual chip select in > the platform data, rather than have it be inferred from the > platform device id. The attached patch provides for this. Also, > this patch is a no-op for target platforms that do not specify > the core_chipsel value in the platform data. This patch was > generated against the mainline 3.0 kernel, but applies to 3.2 > as well. > Note: there does not seem to be an identified maintainer of this > code, so this list was my first guess at where to post. Pelase send your patches inline, not as attachments. >>From 9695c4d14bacf12dce8b8ab027f1658d6ecea6f0 Mon Sep 17 00:00:00 2001 > From: Gary Thomas > Date: Fri, 27 Jan 2012 14:44:08 -0700 > Subject: [PATCH] davinci_nand: Fix 4 bit ECC on OMAP-L138 Don't include this header in the patches. > NAND chip selects restricted to 2-5 when using HW 4BIT ECC. > Using the platform device id to specify this is problematic > at best and confusing at least. > Let the platform data specify the actual chip select (2..5) > Signed-off-by: Gary Thomas > --- > arch/arm/mach-davinci/include/mach/nand.h | 5 ++++- > drivers/mtd/nand/davinci_nand.c | 5 ++++- > 2 files changed, 8 insertions(+), 2 deletions(-) > diff --git a/arch/arm/mach-davinci/include/mach/nand.h b/arch/arm/mach-davinci/include/mach/nand.h > index 0251510..2d71548 100644 > --- a/arch/arm/mach-davinci/include/mach/nand.h > +++ b/arch/arm/mach-davinci/include/mach/nand.h > @@ -57,7 +57,10 @@ struct davinci_nand_pdata { /* platform_data */ > uint32_t mask_cle; > > /* for packages using two chipselects */ > - uint32_t mask_chipsel; > + uint32_t mask_chipsel; You're adding trailing whitespace here. > + > + /* Old way using pdev->id is confusing */ Shaould indent this with a tab, not spaces. > + uint32_t core_chipsel; > > /* board's default static partition info */ > struct mtd_partition *parts; > diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c > index 1f34951..2072da5 100644 > --- a/drivers/mtd/nand/davinci_nand.c > +++ b/drivers/mtd/nand/davinci_nand.c > @@ -590,7 +590,10 @@ static int __init nand_davinci_probe(struct platform_device *pdev) > info->ioaddr = (uint32_t __force) vaddr; > > info->current_cs = info->ioaddr; > - info->core_chipsel = pdev->id; > + if (pdata->core_chipsel) > + info->core_chipsel = pdata->core_chipsel-2; > + else > + info->core_chipsel = pdev->id; Your code is whitespace damaged here, i.e. all tabs replaced by spaces. And that's despite the patch is in attachament... WBR, Sergei From gary at mlbassoc.com Sat Jan 28 10:08:34 2012 From: gary at mlbassoc.com (Gary Thomas) Date: Sat, 28 Jan 2012 09:08:34 -0700 Subject: [PATCH] Fix 4 bit ECC on OMAP-L13x In-Reply-To: <4F240C06.8070300@mvista.com> References: <4F23D8F3.3000100@mlbassoc.com> <4F240C06.8070300@mvista.com> Message-ID: <4F241D82.5050805@mlbassoc.com> On 2012-01-28 07:53, Sergei Shtylyov wrote: > On 28.01.2012 15:16, Gary Thomas wrote: > >> The use of pdev->id as a channel select is problematic, at least >> on the OMAP-L13x when using 4 bit hardware assisted ECC. On this >> hardware, only EMiF channels (chip select) 2 through 5 are available. >> Specifying platform device id 1 when using chip select 3 is obscure >> at best. > >> If the core_chipsel value used by the driver is incorrect, then >> the ECC hardware is not set up properly and ends up always reading >> ECC values of zero. This is totally broken as no ECC errors will >> be detected on reads and incorrect ECC values will be stored on writes. > >> The best way to fix this is to pass the actual chip select in >> the platform data, rather than have it be inferred from the >> platform device id. The attached patch provides for this. Also, >> this patch is a no-op for target platforms that do not specify >> the core_chipsel value in the platform data. This patch was >> generated against the mainline 3.0 kernel, but applies to 3.2 >> as well. > >> Note: there does not seem to be an identified maintainer of this >> code, so this list was my first guess at where to post. > > Pelase send your patches inline, not as attachments. > >>> From 9695c4d14bacf12dce8b8ab027f1658d6ecea6f0 Mon Sep 17 00:00:00 2001 >> From: Gary Thomas >> Date: Fri, 27 Jan 2012 14:44:08 -0700 >> Subject: [PATCH] davinci_nand: Fix 4 bit ECC on OMAP-L138 > > Don't include this header in the patches. > >> NAND chip selects restricted to 2-5 when using HW 4BIT ECC. >> Using the platform device id to specify this is problematic >> at best and confusing at least. > >> Let the platform data specify the actual chip select (2..5) > >> Signed-off-by: Gary Thomas >> --- >> arch/arm/mach-davinci/include/mach/nand.h | 5 ++++- >> drivers/mtd/nand/davinci_nand.c | 5 ++++- >> 2 files changed, 8 insertions(+), 2 deletions(-) > >> diff --git a/arch/arm/mach-davinci/include/mach/nand.h b/arch/arm/mach-davinci/include/mach/nand.h >> index 0251510..2d71548 100644 >> --- a/arch/arm/mach-davinci/include/mach/nand.h >> +++ b/arch/arm/mach-davinci/include/mach/nand.h >> @@ -57,7 +57,10 @@ struct davinci_nand_pdata { /* platform_data */ >> uint32_t mask_cle; >> >> /* for packages using two chipselects */ >> - uint32_t mask_chipsel; >> + uint32_t mask_chipsel; > > You're adding trailing whitespace here. > >> + >> + /* Old way using pdev->id is confusing */ > > Shaould indent this with a tab, not spaces. > >> + uint32_t core_chipsel; >> >> /* board's default static partition info */ >> struct mtd_partition *parts; >> diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c >> index 1f34951..2072da5 100644 >> --- a/drivers/mtd/nand/davinci_nand.c >> +++ b/drivers/mtd/nand/davinci_nand.c >> @@ -590,7 +590,10 @@ static int __init nand_davinci_probe(struct platform_device *pdev) >> info->ioaddr = (uint32_t __force) vaddr; >> >> info->current_cs = info->ioaddr; >> - info->core_chipsel = pdev->id; >> + if (pdata->core_chipsel) >> + info->core_chipsel = pdata->core_chipsel-2; >> + else >> + info->core_chipsel = pdev->id; > > Your code is whitespace damaged here, i.e. all tabs replaced by spaces. And that's despite the patch is in attachament... > > WBR, Sergei Fair enough, I can clean up the cosmetics. What about the content of the patch itself?? -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ From sshtylyov at mvista.com Sat Jan 28 13:22:43 2012 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Sat, 28 Jan 2012 23:22:43 +0400 Subject: [PATCH] Fix 4 bit ECC on OMAP-L13x In-Reply-To: <4F241D82.5050805@mlbassoc.com> References: <4F23D8F3.3000100@mlbassoc.com> <4F240C06.8070300@mvista.com> <4F241D82.5050805@mlbassoc.com> Message-ID: <4F244B03.9060905@mvista.com> Hello. On 28-01-2012 20:08, Gary Thomas wrote: >>> The use of pdev->id as a channel select is problematic, at least >>> on the OMAP-L13x when using 4 bit hardware assisted ECC. On this >>> hardware, only EMiF channels (chip select) 2 through 5 are available. >>> Specifying platform device id 1 when using chip select 3 is obscure >>> at best. >>> If the core_chipsel value used by the driver is incorrect, then >>> the ECC hardware is not set up properly and ends up always reading >>> ECC values of zero. This is totally broken as no ECC errors will >>> be detected on reads and incorrect ECC values will be stored on writes. >>> The best way to fix this is to pass the actual chip select in >>> the platform data, rather than have it be inferred from the >>> platform device id. The attached patch provides for this. Also, >>> this patch is a no-op for target platforms that do not specify >>> the core_chipsel value in the platform data. This patch was >>> generated against the mainline 3.0 kernel, but applies to 3.2 >>> as well. >>> Note: there does not seem to be an identified maintainer of this >>> code, so this list was my first guess at where to post. >> Pelase send your patches inline, not as attachments. >>>> From 9695c4d14bacf12dce8b8ab027f1658d6ecea6f0 Mon Sep 17 00:00:00 2001 >>> From: Gary Thomas >>> Date: Fri, 27 Jan 2012 14:44:08 -0700 >>> Subject: [PATCH] davinci_nand: Fix 4 bit ECC on OMAP-L138 >> Don't include this header in the patches. >>> NAND chip selects restricted to 2-5 when using HW 4BIT ECC. >>> Using the platform device id to specify this is problematic >>> at best and confusing at least. >>> Let the platform data specify the actual chip select (2..5) >>> Signed-off-by: Gary Thomas >>> --- >>> arch/arm/mach-davinci/include/mach/nand.h | 5 ++++- >>> drivers/mtd/nand/davinci_nand.c | 5 ++++- >>> 2 files changed, 8 insertions(+), 2 deletions(-) >>> diff --git a/arch/arm/mach-davinci/include/mach/nand.h >>> b/arch/arm/mach-davinci/include/mach/nand.h >>> index 0251510..2d71548 100644 >>> --- a/arch/arm/mach-davinci/include/mach/nand.h >>> +++ b/arch/arm/mach-davinci/include/mach/nand.h >>> @@ -57,7 +57,10 @@ struct davinci_nand_pdata { /* platform_data */ >>> uint32_t mask_cle; >>> >>> /* for packages using two chipselects */ >>> - uint32_t mask_chipsel; >>> + uint32_t mask_chipsel; >> >> You're adding trailing whitespace here. >> >>> + >>> + /* Old way using pdev->id is confusing */ >> >> Shaould indent this with a tab, not spaces. >> >>> + uint32_t core_chipsel; >>> >>> /* board's default static partition info */ >>> struct mtd_partition *parts; >>> diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c >>> index 1f34951..2072da5 100644 >>> --- a/drivers/mtd/nand/davinci_nand.c >>> +++ b/drivers/mtd/nand/davinci_nand.c >>> @@ -590,7 +590,10 @@ static int __init nand_davinci_probe(struct >>> platform_device *pdev) >>> info->ioaddr = (uint32_t __force) vaddr; >>> >>> info->current_cs = info->ioaddr; >>> - info->core_chipsel = pdev->id; >>> + if (pdata->core_chipsel) >>> + info->core_chipsel = pdata->core_chipsel-2; >>> + else >>> + info->core_chipsel = pdev->id; >> Your code is whitespace damaged here, i.e. all tabs replaced by spaces. And >> that's despite the patch is in attachament... >> WBR, Sergei > Fair enough, I can clean up the cosmetics. What about the > content of the patch itself?? I like it, if you ask me. WBR, Sergei From olof at lixom.net Sat Jan 28 17:57:43 2012 From: olof at lixom.net (Olof Johansson) Date: Sat, 28 Jan 2012 15:57:43 -0800 Subject: ARM/ARM-SoC plans for v3.4 merge window In-Reply-To: <20120126212319.GE11941@n2100.arm.linux.org.uk> References: <20120123114902.GY1068@n2100.arm.linux.org.uk> <20120124095009.GS16726@n2100.arm.linux.org.uk> <20120126212319.GE11941@n2100.arm.linux.org.uk> Message-ID: Hi, On Thu, Jan 26, 2012 at 1:23 PM, Russell King - ARM Linux wrote: > And we're now there. ?So... > > Arnd, Olaf, > > Please incorporate the latest ARM (for-armsoc branch) changes, which can be found at: > > ? ? ? ?git://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-arm.git for-armsoc > > with SHA1 dcf81c1af839b77b44404453ecae6e5ac5a75f05. Thanks. I have added this as depends/rmk/for-armsoc in the arm-soc repo. Any next/ branch we start will have this as the base of said branch, so any vendor branches must either already be developed against this stable branch, or merge on top of this with minimal conflicts. Thanks! -Olof From ido at wizery.com Sun Jan 29 13:37:10 2012 From: ido at wizery.com (Ido Yariv) Date: Sun, 29 Jan 2012 21:37:10 +0200 Subject: [RFC 1/2] mmc: davinci: Eliminate spurious interrupts In-Reply-To: References: <4F1E9194.90608@mvista.com> <1327403766-962-1-git-send-email-ido@wizery.com> Message-ID: <20120129193710.GA24514@WorkStation> Hello Sudhakar, On Fri, Jan 27, 2012 at 08:11:55AM +0000, Rajashekhara, Sudhakar wrote: > I tested both these patches and they work fine on the OMAP-L138 EVM. I > observed that with these patches the number of interrupts during a transfer > are less compared to earlier. For a 100 MB transfer, I could see around > 700-800 interrupts less. Did you see any performance improvement with these > patches? Thanks for testing these. The difference in the number of interrupts, or rather the ratio, depends on the scenario you're working on. The spurious patch has an effect on non-dma transfers, while the polling optimization affects small (i.e. up to 128 bytes) transactions. I expect these to have a greater impact on SDIO scenarios than on SD scenarios. Regarding the performance improvement, these patches were tested using a WLAN SDIO adapter, which requires quite a few small transactions. The polling optimization had an impact of around 10-15% in throughput. The spurious patch did not have any noticeable effect on throughput, but did lower the number of interrupts by up to 25% in some cases. Thanks, Ido. From olof at lixom.net Sun Jan 29 16:39:37 2012 From: olof at lixom.net (Olof Johansson) Date: Sun, 29 Jan 2012 14:39:37 -0800 Subject: [GIT PULL] DaVinci fixes for v3.3-rc In-Reply-To: References: Message-ID: Hi, On Fri, Jan 27, 2012 at 9:26 AM, Nori, Sekhar wrote: > Hi Olof, Arnd, > > Can you please pull these DaVinci fixes for the next v3.3-rc? > Both the patches have not been stable tagged. The fix by me > is a v3.3 regression. The fix by Bas van den Berg is not critical > enough to get into stable kernels. > > Thanks, > Sekhar > > The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f: > ?Linus Torvalds (1): > ? ? ? ?Linux 3.3-rc1 > > are available in the git repository at: > > ?git://gitorious.org/linux-davinci/linux-davinci.git fixes > > Bas van den Berg (1): > ? ? ?ARM: davinci: DA850: remove non-existing pll1_sysclk4-7 clocks > > Sekhar Nori (1): > ? ? ?ARM: davinci: update mdio bus name Looks like the clock removal is almost crossing over into cleanup territory not a fix. In the future please help us out by briefly motivate why it's a fix (for something that is broken) and not a cleanup if it's not obvious from reading it -- noncritical fixes are usually saved for the next merge window instead. With that said; I've pulled the branch. Thanks! -Olof From sudhakar.raj at ti.com Sun Jan 29 22:17:50 2012 From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar) Date: Mon, 30 Jan 2012 04:17:50 +0000 Subject: [PATCH] Fix 4 bit ECC on OMAP-L13x In-Reply-To: <4F241D82.5050805@mlbassoc.com> References: <4F23D8F3.3000100@mlbassoc.com> <4F240C06.8070300@mvista.com> <4F241D82.5050805@mlbassoc.com> Message-ID: Hi Gary, On Sat, Jan 28, 2012 at 21:38:34, Gary Thomas wrote: > On 2012-01-28 07:53, Sergei Shtylyov wrote: > > On 28.01.2012 15:16, Gary Thomas wrote: > > > >> The use of pdev->id as a channel select is problematic, at least > >> on the OMAP-L13x when using 4 bit hardware assisted ECC. On this > >> hardware, only EMiF channels (chip select) 2 through 5 are available. > >> Specifying platform device id 1 when using chip select 3 is obscure > >> at best. > > > >> If the core_chipsel value used by the driver is incorrect, then > >> the ECC hardware is not set up properly and ends up always reading > >> ECC values of zero. This is totally broken as no ECC errors will > >> be detected on reads and incorrect ECC values will be stored on writes. > > > >> The best way to fix this is to pass the actual chip select in > >> the platform data, rather than have it be inferred from the > >> platform device id. The attached patch provides for this. Also, > >> this patch is a no-op for target platforms that do not specify > >> the core_chipsel value in the platform data. This patch was > >> generated against the mainline 3.0 kernel, but applies to 3.2 > >> as well. > > > >> Note: there does not seem to be an identified maintainer of this > >> code, so this list was my first guess at where to post. > > > > Pelase send your patches inline, not as attachments. > > As Sergei suggested, please modify your patch to convert spaces to tabs and remove trailing white-spaces. You can run your patch through the scripts/checkpatch.pl script which will detect such errors. Once done, please resubmit your patch inline. Thanks, Sudhakar From FlorianSchandinat at gmx.de Sun Jan 29 23:12:57 2012 From: FlorianSchandinat at gmx.de (Florian Tobias Schandinat) Date: Mon, 30 Jan 2012 05:12:57 +0000 Subject: [PATCH v3] video: da8xx-fb: reset LCDC only if functional clock changes with DVFS In-Reply-To: <1325594451-11963-1-git-send-email-prakash.pm@ti.com> References: <1325594451-11963-1-git-send-email-prakash.pm@ti.com> Message-ID: <4F2626D9.8070808@gmx.de> On 01/03/2012 12:40 PM, Manjunathappa, Prakash wrote: > LCDC functional clock may or may not be derived from CPU/MPU DPLL, > For example, > AM335x => Separate independent DPLL for LCDC > Davinci => Same DPLL as MPU > > So, on platforms where LCDC functional clock is not derived from CPU/MPU > PLL it is not required to reset LCDC module as its functional clock does > not change with DVFS. > > This patch adds check to do reset only if functional clock changes > between pre and post notifier callbacks with DVFS. > > Signed-off-by: Manjunathappa, Prakash Applied. Thanks, Florian Tobias Schandinat > --- > Since v2: > Fix, update lcd_fck_rate with current LCD functional clock rate. > Since v1: > Fixed the commit message. > > drivers/video/da8xx-fb.c | 16 +++++++++++----- > 1 files changed, 11 insertions(+), 5 deletions(-) > > diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c > index 6b27751..dee1918 100644 > --- a/drivers/video/da8xx-fb.c > +++ b/drivers/video/da8xx-fb.c > @@ -163,6 +163,7 @@ struct da8xx_fb_par { > int vsync_timeout; > #ifdef CONFIG_CPU_FREQ > struct notifier_block freq_transition; > + unsigned int lcd_fck_rate; > #endif > void (*panel_power_ctrl)(int); > }; > @@ -895,11 +896,13 @@ static int lcd_da8xx_cpufreq_transition(struct notifier_block *nb, > struct da8xx_fb_par *par; > > par = container_of(nb, struct da8xx_fb_par, freq_transition); > - if (val == CPUFREQ_PRECHANGE) { > - lcd_disable_raster(); > - } else if (val == CPUFREQ_POSTCHANGE) { > - lcd_calc_clk_divider(par); > - lcd_enable_raster(); > + if (val == CPUFREQ_POSTCHANGE) { > + if (par->lcd_fck_rate != clk_get_rate(par->lcdc_clk)) { > + par->lcd_fck_rate = clk_get_rate(par->lcdc_clk); > + lcd_disable_raster(); > + lcd_calc_clk_divider(par); > + lcd_enable_raster(); > + } > } > > return 0; > @@ -1192,6 +1195,9 @@ static int __devinit fb_probe(struct platform_device *device) > > par = da8xx_fb_info->par; > par->lcdc_clk = fb_clk; > +#ifdef CONFIG_CPU_FREQ > + par->lcd_fck_rate = clk_get_rate(fb_clk); > +#endif > par->pxl_clk = lcdc_info->pxl_clk; > if (fb_pdata->panel_power_ctrl) { > par->panel_power_ctrl = fb_pdata->panel_power_ctrl; From prakash.pm at ti.com Mon Jan 30 00:58:12 2012 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Mon, 30 Jan 2012 06:58:12 +0000 Subject: [PATCH v2 3/3] arm: da830: move NAND and NOR devices as aemif MFD slaves In-Reply-To: <4F2016F4.2080302@mvista.com> References: <1327487156-10238-1-git-send-email-prakash.pm@ti.com> <1327487156-10238-3-git-send-email-prakash.pm@ti.com> <4F2016F4.2080302@mvista.com> Message-ID: Hi Sergei, On Wed, Jan 25, 2012 at 20:21:32, Sergei Shtylyov wrote: > Hello. > > On 01/25/2012 01:25 PM, Manjunathappa, Prakash wrote: > > > NAND and NOR device are made as aemif devices slave, hence device > > registration achieved via aemif MFD driver. > > > Signed-off-by: Manjunathappa, Prakash > > --- > > Since v1: > > Patch is generated using -M option. > > > arch/arm/mach-davinci/board-da830-evm.c | 31 +++++++++++++++++++++++-------- > > 1 files changed, 23 insertions(+), 8 deletions(-) > > Why only this file? Don't other board files have NAND/NOR devices? Yes I thought of sending board-da850 changes in separate patch. Should I have to send those changes also in this patch? Thanks, Prakash > > WBR, Sergei > From nicolas.ferre at atmel.com Mon Jan 30 04:08:19 2012 From: nicolas.ferre at atmel.com (Nicolas Ferre) Date: Mon, 30 Jan 2012 11:08:19 +0100 Subject: ARM/ARM-SoC plans for v3.4 merge window In-Reply-To: References: <20120123114902.GY1068@n2100.arm.linux.org.uk> <20120124095009.GS16726@n2100.arm.linux.org.uk> <20120126212319.GE11941@n2100.arm.linux.org.uk> Message-ID: <4F266C13.5080302@atmel.com> On 01/29/2012 12:57 AM, Olof Johansson : > Hi, > > > On Thu, Jan 26, 2012 at 1:23 PM, Russell King - ARM Linux > wrote: > > >> And we're now there. So... >> >> Arnd, Olaf, >> >> Please incorporate the latest ARM (for-armsoc branch) changes, which can be found at: >> >> git://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-arm.git for-armsoc >> >> with SHA1 dcf81c1af839b77b44404453ecae6e5ac5a75f05. > > Thanks. I have added this as depends/rmk/for-armsoc in the arm-soc repo. > > Any next/ branch we start will have this as the base of said branch, > so any vendor branches must either already be developed against this > stable branch, or merge on top of this with minimal conflicts. Ok, great. I just let you know that there is a conflict between the current Linus' tree (with recently updated at91 fixes) and this rmk/for-armsoc branch. I can give you the resolution of this conflict easily but I would like to know which way I execute the merge: I use this rmk/for-armsoc as a baseline and merge the fixes already in Linus' tree on top of it or the other way around? Maybe it is preferable that I wait for 3.3-rc2 and merge rmk/for-armsoc on top of it. This result can be the base of our AT91 work for 3.4 preparation. Your thought? Best regards, -- Nicolas Ferre From sshtylyov at mvista.com Mon Jan 30 04:40:31 2012 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Mon, 30 Jan 2012 14:40:31 +0400 Subject: [PATCH v2 3/3] arm: da830: move NAND and NOR devices as aemif MFD slaves In-Reply-To: References: <1327487156-10238-1-git-send-email-prakash.pm@ti.com> <1327487156-10238-3-git-send-email-prakash.pm@ti.com> <4F2016F4.2080302@mvista.com> Message-ID: <4F26739F.2070305@mvista.com> Hello. On 30-01-2012 10:58, Manjunathappa, Prakash wrote: >>> NAND and NOR device are made as aemif devices slave, hence device >>> registration achieved via aemif MFD driver. >>> Signed-off-by: Manjunathappa, Prakash >>> --- >>> Since v1: >>> Patch is generated using -M option. >>> arch/arm/mach-davinci/board-da830-evm.c | 31 +++++++++++++++++++++++-------- >>> 1 files changed, 23 insertions(+), 8 deletions(-) >> Why only this file? Don't other board files have NAND/NOR devices? > Yes I thought of sending board-da850 changes in separate patch. Should I have to send those changes also in this patch? There's also board-dm*.c files. I'd done them all in the same patch. > Thanks, > Prakash WBR, Sergei From nsekhar at ti.com Mon Jan 30 11:16:50 2012 From: nsekhar at ti.com (Nori, Sekhar) Date: Mon, 30 Jan 2012 17:16:50 +0000 Subject: [GIT PULL] DaVinci fixes for v3.3-rc In-Reply-To: References: Message-ID: Hi Olof, On Mon, Jan 30, 2012 at 04:09:37, Olof Johansson wrote: > Hi, > > On Fri, Jan 27, 2012 at 9:26 AM, Nori, Sekhar wrote: > > Hi Olof, Arnd, > > > > Can you please pull these DaVinci fixes for the next v3.3-rc? > > Both the patches have not been stable tagged. The fix by me > > is a v3.3 regression. The fix by Bas van den Berg is not critical > > enough to get into stable kernels. > > > > Thanks, > > Sekhar > > > > The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f: > > ?Linus Torvalds (1): > > ? ? ? ?Linux 3.3-rc1 > > > > are available in the git repository at: > > > > ?git://gitorious.org/linux-davinci/linux-davinci.git fixes > > > > Bas van den Berg (1): > > ? ? ?ARM: davinci: DA850: remove non-existing pll1_sysclk4-7 clocks > > > > Sekhar Nori (1): > > ? ? ?ARM: davinci: update mdio bus name > > Looks like the clock removal is almost crossing over into cleanup > territory not a fix. In the future please help us out by briefly > motivate why it's a fix (for something that is broken) and not a > cleanup if it's not obvious from reading it -- noncritical fixes are > usually saved for the next merge window instead. I categorized it as a fix since the path removes clocks which don't exist in hardware. Accessing such clocks will cause undefined behavior. The patch description does say that the clocks don't exist in hardware. Code without the patch is definitely outside the specification. In this regard, what could have been done better in the patch description? Thanks, Sekhar From grant.likely at secretlab.ca Mon Jan 30 14:32:52 2012 From: grant.likely at secretlab.ca (Grant Likely) Date: Mon, 30 Jan 2012 13:32:52 -0700 Subject: [RFC PATCH 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board In-Reply-To: <1327308967-8092-8-git-send-email-hs@denx.de> References: <1327308967-8092-1-git-send-email-hs@denx.de> <1327308967-8092-8-git-send-email-hs@denx.de> Message-ID: <20120130203252.GX28397@ponder.secretlab.ca> On Mon, Jan 23, 2012 at 09:56:07AM +0100, Heiko Schocher wrote: > - AM1808 based board > - 64 MiB DDR ram > - 2 MiB Nor flash > - 128 MiB NAND flash > - use internal RTC > - I2C support > - hwmon lm75 support > - UBI/UBIFS support > - MMC support > - USB OTG support > > Signed-off-by: Heiko Schocher > Cc: linux-arm-kernel at lists.infradead.org > Cc: devicetree-discuss at lists.ozlabs.org > Cc: davinci-linux-open-source at linux.davincidsp.com > Cc: linux-mtd at lists.infradead.org > Cc: linux-i2c at vger.kernel.org > Cc: netdev at vger.kernel.org > Cc: David Woodhouse > Cc: Ben Dooks > Cc: Wolfram Sang > Cc: Sekhar Nori > Cc: Kevin Hilman > Cc: Wolfgang Denk > > --- > - post this board support with USB support, even though > USB is only working with the 10 ms "workaround", posted here: > http://comments.gmane.org/gmane.linux.usb.general/54505 > I see this issue also on the AM1808 TMDXEXP1808L evalboard. > - MMC and USB are not using OF support yet, ideas how to port > this are welcome. I need for USB and MMC boards board > specific callbacks, how to solve this with OF support? > > arch/arm/boot/dts/enbw_cmc.dts | 286 +++++++++++++++++ > arch/arm/configs/enbw_cmc_defconfig | 125 ++++++++ > arch/arm/mach-davinci/Kconfig | 8 + > arch/arm/mach-davinci/Makefile | 1 + > arch/arm/mach-davinci/board-enbw-cmc.c | 384 +++++++++++++++++++++++ > arch/arm/mach-davinci/include/mach/uncompress.h | 1 + > 6 files changed, 805 insertions(+), 0 deletions(-) > create mode 100644 arch/arm/boot/dts/enbw_cmc.dts > create mode 100644 arch/arm/configs/enbw_cmc_defconfig > create mode 100644 arch/arm/mach-davinci/board-enbw-cmc.c > > diff --git a/arch/arm/boot/dts/enbw_cmc.dts b/arch/arm/boot/dts/enbw_cmc.dts > new file mode 100644 > index 0000000..e5995ce > --- /dev/null > +++ b/arch/arm/boot/dts/enbw_cmc.dts > @@ -0,0 +1,286 @@ > +/* > + * Device Tree for the EnBW CMC plattform > + * > + * Copyright 2011 DENX Software Engineering GmbH > + * Heiko Schocher > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License as published by the > + * Free Software Foundation; either version 2 of the License, or (at your > + * option) any later version. > + */ > +/dts-v1/; > +/include/ "skeleton.dtsi" > + > +/ { > + model = "EnBW CMC"; > + compatible = "enbw,cmc"; > + > + aliases { > + ethernet0 = ð0; > + }; > + > + arm { > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0 0xfffee000 0x00020000>; > + intc: interrupt-controller at 1 { > + compatible = "ti,davinci-intc"; > + interrupt-controller; > + #interrupt-cells = <1>; > + ti,intc-size = <101>; > + reg = <0x0 0x2000>; > + }; > + }; > + soc at 1c00000 { > + compatible = "ti,da8xx"; As previously mentioned, using wildcard ('x') characters in compatible properties is bad practice. Always be specific and use the compatible list to make sure the correct driver gets bound (assuming the device is 100% register level compatible with the older one). > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0x0 0x01c00000 0x400000>; > + > + serial0: serial at 1c42000 { > + cell-index = <2>; As previously mentioned, don't use cell index. If you *really* need to assign a number to a device, then use a property in the /aliases node and make sure pdev->id does *not* get modified. > + compatible = "ns16550a"; Should include a string for the specific device. Something like: compatible = "ti,da800", "ns16550a"; > diff --git a/arch/arm/mach-davinci/board-enbw-cmc.c b/arch/arm/mach-davinci/board-enbw-cmc.c > new file mode 100644 > index 0000000..4473c4a > --- /dev/null > +++ b/arch/arm/mach-davinci/board-enbw-cmc.c > @@ -0,0 +1,384 @@ > +/* > + * EnBW Communication Module Compact board > + * Copyright 2011 DENX Software Engineering GmbH > + * Author: Heiko Schocher > + * > + * based on: > + * TI DA850/OMAP-L138 EVM board > + * > + * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/ > + * > + * Derived from: arch/arm/mach-davinci/board-da850-evm.c > + * Original Copyrights follow: > + * > + * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under > + * the terms of the GNU General Public License version 2. This program > + * is licensed "as is" without any warranty of any kind, whether express > + * or implied. > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define ENBW_CMC_MMCSD_CD_PIN GPIO_TO_PIN(3, 13) > + > +/* > + * USB1 VBUS is controlled by GPIO7[12], over-current is reported on GPIO7[8]. > + */ > +#define DA850_USB_VBUS_PIN GPIO_TO_PIN(7, 12) > +#define ON_BD_USB_OVC GPIO_TO_PIN(7, 8) > + > +#if defined(CONFIG_USB_OHCI_HCD) > +static irqreturn_t enbw_cmc_usb_ocic_irq(int irq, void *dev_id); > +static da8xx_ocic_handler_t enbw_cmc_usb_ocic_handler; > + > +static int enbw_cmc_usb_set_power(unsigned port, int on) > +{ > + gpio_set_value(DA850_USB_VBUS_PIN, on); > + return 0; > +} > + > +static int enbw_cmc_usb_get_power(unsigned port) > +{ > + return gpio_get_value(DA850_USB_VBUS_PIN); > +} > + > +static int enbw_cmc_usb_get_oci(unsigned port) > +{ > + return !gpio_get_value(ON_BD_USB_OVC); > +} > + > +static irqreturn_t enbw_cmc_usb_ocic_irq(int, void *); > + > +static int enbw_cmc_usb_ocic_notify(da8xx_ocic_handler_t handler) > +{ > + int irq = gpio_to_irq(ON_BD_USB_OVC); > + int error = 0; > + > + if (handler != NULL) { > + enbw_cmc_usb_ocic_handler = handler; > + > + error = request_irq(irq, enbw_cmc_usb_ocic_irq, > + IRQF_DISABLED | IRQF_TRIGGER_RISING | > + IRQF_TRIGGER_FALLING, > + "OHCI over-current indicator", NULL); > + if (error) > + pr_err("%s: could not request IRQ to watch " > + "over-current indicator changes\n", __func__); > + } else { > + free_irq(irq, NULL); > + } > + return error; > +} > + > +static struct da8xx_ohci_root_hub enbw_cmc_usb11_pdata = { > + .set_power = enbw_cmc_usb_set_power, > + .get_power = enbw_cmc_usb_get_power, > + .get_oci = enbw_cmc_usb_get_oci, > + .ocic_notify = enbw_cmc_usb_ocic_notify, > + .potpgt = (10 + 1) / 2, /* 10 ms max */ > +}; > + > +static irqreturn_t enbw_cmc_usb_ocic_irq(int irq, void *dev_id) > +{ > + enbw_cmc_usb_ocic_handler(&enbw_cmc_usb11_pdata, 1); > + return IRQ_HANDLED; > +} > +#endif > + > +#if defined(CONFIG_OF) > +static __init void enbw_cmc_usb_init(void) All the focus is on DT now. How about making CONFIG_OF required for this board? Also, this is just another board file. The focus should be on creating a generic board support file for DT platforms. From grant.likely at secretlab.ca Mon Jan 30 14:04:36 2012 From: grant.likely at secretlab.ca (Grant Likely) Date: Mon, 30 Jan 2012 13:04:36 -0700 Subject: [RFC PATCH 5/7] ARM: davinci: i2c: add OF support In-Reply-To: <1327308967-8092-6-git-send-email-hs@denx.de> References: <1327308967-8092-1-git-send-email-hs@denx.de> <1327308967-8092-6-git-send-email-hs@denx.de> Message-ID: <20120130200436.GU28397@ponder.secretlab.ca> On Mon, Jan 23, 2012 at 09:56:05AM +0100, Heiko Schocher wrote: > add of support for the davinci i2c driver. > > Signed-off-by: Heiko Schocher > Cc: davinci-linux-open-source at linux.davincidsp.com > Cc: linux-arm-kernel at lists.infradead.org > Cc: devicetree-discuss at lists.ozlabs.org > Cc: linux-i2c at vger.kernel.org > Cc: Ben Dooks > Cc: Wolfram Sang > Cc: Grant Likely > Cc: Sekhar Nori > Cc: Wolfgang Denk Hi Heiko, comments below. > --- > .../devicetree/bindings/arm/davinci/i2c.txt | 39 ++++++++++++++++++ > drivers/i2c/busses/i2c-davinci.c | 43 ++++++++++++++++++++ > 2 files changed, 82 insertions(+), 0 deletions(-) > create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt > > diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt b/Documentation/devicetree/bindings/arm/davinci/i2c.txt > new file mode 100644 > index 0000000..94ec670 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt > @@ -0,0 +1,39 @@ > +* Texas Instruments Davinci I2C > + > +This file provides information, what the device node for the > +davinci i2c interface contain. > + > +Required properties: > +- compatible: "ti,davinci-i2c"; > +- reg : Offset and length of the register set for the device > +- id: id of the controller Don't use an 'id' property. i2c bus numbers should be dynamically assigned when using the device tree. > + > +Recommended properties : > +- interrupts : where a is the interrupt number and b is a > + field that represents an encoding of the sense and level > + information for the interrupt. This is inaccurate. It is entirely defined by the interrupt controller. All you need to say here is that this is a standard interrupts property. > +- interrupt-parent : the phandle for the interrupt controller that > + services interrupts for this device. Don't even mention this one. It can often be inherited from a parent node. > +- clock-frequency : desired I2C bus clock frequency in Hz. > + > +Optional properties: > +- bus-delay: bus delay in usec > +- pinmux-handle: Contains a handle to configure the pinmux settings. > + > +Example (enbw_cmc board): > + i2c at 1c22000 { > + compatible = "ti,davinci-i2c"; > + reg = <0x22000 0x1000>; > + clock-frequency = <100000>; > + interrupts = <15 2>; > + interrupt-parent = <&intc>; > + id = <1>; > + pinmux-handle = <&i2c1_pins>; > + #address-cells = <1>; > + #size-cells = <0>; > + > + dtt at 48 { > + compatible = "national,lm75"; > + reg = <0x48>; > + }; > + }; > diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c > index a76d85f..6f59fae 100644 > --- a/drivers/i2c/busses/i2c-davinci.c > +++ b/drivers/i2c/busses/i2c-davinci.c > @@ -38,9 +38,12 @@ > #include > #include > #include > +#include > +#include > > #include > #include > +#include > > /* ----- global defines ----------------------------------------------- */ > > @@ -635,6 +638,16 @@ static struct i2c_algorithm i2c_davinci_algo = { > .functionality = i2c_davinci_func, > }; > > +#if defined(CONFIG_OF) > +static const struct of_device_id davinci_i2c_of_match[] = { > + {.compatible = "ti,davinci-i2c", }, > + {}, > +} > +MODULE_DEVICE_TABLE(of, davinci_i2c_of_match); > +#else > +#define davinci_i2c_of_match NULL > +#endif The #else clause can be dropped if you use the of_match_ptr() macro when referencing it. > + > static int davinci_i2c_probe(struct platform_device *pdev) > { > struct davinci_i2c_dev *dev; > @@ -676,7 +689,34 @@ static int davinci_i2c_probe(struct platform_device *pdev) > dev->irq = irq->start; > platform_set_drvdata(pdev, dev); > > + if ((dev->dev->platform_data == NULL) && > + (pdev->dev.of_node)) { > + struct device_node *pinmux_np; > + struct davinci_i2c_platform_data *pdata; > + u32 prop; > + > + dev->dev->platform_data = &davinci_i2c_platform_data_default; Don't do this. What if a davinci part shows up with two i2c busses? Use devm_kzalloc() instead. > + pdata = &davinci_i2c_platform_data_default; > + if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency", > + &prop)) > + pdata->bus_freq = prop / 1000; > + if (!of_property_read_u32(pdev->dev.of_node, "bus-delay", > + &prop)) > + pdata->bus_delay = prop; > + if (!of_property_read_u32(pdev->dev.of_node, "id", > + &prop)) { > + pdev->id = prop; > + pdev->dev.init_name = kzalloc(20, GFP_KERNEL); > + sprintf((char *)pdev->dev.init_name, > + "i2c_davinci.%d", pdev->id); Blech! Drop this. Leave the core code to set the device name. > dev->clk = clk_get(&pdev->dev, NULL); > + > if (IS_ERR(dev->clk)) { Nit: unrelated whitespace change > r = -ENODEV; > goto err_free_mem; > @@ -711,6 +751,7 @@ static int davinci_i2c_probe(struct platform_device *pdev) > adap->algo = &i2c_davinci_algo; > adap->dev.parent = &pdev->dev; > adap->timeout = DAVINCI_I2C_TIMEOUT; > + adap->dev.of_node = pdev->dev.of_node; > > adap->nr = pdev->id; > r = i2c_add_numbered_adapter(adap); > @@ -718,6 +759,7 @@ static int davinci_i2c_probe(struct platform_device *pdev) > dev_err(&pdev->dev, "failure adding adapter\n"); > goto err_free_irq; > } > + of_i2c_register_devices(adap); > > return 0; > > @@ -809,6 +851,7 @@ static struct platform_driver davinci_i2c_driver = { > .name = "i2c_davinci", > .owner = THIS_MODULE, > .pm = davinci_i2c_pm_ops, > + .of_match_table = davinci_i2c_of_match, > }, > }; > > -- > 1.7.7.5 > From grant.likely at secretlab.ca Mon Jan 30 14:13:07 2012 From: grant.likely at secretlab.ca (Grant Likely) Date: Mon, 30 Jan 2012 13:13:07 -0700 Subject: [RFC PATCH 5/7] ARM: davinci: i2c: add OF support In-Reply-To: <4F1E7F36.50505@samsung.com> References: <1327308967-8092-1-git-send-email-hs@denx.de> <1327308967-8092-6-git-send-email-hs@denx.de> <4F1DC480.4010603@gmail.com> <4F1E5B44.4090200@denx.de> <4F1E7F36.50505@samsung.com> Message-ID: <20120130201307.GV28397@ponder.secretlab.ca> On Tue, Jan 24, 2012 at 10:51:50AM +0100, Sylwester Nawrocki wrote: > Hello Heiko, > > On 01/24/2012 08:18 AM, Heiko Schocher wrote: > >> On 01/23/2012 09:56 AM, Heiko Schocher wrote: > >>> add of support for the davinci i2c driver. > >>> > >>> Signed-off-by: Heiko Schocher > >>> Cc: davinci-linux-open-source at linux.davincidsp.com > >>> Cc: linux-arm-kernel at lists.infradead.org > >>> Cc: devicetree-discuss at lists.ozlabs.org > >>> Cc: linux-i2c at vger.kernel.org > >>> Cc: Ben Dooks > >>> Cc: Wolfram Sang > >>> Cc: Grant Likely > >>> Cc: Sekhar Nori > >>> Cc: Wolfgang Denk > >>> --- > >>> .../devicetree/bindings/arm/davinci/i2c.txt | 39 ++++++++++++++++++ > >>> drivers/i2c/busses/i2c-davinci.c | 43 ++++++++++++++++++++ > >>> 2 files changed, 82 insertions(+), 0 deletions(-) > >>> create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt > >>> > >>> diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt b/Documentation/devicetree/bindings/arm/davinci/i2c.txt > >>> new file mode 100644 > >>> index 0000000..94ec670 > >>> --- /dev/null > >>> +++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt > >>> @@ -0,0 +1,39 @@ > >>> +* Texas Instruments Davinci I2C > >>> + > >>> +This file provides information, what the device node for the > >>> +davinci i2c interface contain. > >>> + > >>> +Required properties: > >>> +- compatible: "ti,davinci-i2c"; > >>> +- reg : Offset and length of the register set for the device > >>> +- id: id of the controller > >> > >> I was wondering whether we're supposed to use "cell-index" property name > >> for such a device instance index? or doesn't it really matter and "id" is > >> fine? Such an IP instance index seems quite common so I thought it could > >> be easier to follow to use standard name. > > > > I just copied the "name" from "struct davinci_nand_pdata" ... it is > > used in the davinci_nand driver as chipselect ... maybe it is better > > I rename this to "chipselect" ? > > From what I can see the 'id' property is used to determine I2C adapter > number. In that case 'id' seems more correct than "chipselect". Are you > sure there is a chip select functionality in I2C controller ? > > It seems that your id is just an index of I2C controller in hardware. > I would personally just use cell-index for that, but I'm not a dt expert, > someone nay correct me. The whole 'cell-index' or 'id' thing is a BadIdea(tm). Don't use it, and tell others not to do it when you see it. There are some legacy uses in powerpc, but those were written before I and others knew better. The *only* situation where cell-index is acceptable is when the driver absolutely must know which hardware instance it is driving because it needs to calculate offsets in a shared register or something, and even then it should not be used to set the pdev->id field. That situation does not look to be the case here. If you're using the DT, then let the core code dynamically assign the i2c adapter number. > Moreover you seem to overwrite platform device name and id, > > if (!of_property_read_u32(pdev->dev.of_node, "id", > + &prop)) { > + pdev->id = prop; > + pdev->dev.init_name = kzalloc(20, GFP_KERNEL); > + sprintf((char *)pdev->dev.init_name, > + "i2c_davinci.%d", pdev->id); > > I'm not sure if it is a good practice. No, it is not good practice. At this point the device is already registered. Changing the value of pdev->id will cause problems in the core code because the /sysfs files will have already been created. > If you want to pre-define platform > device name (likely for the clock API to work), it might be more appropriate > to use OF_DEV_AUXDATA in the machine code, until there are clock bindings > available. Yes, use OF_DEV_AUXDATA, but *only* if you need it for hooking up clocks, regulators, or similar. Don't use it just because you want the device to have a different name for cosmetic reasons. The need for AUXDATA should go away once the DT clock binding code is merged. g. From grant.likely at secretlab.ca Mon Jan 30 14:22:08 2012 From: grant.likely at secretlab.ca (Grant Likely) Date: Mon, 30 Jan 2012 13:22:08 -0700 Subject: [RFC PATCH 4/7] ARM: davinci: net: davinci_emac: add OF support In-Reply-To: <1327308967-8092-5-git-send-email-hs@denx.de> References: <1327308967-8092-1-git-send-email-hs@denx.de> <1327308967-8092-5-git-send-email-hs@denx.de> Message-ID: <20120130202208.GW28397@ponder.secretlab.ca> On Mon, Jan 23, 2012 at 09:56:04AM +0100, Heiko Schocher wrote: > add of support for the davinci_emac driver. > > Signed-off-by: Heiko Schocher > Cc: davinci-linux-open-source at linux.davincidsp.com > Cc: linux-arm-kernel at lists.infradead.org > Cc: devicetree-discuss at lists.ozlabs.org > Cc: netdev at vger.kernel.org > Cc: Grant Likely > Cc: Sekhar Nori > Cc: Wolfgang Denk > --- > .../bindings/arm/davinci/davinci_emac.txt | 46 ++++++++ > drivers/net/ethernet/ti/davinci_emac.c | 111 +++++++++++++++++++- > 2 files changed, 156 insertions(+), 1 deletions(-) > create mode 100644 Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt > > diff --git a/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt > new file mode 100644 > index 0000000..4e5dc8d > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt > @@ -0,0 +1,46 @@ > +* Texas Instruments Davinci EMAC > + > +This file provides information, what the davice node > +for the davinci_emac interface contain. > + > +Required properties: > +- compatible: "ti,davinci-emac"; > +- reg: Offset and length of the register set for the device > +- ctrl_reg_offset: offset to control register > +- ctrl_mod_reg_offset: offset to control module register > +- ctrl_ram_offset: offset to control module ram Should these be explicit properties, or can they be discerned from the compatible string (which should include the hardware version; see below). Also, any custom properties that are specific to a binding really should include a vendor prefix ('ti,') to avoid namespace collisions with common bindings. > +- hw_ram_addr: hardware ram addr Can this be added as a second tuple in the reg property? > +- ctrl_ram_size: size of control module ram > +- version: 1 (EMAC_VERSION_1 for DM644x) > + 2 (EMAC_VERSION_2 for DM646x) Don't use a version property. Encode it into the compatible property. ie: compatible = "ti,davinci-dm6440-emac"; or compatible = "ti,davinci-dm6460-emac"; You'll also note that I did not use a 'x' as a wildcard. It is always safer to be explicit about the part number. And have newer parts claim compatibility with older ones like so: compatible = "ti,davinci-dm6443-emac", "ti,davinci-dm6440-emac"; (I am obviously making up numbers here. Fill in appropriate numbers for your device. > +- phy-handle: Contains a phandle to an Ethernet PHY. > + if not, davinci_emac driver defaults to 100/FULL > +- interrupts: interrupt mapping for the davinci emac interrupts sources: > + 4 sources: + Receive Interrupt > + Transmit Interrupt > + Miscellaneous Interrupt> > +- pinmux-handle: Contains a handle to configure the pinmux settings. > + > +Optional properties: > +- local-mac-address : 6 bytes, mac address > + > +Example (enbw_cmc board): > + eth0: emac at 1e20000 { > + compatible = "ti,davinci-emac"; > + reg = <0x220000 0x4000>; > + ctrl_reg_offset = <0x3000>; > + ctrl_mod_reg_offset = <0x2000>; > + ctrl_ram_offset = <0>; > + hw_ram_addr = <0>; > + ctrl_ram_size = <0x2000>; > + version = <1>; > + local-mac-address = [ 00 00 00 00 00 00 ]; > + interrupts = <33 > + 34 > + 35 > + 36 > + >; > + interrupt-parent = <&intc>; > + pinmux-handle = <&emac_pins>; > + }; > diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c > index 794ac30..cad7a96 100644 > --- a/drivers/net/ethernet/ti/davinci_emac.c > +++ b/drivers/net/ethernet/ti/davinci_emac.c > @@ -58,6 +58,12 @@ > #include > #include > #include > +#include > +#include > +#include > +#include > + > +#include > > #include > #include > @@ -339,6 +345,9 @@ struct emac_priv { > u32 rx_addr_type; > atomic_t cur_tx; > const char *phy_id; > +#ifdef CONFIG_OF > + struct device_node *phy_node; > +#endif > struct phy_device *phydev; > spinlock_t lock; > /*platform specific members*/ > @@ -1582,6 +1591,7 @@ static int emac_dev_open(struct net_device *ndev) > cpdma_ctlr_start(priv->dma); > > priv->phydev = NULL; > + > /* use the first phy on the bus if pdata did not give us a phy id */ > if (!priv->phy_id) { > struct device *phy; > @@ -1759,6 +1769,104 @@ static const struct net_device_ops emac_netdev_ops = { > #endif > }; > > +#ifdef CONFIG_OF > +static struct emac_platform_data > + *davinci_emac_of_get_pdata(struct platform_device *pdev, > + struct emac_priv *priv) > +{ > + struct device_node *np; > + struct device_node *pinmux_np; > + struct emac_platform_data *pdata = NULL; > + const u8 *mac_addr; > + u32 data; > + int ret; > + struct resource temp_res; > + int irq; > + int index = 0; > + > + np = of_find_compatible_node(NULL, NULL, "ti,davinci-emac"); > + if (!np) > + goto nodata; > + > + pdata = pdev->dev.platform_data; > + if (!pdata) { > + pdata = kzalloc(sizeof(struct emac_platform_data), GFP_KERNEL); devm_kzalloc() > + if (!pdata) > + goto nodata; > + } > + > + mac_addr = of_get_mac_address(np); > + if (mac_addr) > + memcpy(pdata->mac_addr, mac_addr, ETH_ALEN); > + > + ret = of_property_read_u32(np, "ctrl_reg_offset", &data); > + if (!ret) > + pdata->ctrl_reg_offset = data; > + > + ret = of_property_read_u32(np, "ctrl_mod_reg_offset", &data); > + if (!ret) > + pdata->ctrl_mod_reg_offset = data; > + > + ret = of_property_read_u32(np, "ctrl_ram_offset", &data); > + if (!ret) > + pdata->ctrl_ram_offset = data; > + > + ret = of_property_read_u32(np, "hw_ram_addr", &data); > + if (!ret) > + pdata->hw_ram_addr = data; > + > + ret = of_property_read_u32(np, "ctrl_ram_size", &data); > + if (!ret) > + pdata->ctrl_ram_size = data; > + > + ret = of_property_read_u32(np, "rmii_en", &data); > + if (!ret) > + pdata->rmii_en = data; > + > + ret = of_property_read_u32(np, "version", &data); > + if (!ret) > + pdata->version = data; > + > + ret = of_property_read_u32(np, "no_bd_ram", &data); > + if (!ret) > + pdata->ctrl_mod_reg_offset = data; Not all these properties are mentioned in the documentation. > + > + priv->phy_node = of_parse_phandle(np, "phy-handle", 0); > + if (!priv->phy_node) > + pdata->phy_id = ""; > + > + if (!of_address_to_resource(np, 0, &temp_res)) > + memcpy(&pdev->resource[0], &temp_res, sizeof(struct resource)); Don't use of_address_to_resource. The platform device resource table will already be populated by the core code so you don't need to call it here. Besides, it is illegal for drivers to overwrite the pdev->resource[] table. > + > + index = 0; > + while (index < 4) { > + irq = irq_of_parse_and_map(np, index); > + if (irq > 0) { > + temp_res.start = irq; > + temp_res.end = irq; > + temp_res.flags = IORESOURCE_IRQ; > + memcpy(&pdev->resource[index + 1], &temp_res, > + sizeof(struct resource)); Same here, the core code will have already populated the irqs into the resource table for you. > + } > + index++; > + } > + > + pinmux_np = of_parse_phandle(np, "pinmux-handle", 0); > + if (pinmux_np) > + davinci_cfg_reg_of(pinmux_np); > + > + pdev->dev.platform_data = pdata; > +nodata: > + return pdata; > +} > +#else > +static struct emac_platform_data > + *davinci_emac_of_get_pdata(struct platform_device *pdev, > + struct emac_priv *priv) > +{ > + return pdev->dev.platform_data; > +} > +#endif > /** > * davinci_emac_probe: EMAC device probe > * @pdev: The DaVinci EMAC device that we are removing > @@ -1802,7 +1910,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev) > > spin_lock_init(&priv->lock); > > - pdata = pdev->dev.platform_data; > + pdata = davinci_emac_of_get_pdata(pdev, priv); > if (!pdata) { > dev_err(&pdev->dev, "no platform data\n"); > rc = -ENODEV; > @@ -1811,6 +1919,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev) > > /* MAC addr and PHY mask , RMII enable info from platform_data */ > memcpy(priv->mac_addr, pdata->mac_addr, 6); > + Nit: There are a few instances of unrelated whitespace changes in this patch. g. From gary at mlbassoc.com Mon Jan 30 17:08:45 2012 From: gary at mlbassoc.com (Gary Thomas) Date: Mon, 30 Jan 2012 16:08:45 -0700 Subject: [PATCH v2] davinci_nand: Fix 4 bit ECC on OMAP-L138 Message-ID: <1327964925-25573-1-git-send-email-gary@mlbassoc.com> NAND chip selects restricted to 2-5 when using HW 4BIT ECC. Using the platform device id to specify this is problematic at best and confusing at least. Let the platform data specify the actual chip select (2..5) This patch does not alter any behaviour if core_chipsel is not specified, so existing targets are unaffected. Signed-off-by: Gary Thomas --- arch/arm/mach-davinci/include/mach/nand.h | 5 ++++- drivers/mtd/nand/davinci_nand.c | 5 ++++- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-davinci/include/mach/nand.h b/arch/arm/mach-davinci/include/mach/nand.h index 0251510..2d71548 100644 --- a/arch/arm/mach-davinci/include/mach/nand.h +++ b/arch/arm/mach-davinci/include/mach/nand.h @@ -57,7 +57,10 @@ struct davinci_nand_pdata { /* platform_data */ uint32_t mask_cle; /* for packages using two chipselects */ - uint32_t mask_chipsel; + uint32_t mask_chipsel; + + /* Old way using pdev->id is confusing */ + uint32_t core_chipsel; /* board's default static partition info */ struct mtd_partition *parts; diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c index 1f34951..2072da5 100644 --- a/drivers/mtd/nand/davinci_nand.c +++ b/drivers/mtd/nand/davinci_nand.c @@ -590,8 +590,10 @@ static int __init nand_davinci_probe(struct platform_device *pdev) info->ioaddr = (uint32_t __force) vaddr; info->current_cs = info->ioaddr; - info->core_chipsel = pdev->id; + if (pdata->core_chipsel) + info->core_chipsel = pdata->core_chipsel-2; + else + info->core_chipsel = pdev->id; info->mask_chipsel = pdata->mask_chipsel; /* use nandboot-capable ALE/CLE masks by default */ -- 1.7.7.5 From olof at lixom.net Mon Jan 30 23:59:06 2012 From: olof at lixom.net (Olof Johansson) Date: Mon, 30 Jan 2012 21:59:06 -0800 Subject: [GIT PULL] DaVinci fixes for v3.3-rc In-Reply-To: References: Message-ID: Hi, On Mon, Jan 30, 2012 at 9:16 AM, Nori, Sekhar wrote: > Hi Olof, > > On Mon, Jan 30, 2012 at 04:09:37, Olof Johansson wrote: >> Hi, >> >> On Fri, Jan 27, 2012 at 9:26 AM, Nori, Sekhar wrote: >> > Hi Olof, Arnd, >> > >> > Can you please pull these DaVinci fixes for the next v3.3-rc? >> > Both the patches have not been stable tagged. The fix by me >> > is a v3.3 regression. The fix by Bas van den Berg is not critical >> > enough to get into stable kernels. >> > >> > Thanks, >> > Sekhar >> > >> > The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f: >> > ?Linus Torvalds (1): >> > ? ? ? ?Linux 3.3-rc1 >> > >> > are available in the git repository at: >> > >> > ?git://gitorious.org/linux-davinci/linux-davinci.git fixes >> > >> > Bas van den Berg (1): >> > ? ? ?ARM: davinci: DA850: remove non-existing pll1_sysclk4-7 clocks >> > >> > Sekhar Nori (1): >> > ? ? ?ARM: davinci: update mdio bus name >> >> Looks like the clock removal is almost crossing over into cleanup >> territory not a fix. In the future please help us out by briefly >> motivate why it's a fix (for something that is broken) and not a >> cleanup if it's not obvious from reading it -- noncritical fixes are >> usually saved for the next merge window instead. > > I categorized it as a fix since the path removes clocks which don't > exist in hardware. Accessing such clocks will cause undefined behavior. > > The patch description does say that the clocks don't exist in hardware. > Code without the patch is definitely outside the specification. > > In this regard, what could have been done better in the patch description? A brief note as to why this should be cleaned up in time for 3.3 instead of wait for the 3.4 merge window (i.e. explain what breaks with using the kernel if this isn't picked up). If the definitions are wrong, and there are no in-tree users of them, it's less critical to get an urgent fix in -- especially if the broken code wasn't added in this merge window. Later in the -rc release cycle this becomes more important, since technically only regressions and critical bugfixes are supposed to go in then. Anyway, I am splitting hairs here. The fix was good to go in, and I'm not looking to argue over it. :) -Olof From prakash.pm at ti.com Tue Jan 31 01:11:52 2012 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Tue, 31 Jan 2012 07:11:52 +0000 Subject: [PATCH v2 3/3] arm: da830: move NAND and NOR devices as aemif MFD slaves In-Reply-To: <4F26739F.2070305@mvista.com> References: <1327487156-10238-1-git-send-email-prakash.pm@ti.com> <1327487156-10238-3-git-send-email-prakash.pm@ti.com> <4F2016F4.2080302@mvista.com> <4F26739F.2070305@mvista.com> Message-ID: Hi Sergei, On Mon, Jan 30, 2012 at 16:10:31, Sergei Shtylyov wrote: > Hello. > > On 30-01-2012 10:58, Manjunathappa, Prakash wrote: > > >>> NAND and NOR device are made as aemif devices slave, hence device > >>> registration achieved via aemif MFD driver. > > >>> Signed-off-by: Manjunathappa, Prakash > >>> --- > >>> Since v1: > >>> Patch is generated using -M option. > > >>> arch/arm/mach-davinci/board-da830-evm.c | 31 +++++++++++++++++++++++-------- > >>> 1 files changed, 23 insertions(+), 8 deletions(-) > > >> Why only this file? Don't other board files have NAND/NOR devices? > > > Yes I thought of sending board-da850 changes in separate patch. Should I have to send those changes also in this patch? > > There's also board-dm*.c files. I'd done them all in the same patch. ok, I will consider all davinci board changes in next version of patch. Thanks, Prakash > > WBR, Sergei > From hs at denx.de Tue Jan 31 01:14:28 2012 From: hs at denx.de (Heiko Schocher) Date: Tue, 31 Jan 2012 08:14:28 +0100 Subject: [RFC PATCH 5/7] ARM: davinci: i2c: add OF support In-Reply-To: <20120130200436.GU28397@ponder.secretlab.ca> References: <1327308967-8092-1-git-send-email-hs@denx.de> <1327308967-8092-6-git-send-email-hs@denx.de> <20120130200436.GU28397@ponder.secretlab.ca> Message-ID: <4F2794D4.8060103@denx.de> Hello Grant, Grant Likely wrote: > On Mon, Jan 23, 2012 at 09:56:05AM +0100, Heiko Schocher wrote: >> add of support for the davinci i2c driver. >> >> Signed-off-by: Heiko Schocher >> Cc: davinci-linux-open-source at linux.davincidsp.com >> Cc: linux-arm-kernel at lists.infradead.org >> Cc: devicetree-discuss at lists.ozlabs.org >> Cc: linux-i2c at vger.kernel.org >> Cc: Ben Dooks >> Cc: Wolfram Sang >> Cc: Grant Likely >> Cc: Sekhar Nori >> Cc: Wolfgang Denk > > Hi Heiko, > > comments below. Thanks! >> --- >> .../devicetree/bindings/arm/davinci/i2c.txt | 39 ++++++++++++++++++ >> drivers/i2c/busses/i2c-davinci.c | 43 ++++++++++++++++++++ >> 2 files changed, 82 insertions(+), 0 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt >> >> diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt b/Documentation/devicetree/bindings/arm/davinci/i2c.txt >> new file mode 100644 >> index 0000000..94ec670 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt >> @@ -0,0 +1,39 @@ >> +* Texas Instruments Davinci I2C >> + >> +This file provides information, what the device node for the >> +davinci i2c interface contain. >> + >> +Required properties: >> +- compatible: "ti,davinci-i2c"; >> +- reg : Offset and length of the register set for the device >> +- id: id of the controller > > Don't use an 'id' property. i2c bus numbers should be dynamically > assigned when using the device tree. Yep, removed! >> + >> +Recommended properties : >> +- interrupts : where a is the interrupt number and b is a >> + field that represents an encoding of the sense and level >> + information for the interrupt. > > This is inaccurate. It is entirely defined by the interrupt > controller. All you need to say here is that this is a standard > interrupts property. fixed. >> +- interrupt-parent : the phandle for the interrupt controller that >> + services interrupts for this device. > > Don't even mention this one. It can often be inherited from a parent > node. deleted. [...] >> diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c >> index a76d85f..6f59fae 100644 >> --- a/drivers/i2c/busses/i2c-davinci.c >> +++ b/drivers/i2c/busses/i2c-davinci.c >> @@ -38,9 +38,12 @@ >> #include >> #include >> #include >> +#include >> +#include >> >> #include >> #include >> +#include >> >> /* ----- global defines ----------------------------------------------- */ >> >> @@ -635,6 +638,16 @@ static struct i2c_algorithm i2c_davinci_algo = { >> .functionality = i2c_davinci_func, >> }; >> >> +#if defined(CONFIG_OF) >> +static const struct of_device_id davinci_i2c_of_match[] = { >> + {.compatible = "ti,davinci-i2c", }, >> + {}, >> +} >> +MODULE_DEVICE_TABLE(of, davinci_i2c_of_match); >> +#else >> +#define davinci_i2c_of_match NULL >> +#endif > > The #else clause can be dropped if you use the of_match_ptr() macro > when referencing it. removed. >> + >> static int davinci_i2c_probe(struct platform_device *pdev) >> { >> struct davinci_i2c_dev *dev; >> @@ -676,7 +689,34 @@ static int davinci_i2c_probe(struct platform_device *pdev) >> dev->irq = irq->start; >> platform_set_drvdata(pdev, dev); >> >> + if ((dev->dev->platform_data == NULL) && >> + (pdev->dev.of_node)) { >> + struct device_node *pinmux_np; >> + struct davinci_i2c_platform_data *pdata; >> + u32 prop; >> + >> + dev->dev->platform_data = &davinci_i2c_platform_data_default; > > Don't do this. What if a davinci part shows up with two i2c busses? > Use devm_kzalloc() instead. Fixed. >> + pdata = &davinci_i2c_platform_data_default; >> + if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency", >> + &prop)) >> + pdata->bus_freq = prop / 1000; >> + if (!of_property_read_u32(pdev->dev.of_node, "bus-delay", >> + &prop)) >> + pdata->bus_delay = prop; >> + if (!of_property_read_u32(pdev->dev.of_node, "id", >> + &prop)) { >> + pdev->id = prop; >> + pdev->dev.init_name = kzalloc(20, GFP_KERNEL); >> + sprintf((char *)pdev->dev.init_name, >> + "i2c_davinci.%d", pdev->id); > > Blech! Drop this. Leave the core code to set the device name. completely removed. >> dev->clk = clk_get(&pdev->dev, NULL); >> + >> if (IS_ERR(dev->clk)) { > > Nit: unrelated whitespace change Ups, good catch, fixed. [...] bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany From hs at denx.de Tue Jan 31 01:31:26 2012 From: hs at denx.de (Heiko Schocher) Date: Tue, 31 Jan 2012 08:31:26 +0100 Subject: [RFC PATCH 5/7] ARM: davinci: i2c: add OF support In-Reply-To: <20120130201307.GV28397@ponder.secretlab.ca> References: <1327308967-8092-1-git-send-email-hs@denx.de> <1327308967-8092-6-git-send-email-hs@denx.de> <4F1DC480.4010603@gmail.com> <4F1E5B44.4090200@denx.de> <4F1E7F36.50505@samsung.com> <20120130201307.GV28397@ponder.secretlab.ca> Message-ID: <4F2798CE.1090804@denx.de> Hello Grant, Grant Likely wrote: > On Tue, Jan 24, 2012 at 10:51:50AM +0100, Sylwester Nawrocki wrote: >> Hello Heiko, >> >> On 01/24/2012 08:18 AM, Heiko Schocher wrote: >>>> On 01/23/2012 09:56 AM, Heiko Schocher wrote: >>>>> add of support for the davinci i2c driver. >>>>> >>>>> Signed-off-by: Heiko Schocher >>>>> Cc: davinci-linux-open-source at linux.davincidsp.com >>>>> Cc: linux-arm-kernel at lists.infradead.org >>>>> Cc: devicetree-discuss at lists.ozlabs.org >>>>> Cc: linux-i2c at vger.kernel.org >>>>> Cc: Ben Dooks >>>>> Cc: Wolfram Sang >>>>> Cc: Grant Likely >>>>> Cc: Sekhar Nori >>>>> Cc: Wolfgang Denk >>>>> --- >>>>> .../devicetree/bindings/arm/davinci/i2c.txt | 39 ++++++++++++++++++ >>>>> drivers/i2c/busses/i2c-davinci.c | 43 ++++++++++++++++++++ >>>>> 2 files changed, 82 insertions(+), 0 deletions(-) >>>>> create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt [...] >> Moreover you seem to overwrite platform device name and id, >> >> if (!of_property_read_u32(pdev->dev.of_node, "id", >> + &prop)) { >> + pdev->id = prop; >> + pdev->dev.init_name = kzalloc(20, GFP_KERNEL); >> + sprintf((char *)pdev->dev.init_name, >> + "i2c_davinci.%d", pdev->id); >> >> I'm not sure if it is a good practice. > > No, it is not good practice. At this point the device is already > registered. Changing the value of pdev->id will cause problems in the > core code because the /sysfs files will have already been created. > >> If you want to pre-define platform >> device name (likely for the clock API to work), it might be more appropriate >> to use OF_DEV_AUXDATA in the machine code, until there are clock bindings >> available. > > Yes, use OF_DEV_AUXDATA, but *only* if you need it for hooking up > clocks, regulators, or similar. Don't use it just because you want > the device to have a different name for cosmetic reasons. The need > for AUXDATA should go away once the DT clock binding code is merged. I now use OF_DEV_AUXDATA in board code, "id" nor "cell-index" used: struct of_dev_auxdata enbw_cmc_auxdata_lookup[] __initdata = { OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL), OF_DEV_AUXDATA("ti,davinci-i2c", 0x01e28000, "i2c_davinci.2", NULL), {} }; This is needed for hooking up clocks, see: arch/arm/mach-davinci/da850.c static struct clk_lookup da850_clks [...] CLK("i2c_davinci.1", NULL, &i2c0_clk), [...] CLK("i2c_davinci.2", NULL, &i2c1_clk), bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany From sshtylyov at mvista.com Tue Jan 31 04:32:25 2012 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Tue, 31 Jan 2012 14:32:25 +0400 Subject: [PATCH v2] davinci_nand: Fix 4 bit ECC on OMAP-L138 In-Reply-To: <1327964925-25573-1-git-send-email-gary@mlbassoc.com> References: <1327964925-25573-1-git-send-email-gary@mlbassoc.com> Message-ID: <4F27C339.80403@mvista.com> Hello. On 31-01-2012 3:08, Gary Thomas wrote: > NAND chip selects restricted to 2-5 when using HW 4BIT ECC. > Using the platform device id to specify this is problematic > at best and confusing at least. > Let the platform data specify the actual chip select (2..5) > This patch does not alter any behaviour if core_chipsel is > not specified, so existing targets are unaffected. The changelog is usually filled without indent. > Signed-off-by: Gary Thomas > --- > arch/arm/mach-davinci/include/mach/nand.h | 5 ++++- > drivers/mtd/nand/davinci_nand.c | 5 ++++- > 2 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-davinci/include/mach/nand.h b/arch/arm/mach-davinci/include/mach/nand.h > index 0251510..2d71548 100644 > --- a/arch/arm/mach-davinci/include/mach/nand.h > +++ b/arch/arm/mach-davinci/include/mach/nand.h > @@ -57,7 +57,10 @@ struct davinci_nand_pdata { /* platform_data */ > uint32_t mask_cle; > > /* for packages using two chipselects */ > - uint32_t mask_chipsel; > + uint32_t mask_chipsel; I still don't understand why you have to change this line... > + > + /* Old way using pdev->id is confusing */ > + uint32_t core_chipsel; uint8_t would have been enough... althought I don't undesrtand why these types are used there at all -- they are intendede for userland. > diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c > index 1f34951..2072da5 100644 > --- a/drivers/mtd/nand/davinci_nand.c > +++ b/drivers/mtd/nand/davinci_nand.c > @@ -590,8 +590,10 @@ static int __init nand_davinci_probe(struct platform_device *pdev) > info->ioaddr = (uint32_t __force) vaddr; > > info->current_cs = info->ioaddr; > - info->core_chipsel = pdev->id; > + if (pdata->core_chipsel) > + info->core_chipsel = pdata->core_chipsel-2; Kernel style assumen spaces between operands and operator. WBR, Sergei From hs at denx.de Tue Jan 31 05:27:11 2012 From: hs at denx.de (Heiko Schocher) Date: Tue, 31 Jan 2012 12:27:11 +0100 Subject: [RFC PATCH 4/7] ARM: davinci: net: davinci_emac: add OF support In-Reply-To: <20120130202208.GW28397@ponder.secretlab.ca> References: <1327308967-8092-1-git-send-email-hs@denx.de> <1327308967-8092-5-git-send-email-hs@denx.de> <20120130202208.GW28397@ponder.secretlab.ca> Message-ID: <4F27D00F.4040807@denx.de> Hello Grant, Grant Likely wrote: > On Mon, Jan 23, 2012 at 09:56:04AM +0100, Heiko Schocher wrote: >> add of support for the davinci_emac driver. >> >> Signed-off-by: Heiko Schocher >> Cc: davinci-linux-open-source at linux.davincidsp.com >> Cc: linux-arm-kernel at lists.infradead.org >> Cc: devicetree-discuss at lists.ozlabs.org >> Cc: netdev at vger.kernel.org >> Cc: Grant Likely >> Cc: Sekhar Nori >> Cc: Wolfgang Denk >> --- >> .../bindings/arm/davinci/davinci_emac.txt | 46 ++++++++ >> drivers/net/ethernet/ti/davinci_emac.c | 111 +++++++++++++++++++- >> 2 files changed, 156 insertions(+), 1 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt >> >> diff --git a/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt >> new file mode 100644 >> index 0000000..4e5dc8d >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt >> @@ -0,0 +1,46 @@ >> +* Texas Instruments Davinci EMAC >> + >> +This file provides information, what the davice node >> +for the davinci_emac interface contain. >> + >> +Required properties: >> +- compatible: "ti,davinci-emac"; >> +- reg: Offset and length of the register set for the device >> +- ctrl_reg_offset: offset to control register >> +- ctrl_mod_reg_offset: offset to control module register >> +- ctrl_ram_offset: offset to control module ram > > Should these be explicit properties, or can they be discerned from the > compatible string (which should include the hardware version; see > below). Hmm.. I do not know all davinci SoCs ... maybe someone from TI could answer this? But I think, we could discern this from the compatible string. I prepare this for v2. Maybe it is Ok, if I do this only for my hardwareversion and others add this, if needed? (maybe the better approach, as I can code it, but have no hw for testing it ... so it maybe is buggy) > Also, any custom properties that are specific to a binding really > should include a vendor prefix ('ti,') to avoid namespace collisions > with common bindings. Yep, is "ti,davinci-" ok? Also I should use dashes instead underscores, right? >> +- hw_ram_addr: hardware ram addr > > Can this be added as a second tuple in the reg property? No, if I know this right, this is used for DMA, and also could be RAM. >> +- ctrl_ram_size: size of control module ram >> +- version: 1 (EMAC_VERSION_1 for DM644x) >> + 2 (EMAC_VERSION_2 for DM646x) > > Don't use a version property. Encode it into the compatible property. ie: > > compatible = "ti,davinci-dm6440-emac"; or > compatible = "ti,davinci-dm6460-emac"; > > You'll also note that I did not use a 'x' as a wildcard. It is always > safer to be explicit about the part number. And have newer parts > claim compatibility with older ones like so: > > compatible = "ti,davinci-dm6443-emac", "ti,davinci-dm6440-emac"; (I am > obviously making up numbers here. Fill in appropriate numbers for > your device. Ok. [...] >> diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c >> index 794ac30..cad7a96 100644 >> --- a/drivers/net/ethernet/ti/davinci_emac.c >> +++ b/drivers/net/ethernet/ti/davinci_emac.c >> @@ -58,6 +58,12 @@ [...] >> + pdata = pdev->dev.platform_data; >> + if (!pdata) { >> + pdata = kzalloc(sizeof(struct emac_platform_data), GFP_KERNEL); > > devm_kzalloc() fixed. >> + if (!pdata) >> + goto nodata; >> + } >> + >> + mac_addr = of_get_mac_address(np); >> + if (mac_addr) >> + memcpy(pdata->mac_addr, mac_addr, ETH_ALEN); >> + >> + ret = of_property_read_u32(np, "ctrl_reg_offset", &data); >> + if (!ret) >> + pdata->ctrl_reg_offset = data; >> + >> + ret = of_property_read_u32(np, "ctrl_mod_reg_offset", &data); >> + if (!ret) >> + pdata->ctrl_mod_reg_offset = data; >> + >> + ret = of_property_read_u32(np, "ctrl_ram_offset", &data); >> + if (!ret) >> + pdata->ctrl_ram_offset = data; >> + >> + ret = of_property_read_u32(np, "hw_ram_addr", &data); >> + if (!ret) >> + pdata->hw_ram_addr = data; >> + >> + ret = of_property_read_u32(np, "ctrl_ram_size", &data); >> + if (!ret) >> + pdata->ctrl_ram_size = data; >> + >> + ret = of_property_read_u32(np, "rmii_en", &data); >> + if (!ret) >> + pdata->rmii_en = data; >> + >> + ret = of_property_read_u32(np, "version", &data); >> + if (!ret) >> + pdata->version = data; >> + >> + ret = of_property_read_u32(np, "no_bd_ram", &data); >> + if (!ret) >> + pdata->ctrl_mod_reg_offset = data; > > Not all these properties are mentioned in the documentation. fixed. >> + >> + priv->phy_node = of_parse_phandle(np, "phy-handle", 0); >> + if (!priv->phy_node) >> + pdata->phy_id = ""; >> + >> + if (!of_address_to_resource(np, 0, &temp_res)) >> + memcpy(&pdev->resource[0], &temp_res, sizeof(struct resource)); > > Don't use of_address_to_resource. The platform device resource table > will already be populated by the core code so you don't need to call > it here. Besides, it is illegal for drivers to overwrite the > pdev->resource[] table. fix this. >> + >> + index = 0; >> + while (index < 4) { >> + irq = irq_of_parse_and_map(np, index); >> + if (irq > 0) { >> + temp_res.start = irq; >> + temp_res.end = irq; >> + temp_res.flags = IORESOURCE_IRQ; >> + memcpy(&pdev->resource[index + 1], &temp_res, >> + sizeof(struct resource)); > > Same here, the core code will have already populated the irqs into the > resource table for you. and this. Currently it don't work after this fix, searching for the reason ... >> + } >> + index++; >> + } >> + >> + pinmux_np = of_parse_phandle(np, "pinmux-handle", 0); >> + if (pinmux_np) >> + davinci_cfg_reg_of(pinmux_np); >> + >> + pdev->dev.platform_data = pdata; >> +nodata: >> + return pdata; >> +} >> +#else >> +static struct emac_platform_data >> + *davinci_emac_of_get_pdata(struct platform_device *pdev, >> + struct emac_priv *priv) >> +{ >> + return pdev->dev.platform_data; >> +} >> +#endif >> /** >> * davinci_emac_probe: EMAC device probe >> * @pdev: The DaVinci EMAC device that we are removing >> @@ -1802,7 +1910,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev) >> >> spin_lock_init(&priv->lock); >> >> - pdata = pdev->dev.platform_data; >> + pdata = davinci_emac_of_get_pdata(pdev, priv); >> if (!pdata) { >> dev_err(&pdev->dev, "no platform data\n"); >> rc = -ENODEV; >> @@ -1811,6 +1919,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev) >> >> /* MAC addr and PHY mask , RMII enable info from platform_data */ >> memcpy(priv->mac_addr, pdata->mac_addr, 6); >> + > > Nit: There are a few instances of unrelated whitespace changes in this > patch. fixed. Thanks for the review! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany From sudhakar.raj at ti.com Tue Jan 31 05:30:51 2012 From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar) Date: Tue, 31 Jan 2012 11:30:51 +0000 Subject: [RFC 1/2] mmc: davinci: Eliminate spurious interrupts In-Reply-To: <1327403766-962-1-git-send-email-ido@wizery.com> References: <4F1E9194.90608@mvista.com> <1327403766-962-1-git-send-email-ido@wizery.com> Message-ID: Hi, On Tue, Jan 24, 2012 at 16:46:05, Ido Yariv wrote: > The davinci mmc interrupt handler fills the fifo, as long as the DXRDY > or DRRDY bits are set in the status register. > > If interrupts fire during this loop, they will be handled by the > handler, but the interrupt controller will still buffer these. As a > result, the handler will be called again to serve these needlessly. In > order to avoid these spurious interrupts, keep interrupts masked while > filling the fifo. > > Signed-off-by: Ido Yariv > --- Tested this series on OMAP-L138 EVM using SD card. Observed that number of interrupts during IO transaction were less compared to earlier and there was no drop in performance numbers. Tested-by: Rajashekhara, Sudhakar Regards, Sudhakar From hs at denx.de Tue Jan 31 07:04:32 2012 From: hs at denx.de (Heiko Schocher) Date: Tue, 31 Jan 2012 14:04:32 +0100 Subject: [RFC PATCH 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board In-Reply-To: <20120130203252.GX28397@ponder.secretlab.ca> References: <1327308967-8092-1-git-send-email-hs@denx.de> <1327308967-8092-8-git-send-email-hs@denx.de> <20120130203252.GX28397@ponder.secretlab.ca> Message-ID: <4F27E6E0.1050608@denx.de> Hello Grant, Grant Likely wrote: > On Mon, Jan 23, 2012 at 09:56:07AM +0100, Heiko Schocher wrote: >> - AM1808 based board >> - 64 MiB DDR ram >> - 2 MiB Nor flash >> - 128 MiB NAND flash >> - use internal RTC >> - I2C support >> - hwmon lm75 support >> - UBI/UBIFS support >> - MMC support >> - USB OTG support >> >> Signed-off-by: Heiko Schocher >> Cc: linux-arm-kernel at lists.infradead.org >> Cc: devicetree-discuss at lists.ozlabs.org >> Cc: davinci-linux-open-source at linux.davincidsp.com >> Cc: linux-mtd at lists.infradead.org >> Cc: linux-i2c at vger.kernel.org >> Cc: netdev at vger.kernel.org >> Cc: David Woodhouse >> Cc: Ben Dooks >> Cc: Wolfram Sang >> Cc: Sekhar Nori >> Cc: Kevin Hilman >> Cc: Wolfgang Denk >> >> --- >> - post this board support with USB support, even though >> USB is only working with the 10 ms "workaround", posted here: >> http://comments.gmane.org/gmane.linux.usb.general/54505 >> I see this issue also on the AM1808 TMDXEXP1808L evalboard. >> - MMC and USB are not using OF support yet, ideas how to port >> this are welcome. I need for USB and MMC boards board >> specific callbacks, how to solve this with OF support? Can you give me a hint, how to add callbacks to OF support? >> arch/arm/boot/dts/enbw_cmc.dts | 286 +++++++++++++++++ >> arch/arm/configs/enbw_cmc_defconfig | 125 ++++++++ >> arch/arm/mach-davinci/Kconfig | 8 + >> arch/arm/mach-davinci/Makefile | 1 + >> arch/arm/mach-davinci/board-enbw-cmc.c | 384 +++++++++++++++++++++++ >> arch/arm/mach-davinci/include/mach/uncompress.h | 1 + >> 6 files changed, 805 insertions(+), 0 deletions(-) >> create mode 100644 arch/arm/boot/dts/enbw_cmc.dts >> create mode 100644 arch/arm/configs/enbw_cmc_defconfig >> create mode 100644 arch/arm/mach-davinci/board-enbw-cmc.c >> >> diff --git a/arch/arm/boot/dts/enbw_cmc.dts b/arch/arm/boot/dts/enbw_cmc.dts >> new file mode 100644 >> index 0000000..e5995ce >> --- /dev/null >> +++ b/arch/arm/boot/dts/enbw_cmc.dts >> @@ -0,0 +1,286 @@ >> +/* >> + * Device Tree for the EnBW CMC plattform >> + * >> + * Copyright 2011 DENX Software Engineering GmbH >> + * Heiko Schocher >> + * >> + * This program is free software; you can redistribute it and/or modify it >> + * under the terms of the GNU General Public License as published by the >> + * Free Software Foundation; either version 2 of the License, or (at your >> + * option) any later version. >> + */ >> +/dts-v1/; >> +/include/ "skeleton.dtsi" >> + >> +/ { >> + model = "EnBW CMC"; >> + compatible = "enbw,cmc"; >> + >> + aliases { >> + ethernet0 = ð0; >> + }; >> + >> + arm { >> + #address-cells = <1>; >> + #size-cells = <1>; >> + ranges = <0 0xfffee000 0x00020000>; >> + intc: interrupt-controller at 1 { >> + compatible = "ti,davinci-intc"; >> + interrupt-controller; >> + #interrupt-cells = <1>; >> + ti,intc-size = <101>; >> + reg = <0x0 0x2000>; >> + }; >> + }; >> + soc at 1c00000 { >> + compatible = "ti,da8xx"; > > As previously mentioned, using wildcard ('x') characters in compatible > properties is bad practice. Always be specific and use the compatible > list to make sure the correct driver gets bound (assuming the device > is 100% register level compatible with the older one). fixed. >> + #address-cells = <1>; >> + #size-cells = <1>; >> + ranges = <0x0 0x01c00000 0x400000>; >> + >> + serial0: serial at 1c42000 { >> + cell-index = <2>; > > As previously mentioned, don't use cell index. If you *really* need > to assign a number to a device, then use a property in the /aliases > node and make sure pdev->id does *not* get modified. removed, as not needed. >> + compatible = "ns16550a"; > > Should include a string for the specific device. Something like: > > compatible = "ti,da800", "ns16550a"; added. >> diff --git a/arch/arm/mach-davinci/board-enbw-cmc.c b/arch/arm/mach-davinci/board-enbw-cmc.c >> new file mode 100644 >> index 0000000..4473c4a >> --- /dev/null >> +++ b/arch/arm/mach-davinci/board-enbw-cmc.c >> @@ -0,0 +1,384 @@ [...] >> +#if defined(CONFIG_OF) >> +static __init void enbw_cmc_usb_init(void) > > All the focus is on DT now. How about making CONFIG_OF required for > this board? Also, this is just another board file. The focus should fixed. > be on creating a generic board support file for DT platforms. move the arch/arm/mach-davinci/board-enbw-cmc.c to arch/arm/mach-davinci/board-da850_simple.c and do it like arch/powerpc/platforms/52xx/mpc5200_simple.c ? and extract common nodes from arch/arm/boot/dts/enbw_cmc.dts to arch/arm/boot/dts/da850.dtsi? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany From m-karicheri2 at ti.com Tue Jan 31 15:21:03 2012 From: m-karicheri2 at ti.com (Karicheri, Muralidharan) Date: Tue, 31 Jan 2012 21:21:03 +0000 Subject: UBIFS with davinci NAND driver - ECC error Message-ID: <3E54258959B69E4282D79E01AB1F32B72747DF@DFLE34.ent.ti.com> Hi, I am trying to use UBIFS in my project and we are using the davinci nand driver with a flash part that has page size of 2048, block size of 128KiB and size of 128MiB. I have done following to boot the kernel with a UBIFS rootfs. sudo mkfs.ubifs -r arago-rootfs-ubi -m 2048 -e 129024 -c 960 -o ubifs.img -x zlib 2) Boot up Linux using rootfs that has ubi mtdutils 3) ubinize the image using the following ubi.cfg from the target. [ubifs] mode=ubi image=ubifs.img vol_id=0 vol_size=110MiB vol_type=dynamic vol_name=rootfs vol_flags=autoresize > ubinize -o ubi1.img -m 2048 -p 128KiB -s 512 ubi.cfg 4) erase the partition and flash it >flash_erase /dev/mtd3 0 0 >nandwrite -p /dev/mtd3 /ubi1.img 5) reboot and setup following env variables in u-boot setenv bootargs 'console=ttyS0,115200n8 root=ubi0:rootfs ubi.mtd=3 rw rootfstype=ubifs' saveenv boot See following during boot:- davinci_nand davinci_nand.0: controller rev. 2.5 UBI: attaching mtd3 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 129024 bytes UBI: smallest flash I/O unit: 2048 UBI: sub-page size: 512 UBI: VID header offset: 512 (aligned 512) UBI: data offset: 2048 UBI: max. sequence number: 0 UBI: volume 0 ("rootfs") re-sized from 894 to 963 LEBs UBI: attached mtd3 to ubi0 UBI: MTD device name: "filesystem" UBI: MTD device size: 122 MiB UBI: number of good PEBs: 976 UBI: number of bad PEBs: 4 UBI: number of corrupted PEBs: 0 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold: 4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 1 UBI: available PEBs: 0 UBI: total number of reserved PEBs: 976 UBI: number of PEBs reserved for bad PEB handling: 9 UBI: max/mean erase counter: 1/0 UBI: image sequence number: 1997956010 UBI: background thread "ubi_bgt0d" started, PID 248 And then I get the following ECC error:- VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3 UBIFS: mounted UBI device 0, volume 0, name "rootfs" UBIFS: file system size: 122830848 bytes (119952 KiB, 117 MiB, 952 LEBs) UBIFS: journal size: 9033728 bytes (8822 KiB, 8 MiB, 71 LEBs) UBIFS: media format: w4/r0 (latest is w4/r0) UBIFS: default compressor: zlib UBIFS: reserved for root: 0 bytes (0 KiB) VFS: Mounted root (ubifs filesystem) on device 0:12. Freeing init memory: 124K modprobe: FATAL: Could not load /lib/modules/3.2.0-00103-gee5968d-dirty/modules.dep: No such fil e or directory modprobe: FATAL: Could not load /lib/modules/3.2.0-00103-gee5968d-dirty/modules.dep: No such fil e or directory INIT: version 2.86 booting Please wait: booting... Starting udev WARNING: -e needs -E or -F UBI error: ubi_io_read: error -74 (ECC error) while reading 76 bytes from PEB 62:104104, read 76 bytes UBI error: ubi_io_read: error -74 (ECC error) while reading 81 bytes from PEB 62:106240, read 81 bytes UBI error: ubi_io_read: error -74 (ECC error) while reading 75 bytes from PEB 62:108416, read 75 bytes UBI error: ubi_io_read: error -74 (ECC error) while reading 32 bytes from PEB 62:110560, read 32 bytes UBI error: ubi_io_read: error -74 (ECC error) while reading 77 bytes from PEB 62:111992, read 77 bytes UBI error: ubi_io_read: error -74 (ECC error) while reading 77 bytes from PEB 62:114256, read 77 bytes udevd (310): /proc/310/oom_adj is deprecated, please use /proc/310/oom_score_adj instead. And then I reboot again, Kernel panic with due to ECC error and Kernel is unable to mount the rootfs. And then I see that subpage write has problem with davinci NAND driver from the following post and tried disabling The subpage write as suggested in the post http://davinci-linux-open-source.1494791.n2.nabble.com/UBI-crashes-fixing-NAND-subpage-writes-td5485828.html But that also gave me the same result. Any suggestion on how to fix this? Thanks. Murali Karicheri Software Design Engineer email: m-karicheri2 at ti.com Phone: (301) 407 9583 From sudhakar.raj at ti.com Tue Jan 31 22:47:44 2012 From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar) Date: Wed, 1 Feb 2012 04:47:44 +0000 Subject: UBIFS with davinci NAND driver - ECC error In-Reply-To: <3E54258959B69E4282D79E01AB1F32B72747DF@DFLE34.ent.ti.com> References: <3E54258959B69E4282D79E01AB1F32B72747DF@DFLE34.ent.ti.com> Message-ID: Hi Murali, On Wed, Feb 01, 2012 at 02:51:03, Karicheri, Muralidharan wrote: > Hi, > > I am trying to use UBIFS in my project and we are using the davinci > nand driver with a flash part that has page size of 2048, block size > of 128KiB and size of 128MiB. I have done following to boot the kernel > with a UBIFS rootfs. > Please refer to http://processors.wiki.ti.com/index.php/UBIFS_Support which has steps to get UBIFS working on AM335x. But I followed these steps and was able to get UBIFS working on OMAP-L138. The bootargs I used from U-Boot are as below: setenv bootargs mem=32M console=ttyS2,115200n8 root=ubi0:rootfs rw rootfstype=ubifs ubi.mtd=4,2048 ip=dhcp Note that I also faced similar booting issues when I was using mkfs.ubifs version 1.3 on the host system to generate the UBIFS file system. The issue went away when I used v 1.4.8. Thanks, Sudhakar