Hi,
The problem is with gateway ip.I modified and its working.
changed the gw of DM6446.
Thank u
On 4/22/09, Balagopalakrishnan, Anand wrote:
>
> There could be several reasons:
>
>
>
>1. Does the EVM network configuration contain the correct gateway IP?
>2. Is the correct DNS server
On Tuesday 21 April 2009, weiji...@mail.ustc.edu.cn wrote:
> Then should you mean gpio_to_irq(10) == IRQ_GPIOBNK0 ??
No. Go look at the code. It uses the IRQ chaining logic
in genirq ... IRQ_GPIOBNK0 comes in, and the handler sorts
things out and dispatches it gpio_to_irq(10) ... == 74 or so
There could be several reasons:
1. Does the EVM network configuration contain the correct gateway IP?
2. Is the correct DNS server configured? If not, this needs to be added as
part of DHCP options or in the static IP configuration.
3. If you have the EVM inside the corporate network, the
David,
Thanks for your reply..
Then should you mean gpio_to_irq(10) == IRQ_GPIOBNK0 ??
Actually, if I request_irq(gpio_to_irq(10)...) will failed because the irq
number is much bigger than arm interrupt max number--64.
ÔÚÄúµÄÀ´ÐÅÖÐÔø¾Ìáµ½:
>From: David Brownell
>Reply-To:
>To: weij
On Tuesday 21 April 2009, Wei Jiang wrote:
> In SPRUE25-GPIO.pdf Page13, the arm side gpio interrupt should begin at 48.
Not really ... those are only for eight of the GPIO interrupts;
you can't use them for GPIO #10, for example.
If you request_irq(gpio_to_irq(6), ...) it goes through the
GPIO b
David,
Thanks for your reply.
In SPRUE25-GPIO.pdf, Table.2 of Page13. The arm side gpio interrupt base
shoule be 48.
For example, IRQ_GPIO6 is defined as 54 in "irqs.h" but the result of
gpio_to_irq(6) is "64+6". I think they should be same.
ÔÚÄúµÄÀ´ÐÅÖÐÔø¾Ìáµ½:
>From: David Browne
On Tuesday 21 April 2009, Mark A. Greer wrote:
> Should this go to the usb community?
Yes; done.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-s
On Tuesday 21 April 2009, weiji...@mail.ustc.edu.cn wrote:
> In Mv linux kernel, gpio_to_irq funxtions is defined as below:
> static inline int gpio_to_irq(unsigned gpio)
> {
> return DAVINCI_N_AINTC_IRQ + gpio;
> }
>
> But DAVINCI_N_AINTC_IRQ is defined as "64" which is the
> dsp side irq
From: David Brownell
Minimal support for the 4-bit ECC engine found on DM355, DM365,
DA830/OMAP-L137, and similar recent DaVinci-family chips.
This is limited to small-page flash for now; there are some page
layout issues for large page chips. Note that most boards using
this engine (like the D
From: David Brownell
Make the DaVinci NAND driver require platform_data with
board-specific configuration. We can't actually do any
kind of sane job of configuring it otherwise.
Also fix the comment about picking the "best" ECC mode.
We can't do those any more; that relied on knowing what kind
In Mv linux kernel, gpio_to_irq funxtions is defined as below:
static inline int gpio_to_irq(unsigned gpio)
{
return DAVINCI_N_AINTC_IRQ + gpio;
}
But DAVINCI_N_AINTC_IRQ is defined as "64" which is the dsp side irq start
number,
and I think it should be "48" with the arm side.Is this a bu
From: Mark A. Greer
Add #ifndef to musb header file to prevent multiple inclusions.
Signed-off-by: Mark A. Greer
---
Should this go to the usb community?
include/linux/usb/musb.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/musb.h b/include/li
Hi,
I have DM6446 Linux Kernel.
I want to add ntp client to DM6446.
In the command prompt of DM6446 if i give ping yahoo.com then i get
"Hostname Look up failure"
When i connect to NTP server i am getting the same error message.
ntpclient -s -h pool.ntp.org..
Any kernel options i need to co
On Tue, Apr 21, 2009 at 05:04:30PM -0700, Mark A. Greer wrote:
> From: Mark A. Greer
>
> The offset for the compare register used by the davinci
> time code are passed in via the cmp_off member of the
> 'davinci_timer_instance' structure. Therefore, the
> offset defined in time.c are not necessa
On Tue, Apr 21, 2009 at 05:05:14PM -0700, Mark A. Greer wrote:
> From: Mark A. Greer
>
> The da830/omap l137 is a new SoC from TI that is similar
> to the davinci line. Since its so similar to davinci,
> put the support for the da830 in the same directory as
> the davinci code.
I meant to add a
From: Mark A. Greer
Add support for the DA830/OMAP-L137 Evaluation Module (EVM
from TI. The EVM has User Interface (UI) and Audio cards
that can be connected that contain various devices.
Support for those devices and ones on the EVM will be
added in subsequent patches.
Signed-off-by: Mark A. G
From: Mark A. Greer
The offset for the compare register used by the davinci
time code are passed in via the cmp_off member of the
'davinci_timer_instance' structure. Therefore, the
offset defined in time.c are not necessary.
Signed-off-by: Mark A. Greer
---
arch/arm/mach-davinci/time.c | 10
Russell King - ARM Linux writes:
> On Tue, Apr 21, 2009 at 07:30:03AM -0700, Kevin Hilman wrote:
>> Russell King - ARM Linux writes:
>>
>> > On Wed, Apr 15, 2009 at 10:38:13AM -0500, Kevin Hilman wrote:
>> >> + sprintf(name, "uart%d", i);
>> >> + uart_clk = clk_get(dev, name);
>
David Brownell writes:
> On Tuesday 21 April 2009, Kevin Hilman wrote:
>> Russell King - ARM Linux writes:
>>
>> > On Wed, Apr 15, 2009 at 10:38:07AM -0500, Kevin Hilman wrote:
>> >> @@ -343,6 +353,14 @@ struct sys_timer davinci_timer = {
>> >> void davinci_watchdog_reset(void) {
>> >> u32 t
David Brownell writes:
> On Tuesday 21 April 2009, Kevin Hilman wrote:
>> Russell King - ARM Linux writes:
>>
>> > On Wed, Apr 15, 2009 at 10:38:07AM -0500, Kevin Hilman wrote:
>> >> @@ -343,6 +353,14 @@ struct sys_timer davinci_timer = {
>> >> void davinci_watchdog_reset(void) {
>> >> u32 t
Russell King - ARM Linux writes:
> On Tue, Apr 21, 2009 at 07:30:03AM -0700, Kevin Hilman wrote:
>> Russell King - ARM Linux writes:
>>
>> > On Wed, Apr 15, 2009 at 10:38:13AM -0500, Kevin Hilman wrote:
>> >> + sprintf(name, "uart%d", i);
>> >> + uart_clk = clk_get(dev, name);
>
On Tuesday 21 April 2009, Kevin Hilman wrote:
> Russell King - ARM Linux writes:
>
> > On Wed, Apr 15, 2009 at 10:38:07AM -0500, Kevin Hilman wrote:
> >> @@ -343,6 +353,14 @@ struct sys_timer davinci_timer = {
> >> void davinci_watchdog_reset(void) {
> >>u32 tgcr, wdtcr;
> >>void __iomem
Rework DM644x code into SoC specific and board specific parts.
This is also to generalize the structure a bit so it's easier to add
support for new SoCs in the DaVinci family.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-davinci/Kconfig |9 +-
arch/arm/mach-davinci/Make
From: s-paul...@ti.com
Adding IRQ defintions for DaVinci DM355 and default interrupt
priorities for DM355
Signed-off-by: Sandeep Paulraj
Signed-off-by: Kevin Hilman
---
arch/arm/mach-davinci/include/mach/irqs.h | 51 ++
arch/arm/mach-davinci/irq.c | 67 ++
Update MUX support to be more general and useful across multiple
SoCs in the DaVinci family.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-davinci/Kconfig| 26
arch/arm/mach-davinci/Makefile |4 +-
arch/arm/mach-davinci/devices.c |5 +
arch/arm/mach-
Rename DM6446 EVM board file, no functional changes. Code is updated
and reworked in following patch.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-davinci/board-dm644x-evm.c | 440 ++
arch/arm/mach-davinci/board-evm.c| 440 --
2
From: David Brownell
Update NAND partitioning for the dm6446 evm, unmasking the hidden
data at the beginning and letting the kernel be updated from Linux.
- This is boot-compatible with TI's software (U-Boot 1.20 and both
the 2.6.10 and 2.6.18 kernels), in terms of startup and loading
ker
From: David Brownell
Update the DaVinci GPIO code to work better on non-dm6446 parts,
notably the dm355:
- Only handle the number of GPIOs the chip actually has. So
for example on dm6467, GPIO-42 is the last GPIO, and trying
to use GPIO-43 now fails cleanly; or GPIO-72 on dm6446.
- Ena
From: Sudhakar Rajashekhara
Signed-off-by: Sudhakar Rajashekhara
Signed-off-by: Kevin Hilman
---
arch/arm/mach-davinci/include/mach/irqs.h | 52 ++-
arch/arm/mach-davinci/irq.c | 83 +++--
2 files changed, 129 insertions(+), 6 deletions
Original code for 2.6.10 and 2.6.28 series done by Texas Instruments
and MontaVista, but major updates and rework done by Troy Kisky and
David Brownell.
Cc: Sergei Shtylyov
Cc: Sudhakar Rajashekhara
Cc: Troy Kisky
Cc: David Brownell
Signed-off-by: Kevin Hilman
---
arch/arm/mach-davinci/Makef
Signed-off-by: Kevin Hilman
---
arch/arm/Kconfig |1 +
arch/arm/configs/davinci_all_defconfig | 1784
2 files changed, 1785 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/configs/davinci_all_defconfig
diff --git a/arch/arm/Kc
Add arch-specific ioremap() which uses any existing static mappings in
place of doing a new mapping. From now on, drivers should always use
ioremap() instead of IO_ADDRESS().
In addition, remove the davinci_[read|write]* macros in favor of using
ioremap.
Signed-off-by: Kevin Hilman
---
arch/ar
Use clock framework instead of hard-coded CLOCK_TICK_RATE for
determining timer tick frequencies.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-davinci/time.c | 25 ++---
1 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-davinci/time.c b/arch/arm
This is a significant rework of the low-level clock, PLL and Power
Sleep Controller (PSC) implementation for the DaVinci family. The
primary goal is to have better modeling if the hardware clocks and
features with the aim of DVFS functionality.
Highlights:
- model PLLs and all PLL-derived clocks
Signed-off-by: Kevin Hilman
---
arch/arm/mach-davinci/include/mach/serial.h | 21 +-
arch/arm/mach-davinci/serial.c | 95 ++-
2 files changed, 96 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/serial.h
b/arch/arm/mach-
From: Mark A. Greer
Clear any set bits in the 'NEXT' field of the MDCTL register in the
Power and Sleep Controller (PSC) before setting any new bits.
This also allows some minor cleanup by removing some no longer
needed lines of code.
Signed-off-by: Mark A. Greer
Signed-off-by: Kevin Hilman
--
Updataded from v1:
- fixed Russell's comments
- added another NAND patch from David Brownell (patch 15)
This series is to push the core kernel code from the DaVinci git tree
into mainline. Many of the drivers are making their way via subsystem
trees but the core code is long out of sync.
This s
Signed-off-by: Kevin Hilman
---
arch/arm/mach-davinci/id.c | 29 ++--
arch/arm/mach-davinci/include/mach/cputype.h | 49 ++
2 files changed, 75 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-davinci/include/mach/cputype.h
Russell King - ARM Linux writes:
> On Wed, Apr 15, 2009 at 10:38:13AM -0500, Kevin Hilman wrote:
>> +sprintf(name, "uart%d", i);
>> +uart_clk = clk_get(dev, name);
>> +p->uartclk = clk_get_rate(uart_clk);
>> +if (IS_ERR(uart_clk))
>
> Umm, isn't thi
Obviously Linux *is* Open Source.
But I personally find a bit exaggerated to say that the survey is
useless just because of how this specific question is posed:
"Which OS are you using? MV Linux / Open Source Linux / WinCE / Other"
since this reflects what is the Os landscape availability for
Russell King - ARM Linux writes:
> On Wed, Apr 15, 2009 at 10:38:07AM -0500, Kevin Hilman wrote:
>> @@ -343,6 +353,14 @@ struct sys_timer davinci_timer = {
>> void davinci_watchdog_reset(void) {
>> u32 tgcr, wdtcr;
>> void __iomem *base = IO_ADDRESS(DAVINCI_WDOG_BASE);
>> +struct d
> >
> > This required by SD controller as suggested by IP designer. Please
> > look at SD controller spec at http://www.ti.com/litv/pdf/sprue30d .
> > Please check section 3.2/3.6 and point no 11/10 in the controller spec.
>
> In this case the spec says in a note in 2.7.2 that priming
> the fifo i
On Tuesday 21 April 2009, Sergei Shtylyov wrote:
> David Brownell wrote:
>
> > Fix UDMA throughput bug: tCYC averages t2CYCTYP/2, but the code
> > previously assumed it was the same as t2CYCTYP.
>
> Wow, thanks for finding it!
> IIUC however, this should have only affected UDMA writes, n
David Brownell wrote:
Fix UDMA throughput bug: tCYC averages t2CYCTYP/2, but the code
previously assumed it was the same as t2CYCTYP.
Wow, thanks for finding it!
IIUC however, this should have only affected UDMA writes, not reads
because on reads the device controls the strobe timing.
On 21-04-09 09:53, Leo DaVinci wrote:
Koen,
The point was that when you say:
Which OS do you use:
[ ] Foo linux
[ ] Bar linux
[ ] Open Source linux
[ ] QNX
[ ] WinCE
And ask people to check a box your survey becomes useless. The question
forces people to aknowledge a *false* presumption t
On Fri, Apr 17, 2009 at 10:22 PM, Kevin Hilman
wrote:
> Jorge Luis Zapata Muga writes:
>
>> This series of patches add support for the Neuros Technologies OSD2
>> board (http://wiki.neurostechnology.com/index.php/OSD_2.0_HD). It is a
>> multimedia player/recorder based on DM6446.
>
> For the most
On Fri, Apr 17, 2009 at 10:10 PM, Kevin Hilman
wrote:
> Jorge Luis Zapata Muga writes:
>
>> This series of patches add support for the Neuros Technologies OSD2
>> board (http://wiki.neurostechnology.com/index.php/OSD_2.0_HD). It is a
>> multimedia player/recorder based on DM6446.
>>
>> Sorry for
can not get any images on LCD.
Can anybody please let me know, what I am missing here with the LCD
interface?
Thanks!
------ next part --
An HTML attachment was scrubbed...
URL:
http://linux.omap.com/pipermail/davinci-linux-open-source/attachments/20090421/a556458d/attachm
You probably need to add code to support the initialisation of the
LCD, and ensure other parts are set up correctly.
What LCD are you using, How is it attached
Its likely that the LCD panel will need configuring through an SPI link perhaps.
Setting ch0_output=LCD is only going to switch the
Koen,
the Linux used / recommended for DaVinci products is a commercial
offering from MontaVista (MV pro 4.x or 5.x).
You can find some details about it on the MV website
http://www.mvista.com/product_detail_pro.php
or from the product folder of the DVSPB (
http://focus.ti.com/docs/toolsw/folder
50 matches
Mail list logo
