date:20110712

RE: [PATCH v3 1/6] arm: davinci: Fix low level gpio irq handlers' argument

2011-07-12 Thread Nori, Sekhar

Hi Ido,

On Tue, Jul 12, 2011 at 02:33:11, Ido Yariv wrote:
 Commit 7416401 (arm: davinci: Fix fallout from generic irq chip
 conversion) introduced a bug, causing low level interrupt handlers to
 get a bogus irq number as an argument. The gpio irq handler falsely
 assumes that the handler data is the irq base number and that is no
 longer true.
 
 Set the irq handler data to be a pointer to the corresponding gpio
 controller. The chained irq handler can then use it to extract both the
 irq base number and the gpio registers structure.
 
 Signed-off-by: Ido Yariv i...@wizery.com
 CC: Thomas Gleixner t...@linutronix.de
 ---
  arch/arm/mach-davinci/gpio.c |   14 +++---
  1 files changed, 11 insertions(+), 3 deletions(-)
 
 diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
 index e722139..7d64a07 100644
 --- a/arch/arm/mach-davinci/gpio.c
 +++ b/arch/arm/mach-davinci/gpio.c
 @@ -254,8 +254,10 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)
  {
   struct davinci_gpio_regs __iomem *g;
   u32 mask = 0x;
 + struct davinci_gpio_controller *ctl;

Lets call the variable d to be consistent with the rest of the file.

  
 - g = (__force struct davinci_gpio_regs __iomem *) 
 irq_desc_get_handler_data(desc);
 + ctl = (struct davinci_gpio_controller *)irq_desc_get_handler_data(desc);
 + g = (struct davinci_gpio_regs __iomem *)ctl-regs;
  
   /* we only care about one bank */
   if (irq  1)
 @@ -278,7 +280,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)
   status = 16;
  
   /* now demux them to the right lowlevel handler */
 - n = (int)irq_get_handler_data(irq);
 + n = ctl-irq_base;

I realized that this breaks for odd banks as the status is
right shifted by 16. The GPIO you are using must have been
in even bank?

   while (status) {
   res = ffs(status);
   n += res;
 @@ -424,7 +426,13 @@ static int __init davinci_gpio_irq_setup(void)
  
   /* set up all irqs in this bank */
   irq_set_chained_handler(bank_irq, gpio_irq_handler);
 - irq_set_handler_data(bank_irq, (__force void *)g);
 +
 + /*
 +  * Each chip handles 32 gpios, and each irq bank consists of 16
 +  * gpio irqs. Pass the irq bank's corresponding controller to
 +  * the chained irq handler.
 +  */
 + irq_set_handler_data(bank_irq, chips[bank * 16 / 32]);

This can simply be:

irq_set_handler_data(bank_irq, chips[gpio / 32]);

In the interest of time, I did these fixes and pushed the
patch to fixes branch of git://gitorious.org/linux-davinci/linux-davinci.git

Can you please test it out and let me know if it works.

Updated patch also attached.

Thanks,
Sekhar

8-
From: Ido Yariv i...@wizery.com
Subject: arm: davinci: Fix low level gpio irq handlers' argument

Commit 7416401 (arm: davinci: Fix fallout from generic irq chip
conversion) introduced a bug, causing low level interrupt handlers to
get a bogus irq number as an argument. The gpio irq handler falsely
assumes that the handler data is the irq base number and that is no
longer true.

Set the irq handler data to be a pointer to the corresponding gpio
controller. The chained irq handler can then use it to extract both the
irq base number and the gpio registers structure.

Signed-off-by: Ido Yariv i...@wizery.com
CC: Thomas Gleixner t...@linutronix.de
[nsek...@ti.com: renamed ctl to d, simplified indexing logic for chips and
took care of odd bank handling in irq handler]
Signed-off-by: Sekhar Nori nsek...@ti.com
---
 arch/arm/mach-davinci/gpio.c |   21 -
 1 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index e722139..cafbe13 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -254,8 +254,10 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)
 {
struct davinci_gpio_regs __iomem *g;
u32 mask = 0x;
+   struct davinci_gpio_controller *d;
 
-   g = (__force struct davinci_gpio_regs __iomem *) 
irq_desc_get_handler_data(desc);
+   d = (struct davinci_gpio_controller *)irq_desc_get_handler_data(desc);
+   g = (struct davinci_gpio_regs __iomem *)d-regs;
 
/* we only care about one bank */
if (irq  1)
@@ -274,11 +276,14 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)
if (!status)
break;
__raw_writel(status, g-intstat);
-   if (irq  1)
-   status = 16;
 
/* now demux them to the right lowlevel handler */
-   n = (int)irq_get_handler_data(irq);
+   n = d-irq_base;
+   if (irq  1) {
+   n += 16;
+   status = 16;
+

Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

2011-07-12 Thread Linus Walleij

On Mon, Jul 11, 2011 at 11:39 PM, Dan Williams dan.j.willi...@intel.com wrote:
 On Mon, Jul 11, 2011 at 2:28 AM, Linus Walleij linus.wall...@linaro.org 
 wrote:

 ...and I suspect the slave device drivers that use TI DMA are not
 expected to ever work with other dmaengines?  Likely the case, but
 just wondering out loud.

Typically the OMAP/TI drivers are one-to-one with this specific DMA
controller, but they *can* support controllers without stride options, and
notice that striding will only be used for the display driver IIRC,
pseudo-code:

ret = dmaengine_device_control(chan, TI_DMA_STRIDE_CONFIG,
(unsigned long) my_stride_config);
if (ret) {
   /*
* OK no striding on this DMA engine, fall back to something else,
* such as creating an SGlist which emulates the striding with one
* sglist element per stride.
*/
}

By injecting an error in the stride config path this can even be
properly tested. So it will become an optional acceleration.

Thanks,
Linus Walleij
___
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] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

2011-07-12 Thread Linus Walleij

On Tue, Jul 12, 2011 at 6:17 AM, Jassi Brar jassisinghb...@gmail.com wrote:

 1) Striding, in one form or other, is supported by other DMACs as well.
   The number will only increase in future.
   Are we to add  VENDOR_DMA_STRIDE_CONFIG for each case ?

If we are sure about this and striding will work in a similar way on all
then let's have the enum named DMA_STRIDE_CONFIG and move the
passed-in struct to linux/dmaengine.h) then?

Would that be:

struct dma_stride_config {
u32 read_bytes;
u32 skip_bytes;
};

