Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-12-18 Thread Sakari Ailus
Hi Pavel,

On Tue, Dec 13, 2016 at 10:05:06PM +0100, Pavel Machek wrote:
> Hi!
> 
> I have finally found the old mail you were refering to. Let me go
> through it.
> 
> > > +/*
> > > + * Convert exposure time `us' to rows. Modify `us' to make it to
> > > + * correspond to the actual exposure time.
> > > + */
> > > +static int et8ek8_exposure_us_to_rows(struct et8ek8_sensor *sensor, u32 
> > > *us)
> > 
> > Should a driver do something like this to begin with?
> > 
> > The smiapp driver does use the native unit of exposure (lines) for the
> > control and I think the et8ek8 driver should do so as well.
> > 
> > The HBLANK, VBLANK and PIXEL_RATE controls are used to provide the user with
> > enough information to perform the conversion (if necessary).
> 
> Well... I believe exposure in usec is preffered format for userspace
> to work with (because then it can change resolution and keep camera
> settings) but I see kernel code is quite ugly. Let me see what I can do...

That's not so important IMO --- the granularity may matter and there's no
way you can properly communicate that to the user if you use a non-native
unit.

My preference is the native unit, but considering that you've got an
existing user space application and perhaps even more importantly, it's very
unlikely the device would be used elsewhere.

The smiapp driver uses lines. Up to you.

