Touchscreen and GPIO Interrupt

[Nicolas Luna]

Hi everyone,

I'm running linux davinci on custom hardware with an AM1808.

I got a problem to make working my touchscreen and gpio used as external
interrupt together.

My touchscreen alone is working well but when I add support for gpio used as
external interrupt, the touchscreen is not work anymore. They seems to use
the same input event.

Here is what I did to add *gpio-keys* into *board-da850-evm.c* :

*static struct gpio_keys_button da850_evm_ui_keys[] = {*
*
*
* [0] = {*
* .code = KEY_RECORD, //input event code (KEY_*, SW_*)*
* .gpio = DA850_GPIO_INTERRUPT,*
* .active_low = 0,*
* .desc = "gpio_interrupt",*
* .type = EV_KEY, //input event type (EV_KEY, EV_SW)*
* .wakeup = 0, //configure the button as a wake-up source*
* .debounce_interval = 1, //debounce ticks interval in msecs*
* //.can_disable*
* },*
*};*
*
*
*static struct gpio_keys_platform_data da850_evm_ui_keys_pdata = {*
* .buttons = da850_evm_ui_keys,*
* .nbuttons = ARRAY_SIZE(da850_evm_ui_keys),*
*};*
*
*
*static struct platform_device da850_evm_ui_keys_device = {*
* .name = "gpio-keys",*
* .id = 0,*
* .dev = {*
* .platform_data = &da850_evm_ui_keys_pdata*
* },*
*};*
*
*
*...*
*
*
*ret = platform_device_register(&da850_evm_ui_keys_device);*
*if (ret)*
*   pr_warning("da850_evm_init: gpio interrupt registration failed: %d\n",
ret);*


Both input devices are correclty initialized by the kernel :

*input: gpio-keys as /devices/platform/gpio-keys.0/input/input0*
*input: TPS6507x Touchscreen as
/devices/platform/i2c_davinci.1/i2c-1/1-0048/input/input1*


I wrote an application to read /dev/input/event0, and it allows me to grab
interrupt events that occurred on the gpio.

*struct input_event ev;*
*fd = open( "/dev/input/event0", O_RDONLY );*
*rb = read(fd, &ev, sizeof(struct input_event));*
printf("ev.type: %d | ev.code: %d | ev.value: %d\n", ev.type, ev.code,
ev.value);

When I use it I read correctly events on the gpio but I got an error message
on the touchscreen:

*selected device is not a touchscreen I understand*

*
*
I got */dev/input/touchscreen0 *in my filesystem but for an unknowm reason
the touchscreen also use event0. I tried to cat /dev/input/event0 and I see
event from my gpio interrupt AND the touchscreen.

I would like to create a new eventX in /dev/input to redirect gpio interrupt
there. Is there any way to do that?

Here's more info:

*# cat /proc/bus/input/devices*
*I: Bus=0019 Vendor=0001 Product=0001 Version=0100*
*N: Name="gpio-keys"*
*P: Phys=gpio-keys/input0*
*S: Sysfs=/devices/platform/gpio-keys.0/input/input0*
*U: Uniq=*
*H: Handlers=kbd event0*
*B: EV=3*
*B: KEY=80 0 0 0 0 0*
*
*
*I: Bus=0018 Vendor= Product=fe2e Version=0100*
*N: Name="TPS6507x Touchscreen"*
*P: Phys=1-0048/input0*
*S: Sysfs=/devices/platform/i2c_davinci.1/i2c-1/1-0048/input/input1*
*U: Uniq=*
*H: Handlers=event1*
*B: EV=b*
*B: KEY=400 0 0 0 0 0 0 0 0 0 0*
*B: ABS=103*

Thanks!

Best regards,

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

Touchscreen - MFD driver for TPS6507x family

[Nicolas Luna]

Hi,

I downloaded and tried the kernel v2.6.34 from *
linux/kernel/git/khilman/linux-davinci.git**/ *to get the touchscreen patch.
It is working well, but I wonder if it is normal that the touchscreen
constantly use the I2C bus, even if I don't touch to the touchscreen. Because
of that, it is not possible to have an other device on the bus. Is there any
specific reason why the driver do not use the INT pin from the TPS6507x to
free a little bit the I2C bus.

Thanks

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

Re: Touchscreen - MFD driver for TPS6507x family

[Nicolas Luna]

Hi Todd,

I got custum hardware based on OMAP-L138 EVM, with OMAPL138 and TPS65070.
It's ok you answered my question why the INT pins is not used.

I did more tests and you are right, the touchscreen driver is not locking
out all other access to the I2C bus, that was a mistake from my side. So
everything seems to be ok even if there's a lot a communication on the bus.

Thank you.

Nicolas



On Fri, Jun 4, 2010 at 4:33 PM, Todd Fischer wrote:

>  Hi Nicolas,
>
>
> On Fri, 2010-06-04 at 16:15 -0400, Nicolas Luna wrote:
>
> Hi,
>
>
>
>  I downloaded and tried the kernel v2.6.34 from *
> linux/kernel/git/khilman/linux-davinci.git**/ *to get the touchscreen
> patch. It is working well, but I wonder if it is normal that the touchscreen
> constantly use the I2C bus, even if I don't touch to the touchscreen.
>
> No, that is not normal.  The hardware I was using doesn't have the TPS6507x
> interrupt pin connected, so I couldn't test that code path (and thus didn't
> attempt to include it).  What hardware are you using?
>
>
>  Because of that, it is not possible to have an other device on the bus. Is
> there any specific reason why the driver do not use the INT pin from the
> TPS6507x to free a little bit the I2C bus.
>
>
> Also, I didn't think the driver was locking out all other access to the I2C
> bus.  I will enhance my test suite to check for that case.
>
> Todd
>
>  Thanks
>
>
>
>  Nicolas
>
>
>
>
>  ___
> Davinci-linux-open-source mailing 
> listdavinci-linux-open-sou...@linux.davincidsp.comhttp://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: Touchscreen - MFD driver for TPS6507x family

[Nicolas Luna]

Bastian,

Here's my .config file that works on my *OMAP-L138 EVM*. I used this kernel
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=commit;h=33bd223cd8f649be74975f9abc52c84f7a2ee8ab

Hope
this will help you to check if your hardware is ok.

Nicolas


On Tue, Jun 8, 2010 at 6:05 AM, Caglar Akyuz  wrote:

> On Tuesday 08 June 2010 12:24:34 pm Bastian Ruppert wrote:
> > Hello Caglar,
> >
>
> Hello,
>
> [...]
>
> >
> > I can communication in this situation with an i2c device on an attached
> >  custom hardware via i2ctools.
> > Without the custom hardware the error is still existing.
>
> So same kernel can communicate with another I2C but not with tps6507x...
>
> > Running another kernel (url =
> > git://arago-project.org/git/people/sekhar/linux-omapl1.git
> > on commit d1aeb54a603514d7757c0b88da57f23e498eeacc )
> > the touchscreen is working on the same hardware.
> >
>
> I couldn't find any references to those commit in linux-omapl1, maybe you
> have
> local changes in your tree?
>
> Anyway, by looking at the linux-omapl1 sources, I see that it uses
> bitbanging
> i2c driver not the DaVinci I2C driver. OTH linux-davinci, which I assume is
> other tree that you are trying, uses DaVinci I2C driver. This suggests that
> I2C hardware on your EVM is not working correctly.
>
> Best regards,
> Caglar
>
> > Any ideas are very welcome, thank you very much
> >
> > regards,
> >
> > Bastian.
> >
> ___
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>


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

Kernel v2.6.34 SPI & USB

[Nicolas Luna]

Hi everyone,

I'm running kernel v2.6.34 from *linux/kernel/git/khilman/linux-davinci.git*
*/.* I wonder why SPI is not anymore supported, everything about the driver
(files, code, etc) have been removed. Is there any patch to add it to the
mainline (2.6.34) ?

Also, I got linking error when I try to add USB support. I followed TI wiki
to configure my kernel (
http://processors.wiki.ti.com/index.php/GSG:_Building_Software_Components_for_OMAP-L1#USB_2.0
 )

LD  drivers/built-in.o
LD  vmlinux.o
MODPOST vmlinux.o
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC  init/version.o
LD  init/built-in.o
LD  .tmp_vmlinux1
drivers/built-in.o: In function `musb_stop':
i2c-davinci.c:(.text+0x79c00): undefined reference to
`musb_platform_disable'
drivers/built-in.o: In function `musb_shutdown':
i2c-davinci.c:(.text+0x79c80): undefined reference to
`musb_platform_disable'
drivers/built-in.o: In function `musb_mode_store':
i2c-davinci.c:(.text+0x79f70): undefined reference to
`musb_platform_set_mode'
drivers/built-in.o: In function `musb_start':
i2c-davinci.c:(.text+0x7a970): undefined reference to `musb_platform_enable'
drivers/built-in.o: In function `musb_probe':
i2c-davinci.c:(.init.text+0x48b8): undefined reference to
`musb_platform_init'
i2c-davinci.c:(.init.text+0x491c): undefined reference to
`musb_platform_disable'
i2c-davinci.c:(.init.text+0x50b4): undefined reference to
`musb_platform_exit'
make: *** [.tmp_vmlinux1] Error 1

I don't understand these errors because i2c-davinci.c doesn't do reference
to musb functions.

Thank you

Nicolas
___
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 v2.6.34 SPI & USB

[Nicolas Luna]

Sergei,

My plateform is OMAP-L138. Yes davinci_spi.c is still there but all the code
about spi in board-da850-evm.c, da850.c, devices-da850.c, da8xx.c have been
removed.

Is there any plan to support USB with this kernel on OMAP-L1xx plateform?

Regards,

Nicolas


On Tue, Jun 8, 2010 at 11:27 AM, Sergei Shtylyov wrote:

> Hello.
>
>
> Nicolas Luna wrote:
>
>  I'm running kernel v2.6.34 from
>> /linux/kernel/git/khilman/linux-davinci.git///./ I wonder why SPI is not
>> anymore supported, everything about the driver (files, code, etc) have been
>> removed. Is there any patch to add it to the mainline (2.6.34) ?
>>
>
>   Strange, I'm seeing drivers/spi/davinci_spi.c in 2.6.34...
>
>
>  Also, I got linking error when I try to add USB support. I followed TI
>> wiki to configure my kernel (
>> http://processors.wiki.ti.com/index.php/GSG:_Building_Software_Components_for_OMAP-L1#USB_2.0)
>>
>
>   If your platfrom is OMAP-L1x, its USB is not yet supported in 2.6.34.
>
>
>  LD  drivers/built-in.o
>> LD  vmlinux.o
>> MODPOST vmlinux.o
>> GEN .version
>> CHK include/generated/compile.h
>> UPD include/generated/compile.h
>> CC  init/version.o
>> LD  init/built-in.o
>> LD  .tmp_vmlinux1
>> drivers/built-in.o: In function `musb_stop':
>> i2c-davinci.c:(.text+0x79c00): undefined reference to
>> `musb_platform_disable'
>> drivers/built-in.o: In function `musb_shutdown':
>> i2c-davinci.c:(.text+0x79c80): undefined reference to
>> `musb_platform_disable'
>> drivers/built-in.o: In function `musb_mode_store':
>> i2c-davinci.c:(.text+0x79f70): undefined reference to
>> `musb_platform_set_mode'
>> drivers/built-in.o: In function `musb_start':
>> i2c-davinci.c:(.text+0x7a970): undefined reference to
>> `musb_platform_enable'
>> drivers/built-in.o: In function `musb_probe':
>> i2c-davinci.c:(.init.text+0x48b8): undefined reference to
>> `musb_platform_init'
>> i2c-davinci.c:(.init.text+0x491c): undefined reference to
>> `musb_platform_disable'
>> i2c-davinci.c:(.init.text+0x50b4): undefined reference to
>> `musb_platform_exit'
>> make: *** [.tmp_vmlinux1] Error 1
>>
>
>  I don't understand these errors because i2c-davinci.c doesn't do reference
>> to musb functions.
>>
>
>   For some reason, the source module displayed is incorrect, it should be
> musb_core.c instead.
>
>  Thank you
>>
>
>  Nicolas
>>
>
> 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: Touchscreen - MFD driver for TPS6507x family

[Nicolas Luna]

Bastian,

Glad to see that it worked. I also patched drivers/mfd/tps6507x.c otherwise
it's impossible to compile the kernel.

I have the same behaviour about i2c_davinci. I didn't investigate at the
moment to find the problem, maybe we could ask Todd if he encounter this
problem.

Nicolas


On Wed, Jun 9, 2010 at 4:59 AM, Bastian Ruppert  wrote:

>  Hello Nicolas,
>
> thanks for the .conf file.
>
> > this will help you to check if your hardware is ok.
>
> It helped.
>
> I applied your file on the khilman commit you are using but i had to patch
> the kernel in order to
> compile drivers/mfd/tps6507x.c . I think if you don`t have the same
> problems, that is anomalous.
>
> After that the touchscreen driver is running on that kernel. It`s a little
> bit unstable, there are sometimes errors like
>
> tps6507x 1-0048: TSC mode read failed
> i2c_davinci i2c_davinci.1: controller timed out
> i2c_davinci i2c_davinci.1: initiating i2c bus recovery
> i2c_davinci i2c_davinci.1: controller timed out
> i2c_davinci i2c_davinci.1: initiating i2c bus recovery
>
> but the hardware can in principle do it.
>
> Regards,
>
> Bastian.
>
___
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 3/3] davinci: spi: modify platform data for updated SPIdriver

