Re: [PATCH 1/1 linux-next] omap_vout: use swap() in omapvid_init()

2015-05-18 Thread Vaibhav Hiremath 



On Tuesday 19 May 2015 12:01 AM, Fabian Frederick wrote:




On 18 May 2015 at 20:20 Vaibhav Hiremath  wrote:




On Monday 18 May 2015 11:24 PM, Fabian Frederick wrote:

Use kernel.h macro definition.

Signed-off-by: Fabian Frederick 
---
drivers/media/platform/omap/omap_vout.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/omap/omap_vout.c
b/drivers/media/platform/omap/omap_vout.c
index 17b189a..f09c5f1 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -445,7 +445,7 @@ static int omapvid_init(struct omap_vout_device *vout,
u32 addr)
  int ret = 0, i;
  struct v4l2_window *win;
  struct omap_overlay *ovl;
-   int posx, posy, outw, outh, temp;
+   int posx, posy, outw, outh;
  struct omap_video_timings *timing;
  struct omapvideo_info *ovid = &vout->vid_info;

@@ -468,9 +468,7 @@ static int omapvid_init(struct omap_vout_device *vout,
u32 addr)
  /* Invert the height and width for 90
   * and 270 degree rotation
   */
-   temp = outw;
-   outw = outh;
-   outh = temp;
+   swap(outw, outh);
  posy = (timing->y_res - win->w.width) - win->w.left;
  posx = win->w.top;
  break;
@@ -481,9 +479,7 @@ static int omapvid_init(struct omap_vout_device *vout,
u32 addr)
  break;

  case dss_rotation_270_degree:
-   temp = outw;
-   outw = outh;
-   outh = temp;
+   swap(outw, outh);
  posy = win->w.left;
  posx = (timing->x_res - win->w.height) - win->w.top;
  break;




Curious to know,
How do you test this? Do you have any OMAP2/3 or AM335x board?
Does this driver still works?


Hello Vaibhav,

Unfortunately I can't test it.



Thats what I expected.

I am doubtful that anyone still uses this driver.
With DRM framework support, I see very little use of this driver.

Also there are some hacks regarding buffer management, that need to be
fixed if at all we want to support it.

I would really want to slowly kill this driver, if no one uses it.

Thanks,
Vaibhav
--
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

Re: [PATCH 1/1 linux-next] omap_vout: use swap() in omapvid_init()

2015-05-18 Thread Vaibhav Hiremath 



On Monday 18 May 2015 11:24 PM, Fabian Frederick wrote:

Use kernel.h macro definition.

Signed-off-by: Fabian Frederick 
---
  drivers/media/platform/omap/omap_vout.c | 10 +++---
  1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/omap/omap_vout.c 
b/drivers/media/platform/omap/omap_vout.c
index 17b189a..f09c5f1 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -445,7 +445,7 @@ static int omapvid_init(struct omap_vout_device *vout, u32 
addr)
int ret = 0, i;
struct v4l2_window *win;
struct omap_overlay *ovl;
-   int posx, posy, outw, outh, temp;
+   int posx, posy, outw, outh;
struct omap_video_timings *timing;
struct omapvideo_info *ovid = &vout->vid_info;

@@ -468,9 +468,7 @@ static int omapvid_init(struct omap_vout_device *vout, u32 
addr)
/* Invert the height and width for 90
 * and 270 degree rotation
 */
-   temp = outw;
-   outw = outh;
-   outh = temp;
+   swap(outw, outh);
posy = (timing->y_res - win->w.width) - win->w.left;
posx = win->w.top;
break;
@@ -481,9 +479,7 @@ static int omapvid_init(struct omap_vout_device *vout, u32 
addr)
break;

case dss_rotation_270_degree:
-   temp = outw;
-   outw = outh;
-   outh = temp;
+   swap(outw, outh);
posy = win->w.left;
posx = (timing->x_res - win->w.height) - win->w.top;
break;