> 
> > > + if (ret) {
> > > + dev_warn(dev, "can't get clock-frequency\n");
> > > + return ret;
> > > + }
> > > +
> > > + mutex_init(&sensor->power_lock);
> > 
> > mutex_destroy() should be called on the mutex if probe fails after this and
> > in remove().
> 
> Ok.
> 
> > > +static int __exit et8ek8_remove(struct i2c_client *client)
> > > +{
> > > + struct v4l2_subdev *subdev = i2c_get_clientdata(client);
> > > + struct et8ek8_sensor *sensor = to_et8ek8_sensor(subdev);
> > > +
> > > + if (sensor->power_count) {
> > > + gpiod_set_value(sensor->reset, 0);
> > > + clk_disable_unprepare(sensor->ext_clk);
> > 
> > How about the regulator? Could you call et8ek8_power_off() instead?
> 
> Hmm. Actually if we hit this, it indicates something funny is going
> on, no? I guess I'll add WARN_ON there...

Yes. A WARN_ON() would be good.

> 
> > > +++ b/drivers/media/i2c/et8ek8/et8ek8_reg.h
> > > @@ -0,0 +1,96 @@
> > > +/*
> > > + * et8ek8.h
> > 
> > et8ek8_reg.h
> 
> Ok.
> 
> Thanks for patience,

Same to you! :-)

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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 v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-12-13 Thread Pavel Machek
Hi!

I have finally found the old mail you were refering to. Let me go
through it.

> > +/*
> > + * Convert exposure time `us' to rows. Modify `us' to make it to
> > + * correspond to the actual exposure time.
> > + */
> > +static int et8ek8_exposure_us_to_rows(struct et8ek8_sensor *sensor, u32 
> > *us)
> 
> Should a driver do something like this to begin with?
> 
> The smiapp driver does use the native unit of exposure (lines) for the
> control and I think the et8ek8 driver should do so as well.
> 
> The HBLANK, VBLANK and PIXEL_RATE controls are used to provide the user with
> enough information to perform the conversion (if necessary).

Well... I believe exposure in usec is preffered format for userspace
to work with (because then it can change resolution and keep camera
settings) but I see kernel code is quite ugly. Let me see what I can do...

> > +   if (ret) {
> > +   dev_warn(dev, "can't get clock-frequency\n");
> > +   return ret;
> > +   }
> > +
> > +   mutex_init(&sensor->power_lock);
> 
> mutex_destroy() should be called on the mutex if probe fails after this and
> in remove().

Ok.

> > +static int __exit et8ek8_remove(struct i2c_client *client)
> > +{
> > +   struct v4l2_subdev *subdev = i2c_get_clientdata(client);
> > +   struct et8ek8_sensor *sensor = to_et8ek8_sensor(subdev);
> > +
> > +   if (sensor->power_count) {
> > +   gpiod_set_value(sensor->reset, 0);
> > +   clk_disable_unprepare(sensor->ext_clk);
> 
> How about the regulator? Could you call et8ek8_power_off() instead?

Hmm. Actually if we hit this, it indicates something funny is going
on, no? I guess I'll add WARN_ON there...

> > +++ b/drivers/media/i2c/et8ek8/et8ek8_reg.h
> > @@ -0,0 +1,96 @@
> > +/*
> > + * et8ek8.h
> 
> et8ek8_reg.h

Ok.

Thanks for patience,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-20 Thread Pavel Machek
Hi!

> > +   /* V4L2_CID_EXPOSURE */
> > +   min = et8ek8_exposure_rows_to_us(sensor, 1);
> > +   max = et8ek8_exposure_rows_to_us(sensor,
> > +   sensor->current_reglist->mode.max_exp);
> 
> Haven't I suggested to use lines instead? I vaguely remember doing so...
> this would remove quite some code from the driver.

Lines ... lines ... no, I don't think I understand how to use lines
here. I guess I could switch units from us to rows here...?

Is it good idea? For userspace, microseconds are really a nice
interface, because ... well, that's what photographers are used to
think about (ISO 400, time 1/100). fcam also uses usec internally.

In the current camera code, I do autogain in small resolution, then
use same parameters (gain, time) at higher resolution. I guess I could
do the same with the non-microseconds interface, but then I'd have to
move the microsecond computation into userspace. And userspace is
not really good place to do that, as it does not know (and should not
have to know!) such low level details.

So... can we keep the interface as it is?

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-20 Thread Pavel Machek
Hi!

> > +static void et8ek8_reglist_to_mbus(const struct et8ek8_reglist *reglist,
> > +  struct v4l2_mbus_framefmt *fmt)
> > +{
> > +   fmt->width = reglist->mode.window_width;
> > +   fmt->height = reglist->mode.window_height;
> > +
> > +   if (reglist->mode.pixel_format == V4L2_PIX_FMT_SGRBG10DPCM8)
> 
> The driver doesn't really need to deal with pixel formats. Could you use
> media bus formats instead, and rename the fields accordingly?
> 
> The reason why it did use pixel formats was that (V4L2) media bus formats
> did not exist when the driver was written. :-)

Makes sense...

Something like this? [untested, will test complete changes.]

Pavel

diff --git a/drivers/media/i2c/et8ek8/et8ek8_driver.c 
b/drivers/media/i2c/et8ek8/et8ek8_driver.c
index 0301e81..eb131b2 100644
--- a/drivers/media/i2c/et8ek8/et8ek8_driver.c
+++ b/drivers/media/i2c/et8ek8/et8ek8_driver.c
@@ -395,11 +395,7 @@ static void et8ek8_reglist_to_mbus(const struct 
et8ek8_reglist *reglist,
 {
fmt->width = reglist->mode.window_width;
fmt->height = reglist->mode.window_height;
-
-   if (reglist->mode.pixel_format == V4L2_PIX_FMT_SGRBG10DPCM8)
-   fmt->code = MEDIA_BUS_FMT_SGRBG10_DPCM8_1X8;
-   else
-   fmt->code = MEDIA_BUS_FMT_SGRBG10_1X10;
+   fmt->code = reglist->mode.bus_format;
 }
 
 static struct et8ek8_reglist *et8ek8_reglist_find_mode_fmt(
@@ -538,7 +534,7 @@ static int et8ek8_reglist_import(struct i2c_client *client,
   __func__,
   list->type,
   list->mode.window_width, list->mode.window_height,
-  list->mode.pixel_format,
+  list->mode.bus_format,
   list->mode.timeperframe.numerator,
   list->mode.timeperframe.denominator,
   (void *)meta->reglist[nlists].ptr);
@@ -967,21 +963,18 @@ static int et8ek8_enum_mbus_code(struct v4l2_subdev 
*subdev,
continue;
 
for (i = 0; i < npixelformat; i++) {
-   if (pixelformat[i] == mode->pixel_format)
+   if (pixelformat[i] == mode->bus_format)
break;
}
if (i != npixelformat)
continue;
 
if (code->index == npixelformat) {
-   if (mode->pixel_format == V4L2_PIX_FMT_SGRBG10DPCM8)
-   code->code = MEDIA_BUS_FMT_SGRBG10_DPCM8_1X8;
-   else
-   code->code = MEDIA_BUS_FMT_SGRBG10_1X10;
+   code->code = mode->bus_format;
return 0;
}
 
-   pixelformat[npixelformat] = mode->pixel_format;
+   pixelformat[npixelformat] = mode->bus_format;
npixelformat++;
}
 
diff --git a/drivers/media/i2c/et8ek8/et8ek8_mode.c 
b/drivers/media/i2c/et8ek8/et8ek8_mode.c
index 956fc60..12998d8 100644
--- a/drivers/media/i2c/et8ek8/et8ek8_mode.c
+++ b/drivers/media/i2c/et8ek8/et8ek8_mode.c
@@ -59,7 +59,7 @@ static struct et8ek8_reglist 
mode1_poweron_mode2_16vga_2592x1968_12_07fps = {
},
.max_exp = 2012,
/* .max_gain = 0, */
-   .pixel_format = V4L2_PIX_FMT_SGRBG10,
+   .bus_format = MEDIA_BUS_FMT_SGRBG10_1X10,
.sensitivity = 65536
},
.regs = {
@@ -160,7 +160,7 @@ static struct et8ek8_reglist 
mode1_16vga_2592x1968_13_12fps_dpcm10_8 = {
},
.max_exp = 2012,
/* .max_gain = 0, */
-   .pixel_format = V4L2_PIX_FMT_SGRBG10DPCM8,
+   .bus_format = MEDIA_BUS_FMT_SGRBG10_DPCM8_1X8,
.sensitivity = 65536
},
.regs = {
@@ -216,7 +216,7 @@ static struct et8ek8_reglist 
mode3_4vga_1296x984_29_99fps_dpcm10_8 = {
},
.max_exp = 1004,
/* .max_gain = 0, */
-   .pixel_format = V4L2_PIX_FMT_SGRBG10DPCM8,
+   .bus_format = MEDIA_BUS_FMT_SGRBG10_DPCM8_1X8,
.sensitivity = 65536
},
.regs = {
@@ -272,7 +272,7 @@ static struct et8ek8_reglist mode4_svga_864x656_29_88fps = {
},
.max_exp = 668,
/* .max_gain = 0, */
-   .pixel_format = V4L2_PIX_FMT_SGRBG10,
+   .bus_format = MEDIA_BUS_FMT_SGRBG10_1X10,
.sensitivity = 65536
},
.regs = {
@@ -328,7 +328,7 @@ static struct et8ek8_reglist mode5_vga_648x492_29_93fps = {
},
.max_exp = 500,
/* .max_gain = 0, */
-   .pixel_format = V4L2_PIX_FMT_SGRBG10,
+   .bus_format = MEDIA_BUS_FMT_SGRBG10_1X10,
.sensitivity = 65536
}

Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-20 Thread Pavel Machek
Hi!

> > +   u32 min, max;
> > +
> > +   v4l2_ctrl_handler_init(&sensor->ctrl_handler, 4);
> > +
> > +   /* V4L2_CID_GAIN */
> > +   v4l2_ctrl_new_std(&sensor->ctrl_handler, &et8ek8_ctrl_ops,
> > + V4L2_CID_GAIN, 0, ARRAY_SIZE(et8ek8_gain_table) - 1,
> > + 1, 0);
> > +
> > +   /* V4L2_CID_EXPOSURE */
> > +   min = et8ek8_exposure_rows_to_us(sensor, 1);
> > +   max = et8ek8_exposure_rows_to_us(sensor,
> > +   sensor->current_reglist->mode.max_exp);
> 
> Haven't I suggested to use lines instead? I vaguely remember doing so...
> this would remove quite some code from the driver.

Do you have some more hints? I'll try to figure it out...

> > +#ifdef CONFIG_PM
> > +
> > +static int et8ek8_suspend(struct device *dev)
> 
> static int __maybe_unused ...
> 
> Please check the smiapp patches I just sent to the list. The smiapp driver
> had similar issues.

Ok, I guess I figured it out from other code (no network at the
moment).

> > +   if (sensor->power_count) {
> > +   gpiod_set_value(sensor->reset, 0);
> > +   clk_disable_unprepare(sensor->ext_clk);
> > +   sensor->power_count = 0;
> > +   }
> > +
> 
> You're missing v4l2_async_unregister_subdev() here.

Added.

> > +   v4l2_device_unregister_subdev(&sensor->subdev);
> > +   device_remove_file(&client->dev, &dev_attr_priv_mem);
> > +   v4l2_ctrl_handler_free(&sensor->ctrl_handler);
> > +   media_entity_cleanup(&sensor->subdev.entity);
> > +
> > +   return 0;
> > +}

> > +MODULE_DEVICE_TABLE(i2c, et8ek8_id_table);
> > +
> > +static const struct dev_pm_ops et8ek8_pm_ops = {
> > +   .suspend= et8ek8_suspend,
> > +   .resume = et8ek8_resume,
> 
> How about using  SET_SYSTEM_SLEEP_PM_OPS() here?

Ok, I guess that saves few lines.

> > +module_i2c_driver(et8ek8_i2c_driver);
> > +
> > +MODULE_AUTHOR("Sakari Ailus ");
> 
> You should put your name here as well. :-)
> 
> It's been a long time I even tried to use it. :-i

Me? Ok, I can list myself there, but I don't really know much about
that driver.

> > + * Contact: Sakari Ailus 
> > + *  Tuukka Toivonen 
> 
> Tuukka's e-mail is wrong here (the correct address is elsewhere in the
> patch).

Fixed.

Ok, these cleanups are here.

Pavel

diff --git a/drivers/media/i2c/et8ek8/et8ek8_driver.c 
b/drivers/media/i2c/et8ek8/et8ek8_driver.c
index eb131b2..eb8c1b4 100644
--- a/drivers/media/i2c/et8ek8/et8ek8_driver.c
+++ b/drivers/media/i2c/et8ek8/et8ek8_driver.c
@@ -5,6 +5,7 @@
  *
  * Contact: Sakari Ailus 
  *  Tuukka Toivonen 
+ *  Pavel Machek 
  *
  * Based on code from Toni Leinonen .
  *
@@ -1435,9 +1436,7 @@ static const struct v4l2_subdev_internal_ops 
et8ek8_internal_ops = {
 /* --
  * I2C driver
  */
-#ifdef CONFIG_PM
-
-static int et8ek8_suspend(struct device *dev)
+static int __maybe_unused et8ek8_suspend(struct device *dev)
 {
struct i2c_client *client = to_i2c_client(dev);
struct v4l2_subdev *subdev = i2c_get_clientdata(client);
@@ -1449,7 +1448,7 @@ static int et8ek8_suspend(struct device *dev)
return __et8ek8_set_power(sensor, false);
 }
 
-static int et8ek8_resume(struct device *dev)
+static int __maybe_unused et8ek8_resume(struct device *dev)
 {
struct i2c_client *client = to_i2c_client(dev);
struct v4l2_subdev *subdev = i2c_get_clientdata(client);
@@ -1461,13 +1460,6 @@ static int et8ek8_resume(struct device *dev)
return __et8ek8_set_power(sensor, true);
 }
 
-#else
-
-#define et8ek8_suspend NULL
-#define et8ek8_resume NULL
-
-#endif /* CONFIG_PM */
-
 static int et8ek8_probe(struct i2c_client *client,
const struct i2c_device_id *devid)
 {
@@ -1542,6 +1534,7 @@ static int __exit et8ek8_remove(struct i2c_client *client)
v4l2_device_unregister_subdev(&sensor->subdev);
device_remove_file(&client->dev, &dev_attr_priv_mem);
v4l2_ctrl_handler_free(&sensor->ctrl_handler);
+   v4l2_async_unregister_subdev(&sensor->subdev);
media_entity_cleanup(&sensor->subdev.entity);
 
return 0;
@@ -1559,8 +1552,7 @@ static const struct i2c_device_id et8ek8_id_table[] = {
 MODULE_DEVICE_TABLE(i2c, et8ek8_id_table);
 
 static const struct dev_pm_ops et8ek8_pm_ops = {
-   .suspend= et8ek8_suspend,
-   .resume = et8ek8_resume,
+   SET_SYSTEM_SLEEP_PM_OPS(et8ek8_suspend, et8ek8_resume)
 };
 
 static struct i2c_driver et8ek8_i2c_driver = {
@@ -1576,6 +1568,6 @@ static struct i2c_driver et8ek8_i2c_driver = {
 
 module_i2c_driver(et8ek8_i2c_driver);
 
-MODULE_AUTHOR("Sakari Ailus ");
+MODULE_AUTHOR("Sakari Ailus , Pavel Machek 
http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-20 Thread Pavel Machek
Hi!

> Just a few more comments...
> 
> Please check my other review as well. I believe you may have missed the
> comments in between in that one.

Sorry for that. Would you have a link for that email or a copy? (I
can't seem to find it.)

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-19 Thread Sakari Ailus
Hi Pavel,

Just a few more comments...

Please check my other review as well. I believe you may have missed the
comments in between in that one.

On Sun, Oct 23, 2016 at 10:03:55PM +0200, Pavel Machek wrote:
> 
> Add driver for et8ek8 sensor, found in Nokia N900 main camera. Can be
> used for taking photos in 2.5MP resolution with fcam-dev.
> 
> Signed-off-by: Ivaylo Dimitrov 
> Signed-off-by: Pavel Machek 
> 
> ---
> From v4 I did cleanups to coding style and removed various oddities.
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 2669b4b..6d01e15 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -667,6 +667,7 @@ config VIDEO_S5K5BAF
> camera sensor with an embedded SoC image signal processor.
>  
>  source "drivers/media/i2c/smiapp/Kconfig"
> +source "drivers/media/i2c/et8ek8/Kconfig"
>  
>  config VIDEO_S5C73M3
>   tristate "Samsung S5C73M3 sensor support"
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 92773b2..5bc7bbe 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -2,6 +2,7 @@ msp3400-objs  :=  msp3400-driver.o msp3400-kthreads.o
>  obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o
>  
>  obj-$(CONFIG_VIDEO_SMIAPP)   += smiapp/
> +obj-$(CONFIG_VIDEO_ET8EK8)   += et8ek8/
>  obj-$(CONFIG_VIDEO_CX25840) += cx25840/
>  obj-$(CONFIG_VIDEO_M5MOLS)   += m5mols/
>  obj-y+= soc_camera/
> diff --git a/drivers/media/i2c/et8ek8/Kconfig 
> b/drivers/media/i2c/et8ek8/Kconfig
> new file mode 100644
> index 000..1439936
> --- /dev/null
> +++ b/drivers/media/i2c/et8ek8/Kconfig
> @@ -0,0 +1,6 @@
> +config VIDEO_ET8EK8
> + tristate "ET8EK8 camera sensor support"
> + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> + ---help---
> +   This is a driver for the Toshiba ET8EK8 5 MP camera sensor.
> +   It is used for example in Nokia N900 (RX-51).
> diff --git a/drivers/media/i2c/et8ek8/Makefile 
> b/drivers/media/i2c/et8ek8/Makefile
> new file mode 100644
> index 000..66d1b7d
> --- /dev/null
> +++ b/drivers/media/i2c/et8ek8/Makefile
> @@ -0,0 +1,2 @@
> +et8ek8-objs  += et8ek8_mode.o et8ek8_driver.o
> +obj-$(CONFIG_VIDEO_ET8EK8)   += et8ek8.o
> diff --git a/drivers/media/i2c/et8ek8/et8ek8_driver.c 
> b/drivers/media/i2c/et8ek8/et8ek8_driver.c
> new file mode 100644
> index 000..0301e81
> --- /dev/null
> +++ b/drivers/media/i2c/et8ek8/et8ek8_driver.c
> @@ -0,0 +1,1588 @@
> +/*
> + * et8ek8_driver.c
> + *
> + * Copyright (C) 2008 Nokia Corporation
> + *
> + * Contact: Sakari Ailus 
> + *  Tuukka Toivonen 
> + *
> + * Based on code from Toni Leinonen .
> + *
> + * This driver is based on the Micron MT9T012 camera imager driver
> + * (C) Texas Instruments.
> + *
> + * This program 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "et8ek8_reg.h"
> +
> +#define ET8EK8_NAME  "et8ek8"
> +#define ET8EK8_PRIV_MEM_SIZE 128
> +#define ET8EK8_MAX_MSG   48
> +
> +struct et8ek8_sensor {
> + struct v4l2_subdev subdev;
> + struct media_pad pad;
> + struct v4l2_mbus_framefmt format;
> + struct gpio_desc *reset;
> + struct regulator *vana;
> + struct clk *ext_clk;
> + u32 xclk_freq;
> +
> + u16 version;
> +
> + struct v4l2_ctrl_handler ctrl_handler;
> + struct v4l2_ctrl *exposure;
> + struct v4l2_ctrl *pixel_rate;
> + struct et8ek8_reglist *current_reglist;
> +
> + u8 priv_mem[ET8EK8_PRIV_MEM_SIZE];
> +
> + struct mutex power_lock;
> + int power_count;
> +};
> +
> +#define to_et8ek8_sensor(sd) container_of(sd, struct et8ek8_sensor, subdev)
> +
> +enum et8ek8_versions {
> + ET8EK8_REV_1 = 0x0001,
> + ET8EK8_REV_2,
> +};
> +
> +/*
> + * This table describes what should be written to the sensor register
> + * for each gain value. The gain(index in the table) is in terms of
> + * 0.1EV, i.e. 10 indexes in the table give 2 time more gain [0] in
> + * the *analog gain, [1] in the digital gain
> + *
> + * Analog gain [dB] = 20*log10(regvalue/32); 0x20..0x100
> + */
> +static struct et8ek8_gain {
> + u16 analog;
> + u16 digital;
> +} const et8ek8_gain_table[] = {
> + { 32,0},  /* x1 */
> + { 34,0},
> + { 37,0},
> + { 39,0},
> + { 42,0},
> + { 45,0},
> + { 49,0},
> + 

Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-15 Thread Sakari Ailus
Hi Pavel,

On Tue, Nov 15, 2016 at 11:54:25AM +0100, Pavel Machek wrote:
> Hi!
> 
> > On Tue, Nov 01, 2016 at 12:54:08AM +0200, Sakari Ailus wrote:
> > > > > Thanks, this answered half of my questions already. ;-)
> > > > :-).
> > > > 
> > > > I'll have to go through the patches, et8ek8 driver is probably not
> > > > enough to get useful video. platform/video-bus-switch.c is needed for
> > > > camera switching, then some omap3isp patches to bind flash and
> > > > autofocus into the subdevice.
> > > > 
> > > > Then, device tree support on n900 can be added.
> > > 
> > > I briefly discussed with with Sebastian.
> > > 
> > > Do you think the elusive support for the secondary camera is worth keeping
> > > out the main camera from the DT in mainline? As long as there's a 
> > > reasonable
> > > way to get it working, I'd just merge that. If someone ever gets the
> > > secondary camera working properly and nicely with the video bus switch,
> > > that's cool, we'll somehow deal with the problem then. But frankly I don't
> > > think it's very useful even if we get there: the quality is really bad.
> > 
> > If we want to keep open the option to add proper support for the
> > second camera, we could also add the bus switch and not add the
> > front camera node in DT. Then adding the front camera does not
> 
> Now that we have ack on the device tree parts, could you merge the
> et8ek8 driver (or provide review comments?)?
> 
> Yes, there are more parts missing for useful camera support on n900,
> but the chip driver is neccessary part and it should be ready.

Sure, I was somehow expecting we could perhaps merge the rest of the
necessary patches sooner than it now appears.

Let me check the latest et8ek8 patch.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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 v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-15 Thread Pavel Machek
Hi!

> On Tue, Nov 01, 2016 at 12:54:08AM +0200, Sakari Ailus wrote:
> > > > Thanks, this answered half of my questions already. ;-)
> > > :-).
> > > 
> > > I'll have to go through the patches, et8ek8 driver is probably not
> > > enough to get useful video. platform/video-bus-switch.c is needed for
> > > camera switching, then some omap3isp patches to bind flash and
> > > autofocus into the subdevice.
> > > 
> > > Then, device tree support on n900 can be added.
> > 
> > I briefly discussed with with Sebastian.
> > 
> > Do you think the elusive support for the secondary camera is worth keeping
> > out the main camera from the DT in mainline? As long as there's a reasonable
> > way to get it working, I'd just merge that. If someone ever gets the
> > secondary camera working properly and nicely with the video bus switch,
> > that's cool, we'll somehow deal with the problem then. But frankly I don't
> > think it's very useful even if we get there: the quality is really bad.
> 
> If we want to keep open the option to add proper support for the
> second camera, we could also add the bus switch and not add the
> front camera node in DT. Then adding the front camera does not

Now that we have ack on the device tree parts, could you merge the
et8ek8 driver (or provide review comments?)?

Yes, there are more parts missing for useful camera support on n900,
but the chip driver is neccessary part and it should be ready.

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-14 Thread Sebastian Reichel
Hi Sakari,

On Mon, Nov 14, 2016 at 11:58:28PM +0200, Sakari Ailus wrote:
> [...]
>
> On Fri, Nov 04, 2016 at 01:05:25AM +0100, Sebastian Reichel wrote:
> > I'm not sure what part relevant for video-bus-switch is currently
> > not supported?
> > 
> > video-bus-switch registers its own async notifier and only registers
> > itself as subdevices to omap3isp, once its own subdevices have been
> > registered successfully.
> 
> Do you happen to have patches for this?
> I still think we should clean up the V4L2 async framework though.

http://git.kernel.org/cgit/linux/kernel/git/sre/linux-n900.git/tree/drivers/media/platform/video-bus-switch.c?h=n900-camera-ivo

It was inside of the RFC series Ivo sent in April.

> [...]

-- Sebastian


signature.asc
Description: PGP signature


Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-14 Thread Sakari Ailus
Hi Sebastian,

On Fri, Nov 04, 2016 at 01:05:25AM +0100, Sebastian Reichel wrote:
> Hi,
> 
> On Fri, Nov 04, 2016 at 01:05:01AM +0200, Sakari Ailus wrote:
> > On Thu, Nov 03, 2016 at 11:48:43PM +0100, Sebastian Reichel wrote:
> > > On Tue, Nov 01, 2016 at 12:54:08AM +0200, Sakari Ailus wrote:
> > > > > > Thanks, this answered half of my questions already. ;-)
> > > > > :-).
> > > > > 
> > > > > I'll have to go through the patches, et8ek8 driver is probably not
> > > > > enough to get useful video. platform/video-bus-switch.c is needed for
> > > > > camera switching, then some omap3isp patches to bind flash and
> > > > > autofocus into the subdevice.
> > > > > 
> > > > > Then, device tree support on n900 can be added.
> > > > 
> > > > I briefly discussed with with Sebastian.
> > > > 
> > > > Do you think the elusive support for the secondary camera is worth 
> > > > keeping
> > > > out the main camera from the DT in mainline? As long as there's a 
> > > > reasonable
> > > > way to get it working, I'd just merge that. If someone ever gets the
> > > > secondary camera working properly and nicely with the video bus switch,
> > > > that's cool, we'll somehow deal with the problem then. But frankly I 
> > > > don't
> > > > think it's very useful even if we get there: the quality is really bad.
> > > 
> > > If we want to keep open the option to add proper support for the
> > > second camera, we could also add the bus switch and not add the
> > > front camera node in DT. Then adding the front camera does not
> > > require DT or userspace API changes. It would need an additional
> > > DT quirk in arch/arm/mach-omap2/board-generic.c for RX51, which
> > > adds the CCP2 bus settings from the camera node to the bus
> > > switch node to keep isp_of_parse_node happy. That should be
> > > easy to implement and not add much delay in upstreaming.
> > 
> > By adding the video bus switch we have a little bit more complex system as a
> > whole. The V4L2 async does not currently support this. There's more here:
> > 
> > http://www.spinics.net/lists/linux-media/msg107262.html>
> 
> I'm not sure what part relevant for video-bus-switch is currently
> not supported?
> 
> video-bus-switch registers its own async notifier and only registers
> itself as subdevices to omap3isp, once its own subdevices have been
> registered successfully.

Do you happen to have patches for this?

I still think we should clean up the V4L2 async framework though.

> 
> > What I thought was that once we have everything that's required in
> > place, we can just change what's in DT. But the software needs to
> > continue to work with the old DT content.
> 
> Right, so DT is not a problem. But adding the switch would change
> the media-graph, which is exposed to userspace.

Well, yes, indeed. We'll have those cases coming anyway, as support for
multiple streams over a single link is added. In some cases more sub-devices
will be needed to expose all the necessary configurability to the user.

> 
> > > For actually getting both cameras available with runtime-switching
> > > the proper solution would probably involve moving the parsing of
> > > the bus-settings to the sensor driver and providing a callback.
> > > This callback can be called by omap3isp when it wants to configure
> > > the phy (which is basically when it starts streaming). That seems
> > > to be the only place needing the buscfg anyways.
> > > 
> > > Then the video-bus-switch could do something like this (pseudocode):
> > > 
> > > static void get_buscfg(struct *this, struct *buscfg) {
> > > if (selected_cam == 0)
> > > return this->sensor_a->get_buscfg(buscfg);
> > > else
> > > return this->sensor_b->get_buscfg(buscfg);
> > > }
> > > 
> > > Regarding the usefulness: I noticed, that the Neo900 people also
> > > plan to have the bus-switch [0]. It's still the same crappy front-cam,
> > > though. Nevertheless it might be useful for testing. It has nice
> > > test-image capabilities, which might be useful for regression
> > > testing once everything is in place.
> > > 
> > > [0] http://neo900.org/stuff/block-diagrams/neo900/neo900.html
> > 
> > Seriously? I suppose there should be no need for that anymore, is there?
> > 
> > I think they wanted to save one GPIO in order to shave off 0,0001 cents from
> > the manufacturing costs or something like that. And the result is...
> > painful. :-I
> 
> CSI1/CCP2 is more than a single I/O pin, isn't it? Or do you
> reference to the GPIO dual use to enable frontcam and switch
> between the cameras? That is indeed a really ugly solution :(

The GPIO, yes. It was a really bad idea...

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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 v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-03 Thread Sebastian Reichel
Hi,

On Fri, Nov 04, 2016 at 01:05:01AM +0200, Sakari Ailus wrote:
> On Thu, Nov 03, 2016 at 11:48:43PM +0100, Sebastian Reichel wrote:
> > On Tue, Nov 01, 2016 at 12:54:08AM +0200, Sakari Ailus wrote:
> > > > > Thanks, this answered half of my questions already. ;-)
> > > > :-).
> > > > 
> > > > I'll have to go through the patches, et8ek8 driver is probably not
> > > > enough to get useful video. platform/video-bus-switch.c is needed for
> > > > camera switching, then some omap3isp patches to bind flash and
> > > > autofocus into the subdevice.
> > > > 
> > > > Then, device tree support on n900 can be added.
> > > 
> > > I briefly discussed with with Sebastian.
> > > 
> > > Do you think the elusive support for the secondary camera is worth keeping
> > > out the main camera from the DT in mainline? As long as there's a 
> > > reasonable
> > > way to get it working, I'd just merge that. If someone ever gets the
> > > secondary camera working properly and nicely with the video bus switch,
> > > that's cool, we'll somehow deal with the problem then. But frankly I don't
> > > think it's very useful even if we get there: the quality is really bad.
> > 
> > If we want to keep open the option to add proper support for the
> > second camera, we could also add the bus switch and not add the
> > front camera node in DT. Then adding the front camera does not
> > require DT or userspace API changes. It would need an additional
> > DT quirk in arch/arm/mach-omap2/board-generic.c for RX51, which
> > adds the CCP2 bus settings from the camera node to the bus
> > switch node to keep isp_of_parse_node happy. That should be
> > easy to implement and not add much delay in upstreaming.
> 
> By adding the video bus switch we have a little bit more complex system as a
> whole. The V4L2 async does not currently support this. There's more here:
> 
> http://www.spinics.net/lists/linux-media/msg107262.html>

I'm not sure what part relevant for video-bus-switch is currently
not supported?

video-bus-switch registers its own async notifier and only registers
itself as subdevices to omap3isp, once its own subdevices have been
registered successfully.

> What I thought was that once we have everything that's required in
> place, we can just change what's in DT. But the software needs to
> continue to work with the old DT content.

Right, so DT is not a problem. But adding the switch would change
the media-graph, which is exposed to userspace.

> > For actually getting both cameras available with runtime-switching
> > the proper solution would probably involve moving the parsing of
> > the bus-settings to the sensor driver and providing a callback.
> > This callback can be called by omap3isp when it wants to configure
> > the phy (which is basically when it starts streaming). That seems
> > to be the only place needing the buscfg anyways.
> > 
> > Then the video-bus-switch could do something like this (pseudocode):
> > 
> > static void get_buscfg(struct *this, struct *buscfg) {
> > if (selected_cam == 0)
> > return this->sensor_a->get_buscfg(buscfg);
> > else
> > return this->sensor_b->get_buscfg(buscfg);
> > }
> > 
> > Regarding the usefulness: I noticed, that the Neo900 people also
> > plan to have the bus-switch [0]. It's still the same crappy front-cam,
> > though. Nevertheless it might be useful for testing. It has nice
> > test-image capabilities, which might be useful for regression
> > testing once everything is in place.
> > 
> > [0] http://neo900.org/stuff/block-diagrams/neo900/neo900.html
> 
> Seriously? I suppose there should be no need for that anymore, is there?
> 
> I think they wanted to save one GPIO in order to shave off 0,0001 cents from
> the manufacturing costs or something like that. And the result is...
> painful. :-I

CSI1/CCP2 is more than a single I/O pin, isn't it? Or do you
reference to the GPIO dual use to enable frontcam and switch
between the cameras? That is indeed a really ugly solution :(

-- Sebastian


signature.asc
Description: PGP signature


Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-03 Thread Ivaylo Dimitrov

Hi,

On  4.11.2016 01:05, Sakari Ailus wrote:

Hi Sebastian,

On Thu, Nov 03, 2016 at 11:48:43PM +0100, Sebastian Reichel wrote:

Hi,

On Tue, Nov 01, 2016 at 12:54:08AM +0200, Sakari Ailus wrote:

Thanks, this answered half of my questions already. ;-)

:-).

I'll have to go through the patches, et8ek8 driver is probably not
enough to get useful video. platform/video-bus-switch.c is needed for
camera switching, then some omap3isp patches to bind flash and
autofocus into the subdevice.

Then, device tree support on n900 can be added.


I briefly discussed with with Sebastian.

Do you think the elusive support for the secondary camera is worth keeping
out the main camera from the DT in mainline? As long as there's a reasonable
way to get it working, I'd just merge that. If someone ever gets the
secondary camera working properly and nicely with the video bus switch,
that's cool, we'll somehow deal with the problem then. But frankly I don't
think it's very useful even if we get there: the quality is really bad.


If we want to keep open the option to add proper support for the
second camera, we could also add the bus switch and not add the
front camera node in DT. Then adding the front camera does not
require DT or userspace API changes. It would need an additional
DT quirk in arch/arm/mach-omap2/board-generic.c for RX51, which
adds the CCP2 bus settings from the camera node to the bus
switch node to keep isp_of_parse_node happy. That should be
easy to implement and not add much delay in upstreaming.


By adding the video bus switch we have a little bit more complex system as a
whole. The V4L2 async does not currently support this. There's more here:

http://www.spinics.net/lists/linux-media/msg107262.html>

What I thought was that once we have everything that's required in place, we
can just change what's in DT. But the software needs to continue to work
with the old DT content.


For actually getting both cameras available with runtime-switching
the proper solution would probably involve moving the parsing of
the bus-settings to the sensor driver and providing a callback.
This callback can be called by omap3isp when it wants to configure
the phy (which is basically when it starts streaming). That seems
to be the only place needing the buscfg anyways.

Then the video-bus-switch could do something like this (pseudocode):

static void get_buscfg(struct *this, struct *buscfg) {
if (selected_cam == 0)
return this->sensor_a->get_buscfg(buscfg);
else
return this->sensor_b->get_buscfg(buscfg);
}

Regarding the usefulness: I noticed, that the Neo900 people also
plan to have the bus-switch [0]. It's still the same crappy front-cam,
though. Nevertheless it might be useful for testing. It has nice
test-image capabilities, which might be useful for regression
testing once everything is in place.

[0] http://neo900.org/stuff/block-diagrams/neo900/neo900.html


Seriously? I suppose there should be no need for that anymore, is there?

I think they wanted to save one GPIO in order to shave off 0,0001 cents from
the manufacturing costs or something like that. And the result is...
painful. :-I



No, the reason is that hey want to keep Neo900 as close as possible to 
N900, HW wise

--
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 v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-03 Thread Sakari Ailus
Hi Sebastian,

On Thu, Nov 03, 2016 at 11:48:43PM +0100, Sebastian Reichel wrote:
> Hi,
> 
> On Tue, Nov 01, 2016 at 12:54:08AM +0200, Sakari Ailus wrote:
> > > > Thanks, this answered half of my questions already. ;-)
> > > :-).
> > > 
> > > I'll have to go through the patches, et8ek8 driver is probably not
> > > enough to get useful video. platform/video-bus-switch.c is needed for
> > > camera switching, then some omap3isp patches to bind flash and
> > > autofocus into the subdevice.
> > > 
> > > Then, device tree support on n900 can be added.
> > 
> > I briefly discussed with with Sebastian.
> > 
> > Do you think the elusive support for the secondary camera is worth keeping
> > out the main camera from the DT in mainline? As long as there's a reasonable
> > way to get it working, I'd just merge that. If someone ever gets the
> > secondary camera working properly and nicely with the video bus switch,
> > that's cool, we'll somehow deal with the problem then. But frankly I don't
> > think it's very useful even if we get there: the quality is really bad.
> 
> If we want to keep open the option to add proper support for the
> second camera, we could also add the bus switch and not add the
> front camera node in DT. Then adding the front camera does not
> require DT or userspace API changes. It would need an additional
> DT quirk in arch/arm/mach-omap2/board-generic.c for RX51, which
> adds the CCP2 bus settings from the camera node to the bus
> switch node to keep isp_of_parse_node happy. That should be
> easy to implement and not add much delay in upstreaming.

By adding the video bus switch we have a little bit more complex system as a
whole. The V4L2 async does not currently support this. There's more here:

http://www.spinics.net/lists/linux-media/msg107262.html>

What I thought was that once we have everything that's required in place, we
can just change what's in DT. But the software needs to continue to work
with the old DT content.

> For actually getting both cameras available with runtime-switching
> the proper solution would probably involve moving the parsing of
> the bus-settings to the sensor driver and providing a callback.
> This callback can be called by omap3isp when it wants to configure
> the phy (which is basically when it starts streaming). That seems
> to be the only place needing the buscfg anyways.
> 
> Then the video-bus-switch could do something like this (pseudocode):
> 
> static void get_buscfg(struct *this, struct *buscfg) {
> if (selected_cam == 0)
> return this->sensor_a->get_buscfg(buscfg);
> else
> return this->sensor_b->get_buscfg(buscfg);
> }
> 
> Regarding the usefulness: I noticed, that the Neo900 people also
> plan to have the bus-switch [0]. It's still the same crappy front-cam,
> though. Nevertheless it might be useful for testing. It has nice
> test-image capabilities, which might be useful for regression
> testing once everything is in place.
> 
> [0] http://neo900.org/stuff/block-diagrams/neo900/neo900.html

Seriously? I suppose there should be no need for that anymore, is there?

I think they wanted to save one GPIO in order to shave off 0,0001 cents from
the manufacturing costs or something like that. And the result is...
painful. :-I

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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 v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-03 Thread Sebastian Reichel
Hi,

On Tue, Nov 01, 2016 at 12:54:08AM +0200, Sakari Ailus wrote:
> > > Thanks, this answered half of my questions already. ;-)
> > :-).
> > 
> > I'll have to go through the patches, et8ek8 driver is probably not
> > enough to get useful video. platform/video-bus-switch.c is needed for
> > camera switching, then some omap3isp patches to bind flash and
> > autofocus into the subdevice.
> > 
> > Then, device tree support on n900 can be added.
> 
> I briefly discussed with with Sebastian.
> 
> Do you think the elusive support for the secondary camera is worth keeping
> out the main camera from the DT in mainline? As long as there's a reasonable
> way to get it working, I'd just merge that. If someone ever gets the
> secondary camera working properly and nicely with the video bus switch,
> that's cool, we'll somehow deal with the problem then. But frankly I don't
> think it's very useful even if we get there: the quality is really bad.