[Nicolas Luna]

Hi,

I got OMAP-L138 EVM and I'm running kernel v2.6.34
from khilman/linux-davinci.git and I would like to try the SPI patch. I
successfully applied the patch to the driver, and now I'm trying to modify
platform data in board-da850-evm.c. I added the following lines :

#include 

[...]

static struct davinci_spi_config spidev_cfg = {
.parity_enable  = 0,
.intr_level = 0,
.io_type= SPI_IO_TYPE_DMA,
.wdelay = 0,
.timer_disable  = 1,
};

static struct spi_board_info da850_spi_board_info[] = {

[0] = {
.modalias = "spidev",
.controller_data = &spidev_cfg,
.mode = SPI_MODE_0,
.max_speed_hz = 1000,
.bus_num = 1,
.chip_select = 1,
},
};

[...]

static __init void da850_evm_init(void)
{
int ret;

[...]

ret = davinci_cfg_reg_list(da850_spi1_pins);
if (ret)
pr_warning("da850_evm_init: spi1 mux setup failed: %d\n", ret);

da850_init_spi1(NULL, 2, da850_spi_board_info,
ARRAY_SIZE(da850_spi_board_info));

[...]
}

I do not see spidev1.1 in /dev. Any clue?

Thank you.

Regards,

Nicolas



On Mon, Jun 14, 2010 at 3:13 PM, Brian Niebuhr wrote:

> > > diff --git a/arch/arm/mach-davinci/dm365.c
> > b/arch/arm/mach-davinci/dm365.c
> > > index a146849..0bd9f93 100644
> > > --- a/arch/arm/mach-davinci/dm365.c
> > > +++ b/arch/arm/mach-davinci/dm365.c
> > > @@ -625,12 +625,6 @@ static u64 dm365_spi0_dma_mask =
> > DMA_BIT_MASK(32);
> > >  static struct davinci_spi_platform_data dm365_spi0_pdata = {
> > > .version= SPI_VERSION_1,
> > > .num_chipselect = 2,
> > > -   .clk_internal   = 1,
> > > -   .cs_hold= 1,
> > > -   .intr_level = 0,
> > > -   .poll_mode  = 1,/* 0 -> interrupt mode 1->
> > polling mode */
> > > -   .c2tdelay   = 0,
> > > -   .t2cdelay   = 0,
> > >  };
> > >
> > >  static struct resource dm365_spi0_resources[] = {
> >
> > This patch does not contain modifications to resource
> > structure to 'or' the
> > IORESOURCE_DMA_RX_CHAN, IORESOURCE_DMA_TX_CHAN and
> > IORESOURCE_DMA_EVENT_Q
> > flags with IORESOURCE_DMA. I don't think without this
> > modification driver
> > will work.
>
> You are right - my mistake.  I will include that in the next version.  I
> assume you added these flags when you were testing?
>
> ___
> 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: [PATCH 3/3] davinci: spi: modify platform data for updated SPIdriver

[Nicolas Luna]

Brian,

I modified board-da850-evm.c with what you proposed and it's working very
well. I didn't test the spi flash (because I do not have one on my custum
hardware), but my 2 SPI CS (spidev1.1 and spidev1.2) are working.

Thanks for your time.

Nicolas


On Wed, Jun 16, 2010 at 11:57 AM, Brian Niebuhr wrote:

> > I got OMAP-L138 EVM and I'm running kernel v2.6.34 from
> > khilman/linux-davinci.git and I would like to try the SPI
> > patch. I successfully applied the patch to the driver, and
> > now I'm trying to modify platform data in board-da850-evm.c.
> > I added the following lines :
> >
> > [...]
> >
> > I do not see spidev1.1 in /dev. Any clue?
>
> Following is a diff of changes I made to the board configuration to add
> the M25P64 SPI flash to the DA850 EVM.  Note that this is NOT
> recommended as a patch - I just put in some quick and dirty code to
> reproduce Sudhakar's issue with the driver.  See diff below:
>
> diff --git a/arch/arm/mach-davinci/board-da850-evm.c
> b/arch/arm/mach-davinci/boa
> index 2ec3095..4ecae04 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -27,6 +27,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>
>  #include 
>  #include 
> @@ -35,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #define DA850_EVM_PHY_MASK 0x1
>  #define DA850_EVM_MDIO_FREQUENCY   220 /* PHY bus frequency */
> @@ -92,6 +95,59 @@ static struct platform_device
> da850_evm_norflash_device = {
>.resource   = da850_evm_norflash_resource,
>  };
>
> +static struct mtd_partition spi_flash_partitions[] = {
> +   [0] = {
> +   .name = "U-Boot",
> +   .offset = 0,
> +   .size = SZ_256K,
> +   .mask_flags = MTD_WRITEABLE,
> +   },
> +   [1] = {
> +   .name = "U-Boot Environment",
> +   .offset = MTDPART_OFS_APPEND,
> +   .size = SZ_64K,
> +   .mask_flags = MTD_WRITEABLE,
> +   },
> +   [2] = {
> +   .name = "Linux",
> +   .offset = MTDPART_OFS_NXTBLK,
> +   .size = SZ_8M - (SZ_256K + SZ_64K + SZ_64K),
> +   .mask_flags = 0,
> +   },
> +};
> +
> +struct davinci_spi_config m25p64_spi_cfg = {
> +   .odd_parity = 0,
> +   .parity_enable  = 0,
> +   .intr_level = 1,
> +   .io_type= SPI_IO_TYPE_DMA,
> +   .wdelay = 0,
> +   .timer_disable  = 1,
> +   .c2t_delay  = 0,
> +   .t2c_delay  = 0,
> +   .t2e_delay  = 0,
> +   .c2e_delay  = 0,
> +};
> +
> +static struct flash_platform_data spi_flash_data = {
> +   .name = "m25p80",
> +   .parts = spi_flash_partitions,
> +   .nr_parts = ARRAY_SIZE(spi_flash_partitions),
> +   .type = "m25p64",
> +};
> +
> +static struct spi_board_info da850_spi_board_info[] = {
> +   [0] = {
> +   .modalias = "m25p80",
> +   .platform_data = &spi_flash_data,
> +   .controller_data = &m25p64_spi_cfg,
> +   .mode = SPI_MODE_0,
> +   .max_speed_hz = 3000,
> +   .bus_num = 1,
> +   .chip_select = 0,
> +   },
> +};
> +
>  static struct davinci_pm_config da850_pm_pdata = {
>.sleepcount = 128,
>  };
> @@ -629,6 +685,61 @@ static int __init da850_evm_config_emac(void)
>  }
>  device_initcall(da850_evm_config_emac);
>
> +static struct davinci_spi_platform_data da850_spi_pdata1 = {
> +   .version = SPI_VERSION_2,
> +};
> +
> +static struct resource da850_spi_resources1[] = {
> +   [0] = {
> +   .start = 0x01F0E000,
> +   .end = 0x01F0E000 + 0xfff,
> +   .flags = IORESOURCE_MEM,
> +   },
> +   [1] = {
> +   .start = IRQ_DA8XX_SPINT1,
> +   .end = IRQ_DA8XX_SPINT1,
> +   .flags = IORESOURCE_IRQ,
> +   },
> +   [2] = {
> +   .start = EDMA_CTLR_CHAN(0, 18),
> +   .end = EDMA_CTLR_CHAN(0, 18),
> +   .flags = IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
> +   },
> +   [3] = {
> +   .start = EDMA_CTLR_CHAN(0, 19),
> +   .end = EDMA_CTLR_CHAN(0, 19),
> +   .flags = IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
> +   },
> +   [4] = {
> +   .start = 1,
> +   .end = 1,
> +   .flags = IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
> +   },
> +};
> +
> +static struct platform_device da850_spi_pdev1 = {
> +   .name = "spi_davinci",
> +   .id = 1,
> +   .resource = da850_spi_resources1,
> +   .num_resources = ARRAY_SIZE(da850_spi_resources1),
> +   .dev = {
> +   .platform_data = &da850_spi_pdata1,
> +   },
> +};
> +
> +static void __init da850_init_spi1(unsigned char* chip_sel,
> +   unsigned int num_sel, struct spi_board_info *info, unsigned
> num_dev)
> +{
> +   struct davinci_s

Re: [PATCH 3/3] davinci: spi: modify platform data for updated SPIdriver

[Nicolas Luna]

Brian,

I changed .io_type from SPI_IO_TYPE_DMA to SPI_IO_TYPE_INTR with
".intr_level = 1". My kernel it not freezing at startup and both devices
(CS1 and CS2) are still working fine. Anything else you would like to check?

Nicolas


On Wed, Jun 16, 2010 at 12:54 PM, Brian Niebuhr wrote:

> > I modified board-da850-evm.c with what you proposed and it's
> > working very well. I didn't test the spi flash (because I do
> > not have one on my custum hardware), but my 2 SPI CS
> > (spidev1.1 and spidev1.2) are working.
>
> Nicolas -
>
> Would you mind taking a few minutes and testing interrupt mode for the
> devices on your board?  I'm trying to reproduce the issue that Sudhakar
> was seeing, and I would appreciate additional testing if you've got the
> time.
>
> Thanks,
>
> Brian
>
>
___
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 v2.6.34 SPI & USB

[Nicolas Luna]

Hello,

Is there anyone else that tried to modify platform data (board-da850-evm.c)
to add USB1.1 and USB2.0 support for OMAP-L138?

Thanks

Nicolas



On Wed, Jun 9, 2010 at 8:58 AM, Nori, Sekhar  wrote:

> Hi Nicolas,
>
> On Tue, Jun 08, 2010 at 21:22:55, Nicolas Luna wrote:
> > Sergei,
> >
> > My plateform is OMAP-L138. Yes davinci_spi.c is still there but all the
> > code about spi in board-da850-evm.c, da850.c, devices-da850.c, da8xx.c
> > have been removed.
>
> I don't think the SPI support was removed at any time. The board
> specific hook-up for OMAP-L138 was never submitted upstream. The SPI
> driver as such was accepted upstream only recently (and is currently
> undergoing an overhaul by Brian Niebuhr).
>
> 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

GPIO in userspace

[Nicolas Luna]

Hi,

I wonder what would be the easiest way to control GPIO in userspace. I read
the documentation gpio.txt but I'm not sure what I should use (Control
interfaces?, GPIO controllers?) and how to implement it.

Is there more explication about *int gpio_export_link(struct device *dev,
const char *name, unsigned gpio) *because I think it could be the key.

Will I need to write my own module and communicate with it?.

Thank you.

Regards,

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

Re: GPIO in userspace

[Nicolas Luna]

Hi,

With the code below in da850-board-evm.c, I can turn on my LED connected to
the gpio.

#define DA850_LED0_GPIO GPIO_TO_PIN(8, 14)

status = gpio_request(DA850_LED0_GPIO, "led0gpio");
if (status < 0) {
return status;
}
gpio_direction_output(DA850_LED0_GPIO, 0);
gpio_set_value(DA850_LED0_GPIO, 0);

If I comment this code in the kernel initialization and I try what you
proposed, I do not get the same result. (142 comes from 16*8+14)