Or something more complex?

 2) As Dan noted, client drivers are going to have ifdef hackery in
 order to be common
  to other SoCs.

Don't think so, why? This is a runtime config entirely, and I just illustrated
in mail to Dan how that can be handled by falling back to a sglist I believe?

We can *maybe* even put the fallback code into dmaengine, so that an
emulated sglist in place for the DMAengine is done automatically of the
DMA controller does not support striding.

 3) TI may not have just one DMAC IP used in all the SoCs. So if you want
  vendor specific defines anyway, please atleast also add DMAC version to it.
  Something like
        DMA_SLAVE_CONFIG,
        FSLDMA_EXTERNAL_START,
 +       TI_DMA_v1_STRIDE_CONFIG,

Yep unless we make it generic DMA_STRIDE_CONFIG simply, this makes
a lot of sense.

Linus Walleij
___
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] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

2011-07-12 Thread Raju, Sundaram

 -Original Message-
 From: Linus Walleij [mailto:linus.wall...@linaro.org]
 Sent: Tuesday, July 12, 2011 3:28 PM
 To: Dan Williams
 Cc: Raju, Sundaram; linux-arm-ker...@lists.infradead.org; linux-
 ker...@vger.kernel.org; davinci-linux-open-source@linux.davincidsp.com;
 li...@arm.linux.org.uk; linux-o...@vger.kernel.org
 Subject: Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride
 configuration

 On Mon, Jul 11, 2011 at 11:39 PM, Dan Williams dan.j.willi...@intel.com
 wrote:
  On Mon, Jul 11, 2011 at 2:28 AM, Linus Walleij linus.wall...@linaro.org
 wrote:

  ...and I suspect the slave device drivers that use TI DMA are not
  expected to ever work with other dmaengines?  Likely the case, but
  just wondering out loud.

 Typically the OMAP/TI drivers are one-to-one with this specific DMA
 controller, but they *can* support controllers without stride options, and
 notice that striding will only be used for the display driver IIRC,
 pseudo-code:

 ret = dmaengine_device_control(chan, TI_DMA_STRIDE_CONFIG,
 (unsigned long) my_stride_config);
 if (ret) {
/*
 * OK no striding on this DMA engine, fall back to something else,
 * such as creating an SGlist which emulates the striding with one
 * sglist element per stride.
 */
 }

 By injecting an error in the stride config path this can even be
 properly tested. So it will become an optional acceleration.

Yes, this is exactly what I also wanted to say. :)

But if the client driver does not implement a fallback like this then that
driver will work only with TI DMA and not any other dmaengines.
(Mentioning this because, there are client drivers which are tightly 
coupled to this special configuration)

Keeping this in mind, I had started the original discussion with
the suggestion of modifying the existing prepare API and adding
an extra argument to it, which can be used to pass special configuration.
And I also wanted to generalize that configuration passed.

Anyways that design also will come down to this same path, and instead
of modifying the existing API signatures, I think this is the best way
we can go.

Regards,
Sundaram
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

bad sd card write performance

2011-07-12 Thread Bosi Daniele

Hi all,
I have an application that is writing 2 D1 h264 videos on the SD card and I see 
some slowdown on the thread that is saving the videos on sd card,  when it is 
mounted with the sync option.

I mean with a bitrate lesser than 1 MByte (2 D1 h264 videos), using a class 10 
SD card mounted with the SYNC option, I can write on sd card at a frame rate of 
max 20 fps on both the videos, while the capture tasks are running at 25 fps.

This means that I'm loosing 5 captured frames every sec on both the videos!

So my question is: is there a way to improve the driver write performance on 
the SD card?

BTW the used file system is FAT32 and the hardware has a DM368 cpu with Linux 
kernel 2.6.18 from Udworks

For us the sync option is a requirement, because the system should be power 
cut safe.

Does anyone encountered the same problems?

Thanks in advance
   Daniele

___
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 v3] davinci: da850 EVM: read mac address from SPI flash

2011-07-12 Thread Rajashekhara, Sudhakar

Hi,

