from:"Hiremath, Vaibhav"

 -Original Message-
 From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com]
 Sent: Monday, April 20, 2009 4:15 PM
 To: Hiremath, Vaibhav
 Cc: Hans Verkuil; linux-me...@vger.kernel.org; Aguirre Rodriguez,
 Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux-
 o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R;
 R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam
 Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support
 under V4L2 framework

 Hello Vaibhav,

 This is user manual of S3C6400 (not much different from S3C6410)
 http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C64
 00X_UserManual_rev1-0_2008-02_661558um.pdf

 That SoC is from my company but not from the same division of mine.
 Actually I'm doing this driver job without any request from chip
 delivering division. I'm doing this because this is so challenging
 and
 want better generic driver :-)

 Take a look at the user manual and please let me know your opinion.
 In my understanding scaler and some camera interface feature in
 S3C64XX are very similar to the features in Omap3.

[Hiremath, Vaibhav] Hi Kim,

I went through the document and below are some observations and questions I 
have - 

- If I compare it with OMAP then there is nothing application needs to 
configure specific to hardware. All the parameters supported through 
v4l2_format one with TYPE_VIDEO_OUTPUT and another with TYPE_VIDEO_CAPTURE 
except the parameter offset (If driver is supporting it)

- I wanted to understand how are you configuring offset register? How 
are you exporting it to user application?

Rest everything we can handle in driver once input source and output 
destination format receives from application.

From OMAP Point of view - 
---

The extra configuration is coefficients, which if we don't export to user 
application then I think we are very close to your IP.

Extra configuration required other than coeff.

RSZ_YENH - which takes 4 params

- Algo
- Gain
- Slope
- Core

All are part of one register so we can make use of priv field for this 
configuration. 

Thanks,
Vaibhav Hiremath

 Cheers,

 Nate

 On Mon, Apr 20, 2009 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com
 wrote:

  Thanks,
  Vaibhav Hiremath

  -Original Message-
  From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
  ow...@vger.kernel.org] On Behalf Of Dongsoo Kim
  Sent: Sunday, April 19, 2009 12:06 PM
  To: Hans Verkuil
  Cc: Hiremath, Vaibhav; linux-me...@vger.kernel.org; Aguirre
  Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu);
 linux-
  o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh
 R;
  R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam
  Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support
  under V4L2 framework

  Hello Hans and Hiremath,

  One of my recent job is making S3C64XX camera interface driver
 (even
  though other jobs of mine are not finished yet...;-()
  And, what a incident! S3C64XX has also similar H/W block in
 camera
  interface.
  Resizer in S3C camera interface can be used in system wide like
 the
  one in Omap3.

  [Hiremath, Vaibhav] Can you share the spec for the same; I wanted
 to verify the configuration part of it? What all configuration is
 exported to the user?

  But in case of mine, I decided to make it as a TYPE_VIDEO_CAPTURE
  and
  TYPE_VIDEO_OUTPUT.
  I thought that is was enough. Actually I took omap video out
 (vout?)
  for reference :-)

  [Hiremath, Vaibhav] I have also implemented the driver is the same
 way and also working with Hans to get it reviewed. But there are
 some configuration like coeff., luma enhancement, etc... need to
 export to the user, where we need to add mechanism in V4L2
 framework.

  Since we have one more device where we are demanding for M-to-M
 operation, I think it is important to go through it. Can you share
 some documents of your IP for better understanding.

  Cheers,

  Nate

  2009. 04. 19, 오전 12:53, Hans Verkuil 작성:

   On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote:
   Thanks,
   Vaibhav Hiremath

   APPROACH 3 -
   --

   .

   (Any other approach which I could not think of would be

   appreciated)

   I would prefer second approach, since this will provide
  standard
   interface to applications independent on underneath
 hardware.

   There may be many number of such configuration parameters
  required

   for

   different such devices, we need to work on this and come up
  with

   some

   standard capability fields covering most of available
 devices.

   Does anybody have some other opinions on this?
   Any suggestions will be helpful here,

   FYI: I have very little time to look at this for the next 2-3
  weeks.
   As you
   know I'm working on the last pieces of the v4l2_subdev
  conversion
   for 2.6.30
   that should

RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework

 -Original Message-
 From: Hiremath, Vaibhav
 Sent: Tuesday, April 21, 2009 3:16 PM
 To: 'Dongsoo, Nathaniel Kim'
 Cc: Hans Verkuil; linux-me...@vger.kernel.org; Aguirre Rodriguez,
 Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux-
 o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R;
 R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam
 Subject: RE: [RFC] Stand-alone Resizer/Previewer Driver support
 under V4L2 framework

  -Original Message-
  From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com]
  Sent: Monday, April 20, 2009 4:15 PM
  To: Hiremath, Vaibhav
  Cc: Hans Verkuil; linux-me...@vger.kernel.org; Aguirre Rodriguez,
  Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux-
  o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh
 R;
  R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam
  Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support
  under V4L2 framework

  Hello Vaibhav,

  This is user manual of S3C6400 (not much different from S3C6410)

 http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C64
  00X_UserManual_rev1-0_2008-02_661558um.pdf

  That SoC is from my company but not from the same division of
 mine.
  Actually I'm doing this driver job without any request from chip
  delivering division. I'm doing this because this is so challenging
  and
  want better generic driver :-)

  Take a look at the user manual and please let me know your
 opinion.
  In my understanding scaler and some camera interface feature in
  S3C64XX are very similar to the features in Omap3.

 [Hiremath, Vaibhav] Hi Kim,

 I went through the document and below are some observations and
 questions I have -

   - If I compare it with OMAP then there is nothing application
 needs to configure specific to hardware. All the parameters
 supported through v4l2_format one with TYPE_VIDEO_OUTPUT and
 another with TYPE_VIDEO_CAPTURE except the parameter offset (If
 driver is supporting it)

   - I wanted to understand how are you configuring offset
 register? How are you exporting it to user application?

 Rest everything we can handle in driver once input source and output
 destination format receives from application.

[Hiremath, Vaibhav] Missed one point in last draft, about buffer handling. How 
are you handling buffers? Are you supporting both USER_POINTER and MMAP buffers?
What is the size of buffers, is that different for input and output?
If yes, then how are you managing it?

If no, don't you see requirement for it?

Thanks,
Vaibhav

 From OMAP Point of view -
 ---

 The extra configuration is coefficients, which if we don't export to
 user application then I think we are very close to your IP.

 Extra configuration required other than coeff.

 RSZ_YENH - which takes 4 params

   - Algo
   - Gain
   - Slope
   - Core

 All are part of one register so we can make use of priv field for
 this configuration.

 Thanks,
 Vaibhav Hiremath

  Cheers,

  Nate

  On Mon, Apr 20, 2009 at 7:11 PM, Hiremath, Vaibhav
 hvaib...@ti.com
  wrote:

   Thanks,
   Vaibhav Hiremath

   -Original Message-
   From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
   ow...@vger.kernel.org] On Behalf Of Dongsoo Kim
   Sent: Sunday, April 19, 2009 12:06 PM
   To: Hans Verkuil
   Cc: Hiremath, Vaibhav; linux-me...@vger.kernel.org; Aguirre
   Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu);
  linux-
   o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav,
 Brijesh
  R;
   R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam
   Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support
   under V4L2 framework

   Hello Hans and Hiremath,

   One of my recent job is making S3C64XX camera interface driver
  (even
   though other jobs of mine are not finished yet...;-()
   And, what a incident! S3C64XX has also similar H/W block in
  camera
   interface.
   Resizer in S3C camera interface can be used in system wide like
  the
   one in Omap3.

   [Hiremath, Vaibhav] Can you share the spec for the same; I
 wanted
  to verify the configuration part of it? What all configuration is
  exported to the user?

   But in case of mine, I decided to make it as a
 TYPE_VIDEO_CAPTURE
   and
   TYPE_VIDEO_OUTPUT.
   I thought that is was enough. Actually I took omap video out
  (vout?)
   for reference :-)

   [Hiremath, Vaibhav] I have also implemented the driver is the
 same
  way and also working with Hans to get it reviewed. But there are
  some configuration like coeff., luma enhancement, etc... need to
  export to the user, where we need to add mechanism in V4L2
  framework.

   Since we have one more device where we are demanding for M-to-M
  operation, I think it is important to go through it. Can you share
  some documents of your IP for better understanding.

   Cheers,

   Nate

   2009. 04. 19, 오전 12:53

RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework

 -Original Message-
 From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com]
 Sent: Tuesday, April 21, 2009 3:44 PM
 To: Hiremath, Vaibhav
 Cc: Hans Verkuil; linux-me...@vger.kernel.org; Aguirre Rodriguez,
 Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux-
 o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R;
 R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam
 Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support
 under V4L2 framework

 Hello, Vaibhav,

 On Tue, Apr 21, 2009 at 7:01 PM, Hiremath, Vaibhav hvaib...@ti.com
 wrote:

  -Original Message-
  From: Hiremath, Vaibhav
  Sent: Tuesday, April 21, 2009 3:16 PM
  To: 'Dongsoo, Nathaniel Kim'
  Cc: Hans Verkuil; linux-me...@vger.kernel.org; Aguirre Rodriguez,
  Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux-
  o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh
 R;
  R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam
  Subject: RE: [RFC] Stand-alone Resizer/Previewer Driver support
  under V4L2 framework

   -Original Message-
   From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com]
   Sent: Monday, April 20, 2009 4:15 PM
   To: Hiremath, Vaibhav
   Cc: Hans Verkuil; linux-me...@vger.kernel.org; Aguirre
 Rodriguez,
   Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux-
   o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav,
 Brijesh
  R;
   R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam
   Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support
   under V4L2 framework

   Hello Vaibhav,

   This is user manual of S3C6400 (not much different from
 S3C6410)

 http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C64
   00X_UserManual_rev1-0_2008-02_661558um.pdf

   That SoC is from my company but not from the same division of
  mine.
   Actually I'm doing this driver job without any request from
 chip
   delivering division. I'm doing this because this is so
 challenging
   and
   want better generic driver :-)

   Take a look at the user manual and please let me know your
  opinion.
   In my understanding scaler and some camera interface feature in
   S3C64XX are very similar to the features in Omap3.

  [Hiremath, Vaibhav] Hi Kim,

  I went through the document and below are some observations and
  questions I have -

- If I compare it with OMAP then there is nothing
 application
  needs to configure specific to hardware. All the parameters
  supported through v4l2_format one with TYPE_VIDEO_OUTPUT and
  another with TYPE_VIDEO_CAPTURE except the parameter offset (If
  driver is supporting it)

 I'm not sure whether I'm following your question, but S3C64XX camera
 interface is obviously simpler than OMAP. So there is no wonder that
 user doesn't need to configure H/W specific things. And I don't get
 the question about offset parameter. Can you explain me more
 specifically?

[Hiremath, Vaibhav] Please refer to the section 16.5.1 (Page no 532 (16-11)) 
16.7.11 and 16.7.16.

You can specify offset from the input image to start, so that you can have part 
of image for scaling.

- I wanted to understand how are you configuring offset
  register? How are you exporting it to user application?

 Again, I don't get the point. Sorry.

  Rest everything we can handle in driver once input source and
 output
  destination format receives from application.

  [Hiremath, Vaibhav] Missed one point in last draft, about buffer
 handling. How are you handling buffers? Are you supporting both
 USER_POINTER and MMAP buffers?
  What is the size of buffers, is that different for input and
 output?
  If yes, then how are you managing it?

  If no, don't you see requirement for it?

 Sorry, my driver work is not that stage yet. It's just still in
 designing level, because of some special H/W features (like MSDMA,
 scaler and so) I'm totally stuck and can't go further.
 But your buffer theory seems to make sense and I suppose that is
 necessary if we have that kind of device.

[Hiremath, Vaibhav] I am talking to Mauro, and will keep you updated on this.

Thanks,
Vaibhav Hiremath

  Thanks,
  Vaibhav

  From OMAP Point of view -
  ---

  The extra configuration is coefficients, which if we don't export
 to
  user application then I think we are very close to your IP.

  Extra configuration required other than coeff.

  RSZ_YENH - which takes 4 params

- Algo
- Gain
- Slope
- Core

  All are part of one register so we can make use of priv field
 for
  this configuration.

 I get it. But S3C64XX is not that much configurable. As you see in
 user manual, it's a quite simple device.
 For now I'm still designing my driver, so I'll let you know if I
 face
 those issues in my driver.
 Cheers,

 Nate

  Thanks,
  Vaibhav Hiremath

   Cheers,

   Nate

   On Mon, Apr 20, 2009 at 7:11 PM, Hiremath, Vaibhav
  hvaib...@ti.com

RE: Previewer and resizer demo


 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Felix Radensky
 Sent: Tuesday, April 21, 2009 8:23 PM
 To: linux-omap@vger.kernel.org Mailing List
 Subject: Previewer and resizer demo
 
 Hi,
 
 Are there any userspace applications that demonstrate
 the use of previewer and resizer found in OPMA3 ISP.
 
[Hiremath, Vaibhav] Which release or patches you are using?

Thanks,
Vaibhav Hiremath

 Thanks.
 
 Felix.
 --
 To unsubscribe from this list: send the line unsubscribe linux-
 omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework

 -Original Message-
 From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com]
 Sent: Tuesday, April 21, 2009 6:34 PM
 To: Hiremath, Vaibhav
 Cc: Hans Verkuil; linux-me...@vger.kernel.org; Aguirre Rodriguez,
 Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux-
 o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R;
 R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam
 Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support
 under V4L2 framework

 Hello Vaibhav,

 On Tue, Apr 21, 2009 at 9:08 PM, Hiremath, Vaibhav hvaib...@ti.com
 wrote:
  -Original Message-
  From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com]
  Sent: Tuesday, April 21, 2009 3:44 PM
  To: Hiremath, Vaibhav
  Cc: Hans Verkuil; linux-me...@vger.kernel.org; Aguirre Rodriguez,
  Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux-
  o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh
 R;
  R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam
  Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support
  under V4L2 framework

  Hello, Vaibhav,

  On Tue, Apr 21, 2009 at 7:01 PM, Hiremath, Vaibhav
 hvaib...@ti.com
  wrote:

   -Original Message-
   From: Hiremath, Vaibhav
   Sent: Tuesday, April 21, 2009 3:16 PM
   To: 'Dongsoo, Nathaniel Kim'
   Cc: Hans Verkuil; linux-me...@vger.kernel.org; Aguirre
 Rodriguez,
   Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux-
   o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav,
 Brijesh
  R;
   R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam
   Subject: RE: [RFC] Stand-alone Resizer/Previewer Driver
 support
   under V4L2 framework

-Original Message-
From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com]
Sent: Monday, April 20, 2009 4:15 PM
To: Hiremath, Vaibhav
Cc: Hans Verkuil; linux-me...@vger.kernel.org; Aguirre
  Rodriguez,
Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux-
o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav,
  Brijesh
   R;
R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar,
 Purushotam
Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver
 support
under V4L2 framework

Hello Vaibhav,

This is user manual of S3C6400 (not much different from
  S3C6410)

 http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C64
00X_UserManual_rev1-0_2008-02_661558um.pdf

That SoC is from my company but not from the same division
 of
   mine.
Actually I'm doing this driver job without any request from
  chip
delivering division. I'm doing this because this is so
  challenging
and
want better generic driver :-)

Take a look at the user manual and please let me know your
   opinion.
In my understanding scaler and some camera interface feature
 in
S3C64XX are very similar to the features in Omap3.

   [Hiremath, Vaibhav] Hi Kim,

   I went through the document and below are some observations
 and
   questions I have -

 - If I compare it with OMAP then there is nothing
  application
   needs to configure specific to hardware. All the parameters
   supported through v4l2_format one with TYPE_VIDEO_OUTPUT and
   another with TYPE_VIDEO_CAPTURE except the parameter offset
 (If
   driver is supporting it)

  I'm not sure whether I'm following your question, but S3C64XX
 camera
  interface is obviously simpler than OMAP. So there is no wonder
 that
  user doesn't need to configure H/W specific things. And I don't
 get
  the question about offset parameter. Can you explain me more
  specifically?

  [Hiremath, Vaibhav] Please refer to the section 16.5.1 (Page no
 532 (16-11)) 16.7.11 and 16.7.16.

  You can specify offset from the input image to start, so that you
 can have part of image for scaling.

 Oh! sorry I made you get confused.
 What I'm working on is not the TV scaler of S3C64XX but scaler and
 rotator in camera interface.
 Please take a look at 20-1 camera interface
 This scaler/rotator feature can be used in general purpose.

 - I wanted to understand how are you configuring offset
   register? How are you exporting it to user application?

  Again, I don't get the point. Sorry.

   Rest everything we can handle in driver once input source and
  output
   destination format receives from application.

   [Hiremath, Vaibhav] Missed one point in last draft, about
 buffer
  handling. How are you handling buffers? Are you supporting both
  USER_POINTER and MMAP buffers?
   What is the size of buffers, is that different for input and
  output?
   If yes, then how are you managing it?

   If no, don't you see requirement for it?

  Sorry, my driver work is not that stage yet. It's just still in
  designing level, because of some special H/W features (like
 MSDMA,
  scaler and so) I'm totally stuck and can't go further.
  But your buffer theory seems to make sense and I suppose

RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework

2009-04-20 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Hans Verkuil [mailto:hverk...@xs4all.nl]
 Sent: Saturday, April 18, 2009 9:24 PM
 To: Hiremath, Vaibhav
 Cc: linux-me...@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto;
 DongSoo(Nathaniel) Kim; Toivonen Tuukka.O (Nokia-D/Oulu); linux-
 o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R;
 R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam
 Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support
 under V4L2 framework

 On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote:
  Thanks,
  Vaibhav Hiremath

APPROACH 3 -
--

.
  It makes sense, since such memory-to-memory devices will mostly
 being
  used from codecs context. And this would be more clear from user
  application.

 To be honest, I don't see the need for this. I think
 TYPE_VIDEO_CAPTURE and
 TYPE_VIDEO_OUTPUT are perfectly fine.

[Hiremath, Vaibhav] Agreed, and you will also find implementation of driver 
aligned to this which I have shared with you.

  And as acknowledged by you, we can use VIDIOC_S_FMT for setting
  parameters.

  One thing I am not able to convince myself is that, using priv
 field
  for custom configuration.

 I agree. Especially since you cannot use it as a pointer to addition
 information.

  I would prefer and recommend capability based
  interface, where application will query the capability of the
 device for
  luma enhancement, filter coefficients (number of coeff and depth),
  interpolation type, etc...

  This way we can make sure that, any such future devices can be
 adapted by
  this framework.

 The big question is how many of these capabilities are 'generic' and
 how
 many are very much hardware specific. I am leaning towards using the
 extended control API for this. It's a bit awkward to implement in
 drivers
 at the moment, but that should improve in the future when a lot of
 the
 control handling code will move into the new core framework.

 I really need to know more about the sort of features that
 omap/davinci
 offer (and preferably also for similar devices by other
 manufacturers).

[Hiremath, Vaibhav] Hans, Can we have IRC session for this? We will discuss 
this in detail and try to get closure on it.

Again I would request you to join me and mauro on IRC chat, I will be staying 
online tomorrow.

 Regards,

   Hans

 --
 Hans Verkuil - video4linux developer - sponsored by TANDBERG

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework

2009-04-20 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com]
 Sent: Monday, April 20, 2009 4:15 PM
 To: Hiremath, Vaibhav
 Cc: Hans Verkuil; linux-me...@vger.kernel.org; Aguirre Rodriguez,
 Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux-
 o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R;
 R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam
 Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support
 under V4L2 framework

 Hello Vaibhav,

 This is user manual of S3C6400 (not much different from S3C6410)
 http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C64
 00X_UserManual_rev1-0_2008-02_661558um.pdf

 That SoC is from my company but not from the same division of mine.
 Actually I'm doing this driver job without any request from chip
 delivering division. I'm doing this because this is so challenging
 and
 want better generic driver :-)

 Take a look at the user manual and please let me know your opinion.
 In my understanding scaler and some camera interface feature in
 S3C64XX are very similar to the features in Omap3.

[Hiremath, Vaibhav] Thanks for the link, I will go though it and get back to 
you.

 Cheers,

 Nate

 On Mon, Apr 20, 2009 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com
 wrote:

  Thanks,
  Vaibhav Hiremath

  -Original Message-
  From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
  ow...@vger.kernel.org] On Behalf Of Dongsoo Kim
  Sent: Sunday, April 19, 2009 12:06 PM
  To: Hans Verkuil
  Cc: Hiremath, Vaibhav; linux-me...@vger.kernel.org; Aguirre
  Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu);
 linux-
  o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh
 R;
  R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam
  Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support
  under V4L2 framework

  Hello Hans and Hiremath,

  One of my recent job is making S3C64XX camera interface driver
 (even
  though other jobs of mine are not finished yet...;-()
  And, what a incident! S3C64XX has also similar H/W block in
 camera
  interface.
  Resizer in S3C camera interface can be used in system wide like
 the
  one in Omap3.

  [Hiremath, Vaibhav] Can you share the spec for the same; I wanted
 to verify the configuration part of it? What all configuration is
 exported to the user?

  But in case of mine, I decided to make it as a TYPE_VIDEO_CAPTURE
  and
  TYPE_VIDEO_OUTPUT.
  I thought that is was enough. Actually I took omap video out
 (vout?)
  for reference :-)

  [Hiremath, Vaibhav] I have also implemented the driver is the same
 way and also working with Hans to get it reviewed. But there are
 some configuration like coeff., luma enhancement, etc... need to
 export to the user, where we need to add mechanism in V4L2
 framework.

  Since we have one more device where we are demanding for M-to-M
 operation, I think it is important to go through it. Can you share
 some documents of your IP for better understanding.

  Cheers,

  Nate

  2009. 04. 19, 오전 12:53, Hans Verkuil 작성:

   On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote:
   Thanks,
   Vaibhav Hiremath

   APPROACH 3 -
   --

   .

   (Any other approach which I could not think of would be

   appreciated)

   I would prefer second approach, since this will provide
  standard
   interface to applications independent on underneath
 hardware.

   There may be many number of such configuration parameters
  required

   for

   different such devices, we need to work on this and come up
  with

   some

   standard capability fields covering most of available
 devices.

   Does anybody have some other opinions on this?
   Any suggestions will be helpful here,

   FYI: I have very little time to look at this for the next 2-3
  weeks.
   As you
   know I'm working on the last pieces of the v4l2_subdev
  conversion
   for 2.6.30
   that should be finished this week. After that I'm attending
 the
   Embedded
   Linux Conference in San Francisco.

   But I always thought that something like this would be just a
   regular video
   device that can do both 'output' and 'capture'. For a resizer
 I
   would
   expect that you set the 'output' size (the size of your
 source
   image) and
   the 'capture' size (the size of the resized image), then just
  send
   the
   frames to the device (== resizer) and get them back on the
  capture
   side.

   [Hiremath, Vaibhav] Yes, it is possible to do that.

   Hans,

   I went through the link referred by Sergio and I think we
 should
   inherit
   some implementation for CODECs here for such devices.

   V4L2_BUF_TYPE_CODECIN - To access the input format.
   V4L2_BUF_TYPE_CODECOUT - To access the output format.

   It makes sense, since such memory-to-memory devices will
 mostly
  being
   used from codecs context. And this would be more clear from
 user

RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework

2009-03-31 Thread Hiremath, Vaibhav



Thanks,
Vaibhav Hiremath

 
  APPROACH 3 -
  --
 
  .
 
  (Any other approach which I could not think of would be
 appreciated)
 
 
  I would prefer second approach, since this will provide standard
  interface to applications independent on underneath hardware.
 
  There may be many number of such configuration parameters required
 for
  different such devices, we need to work on this and come up with
 some
  standard capability fields covering most of available devices.
 
  Does anybody have some other opinions on this?
  Any suggestions will be helpful here,
 
 FYI: I have very little time to look at this for the next 2-3 weeks.
 As you
 know I'm working on the last pieces of the v4l2_subdev conversion
 for 2.6.30
 that should be finished this week. After that I'm attending the
 Embedded
 Linux Conference in San Francisco.
 
 But I always thought that something like this would be just a
 regular video
 device that can do both 'output' and 'capture'. For a resizer I
 would
 expect that you set the 'output' size (the size of your source
 image) and
 the 'capture' size (the size of the resized image), then just send
 the
 frames to the device (== resizer) and get them back on the capture
 side.
 
[Hiremath, Vaibhav] Yes, it is possible to do that.

Hans,

I went through the link referred by Sergio and I think we should inherit some 
implementation for CODECs here for such devices.

V4L2_BUF_TYPE_CODECIN - To access the input format. V4L2_BUF_TYPE_CODECOUT - To 
access the output format.

It makes sense, since such memory-to-memory devices will mostly being used from 
codecs context. And this would be more clear from user application.