# echo 142 > /sys/class/gpio/export

# ls /sys/class/gpio
export  gpio142  gpiochip128  gpiochip64  unexport  gpiochip0  gpiochip32
 gpiochip96

# cat /sys/class/gpio/gpio142/value
1

# echo 1 > /sys/class/gpio/gpio142/direction
# echo 0 > /sys/class/gpio/gpio142/value
# cat /sys/class/gpio/gpio142/value
1

The output is always to 1, in fact the gpio is not in output, it is still in
tri-state. CONFIG_GPIO_SYSFS is enabled.

Do you have any idea?

Thanks.

Regards,

Nicolas



On Wed, Jun 30, 2010 at 3:28 AM, Christophe Aeschlimann <
c.aeschlim...@acn-group.ch> wrote:

> Hi,
>
>
> On 30.06.2010 04:09, Jon Povey wrote:
>
>> Nicolas Luna wrote:
>>
>>> Hi,
>>>
>>> I wonder what would be the easiest way to control GPIO in userspace.
>>> I read the documentation gpio.txt but I'm not sure what I should use
>>> (Control interfaces?, GPIO controllers?) and how to implement it.
>>>
>>> Is there more explication about int gpio_export_link(struct device
>>> *dev, const char *name, unsigned gpio) because I think it could be
>>> the key.
>>>
>>> Will I need to write my own module and communicate with it?.
>>>
>>
>> You don't need to write a module. You can access GPIOs from a shell
>> script:
>>
>
> To be able to do so you must configure your kernel with the following
> option enabled :
>
> CONFIG_GPIO_SYSFS
>
>
>  echo $GPIO_NUMBER>  /sys/class/gpio/export
>>
>> creates a directory /sys/class/gpio/gpio$GPIO_NUMBER, e.g. 8.
>> (That will fail if something else like a driver has requested that gpio
>> already).
>>
>> cat /sys/class/gpio/gpio8/value
>>
>> gets the value 0/1
>>
>> echo 1>  /sys/class/gpio/gpio8/direction
>>
>> sets it to output (iirc)
>>
>> echo 1>  /sys/class/gpio/gpio8/value
>>
>> now sets the output value.
>>
>> echo 8>  /sys/class/gpio/unexport
>>
>> to release it when you are finished.
>>
>> gpio_export_link() is for when you claim a gpio for use in the kernel but
>> also want to export one of the above kind of sysfs entries.
>>
>> --
>> 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
>>
>>
>>
> Regards,
>
>
> --
> Christophe Aeschlimann
>
> Embedded Software Engineer
>
> 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: GPIO in userspace

[Nicolas Luna]

I changed it:

MUX_CFG(DA850, GPIO_LED0, 18, 12, 15, 8, false)

--
Nicolas Luna



On Wed, Jun 30, 2010 at 1:29 PM, Caglar Akyuz  wrote:

> On Wednesday 30 June 2010 08:06:38 pm Nicolas Luna wrote:
> > Hi,
> >
> > With the code below in da850-board-evm.c, I can turn on my LED connected
> to
> > the gpio.
> >
> > #define DA850_LED0_GPIO GPIO_TO_PIN(8, 14)
> >
> > status = gpio_request(DA850_LED0_GPIO, "led0gpio");
> > if (status < 0) {
> > return status;
> > }
> > gpio_direction_output(DA850_LED0_GPIO, 0);
> > gpio_set_value(DA850_LED0_GPIO, 0);
> >
> > If I comment this code in the kernel initialization and I try what you
> > proposed, I do not get the same result. (142 comes from 16*8+14)
> >
> > # echo 142 > /sys/class/gpio/export
> >
> > # ls /sys/class/gpio
> > export  gpio142  gpiochip128  gpiochip64  unexport  gpiochip0  gpiochip32
> >  gpiochip96
> >
> > # cat /sys/class/gpio/gpio142/value
> > 1
> >
> > # echo 1 > /sys/class/gpio/gpio142/direction
> > # echo 0 > /sys/class/gpio/gpio142/value
> > # cat /sys/class/gpio/gpio142/value
> > 1
> >
> > The output is always to 1, in fact the gpio is not in output, it is still
> >  in tri-state. CONFIG_GPIO_SYSFS is enabled.
> >
> > Do you have any idea?
> >
>
> Maybe you have a pinmux specific configuration in your board file as well?
>
> Regards,
> Caglar
>
> > Thanks.
> >
> > Regards,
> >
> > Nicolas
> >
> >
> >
> > On Wed, Jun 30, 2010 at 3:28 AM, Christophe Aeschlimann <
> >
> > c.aeschlim...@acn-group.ch> wrote:
> > > Hi,
> > >
> > > On 30.06.2010 04:09, Jon Povey wrote:
> > >> Nicolas Luna wrote:
> > >>> Hi,
> > >>>
> > >>> I wonder what would be the easiest way to control GPIO in userspace.
> > >>> I read the documentation gpio.txt but I'm not sure what I should use
> > >>> (Control interfaces?, GPIO controllers?) and how to implement it.
> > >>>
> > >>> Is there more explication about int gpio_export_link(struct device
> > >>> *dev, const char *name, unsigned gpio) because I think it could be
> > >>> the key.
> > >>>
> > >>> Will I need to write my own module and communicate with it?.
> > >>
> > >> You don't need to write a module. You can access GPIOs from a shell
> > >> script:
> > >
> > > To be able to do so you must configure your kernel with the following
> > > option enabled :
> > >
> > > CONFIG_GPIO_SYSFS
> > >
> > >
> > >  echo $GPIO_NUMBER>  /sys/class/gpio/export
> > >
> > >> creates a directory /sys/class/gpio/gpio$GPIO_NUMBER, e.g. 8.
> > >> (That will fail if something else like a driver has requested that
> gpio
> > >> already).
> > >>
> > >> cat /sys/class/gpio/gpio8/value
> > >>
> > >> gets the value 0/1
> > >>
> > >> echo 1>  /sys/class/gpio/gpio8/direction
> > >>
> > >> sets it to output (iirc)
> > >>
> > >> echo 1>  /sys/class/gpio/gpio8/value
> > >>
> > >> now sets the output value.
> > >>
> > >> echo 8>  /sys/class/gpio/unexport
> > >>
> > >> to release it when you are finished.
> > >>
> > >> gpio_export_link() is for when you claim a gpio for use in the kernel
> > >> but also want to export one of the above kind of sysfs entries.
> > >>
> > >> --
> > >> 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
> > >
> > > Regards,
> > >
> > >
> > > --
> > > Christophe Aeschlimann
> > >
> > > Embedded Software Engineer
> > >
> > > 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: GPIO in userspace

[Nicolas Luna]

Ok so finally I found it.. I changed

echo 1 > /sys/class/gpio/gpio142/direction

to

echo "high" > /sys/class/gpio/gpio142/direction

I think it is also possible to use "out".

Thank you guys,

Regards,

Nicolas



On Wed, Jun 30, 2010 at 1:43 PM, Nicolas Luna  wrote:

> I changed it:
>
> MUX_CFG(DA850, GPIO_LED0, 18, 12, 15, 8, false)
>
> --
> Nicolas Luna
>
>
>
>
> On Wed, Jun 30, 2010 at 1:29 PM, Caglar Akyuz wrote:
>
>> On Wednesday 30 June 2010 08:06:38 pm Nicolas Luna wrote:
>> > Hi,
>> >
>> > With the code below in da850-board-evm.c, I can turn on my LED connected
>> to
>> > the gpio.
>> >
>> > #define DA850_LED0_GPIO GPIO_TO_PIN(8, 14)
>> >
>> > status = gpio_request(DA850_LED0_GPIO, "led0gpio");
>> > if (status < 0) {
>> > return status;
>> > }
>> > gpio_direction_output(DA850_LED0_GPIO, 0);
>> > gpio_set_value(DA850_LED0_GPIO, 0);
>> >
>> > If I comment this code in the kernel initialization and I try what you
>> > proposed, I do not get the same result. (142 comes from 16*8+14)
>> >
>> > # echo 142 > /sys/class/gpio/export
>> >
>> > # ls /sys/class/gpio
>> > export  gpio142  gpiochip128  gpiochip64  unexport  gpiochip0
>>  gpiochip32
>> >  gpiochip96
>> >
>> > # cat /sys/class/gpio/gpio142/value
>> > 1
>> >
>> > # echo 1 > /sys/class/gpio/gpio142/direction
>> > # echo 0 > /sys/class/gpio/gpio142/value
>> > # cat /sys/class/gpio/gpio142/value
>> > 1
>> >
>> > The output is always to 1, in fact the gpio is not in output, it is
>> still
>> >  in tri-state. CONFIG_GPIO_SYSFS is enabled.
>> >
>> > Do you have any idea?
>> >
>>
>> Maybe you have a pinmux specific configuration in your board file as well?
>>
>> Regards,
>> Caglar
>>
>> > Thanks.
>> >
>> > Regards,
>> >
>> > Nicolas
>> >
>> >
>> >
>> > On Wed, Jun 30, 2010 at 3:28 AM, Christophe Aeschlimann <
>> >
>> > c.aeschlim...@acn-group.ch> wrote:
>> > > Hi,
>> > >
>> > > On 30.06.2010 04:09, Jon Povey wrote:
>> > >> Nicolas Luna wrote:
>> > >>> Hi,
>> > >>>
>> > >>> I wonder what would be the easiest way to control GPIO in userspace.
>> > >>> I read the documentation gpio.txt but I'm not sure what I should use
>> > >>> (Control interfaces?, GPIO controllers?) and how to implement it.
>> > >>>
>> > >>> Is there more explication about int gpio_export_link(struct device
>> > >>> *dev, const char *name, unsigned gpio) because I think it could be
>> > >>> the key.
>> > >>>
>> > >>> Will I need to write my own module and communicate with it?.
>> > >>
>> > >> You don't need to write a module. You can access GPIOs from a shell
>> > >> script:
>> > >
>> > > To be able to do so you must configure your kernel with the following
>> > > option enabled :
>> > >
>> > > CONFIG_GPIO_SYSFS
>> > >
>> > >
>> > >  echo $GPIO_NUMBER>  /sys/class/gpio/export
>> > >
>> > >> creates a directory /sys/class/gpio/gpio$GPIO_NUMBER, e.g. 8.
>> > >> (That will fail if something else like a driver has requested that
>> gpio
>> > >> already).
>> > >>
>> > >> cat /sys/class/gpio/gpio8/value
>> > >>
>> > >> gets the value 0/1
>> > >>
>> > >> echo 1>  /sys/class/gpio/gpio8/direction
>> > >>
>> > >> sets it to output (iirc)
>> > >>
>> > >> echo 1>  /sys/class/gpio/gpio8/value
>> > >>
>> > >> now sets the output value.
>> > >>
>> > >> echo 8>  /sys/class/gpio/unexport
>> > >>
>> > >> to release it when you are finished.
>> > >>
>> > >> gpio_export_link() is for when you claim a gpio for use in the kernel
>> > >> but also want to export one of the above kind of sysfs entries.
>> > >>
>> > >> --
>> > >> Jon Povey
>> > >> jon.po...@racelogic.co.uk
>> > >>
>> 

Re: YAFFS2 not in git????

[Nicolas Luna]

Patch it : http://www.yaffs.net/

Regards,

Nicolas


On Mon, Jul 12, 2010 at 2:30 AM, rohan tabish wrote:

> How to use yaffs with git kernel there is no support for it?
>
>
> Regard's
> Rohan Tabish
>
>
> ___
> 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

Boot time

[Nicolas Luna]

Hi guys,

I'm trying to make by board boot as quick as possible. I did some
optimisation with the "All This For 1 Second Boot" wiki and other website. I
would like to reduce a little bit more the boot time and I wonder if you
guys could give me some clues.

I copied my boot log below. For sure I'll remove the uboot autoboot delay
and probably build a new kernel with modules. I putted in bold part that I
think it is possible to do more optimisation.

1- See bullet #3.
2- The verifying Checksum is about 400 msec is it possible to skip it?
3- It takes ~1 sec to start booting the kernel and there is a other ~1 sec
delay between the starting kernel and the beginning of the uncompressing.
Why it's so long? Ok maybe there is the copy from NOR to RAM but it should
not take more than few msec.
4- It takes ~1 sec to the kernel to free 120K memory... I got enought RAM is
it possible to remove it?

