named pipe issue on Davinci

[gather bzbz]

hi, 

I tried to the following code on DM355 platform, but always got stuck at 
fopen(),
it never returned. Any help would be appreicated.



#include 
#include 
#include 

int main()
{
  char MY_NAMMED_PIPE[64]="/tmp/mypipe";
  FILE *dps=NULL;

  printf("mkfifo on %s\n", MY_NAMMED_PIPE);
  if (mkfifo(MY_NAMMED_PIPE, 0777)) {
perror("Error with Server FIFO");
exit(1);
  }

  printf("fopen on %s\n", MY_NAMMED_PIPE);
  dps=fopen(MY_NAMMED_PIPE,"w");
  if(dps == NULL) {
perror("Error opening the FIFO\n");
exit(2);
  }

  while(1){
// do sth
  }

  exit(0);
}




  

___
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

[Deepika Makhija]

Hi, 

Display won't work with YUV 422 Planar sorry it was my mistake.
 
Your input is 4:2:0 semi planar to VDCE, and output of VDCE will be
4:2:2 semi planar which will be given to display driver and hence
display would be working, as display accepts 4:2:2 semi planar input.

Regards,
Deepika

Vinayagam Mariappan wrote:

  Hi  Deepika,
   
  I just made the saDisplay to work.
   
  Its always better to follow some principle like,
   
  >> Give YUV420 semi planar data to convert YUV422 data
other wise you will get wrong conversion file because when we use Ccv
it always copy the data with image width size
   
  >> Display always works with YUV422 Planar
   
  Anyway thanks for your detailed description that made me analyse
it properly.
   
  Regards,
  Vinayagam M
  
  
  On Sun, Aug 2, 2009 at 3:04 AM, Jadav,
Brijesh R  wrote:
  Hi
Deepika,

As per the specs, VPIF cannot display planar YUV422 data. It says it
takes Luma and Chroma data for top and bottom field for interlaced
image and Luma and Chroma data for the Progressive image. Also there is
no separate register even to specify buffer pointer for cb and cr data.
This is also true for the VDCE. Can you please tell me where it says
VPIF can display planar YUV422 images?

Thanks,
Brijesh Jadav

From: davinci-linux-open-source-boun...@linux.davincidsp.com
[davinci-linux-open-source-boun...@linux.davincidsp.com]
On Behalf Of Deepika Makhija [deepika.makh...@einfochips.com]
Sent: Saturday, August 01, 2009 12:01 AM
To: Vinayagam Mariappan
Cc: Davinci-linux-open-source@linux.davincidsp.com

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

Hi,


DM6467 encode/decode  supports 4:2:0 YUV semi
planar mode only
Capture driver supports 4:2:2 YUV semi planar and display supports
4:2:2  semi planar and planar.
VDCE module performs conversion irrespective of planar/semi planar
mode, it does resize and CCV conversion

Assume you perform CCV conversion of 4:2:2 to 4:2:0 than

 *   If input is 4:2:2 semi planar than output will be 4:2:0 semi planar
 *   If input is 4:2:2 planar than output will be 4:2:0 planar

Capture and display drivers allocate buffer for 1920x1080 resolution
during initialization.  Two buffers are located, one for luma and other
for chroma.
So, Chroma will be at the offset of 1920*1080 irrespective of the
capture resolution. Same is true for the display driver. But this is
the case only for MMAP buffers as MMAP buffers are allocated by the
driver.

Luma and chroma can be arranged together with the ioctl S_FMT. In that
case chroma data will be at the offset of "width*height", where
width/height corresponds to the resolution selected.

One more thing, in case of MMAP buffers, if S_FMT is performed than
Luma and chroma will be aligned together and buffer length would be
still 1920*1080*2 as those buffers are allocated during initialization.
VDCE expects chroma at the offset of  "buffer length /2", in that case
also only Y data will appear, as actual chroma data would be at 720*480
offset for NTSC.

Hope this helps you to debug your problem

Regards,
Deepika

Vinayagam Mariappan wrote:
Hi,

Its confusing me..

Let me give your data