On Mon, Jul 11, 2011 at 18:02:55, Nori, Sekhar wrote:
 Hi Sudhakar,
 
 On Mon, Jul 11, 2011 at 14:58:21, Rajashekhara, Sudhakar wrote:
 
  diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
  b/arch/arm/mach-davinci/board-da850-evm.c
  index a7b41bf..5bb6556 100644
  --- a/arch/arm/mach-davinci/board-da850-evm.c
  +++ b/arch/arm/mach-davinci/board-da850-evm.c
  @@ -115,6 +115,25 @@ static struct spi_board_info da850evm_spi_info[] = {
  },
   };
   
  +#ifdef CONFIG_MTD
  +static void da850_evm_m25p80_notify_add(struct mtd_info *mtd)
  +{
  +   char *mac_addr = davinci_soc_info.emac_pdata-mac_addr;
  +   size_t retlen;
  +
  +   if (!strcmp(mtd-name, MAC-Address)) {
  +   mtd-read(mtd, 0, ETH_ALEN, retlen, mac_addr);
  +   if (retlen == ETH_ALEN)
  +   pr_info(Read MAC addr from SPI Flash: %pM\n,
  +   mac_addr);
  +   }
  +}
  +
  +static struct mtd_notifier da850evm_spi_notifier = {
  +   .add= da850_evm_m25p80_notify_add,
  +};
  +#endif
  +
   static struct mtd_partition da850_evm_norflash_partition[] = {
  {
  .name   = bootloaders + env,
  @@ -1117,6 +1136,15 @@ static __init int da850_evm_init_cpufreq(void)
   static __init int da850_evm_init_cpufreq(void) { return 0; }
   #endif
   
  +#ifdef CONFIG_MTD
  +static void da850_evm_setup_mac_addr(void)
  +{
  +   register_mtd_user(da850evm_spi_notifier);
  +}
  +#else
  +static void da850_evm_setup_mac_addr(void) { }
  +#endif
 
 Why not combine this ifdef construct with
 earlier one?
 

Ok. Updated patch will follow.

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

[PATCH v4] davinci: da850 EVM: read mac address from SPI flash

2011-07-12 Thread Rajashekhara, Sudhakar

DA850/OMAP-L138 EMAC driver uses random mac address instead of
a fixed one because the mac address is not stuffed into EMAC
platform data.

This patch provides a function which reads the mac address
stored in SPI flash (registered as MTD device) and populates the
EMAC platform data. The function which reads the mac address is
registered as a callback which gets called upon addition of MTD
device.

NOTE: In case the MAC address stored in SPI flash is erased, follow
the instructions at [1] to restore it.

[1] 
http://processors.wiki.ti.com/index.php/GSG:_OMAP-L138_DVEVM_Additional_Procedures#Restoring_MAC_address_on_SPI_Flash

Modifications in v2:
Guarded registering the mtd_notifier only when MTD is enabled.
Earlier this was handled using mtd_has_partitions() call, but
this has been removed in Linux v3.0.

Modifications in v3:
a. Guarded da850_evm_m25p80_notify_add() function and
   da850evm_spi_notifier structure with CONFIG_MTD macros.
b. Renamed da850_evm_register_mtd_user() function to
   da850_evm_setup_mac_addr() and removed the struct mtd_notifier
   argument to this function.
c. Passed the da850evm_spi_notifier structure to register_mtd_user()
   function.

Modifications in v4:
Moved the da850_evm_setup_mac_addr() function within the first
CONFIG_MTD ifdef construct.

Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com
---
 arch/arm/mach-davinci/board-da850-evm.c |   28 
 1 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index a7b41bf..e83cc86 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -115,6 +115,32 @@ static struct spi_board_info da850evm_spi_info[] = {
},
 };
 
+#ifdef CONFIG_MTD
+static void da850_evm_m25p80_notify_add(struct mtd_info *mtd)
+{
+   char *mac_addr = davinci_soc_info.emac_pdata-mac_addr;
+   size_t retlen;
+
+   if (!strcmp(mtd-name, MAC-Address)) {
+   mtd-read(mtd, 0, ETH_ALEN, retlen, mac_addr);
+   if (retlen == ETH_ALEN)
+   pr_info(Read MAC addr from SPI Flash: %pM\n,
+   mac_addr);
+   }
+}
+
+static struct mtd_notifier da850evm_spi_notifier = {
+   .add= da850_evm_m25p80_notify_add,
+};
+
+static void da850_evm_setup_mac_addr(void)
+{
+   register_mtd_user(da850evm_spi_notifier);
+}
+#else
+static void da850_evm_setup_mac_addr(void) { }
+#endif
+
 static struct mtd_partition da850_evm_norflash_partition[] = {
{
.name   = bootloaders + env,
@@ -1237,6 +1263,8 @@ static __init void da850_evm_init(void)
if (ret)
pr_warning(da850_evm_init: spi 1 registration failed: %d\n,
ret);
+
+   da850_evm_setup_mac_addr();
 }
 
 #ifdef CONFIG_SERIAL_8250_CONSOLE
-- 
1.7.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[PATCH] [RESENDING] Enable USB on TI DM365

2011-07-12 Thread const

 # Common objects
 obj-y  := time.o clock.o serial.o io.o psc.o \
-  gpio.o dma.o usb.o common.o sram.o aemif.o
+  gpio.o dma.o common.o sram.o aemif.o
 
 obj-$(CONFIG_DAVINCI_MUX)  += mux.o
 
@@ -40,3 +40,4 @@ obj-$(CONFIG_MACH_OMAPL138_HAWKBOARD) += board-omapl138-hawk.o
 obj-$(CONFIG_CPU_FREQ) += cpufreq.o
 obj-$(CONFIG_CPU_IDLE) += cpuidle.o
 obj-$(CONFIG_SUSPEND)  += pm.o sleep.o
+obj-$(CONFIG_USB_MUSB_DAVINCI) += usb.o
diff --git a/arch/arm/mach-davinci/include/mach/usb.h 
b/arch/arm/mach-davinci/include/mach/usb.h
index e0bc4ab..863c27f 100644
--- a/arch/arm/mach-davinci/include/mach/usb.h
+++ b/arch/arm/mach-davinci/include/mach/usb.h
@@ -54,6 +54,6 @@ structda8xx_ohci_root_hub {
u8  potpgt;
 };
 
-void davinci_setup_usb(unsigned mA, unsigned potpgt_ms);
+int davinci_setup_usb(unsigned mA, unsigned potpgt_ms);
 
 #endif /* ifndef __ASM_ARCH_USB_H */
diff --git a/arch/arm/mach-davinci/usb.c b/arch/arm/mach-davinci/usb.c
index 23d2b6d..daf5398 100644
--- a/arch/arm/mach-davinci/usb.c
+++ b/arch/arm/mach-davinci/usb.c
@@ -4,13 +4,14 @@
 #include linux/init.h
 #include linux/platform_device.h
 #include linux/dma-mapping.h
-
 #include linux/usb/musb.h
 
 #include mach/common.h
 #include mach/irqs.h
 #include mach/cputype.h
 #include mach/usb.h
+#include mach/mux.h
+#include linux/gpio.h
 
 #define DAVINCI_USB_OTG_BASE   0x01c64000
 
@@ -87,7 +88,7 @@ static struct platform_device usb_dev = {
.num_resources  = ARRAY_SIZE(usb_resources),
 };
 
-void __init davinci_setup_usb(unsigned mA, unsigned potpgt_ms)
+int __init davinci_setup_usb(unsigned mA, unsigned potpgt_ms)
 {
usb_data.power = mA  510 ? 255 : mA / 2;
usb_data.potpgt = (potpgt_ms + 1) / 2;
@@ -99,7 +100,7 @@ void __init davinci_setup_usb(unsigned mA, unsigned 
potpgt_ms)
} else  /* other devices don't have dedicated CPPI IRQ */
usb_dev.num_resources = 2;
 
-   platform_device_register(usb_dev);
+   return platform_device_register(usb_dev);
 }
 
 #ifdef CONFIG_ARCH_DAVINCI_DA8XX
@@ -132,7 +133,7 @@ int __init da8xx_register_usb20(unsigned mA, unsigned 
potpgt)
 
 #else
 
-void __init davinci_setup_usb(unsigned mA, unsigned potpgt_ms)
+int __init davinci_setup_usb(unsigned mA, unsigned potpgt_ms)
 {
 }
 
@@ -178,3 +179,23 @@ int __init da8xx_register_usb11(struct da8xx_ohci_root_hub 
*pdata)
return platform_device_register(da8xx_usb11_device);
 }
 #endif /* CONFIG_DAVINCI_DA8XX */