If we want to keep open the option to add proper support for the
second camera, we could also add the bus switch and not add the
front camera node in DT. Then adding the front camera does not
require DT or userspace API changes. It would need an additional
DT quirk in arch/arm/mach-omap2/board-generic.c for RX51, which
adds the CCP2 bus settings from the camera node to the bus
switch node to keep isp_of_parse_node happy. That should be
easy to implement and not add much delay in upstreaming.

For actually getting both cameras available with runtime-switching
the proper solution would probably involve moving the parsing of
the bus-settings to the sensor driver and providing a callback.
This callback can be called by omap3isp when it wants to configure
the phy (which is basically when it starts streaming). That seems
to be the only place needing the buscfg anyways.

Then the video-bus-switch could do something like this (pseudocode):

static void get_buscfg(struct *this, struct *buscfg) {
if (selected_cam == 0)
return this->sensor_a->get_buscfg(buscfg);
else
return this->sensor_b->get_buscfg(buscfg);
}

Regarding the usefulness: I noticed, that the Neo900 people also
plan to have the bus-switch [0]. It's still the same crappy front-cam,
though. Nevertheless it might be useful for testing. It has nice
test-image capabilities, which might be useful for regression
testing once everything is in place.

[0] http://neo900.org/stuff/block-diagrams/neo900/neo900.html