Curious to know,
How do you test this? Do you have any OMAP2/3 or AM335x board?
Does this driver still works?

Thanks,
Vaibhav
--
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

Re: soc-camera: opinion poll - future directions

2015-05-04 Thread Vaibhav Hiremath 



On Monday 04 May 2015 12:49 PM, Hans Verkuil wrote:

On 05/03/2015 07:45 PM, Guennadi Liakhovetski wrote:

Hi Hans,

On Sun, 3 May 2015, Hans Verkuil wrote:


Hi Guennadi,

On 05/03/2015 06:11 PM, Guennadi Liakhovetski wrote:

Hi all,

Just a quick opinion poll - where and how should the soc-camera framework
and drivers be heading? Possible (probably not all) directions:

(1) all is good, keep as is. That means keep all drivers, killing them off
only when it becomes very obvious, that noone wants them, keep developing
drivers, that are still being used and updating all of them on any API
updates. Keep me as maintainer, which means slow patch processing rate and
no active participation in new developments - at hardware, soc-camera or
V4L levels.

(2) we want more! I.e. some contributors are planning to either add new
drivers to it or significantly develop existing ones, see significant
benefit in it. In this case it might become necessary to replace me with
someone, who can be more active in this area.

(3) slowly phase out. Try to either deprecate and remove soc-camera
drivers one by one or move them out to become independent V4L2 host or
subdevice drivers, but keep updating while still there.

(4) basically as (3) but even more aggressively - get rid of it ASAP:)

Opinions? Expecially would be interesting to hear from respective
host-driver maintainers / developers, sorry, not adding CCs, they probably
read the list anyway:)


I'm closest to 1. I would certainly not use it for new drivers, I see no
reason to do that anymore. The core frameworks are quite good these days
and I think the need for soc-camera has basically disappeared. But there
is no need to phase out or remove soc-camera drivers (unless they are
clearly broken and nobody will fix them). And if someone wants to turn
a soc-camera driver into a standalone driver, then I would encourage
that.


Understand, thanks.


However, there are two things that need work fairly soon:

1) the dependency of subdev drivers on soc_camera: that has to go. I plan
to work on that, but the first step is to replace the video crop ops by
the pad selection ops. I finally got my Renesas sh7724 board up and running,


Uhm... Does anyone really still care about V4L on SuperH?..


I am :-)

It's the only soc-camera board I have, so it's good to have it working.




so I hope to make progress on this soon. I'll update soc-camera as well
to conform to v4l2-compliance. Once that's done I will investigate how to
remove the soc-camera dependency.

The soc-camera dependency kills the reusability of those drivers and it
really needs to be addressed.

2) Converting soc-camera videobuf drivers to vb2. At some point vb1 will be
removed, so any remaining vb1 driver will likely be killed off if nobody does
the conversion. I believe it is only omap1 and pxa that still use videobuf.

I think omap1 might be a candidate for removal, but I don't know about the pxa.
Guennadi, what is the status of these drivers?


Dont know, sorry. PXA in general seems to still be quite actively
maintained - I recently saw a patch series for PXA CCF support, so,
probably V4L is still in use too.


If I would do a vb2 conversion
for the pxa, would you be able to test it?


I have a board with PXA270, and it still seems to be in the mainline, but
I don't know how easy it would be to get it running with a current kernel.


Can you take a look? If you can get it running, then I can make a patch for
you to try. But I don't want to put time into that unless I know you can
test it.

I think it is reasonable to phase out the omap1 driver: move it to staging
first and if nobody complains remove it altogether.



Hans,

I think OMAP2_VOUT is also another candidate which we need to probably
move it to staging and then remove it.
I am not sure if anyone is still using it.

It is just compiling as of now, but I am doubtful that it will work.


Thanks,
Vaibhav
--
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

[PATCH] omap_vout: Fix the build warning and section miss-match warning

2012-03-09 Thread Vaibhav Hiremath 
Patch fixes below build warning and section miss-match warning 
from omap_vout driver -