I got custom hardware based on OMAP-L138 with FS (jffs2) and compressed
kernel in NOR Flash.

Thanks a lot

Nicolas

-

0.000 0.000: OMAP-L138 initialization passed!
0.000 0.000: Booting TI User Boot Loader
0.004 0.004:UBL Version: 1.65
0.004 0.000:UBL Flashtype: NOR
0.008 0.004: Starting NOR Copy...
0.008 0.000: CFI Query...passed.
0.012 0.004: NOR Initialization:
0.012 0.000:Command Set: Intel
0.012 0.000:Manufacturer: INTEL
0.016 0.004:Size: 0x0020 MB
0.020 0.004: Valid magicnum, 0x55424CBB, found..
0.184 0.164:DONE
0.188 0.004: Jumping to entry point at 0xC108.
0.504 0.316:
1.548 1.044: Hit any key to stop autoboot:  0
*2.372 0.824: ## Booting kernel from Legacy Image at c0007fc0 ...*
2.372 0.000:Image Name:   Linux-2.6.34
2.380 0.008:Image Type:   ARM Linux Kernel Image (uncompressed)
2.380 0.000:Data Size:1505956 Bytes =  1.4 MB
2.384 0.004:Load Address: c0008000
2.388 0.004:Entry Point:  c0008000
*2.808 0.420:Verifying Checksum ... OK*
2.808 0.000:Loading Kernel Image ... OK
2.808 0.000: OK
2.808 0.000:
*2.812 0.004: Starting kernel ...*
*2.812 0.000:*
*3.860 1.048: Uncompressing Linux... done, booting the kernel.*
4.264 0.404: Linux version 2.6.34 (i...@idt-ubuntu-linux) (gcc version 4.3.3
(Sourcery G++ Lite 2009q1-203) ) #89 PREEMPT Thu Jul 22 15:24:03 EDT 2010
4.268 0.004: CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
4.272 0.004: CPU: VIVT data cache, VIVT instruction cache
4.276 0.004: Machine: DaVinci DA850/OMAP-L138 EVM
4.280 0.004: Memory policy: ECC disabled, Data cache writeback
4.284 0.004: DaVinci da850/omap-l138 variant 0x0
4.288 0.004: Built 1 zonelists in Zone order, mobility grouping on.  Total
pages: 32512
4.300 0.012: Kernel command line: lpj=747520 mem=128M console=ttyS2,115200n8
root=/dev/mtdblock2 rootfstype=jffs2 rw ip=off
4.304 0.004: PID hash table entries: 512 (order: -1, 2048 bytes)
4.308 0.004: Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
4.316 0.008: Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
4.316 0.000: Memory: 128MB = 128MB total
4.324 0.008: Memory: 126752k/126752k available, 4320k reserved, 0K highmem
4.324 0.000: Virtual kernel memory layout:
4.332 0.008: vector  : 0x - 0x1000   (   4 kB)
4.336 0.004: fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
4.340 0.004: DMA : 0xff00 - 0xffe0   (  14 MB)
4.344 0.004: vmalloc : 0xc880 - 0xfea0   ( 866 MB)
4.348 0.004: lowmem  : 0xc000 - 0xc800   ( 128 MB)
4.352 0.004: modules : 0xbf00 - 0xc000   (  16 MB)
4.356 0.004:   .init : 0xc0008000 - 0xc0026000   ( 120 kB)
4.360 0.004:   .text : 0xc0026000 - 0xc02e8000   (2824 kB)
4.364 0.004:   .data : 0xc02e8000 - 0xc0307a60   ( 127 kB)
4.372 0.008: SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1,
Nodes=1
4.376 0.004: Hierarchical RCU implementation.
4.376 0.000: NR_IRQS:245
4.380 0.004: Console: colour dummy device 80x30
4.384 0.004: Calibrating delay loop (skipped) preset value.. 149.50 BogoMIPS
(lpj=747520)
4.388 0.004: Mount-cache hash table entries: 512
4.392 0.004: CPU: Testing write buffer coherency: ok
4.396 0.004: DaVinci: 144 gpio irqs
4.396 0.000: NET: Registered protocol family 16
4.400 0.004: bio: create slab  at 0
4.404 0.004: SCSI subsystem initialized
4.408 0.004: usbcore: registered new interface driver usbfs
4.412 0.004: usbcore: registered new interface driver hub
4.416 0.004: usbcore: registered new device driver usb
4.416 0.000: Switching to clocksource timer0_1
4.420 0.004: musb_hdrc: version 6.0, pio, host, debug=0
4.424 0.004: Waiting for USB PHY clock good...
4.428 0.004: musb_hdrc musb_hdrc: MUSB HDRC host driver
4.432 0.004: musb_hdrc musb_hdrc: new USB bus registered, assigned bus
number 1
4.436 0.004: hub 1-0:1.0: USB hub found
4.440 0.004: hub 1-0:1.0: 1 port detected
4.444 0.004: musb_hdrc musb_hdrc: USB Host mode controller at fee0 using
PIO, IRQ 58
4.448 0.004: NET: Register

Re: Touchscreen - MFD driver for TPS6507x family

[Nicolas Luna]

Todd,

What do I need to change if I want to use the bitbang i2c driver and stop to
get those error messages.

I added support for "GPIO-based bitbaging I2C" into the kernel, anything
else to change in the TPS driver source code?

Thanks

Regards,

Nicolas



On Wed, Jun 9, 2010 at 4:17 PM, Todd Fischer wrote:

>  HI Bastian and Nicolas,
>
> I recall getting this error when I wasn't using the bitbang i2c driver on
> the OMAP-L138.
>
> Todd
>
>
> On Wed, 2010-06-09 at 10:59 +0200, Bastian Ruppert wrote:
>
> Hello Nicolas,
>
> thanks for the .conf file.
>
> > this will help you to check if your hardware is ok.
>
> It helped.
>
> I applied your file on the khilman commit you are using but i had to patch
> the kernel in order to
> compile drivers/mfd/tps6507x.c . I think if you don`t have the same
> problems, that is anomalous.
>
> After that the touchscreen driver is running on that kernel. It`s a little
> bit unstable, there are sometimes errors like
>
> tps6507x 1-0048: TSC mode read failed
> i2c_davinci i2c_davinci.1: controller timed out
> i2c_davinci i2c_davinci.1: initiating i2c bus recovery
> i2c_davinci i2c_davinci.1: controller timed out
> i2c_davinci i2c_davinci.1: initiating i2c bus recovery
>
> but the hardware can in principle do it.
>
> Regards,
>
> Bastian.
>
> ___
> Davinci-linux-open-source mailing list
> davinci-linux-open-sou...@linux.davincidsp.comhttp://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: Touchscreen - MFD driver for TPS6507x family

[Nicolas Luna]

board-da850-evm.c

Nicolas



On Wed, Jul 28, 2010 at 4:51 PM, Todd Fischer wrote:

>  On Wed, 2010-07-28 at 16:46 -0400, Nicolas Luna wrote:
>
> Todd,
>
>
>
>  What do I need to change if I want to use the bitbang i2c driver and stop
> to get those error messages.
>
>
>
>  I added support for "GPIO-based bitbaging I2C" into the kernel, anything
> else to change in the TPS driver source code?
>
>
> You need to modify the arm/arch/mach-davinci board file to configure the
> pinmux as GPIOs, not I2C signaling.
>
> Which hardware board are you using?
>
>
>
>
>  Thanks
>
>
>
>  Regards,
>
>
>
>  Nicolas
>
>
>
>  On Wed, Jun 9, 2010 at 4:17 PM, Todd Fischer 
> wrote:
>
>  HI Bastian and Nicolas,
>
> I recall getting this error when I wasn't using the bitbang i2c driver on
> the OMAP-L138.
>
> Todd
>
>
>
>
> On Wed, 2010-06-09 at 10:59 +0200, Bastian Ruppert wrote:
>
>
>Hello Nicolas,
>
> thanks for the .conf file.
>
> > this will help you to check if your hardware is ok.
>
> It helped.
>
> I applied your file on the khilman commit you are using but i had to patch
> the kernel in order to
> compile drivers/mfd/tps6507x.c . I think if you don`t have the same
> problems, that is anomalous.
>
> After that the touchscreen driver is running on that kernel. It`s a little
> bit unstable, there are sometimes errors like
>
> tps6507x 1-0048: TSC mode read failed
> i2c_davinci i2c_davinci.1: controller timed out
> i2c_davinci i2c_davinci.1: initiating i2c bus recovery
> i2c_davinci i2c_davinci.1: controller timed out
> i2c_davinci i2c_davinci.1: initiating i2c bus recovery
>
> but the hardware can in principle do it.
>
> Regards,
>
> Bastian.
>
>___
> 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: Touchscreen - MFD driver for TPS6507x family

[Nicolas Luna]

I changed

MUX_CFG(DA850, I2C0_SDA, 4, 12, 15, 2, false)
MUX_CFG(DA850, I2C0_SCL, 4, 8, 15, 2, false)

to

MUX_CFG(DA850, I2C0_SDA, 4, 12, 15, 8, false)
MUX_CFG(DA850, I2C0_SCL, 4, 8, 15, 8, false)

seems to have the same behaviour..

Nicolas



On Wed, Jul 28, 2010 at 5:08 PM, Nicolas Luna  wrote:

> board-da850-evm.c
>
> Nicolas
>
>
>
>
> On Wed, Jul 28, 2010 at 4:51 PM, Todd Fischer 
> wrote:
>
>>  On Wed, 2010-07-28 at 16:46 -0400, Nicolas Luna wrote:
>>
>> Todd,
>>
>>
>>
>>  What do I need to change if I want to use the bitbang i2c driver and
>> stop to get those error messages.
>>
>>
>>
>>  I added support for "GPIO-based bitbaging I2C" into the kernel, anything
>> else to change in the TPS driver source code?
>>
>>
>> You need to modify the arm/arch/mach-davinci board file to configure the
>> pinmux as GPIOs, not I2C signaling.
>>
>> Which hardware board are you using?
>>
>>
>>
>>
>>  Thanks
>>
>>
>>
>>  Regards,
>>
>>
>>
>>  Nicolas
>>
>>
>>
>>  On Wed, Jun 9, 2010 at 4:17 PM, Todd Fischer 
>> wrote:
>>
>>  HI Bastian and Nicolas,
>>
>> I recall getting this error when I wasn't using the bitbang i2c driver on
>> the OMAP-L138.
>>
>> Todd
>>
>>
>>
>>
>> On Wed, 2010-06-09 at 10:59 +0200, Bastian Ruppert wrote:
>>
>>
>>Hello Nicolas,
>>
>> thanks for the .conf file.
>>
>> > this will help you to check if your hardware is ok.
>>
>> It helped.
>>
>> I applied your file on the khilman commit you are using but i had to patch
>> the kernel in order to
>> compile drivers/mfd/tps6507x.c . I think if you don`t have the same
>> problems, that is anomalous.
>>
>> After that the touchscreen driver is running on that kernel. It`s a little
>> bit unstable, there are sometimes errors like
>>
>> tps6507x 1-0048: TSC mode read failed
>> i2c_davinci i2c_davinci.1: controller timed out
>> i2c_davinci i2c_davinci.1: initiating i2c bus recovery
>> i2c_davinci i2c_davinci.1: controller timed out
>> i2c_davinci i2c_davinci.1: initiating i2c bus recovery
>>
>> but the hardware can in principle do it.
>>
>> Regards,
>>
>> Bastian.
>>
>>___
>> 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: Touchscreen - MFD driver for TPS6507x family

[Nicolas Luna]

Oh I did'nt loaded the right kernel, my fault...

Well now it's not working at all, I got this error "
*QWSTslibMouseHandlerPrivate:
ts_open() failed with error: 'No such file or directory' " *and no more
/dev/input/touchscreen0 detected by udev.

Any clues?

Regards,

Nicolas


On Wed, Jul 28, 2010 at 5:18 PM, Nicolas Luna  wrote:

