date:20090810

Re: saDisplay + DM6467 showing black an white image in SD Display

2009-08-10 Thread Deepika Makhija





Hi Vinayagam,

H264 sample streams are available on TI Extranet:
https://www-a.ti.com/extranet/cm/product/dvevmsw/dspswext/general/dm355_dvevm.shtml


Consider TI's decode application, file
"dvsdk_demos_1_40_00_18/dm6467/decode/video.c" is used to set the
decoder parameters, where Vdec2_Params_DEFAULT and
Vdec2_DynamicParams_DEFAULT are used to set the default decoder
parameters, whose value is mentioned in dmai module, you have to
modify height/width of these as per your resolution. Same would be the
case with "dvsdk_demos_1_40_00_18/dm6467/decode/display.c" where
default display parameters are set with
Display_Attrs_DM6467_VID_DEFAULT. 

Regards,
Deepika


Vinayagam Mariappan wrote:
Hi,
  
I have only H264 TI Codec Lib but I do not find H264 Stream for D1. 
Do you have any sample file? 
  
Please send me if you have one...
  
Its confusing me to Integrate with our customized codec... As I know,
I have to do minimal changes to get our customized codec to work with
our TI Demo Application. 
Could you please me specific things to see?
Do you have any idea which specific enum directly look into it...?
  
Regards,
Vinayagam M
  
  
  On Mon, Aug 3, 2009 at 1:40 PM, Deepika
Makhija deepika.makh...@einfochips.com
wrote:
  Hi,

Nice to hear that your saDisplay is working now.

"we are not getting video.But I get video data till App." Can you
please describe in detail, up till which module you are getting correct
output.

I would suggest instead of integrating your decoder, first try to
modify the application to work at D1 resolution with TI codecs, which
are capable of decoding D1 resolution also, for that you would have to
change few enums in the application. Once that path is clear than
integrate your decoder.


Regards,
Deepika

Vinayagam Mariappan wrote:


Hi
Deepika,
I just made the saDisplay to work properly.
Now I have to change the Decoder Application to work with our
customized decoder which always give video out with D1 resolution...
The TI Demo Application is for HD Display and I change that to work
for SD Display. When I integrate our customized decoder with demo
application, we are not getting video.But I get video data till App.
Where will be the problem...
Regards,
Vinayagam M


-- 
_

Disclaimer: This e-mail message and all attachments transmitted with it
are intended solely for the use of the addressee and may contain legally
privileged and confidential information. If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution, copying, or other use of
this message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender immediately by
replying to this message and please delete it from your computer. Any
views expressed in this message are those of the individual sender
unless otherwise stated.Company has taken enough precautions to prevent
the spread of viruses. However the company accepts no liability for any
damage caused by any virus transmitted by this email.

_

  
  
  
  
  
-- 
Regards, 
Vinayagam M 
  
VeNMSOL Technologies,
  
#7A, First Cross Street, Ganapathy Colony,
  
Ekkaduthangal, Chennai - 600 032,India.
  
Tel:+91-44-4353 0168;Mobile:+91-9445-019919
  
URL: www.venmsol.com
"We make a living by what we get, we make a life by what we give...-
Unknown "
  
  
  
  
  

  

Email Scanned for
Virus  Dangerous Content by : www.CleanMailGateway.com

  

  



-- 
Thanks  Regards,
Deepika Makhija
eInfochips Ltd.
Tel. No. +91-79-26563705 Ext. 218
www.einfochips.com

--  



Disclaimer: This e-mail message and all attachments transmitted with it
are intended solely for the use of the addressee and may contain legally
privileged and confidential information. If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution, copying, or other use of
this message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender immediately by
replying to this message and please delete it from your computer. Any
views expressed in this message are those of the individual sender
unless otherwise stated.Company has taken enough precautions to prevent
the spread of viruses. However the company accepts no liability for any
damage caused by any virus transmitted by this email.






___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com

how can i add spi1 or spi2 device in the kernel linux2.6.10 of dm355?

2009-08-10 Thread zuowenping

I have to use spi0 and spi1 in dm355 on the same time,I have modified the 
davinci_spi_eeprom driver(it used spi0) to communicate a device sucessed!  but 
now when i wanted to add spi1 driver for another device to kernel, it didn't 
work! I add source as bellow:

static struct spi_board_info dm355_spi_board_info[] = {
...
#if SPI_1098
{
 .modalias = spi_1098,
 .platform_data = NULL,//davinci_8k_spi_eeprom_info,
 .mode = SPI_MODE_0,
 .irq = 0,
 .max_speed_hz = 200*1000,//2 * 1000 * 1000 /* max sample rate at 3V */ ,
 .bus_num = 65535, 
 .chip_select = 1,
 },
#endif
.
}

And  i have register a spi driver spi_driver :
static struct spi_driver spidev_1098 = {
.driver = {
.name = spi_1098,
.bus = spi_bus_type,
.owner = THIS_MODULE,
},
.probe = spi1098_probe,
.remove = __devexit_p(spi1098_remove),
};
By the printk information, spi1098_probe cann't been call, And i only find one 
device (spi_eeprom) in /sys/bus/spi/devices/ ,so the driver cann't been 
matched!  then how can i add spi1 or spi2 device in the kernel? Any hints will 
been appreciated!
2009-08-10 



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

webcam h264 dm6467

2009-08-10 Thread anis monser


hello everybody

I want to encode with h264 on dm6467 an input video witch captured with a 
webcam. 
is it possible ?? 
If not tell me please the reason 
I can’t find any information in the web
thanks

_
Avec Windows Live, vous organisez, retouchez et partagez vos photos.
http://www.microsoft.com/northafrica/windows/windowslive/products/photo-gallery-edit.aspx___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: [PATCH v4 3/3] mtd-nand: DaVinci: Add 4-bit ECC support for large page NAND chips

2009-08-10 Thread Narnakaje, Snehaprabha

Artem,

The patches on the link below are quite old - v2 version of the patches.

I had sent v3 version of the patches mid July, which Andrew had pulled into the 
mmotm tree. One of the patches v4, 3/3 was re-submitted last week.

Patch v3 1/3: 
http://userweb.kernel.org/~akpm/mmotm/broken-out/mtd-nand-add-page-parameter-to-all-read_page-read_page_raw-apis.patch
Patch v3 2/3: 
http://userweb.kernel.org/~akpm/mmotm/broken-out/mtd-nand-add-new-ecc-mode-ecc_hw_oob_first.patch
Patch v4 3/3: 
http://lists.infradead.org/pipermail/linux-mtd/2009-August/026832.html

The l2-mtd-2.6.git tree can be updated for the 3 patches above.

Thanks
Sneha

 -Original Message-
 From: Artem Bityutskiy [mailto:dedeki...@gmail.com]
 Sent: Monday, August 10, 2009 2:50 AM
 To: Narnakaje, Snehaprabha
 Cc: linux-...@lists.infradead.org; davinci-linux-open-
 sou...@linux.davincidsp.com; dw...@infradead.org; t...@linutronix.de;
 a...@linux-foundation.org; Paulraj, Sandeep
 Subject: Re: [PATCH v4 3/3] mtd-nand: DaVinci: Add 4-bit ECC support for
 large page NAND chips
 
 On 08/07/2009 11:48 PM, nsnehapra...@ti.com wrote:
  From: Sneha Narnakajensnehapra...@ti.com
 
  This patch adds 4-bit ECC support for large page NAND chips using the
 new ECC
  mode NAND_ECC_HW_OOB_FIRST. The platform data from board-dm355-evm has
 been
  adjusted to use this mode.
 
  The patches have been verified on DM355 device with 2K Micron devices
 using
  mtd-tests and JFFS2. Error correction upto 4-bits has also been verified
 using
  nandwrite/nanddump utilities.
 
  This patch series applies to linux-mtd next (mmotm) GIT tree.
 
  This version (v4) addresses the review comment to leave 2 bytes at
 offset 0
  for NAND manufacturer badblock markers.
 
  Reviewed-by: David Brownelldbrown...@users.sourceforge.net
  Signed-off-by: Sneha Narnakajensnehapra...@ti.com
  Signed-off-by: Sandeep Paulrajs-paul...@ti.com
 
 There are already 3 patches in my l2-mtd-2.6.git tree:
 
 http://git.infradead.org/users/dedekind/l2-mtd-
 2.6.git/commit/d391d866060d31884c6fc0fe459b3d9ee0a8fd4c
 http://git.infradead.org/users/dedekind/l2-mtd-
 2.6.git/commit/5284a62fc7a526db9db1c922208e07b7fc442e72
 http://git.infradead.org/users/dedekind/l2-mtd-
 2.6.git/commit/8cefbcdbb7d60baddb2db3d8d743b03eb3df619e
 
 Please, verify them and let me know if they are OK or I should drop
 them and take other patches.
 
 --
 Best Regards,
 Artem Bityutskiy (Артём Битюцкий)

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