-- Sebastian


signature.asc
Description: PGP signature


Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-03 Thread Pavel Machek
Hi!

> > > > I'll have to go through the patches, et8ek8 driver is probably not
> > > > enough to get useful video. platform/video-bus-switch.c is needed for
> > > > camera switching, then some omap3isp patches to bind flash and
> > > > autofocus into the subdevice.
> > > > 
> > > > Then, device tree support on n900 can be added.
> > > 
> > > I briefly discussed with with Sebastian.
> > > 
> > > Do you think the elusive support for the secondary camera is worth keeping
> > > out the main camera from the DT in mainline? As long as there's a 
> > > reasonable
> > > way to get it working, I'd just merge that. If someone ever gets the
> > > secondary camera working properly and nicely with the video bus switch,
> > > that's cool, we'll somehow deal with the problem then. But frankly I don't
> > > think it's very useful even if we get there: the quality is really
> > > bad.
> > 
> > Well, I am a little bit worried that /dev/video* entries will
> > renumber themself when the the front camera support is merged,
> > breaking userspace.
> > 
> > But the first step is still the same: get et8ek8 support merged :-).
> 
> Do you happen to have a patch for the DT part as well? People could more
> easily test this...

If you want complete/working tree for testing, it is at

https://git.kernel.org/cgit/linux/kernel/git/pavel/linux-n900.git/?h=camera-v4.9