> I changed
>
> MUX_CFG(DA850, I2C0_SDA, 4, 12, 15, 2, false)
>  MUX_CFG(DA850, I2C0_SCL, 4, 8, 15, 2, false)
>
> to
>
> MUX_CFG(DA850, I2C0_SDA, 4, 12, 15, 8, false)
>  MUX_CFG(DA850, I2C0_SCL, 4, 8, 15, 8, false)
>
> seems to have the same behaviour..
>
> Nicolas
>
>
>
>
> On Wed, Jul 28, 2010 at 5:08 PM, Nicolas Luna  wrote:
>
>> board-da850-evm.c
>>
>> Nicolas
>>
>>
>>
>>
>> On Wed, Jul 28, 2010 at 4:51 PM, Todd Fischer 
>> wrote:
>>
>>>  On Wed, 2010-07-28 at 16:46 -0400, Nicolas Luna wrote:
>>>
>>> Todd,
>>>
>>>
>>>
>>>  What do I need to change if I want to use the bitbang i2c driver and
>>> stop to get those error messages.
>>>
>>>
>>>
>>>  I added support for "GPIO-based bitbaging I2C" into the kernel,
>>> anything else to change in the TPS driver source code?
>>>
>>>
>>> You need to modify the arm/arch/mach-davinci board file to configure the
>>> pinmux as GPIOs, not I2C signaling.
>>>
>>> Which hardware board are you using?
>>>
>>>
>>>
>>>
>>>  Thanks
>>>
>>>
>>>
>>>  Regards,
>>>
>>>
>>>
>>>  Nicolas
>>>
>>>
>>>
>>>  On Wed, Jun 9, 2010 at 4:17 PM, Todd Fischer 
>>> wrote:
>>>
>>>  HI Bastian and Nicolas,
>>>
>>> I recall getting this error when I wasn't using the bitbang i2c driver on
>>> the OMAP-L138.
>>>
>>> Todd
>>>
>>>
>>>
>>>
>>> On Wed, 2010-06-09 at 10:59 +0200, Bastian Ruppert wrote:
>>>
>>>
>>>Hello Nicolas,
>>>
>>> thanks for the .conf file.
>>>
>>> > this will help you to check if your hardware is ok.
>>>
>>> It helped.
>>>
>>> I applied your file on the khilman commit you are using but i had to
>>> patch the kernel in order to
>>> compile drivers/mfd/tps6507x.c . I think if you don`t have the same
>>> problems, that is anomalous.
>>>
>>> After that the touchscreen driver is running on that kernel. It`s a
>>> little bit unstable, there are sometimes errors like
>>>
>>> tps6507x 1-0048: TSC mode read failed
>>> i2c_davinci i2c_davinci.1: controller timed out
>>> i2c_davinci i2c_davinci.1: initiating i2c bus recovery
>>> i2c_davinci i2c_davinci.1: controller timed out
>>> i2c_davinci i2c_davinci.1: initiating i2c bus recovery
>>>
>>> but the hardware can in principle do it.
>>>
>>> Regards,
>>>
>>> Bastian.
>>>
>>>___
>>> 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: Touchscreen - MFD driver for TPS6507x family

[Nicolas Luna]

Sekhar,

Thank you for the advice. I would like to know if you are aware of the
modification that will be made by Logic. I suppose that if Logic is in the
loop it means that the problem is hardware?

I have custom hardware based on OMAPL138 EVM. We are releasing the REV2 very
soon, so maybe I could change it.

Thanks.

Regards,

Nicolas


On Thu, Jul 29, 2010 at 1:12 AM, Nori, Sekhar  wrote:

> Hi Nicolas,
>
> On Thu, Jul 29, 2010 at 02:16:16, Nicolas Luna wrote:
> > Todd,
> >
> > What do I need to change if I want to use the bitbang i2c driver and
> > stop to get those error messages.
>
> You can try the patch here:
> http://arago-project.org/git/projects/?p=linux-omapl1.git;a=commit;h=7d8accda275fdbe6e727e7ac02ae5a92f5695326
>
> This issue should be fixed in future revisions of Logic EVMs so this patch
> wont be needed afterward.
>
> 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: Touchscreen - MFD driver for TPS6507x family

[Nicolas Luna]

Todd,

Yes the polling is not such a problem because 2% is not that much. Probably
that the bitbang will be more than that it's why I would like to avoid it.
If there is a hardware mod to correct NACK problem I'll be glad to apply it.

Thanks,

Nicolas




On Thu, Jul 29, 2010 at 7:43 AM, Todd Fischer wrote:

>  Nicolas,
>
> Also, due to another hardware limitation, the touch screen driver using
> polling instead of interrupts.  I heard a hardware change that will allow
> for interrupts to be used is planned as well.  The polling overhead costs
> around 2% ARM CPU.
>
> Todd
>
>
> On Thu, 2010-07-29 at 10:42 +0530, Nori, Sekhar wrote:
>
> Hi Nicolas,
>
> On Thu, Jul 29, 2010 at 02:16:16, Nicolas Luna wrote:
> > Todd,
> >
> > What do I need to change if I want to use the bitbang i2c driver and
> > stop to get those error messages.
>
> You can try the patch here: 
> http://arago-project.org/git/projects/?p=linux-omapl1.git;a=commit;h=7d8accda275fdbe6e727e7ac02ae5a92f5695326
>
> This issue should be fixed in future revisions of Logic EVMs so this patch
> wont be needed afterward.
>
> 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: Touchscreen - MFD driver for TPS6507x family

[Nicolas Luna]

Todd,

Is it possible that the problem occurs because the driver is using polling
and it polls the PMIC to fast and it cannot handles all commands received so
it returns NACK?

Thanks

Nicolas


On Thu, Jul 29, 2010 at 8:24 AM, Nicolas Luna  wrote:

> Todd,
>
> Yes the polling is not such a problem because 2% is not that much. Probably
> that the bitbang will be more than that it's why I would like to avoid it.
> If there is a hardware mod to correct NACK problem I'll be glad to apply it.
>
> Thanks,
>
> Nicolas
>
>
>
>
>
> On Thu, Jul 29, 2010 at 7:43 AM, Todd Fischer 
> wrote:
>
>>  Nicolas,
>>
>> Also, due to another hardware limitation, the touch screen driver using
>> polling instead of interrupts.  I heard a hardware change that will allow
>> for interrupts to be used is planned as well.  The polling overhead costs
>> around 2% ARM CPU.
>>
>> Todd
>>
>>
>> On Thu, 2010-07-29 at 10:42 +0530, Nori, Sekhar wrote:
>>
>> Hi Nicolas,
>>
>> On Thu, Jul 29, 2010 at 02:16:16, Nicolas Luna wrote:
>> > Todd,
>> >
>> > What do I need to change if I want to use the bitbang i2c driver and
>> > stop to get those error messages.
>>
>> You can try the patch here: 
>> http://arago-project.org/git/projects/?p=linux-omapl1.git;a=commit;h=7d8accda275fdbe6e727e7ac02ae5a92f5695326
>>
>> This issue should be fixed in future revisions of Logic EVMs so this patch
>> wont be needed afterward.
>>
>> 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: Touchscreen - MFD driver for TPS6507x family

[Nicolas Luna]

Ok it's good to know.

Do you know if the problem is solved in AM1808 I2C silicon module?

Thanks

Nicolas


On Thu, Jul 29, 2010 at 11:19 AM, Todd Fischer wrote:

>  Nicolas,
>
> The polling TPS6507x touchscreen driver works without error (just uses 2%
> of the CPU).  It is the hw design when using the I2C silicon module in the
> L138 that has the problem.
>
> Todd
>
>
> On Thu, 2010-07-29 at 09:18 -0400, Nicolas Luna wrote:
>
> Todd,
>
>
>
>  Is it possible that the problem occurs because the driver is using
> polling and it polls the PMIC to fast and it cannot handles all commands
> received so it returns NACK?
>
>
>
>  Thanks
>
>
>
>  Nicolas
>
>
>  On Thu, Jul 29, 2010 at 8:24 AM, Nicolas Luna  wrote:
>
> Todd,
>
>
>
>   Yes the polling is not such a problem because 2% is not that much.
> Probably that the bitbang will be more than that it's why I would like to
> avoid it. If there is a hardware mod to correct NACK problem I'll be glad to
> apply it.
>
>
>
>   Thanks,
>
>
>
>   Nicolas
>
>
>
>
>
>
>
>   On Thu, Jul 29, 2010 at 7:43 AM, Todd Fischer 
> wrote:
>
>   Nicolas,
>
> Also, due to another hardware limitation, the touch screen driver using
> polling instead of interrupts.  I heard a hardware change that will allow
> for interrupts to be used is planned as well.  The polling overhead costs
> around 2% ARM CPU.
>
> Todd
>
>
>
>
> On Thu, 2010-07-29 at 10:42 +0530, Nori, Sekhar wrote:
>
> Hi Nicolas,
>
> On Thu, Jul 29, 2010 at 02:16:16, Nicolas Luna wrote:
> > Todd,
> >
> > What do I need to change if I want to use the bitbang i2c driver and
> > stop to get those error messages.
>
> You can try the patch here: 
> http://arago-project.org/git/projects/?p=linux-omapl1.git;a=commit;h=7d8accda275fdbe6e727e7ac02ae5a92f5695326
>
> This issue should be fixed in future revisions of Logic EVMs so this patch
> wont be needed afterward.
>
> 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: Touchscreen - MFD driver for TPS6507x family

[Nicolas Luna]

Sekhar,

We do not have this buffer on our custom hardware and we have the NACK
problem. SDA and SCL are directly connected from PMIC to OMAP with pull-up.

Is Todd right with the silicon issue? Or a I2C driver issue when it is used
too much... ?

Regards,

Nicolas


On Fri, Jul 30, 2010 at 2:33 AM, Nori, Sekhar  wrote:

> On Thu, Jul 29, 2010 at 23:36:18, Nicolas Luna wrote:
> > Ok it's good to know.
> >
> > Do you know if the problem is solved in AM1808 I2C silicon module?
> >
>
> By "silicon module" you mean Logic's "System-on-Module (SoM)"?
>
> The answer I believe is no. The solution will be implemented in
> an upcoming Logic EVM revision. Here is the change statement:
>
> "The hardware fix for this issue is to remove U24 and R161 and short U24
> pins 2 to 4"
>
> Due to the high amount of integration on SoM, I am not sure how
> feasible it is to do such a change in a simple lab setup.
>
> 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: Boot time

[Nicolas Luna]

Hi,

Thanks guys for your advices, I applied few of them and I save a lot of
time, I'm at 3.9 seconds now. I'll also apply the deferred init calls concept
later.

I have two other questions.

I'm not sure to understand how to use EDMA to copy from NOR to RAM in uboot.
Every post that I found it is never explain the procedure to apply this
patch. Do you guys have a piece of code or something to get started with
that?

In the same way, after the kernel boot, I have to start an application with
QT and it takes 10 seconds to transfert QT lib (libQtCore, libQtGui,
libQtNetwork, fonts) from NOR to RAM and start the application. QT stuff is
~20MB, I removed every useless lib to reduce the amount of data to
transfert. I also optimised the EMIFA CS2 (I changed EMIFA clock to 150 Mhz
and changed CS timing to be at the maximum of my NOR). I probed the NOR chip
select and there are big delays between read access. I suppose that is
because it is not using EDMA and the CPU is not able to feed the NOR... I
would like to reduce this transfert time to ~4 secondes or less and I think
that EDMA could maybe help to do it. Do you have any idea how to apply it,
or any other ideas?

Thanks for your time.

Regards,

Nicolas


On Thu, Jul 29, 2010 at 10:42 PM, rohan tabish wrote:

