Re: [RFC v3] [RFC] v4l2: Support for multiple selections
Hi Ricardo, I am the designer of selection API. I hope I can help you a little. I think that there are two issues mixed in 'Mulitple selections' topic. Firstly, you described that you program a piece of hardware that is capable of selecting 8 areas for scanning. Now you are looking for userspace API to support such a feature. The feature of posting multiple rectangle was proposed in this RFC. Secondly, You introduced struct v4l2_ext_rect which is a future-proof version of v4l2_rect. I think that both issues should be solved in two separate patchsets. Ad 1. The selection of multiple scanning areas is a very driver-specific feature, isn't it? I think that you do not need to introduce any abstract interface. What would be other applications of the proposed interface? Do you know other drivers that may need it? Sakari mentioned introduction of private targets for selections. I like this idea. Just define: #define V4L2_SEL_TGT_PRIVATE 0x8000 All targets that are = V4L2_SEL_TGT_PRIVATE are driver-specific. Generic applications must not use them. Non-generic application must check out the driver of video node before using selections from private set. If some target becomes more useful and accepted by more then one driver then it can be moved to generic API. The good thing about private target is that enums from different drivers can collide so the target space is not going to be trashed. But how to deal with multiple rectangles? I have an auxiliary question. Do you have to set all rectangles at once? can you set up them one by one? Anyway, first try to define something like this: #define V4L2_SEL_TGT_XXX_SCANOUT0 V4L2_SEL_TGT_PRIVATE #define V4L2_SEL_TGT_XXX_SCANOUT0_DEFAULT (V4L2_SEL_TGT_XXX_SCANOUT0 + 1) #define V4L2_SEL_TGT_XXX_SCANOUT0_BOUNDS (V4L2_SEL_TGT_XXX_SCANOUT0 + 2) #define V4L2_SEL_TGT_XXX_SCANOUT0 (V4L2_SEL_TGT_PRIVATE + 16) ... -- OR-- parametrized macros similar to one below: #define V4L2_SEL_TGT_XXX_SCANOUT(n) (V4L2_SEL_TGT_PRIVATE + 16 * (n)) The application could setup all scanout areas one-by-one. By default V4L2_SEL_TGT_XXX_SCANOUT0 would be equal to the whole array. The height of all consecutive area would be 0. This means disabling them effectively. The change of V4L2_SEL_TGT_XXX_SCANOUT0 would influence all consequtive rectangle by shifting them down or resetting them to height 0. Notice that as long as targets are driver specific you are free do define interaction between the targets. I hope that proposed solution is satisfactory. BTW. I think that the HW trick you described is not cropping. By cropping you select which part of sensor area is going to be processed into compose rectangle in a buffer. So technicaly you still insert the whole sensor area into the buffer. Only part of the buffer is actually updated. So there is no cropping (cropping area is equal to the whole array). Notice, that every 'cropping' area goes to different part of a buffer. So you would need also muliple targets for composing (!!!) and very long chapter in V4L2 doc describing interactions between muliple-rectangle crops and compositions. Good luck !!! :). Currently it is a hell to understand and define interaction between single crop, and compose and unfamous VIDIOC_S_FMT and m2m madness. I strongly recommend to use private selections. It will be much simpler to define, implement, and modify if needed. BTW2. I think that the mulitple scanout areas can be modelled using media device API. Sakari may know how to do this. Ad 2. Extended rectangles. It is a good idea because v4l2_rect lacks any place for extensions. But before adding it to V4L2 API, I would like to know the examples of actual applications. Please, point drivers that actually need it. Other thing worth mentioning is reservation of few bits from v4l2_selection::flags to describe the type of data used for rectangle, v4l2_rect or v4l2_ext_rect. This way one can avoid introducting v4l2_selection::rectangles field. I hope you find this comments useful. Regards, Tomasz Stanislawski -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFR 2/2] drm/panel: Add simple panel support
Hi Tomi,
On Thursday 17 October 2013 15:32:29 Tomi Valkeinen wrote:
On 17/10/13 15:17, Laurent Pinchart wrote:
On Thursday 17 October 2013 14:59:41 Tomi Valkeinen wrote:
On 17/10/13 14:51, Laurent Pinchart wrote:
I'm not sure if there's a specific need for the port or endpoint nodes
in cases like the above. Even if we have common properties describing
the endpoint, I guess they could just be in the parent node.
panel {
remote = dc;
common-video-property = asd;
};
The above would imply one port and one endpoint. Would that work? If we
had a function like parse_endpoint(node), we could just point it to
either a real endpoint node, or to the device's node.
You reference the display controller here, not a specific display
controller output. Don't most display controllers have several outputs ?
Sure. Then the display controller could have more verbose description.
But the panel could still have what I wrote above, except the 'remote'
property would point to a real endpoint node inside the dispc node, not
to the dispc node.
This would, of course, need some extra code to handle the different
cases, but just from DT point of view, I think all the relevant
information is there.
There's many ways to describe the same information in DT. While we could
have DT bindings that use different descriptions for different devices
and still support all of them in our code, why should we opt for that
option that will make the implementation much more complex when we can
describe connections in a simple and generic way ?
My suggestion was simple and generic. I'm not proposing per-device
custom bindings.
My point was, if we can describe the connections as I described above,
which to me sounds possible, we can simplify the panel DT data for 99.9%
of the cases.
To me, the first of these looks much nicer:
panel {
remote = remote-endpoint;
common-video-property = asd;
};
panel {
port {
endpoint {
remote = remote-endpoint;
common-video-property = asd;
};
};
};
Please note that the common video properties would be in the panel node, not
in the endpoint node (unless you have specific requirements to do so, which
isn't the common case).
If that can be supported in the SW by adding complexity to a few functions,
and it covers practically all the panels, isn't it worth it?
Note that I have not tried this, so I don't know if there are issues.
It's just a thought. Even if there's need for a endpoint node, perhaps
the port node can be made optional.
It can be worth it, as long as we make sure that simplified bindings cover the
needs of the generic code.
We could assume that, if the port subnode isn't present, the device will have
a single port, with a single endpoint. However, isn't the number of endpoints
a system property rather than a device property ? If a port of a device is
connected to two remote ports it will require two endpoints. We could select
the simplified or full bindings based on the system topology though.
I've CC'ed Sylwester Nawrocki and Guennadi Liakhovetski, the V4L2 DT bindings
authors, as well as the linux-media list, to get their opinion on this.
--
Regards,
Laurent Pinchart
signature.asc
Description: This is a digitally signed message part.
Re: [RFR 2/2] drm/panel: Add simple panel support
On 24/10/13 13:40, Laurent Pinchart wrote:
panel {
remote = remote-endpoint;
common-video-property = asd;
};
panel {
port {
endpoint {
remote = remote-endpoint;
common-video-property = asd;
};
};
};
Please note that the common video properties would be in the panel node, not
in the endpoint node (unless you have specific requirements to do so, which
isn't the common case).
Hmm, well, the panel driver must look for its properties either in the
panel node, or in the endpoint node (I guess it could look them from
both, but that doesn't sound good).
If you write the panel driver, and in all your cases the properties work
fine in the panel node, does that mean they'll work fine with everybody?
I guess there are different kinds of properties. Something like a
regulator is obviously property of the panel. But anything related to
the video itself, like DPI's bus width, or perhaps even something like
orientation if the panel supports such, could need to be in the
endpoint node.
But yes, I understand what you mean. With common-video-property I
meant common properties like DPI bus width.
If that can be supported in the SW by adding complexity to a few functions,
and it covers practically all the panels, isn't it worth it?
Note that I have not tried this, so I don't know if there are issues.
It's just a thought. Even if there's need for a endpoint node, perhaps
the port node can be made optional.
It can be worth it, as long as we make sure that simplified bindings cover
the
needs of the generic code.
We could assume that, if the port subnode isn't present, the device will have
a single port, with a single endpoint. However, isn't the number of endpoints
Right.
a system property rather than a device property ? If a port of a device is
Yes.
connected to two remote ports it will require two endpoints. We could select
the simplified or full bindings based on the system topology though.
The drivers should not know about simplified/normal bindings. They
should use CDF DT helper functions to get the port and endpoint
information. The helper functions would do the assuming.
Tomi
signature.asc
Description: OpenPGP digital signature
Terratec H5 (analog support)
Hi! I'm trying this question again. DVB-C works perfectly with the V4L-driver, but I'm a bit curious if the analog tuner is supposed to be supported? A video0 device gets created but starting tvheadend it complains about it missing a tuner and the device is skipped. Is this an issue with tvheadend or a constraint of the driver? Thanks in advance. -- Tobias Bengtsson (tjo...@gmail.com) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] video: exynos_mipi_dsim: Use the generic PHY driver
Hi Kishon, On Wed, Oct 16, 2013 at 9:28 AM, Kishon Vijay Abraham I kis...@ti.com wrote: diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c index 32e5406..00b3a52 100644 --- a/drivers/video/exynos/exynos_mipi_dsi.c +++ b/drivers/video/exynos/exynos_mipi_dsi.c @@ -156,8 +157,7 @@ static int exynos_mipi_dsi_blank_mode(struct mipi_dsim_device *dsim, int power) exynos_mipi_regulator_enable(dsim); /* enable MIPI-DSI PHY. */ - if (dsim-pd-phy_enable) - dsim-pd-phy_enable(pdev, true); + phy_power_on(dsim-phy); clk_enable(dsim-clock); This introduces the below with exynos_defconfig: ../../drivers/video/exynos/exynos_mipi_dsi.c: In function 'exynos_mipi_dsi_blank_mode': ../../drivers/video/exynos/exynos_mipi_dsi.c:144:26: warning: unused variable 'pdev' [-Wunused-variable] struct platform_device *pdev = to_platform_device(dsim-dev); -Olof -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] phy: Add driver for Exynos DP PHY
Hi Kishon, Recently, I posted 'simple-phy' driver. It is a part of patchset for HDMI enabling on Exynos4 using Device Tree. http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg23655.html The simple-phy was dedicated for single register PHYs like HDMI or DP. Using such a generic phy may help to avoid code duplication. Regards, Tomasz Stanislawski On 10/16/2013 06:28 PM, Kishon Vijay Abraham I wrote: From: Jingoo Han jg1@samsung.com Add a PHY provider driver for the Samsung Exynos SoC Display Port PHY. Signed-off-by: Jingoo Han jg1@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com Cc: Sylwester Nawrocki s.nawro...@samsung.com Acked-by: Felipe Balbi ba...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- .../devicetree/bindings/phy/samsung-phy.txt|8 ++ drivers/phy/Kconfig|7 ++ drivers/phy/Makefile |1 + drivers/phy/phy-exynos-dp-video.c | 111 4 files changed, 127 insertions(+) create mode 100644 drivers/phy/phy-exynos-dp-video.c -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] video: exynos_mipi_dsim: Use the generic PHY driver
Hi Olof, On 24 October 2013 20:00, Olof Johansson o...@lixom.net wrote: Hi Kishon, On Wed, Oct 16, 2013 at 9:28 AM, Kishon Vijay Abraham I kis...@ti.com wrote: diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c index 32e5406..00b3a52 100644 --- a/drivers/video/exynos/exynos_mipi_dsi.c +++ b/drivers/video/exynos/exynos_mipi_dsi.c @@ -156,8 +157,7 @@ static int exynos_mipi_dsi_blank_mode(struct mipi_dsim_device *dsim, int power) exynos_mipi_regulator_enable(dsim); /* enable MIPI-DSI PHY. */ - if (dsim-pd-phy_enable) - dsim-pd-phy_enable(pdev, true); + phy_power_on(dsim-phy); clk_enable(dsim-clock); This introduces the below with exynos_defconfig: ../../drivers/video/exynos/exynos_mipi_dsi.c: In function 'exynos_mipi_dsi_blank_mode': ../../drivers/video/exynos/exynos_mipi_dsi.c:144:26: warning: unused variable 'pdev' [-Wunused-variable] struct platform_device *pdev = to_platform_device(dsim-dev); I have already submitted a patch to fix this [1] [1] http://marc.info/?l=linux-fbdevm=138233359617936w=2 -- With warm regards, Sachin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] video: exynos_mipi_dsim: Use the generic PHY driver
Hi, On Thursday 24 October 2013 09:12 PM, Sachin Kamat wrote: Hi Olof, On 24 October 2013 20:00, Olof Johansson o...@lixom.net wrote: Hi Kishon, On Wed, Oct 16, 2013 at 9:28 AM, Kishon Vijay Abraham I kis...@ti.com wrote: diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c index 32e5406..00b3a52 100644 --- a/drivers/video/exynos/exynos_mipi_dsi.c +++ b/drivers/video/exynos/exynos_mipi_dsi.c @@ -156,8 +157,7 @@ static int exynos_mipi_dsi_blank_mode(struct mipi_dsim_device *dsim, int power) exynos_mipi_regulator_enable(dsim); /* enable MIPI-DSI PHY. */ - if (dsim-pd-phy_enable) - dsim-pd-phy_enable(pdev, true); + phy_power_on(dsim-phy); clk_enable(dsim-clock); This introduces the below with exynos_defconfig: ../../drivers/video/exynos/exynos_mipi_dsi.c: In function 'exynos_mipi_dsi_blank_mode': ../../drivers/video/exynos/exynos_mipi_dsi.c:144:26: warning: unused variable 'pdev' [-Wunused-variable] struct platform_device *pdev = to_platform_device(dsim-dev); I have already submitted a patch to fix this [1] [1] http://marc.info/?l=linux-fbdevm=138233359617936w=2 Sorry, missed that :-( Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB-S2 USB device: DVBsky, Technotrend or Tevii?
Hi P., I own a DVBSky S960 device and so far it has been working fine with my DiSEqC setup (A/B) and the vendor supplied drivers. From my experience the driver is updated frequently and thus compiles with recent kernels most of the time. Unfortunately integration into the mainline kernel is on halt due to copyright and code issues as well as (obviously) personal/competitive differences (see http://www.spinics.net/lists/linux-media/msg46802.html for example). I haven't tested any other DVB-S2 USB devices so far. For that reason I cannot help you with selecting the right one. However, I would be interested in any recommendations myself. - Felix -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec H5 (analog support)
On 10/24/2013 04:26 PM, Tobias Bengtsson wrote: Hi! I'm trying this question again. DVB-C works perfectly with the V4L-driver, but I'm a bit curious if the analog tuner is supposed to be supported? A video0 device gets created but starting tvheadend it complains about it missing a tuner and the device is skipped. Is this an issue with tvheadend or a constraint of the driver? Thanks in advance. Hi Tobias, To my knowledge, the driver does not support analog in any way. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] video: exynos_mipi_dsim: Use the generic PHY driver
On Thu, Oct 24, 2013 at 8:42 AM, Sachin Kamat sachin.ka...@linaro.org wrote: Hi Olof, On 24 October 2013 20:00, Olof Johansson o...@lixom.net wrote: Hi Kishon, On Wed, Oct 16, 2013 at 9:28 AM, Kishon Vijay Abraham I kis...@ti.com wrote: diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c index 32e5406..00b3a52 100644 --- a/drivers/video/exynos/exynos_mipi_dsi.c +++ b/drivers/video/exynos/exynos_mipi_dsi.c @@ -156,8 +157,7 @@ static int exynos_mipi_dsi_blank_mode(struct mipi_dsim_device *dsim, int power) exynos_mipi_regulator_enable(dsim); /* enable MIPI-DSI PHY. */ - if (dsim-pd-phy_enable) - dsim-pd-phy_enable(pdev, true); + phy_power_on(dsim-phy); clk_enable(dsim-clock); This introduces the below with exynos_defconfig: ../../drivers/video/exynos/exynos_mipi_dsi.c: In function 'exynos_mipi_dsi_blank_mode': ../../drivers/video/exynos/exynos_mipi_dsi.c:144:26: warning: unused variable 'pdev' [-Wunused-variable] struct platform_device *pdev = to_platform_device(dsim-dev); I have already submitted a patch to fix this [1] [1] http://marc.info/?l=linux-fbdevm=138233359617936w=2 Ah, I'm not subscribed to the fbdev list. Next time it might be a good idea to cc the same lists as the original patch. But thanks for fixing it! -Olof -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB-S2 USB device: DVBsky, Technotrend or Tevii?
Hi, Am 24.10.2013 01:17, schrieb P. van Gaans: I want to buy a DVB-S2 USB device. The following are available here (all Montage tuner/demod): I know that it's not on your list but I have two of those (working very well here) and the driver is in mainline linux since at least 2.6.39: http://www.linuxtv.org/wiki/index.php/Technisat_SkyStar_USB_HD I personally don't use DiSEqC at all but other users reported that it should work. Maybe you want to consider buying it from abroad? Best regards, Jannis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] video: exynos_mipi_dsim: Use the generic PHY driver
On 10/24/2013 05:57 PM, Kishon Vijay Abraham I wrote: On Thursday 24 October 2013 09:12 PM, Sachin Kamat wrote: On 24 October 2013 20:00, Olof Johanssono...@lixom.net wrote: On Wed, Oct 16, 2013 at 9:28 AM, Kishon Vijay Abraham Ikis...@ti.com wrote: diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c index 32e5406..00b3a52 100644 --- a/drivers/video/exynos/exynos_mipi_dsi.c +++ b/drivers/video/exynos/exynos_mipi_dsi.c @@ -156,8 +157,7 @@ static int exynos_mipi_dsi_blank_mode(struct mipi_dsim_device *dsim, int power) exynos_mipi_regulator_enable(dsim); /* enable MIPI-DSI PHY. */ - if (dsim-pd-phy_enable) - dsim-pd-phy_enable(pdev, true); + phy_power_on(dsim-phy); clk_enable(dsim-clock); This introduces the below with exynos_defconfig: ../../drivers/video/exynos/exynos_mipi_dsi.c: In function 'exynos_mipi_dsi_blank_mode': ../../drivers/video/exynos/exynos_mipi_dsi.c:144:26: warning: unused variable 'pdev' [-Wunused-variable] struct platform_device *pdev = to_platform_device(dsim-dev); Sorry about missing that, I only noticed this warning recently and didn't get around to submit a patch. I have already submitted a patch to fix this [1] Thanks a lot guys for fixing this. [1] http://marc.info/?l=linux-fbdevm=138233359617936w=2 Sorry, missed that :-( This MIPI DSIM driver is affectively a dead code in the mainline now, once Exynos become a dt-only platform. I guess it can be deleted for 3.14, once S5P gets converted to the device tree. The new driver using CDF is basically a complete rewrite. Or device tree support should be added to that driver, but I believe it doesn't make sense without CDF. -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
FROM: BRUCE
Greetings, I am a US Army officer currently on military assignment in Iraq, I humbly ask of your assistance secure and invest some money for me in your country. As a matter of fact, I have the sum of US$5 Million which I would like you to help me to invest. I will appreciate it if you can assist me urgently in securing and investing the money in your country pending when I will disengage from my military assignment. I promise to compensate you with 10% of the funds for your assistance while hoping that you assist me as soon as possible. I await your urgent response. Contact: brucewest2...@gmail.com Best Regards Major Bruce -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