RE: linux-next on V4L-DVB repository not booting up on DM6467 evm

2009-08-10 Thread Karicheri, Muralidharan

Kevin,

I think for developers like me, it is best bet to create the architecture part 
of the patches w.r.t davinci tree that you maintain and v4l patches using 
linux-next of the v4l-dbv tree. I had used all of Chaithrika's patches 
including architecture part. What I have seen is the board and platform files 
on linux-next is not the latest. So I had to manually merge the changes.

For testing it is best to use the davinci tree as it is the latest and greatest 
for davinci platforms.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com

-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, August 07, 2009 7:59 PM
To: Karicheri, Muralidharan
Cc: Narnakaje, Snehaprabha; davinci-linux-open-source@linux.davincidsp.com;
Mauro Carvalho Chehab; mche...@infradead.org
Subject: Re: linux-next on V4L-DVB repository not booting up on DM6467 evm

Karicheri, Muralidharan m-kariche...@ti.com writes:

 linux-next branch on v4l-dvb has added vpfe and vpif drivers. I have
 tried building DM646x with vpif display driver and loaded onto my
 DM6467 evm.  But it doesn't boot up. So I am wondering if relevant
 board specific changes are available onto this branch.

More than likely you're missing Chaithrika's patch:

  [PATCH v4] ARM: DaVinci: DM646x Video: Platform and board specific setup

which wasn't in either davinci git or Mauro's queue.

 Any idea if I need to test this branch or wait for this to be merged
 to davinci tree and test it on the davinci tree. What is the plan
 for adding these to your davinci tree? In my understanding, I can
 use davinci tree for testing and V4l-DVB for patch submission. Do
 you know if this is fine? I have copied Mauro also to this email for
 his comment.

If that doesn't work, there may be some other platform support
that has gone via davinci git.

You should probably use DaVinci git merged with Mauro's next branch.
You will have to resolve several conflicts that are simple to resolve
because DaVinci has a bunch of platform updates and so does Mauro's
branch.  They are trivial to resolve since they both add new code to
the same place.

Hope that helps,

Kevin

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

Re: linux-next on V4L-DVB repository not booting up on DM6467 evm

2009-08-10 Thread Kevin Hilman

Karicheri, Muralidharan m-kariche...@ti.com writes:

 I think for developers like me, it is best bet to create the
 architecture part of the patches w.r.t davinci tree that you maintain
 and v4l patches using linux-next of the v4l-dbv tree. 

That's OK with me, as long as you can ensure that things build.

 I had used all of Chaithrika's patches including architecture
 part. What I have seen is the board and platform files on linux-next
 is not the latest. So I had to manually merge the changes.

Yes, you have to merge the two together as Mauro's tree only has V4L2
related changes.

All the other board/platform file changes are in DaVinci git and
queued for linux-next that way.

 For testing it is best to use the davinci tree as it is the latest and
 greatest for davinci platforms.

Yet, for testing some drivers that are going upstream via different
trees, you will sometimes have to merge DaVinci git with another
upstream tree for testing.

Kevin


 Murali Karicheri Software Design Engineer Texas Instruments Inc.
 Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736
 (will be deprecated) email: m-kariche...@ti.com

-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, August 07, 2009 7:59 PM
To: Karicheri, Muralidharan
Cc: Narnakaje, Snehaprabha;
 davinci-linux-open-source@linux.davincidsp.com;
Mauro Carvalho Chehab; mche...@infradead.org
Subject: Re: linux-next on V4L-DVB repository not booting up on
 DM6467 evm

Karicheri, Muralidharan m-kariche...@ti.com writes:

 linux-next branch on v4l-dvb has added vpfe and vpif drivers. I
 have tried building DM646x with vpif display driver and loaded onto
 my DM6467 evm.  But it doesn't boot up. So I am wondering if
 relevant board specific changes are available onto this branch.

More than likely you're missing Chaithrika's patch:
 [PATCH v4] ARM: DaVinci: DM646x Video: Platform and board specific
 setup

which wasn't in either davinci git or Mauro's queue.

 Any idea if I need to test this branch or wait for this to be
 merged to davinci tree and test it on the davinci tree. What is the
 plan for adding these to your davinci tree? In my understanding, I
 can use davinci tree for testing and V4l-DVB for patch
 submission. Do you know if this is fine? I have copied Mauro also
 to this email for his comment.

If that doesn't work, there may be some other platform support
that has gone via davinci git.

You should probably use DaVinci git merged with Mauro's next branch.
You will have to resolve several conflicts that are simple to resolve
because DaVinci has a bunch of platform updates and so does Mauro's
branch.  They are trivial to resolve since they both add new code to
the same place.

Hope that helps,

Kevin

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

Re: [PATCH] V4L/DVB: dm646x: fix DMA_nnBIT_MASK

2009-08-10 Thread Kevin Hilman

Kevin Hilman khil...@deeprootsystems.com writes:

 Fix deprecated use of DMA_nnBIT_MASK which now gives a compiler
 warning.

 Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
 ---
 This compiler warning patch is on top of the master branch of Mauro's 
 linux-next tree.

Ping. 

This is needed on top of the DaVinci changes queued in the master branch
of Mauro's linux-next.git.

Kevin

  arch/arm/mach-davinci/dm646x.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
 index 73a7e8b..8f38371 100644
 --- a/arch/arm/mach-davinci/dm646x.c
 +++ b/arch/arm/mach-davinci/dm646x.c
 @@ -720,7 +720,7 @@ static struct platform_device vpif_display_dev = {
   .id = -1,
   .dev= {
   .dma_mask   = vpif_dma_mask,
 - .coherent_dma_mask  = DMA_32BIT_MASK,
 + .coherent_dma_mask  = DMA_BIT_MASK(32),
   },
   .resource   = vpif_resource,
   .num_resources  = ARRAY_SIZE(vpif_resource),
 -- 
 1.6.3.3

___
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 2/3] cpufreq: add generic CPUFreq driver for DaVinci

2009-08-10 Thread Kevin Hilman

Sekhar Nori nsek...@ti.com writes:

 Adds a basic CPUFreq driver for DaVinci devices registering with the
 kernel CPUFreq infrastructure.

 Signed-off-by: Sekhar Nori nsek...@ti.com

Looks mostly OK, some minor comments below, mainly based on stuff
copied from OMAP...

 ---
  arch/arm/Kconfig|2 +-
  arch/arm/mach-davinci/Makefile  |3 +
  arch/arm/mach-davinci/cpu-davinci.c |  179 
 +++

I know this is copied from cpu-omap.c, but I've never liked that name.
How about cpufreq.c.

  arch/arm/mach-davinci/include/mach/common.h |3 +
  4 files changed, 186 insertions(+), 1 deletions(-)
  create mode 100644 arch/arm/mach-davinci/cpu-davinci.c

 diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
 index aef63c8..37ad68a 100644
 --- a/arch/arm/Kconfig
 +++ b/arch/arm/Kconfig
 @@ -1241,7 +1241,7 @@ endmenu
  
  menu CPU Power Management
  
 -if (ARCH_SA1100 || ARCH_INTEGRATOR || ARCH_OMAP || ARCH_PXA || ARCH_S3C64XX)
 +if (ARCH_SA1100 || ARCH_INTEGRATOR || ARCH_OMAP || ARCH_PXA || ARCH_S3C64XX 
 || ARCH_DAVINCI)
  

