Re: [PATCH 1/2] media: davinci: vpif: capture: add V4L2-async support
Hi Hans,
Thanks for the review.
On Thu, Jun 27, 2013 at 11:27 AM, Hans Verkuil hverk...@xs4all.nl wrote:
On Tue June 25 2013 17:17:34 Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
Add support for asynchronous subdevice probing, using the v4l2-async API.
The legacy synchronous mode is still supported too, which allows to
gradually update drivers and platforms.
Signed-off-by: Prabhakar Lad prabhakar.cse...@gmail.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/platform/davinci/vpif_capture.c | 151
+
drivers/media/platform/davinci/vpif_capture.h |2 +
include/media/davinci/vpif_types.h|2 +
3 files changed, 107 insertions(+), 48 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index 5514175..b11d7a7 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1979,6 +1979,76 @@ vpif_init_free_channel_objects:
return err;
}
+static int vpif_async_bound(struct v4l2_async_notifier *notifier,
+ struct v4l2_subdev *subdev,
+ struct v4l2_async_subdev *asd)
+{
+ int i;
+
+ for (i = 0; i vpif_obj.config-subdev_count; i++)
+ if (!strcmp(vpif_obj.config-subdev_info[i].name,
+ subdev-name)) {
Since the subdev name is now prefixed with the i2c bus identifier instead of
just the chip name, does this code still work? Shouldn't it be 'strstr'
instead
of strcmp? Ditto for vpif_display and possibly others where the same
mechanism might be used.
This is because the DA850-EVM has two tvp514x devices and assigning
the tvp514x device to appropriate channel is important, In this case strstr()
wont work so I used strcmp instead to match it appropriately.
Yes the code still works tested on DA850-EVM, with this patch [1].
[1]
http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git/commitdiff/c906a89762541361158cf73e9494fa2f1ff8ba02
Regards,
--Prabhakar Lad
--
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 v2 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
On Wed, Jun 26, 2013 at 05:00:34PM +0200, Sylwester Nawrocki wrote:
Hi,
On 06/25/2013 05:06 PM, Felipe Balbi wrote:
+static struct platform_driver exynos_video_phy_driver = {
+.probe = exynos_video_phy_probe,
you *must* provide a remove method. drivers with NULL remove are
non-removable :-)
Actually the remove() callback can be NULL, it's just missing module_exit
function that makes a module not unloadable.
look at the implementation of platform_drv_remove():
499 static int platform_drv_remove(struct device *_dev)
500 {
501 struct platform_driver *drv = to_platform_driver(_dev-driver);
502 struct platform_device *dev = to_platform_device(_dev);
503 int ret;
504
505 ret = drv-remove(dev);
506 if (ACPI_HANDLE(_dev))
507 acpi_dev_pm_detach(_dev, true);
508
509 return ret;
510 }
that's not a conditional call right :-)
--
balbi
signature.asc
Description: Digital signature
Re: Samsung i2c subdev drivers that set sd-name
On Wed June 26 2013 11:00:51 Sakari Ailus wrote: Hi Sylwester and Hans, On Tue, Jun 25, 2013 at 06:55:49PM +0200, Sylwester Nawrocki wrote: Hi Hans, Cc: Laurent and Sakari On 06/24/2013 10:54 AM, Hans Verkuil wrote: Hi Sylwester, It came to my attention that several i2c subdev drivers overwrite the sd-name as set by v4l2_i2c_subdev_init with a custom name. This is wrong if it is possible that there are multiple identical sensors in the system. The sd-name must be unique since it is used to prefix kernel messages etc, so you have to be able to tell the sensor devices apart. This has been discussed in the past, please see thread [1]. It concerns the following Samsung-contributed drivers: drivers/media/i2c/s5k4ecgx.c: strlcpy(sd-name, S5K4ECGX_DRIVER_NAME, sizeof(sd-name)); drivers/media/i2c/s5c73m3/s5c73m3-core.c: strlcpy(sd-name, S5C73M3, sizeof(sd-name)); drivers/media/i2c/s5c73m3/s5c73m3-core.c: strcpy(oif_sd-name, S5C73M3-OIF); drivers/media/i2c/sr030pc30.c: strcpy(sd-name, MODULE_NAME); drivers/media/i2c/noon010pc30.c:strlcpy(sd-name, MODULE_NAME, sizeof(sd-name)); drivers/media/i2c/m5mols/m5mols_core.c: strlcpy(sd-name, MODULE_NAME, sizeof(sd-name)); drivers/media/i2c/s5k6aa.c: strlcpy(sd-name, DRIVER_NAME, sizeof(sd-name)); It seems ov9650 is missing on this list, $ git grep .*cpy.*(.*sd\|subdev.*name -- drivers/media/i2c drivers/media/i2c/m5mols/m5mols_core.c: strlcpy(sd-name, MODULE_NAME, sizeof(sd-name)); drivers/media/i2c/noon010pc30.c:strlcpy(sd-name, MODULE_NAME, sizeof(sd-name)); drivers/media/i2c/ov9650.c: strlcpy(sd-name, DRIVER_NAME, sizeof(sd-name)); drivers/media/i2c/s5c73m3/s5c73m3-core.c: strlcpy(sd-name, S5C73M3, sizeof(sd-name)); drivers/media/i2c/s5c73m3/s5c73m3-core.c: strcpy(oif_sd-name, S5C73M3-OIF); drivers/media/i2c/s5k4ecgx.c: strlcpy(sd-name, S5K4ECGX_DRIVER_NAME, sizeof(sd-name)); drivers/media/i2c/s5k6aa.c: strlcpy(sd-name, DRIVER_NAME, sizeof(sd-name)); drivers/media/i2c/smiapp/smiapp-core.c: subdev-name, code-pad, code-index); drivers/media/i2c/smiapp/smiapp-core.c: strlcpy(subdev-name, sensor-minfo.name, sizeof(subdev-name)); For smiapp the issue is that smiapp is the name of the driver; there's no sensor which would be called smiapp but a large number of different devices that implement the SMIA or SMIA++ standard. The driver can recognise some of them and call them according to their real name. But the smiapp driver can still prefix that real name with the i2c bus info, right? Just as v4l2_i2c_subdev_init does. drivers/media/i2c/sr030pc30.c: strcpy(sd-name, MODULE_NAME); drivers/media/i2c/tvp514x.c:strlcpy(sd-name, TVP514X_MODULE_NAME, sizeof(sd-name)); If there can be only one sensor (because it is integrated in the SoC), then there is no problem with doing this. But it is not obvious to me which of these drivers are for integrated systems, and which aren't. Those sensors are standalone devices, I'm not aware of any of them to be integrated with an Application Processor SoC. I've never seen something like that. However some of those devices are hybrid modules with a raw image sensor and an ISP SoC. So in theory there could be multiple such devices in a single system, although personally I've never seen something like that. I can make patches for those that need to be fixed if you can tell me which drivers are affected. You may want to have a look at the commits listed below, and the comments I received to that [2] patch series... What comments? I see no comments. I would have Nacked those patches, but I probably never saw them since you posted them during a period where I was mostly absent from the list. commit 2138d73b69be1cfa4982c9949f2445ec77ea9edc [media] noon010pc30: Make subdev name independent of the I2C slave address commit 14b702dd71d38b6d0662251b3f8cd60da98602ce [media] s5k6aa: Make subdev name independent of the I2C slave address commit c5024a70bb60b678f08586ed786340ec162d250f [media] m5mols: Make subdev name independent of the I2C slave address Before we start messing with those drivers it would be nice to have defined rules of the media entity naming. I2C bus number and address is not something that's useful in the media entity name. And multiple Isn't it? Why not? As long as the format is strictly adhered to then I see no reason not to use it. Not only does it make the name unique, it also tells you where the device is in the hardware topology. We could make the simple rule that the driver name is the first word of the name. So it would be easy to provide a function that matches just the first word and ignores the bus info (if there is any). Well... there's currently no other way to figure out which I2C bus and address
Re: [PATCH 1/2] media: davinci: vpif: capture: add V4L2-async support
On Thu June 27 2013 08:13:40 Prabhakar Lad wrote:
Hi Hans,
Thanks for the review.
On Thu, Jun 27, 2013 at 11:27 AM, Hans Verkuil hverk...@xs4all.nl wrote:
On Tue June 25 2013 17:17:34 Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
Add support for asynchronous subdevice probing, using the v4l2-async API.
The legacy synchronous mode is still supported too, which allows to
gradually update drivers and platforms.
Signed-off-by: Prabhakar Lad prabhakar.cse...@gmail.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/platform/davinci/vpif_capture.c | 151
+
drivers/media/platform/davinci/vpif_capture.h |2 +
include/media/davinci/vpif_types.h|2 +
3 files changed, 107 insertions(+), 48 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index 5514175..b11d7a7 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1979,6 +1979,76 @@ vpif_init_free_channel_objects:
return err;
}
+static int vpif_async_bound(struct v4l2_async_notifier *notifier,
+ struct v4l2_subdev *subdev,
+ struct v4l2_async_subdev *asd)
+{
+ int i;
+
+ for (i = 0; i vpif_obj.config-subdev_count; i++)
+ if (!strcmp(vpif_obj.config-subdev_info[i].name,
+ subdev-name)) {
Since the subdev name is now prefixed with the i2c bus identifier instead of
just the chip name, does this code still work? Shouldn't it be 'strstr'
instead
of strcmp? Ditto for vpif_display and possibly others where the same
mechanism might be used.
This is because the DA850-EVM has two tvp514x devices and assigning
the tvp514x device to appropriate channel is important, In this case strstr()
wont work so I used strcmp instead to match it appropriately.
Yes the code still works tested on DA850-EVM, with this patch [1].
[1]
http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git/commitdiff/c906a89762541361158cf73e9494fa2f1ff8ba02
Ah, OK. That's what I wanted to verify!
Regards,
Hans
Regards,
--Prabhakar Lad
--
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
[GIT PULL FOR v3.11]
(Same as my previous git pull message, but with more cleanup patches and fixes from Prabhakar.) Some async/OF work from Prabhakar (the correct version this time) and assorted improvements and fixes for compiler warnings. Also some fixes for some fallout from the new requirement that v4l2_dev must be set when registering a device node. I missed two cases: the wl128x never had a v4l2_device and it never set the old parent pointer, and the case where a v4l2_device was created, but it was never set in video_device (and neither was the old parent pointer). I've tested the wl128x since it turns out that it tries to load itself on a regular PC that does not have this chipset. Dubious behavior in any case, but useful now because it made it easy to test this patch. Regards, Hans The following changes since commit ee17608d6aa04a86e253a9130d6c6d00892f132b: [media] imx074: support asynchronous probing (2013-06-21 16:36:15 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.11 for you to fetch changes up to 7a95f9fbecf8eb65678cb945f0bc3564018e1950: media: davinci: vpif: display: add V4L2-async support (2013-06-27 08:48:38 +0200) Emil Goode (1): saa7134: Fix sparse warnings by adding __user annotation Hans Verkuil (7): ml86v7667: fix compiler warning bfin_capture: fix compiler warning omap_vout: fix compiler warning v4l2-controls.h: fix copy-and-paste error in comment saa7164: fix compiler warning wl128x: add missing struct v4l2_device. mem2mem: set missing v4l2_dev pointer Lad, Prabhakar (9): media: i2c: ths8200: support asynchronous probing media: i2c: ths8200: add OF support media: i2c: adv7343: add support for asynchronous probing media: i2c: tvp7002: add support for asynchronous probing media: i2c: tvp7002: remove manual setting of subdev name media: i2c: tvp514x: remove manual setting of subdev name media: i2c: tvp514x: add support for asynchronous probing media: davinci: vpif: capture: add V4L2-async support media: davinci: vpif: display: add V4L2-async support Lars-Peter Clausen (1): tvp514x: Fix init seqeunce Documentation/devicetree/bindings/media/i2c/ths8200.txt | 19 +++ drivers/media/i2c/adv7343.c | 15 -- drivers/media/i2c/ml86v7667.c | 2 +- drivers/media/i2c/ths8200.c | 18 ++- drivers/media/i2c/tvp514x.c | 31 ++- drivers/media/i2c/tvp7002.c | 7 ++- drivers/media/pci/saa7134/saa7134-video.c | 2 +- drivers/media/pci/saa7164/saa7164-core.c| 3 +- drivers/media/platform/blackfin/bfin_capture.c | 4 +- drivers/media/platform/davinci/vpif_capture.c | 151 +++- drivers/media/platform/davinci/vpif_capture.h | 2 + drivers/media/platform/davinci/vpif_display.c | 210 - drivers/media/platform/davinci/vpif_display.h | 3 +- drivers/media/platform/m2m-deinterlace.c| 1 + drivers/media/platform/mem2mem_testdev.c| 3 +- drivers/media/platform/mx2_emmaprp.c| 1 + drivers/media/platform/omap/omap_vout.c | 3 +- drivers/media/radio/wl128x/fmdrv.h | 2 + drivers/media/radio/wl128x/fmdrv_v4l2.c | 8 +++ include/media/davinci/vpif_types.h | 4 ++ include/uapi/linux/v4l2-controls.h | 4 +- 21 files changed, 335 insertions(+), 158 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/i2c/ths8200.txt -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/3] R8A7779/Marzen R-Car VIN driver support
On Thu, May 16, 2013 at 01:53:29AM +0400, Sergei Shtylyov wrote: Hello. Here's the set of 3 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130515v2' tag and my recent yet unapplied USB/I2C patches. Here we add the VIN driver platform code for the R8A7779/Marzen with ADV7180 I2C video decoder. [1/3] ARM: shmobile: r8a7779: add VIN support [2/3] ARM: shmobile: Marzen: add VIN and ADV7180 support [3/3] ARM: shmobile: Marzen: enable VIN and ADV7180 in defconfig The VIN driver itself has been excluded from the series as it will be developed against Mauro's 'media_tree.git' plus some yet unapplied patches in the future... Sergei, is this patch-set still needing review? -- 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 v2 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
Hi Felipe,
On 06/27/2013 08:17 AM, Felipe Balbi wrote:
On Wed, Jun 26, 2013 at 05:00:34PM +0200, Sylwester Nawrocki wrote:
Hi,
On 06/25/2013 05:06 PM, Felipe Balbi wrote:
+static struct platform_driver exynos_video_phy_driver = {
+ .probe = exynos_video_phy_probe,
you *must* provide a remove method. drivers with NULL remove are
non-removable :-)
Actually the remove() callback can be NULL, it's just missing module_exit
function that makes a module not unloadable.
look at the implementation of platform_drv_remove():
499 static int platform_drv_remove(struct device *_dev)
500 {
501 struct platform_driver *drv = to_platform_driver(_dev-driver);
502 struct platform_device *dev = to_platform_device(_dev);
503 int ret;
504
505 ret = drv-remove(dev);
506 if (ACPI_HANDLE(_dev))
507 acpi_dev_pm_detach(_dev, true);
508
509 return ret;
510 }
that's not a conditional call right :-)
It is conditional, just condition check is in different place:
int platform_driver_register(struct platform_driver *drv)
{
(...)
if (drv-remove)
drv-driver.remove = platform_drv_remove;
(...)
}
Regards
Andrzej
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 v2 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
On Thu, Jun 27, 2013 at 09:47:47AM +0200, Andrzej Hajda wrote:
Hi Felipe,
On 06/27/2013 08:17 AM, Felipe Balbi wrote:
On Wed, Jun 26, 2013 at 05:00:34PM +0200, Sylwester Nawrocki wrote:
Hi,
On 06/25/2013 05:06 PM, Felipe Balbi wrote:
+static struct platform_driver exynos_video_phy_driver = {
+ .probe = exynos_video_phy_probe,
you *must* provide a remove method. drivers with NULL remove are
non-removable :-)
Actually the remove() callback can be NULL, it's just missing module_exit
function that makes a module not unloadable.
look at the implementation of platform_drv_remove():
499 static int platform_drv_remove(struct device *_dev)
500 {
501 struct platform_driver *drv = to_platform_driver(_dev-driver);
502 struct platform_device *dev = to_platform_device(_dev);
503 int ret;
504
505 ret = drv-remove(dev);
506 if (ACPI_HANDLE(_dev))
507 acpi_dev_pm_detach(_dev, true);
508
509 return ret;
510 }
that's not a conditional call right :-)
It is conditional, just condition check is in different place:
int platform_driver_register(struct platform_driver *drv)
{
(...)
if (drv-remove)
drv-driver.remove = platform_drv_remove;
(...)
}
good point :-) thanks. I'll go ack your driver now
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
On Wed, Jun 26, 2013 at 05:02:22PM +0200, Sylwester Nawrocki wrote: Add a PHY provider driver for the Samsung S5P/Exynos SoC MIPI CSI-2 receiver and MIPI DSI transmitter DPHYs. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 2/5] ARM: dts: Add MIPI PHY node to exynos4.dtsi
On Wed, Jun 26, 2013 at 05:02:23PM +0200, Sylwester Nawrocki wrote: Add PHY provider node for the MIPI CSIS and MIPI DSIM PHYs. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
On 06/27/2013 09:52 AM, Felipe Balbi wrote: On Wed, Jun 26, 2013 at 05:02:22PM +0200, Sylwester Nawrocki wrote: Add a PHY provider driver for the Samsung S5P/Exynos SoC MIPI CSI-2 receiver and MIPI DSI transmitter DPHYs. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Felipe Balbi ba...@ti.com Thank you for your review and ack! Just for the record, I have tested this driver as a loadable module on Exynos4412 TRATS2 board and it all worked fine for both the camera and display side. -- 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
Re: [PATCH v2 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
On Thu, Jun 27, 2013 at 09:17:13AM +0300, Felipe Balbi wrote:
On Wed, Jun 26, 2013 at 05:00:34PM +0200, Sylwester Nawrocki wrote:
Hi,
On 06/25/2013 05:06 PM, Felipe Balbi wrote:
+static struct platform_driver exynos_video_phy_driver = {
+ .probe = exynos_video_phy_probe,
you *must* provide a remove method. drivers with NULL remove are
non-removable :-)
Actually the remove() callback can be NULL, it's just missing module_exit
function that makes a module not unloadable.
look at the implementation of platform_drv_remove():
499 static int platform_drv_remove(struct device *_dev)
500 {
501 struct platform_driver *drv = to_platform_driver(_dev-driver);
502 struct platform_device *dev = to_platform_device(_dev);
503 int ret;
504
505 ret = drv-remove(dev);
506 if (ACPI_HANDLE(_dev))
507 acpi_dev_pm_detach(_dev, true);
508
509 return ret;
510 }
that's not a conditional call right :-)
Wrong.
if (drv-remove)
drv-driver.remove = platform_drv_remove;
The function you quote will only be used if drv-remove is non-NULL.
You do not need to provide a remove method.
--
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: Question: interaction between selection API, ENUM_FRAMESIZES and S_FMT?
Hi Hans On Mon, 24 Jun 2013, Hans Verkuil wrote: Hi all, While working on extending v4l2-compliance with cropping/selection test cases I decided to add support for that to vivi as well (this would give applications a good test driver to work with). However, I ran into problems how this should be implemented for V4L2 devices (we are not talking about complex media controller devices where the video pipelines are setup manually). There are two problems, one related to ENUM_FRAMESIZES and one to S_FMT. The ENUM_FRAMESIZES issue is simple: if you have a sensor that has several possible frame sizes, and that can crop, compose and/or scale, then you need to be able to set the frame size. Currently this is decided by S_FMT which maps the format size to the closest valid frame size. This however makes it impossible to e.g. scale up a frame, or compose the image into a larger buffer. For video receivers this issue doesn't exist: there the size of the incoming video is decided by S_STD or S_DV_TIMINGS, but no equivalent exists for sensors. Isn't it a part of the current uncertainty of the type who should scale? Or what output format should be set on the sensor for any specific final user-facing output frame? I thought we decided not to try to become much smarter here with the classical V4L2 API, instead, those for whom this is really important should support subdevice- or even pad-level configuration? I propose that a new selection target is added: V4L2_SEL_TGT_FRAMESIZE. However, this leads to another problem: the current S_FMT behavior is that it implicitly sets the framesize. That behavior we will have to keep, otherwise applications will start to behave differently. I have an idea on how to solve that, but the solution is related to the second problem I found: When you set a new format size, then the compose rectangle must be set to the new format size as well since that has always been the behavior in the past that applications have come to expect. But this makes certain operations impossible to execute: if a driver can't scale, then you can never select a new format size larger than the current (possibly cropped) frame size, even though you would want to compose the unscaled image into such a larger buffer. So what is the behavior that I would expect from drivers? 1) After calling S_STD, S_DV_TIMINGS or S_SELECTION(V4L2_SEL_TGT_FRAMESIZE) the cropping, composing and format parameters are all adjusted to support the new input video size (typically they are all set to the new size). 2) After calling S_CROP/S_SELECTION(CROP) the compose and format parameters are all adjusted to support the new crop rectangle. 3) After calling S_SEL(COMPOSE) the format parameters are adjusted. 4) Calling S_FMT validates the format parameters to support the compose rectangle. However, today step 4 does something different: the compose rectangle will be adjusted to the format size (and in the case of a sensor supporting different framesizes the whole pipeline will be adjusted). The only way I see that would solve this (although it isn't perfect) is to change the behavior of S_FMT only if the selection API was used before by the filehandle. The core can keep easily keep track of that. When the application calls S_FMT and no selection API was used in the past by that filehandle, then the core will call first S_SELECTION(V4L2_SEL_TGT_FRAMESIZE). If that returns -EINVAL, then it will call S_SELECTION(V4L2_SEL_TGT_COMPOSE). Finally it will call S_FMT. Note that a similar sequence is needed for the display case. This means that a driver supporting the selection API can implement the logical behavior and the core will implement the historically-required illogical part. So the fix for this would be to add a new selection target and add compatibility code to the v4l2-core. With that in place I can easily add crop/compose support to vivi. One area of uncertainty is how drivers currently implement S_FMT: do they reset any cropping done before? They should keep the crop rectangle according to the spec (well, it is implied there). Guennadi, what does soc_camera do? No, soc-camera core doesn't touch cropping parameters in s_fmt. Similarly host drivers aren't expected to do that. Thanks Guennadi Sylwester, I am also looking at exynos4-is/fimc-lite.c. I do see that setting the compose rectangle will adjust it to the format size instead of the other way around, but I can't tell if setting the format size will also adjust the compose rectangle if that is now out-of-bounds of the new format size. Comments? Questions? Regards, Hans --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
Re: [PATCH v4] [media] mem2mem: add support for hardware buffered queue
On 06/03/2013 10:23 AM, Philipp Zabel wrote: On mem2mem decoders with a hardware bitstream ringbuffer, to drain the buffer at the end of the stream, remaining frames might need to be decoded from the bitstream buffer without additional input buffers being provided. To achieve this, allow a queue to be marked as buffered by the driver, and allow scheduling of device_runs when buffered ready queues are empty. This also allows a driver to copy input buffers into their bitstream ringbuffer and immediately mark them as done to be dequeued. The motivation for this patch is hardware assisted h.264 reordering support in the coda driver. For high profile streams, the coda can hold back out-of-order frames, causing a few mem2mem device runs in the beginning, that don't produce any decompressed buffer at the v4l2 capture side. At the same time, the last few frames can be decoded from the bitstream with mem2mem device runs that don't need a new input buffer at the v4l2 output side. The decoder command ioctl can be used to put the decoder into the ringbuffer draining end-of-stream mode. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Acked-by: Sylwester Nawrocki s.nawro...@samsung.com -- 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
Re: Question: interaction between selection API, ENUM_FRAMESIZES and S_FMT?
On Thu 27 June 2013 10:59:20 Guennadi Liakhovetski wrote: Hi Hans On Mon, 24 Jun 2013, Hans Verkuil wrote: Hi all, While working on extending v4l2-compliance with cropping/selection test cases I decided to add support for that to vivi as well (this would give applications a good test driver to work with). However, I ran into problems how this should be implemented for V4L2 devices (we are not talking about complex media controller devices where the video pipelines are setup manually). There are two problems, one related to ENUM_FRAMESIZES and one to S_FMT. The ENUM_FRAMESIZES issue is simple: if you have a sensor that has several possible frame sizes, and that can crop, compose and/or scale, then you need to be able to set the frame size. Currently this is decided by S_FMT which maps the format size to the closest valid frame size. This however makes it impossible to e.g. scale up a frame, or compose the image into a larger buffer. For video receivers this issue doesn't exist: there the size of the incoming video is decided by S_STD or S_DV_TIMINGS, but no equivalent exists for sensors. Isn't it a part of the current uncertainty of the type who should scale? Or what output format should be set on the sensor for any specific final user-facing output frame? I thought we decided not to try to become much smarter here with the classical V4L2 API, instead, those for whom this is really important should support subdevice- or even pad-level configuration? I'm actually not trying to do anything complex. And remember that this is not scaler specific: even if there is no scaler but you just want to crop and/or compose you end up with the same problem: you can't define which framesize should be used. You need to be able to do that in order to know how to interpret the crop/compose rectangles. The reason I found all these problems is by the simple experiment of adding crop/compose support to vivi. Hardly a complex driver. But it is impossible to do this today. I propose that a new selection target is added: V4L2_SEL_TGT_FRAMESIZE. However, this leads to another problem: the current S_FMT behavior is that it implicitly sets the framesize. That behavior we will have to keep, otherwise applications will start to behave differently. I have an idea on how to solve that, but the solution is related to the second problem I found: When you set a new format size, then the compose rectangle must be set to the new format size as well since that has always been the behavior in the past that applications have come to expect. But this makes certain operations impossible to execute: if a driver can't scale, then you can never select a new format size larger than the current (possibly cropped) frame size, even though you would want to compose the unscaled image into such a larger buffer. So what is the behavior that I would expect from drivers? 1) After calling S_STD, S_DV_TIMINGS or S_SELECTION(V4L2_SEL_TGT_FRAMESIZE) the cropping, composing and format parameters are all adjusted to support the new input video size (typically they are all set to the new size). 2) After calling S_CROP/S_SELECTION(CROP) the compose and format parameters are all adjusted to support the new crop rectangle. 3) After calling S_SEL(COMPOSE) the format parameters are adjusted. 4) Calling S_FMT validates the format parameters to support the compose rectangle. However, today step 4 does something different: the compose rectangle will be adjusted to the format size (and in the case of a sensor supporting different framesizes the whole pipeline will be adjusted). The only way I see that would solve this (although it isn't perfect) is to change the behavior of S_FMT only if the selection API was used before by the filehandle. The core can keep easily keep track of that. When the application calls S_FMT and no selection API was used in the past by that filehandle, then the core will call first S_SELECTION(V4L2_SEL_TGT_FRAMESIZE). If that returns -EINVAL, then it will call S_SELECTION(V4L2_SEL_TGT_COMPOSE). Finally it will call S_FMT. Note that a similar sequence is needed for the display case. This means that a driver supporting the selection API can implement the logical behavior and the core will implement the historically-required illogical part. So the fix for this would be to add a new selection target and add compatibility code to the v4l2-core. With that in place I can easily add crop/compose support to vivi. One area of uncertainty is how drivers currently implement S_FMT: do they reset any cropping done before? They should keep the crop rectangle according to the spec (well, it is implied there). Guennadi, what does soc_camera do? No, soc-camera core doesn't touch cropping parameters in s_fmt.
RE: [PATCH v3 5/5] ARM: Samsung: Remove the MIPI PHY setup code
Sylwester Nawrocki wrote: Generic PHY drivers are used to handle the MIPI CSIS and MIPI DSIM DPHYs so we can remove now unused code at arch/arm/plat-samsung. In case there is any board file for S5PV210 platforms using MIPI CSIS/DSIM (not any upstream currently) it should use the generic PHY API to bind the PHYs to respective PHY consumer drivers and a platform device for the PHY provider should be defined. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Felipe Balbi ba...@ti.com --- arch/arm/mach-exynos/include/mach/regs-pmu.h|5 -- arch/arm/mach-s5pv210/include/mach/regs-clock.h |4 -- arch/arm/plat-samsung/Kconfig |5 -- arch/arm/plat-samsung/Makefile |1 - arch/arm/plat-samsung/setup-mipiphy.c | 60 - -- 5 files changed, 75 deletions(-) delete mode 100644 arch/arm/plat-samsung/setup-mipiphy.c Looks good, please feel free to add my ack on this, Acked-by: Kukjin Kim kgene@samsung.com Thanks, - Kukjin -- 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: Samsung i2c subdev drivers that set sd-name
On 06/27/2013 08:43 AM, Hans Verkuil wrote: On Wed June 26 2013 11:00:51 Sakari Ailus wrote: On Tue, Jun 25, 2013 at 06:55:49PM +0200, Sylwester Nawrocki wrote: On 06/24/2013 10:54 AM, Hans Verkuil wrote: Hi Sylwester, It came to my attention that several i2c subdev drivers overwrite the sd-name as set by v4l2_i2c_subdev_init with a custom name. This is wrong if it is possible that there are multiple identical sensors in the system. The sd-name must be unique since it is used to prefix kernel messages etc, so you have to be able to tell the sensor devices apart. This has been discussed in the past, please see thread [1]. It concerns the following Samsung-contributed drivers: drivers/media/i2c/s5k4ecgx.c: strlcpy(sd-name, S5K4ECGX_DRIVER_NAME, sizeof(sd-name)); drivers/media/i2c/s5c73m3/s5c73m3-core.c: strlcpy(sd-name, S5C73M3, sizeof(sd-name)); drivers/media/i2c/s5c73m3/s5c73m3-core.c: strcpy(oif_sd-name, S5C73M3-OIF); drivers/media/i2c/sr030pc30.c: strcpy(sd-name, MODULE_NAME); drivers/media/i2c/noon010pc30.c:strlcpy(sd-name, MODULE_NAME, sizeof(sd-name)); drivers/media/i2c/m5mols/m5mols_core.c: strlcpy(sd-name, MODULE_NAME, sizeof(sd-name)); drivers/media/i2c/s5k6aa.c: strlcpy(sd-name, DRIVER_NAME, sizeof(sd-name)); It seems ov9650 is missing on this list, $ git grep .*cpy.*(.*sd\|subdev.*name -- drivers/media/i2c drivers/media/i2c/m5mols/m5mols_core.c: strlcpy(sd-name, MODULE_NAME, sizeof(sd-name)); drivers/media/i2c/noon010pc30.c:strlcpy(sd-name, MODULE_NAME, sizeof(sd-name)); drivers/media/i2c/ov9650.c: strlcpy(sd-name, DRIVER_NAME, sizeof(sd-name)); drivers/media/i2c/s5c73m3/s5c73m3-core.c: strlcpy(sd-name, S5C73M3, sizeof(sd-name)); drivers/media/i2c/s5c73m3/s5c73m3-core.c: strcpy(oif_sd-name, S5C73M3-OIF); drivers/media/i2c/s5k4ecgx.c: strlcpy(sd-name, S5K4ECGX_DRIVER_NAME, sizeof(sd-name)); drivers/media/i2c/s5k6aa.c: strlcpy(sd-name, DRIVER_NAME, sizeof(sd-name)); drivers/media/i2c/smiapp/smiapp-core.c: subdev-name, code-pad, code-index); drivers/media/i2c/smiapp/smiapp-core.c: strlcpy(subdev-name, sensor-minfo.name, sizeof(subdev-name)); For smiapp the issue is that smiapp is the name of the driver; there's no sensor which would be called smiapp but a large number of different devices that implement the SMIA or SMIA++ standard. The driver can recognise some of them and call them according to their real name. But the smiapp driver can still prefix that real name with the i2c bus info, right? Just as v4l2_i2c_subdev_init does. drivers/media/i2c/sr030pc30.c: strcpy(sd-name, MODULE_NAME); drivers/media/i2c/tvp514x.c:strlcpy(sd-name, TVP514X_MODULE_NAME, sizeof(sd-name)); If there can be only one sensor (because it is integrated in the SoC), then there is no problem with doing this. But it is not obvious to me which of these drivers are for integrated systems, and which aren't. Those sensors are standalone devices, I'm not aware of any of them to be integrated with an Application Processor SoC. I've never seen something like that. However some of those devices are hybrid modules with a raw image sensor and an ISP SoC. So in theory there could be multiple such devices in a single system, although personally I've never seen something like that. I can make patches for those that need to be fixed if you can tell me which drivers are affected. You may want to have a look at the commits listed below, and the comments I received to that [2] patch series... What comments? I see no comments. Yes, that's the point :) IMHO it's a bit late for reverting that, and breaking existing user space. I would have Nacked those patches, but I probably never saw them since you posted them during a period where I was mostly absent from the list. Fair enough. commit 2138d73b69be1cfa4982c9949f2445ec77ea9edc [media] noon010pc30: Make subdev name independent of the I2C slave address commit 14b702dd71d38b6d0662251b3f8cd60da98602ce [media] s5k6aa: Make subdev name independent of the I2C slave address commit c5024a70bb60b678f08586ed786340ec162d250f [media] m5mols: Make subdev name independent of the I2C slave address Before we start messing with those drivers it would be nice to have defined rules of the media entity naming. I2C bus number and address is not something that's useful in the media entity name. And multiple Isn't it? Why not? As long as the format is strictly adhered to then I see no reason not to use it. Not only does it make the name unique, it also tells you where the device is in the hardware topology. We could make the simple rule that the driver name is the first word of the name. So it would be easy to provide a function that matches just the first word and ignores the bus info (if there is any). Yes, and that's basically all I needed before fixing those affected drivers. No matter what exact rules,
RE: [PATCH v2 8/8] [media] coda: add CODA7541 decoding support
Hi Philipp,
This patch did not apply well on my tree. I find this quite strange.
I did try and applied it manually, but please check here if it is
correct:
http://git.linuxtv.org/kdebski/media.git/shortlog/refs/heads/master
Best wishes,
--
Kamil Debski
Linux Kernel Developer
Samsung RD Institute Poland
-Original Message-
From: Philipp Zabel [mailto:p.za...@pengutronix.de]
Sent: Friday, June 21, 2013 9:56 AM
To: linux-media@vger.kernel.org
Cc: Kamil Debski; Javier Martin; Sylwester Nawrocki; Gaëtan Carlier;
Wei Yongjun; Philipp Zabel
Subject: [PATCH v2 8/8] [media] coda: add CODA7541 decoding support
This patch enables decoding of h.264 and mpeg4 streams on CODA7541.
Queued output buffers are immediately copied into the bitstream
ringbuffer. A device_run can be scheduled whenever there is either
enough compressed bitstream data, or the CODA is in stream end mode.
Each successful device_run, data is read from the bitstream ringbuffer
and a frame is decoded into a free internal framebuffer. Depending on
reordering, a possibly previously decoded frame is marked as display
frame, and at the same time the display frame from the previous run is
copied out into a capture buffer by the rotator hardware.
The dequeued capture buffers are counted to send the EOS signal to
userspace with the last frame. When userspace sends the decoder stop
command or enqueues an empty output buffer, the stream end flag is set
to allow decoding the remaining frames in the bitstream ringbuffer.
The enum_fmt/try_fmt functions return fixed capture buffer sizes while
the output queue is streaming, to allow better autonegotiation in
userspace.
A per-context buffer mutex is used to lock the picture run against
buffer dequeueing: if a job gets queued, then streamoff dequeues the
last buffer, and then device_run is called, bail out. For that the
interrupt handler has to be threaded.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
Changes since v1:
- Included the fix by Wei Yongjun, adding a missing unlock in the
coda_stop_streaming() error handling case.
- Restricted check for available bitstream data in coda_job_ready()
to the decoder case.
---
drivers/media/platform/coda.c | 787
++
drivers/media/platform/coda.h | 84 +
2 files changed, 813 insertions(+), 58 deletions(-)
diff --git a/drivers/media/platform/coda.c
b/drivers/media/platform/coda.c index e8b3708..9cbdea6 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -29,6 +29,7 @@
#include media/v4l2-ctrls.h
#include media/v4l2-device.h
+#include media/v4l2-event.h
#include media/v4l2-ioctl.h
#include media/v4l2-mem2mem.h
#include media/videobuf2-core.h
@@ -47,9 +48,11 @@
#define CODA_PARA_BUF_SIZE (10 * 1024)
#define CODA_ISRAM_SIZE (2048 * 2)
#define CODADX6_IRAM_SIZE0xb000
-#define CODA7_IRAM_SIZE 0x14000 /* 81920 bytes */
+#define CODA7_IRAM_SIZE 0x14000
-#define CODA_MAX_FRAMEBUFFERS2
+#define CODA7_PS_BUF_SIZE0x28000
+
+#define CODA_MAX_FRAMEBUFFERS8
#define MAX_W8192
#define MAX_H8192
@@ -178,12 +181,16 @@ struct coda_iram_info {
struct coda_ctx {
struct coda_dev *dev;
+ struct mutexbuffer_mutex;
struct list_headlist;
+ struct work_struct skip_run;
int aborting;
+ int initialized;
int streamon_out;
int streamon_cap;
u32 isequence;
u32 qsequence;
+ u32 osequence;
struct coda_q_data q_data[2];
enum coda_inst_type inst_type;
struct coda_codec *codec;
@@ -193,12 +200,16 @@ struct coda_ctx {
struct v4l2_ctrl_handlerctrls;
struct v4l2_fh fh;
int gopcounter;
+ int runcounter;
charvpu_header[3][64];
int vpu_header_size[3];
struct kfifobitstream_fifo;
struct mutexbitstream_mutex;
struct coda_aux_buf bitstream;
+ boolprescan_failed;
struct coda_aux_buf parabuf;
+ struct coda_aux_buf psbuf;
+ struct coda_aux_buf slicebuf;
struct coda_aux_buf
internal_frames[CODA_MAX_FRAMEBUFFERS];
struct coda_aux_buf workbuf;
int num_internal_frames;
@@ -206,6 +217,8 @@ struct coda_ctx {
int reg_idx;
Bewerben Sie sich für Darlehen
-- Haben Sie schon unten durch Banken oder finanzielle Kreditgeber eingeschaltet? Sind Sie in Schulden? Sie benötigen einen schnellen Kredit für Unternehmen? Dann ist hier die Chance, Ihr Unternehmen bieten persönliche und geschäftliche Darlehen an Individuen, ist unser Zinssatz bei 3% Zinsen per annum festgelegt, in die ein Kreditnehmer zurückzahlen kann in einem bestimmten Zeitraum. Wenn Sie interessiert sind, kontaktieren Sie uns jetzt an bistolcreditservi...@yahoo.ca Hier sind die Informationen ist erforderlich: * Vollständiger Name * Darlehensbetrag benötigt: * Zweck des Darlehens: * Dauer der Ausleihe: * Land: * Telefon: Durch unsere unbesicherten und Secured Loan Programs, können wir jede Art der Finanzierung, dass ein Unternehmen benötigen. Wir gestalten unser Programm passen Ihre Bedürfnisse, nicht unsere. In den meisten Fällen werden Sie feststellen, dass wir haben Optionen aus die nicht von Banken angeboten. Zur weiteren besprechen Sie Ihre Situation, bitte kontaktieren Sie uns jetzt bistolcreditservi...@yahoo.ca für die Anwendung -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/3] R8A7779/Marzen R-Car VIN driver support
Hello. On 27-06-2013 11:41, Simon Horman wrote: Here's the set of 3 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130515v2' tag and my recent yet unapplied USB/I2C patches. Here we add the VIN driver platform code for the R8A7779/Marzen with ADV7180 I2C video decoder. [1/3] ARM: shmobile: r8a7779: add VIN support [2/3] ARM: shmobile: Marzen: add VIN and ADV7180 support [3/3] ARM: shmobile: Marzen: enable VIN and ADV7180 in defconfig The VIN driver itself has been excluded from the series as it will be developed against Mauro's 'media_tree.git' plus some yet unapplied patches in the future... Sergei, is this patch-set still needing review? Probably. Note that it depends on the VIN driver too. WBR, Sergei -- 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 v2 8/8] [media] coda: add CODA7541 decoding support
Hi Kamil, Am Donnerstag, den 27.06.2013, 12:10 +0200 schrieb Kamil Debski: Hi Philipp, This patch did not apply well on my tree. I find this quite strange. I did try and applied it manually, but please check here if it is correct: http://git.linuxtv.org/kdebski/media.git/shortlog/refs/heads/master yes, the commit contents are identical. thanks Philipp -- 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 RFC v3] s5k5baf: add camera sensor driver
Hi Andrzej,
On 06/05/2013 01:44 PM, Andrzej Hajda wrote:
Driver for Samsung S5K5BAF UXGA 1/5 2M CMOS Image Sensor
with embedded SoC ISP.
The driver exposes the sensor as two V4L2 subdevices:
- S5K5BAF-CIS - pure CMOS Image Sensor, fixed 1600x1200 format,
no controls.
- S5K5BAF-ISP - Image Signal Processor, formats up to 1600x1200,
pre/post ISP cropping, downscaling via selection API, controls.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
v3:
- narrowed state-error usage to i2c and power errors,
Hmm, there still seems to be quite a few functions that use state-error
and IMHO it would be better if those just return the result directly.
How about changing at least these:
static void s5k5baf_check_fw_revision(struct s5k5baf *state)
static void s5k5baf_hw_set_video_bus(struct s5k5baf *state)
static void s5k5baf_power_on(struct s5k5baf *state)
static void s5k5baf_power_off(struct s5k5baf *state)
static void s5k5baf_hw_set_crop_rects(struct s5k5baf *state)
to return result directly ?
Personally I would also convert functins used in s5k5baf_s_ctrl()
handler:
s5k5baf_hw_set_awb()
s5k5baf_hw_set_colorfx()
s5k5baf_hw_set_auto_exposure()
s5k5baf_hw_set_mirror()
s5k5baf_hw_set_anti_flicker()
s5k5baf_hw_set_test_pattern()
And have state-err cleared at beginning of s5k5baf_s_ctrl().
But I'll probably not complain if those are left as they are. :)
- private gain controls replaced by red/blue balance user controls,
- added checks to devicetree gpio node parsing
v2:
- lower-cased driver name,
- removed underscore from regulator names,
- removed platform data code,
- v4l controls grouped in anonymous structs,
- added s5k5baf_clear_error function,
- private controls definitions moved to uapi header file,
- added v4l2-controls.h reservation for private controls,
- corrected subdev registered/unregistered code,
- .log_status sudbev op set to v4l2 helper,
- moved entity link creation to probe routines,
- added cleanup on error to probe function.
---
.../devicetree/bindings/media/samsung-s5k5baf.txt | 53 +
MAINTAINERS|7 +
drivers/media/i2c/Kconfig |7 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/s5k5baf.c| 1979
5 files changed, 2047 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/samsung-s5k5baf.txt
create mode 100644 drivers/media/i2c/s5k5baf.c
diff --git a/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt
b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt
new file mode 100644
index 000..0e46743
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt
@@ -0,0 +1,53 @@
+Samsung S5K5BAF UXGA 1/5 2M CMOS Image Sensor with embedded SoC ISP
+-
+
+Required properties:
+
+- compatible : samsung,s5k5baf;
+- reg : i2c slave address of the sensor;
i2c should be capitalized.
[...]
+/* Auto-algorithms enable mask */
+#define REG_DBG_AUTOALG_EN 0x03f8
+#define AALG_ALL_EN BIT(0)
+#define AALG_AE_EN BIT(1)
+#define AALG_DIVLEI_EN BIT(2)
+#define AALG_WB_EN BIT(3)
+#define AALG_USE_WB_FOR_ISP BIT(4)
+#define AALG_FLICKER_EN BIT(5)
+#define AALG_FIT_EN BIT(6)
+#define AALG_WRHW_ENBIT(7)
Perhaps some comment on what the below definitions refer to ?
+#define REG_PTR_CCM_HORIZON 0x06d0
+#define REG_PTR_CCM_INCANDESCENT 0x06d4
+#define REG_PTR_CCM_WARM_WHITE 0x06d8
+#define REG_PTR_CCM_COOL_WHITE 0x06dc
+#define REG_PTR_CCM_DL50 0x06e0
+#define REG_PTR_CCM_DL65 0x06e4
+#define REG_PTR_CCM_OUTDOOR 0x06ec
+
+#define REG_ARR_CCM(n) (0x2800 + 36 * (n))
+
[...]
+struct s5k5baf_ctrls {
+ struct v4l2_ctrl_handler handler;
+ struct { /* Auto / manual white balance cluster */
+ struct v4l2_ctrl *awb;
+ struct v4l2_ctrl *gain_red;
+ struct v4l2_ctrl *gain_blue;
+ };
+ struct { /* Mirror cluster */
+ struct v4l2_ctrl *hflip;
+ struct v4l2_ctrl *vflip;
+ };
+ struct { /* Auto exposure / manual exposure and gain cluster */
+ struct v4l2_ctrl *auto_exp;
+ struct v4l2_ctrl *exposure;
+ struct v4l2_ctrl *gain;
+ };
+};
+
+struct s5k5baf {
+ u32 mclk_frequency;
+ struct s5k5baf_gpio gpios[2];
struct s5k5baf_gpio gpios[GPIO_NUM]; ?
+ enum v4l2_mbus_type bus_type;
+ u8 nlanes;
+ u8
Re: linux-next: Tree for Jun 27 (v4l2 usbtv)
On 06/27/13 02:24, Stephen Rothwell wrote: Hi all, Changes since 20130626: on i386: CONFIG_VIDEO_USBTV=y CONFIG_I2C=m CONFIG_VIDEO_V4L2=m Looks like VIDEO_USBTV should depend on VIDEO_V4L2. drivers/built-in.o: In function `vb2_fop_mmap': (.text+0x199b4e): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_streamoff': (.text+0x19a00b): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_streamon': (.text+0x19a134): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_expbuf': (.text+0x19a2cb): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_querybuf': (.text+0x19a3fe): undefined reference to `video_devdata' drivers/built-in.o:(.text+0x19ad7d): more undefined references to `video_devdata' follow drivers/built-in.o: In function `vb2_poll': (.text+0x19bef0): undefined reference to `v4l2_event_pending' drivers/built-in.o: In function `vb2_fop_poll': (.text+0x19c0ce): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_fop_release': (.text+0x19c21c): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_fop_release': (.text+0x19c24a): undefined reference to `v4l2_fh_release' drivers/built-in.o: In function `usbtv_release': usbtv.c:(.text+0x1a9411): undefined reference to `v4l2_device_unregister' drivers/built-in.o: In function `usbtv_querycap': usbtv.c:(.text+0x1a942e): undefined reference to `video_devdata' drivers/built-in.o: In function `usbtv_probe': usbtv.c:(.text+0x1a95da): undefined reference to `v4l2_device_register' usbtv.c:(.text+0x1a961e): undefined reference to `video_device_release_empty' usbtv.c:(.text+0x1a9689): undefined reference to `__video_register_device' usbtv.c:(.text+0x1a96a3): undefined reference to `v4l2_device_unregister' drivers/built-in.o: In function `usbtv_disconnect': usbtv.c:(.text+0x1a9937): undefined reference to `video_unregister_device' usbtv.c:(.text+0x1a993e): undefined reference to `v4l2_device_disconnect' drivers/built-in.o: In function `usbtv_iso_cb': usbtv.c:(.text+0x1a9b5c): undefined reference to `v4l2_get_timestamp' drivers/built-in.o: In function `usbtv_disconnect': usbtv.c:(.text+0x1a9966): undefined reference to `v4l2_device_put' drivers/built-in.o:(.data+0x22918): undefined reference to `video_ioctl2' drivers/built-in.o:(.data+0x22924): undefined reference to `v4l2_fh_open' -- ~Randy -- 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
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Jun 27 19:00:19 CEST 2013 git branch: test git hash: 188af63c0af2d7ef395bc94e3efa173f34dae03d gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: v0.4.5-rc1 host hardware: x86_64 host os:3.9-7.slh.1-amd64 linux-git-arm-at91: WARNINGS linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: OK linux-git-arm-mx: WARNINGS linux-git-arm-omap: WARNINGS linux-git-arm-omap1: WARNINGS linux-git-arm-pxa: WARNINGS linux-git-blackfin: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: WARNINGS linux-git-sh: WARNINGS linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.10-rc1-i686: OK linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.10-rc1-x86_64: OK linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse version: v0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- 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
lgdt3304
Has the driver for lgdt3304 been tested ? I am trying to get a new card
working
AVerMedia AVerTVHD Duet PCTV tuner (A188) A188-AF PCI-Express x1 Interface
It is using
1 x saa7160E
2 x LGDT3304
2 x TDA18271HD/C2
I get so far that I can load a basic driver by modifying the existing
saa716x driver, I can detect the TDA18271HD/C2, but I fail to detect the
LGDT3304 when attaching it using the 3305 driver.
I always fail at the first read from LGDT3305_GEN_CTRL_2, does this register
even exist in lgdt3304 or is it specific to lgdt3305?
/* verify that we're talking to a lg dt3304/5 */
ret = lgdt3305_read_reg(state, LGDT3305_GEN_CTRL_2, val);
if ((lg_fail(ret)) | (val == 0))
{
printk(fail 1\n);
goto fail;
}
Since I do find the TDA18271HD/C2 I don't think there is something wrong
with the i2c buss. I also tried every possible i2c address without success.
The lgdt3305 has option between address 0x0e and 0x59, is it the same for
3304 ?
This is the first time I am trying to get a driver to work in Linux. Please
help me.
Thanks /// Carl-Fredrik
--
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: lgdt3304
I get so far that I can load a basic driver by modifying the existing saa716x driver, I can detect the TDA18271HD/C2, but I fail to detect the LGDT3304 when attaching it using the 3305 driver. A GPIO holding the 3304 in reset? -- Steven Toth - Kernel Labs http://www.kernellabs.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: lgdt3304
On Thu, Jun 27, 2013 at 2:38 PM, Carl-Fredrik Sundstrom
c...@blueflowamericas.com wrote:
Has the driver for lgdt3304 been tested ? I am trying to get a new card
working
AVerMedia AVerTVHD Duet PCTV tuner (A188) A188-AF PCI-Express x1 Interface
It is using
1 x saa7160E
2 x LGDT3304
2 x TDA18271HD/C2
I get so far that I can load a basic driver by modifying the existing
saa716x driver, I can detect the TDA18271HD/C2, but I fail to detect the
LGDT3304 when attaching it using the 3305 driver.
I always fail at the first read from LGDT3305_GEN_CTRL_2, does this register
even exist in lgdt3304 or is it specific to lgdt3305?
/* verify that we're talking to a lg dt3304/5 */
ret = lgdt3305_read_reg(state, LGDT3305_GEN_CTRL_2, val);
if ((lg_fail(ret)) | (val == 0))
{
printk(fail 1\n);
goto fail;
}
Since I do find the TDA18271HD/C2 I don't think there is something wrong
with the i2c buss. I also tried every possible i2c address without success.
The lgdt3305 has option between address 0x0e and 0x59, is it the same for
3304 ?
This is the first time I am trying to get a driver to work in Linux. Please
help me.
Either the i2c is broken or the lgdt3304 is being held in reset by a GPIO.
Also, that device has multiple i2c busses, so you could be looking on
the wrong bus.
Do you see *any* i2c devices (such as an eeprom).
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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: lgdt3304
One of the TDA18271HD/C2 is detected on the secondary i2c bus at address
0x60. I haven't tried yet to find the second one.
The SAA7160E PCI-E interface has the following GPIO
GPIO_[15:1]: interrupts from other external devices
GPIO_[23:16]: chip select to other external devices
GPIO_[29:26]: general purpose
BOOT_0 and BOOT_1: boot mode. The boot mode pins can be used as application
GPIO pins after 500 ms (after power-up). The boot mode has been latched.
All of them are input and output with internal pull-up, so they should all
be set high.
Should I just try to change them all to outputs and then set them low one by
one until something answers at address 0x0e or 0x59?
Thanks /// Carl
-Original Message-
From: Devin Heitmueller [mailto:dheitmuel...@kernellabs.com]
Sent: Thursday, June 27, 2013 1:59 PM
To: Carl-Fredrik Sundstrom
Cc: linux-media@vger.kernel.org
Subject: Re: lgdt3304
On Thu, Jun 27, 2013 at 2:38 PM, Carl-Fredrik Sundstrom
c...@blueflowamericas.com wrote:
Has the driver for lgdt3304 been tested ? I am trying to get a new
card working
AVerMedia AVerTVHD Duet PCTV tuner (A188) A188-AF PCI-Express x1
Interface
It is using
1 x saa7160E
2 x LGDT3304
2 x TDA18271HD/C2
I get so far that I can load a basic driver by modifying the existing
saa716x driver, I can detect the TDA18271HD/C2, but I fail to detect
the
LGDT3304 when attaching it using the 3305 driver.
I always fail at the first read from LGDT3305_GEN_CTRL_2, does this
register even exist in lgdt3304 or is it specific to lgdt3305?
/* verify that we're talking to a lg dt3304/5 */
ret = lgdt3305_read_reg(state, LGDT3305_GEN_CTRL_2, val);
if ((lg_fail(ret)) | (val == 0))
{
printk(fail 1\n);
goto fail;
}
Since I do find the TDA18271HD/C2 I don't think there is something
wrong with the i2c buss. I also tried every possible i2c address without
success.
The lgdt3305 has option between address 0x0e and 0x59, is it the same
for
3304 ?
This is the first time I am trying to get a driver to work in Linux.
Please help me.
Either the i2c is broken or the lgdt3304 is being held in reset by a GPIO.
Also, that device has multiple i2c busses, so you could be looking on the
wrong bus.
Do you see *any* i2c devices (such as an eeprom).
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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: lgdt3304
I found a datasheet for lgdt3305 it does indeed have a reset pin at pin 37 active low with internal pull up. I will try to attach a probe to that pin and walk through all of the GPIO until I find the right one. I hope that lgdt3304 and lgdt3305 are pin compatible otherwise I might not have much success. -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Steven Toth Sent: Thursday, June 27, 2013 1:59 PM To: Carl-Fredrik Sundstrom Cc: linux-media@vger.kernel.org Subject: Re: lgdt3304 I get so far that I can load a basic driver by modifying the existing saa716x driver, I can detect the TDA18271HD/C2, but I fail to detect the LGDT3304 when attaching it using the 3305 driver. A GPIO holding the 3304 in reset? -- Steven Toth - Kernel Labs http://www.kernellabs.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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] v4l-utils: Fix crashes found by Mayhem
The Mayhem Team ran their code checker over the Debian archive and also found two crashes in v4l-utils. See http://lists.debian.org/debian-devel/2013/06/msg00720.html Gregor Jasny (2): libv4lconvert: Prevent integer overflow by checking width and height keytable: Always check if strtok return value is null lib/libv4lconvert/ov511-decomp.c | 7 ++- lib/libv4lconvert/ov518-decomp.c | 7 ++- utils/keytable/keytable.c| 19 --- 3 files changed, 28 insertions(+), 5 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] libv4lconvert: Prevent integer overflow by checking width and height
The Mayhem Team found a crash caused by an integer overflow.
Details are here:
http://www.forallsecure.com/bug-reports/8aae67d864bce76993f3f9812b4a2aeea0eb38da/
Signed-off-by: Gregor Jasny gja...@googlemail.com
---
lib/libv4lconvert/ov511-decomp.c | 7 ++-
lib/libv4lconvert/ov518-decomp.c | 7 ++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/lib/libv4lconvert/ov511-decomp.c b/lib/libv4lconvert/ov511-decomp.c
index 90fc4b1..971d497 100644
--- a/lib/libv4lconvert/ov511-decomp.c
+++ b/lib/libv4lconvert/ov511-decomp.c
@@ -14,6 +14,7 @@
* Free Software Foundation; version 2 of the License.
*/
+#include limits.h
#include string.h
#include unistd.h
#include helper-funcs.h
@@ -640,7 +641,11 @@ int main(int argc, char *argv[])
dest_size = width * height * 3 / 2;
- if (dest_size sizeof(dest_buf)) {
+ if (width = 0 || width SHRT_MAX || height = 0 || height
SHRT_MAX) {
+ fprintf(stderr, %s: error: width or height out of
bounds\n,
+ argv[0]);
+ dest_size = -1;
+ } else if (dest_size sizeof(dest_buf)) {
fprintf(stderr, %s: error: dest_buf too small, need:
%d\n,
argv[0], dest_size);
dest_size = -1;
diff --git a/lib/libv4lconvert/ov518-decomp.c b/lib/libv4lconvert/ov518-decomp.c
index 47b5cbb..91d908c 100644
--- a/lib/libv4lconvert/ov518-decomp.c
+++ b/lib/libv4lconvert/ov518-decomp.c
@@ -15,6 +15,7 @@
* Free Software Foundation; version 2 of the License.
*/
+#include limits.h
#include string.h
#include unistd.h
#include helper-funcs.h
@@ -1454,7 +1455,11 @@ int main(int argc, char *argv[])
dest_size = width * height * 3 / 2;
- if (dest_size sizeof(dest_buf)) {
+ if (width = 0 || width SHRT_MAX || height = 0 || height
SHRT_MAX) {
+ fprintf(stderr, %s: error: width or height out of
bounds\n,
+ argv[0]);
+ dest_size = -1;
+ } else if (dest_size sizeof(dest_buf)) {
fprintf(stderr, %s: error: dest_buf too small, need:
%d\n,
argv[0], dest_size);
dest_size = -1;
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] keytable: Always check if strtok return value is null
The Mayhem Team found a crash caused by a nullptr.
Details are here:
http://www.forallsecure.com/bug-reports/567323cd26f180910beb03ae26afb40c432a0c6a/
Signed-off-by: Gregor Jasny gja...@googlemail.com
---
utils/keytable/keytable.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/utils/keytable/keytable.c b/utils/keytable/keytable.c
index 06b3d95..8bcd5c4 100644
--- a/utils/keytable/keytable.c
+++ b/utils/keytable/keytable.c
@@ -207,13 +207,19 @@ static error_t parse_keyfile(char *fname, char **table)
p++;
p = strtok(p, \n\t =:);
do {
+ if (!p)
+ goto err_einval;
if (!strcmp(p, table)) {
p = strtok(NULL,\n, );
+ if (!p)
+ goto err_einval;
*table = malloc(strlen(p) + 1);
strcpy(*table, p);
} else if (!strcmp(p, type)) {
p = strtok(NULL, ,\n);
do {
+ if (!p)
+ goto err_einval;
if (!strcasecmp(p,rc5) ||
!strcasecmp(p,rc-5))
ch_proto |= RC_5;
else if (!strcasecmp(p,rc6)
|| !strcasecmp(p,rc-6))
@@ -447,6 +453,8 @@ static error_t parse_opt(int k, char *arg, struct
argp_state *state)
case 'p':
p = strtok(arg, ,;);
do {
+ if (!p)
+ goto err_inval;
if (!strcasecmp(p,rc5) || !strcasecmp(p,rc-5))
ch_proto |= RC_5;
else if (!strcasecmp(p,rc6) || !strcasecmp(p,rc-6))
@@ -813,14 +821,19 @@ static int v1_get_sw_enabled_protocol(char *dirname)
return 0;
}
- p = strtok(buf, \n);
- rc = atoi(p);
-
if (fclose(fp)) {
perror(name);
return errno;
}
+ p = strtok(buf, \n);
+ if (!p) {
+ fprintf(stderr, %s has invalid content: '%s'\n, name, buf);
+ return 0;
+ }
+
+ rc = atoi(p);
+
if (debug)
fprintf(stderr, protocol %s is %s\n,
name, rc? enabled : disabled);
--
1.8.3.1
--
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 0/2] v4l-utils: Fix crashes found by Mayhem
Hi, Thanks for working on this, both patches look good, ack series. Regards, Hans On 06/27/2013 11:11 PM, Gregor Jasny wrote: The Mayhem Team ran their code checker over the Debian archive and also found two crashes in v4l-utils. See http://lists.debian.org/debian-devel/2013/06/msg00720.html Gregor Jasny (2): libv4lconvert: Prevent integer overflow by checking width and height keytable: Always check if strtok return value is null lib/libv4lconvert/ov511-decomp.c | 7 ++- lib/libv4lconvert/ov518-decomp.c | 7 ++- utils/keytable/keytable.c| 19 --- 3 files changed, 28 insertions(+), 5 deletions(-) -- 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
дистанционная методика кадровой переподготовки
склонны обратиться акулой бизнеса? http://goo.gl/1cPy9?/biASSPhabX -- 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 v7] V4L2: soc_camera: Renesas R-Car VIN driver
Hi Guennadi,
Guennadi Liakhovetski wrote:
Hi Sergei
On Sat, 22 Jun 2013, Sergei Shtylyov wrote:
From: Vladimir Barinov vladimir.bari...@cogentembedded.com
Add Renesas R-Car VIN (Video In) V4L2 driver.
Based on the patch by Phil Edworthy phil.edwor...@renesas.com.
Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
[Sergei: removed deprecated IRQF_DISABLED flag, reordered/renamed 'enum chip_id'
values, reordered rcar_vin_id_table[] entries, removed senseless parens from
to_buf_list() macro, used ALIGN() macro in rcar_vin_setup(), added {} to the
*if* statement and used 'bool' values instead of 0/1 where necessary, removed
unused macros, done some reformatting and clarified some comments.]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Reviewing this iteration of the patch is still on my todo, in the meantime
you might verify whether it works on top of the for-3.11-3 branch of my
http://git.linuxtv.org/gliakhovetski/v4l-dvb.git
git-tree, or next after it's been pulled by Mauro and pushed upstream.
With that branch you shouldn't need any additional patches andy more.
Actually we need to apply/merge more patches here that enables VIN
support on separate platform (like pinctrl/clock/setup/) :)
Despite of above the rcar_vin driver works fine on Marzen board in
v4l-dvb.git after adding soc_camera_host_ops clock_start/clock_stop.
Regards,
Vladimir
--
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: lgdt3304
I am able to detect two lgdt3304 one on each i2c bus now. As you suspected I
had to set GPIO pin 17 for them to come alive.
Now to my next question, how do I attach two front ends I have two lgdt3304
and two TDA18271HD/C2
Is there a good driver I can look at where they do that ?
Thanks /// Carl
-Original Message-
From: Devin Heitmueller [mailto:dheitmuel...@kernellabs.com]
Sent: Thursday, June 27, 2013 1:59 PM
To: Carl-Fredrik Sundstrom
Cc: linux-media@vger.kernel.org
Subject: Re: lgdt3304
On Thu, Jun 27, 2013 at 2:38 PM, Carl-Fredrik Sundstrom
c...@blueflowamericas.com wrote:
Has the driver for lgdt3304 been tested ? I am trying to get a new
card working
AVerMedia AVerTVHD Duet PCTV tuner (A188) A188-AF PCI-Express x1
Interface
It is using
1 x saa7160E
2 x LGDT3304
2 x TDA18271HD/C2
I get so far that I can load a basic driver by modifying the existing
saa716x driver, I can detect the TDA18271HD/C2, but I fail to detect
the
LGDT3304 when attaching it using the 3305 driver.
I always fail at the first read from LGDT3305_GEN_CTRL_2, does this
register even exist in lgdt3304 or is it specific to lgdt3305?
/* verify that we're talking to a lg dt3304/5 */
ret = lgdt3305_read_reg(state, LGDT3305_GEN_CTRL_2, val);
if ((lg_fail(ret)) | (val == 0))
{
printk(fail 1\n);
goto fail;
}
Since I do find the TDA18271HD/C2 I don't think there is something
wrong with the i2c buss. I also tried every possible i2c address without
success.
The lgdt3305 has option between address 0x0e and 0x59, is it the same
for
3304 ?
This is the first time I am trying to get a driver to work in Linux.
Please help me.
Either the i2c is broken or the lgdt3304 is being held in reset by a GPIO.
Also, that device has multiple i2c busses, so you could be looking on the
wrong bus.
Do you see *any* i2c devices (such as an eeprom).
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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
[PATCH 0/3] Generic PHY driver for the Exynos SoC DP PHY
This patch series adds a simple driver for the Samsung Exynos SoC series DP transmitter PHY, using the generic PHY framework [1]. Previously the DP PHY used a platform callback or internal DT node to control the PHY power enable bit. The platform callback and internal DT node can be dropped and this driver does not need any calls back to the platform code. This series depends on the generic PHY framework [1]. These patches refer to Sylwester Nawrocki's patches about Exynos MIPI [2]. [1] https://lkml.org/lkml/2013/6/26/259 [2] http://www.spinics.net/lists/linux-samsung-soc/msg20034.html Jingoo Han (3): phy: Add driver for Exynos DP PHY ARM: dts: Add DP PHY node to exynos5250.dtsi video: exynos_dp: Use the generic PHY driver .../phy/samsung,exynos5250-dp-video-phy.txt|7 ++ .../devicetree/bindings/video/exynos_dp.txt| 17 --- arch/arm/boot/dts/exynos5250.dtsi | 13 - drivers/phy/Kconfig|8 ++ drivers/phy/Makefile |3 +- drivers/phy/phy-exynos-dp-video.c | 130 drivers/video/exynos/exynos_dp_core.c | 118 ++-- drivers/video/exynos/exynos_dp_core.h |2 + include/video/exynos_dp.h |6 +- 9 files changed, 170 insertions(+), 134 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt create mode 100644 drivers/phy/phy-exynos-dp-video.c -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] phy: Add driver for Exynos DP PHY
Add a PHY provider driver for the Samsung Exynos SoC DP PHY.
Signed-off-by: Jingoo Han jg1@samsung.com
---
.../phy/samsung,exynos5250-dp-video-phy.txt|7 ++
drivers/phy/Kconfig|8 ++
drivers/phy/Makefile |3 +-
drivers/phy/phy-exynos-dp-video.c | 130
4 files changed, 147 insertions(+), 1 deletion(-)
create mode 100644
Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt
create mode 100644 drivers/phy/phy-exynos-dp-video.c
diff --git
a/Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt
b/Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt
new file mode 100644
index 000..8b6fa79
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt
@@ -0,0 +1,7 @@
+Samsung EXYNOS SoC series DP PHY
+-
+
+Required properties:
+- compatible : should be samsung,exynos5250-dp-video-phy;
+- reg : offset and length of the DP PHY register set;
+- #phy-cells : from the generic phy bindings, must be 1;
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 5f85909..6d10e3b 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -11,3 +11,11 @@ menuconfig GENERIC_PHY
devices present in the kernel. This layer will have the generic
API by which phy drivers can create PHY using the phy framework and
phy users can obtain reference to the PHY.
+
+if GENERIC_PHY
+
+config PHY_EXYNOS_DP_VIDEO
+ tristate EXYNOS SoC series DP PHY driver
+ help
+ Support for DP PHY found on Samsung EXYNOS SoCs.
+endif
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9e9560f..d8d861c 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -2,4 +2,5 @@
# Makefile for the phy drivers.
#
-obj-$(CONFIG_GENERIC_PHY) += phy-core.o
+obj-$(CONFIG_GENERIC_PHY) += phy-core.o
+obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
diff --git a/drivers/phy/phy-exynos-dp-video.c
b/drivers/phy/phy-exynos-dp-video.c
new file mode 100644
index 000..376b3bc2
--- /dev/null
+++ b/drivers/phy/phy-exynos-dp-video.c
@@ -0,0 +1,130 @@
+/*
+ * Samsung EXYNOS SoC series DP PHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Jingoo Han jg1@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/phy/phy.h
+#include linux/platform_device.h
+#include linux/spinlock.h
+
+/* DPTX_PHY_CONTROL register */
+#define EXYNOS_DPTX_PHY_ENABLE (1 0)
+
+struct exynos_dp_video_phy {
+ spinlock_t slock;
+ struct phy *phys;
+ void __iomem *regs;
+};
+
+static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int on)
+{
+ void __iomem *addr;
+ unsigned long flags;
+ u32 reg;
+
+ addr = state-regs;
+
+ spin_lock_irqsave(state-slock, flags);
+ reg = readl(addr);
+ if (on)
+ reg |= EXYNOS_DPTX_PHY_ENABLE;
+ else
+ reg = ~EXYNOS_DPTX_PHY_ENABLE;
+ writel(reg, addr);
+ spin_unlock_irqrestore(state-slock, flags);
+ return 0;
+}
+
+static int exynos_dp_video_phy_power_on(struct phy *phy)
+{
+ struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
+
+ return __set_phy_state(state, 1);
+}
+
+static int exynos_dp_video_phy_power_off(struct phy *phy)
+{
+ struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
+
+ return __set_phy_state(state, 0);
+}
+
+static struct phy *exynos_dp_video_phy_xlate(struct device *dev,
+ struct of_phandle_args *args)
+{
+ struct exynos_dp_video_phy *state = dev_get_drvdata(dev);
+
+ return state-phys;
+}
+
+static struct phy_ops exynos_dp_video_phy_ops = {
+ .power_on = exynos_dp_video_phy_power_on,
+ .power_off = exynos_dp_video_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static int exynos_dp_video_phy_probe(struct platform_device *pdev)
+{
+ struct exynos_dp_video_phy *state;
+ struct device *dev = pdev-dev;
+ struct resource *res;
+ struct phy_provider *phy_provider;
+
+ state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+ state-regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(state-regs))
+ return PTR_ERR(state-regs);
+
+ dev_set_drvdata(dev, state);
+
+ phy_provider =
[PATCH 2/3] ARM: dts: Add DP PHY node to exynos5250.dtsi
Add PHY provider node for the DP PHY.
Signed-off-by: Jingoo Han jg1@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 41cd625..d1d6e14 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -614,6 +614,12 @@
interrupts = 0 94 0;
};
+ dp_phy: video-phy@10040720 {
+ compatible = samsung,exynos5250-dp-video-phy;
+ reg = 0x10040720 4;
+ #phy-cells = 1;
+ };
+
dp-controller {
compatible = samsung,exynos5-dp;
reg = 0x145b 0x1000;
@@ -623,11 +629,8 @@
clock-names = dp;
#address-cells = 1;
#size-cells = 0;
-
- dptx-phy {
- reg = 0x10040720;
- samsung,enable-mask = 1;
- };
+ phys = dp_phy 0;
+ phy-names = dp;
};
fimd {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] video: exynos_dp: Use the generic PHY driver
Use the generic PHY API instead of the platform callback to control
the DP PHY. The 'phy_label' field is added to the platform data
structure to allow PHY lookup on non-dt platforms.
Signed-off-by: Jingoo Han jg1@samsung.com
---
.../devicetree/bindings/video/exynos_dp.txt| 17 ---
drivers/video/exynos/exynos_dp_core.c | 118 ++--
drivers/video/exynos/exynos_dp_core.h |2 +
include/video/exynos_dp.h |6 +-
4 files changed, 15 insertions(+), 128 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 84f10c1..a8320e3 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -1,17 +1,6 @@
The Exynos display port interface should be configured based on
the type of panel connected to it.
-We use two nodes:
- -dp-controller node
- -dptx-phy node(defined inside dp-controller node)
-
-For the DP-PHY initialization, we use the dptx-phy node.
-Required properties for dptx-phy:
- -reg:
- Base address of DP PHY register.
- -samsung,enable-mask:
- The bit-mask used to enable/disable DP PHY.
-
For the Panel initialization, we read data from dp-controller node.
Required properties for dp-controller:
-compatible:
@@ -67,12 +56,6 @@ SOC specific portion:
interrupt-parent = combiner;
clocks = clock 342;
clock-names = dp;
-
- dptx-phy {
- reg = 0x10040720;
- samsung,enable-mask = 1;
- };
-
};
Board Specific portion:
diff --git a/drivers/video/exynos/exynos_dp_core.c
b/drivers/video/exynos/exynos_dp_core.c
index 12bbede..bac515b 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -19,6 +19,7 @@
#include linux/interrupt.h
#include linux/delay.h
#include linux/of.h
+#include linux/phy/phy.h
#include video/exynos_dp.h
@@ -960,84 +961,15 @@ static struct exynos_dp_platdata
*exynos_dp_dt_parse_pdata(struct device *dev)
return ERR_PTR(-EINVAL);
}
- return pd;
-}
-
-static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
-{
- struct device_node *dp_phy_node = of_node_get(dp-dev-of_node);
- u32 phy_base;
- int ret = 0;
-
- dp_phy_node = of_find_node_by_name(dp_phy_node, dptx-phy);
- if (!dp_phy_node) {
- dev_err(dp-dev, could not find dptx-phy node\n);
- return -ENODEV;
- }
-
- if (of_property_read_u32(dp_phy_node, reg, phy_base)) {
- dev_err(dp-dev, failed to get reg for dptx-phy\n);
- ret = -EINVAL;
- goto err;
- }
-
- if (of_property_read_u32(dp_phy_node, samsung,enable-mask,
- dp-enable_mask)) {
- dev_err(dp-dev, failed to get enable-mask for dptx-phy\n);
- ret = -EINVAL;
- goto err;
- }
-
- dp-phy_addr = ioremap(phy_base, SZ_4);
- if (!dp-phy_addr) {
- dev_err(dp-dev, failed to ioremap dp-phy\n);
- ret = -ENOMEM;
- goto err;
- }
-
-err:
- of_node_put(dp_phy_node);
-
- return ret;
-}
-
-static void exynos_dp_phy_init(struct exynos_dp_device *dp)
-{
- u32 reg;
-
- reg = __raw_readl(dp-phy_addr);
- reg |= dp-enable_mask;
- __raw_writel(reg, dp-phy_addr);
-}
-
-static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
-{
- u32 reg;
+ pd-phy_label = dp;
- reg = __raw_readl(dp-phy_addr);
- reg = ~(dp-enable_mask);
- __raw_writel(reg, dp-phy_addr);
+ return pd;
}
#else
static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
{
return NULL;
}
-
-static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
-{
- return -EINVAL;
-}
-
-static void exynos_dp_phy_init(struct exynos_dp_device *dp)
-{
- return;
-}
-
-static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
-{
- return;
-}
#endif /* CONFIG_OF */
static int exynos_dp_probe(struct platform_device *pdev)
@@ -1061,10 +993,6 @@ static int exynos_dp_probe(struct platform_device *pdev)
pdata = exynos_dp_dt_parse_pdata(pdev-dev);
if (IS_ERR(pdata))
return PTR_ERR(pdata);
-
- ret = exynos_dp_dt_parse_phydata(dp);
- if (ret)
- return ret;
} else {
pdata = pdev-dev.platform_data;
if (!pdata) {
@@ -1073,6 +1001,10 @@ static int exynos_dp_probe(struct platform_device *pdev)
}
}
+ dp-phy = devm_phy_get(pdev-dev, pdata-phy_label);
+ if (IS_ERR(dp-phy))
+ return
Re: [PATCH 1/3] phy: Add driver for Exynos DP PHY
Hi,
On Friday 28 June 2013 10:52 AM, Jingoo Han wrote:
Add a PHY provider driver for the Samsung Exynos SoC DP PHY.
Signed-off-by: Jingoo Han jg1@samsung.com
---
.../phy/samsung,exynos5250-dp-video-phy.txt|7 ++
drivers/phy/Kconfig|8 ++
drivers/phy/Makefile |3 +-
drivers/phy/phy-exynos-dp-video.c | 130
4 files changed, 147 insertions(+), 1 deletion(-)
create mode 100644
Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt
create mode 100644 drivers/phy/phy-exynos-dp-video.c
diff --git
a/Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt
b/Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt
new file mode 100644
index 000..8b6fa79
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt
@@ -0,0 +1,7 @@
+Samsung EXYNOS SoC series DP PHY
+-
+
+Required properties:
+- compatible : should be samsung,exynos5250-dp-video-phy;
+- reg : offset and length of the DP PHY register set;
+- #phy-cells : from the generic phy bindings, must be 1;
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 5f85909..6d10e3b 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -11,3 +11,11 @@ menuconfig GENERIC_PHY
devices present in the kernel. This layer will have the generic
API by which phy drivers can create PHY using the phy framework and
phy users can obtain reference to the PHY.
+
+if GENERIC_PHY
+
+config PHY_EXYNOS_DP_VIDEO
+ tristate EXYNOS SoC series DP PHY driver
+ help
+ Support for DP PHY found on Samsung EXYNOS SoCs.
+endif
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9e9560f..d8d861c 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -2,4 +2,5 @@
# Makefile for the phy drivers.
#
-obj-$(CONFIG_GENERIC_PHY) += phy-core.o
+obj-$(CONFIG_GENERIC_PHY) += phy-core.o
+obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
diff --git a/drivers/phy/phy-exynos-dp-video.c
b/drivers/phy/phy-exynos-dp-video.c
new file mode 100644
index 000..376b3bc2
--- /dev/null
+++ b/drivers/phy/phy-exynos-dp-video.c
@@ -0,0 +1,130 @@
+/*
+ * Samsung EXYNOS SoC series DP PHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Jingoo Han jg1@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
this header file is not needed here.
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/phy/phy.h
+#include linux/platform_device.h
+#include linux/spinlock.h
+
+/* DPTX_PHY_CONTROL register */
+#define EXYNOS_DPTX_PHY_ENABLE (1 0)
+
+struct exynos_dp_video_phy {
+ spinlock_t slock;
+ struct phy *phys;
+ void __iomem *regs;
+};
+
+static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int on)
+{
+ void __iomem *addr;
+ unsigned long flags;
+ u32 reg;
+
+ addr = state-regs;
+
+ spin_lock_irqsave(state-slock, flags);
+ reg = readl(addr);
+ if (on)
+ reg |= EXYNOS_DPTX_PHY_ENABLE;
+ else
+ reg = ~EXYNOS_DPTX_PHY_ENABLE;
+ writel(reg, addr);
+ spin_unlock_irqrestore(state-slock, flags);
+ return 0;
+}
+
+static int exynos_dp_video_phy_power_on(struct phy *phy)
+{
+ struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
+
+ return __set_phy_state(state, 1);
+}
+
+static int exynos_dp_video_phy_power_off(struct phy *phy)
+{
+ struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
+
+ return __set_phy_state(state, 0);
+}
+
+static struct phy *exynos_dp_video_phy_xlate(struct device *dev,
+ struct of_phandle_args *args)
+{
+ struct exynos_dp_video_phy *state = dev_get_drvdata(dev);
+
+ return state-phys;
you can instead use of_phy_simple_xlate for such simple cases.
+}
+
+static struct phy_ops exynos_dp_video_phy_ops = {
+ .power_on = exynos_dp_video_phy_power_on,
+ .power_off = exynos_dp_video_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static int exynos_dp_video_phy_probe(struct platform_device *pdev)
+{
+ struct exynos_dp_video_phy *state;
+ struct device *dev = pdev-dev;
+ struct resource *res;
+ struct phy_provider *phy_provider;
+
+ state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+ state-regs = devm_ioremap_resource(dev,
Re: [PATCH 2/3] ARM: dts: Add DP PHY node to exynos5250.dtsi
Hi,
On Friday 28 June 2013 10:53 AM, Jingoo Han wrote:
Add PHY provider node for the DP PHY.
Signed-off-by: Jingoo Han jg1@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 41cd625..d1d6e14 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -614,6 +614,12 @@
interrupts = 0 94 0;
};
+ dp_phy: video-phy@10040720 {
+ compatible = samsung,exynos5250-dp-video-phy;
+ reg = 0x10040720 4;
+ #phy-cells = 1;
phy-cells can be '0' here since this phy_provider implements only one PHY.
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: [PATCH 1/3] phy: Add driver for Exynos DP PHY
On Friday, June 28, 2013 2:31 PM, Kishon Vijay Abraham I wrote:
Hi,
On Friday 28 June 2013 10:52 AM, Jingoo Han wrote:
Add a PHY provider driver for the Samsung Exynos SoC DP PHY.
Signed-off-by: Jingoo Han jg1@samsung.com
---
.../phy/samsung,exynos5250-dp-video-phy.txt|7 ++
drivers/phy/Kconfig|8 ++
drivers/phy/Makefile |3 +-
drivers/phy/phy-exynos-dp-video.c | 130
4 files changed, 147 insertions(+), 1 deletion(-)
create mode 100644
Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt
create mode 100644 drivers/phy/phy-exynos-dp-video.c
diff --git
a/Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt
b/Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt
new file mode 100644
index 000..8b6fa79
--- /dev/null
+++
b/Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt
@@ -0,0 +1,7 @@
+Samsung EXYNOS SoC series DP PHY
+-
+
+Required properties:
+- compatible : should be samsung,exynos5250-dp-video-phy;
+- reg : offset and length of the DP PHY register set;
+- #phy-cells : from the generic phy bindings, must be 1;
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 5f85909..6d10e3b 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -11,3 +11,11 @@ menuconfig GENERIC_PHY
devices present in the kernel. This layer will have the generic
API by which phy drivers can create PHY using the phy framework and
phy users can obtain reference to the PHY.
+
+if GENERIC_PHY
+
+config PHY_EXYNOS_DP_VIDEO
+ tristate EXYNOS SoC series DP PHY driver
+ help
+ Support for DP PHY found on Samsung EXYNOS SoCs.
+endif
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9e9560f..d8d861c 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -2,4 +2,5 @@
# Makefile for the phy drivers.
#
-obj-$(CONFIG_GENERIC_PHY) += phy-core.o
+obj-$(CONFIG_GENERIC_PHY) += phy-core.o
+obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
diff --git a/drivers/phy/phy-exynos-dp-video.c
b/drivers/phy/phy-exynos-dp-video.c
new file mode 100644
index 000..376b3bc2
--- /dev/null
+++ b/drivers/phy/phy-exynos-dp-video.c
@@ -0,0 +1,130 @@
+/*
+ * Samsung EXYNOS SoC series DP PHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Jingoo Han jg1@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
this header file is not needed here.
OK, I will remove it.
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/phy/phy.h
+#include linux/platform_device.h
+#include linux/spinlock.h
+
+/* DPTX_PHY_CONTROL register */
+#define EXYNOS_DPTX_PHY_ENABLE (1 0)
+
+struct exynos_dp_video_phy {
+ spinlock_t slock;
+ struct phy *phys;
+ void __iomem *regs;
+};
+
+static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int
on)
+{
+ void __iomem *addr;
+ unsigned long flags;
+ u32 reg;
+
+ addr = state-regs;
+
+ spin_lock_irqsave(state-slock, flags);
+ reg = readl(addr);
+ if (on)
+ reg |= EXYNOS_DPTX_PHY_ENABLE;
+ else
+ reg = ~EXYNOS_DPTX_PHY_ENABLE;
+ writel(reg, addr);
+ spin_unlock_irqrestore(state-slock, flags);
+ return 0;
+}
+
+static int exynos_dp_video_phy_power_on(struct phy *phy)
+{
+ struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
+
+ return __set_phy_state(state, 1);
+}
+
+static int exynos_dp_video_phy_power_off(struct phy *phy)
+{
+ struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
+
+ return __set_phy_state(state, 0);
+}
+
+static struct phy *exynos_dp_video_phy_xlate(struct device *dev,
+ struct of_phandle_args *args)
+{
+ struct exynos_dp_video_phy *state = dev_get_drvdata(dev);
+
+ return state-phys;
you can instead use of_phy_simple_xlate for such simple cases.
OK, I will use of_phy_simple_xlate().
+}
+
+static struct phy_ops exynos_dp_video_phy_ops = {
+ .power_on = exynos_dp_video_phy_power_on,
+ .power_off = exynos_dp_video_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static int exynos_dp_video_phy_probe(struct platform_device *pdev)
+{
+ struct exynos_dp_video_phy *state;
+ struct device *dev = pdev-dev;
+ struct resource
Re: [PATCH 3/3] video: exynos_dp: Use the generic PHY driver
Hi,
On Friday 28 June 2013 10:54 AM, Jingoo Han wrote:
Use the generic PHY API instead of the platform callback to control
the DP PHY. The 'phy_label' field is added to the platform data
structure to allow PHY lookup on non-dt platforms.
Signed-off-by: Jingoo Han jg1@samsung.com
---
.../devicetree/bindings/video/exynos_dp.txt| 17 ---
drivers/video/exynos/exynos_dp_core.c | 118 ++--
drivers/video/exynos/exynos_dp_core.h |2 +
include/video/exynos_dp.h |6 +-
4 files changed, 15 insertions(+), 128 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 84f10c1..a8320e3 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -1,17 +1,6 @@
The Exynos display port interface should be configured based on
the type of panel connected to it.
-We use two nodes:
- -dp-controller node
- -dptx-phy node(defined inside dp-controller node)
-
-For the DP-PHY initialization, we use the dptx-phy node.
-Required properties for dptx-phy:
- -reg:
- Base address of DP PHY register.
- -samsung,enable-mask:
- The bit-mask used to enable/disable DP PHY.
-
For the Panel initialization, we read data from dp-controller node.
Required properties for dp-controller:
-compatible:
@@ -67,12 +56,6 @@ SOC specific portion:
interrupt-parent = combiner;
clocks = clock 342;
clock-names = dp;
-
- dptx-phy {
- reg = 0x10040720;
- samsung,enable-mask = 1;
- };
-
};
Board Specific portion:
diff --git a/drivers/video/exynos/exynos_dp_core.c
b/drivers/video/exynos/exynos_dp_core.c
index 12bbede..bac515b 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -19,6 +19,7 @@
#include linux/interrupt.h
#include linux/delay.h
#include linux/of.h
+#include linux/phy/phy.h
#include video/exynos_dp.h
@@ -960,84 +961,15 @@ static struct exynos_dp_platdata
*exynos_dp_dt_parse_pdata(struct device *dev)
return ERR_PTR(-EINVAL);
}
- return pd;
-}
-
-static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
-{
- struct device_node *dp_phy_node = of_node_get(dp-dev-of_node);
- u32 phy_base;
- int ret = 0;
-
- dp_phy_node = of_find_node_by_name(dp_phy_node, dptx-phy);
- if (!dp_phy_node) {
- dev_err(dp-dev, could not find dptx-phy node\n);
- return -ENODEV;
- }
-
- if (of_property_read_u32(dp_phy_node, reg, phy_base)) {
- dev_err(dp-dev, failed to get reg for dptx-phy\n);
- ret = -EINVAL;
- goto err;
- }
-
- if (of_property_read_u32(dp_phy_node, samsung,enable-mask,
- dp-enable_mask)) {
- dev_err(dp-dev, failed to get enable-mask for dptx-phy\n);
- ret = -EINVAL;
- goto err;
- }
-
- dp-phy_addr = ioremap(phy_base, SZ_4);
- if (!dp-phy_addr) {
- dev_err(dp-dev, failed to ioremap dp-phy\n);
- ret = -ENOMEM;
- goto err;
- }
-
-err:
- of_node_put(dp_phy_node);
-
- return ret;
-}
-
-static void exynos_dp_phy_init(struct exynos_dp_device *dp)
-{
- u32 reg;
-
- reg = __raw_readl(dp-phy_addr);
- reg |= dp-enable_mask;
- __raw_writel(reg, dp-phy_addr);
-}
-
-static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
-{
- u32 reg;
+ pd-phy_label = dp;
In the case of non-dt boot, this phy_label should have ideally come from
platform code.
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: [PATCH 2/3] ARM: dts: Add DP PHY node to exynos5250.dtsi
On Friday, June 28, 2013 2:42 PM, Kishon Vijay Abraham I wrote:
Hi,
On Friday 28 June 2013 10:53 AM, Jingoo Han wrote:
Add PHY provider node for the DP PHY.
Signed-off-by: Jingoo Han jg1@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 41cd625..d1d6e14 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -614,6 +614,12 @@
interrupts = 0 94 0;
};
+ dp_phy: video-phy@10040720 {
+ compatible = samsung,exynos5250-dp-video-phy;
+ reg = 0x10040720 4;
+ #phy-cells = 1;
phy-cells can be '0' here since this phy_provider implements only one PHY.
Oh, thank you.
I will fix it.
Best regards,
Jingoo Han
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: mmotm 2013-06-27-16-36 uploaded (v4l2 without I2C)
On 06/27/13 16:37, a...@linux-foundation.org wrote: The mm-of-the-moment snapshot 2013-06-27-16-36 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ on x86_64: CONFIG_I2C is not enabled. drivers/built-in.o: In function `match_i2c': v4l2-async.c:(.text+0x12f4c8): undefined reference to `i2c_verify_client' Full randconfig file is attached. -- ~Randy # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 3.10.0-rc7-mm1 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT=elf64-x86-64 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_CPU_AUTOPROBE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11 CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set CONFIG_KERNEL_LZO=y # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) # CONFIG_SWAP is not set # CONFIG_SYSVIPC is not set CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_FHANDLE=y # CONFIG_AUDIT is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_IRQ_DOMAIN=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_STALL_COMMON is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y # CONFIG_CGROUP_CPUACCT is not set CONFIG_RESOURCE_COUNTERS=y # CONFIG_MEMCG is not set # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_BLK_CGROUP=y CONFIG_DEBUG_BLK_CGROUP=y # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set CONFIG_IPC_NS=y CONFIG_PID_NS=y # CONFIG_NET_NS is not set CONFIG_SCHED_AUTOGROUP=y # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y # CONFIG_EXPERT is not set # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y CONFIG_VM_EVENT_COUNTERS=y #