> set verify=n this will ignore checksum
>
> Regard's
> RT
>
> --- On *Thu, 29/7/10, Nicolas Luna * wrote:
>
>
> From: Nicolas Luna 
> Subject: Boot time
> To: davinci-linux-open-source@linux.davincidsp.com
> Date: Thursday, 29 July, 2010, 0:59
>
>
> Hi guys,
>
> I'm trying to make by board boot as quick as possible. I did some
> optimisation with the "All This For 1 Second Boot" wiki and other website. I
> would like to reduce a little bit more the boot time and I wonder if you
> guys could give me some clues.
>
> I copied my boot log below. For sure I'll remove the uboot autoboot delay
> and probably build a new kernel with modules. I putted in bold part that I
> think it is possible to do more optimisation.
>
> 1- See bullet #3.
> 2- The verifying Checksum is about 400 msec is it possible to skip it?
> 3- It takes ~1 sec to start booting the kernel and there is a other ~1 sec
> delay between the starting kernel and the beginning of the uncompressing.
> Why it's so long? Ok maybe there is the copy from NOR to RAM but it should
> not take more than few msec.
> 4- It takes ~1 sec to the kernel to free 120K memory... I got enought RAM
> is it possible to remove it?
>
> I got custom hardware based on OMAP-L138 with FS (jffs2) and compressed
> kernel in NOR Flash.
>
> Thanks a lot
>
> Nicolas
>
>
> -
>
> 0.000 0.000: OMAP-L138 initialization passed!
> 0.000 0.000: Booting TI User Boot Loader
> 0.004 0.004:UBL Version: 1.65
> 0.004 0.000:UBL Flashtype: NOR
> 0.008 0.004: Starting NOR Copy...
> 0.008 0.000: CFI Query...passed.
> 0.012 0.004: NOR Initialization:
> 0.012 0.000:Command Set: Intel
> 0.012 0.000:Manufacturer: INTEL
> 0.016 0.004:Size: 0x0020 MB
> 0.020 0.004: Valid magicnum, 0x55424CBB, found..
> 0.184 0.164:DONE
> 0.188 0.004: Jumping to entry point at 0xC108.
> 0.504 0.316:
> 1.548 1.044: Hit any key to stop autoboot:  0
> *2.372 0.824: ## Booting kernel from Legacy Image at c0007fc0 ...*
> 2.372 0.000:Image Name:   Linux-2.6.34
> 2.380 0.008:Image Type:   ARM Linux Kernel Image (uncompressed)
> 2.380 0.000:Data Size:1505956 Bytes =  1.4 MB
> 2.384 0.004:Load Address: c0008000
> 2.388 0.004:Entry Point:  c0008000
> *2.808 0.420:Verifying Checksum ... OK*
> 2.808 0.000:Loading Kernel Image ... OK
> 2.808 0.000: OK
> 2.808 0.000:
> *2.812 0.004: Starting kernel ...*
> *2.812 0.000:*
> *3.860 1.048: Uncompressing Linux... done, booting the kernel.*
> 4.264 0.404: Linux version 2.6.34 (i...@idt-ubuntu-linux) (gcc version 4.3.3
> (Sourcery G++ Lite 2009q1-203) ) #89 PREEMPT Thu Jul 22 15:24:03 EDT 2010
> 4.268 0.004: CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
> 4.272 0.004: CPU: VIVT data cache, VIVT instruction cache
> 4.276 0.004: Machine: DaVinci DA850/OMAP-L138 EVM
> 4.280 0.004: Memory policy: ECC disabled, Data cache writeback
> 4.284 0.004: DaVinci da850/omap-l138 variant 0x0
> 4.288 0.004: Built 1 zonelists in Zone order, mobility grouping on.  Total
> pages: 32512
> 4.300 0.012: Kernel command line: lpj=747520 mem=128M
> console=ttyS2,115200n8 root=/dev/mtdblock2 rootfstype=jffs2 rw ip=off
> 4.304 0.004: PID hash table entries: 512 (order: -1, 2048 bytes)
> 4.308 0.004: Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> 4.316 0.008: Inode-cache hash table entr

Re: Touchscreen - MFD driver for TPS6507x family

[Nicolas Luna]

Hi Sekhar,

Yes there is an other device on the bus, but I removed it and I decreased
the clock to 20khz. I cannot go below because the i2c seems not to work. It
does solved the problem.

I modified the driver to add a while(1) when it got an abnormal termination.
I notified that every time the driver makes this error, I can see a clock
stretch (with a scope) on the last i2c frame.

- The PMIC (tps65070) is rated to work at 400khz, but even at 20khz it seems
to need more time to response when it is addressed to much. I modified the
touchscreen polling period to 100 msec and I still got errors. Maybe if the
touchscreen driver was working by interruption that would leave a chance to
the PMIC.

- Why the i2c driver do not handles clock stretching?

- On a test there was 2 successive reads to register 02h with a delay of 85
msec between. The first went right but while the next read, the salve put
the clock low to stretch it. It sounds like a problem to me because the chip
was not receiving a lot of messages and it stretched the clock. I cannot
find any place in the datasheet that is talking about that issue.

Thank you.

Regards,

Nicolas



On Mon, Aug 2, 2010 at 12:35 PM, Nori, Sekhar  wrote:

>
> Hi Nicolas,
>
> On Fri, Jul 30, 2010 at 23:05:21, Nicolas Luna wrote:
> > Sekhar,
> >
> > We do not have this buffer on our custom hardware and we have the NACK
> > problem. SDA and SCL are directly connected from PMIC to OMAP with
> > pull-up.
> >
> > Is Todd right with the silicon issue? Or a I2C driver issue when it is
> > used too much... ?
>
> There is no silicon issue that I know of. The silicon meets I2C
> specification.
> All the advisories with silicon are documented here:
> http://focus.ti.com/lit/er/sprz301c/sprz301c.pdf
>
> >   i2c_davinci i2c_davinci.1: controller timed out
> >   i2c_davinci i2c_davinci.1: initiating i2c bus recovery
>
> I remember users on the list reporting these errors when a slave device is
> pulling the clock low for a long time. The first thing to try is a lower
> bus frequency - this is done on DM644x EVM to talk to a slow MSP430 based
> slave.
>
> Also, as I remember, this can even be caused by a slave you are not talking
> to.
> Are there other devices on the I2C bus?
>
> 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: Touchscreen - MFD driver for TPS6507x family

[Nicolas Luna]

Sekhar,


On Tue, Aug 3, 2010 at 12:43 PM, Nori, Sekhar  wrote:

> Hi Nicolas,
>
> On Tue, Aug 03, 2010 at 01:21:14, Nicolas Luna wrote:
> > Hi Sekhar,
> >
> > Yes there is an other device on the bus, but I removed it and I
> > decreased the clock to 20khz. I cannot go below because the i2c seems
> > not to work. It does solved the problem.
> >
> > I modified the driver to add a while(1) when it got an abnormal
> > termination. I notified that every time the driver makes this error, I
> > can see a clock stretch (with a scope) on the last i2c frame.
> >
> > - The PMIC (tps65070) is rated to work at 400khz, but even at 20khz it
> > seems to need more time to response when it is addressed to much. I
> > modified the touchscreen polling period to 100 msec and I still got
> > errors. Maybe if the touchscreen driver was working by interruption that
> > would leave a chance to the PMIC.
>
> It should be possible to use an interrupt on a correctly wired hardware.
> Can you try getting the interrupt mode working? Hopefully Todd or others
> from list can help out in case you run into issues.
>

I'll see what I can do.


>
> >
> > - Why the i2c driver do not handles clock stretching?
>
> It should and seems like there is a 1 second time out the driver has
> waiting for transfer to complete. How long does the clock stretch in
> your case? Please see DAVINCI_I2C_TIMEOUT in
> drivers/i2c/busses/i2c-davinci.c
>

I already tried to change the I2C delay to more than 1 second and my
conclusion is that 1 second is really enough because even with more I had
errors. I think that the delay is not the problem there is something else
when the driver wait for completion. The max stretch I got was not more than
30 msec (when using 30msec polling period). I think that this is due to the
polling period. The touchscreen driver send an other request to the PMIC
even if the last one didn't finished.

*To summarize:*

1- The touchscreen driver should not send an other request if the last one
is not finish. (Interrupts could solve that issue)
2- It's sometime a little long to get a response from the PMIC (I dont know
exacly but it's more than 100msec) let see what TPS hardware person will
say.


>
> > - On a test there was 2 successive reads to register 02h with a delay of
> > 85 msec between. The first went right but while the next read, the salve
> > put the clock low to stretch it. It sounds like a problem to me because
> > the chip was not receiving a lot of messages and it stretched the clock.
> > I cannot find any place in the datasheet that is talking about that
> > issue.
>
> Not sure regarding this. This will likely need some TPS hardware person to
> analyze. Can you please post your observations to the PMU forum at:
> http://e2e.ti.com/support/power_management/pmu/f/200.aspx
>
>
Done.


> Thanks,
> Sekhar
>
>
Nicolas
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: Boot time

[Nicolas Luna]

Caglar,

I tried to use static linking, it reduced the boot time but not enough. Is
it possible to have a look at the code that you ported from linux kernel to
u-boot/UBL ?

Thank you.

Regards,

Nicolas



On Sat, Jul 31, 2010 at 5:10 AM, Caglar Akyuz  wrote:

> On Friday 30 July 2010 11:47:14 pm Nicolas Luna wrote:
> > Hi,
> >
> > Thanks guys for your advices, I applied few of them and I save a lot of
> > time, I'm at 3.9 seconds now. I'll also apply the deferred init calls
> >  concept later.
> >
> > I have two other questions.
> >
> > I'm not sure to understand how to use EDMA to copy from NOR to RAM in
> >  uboot. Every post that I found it is never explain the procedure to
> apply
> >  this patch.
>
> Where is this patch?
>
> >  Do you guys have a piece of code or something to get started
> >  with that?
> >
>
> I ported edma code from Linux kernel to u-boot(and ubl as well), then I
> changed memcpy with edma copy function under u-boot where kernel is copied
> from flash to ram, and later for the relocation in ram. That's all.
>
> > In the same way, after the kernel boot, I have to start an application
> with
> > QT and it takes 10 seconds to transfert QT lib (libQtCore, libQtGui,
> > libQtNetwork, fonts) from NOR to RAM and start the application. QT stuff
> is
> > ~20MB, I removed every useless lib to reduce the amount of data to
> > transfert. I also optimised the EMIFA CS2 (I changed EMIFA clock to 150
> Mhz
> > and changed CS timing to be at the maximum of my NOR). I probed the NOR
> >  chip select and there are big delays between read access. I suppose that
> >  is because it is not using EDMA and the CPU is not able to feed the
> NOR...
> >  I would like to reduce this transfert time to ~4 secondes or less and I
> >  think that EDMA could maybe help to do it. Do you have any idea how to
> >  apply it, or any other ideas?
> >
>
> I think optimizing link time is more important than optimizing transfer
> time.
> You can use static linking but then your application needs to be GPL. So I
> don't think using static linking is an option. In that case you may use
> prelinking feature of gnu linker [1].
>
> [1] http://people.redhat.com/jakub/prelink.pdf
>
> Regards,
> Caglar
>
> > Thanks for your time.
> >
> > Regards,
> >
> > Nicolas
> >
> > On Thu, Jul 29, 2010 at 10:42 PM, rohan tabish
> wrote:
> > > set verify=n this will ignore checksum
> > >
> > > Regard's
> > > RT
> > >
> > > --- On *Thu, 29/7/10, Nicolas Luna * wrote:
> > >
> > >
> > > From: Nicolas Luna 
> > > Subject: Boot time
> > > To: davinci-linux-open-source@linux.davincidsp.com
> > > Date: Thursday, 29 July, 2010, 0:59
> > >
> > >
> > > Hi guys,
> > >
> > > I'm trying to make by board boot as quick as possible. I did some
> > > optimisation with the "All This For 1 Second Boot" wiki and other
> > > website. I would like to reduce a little bit more the boot time and I
> > > wonder if you guys could give me some clues.
> > >
> > > I copied my boot log below. For sure I'll remove the uboot autoboot
> delay
> > > and probably build a new kernel with modules. I putted in bold part
> that
> > > I think it is possible to do more optimisation.
> > >
> > > 1- See bullet #3.
> > > 2- The verifying Checksum is about 400 msec is it possible to skip it?
> > > 3- It takes ~1 sec to start booting the kernel and there is a other ~1
> > > sec delay between the starting kernel and the beginning of the
> > > uncompressing. Why it's so long? Ok maybe there is the copy from NOR to
> > > RAM but it should not take more than few msec.
> > > 4- It takes ~1 sec to the kernel to free 120K memory... I got enought
> RAM
> > > is it possible to remove it?
> > >
> > > I got custom hardware based on OMAP-L138 with FS (jffs2) and compressed
> > > kernel in NOR Flash.
> > >
> > > Thanks a lot
> > >
> > > Nicolas
> > >
> > >
> > >
> -
> > >
> > >
> > > 0.000 0.000: OMAP-L138 initialization passed!
> > > 0.000 0.000: Booting TI User Boot Loader
> > > 0.004 0.004:UBL Version: 1.65
> > > 0.004 0.000:UBL Flashtype: NOR
> > > 0.008 0.004: Starting NOR Copy...
> > > 0.008 0.000: CFI Query...pa

