media: Driver for Toshiba et8ek8 5MP sensor
Subsystems (4)
Re: [PATCH] devicetree: Add video bus switch
In reply to Sakari AilusHi!
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Review
Quoted 4 lines
(quoted diff) +4
-0+Required properties +=================== + +compatible : must contain "video-bus-switch"How generic is this? Should we have e.g. nokia,video-bus-switch? And if so, change the file name accordingly.
Quoted 4 lines
Quoted 2 lines
Generic for "single GPIO controls the switch", AFAICT. But that should be common enough...
Um, yes. Then... how about: video-bus-switch-gpio? No Nokia prefix.
Ok, done. I also fixed the english a bit.
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Review
Quoted 4 lines
(quoted diff) +4
-0+reg : The interface: + 0 - port for image signal processor + 1 - port for first camera sensor + 2 - port for second camera sensorI'd say this must be pretty much specific to the one in N900. You could have more ports. Or you could say that ports beyond 0 are camera sensors. I guess this is good enough for now though, it can be changed later on with the source if a need arises.
Quoted 8 lines
Quoted 3 lines
Well, I'd say that selecting between two sensors is going to be the common case. If someone needs more than two, it will no longer be simple GPIO, so we'll have some fixing to do.
It could be two GPIOs --- that's how the GPIO I2C mux works.
But I'd be surprised if someone ever uses something like that again. ;-)
I'd say.. lets handle that when we see hardware like that.
Quoted 8 lines
Quoted 8 lines
Quoted 4 lines
Btw. was it still considered a problem that the endpoint properties for the sensors can be different? With the
g_routing()pad op which is to be added, the ISP driver (should actually go to a framework somewhere) could parse the graph and find the proper endpoint there.I don't know about
g_routing. I addedg_endpoint_configmethod that passes the configuration, and that seems to work for me.
Quoted 8 lines
Quoted 1 line
I don't see
g_routingin next-20170201 . Is there place to look?I think there was a patch by Laurent to LMML quite some time ago. I suppose that set will be repicked soonish.
I don't really object using
g_endpoint_config()as a temporary solution; I'd like to have Laurent's opinion on that though. Another option is to wait, but we've already waited a looong time (as in total).
Laurent, do you have some input here? We have simple "2 cameras connected to one signal processor" situation here. We need some way of passing endpoint configuration from the sensors through the switch. I did this:
Quoted 6 lines
include/media/v4l2-subdev.h struct v4l2_subdev_video_ops { · line 420
Quoted 6 lines
include/media/v4l2-subdev.h +2
-0@@ -415,6 +416,8 @@ struct v4l2_subdev_video_ops { const struct v4l2_mbus_config *cfg);int (*s_rx_buffer)(struct v4l2_subdev *sd,void *buf,unsigned int *size); +int (*g_endpoint_config)(struct v4l2_subdev *sd, +struct v4l2_of_endpoint *cfg);
Google of g_routing tells me:
9) Highly reconfigurable hardware - Julien Beraud
- 44 sub-devices connected with an interconnect.
- As long as formats match, any sub-device could be connected to any
- other sub-device through a link.
- The result is 44 * 44 links at worst.
- A switch sub-device proposed as the solution to model the
- interconnect. The sub-devices are connected to the switch
- sub-devices through the hardware links that connect to the
- interconnect.
- The switch would be controlled through new IOCTLs S_ROUTING and
- G_ROUTING.
- Patches available:
http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/log/?h=xilinx-wip
but the patches are from 2005. So I guess I'll need some guidance here...
Quoted 1 line
I'll reply to the other patch containing the code.
Ok, thanks.
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: [PATCH] devicetree: Add video bus switch
Hi Pavel,
Quoted 31 lines · Pavel Machek
Hi!
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Review
Quoted 4 lines
(quoted diff) +4
-0+Required properties +=================== + +compatible : must contain "video-bus-switch"How generic is this? Should we have e.g. nokia,video-bus-switch? And if so, change the file name accordingly.
Quoted 4 lines
Quoted 2 lines
Generic for "single GPIO controls the switch", AFAICT. But that should be common enough...
Um, yes. Then... how about: video-bus-switch-gpio? No Nokia prefix.
Ok, done. I also fixed the english a bit.
Quoted 14 lines
Quoted 13 lines
Quoted 9 lines
Review
Quoted 4 lines
(quoted diff) +4
-0+reg : The interface: + 0 - port for image signal processor + 1 - port for first camera sensor + 2 - port for second camera sensorI'd say this must be pretty much specific to the one in N900. You could have more ports. Or you could say that ports beyond 0 are camera sensors. I guess this is good enough for now though, it can be changed later on with the source if a need arises.
Well, I'd say that selecting between two sensors is going to be the common case. If someone needs more than two, it will no longer be simple GPIO, so we'll have some fixing to do.
Quoted 6 lines
Quoted 4 lines
It could be two GPIOs --- that's how the GPIO I2C mux works.
But I'd be surprised if someone ever uses something like that again. ;-)
I'd say.. lets handle that when we see hardware like that.
Yes. :-)
Quoted 47 lines
Quoted 9 lines
Quoted 9 lines
Quoted 5 lines
Btw. was it still considered a problem that the endpoint properties for the sensors can be different? With the
g_routing()pad op which is to be added, the ISP driver (should actually go to a framework somewhere) could parse the graph and find the proper endpoint there.I don't know about
g_routing. I addedg_endpoint_configmethod that passes the configuration, and that seems to work for me.Quoted 8 lines
Quoted 1 line
I don't see
g_routingin next-20170201 . Is there place to look?I think there was a patch by Laurent to LMML quite some time ago. I suppose that set will be repicked soonish.
I don't really object using
g_endpoint_config()as a temporary solution; I'd like to have Laurent's opinion on that though. Another option is to wait, but we've already waited a looong time (as in total).Laurent, do you have some input here? We have simple "2 cameras connected to one signal processor" situation here. We need some way of passing endpoint configuration from the sensors through the switch. I did this:
Quoted 6 lines
include/media/v4l2-subdev.h struct v4l2_subdev_video_ops { · line 420
Quoted 6 lines
include/media/v4l2-subdev.h +2
-0@@ -415,6 +416,8 @@ struct v4l2_subdev_video_ops { const struct v4l2_mbus_config *cfg);int (*s_rx_buffer)(struct v4l2_subdev *sd,void *buf,unsigned int *size); +int (*g_endpoint_config)(struct v4l2_subdev *sd, +struct v4l2_of_endpoint *cfg);Google of
g_routingtells me:9) Highly reconfigurable hardware - Julien Beraud
- 44 sub-devices connected with an interconnect.
- As long as formats match, any sub-device could be connected to any
- other sub-device through a link.
- The result is 44 * 44 links at worst.
- A switch sub-device proposed as the solution to model the
- interconnect. The sub-devices are connected to the switch
- sub-devices through the hardware links that connect to the
- interconnect.
- The switch would be controlled through new IOCTLsS_ROUTINGand
-G_ROUTING.
- Patches available:
http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/log/?h=xilinx-wip
Quoted 1 line
but the patches are from 2005. So I guess I'll need some guidance here...
Yeah, that's where it began (2015?), but right now I can only suggest to wait until there's more. My estimate is within next couple of weeks / months. But it won't be years.
Signature · 8 lines
Kind regards, Sakari Ailus e-mail: [email protected] XMPP: [email protected] -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] devicetree: Add video bus switch
Hi!
Quoted 15 lines
Quoted 15 lines
9) Highly reconfigurable hardware - Julien Beraud
- 44 sub-devices connected with an interconnect.
- As long as formats match, any sub-device could be connected to any
- other sub-device through a link.
- The result is 44 * 44 links at worst.
- A switch sub-device proposed as the solution to model the
- interconnect. The sub-devices are connected to the switch
- sub-devices through the hardware links that connect to the
- interconnect.
- The switch would be controlled through new IOCTLsS_ROUTINGand
-G_ROUTING.
- Patches available:
http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/log/?h=xilinx-wip
Quoted 5 lines
Quoted 1 line
but the patches are from 2005. So I guess I'll need some guidance here...
Yeah, that's where it began (2015?), but right now I can only suggest to wait until there's more. My estimate is within next couple of weeks / months. But it won't be years.
Ok, week or two would be ok, couple of months is not. And all I need is single hook in common structure.
So if g_endpoint_config hook looks sane to _you_, I suggest we simply proceed. Now, maybe Mauro Carvalho Chehab <[email protected]> or Laurent or Julien will want a different solution, but then... they'll have to suggest something doable now, not in couple of months.
Does that sound like a plan?
Mauro added to cc list, so we can get some input.
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: [PATCH] devicetree: Add video bus switch
Hi,
Quoted 30 lines · Pavel Machek
Quoted 15 lines
Quoted 15 lines
9) Highly reconfigurable hardware - Julien Beraud
- 44 sub-devices connected with an interconnect.
- As long as formats match, any sub-device could be connected to any
- other sub-device through a link.
- The result is 44 * 44 links at worst.
- A switch sub-device proposed as the solution to model the
- interconnect. The sub-devices are connected to the switch
- sub-devices through the hardware links that connect to the
- interconnect.
- The switch would be controlled through new IOCTLsS_ROUTINGand
-G_ROUTING.
- Patches available:
http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/log/?h=xilinx-wipQuoted 5 lines
Quoted 1 line
but the patches are from 2005. So I guess I'll need some guidance here...
Yeah, that's where it began (2015?), but right now I can only suggest to wait until there's more. My estimate is within next couple of weeks / months. But it won't be years.
Ok, week or two would be ok, couple of months is not. And all I need is single hook in common structure.
So if
g_endpoint_confighook looks sane to _you_, I suggest we simply proceed. Now, maybe Mauro Carvalho Chehab <[email protected]> or Laurent or Julien will want a different solution, but
then... they'll have to suggest something doable now, not in couple of months.
Quoted 3 lines
Does that sound like a plan?
Mauro added to cc list, so we can get some input.
side note: It's an kernel-internal API only used by the media subsystem. Code can be easily updated to use an improved API at any time.
-- Sebastian
PATCH 1/1 media: add operation to get configuration of "the other side" of the link
Normally, link configuration can be determined at probe time... but Nokia N900 has two cameras, and can switch between them at runtime, so that mechanism is not suitable here.
Add a hook that tells us link configuration.
include/media/v4l2-subdev.h +5 -0
@@ -25,6 +25,7 @@#include <media/v4l2-dev.h> #include <media/v4l2-fh.h> #include <media/v4l2-mediabus.h> +#include <media/v4l2-of.h> /* generic v4l2_device notify callback notification values */ #define V4L2_SUBDEV_IR_RX_NOTIFY _IOW('v', 0, u32)
@@ -383,6 +384,8 @@ struct v4l2_mbus_frame_desc {* @s_rx_buffer: set a host allocated memory buffer for the subdev. The subdev * can adjust @size to a lower value and must not write more data to the * buffer starting at @data than the original value of @size. +* +* @g_endpoint_config: get link configuration required by this device. */ struct v4l2_subdev_video_ops {int (*s_routing)(struct v4l2_subdev *sd,u32 input,u32 output,u32 config);
@@ -415,6 +418,8 @@ struct v4l2_subdev_video_ops { const struct v4l2_mbus_config *cfg);int (*s_rx_buffer)(struct v4l2_subdev *sd,void *buf,unsigned int *size); +int (*g_endpoint_config)(struct v4l2_subdev *sd, +struct v4l2_of_endpoint *cfg); };/**
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: [PATCH] media: add operation to get configuration of "the other side" of the link
Hi Pavel,
Quoted 35 lines · Pavel Machek
Normally, link configuration can be determined at probe time... but Nokia N900 has two cameras, and can switch between them at runtime, so that mechanism is not suitable here.
Add a hook that tells us link configuration.
Signed-off-by Pavel Machek <[email protected]>include/media/v4l2-subdev.h +3
-0@@ -25,6 +25,7 @@#include <media/v4l2-dev.h> #include <media/v4l2-fh.h> #include <media/v4l2-mediabus.h> +#include <media/v4l2-of.h> /* generic v4l2_device notify callback notification values */ #define V4L2_SUBDEV_IR_RX_NOTIFY _IOW('v', 0, u32)@@ -383,6 +384,8 @@ struct v4l2_mbus_frame_desc {* @s_rx_buffer: set a host allocated memory buffer for the subdev. The subdev * can adjust @size to a lower value and must not write more data to the * buffer starting at @data than the original value of @size. +* +* @g_endpoint_config: get link configuration required by this device. */ struct v4l2_subdev_video_ops {int (*s_routing)(struct v4l2_subdev *sd,u32 input,u32 output,u32 config);
include/media/v4l2-subdev.h struct v4l2_subdev_video_ops { · line 425
Quoted 8 lines
include/media/v4l2-subdev.h +2
-0@@ -415,6 +418,8 @@ struct v4l2_subdev_video_ops { const struct v4l2_mbus_config *cfg);int (*s_rx_buffer)(struct v4l2_subdev *sd,void *buf,unsigned int *size); +int (*g_endpoint_config)(struct v4l2_subdev *sd, +struct v4l2_of_endpoint *cfg); };/**
I think Laurent has a board that has a similar issue.
I'd like to address such issues in conjunction with the CSI-2 virtual channel and data type support, with the patches in the vc branch here:
<URL:https://git.linuxtv.org/sailus/media_tree.git/log/?h=vc>
V4L2 OF (or fwnode) endpoint alone doesn't contain all the related information, and it'd be nice if the solution was indeed independent of OF (or fwnode).
Niklas has been working on more driver support for this so we're getting closer to having these merged.
Signature · 4 lines
Kind regards, Sakari Ailus e-mail: [email protected]
Laurent Pinchart
maintainerRe: [PATCH] devicetree: Add video bus switch
In reply to Pavel MachekHi Pavel,
Quoted 51 lines · On Saturday, 4 February 2017 23:56:10 EET Pavel Machek wrote:
Hi!
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Review
Quoted 4 lines
(quoted diff) +4
-0+Required properties +=================== + +compatible : must contain "video-bus-switch"How generic is this? Should we have e.g. nokia,video-bus-switch? And if so, change the file name accordingly.
Quoted 4 lines
Quoted 2 lines
Generic for "single GPIO controls the switch", AFAICT. But that should be common enough...
Um, yes. Then... how about: video-bus-switch-gpio? No Nokia prefix.
Ok, done. I also fixed the english a bit.
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Review
Quoted 4 lines
(quoted diff) +4
-0+reg : The interface: + 0 - port for image signal processor + 1 - port for first camera sensor + 2 - port for second camera sensorI'd say this must be pretty much specific to the one in N900. You could have more ports. Or you could say that ports beyond 0 are camera sensors. I guess this is good enough for now though, it can be changed later on with the source if a need arises.
Quoted 8 lines
Quoted 3 lines
Well, I'd say that selecting between two sensors is going to be the common case. If someone needs more than two, it will no longer be simple GPIO, so we'll have some fixing to do.
It could be two GPIOs --- that's how the GPIO I2C mux works.
But I'd be surprised if someone ever uses something like that again. ;-)
I'd say.. lets handle that when we see hardware like that.
Quoted 13 lines
Quoted 9 lines
Quoted 4 lines
Btw. was it still considered a problem that the endpoint properties for the sensors can be different? With the
g_routing()pad op which is to be added, the ISP driver (should actually go to a framework somewhere) could parse the graph and find the proper endpoint there.I don't know about
g_routing. I addedg_endpoint_configmethod that passes the configuration, and that seems to work for me.I don't see
g_routingin next-20170201 . Is there place to look?I think there was a patch by Laurent to LMML quite some time ago. I suppose that set will be repicked soonish.
Quoted 8 lines
Quoted 3 lines
I don't really object using
g_endpoint_config()as a temporary solution; I'd like to have Laurent's opinion on that though. Another option is to wait, but we've already waited a looong time (as in total).Laurent, do you have some input here? We have simple "2 cameras connected to one signal processor" situation here. We need some way of passing endpoint configuration from the sensors through the switch. I did this:
Could you give me a bit more information about the platform you're targeting:
how the switch is connected, what kind of switch it is, and what endpoint configuration data you need ?
Quoted 24 lines
Quoted 6 lines
include/media/v4l2-subdev.h struct v4l2_subdev_video_ops { · line 420
Quoted 6 lines
include/media/v4l2-subdev.h +2
-0@@ -415,6 +416,8 @@ struct v4l2_subdev_video_ops { const struct v4l2_mbus_config *cfg);int (*s_rx_buffer)(struct v4l2_subdev *sd,void *buf,unsigned int *size); +int (*g_endpoint_config)(struct v4l2_subdev *sd, +struct v4l2_of_endpoint *cfg);Google of
g_routingtells me:9) Highly reconfigurable hardware - Julien Beraud
- 44 sub-devices connected with an interconnect.
- As long as formats match, any sub-device could be connected to any
- other sub-device through a link.
- The result is 44 * 44 links at worst.
- A switch sub-device proposed as the solution to model the
- interconnect. The sub-devices are connected to the switch
- sub-devices through the hardware links that connect to the
- interconnect.
- The switch would be controlled through new IOCTLsS_ROUTINGand
-G_ROUTING.
- Patches available:
http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/log/?h=xilinx-wip
Quoted 1 line
but the patches are from 2005. So I guess I'll need some guidance here...
You made me feel very old for a moment. The patches are from 2015 :-)
Quoted 1 line
Quoted 1 line
I'll reply to the other patch containing the code.
Signature · 3 lines
Regards, Laurent Pinchart
Sakari Ailus
maintainerRe: [PATCH] devicetree: Add video bus switch
Quoted 91 lines · Laurent Pinchart
Hi Pavel,
Quoted 51 lines · On Saturday, 4 February 2017 23:56:10 EET Pavel Machek wrote:
Hi!
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Review
Quoted 4 lines
(quoted diff) +4
-0+Required properties +=================== + +compatible : must contain "video-bus-switch"How generic is this? Should we have e.g. nokia,video-bus-switch? And if so, change the file name accordingly.
Quoted 4 lines
Quoted 2 lines
Generic for "single GPIO controls the switch", AFAICT. But that should be common enough...
Um, yes. Then... how about: video-bus-switch-gpio? No Nokia prefix.
Ok, done. I also fixed the english a bit.
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Review
Quoted 4 lines
(quoted diff) +4
-0+reg : The interface: + 0 - port for image signal processor + 1 - port for first camera sensor + 2 - port for second camera sensorI'd say this must be pretty much specific to the one in N900. You could have more ports. Or you could say that ports beyond 0 are camera sensors. I guess this is good enough for now though, it can be changed later on with the source if a need arises.
Quoted 8 lines
Quoted 3 lines
Well, I'd say that selecting between two sensors is going to be the common case. If someone needs more than two, it will no longer be simple GPIO, so we'll have some fixing to do.
It could be two GPIOs --- that's how the GPIO I2C mux works.
But I'd be surprised if someone ever uses something like that again. ;-)
I'd say.. lets handle that when we see hardware like that.
Quoted 13 lines
Quoted 9 lines
Quoted 4 lines
Btw. was it still considered a problem that the endpoint properties for the sensors can be different? With the
g_routing()pad op which is to be added, the ISP driver (should actually go to a framework somewhere) could parse the graph and find the proper endpoint there.I don't know about
g_routing. I addedg_endpoint_configmethod that passes the configuration, and that seems to work for me.I don't see
g_routingin next-20170201 . Is there place to look?I think there was a patch by Laurent to LMML quite some time ago. I suppose that set will be repicked soonish.
Quoted 8 lines
Quoted 3 lines
I don't really object using
g_endpoint_config()as a temporary solution; I'd like to have Laurent's opinion on that though. Another option is to wait, but we've already waited a looong time (as in total).Laurent, do you have some input here? We have simple "2 cameras connected to one signal processor" situation here. We need some way of passing endpoint configuration from the sensors through the switch. I did this:
Could you give me a bit more information about the platform you're targeting:
how the switch is connected, what kind of switch it is, and what endpoint configuration data you need ?Quoted 24 lines
Quoted 6 lines
include/media/v4l2-subdev.h struct v4l2_subdev_video_ops { · line 420
Quoted 6 lines
include/media/v4l2-subdev.h +2
-0@@ -415,6 +416,8 @@ struct v4l2_subdev_video_ops { const struct v4l2_mbus_config *cfg);int (*s_rx_buffer)(struct v4l2_subdev *sd,void *buf,unsigned int *size); +int (*g_endpoint_config)(struct v4l2_subdev *sd, +struct v4l2_of_endpoint *cfg);Google of
g_routingtells me:9) Highly reconfigurable hardware - Julien Beraud
- 44 sub-devices connected with an interconnect.
- As long as formats match, any sub-device could be connected to any
- other sub-device through a link.
- The result is 44 * 44 links at worst.
- A switch sub-device proposed as the solution to model the
- interconnect. The sub-devices are connected to the switch
- sub-devices through the hardware links that connect to the
- interconnect.
- The switch would be controlled through new IOCTLsS_ROUTINGand
-G_ROUTING.
- Patches available:
http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/log/?h=xilinx-wip
Quoted 3 lines
Quoted 1 line
but the patches are from 2005. So I guess I'll need some guidance here...
You made me feel very old for a moment. The patches are from 2015 :-)
There are up-to-date patches here:
<URL:https://git.linuxtv.org/sailus/media_tree.git/log/?h=vc>
Signature · 6 lines
Sakari Ailus e-mail: [email protected] -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] devicetree: Add video bus switch
In reply to Laurent PinchartHi,
Quoted 58 lines · Laurent Pinchart
Hi Pavel,
Quoted 55 lines · On Saturday, 4 February 2017 23:56:10 EET Pavel Machek wrote:
Hi!
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Review
Quoted 4 lines
(quoted diff) +4
-0+Required properties +=================== + +compatible : must contain "video-bus-switch"How generic is this? Should we have e.g. nokia,video-bus-switch? And if so, change the file name accordingly.
Quoted 4 lines
Quoted 2 lines
Generic for "single GPIO controls the switch", AFAICT. But that should be common enough...
Um, yes. Then... how about: video-bus-switch-gpio? No Nokia prefix.
Ok, done. I also fixed the english a bit.
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Review
Quoted 4 lines
(quoted diff) +4
-0+reg : The interface: + 0 - port for image signal processor + 1 - port for first camera sensor + 2 - port for second camera sensorI'd say this must be pretty much specific to the one in N900. You could have more ports. Or you could say that ports beyond 0 are camera sensors. I guess this is good enough for now though, it can be changed later on with the source if a need arises.
Quoted 8 lines
Quoted 3 lines
Well, I'd say that selecting between two sensors is going to be the common case. If someone needs more than two, it will no longer be simple GPIO, so we'll have some fixing to do.
It could be two GPIOs --- that's how the GPIO I2C mux works.
But I'd be surprised if someone ever uses something like that again. ;-)
I'd say.. lets handle that when we see hardware like that.
Quoted 16 lines
Quoted 9 lines
Quoted 4 lines
Btw. was it still considered a problem that the endpoint properties for the sensors can be different? With the
g_routing()pad op which is to be added, the ISP driver (should actually go to a framework somewhere) could parse the graph and find the proper endpoint there.I don't know about
g_routing. I addedg_endpoint_configmethod that passes the configuration, and that seems to work for me.I don't see
g_routingin next-20170201 . Is there place to look?I think there was a patch by Laurent to LMML quite some time ago. I suppose that set will be repicked soonish.
I don't really object using
g_endpoint_config()as a temporary solution; I'd like to have Laurent's opinion on that though. Another option is to wait, but we've already waited a looong time (as in total).
Quoted 7 lines
Quoted 4 lines
Laurent, do you have some input here? We have simple "2 cameras connected to one signal processor" situation here. We need some way of passing endpoint configuration from the sensors through the switch. I did this:
Could you give me a bit more information about the platform you're targeting:
how the switch is connected, what kind of switch it is, and what endpoint
http://plan9.stanleylieber.com/hardware/n900/n900.schematics.pdf, on page 2, see N5801 and N5802.
Quoted 26 lines
configuration data you need ?
Quoted 24 lines
Quoted 6 lines
include/media/v4l2-subdev.h struct v4l2_subdev_video_ops { · line 420
Quoted 6 lines
include/media/v4l2-subdev.h +2
-0@@ -415,6 +416,8 @@ struct v4l2_subdev_video_ops { const struct v4l2_mbus_config *cfg);int (*s_rx_buffer)(struct v4l2_subdev *sd,void *buf,unsigned int *size); +int (*g_endpoint_config)(struct v4l2_subdev *sd, +struct v4l2_of_endpoint *cfg);Google of
g_routingtells me:9) Highly reconfigurable hardware - Julien Beraud
- 44 sub-devices connected with an interconnect.
- As long as formats match, any sub-device could be connected to any
- other sub-device through a link.
- The result is 44 * 44 links at worst.
- A switch sub-device proposed as the solution to model the
- interconnect. The sub-devices are connected to the switch
- sub-devices through the hardware links that connect to the
- interconnect.
- The switch would be controlled through new IOCTLsS_ROUTINGand
-G_ROUTING.
- Patches available:
http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/log/?h=xilinx-wip
Quoted 6 lines
Quoted 1 line
but the patches are from 2005. So I guess I'll need some guidance here...
You made me feel very old for a moment. The patches are from 2015 :-)
Quoted 1 line
Quoted 1 line
I'll reply to the other patch containing the code.
Regards,
Ivo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] devicetree: Add video bus switch
In reply to Laurent PinchartHi!
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
I don't really object using
g_endpoint_config()as a temporary solution; I'd like to have Laurent's opinion on that though. Another option is to wait, but we've already waited a looong time (as in total).
Quoted 8 lines
Quoted 4 lines
Laurent, do you have some input here? We have simple "2 cameras connected to one signal processor" situation here. We need some way of passing endpoint configuration from the sensors through the switch. I did this:
Could you give me a bit more information about the platform you're targeting:
how the switch is connected, what kind of switch it is, and what endpoint configuration data you need ?
Platform is Nokia N900, Ivaylo already gave pointer to schematics.
Switch is controlled using GPIO, and basically there's CSI configuration that would normally be in the device tree, but now we have two CSI configurations to select from...
Quoted 15 lines
Quoted 15 lines
9) Highly reconfigurable hardware - Julien Beraud
- 44 sub-devices connected with an interconnect.
- As long as formats match, any sub-device could be connected to any
- other sub-device through a link.
- The result is 44 * 44 links at worst.
- A switch sub-device proposed as the solution to model the
- interconnect. The sub-devices are connected to the switch
- sub-devices through the hardware links that connect to the
- interconnect.
- The switch would be controlled through new IOCTLsS_ROUTINGand
-G_ROUTING.
- Patches available:
http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/log/?h=xilinx-wip
Quoted 3 lines
Quoted 1 line
but the patches are from 2005. So I guess I'll need some guidance here...
You made me feel very old for a moment. The patches are from 2015 :-)
Sorry about that :-).
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH] devicetree: Add video bus switch
In reply to Pavel MachekQuoted 3 lines · On Friday 03 February 2017 13:35:08 Pavel Machek wrote:
N900 contains front and back camera, with a switch between the two. This adds support for the switch component, and it is now possible to select between front and back cameras during runtime.
IIRC for controlling cameras on N900 there are two GPIOs. Should not you have both in switch driver?
Signature · 2 lines
Pali Rohár [email protected]
Re: [PATCH] devicetree: Add video bus switch
Quoted 7 lines · Pali Rohár
Quoted 3 lines · On Friday 03 February 2017 13:35:08 Pavel Machek wrote:
N900 contains front and back camera, with a switch between the two. This adds support for the switch component, and it is now possible to select between front and back cameras during runtime.
IIRC for controlling cameras on N900 there are two GPIOs. Should not you have both in switch driver?
I guess you recall wrongly :-). Switch seems to work. The issue was with switch GPIO also serving as reset GPIO for one sensor, or something like that, if _I_ recall correctly ;-).
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: [PATCH] devicetree: Add video bus switch
Hi,
Quoted 6 lines · Pavel Machek
Quoted 5 lines · Pali Rohár
Quoted 3 lines · On Friday 03 February 2017 13:35:08 Pavel Machek wrote:
N900 contains front and back camera, with a switch between the two. This adds support for the switch component, and it is now possible to select between front and back cameras during runtime.
Quoted 6 lines
Quoted 2 lines
IIRC for controlling cameras on N900 there are two GPIOs. Should not you have both in switch driver?
I guess you recall wrongly :-). Switch seems to work. The issue was with switch GPIO also serving as reset GPIO for one sensor, or something like that, if _I_ recall correctly ;-).
I have a schematic in my master thesis, which shows how the camera sensors are connected to the SoC. The PDF is available here:
The schematic is on page 37 (or 45 if your PDF reader does not use different numbers for the preamble stuff).
--Sebastian
Rob Herring
maintainerRe: [PATCH] devicetree: Add video bus switch
In reply to Pavel MachekQuoted 18 lines · Pavel Machek
N900 contains front and back camera, with a switch between the two. This adds support for the switch component, and it is now possible to select between front and back cameras during runtime.
This adds documentation for the devicetree binding.
Signed-off-by Sebastian Reichel <[email protected]>Signed-off-by Ivaylo Dimitrov <[email protected]>Signed-off-by Pavel Machek <[email protected]>Documentation/devicetree/bindings/media/video-bus-switch.txt new file +0
-0
Documentation/devicetree/bindings/media/video-bus-switch.txt line 2
Quoted 2 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt new file +2
-0@@ -0,0 +1,63 @@ +Video Bus Switch Binding +========================
I'd call it a mux rather than switch.
BTW, there's a new mux-controller binding under review you might look at. It would only be needed here if the mux ctrl also controls other things.
Documentation/devicetree/bindings/media/video-bus-switch.txt line 11
Quoted 9 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt new file +9
-0+ +This is a binding for a gpio controlled switch for camera interfaces. Such a +device is used on some embedded devices to connect two cameras to the same +interface of a image signal processor. + +Required properties +=================== + +compatible : must contain "video-bus-switch"
video-bus-gpio-mux
Documentation/devicetree/bindings/media/video-bus-switch.txt line 12
Quoted 1 line
Documentation/devicetree/bindings/media/video-bus-switch.txt new file +1
-0+switch-gpios : GPIO specifier for the gpio, which can toggle the
mux-gpios to align with existing GPIO controlled muxes.
Quoted 4 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt new file +4
-0+ selected camera. The GPIO should be configured, so + that a disabled GPIO means, that the first port is + selected. +
Documentation/devicetree/bindings/media/video-bus-switch.txt line 26
Quoted 10 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt new file +10
-0+Required Port nodes +=================== + +More documentation on these bindings is available in +video-interfaces.txt in the same directory. + +reg : The interface: + 0 - port for image signal processor + 1 - port for first camera sensor + 2 - port for second camera sensor
This could be used for display side as well. So describe these just as inputs and outputs.
Rob
Re: [PATCH] devicetree: Add video bus switch
Quoted 13 lines · Rob Herring
Quoted 12 lines · Pavel Machek
N900 contains front and back camera, with a switch between the two. This adds support for the switch component, and it is now possible to select between front and back cameras during runtime.
This adds documentation for the devicetree binding.
Signed-off-by Sebastian Reichel <[email protected]>Signed-off-by Ivaylo Dimitrov <[email protected]>Signed-off-by Pavel Machek <[email protected]>
Quoted 10 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt line 2
Quoted 8 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt new file +2
-0@@ -0,0 +1,63 @@ +Video Bus Switch Binding +========================I'd call it a mux rather than switch.
It is a switch, not a multiplexor (
https://en.wikipedia.org/wiki/Multiplexing ). Only one camera can operate at a time.
Quoted 3 lines
BTW, there's a new mux-controller binding under review you might look at. It would only be needed here if the mux ctrl also controls other things.
Do you have a pointer?
Quoted 5 lines
Quoted 5 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt new file +5
-0+Required Port nodes +=================== + +More documentation on these bindings is available in +video-interfaces.txt in the same directory.
Quoted 8 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt line 26
Quoted 5 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt new file +5
-0+ +reg : The interface: + 0 - port for image signal processor + 1 - port for first camera sensor + 2 - port for second camera sensorThis could be used for display side as well. So describe these just as inputs and outputs.
I'd prefer not to confuse people. I guess that would be 0 -- output port, 1, 2 -- input ports... But this is media data, are you sure it is good idea to change this?
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Rob Herring
maintainerRe: [PATCH] devicetree: Add video bus switch
Quoted 25 lines · Pavel Machek
Quoted 13 lines · Rob Herring
Quoted 12 lines · Pavel Machek
N900 contains front and back camera, with a switch between the two. This adds support for the switch component, and it is now possible to select between front and back cameras during runtime.
This adds documentation for the devicetree binding.
Signed-off-by Sebastian Reichel <[email protected]>Signed-off-by Ivaylo Dimitrov <[email protected]>Signed-off-by Pavel Machek <[email protected]>Quoted 10 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt line 2
Quoted 8 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt new file +2
-0@@ -0,0 +1,63 @@ +Video Bus Switch Binding +========================I'd call it a mux rather than switch.
Quoted 3 lines
It is a switch, not a multiplexor (
https://en.wikipedia.org/wiki/Multiplexing ). Only one camera can operate at a time.
It's no different than an i2c mux. It's one at a time.
Quoted 6 lines
Quoted 4 lines
BTW, there's a new mux-controller binding under review you might look at. It would only be needed here if the mux ctrl also controls other things.
Do you have a pointer?
Let me Google that for you:
Quoted 15 lines
Quoted 14 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt line 26
Quoted 11 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt new file +10
-0+Required Port nodes +=================== + +More documentation on these bindings is available in +video-interfaces.txt in the same directory. + +reg : The interface: + 0 - port for image signal processor + 1 - port for first camera sensor + 2 - port for second camera sensorThis could be used for display side as well. So describe these just as inputs and outputs.
Quoted 3 lines
I'd prefer not to confuse people. I guess that would be 0 -- output port, 1, 2 -- input ports... But this is media data, are you sure it is good idea to change this?
And I'd prefer something that can be reused by others.
Quoted 5 lines
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Rob Herring
maintainerRe: [PATCH] devicetree: Add video bus switch
Quoted 33 lines · Rob Herring
Quoted 25 lines · Pavel Machek
Quoted 13 lines · Rob Herring
Quoted 12 lines · Pavel Machek
N900 contains front and back camera, with a switch between the two. This adds support for the switch component, and it is now possible to select between front and back cameras during runtime.
This adds documentation for the devicetree binding.
Signed-off-by Sebastian Reichel <[email protected]>Signed-off-by Ivaylo Dimitrov <[email protected]>Signed-off-by Pavel Machek <[email protected]>Quoted 10 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt line 2
Quoted 8 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt new file +2
-0@@ -0,0 +1,63 @@ +Video Bus Switch Binding +========================I'd call it a mux rather than switch.
Quoted 3 lines
It is a switch, not a multiplexor (
https://en.wikipedia.org/wiki/Multiplexing ). Only one camera can operate at a time.It's no different than an i2c mux. It's one at a time.
Quoted 1 line
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
BTW, there's a new mux-controller binding under review you might look at. It would only be needed here if the mux ctrl also controls other things.
Do you have a pointer?
Let me Google that for you:
https://lwn.net/Articles/713971/
Quoted 27 lines
Quoted 16 lines
Quoted 15 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt line 26
Quoted 12 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt new file +10
-0+Required Port nodes +=================== + +More documentation on these bindings is available in +video-interfaces.txt in the same directory. + +reg : The interface: + 0 - port for image signal processor + 1 - port for first camera sensor + 2 - port for second camera sensorThis could be used for display side as well. So describe these just as inputs and outputs.
Quoted 3 lines
I'd prefer not to confuse people. I guess that would be 0 -- output port, 1, 2 -- input ports... But this is media data, are you sure it is good idea to change this?
And I'd prefer something that can be reused by others.
Quoted 5 lines
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH] devicetree: Add video bus switch
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt line 2
Quoted 9 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt new file +2
-0@@ -0,0 +1,63 @@ +Video Bus Switch Binding +========================I'd call it a mux rather than switch.
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
It is a switch, not a multiplexor (
https://en.wikipedia.org/wiki/Multiplexing ). Only one camera can operate at a time.It's no different than an i2c mux. It's one at a time.
Take a look at the wikipedia. If you do "one at a time" at 100Hz, you can claim it is time-domain multiplex. But we are plain switching the cameras. It takes second (or so) to setup the pipeline.
This is not multiplex.
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: [PATCH] devicetree: Add video bus switch
Hi Pavel,
Quoted 16 lines · Pavel Machek
Quoted 16 lines
Quoted 16 lines
Quoted 15 lines
Quoted 11 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt line 2
Quoted 9 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt new file +2
-0@@ -0,0 +1,63 @@ +Video Bus Switch Binding +========================I'd call it a mux rather than switch.
It is a switch, not a multiplexor (
https://en.wikipedia.org/wiki/Multiplexing ). Only one camera can operate at a time.
Quoted 7 lines
Quoted 1 line
Quoted 1 line
It's no different than an i2c mux. It's one at a time.
Take a look at the wikipedia. If you do "one at a time" at 100Hz, you can claim it is time-domain multiplex. But we are plain switching the cameras. It takes second (or so) to setup the pipeline.
This is not multiplex.
The functionality is still the same, isn't it? Does it change what it is if the frequency might be 100 Hz or 0,01 Hz?
I was a bit annoyed for having to have two drivers for switching the source (one for GPIO, another for syscon / register), where both of the drivers would be essentially the same with the minor exception of having a slightly different means to toggle the mux setting.
The MUX framework adds an API for controlling the MUX. Thus we'll need only a single driver that uses the MUX framework API for V4L2. As an added bonus, V4L2 would be in line with the rest of the MUX usage in the kernel.
The set appears to already contain a GPIO MUX. What's needed would be to use the MUX API instead of direct GPIOs usage.
Signature · 8 lines
Kind regards, Sakari Ailus e-mail: [email protected] XMPP: [email protected] -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] devicetree: Add video bus switch
Hi!
Quoted 8 lines
Quoted 5 lines
Take a look at the wikipedia. If you do "one at a time" at 100Hz, you can claim it is time-domain multiplex. But we are plain switching the cameras. It takes second (or so) to setup the pipeline.
This is not multiplex.
The functionality is still the same, isn't it? Does it change what it is if the frequency might be 100 Hz or 0,01 Hz?
Well. In your living your you can have a switch, which is switch at much less than 0.01Hz. You can also have a dimmer, which is a PWM, which is switch at 100Hz or so. So yes, I'd say switch and mux are different things.
Quoted 4 lines
I was a bit annoyed for having to have two drivers for switching the source (one for GPIO, another for syscon / register), where both of the drivers would be essentially the same with the minor exception of having a slightly different means to toggle the mux setting.
Well, most of the video-bus-switch is the video4linux glue. Actual switching is very very small part. So.. where is the other driver? Looks like we have the same problem.
Quoted 6 lines
The MUX framework adds an API for controlling the MUX. Thus we'll need only a single driver that uses the MUX framework API for V4L2. As an added bonus, V4L2 would be in line with the rest of the MUX usage in the kernel.
The set appears to already contain a GPIO MUX. What's needed would be to use the MUX API instead of direct GPIOs usage.
If there's a driver that already does switching for video4linux devices? Do you have a pointer?
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: [PATCH] devicetree: Add video bus switch
Hi Pavel,
Quoted 8 lines · Pavel Machek
Hi!
Quoted 6 lines
Quoted 5 lines
Take a look at the wikipedia. If you do "one at a time" at 100Hz, you can claim it is time-domain multiplex. But we are plain switching the cameras. It takes second (or so) to setup the pipeline.
This is not multiplex.
Quoted 7 lines
Quoted 2 lines
The functionality is still the same, isn't it? Does it change what it is if the frequency might be 100 Hz or 0,01 Hz?
Well. In your living your you can have a switch, which is switch at much less than 0.01Hz. You can also have a dimmer, which is a PWM, which is switch at 100Hz or so. So yes, I'd say switch and mux are different things.
Light switches are mostly on/off switches. It'd be interesting to have a light switch that you could use to light either of the light bulbs in a room but not to switch both of them on at the same time. Or off... :-)
I wonder if everyone would be happy with a statement saying that it's a on / on switch which is used to implement a multiplexer?
Quoted 9 lines
Quoted 5 lines
I was a bit annoyed for having to have two drivers for switching the source (one for GPIO, another for syscon / register), where both of the drivers would be essentially the same with the minor exception of having a slightly different means to toggle the mux setting.
Well, most of the video-bus-switch is the video4linux glue. Actual switching is very very small part. So.. where is the other driver? Looks like we have the same problem.
It's here, slightly hidden in plain sight in the same patch with the MUX framework:
<URL:https://www.mail-archive.com/[email protected]/msg1328763.html>
Quoted 10 lines
Quoted 7 lines
The MUX framework adds an API for controlling the MUX. Thus we'll need only a single driver that uses the MUX framework API for V4L2. As an added bonus, V4L2 would be in line with the rest of the MUX usage in the kernel.
The set appears to already contain a GPIO MUX. What's needed would be to use the MUX API instead of direct GPIOs usage.
If there's a driver that already does switching for video4linux devices? Do you have a pointer?
I don't think there's one. But with MUX API, we'll be fine using a single driver instead of two (other one for syscon on iMX).
Cc Steve and Philipp.
Signature · 8 lines
Kind regards, Sakari Ailus e-mail: [email protected] XMPP: [email protected] -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] devicetree: Add video bus switch
Quoted 19 lines · Sakari Ailus
Hi Pavel,
Quoted 8 lines · Pavel Machek
Hi!
Quoted 6 lines
Quoted 5 lines
Take a look at the wikipedia. If you do "one at a time" at 100Hz, you can claim it is time-domain multiplex. But we are plain switching the cameras. It takes second (or so) to setup the pipeline.
This is not multiplex.
Quoted 7 lines
Quoted 2 lines
The functionality is still the same, isn't it? Does it change what it is if the frequency might be 100 Hz or 0,01 Hz?
Well. In your living your you can have a switch, which is switch at much less than 0.01Hz. You can also have a dimmer, which is a PWM, which is switch at 100Hz or so. So yes, I'd say switch and mux are different things.
Quoted 6 lines
Light switches are mostly on/off switches. It'd be interesting to have a light switch that you could use to light either of the light bulbs in a room but not to switch both of them on at the same time. Or off... :-)
I wonder if everyone would be happy with a statement saying that it's a on / on switch which is used to implement a multiplexer?
I believe the difference is the timescale. If it switches "slow" it is a switch. If it switches fast, it is a dimmer, mux, or something....
Anyway, someone else was faster, so they get to name their creation...
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH] devicetree: Add video bus switch
In reply to Rob HerringQuoted 11 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt line 11
Quoted 9 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt new file +9
-0+ +This is a binding for a gpio controlled switch for camera interfaces. Such a +device is used on some embedded devices to connect two cameras to the same +interface of a image signal processor. + +Required properties +=================== + +compatible : must contain "video-bus-switch"video-bus-gpio-mux
Sakari already asked for rename here. I believe I waited reasonable time, but got no input from you, so I did rename it. Now you decide on different name.
Can we either get timely reactions or less bikeshedding?
Thanks,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Rob Herring
maintainerRe: [PATCH] devicetree: Add video bus switch
Quoted 12 lines · Pavel Machek
Quoted 11 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt line 11
Quoted 9 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt new file +9
-0+ +This is a binding for a gpio controlled switch for camera interfaces. Such a +device is used on some embedded devices to connect two cameras to the same +interface of a image signal processor. + +Required properties +=================== + +compatible : must contain "video-bus-switch"video-bus-gpio-mux
Quoted 5 lines
Sakari already asked for rename here. I believe I waited reasonable time, but got no input from you, so I did rename it. Now you decide on different name.
Can we either get timely reactions or less bikeshedding?
You mean less than 5 days because I don't see any other version of this? But in short, no, you can't.
Rob
Re: [PATCH] devicetree: Add video bus switch
Quoted 13 lines · Rob Herring
Quoted 12 lines · Pavel Machek
Quoted 11 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt line 11
Quoted 9 lines
Documentation/devicetree/bindings/media/video-bus-switch.txt new file +9
-0+ +This is a binding for a gpio controlled switch for camera interfaces. Such a +device is used on some embedded devices to connect two cameras to the same +interface of a image signal processor. + +Required properties +=================== + +compatible : must contain "video-bus-switch"video-bus-gpio-mux
Quoted 8 lines
Quoted 5 lines
Sakari already asked for rename here. I believe I waited reasonable time, but got no input from you, so I did rename it. Now you decide on different name.
Can we either get timely reactions or less bikeshedding?
You mean less than 5 days because I don't see any other version of this? But in short, no, you can't.
Could we switch device tree bindings from "cc: subsystem, to: device tree" to "to: subsystem, cc: device tree" mode? Currently it takes more effort to merge the device tree parts than the relevant driver, and that is not quite good.
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
Sakari Ailus
maintainerQuoted 6 lines · 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 <[email protected]>Signed-off-by Pavel Machek <[email protected]>
Thanks!
I fixed a few checkpatch warnings and one or two minor matters, the diff is here. No functional changes. I'm a bit surprised checkpatch.pl suggests to use numerical values for permissions but I think I agree with that. Reason is prioritised agains the rules. :-)
Btw. should we update maintainers as well? Would you like to put yourself there? Feel free to add me, too...
The patches are here. I think they should be good to go to v4.11.
<URL:https://git.linuxtv.org/sailus/media_tree.git/log/?h=et8ek8>
Let me know if you're (not) happy with these:
drivers/media/i2c/et8ek8/et8ek8_driver.c +15 -15
@@ -347,13 +347,13 @@ static int et8ek8_i2c_write_reg(struct i2c_client *client, u16 data_length,et8ek8_i2c_create_msg (client, data_length, reg, val, &msg, data); r =i2c_transfer (client->adapter, &msg,1 ); -if (r <0 ) +if (r <0 ) {dev_err (&client->dev,"wrote 0x%x to offset 0x%x error %d\n" , val, reg, r); -else - r =0 ;/* on success i2c_transfer() returns messages trasfered */ +return r; + } -return r; +return 0 ; } static struct et8ek8_reglist *et8ek8_reglist_find_type(
@@ -620,14 +620,13 @@ static int et8ek8_set_test_pattern(struct et8ek8_sensor *sensor, s32 mode) rval =et8ek8_i2c_write_reg (client,ET8EK8_REG_8BIT ,0x1124 , cbv_mode <<7 );if (rval) -return rval; +return rval; rval =et8ek8_i2c_write_reg (client,ET8EK8_REG_8BIT ,0x112C , din_sw);if (rval)return rval; - rval =et8ek8_i2c_write_reg (client,ET8EK8_REG_8BIT ,0x1420 , r1420); -return rval; +return et8ek8_i2c_write_reg (client,ET8EK8_REG_8BIT ,0x1420 , r1420); }/* -----------------------------------------------------------------------------
@@ -645,11 +644,11 @@ static int et8ek8_set_ctrl(struct v4l2_ctrl *ctrl)case V4L2_CID_EXPOSURE : { -int rows; -struct i2c_client *client =v4l2_get_subdevdata (&sensor->subdev); - rows = ctrl->val; +struct i2c_client *client = +v4l2_get_subdevdata (&sensor->subdev); +return et8ek8_i2c_write_reg (client,ET8EK8_REG_16BIT ,0x1243 , - rows); + ctrl->val); }case V4L2_CID_TEST_PATTERN :
@@ -695,8 +694,9 @@ static int et8ek8_init_controls(struct et8ek8_sensor *sensor)u32 min =1 , max = max_rows; sensor->exposure = -v4l2_ctrl_new_std (&sensor->ctrl_handler, &et8ek8_ctrl_ops, -V4L2_CID_EXPOSURE , min, max, min, max); +v4l2_ctrl_new_std (&sensor->ctrl_handler, + &et8ek8_ctrl_ops,V4L2_CID_EXPOSURE , + min, max, min, max); }/* V4L2_CID_PIXEL_RATE */
@@ -722,7 +722,7 @@ static void et8ek8_update_controls(struct et8ek8_sensor *sensor) {struct v4l2_ctrl *ctrl;struct et8ek8_mode *mode = &sensor->current_reglist->mode; - +u32 min, max, pixel_rate;static const int S =8 ;
@@ -1248,7 +1248,7 @@ et8ek8_priv_mem_read(struct device *dev, struct device_attribute *attr,return ET8EK8_PRIV_MEM_SIZE ; } -static DEVICE_ATTR(priv_mem, S_IRUGO, et8ek8_priv_mem_read, NULL); +static DEVICE_ATTR(priv_mem, 0444, et8ek8_priv_mem_read, NULL);/* -------------------------------------------------------------------------- * V4L2 subdev core operations
Signature · 4 lines
Kind regards, Sakari Ailus e-mail: [email protected] XMPP: [email protected]
Hi!
Quoted 8 lines · Sakari Ailus
Quoted 6 lines · 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 <[email protected]>Signed-off-by Pavel Machek <[email protected]>
Quoted 6 lines
Thanks!
I fixed a few checkpatch warnings and one or two minor matters, the diff is here. No functional changes. I'm a bit surprised checkpatch.pl suggests to use numerical values for permissions but I think I agree with that. Reason is prioritised agains the rules. :-)
Yeah, there was big flamewar about the permissions. In the end Linus decided that everyone knows the octal numbers, but the constants are tricky. It began with patch series with 1000 patches...
Quoted 2 lines
Btw. should we update maintainers as well? Would you like to put yourself there? Feel free to add me, too...
Ok, will do.
Quoted 5 lines
The patches are here. I think they should be good to go to v4.11.
<URL:https://git.linuxtv.org/sailus/media_tree.git/log/?h=et8ek8>
Let me know if you're (not) happy with these:
Happy, thanks for doing that. And looking forward for v4.11 :-).
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
PATCH 1/1 mark myself as mainainer for camera on N900
Mark and Sakari as maintainers for Nokia N900 camera pieces.
---
Hi!
Quoted 8 lines
Yeah, there was big flamewar about the permissions. In the end Linus decided that everyone knows the octal numbers, but the constants are tricky. It began with patch series with 1000 patches...
Quoted 2 lines
Btw. should we update maintainers as well? Would you like to put yourself there? Feel free to add me, too...
Ok, will do.
Something like this? Actually, I guess we could merge ADP1653 entry there. Yes, it is random collection of devices, but are usually tested "together", so I believe one entry makes sense.
(But I have no problem with having multiple entries, too.)
Thanks,
Pavel
MAINTAINERS +8 -0
@@ -8613,6 +8613,14 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/lftan/nios2.git S: Maintained F: arch/nios2/ +NOKIA N900 CAMERA SUPPORT (ET8EK8 SENSOR, AD5820 FOCUS) +M: Pavel Machek <[email protected]> +M: Sakari Ailus <[email protected]> +L: [email protected] +S: Maintained +F: drivers/media/i2c/et8ek8 +F: drivers/media/i2c/ad5820.c + NOKIA N900 POWER SUPPLY DRIVERS R: Pali Rohár <[email protected]> F: include/linux/power/bq2415x_charger.h
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH] mark myself as mainainer for camera on N900
Hi,
Quoted 1 line · Pavel Machek
Mark and Sakari as maintainers for Nokia N900 camera pieces.
^^^ missing me after Mark. Otherwise Mark looks like a name :)
Quoted 30 lines
Signed-off-by Pavel Machek <[email protected]>---
Hi!
Quoted 8 lines
Yeah, there was big flamewar about the permissions. In the end Linus decided that everyone knows the octal numbers, but the constants are tricky. It began with patch series with 1000 patches...
Quoted 2 lines
Btw. should we update maintainers as well? Would you like to put yourself there? Feel free to add me, too...
Ok, will do.
Something like this? Actually, I guess we could merge ADP1653 entry there. Yes, it is random collection of devices, but are usually tested "together", so I believe one entry makes sense.
(But I have no problem with having multiple entries, too.)
Thanks,
PavelMAINTAINERS +0
-0
MAINTAINERS T: git git://git.kernel.org/pub/scm/linux/kernel/git/lftan/nios2.git · line 8622
Quoted 10 lines
MAINTAINERS +7
-0@@ -8613,6 +8613,14 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/lftan/nios2.git S: Maintained F: arch/nios2/ +NOKIA N900 CAMERA SUPPORT (ET8EK8 SENSOR, AD5820 FOCUS) +M: Pavel Machek <[email protected]> +M: Sakari Ailus <[email protected]> +L: [email protected] +S: Maintained +F: drivers/media/i2c/et8ek8 +F: drivers/media/i2c/ad5820.c
Not sure if this is useful information, but I solved it like this for N900 power supply drivers:
NOKIA N900 POWER SUPPLY DRIVERS
R: Pali Rohár <[email protected]>
F: include/linux/power/bq2415x_charger.h
F: include/linux/power/bq27xxx_battery.h
F: include/linux/power/isp1704_charger.h
F: drivers/power/supply/bq2415x_charger.c
F: drivers/power/supply/bq27xxx_battery.c
F: drivers/power/supply/bq27xxx_battery_i2c.c
F: drivers/power/supply/isp1704_charger.c
F: drivers/power/supply/rx51_battery.c
TI BQ27XXX POWER SUPPLY DRIVER
R: Andrew F. Davis <[email protected]>
F: include/linux/power/bq27xxx_battery.h
F: drivers/power/supply/bq27xxx_battery.c
F: drivers/power/supply/bq27xxx_battery_i2c.c
POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
M: Sebastian Reichel <[email protected]>
L: [email protected]
T: git git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git
S: Maintained
F: Documentation/devicetree/bindings/power/supply/
F: include/linux/power_supply.h
F: drivers/power/supply/
This makes it quite easy to see who applies patches and who should be Cc'd for what reason:
$ ./scripts/get_maintainer.pl -f drivers/power/supply/bq27xxx_battery.c "Pali Rohár" <[email protected]> (reviewer:NOKIA N900 POWER SUPPLY DRIVERS) "Andrew F. Davis" <[email protected]> (reviewer:TI BQ27XXX POWER SUPPLY DRIVER) Sebastian Reichel <[email protected]> (maintainer:POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS) [email protected] (open list:POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS) [email protected] (open list)
-- Sebastian
Sakari Ailus
maintainerRe: [PATCH] mark myself as mainainer for camera on N900
Hi Sebastian and Pavel,
Quoted 80 lines · Sebastian Reichel
Hi,
Quoted 1 line · Pavel Machek
Mark and Sakari as maintainers for Nokia N900 camera pieces.
^^^ missing me after Mark. Otherwise Mark looks like a name :)
Quoted 30 lines
Signed-off-by Pavel Machek <[email protected]>---
Hi!
Quoted 8 lines
Yeah, there was big flamewar about the permissions. In the end Linus decided that everyone knows the octal numbers, but the constants are tricky. It began with patch series with 1000 patches...
Quoted 2 lines
Btw. should we update maintainers as well? Would you like to put yourself there? Feel free to add me, too...
Ok, will do.
Something like this? Actually, I guess we could merge ADP1653 entry there. Yes, it is random collection of devices, but are usually tested "together", so I believe one entry makes sense.
(But I have no problem with having multiple entries, too.)
Thanks,
PavelMAINTAINERS +0
-0MAINTAINERS T: git git://git.kernel.org/pub/scm/linux/kernel/git/lftan/nios2.git · line 8622
Quoted 10 lines
MAINTAINERS +7
-0@@ -8613,6 +8613,14 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/lftan/nios2.git S: Maintained F: arch/nios2/ +NOKIA N900 CAMERA SUPPORT (ET8EK8 SENSOR, AD5820 FOCUS) +M: Pavel Machek <[email protected]> +M: Sakari Ailus <[email protected]> +L: [email protected] +S: Maintained +F: drivers/media/i2c/et8ek8 +F: drivers/media/i2c/ad5820.cNot sure if this is useful information, but I solved it like this for N900 power supply drivers:
NOKIA N900 POWER SUPPLY DRIVERS
R: Pali Rohár <[email protected]>
F:include/linux/power/bq2415x_charger.h
F:include/linux/power/bq27xxx_battery.h
F:include/linux/power/isp1704_charger.h
F:drivers/power/supply/bq2415x_charger.c
F:drivers/power/supply/bq27xxx_battery.c
F:drivers/power/supply/bq27xxx_battery_i2c.c
F:drivers/power/supply/isp1704_charger.c
F:drivers/power/supply/rx51_battery.cTI BQ27XXX POWER SUPPLY DRIVER
R: Andrew F. Davis <[email protected]>
F:include/linux/power/bq27xxx_battery.h
F:drivers/power/supply/bq27xxx_battery.c
F:drivers/power/supply/bq27xxx_battery_i2c.cPOWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
M: Sebastian Reichel <[email protected]>
L: [email protected]
T: gitgit://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git
S: Maintained
F:Documentation/devicetree/bindings/power/supply/
F:include/linux/power_supply.h
F:drivers/power/supply/This makes it quite easy to see who applies patches and who should be Cc'd for what reason:
Quoted 6 lines
$ ./scripts/get_maintainer.pl -f drivers/power/supply/bq27xxx_battery.c "Pali Rohár" <[email protected]> (reviewer:NOKIA N900 POWER SUPPLY DRIVERS) "Andrew F. Davis" <[email protected]> (reviewer:TI BQ27XXX POWER SUPPLY DRIVER) Sebastian Reichel <[email protected]> (maintainer:POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS) [email protected] (open list:POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS) [email protected] (open list)
I'm adding Pavel's patch to my tree and then send a pull req to Mauro. If further changes are needed then let's write more patches.
Signature · 2 lines
Sakari Ailus e-mail: [email protected] XMPP: [email protected]