+
+#ifdef ARCH_DAVINCI_DM365
+int __init dm365_usb_configure(void)
+{
+   /* GPIO33 is multiplexed with USB DRVVBUS */
+   davinci_cfg_reg(DM365_GPIO33);
+   gpio_request(33, usb);
+   gpio_direction_output(33, 1);
+   return davinci_setup_usb(500, 8);
+}
+subsys_initcall(dm365_usb_configure);
+
+static void __exit dm365evm_usb_exit(void)
+{
+   platform_device_unregister(usb_dev);
+}
+module_exit(dm365evm_usb_exit);
+#endif
+
+MODULE_LICENSE(GPL);
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index 2a2adf6..e6721e1 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -72,6 +72,15 @@ static inline void phy_on(void)
/* power everything up; start the on-chip PHY and its PLL */
phy_ctrl = ~(USBPHY_OSCPDWN | USBPHY_OTGPDWN | USBPHY_PHYPDWN);
phy_ctrl |= USBPHY_SESNDEN | USBPHY_VBDTCTEN | USBPHY_PHYPLLON;
+
+   if (cpu_is_davinci_dm365()) {
+   /*
+* DM365 PHYCLKFREQ field [15:12] is set to 2
+* to get clock from 24MHz crystal
+*/
+   phy_ctrl |= USBPHY_CLKFREQ_24MHZ;
+   }
+
__raw_writel(phy_ctrl, USB_PHY_CTRL);
 
/* wait for PLL to lock before proceeding */
@@ -193,6 +202,9 @@ static void davinci_musb_source_power(struct musb *musb, 
int is_on, int immediat
else
schedule_work(evm_vbus_work);
}
+
+   if (cpu_is_davinci_dm365())
+   gpio_set_value(33, is_on);
if (immediate)
vbus_state = is_on;
 #endif
diff --git a/drivers/usb/musb/davinci.h b/drivers/usb/musb/davinci.h
index 046c844..1bf50e6 100644
--- a/drivers/usb/musb/davinci.h
+++ b/drivers/usb/musb/davinci.h
@@ -17,6 +17,7 @@
 /* Integrated highspeed/otg PHY */
 #define USBPHY_CTL_PADDR   (DAVINCI_SYSTEM_MODULE_BASE + 0x34)
 #define USBPHY_DATAPOL BIT(11) /* (dm355) switch D+/D- */
+#define USBPHY_CLKFREQ_24MHZBIT(13)
 #define USBPHY_PHYCLKGDBIT(8)
 #define USBPHY_SESNDEN BIT(7)  /* v(sess_end) comparator */
 #define USBPHY_VBDTCTENBIT(6)  /* v(bus) comparator */
___
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] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

2011-07-12 Thread Raju, Sundaram

 -Original Message-
 From: Linus Walleij [mailto:linus.wall...@linaro.org]
 Sent: Tuesday, July 12, 2011 3:33 PM
 To: Jassi Brar
 Cc: Raju, Sundaram; linux-arm-ker...@lists.infradead.org; linux-
 ker...@vger.kernel.org; davinci-linux-open-source@linux.davincidsp.com;
 li...@arm.linux.org.uk; dan.j.willi...@intel.com; linux-o...@vger.kernel.org
 Subject: Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride
 configuration

 On Tue, Jul 12, 2011 at 6:17 AM, Jassi Brar jassisinghb...@gmail.com
 wrote:

  1) Striding, in one form or other, is supported by other DMACs as well.
    The number will only increase in future.
    Are we to add  VENDOR_DMA_STRIDE_CONFIG for each case ?

 If we are sure about this and striding will work in a similar way on all
 then let's have the enum named DMA_STRIDE_CONFIG and move the
 passed-in struct to linux/dmaengine.h) then?

 Would that be:

 struct dma_stride_config {
 u32 read_bytes;
 u32 skip_bytes;
 };

 Or something more complex?

When I started this discussion on stride config, I received comments like
this is too specific to TI DMAC, and there are not many DMACs which can
do this. I actually wanted to generalize the configuration passed and put
a comment on it similar to the one on top of dma_slave_config, which says

|
|/**
snip
| * The rationale for adding configuration information to this struct
| * is as follows: if it is likely that most DMA slave controllers in
| * the world will support the configuration option, then make it
| * generic. If not: if it is fixed so that it be sent in static from
| * the platform data, then prefer to do that. Else, if it is neither
| * fixed at runtime, nor generic enough (such as bus mastership on
| * some CPU family and whatnot) then create a custom slave config
| * struct and pass that, then make this config a member of that
| * struct, if applicable.
| */
|

If any other DMAC can do similar stride configuration,
then we can generalize it. 

Till we generalize this stride configuration I think a custom
configuration aligned between the client driver and
the offload engine driver can be used.

  2) As Dan noted, client drivers are going to have ifdef hackery in
  order to be common
   to other SoCs.

 Don't think so, why? This is a runtime config entirely, and I just illustrated
 in mail to Dan how that can be handled by falling back to a sglist I believe?

 We can *maybe* even put the fallback code into dmaengine, so that an
 emulated sglist in place for the DMAengine is done automatically of the
 DMA controller does not support striding.

Good Idea.

But the client might always have a better way to handle this fallback than
this suggested fallback code in dmaengine, which will be a common
implementation based on the received sg_list and the DMAC capabilities.
If this is done then preference should be provided to the client's fallback
implementation, if present.

  3) TI may not have just one DMAC IP used in all the SoCs. So if you want
   vendor specific defines anyway, please atleast also add DMAC version to it.
   Something like
         DMA_SLAVE_CONFIG,
         FSLDMA_EXTERNAL_START,
  +       TI_DMA_v1_STRIDE_CONFIG,

 Yep unless we make it generic DMA_STRIDE_CONFIG simply, this makes
 a lot of sense.

Okay, I can add one cmd for the EDMAC in DaVinci series of SoCs and 
one for SDMAC in OMAP series of SoCs.

Regards,
Sundaram
___
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] [RESENDING] Enable USB on TI DM365

2011-07-12 Thread Sergei Shtylyov


Hello.

On 12-07-2011 14:52, co...@makelinux.com wrote:

   There's no use resending -- the patch won't be accepted as is.


  # Common objects
  obj-y := time.o clock.o serial.o io.o psc.o \
-  gpio.o dma.o usb.o common.o sram.o aemif.o
+  gpio.o dma.o common.o sram.o aemif.o

  obj-$(CONFIG_DAVINCI_MUX) += mux.o



   It seems the beginning of the patch got eaten by something.