Re: Boot time

[Nicolas Luna]

Caglar,

Thank you, it's appreciated. I would be interested to receive u-boot level
changes as a patch.

Regards,

Nicolas



On Tue, Aug 17, 2010 at 10:31 AM, Caglar Akyuz wrote:

> On Tuesday 17 August 2010 05:15:32 pm Nicolas Luna wrote:
> > Caglar,
> >
> > I tried to use static linking, it reduced the boot time but not enough.
> Is
> > it possible to have a look at the code that you ported from linux kernel
> to
> > u-boot/UBL ?
> >
>
> My local UBL git tree is attached. You can see both DMA and Linux booting
> related changes in history. I can provide u-boot level changes(for dma and
> some small optimizations) as a patch for u-boot as well.
>
> Regards,
> Caglar
>
>
> > Thank you.
> >
> > Regards,
> >
> > Nicolas
> >
> > On Sat, Jul 31, 2010 at 5:10 AM, Caglar Akyuz 
> wrote:
> > > On Friday 30 July 2010 11:47:14 pm Nicolas Luna wrote:
> > > > Hi,
> > > >
> > > > Thanks guys for your advices, I applied few of them and I save a lot
> of
> > > > time, I'm at 3.9 seconds now. I'll also apply the deferred init calls
> > > >  concept later.
> > > >
> > > > I have two other questions.
> > > >
> > > > I'm not sure to understand how to use EDMA to copy from NOR to RAM in
> > > >  uboot. Every post that I found it is never explain the procedure to
> > >
> > > apply
> > >
> > > >  this patch.
> > >
> > > Where is this patch?
> > >
> > > >  Do you guys have a piece of code or something to get started
> > > >  with that?
> > >
> > > I ported edma code from Linux kernel to u-boot(and ubl as well), then I
> > > changed memcpy with edma copy function under u-boot where kernel is
> > > copied from flash to ram, and later for the relocation in ram. That's
> > > all.
> > >
> > > > In the same way, after the kernel boot, I have to start an
> application
> > >
> > > with
> > >
> > > > QT and it takes 10 seconds to transfert QT lib (libQtCore, libQtGui,
> > > > libQtNetwork, fonts) from NOR to RAM and start the application. QT
> > > > stuff
> > >
> > > is
> > >
> > > > ~20MB, I removed every useless lib to reduce the amount of data to
> > > > transfert. I also optimised the EMIFA CS2 (I changed EMIFA clock to
> 150
> > >
> > > Mhz
> > >
> > > > and changed CS timing to be at the maximum of my NOR). I probed the
> NOR
> > > >  chip select and there are big delays between read access. I suppose
> > > > that is because it is not using EDMA and the CPU is not able to feed
> > > > the
> > >
> > > NOR...
> > >
> > > >  I would like to reduce this transfert time to ~4 secondes or less
> and
> > > > I think that EDMA could maybe help to do it. Do you have any idea how
> > > > to apply it, or any other ideas?
> > >
> > > I think optimizing link time is more important than optimizing transfer
> > > time.
> > > You can use static linking but then your application needs to be GPL.
> So
> > > I don't think using static linking is an option. In that case you may
> use
> > > prelinking feature of gnu linker [1].
> > >
> > > [1] http://people.redhat.com/jakub/prelink.pdf
> > >
> > > Regards,
> > > Caglar
> > >
> > > > Thanks for your time.
> > > >
> > > > Regards,
> > > >
> > > > Nicolas
> > > >
> > > > On Thu, Jul 29, 2010 at 10:42 PM, rohan tabish
> > >
> > > wrote:
> > > > > set verify=n this will ignore checksum
> > > > >
> > > > > Regard's
> > > > > RT
> > > > >
> > > > > --- On *Thu, 29/7/10, Nicolas Luna * wrote:
> > > > >
> > > > >
> > > > > From: Nicolas Luna 
> > > > > Subject: Boot time
> > > > > To: davinci-linux-open-source@linux.davincidsp.com
> > > > > Date: Thursday, 29 July, 2010, 0:59
> > > > >
> > > > >
> > > > > Hi guys,
> > > > >
> > > > > I'm trying to make by board boot as quick as possible. I did some
> > > > > optimisation with t

Unhandled USB IRQ

[Nicolas Luna]

Hi,

I got this message when I disconnect usb key from my USB2.0 connector.

*da8xx_interrupt 514: Unhandled USB IRQ 0028*

I'm on OMAPL138 with custum hardware based on EVM. I'm using khilman tree
Linux-2.6.34 with DA8xx glue layer and I modified my board specific files to
add usb 2.0 support.

Any idea what I could look at to correct this issue?

Also, I'll would like to know if its possible to use sda with usb2.0 and sdb
with usb1.1. I'm not using udev all my dev are static.

Thanks

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

Re: Unhandled USB IRQ

[Nicolas Luna]

Thank you it solved the problem.

Regards,
Nicolas


On Wed, Aug 25, 2010 at 2:50 PM, Sergei Shtylyov wrote:

> Hello.
>
>
> Nicolas Luna wrote:
>
>  I got this message when I disconnect usb key from my USB2.0 connector.
>>
>
>  */da8xx_interrupt 514: Unhandled USB IRQ 0028/*
>>
>
>  I'm on OMAPL138 with custum hardware based on EVM. I'm using khilman tree
>> Linux-2.6.34 with DA8xx glue layer and I modified my board specific files to
>> add usb 2.0 support.
>>
>
>  Any idea what I could look at to correct this issue?
>>
>
>   The following patch from 2.6.35 should help:
>
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=patch;h=7d9645fdca444d53907b22a4b73e3967efe09781
>
>
>  Also, I'll would like to know if its possible to use sda with usb2.0 and
>> sdb with usb1.1.
>>
>
>   Don't think so.
>
> 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

OMAP-L138 to AM1808

[Nicolas Luna]

Hi,

I'm running Linux Davinci on a custum hardware based on OMAP L138 EVM. I got
two cards, one with
OMAP-L138and
an other with 
AM1808.
The only difference between the two cards is the CPU, all others peripherals
are same.

I compiled the kernel from DaVinci-PSP-SDK-03.20.00.12.tgz.

The first board with
OMAP-L138
boot
correctly.

With the same kernel image, the second board with
AM1808
freeze
at boot time.

Here is the boot log:

*
*



*Loading: #*

*  #
*

*  *

*done*

*Bytes transferred = 2142892 (20b2ac hex)*

*## Booting kernel from Legacy Image at c0007fc0 ...*

*   Image Name:   Linux-2.6.33-rc4*

*   Image Type:   ARM Linux Kernel Image (uncompressed)*

*   Data Size:2142828 Bytes =  2 MB*

*   Load Address: c0008000*

*   Entry Point:  c0008000*

*   Verifying Checksum ... OK*

*   Loading Kernel Image ... OK*

*OK*

*Starting kernel ...*

*Uncompressing Linux... done, booting the kernel. <= Freezes here !*





I configured the kernel to use 300 Mhz clock, I also tried 456 Mhz but same
behaviour.

It seems to be a bad access to memory. Is there any access to DSP memory map
in the linux kernel?

Also, I tried to turn on a LED before the kernel freeze. Can anybody tell me
where is the linux entry point in the code. I tried to add a raw_write into
"da850_evm_map_io" and in "da850_evm_init" to turn on the LED and it doesn't
work.



Thank you.

Regards,

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

Re: OMAP-L138 to AM1808

[Nicolas Luna]

On Tue, Oct 12, 2010 at 1:19 PM, Victor Rodriguez wrote:

> On Tue, Oct 12, 2010 at 12:12 PM, Nicolas Luna  wrote:
> > Hi,
> >
> > I'm running Linux Davinci on a custum hardware based on OMAP L138 EVM. I
> got
> > two cards, one with OMAP-L138and an other with AM1808. The only
> difference
> > between the two cards is the CPU, all others peripherals are same.
> >
> > I compiled the kernel from DaVinci-PSP-SDK-03.20.00.12.tgz.
> >
> > The first board with OMAP-L138 boot correctly.
> >
> > With the same kernel image, the second board with AM1808 freeze at boot
> > time.
> >
> > Here is the boot log:
> >
> >
> >
> > Loading:
> #
> >
> >
> #
> >
> >   
> >
> > done
> >
> > Bytes transferred = 2142892 (20b2ac hex)
> >
> > ## Booting kernel from Legacy Image at c0007fc0 ...
> >
> >Image Name:   Linux-2.6.33-rc4
> >
> >Image Type:   ARM Linux Kernel Image (uncompressed)
> >
> >Data Size:2142828 Bytes =  2 MB
> >
> >Load Address: c0008000
> >
> >Entry Point:  c0008000
> >
> >Verifying Checksum ... OK
> >
> >Loading Kernel Image ... OK
> >
> > OK
> >
> > Starting kernel ...
> >
> > Uncompressing Linux... done, booting the kernel. <= Freezes here !
> >
>
>
> Check uncompress.h and if your board is there available
>
>
It is.


>
> Besides which board are you using , i mean hawkboard? mytiomap? ...
>

Custom hardware based on OMAP-L138 EVM (ZOOM™ OMAP-L138 EVM DEVELOPMENT KIT)


>
>
> >
> >
> >
> > I configured the kernel to use 300 Mhz clock, I also tried 456 Mhz but
> same
> > behaviour.
> >
> > It seems to be a bad access to memory. Is there any access to DSP memory
> map
> > in the linux kernel?
> >
> > Also, I tried to turn on a LED before the kernel freeze. Can anybody tell
> me
> > where is the linux entry point in the code. I tried to add a raw_write
> into
> > "da850_evm_map_io" and in "da850_evm_init" to turn on the LED and it
> doesn't
> > work.
>
>
> Check the gpio if it si maped and then make a module similar to this
>
> #define PIN_LED GPIO_TO_PIN(6, 12)
> #define MUX_LED DA850_GPIO6_12
>
> static int led_on(void)
> {
>
>
>int ret;
>
>
>gpio_free(PIN_LED);
>
>
>ret = davinci_cfg_reg (MUX_LED);
>if (ret<0)
>{
>printk(KERN_INFO "Error\n");
>return ret;
>}
>
>
>ret = gpio_request(PIN_LED, "led");
>if (ret)
>{
>printk(KERN_INFO "error\n");
>return ret;
>}
>
>
>
>
>gpio_direction_output(PIN_LED, 1);
>
>
>gpio_set_value(PIN_LED, 1);
>
>
>return 0 ;
>
> }
>
>
Well, my board is freezing before all inits, it is why I tried to turn on a
LED directly by writing into the GPIO register. It is working on the board
why OMAP processor but with AM1808 the code seems to freeze
before "da850_evm_init" so the LED doesn't turn on. The goal of this is to
find where the code freeze with the LED. I wonder where I could move my code
to be at the very beginning of linux startup.

Regards,
Nicolas



> Regards
>
> Victor Rodriguez
>
>
> >
> >
> > Thank you.
> >
> > Regards,
> >
> > Nicolas
> >
> > ___
> > 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: OMAP-L138 to AM1808

[Nicolas Luna]

Juha,

It was exactly the problem. With the memory dump I found this ".<3>Unknown
DaVinci JTAG ID 0x1b7d102f" then I changed the variant from 0 to 1 and the
board booted.

*To TI:*
*
*
I checked into the AM1808 datasheet and if I follow this (see below), the
variant should be 0:

u16 variant;/* JTAG ID bits 31:28 */
u16 part_no;/* JTAG ID bits 27:12 */
u16 manufacturer;   /* JTAG ID bits 11:1 */

AM1808 JTAG ID from datasheet: 0x0B7D_102F

 Is it a mistake from the datasheet? We have the ZWT package with silicon
Rev B, is it have anything to do with this?

Nicolas




On Tue, Oct 12, 2010 at 3:31 PM, Juha Kuikka  wrote:

