RE: dm644x DDR2 interface
Hello Gabriele, On Mon, Mar 15, 2010 at 21:34:07, Gabriele Filosofi wrote: > Hi all. > > This is a hardware issue. > > At the beginning of paragraph 2 "DM644x DDR2 Supported Devices" of the > document SPRAAC5F, I read: > > > > "The DM644x DDR2 interface supports JEDEC DDR2 x16 devices. Supported > densities are 256 Mb, 512Mb, and 1Gb in the x16 device width." > > > > Really, SPRAAC5F deals only with x16 devices. > > > > The question is: > > does dm6446 support x32 devices? I think so, but the statement quoted > above doesn't tell it. Can you please post this on http://e2e.ti.com? The right folks to answer this would be tracking those forums. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: NAND ECC and filesystem with git DM355 - JFFS2, UBIFS, YAFFS2?
Hi Jon, what's up? :) > Trying to move from TI beta SDK MV kernel + u-boot, to git on DM355. > I find I am reopening the can of worms that is NAND ECC and filesystem > choice. LOL. I remember "something" of all this stuff too.. :D > Having booted a new kernel and apparently messed up my NAND flash > somehow (lots of bad blocks, clobbered BBTs; investigating), I am > looking for any clues about what might have changed in terms of NAND/ECC > handling, and also what filesystem people are using with the git kernel > on DM355 NAND - YAFFS2? JFFS2? UBIFS (which I don't know much about)? ... > Hints or war stories appreciated, thanks. My latest story is about 2.6.18, I found that I should disable CONFIG_DAVINCI_NAND_STD_LAYOUT in order to have a working NAND, although Linux made a "little of" confusion reading the bbt table. My solution was to purge the BBT table from u-boot, recompile 2.6.18 kernel without NAND_STD_LAYOUT, and rewrite all stuff into the NAND (uboot,kernel,rootfs). I don't know if git kernel has the same problems, but this is just how we rescued our board. bye! ( happy to know that NAND with git will continue to be a pain ) -- Andrea Gasparini ImaVis S.r.l. web: www.imavis.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] Davinci SDIO Support
Hi Alagu, On Mon, Mar 15, 2010 at 18:12:43, alagusan...@embwise.com wrote: > From: Alagu Sankar > > Added SDIO Support for Davinci Platforms. This is tested with DM355 and DM365 > EVM platforms using Libertas driver with SD8686 and SD8688 SDIO WiFi cards. > There is a hack to support Libertas firmware download. This hack may not be > required for other SDIO cards. Can you please separate the 'hack' from the actual patch adding the basic support. That way folks can review them separately and hopefully someone with a different WLAN card can say if the 'hack' is really required for all cards. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: NAND ECC and filesystem with git DM355 - JFFS2, UBIFS, YAFFS2?
On Wednesday 17 March 2010 11:07:19 am Andrea Gasparini wrote: > Hi Jon, > what's up? :) > > > Trying to move from TI beta SDK MV kernel + u-boot, to git on DM355. > > I find I am reopening the can of worms that is NAND ECC and filesystem > > choice. > > LOL. I remember "something" of all this stuff too.. :D > > > Having booted a new kernel and apparently messed up my NAND flash > > somehow (lots of bad blocks, clobbered BBTs; investigating), I am > > looking for any clues about what might have changed in terms of NAND/ECC > > handling, and also what filesystem people are using with the git kernel > > on DM355 NAND - YAFFS2? JFFS2? UBIFS (which I don't know much about)? > > ... > > > Hints or war stories appreciated, thanks. > > My latest story is about 2.6.18, I found that I should disable > CONFIG_DAVINCI_NAND_STD_LAYOUT in order to have a working NAND, although > Linux made a "little of" confusion reading the bbt table. > > My solution was to purge the BBT table from u-boot, recompile 2.6.18 kernel > without NAND_STD_LAYOUT, and rewrite all stuff into the NAND > (uboot,kernel,rootfs). > > I don't know if git kernel has the same problems, but this is just how we > rescued our board. > My experience was latest u-boot was consistent with latest kernels but ubl(and rbl) was using a different layout thus no ubl updates from kernel or u-boot which is not good. When transiting from an older u-boot(or kernel) to a newer one nand bbt should be erased or new u-boot will mark all pages bad. > > bye! ( happy to know that NAND with git will continue to be a pain ) > A little, not that much. Regards, Caglar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: NAND ECC and filesystem with git DM355 - JFFS2, UBIFS, YAFFS2?
> On Wednesday 17 March 2010 11:07:19 am Andrea Gasparini wrote: >> Hi Jon, >> what's up? :) Hey Andrea, same old same old :) >>> the git kernel on DM355 NAND - YAFFS2? JFFS2? UBIFS (which I don't Having looked a little at this it seems UBIFS is promoted nowadays. I will try that instead of YAFFS2. Anyone using it already? >> My latest story is about 2.6.18, I found that I should disable >> CONFIG_DAVINCI_NAND_STD_LAYOUT in order to have a working NAND, >> although Linux made a "little of" confusion reading >> the bbt table. >> >> My solution was to purge the BBT table from u-boot, recompile 2.6.18 >> kernel without NAND_STD_LAYOUT, and rewrite all stuff into the NAND >> (uboot,kernel,rootfs). >> >> I don't know if git kernel has the same problems, but this is just >> how we rescued our board. OK, thanks for the clues. If we have to do a watershed-upgrade of everything to latest versions then we can do that. Çaglar AKYÜZ wrote: > My experience was latest u-boot was consistent with latest kernels > but ubl(and rbl) was using a different layout thus no ubl updates > from kernel or u-boot which is not good. No that is not good.. We would really like to be able to write the ubl from linux. I wonder if we can write raw and calculate the ECC ourselves in software for the RBL a.k.a. "wrong" style. If u-boot was incompatible with ubl, did you use u-boot to write itself? I am wondering how ubl read u-boot if u-boot was written with different layout. > When transiting from an > older u-boot(or kernel) to a newer one nand bbt should be erased or > new u-boot will mark all pages bad. Did you find it was just the bbt format that had changed, or the ECC layout inside each page? >> bye! ( happy to know that NAND with git will continue to be a pain ) > > A little, not that much. I hope not too much.. Thanks, -- Jon Povey jon.po...@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 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: NAND ECC and filesystem with git DM355 - JFFS2, UBIFS, YAFFS2?
On Wednesday 17 March 2010 12:10:52 pm Jon Povey wrote: [...] > Çaglar AKYÜZ wrote: > > My experience was latest u-boot was consistent with latest kernels > > but ubl(and rbl) was using a different layout thus no ubl updates > > from kernel or u-boot which is not good. > > No that is not good.. We would really like to be able to write the ubl from > linux. I wonder if we can write raw and calculate the ECC ourselves in > software for the RBL a.k.a. "wrong" style. > > If u-boot was incompatible with ubl, did you use u-boot to write itself? I > am wondering how ubl read u-boot if u-boot was written with different > layout. > TI flash programming utility writes ubl and u-boot. Since ubl reads u-boot into nand no problem occurs there. > > When transiting from an > > older u-boot(or kernel) to a newer one nand bbt should be erased or > > new u-boot will mark all pages bad. > > Did you find it was just the bbt format that had changed, or the ECC layout > inside each page? > I guess ECC was different because ubl was not reading anything written by u- boot(or kernel). That was where I lost track of all. Infix ECC, different layouts supported by newer chips, etc. Regards, Caglar > >> bye! ( happy to know that NAND with git will continue to be a pain ) > > > > A little, not that much. > > I hope not too much.. > > Thanks, > ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] i2c: Set SCL pin to gpio functionality before bus recovery
From: Philby John
Date: Wed, 17 Mar 2010 16:20:12 +0530
Subject: [PATCH] Set SCL pin to gpio functionality before bus recovery
Before using the SCL pin, set it to GPIO by conditionally
checking the i2c revision id for peripherals that match 0x05.
Clean up data structures along the way.
Signed-off-by: Philby John
---
arch/arm/mach-davinci/board-dm355-evm.c |1 -
arch/arm/mach-davinci/board-dm644x-evm.c |1 -
arch/arm/mach-davinci/include/mach/i2c.h |3 +--
drivers/i2c/busses/i2c-davinci.c | 19 ---
4 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index aa48e3f..f4cbf54 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -111,7 +111,6 @@ static struct platform_device davinci_nand_device = {
static struct davinci_i2c_platform_data i2c_pdata = {
.bus_freq = 400 /* kHz */,
.bus_delay = 0 /* usec */,
- .sda_pin= 15,
.scl_pin= 14,
};
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 976e11b..19508e3 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -629,7 +629,6 @@ static struct i2c_board_info __initdata i2c_info[] = {
static struct davinci_i2c_platform_data i2c_pdata = {
.bus_freq = 20 /* kHz */,
.bus_delay = 100 /* usec */,
- .sda_pin= 44,
.scl_pin= 43,
};
diff --git a/arch/arm/mach-davinci/include/mach/i2c.h
b/arch/arm/mach-davinci/include/mach/i2c.h
index 39fdcea..95894ca 100644
--- a/arch/arm/mach-davinci/include/mach/i2c.h
+++ b/arch/arm/mach-davinci/include/mach/i2c.h
@@ -16,8 +16,7 @@
struct davinci_i2c_platform_data {
unsigned intbus_freq; /* standard bus frequency (kHz) */
unsigned intbus_delay; /* post-transaction delay (usec) */
- unsigned intsda_pin;/* GPIO pin ID to use for SDA */
- unsigned intscl_pin;/* GPIO pin ID to use for SCL */
+ unsigned intscl_pin;/* GPIO pin ID to use for SCL */
};
/* for board setup code */
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 7a28e60..df909e3 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -64,6 +64,7 @@
#define DAVINCI_I2C_IVR_REG0x28
#define DAVINCI_I2C_EMDR_REG 0x2c
#define DAVINCI_I2C_PSC_REG0x30
+#define DAVINCI_I2C_REVID2_REG 0x38
#define DAVINCI_I2C_IVR_AAS0x07
#define DAVINCI_I2C_IVR_SCD0x06
@@ -133,11 +134,21 @@ static inline u16 davinci_i2c_read_reg(struct
davinci_i2c_dev *i2c_dev, int reg)
}
/* Generate a pulse on the i2c clock pin. */
-static void generic_i2c_clock_pulse(unsigned int scl_pin)
+static void generic_i2c_clock_pulse(unsigned int revid, unsigned int scl_pin)
{
u16 i;
+ int ret;
if (scl_pin) {
+ if (revid == 0x05) {
+ ret = gpio_request(scl_pin, "SCL Pin\n");
+ if (ret) {
+ pr_warning("gpio request pin %d failed\n",
+ scl_pin);
+ return;
+ }
+ gpio_direction_output(scl_pin, 1);
+ }
/* Send high and low on the SCL line */
for (i = 0; i < 9; i++) {
gpio_set_value(scl_pin, 0);
@@ -162,8 +173,10 @@ static void i2c_recover_bus(struct davinci_i2c_dev *dev)
flag |= DAVINCI_I2C_MDR_NACK;
/* write the data into mode register */
davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
- if (pdata)
- generic_i2c_clock_pulse(pdata->scl_pin);
+ if (pdata) {
+ flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_REVID2_REG);
+ generic_i2c_clock_pulse(flag, pdata->scl_pin);
+ }
/* Send STOP */
flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
flag |= DAVINCI_I2C_MDR_STP;
--
1.6.3.3.311.g7ec7
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus
On 03/17/2010 02:20 AM, Kevin Hilman wrote:
Philby John writes:
On 02/08/2010 04:05 PM, Nori, Sekhar wrote:
Hi Philby,
On Fri, Feb 05, 2010 at 19:23:43, Philby John wrote:
Hello Sekhar,
[...]
+/* Generate a pulse on the i2c clock pin. */
+static void generic_i2c_clock_pulse(unsigned int scl_pin)
+{
+ u16 i;
+
+ if (scl_pin) {
+ /* Send high and low on the SCL line */
+ for (i = 0; i< 9; i++) {
+ gpio_set_value(scl_pin, 0);
+ udelay(20);
+ gpio_set_value(scl_pin, 1);
+ udelay(20);
+ }
Before using the pins as GPIO, you would have to set the
functionality of these pins as GPIO. You had this code in
previous incarnations of this patch - not sure why it is
dropped now.
I now think that the previous versions were incorrect since
davinci_cfg_reg() does not set the scl or sda pins for gpio
functionality. Instead they set them as scl or sda which is not what
we want at the time of pulsing. The previous versions used
gpio_set_value() in disable_i2c_pins() and then called
davinci_cfg_reg(). After which it called pulse_i2c_clock().
Please correct me if my interpretation of the code is incorrect.
Can we get some resolution here?
I have a queue of davinci i2c patches waiting to go upstream, and I'd
like to get them in for 2.6.35.
The current i2c series is in the 'davinci-i2c' branch of davinci git.
To quote Sekhar, "...Right. It is only an enhancement (and only good
to have at that). This should not stop the current patch from getting
in." So this patch is good to make it to 2.6.35
Please submit an updated version so we can get this stuff upstream.
Right, the enhancement has now been sent.
Regards,
Philby
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2] davinci: MMC: Pass number of SG segments as platform data
Hi, On Tue, Mar 16, 2010 at 03:10:37, Andrew Morton wrote: > On Fri, 12 Mar 2010 18:04:09 +0530 > Sudhakar Rajashekhara wrote: > > > On some platforms like DM355, the number of EDMA parameter > > slots available for EDMA_SLOT_ANY usage are few. In such cases, > > if MMC/SD uses 16 slots for each instance of MMC controller, > > then the number of slots available for other modules will be > > very few. > > > > By passing the number of EDMA slots to be used in MMC driver > > from platform data, EDMA slots available for other purposes > > can be controlled. > > It's unclear what the runtime effects of this change are. I assumed > (without justification) that they're minor and I scheduled the patch for > 2.6.35. > > If that was the wrong decision then blame the changelog ;) > Most of the platforms will not use this platform data variable. But on DM355, as the number of EDMA resources available is limited, the number of scatter- gather segments used inside the MMC driver can be 8 (passed as platform data) instead of 16. On DM355, when the number of scatter-gather segments was reduced to 8, I saw a performance difference of about 0.25-0.4 Mbytes/sec during write. Read performance variations were negligible. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Custom pinmuxing on DM355 with git kernel
On Fri, Mar 12, 2010 at 7:06 PM, Mike Williamson wrote: > > > On Fri, Mar 12, 2010 at 5:18 PM, Kevin Hilman > wrote: >> >> "Nori, Sekhar" writes: >> >> > On Thu, Mar 11, 2010 at 11:45:47, Jon Povey wrote: >> >> Steve Chen wrote: >> >> > On Wed, Mar 10, 2010 at 12:49 AM, Jon Povey >> >> > wrote: >> >> >> >> >> We have 3 different boards using DM355, with different gpio / pinmux >> >> >> setups. So far, our device drivers are modules which fiddle the >> >> >> pinmux registers directly. >> >> >> >> >> At the moment I am thinking that I might want to split up >> >> >> davinci_cfg_reg into two functions so it's not hardwired to >> >> >> soc_info->pinmux_pins, and I could pass my own mux_config structs >> >> >> in. If this is of interest I can have a go at doing this and >> >> >> submitting the patch here. >> >> > >> >> > For board specific pinmux, you can put them in board-dm355-*.c. >> >> > There are some board specific pinmux setup in board-da830-evm.c. >> >> > Look for da8xx_pinmux_setup. >> >> >> >> Thanks, I see this. I have also been looking at the gpiolib support and >> >> something like that would be useful. >> >> >> >> At minimum it would be helpful to split out the davinci_cfg_reg stuff >> >> as >> >> described above so that driver modules can use the same functions. >> > >> > Methods of handing pinmux were debated at length on this list. I think >> > this >> > thread captures most of it: >> > >> > >> > http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg11281.html >> > >> > It's a long thread, but very useful read. >> > >> > I don't think having drivers handle pinmux directly is acceptable at >> > all. >> >> Correct. Drivers should not do muxing. This should be done by SoC or >> board init code. If your bootloader is doing it, that suggests that it is >> init-time only, and should be done in init code. >> > > Would it be possible to architect the pin-mux logic to accept boot > arguments to > configure the SoC devices wanted? We are struggling with porting a kernel > to > a davinci based System-on-Module type board that would allow end users to > select what interfaces (e.g., UARTS vs. SPI ports) to use on these devices. > With the pinmux stuff in the board specific code, u-boot passes the board type into the kernel, so only the code that matches the specific board type is executed. I realized that I'm repeating my last post. Perhaps I don't fully understand your requirements. Regarding your comment about passing pinmux setting as a kernel parameter. Of course that can be done. you got the source code ;) The dangers are 1. The change would not be accepted by the community. 2. Potential maintenance issue with custom kernel. > Having a pile of custom machines (kernel configurations) for every > permutation seems > painful if all they are doing is enabling different devices. I sort of > thought the Kevin's tree supports single binary that boots multiple DaVinci SoC. In other words, you can have a single binary with multiple boards (or SoCs) enabled. You can have a specific pinmux setting depends on the board type u-boot pass to the kernel in a single binary. Steve ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
kernel BUG in VPFE with DM365
I have the problem below with commit
f5cef8f45739db4c0c1c346296922cac274c87eb .
The capture works anyway using:
gst-launch v4l2src ! video/x-raw-yuv ! filesink location=video5.raw
and I play it with
mplayer -fps 4 video5.raw -demuxer rawvideo -rawvideo
w=720:h=480:format=uyvy
Suggestions are welcome to fix it better..
kernel BUG at drivers/media/video/davinci/vpfe_capture.c:225!
Unable to handle kernel NULL pointer dereference at virtual address
pgd = c0004000
[] *pgd=
Internal error: Oops: 805 [#1] PREEMPT
last sysfs file:
Modules linked in:
CPU: 0Not tainted (2.6.34-rc1-07158-g2a02dc4 #15)
-
this is a quick fix copying isif_set_params from ccdc_set_params, but I hope
someone help to understand what is really needed.
diff --git a/drivers/media/video/davinci/isif.c
b/drivers/media/video/davinci/is
index 29c29c6..4412a43 100644
--- a/drivers/media/video/davinci/isif.c
+++ b/drivers/media/video/davinci/isif.c
@@ -861,6 +861,36 @@ static void isif_setfbaddr(unsigned long addr)
regw((addr >> 5) & 0x0, CADL);
}
+/* Parameter operations */
+/* TODO from dm355 ccdc_set_params */
+static int isif_set_params(void __user *params)
+{
+#if 0
+ struct ccdc_config_params_raw ccdc_raw_params;
+ int x;
+
+ /* only raw module parameters can be set through the IOCTL */
+ if (ccdc_cfg.if_type != VPFE_RAW_BAYER)
+ return -EINVAL;
+
+ x = copy_from_user(&ccdc_raw_params, params,
sizeof(ccdc_raw_params));
+ if (x) {
+ dev_dbg(ccdc_cfg.dev, "ccdc_set_params: error in copying
ccdc"
+ "params, %d\n", x);
+ return -EFAULT;
+ }
+
+ if (!validate_ccdc_param(&ccdc_raw_params)) {
+ memcpy(&ccdc_cfg.bayer.config_params,
+ &ccdc_raw_params,
+ sizeof(ccdc_raw_params));
+ return 0;
+ }
+ return -EINVAL;
+#else
+ return 0;
+#endif
+}
static int isif_set_hw_if_params(struct vpfe_hw_if_param *params)
{
isif_cfg.if_type = params->if_type;
@@ -1015,6 +1045,7 @@ static struct ccdc_hw_device isif_hw_dev = {
.enable = isif_enable,
.enable_out_to_sdram = isif_enable_output_to_sdram,
.set_hw_if_params = isif_set_hw_if_params,
+ .set_params = isif_set_params,
.configure = isif_configure,
.set_buftype = isif_set_buftype,
.get_buftype = isif_get_buftype,
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Custom pinmuxing on DM355 with git kernel
> > How about a generic interface which included claim/free resource > methods, like for gpio, but taking a pointer to a mux resource struct > instead of a gpio number. The mux resource struct would include function > pointers to mach- or soc- specific functions to do the work of checking, > setting and freeing the mux resources. The mux resource struct would > also contain a list of mach- or soc- specific resource data required by > that device (pointers into an array of mux resource structs or > whatever?) > > The mux resources would be setup and passed by the board init to the > driver. The driver could claim and release them using the > platform-independent functions. The platform-independent functions could > just be wrappers calling the mach-specific functions, or do more > elaborate generic things (sysfs stuff, printing/handling conflicts) > > I appreciate this is fairly simpleminded and doesn't handle, for > example, large peripherals that you may not want to mux all of the pins > for (I'm thinking DM355 VPFE, we reuse the sync pins for example). > > Obviously I am handwaving all implementation details. Just trying to get > a grip on the theory and appreciate all experienced criticism. > Kevin, This reminds me of the discussions between you, Mark G, and Dave Brownell about dynamic pinmux setup and conflict detection. I seem to remember a comment regarding a change in clock setup (or was it some driver init) that would make a variant of dynamic pinmux setup in MVL Pro5 acceptable to the community. Just wondering if you remember any details. Steve ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
arago and kernel git
I'm on commit f5cef8f45739db4c0c1c346296922cac274c87eb (2.6.34-rc1 of http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git) . The evm dm365 works: boot,eth,vpfe tested by now on this kernel. I'd like to know which is the best way to proceed in order to add codec functionalities (encoding for instance). I know that cmem and dmai and gstreamer-ti are something useful, but I don't know if the recommended way is to use arago as filesystem. I had problems compiling gstreamer-ti with r28 version. I read something about arago-next, but I don't know if it is only for omapl138 or also for dm365. Maybe is better to move to openembedded itself, without using arago overlay? Thanks -arago- $ MACHINE=dm365-evm bitbake gstreamer-ti NOTE: Handling BitBake files: / (7462/7462) [100 %] NOTE: Parsing finished. 7152 cached, 0 parsed, 310 skipped, 129 masked. NOTE: Cache is clean, not saving. NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing runqueue NOTE: Running task 522 of 1272 (ID: 421, /home/sources/NEXTGEN/M/OE/arago/recipes/ti/ti-xdctools-native.bb, do_fetch) NOTE: Missing checksum ERROR: ti-xdctools-native-3_15_01_59: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/rtsc/xdctools_3_15/exports/xdctools_setuplinux_3_15_01_59.binhas no entry in conf/checksums.ini, not checking URI ERROR: Error in executing: /home/sources/NEXTGEN/M/OE/arago/recipes/ti/ ti-xdctools-native.bb ERROR: Exception: Message:1 ERROR: Printing the environment of the function ERROR: Error in executing: /home/sources/NEXTGEN/M/OE/arago/recipes/ti/ ti-xdctools-native.bb ERROR: Exception: Message:1 ERROR: Printing the environment of the function ERROR: Build of /home/sources/NEXTGEN/M/OE/arago/recipes/ti/ ti-xdctools-native.bb do_fetch failed ERROR: Task 421 (/home/sources/NEXTGEN/M/OE/arago/recipes/ti/ ti-xdctools-native.bb, do_fetch) failed NOTE: Tasks Summary: Attempted 521 tasks of which 521 didn't need to be rerun and 1 failed. ERROR: '/home/sources/NEXTGEN/M/OE/arago/recipes/ti/ti-xdctools-native.bb' failed -- www.opensurf.it ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Custom pinmuxing on DM355 with git kernel
On Wed, Mar 17, 2010 at 8:17 AM, Steve Chen wrote: > On Fri, Mar 12, 2010 at 7:06 PM, Mike Williamson > wrote: >> >> >> On Fri, Mar 12, 2010 at 5:18 PM, Kevin Hilman >> wrote: >>> >>> "Nori, Sekhar" writes: >>> >>> > On Thu, Mar 11, 2010 at 11:45:47, Jon Povey wrote: >>> >> Steve Chen wrote: >>> >> > On Wed, Mar 10, 2010 at 12:49 AM, Jon Povey >>> >> > wrote: >>> >> >>> >> >> We have 3 different boards using DM355, with different gpio / pinmux >>> >> >> setups. So far, our device drivers are modules which fiddle the >>> >> >> pinmux registers directly. >>> >> >>> >> >> At the moment I am thinking that I might want to split up >>> >> >> davinci_cfg_reg into two functions so it's not hardwired to >>> >> >> soc_info->pinmux_pins, and I could pass my own mux_config structs >>> >> >> in. If this is of interest I can have a go at doing this and >>> >> >> submitting the patch here. >>> >> > >>> >> > For board specific pinmux, you can put them in board-dm355-*.c. >>> >> > There are some board specific pinmux setup in board-da830-evm.c. >>> >> > Look for da8xx_pinmux_setup. >>> >> >>> >> Thanks, I see this. I have also been looking at the gpiolib support and >>> >> something like that would be useful. >>> >> >>> >> At minimum it would be helpful to split out the davinci_cfg_reg stuff >>> >> as >>> >> described above so that driver modules can use the same functions. >>> > >>> > Methods of handing pinmux were debated at length on this list. I think >>> > this >>> > thread captures most of it: >>> > >>> > >>> > http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg11281.html >>> > >>> > It's a long thread, but very useful read. >>> > >>> > I don't think having drivers handle pinmux directly is acceptable at >>> > all. >>> >>> Correct. Drivers should not do muxing. This should be done by SoC or >>> board init code. If your bootloader is doing it, that suggests that it is >>> init-time only, and should be done in init code. >>> >> >> Would it be possible to architect the pin-mux logic to accept boot >> arguments to >> configure the SoC devices wanted? We are struggling with porting a kernel >> to >> a davinci based System-on-Module type board that would allow end users to >> select what interfaces (e.g., UARTS vs. SPI ports) to use on these devices. >> > > With the pinmux stuff in the board specific code, u-boot passes the > board type into the kernel, so only the code that matches the specific > board type is executed. I realized that I'm repeating my last post. > Perhaps I don't fully understand your requirements. > > Regarding your comment about passing pinmux setting as a kernel > parameter. Of course that can be done. you got the source code ;) > The dangers are > > 1. The change would not be accepted by the community. > 2. Potential maintenance issue with custom kernel. > Understood, and I have no desire to go this route. >> Having a pile of custom machines (kernel configurations) for every >> permutation seems >> painful if all they are doing is enabling different devices. I sort of >> thought the > > Kevin's tree supports single binary that boots multiple DaVinci SoC. > In other words, you can have a single binary with multiple boards (or > SoCs) enabled. You can have a specific pinmux setting depends on the > board type u-boot pass to the kernel in a single binary. > My concern spawns from the fact that I can foresee maybe as many as 20 unique pinmux configurations for 1 specific davinci based SoM. This is based on real experience with older SoM's (not running a linux OS). These devices support a lot of permutations of pin assignments. If the right way is really to register 20 different machines over time and make 20 different board init files and submit them up, no problem. But it seems like it would become a headache managing that over time. I had a brief experience working with FreeScale parts that used a ROM device tree block, where this sort of configuration was read in at init and provided a way to define which peripherals on a SoC you wanted to use without having to rebuild the kernel (or "worse", make a new machine type). It was't perfect, but seemed to work. I thought perhaps there was a similar approach available for the davincis. Thanks for the insight. -Mike ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus
Hi Philby,
On Wed, Mar 17, 2010 at 16:58:44, Philby John wrote:
> On 03/17/2010 02:20 AM, Kevin Hilman wrote:
> > Philby John writes:
> >
> >> On 02/08/2010 04:05 PM, Nori, Sekhar wrote:
> >>> Hi Philby,
> >>>
> >>> On Fri, Feb 05, 2010 at 19:23:43, Philby John wrote:
> Hello Sekhar,
>
> >>>
> >>> [...]
> >>>
> >> +/* Generate a pulse on the i2c clock pin. */
> >> +static void generic_i2c_clock_pulse(unsigned int scl_pin)
> >> +{
> >> + u16 i;
> >> +
> >> + if (scl_pin) {
> >> + /* Send high and low on the SCL line */
> >> + for (i = 0; i< 9; i++) {
> >> + gpio_set_value(scl_pin, 0);
> >> + udelay(20);
> >> + gpio_set_value(scl_pin, 1);
> >> + udelay(20);
> >> + }
> >
> > Before using the pins as GPIO, you would have to set the
> > functionality of these pins as GPIO. You had this code in
> > previous incarnations of this patch - not sure why it is
> > dropped now.
> >
> >>
> >> I now think that the previous versions were incorrect since
> >> davinci_cfg_reg() does not set the scl or sda pins for gpio
> >> functionality. Instead they set them as scl or sda which is not what
> >> we want at the time of pulsing. The previous versions used
> >> gpio_set_value() in disable_i2c_pins() and then called
> >> davinci_cfg_reg(). After which it called pulse_i2c_clock().
> >>
> >> Please correct me if my interpretation of the code is incorrect.
> >
> > Can we get some resolution here?
> >
> > I have a queue of davinci i2c patches waiting to go upstream, and I'd
> > like to get them in for 2.6.35.
> >
> > The current i2c series is in the 'davinci-i2c' branch of davinci git.
>
> To quote Sekhar, "...Right. It is only an enhancement (and only good
> to have at that). This should not stop the current patch from getting
> in." So this patch is good to make it to 2.6.35
How about the using the "free data format" method that Brad was
suggesting [1]? That sounds like a much simpler approach than the
GPIO muxing method that this patch is adopting.
I think we should try that method before accepting this approach
as the final one.
Thanks,
Sekhar
[1] http://www.mail-archive.com/linux-...@vger.kernel.org/msg02800.html
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v4 2/3] davinci: da8xx/omapl EVM: Specify reserved channels/slots
From: Sudhakar Rajashekhara
The drivers on da8xx/omapl EVMs do not utilize all the channels
and slots provided by EDMA. Some of these are better utilitzed by
the DSP on the SoC for speeding up codec operations.
Reserve these channels/slots for the DSP.
Signed-off-by: Sudhakar Rajashekhara
Signed-off-by: Sekhar Nori
---
arch/arm/mach-davinci/board-da830-evm.c| 32 ++-
arch/arm/mach-davinci/board-da850-evm.c| 48 +++-
arch/arm/mach-davinci/devices-da8xx.c | 21 +++-
arch/arm/mach-davinci/include/mach/da8xx.h |3 +-
4 files changed, 92 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c
b/arch/arm/mach-davinci/board-da830-evm.c
index dc19870..5c53864 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -482,12 +482,42 @@ static struct davinci_i2c_platform_data
da830_evm_i2c_0_pdata = {
.bus_delay = 0,/* usec */
};
+/*
+ * The following EDMA channels/slots are not being used by drivers (for
+ * example: Timer, GPIO, UART events etc) on da830/omap-l137 EVM, hence
+ * they are being reserved for codecs on the DSP side.
+ */
+static const s16 da830_dma_rsv_chans[][2] = {
+ /* (offset, number) */
+ { 8, 2},
+ {12, 2},
+ {24, 4},
+ {30, 2},
+ {-1, -1}
+};
+
+static const s16 da830_dma_rsv_slots[][2] = {
+ /* (offset, number) */
+ { 8, 2},
+ {12, 2},
+ {24, 4},
+ {30, 26},
+ {-1, -1}
+};
+
+static struct edma_rsv_info da830_edma_rsv[] = {
+ {
+ .rsv_chans = da830_dma_rsv_chans,
+ .rsv_slots = da830_dma_rsv_slots,
+ },
+};
+
static __init void da830_evm_init(void)
{
struct davinci_soc_info *soc_info = &davinci_soc_info;
int ret;
- ret = da8xx_register_edma();
+ ret = da830_register_edma(da830_edma_rsv);
if (ret)
pr_warning("da830_evm_init: edma registration failed: %d\n",
ret);
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 411284d..dda8b57 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -612,6 +612,52 @@ static int __init da850_evm_config_emac(void)
}
device_initcall(da850_evm_config_emac);
+/*
+ * The following EDMA channels/slots are not being used by drivers (for
+ * example: Timer, GPIO, UART events etc) on da850/omap-l138 EVM, hence
+ * they are being reserved for codecs on the DSP side.
+ */
+static const s16 da850_dma0_rsv_chans[][2] = {
+ /* (offset, number) */
+ { 8, 6},
+ {24, 4},
+ {30, 2},
+ {-1, -1}
+};
+
+static const s16 da850_dma0_rsv_slots[][2] = {
+ /* (offset, number) */
+ { 8, 6},
+ {24, 4},
+ {30, 50},
+ {-1, -1}
+};
+
+static const s16 da850_dma1_rsv_chans[][2] = {
+ /* (offset, number) */
+ { 0, 28},
+ {30, 2},
+ {-1, -1}
+};
+
+static const s16 da850_dma1_rsv_slots[][2] = {
+ /* (offset, number) */
+ { 0, 28},
+ {30, 90},
+ {-1, -1}
+};
+
+static struct edma_rsv_info da850_edma_rsv[] = {
+ {
+ .rsv_chans = da850_dma0_rsv_chans,
+ .rsv_slots = da850_dma0_rsv_slots,
+ },
+ {
+ .rsv_chans = da850_dma1_rsv_chans,
+ .rsv_slots = da850_dma1_rsv_slots,
+ },
+};
+
static __init void da850_evm_init(void)
{
int ret;
@@ -621,7 +667,7 @@ static __init void da850_evm_init(void)
pr_warning("da850_evm_init: TPS65070 PMIC init failed: %d\n",
ret);
- ret = da8xx_register_edma();
+ ret = da850_register_edma(da850_edma_rsv);
if (ret)
pr_warning("da850_evm_init: edma registration failed: %d\n",
ret);
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index 0a96791..83e7318 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -248,18 +248,21 @@ static struct platform_device da850_edma_device = {
.resource = da850_edma_resources,
};
-int __init da8xx_register_edma(void)
+int __init da830_register_edma(struct edma_rsv_info *rsv)
{
- struct platform_device *pdev;
+ da830_edma_info[0].rsv = rsv;
- if (cpu_is_davinci_da830())
- pdev = &da830_edma_device;
- else if (cpu_is_davinci_da850())
- pdev = &da850_edma_device;
- else
- return -ENODEV;
+ return platform_device_register(&da830_edma_device);
+}
- return platform_device_register(pdev);
+int __init da850_register_edma(struct edma_rsv_info *rsv)
+{
+ if (rsv) {
+ da850_edma_info[0].rsv = &rsv[0];
+ da850_edm
[PATCH v4 3/3] davinci: dm646x EVM: Specify reserved EDMA channel/slots
From: Sudhakar Rajashekhara
Not all the channels and slots available on the DM646x EVM
are used by the devices on the EVM. These resources can be
used by the DSP to speed up codec operations.
This patch reserves these channels for the DSP.
Signed-off-by: Sudhakar Rajashekhara
Signed-off-by: Sekhar Nori
---
arch/arm/mach-davinci/board-dm646x-evm.c| 35 +++
arch/arm/mach-davinci/dm646x.c |8 +-
arch/arm/mach-davinci/include/mach/dm646x.h |1 +
3 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 5ba3cb2..d14f962 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -724,6 +724,39 @@ static struct davinci_uart_config uart_config __initdata =
{
#define DM646X_EVM_PHY_MASK(0x2)
#define DM646X_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */
+/*
+ * The following EDMA channels/slots are not being used by drivers (for
+ * example: Timer, GPIO, UART events etc) on dm646x, hence they are being
+ * reserved for codecs on the DSP side.
+ */
+static const s16 dm646x_dma_rsv_chans[][2] = {
+ /* (offset, number) */
+ { 0, 4},
+ {13, 3},
+ {24, 4},
+ {30, 2},
+ {54, 3},
+ {-1, -1}
+};
+
+static const s16 dm646x_dma_rsv_slots[][2] = {
+ /* (offset, number) */
+ { 0, 4},
+ {13, 3},
+ {24, 4},
+ {30, 2},
+ {54, 3},
+ {128, 384},
+ {-1, -1}
+};
+
+static struct edma_rsv_info dm646x_edma_rsv[] = {
+ {
+ .rsv_chans = dm646x_dma_rsv_chans,
+ .rsv_slots = dm646x_dma_rsv_slots,
+ },
+};
+
static __init void evm_init(void)
{
struct davinci_soc_info *soc_info = &davinci_soc_info;
@@ -735,6 +768,8 @@ static __init void evm_init(void)
platform_device_register(&davinci_nand_device);
+ dm646x_init_edma(dm646x_edma_rsv);
+
if (HAS_ATA)
dm646x_init_ide();
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 893baf4..fb48c24 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -912,6 +912,13 @@ void dm646x_setup_vpif(struct vpif_display_config
*display_config,
platform_device_register(&vpif_capture_dev);
}
+int __init dm646x_init_edma(struct edma_rsv_info *rsv)
+{
+ dm646x_edma_info[0].rsv = rsv;
+
+ return platform_device_register(&dm646x_edma_device);
+}
+
void __init dm646x_init(void)
{
dm646x_board_setup_refclk(&ref_clk);
@@ -923,7 +930,6 @@ static int __init dm646x_init_devices(void)
if (!cpu_is_davinci_dm646x())
return 0;
- platform_device_register(&dm646x_edma_device);
platform_device_register(&dm646x_emac_device);
return 0;
}
diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h
b/arch/arm/mach-davinci/include/mach/dm646x.h
index 846da98..38c7d87 100644
--- a/arch/arm/mach-davinci/include/mach/dm646x.h
+++ b/arch/arm/mach-davinci/include/mach/dm646x.h
@@ -32,6 +32,7 @@ void __init dm646x_init_ide(void);
void __init dm646x_init_mcasp0(struct snd_platform_data *pdata);
void __init dm646x_init_mcasp1(struct snd_platform_data *pdata);
void __init dm646x_board_setup_refclk(struct clk *clk);
+int __init dm646x_init_edma(struct edma_rsv_info *rsv);
void dm646x_video_init(void);
--
1.6.2.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2 1/3] davinci: support for EDMA resource sharing
From: Sudhakar Rajashekhara
Current EDMA driver is not taking care of EDMA channels/slots
which are allocated from other processor, say DSP. If a
channel/slot is allocated from DSP, the existing EDMA driver
can still allocate the same resource on ARM.
This patch enables the user to pass the channel/slots reserved
for DSP as platform data. EDMA driver scans this list during
probe and prepares a bitmap of channel/slots which can be used
on ARM side.
Signed-off-by: Sudhakar Rajashekhara
Signed-off-by: Sekhar Nori
Cc: David Brownell
---
Since v1, the reservation information has been moved to a
seperate structure so it is easier for boards to pass this
information or pass NULL if they are not interested in
resource reservation at all.
arch/arm/mach-davinci/dma.c | 41 -
arch/arm/mach-davinci/include/mach/edma.h |9 ++
2 files changed, 49 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index 260485c..9574e14 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -206,6 +206,18 @@ static inline void edma_parm_or(unsigned ctlr, int offset,
int param_no,
edma_or(ctlr, EDMA_PARM + offset + (param_no << 5), or);
}
+static inline void set_bits(int offset, int len, unsigned long *p)
+{
+ for (; len > 0; len--)
+ set_bit(offset + (len - 1), p);
+}
+
+static inline void clear_bits(int offset, int len, unsigned long *p)
+{
+ for (; len > 0; len--)
+ clear_bit(offset + (len - 1), p);
+}
+
/*/
/* actual number of DMA channels and slots on this silicon */
@@ -1380,8 +1392,10 @@ static int __init edma_probe(struct platform_device
*pdev)
struct edma_soc_info*info = pdev->dev.platform_data;
const s8(*queue_priority_mapping)[2];
const s8(*queue_tc_mapping)[2];
- int i, j, found = 0;
+ int i, j, off, ln, found = 0;
int status = -1;
+ const s16 (*rsv_chans)[2];
+ const s16 (*rsv_slots)[2];
int irq[EDMA_MAX_CC] = {0, 0};
int err_irq[EDMA_MAX_CC] = {0, 0};
struct resource *r[EDMA_MAX_CC] = {NULL};
@@ -1448,6 +1462,31 @@ static int __init edma_probe(struct platform_device
*pdev)
memset(edma_info[j]->edma_unused, 0xff,
sizeof(edma_info[j]->edma_unused));
+ if (info[j].rsv) {
+
+ /* Clear the reserved channels in unused list */
+ rsv_chans = info[j].rsv->rsv_chans;
+ if (rsv_chans) {
+ for (i = 0; rsv_chans[i][0] != -1; i++) {
+ off = rsv_chans[i][0];
+ ln = rsv_chans[i][1];
+ clear_bits(off, ln,
+ edma_info[j]->edma_unused);
+ }
+ }
+
+ /* Set the reserved slots in inuse list */
+ rsv_slots = info[j].rsv->rsv_slots;
+ if (rsv_slots) {
+ for (i = 0; rsv_slots[i][0] != -1; i++) {
+ off = rsv_slots[i][0];
+ ln = rsv_slots[i][1];
+ set_bits(off, ln,
+ edma_info[j]->edma_inuse);
+ }
+ }
+ }
+
sprintf(irq_name, "edma%d", j);
irq[j] = platform_get_irq_byname(pdev, irq_name);
edma_info[j]->irq_res_start = irq[j];
diff --git a/arch/arm/mach-davinci/include/mach/edma.h
b/arch/arm/mach-davinci/include/mach/edma.h
index ced3092..3983644 100644
--- a/arch/arm/mach-davinci/include/mach/edma.h
+++ b/arch/arm/mach-davinci/include/mach/edma.h
@@ -269,6 +269,12 @@ void edma_clear_event(unsigned channel);
void edma_pause(unsigned channel);
void edma_resume(unsigned channel);
+struct edma_rsv_info {
+
+ const s16 (*rsv_chans)[2];
+ const s16 (*rsv_slots)[2];
+};
+
/* platform_data for EDMA driver */
struct edma_soc_info {
@@ -280,6 +286,9 @@ struct edma_soc_info {
unsignedn_cc;
enum dma_event_qdefault_queue;
+ /* Resource reservation for other cores */
+ struct edma_rsv_info*rsv;
+
const s8(*queue_tc_mapping)[2];
const s8(*queue_priority_mapping)[2];
};
--
1.6.2.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://l
Re: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus
On 03/17/2010 06:48 PM, Nori, Sekhar wrote:
Hi Philby,
On Wed, Mar 17, 2010 at 16:58:44, Philby John wrote:
On 03/17/2010 02:20 AM, Kevin Hilman wrote:
Philby John writes:
On 02/08/2010 04:05 PM, Nori, Sekhar wrote:
Hi Philby,
On Fri, Feb 05, 2010 at 19:23:43, Philby John wrote:
Hello Sekhar,
[...]
+/* Generate a pulse on the i2c clock pin. */
+static void generic_i2c_clock_pulse(unsigned int scl_pin)
+{
+ u16 i;
+
+ if (scl_pin) {
+ /* Send high and low on the SCL line */
+ for (i = 0; i<9; i++) {
+ gpio_set_value(scl_pin, 0);
+ udelay(20);
+ gpio_set_value(scl_pin, 1);
+ udelay(20);
+ }
Before using the pins as GPIO, you would have to set the
functionality of these pins as GPIO. You had this code in
previous incarnations of this patch - not sure why it is
dropped now.
I now think that the previous versions were incorrect since
davinci_cfg_reg() does not set the scl or sda pins for gpio
functionality. Instead they set them as scl or sda which is not what
we want at the time of pulsing. The previous versions used
gpio_set_value() in disable_i2c_pins() and then called
davinci_cfg_reg(). After which it called pulse_i2c_clock().
Please correct me if my interpretation of the code is incorrect.
Can we get some resolution here?
I have a queue of davinci i2c patches waiting to go upstream, and I'd
like to get them in for 2.6.35.
The current i2c series is in the 'davinci-i2c' branch of davinci git.
To quote Sekhar, "...Right. It is only an enhancement (and only good
to have at that). This should not stop the current patch from getting
in." So this patch is good to make it to 2.6.35
How about the using the "free data format" method that Brad was
suggesting [1]? That sounds like a much simpler approach than the
GPIO muxing method that this patch is adopting.
I can't seem to agree with your argument. The recovery method adopted
here is part of the standard i2c v3 spec.
I think we should try that method before accepting this approach
as the final one.
It would be wiser allowing this one to go in, since a lot of
reviewing/testing has already been done. Later on we could try the "free
data format" and hope that this would work. Otherwise, we would still be
without a fix until "free data format" is done.
Regards,
Philby
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Custom pinmuxing on DM355 with git kernel
On Wed, Mar 17, 2010 at 7:17 AM, Mike Williamson wrote: > On Wed, Mar 17, 2010 at 8:17 AM, Steve Chen wrote: >> On Fri, Mar 12, 2010 at 7:06 PM, Mike Williamson >> wrote: >>> >>> >>> On Fri, Mar 12, 2010 at 5:18 PM, Kevin Hilman >>> wrote: "Nori, Sekhar" writes: > On Thu, Mar 11, 2010 at 11:45:47, Jon Povey wrote: >> Steve Chen wrote: >> > On Wed, Mar 10, 2010 at 12:49 AM, Jon Povey >> > wrote: >> >> >> We have 3 different boards using DM355, with different gpio / pinmux >> >> setups. So far, our device drivers are modules which fiddle the >> >> pinmux registers directly. >> >> >> At the moment I am thinking that I might want to split up >> >> davinci_cfg_reg into two functions so it's not hardwired to >> >> soc_info->pinmux_pins, and I could pass my own mux_config structs >> >> in. If this is of interest I can have a go at doing this and >> >> submitting the patch here. >> > >> > For board specific pinmux, you can put them in board-dm355-*.c. >> > There are some board specific pinmux setup in board-da830-evm.c. >> > Look for da8xx_pinmux_setup. >> >> Thanks, I see this. I have also been looking at the gpiolib support and >> something like that would be useful. >> >> At minimum it would be helpful to split out the davinci_cfg_reg stuff >> as >> described above so that driver modules can use the same functions. > > Methods of handing pinmux were debated at length on this list. I think > this > thread captures most of it: > > > http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg11281.html > > It's a long thread, but very useful read. > > I don't think having drivers handle pinmux directly is acceptable at > all. Correct. Drivers should not do muxing. This should be done by SoC or board init code. If your bootloader is doing it, that suggests that it is init-time only, and should be done in init code. >>> >>> Would it be possible to architect the pin-mux logic to accept boot >>> arguments to >>> configure the SoC devices wanted? We are struggling with porting a kernel >>> to >>> a davinci based System-on-Module type board that would allow end users to >>> select what interfaces (e.g., UARTS vs. SPI ports) to use on these devices. >>> >> >> With the pinmux stuff in the board specific code, u-boot passes the >> board type into the kernel, so only the code that matches the specific >> board type is executed. I realized that I'm repeating my last post. >> Perhaps I don't fully understand your requirements. >> >> Regarding your comment about passing pinmux setting as a kernel >> parameter. Of course that can be done. you got the source code ;) >> The dangers are >> >> 1. The change would not be accepted by the community. >> 2. Potential maintenance issue with custom kernel. >> > > Understood, and I have no desire to go this route. > >>> Having a pile of custom machines (kernel configurations) for every >>> permutation seems >>> painful if all they are doing is enabling different devices. I sort of >>> thought the >> >> Kevin's tree supports single binary that boots multiple DaVinci SoC. >> In other words, you can have a single binary with multiple boards (or >> SoCs) enabled. You can have a specific pinmux setting depends on the >> board type u-boot pass to the kernel in a single binary. >> > > My concern spawns from the fact that I can foresee maybe as many as > 20 unique pinmux configurations for 1 specific davinci based SoM. This > is based on real experience with older SoM's (not running a linux OS). > These devices support a lot of permutations of pin assignments. > > If the right way is really to register 20 different machines over time and > make 20 different board init files and submit them up, no problem. But it > seems like it would become a headache managing that over time. I did not know that there are so many permutations. Having a different machine for every permutations does not look like a good solution. > > I had a brief experience working with FreeScale parts that used a ROM > device tree block, where this sort of configuration was read in at init and > provided a way to define which peripherals on a SoC you wanted to use > without having to rebuild the kernel (or "worse", make a new machine type). > It was't perfect, but seemed to work. I thought perhaps there was a > similar approach available for the davincis. > > Thanks for the insight. > In MVL Pro5, I embedded pinmux configuration in clock setup code. This provide the ability to dynamically setup pinmux as each device is loaded. There was also a provision to detect pinmux conflict. Because the patch abuses the clock API, it was rejected. Perhaps we should take another look at pinmux and explore the possibilities... whenever time permits :( Steve _
RE: kernel BUG in VPFE with DM365
Raffaele,
Is there a call to VPFE_CMD_S_CCDC_RAW_PARAMS in your gstreamer code?
This IOCTL handling code in isif.c had to be removed during merge to
upstream based on community feedback and is required only for raw bayer RGB
capture. However since it was earlier a mandatory call in vpfe capture, there
was no check in vpfe_capture.c to see if the ccdc/isif implements the
set_params() call. I will send a patch to fix this bug in upstream. But I am
wondering why there is a call to VPFE_CMD_S_CCDC_RAW_PARAMS when you are
doing a yuv capture. Raw capture is currently not supported. This ioctl will be
supported when the ccdc/isif drivers are converted to sub devices in
which case they will have to be called on the sub device node.
You need the following code in vpfe_capture.c to fix the bug.
switch (cmd) {
case VPFE_CMD_S_CCDC_RAW_PARAMS:
v4l2_warn(&vpfe_dev->v4l2_dev,
"VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n");
+ if (ccdc_dev->hw_ops.set_params) {
ret = ccdc_dev->hw_ops.set_params(param);
if (ret) {
v4l2_err(&vpfe_dev->v4l2_dev,
"Error in setting parameters in CCDC\n");
goto unlock_out;
}
+ }
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Raffaele Recalcati
Sent: Wednesday, March 17, 2010 8:38 AM
To: davinci-linux-open-source
Subject: kernel BUG in VPFE with DM365
I have the problem below with commit f5cef8f45739db4c0c1c346296922cac274c87eb .
The capture works anyway using:
gst-launch v4l2src ! video/x-raw-yuv ! filesink location=video5.raw
and I play it with
mplayer -fps 4 video5.raw -demuxer rawvideo -rawvideo w=720:h=480:format=uyvy
Suggestions are welcome to fix it better..
kernel BUG at drivers/media/video/davinci/vpfe_capture.c:225!
Unable to handle kernel NULL pointer dereference at virtual address
pgd = c0004000
[] *pgd=
Internal error: Oops: 805 [#1] PREEMPT
last sysfs file:
Modules linked in:
CPU: 0 Not tainted (2.6.34-rc1-07158-g2a02dc4 #15)
-
this is a quick fix copying isif_set_params from ccdc_set_params, but I hope
someone help to understand what is really needed.
diff --git a/drivers/media/video/davinci/isif.c b/drivers/media/video/davinci/is
index 29c29c6..4412a43 100644
--- a/drivers/media/video/davinci/isif.c
+++ b/drivers/media/video/davinci/isif.c
@@ -861,6 +861,36 @@ static void isif_setfbaddr(unsigned long addr)
regw((addr >> 5) & 0x0, CADL);
}
+/* Parameter operations */
+/* TODO from dm355 ccdc_set_params */
+static int isif_set_params(void __user *params)
+{
+#if 0
+ struct ccdc_config_params_raw ccdc_raw_params;
+ int x;
+
+ /* only raw module parameters can be set through the IOCTL */
+ if (ccdc_cfg.if_type != VPFE_RAW_BAYER)
+ return -EINVAL;
+
+ x = copy_from_user(&ccdc_raw_params, params, sizeof(ccdc_raw_params));
+ if (x) {
+ dev_dbg(ccdc_cfg.dev, "ccdc_set_params: error in copying ccdc"
+ "params, %d\n", x);
+ return -EFAULT;
+ }
+
+ if (!validate_ccdc_param(&ccdc_raw_params)) {
+ memcpy(&ccdc_cfg.bayer.config_params,
+ &ccdc_raw_params,
+ sizeof(ccdc_raw_params));
+ return 0;
+ }
+ return -EINVAL;
+#else
+ return 0;
+#endif
+}
static int isif_set_hw_if_params(struct vpfe_hw_if_param *params)
{
isif_cfg.if_type = params->if_type;
@@ -1015,6 +1045,7 @@ static struct ccdc_hw_device isif_hw_dev = {
.enable = isif_enable,
.enable_out_to_sdram = isif_enable_output_to_sdram,
.set_hw_if_params = isif_set_hw_if_params,
+ .set_params = isif_set_params,
.configure = isif_configure,
.set_buftype = isif_set_buftype,
.get_buftype = isif_get_buftype,
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: kernel BUG in VPFE with DM365
Thx for the reply.
2010/3/17 Karicheri, Muralidharan
> Raffaele,
>
> Is there a call to VPFE_CMD_S_CCDC_RAW_PARAMS in your gstreamer code?
>
No, the BUG is during the boot using this bootargs:
console=ttyS0,115200n8 use_acm=0 rw ip=10.39.10.177:10
.39.10.169:10.39.8.1:255.2
55.248.0:::off root=/dev/nfs nfsroot=10.39.10.169:/NFS/ARAGO_DEMO_IMAGE-r28-evm
mem=76M
video=davincifb:vid0=1280x720x16,5400K:vid1=1280x720x16,5400K:osd0=720x5
76x16,2025K vpfe_capture.bufsize=4147200 tvp7002.debug=1 ths7353.debug=1
2c /dev entries driver
Linux video capture interface: v2.00
vpfe_init
vpfe-capture vpfe-capture: v4l2 device registered
vpfe-capture vpfe-capture: video device registered
tvp514x 1-005d: tvp514x 1-005d decoder driver registered !!
vpfe-capture vpfe-capture: v4l2 sub device tvp5146 registered
vpfe_register_ccdc_device: ISIF
kernel BUG at drivers/media/video/davinci/vpfe_capture.c:225!
Unable to handle kernel NULL pointer dereference at virtual address
pgd = c0004000
[] *pgd=
Internal error: Oops: 805 [#1] PREEMPT
last sysfs file:
Modules linked in:
CPU: 0Not tainted (2.6.34-rc1-07158-g2a02dc4 #15)
PC is at __bug+0x20/0x2c
LR is at vprintk+0x3c4/0x418
pc : []lr : []psr: 2013
sp : c4823e60 ip : c4823dc0 fp : c4823e6c
r10: r9 : r8 : c0364898
r7 : c49615a0 r6 : c03522e8 r5 : c03522f0 r4 : c036e2e8
r3 : r2 : c4822000 r1 : c4823dc0 r0 : 0044
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 0005317f Table: 80004000 DAC: 0017
Process swapper (pid: 1, stack limit = 0xc4822270)
Stack: (0xc4823e60 to 0xc4824000)
3e60: c4823e84 c4823e70 c01e32a0 c002e1d8 c03522f0 c03522f0 c4823eac
c4823e88
3e80: c001c438 c01e3268 c00ea940 c00ea778 c03522f0 c03522f0 c036e2b0
c49615a0
3ea0: c4823ebc c4823eb0 c019a650 c001c42c c4823edc c4823ec0 c0199650
c019a640
3ec0: c03522f0 c0352324 c036e2b0 c49615a0 c4823efc c4823ee0 c019976c
c01995b0
3ee0: c0199704 c036e2b0 c49615a0 c4823f24 c4823f00 c0198e1c
c0199714
3f00: c4805638 c483b930 c01584f0 c00221ac c036e2b0 c036e2b0 c4823f34
c4823f28
3f20: c01994b4 c0198ddc c4823f64 c4823f38 c01986f4 c01994a4 c03021fc
3f40: c00221ac c036e2b0 0001 c4823f8c
c4823f68
3f60: c0199a88 c0198660 c00221ac c001c400 0001
3f80: c4823f9c c4823f90 c019a900 c01999e8 c4823fac c4823fa0 c001c414
c019a8c4
3fa0: c4823fdc c4823fb0 c002a3dc c001c410 c4823fdc
c4823fc8
3fc0: c00221ac c4823ff4 c4823fe0 c0008480
c002a388
3fe0: c4823ff8 c00434ac c00083e8 b4090392
f0786fe7
Backtrace:
[] (__bug+0x0/0x2c) from []
(vpfe_register_ccdc_device+0x48/
0x1e4)
[] (vpfe_register_ccdc_device+0x0/0x1e4) from []
(isif_probe
+0x1c/0x1c8)
r5:c03522f0 r4:c03522f0
[] (isif_probe+0x0/0x1c8) from []
(platform_drv_probe+0x20/0
x24)
r7:c49615a0 r6:c036e2b0 r5:c03522f0 r4:c03522f0
[] (platform_drv_probe+0x0/0x24) from []
(driver_probe_devic
e+0xb0/0x164)
[] (driver_probe_device+0x0/0x164) from []
(__driver_attach+
0x68/0x8c)
r7:c49615a0 r6:c036e2b0 r5:c0352324 r4:c03522f0
[] (__driver_attach+0x0/0x8c) from []
(bus_for_each_dev+0x50
/0x84)
r7:c49615a0 r6:c036e2b0 r5:c0199704 r4:
[] (bus_for_each_dev+0x0/0x84) from []
(driver_attach+0x20/0
x28)
r6:c036e2b0 r5:c036e2b0 r4:c00221ac
[] (driver_attach+0x0/0x28) from []
(bus_add_driver+0xa4/0x2
30)
[] (bus_add_driver+0x0/0x230) from []
(driver_register+0xb0/
0x13c)
[] (driver_register+0x0/0x13c) from []
(platform_driver_regi
ster+0x4c/0x60)
r9: r8: r7:0001 r6:c001c400 r5:
r4:c00221ac
[] (platform_driver_register+0x0/0x60) from []
(isif_init+0x
14/0x1c)
[] (isif_init+0x0/0x1c) from []
(do_one_initcall+0x64/0x1c4)
[] (do_one_initcall+0x0/0x1c4) from []
(kernel_init+0xa8/0x1
64)
r7: r6: r5: r4:c00221ac
[] (kernel_init+0x0/0x164) from [] (do_exit+0x0/0x684)
r5: r4:
Code: e1a01000 e59f000c eb093134 e3a03000 (e5833000)
> This IOCTL handling code in isif.c had to be removed during merge to
> upstream based on community feedback and is required only for raw bayer RGB
> capture. However since it was earlier a mandatory call in vpfe capture,
> there was no check in vpfe_capture.c to see if the ccdc/isif implements the
> set_params() call. I will send a patch to fix this bug in upstream. But I am
> wondering why there is a call to VPFE_CMD_S_CCDC_RAW_PARAMS when you are
> doing a yuv capture. Raw capture is currently not supported. This ioctl
> will be supported when the ccdc/isif drivers are converted to sub devices in
> which case they will have to be called on the sub device node.
>
> You need the following code in vpfe_capture.c to fix the bug.
>
> switch (cmd) {
>
>case VPFE_CMD_S_CCDC_RAW_PARAMS:
> v4l2_warn(&vpfe_dev->v4l2_dev,
>"VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n");
> + if (ccdc_de
RE: kernel BUG in VPFE with DM365
Raffaele, Thanks for the reply.. Yes. Your log helped. There is a check in vpfe_register_ccdc_device() BUG_ON(!dev->hw_ops.set_params); This has to be removed along with my earlier changes. BTW, tvp7002 is not yet integrated in upstream. So some more work is required to support this. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com From: Raffaele Recalcati [mailto:lamiapost...@gmail.com] Sent: Wednesday, March 17, 2010 10:05 AM To: Karicheri, Muralidharan Cc: davinci-linux-open-source Subject: Re: kernel BUG in VPFE with DM365 Thx for the reply. 2010/3/17 Karicheri, Muralidharan mailto:m-kariche...@ti.com>> Raffaele, Is there a call to VPFE_CMD_S_CCDC_RAW_PARAMS in your gstreamer code? No, the BUG is during the boot using this bootargs: console=ttyS0,115200n8 use_acm=0 rw ip=10.39.10.177:10.39.10.169:10.39.8.1:255.2 55.248.0:::off root=/dev/nfs nfsroot=10.39.10.169:/NFS/ARAGO_DEMO_IMAGE-r28-evm mem=76M video=davincifb:vid0=1280x720x16,5400K:vid1=1280x720x16,5400K:osd0=720x5 76x16,2025K vpfe_capture.bufsize=4147200 tvp7002.debug=1 ths7353.debug=1 2c /dev entries driver Linux video capture interface: v2.00 vpfe_init vpfe-capture vpfe-capture: v4l2 device registered vpfe-capture vpfe-capture: video device registered tvp514x 1-005d: tvp514x 1-005d decoder driver registered !! vpfe-capture vpfe-capture: v4l2 sub device tvp5146 registered vpfe_register_ccdc_device: ISIF kernel BUG at drivers/media/video/davinci/vpfe_capture.c:225! Unable to handle kernel NULL pointer dereference at virtual address pgd = c0004000 [] *pgd= Internal error: Oops: 805 [#1] PREEMPT last sysfs file: Modules linked in: CPU: 0Not tainted (2.6.34-rc1-07158-g2a02dc4 #15) PC is at __bug+0x20/0x2c LR is at vprintk+0x3c4/0x418 pc : []lr : []psr: 2013 sp : c4823e60 ip : c4823dc0 fp : c4823e6c r10: r9 : r8 : c0364898 r7 : c49615a0 r6 : c03522e8 r5 : c03522f0 r4 : c036e2e8 r3 : r2 : c4822000 r1 : c4823dc0 r0 : 0044 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 0005317f Table: 80004000 DAC: 0017 Process swapper (pid: 1, stack limit = 0xc4822270) Stack: (0xc4823e60 to 0xc4824000) 3e60: c4823e84 c4823e70 c01e32a0 c002e1d8 c03522f0 c03522f0 c4823eac c4823e88 3e80: c001c438 c01e3268 c00ea940 c00ea778 c03522f0 c03522f0 c036e2b0 c49615a0 3ea0: c4823ebc c4823eb0 c019a650 c001c42c c4823edc c4823ec0 c0199650 c019a640 3ec0: c03522f0 c0352324 c036e2b0 c49615a0 c4823efc c4823ee0 c019976c c01995b0 3ee0: c0199704 c036e2b0 c49615a0 c4823f24 c4823f00 c0198e1c c0199714 3f00: c4805638 c483b930 c01584f0 c00221ac c036e2b0 c036e2b0 c4823f34 c4823f28 3f20: c01994b4 c0198ddc c4823f64 c4823f38 c01986f4 c01994a4 c03021fc 3f40: c00221ac c036e2b0 0001 c4823f8c c4823f68 3f60: c0199a88 c0198660 c00221ac c001c400 0001 3f80: c4823f9c c4823f90 c019a900 c01999e8 c4823fac c4823fa0 c001c414 c019a8c4 3fa0: c4823fdc c4823fb0 c002a3dc c001c410 c4823fdc c4823fc8 3fc0: c00221ac c4823ff4 c4823fe0 c0008480 c002a388 3fe0: c4823ff8 c00434ac c00083e8 b4090392 f0786fe7 Backtrace: [] (__bug+0x0/0x2c) from [] (vpfe_register_ccdc_device+0x48/ 0x1e4) [] (vpfe_register_ccdc_device+0x0/0x1e4) from [] (isif_probe +0x1c/0x1c8) r5:c03522f0 r4:c03522f0 [] (isif_probe+0x0/0x1c8) from [] (platform_drv_probe+0x20/0 x24) r7:c49615a0 r6:c036e2b0 r5:c03522f0 r4:c03522f0 [] (platform_drv_probe+0x0/0x24) from [] (driver_probe_devic e+0xb0/0x164) [] (driver_probe_device+0x0/0x164) from [] (__driver_attach+ 0x68/0x8c) r7:c49615a0 r6:c036e2b0 r5:c0352324 r4:c03522f0 [] (__driver_attach+0x0/0x8c) from [] (bus_for_each_dev+0x50 /0x84) r7:c49615a0 r6:c036e2b0 r5:c0199704 r4: [] (bus_for_each_dev+0x0/0x84) from [] (driver_attach+0x20/0 x28) r6:c036e2b0 r5:c036e2b0 r4:c00221ac [] (driver_attach+0x0/0x28) from [] (bus_add_driver+0xa4/0x2 30) [] (bus_add_driver+0x0/0x230) from [] (driver_register+0xb0/ 0x13c) [] (driver_register+0x0/0x13c) from [] (platform_driver_regi ster+0x4c/0x60) r9: r8: r7:0001 r6:c001c400 r5: r4:c00221ac [] (platform_driver_register+0x0/0x60) from [] (isif_init+0x 14/0x1c) [] (isif_init+0x0/0x1c) from [] (do_one_initcall+0x64/0x1c4) [] (do_one_initcall+0x0/0x1c4) from [] (kernel_init+0xa8/0x1 64) r7: r6: r5: r4:c00221ac [] (kernel_init+0x0/0x164) from [] (do_exit+0x0/0x684) r5: r4: Code: e1a01000 e59f000c eb093134 e3a03000 (e5833000) This IOCTL handling code in isif.c had to be removed during merge to upstream based on community feedback and is required only for raw bayer RGB capture. However since it was earlier a mandatory call in vpfe capture, there was no check in vpfe_capture.c to see if the ccdc/isif i
RE: [PATCH 1/2 v2] spi: overhaul davinci spi driver to correct multiple errors
Hi Brian, On Mon, Mar 15, 2010 at 21:20:13, Kevin Hilman wrote: > Brian Niebuhr writes: > > > > > This patch is a significant overhaul of the davinci spi > >> controller driver > >> > that corrects multiple errors: > >> > > >> > - Eliminate a race condition that exists for slow SPI devices > >> > - Fix DMA transfer length error > >> > - Fix limitations preventing multiple SPI devices on the > >> same controller > >> > > >> > Signed-off-by: Brian Niebuhr > >> > >> The verbose description of the issues addressed from PATCH 0/2 should > >> go here is well so it makes it into the permanent git history. > > > > I can certainly do that. > > > >> That being said, I think for the sake of reviewing, you're going to > >> need to break this up into reviewable pieces, each having a verbose > >> description of the issues being solved. > >> > >> There is also a mixture of fixes, enhancements, renames etc. These > >> should be done as separate patches. > >> > >> I know that it's more work to break it up like this, but that's the > >> only way to make a large change like this reviewable by others. > > > > I guess I was hoping that this could be reviewed as if it were a new > > driver submission. I ended up more or less rewriting all of the > > functional parts of the driver (txrx_bufs(), chipselect(), IRQs and DMA > > callbacks), so it's very difficult to show this as a series of changes. > > I do understand the problem from your perspective, though. My thought > > was that if the TI folks were willing to look the driver over and they > > gave their blessing, that you would look at it as if it were a > > replacement driver and accept or deny it on that basis. > > I'm OK with the approach of considering it as a brand new driver. The > changelog made me think it was a bunch of fixes/enhancements and not a > re-write. > > It should then be made more clear in the changelog that this is > essentially a re-write, and why it is not done in a series of small > changes. > > Whichever approach, this will need to worked out between you and the > origial TI authors (Sandeep, Sudahkar) who will need to review/signoff > this replacement. > I tried testing this patch on some DA8xx platforms I have but could not do it as the patch did not apply cleanly to Kevin's tree. You might have to rebase this patch so that it applies on Kevin's tree. Also, I would still prefer if you can breakdown this patch as per the various fixes you have done because the current SPI driver is already accepted in mainline and is working, of course with some limitations. But if you want to treat it as complete overhaul, then it is better to split the patch such that, one patch removes the existing driver and other patch adds the new driver. In this way it is easy to review the patch. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Custom pinmuxing on DM355 with git kernel
Steve Chen writes: >> >> How about a generic interface which included claim/free resource >> methods, like for gpio, but taking a pointer to a mux resource struct >> instead of a gpio number. The mux resource struct would include function >> pointers to mach- or soc- specific functions to do the work of checking, >> setting and freeing the mux resources. The mux resource struct would >> also contain a list of mach- or soc- specific resource data required by >> that device (pointers into an array of mux resource structs or >> whatever?) >> >> The mux resources would be setup and passed by the board init to the >> driver. The driver could claim and release them using the >> platform-independent functions. The platform-independent functions could >> just be wrappers calling the mach-specific functions, or do more >> elaborate generic things (sysfs stuff, printing/handling conflicts) >> >> I appreciate this is fairly simpleminded and doesn't handle, for >> example, large peripherals that you may not want to mux all of the pins >> for (I'm thinking DM355 VPFE, we reuse the sync pins for example). >> >> Obviously I am handwaving all implementation details. Just trying to get >> a grip on the theory and appreciate all experienced criticism. >> > > Kevin, > > This reminds me of the discussions between you, Mark G, and Dave > Brownell about dynamic pinmux setup and conflict detection. I seem to > remember a comment regarding a change in clock setup (or was it some > driver init) that would make a variant of dynamic pinmux setup in MVL > Pro5 acceptable to the community. Just wondering if you remember any > details. > I don't remember anything that would make the MVL5 method acceptable. What I remember saying was that there was a new framework coming along that would generalize dynamic runtime PM features, allowing more than just clocks to be managed if desired. This framework is now in mainline, and is called runtime PM. I am currently working on the implementation for OMAP. There's an LWN article[1] covering the basics, and I'll also be giving a talk on runtime PM at ELC San Francisco in abouta month. Kevin [1] http://lwn.net/Articles/347573/ ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Custom pinmuxing on DM355 with git kernel
Mike Williamson writes: > On Wed, Mar 17, 2010 at 8:17 AM, Steve Chen wrote: >> On Fri, Mar 12, 2010 at 7:06 PM, Mike Williamson >> wrote: >>> >>> >>> On Fri, Mar 12, 2010 at 5:18 PM, Kevin Hilman >>> wrote: "Nori, Sekhar" writes: > On Thu, Mar 11, 2010 at 11:45:47, Jon Povey wrote: >> Steve Chen wrote: >> > On Wed, Mar 10, 2010 at 12:49 AM, Jon Povey >> > wrote: >> >> >> We have 3 different boards using DM355, with different gpio / pinmux >> >> setups. So far, our device drivers are modules which fiddle the >> >> pinmux registers directly. >> >> >> At the moment I am thinking that I might want to split up >> >> davinci_cfg_reg into two functions so it's not hardwired to >> >> soc_info->pinmux_pins, and I could pass my own mux_config structs >> >> in. If this is of interest I can have a go at doing this and >> >> submitting the patch here. >> > >> > For board specific pinmux, you can put them in board-dm355-*.c. >> > There are some board specific pinmux setup in board-da830-evm.c. >> > Look for da8xx_pinmux_setup. >> >> Thanks, I see this. I have also been looking at the gpiolib support and >> something like that would be useful. >> >> At minimum it would be helpful to split out the davinci_cfg_reg stuff >> as >> described above so that driver modules can use the same functions. > > Methods of handing pinmux were debated at length on this list. I think > this > thread captures most of it: > > > http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg11281.html > > It's a long thread, but very useful read. > > I don't think having drivers handle pinmux directly is acceptable at > all. Correct. Drivers should not do muxing. This should be done by SoC or board init code. If your bootloader is doing it, that suggests that it is init-time only, and should be done in init code. >>> >>> Would it be possible to architect the pin-mux logic to accept boot >>> arguments to >>> configure the SoC devices wanted? We are struggling with porting a kernel >>> to >>> a davinci based System-on-Module type board that would allow end users to >>> select what interfaces (e.g., UARTS vs. SPI ports) to use on these devices. >>> >> >> With the pinmux stuff in the board specific code, u-boot passes the >> board type into the kernel, so only the code that matches the specific >> board type is executed. I realized that I'm repeating my last post. >> Perhaps I don't fully understand your requirements. >> >> Regarding your comment about passing pinmux setting as a kernel >> parameter. Of course that can be done. you got the source code ;) >> The dangers are >> >> 1. The change would not be accepted by the community. >> 2. Potential maintenance issue with custom kernel. >> > > Understood, and I have no desire to go this route. > >>> Having a pile of custom machines (kernel configurations) for every >>> permutation seems >>> painful if all they are doing is enabling different devices. I sort of >>> thought the >> >> Kevin's tree supports single binary that boots multiple DaVinci SoC. >> In other words, you can have a single binary with multiple boards (or >> SoCs) enabled. You can have a specific pinmux setting depends on the >> board type u-boot pass to the kernel in a single binary. >> > > My concern spawns from the fact that I can foresee maybe as many as > 20 unique pinmux configurations for 1 specific davinci based SoM. This > is based on real experience with older SoM's (not running a linux OS). > These devices support a lot of permutations of pin assignments. > > If the right way is really to register 20 different machines over time and > make 20 different board init files and submit them up, no problem. But it > seems like it would become a headache managing that over time. Is there any way in SW to determine between the variants? If so, you don't need 20 different machine types, just a single one with runtime detection in the board file. > I had a brief experience working with FreeScale parts that used a ROM > device tree block, where this sort of configuration was read in at init and > provided a way to define which peripherals on a SoC you wanted to use > without having to rebuild the kernel (or "worse", make a new machine type). > It was't perfect, but seemed to work. I thought perhaps there was a > similar approach available for the davincis. > > Thanks for the insight. One way or the other, you have to maintain *something* different for each variant. A separate u-boot, separate device tree or a separate pin-mux init in the kernel. Since we don't have device trees for ARM/Linux (not unique to davinci), I strongly prefer the latter. If you cannot detect the variant boards in SW, an alternate might be to use a single machine type but add a custom command-li
Re: [PATCH v4 2/3] davinci: da8xx/omapl EVM: Specify reserved channels/slots
Sekhar Nori writes:
> From: Sudhakar Rajashekhara
>
> The drivers on da8xx/omapl EVMs do not utilize all the channels
> and slots provided by EDMA. Some of these are better utilitzed by
> the DSP on the SoC for speeding up codec operations.
>
> Reserve these channels/slots for the DSP.
>
> Signed-off-by: Sudhakar Rajashekhara
> Signed-off-by: Sekhar Nori
> ---
> arch/arm/mach-davinci/board-da830-evm.c| 32 ++-
> arch/arm/mach-davinci/board-da850-evm.c| 48
> +++-
> arch/arm/mach-davinci/devices-da8xx.c | 21 +++-
> arch/arm/mach-davinci/include/mach/da8xx.h |3 +-
> 4 files changed, 92 insertions(+), 12 deletions(-)
>
Thanks, I like this one better. Still a small problem though..
> +int __init da850_register_edma(struct edma_rsv_info *rsv)
> +{
> + if (rsv) {
> + da850_edma_info[0].rsv = &rsv[0];
> + da850_edma_info[1].rsv = &rsv[1];
> + }
> +
> + return platform_device_register(&da850_edma_device);
What if the caller only has reserved chans/slots for controller 0?
&rsv[1] will be an undefined pointer.
I think you need some sort of terminator on the list passed in.
so only edma_rsv_info pointers that are valid are passed along.
Kevin
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Custom pinmuxing on DM355 with git kernel
On Wed, Mar 17, 2010 at 8:37 AM, Kevin Hilman wrote: > Steve Chen writes: > >>> >>> How about a generic interface which included claim/free resource >>> methods, like for gpio, but taking a pointer to a mux resource struct >>> instead of a gpio number. The mux resource struct would include function >>> pointers to mach- or soc- specific functions to do the work of checking, >>> setting and freeing the mux resources. The mux resource struct would >>> also contain a list of mach- or soc- specific resource data required by >>> that device (pointers into an array of mux resource structs or >>> whatever?) >>> >>> The mux resources would be setup and passed by the board init to the >>> driver. The driver could claim and release them using the >>> platform-independent functions. The platform-independent functions could >>> just be wrappers calling the mach-specific functions, or do more >>> elaborate generic things (sysfs stuff, printing/handling conflicts) >>> >>> I appreciate this is fairly simpleminded and doesn't handle, for >>> example, large peripherals that you may not want to mux all of the pins >>> for (I'm thinking DM355 VPFE, we reuse the sync pins for example). >>> >>> Obviously I am handwaving all implementation details. Just trying to get >>> a grip on the theory and appreciate all experienced criticism. >>> >> >> Kevin, >> >> This reminds me of the discussions between you, Mark G, and Dave >> Brownell about dynamic pinmux setup and conflict detection. I seem to >> remember a comment regarding a change in clock setup (or was it some >> driver init) that would make a variant of dynamic pinmux setup in MVL >> Pro5 acceptable to the community. Just wondering if you remember any >> details. >> > > I don't remember anything that would make the MVL5 method acceptable. > > What I remember saying was that there was a new framework coming along > that would generalize dynamic runtime PM features, allowing more than > just clocks to be managed if desired. > > This framework is now in mainline, and is called runtime PM. I am > currently working on the implementation for OMAP. > > There's an LWN article[1] covering the basics, and I'll also be giving > a talk on runtime PM at ELC San Francisco in abouta month. > > Kevin > > [1] http://lwn.net/Articles/347573/ > Kevin, Yes, runtime PM was it. I'll check out the link. Thanks, Steve ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 1/6] davinci: timers: don't enable timer until clocksource is initialized
On da830, when the same timer is used for clocksource and clockevent,
the timer can be started before the clockevent is
registered/initialzed. This creates a window where a timer
interrupt might fire before the clockevent handler has been
setup and causes a crash.
This patch moves the actual enable/start of the timer after
the clockevent has ben registered.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-davinci/time.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c
index 42d985b..9e0b106 100644
--- a/arch/arm/mach-davinci/time.c
+++ b/arch/arm/mach-davinci/time.c
@@ -253,8 +253,6 @@ static void __init timer_init(void)
irq = USING_COMPARE(t) ? dtip[i].cmp_irq : irq;
setup_irq(irq, &t->irqaction);
}
-
- timer32_config(&timers[i]);
}
}
@@ -331,6 +329,7 @@ static void __init davinci_timer_init(void)
unsigned int clocksource_id;
static char err[] __initdata = KERN_ERR
"%s: can't register clocksource!\n";
+ int i;
clockevent_id = soc_info->timer_info->clockevent_id;
clocksource_id = soc_info->timer_info->clocksource_id;
@@ -389,6 +388,9 @@ static void __init davinci_timer_init(void)
clockevent_davinci.cpumask = cpumask_of(0);
clockevents_register_device(&clockevent_davinci);
+
+ for (i=0; i< ARRAY_SIZE(timers); i++)
+ timer32_config(&timers[i]);
}
struct sys_timer davinci_timer = {
--
1.7.0.2
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 3/6] davinci: edma: clear events in edma_start()
From: Brian Niebuhr
This patch fixes an issue where a DMA channel can erroneously process an
event generated by a previous transfer. A failure case is where DMA is
being used for SPI transmit and receive channels on OMAP L138. In this
case there is a single bit that controls all event generation from the
SPI peripheral. Therefore it is possible that between when edma_stop()
has been called for the transmit channel on a previous transfer and
edma_start() is called for the transmit channel on a subsequent transfer,
that a transmit event has been generated.
The fix is to clear events in edma_start(). This prevents false events
from being processed when events are enabled for that channel.
Signed-off-by: Brian Niebuhr
Signed-off-by: Kevin Hilman
---
arch/arm/mach-davinci/dma.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index 15dd886..260485c 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -1266,7 +1266,8 @@ int edma_start(unsigned channel)
/* EDMA channel with event association */
pr_debug("EDMA: ER%d %08x\n", j,
edma_shadow0_read_array(ctlr, SH_ER, j));
- /* Clear any pending error */
+ /* Clear any pending event or error */
+ edma_write_array(ctlr, EDMA_ECR, j, mask);
edma_write_array(ctlr, EDMA_EMCR, j, mask);
/* Clear any SER */
edma_shadow0_write_array(ctlr, SH_SECR, j, mask);
--
1.7.0.2
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 4/6] davinci: DM365: fix duplicate default IRQ priorities
IRQ 29 has two possible interrupts DDRINT and RTC, but having both in
the default priority table is confusing (and triggers a warning from
sparse.)
This patch removes the lower priority DDRINT from the default priority
table leaving the RTC setting as the default.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-davinci/dm365.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 27772e1..0d6ee58 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -758,7 +758,6 @@ static u8 dm365_default_priorities[DAVINCI_N_AINTC_IRQ] = {
[IRQ_MMCINT]= 7,
[IRQ_DM365_MMCINT1] = 7,
[IRQ_DM365_PWMINT3] = 7,
- [IRQ_DDRINT]= 4,
[IRQ_AEMIFINT] = 2,
[IRQ_DM365_SDIOINT1]= 2,
[IRQ_TINT0_TINT12] = 7,
--
1.7.0.2
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 0/6] davinci fixes for 2.6.34-rc
This series of davinci fixes is targeted for the next 2.6.34-rc, and are also available in the 'davinci-fixes' branch of: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git Kevin Brian Niebuhr (1): davinci: edma: clear events in edma_start() Kevin Hilman (4): davinci: timers: don't enable timer until clocksource is initialized davinci: DM365: fix duplicate default IRQ priorities davinci: misc cleanups from sparse davinci: sparse: gpio: void casting Sekhar Nori (1): davinci: da8xx/omap-l1: fix build error when CONFIG_DAVINCI_MUX is undefined arch/arm/mach-davinci/board-dm644x-evm.c |2 +- arch/arm/mach-davinci/board-neuros-osd2.c |2 +- arch/arm/mach-davinci/board-sffsdr.c |2 +- arch/arm/mach-davinci/cdce949.c|1 + arch/arm/mach-davinci/clock.c |1 + arch/arm/mach-davinci/devices.c|2 + arch/arm/mach-davinci/dm355.c |2 +- arch/arm/mach-davinci/dm365.c |3 +- arch/arm/mach-davinci/dm644x.c |4 +- arch/arm/mach-davinci/dm646x.c |6 ++-- arch/arm/mach-davinci/dma.c|3 +- arch/arm/mach-davinci/gpio.c | 41 +--- arch/arm/mach-davinci/include/mach/da8xx.h |4 +++ arch/arm/mach-davinci/include/mach/gpio.h |8 +++--- arch/arm/mach-davinci/mux.c|1 + arch/arm/mach-davinci/time.c |6 +++- 16 files changed, 54 insertions(+), 34 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 2/6] davinci: da8xx/omap-l1: fix build error when CONFIG_DAVINCI_MUX is undefined
From: Sekhar Nori
The da8xx/omap-l1 boards refuse to build when CONFIG_DAVINCI_MUX is undefined
because arch/arm/mach-davinci/mux.c:da8xx_pinmux_setup() is not defined.
This patch fixes this issue. This is build tested with davinci_all_defconfig
and da8xx_omapl_defconfig and boot tested on DA830 EVM.
Reported-by: Shanmuga Sundaram Mahendran
Signed-off-by: Sekhar Nori
Signed-off-by: Kevin Hilman
---
arch/arm/mach-davinci/include/mach/da8xx.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h
b/arch/arm/mach-davinci/include/mach/da8xx.h
index cc9be7f..b87a6ba 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -144,6 +144,10 @@ extern const short da850_mmcsd0_pins[];
extern const short da850_nand_pins[];
extern const short da850_nor_pins[];
+#ifdef CONFIG_DAVINCI_MUX
int da8xx_pinmux_setup(const short pins[]);
+#else
+static inline int da8xx_pinmux_setup(const short pins[]) { return 0; }
+#endif
#endif /* __ASM_ARCH_DAVINCI_DA8XX_H */
--
1.7.0.2
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 5/6] davinci: misc cleanups from sparse
- Convert data/functions to static
- include headers for missing declarations
- pointer cleanups: struct foo *__iomem f --> struct foo __iomem *f;
Signed-off-by: Kevin Hilman
---
arch/arm/mach-davinci/board-dm644x-evm.c |2 +-
arch/arm/mach-davinci/board-neuros-osd2.c |2 +-
arch/arm/mach-davinci/board-sffsdr.c |2 +-
arch/arm/mach-davinci/cdce949.c |1 +
arch/arm/mach-davinci/clock.c |1 +
arch/arm/mach-davinci/devices.c |2 ++
arch/arm/mach-davinci/dm355.c |2 +-
arch/arm/mach-davinci/dm365.c |2 +-
arch/arm/mach-davinci/dm644x.c|4 ++--
arch/arm/mach-davinci/dm646x.c|6 +++---
arch/arm/mach-davinci/gpio.c | 24
arch/arm/mach-davinci/include/mach/gpio.h |8
arch/arm/mach-davinci/mux.c |1 +
13 files changed, 31 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 976e11b..95cef1f 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -111,7 +111,7 @@ static struct platform_device davinci_evm_norflash_device =
{
* It may used instead of the (default) NOR chip to boot, using TI's
* tools to install the secondary boot loader (UBL) and U-Boot.
*/
-struct mtd_partition davinci_evm_nandflash_partition[] = {
+static struct mtd_partition davinci_evm_nandflash_partition[] = {
/* Bootloader layout depends on whose u-boot is installed, but we
* can hide all the details.
* - block 0 for u-boot environment ... in mainline u-boot
diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c
b/arch/arm/mach-davinci/board-neuros-osd2.c
index bd9ca07..1fadc68 100644
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -60,7 +60,7 @@
#define NAND_BLOCK_SIZESZ_128K
-struct mtd_partition davinci_ntosd2_nandflash_partition[] = {
+static struct mtd_partition davinci_ntosd2_nandflash_partition[] = {
{
/* UBL (a few copies) plus U-Boot */
.name = "bootloader",
diff --git a/arch/arm/mach-davinci/board-sffsdr.c
b/arch/arm/mach-davinci/board-sffsdr.c
index 08d373b..a7cf810 100644
--- a/arch/arm/mach-davinci/board-sffsdr.c
+++ b/arch/arm/mach-davinci/board-sffsdr.c
@@ -48,7 +48,7 @@
#define DAVINCI_ASYNC_EMIF_CONTROL_BASE 0x01e0
#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE 0x0200
-struct mtd_partition davinci_sffsdr_nandflash_partition[] = {
+static struct mtd_partition davinci_sffsdr_nandflash_partition[] = {
/* U-Boot Environment: Block 0
* UBL:Block 1
* U-Boot: Blocks 6-7 (256 kb)
diff --git a/arch/arm/mach-davinci/cdce949.c b/arch/arm/mach-davinci/cdce949.c
index aec3756..ba8b12b 100644
--- a/arch/arm/mach-davinci/cdce949.c
+++ b/arch/arm/mach-davinci/cdce949.c
@@ -19,6 +19,7 @@
#include
#include
+#include
#include "clock.h"
diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c
index bf6218e..058c77f 100644
--- a/arch/arm/mach-davinci/clock.c
+++ b/arch/arm/mach-davinci/clock.c
@@ -22,6 +22,7 @@
#include
+#include
#include
#include
#include "clock.h"
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 1479496..ef28080 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -23,6 +23,8 @@
#include
#include
+#include "clock.h"
+
#define DAVINCI_I2C_BASE0x01C21000
#define DAVINCI_MMCSD0_BASE 0x01E1
#define DM355_MMCSD0_BASE 0x01E11000
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 3dc0a88..5efce70 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -798,7 +798,7 @@ static void __iomem *dm355_psc_bases[] = {
* T1_BOT: Timer 1, bottom: (used by DSP in TI DSPLink code)
* T1_TOP: Timer 1, top :
*/
-struct davinci_timer_info dm355_timer_info = {
+static struct davinci_timer_info dm355_timer_info = {
.timers = davinci_timer_instance,
.clockevent_id = T0_BOT,
.clocksource_id = T0_TOP,
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 0d6ee58..871be5a 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1010,7 +1010,7 @@ static void __iomem *dm365_psc_bases[] = {
IO_ADDRESS(DAVINCI_PWR_SLEEP_CNTRL_BASE),
};
-struct davinci_timer_info dm365_timer_info = {
+static struct davinci_timer_info dm365_timer_info = {
.timers = davinci_timer_instance,
.clockevent_id = T0_BOT,
.clocksource_id = T0_TOP,
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 2f2ae8b..23cbe9d 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/
[PATCH 6/6] davinci: sparse: gpio: void casting
Cleanup usage of void pointers when using genirq. genirq API
takes and returns void *, where this GPIO API is using those
as __iomem pointers.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-davinci/gpio.c | 27 ++-
1 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index 3f77062..5476ad1 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -36,6 +36,15 @@ static struct gpio_controller __iomem __init
*gpio2controller(unsigned gpio)
return __gpio_to_controller(gpio);
}
+static inline struct gpio_controller __iomem *irq2controller(int irq)
+{
+ struct gpio_controller __iomem *g;
+
+ g = (__force struct gpio_controller __iomem *)get_irq_chip_data(irq);
+
+ return g;
+}
+
static int __init davinci_gpio_irq_setup(void);
/*--*/
@@ -161,7 +170,7 @@ pure_initcall(davinci_gpio_setup);
static void gpio_irq_disable(unsigned irq)
{
- struct gpio_controller __iomem *g = get_irq_chip_data(irq);
+ struct gpio_controller __iomem *g = irq2controller(irq);
u32 mask = (u32) get_irq_data(irq);
__raw_writel(mask, &g->clr_falling);
@@ -170,7 +179,7 @@ static void gpio_irq_disable(unsigned irq)
static void gpio_irq_enable(unsigned irq)
{
- struct gpio_controller __iomem *g = get_irq_chip_data(irq);
+ struct gpio_controller __iomem *g = irq2controller(irq);
u32 mask = (u32) get_irq_data(irq);
unsigned status = irq_desc[irq].status;
@@ -186,7 +195,7 @@ static void gpio_irq_enable(unsigned irq)
static int gpio_irq_type(unsigned irq, unsigned trigger)
{
- struct gpio_controller __iomem *g = get_irq_chip_data(irq);
+ struct gpio_controller __iomem *g = irq2controller(irq);
u32 mask = (u32) get_irq_data(irq);
if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
@@ -215,7 +224,7 @@ static struct irq_chip gpio_irqchip = {
static void
gpio_irq_handler(unsigned irq, struct irq_desc *desc)
{
- struct gpio_controller __iomem *g = get_irq_chip_data(irq);
+ struct gpio_controller __iomem *g = irq2controller(irq);
u32 mask = 0x;
/* we only care about one bank */
@@ -276,7 +285,7 @@ static int gpio_to_irq_unbanked(struct gpio_chip *chip,
unsigned offset)
static int gpio_irq_type_unbanked(unsigned irq, unsigned trigger)
{
- struct gpio_controller __iomem *g = get_irq_chip_data(irq);
+ struct gpio_controller __iomem *g = irq2controller(irq);
u32 mask = (u32) get_irq_data(irq);
if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
@@ -362,7 +371,7 @@ static int __init davinci_gpio_irq_setup(void)
for (gpio = 0; gpio < soc_info->gpio_unbanked; gpio++, irq++) {
set_irq_chip(irq, &gpio_irqchip_unbanked);
set_irq_data(irq, (void *) __gpio_mask(gpio));
- set_irq_chip_data(irq, g);
+ set_irq_chip_data(irq, (__force void *) g);
irq_desc[irq].status |= IRQ_TYPE_EDGE_BOTH;
}
@@ -385,12 +394,12 @@ static int __init davinci_gpio_irq_setup(void)
/* set up all irqs in this bank */
set_irq_chained_handler(bank_irq, gpio_irq_handler);
- set_irq_chip_data(bank_irq, g);
- set_irq_data(bank_irq, (void *)irq);
+ set_irq_chip_data(bank_irq, (__force void *) g);
+ set_irq_data(bank_irq, (void *) irq);
for (i = 0; i < 16 && gpio < ngpio; i++, irq++, gpio++) {
set_irq_chip(irq, &gpio_irqchip);
- set_irq_chip_data(irq, g);
+ set_irq_chip_data(irq, (__force void *) g);
set_irq_data(irq, (void *) __gpio_mask(gpio));
set_irq_handler(irq, handle_simple_irq);
set_irq_flags(irq, IRQF_VALID);
--
1.7.0.2
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v4 2/3] davinci: da8xx/omapl EVM: Specify reserved channels/slots
On Wed, Mar 17, 2010 at 20:21:21, Kevin Hilman wrote:
> Sekhar Nori writes:
>
> > From: Sudhakar Rajashekhara
> >
> > The drivers on da8xx/omapl EVMs do not utilize all the channels
> > and slots provided by EDMA. Some of these are better utilitzed by
> > the DSP on the SoC for speeding up codec operations.
> >
> > Reserve these channels/slots for the DSP.
> >
> > Signed-off-by: Sudhakar Rajashekhara
> > Signed-off-by: Sekhar Nori
> > ---
> > arch/arm/mach-davinci/board-da830-evm.c| 32 ++-
> > arch/arm/mach-davinci/board-da850-evm.c| 48
> > +++-
> > arch/arm/mach-davinci/devices-da8xx.c | 21 +++-
> > arch/arm/mach-davinci/include/mach/da8xx.h |3 +-
> > 4 files changed, 92 insertions(+), 12 deletions(-)
> >
>
> Thanks, I like this one better. Still a small problem though..
>
> > +int __init da850_register_edma(struct edma_rsv_info *rsv)
> > +{
> > + if (rsv) {
> > + da850_edma_info[0].rsv = &rsv[0];
> > + da850_edma_info[1].rsv = &rsv[1];
> > + }
> > +
> > + return platform_device_register(&da850_edma_device);
>
> What if the caller only has reserved chans/slots for controller 0?
> &rsv[1] will be an undefined pointer.
>
> I think you need some sort of terminator on the list passed in.
> so only edma_rsv_info pointers that are valid are passed along.
>
Kevin,
I am assuming since all the other platform data is defined for both
controllers, all the platform data should be consistent and provide
information on both controllers.
In case the caller does not need reservation for second controller he
can use NULL initialization:
+static struct edma_rsv_info da850_edma_rsv[] = {
+ {
+ .rsv_chans = da850_dma0_rsv_chans,
+ .rsv_slots = da850_dma0_rsv_slots,
+ },
+ {
+ },
+};
Even currently, if devices-da8xx.c had defined two EDMA instances in resource
structure (da850_edma_resources), but populated da850_edma_info[] for only one
controller, the edma probe would go ahead and access info for second instance.
Is it necessary to check for platform data consistency in such a rigorous manner
(since it is not really a 'user' input)?
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
upstream build broken for emac driver
Hi, When I build upstream accepted branch of linux-davinci tree maintained by Kevin, I get following compilation error... I am reverting to master branch. drivers/net/davinci_emac.c: In function 'emac_dev_xmit': drivers/net/davinci_emac.c:1471: error: implicit declaration of function 'dma_ca che_maint' make[2]: *** [drivers/net/davinci_emac.o] Error 1 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
arago next and gstreamer-ti and dm365
I'm looking at gstreamer-ti, and seems really nice. But the compilation stops due to the error below. I'm not sure that I can ask something to this mailing list, but please answer me where is the best place to go on with git kernel and DM365 codecs. Thanks. http://arago-project.org/git/arago.git commit 86ccaa2e12c182d719d056b8c610885612d5ff64 http://arago-project.org/git/arago-oe-dev.git commit 6ae2b9cc72fd4e9ff99412688c7264bbead47fc1 --- MACHINE=dm365-evm bitbake gstreamer-ti .. NOTE: fetch http://arago-project.org/files/sources/ti_cgt_c6000_6.1.9_setup_linux_x86.bin --17:55:49-- http://arago-project.org/files/sources/ti_cgt_c6000_6.1.9_setup_linux_x86.bin => `/home/sources/NEXTGEN/M/OE/scratch/downloads/ti_cgt_c6000_6.1.9_setup_linux_x86.bin' Resolving arago-project.org... 74.208.68.4 Connecting to arago-project.org|74.208.68.4|:80... connected. HTTP request sent, awaiting response... 404 Not Found 17:55:55 ERROR 404: Not Found. NOTE: fetch http://www.angstrom-distribution.org/unstable/sources/ti_cgt_c6000_6.1.9_setup_linux_x86.bin --17:55:55-- http://www.angstrom-distribution.org/unstable/sources/ti_cgt_c6000_6.1.9_setup_linux_x86.bin => `/home/sources/NEXTGEN/M/OE/scratch/downloads/ti_cgt_c6000_6.1.9_setup_linux_x86.bin' Resolving www.angstrom-distribution.org... 188.40.83.200 Connecting to www.angstrom-distribution.org|188.40.83.200|:80... connected. HTTP request sent, awaiting response... 404 Not Found 17:56:00 ERROR 404: Not Found. NOTE: Task failed: Fetch failed: http://install.source.dir.local /ti_cgt_c6000_6.1.9_setup_linux_x86.bin;name=cgt6xbin ERROR: TaskFailed event exception, aborting ERROR: Build of /home/sources/NEXTGEN/M/OE/arago/recipes/ti/ ti-cgt6x_6.1.9.bb do_fetch failed ERROR: Task 780 (/home/sources/NEXTGEN/M/OE/arago/recipes/ti/ ti-cgt6x_6.1.9.bb, do_fetch) failed NOTE: Tasks Summary: Attempted 1101 tasks of which 1101 didn't need to be rerun and 1 failed. ERROR: '/home/sources/NEXTGEN/M/OE/arago/recipes/ti/ti-cgt6x_6.1.9.bb' failed -- www.opensurf.it ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4 2/3] davinci: da8xx/omapl EVM: Specify reserved channels/slots
"Nori, Sekhar" writes:
> On Wed, Mar 17, 2010 at 20:21:21, Kevin Hilman wrote:
>> Sekhar Nori writes:
>>
>> > From: Sudhakar Rajashekhara
>> >
>> > The drivers on da8xx/omapl EVMs do not utilize all the channels
>> > and slots provided by EDMA. Some of these are better utilitzed by
>> > the DSP on the SoC for speeding up codec operations.
>> >
>> > Reserve these channels/slots for the DSP.
>> >
>> > Signed-off-by: Sudhakar Rajashekhara
>> > Signed-off-by: Sekhar Nori
>> > ---
>> > arch/arm/mach-davinci/board-da830-evm.c| 32 ++-
>> > arch/arm/mach-davinci/board-da850-evm.c| 48
>> > +++-
>> > arch/arm/mach-davinci/devices-da8xx.c | 21 +++-
>> > arch/arm/mach-davinci/include/mach/da8xx.h |3 +-
>> > 4 files changed, 92 insertions(+), 12 deletions(-)
>> >
>>
>> Thanks, I like this one better. Still a small problem though..
>>
>> > +int __init da850_register_edma(struct edma_rsv_info *rsv)
>> > +{
>> > + if (rsv) {
>> > + da850_edma_info[0].rsv = &rsv[0];
>> > + da850_edma_info[1].rsv = &rsv[1];
>> > + }
>> > +
>> > + return platform_device_register(&da850_edma_device);
>>
>> What if the caller only has reserved chans/slots for controller 0?
>> &rsv[1] will be an undefined pointer.
>>
>> I think you need some sort of terminator on the list passed in.
>> so only edma_rsv_info pointers that are valid are passed along.
>>
>
> Kevin,
>
> I am assuming since all the other platform data is defined for both
> controllers, all the platform data should be consistent and provide
> information on both controllers.
>
> In case the caller does not need reservation for second controller he
> can use NULL initialization:
>
> +static struct edma_rsv_info da850_edma_rsv[] = {
> + {
> + .rsv_chans = da850_dma0_rsv_chans,
> + .rsv_slots = da850_dma0_rsv_slots,
> + },
> + {
> + },
> +};
> Even currently, if devices-da8xx.c had defined two EDMA instances in resource
> structure (da850_edma_resources), but populated da850_edma_info[] for only one
> controller, the edma probe would go ahead and access info for second instance.
And probably crash. I would call that a bug that needs a fix.
> Is it necessary to check for platform data consistency in such a rigorous
> manner
> (since it is not really a 'user' input)?
IMO, it is user input. And if we expect it to be straight forward for
anyone to add support for their own board, we should try our best to
make the handling of that board-specific data robust.
At a minimum, to make this cleaner, the size of the *_edma_info
structs (and rsv structs) should use a fixed array size for the max
number of controllers for that SoC. Then checking for NULL
before they are passed along should be done as well.
In addition, after looking at this a little closer, the *_edma_info
structs in devices-da8xx.c could be __initdata since they are copied
during edma_probe() (should be done as a fix before this patch.) The
same for the rsv structs in the board files.
Kevin
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: upstream build broken for emac driver
"Karicheri, Muralidharan" writes:
> Hi,
>
> When I build upstream accepted branch of linux-davinci tree maintained by
> Kevin, I get following compilation error... I am reverting to master branch.
>
> drivers/net/davinci_emac.c: In function 'emac_dev_xmit':
> drivers/net/davinci_emac.c:1471: error: implicit declaration of function
> 'dma_ca
> che_maint'
> make[2]: *** [drivers/net/davinci_emac.o] Error 1
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2
When did you try this?
The davinci-upstream-accepted branch should have the commit below. If
it doesn't, try to re-pull.
Kevin
Author: Sekhar Nori 2010-03-09 03:20:37
Committer: Kevin Hilman 2010-03-16 13:01:14
Parent: d4c893e7d670f1fb67812fc36c43942dfb729c42 (davinci: MMC: Pass number of
SG segments as platform data)
Child: ded384babbf02ecbfc67c7b339e2667f7f7c791e (TI DaVinci EMAC: Convert to
dev_pm_ops)
Branches: davinci-upstream-accepted, new-master,
remotes/origin/davinci-upstream-accepted, remotes/origin/master
Follows: v2.6.34-rc1
Precedes:
net: davinci emac: use dma_{map, unmap}_single API for cache coherency
The davinci emac driver uses some ARM specific DMA APIs
for cache coherency which have been removed from kernel
with the 2.6.34 merge.
Modify the driver to use the dma_{map, unmap}_single() APIs
defined in dma-mapping.h
Without this fix, the driver fails to compile on Linus's
tree.
Tested on DM365 and OMAP-L138 EVMs.
Signed-off-by: Sekhar Nori
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: upstream build broken for emac driver
In the morning...
Nice to know it has been fixed. But I got around it for my testing and hence
not blocking for me.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
>-Original Message-
>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: Wednesday, March 17, 2010 1:22 PM
>To: Karicheri, Muralidharan
>Cc: davinci-linux-open-source
>Subject: Re: upstream build broken for emac driver
>
>"Karicheri, Muralidharan" writes:
>
>> Hi,
>>
>> When I build upstream accepted branch of linux-davinci tree maintained by
>Kevin, I get following compilation error... I am reverting to master branch.
>>
>> drivers/net/davinci_emac.c: In function 'emac_dev_xmit':
>> drivers/net/davinci_emac.c:1471: error: implicit declaration of function
>'dma_ca
>> che_maint'
>> make[2]: *** [drivers/net/davinci_emac.o] Error 1
>> make[1]: *** [drivers/net] Error 2
>> make: *** [drivers] Error 2
>
>When did you try this?
>
>The davinci-upstream-accepted branch should have the commit below. If
>it doesn't, try to re-pull.
>
>Kevin
>
>
>
>Author: Sekhar Nori 2010-03-09 03:20:37
>Committer: Kevin Hilman 2010-03-16 13:01:14
>Parent: d4c893e7d670f1fb67812fc36c43942dfb729c42 (davinci: MMC: Pass number
>of SG segments as platform data)
>Child: ded384babbf02ecbfc67c7b339e2667f7f7c791e (TI DaVinci EMAC: Convert
>to dev_pm_ops)
>Branches: davinci-upstream-accepted, new-master, remotes/origin/davinci-
>upstream-accepted, remotes/origin/master
>Follows: v2.6.34-rc1
>Precedes:
>
>net: davinci emac: use dma_{map, unmap}_single API for cache coherency
>
>The davinci emac driver uses some ARM specific DMA APIs
>for cache coherency which have been removed from kernel
>with the 2.6.34 merge.
>
>Modify the driver to use the dma_{map, unmap}_single() APIs
>defined in dma-mapping.h
>
>Without this fix, the driver fails to compile on Linus's
>tree.
>
>Tested on DM365 and OMAP-L138 EVMs.
>
>Signed-off-by: Sekhar Nori
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT FIX for 2.6.34] V4L - vpfe capture - fix for kernel crash on DM365
From: Muralidharan Karicheri
As part of upstream merge, set_params() function was removed from isif.c. This
requires
removal of BUG_ON() and check for set_params ptr in vpfe_capture.c.
Signed-off-by: Muralidharan Karicheri
---
drivers/media/video/davinci/vpfe_capture.c | 24 +---
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 91f665b..aa7dd65 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -222,7 +222,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device *dev)
BUG_ON(!dev->hw_ops.get_frame_format);
BUG_ON(!dev->hw_ops.get_pixel_format);
BUG_ON(!dev->hw_ops.set_pixel_format);
- BUG_ON(!dev->hw_ops.set_params);
BUG_ON(!dev->hw_ops.set_image_window);
BUG_ON(!dev->hw_ops.get_image_window);
BUG_ON(!dev->hw_ops.get_line_length);
@@ -1704,16 +1703,19 @@ static long vpfe_param_handler(struct file *file, void
*priv,
case VPFE_CMD_S_CCDC_RAW_PARAMS:
v4l2_warn(&vpfe_dev->v4l2_dev,
"VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n");
- ret = ccdc_dev->hw_ops.set_params(param);
- if (ret) {
- v4l2_err(&vpfe_dev->v4l2_dev,
- "Error in setting parameters in CCDC\n");
- goto unlock_out;
- }
- if (vpfe_get_ccdc_image_format(vpfe_dev, &vpfe_dev->fmt) < 0) {
- v4l2_err(&vpfe_dev->v4l2_dev,
- "Invalid image format at CCDC\n");
- goto unlock_out;
+ if (ccdc_dev->hw_ops.set_params) {
+ ret = ccdc_dev->hw_ops.set_params(param);
+ if (ret) {
+ v4l2_err(&vpfe_dev->v4l2_dev,
+ "Error setting parameters in CCDC\n");
+ goto unlock_out;
+ }
+ if (vpfe_get_ccdc_image_format(vpfe_dev,
+ &vpfe_dev->fmt) < 0) {
+ v4l2_err(&vpfe_dev->v4l2_dev,
+ "Invalid image format at CCDC\n");
+ goto unlock_out;
+ }
}
break;
default:
--
1.6.0.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: arago next and gstreamer-ti and dm365
Hi, I would recommend you try using the arago-next branch. The trunk is the stable version, but is kind of outdated. If you have some other problems, you may try poking developers on the #arago IRC channel at freenode. Diego On Mar 17, 2010, at 11:05 AM, Raffaele Recalcati wrote: > I'm looking at gstreamer-ti, and seems really nice. > But the compilation stops due to the error below. > I'm not sure that I can ask something to this mailing list, but please answer > me where is the best place to go on with git kernel and DM365 codecs. > Thanks. > > http://arago-project.org/git/arago.git > commit 86ccaa2e12c182d719d056b8c610885612d5ff64 > > http://arago-project.org/git/arago-oe-dev.git > commit 6ae2b9cc72fd4e9ff99412688c7264bbead47fc1 > > --- > MACHINE=dm365-evm bitbake gstreamer-ti > .. > > NOTE: fetch > http://arago-project.org/files/sources/ti_cgt_c6000_6.1.9_setup_linux_x86.bin > --17:55:49-- > http://arago-project.org/files/sources/ti_cgt_c6000_6.1.9_setup_linux_x86.bin >=> > `/home/sources/NEXTGEN/M/OE/scratch/downloads/ti_cgt_c6000_6.1.9_setup_linux_x86.bin' > Resolving arago-project.org... 74.208.68.4 > Connecting to arago-project.org|74.208.68.4|:80... connected. > HTTP request sent, awaiting response... 404 Not Found > 17:55:55 ERROR 404: Not Found. > > NOTE: fetch > http://www.angstrom-distribution.org/unstable/sources/ti_cgt_c6000_6.1.9_setup_linux_x86.bin > --17:55:55-- > http://www.angstrom-distribution.org/unstable/sources/ti_cgt_c6000_6.1.9_setup_linux_x86.bin >=> > `/home/sources/NEXTGEN/M/OE/scratch/downloads/ti_cgt_c6000_6.1.9_setup_linux_x86.bin' > Resolving www.angstrom-distribution.org... 188.40.83.200 > Connecting to www.angstrom-distribution.org|188.40.83.200|:80... connected. > HTTP request sent, awaiting response... 404 Not Found > 17:56:00 ERROR 404: Not Found. > > NOTE: Task failed: Fetch failed: > http://install.source.dir.local/ti_cgt_c6000_6.1.9_setup_linux_x86.bin;name=cgt6xbin > ERROR: TaskFailed event exception, aborting > ERROR: Build of /home/sources/NEXTGEN/M/OE/arago/recipes/ti/ti-cgt6x_6.1.9.bb > do_fetch failed > ERROR: Task 780 > (/home/sources/NEXTGEN/M/OE/arago/recipes/ti/ti-cgt6x_6.1.9.bb, do_fetch) > failed > NOTE: Tasks Summary: Attempted 1101 tasks of which 1101 didn't need to be > rerun and 1 failed. > ERROR: '/home/sources/NEXTGEN/M/OE/arago/recipes/ti/ti-cgt6x_6.1.9.bb' failed > > > > > -- > www.opensurf.it > ___ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