@@ -132,7 +133,7 @@ int __init da8xx_register_usb20(unsigned mA, unsigned 
potpgt)

  #else

-void __init davinci_setup_usb(unsigned mA, unsigned potpgt_ms)
+int __init davinci_setup_usb(unsigned mA, unsigned potpgt_ms)
  {


   You need the *return* statement here now...


  }



WBR, Sergei
___
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] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

2011-07-12 Thread Linus Walleij

On Tue, Jul 12, 2011 at 12:56 PM, Raju, Sundaram sunda...@ti.com wrote:
 [Me]
 [Jassi]
  3) TI may not have just one DMAC IP used in all the SoCs. So if you want
   vendor specific defines anyway, please atleast also add DMAC version to 
  it.
   Something like
         DMA_SLAVE_CONFIG,
         FSLDMA_EXTERNAL_START,
  +       TI_DMA_v1_STRIDE_CONFIG,

 Yep unless we make it generic DMA_STRIDE_CONFIG simply, this makes
 a lot of sense.

 Okay, I can add one cmd for the EDMAC in DaVinci series of SoCs and
 one for SDMAC in OMAP series of SoCs.

Wait, that's two different silicon blocks right? Then you already have proof
that this spans more than one DMAC and then you can just go for a generic
DMA_STRIDE_CONFIG from day one.

That both are TI does not matter, if they are totally unrelated implementations.

Yours,
Linus Walleij
___
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 support in U-Boot

2011-07-12 Thread Christophe Aeschlimann

Hi Gary,

On 11.07.2011 13:24, Gary Thomas wrote:
 Note: I'm not sure the best place to ask this question as it's very
 Davinci specific.
 
 Has anyone worked on the NAND drivers in U-Boot for the Davinci chips?
 In particular the OMAP-L138?  It seems that the U-Boot drivers in use
 only use software ECC which is incompatible with the hardware ECC engine
 on the device.  My board is booting from NAND and if I use U-Boot to
 update the U-Boot image in NAND, the ECC information is incorrect and
 the board stops booting.

I don't think the problem is HW ECC vs SW ECC the problem is where the
ECC bits are stored in the Out-Of-Band (OOB) area of the NAND.

The ROM boot loader (RBL) expects them to be at a certain position where
U-BOOT and the Linux Kernel have them stored in another place.

More info here :
http://processors.wiki.ti.com/index.php/DM365_Nand_ECC_layout

A solution is to have a small dedicated partition that has the same ECC
layout as the Rom Boot Loader that contain a very basic bootloader (e.g.
TI's UBL) which then let you jump to U-Boot.

Having the RBL loading UBL to load U-Boot to finally start Linux was too
cumbersome for us so we just boot U-Boot directly from a SPI flash.

 Any ideas/help?  Should I ask this on a different list (please don't
 say e2e forums...)

Apart from the terrible user experience the site offers the persons
active on these forums are very helpful.

 Thanks

Hope it helped,

Best regards,

-- 
Christophe Aeschlimann

Embedded Software Engineer  IT Manager

ACN Advanced Communications Networks S.A.

Rue du Puits-Godet 8a
2000 Neuchâtel, Switzerland

Tél. +41 32 724 74 31
c.aeschlim...@acn-group.ch
___
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] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

2011-07-12 Thread Jassi Brar

On Tue, Jul 12, 2011 at 3:33 PM, Linus Walleij linus.wall...@linaro.org wrote:
 On Tue, Jul 12, 2011 at 6:17 AM, Jassi Brar jassisinghb...@gmail.com wrote:

 1) Striding, in one form or other, is supported by other DMACs as well.
   The number will only increase in future.
   Are we to add  VENDOR_DMA_STRIDE_CONFIG for each case ?

 If we are sure about this and striding will work in a similar way on all
 then let's have the enum named DMA_STRIDE_CONFIG and move the
 passed-in struct to linux/dmaengine.h) then?

 Would that be:

 struct dma_stride_config {
    u32 read_bytes;
    u32 skip_bytes;
 };

 Or something more complex?
Well, I am not sure if striding needs any special treatment at all.
Why not have client drivers prepare and submit sg-list.
Let the DMAC drivers interpret/parse the sg-list and program it
as strides if the h/w supports it.
If anything, we should make preparation and submission of sg-list
as efficient as possible.

 2) As Dan noted, client drivers are going to have ifdef hackery in
 order to be common
  to other SoCs.

 Don't think so, why? This is a runtime config entirely, and I just illustrated
 in mail to Dan how that can be handled by falling back to a sglist I believe?
Runtime decision isn't neat either.
What if a client driver is common to 'N' SoCs each with different DMACs ?
We would need a switch construct !
___
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] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

2011-07-12 Thread Raju, Sundaram

 -Original Message-
 From: Jassi Brar [mailto:jassisinghb...@gmail.com]
 Sent: Tuesday, July 12, 2011 4:51 PM
 To: Linus Walleij
 Cc: Raju, Sundaram; linux-arm-ker...@lists.infradead.org; linux-
 ker...@vger.kernel.org; davinci-linux-open-source@linux.davincidsp.com;
 li...@arm.linux.org.uk; dan.j.willi...@intel.com; linux-o...@vger.kernel.org
 Subject: Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride
 configuration

 On Tue, Jul 12, 2011 at 3:33 PM, Linus Walleij linus.wall...@linaro.org
 wrote:
  On Tue, Jul 12, 2011 at 6:17 AM, Jassi Brar jassisinghb...@gmail.com
 wrote:

  1) Striding, in one form or other, is supported by other DMACs as well.
    The number will only increase in future.
    Are we to add  VENDOR_DMA_STRIDE_CONFIG for each case ?

  If we are sure about this and striding will work in a similar way on all
  then let's have the enum named DMA_STRIDE_CONFIG and move the
  passed-in struct to linux/dmaengine.h) then?

  Would that be:

  struct dma_stride_config {
     u32 read_bytes;
     u32 skip_bytes;
  };

  Or something more complex?
 Well, I am not sure if striding needs any special treatment at all.
 Why not have client drivers prepare and submit sg-list.
 Let the DMAC drivers interpret/parse the sg-list and program it
 as strides if the h/w supports it.
 If anything, we should make preparation and submission of sg-list
 as efficient as possible.
Jassi,

sg_lists describe only a bunch of disjoint buffers. But what if the
DMAC can skip and read the bytes within each of the buffers in
the sg_list? (like TI EDMAC and TI SDMAC)
How can that information be passed to the offload
engine driver from the client?