>
> On Tue, Oct 12, 2010 at 10:12 AM, Nicolas Luna  wrote:
>
>> Hi,
>>
>> I'm running Linux Davinci on a custum hardware based on OMAP L138 EVM. I
>> got two cards, one with 
>> OMAP-L138<http://focus-webapps.ti.com/general/docs/sitesearch/searchdevice.tsp?partNumber=omap-l138>and
>> an other with 
>> AM1808<http://focus-webapps.ti.com/general/docs/sitesearch/searchdevice.tsp?partNumber=am1808>.
>> The only difference between the two cards is the CPU, all others peripherals
>> are same.
>>
>> I compiled the kernel from DaVinci-PSP-SDK-03.20.00.12.tgz.
>>
>> The first board with 
>> OMAP-L138<http://focus-webapps.ti.com/general/docs/sitesearch/searchdevice.tsp?partNumber=omap-l138>
>>  boot
>> correctly.
>>
>> With the same kernel image, the second board with 
>> AM1808<http://focus-webapps.ti.com/general/docs/sitesearch/searchdevice.tsp?partNumber=am1808>
>>  freeze
>> at boot time.
>>
>> Here is the boot log:
>>
>> *
>> *
>>
>>
>>
>> *Loading:
>> #*
>>
>> *
>> #*
>>
>> *  *
>>
>> *done*
>>
>> *Bytes transferred = 2142892 (20b2ac hex)*
>>
>> *## Booting kernel from Legacy Image at c0007fc0 ...*
>>
>> *   Image Name:   Linux-2.6.33-rc4*
>>
>> *   Image Type:   ARM Linux Kernel Image (uncompressed)*
>>
>> *   Data Size:2142828 Bytes =  2 MB*
>>
>> *   Load Address: c0008000*
>>
>> *   Entry Point:  c0008000*
>>
>> *   Verifying Checksum ... OK*
>>
>> *   Loading Kernel Image ... OK*
>>
>> *OK*
>>
>> *Starting kernel ...*
>>
>> *Uncompressing Linux... done, booting the kernel. <= Freezes here !*
>>
>>
>> Hi,
>
> I had similar symptoms with a custom board and it turned out that the chip
> (L138) variant was different. I had to add another entry with .variant = 1
> into the da850_ids[] structure in mach-davinci/da850.c.
>
> Just my 2c. :)
>
> Also, take a look at this[1] for getting access to early boot messages
> without LL.
>
>  - Juha
>
> [1] http://elinux.org/Kernel_Debugging_Tips#Debugging_early_boot_problems
> --
> Duck tape is like the force, it has a light side and a dark side and it
> holds the universe together.
>
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Problem with UART1 on Davinci with OMAP-L138 ?

[Nicolas Luna]

Hi,

I'm trying to communication with UART1 on OMAP-L138. At the moment, I can
write message to the serial port but I cannot read some. I got the error 11:
Resource temporarily unavailable.

To activate the UART1, I commented one line (see below) in
board-da850-evm.c. I wonder what is "too much work in irq53", is it has
anything to do with my problem? Is it a know bug to not be able to read from
UART1 under Davinci?

/*
 * shut down uart 0 and 1; they are not used on the board and
 * accessing them causes endless "too much work in irq53" messages
 * with arago fs
 */
*//__raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);*
__raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);


Thanks for support.

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

Re: Problem with UART1 on Davinci with OMAP-L138 ?

[Nicolas Luna]

Victor,

What should I check? You mean the file system /dev/ttyS.. is not correct?

Regards,
Nicolas


On Thu, Oct 14, 2010 at 4:53 PM, Victor Rodriguez wrote:

> On Thu, Oct 14, 2010 at 3:41 PM, Nicolas Luna  wrote:
> > Hi,
> > I'm trying to communication with UART1 on OMAP-L138. At the moment, I can
> > write message to the serial port but I cannot read some. I got the error
> 11:
> > Resource temporarily unavailable.
> > To activate the UART1, I commented one line (see below) in
> > board-da850-evm.c. I wonder what is "too much work in irq53", is it has
> > anything to do with my problem? Is it a know bug to not be able to read
> from
> > UART1 under Davinci?
> > /*
> > * shut down uart 0 and 1; they are not used on the board and
> > * accessing them causes endless "too much work in irq53" messages
> > * with arago fs
> > */
> > //__raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
> > __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
>
>
> Check with latest file system from angstrom I had the same problem
> with the initial support fro Hawkboard omapl 138
>
> Regards
>
> Victor Rodriguez
>
> > Thanks for support.
> > Regards,
> > Nicolas
> >
> >
> >
> > ___
> > 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: Problem with UART1 on Davinci with OMAP-L138 ?

[Nicolas Luna]

On Thu, Oct 14, 2010 at 5:18 PM, Victor Rodriguez wrote:

> On Thu, Oct 14, 2010 at 4:10 PM, Nicolas Luna  wrote:
> > Victor,
> > What should I check? You mean the file system /dev/ttyS.. is not correct?
> > Regards,
> > Nicolas
>
>
> Do not top post :)
>
> >
> > On Thu, Oct 14, 2010 at 4:53 PM, Victor Rodriguez 
> > wrote:
> >>
> >> On Thu, Oct 14, 2010 at 3:41 PM, Nicolas Luna 
> wrote:
> >> > Hi,
> >> > I'm trying to communication with UART1 on OMAP-L138. At the moment, I
> >> > can
> >> > write message to the serial port but I cannot read some. I got
> the error
> >> > 11:
> >> > Resource temporarily unavailable.
> >> > To activate the UART1, I commented one line (see below) in
> >> > board-da850-evm.c. I wonder what is "too much work in irq53", is it
> has
> >> > anything to do with my problem? Is it a know bug to not be able to
> read
> >> > from
> >> > UART1 under Davinci?
> >> > /*
> >> > * shut down uart 0 and 1; they are not used on the board and
> >> > * accessing them causes endless "too much work in irq53" messages
> >> > * with arago fs
> >> > */
> >> > //__raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
> >> > __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
> >>
> >>
> >> Check with latest file system from angstrom I had the same problem
> >> with the initial support fro Hawkboard omapl 138
>
> Check this commit
>
>
> https://mail.sasken.com/OWA/redir.aspx?C=ded1d3bc21834b138e93aa6e04f85155&URL=http%3a%2f%2fgit.kernel.org%2f%3fp%3dlinux%2fkernel%2fgit%2fkhilman%2flinux-davinci.git%3ba%3dcommitdiff%3bh%3d6c18c91b3a6db6169998b54df12c9d53e74999f3
>
> This patch adds initial support for the Hawkboard-L138 system
> It is under the machine name "omapl138_hawkboard".
> This system is based on the da850 davinci CPU architecture.
> Information on these system may be found at http://www.hawkboard.org.
> Basic support for the UART console is included in this patch.
> It's tested with latest Angstrom File Systems like ramdisk
> from http://alturl.com/imb45.
>
>
> Some old file systems used to open all the Serial Ports but in OMAP
> l138 the uart 1 is multiplexed and generate the spurious interrupt Try
> with latest Argo File Systems
>
>
> Regards
>
> Victor Rodriguez
>
>
> >> Regards
> >>
> >> Victor Rodriguez
> >>
> >> > Thanks for support.
> >> > Regards,
> >> > Nicolas
> >> >
> >> >
> >> >
> >> > ___
> >> > Davinci-linux-open-source mailing list
> >> > Davinci-linux-open-source@linux.davincidsp.com
> >> >
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> >> >
> >> >
> >
> >
>

Victor,

Sorry for top post, gmail automaticlly top post.

I tried the file system with my current kernel image and I got the same
error. Then I tried the linux image provided into the tar generated by the
siteweb but I am not able to boot it because I need an other JTAG ID that
the default one because of my silicon revision.

I checked to the patch and I got the same configuration.

Do you have any idea what I should change into my kernel source code to
solve the uart issue?

Thank you

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

Touchscreen & PMIC

[Nicolas Luna]

Hi,

I'm running kernel v2.6.34 from *linux/kernel/git/khilman/linux-davinci.git*
*/ *on custom hardware based on OMAP-L138 EVM. I got tps65070 to manage
power, touchscreen and LCD backlight. My touchscreen is working fine but
when I try to communicate with my PMIC by I2C, I got this error  "errno 16
Device or resource busy".

If I disable the touchscreen driver, everything is fine and I can modify
PMIC registers without problem.

Any ideas?

Thanks

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

OMAP-L138 SPI kernel panic

[Nicolas Luna]

Hi everyone,

I got the ZOOM OMAP-L138 EVM DEVELOPMENT KIT and DaVinci-PSP-SDK-03.20.00.06
with Arago distribution developed by TI for OMAP processor.

I'm trying to communicate with an external spi device. I configured my
kernel to support spi and modified arch source file to add "spidev" to /dev
directory.


*Here’s what I changed in board-da850-evm.c :*

*static struct spi_board_info da850_spi_board_info[] = {*

*[0] = {*

*//  .modalias = "m25p80",*

*.modalias = "spidev",*

*//  .platform_data = &spi_flash_data,*

*//  .controller_data = &m25p64_spi_cfg,*

*.mode = SPI_MODE_0,*

*.max_speed_hz = 3000,   /* max sample rate at 3V */
*

*.bus_num = 1,*

*.chip_select = 0,*

*},*

*};*


Also, in the menuconfig I added support for SPI and Device Drivers  ---> SPI
support  ---> User mode SPI device driver support.

I currently have spidev1.0 in /dev directory. There are a lot of ioctl
command with the SPI, I successfully executed few of them: SPI_IOC_RD_MODE,
SPI_IOC_RD_BITS_PER_WORD, SPI_IOC_RD_MAX_SPEED_HZ.

The problem is when I execute ioctl(.., SPI_IOC_MESSAGE(1), ..) the board
crash.


*Here’s what happens when I execute SPI_IOC_MESSAGE:*

*Unable to handle kernel NULL pointer dereference at virtual address
0010*

*pgd = c0004000*

*[0010] *pgd=*

*Internal error: Oops: 17 [#1] PREEMPT*

*CPU: 0Not tainted  (2.6.31-rc7-davinci1 #2)*

*PC is at davinci_spi_bufs_prep+0xc/0x47c*

*LR is at davinci_spi_bufs_pio+0x68/0x2b4*

*pc : []lr : []psr: 6013*

*sp : c1dcbf04  ip : c1dcbf18  fp : c1dcbf14*

*r10: c1d042b8  r9 : 0001  r8 : c1ddbf00*

*r7 :   r6 : c02a06dc  r5 : c1ce7300  r4 : c1d042b8*

*r3 :   r2 :   r1 : c1d042b8  r0 : c1ce7300*

*Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel*

*Control: 0005317f  Table: c1e3  DAC: 0017*

*Process dm_spi.1 (pid: 236, stack limit = 0xc1dca270)*

*Stack: (0xc1dcbf04 to 0xc1dcc000)*

*bf00:  c1d042b8 c1dcbf44 c1dcbf18 c01abb7c c01ab0f8 
c1ddbf00*

*bf20:  c1c6de9c c1c6debc c1dca000  c1d042b8 c1dcbf84
c1dcbf48*

*bf40: c01aacfc c01abb24 c1d042cc  c01ac3b0 c1ce7300 
c1d042c0*

*bf60: c1d042bc c1dca000 c1dcdf80 c01aab74  c1dcdf88 c1dcbfc4
c1dcbf88*

*bf80: c0049b30 c01aab84 c0234400  c1cd4000 c004d750 c1dcbf98
c1dcbf98*

*bfa0: c1dcbfcc c1c21d78 c1dcdf80 c00499e8   c1dcbff4
c1dcbfc8*

*bfc0: c004d4e0 c00499f8   c1dcbfd0 c1dcbfd0 
*

*bfe0:    c1dcbff8 c003ac50 c004d468 
*

*Backtrace:*

*[] (davinci_spi_bufs_prep+0x0/0x47c) from []
(davinci_spi_bufs_pio+0x68/0x2b4)*

* r4:c1d042b8*

*[] (davinci_spi_bufs_pio+0x0/0x2b4) from []
(bitbang_work+0x188/0x2ec)*

*[] (bitbang_work+0x0/0x2ec) from []
(worker_thread+0x148/0x20c)*

*[] (worker_thread+0x0/0x20c) from []
(kthread+0x88/0x90)*

*[] (kthread+0x0/0x90) from [] (do_exit+0x0/0x650)*

* r7: r6: r5: r4:*

*Code: e89da800 e1a0c00d e92dd810 e24cb004 (e5923010)*

*---[ end trace 4f0e16f9f2f85b61 ]---*


Do you have any idea why the board is crashing?

Thanks

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