And as acknowledged by you, we can use VIDIOC_S_FMT for setting parameters.

One thing I am not able to convince myself is that, using priv field for 
custom configuration. I would prefer and recommend capability based interface, 
where application will query the capability of the device for luma enhancement, 
filter coefficients (number of coeff and depth), interpolation type, etc...

This way we can make sure that, any such future devices can be adapted by this 
framework.



Hans,
Have you get a chance to look at Video-Buf layer issues I mentioned in original 
draft?

 Regards,
 
   Hans
 
 --
 Hans Verkuil - video4linux developer - sponsored by TANDBERG

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework

Hi,

With reference to the mail-thread started by Sakari on Resizer driver interface,

http://marc.info/?l=linux-omapm=123628392325716w=2

I would like to bring some issues and propose changes to adapt such devices 
under V4L2 framework. Sorry for delayed response on this mail-thread, actually 
I was on vacation.

As proposed by Sakari, I do agree with the approach of having V4L2 interface 
for memory-to-memory operation of the ISP (like resizer and previewer), but I 
would like to bring some important aspects/issues here - 

- Some drawbacks of V4L2-buf layer framework for such kind of devices
- Need for backward compatibility. 

Drawbacks for V4L2-Buf layer - 
-

1} In case of resizer driver, the input buffer will always be different than 
output buffer. 

In case of Mmapped buffer there is no issue, since driver allocates maximum of 
input and output. User doesn't have control on this, although there is loss of 
memory from system point of view. 

In case of User Pointer Exchange, User would expect and may allocate different 
sizes of buffers for input and output which V4L2-buf layer doesn't support with 
single queue. And to address this, I think here we need to have either of 
following approaches - 

- Use two separate buffer queues, one for input and another for output.
- Or hack the driver for v4l2_buffer, internally using different buffer 
params for input and output. [Not recommended]

Please note that sometimes application receives buffers from another driver or 
from some codecs engine that's why input and output buffer will never be of 
same size.

2) V4L2-buf layer doesn't support IOMEM coming from user application. Just to 
give low level details about this - 

When application tries to configure for 'V4L2_MEMORY_USERPTR' with buffer 
coming from another driver (which is iomampped), then QUEUEBUF ioctl will fail 
from 'videobuf_iolock' -- videobuf_dma_init_user_locked -- get_user_pages.

In 'get_user_pages' it checks for IOMEM flag and returns error, which is 
expected behavior from Kernel point of view. We are trying to map buffer which 
is already mapped to kernel by another driver.

One thing I am not able to understand, how nobody came across such use-case 
which is very common. And to address this issue we need to add support for 
IOMEM in V4L2-buf layer.

NOTE: Currently both of these issues have been addressed as a custom 
implementation for our internal use case.

Backward Compatibility - 
---

This is an important aspect, since similar hardware modules are available on 
Davinci as well as on OMAP and their driver interface is completely different.

On Davinci, resizer driver is supported through plane char driver interface 
which handles all data/buffer processing and control paths. It maintains 
internal queue for priority of resizing tasks and stuff.

The driver is present under /drivers/char/Davinci.

Here I feel, V4L2 way is better, since all image processing drivers should go 
under drivers/media/video/. And again we can make use of readily available 
V4L2 framework interface for data and control path to manage buffers. We should 
enhance V4L2 framework to support such devices.


Proposed Required Changes -
--

I am putting some high level changes required to be done for supporting such 
devices - 

- Enhancement in V4L2-buf layer for above issues

- Will be directly using sub-device frame-work and have to enhance it 
to support such devices.

- Below are the parameters we need to configure for Resizer from user 
application - 

  __s32 in_hsize;/* input frame horizontal size.*/
  __s32 in_vsize;/* input frame vertical size */
  __s32 in_pitch;/* offset between 2 rows of input frame.*/
  __s32 inptyp;  /* for determining 16 bit or 8 bit data.*/
  __s32 vert_starting_pixel; /* vertical starting pixel in input.*/
  __s32 horz_starting_pixel; /* horizontal starting pixel in input.*/
  __s32 cbilin;  /* filter with luma or bi-linear interpolation.*/
  __s32 pix_fmt; /* UYVY or YUYV */
  __s32 out_hsize;   /* output frame horizontal size. */
  __s32 out_vsize;   /* output frame vertical size.*/
  __s32 out_pitch;   /* offset between 2 rows of output frame.*/
  __s32 hstph;   /* for specifying horizontal starting phase.*/
  __s32 vstph;   /* for specifying vertical starting phase.*/
  __u16 tap4filt_coeffs[32]; /* horizontal filtercoefficients.*/
  __u16 tap7filt_coeffs[32]; /* vertical filter coefficients. */
  struct rsz_yenh yenh_params;

(Pasted from previous patches posted by Sergio)


Putting one sample proposal using VIDIOC_S_FMT -

APPROACH 1 -
--

Either we can add this under struct v4l2_format or need to enhance stuct 
v4l2_crop to support such device.

We can use 'VIDIOC_S_FMT' ioctl to configure the resizer parameters. From top 
level it will look something like -

struct v4l2_buffer buf;
struct

RE: BT656 Support and MMDC support on top of OMAP3EVM

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Hiremath, Vaibhav
 Sent: Thursday, March 19, 2009 5:57 PM
 To: linux-me...@vger.kernel.org
 Cc: linux-omap@vger.kernel.org; psp_vi...@list.ti.com - Video
 discussion list for PSP Video team (May contain non-TIers)
 Subject: [PSP_VIDEO] BT656 Support and MMDC support on top of
 OMAP3EVM

 Hi,

 I am getting some private requests for supporting BT656 and Multi-
 Media Daughter card on top of latest Kernel + Sakari's latest ISP-
 Camera patches/repository. So I am posting the patch supporting
 BT656 and MMDC support with all the review comments fixed (received
 from earlier posts).

 Please note that, hence forth I will try to avoid submitting patches
 on top of V4L2-int framework. The next immediate activity would be
 migration to sub-device framework.

 Sakari,

 How about merging these patches (BT656 support patch) into your
 repository so that I don't have to maintain and re-submit the
 patches again and again.

[Hiremath, Vaibhav] Sakari,

I have not heard back anything from you on this, if you don't see any issues 
then I request you to merge these patches into your private branch/repository. 
So that people will be able to use it directly.

 If you feel it should be done, then please let me know if you have
 any review comments I will try to fix immediately and provide you a
 patch.

 The patches are following this mail.

 Thanks,
 Vaibhav Hiremath

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Koen Kooi [mailto:k.k...@student.utwente.nl]
 Sent: Monday, March 30, 2009 8:54 PM
 To: Hiremath, Vaibhav
 Cc: linux-me...@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto;
 DongSoo(Nathaniel) Kim; Toivonen Tuukka.O (Nokia-D/Oulu); linux-
 o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Hans Verkuil;
 Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar,
 Purushotam
 Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support
 under V4L2 framework

 Op 30 mrt 2009, om 16:34 heeft Hiremath, Vaibhav het volgende
 geschreven:

  Hi,

  With reference to the mail-thread started by Sakari on Resizer
  driver interface,

  http://marc.info/?l=linux-omapm=123628392325716w=2

  I would like to bring some issues and propose changes to adapt
 such
  devices under V4L2 framework. Sorry for delayed response on this
  mail-thread, actually I was on vacation.

 I extracted a patch from that branch, but I can't figure out how to
 actually enable the resizer on beagleboard, overo and omapzoom,
 since
 the patches to do that seem to be missing from the branches of the
 ISP
 tree. Any clue where I can get those?

[Hiremath, Vaibhav] If I understand correctly, Sakari has removed stand-alone 
drivers (both resizer and previewer) from his patch-sets. I have ported it for 
our release. And this RFC is about supporting these drivers, since the current 
implementation has custom interface.

 Also, any test apps for the new code? AIUI dmai doesn't understand
 the
 new code yet.

[Hiremath, Vaibhav] I can provide you the sample application, can you please 
provide me your code-base for ISP and resizer?

 regards,

 Koen
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Aguirre Rodriguez, Sergio Alberto
 Sent: Monday, March 30, 2009 9:10 PM
 To: Hiremath, Vaibhav; linux-me...@vger.kernel.org
 Cc: DongSoo(Nathaniel) Kim; Toivonen Tuukka.O (Nokia-D/Oulu); linux-
 o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Hans Verkuil;
 Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar,
 Purushotam
 Subject: RE: [RFC] Stand-alone Resizer/Previewer Driver support
 under V4L2 framework

 Hi Vaibhav,

 Please find some comments below

  -Original Message-
  From: Hiremath, Vaibhav
  Sent: Monday, March 30, 2009 8:35 AM
  To: linux-me...@vger.kernel.org
  Cc: Aguirre Rodriguez, Sergio Alberto; DongSoo(Nathaniel) Kim;
 Toivonen
  Tuukka.O (Nokia-D/Oulu); linux-omap@vger.kernel.org; Nagalla,
 Hari; Sakari
  Ailus; Hans Verkuil; Jadav, Brijesh R; R, Sivaraj; Hadli,
 Manjunath; Shah,
  Hardik; Kumar, Purushotam
  Subject: [RFC] Stand-alone Resizer/Previewer Driver support under
 V4L2
  framework

  Hi,

  With reference to the mail-thread started by Sakari on Resizer
 driver
  interface,

  http://marc.info/?l=linux-omapm=123628392325716w=2

  I would like to bring some issues and propose changes to adapt
 such
  devices under V4L2 framework. Sorry for delayed response on this
 mail-
  thread, actually I was on vacation.

  As proposed by Sakari, I do agree with the approach of having V4L2
  interface for memory-to-memory operation of the ISP (like resizer
 and
  previewer), but I would like to bring some important
 aspects/issues here -

  - Some drawbacks of V4L2-buf layer framework for such kind of
  devices
  - Need for backward compatibility.

  Drawbacks for V4L2-Buf layer -
  -

  1} In case of resizer driver, the input buffer will always be
 different
  than output buffer.

  In case of Mmapped buffer there is no issue, since driver
 allocates
  maximum of input and output. User doesn't have control on this,
 although
  there is loss of memory from system point of view.

  In case of User Pointer Exchange, User would expect and may
 allocate
  different sizes of buffers for input and output which V4L2-buf
 layer
  doesn't support with single queue. And to address this, I think
 here we
  need to have either of following approaches -

  - Use two separate buffer queues, one for input and another
 for
  output.
  - Or hack the driver for v4l2_buffer, internally using
 different
  buffer params for input and output. [Not recommended]

  Please note that sometimes application receives buffers from
 another
  driver or from some codecs engine that's why input and output
 buffer will
  never be of same size.

  2) V4L2-buf layer doesn't support IOMEM coming from user
 application. Just
  to give low level details about this -

  When application tries to configure for 'V4L2_MEMORY_USERPTR' with
 buffer
  coming from another driver (which is iomampped), then QUEUEBUF
 ioctl will
  fail from 'videobuf_iolock' -- videobuf_dma_init_user_locked --
  get_user_pages.

  In 'get_user_pages' it checks for IOMEM flag and returns error,
 which is
  expected behavior from Kernel point of view. We are trying to map
 buffer
  which is already mapped to kernel by another driver.

 I'm not sure if I understood the problem right... Can you please
 help me clarify?

 So, basically the problem is that both drivers needs to associate a
 single buffer with 2 different DMA transfers at the same time (one
 from other driver, and other from ISP) Is that correct?

[Hiremath, Vaibhav] No, 

Let's take real-time example here, say you have 128 Mb DDR available with you 
and you have asked linux to use only say 80Mb. And rest of the memory you are 
mapping to kernel from some another driver using ioremap.

This is valid use-case, since most of application does this due to memory 
fragmentation.

Now you want to use this ioremapped buffer for your capture driver as a use 
pointer exchange mechanism. And here it fails due to issues as I explained 
before.

  One thing I am not able to understand, how nobody came across such
 use-
  case which is very common. And to address this issue we need to
 add
  support for IOMEM in V4L2-buf layer.

  NOTE: Currently both of these issues have been addressed as a
 custom
  implementation for our internal use case.

  Backward Compatibility -
  ---

  This is an important aspect, since similar hardware modules are
 available
  on Davinci as well as on OMAP and their driver interface is
 completely
  different.

  On Davinci, resizer driver is supported through plane char driver
  interface which handles all data/buffer processing and control
 paths. It
  maintains internal queue for priority of resizing tasks and stuff.

  The driver is present under /drivers/char/Davinci.

  Here I feel, V4L2 way is better, since all image processing
 drivers should
  go under drivers/media/video/. And again we can

BT656 Support and MMDC support on top of OMAP3EVM

2009-03-19 Thread Hiremath, Vaibhav

Hi,

I am getting some private requests for supporting BT656 and Multi-Media 
Daughter card on top of latest Kernel + Sakari's latest ISP-Camera 
patches/repository. So I am posting the patch supporting BT656 and MMDC support 
with all the review comments fixed (received from earlier posts).

Please note that, hence forth I will try to avoid submitting patches on top of 
V4L2-int framework. The next immediate activity would be migration to 
sub-device framework.

Sakari,

How about merging these patches (BT656 support patch) into your repository so 
that I don't have to maintain and re-submit the patches again and again. 

If you feel it should be done, then please let me know if you have any review 
comments I will try to fix immediately and provide you a patch.

The patches are following this mail.

Thanks,
Vaibhav Hiremath

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Embedded Linux Conference

2009-03-17 Thread Hiremath, Vaibhav

 -Original Message-
 From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
 Sent: Tuesday, March 17, 2009 4:22 AM
 To: Hans Verkuil
 Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Hadli,
 Manjunath; DongSoo(Nathaniel) Kim; Aguirre Rodriguez, Sergio
 Alberto; Hiremath, Vaibhav
 Subject: Re: Embedded Linux Conference

 Hans Verkuil hverk...@xs4all.nl writes:

  Just FYI:

  I'll be attending the Embedded Linux Conference in San Francisco,
 April
  6th-8th (http://www.embeddedlinuxconference.com/elc_2009).

  This might be a good opportunity to discuss omap and davinci V4L2
 issues
  face-to-face. Let me know if you are interested.

[Hiremath, Vaibhav] Unfortunately I will not be able to attend :)

Thanks,
Vaibhav Hiremath

 I will be there as well, and while not directly involved with V4L2,
 I'm involved in various parts of getting OMAP and DaVinci devices
 supported in mainline kernels.

 Kevin

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: I have some questions about DSS.

2009-03-15 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

From: InKi Dae [mailto:daei...@gmail.com] 
Sent: Sunday, March 15, 2009 12:28 PM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org
Subject: I have some questions about DSS.

I am trying to draw 720P streamming images decoded on LCD.
I really wonder about that.
In case of OMAP34XX, only video1 and video2 layer support color space 
conversion, scaling, rotation.
I think that ways using these features are like below.

[Hiremath, Vaibhav] Rotation is independent on plane, we are supporting 
rotation through VRFB.

1. Application - video1 or 2 device node - V4L2 Interface - DSS Library - 
LCD Panel or Digital output.
2. Application - fb1 or 2 device node - omafb driver - DSS Library - LCD 
Panel or Digital output.

[Hiremath, Vaibhav] Both the methods are working fine, at-least I have tested 
both.

Are all of the 1 and 2 case possible to draw 720P streamming images on LCD 
Panel in real-time ?
If the case of 1 is impossible, why impossible, and what is the reason 
implementing like case 2 ?
If possible, What is the way better ?

[Hiremath, Vaibhav]For streaming kind of application I would suggest you to use 
V4L2 framework.

Could you please tell me you know and you think ?
Thank you,
- InKi -
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Suspend/Resume support with Omap2fb

2009-03-13 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
 Sent: Friday, March 13, 2009 2:01 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org
 Subject: RE: Suspend/Resume support with Omap2fb

 Hi,

 On Thu, 2009-03-12 at 19:26 +0100, ext Hiremath, Vaibhav wrote:
  Hi,

  Finally I could able to find the root-cause, actually some of the
 previous observations miss-led me to dig into power management,
 suspend/resume path and clock structure. But after bit debugging and
 with the help of Sanjeev, we got the rid of it.

  The issue is with DSS2 library, inside function
 dpi_display_suspend. It calls dispc_enable_lcd_out(0), but doesn't
 wait till the frame-done interrupt. And due to this I was getting
 some abrupt behavior in suspend/resume path.
  Actually in the beginning I overlooked legacy frame-buffer driver,
 which handles this scenario perfectly.

 dispc_enable_lcd_out(0) waits for FRAMEDONE. Please use the latest
 DSS2
 version from my git repository =).

[Hiremath, Vaibhav] Ohhh great, but I think yesterday only I pulled changes 
from your repository, and it was not there. 

Ok, but it's great that you merged the change.

  Tomi

  For Display sub-system we have 2 interface clocks coming, L3_ICLK
 and L4_ICLK. Out of these, L4_ICLK goes to Display register access
 and L3_ICLK goes to DMA register. In our suspend call we are
 disabling clocks for L3_ICLK (we don't control L4_ICLK), and due to
 this L4_ICLK stays attached with GFX. You will only be able to find
 out this by looking to CM_CLKSTST_DSS.CLKACTIVITY_DSS, which is set
 1 and indicates some interface clock is still active in DSS domain.

  Below is the patch which will explain the change

  +#include linux/completion.h
  +#include linux/jiffies.h

  +static void dpi_display_isr(void *arg, unsigned int irqstatus)
  +{
  +   struct omap_display *display = (struct omap_display *)arg;
  +
  +   complete(display-frame_done);
  +}

  static int dpi_display_suspend(struct omap_display *display)
   {
  +   void *handle = NULL;
  +
  if (display-state != OMAP_DSS_DISPLAY_ACTIVE)
  return -EINVAL;

  if (display-panel-suspend)
  display-panel-suspend(display);

  +   /*
  +* Wait for frame done interrupt
  +*/
  +   handle = omap_dispc_register_isr(dpi_display_isr, display,
  +   DISPC_IRQ_FRAMEDONE);
  +   if (!handle)
  +   return -EINVAL;
  +
  +   init_completion(display-frame_done);
  +
  dispc_enable_lcd_out(0);
  +   if (!wait_for_completion_timeout(display-frame_done,
  +   msecs_to_jiffies(500))) {
  +   printk(timeout waiting for FRAME DONE\n);
  +   }

  Still I need to test this thoroughly, I may hit some another issue
 (Already I am seeing some crashes also when off state is enabled). I
 will create consolidated patch for this and will submit to list.

  Thanks,
  Vaibhav Hiremath

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Suspend/Resume support with Omap2fb

2009-03-13 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
 Sent: Friday, March 13, 2009 2:44 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org
 Subject: RE: Suspend/Resume support with Omap2fb

 On Fri, 2009-03-13 at 10:10 +0100, ext Hiremath, Vaibhav wrote:

  Thanks,
  Vaibhav Hiremath

   -Original Message-
   From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
   Sent: Friday, March 13, 2009 2:01 PM
   To: Hiremath, Vaibhav
   Cc: linux-omap@vger.kernel.org
   Subject: RE: Suspend/Resume support with Omap2fb

   Hi,

   On Thu, 2009-03-12 at 19:26 +0100, ext Hiremath, Vaibhav wrote:
Hi,

Finally I could able to find the root-cause, actually some of
 the
   previous observations miss-led me to dig into power management,
   suspend/resume path and clock structure. But after bit debugging
 and
   with the help of Sanjeev, we got the rid of it.

The issue is with DSS2 library, inside function
   dpi_display_suspend. It calls dispc_enable_lcd_out(0), but
 doesn't
   wait till the frame-done interrupt. And due to this I was
 getting
   some abrupt behavior in suspend/resume path.
Actually in the beginning I overlooked legacy frame-buffer
 driver,
   which handles this scenario perfectly.

   dispc_enable_lcd_out(0) waits for FRAMEDONE. Please use the
 latest
   DSS2
   version from my git repository =).

  [Hiremath, Vaibhav] Ohhh great, but I think yesterday only I
 pulled changes from your repository, and it was not there.

  Ok, but it's great that you merged the change.

 No, it's been there for quite a while... (weeks, months, I don't
 remember).

[Hiremath, Vaibhav] May be I looked into wrong branch, can you please provide 
in which branch of yours the change is? So that I can validate my changes and 
make it more close to yours, it will be easy for me to migrate in the future.

  Tomi

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Suspend/Resume support with Omap2fb

2009-03-12 Thread Hiremath, Vaibhav


Hi,

Finally I could able to find the root-cause, actually some of the previous 
observations miss-led me to dig into power management, suspend/resume path and 
clock structure. But after bit debugging and with the help of Sanjeev, we got 
the rid of it.

The issue is with DSS2 library, inside function dpi_display_suspend. It calls 
dispc_enable_lcd_out(0), but doesn't wait till the frame-done interrupt. And 
due to this I was getting some abrupt behavior in suspend/resume path. 
Actually in the beginning I overlooked legacy frame-buffer driver, which 
handles this scenario perfectly.
 
For Display sub-system we have 2 interface clocks coming, L3_ICLK and L4_ICLK. 
Out of these, L4_ICLK goes to Display register access and L3_ICLK goes to DMA 
register. In our suspend call we are disabling clocks for L3_ICLK (we don't 
control L4_ICLK), and due to this L4_ICLK stays attached with GFX. You will 
only be able to find out this by looking to CM_CLKSTST_DSS.CLKACTIVITY_DSS, 
which is set 1 and indicates some interface clock is still active in DSS domain.

Below is the patch which will explain the change 


+#include linux/completion.h
+#include linux/jiffies.h

+static void dpi_display_isr(void *arg, unsigned int irqstatus)
+{
+   struct omap_display *display = (struct omap_display *)arg;
+
+   complete(display-frame_done);
+}

