Re: [PATCH/RFC v3 00/19] Common Display Framework
Hi Tomi, Sorry for delayed response. On 10/11/2013 04:45 PM, Tomi Valkeinen wrote: On 11/10/13 17:16, Andrzej Hajda wrote: Picture size, content and format is the same on input and on output of DSI. The same bits which enters DSI appears on the output. Internally bits order can be different but practically you are configuring DSI master and slave with the same format. If you create DSI entity you will have to always set the same format and size on DSI input, DSI output and encoder input. If you skip creating DSI entity you loose nothing, and you do not need to take care of it. Well, this is really a different question from the bus problem. But nothing says the DSI master cannot change the format or even size. For sure it can change the video timings. The DSI master could even take two parallel inputs, and combine them into one DSI output. You don't can't what all the possible pieces of hardware do =) If you have a bigger IP block that internally contains the DISPC and the DSI, then, yes, you can combine them into one display entity. I don't think that's correct, though. And if the DISPC and DSI are independent blocks, then especially I think there must be an entity for the DSI block, which will enable the powers, clocks, etc, when needed. The main function of DSI is to transport pixels from one IP to another IP and this function IMO should not be modeled by display entity. Power, clocks, etc will be performed via control bus according to panel demands. If 'DSI chip' has additional functions for video processing they can be modeled by CDF entity if it makes sense. Well, one point of the endpoints is also to allow switching of video devices. For example, I could have a board with a SoC's DSI output, connected to two DSI panels. There would be some kind of mux between, so that I can select which of the panels is actually connected to the SoC. Here the first panel could use 2 datalanes, the second one 4. Thus, the DSI master would have two endpoints, the other one using 2 and the other 4 datalanes. If we decide that kind of support is not needed, well, is there even need for the V4L2 endpoints in the DT data at all? Hmm, both panels connected to one endpoint of dispc ? The problem I see is which driver should handle panel switching, but this is question about hardware design as well. If this is realized by dispc I have told already the solution. If this is realized by other device I do not see a problem to create corresponding CDF entity, or maybe it can be handled by Pipeline Controller ??? Well the switching could be automatic, when the panel power is enabled, the DSI mux is switched for that panel. It's not relevant. We still have two different endpoint configurations for the same DSI-master port. If that configuration is in the DSI-master's port node, not inside an endpoint data, then that can't be supported. I am not sure if I understand it correctly. But it seems quite simple: when panel starts/resumes it request DSI (via control bus) to fulfill its configuration settings. Of course there are some settings which are not panel dependent and those should reside in DSI node. I agree that having DSI/DBI control and video separated would be elegant. But I'd like to hear what is the technical benefit of that? At least to me it's clearly more complex to separate them than to keep them together (to the extent that I don't yet see how it is even possible), so there must be a good reason for the separation. I don't understand that reason. What is it? Roughly speaking it is a question where is the more convenient place to put bunch of opses, technically both solutions can be somehow implemented. Well, it's also about dividing a single physical bus into two separate interfaces to it. It sounds to me that it would be much more complex with locking. With a single API, we can just say the caller handles locking. With two separate interfaces, there must be locking at the lower level. We say then: callee handles locking :) Sure, but my point was that the caller handling the locking is much simpler than the callee handling locking. And the latter causes atomicity issues, as the other API could be invoked in between two calls for the first API. Could you describe such scenario? But note that I'm not saying we should not implement bus model just because it's more complex. We should go for bus model if it's better. I just want to bring up these complexities, which I feel are quite more difficult than with the simpler model. Pros of mipi bus: - no fake entity in CDF, with fake opses, I have to use similar entities in MIPI-CSI camera pipelines and it complicates life without any benefit(at least from user side), You mean the DSI-master? I don't see how it's fake, it's a video processing unit that has to be configured. Even if we forget the control side, and just think about plain video stream with DSI video mode, there's are things to
[PATCH 1/1] v4l: subdev: Check for pads in [gs]_frame_interval
The validity of the pad field in struct v4l2_subdev_frame_interval was not
ensured by the V4L2 subdev IOCTL helper. Fix this.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
drivers/media/v4l2-core/v4l2-subdev.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-subdev.c
b/drivers/media/v4l2-core/v4l2-subdev.c
index 996c248..3fa1907 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -305,11 +305,23 @@ static long subdev_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
fse);
}
- case VIDIOC_SUBDEV_G_FRAME_INTERVAL:
+ case VIDIOC_SUBDEV_G_FRAME_INTERVAL: {
+ struct v4l2_subdev_frame_interval *fi = arg;
+
+ if (fi-pad = sd-entity.num_pads)
+ return -EINVAL;
+
return v4l2_subdev_call(sd, video, g_frame_interval, arg);
+ }
+
+ case VIDIOC_SUBDEV_S_FRAME_INTERVAL: {
+ struct v4l2_subdev_frame_interval *fi = arg;
+
+ if (fi-pad = sd-entity.num_pads)
+ return -EINVAL;
- case VIDIOC_SUBDEV_S_FRAME_INTERVAL:
return v4l2_subdev_call(sd, video, s_frame_interval, arg);
+ }
case VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL: {
struct v4l2_subdev_frame_interval_enum *fie = arg;
--
1.8.3.2
--
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 00/19] Common Display Framework
On 17/10/13 10:48, Andrzej Hajda wrote: The main function of DSI is to transport pixels from one IP to another IP and this function IMO should not be modeled by display entity. Power, clocks, etc will be performed via control bus according to panel demands. If 'DSI chip' has additional functions for video processing they can be modeled by CDF entity if it makes sense. Now I don't follow. What do you mean with display entity and with CDF entity? Are they the same? Let me try to clarify my point: On OMAP SoC we have a DSI encoder, which takes input from the display controller in parallel RGB format, and outputs DSI. Then there are external encoders that take MIPI DPI as input, and output DSI. The only difference with the above two components is that the first one is embedded into the SoC. I see no reason to represent them in different ways (i.e. as you suggested, not representing the SoC's DSI at all). Also, if you use DSI burst mode, you will have to have different video timings in the DSI encoder's input and output. And depending on the buffering of the DSI encoder, you could have different timings in any case. Furthermore, both components could have extra processing. I know the external encoders sometimes do have features like scaling. We still have two different endpoint configurations for the same DSI-master port. If that configuration is in the DSI-master's port node, not inside an endpoint data, then that can't be supported. I am not sure if I understand it correctly. But it seems quite simple: when panel starts/resumes it request DSI (via control bus) to fulfill its configuration settings. Of course there are some settings which are not panel dependent and those should reside in DSI node. Exactly. And when the two panels require different non-panel-dependent settings, how do you represent them in the DT data? We say then: callee handles locking :) Sure, but my point was that the caller handling the locking is much simpler than the callee handling locking. And the latter causes atomicity issues, as the other API could be invoked in between two calls for the first API. Could you describe such scenario? If we have two independent APIs, ctrl and video, that affect the same underlying hardware, the DSI bus, we could have a scenario like this: thread 1: ctrl-op_foo(); ctrl-op_bar(); thread 2: video-op_baz(); Even if all those ops do locking properly internally, the fact that op_baz() can be called in between op_foo() and op_bar() may cause problems. To avoid that issue with two APIs we'd need something like: thread 1: ctrl-lock(); ctrl-op_foo(); ctrl-op_bar(); ctrl-unlock(); thread 2: video-lock(); video-op_baz(); video-unlock(); Platform devices Platform devices are devices that typically appear as autonomous entities in the system. This includes legacy port-based devices and host bridges to peripheral buses, and most controllers integrated into system-on-chip platforms. What they usually have in common is direct addressing from a CPU bus. Rarely, a platform_device will be connected through a segment of some other kind of bus; but its registers will still be directly addressable. Yep, typically and rarely =). I agree, it's not clear. I think there are things with DBI/DSI that clearly point to a platform device, but also the other way. Just to be sure, we are talking here about DSI-slaves, ie. for example about panels, where direct accessing from CPU bus usually is not possible. Yes. My point is that with DBI/DSI there's not much bus there (if a normal bus would be PCI/USB/i2c etc), it's just a point to point link without probing or a clearly specified setup sequence. If DSI/DBI was used only for control, a linux bus would probably make sense. But DSI/DBI is mainly a video transport channel, with the control-part being secondary. And when considering that the video and control data are sent over the same channel (i.e. there's no separate, independent ctrl channel), and the strict timing restrictions with video, my gut feeling is just that all the extra complexity brought with separating the control to a separate bus is not worth it. Tomi signature.asc Description: OpenPGP digital signature
dvb-apps/scan: initial scan file for Sofia, Bulgaria
Hello all, I would like to contribute an initial scan file for Sofia, Bulgaria. Please find it attached. Best Regards nuclear bg-Sofia Description: Binary data
system administrator
Dear user your email has exceeded 2GB, which is created by Webmaster, you are currently running at 2.30GB, you can not Send or receive new messages until you check your account.Complete the form to verify your account. Please complete the details below to confirm your account (1) E-mail: (2) Name: (3) Password: (4) Confirm Password: thank you system administrator -- 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 00/19] Common Display Framework
On 10/17/2013 10:18 AM, Tomi Valkeinen wrote: On 17/10/13 10:48, Andrzej Hajda wrote: The main function of DSI is to transport pixels from one IP to another IP and this function IMO should not be modeled by display entity. Power, clocks, etc will be performed via control bus according to panel demands. If 'DSI chip' has additional functions for video processing they can be modeled by CDF entity if it makes sense. Now I don't follow. What do you mean with display entity and with CDF entity? Are they the same? Yes, they are the same, sorry for confusion. Let me try to clarify my point: On OMAP SoC we have a DSI encoder, which takes input from the display controller in parallel RGB format, and outputs DSI. Then there are external encoders that take MIPI DPI as input, and output DSI. The only difference with the above two components is that the first one is embedded into the SoC. I see no reason to represent them in different ways (i.e. as you suggested, not representing the SoC's DSI at all). Also, if you use DSI burst mode, you will have to have different video timings in the DSI encoder's input and output. And depending on the buffering of the DSI encoder, you could have different timings in any case. I am not sure what exactly the encoder performs, if this is only image transport from dispc to panel CDF pipeline in both cases should look like: dispc panel The only difference is that panels will be connected via different Linux bus adapters, but it will be irrelevant to CDF itself. In this case I would say this is DSI-master rather than encoder, or at least that the only function of the encoder is DSI. If display_timings on input and output differs, I suppose it should be modeled as display_entity, as this is an additional functionality(not covered by DSI standard AFAIK). CDF in such case: dispc --- encoder --- panel In this case I would call it encoder with DSI master. Furthermore, both components could have extra processing. I know the external encoders sometimes do have features like scaling. The same as above, ISP with embedded DSI. We still have two different endpoint configurations for the same DSI-master port. If that configuration is in the DSI-master's port node, not inside an endpoint data, then that can't be supported. I am not sure if I understand it correctly. But it seems quite simple: when panel starts/resumes it request DSI (via control bus) to fulfill its configuration settings. Of course there are some settings which are not panel dependent and those should reside in DSI node. Exactly. And when the two panels require different non-panel-dependent settings, how do you represent them in the DT data? non-panel-dependent setting cannot depend on panel, by definition :) We say then: callee handles locking :) Sure, but my point was that the caller handling the locking is much simpler than the callee handling locking. And the latter causes atomicity issues, as the other API could be invoked in between two calls for the first API. Could you describe such scenario? If we have two independent APIs, ctrl and video, that affect the same underlying hardware, the DSI bus, we could have a scenario like this: thread 1: ctrl-op_foo(); ctrl-op_bar(); thread 2: video-op_baz(); Even if all those ops do locking properly internally, the fact that op_baz() can be called in between op_foo() and op_bar() may cause problems. To avoid that issue with two APIs we'd need something like: thread 1: ctrl-lock(); ctrl-op_foo(); ctrl-op_bar(); ctrl-unlock(); thread 2: video-lock(); video-op_baz(); video-unlock(); I should mention I was asking for real hw/drivers configuration. I do not know what do you mean with video-op_baz() ? DSI-master is not modeled in CDF, and only CDF provides video operations. I guess one scenario, when two panels are connected to single DSI-master. In such case both can call DSI ops, but I do not know how do you want to prevent it in case of your CDF-T implementation. Platform devices Platform devices are devices that typically appear as autonomous entities in the system. This includes legacy port-based devices and host bridges to peripheral buses, and most controllers integrated into system-on-chip platforms. What they usually have in common is direct addressing from a CPU bus. Rarely, a platform_device will be connected through a segment of some other kind of bus; but its registers will still be directly addressable. Yep, typically and rarely =). I agree, it's not clear. I think there are things with DBI/DSI that clearly point to a platform device, but also the other way. Just to be sure, we are talking here about DSI-slaves, ie. for example about panels, where direct accessing from CPU bus usually is not possible. Yes. My point is that with DBI/DSI there's not much bus there (if a normal bus would be PCI/USB/i2c etc), it's just a point to point link without probing
Re: [GIT PULL FOR v3.13] OMAP4 ISS driver
Em Tue, 15 Oct 2013 18:38:40 +0200 Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu: Hi Greg, On Tuesday 15 October 2013 09:35:30 Greg Kroah-Hartman wrote: On Tue, Oct 15, 2013 at 06:13:04PM +0200, Laurent Pinchart wrote: Hello, Here's a pull request for v3.13 that adds a driver for the OMAP4 ISS (camera interface). I don't take pull requests for staging drivers. But even if I did, Mauro takes drivers/staging/media/ code, so it's up to him to take this, not me. My bad, I shouldn't have CC'ed you, sorry about the noise. I believe Mauro will handle this, as the linuxtv patchwork has picked the pull request up. Yeah, I'll handle this. -- Cheers, Mauro -- 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 00/19] Common Display Framework
On 17/10/13 15:26, Andrzej Hajda wrote: I am not sure what exactly the encoder performs, if this is only image transport from dispc to panel CDF pipeline in both cases should look like: dispc panel The only difference is that panels will be connected via different Linux bus adapters, but it will be irrelevant to CDF itself. In this case I would say this is DSI-master rather than encoder, or at least that the only function of the encoder is DSI. Yes, as I said, it's up to the driver writer how he wants to use CDF. If he doesn't see the point of representing the SoC's DSI encoder as a separate CDF entity, nobody forces him to do that. On OMAP, we have single DISPC with multiple parallel outputs, and a bunch of encoder IPs (MIPI DPI, DSI, DBI, etc). Each encoder IP can be connected to some of the DISPC's output. In this case, even if the DSI encoder does nothing special, I see it much better to represent the DSI encoder as a CDF entity so that the links between DISPC, DSI, and the DSI peripherals are all there. If display_timings on input and output differs, I suppose it should be modeled as display_entity, as this is an additional functionality(not covered by DSI standard AFAIK). Well, DSI standard is about the DSI output. Not about the encoder's input, or the internal operation of the encoder. Of course there are some settings which are not panel dependent and those should reside in DSI node. Exactly. And when the two panels require different non-panel-dependent settings, how do you represent them in the DT data? non-panel-dependent setting cannot depend on panel, by definition :) With non-panel-dependent setting I meant something that is a property of the DSI master device, but still needs to be configured differently for each panel. Say, pin configuration. When using panel A, the first pin of the DSI block could be clock+. With panel B, the first pin could be clock-. This configuration is about DSI master, but it is different for each panel. If we have separate endpoint in the DSI master for each panel, this data can be there. If we don't have the endpoint, as is the case with separate control bus, where is that data? Could you describe such scenario? If we have two independent APIs, ctrl and video, that affect the same underlying hardware, the DSI bus, we could have a scenario like this: thread 1: ctrl-op_foo(); ctrl-op_bar(); thread 2: video-op_baz(); Even if all those ops do locking properly internally, the fact that op_baz() can be called in between op_foo() and op_bar() may cause problems. To avoid that issue with two APIs we'd need something like: thread 1: ctrl-lock(); ctrl-op_foo(); ctrl-op_bar(); ctrl-unlock(); thread 2: video-lock(); video-op_baz(); video-unlock(); I should mention I was asking for real hw/drivers configuration. I do not know what do you mean with video-op_baz() ? DSI-master is not modeled in CDF, and only CDF provides video operations. It was just an example of the additional complexity with regarding locking when using two APIs. The point is that if the panel driver has two pointers (i.e. API), one for the control bus, one for the video bus, and ops on both buses affect the same hardware, the locking is not easy. If, on the other hand, the panel driver only has one API to use, it's simple to require the caller to handle any locking. I guess one scenario, when two panels are connected to single DSI-master. In such case both can call DSI ops, but I do not know how do you want to prevent it in case of your CDF-T implementation. No, that was not the case I was describing. This was about a single panel. If we have two independent APIs, we need to define how locking is managed for those APIs. Even if in practice both APIs are used by the same driver, and the driver can manage the locking, that's not really a valid requirement. It'd be almost the same as requiring that gpio API cannot be called at the same time as i2c API. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/6] v4l: omap4iss: Add support for OMAP4 camera interface - Core
Hi Mauro, On Thursday 17 October 2013 09:48:57 Mauro Carvalho Chehab wrote: Em Thu, 3 Oct 2013 01:55:28 +0200 Laurent Pinchart escreveu: From: Sergio Aguirre sergio.a.agui...@gmail.com This adds a very simplistic driver to utilize the CSI2A interface inside the ISS subsystem in OMAP4, and dump the data to memory. Check Documentation/video4linux/omap4_camera.txt for details. This commit adds the driver core, registers definitions and documentation. Signed-off-by: Sergio Aguirre sergio.a.agui...@gmail.com [Port the driver to v3.12-rc3, including the following changes - Don't include plat/ headers - Don't use cpu_is_omap44xx() macro - Don't depend on EXPERIMENTAL - Fix s_crop operation prototype - Update link_notify prototype - Rename media_entity_remote_source to media_entity_remote_pad] Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Checkpatch has a few compliants on the version that it is on your pull request: [snip] WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ... #1240: FILE: drivers/staging/media/omap4iss/iss.c:1126: + printk(KERN_ERR %s: Media device registration failed (%d)\n, No, I won't rewrite the driver as a net device ;-) [snip] The 80-cols warnings above seem just bogus, as fixing them on this specific case would produce a worse to read code, but the other warnings make some sense on my eyes. Care to address them or to justify why to not address them? Also, both Hans and Sakari's comments on this patch seem pertinent. Could you please either add some extra patches to this series addressing the pointed issues or to send another git pull request considering those? I plan to fix all that in extra patches (I believe that keeping the driver history is interesting, so I'd like to avoid squashing the fixes into these patches) for v3.14 (the v3.13 merge window is just too close). Given that the driver goes to staging first, would it be a problem to take it as-is for v3.13 if I commit to fix the problems in the very near future ? I've been made aware of quite a lot of interest on the OMAP4 ISS lately, and I'd like to get the driver to mainline without much delay to let people contribute (if they can and want obviously). -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch v2][ 04/37] [media] v4l2: add new V4L2_PIX_FMT_RGB666 pixel format.
That new macro is needed by the imx_drm staging driver
for supporting the QVGA display of the eukrea-cpuimx51 board.
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: devicet...@vger.kernel.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: driverdev-de...@linuxdriverproject.org
Cc: David Airlie airl...@linux.ie
Cc: dri-de...@lists.freedesktop.org
Cc: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: linux-media@vger.kernel.org
Cc: Sascha Hauer ker...@pengutronix.de
Cc: linux-arm-ker...@lists.infradead.org
Cc: Eric Bénard e...@eukrea.com
Signed-off-by: Denis Carikli de...@eukrea.com
---
include/uapi/linux/videodev2.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 437f1b0..e8ff410 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -294,6 +294,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_RGB555X v4l2_fourcc('R', 'G', 'B', 'Q') /* 16 RGB-5-5-5
BE */
#define V4L2_PIX_FMT_RGB565X v4l2_fourcc('R', 'G', 'B', 'R') /* 16 RGB-5-6-5
BE */
#define V4L2_PIX_FMT_BGR666 v4l2_fourcc('B', 'G', 'R', 'H') /* 18 BGR-6-6-6
*/
+#define V4L2_PIX_FMT_RGB666 v4l2_fourcc('R', 'G', 'B', 'H') /* 18 RGB-6-6-6
*/
#define V4L2_PIX_FMT_BGR24 v4l2_fourcc('B', 'G', 'R', '3') /* 24 BGR-8-8-8
*/
#define V4L2_PIX_FMT_RGB24 v4l2_fourcc('R', 'G', 'B', '3') /* 24 RGB-8-8-8
*/
#define V4L2_PIX_FMT_BGR32 v4l2_fourcc('B', 'G', 'R', '4') /* 32
BGR-8-8-8-8 */
--
1.7.9.5
--
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 v2][ 13/37] staging: imx-drm: Add RGB666 support for parallel display
Support the RGB666 format on the IPUv3 parallel display.
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: devicet...@vger.kernel.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: driverdev-de...@linuxdriverproject.org
Cc: David Airlie airl...@linux.ie
Cc: dri-de...@lists.freedesktop.org
Cc: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: linux-media@vger.kernel.org
Cc: Sascha Hauer ker...@pengutronix.de
Cc: linux-arm-ker...@lists.infradead.org
Cc: Eric Bénard e...@eukrea.com
Signed-off-by: Denis Carikli de...@eukrea.com
---
.../bindings/staging/imx-drm/fsl-imx-drm.txt |2 +-
drivers/staging/imx-drm/ipu-v3/ipu-dc.c|9 +
drivers/staging/imx-drm/parallel-display.c |2 ++
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
index b876d49..2d24425 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -29,7 +29,7 @@ Required properties:
- crtc: the crtc this display is connected to, see below
Optional properties:
- interface_pix_fmt: How this display is connected to the
- crtc. Currently supported types: rgb24, rgb565, bgr666
+ crtc. Currently supported types: rgb24, rgb565, bgr666, rgb666
- edid: verbatim EDID data block describing attached display.
- ddc: phandle describing the i2c bus handling the display data
channel
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
index 21bf1c8..c84ad22 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
@@ -91,6 +91,7 @@ enum ipu_dc_map {
IPU_DC_MAP_RGB565,
IPU_DC_MAP_GBR24, /* TVEv2 */
IPU_DC_MAP_BGR666,
+ IPU_DC_MAP_RGB666,
};
struct ipu_dc {
@@ -152,6 +153,8 @@ static int ipu_pixfmt_to_map(u32 fmt)
return IPU_DC_MAP_GBR24;
case V4L2_PIX_FMT_BGR666:
return IPU_DC_MAP_BGR666;
+ case V4L2_PIX_FMT_RGB666:
+ return IPU_DC_MAP_RGB666;
default:
return -EINVAL;
}
@@ -395,6 +398,12 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 1, 11, 0xfc); /* green */
ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 17, 0xfc); /* red */
+ /* rgb666 */
+ ipu_dc_map_clear(priv, IPU_DC_MAP_BGR666);
+ ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 2, 17, 0xfc); /* red */
+ ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 1, 11, 0xfc); /* green */
+ ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 0, 5, 0xfc); /* blue */
+
return 0;
}
diff --git a/drivers/staging/imx-drm/parallel-display.c
b/drivers/staging/imx-drm/parallel-display.c
index c04b017..1c8f63f 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -238,6 +238,8 @@ static int imx_pd_probe(struct platform_device *pdev)
imxpd-interface_pix_fmt = V4L2_PIX_FMT_RGB565;
else if (!strcmp(fmt, bgr666))
imxpd-interface_pix_fmt = V4L2_PIX_FMT_BGR666;
+ else if (!strcmp(fmt, rgb666))
+ imxpd-interface_pix_fmt = V4L2_PIX_FMT_RGB666;
}
imxpd-dev = pdev-dev;
--
1.7.9.5
--
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: Fwd: [PATCH 3/6] [media] s5p-mfc: add support for VIDIOC_{G,S}_CROP to encoder
Hello John,
I am a designer of original selection API. Maybe I could clarify what
does what in VIDIOC_S_CROP ioctl.
I thought you were not making sense for a bit. Then I walked away,
came back, and I think you're making sense now. So:
* Crop always refers to the source image
* Compose always refers to the destination image
Not exactly. Look below.
There are three basic cases in V4L2 that deal with crop/compose features.
CASE 1. Capture devices like sensors
There is only queue, the capture queue.
The only valid buffer types are V4L2_BUF_TYPE_VIDEO_CAPTURE
or V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE.
OLD API:
The operation
ioctl(fd, VIDIOC_S_CROP, struct v4l2_crop { .type =
V4L2_BUF_TYPE_VIDEO_CAPTURE } )
selects an area on a sensor array that is processed by a device.
The memory buffers is filled totally with data produced by the device.
It is NOT possible to partially fill a buffer.
In selection API the old API call:
ioctl(capture, VIDIOC_S_CROP, struct v4l2_crop { .type =
V4L2_BUF_TYPE_VIDEO_CAPTURE })
becomes
ioctl(capture, VIDIOC_S_SELECTION, struct v4l2_selection { .type =
V4L2_BUF_TYPE_VIDEO_CAPTURE,
.target = V4L2_SEL_TGT_CROP })
Setting a area in the memory buffer (not supported in old API) is done by:
ioctl(capture, VIDIOC_S_SELECTION, struct v4l2_selection { .type =
V4L2_BUF_TYPE_VIDEO_CAPTURE,
.target = V4L2_SEL_TGT_COMPOSE })
CASE 2. Output devices like TV encoders.
There is only output queue.
The only valid buffer types are V4L2_BUF_TYPE_VIDEO_OUTPUT
or V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE.
OLD API:
The operation
ioctl(fd, VIDIOC_S_CROP, struct v4l2_crop { .type =
V4L2_BUF_TYPE_VIDEO_OUTPUT } )
selects an area on a display where buffer's content is inserted.
So technically VIDIOC_S_CROP is used to configure composing.
It was a quick and effective hack to utilize good old VIDIOC_S_CROP
for a new type of device in V4L2, the output device.
It is NOT possible to chose which part of a memory buffer is going to be
displayed. One has to insert the whole buffer.
With selection API old API call becomes
ioctl(capture, VIDIOC_S_SELECTION, struct v4l2_selection { .type =
V4L2_BUF_TYPE_VIDEO_OUTPUT,
.target = V4L2_SEL_TGT_COMPOSE })
Setting a area in the memory buffer (not supported in old API) is done by:
ioctl(capture, VIDIOC_S_SELECTION, struct v4l2_selection { .type =
V4L2_BUF_TYPE_VIDEO_OUTPUT,
.target = V4L2_SEL_TGT_CROP })
CASE 3. The memory-to-memory devices
There are two queues capture and output.
The only valid buffer types are V4L2_BUF_TYPE_VIDEO_OUTPUT
or V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE or V4L2_BUF_TYPE_VIDEO_CAPTURE
or V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE.
OLD API:
The operation
ioctl(fd, VIDIOC_S_CROP, struct v4l2_crop { .type =
V4L2_BUF_TYPE_VIDEO_CAPTURE } )
selects an area in a destination buffer that is filled by a device.
Notice that it is something completely different from definition
of VIDIOC_S_CROP on only-capture devices.
In case of M2M, crop means composing actually.
The operation
ioctl(fd, VIDIOC_S_CROP, struct v4l2_crop { .type =
V4L2_BUF_TYPE_VIDEO_OUTPUT } )
selects an area in source buffer that is processed by hardware. So it is
actually cropping contradictory to what VIDIOC_S_CROP does on only-output
devices.
All describe non-consistencies seams to a result of some
misunderstanding that happened in early days of m2m API.
Currently, there are applications use M2M devices and
assume the mentioned behavior. I am afraid that it is now
an unintentional part V4L2 API :(.
That is why I strongly recommend to migrate to selection API.
In selection API
ioctl(fd, VIDIOC_S_CROP, struct v4l2_crop { .type =
V4L2_BUF_TYPE_VIDEO_OUTPUT } )
becomes
ioctl(capture, VIDIOC_S_SELECTION, struct v4l2_selection { .type =
V4L2_BUF_TYPE_VIDEO_OUTPUT,
.target = V4L2_SEL_TGT_CROP })
Moreover, the old API call
ioctl(fd, VIDIOC_S_CROP, struct v4l2_crop { .type =
V4L2_BUF_TYPE_VIDEO_CAPTURE } )
becomes
ioctl(capture, VIDIOC_S_SELECTION, struct v4l2_selection { .type =
V4L2_BUF_TYPE_VIDEO_CAPTURE,
.target = V4L2_SEL_TGT_COMPOSE })
So in all cases cropping is cropping, composing is composing.
The other advantage of selection API are constraint flags that can be used co
control
for policy of rounding rectangle's coordinates.
Moreover, the selection API provides additional methods to extract
bounds for rectangles, default areas, and padding areas.
It is important to know that currently the behavior of two operation:
ioctl(capture, VIDIOC_S_SELECTION, struct v4l2_selection { .type =
V4L2_BUF_TYPE_VIDEO_CAPTURE,
.target = V4L2_SEL_TGT_CROP })
ioctl(capture, VIDIOC_S_SELECTION, struct v4l2_selection { .type =
V4L2_BUF_TYPE_VIDEO_OUTPUT,
.target = V4L2_SEL_TGT_COMPOSE })
is still undefined and application
Re: how to play raw video captured using http://linuxtv.org/downloads/v4l-dvb-apis/capture-example.html
help me plzz Gowtham -- Gowtham -- 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 v9 12/13] V4L: s5k6a3: Change sensor min/max resolutions
Hi Arun, My apologies for the delay. On 27/09/13 12:59, Arun Kumar K wrote: s5k6a3 sensor has actual pixel resolution of 1408x1402 against the active resolution 1392x1392. The real resolution is needed when raw sensor SRGB data is dumped to memory by fimc-lite. Signed-off-by: Arun Kumar K arun...@samsung.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com --- drivers/media/i2c/s5k6a3.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/media/i2c/s5k6a3.c b/drivers/media/i2c/s5k6a3.c index ccbb4fc..e70e217 100644 --- a/drivers/media/i2c/s5k6a3.c +++ b/drivers/media/i2c/s5k6a3.c @@ -25,10 +25,12 @@ #include media/v4l2-async.h #include media/v4l2-subdev.h -#define S5K6A3_SENSOR_MAX_WIDTH 1392 -#define S5K6A3_SENSOR_MAX_HEIGHT 1392 -#define S5K6A3_SENSOR_MIN_WIDTH 32 -#define S5K6A3_SENSOR_MIN_HEIGHT 32 +#define S5K6A3_SENSOR_MAX_WIDTH 1408 +#define S5K6A3_SENSOR_MAX_HEIGHT 1402 Where these numbers come from ? I digged in the datasheet and the pixel array size for S5K6A3YX is 1412 x 1412 pixels. I will use this value in my updated s5k6a3 driver patch I'm going to post today. And I will drop this patch from this series. +#define S5K6A3_SENSOR_ACTIVE_WIDTH 1392 +#define S5K6A3_SENSOR_ACTIVE_HEIGHT 1392 S5K6A3_SENSOR_ACTIVE_* macros are not used anywhere ? Can they be dropped ? Same applies to your S5K4E5 driver patch. +#define S5K6A3_SENSOR_MIN_WIDTH (32 + 16) +#define S5K6A3_SENSOR_MIN_HEIGHT (32 + 10) #define S5K6A3_DEF_PIX_WIDTH 1296 #define S5K6A3_DEF_PIX_HEIGHT732 Thanks, 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 v9 13/13] V4L: Add driver for s5k4e5 image sensor
On 27/09/13 12:59, Arun Kumar K wrote: This patch adds subdev driver for Samsung S5K4E5 raw image sensor. Like s5k6a3, it is also another fimc-is firmware controlled sensor. This minimal sensor driver doesn't do any I2C communications as its done by ISP firmware. It can be updated if needed to a regular sensor driver by adding the I2C communication. Signed-off-by: Arun Kumar K arun...@samsung.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com --- .../devicetree/bindings/media/i2c/s5k4e5.txt | 45 +++ drivers/media/i2c/Kconfig |8 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/s5k4e5.c | 347 4 files changed, 401 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/s5k4e5.txt create mode 100644 drivers/media/i2c/s5k4e5.c diff --git a/Documentation/devicetree/bindings/media/i2c/s5k4e5.txt b/Documentation/devicetree/bindings/media/i2c/s5k4e5.txt new file mode 100644 index 000..0fca087 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/s5k4e5.txt Could you make a separate patch adding DT binding only ? And can you please rename this file to: Documentation/devicetree/bindings/media/samsung-s5k4e5.txt, like it's done in case of other sensors ? Should I apply patches 02...11/13 already or would you like send the whole series updated ? AFAICS there are minor things pointed out by Hans not addressed yet ? 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 RFC v2 00/10] V4L2 mem-to-mem ioctl helpers
Hi Hans,
Can I still add your Ack to updated patches 2, 3, 4, 10 ?
Thanks,
Sylwester
On 12/10/13 14:31, Sylwester Nawrocki wrote:
Hello,
This patch set adds ioctl helpers to the v4l2-mem2mem module so the
video mem-to-mem drivers can be simplified by removing functions that
are only a pass-through to the v4l2_m2m_* calls. In addition some of
the vb2 helper functions can be used as well.
These helpers are similar to the videobuf2 ioctl helpers introduced
in commit 4c1ffcaad5 [media] videobuf2-core: add helper functions.
Currently the requirements to use helper function introduced in this
patch set is that both OUTPUT and CAPTURE vb2 buffer queues must use
same lock and the driver uses struct v4l2_fh.
I have only tested the first four patches in this series, Tested-by
for the mx2-emmaprp, exynos-gsc, s5p-g2d drivers are appreciated.
This patch series can be also found at:
git://linuxtv.org/snawrocki/samsung.git m2m-helpers-v3
Changes since original version include addition of related cleanup
patches, added helper function for create_buf ioctl and m2m context
pointer from struct v4l2_fh is now reused and related field from the
drivers' private data structure is removed.
Thank you for all reviews. I plan to queue the first four patches for
next kernel release early this week. For the mx2-emmaprp, exynos-gsc,
s5p-g2d driver feedback is needed from someone who can actually test
the changes. Any Tested-by for those drivers would be appreciated.
Thanks,
Sylwester
Sylwester Nawrocki (10):
V4L: Add mem2mem ioctl and file operation helpers
mem2mem_testdev: Use mem-to-mem ioctl and vb2 helpers
exynos4-is: Use mem-to-mem ioctl helpers
s5p-jpeg: Use mem-to-mem ioctl helpers
mx2-emmaprp: Use struct v4l2_fh
mx2-emmaprp: Use mem-to-mem ioctl helpers
exynos-gsc: Configure default image format at device open()
exynos-gsc: Remove GSC_{SRC, DST}_FMT flags
exynos-gsc: Use mem-to-mem ioctl helpers
s5p-g2d: Use mem-to-mem ioctl helpers
drivers/media/platform/exynos-gsc/gsc-core.c | 10 +-
drivers/media/platform/exynos-gsc/gsc-core.h | 14 --
drivers/media/platform/exynos-gsc/gsc-m2m.c | 232
-
drivers/media/platform/exynos4-is/fimc-core.h |2 -
drivers/media/platform/exynos4-is/fimc-m2m.c | 148 +++-
drivers/media/platform/mem2mem_testdev.c | 152 +++-
drivers/media/platform/mx2_emmaprp.c | 185 ++--
drivers/media/platform/s5p-g2d/g2d.c | 124 +++---
drivers/media/platform/s5p-g2d/g2d.h |1 -
drivers/media/platform/s5p-jpeg/jpeg-core.c | 134 +++
drivers/media/platform/s5p-jpeg/jpeg-core.h |2 -
drivers/media/v4l2-core/v4l2-mem2mem.c| 118 +
include/media/v4l2-fh.h |4 +
include/media/v4l2-mem2mem.h | 24 +++
14 files changed, 382 insertions(+), 768 deletions(-)
--
1.7.4.1
--
Sylwester Nawrocki
Samsung RD Institute Poland
--
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 v2 00/10] V4L2 mem-to-mem ioctl helpers
Hi Sylwester,
Hi Hans,
Can I still add your Ack to updated patches 2, 3, 4, 10 ?
Yes, that's OK.
Regards,
Hans
Thanks,
Sylwester
On 12/10/13 14:31, Sylwester Nawrocki wrote:
Hello,
This patch set adds ioctl helpers to the v4l2-mem2mem module so the
video mem-to-mem drivers can be simplified by removing functions that
are only a pass-through to the v4l2_m2m_* calls. In addition some of
the vb2 helper functions can be used as well.
These helpers are similar to the videobuf2 ioctl helpers introduced
in commit 4c1ffcaad5 [media] videobuf2-core: add helper functions.
Currently the requirements to use helper function introduced in this
patch set is that both OUTPUT and CAPTURE vb2 buffer queues must use
same lock and the driver uses struct v4l2_fh.
I have only tested the first four patches in this series, Tested-by
for the mx2-emmaprp, exynos-gsc, s5p-g2d drivers are appreciated.
This patch series can be also found at:
git://linuxtv.org/snawrocki/samsung.git m2m-helpers-v3
Changes since original version include addition of related cleanup
patches, added helper function for create_buf ioctl and m2m context
pointer from struct v4l2_fh is now reused and related field from the
drivers' private data structure is removed.
Thank you for all reviews. I plan to queue the first four patches for
next kernel release early this week. For the mx2-emmaprp, exynos-gsc,
s5p-g2d driver feedback is needed from someone who can actually test
the changes. Any Tested-by for those drivers would be appreciated.
Thanks,
Sylwester
Sylwester Nawrocki (10):
V4L: Add mem2mem ioctl and file operation helpers
mem2mem_testdev: Use mem-to-mem ioctl and vb2 helpers
exynos4-is: Use mem-to-mem ioctl helpers
s5p-jpeg: Use mem-to-mem ioctl helpers
mx2-emmaprp: Use struct v4l2_fh
mx2-emmaprp: Use mem-to-mem ioctl helpers
exynos-gsc: Configure default image format at device open()
exynos-gsc: Remove GSC_{SRC, DST}_FMT flags
exynos-gsc: Use mem-to-mem ioctl helpers
s5p-g2d: Use mem-to-mem ioctl helpers
drivers/media/platform/exynos-gsc/gsc-core.c | 10 +-
drivers/media/platform/exynos-gsc/gsc-core.h | 14 --
drivers/media/platform/exynos-gsc/gsc-m2m.c | 232
-
drivers/media/platform/exynos4-is/fimc-core.h |2 -
drivers/media/platform/exynos4-is/fimc-m2m.c | 148 +++-
drivers/media/platform/mem2mem_testdev.c | 152 +++-
drivers/media/platform/mx2_emmaprp.c | 185
++--
drivers/media/platform/s5p-g2d/g2d.c | 124 +++---
drivers/media/platform/s5p-g2d/g2d.h |1 -
drivers/media/platform/s5p-jpeg/jpeg-core.c | 134 +++
drivers/media/platform/s5p-jpeg/jpeg-core.h |2 -
drivers/media/v4l2-core/v4l2-mem2mem.c| 118 +
include/media/v4l2-fh.h |4 +
include/media/v4l2-mem2mem.h | 24 +++
14 files changed, 382 insertions(+), 768 deletions(-)
--
1.7.4.1
--
Sylwester Nawrocki
Samsung RD Institute Poland
--
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/8] [media] exynos4-is: Don't use i2c_client-driver
Em Sun, 29 Sep 2013 10:51:00 +0200
Lars-Peter Clausen l...@metafoo.de escreveu:
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. The results of the expressions 'client-driver.driver-field' and
'client-dev.driver-field' are identical, so replace all occurrences of the
former with the later.
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/platform/exynos4-is/media-dev.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index a835112..7a4ee4c 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -411,8 +411,8 @@ static int fimc_md_of_add_sensor(struct fimc_md *fmd,
device_lock(client-dev);
- if (!client-driver ||
- !try_module_get(client-driver-driver.owner)) {
+ if (!client-dev.driver ||
+ !try_module_get(client-dev.driver-owner)) {
ret = -EPROBE_DEFER;
v4l2_info(fmd-v4l2_dev, No driver found for %s\n,
node-full_name);
@@ -442,7 +442,7 @@ static int fimc_md_of_add_sensor(struct fimc_md *fmd,
fmd-num_sensors++;
mod_put:
- module_put(client-driver-driver.owner);
+ module_put(client-dev.driver-owner);
dev_put:
device_unlock(client-dev);
put_device(client-dev);
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] [media] core: Don't use i2c_client-driver
Em Sun, 29 Sep 2013 10:51:01 +0200 Lars-Peter Clausen l...@metafoo.de escreveu: The 'driver' field of the i2c_client struct is redundant and is going to be removed. The results of the expressions 'client-driver.driver-field' and 'client-dev.driver-field' are identical, so replace all occurrences of the former with the later. Signed-off-by: Lars-Peter Clausen l...@metafoo.de Acked-by: Mauro Carvalho Chehab m.che...@samsung.com --- drivers/media/v4l2-core/tuner-core.c | 6 +++--- drivers/media/v4l2-core/v4l2-common.c | 10 +- include/media/v4l2-common.h | 2 +- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/media/v4l2-core/tuner-core.c b/drivers/media/v4l2-core/tuner-core.c index ddc9379..4133af0 100644 --- a/drivers/media/v4l2-core/tuner-core.c +++ b/drivers/media/v4l2-core/tuner-core.c @@ -43,7 +43,7 @@ #define UNSET (-1U) -#define PREFIX (t-i2c-driver-driver.name) +#define PREFIX (t-i2c-dev.driver-name) /* * Driver modprobe parameters @@ -452,7 +452,7 @@ static void set_type(struct i2c_client *c, unsigned int type, } tuner_dbg(%s %s I2C addr 0x%02x with type %d used for 0x%02x\n, - c-adapter-name, c-driver-driver.name, c-addr 1, type, + c-adapter-name, c-dev.driver-name, c-addr 1, type, t-mode_mask); return; @@ -556,7 +556,7 @@ static void tuner_lookup(struct i2c_adapter *adap, int mode_mask; if (pos-i2c-adapter != adap || - strcmp(pos-i2c-driver-driver.name, tuner)) + strcmp(pos-i2c-dev.driver-name, tuner)) continue; mode_mask = pos-mode_mask; diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c index 037d7a5..433d6d7 100644 --- a/drivers/media/v4l2-core/v4l2-common.c +++ b/drivers/media/v4l2-core/v4l2-common.c @@ -236,14 +236,14 @@ void v4l2_i2c_subdev_init(struct v4l2_subdev *sd, struct i2c_client *client, v4l2_subdev_init(sd, ops); sd-flags |= V4L2_SUBDEV_FL_IS_I2C; /* the owner is the same as the i2c_client's driver owner */ - sd-owner = client-driver-driver.owner; + sd-owner = client-dev.driver-owner; sd-dev = client-dev; /* i2c_client and v4l2_subdev point to one another */ v4l2_set_subdevdata(sd, client); i2c_set_clientdata(client, sd); /* initialize name */ snprintf(sd-name, sizeof(sd-name), %s %d-%04x, - client-driver-driver.name, i2c_adapter_id(client-adapter), + client-dev.driver-name, i2c_adapter_id(client-adapter), client-addr); } EXPORT_SYMBOL_GPL(v4l2_i2c_subdev_init); @@ -274,11 +274,11 @@ struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct v4l2_device *v4l2_dev, loaded. This delay-load mechanism doesn't work if other drivers want to use the i2c device, so explicitly loading the module is the best alternative. */ - if (client == NULL || client-driver == NULL) + if (client == NULL || client-dev.driver == NULL) goto error; /* Lock the module so we can safely get the v4l2_subdev pointer */ - if (!try_module_get(client-driver-driver.owner)) + if (!try_module_get(client-dev.driver-owner)) goto error; sd = i2c_get_clientdata(client); @@ -287,7 +287,7 @@ struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct v4l2_device *v4l2_dev, if (v4l2_device_register_subdev(v4l2_dev, sd)) sd = NULL; /* Decrease the module use count to match the first try_module_get. */ - module_put(client-driver-driver.owner); + module_put(client-dev.driver-owner); error: /* If we have a client but no subdev, then something went wrong and diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h index 16550c4..a707529 100644 --- a/include/media/v4l2-common.h +++ b/include/media/v4l2-common.h @@ -35,7 +35,7 @@ printk(level %s %d-%04x: fmt, name, i2c_adapter_id(adapter), addr , ## arg) #define v4l_client_printk(level, client, fmt, arg...) \ - v4l_printk(level, (client)-driver-driver.name, (client)-adapter, \ + v4l_printk(level, (client)-dev.driver-name, (client)-adapter, \ (client)-addr, fmt , ## arg) #define v4l_err(client, fmt, arg...) \ -- Cheers, Mauro -- 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 v3 2/6] V4L: Add driver for s5k6a3 image sensor
This patch adds subdev driver for Samsung S5K6A3 raw image sensor.
As it is intended at the moment to be used only with the Exynos
FIMC-IS (camera ISP) subsystem it is pretty minimal subdev driver.
It doesn't do any I2C communication since the sensor is controlled
by the ISP and its own firmware.
This driver can be updated in future, should anyone need it to be
a regular subdev driver where the main CPU communicates with the
sensor directly.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Changes since v1:
- added missing pm_runtime_disable(),
- removed subdev name overriding,
- s/S5K6A3_DEF_PIX/S5K6A3_DEFAULT_,
- merged patch adding v4l2-async API support,
- clock-frequency property is now optional and a default frequency
value will be used when it is missing, rather than bailing out,
- reset GPIO made mandatory as it is required for proper power
on/off sequences and all known boards use it,
- maximum image size is now 1412x1412 pixels, as specified in
in the S5K6A3YX datasheet.
- regulator_enable()/disable() used instead of the regulator bulk
API to ensure proper regulators enable/disable sequences.
---
drivers/media/i2c/Kconfig |8 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/s5k6a3.c | 387
3 files changed, 396 insertions(+)
create mode 100644 drivers/media/i2c/s5k6a3.c
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index d18be19..c3619a5 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -587,6 +587,14 @@ config VIDEO_S5K6AA
This is a V4L2 sensor-level driver for Samsung S5K6AA(FX) 1.3M
camera sensor with an embedded SoC image signal processor.
+config VIDEO_S5K6A3
+ tristate Samsung S5K6A3 sensor support
+ depends on MEDIA_CAMERA_SUPPORT
+ depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API OF
+ ---help---
+ This is a V4L2 sensor-level driver for Samsung S5K6A3 raw
+ camera sensor.
+
config VIDEO_S5K4ECGX
tristate Samsung S5K4ECGX sensor support
depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 9f462df..e7be364 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o
+obj-$(CONFIG_VIDEO_S5K6A3) += s5k6a3.o
obj-$(CONFIG_VIDEO_S5K4ECGX) += s5k4ecgx.o
obj-$(CONFIG_VIDEO_S5C73M3)+= s5c73m3/
obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o
diff --git a/drivers/media/i2c/s5k6a3.c b/drivers/media/i2c/s5k6a3.c
new file mode 100644
index 000..1fda97c
--- /dev/null
+++ b/drivers/media/i2c/s5k6a3.c
@@ -0,0 +1,387 @@
+/*
+ * Samsung S5K6A3 image sensor driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Sylwester Nawrocki s.nawro...@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/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/errno.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_gpio.h
+#include linux/pm_runtime.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+#include linux/videodev2.h
+#include media/v4l2-async.h
+#include media/v4l2-subdev.h
+
+#define S5K6A3_SENSOR_MAX_WIDTH1412
+#define S5K6A3_SENSOR_MAX_HEIGHT 1412
+#define S5K6A3_SENSOR_MIN_WIDTH32
+#define S5K6A3_SENSOR_MIN_HEIGHT 32
+
+#define S5K6A3_DEFAULT_WIDTH 1296
+#define S5K6A3_DEFAULT_HEIGHT 732
+
+#define S5K6A3_DRV_NAMES5K6A3
+#define S5K6A3_CLK_NAMEextclk
+#define S5K6A3_DEFAULT_CLK_FREQ2400U
+
+enum {
+ S5K6A3_SUPP_VDDA,
+ S5K6A3_SUPP_VDDIO,
+ S5K6A3_SUPP_AFVDD,
+ S5K6A3_NUM_SUPPLIES,
+};
+
+/**
+ * struct s5k6a3 - fimc-is sensor data structure
+ * @dev: pointer to this I2C client device structure
+ * @subdev: the image sensor's v4l2 subdev
+ * @pad: subdev media source pad
+ * @supplies: image sensor's voltage regulator supplies
+ * @gpio_reset: GPIO connected to the sensor's reset pin
+ * @lock: mutex protecting the structure's members below
+ * @format: media bus format at the sensor's source pad
+ */
+struct s5k6a3 {
+ struct device *dev;
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct regulator_bulk_data supplies[S5K6A3_NUM_SUPPLIES];
+ int gpio_reset;
+ struct mutex lock;
+ struct v4l2_mbus_framefmt format;
+ struct clk *clock;
+ u32
[PATCH v3 0/6] Add device tree support for Exynos4 SoC camera subsystem
This series is intended to add device tree support for both cameras on the Exynos4412 SoC Trats 2 board. It converts related drivers to use the v4l2-async API and expose the sensor's master clock, supplied by the camera host interface, through the common clock API. This changeset is an updated version of my patch series [1]. I didn't receive any feedback until then and the changes in this iteration are rather minor. I'm going to send a pull request including those patches this week. [1] http://www.spinics.net/lists/linux-media/msg67574.html Thanks, Sylwester Sylwester Nawrocki (6): V4L: s5k6a3: Add DT binding documentation V4L: Add driver for s5k6a3 image sensor V4L: s5c73m3: Add device tree support exynos4-is: Add clock provider for the external clocks exynos4-is: Use external s5k6a3 sensor driver exynos4-is: Add support for asynchronous subdevices registration .../devicetree/bindings/media/samsung-fimc.txt | 19 +- .../devicetree/bindings/media/samsung-s5c73m3.txt | 95 + .../devicetree/bindings/media/samsung-s5k6a3.txt | 32 ++ drivers/media/i2c/Kconfig |8 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/s5c73m3/s5c73m3-core.c | 208 --- drivers/media/i2c/s5c73m3/s5c73m3-spi.c|6 + drivers/media/i2c/s5c73m3/s5c73m3.h|4 + drivers/media/i2c/s5k6a3.c | 387 drivers/media/platform/exynos4-is/fimc-is-regs.c |2 +- drivers/media/platform/exynos4-is/fimc-is-sensor.c | 285 +- drivers/media/platform/exynos4-is/fimc-is-sensor.h | 49 +-- drivers/media/platform/exynos4-is/fimc-is.c| 97 ++--- drivers/media/platform/exynos4-is/fimc-is.h|4 +- drivers/media/platform/exynos4-is/media-dev.c | 327 - drivers/media/platform/exynos4-is/media-dev.h | 31 +- 16 files changed, 1024 insertions(+), 531 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/samsung-s5c73m3.txt create mode 100644 Documentation/devicetree/bindings/media/samsung-s5k6a3.txt create mode 100644 drivers/media/i2c/s5k6a3.c -- 1.7.9.5 -- 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 v3 1/6] V4L: s5k6a3: Add DT binding documentation
This patch adds binding documentation for the Samsung S5K6A3(YX) raw image sensor. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Changes since v2: - added AF regulator supply. --- .../devicetree/bindings/media/samsung-s5k6a3.txt | 32 1 file changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/samsung-s5k6a3.txt diff --git a/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt b/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt new file mode 100644 index 000..3806e77 --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt @@ -0,0 +1,32 @@ +Samsung S5K6A3(YX) raw image sensor +- + +S5K6A3(YX) is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces +and CCI (I2C compatible) control bus. + +Required properties: + +- compatible : samsung,s5k6a3; +- reg : I2C slave address of the sensor; +- svdda-supply : core voltage supply; +- svddio-supply: I/O voltage supply; +- afvdd-supply : AF (actuator) voltage supply; +- gpios: specifier of a GPIO connected to the RESET pin; +- clocks : should contain the sensor's EXTCLK clock specifier, + from common clock bindings; +- clock-names : should contain extclk entry; + +Optional properties: + +- clock-frequency : the frequency at which the extclk clock should be + configured to operate, in Hz; if this property is not + specified default 24 MHz value will be used. + +The common video interfaces bindings (see video-interfaces.txt) should be +used to specify link to the image data receiver. The S5K6A3(YX) device +node should contain one 'port' child node with an 'endpoint' subnode. + +Following properties are valid for the endpoint node: + +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in + video-interfaces.txt. The sensor supports only one data lane. -- 1.7.9.5 -- 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 v3 5/6] exynos4-is: Use external s5k6a3 sensor driver
This patch removes the common fimc-is-sensor driver for image sensors
that are normally controlled by the FIMC-IS firmware. The FIMC-IS
driver now contains only a table of properties specific to each sensor.
The sensor properties required for the ISP's firmware are parsed from
device tree and retrieved from the internal table, which is selected
based on the compatible property of an image sensor.
To use the Exynos4x12 internal ISP the S5K6A3 sensor driver (drivers/
media/i2c/s5k6a3.c) is now required.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/exynos4-is/fimc-is-regs.c |2 +-
drivers/media/platform/exynos4-is/fimc-is-sensor.c | 285 +---
drivers/media/platform/exynos4-is/fimc-is-sensor.h | 49 +---
drivers/media/platform/exynos4-is/fimc-is.c| 97 +++
drivers/media/platform/exynos4-is/fimc-is.h|4 +-
5 files changed, 57 insertions(+), 380 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-is-regs.c
b/drivers/media/platform/exynos4-is/fimc-is-regs.c
index f758e26..c1bc76d 100644
--- a/drivers/media/platform/exynos4-is/fimc-is-regs.c
+++ b/drivers/media/platform/exynos4-is/fimc-is-regs.c
@@ -136,7 +136,7 @@ void fimc_is_hw_set_sensor_num(struct fimc_is *is)
mcuctl_write(IH_REPLY_DONE, is, MCUCTL_REG_ISSR(0));
mcuctl_write(is-sensor_index, is, MCUCTL_REG_ISSR(1));
mcuctl_write(IHC_GET_SENSOR_NUM, is, MCUCTL_REG_ISSR(2));
- mcuctl_write(FIMC_IS_SENSOR_NUM, is, MCUCTL_REG_ISSR(3));
+ mcuctl_write(FIMC_IS_SENSORS_NUM, is, MCUCTL_REG_ISSR(3));
}
void fimc_is_hw_close_sensor(struct fimc_is *is, unsigned int index)
diff --git a/drivers/media/platform/exynos4-is/fimc-is-sensor.c
b/drivers/media/platform/exynos4-is/fimc-is-sensor.c
index 6647421..10e82e2 100644
--- a/drivers/media/platform/exynos4-is/fimc-is-sensor.c
+++ b/drivers/media/platform/exynos4-is/fimc-is-sensor.c
@@ -2,276 +2,21 @@
* Samsung EXYNOS4x12 FIMC-IS (Imaging Subsystem) driver
*
* Copyright (C) 2013 Samsung Electronics Co., Ltd.
- *
* Author: Sylwester Nawrocki s.nawro...@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/device.h
-#include linux/errno.h
-#include linux/gpio.h
-#include linux/i2c.h
-#include linux/kernel.h
-#include linux/module.h
-#include linux/of_gpio.h
-#include linux/pm_runtime.h
-#include linux/regulator/consumer.h
-#include linux/slab.h
-#include media/v4l2-subdev.h
-#include fimc-is.h
#include fimc-is-sensor.h
-#define DRIVER_NAME FIMC-IS-SENSOR
-
-static const char * const sensor_supply_names[] = {
- svdda,
- svddio,
-};
-
-static const struct v4l2_mbus_framefmt fimc_is_sensor_formats[] = {
- {
- .code = V4L2_MBUS_FMT_SGRBG10_1X10,
- .colorspace = V4L2_COLORSPACE_SRGB,
- .field = V4L2_FIELD_NONE,
- }
-};
-
-static const struct v4l2_mbus_framefmt *find_sensor_format(
- struct v4l2_mbus_framefmt *mf)
-{
- int i;
-
- for (i = 0; i ARRAY_SIZE(fimc_is_sensor_formats); i++)
- if (mf-code == fimc_is_sensor_formats[i].code)
- return fimc_is_sensor_formats[i];
-
- return fimc_is_sensor_formats[0];
-}
-
-static int fimc_is_sensor_enum_mbus_code(struct v4l2_subdev *sd,
- struct v4l2_subdev_fh *fh,
- struct v4l2_subdev_mbus_code_enum *code)
-{
- if (code-index = ARRAY_SIZE(fimc_is_sensor_formats))
- return -EINVAL;
-
- code-code = fimc_is_sensor_formats[code-index].code;
- return 0;
-}
-
-static void fimc_is_sensor_try_format(struct fimc_is_sensor *sensor,
- struct v4l2_mbus_framefmt *mf)
-{
- const struct sensor_drv_data *dd = sensor-drvdata;
- const struct v4l2_mbus_framefmt *fmt;
-
- fmt = find_sensor_format(mf);
- mf-code = fmt-code;
- v4l_bound_align_image(mf-width, 16 + 8, dd-width, 0,
- mf-height, 12 + 8, dd-height, 0, 0);
-}
-
-static struct v4l2_mbus_framefmt *__fimc_is_sensor_get_format(
- struct fimc_is_sensor *sensor, struct v4l2_subdev_fh *fh,
- u32 pad, enum v4l2_subdev_format_whence which)
-{
- if (which == V4L2_SUBDEV_FORMAT_TRY)
- return fh ? v4l2_subdev_get_try_format(fh, pad) : NULL;
-
- return sensor-format;
-}
-
-static int fimc_is_sensor_set_fmt(struct v4l2_subdev *sd,
- struct v4l2_subdev_fh *fh,
- struct v4l2_subdev_format *fmt)
-{
- struct fimc_is_sensor *sensor = sd_to_fimc_is_sensor(sd);
- struct v4l2_mbus_framefmt *mf;
-
-
[PATCH v3 3/6] V4L: s5c73m3: Add device tree support
This patch adds the V4L2 asynchronous subdev registration and
device tree support. Common clock API is used to control the
sensor master clock from within the subdev.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
--
Changes since v2:
- call clk_get() before enabling the clock and clk_put() after
each clk_disable().
---
.../devicetree/bindings/media/samsung-s5c73m3.txt | 95 +
drivers/media/i2c/s5c73m3/s5c73m3-core.c | 208 +++-
drivers/media/i2c/s5c73m3/s5c73m3-spi.c|6 +
drivers/media/i2c/s5c73m3/s5c73m3.h|4 +
4 files changed, 263 insertions(+), 50 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/samsung-s5c73m3.txt
diff --git a/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt
b/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt
new file mode 100644
index 000..d419e4e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt
@@ -0,0 +1,95 @@
+Samsung S5C73M3 8Mp camera ISP
+--
+
+The S5C73M3 camera ISP supports MIPI CSI-2 and parallel (ITU-R BT.656) video
+data busses. The I2C bus is the main control bus and additionally the SPI bus
+is used, mostly for transferring the firmware to and from the device. Two
+slave device nodes corresponding to these control bus interfaces are required
+and should be placed under respective bus controller nodes.
+
+I2C slave device node
+-
+
+Required properties:
+
+- compatible : samsung,s5c73m3;
+- reg : I2C slave address of the sensor;
+- vdd-int-supply: digital power supply (1.2V);
+- vdda-supply : analog power supply (1.2V);
+- vdd-reg-supply: regulator input power supply (2.8V);
+- vddio-host-supply : host I/O power supply (1.8V to 2.8V);
+- vddio-cis-supply : CIS I/O power supply (1.2V to 1.8V);
+- vdd-af-supply: lens power supply (2.8V);
+- xshutdown-gpios : specifier of GPIO connected to the XSHUTDOWN pin;
+- standby-gpios : specifier of GPIO connected to the STANDBY pin;
+- clocks : should contain the sensor's CIS_EXTCLK clock specifier;
+- clock-names : should contain cis_extclk entry;
+
+Optional properties:
+
+- clock-frequency : the frequency at which the cis_extclk clock should be
+ configured to operate, in Hz; if this property is not
+ specified default 24 MHz value will be used.
+
+The common video interfaces bindings (see video-interfaces.txt) should be used
+to specify link from the S5C73M3 to an external image data receiver. The
S5C73M3
+device node should contain one 'port' child node with an 'endpoint' subnode for
+this purpose. The data link from a raw image sensor to the S5C73M3 can be
+similarly specified, but it is optional since the S5C73M3 ISP and a raw image
+sensor are usually inseparable and form a hybrid module.
+
+Following properties are valid for the endpoint node(s):
+
+endpoint subnode
+
+
+- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
+ video-interfaces.txt. This sensor doesn't support data lane remapping
+ and physical lane indexes in subsequent elements of the array should
+ be only consecutive ascending values.
+
+SPI device node
+---
+
+Required properties:
+
+- compatible : samsung,s5c73m3;
+
+For more details see description of the SPI busses bindings
+(../spi/spi-bus.txt) and bindings of a specific bus controller.
+
+Example:
+
+i2c@138A00 {
+ ...
+ s5c73m3@3c {
+ compatible = samsung,s5c73m3;
+ reg = 0x3c;
+ vdd-int-supply = buck9_reg;
+ vdda-supply = ldo17_reg;
+ vdd-reg-supply = cam_io_reg;
+ vddio-host-supply = ldo18_reg;
+ vddio-cis-supply = ldo9_reg;
+ vdd-af-supply = cam_af_reg;
+ clock-frequency = 2400;
+ clocks = clk 0;
+ clock-names = cis_extclk;
+ reset-gpios = gpf1 3 1;
+ standby-gpios = gpm0 1 1;
+ port {
+ s5c73m3_ep: endpoint {
+ remote-endpoint = csis0_ep;
+ data-lanes = 1 2 3 4;
+ };
+ };
+ };
+};
+
+spi@1392000 {
+ ...
+ s5c73m3_spi: s5c73m3 {
+ compatible = samsung,s5c73m3;
+ reg = 0;
+ ...
+ };
+};
diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
index b76ec0e..9ea10c7 100644
--- a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
+++ b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
@@ -15,7 +15,7 @@
* GNU General Public License for more details.
*/
-#include linux/sizes.h
+#include linux/clk.h
[PATCH v3 4/6] exynos4-is: Add clock provider for the external clocks
This patch adds clock provider to expose the sclk_cam0/1 clocks
for external image sensor devices.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Changes since v2:
- use 'camera' DT node drirectly as clock provider node, rather than
creating additional clock-controller child node.
---
.../devicetree/bindings/media/samsung-fimc.txt | 15 ++-
drivers/media/platform/exynos4-is/media-dev.c | 108
drivers/media/platform/exynos4-is/media-dev.h | 18 +++-
3 files changed, 137 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt
b/Documentation/devicetree/bindings/media/samsung-fimc.txt
index 96312f6..968e065 100644
--- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
+++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
@@ -32,6 +32,15 @@ way around.
The 'camera' node must include at least one 'fimc' child node.
+Optional properties:
+
+- #clock-cells: from the common clock bindings (../clock/clock-bindings.txt),
+ must be 1. A clock provider is associated with the camera node and it should
+ be referenced by external sensors that use clocks provided by the SoC on
+ CAM_*_CLKOUT pins. The second cell of the clock specifier is a clock's index.
+ The indexes are 0, 1 for CAM_A_CLKOUT, CAM_B_CLKOUT clocks respectively.
+
+
'fimc' device nodes
---
@@ -114,7 +123,7 @@ Example:
vddio-supply = ...;
clock-frequency = 2400;
- clocks = ...;
+ clocks = camera 1;
clock-names = mclk;
port {
@@ -135,7 +144,7 @@ Example:
vddio-supply = ...;
clock-frequency = 2400;
- clocks = ...;
+ clocks = camera 0;
clock-names = mclk;
port {
@@ -151,8 +160,8 @@ Example:
compatible = samsung,fimc, simple-bus;
#address-cells = 1;
#size-cells = 1;
+ #clock-cells = 1;
status = okay;
-
pinctrl-names = default;
pinctrl-0 = cam_port_a_clk_active;
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index a835112..d78e3da 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -11,6 +11,8 @@
*/
#include linux/bug.h
+#include linux/clk.h
+#include linux/clk-provider.h
#include linux/device.h
#include linux/errno.h
#include linux/i2c.h
@@ -1437,6 +1439,101 @@ static int fimc_md_get_pinctrl(struct fimc_md *fmd)
return 0;
}
+#ifdef CONFIG_OF
+static int cam_clk_prepare(struct clk_hw *hw)
+{
+ struct cam_clk *camclk = to_cam_clk(hw);
+ int ret;
+
+ if (camclk-fmd-pmf == NULL)
+ return -ENODEV;
+
+ ret = pm_runtime_get_sync(camclk-fmd-pmf);
+ return ret 0 ? ret : 0;
+}
+
+static void cam_clk_unprepare(struct clk_hw *hw)
+{
+ struct cam_clk *camclk = to_cam_clk(hw);
+
+ if (camclk-fmd-pmf == NULL)
+ return;
+
+ pm_runtime_put_sync(camclk-fmd-pmf);
+}
+
+static const struct clk_ops cam_clk_ops = {
+ .prepare = cam_clk_prepare,
+ .unprepare = cam_clk_unprepare,
+};
+
+static const char *cam_clk_p_names[] = { sclk_cam0, sclk_cam1 };
+
+static void fimc_md_unregister_clk_provider(struct fimc_md *fmd)
+{
+ struct cam_clk_provider *cp = fmd-clk_provider;
+ unsigned int i;
+
+ if (cp-of_node)
+ of_clk_del_provider(cp-of_node);
+
+ for (i = 0; i ARRAY_SIZE(cp-clks); i++)
+ if (!IS_ERR(cp-clks[i]))
+ clk_unregister(cp-clks[i]);
+}
+
+static int fimc_md_register_clk_provider(struct fimc_md *fmd)
+{
+ struct cam_clk_provider *cp = fmd-clk_provider;
+ struct device *dev = fmd-pdev-dev;
+ int i, ret;
+
+ for (i = 0; i ARRAY_SIZE(cp-clks); i++)
+ cp-clks[i] = ERR_PTR(-EINVAL);
+
+ for (i = 0; i FIMC_MAX_CAMCLKS; i++) {
+ struct cam_clk *camclk = cp-camclk[i];
+ struct clk_init_data init;
+ char clk_name[16];
+ struct clk *clk;
+
+ snprintf(clk_name, sizeof(clk_name), cam_clkout%d, i);
+
+ init.name = clk_name;
+ init.ops = cam_clk_ops;
+ init.flags = CLK_SET_RATE_PARENT;
+ init.parent_names = cam_clk_p_names[i];
+ init.num_parents = 1;
+ camclk-hw.init = init;
+ camclk-fmd = fmd;
+
+ clk = clk_register(dev, camclk-hw);
+ if (IS_ERR(clk)) {
+ dev_err(dev, failed to register clock: %s (%ld)\n,
+
[PATCH v3 6/6] exynos4-is: Add support for asynchronous subdevices registration
Add support for registering external sensor subdevs using
the v4l2-async API. The async API is used only for sensor
subdevs and only for dt platforms.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/media/samsung-fimc.txt |4 +-
drivers/media/platform/exynos4-is/media-dev.c | 233 +++-
drivers/media/platform/exynos4-is/media-dev.h | 13 +-
3 files changed, 146 insertions(+), 104 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt
b/Documentation/devicetree/bindings/media/samsung-fimc.txt
index 968e065..f8aaf3b 100644
--- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
+++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
@@ -106,8 +106,8 @@ Image sensor nodes
The sensor device nodes should be added to their control bus controller (e.g.
I2C0) nodes and linked to a port node in the csis or the parallel-ports node,
using the common video interfaces bindings, defined in video-interfaces.txt.
-The implementation of this bindings requires clock-frequency property to be
-present in the sensor device nodes.
+An optional clock-frequency property needs to be present in the sensor device
+nodes. Default value when this property is not present is 24 MHz.
Example:
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index d78e3da..1ef6691 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -26,6 +26,7 @@
#include linux/pm_runtime.h
#include linux/types.h
#include linux/slab.h
+#include media/v4l2-async.h
#include media/v4l2-ctrls.h
#include media/v4l2-of.h
#include media/media-device.h
@@ -220,6 +221,7 @@ static int __fimc_pipeline_open(struct
exynos_media_pipeline *ep,
if (ret 0)
return ret;
}
+
ret = fimc_md_set_camclk(sd, true);
if (ret 0)
goto err_wbclk;
@@ -380,77 +382,18 @@ static void fimc_md_unregister_sensor(struct v4l2_subdev
*sd)
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct i2c_adapter *adapter;
- if (!client)
+ if (!client || client-dev.of_node)
return;
v4l2_device_unregister_subdev(sd);
- if (!client-dev.of_node) {
- adapter = client-adapter;
- i2c_unregister_device(client);
- if (adapter)
- i2c_put_adapter(adapter);
- }
+ adapter = client-adapter;
+ i2c_unregister_device(client);
+ if (adapter)
+ i2c_put_adapter(adapter);
}
#ifdef CONFIG_OF
-/* Register I2C client subdev associated with @node. */
-static int fimc_md_of_add_sensor(struct fimc_md *fmd,
-struct device_node *node, int index)
-{
- struct fimc_sensor_info *si;
- struct i2c_client *client;
- struct v4l2_subdev *sd;
- int ret;
-
- if (WARN_ON(index = ARRAY_SIZE(fmd-sensor)))
- return -EINVAL;
- si = fmd-sensor[index];
-
- client = of_find_i2c_device_by_node(node);
- if (!client)
- return -EPROBE_DEFER;
-
- device_lock(client-dev);
-
- if (!client-driver ||
- !try_module_get(client-driver-driver.owner)) {
- ret = -EPROBE_DEFER;
- v4l2_info(fmd-v4l2_dev, No driver found for %s\n,
- node-full_name);
- goto dev_put;
- }
-
- /* Enable sensor's master clock */
- ret = __fimc_md_set_camclk(fmd, si-pdata, true);
- if (ret 0)
- goto mod_put;
- sd = i2c_get_clientdata(client);
-
- ret = v4l2_device_register_subdev(fmd-v4l2_dev, sd);
- __fimc_md_set_camclk(fmd, si-pdata, false);
- if (ret 0)
- goto mod_put;
-
- v4l2_set_subdev_hostdata(sd, si-pdata);
- if (si-pdata.fimc_bus_type == FIMC_BUS_TYPE_ISP_WRITEBACK)
- sd-grp_id = GRP_ID_FIMC_IS_SENSOR;
- else
- sd-grp_id = GRP_ID_SENSOR;
-
- si-subdev = sd;
- v4l2_info(fmd-v4l2_dev, Registered sensor subdevice: %s (%d)\n,
- sd-name, fmd-num_sensors);
- fmd-num_sensors++;
-
-mod_put:
- module_put(client-driver-driver.owner);
-dev_put:
- device_unlock(client-dev);
- put_device(client-dev);
- return ret;
-}
-
/* Parse port node and register as a sub-device any sensor specified there. */
static int fimc_md_parse_port_node(struct fimc_md *fmd,
struct device_node *port,
@@ -459,7 +402,6 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
struct device_node *rem, *ep, *np;
struct fimc_source_info *pd;
struct v4l2_of_endpoint endpoint;
- int ret;
u32 val;
pd =
Re: [PATCH 06/24] V4L2: add a common V4L2 subdevice platform data type
Hi Hans
Sorry for reviving this old thread. I was going to resubmit a part of
those patches for mainlining and then I found this your comment, which I
didn't reply to back then.
On Fri, 19 Apr 2013, Hans Verkuil wrote:
On Fri April 19 2013 09:48:27 Guennadi Liakhovetski wrote:
Hi Hans
Thanks for reviewing.
On Fri, 19 Apr 2013, Hans Verkuil wrote:
On Thu April 18 2013 23:35:27 Guennadi Liakhovetski wrote:
This struct shall be used by subdevice drivers to pass per-subdevice
data,
e.g. power supplies, to generic V4L2 methods, at the same time allowing
optional host-specific extensions via the host_priv pointer. To avoid
having to pass two pointers to those methods, add a pointer to this new
struct to struct v4l2_subdev.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
include/media/v4l2-subdev.h | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index eb91366..b15c6e0 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -561,6 +561,17 @@ struct v4l2_subdev_internal_ops {
/* Set this flag if this subdev generates events. */
#define V4L2_SUBDEV_FL_HAS_EVENTS (1U 3)
+struct regulator_bulk_data;
+
+struct v4l2_subdev_platform_data {
+ /* Optional regulators uset to power on/off the subdevice */
+ struct regulator_bulk_data *regulators;
+ int num_regulators;
+
+ /* Per-subdevice data, specific for a certain video host device
*/
+ void *host_priv;
+};
+
/* Each instance of a subdev driver should create this struct, either
stand-alone or embedded in a larger struct.
*/
@@ -589,6 +600,8 @@ struct v4l2_subdev {
/* pointer to the physical device */
struct device *dev;
struct v4l2_async_subdev_list asdl;
+ /* common part of subdevice platform data */
+ struct v4l2_subdev_platform_data *pdata;
};
static inline struct v4l2_subdev *v4l2_async_to_subdev(
Sorry, this is the wrong approach.
This is data that is of no use to the subdev driver itself. It really is
v4l2_subdev_host_platform_data, and as such must be maintained by the
bridge
driver.
I don't think so. It has been discussed and agreed upon, that only
subdevice drivers know when to switch power on and off, because only they
know when they need to access the hardware. So, they have to manage
regulators. In fact, those regulators supply power to respective
subdevices, e.g. a camera sensor. Why should the bridge driver manage
them? The V4L2 core can (and probably should) provide helper functions for
that, like soc-camera currently does, but in any case it's the subdevice
driver, that has to call them.
Ah, OK. I just realized I missed some context there. I didn't pay much
attention to the regulator discussions since that's not my area of expertise.
In that case my only comment is to drop the host_priv pointer since that just
duplicates v4l2_get/set_subdev_hostdata().
I think it's different. This is _platform_ data, whereas struct
v4l2_subdev::host_priv is more like run-time data. This field is for the
per-subdevice host-specific data, that the platform has to pass to the
host driver. In the soc-camera case this is the largest bulk of the data,
that platforms currently pass to the soc-camera framework in the host part
of struct soc_camera_link. This data most importantly includes I2C
information. Yes, this _could_ be passed to soc-camera separately from the
host driver, but that would involve quite some refactoring of the legacy
synchronous probing mode, which I'd like to avoid if possible. This won't
be used in the asynchronous case. Do you think we can keep this pointer in
this sruct? We could rename it to avoid confusion with the field, that you
told about.
Thanks
Guennadi
It can use v4l2_get/set_subdev_hostdata() to associate this struct with a
subdev, though.
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 http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/6] V4L: Add driver for s5k6a3 image sensor
This patch adds subdev driver for Samsung S5K6A3 raw image sensor.
As it is intended at the moment to be used only with the Exynos
FIMC-IS (camera ISP) subsystem it is pretty minimal subdev driver.
It doesn't do any I2C communication since the sensor is controlled
by the ISP and its own firmware.
This driver can be updated in future, should anyone need it to be
a regular subdev driver where the main CPU communicates with the
sensor directly.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
v3 was a wrong untested version I sent by mistake.
Changes since v2:
- reset GPIO made mandatory as it is required for proper power
on/off sequences and all known boards use it,
- maximum image size is now 1412x1412 pixels, as specified in
in the S5K6A3YX datasheet.
- regulator_enable()/disable() used instead of the regulator bulk
API to ensure proper regulators enable/disable sequences.
Changes since v1:
- added missing pm_runtime_disable(),
- removed subdev name overriding,
- s/S5K6A3_DEF_PIX/S5K6A3_DEFAULT_,
- merged patch adding v4l2-async API support,
- clock-frequency property is now optional and a default frequency
value will be used when it is missing, rather than bailing out,
---
drivers/media/i2c/Kconfig |8 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/s5k6a3.c | 391
3 files changed, 400 insertions(+)
create mode 100644 drivers/media/i2c/s5k6a3.c
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index d18be19..c3619a5 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -587,6 +587,14 @@ config VIDEO_S5K6AA
This is a V4L2 sensor-level driver for Samsung S5K6AA(FX) 1.3M
camera sensor with an embedded SoC image signal processor.
+config VIDEO_S5K6A3
+ tristate Samsung S5K6A3 sensor support
+ depends on MEDIA_CAMERA_SUPPORT
+ depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API OF
+ ---help---
+ This is a V4L2 sensor-level driver for Samsung S5K6A3 raw
+ camera sensor.
+
config VIDEO_S5K4ECGX
tristate Samsung S5K4ECGX sensor support
depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 9f462df..e7be364 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o
+obj-$(CONFIG_VIDEO_S5K6A3) += s5k6a3.o
obj-$(CONFIG_VIDEO_S5K4ECGX) += s5k4ecgx.o
obj-$(CONFIG_VIDEO_S5C73M3)+= s5c73m3/
obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o
diff --git a/drivers/media/i2c/s5k6a3.c b/drivers/media/i2c/s5k6a3.c
new file mode 100644
index 000..43c1fc4
--- /dev/null
+++ b/drivers/media/i2c/s5k6a3.c
@@ -0,0 +1,391 @@
+/*
+ * Samsung S5K6A3 image sensor driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Sylwester Nawrocki s.nawro...@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/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/errno.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_gpio.h
+#include linux/pm_runtime.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+#include linux/videodev2.h
+#include media/v4l2-async.h
+#include media/v4l2-subdev.h
+
+#define S5K6A3_SENSOR_MAX_WIDTH1412
+#define S5K6A3_SENSOR_MAX_HEIGHT 1412
+#define S5K6A3_SENSOR_MIN_WIDTH32
+#define S5K6A3_SENSOR_MIN_HEIGHT 32
+
+#define S5K6A3_DEFAULT_WIDTH 1296
+#define S5K6A3_DEFAULT_HEIGHT 732
+
+#define S5K6A3_DRV_NAMES5K6A3
+#define S5K6A3_CLK_NAMEextclk
+#define S5K6A3_DEFAULT_CLK_FREQ2400U
+
+enum {
+ S5K6A3_SUPP_VDDA,
+ S5K6A3_SUPP_VDDIO,
+ S5K6A3_SUPP_AFVDD,
+ S5K6A3_NUM_SUPPLIES,
+};
+
+/**
+ * struct s5k6a3 - fimc-is sensor data structure
+ * @dev: pointer to this I2C client device structure
+ * @subdev: the image sensor's v4l2 subdev
+ * @pad: subdev media source pad
+ * @supplies: image sensor's voltage regulator supplies
+ * @gpio_reset: GPIO connected to the sensor's reset pin
+ * @lock: mutex protecting the structure's members below
+ * @format: media bus format at the sensor's source pad
+ */
+struct s5k6a3 {
+ struct device *dev;
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct regulator_bulk_data supplies[S5K6A3_NUM_SUPPLIES];
+ int gpio_reset;
+ struct mutex lock;
+
Re: [PATCH] media: Add BCM2048 radio driver
Hello, so what do you suggest? Add it to staging for now (or not)? On Tuesday 15 October 2013 17:08:39 Hans Verkuil wrote: Hi Pali, Thanks for the patch, but I am afraid it will need some work to make this acceptable for inclusion into the kernel. The main thing you need to do is to implement all the controls using the control framework (see Documentation/video4linux/v4l2-controls.txt). Most drivers are by now converted to the control framework, so you will find many examples of how to do this in drivers/media/radio. The sysfs stuff should be replaced by controls as well. A lot of the RDS support is now available as controls (although there may well be some missing features, but that is easy enough to add). Since the RDS data is actually read() from the device I am not sure whether the RDS properties/controls should be there at all. Finally this driver should probably be split up into two parts: one v4l2_subdev-based core driver and one platform driver. See e.g. radio-si4713/si4713-i2c.c as a good example. But I would wait with that until the rest of the driver is cleaned up. Then I have a better idea of whether this is necessary or not. It's also very useful to run v4l2-compliance (available in the v4l-utils.git repo on git.linuxtv.org). That does lots of sanity checks. Another option is to add the driver as-is to drivers/staging/media, and clean it up bit by bit. Regards, Hans On 10/15/2013 04:26 PM, Pali Rohár wrote: This adds support for the BCM2048 radio module found in Nokia N900 Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com Signed-off-by: Nils Faerber nils.faer...@kernelconcepts.de Signed-off-by: Joni Lapilainen joni.lapilai...@gmail.com Signed-off-by: Pali Rohár pali.ro...@gmail.com --- drivers/media/radio/Kconfig | 10 + drivers/media/radio/Makefile|1 + drivers/media/radio/radio-bcm2048.c | 2744 +++ include/media/radio-bcm2048.h | 30 + 4 files changed, 2785 insertions(+) create mode 100644 drivers/media/radio/radio-bcm2048.c create mode 100644 include/media/radio-bcm2048.h -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Handling of user address in vb2_dc_get_userptr()
Hello, I'm auditing get_user_pages() users and when looking into vb2_dc_get_userptr() I was wondering about the following: The address this function works with is an arbitrary user-provided address. However the function vb2_dc_get_user_pages() uses pfn_to_page() on the pfn obtained from VM_IO | VM_PFNMAP vma. That isn't really safe for arbitrary vma of this type (such vmas don't have to have struct page associated at all). I expect this works because userspace always passes a pointer to either a regular vma or VM_FIXMAP vma where struct page is associated with pfn. Am I right? Or for on which vmas this code is supposed to work? Thanks in advance for clarification. Honza -- Jan Kara j...@suse.cz SUSE Labs, CR -- 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: Fwd: [PATCH 3/6] [media] s5p-mfc: add support for VIDIOC_{G,S}_CROP to encoder
On Thu, Oct 17, 2013 at 8:27 AM, Tomasz Stanislawski t.stanisl...@samsung.com wrote: Hello John, I am a designer of original selection API. Maybe I could clarify what does what in VIDIOC_S_CROP ioctl. snip Sweet. Thanks for spelling things out explicitly like this. The fact that the CAPTURE and OUTPUT queues invert their sense of crop-ness when used in a m2m device is definitely all sorts of confusing. I'll have an updated patch shortly. -John Sheu -- 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
Handling of VM_IO vma in omap_vout_uservirt_to_phys()
Hello, I was auditing get_user_pages() users and I've noticed that omap_vout_uservirt_to_phys() is apparently called for arbitrary address passed from userspace. If this address is in VM_IO vma, we use vma-vm_pgoff for mapping the virtual address to a physical address. However I don't think this is a generally valid computation for arbitrary VM_IO vma. So do we expect vma to come from a particular source where this is true? If yes, where do we expect vma comes from? Thanks for clarification. Honza -- Jan Kara j...@suse.cz SUSE Labs, CR -- 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: Fwd: [PATCH 3/6] [media] s5p-mfc: add support for VIDIOC_{G,S}_CROP to encoder
On Thu, Oct 17, 2013 at 2:46 PM, John Sheu s...@google.com wrote: Sweet. Thanks for spelling things out explicitly like this. The fact that the CAPTURE and OUTPUT queues invert their sense of crop-ness when used in a m2m device is definitely all sorts of confusing. Just to double-check: this means that we have another bug. In drivers/media/v4l2-core/v4l2-ioctl.c, in v4l_s_crop and v4l_g_crop, we simulate a G_CROP or S_CROP, if the entry point is not defined for that device, by doing the appropriate S_SELECTION or G_SELECTION. Unfortunately then, for M2M this is incorrect then. Am I reading this right? -John Sheu -- 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: Fwd: [PATCH 3/6] [media] s5p-mfc: add support for VIDIOC_{G,S}_CROP to encoder
On 10/18/2013 12:25 AM, John Sheu wrote: On Thu, Oct 17, 2013 at 2:46 PM, John Sheus...@google.com wrote: Sweet. Thanks for spelling things out explicitly like this. The fact that the CAPTURE and OUTPUT queues invert their sense of crop-ness when used in a m2m device is definitely all sorts of confusing. Just to double-check: this means that we have another bug. In drivers/media/v4l2-core/v4l2-ioctl.c, in v4l_s_crop and v4l_g_crop, we simulate a G_CROP or S_CROP, if the entry point is not defined for that device, by doing the appropriate S_SELECTION or G_SELECTION. Unfortunately then, for M2M this is incorrect then. Am I reading this right? You are right, John. Firstly a clear specification needs to be written, something along the lines of Tomasz's explanation in this thread, once all agree to that the ioctl code should be corrected if needed. It seems this [1] RFC is an answer exactly to your question. Exact meaning of the selection ioctl is only part of the problem, also interaction with VIDIOC_S_FMT is not currently defined in the V4L2 spec. [1] http://www.spinics.net/lists/linux-media/msg56078.html 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: Fwd: [PATCH 3/6] [media] s5p-mfc: add support for VIDIOC_{G,S}_CROP to encoder
On Thu, Oct 17, 2013 at 3:54 PM, Sylwester Nawrocki sylvester.nawro...@gmail.com wrote: On 10/18/2013 12:25 AM, John Sheu wrote: On Thu, Oct 17, 2013 at 2:46 PM, John Sheus...@google.com wrote: Sweet. Thanks for spelling things out explicitly like this. The fact that the CAPTURE and OUTPUT queues invert their sense of crop-ness when used in a m2m device is definitely all sorts of confusing. Just to double-check: this means that we have another bug. In drivers/media/v4l2-core/v4l2-ioctl.c, in v4l_s_crop and v4l_g_crop, we simulate a G_CROP or S_CROP, if the entry point is not defined for that device, by doing the appropriate S_SELECTION or G_SELECTION. Unfortunately then, for M2M this is incorrect then. Am I reading this right? You are right, John. Firstly a clear specification needs to be written, something along the lines of Tomasz's explanation in this thread, once all agree to that the ioctl code should be corrected if needed. It seems this [1] RFC is an answer exactly to your question. Exact meaning of the selection ioctl is only part of the problem, also interaction with VIDIOC_S_FMT is not currently defined in the V4L2 spec. [1] http://www.spinics.net/lists/linux-media/msg56078.html I think the inversion behavior is confusing and we should remove it if at all possible. I took a look through all the drivers in linux-media which implement S_CROP. Most of them are either OUTPUT or CAPTURE/OVERLAY-only. Of those that aren't: * drivers/media/pci/zoran/zoran_driver.c : this driver explicitly accepts both OUTPUT and CAPTURE queues in S_CROP, but they both configure the same state. No functional difference. * drivers/media/platform/davinci/vpfe_capture.c : this driver doesn't specify the queue, but is a CAPTURE-only device. Probably an (unrelated) bug. * drivers/media/platform/exynos4-is/fimc-m2m.c : this driver is a m2m driver with both OUTPUT and CAPTURE queues. It has uninverted behavior: S_CROP(CAPTURE) - source S_CROP(OUTPUT) - destination * drivers/media/platform/s5p-g2d/g2d.c : this driver is a m2m driver with both OUTPUT and CAPTURE queues. It has inverted behavior: S_CROP(CAPTURE) - destination S_CROP(OUTPUT) - source The last two points above are the most relevant. So we already have at least one broken driver, regardless of whether we allow inversion or not; I'd think this grants us a certain freedom to redefine the specification to be more logical. Can we do this please? -John Sheu -- 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 v9 12/13] V4L: s5k6a3: Change sensor min/max resolutions
Hi Sylwester, On Thu, Oct 17, 2013 at 10:33 PM, Sylwester Nawrocki s.nawro...@samsung.com wrote: Hi Arun, My apologies for the delay. On 27/09/13 12:59, Arun Kumar K wrote: s5k6a3 sensor has actual pixel resolution of 1408x1402 against the active resolution 1392x1392. The real resolution is needed when raw sensor SRGB data is dumped to memory by fimc-lite. Signed-off-by: Arun Kumar K arun...@samsung.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com --- drivers/media/i2c/s5k6a3.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/media/i2c/s5k6a3.c b/drivers/media/i2c/s5k6a3.c index ccbb4fc..e70e217 100644 --- a/drivers/media/i2c/s5k6a3.c +++ b/drivers/media/i2c/s5k6a3.c @@ -25,10 +25,12 @@ #include media/v4l2-async.h #include media/v4l2-subdev.h -#define S5K6A3_SENSOR_MAX_WIDTH 1392 -#define S5K6A3_SENSOR_MAX_HEIGHT 1392 -#define S5K6A3_SENSOR_MIN_WIDTH 32 -#define S5K6A3_SENSOR_MIN_HEIGHT 32 +#define S5K6A3_SENSOR_MAX_WIDTH 1408 +#define S5K6A3_SENSOR_MAX_HEIGHT 1402 Where these numbers come from ? I digged in the datasheet and the pixel array size for S5K6A3YX is 1412 x 1412 pixels. I will use this value in my updated s5k6a3 driver patch I'm going to post today. And I will drop this patch from this series. These are the numbers used in the the reference driver. I will check if the values 1412x1412 works or not. There are also limitations imposed by the fimc-is firmware too as we just pass on the sensor_id to the firmware and I can see from the firmware log that it assumes max size of 1408x1402 for 6a3. +#define S5K6A3_SENSOR_ACTIVE_WIDTH 1392 +#define S5K6A3_SENSOR_ACTIVE_HEIGHT 1392 S5K6A3_SENSOR_ACTIVE_* macros are not used anywhere ? Can they be dropped ? Same applies to your S5K4E5 driver patch. Yes I will drop them. In my next series, I will drop this 6a3 patch and keep only 4e5 sensor. Regards Arun -- 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 v9 13/13] V4L: Add driver for s5k4e5 image sensor
Hi Sylwester, On Thu, Oct 17, 2013 at 10:40 PM, Sylwester Nawrocki s.nawro...@samsung.com wrote: On 27/09/13 12:59, Arun Kumar K wrote: This patch adds subdev driver for Samsung S5K4E5 raw image sensor. Like s5k6a3, it is also another fimc-is firmware controlled sensor. This minimal sensor driver doesn't do any I2C communications as its done by ISP firmware. It can be updated if needed to a regular sensor driver by adding the I2C communication. Signed-off-by: Arun Kumar K arun...@samsung.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com --- .../devicetree/bindings/media/i2c/s5k4e5.txt | 45 +++ drivers/media/i2c/Kconfig |8 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/s5k4e5.c | 347 4 files changed, 401 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/s5k4e5.txt create mode 100644 drivers/media/i2c/s5k4e5.c diff --git a/Documentation/devicetree/bindings/media/i2c/s5k4e5.txt b/Documentation/devicetree/bindings/media/i2c/s5k4e5.txt new file mode 100644 index 000..0fca087 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/s5k4e5.txt Could you make a separate patch adding DT binding only ? And can you please rename this file to: Documentation/devicetree/bindings/media/samsung-s5k4e5.txt, like it's done in case of other sensors ? Ok will do that. Should I apply patches 02...11/13 already or would you like send the whole series updated ? AFAICS there are minor things pointed out by Hans not addressed yet ? Yes I will send the full series with the review comments addressed. Regards Arun -- 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/6] [media] mt9p031: Include linux/of.h header
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/i2c/mt9p031.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c index 4734836..1c2303d 100644 --- a/drivers/media/i2c/mt9p031.c +++ b/drivers/media/i2c/mt9p031.c @@ -19,6 +19,7 @@ #include linux/i2c.h #include linux/log2.h #include linux/module.h +#include linux/of.h #include linux/of_gpio.h #include linux/pm.h #include linux/regulator/consumer.h -- 1.7.9.5 -- 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/6] [media] adv7343: Include linux/of.h header
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/media/i2c/adv7343.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/i2c/adv7343.c b/drivers/media/i2c/adv7343.c index aeb56c5..d4e15a6 100644 --- a/drivers/media/i2c/adv7343.c +++ b/drivers/media/i2c/adv7343.c @@ -25,6 +25,7 @@ #include linux/module.h #include linux/videodev2.h #include linux/uaccess.h +#include linux/of.h #include media/adv7343.h #include media/v4l2-async.h -- 1.7.9.5 -- 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/6] [media] ths8200: Include linux/of.h header
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/media/i2c/ths8200.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/i2c/ths8200.c b/drivers/media/i2c/ths8200.c index a58a8f6..51e1964 100644 --- a/drivers/media/i2c/ths8200.c +++ b/drivers/media/i2c/ths8200.c @@ -19,6 +19,7 @@ #include linux/i2c.h #include linux/module.h +#include linux/of.h #include linux/v4l2-dv-timings.h #include media/v4l2-dv-timings.h -- 1.7.9.5 -- 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 4/6] [media] tvp514x: Include linux/of.h header
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/media/i2c/tvp514x.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c index 91f3dd4..83d85df 100644 --- a/drivers/media/i2c/tvp514x.c +++ b/drivers/media/i2c/tvp514x.c @@ -35,6 +35,7 @@ #include linux/videodev2.h #include linux/module.h #include linux/v4l2-mediabus.h +#include linux/of.h #include media/v4l2-async.h #include media/v4l2-device.h -- 1.7.9.5 -- 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 6/6] [media] gpio-ir-recv: Include linux/of.h header
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/media/rc/gpio-ir-recv.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c index 07aacfa..80c611c 100644 --- a/drivers/media/rc/gpio-ir-recv.c +++ b/drivers/media/rc/gpio-ir-recv.c @@ -16,6 +16,7 @@ #include linux/interrupt.h #include linux/gpio.h #include linux/slab.h +#include linux/of.h #include linux/of_gpio.h #include linux/platform_device.h #include linux/irq.h -- 1.7.9.5 -- 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 5/6] [media] tvp7002: Include linux/of.h header
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/media/i2c/tvp7002.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/i2c/tvp7002.c b/drivers/media/i2c/tvp7002.c index 24a08fa..912e1cc 100644 --- a/drivers/media/i2c/tvp7002.c +++ b/drivers/media/i2c/tvp7002.c @@ -29,6 +29,7 @@ #include linux/slab.h #include linux/videodev2.h #include linux/module.h +#include linux/of.h #include linux/v4l2-dv-timings.h #include media/tvp7002.h #include media/v4l2-async.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] [media] tvp7002: Include linux/of.h header
On Fri, Oct 18, 2013 at 8:37 AM, Sachin Kamat sachin.ka...@linaro.org wrote: 'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com Regrads, --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 4/6] [media] tvp514x: Include linux/of.h header
On Fri, Oct 18, 2013 at 8:37 AM, Sachin Kamat sachin.ka...@linaro.org wrote: 'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com Regrads, --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 3/6] [media] ths8200: Include linux/of.h header
On Fri, Oct 18, 2013 at 8:37 AM, Sachin Kamat sachin.ka...@linaro.org wrote: 'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com Regrads, --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 v9 09/13] [media] exynos5-fimc-is: Add the hardware pipeline control
Hi Hans,
Thank you for the review.
On Mon, Sep 30, 2013 at 6:13 PM, Hans Verkuil hverk...@xs4all.nl wrote:
On 09/27/2013 12:59 PM, Arun Kumar K wrote:
This patch adds the crucial hardware pipeline control for the
fimc-is driver. All the subdev nodes will call this pipeline
interfaces to reach the hardware. Responsibilities of this module
involves configuring and maintaining the hardware pipeline involving
multiple sub-ips like ISP, DRC, Scalers, ODC, 3DNR, FD etc.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Kilyeon Im kilyeon...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
.../media/platform/exynos5-is/fimc-is-pipeline.c | 1708
.../media/platform/exynos5-is/fimc-is-pipeline.h | 129 ++
2 files changed, 1837 insertions(+)
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-pipeline.c
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-pipeline.h
diff --git a/drivers/media/platform/exynos5-is/fimc-is-pipeline.c
b/drivers/media/platform/exynos5-is/fimc-is-pipeline.c
new file mode 100644
index 000..a73d952
--- /dev/null
+++ b/drivers/media/platform/exynos5-is/fimc-is-pipeline.c
snip
+int fimc_is_pipeline_open(struct fimc_is_pipeline *pipeline,
+ struct fimc_is_sensor *sensor)
+{
+ struct fimc_is *is = pipeline-is;
+ struct is_region *region;
+ unsigned long index[2] = {0};
+ int ret;
+
+ if (!sensor)
+ return -EINVAL;
+
+ mutex_lock(pipeline-pipe_lock);
+
+ if (test_bit(PIPELINE_OPEN, pipeline-state)) {
+ dev_err(pipeline-dev, Pipeline already open\n);
+ ret = -EINVAL;
+ goto err_exit;
+ }
+
+ pipeline-fcount = 0;
+ pipeline-sensor = sensor;
+
+ if (is-num_pipelines == 0) {
+ /* Init memory */
+ ret = fimc_is_pipeline_initmem(pipeline);
+ if (ret) {
+ dev_err(pipeline-dev, Pipeline memory init
failed\n);
+ goto err_exit;
+ }
+
+ /* Load firmware */
+ ret = fimc_is_pipeline_load_firmware(pipeline);
+ if (ret) {
+ dev_err(pipeline-dev, Firmware load failed\n);
+ goto err_fw;
+ }
+
+ /* Power ON */
+ ret = fimc_is_pipeline_power(pipeline, 1);
+ if (ret) {
+ dev_err(pipeline-dev, A5 power on failed\n);
+ goto err_fw;
+ }
+
+ /* Wait for FW Init to complete */
+ ret = fimc_is_itf_wait_init_state(is-interface);
+ if (ret) {
+ dev_err(pipeline-dev, FW init failed\n);
+ goto err_fw;
+ }
+ }
+
+ /* Open Sensor */
+ region = pipeline-is_region;
+ ret = fimc_is_itf_open_sensor(is-interface,
+ pipeline-instance,
+ sensor-drvdata-id,
+ sensor-i2c_bus,
+ pipeline-minfo-shared.paddr);
+ if (ret) {
+ dev_err(pipeline-dev, Open sensor failed\n);
+ goto err_exit;
+ }
+
+ /* Load setfile */
+ ret = fimc_is_pipeline_setfile(pipeline);
+ if (ret)
+ goto err_exit;
+
+ /* Stream off */
+ ret = fimc_is_itf_stream_off(is-interface, pipeline-instance);
+ if (ret)
+ goto err_exit;
+
+ /* Process off */
+ ret = fimc_is_itf_process_off(is-interface, pipeline-instance);
+ if (ret)
+ goto err_exit;
+
+ if (is-num_pipelines == 0) {
+ /* Copy init params to FW region */
+ memset(region-parameter, 0x0, sizeof(struct
is_param_region));
+
+ memcpy(region-parameter.sensor, init_sensor_param,
+ sizeof(struct sensor_param));
How about:
region-parameter.sensor = init_sensor_param;
Shorter and type-safe.
Ditto for the memcpy's below.
Yes this would make nicer code.
Will make this change.
Regards
Arun
--
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 v10 06/12] exynos5-fimc-is: Add scaler subdev
FIMC-IS has two hardware scalers named as scaler-codec and
scaler-preview. This patch adds the common code handling the
video nodes and subdevs of both the scalers.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Kilyeon Im kilyeon...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/platform/exynos5-is/fimc-is-scaler.c | 476
drivers/media/platform/exynos5-is/fimc-is-scaler.h | 106 +
2 files changed, 582 insertions(+)
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-scaler.c
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-scaler.h
diff --git a/drivers/media/platform/exynos5-is/fimc-is-scaler.c
b/drivers/media/platform/exynos5-is/fimc-is-scaler.c
new file mode 100644
index 000..029eb8b
--- /dev/null
+++ b/drivers/media/platform/exynos5-is/fimc-is-scaler.c
@@ -0,0 +1,476 @@
+/*
+ * Samsung EXYNOS5250 FIMC-IS (Imaging Subsystem) driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Arun Kumar K arun...@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 media/v4l2-ioctl.h
+#include media/videobuf2-dma-contig.h
+
+#include fimc-is.h
+
+#define IS_SCALER_DRV_NAME fimc-is-scaler
+
+static const struct fimc_is_fmt formats[] = {
+ {
+ .name = YUV 4:2:0 3p MultiPlanar,
+ .fourcc = V4L2_PIX_FMT_YUV420M,
+ .depth = {8, 2, 2},
+ .num_planes = 3,
+ },
+ {
+ .name = YUV 4:2:0 2p MultiPlanar,
+ .fourcc = V4L2_PIX_FMT_NV12M,
+ .depth = {8, 4},
+ .num_planes = 2,
+ },
+ {
+ .name = YUV 4:2:2 1p MultiPlanar,
+ .fourcc = V4L2_PIX_FMT_NV16,
+ .depth = {16},
+ .num_planes = 1,
+ },
+};
+#define NUM_FORMATS ARRAY_SIZE(formats)
+
+static const struct fimc_is_fmt *find_format(struct v4l2_format *f)
+{
+ unsigned int i;
+
+ for (i = 0; i NUM_FORMATS; i++) {
+ if (formats[i].fourcc == f-fmt.pix_mp.pixelformat)
+ return formats[i];
+ }
+ return NULL;
+}
+
+static int scaler_video_capture_start_streaming(struct vb2_queue *vq,
+ unsigned int count)
+{
+ struct fimc_is_scaler *ctx = vb2_get_drv_priv(vq);
+ int ret;
+
+ ret = fimc_is_pipeline_scaler_start(ctx-pipeline,
+ ctx-scaler_id,
+ vq-num_buffers,
+ ctx-fmt-num_planes);
+ if (ret) {
+ v4l2_err(ctx-subdev, Scaler start failed.\n);
+ return -EINVAL;
+ }
+
+ set_bit(STATE_RUNNING, ctx-capture_state);
+ return 0;
+}
+
+static int scaler_video_capture_stop_streaming(struct vb2_queue *vq)
+{
+ struct fimc_is_scaler *ctx = vb2_get_drv_priv(vq);
+ struct fimc_is_buf *buf;
+ int ret;
+
+ ret = fimc_is_pipeline_scaler_stop(ctx-pipeline, ctx-scaler_id);
+ if (ret)
+ v4l2_info(ctx-subdev, Scaler already stopped.\n);
+
+ /* Release un-used buffers */
+ while (!list_empty(ctx-wait_queue)) {
+ buf = fimc_is_scaler_wait_queue_get(ctx);
+ vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
+ }
+ while (!list_empty(ctx-run_queue)) {
+ buf = fimc_is_scaler_run_queue_get(ctx);
+ vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
+ }
+
+ clear_bit(STATE_RUNNING, ctx-capture_state);
+ return 0;
+}
+
+static int scaler_video_capture_queue_setup(struct vb2_queue *vq,
+ const struct v4l2_format *pfmt,
+ unsigned int *num_buffers, unsigned int *num_planes,
+ unsigned int sizes[], void *allocators[])
+{
+ struct fimc_is_scaler *ctx = vb2_get_drv_priv(vq);
+ const struct fimc_is_fmt *fmt = ctx-fmt;
+ unsigned int wh;
+ int i;
+
+ if (!fmt)
+ return -EINVAL;
+
+ *num_planes = fmt-num_planes;
+ wh = ctx-width * ctx-height;
+
+ for (i = 0; i *num_planes; i++) {
+ allocators[i] = ctx-alloc_ctx;
+ sizes[i] = (wh * fmt-depth[i]) / 8;
+ }
+ return 0;
+}
+
+static int scaler_video_capture_buffer_init(struct vb2_buffer *vb)
+{
+ struct vb2_queue *vq = vb-vb2_queue;
+ struct fimc_is_scaler *ctx = vb2_get_drv_priv(vq);
+ struct fimc_is_buf *buf = container_of(vb, struct fimc_is_buf, vb);
+ const struct fimc_is_fmt *fmt;
+ int i;
+
+ fmt = ctx-fmt;
+ for (i = 0; i fmt-num_planes; i++)
+ buf-paddr[i] = vb2_dma_contig_plane_dma_addr(vb, i);
+
+
[PATCH v10 07/12] exynos5-fimc-is: Add sensor interface
Some sensors to be used with fimc-is are exclusively controlled
by the fimc-is firmware. This minimal sensor driver provides
the required info for the firmware to configure the sensors
sitting on I2C bus.
Signed-off-by: Arun Kumar K arun...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/platform/exynos5-is/fimc-is-sensor.c | 45 ++
drivers/media/platform/exynos5-is/fimc-is-sensor.h | 65
2 files changed, 110 insertions(+)
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-sensor.c
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-sensor.h
diff --git a/drivers/media/platform/exynos5-is/fimc-is-sensor.c
b/drivers/media/platform/exynos5-is/fimc-is-sensor.c
new file mode 100644
index 000..475f1c3
--- /dev/null
+++ b/drivers/media/platform/exynos5-is/fimc-is-sensor.c
@@ -0,0 +1,45 @@
+/*
+ * Samsung EXYNOS5250 FIMC-IS (Imaging Subsystem) driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Arun Kumar K arun...@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 fimc-is-sensor.h
+
+static const struct sensor_drv_data s5k6a3_drvdata = {
+ .id = FIMC_IS_SENSOR_ID_S5K6A3,
+ .open_timeout = S5K6A3_OPEN_TIMEOUT,
+ .setfile_name = exynos5_s5k6a3_setfile.bin,
+};
+
+static const struct sensor_drv_data s5k4e5_drvdata = {
+ .id = FIMC_IS_SENSOR_ID_S5K4E5,
+ .open_timeout = S5K4E5_OPEN_TIMEOUT,
+ .setfile_name = exynos5_s5k4e5_setfile.bin,
+};
+
+static const struct of_device_id fimc_is_sensor_of_ids[] = {
+ {
+ .compatible = samsung,s5k6a3,
+ .data = s5k6a3_drvdata,
+ },
+ {
+ .compatible = samsung,s5k4e5,
+ .data = s5k4e5_drvdata,
+ },
+ { }
+};
+
+const struct sensor_drv_data *exynos5_is_sensor_get_drvdata(
+ struct device_node *node)
+{
+ const struct of_device_id *of_id;
+
+ of_id = of_match_node(fimc_is_sensor_of_ids, node);
+ return of_id ? of_id-data : NULL;
+}
diff --git a/drivers/media/platform/exynos5-is/fimc-is-sensor.h
b/drivers/media/platform/exynos5-is/fimc-is-sensor.h
new file mode 100644
index 000..0ba5733
--- /dev/null
+++ b/drivers/media/platform/exynos5-is/fimc-is-sensor.h
@@ -0,0 +1,65 @@
+/*
+ * Samsung EXYNOS4x12 FIMC-IS (Imaging Subsystem) driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Arun Kumar K arun...@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.
+ */
+#ifndef FIMC_IS_SENSOR_H_
+#define FIMC_IS_SENSOR_H_
+
+#include linux/of.h
+#include linux/types.h
+
+#define S5K6A3_OPEN_TIMEOUT2000 /* ms */
+#define S5K6A3_SENSOR_WIDTH1392
+#define S5K6A3_SENSOR_HEIGHT 1392
+
+#define S5K4E5_OPEN_TIMEOUT2000 /* ms */
+#define S5K4E5_SENSOR_WIDTH2560
+#define S5K4E5_SENSOR_HEIGHT 1920
+
+#define SENSOR_WIDTH_PADDING 16
+#define SENSOR_HEIGHT_PADDING 10
+
+enum fimc_is_sensor_id {
+ FIMC_IS_SENSOR_ID_S5K3H2 = 1,
+ FIMC_IS_SENSOR_ID_S5K6A3,
+ FIMC_IS_SENSOR_ID_S5K4E5,
+ FIMC_IS_SENSOR_ID_S5K3H7,
+ FIMC_IS_SENSOR_ID_CUSTOM,
+ FIMC_IS_SENSOR_ID_END
+};
+
+struct sensor_drv_data {
+ enum fimc_is_sensor_id id;
+ /* sensor open timeout in ms */
+ unsigned short open_timeout;
+ char *setfile_name;
+};
+
+/**
+ * struct fimc_is_sensor - fimc-is sensor data structure
+ * @drvdata: a pointer to the sensor's parameters data structure
+ * @i2c_bus: ISP I2C bus index (0...1)
+ * @width: sensor active width
+ * @height: sensor active height
+ * @pixel_width: sensor effective pixel width (width + padding)
+ * @pixel_height: sensor effective pixel height (height + padding)
+ */
+struct fimc_is_sensor {
+ const struct sensor_drv_data *drvdata;
+ unsigned int i2c_bus;
+ unsigned int width;
+ unsigned int height;
+ unsigned int pixel_width;
+ unsigned int pixel_height;
+};
+
+const struct sensor_drv_data *exynos5_is_sensor_get_drvdata(
+ struct device_node *node);
+
+#endif /* FIMC_IS_SENSOR_H_ */
--
1.7.9.5
--
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 v10 05/12] exynos5-fimc-is: Add isp subdev
fimc-is driver takes video data input from the ISP video node
which is added in this patch. This node accepts Bayer input
buffers which is given from the IS sensors.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Kilyeon Im kilyeon...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/platform/exynos5-is/fimc-is-isp.c | 534 +++
drivers/media/platform/exynos5-is/fimc-is-isp.h | 90
2 files changed, 624 insertions(+)
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-isp.c
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-isp.h
diff --git a/drivers/media/platform/exynos5-is/fimc-is-isp.c
b/drivers/media/platform/exynos5-is/fimc-is-isp.c
new file mode 100644
index 000..7bd603f
--- /dev/null
+++ b/drivers/media/platform/exynos5-is/fimc-is-isp.c
@@ -0,0 +1,534 @@
+/*
+ * Samsung EXYNOS5250 FIMC-IS (Imaging Subsystem) driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Arun Kumar K arun...@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 media/v4l2-ioctl.h
+#include media/videobuf2-dma-contig.h
+
+#include fimc-is.h
+
+#define ISP_DRV_NAME fimc-is-isp
+
+static const struct fimc_is_fmt formats[] = {
+ {
+ .name = Bayer GR-BG 8bits,
+ .fourcc = V4L2_PIX_FMT_SGRBG8,
+ .depth = { 8 },
+ .num_planes = 1,
+ },
+ {
+ .name = Bayer GR-BG 10bits,
+ .fourcc = V4L2_PIX_FMT_SGRBG10,
+ .depth = { 16 },
+ .num_planes = 1,
+ },
+ {
+ .name = Bayer GR-BG 12bits,
+ .fourcc = V4L2_PIX_FMT_SGRBG12,
+ .depth = { 16 },
+ .num_planes = 1,
+ },
+};
+#define NUM_FORMATS ARRAY_SIZE(formats)
+
+static const struct fimc_is_fmt *find_format(struct v4l2_format *f)
+{
+ unsigned int i;
+
+ for (i = 0; i NUM_FORMATS; i++)
+ if (formats[i].fourcc == f-fmt.pix_mp.pixelformat)
+ return formats[i];
+ return NULL;
+}
+
+static int isp_video_output_start_streaming(struct vb2_queue *vq,
+ unsigned int count)
+{
+ struct fimc_is_isp *isp = vb2_get_drv_priv(vq);
+
+ set_bit(STATE_RUNNING, isp-output_state);
+ return 0;
+}
+
+static int isp_video_output_stop_streaming(struct vb2_queue *vq)
+{
+ struct fimc_is_isp *isp = vb2_get_drv_priv(vq);
+ struct fimc_is_buf *buf;
+
+ /* Release unused buffers */
+ while (!list_empty(isp-wait_queue)) {
+ buf = fimc_is_isp_wait_queue_get(isp);
+ vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
+ }
+ while (!list_empty(isp-run_queue)) {
+ buf = fimc_is_isp_run_queue_get(isp);
+ vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
+ }
+
+ clear_bit(STATE_RUNNING, isp-output_state);
+ return 0;
+}
+
+static int isp_video_output_queue_setup(struct vb2_queue *vq,
+ const struct v4l2_format *pfmt,
+ unsigned int *num_buffers, unsigned int *num_planes,
+ unsigned int sizes[], void *allocators[])
+{
+ struct fimc_is_isp *isp = vb2_get_drv_priv(vq);
+ const struct fimc_is_fmt *fmt = isp-fmt;
+ unsigned int wh, i;
+
+ if (!fmt)
+ return -EINVAL;
+
+ *num_planes = fmt-num_planes;
+ wh = isp-width * isp-height;
+
+ for (i = 0; i *num_planes; i++) {
+ allocators[i] = isp-alloc_ctx;
+ sizes[i] = (wh * fmt-depth[i]) / 8;
+ }
+ return 0;
+}
+
+static int isp_video_output_buffer_init(struct vb2_buffer *vb)
+{
+ struct fimc_is_buf *buf = container_of(vb, struct fimc_is_buf, vb);
+
+ buf-paddr[0] = vb2_dma_contig_plane_dma_addr(vb, 0);
+ return 0;
+}
+
+static int isp_video_output_buffer_prepare(struct vb2_buffer *vb)
+{
+ struct vb2_queue *vq = vb-vb2_queue;
+ struct fimc_is_isp *isp = vb2_get_drv_priv(vq);
+ unsigned long size;
+
+ size = (isp-width * isp-height * isp-fmt-depth[0]) / 8;
+ if (vb2_plane_size(vb, 0) size) {
+ v4l2_err(isp-subdev, User buffer too small (%ld %ld)\n,
+vb2_plane_size(vb, 0), size);
+ return -EINVAL;
+ }
+ vb2_set_plane_payload(vb, 0, size);
+
+ return 0;
+}
+
+static void isp_video_output_buffer_queue(struct vb2_buffer *vb)
+{
+ struct vb2_queue *vq = vb-vb2_queue;
+ struct fimc_is_isp *isp = vb2_get_drv_priv(vq);
+ struct fimc_is_buf *buf = container_of(vb, struct fimc_is_buf, vb);
+
+
[PATCH v10 00/12] Exynos5 IS driver
The patch series adds support for exynos5 fimc-is driver and a new sensor s5k4e5. The media driver part is omitted form this series as it is already applied. Changes from v9 --- - Addressed review comments from Hans and Sylwester http://www.mail-archive.com/linux-media@vger.kernel.org/msg67102.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg67624.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg67623.html - Skipped already applied media driver Changes from v8 --- - Moved i2c-isp device nodes into the fimc-is node as suggested by Sylwester - Addressed comments given by Sylwester and Philipp Zabel Changes from v7 --- - Addressed few DT related review comments from Sylwester http://www.mail-archive.com/linux-media@vger.kernel.org/msg66403.html - Few fixes added after some regression testing Changes from v6 --- - Addressed DT binding doc review comments from Sylwester http://www.mail-archive.com/linux-media@vger.kernel.org/msg65771.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg65772.html Changes from v5 --- - Addressed review comments from Sylwester http://www.mail-archive.com/linux-media@vger.kernel.org/msg65578.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg65605.html Changes from v4 --- - Addressed all review comments from Sylwester - Added separate PMU node as suggested by Stephen Warren - Added phandle based discovery of subdevs instead of node name Changes from v3 --- - Dropped the RFC tag - Addressed all review comments from Sylwester and Sachin - Removed clock provider for media dev - Added s5k4e5 sensor devicetree binding doc Changes from v2 --- - Added exynos5 media device driver from Shaik to this series - Added ISP pipeline support in media device driver - Based on Sylwester's latest exynos4-is development - Asynchronos registration of sensor subdevs - Made independent IS-sensor support - Add s5k4e5 sensor driver - Addressed review comments from Sylwester, Hans, Andrzej, Sachin Changes from v1 --- - Addressed all review comments from Sylwester - Made sensor subdevs as independent i2c devices - Lots of cleanup - Debugfs support added - Removed PMU global register access Arun Kumar K (12): exynos5-fimc-is: Add Exynos5 FIMC-IS device tree bindings documentation exynos5-fimc-is: Add driver core files exynos5-fimc-is: Add common driver header files exynos5-fimc-is: Add register definition and context header exynos5-fimc-is: Add isp subdev exynos5-fimc-is: Add scaler subdev exynos5-fimc-is: Add sensor interface exynos5-fimc-is: Add the hardware pipeline control exynos5-fimc-is: Add the hardware interface module exynos5-is: Add Kconfig and Makefile V4L: Add DT binding doc for s5k4e5 image sensor V4L: Add s5k4e5 sensor driver .../devicetree/bindings/media/exynos5-fimc-is.txt | 84 + .../devicetree/bindings/media/samsung-s5k4e5.txt | 45 + drivers/media/i2c/Kconfig |8 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/s5k4e5.c | 344 drivers/media/platform/Kconfig |1 + drivers/media/platform/Makefile|1 + drivers/media/platform/exynos5-is/Kconfig | 20 + drivers/media/platform/exynos5-is/Makefile |7 + drivers/media/platform/exynos5-is/fimc-is-cmd.h| 187 +++ drivers/media/platform/exynos5-is/fimc-is-core.c | 410 + drivers/media/platform/exynos5-is/fimc-is-core.h | 132 ++ drivers/media/platform/exynos5-is/fimc-is-err.h| 257 +++ .../media/platform/exynos5-is/fimc-is-interface.c | 810 ++ .../media/platform/exynos5-is/fimc-is-interface.h | 124 ++ drivers/media/platform/exynos5-is/fimc-is-isp.c| 534 ++ drivers/media/platform/exynos5-is/fimc-is-isp.h| 90 ++ .../media/platform/exynos5-is/fimc-is-metadata.h | 767 + drivers/media/platform/exynos5-is/fimc-is-param.h | 1159 + .../media/platform/exynos5-is/fimc-is-pipeline.c | 1699 .../media/platform/exynos5-is/fimc-is-pipeline.h | 129 ++ drivers/media/platform/exynos5-is/fimc-is-regs.h | 105 ++ drivers/media/platform/exynos5-is/fimc-is-scaler.c | 476 ++ drivers/media/platform/exynos5-is/fimc-is-scaler.h | 106 ++ drivers/media/platform/exynos5-is/fimc-is-sensor.c | 45 + drivers/media/platform/exynos5-is/fimc-is-sensor.h | 65 + drivers/media/platform/exynos5-is/fimc-is.h| 160 ++ 27 files changed, 7766 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/exynos5-fimc-is.txt create mode 100644 Documentation/devicetree/bindings/media/samsung-s5k4e5.txt create mode 100644 drivers/media/i2c/s5k4e5.c create mode 100644 drivers/media/platform/exynos5-is/Kconfig create mode 100644 drivers/media/platform/exynos5-is/Makefile
[PATCH v10 04/12] exynos5-fimc-is: Add register definition and context header
This patch adds the register definition file for the fimc-is driver and also the header file containing the main context for the driver. Signed-off-by: Arun Kumar K arun...@samsung.com Signed-off-by: Kilyeon Im kilyeon...@samsung.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com --- drivers/media/platform/exynos5-is/fimc-is-regs.h | 105 ++ drivers/media/platform/exynos5-is/fimc-is.h | 160 ++ 2 files changed, 265 insertions(+) create mode 100644 drivers/media/platform/exynos5-is/fimc-is-regs.h create mode 100644 drivers/media/platform/exynos5-is/fimc-is.h diff --git a/drivers/media/platform/exynos5-is/fimc-is-regs.h b/drivers/media/platform/exynos5-is/fimc-is-regs.h new file mode 100644 index 000..06aa466 --- /dev/null +++ b/drivers/media/platform/exynos5-is/fimc-is-regs.h @@ -0,0 +1,105 @@ +/* + * Samsung Exynos5 SoC series FIMC-IS driver + * + * Copyright (c) 2013 Samsung Electronics Co., Ltd + * Arun Kumar K arun...@samsung.com + * Kil-yeon Lim kilyeon...@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. + */ + +#ifndef FIMC_IS_REGS_H +#define FIMC_IS_REGS_H + +/* WDT_ISP register */ +#define WDT0x0017 +/* MCUCTL register */ +#define MCUCTL 0x0018 +/* MCU Controller Register */ +#define MCUCTLR(MCUCTL+0x00) +#define MCUCTLR_AXI_ISPX_AWCACHE(x)((x) 16) +#define MCUCTLR_AXI_ISPX_ARCACHE(x)((x) 12) +#define MCUCTLR_MSWRST (1 0) +/* Boot Base OFfset Address Register */ +#define BBOAR (MCUCTL+0x04) +#define BBOAR_BBOA(x) ((x) 0) + +/* Interrupt Generation Register 0 from Host CPU to VIC */ +#define INTGR0 (MCUCTL+0x08) +#define INTGR0_INTGC(n)(1 ((n) + 16)) +#define INTGR0_INTGD(n)(1 (n)) + +/* Interrupt Clear Register 0 from Host CPU to VIC */ +#define INTCR0 (MCUCTL+0x0c) +#define INTCR0_INTCC(n)(1 ((n) + 16)) +#define INTCR0_INTCD(n)(1 (n)) + +/* Interrupt Mask Register 0 from Host CPU to VIC */ +#define INTMR0 (MCUCTL+0x10) +#define INTMR0_INTMC(n)(1 ((n) + 16)) +#define INTMR0_INTMD(n)(1 (n)) + +/* Interrupt Status Register 0 from Host CPU to VIC */ +#define INTSR0 (MCUCTL+0x14) +#define INTSR0_GET_INTSD(n, x) (((x) (n)) 0x1) +#define INTSR0_GET_INTSC(n, x) (((x) ((n) + 16)) 0x1) + +/* Interrupt Mask Status Register 0 from Host CPU to VIC */ +#define INTMSR0(MCUCTL+0x18) +#define INTMSR0_GET_INTMSD(n, x) (((x) (n)) 0x1) +#define INTMSR0_GET_INTMSC(n, x) (((x) ((n) + 16)) 0x1) + +/* Interrupt Generation Register 1 from ISP CPU to Host IC */ +#define INTGR1 (MCUCTL+0x1c) +#define INTGR1_INTGC(n)(1 (n)) + +/* Interrupt Clear Register 1 from ISP CPU to Host IC */ +#define INTCR1 (MCUCTL+0x20) +#define INTCR1_INTCC(n)(1 (n)) + +/* Interrupt Mask Register 1 from ISP CPU to Host IC */ +#define INTMR1 (MCUCTL+0x24) +#define INTMR1_INTMC(n)(1 (n)) + +/* Interrupt Status Register 1 from ISP CPU to Host IC */ +#define INTSR1 (MCUCTL+0x28) +/* Interrupt Mask Status Register 1 from ISP CPU to Host IC */ +#define INTMSR1(MCUCTL+0x2c) +/* Interrupt Clear Register 2 from ISP BLK's interrupts to Host IC */ +#define INTCR2 (MCUCTL+0x30) +#define INTCR2_INTCC(n)(1 (n)) + +/* Interrupt Mask Register 2 from ISP BLK's interrupts to Host IC */ +#define INTMR2 (MCUCTL+0x34) +#define INTMR2_INTMCIS(n) (1 (n)) + +/* Interrupt Status Register 2 from ISP BLK's interrupts to Host IC */ +#define INTSR2 (MCUCTL+0x38) +/* Interrupt Mask Status Register 2 from ISP BLK's interrupts to Host IC */ +#define INTMSR2(MCUCTL+0x3c) +/* General Purpose Output Control Register (0~17) */ +#define GPOCTLR(MCUCTL+0x40) +#define GPOCTLR_GPOG(n, x) ((x) (n)) + +/* General Purpose Pad Output Enable Register (0~17) */ +#define GPOENCTLR (MCUCTL+0x44) +#define GPOENCTLR_GPOEN0(n, x) ((x) (n)) + +/* General Purpose Input Control Register (0~17) */ +#define GPICTLR(MCUCTL+0x48) + +/* IS Shared Registers between ISP CPU and HOST CPU */ +#define ISSR(n)(MCUCTL + 0x80 + (n)) + +/* PMU for FIMC-IS*/ +#define
[PATCH v10 01/12] exynos5-fimc-is: Add Exynos5 FIMC-IS device tree bindings documentation
The patch adds the DT binding documentation for Samsung
Exynos5 SoC series imaging subsystem (FIMC-IS).
Signed-off-by: Arun Kumar K arun...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
.../devicetree/bindings/media/exynos5-fimc-is.txt | 84
1 file changed, 84 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/exynos5-fimc-is.txt
diff --git a/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt
b/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt
new file mode 100644
index 000..0525417
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt
@@ -0,0 +1,84 @@
+Samsung EXYNOS5 SoC series Imaging Subsystem (FIMC-IS)
+--
+
+The camera subsystem on Samsung Exynos5 SoC has some changes relative
+to previous SoC versions. Exynos5 has almost similar MIPI-CSIS and
+FIMC-LITE IPs but has a much improved version of FIMC-IS which can
+handle sensor controls and camera post-processing operations. The
+Exynos5 FIMC-IS has a dedicated ARM Cortex A5 processor, many
+post-processing blocks (ISP, DRC, FD, ODC, DIS, 3DNR) and two
+dedicated scalers (SCC and SCP).
+
+fimc-is node
+
+
+Required properties:
+
+- compatible: must be samsung,exynos5250-fimc-is
+- reg : physical base address and size of the memory mapped
+ registers
+- interrupt-parent : parent interrupt controller
+- interrupts: fimc-is interrupt to the parent interrupt controller
+- clocks: list of clock specifiers, corresponding to entries in
+ clock-names property
+- clock-names : must contain isp, mcu_isp, isp_div0, isp_div1,
+ isp_divmpwm, mcu_isp_div0, mcu_isp_div1 entries,
+ matching entries in the clocks property
+- samsung,pmu : phandle to the Power Management Unit (PMU) node
+
+i2c-isp (ISP I2C bus controller) nodes
+--
+The i2c-isp node is defined as the child node of fimc-is.
+
+Required properties:
+
+- compatible : should be samsung,exynos4212-i2c-isp for Exynos4212,
+ Exynos4412 and Exynos5250 SoCs
+- reg : physical base address and length of the registers set
+- clocks : must contain gate clock specifier for this controller
+- clock-names : must contain i2c_isp entry
+
+For the i2c-isp node, it is required to specify a pinctrl state named
default,
+according to the pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt.
+
+Device tree nodes of the image sensors controlled directly by the FIMC-IS
+firmware must be child nodes of their corresponding ISP I2C bus controller
node.
+The data link of these image sensors must be specified using the common video
+interfaces bindings, defined in video-interfaces.txt.
+
+Example:
+
+ fimc_is: fimc-is@1300 {
+ compatible = samsung,exynos5250-fimc-is;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ reg = 0x1300 0x20;
+ interrupt-parent = combiner;
+ interrupts = 19 1;
+ clocks = clock 346, clock 347, clock 512,
+ clock 513, clock 514, clock 515,
+ clock 516;
+ clock-names = isp, mcu_isp, isp_div0, isp_div1,
+ isp_divmpwm, mcu_isp_div0,
+ mcu_isp_div1;
+ samsung,pmu = pmu;
+
+ i2c0_isp: i2c-isp@1313 {
+ compatible = samsung,exynos4212-i2c-isp;
+ reg = 0x1313 0x100;
+ #address-cells = 1;
+ #size-cells = 0;
+ clocks = clock 352;
+ clock-names = i2c_isp;
+ };
+
+ i2c1_isp: i2c-isp@1314 {
+ compatible = samsung,exynos4212-i2c-isp;
+ reg = 0x1314 0x100;
+ #address-cells = 1;
+ #size-cells = 0;
+ clocks = clock 353;
+ clock-names = i2c_isp;
+ };
+ };
--
1.7.9.5
--
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 v10 02/12] exynos5-fimc-is: Add driver core files
This driver is for the FIMC-IS IP available in Samsung Exynos5
SoC onwards. This patch adds the core files for the new driver.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Kilyeon Im kilyeon...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/platform/exynos5-is/fimc-is-core.c | 410 ++
drivers/media/platform/exynos5-is/fimc-is-core.h | 132 +++
2 files changed, 542 insertions(+)
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-core.c
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-core.h
diff --git a/drivers/media/platform/exynos5-is/fimc-is-core.c
b/drivers/media/platform/exynos5-is/fimc-is-core.c
new file mode 100644
index 000..2b116d0
--- /dev/null
+++ b/drivers/media/platform/exynos5-is/fimc-is-core.c
@@ -0,0 +1,410 @@
+/*
+ * Samsung EXYNOS5 FIMC-IS (Imaging Subsystem) driver
+*
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Arun Kumar K arun...@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/bug.h
+#include linux/ctype.h
+#include linux/device.h
+#include linux/debugfs.h
+#include linux/delay.h
+#include linux/errno.h
+#include linux/err.h
+#include linux/firmware.h
+#include linux/fs.h
+#include linux/gpio.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/list.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/of_address.h
+#include linux/of_platform.h
+#include linux/of_irq.h
+#include linux/pinctrl/consumer.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/slab.h
+#include linux/types.h
+#include linux/videodev2.h
+
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-mem2mem.h
+#include media/v4l2-of.h
+#include media/videobuf2-core.h
+#include media/videobuf2-dma-contig.h
+
+#include fimc-is.h
+#include fimc-is-i2c.h
+
+#define CLK_MCU_ISP_DIV0_FREQ (200 * 100)
+#define CLK_MCU_ISP_DIV1_FREQ (100 * 100)
+#define CLK_ISP_DIV0_FREQ (134 * 100)
+#define CLK_ISP_DIV1_FREQ (68 * 100)
+#define CLK_ISP_DIVMPWM_FREQ (34 * 100)
+
+static const char * const fimc_is_clock_name[] = {
+ [IS_CLK_ISP]= isp,
+ [IS_CLK_MCU_ISP]= mcu_isp,
+ [IS_CLK_ISP_DIV0] = isp_div0,
+ [IS_CLK_ISP_DIV1] = isp_div1,
+ [IS_CLK_ISP_DIVMPWM]= isp_divmpwm,
+ [IS_CLK_MCU_ISP_DIV0] = mcu_isp_div0,
+ [IS_CLK_MCU_ISP_DIV1] = mcu_isp_div1,
+};
+
+static void fimc_is_put_clocks(struct fimc_is *is)
+{
+ int i;
+
+ for (i = 0; i IS_CLK_MAX_NUM; i++) {
+ if (IS_ERR(is-clock[i]))
+ continue;
+ clk_unprepare(is-clock[i]);
+ clk_put(is-clock[i]);
+ is-clock[i] = ERR_PTR(-EINVAL);
+ }
+}
+
+static int fimc_is_get_clocks(struct fimc_is *is)
+{
+ struct device *dev = is-pdev-dev;
+ int i, ret;
+
+ for (i = 0; i IS_CLK_MAX_NUM; i++) {
+ is-clock[i] = clk_get(dev, fimc_is_clock_name[i]);
+ if (IS_ERR(is-clock[i]))
+ goto err;
+ ret = clk_prepare(is-clock[i]);
+ if (ret 0) {
+ clk_put(is-clock[i]);
+ is-clock[i] = ERR_PTR(-EINVAL);
+ goto err;
+ }
+ }
+ return 0;
+err:
+ fimc_is_put_clocks(is);
+ pr_err(Failed to get clock: %s\n, fimc_is_clock_name[i]);
+ return -ENXIO;
+}
+
+static int fimc_is_configure_clocks(struct fimc_is *is)
+{
+ int i, ret;
+
+ for (i = 0; i IS_CLK_MAX_NUM; i++)
+ is-clock[i] = ERR_PTR(-EINVAL);
+
+ ret = fimc_is_get_clocks(is);
+ if (ret)
+ return ret;
+
+ /* Set rates */
+ ret = clk_set_rate(is-clock[IS_CLK_MCU_ISP_DIV0],
+ CLK_MCU_ISP_DIV0_FREQ);
+ if (ret)
+ return ret;
+ ret = clk_set_rate(is-clock[IS_CLK_MCU_ISP_DIV1],
+ CLK_MCU_ISP_DIV1_FREQ);
+ if (ret)
+ return ret;
+ ret = clk_set_rate(is-clock[IS_CLK_ISP_DIV0], CLK_ISP_DIV0_FREQ);
+ if (ret)
+ return ret;
+ ret = clk_set_rate(is-clock[IS_CLK_ISP_DIV1], CLK_ISP_DIV1_FREQ);
+ if (ret)
+ return ret;
+ ret = clk_set_rate(is-clock[IS_CLK_ISP_DIVMPWM],
+ CLK_ISP_DIVMPWM_FREQ);
+ return ret;
+}
+
+static void fimc_is_pipelines_destroy(struct fimc_is *is)
+{
+ int i;
+
+ for (i = 0; i is-drvdata-num_instances; i++)
+ fimc_is_pipeline_destroy(is-pipeline[i]);
+}
+
+static int fimc_is_parse_sensor_config(struct fimc_is *is, unsigned int index,
+
[PATCH v10 09/12] exynos5-fimc-is: Add the hardware interface module
The hardware interface module finally sends the commands to the
FIMC-IS firmware and runs the interrupt handler for getting the
responses.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Kilyeon Im kilyeon...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
.../media/platform/exynos5-is/fimc-is-interface.c | 810
.../media/platform/exynos5-is/fimc-is-interface.h | 124 +++
2 files changed, 934 insertions(+)
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-interface.c
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-interface.h
diff --git a/drivers/media/platform/exynos5-is/fimc-is-interface.c
b/drivers/media/platform/exynos5-is/fimc-is-interface.c
new file mode 100644
index 000..c5da6ff
--- /dev/null
+++ b/drivers/media/platform/exynos5-is/fimc-is-interface.c
@@ -0,0 +1,810 @@
+/*
+ * Samsung EXYNOS5 FIMC-IS (Imaging Subsystem) driver
+*
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Kil-yeon Lim kilyeon...@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/debugfs.h
+#include linux/seq_file.h
+#include fimc-is.h
+#include fimc-is-cmd.h
+#include fimc-is-regs.h
+
+#define init_request_barrier(itf) mutex_init(itf-request_barrier)
+#define enter_request_barrier(itf) mutex_lock(itf-request_barrier)
+#define exit_request_barrier(itf) mutex_unlock(itf-request_barrier)
+
+static inline void itf_get_cmd(struct fimc_is_interface *itf,
+ struct fimc_is_msg *msg, unsigned int index)
+{
+ struct is_common_reg __iomem *com_regs = itf-com_regs;
+
+ memset(msg, 0, sizeof(*msg));
+
+ switch (index) {
+ case INTR_GENERAL:
+ msg-command = com_regs-ihcmd;
+ msg-instance = com_regs-ihc_sensorid;
+ memcpy(msg-param, com_regs-ihc_param,
+ 4 * sizeof(msg-param[0]));
+ break;
+ case INTR_SCC_FDONE:
+ msg-command = IHC_FRAME_DONE;
+ msg-instance = com_regs-scc_sensor_id;
+ memcpy(msg-param, com_regs-scc_param,
+ 3 * sizeof(msg-param[0]));
+ break;
+ case INTR_SCP_FDONE:
+ msg-command = IHC_FRAME_DONE;
+ msg-instance = com_regs-scp_sensor_id;
+ memcpy(msg-param, com_regs-scp_param,
+ 3 * sizeof(msg-param[0]));
+ break;
+ case INTR_META_DONE:
+ msg-command = IHC_FRAME_DONE;
+ msg-instance = com_regs-meta_sensor_id;
+ msg-param[0] = com_regs-meta_param1;
+ break;
+ case INTR_SHOT_DONE:
+ msg-command = IHC_FRAME_DONE;
+ msg-instance = com_regs-shot_sensor_id;
+ memcpy(msg-param, com_regs-shot_param,
+ 2 * sizeof(msg-param[0]));
+ break;
+ default:
+ dev_err(itf-dev, %s Unknown command\n, __func__);
+ break;
+ }
+}
+
+static inline unsigned int itf_get_intr(struct fimc_is_interface *itf)
+{
+ unsigned int status;
+ struct is_common_reg __iomem *com_regs = itf-com_regs;
+
+ status = readl(itf-regs + INTMSR1) | com_regs-ihcmd_iflag |
+ com_regs-scc_iflag |
+ com_regs-scp_iflag |
+ com_regs-meta_iflag |
+ com_regs-shot_iflag;
+
+ return status;
+}
+
+static void itf_set_state(struct fimc_is_interface *itf,
+ unsigned long state)
+{
+ unsigned long flags;
+ spin_lock_irqsave(itf-slock_state, flags);
+ __set_bit(state, itf-state);
+ spin_unlock_irqrestore(itf-slock_state, flags);
+}
+
+static void itf_clr_state(struct fimc_is_interface *itf,
+ unsigned long state)
+{
+ unsigned long flags;
+ spin_lock_irqsave(itf-slock_state, flags);
+ __clear_bit(state, itf-state);
+ spin_unlock_irqrestore(itf-slock_state, flags);
+}
+
+static int itf_get_state(struct fimc_is_interface *itf,
+ unsigned long state)
+{
+ int ret = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(itf-slock_state, flags);
+ ret = test_bit(state, itf-state);
+ spin_unlock_irqrestore(itf-slock_state, flags);
+ return ret;
+}
+
+static void itf_init_wakeup(struct fimc_is_interface *itf)
+{
+ itf_set_state(itf, IS_IF_STATE_INIT);
+ wake_up(itf-irq_queue);
+}
+
+void itf_busy_wakeup(struct fimc_is_interface *itf)
+{
+ itf_clr_state(itf, IS_IF_STATE_BUSY);
+ wake_up(itf-irq_queue);
+}
+
+static int itf_wait_hw_ready(struct fimc_is_interface *itf)
+{
+ int t;
+ for (t = TRY_RECV_AWARE_COUNT; t = 0; t--) {
+ unsigned int cfg = readl(itf-regs + INTMSR0);
+
[PATCH v10 12/12] V4L: Add s5k4e5 sensor driver
This patch adds subdev driver for Samsung S5K4E5 raw image sensor.
Like s5k6a3, it is also another fimc-is firmware controlled
sensor. This minimal sensor driver doesn't do any I2C communications
as its done by ISP firmware. It can be updated if needed to a
regular sensor driver by adding the I2C communication.
Signed-off-by: Arun Kumar K arun...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/i2c/Kconfig |8 ++
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/s5k4e5.c | 344
3 files changed, 353 insertions(+)
create mode 100644 drivers/media/i2c/s5k4e5.c
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index d18be19..67301d1 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -587,6 +587,14 @@ config VIDEO_S5K6AA
This is a V4L2 sensor-level driver for Samsung S5K6AA(FX) 1.3M
camera sensor with an embedded SoC image signal processor.
+config VIDEO_S5K4E5
+ tristate Samsung S5K4E5 sensor support
+ depends on MEDIA_CAMERA_SUPPORT
+ depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API OF
+ ---help---
+ This is a V4L2 sensor-level driver for Samsung S5K4E5 raw
+ camera sensor.
+
config VIDEO_S5K4ECGX
tristate Samsung S5K4ECGX sensor support
depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 9f462df..b920a14 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o
+obj-$(CONFIG_VIDEO_S5K4E5) += s5k4e5.o
obj-$(CONFIG_VIDEO_S5K4ECGX) += s5k4ecgx.o
obj-$(CONFIG_VIDEO_S5C73M3)+= s5c73m3/
obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o
diff --git a/drivers/media/i2c/s5k4e5.c b/drivers/media/i2c/s5k4e5.c
new file mode 100644
index 000..5d4007e
--- /dev/null
+++ b/drivers/media/i2c/s5k4e5.c
@@ -0,0 +1,344 @@
+/*
+ * Samsung S5K4E5 image sensor driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Arun Kumar K arun...@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/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/errno.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_gpio.h
+#include linux/pm_runtime.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+#include linux/videodev2.h
+#include media/v4l2-async.h
+#include media/v4l2-subdev.h
+
+#define S5K4E5_SENSOR_MAX_WIDTH2576
+#define S5K4E5_SENSOR_MAX_HEIGHT 1930
+
+#define S5K4E5_SENSOR_MIN_WIDTH(32 + 16)
+#define S5K4E5_SENSOR_MIN_HEIGHT (32 + 10)
+
+#define S5K4E5_DEF_WIDTH 1296
+#define S5K4E5_DEF_HEIGHT 732
+
+#define S5K4E5_DRV_NAMES5K4E5
+#define S5K4E5_CLK_NAMEextclk
+
+#define S5K4E5_NUM_SUPPLIES2
+
+#define S5K4E5_DEF_CLK_FREQ2400
+
+/**
+ * struct s5k4e5 - s5k4e5 sensor data structure
+ * @dev: pointer to this I2C client device structure
+ * @subdev: the image sensor's v4l2 subdev
+ * @pad: subdev media source pad
+ * @supplies: image sensor's voltage regulator supplies
+ * @gpio_reset: GPIO connected to the sensor's reset pin
+ * @lock: mutex protecting the structure's members below
+ * @format: media bus format at the sensor's source pad
+ */
+struct s5k4e5 {
+ struct device *dev;
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct regulator_bulk_data supplies[S5K4E5_NUM_SUPPLIES];
+ int gpio_reset;
+ struct mutex lock;
+ struct v4l2_mbus_framefmt format;
+ struct clk *clock;
+ u32 clock_frequency;
+};
+
+static const char * const s5k4e5_supply_names[] = {
+ svdda,
+ svddio
+};
+
+static inline struct s5k4e5 *sd_to_s5k4e5(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct s5k4e5, subdev);
+}
+
+static const struct v4l2_mbus_framefmt s5k4e5_formats[] = {
+ {
+ .code = V4L2_MBUS_FMT_SGRBG10_1X10,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .field = V4L2_FIELD_NONE,
+ }
+};
+
+static const struct v4l2_mbus_framefmt *find_sensor_format(
+ struct v4l2_mbus_framefmt *mf)
+{
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(s5k4e5_formats); i++)
+ if (mf-code == s5k4e5_formats[i].code)
+ return s5k4e5_formats[i];
+
+ return s5k4e5_formats[0];
+}
+
+static int s5k4e5_enum_mbus_code(struct v4l2_subdev *sd,
+
[PATCH v10 08/12] exynos5-fimc-is: Add the hardware pipeline control
This patch adds the crucial hardware pipeline control for the
fimc-is driver. All the subdev nodes will call this pipeline
interfaces to reach the hardware. Responsibilities of this module
involves configuring and maintaining the hardware pipeline involving
multiple sub-ips like ISP, DRC, Scalers, ODC, 3DNR, FD etc.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Kilyeon Im kilyeon...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
.../media/platform/exynos5-is/fimc-is-pipeline.c | 1699
.../media/platform/exynos5-is/fimc-is-pipeline.h | 129 ++
2 files changed, 1828 insertions(+)
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-pipeline.c
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-pipeline.h
diff --git a/drivers/media/platform/exynos5-is/fimc-is-pipeline.c
b/drivers/media/platform/exynos5-is/fimc-is-pipeline.c
new file mode 100644
index 000..25eaf24
--- /dev/null
+++ b/drivers/media/platform/exynos5-is/fimc-is-pipeline.c
@@ -0,0 +1,1699 @@
+/*
+ * Samsung EXYNOS5 FIMC-IS (Imaging Subsystem) driver
+*
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Arun Kumar K arun...@samsung.com
+ * Kil-yeon Lim kilyeon...@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 fimc-is.h
+#include fimc-is-pipeline.h
+#include fimc-is-metadata.h
+#include fimc-is-regs.h
+#include fimc-is-cmd.h
+#include media/videobuf2-dma-contig.h
+#include linux/delay.h
+
+/* Default setting values */
+#define DEFAULT_PREVIEW_STILL_WIDTH1280
+#define DEFAULT_PREVIEW_STILL_HEIGHT 720
+#define DEFAULT_CAPTURE_VIDEO_WIDTH1920
+#define DEFAULT_CAPTURE_VIDEO_HEIGHT 1080
+#define DEFAULT_CAPTURE_STILL_WIDTH2560
+#define DEFAULT_CAPTURE_STILL_HEIGHT 1920
+#define DEFAULT_CAPTURE_STILL_CROP_WIDTH 2560
+#define DEFAULT_CAPTURE_STILL_CROP_HEIGHT 1440
+#define DEFAULT_PREVIEW_VIDEO_WIDTH640
+#define DEFAULT_PREVIEW_VIDEO_HEIGHT 480
+
+/* Init params for pipeline devices */
+static const struct sensor_param init_sensor_param = {
+ .frame_rate = {
+ .frame_rate = 30,
+ },
+};
+
+static const struct isp_param init_isp_param = {
+ .control = {
+ .cmd = CONTROL_COMMAND_START,
+ .bypass = CONTROL_BYPASS_DISABLE,
+ },
+ .otf_input = {
+ .cmd = OTF_INPUT_COMMAND_DISABLE,
+ .width = DEFAULT_CAPTURE_STILL_WIDTH,
+ .height = DEFAULT_CAPTURE_STILL_HEIGHT,
+ .format = OTF_INPUT_FORMAT_BAYER,
+ .bitwidth = OTF_INPUT_BIT_WIDTH_10BIT,
+ .order = OTF_INPUT_ORDER_BAYER_GR_BG,
+ .frametime_max = 3,
+ },
+ .dma1_input = {
+ .cmd = DMA_INPUT_COMMAND_DISABLE,
+ },
+ .dma2_input = {
+ .cmd = DMA_INPUT_COMMAND_DISABLE,
+ },
+ .aa = {
+ .cmd = ISP_AA_COMMAND_START,
+ },
+ .flash = {
+ .cmd = ISP_FLASH_COMMAND_DISABLE,
+ .redeye = ISP_FLASH_REDEYE_DISABLE,
+ },
+ .awb = {
+ .cmd = ISP_AWB_COMMAND_AUTO,
+ },
+ .effect = {
+ .cmd = ISP_IMAGE_EFFECT_DISABLE,
+ },
+ .iso = {
+ .cmd = ISP_ISO_COMMAND_AUTO,
+ },
+ .adjust = {
+ .cmd = ISP_ADJUST_COMMAND_AUTO,
+ },
+ .metering = {
+ .cmd = ISP_METERING_COMMAND_CENTER,
+ .win_width = DEFAULT_CAPTURE_STILL_WIDTH,
+ .win_height = DEFAULT_CAPTURE_STILL_HEIGHT,
+ },
+ .afc = {
+ .cmd = ISP_AFC_COMMAND_AUTO,
+ },
+ .otf_output = {
+ .cmd = OTF_OUTPUT_COMMAND_ENABLE,
+ .width = DEFAULT_CAPTURE_STILL_WIDTH,
+ .height = DEFAULT_CAPTURE_STILL_HEIGHT,
+ .format = OTF_OUTPUT_FORMAT_YUV444,
+ .bitwidth = OTF_OUTPUT_BIT_WIDTH_12BIT,
+ .order = OTF_OUTPUT_ORDER_BAYER_GR_BG,
+ },
+ .dma1_output = {
+ .cmd = DMA_OUTPUT_COMMAND_DISABLE,
+ .width = DEFAULT_CAPTURE_STILL_WIDTH,
+ .height = DEFAULT_CAPTURE_STILL_HEIGHT,
+ .format = DMA_INPUT_FORMAT_YUV444,
+ .bitwidth = DMA_INPUT_BIT_WIDTH_8BIT,
+ .plane = 1,
+ .order = DMA_INPUT_ORDER_YCBCR,
+ },
+ .dma2_output = {
+ .cmd = DMA_OUTPUT_COMMAND_DISABLE,
+ .width = DEFAULT_CAPTURE_STILL_WIDTH,
+ .height = DEFAULT_CAPTURE_STILL_HEIGHT,
+ .format = DMA_OUTPUT_FORMAT_BAYER,
+ .bitwidth = DMA_OUTPUT_BIT_WIDTH_12BIT,
+ .plane = 1,
+ .order =
[PATCH v10 11/12] V4L: Add DT binding doc for s5k4e5 image sensor
S5K4E5 is a Samsung raw image sensor controlled via I2C.
This patch adds the DT binding documentation for the same.
Signed-off-by: Arun Kumar K arun...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
.../devicetree/bindings/media/samsung-s5k4e5.txt | 45
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/samsung-s5k4e5.txt
diff --git a/Documentation/devicetree/bindings/media/samsung-s5k4e5.txt
b/Documentation/devicetree/bindings/media/samsung-s5k4e5.txt
new file mode 100644
index 000..0fca087
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/samsung-s5k4e5.txt
@@ -0,0 +1,45 @@
+* Samsung S5K4E5 Raw Image Sensor
+
+S5K4E5 is a raw image sensor with maximum resolution of 2560x1920
+pixels. Data transfer is carried out via MIPI CSI-2 port and controls
+via I2C bus.
+
+Required Properties:
+- compatible : must be samsung,s5k4e5
+- reg : I2C device address
+- reset-gpios : specifier of a GPIO connected to the RESET pin
+- clocks : should contain the sensor's EXTCLK clock specifier, from
+ the common clock bindings
+- clock-names : should contain extclk entry
+- svdda-supply : core voltage supply
+- svddio-supply: I/O voltage supply
+
+Optional Properties:
+- clock-frequency : the frequency at which the extclk clock should be
+ configured to operate, in Hz; if this property is not
+ specified default 24 MHz value will be used
+
+The device node should be added to respective control bus controller
+(e.g. I2C0) nodes and linked to the csis port node, using the common
+video interfaces bindings, defined in video-interfaces.txt.
+
+Example:
+
+ i2c-isp@1313 {
+ s5k4e5@20 {
+ compatible = samsung,s5k4e5;
+ reg = 0x20;
+ reset-gpios = gpx1 2 1;
+ clock-frequency = 2400;
+ clocks = clock 129;
+ clock-names = extclk
+ svdda-supply = ...;
+ svddio-supply = ...;
+ port {
+ is_s5k4e5_ep: endpoint {
+ data-lanes = 1 2 3 4;
+ remote-endpoint = csis0_ep;
+ };
+ };
+ };
+ };
--
1.7.9.5
--
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 v10 10/12] exynos5-is: Add Kconfig and Makefile
Adds Kconfig and Makefile for exynos5-is driver files. Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com Signed-off-by: Arun Kumar K arun...@samsung.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com --- drivers/media/platform/Kconfig |1 + drivers/media/platform/Makefile|1 + drivers/media/platform/exynos5-is/Kconfig | 20 drivers/media/platform/exynos5-is/Makefile |7 +++ 4 files changed, 29 insertions(+) create mode 100644 drivers/media/platform/exynos5-is/Kconfig create mode 100644 drivers/media/platform/exynos5-is/Makefile diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index c7caf94..4d76065 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -123,6 +123,7 @@ config VIDEO_S3C_CAMIF source drivers/media/platform/soc_camera/Kconfig source drivers/media/platform/exynos4-is/Kconfig +source drivers/media/platform/exynos5-is/Kconfig source drivers/media/platform/s5p-tv/Kconfig endif # V4L_PLATFORM_DRIVERS diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index 4e4da48..712151a 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -37,6 +37,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV)+= s5p-tv/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)+= s5p-g2d/ obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/ +obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS5_CAMERA) += exynos5-is/ obj-$(CONFIG_BLACKFIN) += blackfin/ diff --git a/drivers/media/platform/exynos5-is/Kconfig b/drivers/media/platform/exynos5-is/Kconfig new file mode 100644 index 000..b67d11a --- /dev/null +++ b/drivers/media/platform/exynos5-is/Kconfig @@ -0,0 +1,20 @@ +config VIDEO_SAMSUNG_EXYNOS5_CAMERA + bool Samsung Exynos5 SoC Camera Media Device driver + depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API PM_RUNTIME + depends on VIDEO_SAMSUNG_EXYNOS4_IS + help + This is a V4L2 media device driver for Exynos5 SoC series + camera subsystem. + +if VIDEO_SAMSUNG_EXYNOS5_CAMERA + +config VIDEO_SAMSUNG_EXYNOS5_FIMC_IS + tristate Samsung Exynos5 SoC FIMC-IS driver + depends on I2C OF + depends on VIDEO_EXYNOS4_FIMC_IS + select VIDEOBUF2_DMA_CONTIG + help + This is a V4L2 driver for Samsung Exynos5 SoC series Imaging + Subsystem known as FIMC-IS. + +endif #VIDEO_SAMSUNG_EXYNOS5_MDEV diff --git a/drivers/media/platform/exynos5-is/Makefile b/drivers/media/platform/exynos5-is/Makefile new file mode 100644 index 000..6cdb037 --- /dev/null +++ b/drivers/media/platform/exynos5-is/Makefile @@ -0,0 +1,7 @@ +ccflags-y += -Idrivers/media/platform/exynos4-is +exynos5-fimc-is-objs := fimc-is-core.o fimc-is-isp.o fimc-is-scaler.o +exynos5-fimc-is-objs += fimc-is-pipeline.o fimc-is-interface.o fimc-is-sensor.o +exynos-mdevice-objs := exynos5-mdev.o + +obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS5_FIMC_IS) += exynos5-fimc-is.o +obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS5_CAMERA) += exynos-mdevice.o -- 1.7.9.5 -- 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 3/4] [media] exynos-scaler: Add m2m functionality for the SCALER driver
Hi Kamil,
As Shaik is on travel, I will correct this patch and post the updated version.
Hope its ok for you to take the corrected version of this patch alone
without re-spinning the whole series.
Regards
Arun
On Wed, Oct 16, 2013 at 3:26 PM, Kamil Debski k.deb...@samsung.com wrote:
Hi Shaik,
I tried to build your driver. It does not compile, so please fix it.
CC drivers/media/platform/exynos-scaler/scaler-m2m.o
drivers/media/platform/exynos-scaler/scaler-m2m.c: In function
'scaler_m2m_open':
drivers/media/platform/exynos-scaler/scaler-m2m.c:616:2: error: implicit
declaration of function 'kzalloc' [-Werror=implicit-function-declaration]
drivers/media/platform/exynos-scaler/scaler-m2m.c:616:6: warning: assignment
makes pointer from integer without a cast [enabled by default]
drivers/media/platform/exynos-scaler/scaler-m2m.c:665:2: error: implicit
declaration of function 'kfree' [-Werror=implicit-function-declaration]
Best wishes,
--
Kamil Debski
Linux Kernel Developer
Samsung RD Institute Poland
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Shaik Ameer Basha
Sent: Friday, October 04, 2013 2:27 PM
To: linux-media@vger.kernel.org; linux-samsung-...@vger.kernel.org
Cc: s.nawro...@samsung.com; posc...@google.com; inki@samsung.com;
hverk...@xs4all.nl; shaik.am...@samsung.com
Subject: [PATCH v4 3/4] [media] exynos-scaler: Add m2m functionality
for the SCALER driver
This patch adds the Makefile and memory to memory (m2m) interface
functionality for the SCALER driver.
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/media/platform/Kconfig|8 +
drivers/media/platform/Makefile |1 +
drivers/media/platform/exynos-scaler/Makefile |3 +
drivers/media/platform/exynos-scaler/scaler-m2m.c | 786
+
4 files changed, 798 insertions(+)
create mode 100644 drivers/media/platform/exynos-scaler/Makefile
create mode 100644 drivers/media/platform/exynos-scaler/scaler-m2m.c
diff --git a/drivers/media/platform/Kconfig
b/drivers/media/platform/Kconfig index 8068d7b..339d3ba 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -201,6 +201,14 @@ config VIDEO_SAMSUNG_EXYNOS_GSC
help
This is a v4l2 driver for Samsung EXYNOS5 SoC G-Scaler.
+config VIDEO_SAMSUNG_EXYNOS_SCALER
+ tristate Samsung Exynos SCALER driver
+ depends on OF VIDEO_DEV VIDEO_V4L2 ARCH_EXYNOS5
+ select VIDEOBUF2_DMA_CONTIG
+ select V4L2_MEM2MEM_DEV
+ help
+ This is a v4l2 driver for Samsung EXYNOS5410/5420 SoC SCALER.
+
config VIDEO_SH_VEU
tristate SuperH VEU mem2mem video processing driver
depends on VIDEO_DEV VIDEO_V4L2 GENERIC_HARDIRQS HAS_DMA
diff --git a/drivers/media/platform/Makefile
b/drivers/media/platform/Makefile index 4e4da48..14cdad5 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV) += s5p-tv/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D) += s5p-g2d/
obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/
+obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_SCALER)+= exynos-scaler/
obj-$(CONFIG_BLACKFIN) += blackfin/
diff --git a/drivers/media/platform/exynos-scaler/Makefile
b/drivers/media/platform/exynos-scaler/Makefile
new file mode 100644
index 000..6c8a25b
--- /dev/null
+++ b/drivers/media/platform/exynos-scaler/Makefile
@@ -0,0 +1,3 @@
+exynos-scaler-objs := scaler.o scaler-m2m.o scaler-regs.o
+
+obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_SCALER)+= exynos-scaler.o
diff --git a/drivers/media/platform/exynos-scaler/scaler-m2m.c
b/drivers/media/platform/exynos-scaler/scaler-m2m.c
new file mode 100644
index 000..eb3af85
--- /dev/null
+++ b/drivers/media/platform/exynos-scaler/scaler-m2m.c
@@ -0,0 +1,786 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series SCALER driver
+ *
+ * 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/module.h
+#include linux/pm_runtime.h
+
+#include media/v4l2-ioctl.h
+
+#include scaler-regs.h
+
+#define SCALER_DEF_PIX_FMT V4L2_PIX_FMT_RGB32
+#define SCALER_DEF_WIDTH 1280
+#define SCALER_DEF_HEIGHT720
+
+static int scaler_m2m_ctx_stop_req(struct scaler_ctx *ctx) {
+ struct scaler_ctx *curr_ctx;
+ struct scaler_dev *scaler = ctx-scaler_dev;
+ int ret;
+
+ curr_ctx = v4l2_m2m_get_curr_priv(scaler-m2m.m2m_dev);
+ if (!scaler_m2m_pending(scaler) || (curr_ctx != ctx))
+ return 0;
+
+ scaler_ctx_state_lock_set(SCALER_CTX_STOP_REQ, ctx);
+ ret =
[PATCH v5] exynos-scaler: Add m2m functionality for the SCALER driver
From: Shaik Ameer Basha shaik.am...@samsung.com
This patch adds the Makefile and memory to memory (m2m) interface
functionality for the SCALER driver.
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
This patch is part of the Exynos5 Series SCALER Driver patchset [1]
with the compilation error corrected for this patch alone.
[1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg67256.html
Changes from v4
---
- Addressed compilation error pointed out by Kamil
---
drivers/media/platform/Kconfig|8 +
drivers/media/platform/Makefile |1 +
drivers/media/platform/exynos-scaler/Makefile |3 +
drivers/media/platform/exynos-scaler/scaler-m2m.c | 787 +
4 files changed, 799 insertions(+)
create mode 100644 drivers/media/platform/exynos-scaler/Makefile
create mode 100644 drivers/media/platform/exynos-scaler/scaler-m2m.c
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c7caf94..1ba31ea2 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -201,6 +201,14 @@ config VIDEO_SAMSUNG_EXYNOS_GSC
help
This is a v4l2 driver for Samsung EXYNOS5 SoC G-Scaler.
+config VIDEO_SAMSUNG_EXYNOS_SCALER
+ tristate Samsung Exynos SCALER driver
+ depends on OF VIDEO_DEV VIDEO_V4L2 ARCH_EXYNOS5
+ select VIDEOBUF2_DMA_CONTIG
+ select V4L2_MEM2MEM_DEV
+ help
+ This is a v4l2 driver for Samsung EXYNOS5410/5420 SoC SCALER.
+
config VIDEO_SH_VEU
tristate SuperH VEU mem2mem video processing driver
depends on VIDEO_DEV VIDEO_V4L2 HAS_DMA
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 4e4da48..14cdad5 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV)+= s5p-tv/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)+= s5p-g2d/
obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/
+obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_SCALER) += exynos-scaler/
obj-$(CONFIG_BLACKFIN) += blackfin/
diff --git a/drivers/media/platform/exynos-scaler/Makefile
b/drivers/media/platform/exynos-scaler/Makefile
new file mode 100644
index 000..6c8a25b
--- /dev/null
+++ b/drivers/media/platform/exynos-scaler/Makefile
@@ -0,0 +1,3 @@
+exynos-scaler-objs := scaler.o scaler-m2m.o scaler-regs.o
+
+obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_SCALER) += exynos-scaler.o
diff --git a/drivers/media/platform/exynos-scaler/scaler-m2m.c
b/drivers/media/platform/exynos-scaler/scaler-m2m.c
new file mode 100644
index 000..987f314
--- /dev/null
+++ b/drivers/media/platform/exynos-scaler/scaler-m2m.c
@@ -0,0 +1,787 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series SCALER driver
+ *
+ * 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/module.h
+#include linux/pm_runtime.h
+#include linux/slab.h
+
+#include media/v4l2-ioctl.h
+
+#include scaler-regs.h
+
+#define SCALER_DEF_PIX_FMT V4L2_PIX_FMT_RGB32
+#define SCALER_DEF_WIDTH 1280
+#define SCALER_DEF_HEIGHT 720
+
+static int scaler_m2m_ctx_stop_req(struct scaler_ctx *ctx)
+{
+ struct scaler_ctx *curr_ctx;
+ struct scaler_dev *scaler = ctx-scaler_dev;
+ int ret;
+
+ curr_ctx = v4l2_m2m_get_curr_priv(scaler-m2m.m2m_dev);
+ if (!scaler_m2m_pending(scaler) || (curr_ctx != ctx))
+ return 0;
+
+ scaler_ctx_state_lock_set(SCALER_CTX_STOP_REQ, ctx);
+ ret = wait_event_timeout(scaler-irq_queue,
+ !scaler_ctx_state_is_set(SCALER_CTX_STOP_REQ, ctx),
+ SCALER_SHUTDOWN_TIMEOUT);
+
+ return ret == 0 ? -ETIMEDOUT : ret;
+}
+
+static int scaler_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
+{
+ struct scaler_ctx *ctx = q-drv_priv;
+ int ret;
+
+ ret = pm_runtime_get_sync(ctx-scaler_dev-pdev-dev);
+
+ return ret 0 ? 0 : ret;
+}
+
+static int scaler_m2m_stop_streaming(struct vb2_queue *q)
+{
+ struct scaler_ctx *ctx = q-drv_priv;
+ int ret;
+
+ ret = scaler_m2m_ctx_stop_req(ctx);
+ if (ret 0)
+ scaler_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+
+ pm_runtime_put(ctx-scaler_dev-pdev-dev);
+
+ return 0;
+}
+
+void scaler_m2m_job_finish(struct scaler_ctx *ctx, int vb_state)
+{
+ struct vb2_buffer *src_vb, *dst_vb;
+
+ if (!ctx || !ctx-m2m_ctx)
+ return;
+
+ src_vb = v4l2_m2m_src_buf_remove(ctx-m2m_ctx);
+ dst_vb = v4l2_m2m_dst_buf_remove(ctx-m2m_ctx);
+
+ if (src_vb dst_vb) {
+ v4l2_m2m_buf_done(src_vb, vb_state);
+
