-----Messaggio originale-----
Da:
davinci-linux-open-source-bounces+erasmo.punzo=alice...@linux.davincidsp.com
[mailto:davinci-linux-open-source-bounces+erasmo.punzo=alice...@linux.davinc
idsp.com] Per conto di
[email protected]
Inviato: mercoledì 13 maggio 2009 15.42
A: [email protected]
Oggetto: Davinci-linux-open-source Digest, Vol 41, Issue 62
Send Davinci-linux-open-source mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Davinci-linux-open-source digest..."
Today's Topics:
1. about cocurrent Tx/Rx issue using USB on DM355 (Jeff)
2. Re: multiple nand on dm355 (Steve Chen)
3. Re: I can't boot linux2.6.18 uImage in dm355 (Steve Chen)
4. [PATCH] ASoC: Correct the resource structure assignment
(Chaithrika U S)
5. RE: I can't boot linux2.6.18 uImage in dm355 (Maupin, Chase)
6. RE: [PATCH 1/7] VPFE capture driver for DM355 and DM6446
(Karicheri, Muralidharan)
----------------------------------------------------------------------
Message: 1
Date: Wed, 13 May 2009 18:58:59 +0800
From: "Jeff" <[email protected]>
Subject: about cocurrent Tx/Rx issue using USB on DM355
To: "Davinci-Linux-Source"
<[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
All,
I used MVL 2.6.18 kernel on DM355. When I read / write usb disk
simultaneously, I got some errors as below:
"
usb 1-1: reset high speed USB device using musb_hdrc and address 5
musb_host_rx 1557: RX1 dma busy, csr 2020
usb 1-1: reset high speed USB device using musb_hdrc and address 5
usb 1-1: reset high speed USB device using musb_hdrc and address 5
usb 1-1: reset high speed USB device using musb_hdrc and address 5
usb 1-1: reset high speed USB device using musb_hdrc and address 5
sd 3:0:0:0: scsi: Device offlined - not ready after error recovery
sd 3:0:0:0: SCSI error: return code = 0x00050000
end_request: I/O error, dev sda, sector 6365456
sd 3:0:0:0: rejecting I/O to offline device
sd 3:0:0:0: SCSI error: return code = 0x00010000
end_request: I/O error, dev sda, sector 6365696
sd 3:0:0:0: rejecting I/O to offline device
sd 3:0:0:0: rejecting I/O to offline device
FAT: FAT read failed (blocknr 7022)
sd 3:0:0:0: rejecting I/O to offline device
sd 3:0:0:0: rejecting I/O to offline device
"
I have no found this issue on MVL 2.6.10 + Patch 45. Could anyone help me?
Thanks very much.
BR
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://linux.omap.com/pipermail/davinci-linux-open-source/attachments/200905
13/647c02ce/attachment-0001.htm
------------------------------
Message: 2
Date: Wed, 13 May 2009 06:15:49 -0500
From: Steve Chen <[email protected]>
Subject: Re: multiple nand on dm355
To: Vijay Soni <[email protected]>
Cc: [email protected]
Message-ID: <1242213349.3095.281.ca...@linux-1lbu>
Content-Type: text/plain
On Tue, 2009-05-12 at 17:07 -0700, Vijay Soni wrote:
> Does anyone know what code changes would be required to have multiple nand
flash
> support on dm355 based hardware. The different nand flash will have
different nand
> base addresses (due to external chip select multiplexer) and all need to
be seen by kernel.
> Further, we have three nand flash, of which the boot nand is same as in
evm(2k page size)
> but the other two are 4k page size nand flashes.
>
Take a look at nand_resources in
arch/arm/mach-davinci/board-dm355-evm.c. The MVL tree has an extra
entry to support a NAND chip on DM355 EVM with 2 chip selects which
appears as 2 separate NAND devices to the kernel. Perhaps you can do
something similar.
Regards,
Steve
------------------------------
Message: 3
Date: Wed, 13 May 2009 06:31:01 -0500
From: Steve Chen <[email protected]>
Subject: Re: I can't boot linux2.6.18 uImage in dm355
To: zuowenping <[email protected]>
Cc: davinci-linux-open-source
<[email protected]>
Message-ID: <1242214261.3095.288.ca...@linux-1lbu>
Content-Type: text/plain
On Wed, 2009-05-13 at 12:51 +0800, zuowenping wrote:
> dear all:
> I used the DaVinciLSP-01_20_00_014 in the past ,now i want to use the
DaVinciLSP_02_00_00_110
> because i want to use the linux2.6.18 kernel, so i use toolchains
mvltools5_0_0 to compile the new
> kernel and it produced a uImage,but when i download it to the dm355 evm,it
cann't been booted:
>
> DM355 EVM # tftpboot
> TFTP from server 10.0.0.89; our IP address is 10.0.0.53
> Filename 'uImage'.
> Load address: 0x80700000
> Loading: #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> ###########################################################
> done
> Bytes transferred = 1965516 (1dfdcc hex)
> DM355 EVM # setenv bootargs 'mem=116M console=ttyS0,115200n8
root=/dev/mtdblock3
> rw rootfstype=yaffs2 ip=dhcp
video=davincifb:vid0=720x576x16,2500K:vid1=720x576x16,2500K:
You did put the file system for 2.6.18 kernel in the flash right?
2.6.18 kernel won't boot with 2.6.10 file system.
> osd0=800x600x16,2025K davinci_enc_mngr.ch0_output=COMPOSITE
davinci_enc_mngr.ch0_mode=PAL'
> DM355 EVM # bootm
> ## Booting image at 80700000 ...
> Image Name: Linux-2.6.18_pro500-davinci_evm-
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 1965452 Bytes = 1.9 MB
> Load Address: 80008000
> Entry Point: 80008000
> Verifying Checksum ... OK
> OK
>
> Starting kernel ..
>
> Uncompressing
Linux.......................................................................
............................................................ done, booting
the kernel.
>
> It stop here forever,it seems the kernel can't been booted,why?I used
> the old kernel uImage linux2.6.10 or i used the uImage-dm355 the
> PSP_02_00_00_110 supported,they are all ok! the arm_v5t_le-gcc
> i version is 4.2.0 (MontaVista 4.2.0-16.0.32.0801914 2008-08-30) ,I
> compile the kernel image steps is:
>
> make ARCH=arm CROSS_COMPILE=arm_v5t_le- davinci_dm355_defconfig
> make ARCH=arm CROSS_COMPILE=arm_v5t_le- uImage
>
> I have compiled too many times linux2.6.10 kernel in mv_pro_4.0.1
> envirment just like up steps,they are all ok!
Turn on DEBUG_LL would provide more debug information and perhaps point
you to the problem.
Regards,
Steve
------------------------------
Message: 4
Date: Wed, 13 May 2009 07:37:02 -0400
From: Chaithrika U S <[email protected]>
Subject: [PATCH] ASoC: Correct the resource structure assignment
To: [email protected]
Message-ID: <[email protected]>
Assign the platform resource structures according to the EVMs used.
Signed-off-by: Chaithrika U S <[email protected]>
---
sound/soc/davinci/davinci-evm.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/sound/soc/davinci/davinci-evm.c
b/sound/soc/davinci/davinci-evm.c
index 45912b4..4ddb13d 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -199,13 +199,14 @@ static int __init evm_init(void)
{
struct resource *resources;
struct evm_snd_platform_data *data;
- int index;
+ int index, res_size;
int ret;
if (machine_is_davinci_evm()) {
davinci_cfg_reg(DM644X_MCBSP);
resources = evm_snd_resources;
+ res_size = ARRAY_SIZE(evm_snd_resources);
data = &evm_snd_data;
index = 0;
} else if (machine_is_davinci_dm355_evm()) {
@@ -214,6 +215,7 @@ static int __init evm_init(void)
davinci_cfg_reg(DM355_EVT9_ASP1_RX);
resources = dm335evm_snd_resources;
+ res_size = ARRAY_SIZE(dm335evm_snd_resources);
data = &dm335evm_snd_data;
index = 1;
} else
@@ -227,8 +229,8 @@ static int __init evm_init(void)
evm_snd_devdata.dev = &evm_snd_device->dev;
platform_device_add_data(evm_snd_device, data, sizeof(*data));
- ret = platform_device_add_resources(evm_snd_device,
evm_snd_resources,
- ARRAY_SIZE(evm_snd_resources));
+ ret = platform_device_add_resources(evm_snd_device, resources,
+ res_size);
if (ret) {
platform_device_put(evm_snd_device);
return ret;
--
1.5.6
------------------------------
Message: 5
Date: Wed, 13 May 2009 08:28:46 -0500
From: "Maupin, Chase" <[email protected]>
Subject: RE: I can't boot linux2.6.18 uImage in dm355
To: Steve Chen <[email protected]>, zuowenping
<[email protected]>
Cc: davinci-linux-open-source
<[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Also, check you console setting in your u-boot bootargs variable. This
looks like what happens when the console isn't setup right. Once control is
given over to the kernel it does not know how to output the console
messages. Please include your u-boot environment variables in your next
e-mail.
Sincerely,
Chase Maupin
Software Applications
Catalog DSP Products
e-mail: [email protected]
phone: (281) 274-3285
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf
> Of Steve Chen
> Sent: Wednesday, May 13, 2009 6:31 AM
> To: zuowenping
> Cc: davinci-linux-open-source
> Subject: Re: I can't boot linux2.6.18 uImage in dm355
>
> On Wed, 2009-05-13 at 12:51 +0800, zuowenping wrote:
> > dear all:
> > I used the DaVinciLSP-01_20_00_014 in the past ,now i want to use the
> DaVinciLSP_02_00_00_110
> > because i want to use the linux2.6.18 kernel, so i use toolchains
> mvltools5_0_0 to compile the new
> > kernel and it produced a uImage,but when i download it to the dm355
> evm,it cann't been booted:
> >
> > DM355 EVM # tftpboot
> > TFTP from server 10.0.0.89; our IP address is 10.0.0.53
> > Filename 'uImage'.
> > Load address: 0x80700000
> > Loading:
> #################################################################
> >
> #################################################################
> >
> #################################################################
> >
> #################################################################
> >
> #################################################################
> > ###########################################################
> > done
> > Bytes transferred = 1965516 (1dfdcc hex)
> > DM355 EVM # setenv bootargs 'mem=116M console=ttyS0,115200n8
> root=/dev/mtdblock3
> > rw rootfstype=yaffs2 ip=dhcp
> video=davincifb:vid0=720x576x16,2500K:vid1=720x576x16,2500K:
>
> You did put the file system for 2.6.18 kernel in the flash right?
> 2.6.18 kernel won't boot with 2.6.10 file system.
>
> > osd0=800x600x16,2025K davinci_enc_mngr.ch0_output=COMPOSITE
> davinci_enc_mngr.ch0_mode=PAL'
> > DM355 EVM # bootm
> > ## Booting image at 80700000 ...
> > Image Name: Linux-2.6.18_pro500-davinci_evm-
> > Image Type: ARM Linux Kernel Image (uncompressed)
> > Data Size: 1965452 Bytes = 1.9 MB
> > Load Address: 80008000
> > Entry Point: 80008000
> > Verifying Checksum ... OK
> > OK
> >
> > Starting kernel ..
> >
> > Uncompressing
> Linux.....................................................................
> .............................................................. done,
> booting the kernel.
> >
> > It stop here forever,it seems the kernel can't been booted,why?I used
> > the old kernel uImage linux2.6.10 or i used the uImage-dm355 the
> > PSP_02_00_00_110 supported,they are all ok! the arm_v5t_le-gcc
> > i version is 4.2.0 (MontaVista 4.2.0-16.0.32.0801914 2008-08-30) ,I
> > compile the kernel image steps is:
> >
> > make ARCH=arm CROSS_COMPILE=arm_v5t_le- davinci_dm355_defconfig
> > make ARCH=arm CROSS_COMPILE=arm_v5t_le- uImage
> >
> > I have compiled too many times linux2.6.10 kernel in mv_pro_4.0.1
> > envirment just like up steps,they are all ok!
>
> Turn on DEBUG_LL would provide more debug information and perhaps point
> you to the problem.
>
> Regards,
>
> Steve
>
>
>
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> [email protected]
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
------------------------------
Message: 6
Date: Wed, 13 May 2009 08:41:07 -0500
From: "Karicheri, Muralidharan" <[email protected]>
Subject: RE: [PATCH 1/7] VPFE capture driver for DM355 and DM6446
To: Laurent Pinchart <[email protected]>
Cc: "[email protected]"
<[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-15"
Laurent,
Thanks.
I am done all my rework except the one discussed here. I have also ported
the driver to sub device framework. So I feel I could submit the patch
directly to v4l2 mailing list without another round of iteration on this
list. For the response to this email, please see below.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: [email protected]
>-----Original Message-----
>From: Laurent Pinchart [mailto:[email protected]]
>Sent: Tuesday, May 12, 2009 6:56 PM
>To: Karicheri, Muralidharan
>Cc: [email protected]
>Subject: Re: [PATCH 1/7] VPFE capture driver for DM355 and DM6446
>
>Hi,
>
>On Thursday 07 May 2009 17:06:02 Karicheri, Muralidharan wrote:
>> Laurent,
>>
>> I need to re-visit following comments as I found something different
>> after going through the videobuf-core.c
>>
>> > > > > +static void vpfe_videobuf_queue(struct videobuf_queue *vq,
>> > > > > + struct videobuf_buffer *vb)
>> > > > > +{
>> > > > > + /* Get the file handle object and channel object */
>> > > > > + struct vpfe_fh *fh = vq->priv_data;
>> > > > > + struct channel_obj *channel = fh->channel;
>> > > > > + struct common_obj *common = NULL;
>> > > > > +
>> > > > > + v4l2_dbg(1, debug, vpfe_dev->driver,
>"<vpfe_buffer_queue>\n");
>> > > > > + common = &(channel->common[VPFE_VIDEO_INDEX]);
>> > > > > +
>> > > > > + /* add the buffer to the DMA queue */
>> > > > > + list_add_tail(&vb->queue, &common->dma_queue);
>> > > >
>> > > > This needs to be protected by a mutex
>> > >
>> > > [MK] I think in the videobuf-core.c this is already protected
>> > > by mutex lock using vb_lock of videobuf_queue structure.
>> >
>> > Actually it needs to be protected by a spinlock. common->dma_queue is
>> > accessed in IRQ handlers.
>>
>> [MK] in videobuf-core.c, all calls to buffer_queue() is called inside
>> spin_lock_irqsave()/spin_lock_restore() which means irq is disabled.
>> So this is not required to be locked in the bridge driver code.
>
>If I'm not mistaken, spin_lock_irqsave() will only disable interrupts on
>the
>current processor. As the Davinci processors do not support SMP this
>shouldn't
>be a real issue, but for the sake of correctness you should still protect
>access to the list with a spinlock in the IRQ handlers. Beside, some real-
>time
>patches to the Linux kernel run interrupts in kernel threads. Failure to
>use
>proper locking will likely cause problems there.
>
[MK] Ok. I will add spinlock() to protect the list.
>> > > > > +static void vpfe_videobuf_release(struct videobuf_queue *vq,
>> > > > > + struct videobuf_buffer *vb)
>> > > > > +{
>> > > > > + v4l2_dbg(1, debug, vpfe_dev->driver,
>> > > > > "vpfe_videobuf_release\n"); + videobuf_dma_contig_free(vq,
>vb);
>> > > > > + vb->state = VIDEOBUF_NEEDS_INIT;
>> > > >
>> > > > I'm not sure about this, but aren't you supposed to remove the
>buffer
>> > > > from the dma_queue here ?
>> > >
>> > > [MK] I believe when REQUEST_BUF is called the second time,
>> > > INIT_LIST_HEAD will re-initialize the queue.
>> >
>> > The buf_release callback is not necessarily followed by a
>VIDIOC_REQBUFS.
>> > For instance, if the user calls VIDIOC_STREAMOFF, vpfe_videobuf_release
>> > will be called. It would be perfectly valid to call VIDIOC_STREAMON
>after
>> > that with any VIDIOC_REQBUFS in between.
>>
>> [MK] also here when freeing the buffer, driver could use the same irqlock
>> passed to the core from bridge driver to lock/unlock since when calling
>> this function, core is not using the same. Do you agree ?
>
>The general rule is that you need to protect concurrent access to data
>using
>mutexes and/or spinlocks where applicable. Some data structures don't
>require
>locking, but linked lists do. When manipulating linked lists you either
>need a
>mutex if all access to the list is done in a context where you can sleep,
>or a
>spinlock otherwise.
>
>What do you mean exactly by "irqlock passed to the core from bridge
>driver" ?
>
[MK] I meant 4th argument to videobuf_queue_dma_contig_init(). Anyways, as
per the above comment, I will use the spinlock used above for this as well.
>Best regards,
>
>Laurent Pinchart
>
------------------------------
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
End of Davinci-linux-open-source Digest, Vol 41, Issue 62
*********************************************************
Nessun virus nel messaggio in arrivo.
Controllato da AVG - www.avg.com
Versione: 8.5.329 / Database dei virus: 270.12.27/2112 - Data di rilascio:
05/13/09 07:04:00
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