static int dpi_display_suspend(struct omap_display *display)
 {
+   void *handle = NULL;
+
if (display-state != OMAP_DSS_DISPLAY_ACTIVE)
return -EINVAL;

if (display-panel-suspend)
display-panel-suspend(display);

+   /*
+* Wait for frame done interrupt
+*/
+   handle = omap_dispc_register_isr(dpi_display_isr, display,
+   DISPC_IRQ_FRAMEDONE);
+   if (!handle)
+   return -EINVAL;
+
+   init_completion(display-frame_done);
+
dispc_enable_lcd_out(0);
+   if (!wait_for_completion_timeout(display-frame_done,
+   msecs_to_jiffies(500))) {
+   printk(timeout waiting for FRAME DONE\n);
+   }

Still I need to test this thoroughly, I may hit some another issue (Already I 
am seeing some crashes also when off state is enabled). I will create 
consolidated patch for this and will submit to list.

Thanks,
Vaibhav Hiremath
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Suspend/Resume support with Omap2fb

Hi,

I am using New Frame-Buffer driver which is based on DSS2 library submitted by 
Tomi, and I am trying to add full power management support. But things are not 
working out as expected, every time when I am issuing command echo mem  
/sys/power/state the system doesn't go into off state. It always points to 
dss_prwdm, below are the steps I am following - 

- Build the kernel with CPU_IDLE
- Enable all the PM flags 

# echo 1  /sys/power/sleep_while_idle
# echo 1  /sys/power/clocks_off_while_idle
# echo 1  /sys/power/enable_off_mode

- From Linux prompt issue command 

# echo mem  /sys/power/state

The log is - 


r...@arago:~# echo mem  /sys/power/state
6PM: Syncing filesystems ... PM: Syncing filesystems ... done.
done.
Freezing user space processes ... Freezing user space processes ... (elapsed 
0.00 seconds) (elapsed 0.00 seconds) done.
done.
Freezing remaining freezable tasks ... Freezing remaining freezable tasks ... 
(elapsed 0.06 seconds) (elapsed 0.06 seconds) done.done.
Suspending console(s) (use no_console_suspend to debug)
Suspending console(s) (use no_console_suspend to debug)
6omap-backlight: suspending...
omapfb_suspend

omapfb_resume
6omap-backlight: resuming...
omap-backlight: suspending...
omapfb_suspend
Powerdomain (core_pwrdm) didn't enter target state 0
Powerdomain (dss_pwrdm) didn't enter target state 0
Powerdomain (per_pwrdm) didn't enter target state 0
Could not enter target state in pm_suspend
eth0: link down
omapfb_resume
omap-backlight: resuming...
Restarting tasks ... Restarting tasks ... done.
done.

r...@arago:~#


Some analysis which I observed during debugging this issue - 

- The root-cause is, DSS PowerDomain always shows it is in ON state 
(PWRDM_POWER_ON), and if I understand correctly this is only dependent on 
clocks. But I am making sure that DSS clocks are disabled. And with CPU_IDLE 
enabled I am going to complete OFF state. 
(/sys/devices/system/cpu/cpu0/cpuidle/state5/usage is incrementing).

- If I compile out framebuffer driver and include DSS2 and V4L2 driver, 
everything works fine. I am not sure how omapfb is being tied with 
PowerDomain. Again I have seen references in arch/arm/mach-omap2/omapdev3xxx.h 
to the pdev_name = omapfb, not sure how this is being used. 
 
I believe if system is hitting OFF state, then my enable/disable paths are 
proper, but really not sure about why mem is causing problem here.

Thanks,
Vaibhav Hiremath
Platform Support Products
Texas Instruments Inc
Ph: +91-80-25099927


Thanks,
Vaibhav Hiremath
Platform Support Products
Texas Instruments Inc
Ph: +91-80-25099927

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Suspend/Resume support with Omap2fb

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
 Sent: Wednesday, March 11, 2009 1:23 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org
 Subject: Re: Suspend/Resume support with Omap2fb

 Hi,

 On Wed, 2009-03-11 at 07:55 +0100, ext Hiremath, Vaibhav wrote:
  Hi,

  I am using New Frame-Buffer driver which is based on DSS2 library
 submitted by Tomi, and I am trying to add full power management
 support. But things are not working out as expected, every time when
 I am issuing command echo mem  /sys/power/state the system
 doesn't go into off state. It always points to dss_prwdm, below are
 the steps I am following -

 OFF mode should work. I have verified it with DSI, DPI and SDI.
 However,
 it needs passing the get_last_off_on_transaction_id pointer in
 omap_dss_platform_data.

 Also, see below.

[Hiremath, Vaibhav] I believe this is only required when you do save and 
restore context right?
Actually I have modified that part of code where it doesn't expect this pointer 
and save/restore happens perfectly fine, which I am very will sure about, since 
I am hitting state5 of CPU_IDLE (Full OFF state) and it resumes back with the 
same state.

Again one more data point which I missed in last mail is, I am following 
clk-usecount which shows me 0. That means clocks are already disabled.

r...@arago:~# cat /sys/devices/platform/omap-dss/clk
- dss -
internal clk count  0
dss_ick 83000
dss1_alwon_fck  96000
dss2_alwon_fck  13000
dss_tv_fck  54000
dss_96m_fck 96000
- dispc -
dispc fclk source = dss1_alwon_fclk
pixel clk = 9600 / 1 / 5 = 1920
r...@arago:~#

  - Build the kernel with CPU_IDLE
  - Enable all the PM flags

  # echo 1  /sys/power/sleep_while_idle
  # echo 1  /sys/power/clocks_off_while_idle
  # echo 1  /sys/power/enable_off_mode

  - From Linux prompt issue command

  # echo mem  /sys/power/state

  The log is -

  r...@arago:~# echo mem  /sys/power/state
  6PM: Syncing filesystems ... PM: Syncing filesystems ... done.
  done.
  Freezing user space processes ... Freezing user space processes
 ... (elapsed 0.00 seconds) (elapsed 0.00 seconds) done.
  done.
  Freezing remaining freezable tasks ... Freezing remaining
 freezable tasks ... (elapsed 0.06 seconds) (elapsed 0.06 seconds)
 done.done.
  Suspending console(s) (use no_console_suspend to debug)
  Suspending console(s) (use no_console_suspend to debug)
  6omap-backlight: suspending...
  omapfb_suspend

  omapfb_resume
  6omap-backlight: resuming...
  omap-backlight: suspending...
  omapfb_suspend
  Powerdomain (core_pwrdm) didn't enter target state 0
  Powerdomain (dss_pwrdm) didn't enter target state 0
  Powerdomain (per_pwrdm) didn't enter target state 0
  Could not enter target state in pm_suspend
  eth0: link down
  omapfb_resume
  omap-backlight: resuming...
  Restarting tasks ... Restarting tasks ... done.
  done.

  r...@arago:~#

  Some analysis which I observed during debugging this issue -

  - The root-cause is, DSS PowerDomain always shows it is in ON
 state (PWRDM_POWER_ON), and if I understand correctly this is only
 dependent on clocks. But I am making sure that DSS clocks are
 disabled. And with CPU_IDLE enabled I am going to complete OFF
 state. (/sys/devices/system/cpu/cpu0/cpuidle/state5/usage is
 incrementing).

  - If I compile out framebuffer driver and include DSS2 and
 V4L2 driver, everything works fine. I am not sure how omapfb is
 being tied with PowerDomain. Again I have seen references in
 arch/arm/mach-omap2/omapdev3xxx.h to the pdev_name = omapfb, not
 sure how this is being used.

 You have to change it to omapdss (or omap-dss in earlier DSS2
 versions).

[Hiremath, Vaibhav] I have tried this option also, didn't work out.
Tomi,

Do you have summary or list of changes required in clock and PowerDomain 
related files to make it work?

How have you tested this? 
Have you also tested with echo mem  /sys/power/state?
Are you using Kevin's power management tree? What is default configuration of 
your kernel during this test?

  Tomi

  I believe if system is hitting OFF state, then my enable/disable
 paths are proper, but really not sure about why mem is causing
 problem here.

  Thanks,
  Vaibhav Hiremath
  Platform Support Products
  Texas Instruments Inc
  Ph: +91-80-25099927

  Thanks,
  Vaibhav Hiremath
  Platform Support Products
  Texas Instruments Inc
  Ph: +91-80-25099927

  --
  To unsubscribe from this list: send the line unsubscribe linux-
 omap in
  the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org

RE: Suspend/Resume support with Omap2fb

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
 Sent: Wednesday, March 11, 2009 3:01 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org
 Subject: RE: Suspend/Resume support with Omap2fb

 On Wed, 2009-03-11 at 09:46 +0100, ext Hiremath, Vaibhav wrote:

  Thanks,
  Vaibhav Hiremath

   -Original Message-
   From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
   Sent: Wednesday, March 11, 2009 1:23 PM
   To: Hiremath, Vaibhav
   Cc: linux-omap@vger.kernel.org
   Subject: Re: Suspend/Resume support with Omap2fb

   Hi,

   On Wed, 2009-03-11 at 07:55 +0100, ext Hiremath, Vaibhav wrote:
Hi,

I am using New Frame-Buffer driver which is based on DSS2
 library
   submitted by Tomi, and I am trying to add full power management
   support. But things are not working out as expected, every time
 when
   I am issuing command echo mem  /sys/power/state the system
   doesn't go into off state. It always points to dss_prwdm, below
 are
   the steps I am following -

   OFF mode should work. I have verified it with DSI, DPI and SDI.
   However,
   it needs passing the get_last_off_on_transaction_id pointer in
   omap_dss_platform_data.

   Also, see below.

  [Hiremath, Vaibhav] I believe this is only required when you do
 save and restore context right?

 Well, yes. But you need to save and restore context if you want OFF
 mode.

[Hiremath, Vaibhav] As I mentioned I am hitting full OFF state (state5), and 
save and restore is happening perfectly fine.

  Actually I have modified that part of code where it doesn't expect
 this pointer and save/restore happens perfectly fine, which I am
 very will sure about, since I am hitting state5 of CPU_IDLE (Full
 OFF state) and it resumes back with the same state.

  Again one more data point which I missed in last mail is, I am
 following clk-usecount which shows me 0. That means clocks are
 already disabled.

  r...@arago:~# cat /sys/devices/platform/omap-dss/clk
  - dss -
  internal clk count  0
  dss_ick 83000
  dss1_alwon_fck  96000
  dss2_alwon_fck  13000
  dss_tv_fck  54000
  dss_96m_fck 96000
  - dispc -
  dispc fclk source = dss1_alwon_fclk
  pixel clk = 9600 / 1 / 5 = 1920
  r...@arago:~#

- Build the kernel with CPU_IDLE
- Enable all the PM flags

# echo 1  /sys/power/sleep_while_idle
# echo 1  /sys/power/clocks_off_while_idle
# echo 1  /sys/power/enable_off_mode

- From Linux prompt issue command

# echo mem  /sys/power/state

The log is -

r...@arago:~# echo mem  /sys/power/state
6PM: Syncing filesystems ... PM: Syncing filesystems ...
 done.
done.
Freezing user space processes ... Freezing user space
 processes
   ... (elapsed 0.00 seconds) (elapsed 0.00 seconds) done.
done.
Freezing remaining freezable tasks ... Freezing remaining
   freezable tasks ... (elapsed 0.06 seconds) (elapsed 0.06
 seconds)
   done.done.
Suspending console(s) (use no_console_suspend to debug)
Suspending console(s) (use no_console_suspend to debug)
6omap-backlight: suspending...
omapfb_suspend

omapfb_resume
6omap-backlight: resuming...
omap-backlight: suspending...
omapfb_suspend
Powerdomain (core_pwrdm) didn't enter target state 0
Powerdomain (dss_pwrdm) didn't enter target state 0
Powerdomain (per_pwrdm) didn't enter target state 0
Could not enter target state in pm_suspend
eth0: link down
omapfb_resume
omap-backlight: resuming...
Restarting tasks ... Restarting tasks ... done.
done.

r...@arago:~#

Some analysis which I observed during debugging this issue -

- The root-cause is, DSS PowerDomain always shows it is
 in ON
   state (PWRDM_POWER_ON), and if I understand correctly this is
 only
   dependent on clocks. But I am making sure that DSS clocks are
   disabled. And with CPU_IDLE enabled I am going to complete OFF
   state. (/sys/devices/system/cpu/cpu0/cpuidle/state5/usage is
   incrementing).

- If I compile out framebuffer driver and include DSS2
 and
   V4L2 driver, everything works fine. I am not sure how omapfb
 is
   being tied with PowerDomain. Again I have seen references in
   arch/arm/mach-omap2/omapdev3xxx.h to the pdev_name = omapfb,
 not
   sure how this is being used.

   You have to change it to omapdss (or omap-dss in earlier DSS2
   versions).

  [Hiremath, Vaibhav] I have tried this option also, didn't work
 out.
  Tomi,

  Do you have summary or list of changes required in clock and
 PowerDomain related files to make it work?

  How have you tested this?
  Have you also tested with echo mem  /sys/power/state?
  Are you using Kevin's power management tree? What

RE: Suspend/Resume support with Omap2fb

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
 Sent: Wednesday, March 11, 2009 6:20 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org
 Subject: RE: Suspend/Resume support with Omap2fb

 On Wed, 2009-03-11 at 11:47 +0100, ext Hiremath, Vaibhav wrote:

How have you tested this?
Have you also tested with echo mem  /sys/power/state?
Are you using Kevin's power management tree? What is default
   configuration of your kernel during this test?

   It's been some time since I tested it, but it did work on OMAP3
 SDP
   with
   the pm-branch. Only changed needed were the
   get_last_off_on_transaction_id and omapfb - omapdss. I also
 tested
   echo
   mem  

   I'll try to find time to test it again with latest trees.

  [Hiremath, Vaibhav] That would be great, I am also trying few
 things here at my end. Hopefully I will get something.

 Yeah, it works ok for me. I rebased my DSS2 tree to latest l-o, then
 merged pm-branch, and made the changes mentioned above. I get some
 warnings from getnstimeofday when resuming the kernel, but they seem
 to
 be unrelated to DSS, and the image is fine after resume. I used my
 dss_omap_3430sdp_defconfig and made the following commands to enable
 PM:

 echo 1  /sys/power/clocks_off_while_idle
 echo 1  /sys/power/enable_off_mode
 echo 1  /sys/power/voltage_off_while_idle
 echo 1  /sys/power/sleep_while_idle

[Hiremath, Vaibhav] Tomi, I looked into your latest code base, and I can see 
that you have added suspend and resume functionality and as you mentioned it is 
working for you.

The only difference I could point out here is, I am handling suspend at driver 
level (fb and v4l2) and you are handling it at DSS2 level. I can give try to 
your implementation; tomorrow morning after reaching to office first thing I 
will try this and let you know.

Just to share with wider audience, I am seeing some abrupt behavior and I doubt 
some timing synchronization is causing problem. I could see suspend is working 
if I comment ovl-enable or if I call echo gfx e:0  
/sys/devices/platform/omapfb/overlays. Although I have same implementation in 
omapfb_suspend and it does disables clock and overlay, system doesn't go to off 
state. It always gives error for dss_prwm.

Tomi,
Can you try enabling CONFIG_CPU_IDLE flag and see whether it is going to state5 
or not? 

And I think it won't go due to obvious reasons, framebuffer will hold the 
clocks. You have to have something in your framebuffer driver to trigger 
display disable. I have implemented timer here to do that.

I will send you the patch once I get rid of this issue.

  Tomi

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: What did omap2_disp_get_dss morph into?

2009-03-10 Thread Hiremath, Vaibhav

Hi David,

You must be having struct omap_display pointer populated in your driver 
during probe, you just need to stick with display-enable and
Display-disable function call. These functions in turn enables and disables 
clocks and save/restores the context.

If you provide some more details about your use case, then I would be able to 
understand better.

One more thing I just wanted to share, there some bugs we found during our 
release cycle in save and restore context path which I will be publishing soon. 
So please let me know if you are facing some issues, I can assist you with this.

Thanks,
Vaibhav Hiremath
Platform Support Products
Texas Instruments Inc
Ph: +91-80-25099927
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of david.hag...@gmail.com
 Sent: Wednesday, March 11, 2009 2:02 AM
 To: linux-omap@vger.kernel.org
 Subject: What did omap2_disp_get_dss morph into?
 
 I am trying to get the TI accelerated video driver to build against
 the
 current DSS2 kernel image, and I think I am this close || to getting
 it to
 go, but I am missing a pair of functions: omap2_disp_get_dss and
 omap2_disp_put_dss.
 
 Obviously, they've changed into something else - what did they morph
 into?
 
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-
 omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC 0/9] OMAP3 ISP and camera drivers

2009-03-04 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Sakari Ailus
 Sent: Tuesday, March 03, 2009 3:37 PM
 To: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org
 Cc: Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka Olli Artturi;
 Hiroshi DOYU; DongSoo Kim
 Subject: [RFC 0/9] OMAP3 ISP and camera drivers

 Hi,

 So here's the patchset for OMAP 3 ISP and camera drivers plus the
 associated V4L changes. Sergio Aguirre has been posting a related
 patchset earlier, containing also sensor and lens driver used on
 SDP.
 This patchset is agains the linux-omap tree:

 URL:http://www.muru.com/linux/omap/README_OMAP_GIT

[Hiremath, Vaibhav] Sakari, Let me ask you basic question, have you 
tested/verified these patch-sets?

The reason I am asking this question is, for me it was not working. I had to 
debug this and found that - 

- Changes missing in devices.c file, so isp_probe function will not be 
called at all, keeping omap3isp = NULL. You will end up into kernel crash in 
omap34xxcam_device_register.

- The patches from Hiroshi DOYU doesn't build as is, you need to add 
one include line #include linux/hardirq.h in iovmmu.c
(I am using the patches submitted on 16th Jan 2009)

I have attached git diff output here with this mail for reference.

Am I missing any patches here? I am not sure how Sergio is able to use these 
patches?
If I am not missing anything, then I think you should mention all these issues 
clearly in the patch so that anybody who might want to use will not suffer.

 So I and Sergio have synchronised our versions of the ISP and camera
 drivers and this is the end result. There is still a lot of work to
 do,
 though. You can find some comments in individual patch descriptions.
 If
 the todo list for a patch is empty it doesn't mean there wouldn't be
 anything left to do. ;)

 There's at least one major change to Sergio Aguirre's earlier
 patches
 which is that the ISP driver now uses the IOMMU from Hiroshi Doyu.
 Hiroshi is away for some time now so there are just some hacks on
 top of
 Hiroshi's older iommu patches to use with current linux-omap.

 This patchset does not contain the resizer or preview wrappers from
 TI
 but they have been left intentionally out. A proper interface (V4L)
 should be used for those and the camera driver should be somehow
 involved --- the wrappers are just duplicating much of the camera
 driver's functionality.

 I don't have any sensor or lens drivers to publish at this time.

 This patchset should work with the SDP and OMAPZoom boards although
 you
 need the associated sensor drivers + the board code from Sergio
 Aguirre
 to use it. You'll also need the IOMMU patchset from Hiroshi Doyu.
 Everything except the sensor / board stuff is available here:

 URL:http://www.gitorious.org/projects/omap3camera

 In short, on linux-omap:

 $ git pull http://git.gitorious.org/omap3camera/mainline.git v4l \
iommu omap3camera base

 Hiroshi's original iommu tree is here (branch iommu):

 URL:http://git.gitorious.org/lk/mainline.git

 Some of the camera and ISP driver development history is available,
 too.
 See the first link.

 Any feedback is appreciated.

 Sincerely,

 --
 Sakari Ailus
 sakari.ai...@maxwell.research.nokia.com

 --
 To unsubscribe from this list: send the line unsubscribe linux-
 media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

isp_patch_fix.patch
Description: isp_patch_fix.patch

RE: [RFC 0/9] OMAP3 ISP and camera drivers

2009-03-04 Thread Hiremath, Vaibhav



Thanks,
Vaibhav Hiremath

 -Original Message-
 From: DongSoo(Nathaniel) Kim [mailto:dongsoo@gmail.com]
 Sent: Thursday, March 05, 2009 5:41 AM
 To: Sakari Ailus
 Cc: Hiremath, Vaibhav; linux-me...@vger.kernel.org; linux-
 o...@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen
 Tuukka Olli Artturi; Hiroshi DOYU
 Subject: Re: [RFC 0/9] OMAP3 ISP and camera drivers
 
 Hi Sakari,
 
 I'm also facing same issue with Hiremath.
 
 Here you are my kernel stack dump.
 
[Hiremath, Vaibhav] I was getting same kernel crash,  The reason is -

Since  isp_probe doesn't get called, leaving omap3isp = NULL. So isp_get will 
return -EBUSY from the very beginning of function.  And the function 
omap34xxcam_device_register which calls isp_get tries to access 
vdev-vfd-dev where it crashes. Which is completely wrong, since the vfd gets 
initialize later part of function


if (hwc.dev_type == OMAP34XXCAM_SLAVE_SENSOR) {
rval = isp_get();
if (rval  0) {
dev_err(vdev-vfd-dev, can't get ISP, sensor init
failed\n);
[Vaibhav] - Here it crashes.
 goto err;
 }
}

There are some instances where vdev-vfd is being accessed before initializing.

 Cheers,
 
 Nate
 
 [6.465606] [c019e194] (dev_driver_string+0x0/0x44) from
 [c01cc5e0] (omap34xxcam_device_register+0x110/0x2f8)
 [6.475952] [c01cc4d0] (omap34xxcam_device_register+0x0/0x2f8)
 from [c01b91a0] (__v4l2_int_device_try_attach_all+0xb0/0x108)
 [6.487609]  r7: r6:c03e4fcc r5:cfbbf834 r4:c03e4f94
 [6.493347] [c01b90f0]
 (__v4l2_int_device_try_attach_all+0x0/0x108) from [c01b9258]
 (v4l2_int_device_register+0x60/0x7c)
 [6.504638]  r7:c03e4eec r6:cf9e5020 r5:c03e4f94 r4:c03e03f8
 [6.510375] [c01b91f8] (v4l2_int_device_register+0x0/0x7c) from
 [c00182e4] (ce131f_probe+0x88/0xa8)
 [6.519836]  r5: r4:cf9e5000
 [6.523437] [c001825c] (ce131f_probe+0x0/0xa8) from
 [c01cefa4]
 (i2c_device_probe+0x78/0x90)
 [6.532226]  r5:cf9e5000 r4:c001825c
 [6.535827] [c01cef2c] (i2c_device_probe+0x0/0x90) from
 [c01a1634] (driver_probe_device+0xd4/0x180)
 [6.545318]  r7:c03e4eec r6:c03e4eec r5:cf9e50a8 r4:cf9e5020
 [6.551025] [c01a1560] (driver_probe_device+0x0/0x180) from
 [c01a1748] (__driver_attach+0x68/0x8c)
 [6.560394]  r7:c03e4eec r6:c03e4eec r5:cf9e50a8 r4:cf9e5020
 [6.566131] [c01a16e0] (__driver_attach+0x0/0x8c) from
 [c01a0a8c] (bus_for_each_dev+0x4c/0x84)
 [6.575164]  r7:c03e4eec r6:c01a16e0 r5:cf821cc8 r4:
 [6.580871] [c01a0a40] (bus_for_each_dev+0x0/0x84) from
 [c01a1478] (driver_attach+0x20/0x28)
 [6.589721]  r7:cfb121a0 r6:c0018224 r5:c03e4eec r4:
 [6.595458] [c01a1458] (driver_attach+0x0/0x28) from
 [c01a1054]
 (bus_add_driver+0xa8/0x214)
 [6.604217] [c01a0fac] (bus_add_driver+0x0/0x214) from
 [c01a196c] (driver_register+0x98/0x120)
 [6.613250]  r8: r7:c03ef760 r6:c0018224 r5:c03e4eec
 r4:c03e4ec0
 [6.620025] [c01a18d4] (driver_register+0x0/0x120) from
 [c01cfffc] (i2c_register_driver+0x98/0xfc)
 [6.629425] [c01cff64] (i2c_register_driver+0x0/0xfc) from
 [c001823c] (ce131f_isp_init+0x18/0x38)
 [6.638702]  r7:c03ef760 r6:c0018224 r5:c0022d78 r4:c0023128
 [6.644439] [c0018224] (ce131f_isp_init+0x0/0x38) from
 [c002a2d0] (do_one_initcall+0x78/0x1d8)
 [6.653472]  r5:c0022d78 r4:c0023128
 [6.657073] [c002a258] (do_one_initcall+0x0/0x1d8) from
 [c0008720] (kernel_init+0x74/0xe0)
 [6.665740]  r8: r7: r6: r5:c0022d78
 r4:c0023128
 [6.672515] [c00086ac] (kernel_init+0x0/0xe0) from [c005c234]
 (do_exit+0x0/0x684)
 [6.680419]  r5: r4:
 [6.684020] Code: c036e993 e1a0c00d e92dd800 e24cb004 (e5903098)
 [6.690246] ---[ end trace cc13b15a4191e849 ]---
 [6.694915] Kernel panic - not syncing: Attempted to kill init!
 
 On Thu, Mar 5, 2009 at 12:38 AM, Sakari Ailus
 sakari.ai...@maxwell.research.nokia.com wrote:
  Hiremath, Vaibhav wrote:
 
  [Hiremath, Vaibhav] Sakari, Let me ask you basic question, have
 you
  tested/verified these patch-sets?
 
  For the ISP and camera drivers, yes. That's actually the only
 thing that's
  contained in the patchset.
 
  The reason I am asking this question is, for me it was not
 working. I
  had to debug this and found that -
 
  - Changes missing in devices.c file, so isp_probe function will
 not
  be called at all, keeping omap3isp = NULL. You will end up into
  kernel crash in omap34xxcam_device_register.
 
  Anyway a crash shouldn't happen here. Could I see the kernel oops
 if there
  was such?
 
  - The patches from Hiroshi DOYU doesn't build as is, you need to
 add
  one include line #include linux/hardirq.h in iovmmu.c (I am
 using
  the patches submitted on 16th Jan 2009)
 
  Just pull the iommu branch, the Hiroshi's original patches are
 missing some
  hacks that you need to use them now. I'd expect Hiroshi to update
 the
  patchset when he comes back.
 
  I have attached git

RE: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver

2009-03-02 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of DongSoo(Nathaniel) Kim
 Sent: Tuesday, March 03, 2009 8:18 AM
 To: Tuukka.O Toivonen
 Cc: Aguirre Rodriguez, Sergio Alberto; linux-omap@vger.kernel.org;
 Ailus Sakari (Nokia-D/Helsinki); Nagalla, Hari
 Subject: Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver

 Hi Tuukka,

 I understand that it is a huge thing to support VIDIOC_S_INPUT.
 But without that, we don't have any proper V4L2 api to get
 information about how many devices are attached to camera interface,
 and names of input devices...and so on. Because VIDIOC_ENUMINPUT and
 VIDIOC_G_INPUT needs VIDIOC_S_INPUT for prior. Of course we can
 refer
 to sysfs, but using only single set of APIs like V4L2 looks more
 decent.

 What do you think about this?
 If you think that it is a big burden, can I make a patch for this?
 Cheers,

[Hiremath, Vaibhav] You may want to refer to the thread on this subject.