~Sundaram
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: [ RFC PATCH 0/8] RFC for Media Controller capture driver for DM365

2011-07-12 Thread Hadli, Manjunath


Sakari/Laurent,
  Did you get some time to review the code? Will look forward for your comments.
-Manju

 On Wed, Jul 06, 2011 at 11:10:38, Hadli, Manjunath wrote:
 
 Hi Sakari,
 
  On Mon, Jul 04, 2011 at 21:43:09, Sakari Ailus wrote:
  Hadli, Manjunath wrote:
   Thank you Laurent.
  
  Hi Manjunath,
  
   On Mon, Jul 04, 2011 at 18:52:37, Laurent Pinchart wrote:
   Hi Manjunath,
   
   On Monday 04 July 2011 07:58:06 Hadli, Manjunath wrote:
   On Thu, Jun 30, 2011 at 19:27:36, Sakari Ailus wrote:
   
   [snip]
   
   I understand that not all the blocks are there. Are there any 
   major functional differences between those in Davinci and those 
   in OMAP 3? Could the OMAP 3 ISP driver made support Davinci ISP as 
   well?
   
   Yes, there are a lot of major differences between OMAP3 and 
   Dm365/Dm355, both in terms of features, there IP, and the software 
   interface, including all the registers which are entirely different.
   The closest omap3 would come to is only to DM6446. I do not think
   OMAP3 driver can be made to support Dm355 and Dm365. It is good to 
   keep the OMAP3 neat and clean to cater for OMAP4 and beyond, and 
   keep the Davinci family separate. The names might look similar and 
   hence confusing for you, but the names can as well be made the 
   same as Dm365 blocks like ISIF and IPIPE and IPIPEIF which are 
   different.
   
   The DM6446 ISP is very similar to the OMAP3 ISP, and thus quite 
   different from the DM355/365 ISPs. Should the DM6446 be supported 
   by the OMAP3 ISP driver, and the DM355/365 by this driver ?
   
   DM6446 capture IP is in some respects similar to OMAP3 for some 
   features, but there are a large number of differences also (MMU, 
   VRFB, a lot of display interfaces etc). Having a single driver 
   catering to Since DM6446 and OMAP3 is going to be unwieldy. Also,
   DM6446 belongs to the Davinci family of chips, it should be clubbed 
   with the other Davinci SoCs as it will simplify a lot of other 
   things including directory subdirectory/file naming, organization of 
   machine/platform code etc among other things. Other than Video a lot 
   of other system registers and features which are common with the 
   rest of Davinci SoCs which if treated together is a good thing, 
   whereas
   OMAP3 can be modified and developed with those on the OMAP family
   (OMAP4 for ex).
  
  Thanks for the clarifications.
  
  What about the DM3730? As far as I understand, the ISP on that one is 
  supported by the OMAP 3 ISP driver. But it looks like that it's more 
  continuation for the OMAP family of the chips than the Davinci.
 Let me say that for all practical purposes, for developers, DM3730 is OMAP3. 
 So a distinction between OMAP3 and DM3730 need not be made at all. As to why 
 it is a Davinci device, has more to do with things outside the realm of 
 development. So Dm3730 for us, including you and me, can be OMAP3, As the TRM 
 says -  It is OMAP3 compatible.
 
  
  I glanced at the DM6446 documentation and at the register level the 
  interface looks somewhat different although some register names are the 
  same. I didn't found a proper TRM which would be as detailed as the OMAP 
  ones --- does TI have one available in public?
 TRMs for Davinci devices are slightly in a different format - split into 
 multiple documents for each peripheral and system functionalities unlike a 
 big singe doc for OMAP.
 But all the required documents are in public domain and can be found at :
 http://focus.ti.com/docs/prod/folders/print/tms320dm6446.html  under the user 
 guides category. If you are looking for some particular information, let me 
 know and I can help you locate it.
 
 
 
  
  OMAP 4 has a quite different ISS --- which the ISP is a part of, and which 
  also is very different to the OMAP 3 one  --- so it's unlikely that the 
  same driver would support OMAP 3 and OMAP 4 ISPs.
  
  Kind regards,
  
  --
  Sakari Ailus
  sakari.ai...@iki.fi
  
 
 Regards,
 -Manjunath
 

___
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] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

2011-07-12 Thread Jassi Brar

On Tue, Jul 12, 2011 at 5:01 PM, Raju, Sundaram sunda...@ti.com wrote:
 -Original Message-
 From: Jassi Brar [mailto:jassisinghb...@gmail.com]
 Sent: Tuesday, July 12, 2011 4:51 PM
 To: Linus Walleij
 Cc: Raju, Sundaram; linux-arm-ker...@lists.infradead.org; linux-
 ker...@vger.kernel.org; davinci-linux-open-source@linux.davincidsp.com;
 li...@arm.linux.org.uk; dan.j.willi...@intel.com; linux-o...@vger.kernel.org
 Subject: Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride
 configuration

 On Tue, Jul 12, 2011 at 3:33 PM, Linus Walleij linus.wall...@linaro.org
 wrote:
  On Tue, Jul 12, 2011 at 6:17 AM, Jassi Brar jassisinghb...@gmail.com
 wrote:

  1) Striding, in one form or other, is supported by other DMACs as well.
    The number will only increase in future.
    Are we to add  VENDOR_DMA_STRIDE_CONFIG for each case ?

  If we are sure about this and striding will work in a similar way on all
  then let's have the enum named DMA_STRIDE_CONFIG and move the
  passed-in struct to linux/dmaengine.h) then?

  Would that be:

  struct dma_stride_config {
     u32 read_bytes;
     u32 skip_bytes;
  };

  Or something more complex?
 Well, I am not sure if striding needs any special treatment at all.
 Why not have client drivers prepare and submit sg-list.
 Let the DMAC drivers interpret/parse the sg-list and program it
 as strides if the h/w supports it.
 If anything, we should make preparation and submission of sg-list
 as efficient as possible.
 Jassi,

 sg_lists describe only a bunch of disjoint buffers. But what if the
 DMAC can skip and read the bytes within each of the buffers in
 the sg_list? (like TI EDMAC and TI SDMAC)
 How can that information be passed to the offload
 engine driver from the client?

OK, I overlooked.
We do need something new to handle these ultra-fine-grained sg-lists.
But still we shouldn't add SoC specific API to the common sub-systems.

