HI all:
The DM9000 network phy chip on my DM355 board has some issues, during our
testing, we found the system always hung up by ksoftirqd/0 which consumed 98%
CPU, then I do some modifications at "dm9000_start_xmit()", use
"spin_lock_irqsave(&db->lock, irq_flag);", spin_unlock_irqrestor
Caglar,
Are you seeing this OOPs when you do Ctrl-C? Since you say that mutex is
deleted, which means that some thread has done the cleanup (Mutex got deleted).
Please provide more details regarding the scenario.
Regards,
Samir
-Original Message-
From: davinci-linux-open-source-bou
Hi.. This is Billy Jang.
I just give a simple comment for you.
This message occurred in the absent of NAND flash in the board.
If you remove the flash memory in the EVM board, you can get the same
message.
Please check your hardware schematic and the component value. etc.
In these days,
Hi, all,
My board can boot from my nand flash NAND01GR3B2B (ST 's product) using
U-boot 1.2.0, but When the board is starting
linux kernel, the kernel should scan the bad block and the kernel print the
messages:
NAND device: Manufacturer ID: 0x20, Chip ID: 0xa1 (ST Micro NAND 128MiB 1,8V
8-bit)
Sc
Sergei Shtylyov writes:
> Kevin Hilman wrote:
>
>> 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 fav
Sergei Shtylyov writes:
> Kevin Hilman wrote:
>
[...]
>> I guess the primary concern is performance, and my main point is that
>> I'm OK with the cost of a few extra instructions per interrupt if I can
>> get a single binary for multiple devices.
>
>As I've pointed out you can't get full fea
Sergei Shtylyov writes:
> Hello.
>
> Russell King wrote:
>
>>>Therefore, my proposal is to leave it in arch/arm/mach-davinci/ until
>>>there is need to reuse it elsewhere.
>
>> Sounds good to me. Just give it a sane config symbol, and then moving
>> it elsewhere in the tree shouldn't be too prob
Hello, I wrote:
Currently, the davinci code uses a fixed base address for the interrupt
controller. Change this so the the base address is determined at
runtime to support some new SoC that will be added. Use the SoC
infrastructure to pass the base address to the common code and
then put the a
Kevin Hilman wrote:
Currently, the davinci code uses a fixed base address for the interrupt
controller. Change this so the the base address is determined at
runtime to support some new SoC that will be added. Use the SoC
infrastructure to pass the base address to the common code and
then put t
Mark A. Greer wrote:
static void dm355_psc_mux(unsigned int id)
{
u32 tmp;
+ void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
OMAP-L137 has a different base, so this should've better been static...
I already have a patch the puts the base in davinci_soc_info
On Wed, Mar 11, 2009 at 03:03:35PM +0300, Sergei Shtylyov wrote:
> Kevin Hilman wrote:
>> static void dm355_psc_mux(unsigned int id)
>> {
>> u32 tmp;
>> +void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
>
>OMAP-L137 has a different base, so this should've better been
Hello.
David Brownell wrote:
+ .mux_base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE),
Surely it should be called "system_base" or somesuch;
it holds more than just MUX registers...
On OMAP-L137, the piece of h/w incorporates PINMUX registers is called
boot configuration contro
Add support for Texas Instuments Common Platform Interrupt Controller
(cp_intc) used on DA830/OMAP-L137.
---
As DA830/OMAP-L137 code is going to reside in arch/arm/mach-davinci/, I had to
place the code into this directory by the popular demand, despite cp_intc not
really being arch-specific...
S
Mark A. Greer wrote:
Factor out the common SoC init code and create some infrastructure
to allow easy adding of hooks to SoC-specific data in future patches.
Frankly speaking, the big win is not obvious to me. The current scheme
looks good enought already...
WBR, Sergei
Yes, you are right, I changed to another terminal and can see them all as
below.
/proc/net# cat ./emac_rfc2665_stats
ifSpeed: 1
dot3StatsDuplexStatus : 3
ifAdminStatus : 1
ifOperStatus : 1
ifLastChange
Kevin Hilman wrote:
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 + io[read|write]*.
Hello.
Russell King wrote:
Therefore, my proposal is to leave it in arch/arm/mach-davinci/ until
there is need to reuse it elsewhere.
Sounds good to me. Just give it a sane config symbol, and then moving
it elsewhere in the tree shouldn't be too problematical.
OK, will CONFIG_TI_CP_INT
> >> The DaVinci ASoC code is indeed in mainline, but not all of the
> >> DaVinci core (in this case the pin mux) is yet in mainline. I will be
> >> pushing it during the next merge window.
> >
> > That doesn't really answer my question.
> >
> > I can see that David Brownell pushed a patch to the
Venkatachala,
With the LSP2.0/MVL 2.6.18 kernel, you can use amixer to adjust the
volume of the mixer and test with arecord/aplay. ALSA also provides
full OSS emulation which can be enabled via kernel config.
Regards,
Steve
On Wed, 2009-03-11 at 10:58 +0530, Nori, Sekhar wrote:
> Hi,
>
> You
Hi,All,
I want to know if the Davinci DM6446 support the MCP NAND for booting from
the nand flash or not.
For my first version board, my nand flash is ST 's NAND01GR3B2B, which has
the 8-Bit width organization. and my boss
tell me that he want to use the Numonyx 's nand flash NAND01GR4B2C in my
Hi
Does anyone change the PHY on u-boot or work with the SMSC LAN8700i PHY
Ethernet transceiver?
I work with the Davinci chip DM6441.
I am developing a board similar to the EVM6446 evaluation kit and I
replace the
Intel LXT971A PHY by SMSC LAN8700i
Segal Eran
21 matches
Mail list logo