If you want userspace to go with that, there's fcam-dev. It is on
gitlab:

https://gitlab.com/pavelm/fcam-dev


> > > > > Do all the modes work for you currently btw.?
> > > > 
> > > > I don't think I got 5MP mode to work. Even 2.5MP mode is tricky (needs
> > > > a lot of continuous memory).
> > > 
> > > The OMAP 3 ISP has got an MMU, getting some contiguous memory is not 
> > > really
> > > a problem when you have a 4 GiB empty space to use.
> > 
> > Ok, maybe it is something else. 2.5MP mode seems to work better when
> > there is free memory.
> 
> That's very odd. Do you use MMAP or USERPTR buffers btw.? I remember the
> cache was different on 3430, that could be an issue as well (VIVT AFAIR, so
> flushing requires making sure there are no other mappings or flushing the
> entire cache).

The userland code I'm using does

 struct v4l2_requestbuffers req;
 memset(&req, 0, sizeof(req));
 req.type   = V4L2_BUF_TYPE_VIDEO_CAPTURE;
 req.memory = V4L2_MEMORY_MMAP;
 req.count  = 8;
 printf("Reqbufs\n");
 if (ioctl(fd, VIDIOC_REQBUFS, &req) < 0) {
 ...


so I guess answer to your question is "MMAP". The v4l interface is at

https://gitlab.com/pavelm/fcam-dev/blob/master/src/N900/V4L2Sensor.cpp

.
Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-02 Thread Ivaylo Dimitrov



On  2.11.2016 10:15, Pavel Machek wrote:

Hi!


I'll have to go through the patches, et8ek8 driver is probably not
enough to get useful video. platform/video-bus-switch.c is needed for
camera switching, then some omap3isp patches to bind flash and
autofocus into the subdevice.

Then, device tree support on n900 can be added.


I briefly discussed with with Sebastian.

Do you think the elusive support for the secondary camera is worth keeping
out the main camera from the DT in mainline? As long as there's a reasonable
way to get it working, I'd just merge that. If someone ever gets the
secondary camera working properly and nicely with the video bus switch,
that's cool, we'll somehow deal with the problem then. But frankly I don't
think it's very useful even if we get there: the quality is really bad.



Yes, lets merge what we have till now, it will be way easier to improve on
it once it is part of the mainline.

BTW, I have (had) patched VBS working almost without problems, when it comes
to it I'll dig it.


Do you have a version that switches on runtime?

Best regards,
Pavel



IIRC yes, but I might be wrong, it was a while I was playing with it.

Ivo
--
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 v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-02 Thread Pavel Machek
Hi!

> >>I'll have to go through the patches, et8ek8 driver is probably not
> >>enough to get useful video. platform/video-bus-switch.c is needed for
> >>camera switching, then some omap3isp patches to bind flash and
> >>autofocus into the subdevice.
> >>
> >>Then, device tree support on n900 can be added.
> >
> >I briefly discussed with with Sebastian.
> >
> >Do you think the elusive support for the secondary camera is worth keeping
> >out the main camera from the DT in mainline? As long as there's a reasonable
> >way to get it working, I'd just merge that. If someone ever gets the
> >secondary camera working properly and nicely with the video bus switch,
> >that's cool, we'll somehow deal with the problem then. But frankly I don't
> >think it's very useful even if we get there: the quality is really bad.
> >
> 
> Yes, lets merge what we have till now, it will be way easier to improve on
> it once it is part of the mainline.
> 
> BTW, I have (had) patched VBS working almost without problems, when it comes
> to it I'll dig it.

Do you have a version that switches on runtime?

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-01 Thread Laurent Pinchart
Hello,

On Tuesday 01 Nov 2016 00:58:45 Sakari Ailus wrote:
> On Sun, Oct 23, 2016 at 10:40:01PM +0200, Pavel Machek wrote:
> > Hi!
> > 
> > > Thanks, this answered half of my questions already. ;-)
> > > 
> > > Do all the modes work for you currently btw.?
> > 
> > Aha, went through my notes. This is what it does in 5MP mode, even on
> > v4.9:
> > 
> > pavel@n900:/my/fcam-dev$ ./camera.py
> > ['-r']
> > ['-l', '"et8ek8 3-003e":0 -> "video-bus-switch":1 [1]']
> > ['-l', '"video-bus-switch":0 -> "OMAP3 ISP CCP2":0 [1]']
> > ['-l', '"OMAP3 ISP CCP2":1 -> "OMAP3 ISP CCDC":0 [1]']
> > ['-l', '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0 [1]']
> > ['-V', '"et8ek8 3-003e":0 [SGRBG10 2592x1968]']
> > ['-V', '"OMAP3 ISP CCP2":0 [SGRBG10 2592x1968]']
> > ['-V', '"OMAP3 ISP CCP2":1 [SGRBG10 2592x1968]']
> > ['-V', '"OMAP3 ISP CCDC":1 [SGRBG10 2592x1968]']
> > ['-V', '"OMAP3 ISP CCDC":2 [SGRBG10 2592x1968]']
> > Device /dev/video2 opened.
> > Device `OMAP3 ISP CCDC output' on `media' is a video capture (without
> > mplanes) device.
> > Video format set: SGRBG10 (30314142) 2592x1968 (stride 5184) field
> > none buffer size 10202112
> > Video format: SGRBG10 (30314142) 2592x1968 (stride 5184) field none
> > buffer size 10202112
> > 4 buffers requested.
> > length: 10202112 offset: 0 timestamp type/source: mono/EoF
> > Buffer 0/0 mapped at address 0xb63a.
> > length: 10202112 offset: 10203136 timestamp type/source: mono/EoF
> > Buffer 1/0 mapped at address 0xb59e5000.
> > length: 10202112 offset: 20406272 timestamp type/source: mono/EoF
> > Buffer 2/0 mapped at address 0xb502a000.
> > length: 10202112 offset: 30609408 timestamp type/source: mono/EoF
> > Buffer 3/0 mapped at address 0xb466f000.
> > 0 (0) [E] any 0 10202112 B 0.00 2792.366987 0.001 fps ts mono/EoF
> > Unable to queue buffer: Input/output error (5).
> > Unable to requeue buffer: Input/output error (5).
> > Unable to release buffers: Device or resource busy (16).
> > pavel@n900:/my/fcam-dev$
> > 
> > (gitlab.com fcam-dev branch good)
> > 
> > Kernel will say
> > 
> > [ 2689.598358] stream on success
> > [ 2702.426635] Streamon
> > [ 2702.426727] check_format checking px 808534338 808534338, h 984
> > 984, w 1296 1296, bpline 2592 2592, size 2550528 2550528 field 1 1
> > [ 2702.426818] configuring for 1296(2592)x984
> > [ 2702.434722] stream on success
> > [ 2792.276184] Streamon
> > [ 2792.276306] check_format checking px 808534338 808534338, h 1968
> > 1968, w 2592 2592, bpline 5184 5184, size 10202112 10202112 field 1 1
> > [ 2792.276367] configuring for 2592(5184)x1968
> > [ 2792.284240] stream on success
> > [ 2792.368164] omap3isp 480bc000.isp: CCDC won't become idle!
> 
> This is Bad(tm).
> 
> It means that the driver waited for the CCDC to become idle to reprogram it,
> but it didn't happen. This could be a problem in the number of lines
> configured, or some polarity settings between the CCP2 receiver and the
> CCDC.

Is that polarity even configurable ?

> I suspect the latter, but I could be totally wrong here as well since
> it was more than five years I worked on these things. :-I

The OMAP3 ISP CCDC is very fragile when the input signals don't match exactly 
what it expects. This is partly caused by the driver implementation, I believe 
we could do better, but it's been a long time since I looked at that code.

One possible debugging option is to check how much data the CCDC has written 
to memory (if any). If I remember correctly the SBL_CCDC_WR_* registers can 
help there, the target address they store should be incremented as data is 
written to memory.

> > [ 2793.901550] omap3isp 480bc000.isp: Unable to stop OMAP3 ISP CCDC
> 
> And this is probably directly caused by the same problem. :-(

-- 
Regards,

Laurent Pinchart

--
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 v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-01 Thread Ivaylo Dimitrov



On  1.11.2016 22:11, Sakari Ailus wrote:

Hi Ivaylo,

On Tue, Nov 01, 2016 at 08:36:57AM +0200, Ivaylo Dimitrov wrote:

Hi,

On  1.11.2016 00:54, Sakari Ailus wrote:

Hi Pavel,

On Sun, Oct 23, 2016 at 10:33:15PM +0200, Pavel Machek wrote:

Hi!


Thanks, this answered half of my questions already. ;-)


:-).

I'll have to go through the patches, et8ek8 driver is probably not
enough to get useful video. platform/video-bus-switch.c is needed for
camera switching, then some omap3isp patches to bind flash and
autofocus into the subdevice.

Then, device tree support on n900 can be added.


I briefly discussed with with Sebastian.

Do you think the elusive support for the secondary camera is worth keeping
out the main camera from the DT in mainline? As long as there's a reasonable
way to get it working, I'd just merge that. If someone ever gets the
secondary camera working properly and nicely with the video bus switch,
that's cool, we'll somehow deal with the problem then. But frankly I don't
think it's very useful even if we get there: the quality is really bad.



Yes, lets merge what we have till now, it will be way easier to improve on
it once it is part of the mainline.

BTW, I have (had) patched VBS working almost without problems, when it comes
to it I'll dig it.


I wonder if I'm the only one who wonders what VBS is here. Don't tell me its
the old MS thing. :-) ;-)



Oh, sorry, I thought that V(ideo) B(us) S(witch) is clear in the context :)
--
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 v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-01 Thread Sakari Ailus
Hi Ivaylo,

