drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
Subsystems (4)
Hi!
On n900, probe finishes ok (verified by adding printks), and the device shows up in /sys, but I don't get /dev/video* or /dev/v4l-subdev*.
Other drivers (back and front camera) load ok, and actually work. Any idea what could be wrong?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
Hi!
Quoted 6 lines
On n900, probe finishes ok (verified by adding printks), and the device shows up in /sys, but I don't get
/dev/video*or/dev/v4l-subdev*.Other drivers (back and front camera) load ok, and actually work. Any idea what could be wrong?
Ok, so I guess I realized what is the problem:
adp1653 registers itself as a subdev, but there's no device that register it as its part.
(ad5820 driver seems to have the same problem).
Is there example "dummy" device I could use, for sole purpose of having these devices appear in /dev? They are on i2c, so both can work on their own.
Thanks,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
Quoted 11 lines · Pavel Machek
Hi!
Quoted 6 lines
On n900, probe finishes ok (verified by adding printks), and the device shows up in /sys, but I don't get
/dev/video*or/dev/v4l-subdev*.Other drivers (back and front camera) load ok, and actually work. Any idea what could be wrong?
Ok, so I guess I realized what is the problem:
Quoted 8 lines
adp1653 registers itself as a subdev, but there's no device that register it as its part.
(ad5820 driver seems to have the same problem).
Is there example "dummy" device I could use, for sole purpose of having these devices appear in /dev? They are on i2c, so both can work on their own.
Ah, interesting. This was discussed a little bit during the Media Summit a few weeks back:
http://linuxtv.org/news.php?entry=2016-04-20.mchehab
See section 5:
"5. DT Bindings for flash & lens controllers
There are drivers that create their MC topology using the device tree information, which works great for entities that transport data, but how to detect entities that don?t transport data such as flash devices, focusers, etc.? How can those be deduced using the device tree?
Sensor DT node add phandle to focus controller: add generic v4l binding properties to reference such devices."
This wasn't a problem with the original N900 since that didn't use DT AFAIK and these devices were loaded explicitly through board code.
But now you run into the same problem that I have.
The solution is that sensor devices have to provide phandles to those controller devices. And to do that you need to define bindings which is always the hard part.
Look in Documentation/devicetree/bindings/media/video-interfaces.txt, section "Optional endpoint properties".
Something like:
controllers: an array of phandles to controller devices associated with this endpoint such as flash and lens controllers.
Warning: I'm no DT expert, so this is just a first attempt.
Platform drivers (omap3isp) will have to add these controller devices to the list of subdevs to load asynchronously.
Regards,
Hans
Sakari Ailus
maintainerRe: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
Hi Hans and Pavel,
Quoted 51 lines · Hans Verkuil
Quoted 11 lines · Pavel Machek
Hi!
Quoted 6 lines
On n900, probe finishes ok (verified by adding printks), and the device shows up in /sys, but I don't get
/dev/video*or/dev/v4l-subdev*.Other drivers (back and front camera) load ok, and actually work. Any idea what could be wrong?
Ok, so I guess I realized what is the problem:
Quoted 8 lines
adp1653 registers itself as a subdev, but there's no device that register it as its part.
(ad5820 driver seems to have the same problem).
Is there example "dummy" device I could use, for sole purpose of having these devices appear in /dev? They are on i2c, so both can work on their own.
Ah, interesting. This was discussed a little bit during the Media Summit a few weeks back:
http://linuxtv.org/news.php?entry=2016-04-20.mchehab
See section 5:
"5. DT Bindings for flash & lens controllers
There are drivers that create their MC topology using the device tree information, which works great for entities that transport data, but how to detect entities that don?t transport data such as flash devices, focusers, etc.? How can those be deduced using the device tree?
Sensor DT node add phandle to focus controller: add generic v4l binding properties to reference such devices."
This wasn't a problem with the original N900 since that didn't use DT AFAIK and these devices were loaded explicitly through board code.
But now you run into the same problem that I have.
The solution is that sensor devices have to provide phandles to those controller devices. And to do that you need to define bindings which is always the hard part.
Look in
Documentation/devicetree/bindings/media/video-interfaces.txt, section "Optional endpoint properties".Something like:
Quoted 7 lines
controllers: an array of phandles to controller devices associated with this endpoint such as flash and lens controllers.
Warning: I'm no DT expert, so this is just a first attempt.
Platform drivers (omap3isp) will have to add these controller devices to the list of subdevs to load asynchronously.
I seem to have patches I haven't had time to push back then:
This seems to be mostly in line with what has been discussed in the meeting, except that the patches add a device specific property. Please ignore the led patches in that tree for now (i.e. four patches on the top are the relevant ones here).
Signature · 4 lines
Kind regards, Sakari Ailus e-mail: sakari.ailus at iki.fi XMPP: sailus at retiisi.org.uk
Re: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
Hi!
Quoted 23 lines
Quoted 23 lines
Quoted 8 lines
adp1653 registers itself as a subdev, but there's no device that register it as its part.
(ad5820 driver seems to have the same problem).
Is there example "dummy" device I could use, for sole purpose of having these devices appear in /dev? They are on i2c, so both can work on their own.
Ah, interesting. This was discussed a little bit during the Media Summit a few weeks back:
http://linuxtv.org/news.php?entry=2016-04-20.mchehab
See section 5:
"5. DT Bindings for flash & lens controllers
There are drivers that create their MC topology using the device tree information, which works great for entities that transport data, but how to detect entities that don?t transport data such as flash devices, focusers, etc.? How can those be deduced using the device tree?
Quoted 7 lines
Quoted 7 lines
Sensor DT node add phandle to focus controller: add generic v4l binding properties to reference such devices."
This wasn't a problem with the original N900 since that didn't use DT AFAIK and these devices were loaded explicitly through board code.
But now you run into the same problem that I have.
Actually... being able to do board-code solution for testing for now would be nice...
Quoted 12 lines
Quoted 12 lines
The solution is that sensor devices have to provide phandles to those controller devices. And to do that you need to define bindings which is always the hard part.
Look in
Documentation/devicetree/bindings/media/video-interfaces.txt, section "Optional endpoint properties".Something like:
controllers: an array of phandles to controller devices associated with this endpoint such as flash and lens controllers.
Quoted 9 lines
Quoted 4 lines
Warning: I'm no DT expert, so this is just a first attempt.
Platform drivers (omap3isp) will have to add these controller devices to the list of subdevs to load asynchronously.
I seem to have patches I haven't had time to push back then:
That gitweb is a bit confused about its own address, but I figured it out. Let me check...
pavel at amd:/data/l/linux-n900$ git fetchgit://git.retiisi.org.uk/~sailus/linux.git leds-as3645a:leds-as3645a
fatal: unable to connect to git.retiisi.org.uk:
git.retiisi.org.uk: Name or service not known
pavel at amd:/data/l/linux-n900$ git fetchgit://salottisipuli.retiisi.org.uk/~sailus/linux.git
leds-as3645a:leds-as3645a
remote: Counting objects: 132, done.
remote: Compressing objects: 100% (46/46), done.
remote: Total 132 (delta 111), reused 107 (delta 86) Receiving objects: 100% (132/132), 22.80 KiB | 0 bytes/s, done. Resolving deltas: 100% (111/111), completed with 34 local objects.
Quoted 1 line
From
git://salottisipuli.retiisi.org.uk/~sailus/linux
* [new branch] leds-as3645a -> leds-as3645a
Quoted 5 lines
This seems to be mostly in line with what has been discussed in the meeting, except that the patches add a device specific property. Please ignore the led patches in that tree for now (i.e. four patches on the top are the relevant ones here).
I'm currently trying to apply them to v4.6, but am getting rather ugly rejects :-(.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Sakari Ailus
maintainerRe: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
Hi Pavel,
Quoted 66 lines · Pavel Machek
Hi!
Quoted 23 lines
Quoted 23 lines
Quoted 8 lines
adp1653 registers itself as a subdev, but there's no device that register it as its part.
(ad5820 driver seems to have the same problem).
Is there example "dummy" device I could use, for sole purpose of having these devices appear in /dev? They are on i2c, so both can work on their own.
Ah, interesting. This was discussed a little bit during the Media Summit a few weeks back:
http://linuxtv.org/news.php?entry=2016-04-20.mchehab
See section 5:
"5. DT Bindings for flash & lens controllers
There are drivers that create their MC topology using the device tree information, which works great for entities that transport data, but how to detect entities that don?t transport data such as flash devices, focusers, etc.? How can those be deduced using the device tree?
Quoted 7 lines
Quoted 7 lines
Sensor DT node add phandle to focus controller: add generic v4l binding properties to reference such devices."
This wasn't a problem with the original N900 since that didn't use DT AFAIK and these devices were loaded explicitly through board code.
But now you run into the same problem that I have.
Actually... being able to do board-code solution for testing for now would be nice...
Quoted 12 lines
Quoted 12 lines
The solution is that sensor devices have to provide phandles to those controller devices. And to do that you need to define bindings which is always the hard part.
Look in
Documentation/devicetree/bindings/media/video-interfaces.txt, section "Optional endpoint properties".Something like:
controllers: an array of phandles to controller devices associated with this endpoint such as flash and lens controllers.
Quoted 9 lines
Quoted 4 lines
Warning: I'm no DT expert, so this is just a first attempt.
Platform drivers (omap3isp) will have to add these controller devices to the list of subdevs to load asynchronously.
I seem to have patches I haven't had time to push back then:
That gitweb is a bit confused about its own address, but I figured it out. Let me check...
pavel at amd:/data/l/linux-n900$ git fetch
git://git.retiisi.org.uk/~sailus/linux.gitleds-as3645a:leds-as3645a
fatal: unable to connect to git.retiisi.org.uk:
git.retiisi.org.uk: Name or service not known
Quoted 10 lines
pavel at amd:/data/l/linux-n900$ git fetch
git://salottisipuli.retiisi.org.uk/~sailus/linux.git
leds-as3645a:leds-as3645a
remote: Counting objects: 132, done.
remote: Compressing objects: 100% (46/46), done.
remote: Total 132 (delta 111), reused 107 (delta 86) Receiving objects: 100% (132/132), 22.80 KiB | 0 bytes/s, done. Resolving deltas: 100% (111/111), completed with 34 local objects. Fromgit://salottisipuli.retiisi.org.uk/~sailus/linux
* [new branch] leds-as3645a -> leds-as3645a
Yeah, that works, too. git alias has been added some three weeks ago so there seem to be something strange going on with DNS.
Quoted 10 lines
Quoted 7 lines
This seems to be mostly in line with what has been discussed in the meeting, except that the patches add a device specific property. Please ignore the led patches in that tree for now (i.e. four patches on the top are the relevant ones here).
I'm currently trying to apply them to v4.6, but am getting rather ugly rejects :-(.
:-\
There have been patches applied to the omap3isp driver since that I suppose. These aren't overly complex, feel free to take the patches if they're still useful.
Signature · 4 lines
Kind regards, Sakari Ailus e-mail: sakari.ailus at iki.fi XMPP: sailus at retiisi.org.uk
Re: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
Quoted 16 lines · On Friday 29 April 2016 13:59:44 Sakari Ailus wrote:
Quoted 5 lines
pavel at amd:/data/l/linux-n900$ git fetch
git://git.retiisi.org.uk/~sailus/linux.gitleds-as3645a:leds-as3645a
fatal: unable to connect to git.retiisi.org.uk:
git.retiisi.org.uk: Name or service not knownQuoted 10 lines
pavel at amd:/data/l/linux-n900$ git fetch
git://salottisipuli.retiisi.org.uk/~sailus/linux.git
leds-as3645a:leds-as3645a
remote: Counting objects: 132, done.
remote: Compressing objects: 100% (46/46), done.
remote: Total 132 (delta 111), reused 107 (delta 86) Receiving objects: 100% (132/132), 22.80 KiB | 0 bytes/s, done. Resolving deltas: 100% (111/111), completed with 34 local objects. Fromgit://salottisipuli.retiisi.org.uk/~sailus/linux
* [new branch] leds-as3645a -> leds-as3645a
Quoted 2 lines
Yeah, that works, too. git alias has been added some three weeks ago so there seem to be something strange going on with DNS.
Maybe update SOA record?
Signature · 2 lines
Pali Roh?r pali.rohar at gmail.com
Sakari Ailus
maintainerRe: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
Quoted 17 lines · Pali Roh?r
Quoted 16 lines · On Friday 29 April 2016 13:59:44 Sakari Ailus wrote:
Quoted 15 lines
pavel at amd:/data/l/linux-n900$ git fetch
git://git.retiisi.org.uk/~sailus/linux.gitleds-as3645a:leds-as3645a
fatal: unable to connect to git.retiisi.org.uk:
git.retiisi.org.uk: Name or service not knownpavel at amd:/data/l/linux-n900$ git fetch
git://salottisipuli.retiisi.org.uk/~sailus/linux.git
leds-as3645a:leds-as3645a
remote: Counting objects: 132, done.
remote: Compressing objects: 100% (46/46), done.
remote: Total 132 (delta 111), reused 107 (delta 86) Receiving objects: 100% (132/132), 22.80 KiB | 0 bytes/s, done. Resolving deltas: 100% (111/111), completed with 34 local objects. Fromgit://salottisipuli.retiisi.org.uk/~sailus/linux
* [new branch] leds-as3645a -> leds-as3645a
Quoted 4 lines
Quoted 2 lines
Yeah, that works, too. git alias has been added some three weeks ago so there seem to be something strange going on with DNS.
Maybe update SOA record?
The host has been added before that. It looks like the slaves are performing the zone transfer nicely but for some reason they don't seem to correctly respond when the newly added name is queried.
Signature · 2 lines
Sakari Ailus e-mail: sakari.ailus at iki.fi XMPP: sailus at retiisi.org.uk
Re: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
In reply to Sakari AilusHi!
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
This seems to be mostly in line with what has been discussed in the meeting, except that the patches add a device specific property. Please ignore the led patches in that tree for now (i.e. four patches on the top are the relevant ones here).
Quoted 8 lines
Quoted 2 lines
I'm currently trying to apply them to v4.6, but am getting rather ugly rejects :-(.
:-\
There have been patches applied to the omap3isp driver since that I suppose. These aren't overly complex, feel free to take the patches if they're still useful.
Ok, I got it to work. I can split it back, if needed. I've got patches on camera-fm3 branch. And yes, that gets flash to work.
(I don't know how to turn flash into torch, which is what I really wanted, but I guess I'll figure it out.)
Pavel
arch/arm/boot/dts/omap3-n900.dts +1 -0
@@ -239,6 +239,7 @@ pinctrl-names = "default"; pinctrl-0 = <&camera_pins>; + ti,camera-flashes = <&adp1653 &cam1>; ports { port at 1 {
drivers/media/platform/omap3isp/isp.c +105 -26
178 lines not on this page · raw message
drivers/media/platform/omap3isp/isp.h +2 -1
@@ -228,8 +228,9 @@ struct isp_device {struct isp_async_subdev {struct v4l2_subdev *sd; -struct isp_bus_cfg bus; +struct isp_bus_cfg *bus;struct v4l2_async_subdev asd; +u32 group_id; };#define v4l2_dev_to_isp_device (dev) \
drivers/media/platform/omap3isp/ispcsiphy.c +1 -1
@@ -177,7 +177,7 @@ static int omap3isp_csiphy_config(struct isp_csiphy *phy)struct isp_async_subdev *isd =container_of (pipe->external->asd, struct isp_async_subdev, asd); - buscfg = &isd->bus; + buscfg = isd->bus; } if (buscfg->interface == ISP_INTERFACE_CCP2B_PHY1
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
In reply to Sakari AilusHi!
Quoted 5 lines
Quoted 4 lines
Warning: I'm no DT expert, so this is just a first attempt.
Platform drivers (omap3isp) will have to add these controller devices to the list of subdevs to load asynchronously.
Quoted 8 lines
I seem to have patches I haven't had time to push back then:
This seems to be mostly in line with what has been discussed in the meeting, except that the patches add a device specific property. Please ignore the led patches in that tree for now (i.e. four patches on the top are the relevant ones here).
Ok, I attempted to forward-port the patches to v4.6. Not sure if I was successful.
Signature · 37 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-omap3isp-Fix-async-notifier-registration-order.patch Type: text/x-diff Size: 4550 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160429/250b3c03/attachment-0005.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Solve-conflict-I-missed.patch Type: text/x-diff Size: 1354 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160429/250b3c03/attachment-0006.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Cherry-pick-manually.patch Type: text/x-diff Size: 5662 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160429/250b3c03/attachment-0007.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-omap3isp-Assign-a-group-ID-for-sensor-and-flash-enti.patch Type: text/x-diff Size: 3782 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160429/250b3c03/attachment-0008.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Fix-work-around-compilation.patch Type: text/x-diff Size: 833 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160429/250b3c03/attachment-0009.bin>
[pre-rfc] focus and flash for Nokia N900 (was Re: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*)
In reply to Hans VerkuilHi!
Quoted 18 lines
"5. DT Bindings for flash & lens controllers
There are drivers that create their MC topology using the device tree information, which works great for entities that transport data, but how to detect entities that don?t transport data such as flash devices, focusers, etc.? How can those be deduced using the device tree?
Sensor DT node add phandle to focus controller: add generic v4l binding properties to reference such devices."
This wasn't a problem with the original N900 since that didn't use DT AFAIK and these devices were loaded explicitly through board code.
But now you run into the same problem that I have.
The solution is that sensor devices have to provide phandles to those controller devices. And to do that you need to define bindings which is always the hard part.
Quoted 7 lines
Look in
Documentation/devicetree/bindings/media/video-interfaces.txt, section "Optional endpoint properties".Something like:
controllers: an array of phandles to controller devices associated with this endpoint such as flash and lens controllers.
Ok, so after a big fight, I got both auto focus and flash to work on n900. Relative to N900 camera trees recently posted.
Subdevs behave rather funny, and --sleep-forever is needed for useful operation.
YA=/my/tui/yavta/yavta
# torch sudo $YA --sleep-forever --set-control '0x009c0901 2' /dev/v4l-subdev11
# focus -- near sudo $YA --sleep-forever --set-control '0x009a090a 1023' /dev/l-subdev12
arch/arm/boot/dts/omap3-n900.dts +12 -1
@@ -239,6 +239,7 @@ pinctrl-names = "default"; pinctrl-0 = <&camera_pins>; + ti,camera-flashes = <&adp1653 &cam1 &ad5820 &cam1>; ports { port at 1 {
@@ -251,7 +252,7 @@ data-lanes = <1>; lane-polarity = <0 0>; clock-inv = <0>; - strobe = <0>; + strobe = <1>; crc = <0>; }; };
@@ -879,6 +880,16 @@ }; }; }; + + /* D/A converter for auto-focus */ + ad5820: dac at 0c { + compatible = "adi,ad5820"; + reg = <0x0c>; + + VANA-supply = <&vaux4>; + + #io-channel-cells = <0>; + }; }; &mmc1 {
drivers/media/i2c/Kconfig +7 -0
@@ -279,6 +279,13 @@ config VIDEO_ML86V7667 To compile this driver as a module, choose M here: the module will be called ml86v7667. +config VIDEO_AD5820 + tristate "AD5820 lens voice coil support" + depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER + ---help--- + This is a driver for the AD5820 camera lens voice coil. + It is used for example in Nokia N900 (RX-51). + config VIDEO_SAA7110 tristate "Philips SAA7110 video decoder" depends on VIDEO_V4L2 && I2C
drivers/media/i2c/Makefile +1 -0
@@ -20,6 +20,7 @@ obj-$(CONFIG_VIDEO_SAA717X) += saa717x.o obj-$(CONFIG_VIDEO_SAA7127) += saa7127.o obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o +obj-$(CONFIG_VIDEO_AD5820) += ad5820.o obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
drivers/media/i2c/ad5820.c new file +526 -0
526 lines not on this page · raw message
drivers/media/i2c/adp1653.c +16 -0
@@ -306,6 +306,8 @@ adp1653_init_device(struct adp1653_flash *flash)return -EIO ; } +dev_info (&client->dev,"adp1653 device ok\n" , __func__); +return 0 ; }
@@ -492,6 +494,8 @@ static int adp1653_probe(struct i2c_client *client,if (flash ==NULL )return -ENOMEM ; +dev_info (&client->dev,"adp1653 probe\n" ); +if (client->dev.of_node) { ret =adp1653_of_init (client, flash, client->dev.of_node);if (ret)
@@ -505,11 +509,13 @@ static int adp1653_probe(struct i2c_client *client, flash->platform_data = client->dev.platform_data; } +dev_info (&client->dev,"adp1653 probe: subdev\n" , __func__);mutex_init (&flash->power_lock);v4l2_i2c_subdev_init (&flash->subdev, client, &adp1653_ops); flash->subdev.internal_ops = &adp1653_internal_ops; flash->subdev.flags |=V4L2_SUBDEV_FL_HAS_DEVNODE ; +strcpy (flash->subdev.name,"adp1653 flash" ); ret =adp1653_init_controls (flash);if (ret)
@@ -519,6 +525,14 @@ static int adp1653_probe(struct i2c_client *client,if (ret <0 ) goto free_and_quit; +dev_info (&client->dev,"adp1653 probe: should be ok\n" ); + + ret =v4l2_async_register_subdev (&flash->subdev); +if (ret <0 ) + goto free_and_quit; + +dev_info (&client->dev,"adp1653 probe: async register subdev ok\n" ); + flash->subdev.entity.function =MEDIA_ENT_F_FLASH ;return 0 ;
@@ -538,6 +552,8 @@ static int adp1653_remove(struct i2c_client *client)v4l2_ctrl_handler_free (&flash->ctrls);media_entity_cleanup (&flash->subdev.entity); +dev_info (&client->dev,"adp1653 remove\n" ); +return 0 ; }
drivers/media/platform/omap3isp/isp.c +105 -26
178 lines not on this page · raw message
drivers/media/platform/omap3isp/isp.h +2 -1
@@ -228,8 +228,9 @@ struct isp_device {struct isp_async_subdev {struct v4l2_subdev *sd; -struct isp_bus_cfg bus; +struct isp_bus_cfg *bus;struct v4l2_async_subdev asd; +u32 group_id; };#define v4l2_dev_to_isp_device (dev) \
drivers/media/platform/omap3isp/ispcsiphy.c +1 -1
@@ -177,7 +177,7 @@ static int omap3isp_csiphy_config(struct isp_csiphy *phy)struct isp_async_subdev *isd =container_of (pipe->external->asd, struct isp_async_subdev, asd); - buscfg = &isd->bus; + buscfg = isd->bus; } if (buscfg->interface == ISP_INTERFACE_CCP2B_PHY1
include/media/ad5820.h new file +70 -0
70 lines not on this page · raw message
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
camera application for testing (was Re: v4l subdevs without big device)
In reply to Hans VerkuilHi!
What is reasonable camera application for testing?
N900 looks like a low-end digital camera. I have now have the hardware working (can set focus to X cm using command line), but that's not going to be useful for taking photos.
In particular, who is going to do computation neccessary for autofocus, whitebalance and exposure/gain?
There's http://fcam.garage.maemo.org/gettingStarted.html that should work on maemo, but a) it is not in Debian, b) it has non-trivial dependencies and c) will be a lot of fun to get working...
(and d), will not be too useful, anyway, due to 1sec shutter lag:
Fast resolution switching (less shutter lag)
FCam is built on top of V4L2, which doesn't handle rapidly varying resolutions. When a Shot with a different resolution to the previous one comes down the pipeline, FCam currently flushes the entire V4L2 pipeline, shuts down and restarts the whole camera subsystem, then starts streaming at the new resolution. This takes a long time (nearly a second), and is the cause of the horrible shutter lag on the N900. A brave kernel hacker may be able to reduce this time by fiddling with the FCam ISP kernel modules and the guts of the FCam library source (primarily Daemon.cpp).
Anyone who solves this one will have our undying gratitude. An ideal solution would be able to insert a 5MP capture into a stream of 640x480 frames running at 30fps, without skipping more than the frame time of the 5MP capture. That is, the viewfinder would effectively stay live while taking a photograph.
)
Any other application I should look at? Thanks,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: camera application for testing (was Re: v4l subdevs without big device)
Quoted 1 line · On Saturday 30 April 2016 00:13:59 Pavel Machek wrote:
Any other application I should look at? Thanks,
Maybe camera-ui, which is part of CSSU?
https://github.com/community-ssu/camera-ui
Signature · 9 lines
Pali Roh?r pali.rohar at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160430/7dc0b70f/attachment-0001.sig>
Re: camera application for testing (was Re: v4l subdevs without big device)
Hi,
Quoted 7 lines · Pali Roh?r
Quoted 1 line · On Saturday 30 April 2016 00:13:59 Pavel Machek wrote:
Any other application I should look at? Thanks,
Maybe camera-ui, which is part of CSSU?
This is based on gdigicam, are you sure it is compatible with recent kernel/userspace? Also, iirc gdigicam needs omap3camd working, but we still don't have the needed compat layer.
Ivo
Sakari Ailus
maintainerRe: camera application for testing (was Re: v4l subdevs without big device)
In reply to Pavel MachekHi Pavel,
Quoted 7 lines · Pavel Machek
Hi!
What is reasonable camera application for testing?
N900 looks like a low-end digital camera. I have now have the hardware working (can set focus to X cm using command line), but that's not going to be useful for taking photos.
I guess you already knew about omap3camd; it's proprietary but from purely practical point of view it'd be an option to support taking photos on the N900. That would not be extensible any way, the best possible functionality is limited what the daemon implements.
I'm just mentioning the option of implementing wrapper for the omap3camd so that it can work with upsteam APIs, I don't propose that however.
Quoted 3 lines
In particular, who is going to do computation neccessary for autofocus, whitebalance and exposure/gain?
I think libv4l itself has algorithms to control at least some of these. It relies on the image data so the CPU time consumption will be high.
AFAIR Laurent has also worked on implementing some algorithms that use the histogram and some of the statistics. Add him to cc list.
Quoted 6 lines
There's http://fcam.garage.maemo.org/gettingStarted.html that should work on maemo, but a) it is not in Debian, b) it has non-trivial dependencies and c) will be a lot of fun to get working...
(and d), will not be too useful, anyway, due to 1sec shutter lag:
I believe this will be shorter nowadays. I don't remember the exact technical solution which the text below refers to but I'm pretty sure it'll be better with the current upstream. API-wise, there's work to be done there (to port FCAM to upsteram APIs) but it's a possibility.
Quoted 20 lines
Fast resolution switching (less shutter lag)
FCam is built on top of V4L2, which doesn't handle rapidly varying resolutions. When a Shot with a different resolution to the previous one comes down the pipeline, FCam currently flushes the entire V4L2 pipeline, shuts down and restarts the whole camera subsystem, then starts streaming at the new resolution. This takes a long time (nearly a second), and is the cause of the horrible shutter lag on the N900. A brave kernel hacker may be able to reduce this time by fiddling with the FCam ISP kernel modules and the guts of the FCam library source (primarily Daemon.cpp).
Anyone who solves this one will have our undying gratitude. An ideal solution would be able to insert a 5MP capture into a stream of 640x480 frames running at 30fps, without skipping more than the frame time of the 5MP capture. That is, the viewfinder would effectively stay live while taking a photograph.)
Any other application I should look at? Thanks,
Signature · 4 lines
Kind regards, Sakari Ailus e-mail: sakari.ailus at iki.fi XMPP: sailus at retiisi.org.uk
Re: camera application for testing (was Re: v4l subdevs without big device)
Hi!
Quoted 7 lines
Quoted 6 lines
What is reasonable camera application for testing?
N900 looks like a low-end digital camera. I have now have the hardware working (can set focus to X cm using command line), but that's not going to be useful for taking photos.
Quoted 7 lines
I guess you already knew about omap3camd; it's proprietary but from purely practical point of view it'd be an option to support taking photos on the N900. That would not be extensible any way, the best possible functionality is limited what the daemon implements.
I'm just mentioning the option of implementing wrapper for the omap3camd so that it can work with upsteam APIs, I don't propose that however.
I knew it existed, but I'd prefer not to touch proprietary code.
Quoted 8 lines
Quoted 2 lines
In particular, who is going to do computation neccessary for autofocus, whitebalance and exposure/gain?
I think libv4l itself has algorithms to control at least some of these. It relies on the image data so the CPU time consumption will be high.
AFAIR Laurent has also worked on implementing some algorithms that use the histogram and some of the statistics. Add him to cc list.
Aha, good, let me know.
Quoted 10 lines
Quoted 5 lines
There's http://fcam.garage.maemo.org/gettingStarted.html that should work on maemo, but a) it is not in Debian, b) it has non-trivial dependencies and c) will be a lot of fun to get working...
(and d), will not be too useful, anyway, due to 1sec shutter lag:
I believe this will be shorter nowadays. I don't remember the exact technical solution which the text below refers to but I'm pretty sure it'll be better with the current upstream. API-wise, there's work to be done there (to port FCAM to upsteram APIs) but it's a possibility.
I took a look at fcam-dev in the meantime... and it does not look too bad. It is quite n900-specific -- it needs hardware support for histograms and sharpness maps -- but it should not be too hard to modify.
Relying on hardware support without having fallback software implementation feels wrong, but... it should actually be ok as I already have the hardware...
(Is there accepted "upstream" for it?)
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: camera application for testing (was Re: v4l subdevs without big device)
In reply to Sakari AilusHi!
Quoted 15 lines
Quoted 5 lines
What is reasonable camera application for testing?
N900 looks like a low-end digital camera. I have now have the hardware working (can set focus to X cm using command line), but that's not going to be useful for taking photos.
I guess you already knew about omap3camd; it's proprietary but from purely practical point of view it'd be an option to support taking photos on the N900. That would not be extensible any way, the best possible functionality is limited what the daemon implements.
I'm just mentioning the option of implementing wrapper for the omap3camd so that it can work with upsteam APIs, I don't propose that however.
Quoted 1 line
Quoted 8 lines
Quoted 2 lines
In particular, who is going to do computation neccessary for autofocus, whitebalance and exposure/gain?
I think libv4l itself has algorithms to control at least some of these. It relies on the image data so the CPU time consumption will be high.
AFAIR Laurent has also worked on implementing some algorithms that use the histogram and some of the statistics. Add him to cc list.
Ok, so I played a bit... and have something working. I modified fcam-dev to work with the current kernel, and removed most functionality in the process. Then I re-did sharpness and autogain computations in software, and it seems to work somehow... but its rather slow. (But good news is that's because code is stupid; the computations should be fast enough.)
In particular, it takes cca 10 seconds to take a picture. I guess there's a room for improvement :-).
Quoted 10 lines
Quoted 5 lines
There's http://fcam.garage.maemo.org/gettingStarted.html that should work on maemo, but a) it is not in Debian, b) it has non-trivial dependencies and c) will be a lot of fun to get working...
(and d), will not be too useful, anyway, due to 1sec shutter lag:
I believe this will be shorter nowadays. I don't remember the exact technical solution which the text below refers to but I'm pretty sure it'll be better with the current upstream. API-wise, there's work to be done there (to port FCAM to upsteram APIs) but it's a possibility.
So far I have really horrible hacks.
Best regards,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: camera application for testing (was Re: v4l subdevs without big device)
In reply to Sakari AilusHi Sakari,
Quoted 17 lines · On Sunday 01 May 2016 17:08:31 Sakari Ailus wrote:
Quoted 7 lines · Pavel Machek
Hi!
What is reasonable camera application for testing?
N900 looks like a low-end digital camera. I have now have the hardware working (can set focus to X cm using command line), but that's not going to be useful for taking photos.
I guess you already knew about omap3camd; it's proprietary but from purely practical point of view it'd be an option to support taking photos on the N900. That would not be extensible any way, the best possible functionality is limited what the daemon implements.
I'm just mentioning the option of implementing wrapper for the omap3camd so that it can work with upsteam APIs, I don't propose that however.
Quoted 8 lines
Quoted 2 lines
In particular, who is going to do computation neccessary for autofocus, whitebalance and exposure/gain?
I think libv4l itself has algorithms to control at least some of these. It relies on the image data so the CPU time consumption will be high.
AFAIR Laurent has also worked on implementing some algorithms that use the histogram and some of the statistics. Add him to cc list.
http://git.ideasonboard.org/omap3-isp-live.git
That's outdated and might not run or compile anymore. The code is more of a proof of concept implementation, but it could be used as a starting point. With an infinite amount of free time I'd love to work on an open-source project for computational cameras, integrating it with libv4l.
Quoted 29 lines
Quoted 4 lines
There's http://fcam.garage.maemo.org/gettingStarted.html that should work on maemo, but a) it is not in Debian, b) it has non-trivial dependencies and c) will be a lot of fun to get working... (and d), will not be too useful, anyway, due to 1sec shutter lag:
I believe this will be shorter nowadays. I don't remember the exact technical solution which the text below refers to but I'm pretty sure it'll be better with the current upstream. API-wise, there's work to be done there (to port FCAM to upsteram APIs) but it's a possibility.
Quoted 19 lines
Fast resolution switching (less shutter lag)
FCam is built on top of V4L2, which doesn't handle rapidly varying resolutions. When a Shot with a different resolution to the previous one comes down the pipeline, FCam currently flushes the entire V4L2 pipeline, shuts down and restarts the whole camera subsystem, then starts streaming at the new resolution. This takes a long time (nearly a second), and is the cause of the horrible shutter lag on the N900. A brave kernel hacker may be able to reduce this time by fiddling with the FCam ISP kernel modules and the guts of the FCam library source (primarily Daemon.cpp).
Anyone who solves this one will have our undying gratitude. An ideal solution would be able to insert a 5MP capture into a stream of 640x480 frames running at 30fps, without skipping more than the frame time of the 5MP capture. That is, the viewfinder would effectively stay live while taking a photograph.)
Any other application I should look at? Thanks,
Signature · 3 lines
Regards, Laurent Pinchart
Re: camera application for testing (was Re: v4l subdevs without big device)
Hi!
Quoted 10 lines
Quoted 5 lines
I think libv4l itself has algorithms to control at least some of these. It relies on the image data so the CPU time consumption will be high.
AFAIR Laurent has also worked on implementing some algorithms that use the histogram and some of the statistics. Add him to cc list.
http://git.ideasonboard.org/omap3-isp-live.git
That's outdated and might not run or compile anymore. The code is more of a
Lets see, it compiles with this hack:
index 6f3ffbe..935f41d 100644
isp/v4l2.c +1 -1
@@ -292,7 +292,7 @@ struct v4l2_device *v4l2_open(const char *devname)* driver (>= v3.19) will set both CAPTURE and OUTPUT in the * capabilities field. */ - capabilities = cap.device_caps ? : cap.capabilities; + capabilities =/* cap.device_caps ? : */ cap.capabilities;if (capabilities &V4L2_CAP_VIDEO_CAPTURE ) dev->type =V4L2_BUF_TYPE_VIDEO_CAPTURE ;
I can try to run it, but I guess I'll need kernel with camera support.
pavel at n900:/my/omap3-isp-live$ LD_LIBRARY_PATH=isp ./snapshotmedia_open: Can't open media device /dev/media0
error: unable to open media device /dev/media0 Segmentation fault (core dumped)
I tried again on kernel with camera:
pavel at n900:/my/omap3-isp-live$ LD_LIBRARY_PATH=isp ./snapshot
error: unable to locate sensor.
Segmentation fault (core dumped)
pavel at n900:/my/omap3-isp-live$
Here's the fix for coredump:
isp/subdev.c +2 -0
@@ -75,6 +75,8 @@ int v4l2_subdev_open(struct media_entity *entity)void v4l2_subdev_close (struct media_entity *entity) { +if (!entity) +return ;if (entity->fd ==-1 )return ;
Let me investigate some more.
Quoted 3 lines
proof of concept implementation, but it could be used as a starting point. With an infinite amount of free time I'd love to work on an open-source project for computational cameras, integrating it with libv4l.
For the record, I pushed my code to
https://gitlab.com/pavelm/fcam-dev
Best regards,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html