Maybe a new api to pass fixed-format variable-length encoded message
to the DMAC drivers?
Which could be interpreted by DMAC drivers to extract all the needed xfer
parameters from the 'header' section and instructions to program the xfers
in the DMAC from the variable length body of the 'message' buffer.
It might sound complicated but we can have helpers to make the job easy.
Btw, the regular single/sg-list xfers could also be expressed by this method.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: bad sd card write performance

2011-07-12 Thread Enrico Butera

On Tue, Jul 12, 2011 at 12:17 PM, Bosi Daniele daniele.b...@mta.it wrote:
 Hi all,
 I have an application that is writing 2 D1 h264 videos on the SD card and I 
 see some slowdown on the thread that is saving the videos on sd card,  when 
 it is mounted with the sync option.

 I mean with a bitrate lesser than 1 MByte (2 D1 h264 videos), using a class 
 10 SD card mounted with the SYNC option, I can write on sd card at a frame 
 rate of max 20 fps on both the videos, while the capture tasks are running at 
 25 fps.

 This means that I'm loosing 5 captured frames every sec on both the videos!

 So my question is: is there a way to improve the driver write performance on 
 the SD card?

 BTW the used file system is FAT32 and the hardware has a DM368 cpu with Linux 
 kernel 2.6.18 from Udworks

 For us the sync option is a requirement, because the system should be power 
 cut safe.

 Does anyone encountered the same problems?


Silly question: are you buffering before writing on disk? I mean: if
you make many small writes you'll never reach the SD theoretical write
speed in sync mode, especially with two separate files.

I made some tests (on an omap platform) and i found out that the best
filesystem for this kind of work is nilfs but unfortunately i think
your kernel is too old to support it.

Ciao,

Enrico
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

R: bad sd card write performance

2011-07-12 Thread Bosi Daniele

Enrico,
your one is not a silly question. I tested both write and fwrite functions, 
reaching the best performances with fwrite that AFAIK is buffered.
I also tried splitting the write on the file pointer / file descriptor on 
packets of 32 kBytes (the drivers try to write 64 packets, 512 bytes long), but 
the best solution I found until now on the FAT file system is:
fwrite without splitting the frames. So basically I have a loop for every video 
file where the software writes a frame at a time.

Thanks for your help,
ciao Daniele



-Messaggio originale-
Da: davinci-linux-open-source-boun...@linux.davincidsp.com 
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] Per conto di 
Enrico Butera
Inviato: martedì 12 luglio 2011 17.12
A: davinci-linux-open-source@linux.davincidsp.com
Oggetto: Re: bad sd card write performance

On Tue, Jul 12, 2011 at 12:17 PM, Bosi Daniele daniele.b...@mta.it wrote:
 Hi all,
 I have an application that is writing 2 D1 h264 videos on the SD card and I 
 see some slowdown on the thread that is saving the videos on sd card,  when 
 it is mounted with the sync option.

 I mean with a bitrate lesser than 1 MByte (2 D1 h264 videos), using a class 
 10 SD card mounted with the SYNC option, I can write on sd card at a frame 
 rate of max 20 fps on both the videos, while the capture tasks are running at 
 25 fps.

 This means that I'm loosing 5 captured frames every sec on both the videos!

 So my question is: is there a way to improve the driver write performance on 
 the SD card?

 BTW the used file system is FAT32 and the hardware has a DM368 cpu with Linux 
 kernel 2.6.18 from Udworks

 For us the sync option is a requirement, because the system should be power 
 cut safe.

 Does anyone encountered the same problems?


Silly question: are you buffering before writing on disk? I mean: if
you make many small writes you'll never reach the SD theoretical write
speed in sync mode, especially with two separate files.

I made some tests (on an omap platform) and i found out that the best
filesystem for this kind of work is nilfs but unfortunately i think
your kernel is too old to support it.

Ciao,

Enrico
___
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

Re: bad sd card write performance

2011-07-12 Thread Enrico Butera

On Tue, Jul 12, 2011 at 5:40 PM, Bosi Daniele daniele.b...@mta.it wrote:
 Enrico,
 your one is not a silly question. I tested both write and fwrite 
 functions, reaching the best performances with fwrite that AFAIK is 
 buffered.
 I also tried splitting the write on the file pointer / file descriptor on 
 packets of 32 kBytes (the drivers try to write 64 packets, 512 bytes long), 
 but the best solution I found until now on the FAT file system is:
 fwrite without splitting the frames. So basically I have a loop for every 
 video file where the software writes a frame at a time.

 Thanks for your help,
 ciao Daniele

Just thinking about it, if you have a cbr h264 stream with 1 Mb
bitrate you are writing 128 KB/s, or an average of 5 KB/s per frame.
So you are writing 5 KB of data, 25 times a second. Grand total for
two threads: 50 writes/s just to write 256KB!

You can add logic to batch writes based on a threshold, but i think
it's much more simple to try to disable sync and fflush every X
seconds (even 1 or 2).

Ciao,

Enrico
___
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 support in U-Boot

2011-07-12 Thread Marlon Smith

Hi Christophe,

Sorry to hijack this thread, but it sounds like you have done what I am
trying to do.  I would like to be able to boot a DM365 board off of an
SD card directly into U-boot, which it sounds like you have done just
over SPI instead of SD.  There is no NAND on the board I'm using.

Can you point me a direction where I can find more information on how to
do this?

Thanks

Marlon