On Tue, Nov 01, 2016 at 08:36:57AM +0200, Ivaylo Dimitrov wrote:
> Hi,
> 
> On  1.11.2016 00:54, Sakari Ailus wrote:
> >Hi Pavel,
> >
> >On Sun, Oct 23, 2016 at 10:33:15PM +0200, Pavel Machek wrote:
> >>Hi!
> >>
> >>>Thanks, this answered half of my questions already. ;-)
> >>
> >>:-).
> >>
> >>I'll have to go through the patches, et8ek8 driver is probably not
> >>enough to get useful video. platform/video-bus-switch.c is needed for
> >>camera switching, then some omap3isp patches to bind flash and
> >>autofocus into the subdevice.
> >>
> >>Then, device tree support on n900 can be added.
> >
> >I briefly discussed with with Sebastian.
> >
> >Do you think the elusive support for the secondary camera is worth keeping
> >out the main camera from the DT in mainline? As long as there's a reasonable
> >way to get it working, I'd just merge that. If someone ever gets the
> >secondary camera working properly and nicely with the video bus switch,
> >that's cool, we'll somehow deal with the problem then. But frankly I don't
> >think it's very useful even if we get there: the quality is really bad.
> >
> 
> Yes, lets merge what we have till now, it will be way easier to improve on
> it once it is part of the mainline.
> 
> BTW, I have (had) patched VBS working almost without problems, when it comes
> to it I'll dig it.

I wonder if I'm the only one who wonders what VBS is here. Don't tell me its
the old MS thing. :-) ;-)

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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 v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-01 Thread Sakari Ailus
Hi Pavel,

On Tue, Nov 01, 2016 at 04:39:21PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > I'll have to go through the patches, et8ek8 driver is probably not
> > > enough to get useful video. platform/video-bus-switch.c is needed for
> > > camera switching, then some omap3isp patches to bind flash and
> > > autofocus into the subdevice.
> > > 
> > > Then, device tree support on n900 can be added.
> > 
> > I briefly discussed with with Sebastian.
> > 
> > Do you think the elusive support for the secondary camera is worth keeping
> > out the main camera from the DT in mainline? As long as there's a reasonable
> > way to get it working, I'd just merge that. If someone ever gets the
> > secondary camera working properly and nicely with the video bus switch,
> > that's cool, we'll somehow deal with the problem then. But frankly I don't
> > think it's very useful even if we get there: the quality is really
> > bad.
> 
> Well, I am a little bit worried that /dev/video* entries will
> renumber themself when the the front camera support is merged,
> breaking userspace.
> 
> But the first step is still the same: get et8ek8 support merged :-).

Do you happen to have a patch for the DT part as well? People could more
easily test this...

> > > > Do all the modes work for you currently btw.?
> > > 
> > > I don't think I got 5MP mode to work. Even 2.5MP mode is tricky (needs
> > > a lot of continuous memory).
> > 
> > The OMAP 3 ISP has got an MMU, getting some contiguous memory is not really
> > a problem when you have a 4 GiB empty space to use.
> 
> Ok, maybe it is something else. 2.5MP mode seems to work better when
> there is free memory.

That's very odd. Do you use MMAP or USERPTR buffers btw.? I remember the
cache was different on 3430, that could be an issue as well (VIVT AFAIR, so
flushing requires making sure there are no other mappings or flushing the
entire cache).

> > > Anyway, I have to start somewhere, and I believe this is a good
> > > starting place; I'd like to get the code cleaned up and merged, then
> > > move to the next parts.
> > 
> > I wonder if something else could be the problem. I think the data rate is
> > higher in the 5 MP mode, and that might be the reason. I don't remember how
> > similar is the clock tree in the 3430 to the 3630. Could it be that the ISP
> > clock is lower than it should be for some reason, for instance?
> 
> No idea, really. I'd like to get the support merged, and then debug
> the code when we have common code base in the mainline.

Yes. It's much easier then. Which is why it'd be very nice to have the DT
content, too.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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 v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-11-01 Thread Pavel Machek
Hi!

> > I'll have to go through the patches, et8ek8 driver is probably not
> > enough to get useful video. platform/video-bus-switch.c is needed for
> > camera switching, then some omap3isp patches to bind flash and
> > autofocus into the subdevice.
> > 
> > Then, device tree support on n900 can be added.
> 
> I briefly discussed with with Sebastian.
> 
> Do you think the elusive support for the secondary camera is worth keeping
> out the main camera from the DT in mainline? As long as there's a reasonable
> way to get it working, I'd just merge that. If someone ever gets the
> secondary camera working properly and nicely with the video bus switch,
> that's cool, we'll somehow deal with the problem then. But frankly I don't
> think it's very useful even if we get there: the quality is really
> bad.

Well, I am a little bit worried that /dev/video* entries will
renumber themself when the the front camera support is merged,
breaking userspace.

But the first step is still the same: get et8ek8 support merged :-).

> > > Do all the modes work for you currently btw.?
> > 
> > I don't think I got 5MP mode to work. Even 2.5MP mode is tricky (needs
> > a lot of continuous memory).
> 
> The OMAP 3 ISP has got an MMU, getting some contiguous memory is not really
> a problem when you have a 4 GiB empty space to use.

Ok, maybe it is something else. 2.5MP mode seems to work better when
there is free memory.

> > Anyway, I have to start somewhere, and I believe this is a good
> > starting place; I'd like to get the code cleaned up and merged, then
> > move to the next parts.
> 
> I wonder if something else could be the problem. I think the data rate is
> higher in the 5 MP mode, and that might be the reason. I don't remember how
> similar is the clock tree in the 3430 to the 3630. Could it be that the ISP
> clock is lower than it should be for some reason, for instance?

No idea, really. I'd like to get the support merged, and then debug
the code when we have common code base in the mainline.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-10-31 Thread Ivaylo Dimitrov

Hi,

On  1.11.2016 00:54, Sakari Ailus wrote:

Hi Pavel,

On Sun, Oct 23, 2016 at 10:33:15PM +0200, Pavel Machek wrote:

Hi!


Thanks, this answered half of my questions already. ;-)


:-).

I'll have to go through the patches, et8ek8 driver is probably not
enough to get useful video. platform/video-bus-switch.c is needed for
camera switching, then some omap3isp patches to bind flash and
autofocus into the subdevice.

Then, device tree support on n900 can be added.


I briefly discussed with with Sebastian.

Do you think the elusive support for the secondary camera is worth keeping
out the main camera from the DT in mainline? As long as there's a reasonable
way to get it working, I'd just merge that. If someone ever gets the
secondary camera working properly and nicely with the video bus switch,
that's cool, we'll somehow deal with the problem then. But frankly I don't
think it's very useful even if we get there: the quality is really bad.



Yes, lets merge what we have till now, it will be way easier to improve 
on it once it is part of the mainline.


BTW, I have (had) patched VBS working almost without problems, when it 
comes to it I'll dig it.



Do all the modes work for you currently btw.?


I don't think I got 5MP mode to work. Even 2.5MP mode is tricky (needs
a lot of continuous memory).


The OMAP 3 ISP has got an MMU, getting some contiguous memory is not really
a problem when you have a 4 GiB empty space to use.


Anyway, I have to start somewhere, and I believe this is a good
starting place; I'd like to get the code cleaned up and merged, then
move to the next parts.


I wonder if something else could be the problem. I think the data rate is
higher in the 5 MP mode, and that might be the reason. I don't remember how
similar is the clock tree in the 3430 to the 3630. Could it be that the ISP
clock is lower than it should be for some reason, for instance?



IIRC I checked what Nokia kernel does, and according to my vague 
memories the frequency was the same. Still, it seems the problem is in 
ISP, it has some very fragile calculations. Yet again, having main 
camera merged will ease the problem hunting.


Regards,
Ivo
--
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 v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-10-31 Thread Sakari Ailus
Hi Pavel,

(Cc Laurent.)

On Sun, Oct 23, 2016 at 10:40:01PM +0200, Pavel Machek wrote:
> Hi!
> 
> > Thanks, this answered half of my questions already. ;-)
> > 
> > Do all the modes work for you currently btw.?
> 
> Aha, went through my notes. This is what it does in 5MP mode, even on
> v4.9:
> 
> pavel@n900:/my/fcam-dev$ ./camera.py
> ['-r']
> ['-l', '"et8ek8 3-003e":0 -> "video-bus-switch":1 [1]']
> ['-l', '"video-bus-switch":0 -> "OMAP3 ISP CCP2":0 [1]']
> ['-l', '"OMAP3 ISP CCP2":1 -> "OMAP3 ISP CCDC":0 [1]']
> ['-l', '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0 [1]']
> ['-V', '"et8ek8 3-003e":0 [SGRBG10 2592x1968]']
> ['-V', '"OMAP3 ISP CCP2":0 [SGRBG10 2592x1968]']
> ['-V', '"OMAP3 ISP CCP2":1 [SGRBG10 2592x1968]']
> ['-V', '"OMAP3 ISP CCDC":1 [SGRBG10 2592x1968]']
> ['-V', '"OMAP3 ISP CCDC":2 [SGRBG10 2592x1968]']
> Device /dev/video2 opened.
> Device `OMAP3 ISP CCDC output' on `media' is a video capture (without
> mplanes) device.
> Video format set: SGRBG10 (30314142) 2592x1968 (stride 5184) field
> none buffer size 10202112
> Video format: SGRBG10 (30314142) 2592x1968 (stride 5184) field none
> buffer size 10202112
> 4 buffers requested.
> length: 10202112 offset: 0 timestamp type/source: mono/EoF
> Buffer 0/0 mapped at address 0xb63a.
> length: 10202112 offset: 10203136 timestamp type/source: mono/EoF
> Buffer 1/0 mapped at address 0xb59e5000.
> length: 10202112 offset: 20406272 timestamp type/source: mono/EoF
> Buffer 2/0 mapped at address 0xb502a000.
> length: 10202112 offset: 30609408 timestamp type/source: mono/EoF
> Buffer 3/0 mapped at address 0xb466f000.
> 0 (0) [E] any 0 10202112 B 0.00 2792.366987 0.001 fps ts mono/EoF
> Unable to queue buffer: Input/output error (5).
> Unable to requeue buffer: Input/output error (5).
> Unable to release buffers: Device or resource busy (16).
> pavel@n900:/my/fcam-dev$
> 
> (gitlab.com fcam-dev branch good)
> 
> Kernel will say
> 
> [ 2689.598358] stream on success
> [ 2702.426635] Streamon
> [ 2702.426727] check_format checking px 808534338 808534338, h 984
> 984, w 1296 1296, bpline 2592 2592, size 2550528 2550528 field 1 1
> [ 2702.426818] configuring for 1296(2592)x984
> [ 2702.434722] stream on success
> [ 2792.276184] Streamon
> [ 2792.276306] check_format checking px 808534338 808534338, h 1968
> 1968, w 2592 2592, bpline 5184 5184, size 10202112 10202112 field 1 1
> [ 2792.276367] configuring for 2592(5184)x1968
> [ 2792.284240] stream on success
> [ 2792.368164] omap3isp 480bc000.isp: CCDC won't become idle!