Can we make this dependent on CONFIG_ARCH_DAVINCI_DA8XX? unless there
are plans to make CPUfreq work on DM.

  source drivers/cpufreq/Kconfig
  
 diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
 index 2e11e84..14b9527 100644
 --- a/arch/arm/mach-davinci/Makefile
 +++ b/arch/arm/mach-davinci/Makefile
 @@ -29,3 +29,6 @@ obj-$(CONFIG_MACH_DAVINCI_DM6467_EVM)   += 
 board-dm646x-evm.o
  obj-$(CONFIG_MACH_DAVINCI_DM365_EVM) += board-dm365-evm.o
  obj-$(CONFIG_MACH_DAVINCI_DA830_EVM) += board-da830-evm.o
  obj-$(CONFIG_MACH_DAVINCI_DA850_EVM) += board-da850-evm.o
 +
 +# Power Management
 +obj-$(CONFIG_CPU_FREQ)   += cpu-davinci.o
 diff --git a/arch/arm/mach-davinci/cpu-davinci.c 
 b/arch/arm/mach-davinci/cpu-davinci.c
 new file mode 100644
 index 000..52527f1
 --- /dev/null
 +++ b/arch/arm/mach-davinci/cpu-davinci.c
 @@ -0,0 +1,179 @@
 +/*
 + * CPU frequency scaling for DaVinci
 + *
 + * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
 + *
 + * Based on linux/arch/arm/plat-omap/cpu-omap.c. Original Copyright follows:
 + *
 + *  Copyright (C) 2005 Nokia Corporation
 + *  Written by Tony Lindgren t...@atomide.com
 + *
 + *  Based on cpu-sa1110.c, Copyright (C) 2001 Russell King
 + *
 + * Copyright (C) 2007-2008 Texas Instruments, Inc.
 + * Updated to support OMAP3
 + * Rajendra Nayak rna...@ti.com
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +#include linux/types.h
 +#include linux/kernel.h
 +#include linux/sched.h
 +#include linux/cpufreq.h
 +#include linux/delay.h
 +#include linux/init.h
 +#include linux/err.h
 +#include linux/clk.h
 +#include linux/io.h
 +
 +#include mach/hardware.h
 +#include asm/system.h
 +#include mach/clock.h
 +#include mach/common.h
 +
 +#include clock.h
 +
 +#define VERY_HI_RATE 9
 +
 +static struct cpufreq_frequency_table *freq_table;
 +static struct clk *armclk;
 +
 +static int davinci_verify_speed(struct cpufreq_policy *policy)
 +{
 + if (freq_table)
 + return cpufreq_frequency_table_verify(policy, freq_table);
 +
 + if (policy-cpu)
 + return -EINVAL;
 +
 + cpufreq_verify_within_limits(policy, policy-cpuinfo.min_freq,
 +  policy-cpuinfo.max_freq);
 +
 + policy-min = clk_round_rate(armclk, policy-min * 1000) / 1000;
 + policy-max = clk_round_rate(armclk, policy-max * 1000) / 1000;
 + cpufreq_verify_within_limits(policy, policy-cpuinfo.min_freq,
 +  policy-cpuinfo.max_freq);
 + return 0;
 +}
 +
 +static unsigned int davinci_getspeed(unsigned int cpu)
 +{
 + unsigned long rate;
 +
 + if (cpu)
 + return 0;
 +
 + rate = clk_get_rate(armclk) / 1000;
 +
 + return rate;
 +}
 +
 +static int davinci_target(struct cpufreq_policy *policy,
 +unsigned int target_freq,
 +unsigned int relation)
 +{
 + struct cpufreq_freqs freqs;
 + int ret = 0;
 +
 + /* Ensure desired rate is within allowed range.  Some govenors
 +  * (ondemand) will just pass target_freq=0 to get the minimum. */
 + if (target_freq  policy-cpuinfo.min_freq)
 + target_freq = policy-cpuinfo.min_freq;
 + if (target_freq  policy-cpuinfo.max_freq)
 + target_freq = policy-cpuinfo.max_freq;
 +
 + freqs.old = davinci_getspeed(0);
 + freqs.new = clk_round_rate(armclk, target_freq * 1000) / 1000;
 + freqs.cpu = 0;
 +
 + if (freqs.old == freqs.new)
 + return ret;
 + cpufreq_notify_transition(freqs, CPUFREQ_PRECHANGE);
 +#ifdef CONFIG_CPU_FREQ_DEBUG
 + printk(KERN_DEBUG cpufreq-davinci: transition: %u -- %u\n,
 +freqs.old, freqs.new);

Re: [PATCH 1/3] davinci: clock framework updates for CPUFreq support

2009-08-10 Thread Kevin Hilman

Sekhar Nori nsek...@ti.com writes:

 Update the clock framework for dynamic CPU frequency change.

 clk_round_rate, clk_set_rate have been updated to handle dynamic frequency
 changes.

 davinci_set_pllrate() changes the PLL rate of a given PLL. This function
 has been presented as a generic function though it has been tested only
 on OMAP-L138 EVM. No other currently available DaVinci device will probably
 use this function, but any future device specific changes will hopefully be
 small enough to get taken care using a cpu_is_xxx() macro.

 Finally, another function is implemented to recalculate the PLL derived rates
 after the PLL rate has been changed.

 Tested on OMAP-L138 EVM.

 Signed-off-by: Sekhar Nori nsek...@ti.com

I think this is a good starting point.  As Dave pointed out, there
will need to be some more sanity checking built into this, but I still
think this is a good place to start.

Pushing today.