On Tue, 2011-07-12 at 13:12 +0200, Christophe Aeschlimann wrote:

 Hi Gary,
 
 On 11.07.2011 13:24, Gary Thomas wrote:
  Note: I'm not sure the best place to ask this question as it's very
  Davinci specific.
  
  Has anyone worked on the NAND drivers in U-Boot for the Davinci chips?
  In particular the OMAP-L138?  It seems that the U-Boot drivers in use
  only use software ECC which is incompatible with the hardware ECC engine
  on the device.  My board is booting from NAND and if I use U-Boot to
  update the U-Boot image in NAND, the ECC information is incorrect and
  the board stops booting.
 
 I don't think the problem is HW ECC vs SW ECC the problem is where the
 ECC bits are stored in the Out-Of-Band (OOB) area of the NAND.
 
 The ROM boot loader (RBL) expects them to be at a certain position where
 U-BOOT and the Linux Kernel have them stored in another place.
 
 More info here :
 http://processors.wiki.ti.com/index.php/DM365_Nand_ECC_layout
 
 A solution is to have a small dedicated partition that has the same ECC
 layout as the Rom Boot Loader that contain a very basic bootloader (e.g.
 TI's UBL) which then let you jump to U-Boot.
 
 Having the RBL loading UBL to load U-Boot to finally start Linux was too
 cumbersome for us so we just boot U-Boot directly from a SPI flash.
 
  Any ideas/help?  Should I ask this on a different list (please don't
  say e2e forums...)
 
 Apart from the terrible user experience the site offers the persons
 active on these forums are very helpful.
 
  Thanks
 
 Hope it helped,
 
 Best regards,
 


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [ RFC PATCH 0/8] RFC for Media Controller capture driver for DM365

2011-07-12 Thread 'Sakari Ailus'

On Tue, Jul 12, 2011 at 05:31:52PM +0530, Hadli, Manjunath wrote:
 
 Sakari/Laurent,
   Did you get some time to review the code? Will look forward for your 
 comments.
 -Manju

Hi Manju,

I'll try to review this in near future.

-- 
Sakari Ailus
sakari.ai...@iki.fi
___
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 v3 1/6] arm: davinci: Fix low level gpio irq handlers' argument

2011-07-12 Thread Ido Yariv

Hi Sekhar,

On Tue, Jul 12, 2011 at 02:52:17PM +0530, Nori, Sekhar wrote:
  -   g = (__force struct davinci_gpio_regs __iomem *) 
  irq_desc_get_handler_data(desc);
  +   ctl = (struct davinci_gpio_controller *)irq_desc_get_handler_data(desc);
  +   g = (struct davinci_gpio_regs __iomem *)ctl-regs;
   
  /* we only care about one bank */
  if (irq  1)
  @@ -278,7 +280,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)
  status = 16;
   
  /* now demux them to the right lowlevel handler */
  -   n = (int)irq_get_handler_data(irq);
  +   n = ctl-irq_base;
 
 I realized that this breaks for odd banks as the status is
 right shifted by 16. The GPIO you are using must have been
 in even bank?

You're absolutely right, I missed that. And yes, I have been using an
even bank GPIO.

  while (status) {
  res = ffs(status);
  n += res;
  @@ -424,7 +426,13 @@ static int __init davinci_gpio_irq_setup(void)
   
  /* set up all irqs in this bank */
  irq_set_chained_handler(bank_irq, gpio_irq_handler);
  -   irq_set_handler_data(bank_irq, (__force void *)g);
  +
  +   /*
  +* Each chip handles 32 gpios, and each irq bank consists of 16
  +* gpio irqs. Pass the irq bank's corresponding controller to
  +* the chained irq handler.
  +*/
  +   irq_set_handler_data(bank_irq, chips[bank * 16 / 32]);
 
 This can simply be:
 
   irq_set_handler_data(bank_irq, chips[gpio / 32]);
 
 In the interest of time, I did these fixes and pushed the
 patch to fixes branch of git://gitorious.org/linux-davinci/linux-davinci.git
 
 Can you please test it out and let me know if it works.

This patch seems to work just fine. I'm afraid I can't test an odd bank
GPIO here to verify that this indeed fixed the issue you raised, but it
looks correct.

Thanks,
Ido.
___
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/4] ARM: davinci: Check for NULL return from irq_alloc_generic_chip

2011-07-12 Thread Todd Poynor

Signed-off-by: Todd Poynor toddpoy...@google.com
---
 arch/arm/mach-davinci/irq.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/irq.c b/arch/arm/mach-davinci/irq.c
index bfe68ec..ab7f688 100644
--- a/arch/arm/mach-davinci/irq.c
+++ b/arch/arm/mach-davinci/irq.c
@@ -52,6 +52,13 @@ davinci_alloc_gc(void __iomem *base, unsigned int irq_start, 
unsigned int num)
struct irq_chip_type *ct;
 
gc = irq_alloc_generic_chip(AINTC, 1, irq_start, base, 
handle_edge_irq);
+
+   if (!gc) {
+   pr_err(%s: irq_alloc_generic_chip for IRQ %u failed\n,
+  __func__, irq_start);
+   return;
+   }
+
ct = gc-chip_types;
ct-chip.irq_ack = irq_gc_ack;
ct-chip.irq_mask = irq_gc_mask_clr_bit;
-- 
1.7.3.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: [GIT PULL] DaVinci fix for v3.0

2011-07-12 Thread Nori, Sekhar

On Wed, Jul 13, 2011 at 10:59:47, Nori, Sekhar wrote:
 Hi Arnd,
 
 Can you please pull this late breaking DaVinci fix for v3.0?
 This is fallout of generic irq chip migration and prevents GPIO
 interrupts from functioning correctly.

Resent with fixed DaVinci Linux mailing list address.

Thanks,
Sekhar

 
 The following changes since commit 620917de59eeb934b9f8cf35cc2d95c1ac8ed0fc:
   Linus Torvalds (1):
 Linux 3.0-rc7
 
 are available in the git repository at:
 
   git://gitorious.org/linux-davinci/linux-davinci.git fixes
 
 Ido Yariv (1):
   arm: davinci: Fix low level gpio irq handlers' argument
 
  arch/arm/mach-davinci/gpio.c |   21 -
  1 files changed, 16 insertions(+), 5 deletions(-)
 
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 

___
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 v3 1/6] arm: davinci: Fix low level gpio irq handlers' argument

Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

RE: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

bad sd card write performance

RE: [PATCH v3] davinci: da850 EVM: read mac address from SPI flash

[PATCH v4] davinci: da850 EVM: read mac address from SPI flash

[PATCH] [RESENDING] Enable USB on TI DM365

RE: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

Re: [PATCH] [RESENDING] Enable USB on TI DM365

Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

Re: NAND support in U-Boot

Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

RE: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

RE: [ RFC PATCH 0/8] RFC for Media Controller capture driver for DM365

Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

Re: bad sd card write performance

R: bad sd card write performance

Re: bad sd card write performance

Re: NAND support in U-Boot

Re: [ RFC PATCH 0/8] RFC for Media Controller capture driver for DM365

Re: [PATCH v3 1/6] arm: davinci: Fix low level gpio irq handlers' argument

[PATCH 1/4] ARM: davinci: Check for NULL return from irq_alloc_generic_chip

RE: [GIT PULL] DaVinci fix for v3.0

24 matches

Site Navigation

Mail list logo

Footer information