In my system, I just decode MPEG-4 Data and get YUV420 on D1
resolution.. Now What I am doing is Just get one Frame of YUV420 data
from decoder (YUV420 => [YY][UU...][V] then
convert that YUV420 to YUV422 using saCCV420_422 and then I use the
converted YUV422 to display unit using saDisplay.

I get Luma data properly out on screen but never get Chroma.

Actually I use Decoder Demo Application which made for HD. I have able
to display the HD Decoded data comes with demo and display it on SD
unit. But when I use my customized decoded on D1 resolution I am not
getting anything on screen. So I want to debug the issue using
saDisplay then update it on applicayion.

I hope you got me in a right way...

Looking forward to fix this issue.

Regards,
Vinayagam M


On Sat, Aug 1, 2009 at 3:12 AM, Jadav, Brijesh R
>
wrote:
Hello Murali,

DM6467 supports NV16 video format, where image is stored in two
buffers. First buffer contains luma data and second buffer contains cb
and cr interleaved data. It does not support completele YUV422
interleaved data.

You are right, chroma buffer pointer could also be an problem. Display
driver always expects chroma data at the half of the buffer size.

Thanks,
Brijesh Jadav

From: Karicheri, Muralidharan
Sent: Friday, July 31, 2009 10:34 AM
To: Jadav, Brijesh R; Vinayagam Mariappan

Cc: Davinci-linux-open-source@linux.davincidsp.comDavinci-linux-open-source@linux.davincidsp.com>

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

Brijesh,

DM646

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

[Deepika Makhija]

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.
_


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

Re: 8-bit planar support for Resizer

[Nitin Mahajan]

HI!

Does that mean, if I am trying to pass say a color separated R or G or B frame, 
the driver wont be able to process that?

As of now I tried doing that, by setting  

params.pix_fmt=  RSZ_PIX_FMT_PLANAR;

params.inptyp  =  RSZ_INTYPE_PLANAR_8BIT;

The IOCTL "RSZ_S_PARAM" fails.

I wish to scale up / down a RGB image(using DM6443 resizer) after doing a color 
separation. Could you please guide me towards a way to achieve that?

regards

-Nitin

- Original Message 
> From: "Jadav, Brijesh R" 
> To: Vladimir Pantelic ; 
> "davinci-linux-open-source@linux.davincidsp.com" 
> 
> Cc: "davinci-linux-open-source@linux.davincidsp.com" 
> 
> Sent: Friday, July 31, 2009 17:50:42
> Subject: RE: 8-bit planar support for Resizer
> 
> Hi,
> 
> Driver supports planar Resizer but no in the RGB format. Resizer supports 
> planar 
> YUV422 scaling.
> 
> Thanks,
> Brijesh Jadav
> 
> -Original Message-
> From: davinci-linux-open-source-boun...@linux.davincidsp.com 
> [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of 
> Vladimir Pantelic
> Sent: Friday, July 31, 2009 5:44 PM
> To: davinci-linux-open-source@linux.davincidsp.com
> Cc: davinci-linux-open-source@linux.davincidsp.com
> Subject: Re: 8-bit planar support for Resizer
> 
> Nitin Mahajan wrote:
> > HI!
> >
> > Does the Davinci Resizer driver supports, RGB 8-bit color separated input 
> data?
> 
> don't know about the driver, but the resizer HW does support 8 bit resize,
> so a 3-pass will resize separated components...
> 
> 
> ___
> 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



  Get your new Email address!
Grab the Email name you've always wanted before someone else does!
http://mail.promotions.yahoo.com/newdomains/aa/

___
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 v3] ARM: DaVinci: DM646x Video: Platform and board specific setup

[chaithrika]

Mauro/Russell,

The previous version (v2) of this patch is on the linux-next tree.
This patch has some updates done on top of that patch. Should I
post an incremental patch for those changes to the Linux-next tree?
Please suggest.

Regards,
Chaithrika

On Mon, Jul 20, 2009 at 13:31:22, Chaithrika U S wrote:
> Platform specific display device setup for DM646x EVM
> 
> Add platform device and resource structures. Also define a platform
specific
> clock setup function that can be accessed by the driver to configure the
clock
> and CPLD.
> 
> Signed-off-by: Manjunath Hadli 
> Signed-off-by: Brijesh Jadav 
> Signed-off-by: Chaithrika U S 
> Signed-off-by: Kevin Hilman 
> ---
> Applies to Davinci GIT tree. Minor updates like change in structure name-
> subdev_info to vpif_subdev_info and correction to VDD3P3V_VID_MASK value.
> 
>  arch/arm/mach-davinci/board-dm646x-evm.c|  125
+++
>  arch/arm/mach-davinci/dm646x.c  |   62 +
>  arch/arm/mach-davinci/include/mach/dm646x.h |   24 +
>  3 files changed, 211 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
> index b1bf18c..8c88fd0 100644
> --- a/arch/arm/mach-davinci/board-dm646x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm646x-evm.c
> @@ -63,6 +63,19 @@
>  #define DM646X_EVM_PHY_MASK  (0x2)
>  #define DM646X_EVM_MDIO_FREQUENCY(220) /* PHY bus frequency */
>  
> +#define VIDCLKCTL_OFFSET (0x38)
> +#define VSCLKDIS_OFFSET  (0x6c)
> +
> +#define VCH2CLK_MASK (BIT_MASK(10) | BIT_MASK(9) | BIT_MASK(8))
> +#define VCH2CLK_SYSCLK8  (BIT(9))
> +#define VCH2CLK_AUXCLK   (BIT(9) | BIT(8))
> +#define VCH3CLK_MASK (BIT_MASK(14) | BIT_MASK(13) | BIT_MASK(12))
> +#define VCH3CLK_SYSCLK8  (BIT(13))
> +#define VCH3CLK_AUXCLK   (BIT(14) | BIT(13))
> +
> +#define VIDCH2CLK(BIT(10))
> +#define VIDCH3CLK(BIT(11))
> +
>  static struct davinci_uart_config uart_config __initdata = {
>   .enabled_uarts = (1 << 0),
>  };
> @@ -288,6 +301,40 @@ static struct snd_platform_data dm646x_evm_snd_data[]
= {
>   },
>  };
>  
> +static struct i2c_client *cpld_client;
> +
> +static int cpld_video_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + cpld_client = client;
> + return 0;
> +}
> +
> +static int __devexit cpld_video_remove(struct i2c_client *client)
> +{
> + cpld_client = NULL;
> + return 0;
> +}
> +
> +static const struct i2c_device_id cpld_video_id[] = {
> + { "cpld_video", 0 },
> + { }
> +};
> +
> +static struct i2c_driver cpld_video_driver = {
> + .driver = {
> + .name   = "cpld_video",
> + },
> + .probe  = cpld_video_probe,
> + .remove = cpld_video_remove,
> + .id_table   = cpld_video_id,
> +};
> +
> +static void evm_init_cpld(void)
> +{
> + i2c_add_driver(&cpld_video_driver);
> +}
> +
>  static struct i2c_board_info __initdata i2c_info[] =  {
>   {
>   I2C_BOARD_INFO("24c256", 0x50),
> @@ -300,6 +347,9 @@ static struct i2c_board_info __initdata i2c_info[] =
{
>   {
>   I2C_BOARD_INFO("cpld_reg0", 0x3a),
>   },
> + {
> + I2C_BOARD_INFO("cpld_video", 0x3B),
> + },
>  };
>  
>  static struct davinci_i2c_platform_data i2c_pdata = {
> @@ -307,11 +357,85 @@ static struct davinci_i2c_platform_data i2c_pdata =
{
>   .bus_delay  = 0 /* usec */,
>  };
>  
> +static int set_vpif_clock(int mux_mode, int hd)
> +{
> + int val = 0;
> + int err = 0;
> + unsigned int value;
> + void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
> +
> + if (!cpld_client)
> + return -ENXIO;
> +
> + /* disable the clock */
> + value = __raw_readl(base + VSCLKDIS_OFFSET);
> + value |= (VIDCH3CLK | VIDCH2CLK);
> + __raw_writel(value, base + VSCLKDIS_OFFSET);
> +
> + val = i2c_smbus_read_byte(cpld_client);
> + if (val < 0)
> + return val;
> +
> + if (mux_mode == 1)
> + val &= ~0x40;
> + else
> + val |= 0x40;
> +
> + err = i2c_smbus_write_byte(cpld_client, val);
> + if (err)
> + return err;
> +
> + value = __raw_readl(base + VIDCLKCTL_OFFSET);
> + value &= ~(VCH2CLK_MASK);
> + value &= ~(VCH3CLK_MASK);
> +
> + if (hd >= 1)
> + value |= (VCH2CLK_SYSCLK8 | VCH3CLK_SYSCLK8);
> + else
> + value |= (VCH2CLK_AUXCLK | VCH3CLK_AUXCLK);
> +
> + __raw_writel(value, base + VIDCLKCTL_OFFSET);
> +
> + /* enable the clock */
> + value = __raw_readl(base + VSCLKDIS_OFFSET);
> + value &= ~(VIDCH3CLK | VIDCH2CLK);
> + __raw_writel(value, base + VSCLKDIS_OFFSET);
> +
> + return 0;
> +}
> +
> +static const struct vpif_subdev_info dm646x_vpif_subdev[] = {
> + {
> + .addr   = 0x2A,
> +   

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

[Vinayagam Mariappan]

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




On Sat, Aug 1, 2009 at 2:01 PM, Deepika Makhija <
deepika.makh...@einfochips.com> wrote:

> Hi,
>
> DM6467 encode/decode  supports 4:2:0 YUV semi planar mode only
> Capture driver supports 4:2:2 YUV semi planar and display supports 4:2:2
> semi planar and planar.
> VDCE module performs conversion irrespective of planar/semi planar mode, it
> does resize and CCV conversion
>
> Assume you perform CCV conversion of 4:2:2 to 4:2:0 than
>
>- If input is 4:2:2 semi planar than output will be 4:2:0 semi planar
>- If input is 4:2:2 planar than output will be 4:2:0 planar
>
> Capture and display drivers allocate buffer for 1920x1080 resolution during
> initialization.  Two buffers are located, one for luma and other for chroma.
> So, Chroma will be at the offset of 1920*1080 irrespective of the capture
> resolution. Same is true for the display driver. But this is the case only
> for MMAP buffers as MMAP buffers are allocated by the driver.
>
> Luma and chroma can be arranged together with the ioctl S_FMT. In that case
> chroma data will be at the offset of "width*height", where width/height
> corresponds to the resolution selected.
>
> One more thing, in case of MMAP buffers, if S_FMT is performed than Luma
> and chroma will be aligned together and buffer length would be still
> 1920*1080*2 as those buffers are allocated during initialization. VDCE
> expects chroma at the offset of  "buffer length /2", in that case also only
> Y data will appear, as actual chroma data would be at 720*480 offset for
> NTSC.
>
> Hope this helps you to debug your problem
>
> Regards,
> Deepika
>
> Vinayagam Mariappan wrote:
>
>   Hi,
>
> Its confusing me..
>
> Let me give your data
>
> In my system, I just decode MPEG-4 Data and get YUV420 on D1 resolution..
> Now What I am doing is Just get one Frame of YUV420 data from decoder
> (YUV420 => [YY][UU...][V] then convert that YUV420
> to YUV422 using saCCV420_422 and then I use the converted YUV422 to display
> unit using saDisplay.
>
> I get Luma data properly out on screen but never get Chroma.
>
> Actually I use Decoder Demo Application which made for HD. I have able to
> display the HD Decoded data comes with demo and display it on SD unit. But
> when I use my customized decoded on D1 resolution I am not getting anything
> on screen. So I want to debug the issue using saDisplay then update it on
> applicayion.
>
> I hope you got me in a right way...
>
> Looking forward to fix this issue.
>
> Regards,
> Vinayagam M
>
> On Sat, Aug 1, 2009 at 3:12 AM, Jadav, Brijesh R  wrote:
>
>> Hello Murali,
>>
>> DM6467 supports NV16 video format, where image is stored in two buffers.
>> First buffer contains luma data and second buffer contains cb and cr
>> interleaved data. It does not support completele YUV422 interleaved data.
>>
>> You are right, chroma buffer pointer could also be an problem. Display
>> driver always expects chroma data at the half of the buffer size.
>>
>> Thanks,
>> Brijesh Jadav
>> 
>> From: Karicheri, Muralidharan
>> Sent: Friday, July 31, 2009 10:34 AM
>> To: Jadav, Brijesh R; Vinayagam Mariappan
>>  Cc: Davinci-linux-open-source@linux.davincidsp.com
>> Subject: RE: saDisplay + DM6467 showing black an white image in SD Display
>>
>> Brijesh,
>>
>> DM6467 display accept YUV422 planar. The format is YUV422 =>
>> [][U][V].
>> as given by Vinayagam.
>>
>> If you are seeing black and white image, it is probably because your cbcr
>> offer is not correct.
>> The display driver in expects cbcr offset at half kernel buffer size
>> (MMAP) and half of sizeimage for UserPTR.
>> I have been working to port the code to GIT and this is what I have
>> understood.
>>
>> Murali Karicheri
>> Software Design Engineer
>> Texas Instruments Inc.
>> Germantown, MD 20874
>> Phone : 301-515-3736
>> email: m-kariche...@ti.com
>> 
>> From: davinci-linux-open-source-bounces+m-karicheri2=ti.com@
>> linux.davincidsp.com [mailto:
>> davinci-linux-open-source-bounces+m-karicheri2
>> =ti@linux.davincidsp.com] On Behalf Of Jadav, Brijesh R
>> Sent: Friday, July 31, 2009 8:42 AM
>> To: Vinayagam Mariappan
>> Cc: Davinci-linux-open-source@linux.davincidsp.com
>> Subject: RE: saDisplay + DM6467 showing black an white image in SD Display
>>
>> Hi,
>>
>> DM6467 display module accepts data in the YUV422 semi-planar format. It is
>> as shown below
>>
>> YUV422 => [][UVUVUVUVUV].
>> Probably, this is reason why you a

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

[Vinayagam Mariappan]

Hi  Deepika,

I just made the saDisplay to work.

Its always better to follow some principle like,

>> Give YUV420 semi planar data to convert YUV422 data other wise you will
get wrong conversion file because when we use Ccv it always copy the data
with image width size

>> Display always works with YUV422 Planar

Anyway thanks for your detailed description that made me analyse it
properly.

Regards,
Vinayagam M

On Sun, Aug 2, 2009 at 3:04 AM, Jadav, Brijesh R  wrote:

> Hi Deepika,
>
> As per the specs, VPIF cannot display planar YUV422 data. It says it takes
> Luma and Chroma data for top and bottom field for interlaced image and Luma
> and Chroma data for the Progressive image. Also there is no separate
> register even to specify buffer pointer for cb and cr data. This is also
> true for the VDCE. Can you please tell me where it says VPIF can display
> planar YUV422 images?
>
> Thanks,
> Brijesh Jadav
> 
> From: davinci-linux-open-source-boun...@linux.davincidsp.com [
> davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
> Deepika Makhija [deepika.makh...@einfochips.com]
> Sent: Saturday, August 01, 2009 12:01 AM
> To: Vinayagam Mariappan
> Cc: Davinci-linux-open-source@linux.davincidsp.com
> Subject: Re: saDisplay + DM6467 showing black an white image in SD Display
>
> Hi,
>
> DM6467 encode/decode  supports 4:2:0 YUV semi planar mode only
> Capture driver supports 4:2:2 YUV semi planar and display supports 4:2:2
>  semi planar and planar.
> VDCE module performs conversion irrespective of planar/semi planar mode, it
> does resize and CCV conversion
>
> Assume you perform CCV conversion of 4:2:2 to 4:2:0 than
>
>  *   If input is 4:2:2 semi planar than output will be 4:2:0 semi planar
>  *   If input is 4:2:2 planar than output will be 4:2:0 planar
>
> Capture and display drivers allocate buffer for 1920x1080 resolution during
> initialization.  Two buffers are located, one for luma and other for chroma.
> So, Chroma will be at the offset of 1920*1080 irrespective of the capture
> resolution. Same is true for the display driver. But this is the case only
> for MMAP buffers as MMAP buffers are allocated by the driver.
>
> Luma and chroma can be arranged together with the ioctl S_FMT. In that case
> chroma data will be at the offset of "width*height", where width/height
> corresponds to the resolution selected.
>
> One more thing, in case of MMAP buffers, if S_FMT is performed than Luma
> and chroma will be aligned together and buffer length would be still
> 1920*1080*2 as those buffers are allocated during initialization. VDCE
> expects chroma at the offset of  "buffer length /2", in that case also only
> Y data will appear, as actual chroma data would be at 720*480 offset for
> NTSC.
>
> Hope this helps you to debug your problem
>
> Regards,
> Deepika
>
> Vinayagam Mariappan wrote:
> Hi,
>
> Its confusing me..
>
> Let me give your data
>
> In my system, I just decode MPEG-4 Data and get YUV420 on D1 resolution..
> Now What I am doing is Just get one Frame of YUV420 data from decoder
> (YUV420 => [YY][UU...][V] then convert that YUV420
> to YUV422 using saCCV420_422 and then I use the converted YUV422 to display
> unit using saDisplay.
>
> I get Luma data properly out on screen but never get Chroma.
>
> Actually I use Decoder Demo Application which made for HD. I have able to
> display the HD Decoded data comes with demo and display it on SD unit. But
> when I use my customized decoded on D1 resolution I am not getting anything
> on screen. So I want to debug the issue using saDisplay then update it on
> applicayion.
>
> I hope you got me in a right way...
>
> Looking forward to fix this issue.
>
> Regards,
> Vinayagam M
>
> On Sat, Aug 1, 2009 at 3:12 AM, Jadav, Brijesh R  brijes...@ti.com>> wrote:
> Hello Murali,
>
> DM6467 supports NV16 video format, where image is stored in two buffers.
> First buffer contains luma data and second buffer contains cb and cr
> interleaved data. It does not support completele YUV422 interleaved data.
>
> You are right, chroma buffer pointer could also be an problem. Display
> driver always expects chroma data at the half of the buffer size.
>
> Thanks,
> Brijesh Jadav
> 
> From: Karicheri, Muralidharan
> Sent: Friday, July 31, 2009 10:34 AM
> To: Jadav, Brijesh R; Vinayagam Mariappan
> Cc: Davinci-linux-open-source@linux.davincidsp.com Davinci-linux-open-source@linux.davincidsp.com>
> Subject: RE: saDisplay + DM6467 showing black an white image in SD Display
>
> Brijesh,
>
> DM6467 display accept YUV422 planar. The format is YUV422 =>
> [][U][V].
> as given by Vinayagam.
>
> If you are seeing black and white image, it is probably because your cbcr
> offer is not correct.
> The display driver in expects cbcr offset at half kernel buffer size (MMAP)
> and half of sizeimage for UserPTR.
> I have been working to port the co

Re: Problem regarding DSPLink build

[Pablo Bitton]

I can recommend building DSPLink using OE/Arago:
https://gforge.ti.com/gf/project/arago/mailman/?_forum_action=ForumMessageBrowse&thread_id=2096&action=ListThreads&mailman_id=39


On Fri, Jul 31, 2009 at 11:43 AM, Vijayabharathi
C wrote:
> Hi
>
> Iam facing some problem when i tried to built DSPLink in the DM6446 EVM
> board. I followed the same procedure as mentioned in the below link. but iam
> facing problem when iam trying to build the Dsplink on arm-linux.
>
> http://wiki.davincidsp.com/index.php/How_to_build_an_ARM/DSP_Hello_World_program_on_the_DaVinci_EVM
>
> Kindly suggest me any patch to be added?
>
> Regards
> Vijayabharathi C
> ___
> 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