This is Bad(tm).

It means that the driver waited for the CCDC to become idle to reprogram it,
but it didn't happen. This could be a problem in the number of lines
configured, or some polarity settings between the CCP2 receiver and the
CCDC. I suspect the latter, but I could be totally wrong here as well since
it was more than five years I worked on these things. :-I

> [ 2793.901550] omap3isp 480bc000.isp: Unable to stop OMAP3 ISP CCDC

And this is probably directly caused by the same problem. :-(

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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 v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-10-31 Thread Sakari Ailus
Hi Pavel,

On Sun, Oct 23, 2016 at 10:33:15PM +0200, Pavel Machek wrote:
> Hi!
> 
> > Thanks, this answered half of my questions already. ;-)
> 
> :-).
> 
> I'll have to go through the patches, et8ek8 driver is probably not
> enough to get useful video. platform/video-bus-switch.c is needed for
> camera switching, then some omap3isp patches to bind flash and
> autofocus into the subdevice.
> 
> Then, device tree support on n900 can be added.

I briefly discussed with with Sebastian.

Do you think the elusive support for the secondary camera is worth keeping
out the main camera from the DT in mainline? As long as there's a reasonable
way to get it working, I'd just merge that. If someone ever gets the
secondary camera working properly and nicely with the video bus switch,
that's cool, we'll somehow deal with the problem then. But frankly I don't
think it's very useful even if we get there: the quality is really bad.

> > Do all the modes work for you currently btw.?
> 
> I don't think I got 5MP mode to work. Even 2.5MP mode is tricky (needs
> a lot of continuous memory).

The OMAP 3 ISP has got an MMU, getting some contiguous memory is not really
a problem when you have a 4 GiB empty space to use.

> Anyway, I have to start somewhere, and I believe this is a good
> starting place; I'd like to get the code cleaned up and merged, then
> move to the next parts.

I wonder if something else could be the problem. I think the data rate is
higher in the 5 MP mode, and that might be the reason. I don't remember how
similar is the clock tree in the 3430 to the 3630. Could it be that the ISP
clock is lower than it should be for some reason, for instance?

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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 v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-10-23 Thread Pavel Machek
On Sun 2016-10-23 23:19:54, Sakari Ailus wrote:
> Hi Pavel,
> 
> Thanks, this answered half of my questions already. ;-)
> 
> Do all the modes work for you currently btw.?

I pushed current kernel sources to kernel.org:

git push
g...@gitolite.kernel.org:pub/scm/linux/kernel/git/pavel/linux-n900.git
camera-v4.9:camera-v4.9

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-10-23 Thread Pavel Machek
Hi!

> Thanks, this answered half of my questions already. ;-)
> 
> Do all the modes work for you currently btw.?

Aha, went through my notes. This is what it does in 5MP mode, even on
v4.9:

pavel@n900:/my/fcam-dev$ ./camera.py
['-r']
['-l', '"et8ek8 3-003e":0 -> "video-bus-switch":1 [1]']
['-l', '"video-bus-switch":0 -> "OMAP3 ISP CCP2":0 [1]']
['-l', '"OMAP3 ISP CCP2":1 -> "OMAP3 ISP CCDC":0 [1]']
['-l', '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0 [1]']
['-V', '"et8ek8 3-003e":0 [SGRBG10 2592x1968]']
['-V', '"OMAP3 ISP CCP2":0 [SGRBG10 2592x1968]']
['-V', '"OMAP3 ISP CCP2":1 [SGRBG10 2592x1968]']
['-V', '"OMAP3 ISP CCDC":1 [SGRBG10 2592x1968]']
['-V', '"OMAP3 ISP CCDC":2 [SGRBG10 2592x1968]']
Device /dev/video2 opened.
Device `OMAP3 ISP CCDC output' on `media' is a video capture (without
mplanes) device.
Video format set: SGRBG10 (30314142) 2592x1968 (stride 5184) field
none buffer size 10202112
Video format: SGRBG10 (30314142) 2592x1968 (stride 5184) field none
buffer size 10202112
4 buffers requested.
length: 10202112 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0xb63a.
length: 10202112 offset: 10203136 timestamp type/source: mono/EoF
Buffer 1/0 mapped at address 0xb59e5000.
length: 10202112 offset: 20406272 timestamp type/source: mono/EoF
Buffer 2/0 mapped at address 0xb502a000.
length: 10202112 offset: 30609408 timestamp type/source: mono/EoF
Buffer 3/0 mapped at address 0xb466f000.
0 (0) [E] any 0 10202112 B 0.00 2792.366987 0.001 fps ts mono/EoF
Unable to queue buffer: Input/output error (5).
Unable to requeue buffer: Input/output error (5).
Unable to release buffers: Device or resource busy (16).
pavel@n900:/my/fcam-dev$

(gitlab.com fcam-dev branch good)

Kernel will say

[ 2689.598358] stream on success
[ 2702.426635] Streamon
[ 2702.426727] check_format checking px 808534338 808534338, h 984
984, w 1296 1296, bpline 2592 2592, size 2550528 2550528 field 1 1
[ 2702.426818] configuring for 1296(2592)x984
[ 2702.434722] stream on success
[ 2792.276184] Streamon
[ 2792.276306] check_format checking px 808534338 808534338, h 1968
1968, w 2592 2592, bpline 5184 5184, size 10202112 10202112 field 1 1
[ 2792.276367] configuring for 2592(5184)x1968
[ 2792.284240] stream on success
[ 2792.368164] omap3isp 480bc000.isp: CCDC won't become idle!
[ 2793.901550] omap3isp 480bc000.isp: Unable to stop OMAP3 ISP CCDC
pavel@n900:/my/fcam-dev$

in this case.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-10-23 Thread Pavel Machek
Hi!

> Thanks, this answered half of my questions already. ;-)

:-).

I'll have to go through the patches, et8ek8 driver is probably not
enough to get useful video. platform/video-bus-switch.c is needed for
camera switching, then some omap3isp patches to bind flash and
autofocus into the subdevice.

Then, device tree support on n900 can be added.

> Do all the modes work for you currently btw.?

I don't think I got 5MP mode to work. Even 2.5MP mode is tricky (needs
a lot of continuous memory).

Anyway, I have to start somewhere, and I believe this is a good
starting place; I'd like to get the code cleaned up and merged, then
move to the next parts.

Best regards,
Pavel