Kevin


 ---
  arch/arm/mach-davinci/clock.c |  115 +++-
  arch/arm/mach-davinci/clock.h |9 +++
  2 files changed, 121 insertions(+), 3 deletions(-)

 diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c
 index 83d54d5..8c108eb 100644
 --- a/arch/arm/mach-davinci/clock.c
 +++ b/arch/arm/mach-davinci/clock.c
 @@ -19,6 +19,7 @@
  #include linux/mutex.h
  #include linux/platform_device.h
  #include linux/io.h
 +#include linux/delay.h
  
  #include mach/hardware.h
  
 @@ -99,17 +100,27 @@ long clk_round_rate(struct clk *clk, unsigned long rate)
   if (clk == NULL || IS_ERR(clk))
   return -EINVAL;
  
 + if (clk-round_rate)
 + return clk-round_rate(clk, rate);
 +
   return clk-rate;
  }
  EXPORT_SYMBOL(clk_round_rate);
  
  int clk_set_rate(struct clk *clk, unsigned long rate)
  {
 + unsigned long flags;
 + int ret = -EINVAL;
 +
   if (clk == NULL || IS_ERR(clk))
 - return -EINVAL;
 + return ret;
 +
 + spin_lock_irqsave(clockfw_lock, flags);
 + if (clk-set_rate)
 + ret = clk-set_rate(clk, rate);
 + spin_unlock_irqrestore(clockfw_lock, flags);
  
 - /* changing the clk rate is not supported */
 - return -EINVAL;
 + return ret;
  }
  EXPORT_SYMBOL(clk_set_rate);
  
 @@ -273,6 +284,104 @@ static void __init clk_pll_init(struct clk *clk)
   pr_debug(] -- %lu MHz output.\n, clk-rate / 100);
  }
  
 +/**
 + * davinci_set_pllrate - set the output rate of a given PLL.
 + *
 + * Note: Currently tested to work with OMAP-L138 only.
 + *
 + * @pll: pll whose rate needs to be changed.
 + * @prediv: prediv value to be programmed. Passing 0 disables prediv.
 + * @pllm: pllm value to be programmed. Passing 0 leads to multiply-by-one.
 + * @postdiv: postdiv value to be programmed. Passing 0 disables postdiv.
 + */
 +int davinci_set_pllrate(struct pll_data *pll, unsigned int prediv,
 + unsigned int mult, unsigned int postdiv)
 +{
 + u32 ctrl;
 +
 + BUG_ON(pll-base == NULL);
 +
 + if (prediv)
 + prediv = (prediv - 1) | PLLDIV_EN;
 + if (postdiv)
 + postdiv = (postdiv - 1) | PLLDIV_EN;
 + if (mult)
 + mult = mult - 1;
 +
 + ctrl = __raw_readl(pll-base + PLLCTL);
 +
 + /* Switch the PLL to bypass mode */
 + ctrl = ~(PLLCTL_PLLENSRC | PLLCTL_PLLEN);
 + __raw_writel(ctrl, pll-base + PLLCTL);
 +
 + /*
 +  * Wait for 4 OSCIN/CLKIN cycles to ensure that the PLLC has switched
 +  * to bypass mode. Delay of 1us ensures we are good for all  4MHz
 +  * OSCIN/CLKIN inputs. Typically the input is ~25MHz.
 +  */
 + udelay(1);
 +
 + /* Reset and enable PLL */
 + ctrl = ~(PLLCTL_PLLRST | PLLCTL_PLLDIS);
 + __raw_writel(ctrl, pll-base + PLLCTL);
 +
 + if (pll-flags  PLL_HAS_PREDIV)
 + __raw_writel(prediv, pll-base + PREDIV);
 +
 + __raw_writel(mult, pll-base + PLLM);
 +
 + if (pll-flags  PLL_HAS_POSTDIV)
 + __raw_writel(postdiv, pll-base + POSTDIV);
 +
 + /*
 +  * Wait for PLL to reset properly, OMAP-L138 datasheet says
 +  * 'min' time = 125ns
 +  */
 + udelay(1);
 +
 + /* Bring PLL out of reset */
 + ctrl |= PLLCTL_PLLRST;
 + __raw_writel(ctrl, pll-base + PLLCTL);
 +
 + /*
 +  * Wait for PLL to lock. Time required per OMAP-L138 datasheet is
 +  * (2000 * prediv)/sqrt(pllm) OSCIN cycles. We approximate sqrt(pllm)
 +  * as 4 and OSCIN cycle as 25 MHz.
 +  */
 + udelay((2000 * (prediv + 1)) / 100);
 +
 + /* Remove PLL from bypass mode */
 + ctrl |= PLLCTL_PLLEN;
 + __raw_writel(ctrl, pll-base + PLLCTL);
 +
 + return 0;
 +}
 +EXPORT_SYMBOL(davinci_set_pllrate);
 +
 +/**
 + * davinci_clk_recal_rates - recalculate rates of the davinci clock tree
 + *
 + * @clocks: pointer to the clock tree
 + */
 +int davinci_clk_recalc_rates(struct davinci_clk *clocks)
 +{
 + struct davinci_clk *c;
 + struct clk *clk;
 +
 +

Re: [PATCH 3/3] davinci: DA850/OMAP-L138: add CPUFreq support

2009-08-10 Thread Kevin Hilman

Sekhar Nori nsek...@ti.com writes:

 add basic CPUFreq support for DA850/OMAP-L138

 Currently, frequency scaling only on PLL0 is supported. No scaling of PLL1
 or voltage levels as yet.

 Peripherals like MMC/SD which have a clock input synchronous with
 ARM clock will not work well since the clock will change behind their backs.
 Support for notification to such devices to adjust themselves to the
 new frequency will be added in later patches. Current defconfigs keep
 CPUFreq disabled so it will not affect normal operation.

 The patch moves Async3 clock source to PLL1 so that frequency scaling
 on PLL0 does not affect those peripherals. Without this the console on UART2
 goes for a toss the moment CPUFreq kicks in.

Can you break this change of ASYNC3 modules out into a separate patch?

Also, I'd rather see this done in a function in da850.c that changes
the parents of these clocks instead of changing them statically.  This
way, when other clocks in ASYNC3 are added, this function will need to
be updated.

Maybe start with something like this (on top of this series, but not
even compile tested):

diff --git a/arch/arm/mach-davinci/clock.h b/arch/arm/mach-davinci/clock.h
index f772e6e..beb96f8 100644
--- a/arch/arm/mach-davinci/clock.h
+++ b/arch/arm/mach-davinci/clock.h
@@ -79,7 +79,7 @@ struct clk {
int (*round_rate) (struct clk *clk, unsigned long rate);
 };
 
-/* Clock flags */
+/* Clock flags: SoC-specific flags start at BIT(16) */
 #define ALWAYS_ENABLED BIT(1)
 #define CLK_PSC BIT(2)
 #define PSC_DSP BIT(3) /* PSC uses DSP domain, not ARM */
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index fe71f13..ebb90d8 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -31,6 +31,9 @@
 #include clock.h
 #include mux.h
 
+/* SoC specific clock flags */
+#define DA850_CLK_ASYNC3BIT(16)
+
 #define DA850_PLL1_BASE0x01e1a000
 #define DA850_TIMER64P2_BASE   0x01f0c000
 #define DA850_TIMER64P3_BASE   0x01f0d000

...then, in each ASYNC3 clock, set that flag.  Then add a function to
change the parents by DA8XX_CFGCHIP3_REG and changing the parent of
every clock that has the DA850_CLK_ASYNC3 flag.

This function should be able to change it back to the default setting
as well.

This way, as the other clocks in ASYNC3 are added (McASP, SPI, etc.)
all that is needed is to make sure they have the DA850_CLK_ASYNC3 flag
set.

 The OPP defintions assume clock input of 24MHz to the SoC. This is inline
 with hardcoding of input frequency in the soc.c files. At some point
 this will need to move into board dependent code as boards appear with
 different input clock.

 Tested with ondemand governer and a shell script to vary processor load.

 Note: This patch also does an off-topic change of making the JTAG id register
 definition derive from SYSCFG base address.

Even though it's trivial, this part should also be broken out into a
separate patch as it is unrelated to $SUBJECT.

 Signed-off-by: Sekhar Nori nsek...@ti.com
 ---
  arch/arm/mach-davinci/da850.c  |  146 
 +++-
  arch/arm/mach-davinci/include/mach/da8xx.h |4 +-
  2 files changed, 147 insertions(+), 3 deletions(-)

 diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
 index 4a43ae2..fe71f13 100644
 --- a/arch/arm/mach-davinci/da850.c
 +++ b/arch/arm/mach-davinci/da850.c
 @@ -15,6 +15,7 @@
  #include linux/init.h
  #include linux/clk.h
  #include linux/platform_device.h
 +#include linux/cpufreq.h
  
  #include asm/mach/map.h
  
 @@ -35,6 +36,8 @@
  #define DA850_TIMER64P3_BASE 0x01f0d000
  
  #define DA850_REF_FREQ   2400
 +static int da850_set_armrate(struct clk *clk, unsigned long rate);
 +static int da850_round_armrate(struct clk *clk, unsigned long rate);
  
  static struct pll_data pll0_data = {
   .num= 1,
 @@ -230,14 +233,14 @@ static struct clk uart0_clk = {
  
  static struct clk uart1_clk = {
   .name   = uart1,
 - .parent = pll0_sysclk2,
 + .parent = pll1_sysclk2,
   .lpsc   = DA8XX_LPSC1_UART1,
   .psc_ctlr   = 1,
  };
  
  static struct clk uart2_clk = {
   .name   = uart2,
 - .parent = pll0_sysclk2,
 + .parent = pll1_sysclk2,
   .lpsc   = DA8XX_LPSC1_UART2,
   .psc_ctlr   = 1,
  };
 @@ -276,6 +279,8 @@ static struct clk arm_clk = {
   .parent = pll0_sysclk6,
   .lpsc   = DA8XX_LPSC0_ARM,
   .flags  = ALWAYS_ENABLED,
 + .set_rate   = da850_set_armrate,
 + .round_rate = da850_round_armrate,
  };
  
  static struct clk rmii_clk = {
 @@ -601,6 +606,65 @@ static struct davinci_timer_info da850_timer_info = {
   .clocksource_id = T0_TOP,
  };
  
 +#define MAX_NUM_OPP  3
 +
 +/*
 + * Notes:
 + * According to the TRM, minimum PLLM results in max power savings.
 + * The OPP

Re: [PATCH] davinci: Add MMC/SD support for da850/omap-l138

2009-08-10 Thread Kevin Hilman

Sudhakar Rajashekhara sudhakar@ti.com writes:

 There are two instances of MMC/SD on da850/omap-l138.
 Connector for the first instance is available on the
 EVM. This patch adds support for this instance.

 This patch also adds support for card detect and write
 protect switches on da850/omap-l138 EVM.

 Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
 ---
  This patch has been tested on OMAP-L138 EVM.

  arch/arm/mach-davinci/board-da850-evm.c|   55 
 
  arch/arm/mach-davinci/da850.c  |   20 ++
  arch/arm/mach-davinci/devices-da8xx.c  |   38 +++
  arch/arm/mach-davinci/include/mach/da8xx.h |4 ++
  arch/arm/mach-davinci/include/mach/mux.h   |8 
  5 files changed, 125 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
 b/arch/arm/mach-davinci/board-da850-evm.c
 index d989346..ae4a2f0 100644
 --- a/arch/arm/mach-davinci/board-da850-evm.c
 +++ b/arch/arm/mach-davinci/board-da850-evm.c
 @@ -17,6 +17,7 @@
  #include linux/console.h
  #include linux/i2c.h
  #include linux/i2c/at24.h
 +#include linux/gpio.h
  
  #include asm/mach-types.h
  #include asm/mach/arch.h
 @@ -38,6 +39,49 @@ static struct davinci_uart_config da850_evm_uart_config 
 __initdata = {
   .enabled_uarts = 0x7,
  };
  
 +#if defined(CONFIG_MMC_DAVINCI) || defined(CONFIG_MMC_DAVINCI_MODULE)
 +static int da850_evm_mmc_get_ro(int index)
 +{
 + /* GPIO 4[1] is used for MMC/SD WP - 16 * 4 + 1 = 65 */
 + int val, status, gpio_num = 65;
 +
 + status = gpio_request(gpio_num, MMC WP\n);
 + if (status  0) {
 + printk(KERN_WARNING %s can not open GPIO %d\n, __func__,
 + gpio_num);
 + return 0;
 + }
 + gpio_direction_input(gpio_num);
 + val = gpio_get_value(gpio_num);
 + gpio_free(gpio_num);
 + return val;
 +}
 +
 +static int da850_evm_mmc_get_cd(int index)
 +{
 + /* GPIO 4[0] is used for MMC/SD WP - 16 * 4 + 0 = 64 */
 + int val, status, gpio_num = 64;
 +
 + status = gpio_request(gpio_num, MMC CD\n);
 + if (status  0) {
 + printk(KERN_WARNING %s can not open GPIO %d\n, __func__,
 + gpio_num);
 + return 0;
 + }
 + gpio_direction_input(gpio_num);
 + val = gpio_get_value(gpio_num);
 + gpio_free(gpio_num);
 + return !val;
 +}
 +
 +static struct davinci_mmc_config da850_mmc_config = {
 + .get_ro = da850_evm_mmc_get_ro,
 + .get_cd = da850_evm_mmc_get_cd,
 + .wires  = 4,
 + .version= MMC_CTLR_VERSION_2,
 +};
 +#endif
 +

Rather than do the gpio_request()/free() every time, I think you should
just #define the GPIO numbers, do the request() and gpio_direction_input()
in da850_evm_init() after you mux.

Then, the mmc_get_* funcs can simply 'return gpio_get_value(gpio);'

Kevin

  static __init void da850_evm_init(void)
  {
   struct davinci_soc_info *soc_info = davinci_soc_info;
 @@ -76,6 +120,17 @@ static __init void da850_evm_init(void)
   if (ret)
   pr_warning(da830_evm_init: watchdog registration failed: %d\n,
   ret);
 +#if defined(CONFIG_MMC_DAVINCI) || defined(CONFIG_MMC_DAVINCI_MODULE)
 + ret = da8xx_pinmux_setup(da850_mmcsd0_pins);
 + if (ret)
 + pr_warning(da850_evm_init: mmcsd0 mux setup failed: %d\n,
 + ret);
 +
 + ret = da8xx_register_mmcsd0(da850_mmc_config);
 + if (ret)
 + pr_warning(da850_evm_init: mmcsd0 registration failed: %d\n,
 + ret);
 +#endif
  
   davinci_serial_init(da850_evm_uart_config);
  
 diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
 index 4a43ae2..4b5ac24 100644
 --- a/arch/arm/mach-davinci/da850.c
 +++ b/arch/arm/mach-davinci/da850.c
 @@ -289,6 +289,12 @@ static struct clk emac_clk = {
   .lpsc   = DA8XX_LPSC1_CPGMAC,
  };
  
 +static struct clk mmcsd_clk = {
 + .name   = mmcsd,
 + .parent = pll0_sysclk2,
 + .lpsc   = DA8XX_LPSC0_MMC_SD,
 +};
 +
  static struct davinci_clk da850_clks[] = {
   CLK(NULL,   ref,  ref_clk),
   CLK(NULL,   pll0, pll0_clk),
 @@ -326,6 +332,7 @@ static struct davinci_clk da850_clks[] = {
   CLK(NULL,   arm,  arm_clk),
   CLK(NULL,   rmii, rmii_clk),
   CLK(davinci_emac.1,   NULL,   emac_clk),
 + CLK(davinci_mmc.0,NULL,   mmcsd_clk),
   CLK(NULL,   NULL,   NULL),
  };
  
 @@ -370,6 +377,13 @@ static const struct mux_config da850_pins[] = {
   MUX_CFG(DA850, MII_RXD_2,   3,  20, 15, 8,  false)
   MUX_CFG(DA850, MII_RXD_1,   3,  24, 15, 8,  false)
   MUX_CFG(DA850, MII_RXD_0,   3,  28, 15, 8,  false)

Re: [PATCH] davinci: Configure MDIO pins for EMAC

2009-08-10 Thread Kevin Hilman

Sudhakar Rajashekhara sudhakar@ti.com writes:

 Earlier patch which adds EMAC support for da850/omap-l138
 was not configuring the MDIO pins.

 Ethernet was working fine with the earlier patch, because
 the MDIO pins were configured from the boot loader. This
 patch removes that dependency.

 Also, this patch populates a member in the emac clk structure
 to say that EMAC LPSC sits on controller 1.

 Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com

Looks fine.

 ---
  This patch depends on the following patch which I have
  submitted to davinci git:
  [PATCH] davinci: Add MMC/SD support for da850/omap-l138

Either re-send based on master, or I'll have to wait for
an updated MMC/SD patch.

Kevin

  arch/arm/mach-davinci/da850.c|6 +-
  arch/arm/mach-davinci/include/mach/mux.h |2 ++
  2 files changed, 7 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
 index 4b5ac24..dc7ca1d 100644
 --- a/arch/arm/mach-davinci/da850.c
 +++ b/arch/arm/mach-davinci/da850.c
 @@ -287,6 +287,7 @@ static struct clk emac_clk = {
   .name   = emac,
   .parent = pll0_sysclk4,
   .lpsc   = DA8XX_LPSC1_CPGMAC,
 + .psc_ctlr   = 1,
  };
  
  static struct clk mmcsd_clk = {
 @@ -377,6 +378,8 @@ static const struct mux_config da850_pins[] = {
   MUX_CFG(DA850, MII_RXD_2,   3,  20, 15, 8,  false)
   MUX_CFG(DA850, MII_RXD_1,   3,  24, 15, 8,  false)
   MUX_CFG(DA850, MII_RXD_0,   3,  28, 15, 8,  false)
 + MUX_CFG(DA850, MDIO_CLK,4,  0,  15, 8,  false)
 + MUX_CFG(DA850, MDIO_D,  4,  4,  15, 8,  false)
   /* MMC/SD0 function */
   MUX_CFG(DA850, MMCSD0_DAT_0,10, 8,  15, 2,  false)
   MUX_CFG(DA850, MMCSD0_DAT_1,10, 12, 15, 2,  false)
 @@ -416,7 +419,8 @@ const short da850_cpgmac_pins[] __initdata = {
   DA850_MII_TXEN, DA850_MII_TXCLK, DA850_MII_COL, DA850_MII_TXD_3,
   DA850_MII_TXD_2, DA850_MII_TXD_1, DA850_MII_TXD_0, DA850_MII_RXER,
   DA850_MII_CRS, DA850_MII_RXCLK, DA850_MII_RXDV, DA850_MII_RXD_3,
 - DA850_MII_RXD_2, DA850_MII_RXD_1, DA850_MII_RXD_0,
 + DA850_MII_RXD_2, DA850_MII_RXD_1, DA850_MII_RXD_0, DA850_MDIO_CLK,
 + DA850_MDIO_D,
   -1
  };
  
 diff --git a/arch/arm/mach-davinci/include/mach/mux.h 
 b/arch/arm/mach-davinci/include/mach/mux.h
 index 09dbede..f5febdd 100644
 --- a/arch/arm/mach-davinci/include/mach/mux.h
 +++ b/arch/arm/mach-davinci/include/mach/mux.h
 @@ -747,6 +747,8 @@ enum davinci_da850_index {
   DA850_MII_RXD_2,
   DA850_MII_RXD_1,
   DA850_MII_RXD_0,
 + DA850_MDIO_CLK,
 + DA850_MDIO_D,
  
   /* MMC/SD0 function */
   DA850_MMCSD0_DAT_0,
 -- 
 1.5.6

 ___
 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] davinci: Add NAND flash support for DA850/OMAP-L138

2009-08-10 Thread Kevin Hilman

Sudhakar Rajashekhara sudhakar@ti.com writes:

 This patch adds platform data for the 512MB NAND Flash
 found on DA850/OMAP-L138 EVM. Currently it supports
 only 1-bit ECC.

 Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com

Looks fine.

 ---
  This patch has been tested on DA850/OMAP-L138.

  This patch depends on the following two patches which
  I have submitted to davinci git:
  [PATCH] davinci: Add MMC/SD support for da850/omap-l138
  [PATCH] davinci: Configure MDIO pins for EMAC

Again, needs rebase on master or updated MMC series.

Kevin

  arch/arm/mach-davinci/board-da850-evm.c|   92 
 
  arch/arm/mach-davinci/da850.c  |   31 +
  arch/arm/mach-davinci/include/mach/da8xx.h |3 +
  arch/arm/mach-davinci/include/mach/mux.h   |   16 +
  4 files changed, 142 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
 b/arch/arm/mach-davinci/board-da850-evm.c
 index ae4a2f0..5f3e45b 100644
 --- a/arch/arm/mach-davinci/board-da850-evm.c
 +++ b/arch/arm/mach-davinci/board-da850-evm.c
 @@ -18,6 +18,10 @@
  #include linux/i2c.h
  #include linux/i2c/at24.h
  #include linux/gpio.h
 +#include linux/platform_device.h
 +#include linux/mtd/mtd.h
 +#include linux/mtd/nand.h
 +#include linux/mtd/partitions.h
  
  #include asm/mach-types.h
  #include asm/mach/arch.h
 @@ -26,10 +30,81 @@
  #include mach/irqs.h
  #include mach/cp_intc.h
  #include mach/da8xx.h
 +#include mach/nand.h
  
  #define DA850_EVM_PHY_MASK   0x1
  #define DA850_EVM_MDIO_FREQUENCY 220 /* PHY bus frequency */
  
 +#if defined(CONFIG_MTD_NAND_DAVINCI) || 
 defined(CONFIG_MTD_NAND_DAVINCI_MODULE)
 +/* DA850/OMAP-L138 EVM includes a 512 MByte large-page NAND flash
 + * (128K blocks). It may be used instead of the (default) SPI flash
 + * to boot, using TI's tools to install the secondary boot loader
 + * (UBL) and U-Boot.
 + */
 +struct mtd_partition da850_evm_nandflash_partition[] = {
 + {
 + .name   = u-boot env,
 + .offset = 0,
 + .size   = SZ_128K,
 + .mask_flags = MTD_WRITEABLE,
 +  },
 + {
 + .name   = UBL,
 + .offset = MTDPART_OFS_APPEND,
 + .size   = SZ_128K,
 + .mask_flags = MTD_WRITEABLE,
 + },
 + {
 + .name   = u-boot,
 + .offset = MTDPART_OFS_APPEND,
 + .size   = 4 * SZ_128K,
 + .mask_flags = MTD_WRITEABLE,
 + },
 + {
 + .name   = kernel,
 + .offset = 0x20,
 + .size   = SZ_2M,
 + .mask_flags = 0,
 + },
 + {
 + .name   = filesystem,
 + .offset = MTDPART_OFS_APPEND,
 + .size   = MTDPART_SIZ_FULL,
 + .mask_flags = 0,
 + },
 +};
 +
 +static struct davinci_nand_pdata da850_evm_nandflash_data = {
 + .parts  = da850_evm_nandflash_partition,
 + .nr_parts   = ARRAY_SIZE(da850_evm_nandflash_partition),
 + .ecc_mode   = NAND_ECC_HW,
 + .options= NAND_USE_FLASH_BBT,
 +};
 +
 +static struct resource da850_evm_nandflash_resource[] = {
 + {
 + .start  = DA8XX_AEMIF_CS3_BASE,
 + .end= DA8XX_AEMIF_CS3_BASE + SZ_512K + 2 * SZ_1K - 1,
 + .flags  = IORESOURCE_MEM,
 + },
 + {
 + .start  = DA8XX_AEMIF_CTL_BASE,
 + .end= DA8XX_AEMIF_CTL_BASE + SZ_32K - 1,
 + .flags  = IORESOURCE_MEM,
 + },
 +};
 +
 +static struct platform_device da850_evm_nandflash_device = {
 + .name   = davinci_nand,
 + .id = 1,
 + .dev= {
 + .platform_data  = da850_evm_nandflash_data,
 + },
 + .num_resources  = ARRAY_SIZE(da850_evm_nandflash_resource),
 + .resource   = da850_evm_nandflash_resource,
 +};
 +#endif
 +
  static struct davinci_i2c_platform_data da850_evm_i2c_0_pdata = {
   .bus_freq   = 100,  /* kHz */
   .bus_delay  = 0,/* usec */
 @@ -39,6 +114,12 @@ static struct davinci_uart_config da850_evm_uart_config 
 __initdata = {
   .enabled_uarts = 0x7,
  };
  
 +static struct platform_device *da850_evm_devices[] __initdata = {
 +#if defined(CONFIG_MTD_NAND_DAVINCI) || 
 defined(CONFIG_MTD_NAND_DAVINCI_MODULE)
 + da850_evm_nandflash_device,
 +#endif
 +};
 +
  #if defined(CONFIG_MMC_DAVINCI) || defined(CONFIG_MMC_DAVINCI_MODULE)
  static int da850_evm_mmc_get_ro(int index)
  {
 @@ -87,6 +168,16 @@ static __init void da850_evm_init(void)
   struct davinci_soc_info *soc_info = davinci_soc_info;
   int ret;
  
 +#if defined(CONFIG_MTD_NAND_DAVINCI) || 
 defined(CONFIG_MTD_NAND_DAVINCI_MODULE)
 + ret = da8xx_pinmux_setup(da850_nand_pins);
 + if (ret)
 + pr_warning(da850_evm_init: nand mux setup

Re: [PATCH] davinci: Add NOR flash support for da850/omap-l138

2009-08-10 Thread Kevin Hilman

Sudhakar Rajashekhara sudhakar@ti.com writes:

 This patch adds platform data for the 8MB NOR flash
 found on da850/omap-l138 EVM. Both NOR and NAND can
 co-exist on da850/omap-l138 as they are using different
 chip selects.

 Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com

Mostly ok, see below.

 ---
  This patch has been tested on DA850/OMAP-L138 EVM.

  This patch depends on the following patches which
  I have submitted to davinci git:
  [PATCH] davinci: Add MMC/SD support for da850/omap-l138
  [PATCH] davinci: Configure MDIO pins for EMAC
  [PATCH] davinci: Add NAND flash support for DA850/OMAP-L138

Same as previous...

  arch/arm/mach-davinci/board-da850-evm.c|   62 
 
  arch/arm/mach-davinci/da850.c  |   51 +++
  arch/arm/mach-davinci/include/mach/da8xx.h |2 +
  arch/arm/mach-davinci/include/mach/mux.h   |   35 
  4 files changed, 150 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
 b/arch/arm/mach-davinci/board-da850-evm.c
 index da37a63..39ed364 100644
 --- a/arch/arm/mach-davinci/board-da850-evm.c
 +++ b/arch/arm/mach-davinci/board-da850-evm.c
 @@ -22,6 +22,7 @@
  #include linux/mtd/mtd.h
  #include linux/mtd/nand.h
  #include linux/mtd/partitions.h
 +#include linux/mtd/physmap.h
  
  #include asm/mach-types.h
  #include asm/mach/arch.h
 @@ -35,6 +36,41 @@
  #define DA850_EVM_PHY_MASK   0x1
  #define DA850_EVM_MDIO_FREQUENCY 220 /* PHY bus frequency */
  
 +#if defined(CONFIG_MTD_PHYSMAP) || defined(CONFIG_MTD_PHYSMAP_MODULE)
 +static struct mtd_partition da850_evm_norflash_partition[] = {
 + {
 + .name   = NOR filesystem,
 + .offset = 0,
 + .size   = MTDPART_SIZ_FULL,
 + .mask_flags = 0,
 + },
 +};
 +
 +static struct physmap_flash_data da850_evm_norflash_data = {
 + .width  = 2,
 + .parts  = da850_evm_norflash_partition,
 + .nr_parts   = ARRAY_SIZE(da850_evm_norflash_partition),
 +};
 +
 +static struct resource da850_evm_norflash_resource[] = {
 + {
 + .start  = DA8XX_AEMIF_CS2_BASE,
 + .end= DA8XX_AEMIF_CS2_BASE + SZ_32M - 1,
 + .flags  = IORESOURCE_MEM,
 + },
 +};
 +
 +static struct platform_device da850_evm_norflash_device = {
 + .name   = physmap-flash,
 + .id = 0,
 + .dev= {
 + .platform_data  = da850_evm_norflash_data,
 + },
 + .num_resources  = 1,
 + .resource   = da850_evm_norflash_resource,
 +};
 +#endif
 +
  #if defined(CONFIG_MTD_NAND_DAVINCI) || 
 defined(CONFIG_MTD_NAND_DAVINCI_MODULE)
  /* DA850/OMAP-L138 EVM includes a 512 MByte large-page NAND flash
   * (128K blocks). It may be used instead of the (default) SPI flash
 @@ -118,6 +154,9 @@ static struct platform_device *da850_evm_devices[] 
 __initdata = {
  #if defined(CONFIG_MTD_NAND_DAVINCI) || 
 defined(CONFIG_MTD_NAND_DAVINCI_MODULE)
   da850_evm_nandflash_device,
  #endif
 +#if defined(CONFIG_MTD_PHYSMAP) || defined(CONFIG_MTD_PHYSMAP_MODULE)
 + da850_evm_norflash_device,
 +#endif
  };
  
  #if defined(CONFIG_MMC_DAVINCI) || defined(CONFIG_MMC_DAVINCI_MODULE)
 @@ -163,6 +202,20 @@ static struct davinci_mmc_config da850_mmc_config = {
  };
  #endif
  
 +#if defined(CONFIG_MTD_PHYSMAP) || defined(CONFIG_MTD_PHYSMAP_MODULE)
 +static void __init da850_evm_init_nor(void)
 +{
 + void __iomem *aemif_addr;
 +
 + aemif_addr = ioremap(DA8XX_AEMIF_CTL_BASE, SZ_32K - 1);
 +
 + /* Configure data bus width of CS2 to 16 bit */
 + __raw_writel(1, aemif_addr + 0x10);
 +
 + iounmap(aemif_addr);
 +}
 +#endif

Probably don't need #ifdef here as it is __init.

  static __init void da850_evm_init(void)
  {
   struct davinci_soc_info *soc_info = davinci_soc_info;
 @@ -175,6 +228,15 @@ static __init void da850_evm_init(void)
   ret);
  #endif
  
 +#if defined(CONFIG_MTD_PHYSMAP) || defined(CONFIG_MTD_PHYSMAP_MODULE)
 + ret = da8xx_pinmux_setup(da850_nor_pins);
 + if (ret)
 + pr_warning(da850_evm_init: nor mux setup failed: %d\n,
 + ret);
 +
 + da850_evm_init_nor();
 +#endif
 +
   platform_add_devices(da850_evm_devices,
   ARRAY_SIZE(da850_evm_devices));
  
 diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
 index e0fd7fe..a4fa1d7 100644
 --- a/arch/arm/mach-davinci/da850.c
 +++ b/arch/arm/mach-davinci/da850.c
 @@ -410,6 +410,41 @@ static const struct mux_config da850_pins[] = {
   MUX_CFG(DA850, NEMA_CS_4,   7,  8,  15, 1,  false)
   MUX_CFG(DA850, NEMA_WE, 7,  16, 15, 1,  false)
   MUX_CFG(DA850, NEMA_OE, 7,  20, 15, 1,  false)
 + MUX_CFG(DA850, EMA_A_0, 12, 28, 15, 1,  false)
 +

Re: [PATCH v5] davinci: fb: Frame Buffer driver for TI DA8xx/OMAP-L1xx

2009-08-10 Thread Kevin Hilman

[ distribution trimmed to Davinci only. ]

Sudhakar Rajashekhara sudhakar@ti.com writes:

 Adds LCD controller (LCDC) driver for TI's DA8xx/OMAP-L1xx
 architecture. LCDC specifications can be found at
 http://www.ti.com/litv/pdf/sprufm0a.

 LCDC on DA8xx consists of two independent controllers, the
 Raster Controller and the LCD Interface Display Driver (LIDD)
 controller. LIDD further supports character and graphic displays.

 This patch adds support for the graphic display (Sharp LQ035Q3DG01)
 found on the DA830 based EVM. The EVM details can be found at:
 http://support.spectrumdigital.com/boards/dskda830/revc/.

 Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
 Signed-off-by: Pavel Kiryukhin pkiryuk...@ru.mvista.com
 Signed-off-by: Steve Chen sc...@mvista.com
 Acked-by: Krzysztof Helt krzysztof...@wp.pl

As of 06 Aug, looks like Andrew has this in -mm.  
Pulling into DaVinci git while awaiting merge.

Sudhakar, do you have platform changes also for this?  
You should submit those ASAP so I can queue them up for the next
merge window as well.

Kevin

 ---
  This patch applies to Linus's Kernel tree.

  Following are the changes since the previous version(v4):
  a. An if loop check while returning from lcd_disable_raster()
 function has been removed.
  b. invert_pxl_clock variable has been renamed as invert_pxl_clk
 and moved from lcd_ctrl_config structure in include/video/da8xx-fb.h
 file to da8xx_panel structure in drivers/video/da8xx-fb.c file.
 Appropriate changes in source code as a result of moving this
 variable has also been done. 

  drivers/video/Kconfig|   11 +
  drivers/video/Makefile   |1 +
  drivers/video/da8xx-fb.c |  910 
 ++
  include/video/da8xx-fb.h |  103 ++
  4 files changed, 1025 insertions(+), 0 deletions(-)
  create mode 100644 drivers/video/da8xx-fb.c
  create mode 100644 include/video/da8xx-fb.h

 diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
 index 3b54b39..d2f17af 100644
 --- a/drivers/video/Kconfig
 +++ b/drivers/video/Kconfig
 @@ -2039,6 +2039,17 @@ config FB_SH7760
 and 8, 15 or 16 bpp color; 90 degrees clockwise display rotation for
 panels = 320 pixel horizontal resolution.
  
 +config FB_DA8XX
 + tristate DA8xx/OMAP-L1xx Framebuffer support
 + depends on FB  ARCH_DAVINCI_DA8XX
 + select FB_CFB_FILLRECT
 + select FB_CFB_COPYAREA
 + select FB_CFB_IMAGEBLIT
 + ---help---
 +   This is the frame buffer device driver for the TI LCD controller
 +   found on DA8xx/OMAP-L1xx SoCs.
 +   If unsure, say N.
 +
  config FB_VIRTUAL
   tristate Virtual Frame Buffer support (ONLY FOR TESTING!)
   depends on FB
 diff --git a/drivers/video/Makefile b/drivers/video/Makefile
 index 01a819f..288d9b0 100644
 --- a/drivers/video/Makefile
 +++ b/drivers/video/Makefile
 @@ -136,6 +136,7 @@ obj-$(CONFIG_FB_OF)   += offb.o
  obj-$(CONFIG_FB_BF54X_LQ043)   += bf54x-lq043fb.o
  obj-$(CONFIG_FB_BFIN_T350MCQB) += bfin-t350mcqb-fb.o
  obj-$(CONFIG_FB_MX3)   += mx3fb.o
 +obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o
  
  # the test framebuffer is last
  obj-$(CONFIG_FB_VIRTUAL)  += vfb.o
 diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
 new file mode 100644
 index 000..04de744
 --- /dev/null
 +++ b/drivers/video/da8xx-fb.c
 @@ -0,0 +1,910 @@
 +/*
 + * Copyright (C) 2008-2009 MontaVista Software Inc.
 + * Copyright (C) 2008-2009 Texas Instruments Inc
 + *
 + * Based on the LCD driver for TI Avalanche processors written by
 + * Ajay Singh and Shalom Hai.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option)any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program; if not, write to the Free Software
 + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
 + */
 +#include linux/module.h
 +#include linux/kernel.h
 +#include linux/fb.h
 +#include linux/dma-mapping.h
 +#include linux/device.h
 +#include linux/platform_device.h
 +#include linux/uaccess.h
 +#include linux/device.h
 +#include linux/interrupt.h
 +#include linux/clk.h
 +#include video/da8xx-fb.h
 +
 +#define DRIVER_NAME da8xx_lcdc
 +
 +/* LCD Status Register */
 +#define LCD_END_OF_FRAME0BIT(8)
 +#define LCD_FIFO_UNDERFLOW   BIT(5)
 +#define LCD_SYNC_LOSTBIT(2)
 +
 +/* LCD DMA Control Register */
 +#define LCD_DMA_BURST_SIZE(x)((x)  4)

Re: [alsa-devel] [PATCH 5/5] ASoC: DaVinci: pcm, fix underruns by using sram

2009-08-10 Thread Troy Kisky

Mark Brown wrote:
 On Thu, Aug 06, 2009 at 07:05:54PM -0700, Troy Kisky wrote:
 
 This is allocated too late for the ensure that buffer size is a multiple of 
 period size
 constraint.
 
 I have a patch after fixing other feedback.
 
 It looks good to me - I've no issues with the patch except for the one I
 mentioned last time about considering ignoring the data in SRAM when
 reporting the current position but I'm happy either way.  The patch will
 run into the cross tree issues with the platform data like the channel
 combining one, probably best to submit patches against Kevin's tree for
 now (or wait until after the merge window).
 
 Have you tested with PulseAudio?  If not it'd be worth giving it a spin
 - it's one of the more demanding applications.
 
I haven't tested with PulseAudio, and I don't have time to look into it 
currently.
Any volunteers?

On question I had concerns davinci_pcm_hardware. It is currently for both 
playback
and capture. Since allocate_sram contains 
davinci_pcm_hardware.period_bytes_max = size;,
should I change davinci_pcm_hardware to playback_pcm_hardware, 
capture_pcm_hardware?



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

RE: webcam h264 dm6467

2009-08-10 Thread sureshs

Yes! it is possible. We used TI H264 encoder.

Regards,
Suresh .S

  -Original Message-
  From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com]on Behalf Of
anis monser
  Sent: Monday, August 10, 2009 6:43 PM
  To: davinci-linux-open-source@linux.davincidsp.com
  Subject: webcam h264 dm6467


  hello everybody

  I want to encode with h264 on dm6467 an input video witch captured with a
webcam.

  is it possible ??

  If not tell me please the reason

  I can’t find any information in the web

  thanks



--
  Avec Windows Live, vous organisez, retouchez et partagez vos photos.

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

Dynamic resolution in VPIF

2009-08-10 Thread saravanan s

Hi,

 

We are using VPIF driver in our video application (DM6467) which captures
RAW video data from CMOS sensor. We have configured the VPIF driver for
1280x1024 resolution which is the maximum resolution of CMOS sensor. But we
can change the height and width of the CMOS output by changing the
corresponding CMOS register values. Here I need your input to dynamically
change the VPIF resolution.

 

Thanks,

Saravanan S 

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

RE: [PATCH] davinci: Add NOR flash support for da850/omap-l138

2009-08-10 Thread Sudhakar Rajashekhara

On Tue, Aug 11, 2009 at 04:51:56, Kevin Hilman wrote:
 Sudhakar Rajashekhara sudhakar@ti.com writes:
 
  This patch adds platform data for the 8MB NOR flash
  found on da850/omap-l138 EVM. Both NOR and NAND can
  co-exist on da850/omap-l138 as they are using different
  chip selects.
 
  Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
 
 Mostly ok, see below.
 
  ---
   This patch has been tested on DA850/OMAP-L138 EVM.
 
   This patch depends on the following patches which
   I have submitted to davinci git:
   [PATCH] davinci: Add MMC/SD support for da850/omap-l138
   [PATCH] davinci: Configure MDIO pins for EMAC
   [PATCH] davinci: Add NAND flash support for DA850/OMAP-L138
 
 Same as previous...
 

I'll re-submit the above patches and this patch with your review
comments incorporated.

Regards, Sudhakar


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

insmod error

2009-08-10 Thread Jaya krishnan

I am  getting  the  following error while inserting dsplinkk.ko

insmod: cannot mmap `dsplinkk.ko': Invalid argument

I am using  a  DM6467 EVM and  my file  system is  ramdisk  based.
Linux  version is  2.6.10_mvl401-PSP_01_30_00_060

Any  clues?

Jayakrishnan

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

[PATCH v2] davinci: Configure MDIO pins for EMAC

2009-08-10 Thread Sudhakar Rajashekhara

Earlier patch which adds EMAC support for da850/omap-l138
was not configuring the MDIO pins.

Ethernet was working fine with the earlier patch, because
the MDIO pins were configured from the boot loader. This
patch removes that dependency.

Also, this patch populates a member in the emac clk structure
to say that EMAC LPSC sits on controller 1.

Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
 No changes from the previous version, except that the patch
 has been modified to apply on master branch.

 arch/arm/mach-davinci/da850.c|6 +-
 arch/arm/mach-davinci/include/mach/mux.h |2 ++
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 4a43ae2..22205a3 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -287,6 +287,7 @@ static struct clk emac_clk = {
.name   = emac,
.parent = pll0_sysclk4,
.lpsc   = DA8XX_LPSC1_CPGMAC,
+   .psc_ctlr   = 1,
 };
 
 static struct davinci_clk da850_clks[] = {
@@ -370,6 +371,8 @@ static const struct mux_config da850_pins[] = {
MUX_CFG(DA850, MII_RXD_2,   3,  20, 15, 8,  false)
MUX_CFG(DA850, MII_RXD_1,   3,  24, 15, 8,  false)
MUX_CFG(DA850, MII_RXD_0,   3,  28, 15, 8,  false)
+   MUX_CFG(DA850, MDIO_CLK,4,  0,  15, 8,  false)
+   MUX_CFG(DA850, MDIO_D,  4,  4,  15, 8,  false)
 #endif
 };
 
@@ -402,7 +405,8 @@ const short da850_cpgmac_pins[] __initdata = {
DA850_MII_TXEN, DA850_MII_TXCLK, DA850_MII_COL, DA850_MII_TXD_3,
DA850_MII_TXD_2, DA850_MII_TXD_1, DA850_MII_TXD_0, DA850_MII_RXER,
DA850_MII_CRS, DA850_MII_RXCLK, DA850_MII_RXDV, DA850_MII_RXD_3,
-   DA850_MII_RXD_2, DA850_MII_RXD_1, DA850_MII_RXD_0,
+   DA850_MII_RXD_2, DA850_MII_RXD_1, DA850_MII_RXD_0, DA850_MDIO_CLK,
+   DA850_MDIO_D,
-1
 };
 
diff --git a/arch/arm/mach-davinci/include/mach/mux.h 
b/arch/arm/mach-davinci/include/mach/mux.h
index a676b2f..8676680 100644
--- a/arch/arm/mach-davinci/include/mach/mux.h
+++ b/arch/arm/mach-davinci/include/mach/mux.h
@@ -748,6 +748,8 @@ enum davinci_da850_index {
DA850_MII_RXD_2,
DA850_MII_RXD_1,
DA850_MII_RXD_0,
+   DA850_MDIO_CLK,
+   DA850_MDIO_D,
 };
 
 #ifdef CONFIG_DAVINCI_MUX
-- 
1.5.6

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

Re: saDisplay + DM6467 showing black an white image in SD Display

how can i add spi1 or spi2 device in the kernel linux2.6.10 of dm355?

webcam h264 dm6467

RE: [PATCH v4 3/3] mtd-nand: DaVinci: Add 4-bit ECC support for large page NAND chips

RE: linux-next on V4L-DVB repository not booting up on DM6467 evm

Re: linux-next on V4L-DVB repository not booting up on DM6467 evm

Re: [PATCH] V4L/DVB: dm646x: fix DMA_nnBIT_MASK

Re: [PATCH 2/3] cpufreq: add generic CPUFreq driver for DaVinci

Re: [PATCH 1/3] davinci: clock framework updates for CPUFreq support

Re: [PATCH 3/3] davinci: DA850/OMAP-L138: add CPUFreq support

Re: [PATCH] davinci: Add MMC/SD support for da850/omap-l138

Re: [PATCH] davinci: Configure MDIO pins for EMAC

Re: [PATCH] davinci: Add NAND flash support for DA850/OMAP-L138

Re: [PATCH] davinci: Add NOR flash support for da850/omap-l138

Re: [PATCH v5] davinci: fb: Frame Buffer driver for TI DA8xx/OMAP-L1xx

Re: [alsa-devel] [PATCH 5/5] ASoC: DaVinci: pcm, fix underruns by using sram

RE: webcam h264 dm6467

Dynamic resolution in VPIF

RE: [PATCH] davinci: Add NOR flash support for da850/omap-l138

insmod error

[PATCH v2] davinci: Configure MDIO pins for EMAC

21 matches

Site Navigation

Mail list logo

Footer information