http://marc.info/?l=linux-omapm=122772175002777w=2
http://marc.info/?l=linux-omapm=122823846806440w=2

 Nate

 On Mon, Feb 23, 2009 at 5:50 PM, Tuukka.O Toivonen
 tuukka.o.toivo...@nokia.com wrote:
  On Monday 23 February 2009 10:08:54 ext DongSoo(Nathaniel) Kim
 wrote:
  So, logically it does not make sense with making device nodes of
 every
  single slave attached with OMAP3camera interface. Because they
 can't
  be opened at the same time,even if it is possible it should not
 work
  properly.

  So.. how about making only single device node like /dev/video0
 for
  OMAP3 camera interface and make it switchable through V4L2 API.
 Like
  VIDIOC_S_INPUT?

  You are right that if the OMAP3 has several camera sensors
 attached
  to its camera interface, generally just one can be used at once.

  However, from user's perspective those are still distinct
  cameras. Many v4l2 applications don't support VIDIOC_S_INPUT
  or at least it will be more difficult to use than just pointing
  an app to the correct video device. Logically they are two
  independent cameras, which can't be used simultaneously
  due to HW restrictions.

  - Tuukka

 --

 DongSoo(Nathaniel), Kim
 Engineer
 Mobile S/W Platform Lab. S/W centre
 Telecommunication RD Centre
 Samsung Electronics CO., LTD.
 e-mail : dongsoo@gmail.com
   dongsoo45@samsung.com

 --
 To unsubscribe from this list: send the line unsubscribe linux-
 omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/2] Pad configuration for OMAP3EVM Multi-Media Daughter Card Support



Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Hiremath, Vaibhav
 Sent: Friday, January 30, 2009 12:52 AM
 To: linux-omap@vger.kernel.org
 Cc: linux-me...@vger.kernel.org; Hiremath, Vaibhav; Jadav, Brijesh
 R; Shah, Hardik
 Subject: [PATCH 1/2] Pad configuration for OMAP3EVM Multi-Media
 Daughter Card Support
 
 From: Vaibhav Hiremath hvaib...@ti.com
 
 On OMAP3EVM Mass Market Daugher Card following GPIO pins are being
 used -
 
 GPIO134 -- Enable/Disable TVP5146 interface
 GPIO54 -- Enable/Disable Expansion Camera interface
 GPIO136 -- Enable/Disable Camera (Sensor) interface
 
 Added entry for the above GPIO's in mux.c and mux.h file
 
 Signed-off-by: Brijesh Jadav brijes...@ti.com
 Signed-off-by: Hardik Shah hardik.s...@ti.com
 Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
 ---
  arch/arm/mach-omap2/mux.c |6 ++
  arch/arm/plat-omap/include/mach/mux.h |5 -
  2 files changed, 10 insertions(+), 1 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
 index 1556688..d226d81 100644
 --- a/arch/arm/mach-omap2/mux.c
 +++ b/arch/arm/mach-omap2/mux.c
 @@ -471,6 +471,12 @@ MUX_CFG_34XX(AF5_34XX_GPIO142, 0x170,
   OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
  MUX_CFG_34XX(AE5_34XX_GPIO143, 0x172,
   OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
 +MUX_CFG_34XX(AG4_34XX_GPIO134, 0x160,
 + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
 +MUX_CFG_34XX(U8_34XX_GPIO54, 0x0b4,
 + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
 +MUX_CFG_34XX(AE4_34XX_GPIO136, 0x164,
 + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
 
  };
 
 diff --git a/arch/arm/plat-omap/include/mach/mux.h b/arch/arm/plat-
 omap/include/mach/mux.h
 index 67fddec..ace037f 100644
 --- a/arch/arm/plat-omap/include/mach/mux.h
 +++ b/arch/arm/plat-omap/include/mach/mux.h
 @@ -795,7 +795,10 @@ enum omap34xx_index {
   AF6_34XX_GPIO140_UP,
   AE6_34XX_GPIO141,
   AF5_34XX_GPIO142,
 - AE5_34XX_GPIO143
 + AE5_34XX_GPIO143,
 + AG4_34XX_GPIO134,
 + U8_34XX_GPIO54,
 + AE4_34XX_GPIO136,
  };
 
[Hiremath, Vaibhav] If there are no review comments on this then probably this 
patch should go through, since this is independent and being used with 
Multi-Media Daughter card support.

  struct omap_mux_cfg {
 --
 1.5.6

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [REVIEW PATCH 2/2] OMAP3EVM Multi-Media Daughter Card Support



Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Alexey Klimov [mailto:klimov.li...@gmail.com]
 Sent: Saturday, January 31, 2009 9:59 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org; linux-me...@vger.kernel.org; Jadav,
 Brijesh R; Shah, Hardik
 Subject: Re: [REVIEW PATCH 2/2] OMAP3EVM Multi-Media Daughter Card
 Support
 
 Hello, Vaibhav
 May i tell few suggestions ?
 
 On Fri, 2009-01-30 at 00:52 +0530, hvaib...@ti.com wrote:
  From: Vaibhav Hiremath hvaib...@ti.com
 
  This is second version of OMAP3EVM Mulit-Media/Mass Market
  Daughter Card support.
 
  Fixes:
  - Cleaned unused header files, struct formating, and unused
comments.
  - Pad/mux configuration handled in mux.ch
  - mux.ch related changes moved to seperate patch
  - Renamed file board-omap3evm-dc.c to board-omap3evm-dc-v4l.c
to make more explicit.
  - Added some more meaningful name for Kconfig option
 
  TODO:
  - Camera sensor support (for future development).
  - Driver header file inclusion (dependency on ISP-Camera
 patches)
I am working with Sergio to seperate/move header file to
 standard
location.
  - Still need to fix naming convention for DC
 
  Tested:
  - TVP5146 (BT656) decoder interface on top of
Sergio's ISP-Camera patches.
  - Loopback application, capturing image through TVP5146
and saving it to file per frame.
  - Basic functionality of HSUSB Transceiver USB-83320
 
  Signed-off-by: Brijesh Jadav brijes...@ti.com
  Signed-off-by: Hardik Shah hardik.s...@ti.com
  Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
  ---
   arch/arm/mach-omap2/Kconfig |8 +-
   arch/arm/mach-omap2/Makefile|1 +
   arch/arm/mach-omap2/board-omap3evm-dc-v4l.c |  348
 +++
   arch/arm/mach-omap2/board-omap3evm-dc.h |   42 
   4 files changed, 398 insertions(+), 1 deletions(-)
   create mode 100644 arch/arm/mach-omap2/board-omap3evm-dc-v4l.c
   create mode 100644 arch/arm/mach-omap2/board-omap3evm-dc.h
 
[Hiremath, Vaibhav] This patch is strongly dependent on ISP-Camera patches, and 
need rebase/refreshment/synchronization with latest code-base from Sergio and 
Sakari. I believe they are under process of fixing review comments.

Since there are only minor review comments received for MMDC patch, I will wait 
till the time Sergio posts the patches supporting ISP-Camera module. And then I 
will submit it to the community after refreshing on top of it (with review 
comment fix).
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] Backlight driver for omap3evm

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev
 Sent: Wednesday, January 07, 2009 8:52 PM
 To: Richard Purdie
 Cc: linux-omap@vger.kernel.org
 Subject: RE: [PATCH] Backlight driver for omap3evm

  -Original Message-
  From: Richard Purdie [mailto:rpur...@rpsys.net]
  Sent: Wednesday, January 07, 2009 8:37 PM
  To: Premi, Sanjeev
  Cc: linux-omap@vger.kernel.org
  Subject: Re: [PATCH] Backlight driver for omap3evm

  On Wed, 2009-01-07 at 20:25 +0530, Sanjeev Premi wrote:
  should be done in the platform code for the board, not in the
  general driver. If you do that, you should be able to reuse
  most of the generic-bl device code.

 I tried so, but wasn't able to get the Kconfig dependencies right to
 get 'generic-bl' into my build. Hence, removed the code that I
 believed to be generic (since yesterday's mail) and created the
 patch.

 Will give another try.

[Hiremath, Vaibhav] Now I will be following up for OMAP3EVM backlight driver 
patch initiated/posted by Sanjeev. I was just referring to the backlight drives 
currently available under Linux tree, and observed that almost all drivers have 
been implemented in different way. I could not able to get one driver to which 
I can refer to for adding support for OMAP3EVM backlight driver.

Can anybody tell me the expected way of implementation for backlight driver is?

I have some questions here,

- If I understand correctly (and as mentioned and pointed out by 
Richard in the mail-chain), platform_device should get added in platform file 
where it registers the pointer to the structure struct generic_bl_info. 
This I believe should be standard way everybody should follow, which is not the 
case.
Am I missing something here?

- The below question may sound foolish, but to is important for me to 
understand the framework.

If I have simple and straight control of backlight, do I really required to 
have separate backlight driver for my platform? Can I make use of generic-bl 
driver?
The only difference (atleast to my platform) would be the SYSFS entry, the 
entry will get created something like
/sys/class/backlight/generic-bl/

Is it required to make driver, Power aware and differentiate from generic 
driver?

Do we have any document on backlight driver framework?

  Regards,

  Richard

  --
 To unsubscribe from this list: send the line unsubscribe linux-
 omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: OMAP [TV] video

Thanks,
Vaibhav Hiremath
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Gary Thomas
 Sent: Tuesday, February 10, 2009 9:35 PM
 To: Linux OMAP
 Subject: OMAP [TV] video

 I'm trying to get TV [S-Video] working on my 3530 board.
 The settings in the current kernel don't seem to work very
 well on my TV (U.S. NTSC, standard).  Comparing the video
 encoder setup with the suggested values in the manual, I
 find many differences, mostly with respect to the framing
 (signal shaping).

 Questions:
 * Are the settings in the kernel tree known to work [as is]?
 * Why the divergence from the recommended values?

 Any ideas or helpful pointers would be graciously accepted

[Hiremath, Vaibhav] Can you provide some more details like,

Which kernel version are you using?
Are you using DSS2 for TV out?
Which board you are using, (must be EVM)?

 Thanks

 --

 Gary Thomas |  Consulting for the
 MLB Associates  |Embedded world

 --
 To unsubscribe from this list: send the line unsubscribe linux-
 omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [REVIEW PATCH 00/14] OMAP3 camera + ISP + MT9P012 sensor driver v2

2009-02-06 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: video4linux-list-boun...@redhat.com [mailto:video4linux-list-
 boun...@redhat.com] On Behalf Of Sakari Ailus
 Sent: Monday, January 19, 2009 3:50 PM
 To: Aguirre Rodriguez, Sergio Alberto
 Cc: Nagalla, Hari; video4linux-l...@redhat.com; linux-
 o...@vger.kernel.org; Tuukka.O Toivonen; linux-me...@vger.kernel.org
 Subject: Re: [REVIEW PATCH 00/14] OMAP3 camera + ISP + MT9P012
 sensor driver v2

 Aguirre Rodriguez, Sergio Alberto wrote:
  Hi,

  I'm sending the following patchset for review to the relevant
 lists (linux-omap, v4l, linux-media).

  Includes:
   - Omap3 camera core + ISP drivers.
   - MT9P012 sensor driver (adapted to 3430SDP)
   - DW9710 lens driver (adapted to work with MT9P012 for SDP)
   - Necessary v4l2-int-device changes to make above drivers work
   - Redefine OMAP3 ISP platform device.
   - Review comments fixed from: (Thanks a lot for their time and
 help)
 - Hans Verkuil
 - Tony Lindgreen
 - Felipe Balbi
 - Vaibhav Hiremath
 - David Brownell

 Hi Sergio,

 We should try to figure out how we could synchronise our version of
 the
 ISP and camera ASAP before making any more changes... I wouldn't
 want to
 start posting a competing version. ;-)

[Hiremath, Vaibhav] Sakari,
Can you share your version of code (either in form of patches or source) here 
onto the mailing list, so that everybody those who are interested will be aware 
of changes?

Atleast for me I would get prior view of changes which might affect BT656 
support (posted on top of Sergio's patch).

Again one more thing I would like to bring to your notice is about sub-device 
framework. Also we need to plan for the migration from V4L2-int to sub-device 
framework, which is of equal important. I feel the more time we spend in 
merging and aligning offline, more we are carrying risk.

According to me as I mentioned before, the plan should be to push ISP-Camera 
with V4L2-int interface as early as possible with whatever minimal 
sensor/decoder support we have today, which will make sure that our underneath 
ISP-library is in place. Once that is placed in, we can have additional patches 
on top of it to add more features. 

In this way, we can plan for migration to sub-device framework and also be 
easier and simpler. Even if any customers are interested, they can pick it up 
the ISP library and start development on top of it.

 --
 Sakari Ailus
 sakari.ai...@nokia.com

 --
 video4linux-list mailing list
 Unsubscribe mailto:video4linux-list-
 requ...@redhat.com?subject=unsubscribe
 https://www.redhat.com/mailman/listinfo/video4linux-list

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [REVIEW PATCH 00/14] OMAP3 camera + ISP + MT9P012 sensor driver v2

2009-02-06 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Sakari Ailus [mailto:sakari.ai...@maxwell.research.nokia.com]
 Sent: Friday, February 06, 2009 8:33 PM
 To: Hiremath, Vaibhav
 Cc: Ailus Sakari (Nokia-D/Helsinki); Aguirre Rodriguez, Sergio
 Alberto; Nagalla, Hari; video4linux-l...@redhat.com; linux-
 o...@vger.kernel.org; Toivonen Tuukka.O (Nokia-D/Oulu); linux-
 me...@vger.kernel.org
 Subject: Re: [REVIEW PATCH 00/14] OMAP3 camera + ISP + MT9P012
 sensor driver v2

 Hiremath, Vaibhav wrote:
  [Hiremath, Vaibhav] Sakari, Can you share your version of code
  (either in form of patches or source) here onto the mailing list,
 so
  that everybody those who are interested will be aware of changes?

 I will synchronise soon with Sergio (as he noted). After that we'll
 send
 a new patchset. I was thinking of separating the ISP and camera
 driver
 patches from other hardware dependent patches. The resulting
 patchset
 wouldn't be that huge anymore but on the other hand it wouldn't be
 very
 usable as such.

[Hiremath, Vaibhav] How much change can we expect as compared to the patches 
posted by Sergio on 14th Jan?

  Atleast for me I would get prior view of changes which might
 affect
  BT656 support (posted on top of Sergio's patch).

  Again one more thing I would like to bring to your notice is about
  sub-device framework. Also we need to plan for the migration from
  V4L2-int to sub-device framework, which is of equal important. I
 feel
  the more time we spend in merging and aligning offline, more we
 are
  carrying risk.

 I agree that we should be moving to v4l2 sub-device at some point,
 preferrably sooner than later, but I think the ISP driver should get
 a
 much much better interface than it currently has. So that should be
 part
 of the task.

  According to me as I mentioned before, the plan should be to push
  ISP-Camera with V4L2-int interface as early as possible with
 whatever
  minimal sensor/decoder support we have today, which will make sure
  that our underneath ISP-library is in place. Once that is placed
 in,
  we can have additional patches on top of it to add more features.

 I agree. But I'd say that fixing the bugs and cleaning up the code
 is as
 least as important than adding new features.

[Hiremath, Vaibhav] It would be really great if you could share your plan of 
action for ISP-Camera driver that would really help to plan our milestone 
accordingly.

  In this way, we can plan for migration to sub-device framework and
  also be easier and simpler. Even if any customers are interested,
  they can pick it up the ISP library and start development on top
 of
  it.

 There's still a long way to get there --- the ISP driver's current
 interface and internals don't mix well with either v4l2 sub-device
 or
 v4l2-int-if. For example, there's no ISP object, just function calls
 and
 then output frame size / frame interval enumeration doesn't work
 properly for YUV (maybe not even for RAW10). Enumerating frame size
 has
 side effects. The ISP driver doesn't have a standard interface, it's
 now
 specific to OMAP 3. And this is just an example...

 Regards,

 --
 Sakari Ailus
 sakari.ai...@maxwell.research.nokia.com

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Naming convention used in mux.c

Hi,

Can anybody tell me the meaning of naming convention used in mux.c file, e.g. - 

MUX_CFG_34XX(AH8_34XX_GPIO29, 0x5fa,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
MUX_CFG_34XX(J25_34XX_GPIO170, 0x1c6,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)

What the suffix AH8_ and J25_ means here? I looked into TRM and could not 
able to co-relate with any meaningful?

Thanks,
Vaibhav Hiremath
Platform Support Products
Texas Instruments Inc
Ph: +91-80-25099927

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Naming convention used in mux.c

Thanks Ashwin, I got it.

But I would recommend to have some kind of comment in mux.c which will mention 
this.

Thanks,
Vaibhav Hiremath
Platform Support Products
Texas Instruments Inc
Ph: +91-80-25099927

From: Ashwin Bihari [mailto:abih...@gmail.com] 
Sent: Thursday, January 29, 2009 9:16 PM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org
Subject: Re: Naming convention used in mux.c

Vaibhav,

I was also confused by that when I began playing with the OMAP and only found 
those references to make sense when I looked at the schematics of the board I'm 
working on. If you look at the Terminal Pin documents for your specific OMAP 
you will see the alphabet and numbers make sense. But you need to know which 
alphabet/number specifically is designated to a particular function and this is 
something the hardware engineer would do while connecting the OMAP to the rest 
of the peripherals on the board.

Regards

-- Ashwin

On Thu, Jan 29, 2009 at 10:34 AM, Hiremath, Vaibhav hvaib...@ti.com wrote:
Hi,

Can anybody tell me the meaning of naming convention used in mux.c file, e.g. -

MUX_CFG_34XX(AH8_34XX_GPIO29, 0x5fa,
               OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
MUX_CFG_34XX(J25_34XX_GPIO170, 0x1c6,
               OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)

What the suffix AH8_ and J25_ means here? I looked into TRM and could not 
able to co-relate with any meaningful?

Thanks,
Vaibhav Hiremath
Platform Support Products
Texas Instruments Inc
Ph: +91-80-25099927

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [REVIEW PATCH 2/2] OMAP3EVM Multi-Media Daughter Card Support

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Hans Verkuil [mailto:hverk...@xs4all.nl]
 Sent: Friday, January 30, 2009 1:03 AM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org; linux-me...@vger.kernel.org; Jadav,
 Brijesh R; Shah, Hardik
 Subject: Re: [REVIEW PATCH 2/2] OMAP3EVM Multi-Media Daughter Card
 Support

 On Thursday 29 January 2009 20:22:30 hvaib...@ti.com wrote:
  From: Vaibhav Hiremath hvaib...@ti.com

  This is second version of OMAP3EVM Mulit-Media/Mass Market
  Daughter Card support.

  Fixes:
  - Cleaned unused header files, struct formating, and unused
comments.
  - Pad/mux configuration handled in mux.ch
  - mux.ch related changes moved to seperate patch
  - Renamed file board-omap3evm-dc.c to board-omap3evm-dc-v4l.c
to make more explicit.
  - Added some more meaningful name for Kconfig option

  TODO:
  - Camera sensor support (for future development).
  - Driver header file inclusion (dependency on ISP-Camera
 patches)
I am working with Sergio to seperate/move header file to
 standard
location.
  - Still need to fix naming convention for DC

  Tested:
  - TVP5146 (BT656) decoder interface on top of
Sergio's ISP-Camera patches.
  - Loopback application, capturing image through TVP5146
and saving it to file per frame.

 What is the status of converting tvp5146 to v4l2_subdev? The longer
 it takes
 to convert it, the harder it will be now that you are starting to
 use this
 driver. v4l2_int_device should be phased out, preferably by 2.6.30.

 I'm more than happy to assist in this conversion, but please try to
 do this
 asap!

[Hiremath, Vaibhav] Hans, I understand your concerns here. The TVP driver has 
strong dependency on ISP-Camera driver (Master) and without which it really 
doesn't make sense atleast for me. So actually I was trying to finish the 
ISP-Camera with V4L2-int and then migrate everything to the sub-devices. I am 
working with Sergio to finish this as early as possible.
As far as sub-device framework is concerned, we have taken pro-active steps. If 
I understand correctly Davinci team here has already started migrating to the 
sub-device framework and the patches are under review internally. Soon you will 
see some patches on v4L mailing list for this.

 Thanks,

   Hans

 --
 Hans Verkuil - video4linux developer - sponsored by TANDBERG

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [OMAPZOOM][PATCH 2/6] Increase isp workaround buffer size for 8MP sensor.



Thanks,
Vaibhav Hiremath

 -Original Message-
 From: video4linux-list-boun...@redhat.com [mailto:video4linux-list-
 boun...@redhat.com] On Behalf Of Curran, Dominic
 Sent: Friday, January 30, 2009 6:24 AM
 To: linux-omap; video4linux-l...@redhat.com
 Cc: greg.ho...@hp.com
 Subject: [OMAPZOOM][PATCH 2/6] Increase isp workaround buffer size
 for 8MP sensor.
 
 From: Dominic Curran dcur...@ti.com
 Subject: [OMAPZOOM][PATCH 2/6] Increase isp workaround buffer size
 for 8MP
 sensor.
 
 A temporary buffer is created to hold the image while it is written
 by
 Previewer module and then read by Resizer module. This is called LSC
 Workaround. To take into account the Sony IMX046 8MP sensor that
 buffer
 needs to be increased in size.
 Changed the #defines to be upper case.
 Patch also fixes the initialization of a couple of CCDC values.
 
 Signed-off-by: Dominic Curran dcur...@ti.com
 ---
  drivers/media/video/isp/isp.c |   10 +-
  drivers/media/video/isp/isp.h |4 ++--
  drivers/media/video/isp/ispccdc.c |2 ++
  3 files changed, 9 insertions(+), 7 deletions(-)
 
 Index: omapzoom04/drivers/media/video/isp/isp.c
 ===
 --- omapzoom04.orig/drivers/media/video/isp/isp.c
 +++ omapzoom04/drivers/media/video/isp/isp.c
 @@ -1172,20 +1172,20 @@ void omapisp_unset_callback()
   **/
  u32 isp_buf_allocation(void)
  {
 - buff_addr = (void *) vmalloc(buffer_size);
 + buff_addr = (void *) vmalloc(ISP_BUFFER_MAX_SIZE);
 
   if (!buff_addr) {
   printk(KERN_ERR Cannot allocate memory );
   return -ENOMEM;
   }
 
 - sglist_alloc = videobuf_vmalloc_to_sg(buff_addr, no_of_pages);
 + sglist_alloc = videobuf_vmalloc_to_sg(buff_addr,
 ISP_BUFFER_MAX_PAGES);
   if (!sglist_alloc) {
   printk(KERN_ERR videobuf_vmalloc_to_sg error);
   return -ENOMEM;
   }
 - num_sc = dma_map_sg(NULL, sglist_alloc, no_of_pages, 1);
 - buff_addr_mapped = ispmmu_map_sg(sglist_alloc, no_of_pages);
 + num_sc = dma_map_sg(NULL, sglist_alloc, ISP_BUFFER_MAX_PAGES,
 1);
 + buff_addr_mapped = ispmmu_map_sg(sglist_alloc,
 ISP_BUFFER_MAX_PAGES);
   if (!buff_addr_mapped) {
   printk(KERN_ERR ispmmu_map_sg mapping failed );
   return -ENOMEM;
 @@ -1217,7 +1217,7 @@ void isp_buf_free(void)
  {
   if (alloc_done == 1) {
   ispmmu_unmap(buff_addr_mapped);
 - dma_unmap_sg(NULL, sglist_alloc, no_of_pages, 1);
 + dma_unmap_sg(NULL, sglist_alloc, ISP_BUFFER_MAX_PAGES,
 1);
   kfree(sglist_alloc);
   vfree(buff_addr);
   alloc_done = 0;
 Index: omapzoom04/drivers/media/video/isp/isp.h
 ===
 --- omapzoom04.orig/drivers/media/video/isp/isp.h
 +++ omapzoom04/drivers/media/video/isp/isp.h
 @@ -69,8 +69,8 @@
  #define NUM_ISP_CAPTURE_FORMATS  (sizeof(isp_formats) /\
   sizeof(isp_formats[0]))
  #define ISP_WORKAROUND 1
 -#define buffer_size (1024 * 1024 * 10)
 -#define no_of_pages (buffer_size / (4 * 1024))
 +#define ISP_BUFFER_MAX_SIZE (1024 * 1024 * 16)
 +#define ISP_BUFFER_MAX_PAGES (ISP_BUFFER_MAX_SIZE / (4 * 1024))
 
[Hiremath, Vaibhav] Is here (4 * 1024) indicates ISP-MMUSG page size 
configuration or normal kernel page size?

If it is kernel page size, then we can use PAGE_SIZE macro instead of hard 
coding.

  typedef int (*isp_vbq_callback_ptr) (struct videobuf_buffer *vb);
  typedef void (*isp_callback_t) (unsigned long status,
 Index: omapzoom04/drivers/media/video/isp/ispccdc.c
 ===
 --- omapzoom04.orig/drivers/media/video/isp/ispccdc.c
 +++ omapzoom04/drivers/media/video/isp/ispccdc.c
 @@ -1265,6 +1265,8 @@ int ispccdc_config_size(u32 input_w, u32
   }
 
   if (ispccdc_obj.ccdc_outfmt == CCDC_OTHERS_VP) {
 + ispccdc_obj.ccdcin_woffset = 0;
 + ispccdc_obj.ccdcin_hoffset = 0;
   omap_writel((ispccdc_obj.ccdcin_woffset 
   ISPCCDC_FMT_HORZ_FMTSPH_SHIFT) |
   (ispccdc_obj.ccdcin_w 
 
 --
 video4linux-list mailing list
 Unsubscribe mailto:video4linux-list-
 requ...@redhat.com?subject=unsubscribe
 https://www.redhat.com/mailman/listinfo/video4linux-list

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [OMAPZOOM][PATCH 4/6] Add support for Sony imx046 to OMAP3430 SDP board.



Thanks,
Vaibhav Hiremath

 -Original Message-
 From: video4linux-list-boun...@redhat.com [mailto:video4linux-list-
 boun...@redhat.com] On Behalf Of Curran, Dominic
 Sent: Friday, January 30, 2009 6:24 AM
 To: linux-omap; video4linux-l...@redhat.com
 Cc: greg.ho...@hp.com
 Subject: [OMAPZOOM][PATCH 4/6] Add support for Sony imx046 to
 OMAP3430 SDP board.
 
 From: Dominic Curran dcur...@ti.com
 Subject: [OMAPZOOM][PATCH 4/6] Add support for Sony imx046 to
 OMAP3430 SDP board.
 
 Support for the Sony IMX046 sensor on the OMAP3430 SDP board.
 
 Signed-off-by: Greg Hofer greg.ho...@hp.com
 Signed-off-by: Dominic Curran dcur...@ti.com
 ---
  arch/arm/mach-omap2/board-3430sdp.c |  197
 
  1 file changed, 197 insertions(+)
 
 Index: omapzoom04/arch/arm/mach-omap2/board-3430sdp.c
 ===
 --- omapzoom04.orig/arch/arm/mach-omap2/board-3430sdp.c
 +++ omapzoom04/arch/arm/mach-omap2/board-3430sdp.c
 @@ -45,6 +45,9 @@
  #include ti-compat.h
 
  #ifdef CONFIG_VIDEO_OMAP3
 +#ifndef CONFIG_TWL4030_CORE
 +#error no power companion board defined!
 +#endif
[Hiremath, Vaibhav] Do we really required to do this?

  #include media/v4l2-int-device.h
  #include ../drivers/media/video/omap34xxcam.h
  #include ../drivers/media/video/isp/ispreg.h
 @@ -52,9 +55,11 @@
  #define FPGA_SPR_GPIO1_3v3   (0x1  14)
  #define FPGA_GPIO6_DIR_CTRL  (0x1  6)
  static void __iomem *fpga_map_addr;
 +
  #if defined(CONFIG_VIDEO_MT9P012) ||
 defined(CONFIG_VIDEO_MT9P012_MODULE)
  #include ../drivers/media/video/mt9p012.h
  #endif
 +
  #if defined(CONFIG_VIDEO_OV3640) ||
 defined(CONFIG_VIDEO_OV3640_MODULE)
  #include ../drivers/media/video/ov3640.h
  #include ../drivers/media/video/isp/ispcsi2.h
 @@ -71,6 +76,22 @@ static struct omap34xxcam_hw_config *hwc
  #define OV3640_CSI2_PHY_TCLK_MISS1
  #define OV3640_CSI2_PHY_TCLK_SETTLE  14
  #endif
 +
 +#if defined(CONFIG_VIDEO_IMX046) ||
 defined(CONFIG_VIDEO_IMX046_MODULE)
 +#include ../drivers/media/video/imx046.h
 +#include ../drivers/media/video/isp/ispcsi2.h
 +#define IMX046_CSI2_CLOCK_POLARITY   0   /* +/- pin order */
 +#define IMX046_CSI2_DATA0_POLARITY   0   /* +/- pin order */
 +#define IMX046_CSI2_DATA1_POLARITY   0   /* +/- pin order */
 +#define IMX046_CSI2_CLOCK_LANE   1/* Clock lane
 position: 1 */
 +#define IMX046_CSI2_DATA0_LANE   2/* Data0 lane
 position: 2 */
 +#define IMX046_CSI2_DATA1_LANE   3/* Data1 lane
 position: 3 */
 +#define IMX046_CSI2_PHY_THS_TERM 2
 +#define IMX046_CSI2_PHY_THS_SETTLE   23
 +#define IMX046_CSI2_PHY_TCLK_TERM0
 +#define IMX046_CSI2_PHY_TCLK_MISS1
 +#define IMX046_CSI2_PHY_TCLK_SETTLE  14
 +#endif
  #endif
 
  #ifdef CONFIG_VIDEO_DW9710
 @@ -926,6 +947,176 @@ static struct ov3640_platform_data sdp34
 
  #endif
 
 +
 +#if defined(CONFIG_VIDEO_IMX046) ||
 defined(CONFIG_VIDEO_IMX046_MODULE)
 +
 +static struct omap34xxcam_sensor_config imx046_hwc = {
 + .sensor_isp = 0,
 + .xclk = OMAP34XXCAM_XCLK_B,
 + .capture_mem = PAGE_ALIGN(3280 * 2464 * 2) * 2,
 +};
 +
[Hiremath, Vaibhav] You may want to align the structure, same comment I had 
also received from Tony on MMDC support patch.

 +static int imx046_sensor_set_prv_data(void *priv)
 +{
 + struct omap34xxcam_hw_config *hwc = priv;
 +
 + hwc-u.sensor.xclk = imx046_hwc.xclk;
 + hwc-u.sensor.sensor_isp = imx046_hwc.sensor_isp;
 + hwc-dev_index = 2;
 + hwc-dev_minor = 5;
 + hwc-dev_type = OMAP34XXCAM_SLAVE_SENSOR;
 + hwc-interface_type = ISP_CSIA;
 +
 + hwc-csi2.hw_csi2.lanes.clock.polarity =
 IMX046_CSI2_CLOCK_POLARITY;
 + hwc-csi2.hw_csi2.lanes.clock.position =
 IMX046_CSI2_CLOCK_LANE;
 + hwc-csi2.hw_csi2.lanes.data[0].polarity =
 IMX046_CSI2_DATA0_POLARITY;
 + hwc-csi2.hw_csi2.lanes.data[0].position =
 IMX046_CSI2_DATA0_LANE;
 + hwc-csi2.hw_csi2.lanes.data[1].polarity =
 IMX046_CSI2_DATA1_POLARITY;
 + hwc-csi2.hw_csi2.lanes.data[1].position =
 IMX046_CSI2_DATA1_LANE;
 + hwc-csi2.hw_csi2.phy.ths_term = IMX046_CSI2_PHY_THS_TERM;
 + hwc-csi2.hw_csi2.phy.ths_settle = IMX046_CSI2_PHY_THS_SETTLE;
 + hwc-csi2.hw_csi2.phy.tclk_term = IMX046_CSI2_PHY_TCLK_TERM;
 + hwc-csi2.hw_csi2.phy.tclk_miss = IMX046_CSI2_PHY_TCLK_MISS;
 + hwc-csi2.hw_csi2.phy.tclk_settle =
 IMX046_CSI2_PHY_TCLK_SETTLE;
 + return 0;
 +}
 +
 +static struct isp_interface_config imx046_if_config = {
 + .ccdc_par_ser = ISP_CSIA,
 + .dataline_shift = 0x0,
 + .hsvs_syncdetect = ISPCTRL_SYNC_DETECT_VSRISE,
 + .vdint0_timing = 0x0,
 + .vdint1_timing = 0x0,
 + .strobe = 0x0,
 + .prestrobe = 0x0,
 + .shutter = 0x0,
 + .prev_sph = 2,
 + .prev_slv = 0,
 + .wenlog = ISPCCDC_CFG_WENLOG_OR,
 + .dcsub = IMX046_BLACK_LEVEL_AVG,
 + .u.csi.crc = 0x0,
 + .u.csi.mode = 0x0,
 + .u.csi.edge = 0x0,
 + .u.csi.signalling = 0x0

RE: [OMAPZOOM][PATCH 5/6] ZOOM2: Rename the zoom2 i2c struct.



Thanks,
Vaibhav Hiremath

 -Original Message-
 From: video4linux-list-boun...@redhat.com [mailto:video4linux-list-
 boun...@redhat.com] On Behalf Of Curran, Dominic
 Sent: Friday, January 30, 2009 6:24 AM
 To: linux-omap; video4linux-l...@redhat.com
 Cc: greg.ho...@hp.com
 Subject: [OMAPZOOM][PATCH 5/6] ZOOM2: Rename the zoom2 i2c struct.
 
 From: Dominic Curran dcur...@ti.com
 Subject: [OMAPZOOM][PATCH 5/6] ZOOM2: Rename the zoom2 i2c struct.
 
 Rename i2c structures to something sensible.
 This patch is not specific for imx046 sensor.
 Do this in preparation for i2c changes for imx046 sensor.
 
 Signed-off-by: Greg Hofer greg.ho...@hp.com
 Signed-off-by: Dominic Curran dcur...@ti.com
 ---
  arch/arm/mach-omap2/board-zoom2.c |   14 +++---
  1 file changed, 7 insertions(+), 7 deletions(-)
 
 Index: omapzoom04/arch/arm/mach-omap2/board-zoom2.c
 ===
 --- omapzoom04.orig/arch/arm/mach-omap2/board-zoom2.c
 +++ omapzoom04/arch/arm/mach-omap2/board-zoom2.c
 @@ -472,7 +472,7 @@ static struct twl4030_platform_data ldp_
   .keypad = ldp_kp_twl4030_data,
  };
 
 -static struct i2c_board_info __initdata ldp_i2c_boardinfo[] = {
 +static struct i2c_board_info __initdata zoom2_i2c_bus1_info[] = {
[Hiremath, Vaibhav] I think zoom2_i2c1_info should be sufficient, since 
i2c1,2,3 itself indicates bus.

   {
   I2C_BOARD_INFO(twl4030, 0x48),
   .flags = I2C_CLIENT_WAKE,
 @@ -507,7 +507,7 @@ static struct synaptics_i2c_rmi_platform
   .power  = synaptics_power,
  };
 
 -static struct i2c_board_info __initdata ldp3430_i2c_board_info[] =
 {
 +static struct i2c_board_info __initdata zoom2_i2c_bus2_info[] = {
   {
   I2C_BOARD_INFO(SYNAPTICS_I2C_RMI_NAME,
 SYNAPTICS_I2C_ADDR),
   .platform_data = ldp3430_synaptics_platform_data,
 @@ -518,12 +518,12 @@ static struct i2c_board_info __initdata
 
  static int __init omap_i2c_init(void)
  {
 - omap_register_i2c_bus(1, 2600, ldp_i2c_boardinfo,
 - ARRAY_SIZE(ldp_i2c_boardinfo));
 + omap_register_i2c_bus(1, 2600, zoom2_i2c_bus1_info,
 + ARRAY_SIZE(zoom2_i2c_bus1_info));
  #ifdef CONFIG_TOUCHSCREEN_SYNAPTICS
 - ldp3430_i2c_board_info[0].irq =
 OMAP_GPIO_IRQ(OMAP_SYNAPTICS_GPIO);
 - omap_register_i2c_bus(2, 100, ldp3430_i2c_board_info,
 - ARRAY_SIZE(ldp3430_i2c_board_info));
 + zoom2_i2c_bus2_info[0].irq =
 OMAP_GPIO_IRQ(OMAP_SYNAPTICS_GPIO);
 + omap_register_i2c_bus(2, 100, zoom2_i2c_bus2_info,
 + ARRAY_SIZE(zoom2_i2c_bus2_info));
  #endif
   omap_register_i2c_bus(3, 400, NULL, 0);
   return 0;
 
 --
 video4linux-list mailing list
 Unsubscribe mailto:video4linux-list-
 requ...@redhat.com?subject=unsubscribe
 https://www.redhat.com/mailman/listinfo/video4linux-list

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [REVIEW PATCH 2/2] Added OMAP3EVM Multi-Media Daughter Card Support

2009-01-28 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Mauro Carvalho Chehab [mailto:mche...@infradead.org]
 Sent: Wednesday, January 07, 2009 4:10 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org; video4linux-l...@redhat.com; linux-
 me...@vger.kernel.org
 Subject: Re: [REVIEW PATCH 2/2] Added OMAP3EVM Multi-Media Daughter
 Card Support

 On Wed, 7 Jan 2009 15:51:53 +0530
 Hiremath, Vaibhav hvaib...@ti.com wrote:

  [Hiremath, Vaibhav] Mauro, the Daughter card not only supports
 TVP1546/sensor but also supports USB EHCI. So this driver may not be
 fit into V4L driver. Daughter card driver (board-omap3evm-dc.c) only
 does basic initialization which happens during arch_init. The
 underneath V4L drivers are omap34xxcam.c (drivers/media/video) and
 TVP514x.c (drivers/media/video).

 Understood. This makes things a little more complicated. I suggest
 then to
 split the V4L specific part into a separate file, in order to allow
 a better
 maintenance (something like board-omap3evm-dc-v4l.c), since I'd like
 to review
 the changes there.

[Hiremath, Vaibhav] Mauro sorry for delayed response, again as I mentioned I 
was busy with our internal commitments. 

I do agree with your point and will change accordingly. Now the config option 
will look like something - 

Arch/arm/mach-omap2/Kconfig - 

config MACH_OMAP3EVM_MMDC
bool OMAP 3530 EVM Mass Market daughter card board
depends on ARCH_OMAP3  ARCH_OMAP34XX  MACH_OMAP3EVM

arch/arm/mach-omap2/Makefile - 

obj-$(CONFIG_MACH_OMAP3EVM_MMDC)+= board-omap3evm-dc-v4l.o

In the future we may want to add board-omap3evm-dc-usb.c under the same option.

+/* include V4L2 camera driver related header file */
+#if defined(CONFIG_VIDEO_OMAP3) ||
   defined(CONFIG_VIDEO_OMAP3_MODULE)
+#include ../drivers/media/video/omap34xxcam.h
+#include ../drivers/media/video/isp/ispreg.h
+#endif /* #ifdef CONFIG_VIDEO_OMAP3 */
+#endif /* #ifdef CONFIG_VIDEO_TVP514X*/

   Please, don't use ../* at your includes. IMO, the better is to
   create a
   drivers/media/video/omap dir, and put omap2/omap3 files there,
   including board-omap3evm-dc.c.
   This will avoid those ugly includes.

  [Hiremath, Vaibhav] I do agree with this. I have mentioned this in
 my TODO list.

 A cleaner solution is to add something like this at the Makefile:

 EXTRA_CFLAGS += -Idrivers/media/video
 EXTRA_CFLAGS += -Idrivers/media/video/isp

 Then, all you need to do is to use:

 #include omap34xxcam.h
 #include ispreg.h

   Btw, drivers/media/video/isp/ currently doesn't exist. Please
 submit
   the patch for it first.

[Hiremath, Vaibhav] I do agree with this, but I have seen there are some other 
board specific files including the header files in this way, 
arch/arm/mach-omap2/board-n800-camera.c
arch/arm/mach-omap2/board-n800.c

  [Hiremath, Vaibhav] Following up with Sergio on this, and soon
 will be available.

 Ok, thanks.

 Cheers,
 Mauro

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [REVIEW PATCH 2/2] Added OMAP3EVM Multi-Media Daughter Card Support

2009-01-28 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: David Brownell [mailto:davi...@pacbell.net]
 Sent: Monday, January 12, 2009 5:24 AM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org; linux-me...@vger.kernel.org;
 video4linux-l...@redhat.com; Jadav, Brijesh R; Shah, Hardik; Hadli,
 Manjunath; R, Sivaraj
 Subject: Re: [REVIEW PATCH 2/2] Added OMAP3EVM Multi-Media Daughter
 Card Support

 On Tuesday 06 January 2009, hvaib...@ti.com wrote:
  +config MACH_OMAP3EVM_DC
  +   bool OMAP 3530 EVM daughter card board
  +   depends on ARCH_OMAP3  ARCH_OMAP34XX  MACH_OMAP3EVM

 There can be other daughtercards, so the Kconfig text should
 say which specific card is being configured.  And it should
 probably use the zero or one of these choices syntax, so
 it's easier to include other options..

[Hiremath, Vaibhav] I do agree with this point, but as of now I believe there 
is only one Daughter card which is available with us. And I would prefer to 
have menu option for the future when any new daughter card available and gets 
added to tree.

Any other opinions would be helpful?

 - Dave

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 00/12] DSS: Series description

2009-01-12 Thread Hiremath, Vaibhav



Thanks,
Vaibhav Hiremath

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Koen Kooi
 Sent: Monday, January 12, 2009 7:14 PM
 To: Tomi Valkeinen
 Cc: linux-fbdev-de...@lists.sourceforge.net; linux-
 o...@vger.kernel.org
 Subject: Re: [PATCH 00/12] DSS: Series description
 
 
 Op 12 jan 2009, om 12:47 heeft Tomi Valkeinen het volgende
 geschreven:
 
  New Display Subsystem for OMAP2/3
  -
 
  This patch set implements new Display Subsystem (DSS) for OMAP2/3
  processors.
  The DSS is still under work and these patches are for review.
 
 I've tested these patches on beagleboard and omap35x EVM. The
 beagleboard is fully functional with it, the EVM has some glitches
 with DVI, but that might be due to differences between revisions of
 the EVM board (or rather the PMIC + SoC daugtherboards). 

[Hiremath, Vaibhav] Koen, I have also tested DVI output on EVM and facing same 
issues but I believe they are not because of board revisions. I have validated 
the DVI output with our previous (TI version of DSS library) on the same board 
and it comes absolutely fine. I need to dig bit more to find where exactly the 
issue is.

 The
 internal
 LCD works great on the EVM, the 3 dots in the corner problem that
 DSS1 had is gone.
 
 Summary: please merge this, for beagleboard and omap3evm there are
 no
 regressions, only feature additions (s-video, better pixclock, etc)
 over the current code.
 
 regards,
 
 Koen
 
 
 
  This is an updated version of the patch set I sent back in
 november:
  http://marc.info/?l=linux-fbdev-develm=122581504222406w=2
 
  The first patch is a doc file that tries to explain a bit how the
  drivers work.
 
  The patch set is based on the current linux-omap tree.
 
  You can find the patches also from a git tree at
  http://www.bat.org/~tomba/git/linux-omap-dss.git/
 
  ---
 
  Tomi Valkeinen (12):
  DSS: Hacked N810 support
  DSS: Support for OMAP3 EVM board
  DSS: Support for OMAP3 SDP board
  DSS: Sharp LS037V7DW01 LCD Panel driver
  DSS: support for Beagle Board
  DSS: Add generic DVI panel
  DSS: OMAPFB: fb driver for new display subsystem
  DSS: DSI support
  DSS: VENC support
  DSS: RFBI support
  DSS: Display subsystem for OMAP2/3
  DSS: Documentation for DSS2
 
 
  Documentation/arm/OMAP/DSS|  270 ++
  arch/arm/configs/dss_omap3_beagle_defconfig   | 1437 +++
  arch/arm/configs/dss_omap_3430sdp_defconfig   | 1603 +
  arch/arm/mach-omap2/board-3430sdp.c   |  215 ++
  arch/arm/mach-omap2/board-n800.c  |  214 +-
  arch/arm/mach-omap2/board-omap3beagle.c   |  101 +
  arch/arm/mach-omap2/board-omap3evm.c  |  203 ++
  arch/arm/plat-omap/Kconfig|2
  arch/arm/plat-omap/Makefile   |4
  arch/arm/plat-omap/dss/Kconfig|   71 +
  arch/arm/plat-omap/dss/Makefile   |6
  arch/arm/plat-omap/dss/dispc.c| 2113
 +
  arch/arm/plat-omap/dss/display.c  |  787 ++
  arch/arm/plat-omap/dss/dpi.c  |  344 +++
  arch/arm/plat-omap/dss/dsi.c  | 3187
 
  +
  arch/arm/plat-omap/dss/dss.c  |  774 ++
  arch/arm/plat-omap/dss/dss.h  |  274 ++
  arch/arm/plat-omap/dss/rfbi.c | 1262 ++
  arch/arm/plat-omap/dss/sdi.c  |  174 +
  arch/arm/plat-omap/dss/venc.c |  506 
  arch/arm/plat-omap/fb-vram.c  |  646 +
  arch/arm/plat-omap/fb.c   |   22
  arch/arm/plat-omap/include/mach/display.h |  462 
  arch/arm/plat-omap/include/mach/omapfb.h  |   14
  drivers/video/Kconfig |1
  drivers/video/Makefile|1
  drivers/video/omap/Kconfig|5
  drivers/video/omap2/Kconfig   |   62
  drivers/video/omap2/Makefile  |8
  drivers/video/omap2/ctrl-blizzard.c   |  279 ++
  drivers/video/omap2/omapfb-ioctl.c|  460 
  drivers/video/omap2/omapfb-main.c | 1442 +++
  drivers/video/omap2/omapfb-sysfs.c|  901 +++
  drivers/video/omap2/omapfb.h  |  115 +
  drivers/video/omap2/panel-generic.c   |   97 +
  drivers/video/omap2/panel-n800.c  |  437 +++
  drivers/video/omap2/panel-sharp-ls037v7dw01.c |  109 +
  37 files changed, 18537 insertions(+), 71 deletions(-)
  create mode 100644 Documentation/arm/OMAP/DSS
  create mode 100644 arch/arm/configs/dss_omap3_beagle_defconfig
  create mode 100644 arch/arm/configs/dss_omap_3430sdp_defconfig
  create mode 100644 arch/arm/plat-omap/dss/Kconfig
  create mode 100644 arch/arm/plat-omap/dss/Makefile
  create mode 100644 arch/arm/plat-omap/dss/dispc.c
  create

RE: [REVIEW PATCH 2/2] Added OMAP3EVM Multi-Media Daughter Card Support

2009-01-08 Thread Hiremath, Vaibhav



Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Tony Lindgren [mailto:t...@atomide.com]
 Sent: Wednesday, January 07, 2009 6:06 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org; linux-me...@vger.kernel.org;
 video4linux-l...@redhat.com; Jadav, Brijesh R; Shah, Hardik; Hadli,
 Manjunath; R, Sivaraj
 Subject: Re: [REVIEW PATCH 2/2] Added OMAP3EVM Multi-Media Daughter
 Card Support

 Hi,

 Few comments below.

 * hvaib...@ti.com hvaib...@ti.com [090107 08:09]:
  From: Vaibhav Hiremath hvaib...@ti.com
 
  This is first version of OMAP3EVM Mulit-Media Daughter
  Card support.
 
  Tested:
  - TVP5146 (BT656) decoder interface on top of
Sergio's ISP-Camera patches.
  - Loopback application, capturing image through TVP5146
and displaying it onto the TV/LCD on top of Hardik's
V4L2 driver.
  - Basic functionality of HSUSB Transceiver USB-83320
  -
 
  TODO:
  - Camera sensor support
  - Driver header file inclusion (dependency on ISP-Camera
 patches)
  - Some more clean-up may required.
 
  Signed-off-by: Brijesh Jadav brijes...@ti.com
  Signed-off-by: Hardik Shah hardik.s...@ti.com
  Signed-off-by: Manjunath Hadli m...@ti.com
  Signed-off-by: R Sivaraj siva...@ti.com
  Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
  ---
   arch/arm/mach-omap2/Kconfig |4 +
   arch/arm/mach-omap2/Makefile|1 +
   arch/arm/mach-omap2/board-omap3evm-dc.c |  417
 +++
   arch/arm/mach-omap2/board-omap3evm-dc.h |   43 
   arch/arm/mach-omap2/mux.c   |7 +
   arch/arm/plat-omap/include/mach/mux.h   |4 +
   6 files changed, 476 insertions(+), 0 deletions(-)
   mode change 100644 = 100755 arch/arm/mach-omap2/Kconfig
   mode change 100644 = 100755 arch/arm/mach-omap2/Makefile
   create mode 100755 arch/arm/mach-omap2/board-omap3evm-dc.c
   create mode 100755 arch/arm/mach-omap2/board-omap3evm-dc.h
   mode change 100644 = 100755 arch/arm/mach-omap2/mux.c
   mode change 100644 = 100755 arch/arm/plat-
 omap/include/mach/mux.h

 Hmm, why do you have these files with x bit set?

[Hiremath, Vaibhav] overlooked, will take care in next version.

  diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-
 omap2/Kconfig
  old mode 100644
  new mode 100755
  index ca24a7a..094c97f
  --- a/arch/arm/mach-omap2/Kconfig
  +++ b/arch/arm/mach-omap2/Kconfig
  @@ -121,6 +121,10 @@ config MACH_OMAP3EVM
  bool OMAP 3530 EVM board
  depends on ARCH_OMAP3  ARCH_OMAP34XX
 
  +config MACH_OMAP3EVM_DC
  +   bool OMAP 3530 EVM daughter card board
  +   depends on ARCH_OMAP3  ARCH_OMAP34XX  MACH_OMAP3EVM
  +
   config MACH_OMAP3_BEAGLE
  bool OMAP3 BEAGLE board
  depends on ARCH_OMAP3  ARCH_OMAP34XX
  diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-
 omap2/Makefile
  old mode 100644
  new mode 100755
  index 3897347..16fa35a
  --- a/arch/arm/mach-omap2/Makefile
  +++ b/arch/arm/mach-omap2/Makefile
  @@ -60,6 +60,7 @@ obj-$(CONFIG_MACH_OMAP3EVM)   += board-
 omap3evm.o \
 usb-musb.o usb-ehci.o \
 board-omap3evm-flash.o \
 twl4030-generic-scripts.o
  +obj-$(CONFIG_MACH_OMAP3EVM_DC) += board-omap3evm-dc.o
   obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
 usb-musb.o usb-ehci.o \
 mmc-twl4030.o \
  diff --git a/arch/arm/mach-omap2/board-omap3evm-dc.c
 b/arch/arm/mach-omap2/board-omap3evm-dc.c
  new file mode 100755
  index 000..233c219
  --- /dev/null
  +++ b/arch/arm/mach-omap2/board-omap3evm-dc.c
  @@ -0,0 +1,417 @@
  +/*
  + * arch/arm/mach-omap2/board-omap3evm-dc.c
  + *
  + * Driver for OMAP3 EVM Daughter Card
  + *
  + * Copyright (C) 2008 Texas Instruments Inc
  + * Author: Vaibhav Hiremath hvaib...@ti.com
  + *
  + * Contributors:
  + * Anuj Aggarwal anuj.aggar...@ti.com
  + * Sivaraj R siva...@ti.com
  + *
  + * This package 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.
  + *
  + * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
  + *
  + */
  +
  +#include linux/module.h
  +#include linux/kernel_stat.h
  +#include linux/init.h
  +#include linux/i2c.h
  +#include linux/delay.h
  +#include linux/spinlock.h
  +#include linux/clk.h
  +#include linux/device.h
  +#include linux/io.h
  +#include

RE: [REVIEW PATCH 1/2] OMAP3 ISP-Camera: Added BT656 support

2009-01-07 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Mauro Carvalho Chehab [mailto:mche...@infradead.org]
 Sent: Wednesday, January 07, 2009 3:10 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org; video4linux-l...@redhat.com; linux-
 me...@vger.kernel.org
 Subject: Re: [REVIEW PATCH 1/2] OMAP3 ISP-Camera: Added BT656
 support

 On Wed,  7 Jan 2009 11:37:20 +0530
 hvaib...@ti.com wrote:

  From: Vaibhav Hiremath hvaib...@ti.com

  Support for BT656 through TVP5146 decoder, works on top of
  ISP-Camera patches posted by Sergio on 12th Dec 2008.

  The TVP514x driver patch has been accepted under V4L, will
  be part of O-L in the next merge window. As of now you can
  access the patches from -

 http://markmail.org/search/?q=TVP514x#query:TVP514x%20from%3A%22Hire
 math%2C%20Vaibhav%22%20extension%3Apatch+page:1+mid:b5pcj3sriwknm2cv
 +state:results

  ToDO List:
  - Add support for scaling and cropping

  Signed-off-by: Brijesh Jadav brijes...@ti.com
  Signed-off-by: Hardik Shah hardik.s...@ti.com
  Signed-off-by: Manjunath Hadli m...@ti.com
  Signed-off-by: R Sivaraj siva...@ti.com
  Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
  ---
   drivers/media/video/isp/isp.c |  118 ---
   drivers/media/video/isp/isp.h |7 +-
   drivers/media/video/isp/ispccdc.c |  146 +++-
 ---
   drivers/media/video/isp/ispccdc.h |9 ++
   drivers/media/video/omap34xxcam.c |  197
 +
   drivers/media/video/omap34xxcam.h |5 +
   6 files changed, 428 insertions(+), 54 deletions(-)
   mode change 100644 = 100755 drivers/media/video/isp/isp.c
   mode change 100644 = 100755 drivers/media/video/omap34xxcam.c

 Your patch looks OK, but it touched
 drivers/media/video/omap34xxcam.c, that
 doesn't exist yet on my tree, so I can't apply it.

 Could you please submit first the opam34 patch on linux-
 me...@vger.kernel.org,
 in order to allow patchwork.kernel.org to track it also, and allow
 me to merge
 the files?

[Hiremath, Vaibhav] Thanks Mauro for quick review. As I mentioned in the 
description this patch is build on top of ISP-Camera patches posted by Sergio 
on 12th Dec 2008. I am following up with Sergio on the same and will post the 
patches soon with review comment fixes.

 Cheers,
 Mauro

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Spurious interrupt warning

2009-01-06 Thread Hiremath, Vaibhav

For capture driver I am also getting similar messages

4Spurious irq 95: 0xffdf, please flush posted write for irq 24
Spurious irq 95: 0xffdf, please flush posted write for irq 24
4Spurious irq 95: 0xffdf, please flush posted write for irq 24
Spurious irq 95: 0xffdf, please flush posted write for irq 24


Thanks,
Vaibhav Hiremath

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Tony Lindgren
 Sent: Tuesday, January 06, 2009 4:39 PM
 To: Shah, Hardik
 Cc: linux-omap@vger.kernel.org
 Subject: Re: Spurious interrupt warning
 
 Hi,
 
 * Shah, Hardik hardik.s...@ti.com [090106 11:54]:
  I have ported the V4L2 driver on top of Tomi's DSS library.  DSS
 library has requested irq number 25.  It is never freeing it.  But
 whenever I get interrupt from the DSS I get this warning
 intermittently.
 
  4Spurious irq 95: 0xffdf, please flush posted write for irq
 25
  Spurious irq 95: 0xffdf, please flush posted write for irq 25
  4Spurious irq 95: 0xffdf, please flush posted write for irq
 25
  Spurious irq 95: 0xffdf, please flush posted write for irq 25
  4Spurious irq 95: 0xffdf, please flush posted write for irq
 25
  Spurious irq 95: 0xffdf, please flush posted write for irq 25
  4Spurious irq 95: 0xffdf, please flush posted write for irq
 25
  Spurious irq 95: 0xffdf, please flush posted write for irq 25
  4Spurious irq 95: 0xffdf, please flush posted write for irq
 25
  Spurious irq 95: 0xffdf, please flush posted write for irq 25
  4Spurious irq 95: 0xffdf, please flush posted write for irq
 25
  Spurious irq 95: 0xffdf, please flush posted write for irq 25
  4Spurious irq 95: 0xffdf, please flush posted write for irq
 25
  Spurious irq 95: 0xffdf, please flush posted write for irq 25
  4Spurious irq 95: 0xffdf, please flush posted write for irq
 25
  Spurious irq 95: 0xffdf, please flush posted write for irq 25
  4Spurious irq 95: 0xffdf, please flush posted write for irq
 25
  Spurious irq 95: 0xffdf, please flush posted write for irq 25
  4Spurious irq 95: 0xffdf, please flush posted write for irq
 25
  Spurious irq 95: 0xffdf, please flush posted write for irq 25
  4Spurious irq 95: 0xffdf, please flush posted write for irq
 25
  Spurious irq 95: 0xffdf, please flush posted write for irq 25
  4Spurious irq 95: 0xffdf, please flush posted write for irq
 25
  Spurious irq 95: 0xffdf, please flush posted write for irq 25
  4Spurious irq 95: 0xffdf, please flush posted write for irq
 25
  Spurious irq 95: 0xffdf, please flush posted write for irq 25
  4Spurious irq 95: 0xffdf, please flush posted write for irq
 25
  Spurious irq 95: 0xffdf, please flush posted write for irq 25
  4Spurious irq 95: 0xffdf, please flush posted write for irq
 25
  Spurious irq 95: 0xffdf, please flush posted write for irq 25
  4Spurious irq 95: 0xffdf, please flush posted write for irq
 25
 
 
 
  Please note it's not continuous.  Driver is also working fine. Is
 it something to do with the latest spurious interrupt patch.
  http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-
 2.6.git;a=commitdiff;h=ea153a1765dc754be688013192e8c83c40e008dc
 
  Is there something to do in the driver to solve this interrupt
 warning issue.
 
 Interesting. Can you please try adding a read-back of the interrupt
 status register (or revision register) at the end of the interrupt
 handler for irq 25?
 
 I guess it's INT_24XX_DSS_IRQ, which is the same for 34xx as 24xx?
 
 Most likely this spurious interrupt means that the write does not
 get posted all the way to the interrupt controller for device
 interrupt
 handler for irq 25 before irq 25 is unmasked again.
 
 Doing a read back in the irq 25 handler after the last write forces
 the write to get posted.
 
 Let me know if that does not help.
 
 Regards,
 
 Tony
 --
 To unsubscribe from this list: send the line unsubscribe linux-
 omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC] OMAP3EVM Multi-Media Daughter Card Support

2009-01-06 Thread Hiremath, Vaibhav

Hi,

This RFC provides high level design/changes for supporting 
Multi-Media/Mass-Market/Mistral/Customer Daughter card based on OMAP3 EVM.

Background
==
OMAP3 EVM doesn't support camera interface, TI and Mistral has developed 
Daughter card on top of OMAP3 EVM which will add support for 

- TVP5146 decoder, providing BT656 capture support through 
S-Video/Component/Composite input.
- Camera/sensor interface (Micron)
- HSUSB Transceiver USB-83320

Soon the block-diagram, schematics and other details will be available publicly.

Hardware Block Diagram
==
Below is top level block diagram for the OMAP3 EVM Multi-Media Daughter Card -

  
 
 OMAP 3 Processor  Multi-Media Daughter Card
Board
 - - - - - - -   - - - - - - -- - - - - - - - - - - - - - 
| OMAP3530| |- - - - - - --O S-Vid  |
| | |   |   ||
| I2C ||   |  |O|   |
| | |   |   |-|O|Compo  |
| | |   /|  |  Video|  |O|site   |
| | |  | |  |  Decoder  ||
| | |  | |-|  TVP5146  |  |O|   |
|  Camera | |  | |   - - - - - - -|O|Compo  |
|interface|---| | |O|nent   |
| | |  | |   - - - - - - |
| | |  | |-|   ||
| | |  | |  |  Micron   ||
| | |  | |  |  Image||
| | |   \|  |  Sensor   ||
| I2C ||   ||
| | |- - - - - - |
| | ||
|HSUSB| |- - - - - - |
| HOST|---|   ||
 - - - - - - -  |   |   HSUSB   ||
|   |Transceiver||
|   |  USB83320 ||
|   |   ||
|- - - - - - |
||
||
 - - - - - - -- - - - - - - - - - - - - -
   
High Level-Software Design
=

Following are the files which will add support for Daughter Card -

- arch/arm/mach-omap2/board-omap3evm-dc.c
Source file which will handle initialization of the GPMC and similar 
stuff, registers to the I2C framework for I2C bus 3(TVP5146 interface).
  
- arch/arm/mach-omap2/board-omap3evm-dc.h
Corresponding Header file.


Current implementation/support available


The basic Daughter card support has been added to the latest git kernel; soon I 
will be posting the patches for review.

Following things have been tested - 
- TVP5146: (On top of Sergio's ISP-Camera patch-sets)
- S-Video
- Composite

- HSUSB:
Basic functionality is working.

NOTE: Please note that all the above testing is done on top of ES2.0 silicon 
version.

TODO - 
- Component support (Should be very easy)
- Rigorous testing of TVP5146 and HSUSB.
- Camera/sensor support

Thanks,
Vaibhav Hiremath

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] Add Omnivision OV9640 sensor support.

2008-12-07 Thread Hiremath, Vaibhav

Hi Soni,

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:linux-omap-
 [EMAIL PROTECTED] On Behalf Of Trilok Soni
 Sent: Sunday, December 07, 2008 3:11 PM
 To: Hans Verkuil
 Cc: v4l; linux-omap@vger.kernel.org Mailing List; Sakari Ailus
 Subject: Re: [PATCH] Add Omnivision OV9640 sensor support.

 Hi Hans,

 On Mon, Dec 1, 2008 at 6:21 PM, Trilok Soni [EMAIL PROTECTED]
 wrote:
  Hi Hans,

  I reviewed this sensor driver and it's fine except for one thing:
  setting the default registers from outside the driver. This is a
 really
  bad idea. I2C drivers should be self-contained. I've made the
 same
  comment in the tvp514x driver review which I'm copying below
 (with some
  small edits):

  I knew that you are going to comment on that, and I agree on those
  points. I will pull in that register initialization to the driver.

 Attached the updated ov9640 sensor patch.

[Hiremath, Vaibhav] I just had quick walk through of code and I think you may 
want to take look at the review comments received for TVP514x driver 
(Especially for I2C).

 --
 ---Trilok Soni
 http://triloksoni.wordpress.com
 http://www.linkedin.com/in/triloksoni
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] Add OMAP2 camera driver

2008-12-05 Thread Hiremath, Vaibhav



Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Tony Lindgren [mailto:[EMAIL PROTECTED]
 Sent: Friday, December 05, 2008 5:16 AM
 To: Hiremath, Vaibhav
 Cc: Koen Kooi; Trilok Soni; Hans Verkuil; Sakari Ailus; linux-
 [EMAIL PROTECTED] Mailing List; [EMAIL PROTECTED]
 Subject: Re: [PATCH] Add OMAP2 camera driver
 
 * Hiremath, Vaibhav [EMAIL PROTECTED] [081203 01:38]:
 
 
  Thanks,
  Vaibhav Hiremath
 
   -Original Message-
   From: Koen Kooi [mailto:[EMAIL PROTECTED]
   Sent: Wednesday, December 03, 2008 3:04 PM
   To: Hiremath, Vaibhav
   Cc: Trilok Soni; Hans Verkuil; Sakari Ailus; linux-
   [EMAIL PROTECTED] Mailing List; [EMAIL PROTECTED]
   Subject: Re: [PATCH] Add OMAP2 camera driver
  
  
   Op 3 dec 2008, om 08:05 heeft Hiremath, Vaibhav het volgende
   geschreven:
OMAP3 -
Display - (Posted twice with old DSS library)
- omap_vout.c
- omap_voutlib.c
- omap_voutlib.h
- omap_voutdef.h
Camera - (Will come soon)
- omap34xxcam.c
- omap34xxcam.h
ISP - (Will come soon)
- Here definitely we will plenty number of files.
  
   Isn't DSS2 supposed to work on omap2 (and perhaps omap1) as
 well?
  
  [Hiremath, Vaibhav] yes, but the DSS2 library goes under
 arch/arm/plat-omap/dss/. The above files are belongs to the driver
 underneath.
 
 Huh? Why would it need to be under plat-omap?
 
[Hiremath, Vaibhav] This is low level library which will export Kernel API's to 
top level driver like, Frame buffer and V4L2 driver. So this has to be in some 
common directory, and both patches on DSS (from Tomi and from TI) aligned to 
the same thing.

 Tony

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] Add OMAP2 camera driver

2008-12-03 Thread Hiremath, Vaibhav



Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Koen Kooi [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, December 03, 2008 3:04 PM
 To: Hiremath, Vaibhav
 Cc: Trilok Soni; Hans Verkuil; Sakari Ailus; linux-
 [EMAIL PROTECTED] Mailing List; [EMAIL PROTECTED]
 Subject: Re: [PATCH] Add OMAP2 camera driver
 
 
 Op 3 dec 2008, om 08:05 heeft Hiremath, Vaibhav het volgende
 geschreven:
  OMAP3 -
  Display - (Posted twice with old DSS library)
  - omap_vout.c
  - omap_voutlib.c
  - omap_voutlib.h
  - omap_voutdef.h
  Camera - (Will come soon)
  - omap34xxcam.c
  - omap34xxcam.h
  ISP - (Will come soon)
  - Here definitely we will plenty number of files.
 
 Isn't DSS2 supposed to work on omap2 (and perhaps omap1) as well?
 
[Hiremath, Vaibhav] yes, but the DSS2 library goes under 
arch/arm/plat-omap/dss/. The above files are belongs to the driver underneath.
 
 regards,
 
 Koen

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/2] TVP514x Driver with Review comments fixed

2008-12-02 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: David Brownell [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, December 02, 2008 2:05 PM
 To: Hiremath, Vaibhav
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
 [EMAIL PROTECTED]; linux-
 [EMAIL PROTECTED]; Jadav, Brijesh R; Shah, Hardik; Hadli,
 Manjunath; R, Sivaraj; Karicheri, Muralidharan
 Subject: Re: [PATCH 2/2] TVP514x Driver with Review comments fixed

 On Monday 01 December 2008, David Brownell wrote:
   - Pointer to init_reg_seq, which is pointer to array of
 structure
     for tvp514x_regs. This is little bit ugly, since will
 have to
     export tvp514x_regs structure.

  The platform_data should not hold such stuff; it's not board-
 specific.
  I'd expect platform_data to hold regulator_init_data as needed to
  instantiate the regulator; and maybe other stuff needed on this
 board
  too.  Floor and ceiling parameters, maybe, unless they change at
 runtime.

 Apologies, I was confusing this driver with another.  For a video
 codec, the platform_data should say things like which of the dozen
 or so input channels are wired up, and how; and how the outputs
 are encoded (8 bits, 2x 8 bits, 10 bits, 2x 10 bits, etc).  Nothing
 to do with regulators or DVFS.

 And the id parameter to probe() is enough to tell whether this is
 a '46 device, with extra registers and input channels, or a '47
 that's less capable (but lower power, etc).

[Hiremath, Vaibhav] To avoid any more confusion, I will post the patch again 
for review, which will give you clear picture.

  The init sequence wouldn't matter at all for i2c_get_clientdata(),
  since it should only kick in during probe().

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] Add OMAP2 camera driver

2008-12-02 Thread Hiremath, Vaibhav



Thanks,
Vaibhav Hiremath

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:video4linux-list-
 [EMAIL PROTECTED] On Behalf Of Hans Verkuil
 Sent: Monday, December 01, 2008 6:27 PM
 To: Trilok Soni
 Cc: Sakari Ailus; linux-omap@vger.kernel.org Mailing List;
 [EMAIL PROTECTED]
 Subject: Re: [PATCH] Add OMAP2 camera driver
 
 On Friday 28 November 2008 11:07:15 Trilok Soni wrote:
  Hi Hans
 
   I'm in if the aim is to get this back to linux-omap. :-)
 (Waiting
   for the next patch from Trilok.)
 
  Attached the updated patch for OMAP2 camera driver.
 
 Hi Trilok, Sakari,
 
 I've merged it in my tree: http://www.linuxtv.org/hg/~hverkuil/v4l-
 dvb
 
 Is it OK for me to issue a pull request for that it can be merged in
 the
 v4l-dvb master?
 

[Hiremath, Vaibhav] How about making a separate directory for OMAP, which will 
contain OMAP1/2/3 specific drivers?

 Regards,
 
   Hans
 
 --
 Hans Verkuil - video4linux developer - sponsored by TANDBERG
 
 --
 video4linux-list mailing list
 Unsubscribe mailto:video4linux-list-
 [EMAIL PROTECTED]
 https://www.redhat.com/mailman/listinfo/video4linux-list

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] Add OMAP2 camera driver

2008-12-02 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Trilok Soni [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, December 03, 2008 12:18 PM
 To: Hiremath, Vaibhav
 Cc: Hans Verkuil; Sakari Ailus; linux-omap@vger.kernel.org Mailing
 List; [EMAIL PROTECTED]
 Subject: Re: [PATCH] Add OMAP2 camera driver

 Hi Vaibhav,

  [Hiremath, Vaibhav] How about making a separate directory for
 OMAP, which will contain OMAP1/2/3 specific drivers?

 I really don't want omap directory for OMAP1 and OMAP2 atleast. Even
 in my next patches for OMAP1 camera controller I am going to  remove
 omap/ directory existing on linux-omap git history. For omap1 it
 is
 just two files camera_core.c and omap16xxcam.c, so no need of
 directory here. Even going further I am going to merge camera_core
 and
 omap16xxcam into one file, as I don't see code for any other omap1
 platform like omap15xxcam.

 I don't know about OMAP3 ISP code, some one from TI should refresh
 those patches.

[Hiremath, Vaibhav] I can tell you that for OMAP3 we do have lot of files 
coming in, and it really brings more confusion if we have OMAP1 and OMAP2 lying 
outside and OMAP3 code (Display + capture) say under omap/ or omap3/.

It makes sense to have omap/ directory, and all the versions/devices of OMAP 
get handled from omap/Kconfig and omap/Makefile. Even if they have single file 
it would be nice to follow directory layers.

Hans, Sakari or Mauro can provide their opinion on this, and decide how to 
handle this. 

I am just providing details, so that it would be easy to take decision - 

OMAP1 - (I have listed names from old O-L tree)
- omap16xxcam.c
- camera_core.c
- camera_hw_if.h
- omap16xxcam.h
- camera_core.h

OMAP2 - (I have listed names from old O-L tree)
- omap24xxcam.c
- omap24xxcam-dma.c
- omap24xxcam.h

In future may be display will add here.

OMAP3 - 
Display - (Posted twice with old DSS library)
- omap_vout.c
- omap_voutlib.c
- omap_voutlib.h
- omap_voutdef.h
Camera - (Will come soon)
- omap34xxcam.c
- omap34xxcam.h
ISP - (Will come soon)
- Here definitely we will plenty number of files.

 --
 ---Trilok Soni
 http://triloksoni.wordpress.com
 http://www.linkedin.com/in/triloksoni

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/2] TVP514x Driver with Review comments fixed

2008-12-01 Thread Hiremath, Vaibhav

Hi David,

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: David Brownell [mailto:[EMAIL PROTECTED]
 Sent: Saturday, November 29, 2008 1:24 AM
 To: Hiremath, Vaibhav
 Cc: [EMAIL PROTECTED]; davinci-linux-open-source-
 [EMAIL PROTECTED]; linux-omap@vger.kernel.org; Jadav,
 Brijesh R; Shah, Hardik; Hadli, Manjunath; R, Sivaraj; Karicheri,
 Muralidharan
 Subject: Re: [PATCH 2/2] TVP514x Driver with Review comments fixed

 On Friday 28 November 2008, David Brownell wrote:
  On Friday 28 November 2008, Hiremath, Vaibhav wrote:
   Will have to now think how to differentiate between these
   two chips and handle this sequence.

  That's really easy, the id parameter to probe() tells you:

  if (strcmp(id-name, tvp5146) == 0)
  /* original '46 part ... */;
  else if (strmcp(id-name, tvp5146m2) == 0)
  /* new '46m2 version ... */
  ... etc

 ... although it's even easier to use id-driver_data to
 hold, for example, a bitmask telling various attributes
 of that particular device.  Examples here:

   - does it have the extra '46 registers?
   - does it use the original '46 init sequence?
   - or the new m2 one?
   - or the original '47 init sequence?
   - or the new m1 version?
   - ...

 Another common use of driver_data is to hold a pointer
 to a struct holding chip-specific data that doesn't fit
 into a simple bitmask.

[Hiremath, Vaibhav] I am trying to use/save complete init sequence in 
id-driver_data -

static const struct i2c_device_id tvp514x_id[] = {
{tvp5146, (unsigned int)tvp5146_init},
{tvp5146m2, (unsigned int)tvp514xm_init},
{tvp5147, (unsigned int)tvp5147_init},
{tvp5147m1, (unsigned int)tvp514xm_init},
{},
};

NOTE: Please note that init sequence for 46, 47 are different.

But I came to know that, client structure doesn't have any parameter which will 
provide me the index under this id table. The only differentiating parameter we 
have is name (decoder-client-driver-name).

I can use id-driver_data only in my probe function without any index. 

So left with only following options -

1) 
if (strcmp(id-name, tvp5146) == 0)
/* original 46 init seq */;
else if (strcmp(id-name, tvp5147) == 0) 
/* original 47 init seq */
else if ((strmcp(id-name, tvp5146m2) == 0) || 
(strmcp(id-name, tvp5147m1) == 0))
/* New 46/47 init seq */

2)

Driver specific structure must contain either of
- Index of i2c_device_id table, use this to get the driver_data. (This 
also requires string compare to get the index.)
- Pointer to init_reg_seq, which is pointer to array of structure for 
tvp514x_regs. This is little bit ugly, since will have to export tvp514x_regs 
structure.
- Or have pointer to i2c_device_id itself. (Implemented and tested)

I prefer to use second option, instead of comparing the name string in s_power 
every time. And it will be very easy to add even more chips providing generic 
solution; we need to just add entry to i2c_device_id with expected init 
sequence and you are done.

Any suggestions or inputs appreciated???

 - Dave

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/2] TVP514x Driver with Review comments fixed

2008-12-01 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: David Brownell [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, December 02, 2008 12:09 PM
 To: Hiremath, Vaibhav
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
 [EMAIL PROTECTED]; linux-
 [EMAIL PROTECTED]; Jadav, Brijesh R; Shah, Hardik; Hadli,
 Manjunath; R, Sivaraj; Karicheri, Muralidharan
 Subject: Re: [PATCH 2/2] TVP514x Driver with Review comments fixed

 On Monday 01 December 2008, Hiremath, Vaibhav wrote:

   Another common use of driver_data is to hold a pointer
   to a struct holding chip-specific data that doesn't fit
   into a simple bitmask.

  [Hiremath, Vaibhav] I am trying to use/save complete init sequence
 in
  id-driver_data -

  static const struct i2c_device_id tvp514x_id[] = {
  {tvp5146, (unsigned int)tvp5146_init},

 Well, kernel_ulong_t ...

  {tvp5146m2, (unsigned int)tvp514xm_init},
  {tvp5147, (unsigned int)tvp5147_init},
  {tvp5147m1, (unsigned int)tvp514xm_init},
  {},
  };

  NOTE: Please note that init sequence for 46, 47 are different.

  I prefer to use second option, instead of comparing the name
 string in
  s_power every time. And it will be very easy to add even more
 chips
  providing generic solution; we need to just add entry to
 i2c_device_id
  with expected init sequence and you are done.

 If I interpret your words correctly, I agree.  The whole point of
 the id table is to let probe just use the id directly to get at
 descriptors with chip-specific data.

 - Dave

[Hiremath, Vaibhav] We are almost on same page, but you are looking to 
implement this in probe function where we do have id straight coming as 
params.
But for the devices like OMAP where power management is critical thing, I want 
to put the TVP to off state and bring it again whenever required (being used). 
For this, we do have ioctl interface called  ioctl_s_power under V4L2-Int 
framework. 

To get the sequence supported for registered chip (46/47/4xM), I need index 
under the I2C_table (client-driver-id_table[index]) which will give me the 
driver_data for registered chip.

  Any suggestions or inputs appreciated???

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/2] TVP514x Driver with Review comments fixed

2008-11-28 Thread Hiremath, Vaibhav



Thanks,
Vaibhav Hiremath

 -Original Message-
 From: David Brownell [mailto:[EMAIL PROTECTED]
 Sent: Friday, November 28, 2008 10:04 PM
 To: Hiremath, Vaibhav
 Cc: [EMAIL PROTECTED]; davinci-linux-open-source-
 [EMAIL PROTECTED]; linux-omap@vger.kernel.org; Jadav,
 Brijesh R; Shah, Hardik; Hadli, Manjunath; R, Sivaraj; Karicheri,
 Muralidharan
 Subject: Re: [PATCH 2/2] TVP514x Driver with Review comments fixed
 
 On Friday 28 November 2008, [EMAIL PROTECTED] wrote:
  +/*
  + * Supported standards - These must be ordered according to enum
 tvp514x_std
  + * order.
 
 In this case it'd be easy to remove that restriction...
 
 
[Hiremath, Vaibhav] Very true, I never thought this of while implementing. I 
will change this in next patch.

  + * Currently supports two standards only, need to add support for
 rest of the
  + * modes, like SECAM, etc...
  + */
  +static struct tvp514x_std_info tvp514x_std_list[] = {
  +   {
 
   [STD_NTSC_MJ] = {
 
  +    .width = NTSC_NUM_ACTIVE_PIXELS,
  +    .height = NTSC_NUM_ACTIVE_LINES,
  +    .video_std = VIDEO_STD_NTSC_MJ_BIT,
  +    .standard = {
  +         .index = 0,
  +         .id = V4L2_STD_NTSC,
  +         .name = NTSC,
  +         .frameperiod = {1001, 3},
  +         .framelines = 525
  +        },
  +   }, {
 
   [STD_PAL_BDGHIN] = { ...
 
 ... for clarity.  Though it's more conventional to have
 the undefined value be zero, and thus what kzalloc or
 static initialization provides, than have NTSC be zero.  :)
 
 
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/2] TVP514x Driver with Review comments fixed

2008-11-28 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: David Brownell [mailto:[EMAIL PROTECTED]
 Sent: Friday, November 28, 2008 10:22 PM
 To: Hiremath, Vaibhav
 Cc: [EMAIL PROTECTED]; davinci-linux-open-source-
 [EMAIL PROTECTED]; linux-omap@vger.kernel.org; Jadav,
 Brijesh R; Shah, Hardik; Hadli, Manjunath; R, Sivaraj; Karicheri,
 Muralidharan
 Subject: Re: [PATCH 2/2] TVP514x Driver with Review comments fixed

 On Friday 28 November 2008, [EMAIL PROTECTED] wrote:
  +   for (; next-token != TOK_TERM; next++) {
  +   if (next-token == TOK_DELAY) {
  +   schedule_timeout(msecs_to_jiffies(next-
 val));

   msleep(next-val);

 would be clearer and more conventional.

[Hiremath, Vaibhav] Yes, verified the implementation of msleep. It does the 
same thing what I am doing. Good to change.

  +   continue;
  +   }

  +static int
  +tvp514x_probe(struct i2c_client *client, const struct
 i2c_device_id *id)
  +{
  +   struct tvp514x_decoder *decoder = tvp514x_dev;
  +   int err;
  +
  +   if (i2c_get_clientdata(client))
  +   return -EBUSY;
  +

 When no driver is bound to the client, clientdata is undefined.
 So just strike that ... you can rely on probe() only being
 called on un-bound drivers.

[Hiremath, Vaibhav] I am not an expert in I2C, will get back to you on this.

 I still don't see any post-reset chip init being done.  The data
 sheets for the tvp5146 and tvp5147 say that after reset, some
 commands must be sent ... that's not being done here.  Are you
 assuming perhaps tvp5146m2 and tvp5147m1, although they are not
 listed as chips supported by this driver?  (That's a repeat of
 a previous review comment, which garnered no response, so the
 $SUBJECT is inaccurate:  at least some review comments have not
 yet been addressed...)

[Hiremath, Vaibhav] Thanks pointing me to this, I was not aware of this thing. 
Two same ID chips (0x46) require different reset sequence. May be overlooked 
this part due to ID.

Will have to now think how to differentiate between these two chips and handle 
this sequence.

 - Dave

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/2] TVP514x V4L int device driver support

2008-11-24 Thread Hiremath, Vaibhav

Hans,

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:linux-omap-
 [EMAIL PROTECTED] On Behalf Of Trilok Soni
 Sent: Monday, November 24, 2008 2:13 PM
 To: Hans Verkuil
 Cc: [EMAIL PROTECTED]; linux-omap@vger.kernel.org;
 [EMAIL PROTECTED]
 Subject: Re: [PATCH 2/2] TVP514x V4L int device driver support

 Hi Hans,

  The v4l2-int-device.h stuff should never have been added. Ditto
 for
  parts of the soc-camera framework that duplicates v4l2-int-
 device.h. My
  new v4l2_subdev support will replace the three methods of using
 i2c
  devices (or similar) that are currently in use. It's exactly to
 reduce
  the confusion that I'm working on this.

  It's been discussed before on the v4l mailinglist and the relevant
  developers are aware of this. It's almost finished, just need to
 track
  down a single remaining oops.

 Right, I will wait for your updates.

 I am planning to send omap24xxcam and ov9640 drivers (now deleted)
 available from linux-omap tree after syncing them with latest
 linux-2.6.x tree, and the whole driver and the sensor is written
 using
 v4l2-int-device framework. I am going to send it anyway, so that it
 can have some review comments.

[Hiremath, Vaibhav] Is your current development accessible through linuxtv.org? 
Can you share it with us, so that we can have a look into it? Which driver you 
are migrating to new interface (which I can refer to as a sample)?
Again I would like to know, how are we handling current drivers (soc-camera and 
v4l2-int)?

 --
 ---Trilok Soni
 http://triloksoni.wordpress.com
 http://www.linkedin.com/in/triloksoni
 --
 To unsubscribe from this list: send the line unsubscribe linux-
 omap in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] [OMAPZOOM] OMAP: DISPLAY: Code Clean up Trailing Whitespace

2008-11-24 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:linux-omap-
 [EMAIL PROTECTED] On Behalf Of Trilok Soni
 Sent: Tuesday, November 25, 2008 12:14 PM
 To: Ogeid Alavaz
 Cc: linux-omap@vger.kernel.org
 Subject: Re: [PATCH] [OMAPZOOM] OMAP: DISPLAY: Code Clean up
 Trailing Whitespace

 Hi Ogeid,

 On Tue, Nov 25, 2008 at 12:11 PM, Ogeid Alavaz [EMAIL PROTECTED]
 wrote:
  Hi Soni,

  the video/omap directory is at omapzoom.org kernel, from master
 branch,
  it has been removed from linux-omap kernel and pass it to v4l2
 kernel,
  thats what I had understand.

   drivers/media/video/omap/Makefile  |2 +-
   drivers/media/video/omap/omap24xxlib.c |   64 +++---
   drivers/media/video/omap/omap24xxlib.h |4 +-
   drivers/media/video/omap/omap24xxvout.c|  294
 ++--
   drivers/media/video/omap/omap24xxvout.h|6 +-
   drivers/media/video/omap/omap24xxvoutdef.h |   32 ++--
   6 files changed, 201 insertions(+), 201 deletions(-)

 Not really. Some one need to submit omap24xxcam and omap16xxcam
 driver
 to v4l2-list, not one has done this yet. Also I don't remember when
 this omap24xxlib.[ch] and vout.[ch] was accepted in the linux-omap?

[Hiremath, Vaibhav] under omap-linux, there is no support for DSS driver, the 
files you are referring to are part of omapzoom. Don't get confused between two 
trees, both the trees are different and has different set of features/code-base 
supported.

 I am taking liberty to CC linux-omap list.

 --
 ---Trilok Soni
 http://triloksoni.wordpress.com
 http://www.linkedin.com/in/triloksoni
 --
 To unsubscribe from this list: send the line unsubscribe linux-
 omap in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [REVIEW PATCH 0/9] DSS: Series description

2008-11-23 Thread Hiremath, Vaibhav

   create mode 100644 arch/arm/plat-omap/dss/Kconfig
   create mode 100644 arch/arm/plat-omap/dss/Makefile
   create mode 100644 arch/arm/plat-omap/dss/dispc.c
   create mode 100644 arch/arm/plat-omap/dss/display.c
   create mode 100644 arch/arm/plat-omap/dss/dpi.c
   create mode 100644 arch/arm/plat-omap/dss/dsi.c
   create mode 100644 arch/arm/plat-omap/dss/dss.c
   create mode 100644 arch/arm/plat-omap/dss/dss.h
   create mode 100644 arch/arm/plat-omap/dss/rfbi.c
   create mode 100644 arch/arm/plat-omap/dss/sdi.c
   create mode 100644 arch/arm/plat-omap/dss/venc.c
   create mode 100644 arch/arm/plat-omap/include/mach/display.h
   create mode 100644 drivers/video/omap2/Kconfig
   create mode 100644 drivers/video/omap2/Makefile
   create mode 100644 drivers/video/omap2/omapfb-ioctl.c
   create mode 100644 drivers/video/omap2/omapfb-main.c
   create mode 100644 drivers/video/omap2/omapfb-sysfs.c
   create mode 100644 drivers/video/omap2/omapfb.h
   create mode 100644 drivers/video/omap2/panel-dvi.c
   create mode 100644 drivers/video/omap2/panel-sdp3430.c
 
  --
   Tomi Valkeinen
 
  --
  To unsubscribe from this list: send the line unsubscribe linux-
 omap in
  the body of a message to [EMAIL PROTECTED]
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
 Is [REVIEW PATCH 2/9] missing?
 
[Hiremath, Vaibhav] No, below is the link - 

http://marc.info/?l=linux-fbdev-develm=122581507722475w=2


 Regards,
 Arun
 --
 To unsubscribe from this list: send the line unsubscribe linux-
 omap in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: defconfig for omap3-evm

2008-11-21 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:linux-omap-
 [EMAIL PROTECTED] On Behalf Of Amit Pundir
 Sent: Friday, November 21, 2008 5:29 PM
 To: Premi, Sanjeev
 Cc: linux-omap@vger.kernel.org
 Subject: Re: defconfig for omap3-evm

 Hi,

  When you say TI kernel, is it the one you received with your EVM
 package?

  If so, you will need to continue using the same defconfig.

 Yes the one received with the EVM package.

  drivers/built-in.o: In function `omapfb_do_probe':
  /home/amit/omap35xx/ti/muru_linux/linux-2.6.22.1/drivers/video
  /omap/omapfb_main.c:1777:
  undefined reference to `omap2_int_ctrl'

 undefined reference to `omap2_int_ctr' is the problem. This
 variable
 is only defined for ARCH_OMAP2 build and I cannot enable OMAP2 and
 OMAP3 builds simultaneously.

 This error comes when it tries to build LCD controller part which is
 an internal part of evm and hence necessary.

 Still stuck at the kernel build.

[Hiremath, Vaibhav] Can you provide your .config file? 

 Regards
 Amit Pundir
 --
 To unsubscribe from this list: send the line unsubscribe linux-
 omap in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: defconfig for omap3-evm

2008-11-21 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Amit Pundir [mailto:[EMAIL PROTECTED]
 Sent: Friday, November 21, 2008 5:46 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org
 Subject: Re: defconfig for omap3-evm

 here it is.

[Hiremath, Vaibhav] Is this the valid config file? The reason I am asking is, I 
see both OMAP2 and OMAP3 architectures have been enabled.

 Thanks
 Amit Pundir

 On Fri, Nov 21, 2008 at 5:39 PM, Hiremath, Vaibhav [EMAIL PROTECTED]
 wrote:
  I think you missed to attach the .config file.

  Thanks,
  Vaibhav Hiremath
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: defconfig for omap3-evm

2008-11-21 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Amit Pundir [mailto:[EMAIL PROTECTED]
 Sent: Friday, November 21, 2008 5:44 PM
 To: Hiremath, Vaibhav
 Cc: Premi, Sanjeev; linux-omap@vger.kernel.org
 Subject: Re: defconfig for omap3-evm

 The reason I moved to linux-omap kernel from the provided with EVM
 is
 that I was not able to run my Xorg server on omap-3.

 So I raised my concern in Xorg mailing list regarding my problem
 i.e.
 running X on
 omap3-evm. In reply they told me that the problem is the TI's
 omapfb
 which won't let you set arbitrary modes. The mainstream one (i.e.
 the
 one in linux-omap) works fine with fbdev.

[Hiremath, Vaibhav] Can you please describe about the term arbitrary mode?

 Can anyone please confirm that it is a known issue with TI provided
 kernel.

 Regards
 Amit Pundir

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: OMAP Framebuffer memory allocation and mapping

2008-11-20 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:linux-omap-
 [EMAIL PROTECTED] On Behalf Of Tomi Valkeinen
 Sent: Thursday, November 20, 2008 4:22 PM
 To: linux-omap@vger.kernel.org
 Subject: OMAP Framebuffer memory allocation and mapping

 Hi,

 I have a couple of questions regarding the memory management for the
 new
 display subsystem.

 The new DSS allocates memory with dma_alloc_writecombine() and mmaps
 it
 to user space with dma_mmap_writecombine(). Allocation is done when
 omapfb starts up. Normally memory gets very quickly too fragmented
 for
 dma_alloc_writecombine() to work, but setting
 CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE helps this.

 However, even when CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE is set to 14,
 I
 am, for some reason, not able to allocate 1280x1024x4 (~5.2M)
 framebuffer. Could the consistent DMA area be already too
 fragmented, or
 is there some size limit there?

[Hiremath, Vaibhav] Similar issue I had also faced while implementing VRFB 
rotation on new DSS of yours. I increased the value of MAX_ORDER to 12 
(currently set to 11), defined in include/linux/mmzone.h file. And it worked 
for me; I am allocating 2048*720*4 bytes of buffer.

I am not sure community acceptance on this, probably somebody could suggest 
better way to this.

 There's also support to allocate fb memory in very early phase with
 reserve_bootmem(), which needs a predefined physical address and
 size
 that can come from the bootloader. I've been looking at the old DSS
 to
 see how this memory should be mapped, but I haven't been able to get
 it
 to work. It looks like the DSS DMA and the user space have a bit
 different view of the memory, so my assumption is that there's some
 caching or similar being done.

 So how to setup the memory gotten from reserve_bootmem() (or
 alloc_bootmem()) so that it would work the same way as
 dma_alloc_writecombine()'s memory?

 And generally: any other ideas how to improve the memory management
 of
 the DSS?

  Tomi

 --
 To unsubscribe from this list: send the line unsubscribe linux-
 omap in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: omap display controller strange problem

2008-11-20 Thread Hiremath, Vaibhav



Thanks,
Vaibhav Hiremath

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:linux-omap-
 [EMAIL PROTECTED] On Behalf Of Sudipta GHOSH
 Sent: Thursday, November 20, 2008 8:48 PM
 To: linux-omap@vger.kernel.org
 Subject: omap display controller strange problem
 
 Hi,
 
 I am facing a strange problem with omap display controller. (kernel
 2.6.25)
 
 in omap_dispc_irq_handler, if I use printk then only display is
 working (initialization and refreshing)
 
[Hiremath, Vaibhav] What do you mean by only display?

Can you please provide detailed information about the issue? Your mail doesn't 
convey much.

 else after few refresh ..its stop working.
 
 static irqreturn_t omap_dispc_irq_handler(int irq, void *dev)
 {
   
 
   if ((stat  dispc.enabled_irqs)  dispc.irq_callback) {
   printk(omap_irqH\n); 
  ?
   dispc.irq_callback(dispc.irq_callback_data);
   }
 
 
 Regards,
 -SG
 --
 To unsubscribe from this list: send the line unsubscribe linux-
 omap in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [REVIEW PATCH] Added OMAP3EVM support on Tomis FBDEV/DSS Patches

2008-11-18 Thread Hiremath, Vaibhav



Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Koen Kooi [mailto:[EMAIL PROTECTED]
 Sent: Saturday, November 15, 2008 1:14 AM
 To: Tomi Valkeinen
 Cc: Hiremath, Vaibhav; [EMAIL PROTECTED];
 linux-omap@vger.kernel.org
 Subject: Re: [REVIEW PATCH] Added OMAP3EVM support on Tomis
 FBDEV/DSS Patches
 
 
 Op 14 nov 2008, om 16:53 heeft Tomi Valkeinen het volgende
 geschreven:
 
  Hi,
  On Fri, 2008-11-14 at 18:05 +0530, ext Hiremath, Vaibhav wrote:
 
 
  I think the LCD panel on SDP and EVM boards are the same, so we
  should
  only have one driver. Do you have specifications about the LCD?
 The
  manufacturer, model etc?. I didn't find any proper information
 about
  the
  LCD.
 
  [Hiremath, Vaibhav] The LCD on OMAP3EVM is Sharp LCD (Model No. -
  LS037V7DW01).
  Koen has already conformed that panel3430sdp.c is working with
  OMAP3EVM, let me try at my end. If it works properly then we can
  have same file to build for both SDP and EVM. But in that case it
  make sense to rename file to panel-lcd.c.
 
 
  I took the liberty to add you EVM changes to my tree, with a
 comment
  about the origin. I also changed the SDP panel name to sharp
 panel,
  and
  made both EVM and SDP use that. But I can't test the EVM, as I
 don't
  have one.
 
 I finally got rc4 working on evm and with your latest patches I get:
 
[Hiremath, Vaibhav] Probably you missed to apply the clock set_rate and 
round_rate patches by Mans Rullgard.

 udevd version 124 started
 eth0: link down
 eth0: link up, 100Mbps, full-duplex, lpa 0x8DE1
 DSS2 debug: best_ld is 1, best_pd is 3
 DSS2 debug: best_ld is 1, best_pd is 3
 DSS2 debug: best.lck_div is 1, best.pck_div is 3
 omap-dss DISPLAY: omap_dss_mgr_apply(lcd)
 omap-dss DISPC: dispc_setup_plane 0, 8720, sw 480, 0,0, 480x640
 -
 480x640, (ilace 0)
 omap-dss DISPC: dispc_enable_plane 0, 1
 omap-dss DISPC: dispc_enable_plane 1, 0
 omap-dss DISPC: dispc_enable_plane 2, 0
 omap-dss DISPC: GO LCD
 Division by zero in kernel.
 [c0033a60] (dump_stack+0x0/0x14) from [c0033a8c]
 (__div0+0x18/0x20)
 [c0033a74] (__div0+0x0/0x20) from [c01a235c] (Ldiv0+0x8/0x10)
 [c01c7f08] (check_fb_var+0x0/0x35c) from [c01c8280]
 (omapfb_check_var+0x1c/0x20)
   r7:c6711e08 r6:c708bc00 r5:4601 r4:c01c8264
 [c01c8264] (omapfb_check_var+0x0/0x20) from [c01b55dc]
 (fb_set_var
 +0xd4/0x254)
 [c01b5508] (fb_set_var+0x0/0x254) from [c01b59c0] (fb_ioctl
 +0x170/0x4f0)
 [c01b5850] (fb_ioctl+0x0/0x4f0) from [c00c59c8] (vfs_ioctl
 +0x34/0x94)
   r8:c0030004 r7:c7b4e6c0 r6:03d7ca30 r5:4601 r4:c7b4e6c0
 [c00c5994] (vfs_ioctl+0x0/0x94) from [c00c5fc8] (do_vfs_ioctl
 +0x4a4/0x4e4)
   r7:c7b4e6c0 r6:03d7ca30 r5:c7b4e6c0 r4:c70f9290
 [c00c5b24] (do_vfs_ioctl+0x0/0x4e4) from [c00c6048] (sys_ioctl
 +0x40/0x64)
   r9:c671 r8:c0030004 r6:4601 r5:03d7ca30 r4:0006
 [c00c6008] (sys_ioctl+0x0/0x64) from [c002fe80]
 (ret_fast_syscall
 +0x0/0x2c)
   r7:0036 r6:0281 r5:01fc r4:
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best.lck_div is 0, best.pck_div is 0
 Division by zero in kernel.
 [c0033a60] (dump_stack+0x0/0x14) from [c0033a8c]
 (__div0+0x18/0x20)
 [c0033a74] (__div0+0x0/0x20) from [c01a235c] (Ldiv0+0x8/0x10)
 [c01c7f08] (check_fb_var+0x0/0x35c) from [c01c8280]
 (omapfb_check_var+0x1c/0x20)
   r7:c6711e08 r6:c708bc00 r5:4601 r4:c01c8264
 [c01c8264] (omapfb_check_var+0x0/0x20) from [c01b55dc]
 (fb_set_var
 +0xd4/0x254)
 [c01b5508] (fb_set_var+0x0/0x254) from [c01b59c0] (fb_ioctl
 +0x170/0x4f0)
 [c01b5850] (fb_ioctl+0x0/0x4f0) from [c00c59c8] (vfs_ioctl
 +0x34/0x94)
   r8:c0030004 r7:c7b4e6c0 r6:03d7ca30 r5:4601 r4:c7b4e6c0
 [c00c5994] (vfs_ioctl+0x0/0x94) from [c00c5fc8] (do_vfs_ioctl
 +0x4a4/0x4e4)
   r7:c7b4e6c0 r6:03d7ca30 r5:c7b4e6c0 r4:c70f9290
 [c00c5b24] (do_vfs_ioctl+0x0/0x4e4) from [c00c6048] (sys_ioctl
 +0x40/0x64)
   r9:c671 r8:c0030004 r6:4601 r5:03d7ca30 r4:0006
 [c00c6008] (sys_ioctl+0x0/0x64) from [c002fe80]
 (ret_fast_syscall
 +0x0/0x2c)
   r7:0036 r6:0281 r5:01fc r4:
 omap-dss DISPLAY: omap_dss_mgr_apply(lcd)
 omap-dss DISPC: dispc_setup_plane 0, 8720, sw 480, 0,0, 480x640
 -
 480x640, (ilace 0)
 omap-dss DISPC: dispc_enable_plane 0, 1
 omap-dss DISPC: dispc_enable_plane 1, 0
 omap-dss DISPC: dispc_enable_plane 2, 0
 omap-dss DISPC: GO LCD
 omap-dss DISPLAY: omap_dss_mgr_apply(lcd)
 omap-dss DISPC: dispc_setup_plane 0, 8720, sw 480, 0,0, 480x640
 -
 480x640, (ilace 0)
 omap-dss DISPC: dispc_enable_plane 0, 1
 omap-dss DISPC

RE: [Linux-fbdev-devel] [PATCHv3 1/4] OMAP 2/3 DSS Library

2008-11-18 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Ben Dooks [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, November 18, 2008 11:41 PM
 To: Shah, Hardik
 Cc: [EMAIL PROTECTED]; linux-omap@vger.kernel.org; linux-
 [EMAIL PROTECTED]
 Subject: Re: [Linux-fbdev-devel] [PATCHv3 1/4] OMAP 2/3 DSS Library

 On Tue, Nov 04, 2008 at 02:49:17PM +0530, Hardik Shah wrote:
  Removed the io_p2v macro and used ioremap and
  __raw_readl/__raw_writel instead.

  Signed-off-by: Brijesh Jadav [EMAIL PROTECTED]
  Hari Nagalla [EMAIL PROTECTED]
  Hardik Shah [EMAIL PROTECTED]
  Manjunath Hadli [EMAIL PROTECTED]
  R Sivaraj [EMAIL PROTECTED]
  Vaibhav Hiremath [EMAIL PROTECTED]

  ---
   arch/arm/plat-omap/Kconfig |7 +
   arch/arm/plat-omap/Makefile|2 +-
   arch/arm/plat-omap/include/mach/omap-dss.h |  896 +++
   arch/arm/plat-omap/omap-dss.c  | 2268

 why is this huge driver under arch/arm/plat-omap?

[Hiremath, Vaibhav] omap-dss.c is the OMAP-DSS library which will export low 
level API's to upper level driver (V4L2 and FBDEV). For more information please 
refer to the RFC which we had posted some time back, below is the link

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg02510.html

Again this is the old story on OMAP3-DSS development, there was parallel 
development from Nokia and we had acknowledged their design and implementation 
and started working/developing on top of it.

   4 files changed, 3172 insertions(+), 1 deletions(-)
   create mode 100644 arch/arm/plat-omap/include/mach/omap-dss.h
   create mode 100644 arch/arm/plat-omap/omap-dss.c
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: DVI output support for OMAP35x EVM

Thanks,
Vaibhav Hiremath

-Original Message-
From: twebb [mailto:[EMAIL PROTECTED]
Sent: Saturday, November 15, 2008 3:31 AM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org Mailing List
Subject: Re: DVI output support for OMAP35x EVM

The SDK 1.0.0 kernel for OMAP35x EVM from TI included DVI support
(480P and 720P) in the display driver. Is there a patch that was
submitted to the l-o git that includes that support? I'm looking
to
add DVI support into the kernel I'm currently using, which is
linux-omap-2.6 (tag = v2.6.27-omap1).

[Hiremath, Vaibhav] The l-o version of kernel doesn't support most
of the features supported in SDK 1.0.0. We are working towards it.
Below is link which will help you to understand where we are heading
-

http://markmail.org/message/p3aktfdgoumeludd#query:vaibhav%20DSS%20l
ib+page:1+mid:nzjsnawvnmtqjfwa+state:results

I'm not very familiar with the video and graphics subsystems, but
was
just looking for code that supported output on the DVI connector.
So
is the RFC by Hardik Shah at this link...
http://lists-archives.org/video4linux/23648-omap3-display-driver-
v4l2.html
the best description of where TI is headed? And is code based on
this only available in omapzoom git? Also, I don't see mention of
the
DVI support in the RFC - am I missing something?

[Hiremath, Vaibhav] This RFC was the initial plan and design from TII to
support all the features and functionality available with OMAPZOOM kernel
version. But recently Tomi (from Nokia) came with new design and implementation
which we acknowledged and started using as a baseline for DSS development.
Please refer to the below link which will take you to latest patches for DSS
from Nokia -
http://markmail.org/search/?q=Tomi+Valkeinen#query:Tomi%20Valkeinen%20from%3A%22Tomi%20Valkeinen%22+page:1+state:facets

This supports DVI output on FBDEV interface.

Thanks,
twebb

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html

RE: [REVIEW PATCH] Added OMAP3EVM support on Tomis FBDEV/DSS Patches

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Tomi Valkeinen [mailto:[EMAIL PROTECTED]
 Sent: Friday, November 14, 2008 9:24 PM
 To: Hiremath, Vaibhav
 Cc: [EMAIL PROTECTED]; linux-
 [EMAIL PROTECTED]
 Subject: RE: [REVIEW PATCH] Added OMAP3EVM support on Tomis
 FBDEV/DSS Patches

 Hi,
 On Fri, 2008-11-14 at 18:05 +0530, ext Hiremath, Vaibhav wrote:

   I think the LCD panel on SDP and EVM boards are the same, so we
   should
   only have one driver. Do you have specifications about the LCD?
 The
   manufacturer, model etc?. I didn't find any proper information
 about
   the
   LCD.

  [Hiremath, Vaibhav] The LCD on OMAP3EVM is Sharp LCD (Model No. -
 LS037V7DW01).
  Koen has already conformed that panel3430sdp.c is working with
 OMAP3EVM, let me try at my end. If it works properly then we can
 have same file to build for both SDP and EVM. But in that case it
 make sense to rename file to panel-lcd.c.

 I took the liberty to add you EVM changes to my tree, with a comment
 about the origin. I also changed the SDP panel name to sharp panel,
 and
 made both EVM and SDP use that. But I can't test the EVM, as I don't
 have one.

[Hiremath, Vaibhav] It's ok; you can incorporate required changes from my 
patches, no issues at all. Please share the code base which you merged from my 
patch so that I can validate it on EVM, since you don't have EVM to test. 

   The #ifdef mode selection in DVI panel is quit hack, I agree.
 The
   mode
   selection should be possible to be done runtime (or with kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [REVIEW PATCH] Added OMAP3EVM support on Tomis FBDEV/DSS Patches



Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Koen Kooi [mailto:[EMAIL PROTECTED]
 Sent: Saturday, November 15, 2008 1:14 AM
 To: Tomi Valkeinen
 Cc: Hiremath, Vaibhav; [EMAIL PROTECTED];
 linux-omap@vger.kernel.org
 Subject: Re: [REVIEW PATCH] Added OMAP3EVM support on Tomis
 FBDEV/DSS Patches
 
 
 Op 14 nov 2008, om 16:53 heeft Tomi Valkeinen het volgende
 geschreven:
 
  Hi,
  On Fri, 2008-11-14 at 18:05 +0530, ext Hiremath, Vaibhav wrote:
 
 
  I think the LCD panel on SDP and EVM boards are the same, so we
  should
  only have one driver. Do you have specifications about the LCD?
 The
  manufacturer, model etc?. I didn't find any proper information
 about
  the
  LCD.
 
  [Hiremath, Vaibhav] The LCD on OMAP3EVM is Sharp LCD (Model No. -
  LS037V7DW01).
  Koen has already conformed that panel3430sdp.c is working with
  OMAP3EVM, let me try at my end. If it works properly then we can
  have same file to build for both SDP and EVM. But in that case it
  make sense to rename file to panel-lcd.c.
 
 
  I took the liberty to add you EVM changes to my tree, with a
 comment
  about the origin. I also changed the SDP panel name to sharp
 panel,
  and
  made both EVM and SDP use that. But I can't test the EVM, as I
 don't
  have one.
 
 I finally got rc4 working on evm and with your latest patches I get:
 
[Hiremath, Vaibhav] What was the issue you figured out?

 udevd version 124 started
 eth0: link down
 eth0: link up, 100Mbps, full-duplex, lpa 0x8DE1
 DSS2 debug: best_ld is 1, best_pd is 3
 DSS2 debug: best_ld is 1, best_pd is 3
 DSS2 debug: best.lck_div is 1, best.pck_div is 3
 omap-dss DISPLAY: omap_dss_mgr_apply(lcd)
 omap-dss DISPC: dispc_setup_plane 0, 8720, sw 480, 0,0, 480x640
 -
 480x640, (ilace 0)
 omap-dss DISPC: dispc_enable_plane 0, 1
 omap-dss DISPC: dispc_enable_plane 1, 0
 omap-dss DISPC: dispc_enable_plane 2, 0
 omap-dss DISPC: GO LCD
 Division by zero in kernel.
[Hiremath, Vaibhav] Are you using the patch I submitted or the merged code from 
Tomi?

 [c0033a60] (dump_stack+0x0/0x14) from [c0033a8c]
 (__div0+0x18/0x20)
 [c0033a74] (__div0+0x0/0x20) from [c01a235c] (Ldiv0+0x8/0x10)
 [c01c7f08] (check_fb_var+0x0/0x35c) from [c01c8280]
 (omapfb_check_var+0x1c/0x20)
   r7:c6711e08 r6:c708bc00 r5:4601 r4:c01c8264
 [c01c8264] (omapfb_check_var+0x0/0x20) from [c01b55dc]
 (fb_set_var
 +0xd4/0x254)
 [c01b5508] (fb_set_var+0x0/0x254) from [c01b59c0] (fb_ioctl
 +0x170/0x4f0)
 [c01b5850] (fb_ioctl+0x0/0x4f0) from [c00c59c8] (vfs_ioctl
 +0x34/0x94)
   r8:c0030004 r7:c7b4e6c0 r6:03d7ca30 r5:4601 r4:c7b4e6c0
 [c00c5994] (vfs_ioctl+0x0/0x94) from [c00c5fc8] (do_vfs_ioctl
 +0x4a4/0x4e4)
   r7:c7b4e6c0 r6:03d7ca30 r5:c7b4e6c0 r4:c70f9290
 [c00c5b24] (do_vfs_ioctl+0x0/0x4e4) from [c00c6048] (sys_ioctl
 +0x40/0x64)
   r9:c671 r8:c0030004 r6:4601 r5:03d7ca30 r4:0006
 [c00c6008] (sys_ioctl+0x0/0x64) from [c002fe80]
 (ret_fast_syscall
 +0x0/0x2c)
   r7:0036 r6:0281 r5:01fc r4:
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best_ld is 255, best_pd is 255
 DSS2 debug: best.lck_div is 0, best.pck_div is 0
 Division by zero in kernel.
 [c0033a60] (dump_stack+0x0/0x14) from [c0033a8c]
 (__div0+0x18/0x20)
 [c0033a74] (__div0+0x0/0x20) from [c01a235c] (Ldiv0+0x8/0x10)
 [c01c7f08] (check_fb_var+0x0/0x35c) from [c01c8280]
 (omapfb_check_var+0x1c/0x20)
   r7:c6711e08 r6:c708bc00 r5:4601 r4:c01c8264
 [c01c8264] (omapfb_check_var+0x0/0x20) from [c01b55dc]
 (fb_set_var
 +0xd4/0x254)
 [c01b5508] (fb_set_var+0x0/0x254) from [c01b59c0] (fb_ioctl
 +0x170/0x4f0)
 [c01b5850] (fb_ioctl+0x0/0x4f0) from [c00c59c8] (vfs_ioctl
 +0x34/0x94)
   r8:c0030004 r7:c7b4e6c0 r6:03d7ca30 r5:4601 r4:c7b4e6c0
 [c00c5994] (vfs_ioctl+0x0/0x94) from [c00c5fc8] (do_vfs_ioctl
 +0x4a4/0x4e4)
   r7:c7b4e6c0 r6:03d7ca30 r5:c7b4e6c0 r4:c70f9290
 [c00c5b24] (do_vfs_ioctl+0x0/0x4e4) from [c00c6048] (sys_ioctl
 +0x40/0x64)
   r9:c671 r8:c0030004 r6:4601 r5:03d7ca30 r4:0006
 [c00c6008] (sys_ioctl+0x0/0x64) from [c002fe80]
 (ret_fast_syscall
 +0x0/0x2c)
   r7:0036 r6:0281 r5:01fc r4:
 omap-dss DISPLAY: omap_dss_mgr_apply(lcd)
 omap-dss DISPC: dispc_setup_plane 0, 8720, sw 480, 0,0, 480x640
 -
 480x640, (ilace 0)
 omap-dss DISPC: dispc_enable_plane 0, 1
 omap-dss DISPC: dispc_enable_plane 1, 0
 omap-dss DISPC: dispc_enable_plane 2, 0
 omap-dss DISPC: GO LCD
 omap-dss DISPLAY: omap_dss_mgr_apply(lcd)
 omap-dss DISPC: dispc_setup_plane 0, 8720, sw 480, 0,0, 480x640
 -
 480x640, (ilace 0)
 omap-dss DISPC

RE: [REVIEW PATCH] Added OMAP3EVM support on Tomis FBDEV/DSS Patches

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Koen Kooi [mailto:[EMAIL PROTECTED]
 Sent: Saturday, November 15, 2008 2:21 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org List
 Subject: Re: [REVIEW PATCH] Added OMAP3EVM support on Tomis
 FBDEV/DSS Patches

 Op 15 nov 2008, om 09:45 heeft Hiremath, Vaibhav het volgende
 geschreven:

  Thanks,
  Vaibhav Hiremath

  -Original Message-
  From: Koen Kooi [mailto:[EMAIL PROTECTED]
  Sent: Saturday, November 15, 2008 1:14 AM
  To: Tomi Valkeinen
  Cc: Hiremath, Vaibhav; [EMAIL PROTECTED];
  linux-omap@vger.kernel.org
  Subject: Re: [REVIEW PATCH] Added OMAP3EVM support on Tomis
  FBDEV/DSS Patches

  Op 14 nov 2008, om 16:53 heeft Tomi Valkeinen het volgende
  geschreven:

  Hi,
  On Fri, 2008-11-14 at 18:05 +0530, ext Hiremath, Vaibhav wrote:

  I think the LCD panel on SDP and EVM boards are the same, so
 we
  should
  only have one driver. Do you have specifications about the
 LCD?
  The
  manufacturer, model etc?. I didn't find any proper information
  about
  the
  LCD.

  [Hiremath, Vaibhav] The LCD on OMAP3EVM is Sharp LCD (Model No.
 -
  LS037V7DW01).
  Koen has already conformed that panel3430sdp.c is working with
  OMAP3EVM, let me try at my end. If it works properly then we
 can
  have same file to build for both SDP and EVM. But in that case
 it
  make sense to rename file to panel-lcd.c.

  I took the liberty to add you EVM changes to my tree, with a
  comment
  about the origin. I also changed the SDP panel name to sharp
  panel,
  and
  made both EVM and SDP use that. But I can't test the EVM, as I
  don't
  have one.

  I finally got rc4 working on evm and with your latest patches I
 get:

  [Hiremath, Vaibhav] What was the issue you figured out?

 I figured out which patch to use to fix MMC on evm.

  udevd version 124 started
  eth0: link down
  eth0: link up, 100Mbps, full-duplex, lpa 0x8DE1
  DSS2 debug: best_ld is 1, best_pd is 3
  DSS2 debug: best_ld is 1, best_pd is 3
  DSS2 debug: best.lck_div is 1, best.pck_div is 3
  omap-dss DISPLAY: omap_dss_mgr_apply(lcd)
  omap-dss DISPC: dispc_setup_plane 0, 8720, sw 480, 0,0,
 480x640
  -
  480x640, (ilace 0)
  omap-dss DISPC: dispc_enable_plane 0, 1
  omap-dss DISPC: dispc_enable_plane 1, 0
  omap-dss DISPC: dispc_enable_plane 2, 0
  omap-dss DISPC: GO LCD
  Division by zero in kernel.
  [Hiremath, Vaibhav] Are you using the patch I submitted or the
  merged code from Tomi?

 I'm using the merged code from Tomi. I extracted the patches from
 his
 git tree:
 http://gitweb.openembedded.net/?p=openembedded.git;a=commit;h=5f7bde
 74179a9eac56e874687f4837d3af759878

[Hiremath, Vaibhav] Let me have a look at his changes then.

 regards,

 Koen

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [REVIEW PATCH] Added OMAP3EVM support on Tomis FBDEV/DSS Patches



Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Koen Kooi [mailto:[EMAIL PROTECTED]
 Sent: Friday, November 14, 2008 2:31 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org List
 Subject: Re: [REVIEW PATCH] Added OMAP3EVM support on Tomis
 FBDEV/DSS Patches
 
 
 Op 14 nov 2008, om 07:32 heeft [EMAIL PROTECTED] het volgende
 geschreven:
 
 
  +++ b/drivers/video/omap2/panel-dvi.c
  @@ -52,54 +52,20 @@ static struct omap_panel dvi_panel = {
  .disable= dvi_panel_disable,
  /*.set_mode = dvi_set_mode, */
 
  -#if defined(CONFIG_PANEL_DVI_LOWRES)
  .timings = {
  -   /* 800 x 600 @ 60 Hz  Reduced blanking VESA CVT 0.48M3-R
 */
  -   .pixel_clock= 35500,
  -   .hfp= 48,
  -   .hsw= 32,
  -   .hbp= 80,
  -   .vfp= 3,
  -   .vsw= 4,
  -   .vbp= 11,
  +   /* 480P */
  +   .pixel_clock= 3,
  +   .hfp= 24,
  +   .hsw= 40,
  +   .hbp= 96,
  +   .vfp= 10,
  +   .vsw= 3,
  +   .vbp= 32,
  },
 
  -   .x_res  = 800,
  -   .y_res  = 600,
  +   .x_res  = 480,
  +   .y_res  = 720,
  .bpp= 24,
  -#elif defined(CONFIG_PANEL_DVI_HIGHRES)
  -   .timings = {
  -   /* 1024 x 768 @ 60 Hz Reduced blanking */
  -   .pixel_clock= 56000,
  -   .hfp= 48,
  -   .hsw= 32,
  -   .hbp= 80,
  -   .vfp= 3,
  -   .vsw= 4,
  -   .vbp= 15,
  -   },
  -
  -   .x_res  = 1024,
  -   .y_res  = 768,
  -   .bpp= 24,
  -#elif defined(CONFIG_PANEL_DVI_VERYHIGHRES)
  -   .timings = {
  -   /* 1280 x 1024 @ 57 Hz Reduced blanking */
  -   .pixel_clock= 86500,
  -   .hfp= 48,
  -   .hsw= 32,
  -   .hbp= 80,
  -   .vfp= 3,
  -   .vsw= 4,
  -   .vbp= 15,
  -   },
  -
  -   .x_res  = 1280,
  -   .y_res  = 1024,
  -   .bpp= 16,
  -#else
  -#error Undefined default mode
  -#endif
 
 Can't the 480p mode the _added_ to the dvi file instead of removing
 all non-480p modes?
 
[Hiremath, Vaibhav] Since LOWERS/HIGHERS/VERYHIGHERS doesn't convey meaningful 
information, I thought of changing this. So started with 480P, after addition 
of more modes say 720P, etc... we will have config option depending on the 
modes.

 regards,
 
 Koen
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [REVIEW PATCH] Added OMAP3EVM support on Tomis FBDEV/DSS Patches



Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Koen Kooi [mailto:[EMAIL PROTECTED]
 Sent: Friday, November 14, 2008 3:26 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org
 Subject: Re: [REVIEW PATCH] Added OMAP3EVM support on Tomis
 FBDEV/DSS Patches
 
 
 Op 14 nov 2008, om 07:32 heeft [EMAIL PROTECTED] het volgende
 geschreven:
 
  From: Vaibhav Hiremath [EMAIL PROTECTED]
 
  diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
  omap2/board-omap3evm.c
 
  +   omap_set_gpio_dataout(LCD_PANEL_ENABLE_GPIO, 1);
 
 omap_set_gpio_dataout changed to gpio_set_value 12 hours ago on l-o
 git
 
[Hiremath, Vaibhav] Thanks for pointing me to this change, I will refresh the 
patch with this and post it again.

 regards,
 
 Koen

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [REVIEW PATCH] Added OMAP3EVM support on Tomis FBDEV/DSS Patches

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Tomi Valkeinen [mailto:[EMAIL PROTECTED]
 Sent: Friday, November 14, 2008 4:24 PM
 To: Hiremath, Vaibhav
 Cc: [EMAIL PROTECTED]; linux-
 [EMAIL PROTECTED]
 Subject: Re: [REVIEW PATCH] Added OMAP3EVM support on Tomis
 FBDEV/DSS Patches

 Hi,

 On Fri, 2008-11-14 at 12:02 +0530, ext [EMAIL PROTECTED] wrote:
  From: Vaibhav Hiremath [EMAIL PROTECTED]

  Tested LCD, TV, DVI (480P) out on OMAP3EVM board.

  Please make sure that you change the option
  CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=7  and apply the
  Mans Rullgard clock patches to support set_rate and round_rate
 API.

  Signed-off-by: Vaibhav Hiremath [EMAIL PROTECTED]

 I think the LCD panel on SDP and EVM boards are the same, so we
 should
 only have one driver. Do you have specifications about the LCD? The
 manufacturer, model etc?. I didn't find any proper information about
 the
 LCD.

[Hiremath, Vaibhav] The LCD on OMAP3EVM is Sharp LCD (Model No. - LS037V7DW01).
Koen has already conformed that panel3430sdp.c is working with OMAP3EVM, let me 
try at my end. If it works properly then we can have same file to build for 
both SDP and EVM. But in that case it make sense to rename file to panel-lcd.c.

 The #ifdef mode selection in DVI panel is quit hack, I agree. The
 mode
 selection should be possible to be done runtime (or with kernel boot
 option at minimum), but I'm not yet sure how to implement it. But I
 guess I could at least name the mode config options a bit better.

[Hiremath, Vaibhav] We will also work on this and let you know.

 You also set the LCD's bpp to 18, why is that? The bpp in panel
 driver
 is currently only used as a default bpp for omapfb, but there's no
 18bpp
 mode in OMAP. For some reason omapfb let's the 18bpp through, but it
 acts like it is 16bpp. I can't remember why it does that, I think
 I'll
 remove it from omapfb.

[Hiremath, Vaibhav] LCD panel connected to OMAP3EVM is 18 bit LCD, the 
interface is also 18 bit in schematics. I am not sure about SDP board though.

  Tomi

  ---
   arch/arm/mach-omap2/board-omap3evm.c |  224
 --
   drivers/video/omap2/Kconfig  |5 +
   drivers/video/omap2/Makefile |1 +
   drivers/video/omap2/panel-dvi.c  |   54 ++---
   drivers/video/omap2/panel-omap3evm.c |  110 +
   5 files changed, 341 insertions(+), 53 deletions(-)
   create mode 100644 drivers/video/omap2/panel-omap3evm.c

  diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
 omap2/board-omap3evm.c
  index 42ab826..e244fa7 100644
  --- a/arch/arm/mach-omap2/board-omap3evm.c
  +++ b/arch/arm/mach-omap2/board-omap3evm.c
  @@ -37,6 +37,8 @@
   #include mach/usb-ehci.h
   #include mach/common.h
   #include mach/mcspi.h
  +#include mach/omapfb.h
  +#include mach/display.h

   #include sdram-micron-mt46h32m32lf-6.h
   #include twl4030-generic-scripts.h
  @@ -161,14 +163,215 @@ static int __init omap3_evm_i2c_init(void)
  omap_register_i2c_bus(3, 400, NULL, 0);
  return 0;
   }
  +static struct omap_fbmem_config evm_fbmem0_config = {
  +   .size = 480*720*4,
  +   .start = OMAPFB_MEMTYPE_SDRAM,
  +};

  -static struct platform_device omap3_evm_lcd_device = {
  -   .name   = omap3evm_lcd,
  -   .id = -1,
  +static struct omap_fbmem_config evm_fbmem1_config = {
  +   .size = 480*720*4,
  +   .start = OMAPFB_MEMTYPE_SDRAM,
   };

  -static struct omap_lcd_config omap3_evm_lcd_config __initdata = {
  -   .ctrl_name  = internal,
  +static struct omap_fbmem_config evm_fbmem2_config = {
  +   .size = 480*720*4,
  +   .start = OMAPFB_MEMTYPE_SDRAM,
  +};
  +#define LCD_PANEL_LR   2
  +#define LCD_PANEL_UD   3
  +#define LCD_PANEL_INI  152
  +#define LCD_PANEL_ENABLE_GPIO  153
  +#define LCD_PANEL_QVGA 154
  +#define LCD_PANEL_RESB 155
  +
  +#define ENABLE_VDAC_DEDICATED  0x03
  +#define ENABLE_VDAC_DEV_GRP0x20
  +#define ENABLE_VPLL2_DEDICATED 0x05
  +#define ENABLE_VPLL2_DEV_GRP   0xE0
  +
  +#define TWL4030_GPIODATA_IN3   0x03
  +#define TWL4030_GPIODATA_DIR3  0x06
  +#define TWL4030_VPLL2_DEV_GRP  0x33
  +#define TWL4030_VPLL2_DEDICATED0x36
  +
  +static int lcd_enabled;
  +static int dvi_enabled;
  +
  +static void __init evm_display_init(void)
  +{
  +   int r;
  +   r = gpio_request(LCD_PANEL_LR, lcd_panel_lr);
  +   if (r) {
  +   printk(KERN_ERR failed to get LCD_PANEL_LR\n);
  +   return;
  +   }
  +   r = gpio_request(LCD_PANEL_UD, lcd_panel_ud);
  +   if (r) {
  +   printk(KERN_ERR failed to get LCD_PANEL_UD\n);
  +   goto err_1;
  +   }
  +
  +   r = gpio_request(LCD_PANEL_INI, lcd_panel_ini);
  +   if (r) {
  +   printk(KERN_ERR failed to get LCD_PANEL_INI\n);
  +   goto err_2;
  +   }
  +   r = gpio_request(LCD_PANEL_RESB, lcd_panel_resb

RE: [REVIEW PATCH] Added OMAP3EVM support on Tomis FBDEV/DSS Patches