> On Sun, Oct 23, 2016 at 10:03:55PM +0200, Pavel Machek wrote:
> > 
> > Add driver for et8ek8 sensor, found in Nokia N900 main camera. Can be
> > used for taking photos in 2.5MP resolution with fcam-dev.
> > 
> > Signed-off-by: Ivaylo Dimitrov 
> > Signed-off-by: Pavel Machek 
> > 
> > ---
> > From v4 I did cleanups to coding style and removed various oddities.
> > 
> > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> > index 2669b4b..6d01e15 100644
> > --- a/drivers/media/i2c/Kconfig
> > +++ b/drivers/media/i2c/Kconfig
> > @@ -667,6 +667,7 @@ config VIDEO_S5K5BAF
> >   camera sensor with an embedded SoC image signal processor.
> >  
> >  source "drivers/media/i2c/smiapp/Kconfig"
> > +source "drivers/media/i2c/et8ek8/Kconfig"
> >  
> >  config VIDEO_S5C73M3
> > tristate "Samsung S5C73M3 sensor support"
> > diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> > index 92773b2..5bc7bbe 100644
> > --- a/drivers/media/i2c/Makefile
> > +++ b/drivers/media/i2c/Makefile
> > @@ -2,6 +2,7 @@ msp3400-objs:=  msp3400-driver.o 
> > msp3400-kthreads.o
> >  obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o
> >  
> >  obj-$(CONFIG_VIDEO_SMIAPP) += smiapp/
> > +obj-$(CONFIG_VIDEO_ET8EK8) += et8ek8/
> >  obj-$(CONFIG_VIDEO_CX25840) += cx25840/
> >  obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/
> >  obj-y  += soc_camera/
> > diff --git a/drivers/media/i2c/et8ek8/Kconfig 
> > b/drivers/media/i2c/et8ek8/Kconfig
> > new file mode 100644
> > index 000..1439936
> > --- /dev/null
> > +++ b/drivers/media/i2c/et8ek8/Kconfig
> > @@ -0,0 +1,6 @@
> > +config VIDEO_ET8EK8
> > +   tristate "ET8EK8 camera sensor support"
> > +   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> > +   ---help---
> > + This is a driver for the Toshiba ET8EK8 5 MP camera sensor.
> > + It is used for example in Nokia N900 (RX-51).
> > diff --git a/drivers/media/i2c/et8ek8/Makefile 
> > b/drivers/media/i2c/et8ek8/Makefile
> > new file mode 100644
> > index 000..66d1b7d
> > --- /dev/null
> > +++ b/drivers/media/i2c/et8ek8/Makefile
> > @@ -0,0 +1,2 @@
> > +et8ek8-objs+= et8ek8_mode.o et8ek8_driver.o
> > +obj-$(CONFIG_VIDEO_ET8EK8) += et8ek8.o
> > diff --git a/drivers/media/i2c/et8ek8/et8ek8_driver.c 
> > b/drivers/media/i2c/et8ek8/et8ek8_driver.c
> > new file mode 100644
> > index 000..0301e81
> > --- /dev/null
> > +++ b/drivers/media/i2c/et8ek8/et8ek8_driver.c
> > @@ -0,0 +1,1588 @@
> > +/*
> > + * et8ek8_driver.c
> > + *
> > + * Copyright (C) 2008 Nokia Corporation
> > + *
> > + * Contact: Sakari Ailus 
> > + *  Tuukka Toivonen 
> > + *
> > + * Based on code from Toni Leinonen .
> > + *
> > + * This driver is based on the Micron MT9T012 camera imager driver
> > + * (C) Texas Instruments.
> > + *
> > + * This program 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.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "et8ek8_reg.h"
> > +
> > +#define ET8EK8_NAME"et8ek8"
> > +#define ET8EK8_PRIV_MEM_SIZE   128
> > +#define ET8EK8_MAX_MSG 48
> > +
> > +struct et8ek8_sensor {
> > +   struct v4l2_subdev subdev;
> > +   struct media_pad pad;
> > +   struct v4l2_mbus_framefmt format;
> > +   struct gpio_desc *reset;
> > +   struct regulator *vana;
> > +   struct clk *ext_clk;
> > +   u32 xclk_freq;
> > +
> > +   u16 version;
> > +
> > +   struct v4l2_ctrl_handler ctrl_handler;
> > +   struct v4l2_ctrl *exposure;
> > +   struct v4l2_ctrl *pixel_rate;
> > +   struct et8ek8_reglist *current_reglist;
> > +
> > +   u8 priv_mem[ET8EK8_PRIV_MEM_SIZE];
> > +
> > +   struct mutex po

Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-10-23 Thread Sakari Ailus
Hi Pavel,

Thanks, this answered half of my questions already. ;-)

Do all the modes work for you currently btw.?

On Sun, Oct 23, 2016 at 10:03:55PM +0200, Pavel Machek wrote:
> 
> Add driver for et8ek8 sensor, found in Nokia N900 main camera. Can be
> used for taking photos in 2.5MP resolution with fcam-dev.
> 
> Signed-off-by: Ivaylo Dimitrov 
> Signed-off-by: Pavel Machek 
> 
> ---
> From v4 I did cleanups to coding style and removed various oddities.
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 2669b4b..6d01e15 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -667,6 +667,7 @@ config VIDEO_S5K5BAF
> camera sensor with an embedded SoC image signal processor.
>  
>  source "drivers/media/i2c/smiapp/Kconfig"
> +source "drivers/media/i2c/et8ek8/Kconfig"
>  
>  config VIDEO_S5C73M3
>   tristate "Samsung S5C73M3 sensor support"
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 92773b2..5bc7bbe 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -2,6 +2,7 @@ msp3400-objs  :=  msp3400-driver.o msp3400-kthreads.o
>  obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o
>  
>  obj-$(CONFIG_VIDEO_SMIAPP)   += smiapp/
> +obj-$(CONFIG_VIDEO_ET8EK8)   += et8ek8/
>  obj-$(CONFIG_VIDEO_CX25840) += cx25840/
>  obj-$(CONFIG_VIDEO_M5MOLS)   += m5mols/
>  obj-y+= soc_camera/
> diff --git a/drivers/media/i2c/et8ek8/Kconfig 
> b/drivers/media/i2c/et8ek8/Kconfig
> new file mode 100644
> index 000..1439936
> --- /dev/null
> +++ b/drivers/media/i2c/et8ek8/Kconfig
> @@ -0,0 +1,6 @@
> +config VIDEO_ET8EK8
> + tristate "ET8EK8 camera sensor support"
> + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> + ---help---
> +   This is a driver for the Toshiba ET8EK8 5 MP camera sensor.
> +   It is used for example in Nokia N900 (RX-51).
> diff --git a/drivers/media/i2c/et8ek8/Makefile 
> b/drivers/media/i2c/et8ek8/Makefile
> new file mode 100644
> index 000..66d1b7d
> --- /dev/null
> +++ b/drivers/media/i2c/et8ek8/Makefile
> @@ -0,0 +1,2 @@
> +et8ek8-objs  += et8ek8_mode.o et8ek8_driver.o
> +obj-$(CONFIG_VIDEO_ET8EK8)   += et8ek8.o
> diff --git a/drivers/media/i2c/et8ek8/et8ek8_driver.c 
> b/drivers/media/i2c/et8ek8/et8ek8_driver.c
> new file mode 100644
> index 000..0301e81
> --- /dev/null
> +++ b/drivers/media/i2c/et8ek8/et8ek8_driver.c
> @@ -0,0 +1,1588 @@
> +/*
> + * et8ek8_driver.c
> + *
> + * Copyright (C) 2008 Nokia Corporation
> + *
> + * Contact: Sakari Ailus 
> + *  Tuukka Toivonen 
> + *
> + * Based on code from Toni Leinonen .
> + *
> + * This driver is based on the Micron MT9T012 camera imager driver
> + * (C) Texas Instruments.
> + *
> + * This program 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "et8ek8_reg.h"
> +
> +#define ET8EK8_NAME  "et8ek8"
> +#define ET8EK8_PRIV_MEM_SIZE 128
> +#define ET8EK8_MAX_MSG   48
> +
> +struct et8ek8_sensor {
> + struct v4l2_subdev subdev;
> + struct media_pad pad;
> + struct v4l2_mbus_framefmt format;
> + struct gpio_desc *reset;
> + struct regulator *vana;
> + struct clk *ext_clk;
> + u32 xclk_freq;
> +
> + u16 version;
> +
> + struct v4l2_ctrl_handler ctrl_handler;
> + struct v4l2_ctrl *exposure;
> + struct v4l2_ctrl *pixel_rate;
> + struct et8ek8_reglist *current_reglist;
> +
> + u8 priv_mem[ET8EK8_PRIV_MEM_SIZE];
> +
> + struct mutex power_lock;
> + int power_count;
> +};
> +
> +#define to_et8ek8_sensor(sd) container_of(sd, struct et8ek8_sensor, subdev)
> +
> +enum et8ek8_versions {
> + ET8EK8_REV_1 = 0x0001,
> + ET8EK8_REV_2,
> +};
> +
> +/*
> + * This table describes what should be written to the sensor register
> + * for each gain value. The gain(index in the table) is in terms of
> + * 0.1EV, i.e. 10 indexes in the table give 2 time more gain [0] in
> + * the *analog gain, [1] in the digital gain
> + *
> + * Analog gain [dB] = 20*log10(regvalue/32); 0x20..0x100
> + */
> +static struct et8ek8_gain {
> + u16 analog;
> + u16 digital;
> +} const et8ek8_gain_table[] = {
> + { 32,0},  /* x1 */
> + { 34,0},
> + { 37,0},
> + { 39,0},
> + { 42,0},
> + { 45,0},
> + { 49,0},
> + { 52,0},
> + { 56,0

[PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-10-23 Thread Pavel Machek

Add driver for et8ek8 sensor, found in Nokia N900 main camera. Can be
used for taking photos in 2.5MP resolution with fcam-dev.

Signed-off-by: Ivaylo Dimitrov 
Signed-off-by: Pavel Machek 

---
From v4 I did cleanups to coding style and removed various oddities.

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 2669b4b..6d01e15 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -667,6 +667,7 @@ config VIDEO_S5K5BAF
  camera sensor with an embedded SoC image signal processor.
 
 source "drivers/media/i2c/smiapp/Kconfig"
+source "drivers/media/i2c/et8ek8/Kconfig"
 
 config VIDEO_S5C73M3
tristate "Samsung S5C73M3 sensor support"
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 92773b2..5bc7bbe 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -2,6 +2,7 @@ msp3400-objs:=  msp3400-driver.o msp3400-kthreads.o
 obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o
 
 obj-$(CONFIG_VIDEO_SMIAPP) += smiapp/
+obj-$(CONFIG_VIDEO_ET8EK8) += et8ek8/
 obj-$(CONFIG_VIDEO_CX25840) += cx25840/
 obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/
 obj-y  += soc_camera/
diff --git a/drivers/media/i2c/et8ek8/Kconfig b/drivers/media/i2c/et8ek8/Kconfig
new file mode 100644
index 000..1439936
--- /dev/null
+++ b/drivers/media/i2c/et8ek8/Kconfig
@@ -0,0 +1,6 @@
+config VIDEO_ET8EK8
+   tristate "ET8EK8 camera sensor support"
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   ---help---
+ This is a driver for the Toshiba ET8EK8 5 MP camera sensor.
+ It is used for example in Nokia N900 (RX-51).
diff --git a/drivers/media/i2c/et8ek8/Makefile 
b/drivers/media/i2c/et8ek8/Makefile
new file mode 100644
index 000..66d1b7d
--- /dev/null
+++ b/drivers/media/i2c/et8ek8/Makefile
@@ -0,0 +1,2 @@
+et8ek8-objs+= et8ek8_mode.o et8ek8_driver.o
+obj-$(CONFIG_VIDEO_ET8EK8) += et8ek8.o
diff --git a/drivers/media/i2c/et8ek8/et8ek8_driver.c 
b/drivers/media/i2c/et8ek8/et8ek8_driver.c
new file mode 100644
index 000..0301e81
--- /dev/null
+++ b/drivers/media/i2c/et8ek8/et8ek8_driver.c
@@ -0,0 +1,1588 @@
+/*
+ * et8ek8_driver.c
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ *
+ * Contact: Sakari Ailus 
+ *  Tuukka Toivonen 
+ *
+ * Based on code from Toni Leinonen .
+ *
+ * This driver is based on the Micron MT9T012 camera imager driver
+ * (C) Texas Instruments.
+ *
+ * This program 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "et8ek8_reg.h"
+
+#define ET8EK8_NAME"et8ek8"
+#define ET8EK8_PRIV_MEM_SIZE   128
+#define ET8EK8_MAX_MSG 48
+
+struct et8ek8_sensor {
+   struct v4l2_subdev subdev;
+   struct media_pad pad;
+   struct v4l2_mbus_framefmt format;
+   struct gpio_desc *reset;
+   struct regulator *vana;
+   struct clk *ext_clk;
+   u32 xclk_freq;
+
+   u16 version;
+
+   struct v4l2_ctrl_handler ctrl_handler;
+   struct v4l2_ctrl *exposure;
+   struct v4l2_ctrl *pixel_rate;
+   struct et8ek8_reglist *current_reglist;
+
+   u8 priv_mem[ET8EK8_PRIV_MEM_SIZE];
+
+   struct mutex power_lock;
+   int power_count;
+};
+
+#define to_et8ek8_sensor(sd)   container_of(sd, struct et8ek8_sensor, subdev)
+
+enum et8ek8_versions {
+   ET8EK8_REV_1 = 0x0001,
+   ET8EK8_REV_2,
+};
+
+/*
+ * This table describes what should be written to the sensor register
+ * for each gain value. The gain(index in the table) is in terms of
+ * 0.1EV, i.e. 10 indexes in the table give 2 time more gain [0] in
+ * the *analog gain, [1] in the digital gain
+ *
+ * Analog gain [dB] = 20*log10(regvalue/32); 0x20..0x100
+ */
+static struct et8ek8_gain {
+   u16 analog;
+   u16 digital;
+} const et8ek8_gain_table[] = {
+   { 32,0},  /* x1 */
+   { 34,0},
+   { 37,0},
+   { 39,0},
+   { 42,0},
+   { 45,0},
+   { 49,0},
+   { 52,0},
+   { 56,0},
+   { 60,0},
+   { 64,0},  /* x2 */
+   { 69,0},
+   { 74,0},
+   { 79,0},
+   { 84,0},
+   { 91,0},
+   { 97,0},
+   {104,0},
+   {111,0},
+   {119,0},
+   {128,0},  /* x4 */
+   {137,0},
+   {147,0},
+   {158,0},
+   {169,0},
+   {181,0},
+   {194,0},
+   {208,0}