Build warnings:
=
drivers/media/video/omap/omap_vout.c: In function 'omapvid_setup_overlay':
drivers/media/video/omap/omap_vout.c:381:17: warning: 'mode' may be used
uninitialized in this function

Section Mis-Match warnings:
==
WARNING: drivers/media/video/omap/omap-vout.o(.data+0x0): Section mismatch in
reference from the variable
omap_vout_driver to the function .init.text:omap_vout_probe()
The variable omap_vout_driver references
the function __init omap_vout_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

Signed-off-by: Vaibhav Hiremath 
---
 drivers/media/video/omap/omap_vout.c |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/media/video/omap/omap_vout.c 
b/drivers/media/video/omap/omap_vout.c
index dffcf66..0fb0437 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -328,7 +328,7 @@ static int video_mode_to_dss_mode(struct omap_vout_device 
*vout)
struct omap_overlay *ovl;
struct omapvideo_info *ovid;
struct v4l2_pix_format *pix = &vout->pix;
-   enum omap_color_mode mode;
+   enum omap_color_mode mode = -EINVAL;

ovid = &vout->vid_info;
ovl = ovid->overlays[0];
@@ -2108,7 +2108,7 @@ static void omap_vout_cleanup_device(struct 
omap_vout_device *vout)
kfree(vout);
 }

-static int omap_vout_remove(struct platform_device *pdev)
+static int __devexit omap_vout_remove(struct platform_device *pdev)
 {
int k;
struct v4l2_device *v4l2_dev = platform_get_drvdata(pdev);
@@ -2129,7 +2129,7 @@ static int omap_vout_remove(struct platform_device *pdev)
return 0;
 }

-static int __init omap_vout_probe(struct platform_device *pdev)
+static int __devinit omap_vout_probe(struct platform_device *pdev)
 {
int ret = 0, i;
struct omap_overlay *ovl;
@@ -2241,9 +2241,10 @@ probe_err0:
 static struct platform_driver omap_vout_driver = {
.driver = {
.name = VOUT_NAME,
+   .owner = THIS_MODULE,
},
.probe = omap_vout_probe,
-   .remove = omap_vout_remove,
+   .remove = __devexit_p(omap_vout_remove),
 };

 static int __init omap_vout_init(void)
--
1.7.0.4

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

[PATCH] omap_vout: Fix "DMA transaction error" issue when rotation is enabled

2012-03-09 Thread Vaibhav Hiremath 
When rotation is enabled and driver is configured in USERPTR
buffer exchange mechanism, in specific use-case driver reports
an error,
   "DMA transaction error with device 0".

In driver _buffer_prepare funtion, we were using
"vout->buf_phy_addr[vb->i]" for buffer physical address to
configure SDMA channel, but this variable does get updated
only during init.
And the issue will occur when driver allocates less number
of buffers during init and application requests more buffers
through REQBUF ioctl; this variable will lead to invalid
configuration of SDMA channel leading to DMA transaction error.

Signed-off-by: Vaibhav Hiremath 
---
Archit/Laurent,
Can you help me to validate this patch on your platform/usecase?

 drivers/media/video/omap/omap_vout_vrfb.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/omap/omap_vout_vrfb.c 
b/drivers/media/video/omap/omap_vout_vrfb.c
index 4be26ab..240d36d 100644
--- a/drivers/media/video/omap/omap_vout_vrfb.c
+++ b/drivers/media/video/omap/omap_vout_vrfb.c
@@ -225,7 +225,7 @@ int omap_vout_prepare_vrfb(struct omap_vout_device *vout,
if (!is_rotation_enabled(vout))
return 0;

-   dmabuf = vout->buf_phy_addr[vb->i];
+   dmabuf = (dma_addr_t) vout->queued_buf_addr[vb->i];
/* If rotation is enabled, copy input buffer into VRFB
 * memory space using DMA. We are copying input buffer
 * into VRFB memory space of desired angle and DSS will
--
1.7.0.4

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